[cut: only the first 33554432 bytes of this file were read]
-- MySQL dump 10.13  Distrib 5.5.41, for debian-linux-gnu (x86_64)
--
-- Host: localhost    Database: lcanas_mlstats_openstack_1376
-- ------------------------------------------------------
-- Server version	5.5.41-0+wheezy1

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `compressed_files`
--

DROP TABLE IF EXISTS `compressed_files`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `compressed_files` (
  `url` varchar(255) CHARACTER SET utf8 NOT NULL,
  `mailing_list_url` varchar(255) CHARACTER SET utf8 NOT NULL,
  `status` enum('new','visited','failed') DEFAULT NULL,
  `last_analysis` datetime DEFAULT NULL,
  PRIMARY KEY (`url`),
  KEY `mailing_list_url` (`mailing_list_url`),
  CONSTRAINT `compressed_files_ibfk_1` FOREIGN KEY (`mailing_list_url`) REFERENCES `mailing_lists` (`mailing_list_url`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `compressed_files`
--

LOCK TABLES `compressed_files` WRITE;
/*!40000 ALTER TABLE `compressed_files` DISABLE KEYS */;
INSERT INTO `compressed_files` VALUES ('http://lists.openstack.org/pipermail/community/2012-August.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:23'),('http://lists.openstack.org/pipermail/community/2012-December.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:26'),('http://lists.openstack.org/pipermail/community/2012-November.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:25'),('http://lists.openstack.org/pipermail/community/2012-October.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:24'),('http://lists.openstack.org/pipermail/community/2012-September.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:23'),('http://lists.openstack.org/pipermail/community/2013-April.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:35'),('http://lists.openstack.org/pipermail/community/2013-August.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:48'),('http://lists.openstack.org/pipermail/community/2013-December.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:11:00'),('http://lists.openstack.org/pipermail/community/2013-February.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:30'),('http://lists.openstack.org/pipermail/community/2013-January.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:29'),('http://lists.openstack.org/pipermail/community/2013-July.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:45'),('http://lists.openstack.org/pipermail/community/2013-June.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:40'),('http://lists.openstack.org/pipermail/community/2013-March.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:32'),('http://lists.openstack.org/pipermail/community/2013-May.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:38'),('http://lists.openstack.org/pipermail/community/2013-November.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:58'),('http://lists.openstack.org/pipermail/community/2013-October.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:56'),('http://lists.openstack.org/pipermail/community/2013-September.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:10:51'),('http://lists.openstack.org/pipermail/community/2014-April.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:11:04'),('http://lists.openstack.org/pipermail/community/2014-August.txt','http://lists.openstack.org/pipermail/community','visited','2014-08-04 18:55:11'),('http://lists.openstack.org/pipermail/community/2014-August.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-08-31 13:10:54'),('http://lists.openstack.org/pipermail/community/2014-December.txt','http://lists.openstack.org/pipermail/community','visited','2014-12-06 01:00:07'),('http://lists.openstack.org/pipermail/community/2014-December.txt.gz','http://lists.openstack.org/pipermail/community','visited','2015-01-01 01:00:15'),('http://lists.openstack.org/pipermail/community/2014-February.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:11:02'),('http://lists.openstack.org/pipermail/community/2014-January.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:11:01'),('http://lists.openstack.org/pipermail/community/2014-July.txt','http://lists.openstack.org/pipermail/community','visited','2014-07-01 20:26:50'),('http://lists.openstack.org/pipermail/community/2014-July.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-08-01 20:52:36'),('http://lists.openstack.org/pipermail/community/2014-June.txt','http://lists.openstack.org/pipermail/community','visited','2014-06-04 22:27:10'),('http://lists.openstack.org/pipermail/community/2014-June.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-07-01 20:26:49'),('http://lists.openstack.org/pipermail/community/2014-March.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-05-27 18:11:03'),('http://lists.openstack.org/pipermail/community/2014-May.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-06-01 20:30:47'),('http://lists.openstack.org/pipermail/community/2014-November.txt','http://lists.openstack.org/pipermail/community','visited','2014-11-11 22:42:10'),('http://lists.openstack.org/pipermail/community/2014-November.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-12-01 01:00:09'),('http://lists.openstack.org/pipermail/community/2014-October.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-10-30 14:13:41'),('http://lists.openstack.org/pipermail/community/2014-September.txt','http://lists.openstack.org/pipermail/community','visited','2014-09-04 07:07:33'),('http://lists.openstack.org/pipermail/community/2014-September.txt.gz','http://lists.openstack.org/pipermail/community','visited','2014-10-01 02:45:17'),('http://lists.openstack.org/pipermail/community/2015-February.txt','http://lists.openstack.org/pipermail/community','visited','2015-02-06 01:00:10'),('http://lists.openstack.org/pipermail/community/2015-January.txt','http://lists.openstack.org/pipermail/community','visited','2015-01-02 01:00:22'),('http://lists.openstack.org/pipermail/community/2015-January.txt.gz','http://lists.openstack.org/pipermail/community','visited','2015-02-01 01:00:04'),('http://lists.openstack.org/pipermail/fits/2011-September.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-05-27 18:11:08'),('http://lists.openstack.org/pipermail/fits/2012-April.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-05-27 18:11:08'),('http://lists.openstack.org/pipermail/fits/2014-April.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-05-27 18:11:09'),('http://lists.openstack.org/pipermail/fits/2014-July.txt','http://lists.openstack.org/pipermail/fits','visited','2014-08-01 20:52:40'),('http://lists.openstack.org/pipermail/fits/2014-July.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-09-18 01:42:38'),('http://lists.openstack.org/pipermail/fits/2014-June.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-07-01 20:26:51'),('http://lists.openstack.org/pipermail/fits/2014-March.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-05-27 18:11:08'),('http://lists.openstack.org/pipermail/fits/2014-May.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-06-01 20:30:49'),('http://lists.openstack.org/pipermail/fits/2014-October.txt','http://lists.openstack.org/pipermail/fits','visited','2014-10-30 14:13:49'),('http://lists.openstack.org/pipermail/fits/2014-October.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-11-02 09:39:29'),('http://lists.openstack.org/pipermail/fits/2014-September.txt','http://lists.openstack.org/pipermail/fits','visited','2014-09-24 03:24:13'),('http://lists.openstack.org/pipermail/fits/2014-September.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2014-10-01 02:45:20'),('http://lists.openstack.org/pipermail/fits/2015-February.txt','http://lists.openstack.org/pipermail/fits','visited','2015-02-06 01:00:22'),('http://lists.openstack.org/pipermail/fits/2015-January.txt','http://lists.openstack.org/pipermail/fits','visited','2015-01-09 01:04:51'),('http://lists.openstack.org/pipermail/fits/2015-January.txt.gz','http://lists.openstack.org/pipermail/fits','visited','2015-02-01 01:00:06'),('http://lists.openstack.org/pipermail/foundation/2011-November.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:28'),('http://lists.openstack.org/pipermail/foundation/2011-October.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:27'),('http://lists.openstack.org/pipermail/foundation/2012-April.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:39'),('http://lists.openstack.org/pipermail/foundation/2012-August.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:53'),('http://lists.openstack.org/pipermail/foundation/2012-December.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:05'),('http://lists.openstack.org/pipermail/foundation/2012-February.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:34'),('http://lists.openstack.org/pipermail/foundation/2012-January.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:31'),('http://lists.openstack.org/pipermail/foundation/2012-July.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:45'),('http://lists.openstack.org/pipermail/foundation/2012-March.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:39'),('http://lists.openstack.org/pipermail/foundation/2012-May.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:41'),('http://lists.openstack.org/pipermail/foundation/2012-November.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:04'),('http://lists.openstack.org/pipermail/foundation/2012-October.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:01'),('http://lists.openstack.org/pipermail/foundation/2012-September.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:11:55'),('http://lists.openstack.org/pipermail/foundation/2013-April.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:12'),('http://lists.openstack.org/pipermail/foundation/2013-August.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:15'),('http://lists.openstack.org/pipermail/foundation/2013-December.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:23'),('http://lists.openstack.org/pipermail/foundation/2013-February.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:10'),('http://lists.openstack.org/pipermail/foundation/2013-January.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:07'),('http://lists.openstack.org/pipermail/foundation/2013-July.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:14'),('http://lists.openstack.org/pipermail/foundation/2013-June.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:14'),('http://lists.openstack.org/pipermail/foundation/2013-March.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:11'),('http://lists.openstack.org/pipermail/foundation/2013-May.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:13'),('http://lists.openstack.org/pipermail/foundation/2013-November.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:23'),('http://lists.openstack.org/pipermail/foundation/2013-October.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:22'),('http://lists.openstack.org/pipermail/foundation/2013-September.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:16'),('http://lists.openstack.org/pipermail/foundation/2014-April.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:26'),('http://lists.openstack.org/pipermail/foundation/2014-August.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-08-31 13:11:09'),('http://lists.openstack.org/pipermail/foundation/2014-December.txt','http://lists.openstack.org/pipermail/foundation','visited','2014-12-19 01:00:19'),('http://lists.openstack.org/pipermail/foundation/2014-December.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2015-01-01 01:00:22'),('http://lists.openstack.org/pipermail/foundation/2014-February.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:25'),('http://lists.openstack.org/pipermail/foundation/2014-January.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:24'),('http://lists.openstack.org/pipermail/foundation/2014-July.txt','http://lists.openstack.org/pipermail/foundation','visited','2014-07-01 20:26:53'),('http://lists.openstack.org/pipermail/foundation/2014-July.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-08-01 20:53:00'),('http://lists.openstack.org/pipermail/foundation/2014-June.txt','http://lists.openstack.org/pipermail/foundation','visited','2014-06-22 11:53:51'),('http://lists.openstack.org/pipermail/foundation/2014-June.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-07-01 20:26:53'),('http://lists.openstack.org/pipermail/foundation/2014-March.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-05-27 18:12:25'),('http://lists.openstack.org/pipermail/foundation/2014-May.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-06-01 20:30:51'),('http://lists.openstack.org/pipermail/foundation/2014-November.txt','http://lists.openstack.org/pipermail/foundation','visited','2014-11-02 09:39:39'),('http://lists.openstack.org/pipermail/foundation/2014-November.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-12-01 01:00:14'),('http://lists.openstack.org/pipermail/foundation/2014-October.txt','http://lists.openstack.org/pipermail/foundation','visited','2014-10-02 03:45:29'),('http://lists.openstack.org/pipermail/foundation/2014-October.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-10-30 14:13:51'),('http://lists.openstack.org/pipermail/foundation/2014-September.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2014-10-01 02:45:25'),('http://lists.openstack.org/pipermail/foundation/2015-February.txt','http://lists.openstack.org/pipermail/foundation','visited','2015-02-04 01:00:19'),('http://lists.openstack.org/pipermail/foundation/2015-February.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2015-02-06 01:00:31'),('http://lists.openstack.org/pipermail/foundation/2015-January.txt','http://lists.openstack.org/pipermail/foundation','visited','2015-01-12 01:00:29'),('http://lists.openstack.org/pipermail/foundation/2015-January.txt.gz','http://lists.openstack.org/pipermail/foundation','visited','2015-02-01 01:00:15'),('http://lists.openstack.org/pipermail/openstack-announce/2010-November.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2011-April.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2011-August.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2011-February.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2011-July.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2011-March.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:41'),('http://lists.openstack.org/pipermail/openstack-announce/2012-August.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:42'),('http://lists.openstack.org/pipermail/openstack-announce/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:44'),('http://lists.openstack.org/pipermail/openstack-announce/2012-July.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:42'),('http://lists.openstack.org/pipermail/openstack-announce/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:44'),('http://lists.openstack.org/pipermail/openstack-announce/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:43'),('http://lists.openstack.org/pipermail/openstack-announce/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:43'),('http://lists.openstack.org/pipermail/openstack-announce/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:46'),('http://lists.openstack.org/pipermail/openstack-announce/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:49'),('http://lists.openstack.org/pipermail/openstack-announce/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:52'),('http://lists.openstack.org/pipermail/openstack-announce/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:45'),('http://lists.openstack.org/pipermail/openstack-announce/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:45'),('http://lists.openstack.org/pipermail/openstack-announce/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:48'),('http://lists.openstack.org/pipermail/openstack-announce/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:47'),('http://lists.openstack.org/pipermail/openstack-announce/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:46'),('http://lists.openstack.org/pipermail/openstack-announce/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:47'),('http://lists.openstack.org/pipermail/openstack-announce/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:51'),('http://lists.openstack.org/pipermail/openstack-announce/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:50'),('http://lists.openstack.org/pipermail/openstack-announce/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:49'),('http://lists.openstack.org/pipermail/openstack-announce/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:54'),('http://lists.openstack.org/pipermail/openstack-announce/2014-August.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-08-06 21:51:01'),('http://lists.openstack.org/pipermail/openstack-announce/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-08-31 13:11:16'),('http://lists.openstack.org/pipermail/openstack-announce/2014-December.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-12-09 01:00:26'),('http://lists.openstack.org/pipermail/openstack-announce/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2015-01-01 01:00:36'),('http://lists.openstack.org/pipermail/openstack-announce/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:53'),('http://lists.openstack.org/pipermail/openstack-announce/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:52'),('http://lists.openstack.org/pipermail/openstack-announce/2014-July.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-07-03 21:56:11'),('http://lists.openstack.org/pipermail/openstack-announce/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-08-01 20:53:03'),('http://lists.openstack.org/pipermail/openstack-announce/2014-June.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-06-08 23:48:19'),('http://lists.openstack.org/pipermail/openstack-announce/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-07-01 20:26:55'),('http://lists.openstack.org/pipermail/openstack-announce/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-05-27 18:12:53'),('http://lists.openstack.org/pipermail/openstack-announce/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-06-01 20:30:53'),('http://lists.openstack.org/pipermail/openstack-announce/2014-November.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-11-18 11:46:22'),('http://lists.openstack.org/pipermail/openstack-announce/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-12-01 01:00:17'),('http://lists.openstack.org/pipermail/openstack-announce/2014-October.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-10-03 15:07:46'),('http://lists.openstack.org/pipermail/openstack-announce/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-10-30 14:13:52'),('http://lists.openstack.org/pipermail/openstack-announce/2014-September.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-09-05 15:44:25'),('http://lists.openstack.org/pipermail/openstack-announce/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2014-10-01 02:45:30'),('http://lists.openstack.org/pipermail/openstack-announce/2015-February.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2015-02-05 01:00:29'),('http://lists.openstack.org/pipermail/openstack-announce/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2015-02-06 01:01:12'),('http://lists.openstack.org/pipermail/openstack-announce/2015-January.txt','http://lists.openstack.org/pipermail/openstack-announce','visited','2015-01-08 01:00:42'),('http://lists.openstack.org/pipermail/openstack-announce/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-announce','visited','2015-02-01 01:00:17'),('http://lists.openstack.org/pipermail/openstack-dev/2012-August.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:14:45'),('http://lists.openstack.org/pipermail/openstack-dev/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:18:50'),('http://lists.openstack.org/pipermail/openstack-dev/2012-July.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:14:06'),('http://lists.openstack.org/pipermail/openstack-dev/2012-June.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:13:52'),('http://lists.openstack.org/pipermail/openstack-dev/2012-May.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:13:52'),('http://lists.openstack.org/pipermail/openstack-dev/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:17:39'),('http://lists.openstack.org/pipermail/openstack-dev/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:15:46'),('http://lists.openstack.org/pipermail/openstack-dev/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:15:12'),('http://lists.openstack.org/pipermail/openstack-dev/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:26:41'),('http://lists.openstack.org/pipermail/openstack-dev/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:38:46'),('http://lists.openstack.org/pipermail/openstack-dev/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:56:29'),('http://lists.openstack.org/pipermail/openstack-dev/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:22:30'),('http://lists.openstack.org/pipermail/openstack-dev/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:20:56'),('http://lists.openstack.org/pipermail/openstack-dev/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:35:33'),('http://lists.openstack.org/pipermail/openstack-dev/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:32:09'),('http://lists.openstack.org/pipermail/openstack-dev/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:24:19'),('http://lists.openstack.org/pipermail/openstack-dev/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:29:35'),('http://lists.openstack.org/pipermail/openstack-dev/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:51:28'),('http://lists.openstack.org/pipermail/openstack-dev/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:45:55'),('http://lists.openstack.org/pipermail/openstack-dev/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 18:41:25'),('http://lists.openstack.org/pipermail/openstack-dev/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 19:17:59'),('http://lists.openstack.org/pipermail/openstack-dev/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-08-31 13:12:30'),('http://lists.openstack.org/pipermail/openstack-dev/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2015-01-01 01:03:37'),('http://lists.openstack.org/pipermail/openstack-dev/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 19:06:58'),('http://lists.openstack.org/pipermail/openstack-dev/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 19:02:00'),('http://lists.openstack.org/pipermail/openstack-dev/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-08-01 20:53:53'),('http://lists.openstack.org/pipermail/openstack-dev/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-07-01 20:27:03'),('http://lists.openstack.org/pipermail/openstack-dev/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-05-27 19:12:45'),('http://lists.openstack.org/pipermail/openstack-dev/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-06-01 20:31:18'),('http://lists.openstack.org/pipermail/openstack-dev/2014-November.txt','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-11-02 09:40:08'),('http://lists.openstack.org/pipermail/openstack-dev/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-12-01 01:03:05'),('http://lists.openstack.org/pipermail/openstack-dev/2014-October.txt','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-10-01 02:46:44'),('http://lists.openstack.org/pipermail/openstack-dev/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-10-30 14:14:29'),('http://lists.openstack.org/pipermail/openstack-dev/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2014-10-01 02:46:44'),('http://lists.openstack.org/pipermail/openstack-dev/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2015-02-06 01:03:43'),('http://lists.openstack.org/pipermail/openstack-dev/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-dev','visited','2015-02-01 01:03:12'),('http://lists.openstack.org/pipermail/openstack-docs/2012-August.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:22:09'),('http://lists.openstack.org/pipermail/openstack-docs/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:23:02'),('http://lists.openstack.org/pipermail/openstack-docs/2012-July.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:21:58'),('http://lists.openstack.org/pipermail/openstack-docs/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:22:41'),('http://lists.openstack.org/pipermail/openstack-docs/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:22:18'),('http://lists.openstack.org/pipermail/openstack-docs/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:22:12'),('http://lists.openstack.org/pipermail/openstack-docs/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:24:29'),('http://lists.openstack.org/pipermail/openstack-docs/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:25:40'),('http://lists.openstack.org/pipermail/openstack-docs/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:27:29'),('http://lists.openstack.org/pipermail/openstack-docs/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:24:04'),('http://lists.openstack.org/pipermail/openstack-docs/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:23:34'),('http://lists.openstack.org/pipermail/openstack-docs/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:25:17'),('http://lists.openstack.org/pipermail/openstack-docs/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:24:57'),('http://lists.openstack.org/pipermail/openstack-docs/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:24:12'),('http://lists.openstack.org/pipermail/openstack-docs/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:24:46'),('http://lists.openstack.org/pipermail/openstack-docs/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:27:14'),('http://lists.openstack.org/pipermail/openstack-docs/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:26:51'),('http://lists.openstack.org/pipermail/openstack-docs/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:26:11'),('http://lists.openstack.org/pipermail/openstack-docs/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:29:02'),('http://lists.openstack.org/pipermail/openstack-docs/2014-August.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-08-02 18:01:32'),('http://lists.openstack.org/pipermail/openstack-docs/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-08-31 13:12:36'),('http://lists.openstack.org/pipermail/openstack-docs/2014-December.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-12-02 01:01:04'),('http://lists.openstack.org/pipermail/openstack-docs/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2015-01-01 01:03:42'),('http://lists.openstack.org/pipermail/openstack-docs/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:28:15'),('http://lists.openstack.org/pipermail/openstack-docs/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:27:56'),('http://lists.openstack.org/pipermail/openstack-docs/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-08-01 20:54:11'),('http://lists.openstack.org/pipermail/openstack-docs/2014-June.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-06-01 20:31:22'),('http://lists.openstack.org/pipermail/openstack-docs/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-07-01 20:27:05'),('http://lists.openstack.org/pipermail/openstack-docs/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-05-27 19:28:46'),('http://lists.openstack.org/pipermail/openstack-docs/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-06-01 20:31:21'),('http://lists.openstack.org/pipermail/openstack-docs/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-12-01 01:03:12'),('http://lists.openstack.org/pipermail/openstack-docs/2014-October.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-10-02 03:45:38'),('http://lists.openstack.org/pipermail/openstack-docs/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-10-30 14:14:34'),('http://lists.openstack.org/pipermail/openstack-docs/2014-September.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-09-02 13:35:20'),('http://lists.openstack.org/pipermail/openstack-docs/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2014-10-01 02:46:49'),('http://lists.openstack.org/pipermail/openstack-docs/2015-February.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2015-02-02 01:00:18'),('http://lists.openstack.org/pipermail/openstack-docs/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2015-02-06 01:03:53'),('http://lists.openstack.org/pipermail/openstack-docs/2015-January.txt','http://lists.openstack.org/pipermail/openstack-docs','visited','2015-01-05 01:00:49'),('http://lists.openstack.org/pipermail/openstack-docs/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-docs','visited','2015-02-01 01:03:17'),('http://lists.openstack.org/pipermail/openstack-hpc/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:34'),('http://lists.openstack.org/pipermail/openstack-hpc/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:33'),('http://lists.openstack.org/pipermail/openstack-hpc/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:32'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:35'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:39'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:41'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:34'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:39'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:40'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:39'),('http://lists.openstack.org/pipermail/openstack-hpc/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:39'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:42'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-December.txt','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-12-14 01:03:35'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2015-01-01 01:03:44'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:41'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:41'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-July.txt','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-08-01 20:54:14'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-11-10 16:12:14'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-June.txt','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-06-30 01:32:48'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-07-01 20:27:06'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-05-27 19:29:41'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-06-01 20:31:23'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-November.txt','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-11-25 01:02:46'),('http://lists.openstack.org/pipermail/openstack-hpc/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2014-12-01 01:03:15'),('http://lists.openstack.org/pipermail/openstack-hpc/2015-January.txt','http://lists.openstack.org/pipermail/openstack-hpc','visited','2015-01-07 01:02:54'),('http://lists.openstack.org/pipermail/openstack-hpc/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-hpc','visited','2015-02-01 01:03:19'),('http://lists.openstack.org/pipermail/openstack-infra/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:56'),('http://lists.openstack.org/pipermail/openstack-infra/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:55'),('http://lists.openstack.org/pipermail/openstack-infra/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:55'),('http://lists.openstack.org/pipermail/openstack-infra/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:55'),('http://lists.openstack.org/pipermail/openstack-infra/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:59'),('http://lists.openstack.org/pipermail/openstack-infra/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:08'),('http://lists.openstack.org/pipermail/openstack-infra/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:47'),('http://lists.openstack.org/pipermail/openstack-infra/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:57'),('http://lists.openstack.org/pipermail/openstack-infra/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:57'),('http://lists.openstack.org/pipermail/openstack-infra/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:05'),('http://lists.openstack.org/pipermail/openstack-infra/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:02'),('http://lists.openstack.org/pipermail/openstack-infra/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:29:57'),('http://lists.openstack.org/pipermail/openstack-infra/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:00'),('http://lists.openstack.org/pipermail/openstack-infra/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:33'),('http://lists.openstack.org/pipermail/openstack-infra/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:22'),('http://lists.openstack.org/pipermail/openstack-infra/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:30:13'),('http://lists.openstack.org/pipermail/openstack-infra/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:32:01'),('http://lists.openstack.org/pipermail/openstack-infra/2014-August.txt','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-08-01 20:54:23'),('http://lists.openstack.org/pipermail/openstack-infra/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-08-31 13:12:43'),('http://lists.openstack.org/pipermail/openstack-infra/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2015-01-01 01:03:48'),('http://lists.openstack.org/pipermail/openstack-infra/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:31:27'),('http://lists.openstack.org/pipermail/openstack-infra/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:31:04'),('http://lists.openstack.org/pipermail/openstack-infra/2014-July.txt','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-07-01 20:27:09'),('http://lists.openstack.org/pipermail/openstack-infra/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-08-01 20:54:22'),('http://lists.openstack.org/pipermail/openstack-infra/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-07-01 20:27:08'),('http://lists.openstack.org/pipermail/openstack-infra/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-05-27 19:31:53'),('http://lists.openstack.org/pipermail/openstack-infra/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-06-01 20:31:25'),('http://lists.openstack.org/pipermail/openstack-infra/2014-November.txt','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-11-02 09:40:12'),('http://lists.openstack.org/pipermail/openstack-infra/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-12-01 01:03:20'),('http://lists.openstack.org/pipermail/openstack-infra/2014-October.txt','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-10-02 03:45:58'),('http://lists.openstack.org/pipermail/openstack-infra/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-10-30 14:14:40'),('http://lists.openstack.org/pipermail/openstack-infra/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2014-10-01 02:47:12'),('http://lists.openstack.org/pipermail/openstack-infra/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2015-02-06 01:03:57'),('http://lists.openstack.org/pipermail/openstack-infra/2015-January.txt','http://lists.openstack.org/pipermail/openstack-infra','visited','2015-01-02 01:01:12'),('http://lists.openstack.org/pipermail/openstack-infra/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-infra','visited','2015-02-01 01:03:30'),('http://lists.openstack.org/pipermail/openstack-operators/2010-December.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:42'),('http://lists.openstack.org/pipermail/openstack-operators/2010-November.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:42'),('http://lists.openstack.org/pipermail/openstack-operators/2011-April.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:45'),('http://lists.openstack.org/pipermail/openstack-operators/2011-August.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:57'),('http://lists.openstack.org/pipermail/openstack-operators/2011-December.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:09'),('http://lists.openstack.org/pipermail/openstack-operators/2011-February.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:44'),('http://lists.openstack.org/pipermail/openstack-operators/2011-January.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:43'),('http://lists.openstack.org/pipermail/openstack-operators/2011-July.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:55'),('http://lists.openstack.org/pipermail/openstack-operators/2011-June.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:51'),('http://lists.openstack.org/pipermail/openstack-operators/2011-March.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:44'),('http://lists.openstack.org/pipermail/openstack-operators/2011-May.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:48'),('http://lists.openstack.org/pipermail/openstack-operators/2011-November.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:07'),('http://lists.openstack.org/pipermail/openstack-operators/2011-October.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:04'),('http://lists.openstack.org/pipermail/openstack-operators/2011-September.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:32:59'),('http://lists.openstack.org/pipermail/openstack-operators/2012-April.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:24'),('http://lists.openstack.org/pipermail/openstack-operators/2012-August.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:34:19'),('http://lists.openstack.org/pipermail/openstack-operators/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:35:06'),('http://lists.openstack.org/pipermail/openstack-operators/2012-February.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:15'),('http://lists.openstack.org/pipermail/openstack-operators/2012-January.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:13'),('http://lists.openstack.org/pipermail/openstack-operators/2012-July.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:59'),('http://lists.openstack.org/pipermail/openstack-operators/2012-June.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:49'),('http://lists.openstack.org/pipermail/openstack-operators/2012-March.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:16'),('http://lists.openstack.org/pipermail/openstack-operators/2012-May.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:33:45'),('http://lists.openstack.org/pipermail/openstack-operators/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:34:59'),('http://lists.openstack.org/pipermail/openstack-operators/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:34:42'),('http://lists.openstack.org/pipermail/openstack-operators/2012-September.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:34:33'),('http://lists.openstack.org/pipermail/openstack-operators/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:36:02'),('http://lists.openstack.org/pipermail/openstack-operators/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:37:13'),('http://lists.openstack.org/pipermail/openstack-operators/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:37:52'),('http://lists.openstack.org/pipermail/openstack-operators/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:35:23'),('http://lists.openstack.org/pipermail/openstack-operators/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:35:18'),('http://lists.openstack.org/pipermail/openstack-operators/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:36:56'),('http://lists.openstack.org/pipermail/openstack-operators/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:36:39'),('http://lists.openstack.org/pipermail/openstack-operators/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:35:38'),('http://lists.openstack.org/pipermail/openstack-operators/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:36:24'),('http://lists.openstack.org/pipermail/openstack-operators/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:37:45'),('http://lists.openstack.org/pipermail/openstack-operators/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:37:37'),('http://lists.openstack.org/pipermail/openstack-operators/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:37:23'),('http://lists.openstack.org/pipermail/openstack-operators/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:38:59'),('http://lists.openstack.org/pipermail/openstack-operators/2014-August.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-08-01 20:54:28'),('http://lists.openstack.org/pipermail/openstack-operators/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-08-31 13:12:50'),('http://lists.openstack.org/pipermail/openstack-operators/2014-December.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-12-02 01:01:24'),('http://lists.openstack.org/pipermail/openstack-operators/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2015-01-01 01:04:10'),('http://lists.openstack.org/pipermail/openstack-operators/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:38:24'),('http://lists.openstack.org/pipermail/openstack-operators/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:38:09'),('http://lists.openstack.org/pipermail/openstack-operators/2014-July.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-07-01 10:38:11'),('http://lists.openstack.org/pipermail/openstack-operators/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-08-01 20:54:28'),('http://lists.openstack.org/pipermail/openstack-operators/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-07-01 20:27:11'),('http://lists.openstack.org/pipermail/openstack-operators/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-05-27 19:38:41'),('http://lists.openstack.org/pipermail/openstack-operators/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-06-01 20:31:30'),('http://lists.openstack.org/pipermail/openstack-operators/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-12-01 01:03:27'),('http://lists.openstack.org/pipermail/openstack-operators/2014-October.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-10-02 03:46:03'),('http://lists.openstack.org/pipermail/openstack-operators/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-10-30 14:14:52'),('http://lists.openstack.org/pipermail/openstack-operators/2014-September.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-09-02 13:35:25'),('http://lists.openstack.org/pipermail/openstack-operators/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2014-10-01 02:47:23'),('http://lists.openstack.org/pipermail/openstack-operators/2015-February.txt','http://lists.openstack.org/pipermail/openstack-operators','visited','2015-02-02 01:00:41'),('http://lists.openstack.org/pipermail/openstack-operators/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2015-02-06 01:04:18'),('http://lists.openstack.org/pipermail/openstack-operators/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-operators','visited','2015-02-01 01:03:40'),('http://lists.openstack.org/pipermail/openstack-qa/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:39:40'),('http://lists.openstack.org/pipermail/openstack-qa/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:39:35'),('http://lists.openstack.org/pipermail/openstack-qa/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:09'),('http://lists.openstack.org/pipermail/openstack-qa/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:57'),('http://lists.openstack.org/pipermail/openstack-qa/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:26'),('http://lists.openstack.org/pipermail/openstack-qa/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:01'),('http://lists.openstack.org/pipermail/openstack-qa/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:39:52'),('http://lists.openstack.org/pipermail/openstack-qa/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:49'),('http://lists.openstack.org/pipermail/openstack-qa/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:37'),('http://lists.openstack.org/pipermail/openstack-qa/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:06'),('http://lists.openstack.org/pipermail/openstack-qa/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:40:24'),('http://lists.openstack.org/pipermail/openstack-qa/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:20'),('http://lists.openstack.org/pipermail/openstack-qa/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:14'),('http://lists.openstack.org/pipermail/openstack-qa/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:08'),('http://lists.openstack.org/pipermail/openstack-qa/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:41'),('http://lists.openstack.org/pipermail/openstack-qa/2014-August.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-08-01 20:54:30'),('http://lists.openstack.org/pipermail/openstack-qa/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-08-31 13:12:59'),('http://lists.openstack.org/pipermail/openstack-qa/2014-December.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-12-04 01:02:51'),('http://lists.openstack.org/pipermail/openstack-qa/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2015-01-01 01:04:12'),('http://lists.openstack.org/pipermail/openstack-qa/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:34'),('http://lists.openstack.org/pipermail/openstack-qa/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:30'),('http://lists.openstack.org/pipermail/openstack-qa/2014-July.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-07-01 10:38:14'),('http://lists.openstack.org/pipermail/openstack-qa/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-08-01 20:54:30'),('http://lists.openstack.org/pipermail/openstack-qa/2014-June.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-06-01 20:31:31'),('http://lists.openstack.org/pipermail/openstack-qa/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-07-01 20:27:12'),('http://lists.openstack.org/pipermail/openstack-qa/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-05-27 19:41:37'),('http://lists.openstack.org/pipermail/openstack-qa/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-06-01 20:31:31'),('http://lists.openstack.org/pipermail/openstack-qa/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-12-01 01:03:29'),('http://lists.openstack.org/pipermail/openstack-qa/2014-October.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-10-02 03:46:07'),('http://lists.openstack.org/pipermail/openstack-qa/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-10-30 14:14:53'),('http://lists.openstack.org/pipermail/openstack-qa/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2014-10-01 02:47:26'),('http://lists.openstack.org/pipermail/openstack-qa/2015-February.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2015-02-02 01:01:13'),('http://lists.openstack.org/pipermail/openstack-qa/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2015-02-06 01:04:21'),('http://lists.openstack.org/pipermail/openstack-qa/2015-January.txt','http://lists.openstack.org/pipermail/openstack-qa','visited','2015-01-02 01:01:20'),('http://lists.openstack.org/pipermail/openstack-qa/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-qa','visited','2015-02-01 01:03:43'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:42:30'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:42:18'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:43:21'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:44:41'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:46:11'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:42:48'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:42:44'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:44:16'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:43:56'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:42:57'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:43:46'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:45:46'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:45:19'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:44:56'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:46:47'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-August.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-08-01 20:54:34'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-08-31 13:13:03'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-December.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-12-04 01:02:55'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2015-01-01 01:04:16'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:46:37'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:46:22'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-July.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-07-10 23:46:30'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-08-01 20:54:34'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-June.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-06-02 20:24:06'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-07-01 20:27:13'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-05-27 19:46:43'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-06-01 20:31:33'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-12-01 01:03:31'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-October.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-10-02 03:46:09'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-10-30 14:14:58'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2014-10-01 02:47:34'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2015-February.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2015-02-03 01:02:15'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2015-02-06 01:04:23'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2015-January.txt','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2015-01-02 01:01:26'),('http://lists.openstack.org/pipermail/openstack-stable-maint/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-stable-maint','visited','2015-02-01 01:03:45'),('http://lists.openstack.org/pipermail/openstack-tc/2012-December.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:12'),('http://lists.openstack.org/pipermail/openstack-tc/2012-November.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:11'),('http://lists.openstack.org/pipermail/openstack-tc/2012-October.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:08'),('http://lists.openstack.org/pipermail/openstack-tc/2013-April.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:26'),('http://lists.openstack.org/pipermail/openstack-tc/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:41'),('http://lists.openstack.org/pipermail/openstack-tc/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:57'),('http://lists.openstack.org/pipermail/openstack-tc/2013-February.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:15'),('http://lists.openstack.org/pipermail/openstack-tc/2013-January.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:14'),('http://lists.openstack.org/pipermail/openstack-tc/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:39'),('http://lists.openstack.org/pipermail/openstack-tc/2013-June.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:34'),('http://lists.openstack.org/pipermail/openstack-tc/2013-March.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:16'),('http://lists.openstack.org/pipermail/openstack-tc/2013-May.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:32'),('http://lists.openstack.org/pipermail/openstack-tc/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:51'),('http://lists.openstack.org/pipermail/openstack-tc/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:46'),('http://lists.openstack.org/pipermail/openstack-tc/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:47:43'),('http://lists.openstack.org/pipermail/openstack-tc/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:48:29'),('http://lists.openstack.org/pipermail/openstack-tc/2014-August.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-08-03 20:53:55'),('http://lists.openstack.org/pipermail/openstack-tc/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-08-31 13:13:05'),('http://lists.openstack.org/pipermail/openstack-tc/2014-December.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-12-08 01:02:40'),('http://lists.openstack.org/pipermail/openstack-tc/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2015-01-01 01:04:21'),('http://lists.openstack.org/pipermail/openstack-tc/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:48:06'),('http://lists.openstack.org/pipermail/openstack-tc/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:48:03'),('http://lists.openstack.org/pipermail/openstack-tc/2014-July.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-07-07 10:09:43'),('http://lists.openstack.org/pipermail/openstack-tc/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-08-01 20:54:36'),('http://lists.openstack.org/pipermail/openstack-tc/2014-June.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-06-03 22:11:40'),('http://lists.openstack.org/pipermail/openstack-tc/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-07-01 20:27:15'),('http://lists.openstack.org/pipermail/openstack-tc/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-05-27 19:48:16'),('http://lists.openstack.org/pipermail/openstack-tc/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-06-01 20:31:34'),('http://lists.openstack.org/pipermail/openstack-tc/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-12-01 01:03:34'),('http://lists.openstack.org/pipermail/openstack-tc/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-10-30 14:14:59'),('http://lists.openstack.org/pipermail/openstack-tc/2014-September.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-09-02 13:35:29'),('http://lists.openstack.org/pipermail/openstack-tc/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2014-10-01 02:47:36'),('http://lists.openstack.org/pipermail/openstack-tc/2015-February.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2015-02-06 01:04:25'),('http://lists.openstack.org/pipermail/openstack-tc/2015-January.txt','http://lists.openstack.org/pipermail/openstack-tc','visited','2015-01-07 01:03:19'),('http://lists.openstack.org/pipermail/openstack-tc/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack-tc','visited','2015-02-01 01:03:47'),('http://lists.openstack.org/pipermail/openstack/2013-August.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:51:47'),('http://lists.openstack.org/pipermail/openstack/2013-December.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:58:38'),('http://lists.openstack.org/pipermail/openstack/2013-July.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:50:05'),('http://lists.openstack.org/pipermail/openstack/2013-November.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:56:55'),('http://lists.openstack.org/pipermail/openstack/2013-October.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:54:58'),('http://lists.openstack.org/pipermail/openstack/2013-September.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 19:53:09'),('http://lists.openstack.org/pipermail/openstack/2014-April.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 20:03:33'),('http://lists.openstack.org/pipermail/openstack/2014-August.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-08-31 13:13:23'),('http://lists.openstack.org/pipermail/openstack/2014-December.txt','http://lists.openstack.org/pipermail/openstack','visited','2014-12-02 01:02:03'),('http://lists.openstack.org/pipermail/openstack/2014-December.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2015-01-01 01:04:46'),('http://lists.openstack.org/pipermail/openstack/2014-February.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 20:01:33'),('http://lists.openstack.org/pipermail/openstack/2014-January.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 20:00:23'),('http://lists.openstack.org/pipermail/openstack/2014-July.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-08-01 20:54:49'),('http://lists.openstack.org/pipermail/openstack/2014-June.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-07-01 20:27:22'),('http://lists.openstack.org/pipermail/openstack/2014-March.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-05-27 20:02:51'),('http://lists.openstack.org/pipermail/openstack/2014-May.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-06-01 20:31:42'),('http://lists.openstack.org/pipermail/openstack/2014-November.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-12-01 01:03:53'),('http://lists.openstack.org/pipermail/openstack/2014-October.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-10-30 14:15:09'),('http://lists.openstack.org/pipermail/openstack/2014-September.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2014-10-01 02:47:56'),('http://lists.openstack.org/pipermail/openstack/2015-February.txt','http://lists.openstack.org/pipermail/openstack','visited','2015-02-03 01:02:49'),('http://lists.openstack.org/pipermail/openstack/2015-February.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2015-02-06 01:04:56'),('http://lists.openstack.org/pipermail/openstack/2015-January.txt','http://lists.openstack.org/pipermail/openstack','visited','2015-01-02 01:01:48'),('http://lists.openstack.org/pipermail/openstack/2015-January.txt.gz','http://lists.openstack.org/pipermail/openstack','visited','2015-02-01 01:03:58'),('http://lists.openstack.org/pipermail/transparency/2013-April.txt.gz','http://lists.openstack.org/pipermail/transparency','visited','2014-05-27 19:48:35'),('http://lists.openstack.org/pipermail/transparency/2013-February.txt.gz','http://lists.openstack.org/pipermail/transparency','visited','2014-05-27 19:48:35'),('http://lists.openstack.org/pipermail/transparency/2013-October.txt.gz','http://lists.openstack.org/pipermail/transparency','visited','2014-05-27 19:48:37'),('http://lists.openstack.org/pipermail/user-committee/2012-December.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:48:46'),('http://lists.openstack.org/pipermail/user-committee/2013-April.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:04'),('http://lists.openstack.org/pipermail/user-committee/2013-December.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:16'),('http://lists.openstack.org/pipermail/user-committee/2013-February.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:48:52'),('http://lists.openstack.org/pipermail/user-committee/2013-January.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:48:48'),('http://lists.openstack.org/pipermail/user-committee/2013-July.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:13'),('http://lists.openstack.org/pipermail/user-committee/2013-June.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:09'),('http://lists.openstack.org/pipermail/user-committee/2013-March.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:48:57'),('http://lists.openstack.org/pipermail/user-committee/2013-May.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:07'),('http://lists.openstack.org/pipermail/user-committee/2013-November.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:15'),('http://lists.openstack.org/pipermail/user-committee/2013-October.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:14'),('http://lists.openstack.org/pipermail/user-committee/2013-September.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:13'),('http://lists.openstack.org/pipermail/user-committee/2014-April.txt','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:23'),('http://lists.openstack.org/pipermail/user-committee/2014-April.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-07-01 20:27:17'),('http://lists.openstack.org/pipermail/user-committee/2014-August.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-08-31 13:13:09'),('http://lists.openstack.org/pipermail/user-committee/2014-December.txt','http://lists.openstack.org/pipermail/user-committee','visited','2014-12-10 01:04:00'),('http://lists.openstack.org/pipermail/user-committee/2014-December.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2015-01-01 01:04:26'),('http://lists.openstack.org/pipermail/user-committee/2014-February.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:21'),('http://lists.openstack.org/pipermail/user-committee/2014-January.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:19'),('http://lists.openstack.org/pipermail/user-committee/2014-July.txt','http://lists.openstack.org/pipermail/user-committee','visited','2014-07-07 10:09:58'),('http://lists.openstack.org/pipermail/user-committee/2014-July.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-08-01 20:54:38'),('http://lists.openstack.org/pipermail/user-committee/2014-March.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-05-27 19:49:23'),('http://lists.openstack.org/pipermail/user-committee/2014-November.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-12-01 01:03:37'),('http://lists.openstack.org/pipermail/user-committee/2014-October.txt','http://lists.openstack.org/pipermail/user-committee','visited','2014-10-22 02:43:47'),('http://lists.openstack.org/pipermail/user-committee/2014-October.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-10-30 14:15:04'),('http://lists.openstack.org/pipermail/user-committee/2014-September.txt','http://lists.openstack.org/pipermail/user-committee','visited','2014-09-06 15:30:30'),('http://lists.openstack.org/pipermail/user-committee/2014-September.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2014-10-01 02:47:39'),('http://lists.openstack.org/pipermail/user-committee/2015-February.txt','http://lists.openstack.org/pipermail/user-committee','visited','2015-02-05 01:03:34'),('http://lists.openstack.org/pipermail/user-committee/2015-February.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2015-02-06 01:04:35'),('http://lists.openstack.org/pipermail/user-committee/2015-January.txt','http://lists.openstack.org/pipermail/user-committee','visited','2015-01-29 01:05:23'),('http://lists.openstack.org/pipermail/user-committee/2015-January.txt.gz','http://lists.openstack.org/pipermail/user-committee','visited','2015-02-01 01:03:49');
/*!40000 ALTER TABLE `compressed_files` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `mailing_lists`
--

DROP TABLE IF EXISTS `mailing_lists`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `mailing_lists` (
  `mailing_list_url` varchar(255) NOT NULL,
  `mailing_list_name` varchar(255) DEFAULT 'NULL',
  `project_name` varchar(255) DEFAULT 'NULL',
  `last_analysis` datetime DEFAULT NULL,
  PRIMARY KEY (`mailing_list_url`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `mailing_lists`
--

LOCK TABLES `mailing_lists` WRITE;
/*!40000 ALTER TABLE `mailing_lists` DISABLE KEYS */;
INSERT INTO `mailing_lists` VALUES ('http://lists.openstack.org/pipermail/community','community','NULL','2015-02-06 01:00:03'),('http://lists.openstack.org/pipermail/fits','fits','NULL','2015-02-06 01:00:17'),('http://lists.openstack.org/pipermail/foundation','foundation','NULL','2015-02-06 01:00:25'),('http://lists.openstack.org/pipermail/openstack','openstack','NULL','2015-02-06 01:04:39'),('http://lists.openstack.org/pipermail/openstack-announce','openstack-announce','NULL','2015-02-06 01:00:36'),('http://lists.openstack.org/pipermail/openstack-dev','openstack-dev','NULL','2015-02-06 01:01:15'),('http://lists.openstack.org/pipermail/openstack-docs','openstack-docs','NULL','2015-02-06 01:03:43'),('http://lists.openstack.org/pipermail/openstack-hpc','openstack-hpc','NULL','2015-02-06 01:03:53'),('http://lists.openstack.org/pipermail/openstack-infra','openstack-infra','NULL','2015-02-06 01:03:54'),('http://lists.openstack.org/pipermail/openstack-operators','openstack-operators','NULL','2015-02-06 01:03:57'),('http://lists.openstack.org/pipermail/openstack-qa','openstack-qa','NULL','2015-02-06 01:04:19'),('http://lists.openstack.org/pipermail/openstack-stable-maint','openstack-stable-maint','NULL','2015-02-06 01:04:21'),('http://lists.openstack.org/pipermail/openstack-tc','openstack-tc','NULL','2015-02-06 01:04:23'),('http://lists.openstack.org/pipermail/transparency','transparency','NULL','2015-02-06 01:04:27'),('http://lists.openstack.org/pipermail/user-committee','user-committee','NULL','2015-02-06 01:04:34');
/*!40000 ALTER TABLE `mailing_lists` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `mailing_lists_people`
--

DROP TABLE IF EXISTS `mailing_lists_people`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `mailing_lists_people` (
  `email_address` varchar(255) CHARACTER SET utf8 NOT NULL,
  `mailing_list_url` varchar(255) CHARACTER SET utf8 NOT NULL,
  PRIMARY KEY (`email_address`,`mailing_list_url`),
  KEY `mailing_list_url` (`mailing_list_url`),
  CONSTRAINT `mailing_lists_people_ibfk_1` FOREIGN KEY (`mailing_list_url`) REFERENCES `mailing_lists` (`mailing_list_url`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `mailing_lists_people_ibfk_2` FOREIGN KEY (`email_address`) REFERENCES `people` (`email_address`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `mailing_lists_people`
--

LOCK TABLES `mailing_lists_people` WRITE;
/*!40000 ALTER TABLE `mailing_lists_people` DISABLE KEYS */;
INSERT INTO `mailing_lists_people` VALUES ('A.Silvi@cbt.it','http://lists.openstack.org/pipermail/community'),('Academicgareth@gmail.com','http://lists.openstack.org/pipermail/community'),('acerkarthid@gmail.com','http://lists.openstack.org/pipermail/community'),('adam@varud.com','http://lists.openstack.org/pipermail/community'),('adrian_moti@yahoo.com','http://lists.openstack.org/pipermail/community'),('adromeda.troya@gmail.com','http://lists.openstack.org/pipermail/community'),('afreedland@mirantis.com','http://lists.openstack.org/pipermail/community'),('aj@suse.com','http://lists.openstack.org/pipermail/community'),('alawson@aqorn.com','http://lists.openstack.org/pipermail/community'),('alessandro@ams0.org','http://lists.openstack.org/pipermail/community'),('alexandrehaguiar@gmail.com','http://lists.openstack.org/pipermail/community'),('alexey@kaytaz.ru','http://lists.openstack.org/pipermail/community'),('alfonsodg@gmail.com','http://lists.openstack.org/pipermail/community'),('allison@openstack.org','http://lists.openstack.org/pipermail/community'),('al_kari@manceps.com','http://lists.openstack.org/pipermail/community'),('Andi_Abes@Dell.com','http://lists.openstack.org/pipermail/community'),('andrew.edmonds@zhaw.ch','http://lists.openstack.org/pipermail/community'),('anita.kuno@enovance.com','http://lists.openstack.org/pipermail/community'),('aparathyras@stackmasters.eu','http://lists.openstack.org/pipermail/community'),('arturo.era@gmail.com','http://lists.openstack.org/pipermail/community'),('Ashiq.Anjum@cern.ch','http://lists.openstack.org/pipermail/community'),('asmaa.ibrahim12@gmail.com','http://lists.openstack.org/pipermail/community'),('ata.husain@hotmail.com','http://lists.openstack.org/pipermail/community'),('Atul.Jha@csscorp.com','http://lists.openstack.org/pipermail/community'),('avner.algom@gmail.com','http://lists.openstack.org/pipermail/community'),('bevcorwin@gmail.com','http://lists.openstack.org/pipermail/community'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/community'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/community'),('brent.scotten@dreamhost.com','http://lists.openstack.org/pipermail/community'),('brucelok@cyberport.hk','http://lists.openstack.org/pipermail/community'),('bsjcloud@gmail.com','http://lists.openstack.org/pipermail/community'),('carol.l.barrett@intel.com','http://lists.openstack.org/pipermail/community'),('cchaconr@gmail.com','http://lists.openstack.org/pipermail/community'),('cesar@teltecnetworks.com.br','http://lists.openstack.org/pipermail/community'),('chmouel@enovance.com','http://lists.openstack.org/pipermail/community'),('chris.williams@alliance-it.com','http://lists.openstack.org/pipermail/community'),('chrisfer@us.ibm.com','http://lists.openstack.org/pipermail/community'),('christophe.sauthier@objectif-libre.com','http://lists.openstack.org/pipermail/community'),('citctacloud@gmail.com','http://lists.openstack.org/pipermail/community'),('claire@openstack.org','http://lists.openstack.org/pipermail/community'),('Colin.McNamara@NexusIS.com','http://lists.openstack.org/pipermail/community'),('colin@2cups.com','http://lists.openstack.org/pipermail/community'),('dana.bauer@RACKSPACE.COM','http://lists.openstack.org/pipermail/community'),('danielnuneze@gmail.com','http://lists.openstack.org/pipermail/community'),('danilo.ingami@gmail.com','http://lists.openstack.org/pipermail/community'),('dave.walker@canonical.com','http://lists.openstack.org/pipermail/community'),('david@zeromail.us','http://lists.openstack.org/pipermail/community'),('dce3062@gmail.com','http://lists.openstack.org/pipermail/community'),('deepakgarg.iitg@gmail.com','http://lists.openstack.org/pipermail/community'),('dgmbr15@rediffmail.com','http://lists.openstack.org/pipermail/community'),('dheerendra.madhusudhana@gmail.com','http://lists.openstack.org/pipermail/community'),('diego.woitasen@vhgroup.net','http://lists.openstack.org/pipermail/community'),('diego@flugel.it','http://lists.openstack.org/pipermail/community'),('diego@woitasen.com.ar','http://lists.openstack.org/pipermail/community'),('dizquierdo@bitergia.com','http://lists.openstack.org/pipermail/community'),('dmc@dungeoninnovations.com','http://lists.openstack.org/pipermail/community'),('dneary@redhat.com','http://lists.openstack.org/pipermail/community'),('dongjh@nci.com.cn','http://lists.openstack.org/pipermail/community'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/community'),('duran@andresduran.es','http://lists.openstack.org/pipermail/community'),('duyujie.dyj@gmail.com','http://lists.openstack.org/pipermail/community'),('E.Kessels@fairbanks.nl','http://lists.openstack.org/pipermail/community'),('Earle_Kirkland@symantec.com','http://lists.openstack.org/pipermail/community'),('ejmarten@gmail.com','http://lists.openstack.org/pipermail/community'),('emujicad@gmail.com','http://lists.openstack.org/pipermail/community'),('erhan.ekici@gmail.com','http://lists.openstack.org/pipermail/community'),('erwan@erwan.com','http://lists.openstack.org/pipermail/community'),('everett.toews@RACKSPACE.COM','http://lists.openstack.org/pipermail/community'),('fajwilson@gmail.com','http://lists.openstack.org/pipermail/community'),('fifieldt@unimelb.edu.au','http://lists.openstack.org/pipermail/community'),('frans@meruvian.org','http://lists.openstack.org/pipermail/community'),('fred_witteman@nl.ibm.com','http://lists.openstack.org/pipermail/community'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/community'),('gareth@unitedstack.com','http://lists.openstack.org/pipermail/community'),('gfidente@fedoraproject.org','http://lists.openstack.org/pipermail/community'),('girijasharansingh@gmail.com','http://lists.openstack.org/pipermail/community'),('gokoproject@gmail.com','http://lists.openstack.org/pipermail/community'),('guoyingc@cn.ibm.com','http://lists.openstack.org/pipermail/community'),('hang.tran@dtt.vn','http://lists.openstack.org/pipermail/community'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/community'),('hasegawa@bit-isle.co.jp','http://lists.openstack.org/pipermail/community'),('hisayuki.takeda@oceanearth-corp.com','http://lists.openstack.org/pipermail/community'),('humberto.parra@gmail.com','http://lists.openstack.org/pipermail/community'),('ianyrchoi@gmail.com','http://lists.openstack.org/pipermail/community'),('Ilkka.Tengvall@cybercom.com','http://lists.openstack.org/pipermail/community'),('ilyaalekseyev@acm.org','http://lists.openstack.org/pipermail/community'),('Ina.Dobrilova@telerik.com','http://lists.openstack.org/pipermail/community'),('itoumsn@nttdata.co.jp','http://lists.openstack.org/pipermail/community'),('jana@sysnetinfocom.com','http://lists.openstack.org/pipermail/community'),('jasper@aikema.nl','http://lists.openstack.org/pipermail/community'),('jcoufal@redhat.com','http://lists.openstack.org/pipermail/community'),('Jean_Marie_Martini@Dell.com','http://lists.openstack.org/pipermail/community'),('jgotangco@gmail.com','http://lists.openstack.org/pipermail/community'),('jlennox@redhat.com','http://lists.openstack.org/pipermail/community'),('jogo@hp.com','http://lists.openstack.org/pipermail/community'),('jolyon@limilo.com','http://lists.openstack.org/pipermail/community'),('jonathan.lelous@gmail.com','http://lists.openstack.org/pipermail/community'),('joshua.hesketh@rackspace.com','http://lists.openstack.org/pipermail/community'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/community'),('juanfra.rodriguez.cardoso@gmail.com','http://lists.openstack.org/pipermail/community'),('juliocarlos.barrera@i2cat.net','http://lists.openstack.org/pipermail/community'),('k4ncerbero@gmail.com','http://lists.openstack.org/pipermail/community'),('kamelia.benchekroun@gmail.com','http://lists.openstack.org/pipermail/community'),('Kamesh_Pemmaraju@Dell.com','http://lists.openstack.org/pipermail/community'),('kathyc@openstack.org','http://lists.openstack.org/pipermail/community'),('kavit@aptira.com','http://lists.openstack.org/pipermail/community'),('ken.hui@RACKSPACE.COM','http://lists.openstack.org/pipermail/community'),('kenhuinyc@gmail.com','http://lists.openstack.org/pipermail/community'),('khan.imran2591@gmail.com','http://lists.openstack.org/pipermail/community'),('khayam.gondal@gmail.com','http://lists.openstack.org/pipermail/community'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/community'),('koolhead17@gmail.com','http://lists.openstack.org/pipermail/community'),('krook@us.ibm.com','http://lists.openstack.org/pipermail/community'),('krzysiekg18@gmail.com','http://lists.openstack.org/pipermail/community'),('laura.adq@gmail.com','http://lists.openstack.org/pipermail/community'),('lauren@openstack.org','http://lists.openstack.org/pipermail/community'),('lennard@cloudvps.com','http://lists.openstack.org/pipermail/community'),('lloydostack@gmail.com','http://lists.openstack.org/pipermail/community'),('lyz@princessleia.com','http://lists.openstack.org/pipermail/community'),('m.hauville@buildpartner.net','http://lists.openstack.org/pipermail/community'),('mail2akhtar@gmail.com','http://lists.openstack.org/pipermail/community'),('mail@cberendt.net','http://lists.openstack.org/pipermail/community'),('marcelodieder@gmail.com','http://lists.openstack.org/pipermail/community'),('marian.tort@gmail.com','http://lists.openstack.org/pipermail/community'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/community'),('mark@openstack.org','http://lists.openstack.org/pipermail/community'),('markashtonb@gmail.com','http://lists.openstack.org/pipermail/community'),('marko.sluga@chs.si','http://lists.openstack.org/pipermail/community'),('marton.kiss@gmail.com','http://lists.openstack.org/pipermail/community'),('masanori.itoh@gmail.com','http://lists.openstack.org/pipermail/community'),('matt@mattfischer.com','http://lists.openstack.org/pipermail/community'),('me@mark.atwood.name','http://lists.openstack.org/pipermail/community'),('me@not.mn','http://lists.openstack.org/pipermail/community'),('meandopenstack@gmail.com','http://lists.openstack.org/pipermail/community'),('mhr.james@gmail.com','http://lists.openstack.org/pipermail/community'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/community'),('mistria@redhat.com','http://lists.openstack.org/pipermail/community'),('miumiento@gmail.com','http://lists.openstack.org/pipermail/community'),('mobiwen@gmail.com','http://lists.openstack.org/pipermail/community'),('moe.elbaz@gmail.com','http://lists.openstack.org/pipermail/community'),('moizarif2002@hotmail.com','http://lists.openstack.org/pipermail/community'),('muharem@lbox.cc','http://lists.openstack.org/pipermail/community'),('n.paladi@gmail.com','http://lists.openstack.org/pipermail/community'),('ndquockhanh@gmail.com','http://lists.openstack.org/pipermail/community'),('nicolaslino1@gmail.com','http://lists.openstack.org/pipermail/community'),('openstack@detacloud.com','http://lists.openstack.org/pipermail/community'),('openstack@medberry.net','http://lists.openstack.org/pipermail/community'),('pantoni@us.ibm.com','http://lists.openstack.org/pipermail/community'),('para.vikas@gmail.com','http://lists.openstack.org/pipermail/community'),('patrick.petit@bull.net','http://lists.openstack.org/pipermail/community'),('pednape@gmail.com','http://lists.openstack.org/pipermail/community'),('pieter.c.kruithof-jr@hp.com','http://lists.openstack.org/pipermail/community'),('plancast@redhat.com','http://lists.openstack.org/pipermail/community'),('ppetit@mirantis.com','http://lists.openstack.org/pipermail/community'),('premedge@gmail.com','http://lists.openstack.org/pipermail/community'),('pskarthikps13@gmail.com','http://lists.openstack.org/pipermail/community'),('Qing.He@radisys.com','http://lists.openstack.org/pipermail/community'),('qingye.jiang@eucalyptus.com','http://lists.openstack.org/pipermail/community'),('qjiang@ieee.org','http://lists.openstack.org/pipermail/community'),('r.malujda@gmail.com','http://lists.openstack.org/pipermail/community'),('rafael.knuth@gmail.com','http://lists.openstack.org/pipermail/community'),('raheel_com88@yahoo.com','http://lists.openstack.org/pipermail/community'),('rbowen@redhat.com','http://lists.openstack.org/pipermail/community'),('rick.bauer@opennetworking.org','http://lists.openstack.org/pipermail/community'),('riteshnanda09@gmail.com','http://lists.openstack.org/pipermail/community'),('rossella@midokura.com','http://lists.openstack.org/pipermail/community'),('s.chraigui@gmail.com','http://lists.openstack.org/pipermail/community'),('sammiestoel@gmail.com','http://lists.openstack.org/pipermail/community'),('samuel.hassine@anotherservice.com','http://lists.openstack.org/pipermail/community'),('sankarshan.mukhopadhyay@gmail.com','http://lists.openstack.org/pipermail/community'),('sbunatyan@mirantis.com','http://lists.openstack.org/pipermail/community'),('sc360@kent.ac.uk','http://lists.openstack.org/pipermail/community'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/community'),('seanroberts66@gmail.com','http://lists.openstack.org/pipermail/community'),('Sean_Collins2@cable.comcast.com','http://lists.openstack.org/pipermail/community'),('serverascode@gmail.com','http://lists.openstack.org/pipermail/community'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/community'),('shari@openstack.org','http://lists.openstack.org/pipermail/community'),('shouhengzhang.xu@mail.utoronto.ca','http://lists.openstack.org/pipermail/community'),('sim.ple@live.nl','http://lists.openstack.org/pipermail/community'),('stackerandrew@gmail.com','http://lists.openstack.org/pipermail/community'),('stackeratul@gmail.com','http://lists.openstack.org/pipermail/community'),('stefano@openstack.org','http://lists.openstack.org/pipermail/community'),('stephen.halpin@hp.com','http://lists.openstack.org/pipermail/community'),('stephen.spector@hp.com','http://lists.openstack.org/pipermail/community'),('steve.loving@metacloud.com','http://lists.openstack.org/pipermail/community'),('stuartl@vrt.com.au','http://lists.openstack.org/pipermail/community'),('sudarshan.pathak@nepallink.net','http://lists.openstack.org/pipermail/community'),('surit.killer@gmail.com','http://lists.openstack.org/pipermail/community'),('swhajjaji@gmail.com','http://lists.openstack.org/pipermail/community'),('syed.armani@hastexo.com','http://lists.openstack.org/pipermail/community'),('sylvain.bauza@digimind.com','http://lists.openstack.org/pipermail/community'),('theracer007@gmail.com','http://lists.openstack.org/pipermail/community'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/community'),('tim.horgan@cit.ie','http://lists.openstack.org/pipermail/community'),('tmartin@codero.com','http://lists.openstack.org/pipermail/community'),('tom@openstack.org','http://lists.openstack.org/pipermail/community'),('trevor.lowing@gmail.com','http://lists.openstack.org/pipermail/community'),('tristan@aptira.com','http://lists.openstack.org/pipermail/community'),('trung@dtt.vn','http://lists.openstack.org/pipermail/community'),('valjohn1647@gmail.com','http://lists.openstack.org/pipermail/community'),('vblando@morphlabs.com','http://lists.openstack.org/pipermail/community'),('vietstack@gmail.com','http://lists.openstack.org/pipermail/community'),('vivek.visolve@gmail.com','http://lists.openstack.org/pipermail/community'),('wickedpuppy@gmail.com','http://lists.openstack.org/pipermail/community'),('yeluaiesec@gmail.com','http://lists.openstack.org/pipermail/community'),('yoyochiang55@gmail.com','http://lists.openstack.org/pipermail/community'),('Yuling_C@DELL.com','http://lists.openstack.org/pipermail/community'),('zzysgx@163.com','http://lists.openstack.org/pipermail/community'),('cdiep@us.ibm.com','http://lists.openstack.org/pipermail/fits'),('david@pistoncloud.com','http://lists.openstack.org/pipermail/fits'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/fits'),('dlenwell@gmail.com','http://lists.openstack.org/pipermail/fits'),('forrest@pistoncloud.com','http://lists.openstack.org/pipermail/fits'),('josh@pistoncloud.com','http://lists.openstack.org/pipermail/fits'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/fits'),('kristen.eisenberg@yahoo.com','http://lists.openstack.org/pipermail/fits'),('matt@nycresistor.com','http://lists.openstack.org/pipermail/fits'),('randyb@cloudscaling.com','http://lists.openstack.org/pipermail/fits'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/fits'),('rochelle.grober@huawei.com','http://lists.openstack.org/pipermail/fits'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/fits'),('zdyu2000@gmail.com','http://lists.openstack.org/pipermail/fits'),('aclark@suse.com','http://lists.openstack.org/pipermail/foundation'),('acs@parvuscaptus.com','http://lists.openstack.org/pipermail/foundation'),('aj@suse.com','http://lists.openstack.org/pipermail/foundation'),('aking@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('alan.kavanagh@ericsson.com','http://lists.openstack.org/pipermail/foundation'),('alevine@cloudscaling.com','http://lists.openstack.org/pipermail/foundation'),('ambuj.jain@netenrich.com','http://lists.openstack.org/pipermail/foundation'),('anne@openstack.org','http://lists.openstack.org/pipermail/foundation'),('anotherjesse@gmail.com','http://lists.openstack.org/pipermail/foundation'),('Atul.Jha@csscorp.com','http://lists.openstack.org/pipermail/foundation'),('b@b3k.us','http://lists.openstack.org/pipermail/foundation'),('b@renski.com','http://lists.openstack.org/pipermail/foundation'),('ben@bencherian.com','http://lists.openstack.org/pipermail/foundation'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/foundation'),('berrange@redhat.com','http://lists.openstack.org/pipermail/foundation'),('bhardwaj.rahul20@gmail.com','http://lists.openstack.org/pipermail/foundation'),('blake.yeager@gmail.com','http://lists.openstack.org/pipermail/foundation'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/foundation'),('bobby@basho.com','http://lists.openstack.org/pipermail/foundation'),('bogus@does.not.exist.com','http://lists.openstack.org/pipermail/foundation'),('bpavlovic@mirantis.com','http://lists.openstack.org/pipermail/foundation'),('brenski@mirantis.com','http://lists.openstack.org/pipermail/foundation'),('bret.piatt@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('bstevens@redhat.com','http://lists.openstack.org/pipermail/foundation'),('carol.l.barrett@intel.com','http://lists.openstack.org/pipermail/foundation'),('cctrieloff@redhat.com','http://lists.openstack.org/pipermail/foundation'),('chmouel@chmouel.com','http://lists.openstack.org/pipermail/foundation'),('chris.c.kemp@nebula.com','http://lists.openstack.org/pipermail/foundation'),('chrisfer@us.ibm.com','http://lists.openstack.org/pipermail/foundation'),('claire@openstack.org','http://lists.openstack.org/pipermail/foundation'),('Cole.Crawford@nebula.com','http://lists.openstack.org/pipermail/foundation'),('colin@2cups.com','http://lists.openstack.org/pipermail/foundation'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/foundation'),('dallas@dreamhost.com','http://lists.openstack.org/pipermail/foundation'),('dan@nicira.com','http://lists.openstack.org/pipermail/foundation'),('davanum@gmail.com','http://lists.openstack.org/pipermail/foundation'),('dave@neary-consulting.com','http://lists.openstack.org/pipermail/foundation'),('dboyzhong@163.com','http://lists.openstack.org/pipermail/foundation'),('deepakgarg.iitg@gmail.com','http://lists.openstack.org/pipermail/foundation'),('devin.carlen@gmail.com','http://lists.openstack.org/pipermail/foundation'),('diego.parrilla@stackops.com','http://lists.openstack.org/pipermail/foundation'),('dneary@gnome.org','http://lists.openstack.org/pipermail/foundation'),('dneary@redhat.com','http://lists.openstack.org/pipermail/foundation'),('dnielsen@gmail.com','http://lists.openstack.org/pipermail/foundation'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/foundation'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/foundation'),('dtroyer@gmail.com','http://lists.openstack.org/pipermail/foundation'),('dug@us.ibm.com','http://lists.openstack.org/pipermail/foundation'),('duncan@dreamhost.com','http://lists.openstack.org/pipermail/foundation'),('duncan@mindpool.io','http://lists.openstack.org/pipermail/foundation'),('duyujie.dyj@gmail.com','http://lists.openstack.org/pipermail/foundation'),('dwendlandt@vmware.com','http://lists.openstack.org/pipermail/foundation'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/foundation'),('eileen.evans@hp.com','http://lists.openstack.org/pipermail/foundation'),('eric@windisch.us','http://lists.openstack.org/pipermail/foundation'),('Ewan.Mellor@eu.citrix.com','http://lists.openstack.org/pipermail/foundation'),('fifieldt@unimelb.edu.au','http://lists.openstack.org/pipermail/foundation'),('franklynp@gladinet.com','http://lists.openstack.org/pipermail/foundation'),('frans@meruvian.org','http://lists.openstack.org/pipermail/foundation'),('freedomhui@gmail.com','http://lists.openstack.org/pipermail/foundation'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/foundation'),('Gabriel.Hurley@nebula.com','http://lists.openstack.org/pipermail/foundation'),('gaire.kabir@gmail.com','http://lists.openstack.org/pipermail/foundation'),('george.reese@imaginary.com','http://lists.openstack.org/pipermail/foundation'),('gokoproject@gmail.com','http://lists.openstack.org/pipermail/foundation'),('gyehuda@yahoo-inc.com','http://lists.openstack.org/pipermail/foundation'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/foundation'),('jan_drake@hotmail.com','http://lists.openstack.org/pipermail/foundation'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/foundation'),('jbryce@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('jcicman@us.ibm.com','http://lists.openstack.org/pipermail/foundation'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/foundation'),('jim.curry@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('jimjag@gmail.com','http://lists.openstack.org/pipermail/foundation'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/foundation'),('Joe.Heck@nebula.com','http://lists.openstack.org/pipermail/foundation'),('johnmark@redhat.com','http://lists.openstack.org/pipermail/foundation'),('John_Igoe@Dell.com','http://lists.openstack.org/pipermail/foundation'),('jonathan@openstack.org','http://lists.openstack.org/pipermail/foundation'),('joonwon7.lee@samsung.com','http://lists.openstack.org/pipermail/foundation'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/foundation'),('jproudman@bluebox.net','http://lists.openstack.org/pipermail/foundation'),('justin@fathomdb.com','http://lists.openstack.org/pipermail/foundation'),('kavit@aptira.com','http://lists.openstack.org/pipermail/foundation'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/foundation'),('Kurt.Garloff@telekom.de','http://lists.openstack.org/pipermail/foundation'),('kyle.macdonald@canonical.com','http://lists.openstack.org/pipermail/foundation'),('kyle.macdonald@gmail.com','http://lists.openstack.org/pipermail/foundation'),('lauren@openstack.org','http://lists.openstack.org/pipermail/foundation'),('letucker@cisco.com','http://lists.openstack.org/pipermail/foundation'),('lisa@lsmillerlaw.com','http://lists.openstack.org/pipermail/foundation'),('lloyd@pistoncloud.com','http://lists.openstack.org/pipermail/foundation'),('lloydostack@gmail.com','http://lists.openstack.org/pipermail/foundation'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/foundation'),('mark.collier@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('Mark.Radcliffe@dlapiper.com','http://lists.openstack.org/pipermail/foundation'),('mark.washenberger@markwash.net','http://lists.openstack.org/pipermail/foundation'),('mark@openstack.org','http://lists.openstack.org/pipermail/foundation'),('markmc@redhat.com','http://lists.openstack.org/pipermail/foundation'),('matt@nycresistor.com','http://lists.openstack.org/pipermail/foundation'),('me@bjm.cc','http://lists.openstack.org/pipermail/foundation'),('me@campbellmcneill.com','http://lists.openstack.org/pipermail/foundation'),('me@not.mn','http://lists.openstack.org/pipermail/foundation'),('melahn@us.ibm.com','http://lists.openstack.org/pipermail/foundation'),('messenger@webex.com','http://lists.openstack.org/pipermail/foundation'),('michael.still@canonical.com','http://lists.openstack.org/pipermail/foundation'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/foundation'),('mikeyp@lhrc.com','http://lists.openstack.org/pipermail/foundation'),('moe.elbaz@gmail.com','http://lists.openstack.org/pipermail/foundation'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/foundation'),('narayan.desai@gmail.com','http://lists.openstack.org/pipermail/foundation'),('nick@enovance.com','http://lists.openstack.org/pipermail/foundation'),('nicolas@barcet.com','http://lists.openstack.org/pipermail/foundation'),('otaku@gface.com','http://lists.openstack.org/pipermail/foundation'),('pat.pushor@cloudchronicle.com','http://lists.openstack.org/pipermail/foundation'),('Raja.Srinivasan@riverbed.com','http://lists.openstack.org/pipermail/foundation'),('Randy.Bias@emc.com','http://lists.openstack.org/pipermail/foundation'),('randyb@cloudscaling.com','http://lists.openstack.org/pipermail/foundation'),('razique.mahroua@gmail.com','http://lists.openstack.org/pipermail/foundation'),('rbergero@redhat.com','http://lists.openstack.org/pipermail/foundation'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/foundation'),('rfontana@redhat.com','http://lists.openstack.org/pipermail/foundation'),('richih.mailinglist@gmail.com','http://lists.openstack.org/pipermail/foundation'),('rick@openstack.org','http://lists.openstack.org/pipermail/foundation'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/foundation'),('robbie@ubuntu.com','http://lists.openstack.org/pipermail/foundation'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/foundation'),('sandy.walsh@RACKSPACE.COM','http://lists.openstack.org/pipermail/foundation'),('santiagoc120@outlook.com','http://lists.openstack.org/pipermail/foundation'),('sayali.92720@gmail.com','http://lists.openstack.org/pipermail/foundation'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/foundation'),('sean@dague.net','http://lists.openstack.org/pipermail/foundation'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/foundation'),('shamun.mahmud@dlt.com','http://lists.openstack.org/pipermail/foundation'),('simon@dreamhost.com','http://lists.openstack.org/pipermail/foundation'),('snoble@sonn.com','http://lists.openstack.org/pipermail/foundation'),('soosiechoi@gmail.com','http://lists.openstack.org/pipermail/foundation'),('soren@linux2go.dk','http://lists.openstack.org/pipermail/foundation'),('stefano@openstack.org','http://lists.openstack.org/pipermail/foundation'),('Stephen_Spector@Dell.com','http://lists.openstack.org/pipermail/foundation'),('thierry@openstack.org','http://lists.openstack.org/pipermail/foundation'),('thor@wolpert.ca','http://lists.openstack.org/pipermail/foundation'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/foundation'),('tim.horgan@cit.ie','http://lists.openstack.org/pipermail/foundation'),('tmmoore@us.ibm.com','http://lists.openstack.org/pipermail/foundation'),('todd.deshane@xen.org','http://lists.openstack.org/pipermail/foundation'),('todd@ansolabs.com','http://lists.openstack.org/pipermail/foundation'),('tom@openstack.org','http://lists.openstack.org/pipermail/foundation'),('trey.morris@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('tristan@aptira.com','http://lists.openstack.org/pipermail/foundation'),('troy.toman@rackspace.com','http://lists.openstack.org/pipermail/foundation'),('troy@tomanator.com','http://lists.openstack.org/pipermail/foundation'),('van.lindberg@gmail.com','http://lists.openstack.org/pipermail/foundation'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/foundation'),('vuntz@suse.com','http://lists.openstack.org/pipermail/foundation'),('wdamarillo@morphlabs.com','http://lists.openstack.org/pipermail/foundation'),('xuchenx@gmail.com','http://lists.openstack.org/pipermail/foundation'),('yoyochiang@itri.org.tw','http://lists.openstack.org/pipermail/foundation'),('zhhuabj@cn.ibm.com','http://lists.openstack.org/pipermail/foundation'),('zx@twitter.com','http://lists.openstack.org/pipermail/foundation'),('11msccssbashir@seecs.edu.pk','http://lists.openstack.org/pipermail/openstack'),('15510333529@163.com','http://lists.openstack.org/pipermail/openstack'),('314631691@qq.com','http://lists.openstack.org/pipermail/openstack'),('386488135@qq.com','http://lists.openstack.org/pipermail/openstack'),('54linhao@gmail.com','http://lists.openstack.org/pipermail/openstack'),('77.chathura@gmail.com','http://lists.openstack.org/pipermail/openstack'),('779738023@qq.com','http://lists.openstack.org/pipermail/openstack'),('905ben@gmail.com','http://lists.openstack.org/pipermail/openstack'),('954102969@qq.com','http://lists.openstack.org/pipermail/openstack'),('a.koppad@gmail.com','http://lists.openstack.org/pipermail/openstack'),('A.Roy@F5.com','http://lists.openstack.org/pipermail/openstack'),('aababilov@griddynamics.com','http://lists.openstack.org/pipermail/openstack'),('aaggarwal@servosity.com','http://lists.openstack.org/pipermail/openstack'),('aanand@viimed.com','http://lists.openstack.org/pipermail/openstack'),('aaron.knister@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aaron.segura@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aashish24@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aayush.asawa@students.iiit.ac.in','http://lists.openstack.org/pipermail/openstack'),('abarabesi@enter.it','http://lists.openstack.org/pipermail/openstack'),('abbass.marouni@virtualscale.fr','http://lists.openstack.org/pipermail/openstack'),('abhijeet.1989@gmail.com','http://lists.openstack.org/pipermail/openstack'),('abogott@wikimedia.org','http://lists.openstack.org/pipermail/openstack'),('abonilla@linuxwireless.org','http://lists.openstack.org/pipermail/openstack'),('academicgareth@gmail.com','http://lists.openstack.org/pipermail/openstack'),('adamg@canonical.com','http://lists.openstack.org/pipermail/openstack'),('adamg@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('admin@grails.asia','http://lists.openstack.org/pipermail/openstack'),('adrian.smith@workday.com','http://lists.openstack.org/pipermail/openstack'),('adrian@17od.com','http://lists.openstack.org/pipermail/openstack'),('adrian@bashlines.com','http://lists.openstack.org/pipermail/openstack'),('adrien@adriencunin.fr','http://lists.openstack.org/pipermail/openstack'),('afe.young@gmail.com','http://lists.openstack.org/pipermail/openstack'),('afef.mdhaffar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Ageeleshwar.Kandavelu@csscorp.com','http://lists.openstack.org/pipermail/openstack'),('agregc@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ahmad.benmaallem@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack'),('aji.zqfan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('akalambu@cisco.com','http://lists.openstack.org/pipermail/openstack'),('akgunjal@in.ibm.com','http://lists.openstack.org/pipermail/openstack'),('akilesh1597@gmail.com','http://lists.openstack.org/pipermail/openstack'),('akshatknsl@gmail.com','http://lists.openstack.org/pipermail/openstack'),('akshya11235@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alan.kavanagh@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('alatynskaya@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('alawson@aqorn.com','http://lists.openstack.org/pipermail/openstack'),('alazarev@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('alb.molina@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alejandro.comisario@mercadolibre.com','http://lists.openstack.org/pipermail/openstack'),('alessandro@ams0.org','http://lists.openstack.org/pipermail/openstack'),('alex.dodson@aarnet.edu.au','http://lists.openstack.org/pipermail/openstack'),('alex.meade@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('alex890714@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alex@yrriba.com','http://lists.openstack.org/pipermail/openstack'),('alexandre7.decarvalho@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alexis@rabbitmq.com','http://lists.openstack.org/pipermail/openstack'),('alexsibeth@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alfredo.deluca@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alinazemian@gmail.com','http://lists.openstack.org/pipermail/openstack'),('alisa.baum@percona.com','http://lists.openstack.org/pipermail/openstack'),('allauddin.mohammed@hp.com','http://lists.openstack.org/pipermail/openstack'),('alleinerwolf@gmail.com','http://lists.openstack.org/pipermail/openstack'),('almuessig@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aloksingh@axway.com','http://lists.openstack.org/pipermail/openstack'),('ALONMA@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('alvin@netvel.net','http://lists.openstack.org/pipermail/openstack'),('Ambadas_Adam01@infosys.com','http://lists.openstack.org/pipermail/openstack'),('amcreynolds@ebay.com','http://lists.openstack.org/pipermail/openstack'),('ameetgandhare@gmail.com','http://lists.openstack.org/pipermail/openstack'),('amir.sadoughi@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('amit.das@cloudbyte.com','http://lists.openstack.org/pipermail/openstack'),('amit.gupta@ask.com','http://lists.openstack.org/pipermail/openstack'),('amitpp23@gmail.com','http://lists.openstack.org/pipermail/openstack'),('amoghpatel4u@gmail.com','http://lists.openstack.org/pipermail/openstack'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack'),('amps@djlab.com','http://lists.openstack.org/pipermail/openstack'),('amrith@tesora.com','http://lists.openstack.org/pipermail/openstack'),('anandts124@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Anatoly.Oreshkin@pnpi.spb.ru','http://lists.openstack.org/pipermail/openstack'),('andar_0@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('Andre.Charbonneau@SSC-SPC.gc.ca','http://lists.openstack.org/pipermail/openstack'),('andre.f.aranha@gmail.com','http://lists.openstack.org/pipermail/openstack'),('andre@drenet.net','http://lists.openstack.org/pipermail/openstack'),('andrea.rosa@hp.com','http://lists.openstack.org/pipermail/openstack'),('Andreas.Scheuring@de.ibm.com','http://lists.openstack.org/pipermail/openstack'),('andreas.voellmy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Andrew.Kerr@netapp.com','http://lists.openstack.org/pipermail/openstack'),('andrew.laski@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('andrew.plunk@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('andrew.richards@keepertech.com','http://lists.openstack.org/pipermail/openstack'),('andrew@andrewspiers.net','http://lists.openstack.org/pipermail/openstack'),('andrew@divvycloud.com','http://lists.openstack.org/pipermail/openstack'),('andrew@etc.gen.nz','http://lists.openstack.org/pipermail/openstack'),('andrew@rainsbrook.co.uk','http://lists.openstack.org/pipermail/openstack'),('andrewsben@gmail.com','http://lists.openstack.org/pipermail/openstack'),('andronat_asf@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('andy@wwwdata.eu','http://lists.openstack.org/pipermail/openstack'),('andymitrich@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ankit.deshwal2011@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Ankit11.Agrawal@nttdata.com','http://lists.openstack.org/pipermail/openstack'),('ankit29.a@tcs.com','http://lists.openstack.org/pipermail/openstack'),('ankushcentos@gmail.com','http://lists.openstack.org/pipermail/openstack'),('anne-claire.gerard@capgemini.com','http://lists.openstack.org/pipermail/openstack'),('anne.hill005@gmail.com','http://lists.openstack.org/pipermail/openstack'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack'),('annegentle@justwriteclick.com','http://lists.openstack.org/pipermail/openstack'),('anthony.michon@eurogiciel.fr','http://lists.openstack.org/pipermail/openstack'),('anton.massoud@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('antonio.s.messina@gmail.com','http://lists.openstack.org/pipermail/openstack'),('aparathyras@stackmasters.eu','http://lists.openstack.org/pipermail/openstack'),('aparna.cloud@gmail.com','http://lists.openstack.org/pipermail/openstack'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack'),('apilotti@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack'),('apiwat@klongprong.com','http://lists.openstack.org/pipermail/openstack'),('arahim.ozel@gmail.com','http://lists.openstack.org/pipermail/openstack'),('archana.nitraipur@gmail.com','http://lists.openstack.org/pipermail/openstack'),('arequipeno@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ari@jameskyle.org','http://lists.openstack.org/pipermail/openstack'),('arindam.bhattacharjee@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack'),('arindam@live.com','http://lists.openstack.org/pipermail/openstack'),('armamig@gmail.com','http://lists.openstack.org/pipermail/openstack'),('arosen@nicira.com','http://lists.openstack.org/pipermail/openstack'),('arumon82@gmail.com','http://lists.openstack.org/pipermail/openstack'),('arun.viswanath@gmail.com','http://lists.openstack.org/pipermail/openstack'),('arvind.tiwari@hp.com','http://lists.openstack.org/pipermail/openstack'),('arvinder.singh@aricent.com','http://lists.openstack.org/pipermail/openstack'),('aryeh.friedman@gmail.com','http://lists.openstack.org/pipermail/openstack'),('asalkeld@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('asalkeld@redhat.com','http://lists.openstack.org/pipermail/openstack'),('asharma@servosity.com','http://lists.openstack.org/pipermail/openstack'),('Ashiq.Anjum@cern.ch','http://lists.openstack.org/pipermail/openstack'),('Ashish.Billore1@in.ibm.com','http://lists.openstack.org/pipermail/openstack'),('ashish.jain14@wipro.com','http://lists.openstack.org/pipermail/openstack'),('ashjain2@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ashokkumaran.b@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ashraf.vazeer@hp.com','http://lists.openstack.org/pipermail/openstack'),('ashujain9727@gmail.com','http://lists.openstack.org/pipermail/openstack'),('asiriwork@gmail.com','http://lists.openstack.org/pipermail/openstack'),('asmaa.ibrahim12@gmail.com','http://lists.openstack.org/pipermail/openstack'),('atb@pravka.net','http://lists.openstack.org/pipermail/openstack'),('atkisc@gmail.com','http://lists.openstack.org/pipermail/openstack'),('augustsimonelli@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('avi3tal@gmail.com','http://lists.openstack.org/pipermail/openstack'),('AVIAD@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('AVISHAY@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('avishay@stratoscale.com','http://lists.openstack.org/pipermail/openstack'),('awasi@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('awasilyev@griddynamics.com','http://lists.openstack.org/pipermail/openstack'),('axel.christiansen@softreset.de','http://lists.openstack.org/pipermail/openstack'),('axel@hardreset.de','http://lists.openstack.org/pipermail/openstack'),('ayoung@redhat.com','http://lists.openstack.org/pipermail/openstack'),('ayurchuk@minuteware.net','http://lists.openstack.org/pipermail/openstack'),('azhagarasu@sanenthusiast.com','http://lists.openstack.org/pipermail/openstack'),('azher@hep.caltech.edu','http://lists.openstack.org/pipermail/openstack'),('azizalim@gmail.com','http://lists.openstack.org/pipermail/openstack'),('azpekt@gmail.com','http://lists.openstack.org/pipermail/openstack'),('b.akila@hp.com','http://lists.openstack.org/pipermail/openstack'),('B37207@freescale.com','http://lists.openstack.org/pipermail/openstack'),('B37208@freescale.com','http://lists.openstack.org/pipermail/openstack'),('B39208@freescale.com','http://lists.openstack.org/pipermail/openstack'),('B39209@freescale.com','http://lists.openstack.org/pipermail/openstack'),('B51469@freescale.com','http://lists.openstack.org/pipermail/openstack'),('bada.boum@outlook.com','http://lists.openstack.org/pipermail/openstack'),('bagelthesmart@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bageshree.lokare@hp.com','http://lists.openstack.org/pipermail/openstack'),('balamuruganvg@gmail.com','http://lists.openstack.org/pipermail/openstack'),('balazs.gibizer@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('balu9463@gmail.com','http://lists.openstack.org/pipermail/openstack'),('barnold@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('bartekzurawski1@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bastian.ballmann@inf.ethz.ch','http://lists.openstack.org/pipermail/openstack'),('batsayan.das@tcs.com','http://lists.openstack.org/pipermail/openstack'),('bbobrov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('bc@marlin.ie','http://lists.openstack.org/pipermail/openstack'),('bcline@softlayer.com','http://lists.openstack.org/pipermail/openstack'),('bdpayne@acm.org','http://lists.openstack.org/pipermail/openstack'),('bedis9@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Ben.Swartzlander@netapp.com','http://lists.openstack.org/pipermail/openstack'),('ben.tomasini@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ben42ml@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ben@benmccann.com','http://lists.openstack.org/pipermail/openstack'),('ben@firshman.co.uk','http://lists.openstack.org/pipermail/openstack'),('benali@gmail.com','http://lists.openstack.org/pipermail/openstack'),('benedikt.trefzer@cirrax.com','http://lists.openstack.org/pipermail/openstack'),('benjamin.ernst.lipp@cern.ch','http://lists.openstack.org/pipermail/openstack'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/openstack'),('berrange@redhat.com','http://lists.openstack.org/pipermail/openstack'),('bertrand.lallau@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bestofnithish@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bevcorwin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('beyounn@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bhaskar.rao@citrix.com','http://lists.openstack.org/pipermail/openstack'),('bhatt246@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('bhuvan@apache.org','http://lists.openstack.org/pipermail/openstack'),('billowen@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('bknowles@momentumsi.com','http://lists.openstack.org/pipermail/openstack'),('blacker1981@163.com','http://lists.openstack.org/pipermail/openstack'),('blair.bethwaite@gmail.com','http://lists.openstack.org/pipermail/openstack'),('blair@orcaware.com','http://lists.openstack.org/pipermail/openstack'),('blak111@gmail.com','http://lists.openstack.org/pipermail/openstack'),('blint@balabit.hu','http://lists.openstack.org/pipermail/openstack'),('blk@acm.org','http://lists.openstack.org/pipermail/openstack'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bma@eurotux.com','http://lists.openstack.org/pipermail/openstack'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/openstack'),('bob@drzyzgula.org','http://lists.openstack.org/pipermail/openstack'),('boden@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('boopathy_k@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('boris.moltchanov@telecomitalia.it','http://lists.openstack.org/pipermail/openstack'),('botemout@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bpradipt@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('Brad_Pokorny@symantec.com','http://lists.openstack.org/pipermail/openstack'),('brandon.adams@newwave-technologies.com','http://lists.openstack.org/pipermail/openstack'),('brandor5@gmail.com','http://lists.openstack.org/pipermail/openstack'),('brantcarrey@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('brenden.conte@witricity.com','http://lists.openstack.org/pipermail/openstack'),('brenski@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('brenttroge2016@gmail.com','http://lists.openstack.org/pipermail/openstack'),('brett.kugler@gdt.com','http://lists.openstack.org/pipermail/openstack'),('breu@breu.org','http://lists.openstack.org/pipermail/openstack'),('brian.haley@hp.com','http://lists.openstack.org/pipermail/openstack'),('brian.lamar@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('brian.schott@nimbisservices.com','http://lists.openstack.org/pipermail/openstack'),('brian@tangent.org','http://lists.openstack.org/pipermail/openstack'),('Brian_Chong@symantec.com','http://lists.openstack.org/pipermail/openstack'),('browne@vmware.com','http://lists.openstack.org/pipermail/openstack'),('brucelok@cyberport.hk','http://lists.openstack.org/pipermail/openstack'),('bruno.graziol@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bruno.semperlotti@gmail.com','http://lists.openstack.org/pipermail/openstack'),('bryan.stenson@moz.com','http://lists.openstack.org/pipermail/openstack'),('bsolie@well.com','http://lists.openstack.org/pipermail/openstack'),('bsreekanth@gmail.com','http://lists.openstack.org/pipermail/openstack'),('btopol@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('buccella@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('buzz42j@gmail.com','http://lists.openstack.org/pipermail/openstack'),('byron.briggs@ait.com','http://lists.openstack.org/pipermail/openstack'),('byron.mccollum@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('c237537@gmail.com','http://lists.openstack.org/pipermail/openstack'),('c35sys@gmail.com','http://lists.openstack.org/pipermail/openstack'),('caifti@gmail.com','http://lists.openstack.org/pipermail/openstack'),('caitlin.bestler@nexenta.com','http://lists.openstack.org/pipermail/openstack'),('caleb@calebgroom.com','http://lists.openstack.org/pipermail/openstack'),('calvin.walton@kepstin.ca','http://lists.openstack.org/pipermail/openstack'),('caustin@bitglass.com','http://lists.openstack.org/pipermail/openstack'),('cazzaniga.sandro@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cbalvarez@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cbehrens@codestud.com','http://lists.openstack.org/pipermail/openstack'),('cbf123@mail.usask.ca','http://lists.openstack.org/pipermail/openstack'),('cbkyeoh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cboylan@sapwetik.org','http://lists.openstack.org/pipermail/openstack'),('ceccarel@fnal.gov','http://lists.openstack.org/pipermail/openstack'),('cedric@yipikai.org','http://lists.openstack.org/pipermail/openstack'),('celttechie@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chabani.mohamed.hadi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chakrabak@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chalanipamo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chamberk@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('chandankumar.093047@gmail.com','http://lists.openstack.org/pipermail/openstack'),('changbin.liu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('changyaoh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chayma87@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chechu.linux@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chen.li@intel.com','http://lists.openstack.org/pipermail/openstack'),('chenhaiq@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('chenrui.momo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Cherif.Mballo@gemalto.com','http://lists.openstack.org/pipermail/openstack'),('chetan.bali@aricent.com','http://lists.openstack.org/pipermail/openstack'),('chgrivas7@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chinasubbareddy_m@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('chinasubbareddy_m@persistent.com','http://lists.openstack.org/pipermail/openstack'),('chloema@juniper.net','http://lists.openstack.org/pipermail/openstack'),('chmouel@enovance.com','http://lists.openstack.org/pipermail/openstack'),('chricker@cisco.com','http://lists.openstack.org/pipermail/openstack'),('chris.buccella@antallagon.com','http://lists.openstack.org/pipermail/openstack'),('chris.friesen@windriver.com','http://lists.openstack.org/pipermail/openstack'),('chris.hoge@puppetlabs.com','http://lists.openstack.org/pipermail/openstack'),('christian.schwede@enovance.com','http://lists.openstack.org/pipermail/openstack'),('christian@berendt.io','http://lists.openstack.org/pipermail/openstack'),('christophe.lehy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('christophe.sauthier@objectif-libre.com','http://lists.openstack.org/pipermail/openstack'),('christopher.lefelhoc@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('chris_millown@libero.it','http://lists.openstack.org/pipermail/openstack'),('chu.ducminh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('chuck.short@canonical.com','http://lists.openstack.org/pipermail/openstack'),('cian.o-driscoll@hp.com','http://lists.openstack.org/pipermail/openstack'),('cjellick@godaddy.com','http://lists.openstack.org/pipermail/openstack'),('cl55hhdu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('claire@openstack.org','http://lists.openstack.org/pipermail/openstack'),('clark.adam.p@gmail.com','http://lists.openstack.org/pipermail/openstack'),('clark.boylan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('claudio.pupparo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('claudio@onesource.pt','http://lists.openstack.org/pipermail/openstack'),('clay.gerrard@gmail.com','http://lists.openstack.org/pipermail/openstack'),('clement.buisson@lookout.com','http://lists.openstack.org/pipermail/openstack'),('clint@fewbar.com','http://lists.openstack.org/pipermail/openstack'),('clintd@waikato.ac.nz','http://lists.openstack.org/pipermail/openstack'),('cloudops@fastmail.cn','http://lists.openstack.org/pipermail/openstack'),('codercotton@me.com','http://lists.openstack.org/pipermail/openstack'),('colin@2cups.com','http://lists.openstack.org/pipermail/openstack'),('comiq@yandex.ru','http://lists.openstack.org/pipermail/openstack'),('communications.conferences@gmail.com','http://lists.openstack.org/pipermail/openstack'),('connectrajeev@gmail.com','http://lists.openstack.org/pipermail/openstack'),('conrad.kimball@boeing.com','http://lists.openstack.org/pipermail/openstack'),('contact@andreagiardini.com','http://lists.openstack.org/pipermail/openstack'),('contact@progbau.de','http://lists.openstack.org/pipermail/openstack'),('coolssandy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('coolsvap@gmail.com','http://lists.openstack.org/pipermail/openstack'),('correo_aar@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/openstack'),('cp16net@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cpaggen@cisco.com','http://lists.openstack.org/pipermail/openstack'),('cpp.cabrera@gmail.com','http://lists.openstack.org/pipermail/openstack'),('craig.jellick@gmail.com','http://lists.openstack.org/pipermail/openstack'),('craig@craigtracey.com','http://lists.openstack.org/pipermail/openstack'),('cristi.falcas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('crlb@uvic.ca','http://lists.openstack.org/pipermail/openstack'),('cseader@suse.com','http://lists.openstack.org/pipermail/openstack'),('cthier@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cuongdorlla@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cuongnguyenvan.it@gmail.com','http://lists.openstack.org/pipermail/openstack'),('curhuman@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cward@isi.edu','http://lists.openstack.org/pipermail/openstack'),('cyberlation@gmail.com','http://lists.openstack.org/pipermail/openstack'),('cyril.roelandt@enovance.com','http://lists.openstack.org/pipermail/openstack'),('d.w.chadwick@kent.ac.uk','http://lists.openstack.org/pipermail/openstack'),('dabige1@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('damon.devops@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dan.dyer00@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dan@cloudscaling.com','http://lists.openstack.org/pipermail/openstack'),('dan@nicira.com','http://lists.openstack.org/pipermail/openstack'),('dancsa@dancsa.hu','http://lists.openstack.org/pipermail/openstack'),('daniel.givens@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('daniel.kuffner@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Daniel.OReilly@dish.com','http://lists.openstack.org/pipermail/openstack'),('daniel.perez@exelisinc.com','http://lists.openstack.org/pipermail/openstack'),('daniel.petersen@hpc2n.umu.se','http://lists.openstack.org/pipermail/openstack'),('Daniel.Snider@hypert.com','http://lists.openstack.org/pipermail/openstack'),('daniel.spiekermann@fernuni-hagen.de','http://lists.openstack.org/pipermail/openstack'),('daniel@netkine.com','http://lists.openstack.org/pipermail/openstack'),('daniel@pocock.com.au','http://lists.openstack.org/pipermail/openstack'),('daniel@speichert.pl','http://lists.openstack.org/pipermail/openstack'),('daniel@syrinx.net','http://lists.openstack.org/pipermail/openstack'),('dannchoi@cisco.com','http://lists.openstack.org/pipermail/openstack'),('danny.roberts@reconnix.com','http://lists.openstack.org/pipermail/openstack'),('dannybeutler@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dara2002-openstack@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('darragh.oreilly@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('darren.birkett@gmail.com','http://lists.openstack.org/pipermail/openstack'),('darren@iweb.co.uk','http://lists.openstack.org/pipermail/openstack'),('das.srikrishna@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dattbbk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('davanum@gmail.com','http://lists.openstack.org/pipermail/openstack'),('davewalker@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('David.Bartlett@uk.ibm.com','http://lists.openstack.org/pipermail/openstack'),('david.comay@oracle.com','http://lists.openstack.org/pipermail/openstack'),('david.ferahi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('david.hill@ubisoft.com','http://lists.openstack.org/pipermail/openstack'),('david.lyle@hp.com','http://lists.openstack.org/pipermail/openstack'),('david.mahony@intel.com','http://lists.openstack.org/pipermail/openstack'),('david.medberry@canonical.com','http://lists.openstack.org/pipermail/openstack'),('david.scott@cloudscaling.com','http://lists.openstack.org/pipermail/openstack'),('david@zeromail.us','http://lists.openstack.org/pipermail/openstack'),('dbangalo@usc.edu','http://lists.openstack.org/pipermail/openstack'),('dbutler898@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dce3062@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ddutta@gmail.com','http://lists.openstack.org/pipermail/openstack'),('deaster@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('deejay1@srem.org','http://lists.openstack.org/pipermail/openstack'),('deepakrghuge@gmail.com','http://lists.openstack.org/pipermail/openstack'),('deepthi@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('dejeswan@in.ibm.com','http://lists.openstack.org/pipermail/openstack'),('dennisml@conversis.de','http://lists.openstack.org/pipermail/openstack'),('dev29aug@gmail.com','http://lists.openstack.org/pipermail/openstack'),('devananda.vdv@gmail.com','http://lists.openstack.org/pipermail/openstack'),('devendran.jagadisan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('devoid@anl.gov','http://lists.openstack.org/pipermail/openstack'),('dfrnascimento@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dfv@eurotux.com','http://lists.openstack.org/pipermail/openstack'),('dguryanov@parallels.com','http://lists.openstack.org/pipermail/openstack'),('dhanesh1212@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dhasthagheer@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dheerendra.madhusudhana@gmail.com','http://lists.openstack.org/pipermail/openstack'),('DHojnik@brainbits.net','http://lists.openstack.org/pipermail/openstack'),('diaominribao@gmail.com','http://lists.openstack.org/pipermail/openstack'),('diego.parrilla.santamaria@gmail.com','http://lists.openstack.org/pipermail/openstack'),('diego.parrilla@stackops.com','http://lists.openstack.org/pipermail/openstack'),('diego@flugel.it','http://lists.openstack.org/pipermail/openstack'),('diego@woitasen.com.ar','http://lists.openstack.org/pipermail/openstack'),('dinakar.gm@cloudbyte.co','http://lists.openstack.org/pipermail/openstack'),('diopter@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dirk@dmllr.de','http://lists.openstack.org/pipermail/openstack'),('divya.chandrasekar911@gmail.com','http://lists.openstack.org/pipermail/openstack'),('divyakk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dj199008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('djhon9813@gmail.com','http://lists.openstack.org/pipermail/openstack'),('djs428@drexel.edu','http://lists.openstack.org/pipermail/openstack'),('dj_dark_junglist@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('dkang@isi.edu','http://lists.openstack.org/pipermail/openstack'),('dmaziuk@bmrb.wisc.edu','http://lists.openstack.org/pipermail/openstack'),('dmescheryakov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('dmitry@athabascau.ca','http://lists.openstack.org/pipermail/openstack'),('dmsimard@iweb.com','http://lists.openstack.org/pipermail/openstack'),('dobhalashish772@gmail.com','http://lists.openstack.org/pipermail/openstack'),('doit4um@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dolph.mathews@gmail.com','http://lists.openstack.org/pipermail/openstack'),('don.waterloo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Donagh.McCabe@hp.com','http://lists.openstack.org/pipermail/openstack'),('donald.d.dugger@intel.com','http://lists.openstack.org/pipermail/openstack'),('dongjh@nci.com.cn','http://lists.openstack.org/pipermail/openstack'),('dotalton@cisco.com','http://lists.openstack.org/pipermail/openstack'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/openstack'),('douglas.mendizabal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('dpkshetty@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dragon889@163.com','http://lists.openstack.org/pipermail/openstack'),('drew.fisher@oracle.com','http://lists.openstack.org/pipermail/openstack'),('drew.weaver@thenap.com','http://lists.openstack.org/pipermail/openstack'),('ds442@outlook.com','http://lists.openstack.org/pipermail/openstack'),('dsb2@cin.ufpe.br','http://lists.openstack.org/pipermail/openstack'),('dscannell@gridcentric.com','http://lists.openstack.org/pipermail/openstack'),('dstepanenko@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('dtroyer@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dua_rajdeep@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('dukov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('dummyhacker85@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dustin@mozilla.com','http://lists.openstack.org/pipermail/openstack'),('dwding@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dwendlandt@vmware.com','http://lists.openstack.org/pipermail/openstack'),('dwittman@gmail.com','http://lists.openstack.org/pipermail/openstack'),('dwmaillist@gmail.com','http://lists.openstack.org/pipermail/openstack'),('earias_hp@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('easy880331@163.com','http://lists.openstack.org/pipermail/openstack'),('eberg@rubensteintech.com','http://lists.openstack.org/pipermail/openstack'),('ebisson@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('edgar.magana@workday.com','http://lists.openstack.org/pipermail/openstack'),('edouard.thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack'),('edward.hope-morley@canonical.com','http://lists.openstack.org/pipermail/openstack'),('Edward.Lezondra@imc-chicago.com','http://lists.openstack.org/pipermail/openstack'),('efedorova@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack'),('egon@egon.cc','http://lists.openstack.org/pipermail/openstack'),('eharney@redhat.com','http://lists.openstack.org/pipermail/openstack'),('eie.harish@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ELeobrera@atum.com','http://lists.openstack.org/pipermail/openstack'),('emagana@plumgrid.com','http://lists.openstack.org/pipermail/openstack'),('email@daviey.com','http://lists.openstack.org/pipermail/openstack'),('emccormick@cirrusseven.com','http://lists.openstack.org/pipermail/openstack'),('emilien.macchi@enovance.com','http://lists.openstack.org/pipermail/openstack'),('emre@groups-inc.com','http://lists.openstack.org/pipermail/openstack'),('emujicad@gmail.com','http://lists.openstack.org/pipermail/openstack'),('endre.karlson@gmail.com','http://lists.openstack.org/pipermail/openstack'),('enikanorov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('er.arunprasath@outlook.com','http://lists.openstack.org/pipermail/openstack'),('erent@skyatlas.com','http://lists.openstack.org/pipermail/openstack'),('erhan.ekici@gmail.com','http://lists.openstack.org/pipermail/openstack'),('eric@cloudscaling.com','http://lists.openstack.org/pipermail/openstack'),('ericperez@komiyaph.com','http://lists.openstack.org/pipermail/openstack'),('erming@ualberta.ca','http://lists.openstack.org/pipermail/openstack'),('esedmehmet@gmail.com','http://lists.openstack.org/pipermail/openstack'),('eshwar.vmcloud@gmail.com','http://lists.openstack.org/pipermail/openstack'),('eswar7028@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ethan@757.org','http://lists.openstack.org/pipermail/openstack'),('ethan_zq@163.com','http://lists.openstack.org/pipermail/openstack'),('evan.fraser@trademe.co.nz','http://lists.openstack.org/pipermail/openstack'),('everett.toews@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('EvgenyF@Radware.com','http://lists.openstack.org/pipermail/openstack'),('f.charlier@enovance.com','http://lists.openstack.org/pipermail/openstack'),('fabien.boucher@enovance.com','http://lists.openstack.org/pipermail/openstack'),('faelrba@gmail.com','http://lists.openstack.org/pipermail/openstack'),('fallertsen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('faraya@kionetworks.com','http://lists.openstack.org/pipermail/openstack'),('fazilx.sajjad@intel.com','http://lists.openstack.org/pipermail/openstack'),('fcortijo@contactpointsolutions.com','http://lists.openstack.org/pipermail/openstack'),('fenghe@corp.dnsbed.com','http://lists.openstack.org/pipermail/openstack'),('fengyc.work@gmail.com','http://lists.openstack.org/pipermail/openstack'),('fengyong.gm@gmail.com','http://lists.openstack.org/pipermail/openstack'),('filipe.manco@gmail.com','http://lists.openstack.org/pipermail/openstack'),('flavio@redhat.com','http://lists.openstack.org/pipermail/openstack'),('florian@hastexo.com','http://lists.openstack.org/pipermail/openstack'),('florianchazal@gmail.com','http://lists.openstack.org/pipermail/openstack'),('flwang@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('fm.hinrichsen@googlemail.com','http://lists.openstack.org/pipermail/openstack'),('fmeini@esseweb.eu','http://lists.openstack.org/pipermail/openstack'),('francisco.lugo.e@gmail.com','http://lists.openstack.org/pipermail/openstack'),('franck.dernoncourt@gmail.com','http://lists.openstack.org/pipermail/openstack'),('francois@ctrlaltdel.ch','http://lists.openstack.org/pipermail/openstack'),('frank@owncloud.com','http://lists.openstack.org/pipermail/openstack'),('frans@meruvian.org','http://lists.openstack.org/pipermail/openstack'),('fsoppelsa@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack'),('furychrist@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('Gabriel.Hurley@nebula.com','http://lists.openstack.org/pipermail/openstack'),('gabriel_staicu@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('gaguilar@aguilardelgado.com','http://lists.openstack.org/pipermail/openstack'),('gale.michael@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gareth@openstacker.org','http://lists.openstack.org/pipermail/openstack'),('gastonkeller@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gavin.brebner@hp.com','http://lists.openstack.org/pipermail/openstack'),('geekinutah@gmail.com','http://lists.openstack.org/pipermail/openstack'),('geert.jansen@ravellosystems.com','http://lists.openstack.org/pipermail/openstack'),('gengjh@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('George.Mihaiescu@Q9.com','http://lists.openstack.org/pipermail/openstack'),('george.reese@imaginary.com','http://lists.openstack.org/pipermail/openstack'),('george.shuklin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('geraint@koding.com','http://lists.openstack.org/pipermail/openstack'),('gerard1@fnal.gov','http://lists.openstack.org/pipermail/openstack'),('germy.lure@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Gerry.Drudy@hp.com','http://lists.openstack.org/pipermail/openstack'),('gessau@cisco.com','http://lists.openstack.org/pipermail/openstack'),('gessners@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('gfa@zumbi.com.ar','http://lists.openstack.org/pipermail/openstack'),('ghacheniour@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ghanshyammann@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ghe@debian.org','http://lists.openstack.org/pipermail/openstack'),('Giacomo.Tenaglia@cern.ch','http://lists.openstack.org/pipermail/openstack'),('Giles.Cornelius@novotel-bd.com','http://lists.openstack.org/pipermail/openstack'),('giorgis@acmac.uoc.gr','http://lists.openstack.org/pipermail/openstack'),('giovanni@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack'),('giri.basava@triliodata.com','http://lists.openstack.org/pipermail/openstack'),('girijasharansingh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('git-harry@live.co.uk','http://lists.openstack.org/pipermail/openstack'),('giulio.vito.demusso@gmail.com','http://lists.openstack.org/pipermail/openstack'),('giuseppegaleota@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gkotton@vmware.com','http://lists.openstack.org/pipermail/openstack'),('GLIKSON@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('glongwave@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gmi68745@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gmurphy@redhat.com','http://lists.openstack.org/pipermail/openstack'),('gokoproject@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gokrokvertskhov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('goldstone1@llnl.gov','http://lists.openstack.org/pipermail/openstack'),('goncalo@lip.pt','http://lists.openstack.org/pipermail/openstack'),('gongysh@unitedstack.com','http://lists.openstack.org/pipermail/openstack'),('gong_ys2013@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('gorozco@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gowri.ln123@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gpeeyush@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('gpeeyush@ymail.com','http://lists.openstack.org/pipermail/openstack'),('graham.hayes@hp.com','http://lists.openstack.org/pipermail/openstack'),('grant.murphy@hp.com','http://lists.openstack.org/pipermail/openstack'),('greenx@yandex.ru','http://lists.openstack.org/pipermail/openstack'),('greg.chavez@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Greg.Waines@windriver.com','http://lists.openstack.org/pipermail/openstack'),('grkim@kisti.re.kr','http://lists.openstack.org/pipermail/openstack'),('gsim@redhat.com','http://lists.openstack.org/pipermail/openstack'),('gtt116@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gtvrreddy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('guang.yee@hp.com','http://lists.openstack.org/pipermail/openstack'),('guangjian@gmail.com','http://lists.openstack.org/pipermail/openstack'),('guangyu@unitedstack.com','http://lists.openstack.org/pipermail/openstack'),('guduru_sirisha@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('guilherme.lazzari@hp.com','http://lists.openstack.org/pipermail/openstack'),('guillaume.thouvenin@bull.net','http://lists.openstack.org/pipermail/openstack'),('guillaume@cheramy.name','http://lists.openstack.org/pipermail/openstack'),('guillermoalvarado89@gmail.com','http://lists.openstack.org/pipermail/openstack'),('guimalufb@gmail.com','http://lists.openstack.org/pipermail/openstack'),('guojw@neusoft.com','http://lists.openstack.org/pipermail/openstack'),('guolongcang.work@gmail.com','http://lists.openstack.org/pipermail/openstack'),('guoyingc@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('gustavo.randich@gmail.com','http://lists.openstack.org/pipermail/openstack'),('gvarghese@aqorn.com','http://lists.openstack.org/pipermail/openstack'),('gvdm@libero.it','http://lists.openstack.org/pipermail/openstack'),('h-aramaki@netone.co.jp','http://lists.openstack.org/pipermail/openstack'),('h@hameedullah.com','http://lists.openstack.org/pipermail/openstack'),('hailybrown@hushmail.com','http://lists.openstack.org/pipermail/openstack'),('haiwu.us@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hanan.liaqat@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('haneef.ali@hp.com','http://lists.openstack.org/pipermail/openstack'),('hanryjohn7@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hao.1.wang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('haomaiwang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hari.kannan@hp.com','http://lists.openstack.org/pipermail/openstack'),('Haribabu_Kasturi@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('harish.amrale@gmail.com','http://lists.openstack.org/pipermail/openstack'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('harm@weites.com','http://lists.openstack.org/pipermail/openstack'),('harsshah@cisco.com','http://lists.openstack.org/pipermail/openstack'),('hartsocks@vmware.com','http://lists.openstack.org/pipermail/openstack'),('hayashi@ntti3.com','http://lists.openstack.org/pipermail/openstack'),('hegde.shashank@gmail.com','http://lists.openstack.org/pipermail/openstack'),('heidi@openstack.org','http://lists.openstack.org/pipermail/openstack'),('helen.walsh@emc.com','http://lists.openstack.org/pipermail/openstack'),('henryn@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('heut2008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hfordham@radiantworlds.com','http://lists.openstack.org/pipermail/openstack'),('hguemar@fedoraproject.org','http://lists.openstack.org/pipermail/openstack'),('hhding@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hiepnv@vccloud.vn','http://lists.openstack.org/pipermail/openstack'),('hisayuki.takeda@oceanearth-corp.com','http://lists.openstack.org/pipermail/openstack'),('hitesh.wadekar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hiya@davidpint.org','http://lists.openstack.org/pipermail/openstack'),('hkang.sunysb@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hkraemer@anynines.com','http://lists.openstack.org/pipermail/openstack'),('hlucken@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('hnakil@contrailsystems.com','http://lists.openstack.org/pipermail/openstack'),('holms@holms.lt','http://lists.openstack.org/pipermail/openstack'),('hrushikesh.gangur@hp.com','http://lists.openstack.org/pipermail/openstack'),('hr_malik@rediffmail.com','http://lists.openstack.org/pipermail/openstack'),('huangxx_2155@live.com','http://lists.openstack.org/pipermail/openstack'),('huapeng@arcor.de','http://lists.openstack.org/pipermail/openstack'),('hubbert@hubbertsmith.com','http://lists.openstack.org/pipermail/openstack'),('huyr@arraynetworks.com.cn','http://lists.openstack.org/pipermail/openstack'),('hvprash@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hyangii@gmail.com','http://lists.openstack.org/pipermail/openstack'),('hyunseok@ieee.org','http://lists.openstack.org/pipermail/openstack'),('hzfangjh@corp.netease.com','http://lists.openstack.org/pipermail/openstack'),('hzguanqiang@corp.netease.com','http://lists.openstack.org/pipermail/openstack'),('hzwangpan@corp.netease.com','http://lists.openstack.org/pipermail/openstack'),('Ian.Marshall@freedom-finance.com','http://lists.openstack.org/pipermail/openstack'),('ian@itlhosting.co.uk','http://lists.openstack.org/pipermail/openstack'),('ian@naimnetworks.com','http://lists.openstack.org/pipermail/openstack'),('ibissga@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ibravo@ltgfederal.com','http://lists.openstack.org/pipermail/openstack'),('iccha.sethi@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('ichihara.hirofumi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack'),('ielterman@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('ifzing@126.com','http://lists.openstack.org/pipermail/openstack'),('igor@tnkng.com','http://lists.openstack.org/pipermail/openstack'),('igordcard@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ikarpov@helioscloud.com','http://lists.openstack.org/pipermail/openstack'),('ikhudoshyn@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('ildiko.vancsa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ilkka.tengvall@cybercom.com','http://lists.openstack.org/pipermail/openstack'),('ilyaalekseyev@acm.org','http://lists.openstack.org/pipermail/openstack'),('iman.1353@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('imsplitbit@gmail.com','http://lists.openstack.org/pipermail/openstack'),('iner45@gmail.com','http://lists.openstack.org/pipermail/openstack'),('info@cyle.ch','http://lists.openstack.org/pipermail/openstack'),('info@honeybutcher.de','http://lists.openstack.org/pipermail/openstack'),('info@intocloud.org','http://lists.openstack.org/pipermail/openstack'),('iosstef@gmail.com','http://lists.openstack.org/pipermail/openstack'),('irenab.dev@gmail.com','http://lists.openstack.org/pipermail/openstack'),('irenab@mellanox.com','http://lists.openstack.org/pipermail/openstack'),('isaacm@bitheads.com','http://lists.openstack.org/pipermail/openstack'),('israel.ziv@huawei.com','http://lists.openstack.org/pipermail/openstack'),('isviridov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('itamar@ispbrasil.com.br','http://lists.openstack.org/pipermail/openstack'),('itzikb@redhat.com','http://lists.openstack.org/pipermail/openstack'),('ivanoch@gmail.com','http://lists.openstack.org/pipermail/openstack'),('J.Pavlik@tcpisek.cz','http://lists.openstack.org/pipermail/openstack'),('jacek.swiderski@codilime.com','http://lists.openstack.org/pipermail/openstack'),('jack.mccann@hp.com','http://lists.openstack.org/pipermail/openstack'),('jacki.bauer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('jacobgodin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jagadeeshwaran.k33@wipro.com','http://lists.openstack.org/pipermail/openstack'),('jagdish1287@gmail.com','http://lists.openstack.org/pipermail/openstack'),('james.burnash@noaa.gov','http://lists.openstack.org/pipermail/openstack'),('james.denton@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('james.kino123@gmail.com','http://lists.openstack.org/pipermail/openstack'),('james.page@canonical.com','http://lists.openstack.org/pipermail/openstack'),('james.page@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('james@talkunafraid.co.uk','http://lists.openstack.org/pipermail/openstack'),('jameszee13@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jamielennox@redhat.com','http://lists.openstack.org/pipermail/openstack'),('jan.krajdl@casablanca.cz','http://lists.openstack.org/pipermail/openstack'),('jankihchhatbar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jarret.raim@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('jason.bishop@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jason.cannavale@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('jason@chatinara.com','http://lists.openstack.org/pipermail/openstack'),('jason@koelker.net','http://lists.openstack.org/pipermail/openstack'),('jasper.aikema@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Jasper.Capel@spilgames.com','http://lists.openstack.org/pipermail/openstack'),('javedamar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jay.lau.513@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jbachtel@bericotechnologies.com','http://lists.openstack.org/pipermail/openstack'),('jbresnah@redhat.com','http://lists.openstack.org/pipermail/openstack'),('jbryce@jbryce.com','http://lists.openstack.org/pipermail/openstack'),('jch.martin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jcoufal@redhat.com','http://lists.openstack.org/pipermail/openstack'),('jcromer@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('jdandrea@research.att.com','http://lists.openstack.org/pipermail/openstack'),('jean-daniel.bonnetot@ovh.net','http://lists.openstack.org/pipermail/openstack'),('jeetuindian@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jeff@sweetlabs.com','http://lists.openstack.org/pipermail/openstack'),('jeffrngu@cisco.com','http://lists.openstack.org/pipermail/openstack'),('Jeff_Cai@symantec.com','http://lists.openstack.org/pipermail/openstack'),('Jeff_dambly@symantec.com','http://lists.openstack.org/pipermail/openstack'),('jemay86@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jenny@intocloud.org','http://lists.openstack.org/pipermail/openstack'),('jens-christian.fischer@switch.ch','http://lists.openstack.org/pipermail/openstack'),('jeremy@dreamhost.com','http://lists.openstack.org/pipermail/openstack'),('jeremy@openstack.org','http://lists.openstack.org/pipermail/openstack'),('jeremydeininger@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jeroen@mediacaster.nl','http://lists.openstack.org/pipermail/openstack'),('jerutley@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jesse.pretorius@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jessica.lucci@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('jeyakumar.jay@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jford@blackmesh.com','http://lists.openstack.org/pipermail/openstack'),('jhorey@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jiajun@unitedstack.com','http://lists.openstack.org/pipermail/openstack'),('jian.wen@canonical.com','http://lists.openstack.org/pipermail/openstack'),('jianghaitao@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jiangyaoguo@huawei.com','http://lists.openstack.org/pipermail/openstack'),('jianlonghei@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jiantao.h.he@intel.com','http://lists.openstack.org/pipermail/openstack'),('jiaqin1017@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jitendra.b@pramati.com','http://lists.openstack.org/pipermail/openstack'),('jkugel@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('jl.santiago21@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jle@cosmicfire.net','http://lists.openstack.org/pipermail/openstack'),('jlennox@redhat.com','http://lists.openstack.org/pipermail/openstack'),('joao.faria@poli.ufrj.br','http://lists.openstack.org/pipermail/openstack'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack'),('joe.hakim.rahme@enovance.com','http://lists.openstack.org/pipermail/openstack'),('joe.savak@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('joe.topjian@cybera.ca','http://lists.openstack.org/pipermail/openstack'),('joe@topjian.net','http://lists.openstack.org/pipermail/openstack'),('joeann.rodriques@icertis.com','http://lists.openstack.org/pipermail/openstack'),('joehazzers@gmail.com','http://lists.openstack.org/pipermail/openstack'),('joel.cooklin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('johanna.heinonen@nsn.com','http://lists.openstack.org/pipermail/openstack'),('john.bartley@gmail.com','http://lists.openstack.org/pipermail/openstack'),('john.griffith8@gmail.com','http://lists.openstack.org/pipermail/openstack'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack'),('john.mann@monash.edu','http://lists.openstack.org/pipermail/openstack'),('john.wood@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('john@dewey.ws','http://lists.openstack.org/pipermail/openstack'),('johndecot@gmail.com','http://lists.openstack.org/pipermail/openstack'),('johnmark@johnmark.org','http://lists.openstack.org/pipermail/openstack'),('johnnykontrolletti@gmx.net','http://lists.openstack.org/pipermail/openstack'),('jojokururu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jolyon@limilo.com','http://lists.openstack.org/pipermail/openstack'),('jon@csail.mit.edu','http://lists.openstack.org/pipermail/openstack'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/openstack'),('jonathan.abdiel@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jonathan.lelous@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jonathan@openstack.org','http://lists.openstack.org/pipermail/openstack'),('jongwoohan@naver.com','http://lists.openstack.org/pipermail/openstack'),('jonkon80@gmx.de','http://lists.openstack.org/pipermail/openstack'),('jordi@cdmon.com','http://lists.openstack.org/pipermail/openstack'),('jorenwu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jorgedr@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('joseph.breu@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('josh.durgin@inktank.com','http://lists.openstack.org/pipermail/openstack'),('josh.odom@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('josh@kleinpeter.org','http://lists.openstack.org/pipermail/openstack'),('joshua.hesketh@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('Joshua.Skains@evault.com','http://lists.openstack.org/pipermail/openstack'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/openstack'),('jp@jamezpolley.com','http://lists.openstack.org/pipermail/openstack'),('jpichon@redhat.com','http://lists.openstack.org/pipermail/openstack'),('jpr@uab.edu','http://lists.openstack.org/pipermail/openstack'),('jranjan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('js@hipro.co.in','http://lists.openstack.org/pipermail/openstack'),('js@vinci-it.com','http://lists.openstack.org/pipermail/openstack'),('jsalvachua@dit.upm.es','http://lists.openstack.org/pipermail/openstack'),('jsbryant@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('jshaw90@gmail.com','http://lists.openstack.org/pipermail/openstack'),('jsuchome@suse.cz','http://lists.openstack.org/pipermail/openstack'),('jt628910@163.com','http://lists.openstack.org/pipermail/openstack'),('juan@memset.com','http://lists.openstack.org/pipermail/openstack'),('juanfra.rodriguez.cardoso@gmail.com','http://lists.openstack.org/pipermail/openstack'),('judd@newgoliath.com','http://lists.openstack.org/pipermail/openstack'),('Juerg.Haefliger@hp.com','http://lists.openstack.org/pipermail/openstack'),('juergen@brendel.com','http://lists.openstack.org/pipermail/openstack'),('juergh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('juha.tynninen@tieto.com','http://lists.openstack.org/pipermail/openstack'),('julian.cash@hp.com','http://lists.openstack.org/pipermail/openstack'),('julien@danjou.info','http://lists.openstack.org/pipermail/openstack'),('justin.brown@fandingo.org','http://lists.openstack.org/pipermail/openstack'),('justin.hopper@hp.com','http://lists.openstack.org/pipermail/openstack'),('justin@netrove.com','http://lists.openstack.org/pipermail/openstack'),('jwilmes@zenoss.com','http://lists.openstack.org/pipermail/openstack'),('k.w.ritchie0@gmail.com','http://lists.openstack.org/pipermail/openstack'),('k4ncerbero@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kai.brennenstuhl@de.ibm.com','http://lists.openstack.org/pipermail/openstack'),('kai.brennenstuhl@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kanabuchi.mitsuru@po.ntts.co.jp','http://lists.openstack.org/pipermail/openstack'),('karan.singh@csc.fi','http://lists.openstack.org/pipermail/openstack'),('karim.esstt@gmail.com','http://lists.openstack.org/pipermail/openstack'),('karun.pruthi07@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kashif.alig@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kaushalshriyan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kazishariar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kb.sankethi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kb718q@att.com','http://lists.openstack.org/pipermail/openstack'),('kbalavignesh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kchamart@redhat.com','http://lists.openstack.org/pipermail/openstack'),('ken1ohmichi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ken@jots.org','http://lists.openstack.org/pipermail/openstack'),('ken@songwhale.com','http://lists.openstack.org/pipermail/openstack'),('kenpeng@pravda.ru','http://lists.openstack.org/pipermail/openstack'),('keshav@edcast.com','http://lists.openstack.org/pipermail/openstack'),('keshava.a@hp.com','http://lists.openstack.org/pipermail/openstack'),('kevin.breit@kevinbreit.net','http://lists.openstack.org/pipermail/openstack'),('Kevin.Duan@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack'),('kevin.huang@canonical.com','http://lists.openstack.org/pipermail/openstack'),('kevin.mitchell@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('kevin@linuxservices.co.uk','http://lists.openstack.org/pipermail/openstack'),('kfiresmith@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kgregorious@gmail.com','http://lists.openstack.org/pipermail/openstack'),('khayam.gondal@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kiall@hp.com','http://lists.openstack.org/pipermail/openstack'),('kiall@macinnes.ie','http://lists.openstack.org/pipermail/openstack'),('kimbyeonggi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kirankumarkuvvarapu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('KISIN@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('kispear@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kiwik.chenrui@huawei.com','http://lists.openstack.org/pipermail/openstack'),('klaus.schuermann@mediabeam.com','http://lists.openstack.org/pipermail/openstack'),('kmbharath.km@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/openstack'),('kodokuu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('konglingxian@huawei.com','http://lists.openstack.org/pipermail/openstack'),('koteswara.kelam@hp.com','http://lists.openstack.org/pipermail/openstack'),('kpeng@netzero.net','http://lists.openstack.org/pipermail/openstack'),('kpeng@terra.com','http://lists.openstack.org/pipermail/openstack'),('krishna1256@gmail.com','http://lists.openstack.org/pipermail/openstack'),('krook@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('krotscheck@gmail.com','http://lists.openstack.org/pipermail/openstack'),('krt@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('krzysiekg18@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ksingh@csc.fi','http://lists.openstack.org/pipermail/openstack'),('ktwcs2005@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kukura@noironetworks.com','http://lists.openstack.org/pipermail/openstack'),('kumarpraveen.nitdgp@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kupo@linuxdigital.net','http://lists.openstack.org/pipermail/openstack'),('kuvaja@hp.com','http://lists.openstack.org/pipermail/openstack'),('kyle.macdonald@gmail.com','http://lists.openstack.org/pipermail/openstack'),('kylin7.sg@gmail.com','http://lists.openstack.org/pipermail/openstack'),('l.allen09@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lacikaaa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('laclasse@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lad.raghavendra@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lalitha.maruthachalam@aricent.com','http://lists.openstack.org/pipermail/openstack'),('landru@telecom-lille.fr','http://lists.openstack.org/pipermail/openstack'),('lars@redhat.com','http://lists.openstack.org/pipermail/openstack'),('laserjetyang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('laszewski@gmail.com','http://lists.openstack.org/pipermail/openstack'),('launchpad-mailinglist-20130227@angelfaq.com','http://lists.openstack.org/pipermail/openstack'),('launchpad@mortman.com','http://lists.openstack.org/pipermail/openstack'),('lauren@openstack.org','http://lists.openstack.org/pipermail/openstack'),('lawlietwf@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('lbalbalba@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ldbragst@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('leandro.21.2008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('leandro.reox@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lecalcot@cisco.com','http://lists.openstack.org/pipermail/openstack'),('lee@aero.org','http://lists.openstack.org/pipermail/openstack'),('Leon.Li2@emc.com','http://lists.openstack.org/pipermail/openstack'),('letsgotry7@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lezz.giles@overturenetworks.com','http://lists.openstack.org/pipermail/openstack'),('li-gong.duan@hp.com','http://lists.openstack.org/pipermail/openstack'),('liam.young@canonical.com','http://lists.openstack.org/pipermail/openstack'),('lianhao.lu@intel.com','http://lists.openstack.org/pipermail/openstack'),('lichaoyin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('licongjuan@huawei.com','http://lists.openstack.org/pipermail/openstack'),('lidan17@jd.com','http://lists.openstack.org/pipermail/openstack'),('lilinguo8212@gmail.com','http://lists.openstack.org/pipermail/openstack'),('linus@linusnova.com','http://lists.openstack.org/pipermail/openstack'),('linuxguru4u@gmail.com','http://lists.openstack.org/pipermail/openstack'),('linuxtovishesh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('linxingnku@gmail.com','http://lists.openstack.org/pipermail/openstack'),('litong01@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('liudong78@huawei.com','http://lists.openstack.org/pipermail/openstack'),('liugang12@sgepri.sgcc.com.cn','http://lists.openstack.org/pipermail/openstack'),('liusheng1175@126.com','http://lists.openstack.org/pipermail/openstack'),('lixq2000@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lizhuran@jd.com','http://lists.openstack.org/pipermail/openstack'),('llg8212@163.com','http://lists.openstack.org/pipermail/openstack'),('ll_nwpu@163.com','http://lists.openstack.org/pipermail/openstack'),('lmihaiescu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('logan@bacoosta.com','http://lists.openstack.org/pipermail/openstack'),('logan@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('logica111@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('lohitv@gwmail.gwu.edu','http://lists.openstack.org/pipermail/openstack'),('longlq.openstack@gmail.com','http://lists.openstack.org/pipermail/openstack'),('longlq.uct@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack'),('louis-marie.loe@uzh.ch','http://lists.openstack.org/pipermail/openstack'),('louis.philippe.reid@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lpl6338236@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lrbbs@cin.ufpe.br','http://lists.openstack.org/pipermail/openstack'),('lsmola@redhat.com','http://lists.openstack.org/pipermail/openstack'),('luaan.lucas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lucas.gary@gmail.com','http://lists.openstack.org/pipermail/openstack'),('luis.fernandez.alvarez@cern.ch','http://lists.openstack.org/pipermail/openstack'),('luis@debethencourt.com','http://lists.openstack.org/pipermail/openstack'),('luis@woorea.es','http://lists.openstack.org/pipermail/openstack'),('luisguilherme.cr@gmail.com','http://lists.openstack.org/pipermail/openstack'),('lukasvizner@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Lysander_David@symantec.com','http://lists.openstack.org/pipermail/openstack'),('lzy.dev@gmail.com','http://lists.openstack.org/pipermail/openstack'),('m.aubry@hexanet.fr','http://lists.openstack.org/pipermail/openstack'),('m.channappa.negalur@accenture.com','http://lists.openstack.org/pipermail/openstack'),('m@metacloud.com','http://lists.openstack.org/pipermail/openstack'),('macias@shellycloud.com','http://lists.openstack.org/pipermail/openstack'),('magesh.gv@oneconvergence.com','http://lists.openstack.org/pipermail/openstack'),('mageshmannar@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('mahardika.gilang@andalabs.com','http://lists.openstack.org/pipermail/openstack'),('mahati.chamarthy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mail.ashishchandra@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mail@lists.macscr.com','http://lists.openstack.org/pipermail/openstack'),('mailing@tam.si','http://lists.openstack.org/pipermail/openstack'),('mailinglists@xgm.de','http://lists.openstack.org/pipermail/openstack'),('maishsk+openstack@maishsk.com','http://lists.openstack.org/pipermail/openstack'),('maksimov@gmail.com','http://lists.openstack.org/pipermail/openstack'),('malei@cn.fujitsu.com','http://lists.openstack.org/pipermail/openstack'),('mali@awcloud.com','http://lists.openstack.org/pipermail/openstack'),('malini.k.bhandaru@intel.com','http://lists.openstack.org/pipermail/openstack'),('mandarkhanolkar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mangelajo@redhat.com','http://lists.openstack.org/pipermail/openstack'),('manoj.agarwal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('marc.heckmann@ubisoft.com','http://lists.openstack.org/pipermail/openstack'),('marcelodieder@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Marco.Fornaro@huawei.com','http://lists.openstack.org/pipermail/openstack'),('marcobravov@gmail.com','http://lists.openstack.org/pipermail/openstack'),('marcosnobregajr@gmail.com','http://lists.openstack.org/pipermail/openstack'),('marek.ruzicka@t-systems.sk','http://lists.openstack.org/pipermail/openstack'),('marica.antonacci@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Marius.Storm-Olsen@student.bi.no','http://lists.openstack.org/pipermail/openstack'),('mariusz.gronczewski@efigence.com','http://lists.openstack.org/pipermail/openstack'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/openstack'),('mark.kirkwood@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack'),('mark.m.miller@hp.com','http://lists.openstack.org/pipermail/openstack'),('mark@carlson.net','http://lists.openstack.org/pipermail/openstack'),('mark@collierclan.net','http://lists.openstack.org/pipermail/openstack'),('mark@markrichman.com','http://lists.openstack.org/pipermail/openstack'),('mark@openstack.org','http://lists.openstack.org/pipermail/openstack'),('markku.tavasti@cybercom.com','http://lists.openstack.org/pipermail/openstack'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack'),('Mark_Jackson@symantec.com','http://lists.openstack.org/pipermail/openstack'),('Martin.Lipka@pulsant.com','http://lists.openstack.org/pipermail/openstack'),('martins@hostnet.lv','http://lists.openstack.org/pipermail/openstack'),('martins@vertigs.lv','http://lists.openstack.org/pipermail/openstack'),('marton.kiss@gmail.com','http://lists.openstack.org/pipermail/openstack'),('maruti.kamat@hp.com','http://lists.openstack.org/pipermail/openstack'),('marvelliu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('masayuki.igawa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('masoom.alam@gmail.com','http://lists.openstack.org/pipermail/openstack'),('masoom.alam@wanclouds.net','http://lists.openstack.org/pipermail/openstack'),('mate.lakat@citrix.com','http://lists.openstack.org/pipermail/openstack'),('matej@tam.si','http://lists.openstack.org/pipermail/openstack'),('mathieu.rohon@gmail.com','http://lists.openstack.org/pipermail/openstack'),('matt.dietz@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('matt.griffin@percona.com','http://lists.openstack.org/pipermail/openstack'),('matt.jarvis@datacentred.co.uk','http://lists.openstack.org/pipermail/openstack'),('matt@cactuar.net','http://lists.openstack.org/pipermail/openstack'),('matt@hogstrom.org','http://lists.openstack.org/pipermail/openstack'),('matt@nycresistor.com','http://lists.openstack.org/pipermail/openstack'),('matt@oliver.net.au','http://lists.openstack.org/pipermail/openstack'),('matt@redhat.com','http://lists.openstack.org/pipermail/openstack'),('mattd5574@gmail.com','http://lists.openstack.org/pipermail/openstack'),('matthew.macdonald-wallace@hp.com','http://lists.openstack.org/pipermail/openstack'),('matthewhray@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mattm@ex.idig.net','http://lists.openstack.org/pipermail/openstack'),('maty.grosz@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack'),('mauch@kit.edu','http://lists.openstack.org/pipermail/openstack'),('maurosr@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mavlcek@cisco.com','http://lists.openstack.org/pipermail/openstack'),('maxiao@unitedstack.com','http://lists.openstack.org/pipermail/openstack'),('maximiliano.venesio@mercadolibre.com','http://lists.openstack.org/pipermail/openstack'),('maxiosorio@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mb@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mbasnight@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mcheung63@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('mclaughi@adobe.com','http://lists.openstack.org/pipermail/openstack'),('mcocmo62@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mcostack@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mdorman@godaddy.com','http://lists.openstack.org/pipermail/openstack'),('me@arangamani.net','http://lists.openstack.org/pipermail/openstack'),('me@not.mn','http://lists.openstack.org/pipermail/openstack'),('mechtri.marwen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('meetmanok@gmail.com','http://lists.openstack.org/pipermail/openstack'),('member@linkedin.com','http://lists.openstack.org/pipermail/openstack'),('menghuizhanguo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mengql112233@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mestery@noironetworks.com','http://lists.openstack.org/pipermail/openstack'),('mestery@siliconloons.com','http://lists.openstack.org/pipermail/openstack'),('mex@di.unipmn.it','http://lists.openstack.org/pipermail/openstack'),('mhr.james@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Michael.Ayenson@jhuapl.edu','http://lists.openstack.org/pipermail/openstack'),('michael.vandeborne@cetic.be','http://lists.openstack.org/pipermail/openstack'),('michael@the-davies.net','http://lists.openstack.org/pipermail/openstack'),('micmeste@cisco.com','http://lists.openstack.org/pipermail/openstack'),('miguel.grinberg@gmail.com','http://lists.openstack.org/pipermail/openstack'),('miguel2hermanas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack'),('mike.hearn@oracle.com','http://lists.openstack.org/pipermail/openstack'),('mike.preston@synety.com','http://lists.openstack.org/pipermail/openstack'),('miki.ryo@po.ntts.co.jp','http://lists.openstack.org/pipermail/openstack'),('min.wang6@hp.com','http://lists.openstack.org/pipermail/openstack'),('Minglong.Shao@netapp.com','http://lists.openstack.org/pipermail/openstack'),('minox.88@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mismith@overstock.com','http://lists.openstack.org/pipermail/openstack'),('mitch@metauser.net','http://lists.openstack.org/pipermail/openstack'),('mizumoto.da@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mjturek@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mk@npulsetech.com','http://lists.openstack.org/pipermail/openstack'),('mkassawara@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mloza@morphlabs.com','http://lists.openstack.org/pipermail/openstack'),('mmaglana@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mmonette@2keys.ca','http://lists.openstack.org/pipermail/openstack'),('mmr@gigahost.dk','http://lists.openstack.org/pipermail/openstack'),('mn1921@att.com','http://lists.openstack.org/pipermail/openstack'),('mn@mnabozny.pl','http://lists.openstack.org/pipermail/openstack'),('mnaser@vexxhost.com','http://lists.openstack.org/pipermail/openstack'),('mnzaki@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mohib@qmail.com.bd','http://lists.openstack.org/pipermail/openstack'),('moizarif2002@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack'),('moreira.belmiro.email.lists@gmail.com','http://lists.openstack.org/pipermail/openstack'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack'),('morgan@metacloud.com','http://lists.openstack.org/pipermail/openstack'),('motoki@da.jp.nec.com','http://lists.openstack.org/pipermail/openstack'),('motovilovets.sergey@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mpatil@hp.com','http://lists.openstack.org/pipermail/openstack'),('mpetersen@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('mrf.mnm@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mrhearn@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mridhul@live.com','http://lists.openstack.org/pipermail/openstack'),('mriedem@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mriedem@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mrunge@redhat.com','http://lists.openstack.org/pipermail/openstack'),('mrz@lookout.com','http://lists.openstack.org/pipermail/openstack'),('mr_amitanand@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('mscherbakov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('msoda@coredial.com','http://lists.openstack.org/pipermail/openstack'),('msolanas@cisco.com','http://lists.openstack.org/pipermail/openstack'),('mspreitz@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('mst4086@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mstaaravin@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack'),('mukul.g.kotwani@hp.com','http://lists.openstack.org/pipermail/openstack'),('mulmisujeetpd@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mune@zhaw.ch','http://lists.openstack.org/pipermail/openstack'),('muralidharb@gmail.com','http://lists.openstack.org/pipermail/openstack'),('murat.birben@ardictech.com','http://lists.openstack.org/pipermail/openstack'),('mvanwink@rackspace.com','http://lists.openstack.org/pipermail/openstack'),('mwjpiero@gmail.com','http://lists.openstack.org/pipermail/openstack'),('myselfasunder@gmail.com','http://lists.openstack.org/pipermail/openstack'),('mzoeller@de.ibm.com','http://lists.openstack.org/pipermail/openstack'),('n.paladi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nagaraju_bingi@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('nallagangus@gmail.com','http://lists.openstack.org/pipermail/openstack'),('naman.g.muley@gmail.com','http://lists.openstack.org/pipermail/openstack'),('namei.unix@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nandakumarpr@gmail.com','http://lists.openstack.org/pipermail/openstack'),('narayan.desai@gmail.com','http://lists.openstack.org/pipermail/openstack'),('narayana@uni-mainz.de','http://lists.openstack.org/pipermail/openstack'),('Narendra.Trivedi@savvis.com','http://lists.openstack.org/pipermail/openstack'),('NARESH.SAADHU@LNTTECHSERVICES.COM','http://lists.openstack.org/pipermail/openstack'),('nathan.nxu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nathanael.i.burton.work@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nathanael.i.burton@gmail.com','http://lists.openstack.org/pipermail/openstack'),('natsume.takashi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack'),('naveen.kunareddy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Navneet.Singh@netapp.com','http://lists.openstack.org/pipermail/openstack'),('nchase@earthlink.net','http://lists.openstack.org/pipermail/openstack'),('ndipanov@redhat.com','http://lists.openstack.org/pipermail/openstack'),('Neil.Tong@evault.com','http://lists.openstack.org/pipermail/openstack'),('nejc.saje@xlab.si','http://lists.openstack.org/pipermail/openstack'),('netmatters@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ng.tuna11@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nhanct92@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nick.veitch@canonical.com','http://lists.openstack.org/pipermail/openstack'),('nicolas.borboen@epfl.ch','http://lists.openstack.org/pipermail/openstack'),('nikeshmahalka@vedams.com','http://lists.openstack.org/pipermail/openstack'),('nikhil12sept@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nikolai.defigueiredo@netronome.com','http://lists.openstack.org/pipermail/openstack'),('nilesh56@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ning.sun@intel.com','http://lists.openstack.org/pipermail/openstack'),('nirlay@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('nishant.sgbk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nishant80@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('nishantkumar_2k@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('niteshselkari@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nkhare@redhat.com','http://lists.openstack.org/pipermail/openstack'),('nkinder@redhat.com','http://lists.openstack.org/pipermail/openstack'),('nmandya@gmail.com','http://lists.openstack.org/pipermail/openstack'),('noel@pistoncloud.com','http://lists.openstack.org/pipermail/openstack'),('noloader@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Nora.Zhou@harmonicinc.com','http://lists.openstack.org/pipermail/openstack'),('norbert@tretkowski.de','http://lists.openstack.org/pipermail/openstack'),('noreply+4220075950@badoo.com','http://lists.openstack.org/pipermail/openstack'),('notsu@virtualtech.jp','http://lists.openstack.org/pipermail/openstack'),('npajtic@gwcodnix.com','http://lists.openstack.org/pipermail/openstack'),('nprivalova@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('nspmangalore@gmail.com','http://lists.openstack.org/pipermail/openstack'),('nsv.shyam@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ntdeveloper2002@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('oakerz@lycos.com','http://lists.openstack.org/pipermail/openstack'),('obondarev@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('ogelbukh@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('ohadlevy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('oliver.leahy@hp.com','http://lists.openstack.org/pipermail/openstack'),('olivier.cant@exxoss.com','http://lists.openstack.org/pipermail/openstack'),('onlydebian@gmail.com','http://lists.openstack.org/pipermail/openstack'),('openstack2014@qq.com','http://lists.openstack.org/pipermail/openstack'),('openstack@detacloud.com','http://lists.openstack.org/pipermail/openstack'),('openstack@stellwag.net','http://lists.openstack.org/pipermail/openstack'),('openstack@yandex.ru','http://lists.openstack.org/pipermail/openstack'),('openstackleaner@gmail.com','http://lists.openstack.org/pipermail/openstack'),('openware.us@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ops@dnsbed.com','http://lists.openstack.org/pipermail/openstack'),('opst@tgndomains.com','http://lists.openstack.org/pipermail/openstack'),('ori.tzoran@tikalk.com','http://lists.openstack.org/pipermail/openstack'),('os@rok-kralj.net','http://lists.openstack.org/pipermail/openstack'),('ostck@gbif.org','http://lists.openstack.org/pipermail/openstack'),('otavio.augusto@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ouhsayn@gmail.com','http://lists.openstack.org/pipermail/openstack'),('p.raghuram@outlook.com','http://lists.openstack.org/pipermail/openstack'),('P@draigBrady.com','http://lists.openstack.org/pipermail/openstack'),('pa1975@gmail.com','http://lists.openstack.org/pipermail/openstack'),('palma.victor@gmail.com','http://lists.openstack.org/pipermail/openstack'),('palma@onesource.pt','http://lists.openstack.org/pipermail/openstack'),('panfy.fnst@cn.fujitsu.com','http://lists.openstack.org/pipermail/openstack'),('pangj@laposte.net','http://lists.openstack.org/pipermail/openstack'),('pannov.tsth@gmail.com','http://lists.openstack.org/pipermail/openstack'),('para.vikas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('parikshit.manur@citrix.com','http://lists.openstack.org/pipermail/openstack'),('parisa-2.heidari@polymtl.ca','http://lists.openstack.org/pipermail/openstack'),('parrott@g.harvard.edu','http://lists.openstack.org/pipermail/openstack'),('parthipan@hp.com','http://lists.openstack.org/pipermail/openstack'),('pasquier.simon@gmail.com','http://lists.openstack.org/pipermail/openstack'),('patg@patg.net','http://lists.openstack.org/pipermail/openstack'),('patnala003@gmail.com','http://lists.openstack.org/pipermail/openstack'),('patricia.gaughen@canonical.com','http://lists.openstack.org/pipermail/openstack'),('paul.belanger@polybeacon.com','http://lists.openstack.org/pipermail/openstack'),('paul.carlton2@hp.com','http://lists.openstack.org/pipermail/openstack'),('paul.e.luse@intel.com','http://lists.openstack.org/pipermail/openstack'),('Paul.Green@stratus.com','http://lists.openstack.org/pipermail/openstack'),('paul.mcmillan@nebula.com','http://lists.openstack.org/pipermail/openstack'),('paul@eventuallyanyway.com','http://lists.openstack.org/pipermail/openstack'),('pc2929@att.com','http://lists.openstack.org/pipermail/openstack'),('pc@pcable.net','http://lists.openstack.org/pipermail/openstack'),('pcm@cisco.com','http://lists.openstack.org/pipermail/openstack'),('pednape@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pedro.serotto@yahoo.es','http://lists.openstack.org/pipermail/openstack'),('pellaeon@hs.ntnu.edu.tw','http://lists.openstack.org/pipermail/openstack'),('penick@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('peter.a.portante@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Peter.J.Scott@jpl.nasa.gov','http://lists.openstack.org/pipermail/openstack'),('peter.vizard@free.fr','http://lists.openstack.org/pipermail/openstack'),('peter@gridcentric.ca','http://lists.openstack.org/pipermail/openstack'),('pf@artcom-gmbh.de','http://lists.openstack.org/pipermail/openstack'),('pguerin@sandvine.com','http://lists.openstack.org/pipermail/openstack'),('phamtungduong@gmail.com','http://lists.openstack.org/pipermail/openstack'),('phanibhushan.pv@gmail.com','http://lists.openstack.org/pipermail/openstack'),('philip.day@hp.com','http://lists.openstack.org/pipermail/openstack'),('philipp.marek@linbit.com','http://lists.openstack.org/pipermail/openstack'),('phucvd.ce@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pierre.pouzols@ense.co','http://lists.openstack.org/pipermail/openstack'),('pierre@gronau.it','http://lists.openstack.org/pipermail/openstack'),('pieter.koorts@me.com','http://lists.openstack.org/pipermail/openstack'),('piiv@zhaw.ch','http://lists.openstack.org/pipermail/openstack'),('pirate112358@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pkeogh@compusoftcs.com','http://lists.openstack.org/pipermail/openstack'),('pkopec17@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pkulkar@Brocade.com','http://lists.openstack.org/pipermail/openstack'),('placeoftheway@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pmasrani@vmware.com','http://lists.openstack.org/pipermail/openstack'),('porombka@uni-paderborn.de','http://lists.openstack.org/pipermail/openstack'),('postmaster.lists@gmail.com','http://lists.openstack.org/pipermail/openstack'),('powerds@gmail.com','http://lists.openstack.org/pipermail/openstack'),('powered.by.solaris@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ppnaik@cse.iitb.ac.in','http://lists.openstack.org/pipermail/openstack'),('prabhu.nk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pradeeptiwari.mca@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pradhanparas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('prag_2648@yahoo.co.in','http://lists.openstack.org/pipermail/openstack'),('pramodhp@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('Pranali.Deore@nttdata.com','http://lists.openstack.org/pipermail/openstack'),('pranav@aptira.com','http://lists.openstack.org/pipermail/openstack'),('praneshp@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('prao@prashanthrao.com','http://lists.openstack.org/pipermail/openstack'),('prashant.upadhyaya@aricent.com','http://lists.openstack.org/pipermail/openstack'),('prashanth.prahal@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pravar3088@gmail.com','http://lists.openstack.org/pipermail/openstack'),('preston@bannister.us','http://lists.openstack.org/pipermail/openstack'),('prisco.napoli@gmail.com','http://lists.openstack.org/pipermail/openstack'),('priti.sarap@gslab.com','http://lists.openstack.org/pipermail/openstack'),('Priti_Desai@symantec.com','http://lists.openstack.org/pipermail/openstack'),('pritkoth@cisco.com','http://lists.openstack.org/pipermail/openstack'),('pritpal@tech-guides.co.uk','http://lists.openstack.org/pipermail/openstack'),('priya_sharma@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('prometheanfire@gentoo.org','http://lists.openstack.org/pipermail/openstack'),('przemyslaw.czesnowicz@intel.com','http://lists.openstack.org/pipermail/openstack'),('pshchelokovskyy@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('pushpesh.eck@gmail.com','http://lists.openstack.org/pipermail/openstack'),('pvrsatya@gmail.com','http://lists.openstack.org/pipermail/openstack'),('qarham@gmail.com','http://lists.openstack.org/pipermail/openstack'),('qianlin1987@gmail.com','http://lists.openstack.org/pipermail/openstack'),('qiaoliyong@gmail.com','http://lists.openstack.org/pipermail/openstack'),('qixiaozhen@huawei.com','http://lists.openstack.org/pipermail/openstack'),('r-mibu@cq.jp.nec.com','http://lists.openstack.org/pipermail/openstack'),('r0j4z0@gmail.com','http://lists.openstack.org/pipermail/openstack'),('radek.skokan.conf@gmail.com','http://lists.openstack.org/pipermail/openstack'),('radek.smigielski@ymail.com','http://lists.openstack.org/pipermail/openstack'),('radek@gruchalski.com','http://lists.openstack.org/pipermail/openstack'),('radhakrishnan.mohan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('raf@io.com','http://lists.openstack.org/pipermail/openstack'),('rafalskiy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('raghavendra.lad@accenture.com','http://lists.openstack.org/pipermail/openstack'),('rahulsharmaait@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rajashree.thorat16@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rajdeep.dua@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rajshree.thorat@gslab.com','http://lists.openstack.org/pipermail/openstack'),('rajuvarghesek@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('rakatti@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rakesh.sinha@gslab.com','http://lists.openstack.org/pipermail/openstack'),('rakhmerov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('ram.nath241089@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ramon.acedo@canonical.com','http://lists.openstack.org/pipermail/openstack'),('ramon.acedo@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('ramon@linux-labs.net','http://lists.openstack.org/pipermail/openstack'),('rampras.vm@gmail.com','http://lists.openstack.org/pipermail/openstack'),('randall.burt@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('randy.krenz@overturenetworks.com','http://lists.openstack.org/pipermail/openstack'),('ranjit.sastra@gmail.com','http://lists.openstack.org/pipermail/openstack'),('raodingyuan@chinacloud.com.cn','http://lists.openstack.org/pipermail/openstack'),('raphaelpr01@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rashg164@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rauf.malik@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ravikumar.venkatesan@hp.com','http://lists.openstack.org/pipermail/openstack'),('ravitanwar@indivar.com','http://lists.openstack.org/pipermail/openstack'),('ray.wang@canonical.com','http://lists.openstack.org/pipermail/openstack'),('raytrac3r@gmail.com','http://lists.openstack.org/pipermail/openstack'),('razique.mahroua@clouditcanada.com','http://lists.openstack.org/pipermail/openstack'),('razique.mahroua@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rcritten@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rdekel@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rellerreller@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('Remo@italy1.com','http://lists.openstack.org/pipermail/openstack'),('remo@mattei.org','http://lists.openstack.org/pipermail/openstack'),('remo@remomattei.com','http://lists.openstack.org/pipermail/openstack'),('rerngvit@n3infinity.com','http://lists.openstack.org/pipermail/openstack'),('retinara@seznam.cz','http://lists.openstack.org/pipermail/openstack'),('reza.b2008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rgbkrk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rggg88@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('rhedlind@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ribozyme847@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ricardo.carrillo.cruz@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Richard.Cunningham@JCDecaux.co.uk','http://lists.openstack.org/pipermail/openstack'),('richard.li@intel.com','http://lists.openstack.org/pipermail/openstack'),('richard.maynard@gmail.com','http://lists.openstack.org/pipermail/openstack'),('richard@raseley.com','http://lists.openstack.org/pipermail/openstack'),('rick.jones2@hp.com','http://lists.openstack.org/pipermail/openstack'),('ricky@cloudera.com','http://lists.openstack.org/pipermail/openstack'),('rima.grati@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rimc@zhaw.ch','http://lists.openstack.org/pipermail/openstack'),('riontel@gmail.com','http://lists.openstack.org/pipermail/openstack'),('riteshnanda09@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rjones@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rkamaldinov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('rkayyar@lcnpl.com','http://lists.openstack.org/pipermail/openstack'),('rkukura@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/openstack'),('rlucio@vmem.com','http://lists.openstack.org/pipermail/openstack'),('rmm0811@gmail.com','http://lists.openstack.org/pipermail/openstack'),('roastedseaweed.k@gmail.com','http://lists.openstack.org/pipermail/openstack'),('robberphex@gmail.com','http://lists.openstack.org/pipermail/openstack'),('robert.clark@hp.com','http://lists.openstack.org/pipermail/openstack'),('Robert.Mengert@charter.com','http://lists.openstack.org/pipermail/openstack'),('Robert.vanLeeuwen@spilgames.com','http://lists.openstack.org/pipermail/openstack'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack'),('roberto@unbit.it','http://lists.openstack.org/pipermail/openstack'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/openstack'),('roccas@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rohara@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rolphd@amgen.com','http://lists.openstack.org/pipermail/openstack'),('Romain.ZIBA@eurogiciel.fr','http://lists.openstack.org/pipermail/openstack'),('romain.ziba@gmail.com','http://lists.openstack.org/pipermail/openstack'),('roman.mashak@gmail.com','http://lists.openstack.org/pipermail/openstack'),('romilgupta19@gmail.com','http://lists.openstack.org/pipermail/openstack'),('romizhang1968@163.com','http://lists.openstack.org/pipermail/openstack'),('RONENKAT@il.ibm.com','http://lists.openstack.org/pipermail/openstack'),('rony.kris@gmail.com','http://lists.openstack.org/pipermail/openstack'),('roozbeh.shafiee@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Ross.Lillie@motorolasolutions.com','http://lists.openstack.org/pipermail/openstack'),('rpodolyaka@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('rrrangrej@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('rrs@researchut.com','http://lists.openstack.org/pipermail/openstack'),('rsamprat@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rsokolkov@gmail.com','http://lists.openstack.org/pipermail/openstack'),('rudrajit.tapadar+osgen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ruediger.rissmann@switch.ch','http://lists.openstack.org/pipermail/openstack'),('rupadhayay@xavient.com','http://lists.openstack.org/pipermail/openstack'),('rvaknin@redhat.com','http://lists.openstack.org/pipermail/openstack'),('rvatspacket@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sachi.king@anchor.com.au','http://lists.openstack.org/pipermail/openstack'),('sahid.ferdjaoui@cloudwatt.com','http://lists.openstack.org/pipermail/openstack'),('sairam.mp@freescale.com','http://lists.openstack.org/pipermail/openstack'),('sajhak@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sajuptpm@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sakamoto.asami@nttcom.co.jp','http://lists.openstack.org/pipermail/openstack'),('salehi1994@gmail.com','http://lists.openstack.org/pipermail/openstack'),('salut@mariuss.net','http://lists.openstack.org/pipermail/openstack'),('salvorapi@yahoo.it','http://lists.openstack.org/pipermail/openstack'),('sam@swiftstack.com','http://lists.openstack.org/pipermail/openstack'),('samba.diop@nagra.com','http://lists.openstack.org/pipermail/openstack'),('sameidea@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sammiestoel@gmail.com','http://lists.openstack.org/pipermail/openstack'),('samu60@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sandeep.raman@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sandhya.ganapathy@hp.com','http://lists.openstack.org/pipermail/openstack'),('sandy.walsh@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('sangh.2014@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sania.sharma9727@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sanjivininaikar@tataelxsi.co.in','http://lists.openstack.org/pipermail/openstack'),('santiago.b.baldassin@intel.com','http://lists.openstack.org/pipermail/openstack'),('sarah.a180@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sarah@fm.secret.jp','http://lists.openstack.org/pipermail/openstack'),('sascha.vogt@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Sateesh_Kumar@mindtree.com','http://lists.openstack.org/pipermail/openstack'),('sathyanarayana.pvr@tcs.com','http://lists.openstack.org/pipermail/openstack'),('satroutr@cisco.com','http://lists.openstack.org/pipermail/openstack'),('saurabh.ag82@gmail.com','http://lists.openstack.org/pipermail/openstack'),('saurabh.b.agarwal@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('sayaji15@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sayali.92720@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sbaker@redhat.com','http://lists.openstack.org/pipermail/openstack'),('sbalukoff@bluebox.net','http://lists.openstack.org/pipermail/openstack'),('sbauza@redhat.com','http://lists.openstack.org/pipermail/openstack'),('sbhosale@in.ibm.com','http://lists.openstack.org/pipermail/openstack'),('scheuran@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('scott.lowe@scottlowe.org','http://lists.openstack.org/pipermail/openstack'),('scottsanchez@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sdainard@miovision.com','http://lists.openstack.org/pipermail/openstack'),('sdake@redhat.com','http://lists.openstack.org/pipermail/openstack'),('sdj@rasmussenequipment.com','http://lists.openstack.org/pipermail/openstack'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack'),('seanmann4000@gmail.com','http://lists.openstack.org/pipermail/openstack'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('seanroberts66@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sean_mccully@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('sebastian.herzberg@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sebastien.han@enovance.com','http://lists.openstack.org/pipermail/openstack'),('sekharv01@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sequel@neofreak.org','http://lists.openstack.org/pipermail/openstack'),('Sergey.Gomanyuk@amdocs.com','http://lists.openstack.org/pipermail/openstack'),('sergio.maffioletti@gc3.uzh.ch','http://lists.openstack.org/pipermail/openstack'),('sertdemiry@hotmail.com','http://lists.openstack.org/pipermail/openstack'),('serverascode@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sg@vinci-it.com','http://lists.openstack.org/pipermail/openstack'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/openstack'),('shafiee01@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shaibn@liveperson.com','http://lists.openstack.org/pipermail/openstack'),('shailrishabh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shake.chen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Shakirov.Aynur@cg.ru','http://lists.openstack.org/pipermail/openstack'),('Shane_Gibson@symantec.com','http://lists.openstack.org/pipermail/openstack'),('shanthakumar.k@hp.com','http://lists.openstack.org/pipermail/openstack'),('sharan.monikantan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shardy@redhat.com','http://lists.openstack.org/pipermail/openstack'),('shay.asher1@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shayne.alone@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sheeprine@nullplace.com','http://lists.openstack.org/pipermail/openstack'),('shengjie.min@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shenwei9008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shepelev.artem@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shida@intellilink.co.jp','http://lists.openstack.org/pipermail/openstack'),('shinobu.kinjo@oist.jp','http://lists.openstack.org/pipermail/openstack'),('shital.patil@gslab.com','http://lists.openstack.org/pipermail/openstack'),('shmughal@cisco.com','http://lists.openstack.org/pipermail/openstack'),('shohel_csdu@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('shoujinwang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shraddha.pandhe@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('shrinand@maginatics.com','http://lists.openstack.org/pipermail/openstack'),('shuichiro.makigaki@gmail.com','http://lists.openstack.org/pipermail/openstack'),('shuo.yang@huawei.com','http://lists.openstack.org/pipermail/openstack'),('siamak.azodolmolky@gmail.com','http://lists.openstack.org/pipermail/openstack'),('silversurfer972@gmail.com','http://lists.openstack.org/pipermail/openstack'),('simon.pasquier@bull.net','http://lists.openstack.org/pipermail/openstack'),('simon@mccartney.ie','http://lists.openstack.org/pipermail/openstack'),('sindhusha.yadavalli@students.iiit.ac.in','http://lists.openstack.org/pipermail/openstack'),('Sirisha_Devineni@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('sirushti.murugesan@hp.com','http://lists.openstack.org/pipermail/openstack'),('skanagasabap@gmail.com','http://lists.openstack.org/pipermail/openstack'),('skazix.git@gmail.com','http://lists.openstack.org/pipermail/openstack'),('skmp81@gmail.com','http://lists.openstack.org/pipermail/openstack'),('skolekonov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('skotzko@sbcglobal.net','http://lists.openstack.org/pipermail/openstack'),('skywalker.nick@gmail.com','http://lists.openstack.org/pipermail/openstack'),('slawek@kaplonski.pl','http://lists.openstack.org/pipermail/openstack'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('smayer69@me.com','http://lists.openstack.org/pipermail/openstack'),('smoser@ubuntu.com','http://lists.openstack.org/pipermail/openstack'),('smwood4@gmail.com','http://lists.openstack.org/pipermail/openstack'),('snake@snake.org.ua','http://lists.openstack.org/pipermail/openstack'),('sngirame@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('softded@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sombrafam@gmail.com','http://lists.openstack.org/pipermail/openstack'),('som_kadam@yahoo.co.in','http://lists.openstack.org/pipermail/openstack'),('soniaverma9727@gmail.com','http://lists.openstack.org/pipermail/openstack'),('soren@linux2go.dk','http://lists.openstack.org/pipermail/openstack'),('sorlando@nicira.com','http://lists.openstack.org/pipermail/openstack'),('sorrison@gmail.com','http://lists.openstack.org/pipermail/openstack'),('soumaya.almorabeti@gmail.com','http://lists.openstack.org/pipermail/openstack'),('souminathan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('spidersddd@gmail.com','http://lists.openstack.org/pipermail/openstack'),('spiros.michelakis@nsn.com','http://lists.openstack.org/pipermail/openstack'),('spring1201@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sputnik13@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sragolu@mvista.com','http://lists.openstack.org/pipermail/openstack'),('sravani.madireddy14@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sridhar.gaddam@enovance.com','http://lists.openstack.org/pipermail/openstack'),('srikanth.lingala@freescale.com','http://lists.openstack.org/pipermail/openstack'),('srinduvai@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('srinivasreddy4390@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sriram@sriramhere.com','http://lists.openstack.org/pipermail/openstack'),('srujana_cp@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('ssevertson@digitalmeasures.com','http://lists.openstack.org/pipermail/openstack'),('sshimpi@expedia.com','http://lists.openstack.org/pipermail/openstack'),('sskripnick@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('sstrato.kong@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stackeratul@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stano@websupport.sk','http://lists.openstack.org/pipermail/openstack'),('starlight@snow.plala.or.jp','http://lists.openstack.org/pipermail/openstack'),('stefan.walter@inf.ethz.ch','http://lists.openstack.org/pipermail/openstack'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack'),('stephane.albert@objectif-libre.com','http://lists.openstack.org/pipermail/openstack'),('stephane.eveillard@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stephen.halpin@hp.com','http://lists.openstack.org/pipermail/openstack'),('stephen.l.blinick@intel.com','http://lists.openstack.org/pipermail/openstack'),('Stephen_Friday@DELL.com','http://lists.openstack.org/pipermail/openstack'),('steve.heistand@nasa.gov','http://lists.openstack.org/pipermail/openstack'),('steve@base-it.co.uk','http://lists.openstack.org/pipermail/openstack'),('steveisoft@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stevemar@ca.ibm.com','http://lists.openstack.org/pipermail/openstack'),('stevenca@cisco.com','http://lists.openstack.org/pipermail/openstack'),('stever@up-south.com','http://lists.openstack.org/pipermail/openstack'),('steveum0105@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stone_an@163.com','http://lists.openstack.org/pipermail/openstack'),('strangerthanbland@gmail.com','http://lists.openstack.org/pipermail/openstack'),('stuart.mclaren@hp.com','http://lists.openstack.org/pipermail/openstack'),('stuartl@vrt.com.au','http://lists.openstack.org/pipermail/openstack'),('subbu@subbu.org','http://lists.openstack.org/pipermail/openstack'),('subhajitc@tislabs.in','http://lists.openstack.org/pipermail/openstack'),('subramanian.neelakantan@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sudhakar.gariganti@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sumitkgaur@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sumitnaiksatam@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sungju.kwon@gmail.com','http://lists.openstack.org/pipermail/openstack'),('surit.killer@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sushma_korati@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('susltd.su@gmail.com','http://lists.openstack.org/pipermail/openstack'),('svenphx@gmail.com','http://lists.openstack.org/pipermail/openstack'),('swapnilkulkarni2608@gmail.com','http://lists.openstack.org/pipermail/openstack'),('swapnil_khanapurkar@persistent.co.in','http://lists.openstack.org/pipermail/openstack'),('swiftops@bigmir.net','http://lists.openstack.org/pipermail/openstack'),('sxmatch1986@gmail.com','http://lists.openstack.org/pipermail/openstack'),('syed.armani@hastexo.com','http://lists.openstack.org/pipermail/openstack'),('Syedhabib.Siddikali@csscorp.com','http://lists.openstack.org/pipermail/openstack'),('sylecn@gmail.com','http://lists.openstack.org/pipermail/openstack'),('sylvain.bauza@bull.net','http://lists.openstack.org/pipermail/openstack'),('sysops@mail2000.us','http://lists.openstack.org/pipermail/openstack'),('t22330033@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tamasb@nikhef.nl','http://lists.openstack.org/pipermail/openstack'),('tangyi@kingsoft.com','http://lists.openstack.org/pipermail/openstack'),('tao.a.zhou@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack'),('taras.shapovalov@brightcomputing.com','http://lists.openstack.org/pipermail/openstack'),('tarkan.erimer@f-secure.com','http://lists.openstack.org/pipermail/openstack'),('tbe@atolcd.com','http://lists.openstack.org/pipermail/openstack'),('tcvn1985@gmail.com','http://lists.openstack.org/pipermail/openstack'),('telekomunikacije@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tengqim@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack'),('teolupus.ext@gmail.com','http://lists.openstack.org/pipermail/openstack'),('terbolous@gmail.com','http://lists.openstack.org/pipermail/openstack'),('terri@terriyu.info','http://lists.openstack.org/pipermail/openstack'),('tetsuya.sodo@hp.com','http://lists.openstack.org/pipermail/openstack'),('teun.docter@brightcomputing.com','http://lists.openstack.org/pipermail/openstack'),('thakkarjanak@live.com','http://lists.openstack.org/pipermail/openstack'),('thang.g.pham@gmail.com','http://lists.openstack.org/pipermail/openstack'),('thanukrishnamurthy.madhusudha@oracle.com','http://lists.openstack.org/pipermail/openstack'),('thefossgeek@gmail.com','http://lists.openstack.org/pipermail/openstack'),('themadengin33r@gmail.com','http://lists.openstack.org/pipermail/openstack'),('theresa.huth@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack'),('therese.persson@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('thiagocmartinsc@gmail.com','http://lists.openstack.org/pipermail/openstack'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack'),('thingee@gmail.com','http://lists.openstack.org/pipermail/openstack'),('thistlesl@aol.com','http://lists.openstack.org/pipermail/openstack'),('thomas.spatzier@de.ibm.com','http://lists.openstack.org/pipermail/openstack'),('Thomas.Stinner@schweickertgruppe.de','http://lists.openstack.org/pipermail/openstack'),('thomas@goirand.fr','http://lists.openstack.org/pipermail/openstack'),('thomas@redhat.com','http://lists.openstack.org/pipermail/openstack'),('thomasth@google.com','http://lists.openstack.org/pipermail/openstack'),('thor@wolpert.ca','http://lists.openstack.org/pipermail/openstack'),('thorfinn@poivron.org','http://lists.openstack.org/pipermail/openstack'),('thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tiagu.asp@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tianzhenhua@huawei.com','http://lists.openstack.org/pipermail/openstack'),('tiffany.j.mathews@nasa.gov','http://lists.openstack.org/pipermail/openstack'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack'),('Tim.Snider@netapp.com','http://lists.openstack.org/pipermail/openstack'),('timon86.wang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tkawano@cloudian.com','http://lists.openstack.org/pipermail/openstack'),('tmmoore@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('tmukharj@cisco.com','http://lists.openstack.org/pipermail/openstack'),('toan.ngo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('todd@toddmorey.com','http://lists.openstack.org/pipermail/openstack'),('tom.cammann@hp.com','http://lists.openstack.org/pipermail/openstack'),('Tom.Hancock@hp.com','http://lists.openstack.org/pipermail/openstack'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack'),('tom@server.biz','http://lists.openstack.org/pipermail/openstack'),('tom@tomverdaat.com','http://lists.openstack.org/pipermail/openstack'),('tom@verdaat.org','http://lists.openstack.org/pipermail/openstack'),('tomo@dream.daynight.jp','http://lists.openstack.org/pipermail/openstack'),('tomokazu.hirai@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tomoya.goto@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack'),('tongkai@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('toni.fuentes@ackstorm.es','http://lists.openstack.org/pipermail/openstack'),('tony@bakeyournoodle.com','http://lists.openstack.org/pipermail/openstack'),('tonytkdk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tpiperatgod@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tqtran@us.ibm.com','http://lists.openstack.org/pipermail/openstack'),('traiano@gmail.com','http://lists.openstack.org/pipermail/openstack'),('trapni@gmail.com','http://lists.openstack.org/pipermail/openstack'),('trinath.somanchi@freescale.com','http://lists.openstack.org/pipermail/openstack'),('tristan.cacqueray@enovance.com','http://lists.openstack.org/pipermail/openstack'),('tristan@aptira.com','http://lists.openstack.org/pipermail/openstack'),('troy@tomanator.com','http://lists.openstack.org/pipermail/openstack'),('tshefi@redhat.com','http://lists.openstack.org/pipermail/openstack'),('tsierkkis@gmail.com','http://lists.openstack.org/pipermail/openstack'),('tsufiev@mirantis.com','http://lists.openstack.org/pipermail/openstack'),('tuantb@vccloud.vn','http://lists.openstack.org/pipermail/openstack'),('tuanvc@vccloud.vn','http://lists.openstack.org/pipermail/openstack'),('tudor@tudorholton.com','http://lists.openstack.org/pipermail/openstack'),('tushar.katarki@percona.com','http://lists.openstack.org/pipermail/openstack'),('Tushar.Patil@nttdata.com','http://lists.openstack.org/pipermail/openstack'),('tushar.vengurlekar@hp.com','http://lists.openstack.org/pipermail/openstack'),('twilson@redhat.com','http://lists.openstack.org/pipermail/openstack'),('tyanqun@qq.com','http://lists.openstack.org/pipermail/openstack'),('tyky72@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ubuntu@shadowprojects.org','http://lists.openstack.org/pipermail/openstack'),('udaraliyanage@gmail.com','http://lists.openstack.org/pipermail/openstack'),('umbertoeklat@gmail.com','http://lists.openstack.org/pipermail/openstack'),('umesh.sahoo@pramati.com','http://lists.openstack.org/pipermail/openstack'),('unicell@gmail.com','http://lists.openstack.org/pipermail/openstack'),('unix.co@gmail.com','http://lists.openstack.org/pipermail/openstack'),('upendrasahu20@gmail.com','http://lists.openstack.org/pipermail/openstack'),('uwe.sauter.de@gmail.com','http://lists.openstack.org/pipermail/openstack'),('varun292006@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vbannai@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vedlad@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vedsarkushwaha@gmail.com','http://lists.openstack.org/pipermail/openstack'),('veera.reddy@freescale.com','http://lists.openstack.org/pipermail/openstack'),('veeraready@gmail.com','http://lists.openstack.org/pipermail/openstack'),('venu.murthy@thoughtworks.com','http://lists.openstack.org/pipermail/openstack'),('venum@thoughtworks.com','http://lists.openstack.org/pipermail/openstack'),('veronica.a.musso@intel.com','http://lists.openstack.org/pipermail/openstack'),('vicky.pawar@gmail.com','http://lists.openstack.org/pipermail/openstack'),('victor.rodionov@nexenta.com','http://lists.openstack.org/pipermail/openstack'),('victoria@vmartinezdelacruz.com','http://lists.openstack.org/pipermail/openstack'),('VictorMRuizS@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vijayabhaskar@sparksupport.com','http://lists.openstack.org/pipermail/openstack'),('vijaykakkars@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vikas.parashar@fosteringlinux.com','http://lists.openstack.org/pipermail/openstack'),('vikash.kumar@oneconvergence.com','http://lists.openstack.org/pipermail/openstack'),('vikaskokare@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vill.srk@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vilobhmm@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack'),('vimal7370@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vinay@avasthi.com','http://lists.openstack.org/pipermail/openstack'),('vinayak.shinde@clogeny.com','http://lists.openstack.org/pipermail/openstack'),('vinayvenkat@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vinc.pii@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vinod.kumar.boppanna@cern.ch','http://lists.openstack.org/pipermail/openstack'),('vipuls@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vishal2.agarwal@aricent.com','http://lists.openstack.org/pipermail/openstack'),('vishalkanaujia@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vitas.yuzhou@foxmail.com','http://lists.openstack.org/pipermail/openstack'),('vitas.yuzhou@huawei.com','http://lists.openstack.org/pipermail/openstack'),('vivekanandan.narasimhan@hp.com','http://lists.openstack.org/pipermail/openstack'),('vivekcherian@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vmtrooper@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vogl@adesso-mobile.de','http://lists.openstack.org/pipermail/openstack'),('vonpupp@gmail.com','http://lists.openstack.org/pipermail/openstack'),('vsekar@live.in','http://lists.openstack.org/pipermail/openstack'),('w.wanghong1@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wahajali@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wakingdreamerfhx@gmail.com','http://lists.openstack.org/pipermail/openstack'),('walterxj@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wanghao.buaa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wanghao749@huawei.com','http://lists.openstack.org/pipermail/openstack'),('wangxuepo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wantwatering@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wanxili@gmail.com','http://lists.openstack.org/pipermail/openstack'),('waqas.riaz@xflowresearch.com','http://lists.openstack.org/pipermail/openstack'),('wayne@openstack.org','http://lists.openstack.org/pipermail/openstack'),('wbaoping0704@163.com','http://lists.openstack.org/pipermail/openstack'),('wdunn@mailtrust.com','http://lists.openstack.org/pipermail/openstack'),('webcokies@yahoo.com','http://lists.openstack.org/pipermail/openstack'),('weiler@soe.ucsc.edu','http://lists.openstack.org/pipermail/openstack'),('weirdbluelights@gmail.com','http://lists.openstack.org/pipermail/openstack'),('weiyuanke123@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wilence.yao@gmail.com','http://lists.openstack.org/pipermail/openstack'),('willierjyt@gmail.com','http://lists.openstack.org/pipermail/openstack'),('willowd878@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wingwj@gmail.com','http://lists.openstack.org/pipermail/openstack'),('winston.d@gmail.com','http://lists.openstack.org/pipermail/openstack'),('wolf@cs.cmu.edu','http://lists.openstack.org/pipermail/openstack'),('wongahshuen@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Wyllys.Ingersoll@evault.com','http://lists.openstack.org/pipermail/openstack'),('wzssyqa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xavpaice@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xchenum@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xianbinxie@163.com','http://lists.openstack.org/pipermail/openstack'),('xiaohanyu1988@gmail.com','http://lists.openstack.org/pipermail/openstack'),('Xiaohong.Qin@emc.com','http://lists.openstack.org/pipermail/openstack'),('xiaohui.xin@intel.com','http://lists.openstack.org/pipermail/openstack'),('xiaoquqi@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xiaoyang.yu@saiway.com.cn','http://lists.openstack.org/pipermail/openstack'),('Xicheng.Chang@huawei.com','http://lists.openstack.org/pipermail/openstack'),('xicoloco@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xin.e.liu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xing.yang@emc.com','http://lists.openstack.org/pipermail/openstack'),('xingchao@unitedstack.com','http://lists.openstack.org/pipermail/openstack'),('xisisu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xizhendu@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xmodulo@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xnull@opensuse.org','http://lists.openstack.org/pipermail/openstack'),('xudi@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('xyzjerry@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xzhao87@gmail.com','http://lists.openstack.org/pipermail/openstack'),('xzhao@bnl.gov','http://lists.openstack.org/pipermail/openstack'),('yagmur@pistoncloud.com','http://lists.openstack.org/pipermail/openstack'),('yaguang.wang@intel.com','http://lists.openstack.org/pipermail/openstack'),('yalla.gnan.kumar@accenture.com','http://lists.openstack.org/pipermail/openstack'),('yamashita@ossl.co.jp','http://lists.openstack.org/pipermail/openstack'),('yanchao727@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yangbaohua@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yanghq@neusoft.com','http://lists.openstack.org/pipermail/openstack'),('yankai.liu@canonical.com','http://lists.openstack.org/pipermail/openstack'),('yannick.foeillet@alterway.fr','http://lists.openstack.org/pipermail/openstack'),('yaoheling@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yard.kam@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yasithucsc@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yatinkumbhare@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ybrodskiy@gmail.com','http://lists.openstack.org/pipermail/openstack'),('ye-hong.fang@hp.com','http://lists.openstack.org/pipermail/openstack'),('ye.a.yuan@intel.com','http://lists.openstack.org/pipermail/openstack'),('Yehia.Beyh@hp.com','http://lists.openstack.org/pipermail/openstack'),('yeluaiesec@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yeuleon@qq.com','http://lists.openstack.org/pipermail/openstack'),('yexianyi@sina.com','http://lists.openstack.org/pipermail/openstack'),('yige2008123@126.com','http://lists.openstack.org/pipermail/openstack'),('yin.zhb@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yipwp@comp.nus.edu.sg','http://lists.openstack.org/pipermail/openstack'),('yj.yuan@huawei.com','http://lists.openstack.org/pipermail/openstack'),('ykaneko0929@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yogeshg1987@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yongiman@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yuan.zhou@intel.com','http://lists.openstack.org/pipermail/openstack'),('yuanpu@139.com','http://lists.openstack.org/pipermail/openstack'),('Yuling_C@DELL.com','http://lists.openstack.org/pipermail/openstack'),('yulli77@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yunhong.jiang@intel.com','http://lists.openstack.org/pipermail/openstack'),('Yuriy.Babenko@telekom.de','http://lists.openstack.org/pipermail/openstack'),('yuxin.zhuang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('yuxingw@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('yuyangbj@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('zabolzadeh@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zaitcev@redhat.com','http://lists.openstack.org/pipermail/openstack'),('zakaria.amine88@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zaknafein.lee@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zarnovican@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zaryan2905@live.com','http://lists.openstack.org/pipermail/openstack'),('zashah@kth.se','http://lists.openstack.org/pipermail/openstack'),('zashah@pdc.kth.se','http://lists.openstack.org/pipermail/openstack'),('zbitter@redhat.com','http://lists.openstack.org/pipermail/openstack'),('zebra.x0r@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zengshan2008@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhang.hare@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhang.lei.fly@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhangjinnan87@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhangjl@awcloud.com','http://lists.openstack.org/pipermail/openstack'),('zhangleiqiang@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhangleiqiang@huawei.com','http://lists.openstack.org/pipermail/openstack'),('zhangxiaolins@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhangyanzi@huawei.com','http://lists.openstack.org/pipermail/openstack'),('zhchaobeyond@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhengguangou@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zhichengli@zju.edu.cn','http://lists.openstack.org/pipermail/openstack'),('zhongjj@foxmail.com','http://lists.openstack.org/pipermail/openstack'),('zhuadl@cn.ibm.com','http://lists.openstack.org/pipermail/openstack'),('zoltan.lajos.kis@ericsson.com','http://lists.openstack.org/pipermail/openstack'),('zou.yun@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack'),('zozo@z0z0.tk','http://lists.openstack.org/pipermail/openstack'),('zsun@fedoraproject.org','http://lists.openstack.org/pipermail/openstack'),('zwlu@ucdavis.edu','http://lists.openstack.org/pipermail/openstack'),('zym0017d@gmail.com','http://lists.openstack.org/pipermail/openstack'),('zzzz88.aaaa@gmail.com','http://lists.openstack.org/pipermail/openstack'),('adamg@canonical.com','http://lists.openstack.org/pipermail/openstack-announce'),('adamg@ubuntu.com','http://lists.openstack.org/pipermail/openstack-announce'),('anne.gentle@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-announce'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-announce'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack-announce'),('bogaard@nlcom.nl','http://lists.openstack.org/pipermail/openstack-announce'),('chuck.short@canonical.com','http://lists.openstack.org/pipermail/openstack-announce'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-announce'),('gmurphy@redhat.com','http://lists.openstack.org/pipermail/openstack-announce'),('grant.murphy@hp.com','http://lists.openstack.org/pipermail/openstack-announce'),('jeremy@openstack.org','http://lists.openstack.org/pipermail/openstack-announce'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-announce'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-announce'),('me@not.mn','http://lists.openstack.org/pipermail/openstack-announce'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-announce'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack-announce'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-announce'),('sbaker@redhat.com','http://lists.openstack.org/pipermail/openstack-announce'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-announce'),('stephen.spector@openstack.org','http://lists.openstack.org/pipermail/openstack-announce'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack-announce'),('tristan.cacqueray@enovance.com','http://lists.openstack.org/pipermail/openstack-announce'),('11msccssbashir@seecs.edu.pk','http://lists.openstack.org/pipermail/openstack-dev'),('128openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('12msccsnahmad@seecs.edu.pk','http://lists.openstack.org/pipermail/openstack-dev'),('13681114606@139.com','http://lists.openstack.org/pipermail/openstack-dev'),('14050403@cnsuning.com','http://lists.openstack.org/pipermail/openstack-dev'),('314631691@qq.com','http://lists.openstack.org/pipermail/openstack-dev'),('49047970@qq.com','http://lists.openstack.org/pipermail/openstack-dev'),('50barca@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aarti.kriplani@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('aashaikh@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('aayushu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('AB0078468@TechMahindra.com','http://lists.openstack.org/pipermail/openstack-dev'),('abartlet@samba.org','http://lists.openstack.org/pipermail/openstack-dev'),('abbasakbar@hushmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('abbass.marouni@virtualscale.fr','http://lists.openstack.org/pipermail/openstack-dev'),('abblly.daniel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('abeekhof@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhijeet.jain@nectechnologies.in','http://lists.openstack.org/pipermail/openstack-dev'),('Abhijeet.Malawade@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('Abhishek.Kekane@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhishek.lekshmanan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhishek.lists@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhishek.talwar@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhishek@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('abhraut@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('abmargb@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('abogott@wikimedia.org','http://lists.openstack.org/pipermail/openstack-dev'),('absubram@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('academicgareth@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('acharyashailendra1@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('achudnovets@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('achuprin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('adalbas@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('adam.harwell@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('adam@kili.io','http://lists.openstack.org/pipermail/openstack-dev'),('adam@younglogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('adamg@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('adamg@ubuntu.com','http://lists.openstack.org/pipermail/openstack-dev'),('adanin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('adidenko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('adin@scannell.ca','http://lists.openstack.org/pipermail/openstack-dev'),('aditirav@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('aditya.thatte8@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('adjustmadi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('adolphxueyan@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('adrian.hoban@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('adrian.otto@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('adrian.rosello@i2cat.net','http://lists.openstack.org/pipermail/openstack-dev'),('adrian@17od.com','http://lists.openstack.org/pipermail/openstack-dev'),('adriant@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-dev'),('adrian_f_smith@dell.com','http://lists.openstack.org/pipermail/openstack-dev'),('adrien@adriencunin.fr','http://lists.openstack.org/pipermail/openstack-dev'),('adyv_adyv@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('aeghtesadi@inocybe.ca','http://lists.openstack.org/pipermail/openstack-dev'),('aepifanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('afazekas@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('afe.young@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('afedorova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('afef.mdhaffar@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('afreedland@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('agamal@itsyn.com','http://lists.openstack.org/pipermail/openstack-dev'),('agarwalnisha1980@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('agordeev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('agorodnev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('agregc@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('agrover@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ahabib.j@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ahrytskiv@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aignatov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('aikawa@mxk.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('aj@dneg.com','http://lists.openstack.org/pipermail/openstack-dev'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('ajayhn@contrailsystems.com','http://lists.openstack.org/pipermail/openstack-dev'),('aji.zqfan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ajku.agr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ajmiller@ajmiller.net','http://lists.openstack.org/pipermail/openstack-dev'),('akalambu@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('akamyshnikova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('akarpinska@griddynamics.com','http://lists.openstack.org/pipermail/openstack-dev'),('akasatkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('akasha.cheung@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('akashacn@icloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('akashg1611@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('akhils@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('akilesh1597@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('akirayoshiyama@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('akislitsky@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('akrivoka@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('akshik@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('akuno@lavabit.com','http://lists.openstack.org/pipermail/openstack-dev'),('akurilin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('akuznetsov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('akuznetsova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ala.rezmerita@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('alan.kavanagh@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('alan.sill@ttu.edu','http://lists.openstack.org/pipermail/openstack-dev'),('alatynskaya@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('alawson@aqorn.com','http://lists.openstack.org/pipermail/openstack-dev'),('alazarev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('albert.vico@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('alee@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('alegendre@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('Aleksei_Chuprin@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('aleonhardt.py@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alevine@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex.barclay@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex.gaynor@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Alex.Gosse@riverbed.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex.heneveld@cloudsoftcorp.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex.meade@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('Alex.Pecoraro@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex.wangyang@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('alex890714@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexander.vollschwitz@est.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('Alexander_Minakov@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexandre.viau@savoirfairelinux.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexandre7.decarvalho@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexei.kornienko@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexei.rudenko@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alexisl@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('alistair.coles@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('allan.metts@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('allison@lohutok.net','http://lists.openstack.org/pipermail/openstack-dev'),('aloga@ifca.unican.es','http://lists.openstack.org/pipermail/openstack-dev'),('alok.mohindra@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ALONMA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('alopgeek@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('alvaro.lopez.garcia@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('alvin@netvel.net','http://lists.openstack.org/pipermail/openstack-dev'),('alvise.dorigo@pd.infn.it','http://lists.openstack.org/pipermail/openstack-dev'),('amakarov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('amala.alungal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('amalaba@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('amank3107@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('amcreynolds@ebay.com','http://lists.openstack.org/pipermail/openstack-dev'),('amesserl@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('amigliaccio@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('amigliaccio@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('aminakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('amir.sadoughi@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('amit.das@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('amit.gandhi@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('amitpp23@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('amolsalunkhe19@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('amrith@tesora.com','http://lists.openstack.org/pipermail/openstack-dev'),('amuller@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('anant.patil@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('anant.techie@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('anaumchev@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('anbu@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('andersonvom@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('andersonvom@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('andi.abes@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('andre.f.aranha@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrea.frittoli@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrea.rosa@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Andreas.Scheuring@de.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('andres.buraschi@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('andreslc@gridcentric.ca','http://lists.openstack.org/pipermail/openstack-dev'),('Andrew.Kerr@netapp.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew.laski@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew.melton@mailtrust.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew.melton@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew.plunk@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('andrew@apmelton.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew@divvycloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('andrew@etc.gen.nz','http://lists.openstack.org/pipermail/openstack-dev'),('andrew@linuxjedi.co.uk','http://lists.openstack.org/pipermail/openstack-dev'),('Andrey_Ostapenko@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('andronat_asf@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('andymitrich@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('angelo.matarazzo@dektech.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('angeloudy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('angus.salkeld@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('aniket.k@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('anil.degwekar@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('anil.gunturu@riftio.com','http://lists.openstack.org/pipermail/openstack-dev'),('anil.rao@gigamon.com','http://lists.openstack.org/pipermail/openstack-dev'),('anil.venkata@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('aniruddha.gautam@aricent.com','http://lists.openstack.org/pipermail/openstack-dev'),('anish@chelsio.com','http://lists.openstack.org/pipermail/openstack-dev'),('anjaneya2@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Ankit11.Agrawal@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('ankit21.a@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('anlin.kong@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('annasort@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('anne.gentle@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('annegentle@justwriteclick.com','http://lists.openstack.org/pipermail/openstack-dev'),('annie.cheng.os@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-dev'),('Anthony_Veiga@cable.comcast.com','http://lists.openstack.org/pipermail/openstack-dev'),('anton.massoud@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('anusha.rayani@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('aovchinnikov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ap@pilotti.it','http://lists.openstack.org/pipermail/openstack-dev'),('apalanisamy@paypal.com','http://lists.openstack.org/pipermail/openstack-dev'),('aparna.cloud@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aparna@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('apashkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('apech@aristanetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('apilotti@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-dev'),('appleorchard2000@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('apxeng@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aradhanaad.conexant@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arahal@iweb.com','http://lists.openstack.org/pipermail/openstack-dev'),('arai@mxa.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('arash.ghoreyshi@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('arati.mahimane@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('ariel.zeitlin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arindam@live.com','http://lists.openstack.org/pipermail/openstack-dev'),('Arkady_Kanevsky@DELL.com','http://lists.openstack.org/pipermail/openstack-dev'),('armamig@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Arne.Wiebalck@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('aroostifer@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('arosen@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('artdream07@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arthur.lutz@logilab.fr','http://lists.openstack.org/pipermail/openstack-dev'),('arturo.era@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arun.kant@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('arunain@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arunkumar.achutha@opexlabs.com','http://lists.openstack.org/pipermail/openstack-dev'),('arvind.bernaulli@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('arvind.tiwari@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('arvtiwar@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('aryeh.friedman@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('asahlin@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('asalkeld@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('asalkeld@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ashestakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ashish.gec@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ashokkumaran.b@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ashujain9727@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('asklyankina@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('asomya@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('aspiers@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('Aswad.Rangnekar@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('athomas@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ativelkov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('Atul.Jha@csscorp.com','http://lists.openstack.org/pipermail/openstack-dev'),('augol@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('aurlapova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('aurynn@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-dev'),('aviostack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('AVISHAY@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('avishay@stratoscale.com','http://lists.openstack.org/pipermail/openstack-dev'),('AvishayB@Radware.com','http://lists.openstack.org/pipermail/openstack-dev'),('avolochay@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('awoodward@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ayip@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('ayoung@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ayshihanzhang@126.com','http://lists.openstack.org/pipermail/openstack-dev'),('azemlyanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('B22160@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('B37207@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('B37839@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('B39208@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('b@renski.com','http://lists.openstack.org/pipermail/openstack-dev'),('bageshree.lokare@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('baktha.sg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('balaji.iyer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Balaji.P@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('balamuruganvg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('balazs.gibizer@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('baoli@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('barrowkwan@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('bartosz.fic@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('bartosz.gorski@ntti3.com','http://lists.openstack.org/pipermail/openstack-dev'),('bartosz.gorski@nttmcl.com','http://lists.openstack.org/pipermail/openstack-dev'),('bbobrov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('bcline@softlayer.com','http://lists.openstack.org/pipermail/openstack-dev'),('bcwaldon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bdastur@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('bdelliott@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bdobrelia@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('bdpayne@acm.org','http://lists.openstack.org/pipermail/openstack-dev'),('beagles@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('bearovercloud@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bedis9@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ben.meyer@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('Ben.Swartzlander@netapp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ben@swartzlander.org','http://lists.openstack.org/pipermail/openstack-dev'),('benali@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('benjamin.grassart@thalesgroup.com','http://lists.openstack.org/pipermail/openstack-dev'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/openstack-dev'),('berrange@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('betsy.luzader@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('beyounn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bezborodovaam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bharat.kobagana@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('bharath_ves@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bhooshan.openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bhuvan@apache.org','http://lists.openstack.org/pipermail/openstack-dev'),('bi.yamagata@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bigzhao@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('Bill.Becker@safenet-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('billowen@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('billshetti@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bjzzu.zz@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bkupidura@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('blacker1981@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('blair.bethwaite@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('blak111@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('blake.yeager@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('blk@acm.org','http://lists.openstack.org/pipermail/openstack-dev'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bmelande@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('bobitanobi102@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('boden@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('bodenvmw@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bogorodskiy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('boh.ricky@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bohai@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('bops.91@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('boris@pavlovic.me','http://lists.openstack.org/pipermail/openstack-dev'),('boris@pavlovic.ru','http://lists.openstack.org/pipermail/openstack-dev'),('botemout@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bouzafr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('bozhu@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('bpavlovic@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('bpiotrowski@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('bpradipt@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('bradjone@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('Brad_Pokorny@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('brandon.logan@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('brantcarrey@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('brbowen@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('brent.roskos@solinea.com','http://lists.openstack.org/pipermail/openstack-dev'),('brents@activestate.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.c.thornock@seagate.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.curtin@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('brian.haley@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.lamar@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.luohao@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.rosmaita@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('brian.schott@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian.waldon@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('brian@python.org','http://lists.openstack.org/pipermail/openstack-dev'),('Brianna.Poulos@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('brooklyn.chen@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('browne@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('brownell@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Bruce.Benjamin@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('Bruce_Montague@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('bruno.bompastor@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('bruno.semperlotti@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('btdan@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('btopol@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('buccella@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('burgerk@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('burt@fnal.gov','http://lists.openstack.org/pipermail/openstack-dev'),('bywang98@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('caboucha@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('caedo@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('Caitlin.Bestler@nexenta.com','http://lists.openstack.org/pipermail/openstack-dev'),('caleb@calebgroom.com','http://lists.openstack.org/pipermail/openstack-dev'),('calfonso@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('Calum.Loudon@metaswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('caperry@edolnx.net','http://lists.openstack.org/pipermail/openstack-dev'),('carl.baldwin@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('carl@ecbaldwin.net','http://lists.openstack.org/pipermail/openstack-dev'),('carlos.garza@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('carol.l.barrett@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('Casper.a.Liu@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('castulo.martinez@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('Cathy.H.Zhang@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('cazzaniga.sandro@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cbehrens@codestud.com','http://lists.openstack.org/pipermail/openstack-dev'),('cbelu@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-dev'),('cbjchen@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('cbkyeoh@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cboylan@sapwetik.org','http://lists.openstack.org/pipermail/openstack-dev'),('ccoleman@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ccrouch@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ccuiyyan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cduryee@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('cedric.soulas@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('celttechie@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cfb@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('chabani.mohamed.hadi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chad.lung@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chamberk@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('chandanc@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('chandankumar.093047@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('changbin.liu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('changzhi1990@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chaochin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('charles.walker.37@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Charles_Wang@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('chayma87@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chdent@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('chen.li@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('chen.zheng@easystack.cn','http://lists.openstack.org/pipermail/openstack-dev'),('chengyuanli@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chenhaiq@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('chenk@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('chenrano2002@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chenrui.momo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chenxil@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('chhagarw@in.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('chhavi.kant@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('chieh.chu@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chinasubbareddy_m@persistent.com','http://lists.openstack.org/pipermail/openstack-dev'),('chipahuac@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chmouel@chmouel.com','http://lists.openstack.org/pipermail/openstack-dev'),('chmouel@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('chris.a.st.pierre@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chris.armstrong@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('chris.buccella@antallagon.com','http://lists.openstack.org/pipermail/openstack-dev'),('chris.friesen@windriver.com','http://lists.openstack.org/pipermail/openstack-dev'),('chrisfer@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('christian.maciocco@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('christian.martinez@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('christian.schwede@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('christophe.sauthier@objectif-libre.com','http://lists.openstack.org/pipermail/openstack-dev'),('christopher.lefelhoc@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('christopher.price@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('chrisw@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('chrisw@sous-sol.org','http://lists.openstack.org/pipermail/openstack-dev'),('chu.ducminh@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chuanchang.jia@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chuck.carlino@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('chuck.short@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('chuckjcarlino@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('chungg@ca.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('chvsnrk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cian.o-driscoll@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('cindy.pallaresq@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('CITRON@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('cjones@siaras.com','http://lists.openstack.org/pipermail/openstack-dev'),('ckmvishnu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('clark.boylan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('clark.laughlin@linaro.org','http://lists.openstack.org/pipermail/openstack-dev'),('claudio@onesource.pt','http://lists.openstack.org/pipermail/openstack-dev'),('clay.gerrard@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('clint@fewbar.com','http://lists.openstack.org/pipermail/openstack-dev'),('cloudbengo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cloudbeyond@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('clu@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('cmsj@tenshu.net','http://lists.openstack.org/pipermail/openstack-dev'),('cnaik@paypal.com','http://lists.openstack.org/pipermail/openstack-dev'),('codeoedoc@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cody-somerville@ubuntu.com','http://lists.openstack.org/pipermail/openstack-dev'),('cody.somerville@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cohen@noironetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('colin@2cups.com','http://lists.openstack.org/pipermail/openstack-dev'),('comnea.dani@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('contactnewsky@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('coolsvap@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/openstack-dev'),('Cory.Benfield@metaswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('cosmos0703@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cp16net@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cpallares@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('cpp.cabrera@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('crack.pop.cloud@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('craig@craigtracey.com','http://lists.openstack.org/pipermail/openstack-dev'),('cristian.a.sanchez@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('cristian.cotes@urv.cat','http://lists.openstack.org/pipermail/openstack-dev'),('croberts@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('cropper.joe@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('csdhe.geek@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cse.soumya@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cseader@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('csumit80@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cthier@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ctomoiaga@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('curhuman@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cward@isi.edu','http://lists.openstack.org/pipermail/openstack-dev'),('cyberlation@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('cyeoh@au1.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('cyrrian@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('d.w.chadwick@kent.ac.uk','http://lists.openstack.org/pipermail/openstack-dev'),('damon.devops@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dan.dyer00@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dan.stangel@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('dan@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('dandrushko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('danehans@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('daniel.genin@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('daniel.kuffner@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('daniel.mcdougall@liftoffsoftware.com','http://lists.openstack.org/pipermail/openstack-dev'),('daniel.morris@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('daniel.nobusada@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('daniele.casini@dektech.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('daniele.pizzolli@create-net.org','http://lists.openstack.org/pipermail/openstack-dev'),('Daniele.Venzano@eurecom.fr','http://lists.openstack.org/pipermail/openstack-dev'),('daniele@dvaleriani.net','http://lists.openstack.org/pipermail/openstack-dev'),('DANIK@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('danms@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('dannchoi@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('dara2002-openstack@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('darksinclair@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('darren.birkett@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Darren.Kenny@Oracle.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Darren.Moffat@Oracle.COM','http://lists.openstack.org/pipermail/openstack-dev'),('darshan.ghumare@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('daryl.walleck@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('dattbbk2@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dattbbk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dav.pineau@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('davanum@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave.birdsall@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave.haynes@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Dave.Johnston@owmobility.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave.mcnally@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave.pippenger@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave.walker@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('dave@dtucker.co.uk','http://lists.openstack.org/pipermail/openstack-dev'),('dave@saltstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.comay@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.cramer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('david.ferahi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.hadas@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.hill@ubisoft.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.koo@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.kranz@qrclab.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.lapsley@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.lyle@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.medberry@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.scott@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('david.scriptfan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('david@bluesunrise.com','http://lists.openstack.org/pipermail/openstack-dev'),('DAVIDH@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('davidh@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('david_peraza@persistentsys.com','http://lists.openstack.org/pipermail/openstack-dev'),('daya_k@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('dbailey@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('dbelova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dbogun@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dborodaenko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dburmistrov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dcahill@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('dce3062@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ddutta@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('deaster@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('deejay1@srem.org','http://lists.openstack.org/pipermail/openstack-dev'),('deepakcs@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('degorenko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dekehn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('demontie@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('dennis@holmes.nl','http://lists.openstack.org/pipermail/openstack-dev'),('derekh@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dev@openstack.sexy','http://lists.openstack.org/pipermail/openstack-dev'),('devananda.vdv@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('devdatta.kulkarni@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('devin@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('devoid@anl.gov','http://lists.openstack.org/pipermail/openstack-dev'),('devvesa@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dgrig@grnet.gr','http://lists.openstack.org/pipermail/openstack-dev'),('dguryanov@parallels.com','http://lists.openstack.org/pipermail/openstack-dev'),('dhami@noironetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('dhanesh1212@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dharmit.dev@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dheeraj.gupta4@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('diakunchikov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('diane.fleming@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('diego.parrilla.santamaria@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('digambarpat@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('digitalwonk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dilyin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dimitri.mazmanov@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('dinakar.gm@cloudbyte.co','http://lists.openstack.org/pipermail/openstack-dev'),('dirk@dmllr.de','http://lists.openstack.org/pipermail/openstack-dev'),('divakar.padiyar-nandavar@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('divius.inside@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dizquierdo@bitergia.com','http://lists.openstack.org/pipermail/openstack-dev'),('dj199008@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('djhon9813@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dkang@isi.edu','http://lists.openstack.org/pipermail/openstack-dev'),('dkliban@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dklyle0@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dkoryavov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmakogon@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmcphers@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmercer@fantoccini.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmescheryakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmitryme.ru@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dms@danplanet.com','http://lists.openstack.org/pipermail/openstack-dev'),('dmsimard@iweb.com','http://lists.openstack.org/pipermail/openstack-dev'),('DNOLL@de.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('doc@aedo.net','http://lists.openstack.org/pipermail/openstack-dev'),('dolph.mathews@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('domas.monkus@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('don.schenck@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('don.waterloo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Donagh.McCabe@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('donald.d.dugger@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('donald@stufft.io','http://lists.openstack.org/pipermail/openstack-dev'),('doudouyam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-dev'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/openstack-dev'),('doug@tesora.com','http://lists.openstack.org/pipermail/openstack-dev'),('dougal@dougalmatthews.com','http://lists.openstack.org/pipermail/openstack-dev'),('dougal@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('douglas.mendizabal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('douglas.sims@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('dougw@a10networks.com','http://lists.openstack.org/pipermail/openstack-dev'),('dougwig@parksidesoftware.com','http://lists.openstack.org/pipermail/openstack-dev'),('dpkselvaraj@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dpkshetty@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dprince@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dpyzhov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dradez@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('drago.rosson@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('dragonetail@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('drew.fisher@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('drfish@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('dripton@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dron@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ds442@kent.ac.uk','http://lists.openstack.org/pipermail/openstack-dev'),('dscannell@gridcentric.com','http://lists.openstack.org/pipermail/openstack-dev'),('dsetia@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('dshulyak@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dstanek@dstanek.com','http://lists.openstack.org/pipermail/openstack-dev'),('dtantsur@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dteselkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dtroyer@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dts68x@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dua_rajdeep@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('dug@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('dukhlov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dukov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('dummyhacker85@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('duncan.johnstonwatt@cloudsoftcorp.com','http://lists.openstack.org/pipermail/openstack-dev'),('duncan.mcgreggor@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('duncan.thomas@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('duncan.thomas@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('duncan@dreamhost.com','http://lists.openstack.org/pipermail/openstack-dev'),('duret.tanguy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dustin@null-ptr.net','http://lists.openstack.org/pipermail/openstack-dev'),('duyujie.dyj@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('dvossel@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('dykstra@umbc.edu','http://lists.openstack.org/pipermail/openstack-dev'),('dz@stackstorm.com','http://lists.openstack.org/pipermail/openstack-dev'),('dzimine@stackstorm.com','http://lists.openstack.org/pipermail/openstack-dev'),('dzyu@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('e0ne@e0ne.info','http://lists.openstack.org/pipermail/openstack-dev'),('ebergenholtz@hortonworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('eblake@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ed.bak2@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ed.cranford@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ed.cranford@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('ed@leafe.com','http://lists.openstack.org/pipermail/openstack-dev'),('ed@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('ed@slumberheart.com','http://lists.openstack.org/pipermail/openstack-dev'),('ed@stackerz.com','http://lists.openstack.org/pipermail/openstack-dev'),('eddie.sheffield@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('edgar.magana@workday.com','http://lists.openstack.org/pipermail/openstack-dev'),('edhall@weirdnoise.com','http://lists.openstack.org/pipermail/openstack-dev'),('edhall@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('edmund.troche@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('edouard.thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('eduard.barrera@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('eduard.matei@cloudfounders.com','http://lists.openstack.org/pipermail/openstack-dev'),('edward.hope-morley@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('eezhova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('efedorova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('egon@egon.cc','http://lists.openstack.org/pipermail/openstack-dev'),('eharney@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ehelms@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ekirpichov@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ekozhemyakin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ekudryashova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('elbarbori1010@msn.com','http://lists.openstack.org/pipermail/openstack-dev'),('eli@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('elias@mussicorp.net','http://lists.openstack.org/pipermail/openstack-dev'),('eltonkevani@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('emagana@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('emagana@plumgrid.com','http://lists.openstack.org/pipermail/openstack-dev'),('email@daviey.com','http://lists.openstack.org/pipermail/openstack-dev'),('emilien.macchi@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('emilien.macchi@stackops.com','http://lists.openstack.org/pipermail/openstack-dev'),('emilien@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('emoe264@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('enakai@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('endre.karlson@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('engg.sanj@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('enikanorov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('enykeev@stackstorm.com','http://lists.openstack.org/pipermail/openstack-dev'),('eoghan.glynn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('eperdomo@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('erhan.ekici@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('erhankins@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('eric.deliot@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('eric.frizziero@pd.infn.it','http://lists.openstack.org/pipermail/openstack-dev'),('eric.pendergrass@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('eric@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('eric@windisch.us','http://lists.openstack.org/pipermail/openstack-dev'),('erik.moe@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('erming@ualberta.ca','http://lists.openstack.org/pipermail/openstack-dev'),('eshumakher@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('Estevao.Vargas@br.unisys.com','http://lists.openstack.org/pipermail/openstack-dev'),('ettorezugliani@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('everett.toews@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('EvgenyF@Radware.com','http://lists.openstack.org/pipermail/openstack-dev'),('ewindisch@docker.com','http://lists.openstack.org/pipermail/openstack-dev'),('EZRA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('f.daisy25@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('f.eleouet@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('FACTOR@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('facundo.n.maldonado@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('faizan.barmawer@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('fank@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('fawad@plumgrid.com','http://lists.openstack.org/pipermail/openstack-dev'),('federico.facca@create-net.org','http://lists.openstack.org/pipermail/openstack-dev'),('feiguang.wu@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('feilong@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-dev'),('fengdong@qiyi.com','http://lists.openstack.org/pipermail/openstack-dev'),('fengqian.gao@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('fifieldt@unimelb.edu.au','http://lists.openstack.org/pipermail/openstack-dev'),('filipe.manco@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('fipuzzles@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('fla@tid.es','http://lists.openstack.org/pipermail/openstack-dev'),('flavio@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('florenllanos@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('florent.flament-ext@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('florian.otel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('florian@hastexo.com','http://lists.openstack.org/pipermail/openstack-dev'),('flwang@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('fpercoco@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('franck110@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('francois.bureau@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('francois.rossigneux@inria.fr','http://lists.openstack.org/pipermail/openstack-dev'),('frans@meruvian.org','http://lists.openstack.org/pipermail/openstack-dev'),('fred@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('freedomhui@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('freyes@tty.cl','http://lists.openstack.org/pipermail/openstack-dev'),('frittoli@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('fschim@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('fsoppelsa@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ftersin@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('fujioka-yuuichi@zx.mxh.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('fukuda.yuko@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-dev'),('furlongm@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('fz1989fz@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('g.franceschi@tmg.nl','http://lists.openstack.org/pipermail/openstack-dev'),('gabe.westmaas@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Gabriel.Hurley@nebula.com','http://lists.openstack.org/pipermail/openstack-dev'),('gabriel.pettier@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('gabriel.wainer@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('gallard.jerome@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gang.sungjin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gangadhar.singh@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('gans.developer@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('garcianavalon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('garrychen@icloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('gary.w.smith@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('garyduan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gauvain.pocentek@objectif-libre.com','http://lists.openstack.org/pipermail/openstack-dev'),('gavin.brebner@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('gavin.mu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gduan@varmour.com','http://lists.openstack.org/pipermail/openstack-dev'),('geekinutah@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('genggjh@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gengjh@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('geoff@geoffarnold.com','http://lists.openstack.org/pipermail/openstack-dev'),('geoffocallaghan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('george.peristerakis@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('george.reese@enstratus.com','http://lists.openstack.org/pipermail/openstack-dev'),('george.reese@imaginary.com','http://lists.openstack.org/pipermail/openstack-dev'),('george.shuklin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('geraint.north@uk.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gerardmn@kth.se','http://lists.openstack.org/pipermail/openstack-dev'),('gergely.matefi2@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('german.eichberger@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('germy.lure@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gessau@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('gessau@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('geza.gemes@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('gfa+os@zumbi.com.ar','http://lists.openstack.org/pipermail/openstack-dev'),('gfa@zumbi.com.ar','http://lists.openstack.org/pipermail/openstack-dev'),('gfidente@fedoraproject.org','http://lists.openstack.org/pipermail/openstack-dev'),('gfidente@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ghanshyam.mann@nectechnologies.in','http://lists.openstack.org/pipermail/openstack-dev'),('ghanshyammann@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ghe.rivero@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ghe@debian.org','http://lists.openstack.org/pipermail/openstack-dev'),('gilbert.pilz@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('gilmeir@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('GILR@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('GILV@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('giri.basava@triliodata.com','http://lists.openstack.org/pipermail/openstack-dev'),('girishbangaram@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('git-harry@live.co.uk','http://lists.openstack.org/pipermail/openstack-dev'),('giuseppe.cossu@create-net.org','http://lists.openstack.org/pipermail/openstack-dev'),('giuseppegaleota@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gkotton@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('gkotton@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('gleebix@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('glen@glenc.io','http://lists.openstack.org/pipermail/openstack-dev'),('GLIKSON@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('glongwave@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('glucas@tesora.com','http://lists.openstack.org/pipermail/openstack-dev'),('gmurphy@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('gokrokvertskhov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('gokul4open@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gongysh@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gongysh@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gongysh@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('gong_ys2004@aliyun.com','http://lists.openstack.org/pipermail/openstack-dev'),('gopi97468@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gord@live.ca','http://lists.openstack.org/pipermail/openstack-dev'),('gorodnev@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gorozco@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gosse.alex@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gotouday@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gouzongmei@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('gpeeyush@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gpeeyush@ymail.com','http://lists.openstack.org/pipermail/openstack-dev'),('gpernot@praksys.org','http://lists.openstack.org/pipermail/openstack-dev'),('gp_stack@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('grafinya.uvarova@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('graflu0@students.zhaw.ch','http://lists.openstack.org/pipermail/openstack-dev'),('graham.hayes@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('greg.hill@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('greg.j.regnier@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('greg.poirier@opower.com','http://lists.openstack.org/pipermail/openstack-dev'),('Greg.Waines@windriver.com','http://lists.openstack.org/pipermail/openstack-dev'),('greg@greghaynes.net','http://lists.openstack.org/pipermail/openstack-dev'),('gregory.ietf@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Greg_Jacobs@Dell.com','http://lists.openstack.org/pipermail/openstack-dev'),('gsagie@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('gsim@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('gtt116@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('guang.yee@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('guangyu@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('guillaume.thouvenin@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('guochbo@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('guohliu@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('guoyingc@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gupeng@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('gus@inodes.org','http://lists.openstack.org/pipermail/openstack-dev'),('guslees@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('guz.fnst@cn.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('gyehuda@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('h-eguchi@az.jp.nec.com','http://lists.openstack.org/pipermail/openstack-dev'),('hachemfst@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hagiwarayuj@nttdata.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('hammadhaleem@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hammondjohnson@hushmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('haneef.ali@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('hangliu@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('hanishgogadahcu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hanlind@kth.se','http://lists.openstack.org/pipermail/openstack-dev'),('hannanabdul55@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hanyu.xiao@eayun.com','http://lists.openstack.org/pipermail/openstack-dev'),('hanzhf@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('hao.1.wang@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('haomai@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('harh@zhaw.ch','http://lists.openstack.org/pipermail/openstack-dev'),('harish.patil@qlogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('harlowja@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('harm@weites.com','http://lists.openstack.org/pipermail/openstack-dev'),('harryxiyou@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('harshada.kakad@izeltech.com','http://lists.openstack.org/pipermail/openstack-dev'),('harsshah@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('hartsock@acm.org','http://lists.openstack.org/pipermail/openstack-dev'),('hartsocks@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('harubelle@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hashar@free.fr','http://lists.openstack.org/pipermail/openstack-dev'),('hashmap@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hayashi@ntti3.com','http://lists.openstack.org/pipermail/openstack-dev'),('hbrock@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('hch@infradead.org','http://lists.openstack.org/pipermail/openstack-dev'),('heckj@mac.com','http://lists.openstack.org/pipermail/openstack-dev'),('heckj@me.com','http://lists.openstack.org/pipermail/openstack-dev'),('hegde.shashank@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hemant.burman@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hemanth.makkapati@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('hemanthraviml@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('henrique@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('henriquecostatruta@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('henry4hly@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('henryn@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('heut2008@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hideyasu.hayashi@oolorg.mygbiz.com','http://lists.openstack.org/pipermail/openstack-dev'),('hillad@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hitesh.wadekar@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hnakil@contrailsystems.com','http://lists.openstack.org/pipermail/openstack-dev'),('hnarkaytis@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('hodosmb@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('holms@holms.lt','http://lists.openstack.org/pipermail/openstack-dev'),('hongbin034@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hongnax.xu@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('hongseok.jeon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hosein.zarei@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hs.chen@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('huanggeng.8552@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('huangtianhua@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('hudayou@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hugh@wherenow.org','http://lists.openstack.org/pipermail/openstack-dev'),('hui.xiang@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('huruifeng@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('huwei.xtu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('huyr@arraynetworks.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('hvprash@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hvprashcloud@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hyangii@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('hyerle@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('hyunsun.moon@kt.com','http://lists.openstack.org/pipermail/openstack-dev'),('hzguanqiang@corp.netease.com','http://lists.openstack.org/pipermail/openstack-dev'),('hzwangpan@corp.netease.com','http://lists.openstack.org/pipermail/openstack-dev'),('i-kumagai@bit-isle.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('ian.cordasco@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('iartarisi@suse.cz','http://lists.openstack.org/pipermail/openstack-dev'),('ibelikov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('iberezovskiy@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('iccha.sethi@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('ichavero@chavero.com.mx','http://lists.openstack.org/pipermail/openstack-dev'),('ichihara.hirofumi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ichihara.hirofumi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('idegtiarov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('idopra@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ielterman@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ifarkas@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ifzing@126.com','http://lists.openstack.org/pipermail/openstack-dev'),('igawa@mxs.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('ignacio@embrane.com','http://lists.openstack.org/pipermail/openstack-dev'),('igor@tnkng.com','http://lists.openstack.org/pipermail/openstack-dev'),('igordcard@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('iheim@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ihrachys@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ijstokes@seas.harvard.edu','http://lists.openstack.org/pipermail/openstack-dev'),('ijw.ubuntu@cack.org.uk','http://lists.openstack.org/pipermail/openstack-dev'),('ik.ibadkhan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ikalnitsky@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ikharin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ikhudoshyn@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ikliuk@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ildiko.vancsa@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('ilkka.tengvall@cybercom.com','http://lists.openstack.org/pipermail/openstack-dev'),('imain@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('imarnat@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('imcleod@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('imelnikov@griddynamics.com','http://lists.openstack.org/pipermail/openstack-dev'),('imsplitbit@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('iner45@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('info@cschwede.de','http://lists.openstack.org/pipermail/openstack-dev'),('inoue.tomoko@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('iosstef@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ip.disabled@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ipekelny@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ipersky@griddynamics.com','http://lists.openstack.org/pipermail/openstack-dev'),('ipovolotskaya@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('irenab@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('isaku.yamahata@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Isao.Yanagimachi@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ishakhat@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ishant.tyagi@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ishishkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('israel.ziv@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('iss@cin.ufpe.br','http://lists.openstack.org/pipermail/openstack-dev'),('isviridov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('itai.mendelsohn@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('itamarost@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('itbrown@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ityaptin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('itzikb@dev.mellanox.co.il','http://lists.openstack.org/pipermail/openstack-dev'),('itzikb@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ivar@embrane.com','http://lists.openstack.org/pipermail/openstack-dev'),('ivarlazzaro@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ivasilevskaya@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('iwallis@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('iwamoto@valinux.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('iwienand@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('izabela@copin.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('j.rosenboom@x-ion.de','http://lists.openstack.org/pipermail/openstack-dev'),('jack.mccann@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('jacki.bauer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jacob@bluehost.com','http://lists.openstack.org/pipermail/openstack-dev'),('jacobgodin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jake@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('James.Bottomley@HansenPartnership.com','http://lists.openstack.org/pipermail/openstack-dev'),('james.page@ubuntu.com','http://lists.openstack.org/pipermail/openstack-dev'),('james.slagle@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('james@jameskyle.org','http://lists.openstack.org/pipermail/openstack-dev'),('jamesk@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('james_r_penick@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('jamie.hannaford@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('jamielennox@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jan.kasius@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Jan.van.Eldik@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('jang@ioctl.org','http://lists.openstack.org/pipermail/openstack-dev'),('janis.gengeris@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jaosorior@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jarret.raim@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jason.dobies@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jason.dunsmore@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('jason.greathouse@leankit.com','http://lists.openstack.org/pipermail/openstack-dev'),('jason.rouault@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('jason@koelker.net','http://lists.openstack.org/pipermail/openstack-dev'),('jay.lau.513@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jay@jvf.cc','http://lists.openstack.org/pipermail/openstack-dev'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jazeltq@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbelamaric@infoblox.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbernard@tuxion.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbjohnso@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbrendel@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbresnah@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbryce@jbryce.com','http://lists.openstack.org/pipermail/openstack-dev'),('jbsloyer@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jcaballero.hep@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jch.martin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jckasper@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jcmartin@ebaysf.com','http://lists.openstack.org/pipermail/openstack-dev'),('jcoufal@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jcsf31459@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jdennis@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jean-baptiste.ransy@alyseo.com','http://lists.openstack.org/pipermail/openstack-dev'),('jean-daniel.bonnetot@ovh.net','http://lists.openstack.org/pipermail/openstack-dev'),('jean.marc.saffroy@scality.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('jecarey@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeckersb@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeff.walls@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeffreyb@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeffrngu@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('Jeff_Cai@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('jemartin@ebay.com','http://lists.openstack.org/pipermail/openstack-dev'),('jenny.jiangying@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeremy-liu@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeremy.liu@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeremy@dreamhost.com','http://lists.openstack.org/pipermail/openstack-dev'),('jeronimo974@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jesse.cook@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jesse.noller@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jesse.pretorius@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jessica.lucci@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jesusaurus@mail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jfehlig@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('jgb@bitergia.com','http://lists.openstack.org/pipermail/openstack-dev'),('jgzhang@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ji23death4@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jiadong2006@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jian.wen@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('jianbo.zheng@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jiangcx@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jiaoyang@opzoon.com','http://lists.openstack.org/pipermail/openstack-dev'),('jichenjc@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jim@geekdaily.org','http://lists.openstack.org/pipermail/openstack-dev'),('jim@jimrollenhagen.com','http://lists.openstack.org/pipermail/openstack-dev'),('jistr@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jjm3lp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jkirnosova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('jkoelker@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('jkt@kde.org','http://lists.openstack.org/pipermail/openstack-dev'),('jkugel@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jkumbhani@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jlennox@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jmank@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('jmaron@hortonworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('jmcbride@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('jmulsow@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jobin.rv@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jodavidg@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('joe.hakim.rahme@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('Joe.Heck@nebula.com','http://lists.openstack.org/pipermail/openstack-dev'),('joe.savak@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('joe.topjian@cybera.ca','http://lists.openstack.org/pipermail/openstack-dev'),('joe@mu.org','http://lists.openstack.org/pipermail/openstack-dev'),('joehazzers@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('joehuang.sweden@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('joehuang@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('Joel.Coffman@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('jogo@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('johannes@erdfelt.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.a@casey.net','http://lists.openstack.org/pipermail/openstack-dev'),('John.Garbutt@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.griffith8@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.herndon@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.hopper@jpserver.net','http://lists.openstack.org/pipermail/openstack-dev'),('John.Plocher@evault.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.sanabria@correounivalle.edu.co','http://lists.openstack.org/pipermail/openstack-dev'),('john.t.gruber@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('John.Utz@wdc.com','http://lists.openstack.org/pipermail/openstack-dev'),('john.vrbanac@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('john.wood@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('john@bresnahan.me','http://lists.openstack.org/pipermail/openstack-dev'),('john@dewey.ws','http://lists.openstack.org/pipermail/openstack-dev'),('john@johngarbutt.com','http://lists.openstack.org/pipermail/openstack-dev'),('johnsomor@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Johnson.Cheng@QsanTechnology.com','http://lists.openstack.org/pipermail/openstack-dev'),('jomara@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/openstack-dev'),('jonathan-lists@cleverdevil.org','http://lists.openstack.org/pipermail/openstack-dev'),('jonathan_gershater@trendmicro.com','http://lists.openstack.org/pipermail/openstack-dev'),('JonPaul.Sullivan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('joonwon7.lee@samsung.com','http://lists.openstack.org/pipermail/openstack-dev'),('jordan.pittier@scality.com','http://lists.openstack.org/pipermail/openstack-dev'),('jorge.miramontes@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('jorge.williams@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('joseph.assiga@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('josh.durgin@inktank.com','http://lists.openstack.org/pipermail/openstack-dev'),('josh.odom@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('josh@jk0.org','http://lists.openstack.org/pipermail/openstack-dev'),('josh@pcsforeducation.com','http://lists.openstack.org/pipermail/openstack-dev'),('joshua.hesketh@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('joshua.hesketh@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('joshua.zhang@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('jp@jamezpolley.com','http://lists.openstack.org/pipermail/openstack-dev'),('jpeeler@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jpichon@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jpittier@octo.com','http://lists.openstack.org/pipermail/openstack-dev'),('jprovazn@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jranjan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jrist@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jroovers@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('jruzicka@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jsbryant@electronicjungle.net','http://lists.openstack.org/pipermail/openstack-dev'),('jsbryant@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jschwarz@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jshepher@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('jspeidel@hortonworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('jswarren@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jswarren@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('jtomasek@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('juanmanuel.reyportal@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Juerg.Haefliger@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('jules@ispire.me','http://lists.openstack.org/pipermail/openstack-dev'),('juliano.ciocari@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('juliano.martinez@locaweb.com.br','http://lists.openstack.org/pipermail/openstack-dev'),('Julien.LELOUP@3ds.com','http://lists.openstack.org/pipermail/openstack-dev'),('julien@danjou.info','http://lists.openstack.org/pipermail/openstack-dev'),('julim@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('juliocarlos.barrera@i2cat.net','http://lists.openstack.org/pipermail/openstack-dev'),('jun.park.earth@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('june.yi@samsung.com','http://lists.openstack.org/pipermail/openstack-dev'),('junqingwang@139.com','http://lists.openstack.org/pipermail/openstack-dev'),('Jussi.Sorjonen@cybercom.com','http://lists.openstack.org/pipermail/openstack-dev'),('justin.hammond@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('justin.hopper@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('justin.simms@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('justin@fathomdb.com','http://lists.openstack.org/pipermail/openstack-dev'),('juvenboy1987@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('jvarlamova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('jvlcek@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('jwcroppe@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('k.ogaki@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('K.W.S.Siu@kent.ac.uk','http://lists.openstack.org/pipermail/openstack-dev'),('kaarle.ritvanen@nsn.com','http://lists.openstack.org/pipermail/openstack-dev'),('kai.brennenstuhl@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Kaitlin.Farr@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('kajinamit@nttdata.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('kaleb.pomeroy@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanabuchi.mitsuru@po.ntts.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('kanagaraj.manickam@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanghua151@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanika.saklani11@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanno.masaki@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanzhe.jiang@bigswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('kanzhe@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kapil.thangavelu@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('kaufer@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('kaushik.chandrashekar@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('kazikubwa@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kbasil@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('kc.wang@bigswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('kchamart@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('kdanilov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('keith.bray@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('keith_newstadt@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('ken.wronkiewicz@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('ken1ohmichi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kenny.jones@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kent.wang@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('keshava.a@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kesten.broughton@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kevin.carter@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('kevin.fox@pnnl.gov','http://lists.openstack.org/pipermail/openstack-dev'),('kevin.mitchell@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('kevin@ie.suberic.net','http://lists.openstack.org/pipermail/openstack-dev'),('kevinjacobconway@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('keyvan.m.sadeghi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kgiusti@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('khanh-toan.tran@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('khayam.gondal@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('khyatitp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kiall@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kiall@managedit.ie','http://lists.openstack.org/pipermail/openstack-dev'),('kilohoku150@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kiran-kumar.vaddi@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kiranmurari@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kispear@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('kodera.yasuo@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('koert@cloudvps.com','http://lists.openstack.org/pipermail/openstack-dev'),('KOLODNER@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('konghuarukhr@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('konglingxian@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('kookikihoo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('koteswara.kelam@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('KPAVEL@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('kprad1@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('kpublicmail@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kragniz@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kraman@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('krishna1256@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('krotscheck@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('krt@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('krtaylor@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('krum.spencer@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kruskakli@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ksambor@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ksamoray@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('kuangching.wang@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kukura@noironetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('kurt.f.martin@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kurt.griffiths@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('kurt.r.taylor@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('kuvaja@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('kvarunkumarme@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('la6470@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('laixuejiao@mail01.huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('lakmal.silva111@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lakshmi.sampath@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('lakshmi@lakshmikannan.me','http://lists.openstack.org/pipermail/openstack-dev'),('lalitha.maruthachalam@aricent.com','http://lists.openstack.org/pipermail/openstack-dev'),('lari.partanen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lars.lehtonen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lars@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('laserjetyang@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('launchpad@chmouel.com','http://lists.openstack.org/pipermail/openstack-dev'),('laura.adq@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lauren@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('laurence.miao@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lbragstad@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lcui@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('ldbragst@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('ldbragst@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('leandro.i.costantino@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('leandro.reox@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('leblancd@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('lecalcot@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('legiangthanh@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Lena.Herscheid@hpi.de','http://lists.openstack.org/pipermail/openstack-dev'),('leoniz127@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('letsgotry7@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lewtucker@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('lex@lexinator.com','http://lists.openstack.org/pipermail/openstack-dev'),('lgy181@foxmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lhcxx0508@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lhh@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('li-gong.duan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('li-zheming@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('li.zhang23@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('lianhao.lu@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('libosvar@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('lijh.hust@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lilinguo8212@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('limao@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('lin-hua.cheng@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('lin.tan@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('linb@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('linchengyong@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('lincoln.max@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Lincoln.Thomas@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('line@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('ling.zhiyang@zte.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('linggao@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('linus.nova@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('linus@linusnova.com','http://lists.openstack.org/pipermail/openstack-dev'),('lisa.clark@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('lisa.zangrando@pd.infn.it','http://lists.openstack.org/pipermail/openstack-dev'),('liufeiyu323@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('liugl@cloud-times.com','http://lists.openstack.org/pipermail/openstack-dev'),('liugya@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('liujiaxiang@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('liusheng1175@126.com','http://lists.openstack.org/pipermail/openstack-dev'),('liushixing@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('liuxinguo@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('liuyang3240@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('liuzhikun@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('liyi.meng@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('liyingjun1988@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lizheminghw@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lloydostack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lnova@linusnova.com','http://lists.openstack.org/pipermail/openstack-dev'),('logan@bacoosta.com','http://lists.openstack.org/pipermail/openstack-dev'),('lohitv@gwmail.gwu.edu','http://lists.openstack.org/pipermail/openstack-dev'),('loic@dachary.org','http://lists.openstack.org/pipermail/openstack-dev'),('lokeshbalcha@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('loles@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('lonely8658@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('longsube@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-dev'),('Louis.Fourie@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('loywolfe@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lpeer@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('lrengan@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('lshaokai@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('lsmola@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('lsurette@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('Luc.Lemieux@ca.kontron.com','http://lists.openstack.org/pipermail/openstack-dev'),('lucas@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('lucasagomes@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('luis.fernandez.alvarez@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('luis@debethencourt.com','http://lists.openstack.org/pipermail/openstack-dev'),('luis@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('luke@snabb.co','http://lists.openstack.org/pipermail/openstack-dev'),('luke@tail-f.com','http://lists.openstack.org/pipermail/openstack-dev'),('lv.erchun@zte.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('lvmxhster@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lyon.liang12@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('lyz@princessleia.com','http://lists.openstack.org/pipermail/openstack-dev'),('lzy.dev@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('m.koderer@telekom.de','http://lists.openstack.org/pipermail/openstack-dev'),('m.paolino@virtualopensystems.com','http://lists.openstack.org/pipermail/openstack-dev'),('m.tejedor-gonzalez@mycit.ie','http://lists.openstack.org/pipermail/openstack-dev'),('m4d.coder@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('m@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('maciejgalkiewicz@ragnarson.com','http://lists.openstack.org/pipermail/openstack-dev'),('magazine.lihuiba@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('magesh.gv@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('mageshmannar@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('maheshp@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('mail-lists@karan.org','http://lists.openstack.org/pipermail/openstack-dev'),('mail.ashishchandra@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mail2digant@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mail@cgoncalves.pt','http://lists.openstack.org/pipermail/openstack-dev'),('maillist.alan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('maishsk+openstack@maishsk.com','http://lists.openstack.org/pipermail/openstack-dev'),('majopela@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('maksimov@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Maksym_Iarmak@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('mali@awcloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('malini.k.bhandaru@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('malini.kamalambal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('manas@stackstorm.com','http://lists.openstack.org/pipermail/openstack-dev'),('manasdk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mandell@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('mandreou@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mangelajo@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('manik@techdazzler.com','http://lists.openstack.org/pipermail/openstack-dev'),('manishg@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('manishgmailbox-os@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('manuel.stein@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('marc@koderer.com','http://lists.openstack.org/pipermail/openstack-dev'),('marcelod@andrew.cmu.edu','http://lists.openstack.org/pipermail/openstack-dev'),('marcios@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('Marco.Fargetta@ct.infn.it','http://lists.openstack.org/pipermail/openstack-dev'),('Marco.Fornaro@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('marcos.fermin.lobo@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('mardan.singh@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('marek.denis@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('mario.adessi@live.com','http://lists.openstack.org/pipermail/openstack-dev'),('marios@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mariusz.gronczewski@efigence.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.collier@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.kirkwood@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-dev'),('mark.m.miller@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Mark.Maglana@NexusIS.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.mcclain@dreamhost.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.seger@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark.washenberger@markwash.net','http://lists.openstack.org/pipermail/openstack-dev'),('Mark.Yakabuski@safenet-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('mark@collierclan.net','http://lists.openstack.org/pipermail/openstack-dev'),('mark@mcclain.xyz','http://lists.openstack.org/pipermail/openstack-dev'),('mark@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('martin.loschwitz@hastexo.com','http://lists.openstack.org/pipermail/openstack-dev'),('martin.packman@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('Martin.Taylor@metaswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('martin@geisler.net','http://lists.openstack.org/pipermail/openstack-dev'),('marun@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('maruti.kamat@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('masayuki.igawa@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('masoom.alam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('massa.nomura@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('masumotok@nttdata.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('matarazzoangelo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('match.jp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mate.lakat@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('mathew@abjayon.com','http://lists.openstack.org/pipermail/openstack-dev'),('mathieu.rohon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mathivathani.s@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('matsuda_kenichi@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.asay@mongodb.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.dietz@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.joyce@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.keenan@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.wagner@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt.wood@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt@mattfarina.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt@nycresistor.com','http://lists.openstack.org/pipermail/openstack-dev'),('matt@oliver.net.au','http://lists.openstack.org/pipermail/openstack-dev'),('matt@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('matthew.gilliard@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('matthew.macdonald-wallace@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('matthieu.huin@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('maty.grosz@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('maurosr@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('maxiao@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('maxime.leroy@6wind.com','http://lists.openstack.org/pipermail/openstack-dev'),('maxime.vidori@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('mayank.mittal@saggezza.com','http://lists.openstack.org/pipermail/openstack-dev'),('mayu.xa.0101@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mb@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mbasnight@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mbayer@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mbirru@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mbooth@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('md@semihalf.com','http://lists.openstack.org/pipermail/openstack-dev'),('mdelder@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mdorman@godaddy.com','http://lists.openstack.org/pipermail/openstack-dev'),('mdragon@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('mdubov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mdurnosvistov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('me@clifhouck.com','http://lists.openstack.org/pipermail/openstack-dev'),('me@jaybuff.com','http://lists.openstack.org/pipermail/openstack-dev'),('me@mark.atwood.name','http://lists.openstack.org/pipermail/openstack-dev'),('me@not.mn','http://lists.openstack.org/pipermail/openstack-dev'),('me@romcheg.me','http://lists.openstack.org/pipermail/openstack-dev'),('mechtri.marwen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('meghal@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('mehdi.alishahi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('melwitt@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('melwitt@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('melwittt@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mengjiel@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mengql112233@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mengqxqx@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mengxiandong@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mestery@mestery.com','http://lists.openstack.org/pipermail/openstack-dev'),('mestery@noironetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('mestery@siliconloons.com','http://lists.openstack.org/pipermail/openstack-dev'),('meytin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mfalatic@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('mgagne@iweb.com','http://lists.openstack.org/pipermail/openstack-dev'),('mgrygoriev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mhanif@brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('miarmak@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('Michael.Ayenson@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('michael.chapman@anu.edu.au','http://lists.openstack.org/pipermail/openstack-dev'),('michael.hinnant@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('michael.kerrin@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('michael.smith6@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('michael.still@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('michael@the-davies.net','http://lists.openstack.org/pipermail/openstack-dev'),('michael@varmour.com','http://lists.openstack.org/pipermail/openstack-dev'),('michal.dulko@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('michal.jastrzebski@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('michal@aegis.org.pl','http://lists.openstack.org/pipermail/openstack-dev'),('michel.gauthier@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('midehaan@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('miguel@mlavalle.com','http://lists.openstack.org/pipermail/openstack-dev'),('miguelangel@ajo.es','http://lists.openstack.org/pipermail/openstack-dev'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-dev'),('mike-launchpad@weirdlooking.com','http://lists.openstack.org/pipermail/openstack-dev'),('mike.asthalter@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('mike.dickson@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('mike.heald@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('mike.r.grima@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mike@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('mikeyp@lhrc.com','http://lists.openstack.org/pipermail/openstack-dev'),('mimccune@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('min.wang6@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('minwoob@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mismith@overstock.com','http://lists.openstack.org/pipermail/openstack-dev'),('mitsuhiro.tanino@hds.com','http://lists.openstack.org/pipermail/openstack-dev'),('miyakz@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('mjbrightfr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mjfork@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mkassawara@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mkkang@isi.edu','http://lists.openstack.org/pipermail/openstack-dev'),('mkolesni@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mkollaro@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mkulkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mlobur@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mlowery@ebay.com','http://lists.openstack.org/pipermail/openstack-dev'),('mmcclain@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('mmcroberts@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mmohan@mvista.com','http://lists.openstack.org/pipermail/openstack-dev'),('mmorais@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('mmosesohn@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('mn@mnabozny.pl','http://lists.openstack.org/pipermail/openstack-dev'),('mnestratov@parallels.com','http://lists.openstack.org/pipermail/openstack-dev'),('mnewby@internap.com','http://lists.openstack.org/pipermail/openstack-dev'),('mnewby@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mnot@mnot.net','http://lists.openstack.org/pipermail/openstack-dev'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack-dev'),('moreira.belmiro.email.lists@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('morgan@parelastic.com','http://lists.openstack.org/pipermail/openstack-dev'),('morita.daisuke@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('morita.kazutaka@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('moshe.elisha@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('moshele@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('motoki@da.jp.nec.com','http://lists.openstack.org/pipermail/openstack-dev'),('motonobu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mozawa@cloudian.com','http://lists.openstack.org/pipermail/openstack-dev'),('mpavlase@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mr.alex.meade@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mriedem@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mriedem@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mrodden@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mrodden@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mrunge@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mrutkows@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('msaidelk@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('mscherbakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('msherborne@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('msm@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mspreitz@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('mssh2001@live.com','http://lists.openstack.org/pipermail/openstack-dev'),('mtaylor@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('mthode@mthode.org','http://lists.openstack.org/pipermail/openstack-dev'),('MThompson@a10networks.com','http://lists.openstack.org/pipermail/openstack-dev'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack-dev'),('munshedm@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('murali.allada@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Murali.Balcha@triliodata.com','http://lists.openstack.org/pipermail/openstack-dev'),('murali.sundar@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('murali@versa-networks.com','http://lists.openstack.org/pipermail/openstack-dev'),('muralimmreddy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mvanwink@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('mvineetmenon+openstackdev@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mvineetmenon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mvoelker@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('mvoelker@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('mxu@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('myer0052@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('mzoeller@de.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('m_mizutani@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('n0ano@n0ano.com','http://lists.openstack.org/pipermail/openstack-dev'),('nab@linux-iscsi.org','http://lists.openstack.org/pipermail/openstack-dev'),('nachi@ntti3.com','http://lists.openstack.org/pipermail/openstack-dev'),('nachi@nttmcl.com','http://lists.openstack.org/pipermail/openstack-dev'),('nachiappan.veerappan-nachiappan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('nader.lahouti@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('najoy@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('namei.unix@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nandavarpk@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nanjunjie@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('narayan.desai@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('NARESH.SAADHU@LNTTECHSERVICES.COM','http://lists.openstack.org/pipermail/openstack-dev'),('nassim.babaci@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('natarajk@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('nathanael.i.burton@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nati.ueno@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('natsume.takashi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('naveen.kunareddy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('naveen882@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('Navneet.Singh@netapp.com','http://lists.openstack.org/pipermail/openstack-dev'),('navneetk@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('nchase@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ndipanov@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('Neil.Jerram@metaswitch.com','http://lists.openstack.org/pipermail/openstack-dev'),('neil.zhangyang@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('neilchiao@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nejc.saje@xlab.si','http://lists.openstack.org/pipermail/openstack-dev'),('nels.nelson@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('nesrine.kaaniche@telecom-sudparis.eu','http://lists.openstack.org/pipermail/openstack-dev'),('neutrondev@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('nextone92@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('nezabravk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ng.tuna11@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nick.barcet@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('nicolas.thomas@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('nicolas.trangez@scality.com','http://lists.openstack.org/pipermail/openstack-dev'),('nicolas@barcet.com','http://lists.openstack.org/pipermail/openstack-dev'),('nihongi.nobuyoshi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('niilo.minkkinen.ext@nsn.com','http://lists.openstack.org/pipermail/openstack-dev'),('nikeshmahalka@vedams.com','http://lists.openstack.org/pipermail/openstack-dev'),('nikhil.komawar@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('nikhil@manchanda.me','http://lists.openstack.org/pipermail/openstack-dev'),('niklas.widell@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('nikunj.aggarwal@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('nilakhya.chatterjee@globallogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('nilesh.bhosale@in.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('nirlay@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nitikaagarwal18@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('niu.zglinux@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('njhtran@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nkhare@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('nkinder@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('nkonovalov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('nmakhotkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('nmarkov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('nobodycam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('noel@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('noorul@noorul.com','http://lists.openstack.org/pipermail/openstack-dev'),('Nora.Zhou@harmonicinc.com','http://lists.openstack.org/pipermail/openstack-dev'),('notsu@virtualtech.jp','http://lists.openstack.org/pipermail/openstack-dev'),('npbiles@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('nprivalova@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('nrupal.jani@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('nsaje@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('nspmangalore@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('nstarodubtsev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('numan.siddique@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('nuritv@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('nux@li.nux.ro','http://lists.openstack.org/pipermail/openstack-dev'),('nyechiel@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('oanufriev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('obalakirev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('oblaut@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('obondarev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('obulapathi.challa@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('ociuhandu@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-dev'),('oda@valinux.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('ofer@checkpoint.com','http://lists.openstack.org/pipermail/openstack-dev'),('ogelbukh@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('oliver.leahy@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ollivier.cedric@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('om.kumar@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('omrim@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('ondrej.wisniewski@dektech.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('oomichi@mxs.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('ootsuka@mxs.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('opensource@peoplemerge.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack-dev@dseven.org','http://lists.openstack.org/pipermail/openstack-dev'),('openstack-dev@storpool.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack.org@sodarock.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@cdl.asgaard.org','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@lanabrindley.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@nemebean.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@nicolas2bonfils.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@rohankanade.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@sheep.art.pl','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@systems-networking.de','http://lists.openstack.org/pipermail/openstack-dev'),('openstack@wormley.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstackgerrit@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('openstackleaner@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('opnstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('orhanc1@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('os.lcheng@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('os.vbvs@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('osanai.hisashi@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('osavatieiev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('OSHRITF@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('osms69@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('otavio.barcelos-gaspareto@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('overone00@qq.com','http://lists.openstack.org/pipermail/openstack-dev'),('ozamiatin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ozgurakan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('p.bouwers@student.rug.nl','http://lists.openstack.org/pipermail/openstack-dev'),('p.romuloo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('p.srikanta@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('P@draigBrady.com','http://lists.openstack.org/pipermail/openstack-dev'),('pa1975@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pablo.a.fuente@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('Pablosan@SalientBlue.com','http://lists.openstack.org/pipermail/openstack-dev'),('padkrish@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('pandeyop@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('panfy.fnst@cn.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('paophillip@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Parashuram.Hallur@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('parikshit.manur@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('parthipan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('pasha.hassaan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pasquale.porreca@dektech.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('pasquier.simon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('patg@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('patnala003@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('patricia.ellis@mycit.ie','http://lists.openstack.org/pipermail/openstack-dev'),('patrick.bredenberg@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('patrick.east@purestorage.com','http://lists.openstack.org/pipermail/openstack-dev'),('patrick.petit@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('pattabi@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('paul-david.bourke@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('paul.belanger@polybeacon.com','http://lists.openstack.org/pipermail/openstack-dev'),('paul.czarkowski@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('paul.e.luse@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('paul.kehrer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('paul.marshall@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Paul.McMillan@Nebula.com','http://lists.openstack.org/pipermail/openstack-dev'),('paul.montgomery@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('paul.voccio@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('PAULA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('pauldbourke@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('paulonascimento@av.it.pt','http://lists.openstack.org/pipermail/openstack-dev'),('pavuluri.kanthi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pawel.skowron@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('pballand@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('pballand@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('pbelanyi@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('pblaho@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('pc2929@att.com','http://lists.openstack.org/pipermail/openstack-dev'),('pc@michali.net','http://lists.openstack.org/pipermail/openstack-dev'),('pcm@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('pe3476@att.com','http://lists.openstack.org/pipermail/openstack-dev'),('pednape@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pedro.r.marques@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pekowski@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('peng.e.wu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pengxuhan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('penick@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('pepedocs@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('persia@shipstone.jp','http://lists.openstack.org/pipermail/openstack-dev'),('peter.a.portante@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('peter.boros@percona.com','http://lists.openstack.org/pipermail/openstack-dev'),('Peter.Hamilton@jhuapl.edu','http://lists.openstack.org/pipermail/openstack-dev'),('peter.mellquist@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('peter.w@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('peter@balland.net','http://lists.openstack.org/pipermail/openstack-dev'),('peter@gridcentric.ca','http://lists.openstack.org/pipermail/openstack-dev'),('peter@tesora.com','http://lists.openstack.org/pipermail/openstack-dev'),('pettori@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('pgrygiel@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('pguerin@sandvine.com','http://lists.openstack.org/pipermail/openstack-dev'),('Phani_Achanta@DELL.com','http://lists.openstack.org/pipermail/openstack-dev'),('phil.neal@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('philip.cheong@elastx.se','http://lists.openstack.org/pipermail/openstack-dev'),('philip.day@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('philipp.marek@linbit.com','http://lists.openstack.org/pipermail/openstack-dev'),('phillip.toohill@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('piaoyuankui@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pierre.freund@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pierre.padrixe@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pieter.c.kruithof-jr@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('pinhede.marc@netvirt.ca','http://lists.openstack.org/pipermail/openstack-dev'),('piotr.korthals@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('piotr.skamruk@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('pkaminski@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('pkilambi@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('pkulkar@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('pliljenberg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pmasrani@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('pmathews@bluehost.com','http://lists.openstack.org/pipermail/openstack-dev'),('pmiriyala@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('pmurray@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('porombka@uni-paderborn.de','http://lists.openstack.org/pipermail/openstack-dev'),('postmaster@ispire.me','http://lists.openstack.org/pipermail/openstack-dev'),('ppouliot@microsoft.com','http://lists.openstack.org/pipermail/openstack-dev'),('pradip.interra@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pranesh.bots@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('prasad.vellanki@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('prashant.upadhyaya@aricent.com','http://lists.openstack.org/pipermail/openstack-dev'),('prashanth.prahal@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('pratik.mallya@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('praveen-sm.kumar@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('preston@bannister.us','http://lists.openstack.org/pipermail/openstack-dev'),('priti.sarap@gslab.com','http://lists.openstack.org/pipermail/openstack-dev'),('Priti_Desai@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('pritkoth@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('priyanka.chopra@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('prof@achampion.net','http://lists.openstack.org/pipermail/openstack-dev'),('przemyslaw.czesnowicz@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('psarpol@gmx.com','http://lists.openstack.org/pipermail/openstack-dev'),('pshchelokovskyy@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('psolanki@salesforce.com','http://lists.openstack.org/pipermail/openstack-dev'),('ptmaway@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('punal.patel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('punith.s@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('qiaojian@awcloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('qili@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('qinchenchong@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Qing.He@radisys.com','http://lists.openstack.org/pipermail/openstack-dev'),('qixiaozhen@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('qsun01185@cienet.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('quanyongf@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('r-mibu@cq.jp.nec.com','http://lists.openstack.org/pipermail/openstack-dev'),('r1chardj0n3s@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('radek@gruchalski.com','http://lists.openstack.org/pipermail/openstack-dev'),('radix@twistedmatrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('radoslaw.smigielski@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('rafadurancastaneda@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rafaelfolco@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rafi@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('raghavendra.lad@accenture.com','http://lists.openstack.org/pipermail/openstack-dev'),('raghuram.gundimeda@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('rahuls@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('rahulsharmaait@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('raildom@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('raj@semihalf.com','http://lists.openstack.org/pipermail/openstack-dev'),('Raja.Srinivasan@riverbed.com','http://lists.openstack.org/pipermail/openstack-dev'),('raja@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('rajdeep.dua@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rajeev.grover@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('rajesh.mlists@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rajesh.ramchandani@cumulogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rajesh.Tailor@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rajesh_Mohan3@Dell.com','http://lists.openstack.org/pipermail/openstack-dev'),('rajshree.thorat@gslab.com','http://lists.openstack.org/pipermail/openstack-dev'),('rakesh.sinha@gslab.com','http://lists.openstack.org/pipermail/openstack-dev'),('rakhmerov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rakrup@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ralekseenkov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('ram.nath241089@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rameshg87.openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rameshg87@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ramielrowe@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ramishra@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ramk@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('ramy.asselin@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('randall.burt@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('randquistcp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Randy.Bias@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('randy.m.tuttle@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('randyb@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('rao.shweta@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('raodingyuan@chinacloud.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('rashg164@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ravikup@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('ravivsn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rbertram@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('rblee88@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rbogorodskiy@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rbrady@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rconradharris@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rcresswe@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('rcritten@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rcurran@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('readwriteom@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('reagul.2007@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('redheadflyundershadow@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('reginaldodbarros@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rellerreller@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('remo@italy1.com','http://lists.openstack.org/pipermail/openstack-dev'),('rerngvit@kth.se','http://lists.openstack.org/pipermail/openstack-dev'),('reza@dslextreme.com','http://lists.openstack.org/pipermail/openstack-dev'),('rfontana@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rgerganov@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('rgowrishankar@extremenetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('rhafer@suse.de','http://lists.openstack.org/pipermail/openstack-dev'),('rhallise@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rharwood@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rhsu@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('ricardo.carrillo.cruz@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rich@annexia.org','http://lists.openstack.org/pipermail/openstack-dev'),('richard.goodwin@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('richard.hagarty@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('richardwoo2003@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rick.chen@prophetstor.com','http://lists.openstack.org/pipermail/openstack-dev'),('rick.jones2@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('rick.richardson@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rimc@zhaw.ch','http://lists.openstack.org/pipermail/openstack-dev'),('rishiraj.devel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('riwinter@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('rjones@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rkamaldinov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rkukura@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/openstack-dev'),('rloo@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('rlooyahoo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rmeggins@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rmoats@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('rmoe@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rneilturner@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rnettleton@hortonworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('rnirmal@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rnorton@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('roagarwa@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('roam@ringlet.net','http://lists.openstack.org/pipermail/openstack-dev'),('rob.raymond@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('robberphex@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('robbyb@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('robemars@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('robert.clark@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Robert.Garron@Access3000.net','http://lists.openstack.org/pipermail/openstack-dev'),('robert.hallgren@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Robert.vanLeeuwen@spilgames.com','http://lists.openstack.org/pipermail/openstack-dev'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack-dev'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rochelle.Grober@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('rockyg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rodrigo.alejandre-prada@tieto.com','http://lists.openstack.org/pipermail/openstack-dev'),('rodrigods@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('rodrigodsousa@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('roel.vannyen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('roeyc@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rohan.Kanade@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('rohara@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rohit.Karajgi@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('Rohit.Karajgi@ril.com','http://lists.openstack.org/pipermail/openstack-dev'),('rohit.mathur1@globallogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('rohitvvv@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('roland.hochmuth@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('rom1.guignard@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('romain.hardouin@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('Romain.ZIBA@eurogiciel.fr','http://lists.openstack.org/pipermail/openstack-dev'),('romain_hardouin@yahoo.fr','http://lists.openstack.org/pipermail/openstack-dev'),('roman.bodnarchuk@indigitus.ch','http://lists.openstack.org/pipermail/openstack-dev'),('roman.dobosz@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('roman.klesel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('romilgupta19@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ronak.malav.shah@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ronak@nuagenetworks.net','http://lists.openstack.org/pipermail/openstack-dev'),('ronak_r.shah@alcatel-lucent.com','http://lists.openstack.org/pipermail/openstack-dev'),('ronen@reduxio.com','http://lists.openstack.org/pipermail/openstack-dev'),('RONENKAT@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('rony.kris@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rosenberg@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('roshan.agrawal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('roshanagr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rossella@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('rpenta@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rpodolyaka@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rprikhodchenko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rraja@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('rrugge@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('rsamprat@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rsblendido@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('rsharma@contrailsystems.com','http://lists.openstack.org/pipermail/openstack-dev'),('rsokolkov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rubasov@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rudra@contrailsystems.com','http://lists.openstack.org/pipermail/openstack-dev'),('rugwiro05@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('rush2balaji@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rushi.agr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ruslan.kiianchuk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('russell.sim@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('russellhaering@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('rverchikov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rvyalov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('rw314w@att.com','http://lists.openstack.org/pipermail/openstack-dev'),('rwsu@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ryan.clevenger@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('ryan.moore@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('ryan.petrello@dreamhost.com','http://lists.openstack.org/pipermail/openstack-dev'),('ryan.tidwell@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('rybrown@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ryotamibu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ryu@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('s3wong@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('sachi.gupta@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('sachi.king@anchor.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('Sachin.Goswami@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('sadasu@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('saelvyn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sagar.r.nikam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sagara177@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sahid.ferdjaoui@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('sahid.ferdjaoui@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sairam438@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sajeesh.cs@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('sajuptpm@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sakiwa.1109@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sakvarma@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('salv.orlando@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sam.alba@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sam.choi@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sam.harwell@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Sam.Wan@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('sam@swiftstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('sambetts@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('sammiestoel@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sampath.priyankara@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('samsong8610@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('samtarangare@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('samuel.bartel@orange.com','http://lists.openstack.org/pipermail/openstack-dev'),('samuel@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('SamuelB@Radware.com','http://lists.openstack.org/pipermail/openstack-dev'),('sandhya.ganapathy@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sandy.walsh@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('sanjivininaikar@tataelxsi.co.in','http://lists.openstack.org/pipermail/openstack-dev'),('sankarshan.mukhopadhyay@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sankha93@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('santiago.b.baldassin@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('Santosh8.Kumar@aricent.com','http://lists.openstack.org/pipermail/openstack-dev'),('saripurigopi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('saripurigopi@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('saschpe@mailbox.org','http://lists.openstack.org/pipermail/openstack-dev'),('saschpe@suse.de','http://lists.openstack.org/pipermail/openstack-dev'),('sasharatkovic@juniper.net','http://lists.openstack.org/pipermail/openstack-dev'),('sateesh.chodapuneedi@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('satish@aristanetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('satishsagar83@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('saurabh.ag82@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('saurabh.chordiya@nechclst.in','http://lists.openstack.org/pipermail/openstack-dev'),('savu.andrei@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sawad@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('sayaji15@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sayali.92720@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sbaker@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sbalukoff@bluebox.net','http://lists.openstack.org/pipermail/openstack-dev'),('sbauza@free.fr','http://lists.openstack.org/pipermail/openstack-dev'),('sbauza@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sbhou@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('sbiswas7@in.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('sbogatkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('scheuran@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('scott.dangelo@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('sdake@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sdmonov@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('sdoll@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('sean.k.mooney@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('sean.winn@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-dev'),('sean@coreitpro.com','http://lists.openstack.org/pipermail/openstack-dev'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-dev'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('seanroberts66@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Sean_Collins2@cable.comcast.com','http://lists.openstack.org/pipermail/openstack-dev'),('sebastian.herzberg@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sebastien.badia@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('sebastien.han@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('seenutn@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('seizadi@infoblox.com','http://lists.openstack.org/pipermail/openstack-dev'),('senhuang@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('sergey_kovalef@symantec40.com','http://lists.openstack.org/pipermail/openstack-dev'),('sergio.j.cazzolato@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('seyam_27@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('sgolovatiuk@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sgotliv@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('shaan7in@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shahhaqu@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('shake.chen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shalini.khandelwal@globallogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('shalz@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shane.wang@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('shanthakumar.k@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sharan.monikantan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shardy@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('sharis@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('shaunak.kashyap@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('shaunm@gnome.org','http://lists.openstack.org/pipermail/openstack-dev'),('sheeprine@nullplace.com','http://lists.openstack.org/pipermail/openstack-dev'),('shenwei9008@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shepelev.artem@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sherpa.urgen@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('sherry.krell@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('shida.takahiro@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shida@intellilink.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('shinohara_masakazu@cyberagent.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('shlomis@mellanox.com','http://lists.openstack.org/pipermail/openstack-dev'),('shraddha.pandhe@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('shreshtha.joshi@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('shrewsbury.dave@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shrirang.phadke@izeltech.com','http://lists.openstack.org/pipermail/openstack-dev'),('shrutisharma0810@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('shuangtai.tian@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('shuichiro.makigaki@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('SHULMANA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('shuo.yang@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('shweta@globallogic.com','http://lists.openstack.org/pipermail/openstack-dev'),('shyam.todeti@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('siaras@fixthebug.org','http://lists.openstack.org/pipermail/openstack-dev'),('sileht@sileht.net','http://lists.openstack.org/pipermail/openstack-dev'),('silvan@quobyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('simo@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('simon.leinen@switch.ch','http://lists.openstack.org/pipermail/openstack-dev'),('simon.pasquier@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('simon.perfer@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('singhs@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('Sirisha_Devineni@persistent.co.in','http://lists.openstack.org/pipermail/openstack-dev'),('sirushti.murugesan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sjing@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('sjm+osdevel@hard.ware.fi','http://lists.openstack.org/pipermail/openstack-dev'),('skalinowski@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('skandasw@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('skolekonov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('skovaleff@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('skraynev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('skywalker.nick@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('slagun@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('slawek@kaplonski.pl','http://lists.openstack.org/pipermail/openstack-dev'),('sleipnir012@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('slicknik@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('smaskalik@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('smcgough@kemptechnologies.com','http://lists.openstack.org/pipermail/openstack-dev'),('smelikyan@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('smoser@ubuntu.com','http://lists.openstack.org/pipermail/openstack-dev'),('smurugesan@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('snaiksat@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('snikitin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('snmohan83@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('snraju@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sogand.shirinbab@bth.se','http://lists.openstack.org/pipermail/openstack-dev'),('sombrafam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('songole@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('soniaverma9727@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('soren@linux2go.dk','http://lists.openstack.org/pipermail/openstack-dev'),('sorlando@nicira.com','http://lists.openstack.org/pipermail/openstack-dev'),('sorrison@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('soulxu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('souminathan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('souminathan@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('sowmini.varadhan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sowmya_nethi@persistent.co.in','http://lists.openstack.org/pipermail/openstack-dev'),('sparkofwisdom.cloud@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('spasquier@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('speilicke@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('sphoorti.joglekar@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('spzala@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('squall2m@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sragolu@mvista.com','http://lists.openstack.org/pipermail/openstack-dev'),('sreedhar.nathani@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sreshetniak@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('sri.networkid@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('srics.r@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sridevi.koushik@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('sridhar.basam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sridhar.gaddam@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('sridharas@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('srikanth.lingala@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('srikanthkumar.lingala@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sriram.madapusivasud@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('sriram@sriramhere.com','http://lists.openstack.org/pipermail/openstack-dev'),('srivastava.abhishek@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sross@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ss7pro@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ssantin.vf@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sskripnick@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('sstattla@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('stackeratul@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('stan.zgy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Stanislav_M@DELLTEAM.com','http://lists.openstack.org/pipermail/openstack-dev'),('stanislaw.pitucha@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('starodubcevna@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('stelfer@cray.com','http://lists.openstack.org/pipermail/openstack-dev'),('stelford@internap.com','http://lists.openstack.org/pipermail/openstack-dev'),('stendulker@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('stephen.gran@guardian.co.uk','http://lists.openstack.org/pipermail/openstack-dev'),('stephen.gran@theguardian.com','http://lists.openstack.org/pipermail/openstack-dev'),('stephen.kf.wong@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('stephen.ma@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('stephen.mulcahy@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('steve.lewis@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('steve.mclellan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('steve.varnau@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('steveloranz@me.com','http://lists.openstack.org/pipermail/openstack-dev'),('stevemar@ca.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('steven-weston@live.com','http://lists.openstack.org/pipermail/openstack-dev'),('steven.gonzales@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('steven.sonnenberg@hds.com','http://lists.openstack.org/pipermail/openstack-dev'),('steven.tran2@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('steven@wedontsleep.org','http://lists.openstack.org/pipermail/openstack-dev'),('stever@up-south.com','http://lists.openstack.org/pipermail/openstack-dev'),('stewartx.t.dale@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('sthakkar@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('stoner@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('stopmakingsense@gmx.de','http://lists.openstack.org/pipermail/openstack-dev'),('stpierre@metacloud.com','http://lists.openstack.org/pipermail/openstack-dev'),('stuart.mclaren@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('stuart@demonware.net','http://lists.openstack.org/pipermail/openstack-dev'),('stvchien@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('subbu@subbu.org','http://lists.openstack.org/pipermail/openstack-dev'),('subramanian.neelakantan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sudarshan.acharya@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sudeepgaddam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sudh03@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('sudhakar-babu.gariganti@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('sujay.m17@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sukhdev@aristanetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('sukhdevkapur@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sumansn@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('sumitkgaur@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sumitnaiksatam@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('sunil@embrane.com','http://lists.openstack.org/pipermail/openstack-dev'),('suolist@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('suro.patz@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Surya_Prabhakar@Dell.com','http://lists.openstack.org/pipermail/openstack-dev'),('susaant.kondapaneni@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('sushma_korati@persistent.com','http://lists.openstack.org/pipermail/openstack-dev'),('susltd.su@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('svasilenko@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('swaminathan.vasudevan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('swamireddy@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('swann.croiset@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('swannon@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('swapnilkulkarni2608@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('swaroop.jayanthi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('swati.shukla1@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('sweston@Brocade.com','http://lists.openstack.org/pipermail/openstack-dev'),('sxmatch1986@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('syed_hussain@persistent.co.in','http://lists.openstack.org/pipermail/openstack-dev'),('syerrapragada@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('sylvain.afchain@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('sylvain.bauza@bull.net','http://lists.openstack.org/pipermail/openstack-dev'),('sylvain.bauza@digimind.com','http://lists.openstack.org/pipermail/openstack-dev'),('sylvain.bauza@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('t.trifonov@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('t.v.ovtchinnikova@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('t.vo_hoang@telekom.de','http://lists.openstack.org/pipermail/openstack-dev'),('taehwan.koo@kt.com','http://lists.openstack.org/pipermail/openstack-dev'),('taget@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tagliapietra.alessandro@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('takase@axlbit.net','http://lists.openstack.org/pipermail/openstack-dev'),('takehiro.kaneko@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('tanqiwen1@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tapiotallgren@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('taras@glek.net','http://lists.openstack.org/pipermail/openstack-dev'),('tatiana.alchueyr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tauqeer.ahmad@rwth-aachen.de','http://lists.openstack.org/pipermail/openstack-dev'),('taurmi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Taurus.Cheung@harmonicinc.com','http://lists.openstack.org/pipermail/openstack-dev'),('tcvn1985@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tdeckers@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('tellesnobrega@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tengqim@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tengqim@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('teran.mckinney@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('termie@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('terry.gong@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tflower@ca.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tfreger@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('th@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('thang.pham@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('thawngv@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('the.doug.fish@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thefossgeek@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('therese.mchale@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('therve@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('the_akshat@yahoo.co.in','http://lists.openstack.org/pipermail/openstack-dev'),('thiagocmartinsc@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thiagop@lsd.ufcg.edu.br','http://lists.openstack.org/pipermail/openstack-dev'),('thierry.carrez@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('thingee@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thinrichs@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('thisisrmr@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thna@nm.gist.ac.kr','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.duesing@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.herve@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.maddox@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.morin@orange.com','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.pessione@orange.com','http://lists.openstack.org/pipermail/openstack-dev'),('thomas.spatzier@de.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('thomas@goirand.fr','http://lists.openstack.org/pipermail/openstack-dev'),('thomasagall@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thouveng@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thulasiram.valleru@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tiago.martins@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tiago@timello.info','http://lists.openstack.org/pipermail/openstack-dev'),('tietz@b1-systems.de','http://lists.openstack.org/pipermail/openstack-dev'),('tiffany.j.mathews@nasa.gov','http://lists.openstack.org/pipermail/openstack-dev'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('tim.kelsey@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tim.schnell@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('tim.simpson@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('Tim.Snider@netapp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tim@freunds.net','http://lists.openstack.org/pipermail/openstack-dev'),('timjr@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('Tina.Tsou.Zouting@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('tizy.elza@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tjones@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('tleontovich@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('tmazur@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('tmckay@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('tmello@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tnapierala@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('tnurlygayanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('tobias.engelbert@ericsson.com','http://lists.openstack.org/pipermail/openstack-dev'),('tom.cammann@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tom.creighton@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('Tom.Goulding@hds.com','http://lists.openstack.org/pipermail/openstack-dev'),('Tom.Hancock@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tom.howley@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack-dev'),('tom@tomleaman.co.uk','http://lists.openstack.org/pipermail/openstack-dev'),('tomasz.janczuk@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tomasz@janczuk.org','http://lists.openstack.org/pipermail/openstack-dev'),('tomoe@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('tomoki.sekiyama@hds.com','http://lists.openstack.org/pipermail/openstack-dev'),('tomoya.goto@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('tom_gall@vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('ton@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tony@bakeyournoodle.com','http://lists.openstack.org/pipermail/openstack-dev'),('tonytkdk@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tpb@dyncloud.net','http://lists.openstack.org/pipermail/openstack-dev'),('tpiperatgod@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tqtran@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('traceyzhang@siu.edu','http://lists.openstack.org/pipermail/openstack-dev'),('travis.mcpeak@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('travis.tripp@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Travis_McPeak@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('treinish@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('trevor.vardeman@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('trey.morris@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('trialsample7@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('trinath.somanchi@freescale.com','http://lists.openstack.org/pipermail/openstack-dev'),('trinath.somanchi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('tristan.cacqueray@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('tross@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('troy@tomanator.com','http://lists.openstack.org/pipermail/openstack-dev'),('trung.t.trinh@dektech.com.au','http://lists.openstack.org/pipermail/openstack-dev'),('tsedovic@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('tsmith@gridcentric.com','http://lists.openstack.org/pipermail/openstack-dev'),('tsufiev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('tsuyuzaki.kota@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('ttao@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('tuomas.paappanen@tieto.com','http://lists.openstack.org/pipermail/openstack-dev'),('tushar.bankar@izeltech.com','http://lists.openstack.org/pipermail/openstack-dev'),('Tushar.Patil@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('twilson@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('tyanqun@qq.com','http://lists.openstack.org/pipermail/openstack-dev'),('tynan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('tzumainn@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ubuntu@consolejunkie.net','http://lists.openstack.org/pipermail/openstack-dev'),('uditanan7@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ugearth@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('ukalifon@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ulrich.schwickerath@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('uma.goring@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('unicell@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('unmesh.gurjar@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('unmesh.gurjar@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('Unmesh.Gurjar@nttdata.com','http://lists.openstack.org/pipermail/openstack-dev'),('uri.elzur@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('uri@gigaspaces.com','http://lists.openstack.org/pipermail/openstack-dev'),('uri_simchoni@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vachon@sessionm.com','http://lists.openstack.org/pipermail/openstack-dev'),('vadivel.openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('valerie.fenwick@oracle.com','http://lists.openstack.org/pipermail/openstack-dev'),('Varun_Lodaya@symantec.com','http://lists.openstack.org/pipermail/openstack-dev'),('vbalachandran@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('vbannai@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vbellur@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('veblush+openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vedlad@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('venkatesh.nag@wipro.com','http://lists.openstack.org/pipermail/openstack-dev'),('venkatesh.sampath@outlook.com','http://lists.openstack.org/pipermail/openstack-dev'),('venza@brownhat.org','http://lists.openstack.org/pipermail/openstack-dev'),('veronica.a.musso@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('vey.julien@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vibhuvardhan.bontala@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('vickymsee@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vickyramuk4u@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('victor.lowther@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('victor.stinner@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('victoria@vmartinezdelacruz.com','http://lists.openstack.org/pipermail/openstack-dev'),('Vijay.Venkatachalam@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('vijayakumar.kodam.ext@nsn.com','http://lists.openstack.org/pipermail/openstack-dev'),('vijayendrabvs@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vijayrg@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('vijendar.komalla@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-dev'),('vikasd@yahoo.com','http://lists.openstack.org/pipermail/openstack-dev'),('vikash.kumar@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-dev'),('vikaskokare@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vikram.choudhary@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('viktor@szepe.net','http://lists.openstack.org/pipermail/openstack-dev'),('vilobhmm@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('vinayak.shinde@clogeny.com','http://lists.openstack.org/pipermail/openstack-dev'),('vinayyadhav@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vinbs@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('vincenzo.di.somma@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('vinod.borole@gslab.com','http://lists.openstack.org/pipermail/openstack-dev'),('vinod.kumar.boppanna@cern.ch','http://lists.openstack.org/pipermail/openstack-dev'),('vinod.kumar5@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('vipuls@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('virtualserver4@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vishal2.agarwal@aricent.com','http://lists.openstack.org/pipermail/openstack-dev'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('visnusaran.murugan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('vitas.yuzhou@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('vitdua@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vivekanandan.narasimhan@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('vivekcherian@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('VIVEKJAIN@ebay.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkkumar.live@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkolosov@griddynamics.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkozhukalov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkramskikh@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkuklin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vkuzmin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vladik.romanovsky@enovance.com','http://lists.openstack.org/pipermail/openstack-dev'),('vladimir@zadarastorage.com','http://lists.openstack.org/pipermail/openstack-dev'),('vmendez@pic.es','http://lists.openstack.org/pipermail/openstack-dev'),('vmthunder.group@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('volmar.junior@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('vparakhin@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vponomaryov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vsergeyev@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vsharathis@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('vsharshov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('vstinner@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('vthapar@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('vuichiap@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('vuntz@suse.com','http://lists.openstack.org/pipermail/openstack-dev'),('w.wanghong1@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('w1z2g3@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('walter.boring@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('wan-yen.hsu@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('wanghao749@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('wanghaomeng@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('wanghaomeng@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wanglm@certusnet.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('wanyenhsu@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wateringcan@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wayne.foley@hp.com','http://lists.openstack.org/pipermail/openstack-dev'),('wdec.ietf@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wdunn@mailtrust.com','http://lists.openstack.org/pipermail/openstack-dev'),('wei.d.chen@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('weidu@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('weiyuanke123@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wenhao@zelin.io','http://lists.openstack.org/pipermail/openstack-dev'),('wenjian@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('wenjianhn@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wentian@unitedstack.com','http://lists.openstack.org/pipermail/openstack-dev'),('wfoster@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('whenry@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('wijet@wijet.pl','http://lists.openstack.org/pipermail/openstack-dev'),('willian.molinari@locaweb.com.br','http://lists.openstack.org/pipermail/openstack-dev'),('willowd878@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wingwj@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('winson.c.chan@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('winston.d@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wiwang@vmware.com','http://lists.openstack.org/pipermail/openstack-dev'),('wolf@cs.cmu.edu','http://lists.openstack.org/pipermail/openstack-dev'),('woppin@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wpf710@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wpward@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('wpward@us.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('wqyuwss@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ws1210@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('wuhongning@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('wujiangtaohehe@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('wuse.kalrey@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xarses@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xavi.leon@midokura.com','http://lists.openstack.org/pipermail/openstack-dev'),('xchenum@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xiake9527@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xianchaobo@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('xiaoding1@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('xiaohui.xin@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('xiaoquqi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xicoloco@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xing.yang@emc.com','http://lists.openstack.org/pipermail/openstack-dev'),('Xingjun.Chu@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('xingtianyi@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xiu.yushen@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xnhp0320@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xrefs.info@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xuanlangjian@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('xuhj@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('xu_zhong_xing@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('xyzjerry@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('y-goto@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('yacine@alyseo.com','http://lists.openstack.org/pipermail/openstack-dev'),('yaguang.tang@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('yalei.wang@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yamahata@valinux.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('yamahataml@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yamamoto@valinux.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('yamazaki-mitsuhiko@cnt.mxc.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('yamini.sardana@tcs.com','http://lists.openstack.org/pipermail/openstack-dev'),('yamini.sridaran@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yanchao727@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yangbaohua@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yangxurong@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('yann.fouillat.ext@makina-corpus.com','http://lists.openstack.org/pipermail/openstack-dev'),('Yapeng.Wu@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('yapengwu@me.com','http://lists.openstack.org/pipermail/openstack-dev'),('yatinkumbhare@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yegang_no.1@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('yfried@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('yfx_at_ibm@163.com','http://lists.openstack.org/pipermail/openstack-dev'),('yi.y.yang@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yige2008123@126.com','http://lists.openstack.org/pipermail/openstack-dev'),('yiya@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('yj.yuan@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('ykaneko0929@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('ykaul@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('ylobankov@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('yogesh.prasad@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-dev'),('yolanda.robla@canonical.com','http://lists.openstack.org/pipermail/openstack-dev'),('yongiman@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yongli.he@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yoobright89@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yorik.sar@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yoshitaka.kato@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('Youcef.Laribi@citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('Youcef.Laribi@eu.citrix.com','http://lists.openstack.org/pipermail/openstack-dev'),('ypraveen@avinetworks.com','http://lists.openstack.org/pipermail/openstack-dev'),('yshovkoplias@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('yst1@students.waikato.ac.nz','http://lists.openstack.org/pipermail/openstack-dev'),('yu@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-dev'),('yuan.zhou@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yuanotes@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yuanying@oeilvert.org','http://lists.openstack.org/pipermail/openstack-dev'),('yudupi@cisco.com','http://lists.openstack.org/pipermail/openstack-dev'),('yueli.m@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yufang521247@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Yuling_C@DELL.com','http://lists.openstack.org/pipermail/openstack-dev'),('yunhong.jiang@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yunhong.jiang@linux.intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('yunlingzeng@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yunmao@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('Yuriy.Babenko@telekom.de','http://lists.openstack.org/pipermail/openstack-dev'),('yusuke@jbking.org','http://lists.openstack.org/pipermail/openstack-dev'),('yuyangbj@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('yuzawataka@intellilink.co.jp','http://lists.openstack.org/pipermail/openstack-dev'),('yvempati@ebaysf.com','http://lists.openstack.org/pipermail/openstack-dev'),('yves-gwenael.bourhis@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-dev'),('yyos1999@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('yzveryanskyy@mirantis.com','http://lists.openstack.org/pipermail/openstack-dev'),('z-launchpad@brim.net','http://lists.openstack.org/pipermail/openstack-dev'),('zabolzadeh@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zaitcev@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('zaknafein.lee@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zanella.stefano@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zaro0508@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zbitter@redhat.com','http://lists.openstack.org/pipermail/openstack-dev'),('zdyu2000@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zealot0630@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zehndton@students.zhaw.ch','http://lists.openstack.org/pipermail/openstack-dev'),('zfx0906@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhang.john.vmthunder@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhang.lei.fly@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhangcan@letv.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhangleiqiang@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhangleiqiang@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhangni@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhangyu11@huawei.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhengpeng-hou@ubuntu.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhenzan.zhou@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhikunli@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhipengh512@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhiweik@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhongyue.luo@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhongyue.nah@intel.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhuadl@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-dev'),('zhuhq@certusnet.com.cn','http://lists.openstack.org/pipermail/openstack-dev'),('ziad.sawalha@rackspace.com','http://lists.openstack.org/pipermail/openstack-dev'),('ziad@sawalha.com','http://lists.openstack.org/pipermail/openstack-dev'),('zigo@debian.org','http://lists.openstack.org/pipermail/openstack-dev'),('zou.yun@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-dev'),('zr.zz.alp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zrzhit@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zsolt@cyaninc.com','http://lists.openstack.org/pipermail/openstack-dev'),('ztralon@hotmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zuocheng2009@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zzelle@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('zzningxp@gmail.com','http://lists.openstack.org/pipermail/openstack-dev'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('adam.morris@multiscalehn.com','http://lists.openstack.org/pipermail/openstack-docs'),('adugas@vmware.com','http://lists.openstack.org/pipermail/openstack-docs'),('ahmeda@cs.umu.se','http://lists.openstack.org/pipermail/openstack-docs'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-docs'),('aji.zqfan@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('ajku.agr@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('akilesh1597@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('alawson@aqorn.com','http://lists.openstack.org/pipermail/openstack-docs'),('alexandra.settle@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('alopgeek@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('alvise.dorigo@pd.infn.it','http://lists.openstack.org/pipermail/openstack-docs'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('andrew@andrewspiers.net','http://lists.openstack.org/pipermail/openstack-docs'),('anil.gunturu@riftio.com','http://lists.openstack.org/pipermail/openstack-docs'),('anlin.kong@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('anne.gentle@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-docs'),('annegentle@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('annegentle@justwriteclick.com','http://lists.openstack.org/pipermail/openstack-docs'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-docs'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('arkadiusz.chylinski@intel.com','http://lists.openstack.org/pipermail/openstack-docs'),('Atul.Jha@csscorp.com','http://lists.openstack.org/pipermail/openstack-docs'),('ayurchuk@minuteware.net','http://lists.openstack.org/pipermail/openstack-docs'),('B39209@freescale.com','http://lists.openstack.org/pipermail/openstack-docs'),('balamuruganvg@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('baspeters93@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('bdobrelia@mirantis.com','http://lists.openstack.org/pipermail/openstack-docs'),('bdpayne@acm.org','http://lists.openstack.org/pipermail/openstack-docs'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/openstack-docs'),('brandon.logan@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('brian.schott@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-docs'),('cbkyeoh@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('chandankumar.093047@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('chayma87@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('chris.friesen@windriver.com','http://lists.openstack.org/pipermail/openstack-docs'),('chris@pushiq.com','http://lists.openstack.org/pipermail/openstack-docs'),('christian@berendt.io','http://lists.openstack.org/pipermail/openstack-docs'),('clark.boylan@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Colin.McNamara@NexusIS.com','http://lists.openstack.org/pipermail/openstack-docs'),('colin@2cups.com','http://lists.openstack.org/pipermail/openstack-docs'),('comnea.dani@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/openstack-docs'),('cyril.roelandt@enovance.com','http://lists.openstack.org/pipermail/openstack-docs'),('dan.florea@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('danehans@cisco.com','http://lists.openstack.org/pipermail/openstack-docs'),('daniel2d2art@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('dara2002-openstack@yahoo.com','http://lists.openstack.org/pipermail/openstack-docs'),('darragh.oreilly@yahoo.com','http://lists.openstack.org/pipermail/openstack-docs'),('david.cramer@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('david.medberry@twcable.com','http://lists.openstack.org/pipermail/openstack-docs'),('david@thingbag.net','http://lists.openstack.org/pipermail/openstack-docs'),('dazzachan@yahoo.com.au','http://lists.openstack.org/pipermail/openstack-docs'),('ddomingo@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('Debra.J.Williams@pearson.com','http://lists.openstack.org/pipermail/openstack-docs'),('deejay1@srem.org','http://lists.openstack.org/pipermail/openstack-docs'),('deepak.mane@tcs.com','http://lists.openstack.org/pipermail/openstack-docs'),('denisbatgm@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('devananda.vdv@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('dfleming@austin.rr.com','http://lists.openstack.org/pipermail/openstack-docs'),('dguitarbite@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('diane.fleming@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('Dj_dark_junglist@yahoo.com','http://lists.openstack.org/pipermail/openstack-docs'),('dleeuw@made-it.com','http://lists.openstack.org/pipermail/openstack-docs'),('dmercer@fantoccini.com','http://lists.openstack.org/pipermail/openstack-docs'),('dnavale@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('dneary@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('dob12460@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-docs'),('doug.hellmann@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('duyujie.dyj@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('dyocum@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('edgar.magana@workday.com','http://lists.openstack.org/pipermail/openstack-docs'),('eduard.barrera@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('ejkern@mac.com','http://lists.openstack.org/pipermail/openstack-docs'),('elkev@yahoo.com','http://lists.openstack.org/pipermail/openstack-docs'),('emagana@plumgrid.com','http://lists.openstack.org/pipermail/openstack-docs'),('emilien.macchi@enovance.com','http://lists.openstack.org/pipermail/openstack-docs'),('emilien.macchi@stackops.com','http://lists.openstack.org/pipermail/openstack-docs'),('emilien@enovance.com','http://lists.openstack.org/pipermail/openstack-docs'),('eperdomo@cisco.com','http://lists.openstack.org/pipermail/openstack-docs'),('evgeny.fadeev@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('fifieldt@unimelb.edu.au','http://lists.openstack.org/pipermail/openstack-docs'),('firatkucuk@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('florian@hastexo.com','http://lists.openstack.org/pipermail/openstack-docs'),('francois.bureau@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-docs'),('frans@meruvian.org','http://lists.openstack.org/pipermail/openstack-docs'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-docs'),('gang.sungjin@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('gauvain.pocentek@objectif-libre.com','http://lists.openstack.org/pipermail/openstack-docs'),('gerrit2@review.openstack.org','http://lists.openstack.org/pipermail/openstack-docs'),('giuseppegaleota@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('googcheng@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Greg.Waines@windriver.com','http://lists.openstack.org/pipermail/openstack-docs'),('guanxiaohua2k6@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('guoyingc@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('hammondjohnson@hushmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('harry.sutton@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('hasegawa@bit-isle.co.jp','http://lists.openstack.org/pipermail/openstack-docs'),('ijw.ubuntu@cack.org.uk','http://lists.openstack.org/pipermail/openstack-docs'),('jamie.hannaford@rackspace.com','http://lists.openstack.org/pipermail/openstack-docs'),('jason.bishop@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('jasper.aikema@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('jidawanghao@163.com','http://lists.openstack.org/pipermail/openstack-docs'),('joe.topjian@cybera.ca','http://lists.openstack.org/pipermail/openstack-docs'),('joe@topjian.net','http://lists.openstack.org/pipermail/openstack-docs'),('jogo@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-docs'),('John.Garbutt@citrix.com','http://lists.openstack.org/pipermail/openstack-docs'),('john@dewey.ws','http://lists.openstack.org/pipermail/openstack-docs'),('jon@csail.mit.edu','http://lists.openstack.org/pipermail/openstack-docs'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/openstack-docs'),('jorge.williams@rackspace.com','http://lists.openstack.org/pipermail/openstack-docs'),('joseph.robinson@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('jpierce@flyingspress.com','http://lists.openstack.org/pipermail/openstack-docs'),('julien@danjou.info','http://lists.openstack.org/pipermail/openstack-docs'),('karin.levenstein@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('kennethpjdyer@fastmail.us','http://lists.openstack.org/pipermail/openstack-docs'),('kersten@us.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('kesten.broughton@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('kevin@linuxservices.co.uk','http://lists.openstack.org/pipermail/openstack-docs'),('lalitha.maruthachalam@aricent.com','http://lists.openstack.org/pipermail/openstack-docs'),('laura.adq@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('lijiangsheng1@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Lincoln.Thomas@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('lisa.m.marino@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('lismarino@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('lmichaels@tesora.com','http://lists.openstack.org/pipermail/openstack-docs'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-docs'),('lorinh@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('lpetrut@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-docs'),('lyarwood@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('lyz@princessleia.com','http://lists.openstack.org/pipermail/openstack-docs'),('mail@lanabrindley.com','http://lists.openstack.org/pipermail/openstack-docs'),('maishsk+openstack@maishsk.com','http://lists.openstack.org/pipermail/openstack-docs'),('Marco.Fornaro@huawei.com','http://lists.openstack.org/pipermail/openstack-docs'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('mark@collierclan.net','http://lists.openstack.org/pipermail/openstack-docs'),('masanori.itoh@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('matarazzoangelo@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Matjaz.Pancur@fri.uni-lj.si','http://lists.openstack.org/pipermail/openstack-docs'),('matt.griffin@percona.com','http://lists.openstack.org/pipermail/openstack-docs'),('matt.kassawara@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('mbasnight@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('michael.still@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-docs'),('mike.asthalter@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('miranda.zhang.q@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('mjfork@us.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('mkassawara@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('mkkang@isi.edu','http://lists.openstack.org/pipermail/openstack-docs'),('mmosesohn@mirantis.com','http://lists.openstack.org/pipermail/openstack-docs'),('mspreitz@us.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('mzoeller@de.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('n.chaand@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('nachi@ntti3.com','http://lists.openstack.org/pipermail/openstack-docs'),('nchase@mirantis.com','http://lists.openstack.org/pipermail/openstack-docs'),('nerminamiller@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('nikhil@manchanda.me','http://lists.openstack.org/pipermail/openstack-docs'),('nmiller@mirantis.com','http://lists.openstack.org/pipermail/openstack-docs'),('obuisson1976@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('olivier.desport@ac-versailles.fr','http://lists.openstack.org/pipermail/openstack-docs'),('openstack@lanabrindley.com','http://lists.openstack.org/pipermail/openstack-docs'),('openstack@medberry.net','http://lists.openstack.org/pipermail/openstack-docs'),('phil.hopkins@rackspace.com','http://lists.openstack.org/pipermail/openstack-docs'),('pieter.c.kruithof-jr@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('pps.pranav@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('pveijk@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Randy_Perryman@Dell.com','http://lists.openstack.org/pipermail/openstack-docs'),('razique.mahroua@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('rbowen@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('realworker99@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('reza@dslextreme.com','http://lists.openstack.org/pipermail/openstack-docs'),('rfontana@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('rl@patchworkscience.org','http://lists.openstack.org/pipermail/openstack-docs'),('rmoats@us.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('robb.romans@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('roberto.sassu@polito.it','http://lists.openstack.org/pipermail/openstack-docs'),('rose.coste@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('roxenham@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('sam.harwell@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-docs'),('sankarshan.mukhopadhyay@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('sayali.92720@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('sdeaton2@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('seanr@vmware.com','http://lists.openstack.org/pipermail/openstack-docs'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-docs'),('seanroberts66@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('Sean_Collins2@cable.comcast.com','http://lists.openstack.org/pipermail/openstack-docs'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('shake.chen@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('shanker.mani0@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('shaunm@gnome.org','http://lists.openstack.org/pipermail/openstack-docs'),('shiori.toyo@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('shuangtai.tian@intel.com','http://lists.openstack.org/pipermail/openstack-docs'),('slong@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-docs'),('sombrafam@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('spbatra@us.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('sriram@sriramhere.com','http://lists.openstack.org/pipermail/openstack-docs'),('sross@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('stackeratul@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-docs'),('stevemar@ca.ibm.com','http://lists.openstack.org/pipermail/openstack-docs'),('stuart@demonware.net','http://lists.openstack.org/pipermail/openstack-docs'),('sumitnaiksatam@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('swaminathan.vasudevan@hp.com','http://lists.openstack.org/pipermail/openstack-docs'),('takehiro.kaneko@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack-docs'),('Tamara.Johnston@emc.com','http://lists.openstack.org/pipermail/openstack-docs'),('taroth@suse.com','http://lists.openstack.org/pipermail/openstack-docs'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack-docs'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack-docs'),('tomo@dream.daynight.jp','http://lists.openstack.org/pipermail/openstack-docs'),('vadivel.openstack@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('vhosakot@cisco.com','http://lists.openstack.org/pipermail/openstack-docs'),('vivekcherian@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('vvaldez@redhat.com','http://lists.openstack.org/pipermail/openstack-docs'),('Will_Newby@discovery.com','http://lists.openstack.org/pipermail/openstack-docs'),('yongli.he@intel.com','http://lists.openstack.org/pipermail/openstack-docs'),('yorik.sar@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('yunhong.jiang@intel.com','http://lists.openstack.org/pipermail/openstack-docs'),('zaro0508@gmail.com','http://lists.openstack.org/pipermail/openstack-docs'),('zigo@debian.org','http://lists.openstack.org/pipermail/openstack-docs'),('ajyounge@indiana.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('alan.sill@ttu.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('andrei.a.vakhnin@nasa.gov','http://lists.openstack.org/pipermail/openstack-hpc'),('antonio.s.messina@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('Ashiq.Anjum@cern.ch','http://lists.openstack.org/pipermail/openstack-hpc'),('ayoung@redhat.com','http://lists.openstack.org/pipermail/openstack-hpc'),('bp@us.ibm.com','http://lists.openstack.org/pipermail/openstack-hpc'),('brian.schott@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-hpc'),('cdl@asgaard.org','http://lists.openstack.org/pipermail/openstack-hpc'),('cjg23@psu.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('colin@2cups.com','http://lists.openstack.org/pipermail/openstack-hpc'),('daniel.westervelt@canonical.com','http://lists.openstack.org/pipermail/openstack-hpc'),('dave.ojika@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('dipeit@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('dkang@isi.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('Eric.Christensen@sanofi.com','http://lists.openstack.org/pipermail/openstack-hpc'),('hailybrown@hushmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('hearnsj@googlemail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('jerome.pansanel@iphc.cnrs.fr','http://lists.openstack.org/pipermail/openstack-hpc'),('john.hearns@mclaren.com','http://lists.openstack.org/pipermail/openstack-hpc'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/openstack-hpc'),('Jonathon.Anderson@Colorado.EDU','http://lists.openstack.org/pipermail/openstack-hpc'),('josh@knoesis.org','http://lists.openstack.org/pipermail/openstack-hpc'),('jpr@uab.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('jsuh@isi.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('juanfra.rodriguez.cardoso@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('jwalters@isi.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('k.wasielewska@fedcsis.org','http://lists.openstack.org/pipermail/openstack-hpc'),('katarzyna.wasielewska.scpe@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('kbs@cray.com','http://lists.openstack.org/pipermail/openstack-hpc'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-hpc'),('mkkang@isi.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('mlovos@computer.org','http://lists.openstack.org/pipermail/openstack-hpc'),('narayan.desai@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('parrott@g.harvard.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('patrick.michel.petit@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('patrick.petit@bull.net','http://lists.openstack.org/pipermail/openstack-hpc'),('paul.rad@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-hpc'),('pegasus@nerv.eu.org','http://lists.openstack.org/pipermail/openstack-hpc'),('phab.lucky@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('ppk@idre.ucla.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('scott.a.mcmillan@intel.com','http://lists.openstack.org/pipermail/openstack-hpc'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-hpc'),('theo@stillwater-sc.com','http://lists.openstack.org/pipermail/openstack-hpc'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack-hpc'),('vangelis@simula.no','http://lists.openstack.org/pipermail/openstack-hpc'),('vhpc.dist@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('wojtek.goscinski@monash.edu','http://lists.openstack.org/pipermail/openstack-hpc'),('zebra.x0r@gmail.com','http://lists.openstack.org/pipermail/openstack-hpc'),('295988511@qq.com','http://lists.openstack.org/pipermail/openstack-infra'),('aaron@greenbtn.com','http://lists.openstack.org/pipermail/openstack-infra'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('abhishek@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-infra'),('achuprin@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('agrimberg@linuxfoundation.org','http://lists.openstack.org/pipermail/openstack-infra'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-infra'),('ajku.agr@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('Alka.Deshpande@oracle.com','http://lists.openstack.org/pipermail/openstack-infra'),('ALONMA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('amit.das@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-infra'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('Andrew.Kerr@netapp.com','http://lists.openstack.org/pipermail/openstack-infra'),('andrew.plunk@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('andrew@nocturnal.net.au','http://lists.openstack.org/pipermail/openstack-infra'),('Andy_S@Dell.com','http://lists.openstack.org/pipermail/openstack-infra'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-infra'),('anthony.michon@eurogiciel.fr','http://lists.openstack.org/pipermail/openstack-infra'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('apilotti@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-infra'),('arxcruz@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('asmundo@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('avib@mellanox.com','http://lists.openstack.org/pipermail/openstack-infra'),('AvishayB@Radware.com','http://lists.openstack.org/pipermail/openstack-infra'),('ayshihanzhang@126.com','http://lists.openstack.org/pipermail/openstack-infra'),('ben.lahoucine@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('Ben.Swartzlander@netapp.com','http://lists.openstack.org/pipermail/openstack-infra'),('ben@swartzlander.org','http://lists.openstack.org/pipermail/openstack-infra'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/openstack-infra'),('berrange@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('bharat.kobagana@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('bigzhao@cisco.com','http://lists.openstack.org/pipermail/openstack-infra'),('blak111@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/openstack-infra'),('bpavlovic@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('brian.haley@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('brian.lamar@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('brian.ruff@oracle.com','http://lists.openstack.org/pipermail/openstack-infra'),('btopol@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('bwiedemann@suse.de','http://lists.openstack.org/pipermail/openstack-infra'),('camunoz@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('caperry@edolnx.net','http://lists.openstack.org/pipermail/openstack-infra'),('cboylan@sapwetik.org','http://lists.openstack.org/pipermail/openstack-infra'),('chenglch@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('chmouel@chmouel.com','http://lists.openstack.org/pipermail/openstack-infra'),('chmouel@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('christian.schwede@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('chsu@swiftstack.com','http://lists.openstack.org/pipermail/openstack-infra'),('chuck.short@canonical.com','http://lists.openstack.org/pipermail/openstack-infra'),('clark.boylan@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('clint@fewbar.com','http://lists.openstack.org/pipermail/openstack-infra'),('cody.somerville@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('coolsvap@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('corvus@gnu.org','http://lists.openstack.org/pipermail/openstack-infra'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/openstack-infra'),('csaba@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('cyril.roelandt@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('dan.fields@nexenta.com','http://lists.openstack.org/pipermail/openstack-infra'),('dan.stangel@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('daragh.bailey@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('davanum@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('dave.birdsall@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('dave.walker@canonical.com','http://lists.openstack.org/pipermail/openstack-infra'),('david.kranz@qrclab.com','http://lists.openstack.org/pipermail/openstack-infra'),('david.medberry@canonical.com','http://lists.openstack.org/pipermail/openstack-infra'),('david.pineau@scality.com','http://lists.openstack.org/pipermail/openstack-infra'),('davidy@vmware.com','http://lists.openstack.org/pipermail/openstack-infra'),('daya_k@yahoo.com','http://lists.openstack.org/pipermail/openstack-infra'),('dbailey@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('dbelova@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('dcaroest@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('deejay1@srem.org','http://lists.openstack.org/pipermail/openstack-infra'),('denny@unitedstack.com','http://lists.openstack.org/pipermail/openstack-infra'),('derekh@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('devdatta.kulkarni@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('dguitarbite@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('dl-ebay-serengeti-admin@ebay.com','http://lists.openstack.org/pipermail/openstack-infra'),('dmescheryakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-infra'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/openstack-infra'),('dougw@a10networks.com','http://lists.openstack.org/pipermail/openstack-infra'),('dpkshetty@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('dprince@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('dpyzhov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('dradez@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('dstanek@dstanek.com','http://lists.openstack.org/pipermail/openstack-infra'),('dteselkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('e0ne@e0ne.info','http://lists.openstack.org/pipermail/openstack-infra'),('Eamonn.OToole@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('eantyshev@parallels.com','http://lists.openstack.org/pipermail/openstack-infra'),('EBalduf@fusionio.com','http://lists.openstack.org/pipermail/openstack-infra'),('edgar.magana@workday.com','http://lists.openstack.org/pipermail/openstack-infra'),('edlin@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('eduard.matei@cloudfounders.com','http://lists.openstack.org/pipermail/openstack-infra'),('edwin.wang@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('eli@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('emagana@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('emagana@plumgrid.com','http://lists.openstack.org/pipermail/openstack-infra'),('email@daviey.com','http://lists.openstack.org/pipermail/openstack-infra'),('emilien.macchi@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('fabre.arnaud@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('flavio@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('florian.schmidt.welzow@t-online.de','http://lists.openstack.org/pipermail/openstack-infra'),('franck.yelles@nuagenetworks.net','http://lists.openstack.org/pipermail/openstack-infra'),('franck110@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('frederic.lepied@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-infra'),('gallard.jerome@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('gang.sungjin@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('garyduan@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('gchamoul@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('gduan@varmour.com','http://lists.openstack.org/pipermail/openstack-infra'),('gessau@cisco.com','http://lists.openstack.org/pipermail/openstack-infra'),('giri.basava@triliodata.com','http://lists.openstack.org/pipermail/openstack-infra'),('guillaume.thouvenin@bull.net','http://lists.openstack.org/pipermail/openstack-infra'),('guoyingc@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('guslees@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('gvenkat@Brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('habdi@microsoft.com','http://lists.openstack.org/pipermail/openstack-infra'),('hailybrown@hushmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('hardworkor@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-infra'),('hashar@free.fr','http://lists.openstack.org/pipermail/openstack-infra'),('herseeing@126.com','http://lists.openstack.org/pipermail/openstack-infra'),('hguoqing@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('ichihara.hirofumi@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-infra'),('idopra@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('ihrachys@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('ishakhat@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('isviridov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('iwienand@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('IzikP@Radware.com','http://lists.openstack.org/pipermail/openstack-infra'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('jbrendel@cisco.com','http://lists.openstack.org/pipermail/openstack-infra'),('jcoufal@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('jeeloo@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('jesse.keating@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('jesusaurus@mail.com','http://lists.openstack.org/pipermail/openstack-infra'),('jgb@bitergia.com','http://lists.openstack.org/pipermail/openstack-infra'),('jimmy@tipit.net','http://lists.openstack.org/pipermail/openstack-infra'),('jishaom@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('jishaomei2009@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-infra'),('jolyon@limilo.com','http://lists.openstack.org/pipermail/openstack-infra'),('joshua.hesketh@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('jp@jamezpolley.com','http://lists.openstack.org/pipermail/openstack-infra'),('jpichon@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('jrnieder@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('jufeng@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('jwang@nimblestorage.com','http://lists.openstack.org/pipermail/openstack-infra'),('kchamart@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('kevin.benton@bigswitch.com','http://lists.openstack.org/pipermail/openstack-infra'),('kevin.mitchell@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('kgiusti@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('kristian@oellegaard.com','http://lists.openstack.org/pipermail/openstack-infra'),('krotscheck@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('krtaylor@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('krum.spencer@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('kurt.griffiths@rackspace.com','http://lists.openstack.org/pipermail/openstack-infra'),('kurt.r.taylor@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('kvmpower@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('lahoucine@benlahmr.com','http://lists.openstack.org/pipermail/openstack-infra'),('laura.adq@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('leandro.i.costantino@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('leblancd@cisco.com','http://lists.openstack.org/pipermail/openstack-infra'),('legiangthanh@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('litong01@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('liuxinguo@huawei.com','http://lists.openstack.org/pipermail/openstack-infra'),('llincdl@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('loic@dachary.org','http://lists.openstack.org/pipermail/openstack-infra'),('longgeek@thstack.com','http://lists.openstack.org/pipermail/openstack-infra'),('lsurette@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('lucas@midokura.com','http://lists.openstack.org/pipermail/openstack-infra'),('luke@snabb.co','http://lists.openstack.org/pipermail/openstack-infra'),('lyz@princessleia.com','http://lists.openstack.org/pipermail/openstack-infra'),('m.koderer@telekom.de','http://lists.openstack.org/pipermail/openstack-infra'),('mail@cgoncalves.pt','http://lists.openstack.org/pipermail/openstack-infra'),('malini.kamalambal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('marcusvrn@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('maria.vinatoru@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('marton.kiss@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mate.lakat@citrix.com','http://lists.openstack.org/pipermail/openstack-infra'),('mathieu.rohon@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('matt.kovacs@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('matt@getchef.com','http://lists.openstack.org/pipermail/openstack-infra'),('maxiao@unitedstack.com','http://lists.openstack.org/pipermail/openstack-infra'),('mayu.xa.0101@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mb@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('me@jaybuff.com','http://lists.openstack.org/pipermail/openstack-infra'),('me@mark.atwood.name','http://lists.openstack.org/pipermail/openstack-infra'),('me@not.mn','http://lists.openstack.org/pipermail/openstack-infra'),('meera.belur@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('mehdi.abaakouk@enovance.com','http://lists.openstack.org/pipermail/openstack-infra'),('mestery@mestery.com','http://lists.openstack.org/pipermail/openstack-infra'),('mgagne@iweb.com','http://lists.openstack.org/pipermail/openstack-infra'),('mhanif@brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('mihailmed@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-infra'),('mike.heald@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('mkassawara@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mmcclain@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-infra'),('mmosesohn@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack-infra'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('motoki@da.jp.nec.com','http://lists.openstack.org/pipermail/openstack-infra'),('mozawa@cloudian.com','http://lists.openstack.org/pipermail/openstack-infra'),('mriedem@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('mrodden@us.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('msabramo@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack-infra'),('mvineetmenon@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('mzigavzquez@paypal.com','http://lists.openstack.org/pipermail/openstack-infra'),('naehring@b1-systems.de','http://lists.openstack.org/pipermail/openstack-infra'),('naggappan@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('Navneet.Singh@netapp.com','http://lists.openstack.org/pipermail/openstack-infra'),('nchase@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('nemowiki@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('nilakhya.chatterjee@globallogic.com','http://lists.openstack.org/pipermail/openstack-infra'),('nkoshikov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('nuritv@mellanox.com','http://lists.openstack.org/pipermail/openstack-infra'),('nxtsheepdogci@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('ociuhandu@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-infra'),('ogelbukh@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('omrim@mellanox.com','http://lists.openstack.org/pipermail/openstack-infra'),('openstack.ci@solidfire.com','http://lists.openstack.org/pipermail/openstack-infra'),('openstack.org@michael-prokop.at','http://lists.openstack.org/pipermail/openstack-infra'),('openstack@nemebean.com','http://lists.openstack.org/pipermail/openstack-infra'),('openstack@rohankanade.com','http://lists.openstack.org/pipermail/openstack-infra'),('P@draigBrady.com','http://lists.openstack.org/pipermail/openstack-infra'),('Parashuram.Hallur@emc.com','http://lists.openstack.org/pipermail/openstack-infra'),('parikshit.manur@citrix.com','http://lists.openstack.org/pipermail/openstack-infra'),('parimalaprahlada@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('pattabi@Brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('paul.belanger@polybeacon.com','http://lists.openstack.org/pipermail/openstack-infra'),('philip.schwartz@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('praneetb@juniper.net','http://lists.openstack.org/pipermail/openstack-infra'),('psedlak@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('psp0808@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('punith.s@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-infra'),('pviswaku@yahoo.com','http://lists.openstack.org/pipermail/openstack-infra'),('qsongbvt@163.com','http://lists.openstack.org/pipermail/openstack-infra'),('rafaelfolco@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('rainya.mosher@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('ramy.asselin@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('renlet@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('review@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('rhsu@vmware.com','http://lists.openstack.org/pipermail/openstack-infra'),('ricardo.carrillo.cruz@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('Richard.Hedlind@X-IO.com','http://lists.openstack.org/pipermail/openstack-infra'),('rick.chen@prophetstor.com','http://lists.openstack.org/pipermail/openstack-infra'),('rkamaldinov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/openstack-infra'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack-infra'),('roeyc@mellanox.com','http://lists.openstack.org/pipermail/openstack-infra'),('rrugge@juniper.net','http://lists.openstack.org/pipermail/openstack-infra'),('rvyalov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('Sam.Wan@emc.com','http://lists.openstack.org/pipermail/openstack-infra'),('SamuelB@Radware.com','http://lists.openstack.org/pipermail/openstack-infra'),('sandy.walsh@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-infra'),('santiago.b.baldassin@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('saper@saper.info','http://lists.openstack.org/pipermail/openstack-infra'),('sasikanth.eda@in.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-infra'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-infra'),('Sean_McGinnis@DELL.com','http://lists.openstack.org/pipermail/openstack-infra'),('sergio.j.cazzolato@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('shannon.bigelow@nexenta.com','http://lists.openstack.org/pipermail/openstack-infra'),('sharis@Brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('skolekonov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('smurugesan@vmware.com','http://lists.openstack.org/pipermail/openstack-infra'),('snikitin@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('sombrafam@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sorlando@nicira.com','http://lists.openstack.org/pipermail/openstack-infra'),('sramanathan@infoblox.com','http://lists.openstack.org/pipermail/openstack-infra'),('sross@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('starmer@cisco.com','http://lists.openstack.org/pipermail/openstack-infra'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('steve.varnau@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('steve.weston@triniplex.com','http://lists.openstack.org/pipermail/openstack-infra'),('steven.kath@brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('steven.sonnenberg@hds.com','http://lists.openstack.org/pipermail/openstack-infra'),('steven.tan@prophetstor.com','http://lists.openstack.org/pipermail/openstack-infra'),('strainu10@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sudarshan.acharya@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sukhdev@aristanetworks.com','http://lists.openstack.org/pipermail/openstack-infra'),('sukhdevkapur@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sumit.naiksatam@bigswitch.com','http://lists.openstack.org/pipermail/openstack-infra'),('sumitnaiksatam@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sushisource@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('sweston@Brocade.com','http://lists.openstack.org/pipermail/openstack-infra'),('syerrapragada@vmware.com','http://lists.openstack.org/pipermail/openstack-infra'),('takehiro.kaneko@ctc-g.co.jp','http://lists.openstack.org/pipermail/openstack-infra'),('tatjana@open-attic.org','http://lists.openstack.org/pipermail/openstack-infra'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('thingee@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('thomas@koch.ro','http://lists.openstack.org/pipermail/openstack-infra'),('thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('tim@freunds.net','http://lists.openstack.org/pipermail/openstack-infra'),('timothy.e.cline@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('tjones@vmware.com','http://lists.openstack.org/pipermail/openstack-infra'),('tnurlygayanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-infra'),('tobbe@tail-f.com','http://lists.openstack.org/pipermail/openstack-infra'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack-infra'),('tphan@paypal.com','http://lists.openstack.org/pipermail/openstack-infra'),('trinath.somanchi@freescale.com','http://lists.openstack.org/pipermail/openstack-infra'),('v-occiuh@microsoft.com','http://lists.openstack.org/pipermail/openstack-infra'),('Vijay.Venkatachalam@citrix.com','http://lists.openstack.org/pipermail/openstack-infra'),('vijayaerukala@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('vm.vinay@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('vmiklos@suse.cz','http://lists.openstack.org/pipermail/openstack-infra'),('wangchy@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('weidongshao@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('wes@purestorage.com','http://lists.openstack.org/pipermail/openstack-infra'),('Wilfredo.Jr@fit-tecnologia.org.br','http://lists.openstack.org/pipermail/openstack-infra'),('william.soula@drillinginfo.com','http://lists.openstack.org/pipermail/openstack-infra'),('xing.yang@emc.com','http://lists.openstack.org/pipermail/openstack-infra'),('xqianxia@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('xyzjerry@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('yalei.wang@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('yfried@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('yixuanzh@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('yixuan_z@hotmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('ykaneko0929@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('yolanda.robla-mota@hp.com','http://lists.openstack.org/pipermail/openstack-infra'),('yongli.he@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('yorik.sar@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('yshao@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('yu.jiang2@pactera.com','http://lists.openstack.org/pipermail/openstack-infra'),('yux.y.jiang@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('yves-gwenael.bourhis@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-infra'),('zaitcev@redhat.com','http://lists.openstack.org/pipermail/openstack-infra'),('zaro0508@gmail.com','http://lists.openstack.org/pipermail/openstack-infra'),('zhenzan.zhou@intel.com','http://lists.openstack.org/pipermail/openstack-infra'),('zhiwchen@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('zyouzhou@cn.ibm.com','http://lists.openstack.org/pipermail/openstack-infra'),('442340542@qq.com','http://lists.openstack.org/pipermail/openstack-operators'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('abrindeyev@griddynamics.com','http://lists.openstack.org/pipermail/openstack-operators'),('acs@parvuscaptus.com','http://lists.openstack.org/pipermail/openstack-operators'),('adam.huffman@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('adam.morris@multiscalehn.com','http://lists.openstack.org/pipermail/openstack-operators'),('Adam.Morris@providence.org','http://lists.openstack.org/pipermail/openstack-operators'),('adamg@canonical.com','http://lists.openstack.org/pipermail/openstack-operators'),('ADatta@primustel.ca','http://lists.openstack.org/pipermail/openstack-operators'),('Adithya.Inavolu@infotech-enterprises.com','http://lists.openstack.org/pipermail/openstack-operators'),('admin@movenix.com','http://lists.openstack.org/pipermail/openstack-operators'),('adrian.smith@workday.com','http://lists.openstack.org/pipermail/openstack-operators'),('adrian@17od.com','http://lists.openstack.org/pipermail/openstack-operators'),('adrian@bashlines.com','http://lists.openstack.org/pipermail/openstack-operators'),('afreedland@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('agoddard@mbl.edu','http://lists.openstack.org/pipermail/openstack-operators'),('ahaldin@griddynamics.com','http://lists.openstack.org/pipermail/openstack-operators'),('ahmadidamha@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('ahmeali@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('ahmed@manhag.org','http://lists.openstack.org/pipermail/openstack-operators'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-operators'),('aji.zqfan@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('akapadia_usa@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('alawson@aqorn.com','http://lists.openstack.org/pipermail/openstack-operators'),('aldavud@crimson.ch','http://lists.openstack.org/pipermail/openstack-operators'),('alejandro.comisario@mercadolibre.com','http://lists.openstack.org/pipermail/openstack-operators'),('aleonhardt.py@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Alex.Chen@lmal.com.au','http://lists.openstack.org/pipermail/openstack-operators'),('alex890714@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('alfred@pontiflex.com','http://lists.openstack.org/pipermail/openstack-operators'),('alopgeek@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('alvaro.lopez.garcia@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('alvise.dorigo@pd.infn.it','http://lists.openstack.org/pipermail/openstack-operators'),('amit.das@cloudbyte.com','http://lists.openstack.org/pipermail/openstack-operators'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('amuller@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('andi.abes@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('andrew.glen-young@canonical.com','http://lists.openstack.org/pipermail/openstack-operators'),('Andrew.Hale@rackspace.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('Andrew.McCrae@rackspace.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('andrew.regner@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('anjaneya2@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-operators'),('anton.haldin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('antonio.s.messina@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('apetresc@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('arahal@iweb.com','http://lists.openstack.org/pipermail/openstack-operators'),('arjen@muntinternet.net','http://lists.openstack.org/pipermail/openstack-operators'),('Armando.Migliaccio@eu.citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('arminder@pugmarks.com','http://lists.openstack.org/pipermail/openstack-operators'),('arnatal@ac.upc.edu','http://lists.openstack.org/pipermail/openstack-operators'),('Arne.Wiebalck@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('arodionov@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('aroostifer@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('arosen@nicira.com','http://lists.openstack.org/pipermail/openstack-operators'),('arubtsov@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('asmaa.ibrahim12@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('atarasov@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('aubrey@vocalcloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('augustineike@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('avghacker@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('aviostack@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('avozza@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('ayoung@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('azpekt@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('b.hagemeier@fz-juelich.de','http://lists.openstack.org/pipermail/openstack-operators'),('baileifirst@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('baktha.sg@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('baumann@b1-systems.de','http://lists.openstack.org/pipermail/openstack-operators'),('bcline@softlayer.com','http://lists.openstack.org/pipermail/openstack-operators'),('bdpayne@acm.org','http://lists.openstack.org/pipermail/openstack-operators'),('Ben.Swartzlander@netapp.com','http://lists.openstack.org/pipermail/openstack-operators'),('ben42ml@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('berendt@b1-systems.de','http://lists.openstack.org/pipermail/openstack-operators'),('berrange@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('betodalas@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bfilippov@griddynamics.com','http://lists.openstack.org/pipermail/openstack-operators'),('bhines@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bhouser@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('bigzhao@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('blair.bethwaite@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('boris-michel.deschenes@ubisoft.com','http://lists.openstack.org/pipermail/openstack-operators'),('boris@pavlovic.me','http://lists.openstack.org/pipermail/openstack-operators'),('borsodp@staff.westminster.ac.uk','http://lists.openstack.org/pipermail/openstack-operators'),('brad@shub-internet.org','http://lists.openstack.org/pipermail/openstack-operators'),('bradley.klein@twcable.com','http://lists.openstack.org/pipermail/openstack-operators'),('brantcarrey@hotmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('breu@breu.org','http://lists.openstack.org/pipermail/openstack-operators'),('brian.clark@cloudapt.com','http://lists.openstack.org/pipermail/openstack-operators'),('brian.schott@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-operators'),('bruce.bushby@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bruno.semperlotti@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('bryan.berry@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('btaylor@alpharender.net','http://lists.openstack.org/pipermail/openstack-operators'),('btorch-os@zeroaccess.org','http://lists.openstack.org/pipermail/openstack-operators'),('bulk.schulz@ucalgary.ca','http://lists.openstack.org/pipermail/openstack-operators'),('C.Reynolds@westminster.ac.uk','http://lists.openstack.org/pipermail/openstack-operators'),('caedo@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('caperry@edolnx.net','http://lists.openstack.org/pipermail/openstack-operators'),('carol.l.barrett@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('cbehrens@codestud.com','http://lists.openstack.org/pipermail/openstack-operators'),('cbkyeoh@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('cglynn@sportingindex.com','http://lists.openstack.org/pipermail/openstack-operators'),('chad.huneycutt@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('changzhi1990@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('chengyli@ebay.com','http://lists.openstack.org/pipermail/openstack-operators'),('chloema@juniper.net','http://lists.openstack.org/pipermail/openstack-operators'),('chris.buccella@antallagon.com','http://lists.openstack.org/pipermail/openstack-operators'),('chris.friesen@windriver.com','http://lists.openstack.org/pipermail/openstack-operators'),('chris.hoge@puppetlabs.com','http://lists.openstack.org/pipermail/openstack-operators'),('chris.ricker@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('chris@leibnizcreations.com','http://lists.openstack.org/pipermail/openstack-operators'),('christian@berendt.io','http://lists.openstack.org/pipermail/openstack-operators'),('chrisw@sous-sol.org','http://lists.openstack.org/pipermail/openstack-operators'),('cjellick@godaddy.com','http://lists.openstack.org/pipermail/openstack-operators'),('clayton@oneill.net','http://lists.openstack.org/pipermail/openstack-operators'),('clint@fewbar.com','http://lists.openstack.org/pipermail/openstack-operators'),('cloud@leibnizcreations.com','http://lists.openstack.org/pipermail/openstack-operators'),('cloudbmail@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('cmsj@tenshu.net','http://lists.openstack.org/pipermail/openstack-operators'),('cody@puppetlabs.com','http://lists.openstack.org/pipermail/openstack-operators'),('comnea.dani@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('craig@craigtracey.com','http://lists.openstack.org/pipermail/openstack-operators'),('cthiel@suse.com','http://lists.openstack.org/pipermail/openstack-operators'),('cthier@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('cunningr@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('cuongtm@vdc.com.vn','http://lists.openstack.org/pipermail/openstack-operators'),('cwestin@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('dafridgie@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dan@nicira.com','http://lists.openstack.org/pipermail/openstack-operators'),('danehans@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('daniel@speichert.pl','http://lists.openstack.org/pipermail/openstack-operators'),('daniele.venzano@eurecom.fr','http://lists.openstack.org/pipermail/openstack-operators'),('daniele@dvaleriani.net','http://lists.openstack.org/pipermail/openstack-operators'),('dara2002-openstack@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('darksinclair@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('darren.birkett@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('darrettac@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('davanum@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dave.pigott@linaro.org','http://lists.openstack.org/pipermail/openstack-operators'),('david.kranz@qrclab.com','http://lists.openstack.org/pipermail/openstack-operators'),('davidp@wirelessconnections.net','http://lists.openstack.org/pipermail/openstack-operators'),('dce3062@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('deepak.mane@tcs.com','http://lists.openstack.org/pipermail/openstack-operators'),('deepak@virtueinsight.com','http://lists.openstack.org/pipermail/openstack-operators'),('deepakgarg.iitg@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('deJongm@TEOCO.com','http://lists.openstack.org/pipermail/openstack-operators'),('derekh@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('devananda.vdv@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('devendran.jagadisan@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('devoid@anl.gov','http://lists.openstack.org/pipermail/openstack-operators'),('diego.parrilla.santamaria@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('diego.parrilla@stackops.com','http://lists.openstack.org/pipermail/openstack-operators'),('digitalwonk@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ding.deng@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dirk@dmllr.de','http://lists.openstack.org/pipermail/openstack-operators'),('dist@vhpc.org','http://lists.openstack.org/pipermail/openstack-operators'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('dloshakov@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dmagda@ee.ryerson.ca','http://lists.openstack.org/pipermail/openstack-operators'),('dmartls1@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dmercer@fantoccini.com','http://lists.openstack.org/pipermail/openstack-operators'),('dmsimard@iweb.com','http://lists.openstack.org/pipermail/openstack-operators'),('DODIN@il.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('dolph.mathews@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('don@endres.us','http://lists.openstack.org/pipermail/openstack-operators'),('donald.mize@hp.com','http://lists.openstack.org/pipermail/openstack-operators'),('dotalton@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-operators'),('dprince@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('dradez@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('dragonetail@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dspano@optogenics.com','http://lists.openstack.org/pipermail/openstack-operators'),('dtroyer@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('duan.xufeng@zte.com.cn','http://lists.openstack.org/pipermail/openstack-operators'),('duncan@dreamhost.com','http://lists.openstack.org/pipermail/openstack-operators'),('durrani.anwar@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('dustin@null-ptr.net','http://lists.openstack.org/pipermail/openstack-operators'),('dyocum@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('e.aslan@logicom.com.tr','http://lists.openstack.org/pipermail/openstack-operators'),('e.st.clabaut@sqltechnologies.com','http://lists.openstack.org/pipermail/openstack-operators'),('e.testingcloud@tid.es','http://lists.openstack.org/pipermail/openstack-operators'),('ebegoli@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('edalzap@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('edgar.magana@workday.com','http://lists.openstack.org/pipermail/openstack-operators'),('edouard.thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('edward.liu@nsn.com','http://lists.openstack.org/pipermail/openstack-operators'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('egon@egon.cc','http://lists.openstack.org/pipermail/openstack-operators'),('eharney@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('emccormick@cirrusseven.com','http://lists.openstack.org/pipermail/openstack-operators'),('emilien.macchi@enovance.com','http://lists.openstack.org/pipermail/openstack-operators'),('emilien.macchi@stackops.com','http://lists.openstack.org/pipermail/openstack-operators'),('endre.karlson@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('enelen@helioscloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('eric.grejda@emergentspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('Eric.Sarakaitis@cbts.net','http://lists.openstack.org/pipermail/openstack-operators'),('eric@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-operators'),('eric@windisch.us','http://lists.openstack.org/pipermail/openstack-operators'),('Eric_E_Smith@DELL.com','http://lists.openstack.org/pipermail/openstack-operators'),('erkan.yanar@linsenraum.de','http://lists.openstack.org/pipermail/openstack-operators'),('Estevao.Vargas@br.unisys.com','http://lists.openstack.org/pipermail/openstack-operators'),('eu@galenogarbe.com','http://lists.openstack.org/pipermail/openstack-operators'),('evanlinwood@arenacore.com','http://lists.openstack.org/pipermail/openstack-operators'),('everett.toews@cybera.ca','http://lists.openstack.org/pipermail/openstack-operators'),('everett.toews@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('Ewan.Mellor@eu.citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('EZRA@il.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('f.ramalhoo@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('fbastani@perennate.com','http://lists.openstack.org/pipermail/openstack-operators'),('fgiunchedi@wikimedia.org','http://lists.openstack.org/pipermail/openstack-operators'),('fifieldt@unimelb.edu.au','http://lists.openstack.org/pipermail/openstack-operators'),('fishlikehexagon@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('florian@hastexo.com','http://lists.openstack.org/pipermail/openstack-operators'),('fractil@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('francois@ctrlaltdel.ch','http://lists.openstack.org/pipermail/openstack-operators'),('franklynp@gladinet.com','http://lists.openstack.org/pipermail/openstack-operators'),('frans@meruvian.org','http://lists.openstack.org/pipermail/openstack-operators'),('fraunhofer.lists.os-operators.001@traced.net','http://lists.openstack.org/pipermail/openstack-operators'),('freyes@tty.cl','http://lists.openstack.org/pipermail/openstack-operators'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-operators'),('furlongm@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gabe.westmaas@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('gallowaymd@ornl.gov','http://lists.openstack.org/pipermail/openstack-operators'),('geekinutah@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('George.Mihaiescu@Q9.com','http://lists.openstack.org/pipermail/openstack-operators'),('george.shuklin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('george@galis.org','http://lists.openstack.org/pipermail/openstack-operators'),('gergnz@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gerrit@gerr1t.nl','http://lists.openstack.org/pipermail/openstack-operators'),('gessau@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('gfa@zumbi.com.ar','http://lists.openstack.org/pipermail/openstack-operators'),('gfortaine@live.com','http://lists.openstack.org/pipermail/openstack-operators'),('ghe.rivero@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gholt@rackspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('gianluigi.zanetti@crs4.it','http://lists.openstack.org/pipermail/openstack-operators'),('gilles.mocellin@nuagelibre.org','http://lists.openstack.org/pipermail/openstack-operators'),('giuseppe.civitella@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gmi68745@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gordon.irving@sophos.com','http://lists.openstack.org/pipermail/openstack-operators'),('guangyu@unitedstack.com','http://lists.openstack.org/pipermail/openstack-operators'),('guimalufb@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gunther@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-operators'),('guolongcang.work@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gustavo.randich@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('guyright@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('gvarghese@aqorn.com','http://lists.openstack.org/pipermail/openstack-operators'),('hailybrown@hushmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('harlan@bloomenterprises.org','http://lists.openstack.org/pipermail/openstack-operators'),('harlowja@outlook.com','http://lists.openstack.org/pipermail/openstack-operators'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-operators'),('haynes.davis@accenture.com','http://lists.openstack.org/pipermail/openstack-operators'),('hdezmora@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('heckj@mac.com','http://lists.openstack.org/pipermail/openstack-operators'),('heckj@me.com','http://lists.openstack.org/pipermail/openstack-operators'),('hedenlipartj@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('hemant.burman@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('henriquev16@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('heut2008@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('hgdeoro@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('hillad@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('hisayuki.takeda@oceanearth-corp.com','http://lists.openstack.org/pipermail/openstack-operators'),('hk4cloud@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('honjo.rikimaru@po.ntts.co.jp','http://lists.openstack.org/pipermail/openstack-operators'),('horia@alum.berkeley.edu','http://lists.openstack.org/pipermail/openstack-operators'),('hvprash@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('hyangii@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ian.s.mcb@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ignace@enovance.com','http://lists.openstack.org/pipermail/openstack-operators'),('igor.laskovy@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('irmatov@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('isaku.yamahata@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('islamsh@indiana.edu','http://lists.openstack.org/pipermail/openstack-operators'),('itzikb@dev.mellanox.co.il','http://lists.openstack.org/pipermail/openstack-operators'),('J.O\'Loughlin@surrey.ac.uk','http://lists.openstack.org/pipermail/openstack-operators'),('j@no-io.net','http://lists.openstack.org/pipermail/openstack-operators'),('jacobgodin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jake@ansolabs.com','http://lists.openstack.org/pipermail/openstack-operators'),('james.page@ubuntu.com','http://lists.openstack.org/pipermail/openstack-operators'),('james.slagle@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jamesd@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-operators'),('james_r_penick@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('Jan.van.Eldik@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('janis.gengeris@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jason.cannavale@rackspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jbryce@jbryce.com','http://lists.openstack.org/pipermail/openstack-operators'),('jean-daniel.bonnetot@ovh.net','http://lists.openstack.org/pipermail/openstack-operators'),('jeff@sweetlabs.com','http://lists.openstack.org/pipermail/openstack-operators'),('jeffkramer@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jeffreycohobupt@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jeremy@dreamhost.com','http://lists.openstack.org/pipermail/openstack-operators'),('jerico.revote@monash.edu','http://lists.openstack.org/pipermail/openstack-operators'),('jerome.pansanel@iphc.cnrs.fr','http://lists.openstack.org/pipermail/openstack-operators'),('jeronimo974@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jesse.cook@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('jesse.pretorius@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jford@blackmesh.com','http://lists.openstack.org/pipermail/openstack-operators'),('jharley@redmind.ca','http://lists.openstack.org/pipermail/openstack-operators'),('jim.chamings@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('jim@freesolutions.net','http://lists.openstack.org/pipermail/openstack-operators'),('jinzishuai@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jj@getchef.com','http://lists.openstack.org/pipermail/openstack-operators'),('jjpavlik@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jkeating@bluebox.net','http://lists.openstack.org/pipermail/openstack-operators'),('jle@cosmicfire.net','http://lists.openstack.org/pipermail/openstack-operators'),('jliberma@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('jlk@bluebox.net','http://lists.openstack.org/pipermail/openstack-operators'),('jlowey@tgen.org','http://lists.openstack.org/pipermail/openstack-operators'),('jm9991@att.com','http://lists.openstack.org/pipermail/openstack-operators'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('joe.topjian@cybera.ca','http://lists.openstack.org/pipermail/openstack-operators'),('joe@topjian.net','http://lists.openstack.org/pipermail/openstack-operators'),('joel.cooklin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jogo@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-operators'),('John.Garbutt@citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-operators'),('john.smith.seccompany@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('john.t.gruber@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('john@dewey.ws','http://lists.openstack.org/pipermail/openstack-operators'),('john@johngarbutt.com','http://lists.openstack.org/pipermail/openstack-operators'),('john@millican.us','http://lists.openstack.org/pipermail/openstack-operators'),('johnmark@gluster.org','http://lists.openstack.org/pipermail/openstack-operators'),('John_Brzozowski@Cable.Comcast.com','http://lists.openstack.org/pipermail/openstack-operators'),('jon.guidry.jozw@statefarm.com','http://lists.openstack.org/pipermail/openstack-operators'),('jon@csail.mit.edu','http://lists.openstack.org/pipermail/openstack-operators'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/openstack-operators'),('jonathan.abdiel@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jonathan_gershater@trendmicro.com','http://lists.openstack.org/pipermail/openstack-operators'),('jordan@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('jorgewilsonmachado@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('josh@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('joshua.pasqualetto@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('jpichon@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('jrussell@thesba.com','http://lists.openstack.org/pipermail/openstack-operators'),('jtaylor@zipgrid.com','http://lists.openstack.org/pipermail/openstack-operators'),('juan.suero@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('juanfra.rodriguez.cardoso@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('julim@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('just.wow@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('justin@vlamea.nl','http://lists.openstack.org/pipermail/openstack-operators'),('jwalker@gluster.com','http://lists.openstack.org/pipermail/openstack-operators'),('jwest@foundation.io','http://lists.openstack.org/pipermail/openstack-operators'),('k.mohammad1@physics.ox.ac.uk','http://lists.openstack.org/pipermail/openstack-operators'),('kathyc@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('kavit@aptira.com','http://lists.openstack.org/pipermail/openstack-operators'),('kelly.goedert@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ken.pepple@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('kevin.carter@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('Kevin.Fox@pnnl.gov','http://lists.openstack.org/pipermail/openstack-operators'),('kevin@linuxservices.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('kevin@yieldex.com','http://lists.openstack.org/pipermail/openstack-operators'),('kiall@hp.com','http://lists.openstack.org/pipermail/openstack-operators'),('kiall@managedit.ie','http://lists.openstack.org/pipermail/openstack-operators'),('kieronb@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('kimi.zhang@nsn.com','http://lists.openstack.org/pipermail/openstack-operators'),('KISIN@il.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('kispear@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('klindgren@godaddy.com','http://lists.openstack.org/pipermail/openstack-operators'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('koert@cloudvps.com','http://lists.openstack.org/pipermail/openstack-operators'),('koolhead17@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('kpeng@terra.com','http://lists.openstack.org/pipermail/openstack-operators'),('kpfoote@iup.edu','http://lists.openstack.org/pipermail/openstack-operators'),('kraemer@avarteq.de','http://lists.openstack.org/pipermail/openstack-operators'),('kristofer@cybernetik.net','http://lists.openstack.org/pipermail/openstack-operators'),('lars.lehtonen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('lbragstad@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('leandro.21.2008@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('leandro.reox@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('leandro.reox@mercadolibre.com','http://lists.openstack.org/pipermail/openstack-operators'),('leeleiwoo@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('liangjx@buptnet.edu.cn','http://lists.openstack.org/pipermail/openstack-operators'),('linux@ramyallam.com','http://lists.openstack.org/pipermail/openstack-operators'),('linuxcole@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('linuxdatacenter@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('lionel@alveonet.org','http://lists.openstack.org/pipermail/openstack-operators'),('litong01@us.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('lleelm@outlook.com','http://lists.openstack.org/pipermail/openstack-operators'),('lloydostack@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-operators'),('lsurette@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('luis.fernandez.alvarez@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('luis.pedrosa@usc.edu','http://lists.openstack.org/pipermail/openstack-operators'),('luis@woorea.es','http://lists.openstack.org/pipermail/openstack-operators'),('luyan.bj@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('lzy.dev@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('lzyeval@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('m@metacloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('madhuchary80@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('magazine.lihuiba@163.com','http://lists.openstack.org/pipermail/openstack-operators'),('maggonzz@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('magicloud.magiclouds@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mahmadur.rahman@giluxe.com','http://lists.openstack.org/pipermail/openstack-operators'),('mail@seetheprogress.com','http://lists.openstack.org/pipermail/openstack-operators'),('mailinglists@expresswebsystems.com','http://lists.openstack.org/pipermail/openstack-operators'),('maishsk+openstack@maishsk.com','http://lists.openstack.org/pipermail/openstack-operators'),('makay22@wp.pl','http://lists.openstack.org/pipermail/openstack-operators'),('mali@awcloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('malini.k.bhandaru@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('manel.me@live.fr','http://lists.openstack.org/pipermail/openstack-operators'),('manishg@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-operators'),('marc.heckmann@ubisoft.com','http://lists.openstack.org/pipermail/openstack-operators'),('marcos.garcia@enovance.com','http://lists.openstack.org/pipermail/openstack-operators'),('marius@nuenneri.ch','http://lists.openstack.org/pipermail/openstack-operators'),('marklee@fortawesome.org','http://lists.openstack.org/pipermail/openstack-operators'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('marrotte@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('martin@jdn.nl','http://lists.openstack.org/pipermail/openstack-operators'),('mathiasbrito@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mathieu.rohon@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('maticue@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('matt.griffin@percona.com','http://lists.openstack.org/pipermail/openstack-operators'),('matt.joyce@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-operators'),('matt@nycresistor.com','http://lists.openstack.org/pipermail/openstack-operators'),('matt@opscode.com','http://lists.openstack.org/pipermail/openstack-operators'),('matthew.fischer@twcable.com','http://lists.openstack.org/pipermail/openstack-operators'),('matthewmackes@deltasoniccarwash.com','http://lists.openstack.org/pipermail/openstack-operators'),('mattias.hemmingsson@elino.se','http://lists.openstack.org/pipermail/openstack-operators'),('mattm@ex.idig.net','http://lists.openstack.org/pipermail/openstack-operators'),('mattrae@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('maximilianrh@googlemail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mc3124@att.com','http://lists.openstack.org/pipermail/openstack-operators'),('md1clv@md1clv.com','http://lists.openstack.org/pipermail/openstack-operators'),('mdargan@twinstrata.com','http://lists.openstack.org/pipermail/openstack-operators'),('mdieder@sinos.net','http://lists.openstack.org/pipermail/openstack-operators'),('mdorman@godaddy.com','http://lists.openstack.org/pipermail/openstack-operators'),('mdshaonimran@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mdubov@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('me@andreatartaglia.com','http://lists.openstack.org/pipermail/openstack-operators'),('me@not.mn','http://lists.openstack.org/pipermail/openstack-operators'),('mechtri.marwen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('megha.t@cisinlabs.com','http://lists.openstack.org/pipermail/openstack-operators'),('mestery@mestery.com','http://lists.openstack.org/pipermail/openstack-operators'),('meytin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mgagne@iweb.com','http://lists.openstack.org/pipermail/openstack-operators'),('mgiammarco@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('michael.chapman@anu.edu.au','http://lists.openstack.org/pipermail/openstack-operators'),('michael.still@canonical.com','http://lists.openstack.org/pipermail/openstack-operators'),('michael.vandeborne@cetic.be','http://lists.openstack.org/pipermail/openstack-operators'),('michael@john.cd','http://lists.openstack.org/pipermail/openstack-operators'),('miguelangel.diaz@ciemat.es','http://lists.openstack.org/pipermail/openstack-operators'),('miguelangel.diaz@externos.ciemat.es','http://lists.openstack.org/pipermail/openstack-operators'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-operators'),('milind.barve@citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('mismith@overstock.com','http://lists.openstack.org/pipermail/openstack-operators'),('misteritguru@gmx.com','http://lists.openstack.org/pipermail/openstack-operators'),('mitch@metauser.net','http://lists.openstack.org/pipermail/openstack-operators'),('mitchell.broome@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mjfork@us.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('mkolesni@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('mlortiz@uci.cu','http://lists.openstack.org/pipermail/openstack-operators'),('mmarch@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('mmosesohn@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('mohib@qmail.com.bd','http://lists.openstack.org/pipermail/openstack-operators'),('mongketengrilo@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('moreira.belmiro.email.lists@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('motoki@da.jp.nec.com','http://lists.openstack.org/pipermail/openstack-operators'),('mpedersen@choopa.com','http://lists.openstack.org/pipermail/openstack-operators'),('mriedem@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('mscherbakov@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack-operators'),('muroi.masahito@lab.ntt.co.jp','http://lists.openstack.org/pipermail/openstack-operators'),('mustafa@netkine.com','http://lists.openstack.org/pipermail/openstack-operators'),('mvanwink@rackspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('mvwilderen@jdn.nl','http://lists.openstack.org/pipermail/openstack-operators'),('mwjpiero@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('myungjin.lee@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('NAGIN@il.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('narayan.desai@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nathan@robotics.net','http://lists.openstack.org/pipermail/openstack-operators'),('nathanael.i.burton@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ndipanov@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('nelsonrp24@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('netmatters@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nhanct92@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('niall.power@oracle.com','http://lists.openstack.org/pipermail/openstack-operators'),('nick@pistoncloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('nickryand@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nico.vangessel@biologie.uni-freiburg.de','http://lists.openstack.org/pipermail/openstack-operators'),('nirbhaysinghtomar@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nisarg.h.patel@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nobuki.ism0115@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ntcong.it@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('nux@li.nux.ro','http://lists.openstack.org/pipermail/openstack-operators'),('ogelbukh@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('Ohad.Baruch@emc.com','http://lists.openstack.org/pipermail/openstack-operators'),('oisin.feeley@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('oliver@openstackusers.org','http://lists.openstack.org/pipermail/openstack-operators'),('omerfsen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('onetown@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('openstack-operators-20140528@angelfaq.com','http://lists.openstack.org/pipermail/openstack-operators'),('openstack@medberry.net','http://lists.openstack.org/pipermail/openstack-operators'),('openstack@newgoliath.com','http://lists.openstack.org/pipermail/openstack-operators'),('OPHIRS@il.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('ops@dnsbed.com','http://lists.openstack.org/pipermail/openstack-operators'),('outbackdingo@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('P@draigBrady.com','http://lists.openstack.org/pipermail/openstack-operators'),('pablo.a.fuente@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('pablo.sanchez@stackops.com','http://lists.openstack.org/pipermail/openstack-operators'),('papaspyrou@adesso-mobile.de','http://lists.openstack.org/pipermail/openstack-operators'),('paul.belanger@polybeacon.com','http://lists.openstack.org/pipermail/openstack-operators'),('paul.d.walton@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('paul.dekkers@surfnet.nl','http://lists.openstack.org/pipermail/openstack-operators'),('paul.rad@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('pavan_avis@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('pborghard@choopa.com','http://lists.openstack.org/pipermail/openstack-operators'),('pc@pcable.net','http://lists.openstack.org/pipermail/openstack-operators'),('pednape@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Pekka.Paakkonen@vtt.fi','http://lists.openstack.org/pipermail/openstack-operators'),('penick@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-operators'),('peter.boros@percona.com','http://lists.openstack.org/pipermail/openstack-operators'),('peter@gridcentric.ca','http://lists.openstack.org/pipermail/openstack-operators'),('peter@pouliot.net','http://lists.openstack.org/pipermail/openstack-operators'),('pglists@zeroaccess.org','http://lists.openstack.org/pipermail/openstack-operators'),('pgsousa@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('phamtungduong@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Philip.Schwartz@lexisnexis.com','http://lists.openstack.org/pipermail/openstack-operators'),('piaoyuankui@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('pieter.c.kruithof-jr@hp.com','http://lists.openstack.org/pipermail/openstack-operators'),('pkd@Glue.umd.edu','http://lists.openstack.org/pipermail/openstack-operators'),('porombka@uni-paderborn.de','http://lists.openstack.org/pipermail/openstack-operators'),('pradhanparas@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('pranav.saxena@citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('premedge@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('prince.m.singh@outlook.com','http://lists.openstack.org/pipermail/openstack-operators'),('prometheanfire@gentoo.org','http://lists.openstack.org/pipermail/openstack-operators'),('pruth@renci.org','http://lists.openstack.org/pipermail/openstack-operators'),('pusch.david@googlemail.com','http://lists.openstack.org/pipermail/openstack-operators'),('qarekhani@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('rafi@metacloud.com','http://lists.openstack.org/pipermail/openstack-operators'),('raju.roks@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('rashford@suse.com','http://lists.openstack.org/pipermail/openstack-operators'),('rass@1984.is','http://lists.openstack.org/pipermail/openstack-operators'),('razique.mahroua@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('razique.mahroua@nuage-and-co.fr','http://lists.openstack.org/pipermail/openstack-operators'),('rborrison@geminare.com','http://lists.openstack.org/pipermail/openstack-operators'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('rcontreras1989@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('regan@wavefunction.org','http://lists.openstack.org/pipermail/openstack-operators'),('renato@dualtec.com.br','http://lists.openstack.org/pipermail/openstack-operators'),('reza.b2008@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('reza@dslextreme.com','http://lists.openstack.org/pipermail/openstack-operators'),('rhafer@suse.de','http://lists.openstack.org/pipermail/openstack-operators'),('ribozyme847@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('richard.boswell@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('richard.kiene@logos.com','http://lists.openstack.org/pipermail/openstack-operators'),('Richard@Raseley.com','http://lists.openstack.org/pipermail/openstack-operators'),('richih.mailinglist@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('rick.jones2@hp.com','http://lists.openstack.org/pipermail/openstack-operators'),('riteshnanda09@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('rkatz@simplicityhosting.com','http://lists.openstack.org/pipermail/openstack-operators'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/openstack-operators'),('robert.plestenjak@xlab.si','http://lists.openstack.org/pipermail/openstack-operators'),('Robert.vanLeeuwen@spilgames.com','http://lists.openstack.org/pipermail/openstack-operators'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack-operators'),('robertico.gonzalez77@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/openstack-operators'),('rochelle.grober@huawei.com','http://lists.openstack.org/pipermail/openstack-operators'),('roland.hochmuth@hp.com','http://lists.openstack.org/pipermail/openstack-operators'),('roland@aptira.com','http://lists.openstack.org/pipermail/openstack-operators'),('Ronald.vanderPol@rvdp.org','http://lists.openstack.org/pipermail/openstack-operators'),('rpodolyaka@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('rrs@researchut.com','http://lists.openstack.org/pipermail/openstack-operators'),('rvellank@rackspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('ryade@mcs.anl.gov','http://lists.openstack.org/pipermail/openstack-operators'),('ryan.clevenger@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('ryan.richard@rackspace.com','http://lists.openstack.org/pipermail/openstack-operators'),('sabaset@us.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('sacampa@gmv.com','http://lists.openstack.org/pipermail/openstack-operators'),('sahasra143@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('sajuptpm@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('salman.toor@it.uu.se','http://lists.openstack.org/pipermail/openstack-operators'),('salut@mariuss.net','http://lists.openstack.org/pipermail/openstack-operators'),('samuel.hassine@anotherservice.com','http://lists.openstack.org/pipermail/openstack-operators'),('sankarshan.mukhopadhyay@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sateesh.chodapuneedi@citrix.com','http://lists.openstack.org/pipermail/openstack-operators'),('Sateesh_Kumar@mindtree.com','http://lists.openstack.org/pipermail/openstack-operators'),('satimis@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('sbarnabas@frontporch.com','http://lists.openstack.org/pipermail/openstack-operators'),('sbauza@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('sbroeker@internap.com','http://lists.openstack.org/pipermail/openstack-operators'),('scarroy@sandia.gov','http://lists.openstack.org/pipermail/openstack-operators'),('scheuran@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('scott_kohler@sil.org','http://lists.openstack.org/pipermail/openstack-operators'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('sean.bigdatafun@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-operators'),('sean@seanhamilton.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-operators'),('seanroberts66@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sebastien.han@enovance.com','http://lists.openstack.org/pipermail/openstack-operators'),('sergey@kulanov.org.ua','http://lists.openstack.org/pipermail/openstack-operators'),('sergio.j.cazzolato@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('serverascode@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('shai@shaibn.com','http://lists.openstack.org/pipermail/openstack-operators'),('shakamunyi@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('shake.chen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('shang@canonical.com','http://lists.openstack.org/pipermail/openstack-operators'),('shang@ubuntu.com','http://lists.openstack.org/pipermail/openstack-operators'),('shashi.eu@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('shashidhar.velagandula@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('shredder12@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('shyam.todeti@oneconvergence.com','http://lists.openstack.org/pipermail/openstack-operators'),('silvia_hung@zmanda.com','http://lists.openstack.org/pipermail/openstack-operators'),('sim.ple@live.nl','http://lists.openstack.org/pipermail/openstack-operators'),('simon.leinen@switch.ch','http://lists.openstack.org/pipermail/openstack-operators'),('simon.pasquier@bull.net','http://lists.openstack.org/pipermail/openstack-operators'),('simon@mccartney.ie','http://lists.openstack.org/pipermail/openstack-operators'),('sking@real-status.com','http://lists.openstack.org/pipermail/openstack-operators'),('skywalker.nick@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('slawek@kaplonski.pl','http://lists.openstack.org/pipermail/openstack-operators'),('slyphon@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('smanos@unimelb.edu.au','http://lists.openstack.org/pipermail/openstack-operators'),('sonali@servercentralen.se','http://lists.openstack.org/pipermail/openstack-operators'),('songweijia@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('song_tia@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('sorhanse@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('sorrison@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('soulxu@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('spasquier@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('sridhar.basam@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sriram@sriramhere.com','http://lists.openstack.org/pipermail/openstack-operators'),('sross@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('ss7pro@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('stackerandrew@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('stefano.zilli@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('stephane.boisvert@gameloft.com','http://lists.openstack.org/pipermail/openstack-operators'),('stephen.gran@guardian.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('stephen.gran@theguardian.com','http://lists.openstack.org/pipermail/openstack-operators'),('stephen.spector@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('stephen.tan@certivox.com','http://lists.openstack.org/pipermail/openstack-operators'),('steve.cousins@maine.edu','http://lists.openstack.org/pipermail/openstack-operators'),('stevej@dblue.ie','http://lists.openstack.org/pipermail/openstack-operators'),('stevenca@cisco.com','http://lists.openstack.org/pipermail/openstack-operators'),('steve_broeker@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('stuart@demonware.net','http://lists.openstack.org/pipermail/openstack-operators'),('subbu@subbu.org','http://lists.openstack.org/pipermail/openstack-operators'),('sudhasadhasivam@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('sujay.m17@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sumitkgaur@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Sushil.Suresh@rackspace.co.uk','http://lists.openstack.org/pipermail/openstack-operators'),('Sushma.Gurram@sandisk.com','http://lists.openstack.org/pipermail/openstack-operators'),('sverrest@opera.com','http://lists.openstack.org/pipermail/openstack-operators'),('swamireddy@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('swinchen@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('syed.armani@hastexo.com','http://lists.openstack.org/pipermail/openstack-operators'),('sylecn@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('sylvain.bauza@bull.net','http://lists.openstack.org/pipermail/openstack-operators'),('sylvain.bauza@digimind.com','http://lists.openstack.org/pipermail/openstack-operators'),('taget@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('tanvir@tanvir.me','http://lists.openstack.org/pipermail/openstack-operators'),('Taurus.Cheung@harmonicinc.com','http://lists.openstack.org/pipermail/openstack-operators'),('Terry.Rankine@csiro.au','http://lists.openstack.org/pipermail/openstack-operators'),('Theresa.Grevell@xerox.com','http://lists.openstack.org/pipermail/openstack-operators'),('thiagocmartinsc@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('thibaut.lapierre@digimind.com','http://lists.openstack.org/pipermail/openstack-operators'),('thirunaresh@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('thna@nm.gist.ac.kr','http://lists.openstack.org/pipermail/openstack-operators'),('thomas@babelgeek.com','http://lists.openstack.org/pipermail/openstack-operators'),('thomasbechtold@jpberlin.de','http://lists.openstack.org/pipermail/openstack-operators'),('thuleau@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Till.Mossakowski@dfki.de','http://lists.openstack.org/pipermail/openstack-operators'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack-operators'),('tim.chipman@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('tim@gerla.net','http://lists.openstack.org/pipermail/openstack-operators'),('timg@catalyst.net.nz','http://lists.openstack.org/pipermail/openstack-operators'),('tnapierala@mirantis.com','http://lists.openstack.org/pipermail/openstack-operators'),('todd.deshane@xen.org','http://lists.openstack.org/pipermail/openstack-operators'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack-operators'),('tonytkdk@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('topper@toppingdesign.com','http://lists.openstack.org/pipermail/openstack-operators'),('trainor@presciencetrust.org','http://lists.openstack.org/pipermail/openstack-operators'),('trapni@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('trey@maldivica.com','http://lists.openstack.org/pipermail/openstack-operators'),('trygvis@inamo.no','http://lists.openstack.org/pipermail/openstack-operators'),('tshefi@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('tsmith@gridcentric.com','http://lists.openstack.org/pipermail/openstack-operators'),('vachon@sessionm.com','http://lists.openstack.org/pipermail/openstack-operators'),('vedprakash.nimbalkar@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('venkata.simhadri.nagender.yasalapu@ericsson.com','http://lists.openstack.org/pipermail/openstack-operators'),('verga.emanuele@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vhpc.dist@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vickreman@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vietstack@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vishalcdac07@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('vivekraghuwanshi@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('walter.bentley@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-operators'),('warren@wangspeed.com','http://lists.openstack.org/pipermail/openstack-operators'),('wateringcan@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('wenjianhn@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('whitekid@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('willfly0620@yahoo.com.cn','http://lists.openstack.org/pipermail/openstack-operators'),('Will_Newby@discovery.com','http://lists.openstack.org/pipermail/openstack-operators'),('winston.d@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('wittwerch@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('woppin@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('xarses@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('xavpaice@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('xing.yang@emc.com','http://lists.openstack.org/pipermail/openstack-operators'),('xsited@yahoo.com','http://lists.openstack.org/pipermail/openstack-operators'),('xuanmingyi@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('xuhj@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-operators'),('yacketrj@potsdam.edu','http://lists.openstack.org/pipermail/openstack-operators'),('yamahata.openstackoperators@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('yaoheling@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('Yapeng.Wu@huawei.com','http://lists.openstack.org/pipermail/openstack-operators'),('yazz.atlas@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('ye.a.yuan@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('yj.yuan@huawei.com','http://lists.openstack.org/pipermail/openstack-operators'),('yocum@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('yrabl@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('yu@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-operators'),('yungho5054@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('yunhong.jiang@intel.com','http://lists.openstack.org/pipermail/openstack-operators'),('yuxcer@126.com','http://lists.openstack.org/pipermail/openstack-operators'),('ywang225@126.com','http://lists.openstack.org/pipermail/openstack-operators'),('z-launchpad@brim.net','http://lists.openstack.org/pipermail/openstack-operators'),('zabolzadeh@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zaitcev@redhat.com','http://lists.openstack.org/pipermail/openstack-operators'),('zarnovican@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zashah@kth.se','http://lists.openstack.org/pipermail/openstack-operators'),('zhangxiaolins@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zhaoyi.luo@hotmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zigo@debian.org','http://lists.openstack.org/pipermail/openstack-operators'),('zjfhappy@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zyh.at.bupt@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('zym0017d@gmail.com','http://lists.openstack.org/pipermail/openstack-operators'),('afazekas@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-qa'),('ajku.agr@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('akuno@lavabit.com','http://lists.openstack.org/pipermail/openstack-qa'),('albert.vico@midokura.com','http://lists.openstack.org/pipermail/openstack-qa'),('anjutiwari5@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-qa'),('annegentle@justwriteclick.com','http://lists.openstack.org/pipermail/openstack-qa'),('ashraf.vazeer@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('ayurchuk@minuteware.net','http://lists.openstack.org/pipermail/openstack-qa'),('bageshree.lokare@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('banveerad@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('bhaskar.rao@citrix.com','http://lists.openstack.org/pipermail/openstack-qa'),('bozhu@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('can@canx.me','http://lists.openstack.org/pipermail/openstack-qa'),('chhuang@us.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('cyeoh@au1.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('daryl.walleck@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-qa'),('david.kranz@qrclab.com','http://lists.openstack.org/pipermail/openstack-qa'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('donald.ngo@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('dprince@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('dron@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('fmyzjs@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('franck110@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('frittoli@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('gessau@cisco.com','http://lists.openstack.org/pipermail/openstack-qa'),('gfidente@fedoraproject.org','http://lists.openstack.org/pipermail/openstack-qa'),('gfidente@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('girijasharansingh@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('hailybrown@hushmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('hateya@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('igawa@mxs.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-qa'),('IzikP@Radware.com','http://lists.openstack.org/pipermail/openstack-qa'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/openstack-qa'),('jenkins@openstack.org','http://lists.openstack.org/pipermail/openstack-qa'),('jeronimo974@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('jesusaurus@mail.com','http://lists.openstack.org/pipermail/openstack-qa'),('jhenner@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('jkt@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('jmichel@suse.de','http://lists.openstack.org/pipermail/openstack-qa'),('jogo@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-qa'),('joshua.hesketh@rackspace.com','http://lists.openstack.org/pipermail/openstack-qa'),('Julien.LELOUP@3ds.com','http://lists.openstack.org/pipermail/openstack-qa'),('kavan.patil@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('kchamart@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('lauria@us.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('lorin@nimbisservices.com','http://lists.openstack.org/pipermail/openstack-qa'),('m.koderer@telekom.de','http://lists.openstack.org/pipermail/openstack-qa'),('malini.kamalambal@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-qa'),('marun@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('masayuki.igawa@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('mathivathani.s@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('me@jaybuff.com','http://lists.openstack.org/pipermail/openstack-qa'),('meera.belur@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('mkollaro@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack-qa'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack-qa'),('naggappan@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('nayna.patel@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('Nora.Zhou@harmonicinc.com','http://lists.openstack.org/pipermail/openstack-qa'),('oscar_correiaj@hotmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('pandeyop@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('prem.karat@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('psedlak@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('r0s2p5.pon@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('ravikumar.venkatesan@hp.com','http://lists.openstack.org/pipermail/openstack-qa'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack-qa'),('Rochelle.Grober@huawei.com','http://lists.openstack.org/pipermail/openstack-qa'),('roeyc@mellanox.com','http://lists.openstack.org/pipermail/openstack-qa'),('Rohit.Karajgi@nttdata.com','http://lists.openstack.org/pipermail/openstack-qa'),('rvaknin@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('sabeen.syed@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-qa'),('sabergeass@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('sam.alba@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('sam.danes@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-qa'),('sandeep.raman@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-qa'),('sjain@thoughtworks.com','http://lists.openstack.org/pipermail/openstack-qa'),('sombrafam@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('ssugrevu@vmware.com','http://lists.openstack.org/pipermail/openstack-qa'),('sujay.m17@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('tiru1012@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('tkammer@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('tom@openstack.org','http://lists.openstack.org/pipermail/openstack-qa'),('treinish@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('v-cesilv@microsoft.com','http://lists.openstack.org/pipermail/openstack-qa'),('vmmilev@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('xiayu.message@gmail.com','http://lists.openstack.org/pipermail/openstack-qa'),('xuhj@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-qa'),('yamazaki-mitsuhiko@cnt.mxc.nes.nec.co.jp','http://lists.openstack.org/pipermail/openstack-qa'),('yangchyeah@163.com','http://lists.openstack.org/pipermail/openstack-qa'),('ykaul@redhat.com','http://lists.openstack.org/pipermail/openstack-qa'),('aaronorosen@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('adamg@canonical.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('adamg@ubuntu.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('afazekas@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('aj@suse.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('amotoki@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('amuller@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-stable-maint'),('apevec@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('apilotti@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('ayoung@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('berrange@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('blak111@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('blk@acm.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('carl@ecbaldwin.net','http://lists.openstack.org/pipermail/openstack-stable-maint'),('cbelu@cloudbasesolutions.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('chuck.short@canonical.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('corvus@inaugust.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('cosmos0703@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('dan@nicira.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('dave.walker@canonical.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('davewalker@ubuntu.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('david.lyle@hp.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('dkranz@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('dolph.mathews@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('dripton@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('emagana@plumgrid.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('email@daviey.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('enikanorov@mirantis.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('flavio@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('fungi@yuggoth.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('Gabriel.Hurley@nebula.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('gkotton@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('gkotton@vmware.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('heckj@mac.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('heckj@me.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('ihrachys@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jamielennox@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jenkins@openstack.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jogo@cloudscaling.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jordan.pittier@cloudwatt.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jpichon@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jsbryant@electronicjungle.net','http://lists.openstack.org/pipermail/openstack-stable-maint'),('jsbryant@us.ibm.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('julien@danjou.info','http://lists.openstack.org/pipermail/openstack-stable-maint'),('kchamart@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('kmestery@cisco.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('libosvar@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('majopela@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mangelajo@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mark.mcclain@dreamhost.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mbayer@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mestery@mestery.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mestery@noironetworks.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mkulkin@mirantis.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mmcclain@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('morgan.fainberg@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('motoki@da.jp.nec.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mriedem@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mrunge@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('mtreinish@kortar.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('ndipanov@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('nikhil@manchanda.me','http://lists.openstack.org/pipermail/openstack-stable-maint'),('nsaje@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('openstack-stable-maint@lists.openstack.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('osanai.hisashi@jp.fujitsu.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('P@draigBrady.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('psedlak@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('sandy.walsh@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-stable-maint'),('sdague@linux.vnet.ibm.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-stable-maint'),('shardy@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('sorlando@nicira.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('sukhdev@aristanetworks.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack-stable-maint'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/openstack-stable-maint'),('tjones@vmware.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('tristan.cacqueray@enovance.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('wpward@us.ibm.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('xqueralt@redhat.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('yaguang.tang@canonical.com','http://lists.openstack.org/pipermail/openstack-stable-maint'),('aclark@suse.com','http://lists.openstack.org/pipermail/openstack-tc'),('allison@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('anne@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('annegentle@justwriteclick.com','http://lists.openstack.org/pipermail/openstack-tc'),('anteaya@anteaya.info','http://lists.openstack.org/pipermail/openstack-tc'),('asalkeld@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('bcwaldon@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('Ben.Swartzlander@netapp.com','http://lists.openstack.org/pipermail/openstack-tc'),('boris@pavlovic.me','http://lists.openstack.org/pipermail/openstack-tc'),('chrisfer@us.ibm.com','http://lists.openstack.org/pipermail/openstack-tc'),('dan@nicira.com','http://lists.openstack.org/pipermail/openstack-tc'),('danwent@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('dbelova@mirantis.com','http://lists.openstack.org/pipermail/openstack-tc'),('devananda.vdv@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('dms@danplanet.com','http://lists.openstack.org/pipermail/openstack-tc'),('dolph.mathews@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('doug.hellmann@dreamhost.com','http://lists.openstack.org/pipermail/openstack-tc'),('doug@doughellmann.com','http://lists.openstack.org/pipermail/openstack-tc'),('dug@us.ibm.com','http://lists.openstack.org/pipermail/openstack-tc'),('eglynn@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('fontana@sharpeleven.org','http://lists.openstack.org/pipermail/openstack-tc'),('Gabriel.Hurley@nebula.com','http://lists.openstack.org/pipermail/openstack-tc'),('ghe@debian.org','http://lists.openstack.org/pipermail/openstack-tc'),('gilles@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('graham.hayes@hp.com','http://lists.openstack.org/pipermail/openstack-tc'),('heckj@mac.com','http://lists.openstack.org/pipermail/openstack-tc'),('heckj@me.com','http://lists.openstack.org/pipermail/openstack-tc'),('james.cooley@hp.com','http://lists.openstack.org/pipermail/openstack-tc'),('jarret.raim@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-tc'),('jaypipes@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('jeblair@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('jesse.noller@RACKSPACE.COM','http://lists.openstack.org/pipermail/openstack-tc'),('joe.gordon0@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('john.griffith8@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('john.griffith@solidfire.com','http://lists.openstack.org/pipermail/openstack-tc'),('julien@danjou.info','http://lists.openstack.org/pipermail/openstack-tc'),('kiall@hp.com','http://lists.openstack.org/pipermail/openstack-tc'),('lauren@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('mark.mcclain@dreamhost.com','http://lists.openstack.org/pipermail/openstack-tc'),('mark.washenberger@markwash.net','http://lists.openstack.org/pipermail/openstack-tc'),('mark@mcclain.xyz','http://lists.openstack.org/pipermail/openstack-tc'),('mark@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('markmc@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('mbasnight@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('me@not.mn','http://lists.openstack.org/pipermail/openstack-tc'),('messenger@webex.com','http://lists.openstack.org/pipermail/openstack-tc'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/openstack-tc'),('mmcclain@yahoo-inc.com','http://lists.openstack.org/pipermail/openstack-tc'),('mordred@inaugust.com','http://lists.openstack.org/pipermail/openstack-tc'),('nick.barcet@canonical.com','http://lists.openstack.org/pipermail/openstack-tc'),('nicolas@barcet.com','http://lists.openstack.org/pipermail/openstack-tc'),('rbryant@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('rkamaldinov@mirantis.com','http://lists.openstack.org/pipermail/openstack-tc'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/openstack-tc'),('robertc@robertcollins.net','http://lists.openstack.org/pipermail/openstack-tc'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/openstack-tc'),('sdake@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('sean@dague.net','http://lists.openstack.org/pipermail/openstack-tc'),('shardy@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('slukjanov@mirantis.com','http://lists.openstack.org/pipermail/openstack-tc'),('stefano@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('thierry@openstack.org','http://lists.openstack.org/pipermail/openstack-tc'),('vishvananda@gmail.com','http://lists.openstack.org/pipermail/openstack-tc'),('zbitter@redhat.com','http://lists.openstack.org/pipermail/openstack-tc'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/transparency'),('kyle.macdonald@canonical.com','http://lists.openstack.org/pipermail/transparency'),('lauren@openstack.org','http://lists.openstack.org/pipermail/transparency'),('markmc@redhat.com','http://lists.openstack.org/pipermail/transparency'),('nick@enovance.com','http://lists.openstack.org/pipermail/transparency'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/transparency'),('tristan@aptira.com','http://lists.openstack.org/pipermail/transparency'),('adam@varud.com','http://lists.openstack.org/pipermail/user-committee'),('aj@suse.com','http://lists.openstack.org/pipermail/user-committee'),('amitry@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('anne@openstack.org','http://lists.openstack.org/pipermail/user-committee'),('anniec@yahoo-inc.com','http://lists.openstack.org/pipermail/user-committee'),('arvindsr@us.ibm.com','http://lists.openstack.org/pipermail/user-committee'),('bluejay.ahn@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('bob.ball@citrix.com','http://lists.openstack.org/pipermail/user-committee'),('burt@fnal.gov','http://lists.openstack.org/pipermail/user-committee'),('carol.l.barrett@intel.com','http://lists.openstack.org/pipermail/user-committee'),('chris.c.kemp@nebula.com','http://lists.openstack.org/pipermail/user-committee'),('chrisfer@us.ibm.com','http://lists.openstack.org/pipermail/user-committee'),('colin@2cups.com','http://lists.openstack.org/pipermail/user-committee'),('dheerendra.madhusudhana@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('dneary@redhat.com','http://lists.openstack.org/pipermail/user-committee'),('duyujie.dyj@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('evan.scheessele@hp.com','http://lists.openstack.org/pipermail/user-committee'),('everett.toews@RACKSPACE.COM','http://lists.openstack.org/pipermail/user-committee'),('gfa@zumbi.com.ar','http://lists.openstack.org/pipermail/user-committee'),('harlowja@yahoo-inc.com','http://lists.openstack.org/pipermail/user-committee'),('hcm@uthi.com','http://lists.openstack.org/pipermail/user-committee'),('jch.martin@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('jcmartin@ebaysf.com','http://lists.openstack.org/pipermail/user-committee'),('jon@jonproulx.com','http://lists.openstack.org/pipermail/user-committee'),('jonathan@openstack.org','http://lists.openstack.org/pipermail/user-committee'),('joshua@pistoncloud.com','http://lists.openstack.org/pipermail/user-committee'),('julim@redhat.com','http://lists.openstack.org/pipermail/user-committee'),('ken.hui@RACKSPACE.COM','http://lists.openstack.org/pipermail/user-committee'),('koolhead17@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('laszewski@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('lauren@openstack.org','http://lists.openstack.org/pipermail/user-committee'),('lsurette@redhat.com','http://lists.openstack.org/pipermail/user-committee'),('mark.atwood@hp.com','http://lists.openstack.org/pipermail/user-committee'),('mark@collierclan.net','http://lists.openstack.org/pipermail/user-committee'),('marko.sluga@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('matt.griffin@percona.com','http://lists.openstack.org/pipermail/user-committee'),('mikal@stillhq.com','http://lists.openstack.org/pipermail/user-committee'),('mvanwink@rackspace.com','http://lists.openstack.org/pipermail/user-committee'),('natishalom@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('noggin143@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('pieter.c.kruithof-jr@hp.com','http://lists.openstack.org/pipermail/user-committee'),('rainya.mosher@RACKSPACE.COM','http://lists.openstack.org/pipermail/user-committee'),('rbowen@redhat.com','http://lists.openstack.org/pipermail/user-committee'),('rlane@wikimedia.org','http://lists.openstack.org/pipermail/user-committee'),('Rob_Hirschfeld@Dell.com','http://lists.openstack.org/pipermail/user-committee'),('rochelle.grober@huawei.com','http://lists.openstack.org/pipermail/user-committee'),('ruben.orduz@RACKSPACE.COM','http://lists.openstack.org/pipermail/user-committee'),('sean@dague.net','http://lists.openstack.org/pipermail/user-committee'),('seanrob@yahoo-inc.com','http://lists.openstack.org/pipermail/user-committee'),('sgordon@redhat.com','http://lists.openstack.org/pipermail/user-committee'),('shilla.saebi@gmail.com','http://lists.openstack.org/pipermail/user-committee'),('stefano@openstack.org','http://lists.openstack.org/pipermail/user-committee'),('steve.loving@metacloud.com','http://lists.openstack.org/pipermail/user-committee'),('subbu@subbu.org','http://lists.openstack.org/pipermail/user-committee'),('suhail.syed@intel.com','http://lists.openstack.org/pipermail/user-committee'),('Tim.Bell@cern.ch','http://lists.openstack.org/pipermail/user-committee'),('tom@openstack.org','http://lists.openstack.org/pipermail/user-committee'),('tom@spoonemore.net','http://lists.openstack.org/pipermail/user-committee'),('tristan@aptira.com','http://lists.openstack.org/pipermail/user-committee');
/*!40000 ALTER TABLE `mailing_lists_people` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `messages`
--

DROP TABLE IF EXISTS `messages`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `messages` (
  `message_ID` varchar(255) CHARACTER SET utf8 NOT NULL,
  `mailing_list_url` varchar(255) CHARACTER SET utf8 NOT NULL,
  `mailing_list` varchar(255) CHARACTER SET utf8 DEFAULT NULL,
  `first_date` datetime DEFAULT NULL,
  `first_date_tz` int(11) DEFAULT NULL,
  `arrival_date` datetime DEFAULT NULL,
  `arrival_date_tz` int(11) DEFAULT NULL,
  `subject` varchar(255) CHARACTER SET utf8 DEFAULT NULL,
  `message_body` text CHARACTER SET utf8,
  `is_response_of` varchar(255) CHARACTER SET utf8 DEFAULT NULL,
  `mail_path` text CHARACTER SET utf8,
  PRIMARY KEY (`message_ID`,`mailing_list_url`),
  KEY `response` (`is_response_of`),
  KEY `mailing_list_url` (`mailing_list_url`),
  CONSTRAINT `messages_ibfk_1` FOREIGN KEY (`mailing_list_url`) REFERENCES `mailing_lists` (`mailing_list_url`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `messages`
--

LOCK TABLES `messages` WRITE;
/*!40000 ALTER TABLE `messages` DISABLE KEYS */;
INSERT INTO `messages` VALUES ('<!&!AAAAAAAAAAAYAAAAAAAAAGzwB59IbutOr2VXhDfUt5bCgAAAEAAAAGTpjJ/GC2dGnr0cG31tnj0BAAAAAA==@cyle.ch>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-10 20:51:06',7200,'2014-10-10 18:51:06',NULL,'[Openstack] portability and cloudbursting','Dear Community\n\n \n\n1.       Is there a possibility to port images from a private openstack cloud to public cloud vendors or in the other direction?\n\nI?m interested in the portability of images from and to ec2, softlayer, azure and rackspace.\n\n \n\n2.       Is there a possibility to connect ec2,softlayer, azure and rackspace with my private openstack cloud to use it for cloudbrusting?\n\n \n\nIf yes, can you share some manuals and how to guidelines?\n\n \n\nThanks a lot\n\nBest\n\nCyrill\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141010/1cf3a0ef/attachment.html>\n\n',NULL,NULL),('<!&!AAAAAAAAAAAYAAAAAAAAAGzwB59IbutOr2VXhDfUt5bCgAAAEAAAAHBWgNaptPxLtOJc15O+UFEBAAAAAA==@cyle.ch>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-12 15:42:54',7200,'2014-10-12 13:42:54',NULL,'[Openstack] image portability from or to Rackspace','Dear community\n\n \n\nIs there a way to port images from and internal Openstack Cloud to or from Rackspace?\n\nIf yes,  is there a guideline available?\n\n \n\nBest regards\n\nCyrill\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141012/9e431b07/attachment.html>\n\n',NULL,NULL),('<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAWrzqbKAklUigF7FY6HCjEMKAAAAQAAAAal41/IkS0k2SFHP5zVZPvAEAAAAA@virtueinsight.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-06-07 13:07:38',16200,'2013-06-07 08:37:38',NULL,'[Openstack-operators] \"7th Cloud Computing 2013\" - Bangalore,\n	India...',' \n\n7th Cloud Computing 2013\"\n\n\"Accelerating your cloud strategy\"\n\n09th July 2013, Taj Vivanta - MG Road, Bangalore, India.\n\n \n\nGreeting From Virtue Insight,\n\nI am happy to invite you and your colleagues to be a sponsor/ delegate for\nour upcoming \"7th Cloud Computing 2013\". The conference will be held on 09th\nJuly 2013, Taj Vivanta - MG Road, Bangalore, India. \n\n \n\n SOME OF THE KEY SPEAKERS ARE FROM :- Salesforce.com, Hp, Centre for e\nGovernance, Government of Karnataka, Citrix, Microsoft (TBC), Cisco,\nVodafone, NIIT Technologies, Microsoft, L&T Infotech, Tonse Telecom,\nMahindra SSG, Deloitte Consulting, 8KMiles Plus Many More... \n\n \n\n*    TARGET AUDIENCE - INDUSTRY:- CIO/CTOs/CxOs, Heads of Business\nDevelopment, Strategy Director\'s, Directors   Telecommunication Manager\'s,\nCommunication Directors, Heads of Sales, Heads of Call and Contact\nManager\'s, VPs of Technology, Product Manager\'s, Business Development\nManagers,  Storage Manager\'s, Business Analysts, Database/Data Center\nManager, Hosting Manager\'s, Head of Training, System and Network\nIntegrators, Data Center Managers, Head of Telecoms, Compliance and Policy\nManager\'s, Network Administrator\'s. \n\n \n\n*    WHY SHOULD YOU ATTEND: - 7th Cloud Computing 2013 is the place to meet\nall the key decision makers across the entire cloud computing eco-system\nfrom enterprises, telecom operators, regulators, government agencies,\nservice providers, system integrators and vendors. This summit will provide\ngreat networking opportunities with industry leaders, presenting you with\nthe opportunity to meet and do business with likeminded individuals. \n\n \n\n*    CONFERENCE BOOKING DETAILS :- \n\nEarly Bird Discounted Price - Conference Delegate Pass (INR 4,000 + Tax\n(12.36%) per delegate) - Book and Pay before 27th May 2013 to avail the\nearly bird discounted price.\n\nThe Standard price for single delegate is (INR INR (5,000 + Tax (12.36%) per\ndelegate)\n\nGroup Discounts - 3 and above Delegates - (INR 4,000 + Tax (12.36%) per\ndelegate)\n\nSpot Registration on the day of the conference - 1 Day Conference - (INR\n6,000 + Tax (12.36%) per delegate)\n\nConference Sponsor & Exhibition Stall - Should you wish to Sponsor, or\npurchase a Exhibition Stall (Booth) or a paid Speaker Slot, you can simply\nemail your interest and queries to TEL: + 91 9171350244 or\ndeepak at virtueinsight.com, deepakrajvirtueinsight at gmail.com \n\nWe also have some sponsorship opportunities available for the event which\ngives you an opportunity to speak/exhibit and create brand awareness. In\naddition, the networking opportunities in focused and relevant industry\ngathering provide the personal contact necessary for business development\nefforts. \n\nIn case you or any of your colleagues might be interested in participating\nin the same, please let me know and I will be happy to call you and help you\nwith the registration.\n\nShould you have any questions, or to receive the updated event brochure or\nsponsorship details, please let me know, don\'t delay! Secure your place\ntoday by calling me on +91 9171350244 or Email - deepak at virtueinsight.com,\ndeepakrajvirtueinsight at gmail.com \n\nThank you for your time and consideration. I look forward to hearing from\nyou. \n\n \n\n Thanks & Regards, \n\nDeepak Raj\n\nDelegate Sales\n\nVirtue Insight\n\nTel -         + 91 44 65515693; \n\nGSM -       + 91 9171350244;\n\nE Mail -      deepak at virtueinsight.com\n\n                         www.virtueinsight.com\n<http://www.virtueinsight.com/> \n\n               www.virtueinsight.blogspot.com\n<http://www.virtueinsight.blogspot.com/>    \n\nFollow Us to keep yourself updated on our upcoming Conferences:  \n\nFacebook: http://facebook.com/virtue.insight\n\nLinked In:  http://in.linkedin.com/in/virtueinsight\n\nTwitter:    http://twitter.com/virtue_insight\n\nYou Tube: http://www.youtube.com/VirtueInsight\n\n\n\nCONFIDENTIALITY NOTICE\n\nThis message and any included attachments are from Virtue Insight and are\nintended only for the addressee. The information contained in this message\nis confidential and may constitute inside or non-public information under\ninternational, federal, or state securities laws. Unauthorized forwarding,\nprinting, copying, distribution, or use of such information is strictly\nprohibited and may be unlawful. If you are not the addressee, please\npromptly delete this message and notify the sender of the delivery error by\ne-mail at info at virtueinsight.com \n\nPlease consider the environment before printing this e-mail \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130607/20be9122/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.gif\nType: image/gif\nSize: 5633 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130607/20be9122/attachment-0001.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 5675 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130607/20be9122/attachment-0001.jpg>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130607/20be9122/attachment-0001.htm>\n\n',NULL,NULL),('<-1037316521717298265@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-27 15:35:49',-25200,'2013-07-27 22:35:49',NULL,'[Openstack] Fwd: Does anyone have a working cloud with Flat\n	Networking?','Make sure if you are using one NIC to configure a bridge interface\nwith the IP address and make the Ethernet interface a port to the\nbridge. Then you can use the Ethernet for the flat network and the IP\naddress on the bridge for management and L3 network connectivity.\n\nOn Jul 27, 2013, at 12:44 PM, comiqadze <comiq at yandex.ru> wrote:\n\n>\n>\n> Hi all,\n>\n> I want to ask for help!\n> Please mail me if you have already WORKING smoothly\n> Openstack cloud with Computes and Controller nodes, that work with Flat Networking configuration, i.e. with ONE NIC !\n> And also with full ubuntu as an image.\n>\n> Thank you,\n> Comiq\n>\n> _______________________________________________\n> Mailing list: %(list_owner)s\n> Post to     : %(list_post)s\n> Unsubscribe : %(list_unsubscribe)s\n> More help   : %(list_help)s\n\n\n','<502281374951916@web7h.yandex.ru>',NULL),('<-1427670325913770469@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-27 08:56:16',3600,'2014-12-27 07:56:16',NULL,'[openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination','+1\n\n-- \n\nBest regards,\n\nIllia Khudoshyn,\nSoftware Engineer, Mirantis, Inc.\n\n\n\n38, Lenina ave. <x-apple-data-detectors://1> Kharkov, Ukraine\n\nwww.mirantis.com <http://www.mirantis.ru/>\n\nwww.mirantis.ru\n\n\n\nSkype: gluke_work\n\nikhudoshyn at mirantis.com\n\n26 ???. 2014 ?., ? 15:16, isviridov <isviridov at mirantis.com> ???????(?):\n\nHello stackers and magnetians,\n\nI suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.\n\nDuring last months he has made huge contribution to MagnetoDB [2]\nAndrey drives Tempest and python-magnetodbclient successfully.\n\nPlease rise your hands.\n\nThank you,\nIlya Sviridov\n\n[1] http://stackalytics.com/report/users/aostapenko\n[2] http://stackalytics.com/report/contribution/magnetodb/90\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141227/30345ef7/attachment.html>\n\n','<549D6DCE.7080506@mirantis.com>',NULL),('<-1461011388042643659@unknownmsgid>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-05-27 00:09:36',36000,'2013-05-26 14:09:36',NULL,'[OpenStack Foundation] April 14th board meeting','I agree with Joshua and I support the approval process that has been in place.\n\n\nOn 26/05/2013, at 10:34 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n\nOn Sat, 2013-05-25 at 18:20 -0700, Joshua McKenty wrote:\n> A beautiful summary, and appreciated - however; as much as I hate to\n> be \"that guy\", I believe the purpose of the board approval for\n> Jonathan\'s \"unofficial recap\" was to have a single, semi-official\n> record of the meeting prior to any blogging free-for-all. I believe\n> board policy is still to forego any commentary on the meeting until\n> either Jonathan\'s notes, or the official board minutes, are published.\n\nJonathan did ask me to go ahead with mine since we were long overdue\nhowever, in retrospect, he also asked me to explicitly note that in my\nsummary and I didn\'t quite do that. Sorry for that.\n\n> As a more serious note - we should refrain from ANY description of\n> what was discussed during executive session - whether it was restated\n> afterwards or not.\n\nThis is what you\'re taking issue with?\n\nAs part of the voting process, some directors chose to publicly\nrestate their concerns with the applications that had been discussed\nduring the executive session.\n\nIt would have been better to leave it ambiguous as to whether these\nconcerns were stated in the executive session or whether they were\nraised for the first time after the executive session?\n\nThe way I saw it, the whole point of those statements after the\nexecutive session was to *restate* concerns publicly for the record ...\nnot to have a whole new conversation.\n\nCheers,\nMark.\n\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n','<1369571418.2325.32.camel@sorcha>',NULL),('<-1669200057889014972@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-07 06:36:31',-28800,'2013-11-07 14:36:31',NULL,'[Openstack] Is there any way to extend the ip address of subnet?','It is not aways possible to extend a subnet due holes in your address\nspace.\nBetter way is to add another subnet to the network.\nUnderlying plugin should be able handle this properly. Some WiFI vendors\ncall it VLAN pooling. Or some call it multi netting.\n\nRegards\n-Harshad\n\n\nOn Nov 7, 2013, at 2:17 AM, Daniel Speichert <daniel at speichert.pl> wrote:\n\n>From my experience, it is rather safe to extend allocation pools directly\nin the database.\nWe also did allocation pool shrinking but always make sure there is no IP\nassociated (or even assigned to a project) from out of the new range.\n\nCheck the neutron MySQL table: ipallocationpools.\n\nRegards,\nDaniel\n\n------------------------------\n\n*From: *\"Aaron Rosen\" <arosen at nicira.com>\n*To: *\"Sam Lee\" <lixq2000 at gmail.com>\n*Cc: *\"openstack\" <openstack at lists.openstack.org>\n*Sent: *Thursday, November 7, 2013 4:28:44 AM\n*Subject: *Re: [Openstack] Is there any way to extend the ip address of\nsubnet?\n\nHi Sam,\n\nUnfortunately we do not support updating the allocation-pools on subnets at\nthis time. This is something that we should definitely fix though in\nneutron.\n\nAaron\n\n\nOn Wed, Nov 6, 2013 at 10:46 PM, Sam Lee <lixq2000 at gmail.com> wrote:\n\n> Hi All,\n>\n>           I have created a subnet with 10 ips. But now I need more than\n> ten instances, is there any way to extend the subnet to add ip address?\n>           eg:\n>           I have ten ips as following:\n>                 172.16.2.210  ~ 172.16.2.220\n>\n>           I want to add 20 more ips, and so the result will be\n>                 172.16.2.210 ~ 172.16.2.230\n>\n>          I try subnet-update command and create a new subnet with the same\n> CIDR, but it doesn\'t work correctly.\n>\n>          Thanks in advance.\n>\n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131107/2d4c77b0/attachment.html>\n\n','<22131917.280.1383818198714.JavaMail.Daniel@Daniel-PC>',NULL),('<-1950210928605427642@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-03-30 14:25:11',-14400,'2013-03-30 18:25:11',NULL,'[Openstack-docs] eliminate \"trunk\" use \"current\" instead?','On Mar 30, 2013, at 2:07 PM, Joe Topjian <joe.topjian at cybera.ca> wrote:\n\n\n\n\nOn Sat, Mar 30, 2013 at 7:17 AM, Anne Gentle <anne at openstack.org> wrote:\n\n>\n>\n>\n> On Fri, Mar 29, 2013 at 11:28 PM, Tom Fifield <fifieldt at unimelb.edu.au>wrote:\n>\n>> On 30/03/13 11:27, Laura Alves wrote:\n>> >\n>> >\n>> > On Fri, Mar 29, 2013 at 7:47 PM, Anne Gentle <anne at openstack.org\n>> > <mailto:anne at openstack.org>> wrote:\n>> >\n>> >     Hi all,\n>> >     Would you be okay if we stop using /trunk/ for the current \"built\n>> >     from git\" versions of the documentation and copied the files to\n>> >     docs.openstack.org/current <http://docs.openstack.org/current>\n>> >     instead? The word \"trunk\" is leftover from bzr/Launchpad days of\n>> yore.\n>> >\n>> >     The tasks that have to happen for this to occur are:\n>> >     - Change all the /trunk/ build jobs in openstack-infra/config to\n>> >     /current/\n>> >     - Check all the pom.xml files for mentions of trunk\n>> >     - Ensure that the sitemap.xml stored on the web server contains\n>> >     /current links\n>> >     - Ensure comments are turned off for /current just like they are for\n>> >     /trunk\n>> >     - Change all the openstack-manuals/www/ pages to point to /current\n>> >     instead of /trunk\n>> >     - Change the Google Custom Search Engine from /trunk to /current (we\n>> >     hide /trunk from the CSE searches)\n>> >\n>> >     Anything else? Warn the mailing list or get further input?\n>> >\n>> >     If no one objects by next Tuesday, I\'ll put this on my to-do list\n>> >     for next week.\n>> >\n>> >     Thanks,\n>> >     Anne\n>> >\n>> >     P.S. Note that this rename is similar to cutting a doc release,\n>> >     documented here:\n>> https://wiki.openstack.org/wiki/Documentation/Release\n>> >\n>> >     _______________________________________________\n>> >     Openstack-docs mailing list\n>> >     Openstack-docs at lists.openstack.org\n>> >     <mailto:Openstack-docs at lists.openstack.org>\n>> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>> >\n>> >\n>> > +1\n>> >\n>> > If there is consensus about this, does it sound like a good idea to\n>> > split the tasks?\n>> > I can certainly help with the pom.xml files, since I\'ve got some patches\n>> > in review and some others to submit, I could check for trunk in them.\n>> >\n>> > Regards!\n>> > Laura\n>>\n>> One note for consideration (just putting this out there - no strong\n>> feelings):\n>>\n>> From a user perspective, \'trunk\' and \'current\' could come across quite\n>> differently. As an Operator, when I see \'trunk\' I think \"oh, that\'s\n>> something to do with the code. I\'m running a production system, so I\'ll\n>> ignore that and find the stable release\". When I see \'current\', I\n>> associate that with the current stable release.\n>>\n>>\n>>\n> This is my thinking as well, that \"current\" means \"current supported\n> version\" and not \"draft in progress\" -- but I\'ve heard otherwise. I think\n> we need a new name for trunk. What about master?\n>\n\nI think the most unambiguous word would be \"dev\". Or devel or development.\n\nMaybe another word could be \"pre\" or \"prerelease\". It doesn\'t sound as\nscary as \"dev\" and maybe more curious users would look at it to see what\'s\nahead in the upcoming version.\n\n\n\n+1 for devel, that would be my preference.\n\nLorin\n\nSent from my iPhone\n\n\n\n\n>\n>\n>> One thing I noticed about the development cycle is that a bunch of\n>> deprecation happened early. Options slated for removal tended to be\n>> deleted as soon as the code freeze was over. I may be living in a dream\n>> world, but I feel that we should be putting these changes into the\n>> documentation as soon as we can after we spot them - an automated system\n>> (which I think is the aim for config options) would certainly do this.\n>> With changes in this manner, the \'current\' doc would be quite quickly\n>> inconsistent with \'current stable release\' and that could cause confusion.\n>>\n>>\n> Yes we definitely should automate the config files - Tom can you share\n> your process?\n>\n> Anne\n>\n>\n>> All this can likely be fixed by some careful wording in the release\n>> selection page for those coming via docs.openstack.org, but I worry\n>> about those who come in direct via Google. Perhaps a little \'draft\' or\n>> \'pre-release\' banner with a link to the current release is needed in the\n>> template.\n>>\n>>\n>> Thoughts?\n>>\n>>\n>> Regards,\n>>\n>>\n>> Tom\n>>\n>>\n>>\n>> _______________________________________________\n>> Openstack-docs mailing list\n>> Openstack-docs at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>>\n>\n>\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n>\n\n\n-- \nJoe Topjian\nSystems Administrator\nCybera Inc.\n\nwww.cybera.ca\n\nCybera is a not-for-profit organization that works to spur and support\ninnovation, for the economic benefit of Alberta, through the use\nof cyberinfrastructure.\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130330/2e047f0b/attachment-0001.html>\n\n','<CAD07=DdPzK1-GaD6su_TqHNKhSamm3N3ucz5y72kcKZrMB5d3g@mail.gmail.com>',NULL),('<-2647283219716699234@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 04:22:31',0,'2014-08-05 04:22:31',NULL,'[openstack-dev] Networking Docs Swarm - Brisbane 9 August','Cant make it to Brisbane but this doc is so needed. Any chamce you could\nput round a questionaire or sethomg similar to get input from those who\ncant make it?\n\n\n\n--\n\nBR,\n\nStuart\n\n\n\nOn 14-08-04 8:05 PM Lana Brindley wrote:\nHi everyone,\n\n I just wanted to let you all know about the OpenStack Networking Docs\nSwarm being held in Brisbane on 9 August.\n\n Currently, there is no OpenStack Networking Guide, so the focus of this\nswarm is to combine the existing networking content into a single doc so\nthat it can be updated, reviewed, and hopefully completed for the Juno\nrelease.\n\n We need both tech writers and OpenStack admins for the event to be a\nsuccess. Even if you can only make it for half an hour, your presence\nwould be greatly appreciated!\n\n RSVP here:\n\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n More information here:\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n See you on Saturday!\n\n Lana\n\n-- \n Lana Brindley\nTechnical Writer\nRackspace Cloud Builders Australia\n\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n_______________________________________________\n OpenStack-dev mailing list\n OpenStack-dev at lists.openstack.org\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/32bd9308/attachment.html>\n\n','<53E049F4.3030000@lanabrindley.com>',NULL),('<-2647283219716699234@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-05 04:22:31',0,'2014-08-05 04:22:31',NULL,'[Openstack-docs] [openstack-dev] Networking Docs Swarm -\n	Brisbane 9 August','Cant make it to Brisbane but this doc is so needed. Any chamce you could\nput round a questionaire or sethomg similar to get input from those who\ncant make it?\n\n\n\n--\n\nBR,\n\nStuart\n\n\n\nOn 14-08-04 8:05 PM Lana Brindley wrote:\nHi everyone,\n\n I just wanted to let you all know about the OpenStack Networking Docs\nSwarm being held in Brisbane on 9 August.\n\n Currently, there is no OpenStack Networking Guide, so the focus of this\nswarm is to combine the existing networking content into a single doc so\nthat it can be updated, reviewed, and hopefully completed for the Juno\nrelease.\n\n We need both tech writers and OpenStack admins for the event to be a\nsuccess. Even if you can only make it for half an hour, your presence\nwould be greatly appreciated!\n\n RSVP here:\n\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n More information here:\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n See you on Saturday!\n\n Lana\n\n-- \n Lana Brindley\nTechnical Writer\nRackspace Cloud Builders Australia\n\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n\n_______________________________________________\n OpenStack-dev mailing list\n OpenStack-dev at lists.openstack.org\nhttp://www.meetup.com/Australian-OpenStack-User-Group/events/198867972/?gj=rcs.b&a=co2.b_grp&rv=rcs.b\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140805/32bd9308/attachment.html>\n\n','<53E049F4.3030000@lanabrindley.com>',NULL),('<-3202173836290961882@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-30 13:56:14',-18000,'2011-11-30 18:56:14',NULL,'[Openstack-operators] FW: Question about swauth','The error means your are missing a python package.\nWhen you say you installed from source - what do you mean?\nYou might want to look at python distutils around how dependencies for\npython packages are handled\n\nOn Nov 30, 2011, at 12:53, Manu Dargan <@twinstratay.com> wrote:\n\nHello,\n\n\n\n                I am trying to install OpenStack for the first time locally\nwithin my environment and ran into an issue which I hope someone can\naddress.\n\n\n\nMy Config:\n\nI have created 6 servers all running Ubuntu 10.04 LTS.  Five of the six\nservers I have configured as the storage nodes.  The sixth is my Proxy/Auth\n node.  I have followed the admin guide step by step.  On the proxy node  I\nhave done the following:\n\n\n\nApt-get install python-software-properties\n\nAdd-apt-repository ppa:swift-core/ppa\n\nApt-get update\n\nApt-get install swift openssh-server\n\nMkdir ?p /etc/swift\n\nChown ?R swift:swift /etc/swift/\n\n\n\nCreated the swift.conf with the following entries\n\n[swift-hash]\n\nSwift_hash_path_suffix = theactualhash\n\n\n\nNow the instructions tell me to install swauth from\nhttps://github.com/gholt/swauth.  I downloaded the package and untarred it\ninto a dir and installed it.  One of the steps during installation involves\nrunning this command:\n\n\n\nswauth-prep -K swauthkey\n\n\n\n*I run that command get the following error:*\n\n\n\n<image004.png>\n\n\n\nDoes anyone know what this error indicates and how to resolve it.  Thanks.\n\n\n\n*Manu **Dargan**\n**Services & Support Manager***\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111130/d25f8d9b/attachment.html>\n\n','<021f01ccaf88$cd431380$67c93a80$@twinstrata.com>',NULL),('<-3244997204274090590@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 20:51:53',-25200,'2013-08-08 03:51:53',NULL,'[Openstack] Instance cannot access internet','  Br-ex is meant for external network.\nYou can add br-ex to any interface which will allow reaching internet.\nBr-int which your vms are already using is for internal network.\n\n\nSent from my Windows Phone\n ------------------------------\nFrom: Jake G. <dj_dark_junglist at yahoo.com>\nSent: 08-08-2013 09:18 AM\nTo: openstack at lists.openstack.org\nSubject: Re: [Openstack] Instance cannot access internet\n\nWhat do you mean by external interface? I access and get internet through\neth0 on my host.\nSo does that mean I will use eth0?\n\nJust want to be sure cause some documents say I should add my private\ninterface(eth1) to br-ex\n\nThank you!\n\n\n\n  ------------------------------\n *From:* Ritesh Nanda <riteshnanda09 at gmail.com>\n*To:* Jake G. <dj_dark_junglist at yahoo.com>\n*Cc:* nilesh pawar <nilesh56 at gmail.com>; \"openstack at lists.openstack.org\" <\nopenstack at lists.openstack.org>\n*Sent:* Thursday, August 8, 2013 12:14 PM\n*Subject:* Re: [Openstack] Instance cannot access internet\n\nhello jake,\n\nCan\'t see that you have added any external interface to br-ex in ovs-vsctl\nshow command output.\n\novs-vsctl add-br br-ex\novs-vsctl add-port br-ex <external interface>\nip link set up br-ex\n\n\n\n\nOn Mon, Aug 5, 2013 at 4:07 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\n- Yes My br-ex bridge has the IP 192.168.100.1 which I can ping from the\n192.168.100.X network.\n-I cannot ping 192.168.100.98 from the the 192.168.100.X network and Openstack\nHost\n\n\n------ My openvswith layout-----\nsudo ovs-vsctl show\n3e02cdce-70d3-4f04-8f85-ec76aa63967b\n    Bridge br-ex\n        Port \"qg-8f16644e-43\"\n            Interface \"qg-8f16644e-43\"\n                type: internal\n        Port br-ex\n            Interface br-ex\n                type: internal\n    Bridge br-int\n        Port br-int\n            Interface br-int\n                type: internal\n        Port \"qvo2a3d522a-28\"\n            tag: 1\n            Interface \"qvo2a3d522a-28\"\n        Port \"tap2a713313-38\"\n            tag: 1\n            Interface \"tap2a713313-38\"\n                type: internal\n        Port \"qr-504a0174-ce\"\n            tag: 1\n            Interface \"qr-504a0174-ce\"\n                type: internal\n----------------------------------------------\n\n\n  ------------------------------\n *From:* nilesh pawar <nilesh56 at gmail.com>\n*To:* Jake G. <dj_dark_junglist at yahoo.com>\n*Cc:* \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n*Sent:* Monday, August 5, 2013 7:30 PM\n*Subject:* Re: [Openstack] Instance cannot access internet\n\nHi\ncan u try to ping 192.168.100.98.\nAlso is ur br-ext over quantum node having an IP.?\n\n\nOn Mon, Aug 5, 2013 at 1:39 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nHi all! I have finally made some progress on networking, but now I have an\nissue with accessing the internet from an instance.\n\nAfter creating an instance, it receives a private IP from DHCP services\n(including DNS servers) which I can see in the console. Trying to ping\nyahoo.com does not work but I can ping 10.0.0.1 which is the private\nnetwork gateway.\n\nI attached some helpful screenshots. I did notice that in the Network\nTopology view, there is no gateway IP address for the Public network\nshowing,\nBut I did set the gateway to 192.168.100.98\n\nThank you in advance.\nJake\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n-- \nNilesh Pawar\n\n\nAvoid the Gates of Hell.  Use Linux\n\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n-- \n* With Regards\n*\n* Ritesh Nanda\n*\n***\n*\n<http://www.ericsson.com/>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130807/31fbdb57/attachment.html>\n\n',NULL,NULL),('<-3474106049364153335@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 19:35:49',-28800,'2014-02-15 03:35:49',NULL,'[openstack-dev] VPC Proposal','Hi JC,\n\nYou have put it aptly. Goal of the blueprint is to present facade for\nAWS VPC API as the name suggest.\nAs per your definition of VPC, shared network will have issues.\nHowever many of these concepts are not exposed to a AWS customers and\nthe API work well.\nWhile we work incrementally towards your definition of VPC we can\nmaintain API compatibility to AWS API that we are proposing. As we are\nsubset of your proposal and don\'t expose all features within VPC.\n\nRegards\n-Harshad\n\n\n> On Feb 14, 2014, at 6:22 PM, \"Martin, JC\" <jch.martin at gmail.com> wrote:\n>\n> Rudra,\n>\n> I do not agree that the current proposal provides the semantic of a VPC. If the goal is to only provide a facade through the EC2 API, it may address this, but unless you implement the basic features of a VPC, what good is it doing ?\n>\n> I do believe that the work can be done incrementally if we agree on the basic properties of a VPC, for example :\n>   - allowing projects to be created while using resources defined at the VPC level\n>   - preventing resources not explicitly defined at the VPC level to be used by a VPC.\n>\n> I do not see in the current proposal how resources are scoped to a VPC, and how, for example, you prevent shared network to be used within a VPC, or how you can define shared networks (or other shared resources) to only be scoped to a VPC.\n>\n> I think we already raised our concern to you several months ago, but it did not seem to have been addressed in the current proposal.\n>\n> thanks,\n>\n> JC\n>\n>> On Feb 14, 2014, at 3:50 PM, Rudra Rugge <rrugge at juniper.net> wrote:\n>>\n>> Hi JC,\n>>\n>> We agree with your proposed model of a VPC resource object. Proposal you are making makes sense to us and we would like to collaborate further on this. After reading your blueprint two things come to mind.\n>>\n>> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)\n>> 2. Providing AWS VPC api compatibility with current constrains of openstack structure.\n>>\n>> The blueprint that we proposed targets #2.\n>> It gives a way to implement \"AWS VPC api\" compatible API. This helps subset of customers to migrate their workloads from AWS to openstack based clouds. In our implementation we tied VPC to project. That was easiest way to keep isolation with current structure. We agree that what you are proposing is more generic. One to way is to implement our current proposal to have one VPC to one project mapping. As your blueprint matures we will\n>> move VPC to multiple project mapping.\n>>\n>> We feel that instead of throwing away all the work done we can take an incremental approach.\n>>\n>> Regards,\n>> Rudra\n>>\n>>\n>>> On Feb 14, 2014, at 11:09 AM, Martin, JC <jch.martin at gmail.com> wrote:\n>>>\n>>>\n>>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the AWS VPC api. I don\'t think that this blueprint is providing the necessary constructs to really implement a VPC, and it is not taking into account the domains, or proposed multi tenant hierarchy. In addition, I could not find a discussion about this topic leading to the approval.\n>>>\n>>> For this reason, I wrote an \'umbrella\' blueprint to hopefully start the discussion on how to really implement VPC, and eventually split it into multiple real blueprints for each area.\n>>>\n>>> Please, provide feedback on the following document, and on the best way to move this forward.\n>>>\n>>> https://wiki.openstack.org/wiki/Blueprint-VPC\n>>>\n>>> Thanks,\n>>>\n>>> JC.\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<29291B4C-7948-42AF-B29F-6D4ED3DBCB3C@gmail.com>',NULL),('<-3578621136898973492@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-29 00:02:16',0,'2014-07-29 00:02:16',NULL,'[Openstack-operators] [OpenStack-Operators] [Cinder] Request\n for input on new/advanced features','This sounds cool but wouldn\'t it put cinder in the data path if you are\nreplicating across vendors?\n\n\n\n--\n\nBR,\n\nStuart\n\n\n\nOn 14-07-28 3:01 PM gustavo panizzo (gfa) wrote:\n\n On 07/26/2014 11:28 AM, John Griffith wrote:\n> Hey OS-Operators,\n>\n> There are two features being worked on currently that I\'d love to get\n> some feedback on:\n>\n> 1. Replication\n\n i would like to Cinder to be able to replicate data between different\nbackend storages.\n\n sometimes your DR site does not have the same storage backend as your\nprimary site, this is common when you rent the DR site.\nthe usual workaround for this is restore from backup over the DR\nstorage, which is painful and slow.\n\n ideally i would have a Fast dedicated storage on primary site and a\nbunch of lun(s) attached to a box with iscsi+lvm to provide volumes to\ncompute nodes.\n\n if i have storage from the same \'vendor\' on both sites that\'s great!\ncinder could offload data replication to vendor\'s appliance\n\n i know is a pony what i\'m asking for, but i would really make a difference\n\n\n-- \n 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n\n\n_______________________________________________\n OpenStack-operators mailing list\n OpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140729/54a94254/attachment.html>\n\n','<53D6C821.2080107@zumbi.com.ar>',NULL),('<-4008899877835891384@unknownmsgid>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-10 08:25:15',39600,'2013-10-09 21:25:15',NULL,'[OpenStack Foundation] Individual Member Director Elections','Thanks Tim, it\'s not clear to me either.\n\nSent from phone.\n\nOn 10 Oct 2013, at 8:13 am, Tim Bell <Tim.Bell at cern.ch> wrote:\n\n\n\nIt is not clear to me that SVT or Condorcet would eliminate ballot stuffing.\n\n\n\nTim\n\n\n\n*From:* Ryan Lane [mailto:rlane at wikimedia.org <rlane at wikimedia.org>]\n*Sent:* 09 October 2013 23:06\n*To:* Boris Renski\n*Cc:* foundation at lists.openstack.org\n*Subject:* Re: [OpenStack Foundation] Individual Member Director Elections\n\n\n\nOn Wed, Oct 9, 2013 at 1:53 PM, Boris Renski <brenski at mirantis.com> wrote:\n\n I agree with Thierry and have mentioned this during the last board\nmeeting. I don\'t think there is anything fundamentally wrong with the\nelection process itself. We should just focus on pruning inactive\nfoundation members and creating a sensible, minimal barrier to voter\neligibility.\n\n\n\nIs there anyone who does not agree with this?\n\n\n\n\n\nAren\'t many people in this thread saying there is indeed something wrong\nwith the election method being used? It allows easy ballot stuffing.\n\n\n\n- Ryan\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131010/9e1b588c/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9783C81@CERNXCHG01.cern.ch>',NULL),('<-4426752061342328447@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-16 08:01:14',-28800,'2014-02-16 16:01:14',NULL,'[openstack-dev] [keystone] role of Domain in VPC definition','Yes, [1] can be done without [2] and [3].\nAs you are well aware [2] is now merged with group policy discussions.\nIMHO all or nothing approach will not get us anywhere.\nBy the time we line up all our ducks in row. New features/ideas/blueprints\nwill keep Emerging.\n\nRegards\n-Harshad\n\n\nOn Feb 16, 2014, at 2:30 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n\nIt seems this work item is made of several blueprints, some of which are\nnot yet approved. This is true at least for the Neutron blueprint regarding\npolicy extensions.\n\nSince I first looked at this spec I\'ve been wondering why nova has been\nselected as an endpoint for network operations rather than Neutron, but\nthis probably a design/implementation details whereas JC here is looking at\nthe general approach.\n\nNevertheless, my only point here is that is seems that features like this\nneed an \"all-or-none\" approval.\nFor instance, could the VPC feature be considered functional if blueprint\n[1] is implemented, but not [2] and [3]?\n\nSalvatore\n\n[1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n[2]\nhttps://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n[3]\nhttps://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy\n\n\nOn 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com> wrote:\n\n> Ravi,\n>\n> It seems that the following Blueprint\n> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n>\n> has been approved.\n>\n> However, I cannot find a discussion with regard to the merit of using\n> project vs. domain, or other mechanism for the implementation.\n>\n> I have an issue with this approach as it prevents tenants within the same\n> domain sharing the same VPC to have projects.\n>\n> As an example, if you are a large organization on AWS, it is likely that\n> you have a large VPC that will be shred by multiple projects. With this\n> proposal, we loose that capability, unless I missed something.\n>\n> JC\n>\n> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:\n>\n> > Hi,\n> >   We had some internal discussions on role of Domain and VPCs. I would\n> like to expand and understand community thinking of Keystone domain and\n> VPCs.\n> >\n> > Is VPC equivalent to Keystone Domain?\n> >\n> > If so, as a public cloud provider - I create a Keystone domain and give\n> it to an organization which wants a virtual private cloud.\n> >\n> > Now the question is if that organization wants to have  departments wise\n> allocation of resources it is becoming difficult to visualize with existing\n> v3 keystone constructs.\n> >\n> > Currently, it looks like each department of an organization cannot have\n> their own resource management with in the organization VPC ( LDAP based\n> user management, network management or dedicating computes etc.,) For us,\n> Openstack Project does not match the requirements of a department of an\n> organization.\n> >\n> > I hope you guessed what we wanted - Domain must have VPCs and VPC to\n> have projects.\n> >\n> > I would like to know how community see the VPC model in Openstack.\n> >\n> > Thanks,\n> > -Ravi.\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/9258cf27/attachment.html>\n\n','<CAGR=i3haRxJKXighUPcR+tDFLXEkuDu+LmchHgiit1NS1egnPQ@mail.gmail.com>',NULL),('<-4463175152181274322@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-11 03:19:21',-25200,'2013-10-11 10:19:21',NULL,'[Openstack] 答复:  Compute Node Resources','You can google \"nova scheduler\". This component decides where to put\nthe instances. ???: Mina Nagy Zaki\n????: ?2013/?10/?11 17:50\n???: openstack\n??: [Openstack] Compute Node Resources\nHello list,\nHow does nova decide which compute node it\'s going to deploy a new VM to?\nCan I specify that I want to deploy a VM to a specific host?\n\nThanks!\n-- \nMina Nagy Zaki\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n',NULL,NULL),('<-5433231319206004095@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-13 23:39:55',19800,'2013-08-13 18:09:55',NULL,'[Openstack] quantum l2 networks','I guess it\'s already back-ported to Grizzly 2013.1.3 cycle\n\nhttps://review.openstack.org/#/c/32679\n\n\nBest\nAshok\n\nSent from my iPhone\n\nOn 13-Aug-2013, at 6:24 PM, Francois Deppierraz <francois at ctrlaltdel.ch>\nwrote:\n\nHi Aaron,\n\nThanks for the patch!\n\nI was experiencing the same issue than the OP with grizzly installed\nfrom the Ubuntu Cloud Archive with quantum and openvswitch. Adding\nsecurity groups to a running instance works well now.\n\nIs there any plan to have it included in the havana release, or even\nbetter patched in grizzly?\n\nCheers,\n\nFran?ois\n\nOn 08. 06. 13 11:40, Aaron Rosen wrote:\n\nHi Daniel,\n\n\nThat\'s for finding this! This is a bug. The code wasn\'t accounting if\n\nthe plugin didn\'t implement port_security_enabled.  Here\'s a patch that\n\nfixes the issue in the meantime.\n\n\nBest,\n\n\nAaron\n\n\n--- a/nova/network/security_group/quantum_driver.py\n\n+++ b/nova/network/security_group/quantum_driver.py\n\n@@ -340,8 +340,9 @@ class\n\nSecurityGroupAPI(security_group_base.SecurityGroupBase):\n\n        has_ip = port.get(\'fixed_ips\')\n\n        if port_security_enabled and has_ip:\n\n            return True\n\n-        else:\n\n-            return False\n\n+        elif \'port_security_enabled\' not in port and has_ip:\n\n+            return True\n\n+        return False\n\n\n    @wrap_check_security_groups_policy\n\n    def add_to_instance(self, context, instance, security_group_name):\n\n\n\n\nOn Sat, Jun 8, 2013 at 2:14 AM, daniels cai <danxcai at gmail.com\n\n<mailto:danxcai at gmail.com <danxcai at gmail.com>>> wrote:\n\n\n\n   nova add-secgroup 24891d97-8d0e-4e99-9537-c8f8291913d0 d11\n\n\n   ERROR: Network requires port_security_enabled and subnet associated\n\n   in order to apply security groups. (HTTP 400) (Request-ID:\n\n   req-94cb2d54-858b-4843-af53-b373c88bcdc0)\n\n\n\n   security group is exists\n\n\n   # quantum security-group-list\n\n   +--------------------------------------+---------+------------------+\n\n   | id                                   | name    | description      |\n\n   +--------------------------------------+---------+------------------+\n\n   | 0acc8258-bd9f-4f87-b051-a94dbc1504eb | default | default          |\n\n   | 5902febc-e793-4b09-8073-567226d83d79 | d11     | des for firewall |\n\n   +--------------------------------------+---------+------------------+\n\n\n\n\n   Daniels Cai\n\n   http://dnscai.com\n\n\n\n   2013/6/8 Aaron Rosen <arosen at nicira.com\n<mailto:arosen at nicira.com<arosen at nicira.com>\n>>\n\n\n       You said:\n\n\nit works, but when i try to attach a security group to an exist\n\n       vm , api throw an error :\"Network requires\n\nport_security_enabled and subnet associated in order to apply\n\n       security groups.\"\n\n\n       What command are you running to generate that error?\n\n\n\n\n       On Sat, Jun 8, 2013 at 1:45 AM, daniels cai <danxcai at gmail.com\n\n       <mailto:danxcai at gmail.com <danxcai at gmail.com>>> wrote:\n\n\n           Aaron , thanks for you answers, i see it.\n\n\n           we are not useing nvp in our environemnt\n\n           yet.\n\n\n           my vm is boot with a subnet_id specified\n\n           .\n\n           i am sure about it .\n\n           here is more info:\n\n\n           vm has an ip \"192.168.6.100\" , this ip belongs to subnet\n\n           83afd693-7e36-41e9-b896-9d8b0d89d255\n\n           , this subnet belongs to network \"iaas-net\", network id is\n\n           5332f0f7-3156-4961-aa67-0b8507265fa5\n\n\n           # nova list\n\n\n           | 24891d97-8d0e-4e99-9537-c8f8291913d0 |\n\n           ubuntu-1304-server-amd64 | ACTIVE  | iaas-net=192.168.6.100\n\n\n           here is quantum network info :\n\n\n           # quantum net-list\n\n           +--------------------------------------+------------------+-------------------------------------------------------+\n\n           | id                                   | name             |\n\n           subnets                                               |\n\n           +--------------------------------------+------------------+-------------------------------------------------------+\n\n           |\n\n           5332f0f7-3156-4961-aa67-0b8507265fa5 | iaas-net         |\n\n           329ca377-6193-4a0c-9320-471cd5ff762f 192.168.202.0/24\n\n           <http://192.168.202.0/24> |\n\n           |                                      |                  |\n\n           83afd693-7e36-41e9-b896-9d8b0d89d255 192.168.6.0/24\n\n           <http://192.168.6.0/24>   |\n\n           |                                      |                  |\n\n           bb1afb2d-ab59-4ba4-8a76-8b5b426b8e33 192.168.7.0/24\n\n           <http://192.168.7.0/24>   |\n\n           |                                      |                  |\n\n           d59794df-bb49-4924-a19f-cbdec0ce24df 192.168.188.0/24\n\n           <http://192.168.188.0/24> |\n\n           |                                      |                  |\n\n           dca45033-e506-42e4-bf05-aaccd0591c55 192.168.193.0/24\n\n           <http://192.168.193.0/24> |\n\n           |                                      |                  |\n\n           e8a9be74-2f39-4d7e-9287-c5b85b573cca 192.168.192.0/24\n\n           <http://192.168.192.0/24> |\n\n\n\n           i enabled the following features in quantum\n\n           1. namespace\n\n           2. overlap ips\n\n\n           if any more info needed for debug, i will attach\n\n\n\n\n           Daniels Cai\n\n           http://dnscai.com\n\n\n\n           2013/6/8 Aaron Rosen <arosen at nicira.com\n\n           <mailto:arosen at nicira.com <arosen at nicira.com>>>\n\n\nThere is no port_security_enabled config option. This is\n\n           an attribute on a port that is used if the plugin you are\n\n           using implements the port_security_extension (which is only\n\n           nvp at the time).\n\n\nI\'m guessing your issue is the network you are trying to\n\n           boot an instance on does not have a subnet associated with it.\n\n\nAaron\n\n\n\nOn Sat, Jun 8, 2013 at 12:37 AM, daniels cai\n\n           <danxcai at gmail.com <mailto:danxcai at gmail.com <danxcai at gmail.com>>>\nwrote:\n\n\nhi Aaron\n\ni set the following in nova.conf\n\n\nsecurity_group_api=quantum\n\nfirewall_driver=nova.virt.firewall.NoopFirewallDriver\n\n\nit works, but when i try to attach a security group to an\n\n           exist vm , api throw an error :\n\n\n\"Network requires port_security_enabled and subnet\n\n           associated in order to apply security groups.\"\n\n\nthe i add port_security_enabled in quantum.conf in all nodes.\n\n\"port_security_enabled=True\"\n\n\nwith no luck, it still doesn\'t work .\n\n\nAny advice ? does quantum security group support this\n\n           feature?\n\n\nDaniels Cai\n\nhttp://dnscai.com\n\n\n\n2013/6/8 Aaron Rosen <arosen at nicira.com\n\n           <mailto:arosen at nicira.com <arosen at nicira.com>>>\n\n\nHi Joe,\n\n\nI thought setting firewall_driver =\n\n           quantum.agent.firewall.NoopFirewallDriver would do the\n\n           trick? Also, the ovs plugin does not do any mac spoof\n\n           filtering at the OVS level. Those are all done in iptables.\n\n\nAaron\n\n\nOn Fri, Jun 7, 2013 at 8:22 PM, Joe Breu\n\n           <joseph.breu at rackspace.com\n\n           <mailto:joseph.breu at rackspace.com <joseph.breu at rackspace.com>>>\nwrote:\n\n\nHello,\n\n\nIs there a way to create a quantum l2 network using OVS\n\n           that does not have MAC and IP spoofing enabled either in\n\n           iptables or OVS?  One workaround that we found was to set\n\n           the OVS plugin firewall_driver =\n\n           quantum.agent.firewall.NoopFirewallDriver to\n\n           security_group_api=nova however this is far from ideal and\n\n           doesn\'t solve the problem of MAC spoof filtering at the OVS\n\n           level.\n\n\nThanks for any help\n\n\n\n_______________________________________________\n\nMailing list: https://launchpad.net/~openstack\n\nPost to     : openstack at lists.launchpad.net\n\n           <mailto:openstack at lists.launchpad.net<openstack at lists.launchpad.net>\n>\n\nUnsubscribe : https://launchpad.net/~openstack\n\nMore help   : https://help.launchpad.net/ListHelp\n\n\n\n\n_______________________________________________\n\nMailing list: https://launchpad.net/~openstack\n\nPost to     : openstack at lists.launchpad.net\n\n           <mailto:openstack at lists.launchpad.net<openstack at lists.launchpad.net>\n>\n\nUnsubscribe : https://launchpad.net/~openstack\n\nMore help   : https://help.launchpad.net/ListHelp\n\n\n\n\n\n\n\n\n\n\n_______________________________________________\n\nMailing list: https://launchpad.net/~openstack\n\nPost to     : openstack at lists.launchpad.net\n\nUnsubscribe : https://launchpad.net/~openstack\n\nMore help   : https://help.launchpad.net/ListHelp\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130813/d2ba5be2/attachment.html>\n\n','<520A2A08.1030809@ctrlaltdel.ch>',NULL),('<-59666615756638005@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-22 21:46:56',39600,'2013-12-22 10:46:56',NULL,'[Openstack] Bringing focus to the Operators and Users at the\n	next summit','All great reasons why the best and really the only place for this is to\nopen the next summit.\n\n\nOn 22 Dec 2013, at 6:34 pm, Matt Van Winkle <mvanwink at rackspace.com> wrote:\n\n I\'m torn.  I get the benefit of trying to do this at another event when a\nlot of folks will be there anyway, but at the same time, I think there are\nsome pretty significant discussions we need to have, as operators, if we\nwant to push Openstack to be what it can be.  If that\'s the case, I don?t\'\nknow that trying to fit a few talks, sessions or other short visits inside\nanother event is going to do it justice.\n\n From the pain of large deploys, to the inability to run some services in a\nredundant fashion to the lack of maintaining state when services restart,\nthere are a lot of areas we, as users, can give feedback to the TC and the\ndevelopers that will help make this product a viable competitor to other\ncloud offerings (like EC2) out there.  It\'s not there right now, at least\nat scale, and I think it\'s up to us to change the trend of\ndevelopment/thought from that of building a cool private cloud technology\nto scaling the product to 10\'s of thousands, 100\'s of thousands or millions\nof nodes.  A lot needs to be done to make that happen.\n\n Anyway, I think to accurately hash out the things we like to see for all\nthis, we should find a time that we can get together for a couple days and\ndiscuss it all in detail without trying to stay focused on material from\nanother conference.  That\'s my $.02 at least.  I\'ll gladly do what ever,\nbut wanted to challenge this current thread about attaching this effort to\nanother event a little.\n\n Thanks a ton!\nMatt\n\n  From: Sriram Subramanian <sriram at sriramhere.com>\nDate: Saturday, December 21, 2013 4:17 PM\nTo: Clint Byrum <clint at fewbar.com>\nCc: openstack <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Bringing focus to the Operators and Users at the\nnext summit\n\n  OSCON <http://www.oscon.com/oscon2014>2014 is AFTER next OpenStack Summit\n- July 20 - 24, 2014.\n\n SCALE <http://learningatscale.acm.org/> is probably doable, with WIP\nproposals are due only on Jan 2nd.\n\n -Sriram\n\n\nOn Sat, Dec 21, 2013 at 12:53 PM, Clint Byrum <clint at fewbar.com> wrote:\n\n> Excerpts from Matthew Ray\'s message of 2013-12-20 20:22:20 -0800:\n> > Perhaps we could try to co-locate a future Operators mini-summit with\n> > FOSDEM or SCALE (February) and/or OSCON (July)? Events like those are\n> > conveniently scheduled between November and April and likely to already\n> > have OpenStack-related developers/deployers planning on attending. The\n> > logistics might not work for February, but we should start planning for\n> the\n> > future.\n> >\n>\n>  OSCON is an ideal venue for this. Certainly we should approach the\n> organizers immediately as I\'m sure plans are already solidifying.\n>\n> For SCALE I think we may be too late, as the CFP has closed and it is\n> just 2 months away.\n>\n> We\'re all busy, is there anybody who can step up and drive this?\n>\n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n\n --\nThanks,\n-Sriram\n  _______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131222/3dafb94a/attachment.html>\n\n','<CEDBEAE8.6C3DC%mvanwink@rackspace.com>',NULL),('<-6193169907932933435@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 14:25:43',-21600,'2013-03-06 20:25:43',NULL,'[openstack-dev] [Nova] nova-core cleanup','Feature freezes can change a lot of things. People may have been busy\ngetting in last minute patches or testing instead of doing reviews\nthat weren\'t going to make the cut. It\'s just not the most accurate\ntime to generate stats that will be used to propose removing people\nfrom core, IMHO.\n\nOn Mar 6, 2013, at 2:14 PM, Russell Bryant <rbryant at redhat.com> wrote:\n\n> On 03/06/2013 02:59 PM, Josh Kearney wrote:\n>> Do these stats include python-novaclient reviews?\n>\n> No, good point.  novaclient stats included below.\n>\n>> It might be better to use 60 days in this case because of the feature\n>> freeze.\n>\n> What does the feature freeze change?\n>\n>\n> Reviews for the last 30 days in python-novaclient\n> ** -- nova-core team member\n> +---------------------+---------+\n> |       Reviewer      | Reviews |\n> +---------------------+---------+\n> |      klmitch **     |    66   |\n> |        jk0 **       |    32   |\n> |     sdague-b **     |    19   |\n> |       jogo **       |    10   |\n> |    vishvananda **   |    6    |\n> |      aababilov      |    6    |\n> |     russellb **     |    5    |\n> |       treinish      |    4    |\n> | johannes.erdfelt ** |    4    |\n> |      philip-day     |    2    |\n> |      devananda      |    2    |\n> |        zulcss       |    1    |\n> |      yehia-beyh     |    1    |\n> |       sorrison      |    1    |\n> |   kravchenko-pavel  |    1    |\n> |       jdurgin       |    1    |\n> |       harlowja      |    1    |\n> |       flaper87      |    1    |\n> |      dscannell      |    1    |\n> |       dripton       |    1    |\n> |     cerberus **     |    1    |\n> |       berrange      |    1    |\n> +---------------------+---------+\n>\n> Total reviews: 167\n>\n>\n> --\n> Russell Bryant\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5137A388.2050102@redhat.com>',NULL),('<-6809432086743984044@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-28 08:42:42',39600,'2013-12-27 21:42:42',NULL,'[Openstack] Bringing focus to the Operators and Users at the\n	next summit','Yep, sounds like a plan. Thanks Tim.\n\nSent from phone.\n\nOn 28 Dec 2013, at 4:17 am, Tim Bell <Tim.Bell at cern.ch> wrote:\n\n\n\nPersonally, I?d like to see two user feedback sessions:\n\n\n\n1.       Before the summit (around end Feb/start March) for the\noperators/users to work through the mechanisms for feedback, prepare the\ninitial set of input for the Juno cycle and agree on the structure for the\nsummit day.  Clearly, this should not be considered as getting input from\nthe entire user/operator community but I suspect a sample would cover many\nof the areas where we all would need improvements. The ambassadors could\nhelp as part of gathering the input and ensure the appropriate quality and\nconsolidation. Offline input should also be possible for those who could\nnot attend.\n\n2.       We arrange a session for user feedback at the summit. Potentially,\nthere may be an opportunity to use some of the summit facilities in Atlanta\non the Sunday which I am exploring with the foundation staff. Getting the\nfuture iterative feedback channels agreed would be key for this session.\nHow can the developers ask the users/operators how important feature X is\n(since it is suggested for depreciation) ? What would be the impact if the\nfunction for X is spun off to another new project or kept within its\nexisting one ?\n\n\n\nDocumentation showed a significant improvement since the last user survey\nwhich reflects the efforts that Anne, Tom and others put in along with the\nvery user friendly methods put in place where anyone can click on a link to\nreport a problem (as opposed to creating a blueprint for the correct\ncomponent with a solution described).\n\n\n\nTim\n\n\n\n*From:* Tristan Goode [mailto:tristan at aptira.com <tristan at aptira.com>]\n*Sent:* 27 December 2013 17:05\n*To:* openstack at lists.openstack.org\n*Subject:* Re: [Openstack] Bringing focus to the Operators and Users at the\nnext summit\n\n\n\nI\'m not at all discounting the DevOps conversation as ideally a continuous\ncyclic dialog. There may well be wonderful continuous communication in Dev\nland for OpenStack right now, but in Ops land it\'s certainly not middle or\nstart or end or anywhere, it\'s almost non-existent. This breakdown in the\nDevOps cycle is evident in the fact that the feedback from the \"OpenStack\nUser Survey\" presented at the most recent summit was essentially unchanged\nfrom the feedback of the previous summit and echoed much of the same\nsentiment, so it\'s clear developers are not completing the DevOps cycle\nhere even when this information was presented in advance last time. The\nattitude seems to be largely that if you have an issue then rather than\n\"complaining about it\" you should write more code to fix the issue i.e. ops\nshould become dev so dev can remain doing what they like.\n\n\n\nI\'m trying to get user feedback solidly and right up front into the summit\nbecause that\'s the only practical place to do it, for exactly the same\nreason the design sessions are done at the summit. I\'m not saying it\'s the\nstart, middle or end of the user feedback cycle, it\'s just a part but it\'s\nas important part as the design session is to the development process. Not\nonly does trying to push this out to some other time and venue send a\nmessage to customers who might want to participate, the sure to be less\nattendance would dilute the input of Ops into the DevOps cycle and\nprejudice those of us that can\'t afford to send people to more events than\nthe summits.\n\n\n\nCheers\n\nTristan\n\n\n\n\n\n\n\n*From:* jagman4000 at gmail.com [mailto:jagman4000 at gmail.com] *On Behalf Of *Joe\nGordon\n*Sent:* Saturday, 28 December 2013 12:37 AM\n*To:* Tristan Goode\n*Cc:* Mark Collier; openstack at lists.openstack.org\n*Subject:* Re: [Openstack] Bringing focus to the Operators and Users at the\nnext summit\n\n\n\n\nOn Dec 27, 2013 4:24 AM, \"Tristan Goode\" <tristan at aptira.com> wrote:\n>\n> I\'m having trouble seeing these great points of insight here other than\nit seems to indicate that the design summit format could be improved.\nDistilling this down to \"We developers are all too busy at the summit, why\ndon?t you users go get your own thing\" suggests that perhaps it\'s time for\na review of the summit format.\n>\n\nI think that\'s missing a key point, there is much more to this then\nevaluating the summit format. The summit is the middle of a long\ndevelopment dialog not the beginning or the end. Getting more operator\nfeedback to the developers shouldn\'t just happen at the summits, it should\nbe a continuous process just like openstack planning and development. So we\nneed some way for operators and developers to have a continuous dialog.\nDevelopers communicate today on: IRC, email and launchpad and lastly in\nperson twice a year at the design summit.\n\n>\n>\n> After all it does say \"users\" and \"developers\" on the summit logo.\n>\n>\n>\n>\n>\n>\n>\n> From: Mark Collier [mailto:mark at collierclan.net]\n> Sent: Tuesday, 24 December 2013 12:30 AM\n> To: Sean Dague\n>\n> Cc: openstack at lists.openstack.org\n> Subject: Re: [Openstack] Bringing focus to the Operators and Users at the\nnext summit\n>\n>\n>\n> Thanks Sean. You and Thierry have made great points on this thread that I\nthink give people more insight into the process and timing required to\nreally impact the releases.\n>\n> I\'ve fallen into the trap many times of thinking we can solve any problem\nin the world during the 10 days a year we are all together, but in the end\nits only 10 days. No matter how you organize them, they don\'t any get\nlonger.\n>\n> So +1 for some activities well before the summit to gather input. I think\nTim\'s suggestion makes a ton of sense.\n>\n> IMHO we should also avoid the trap of thinking that for gatherings to be\nvaluable \"everyone has to be there\". That\'s what leads back to thinking the\nsummit weeks are the answer to everything. As Tim said, it\'s quite likely\noperators are experiencing a lot of the same pain points, so what is needed\nis critical mass and action, not every known user in one room\n(unrealistic). Perhaps with some online components where operators that\ncouldn\'t make a meetup can weigh in (and give a weighted priority to a\nlist?)\n>\n> On Dec 23, 2013 6:35 AM, \"Sean Dague\" <sean at dague.net> wrote:\n>>\n>> On 12/22/2013 12:49 PM, Rob_Hirschfeld at Dell.com wrote:\n>> > I?d like to repeat a suggestion at the Design Summit wrap up ? it?s a\n>> > bit different, so patience?\n>> >\n>> >\n>> >\n>> > My suggestion was to insert a day ?break? into the four day Design\n>> > Summit for users/operations.  Effectively, we?d have a four day design\n>> > summit with Monday+Tuesday  - break for user/ops conf ?\n>> > Thursday+Friday.  This would allow the developers and PTLs to join in\n>> > the conference parts of the summit without needed a distinct event.\n>> > The regular non-design conference could be held Tuesday-Thursday so\n>> > there?s a specific overlap day when 100% of the community would be\ntogether.\n>> >\n>> >\n>> >\n>> > I felt like this allows ideas from the summit to be socialized with\n>> > users/operator before we commit to them.  I also felt that it makes the\n>> > developers more accessible.  Finally, it creates a break/reflection\nfrom\n>> > the intensity of the design.\n>> >\n>> >\n>> >\n>> > To recap, 4 day design, 3 day user/ops conference spanning 5 days.\n>>\n>> Honestly I\'d be pretty -1 on that idea. There is a certain momentum that\n>> builds inside the design summit sessions that 2 hard context switches\n>> like that would really hurt. If you\'ve ever spent time in the Nova track\n>> you can see this in spades.\n>>\n>> I think one of the missing things for folks that don\'t spend all their\n>> time in Design Summit is realizing that DS is really the *middle* of the\n>> conversation, not that start of one. I actually think this is where\n>> folks new to design summit tend to flail a little be in their sessions.\n>> My goals for design summit, and my tracks, were set weeks in advance,\n>> and there was very little new here, it was mostly about working through\n>> the sticky details on things we largely were already working on, and\n>> exposing some of that work to a wider audience which drags in new\n>> volunteers. So the User / Ops day at Summit is far too late to impact\n>> that release cycle.\n>>\n>> That interaction needs to come 3+ weeks before Design Summit to be\n>> effective on that cycle. Because if it\'s later than that, it\'s just too\n>> much to digest at a point where the plates are already overflowing. The\n>> key developers are already about 200% booked at Summits at this point,\n>> which is actually why *more* OpenStack PTLs spoke at LinuxCon NA this\n>> year than at OpenStack Summit HK. For instance, I only wandered out side\n>> of Design Summit twice, when I was on stage. And I didn\'t even get a\n>> chance to go to any of the public parties, as I was booked every single\n>> night at summit - weeks in advance.\n>>\n>> So I think that all those folks are pretty open to getting more engaged\n>> with Users / Ops (I know I am), but the existing Summit structure isn\'t\n>> going to allow that. Making people 250% booked at Summit isn\'t going to\n>> really be a successful way to handle this.\n>>\n>> I\'m far more positive on something mid cycle, preferably at other\n>> conferences that we expected there to be OpenStack folks at to begin\nwith.\n>>\n>>         -Sean\n>>\n>> --\n>> Sean Dague\n>> Samsung Research America\n>> sean at dague.net / sean.dague at samsung.com\n>> http://dague.net\n>>\n>>\n>> _______________________________________________\n>> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe :\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n> _______________________________________________\n> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131228/cbebf91a/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D98E0EAA@CERNXCHG02.cern.ch>',NULL),('<-7356752996624725387@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 08:47:15',-28800,'2014-02-15 16:47:15',NULL,'[openstack-dev] VPC Proposal','EIP will be allocated from public pools. So in effect public pools and\nshared networks are only DC admin functions. Not available to VPC\nusers.\nThere is a implicit external gateway. When one creates NAT instance or\nVPN instance, external interfaces of these interfaces come from the\nshared network which can be configured by the DC admin.\n\n\nRegards\n-Harshad\n\n\n> On Feb 14, 2014, at 10:07 PM, \"Martin, JC\" <jch.martin at gmail.com> wrote:\n>\n> Harshad,\n>\n> I\'m not sure to understand what you mean by :\n>> However many of these concepts are not exposed to a AWS customers and\n>> the API work well.\n>\n> So for example in :\n>\n> http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html#VPC_EIP_EC2_Differences\n>\n> When it says :\n> \"When you allocate an EIP, it\'s for use only in a VPC.\"\n>\n> Are you saying that the behavior of your API would be consistent without scoping the external networks to a VPC and using the public pool instead ?\n>\n> I believe that your api may work for basic features on a small deployments with only one VPC, but as soon as you have complex setups with external gateways that need to be isolated, I\'m not sure that it will provide parity anyway with what EC2 provides.\n>\n>\n> Maybe I missed something.\n>\n>\n> JC\n>\n>> On Feb 14, 2014, at 7:35 PM, Harshad Nakil <hnakil at contrailsystems.com> wrote:\n>>\n>> Hi JC,\n>>\n>> You have put it aptly. Goal of the blueprint is to present facade for\n>> AWS VPC API as the name suggest.\n>> As per your definition of VPC, shared network will have issues.\n>> However many of these concepts are not exposed to a AWS customers and\n>> the API work well.\n>> While we work incrementally towards your definition of VPC we can\n>> maintain API compatibility to AWS API that we are proposing. As we are\n>> subset of your proposal and don\'t expose all features within VPC.\n>>\n>> Regards\n>> -Harshad\n>>\n>>\n>>> On Feb 14, 2014, at 6:22 PM, \"Martin, JC\" <jch.martin at gmail.com> wrote:\n>>>\n>>> Rudra,\n>>>\n>>> I do not agree that the current proposal provides the semantic of a VPC. If the goal is to only provide a facade through the EC2 API, it may address this, but unless you implement the basic features of a VPC, what good is it doing ?\n>>>\n>>> I do believe that the work can be done incrementally if we agree on the basic properties of a VPC, for example :\n>>> - allowing projects to be created while using resources defined at the VPC level\n>>> - preventing resources not explicitly defined at the VPC level to be used by a VPC.\n>>>\n>>> I do not see in the current proposal how resources are scoped to a VPC, and how, for example, you prevent shared network to be used within a VPC, or how you can define shared networks (or other shared resources) to only be scoped to a VPC.\n>>>\n>>> I think we already raised our concern to you several months ago, but it did not seem to have been addressed in the current proposal.\n>>>\n>>> thanks,\n>>>\n>>> JC\n>>>\n>>>> On Feb 14, 2014, at 3:50 PM, Rudra Rugge <rrugge at juniper.net> wrote:\n>>>>\n>>>> Hi JC,\n>>>>\n>>>> We agree with your proposed model of a VPC resource object. Proposal you are making makes sense to us and we would like to collaborate further on this. After reading your blueprint two things come to mind.\n>>>>\n>>>> 1. VPC vision for Openstack? (Your blueprint is proposing this vision)\n>>>> 2. Providing AWS VPC api compatibility with current constrains of openstack structure.\n>>>>\n>>>> The blueprint that we proposed targets #2.\n>>>> It gives a way to implement \"AWS VPC api\" compatible API. This helps subset of customers to migrate their workloads from AWS to openstack based clouds. In our implementation we tied VPC to project. That was easiest way to keep isolation with current structure. We agree that what you are proposing is more generic. One to way is to implement our current proposal to have one VPC to one project mapping. As your blueprint matures we will\n>>>> move VPC to multiple project mapping.\n>>>>\n>>>> We feel that instead of throwing away all the work done we can take an incremental approach.\n>>>>\n>>>> Regards,\n>>>> Rudra\n>>>>\n>>>>\n>>>>> On Feb 14, 2014, at 11:09 AM, Martin, JC <jch.martin at gmail.com> wrote:\n>>>>>\n>>>>>\n>>>>> There is a Blueprint targeted for Icehouse-3 that is aiming to implement the AWS VPC api. I don\'t think that this blueprint is providing the necessary constructs to really implement a VPC, and it is not taking into account the domains, or proposed multi tenant hierarchy. In addition, I could not find a discussion about this topic leading to the approval.\n>>>>>\n>>>>> For this reason, I wrote an \'umbrella\' blueprint to hopefully start the discussion on how to really implement VPC, and eventually split it into multiple real blueprints for each area.\n>>>>>\n>>>>> Please, provide feedback on the following document, and on the best way to move this forward.\n>>>>>\n>>>>> https://wiki.openstack.org/wiki/Blueprint-VPC\n>>>>>\n>>>>> Thanks,\n>>>>>\n>>>>> JC.\n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>\n>>>>\n>>>>\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<AB715718-1B8F-4A82-BD3A-B35BEE1893DB@gmail.com>',NULL),('<-7535770447175714944@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-25 08:32:04',-25200,'2013-10-25 15:32:04',NULL,'[openstack-dev] [Neutron] FWaaS IceHouse summit prep and IRC\n	meeting','Bump in wire service can be within network (intra network) as you suggest\nOR between network ( inter network ).\nAdvantage of bump in wire is one does not need networking config inside the\nservice.\nInter network bump in wire service is analogous to having service inserted\non link between  two routers without the routers knowing about it.\n\nRegards\n-Harshad\n\n\nOn Oct 24, 2013, at 10:22 PM, Sumit Naiksatam <sumitnaiksatam at gmail.com>\nwrote:\n\nThe bump-in-the-wire mode we were referring to here is the one where the\nfirewall has both legs on the same subnet/network. The point that was\ntrying to be made was that applying zones in that case would not make as\nmuch sense. At this point there is no proposal though to validate and\nrestrict this particular case, or for that matter any combination of ports\nfor the zone. If anyone has suggestions on what criteria to use to restrict\nthe port membership for zones, we can definitely discuss it, but there is\nnone on the table at the moment.\n\nThanks,\n~Sumit.\n\n\nOn Thu, Oct 24, 2013 at 2:48 PM, Rajesh Mohan <rajesh.mlists at gmail.com>wrote:\n\n> This is good discussion.\n>\n> +1 for using Neutron ports for defining zones. I see Kaiwei\'s point but\n> for DELL, neutron ports makes more sense.\n>\n> I am not sure if I completely understood the bump-in-the-wire/zone\n> discussion. DELL security appliance allows using different zones with\n> bump-in-the-wire. If the firewall is inserted in bump-in-the-wire mode\n> between router and LAN hosts, then it does makes sense to apply different\n> zones on ports connected to LAN and Router. The there are cases where the\n> end-users apply same zones on both sides but this is a decision we should\n> leave to end customers. We should allow configuring zones in\n> bump-in-the-wire mode as well.\n>\n>\n>\n>\n>\n> On Wed, Oct 23, 2013 at 12:08 PM, Sumit Naiksatam <\n> sumitnaiksatam at gmail.com> wrote:\n>\n>> Log from today\'s meeting:\n>>\n>>\n>> http://eavesdrop.openstack.org/meetings/networking_fwaas/2013/networking_fwaas.2013-10-23-18.02.log.html\n>>\n>> Action items for some of the folks included.\n>>\n>> Please join us for the meeting next week.\n>>\n>> Thanks,\n>> ~Sumit.\n>>\n>> On Tue, Oct 22, 2013 at 2:00 PM, Sumit Naiksatam <\n>> sumitnaiksatam at gmail.com> wrote:\n>>\n>>> Reminder - we will have the Neutron FWaaS IRC meeting tomorrow Wednesday\n>>> 18:00 UTC (11 AM PDT).\n>>>\n>>> Agenda:\n>>> * Tempest tests\n>>> * Definition and use of zones\n>>> * Address Objects\n>>> * Counts API\n>>> * Service Objects\n>>> * Integration with service type framework\n>>> * Open discussion - any other topics you would like to bring up for\n>>> discussion during the summit.\n>>>\n>>> https://wiki.openstack.org/wiki/Meetings/FWaaS\n>>>\n>>> Thanks,\n>>> ~Sumit.\n>>>\n>>>\n>>> On Sun, Oct 13, 2013 at 1:56 PM, Sumit Naiksatam <\n>>> sumitnaiksatam at gmail.com> wrote:\n>>>\n>>>> Hi All,\n>>>>\n>>>> For the next of phase of FWaaS development we will be considering a\n>>>> number of features. I am proposing an IRC meeting on Oct 16th Wednesday\n>>>> 18:00 UTC (11 AM PDT) to discuss this.\n>>>>\n>>>> The etherpad for the summit session proposal is here:\n>>>> https://etherpad.openstack.org/p/icehouse-neutron-fwaas\n>>>>\n>>>> and has a high level list of features under consideration.\n>>>>\n>>>> Thanks,\n>>>> ~Sumit.\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131025/672a313d/attachment.html>\n\n','<CAMWrLvhtq9n5Nrj3VF5qimk4qNaZ2QfAj3Ak-ke7ntE8LwpLog@mail.gmail.com>',NULL),('<-7676677135411579549@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-03-18 18:22:13',-14400,'2013-03-18 22:22:13',NULL,'[Openstack-operators] Scalable Glance Nodes','Your best bet is using a distributed fs for glance, you could use swift or\nceph or anything else really.\n\nSent from my iPad\n\nOn Mar 18, 2013, at 6:16 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:\n\nHi,\n\nHow can I have multiple glance nodes in a way that, when I create an image\nfrom the controler, it would be coppied to all of the glance nodes?\nNow, when I define multiple glance endpoints in the controler (keystone),\nthe images would only go to the first glance node.\n\nI also want to avoid putting the name of all glance nodes in the nova nodes.\n\nThank you,\nAd\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130318/fd915991/attachment.html>\n\n','<1363644750.78541.YahooMailNeo@web120406.mail.ne1.yahoo.com>',NULL),('<-8030404583364417540@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-12 07:38:44',-28800,'2014-01-12 15:38:44',NULL,'[Openstack] [Keystone] performance issues after havana upgrade','Thanks for confirming this!  It also validates my new logic going into\nicehouse (I might have had some ulterior motives here, or not so\nulterior as the case may be).  I\'ll make sure we resolve the test\nissues (unrelated to the patch) and get it into the Havana tree so you\ndon\'t need to maintain it outside of the releases.\n\nCheers,\nMorgan\n\nSent from my tablet-like-device\n\n> On Jan 11, 2014, at 11:01 PM, Jonathan Proulx <jon at jonproulx.com> wrote:\n>\n>> On Sat, Jan 11, 2014 at 10:57 PM, Morgan Fainberg <m at metacloud.com> wrote:\n>> Sounds good!  Just remember that prior to the fix I posted there, for each\n>> token in the user?s index, it incurred a round-trip to memcached to validate\n>> the token wasn?t expired.  This change makes it so that there are\n>> significantly less trips from keystone to memcached.\n>>\n>> If this doesn?t 100% solve the issue, we should start digging further into\n>> what is going on, but I am confident this will (at the very least) help a\n>> reasonable amount.\n>\n> You sir are a miracle worker, my hat is off!\n>\n> The responsiveness of everything is better than it\'s ever been, my\n> users will think this is the best feature the upgrade.\n>\n> For example earlier today I managed to launch 10 VMs in parallel,\n> eventually, I\'d guess on the order of 5-10min.  One of my usual\n> acceptance tests is being able to launch 100 VMs in that time.  Just\n> now Iaunched 100 in <2min from request until they\'d all been\n> provisioned and were booting.  Now there\'s too many moving pieces and\n> too few experimental samples to make any publishable claims, but your\n> patch is the only thing that changed.\n>\n> Thanks,\n> -Jon\n\n\n','<CABZB-sgeDYuwKdxYifPvxHfP+Vw3jmuG4pbBk05ahPYtXC74Yg@mail.gmail.com>',NULL),('<-8185424088913149744@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 20:02:45',-28800,'2013-11-13 04:02:45',NULL,'[openstack-dev] [nova] Blueprint for Juniper OpenContrail\n vrouter nova vif driver support','Kyle,\nThese requirement should also be required for existing third plugins.\nWill you allow new patches to existing plugins without this requirement?\nI hope we don\'t end up creating multiple classes of citizens.\n\nRegards\n-Harshad\n\n\n> On Nov 12, 2013, at 7:08 PM, \"Kyle Mestery (kmestery)\" <kmestery at cisco.com> wrote:\n>\n>> On Nov 12, 2013, at 5:26 PM, Prasad Miriyala <pmiriyala at juniper.net> wrote:\n>>\n>> Hi All,\n>>\n>> A blueprint has been registered to add Nova vif driver support for Juniper vrouter.\n>>\n>> The Juniper OpenContrail Controller is a logically centralized but physically distributed Software Defined Networking (SDN) controller that is responsible for providing the management, control, and analytics functions of the virtualized network.\n>> The Juniper OpenContrail vRouter is a forwarding plane (of a distributed router) that runs in the hypervisor of a virtualized server. It extends the network from the physical routers and switches in a data center into a virtual overlay network hosted in the virtualized servers. The OpenContrail vRouter is conceptually similar to existing commercial and open source vSwitches such as for example the Open vSwitch (OVS) but it also provides routing and higher layer services.\n>> The OpenContrail Controller provides the logically centralized control plane and management plane of the system and orchestrates the vRouters.\n>>\n>> Blueprint\n>> https://blueprints.launchpad.net/nova/+spec/juniper-opencontrail-vrouter-nova-vif-driver\n>>\n>> Associated contrail neutron plugin blueprint\n>> https://blueprints.launchpad.net/neutron/+spec/juniper-plugin-with-extensions\n>>\n>> Please review blueprint, all comments are welcome.\n>>\n>> Regards,\n>> Prasad\n>\n> Hi Prasad:\n>\n> We have seen the BP and review. The problem that we Neutron core are currently\n> looking at is something which was discussed at the Summit in Hong Kong last week:\n> The requirement of having Smokestack/Tempest tests for plugins. As a core team, we\n> haven\'t decided yet if new plugins will require these tests before being added to the\n> tree. All plugins will require these tests by Icehouse-2, so IMHO requiring new plugins\n> to have them before they are submitted makes sense. I suspect we will cover this next\n> week at the weekly Neutron IRC meeting, so stay tuned.\n>\n> Thanks,\n> Kyle\n>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<3AFA4E0B-DCFD-4C3D-A63D-3CF77E24AEE6@cisco.com>',NULL),('<-8439416947758235504@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-16 09:15:30',-28800,'2013-11-16 17:15:30',NULL,'[openstack-dev] Openstack + OpenContrail','Sean,\nWe have diff in three repositories.\nNova, Neutron and devstack. Each review is requiring other to happen first.\nDo you have recommendation how do we deal with these dependencies?\n\nRegards\n-Harshad\n\n\n> On Nov 16, 2013, at 9:11 AM, Sean Dague <sean at dague.net> wrote:\n>\n> For something to go in devstack, it has to be included in the base server project. So first step is to work on getting your code upstream into the relevant upstream.\n>\n> We don\'t preintegrate into devstack, because it\'s job is not to be a general installer, it\'s to be an opinionated development setup tool for the existing integrated projects, making it easier for people to develop and work with the whole stack.\n>\n>    -Sean\n>\n>> On 11/15/2013 07:35 PM, Deepinder Singh Setia wrote:\n>> I would like to add that the work in forked devstack is ongoing and not\n>> complete. I am trying to understand what would it take to push these\n>> changes upstream such as coding requirements, testing, code\n>> organization, documentation  etc.\n>>\n>> Thanks\n>> Deepinder\n>>\n>> From: Deepinder Setia <dsetia at juniper.net <mailto:dsetia at juniper.net>>\n>> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\"\n>> <openstack-dev at lists.openstack.org\n>> <mailto:openstack-dev at lists.openstack.org>>\n>> Date: Friday, November 15, 2013 4:25 PM\n>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>> <openstack-dev at lists.openstack.org\n>> <mailto:openstack-dev at lists.openstack.org>>\n>> Subject: [openstack-dev] Openstack + OpenContrail\n>>\n>> I forked devstack a few weeks ago to integrate with OpenContrail at\n>> https://github.com/dsetia/devstack.  This installs and launches\n>> OpenContrail in addition to openstack components.  OpenContrail provides\n>> network virtualization components -  SDN controller, Virtual Router and\n>> analytics  - via neutron and nova plugins along with other modules built\n>> and launched when stack.sh is run. Please see\n>>\n>>  * https://github.com/dsetia/devstack/blob/master/contrail/README -\n>>  * http://pedrormarques.wordpress.com/2013/11/14/using-devstack-plus-opencontrail/\n>>\n>>  * http://opencontrail.org/\n>>\n>> Bulk of the work is done by new file lib/neutron_thirdparty/contrail\n>> such as cloning open contrail repo, building and launching contrail\n>> modules. I also have directory called contrail under devstack which\n>> includes:\n>>\n>> 1. sample localrc files for setting up single or multi node openstack +\n>>    open contrail system\n>> 2. Support files and scripts needed by  lib/neutron_thirdparty/contrail\n>>    functions\n>> 3. Neutron and Nova patches needed by OpenStack. These plugins have\n>>    been submitted for review. Once approved, I will get rid of code to\n>>    patch them\n>>\n>> I would like to understand the procedure, requirements and logistics  to\n>> push these changes upstream to devstack repository.\n>>\n>> Thanks\n>> Deepinder\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> --\n> Sean Dague\n> http://dague.net\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5287A6BF.3030200@dague.net>',NULL),('<-8687327671741849454@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 18:28:13',-25200,'2014-08-19 01:28:13',NULL,'[openstack-dev] [Neutron][L3] HA Router Review Help','> On Aug 18, 2014, at 3:41 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:\n>\n> Hi all,\n>\n> This is intended for those readers interested in reviewing and soon\n> merging the HA routers implementation for Juno.  Assaf Muller has\n> written a blog [1] about this new feature which serves as a good\n> overview.  It will be useful for reviewers to get up to speed and I\n> recommend reading it before getting started.  He and I have\n> collaborated to create sort of a map [2] which lists the relevant\n> reviews.  The map groups the patches by project and area of focus.\n> Under each heading, it shows the order in which the patches should be\n> reviewed.\n>\n> I hope that this information will help to ease that overwhelming\n> feeling you might have when faced with the list of patches under this\n> topic.\n>\nThanks for putting this together Carl. L3 HA is one of the critical\nBPs for Juno, I\'m very happy to see you collaborating with Assaf to\nget this reviewed and merged!\n\nKyle\n\n> Carl\n>\n> [1] http://assafmuller.wordpress.com/2014/08/16/layer-3-high-availability/\n> [2] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Blueprint:_l3-high-availability_.28safchain.2C_amuller.29\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CALiLy7rgz947bHMxjuaDmFq9vrjZewqnyEb=TQ-t81OnzbfeAQ@mail.gmail.com>',NULL),('<-8861205214381225745@unknownmsgid>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-05-09 17:38:59',-14400,'2013-05-09 21:38:59',NULL,'[Openstack-operators] Adding a Physical Network Interface to an\n	Instance','What did your nova boot command look like? I believe you\'ll need to pass\ntwo --nic args when you call it.\n\nSent from my iPhone\n\nOn May 9, 2013, at 5:17 PM, Steven Barnabas <sbarnabas at frontporch.com>\nwrote:\n\nok I did this:\n*nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1\n--network_size=256 --vlan=1 --label=IN-Interface --project=admin\n--bridge=br-eth4 --bridge_interface=eth4*\n\nAnd it worked!\n\nthis was the output:\n2013-05-09 14:09:14 DEBUG nova.utils\n[req-55460cdf-fe87-4f86-9ffb-237dd8024ea9 None None] backend <module\n\'nova.db.sqlalchemy.api\' from\n\'/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc\'>\n__get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:506\n\nBut?.It did not add a secondary Interface when I launched my VNC console to\nthe instance through the gui.  It actually replaced the first network with\nthe second network.  Not adding the second interface.\n\nShould I try launching it a different way?\n\n\nThanks.\n\n\nSteven Barnabas\nNetwork Engineer\nFront Porch, Inc.\n209-288-5580\n209-652-7733 mobile\nwww.frontporch.com\n\n\n\nOn May 7, 2013, at 7:18 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:\n\nHi Steven,\n\nHave you tried the --bridge_interface option?\n\n\"nova-manage network create -h\" shows both --bridge and --bridge_interface\nas options.\n\nThanks,\nJoe\n\n\nOn Mon, May 6, 2013 at 5:36 PM, Steven Barnabas <sbarnabas at frontporch.com>wrote:\n\n> Ok I changed my /etc/network/interfaces eth-4 interface to manual\n>\n> when I do a *brctl show* this is the output:\n> root at FPCompute:~# brctl show\n> bridge name bridge id STP enabled interfaces\n> br-eth0 0000.00151715ac78 no eth0\n> phy-br-eth0\n> br-eth4 0000.00188b4c7e7a no eth4\n> br-int 0000.d6e482502444 no int-br-eth0\n> qbr4ba9f712-ec 8000.7abe7483f8e4 no qvb4ba9f712-ec\n>\n> So the bridge is already there and the interface is mapped to it from what\n> it looks like.\n>\n> When I do this:\n> *nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1\n> --network_size=256 --vlan=1 --label=IN-Interface --project=admin\n> --bridge=br-eth4*\n> I still get the:\n> Command failed, please check log for more info\n> 2013-05-06 16:18:07 CRITICAL nova\n> [req-9d8bbe89-282c-4490-a3b1-643faeccc849 None None] bridge_interface is\n> required to create a network.\n> 2013-05-06 16:18:07 22953 TRACE nova Traceback (most recent call last):\n> 2013-05-06 16:18:07 22953 TRACE nova   File \"/usr/bin/nova-manage\", line\n> 1404, in <module>\n> 2013-05-06 16:18:07 22953 TRACE nova     main()\n> 2013-05-06 16:18:07 22953 TRACE nova   File \"/usr/bin/nova-manage\", line\n> 1391, in main\n> 2013-05-06 16:18:07 22953 TRACE nova     fn(*fn_args, **fn_kwargs)\n> 2013-05-06 16:18:07 22953 TRACE nova   File \"/usr/bin/nova-manage\", line\n> 480, in create\n> 2013-05-06 16:18:07 22953 TRACE nova\n> net_manager.create_networks(context.get_admin_context(), **kwargs)\n> 2013-05-06 16:18:07 22953 TRACE nova   File\n> \"/usr/lib/python2.7/dist-packages/nova/network/manager.py\", line 2105, in\n> create_networks\n> 2013-05-06 16:18:07 22953 TRACE nova     self, context, vpn=True, **kwargs)\n> 2013-05-06 16:18:07 22953 TRACE nova   File\n> \"/usr/lib/python2.7/dist-packages/nova/network/manager.py\", line 1461, in\n> create_networks\n> 2013-05-06 16:18:07 22953 TRACE nova     raise\n> exception.NetworkNotCreated(req=fld)\n> 2013-05-06 16:18:07 22953 TRACE nova NetworkNotCreated: bridge_interface\n> is required to create a network.\n> 2013-05-06 16:18:07 22953 TRACE nova\n>\n> I even tried adding br-eth4 to my /etc/network/interfaces and it still did\n> not work.  I removed that now.\n>\n>\n> Steven Barnabas\n> Network Engineer\n> Front Porch, Inc.\n> 209-288-5580\n> 209-652-7733 mobile\n> www.frontporch.com\n>\n>\n>\n> On May 4, 2013, at 7:42 AM, Joe Topjian <joe.topjian at cybera.ca> wrote:\n>\n> *nova-manage network create --fixed_range_v4=1.1.1.0/24 --num_networks=1\n> --network_size=256 --vlan=1 --label=IN-Interface --project=admin\n> --bridge=br-2*\n>\n>\n>\n\n\n-- \nJoe Topjian\nSystems Administrator\nCybera Inc.\n\nwww.cybera.ca\n\nCybera is a not-for-profit organization that works to spur and support\ninnovation, for the economic benefit of Alberta, through the use\nof cyberinfrastructure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130509/09382e2c/attachment.html>\n\n','<5A335047-3572-4B04-B13D-1578930A988F@frontporch.com>',NULL),('<0000014acb481c6c-69f2ab88-1bee-4a8c-9864-bef5e0523f58-000000@email.amazonses.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 20:41:48',0,'2015-01-08 20:41:48',NULL,'[openstack-dev] [stable][neutron] minimal dnsmasq version','On Thu, Jan 08, 2015 at 11:53:24AM EST, Carl Baldwin wrote:\n> On Wed, Jan 7, 2015 at 9:25 PM, Kevin Benton <blak111 at gmail.com> wrote:\n> > If the new requirement is expressed in the neutron packages for the distro,\n> > wouldn\'t it be transparent to the operators?\n> \n> I think the difficulty first lies with the distros.  If the required\n> new version isn\'t in an older version of the distro (e.g. Ubuntu\n> 12.04) it may not be possible to update the new distro packages with\n> the new dependency.\n\n+1 - I know for the Icehouse release when we bumped it to the current\nminimum version we were concerned about 12.04 LTS. I think we settled on\n2.63 since that was what was available in the main release channel,\nor possibly what was being shipped in the cloud-archive repos.\n\n-- \nSean M. Collins\n\n\n','<CALiLy7qc5v7kwAjN6gs8adgADdqThn-fcmEL2HntbA_quy+Qyg@mail.gmail.com>',NULL),('<0000014b03bc77ac-a8e15d30-aa3c-4bff-a929-7e7c8d57977b-000000@email.amazonses.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-19 19:47:38',0,'2015-01-19 19:47:38',NULL,'[openstack-dev] [neutron] Next week\'s meeting is cancelled (and\n some other notes)','Thanks Doug!\n\nIt is a big link but I\'d rather see the full URL than trust opening a\nURL shortener link. I\'ve been rickrolled too many times to count. :)\n\n-- \nSean M. Collins\n\n\n','<D0DECF47.1DA28%dougw@a10networks.com>',NULL),('<0000014b4be66f77-35da147f-3e24-4333-a1bf-208ecc1cc441-000000@email.amazonses.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 20:06:08',0,'2015-02-02 20:06:08',NULL,'[openstack-dev] [Neutron] Multiple template libraries being used in\n tree - Switch to using only Jinja2?','Hi,\n\nDuring my review of the full-stack tests framework[1], I noticed that\nMako was being added as an explicit dependency. I know that in the code\nfor creating radvd configs for IPv6, we use Jinja, but I did a quick\ngit grep and see that we have one file[2] that uses Mako for templating.\n\nMy intention is to replace the one file that uses Mako with Jinja2, to\nkeep things consistent.\n\nThoughts?\n\n[1]: https://review.openstack.org/#/c/128259/\n[2]: http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/migration/alembic_migrations/script.py.mako\n-- \nSean M. Collins\n\n\n',NULL,NULL),('<0000014b4beccf61-f985d1d9-de03-442f-9037-61abe768f3b2-000000@email.amazonses.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 20:13:05',0,'2015-02-02 20:13:05',NULL,'[openstack-dev] [Neutron] Multiple template libraries being\n used in tree','Sorry, I should have done a bit more grepping before I sent the e-mail,\nsince it appears that Mako is being used by alembic.\n\nhttp://alembic.readthedocs.org/en/latest/tutorial.html\n\nSo, should we switch the radvd templating over to Mako instead?\n\n-- \nSean M. Collins\n\n\n','<0000014b4be66f77-35da147f-3e24-4333-a1bf-208ecc1cc441-000000@email.amazonses.com>',NULL),('<000001cdc6cf$f6056110$e2102330$@com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 11:34:35',28800,'2012-11-20 03:34:35',NULL,'[openstack-dev] openstack using glusterfs to store vm instance\n	images get error','The error is \"libvirtError: internal error Process exited while reading\nconsole log output: chardev: opening backend \"file\" failed\"\n\n \n\nI have changed the /etc/libvirt/qemu.conf user & group to root, but still\nget such error.\n\n \n\nAnyone can help ?\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121120/a7f2ab5f/attachment.html>\n\n',NULL,NULL),('<000001cef7ce$72b98e90$582cabb0$@gmail.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2013-12-13 07:42:08',3600,'2013-12-13 06:42:08',NULL,'[User-committee] [openstack-community] Bringing focus to the\n	Operators and Users at the next summit','Yes, this is a very good idea!\n\n \n\nFrom: dheeru [mailto:dheerendra.madhusudhana at gmail.com] \nSent: Friday, December 13, 2013 5:46 AM\nTo: Tristan Goode\nCc: user-committee at lists.openstack.org; community at lists.openstack.org\nSubject: Re: [openstack-community] Bringing focus to the Operators and Users\nat the next summit\n\n \n\n+1. I like this idea. \n\n \n\n-Dheeru\n\n@Community Service\n\n \n\nOn Fri, Dec 13, 2013 at 8:00 AM, Tristan Goode <tristan at aptira.com> wrote:\n\nThought I\'d post this here too (because of the noise in the general list)...\n\n \n\n \n\nG\'day OpenStackLand,\n\n \n\nI have an idea for the next summit to put forward...\n\n \n\nLike we have the various project design summit session days at the summits,\nI think it\'d be really useful to have an Operators and Users day at the very\nstart of the next summit (and hopefully all of them in future if it works\nout). So far at the last 4 summits I\'ve attended, from the users and\noperators point of view we\'ve had a rag tag bunch of disconnected panels and\n40 minute sessions that really don\'t get anywhere much and don\'t make it to\nany sort of plan or worthwhile result. This proposed \"Operators and Users\"\nday will be run like the design summit session days where all of us that\nhave to deal with the consequences of the software development of this\nproject sit in a room and work the issues. The goal is to present real\nworld, evidence based Operator, User, and even other input like Sales and\nMarketing experiences back into the development teams. Maybe we might even\nhave our own \"Operators and Users\" lounge too. :-P\n\n \n\n \n\nCheers\n\nTristan\n\n \n\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\n\n \n\n-- \n\n-dheeru\n\n@Community Service\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20131213/af089580/attachment.html>\n\n','<CAKV+guf_mDX8JZ3EdumXJ0x-oreU4Y8n1uZ6xcBQ_qkV2BUwfQ@mail.gmail.com>',NULL),('<000001cfa9bd$50381700$f0a84500$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-28 01:07:56',28800,'2014-07-27 17:07:56',NULL,'[OpenStack-Infra] Requesting a Service Account for Third Party\n	CI System','Hi Anita:\n	Prophetstor is my company name. I plan to verify our cinder volume\ndriver.\n	BP:\nhttps://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n	Please help us to create service account. Thanks.\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info] \nSent: Saturday, July 26, 2014 9:08 PM\nTo: openstack-infra at lists.openstack.org\nSubject: Re: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nOn 07/25/2014 08:36 PM, Rick Chen wrote:\n> Hi Sir:\n> \n>         Please help us to create service account, Thanks.\n> \n>  \n> \n> 1.      Attached file.\n> \n> 2.      A preferred username: prophetstor\n> \n> 3.      A human-readable: Prophetstor-CI\n> \n> 4.      Email address: prophetstor.ci at prophetstor.com\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \nHi Rick:\n\nWe are changing our documentation around requesting a service account, the\npatch hasn\'t been merged yet:\nhttps://review.openstack.org/#/c/101013/11/doc/source/third_party.rst\n\nSo Prophetstor is the name of your company, what details can you give me\nabout what you intend to be verifying with your third party ci account?\nIt might be a piece of software or hardware or something else.\nThe more details you can offer, the better. If you have a blueprint or spec\nfor it, linking to the blueprint or spec in your reply is really helpful.\n\nThanks Rick,\nAnita.\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n','<53D3A841.5090508@anteaya.info>',NULL),('<000001cfaa71$fd0da530$f728ef90$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-28 22:41:15',28800,'2014-07-28 14:41:15',NULL,'[OpenStack-Infra] Requesting a Service Account for Third Party\n	CI System','HI Anita:\n	Does our service account ready?\n	I need change below information, please help me to correct? Or tell\nme how to change it?\n>> 3.      A human-readable: Prophetstor-CI --> ProphetStor-CI\n\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info] \nSent: Monday, July 28, 2014 3:43 AM\nTo: Rick Chen; openstack-infra at lists.openstack.org\nCc: \'steve tan\'; Albert Lin\nSubject: Re: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nOn 07/27/2014 01:07 PM, Rick Chen wrote:\n> Hi Anita:\n> 	Prophetstor is my company name. I plan to verify our cinder volume \n> driver.\n> 	BP:\n> https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n> 	Please help us to create service account. Thanks.\nGreat, thanks Rick. Linking the blueprint really helps.\n\nWe are working on getting me permissions to create accounts, which is soon\nbut hasn\'t happened yet. In the meantime one of my infra colleagues may get\nthe account created before I do.\n\nThanks,\nAnita.\n> \n> -----Original Message-----\n> From: Anita Kuno [mailto:anteaya at anteaya.info]\n> Sent: Saturday, July 26, 2014 9:08 PM\n> To: openstack-infra at lists.openstack.org\n> Subject: Re: [OpenStack-Infra] Requesting a Service Account for Third \n> Party CI System\n> \n> On 07/25/2014 08:36 PM, Rick Chen wrote:\n>> Hi Sir:\n>>\n>>         Please help us to create service account, Thanks.\n>>\n>>  \n>>\n>> 1.      Attached file.\n>>\n>> 2.      A preferred username: prophetstor\n>>\n>> 3.      A human-readable: Prophetstor-CI\n>>\n>> 4.      Email address: prophetstor.ci at prophetstor.com\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-Infra mailing list\n>> OpenStack-Infra at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>\n> Hi Rick:\n> \n> We are changing our documentation around requesting a service account, \n> the patch hasn\'t been merged yet:\n> https://review.openstack.org/#/c/101013/11/doc/source/third_party.rst\n> \n> So Prophetstor is the name of your company, what details can you give \n> me about what you intend to be verifying with your third party ci account?\n> It might be a piece of software or hardware or something else.\n> The more details you can offer, the better. If you have a blueprint or \n> spec for it, linking to the blueprint or spec in your reply is really\nhelpful.\n> \n> Thanks Rick,\n> Anita.\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n\n\n\n','<53D5565F.9070202@anteaya.info>',NULL),('<000001cfac5e$25abe7c0$7103b740$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-31 09:24:16',28800,'2014-07-31 01:24:16',NULL,'[OpenStack-Infra] Requesting a Service Account for Third Party\n	CI System','HI All:\n	I saw the third-pard CI members still increased, but our account is\nnot accepted. Can you tell me why? Or how to solve this problem? \n\n 1.      Attached file.\n 2.      A preferred username: prophetstor\n 3.      A human-readable: ProphetStor-CI\n 4.      Email address: prophetstor.ci at prophetstor.com\n 5.      For cinder volume driver certificate. BP:\nhttps://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n\n> 	Please help us to create service account. Thanks.\n-----Original Message-----\nFrom: Rick Chen [mailto:rick.chen at prophetstor.com] \nSent: Monday, July 28, 2014 10:41 PM\nTo: \'Anita Kuno\'; \'openstack-infra at lists.openstack.org\'\nCc: \'steve tan\'; \'Albert Lin\'\nSubject: RE: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nHI Anita:\n	Does our service account ready?\n	I need change below information, please help me to correct? Or tell\nme how to change it?\n>> 3.      A human-readable: Prophetstor-CI --> ProphetStor-CI\n\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info]\nSent: Monday, July 28, 2014 3:43 AM\nTo: Rick Chen; openstack-infra at lists.openstack.org\nCc: \'steve tan\'; Albert Lin\nSubject: Re: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nOn 07/27/2014 01:07 PM, Rick Chen wrote:\n> Hi Anita:\n> 	Prophetstor is my company name. I plan to verify our cinder volume \n> driver.\n> 	BP:\n> https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n> 	Please help us to create service account. Thanks.\nGreat, thanks Rick. Linking the blueprint really helps.\n\nWe are working on getting me permissions to create accounts, which is soon\nbut hasn\'t happened yet. In the meantime one of my infra colleagues may get\nthe account created before I do.\n\nThanks,\nAnita.\n> \n> -----Original Message-----\n> From: Anita Kuno [mailto:anteaya at anteaya.info]\n> Sent: Saturday, July 26, 2014 9:08 PM\n> To: openstack-infra at lists.openstack.org\n> Subject: Re: [OpenStack-Infra] Requesting a Service Account for Third \n> Party CI System\n> \n> On 07/25/2014 08:36 PM, Rick Chen wrote:\n>> Hi Sir:\n>>\n>>         Please help us to create service account, Thanks.\n>>\n>>  \n>>\n>> 1.      Attached file.\n>>\n>> 2.      A preferred username: prophetstor\n>>\n>> 3.      A human-readable: Prophetstor-CI\n>>\n>> 4.      Email address: prophetstor.ci at prophetstor.com\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-Infra mailing list\n>> OpenStack-Infra at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>\n> Hi Rick:\n> \n> We are changing our documentation around requesting a service account, \n> the patch hasn\'t been merged yet:\n> https://review.openstack.org/#/c/101013/11/doc/source/third_party.rst\n> \n> So Prophetstor is the name of your company, what details can you give \n> me about what you intend to be verifying with your third party ci account?\n> It might be a piece of software or hardware or something else.\n> The more details you can offer, the better. If you have a blueprint or \n> spec for it, linking to the blueprint or spec in your reply is really\nhelpful.\n> \n> Thanks Rick,\n> Anita.\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: id_rsa.pub\nType: application/vnd.ms-publisher\nSize: 244 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140731/5803d060/attachment.bin>\n\n',NULL,NULL),('<000001cfafae$281d4190$7857c4b0$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-04 14:34:34',28800,'2014-08-04 06:34:34',NULL,'[OpenStack-Infra] FW: Requesting a Service Account for Third Party\n	CI System','HI All:\n	I saw the third-pard CI members still increased, but our account is\nnot accepted. Can you tell me why? Or how to solve this problem?\n	Please give me a feedback.\n\n 1.      Attached file.\n 2.      A preferred username: prophetstor\n 3.      A human-readable: ProphetStor-CI\n 4.      Email address: prophetstor.ci at prophetstor.com\n 5.      For cinder volume driver certificate. BP:\nhttps://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n\n> 	Please help us to create service account. Thanks.\n-----Original Message-----\nFrom: Rick Chen [mailto:rick.chen at prophetstor.com]\nSent: Monday, July 28, 2014 10:41 PM\nTo: \'Anita Kuno\'; \'openstack-infra at lists.openstack.org\'\nCc: \'steve tan\'; \'Albert Lin\'\nSubject: RE: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nHI Anita:\n	Does our service account ready?\n	I need change below information, please help me to correct? Or tell\nme how to change it?\n>> 3.      A human-readable: Prophetstor-CI --> ProphetStor-CI\n\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info]\nSent: Monday, July 28, 2014 3:43 AM\nTo: Rick Chen; openstack-infra at lists.openstack.org\nCc: \'steve tan\'; Albert Lin\nSubject: Re: [OpenStack-Infra] Requesting a Service Account for Third Party\nCI System\n\nOn 07/27/2014 01:07 PM, Rick Chen wrote:\n> Hi Anita:\n> 	Prophetstor is my company name. I plan to verify our cinder volume \n> driver.\n> 	BP:\n> https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n> 	Please help us to create service account. Thanks.\nGreat, thanks Rick. Linking the blueprint really helps.\n\nWe are working on getting me permissions to create accounts, which is soon\nbut hasn\'t happened yet. In the meantime one of my infra colleagues may get\nthe account created before I do.\n\nThanks,\nAnita.\n> \n> -----Original Message-----\n> From: Anita Kuno [mailto:anteaya at anteaya.info]\n> Sent: Saturday, July 26, 2014 9:08 PM\n> To: openstack-infra at lists.openstack.org\n> Subject: Re: [OpenStack-Infra] Requesting a Service Account for Third \n> Party CI System\n> \n> On 07/25/2014 08:36 PM, Rick Chen wrote:\n>> Hi Sir:\n>>\n>>         Please help us to create service account, Thanks.\n>>\n>>  \n>>\n>> 1.      Attached file.\n>>\n>> 2.      A preferred username: prophetstor\n>>\n>> 3.      A human-readable: Prophetstor-CI\n>>\n>> 4.      Email address: prophetstor.ci at prophetstor.com\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-Infra mailing list\n>> OpenStack-Infra at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>\n> Hi Rick:\n> \n> We are changing our documentation around requesting a service account, \n> the patch hasn\'t been merged yet:\n> https://review.openstack.org/#/c/101013/11/doc/source/third_party.rst\n> \n> So Prophetstor is the name of your company, what details can you give \n> me about what you intend to be verifying with your third party ci account?\n> It might be a piece of software or hardware or something else.\n> The more details you can offer, the better. If you have a blueprint or \n> spec for it, linking to the blueprint or spec in your reply is really\nhelpful.\n> \n> Thanks Rick,\n> Anita.\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: id_rsa.pub\nType: application/vnd.ms-publisher\nSize: 244 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140804/e2c19553/attachment.bin>\n\n',NULL,NULL),('<000001cfc0cf$0c481e90$24d85bb0$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-26 09:42:50',28800,'2014-08-26 01:42:50',NULL,'[OpenStack-Infra] Third-party CI system \"EMC XIO CI\" disabled','HI Team:\n	Please re-enable my service account \"prophetstor-ci\". The problem\nhas been addressed.\n	https://review.openstack.org/#/c/115886/\n	\nhttp://download.prophetstor.com/prophetstor_ci/115886/18/check/noop-check-co\nmmunication/61/\n\n	Thanks.\n\n-----Original Message-----\nFrom: James E. Blair [mailto:corvus at gnu.org] \nSent: Saturday, August 16, 2014 8:10 AM\nTo: openstack-infra at lists.openstack.org\nCc: emc.xio.ci at emc.com\nSubject: [OpenStack-Infra] Third-party CI system \"EMC XIO CI\" disabled\n\nHi,\n\nI have disabled the above CI system because it is in violation of the\nfollowing policies:\n\n * Include a public link to all test artifacts.\n\nThis system did not leave results at all, only \"starting\" comments.\n\nAdditionally, it was leaving \"Starting check jobs\" comments which is\nunnecessary for third-party CI systems.  We neglected to specify this as a\nformal requirement, but that will be corrected soon.\n\nPlease see the list of requirements as well as instructions on how to test\nthat your system is functioning correctly in the sandbox repository before\nenabling it on actual projects:\n\n  http://ci.openstack.org/third_party.html\n\nOnce your system configuration has been corrected, please contact us at\n<openstack-infra at lists.openstack.org> or in #openstack-infra on Freenode and\nwe will re-enable it.\n\n-Jim\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n','<87y4upe1lq.fsf@meyer.lemoncheese.net>',NULL),('<000001d018eb$47e14070$d7a3c150$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-16 11:46:35',25200,'2014-12-16 04:46:35',NULL,'[Openstack] Upgrade from Icehouse to Juno on Centos 6.5','Hello \n\n \n\nWe have an relatively big OpenStack setup (> 150 Compute Nodes) based on\nCentOS 6.5 with the RDO Icehouse release.\n\nWe now considering an upgrade to Juno, is there a best practice out there\nhow to do it and how is it with the depending CentOS upgrade to 6.6 or even\n7.0?\n\n \n\nAny help is appreciated!\n\n \n\nThanks,\n\nChris\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141216/11fdd4d5/attachment.html>\n\n',NULL,NULL),('<000201ceeb7d$33a7d700$9af78500$@sysnetinfocom.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-11-27 22:30:19',28800,'2013-11-27 14:30:19',NULL,'[openstack-community] Openstack Singapore meetup Group','Hi Sir, Madam,\n\n \n\n                             I need your advice, we created the Openstack\nMeetup Group in Singapore  http://www.meetup.com/openStack-Singapore/   how\nto list the Meetup group in openstack community user Group list.  \n\n \n\nAlso we have http://www.linkedin.com/groups/Openstack-Singapore-5190447\nLinkedin Group.\n\n \n\nPls advice. \n\n \n\nThanks\n\nJana\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131127/3436971e/attachment.html>\n\n',NULL,NULL),('<000201cf414a$d1219ca0$7364d5e0$@flyingspress.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-16 12:06:14',-25200,'2014-03-16 19:06:14',NULL,'[Openstack-docs] turn-key or turnkey?','Hi Anne,\n\nTurnkey is one word. The first instance is hyphenated, as you say, because\nit\'s at the end of the line. I suspect that line breaks will change somewhat\nwhen the edits are entered.\n\n \n\nThanks,\n\nJohn\n\n \n\n \n\nFrom: annegentle at justwriteclick.com [mailto:annegentle at justwriteclick.com]\nOn Behalf Of Anne Gentle\nSent: Sunday, March 16, 2014 11:53 AM\nTo: John Pierce\nCc: openstack-docs at lists.openstack.org\nSubject: turn-key or turnkey?\n\n \n\nHi John,\n\nI\'m working on the preface and on page 12 (xii) there\'s turn-key due to\nend-of-line hyphenation left alone and turn-key with a red dash. Does that\nmean the correct term is turnkey? I\'ll edit both places but wanted to check.\n\nThanks!\n\nAnne\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140316/183feaf0/attachment.html>\n\n','<CAD0KtVFBUV=9cJuf9UxSZkFRRcuVXV6E0owAvxNgUMXy5Sr0+Q@mail.gmail.com>',NULL),('<000301cfa869$b639fdc0$22adf940$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-26 08:36:59',28800,'2014-07-26 00:36:59',NULL,'[OpenStack-Infra] Requesting a Service Account for Third Party CI\n	System','Hi Sir:\n\n        Please help us to create service account, Thanks.\n\n \n\n1.      Attached file.\n\n2.      A preferred username: prophetstor\n\n3.      A human-readable: Prophetstor-CI\n\n4.      Email address: prophetstor.ci at prophetstor.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140726/01dc1f58/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: id_rsa.pub\nType: application/vnd.ms-publisher\nSize: 407 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140726/01dc1f58/attachment.bin>\n\n',NULL,NULL),('<000601ce86f5$0c3fa450$24beecf0$@wirelessconnections.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-22 12:03:44',-14400,'2013-07-22 16:03:44',NULL,'[Openstack-operators] Horizon issue','I followed the Grizzly install guide and am running into a basic issue.\nWhen I try to log into the dashboard, it tells me that I am attempting to\nauthenticate from the wrong IP address.  Here is the keystone log:\n\n \n\n2013-07-22 11:41:19  WARNING [keystone.common.wsgi] Authorization failed.\nThe request you have made requires authentication. from 64.186.195.20\n\n2013-07-22 11:41:51  WARNING [keystone.common.wsgi] Authorization failed.\nThe request you have made requires authentication. from 10.10.10.51\n\n \n\n \n\nAny thoughts?\n\n \n\nDavid\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130722/febd7600/attachment.html>\n\n',NULL,NULL),('<000601cebcf3$4a897400$df9c5c00$@fujitsu.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-29 17:07:15',28800,'2013-09-29 09:07:15',NULL,'[Openstack] I can\'t access instances by ssh with key','I have created three instances using ubuntu\'s official image on my OpenStack\ncontroller node.\n\nTwo of them have run for more than three weeks.\n\nThe third have run for two weeks.\n\nIn the past weeks I used were normal.\n\n \n\nSuddenly, all of them can\'t be accessed by ssh with key.\n\nAnd when I ping them, reply \"Request time out\".\n\nOn the dashboard, the status is active, and the power state is running. \n\n \n\nThe instance console log is:\n\ncloudinit startlocal running: Fri, 27 Sep 2013 05:30:33 +0000. up 5.54\nseconds\n\nno instance data found in startlocal\n\nciinfo: lo    : 1 127.0.0.1       255.0.0.0       .\n\nciinfo: eth0  : 1 10.167.35.142   255.255.255.0   fa:16:3e:31:83:9c\n\nciinfo: route0: 0.0.0.0         10.167.35.1     0.0.0.0         eth0   UG\n\nciinfo: route1: 10.167.35.0     0.0.0.0         255.255.255.0   eth0   U\n\nciinfo: route2: 169.254.169.254 10.167.35.141   255.255.255.255 eth0   UGH\n\ncloudinit start running: Fri, 27 Sep 2013 05:30:34 +0000. up 6.09 seconds\n\nfound data source: DataSourceEc2\n\n20130927 05:30:47,626  __init__.py[WARNING]: Unhandled nonmultipart userdata\n\'\'\n\nSkipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd\n\n * Starting AppArmor profiles       [80G [74G[ OK ]\n\nlandscapeclient is not configured, please run landscapeconfig.\n\n * Stopping System V initialisation compatibility[74G[ OK ]\n\n * Starting System V runlevel compatibility[74G[ OK ]\n\n * Starting save kernel messages[74G[ OK ]\n\nacpid: starting up with proc fs\n\n * Starting ACPI daemon[74G[ OK ]\n\n * Starting automatic crash report generation[74G[ OK ]\n\n * Starting regular background program processing daemon[74G[ OK ]\n\n * Starting deferred execution scheduler[74G[ OK ]\n\n * Stopping save kernel messages[74G[ OK ]\n\n * Starting CPU interrupts balancing daemon[74G[ OK ]\n\nacpid: 1 rule loaded\n\nacpid: waiting for events: event logging is off\n\n * Starting MySQL Server[74G[[31mfail[39;49m]\n\n * Starting crash report submission daemon[74G[ OK ]\n\n * Starting system logging daemon[74G[ OK ]\n\n * Starting Handle applying cloudconfig[74G[ OK ]\n\n * Stopping Handle applying cloudconfig[74G[ OK ]\n\napache2: apr_sockaddr_info_get() failed for webserver\n\napache2: Could not reliably determine the server\'s fully qualified domain\nname, using 127.0.0.1 for ServerName\n\n * Starting web server apache2       [80G [74G[ OK ]\n\n * Stopping System V runlevel compatibility[74G[ OK ]\n\n * Starting execute cloud user/final scripts[74G[ OK ]\n\ncloudinit boot finished at Fri, 27 Sep 2013 05:30:50 +0000. Up 22.48 seconds\n\n[ 3601.676137] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 3602.155585] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 3722.759789] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 3722.760682] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 3842.760065] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 3842.760815] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 3962.760093] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 3962.760839] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 4082.760060] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 4082.760932] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 4202.760097] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 4202.760985] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 4322.760058] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 4322.760936] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 4442.760085] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 4442.761002] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 4682.760064] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 4682.761029] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n[ 5762.760082] INFO: task jbd2/vdc18:1980 blocked for more than 120 seconds.\n\n[ 5762.761044] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables\nthis message.\n\n \n\nThanks.\n\n \n\nmalei\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130929/1976a68d/attachment.html>\n\n',NULL,NULL),('<000a01cf4091$0d5d7d20$28187760$@flyingspress.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-15 13:56:29',-25200,'2014-03-15 20:56:29',NULL,'[Openstack-docs] back-end,\n	back end or backend in OPS Guide and openstack-manuals?','It should be backend?a single word. The red dash is markup that the hyphen\nshould be deleted. It might still appear in a hyphenated form in a couple of\nheadings in the table of contents (which will be generated from the body),\nbut I hope I corrected it throughout the body of the text.\n\n \n\nFrom: annegentle at justwriteclick.com [mailto:annegentle at justwriteclick.com]\nOn Behalf Of Anne Gentle\nSent: Saturday, March 15, 2014 1:39 PM\nTo: Andreas Jaeger; John Pierce\nCc: Matt Kassawara; openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] back-end, back end or backend in OPS Guide and\nopenstack-manuals?\n\n \n\nSorry, hit send too soon. I am seeing \"back-end\" as a markup by\ndouble-clicking the red dash and seeing the whole word corrected to back-end\nusing Adobe Reader in multiple locations. \n\n \n\nHowever, I see http://chimera.labs.oreilly.com/books/1230000000969/ch04.html\nas backend so I\'m sending this to our copy editor John Pierce. John, can you\ncomment? \n\n \n\nThanks,\n\nAnne\n\n \n\nOn Sat, Mar 15, 2014 at 3:34 PM, Anne Gentle <anne at openstack.org\n<mailto:anne at openstack.org> > wrote:\n\nHe intends it to be changed to back-end.\n\n \n\nOn Sat, Mar 15, 2014 at 1:51 PM, Andreas Jaeger <aj at suse.com\n<mailto:aj at suse.com> > wrote:\n\nOn 03/15/2014 07:33 PM, Matt Kassawara wrote:\n> I thought we were only supposed to tackle \"AU\" comments.\n>\n\nThere\'re yellow sticky notes with AU in it and there are blue edits. I\'m\ntackling all blue edits,\n\n\nAndreas\n--\n Andreas Jaeger aj@{suse.com <http://suse.com> ,opensuse.org\n<http://opensuse.org> } Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140315/e8a2a6ba/attachment-0001.html>\n\n','<CAD0KtVFzt6tgA4GOaL5rWtCMRbD3ig1WgvoG2SmqUy0owRoaTA@mail.gmail.com>',NULL),('<000b01cfcde9$00d4e4e0$027eaea0$@vdc.com.vn>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-12 00:51:23',25200,'2014-09-11 17:51:23',NULL,'[Openstack-operators] Cinder + FC + Hitachi storage 110','Hi experts,\n\nI intend to deploy OpenStack icehouse using\n	1. My existing Hitachi Storage 110.\n	2. VM go directly to Storage instead of going through cinder.\n	3. FC Protocol.\nWhen I check: https://wiki.openstack.org/wiki/CinderSupportMatrix\nI just saw HUS with Havana and iSCSI.\n\nSo please help me:\n	1. Which OpenStack version I can use with Hitachi with FC Protocol.\n	2. In addition, how can I configure OpenStack to make VM directly go\nto external Storage (use iSCSI). Because if all Storage traffic go to\nCinder, Cinder will be overloaded.\n\nThanks guys,\n\n\n\n\n',NULL,NULL),('<000c01cf0512$393c3130$abb49390$@snow.plala.or.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-30 12:50:04',32400,'2013-12-30 03:50:04',NULL,'[Openstack] VlanManager on single-host OpenStack can NOT work','Hi Experts,\n\nI need your help on this. VlanManager on single-host OpenStack can NOT work.\nThe test bed I use is as below.\n\nOpenStack release: grizzly\nOS: Cent OS 6.4\nType of network: VlanManager (nova-network)\nHost condition: single-host (NOT multi-host)\n\nI am trying to build VlanManager environment with OpenStack grizzly on Cent\nOS 6.4, but it doesn\'t work. VM creation failed.\nI am using all-in-one architecture (single-host). FlatDHCPManager\nsuccessfully worked on the host.\n\nI am assuming that I came across a bug/defect that VlanManager can\'t work\nwith single-host environment.\nI\'d like OpenStack team to examine and determine if there is such a bug\nrelated to VlanManger on single-host environment.\n\nThank you very much in advance,\nBird Kafka\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131230/91ddb641/attachment.html>\n\n',NULL,NULL),('<000d01cf91f4$783fd250$68bf76f0$@marlin.ie>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-27 11:42:18',3600,'2014-06-27 10:42:18',NULL,'[Openstack] Create_member in LBaaS pool via python API','Hi All,\n\nA newbie question here but I can\'t find the answer in the API documentation\nor maybe I\'m not reading it correctly :-)\nI\'m trying to add an existing server instance to an existing active LBaaS\npool in icehouse.\n\nThis is my code \n\nimport neutronclient.v2_0.cleint as ntclient\nneutron = ntclient (\nauthentication works fine\n)\n\n\nneutron.create_member(\n    protocol_port = \"80\",\n    address = \"xx.xx.xx.xx\",\n    pool_id = \"xxxxxxxxxxxxxxxxxxxxxx\"\n)\n\nI get the following error -  \'create_member got an unexpected keyword\nargument \'protocol_port\'\n\nI have tried different variations such as port, protocol-port.\nI get similar issues with pool_id.\n\nThanks for your help.\n\nBrian.\n    \n\n\n\n\n\n',NULL,NULL),('<000f01cea974$1620c570$42625050$@onesource.pt>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 14:38:48',3600,'2013-09-04 13:38:48',NULL,'[Openstack] Quantum/Grizzly - Instance doesn\'t get IP','Hi Marcelo!\n\n \n\nSeems that you haven\'t got quantum client installed, and probably you have\nsome missing packages as well.\n\nMy advice is, restart from scratch again but follow the guide that \"Happy\"\nadvised you\n<https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_Mul\ntiNode/OpenStack_Grizzly_Install_Guide.rst>\nhttps://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_Mult\niNode/OpenStack_Grizzly_Install_Guide.rst\n\n \n\nGood luck\n\n \n\nClaudio Marques\n\n \n\n <mailto:claudio at onesource.pt> claudio at onesource.pt\n\n <http://www.onesource.pt/> http://www.onesource.pt/\n\n \n\n \n\n.\n\n \n\nHi Happy, thanks for your reply.\n\nI checked this guide, but I already have dhcp-agent installed. \n\nroot at network:~# apt-get -y install quantum-plugin-openvswitch-agent\nquantum-dhcp-agent quantum-l3-agent quantum-metadata-agent\nReading package lists... Done\nBuilding dependency tree       \nReading state information... Done\nquantum-dhcp-agent is already the newest version.\nquantum-l3-agent is already the newest version.\nquantum-metadata-agent is already the newest version.\nquantum-plugin-openvswitch-agent is already the newest version.\n0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n\nI also checked the settings that this guide and I added some options that I\nhad not configured. Now the error \"No active DHCP agents\" doesn\'t appears\nmore, but the error (in the Controler (quantum-server)) still appears below:\n\n2013-09-04 08:25:48  WARNING [quantum.db.agentschedulers_db] Fail scheduling\nnetwork {\'status\': u\'ACTIVE\', \'subnets\':\n[u\'80b21701-4b05-4585-985a-60905ff42531\'], \'name\': u\'public\',\n\'provider:physical_network\': None, \'admin_state_up\': True, \'tenant_id\':\nu\'27d2b93f11ac4e91a3edb26edb28fb6b\', \'provider:network_type\': u\'gre\',\n\'router:external\': True, \'shared\': False, \'id\':\nu\'b3e465b7-b5a2-45d5-8b24-aa8bea0ab0a0\', \'provider:segmentation_id\': 2L}\n\nAnd in all hosts (computer, networking and controller), I have the error:\n\n# quantum agent-list\nUnknown command [\'agent-list\']\n\nAt my network node:\n\ntail -n 10 /var/log/openvswitch/ovs-vswitchd.log\nSep 04 09:27:23|09614|netdev_linux|WARN|ioctl(SIOCGIFINDEX) on\ntap91e05e25-7f device failed: No such device\nSep 04 09:27:32|09615|netdev|WARN|Dropped 253 log messages in last 12\nseconds (most recently, 1 seconds ago) due to excessive rate\nSep 04 09:27:32|09616|netdev|WARN|failed to get flags for network device\ntap91e05e25-7f: No such device\nSep 04 09:27:33|09617|netdev_linux|WARN|Dropped 7 log messages in last 10\nseconds (most recently, 5 seconds ago) due to excessive rate\nSep 04 09:27:33|09618|netdev_linux|WARN|ioctl(SIOCGIFINDEX) on\ntap91e05e25-7f device failed: No such device\nSep 04 09:27:44|09619|netdev|WARN|Dropped 231 log messages in last 12\nseconds (most recently, 1 seconds ago) due to excessive rate\nSep 04 09:27:44|09620|netdev|WARN|failed to get flags for network device\ntap91e05e25-7f: No such device\nSep 04 09:27:48|09621|netdev_linux|WARN|Dropped 11 log messages in last 15\nseconds (most recently, 5 seconds ago) due to excessive rate\nSep 04 09:27:48|09622|netdev_linux|WARN|ioctl(SIOCGIFINDEX) on\ntap91e05e25-7f device failed: No such device\n\n(quantum) net-list\n+--------------------------------------+----------+-------------------------\n------------------------------+\n| id                                   | name     | subnets\n|\n+--------------------------------------+----------+-------------------------\n------------------------------+\n| a8f7c937-e8d0-4952-bff6-7d364335df22 | demo-net |\nfd7f324c-25ec-4134-ab97-e827fcf12824 10.5.5.0/24      |\n| b3e465b7-b5a2-45d5-8b24-aa8bea0ab0a0 | public   |\n80b21701-4b05-4585-985a-60905ff42531 xxx.xxx.xxx.0/24 |\n+--------------------------------------+----------+-------------------------\n------------------------------+\n(quantum) port-list\n+--------------------------------------+------+-------------------+---------\n----------------------------------------------------------------------------\n---+\n| id                                   | name | mac_address       |\nfixed_ips\n|\n+--------------------------------------+------+-------------------+---------\n----------------------------------------------------------------------------\n---+\n| 65c5b6cf-5eef-483e-8b32-8cd07bb83e6d |      | fa:16:3e:58:29:31 |\n{\"subnet_id\": \"80b21701-4b05-4585-985a-60905ff42531\", \"ip_address\":\n\"xxx.xxx.xxx.166\"} |\n| 806b3d3e-35fe-4356-a833-a8a3d44ec9ca |      | fa:16:3e:7c:00:24 |\n{\"subnet_id\": \"fd7f324c-25ec-4134-ab97-e827fcf12824\", \"ip_address\":\n\"10.5.5.1\"}        |\n| 91e05e25-7f7b-4399-9da2-42fef05afe31 |      | fa:16:3e:fe:63:6c |\n{\"subnet_id\": \"fd7f324c-25ec-4134-ab97-e827fcf12824\", \"ip_address\":\n\"10.5.5.2\"}        |\n| a9043279-dd30-40b7-a1e3-8d340c5408c3 |      | fa:16:3e:71:60:57 |\n{\"subnet_id\": \"80b21701-4b05-4585-985a-60905ff42531\", \"ip_address\":\n\"xxx.xxx.xxx.165\"} |\n+--------------------------------------+------+-------------------+---------\n----------------------------------------------------------------------------\n---+\n(quantum) router-list\n+--------------------------------------+-------------+----------------------\n----------------------------------+\n| id                                   | name        | external_gateway_info\n|\n+--------------------------------------+-------------+----------------------\n----------------------------------+\n| 3a703f92-e1d5-4f06-8970-8ae899d40a99 | demo-router | {\"network_id\":\n\"b3e465b7-b5a2-45d5-8b24-aa8bea0ab0a0\"} |\n+--------------------------------------+-------------+----------------------\n----------------------------------+\n(quantum) subnet-list\n+--------------------------------------+-----------------+------------------\n+--------------------------------------------------------+\n| id                                   | name            | cidr\n| allocation_pools                                       |\n+--------------------------------------+-----------------+------------------\n+--------------------------------------------------------+\n| 80b21701-4b05-4585-985a-60905ff42531 | public-subnet   | xxx.xxx.xxx.0/24\n| {\"start\": \"xxx.xxx.xxx.165\", \"end\": \"xxx.xxx.xxx.170\"} |\n| fd7f324c-25ec-4134-ab97-e827fcf12824 | demo-net-subnet | 10.5.5.0/24\n| {\"start\": \"10.5.5.2\", \"end\": \"10.5.5.254\"}             |\n+--------------------------------------+-----------------+------------------\n+--------------------------------------------------------+\n(quantum) \n\nAny more suggestions?\n\nThanks!\nMarcelo Dieder\n\n\n\n\nOn 09/04/2013 02:13 AM, happy idea wrote:\n\nyou didn\'t install the dhcp agent,  please refer to this guide\n<https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_Mul\ntiNode/OpenStack_Grizzly_Install_Guide.rst>\nhttps://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_Mult\niNode/OpenStack_Grizzly_Install_Guide.rst\n\n \n\n2013/9/4 Marcelo Dieder < <mailto:marcelodieder at gmail.com>\nmarcelodieder at gmail.com>\n\nHi All!\n\nI have a ambient with 3 hosts (Network, Controller and Node1 (Qemu)). I\ncreated an ambient based this tutorial (\n<http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_c\nontroller.html>\nhttp://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_co\nntroller.html). My problem is when I create a instance. The instance\nInstance doesn\'t get IP address.\n\n\n\n\nchecking  <http://169.254.169.254/20090404/instanceid>\nhttp://169.254.169.254/20090404/instanceid\nfailed 1/20: up 187.68. request failed\nfailed 2/20: up 190.06. request failed\nfailed 3/20: up 192.24. request failed\nfailed 4/20: up 194.43. request failed\nfailed 5/20: up 196.61. request failed\nfailed 6/20: up 198.82. request failed\nfailed 7/20: up 201.03. request failed\nfailed 8/20: up 203.22. request failed\nfailed 9/20: up 205.42. request failed\nfailed 10/20: up 207.64. request failed\nfailed 11/20: up 209.87. request failed\nfailed 12/20: up 212.08. request failed\nfailed 13/20: up 214.29. request failed\nfailed 14/20: up 216.49. request failed\nfailed 15/20: up 218.70. request failed\nfailed 16/20: up 220.91. request failed\nfailed 17/20: up 223.13. request failed\nfailed 18/20: up 225.38. request failed\nfailed 19/20: up 227.62. request failed\nfailed 20/20: up 229.87. request failed\nfailed to read iid from metadata. tried 20\nno results found for mode=net. up 232.10. searched: nocloud configdrive ec2\nfailed to get instanceid of datasource\nStarting dropbear sshd: generating rsa key... generating dsa key... OK\n=== network info ===\nifinfo: lo,up,127.0.0.1,8,::1\nifinfo: eth0,up,,8,fe80::f816:3eff:fef3:2a6d\n=== datasource: None None ===\n\n\nAt the controller I received the warning:\n\n\n2013-09-04 00:40:44  WARNING [quantum.scheduler.dhcp_agent_scheduler] No\nactive DHCP agents\n2013-09-04 00:40:44  WARNING [quantum.db.agentschedulers_db] Fail scheduling\nnetwork {\'status\': u\'ACTIVE\', \'subnets\':\n[u\'80b21701-4b05-4585-985a-60905ff42531\'], \'name\': u\'public\',\n\'provider:physical_network\': None, \'admin_state_up\': True, \'tenant_id\':\nu\'27d2b93f11ac4e91a3edb26edb28fb6b\', \'provider:network_type\': u\'gre\',\n\'router:external\': True, \'shared\': False, \'id\':\nu\'b3e465b7-b5a2-45d5-8b24-aa8bea0ab0a0\', \'provider:segmentation_id\': 2L}\n\nAnd when I executed:\n\n\nroot at cloud:~# quantum agent-list\nUnknown command [\'agent-list\']\n\nOther commands:\n\nroot at cloud:~# nova-manage service list\nBinary           Host                                 Zone\nStatus     State Updated_At\nnova-cert        cloud                                internal\nenabled    :-)   2013-09-04 03:59:12\nnova-consoleauth cloud                                internal\nenabled    :-)   2013-09-04 03:59:12\nnova-scheduler   cloud                                internal\nenabled    :-)   2013-09-04 03:59:12\nnova-conductor   cloud                                internal\nenabled    :-)   2013-09-04 03:59:12\nnova-compute     c01                                  nova\nenabled    :-)   2013-09-04 03:59:04\n\nroot at c01:~# nova list\n+--------------------------------------+---------+--------+-----------------\n-------+\n| ID                                   | Name    | Status | Networks\n|\n+--------------------------------------+---------+--------+-----------------\n-------+\n| 2c704622-1b5f-4651-9553-51aabee9090c | test29 | ACTIVE |\npublic=xxx.xxx.xxx.xxx |\n\nI searched but I couldn\'t find any resolution. Anybody has this problem?\n\nCheers.\n\nMarcelo Dieder\n\n\n\n\n_______________________________________________\nMailing list:\n<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     :  <mailto:openstack at lists.openstack.org>\nopenstack at lists.openstack.org\nUnsubscribe :\n<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/45408b0a/attachment.html>\n\n',NULL,NULL),('<000f4264.4ddf18ef0c6ed814@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 19:09:55',0,'2013-12-03 19:09:55',NULL,'[openstack-dev] [Nova][Schduler] Volunteers wanted for a modest\n proposal for an external scheduler in our lifetime','I totally agree on this meta level scheduler aspect. This should separate the placement decision making logic (for resources of any type, but can start on Nova resources) from their actual creation, say VM creation.\n\n\n\nThis way the placement decisions can be relayed to the individual components \"allocator\" component or whatever component that handles this after the separation.\n\n\n\nSo in this effort of separating the scheduler I hope some clean interfaces will be created that separate these logics.  At least we should attempt to make the effort follow some  global meta scheduling clean interfaces that should be designed.\n\n\n\nYathi.\n\n\n\n\n\n------ Original message------\n\nFrom: Debojyoti Dutta\n\nDate: Tue, 12/3/2013 10:50 AM\n\nTo: OpenStack Development Mailing List (not for usage questions);\n\nCc: Boris Pavlovic;\n\nSubject:Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime\n\n\n\nI agree with RussellB on this ? if the forklift\'s goal is to just separate the scheduler, there should be no new features etc till the forklift is done and it should work as is with very minor config changes.\n\nA scheduler has several features like place resources correctly, for example. Ideally, this should be a simple service that can allocate any resources to any available bucket - balls in bins, VMs in host, blocks/blobs on disk/SSD etc. Maybe the scheduler should operate on meta level resource maps for each \"type\" and delegate the precise decisions to the allocator for that \"type\".\n\ndebo\n\n\nOn Tue, Dec 3, 2013 at 9:58 AM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:\nOn 12/03/2013 07:22 AM, Boris Pavlovic wrote:\n> Hi all,\n>\n>\n> Finally found a bit time to write my thoughts.\n>\n> There are few blockers that make really complex to build scheduler as a\n> services or even to move main part of scheduler code to separated lib.\n> We already have one unsuccessfully effort\n> https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler .\n>\n> Major problems that we faced were next:\n> 1) Hard connection with project db api layer (e.g. nova.db.api,\n> cinder.db.api)\n> 2) Hard connection between db.models and host_states\n> 3) Hardcoded host states objects structure\n> 4) There is no namespace support in host states (so we are not able to\n> keep all filters for all projects in the same place)\n> 5) Different API methods, that can\'t be effectively generalized.\n>\n>\n> Main goals of no-db-scheduler effort are:\n> 1) Make scheduling much faster, storing data locally on each scheduler\n> and just syncing states of them\n> 2) Remove connections between project.db.api and scheduler.db\n> 3) Make host_states just JSON like objects\n> 4) Add namespace support in host_states\n>\n> When this part will be finished, we will have actually only 1 problem\n> what to do with DB API methods, and business logic of each project. What\n> I see is that there are 2 different ways:\n\nIf the new project is just a forklift of the existing code that still\nimports nova\'s db API and accesses Nova\'s DB, I don\'t think the initial\nforklift necessarily has to be blocked on completing no-db-scheduler.\nThat can happen after just as easily (depending on which effort is ready\nfirst).\n\n> 1) Make scheduler as a big lib, then implement RPC methods + bit of\n> business logic in each project\n> 2) Move all RPC calls from nova,cinder,ironic,... and business logic in\n> 1 scheduler as a service\n\nRight now I think #2 is the approach we should take.  This is mainly\nbecause there is common information that is needed for the scheduling\nlogic for resources in multiple projects.\n\n--\nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\n-Debo~\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/e95552d0/attachment.html>\n\n','<CADyX0K3_wiz4M1SsOOnAJ0uuEx4yN=msso0y52cv0a9v8bb7Xg@mail.gmail.com>',NULL),('<000f427c.01e8170f16bf8015@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 16:09:12',0,'2014-06-10 16:09:12',NULL,'[openstack-dev] [NFV] - follow up on scheduling discussion','Hi Tim,\n\n\n\nIn our current implementation of Smart (Solver) Scheduler,  the constraints are defined as pluggable modules (just like filter definitions in the filter scheduler) and are pulled in together when necessary to solve the scheduling decision. And regarding the data that we get from different services in storage (cinder)  , network and so on, we are currently using their clients to directly get the data to use along with the constraints.\n\n\n\nI believe a policy implementation can specify which constraints to use and which data. So the data can potentially be saved in the individual services.\n\n\n\nThe Gantt project is also planning to have internal DB which will be used for scheduling. That is another option where the unified data can be, when we want to do unified scheduling that we describe in our Smart scheduler project.\n\n\n\nI will open to explore options as to where Congress will fit in here,  but currently I feel it is one layer above this.\n\n\n\nThanks,\n\nYathi.\n\n\n\n\n\n\n\nSent from my LG G2, an AT&T 4G LTE smartphone\n\n\n\n\n\n------ Original message------\n\nFrom: Tim Hinrichs\n\nDate: Tue, Jun 10, 2014 8:27 AM\n\nTo: OpenStack Development Mailing List (not for usage questions);\n\nCc: Norival Figueira;Debo Dutta (dedutta);\n\nSubject:Re: [openstack-dev] [NFV] - follow up on scheduling discussion\n\n\n\nHi all,\n\nI see that many of the use cases require information from different OS components, e.g. networking, compute, and storage.  One thing to think about is where those constraints are written/stored and how the data the constraints depend on is pulled together.  The Congress project might be helpful here, and I?m happy to help explore options.  Let me know if you?re interested.\n\nhttps://wiki.openstack.org/wiki/Congress\n\nTim\n\n\n\nOn Jun 4, 2014, at 11:25 AM, ramki Krishnan <ramk at Brocade.com> wrote:\n\n> All,\n>\n> Thanks for the interest in the NFV scheduling topic. Please find a proposal on \"Smart Scheduler (Solver Scheduler) enhancements for NFV: Use Cases, Constraints etc.\". https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/document/d/1k60BQXOMkZS0SIxpFOppGgYp416uXcJVkAFep3Oeju8/edit%23heading%3Dh.wlbclagujw8c&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0A&s=836991d6daab66b519de3b670db8af001144ddb20e636665b395597aa118538f\n>\n> Based on this proposal, we are planning to enhance the existing solver-scheduler blueprint https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/solver-scheduler&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0A&s=d1883d82f8d09081b35986987b5f2f9f1d7731f16b2a5251fdbf26c1b26b294d.\n>\n> Would love to hear your comments and thoughts. Would be glad to arrange a conference call if needed.\n>\n> Thanks,\n> Ramki\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=vTulCeloS8Hc59%2FeAOd32Ri4eqbNqVE%2FeMgNRzGZnz4%3D%0A&s=7df001977efa968a09f3fae30b16ae35f4278a7bc82fcb3cdbbc9639cc505503\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/0a50d3c7/attachment.html>\n\n','<A8C0DC2E-7D35-4A5D-9075-A096F2943B7D@vmware.com>',NULL),('<000f427c.426efccd0713d2d6@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 19:38:27',0,'2014-02-03 19:38:27',NULL,'[openstack-dev] [Nova][Scheduler] Policy Based Scheduler and\n Solver Scheduler','The solver-scheduler is designed to solve for an arbitrary list of instances of different flavors. We need to have some updated apis in the scheduler to be able to pass on such requests. Instance group api is an initial effort to specify such groups.\n\n\n\nEven now the existing solver scheduler patch,  works for a group request,  only that it is a group of a single flavor. It still solves once for the entire group based on the constraints on available capacity.\n\n\n\nWith updates to the api that call the solver scheduler we can easily demonstrate how an arbitrary group of VM request can be satisfied and solved together in a single constraint solver run. (LP based solver for now in the current patch, But can be any constraint solver)\n\n\n\nThanks,\n\nYathi.\n\n\n\n\n\n------ Original message------\n\nFrom: Chris Friesen\n\nDate: Mon, 2/3/2014 11:24 AM\n\nTo: openstack-dev at lists.openstack.org;\n\nSubject:Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler\n\n\n\nOn 02/03/2014 12:28 PM, Khanh-Toan Tran wrote:\n\n> Another though would be the need for Instance Group API [1].\n> Currently users can only request multiple instances of the same\n> flavors. These requests do not need LP to solve, just placing\n> instances one by one is sufficient. Therefore we need this API so\n> that users can request instances of different flavors, with some\n> relations (constraints) among them. The advantage is that this logic\n> and API will help us add Cinder volumes with ease (not sure how the\n> Cinder-stackers think about it, though).\n\nI don\'t think that the instance group API actually helps here.  (I think\nit\'s a good idea, just not directly related to this.)\n\nI think what we really want is the ability to specify an arbitrary list\nof instances (or other things) that you want to schedule, each of which\nmay have different image/flavor, each of which may be part of an\ninstance group, a specific network, have metadata which associates with\na host aggregate, desire specific PCI passthrough devices, etc.\n\nAn immediate user of something like this would be heat, since it would\nlet them pass the whole stack to the scheduler in one API call.  The\nscheduler could then take a more holistic view, possibly doing a better\nfitting job than if the instances are scheduled one-at-a-time.\n\nChris\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140203/6f85f613/attachment.html>\n\n','<52EFEB98.1080007@windriver.com>',NULL),('<000f427c.4bd3a09816f862f8@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 23:09:50',0,'2013-10-29 23:09:50',NULL,'[openstack-dev] [nova][scheduler] Instance Group Model and APIs\n - Updated document with an example request payload','Hi Alex,\n\n\n\nI thought the value in Nova was established right from the time the initial blueprint was established.  Group of VMs with policies as described in the document.\n\nOnce we have described and registered the group using these apis, it adds value to be schedule them as a whole.\n\n\n\nWith the bigger roadmap in mind we have to start somewhere.\n\n\n\nThanks,\n\nYathi.\n\n\n\n\n\n\n\nSent from my LG G2, an AT&T 4G LTE smartphone\n\n\n\n\n\n------ Original message------\n\nFrom: Alex Glikson\n\nDate: Tue, 10/29/2013 3:11 PM\n\nTo: OpenStack Development Mailing List (not for usage questions);\n\nSubject:Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload\n\n\n\nIf we envision the main benefits only after (parts of) this logic moves outside of Nova (and starts addressing other resources) -- would it be still worth maintaining an order of 5K LOC in Nova to support this feature? Why not going for the \'ultimate\' solution in the first place then, keeping in Nova only the mandatory enablement (TBD)?\nAlternatively, if we think that there is value in having this just in Nova -- would be good to understand the exact scenarios which do not require awareness of other resources (and see if they are important enough to maintain those 5K LOC), and how exactly this can gradually evolve into the \'ultimate\' solution.\nOr am I missing something?\n\nAlex\n\n\n\n\nFrom:        \"Yathiraj Udupi (yudupi)\" <yudupi at cisco.com>\nTo:        \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>,\nDate:        29/10/2013 11:46 PM\nSubject:        Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload\n________________________________\n\n\n\nThanks Alex, Mike, Andrew, Russel for your comments.  This ongoing API discussion started in our scheduler meetings, as a first step to tackle in the Smarter resource placement ideas - See the doc for reference - https://docs.google.com/document/d/1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit  This roadmap calls for a unified resource placement decisions to be taken covering resources across services, starting from a complete topology request with all the necessary nodes/instances/resources, their connections, and the policies.\n\nHowever we agreed that we will first address the defining of the required APIs, and start the effort to make this happen within Nova,  using VM instances groups, with policies.\nHence this proposal for the instance groups.\n\nThe entire group needs to be placed as a whole, at least the first step is to find an ideal placement choices for the entire group.  Once the placement has been identified (using a smart resource placement engine that addresses solving the entire group), we then focus on ways to schedule them as a whole.  This is not part of the API discussion, however important for the smart resource placement ideas.  This definitely involves concepts such as reservation, etc.  Heat or Heat APIs could be a choice to enable the final orchestration, but I am not commenting on that here.\n\nThe APIs effort here is an attempt to provide clean interfaces now to be able to represent this instance group, and save them, and also define apis to create them.  The actual implementation will have to rely on one or more services to - 1. to make the resource placement decisions, 2. then actually provision them, orchestrate them in the right order, etc.\n\nThe placement decisions itself can happen in a module that can be a separate service, and can be reused by different services, and it also needs to have a global vision of all the resources.  (Again all of this part of the scope of smart resource placement topic).\n\nThanks,\nYathi.\n\n\nOn 10/29/13, 2:14 PM, \"Andrew Laski\" <andrew.laski at rackspace.com<mailto:andrew.laski at rackspace.com>> wrote:\n\nOn 10/29/13 at 04:05pm, Mike Spreitzer wrote:\nAlex Glikson <GLIKSON at il.ibm.com<mailto:GLIKSON at il.ibm.com>> wrote on 10/29/2013 03:37:41 AM:\n\n1. I assume that the motivation for rack-level anti-affinity is to\nsurvive a rack failure. Is this indeed the case?\nThis is a very interesting and important scenario, but I am curious\nabout your assumptions regarding all the other OpenStack resources\nand services in this respect.\n\nRemember we are just starting on the roadmap.  Nova in Icehouse, holistic\nlater\n\n2. What exactly do you mean by \"network reachibility\" between the\ntwo groups? Remember that we are in Nova (at least for now), so we\ndon\'t have much visibility to the topology of the physical or\nvirtual networks. Do you have some concrete thoughts on how such\npolicy can be enforced, in presence of potentially complex\nenvironment managed by Neutron?\n\nI am aiming for the holistic future, and Yathi copied that from an example\nI drew with the holistic future in mind.  While we are only addressing\nNova, I think a network reachability policy is inapproprite.\n\n3. The JSON somewhat reminds me the interface of Heat, and I would\nassume that certain capabilities that would be required to implement\nit would be similar too. What is the proposed approach to\n\'harmonize\' between the two, in environments that include Heat? What\nwould be end-to-end flow? For example, who would do the\norchestration of individual provisioning steps? Would \"create\"\noperation delegate back to Heat for that? Also, how other\nrelationships managed by Heat (e.g., links to storage and network)\nwould be incorporated in such an end-to-end scenario?\n\nYou raised a few interesting issues.\n\n1. Heat already has a way to specify resources, I do not see why we should\ninvent another.\n\n2. Should Nova call Heat to do the orchestration?  I would like to see an\nexample where ordering is an issue.  IMHO, since OpenStack already has a\nsolution for creating resources in the right order, I do not see why we\nshould invent another.\n\nHaving Nova call into Heat is backwards IMO.  If there are specific\npieces of information that Nova can expose, or API capabilities to help\nwith orchestration/placement that Heat or some other service would like\nto use then let\'s look at that.  Nova has placement concerns that extend\nto finding a capable hypervisor for the VM that someone would like to\nboot, and then just slightly beyond.  If there are higher level\ndecisions to be made about placement decisions I think that belongs\noutside of Nova, and then just tell Nova where to put it.\n\n\n\nThanks,\nMike\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/d58df970/attachment.html>\n\n','<OF6B57C24B.4748C269-ONC2257C13.00788381-C2257C13.00795A55@il.ibm.com>',NULL),('<001001cf37a7$e0cef780$a26ce680$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 21:47:18',32400,'2014-03-04 12:47:18',NULL,'[openstack-dev] [Ceilometer] Suggestions for alarm improvements','Hi All,\n\n Sandy did a great job by putting up some valuable points for alarm\nimprovements in,\n https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements\n Is there any further discussion about [Part 4 - Moving Alarms into the\nPipelines] in above doc?\n I tried to find more info about above topic but failed.\n If someone working on above Part 4, really appreciate could give a quick\nreply on this.\n Thanks,\n  Sampath.\n\n\n\n',NULL,NULL),('<001001cfd896$54470bf0$fcd523d0$@dektech.com.au>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 14:57:15',25200,'2014-09-25 07:57:15',NULL,'[openstack-dev] Horizon: display status of the VM','Hi OpenStack-dev,\n\n \n\nI\'ve posted a question regarding the displaying status of the VM on\nOpenStack forum:\n\nhttps://ask.openstack.org/en/question/48450/horizon-display-status-of-the-vm\n/\n\n \n\nAny feedback/answer would be much appreciated.\n\n \n\nThanks and regards\n\nTrung\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/61bed4c0/attachment.html>\n\n',NULL,NULL),('<001101ce78ca$cdd50620$697f1260$@gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-04 22:26:02',25200,'2013-07-04 15:26:02',NULL,'[openstack-community] usage of openstack information','Hi Randy,\n\n\nOpenstack\'s operations bases on the installed hypervisor. First, you need to\nknow exactly your hypervisor that is supporting which types  of back-end\nstorage.  After that, you can select one  back-end storage system\ncorresponds to your system.\n\n \n\nCinder is just an front-end to help vms can connect to an back-end storage\nbehind. Cinder supports so much driver to connect to back-end storage system\nsuch as: NFS, Ceph, GlusterFS, LVM ,.\n\n \n\nIf you have a back-end storage which cinder hasn\'t supported yet driver to\nconnect to, you can create a middle mount-point by using  NFS, ISCSI to help\ncinder can operate on them :). \n\n \n\nRegards,\n\nKhanh Nguyen\n\n \n\nFrom: Randy S [mailto:sim.ple at live.nl] \nSent: Thursday, July 4, 2013 5:32 PM\nTo: community at lists.openstack.org\nSubject: [openstack-community] usage of openstack information\n\n \n\nHi all,\n \nI have been reading up on openstack as I am completely new to this. I have\nset \nup some test systems according to manuals found here and there.\nNow, I have a question about the possible use of openstack storage.\nI have seen that the normal provisioning of storage is meant to be for vm\'s \ncreated within openstack itself. This can then be block storage (cinder) or \nobject storage.\n \nCan somebody tell me if it is possible to use openstack to provision the\nsame \nkind of storage to physical servers which are otherwise in no way connected\nto \nopenstack or virtual machines created in systems like vmware?\n \nI hope somebody can asnwer me this and maybe point me the way to test\nsomething \nlike this.\n \nThanks in advance,\n \nRgds,\n \nRandy\n                                          \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130704/72ca5aab/attachment.html>\n\n','<BLU177-W8D6FCD40B1BF7FB198A0AE07C0@phx.gbl>',NULL),('<001101cfcccd$ef2d2930$cd877b90$@org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 10:03:34',7200,'2014-09-10 08:03:34',NULL,'[openstack-dev] [Neutron][QoS] Applying QoS as Quota','Hello everyone,\n\nLooking at the QoS blueprint (proposed for incubation), I suggest to\nconsider adding some parameters to Neutron Quotas. Let\'s suppose using\nrate-limit for managing QoS. The quota parameters could be such as\nrate_limit (per port) and max_bandwidth (per tenant). In this way it is\npossible to set/manage QoS quotas from the admin side, and for instance\nset the maximum bandwidth allowed per tenant (cumulative).\n\nWhat do you think about it?\n\n \n\nRegards,\n\nGiuseppe\n\n \n\n--------------------------------------------------------\n\nGiuseppe Cossu\n\nCREATE-NET\n\n--------------------------------------------------------\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/04640c53/attachment.html>\n\n',NULL,NULL),('<001201cf4427$18e248d0$4aa6da70$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 19:28:12',32400,'2014-03-20 10:28:12',NULL,'[openstack-dev] [Ceilometer] [QA] Slow Ceilometer resource_list\n	CLI command','Hi,\n\n  Re-architecting the schema might fix most of the performance issues of\nresource_list.  \n  And also, must do some work to improve the performance of meter-list.\n  Is the Gordon\'s blue print gonna cover the both aspects ?\n  https://blueprints.launchpad.net/ceilometer/+spec/big-data-sql\n  \nSampath\n\n-----Original Message-----\nFrom: Neal, Phil [mailto:phil.neal at hp.com] \nSent: Wednesday, March 19, 2014 12:17 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer resource_list\nCLI command\n\n\n> -----Original Message-----\n> From: Tim Bell [mailto:Tim.Bell at cern.ch]\n> Sent: Monday, March 17, 2014 2:04 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer \n> resource_list CLI command\n> \n> \n> At CERN, we\'ve had similar issues when enabling telemetry. Our \n> resource-list times out after 10 minutes when the proxies for HA \n> assume there is no answer coming back. Keystone instances per cell \n> have helped the situation a little so we can collect the data but \n> there was a significant increase in load on the API endpoints.\n> \n> I feel that some reference for production scale validation would be \n> beneficial as part of TC approval to leave incubation in case there \n> are issues such as this to be addressed.\n> \n> Tim\n> \n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 17 March 2014 20:25\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [Ceilometer] [QA] Slow Ceilometer\n> resource_list CLI command\n> >\n> ...\n> >\n> > Yep. At AT&T, we had to disable calls to GET /resources without any \n> > filters\n> on it. The call would return hundreds of thousands of\n> > records, all being JSON-ified at the Ceilometer API endpoint, and \n> > the result\n> would take minutes to return. There was no default limit\n> > on the query, which meant every single records in the database was\n> returned, and on even a semi-busy system, that meant\n> > horrendous performance.\n> >\n> > Besides the problem that the SQLAlchemy driver doesn\'t yet support\n> pagination [1], the main problem with the get_resources() call is\n> > the underlying databases schema for the Sample model is wacky, and\n> forces the use of a dependent subquery in the WHERE clause\n> > [2] which completely kills performance of the query to get resources.\n> >\n> > [1]\n> >\n> https://github.com/openstack/ceilometer/blob/master/ceilometer/storage\n> /\n> impl_sqlalchemy.py#L436\n> > [2]\n> >\n> https://github.com/openstack/ceilometer/blob/master/ceilometer/storage\n> /\n> impl_sqlalchemy.py#L503\n> >\n> > > The cli tests are supposed to be quick read-only sanity checks of \n> > > the cli functionality and really shouldn\'t ever be on the list of \n> > > slowest tests for a gate run.\n> >\n> > Oh, the test is readonly all-right. ;) It\'s just that it\'s reading \n> > hundreds of\n> thousands of records.\n> >\n> > >  I think there was possibly a performance regression recently in \n> > > ceilometer because from I can tell this test used to normally take ~60\nsec.\n> > > (which honestly is probably too slow for a cli test too) but it is \n> > > currently much slower than that.\n> > >\n> > > From logstash it seems there are still some cases when the \n> > > resource list takes as long to execute as it used to, but the \n> > > majority of runs take a\n> long time:\n> > > http://goo.gl/smJPB9\n> > >\n> > > In the short term I\'ve pushed out a patch that will remove this \n> > > test from gate\n> > > runs: https://review.openstack.org/#/c/81036 But, I thought it \n> > > would be good to bring this up on the ML to try and figure out \n> > > what changed or why this is so slow.\n> >\n> > I agree with removing the test from the gate in the short term. \n> > Medium to\n> long term, the root causes of the problem (that GET\n> > /resources has no support for pagination on the query, there is no \n> > default\n> for limiting results based on a since timestamp, and that\n> > the underlying database schema is non-optimal) should be addressed.\n\nGordon has introduced a blueprint\nhttps://blueprints.launchpad.net/ceilometer/+spec/big-data-sql with some\nfixes for individual queries but +1 to the point of looking at\nre-architecting the schema as an approach to fixing performance. We\'ve also\nseen some gains here at HP using batch writes as well but have temporarily\ntabled that work in favor of getting a better-performing schema in place.\n- Phil\n\n> >\n> > Best,\n> > -jay\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n',NULL,NULL),('<001401d012ce$b67358c0$235a0a40$@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-12-08 18:07:02',28800,'2014-12-08 10:07:02',NULL,'[OpenStack-Infra] devstack failed\n	\'./stack.sh:1224:start_nova_api\'','HI Sam:\n\n        I happed same issue. In the some log has trace-back in the oslo\npackage, but I forgot which one.\n\n        I try to update all oslo.XXX that can solve this problem.\n\n        Ex:\n\n                pip install oslo.concurrency --upgrade\n\n \n\nFrom: Wan, Sam [mailto:Sam.Wan at emc.com] \nSent: Monday, December 08, 2014 4:14 PM\nTo: openstack-infra at lists.openstack.org\nSubject: [OpenStack-Infra] devstack failed \'./stack.sh:1224:start_nova_api\'\n\n \n\nDear all,\n\n \n\nOur CI failed at devstack setup.\n\nThe error messages in devstacklog is as below:\n\n\n2014-12-07 22:33:47.959 | ./stack.sh:1224:start_nova_api\n\n2014-12-07 22:33:47.959 | /opt/stack/new/devstack/lib/nova:701:die\n\n2014-12-07 22:33:47.965 | [ERROR] /opt/stack/new/devstack/lib/nova:701\nnova-api did not start\n\n2014-12-07 22:33:48.970 | exit_trap: cleaning up child processes\n\n2014-12-07 22:33:48.970 | ./stack.sh: line 441: kill: (5161) - No such\nprocess\n\n2014-12-07 22:33:48.971 | Error on exit\n\n2014-12-07 22:33:49.019 | World dumping... see\n/opt/stack/new/worlddump-2014-12-07-223349.txt for details\n\n2014-12-07 22:33:49.086 | ./stack.sh: line 434:   428 Terminated\n_old_run_process \"$service\" \"$command\"\n\n \n\nSeems there\'s something wrong with nova-api.\n\nHas someone met this too? \n\nAny suggestion or clue will be appreciated.\n\n \n\nThanks and regards\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n| Wan Shan  (Sam)\n\n| Openstack Certification | EMC E-Lab\n\n| Tel: +86-28-82966713\n\n| Addr: 7F, C12, Tianfu Software Park, Chengdu, Sichuan, P. R. of China\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20141208/4659a491/attachment.html>\n\n','<2766FDEB4D6EC647B5ED0A96096A2C3735D1FAE9F8@MX10A.corp.emc.com>',NULL),('<00143011-9902-4D3D-A1AE-A20D9701C042@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 13:02:07',-14400,'2014-09-17 17:02:07',NULL,'[openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder','\nOn Sep 16, 2014, at 6:02 PM, Flavio Percoco <flavio at redhat.com> wrote:\n\n> On 09/16/2014 11:55 PM, Ben Nemec wrote:\n>> Based on my reading of the wiki page about this it sounds like it should\n>> be a sub-project of the Storage program.  While it is targeted for use\n>> by multiple projects, it\'s pretty specific to interacting with Cinder,\n>> right?  If so, it seems like Oslo wouldn\'t be a good fit.  We\'d just end\n>> up adding all of cinder-core to the project anyway. :-)\n> \n> +1 I think the same arguments and conclusions we had on glance-store\n> make sense here. I\'d probably go with having it under the Block Storage\n> program.\n\nI agree. I?m sure we could find some Oslo contributors to give you advice about APIs if you like, but I don?t think the library needs to be part of Oslo to be reusable.\n\nDoug\n\n> \n> Flavio\n> \n>> \n>> -Ben\n>> \n>> On 09/16/2014 12:49 PM, Ivan Kolodyazhny wrote:\n>>> Hi Stackers!\n>>> \n>>> I\'m working on moving Brick out of Cinder for K release.\n>>> \n>>> There\'re a lot of open questions for now:\n>>> \n>>>   - Should we move it to oslo or somewhere on stackforge?\n>>>   - Better architecture of it to fit all Cinder and Nova requirements\n>>>   - etc.\n>>> \n>>> Before starting discussion, I\'ve created some proof-of-concept to try it. I\n>>> moved Brick to some lib named oslo.storage for testing only. It\'s only one\n>>> of the possible solution to start work on it.\n>>> \n>>> All sources are aviable on GitHub [1], [2].\n>>> \n>>> [1] - I\'m not sure that this place and name is good for it, it\'s just a PoC.\n>>> \n>>> [1] https://github.com/e0ne/oslo.storage\n>>> [2] https://github.com/e0ne/cinder/tree/brick - some tests still failed.\n>>> \n>>> Regards,\n>>> Ivan Kolodyazhny\n>>> \n>>> On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny <e0ne at e0ne.info> wrote:\n>>> \n>>>> Hi All!\n>>>> \n>>>> I would to start moving Cinder Brick [1] to oslo as was described on\n>>>> Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be\n>>>> sure that nobody started it and we are on the same page.\n>>>> \n>>>> According to the Juno 3 release, there was not enough time to discuss [3]\n>>>> on the latest Cinder weekly meeting and I would like to get some feedback\n>>>> from the all OpenStack community, so I propose to start this discussion on\n>>>> mailing list for all projects.\n>>>> \n>>>> I anybody didn\'t started it and it is useful at least for both Nova and\n>>>> Cinder I would to start this work according oslo guidelines [4] and\n>>>> creating needed blueprints to make it finished until Kilo 1 is over.\n>>>> \n>>>> \n>>>> \n>>>> [1] https://wiki.openstack.org/wiki/CinderBrick\n>>>> [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014\n>>>> [3]\n>>>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html\n>>>> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary\n>>>> \n>>>> Regards,\n>>>> Ivan Kolodyazhny.\n>>>> \n>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> \n> -- \n> @flaper87\n> Flavio Percoco\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5418B35D.40808@redhat.com>',NULL),('<001501cee1aa$edc95e10$c95c1a30$@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 10:31:43',28800,'2013-11-15 02:31:43',NULL,'[openstack-dev] subscribe','subscribe\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/77bf6aca/attachment.html>\n\n',NULL,NULL),('<00170DD0-C040-42A5-B659-28B3DDE62A99@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 22:50:48',14400,'2013-09-25 18:50:48',NULL,'[openstack-dev] [savanna] sessions for design summit','Hi folks,\n\nSavanna has been accepted for incubation and, so, we have 4 slots at the Icehouse Design Summit that is awesome.\n\nPlease, feel free to suggest sessions about Savanna using topic \"savanna\" at http://summit.openstack.org/ and comment on exesting sessions.\n\nYou have time until mid-October to suggest sessions. Suggested sessions will be reviewed/merged/scheduled after it.\n\nMore information about the Icehouse Design Summit can be found at https://wiki.openstack.org/wiki/Summit\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\n\n\n',NULL,NULL),('<001901cff7e0$4dd826a0$e98873e0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-04 10:34:50',25200,'2014-11-04 03:34:50',NULL,'[Openstack] Second glance server','Hello,\n\n \n\nWe use OpenStack in one of our DC locations (location A). Now we want to\nhave compute nodes in other locations (location B).\n\nIn location B we want to have just compute nodes and an additional glance\nserver to prevent  image transfers from location A to B.\n\n \n\nWhat is the best practice to have two glance servers in OpenStack and what\nconfiguration changes needs to be done to let the compute nodes just access\nthe local glance server.\n\n \n\nThank you!\n\n \n\nCheers\n\nChris\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141104/c6eb87d3/attachment.html>\n\n',NULL,NULL),('<001a01cef04d$e685f5d0$b391e170$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-03 09:34:20',-28800,'2013-12-03 17:34:20',NULL,'[openstack-community] OpenStack Northwest User Group Meetup is\n	tomorrow, Wed 12/4 in Portland','As you may recall, a company called VMware started the virtualization\nrevolution last decade to allow for better utilization of faster computer\nhardware. While the company focused on developing its market share, a book\nseller named Amazon took the industry by surprise and built the world\'s\nlargest Public Cloud using freely available alternatives.\n\nIt was swift, and it embarrassed the largest players in the technology\nsector. The only way for a fragmented industry to fight back was to agree on\nembracing an open source option.\n\nIn 2010, OpenStack which was originally developed by NASA, was ready to meet\nthe challenge. Most leading companies like IBM, HP, Intel, Rackspace, etc.\ninvested in its development to offer an alternative. This ground-breaking\nopen-source platform has grown. It passed through Portland last April and\ncontinued on to taking the world by storm in Hong Kong early this month.\n\nJoin industry influencers and RSVP here:\nhttp://www.meetup.com/OpenStack-Northwest to learn about the most\nfundamental technology transformation of our lifetime, and why you should\nreally pay attention.\n\nWhere: Puppet Labs, 926 NW 13th Ave #210, Portland, OR.\n\nWhen: Wednesday Dec 4 @ 6:30 pm\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording link.\n\nSponsored by DetaCloud and Puppet Labs, this meetup caters to both the\nindustry curious and technology professionals. Following a short\nintroduction, we will describe the lay of the land, why OpenStack, how it\nworks and what\'s new in the latest release, Havana, and finally, automation\nwith Puppet.\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131203/e4bf4c0e/attachment.html>\n\n',NULL,NULL),('<001a01cfd613$0544ee80$0fcecb80$@dektech.com.au>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 10:12:16',25200,'2014-09-22 03:12:16',NULL,'[openstack-dev] About the question \"Switch firewall_driver control\n	from Neutron to Nova\"','Dear OpenStack-dev,\n\n \n\nI\'ve posted a question on\nhttps://ask.openstack.org/en/question/47819/switch-firewall_driver-control-f\nrom-neutron-to-nova/ \n\nIt\'s suggested that I should forward this question to OpenStack-dev mailing\nlist for discussion.\n\n \n\nAny feedback/answer would be very appreciated.\n\n \n\nThanks and regards\n\nTrung\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140922/06aefd82/attachment.html>\n\n',NULL,NULL),('<001a11c1ff949f0d9a04f510beba@google.com>','http://lists.openstack.org/pipermail/fits',NULL,'2014-03-20 21:49:33',0,'2014-03-20 21:49:33',NULL,'[Fits] Invitation: Refstack F2F @ Piston @ Fri Mar 28,\n	2014 1pm - 3:30pm (forrest@pistoncloud.com)','You have been invited to the following event.\n\nTitle: Refstack F2F @ Piston\nWhen: Fri Mar 28, 2014 1pm - 3:30pm Pacific Time\nWhere: Board Room\nCalendar: forrest at pistoncloud.com\nWho:\n     * Forrest Carpenter - organizer\n     * David Lenwell\n     * fits at lists.openstack.org\n\nEvent details:  \nhttps://www.google.com/calendar/event?action=VIEW&eid=M2xzaDhnNHIyNTBmNzFmOTlvbGV2Z3RwcWcgZml0c0BsaXN0cy5vcGVuc3RhY2sub3Jn&tok=MjMjZm9ycmVzdEBwaXN0b25jbG91ZC5jb21lZWY5NTc3OTFjZjllODNlZjUzZDEyNGUxYTI5ZDNjMmE3NDE1OGM1&ctz=America/Los_Angeles&hl=en\n\nInvitation from Google Calendar: https://www.google.com/calendar/\n\nYou are receiving this courtesy email at the account  \nfits at lists.openstack.org because you are an attendee of this event.\n\nTo stop receiving future notifications for this event, decline this event.  \nAlternatively you can sign up for a Google account at  \nhttps://www.google.com/calendar/ and control your notification settings for  \nyour entire calendar.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140320/7326bf6a/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: not available\nType: text/calendar\nSize: 1379 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140320/7326bf6a/attachment.ics>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: invite.ics\nType: application/ics\nSize: 1413 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140320/7326bf6a/attachment.bin>\n\n',NULL,NULL),('<001b01ce8b07$f11573f0$d3405bd0$@googlemail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-27 22:29:02',7200,'2013-07-27 20:29:02',NULL,'[Openstack] Fwd: Does anyone have a working cloud with Flat\n	Networking?','Hello Comiq,\n\ni tried it two or three times with different tutorials and different\nopenstack releases but i did\'nt found a working solution.\nI am very interested in an ONE NIC Config, especially ubuntu-based.\n\nI heard about a solution with nova-network instead of the new networking\nmodule, but it did\'nt worked out for me.\nIf you find out something, I would be very happy if you tell me about your\nsolution!\n\nWith best regards,\nFinn\n\n\n\n-----Urspr?ngliche Nachricht-----\nVon: comiqadze [mailto:comiq at yandex.ru] \nGesendet: Samstag, 27. Juli 2013 21:05\nAn: openstack\nBetreff: [Openstack] Fwd: Does anyone have a working cloud with Flat\nNetworking?\n\n\n\nHi all,\n\nI want to ask for help!\nPlease mail me if you have already WORKING smoothly \nOpenstack cloud with Computes and Controller nodes, that work with Flat\nNetworking configuration, i.e. with ONE NIC !\nAnd also with full ubuntu as an image.\n\nThank you,\nComiq\n\n_______________________________________________\nMailing list: %(list_owner)s\nPost to     : %(list_post)s\nUnsubscribe : %(list_unsubscribe)s\nMore help   : %(list_help)s\n\n\n\n','<502281374951916@web7h.yandex.ru>',NULL),('<001b01cfc333$977465d0$c65d3170$@vdc.com.vn>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-29 09:47:36',25200,'2014-08-29 02:47:36',NULL,'[Openstack-operators] Increase MTU from VM to VM,\n	pass through physical Network devic','Dear experts,\n\n \n\nMy issue is that:\n\n1.    I set up OpenStack in multi Nodes model, with ML2 Plugin and GRE mode.\n\n2.    I created 2 VMs in the same Compute node. (1 Web and 1 DB).\n\n3.    My App needs fully support packet 1500 Bytes.\n\n \n\nHow can I configure Openstack to do that?\n\n \n\n----\n\nI already configured:\n\n1.    Set MTU of Ethernet_interface in VM \n\n\n \n\nVM1# ifconfig eth0 mtu 1600\n\nVM2# ifconfig eth0 mtu 1600\n\n \n\nroot at cuong-vm-01:~# netstat -i\n\nKernel Interface table\n\nIface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg\n\neth0       1600 0     15958      0      0 0         10317      0      0      0 BMRU\n\nlo        65536 0         0      0      0 0             0      0      0      0 LRU\n\nroot at cuong-vm-02:~# netstat -i\n\nKernel Interface table\n\nIface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg\n\neth0       1600 0     15936      0      0 0         10009      0      0      0 BMRU\n\nlo        65536 0         0      0      0 0             0      0      0      0 LRU\n\n \n\n2.    Set MTU of every port in BR-INT to 1600Bytes\n\n\nroot at controller:~# netstat -i\n\nKernel Interface table\n\nIface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg\n\nbr-ex      1500 0     21680      0      0 0          2928      0      0      0 BRU\n\nbr-int     1600 0       308      0      0 0             6      0      0      0 BRU\n\nbr-tun     1500 0         0      0      0 0             6      0      0      0 BRU\n\neth0       1500 0    483582      0      2 0         22859      0      0      0 BMPRU\n\neth1       1500 0       220      0      0 0             6      0      0      0 BMRU\n\nlo        65536 0    174389      0      0 0        174389      0      0      0 LRU\n\nqbr480003c8-57  1500 0        29      0      0 0             6      0      0      0 BMRU\n\nqbr59db81a4-93  1500 0        46      0      0 0             6      0      0      0 BMRU\n\nqvb480003c8-57  1500 0     15907      0      0 0          9877      0      0      0 BMPRU\n\nqvb59db81a4-93  1500 0     15773      0      0 0         10087      0      0      0 BMPRU\n\nqvo480003c8-57  1600 0      9877      0      0 0         15907      0      0      0 BMPRU\n\nqvo59db81a4-93  1600 0     10087      0      0 0         15773      0      0      0 BMPRU\n\ntap480003c8-57  1500 0      9995      0      0 0         15912      0      0      0 BMRU\n\ntap59db81a4-93  1500 0     10169      0      0 0         15764      0      0      0 BMRU\n\nvirbr0     1500 0         0      0      0 0             0      0      0      0 BMU\n\n \n\nHowever, I clouldn?t ping from VM 01 to VM02 without fragment\n\nroot at cuong-vm-01:~# traceroute --mtu 172.16.10.13  \n\ntraceroute to 172.16.10.13 (172.16.10.13), 30 hops max, 65000 byte packets\n\n1  * F=1600 * *\n\n2  * * *\n\n3  * * *\n\n4  * *^C\n\n--- \n\nroot at cuong-vm-02:~# ping -s 1500 -M do 172.16.10.12\n\nPING 172.16.10.12 (172.16.10.12) 1500(1528) bytes of data.\n\n \n\nThank you very much.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140829/0013fb6b/attachment.html>\n\n',NULL,NULL),('<001d01cfd95f$2804fdd0$780ef970$@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-26 09:54:51',7200,'2014-09-26 07:54:51',NULL,'[Openstack-docs] Getting started','Hey everyone,\n\n \n\nI\'m new to the mailing list (and Openstack in general) and would like to\nstart contributing now that I have some more time on my hands. Problem is I\njust rolled out of college and have never seriously contributed to an open\nsource project. What\'s the best way for me to get started? I saw an e-mail\ncome by about install-guide testing and logging bugs against any errors I\nmight find. I was wondering if there\'s some coordinating mechanism in place\nso I can see what distribution I could best focus on?\n\n \n\nWith kind regards,\n\n \n\nBas\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140926/8b39fa5e/attachment-0001.html>\n\n',NULL,NULL),('<001e01ce9ff7$6ceb9500$46c2bf00$@onesource.pt>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-23 12:53:44',3600,'2013-08-23 11:53:44',NULL,'[Openstack] Designate /DnsaaS','Hello guys\n\nI appreciate your help with DESIGNATE and your patience. \n\nIs there any plugin to integrate designate in Horizon?\n\nCheers\n\nCl?udio Marques\n\nclaudio at onesource.pt\n\nhttp://www.onesource.pt/\n\nDe: Simon McCartney [mailto:simon at mccartney.ie] \nEnviada: 22 de agosto de 2013 18:37\nPara: claudio at onesource.pt\nAssunto: Re: [Openstack] Designate /DnsaaA\n\n \n\nDo you mean in conjunction with the notifications sink (where records are\ncreated or deleted in response to instance create/delete events) in which\ncase the domain to be used is set in the designate.conf file, and is global,\nnot currently configurable per tenant.\n\n \n\nOn 22 August 2013 17:05, <claudio at onesource.pt> wrote:\n\nHi Stackers\n\nIs there anyone that have some experience with designate?\n\nI can create domains servers and records but I am a bit stuck. How can\nallocate a domain to a specific Tenant/project?\n\nCan anyone help-me in this?\n\nThank\'s\nCheers\n\nClaudio Marques\n\nclaudio at onesource.pt\nhttp://www.onesource.pt/\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n \n\n-- \n\nSimon McCartney\n\nE: simon at mccartney.ie                     \n\nM: +44 7710 836 915\n\n \n\n \n\n_______________________________________________\n\n\n\n \n\n \n\nClaudio,\n\n \n\nHey, maybe I am not understanding your question, but whatever tenant you are\nusing to create domains and domain records, that is the one allocated to\nthat tenant. \n\n \n\nRegards,\n\n \n\nPatrick\n\n \n\n_______________________________________________\n\n\n\n \n\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130823/c6a608aa/attachment.html>\n\n',NULL,NULL),('<001E6112-81B3-4CB9-B1B3-E3BF0340BB99@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 22:40:43',0,'2013-06-24 22:40:43',NULL,'[openstack-dev] Termination of the title line of commit messages','On Jun 24, 2013, at 2:50 PM, Mark McLoughlin wrote:\n> \n> Unlike other nitpicking I tend to do with commit messages, I previously\n> never thought this was worth even mentioning to committers but if some\n> reviewers were going to start -1ing people for the *correct* style then\n> I figured it was best to clear it up.\n\nI too have never thought it worth mentioning, similar to capitalizing the first word of the first line of the commit message or not. I thought any way works, as long as the first line is brief so it shows up nicely browsing on github.\n\nPersonally, I treat the first line like you mention the subject line of an email, which I never capitalize or use a period at the end.\n\nMelanie\n\n','<1372110618.2370.52.camel@sorcha>',NULL),('<001f01cef04d$e6b67bb0$b4237310$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 09:34:20',-28800,'2013-12-03 17:34:20',NULL,'[Openstack] OpenStack Northwest User Group Meetup is tomorrow,\n	Wed 12/4 in Portland','As you may recall, a company called VMware started the virtualization\nrevolution last decade to allow for better utilization of faster computer\nhardware. While the company focused on developing its market share, a book\nseller named Amazon took the industry by surprise and built the world\'s\nlargest Public Cloud using freely available alternatives.\n\nIt was swift, and it embarrassed the largest players in the technology\nsector. The only way for a fragmented industry to fight back was to agree on\nembracing an open source option.\n\nIn 2010, OpenStack which was originally developed by NASA, was ready to meet\nthe challenge. Most leading companies like IBM, HP, Intel, Rackspace, etc.\ninvested in its development to offer an alternative. This ground-breaking\nopen-source platform has grown. It passed through Portland last April and\ncontinued on to taking the world by storm in Hong Kong early this month.\n\nJoin industry influencers and RSVP here:\nhttp://www.meetup.com/OpenStack-Northwest to learn about the most\nfundamental technology transformation of our lifetime, and why you should\nreally pay attention.\n\nWhere: Puppet Labs, 926 NW 13th Ave #210, Portland, OR.\n\nWhen: Wednesday Dec 4 @ 6:30 pm\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording link.\n\nSponsored by DetaCloud and Puppet Labs, this meetup caters to both the\nindustry curious and technology professionals. Following a short\nintroduction, we will describe the lay of the land, why OpenStack, how it\nworks and what\'s new in the latest release, Havana, and finally, automation\nwith Puppet.\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/71bf9bef/attachment.html>\n\n',NULL,NULL),('<001FC714-54F2-4DD9-B3E8-258B85945C81@switch.ch>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-14 17:04:23',7200,'2014-07-14 15:04:23',NULL,'[Openstack] Unable to delete instances','It seems that I as chasing down the wrong rabbit hole?\n\nOur controller node runs on a VM and has had sever hiccups the last few days (pausing for up to 10 seconds from time to time). We have moved the VM to another host, the pauses disappeared, and I can delete as many VMs at a time as I like?\n\ncheers\njc\n\n-- \nSWITCH\nJens-Christian Fischer, Peta Solutions\nWerdstrasse 2, P.O. Box, 8021 Zurich, Switzerland\nphone +41 44 268 15 15, direct +41 44 268 15 71\njens-christian.fischer at switch.ch\nhttp://www.switch.ch\n\nhttp://www.switch.ch/stories\n\nOn 11.07.2014, at 15:45, Brebner, Gavin <gavin.brebner at hp.com> wrote:\n\n>  \n> we change /etc/security/limits.conf (actually add an entry to /etc/security/limits.conf.d) for the rabbit user.\n>  \n> We just do that for the non-compute nodes.\n>  \n>                 Gavin\n>  \n>  \n> From: Jens-Christian Fischer [mailto:jens-christian.fischer at switch.ch] \n> Sent: Friday, July 11, 2014 3:41 PM\n> To: Brebner, Gavin\n> Cc: openstack at lists.openstack.org\n> Subject: Re: [Openstack] Unable to delete instances\n>  \n> There is just one queue that is building up: notifications.info - there are no consumers for it.\n>  \n> I have upped the ulimit for the rabbitmq server (by changing /etc/default/rabbitmq-server) but that hasn?t made any difference.\n>  \n> Are you also upping the limits on the compute nodes? \n>  \n> cheers\n> jc\n>  \n> -- \n> SWITCH\n> Jens-Christian Fischer, Peta Solutions\n> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland\n> phone +41 44 268 15 15, direct +41 44 268 15 71\n> jens-christian.fischer at switch.ch\n> http://www.switch.ch\n> \n> http://www.switch.ch/stories\n>  \n> On 11.07.2014, at 12:50, Brebner, Gavin <gavin.brebner at hp.com> wrote:\n> \n> \n> Delete issues in my experience are typically linked to messaging getting stuck (or dead hosts). I would have a look at the\n> RMQ queue lengths and see if any are building up.\n>  \n> Have you adjusted your open file descriptor limits ? The default Linux limit (1024) is NOT enough in our experience for any reasonable\n> sized system. We?ve seen that cause messaging outages.\n>  \n>                 Gavin\n>  \n> From: Jens-Christian Fischer [mailto:jens-christian.fischer at switch.ch] \n> Sent: Friday, July 11, 2014 12:32 PM\n> To: Thomas Bernard\n> Cc: openstack at lists.openstack.org\n> Subject: Re: [Openstack] Unable to delete instances\n>  \n> Did you ever come to the bottom of this?\n>  \n> We are seeing the same thing with a brand new Icehouse / Ceph installation (using the stock distributions)\n>  \n> Restarting nova-compute on the compute nodes usually makes the instances go away (or resetting the state, and then restarting nova-compute)\n>  \n> We see this problem intermittent but frequent enough to be really annoying.\n>  \n> The log files have so far not shown anything conclusive: I got an ?Unknown auth strategy? error, but according to https://bugs.launchpad.net/python-neutronclient/+bug/1297309 this is a red herring.\n>  \n> Anyone else running into this problem or having solved it?\n>  \n> cheers\n> Jens-Christian\n> -- \n> SWITCH\n> Jens-Christian Fischer, Peta Solutions\n> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland\n> phone +41 44 268 15 15, direct +41 44 268 15 71\n> jens-christian.fischer at switch.ch\n> http://www.switch.ch\n> \n> http://www.switch.ch/stories\n>  \n> On 22.05.2014, at 16:19, Thomas Bernard <tbe at atolcd.com> wrote:\n> \n> \n> \n> Hi,\n> \n> I just finished my upgrade to icehouse, everything works just fine but... i can\'t delete my instances!\n> \n> When i delete instance (from cli or from horizon) : \n> \n> * The VM goes to \"deleting\"state\n> * Vm are destroy from KVM\n> * But nova list & horizon continue to display the \"deleting\" state\n> \n> Some time after, the Vm state goes to \"ERROR\" and in nova-compute.log i can see : \"Unauthorized: Unknown auth strategy\\n\" (from neutronclient)\n> \n> Any idea?\n> \n> Thx!\n> \n> \n> \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140714/2212e077/attachment.html>\n\n','<B3B005060931BB4B919D1F3F63AE36B31DFDDFF9@G2W2444.americas.hpqcorp.net>',NULL),('<002001cfbea4$7f51e060$7df5a120$@sina.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-23 15:33:13',28800,'2014-08-23 07:33:13',NULL,'[Openstack] How to config the Internet Accessing?','Hi,\n\n \n\nI\'m new to Openstack. Is there anyone can show me an simple step to config\nthe Internet Accessing?\n\nCurrently, I want the instance I created can be accessed (SSH) from external\nnetwork.\n\nProbably, for my understanding, I need to make my instance possess a\nfloating ip which is accessible to outside.\n\nBut I have no idea for the detail configuration steps.\n\n \n\nI would appreciate anyone\'s help.\n\n \n\nThanks!\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140823/51493c90/attachment.html>\n\n',NULL,NULL),('<002101cee5fa$b53f6ae0$1fbe40a0$@casey.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 06:13:36',-28800,'2013-11-20 14:13:36',NULL,'[openstack-dev] [Neutron] Race condition between DB layer and\n	plugin back-end implementation','Hi guys,\n\nNew to the discussion, so please correct if I\'m off base.\n\nif I understand correctly, the controllers handle the state/race-condition in a controller specify way.  So what we are talking about is a new state-flow for inside of the openstack db to describe the state of the network as known to openstack.   Is this correct?\nThanks,\njohn\n-----Original Message-----\nFrom: Isaku Yamahata [mailto:isaku.yamahata at gmail.com] \nSent: Wednesday, November 20, 2013 5:46 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Robert Kukura; Isaku Yamahata\nSubject: Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation\n\nOn Tue, Nov 19, 2013 at 08:59:38AM -0800, Edgar Magana <emagana at plumgrid.com> wrote:\n\n> Do you have in mind any implementation, any BP?\n> We could actually work on this together, all plugins will get the \n> benefits of a better implementation.\n\nYes, let\'s work together. Here is my blueprint (it\'s somewhat old.\nSo needs to be updated.)\nhttps://blueprints.launchpad.net/neutron/+spec/fix-races-of-db-based-plugin\nhttps://docs.google.com/file/d/0B4LNMvjOzyDuU2xNd0piS3JBMHM/edit\n\nAlthough I\'ve thought of status change(adding more status) and locking protocol so far, TaskFlow seems something to look at before starting and another possible approach is decoupling backend process from api call as Salvatore suggested like NVP plugin.\nEven with taskflow or decoupling approach, some kind of enhancing status change/locking protocol will be necessary for performance of creating many ports at once.\n\nthanks,\n\n> \n> Thanks,\n> \n> Edgar\n> \n> On 11/19/13 3:57 AM, \"Isaku Yamahata\" <isaku.yamahata at gmail.com> wrote:\n> \n> >On Mon, Nov 18, 2013 at 03:55:49PM -0500, Robert Kukura \n> ><rkukura at redhat.com> wrote:\n> >\n> >> On 11/18/2013 03:25 PM, Edgar Magana wrote:\n> >> > Developers,\n> >> > \n> >> > This topic has been discussed before but I do not remember if we \n> >> > have\n> >>a\n> >> > good solution or not.\n> >> \n> >> The ML2 plugin addresses this by calling each MechanismDriver \n> >> twice. The\n> >> create_network_precommit() method is called as part of the DB \n> >> transaction, and the create_network_postcommit() method is called \n> >> after the transaction has been committed. Interactions with devices \n> >> or controllers are done in the postcommit methods. If the \n> >> postcommit method raises an exception, the plugin deletes that \n> >> partially-created resource and returns the exception to the client. \n> >> You might consider a similar approach in your plugin.\n> >\n> >Splitting works into two phase, pre/post, is good approach.\n> >But there still remains race window.\n> >Once the transaction is committed, the result is visible to outside.\n> >So the concurrent request to same resource will be racy.\n> >There is a window after pre_xxx_yyy before post_xxx_yyy() where other \n> >requests can be handled.\n> >\n> >The state machine needs to be enhanced, I think. (plugins need\n> >modification)\n> >For example, adding more states like pending_{create, delete, update}.\n> >Also we would like to consider serializing between operation of ports \n> >and subnets. or between operation of subnets and network depending on \n> >performance requirement.\n> >(Or carefully audit complex status change. i.e.\n> >changing port during subnet/network update/deletion.)\n> >\n> >I think it would be useful to establish reference locking policy for \n> >ML2 plugin for SDN controllers.\n> >Thoughts or comments? If this is considered useful and acceptable, \n> >I\'m willing to help.\n> >\n> >thanks,\n> >Isaku Yamahata\n> >\n> >> -Bob\n> >> \n> >> > Basically, if concurrent API calls are sent to Neutron, all of \n> >> > them\n> >>are\n> >> > sent to the plug-in level where two actions have to be made:\n> >> > \n> >> > 1. DB transaction ? No just for data persistence but also to \n> >> > collect\n> >>the\n> >> > information needed for the next action 2. Plug-in back-end \n> >> > implementation ? In our case is a call to the\n> >>python\n> >> > library than consequentially calls PLUMgrid REST GW (soon SAL)\n> >> > \n> >> > For instance:\n> >> > \n> >> > def create_port(self, context, port):\n> >> >         with context.session.begin(subtransactions=True):\n> >> >             # Plugin DB - Port Create and Return port\n> >> >             port_db = super(NeutronPluginPLUMgridV2, \n> >> > self).create_port(context,\n> >> >               \n> >> port)\n> >> >             device_id = port_db[\"device_id\"]\n> >> >             if port_db[\"device_owner\"] == \"network:router_gateway\":\n> >> >                 router_db = self._get_router(context, device_id)\n> >> >             else:\n> >> >                 router_db = None\n> >> >             try:\n> >> >                 LOG.debug(_(\"PLUMgrid Library: create_port() \n> >> > called\")) # Back-end implementation\n> >> >                 self._plumlib.create_port(port_db, router_db)\n> >> >             except Exception:\n> >> >             ?\n> >> > \n> >> > The way we have implemented at the plugin-level in Havana (even \n> >> > in\n> >> > Grizzly) is that both action are wrapped in the same \"transaction\"\n> >>which\n> >> > automatically rolls back any operation done to its original state \n> >> > protecting mostly the DB of having any inconsistency state or \n> >> > left\n> >>over\n> >> > data if the back-end part fails.=.\n> >> > The problem that we are experiencing is when concurrent calls to \n> >> > the same API are sent, the number of operation at the plug-in \n> >> > back-end are long enough to make the next concurrent API call to \n> >> > get stuck at the\n> >>DB\n> >> > transaction level, which creates a hung state for the Neutron \n> >> > Server\n> >>to\n> >> > the point that all concurrent API calls will fail.\n> >> > \n> >> > This can be fixed if we include some \"locking\" system such as calling:\n> >> > \n> >> > from neutron.common import utile\n> >> > ?\n> >> > \n> >> > @utils.synchronized(\'any-name\', external=True) def \n> >> > create_port(self, context, port):\n> >> > ?\n> >> > \n> >> > Obviously, this will create a serialization of all concurrent \n> >> > calls which will ends up in having a really bad performance. Does \n> >> > anyone\n> >>has a\n> >> > better solution?\n> >> > \n> >> > Thanks,\n> >> > \n> >> > Edgar\n> >> > \n> >> > \n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org \n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> > \n> >> \n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >--\n> >Isaku Yamahata <isaku.yamahata at gmail.com>\n> \n> \n\n--\nIsaku Yamahata <isaku.yamahata at gmail.com>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20131120134613.GA8470@private.email.ne.jp>',NULL),('<002433C1-D4A6-4994-9F0B-FA4011F395A1@godaddy.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-24 01:10:47',0,'2014-12-24 01:10:47',NULL,'[openstack-dev] Hierarchical Multitenancy','+1 to Nova support for this getting in to Kilo.\n\nWe have a similar use case.  I?d really like to doll out quota on a department level, and let individual departments manage sub projects and quotas on their own.  I agree that HMT has limited value without Nova support.\n\nThanks!\nMike\n\n\nFrom: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, December 23, 2014 at 11:01 AM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] Hierarchical Multitenancy\n\nJoe,\n\nThanks? there seems to be good agreement on the spec and the matching implementation is well advanced with BARC so the risk is not too high.\n\nLaunching HMT with quota in Nova in the same release cycle would also provide a more complete end user experience.\n\nFor CERN, this functionality is very interesting as it allows the central cloud providers to delegate the allocation of quotas to the LHC experiments. Thus, from a central perspective, we are able to allocate N thousand cores to an experiment and delegate their resource co-ordinator to prioritise the work within the experiment. Currently, we have many manual helpdesk tickets with significant latency to adjust the quotas.\n\nTim\n\nFrom: Joe Gordon [mailto:joe.gordon0 at gmail.com]\nSent: 23 December 2014 17:35\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Hierarchical Multitenancy\n\n\nOn Dec 23, 2014 12:26 AM, \"Tim Bell\" <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:\n>\n>\n>\n> It would be great if we can get approval for the Hierachical Quota handling in Nova too (https://review.openstack.org/#/c/129420/).\n\nNova\'s spec deadline has passed, but I think this is a good candidate for an exception.  We will announce the process for asking for a formal spec exception shortly after new years.\n\n>\n>\n>\n> Tim\n>\n>\n>\n> From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com<mailto:morgan.fainberg at gmail.com>]\n> Sent: 23 December 2014 01:22\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] Hierarchical Multitenancy\n>\n>\n>\n> Hi Raildo,\n>\n>\n>\n> Thanks for putting this post together. I really appreciate all the work you guys have done (and continue to do) to get the Hierarchical Mulittenancy code into Keystone. It?s great to have the base implementation merged into Keystone for the K1 milestone. I look forward to seeing the rest of the development land during the rest of this cycle and what the other OpenStack projects build around the HMT functionality.\n>\n>\n>\n> Cheers,\n>\n> Morgan\n>\n>\n>\n>\n>\n>\n>>\n>> On Dec 22, 2014, at 1:49 PM, Raildo Mascena <raildom at gmail.com<mailto:raildom at gmail.com>> wrote:\n>>\n>>\n>>\n>> Hello folks, My team and I developed the Hierarchical Multitenancy concept for Keystone in Kilo-1 but What is Hierarchical Multitenancy? What have we implemented? What are the next steps for kilo?\n>>\n>> To answers these questions, I created a blog post http://raildo.me/hierarchical-multitenancy-in-openstack/\n>>\n>>\n>>\n>> Any question, I\'m available.\n>>\n>>\n>>\n>> --\n>>\n>> Raildo Mascena\n>>\n>> Software Engineer.\n>>\n>> Bachelor of Computer Science.\n>>\n>> Distributed Systems Laboratory\n>> Federal University of Campina Grande\n>> Campina Grande, PB - Brazil\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141224/9c85f149/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E501025E4E00@CERNXCHG43.cern.ch>',NULL),('<002701ceff20$1e4110a0$5ac331e0$@oceanearth-corp.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-22 23:14:25',32400,'2013-12-22 14:14:25',NULL,'[Openstack] A bug on OpenStack','Hi OpenStack experts,\n\n \n\nCould you please, help me out on this? I need your experts advice.\n\nI am trying to build VlanManager environment with OpenStack grizzly on Cent\nOS 6.4, but it doesn\'t work.\n\nI am using all-in-one architecture (single-host). FlatDHCPManager\nsuccessfully worked.\n\n \n\nSo, I am assuming that there is any bug/defect that VlanManager can\'t work\nwith single-host architecture.\n\nDoes anyone know if there is such a bug related to VlanManager on\nsingle-host architecture?\n\n \n\nAny pointer or letting me know anyone who is familiar with this would be\nhighly appreciated.\n\nThank you so much in advance,\n\n \n\n \n\nBird Kafka\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131222/17ef862d/attachment.html>\n\n',NULL,NULL),('<002701d033d5$fdcdfbd0$f969f370$@lcnpl.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-19 16:22:07',19800,'2015-01-19 10:52:07',NULL,'[Openstack] Some sample code snippets','Hi,\n\nWanted to share some Python code we wrote for our vEPC POC. Not very complex\n(I see people trying lot more stuff here). But when we tried to do it\ninitially, we couldn\'t find enough code samples, we had to actually read\nsome documentation J Thought this may help some beginners.\n\nWe use the Python APIs (Glance, Nova, Kombu).\n\nWhat can you find:\n\n-          Simple Glance and Nova client usage to query images and\ninstances, do some processing.\n\n-          A consumer to wait on neutron and nova notifications, using\ntemporary, dedicated queues\n\n-          Some processing of the messages to gather data of our interest.\n\n \n\nYou can find the code here:\n\n \n\nhttp://community.lcnpl.com/88/snippets-of-python-code-for-openstack-icehouse\n-integration\n\n \n\nIf anyone can help with these two questions, please reply here or through\nthe above site.\n\n1.       After we receive a neutron floating point assignment notification\nif we immediately query nova, we don\'t get the new floating IP address. It\ntakes a few seconds. Is this by design or can we avoid this delay?\n\n2.       We know that the json notifications can be processed more easily by\ngetting him to dump the data as a dictionary. If there is any sample code,\nit will help.\n\n \n\n \n\nRathnakumar Kayyar\n\nLCN\n\nhttp://www.lcnpl.com\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150119/03f11d05/attachment.html>\n\n',NULL,NULL),('<002801cf974e$78fc07e0$6af417a0$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-04 14:09:00',28800,'2014-07-04 06:09:00',NULL,'[Openstack] 答复:  [Ceilometer] Question regarding the meter \"cpu time used\"','Thanks a lot Piyush.  That helps a lot!\n\n \n\nI think delta counter makes more sense too.  In that way, the billing system\ncan simply query something like\n/v2/meters/cpu/statistics?groupby=resource_id and then the ?sum? value is\nthe ?total cpu time consumed? by each VM.  Otherwise, billing system needs\nto go through each and every cpu sample.\n\n \n\nThanks again~\n\n \n\n \n\n- Kurt Rao\n\n \n\n???: Piyush Masrani [mailto:pmasrani at vmware.com] \n????: 2014?7?4? 13:28\n???: openstack at lists.openstack.org\n??: Akhil Sadashiv Hingane; Kumar Gaurav\n??: RE: [Openstack] [Ceilometer] Question regarding the meter \"cpu time\nused\"\n\n \n\nHi Kurt,\n\n \n\nYour understanding is correct about the the \'cpu time used\' meter. It is a\ncumulative meter, ever increasing since boot-up and reset to zero on\nrestart. Vsphere does not support this meter. Details about meters supported\nby different hypervisors can be found at:\nhttp://docs.openstack.org/developer/ceilometer/measurements.html#compute-nov\na. \n\nYou can use \'cpu_util\' meter instead which is of type \'gauge\', if it\nsatisfies your requirement.\n\n \n\nPersonally, I think a \'delta\' counter will make more sense. However, you can\nderive the delta value by comparing two consecutive values for the\ncumulative meter and figuring out the difference.\n\n \n\nHope that helps.\n\n \n\nThanks,\n\nPiyush\n\n \n\nFrom: [mailto:raodingyuan at chinacloud.com.cn] \nSent: Thursday, July 03, 2014 3:15 PM\nTo: openstack at lists.openstack.org <mailto:openstack at lists.openstack.org> \nSubject: [Openstack] [Ceilometer] Question regarding the meter \"cpu time\nused\"\n\n \n\nHi folks,\n\n \n\nI found that the ?cpu time used? meter actually means ?cpu time used\n*since last boot-up*?, at least in libvirt environments. It will be reset\nto ZERO after VM restart. As far as I understand, a cumulative type meter\nshould be strictly increasing, so it looks very strange to me.\n\n \n\nMy questions are:\n\n1, Since I have libvirt environment only, I haven?t tested on vsphere or\nany others. Does it behave the same in other environments?\n\n2, Is it intended to be like this?\n\n2, What should a billing system do to correctly use this meter?\n\n \n\nPlease help :)\n\n \n\nThanks a lot!\n\n \n\n \n\nKurt Rao\n\nChinaCloud Information Technology Co., Ltd.\n\nE_mail:  <mailto:raodingyuan at chinacloud.com.cn>\nraodingyuan at chinacloud.com.cn\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140704/139f337b/attachment.html>\n\n',NULL,NULL),('<002c01ceff20$5b832200$12896600$@oceanearth-corp.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-12-22 23:16:07',32400,'2013-12-22 14:16:07',NULL,'[Openstack-operators] A bug on OpenStack','Hi OpenStack experts,\n\n \n\nCould you please, help me out on this? I need your experts advice.\n\nI am trying to build VlanManager environment with OpenStack grizzly on Cent\nOS 6.4, but it doesn\'t work.\n\nI am using all-in-one architecture (single-host). FlatDHCPManager\nsuccessfully worked.\n\n \n\nSo, I am assuming that there is any bug/defect that VlanManager can\'t work\nwith single-host architecture.\n\nDoes anyone know if there is such a bug related to VlanManager on\nsingle-host architecture?\n\n \n\nAny pointer or letting me know anyone who is familiar with this would be\nhighly appreciated.\n\nThank you so much in advance,\n\n \n\n \n\nBird Kafka\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131222/726f7b5b/attachment.html>\n\n',NULL,NULL),('<002c01cfc32b$44551370$ccff3a50$@neusoft.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-29 09:47:42',28800,'2014-08-29 01:47:42',NULL,'[Openstack] 答复:  Launch of a instance failed',' \n\nCompute node do not support  QEMU hypervisor from Juno. So, you should not deploy a compute node on  VM.\n\n \n\nGuo Jinwei\n\n \n\n \n\n???: Nikesh Kumar Mahalka [mailto:nikeshmahalka at vedams.com] \n????: 2014?8?29? 2:22\n???: openstack at lists.openstack.org\n??: [Openstack] Launch of a instance failed\n\n \n\nHi i am deploying a devstack juno on ubuntu 14.04 server virtual machine.\n\nAfter installation,when i am trying to launch a instance,its failed.\n\nI am getting \"host not found\" error.\n\nBelow is part of /opt/stack/logs/screen/screen-n-cond.log\n\n \n\n \n\nBelow is ther error\n\n2014-08-28 23:44:59.448 ERROR nova.scheduler.utils [req-6f220296-8ec2-4e49-821d-0d69d3acc315 admin admin] [instance: 7f105394-414c-4458-b1a1-6f37d6cff87a] Error from last host: juno-devstack-server (node juno-devstack-server): [u\'Traceback (most recent call last):\\n\', u\'  File \"/opt/stack/nova/nova/compute/manager.py\", line 1932, in do_build_and_run_instance\\n    filter_properties)\\n\', u\'  File \"/opt/stack/nova/nova/compute/manager.py\", line 2067, in _build_and_run_instance\\n    instance_uuid=instance.uuid, reason=six.text_type(e))\\n\', u\'RescheduledException: Build of instance 7f105394-414c-4458-b1a1-6f37d6cff87a was re-scheduled: not all arguments converted during string formatting\\n\']\n\n \n\n \n\n \n\n \n\n \n\n \n\n \n\nRegards\n\nNikesh\n\n \n\n---------------------------------------------------------------------------------------------------\nConfidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) \nis intended only for the use of the intended recipient and may be confidential and/or privileged of \nNeusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is \nnot the intended recipient, unauthorized use, forwarding, printing,  storing, disclosure or copying \nis strictly prohibited, and may be unlawful.If you have received this communication in error,please \nimmediately notify the sender by return e-mail, and delete the original message and all copies from \nyour system. Thank you. \n---------------------------------------------------------------------------------------------------\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140829/c282486f/attachment.html>\n\n','<CAKj7oBw=qpZZ+pPNVsEEQAZHNSEd-yMb90+40LR3SCbNdvhtKA@mail.gmail.com>',NULL),('<002e01cefbd3$374e6980$a5eb3c80$@samsung.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 18:26:22',32400,'2013-12-18 09:26:22',NULL,'[openstack-dev] [Heat] hybrid cloud & bursting question','Hi, stackers,\n\nI know only little about Heat, and I can\'t wholly follow recent \ndiscussions around multi-region support in this mailing list.\nPlease help me understand the roadmap or plan about hybrid cloud \nand \"bursting\" in particular. \n\nI\'d like to ask the following questions to the developers who have \nthe same interests.\n\n1) Can we use Heat to deploy to the AWS using the same template\n   as in the OpenStack cloud?\n\n2) Will Heat support \"bursting\" when multi-region is supported?\n   (i.e., auto scaling from the private cloud to the public cloud)\n\nIf these are not prepared in the Icehouse release, is it possible \nin the J-release? Who\'s interested in these? Will it be able to \nburst into Rackspace cloud or HP cloud using HOT within next year?\n\nWe\'re also considering the development of the related features \nif possible and want to know how to be involved step by step.\n\nThanks in advance,\nJoonwon Lee, Samsung SDS\n\n\n\n\n',NULL,NULL),('<002E300A-3F29-4284-A32D-FAFBC199F369@doughellmann.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-08 11:18:35',-14400,'2014-09-08 15:18:35',NULL,'[Openstack] is anyone using zeromq for RPC?','\nOn Sep 8, 2014, at 10:35 AM, Antonio Messina <antonio.s.messina at gmail.com> wrote:\n\n> Hi All,\n> \n> We tested briefly ZeroMQ with Havana last year, but we couldn\'t find\n> any good documentation on how to implement it, and we were not able to\n> get it working. We also got the impression that the support was not at\n> all mature, so we decided to use RabbitMQ instead.\n> \n> However, I must say that the broker-less design of ZeroMQ is very\n> appealing, and we would like to give it a try, assuming\n> 1) the documentation is improved\n> 2) there is some assurance that support for ZeroMQ is not going to be dropped.\n> \n> I can help with 1) if there is someone that knows a bit of the\n> internals and can bootstrap me, because I have no first hand\n> experience on how message queues are used in OpenStack, and little\n> experience with ZeroMQ.\n\nUnfortunately, the existing Oslo team doesn?t have a lot of experience with ZeroMQ either (hence this thread). It sounds like Li Ma?s team has made it work, though, so maybe you could work together. We should prioritize documentation and then functional testing, I think.\n\n> \n> About 2), well this is a decision for the developers, but IMHO there\n> *should* be support for ZeroMQ in OpenStack: its broker-less\n> architecture would eliminate a SPoF (the message broker), could ease\n> the deployment (especially in HA setup) and grant very high\n> performance.\n\nI agree, it would be useful to support it. This is purely a resource allocation problem for me. I don\'t have anyone willing to do the work needed to ensure the driver is functional and can be deployed sanely (although maybe I?ve found a couple of volunteers now :-).\n\nThere is another effort going on to support AMQP 1.0, which (as I understand it) includes similar broker-less deployment options. Before we decide whether to invest in ZeroMQ for that reason alone, it would be useful to know if AMQP 1.0 support makes potential ZeroMQ support less interesting.\n\nDoug\n\n> \n> My 2 cents...\n> \n> Antonio Messina\n> \n> -- \n> antonio.s.messina at gmail.com\n> antonio.messina at uzh.ch                     +41 (0)44 635 42 22\n> S3IT: Service and Support for Science IT   http://www.s3it.uzh.ch/\n> University of Zurich\n> Winterthurerstrasse 190\n> CH-8057 Zurich Switzerland\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<CA+jNneB2p-UsbtDP0yvPsC2dEVpGK9sF4dJC36WJ+mXqRuHy-Q@mail.gmail.com>',NULL),('<002EC2F8-88F2-422A-87FA-99289C1DA2CC@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 06:52:43',-18000,'2012-10-11 11:52:43',NULL,'[OpenStack Foundation] Board meeting minutes before the Summit?','The approved minutes are in the wiki now:\n\nhttp://wiki.openstack.org/Governance/Foundation/Aug2012BoardMinutes\nhttp://wiki.openstack.org/Governance/Foundation/07Sept2012BoardMinutes\n\n\n\nOn Oct 10, 2012, at 1:27 AM, Vincent Untz wrote:\n\n> Hi,\n> \n> Unless I missed them, I haven\'t seen minutes of any of the meetings\n> published so far.\n> \n> I know we already had a thread about this a month ago, but it\'d be great\n> to have public minutes of all meetings that happened before the Summit;\n> the Summit is a nice opportunity for members to talk to the board, and\n> having the latest news is kind of nice for that :-)\n> \n> Cheers,\n> \n> Vincent\n> \n> -- \n> Les gens heureux ne sont pas press?s.\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121011/50e61b4f/attachment.html>\n\n','<20121010062745.GV16368@vuntz.net>',NULL),('<003101cea001$cf20ae40$6d620ac0$@onesource.pt>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-23 14:08:06',3600,'2013-08-23 13:08:06',NULL,'[Openstack] Designate /DnsaaS','Hi Kiall\n\nGood news then, work in progress. \nIn that case I will continue to explore DESIGNATE with HTTP client or Curl.\n\nThanks a lot\nCheers\n\nClaudio Marques\n	\n-----Mensagem original-----\nDe: Mac Innes, Kiall [mailto:kiall at hp.com] \nEnviada: 23 de agosto de 2013 13:26\nPara: claudio\nCc: \'Simon McCartney\'; openstack at lists.openstack.org\nAssunto: Re: [Openstack] Designate /DnsaaS\n\nHey Cl?udio,\n\nYes and No .. There is a fork of Horizon[1] where we have really basic\nintegration (Create, List, Delete domains - No support for records etc)\n\nOnce we get this a little more complete, We we\'re going to figure out how to\nmake it an actual horizon plugin rather than a fork :)\n\nThanks,\nKiall\n\n[1]: https://github.com/moniker-dns/horizon/\n\nOn 23/08/13 13:04, claudio wrote:\n> Hello guys\n> \n> I appreciate your help with DESIGNATE and your patience.\n> \n> Is there any plugin to integrate designate in Horizon?\n> \n> Cheers\n> \n> Cl?udio Marques\n> \n> claudio at onesource.pt\n> \n> http://www.onesource.pt/\n> \n> *De:*Simon McCartney [mailto:simon at mccartney.ie]\n> *Enviada:* 22 de agosto de 2013 18:37\n> *Para:* claudio at onesource.pt\n> *Assunto:* Re: [Openstack] Designate /DnsaaA\n> \n> Do you mean in conjunction with the notifications sink (where records \n> are created or deleted in response to instance create/delete events) \n> in which case the domain to be used is set in the designate.conf file, \n> and is global, not currently configurable per tenant.\n> \n> On 22 August 2013 17:05, <claudio at onesource.pt\n<mailto:claudio at onesource.pt>> wrote:\n> \n> Hi Stackers\n> \n> Is there anyone that have some experience with designate?\n> \n> I can create domains servers and records but I am a bit stuck. How can \n> allocate a domain to a specific Tenant/project?\n> \n> Can anyone help-me in this?\n> \n> Thank\'s\n> Cheers\n> \n> Claudio Marques\n> \n> claudio at onesource.pt <mailto:claudio at onesource.pt> \n> http://www.onesource.pt/\n> \n> \n> _______________________________________________\n> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n<mailto:openstack at lists.openstack.org>\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n> --\n> \n> Simon McCartney\n> \n> E: simon at mccartney.ie <mailto:simon at mccartney.ie>\n> \n> M: +44 7710 836915\n> \n> _______________________________________________\n> \n> Claudio,\n> \n> Hey, maybe I am not understanding your question, but whatever tenant \n> you are using to create domains and domain records, that is the one \n> allocated to that tenant.\n> \n> Regards,\n> \n> Patrick\n> \n> _______________________________________________\n> \n> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n<mailto:openstack at lists.openstack.org>\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n\n','<2CA92712C6DFEB4D8C2818165644367124DE46A9@G9W0341.americas.hpqcorp.net>',NULL),('<003101ceff20$8bbba550$a332eff0$@oceanearth-corp.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-22 23:17:28',32400,'2013-12-22 14:17:28',NULL,'[openstack-community] A bug on OpenStack','Hi OpenStack experts,\n\n \n\nCould you please, help me out on this? I need your experts advice.\n\nI am trying to build VlanManager environment with OpenStack grizzly on Cent\nOS 6.4, but it doesn\'t work.\n\nI am using all-in-one architecture (single-host). FlatDHCPManager\nsuccessfully worked.\n\n \n\nSo, I am assuming that there is any bug/defect that VlanManager can\'t work\nwith single-host architecture.\n\nDoes anyone know if there is such a bug related to VlanManager on\nsingle-host architecture?\n\n \n\nAny pointer or letting me know anyone who is familiar with this would be\nhighly appreciated.\n\nThank you so much in advance,\n\n \n\n \n\nBird Kafka\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131222/bd15d24a/attachment.html>\n\n',NULL,NULL),('<003201cfc127$bf8eb600$3eac2200$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-26 19:17:44',25200,'2014-08-26 12:17:44',NULL,'[Openstack] No IP addresses through DHCP because DHCP port down?','Hello\n\n \n\nThe instances I create doesn\'t get an IP address. I can see the request on\nthe neutron node but the DHCP server is not answering.\n\n \n\nNeutron successfully creates ports for the instances, the ports are up and\nworking as expected. \n\nThe dhcp port is also created but with the status: DOWN and binding:vif_type\nis binding_failed.\n\nPlease see here: http://pastebin.com/E1Xx1pNw\n\n \n\nHow could it be binding_faild when the port is already created. \n\nWhat is also strange in a different Icehouse installation the tag of the\ndhcp port is \"1\" in this one its \"4095\".\n\n \n\nThanks for any help!\n\nChristoph\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140826/16183990/attachment.html>\n\n',NULL,NULL),('<0032A43F-9C3E-48B5-94E8-8476C76883DC@egon.cc>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-07 03:57:45',-28800,'2015-01-07 11:57:45',NULL,'[Openstack] NSX plug-in configuration on SLES','\nOn Jan 7, 2015, at 1:08 AM, varun bhatnagar <varun292006 at gmail.com> wrote:\n\n> I am deploying OpenStack (Juno) on SLES-11.3 and want to use VMware as hypervisor instead of QEMU/KVM.\n> I was going through the documentation \n> http://docs.openstack.org/admin-guide-cloud/content/nsx_plugin.html and I could not find a way to install \"neutron-plugin-vmware\" on SLES. Can anyone please tell me how can I install this and proceed with the configuration on SLES?\n\nI did a quick search, and found this: https://www.suse.com/documentation/suse_cloud3/singlehtml/book_cloud_deploy/book_cloud_deploy.html\n\nIt has a section under neutron that talks about VMWare. It might be helpful overall.\n\nCheers,\n-j\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150107/10d81cc5/attachment.html>\n\n','<CAGxOggEPh3Sre4wgYmtMRMCSS_NMz1u0vwS786b8Z+1JPFnpaw@mail.gmail.com>',NULL),('<003301cea01d$b3ba4d70$1b2ee850$@onesource.pt>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-23 17:27:46',3600,'2013-08-23 16:27:46',NULL,'[Openstack] Designate /DnsaaS','Thank you so much for your help.\n\nI just have one question. I\'ve already created a server, a domain and a  \"A\"\nrecord, then I used the Google\'s IP for this record. I  ping  this record\nand nothing appends. Am I doing something wrong?\n\nJust for a better explanation, this is what I have done so far:\n\nWith the HTTP client from google\n\nCreated a server:\n\nHost: example.com\nAccept: application/json\nContent-Type: application/json\n\n{\n  \"name\": \"ns1.example.org.\"\n}\nresponse is :\n\n{\n\n\"servers\":[\n{\n	\"created_at\":\"2013-08-22T22:04:59.774331\",\n	\"updated_at\":null,\n	\"name\":\"ns1.exemplo.org.\",\n	\"id\":\"42368625-8691-47ec-9219-47b000cc04ac\"\n}\n]\n}\n\nNow I created a domain\n\nHost: example.com\nAccept: application/json\nContent-Type: application/json\n\n{\n	  \"name\": \"domain1.com.\",\n 	 \"ttl\": 3600,\n  	\"email\": \"nsadmin at example.org\"\n}\nResponse \n\n{\n\n\"domains\":[\n    {\n	\"description\":null,\n	\"created_at\":\"2013-08-22T22:09:15.322631\",\n	\"updated_at\":\"2013-08-22T23:27:11.736447\",\n	\"email\":\"nsadmin at example.org\",\n	\"ttl\":3600,\n	\"serial\":1377214031,\n	\"id\":\"bb72b2e7-75b6-4d18-b8f8-b13c5e5da8ae\",\n	\"name\":\"domain1.com.\"\n    }\n]\n}\n\nFinally a Record\n\nHost: example.com\nAccept: application/json\nContent-Type: application/json\n\n{\n  \"name\": \"www.example.com.\",\n  \"type\": \"A\",\n  \"data\": \"74.125.224.72\"\n}\nResponse:\n\n{\n\n\"records\":[\n{\n	\"name\":\"www.domain1.com.\",\n	\"data\":\"74.125.224.72\",\n	\"created_at\":\"2013-08-22T23:27:11.655047\",\n	\"updated_at\":null,\n	\"id\":\"c1789964-0d7d-4b1f-b0f2-af1e109500de\",\n	\"priority\":null,\n	\"ttl\":null,\n	\"type\":\"A\",\n	\"domain_id\":\"bb72b2e7-75b6-4d18-b8f8-b13c5e5da8ae\",\n	\"description\":null\n    \n}\n]\n}\n\n\n\nIf I ping www.domain1.com. should\'t ping Google?\n\nThis ping is from the machine that as DESIGNATE installed. Should\'t in\ntheory DESIGNATE resolve  this Record?\n\nProbably Someting is missing me here.\n\n\n\nThank you for you enormous patience.\n\n\n\nCheers\n\n\nClaudio Marques\n\nclaudio at onesource.pt\n\nhttp://www.onesource.pt/\n\n\n-----Mensagem original-----\nDe: Mac Innes, Kiall [mailto:kiall at hp.com] \nEnviada: 23 de agosto de 2013 16:50\nPara: claudio\nCc: openstack at lists.openstack.org\nAssunto: Re: [Openstack] Designate /DnsaaS\n\nThere is also the CLI -\nhttps://github.com/stackforge/python-designateclient/\n\nThanks,\nKiall\n\nOn 23/08/13 14:08, claudio wrote:\n> Hi Kiall\n> \n> Good news then, work in progress. \n> In that case I will continue to explore DESIGNATE with HTTP client or\nCurl.\n> \n> Thanks a lot\n> Cheers\n> \n> Claudio Marques\n> 	\n> -----Mensagem original-----\n> De: Mac Innes, Kiall [mailto:kiall at hp.com]\n> Enviada: 23 de agosto de 2013 13:26\n> Para: claudio\n> Cc: \'Simon McCartney\'; openstack at lists.openstack.org\n> Assunto: Re: [Openstack] Designate /DnsaaS\n> \n> Hey Cl?udio,\n> \n> Yes and No .. There is a fork of Horizon[1] where we have really basic \n> integration (Create, List, Delete domains - No support for records \n> etc)\n> \n> Once we get this a little more complete, We we\'re going to figure out \n> how to make it an actual horizon plugin rather than a fork :)\n> \n> Thanks,\n> Kiall\n> \n> [1]: https://github.com/moniker-dns/horizon/\n> \n> On 23/08/13 13:04, claudio wrote:\n>> Hello guys\n>>\n>> I appreciate your help with DESIGNATE and your patience.\n>>\n>> Is there any plugin to integrate designate in Horizon?\n>>\n>> Cheers\n>>\n>> Cl?udio Marques\n>>\n>> claudio at onesource.pt\n>>\n>> http://www.onesource.pt/\n>>\n>> *De:*Simon McCartney [mailto:simon at mccartney.ie]\n>> *Enviada:* 22 de agosto de 2013 18:37\n>> *Para:* claudio at onesource.pt\n>> *Assunto:* Re: [Openstack] Designate /DnsaaA\n>>\n>> Do you mean in conjunction with the notifications sink (where records \n>> are created or deleted in response to instance create/delete events) \n>> in which case the domain to be used is set in the designate.conf \n>> file, and is global, not currently configurable per tenant.\n>>\n>> On 22 August 2013 17:05, <claudio at onesource.pt\n> <mailto:claudio at onesource.pt>> wrote:\n>>\n>> Hi Stackers\n>>\n>> Is there anyone that have some experience with designate?\n>>\n>> I can create domains servers and records but I am a bit stuck. How \n>> can allocate a domain to a specific Tenant/project?\n>>\n>> Can anyone help-me in this?\n>>\n>> Thank\'s\n>> Cheers\n>>\n>> Claudio Marques\n>>\n>> claudio at onesource.pt <mailto:claudio at onesource.pt> \n>> http://www.onesource.pt/\n>>\n>>\n>> _______________________________________________\n>> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n> <mailto:openstack at lists.openstack.org>\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>> --\n>>\n>> Simon McCartney\n>>\n>> E: simon at mccartney.ie <mailto:simon at mccartney.ie>\n>>\n>> M: +44 7710 836915\n>>\n>> _______________________________________________\n>>\n>> Claudio,\n>>\n>> Hey, maybe I am not understanding your question, but whatever tenant \n>> you are using to create domains and domain records, that is the one \n>> allocated to that tenant.\n>>\n>> Regards,\n>>\n>> Patrick\n>>\n>> _______________________________________________\n>>\n>> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n> <mailto:openstack at lists.openstack.org>\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n> \n> \n\n\n\n','<2CA92712C6DFEB4D8C2818165644367124DE4CAD@G9W0341.americas.hpqcorp.net>',NULL),('<00333e1e615548bafbabf7a8c7344ae5@kaplonski.pl>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 10:04:39',7200,'2014-10-01 08:04:39',NULL,'[openstack-dev] [Openstack] Glance on swift problem','Hello,\n\nW dniu 2014-09-30 20:28, Timur Nurlygayanov napisa?(a):\n> Hi Slawek,\n> \n> we faced the same error and this is issue with Swift.\n> We can see 100% disk usage on the Swift node during the file upload\n> and looks like Swift can\'t send info about status of the file loading\n> in time.\n> \n> On our environments we found the workaround for this issue:\n> \n> 1. Set? swift_store_large_object_size = 200 in glance.conf.\n\nI have it set to 1024 - should it be lower? Value which I have is too \nbig now?\n\n> \n> 2. Add to Swift proxy-server.conf:\n> \n> [DEFAULT]\n>  ...\n>  node_timeout = 90\n> \n> Probably we can set this value as default value for this parameter\n> instead of \'30\'?\n> \n> Regards,\n> \n> Timur\n> \n> On Tue, Sep 30, 2014 at 7:41 PM, S?awek Kap?o?ski\n> <slawek at kaplonski.pl> wrote:\n> \n>> Hello,\n>> \n>> I can\'t find that upload from was previous logs but I now try to\n>> upload same image once again. In glance there was exactly same\n>> error. In swift logs I have:\n>> \n>> Sep 30 17:35:10 127.0.0.1 proxy-server X.X.X.X Y.Y.Y.Y\n>> 30/Sep/2014/15/35/10 HEAD\n>> /v1/AUTH_7ef5a7661ccd4c069e3ad387a6dceebd/glance HTTP/1.0 204\n>> Sep 30 17:35:16 127.0.0.1 proxy-server X.X.X.X Y.Y.Y.Y\n>> 30/Sep/2014/15/35/16 PUT\n>> \n> /v1/AUTH_7ef5a7661ccd4c069e3ad387a6dceebd/glance/fa5dfe09-74f5-4287-9852-d2f1991eebc0-00001\n>> HTTP/1.0 201 - -\n>> \n>> Best regards\n>> Slawek Kaplonski\n>> \n>> W dniu 2014-09-30 17:03, Kuo Hugo napisa?(a):\n>> \n>> Hi ,\n>> \n>> Could you please post the log of related requests in Swift\'s log\n>> ???\n>> \n>> Thanks // Hugo\n>> \n>> 2014-09-30 22:20 GMT+08:00 S?awek Kap?o?ski\n>> <slawek at kaplonski.pl>:\n>> \n>> Hello,\n>> \n>> I\'m using openstack havana release and glance with swift backend.\n>> Today I found that I have problem when I create image with url in\n>> \"--copy-from\" when image is bigger than my\n>> \"swift_store_large_object_size\" because then glance is trying to\n>> split image to chunks with size given in\n>> \"swift_store_large_object_chunk_size\" and when try to upload first\n>> chunk to swift I have error:\n>> \n>> 2014-09-30 15:05:29.361 18023 ERROR glance.store.swift [-] Error\n>> during chunked upload to backend, deleting stale chunks\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift Traceback\n>> (most recent call last):\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?File\n>> \"/usr/lib/python2.7/dist-packages/glance/store/swift.py\", line 384,\n>> in add\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?\n>> ?content_length=content_length)\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?File\n>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line\n>> 1234,\n>> in put_object\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?\n>> ?response_dict=response_dict)\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?File\n>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line\n>> 1143,\n>> in _retry\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?\n>> ?reset_func(func, *args, **kwargs)\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ?File\n>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line\n>> 1215,\n>> in _default_reset\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift? ? ?%\n>> (container, obj))\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n>> ClientException: put_object(\'glance\',\n>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n>> ability to reset contents for reupload.\n>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n>> 2014-09-30 15:05:29.362 18023 ERROR glance.store.swift [-] Failed\n>> to add object to Swift.\n>> Got error from Swift: put_object(\'glance\',\n>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n>> ability to reset contents for reupload.\n>> 2014-09-30 15:05:29.362 18023 ERROR glance.api.v1.upload_utils [-]\n>> Failed to upload image 9f56ccec-deeb-4020-95ba-ca7bf1170056\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n>> Traceback (most recent call last):\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils?\n>> ?File\n>> \"/usr/lib/python2.7/dist-packages/glance/api/v1/upload_utils.py\",\n>> line 101, in upload_data_to_store\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils? ?\n>> ?store)\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils?\n>> ?File \"/usr/lib/python2.7/dist-packages/glance/store/__init__.py\",\n>> line 333, in store_add_to_backend\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils? ?\n>> ?(location, size, checksum, metadata) = store.add(image_id, data,\n>> size)\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils?\n>> ?File \"/usr/lib/python2.7/dist-packages/glance/store/swift.py\",\n>> line 447, in add\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils? ?\n>> ?raise glance.store.BackendException(msg)\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n>> BackendException: Failed to add object to Swift.\n>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils Got\n>> error from Swift: put_object(\'glance\',\n>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n>> ability to reset contents for reupload.\n>> \n>> Does someone of You got same error and know what is solution of it?\n>> I was searching about that in google but I not found anything what\n>> could solve my problem.\n>> \n>> --\n>> Best regards\n>> S?awek Kap?o?ski\n>> slawek at kaplonski.pl\n>> \n>> _______________________________________________\n>> Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n>> [1]\n>> Post to? ? ?: openstack at lists.openstack.org\n>> Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n>> [1]\n>> \n>> Links:\n>> ------\n>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> [1]\n> \n>  --\n>  Pozdrawiam\n>  S?awek Kap?o?ski\n>  slawek at kaplonski.pl\n> \n>  _______________________________________________\n>  Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n>  Post to? ? ?: openstack at lists.openstack.org\n>  Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n> \n>  _______________________________________________\n>  OpenStack-dev mailing list\n>  OpenStack-dev at lists.openstack.org\n>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]\n> \n> --\n> \n> Timur,\n> QA Engineer\n> OpenStack Projects\n> Mirantis Inc\n> \n> Links:\n> ------\n> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nPozdrawiam\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\n\n','<CAHCYybPGcD3fGMec=5Umuak1Fr=PW6kR=bW5QeE+_cKPJKxDVg@mail.gmail.com>',NULL),('<003b01cfd4b5$f73c3180$e5b49480$@org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-20 11:32:10',7200,'2014-09-20 09:32:10',NULL,'[openstack-dev] [Neutron][QoS] Applying QoS as Quota','Kevin,\nI\'m aware of the blueprint. Actually I\'ve tried to make it work, but the\nrules are not applied to the OVS bridge.\nMoreover there are these limitations:\n1. it considers only dscp and rate limit\n2. it doesn\'t introduce a way to manage these policy (i.e. from the admin\nside)\nAnyway it\'s a good starting point. I hope it will be extended (not sure\nwhether the incubation proposal passed or not).\n\nGiuseppe\n\n> -----Original Message-----\n> From: Kevin Benton [mailto:blak111 at gmail.com]\n> Sent: 20 September 2014 01:46\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n> \n> Sorry, forgot to include a link.\n> https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api\n> \n> On Fri, Sep 19, 2014 at 4:45 PM, Kevin Benton <blak111 at gmail.com> wrote:\n> > Well there is the QoS work that has been pushed to incubation or Kilo.\n> >\n> > On Fri, Sep 19, 2014 at 1:40 PM, Carlino, Chuck <chuck.carlino at hp.com>\n> wrote:\n> >> I\'m in HP, but not in the group that owns this effort, so I don\'t\nknow what\n> its status is.  There is a havana-based implementation floating around\n> somewhere inside HP.  I\'ll ask around to see what I can find out.\n> >>\n> >> I\'m pretty sure there\'s nothing going on in the community.\n> >>\n> >> Chuck\n> >>\n> >> On Sep 19, 2014, at 5:28 AM, Giuseppe Cossu\n<giuseppe.cossu at create-net.org>\n> wrote:\n> >>\n> >>> Chuck,\n> >>> It seems quite interesting! Are hp or community working to implement\nit?\n> >>>\n> >>> Giuseppe\n> >>>\n> >>>> -----Original Message-----\n> >>>> From: Carlino, Chuck [mailto:chuck.carlino at hp.com]\n> >>>> Sent: 19 September 2014 04:52\n> >>>> To: OpenStack Development Mailing List (not for usage questions)\n> >>>> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n> >>>>\n> >>>> When you say \'associate to VMs\', that would be associating to\n> >>>> neutron\n> >>> ports,\n> >>>> right?  If so, this is a subset of what is in:\n> >>>>\n> >>>>\n> >>> https://blueprints.launchpad.net/neutron/+spec/neutron-port-template\n> >>> -frame\n> >>> work\n> >>>>\n> >>> https://blueprints.launchpad.net/neutron/+spec/neutron-port-template\n> >>> -polic\n> >>> y\n> >>>>\n> >>>> which also include things like bandwidth guarantees and security\npolicy.\n> >>> I\'m\n> >>>> not sure if anyone is pursuing these right now, but there may be\n> >>>> some\n> >>> useful\n> >>>> ideas in there.\n> >>>>\n> >>>> Chuck\n> >>>>\n> >>>>\n> >>>> On Sep 18, 2014, at 4:25 PM, Giuseppe Cossu <giuseppe.cossu at create-\n> >>>> net.org<mailto:giuseppe.cossu at create-net.org>> wrote:\n> >>>>\n> >>>> Hello,\n> >>>> I\'m aware it\'s not so easy to define a solution, so I\'ll expose my\nidea.\n> >>>> I was thinking about a \"network flavor\" that a tenant can associate\n> >>>> to\n> >>> VMs.\n> >>>> Basically the network flavour is a QoS policy.\n> >>>> The admin can define the network flavors (Gold, Silver, ... call it\n> >>>> as\n> >>> you\n> >>>> want) with a set of parameters (some visible to user, some not).\n> >>>> If we define this kind of flavours, a related quota should be\n> >>>> define to\n> >>> keep\n> >>>> track the network resources.\n> >>>>\n> >>>> Giuseppe\n> >>>>\n> >>>> From: Veiga, Anthony\n> >>>> [mailto:Anthony_Veiga at cable.comcast.com<http://cable.comcast.com>]\n> >>>> Sent: 10 September 2014 15:11\n> >>>> To: OpenStack Development Mailing List (not for usage questions)\n> >>>> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n> >>>>\n> >>>>\n> >>>>\n> >>>> Using the quota system would be a nice option to have.\n> >>>>\n> >>>> Can you clarify what you mean by cumulative bandwidth for the\n> >>>> tenant? It\n> >>> would\n> >>>> be possible to rate limit at the tenant router, but having a\n> >>>> cumulative\n> >>> limit\n> >>>> enforced inside of a tenant would be difficult.\n> >>>>\n> >>>> On Wed, Sep 10, 2014 at 1:03 AM, Giuseppe Cossu\n> >>>> <giuseppe.cossu at create-\nnet.org<mailto:giuseppe.cossu at create-net.org>>\n> wrote:\n> >>>>\n> >>>> Hello everyone,\n> >>>>\n> >>>> Looking at the QoS blueprint (proposed for incubation), I suggest\n> >>>> to\n> >>> consider\n> >>>> adding some parameters to Neutron Quotas. Let\'s suppose using\n> >>>> rate-limit\n> >>> for\n> >>>> managing QoS. The quota parameters could be such as rate_limit (per\n> >>> port) and\n> >>>> max_bandwidth (per tenant). In this way it is possible to\n> >>>> set/manage QoS quotas from the admin side, and for instance set the\n> >>>> maximum bandwidth\n> >>> allowed\n> >>>> per tenant (cumulative).\n> >>>>\n> >>>> What do you think about it?\n> >>>>\n> >>>> I\'m cautious about this.  We\'d either need to allow a \"Number of\n> >>>> DSCP settings\" and set them outside the quota or leave it out\naltogether.\n> >>> Let\'s\n> >>>> not forget that there\'s more than just rate limiting in QoS, and we\n> >>>> need\n> >>> to\n> >>>> make sure all the options are included.  Otherwise, there\'s going\n> >>>> to be\n> >>> a lot\n> >>>> of user and operator confusion as to what is and isn\'t considered\n> >>>> part\n> >>> of the\n> >>>> quota.\n> >>>> -Anthony\n> >>>>\n> >>>> Regards,\n> >>>> Giuseppe\n> >>>>\n> >>>> --------------------------------------------------------\n> >>>> Giuseppe Cossu\n> >>>> CREATE-NET\n> >>>> --------------------------------------------------------\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>>\n> >>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.opensta\n> >>> ck.org\n> >>>>\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>>\n> >>>> --\n> >>>> Kevin Benton\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>>\n> >>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.opensta\n> >>> ck.org\n> >>>>\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > --\n> > Kevin Benton\n> \n> \n> \n> --\n> Kevin Benton\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAO_F6JPf=ayptUJrY3ov4=qM1qph9yvoxbpcTavi1cyDN59idA@mail.gmail.com>',NULL),('<00452068-C611-45E5-9D11-7A22861AC89E@a10networks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 09:40:29',0,'2014-11-17 09:40:29',NULL,'[openstack-dev] [neutron] L2 gateway as a service','\n> On Nov 17, 2014, at 9:13 AM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n> \n> Hi\n> \n> On Fri, Nov 14, 2014 at 6:26 PM, Armando M. <armamig at gmail.com> wrote:\n>> Last Friday I recall we had two discussions around this topic. One in the\n>> morning, which I think led to Maruti to push [1]. The way I understood [1]\n>> was that it is an attempt at unifying [2] and [3], by choosing the API\n>> approach of one and the architectural approach of the other.\n>> \n>> [1] https://review.openstack.org/#/c/134179/\n>> [2] https://review.openstack.org/#/c/100278/\n>> [3] https://review.openstack.org/#/c/93613/\n>> \n>> Then there was another discussion in the afternoon, but I am not 100% of the\n>> outcome.\n> \n> Me neither, that\'s why I\'d like ian, who led this discussion, to sum\n> up the outcome from its point of view.\n> \n>> All this churn makes me believe that we probably just need to stop\n>> pretending we can achieve any sort of consensus on the approach and let the\n>> different alternatives develop independently, assumed they can all develop\n>> independently, and then let natural evolution take its course :)\n> \n> I tend to agree, but I think that one of the reason why we are looking\n> for a consensus, is because API evolutions proposed through\n> Neutron-spec are rejected by core-dev, because they rely on external\n> components (sdn controller, proprietary hardware...) or they are not a\n> high priority for neutron core-dev.\n> By finding a consensus, we show that several players are interested in\n> such an API, and it helps to convince core-dev that this use-case, and\n> its API, is missing in neutron.\n> \n> Now, if there is room for easily propose new API in Neutron, It make\n> sense to leave new API appear and evolve, and then \" let natural\n> evolution take its course \", as you said.\n> To me, this is in the scope of the \"advanced services\" project.\n\nI think we need to be careful of the natural tendency to view the new project as a place to put everything that is \"moving too slowly\" in neutron.  Certainly advanced services is one of the most obvious use cases of this functionality, but that doesn\'t mean that the notion of an SDN trunk port should live anywhere but neutron, IMO.\n\nThanks,\ndoug\n\n> \n>> Ultimately the biggest debate is on what the API model needs to be for these\n>> abstractions. We can judge on which one is the best API of all, but\n>> sometimes this ends up being a religious fight. A good API for me might not\n>> be a good API for you, even though I strongly believe that a good API is one\n>> that can:\n>> \n>> - be hard to use incorrectly\n>> - clear to understand\n>> - does one thing, and one thing well\n>> \n>> So far I have been unable to be convinced why we\'d need to cram more than\n>> one abstraction in one single API, as it does violate the above mentioned\n>> principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it\'s\n>> in line with those principles. I\'d rather start from there and iterate.\n>> \n>> My 2c,\n>> Armando\n>> \n>> On 14 November 2014 08:47, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>> \n>>> Thanks guys.\n>>> \n>>> I think you\'ve answered my initial question. Probably not in the way I was\n>>> hoping it to be answered, but it\'s ok.\n>>> \n>>> So now we have potentially 4 different blueprint describing more or less\n>>> overlapping use cases that we need to reconcile into one?\n>>> If the above is correct, then I suggest we go back to the use case and\n>>> make an effort to abstract a bit from thinking about how those use cases\n>>> should be implemented.\n>>> \n>>> Salvatore\n>>> \n>>> On 14 November 2014 15:42, Igor Cardoso <igordcard at gmail.com> wrote:\n>>>> \n>>>> Hello all,\n>>>> Also, what about Kevin\'s https://review.openstack.org/#/c/87825/? One of\n>>>> its use cases is exactly the L2 gateway. These proposals could probably be\n>>>> inserted in a more generic work for moving existing datacenter L2 resources\n>>>> to Neutron.\n>>>> Cheers,\n>>>> \n>>>> On 14 November 2014 15:28, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n>>>>> \n>>>>> Hi,\n>>>>> \n>>>>> As far as I understood last friday afternoon dicussions during the\n>>>>> design summit, this use case is in the scope of another umbrella spec\n>>>>> which would define external connectivity for neutron networks. Details\n>>>>> of those connectivity would be defined through service plugin API.\n>>>>> \n>>>>> Ian do you plan to define such an umbrella spec? or at least, could\n>>>>> you sum up the agreement of the design summit discussion in the ML?\n>>>>> \n>>>>> I see at least 3 specs which would be under such an umbrella spec :\n>>>>> https://review.openstack.org/#/c/93329/ (BGPVPN)\n>>>>> https://review.openstack.org/#/c/101043/ (Inter DC connectivity with\n>>>>> VPN)\n>>>>> https://review.openstack.org/#/c/134179/ (l2 gw aas)\n>>>>> \n>>>>> \n>>>>> On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando <sorlando at nicira.com>\n>>>>> wrote:\n>>>>>> Thanks Maruti,\n>>>>>> \n>>>>>> I have some comments and questions which I\'ve posted on gerrit.\n>>>>>> There are two things I would like to discuss on the mailing list\n>>>>>> concerning\n>>>>>> this effort.\n>>>>>> \n>>>>>> 1) Is this spec replacing  https://review.openstack.org/#/c/100278 and\n>>>>>> https://review.openstack.org/#/c/93613 - I hope so, otherwise this\n>>>>>> just adds\n>>>>>> even more complexity.\n>>>>>> \n>>>>>> 2) It sounds like you should be able to implement this service plugin\n>>>>>> in\n>>>>>> either a feature branch or a repository distinct from neutron. Can you\n>>>>>> confirm that?\n>>>>>> \n>>>>>> Salvatore\n>>>>>> \n>>>>>> On 13 November 2014 13:26, Kamat, Maruti Haridas <maruti.kamat at hp.com>\n>>>>>> wrote:\n>>>>>>> \n>>>>>>> Hi Friends,\n>>>>>>> \n>>>>>>>     As discussed during the summit, I have uploaded the spec for\n>>>>>>> review\n>>>>>>> at https://review.openstack.org/#/c/134179/\n>>>>>>> \n>>>>>>> Thanks,\n>>>>>>> Maruti\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> \n>>>> \n>>>> --\n>>>> Igor Duarte Cardoso.\n>>>> http://igordcard.com\n>>>> @igordcard\n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAAfiWQrf4MDfkWAcXc6_v7Nitn-WhkGNmE=tZsmve9G16B5MGQ@mail.gmail.com>',NULL),('<004c01cf393a$d4bdd210$7e397630$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 21:51:45',32400,'2014-03-06 12:51:45',NULL,'[openstack-dev] [Ceilometer] Suggestions for alarm improvements','Hi Gordon,\n\n \n\n  Thanks for the info and reply.\n\n> your interest purely to see status or were you looking to work on it? ;) \n\nMy interest lies in how to evaluate  large number of  notifications within a\nshort time.\n\nI thought moving alarms into the pipelines would be a good start.\n\n \n\nFrom: Gordon Chung [mailto:chungg at ca.ibm.com] \nSent: Wednesday, March 05, 2014 6:09 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Ceilometer] Suggestions for alarm improvements\n\n \n\nhi Sampath \n\ntbh, i actually like the pipeline solution proposed in the blueprint... that\nsaid, there hasn\'t been any work done relating to this in Icehouse. there\nwas work on adding alarms to notification\n<https://blueprints.launchpad.net/ceilometer/+spec/alarm-on-notification>\nhttps://blueprints.launchpad.net/ceilometer/+spec/alarm-on-notification but\nthat has been pushed. i\'d be interested in discussing adding alarms to\npipeline and it\'s pros/cons vs current implementation. \n\n>   <https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements>\nhttps://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements\n>  Is there any further discussion about [Part 4 - Moving Alarms into the\n> Pipelines] in above doc? \nis the pipeline alarm design attached to a blueprint? also, is your interest\npurely to see status or were you looking to work on it? ;) \n\ncheers,\ngordon chung\nopenstack, ibm software standards\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/21c61f78/attachment.html>\n\n','<OF60CFCA91.413EA6D0-ON85257C91.0073D8C5-85257C91.007436B1@ca.ibm.com>',NULL),('<004d01cfde0e$96943f00$c3bcbd00$@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-02 09:00:43',7200,'2014-10-02 07:00:43',NULL,'[Openstack-docs] Questions regarding the degree of explanation in\n	the openstack manuals','Dear all,\n\n \n\nAs I\'m new to the openstack project, I\'m having some problems regarding the\ndegree of explanation required in the Openstack install guides. In\nHavana/Icehouse, there are a lot of questions by people on very elementary\nthings anyone having worked with linux for some time at least\nsemi-professionally should/would know. For instance, in the Havana release,\nmost noticeably in the Ubuntu section for some reason, there are a lot of\ncomments regarding the setting up of MySQL. A bit of Googling would be able\nto answer most of these questions, but in my opinion the reason they are\nasked in the first place is because it\'s not clear to people just by reading\nthe docs.\n\n \n\nMy question therefore is: To what degree should things be explained in the\ninstall guides? Is there a policy that I can find somewhere (I tried looking\nfor it, but to no avail) regarding the depth of explanation? \n\n\nWith kind regards,\n\n \n\nBas\n\n \n\nPS. Anyone attending Linuxcon/Cloudopen Europe soon?\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141002/848493d1/attachment.html>\n\n',NULL,NULL),('<005401ce522e$e81fe260$b85fa720$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-16 16:14:24',14400,'2013-05-16 12:14:24',NULL,'[openstack-dev] Odd Nova unittests failure with Jenkins','Hi Christopher,\n\nPlease take into consideration the fact that following review (which\nactually adds the test case and the stub which fails for you)-\nhttps://review.openstack.org/#/c/27067 - was merged first and later reverted\nby Russell.\nI believe this caused your problems.\n\nThanks,\nOleg\n\n-----Original Message-----\nFrom: Christopher Yeoh [mailto:cbkyeoh at gmail.com] \nSent: Thursday, May 16, 2013 3:57 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] Odd Nova unittests failure with Jenkins\n\nHi,\n\nI\'m having difficulty understanding why one of my changesets is failing the\nNova unittests. It\'s https://review.openstack.org/#/c/28756/\n\nThe unittests all pass on my development machine as well as second test\nmachine on which I retrieved the code directly from Jenkins using\n\ngit fetch https://review.openstack.org/openstack/nova\nrefs/changes/56/28756/7 && git checkout FETCH_HEAD\n\n(ie for patch set 7 which is the latest version of that changeset).\n\n28756 is dependent on a changeset https://review.openstack.org/#/c/28298/\nwhich has not yet been merged. 28298 used to be dependent on\nhttps://review.openstack.org/#/c/27276/ which has been merged and 28298 has\nsubsequently been rebased on master. Both 28756 and 28298 have been rebased\na lot. 28756 has been rebased on the latest version of 28298.\n\nNow the failures I\'m seeing for 28756 look like Jenkins is using the latest\nversion of 28756, but an earlier version of 28298 which had not yet been\nrebased on a recent version master. For example from the logs:\n\n2013-05-16 08:29:10.211 |\n======================================================================\n2013-05-16 08:29:10.211 | FAIL:\nnova.tests.api.openstack.compute.plugins.v3.test_servers.ServersControllerTe\nst.test_get_server_with_volumes_attached\n2013-05-16 08:29:10.211 | tags: worker-3\n2013-05-16 08:29:10.211 |\n----------------------------------------------------------------------\n2013-05-16 08:29:10.212 | Empty attachments:\n2013-05-16 08:29:10.212 |   pythonlogging:\'\'\n2013-05-16 08:29:10.212 |   stderr\n2013-05-16 08:29:10.212 |   stdout\n2013-05-16 08:29:10.212 |\n2013-05-16 08:29:10.212 | Traceback (most recent call last):\n2013-05-16 08:29:10.212 |   File\n\"/home/jenkins/workspace/gate-nova-python26/nova/tests/api/openstack/compute\n/plugins/v3/test_servers.py\", line 463, in\ntest_get_server_with_volumes_attached\n2013-05-16 08:29:10.212 |     fakes.stub_bdm_get_all_by_instance)\n2013-05-16 08:29:10.212 | AttributeError: \'module\' object has no attribute\n\'stub_bdm_get_all_by_instance\'\n2013-05-16 08:29:10.212 |\n======================================================================\n\nThe above failure seems to indicate that stub_bdm_get_all_by_instance does\nnot exist in fakes.py (this was recently merged in the tree), but looking at\n\nhttps://review.openstack.org/#/c/28298/9/nova/tests/api/openstack/fakes.py \n\nI can see that it does exist in 28298. The id for patch set 9 is\na13c24df13cc3567416673a56e455a29d8fae969 and patch set 7 for 28756 is\ndefinitely dependent on a13c24df13cc3567416673a56e455a29d8fae969 so\nstub_bdm_get_all_by_instance should be present\n\nLooking at the logs it does look like the correct patchset is getting\nchecked out:\n\n2013-05-16 08:25:35.212 | + git checkout FETCH_HEAD\n2013-05-16 08:25:35.457 | Previous HEAD position was f927346... Return\nCustomer\'s Quota Usage through Admin API\n2013-05-16 08:25:35.458 | HEAD is now at 884a084... Merge commit\n\'refs/changes/56/28756/7\' of ssh://review.openstack.org:29418/openstack/nova\n2013-05-16 08:25:35.460 | + git reset --hard FETCH_HEAD\n2013-05-16 08:25:35.542 | HEAD is now at 884a084 Merge commit\n\'refs/changes/56/28756/7\' of ssh://review.openstack.org:29418/openstack/nova\n\nThe other failures are indicative of 28298 being tested when based on an\nearlier version of 28756.\n\nDoes anyone have any idea what might be going on? Is there any way I can get\na copy of the nova tree that Jenkins actually uses?\n\nRegards,\n\nChris\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20130516212714.531374aa@rockhopper>',NULL),('<005585e6faaa57378fc94ee863a08710@li.nux.ro>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-01-07 14:17:46',0,'2013-01-07 14:17:46',NULL,'[Openstack-operators] Inject public IP address in the VM','Hello,\n\nIs there a proper/oficial/elegant way to make Openstack inject the \npublic IP address in the VM itself instead of doing NAT? Any pointers \nappreciated.\n\n-- \nSent from the Delta quadrant using Borg technology!\n\nNux!\nwww.nux.ro\n\n\n',NULL,NULL),('<005601cf0a24$d98c3a60$8ca4af20$@snow.plala.or.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-05 23:46:00',32400,'2014-01-05 14:46:00',NULL,'[Openstack] [3rd Try] A bug on single-host OpenStack with\n	VlanManager','Hi Experts,\n\n \n\nA Happy New Year!\n\n \n\nI need your expert\'s advice on OpenStack.\n\nI will have to report to customer soon about this issue.\n\nI would highly appreciate it if you could help me out on this.\n\n \n\nI am building VlanManager environment on single-host(all-in-one) OpenStack\nGrizzly release, but it doesn\'t work.\n\nFlatDHCPManager worked on the same environment. The test bed condition is as\nbelow.\n\n \n\nOpenStack release: Grizzly\n\nOS: Cent OS 6.4\n\nnetwork: VlanManager(nova-network)\n\nhost: single-host(not multi-host)\n\n \n\nSo, I am assuming that I hit the bug that VlanManager doesn\'t work with\nsingle-host OpenStack on Cent OS.\n\nHave you seen or heard about such a bug?\n\nIf there is no clue, I only can create a bug case on Launchpad.\n\n \n\nAny pointer or letting me know someone who is familiar with this.\n\nThank you in advance,\n\n \n\n \n\nBird Kafka\n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140105/57e5c16e/attachment.html>\n\n',NULL,NULL),('<005701cf9222$d1de3da0$759ab8e0$@marlin.ie>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-27 17:14:06',3600,'2014-06-27 16:14:06',NULL,'[Openstack] Create_member in LBaaS pool via python API','Ok, figured it out. Syntax for neutron is different from nova. Silly me!\n\nneutron.create_member( { \'member\' : { \'protocol_port\' : \'80\', \'address\' :\n\'xx.xx.xx.xx\', \'pool_id\' : xxxxxxxxxxxxxxxxxx } } )\n\n\n\nHi All,\n\nA newbie question here but I can\'t find the answer in the API documentation\nor maybe I\'m not reading it correctly :-) I\'m trying to add an existing\nserver instance to an existing active LBaaS pool in icehouse.\n\nThis is my code \n\nimport neutronclient.v2_0.cleint as ntclient neutron = ntclient (\nauthentication works fine\n)\n\n\nneutron.create_member(\n    protocol_port = \"80\",\n    address = \"xx.xx.xx.xx\",\n    pool_id = \"xxxxxxxxxxxxxxxxxxxxxx\"\n)\n\nI get the following error -  \'create_member got an unexpected keyword\nargument \'protocol_port\'\n\nI have tried different variations such as port, protocol-port.\nI get similar issues with pool_id.\n\nThanks for your help.\n\nBrian.\n    \n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n-----\nNo virus found in this message.\nChecked by AVG - www.avg.com\nVersion: 2014.0.4592 / Virus Database: 3986/7752 - Release Date: 06/27/14\n\n\n\n','<000d01cf91f4$783fd250$68bf76f0$@marlin.ie>',NULL),('<005b01cfd398$064022f0$12c068d0$@org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 01:25:19',7200,'2014-09-18 23:25:19',NULL,'[openstack-dev] [Neutron][QoS] Applying QoS as Quota','Hello,\n\nI\'m aware it\'s not so easy to define a solution, so I\'ll expose my idea.\n\nI was thinking about a \"network flavor\" that a tenant can associate to\nVMs. Basically the network flavour is a QoS policy.\n\nThe admin can define the network flavors (Gold, Silver, ... call it as you\nwant) with a set of parameters (some visible to user, some not).\n\nIf we define this kind of flavours, a related quota should be define to\nkeep track the network resources.\n\n \n\nGiuseppe\n\n \n\nFrom: Veiga, Anthony [mailto:Anthony_Veiga at cable.comcast.com] \nSent: 10 September 2014 15:11\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n\n \n\n \n\n \n\nUsing the quota system would be a nice option to have.  \n\n \n\nCan you clarify what you mean by cumulative bandwidth for the tenant? It\nwould be possible to rate limit at the tenant router, but having a\ncumulative limit enforced inside of a tenant would be difficult.\n\n \n\nOn Wed, Sep 10, 2014 at 1:03 AM, Giuseppe Cossu\n<giuseppe.cossu at create-net.org> wrote:\n\nHello everyone,\n\nLooking at the QoS blueprint (proposed for incubation), I suggest to\nconsider adding some parameters to Neutron Quotas. Let\'s suppose using\nrate-limit for managing QoS. The quota parameters could be such as\nrate_limit (per port) and max_bandwidth (per tenant). In this way it is\npossible to set/manage QoS quotas from the admin side, and for instance\nset the maximum bandwidth allowed per tenant (cumulative).\n\nWhat do you think about it?\n\n \n\nI\'m cautious about this.  We\'d either need to allow a \"Number of DSCP\nsettings\" and set them outside the quota or leave it out altogether.\nLet\'s not forget that there\'s more than just rate limiting in QoS, and we\nneed to make sure all the options are included.  Otherwise, there\'s going\nto be a lot of user and operator confusion as to what is and isn\'t\nconsidered part of the quota.\n\n-Anthony\n\n \n\nRegards,\n\nGiuseppe\n\n \n\n--------------------------------------------------------\n\nGiuseppe Cossu\n\nCREATE-NET\n\n--------------------------------------------------------\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n \n\n-- \n\nKevin Benton\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140919/b1f58ca7/attachment.html>\n\n','<D035C5AC.3DDB%anthony_veiga@cable.comcast.com>',NULL),('<005b01cff349$76402070$62c06150$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-29 14:25:02',25200,'2014-10-29 07:25:02',NULL,'[Openstack] Compute Node without firewall (iptables) and linux\n	bridge','Hello\n\n \n\nI\'m looking for a way to disable any firewall feature in one of our compute\nnodes and prevent the creation of the Linux bridge in the data path inside\nof this compute node. \n\n \n\nHere is the configuration in the compute node:\n\n#/etc/neutron/plugin.ini\n\n[securitygroup]\n\n#firewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\nfirewall_driver = neutron.agent.firewall.NoopFirewall\n\n# enable_security_group = True\n\nenable_security_group = False\n\n \n\n#/etc/nova/nova.conf\n\nfirewall_driver = nova.virt.firewall.NoopFirewallDriver\n\n#security_group_api = neutron\n\n \n\n#/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini\n\n[securitygroup]\n\nfirewall_driver = neutron.agent.firewall.NoopFirewallDriver\n\nenable_security_group = False\n\n \n\nThe firewall seems to be disabled but the bridge and the interfaces are\nbeing still created. \n\nI found an older post about it:\nhttp://lists.openstack.org/pipermail/openstack/2014-May/007079.html\n\nBut changing \"portbindings.OVS_HYBRID_PLUG\" from a hard-coded \"True\" to\n\"False\" didn\'t change anything.\n\n \n\nPlease advise!\n\n \n\nCheers \n\nChris\n\n \n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141029/aaf4fb96/attachment.html>\n\n',NULL,NULL),('<006001cece3d$8a185360$9e48fa20$@netrove.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-21 17:11:32',28800,'2013-10-21 09:11:32',NULL,'[Openstack] General Question on Openstack','Hi Openstack,\n\n \n\nI have a question on the cloud storage. \n\n \n\nIs this cloud storage for users whom dont have IT background?\n\n \n\nAll I want to achieve is to upload the file to the server and share the link\nwith other users (potential clients). The catch here is that these clients\nwill not be able to download the files, but only made viewable for them.\n\n \n\nDo you think this is achievable? I am referring to all kinds of docs.\n\n \n\nAppreicate your reply.\n\n \n\nThank you.\n\n \n\nJustin Soh\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131021/e2411afd/attachment.html>\n\n',NULL,NULL),('<006101cf0b06$5ed06a20$1c713e60$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-01-06 09:40:18',-28800,'2014-01-06 17:40:18',NULL,'[openstack-community] OpenStack Northwest User Group Meetup this\n	Wed Jan 8 in Portland','OpenStack Northwest User Group Meetup in Portland\n\nWednesday Jan 8, 2014 @ 6:00PM PDT\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nhttp://www.meetup.com/OpenStack-Northwest/\n\nSome of the core contributors, developers and implementers of OpenStack\n<http://www.openstack.org> are flying over to Portland to bring you the\nlatest and greatest in Cloud storage. And generous sponsors are buying us\ndinner and beer. This meetup is quickly growing to be one of the most\ninteresting events in the Northwest for those wanting to stay on top of\nadvancement in the future of computing. \n\nMeetup Agenda\n\n6:00 - 6:30 - Check in, pizza, beer and networking\n\n\n6:30 - 7:00 - Introduction, OpenStack and your career - Al Kari (DetaCloud\n<http://www.detacloud.com> )\n\nAccelerate your career and increase your value to your current or potential\nemployers. Learn about shortcuts to quickly acquire some of the hottest\nskills in Cloud computing.\n\n7:00 - 7:45 - OpenStack Block Storage (Cinder) - Mike Perez (DreamHost\n<http://www.dreamhost.com> )\n\nToday there are many different storage solutions to choose from. It can be\noverwhelming from a cloud provider\'s perspective to offer many options for\ntheir users, let alone provide a consistent set of tools with each vendor\noffering their own interface.\nThe OpenStack Block Storage project Cinder provides an API to talk to many\ndifferent vendor solutions, in which other applications or OpenStack\nprograms can talk to.\nWe\'ll first examine the difference between block and object storage. That\'ll\nlead us into having an introduction to Cinder, and an opportunity to review\nthe architecture, vendor driver plugin model, current features, and upcoming\nfeatures for the IceHouse release. \n\n\n7:45 - 8:15 - OpenStack Object Storage (Swift) - Richard Raseley (for\nSwiftStack <http://www.swiftstack.com> )\n\nThis presentation will provide an overview of the OpenStack object storage\nplatform \"Swift\", its history, contributors, example use cases, and features\n\n8:15 - 8:45 - EMC and OpenStack - Jeremy Keen - (EMC <http://www.emc.com> )\n\nAs a Corporate Sponsor of OpenStack, EMC has contributed Cinder drivers for\nVNX, VMAX, and most recently ViPR.  EMC ViPR is a lightweight, software-only\nsolution that transforms your existing storage environment into a simple,\nextensible and open platform, that can deliver fully automated storage\nservices and realize the full potential of the Software-Defined Data Center.\nViPR includes an open source Cinder driver as well as an object storage\nengine with Swift and Amazon S3 APIs.  We will dive into the integration of\nViPR and OpenStack and learn about methods for delivering IT-as-a-Service\nwhile avoiding storage vendor lock-in.\n\n8:45 - 9:00 - OPEN MIKE (YOU)\n\nWorking on an interesting project, or have an idea to share with the group?\nMaybe you have a question or an announcement to make. Here\'s your chance.\n\nAbout the speakers:\n\nAl Kari - After 6 years of leading Cloud Computing services at Dell, Al\nCo-Founded DetaCloud to advocate for building the future of Open Cloud. He\nis a standing member in the Cloud Advisory Council, the Linux Professional\nInstitute and the OpenStack Foundation\n\nMike Perez is a Core developer of the OpenStack Block Storage project Cinder\nand Senior Software Engineer at DreamHost. His primary responsibilities are\ncontributing Cinder, and managing the storage needs of DreamHost\'s public\ncloud DreamCompute. He has written v2 of Cinder\'s API, and is currently\nworking on v3\n\nRichard Raseley is an Infrastructure and Tooling Engineer at Puppet Labs and\na standing member of the OpenStack Foundation. Prior to joining Puppet,\nRichard worked as a Systems Engineer with Concur Technologies, where h\ndeploy a near petabyte-scale distributed object store based upon OpenStack\nSwift\n\nJeremy Keen over the last 3 years at EMC as a Systems Engineer, Jeremy has\ndesigned hybrid and private cloud solutions for businesses in the Pacific\nNorthwest.  He now specializes in software-defined-storage at EMC including\nthe recently launched ViPR an open, extensible software-only solution that\nincludes deep integration with OpenStack Cinder and Swift.\n\nSpecial thanks to our sponsors Jama Software for providing the facilities,\nbeverages and beer, and to ProFocus for the pizza and door prizes.\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140106/f0a326f5/attachment.html>\n\n',NULL,NULL),('<006101cf0b06$5ed06a20$1c713e60$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-06 09:40:18',-28800,'2014-01-06 17:40:18',NULL,'[Openstack] OpenStack Northwest User Group Meetup this Wed Jan 8 in\n	Portland','OpenStack Northwest User Group Meetup in Portland\n\nWednesday Jan 8, 2014 @ 6:00PM PDT\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nhttp://www.meetup.com/OpenStack-Northwest/\n\nSome of the core contributors, developers and implementers of OpenStack\n<http://www.openstack.org> are flying over to Portland to bring you the\nlatest and greatest in Cloud storage. And generous sponsors are buying us\ndinner and beer. This meetup is quickly growing to be one of the most\ninteresting events in the Northwest for those wanting to stay on top of\nadvancement in the future of computing. \n\nMeetup Agenda\n\n6:00 - 6:30 - Check in, pizza, beer and networking\n\n\n6:30 - 7:00 - Introduction, OpenStack and your career - Al Kari (DetaCloud\n<http://www.detacloud.com> )\n\nAccelerate your career and increase your value to your current or potential\nemployers. Learn about shortcuts to quickly acquire some of the hottest\nskills in Cloud computing.\n\n7:00 - 7:45 - OpenStack Block Storage (Cinder) - Mike Perez (DreamHost\n<http://www.dreamhost.com> )\n\nToday there are many different storage solutions to choose from. It can be\noverwhelming from a cloud provider\'s perspective to offer many options for\ntheir users, let alone provide a consistent set of tools with each vendor\noffering their own interface.\nThe OpenStack Block Storage project Cinder provides an API to talk to many\ndifferent vendor solutions, in which other applications or OpenStack\nprograms can talk to.\nWe\'ll first examine the difference between block and object storage. That\'ll\nlead us into having an introduction to Cinder, and an opportunity to review\nthe architecture, vendor driver plugin model, current features, and upcoming\nfeatures for the IceHouse release. \n\n\n7:45 - 8:15 - OpenStack Object Storage (Swift) - Richard Raseley (for\nSwiftStack <http://www.swiftstack.com> )\n\nThis presentation will provide an overview of the OpenStack object storage\nplatform \"Swift\", its history, contributors, example use cases, and features\n\n8:15 - 8:45 - EMC and OpenStack - Jeremy Keen - (EMC <http://www.emc.com> )\n\nAs a Corporate Sponsor of OpenStack, EMC has contributed Cinder drivers for\nVNX, VMAX, and most recently ViPR.  EMC ViPR is a lightweight, software-only\nsolution that transforms your existing storage environment into a simple,\nextensible and open platform, that can deliver fully automated storage\nservices and realize the full potential of the Software-Defined Data Center.\nViPR includes an open source Cinder driver as well as an object storage\nengine with Swift and Amazon S3 APIs.  We will dive into the integration of\nViPR and OpenStack and learn about methods for delivering IT-as-a-Service\nwhile avoiding storage vendor lock-in.\n\n8:45 - 9:00 - OPEN MIKE (YOU)\n\nWorking on an interesting project, or have an idea to share with the group?\nMaybe you have a question or an announcement to make. Here\'s your chance.\n\nAbout the speakers:\n\nAl Kari - After 6 years of leading Cloud Computing services at Dell, Al\nCo-Founded DetaCloud to advocate for building the future of Open Cloud. He\nis a standing member in the Cloud Advisory Council, the Linux Professional\nInstitute and the OpenStack Foundation\n\nMike Perez is a Core developer of the OpenStack Block Storage project Cinder\nand Senior Software Engineer at DreamHost. His primary responsibilities are\ncontributing Cinder, and managing the storage needs of DreamHost\'s public\ncloud DreamCompute. He has written v2 of Cinder\'s API, and is currently\nworking on v3\n\nRichard Raseley is an Infrastructure and Tooling Engineer at Puppet Labs and\na standing member of the OpenStack Foundation. Prior to joining Puppet,\nRichard worked as a Systems Engineer with Concur Technologies, where h\ndeploy a near petabyte-scale distributed object store based upon OpenStack\nSwift\n\nJeremy Keen over the last 3 years at EMC as a Systems Engineer, Jeremy has\ndesigned hybrid and private cloud solutions for businesses in the Pacific\nNorthwest.  He now specializes in software-defined-storage at EMC including\nthe recently launched ViPR an open, extensible software-only solution that\nincludes deep integration with OpenStack Cinder and Swift.\n\nSpecial thanks to our sponsors Jama Software for providing the facilities,\nbeverages and beer, and to ProFocus for the pizza and door prizes.\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140106/f0a326f5/attachment.html>\n\n',NULL,NULL),('<006801cdc712$04ede250$0ec9a6f0$@com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 19:27:25',28800,'2012-11-20 11:27:25',NULL,'[openstack-dev] dashboard can not login','I installed and used openstack in command line well, but when I login\ndashboard, dashboard always shows \"Error: An error occurred authenticating.\nPlease try again later.\"\n\n \n\nAnyone can tell me how to solve this problem?\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121120/bc925190/attachment.html>\n\n',NULL,NULL),('<006801ce2921$99d4e910$cd7ebb30$@nsn.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-25 08:25:51',7200,'2013-03-25 06:25:51',NULL,'[openstack-dev] PCI-passthrough dev ...','Actually, there is no implementation for hw under the framework.\n\nHow do you think to manage it ?\n\n \n\n-niilo-\n\n \n\nFrom: ext Ian Wells [mailto:ijw.ubuntu at cack.org.uk] \nSent: 24. maaliskuuta 2013 19:45\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] PCI-passthrough dev ...\n\n \n\nYep, we\'ve got code in test at the moment.\n\n-- \n\nIan.\n\n \n\nOn 21 March 2013 09:20, Niilo Minkkinen / NSN <niilo.minkkinen.ext at nsn.com>\nwrote:\n\nHi.\n\nIs someone working with this currently, or have some info\nabout usage ?\n\nBlueprint : https://blueprints.launchpad.net/nova/+spec/pci-passthrough-and-\n<https://blueprints.launchpad.net/nova/+spec/pci-passthrough-and-sr-iov> \nsr-iov\n\nLatest code review : https://review.openstack.org/#/c/776/\n\nThanks in advance.\n\n- niilo -\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130325/4d37f041/attachment.html>\n\n','<CAPoubz4qAHQOahKLZNaRuM8tsx289c0Y9oD8k9q0e9w3oWFP3g@mail.gmail.com>',NULL),('<006901ce8794$0854d550$18fe7ff0$@wirelessconnections.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-23 07:01:45',-14400,'2013-07-23 11:01:45',NULL,'[Openstack-operators] Horizon issue','Thanks for the info!  It appears that the script I had used was for the\nFulsome release not Grizzley and didn\'t work properly.  Once I used the\ncorrect script everything worked.\n\nDavid\n\n\n-----Original Message-----\nFrom: Robert Plestenjak [mailto:robert.plestenjak at xlab.si] \nSent: Tuesday, July 23, 2013 2:11 AM\nTo: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Horizon issue\n\nI would say that at least one of Openstack services (Quantum, Nova, ...)\ncan\'t authenticate with Keystone. Try services in shell like: \'quantum\nnet-list\', \'nova image-list\', ... and fix configs.\n\n- Robert\n\n----- Original Message -----\nFrom: \"David Peterson\" <davidp at wirelessconnections.net>\nTo: openstack-operators at lists.openstack.org\nSent: Monday, July 22, 2013 6:03:44 PM\nSubject: [Openstack-operators] Horizon issue\n\n\n\n\n\nI followed the Grizzly install guide and am running into a basic issue. When\nI try to log into the dashboard, it tells me that I am attempting to\nauthenticate from the wrong IP address. Here is the keystone log: \n\n\n\n2013-07-22 11:41:19 WARNING [keystone.common.wsgi] Authorization failed. The\nrequest you have made requires authentication. from 64.186.195.20 \n\n2013-07-22 11:41:51 WARNING [keystone.common.wsgi] Authorization failed. The\nrequest you have made requires authentication. from 10.10.10.51 \n\n\n\n\n\nAny thoughts? \n\n\n\nDavid \n\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<5bdc2373-af98-4cb5-a03b-8d0181291e8b@zimbra>',NULL),('<00698056-6A49-4BEC-9999-CD15DD98E208@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 18:35:00',0,'2014-09-24 18:35:00',NULL,'[openstack-dev] sw process','\nFolks ? we have gotten into a couple of loose habits in our mad dash to beta 1 that we need to tighten up on.  I?ve asked Ryan to set geritt up to fail reviews when the commit id does not contain one of the following, so please add them to your commit.  In addition please make your commit message useful and with enough detail that the reviewer knows what he/she is reviewing.\n\nImplements-Story: XXX\nFixes-Bug: YYY\n\nOther issues\n\nDo not +2 your own patch .  We won?t enforce this unless we need to, but don?t do it\n\nReviewed pushed on master and containing multiple changes\n\nYou should create a branch to hold your work and name it something that makes sense.  This branch should ONLY contain this work.  When you checkin your code it makes it much easier for the reviewer to understand what you are doing.  If you have work that is dependent on other work, create a dependency on your branch\n\nI.e. Git checkout ?b <branch name>  where branch name is bug/1234 or implement-ui-validation\n\nThis is the openstack workflow ? which talks about how to do dependencies, rebating etc.  It?s a pretty good guide.\n\nhttps://wiki.openstack.org/wiki/Gerrit_Workflow#Normal_Workflow\n\n\nAnyone have other guides they want to share on a good workflow?\n\n\n\nLet me know if you have comments or suggestions.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140924/630e09ff/attachment.html>\n\n',NULL,NULL),('<006997A3-DF7C-4F46-890A-30EE4C9C65EC@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 15:11:55',-25200,'2013-06-25 22:11:55',NULL,'[openstack-dev] [OpenStack][python-quantumclient] unit test question','Hi,\n\nI am seeing the following error and cannot figure out why it happened and how to solve it.  Any advice would be appreciated.  Thanks!\n\nUnexpectedMethodCallError: Unexpected method call.  unexpected:-  expected:+\n- request.__call__(\'localurl/v2.0/firewall_policies.xml\', \'POST\', body=\'<?xml version=\\\'1.0\\\' encoding=\\\'UTF-8\\\'?>\\n<firewall_policy xmlns=\"http://openstack.org/quantum/api/v2.0\" xmlns:quantum=\"http://openstack.org/quantum/api/v2.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"><description>my-desc</description><admin_state_up quantum:type=\"bool\">True</admin_state_up><tenant_id>my-tenant</tenant_id><firewall_rules_list><item>rule_id1</item></firewall_rules_list><shared quantum:type=\"bool\">True</shared><audited quantum:type=\"bool\">True</audited><name>my-name</name></firewall_policy>\', headers={\'X-Auth-Token\': \'testtoken\', \'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'User-Agent\': \'python-quantumclient\'}) -> None\n+ request.__call__(\'localurl/v2.0/firewall_policies.xml\', \'POST\', body=<?xml version=\'1.0\' encoding=\'UTF-8\'?>\n\n+ <firewall_policy xmlns=\"http://openstack.org/quantum/api/v2.0\" xmlns:quantum=\"http://openstack.org/quantum/api/v2.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"><tenant_id>my-tenant</tenant_id><description>my-desc</description><admin_state_up quantum:type=\"bool\">True</admin_state_up><firewall_rules_list><item>rule_id1</item></firewall_rules_list><shared quantum:type=\"bool\">True</shared><audited quantum:type=\"bool\">True</audited><name>my-name</name></firewall_policy>, headers=<map containing the entry \'X-Auth-Token: testtoken\'>) -> (<tests.unit.test_cli20.MyResp object at 0x3156d90>, \'<?xml version=\\\'1.0\\\' encoding=\\\'UTF-8\\\'?>\\n<firewall_policy xmlns=\"http://openstack.org/quantum/api/v2.0\" xmlns:quantum=\"http://openstack.org/quantum/api/v2.0\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"><id>myid</id><name>my-name</name></firewall_policy>\')\n\nKC\n\n\n\n',NULL,NULL),('<006EED3F-FAB8-4D52-9B9A-5152675DED51@rackspace.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-20 20:29:00',0,'2015-01-20 20:29:00',NULL,'[Openstack-operators] [openstack-operators][os-ansible-deployment]\n	Meeting Announcement.','Hi everyone,\n\nThe \"os-ansible-deployment? project on stackforge is progressing and we?ve formalized our weekly meetings. If you?re interested in the project we?d love for you to drop by. For more information on our upcoming meetings please have a look here: \"https://wiki.openstack.org/wiki/Meetings/openstack-ansible?.\n\nThanks and have a great week.\n\n?\n\nKevin\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150120/36e28ec8/attachment.pgp>\n\n',NULL,NULL),('<006F58A8-EDAA-41FF-9835-87FFA59A1F2A@metacloud.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-22 23:35:09',-18000,'2013-12-23 04:35:09',NULL,'[openstack-dev] Process for proposing patches attached to\n	launchpad bugs?','\n\n\nOn Dec 22, 2013, at 3:13 , Robert Collins <robertc at robertcollins.net> wrote:\n\n> On 22 December 2013 18:02, Chet Burgess <cfb at metacloud.com> wrote:\n>> \n>> \n>> On Dec 20, 2013, at 14:07 , Russell Bryant <rbryant at redhat.com> wrote:\n>> \n>> \n>> It\'s not your code, so you really can\'t propose it without them having\n>> signed the CLA, or propose it as your own.\n>> \n>> \n>> Is there a time limit on this sort of thing? As an example there is a bug we\n>> opened 2 years ago that still has not been fixed. Someone posted a patch to\n>> the laundpad 4 months ago that addresses the issue but hasn\'t submitted a\n>> review. How long do we wait before its ok to submit the patch so we can have\n>> the fix? Is there some way we can note where the original code came from so\n>> as not to be viewed as stealing credit?\n>> \n>> I ask now because I planned on posted a review with tests in next week or so\n>> because we really need the fix\n>> (https://bugs.launchpad.net/nova/+bug/856764).\n> \n> There is a time limit - 70 years after the authors death. I suggest\n> not waiting for that and instead writing a new patch yourself.\n> \n\nIt\'s unclear to me what exactly constitutes writing a new patch. I can check out oslo.messaging, and without trying to merge the patch just go and make the same change (its literarily a 2 line change). I can write the tests, and I can submit it (which I\'m happy to do, I really want this bug fixed). Honestly though this change is so trivial I don\'t see how my patch would look all that different from the one already posted. I know there is prior art. The mixin class that kombu provides does the exact same thing. Is that sufficient? What else would need to be done to make this free an clear for our use? I\'m going to try reaching out to the author to see if I can sort it that way, but this still seems like there is a general problem here.\n\nGiven the current interpretation of the IP laws someone has an effective way to block progress on a feature, blueprint, or project as a whole. Create a launchpad account, don\'t sign the CLA, just start posting implementations to launchpad. If the simple act of reading the bugs now encumbers us from being able to fix them in a certain way or using certain patterns we have a potentially serious issue. If this is really the case should we not lock the bug tracker to only those who have signed the CLA or have the TOU clearly state that any code posted is automatically ASLv2? Am I misunderstanding the scope of this problem?\n\n--\nChet Burgess\nVice President, Engineering | Metacloud, Inc.\nEmail: cfb at metacloud.com | Tel: 855-638-2256, Ext. 2428\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131222/301b669b/attachment.html>\n\n','<CAJ3HoZ1d_FN=6eTEGzQR6RgFK1x+UkRe4g1+633Bd0PLuyUCvA@mail.gmail.com>',NULL),('<007301cfde52$172810e0$457832a0$@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-02 17:03:55',7200,'2014-10-02 15:03:55',NULL,'[Openstack-docs] Questions regarding the degree of explanation\n	in the openstack manuals','To be honest, I think the way you just described the Openstack experience (of a first-timer) really covers the entire issue. Even though I agree with Matt that it doesn?t make much sense for someone without a decent knowledge of Linux system administration to start deploying clouds, I don?t think people generally care and just try anyways, following the guide as closely as possible. When something then deviates from what?s stated in the install guide I imagine a vast majority of these ?newcomers? don?t have a clue as to how to troubleshoot their setup (I think we can all recall that time ;) ).\n\n \n\nDo you think a preface containing some information on where to find help (MySQL docs, ask.openstack.org, stackexchange sites, distro-specific docs such as the RDO, etc.) would help more people get through the installation by their own means? Maybe a lot of people who want to just ?try out? Openstack could be referenced to Devstack instead in this preface.\n\n \n\nWith kind regards,\n\n \n\nBas Peters\n\n \n\nFrom: annegentle at justwriteclick.com [mailto:annegentle at justwriteclick.com] On Behalf Of Anne Gentle\nSent: Thursday, October 2, 2014 4:40 PM\nTo: Matt Kassawara\nCc: Bas Peters; openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Questions regarding the degree of explanation in the openstack manuals\n\n \n\nWhat Matt says is all true, but specific to Ubuntu/MySQL, there is no other OpenStack install guide for that particular user. So I think that there tend to be more questions for Ubuntu and also more \"beginners\" or \"freshers\" reading that particular guide. RHEL has another install guide, SUSE has another install guide. Debian has no other guide to my knowledge either but we don\'t see as many comments there.\n\n \n\nThis is a nice analysis of the comments, for sure, thanks for looking at it and asking. We have a section in some books describing the audience and what their pre-requisite knowledge should be, for example:\n\nOperations Guide: http://docs.openstack.org/openstack-ops/content/openstack-ops_preface.html#who-this-book-is-for\n\n \n\nSecurity Guide: http://docs.openstack.org/security-guide/content/introduction-to-openstack.html\n\n \n\nArchitecture Design Guide: http://docs.openstack.org/arch-design/content/arch-guide-intended-audience.html\n\n \n\nFor the Install Guides, that audience analysis has been done many times in the past years, and we mostly come up with this type of statement: \"This guide enables you to choose your own OpenStack adventure using a combination of basic and optional services.\" This statement gets various reactions but I think it\'s pretty close to truth: installing OpenStack is an adventure that many take, and we document it for a few happy paths with a lot of assumption about what people should know before going on the adventure. \n\n \n\nDo you have suggestions for indicating that, perhaps with a section like the examples above?\n\n \n\nThanks,\n\nAnne\n\n \n\n \n\nOn Thu, Oct 2, 2014 at 9:18 AM, Matt Kassawara <mkassawara at gmail.com <mailto:mkassawara at gmail.com> > wrote:\n\nI hope most people installing OpenStack have at least a basic amount of Linux systems administration experience. However, after some previous banter on this topic, we still tend to provide the actual commands for steps requiring basic experience (e.g., symlinks). On the other hand, networking steps get tricky because most people installing OpenStack for the first time lack network administration experience, especially on Linux with bridges, iptables, namespaces, etc.\n\n \n\nOn Thu, Oct 2, 2014 at 2:00 AM, Bas Peters <baspeters93 at gmail.com <mailto:baspeters93 at gmail.com> > wrote:\n\nDear all,\n\n \n\nAs I?m new to the openstack project, I?m having some problems regarding the degree of explanation required in the Openstack install guides. In Havana/Icehouse, there are a lot of questions by people on very elementary things anyone having worked with linux for some time at least semi-professionally should/would know. For instance, in the Havana release, most noticeably in the Ubuntu section for some reason, there are a lot of comments regarding the setting up of MySQL. A bit of Googling would be able to answer most of these questions, but in my opinion the reason they are asked in the first place is because it?s not clear to people just by reading the docs.\n\n \n\nMy question therefore is: To what degree should things be explained in the install guides? Is there a policy that I can find somewhere (I tried looking for it, but to no avail) regarding the depth of explanation? \n\n\nWith kind regards,\n\n \n\nBas\n\n \n\nPS. Anyone attending Linuxcon/Cloudopen Europe soon?\n\n \n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org <mailto:Openstack-docs at lists.openstack.org> \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n \n\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org <mailto:Openstack-docs at lists.openstack.org> \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141002/68160391/attachment-0001.html>\n\n','<CAD0KtVEb1Awjdg-SYUjHXwsfdxUc3W=2rRT3krMHVF81UU560w@mail.gmail.com>',NULL),('<007901cfe172$ab042290$010c67b0$@com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-06 16:34:41',7200,'2014-10-06 14:34:41',NULL,'[Openstack-docs] [training-guides] running training sessions in\n	the sfbay openstack user group meetings','Hi\n\nI cloud be interested in participating in this and contributing to the effort, as it could complement my cloud training portfolio.\n\nI am relatively new to this community, so could somebody clue me in on the logistics of said training-guides meeting?\n\nBTW, my geography is NL/EU. I am in touch with local user groups.\n\n \n\nBest regards\n\n \n\nPeter HJ van Eijk | +31 6 2268 4939 | peter at clubcloudcomputing.com| Twitter @petersgriddle | www.clubcloudcomputing.com\n\n \n\n \n\n \n\nFrom: sean roberts [mailto:seanroberts66 at gmail.com] \nSent: Saturday, October 4, 2014 02:23\nTo: openstack-docs >> openstack-docs at lists.openstack.org; Stefano Maffulli; Tom Fifield; Shannon McFarland; mvoelker at cisco.com; Rick Evans; Polina Petriuk\nSubject: [Openstack-docs] [training-guides] running training sessions in the sfbay openstack user group meetings\n\n \n\nI am following up on the original intent of holding openstack user group meetings using the openstack training guides. The plan is to start with the associate guide and hold (6) 2 hour meetings starting the week after the summit. If this works, then perhaps we can develop this into associate training leading up to the summit, upstream training at the summit, followed by the more advanced training over the next release cycle. I am a bit murky on how we coalesce the slightly different training materials, but I\'d rather forge forward before answering all questions.\n\n \n\nSome logistical problems have started showing up as we were thinking through what needs to happen and by when. \n\n- we will need the network, object, and assessment quizzes completed. that isnt a huge deal since we have until jan until we hit the gap. i will track in the project.\n\n- if a laptop with enough mem or disk isn\'t available, we should have a backup like rackspace vm option instructions. again i will track in the project.\n\n- we will need to do trainer training. creating trainer notes for each chapter seems like a likely requirement. I am guessing that most trainers will revert to printing out the material and making notes on paper. this will be a problem. another issue to track in the project.\n\n- we will need to find, train, and retain trainers to help us make this work. Myself, Rick Evans, Polina Petriuk have discussed participating as trainers. I am hoping that Stef and Tom can help us find a few more sfbay area speaker/trainers.\n\n- we will need to find other user groups willing to clone our work asap, so we can get more, better. I have spoken with Shannon McFarland (Denver) and Mark Voelker (Durham) and they are interested.\n\n \n\nThe proposed training schedule below. I am including the likely Kilo release dates as they will impact our availability.\n\n \n\n1) session 1: 20 nov chapters 1-2 getting started \n2) session 2: 04 dec chap 3-4 controller\n\nWeek of 05 dec M1\n\n3) session 3: 18 dec chap 5-6 compute\n\nholiday break\n\n4)session 4: 22 jan chap 7-8 network\nWeek of 23 jan M2\n5) session 5: 05 feb chap 9-10 object\n6) session 6: 19 feb chap 11-12 assessment\nWeek of 20 feb feature freeze propose\nWeek of 06 mar feature freeze, M3\nWeek of 27 mar - 17 apr release\nWeek of 15 may design summit \n\n \n\nLet\'s discuss this at the next training-guides meeting. \n\n \n\n~ sean\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141006/560269e2/attachment.html>\n\n','<CAEoPogHA6f16skaM8icu8mg5ZvfpHAN1iF8P7zE=PfU+ttD50Q@mail.gmail.com>',NULL),('<007a01cfe559$2fc6c700$8f545500$@sanenthusiast.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-11 19:12:07',19800,'2014-10-11 13:42:07',NULL,'[Openstack] Reg: Open Stack Implementation','Hi Experts,\n\n \n\n                    With regards to open stack implementation in my\nenvironment I would like to understand whether it works on Type 1 or Type 2\nHypervisor.\n\n \n\nTo put it in brief with my understanding OpenStack needs a operating system\nto run. I am curious about performance of the OpenStack model. It has to\ninvolve operating system to communicate with the hardware according to\nhypervisor type 2. With our traditional type 1 hypervisor it is independent\nof operating system when communication happens.\n\n \n\nWith this type 2 model it has to communicate with the operating system? Any\ninsights about performance and reliability is appreciated.\n\n \n\nPlease reply all.:)\n\n \n\nRegards,\n\nArasu\n\n \n\n                 \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141011/7afd329f/attachment.html>\n\n',NULL,NULL),('<007f9a8580514282b19fa12be04f9edd@MSR-MAIL-EXCH03.ubisoft.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-08 23:07:57',0,'2014-09-08 23:07:57',NULL,'[Openstack] [heat] identity:create_domain failed (403)','Hi guys,\n\n                I have 2 environments that are almost identical but one of them gives me this:\n\nkeystoneclient.openstack.common.apiclient.exceptions.Forbidden: You are not authorized to perform the requested action, identity:create_domain. (HTTP 403)\n\nWhen I try to run:\n\nheat-keystone-setup-domain --stack-domain-admin stack_admin --stack-domain-admin-password $password --stack-user-domain-name heat\n\nThe problem is that I\'m using the same policy everywhere and one works but the other doesn\'t. I\'m out of ideas!\n\nAny hints?\n\nDave\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140908/96bd7423/attachment.html>\n\n',NULL,NULL),('<008401cf3a36$06729010$1357b030$@yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 13:49:51',-18000,'2014-03-07 18:49:51',NULL,'[Openstack] remove the Volume tab under Project Manage Compute on\n	Horizon dashboard',' \nDear All,\n \nI have a go-do to remove the Volume tab under Project Manage Compute \non the Horizon Console.  Is this an easy fix?  Could someone help me?  \n \nWe need Cinder, so we can\'t simply uninstall Cinder and removing it from the\nKeystone catalog.\\\n \nWe are using the Havana release.\n \nThank you.\n \nFury Christ\nServosity Development\n913-530-5017\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140307/2d6ee98d/attachment.html>\n\n',NULL,NULL),('<008501ced199$ea2afb90$be80f2b0$@openstack.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-25 08:50:20',-25200,'2013-10-25 15:50:20',NULL,'[Openstack] Openstack Digest, Vol 4, Issue 29','y\n\n-----Original Message-----\nFrom: openstack-request at lists.openstack.org\n[mailto:openstack-request at lists.openstack.org] \nSent: Friday, October 25, 2013 5:00 AM\nTo: openstack at lists.openstack.org\nSubject: Openstack Digest, Vol 4, Issue 29\n\nSend Openstack mailing list submissions to\n	openstack at lists.openstack.org\n\nTo subscribe or unsubscribe via the World Wide Web, visit\n	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nor, via email, send a message with subject or body \'help\' to\n	openstack-request at lists.openstack.org\n\nYou can reach the person managing the list at\n	openstack-owner at lists.openstack.org\n\nWhen replying, please edit your Subject line so it is more specific\nthan \"Re: Contents of Openstack digest...\"\n\n\nToday\'s Topics:\n\n   1. Re: Migrate instances/tenants between clouds (Joe Topjian)\n   2. Re: Migrate instances/tenants between clouds (Robert Collins)\n   3. Re: Help for creating the bridge br100 (Razique Mahroua)\n   4. Re: Migrate instances/tenants between clouds (Joshua Harlow)\n   5. Re: Migrate instances/tenants between clouds (Robert Collins)\n   6. libvirtd and Folsom Quantum/Neutron and iptables (Craig E. Ward)\n   7. Re: Migrate instances/tenants between clouds (Joshua Harlow)\n   8. The VM got incorrect DNS server IP (???)\n   9. Re: Directional network performance issues with Neutron	+\n      OpenvSwitch (Martinx - ?????)\n  10. Test Mail (Rajashree Thorat)\n  11. The same IP configured on different compute nodes (???)\n  12. Re: Snapshot failure with VMwareVCDriver (Gary Kotton)\n  13. The dashboard crash after attaching a volume to a VM (???)\n  14. Re: libvirtd and Folsom Quantum/Neutron and iptables\n      (Daniel P. Berrange)\n  15. ??: The dashboard crash after attaching a volume to a VM (???)\n  16. Re: ??: The dashboard crash after attaching a volume to a VM\n      (Lingala Srikanth Kumar-B37208)\n  17. Re: Migrate instances/tenants between clouds (Alexander Stellwag)\n  18. Re: Migrate instances/tenants between clouds (Alexander Stellwag)\n  19. Re: Directional network performance issues with Neutron	+\n      OpenvSwitch (Darragh O\'Reilly)\n  20. Doc or Link for enabling Active Directory authentication for\n      login information in Havana (ankush grover)\n\n\n----------------------------------------------------------------------\n\nMessage: 1\nDate: Thu, 24 Oct 2013 15:30:04 -0600\nFrom: Joe Topjian <joe.topjian at cybera.ca>\nTo: Joshua Harlow <harlowja at yahoo-inc.com>\nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Migrate instances/tenants between clouds\nMessage-ID:\n	<CAD07=DcLMFFkmOj7cufmKWJK4RLN5tsdxvq5bShiu6JDAWvZEA at mail.gmail.com>\nContent-Type: text/plain; charset=\"gb2312\"\n\nI think the ability to migrate instances and projects between clouds is\nvery valid and applies to other use cases besides avoiding an upgrade.\n\nThe instance migration process that Tim describes is one that we use, too.\nIt\'s relatively easy for end-users and requires no admin intervention.\n\nProject migration is a very interesting concept. I\'d imagine it would\ninclude things like users, key pair entries, security groups, networks, etc.\n\nI agree with Joshua about why it\'s bad to avoid upgrades. I\'ve seen a ton\nof effort go into making in-place upgrades possible and safe and it\'s very\nmuch appreciated. I upgraded an environment from Folsom to Grizzly a few\nweeks ago and none of the users noticed it happened.\n\nI definitely don\'t recommend blindly doing \"apt-get dist-upgrade\" on a\nproduction environment, though  :)\n\nOn the flip side, sometimes it can be easier to just migrate rather than\nupgrade in-place. I think where the line is drawn with that decision varies\nfrom person to person.\n\n\nOn Thu, Oct 24, 2013 at 2:56 PM, Joshua Harlow\n<harlowja at yahoo-inc.com>wrote:\n\n>  I agree its not simple (from experience),\n>\n>  There is a difference though between \'simpler for now\' and the \'right\n> thing to do\',\n>\n>  If software doesn\'t support the right thing to do (\'upgrade\',\n> \'dist-upgrade\' - or yum equivalent) then the community needs to make that\n> work (and stop with new features).\n>\n>  Otherwise the community is in a whole world of trouble. If openstack is\n> to make the life of operations & other people  better and the only way to\n> operate it is to build new regions, then something feels backwards in this\n> equation.\n>\n>  IMHO bypassing the problem is not a long-term solution (and is not\n> healthy for openstack to even recommend this).\n>\n>  I don\'t even think its a short-term solution honestly since building a\n> new region costs $$ and downtime. Who wants to do that every 6 months, I\n> can surely tell u I don\'t :)\n>\n>   From: Martinx - ????? <thiagocmartinsc at gmail.com>\n> Date: Thursday, October 24, 2013 1:17 PM\n> To: Joshua Harlow <harlowja at yahoo-inc.com>\n> Cc: Tim Bell <Tim.Bell at cern.ch>, Alexander Stellwag <\n> openstack at stellwag.net>, \"openstack at lists.openstack.org\" <\n> openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Migrate instances/tenants between clouds\n>\n>   I do not even want to try to upgrade my system...\n>\n> I know that DPKG is awesome and handle system upgrades carefully but,\n> sounds more simpler to just build a new Region...\n>\n>\n>  This doesn\'t sound trivial (like `apt-get update ; apt-get\n> dist-upgrade`):\n>\n>\n>\nhttp://www.openstack.org/summit/portland-2013/session-videos/presentation/ge\ntting-from-grizzly-to-havana-a-devops-upgrade-pattern\n>\n>  Don\'t you think!?\n>\n>\n>\n> On 24 October 2013 17:48, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>\n>> Whatever happened to doing in-place upgrades?\n>>\n>> Has that been problematic for u, are people just not doing it? If they\nare\n>> avoiding it, why?\n>>\n>> Shouldn\'t just going from folsom->havana work, if not, why not; it\nworries\n>> me that this isn\'t priority #0 if it doesn\'t work.\n>>\n>> On 10/24/13 10:51 AM, \"Tim Bell\" <Tim.Bell at cern.ch> wrote:\n>>\n>> >\n>> >Have you tried\n>> >\n>> >- snapshot\n>> >- glance download of the snapshot\n>> >- glance upload of the snapshot to new instance\n>> >- boot from snapshot\n>> >\n>> >The process we use at CERN is documented at\n>> >\n>>\nhttp://information-technology.web.cern.ch/book/cern-cloud-infrastructure-u\n>> >ser-guide/images/migrating-using-images\n>> >\n>> >This could be a good technique to document in the standard CERN\nopenstack\n>> >user guide.\n>> >\n>> >BTW, this does increase the storage in your glance server since you\'ll\n>> >loose any commonality between multiple images. So, make sure you\'ve lots\n>> >of space on Glance.\n>> >\n>> >Tim\n>> >\n>> >> -----Original Message-----\n>> >> From: Alexander Stellwag [mailto:openstack at stellwag.net]\n>> >> Sent: 24 October 2013 16:53\n>> >> To: openstack at lists.openstack.org\n>> >> Subject: [Openstack] Migrate instances/tenants between clouds\n>> >>\n>> >> Hi stackers,\n>> >>\n>> >> we\'re looking for a tool / script / blueprint to migrate instances or\n>> >>even complete tenants between multiple installations of OpenStack\n>> >> (possibly running different versions).\n>> >>\n>> >> I searched around the net but didn\'t find anything appropriate. Is any\n>> >>of you aware of such a tool?\n>> >>\n>> >> The current use-case is a migration from a folsom/nova-network based\n>> >>installation into our new havana/neutron based cloud. It is not\n>> >> necessary to migrate instances and volumes online but it should work\nat\n>> >>least semi-automatically to make it usable in large deployments.\n>> >>\n>> >> Any hints would be greatly appreciated.\n>> >>\n>> >> Cheers,\n>> >> Alex\n>> >> --\n>> >> Alexander Stellwag\n>> >> Deutsche Telekom AG Products & Innovation Infrastructure Design\n>> >\n>> >\n>> >_______________________________________________\n>> >Mailing list:\n>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> >Post to     : openstack at lists.openstack.org\n>> >Unsubscribe :\n>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>> _______________________________________________\n>> Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n\n-- \nJoe Topjian\nSystems Architect\nCybera Inc.\n\nwww.cybera.ca\n\nCybera is a not-for-profit organization that works to spur and support\ninnovation, for the economic benefit of Alberta, through the use\nof cyberinfrastructure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL:\n<http://lists.openstack.org/pipermail/openstack/attachments/20131024/b92c35a\n0/attachment-0001.html>\n\n------------------------------\n\nMessage: 2\nDate: Fri, 25 Oct 2013 11:03:16 +1300\nFrom: Robert Collins <robertc at robertcollins.net>\nTo: Shane Johnson <sdj at rasmussenequipment.com>\nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Migrate instances/tenants between clouds\nMessage-ID:\n	<CAJ3HoZ1+c+=1gsd=JLXdxQ8hNkMAoVQGtZx1112BSPCZ3LVRJg at mail.gmail.com>\nContent-Type: text/plain; charset=ISO-8859-1\n\nOn 25 October 2013 10:20, Shane Johnson <sdj at rasmussenequipment.com> wrote:\n\n>\n>\n> But doesn\'t that responsibility lie with the package maintainers for\n> Openstack in each distro?\n\nNo. The responsibility for making it possible to upgrade in place\n*reliably* and *with confidence* is an entirely upstream problem.\nRigorous backwards compatibility, rigorous testing for performance\nregressions, reliable upgrade paths, being able to achieve low/no\ndowntime on the cloud during upgrade. All upstream problems.\n\nPutting the code into packages and making the packages install well is\na distribution problem. For distributions with orchestration code tied\ninto them, orchestrating the upgrade is also a distribution problem\n(e.g. RDO and UO both offer fully orchestrated deployments, so any\nupgrade orchestration will be bundled there).\n\n-Rob\n\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n\n------------------------------\n\nMessage: 3\nDate: Thu, 24 Oct 2013 15:28:02 -0700\nFrom: Razique Mahroua <razique.mahroua at gmail.com>\nTo: ??? <dongjh at nci.com.cn>\nCc: openstack <Openstack at lists.openstack.org>\nSubject: Re: [Openstack] Help for creating the bridge br100\nMessage-ID: <25E77099-8A48-4CDE-8B17-83837D0CCC24 at gmail.com>\nContent-Type: text/plain; charset=\"utf-8\"\n\nNo you don?t have to.\nCheck the instance? log to see if it retrieves an IP :)\n\nLe 23 oct. 2013 ? 23:34, ??? <dongjh at nci.com.cn> a ?crit :\n\n>  \n> Sure.\n>  \n> root at controller:~# nova secgroup-list\n> +----+---------+-------------+\n> | Id | Name    | Description |\n> +----+---------+-------------+\n> | 1  | default | default     |\n> +----+---------+-------------+\n> root at controller:~# nova secgroup-list-rules 1\n> +-------------+-----------+---------+-----------+--------------+\n> | IP Protocol | From Port | To Port | IP Range  | Source Group |\n> +-------------+-----------+---------+-----------+--------------+\n> | tcp         | 22        | 22      | 0.0.0.0/0 |              |\n> | icmp        | -1        | -1      | 0.0.0.0/0 |              |\n> +-------------+-----------+---------+-----------+--------------+\n>  \n> From: Razique Mahroua\n> Date: 2013-10-24 14:25\n> To: ???\n> CC: openstack\n> Subject: Re: [Openstack] Help for creating the bridge br100\n> Did you created the security rules for ICMP echo req/reply ?\n> \n> On Oct 23, 2013, at 22:40, ??? <dongjh at nci.com.cn> wrote:\n> \n>>  \n>> Hi Mahroua,\n>>  \n>> As you suggested, i started the instances after adding the bridge br100\nmanually, the VM\'s started successfully, but were not pingable, however the\nIP for the bridge itself was pingable, what is the issue?  Should i assoiate\na physical NIC with br100?\n>>  \n>> root at compute1:~# nova list\n>>\n+--------------------------------------+--------+--------+------------+-----\n--------+----------------------+\n>> | ID                                   | Name   | Status | Task State |\nPower State | Networks             |\n>>\n+--------------------------------------+--------+--------+------------+-----\n--------+----------------------+\n>> | 4560a831-e3e4-4db9-860e-361834d9cca4 | cirrOS | ACTIVE | None       |\nRunning     | vmnet=192.168.11.195 |\n>> | ac659c91-520b-4b35-8d0d-7a5f2a6c82c4 | cirrOS | ACTIVE | None       |\nRunning     | vmnet=192.168.11.196 |\n>>\n+--------------------------------------+--------+--------+------------+-----\n--------+----------------------+\n>> root at compute1:~# ip addr\n>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n>>     inet 127.0.0.1/8 scope host lo\n>>     inet 169.254.169.254/32 scope link lo\n>>     inet6 ::1/128 scope host\n>>        valid_lft forever preferred_lft forever\n>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP\nqlen 1000\n>>     link/ether b8:ca:3a:ec:66:8c brd ff:ff:ff:ff:ff:ff\n>>     inet6 fe80::baca:3aff:feec:668c/64 scope link\n>>        valid_lft forever preferred_lft forever\n>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000\n>>     link/ether b8:ca:3a:ec:66:8e brd ff:ff:ff:ff:ff:ff\n>> 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000\n>>     link/ether b8:ca:3a:ec:66:90 brd ff:ff:ff:ff:ff:ff\n>> 5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000\n>>     link/ether b8:ca:3a:ec:66:92 brd ff:ff:ff:ff:ff:ff\n>> 6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP\nqlen 1000\n>>     link/ether 00:0a:f7:24:1e:40 brd ff:ff:ff:ff:ff:ff\n>>     inet 10.10.10.182/24 brd 10.10.10.255 scope global eth4\n>>     inet6 fe80::20a:f7ff:fe24:1e40/64 scope link\n>>        valid_lft forever preferred_lft forever\n>> 7: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000\n>>     link/ether 00:0a:f7:24:1e:42 brd ff:ff:ff:ff:ff:ff\n>> 9: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue\nstate DOWN\n>>     link/ether b2:43:fa:53:cc:11 brd ff:ff:ff:ff:ff:ff\n>>     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0\n>> 10: br100: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN\n>>     link/ether fa:16:3e:f3:f0:04 brd ff:ff:ff:ff:ff:ff\n>>     inet 192.168.11.193/27 brd 192.168.11.223 scope global br100\n>> 11: vlan100 at br100: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop\nmaster br100 state DOWN\n>>     link/ether fa:16:3e:f3:f0:04 brd ff:ff:ff:ff:ff:ff\n>> 12: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast\nmaster br100 state UNKNOWN qlen 500\n>>     link/ether fe:16:3e:fa:60:5c brd ff:ff:ff:ff:ff:ff\n>>     inet6 fe80::fc16:3eff:fefa:605c/64 scope link\n>>        valid_lft forever preferred_lft forever\n>> root at compute1:~# ifconfig -a\n>> br100     Link encap:Ethernet  HWaddr fa:16:3e:f3:f0:04\n>>           inet addr:192.168.11.193  Bcast:192.168.11.223\nMask:255.255.255.224\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:0\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>  \n>> eth0      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:8c\n>>           inet6 addr: fe80::baca:3aff:feec:668c/64 Scope:Link\n>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>>           RX packets:28816 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:2514 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:2924850 (2.9 MB)  TX bytes:868260 (868.2 KB)\n>>           Interrupt:34 Memory:d1000000-d17fffff\n>>  \n>> eth1      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:8e\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>           Interrupt:36 Memory:d2000000-d27fffff\n>>  \n>> eth2      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:90\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>           Interrupt:36 Memory:d3000000-d37fffff\n>>  \n>> eth3      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:92\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>           Interrupt:37 Memory:d4000000-d47fffff\n>>  \n>> eth4      Link encap:Ethernet  HWaddr 00:0a:f7:24:1e:40\n>>           inet addr:10.10.10.182  Bcast:10.10.10.255  Mask:255.255.255.0\n>>           inet6 addr: fe80::20a:f7ff:fe24:1e40/64 Scope:Link\n>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>>           RX packets:243487 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:238920 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:94402647 (94.4 MB)  TX bytes:58522363 (58.5 MB)\n>>           Interrupt:72 Memory:c8000000-c87fffff\n>>  \n>> eth5      Link encap:Ethernet  HWaddr 00:0a:f7:24:1e:42\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:1000\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>           Interrupt:76 Memory:c9000000-c97fffff\n>>  \n>> lo        Link encap:Local Loopback\n>>           inet addr:127.0.0.1  Mask:255.0.0.0\n>>           inet6 addr: ::1/128 Scope:Host\n>>           UP LOOPBACK RUNNING  MTU:16436  Metric:1\n>>           RX packets:8 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:8 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:0\n>>           RX bytes:672 (672.0 B)  TX bytes:672 (672.0 B)\n>>  \n>> virbr0    Link encap:Ethernet  HWaddr b2:43:fa:53:cc:11\n>>           inet addr:192.168.122.1  Bcast:192.168.122.255\nMask:255.255.255.0\n>>           UP BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:0\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>  \n>> vlan100   Link encap:Ethernet  HWaddr fa:16:3e:f3:f0:04\n>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:0\n>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>  \n>> vnet0     Link encap:Ethernet  HWaddr fe:16:3e:fa:60:5c\n>>           inet6 addr: fe80::fc16:3eff:fefa:605c/64 Scope:Link\n>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>>           RX packets:9 errors:0 dropped:0 overruns:0 frame:0\n>>           TX packets:6 errors:0 dropped:0 overruns:0 carrier:0\n>>           collisions:0 txqueuelen:500\n>>           RX bytes:1434 (1.4 KB)  TX bytes:468 (468.0 B)\n>>  \n>> root at compute1:~# ping 192.168.11.193\n>> PING 192.168.11.193 (192.168.11.193) 56(84) bytes of data.\n>> 64 bytes from 192.168.11.193: icmp_req=1 ttl=64 time=0.070 ms\n>> 64 bytes from 192.168.11.193: icmp_req=2 ttl=64 time=0.036 ms\n>> ^C\n>> --- 192.168.11.193 ping statistics ---\n>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms\n>> rtt min/avg/max/mdev = 0.036/0.053/0.070/0.017 ms\n>> root at compute1:~# ping 192.168.11.195\n>> connect: Network is unreachable\n>> root at compute1:~# ping 192.168.11.196\n>> connect: Network is unreachable\n>> root at compute1:~# brctl show br100\n>> bridge name     bridge id               STP enabled     interfaces\n>> br100           8000.fa163ef3f004       no              vlan100\n>>\nvnet0\n>>  \n>>  \n>> From: Razique Mahroua\n>> Date: 2013-10-24 12:23\n>> To: ???\n>> CC: Openstack\n>> Subject: Re: [Openstack] Help for creating the bridge br100\n>> Hi, \n>> you can try:\n>> brctl addbr br100\n>> then restart nova-network and nova-compute services, they\'ll hook it up\ncorrectly :)\n>> \n>> Le 23 oct. 2013 ? 04:55, ??? <dongjh at nci.com.cn> a ?crit :\n>> \n>>> Hello all,\n>>>  \n>>> I\'m trying to install openstack and lauch the first VM, following with\nthe installation guide \"openstack-install-guide-apt-havana.pdf\". I have one\ncontroller node plus two compute nodes.\n>>>  \n>>> After creating the network vmnet, i tried to lauch the first CirrOS VM,\ni saw the bridge br100 was created on the first compute node automatically,\nand an IP was assigned to this new created bridge(the last valid IP in vmnet\nsubnet), however i found the netmask for vmnet was not correct, so i removed\nthe bridge br100 from the first compute node via \'brctl\' command, then\nremoved the network \'vmnet\' via the commands \"nova network-disassociate\" and\n\"nova net-delete\", finally i added the network \'vmnet\' back with the correct\nnetmask. After doing that, when i try to lauch a VM, it will fail, the error\nmessage is \'cannot setup interface: No such device\', even if you stop the\n\'nova-network\' and \'nova-compute\' services on the first compute node(i.e.\nthe same issue on the second compute node), and sometimes when i restart the\n\'nova-network\' and \'nova-compute\' services on the compute nodes, it will\nthrow out the similar error messages, and the services fail to start, but\nnot always.\n>>>  \n>>> How can i have nova create the bridge br100 on the compute nodes\nautomatically? Should i clean the mysql database or re-install the\nnova-network package on the compute nodes?\n>>>  \n>>> Thanks.\n>>>  \n>>> root at controller:~# nova image-list\n>>>\n+--------------------------------------+--------------+--------+--------+\n>>> | ID                                   | Name         | Status | Server\n|\n>>>\n+--------------------------------------+--------------+--------+--------+\n>>> | 26fa8866-d075-444d-9844-61b7c22e724b | CirrOS 0.3.1 | ACTIVE |\n|\n>>>\n+--------------------------------------+--------------+--------+--------+\n>>> root at controller:~# nova help start\n>>> usage: nova start <server>\n>>>  \n>>> Start a server.\n>>>  \n>>> Positional arguments:\n>>>   <server>  Name or ID of server.\n>>> root at controller:~#  nova boot --flavor 1 --key_name mykey --image\n26fa8866-d075-444d-9844-61b7c22e724b --security_group default cirrOS\n>>>\n+--------------------------------------+------------------------------------\n--+\n>>> | Property                             | Value\n|\n>>>\n+--------------------------------------+------------------------------------\n--+\n>>> | OS-EXT-STS:task_state                | scheduling\n|\n>>> | image                                | CirrOS 0.3.1\n|\n>>> | OS-EXT-STS:vm_state                  | building\n|\n>>> | OS-EXT-SRV-ATTR:instance_name        | instance-0000000b\n|\n>>> | OS-SRV-USG:launched_at               | None\n|\n>>> | flavor                               | m1.tiny\n|\n>>> | id                                   |\n0d3afadb-ec5c-4f26-ad7f-707679be6b3a |\n>>> | security_groups                      | [{u\'name\': u\'default\'}]\n|\n>>> | user_id                              |\neecb2b5f2b4f481980a5546af680481c     |\n>>> | OS-DCF:diskConfig                    | MANUAL\n|\n>>> | accessIPv4                           |\n|\n>>> | accessIPv6                           |\n|\n>>> | progress                             | 0\n|\n>>> | OS-EXT-STS:power_state               | 0\n|\n>>> | OS-EXT-AZ:availability_zone          | nova\n|\n>>> | config_drive                         |\n|\n>>> | status                               | BUILD\n|\n>>> | updated                              | 2013-10-23T11:40:23Z\n|\n>>> | hostId                               |\n|\n>>> | OS-EXT-SRV-ATTR:host                 | None\n|\n>>> | OS-SRV-USG:terminated_at             | None\n|\n>>> | key_name                             | mykey\n|\n>>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | None\n|\n>>> | name                                 | cirrOS\n|\n>>> | adminPass                            | FSUxpN9QrkhC\n|\n>>> | tenant_id                            |\n382ce85ef00948a3a1442e44f9d033ed     |\n>>> | created                              | 2013-10-23T11:40:23Z\n|\n>>> | os-extended-volumes:volumes_attached | []\n|\n>>> | metadata                             | {}\n|\n>>>\n+--------------------------------------+------------------------------------\n--+\n>>> root at controller:~# nova show 0d3afadb-ec5c-4f26-ad7f-707679be6b3a\n>>>\n+--------------------------------------+------------------------------------\n----------------------------------------------------------------------------\n-------------------+\n>>> | Property                             | Value\n|\n>>>\n+--------------------------------------+------------------------------------\n----------------------------------------------------------------------------\n-------------------+\n>>> | status                               | ERROR\n|\n>>> | updated                              | 2013-10-23T11:40:29Z\n|\n>>> | OS-EXT-STS:task_state                | None\n|\n>>> | OS-EXT-SRV-ATTR:host                 | compute1\n|\n>>> | key_name                             | mykey\n|\n>>> | image                                | CirrOS 0.3.1\n(26fa8866-d075-444d-9844-61b7c22e724b)\n|\n>>> | vmnet network                        | 192.168.11.195\n|\n>>> | hostId                               |\n5ce24c402b2346e375fca2455e0d6dbaf0405f2d46b1e6eaf3b30742\n|\n>>> | OS-EXT-STS:vm_state                  | error\n|\n>>> | OS-EXT-SRV-ATTR:instance_name        | instance-0000000b\n|\n>>> | OS-SRV-USG:launched_at               | None\n|\n>>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | compute1\n|\n>>> | flavor                               | m1.tiny (1)\n|\n>>> | id                                   |\n0d3afadb-ec5c-4f26-ad7f-707679be6b3a\n|\n>>> | security_groups                      | [{u\'name\': u\'default\'}]\n|\n>>> | OS-SRV-USG:terminated_at             | None\n|\n>>> | user_id                              |\neecb2b5f2b4f481980a5546af680481c\n|\n>>> | name                                 | cirrOS\n|\n>>> | created                              | 2013-10-23T11:40:23Z\n|\n>>> | tenant_id                            |\n382ce85ef00948a3a1442e44f9d033ed\n|\n>>> | OS-DCF:diskConfig                    | MANUAL\n|\n>>> | metadata                             | {}\n|\n>>> | os-extended-volumes:volumes_attached | []\n|\n>>> | accessIPv4                           |\n|\n>>> | accessIPv6                           |\n|\n>>> | fault                                | {u\'message\': u\"Remote error:\nProcessExecutionError Unexpected error while running command.\n|\n>>> |                                      | Command: sudo nova-rootwrap\n/etc/nova/rootwrap.conf dhcp_release br100 192.168.11.195 fa:16:3e:13:e9:90\n|\n>>> |                                      | Exit code: 1\n|\n>>> |                                      | Stdout: \'\'\n|\n>>> |                                      | Stderr: \'cannot setup\ninterface: No such device\\\n|\n>>> |                                      | \'\n|\n>>> |                                      | \", u\'code\': 500, u\'details\': u\'\nFile \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 258,\nin decorated_function |\n>>> |                                      |     return function(self,\ncontext, *args, **kwargs)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1613, in\nrun_instance                                     |\n>>> |                                      |     do_run_instance()\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py\", line\n246, in inner                                  |\n>>> |                                      |     return f(*args, **kwargs)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1612, in\ndo_run_instance                                  |\n>>> |                                      |     legacy_bdm_in_spec)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 962, in\n_run_instance                                     |\n>>> |                                      |     notify(\"error\",\nmsg=unicode(e))  # notify that build failed\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 946, in\n_run_instance                                     |\n>>> |                                      |     instance, image_meta,\nlegacy_bdm_in_spec)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1075, in\n_build_instance                                  |\n>>> |                                      |     filter_properties, bdms,\nlegacy_bdm_in_spec)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1119, in\n_reschedule_or_error                             |\n>>> |                                      |\nself._log_original_error(exc_info, instance_uuid)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1114, in\n_reschedule_or_error                             |\n>>> |                                      |     bdms, requested_networks)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1664, in\n_shutdown_instance                               |\n>>> |                                      |\nself._try_deallocate_network(context, instance, requested_networks)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1624, in\n_try_deallocate_network                          |\n>>> |                                      |\nself._set_instance_error_state(context, instance[\\\'uuid\\\'])\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1619, in\n_try_deallocate_network                          |\n>>> |                                      |\nself._deallocate_network(context, instance, requested_networks)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1463, in\n_deallocate_network                              |\n>>> |                                      |     context, instance,\nrequested_networks=requested_networks)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/network/api.py\", line 93, in wrapped\n|\n>>> |                                      |     return func(self, context,\n*args, **kwargs)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/network/api.py\", line 317, in\ndeallocate_for_instance                               |\n>>> |                                      |\nself.network_rpcapi.deallocate_for_instance(context, **args)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/network/rpcapi.py\", line 193, in\ndeallocate_for_instance                            |\n>>> |                                      |     host=host,\nrequested_networks=requested_networks)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/rpcclient.py\", line 85, in call\n|\n>>> |                                      |     return\nself._invoke(self.proxy.call, ctxt, method, **kwargs)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/rpcclient.py\", line 63, in _invoke\n|\n>>> |                                      |     return cast_or_call(ctxt,\nmsg, **self.kwargs)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py\", line\n126, in call                                   |\n>>> |                                      |     result = rpc.call(context,\nreal_topic, msg, timeout)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py\",\nline 139, in call                                |\n>>> |                                      |     return\n_get_impl().call(CONF, context, topic, msg, timeout)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py\",\nline 816, in call                              |\n>>> |                                      |\nrpc_amqp.get_connection_pool(conf, Connection))\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line\n574, in call                                    |\n>>> |                                      |     rv = list(rv)\n|\n>>> |                                      |   File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line\n539, in __iter__                                |\n>>> |                                      |     raise result\n|\n>>> |                                      | \', u\'created\':\nu\'2013-10-23T11:40:29Z\'}\n|\n>>> | OS-EXT-STS:power_state               | 0\n|\n>>> | OS-EXT-AZ:availability_zone          | nova\n|\n>>> | config_drive                         |\n|\n>>>\n+--------------------------------------+------------------------------------\n----------------------------------------------------------------------------\n-------------------+\n>>> root at controller:~#\n>>>  \n>>>  \n>>> root at controller:~# nova service-list\n>>>\n+------------------+------------+----------+---------+-------+--------------\n--------------+-----------------+\n>>> | Binary           | Host       | Zone     | Status  | State |\nUpdated_at                 | Disabled Reason |\n>>>\n+------------------+------------+----------+---------+-------+--------------\n--------------+-----------------+\n>>> | nova-cert        | controller | internal | enabled | up    |\n2013-10-23T11:41:59.000000 | None            |\n>>> | nova-consoleauth | controller | internal | enabled | up    |\n2013-10-23T11:42:02.000000 | None            |\n>>> | nova-scheduler   | controller | internal | enabled | up    |\n2013-10-23T11:42:04.000000 | None            |\n>>> | nova-conductor   | controller | internal | enabled | up    |\n2013-10-23T11:42:00.000000 | None            |\n>>> | nova-network     | compute1   | internal | enabled | up    |\n2013-10-23T11:42:04.000000 | None            |\n>>> | nova-network     | compute2   | internal | enabled | up    |\n2013-10-23T11:41:56.000000 | None            |\n>>> | nova-compute     | compute1   | nova     | enabled | up    |\n2013-10-23T11:41:58.000000 | None            |\n>>> | nova-compute     | compute2   | nova     | enabled | up    |\n2013-10-23T11:42:00.000000 | None            |\n>>>\n+------------------+------------+----------+---------+-------+--------------\n--------------+-----------------+\n>>>  \n>>> root at compute1:~# ifconfig -a\n>>> eth0      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:8c\n>>>           inet6 addr: fe80::baca:3aff:feec:668c/64 Scope:Link\n>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:56 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:6989 (6.9 KB)  TX bytes:4298 (4.2 KB)\n>>>           Interrupt:34 Memory:d1000000-d17fffff\n>>>  \n>>> eth1      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:8e\n>>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>           Interrupt:36 Memory:d2000000-d27fffff\n>>>  \n>>> eth2      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:90\n>>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>           Interrupt:36 Memory:d3000000-d37fffff\n>>>  \n>>> eth3      Link encap:Ethernet  HWaddr b8:ca:3a:ec:66:92\n>>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>           Interrupt:37 Memory:d4000000-d47fffff\n>>>  \n>>> eth4      Link encap:Ethernet  HWaddr 00:0a:f7:24:1e:40\n>>>           inet addr:10.10.10.182  Bcast:10.10.10.255  Mask:255.255.255.0\n>>>           inet6 addr: fe80::20a:f7ff:fe24:1e40/64 Scope:Link\n>>>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:551 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:476 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:95077 (95.0 KB)  TX bytes:70754 (70.7 KB)\n>>>           Interrupt:72 Memory:c8000000-c87fffff\n>>>  \n>>> eth5      Link encap:Ethernet  HWaddr 00:0a:f7:24:1e:42\n>>>           BROADCAST MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:1000\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>           Interrupt:76 Memory:c9000000-c97fffff\n>>>  \n>>> lo        Link encap:Local Loopback\n>>>           inet addr:127.0.0.1  Mask:255.0.0.0\n>>>           inet6 addr: ::1/128 Scope:Host\n>>>           UP LOOPBACK RUNNING  MTU:16436  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:0\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>  \n>>> virbr0    Link encap:Ethernet  HWaddr b2:43:fa:53:cc:11\n>>>           inet addr:192.168.122.1  Bcast:192.168.122.255\nMask:255.255.255.0\n>>>           UP BROADCAST MULTICAST  MTU:1500  Metric:1\n>>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n>>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n>>>           collisions:0 txqueuelen:0\n>>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n>>>  \n>>>  \n>>> My internal NIC is eth4 and eth0 will be the bridge/public interface.\n>>>  \n>>>  \n>>> _______________________________________________\n>>> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe :\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL:\n<http://lists.openstack.org/pipermail/openstack/attachments/20131024/01256c5\n2/attachment-0001.html>\n\n------------------------------\n\nMessage: 4\nDate: Thu, 24 Oct 2013 22:57:54 +0000\nFrom: Joshua Harlow <harlowja at yahoo-inc.com>\nTo: Robert Collins <robertc at robertcollins.net>, Shane Johnson\n	<sdj at rasmussenequipment.com>\nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Migrate instances/tenants between clouds\nMessage-ID: <CE8EF36D.4AD51%harlowja at yahoo-inc.com>\nContent-Type: text/plain; charset=\"us-ascii\"\n\nCompletely agree, and I think there are many people that know its an\nissue, which is positive news.\n\nThere are always people who \'pave\' over there clouds instead, which to me\nis not positive news;\n\nIn fact I think such activities are detrimental to the whole community\n(your opinion may vary).\n\nTo me this is why openstack **must** provide a reference cloud and do as\nmany of these rigorous activities \"checking\" automatically.\n\n-Josh\n\nOn 10/24/13 3:03 PM, \"Robert Collins\" <robertc at robertcollins.net> wrote:\n\n>On 25 October 2013 10:20, Shane Johnson <sdj at rasmussenequipment.com>\n>wrote:\n>\n>>\n>>\n>> But doesn\'t that responsibility lie with the package maintainers for\n>> Openstack in each distro?\n>\n>No. The responsibility for making it possible to upgrade in place\n>*reliably* and *with confidence* is an entirely upstream problem.\n>Rigorous backwards compatibility, rigorous testing for performance\n>regressions, reliable upgrade paths, being able to achieve low/no\n>downtime on the cloud during upgrade. All upstream problems.\n>\n>Putting the code into packages and making the packages install well is\n>a distribution problem. For distributions with orchestration code tied\n>into them, orchestrating the upgrade is also a distribution problem\n>(e.g. RDO and UO both offer fully orchestrated deployments, so any\n>upgrade orchestration will be bundled there).\n>\n>-Rob\n>\n>\n>-- \n>Robert Collins <rbtcollins at hp.com>\n>Distinguished Technologist\n>HP Converged Cloud\n>\n>_______________________________________________\n>Mailing list: \n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to     : openstack at lists.openstack.org\n>Unsubscribe : \n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n------------------------------\n\nMessage: 5\nDate: Fri, 25 Oct 2013 12:00:11 +1300\nFrom: Robert Collins <robertc at robertcollins.net>\nTo: Joshua Harlow <harlowja at yahoo-inc.com>\nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Migrate instances/tenants between clouds\nMessage-ID:\n	<CAJ3HoZ1E9D27J5b-cqx=-Yj7qxiUVNFc+NaniXzxQHHX8MZsjg at mail.gmail.com>\nContent-Type: text/plain; charset=ISO-8859-1\n\nOn 25 October 2013 11:57, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n> Completely agree, and I think there are many people that know its an\n> issue, which is positive news.\n>\n> There are always people who \'pave\' over there clouds instead, which to me\n> is not positive news;\n>\n> In fact I think such activities are detrimental to the whole community\n> (your opinion may vary).\n>\n> To me this is why openstack **must** provide a reference cloud and do as\n> many of these rigorous activities \"checking\" automatically.\n>\n> -Josh\n\nhttps://wiki.openstack.org/TripleO/TripleOCloud :)\n\n-Rob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n\n------------------------------\n\nMessage: 6\nDate: Thu, 24 Oct 2013 16:02:04 -0700\nFrom: \"Craig E. Ward\" <cward at isi.edu>\nTo: OpenStack Mailing List <openstack at lists.openstack.org>\nSubject: [Openstack] libvirtd and Folsom Quantum/Neutron and iptables\nMessage-ID: <5269A6EC.1 at ISI.EDU>\nContent-Type: text/plain; charset=UTF-8; format=flowed\n\nI have a Folsom installation that has re-tasked some of the host hardware.\nWhat \nwas a nova compute node is now a Quantum (agent) node. In the conversion,\nthe \nlibvirtd service was not removed. It looks like it could be cause some\nissues \nwith the iptables rules.\n\nWill libvirtd insert rules that may conflict with the rules inserted by \nQuautum? Or do I need to look elsewhere for conflicts?\n\nIs there any reason to leave libvirtd running on a Folsom Quantum node?\n\nThanks,\n\nCraig\n-- \nCraig E. Ward\nUSC Information Sciences Institute\ncward at ISI.EDU\n\n\n\n------------------------------\n\nMessage: 7\nDate: Thu, 24 Oct 2013 23:05:54 +0000\nFrom: Joshua Harlow <harlowja at yahoo-inc.com>\nTo: Robert Collins <robertc at robertcollins.net>\nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Migrate instances/tenants between clouds\nMessage-ID: <CE8EF55A.4AD5B%harlowja at yahoo-inc.com>\nContent-Type: text/plain; charset=\"iso-8859-1\"\n\nYup, of course, that is being worked on, and I hope it is that :-)\n\nIt just scares me and others that it took this long; I think partly due to\nthe pave your cloud approach.\n\nThat?s part of what just feels backwards to me; how we ever got in this\nsituation in the first place that paving was considered a valid approach.\n\nOn 10/24/13 4:00 PM, \"Robert Collins\" <robertc at robertcollins.net> wrote:\n\n>On 25 October 2013 11:57, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>> Completely agree, and I think there are many people that know its an\n>> issue, which is positive news.\n>>\n>> There are always people who \'pave\' over there clouds instead, which to\n>>me\n>> is not positive news;\n>>\n>> In fact I think such activities are detrimental to the whole community\n>> (your opinion may vary).\n>>\n>> To me this is why openstack **must** provide a reference cloud and do as\n>> many of these rigorous activities \"checking\" automatically.\n>>\n>> -Josh\n>\n>https://wiki.openstack.org/TripleO/TripleOCloud :)\n>\n>-Rob\n>\n>-- \n>Robert Collins <rbtcollins at hp.com>\n>Distinguished Technologist\n>HP Converged Cloud\n\n\n\n\n------------------------------\n\nMessage: 8\nDate: Fri, 25 Oct 2013 10:53:14 +0800\nFrom: ??? <dongjh at nci.com.cn>\nTo: openstack <openstack at lists.openstack.org>\nSubject: [Openstack] The VM got incorrect DNS server IP\nMessage-ID: <2013102510531072487314 at nci.com.cn>\nContent-Type: text/plain; charset=\"gb2312\"\n\nHi all,\n\nI set the --dns1 and --dns2 when creating the vmnet, however the VM instance\nget the default gatway IP as it\'s DNS server, what is the issue?\n\nroot at controller:~# nova network-create vmnet --bridge-interface=br100\n--multi-host=T --gateway=192.168.11.254 --dns1=221.12.1.227\n--dns2=221.12.1.228 \n\nroot at controller:~# nova network-show d960f9aa-647a-4fa6-97d4-bc9e8b322015\n+---------------------+--------------------------------------+\n| Property            | Value                                |\n+---------------------+--------------------------------------+\n| bridge              | br100                                |\n| vpn_public_port     | 1000                                 |\n| dhcp_start          | 192.168.11.3                         |\n| bridge_interface    | br100                                |\n| updated_at          | 2013-10-25T02:01:38.000000           |\n| id                  | d960f9aa-647a-4fa6-97d4-bc9e8b322015 |\n| cidr_v6             | None                                 |\n| deleted_at          | None                                 |\n| gateway             | 192.168.11.254                       |\n| rxtx_base           | None                                 |\n| label               | vmnet                                |\n| priority            | None                                 |\n| project_id          | 382ce85ef00948a3a1442e44f9d033ed     |\n| vpn_private_address | 192.168.11.2                         |\n| deleted             | 0                                    |\n| vlan                | 100                                  |\n| broadcast           | 192.168.11.255                       |\n| netmask             | 255.255.255.0                        |\n| injected            | False                                |\n| cidr                | 192.168.11.0/24                      |\n| vpn_public_address  | 10.10.10.182                         |\n| multi_host          | True                                 |\n| dns2                | 221.12.1.228                         |\n| created_at          | 2013-10-25T01:47:05.000000           |\n| host                | None                                 |\n| gateway_v6          | None                                 |\n| netmask_v6          | None                                 |\n| dns1                | 221.12.1.227                         |\n+---------------------+--------------------------------------+\n\nroot at controller:~# nova boot --flavor 1 --key_name mykey --image\n26fa8866-d075-444d-9844-61b7c22e724b  --security-groups  default CirrOS \n\nroot at controller:~# nova console-log CirrOS\n[    0.000000] Initializing cgroup subsys cpuset\n[    0.000000] Initializing cgroup subsys cpu\n[    0.000000] Linux version 3.2.0-37-virtual (buildd at allspice) (gcc version\n4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #58-Ubuntu SMP Thu Jan 24 15:48:03\nUTC 2013 (Ubuntu 3.2.0-37.58-virtual 3.2.35)\n[    0.000000] Command line: LABEL=cirros-rootfs ro console=tty1\nconsole=ttyS0\n[    0.000000] KERNEL supported cpus:\n[    0.000000]   Intel GenuineIntel\n[    0.000000]   AMD AuthenticAMD\n[    0.000000]   Centaur CentaurHauls\n[    0.000000] BIOS-provided physical RAM map:\n[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)\n[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)\n[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)\n[    0.000000]  BIOS-e820: 0000000000100000 - 000000001fffe000 (usable)\n[    0.000000]  BIOS-e820: 000000001fffe000 - 0000000020000000 (reserved)\n[    0.000000]  BIOS-e820: 00000000feffc000 - 00000000ff000000 (reserved)\n[    0.000000]  BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)\n[    0.000000] NX (Execute Disable) protection: active\n[    0.000000] DMI 2.4 present.\n[    0.000000] No AGP bridge found\n[    0.000000] last_pfn = 0x1fffe max_arch_pfn = 0x400000000\n[    0.000000] x86 PAT enabled: cpu 0, old 0x70406, new 0x7010600070106\n[    0.000000] found SMP MP-table at [ffff8800000f1610] f1610\n[    0.000000] Using GB pages for direct mapping\n[    0.000000] init_memory_mapping: 0000000000000000-000000001fffe000\n[    0.000000] RAMDISK: 1fc96000 - 1ffee000\n[    0.000000] ACPI: RSDP 00000000000f1470 00014 (v00 BOCHS )\n[    0.000000] ACPI: RSDT 000000001fffe450 00034 (v01 BOCHS  BXPCRSDT\n00000001 BXPC 00000001)\n[    0.000000] ACPI: FACP 000000001fffff80 00074 (v01 BOCHS  BXPCFACP\n00000001 BXPC 00000001)\n[    0.000000] ACPI: DSDT 000000001fffe490 01137 (v01   BXPC   BXDSDT\n00000001 INTL 20100528)\n[    0.000000] ACPI: FACS 000000001fffff40 00040\n[    0.000000] ACPI: SSDT 000000001ffff700 00838 (v01 BOCHS  BXPCSSDT\n00000001 BXPC 00000001)\n[    0.000000] ACPI: APIC 000000001ffff610 00078 (v01 BOCHS  BXPCAPIC\n00000001 BXPC 00000001)\n[    0.000000] ACPI: HPET 000000001ffff5d0 00038 (v01 BOCHS  BXPCHPET\n00000001 BXPC 00000001)\n[    0.000000] No NUMA configuration found\n[    0.000000] Faking a node at 0000000000000000-000000001fffe000\n[    0.000000] Initmem setup node 0 0000000000000000-000000001fffe000\n[    0.000000]   NODE_DATA [000000001fff6000 - 000000001fffafff]\n[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00\n[    0.000000] kvm-clock: cpu 0, msr 0:1cf7681, boot clock\n[    0.000000] Zone PFN ranges:\n[    0.000000]   DMA      0x00000010 -> 0x00001000\n[    0.000000]   DMA32    0x00001000 -> 0x00100000\n[    0.000000]   Normal   empty\n[    0.000000] Movable zone start PFN for each node\n[    0.000000] early_node_map[2] active PFN ranges\n[    0.000000]     0: 0x00000010 -> 0x0000009f\n[    0.000000]     0: 0x00000100 -> 0x0001fffe\n[    0.000000] ACPI: PM-Timer IO Port: 0xb008\n[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)\n[    0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])\n[    0.000000] ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0])\n[    0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI\n0-23\n[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)\n[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)\n[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)\n[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)\n[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)\n[    0.000000] Using ACPI (MADT) for SMP configuration information\n[    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000\n[    0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs\n[    0.000000] PM: Registered nosave memory: 000000000009f000 -\n00000000000a0000\n[    0.000000] PM: Registered nosave memory: 00000000000a0000 -\n00000000000f0000\n[    0.000000] PM: Registered nosave memory: 00000000000f0000 -\n0000000000100000\n[    0.000000] Allocating PCI resources starting at 20000000 (gap:\n20000000:deffc000)\n[    0.000000] Booting paravirtualized kernel on KVM\n[    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:1\nnr_node_ids:1\n[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88001fa00000 s82880 r8192\nd23616 u2097152\n[    0.000000] kvm-clock: cpu 0, msr 0:1fa13681, primary cpu clock\n[    0.000000] KVM setup async PF for cpu 0\n[    0.000000] kvm-stealtime: cpu 0, msr 1fa0dd40\n[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total\npages: 128904\n[    0.000000] Policy zone: DMA32\n[    0.000000] Kernel command line: LABEL=cirros-rootfs ro console=tty1\nconsole=ttyS0\n[    0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)\n[    0.000000] xsave/xrstor: enabled xstate_bv 0x7, cntxt size 0x340\n[    0.000000] Checking aperture...\n[    0.000000] No AGP bridge found\n[    0.000000] Memory: 496328k/524280k available (6541k kernel code, 452k\nabsent, 27500k reserved, 6652k data, 924k init)\n[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,\nCPUs=1, Nodes=1\n[    0.000000] Hierarchical RCU implementation.\n[    0.000000]  RCU dyntick-idle grace-period acceleration is enabled.\n[    0.000000] NR_IRQS:4352 nr_irqs:256 16\n[    0.000000] Console: colour VGA+ 80x25\n[    0.000000] console [tty1] enabled\n[    0.000000] console [ttyS0] enabled\n[    0.000000] allocated 4194304 bytes of page_cgroup\n[    0.000000] please try \'cgroup_disable=memory\' option if you don\'t want\nmemory cgroups\n[    0.000000] Detected 1799.999 MHz processor.\n[    0.008000] Calibrating delay loop (skipped) preset value.. 3599.99\nBogoMIPS (lpj=7199996)\n[    0.008012] pid_max: default: 32768 minimum: 301\n[    0.009908] Security Framework initialized\n[    0.012034] AppArmor: AppArmor initialized\n[    0.013761] Yama: becoming mindful.\n[    0.016149] Dentry cache hash table entries: 65536 (order: 7, 524288\nbytes)\n[    0.018938] Inode-cache hash table entries: 32768 (order: 6, 262144\nbytes)\n[    0.020103] Mount-cache hash table entries: 256\n[    0.024189] Initializing cgroup subsys cpuacct\n[    0.026036] Initializing cgroup subsys memory\n[    0.028027] Initializing cgroup subsys devices\n[    0.029856] Initializing cgroup subsys freezer\n[    0.031662] Initializing cgroup subsys blkio\n[    0.032021] Initializing cgroup subsys perf_event\n[    0.034066] mce: CPU supports 10 MCE banks\n[    0.036514] SMP alternatives: switching to UP code\n[    0.067550] Freeing SMP alternatives: 24k freed\n[    0.068013] ACPI: Core revision 20110623\n[    0.070122] ftrace: allocating 27027 entries in 106 pages\n[    0.076340] Enabling x2apic\n[    0.077224] Enabled x2apic\n[    0.078324] Switched APIC routing to physical x2apic.\n[    0.081445] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1\n[    0.084007] CPU0: Intel Xeon E312xx (Sandy Bridge) stepping 01\n[    0.088004] Performance Events: SandyBridge events, Intel PMU driver.\n[    0.088004] PEBS disabled due to CPU errata.\n[    0.088004] ... version:                2\n[    0.088008] ... bit width:              48\n[    0.089110] ... generic registers:      8\n[    0.090209] ... value mask:             0000ffffffffffff\n[    0.091558] ... max period:             000000007fffffff\n[    0.092008] ... fixed-purpose events:   3\n[    0.093109] ... event mask:             00000007000000ff\n[    0.097374] NMI watchdog enabled, takes one hw-pmu counter.\n[    0.098954] Brought up 1 CPUs\n[    0.099872] Total of 1 processors activated (3599.99 BogoMIPS).\n[    0.100460] devtmpfs: initialized\n[    0.102153] EVM: security.selinux\n[    0.104034] EVM: security.SMACK64\n[    0.105015] EVM: security.capability\n[    0.106990] print_constraints: dummy:\n[    0.108127] RTC time:  2:01:50, date: 10/25/13\n[    0.109376] NET: Registered protocol family 16\n[    0.110719] ACPI: bus type pci registered\n[    0.112166] PCI: Using configuration type 1 for base access\n[    0.114470] bio: create slab <bio-0> at 0\n[    0.116122] ACPI: Added _OSI(Module Device)\n[    0.117299] ACPI: Added _OSI(Processor Device)\n[    0.118488] ACPI: Added _OSI(3.0 _SCP Extensions)\n[    0.119729] ACPI: Added _OSI(Processor Aggregator Device)\n[    0.124139] ACPI: Interpreter enabled\n[    0.125195] ACPI: (supports S0 S3 S4 S5)\n[    0.126770] ACPI: Using IOAPIC for interrupt routing\n[    0.131027] ACPI: No dock devices found.\n[    0.132027] HEST: Table not found.\n[    0.133012] PCI: Using host bridge windows from ACPI; if necessary, use\n\"pci=nocrs\" and report a bug\n[    0.135410] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])\n[    0.136153] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]\n[    0.137816] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]\n[    0.140028] pci_root PNP0A03:00: host bridge window [mem\n0x000a0000-0x000bffff]\n[    0.142002] pci_root PNP0A03:00: host bridge window [mem\n0x80000000-0xfebfffff]\n[    0.163047] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4\nACPI\n[    0.164041] pci 0000:00:01.3: quirk: [io  0xb100-0xb10f] claimed by PIIX4\nSMB\n[    0.227143]  pci0000:00: Unable to request _OSC control (_OSC support\nmask: 0x1e)\n[    0.232237] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)\n[    0.234357] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)\n[    0.236134] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)\n[    0.238233] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)\n[    0.240585] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)\n[    0.242403] vgaarb: device added:\nPCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none\n[    0.244035] vgaarb: loaded\n[    0.244904] vgaarb: bridge control possible 0000:00:02.0\n[    0.246366] i2c-core: driver [aat2870] using legacy suspend method\n[    0.248033] i2c-core: driver [aat2870] using legacy resume method\n[    0.249642] SCSI subsystem initialized\n[    0.250778] usbcore: registered new interface driver usbfs\n[    0.252049] usbcore: registered new interface driver hub\n[    0.253461] usbcore: registered new device driver usb\n[    0.254867] PCI: Using ACPI for IRQ routing\n[    0.256341] NetLabel: Initializing\n[    0.257351] NetLabel:  domain hash size = 128\n[    0.258529] NetLabel:  protocols = UNLABELED CIPSOv4\n[    0.260045] NetLabel:  unlabeled traffic allowed by default\n[    0.261552] HPET: 3 timers in total, 0 timers will be used for per-cpu\ntimer\n[    0.263294] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0\n[    0.264872] hpet0: 3 comparators, 64-bit 100.000000 MHz counter\n[    0.276081] Switching to clocksource kvm-clock\n[    0.282780] AppArmor: AppArmor Filesystem Enabled\n[    0.284080] pnp: PnP ACPI init\n[    0.285013] ACPI: bus type pnp registered\n[    0.287002] pnp: PnP ACPI: found 8 devices\n[    0.288161] ACPI: ACPI bus type pnp unregistered\n[    0.297034] NET: Registered protocol family 2\n[    0.298261] IP route cache hash table entries: 4096 (order: 3, 32768\nbytes)\n[    0.300133] TCP established hash table entries: 16384 (order: 6, 262144\nbytes)\n[    0.302120] TCP bind hash table entries: 16384 (order: 6, 262144 bytes)\n[    0.303758] TCP: Hash tables configured (established 16384 bind 16384)\n[    0.305385] TCP reno registered\n[    0.306312] UDP hash table entries: 256 (order: 1, 8192 bytes)\n[    0.307744] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)\n[    0.309362] NET: Registered protocol family 1\n[    0.310533] pci 0000:00:00.0: Limiting direct PCI/PCI transfers\n[    0.311998] pci 0000:00:01.0: PIIX3: Enabling Passive Release\n[    0.313493] pci 0000:00:01.0: Activating ISA DMA hang workarounds\n[    0.315144] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11\n[    0.316650] pci 0000:00:01.2: PCI INT D -> Link[LNKD] -> GSI 11 (level,\nhigh) -> IRQ 11\n[    0.319274] pci 0000:00:01.2: PCI INT D disabled\n[    0.320875] Trying to unpack rootfs image as initramfs...\n[    0.324251] audit: initializing netlink socket (disabled)\n[    0.325646] type=2000 audit(1382666510.320:1): initialized\n[    0.388344] HugeTLB registered 2 MB page size, pre-allocated 0 pages\n[    0.397689] VFS: Disk quotas dquot_6.5.2\n[    0.398852] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)\n[    0.400936] fuse init (API version 7.17)\n[    0.402108] msgmni has been set to 969\n[    0.420367] Block layer SCSI generic (bsg) driver version 0.4 loaded\n(major 253)\n[    0.428481] io scheduler noop registered\n[    0.429707] io scheduler deadline registered (default)\n[    0.431208] io scheduler cfq registered\n[    0.432574] pci_hotplug: PCI Hot Plug PCI Core version: 0.5\n[    0.434173] pciehp: PCI Express Hot Plug Controller Driver version: 0.4\n[    0.436147] input: Power Button as\n/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0\n[    0.438347] ACPI: Power Button [PWRF]\n[    0.444983] ERST: Table is not found!\n[    0.446142] GHES: HEST is not enabled!\n[    0.452342] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10\n[    0.453984] virtio-pci 0000:00:03.0: PCI INT A -> Link[LNKC] -> GSI 10\n(level, high) -> IRQ 10\n[    0.457444] virtio-pci 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 11\n(level, high) -> IRQ 11\n[    0.468267] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10\n[    0.469904] virtio-pci 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10\n(level, high) -> IRQ 10\n[    0.476718] Freeing initrd memory: 3424k freed\n[    0.478965] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled\n[    0.503265] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A\n[    0.527584] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A\n[    0.552996] 00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A\n[    0.577254] 00:06: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A\n[    0.579146] Linux agpgart interface v0.103\n[    0.582398] brd: module loaded\n[    0.584203] loop: module loaded\n[    0.611380]  vda: vda1\n[    0.615719] scsi0 : ata_piix\n[    0.616858] scsi1 : ata_piix\n[    0.617907] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc0a0 irq 14\n[    0.619750] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc0a8 irq 15\n[    0.621986] Fixed MDIO Bus: probed\n[    0.623111] tun: Universal TUN/TAP device driver, 1.6\n[    0.624616] tun: (C) 1999-2004 Max Krasnyansky <maxk at qualcomm.com>\n[    0.652568] PPP generic driver version 2.4.2\n[    0.653997] ehci_hcd: USB 2.0 \'Enhanced\' Host Controller (EHCI) Driver\n[    0.655788] ohci_hcd: USB 1.1 \'Open\' Host Controller (OHCI) Driver\n[    0.657553] uhci_hcd: USB Universal Host Controller Interface driver\n[    0.659329] uhci_hcd 0000:00:01.2: PCI INT D -> Link[LNKD] -> GSI 11\n(level, high) -> IRQ 11\n[    0.663454] uhci_hcd 0000:00:01.2: UHCI Host Controller\n[    0.665060] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus\nnumber 1\n[    0.667415] uhci_hcd 0000:00:01.2: irq 11, io base 0x0000c080\n[    0.669280] hub 1-0:1.0: USB hub found\n[    0.670479] hub 1-0:1.0: 2 ports detected\n[    0.672063] usbcore: registered new interface driver libusual\n[    0.674003] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at\n0x60,0x64 irq 1,12\n[    0.677425] serio: i8042 KBD port at 0x60,0x64 irq 1\n[    0.679082] serio: i8042 AUX port at 0x60,0x64 irq 12\n[    0.680856] mousedev: PS/2 mouse device common for all mice\n[    0.683009] input: AT Translated Set 2 keyboard as\n/devices/platform/i8042/serio0/input/input1\n[    0.685864] rtc_cmos 00:01: RTC can wake from S4\n[    0.687825] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0\n[    0.689877] rtc0: alarms up to one day, 114 bytes nvram, hpet irqs\n[    0.691849] device-mapper: uevent: version 1.0.3\n[    0.693459] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised:\ndm-devel at redhat.com\n[    0.696127] cpuidle: using governor ladder\n[    0.697530] cpuidle: using governor menu\n[    0.698827] EFI Variables Facility v0.08 2004-May-17\n[    0.700653] TCP cubic registered\n[    0.701911] NET: Registered protocol family 10\n[    0.704050] NET: Registered protocol family 17\n[    0.705481] Registering the dns_resolver key type\n[    0.707209] registered taskstats version 1\n[    0.711976]   Magic number: 1:75:6\n[    0.713308] rtc_cmos 00:01: setting system clock to 2013-10-25 02:01:51\nUTC (1382666511)\n[    0.715726] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found\n[    0.717490] EDD information not available.\n[    0.782439] Freeing unused kernel memory: 924k freed\n[    0.784270] Write protecting the kernel read-only data: 12288k\n[    0.792420] Freeing unused kernel memory: 1632k freed\n[    0.799098] Freeing unused kernel memory: 1200k freed\n\ninfo: initramfs: up at 0.80\nGROWROOT: CHANGED: partition=1 start=16065 old: size=64260 end=80325 new:\nsize=2072385,end=2088450\ninfo: initramfs loading root from /dev/vda1\ninfo: /etc/init.d/rc.sysinit: up at 1.13\nStarting logging: OK\nInitializing random number generator... done.\nStarting acpid: OK\ncirros-ds \'local\' up at 1.26\nno results found for mode=local. up 1.33. searched: nocloud configdrive ec2\nStarting network...\nudhcpc (v1.20.1) started\nSending discover...\nSending select for 192.168.11.191...\nLease of 192.168.11.191 obtained, lease time 120\ndeleting routers\nroute: SIOCDELRT: No such process\nadding dns 192.168.11.254\ncirros-ds \'net\' up at 1.38\nchecking http://169.254.169.254/2009-04-04/instance-id\nfailed 1/20: up 1.39. request failed\nfailed 2/20: up 3.48. request failed\nfailed 3/20: up 5.49. request failed\nfailed 4/20: up 7.50. request failed\nfailed 5/20: up 9.52. request failed\nfailed 6/20: ','<mailman.13.1382702402.569.openstack@lists.openstack.org>',NULL),('<008701cfd15d$f6effb40$e4cff1c0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-16 10:26:09',25200,'2014-09-16 03:26:09',NULL,'[Openstack] Scheduler try and error with compute nodes in different\n	subnets/physnet\'s','Hello,\n\n \n\nWe have a OpenStack setup with a large number of compute nodes spread in\ndifferent subnets which are represented as different physnet\'s in OpenStack.\n\nWhen we start an instance we see that the scheduler choose a compute node\nand tries to spawn the instance, then it sees its not in the right physnet\nand choose a different compute node.\n\nIn our case this takes around 4 - 10 attempts. All this attempts counts for\nthe \"scheduler_max_attempts\" which default value is 3. We increase this\nvalue to prevent errors, but it\'s still very inefficient especially in a\nlarge environment.\n\n \n\nIs there a way that the scheduler knows the physnet/subnet position of the\ncompute nodes before the instance tries to spawn?\n\n \n\nThanks in advance!\n\n \n\nGreetings \n\nChris\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140916/69bb9937/attachment.html>\n\n',NULL,NULL),('<008877AC4F55084183884AB779006A8502AC70D73D@exch-mbx-122.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 00:35:30',-25200,'2013-08-27 07:35:30',NULL,'[openstack-dev] [Nova] Requesting feedback on review 35759','\n> -----Original Message-----\n> From: Wang, Shane [mailto:shane.wang at intel.com]\n> Sent: Tuesday, August 27, 2013 6:31 AM\n> To: OpenStack Development Mailing List\n> Subject: [openstack-dev] [Nova] Requesting feedback on review 35759\n> \n> Hi,\n> \n> We submitted the patches for bp\n> https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling\n> 1+ month ago.\n> The first patch is to add a column to save metrics collected by plugins -\n> https://review.openstack.org/#/c/35759/.\n> Is there anyone who is interested in that, would it be possible to get some\n> reviews for that?\n\n [Gary Kotton]  I have taken a look. I too have patches in from over a month ago and understand the frustration... \n\n> \n> Thanks.\n> --\n> Shane\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<3AB6CE7F274E534CAFD089D127A8A1FC256E71B6@SHSMSX103.ccr.corp.intel.com>',NULL),('<008877AC4F55084183884AB779006A8502AC70D76A@exch-mbx-122.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 01:35:29',-25200,'2013-08-27 08:35:29',NULL,'[openstack-dev] [Nova] Requesting feedback on review 35759','\n\n> -----Original Message-----\n> From: Wang, Shane [mailto:shane.wang at intel.com]\n> Sent: Tuesday, August 27, 2013 10:51 AM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Nova] Requesting feedback on review 35759\n> \n> Thank you, Gary, a little bit frustration but still have passion:)\n\n [Gary Kotton] Cool. Nice to hear. \n\n> \n> --\n> Shane\n> \n> > -----Original Message-----\n> > From: Gary Kotton [mailto:gkotton at vmware.com]\n> > Sent: Tuesday, August 27, 2013 3:36 PM\n> > To: OpenStack Development Mailing List\n> > Subject: Re: [openstack-dev] [Nova] Requesting feedback on review\n> > 35759\n> >\n> >\n> > > -----Original Message-----\n> > > From: Wang, Shane [mailto:shane.wang at intel.com]\n> > > Sent: Tuesday, August 27, 2013 6:31 AM\n> > > To: OpenStack Development Mailing List\n> > > Subject: [openstack-dev] [Nova] Requesting feedback on review 35759\n> > >\n> > > Hi,\n> > >\n> > > We submitted the patches for bp\n> > > https://blueprints.launchpad.net/nova/+spec/utilization-aware-schedu\n> > > ling\n> > > 1+ month ago.\n> > > The first patch is to add a column to save metrics collected by\n> > > plugins - https://review.openstack.org/#/c/35759/.\n> > > Is there anyone who is interested in that, would it be possible to\n> > > get some reviews for that?\n> >\n> >  [Gary Kotton]  I have taken a look. I too have patches in from over a\n> > month ago and understand the frustration...\n> >\n> > >\n> > > Thanks.\n> > > --\n> > > Shane\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<3AB6CE7F274E534CAFD089D127A8A1FC256E7438@SHSMSX103.ccr.corp.intel.com>',NULL),('<008877AC4F55084183884AB779006A8502AC70DA48@exch-mbx-122.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-28 02:18:38',-25200,'2013-08-28 09:18:38',NULL,'[openstack-dev] [Nova] Scheduler support for PCI passthrough','Hi,\nWhilst reviewing the code I think that I have stumbled on an issue (I hope that I am mistaken). The change set (https://review.openstack.org/#/c/35749/) expects pci stats to be returned from the host. There are a number of issues here that I have concern with an would like to know what the process is for addressing the fact that the compute node may not provide these statistics, for example, this could be due to the fact that the driver has not been updated to return the pci stats or this could be if the scheduler has been upgraded prior to the compute node (what is the process for the upgrade).\nThanks\nGary\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130828/596c4fa5/attachment.html>\n\n',NULL,NULL),('<008877AC4F55084183884AB779006A8502AC70DB7C@exch-mbx-122.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-28 07:31:19',-25200,'2013-08-28 14:31:19',NULL,'[openstack-dev] [Nova] Frustrations with review wait times','Hi,\nI am not sure that there is a good solution. I guess that we all need to \'vasbyt\' (that is Afrikaans for bite the bullet) and wait for the code posted to be reviewed. In Neutron when we were heading towards the end of a cycle and there were a ton of BP\'s being added the PTL would ensure that there were at least two reviewer on each BP. This would address the problem in two ways:\n1. Accountability for the review process in the critical time period\n2. The coder was able to have a person that he/she could be in touch with. \nThe above would enhance the cadence of the reviews.\nI personally am spending a few hours a day reviewing code. I hope that it is helping move things forwards. A review not only means just looking at the code (there are some cases that it is simple), but it means running and testing the code. In some cases it is not possible to test (for example a Mellanox vif driver). \nIn cases when a reviewer does not have an option to test the code would a tempest run help the reviewer with his/her decision?\nThanks and Alut a continua\nGary\n\n\n\n> -----Original Message-----\n> From: Sandy Walsh [mailto:sandy.walsh at rackspace.com]\n> Sent: Wednesday, August 28, 2013 5:15 PM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times\n> \n> \n> \n> On 08/28/2013 10:58 AM, Thierry Carrez wrote:\n> > Robert Collins wrote:\n> >> So I\'d like to throw two ideas into the mix.\n> >>\n> >> Firstly, consider having a rota - ideally 24x5 but that will need\n> >> some more geographical coverage I suspect for many projects - of folk\n> >> who spend a dedicated time period only reviewing.\n> >\n> > We have been doing that in the past for Nova, with little success. The\n> > reason why \"reviewday\" is called \"reviewday\" is because... well...\n> > there were review days.\n> >\n> > The wiki page was a bit eaten by the wiki conversion, but you can\n> > still read it at:\n> >\n> > https://wiki.openstack.org/wiki/Nova/ReviewDays\n> >\n> > In the end, a strict rotation didn\'t work out because people just\n> > didn\'t review on their review day, but rather when they have one hour\n> > free waiting for a patch to pass gate or whatever. In the end, the\n> > rotation gave us way worse results than random ad-hoc reviewing,\n> > because people would stop reviewing on days other than their review\n> > day, and would regularly skip their review day altogether.\n> >\n> > Furthermore, there is some specialization going on: I prefer the two\n> > Xen experts in nova-core to review one hour every two days rather than\n> > one day every two weeks... because then Xen patches get better review\n> > roundtrip times.\n> >\n> > So I\'m not convinced *at all* that a reboot of this would yield better\n> > results.\n> \n> +1\n> \n> That said, I think the reason my reviews dropped off from Nova was not\n> having a dedicated day for it. But that was my fault, not the fault of the\n> process. With Ceilometer, I try to set aside one fixed day a week for reviews\n> (with moderate success ;)\n> \n> \n> >> Launchpad [the\n> >> project, not the site] did this with considerable success : every\n> >> qualified reviewer committed to a time slot and didn\'t *try* to code\n> >> - they focused on reviews.\n> >\n> > The key difference is that \"every qualified reviewer\" was employed by\n> > the same company, and the review day was enforced by their\n> management.\n> > The amount of patches is also significantly lower, and there is less\n> > specialization effect.\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<521E05FC.7080402@rackspace.com>',NULL),('<008B1276B9D1764F8E841933BD42AFD912DF570C39@BLRX7MCDC204.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-17 18:32:30',-25200,'2012-09-18 01:32:30',NULL,'[openstack-dev] [metering] ceilometer-api integration in\n devstack','Hi,\n   I updated the patch with a minor edit.\n\nhttps://review.openstack.org/13136/\n\nPlease review.\n\nthanks\nSurya\n________________________________________\nFrom: Prabhakar, Surya\nSent: Monday, September 17, 2012 8:33 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [metering]  ceilometer-api integration in devstack\n\nHi,\n     Ceilometer-api integration into devstack.\n\nhttps://review.openstack.org/13123\n\nSurya.\n\n\n','<50573BBF.6040104@dell.com>',NULL),('<008B1276B9D1764F8E841933BD42AFD912DF570C3A@BLRX7MCDC204.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-18 07:57:26',19800,'2012-09-18 02:27:26',NULL,'[openstack-dev] [metering] ceilometer-api integration\n	in	devstack','HI Justin,\n    It is a minor edit which adds a file to in the directory files/pips/ceilometer-api with content as Flask.\n\nI am able to see the patch fine. \n\nCan you update me if this is still a problem?\n\nthanks\nSurya.\n________________________________________\nFrom: Justin Simms [justin.simms at gmail.com]\nSent: Tuesday, September 18, 2012 7:37 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [metering] ceilometer-api integration in   devstack\n\nIt looks like that patch set does not exist anymore. Would you please submit it again?\n\nOn Mon, Sep 17, 2012 at 9:32 PM, <Surya_Prabhakar at dell.com<mailto:Surya_Prabhakar at dell.com>> wrote:\nHi,\n   I updated the patch with a minor edit.\n\nhttps://review.openstack.org/13136/\n\nPlease review.\n\nthanks\nSurya\n________________________________________\nFrom: Prabhakar, Surya\nSent: Monday, September 17, 2012 8:33 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [metering]  ceilometer-api integration in devstack\n\nHi,\n     Ceilometer-api integration into devstack.\n\nhttps://review.openstack.org/13123\n\nSurya.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAH8Rk3w_V8FvqmBL4ugT=88x4FcVBvcazsko8ZyyTLpLZq765Q@mail.gmail.com>',NULL),('<009101cfd174$75cd3cf0$6167b6d0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-16 13:07:10',25200,'2014-09-16 06:07:10',NULL,'[Openstack] Scheduler try and error with compute nodes in\n	different subnets/physnet\'s','Hello Jay,\nAs far as I understand each compute node sends the current available\nresources to the management node.\nThis could also include the physnet, so the scheduler ignore the not\nmatching compute nodes. Or the compute nodes sends the physnet at the first\nregistration in the management node.\nBut to be honest I not have the deep insights to make a proper suggestion\nhere.\n\n-----Original Message-----\nFrom: Jay Pipes [mailto:jaypipes at gmail.com] \nSent: Tuesday, September 16, 2014 11:54\nTo: openstack at lists.openstack.org\nSubject: Re: [Openstack] Scheduler try and error with compute nodes in\ndifferent subnets/physnet\'s\n\nOn 09/15/2014 11:26 PM, Chris wrote:\n> Hello,\n>\n> We have a OpenStack setup with a large number of compute nodes spread \n> in different subnets which are represented as different physnet\'s in\nOpenStack.\n>\n> When we start an instance we see that the scheduler choose a compute \n> node and tries to spawn the instance, then it sees its not in the \n> right physnet and choose a different compute node.\n\nHow would the scheduler know which compute node is \"in the right physnet\"?\nIn other words, when an instance is launched, how does the scheduler know\nwhat is the \"correct physnet\" for that type of instance?\n\n> In our case this takes around 4 - 10 attempts. All this attempts \n> counts for the \"scheduler_max_attempts\" which default value is 3. We \n> increase this value to prevent errors, but it\'s still very inefficient \n> especially in a large environment.\n>\n> Is there a way that the scheduler knows the physnet/subnet position of \n> the compute nodes before the instance tries to spawn?\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<5417C269.50808@gmail.com>',NULL),('<0094FD3B-E69D-4961-984D-D5E9BC24A650@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-12 14:17:27',-28800,'2014-02-12 22:17:27',NULL,'[openstack-dev] [qa][neutron] API tests in the Neutron tree','\nOn Feb 12, 2014, at 1:59 PM, Sean Dague <sean at dague.net> wrote:\n\n> On 02/12/2014 04:25 PM, Maru Newby wrote:\n>> \n>> On Feb 12, 2014, at 12:36 PM, Sean Dague <sean at dague.net> wrote:\n>> \n>>> On 02/12/2014 01:48 PM, Maru Newby wrote:\n>>>> At the last 2 summits, I\'ve suggested that API tests could be maintained in the Neutron tree and reused by Tempest.  I\'ve finally submitted some patches that demonstrate this concept:\n>>>> \n>>>> https://review.openstack.org/#/c/72585/  (implements a unit test for the lifecycle of the network resource)\n>>>> https://review.openstack.org/#/c/72588/  (runs the test with tempest rest clients)\n>>>> \n>>>> My hope is to make API test maintenance a responsibility of the Neutron team.  The API compatibility of each Neutron plugin has to be validated by Neutron tests anyway, and if the tests are structured as I am proposing, Tempest can reuse those efforts rather than duplicating them.\n>>>> \n>>>> I\'ve added this topic to this week\'s agenda, and I would really appreciate it interested parties would take a look at the patches in question to prepare themselves to participate in the discussion.\n>>>> \n>>>> \n>>>> m.\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>>> Realistically, having API tests duplicated in the Tempest tree is a\n>>> feature, not a bug.\n>>> \n>>> tempest/api is there for double book keep accounting, and it has been\n>>> really effective at preventing accidental breakage of our APIs (which\n>>> used to happen all the time), so I don\'t think putting API testing in\n>>> neutron obviates that.\n>> \n>> Given how limited our testing resources are, might it be worth considering whether \'double-entry accounting\' is actually the best way to preventing accidental breakage going forward?  Might reasonable alternatives exist, such as clearly separating api tests from other tests in the neutron tree and giving review oversight only to qualified individuals?\n> \n> Our direct experience is that if we don\'t do this, within 2 weeks some\n> project will have landed API breaking changes. This approach actually\n> takes a lot of review load off the core reviewers, so reverting to a\n> model which puts more work back on the review team (given the current\n> review load), isn\'t something I think we want.\n\nJust so I\'m clear, is there anything I could say that would change your mind?\n\n\nm.\n\n\n> \n> I get that there is a cost with this. But there is a cost of all of\n> this. And because API tests should be write once for the API (and\n> specifically not evolving), the upfront cost vs. the continually paid\n> cost of review time in tree has been the better trade off.\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> Samsung Research America\n> sean at dague.net / sean.dague at samsung.com\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52FBEEB3.3060802@dague.net>',NULL),('<009701ceaeee$daecbb00$90c63100$@manceps.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-11 06:00:12',-25200,'2013-09-11 13:00:12',NULL,'[openstack-community] OpenStack core online hands-on 1-day training\n	from DetaCloud - Only a handful early-bird seats remaining','Learn OpenStack Core in one day by performing end-to-end install &\nconfiguration of your own private cloud, online.\n\n \n\nOpenStack Core Hands-on Install  <http://bit.ly/1e1VLO0> & Configure 1-day\nIntensive Online Training\n\n \n\nOn the leading-edge of experiential training, DetaCloud TeleportT is a 1-day\ninteractive online training at an incredible value. This instructor-led\ninteractive training is delivered via the Web and accessible from most\nconnected devices. Attendees utilize DetaCloud\'s online lab to perform a\nstep-by-step multi-node OpenStack Cloud deployment from scratch, no scripted\ninstallation or automation tools are used http://bit.ly/1e1VLO0 \n\n \n\nOnly a handful early-bird seats remaining for next training scheduled Oct 8.\n\n \n\nteleport at detacloud.com for more information.\n\nwww.detacloud.com\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130911/3793b048/attachment.html>\n\n',NULL,NULL),('<009801cfc086$f9473da0$ebd5b8e0$@vdc.com.vn>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-26 00:06:55',25200,'2014-08-25 17:06:55',NULL,'[Openstack-operators] Iperf isn\'t work between VMs which are\n	placed	in other host','Dear Taeheum Na,\n\n \n\nThere are couple of ways using Iperf (GUI with java app ? Jperf in windows\nand CLI as you did).\n\nMoreover, you should check the listening port.\n\nMake sure of that you can try:\n\n          Listener VM:   iperf ?s ?u\n\n          Sender VM:    iperf ?c ?u IP_of_listner_VM\n\nSo iperf will use the defaul port 5001.\n\n \n\nHope it can help you out.\n\nCuongtm,\n\n \n\n\n----------------------------------------------------------------------------\n------------------------------------------------\n\n\n\n\nCuong, Tong Manh\n\n\n\n\nSolution, Reasearch and Development Division\n\nVDC INFORMATION TECHNOLOGY CENTER\n\nVIETNAM DATACOMMUNICATION COMPANY / VNPT Group\n\nInternet Building, Block 2A, Thang Long International Village, Cau Giay\nDist, Ha Noi\n\n\n\n\nMobile: +84 9 123 189 68\n\n\n\n\ncuongtm at vdc.com.vn\n\n \n\n \n\nFrom: Taeheum Na [mailto:thna at nm.gist.ac.kr] \nSent: 25 Tha?ng Ta?m 2014 11:24 CH\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Iperf isn\'t work between VMs which are placed\nin other host\n\n \n\nHello, I tried to measure network performance BTW VM which connected through\nGRE tunnel. So, I configured neutron(ML2/GRE). \n\nThen I verified TCP performance between VMs which are placed on same host. \n\nBut I could not make Iperf connection BTW VMs (on other host), but ping is\nok.\n\nbellow things are current Security group configuration. I think that I allow\nall traffic which is needed to execute iperf.\n\n+-------------+-----------+---------+-----------+--------------+\n\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n\n+-------------+-----------+---------+-----------+--------------+\n\n| udp         | 1         | 65535   | 0.0.0.0/0 |              |\n\n| tcp         | 1         | 65535   | 0.0.0.0/0 |              |\n\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n\n+-------------+-----------+---------+-----------+--------------+\n\nDo you have any comment?\n\n \n\nRegards\n\nTaeheum Na\n\n****************************************************\n\nM.S. candidate of Networked Computing Systems Lab.\n\nSchool of Information and Communications\n\nGIST (Gwangju Inst. of Sci. and Tech.)\n\nE-mail:  <mailto:thna at nm.gist.ac.kr> thna at nm.gist.ac.kr\n\nPhone: +82-10-2238-9424\n\nOffice: +82-62-715-2273\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/d5e8d81e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 2073 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/d5e8d81e/attachment.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.jpg\nType: image/jpeg\nSize: 1172 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/d5e8d81e/attachment.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.png\nType: image/png\nSize: 2467 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/d5e8d81e/attachment-0001.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.png\nType: image/png\nSize: 2070 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/d5e8d81e/attachment-0002.png>\n\n','<0145D5DF1C56174FABB6EB834BC4909C03FEBD1915C9@NML2007.netmedia.kjist.ac.kr>',NULL),('<00a2761d88537bf0bef258fb96c799c1@qmail.com.bd>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-27 17:05:14',21600,'2014-10-27 11:05:14',NULL,'[Openstack] Glance Image Upload error',' \n\nHi all, \n\nI am facing image upload problem on controller node .\nPlease see in below . \n\nglance image-create --name \"cirros-0.3.3-x86_64\"\n--file cirros-0.3.3-x86_64-disk.img \n> --disk-format qcow2\n--container-format bare --is-public True --progress\n[===> ] 12%\n\nthis\nimage not upload after 12% . \n\nPlease help me for solution this problem.\n\n\nThanks \n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141027/4f4ff819/attachment.html>\n\n',NULL,NULL),('<00A387CF-6519-4787-B9AD-3C8EBDEC751E@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 11:52:07',-14400,'2014-09-12 15:52:07',NULL,'[openstack-dev] [all] PYTHONDONTWRITEBYTECODE=true in tox.ini','\nOn Sep 12, 2014, at 11:21 AM, Mike Bayer <mbayer at redhat.com> wrote:\n\n> \n> On Sep 12, 2014, at 7:39 AM, Sean Dague <sean at dague.net> wrote:\n> \n>> I assume you, gentle OpenStack developers, often find yourself in a hair\n>> tearing out moment of frustration about why local unit tests are doing\n>> completely insane things. The code that it is stack tracing on is no\n>> where to be found, and yet it fails.\n>> \n>> And then you realize.... that part of oslo doesn\'t exist any more....\n>> except there are still pyc files laying around. Gah!\n>> \n>> I\'ve proposed the following to Nova and Python novaclient -\n>> https://review.openstack.org/#/c/121044/\n>> \n>> Which sets PYTHONDONTWRITEBYTECODE=true in the unit tests.\n> \n> my VPN was down and I didn?t get this thread just now, but I am strongly -1 on this as added to tox.ini, my response is http://lists.openstack.org/pipermail/openstack-dev/2014-September/045873.html.\n> \n> Short answer: if you want this feature, put PYTHONDONTWRITEBYTECODE into *your* environment.  Don?t force it on our automated tests or on my environment.   .pyc files make a difference in behavior, and if we banish them from all testing, then our code is never tested within the environment that it will normally be run in after shipment.\n> \n> I?d far prefer a simple script added to tox.ini which deletes orphaned .pyc files only, if a change to tox.ini must be made.\n\nI have to agree with Mike here. Cleaning up our dev environments using a little automation is better than disabling a feature of the interpreter that may have unforeseen consequences in behavior or performance. The more we introduce unusual settings like this into our environments and tools, the more edge cases and weirdness we?re going to find in those tools that keep us from doing the work we really want to be doing.\n\nWe could use a git hook (see my earlier message in this thread) or we could add a command to tox to remove them before starting the tests. Neither of those solutions would affect the runtime behavior in a way that makes our dev environments fundamentally different from a devstack or production deployment.\n\nDoug\n\n\n\n','<DF28B8FB-A8F2-456D-A859-08214723557F@redhat.com>',NULL),('<00A4FC5C-3BA3-4B4E-BAA9-D83FDD72C3A3@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 23:47:46',3600,'2013-07-23 22:47:46',NULL,'[openstack-dev] [keystone] Extending policy checking to include\n	target entities','...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)....so how do we know wether to lie or not?\n\nHenry\nOn 23 Jul 2013, at 21:23, David Chadwick wrote:\n\n> \n> \n> On 23/07/2013 19:02, Henry Nash wrote:\n>> One thing we could do is:\n>> \n>> - Return Forbidden or NotFound if we can determine the correct answer\n>> - When we can\'t (i.e. the object doesn\'t exist), then return NotFound\n>> unless a new config value \'policy_harden\' (?) is set to true (default\n>> false) in which case we translate NotFound into Forbidden.\n> \n> I am not sure that this achieves your objective of no data leakage through error codes, does it?\n> \n> Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not\n> \n> regards\n> \n> David\n>> \n>> Henry\n>> On 23 Jul 2013, at 18:31, Adam Young wrote:\n>> \n>>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n>>>> When writing a previous ISO standard the approach we took was as follows\n>>>> \n>>>> Lie to people who are not authorised.\n>>> \n>>> Is that your verbage?  I am going to reuse that quote, and I would\n>>> like to get the attribution correct.\n>>> \n>>>> \n>>>> So applying this approach to your situation, you could reply Not\n>>>> Found to people who are authorised to see the object if it had\n>>>> existed but does not, and Not Found to those not authorised to see\n>>>> it, regardless of whether it exists or not. In this case, only those\n>>>> who are authorised to see the object will get it if it exists. Those\n>>>> not authorised cannot tell the difference between objects that dont\n>>>> exist and those that do exist\n>>> \n>>> So, to try and apply this to a semi-real example:  There are two types\n>>> of URLs.  Ones that are like this:\n>>> \n>>> users/55FEEDBABECAFE\n>>> \n>>> and ones like this:\n>>> \n>>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n>>> \n>>> \n>>> In the first case, you are selecting against a global collection, and\n>>> in the second, against a scoped collection.\n>>> \n>>> For unscoped, you have to treat all users as equal, and thus a 404\n>>> probably makes sense.\n>>> \n>>> For a scoped collection we could return a 404 or a 403 Forbidden\n>>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users\n>>> credentials:  all resources under domain/66DEADBEEF0000  would show up\n>>> as 403s regardless of existantce or not if the user had no roles in\n>>> the domain 66DEADBEEF0000.  A user that would be allowed access to\n>>> resources in 66DEADBEEF0000  would get a 403 only for an object that\n>>> existed but that they had no permission to read, and 404 for a\n>>> resource that doesn\'t exist.\n>>> \n>>> \n>>> \n>>> \n>>>> \n>>>> regards\n>>>> \n>>>> David\n>>>> \n>>>> \n>>>> On 23/07/2013 16:40, Henry Nash wrote:\n>>>>> Hi\n>>>>> \n>>>>> As part of bp\n>>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n>>>>> I have uploaded some example WIP code showing a proposed approach\n>>>>> for just a few API calls (one easy, one more complex). I\'d\n>>>>> appreciate early feedback on this before I take it any further.\n>>>>> \n>>>>> https://review.openstack.org/#/c/38308/\n>>>>> \n>>>>> A couple of points:\n>>>>> \n>>>>> - One question is on how to handle errors when you are going to get\n>>>>> a target object before doing you policy check.  What do you do if\n>>>>> the object does not exist?  If you return NotFound, then someone,\n>>>>> who was not authorized  could troll for the existence of entities by\n>>>>> seeing whether they got NotFound or Forbidden. If however, you\n>>>>> return Forbidden, then users who are authorized to, say, manage\n>>>>> users in a domain would aways get Forbidden for objects that didn\'t\n>>>>> exist (since we can know where the non-existant object was!).  So\n>>>>> this would modify the expected return codes.\n>>>>> \n>>>>> - I really think we need some good documentation on how to bud\n>>>>> keystone policy files.  I\'m happy to take a first cut as such a\n>>>>> thing - what do you think the right place is for such documentation\n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n\n\n\n','<51EEE62A.5050802@kent.ac.uk>',NULL),('<00a701ce5ab2$3b6b7660$b2426320$@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-27 10:14:35',7200,'2013-05-27 08:14:35',NULL,'[openstack-dev] Lost in translation','Hello, \n\n \n\nI am currently working on the glossary translation into French :\nhttps://www.transifex.com/projects/p/openstack-manuals-i18n/glossary/l/fr/. \n\n \n\nHowever, I\'m confused as to where these words come from. For instance :\n\"computing\" does not show anywhere in\nhttps://wiki.openstack.org/wiki/Glossary. \n\n \n\nCould someone point me in the right direction ? \n\n \n\nThanks a lot for your help !\n\n \n\nBest,\n\n \n\nFran?ois Bureau\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130527/253be25b/attachment.html>\n\n',NULL,NULL),('<00ab89c0a9ab4b26913ff8cafda58879@BN1PR07MB022.namprd07.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-24 14:55:35',0,'2014-03-24 14:55:35',NULL,'[Openstack] Multi-tenancy in Trove ?','Arun,\n\nI\'d love to hear more from you about your requirements regarding multi-tenancy. We are working on something in this area and would like to see whether our solution(s) will help you.\n\nThanks,\n\n-amrith\n\nAmrith Kumar, Founder & CTO\n\n[tesora-small]\n\nMobile: 978-563-9590\n\nDirect: 978-707-8010 x1002\n\nTwitter: @amrithkumar<http://www.twitter.com/amrithkumar>\n\nSkype: amrith.skype\n\nCheck out our blog<http://www.tesora.com/blog>\n\n\n\nTwitter<https://twitter.com/tesoracorp> Facebook<https://www.facebook.com/tesoracorp> LinkedIn<http://www.linkedin.com/company/parelastic>\n\n125 CambridgePark Drive, Suite 400, <https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MA&hl=en&sll=42.036922,-71.683501&sspn=3.422779,6.696167&oq=125+ca&hnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140&t=m&z=17>\nCambridge, MA 02140<https://www.google.com/maps?q=125+Cambridge+Park+Drive,+Cambridge,+MA&hl=en&sll=42.036922,-71.683501&sspn=3.422779,6.696167&oq=125+ca&hnear=125+Cambridge+Park+Dr,+Cambridge,+Middlesex,+Massachusetts+02140&t=m&z=17>\n\n4 Robert Speck Parkway, Suite 1500,<https://www.google.com/maps?q=4+Robert+Speck+Parkway,+Suite+1500,+Mississauga,+ON,+Canada.+L4Z+1S1&hl=en&sll=42.395158,-71.145805&sspn=0.006648,0.013078&hnear=4+Robert+Speck+Pkwy+%231500,+Mississauga,+Peel+Regional+Municipality,+Ontario+L4Z+1S1,+Canada&t=m&z=17>\nMississauga, ON, Canada. L4Z 1S1<https://www.google.com/maps?q=4+Robert+Speck+Parkway,+Suite+1500,+Mississauga,+ON,+Canada.+L4Z+1S1&hl=en&sll=42.395158,-71.145805&sspn=0.006648,0.013078&hnear=4+Robert+Speck+Pkwy+%231500,+Mississauga,+Peel+Regional+Municipality,+Ontario+L4Z+1S1,+Canada&t=m&z=17>\n\n\n\n\nFrom: Arun prasath [mailto:er.arunprasath at outlook.com]\nSent: Monday, March 24, 2014 1:53 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Multi-tenancy in Trove ?\n\nHello all,\n\nWhether multi-tenancy feature in Trove will be available in future releases ? Or it is ignored for some specific reasons ?\n\nArun prasath S\nComputer Science Engineer | Visolve Inc\nPh: +91 9578178060\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140324/814718be/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 1464 bytes\nDesc: image001.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140324/814718be/attachment.jpg>\n\n','<BAY179-W404425DADE455E221BF791807A0@phx.gbl>',NULL),('<00ACA8AF-5CA6-42E9-9AAC-9316D2C07025@tail-f.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-24 09:19:50',7200,'2013-05-24 07:19:50',NULL,'[openstack-dev] [Quantum] Developing a Quantum plugin for\n	Tail-f NCS (Network Control System)','Hi all,\n\nI have created a blueprint for the Tail-f NCS integration with OpenStack networking: https://blueprints.launchpad.net/quantum/+spec/tailf-ncs\n\nI would love a little bit of review before I submit it for consideration for Havana. Particularly - Kyle, Bob, does it still look like MechanismDriver code materializing in h2 is the right approach to take?\n\nCheers,\n-Luke\n\n13 maj 2013 kl. 09:14 skrev Luke Gorrie:\n\n> I would like to develop a Quantum plugin for the Tail-f Network Control System (NCS - http://www.tail-f.com/network-control-system/). I want to do this in a tasteful way that helps to make Quantum better. I am an OpenStack newbie so I would appreciate some advice on the first steps :-)\n> \n> For background, NCS is a network provisioning system that knows how to control Cisco/Juniper/etc devices. The goal for this plugin is for Quantum to notify NCS of network/port/etc changes so that NCS can perform relevant provisioning of the physical switches and routers that connect the OpenStack nodes to the world and to each other.\n> \n> That is: NCS owns the switches and routers, LinuxBridge/OVS owns the hypervisor networking, and the plugin keeps them in sync.\n> \n> I have been reading the Quantum code and it looks like the BigSwitch plugin is close to what we need, i.e. a plugin that proxies all Quantum provisioning events over a REST interface to an external system. I have the impression though that this replaces the LinuxBridge/OVS plugin whereas we want to run that in parallel. (I also don\'t necessarily need the Quantum network state cached in the Python plugin.)\n> \n> Any tips on how to move this forward and thrash out a design that\'s good for Quantum? I have the impression there is a lot of related work going on at the moment...\n> \n> Cheers,\n> -Luke\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<F6AD442A-3A5C-4EA6-8989-3E53023EF3C1@tail-f.com>',NULL),('<00ae89fdf3574063b0f1c5387f272392@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-19 13:36:13',0,'2014-02-19 13:36:13',NULL,'[OpenStack-Infra] External Testing :: install-master.sh errors','Hi Jay-\n\nIts resolved,\nIt\'s a Capital letters issue with the node hostname.\n\n But then, I have found the following.\n\n\nerr: Could not prefetch package provider \'pip\': (provider=pip)\nerr: /Stage[main]/Recheckwatch/Package[gerritlib]: Could not evaluate: (provider=pip)\nerr: /Stage[main]/Os_ext_testing::Base/Package[virtualenv]: Could not evaluate: (provider=pip)\n\n\nDuplicate declaration: A2mod[rewrite] is already declared in file /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/master.pp at line 34; cannot redeclare at /root/config/modules/zuul/manifests/init.pp:236 on node freescale-openstack-ci.ap.freescale.net\n\nDuplicate declaration: A2mod[proxy] is already declared in file /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/master.pp at line 37; cannot redeclare at /root/config/modules/zuul/manifests/init.pp:239 on node freescale-openstack-ci.ap.freescale.net\n\nDuplicate declaration: A2mod[proxy_http] is already declared in file /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/master.pp at line 40; cannot redeclare at /root/config/modules/zuul/manifests/init.pp:242 on node freescale-openstack-ci.ap.freescale.net\n\nI have edited init.pp and commented the lines.\n\n\n\n\n\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\nFrom: trinath.somanchi at freescale.com [mailto:trinath.somanchi at freescale.com]\nSent: Wednesday, February 19, 2014 6:07 PM\nTo: Jay Pipes\nCc: openstack-infra at lists.openstack.org\nSubject: [OpenStack-Infra] External Testing :: install-master.sh errors\n\n\nHi Jay-\n\n\n\nWhile installing the master node  using install_master.sh,\n\n\n\nI get this error\n\n\n\nCould not parse configuration file: Certificate names must be lower case; see #1168\n\n\n\nwith the command,\n\n\n\nsudo puppet apply --verbose $PUPPET_MODULE_PATH -e \"class {\'os_ext_testing::master\': $CLASS_ARGS }\"\n\n\n\nWhen I print the command, the complete key and certificate file contents are given in the JSON format. I feel, that this error specifies that it needs only lower case string rather than upper case.\n\n\n\nAlso, do we need to provide the file names or the file contents in the JSON string to the \"puppet apply\" command.\n\n\n\nKindly guide me resolve the same.\n\n\n\nThanks in advance,\n\n\n\n--\n\nTrinath S\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140219/46aadbba/attachment.html>\n\n','<1443f74ec81f4f12b9750fefe83dc265@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<00B180B44D70DB429A492069FDE633373F9425E47E@AUSX7MCPC109.AMER.DELL.COM>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-15 19:52:06',-18000,'2013-04-16 00:52:06',NULL,'[openstack-community] Quantum installation guide for CentOS','Hi All,\n\nI\'m new to Openstack quantum...just wondering if Quantum is supported on CentOS? If so, is there documentation for installing Quantum server on CentOS?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130415/bd05debf/attachment.html>\n\n',NULL,NULL),('<00B180B44D70DB429A492069FDE633373F9425E486@AUSX7MCPC109.AMER.DELL.COM>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-15 20:15:11',-18000,'2013-04-16 01:15:11',NULL,'[openstack-community] Quantum installation guide for CentOS','Thanks Bruce very much for the info.. this instructions seem to cover Nova only, is there documentation covering the installation of Quantum on CentOS?\n\nThanks,\n\nYuLing\n\nFrom: Bruce Lok [mailto:brucelok at cyberport.hk]\nSent: Monday, April 15, 2013 6:00 PM\nTo: C, Yuling; community at lists.openstack.org\nSubject: RE: Quantum installation guide for CentOS\n\nInstall OpenStack in CentOS\nhttps://wiki.openstack.org/wiki/NovaInstall/CentOSNotes\n\nOpenStack Install and Deploy Manual - Red Hat/CentOS\nhttp://docs.openstack.org/folsom/openstack-compute/install/yum/content/\n\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nEngineer of Hong Kong Cyberport\n\n\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, 16 April, 2013 08:52\nTo: community at lists.openstack.org\nSubject: [openstack-community] Quantum installation guide for CentOS\n\nHi All,\n\nI\'m new to Openstack quantum...just wondering if Quantum is supported on CentOS? If so, is there documentation for installing Quantum server on CentOS?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130415/52ca3e27/attachment.html>\n\n','<0D8D9EBD1BBE224F8AEE23E5837A99C70995F6AC@FSI-EX7.cyberport.hk>',NULL),('<00B180B44D70DB429A492069FDE633373F9425E6B4@AUSX7MCPC109.AMER.DELL.COM>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-16 12:06:31',-18000,'2013-04-16 17:06:31',NULL,'[openstack-community] Quantum installation guide for CentOS','Hi All,\n\nDoes anyone know if Quantum is supported on CentOS and where I can get the installation guide for Quantum on CentOS?\n\nThanks,\n\nYuLing\n\nFrom: C, Yuling\nSent: Monday, April 15, 2013 6:15 PM\nTo: brucelok at cyberport.hk; community at lists.openstack.org\nSubject: Re: [openstack-community] Quantum installation guide for CentOS\n\nThanks Bruce very much for the info.. this instructions seem to cover Nova only, is there documentation covering the installation of Quantum on CentOS?\n\nThanks,\n\nYuLing\n\nFrom: Bruce Lok [mailto:brucelok at cyberport.hk]\nSent: Monday, April 15, 2013 6:00 PM\nTo: C, Yuling; community at lists.openstack.org\nSubject: RE: Quantum installation guide for CentOS\n\nInstall OpenStack in CentOS\nhttps://wiki.openstack.org/wiki/NovaInstall/CentOSNotes\n\nOpenStack Install and Deploy Manual - Red Hat/CentOS\nhttp://docs.openstack.org/folsom/openstack-compute/install/yum/content/\n\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nEngineer of Hong Kong Cyberport\n\n\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, 16 April, 2013 08:52\nTo: community at lists.openstack.org\nSubject: [openstack-community] Quantum installation guide for CentOS\n\nHi All,\n\nI\'m new to Openstack quantum...just wondering if Quantum is supported on CentOS? If so, is there documentation for installing Quantum server on CentOS?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130416/570ffddf/attachment.html>\n\n','<00B180B44D70DB429A492069FDE633373F9425E486@AUSX7MCPC109.AMER.DELL.COM>',NULL),('<00B1BE5B-983A-462D-A689-73C077457D50@aristanetworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-25 15:04:47',-28800,'2013-01-25 23:04:47',NULL,'[openstack-dev] Blueprint Announcement: OVSPlugin Support for\n	Hardware Devices','Hi Folks,\n\nWe (Arista Networks) have submitted a new blueprint today which adds Quantum/OVSPlugin support for hardware switches.\n\nThis blueprint describes a generic python API within the OVS quantum plugin which will enable support for different hardware backends for L2 network segregation (VLANs, tunneling, etc.)\n\nThis may be useful for existing data centers with hardware switches which needs to be used along with Openstack infrastructure. In this case a hardware vendor may introduce the OVS plugin extension/driver which will allow using the vendor\'s hardware within Openstack along with Open vSwitch virtual switches to provide L2 network segregation.\n\nThis will allow automatic L2 network provisioning on the hardware devices alongside with the Open vSwitch provisioning in the compute node hypervisors.\n\nWe have implemented and successfully tested the API proposed in this blueprint and are providing the source code for an Arista Driver which supports provisioning of Arista TOR (top-of-the-rack) switches alongside with open vswitches. This driver will support the python API proposed in this blueprint to interact with the OVS quantum plugin.\n\nThe blueprint is available at:\n\nhttps://blueprints.launchpad.net/quantum/+spec/ovsplugin-hardware-devices\n\nWe will be submitting the code for review at https://review.openstack.org soon, and would love to be considered for inclusion into the Quantum/Grizzly release. \n\nAppreciate your comments and feedback on the same.\n\nRegards,\n\nSatish Mohan\n\nArista Networks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130125/bf7f9b13/attachment.html>\n\n',NULL,NULL),('<00b601cf483c$3c3c82f0$b4b588d0$@jd.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-25 23:09:36',28800,'2014-03-25 15:09:36',NULL,'[Openstack] Error occured while making volume backed live migration\n	based on Ceph Block; Ask for assistance.','Hi all,\n\nI\'m trying the volume backed live migration via Ceph Block Storage and stunk\nin the issues of libvirt.\nThe environment of my cluster is as follows:\nHosts in cluster: \n   Havana(Controller & compute) and Compute1(pure Compute node)\n   Ceph1, ceph2, ceph3: ceph cluster\n\n1. The ceph cluster: checked by command: ceph health\n2. The Openstack cluster: \n  ceph client is installed on each node;\n  Configuration done for ceph in glance, cinder, nova\n  Qemu-kvm, qemu-img, qemu-kvm-tools are installed from ceph source.\n3. Image creation correctly; Volume creation correctly; Instance lunched\nfrom volume on host havana;\n4. Unexpected, the instance migration from Havana to compute1 failed with\nthe following ERROR(I\'m struggling to hard work on the issues and it would\nbe much appreciated if any clue!!!):\n\nCompute.log on host compute1:\n2014-03-25 18:46:44.346 16948 AUDIT nova.compute.manager\n[req-defe320c-bae6-4d57-817e-1cca779e204a 714bab91932043e98ad2d855a81f19b0\n888df5c4bc47459485b96ffa03c671e6] [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7] Detach volume\nf5a34a51-b662-43d4-a7d5-4199de8b1d4b from mountpoint vda\n2014-03-25 18:46:44.364 16948 WARNING nova.compute.manager\n[req-defe320c-bae6-4d57-817e-1cca779e204a 714bab91932043e98ad2d855a81f19b0\n888df5c4bc47459485b96ffa03c671e6] [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7] Detaching volume from unknown instance\n2014-03-25 18:46:44.375 16948 ERROR nova.compute.manager\n[req-defe320c-bae6-4d57-817e-1cca779e204a 714bab91932043e98ad2d855a81f19b0\n888df5c4bc47459485b96ffa03c671e6] [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7] Failed to detach volume\nf5a34a51-b662-43d4-a7d5-4199de8b1d4b from vda\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7] Traceback (most recent call last):\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]   File\n\"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 3737, in\n_detach_volume\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]     encryption=encryption)\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]   File\n\"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 1202,\nin detach_volume\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]     virt_dom =\nself._lookup_by_name(instance_name)\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]   File\n\"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 3101,\nin _lookup_by_name\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]     raise\nexception.InstanceNotFound(instance_id=instance_name)\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7] InstanceNotFound: Instance\ninstance-0000000c could not be found.\n2014-03-25 18:46:44.375 16948 TRACE nova.compute.manager [instance:\naa44d1f6-1f4f-434d-b05e-f785f7b0a2a7]\n\nLibvirtd.log on host compute1:\n2014-03-25 10:32:05.952+0000: 1891: warning : qemuDomainObjTaint:1377 :\nDomain id=1 name=\'instance-0000000b\'\nuuid=4ddb08dc-c7ef-4cdf-8108-80a296eaf457 is tainted: high-privileges\n2014-03-25 10:32:07.188+0000: 1891: warning :\nqemuDomainObjEnterMonitorInternal:1005 : This thread seems to be the async\njob owner; entering monitor without asking for a nested job is dangerous\n2014-03-25 10:33:34.411+0000: 1891: warning :\nqemuDomainObjEnterMonitorInternal:1005 : This thread seems to be the async\njob owner; entering monitor without asking for a nested job is dangerous\n2014-03-25 10:33:34.414+0000: 1891: warning :\nqemuDomainObjEnterMonitorInternal:1005 : This thread seems to be the async\njob owner; entering monitor without asking for a nested job is dangerous\n2014-03-25 10:33:34.416+0000: 1891: warning : qemuSetupCgroupForVcpu:566 :\nUnable to get vcpus\' pids.\n2014-03-25 10:33:34.419+0000: 1891: warning :\nqemuDomainObjEnterMonitorInternal:1005 : This thread seems to be the async\njob owner; entering monitor without asking for a nested job is dangerous\n2014-03-25 10:33:34.419+0000: 1891: warning :\nqemuDomainObjEnterMonitorInternal:1005 : This thread seems to be the async\njob owner; entering monitor without asking for a nested job is dangerous\n\n[root at compute1 ~(keystone_admin)]# rpm -qa |grep qemu\nqemu-img-0.12.1.2-2.415.el6.3ceph.x86_64\nqemu-guest-agent-0.12.1.2-2.415.el6.3ceph.x86_64\nqemu-kvm-tools-0.12.1.2-2.415.el6.3ceph.x86_64\nqemu-kvm-0.12.1.2-2.415.el6.3ceph.x86_64\ngpxe-roms-qemu-0.9.7-6.10.el6.noarch\n[root at compute1 ~(keystone_admin)]# rpm -qa |grep libvirt\nlibvirt-client-0.10.2-29.el6_5.3.x86_64\nlibvirt-python-0.10.2-29.el6_5.3.x86_64\nlibvirt-0.10.2-29.el6_5.3.x86_64\n\n\n\n',NULL,NULL),('<00B8FE1E-B887-456C-A77F-DEA9D00CAC23@cisco.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-06-04 03:37:32',0,'2013-06-04 03:37:32',NULL,'[Openstack-docs] [Openstack-operators] HA configuration in\n	OpenStack','\nHere is another HA option:\n\nhttp://docwiki.cisco.com/wiki/COE_Grizzly_Release:_High-Availability_Manual_Installation_Guide\n\nThe associated Puppet module should be ready in ~2 weeks. \n\nRegards,\nDaneyon Hansen\n\nOn Jun 3, 2013, at 1:13 PM, \"Daniel Mercer\" <dmercer at fantoccini.com> wrote:\n\n> On Jun 3, 2013, at 11:44 AM, \"Morris, Adam\" <Adam.Morris at providence.org> wrote:\n> \n>>> 1. Does Pacemaker is the preferred tool to base OpenStack HA solution on ?\n>>> \n>> \n>> No.  If you are experienced with Pacemaker then it is an option, and possibly a good one.\n>> What you are doing and what you need to provide redundancy for will determine what is a good solution.\n>> I do not think that there is \"A\" preferred tool, but I haven\'t seen that specific question asked.  At the Havana Summit there was a talk that I saw which stated that\n>> Corosync/pacemaker was a good way to do HA, but that is IMHO just an opinion.\n> \n> Thanks for the clarification Adam! The following is not directed at you but to the list in general -- actually, it probably should go to openstack-docs@ (Cc\'d).\n> \n> I think the way the doc (http://docs.openstack.org/trunk/openstack-ha/) is written it is easy for readers to form the impression that Pacemaker is required in order to deploy Openstack in an HA configuration. This probably wasn\'t the intent of the author, but for the sake of objectivity it may be a good idea to include an explanation that there are many ways HA can be implemented of which Pacemaker is the one being documented.\n> \n> dlm\n> GPG: 952A 2749 09E3 E96B 9E4B E85D 2D69 357B 95D1 E502\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<82FB9288-E81F-4B8B-A261-E9827BAFFB03@fantoccini.com>',NULL),('<00B8FE1E-B887-456C-A77F-DEA9D00CAC23@cisco.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-06-04 03:37:32',0,'2013-06-04 03:37:32',NULL,'[Openstack-operators] HA configuration in OpenStack','\nHere is another HA option:\n\nhttp://docwiki.cisco.com/wiki/COE_Grizzly_Release:_High-Availability_Manual_Installation_Guide\n\nThe associated Puppet module should be ready in ~2 weeks. \n\nRegards,\nDaneyon Hansen\n\nOn Jun 3, 2013, at 1:13 PM, \"Daniel Mercer\" <dmercer at fantoccini.com> wrote:\n\n> On Jun 3, 2013, at 11:44 AM, \"Morris, Adam\" <Adam.Morris at providence.org> wrote:\n> \n>>> 1. Does Pacemaker is the preferred tool to base OpenStack HA solution on ?\n>>> \n>> \n>> No.  If you are experienced with Pacemaker then it is an option, and possibly a good one.\n>> What you are doing and what you need to provide redundancy for will determine what is a good solution.\n>> I do not think that there is \"A\" preferred tool, but I haven\'t seen that specific question asked.  At the Havana Summit there was a talk that I saw which stated that\n>> Corosync/pacemaker was a good way to do HA, but that is IMHO just an opinion.\n> \n> Thanks for the clarification Adam! The following is not directed at you but to the list in general -- actually, it probably should go to openstack-docs@ (Cc\'d).\n> \n> I think the way the doc (http://docs.openstack.org/trunk/openstack-ha/) is written it is easy for readers to form the impression that Pacemaker is required in order to deploy Openstack in an HA configuration. This probably wasn\'t the intent of the author, but for the sake of objectivity it may be a good idea to include an explanation that there are many ways HA can be implemented of which Pacemaker is the one being documented.\n> \n> dlm\n> GPG: 952A 2749 09E3 E96B 9E4B E85D 2D69 357B 95D1 E502\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<82FB9288-E81F-4B8B-A261-E9827BAFFB03@fantoccini.com>',NULL),('<00ba01cfc778$35240630$9f6c1290$@sina.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-03 21:08:51',28800,'2014-09-03 13:08:51',NULL,'[Openstack] External accessing issue','Hi all,\n\n \n\nI\'m working on the external accessing configuration inside Virtualbox with a\nCentOS 6.5 x86_64.\n\n \n\nCurrently, I find that my Openstack instance can ping the Centos, but cannot\nping outside.\n\nLikewise, my Centos can ping the Openstack instance, but outside hosts\ncannot.\n\n \n\nIs there anyone encounter same issue with mine?\n\n \n\nBTW, my virtualbox network was using Bridge-Adapter.\n\n \n\nThanks for any help.\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140903/07f63cd8/attachment.html>\n\n',NULL,NULL),('<00bd3cf4436666a0336683d3efa5a14d@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-17 18:19:23',3600,'2013-11-17 17:19:23',NULL,'[Openstack-docs] git-review vs git review','Hello Andreas,\n\nLe 17/11/2013 06:06, Andreas Jaeger a ?crit?:\n> Looking at this change, I think there is some good content - and some\n> unneeded one:\n>\n> \n> https://wiki.openstack.org/w/index.php?title=Documentation/HowTo&diff=0&oldid=34956\n>\n> The installation of git-review is fine but the command itself is \"git\n> review\" - at least on openSUSE. I assume on other distros as well but\n> would like confirmation before somebody reverts those changes for the\n> command...\n\nBoth git-review and \"git review\" exist on debian/ubuntu, but I\'ve \nalways used the latest.\n\nGauvain\n\n\n-- \nGauvain Pocentek\n\nObjectif Libre - Infrastructure et Formations Linux\nhttp://www.objectif-libre.com\n\n\n','<52884EBB.6000202@suse.com>',NULL),('<00bf01ce55d0$96074360$c215ca20$@gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-21 10:09:14',25200,'2013-05-21 03:09:14',NULL,'[openstack-community] Mailing lists in non-English languages','Hello Stefano,\n\nI\'m from Vietnam and I agree with your idea about the native language. \n\nNow we  just discussed on a  fan page on Facebook\nhttps://www.facebook.com/groups/IaaS.VN and so on\nhttps://www.facebook.com/VietOpenStack?fref=ts\n\nIf possible, I suggest a sub domain such as vn.list.openstack.org to help\ngarnering attention to the Openstack project in our country. \n\nThank you,\n\nKhanh Nguyen Dang Quoc\nSenior Software/System Engineer \nVNG Corporation\n13th Floor The Flemington, 182 Le Dai Hanh St., Dist. 11, Ho Chi Minh City,\nVietnam\nE:  khanhndq at vng.com.vn  \nwww.vng.com.vn\n\n\n-----Original Message-----\nFrom: Stefano Maffulli [mailto:stefano at openstack.org] \nSent: segunda-feira, 20 de maio de 2013 18:21\nTo: Community User Groups, OpenStack\nSubject: [openstack-community] Mailing lists in non-English languages\n\nHello folks,\n\nI would like to test the idea of opening the list server lists.openstack.org\nto mailing lists in other languages than English.\n\nAt the moment lists.openstack.org only supports English for the user\ninterfaces, archives included. But mailman supports also different languages\nand our international community is growing, so I think it shouldn\'t be too\nhard to help discussions happen in other languages.\n\nDo you think it would be useful for your groups to have one place hosted by\non the OpenStack infrastructure, where discussions can happen in your local\nlanguage?\n\n/stef\n\n--\nAsk and answer questions on https://ask.openstack.org\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n','<162642CFACE02242ACAE35250B43E3548D10DEE9@GRUPRD8011MB604.lamprd80.prod.outlook.com>',NULL),('<00BF6D27-55FB-4BE7-AF2B-B7C882A48970@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-13 07:39:43',-25200,'2014-03-13 14:39:43',NULL,'[Openstack] Controller and network services in same node','You even can install all in one server with on nic. For red hat or centos, try packstack, for Ubuntu,try devstack.\n\n\n\n???? iPhone\n\n> ? Mar 13, 2014?7:11 AM?Upendra Sahu <upendrasahu20 at gmail.com> ???\n> \n> Hi,\n> \n> I want to install openstack in two node deployment.\n> \n> 1 node with controller(nova server, neutron server, keystone, message queue, storage, horizon, mysql etc) and network (neutron plugin agents: ovs, l3, dhcp, metadata) services\n> \n> 1 node for nova compute.\n> \n> please let me know if its possible to club controller and network node together or not.\n> \n> how many interfaces I need to have in 1st node and and for compute node.\n> \n> please help me on this.\n> \n> Upendra\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<CAE=rkfspcyDpHnxde-h26CpyXXMoq3Hq6Nc9i_n0e1Edrf84Uw@mail.gmail.com>',NULL),('<00c001cf3ed1$7dc47df0$794d79d0$@gmail.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-03-13 16:32:47',3600,'2014-03-13 15:32:47',NULL,'[User-committee] Survey',' \n\nTom,\n\n \n\nAre we doing OK on the survey schedule ? There\'s probably quite a lot of engineering work to be done now that there is a user\nsection as well as a deployment section. The schedule proposed had been\n\n \n\n-        March 1st Additional questions received and ready\n\n-        March 14st Questions finalised and submitted to web team to prepare the forms\n\n-        April 4th Start survey\n\n-        April 18th Close survey\n\n-        April 25th Data available from survey in raw format\n\n-        May 5th Slides/Material ready for review\n\n-        May 12th Summit Start\n\n \n\nTim\n\n \n\n--\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20140313/dab06696/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.png\nType: image/png\nSize: 34628 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20140313/dab06696/attachment-0001.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Tim Bell.vcf\nType: application/octet-stream\nSize: 4839 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20140313/dab06696/attachment-0001.obj>\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: \"Tim Bell\" <Tim.Bell at cern.ch>\nSubject: User/Operator survey lead time\nDate: Wed, 22 Jan 2014 20:43:47 +0100\nSize: 33050\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20140313/dab06696/attachment-0001.mht>\n\n',NULL,NULL),('<00c201cfe240$200d7190$602854b0$@com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-07 17:05:24',7200,'2014-10-07 15:05:24',NULL,'[Openstack-docs] [training-guides] running training sessions in\n	the sfbay openstack user group meetings','Too bad, just missed it. \n\n \n\nIn the notes I see mention of ppts . Where would I be able to see these? (pls excuse me if this is a noob q).\n\n \n\nWill attend next one if other commitments match.\n\n \n\n-Peter.\n\n \n\nFrom: sean roberts [mailto:seanroberts66 at gmail.com] \nSent: Monday, October 6, 2014 21:41\nTo: peter van eijk\nCc: openstack-docs >> openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] [training-guides] running training sessions in the sfbay openstack user group meetings\n\n \n\nWe hold the weekly training guides meeting on irc. See https://wiki.openstack.org/wiki/Meetings for the details on how to connect and times. All are welcome to participate. \n\n \n\nOn Mon, Oct 6, 2014 at 7:34 AM, peter van eijk <pveijk at gmail.com> wrote:\n\nHi\n\nI cloud be interested in participating in this and contributing to the effort, as it could complement my cloud training portfolio.\n\nI am relatively new to this community, so could somebody clue me in on the logistics of said training-guides meeting?\n\nBTW, my geography is NL/EU. I am in touch with local user groups.\n\n \n\nBest regards\n\n \n\nPeter HJ van Eijk | +31 6 2268 4939 | peter at clubcloudcomputing.com| Twitter @petersgriddle | www.clubcloudcomputing.com\n\n \n\n \n\n \n\nFrom: sean roberts [mailto:seanroberts66 at gmail.com] \nSent: Saturday, October 4, 2014 02:23\nTo: openstack-docs >> openstack-docs at lists.openstack.org; Stefano Maffulli; Tom Fifield; Shannon McFarland; mvoelker at cisco.com; Rick Evans; Polina Petriuk\nSubject: [Openstack-docs] [training-guides] running training sessions in the sfbay openstack user group meetings\n\n \n\nI am following up on the original intent of holding openstack user group meetings using the openstack training guides. The plan is to start with the associate guide and hold (6) 2 hour meetings starting the week after the summit. If this works, then perhaps we can develop this into associate training leading up to the summit, upstream training at the summit, followed by the more advanced training over the next release cycle. I am a bit murky on how we coalesce the slightly different training materials, but I\'d rather forge forward before answering all questions.\n\n \n\nSome logistical problems have started showing up as we were thinking through what needs to happen and by when. \n\n- we will need the network, object, and assessment quizzes completed. that isnt a huge deal since we have until jan until we hit the gap. i will track in the project.\n\n- if a laptop with enough mem or disk isn\'t available, we should have a backup like rackspace vm option instructions. again i will track in the project.\n\n- we will need to do trainer training. creating trainer notes for each chapter seems like a likely requirement. I am guessing that most trainers will revert to printing out the material and making notes on paper. this will be a problem. another issue to track in the project.\n\n- we will need to find, train, and retain trainers to help us make this work. Myself, Rick Evans, Polina Petriuk have discussed participating as trainers. I am hoping that Stef and Tom can help us find a few more sfbay area speaker/trainers.\n\n- we will need to find other user groups willing to clone our work asap, so we can get more, better. I have spoken with Shannon McFarland (Denver) and Mark Voelker (Durham) and they are interested.\n\n \n\nThe proposed training schedule below. I am including the likely Kilo release dates as they will impact our availability.\n\n \n\n1) session 1: 20 nov chapters 1-2 getting started \n2) session 2: 04 dec chap 3-4 controller\n\nWeek of 05 dec M1\n\n3) session 3: 18 dec chap 5-6 compute\n\nholiday break\n\n4)session 4: 22 jan chap 7-8 network\nWeek of 23 jan M2\n5) session 5: 05 feb chap 9-10 object\n6) session 6: 19 feb chap 11-12 assessment\nWeek of 20 feb feature freeze propose\nWeek of 06 mar feature freeze, M3\nWeek of 27 mar - 17 apr release\nWeek of 15 may design summit \n\n \n\nLet\'s discuss this at the next training-guides meeting. \n\n \n\n~ sean\n\n\n\n\n\n \n\n-- \n\n \n\n~ sean\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141007/dad3b72b/attachment.html>\n\n','<CAEoPogEpoAjDiQi-qqQ-ojM6jvOY0v+zOxPGCR5t=6fWvo8NMA@mail.gmail.com>',NULL),('<00C88327-1E87-4CA5-B4C2-6299A36FEA41@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 22:01:39',-28800,'2013-11-08 06:01:39',NULL,'[openstack-dev] L3 advanced features blueprint mapping to IETF\n	and IEEE standards','What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m in Japan and 6 a.m CET on the 20th.\nIt is not ideal but i suspect we will have interest in participating from both Europe and Asia.\nI volunteer myself and Nachi Ueno nachi at ntti3.com (the author of the BGP MPLS blueprint) as agenda organizers; please drop us a note if you intend to attend and wether you would like to present something to the group.\n\n  Pedro.\n\nOn Nov 7, 2013, at 11:27 AM, Rochelle.Grober <Rochelle.Grober at huawei.com> wrote:\n\n>  \n>  \n> From: Pedro Roque Marques [mailto:pedro.r.marques at gmail.com]\n> Colin,\n> \"The nice thing about standards is that there are so many of them to choose from.\"\n>  \n> For instance, if you take this Internet Draft:\n> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on RFC4364.\n>  \n> It has already been implemented as a Neutron plugin via OpenContrail (http://juniper.github.io/contrail-vnc/README.html); With this implementation each OpenStack cluster can be configured as its own Autonomous System.\n>  \n> There is a blueprint\n> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn\n> that is discussing adding the provisioning of the autonomous system and peering to Neutron.\n>  \n> Please note that the work above does interoperate with 4364 using option B. Option C is possible but not that practical (as an operator you probably don\'t want to expose your internal topology between clusters).\n>  \n> If you want to give it a try you can use this devstack fork: https://github.com/dsetia/devstack.\n> You can use it to interoperate with a standard router that implements 4364 and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.\n>  \n> I believe that the work i\'m referencing implements interoperability while having very minimal changes to Neutron. It is based on the same concept of neutron virtual network and it hides the BGP/MPLS functionality from the user by translating policies that establish connectivity between virtual networks into RFC 4364 concepts.\n> Please refer to: https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>  \n> Would it make sense to have an IRC/Web meeting around interoperability with RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work that has already been done there by multiple vendors as well as some carriers.\n>  \n> +1  And it should be scheduled and announced a reasonable time in advance developers can plan to participate.\n>  \n> --Rocky\n>  \n>   Pedro.\n>  \n> On Nov 7, 2013, at 12:35 AM, Colin McNamara <colin at 2cups.com> wrote:\n> I have a couple concerns that I don?t feel I clearly communicated during the L3 advanced features session. I?d like to take this opportunity to both clearly communicate my thoughts, as well as start a discussion around them.\n>  \n> Building to the edge of the \"autonomous system\"\n> The current state of neutron implementation is functionally the l2 domain and simple l3 services that are part of a larger autonomous system. The routers and switches northbound of the OpenStack networking layer handled the abstraction and integration of the components.\n> Note, I use the term ?Autonomous System? to describe more then the notion of BGP AS, but more broadly in the term of a system that is controlled within a common framework and methodology, and integrates with a peer system that doesn?t not share that same scope or method of control\n> These components that composed the autonomous system boundary implement protocols and standards that map into IETF and IEEE standards. The reasoning for this is interoperability. Before vendors utilize IETF for interoperability at this layer, the provider experience was horrible (this was my personal experience in the late 90?s).\n>  \n> Wednesdays discussions in the Neutron Design Sessions\n> A couple of the discussions, most notably the extension of l3 functionality fell within the scope of starting the process of extending Neutron with functionality that will result (eventually) in the ability for an OpenStack installation to operate as it?s own Autonomous System.\n> The discussions that occurred to support L3 advanced functionality (northbound boundary), and the QOS extension functionality both fell into the scope of Northbound and Southbound boundaries of this system.\n> My comments in the session\n> My comments in the session, while clouded with jet-lag were specifically around two concepts that are used when integrating other types of systems \n> 1. In a simple (1-8) tenant environment integration with a northbound AS is normally done in a PE-CE model that generally centers around mapping dot1q tags into the appropriate northbound l3 segments and then handling the availability of the L2 path that traverses with port channeling, MLAG, STP, Etc.\n> 2. In a complex environment (8+ for discussion) different Carrier Supporting Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are used. These allow the mapping of segregated tenant networks together and synchronizing between distributed systems. This normally extends the tagging or tunneling mechanism and then allows for BGP to synchronize NLRI information between AS?s.\n> These are the standard ways of integrating between carriers, but also components of these implementations are used to integrate and scale inside of a single web scale data center. Commonly when you scale beyond a certain physical port boundary (1000is edge ports in many implementations, much larger in current implementations) the same designs for C2C integrations are used to create network availability zones inside a web scale data center. \n> Support of these IETF and IEEE standard integrations are necessary for brown field installations\n> In a green field installation, diverging from IETF and IEEE standards on the north bound edge while not a great idea, can result in a functional implementation. In a brown field implementation where OpenStack Neutron will be integrated into an existing network core. This boundary layer is where we move from a controlled system into a distributed system. The cleanly integrate into this system, IETF and IEEE protocols and standards have to be followed. \n>  \n> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>When we diverge from this standards based integration at the north edge of our autonomous system we lose the ability to integrate without introducing major changes (and risk), into our core. In my experience this is sufficient to either slow or stall adoption. This is a major risk, that I believe can be mitigated.\n> My thoughts on mitigating this risk\n> We need to at least map and track the relevant IETF RFC?s that define the internet standards for integration at the AS boundary. I know that many of the network vendor developers that contribute to Neutron have access to people who both have deep knowledge of these standards, and also participate in the IETF working groups. I would hope that these resources could be leveraged to at least give a sanity check, at best ensure a compliant northbound interface to other systems.\n> Side benefit of engaging IETF members in this discussion\n> The other side benefit of this is that inventions inside of Neutron can also be communicated as standards to the rest of the world in the form of net new RFC?s. In OVS this has already happened, as OVS has emerged to be a common component in many network devices, and the need to establish and reference a common standard has risen it?s head. I would think that inventions within Neutron would follow this same path.\n>  \n> Regards,\n> Colin\n> Colin McNamara\n> People | Process | Technology\n> --------------------------------------------\n> Mobile:             858-208-8105\n> Twitter: @colinmcnamara\n> Linkedin:          www.linkedin.com/colinmcnamara\n> Blog:    www.colinmcnamara.com\n> Email:  colin at 2cups.com         \n>  \n>  \n>  \n>  \n> \n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/ae1a3e72/attachment.html>\n\n','<EE954C2560065B4BBB76E698E2FB112B0184CB1D@sjceml501-mbs.china.huawei.com>',NULL),('<00ca01cf643c$05ea4bd0$11bee370$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 15:18:37',32400,'2014-04-30 06:18:37',NULL,'[openstack-dev] [Ceilometer] Policy Issue','Hi : ZhiQiang ,\n\n Found this discussion after I filed the bug report.\n  https://bugs.launchpad.net/ceilometer/+bug/1314372\n\n Sorry for that.\n \n More than happy to work with you on following BP to implement a more\nadvance and user friendly policy settings to ceilometer.\n https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule\n\nIn your BP, \n\"For now, a non-admin user can delete alarm created by other user in same\ntenant, which seems not so good, after this bp is implemented, we can change\nthe default behavior very easily if we want.\"\n\n I was thinking,  at least we need role-based rules and generic rules (Ex:\ntenant_id:%(tenant_id)s) support in policy.json. \n  let me know your plans and also if you need any help.\n\nBest regards,\n          Sampath\n\n> -----Original Message-----\n> From: Julien Danjou [mailto:julien at danjou.info]\n> Sent: Monday, February 10, 2014 7:42 PM\n> To: ZhiQiang Fan\n> Cc: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Ceilometer] Policy Issue\n> \n> On Mon, Feb 10 2014, ZhiQiang Fan wrote:\n> \n> > So, is this loose policy limit designed purposely, or it just a simple\n> > implementation for policy?\n> \n> It\'s just nobody stepped up to implement a more complete one, indeed.\n> \n> > So, is there any opportunity to implement more strict policy check,\n> > for i.e. a normal user can read resources created by other users (to\n> > be stricter, may disable this too), but read+write for his own?\n> >\n> > I\'d like to get some help or advise before create a blueprint\n> \n> Yep, go ahead and create a blueprint. :) If you need help, just ask on\nthis list\n> or on IRC.\n> \n> --\n> Julien Danjou\n> -- Free Software hacker - independent consultant\n> -- http://julien.danjou.info\n\n\n\n\n','<m238jrz1ts.fsf@danjou.info>',NULL),('<00cd01cf4d6c$185e8c90$491ba5b0$@netone.co.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-01 14:34:47',32400,'2014-04-01 05:34:47',NULL,'[Openstack] Limit of tunnel_id_ranges in Neutron','GRE and VXLAN packet use 24bit id range. Max number of ID is 1,677,000\n\nand per host max number of subnet is 4094 that is inner VLAN limitation.\n\n \n\nHiroki Aramaki\n\n \n\nFrom: Robert Kukura [mailto:kukura at noironetworks.com] \nSent: Tuesday, April 01, 2014 11:17 AM\nTo: openstack at lists.openstack.org\nSubject: Re: [Openstack] Limit of tunnel_id_ranges in Neutron\n\n \n\n \n\nOn 3/31/14, 1:31 PM, Changbin Liu wrote:\n\nI notice that there are flow_mod flows on OVS which handle 1-to-1\ntranslations between VLAN IDs and GRE/VXLAN tunnel IDs. Does it mean the\nrange of tunnel_ids is limited by VLAN tags?\n\nThese local VLAN IDs on br-int are assigned separately on each compute or\nnetwork node by neutron\'s openvswitch-agent, so you should be able to use\nany number of networks simultaneously in your deployment as long as no more\nthan 4094 networks are active at once on any one node.\n\n-Bob\n\n\n\n\n\n\n \n\nThanks\n\n \n\nChangbin\n\n \n\nOn Sun, Mar 30, 2014 at 5:31 PM, Kyle Mestery <mestery at noironetworks.com>\nwrote:\n\nOn Fri, Mar 28, 2014 at 11:39 PM, Changbin Liu <changbin.liu at gmail.com>\nwrote:\n\nHi All,  \n\n \n\nMaybe this is a simple question: is there any limit on \"tunnel_id_ranges\" in\nNeutron configuration? Say, can I configured it to e.g., \"1:10000\" if I have\n10000 tenants in the cloud. I know VLAN is limited to 4094 tags.\n\n \n\nI googled around this issue but found that most commonly it  is configured\nto default \"1:1000\".\n\n \n\nThere should not be a limit here, although the code will verify the tunnel\nID falls within an allowed range for your tunnel protocol (currently GRE or\nVXLAN).\n\n \n\nThanks,\n\nKyle\n\n \n\nThanks\n\n \n\nChangbin\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n \n\n \n\n\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140401/cb32f538/attachment.html>\n\n','<533A21B5.1030803@noironetworks.com>',NULL),('<00cd01cfad60$e0d0f510$a272df30$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-01 16:16:21',28800,'2014-08-01 08:16:21',NULL,'[openstack-dev] [ceilometer] Compute agent local VM\n	inspector	-	potential enhancement','Heat cfntools is based on SSH, so I assume it requires TCP/IP connectivity\nbetween VM and the central agent(or collector). But in the cloud, some\nnetworks are isolated from infrastructure layer network, because of security\nreasons. Some of our customers even explicitly require such security\nprotection. Does it mean those isolated VMs cannot be monitored by this\nproposed-VM-agent?\n\nI really wish we can figur out how it could work for all VMs but with no\nsecurity issues.\n\nI\'m not familiar with heat-cfntools, so, correct me if I am wrong :)\n\n\nBest regards!\nKurt\n\n-----????-----\n???: Eoghan Glynn [mailto:eglynn at redhat.com] \n????: 2014?8?1? 14:46\n???: OpenStack Development Mailing List (not for usage questions)\n??: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector -\npotential enhancement\n\n\n\n> Disclaimer: I\'m not fully vested on ceilometer internals, so bear with me.\n> \n> For consumers wanting to leverage ceilometer as a telemetry service \n> atop non-OpenStack Clouds or infrastructure they don\'t own, some edge \n> cases crop up. Most notably the consumer may not have access to the \n> hypervisor host and therefore cannot leverage the ceilometer compute \n> agent on a per host basis.\n\nYes, currently such access to the hypervisor host is required, least in the\ncase of the libvirt-based inspector.\n \n> In such scenarios it\'s my understanding the main option is to employ \n> the central agent to poll measurements from the monitored resources \n> (VMs, etc.).\n\nWell, the ceilometer central agent is not generally concerned with with\npolling related *directly* to VMs - rather it handles acquiring data from\nRESTful API (glance, neutron etc.) that are not otherwise available in the\nform of notifications, and also from host-level interfaces such as SNMP.\n\n> However this approach requires Cloud APIs (or other mechanisms) which \n> allow the polling impl to obtain the desired measurements (VM memory, \n> CPU, net stats, etc.) and moreover the polling approach has it\'s own \n> set of pros / cons from a arch / topology perspective.\n\nIndeed.\n\n> The other potential option is to setup the ceilometer compute agent \n> within the VM and have each VM publish measurements to the collector \n> -- a local VM agent / inspector if you will. With respect to this \n> local VM agent approach:\n> (a) I haven\'t seen this documented to date; is there any desire / reqs \n> to support this topology?\n> (b) If yes to #a, I whipped up a crude PoC here:\n> http://tinyurl.com/pqjgotv  Are folks willing to consider a BP for \n> this approach?\n\nSo in a sense this is similar to the Heat cfn-push-stats utility[1] and\nseems to suffer from the same fundamental problem, i.e. the need for\ninjection of credentials (user/passwds, keys, whatever) into the VM in order\nto allow the metric datapoints be pushed up to the infrastructure layer\n(e.g. onto the AMQP bus, or to a REST API endpoint).\n\nHow would you propose to solve that credentialing issue?\n\nCheers,\nEoghan\n\n[1]\nhttps://github.com/openstack/heat-cfntools/blob/master/bin/cfn-push-stats\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n',NULL,NULL),('<00cd01cfd405$5f32bf40$1d983dc0$@org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 14:28:03',7200,'2014-09-19 12:28:03',NULL,'[openstack-dev] [Neutron][QoS] Applying QoS as Quota','Chuck,\nIt seems quite interesting! Are hp or community working to implement it?\n\nGiuseppe \n\n> -----Original Message-----\n> From: Carlino, Chuck [mailto:chuck.carlino at hp.com]\n> Sent: 19 September 2014 04:52\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n> \n> When you say \'associate to VMs\', that would be associating to neutron\nports,\n> right?  If so, this is a subset of what is in:\n> \n>\nhttps://blueprints.launchpad.net/neutron/+spec/neutron-port-template-frame\nwork\n>\nhttps://blueprints.launchpad.net/neutron/+spec/neutron-port-template-polic\ny\n> \n> which also include things like bandwidth guarantees and security policy.\nI\'m\n> not sure if anyone is pursuing these right now, but there may be some\nuseful\n> ideas in there.\n> \n> Chuck\n> \n> \n> On Sep 18, 2014, at 4:25 PM, Giuseppe Cossu <giuseppe.cossu at create-\n> net.org<mailto:giuseppe.cossu at create-net.org>> wrote:\n> \n> Hello,\n> I\'m aware it\'s not so easy to define a solution, so I\'ll expose my idea.\n> I was thinking about a \"network flavor\" that a tenant can associate to\nVMs.\n> Basically the network flavour is a QoS policy.\n> The admin can define the network flavors (Gold, Silver, ... call it as\nyou\n> want) with a set of parameters (some visible to user, some not).\n> If we define this kind of flavours, a related quota should be define to\nkeep\n> track the network resources.\n> \n> Giuseppe\n> \n> From: Veiga, Anthony\n> [mailto:Anthony_Veiga at cable.comcast.com<http://cable.comcast.com>]\n> Sent: 10 September 2014 15:11\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota\n> \n> \n> \n> Using the quota system would be a nice option to have.\n> \n> Can you clarify what you mean by cumulative bandwidth for the tenant? It\nwould\n> be possible to rate limit at the tenant router, but having a cumulative\nlimit\n> enforced inside of a tenant would be difficult.\n> \n> On Wed, Sep 10, 2014 at 1:03 AM, Giuseppe Cossu <giuseppe.cossu at create-\n> net.org<mailto:giuseppe.cossu at create-net.org>> wrote:\n> \n> Hello everyone,\n> \n> Looking at the QoS blueprint (proposed for incubation), I suggest to\nconsider\n> adding some parameters to Neutron Quotas. Let\'s suppose using rate-limit\nfor\n> managing QoS. The quota parameters could be such as rate_limit (per\nport) and\n> max_bandwidth (per tenant). In this way it is possible to set/manage QoS\n> quotas from the admin side, and for instance set the maximum bandwidth\nallowed\n> per tenant (cumulative).\n> \n> What do you think about it?\n> \n> I\'m cautious about this.  We\'d either need to allow a \"Number of DSCP\n> settings\" and set them outside the quota or leave it out altogether.\nLet\'s\n> not forget that there\'s more than just rate limiting in QoS, and we need\nto\n> make sure all the options are included.  Otherwise, there\'s going to be\na lot\n> of user and operator confusion as to what is and isn\'t considered part\nof the\n> quota.\n> -Anthony\n> \n> Regards,\n> Giuseppe\n> \n> --------------------------------------------------------\n> Giuseppe Cossu\n> CREATE-NET\n> --------------------------------------------------------\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n>\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org\n>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> --\n> Kevin Benton\n> _______________________________________________\n> OpenStack-dev mailing list\n>\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org\n>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F25A729F-0B03-403D-A62D-BBA52250A342@hp.com>',NULL),('<00cd01cffaa9$efe2f800$cfa8e800$@expresswebsystems.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-07 10:43:18',-21600,'2014-11-07 16:43:18',NULL,'[Openstack-operators] Ceph Implementations','Since there seems to be a fair amount of people on this list running Ceph\nwith Openstack, I wanted to ask what configuration most people are using for\ntheir Ceph/Openstack configuration.\n\n \n\nWe tried installing Ceph on CentOS 6 (storage nodes and nova nodes) but\ndiscovered that the kernel that is included in RDO (for nova) doesn\'t\ninclude rbd support in qemu-img. No problem we thought, we will just use the\nkernel-lt from elrepo which does include support for rbd. However after\ninstalling those kernels we discovered that our GRE based networking didn\'t\nwork. After some additional troubleshooting we determined that the kernel-lt\ndidn\'t include the backported ovs vport GRE capability that the RDO kernel\nhas (it apparently was added in 3.11 but kernel-lt is 3.10).\n\n \n\nSo we have to decide how we want to implement our cluster and cloud. \n\n \n\nAre you implementing Openstack on Debian/Ubuntu to get around these sorts of\nissues? \n\nAre you running newer mainline kernels (kernel-ml) with CentOS 6? \n\nOr are you running vlan based tenant isolation for your tenant networks? \n\nAre you running custom compiled kernels?\n\nIs there something else I am missing?\n\n \n\nAny input from your experience is greatly appreciated.\n\n \n\nWarm regards,\n\n \n\nTom Walsh\n\nExpress Web Systems\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141107/03b1946c/attachment.html>\n\n',NULL,NULL),('<00cf01cfa652$f3f0d710$dbd28530$@sina.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-23 16:49:02',28800,'2014-07-23 08:49:02',NULL,'[Openstack] Inconsistent official docs for enabling LBaas and Fwaas','Hi all,\n\n \n\nIs there anyone knows how to enable LBaas and Fwaas simultaneously?\n\nCurrently, I\'m totally confused by 2 different config doc.\n\n \n\nOne is from\nhttp://docs.openstack.org/admin-guide-cloud/content/install_neutron-fwaas-ag\nent.html which told me to modify neutron.conf as below.\n\nservice_plugins = firewall\n\n \n\nAnother doc from https://wiki.openstack.org/wiki/Neutron/FWaaS/HowToInstall\nwhich told me to change same attribute with \n\nservice_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin\n\n \n\nThe thing confused me is why these 2 official docs instruct me to change the\nsame parameter, \'service_plugins\', with 2 absolutely different values and\nformats.\n\n \n\nDos Openstack support both of these 2 formats at a same time? If not, which\ninstruction is correct?\n\n \n\nThanks for any help!\n\nXianyi Ye\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140723/58355079/attachment.html>\n\n',NULL,NULL),('<00D63FF0-6606-41CB-82E7-080CDB98D889@openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-10-03 13:17:28',7200,'2014-10-03 11:17:28',NULL,'[openstack-community] Free passes to CloudOpen EU Dusseldorf\n	available for Booth Volunteers','We\'re still looking for 4 knowledgeable volunteers to help out at the OpenStack booth at CloudOpen / LinuxCon Europe in D?sseldorf, Germany on October 13-15, 2014. \n\nIf you are available during any of the following times please contact me -  shari at openstack.org - and we can set you up with a free conference pass.\n\nFeel free to reach out if you have any questions!\n\nCheers,\nShari\n\nTechnology Showcase Hours\n	? Monday, October 13th: 10:45am - 4:30pm\n	? Tuesday, October 14th: 10:45am - 2:30pm; 5:00pm - 7:00pm\n	? Wednesday, October 15th: 10:45am - 2:30pm\n\nSet-up Hours:\n	? Sunday, October 12th: 4:00pm - 7:00pm\n\nTear-Down Hours:\n	? Wednesday, October 15th: 2:30pm - 5:00pm\n\n\nShari Mahrdt\nOpenStack Foundation\nshari at openstack.org\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141003/120fbb66/attachment.html>\n\n','<C5744198-8FA1-458E-8E11-F08B11E41742@openstack.org>',NULL),('<00d801d000df$1e834210$5b89c630$@austin.rr.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-15 08:19:07',-21600,'2014-11-15 14:19:07',NULL,'[OpenStack-docs] Design revisions and follow up','I love the new pages!\n\n \n\nFrom: Anne Gentle [mailto:anne at openstack.org] \nSent: Friday, November 14, 2014 1:50 PM\nTo: openstack-docs at lists.openstack.org\nSubject: [OpenStack-docs] Design revisions and follow up\n\n \n\nHi all,\n\nI wanted to let you know our Foundation web designer Wes has completed the next round of revisions for the designs based on our input from this week\'s Doc team meeting. Here are his responses to my emailed requests, probably easiest if I just copy and paste them here. I especially appreciate the less-footer-like base now.\n\n \n\nPlease take a look by early next week and let me know if you have any concerns, otherwise I\'m ready to call this the design we\'re going with. I\'ll work with the web devs/designers on a plan to convert to RST/Sphinx. \n\n \n\nMain page - http://openstack-homepage.bitballoon.com/docs\n\nBook view - http://openstack-homepage.bitballoon.com/docs/book\n\nSearch results - http://openstack-homepage.bitballoon.com/docs/search\n\nLanguage landing page (new):  <http://openstack-homepage.bitballoon.com/docs/ja> http://openstack-homepage.bitballoon.com/docs/ja\n\n \n\nThanks!\n\nAnne\n\n \n\n[?] directional but we didn\'t see it. - Same as above, increased the size of the icons.\n\n[?] Could it be bumped even larger? Was the question asked. :)\n\n- bumped it up a little bit more. If this still isn?t clear, I can use some different icons. I?d rather not go any larger than this, because of the impact it has on the design. It might be an issue where the circle outline makes the direction less obvious. It?s an easy switch, so let me know. I also added a scroll function so the user will drop to the body of the page when ?View The Docs? is clicked.\n\n \n\n[?] What happens I think on many Chrome/Mac users is they don\'t know to scroll past it. They think they only click the button to get to content. Not sure I have solutions but wanted to let you know. Maybe it\'s because it\'s blue all the way across, like a footer?\n\nGot it! I made some changes to this section so it looks more like body content (and less like a footer.) Hopefully this helps.\n\n \n\n[?] needs to be larger - Increased the size of the font and converted the size to em\n\n[?] Even more increase please? :) Maybe we\'re all glasses-wearing nerds, I dunno.\n\nIncreased it a bit more. I didn?t want to go overboard with the size, especially since there is quite a bit of text but let me know if it needs to go larger. This is also an easy fix, so keep the feedback coming.\n\n \n\n[?] Noted: what will the landing page look like in another language?\n\nI took a shot at creating the page in Japanese, using the content you have on the current page. I?m certain there are holes since I?m a novice at translations :) but it should give some idea to how it will look. Let me know if this isn?t what you had in mind. http://openstack-homepage.bitballoon.com/docs/ja\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141115/10a2567c/attachment.html>\n\n','<CAD0KtVEUnGjnJWB_5vX9sJxHt1mgvKFGEHvPqwoBdaFwdxS+1w@mail.gmail.com>',NULL),('<00D9D113-6499-498E-88AB-6BCD0A6ED43B@oracle.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 12:05:32',-25200,'2014-09-09 19:05:32',NULL,'[openstack-dev]  [solum] pep8 - splitting expressions','I have a question with regards to splitting expressions in order to conform to the pep8 line-length restriction. I have the following bit of code:\n\n            res = amodel.Assemblies(uri=common.ASSEM_URI_STR %\n                                    pecan.request.host_url,\n                                    name=\'Solum_CAMP_assemblies\',\n                                    type=\'assemblies\',\n                                    description=common.ASSEM_DESC_STR,\n                                    assembly_links=a_links,\n                                    parameter_definitions_uri=common.ASSEM_PARAM_STR %\n                                    pecan.request.host_url)\n\nThe line that assigns a value to \'parameter_definitions_uri\' is (as you might be able to tell) too long. What is the best way to split this expression up?\n\n~ gp\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140909/9ecbc04c/attachment.html>\n\n',NULL,NULL),('<00df01cfc1ba$8448b8f0$8cda2ad0$@sina.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-27 13:48:23',28800,'2014-08-27 05:48:23',NULL,'[Openstack] Instance cannot get any ip address','Hi all,\n\n \n\nI was working on the external network accessing configuration. But I find\nthat after I created an instance, neither internal ip address nor external\nip address could be displayed in the response of \"ifconfig\" command.\n\nHowever, on Dashboard, I can see both of these 2 ip addresses have been\nallocated to that instance successfully.\n\nIs there anyone knows what\'s going on?\n\n \n\nI do appreciate anyone\'s help.\n\n \n\nThanks very much!\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140827/d4c26ece/attachment.html>\n\n',NULL,NULL),('<00E37E7F-84CA-4ED8-AF0C-574087038B8B@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-22 09:40:57',-25200,'2013-03-22 16:40:57',NULL,'[openstack-dev] Keystone Benchmark','We don\'t have any explicit benchmarking scripts set up and captured for Keystone in keystone\'s code base.\n\nI\'ve been doing benchmarking and live-system analysis, in my case based on post-processing of proxy log output and then reporting latency and processing times for various API calls. My analysis has been mostly whole system and a specific configuration. The logs were generated using various \"work the cloud\" continual load tests. \n\nFor single-point direct analysis, you could use any testing system you like that generates HTTP request with specific bodies and headers - grinder, locust, etc. I don\'t know if anyone working on Tempest has done similar things or not. \n\n- joe\n\nOn Mar 22, 2013, at 7:47 AM, Joe Hakim Rahme <joe.hakim.rahme at enovance.com> wrote:\n> I wrote a short benchmark script that launches multiple requests to\n> Keystone and measures the response time to get the authentication\n> token. Since I couldn\'t find anything that does this in Keystone, I\n> thought it\'d be a good idea to add a benchmark tool. Swift already has\n> something similar (common/bench.py).\n> \n> Since I am new to the community (and OpenStack in general) I thought I\'d\n> consult with you here to avoid going in a wrong direction. So here are a\n> few questions:\n> \n> - Is there an existing script that does this and that I might have\n>   missed?\n> - What features would you suggest I include in this tool?\n> - Should I follow (reuse?) what\'s already done for the Swift bench?\n> \n> Thank you for your answers,\n> J.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<4FBDB356-CFEA-48AF-B18D-C1A190871901@enovance.com>',NULL),('<00e401ceee58$bbaf3e80$330dbb80$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-11-30 21:46:50',-28800,'2013-12-01 05:46:50',NULL,'[openstack-community] OpenStack from Austin to Havana',' \n\nThose who missed last OpenStack summit need not worry. DetaCloud will bring\nHong Kong highlights to OpenStack Northwest Meetup. We will level set new\ncomers on the technology then cover what\'s new in the Havana release and how\nit all fits in the overall Cloud market landscape. Come learn, chat, network\nand have a good time.\n\nWhere: Puppet Labs, 926 NW 13th Ave #210, Portland, OR.\n\nWhen: Wednesday Dec 4 @ 6:30 pm PDT\n\nJoin and free RSVP here: http://www.meetup.com/OpenStack-Northwest\n\nThe meetup caters to both the industry curious and technology professionals.\nAfter a short introduction, we will describe the lay of the land, why\nOpenStack, how it works and what\'s new in the latest release, Havana, and\nfinally, automation with Puppet.\n\nFollow @DetaCloud for livestream/recording link.\n\nHope to see you there.\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131130/ae6cc866/attachment.html>\n\n',NULL,NULL),('<00e401ceee58$bbaf3e80$330dbb80$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-30 21:46:50',-28800,'2013-12-01 05:46:50',NULL,'[Openstack] OpenStack from Austin to Havana',' \n\nThose who missed last OpenStack summit need not worry. DetaCloud will bring\nHong Kong highlights to OpenStack Northwest Meetup. We will level set new\ncomers on the technology then cover what\'s new in the Havana release and how\nit all fits in the overall Cloud market landscape. Come learn, chat, network\nand have a good time.\n\nWhere: Puppet Labs, 926 NW 13th Ave #210, Portland, OR.\n\nWhen: Wednesday Dec 4 @ 6:30 pm PDT\n\nJoin and free RSVP here: http://www.meetup.com/OpenStack-Northwest\n\nThe meetup caters to both the industry curious and technology professionals.\nAfter a short introduction, we will describe the lay of the land, why\nOpenStack, how it works and what\'s new in the latest release, Havana, and\nfinally, automation with Puppet.\n\nFollow @DetaCloud for livestream/recording link.\n\nHope to see you there.\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131130/ae6cc866/attachment.html>\n\n',NULL,NULL),('<00e701d01dec$11b31220$35193660$@t-online.de>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-12-22 14:34:53',3600,'2014-12-22 13:34:53',NULL,'[OpenStack-Infra] [Support] Problems installing zuul for\n	jenkins-gerrit gateway (Jenkins does not run jobs)','Hello all together,\n\ni hope, someone of you can help me with my little problem. Actually I use\nGerrit Trigger 8Jenkins plugin) to trigger Jenkins jobs for specific Gerrit\nevents. Now I want to migrate from Gerrit Trigger to zuul (easier, layout\nbased configuration and more trigger options and different pipelines).\n\nI installed zuul with this Blog post as a basis:\nhttp://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.ht\nml\n\nYou can find my zuul configuration here[1] and my initial layout.yaml\nhere[2]\n\nNow I have the problem, that it seems, that Jenkins doesn\'t run jobs added\nIn gearman (they don\'t appear in Jenkins web frontend). Zuul\'s status page\nlists the change (added via a \"recheck\" comment) and the status of the job\n\"Jenkins-test\" is \"queued\" forever. That\'s why I think there is a problem\nsomewhere between Jenkins and zuul, but I can\'t find it. I hope, that\nsomeone from here can assist me to find out the problem? I cleared the log\nand restarted Jenkins and zuul (stopped both and started zuul first and then\nJenkins) and added a new comment \"recheck\" to my test change in gerrit to\ntrigger a new build. I uploaded my log files here[3], maybe it helps to find\nout the problem. I have anonymized the domain to be \"example.com\" in the log\nfiles. \n\nI\'m also online in #openstack-infra on freenode (nick: FlorianSW), so feel\nfree to contact me there, I would be very grateful to get help to solve this\nproblem :)\n\n[1] https://gist.github.com/Florianschmidtwelzow/ed0e3047f0ef0c5e5554\n[2] https://gist.github.com/Florianschmidtwelzow/a101a87d653d5bbc6de6\n[3] https://gist.github.com/Florianschmidtwelzow/12fff7c4530805dece0c\n\nKind regards,\nFlorian\n\n\n\n',NULL,NULL),('<00E9A406-012D-46BE-8796-7AAF199F44E9@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-06-14 05:17:11',-25200,'2011-06-14 12:17:11',NULL,'[Openstack-operators] Using OpenStack in my office','On Jun 14, 2011, at 5:00 AM, openstack-operators-request at lists.openstack.org wrote:\n> I currently have a script that connects to Amazon\'s API, and starts the\n> various types of instances I need and using MetaData, I can then run a bash\n> script automatically on each instance, to identify its role, and thus, start\n> various services on the instance.\n> \n> How much different is OpenStack from Amazon for me to migrate over to\n> OpenStack for our QA env?\n\n\n\nShai -\n\nAssuming that the library you are using to write your provisioning scripts allows you to change the API end point URL/URI and port (to point to your nova-api server), OpenStack Nova should be very similar. \n\nYou may need to repackage your images (for the virtualization solution you choose) but otherwise I don\'t see many differences.\n\n/k\n\n---\nKen Pepple\nken.pepple at gmail.com\nhttp://ken.pepple.info/\n@ken_pepple\n\n\n\n\n\n','<mailman.1.1308052802.27134.openstack-operators@lists.openstack.org>',NULL),('<00eee5bae23a4ba7a9cbd85588c99f2c@HKNPR01MB241.apcprd01.prod.exchangelabs.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 12:23:10',0,'2014-07-21 12:23:10',NULL,'[openstack-dev] [Cinder] Integrated with iSCSI target Question','Dear Thomas,\n\nThanks for your reply.\nSo when I attach volume manually, will iSCSI LUN be automatically setup via cinder.conf (iscsi_helper and iscsi_ip_address)?\n\n\nRegards,\nJohnson\n\n-----Original Message-----\nFrom: Duncan Thomas [mailto:duncan.thomas at gmail.com] \nSent: Monday, July 21, 2014 6:16 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question\n\nThe iSCSI lun won\'t be set up until you try to attach the volume\n\nOn 17 July 2014 12:44, Johnson Cheng <Johnson.Cheng at qsantechnology.com> wrote:\n> Dear All,\n>\n>\n>\n> I installed iSCSI target at my controller node (IP: 192.168.106.20),\n>\n> #>iscsitarget open-iscsi iscsitarget-dkms\n>\n>\n>\n> then modify my cinder.conf at controller node as below,\n>\n> [DEFAULT]\n>\n> rootwrap_config = /etc/cinder/rootwrap.conf\n>\n> api_paste_confg = /etc/cinder/api-paste.ini\n>\n> #iscsi_helper = tgtadm\n>\n> iscsi_helper = ietadm\n>\n> volume_name_template = volume-%s\n>\n> volume_group = cinder-volumes\n>\n> verbose = True\n>\n> auth_strategy = keystone\n>\n> #state_path = /var/lib/cinder\n>\n> #lock_path = /var/lock/cinder\n>\n> #volumes_dir = /var/lib/cinder/volumes\n>\n> iscsi_ip_address=192.168.106.20\n>\n>\n>\n> rpc_backend = cinder.openstack.common.rpc.impl_kombu\n>\n> rabbit_host = controller\n>\n> rabbit_port = 5672\n>\n> rabbit_userid = guest\n>\n> rabbit_password = demo\n>\n>\n>\n> glance_host = controller\n>\n>\n>\n> enabled_backends=lvmdriver-1,lvmdriver-2\n>\n> [lvmdriver-1]\n>\n> volume_group=cinder-volumes-1\n>\n> volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n>\n> volume_backend_name=LVM_iSCSI\n>\n> [lvmdriver-2]\n>\n> volume_group=cinder-volumes-2\n>\n> volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n>\n> volume_backend_name=LVM_iSCSI_b\n>\n> [database]\n>\n> connection = mysql://cinder:demo at controller/cinder\n>\n>\n>\n> [keystone_authtoken]\n>\n> auth_uri = http://controller:5000\n>\n> auth_host = controller\n>\n> auth_port = 35357\n>\n> auth_protocol = http\n>\n> admin_tenant_name = service\n>\n> admin_user = cinder\n>\n> admin_password = demo\n>\n>\n>\n> Now I use the following command to create a cinder volume, and it can \n> be created successfully.\n>\n> #> cinder create --volume-type lvm_controller --display-name vol 1\n>\n>\n>\n> Unfortunately it seems not attach to a iSCSI LUN automatically because \n> I can not discover it from iSCSI initiator,\n>\n> #> iscsiadm -m discovery -t st -p 192.168.106.20\n>\n>\n>\n> Do I miss something?\n>\n>\n>\n>\n>\n> Regards,\n>\n> Johnson\n>\n>\n>\n>\n>\n> From: Manickam, Kanagaraj [mailto:kanagaraj.manickam at hp.com]\n> Sent: Thursday, July 17, 2014 1:19 PM\n>\n>\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target \n> Question\n>\n>\n>\n> I think, It should be on the cinder node which is usually deployed on \n> the controller node\n>\n>\n>\n> From: Johnson Cheng [mailto:Johnson.Cheng at QsanTechnology.com]\n> Sent: Thursday, July 17, 2014 10:38 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: [openstack-dev] [Cinder] Integrated with iSCSI target \n> Question\n>\n>\n>\n> Dear All,\n>\n>\n>\n> I have three nodes, a controller node and two compute nodes(volume node).\n>\n> The default value for iscsi_helper in cinder.conf is ?tgtadm?, I will \n> change to ?ietadm? to integrate with iSCSI target.\n>\n> Unfortunately I am not sure that iscsitarget should be installed at \n> controller node or compute node?\n>\n> Have any reference?\n>\n>\n>\n>\n>\n> Regards,\n>\n> Johnson\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n--\nDuncan Thomas\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<CAOyZ2aEwsu7A+1Sqe7AZB9cgNgLbTff4yAtx_8U-db3v3C7i_w@mail.gmail.com>',NULL),('<00f001cfc1c7$7ef67f10$7ce37d30$@sina.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-27 15:21:18',28800,'2014-08-27 07:21:18',NULL,'[Openstack] Instance cannot get any ip address','Hi, thanks for your helps!\n\n \n\nAfter I enabled DHCP, my instance can get private ip address now.\n\n \n\nHowever, I find that my 2 instances still cannot ping each other successfully.\n\nSo I want to know if I need to config a DNS server for them?\n\n \n\nThanks very much!\n\n \n\nFrom: ?? [mailto:yanchao727 at gmail.com] \nSent: 2014?8?27? 14:31\nTo: Xianyi Ye\nCc: <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Instance cannot get any ip address\n\n \n\nTry to use:\n$ip netns\n\nto find network namespace.\n\n\n\n\nBest Regards?\n\nChao Yan\n--------------\nMy twitter?Andy Yan @yanchao727 <https://twitter.com/yanchao727> \nMy Weibo?http://weibo.com/herewearenow\n--------------\n\n \n\n2014-08-27 14:23 GMT+08:00 ?? <yanchao727 at gmail.com>:\n\nWhat is the output of ifconfig? Are you using Neutron and ip netns?\n\n\n\n\nBest Regards?\n\nChao Yan\n--------------\nMy twitter?Andy Yan @yanchao727 <https://twitter.com/yanchao727> \nMy Weibo?http://weibo.com/herewearenow\n--------------\n\n \n\n2014-08-27 13:48 GMT+08:00 Xianyi Ye <yexianyi at sina.com>:\n\nHi all,\n\n \n\nI was working on the external network accessing configuration. But I find that after I created an instance, neither internal ip address nor external ip address could be displayed in the response of ?ifconfig? command.\n\nHowever, on Dashboard, I can see both of these 2 ip addresses have been allocated to that instance successfully.\n\nIs there anyone knows what?s going on?\n\n \n\nI do appreciate anyone?s help.\n\n \n\nThanks very much!\n\n \n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140827/5ac0b9c7/attachment.html>\n\n','<CALAMvO-PfDyyO+VxETV0Oq5PM8Vs5DRRANJzj4E8aMoJ2kX2+g@mail.gmail.com>',NULL),('<00f228af4c0d116d8e2cb92daba0fa87@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-18 17:18:14',7200,'2014-08-18 15:18:14',NULL,'[Openstack-docs] Proposal: Bug Squashing day on the 9th of\n September','Le 2014-08-12 21:36, Andreas Jaeger a ?crit?:\n> On 08/12/2014 05:29 PM, Anne Gentle wrote:\n>> Thanks Andreas! Sounds like we have a good day and start. I\'ll add it \n>> to\n>> this week\'s What\'s Up Doc and we\'ll plan for 9/9/14 bug squashing.\n> \n> I noticed that many bugs can be fixed with the autogeneration of our \n> tables.\n> \n> Gauvain, could you do a run before the 9th, please? That way we might \n> be\n> able to close many bugs as fixed since the values are already in...\n\nSure!\n\nGauvain\n\n\n','<53EA6CB7.7070503@suse.com>',NULL),('<00f51a0831764790b071eeb81d864dbf@HKXPR04MB183.apcprd04.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-11 04:37:50',0,'2014-10-11 04:37:50',NULL,'[Openstack] [openstacl][neutron][ml2][vlan]','Hi ,\n\nWhen I am configuring ML2 plugin with vlan based network ,  nova boot is failing with following error ,where as if I change the driver from ML2 to OVS  , things are working fine .\nPlease suggest.\n\n\nHere is the ml2 configuration:\n\n[ml2]\ntype_drivers = vlan\ntenant_network_types = vlan\nmechanism drivers = openvswitch\n[ml2_type_vlan]\nnetwork_vlan_ranges = physnet1:1:4094\n[ovs]\ntenant_network_type = vlan\nnetwork_vlan_ranges = physnet1:1:4094\nbridge_mappings = physnet1:br-eth1\n[securitygroup]\nfirewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\nenable_security_group = True\n\n/etc/neutron/neutron.conf:\ncore_plugin = ml2\nservice_plugins = router\nallow_overlapping_ips = True\n\n\nlogs:\n\n\nroot at build-server:/etc/init# grep -ir \"241e4c21-5604-4a1b-a782-f44128fbd0b3\" /var/log/nova/*\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0] [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Instance failed to spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Traceback (most recent call last):\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720, in _spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     block_device_info)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250, in spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     write_to_disk=True)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431, in to_xml\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     disk_info, rescue, block_device_info)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3247, in get_guest_config\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384, in get_config\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     _(\"Unexpected vif_type=%s\") % vif_type)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] NovaException: Unexpected vif_type=binding_failed\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n/var/log/nova/nova-compute.log:2014-09-11 02:41:23.877 21941 ERROR nova.virt.libvirt.driver [-] [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance disappeared.\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0] [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Error: Unexpected vif_type=binding_failed\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Traceback (most recent call last):\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1311, in _build_instance\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     set_access_ip=set_access_ip)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 399, in decorated_function\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     return function(self, context, *args, **kwargs)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1723, in _spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     LOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py\", line 68, in __exit__\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     six.reraise(self.type_, self.value, self.tb)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720, in _spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     block_device_info)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250, in spawn\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     write_to_disk=True)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431, in to_xml\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     disk_info, rescue, block_device_info)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3247, in get_guest_config\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384, in get_config\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]     _(\"Unexpected vif_type=%s\") % vif_type)\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] NovaException: Unexpected vif_type=binding_failed\n/var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n/var/log/nova/nova-compute.log:2014-09-11 02:50:44.135 23339 ERROR nova.virt.libvirt.driver [-] [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance disappeared.\n\n\nRegards,\nSubbareddy\nPersistent systems ltd.\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141011/cc4a1245/attachment.html>\n\n',NULL,NULL),('<00FE4FBC-5084-4AEE-847B-B900E52B5FC3@mattei.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-23 17:09:23',-28800,'2013-12-24 01:09:23',NULL,'[Openstack] neutron install guide wording question','I have done in two modes controller and compute and works fine with no problems \n\nI have not chk the link yet bit you should have no problem with this mode. \n\nInviato da iPhone (?)\n\n> Il giorno Dec 23, 2013, alle ore 16:42, Matt Kassawara <mkassawara at gmail.com> ha scritto:\n> \n> You don\'t need a three-node architecture (controller, network, and compute) to deploy the Networking/Neutron service, but it seems to work best with the installation guide and also simplifies debugging.\n> \n> \n>> On Mon, Dec 23, 2013 at 5:07 PM, August Simonelli <augustsimonelli at yahoo.com> wrote:\n>> Hi all,\n>> \n>> I?m currently going through the havana install guide for a yum-based distro and planning my required hardware. I was hoping to only use two hosts and needed some clarification around neutron:\n>> \n>> Do i need a dedicated network node (exclusive of controller and compute) if i want to use neutron as per the guide? The install guide (http://docs.openstack.org/havana/install-guide/install/yum/content/neutron-install-network-node.html) lists 3 scenarios, one each for dedicated network/compute/controller but the wording is confusing me:\n>> \n>> Install Networking services on a dedicated network node\n>> Install networking support on a dedicated compute node\n>> Install networking support on a dedicated controller node\n>> \n>> I first thought these were mutually exclusive, If i wanted to run networking on it?s own node, use the first, if i wanted networking on compute use the second etc.\n>> \n>> But i noticed the wording uses ?services? for network node and ?support? for the others. Is it correct to assume this example is NOT mutually exclusive and rather each step must be taken on individual respective nodes (one network, one compute and one controller) in a single cloud (i.e. therefor a minimum of 3 nodes)?\n>> \n>> Thanks in advance,\n>> \n>> August\n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> !DSPAM:2,52b8dc57278161812946874!\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:2,52b8dc57278161812946874!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/31b087cf/attachment.html>\n\n','<CABA+jQo1eBzP7PWHEmEYw9iQCcuR=nKs87CStc1B9VjPY-gntA@mail.gmail.com>',NULL),('<01002C72-A319-4944-B0BF-F983BDF7CA85@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 21:29:24',25200,'2014-04-16 14:29:24',NULL,'[openstack-dev] [heat][mistral] Mistral agenda item for Heat\n	community meeting on Apr 17','Hi,\n\nCan we include action item ?Heat/Mistral collaboration? into the agenda of tomorrow?s Heat community meeting? I?d like to take a few minutes and discuss this a little bit. If you think it?s not a suitable time/way to discuss it please let me know your preferences.\n\nThanks\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n\n\n',NULL,NULL),('<010f01cda889$d14d4360$73e7ca20$@mirantis.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-12 07:56:52',-25200,'2012-10-12 14:56:52',NULL,'[OpenStack Foundation] [Foundation Board] OpenStack syllabi\n	-was- Re: Use of the word \"certified\" and protecting brand OpenStack','I second Lloyd\'s comment. We\'ve been running a very popular OpenStack\nBootcamp program and have delivered 20+ private and public OpenStack classes\nduring the last 6 months. We\'ve been asked on many occasions about OpenStack\ncertification, but have purposely deferred this, stating that it is a\nprerogative of the foundation to accredit a certification program. \n\n \n\nI\'d like to propose that we form an OpenStack training / certification\ncommittee comprised of folks passionate about getting the formal training\nand certification program underway. \n\n \n\nNaturally, I volunteer to chair that committee and help spearhead the\ninitiative. I suppose Tristan and folks from RackSpace, Piston and Hastexo\n(who already run trainings) would make good committee members as well. We\ncan discuss the details during the upcoming board meeting on Monday.  \n\n \n\nWhat does everybody think? \n\n \n\nFrom: Lloyd Dewolf [mailto:lloydostack at gmail.com] \nSent: Thursday, October 11, 2012 2:58 PM\nTo: Tristan Goode\nCc: foundation at lists.openstack.org; foundation-board at lists.openstack.org\nSubject: [Foundation Board] OpenStack syllabi -was- Re: [OpenStack\nFoundation] Use of the word \"certified\" and protecting brand OpenStack\n\n \n\nOn Wed, Oct 10, 2012 at 2:42 PM, Tristan Goode <tristan at aptira.com> wrote:\n\n \n\nLeaving Rackspace\'s actions aside, I made a suggestion for a certification\nprocess for training materials and deliverables that they be offered to a\ncommunity sourced committee for review and approval. If this proposal is\naccepted then I would ask Rackspace that they offer up their course\nmaterials for this review, and that this might form a baseline for\nestablishing the certification benchmark.\n\n \n\nI\'m interested in collaborating on OpenStack course work.\n\n \n\nWe\'ve done training for our customers on Piston Enterprise OpenStack, and\nthe European participants particularly have wanted certification. I\'ve been\neager to work on this for many months. I\'ve just waiting for the Foundation\nto get it\'s legs under it.\n\n \n\nNear the start of my career I found the lpi.org first course and test helped\nboost my Linux skill set. The experience encouraged me to play a small role\nin the IBM team developing a version of the certification testing for IBM\nDB2 back in the day.\n\n \n\nI\'d like to contribute to developing common OpenStack syllabi.\n\n \n\n \n\nThank you,\n\n--\n@lloyddewolf\nhttp://www.pistoncloud.com/\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121012/ff52b524/attachment.html>\n\n','<CABN7HMJjViWQSr6ysg8C2Ev_2GC_AmMy=tYQzbWbkSBwr8Mstw@mail.gmail.com>',NULL),('<0114AC53-BA11-47E0-801E-882689B735AA@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 14:55:23',36000,'2013-06-17 04:55:23',NULL,'[openstack-dev] Cells design issue','I like the idea of JSON config for this too, but then again config groups maybe be better as it keeps all configuration together and in the same format. Operators would prefer that I\'d say.\n\nSam\n\n\nOn 15/06/2013, at 6:06 AM, Chris Behrens <cbehrens at codestud.com> wrote:\n\n> Are the group names programmatically computed/accessed?   Ie, do you do something like:  Figure out what plugins are loaded.  Then look at CONF.<plugin_name>.<variable> ?\n> \n> I still think maybe JSON is more what we need for cells? but just curious.\n> \n> On Jun 14, 2013, at 12:57 PM, Jeremy Hanmer <jeremy at dreamhost.com> wrote:\n> \n>> FWIW, this (config groups for each cell) sounds like how quantum\'s nicira plugin handles configuration of clusters and that has proven fairly easy to work with.\n>> \n>> \n>> On Fri, Jun 14, 2013 at 12:41 PM, Chris Behrens <cbehrens at codestud.com> wrote:\n>> \n>> On Jun 13, 2013, at 11:26 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>> \n>> > Is there any reason not to just put it in nova.conf as transport URLs?\n>> >\n>> > (By nova.conf, I mean cfg.CONF for nova which means you could happily do\n>> > e.g. --config-file nova-cells.conf too)\n>> \n>> The issue with using cfg.CONF is that we need the same config options for each cell.  So, I guess you\'d have to dynamically create the config groups with cell name as the group name? and have some sort of global option or an option in a different config group that specifies the list of cells.  I think it just gets kinda nasty.  But let me know if I\'m missing a good way to do it.  It seems like JSON is going to be a little more flexible. :)\n>> \n>> - Chris\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130617/2f8b3731/attachment.html>\n\n','<F20E9AC3-CBA7-4F0E-9ECB-80C9AAC4234B@codestud.com>',NULL),('<011601cf527d$f7a3f1e0$e6ebd5a0$@ltgfederal.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-07 12:25:18',-14400,'2014-04-07 16:25:18',NULL,'[Openstack] Using GlusterFS as backend for Glance','Does anyone has a particular recommendation on what is a best practice for\nimplementing Gluster as the Backend for Glance?\n\n \n\nThe docs allow Glance to be implemented on top of a filesystem, which could\nbe mounted directly to a Gluster mount. That is would be the base case.\n\nBut I also read some documents allowing Glance to be mounted on top of Swift\nor Cinder and here is where it gets tricky.\n\n \n\nShould I go with the default setting of having three different mount points\nin Gluster (/export/cinder, /export/swift, /export/glance) or shall I mount\nglance on top of Cinder or Swift and by doing this allowing additional\nfeatures like live migration or faster deployment of VM images?\n\nWhat are your recommendations for a production environment?\n\n\n\n\n \n\n-- \n\nIgnacio Bravo\n\nLTG Federal\n\nMb: 571.224.6046\n\n <mailto:roganc at ltgfederal.com> ibravo at ltgfederal.com\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140407/77581ec1/attachment.html>\n\n',NULL,NULL),('<011b01ccfe47$182da740$4888f5c0$@renski.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-09 14:50:56',-28800,'2012-03-09 22:50:56',NULL,'[OpenStack Foundation] Foundation Structure: An Alternative','While I like the simplicity and elegance of the newly proposed structure, I don?t see how it does away with the evils of the pay-to-play model?. Which is what you purport we are striving to achieve. What you, Josh, proposed is a simplified pay-to-play that arguably embraces the evils for the ?market driven selfishness? in an even more obvious way than the model before it. In your case, all the seats are simply purchased for a fixed price of $200K. \n\n \n\nIn my view the price tag for the sponsorship and the ultimate means for raising the money is not what drives OpenStack?s vendor independence principles. What matters the most is the degree of decoupling between the front-end, marketing  and the technical governance. Much of the OpenStack current momentum is due to this fairly unique way of doing open source where on one end you have an open, meritocracy-based technology community and, on the other ? structured commercial interest that evangelizes it. As long as the two sides remain sufficiently decoupled (as they have been so far) ? no OpenStack principles will be compromised. \n\n \n\nI think that the community needs to do away with this geek, open source mentality of ?all corporations are evil? and harness the value in strong commercial forces evangelizing and battling for the interest of the independent technology community. This is what got OpenStack to where it is now. So far the line between technology and marketing been well maintained. The bottom line is that a) technical committee must be elected and driven by meritocracy; b) foundation board should have virtually no influence (which is the case in the current structure) on the technical committee. Everything else is noise. \n\n \n\nOnce we accept this, the question of structuring the board really becomes the question of how does one raise the maximum amount of money to continue to have a centralized body with a mission to evangelize the project. You can structure it by tiers to let the bigger guys pay more and get a bigger logo on the homepage. You can do a flat structure like Josh proposed. You can auction off the board seats etc. \n\n \n\nThe one thing I would do away with is the ?elected board members? in favor of more associate member seats. This almost feels like a way to compensate the technology side for giving the marketing side leverage over the former. If we feel that this is necessary, it is a symptom of presence of technology-commercial coupling and we need to fix something else. All technical members should be elected based on merit. All board members ? appointed based on monetary/evangelism contribution. Decoupling between technology direction and purchasing power should be rock solid. \n\n \n\n-Boris \n\n \n\n \n\n \n\n \n\n \n\nFrom: foundation-bounces at lists.openstack.org [mailto:foundation-bounces at lists.openstack.org] On Behalf Of Joshua McKenty\nSent: Friday, March 09, 2012 11:20 AM\nTo: OpenStack; foundation at lists.openstack.org\nSubject: [OpenStack Foundation] Foundation Structure: An Alternative\n\n \n\nI\'ll be the first to admit that I\'m not a diplomatic person. When we were launching OpenStack, this was a bit of an advantage (if we had waited for permission before releasing the Nova source code, we\'d still be waiting) - but since the first summit, the community has grown so quickly, and become so diverse, that I have tried to leave discussions of governance, foundation structure, dispute resolution, and most particularly monetary corporate contributions, to others with more... tact.\n\n \n\nBut now I feel I have no choice but to speak up; I\'m deeply concerned.  \n\n \n\nThe biggest, splashiest openstack stories of the past two years have all had the names of huge, multi-national corporations in them - names like IBM, AT&T, Dell, HP, and CISCO. And while their participation has been tremendously positive for the project (with Quantum and Crowbar standing as examples of this), I see things trending in a direction that makes me nervous for the smaller players - for the startups who will live or die on the strength of the OpenStack project. Like Piston Cloud.\n\n \n\nThe current official proposal for the foundation creates a new class of super-members - with a sticker price of $2.5M (due up front) that puts it out of reach of all but a small handful of organizations. \n\n \n\nThis is not a new idea - it was the first structural proposal for the foundation that I heard from the organizing team, and I have argued against it (at times seemingly successfully) continuously since last fall.\n\n \n\nI understand why it is appealing; it creates a small and manageable board of directors, with a large pool of resources, who shouldn\'t have too much trouble guiding and directing the outcomes of OpenStack. But it\'s not a structure that represents or embodies the principles that OpenStack was founded upon, and I think that while it may offer some short-term benefits, it may be damaging to the long-term health of the project because it strangles the ecosystem of contributing companies we\'ve worked so hard to create. \n\n \n\nThe \"right\" structure is a much harder thing to organize:\n\n - It recognizes and requires project contribution (code, tests, docs, bugs and evangelism) along with cash\n\n - It has a single class of corporate member, a level playing field\n\n - It has room for non-corporate members in the meaningful governance bodies (not tucked away in \'advisory\' boards)\n\n - It aggressively and publicly resolves the conflict-of-interest between the \'company hat\' and the \'project hat\'\n\n \n\nMy understanding of the key challenges of this foundation board are the following:\n\n - Keep it small enough to be manageable (21 directors or less)\n\n - Supply enough funding to carry on with most of the current project support activities\n\n - Ensure representation of the diversity of the OpenStack community\n\n - Provide a mechanism for \"industry luminaries\" as well as OpenStack users and consumers to provide input and feedback\n\n \n\nThe target budget of the Foundation is around $3M per year. Without getting into a discussion about whether that\'s reasonable or not, I\'d like to brainstorm how we could reach that goal in a way that better reflects our goals for an open and democratic community. How\'s this for a proposal:\n\n \n\n - One class of corporate member\n\n - Provide reasonable evidence of 2 FTE (full time equivalents) working on OpenStack in some capacity\n\n - Commit to 2 years of sponsorship, on an evergreen basis, but paid annually\n\n - Individual members, if there are any, cannot be employed by a corporate member\n\n \n\nMy rough calculation, having a reasonably good grasp of the interests and level of engagement of the various corporations in the OpenStack ecosystem, is that we could expect around 15 of the 150 companies involved to meet these requirements. $3M divided by 15 = $200,000. \n\n \n\nIt\'s a high playing field, but at least it\'s a level one. It doesn\'t change the structure or composition of the technical committee, and it doesn\'t limit the ability of the foundation to raise money in other ways (sell sponsorships for events, charge admission for conferences, even license the use of the trademark for training or certification). \n\n \n\nIf we have a simple pay-to-play model, then we can trust market economics and enforce transparency of spending. If we have a simple \"meritocracy\", then we can expect the most skilled and dedicated to rise to the top, provided we\'re extremely careful about how we measure skill and dedication. If we blend the two, I\'m deeply concerned that we\'ll see the worst of both systems play out over time - the selfishness of market-driven economics dominating our decisions with the petulant moralism of the meritocracy. Hoping for any other outcome is, in my opinion, foolish optimism. \n\n \n\nAt the core of OpenStack is the idea that a single project could address the needs of ALL of our organizations - large, small, producers, consumers, non-profits and tool makers. We need to guard that vision, and protect it from our best intentions. No one in the community, whether individual contributor or corporate sponsor, can claim to speak for (or even understand the perspective of) the majority of us. We\'re simply too numerous, and too diverse. If you believe, as I do, that *your* company should have a stake in OpenStack\'s future, then now is the time to speak up in favor of the level playing field we originally set out to create. \n\n \n\nWith (attempted) diplomacy,\n\n \n\nJoshua\n\n \n\n--\n\nJoshua McKenty\n\nCo-Founder, OpenStack\n\nCEO, Piston Cloud Computing, Inc.\n\nw: (650) 24-CLOUD\n\nm: (650) 283-6846\nhttp://www.pistoncloud.com\n\n \n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20120309/c2f5ae3c/attachment-0001.html>\n\n','<6E2E53BEA1B048BA8B5A56B2814283DD@pistoncloud.com>',NULL),('<011cd0378165acc80e4c7dc5464caf5f@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-10 17:42:04',3600,'2014-03-10 16:42:04',NULL,'[Openstack-docs] Prompts conventions','Thank you all for the feedback!\n\nI\'ve updated the wiki and will get started on the \'conventions used in \nthis book\' part.\n\nGauvain\n\nObjectif Libre - Infrastructure et Formations Linux\nhttp://www.objectif-libre.com\n\nLe 2014-03-10 17:07, Gauvain Pocentek a ?crit?:\n> Hello,\n> \n> We have a lot of shell prompts in the documentation, and there\n> doesn\'t seem to be a convention defining in which case $ or # should\n> be used. We also have an inconsistent use of sudo.\n> \n> I\'d like to suggest the following convention:\n> \n> * use # for commands that *need* root privileges to work (*-manage,\n> mysqladmin, service...)\n> * use $ for commands that don\'t require root privileges (all the \n> clients)\n> * never use sudo\n> * add a \"Conventions used in this book\" section in all guides (as is\n> done in all the tech books I ever read) to explain what the prompts\n> actually mean:\n>   - # => you must be root or use sudo\n>   - $ => you can run the command as unprivileged user, but as root as \n> well\n> \n> I guess you can call this nitpicking but I\'ve seen a couple of users\n> confused in bug reports, and consistency is Good anyway :)\n> \n> Let me know what you think and if we agree on this (or an updated\n> proposal) I\'ll update the wiki and start working on this (might be a\n> simple way to get started for newcomers as well).\n> \n> Thanks,\n> Gauvain\n> \n> Objectif Libre - Infrastructure et Formations Linux\n> http://www.objectif-libre.com\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<61b7330d14f9f6ac8d914f0c5a1c4ef2@objectif-libre.com>',NULL),('<012601cf21ee$9e497120$dadc5360$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-02-04 13:18:12',-28800,'2014-02-04 21:18:12',NULL,'[openstack-community] OpenStack Northwest User Group Meetup this\n	Wed Feb 5 in Portland','OpenStack Northwest User Group Meetup in Portland\n\nWednesday Feb 5, 2014 @ 6:00PM PDT\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nDon\'t miss this exciting OSNW event...\n\nHere in Portland, you can now get the best of both Clouds! The OpenStack NW\nteam worked with AWS meetup organizers to provide the best value to the\nPortland Cloud community; we agreed to line both events in close proximity\nallowing you to head straight to Jama Software South facility at 6:00pm,\nimmediately after attending AWS meetup which starts at 4:00pm.\n\nThis would make for a very exciting and super rich Wednesday night, why?\nBecause we have Cameron Seader flying over to share the latest in SUSE Cloud\nthen.\n\nWe\'re bringing the latest OpenStack projects directly from Yahoo\'s building\nC in the Silicon Valley as we join the SFBay OpenStack meetup over live\ntwo-way video link.\n\nAnd for some fun time, our sponsor ProFocus is giving away a Kindle for the\nfirst correct answer of a quiz question from one of the presentations.\n\nOn the agenda:\n\n6:00 - 6:15 Introduction, pizza and beer (RSVP - Please!)\n\n6:15 - 7:00 SUSE Cloud-\n\nOpenStack Heat provides a framework for predefining a structured service,\nand allows you to instantiate that service in an automated manner. Walk\nthrough the process of creating a Heat template for a multi-tiered web\napplication that will include multiple image templates, custom networking,\nand volume storage.\n\n7:00 - 8:30 SFBay Simulcast - Projects Murano and Mistral\n\nOne of the fastest growing parts of OpenStack for the last release cycle is\norchestration and platform-level capabilities. Different aspects of\norchestration are represented by a number of the initiatives. During this\nsession Mirantis engineers will talk about two projects from orchestration\narea which were initiated by Mirantis - Murano and Mistral.\n\nMurano is a project which brings Application Catalog features to OpenStack\ncloud. Application Catalog provides an integration layer for 3rd party\napplications to be deployed via self-service UI for OpenStack cloud. The\ndiscussion, driven by Alex Tivelkov - a Murano technical lead, will cover\nApplication Catalog use cases and their value for cloud users. Some of the\nuse cases will be illustrated during the live demo followed by roadmap\noverview and Q&A.\n\nAs the second part of this meetup Mistral project will be presented. Mistral\nis a new initiative for workflow as a service implementation announced at\nthe latest OpenStack summit in HK. Workflow as a service provides an ability\nto execute tasks in a distributed manner defined by simple DSL instead of\nwriting a python code. Mistral provides features like event triggered tasks,\nscheduled tasks as a part of DSL. Renat Akhmerov - a Mistral technical lead\nwill cover Mistral use cases, architecture overview and live demo for\nMistral PoC followed by roadmap discussion and Q&A.\n\nAt the end of the meetup there will be a general Q&A session about\nintegration between new and existing OpenStack services including Heat,\nTrove, Murano, Savanna and Mistral.\n\nSpecial thanks to our sponsors SUSE Linux, Jama Software and ProFocus.\n\nHope to see you there.\n\nhttp://www.meetup.com/OpenStack-Northwest/\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140204/b9adccec/attachment.html>\n\n',NULL,NULL),('<012601cf21ee$9e497120$dadc5360$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-04 13:18:12',-28800,'2014-02-04 21:18:12',NULL,'[Openstack] OpenStack Northwest User Group Meetup this Wed Feb 5 in\n	Portland','OpenStack Northwest User Group Meetup in Portland\n\nWednesday Feb 5, 2014 @ 6:00PM PDT\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nDon\'t miss this exciting OSNW event...\n\nHere in Portland, you can now get the best of both Clouds! The OpenStack NW\nteam worked with AWS meetup organizers to provide the best value to the\nPortland Cloud community; we agreed to line both events in close proximity\nallowing you to head straight to Jama Software South facility at 6:00pm,\nimmediately after attending AWS meetup which starts at 4:00pm.\n\nThis would make for a very exciting and super rich Wednesday night, why?\nBecause we have Cameron Seader flying over to share the latest in SUSE Cloud\nthen.\n\nWe\'re bringing the latest OpenStack projects directly from Yahoo\'s building\nC in the Silicon Valley as we join the SFBay OpenStack meetup over live\ntwo-way video link.\n\nAnd for some fun time, our sponsor ProFocus is giving away a Kindle for the\nfirst correct answer of a quiz question from one of the presentations.\n\nOn the agenda:\n\n6:00 - 6:15 Introduction, pizza and beer (RSVP - Please!)\n\n6:15 - 7:00 SUSE Cloud-\n\nOpenStack Heat provides a framework for predefining a structured service,\nand allows you to instantiate that service in an automated manner. Walk\nthrough the process of creating a Heat template for a multi-tiered web\napplication that will include multiple image templates, custom networking,\nand volume storage.\n\n7:00 - 8:30 SFBay Simulcast - Projects Murano and Mistral\n\nOne of the fastest growing parts of OpenStack for the last release cycle is\norchestration and platform-level capabilities. Different aspects of\norchestration are represented by a number of the initiatives. During this\nsession Mirantis engineers will talk about two projects from orchestration\narea which were initiated by Mirantis - Murano and Mistral.\n\nMurano is a project which brings Application Catalog features to OpenStack\ncloud. Application Catalog provides an integration layer for 3rd party\napplications to be deployed via self-service UI for OpenStack cloud. The\ndiscussion, driven by Alex Tivelkov - a Murano technical lead, will cover\nApplication Catalog use cases and their value for cloud users. Some of the\nuse cases will be illustrated during the live demo followed by roadmap\noverview and Q&A.\n\nAs the second part of this meetup Mistral project will be presented. Mistral\nis a new initiative for workflow as a service implementation announced at\nthe latest OpenStack summit in HK. Workflow as a service provides an ability\nto execute tasks in a distributed manner defined by simple DSL instead of\nwriting a python code. Mistral provides features like event triggered tasks,\nscheduled tasks as a part of DSL. Renat Akhmerov - a Mistral technical lead\nwill cover Mistral use cases, architecture overview and live demo for\nMistral PoC followed by roadmap discussion and Q&A.\n\nAt the end of the meetup there will be a general Q&A session about\nintegration between new and existing OpenStack services including Heat,\nTrove, Murano, Savanna and Mistral.\n\nSpecial thanks to our sponsors SUSE Linux, Jama Software and ProFocus.\n\nHope to see you there.\n\nhttp://www.meetup.com/OpenStack-Northwest/\n\nFollow @DetaCloud and #OSNW on Twitter for livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140204/b9adccec/attachment.html>\n\n',NULL,NULL),('<012c414b78320ed31b1a264b02845029@secure.spamaps.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-03 22:19:48',-25200,'2013-04-04 05:19:48',NULL,'[openstack-dev] Rackspace Plans Contributions to HEAT','On 2013-04-03 20:17, Alan Kavanagh wrote:\n> This is good news I have to say. Though I have some questions that\n> got me irked in reading bullet 4 below on Auto-Scale so im going to\n> throw this out for discussion.\n> \n> Are we now stating that the HEAT will take care of Auto-Scaling of\n> all Openstack Services? If you consider network services managed and\n> deployed under Quantum, and if you have Ceilometer collecting event\n> notifications then some given \"policy engine\" would know when to call\n> Quantum & || Nova + etc to provision additional resources as needed,\n> you do not need to go through HEAT for this. I do see cases where an\n> application that is deployed via HEAT would make sense, but for\n> services that are inherent and part of the Infrastructure such as LB\n> or FW etc I do not see what HEAT would need to handle the scaling for\n> these services?\n> \n\nIf you look past the current implementation details, and think of Heat \ninstead as a way to manage multi-resource relationships, then it makes \nperfect sense for Heat to implement that policy engine. In fact, it \nalready has done some of this.\n\nBasically, Heat only has one way to define the necessary policies right \nnow, which is a declarative templating system.\n\nHowever, an API for defining the very same policies in an imperative \nfashion should be really simple to create.\n\n> Agree that Event Trigger and Notification Events must be added to LB\n> in order for this to Scale accordingly, I am sure this will come soon\n> ;-) in the LBaaS API.\n> \n\nI am somewhat confused by this. I\'d like to see auto-scaling separated \ninto its own concern. LBaaS is not the only thing that needs to change \nin response to data / config changes.\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E092E3B@eusaamb109.ericsson.se>',NULL),('<012f01ce8f1f$91c57c80$b5507580$@mxs.nes.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 10:28:18',32400,'2013-08-02 01:28:18',NULL,'[openstack-dev] [Nova] Review request: Blurprint of API\n	validation','\nHi Russell,\n\nI have assigned you as the approver of bp \"nova-api-validation-fw\",\nplease approve it or give some comments.\n  https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw\n\nThe implementation of core part is almost complete.\nnow waiting for blueprint approval.\n  https://review.openstack.org/#/c/25358/\n\n\nThanks,\nKen\'ichi Ohmichi\n\n---\nOn Tue, 16 Jul 2013 13:37:15 +0900\n\"Ken\'ichi Ohmichi\" <oomichi at mxs.nes.nec.co.jp> wrote:\n> \n> Hi Russell,\n> \n> I assigned you as the approver of bp \"nova-api-validation-fw\",\n> so could you take a look at this bp?\n> \n> You have changed the priority from Medium to Low these days.\n> Could you show your concerns about this bp if you have.\n> \n> \n> Thanks\n> Ken\'ichi Ohmichi\n> \n> ---\n> On Tue, 9 Jul 2013 20:45:57 +0900\n> \"Ken\'ichi Ohmichi\" <oomichi at mxs.nes.nec.co.jp> wrote:\n> > \n> > Hi,\n> > \n> > The blueprint \"nova-api-validation-fw\" has not been approved yet.\n> > I hope the core patch of this blueprint is merged to Havana-2,\n> > because of completing comprehensive API validation of Nova v3 API\n> > for Havana release. What should we do for it?\n> > \n> > \n> > The summary of \"nova-api-validation-fw\":\n> >   * The patch review is in good progress.\n> >   * \"nova-api-validation-fw\" is API input validation framework.\n> >   * Simplify the code in the extensions of Nova v3 API.\n> >   * Define API schema with JSON Schema.\n> >   * Define common data formats to standardize whole of Nova v3 API.\n> >   * Possible to choose APIs which are applied with this framework.\n> >   * Possible to migrate other web framework.\n> > \n> > \n> > The details of \"nova-api-validation-fw\" are the following:\n> > \n> > * The patch review is in good progress.\n> >   7 reviewers have marked +1 now.\n> >   We are waiting for the approval of this blueprint before merging the\n> >   patch. (https://review.openstack.org/#/c/25358/)\n> > \n> > * \"nova-api-validation-fw\" is API input validation framework.\n> >   This framework validates API parameters in a request body before the\n> >   execution of API method. If the parameter is invalid, nova-api returns\n> >   a BadRequest response including its reason.  \n> > \n> > * Simplify the code in the extensions of Nova v3 API.\n> >   There are a lot of validation code in each API method.\n> >   After applying this framework, we will be able to separate them from\n> >   API methods by defining API schema. That makes the code more readable.\n> >   Also through trying to define API schema of each API, we will find the\n> >   lacks of validation code and complement them for better v3 API.\n> >   Necessary API schemas are for API which contains a request body. They\n> >   are 37 APIs on Nova v3 API now, and they will increase later because\n> >   the tasks, which port v2 API to v3 API, is in progress.\n> > \n> > * Define API schema with JSON Schema.\n> >   JSON Schema contains many features for validation, the details are\n> >   written on http://json-schema.org/.\n> >   Here is the schema of v3 keypairs API as a sample:\n> >   == Request body sample of keypairs API ===============\n> >   {\n> >     \"keypair\": {\n> >         \"name\": \"keypair-dab428fe-6186-4a14-b3de-92131f76cd39\",\n> >         \"public_key\": \"ssh-rsa AAAAB3NzaC1yc2EA[..]== Generated by Nova\"\n> >   }\n> >   == API schema of keypairs API ========================\n> >   {\n> >       \'type\': \'object\',\n> >       \'properties\': {\n> >           \'keypair\': {\n> >               \'type\': \'object\',\n> >               \'properties\': {\n> >                   \'name\': {\'type\': \'string\', \'minLength\': 1, \'maxLength\': 255},\n> >                   \'public_key\': {\'type\': \'string\'},\n> >               },\n> >               \'required\': [\'name\'],\n> >           },\n> >       },\n> >       \'required\': [\'keypair\'],\n> >   }\n> > \n> > * Define common data formats to standardize whole of Nova v3 API.\n> >   We can define common data formats with FormatChecker of JSON Schema\n> >   library.\n> > \n> >   e.g. Data format of \'boolean\':\n> >     @jsonschema.FormatChecker.cls_checks(\'boolean\')\n> >     def validate_boolean_format(instance):\n> >         return instance.upper() == \'TRUE\' or instance.upper() == \'FALSE\'\n> > \n> >   The formats can be used in API schema:\n> >     \'onSharedStorage\': {\n> >         \'type\': \'string\', \'format\': \'boolean\',\n> >     },\n> > \n> >   By re-using these common formats in many API schemas, that will be\n> >   able to standardize whole of Nova v3 API.\n> > \n> > * Possible to choose APIs which are applied with this framework.\n> >   We can apply this framework to Nova v3 API only, the existing API (v2) can\n> >   be out of scope of this framework.\n> > \n> > * Possible to migrate other web framework.\n> >   The API validation of this framework is executed with the decorator of API\n> >   method, that means this framework does not depend on web framework.\n> >   Also when migrating other web framework(e.g. Pecan/WSME) in the future, we\n> >   will be able to use this framework.\n> > \n> > \n> > Thanks\n> > Ken\'ichi Ohmichi\n> > \n> > ---\n> > On Fri, 5 Jul 2013 16:27:39 +0900\n> > \"Ken\'ichi Ohmichi\" <oomichi at mxs.nes.nec.co.jp> wrote:\n> > > \n> > > Hi,\n> > > \n> > > I have submitted a blueprint[1] and a patch[2] for Nova API validation.\n> > > I request someone to review the blueprint and hopefully approve it.\n> > > \n> > > This blueprint was approved once, but the Definition has been changed to\n> > > Discussion because we discussed what is better validation mechanism \"WSME\n> > > original validation or JSON Schema\". IIUC, we have found the advantages\n> > > of JSON Schema through the discussion. [3]\n> > > \n> > > Also we have found the way to overlap JSON Schema with WSME, so we will\n> > > be able to use JSON Schema also when the web framework of Nova is changed\n> > > to WSME. [4]\n> > > \n> > > My latest patch has been implemented with JSON Schema[2], and I think API\n> > > validation with JSON Schema is useful for Nova v3 API, because the API has\n> > > complex API parameters and JSON Schema can check complex parameters naturally. \n> > > \n> > > \n> > > Any comments are welcome :-)\n> > > \n> > > [1]: https://blueprints.launchpad.net/openstack/?searchtext=nova-api-validation-fw\n> > > [2]: https://review.openstack.org/#/c/25358/\n> > > [3]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html\n> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009926.html\n> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009937.html\n> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009970.html\n> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/010057.html\n> > > [4]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010814.html\n> > > \n> > > \n> > > Thanks\n> > > Ken\'ichi Ohmichi\n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n',NULL,NULL),('<013556F3-0FA4-4BA2-A533-FF3BF7E52C34@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-10 11:28:40',-14400,'2013-05-10 15:28:40',NULL,'[openstack-dev] [quantum] multi-node DevStack with bare-metal\n	questions on setup','HI,\n\nFor testing, I wanted to setup DevStack on two nodes (one control/network, one compute) using bare-metal running Ubuntu 12.04 and using quantum networking (this is with Grizzly).\n\nThe H/W (HP Pro Liant) has two physical interfaces. I had a bunch of questions on how to set up the localrc, physical interfaces, and OVS.\n\nIf I make these assumptions:\n\nprivate network 10.0.0.0/24\nadmin network 192.168.220.0/24\npublic network 192.168.221.0/24\n\n\nQ1) Is it best to have admin network on eth0 and both data and public on eth1?\nQ2) Should I use VLANs or tunnels (or doesn\'t it matter)?\nQ3) Do I create a br-int and br-ex for the data network for the two nodes?\nQ4) Do I need to create a bridge and port for the public net, on the control/network node?\nQ5) How do I configure /etc/network/interfaces for the public network?\nQ6) What do I need to specify in localrc for OVS settings?\n\n\nThanks in advance!\n\nPCM (Paul Michali)\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/2e44b8ce/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130510/2e44b8ce/attachment.pgp>\n\n',NULL,NULL),('<0137CFA9-170C-4C85-BFB4-80C62FC8E4C1@zeroaccess.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-09 08:53:22',-21600,'2011-11-09 14:53:22',NULL,'[Openstack-operators] Problem send HTTP GET request.','\nHi Salman,\n\nMy first suggestion is use curl .. I assume you are using telnet here. If you are using telnet and still want to try things out with it, you should be passing the \"X-Auth-Token\" header and not the \"Authorization\" .\n\nExample:\n================================\nroot at saio-2:~# telnet 127.0.0.1 8080\nTrying 127.0.0.1...\nConnected to 127.0.0.1.\nEscape character is \'^]\'.\nGET /v1/AUTH_100d771c-d41e-4614-8370-8848e63a7b1b\nHost: 127.0.0.1:8080\nX-Auth-Token: AUTH_tk03eebc77f9d4432cbc223f08f4b24cf5\n\nHTTP/1.1 200 OK\nX-Account-Object-Count: 0\nX-Account-Bytes-Used: 0\nX-Account-Container-Count: 1\nAccept-Ranges: bytes\nContent-Length: 8\nContent-Type: text/plain; charset=utf-8\nX-Trans-Id: tx7d2415d0e2dd4bd8ba8adaadb8d3deef\nDate: Wed, 09 Nov 2011 14:46:20 GMT\nConnection: close\n\ntest900\nConnection closed by foreign host.\n================================\n\nAlso the Bexar docs are pretty old, if you are using 1.4.X check out http://docs.openstack.org/diablo/openstack-object-storage/admin/content/\n\n\n\n\n\nMarcelo Martins\nOpenstack-swift\nbtorch-os at zeroaccess.org\n\n?Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. ?\n\n\n\n\nOn Nov 9, 2011, at 6:13 AM, Salman Zubair Toor wrote:\n\n> Hi, \n> \n> I am trying to get the object from Swift store using GET request header but facing some problem, \n> \n> I read from the following document \n> \n> http://docs.openstack.org/bexar/openstack-object-storage/developer/content/ch03s03.html\n> \n> That the header should look like this \n> \n> GET /<api version>/<account>/<container>/<object> HTTP/1.1\n>   Host: storage.swiftdrive.com\n>   X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb\n> \n> I did the same and make my GET request something like this\n>  \n> ----------------------------------------------------------------------------------\n> GET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1 \n> Host: swift.uppmax.se\n> Authorization: AWS system:root:VTbBHyLrCdLnxClvd1bVFZcLpy8=\n> \n> ----------------------------------------------------------------------------------\n> \n> Not that the last line is empty right after the Authentication. But it just hangs. no answer form the server. I try to change the header to get it working but no success :-( . Try-4 is interesting. \n> \n> Following are my tries.. \n> \n> Try -1\n> \n> ----------------------------------------------------------------------------------\n> GET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1 \n> Host: swift.uppmax.se\n> Authorization: AWS system:root:yR7OHVFGgsZ4xHJp7RKHv9CuNtY=\n> \n> \n> ----------------------------------------------------------------------------------\n> Now two empty line in the end. and I got the following response. \n> \n> HTTP/1.1 403 Forbidden\n> Content-Type: text/xml; charset=UTF-8\n> Content-Length: 124\n> Date: Wed, 09 Nov 2011 11:47:47 GMT\n> \n> \n> Try-2 \n> \n> ----------------------------------------------------------------------------------\n> GET /v1.0/root/rootContainer/eventdata.root HTTP/1.1 \n> Host: swift.uppmax.se\n> Authorization: AWS system:root:R9She9vkYVXQszVMfDqaeTNtUhQ=\n> \n> ----------------------------------------------------------------------------------\n> change account from system:root to root (I don\'t know why but just want to try) .... \n> \n> HTTP/1.1 403 Forbidden\n> Content-Type: text/xml; charset=UTF-8\n> Content-Length: 124\n> Date: Wed, 09 Nov 2011 11:47:47 GMT\n> \n> \n> Try-3 \n> \n> ----------------------------------------------------------------------------------\n> GET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1 \n> Host: swift.uppmax.se\n> Date: Wed, 09 Nov 2011 12:03:06 GMT\n> Range: bytes=0-3\n> Authorization: AWS system:root:pHhOqVriW4zNmBW9MO1a7rNhHjI=\n> \n> \n> ----------------------------------------------------------------------------------\n> \n> HTTP/1.1 403 Forbidden\n> Content-Type: text/xml; charset=UTF-8\n> Content-Length: 124\n> Date: Wed, 09 Nov 2011 11:47:47 GMT\n> \n> \n> Try-4\n> \n> ----------------------------------------------------------------------------------\n> GET /rootContainer/eventdata.root HTTP/1.1 \n> Host: swift.uppmax.se\n> Date: Wed, 09 Nov 2011 12:04:57 GMT\n> Range: bytes=0-3\n> Authorization: AWS system:root:oQX68HKwnH1OnBJhTmHGz3cm4b4=\n> \n> \n> ----------------------------------------------------------------------------------\n> I have removed the version and the account details  and then at least the request message get changed. No more forbidden response. But now its \"206 Partial Content\" and after getting the headers  the read bytes are 0.  \n> \n> \n> HTTP/1.1 206 Partial Content\n> n: 44\n> line: Last-Modified: Tue, 01 Nov 2011 16:13:21 GMT\n> n: 17\n> line: Content-Length: 4\n> n: 38\n> line: Etag: f3e0c75e57766c5581a6978e2b70698f\n> n: 38\n> line: Content-Type: application/octet-stream\n> n: 35\n> line: Date: Wed, 09 Nov 2011 12:01:30 GMT\n> n: 0\n> line: \n> n: 4\n> line: root\n> n: 0\n> line: \n> \n> Then I send only HEAD request without version and account and that runs successfully\n> \n> ------------------------------------------------------------------------------------------\n> HEAD /rootContainer/eventdata.root HTTP/1.1\n> Host: swift.uppmax.se\n> Date: Wed, 09 Nov 2011 12:14:11 GMT\n> Authorization: AWS system:root:dAWDu4I8SJyY02HEIirYejDWn2w=\n> \n> \n> ------------------------------------------------------------------------------------------\n> \n> gDebug Header: HTTP/1.1 200 OK\n> gDebug Header: Last-Modified: Tue, 01 Nov 2011 16:13:21 GMT\n> gDebug Header: Content-Length: 13\n> gDebug Header: Etag: f3e0c75e57766c5581a6978e2b70698f\n> gDebug Header: Content-Type: text/plain\n> gDebug Header: Date: Wed, 09 Nov 2011 12:10:45 GMT\n> \n> \n> \n> If I use command line tool everything is working fine. Can someone please point out what is wrong or how should I modify things. \n> \n> Thanks. \n> \n> \n> Salman Zubair Toor\n> Ph.Lic. Scientific Computing\n> Ph.D candidate\n> Division of Scientific Computing \n> Uppsala University, Sweden \n> salman.toor at it.uu.se\n> \n> \n> \n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111109/f4cc3d32/attachment-0001.html>\n\n','<1467F3A7-04BA-445B-A2BE-9799D2EA2990@it.uu.se>',NULL),('<013854FB-50DC-4070-A5A5-7E29FC8FAF63@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-08 11:22:47',39600,'2015-01-08 00:22:47',NULL,'[Openstack] [nova] running icehouse computes under juno','Hi Joe,\n\nI?ve managed to track this down. When Juno conductor sends back the service object, it also has an embedded compute node object. \nThis compute node object is too new for Icehouse and so it attempts to back port it.\n\nHowever for some reason instead of asking to back port the compute node object it tries to back port the service object again at the intended compute node version.\nThis is where the loop is. There must be a bug when trying to back port embedded objects.\n\n\n\nThe fix is quite simple if you are using plain juno and icehouse as there is a bug in the service object [0], it has a check when back porting the service and downgrading the compute node but it changes it to the wrong version.\n\nThere is also a bug in the fixed_ip object with the embedded network object which means deletes don?t work. [1]\n\nI have a fix for that too, looking at master the code around this has changed a lot so I don?t know if this has been fixed here.\nI?m wondering if my patches can be applied straight to Juno? [2],[3]\n\nCheers,\nSam\n\n\n[0] https://bugs.launchpad.net/nova/+bug/1408496 <https://bugs.launchpad.net/nova/+bug/1408496>\n[1] https://bugs.launchpad.net/nova/+bug/1408498\n[2] https://github.com/NeCTAR-RC/nova/commit/5c9b340b391cdbb8e3a97fc01258e59b827cb2a9\n[3] https://github.com/NeCTAR-RC/nova/commit/cc20ae961578ede313add592ba81b215e9791816\n\n\n\n> On 8 Jan 2015, at 4:47 am, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> \n> \n> \n> On Tue, Jan 6, 2015 at 5:12 PM, Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:\n> I?m working on upgrading our nova to Juno.\n> \n> First I upgrade the control infrastructure, conductor,api,scheduler etc. and migrate the DB\n> I also set the following on the control hosts\n> [upgrade_levels]\n> compute=icehouse\n> \n> I don?t touch the nodes running nova-compute.\n> \n> Things seem to work however when I start a nova-compute I get the following when it registers its service:\n> \n> Are you restarting existing icehouse nova-compute and not juno?\n> \n> Can you share sanitized copies of your config file as not sure what the issue is based on the stacktrace alone.\n>  \n> \n> Line in question:\n> nova/virt/libvirt/driver.py\n> def _set_host_enabled()\n> service = service_obj.Service.get_by_compute_host(ctx, CONF.host)\n> \n> \n> 2015-01-07 12:06:51.377 26596 <tel:51.377%2026596> TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\", line 155, in call\n> 2015-01-07 12:06:51.377 26596 <tel:51.377%2026596> TRACE nova.virt.libvirt.driver     return self.serializer.deserialize_entity(ctxt, result)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/rpc.py\", line 111, in deserialize_entity\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return self._base.deserialize_entity(context, entity)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/objects/base.py\", line 575, in deserialize_entity\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     entity = self._process_object(context, entity)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/objects/base.py\", line 545, in _process_object\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     e.kwargs[\'supported\'])\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/conductor/api.py\", line 280, in object_backport\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return self._manager.object_backport(context, objinst, target_version)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/conductor/rpcapi.py\", line 435, in object_backport\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     target_version=target_version)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\", line 155, in call\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return self.serializer.deserialize_entity(ctxt, result)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/rpc.py\", line 111, in deserialize_entity\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return self._base.deserialize_entity(context, entity)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/objects/base.py\", line 575, in deserialize_entity\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     entity = self._process_object(context, entity)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/objects/base.py\", line 545, in _process_object\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     e.kwargs[\'supported\'])\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/conductor/api.py\", line 280, in object_backport\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return self._manager.object_backport(context, objinst, target_version)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/nova/nova/conductor/rpcapi.py\", line 435, in object_backport\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     target_version=target_version)\n> ?. REPEATED?.\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\", line 152, in call\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     retry=self.retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/transport.py\", line 90, in _send\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     timeout=timeout, retry=retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 436, in send\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     retry=retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 422, in _send\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     retry=retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 746, in topic_send\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     exchange_name=exchange_name, retry=retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 717, in publisher_send\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.ensure(_error_callback, _publish, retry=retry)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 617, in ensure\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     ret, channel = autoretry_method()\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/connection.py\", line 436, in _ensured\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return fun(*args, **kwargs)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/connection.py\", line 508, in __call__\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     return fun(*args, channel=channels[0], **kwargs), channels[0]\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 714, in _publish\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     publisher = cls(self.conf, channel, topic=topic, **kwargs)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 381, in __init__\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     **options)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 329, in __init__\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.reconnect(channel)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/oslo/messaging/_drivers/impl_rabbit.py\", line 337, in reconnect\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     routing_key=self.routing_key)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/messaging.py\", line 85, in __init__\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.revive(self._channel)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/messaging.py\", line 218, in revive\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.declare()\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/messaging.py\", line 105, in declare\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.exchange.declare()\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/kombu/entity.py\", line 166, in declare\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     nowait=nowait, passive=passive,\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/amqp/channel.py\", line 620, in exchange_declare\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     (40, 11),  # Channel.exchange_declare_ok\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/amqp/abstract_channel.py\", line 67, in wait\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.channel_id, allowed_methods)\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/amqp/connection.py\", line 240, in _wait_method\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     self.method_reader.read_method()\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver   File \"/opt/icehouse/local/lib/python2.7/site-packages/amqp/method_framing.py\", line 189, in read_method\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver     raise m\n> 2015-01-07 12:06:51.377 26596 TRACE nova.virt.libvirt.driver RuntimeError: maximum recursion depth exceeded while calling a Python object\n> \n> \n> In conductor I see the following (after adding a debug log message):\n> 2015-01-07 12:06:50.860 9781 DEBUG nova.conductor.manager [req-2fffdbd0-fbcd-426d-adc5-9f02e1104652 None] Call to backport Service(availability_zone=<?>,binary=\'nova-compute\',compute_node=ComputeNode(2),created_at=2015-01-06T03:33:50Z,deleted=False,deleted_at=None,disabled=False,disabled_reason=None,host=\'nova-compute-i2\',id=8,report_count=6911,topic=\'compute\',updated_at=2015-01-07T01:06:10Z), target_version=1.2 object_backport /opt/juno/local/lib/python2.7/site-packages/nova/conductor/manager.py:439\n> 2015-01-07 12:06:50.889 9781 DEBUG nova.conductor.manager [req-2fffdbd0-fbcd-426d-adc5-9f02e1104652 None] Call to backport Service(availability_zone=<?>,binary=\'nova-compute\',compute_node=ComputeNode(2),created_at=2015-01-06T03:33:50Z,deleted=False,deleted_at=None,disabled=False,disabled_reason=None,host=\'nova-compute-i2\',id=8,report_count=6911,topic=\'compute\',updated_at=2015-01-07T01:06:10Z), target_version=1.3 object_backport /opt/juno/local/lib/python2.7/site-packages/nova/conductor/manager.py:439\n> 2015-01-07 12:06:50.914 9781 DEBUG nova.conductor.manager [req-2fffdbd0-fbcd-426d-adc5-9f02e1104652 None] Call to backport Service(availability_zone=<?>,binary=\'nova-compute\',compute_node=ComputeNode(2),created_at=2015-01-06T03:33:50Z,deleted=False,deleted_at=None,disabled=False,disabled_reason=None,host=\'nova-compute-i2\',id=8,report_count=6911,topic=\'compute\',updated_at=2015-01-07T01:06:10Z), target_version=1.2 object_backport /opt/juno/local/lib/python2.7/site-packages/nova/conductor/manager.py:439\n> 2015-01-07 12:06:50.937 9781 DEBUG nova.conductor.manager [req-2fffdbd0-fbcd-426d-adc5-9f02e1104652 None] Call to backport Service(availability_zone=<?>,binary=\'nova-compute\',compute_node=ComputeNode(2),created_at=2015-01-06T03:33:50Z,deleted=False,deleted_at=None,disabled=False,disabled_reason=None,host=\'nova-compute-i2\',id=8,report_count=6911,topic=\'compute\',updated_at=2015-01-07T01:06:10Z), target_version=1.3 object_backport /opt/juno/local/lib/python2.7/site-packages/nova/conductor/manager.py:439\n> (repeats a bunch more times)\n> \n> What I can?t figure out is why it?s asking for a target version of 1.3, icehouse service object is 1.2 and juno service object is 1.4\n> \n> Anyone come across this?\n> \n> We haven\'t seen this in any other bug reports or in our automated testing.\n>  \n> \n> Cheers,\n> Sam\n> \n> \n> \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>\n> Post to     : openstack at lists.openstack.org <mailto:openstack at lists.openstack.org>\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150108/52d30385/attachment.html>\n\n','<CAHXdxOerpHRr+tgzhyEa+NVwpm68bv7zfFe7-Men1PUiRRd5dg@mail.gmail.com>',NULL),('<013901cff283$c00a45d0$401ed170$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-28 14:49:46',25200,'2014-10-28 07:49:46',NULL,'[Openstack] No metadata with the second dhcp agent','Hello,\n\n \n\nFor high availability we added a second dhcp agent (on one of the compute\nnodes). New spawned instances get their IPs through this agent but the\nmetadata is not working. In the instance bootup I can see they get an error\n500.  \n\nThrough the first dhcp agent on the network node the metadata for the\ninstances works fine. Did I miss something?\n\n \n\nThanks!\n\n \n\nGreetings \n\nChris\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141028/a7507e93/attachment.html>\n\n',NULL,NULL),('<013d01cda88d$6de239d0$49a6ad70$@renski.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-12 08:22:42',-25200,'2012-10-12 15:22:42',NULL,'[OpenStack Foundation] [Foundation Board] OpenStack syllabi\n	-was- Re: Use of the word \"certified\" and protecting brand OpenStack','I second Lloyd\'s comment. We\'ve been running a very popular OpenStack\nBootcamp program and have delivered 20+ private and public OpenStack classes\nduring the last 6 months. We\'ve been asked on many occasions about OpenStack\ncertification, but have purposely deferred this, stating that it is a\nprerogative of the foundation to accredit a certification program. \n\n \n\nI\'d like to propose that we form an OpenStack training / certification\ncommittee comprised of folks passionate about getting the formal training\nand certification program underway. \n\n \n\nNaturally, I volunteer to chair that committee and help spearhead the\ninitiative. I suppose Tristan and folks from RackSpace, Piston and Hastexo\n(who already run trainings) would make good committee members as well. We\ncan discuss the details during the upcoming board meeting on Monday.  \n\n \n\nWhat does everybody think? \n\n \n\nFrom: Lloyd Dewolf [mailto:lloydostack at gmail.com] \nSent: Thursday, October 11, 2012 2:58 PM\nTo: Tristan Goode\nCc: foundation at lists.openstack.org; foundation-board at lists.openstack.org\nSubject: [Foundation Board] OpenStack syllabi -was- Re: [OpenStack\nFoundation] Use of the word \"certified\" and protecting brand OpenStack\n\n \n\nOn Wed, Oct 10, 2012 at 2:42 PM, Tristan Goode <tristan at aptira.com> wrote:\n\n \n\nLeaving Rackspace\'s actions aside, I made a suggestion for a certification\nprocess for training materials and deliverables that they be offered to a\ncommunity sourced committee for review and approval. If this proposal is\naccepted then I would ask Rackspace that they offer up their course\nmaterials for this review, and that this might form a baseline for\nestablishing the certification benchmark.\n\n \n\nI\'m interested in collaborating on OpenStack course work.\n\n \n\nWe\'ve done training for our customers on Piston Enterprise OpenStack, and\nthe European participants particularly have wanted certification. I\'ve been\neager to work on this for many months. I\'ve just waiting for the Foundation\nto get it\'s legs under it.\n\n \n\nNear the start of my career I found the lpi.org first course and test helped\nboost my Linux skill set. The experience encouraged me to play a small role\nin the IBM team developing a version of the certification testing for IBM\nDB2 back in the day.\n\n \n\nI\'d like to contribute to developing common OpenStack syllabi.\n\n \n\n \n\nThank you,\n\n--\n@lloyddewolf\nhttp://www.pistoncloud.com/\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121012/b30cc456/attachment.html>\n\n',NULL,NULL),('<0145D5DF1C56174FABB6EB834BC4909C03FEBD1915A9@NML2007.netmedia.kjist.ac.kr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-14 15:21:02',32400,'2014-08-14 06:21:02',NULL,'[Openstack-operators] Neutron: Why OVS bridges (br-int,\n br-tun) are integrated in Icehouse?','Hello,\nI want to know that why bridges are integrated. So, I saw that GRE tunnels also established on br-int. I dumped FlowTables on br-int like bellow. (It\'s summerized )\n________________________________\ntable=0, n_packets=29, n_bytes=2938, send_flow_rem in_port=3,dl_src=fa:16:3e:9e:dc:5f actions=set_field:0x3->tun_id,goto_table:10 table=0, n_packets=22, n_bytes=2308, send_flow_rem in_port=4,dl_src=fa:16:3e:41:24:1d actions=set_field:0x3->tun_id,goto_table:10 table=0, n_packets=70, n_bytes=8286, send_flow_rem tun_id=0x3,in_port=2 actions=goto_table:20 table=0, n_packets=0, n_bytes=0, send_flow_rem priority=8192,in_port=3 actions=drop table=0, n_packets=0, n_bytes=0, send_flow_rem priority=8192,in_port=4 actions=drop table=0, n_packets=415, n_bytes=37765, send_flow_rem dl_type=0x88cc actions=CONTROLLER:56\ntable=10, n_packets=0, n_bytes=0, send_flow_rem priority=8192,tun_id=0x3 actions=goto_table:20 table=10, n_packets=12, n_bytes=1860, send_flow_rem priority=16384,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:2,goto_table:20 table=10, n_packets=24, n_bytes=2084, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:4c:a5:a9 actions=output:2,goto_table:20 table=10, n_packets=15, n_bytes=1302, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:e8:f6:86 actions=output:2,goto_table:20\ntable=20, n_packets=39, n_bytes=3386, send_flow_rem priority=8192,tun_id=0x3 actions=drop table=20, n_packets=21, n_bytes=2956, send_flow_rem priority=16384,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:4,output:3 table=20, n_packets=18, n_bytes=2102, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:41:24:1d actions=output:4 table=20, n_packets=25, n_bytes=2732, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:9e:dc:5f actions=output:3\n________________________________\nthen, I assumed that by enabling OF1.3 protocol on OVS, they can use pipe-lining process by numbering FlowTable.\nbut, I could not know that what is the advantage of integration of both bridges.\nthere are any performance improvement?\n\n\nRegards\nTaeheum Na\n****************************************************\nM.S. candidate of Networked Computing Systems Lab.\nSchool of Information and Communications\nGIST (Gwangju Inst. of Sci. and Tech.)\nE-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\nPhone: +82-10-2238-9424\nOffice: +82-62-715-2273\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140814/3cc1533b/attachment.html>\n\n',NULL,NULL),('<0145D5DF1C56174FABB6EB834BC4909C03FEBD1915AC@NML2007.netmedia.kjist.ac.kr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-18 12:55:58',32400,'2014-08-18 03:55:58',NULL,'[Openstack-operators] How can I select host node to create VM?','Hello,\nWhen I create instance, I want to choice host node.\nI saw that by default, VMs are scheduled by filter scheduler which only consider computing resource.\nI want to apply substrate network considered scheduling algorithm on OpenStack.\nTo do this one, I have to monitor utilization of computing/network resources.\nNow, I\'m planning to use OpenvSwitch commend to know network situation.\n\nDo you have any comment for me? (monitor/scheduling)\n\nRegards\nTaeheum Na\n****************************************************\nM.S. candidate of Networked Computing Systems Lab.\nSchool of Information and Communications\nGIST (Gwangju Inst. of Sci. and Tech.)\nE-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\nPhone: +82-10-2238-9424\nOffice: +82-62-715-2273\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140818/470f4ef4/attachment.html>\n\n',NULL,NULL),('<0145D5DF1C56174FABB6EB834BC4909C03FEBD1915C9@NML2007.netmedia.kjist.ac.kr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-26 01:23:58',32400,'2014-08-25 16:23:58',NULL,'[Openstack-operators] Iperf isn\'t work between VMs which are placed\n	in other host','Hello, I tried to measure network performance BTW VM which connected through GRE tunnel. So, I configured neutron(ML2/GRE).\nThen I verified TCP performance between VMs which are placed on same host.\nBut I could not make Iperf connection BTW VMs (on other host), but ping is ok.\nbellow things are current Security group configuration. I think that I allow all traffic which is needed to execute iperf.\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| udp         | 1         | 65535   | 0.0.0.0/0 |              |\n| tcp         | 1         | 65535   | 0.0.0.0/0 |              |\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\nDo you have any comment?\n\nRegards\nTaeheum Na\n****************************************************\nM.S. candidate of Networked Computing Systems Lab.\nSchool of Information and Communications\nGIST (Gwangju Inst. of Sci. and Tech.)\nE-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\nPhone: +82-10-2238-9424\nOffice: +82-62-715-2273\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/3e162af0/attachment.html>\n\n',NULL,NULL),('<0145D5DF1C56174FABB6EB834BC4909C03FEBD1915CA@NML2007.netmedia.kjist.ac.kr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-26 11:19:41',32400,'2014-08-26 02:19:41',NULL,'[Openstack-operators] Iperf isn\'t work between VMs which are\n placed in other host','Hello, David\nYour comment was exactly correct!!\nI refer following blog. Then adjust MTU on the VM\nAnd current it\'s work well.\nhttp://techbackground.blogspot.kr/2013/06/path-mtu-discovery-and-gre.html\n\nThank you for your comment.\nIt was helpful to save my time.\n\nFrom: medberry at gmail.com [mailto:medberry at gmail.com] On Behalf Of David Medberry\nSent: Tuesday, August 26, 2014 1:40 AM\nTo: Taeheum Na\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Iperf isn\'t work between VMs which are placed in other host\n\nWhat MTU are you using (try different ping sizes to see if this problem also occurs with large pings.)  You will likely want to limit the vms to 1454 MTU and re-run your tests. Google for GRE OPENSTACK MTU for more info.\n\nOn Mon, Aug 25, 2014 at 11:23 AM, Taeheum Na <thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>> wrote:\nHello, I tried to measure network performance BTW VM which connected through GRE tunnel. So, I configured neutron(ML2/GRE).\nThen I verified TCP performance between VMs which are placed on same host.\nBut I could not make Iperf connection BTW VMs (on other host), but ping is ok.\nbellow things are current Security group configuration. I think that I allow all traffic which is needed to execute iperf.\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| udp         | 1         | 65535   | 0.0.0.0/0 |              |\n| tcp         | 1         | 65535   | 0.0.0.0/0 |              |\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\nDo you have any comment?\n\nRegards\nTaeheum Na\n****************************************************\nM.S. candidate of Networked Computing Systems Lab.\nSchool of Information and Communications\nGIST (Gwangju Inst. of Sci. and Tech.)\nE-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\nPhone: +82-10-2238-9424<tel:%2B82-10-2238-9424>\nOffice: +82-62-715-2273<tel:%2B82-62-715-2273>\n\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140826/e7dc479d/attachment-0001.html>\n\n','<CAJhvMSuOo1fnG8XN6PXKWV3piTpufo10mwhf5NC-On5ehyTRiw@mail.gmail.com>',NULL),('<0145D5DF1C56174FABB6EB834BC4909C03FEC831ED52@NML2007.netmedia.kjist.ac.kr>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 14:28:58',32400,'2014-09-19 05:28:58',NULL,'[openstack-dev] Neutron: why OVS bridges (br-int,\n br-tun) are integrated in Icehouse?','Hello, I want to know that why bridges are integrated. So,\nI saw that GRE tunnels also established on br-int.\nI dumped flowtables on br-int like bellow. (It\'s summerized )\n________________________________\ntable=0, n_packets=29, n_bytes=2938, send_flow_rem in_port=3,dl_src=fa:16:3e:9e:dc:5f actions=set_field:0x3->tun_id,goto_table:10\ntable=0, n_packets=22, n_bytes=2308, send_flow_rem in_port=4,dl_src=fa:16:3e:41:24:1d actions=set_field:0x3->tun_id,goto_table:10\ntable=0, n_packets=70, n_bytes=8286, send_flow_rem tun_id=0x3,in_port=2 actions=goto_table:20\ntable=0, n_packets=0, n_bytes=0, send_flow_rem priority=8192,in_port=3 actions=drop table=0, n_packets=0, n_bytes=0, send_flow_rem priority=8192,in_port=4 actions=drop\ntable=0, n_packets=415, n_bytes=37765, send_flow_rem dl_type=0x88cc actions=CONTROLLER:56\ntable=10, n_packets=0, n_bytes=0, send_flow_rem priority=8192,tun_id=0x3 actions=goto_table:20\ntable=10, n_packets=12, n_bytes=1860, send_flow_rem priority=16384,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:2,goto_table:20\ntable=10, n_packets=24, n_bytes=2084, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:4c:a5:a9 actions=output:2,goto_table:20\ntable=10, n_packets=15, n_bytes=1302, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:e8:f6:86 actions=output:2,goto_table:20\ntable=20, n_packets=39, n_bytes=3386, send_flow_rem priority=8192,tun_id=0x3 actions=drop\ntable=20, n_packets=21, n_bytes=2956, send_flow_rem priority=16384,tun_id=0x3,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:4,output:3\ntable=20, n_packets=18, n_bytes=2102, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:41:24:1d actions=output:4\ntable=20, n_packets=25, n_bytes=2732, send_flow_rem tun_id=0x3,dl_dst=fa:16:3e:9e:dc:5f actions=output:3\n________________________________\nThen, I assumed that by enabling OF1.3 protocol on OVS, they can use pipe-lining method by numbering Flowtable.\nBut, I could not know that what is the advantage of integration of both bridges\nThere are any performance improvement?\nand second question is that packets which are putted tunnel are already transmitted to other host by marked flow-table\nwhy it is addressed by \"table=20\"?\n\n\nRegards\nTaeheum Na\n****************************************************\nM.S. candidate of Networked Computing Systems Lab.\nSchool of Information and Communications\nGIST (Gwangju Inst. of Sci. and Tech.)\nE-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\nPhone: +82-10-2238-9424\nOffice: +82-62-715-2273\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140919/cb5c95d0/attachment.html>\n\n',NULL,NULL),('<014601d01f69$d5f8e4b0$81eaae10$@t-online.de>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-12-24 12:07:41',3600,'2014-12-24 11:07:41',NULL,'[OpenStack-Infra] [Support] Problems installing zuul for\n	jenkins-gerrit gateway (Jenkins does not run jobs)','Hi,\n\n \n\nbig thanks for your help! If you (or any other) need more information about something, please just ask :)\n\n \n\nKind regards,\n\nFlorian\n\n \n\nVon: Abhishek Shrivastava [mailto:abhishek at cloudbyte.com] \nGesendet: Mittwoch, 24. Dezember 2014 06:09\nAn: Florian Schmidt; openstack-infra at lists.openstack.org\nBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\n\n \n\nHi,\n\n \n\nThanks for the information, I\'ll follow as you did and will come back to you as soon as I find the solution.\n\n \n\nOn Wed, Dec 24, 2014 at 2:54 AM, Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> > wrote:\n\nHi,\n\n \n\nthanks again! I?m not sure, if the document/script helps me, because i don?t want to install an external testing for openstack. Maybe this was not ?clear?, but I want to use zuul as the bridge between my own gerrit and my own Jenkins installation (without openstack or any other upstream projects).\n\n \n\nNevertheless, I think I checked the settings, which are set by puppet (as good as I can without much puppet knowledge) and can?t find any difference :/\n\n \n\nKind regards and merry Christmas!\n\nFlorian\n\n \n\nVon: Abhishek Shrivastava [mailto:abhishek at cloudbyte.com <mailto:abhishek at cloudbyte.com> ] \nGesendet: Dienstag, 23. Dezember 2014 10:53\nAn: Florian Schmidt\nBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\n\n \n\nHi Florian,\n\n \n\nThanks for this article, but since we haven\'t got any issues like yours in our setup, therefore I am sending you one automated procedure document for setting up the CI environment that we are following. I hope it can help. \n\n \n\nOn Tue, Dec 23, 2014 at 3:00 PM, Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> > wrote:\n\nHello,\n\n \n\nthanks for your answer. For Jenkins i used this wiki article to install it on Ubuntu server [1] and added Jobs via the Jenkins web frontend (if you need the parameter for the test job, i can attach it, but not now, cause i\'m in a train :/)\n\n \n\nIn order to install zuul i downloaded the gearman plugin from openstack\'s git and build it with marven (clean install), uploaded the resulting plugin binary to jenkins (again via the web frontned), test the connection in the settings (works) and enabled gearman.\n\n \n\n[1] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu\n\n \n\nIf you have further questions, i\'m happy to answer :)\n\n \n\nKind regards,\n\nFlorian\n\n \n\nGesendet mit meinem HTC\n\n \n\n----- Reply message -----\nVon: \"Abhishek Shrivastava\" <abhishek at cloudbyte.com <mailto:abhishek at cloudbyte.com> >\nAn: \"Florian Schmidt\" <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> >, <openstack-infra at lists.openstack.org <mailto:openstack-infra at lists.openstack.org> >\nCc: \"Amit Das\" <amit.das at cloudbyte.com <mailto:amit.das at cloudbyte.com> >, \"Punith S\" <punith.s at cloudbyte.com <mailto:punith.s at cloudbyte.com> >\nBetreff: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\nDatum: Di., Dez. 23, 2014 07:35\n\n \n\nHi Florian,\n\n \n\nCan you please tell me the procedure which you have followed for setting up the CI environment, so that I can be clear with your zuul problem. \n\n \n\n---------- Forwarded message ----------\nFrom: Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> >\nDate: Mon, Dec 22, 2014 at 7:04 PM\nSubject: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\nTo: openstack-infra at lists.openstack.org <mailto:openstack-infra at lists.openstack.org> \n\n\nHello all together,\n\ni hope, someone of you can help me with my little problem. Actually I use\nGerrit Trigger 8Jenkins plugin) to trigger Jenkins jobs for specific Gerrit\nevents. Now I want to migrate from Gerrit Trigger to zuul (easier, layout\nbased configuration and more trigger options and different pipelines).\n\nI installed zuul with this Blog post as a basis:\nhttp://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.ht <http://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.html> \nml\n\nYou can find my zuul configuration here[1] and my initial layout.yaml\nhere[2]\n\nNow I have the problem, that it seems, that Jenkins doesn\'t run jobs added\nIn gearman (they don\'t appear in Jenkins web frontend). Zuul\'s status page\nlists the change (added via a \"recheck\" comment) and the status of the job\n\"Jenkins-test\" is \"queued\" forever. That\'s why I think there is a problem\nsomewhere between Jenkins and zuul, but I can\'t find it. I hope, that\nsomeone from here can assist me to find out the problem? I cleared the log\nand restarted Jenkins and zuul (stopped both and started zuul first and then\nJenkins) and added a new comment \"recheck\" to my test change in gerrit to\ntrigger a new build. I uploaded my log files here[3], maybe it helps to find\nout the problem. I have anonymized the domain to be \"example.com <http://example.com> \" in the log\nfiles.\n\nI\'m also online in #openstack-infra on freenode (nick: FlorianSW), so feel\nfree to contact me there, I would be very grateful to get help to solve this\nproblem :)\n\n[1] https://gist.github.com/Florianschmidtwelzow/ed0e3047f0ef0c5e5554\n[2] https://gist.github.com/Florianschmidtwelzow/a101a87d653d5bbc6de6\n[3] https://gist.github.com/Florianschmidtwelzow/12fff7c4530805dece0c\n\nKind regards,\nFlorian\n\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org <mailto:OpenStack-Infra at lists.openstack.org> \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n \n\n\n\n\n\n \n\n-- \n\nThanks & Regards,\n\nAbhishek\n\n\n\n\n\n \n\n-- \n\nThanks & Regards,\n\nAbhishek\n\n\n\n\n\n \n\n-- \n\nRegards & Merry Christmas,\n\nAbhishek\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20141224/f47b74e3/attachment-0001.html>\n\n','<CAOULzZVnhESW-u+Pcv-SdAod0o+wuVKMhdGZ9e3L+hhc-W-rXg@mail.gmail.com>',NULL),('<014a01cff28c$f7fd9c90$e7f8d5b0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-28 15:55:45',25200,'2014-10-28 08:55:45',NULL,'[Openstack] No metadata with the second dhcp agent','Hello,\n\n \n\nOn the first dhcp agent running on the network node the metadata agent is\nalso running. On the second dhcp agent running on a compute node there is no\nmetadata service running.\n\nShould it?\n\n \n\nCheers\n\nChris\n\n \n\nFrom: Staicu Gabriel [mailto:gabriel_staicu at yahoo.com] \nSent: Tuesday, October 28, 2014 15:19\nTo: Chris\nSubject: Re: [Openstack] No metadata with the second dhcp agent\n\n \n\nHi Chris,\n\n \n\nDo you have also a metadata agent working where the dhcp agent is working?\n\n \n\nGabriel\n\n \n\nOn Tuesday, October 28, 2014 8:53 AM, Chris <contact at progbau.de\n<mailto:contact at progbau.de> > wrote:\n\n \n\nHello,\n\n \n\nFor high availability we added a second dhcp agent (on one of the compute\nnodes). New spawned instances get their IPs through this agent but the\nmetadata is not working. In the instance bootup I can see they get an error\n500.  \n\nThrough the first dhcp agent on the network node the metadata for the\ninstances works fine. Did I miss something?\n\n \n\nThanks!\n\n \n\nGreetings \n\nChris\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to    : openstack at lists.openstack.org\n<mailto:openstack at lists.openstack.org> \nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141028/37660a3d/attachment.html>\n\n','<1414484320.82189.YahooMailNeo@web122602.mail.ne1.yahoo.com>',NULL),('<014b01cc2f75$320a32b0$961e9810$@openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-06-20 13:09:27',-18000,'2011-06-20 18:09:27',NULL,'[Openstack-operators] Nova problem','Have you filed a bug on Launchpad.net ?\n\n \n\nFrom: openstack-operators-bounces at lists.openstack.org\n[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of\nStephen Broeker\nSent: Wednesday, June 15, 2011 2:58 PM\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Nova problem\n\n \n\nThe following is a problem that I am having with Nova.\n\n \n\n \n\n$ nova --username sbroeker --apikey 12345 --url\nhttp://192.168.210.128:8774/v1.0 flavor-list\n\n \n\nThis server could not verify that you are authorized to access the document\nyou requested. Either you supplied the wrong credentials (e.g., bad\npassword), or your browser does not understand how to supply the credentials\nrequired. (HTTP 401)\n\n \n\n \n\nI used curl to debug this:\n\n \n\n \n\ncurl -v -X GET -H \"X-Auth-User: sbroeker\" -H \"X-Auth-Key: 12345\"\nhttp://192.168.210.128:8774/v1.0\n\n \n\n* About to connect() to 192.168.210.128 port 8774 (#0)\n\n*   Trying 192.168.210.128... connected\n\n* Connected to 192.168.210.128 (192.168.210.128) port 8774 (#0)\n\n> GET /v1.0 HTTP/1.1\n\n> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7\nOpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n\n> Host: 192.168.210.128:8774\n\n> Accept: */*\n\n> X-Auth-User: sbroeker\n\n> X-Auth-Key: 12345\n\n> \n\n< HTTP/1.1 204 No Content\n\n< Content-Length: 0\n\n< X-Auth-Token: e2776be2a56713a5bf0cdb2e23e2cf91a26c73c3\n\n< X-Server-Management-Url: http://192.168.210.128:8774/v1.0\n\n< X-Storage-Url: \n\n< X-Cdn-Management-Url: \n\n< Content-Type: text/plain; charset=UTF-8\n\n< Date: Wed, 15 Jun 2011 19:51:53 GMT\n\n< \n\n* Connection #0 to host 192.168.210.128 left intact\n\n* Closing connection #0\n\n \n\n \n\nLooks like the Response Header X-Server-Management-Url is not being\ncompletely filled in.\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110620/1c7b2243/attachment.html>\n\n','<BANLkTimRzsa8UtbQnmSkiHZmzKnWP5e+7Q@mail.gmail.com>',NULL),('<014b01cf1322$0fb7e700$2f27b500$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-01-16 17:18:39',-28800,'2014-01-17 01:18:39',NULL,'[openstack-community] OSNW Call for speakers: SDN (Portland)','Our OpenStack Northwest User Group http://www.meetup.com/OpenStack-Northwest\nis getting very popular very quickly. About 60 stackers attended last meetup\nin Portland where presenters from DetaCloud, DreamHost, SwiftStack and EMC\nfocused on OpenStack storage.\n\n \n\nNext meetup is scheduled for Feb 5 and the focus this time is on networking.\nWe are looking for speakers who can discuss SDN, Neutron, OVS, ML2,\nOpenFlow, Nicira, etc.\n\n \n\nPlease find me on Twitter @alkari if you are developing or implementing any\nof these technologies and like to present them to our user group, hopefully\nyou are in Portland on that date (or if you\'d like to visit Portland - the\nsnow is awesome on Mt. Hood if you\'re into that).\n\n \n\nJoin us if you\'re in town Feb 5th.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140116/53a72300/attachment.html>\n\n',NULL,NULL),('<015401cff296$8399baa0$8acd2fe0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-28 17:04:05',25200,'2014-10-28 10:04:05',NULL,'[Openstack] different ml2 agents per compute node','Hello\n\n \n\nIs it possible to use different ML2 agents on the compute nodes? \n\nLet\'s say I want use OVS on compute node A and the linux bridge on compute\nnode B.\n\n \n\nIf yes what changes are needed in the network node?\n\n \n\nCheers\n\nChris\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141028/95429588/attachment.html>\n\n',NULL,NULL),('<015d01ceeb12$0d7b34c0$28719e40$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-27 10:43:20',32400,'2013-11-27 01:43:20',NULL,'[Openstack] multipath - EMC vs NetApp','Hello Xing,\n\nThank you for your reply.\n\nYou wrote:\n> In the logs, you got a login failure.  I\'m wondering if the\niscsi_ip_address\n> in cinder.conf has the correct value.  It should be the iSCSI IP address\n> from SPA or SPB.\n\nWe set one of SP-Ports\' IP addresses to iscsi_ip_address.\nTo be specific, A-4v0\'s IP address.\n\n> The code in cinder.brick.initiator.connector should work for VNX.  It uses\n> one iSCSI target IP address to do iscsiadm discovery and that should\nreturn\n> multiple IP addresses.  If not, we need to look at your configuration.\n\n\'iscsiadm discovery\' returns multiple IP addresses.\nSo cinder-volume tried to login to each of them.\n\n> Let me contact the account manager for NTT to set up a conference call\nwith\n> you to get this resolved quickly.\n\nWe will get in touch with the account manager of EMC Japan for our company.\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\n> -----Original Message-----\n> From: yang, xing [mailto:xing.yang at emc.com]\n> Sent: Wednesday, November 27, 2013 2:07 AM\n> To: Takashi Natsume; openstack at lists.openstack.org\n> Subject: RE: [Openstack] multipath - EMC vs NetApp\n> \n> Hi Takashi,\n> \n> In the logs, you got a login failure.  I\'m wondering if the\niscsi_ip_address\n> in cinder.conf has the correct value.  It should be the iSCSI IP address\n> from SPA or SPB.\n> \n> The code in cinder.brick.initiator.connector should work for VNX.  It uses\n> one iSCSI target IP address to do iscsiadm discovery and that should\nreturn\n> multiple IP addresses.  If not, we need to look at your configuration.\n> \n> Let me contact the account manager for NTT to set up a conference call\nwith\n> you to get this resolved quickly.\n> \n> Thanks,\n> Xing\n> \n> \n> \n> -----Original Message-----\n> From: Takashi Natsume [mailto:natsume.takashi at lab.ntt.co.jp]\n> Sent: Tuesday, November 26, 2013 3:52 AM\n> To: yang, xing; openstack at lists.openstack.org\n> Subject: RE: [Openstack] multipath - EMC vs NetApp\n> \n> Hello Xing,\n> \n> Thank you for your reply.\n> \n> You wrote:\n> > What OpenStack release are you running?  iSCSI multipath support was\n> > added\n> very late in Grizzly release and there were patches regarding multipath\n> added even after the Grizzly release.  EMC VNX5300 should work with iSCSI\n> multipath with Grizzly and beyond.\n> \n> We tested with \'master\' code\n> (nova:1dca95a74788667e52cab664c8a1dd942222d9c8\n> and cinder:9b599d092ffa168a73ab7fa98ff20cb2cb48fe0b) last month, but\n> iSCSI multipath could not be configured.\n> \n> Our configuration was as follows.\n> (IP addresses, passwords, prefixes are masked.)\n> \n> ----------------------------------------------------------------\n> - /etc/nova/nova.conf\n> volume_api_class = nova.volume.cinder.API libvirt_iscsi_use_multipath =\n> True\n> \n> - /etc/cinder/cinder.conf\n> use_multipath_for_image_xfer = true\n> iscsi_target_prefix = iqn.1992-04.com.emc:cx.fcn00XXXXXXXX\n> iscsi_ip_address = XX.XX.XX.11\n> volume_driver =\n> cinder.volume.drivers.emc.emc_smis_iscsi.EMCSMISISCSIDriver\n> cinder_emc_config_file = /etc/cinder/cinder_emc_config.xml\n> \n> - /etc/cinder/cinder_emc_config.xml\n> \n> <?xml version=\'1.0\' encoding=\'UTF-8\'?>\n> <EMC>\n> <StorageType>Pool0</StorageType>\n> <EcomServerIp>XX.XX.XX.XX</EcomServerIp>\n> <EcomServerPort>5988</EcomServerPort>\n> <EcomUserName>admin</EcomUserName>\n> <EcomPassword>xxxxxxxx</EcomPassword>\n> </EMC>\n> \n> - cinder-volume host\n> A python-pywbem package(Version 0.7.0-4) was installed on the\ncinder-volume\n> host.\n> \n> - SMI-S Provider\n> EMC SMI-S Provider V4.6.1.1 was set up on RHEL 6.3.\n> and configured by following the SMI-S Provider Release notes.\n> \n> - VNX5300\n> Thin Provisioning enabler was installed.\n> Thin pool \'Pool0\' was created.\n> \n> And \"Register with VNX\" by Unisphere\n> (See\n> http://docs.openstack.org/grizzly/openstack-block-storage/admin/conten\n> t/emc-\n> smis-iscsi-driver.html)\n> ----------------------------------------------------------------\n> \n> When copy_image_to_volume was executed, the following log was outputed.\n> (Target IQN and portal IP addresses are masked.)\n> \n> ---\n> 2013-10-31 11:27:43.322 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.13,3260]\n> Login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6,\n> portal: XX.XX.XX.13,3260]: successful\n> 2013-10-31 11:27:45.680 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.17,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.17,3260]:\n> 2013-10-31 11:27:47.945 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.12,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.12,3260]:\n> 2013-10-31 11:27:50.144 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.15,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.15,3260]:\n> 2013-10-31 11:27:52.374 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.11,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.11,3260]:\n> 2013-10-31 11:27:54.621 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.16,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.16,3260]:\n> 2013-10-31 11:27:56.914 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.18,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.18,3260]:\n> 2013-10-31 11:27:59.174 26080 DEBUG cinder.brick.initiator.connector\n> [req-18a3433e-561b-4f04-b3be-b5d5956780f9\n> 59b7221e2f8041e39f643520b78ba533 964613d2565a4a069da9658e44b544ae]\n> iscsiadm (\'--login\',): stdout=Logging in to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\n> XX.XX.XX.14,3260]\n>  stderr=iscsiadm: Could not login to [iface: default, target:\n> iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.14,3260]:\n> ---\n> \n> In cinder.brick.initiator.connector, it is using a single iSCSI\ntarget(IQN)\n> for login to multiple (different) portal IP addresses.\n> VNX5300 has multiple iSCSI ports with different iSCSI target (IQN)s.\n> (Normally it should use a different iSCSI target(IQN) for each IP\naddress.)\n> \n> If our settings was wrong, could you please let us know what are the\ncorrect\n> settings?\n> \n> Regards,\n> Takashi Natsume\n> NTT Software Innovation Center\n> Tel: +81-422-59-4399\n> E-mail: natsume.takashi at lab.ntt.co.jp\n> \n> > -----Original Message-----\n> > From: yang, xing [mailto:xing.yang at emc.com]\n> > Sent: Tuesday, November 26, 2013 12:12 AM\n> > To: Takashi Natsume; openstack at lists.openstack.org\n> > Subject: RE: [Openstack] multipath - EMC vs NetApp\n> >\n> > Hi Takashi,\n> >\n> > What OpenStack release are you running?  iSCSI multipath support was\n> > added very late in Grizzly release and there were patches regarding\n> > multipath added even after the Grizzly release.  EMC VNX5300 should\n> > work with iSCSI multipath with Grizzly and beyond.\n> >\n> > Thanks,\n> > Xing\n> >\n> >\n> >\n> > -----Original Message-----\n> > From: Takashi Natsume [mailto:natsume.takashi at lab.ntt.co.jp]\n> > Sent: Monday, November 25, 2013 6:07 AM\n> > To: yang, xing; openstack at lists.openstack.org\n> > Subject: RE: [Openstack] multipath - EMC vs NetApp\n> >\n> > Hello Xing and all,\n> >\n> > We tried to set up iSCSI multipath with EMC VNX5300.\n> > However, we had some problems with setting the iSCSI multipath with\n> > EMC VNX5300.\n> > So, we analyzed the logs and source codes, and found out that\n> > nova-compute (cinder-volume also same) is using a single iSCSI\n> > target(IQN) for login to multiple (different) portal IP addresses.\n> > VNX5300 has multiple iSCSI ports with different iSCSI target (IQN)s.\n> > (Normally it should use a different iSCSI target(IQN) for each IP\n> address.)\n> >\n> > So, we realized that, iSCSI multipath cannot be configured with VNX5300.\n> > But we would like to use iSCSI multipath with EMC VNX5300.\n> >\n> > Regards,\n> > Takashi Natsume\n> > NTT Software Innovation Center\n> > Tel: +81-422-59-4399\n> > E-mail: natsume.takashi at lab.ntt.co.jp\n> >\n> > From: yang, xing [mailto:xing.yang at emc.com]\n> > Sent: Friday, November 22, 2013 7:25 AM\n> > To: Carlos Alvarez; openstack at lists.openstack.org\n> > Subject: Re: [Openstack] multipath - EMC vs NetApp\n> >\n> > Hi Carlos,\n> >\n> > We are working on this issue and will keep you informed.\n> >\n> > Thanks,\n> > Xing\n> >\n> >\n> > From: Carlos Alvarez [mailto:cbalvarez at gmail.com]\n> > Sent: Monday, November 18, 2013 1:19 PM\n> > To: openstack at lists.openstack.org\n> > Subject: [Openstack] multipath - EMC vs NetApp\n> >\n> > Hi All.\n> >\n> > I recently added a EMC V-Max storage system, and realized the\n> > multipath is not working. The device is called /dev/mapper/XXXX but\n> > when I see the multipath -ll output, I see just one path. It is\n> > working fine with a\n> NetApp\n> > 3250.\n> >\n> > Looking into differences, I see the output of the iscsiadm discovery\n> > differs:\n> >\n> > Netapp output:\n> > root at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p\n> > 10.33.5.10\n> > 10.33.5.10:3260,1030\n> > iqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n> > 10.33.5.11:3260,1031\n> > iqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n> >\n> > Emc output:\n> > root at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p\n> > 10.33.5.25\n> > 10.33.5.25:3260,1 iqn.1992-04.com.emc:50000973f00bcd44\n> >\n> >\n> > Looking into the code, the former is clearly what the connect_volume\n> method\n> > is expecting: a single ip which returns both path. I reported it to\n> > EMC and the answer is that it works with netapp because the 3250 has a\n> > feature EMC lacks (called multipath groups).\n> >\n> > Is anybody using multipath with a V-Max?. It should work or EMC is not\n> > supported?\n> >\n> > Thanks!\n> > Carlos\n> >\n> >\n> \n> \n> \n\n\n\n\n\n','<35804680EDCC5640AFC7C590814F48F50115EDBB4F37@MX40A.corp.emc.com>',NULL),('<0161DF4C-E2D4-4A02-AE70-63564FFC18D7@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 14:21:36',-25200,'2014-06-26 21:21:36',NULL,'[openstack-dev] [nova] Why is there a \'None\' task_state between\n	\'SCHEDULING\' & \'BLOCK_DEVICE_MAPPING\'?','Thanks WingWJ. It would also be great to track this in a bug.\n\nVish\n\nOn Jun 26, 2014, at 5:30 AM, wu jiang <wingwj at gmail.com> wrote:\n\n> Hi Phil, \n> \n> Ok, I\'ll submit a patch to add a new task_state(like \'STARTING_BUILD\') in these two days. \n> And related modifications will be definitely added in the Doc.\n> \n> Thanks for your help. :)\n> \n> WingWJ\n> \n> \n> On Thu, Jun 26, 2014 at 6:42 PM, Day, Phil <philip.day at hp.com> wrote:\n> Why do others think ? do we want a spec to add an additional task_state value that will be set in a well defined place.   Kind of feels overkill for me in terms of the review effort that would take compared to just reviewing the code - its not as there are going to be lots of alternatives to consider here.\n> \n>  \n> \n> From: wu jiang [mailto:wingwj at gmail.com] \n> Sent: 26 June 2014 09:19\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [nova] Why is there a \'None\' task_state between \'SCHEDULING\' & \'BLOCK_DEVICE_MAPPING\'?\n> \n>  \n> \n>  Hi Phil, \n> \n>  \n> \n> thanks for your reply. So should I need to submit a patch/spec to add it now?\n> \n>  \n> \n> On Wed, Jun 25, 2014 at 5:53 PM, Day, Phil <philip.day at hp.com> wrote:\n> \n> Looking at this a bit deeper the comment in _start_buidling() says that its doing this to ?Save the host and launched_on fields and log appropriately ?.    But as far as I can see those don?t actually get set until the claim is made against the resource tracker a bit later in the process, so this whole update might just be not needed ? although I still like the idea of a state to show that the request has been taken off the queue by the compute manager.\n> \n>  \n> \n> From: Day, Phil \n> Sent: 25 June 2014 10:35\n> \n> \n> To: OpenStack Development Mailing List\n> \n> Subject: RE: [openstack-dev] [nova] Why is there a \'None\' task_state between \'SCHEDULING\' & \'BLOCK_DEVICE_MAPPING\'?\n> \n>  \n> \n> Hi WingWJ,\n> \n>  \n> \n> I agree that we shouldn?t have a task state of None while an operation is in progress.  I?m pretty sure back in the day this didn?t use to be the case and task_state stayed as Scheduling until it went to Networking  (now of course networking and BDM happen in parallel, so you have to be very quick to see the Networking state).\n> \n>  \n> \n> Personally I would like to see the extra granularity of knowing that a request has been started on the compute manager (and knowing that the request was started rather than is still sitting on the queue makes the decision to put it into an error state when the manager is re-started more robust).\n> \n>  \n> \n> Maybe a task state of ?STARTING_BUILD? for this case ?\n> \n>  \n> \n> BTW I don?t think _start_building() is called anymore now that we?ve switched to conductor calling build_and_run_instance() ? but the same task_state issue exist in there well.\n> \n>  \n> \n> From: wu jiang [mailto:wingwj at gmail.com]\n> \n> Sent: 25 June 2014 08:19\n> To: OpenStack Development Mailing List\n> \n> Subject: [openstack-dev] [nova] Why is there a \'None\' task_state between \'SCHEDULING\' & \'BLOCK_DEVICE_MAPPING\'?\n> \n>  \n> \n> Hi all, \n> \n>  \n> \n> Recently, some of my instances were stuck in task_state \'None\' during VM creation in my environment.\n> \n>  \n> \n> So I checked & found there\'s a \'None\' task_state between \'SCHEDULING\' & \'BLOCK_DEVICE_MAPPING\'.\n> \n>  \n> \n> The related codes are implemented like this:\n> \n>  \n> \n> #    def _start_building():\n> \n> #        self._instance_update(context, instance[\'uuid\'],\n> \n> #                              vm_state=vm_states.BUILDING,\n> \n> #                              task_state=None,\n> \n> #                              expected_task_state=(task_states.SCHEDULING,\n> \n> #                                                   None))\n> \n>  \n> \n> So if compute node is rebooted after that procession, all building VMs on it will always stay in \'None\' task_state. And it\'s useless and not convenient for locating problems. \n> \n>  \n> \n> Why not a new task_state for this step? \n> \n>  \n> \n>  \n> \n> WingWJ\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n>  \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/a615b9b1/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/a615b9b1/attachment.pgp>\n\n','<CAEfJYtSrYiW3hw0AQDgNa+fRrA6arjojQD9=5Zign5u-VJ7a0w@mail.gmail.com>',NULL),('<016901d01f6c$0d9c4ae0$28d4e0a0$@t-online.de>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-12-24 12:23:33',3600,'2014-12-24 11:23:33',NULL,'[OpenStack-Infra] [Support] Problems installing zuul for\n	jenkins-gerrit gateway (Jenkins does not run jobs)','Hi,\n\n \n\nabout the ?Not permitted? errors see my last E-Mail :) \n\n \n\nworkers give me 2 (Jenkins-related) workers, ?nodeName_exec-1? and ?nodeName_exec-2? (I configured my Jenkins master to be able to build two jobs at one time). Both workers have all Jenkins jobs (including Jenkins-test) with a ?build:? prefix (full name for Jenkins-test: ?build:Jenkins-test?).\n\n \n\nAnd status has all jobs prefixed with build:, too.\n\n \n\nVon: Dmitry Teselkin [mailto:dteselkin at mirantis.com] \nGesendet: Mittwoch, 24. Dezember 2014 12:15\nAn: Florian Schmidt\nCc: Abhishek Shrivastava; openstack-infra at lists.openstack.org\nBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\n\n \n\nHi,\n\nCould you run command \'workers\' instead of \'status\' against zuul and check if your jenkins job is there?\n\nThis morning I had similar issue with \'queued\' jobs in zuul, and I found that although the jobs were in output from \'status\' command, they weren\'t be in \'workers\'.\n\nAnd it looks like I was wrong about permissions for \'jenkins-ci\' user. This user is for communications with gerrit, AFAIK.\n\n \n\nOn Wed, Dec 24, 2014 at 2:07 PM, Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> > wrote:\n\nHi,\n\n \n\nbig thanks for your help! If you (or any other) need more information about something, please just ask :)\n\n \n\nKind regards,\n\nFlorian\n\n \n\nVon: Abhishek Shrivastava [mailto:abhishek at cloudbyte.com <mailto:abhishek at cloudbyte.com> ] \nGesendet: Mittwoch, 24. Dezember 2014 06:09\nAn: Florian Schmidt; openstack-infra at lists.openstack.org <mailto:openstack-infra at lists.openstack.org> \n\n\nBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\n\n \n\nHi,\n\n \n\nThanks for the information, I\'ll follow as you did and will come back to you as soon as I find the solution.\n\n \n\nOn Wed, Dec 24, 2014 at 2:54 AM, Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> > wrote:\n\nHi,\n\n \n\nthanks again! I?m not sure, if the document/script helps me, because i don?t want to install an external testing for openstack. Maybe this was not ?clear?, but I want to use zuul as the bridge between my own gerrit and my own Jenkins installation (without openstack or any other upstream projects).\n\n \n\nNevertheless, I think I checked the settings, which are set by puppet (as good as I can without much puppet knowledge) and can?t find any difference :/\n\n \n\nKind regards and merry Christmas!\n\nFlorian\n\n \n\nVon: Abhishek Shrivastava [mailto:abhishek at cloudbyte.com <mailto:abhishek at cloudbyte.com> ] \nGesendet: Dienstag, 23. Dezember 2014 10:53\nAn: Florian Schmidt\nBetreff: Re: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\n\n \n\nHi Florian,\n\n \n\nThanks for this article, but since we haven\'t got any issues like yours in our setup, therefore I am sending you one automated procedure document for setting up the CI environment that we are following. I hope it can help. \n\n \n\nOn Tue, Dec 23, 2014 at 3:00 PM, Florian Schmidt <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> > wrote:\n\nHello,\n\n \n\nthanks for your answer. For Jenkins i used this wiki article to install it on Ubuntu server [1] and added Jobs via the Jenkins web frontend (if you need the parameter for the test job, i can attach it, but not now, cause i\'m in a train :/)\n\n \n\nIn order to install zuul i downloaded the gearman plugin from openstack\'s git and build it with marven (clean install), uploaded the resulting plugin binary to jenkins (again via the web frontned), test the connection in the settings (works) and enabled gearman.\n\n \n\n[1] https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu\n\n \n\nIf you have further questions, i\'m happy to answer :)\n\n \n\nKind regards,\n\nFlorian\n\n \n\nGesendet mit meinem HTC\n\n \n\n----- Reply message -----\nVon: \"Abhishek Shrivastava\" <abhishek at cloudbyte.com <mailto:abhishek at cloudbyte.com> >\nAn: \"Florian Schmidt\" <florian.schmidt.welzow at t-online.de <mailto:florian.schmidt.welzow at t-online.de> >, <openstack-infra at lists.openstack.org <mailto:openstack-infra at lists.openstack.org> >\nCc: \"Amit Das\" <amit.das at cloudbyte.com <mailto:amit.das at cloudbyte.com> >, \"Punith S\" <punith.s at cloudbyte.com <mailto:punith.s at cloudbyte.com> >\nBetreff: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\nDatum: Di., Dez. 23, 2014 07:35\n\n \n\nHi Florian,\n\n \n\nCan you please tell me the procedure which you have followed for setting up the CI environment, so that I can be clear with your zuul problem. \n\n \n\n---------- Forwarded message ----------\nFrom: Florian Schmidt <florian.schmidt.welzow at t-online.de>\nDate: Mon, Dec 22, 2014 at 7:04 PM\nSubject: [OpenStack-Infra] [Support] Problems installing zuul for jenkins-gerrit gateway (Jenkins does not run jobs)\nTo: openstack-infra at lists.openstack.org <mailto:openstack-infra at lists.openstack.org> \n\n\nHello all together,\n\ni hope, someone of you can help me with my little problem. Actually I use\nGerrit Trigger 8Jenkins plugin) to trigger Jenkins jobs for specific Gerrit\nevents. Now I want to migrate from Gerrit Trigger to zuul (easier, layout\nbased configuration and more trigger options and different pipelines).\n\nI installed zuul with this Blog post as a basis:\nhttp://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.ht <http://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.html> \nml\n\nYou can find my zuul configuration here[1] and my initial layout.yaml\nhere[2]\n\nNow I have the problem, that it seems, that Jenkins doesn\'t run jobs added\nIn gearman (they don\'t appear in Jenkins web frontend). Zuul\'s status page\nlists the change (added via a \"recheck\" comment) and the status of the job\n\"Jenkins-test\" is \"queued\" forever. That\'s why I think there is a problem\nsomewhere between Jenkins and zuul, but I can\'t find it. I hope, that\nsomeone from here can assist me to find out the problem? I cleared the log\nand restarted Jenkins and zuul (stopped both and started zuul first and then\nJenkins) and added a new comment \"recheck\" to my test change in gerrit to\ntrigger a new build. I uploaded my log files here[3], maybe it helps to find\nout the problem. I have anonymized the domain to be \"example.com <http://example.com> \" in the log\nfiles.\n\nI\'m also online in #openstack-infra on freenode (nick: FlorianSW), so feel\nfree to contact me there, I would be very grateful to get help to solve this\nproblem :)\n\n[1] https://gist.github.com/Florianschmidtwelzow/ed0e3047f0ef0c5e5554\n[2] https://gist.github.com/Florianschmidtwelzow/a101a87d653d5bbc6de6\n[3] https://gist.github.com/Florianschmidtwelzow/12fff7c4530805dece0c\n\nKind regards,\nFlorian\n\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org <mailto:OpenStack-Infra at lists.openstack.org> \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n \n\n\n\n\n\n \n\n-- \n\nThanks & Regards,\n\nAbhishek\n\n\n\n\n\n \n\n-- \n\nThanks & Regards,\n\nAbhishek\n\n\n\n\n\n \n\n-- \n\nRegards & Merry Christmas,\n\nAbhishek\n\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org <mailto:OpenStack-Infra at lists.openstack.org> \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n\n-- \n\nThanks,\n\nDmitry Teselkin\nDeployment Engineer\nMirantis\nhttp://www.mirantis.com <http://www.mirantis.com/> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20141224/6db6b744/attachment-0001.html>\n\n','<CAGY=EiyLXo3=Am3PK7aDyB4hM7uc4bv6zGZBV9cMgqcpr-sZyA@mail.gmail.com>',NULL),('<0169B209-7E65-4554-B8BB-0A708754737F@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 09:20:20',-14400,'2014-09-02 13:20:20',NULL,'[openstack-dev] [oslo] library feature freeze and final releases','Oslo team,\n\nWe need to consider how we are going to handle the approaching feature freeze deadline (4 Sept). We should, at this point, be focusing reviews on changes associated with blueprints. We will have time to finish graduation work and handle bugs between the freeze and the release candidate deadline, but obviously it?s OK to review those now, too.\n\nI propose that we apply the feature freeze rules to the incubator and any library that has had a release this cycle and is being used by any other project, but that libraries still being graduated not be frozen. I think that gives us exceptions for oslo.concurrency, oslo.serialization, and oslo.middleware. All of the other libraries should be planning to freeze new feature work this week.\n\nThe app RC1 period starts 25 Sept, so we should be prepared to tag our final releases of libraries before then to ensure those final releases don?t introduce issues into the apps when they are released. We will apply 1.0 tags to the same commits that have the last alpha in the release series for each library, and then focus on fixing any bugs that come up during the release candidate period. I propose that we tag our releases on 18 Sept, to give us a few days to fix any issues that arise before the RC period starts.\n\nPlease let me know if you spot any issues with this plan.\n\nDoug\n\n\n\n',NULL,NULL),('<01770394-FB23-4D8B-9091-AE18BF8FFE4F@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 17:15:55',0,'2014-04-14 17:15:55',NULL,'[openstack-dev] [infra][devstack] Review request for\n https://review.openstack.org/#/c/86567/','Could use one more core to approve this so it can go upstream. Enables easier setup of VPN for DevStack, and allows vendor based customizing of .ini files for agent, until a more comprehensive solution is defined.\n\nThanks in advance!\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n\n\n',NULL,NULL),('<01798D80-60BF-4671-BF7C-2D94D5D96599@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 00:42:04',-18000,'2014-02-03 05:42:04',NULL,'[openstack-dev] [Neutron][IPv6] A pair of mode keywords','I just submitted dnsmasq related code to gerrit:\n\nhttps://review.openstack.org/70649\n\nThis submission intended to implement ?ipv6-two-attributes? BP and other three blueprints (SLAAC, DHCPv6-Stateful, DHCPv6-Stateless) rooted from it. Please review and let me know what you think.\n\nThanks in advance!\n\nShixiong\n\n\n\n\n\nOn Feb 2, 2014, at 12:53 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com> wrote:\n\n> On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote:\n>> In other words, I can retrieve the values by:\n>> \n>> subnet.ipv6_ra_mode\n>> subnet.ipv6_address_mode\n>> \n>> Is that correct? Would you please confirm?\n> \n> Yes - that is the intent.\n> \n> I just have to fix an issue with the DB column definitions, so that\n> it\'ll work with postgres, I think I have a closing brace misplaced, so\n> it\'s not defining the Enum type correctly, and we have to get\n> bug #1270212 resolved, since that\'s making the unit tests fail.\n> \n> -- \n> Sean M. Collins\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20140202175258.GA86205@HQSML-1081034>',NULL),('<017e01ccfe65$b17b1f90$14715eb0$@renski.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-09 18:29:58',-28800,'2012-03-10 02:29:58',NULL,'[OpenStack Foundation] Foundation Structure: An Alternative','I currently don?t see a meaningful path around selling board seats in some shape of form.\n\n \n\nHaving a single, structured body dedicated to project evangelism has been key to OpenStack success so far. It is important that the foundation is able to raise meaningful amounts of money to fund its operations, staff and PR activities. On the other hand, expecting companies to commit $50K - $500K / year to the foundation without offering the credibility and nominal influence that comes with the board seat is not likely to work IMHO. \n\n \n\nSelling board seats is like saying ?thank you for your donation, we publically acknowledge your goodwill and commitment to the foundation ? here is a board seat so you can supervise?\n\n \n\nSelling rights to trademarks, training licenses and event sponsorships is like saying ?bitch, we are important, if you want to benefit from OpenStack ? pay us money?\n\n \n\nOne is about motivating donations?i.e. giving organizations a way to publically demonstrate their commitment to the good cause that is OpenStack; the other - about selling assets and milking the momentum of the brand. One has the ?goodwill donation mentality?, the other ? ?extortion mentality.? I feel that fewer will favor the latter.\n\n \n\n-Boris \n\n \n\nFrom: foundation-bounces at lists.openstack.org [mailto:foundation-bounces at lists.openstack.org] On Behalf Of Joshua McKenty\nSent: Friday, March 09, 2012 3:40 PM\nTo: Jonathan Bryce\nCc: <foundation at lists.openstack.org>; OpenStack\nSubject: Re: [OpenStack Foundation] Foundation Structure: An Alternative\n\n \n\nThis is great!  \n\n \n\nJonathan, do you think a completely-elected board is something that the larger corporations would go along with? Ben\'s suggestion to that effect certainly seems to be the simplest model, since we can scale the membership, deliver specific value for cash contributions, and still manage the size of the board.\n\n \n\nRegarding the \"Individual Member\" seats - I would like to echo Devin\'s concerns about stacking by strategic members. If these are truly independent, meaning that they\'re not employees of the corporate members, then I think it\'s a great benefit to have them be part of the board! I\'m imagining folks like Tim Bell (CERN), Peter Mell (NIST) or Vint Cerf on there. \n\n \n\nBoris, I completely agree with decoupling of the \"business side\" of OpenStack from the technical side, and I think managing two separate organizations would be one way to achieve this. My concerns are solely on the business side right now. I\'ve spent a lot of time chatting with the PTLs today, and I have confidence that they can hold the technical community to a meritocratic standard. I think the proposal to vote for seats on the foundation board is more about managing board size, than any crossover of technical community management. \n\n \n\nHaving said that, I\'m still concerned with the idea that we would \"let the bigger guys pay more and get a bigger logo on the homepage\". If we\'re going to \"sell\" OpenStack privileges, I think we need to do it ala-cart, and explicitly. \n\n \n\nSome examples (echoing Ben Cherian\'s comments) might be: \n\n - Use of the trademark (for products, training, or certification)\n\n - Sponsorship of openstack events\n\n - Priority registration for summits and conferences (not necessarily in favor of this one...)\n\n \n\nWhile I was drafting this up, I saw Sean Robert\'s email suggesting that we meet face-to-face and work through some of this together - it seems like a fantastic plan to me, and I\'ll bump everything else from my schedule to make it happen if others are interested. What do you guys think? \n\n \n\n \n\n--\n\nJoshua McKenty, CEO\n\nPiston Cloud Computing, Inc.\nw: (650) 24-CLOUD\n\nm: (650) 283-6846\nhttp://www.pistoncloud.com\n\n \n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\n \n\nOn Friday, March 9, 2012 at 3:06 PM, Jonathan Bryce wrote:\n\nOn Mar 9, 2012, at 4:50 PM, Boris Renski Jr. wrote:\n\nThe one thing I would do away with is the ?elected board members? in favor of more associate member seats. This almost feels like a way to compensate the technology side for giving the marketing side leverage over the former. If we feel that this is necessary, it is a symptom of presence of technology-commercial coupling and we need to fix something else. All technical members should be elected based on merit. All board members ? appointed based on monetary/evangelism contribution. Decoupling between technology direction and purchasing power should be rock solid.\n\n \n\nThanks for the thoughts, Boris. One point I\'d make: the Individual Member seats are not just about compensating the technology side. It gives an opportunity for the entire community to elect representatives. These could be some of the \"luminaries\" Josh spoke of or others unaffiliated with any corporate member. Individual Membership is not limited solely to developers who are contributing code, but would include users, deployers, translators, marketers and people with all sorts of involvement in the community. Individual Membership is free and a great place for participants academic institutions, non-profits, etc. to participate with no price tag.\n\n \n\nJonathan.\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20120309/ec914011/attachment.html>\n\n','<2CEBE1D89609484991D22E10E5DC5E29@pistoncloud.com>',NULL),('<0188459475FD674DAC9410DF62394F61317056@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 07:25:48',0,'2013-12-11 07:25:48',NULL,'[openstack-dev] [Ceilometer] RFC: blueprint monitoring-network','Hi, Ceilometer team.\n\nWe have posted 2 blueprints.[1][2]\n\nThis feature collects the network information(device, link status, statistics) via NorthBound API from SDN Controller.\nThe purpose of this feature is testing network route, resource optimization based on network proximity and etc.\n\nIn particular, the feature collects statistics and information about ports, flows and tables in switches.\n\nWe feel ceilometer shouldn\'t talk to switches directly.\nIf having made pollster that talks to switches directly via SouthBound API, pollsters would be created for each switch vendor.\nIt would make large maintenance cost.\nIn general, NorthBound API abstracts differences between hardwares. Thus this feature collects via NorthBound API.\n\nWe define some meters in this feature on the blueprints.\nThe meters are based on the OpenFlow Switch Specification.\nBut, We have no intention of limiting to OpenFlow Switch.\nWe guess OpenFlow Switch Specification covers general the network information.\nIf you know other necessary meters, please let me know.\n\nDetails are written in wiki.[3]\n\nWe hope feedback of you.\n\n[1]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network\n[2]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network-from-opendaylight\n[3]https://wiki.openstack.org/wiki/Ceilometer/blueprints/monitoring-network\n\nThanks.\n\n\n',NULL,NULL),('<0188459475FD674DAC9410DF62394F6132B7FB@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 01:16:30',0,'2014-01-17 01:16:30',NULL,'[openstack-dev] [Ceilometer] RFC: blueprint monitoring-network','Hi, Manuel.\n\nThank you for your comments.\n\n> since you introduce switches that are currently not reflected in the Neutron entities, am I correct that a switch.port is always unknown to Neutron? Can a switch.port ever be a VM port?\n\nYes, Neutron doesn\'t know a switch.port. A switch.port is related to physical and virtual switch\'s port. Those are not managed by Neutron.\n\nYou can know VM is connected to a switch.port, if SDN controller manages switch that is connected to VM(e.g. br-int in the compute-node).\nIf SDN controller doesn\'t manage, you can\'t know that.\n\nIn specification of this BP, Server, VM and Switch\'s Mac address and IP address will be included in the resource metadata on a switch.port, if those are connected to switch.\nBut, this is recommend, not requirement.\n\nI am making OpenDaylight Implementation, that supports this.\n\nThanks.\n> Yuuichi,\n> \n> since you introduce switches that are currently not reflected in the Neutron entities, am I correct that a switch.port is always unknown to Neutron? Can a switch.port ever be a VM port?\n> \n> I\'d be happy if you could help me understand this better.\n> \n> Best, Manuel\n> ________________________________________\n> From: Yuuichi Fujioka [fujioka-yuuichi at zx.mxh.nes.nec.co.jp]\n> Sent: Wednesday, December 11, 2013 8:25 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: [openstack-dev] [Ceilometer] RFC: blueprint monitoring-network\n> \n> Hi, Ceilometer team.\n> \n> We have posted 2 blueprints.[1][2]\n> \n> This feature collects the network information(device, link status, statistics) via NorthBound API from SDN Controller.\n> The purpose of this feature is testing network route, resource optimization based on network proximity and etc.\n> \n> In particular, the feature collects statistics and information about ports, flows and tables in switches.\n> \n> We feel ceilometer shouldn\'t talk to switches directly.\n> If having made pollster that talks to switches directly via SouthBound API, pollsters would be created for each switch vendor.\n> It would make large maintenance cost.\n> In general, NorthBound API abstracts differences between hardwares. Thus this feature collects via NorthBound API.\n> \n> We define some meters in this feature on the blueprints.\n> The meters are based on the OpenFlow Switch Specification.\n> But, We have no intention of limiting to OpenFlow Switch.\n> We guess OpenFlow Switch Specification covers general the network information.\n> If you know other necessary meters, please let me know.\n> \n> Details are written in wiki.[3]\n> \n> We hope feedback of you.\n> \n> [1]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network\n> [2]https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network-from-opendaylight\n> [3]https://wiki.openstack.org/wiki/Ceilometer/blueprints/monitoring-network\n> \n> Thanks.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<DA6B6F4B7F698F41AA16462C9FA24F2E0C3B5F@FR712WXCHMBA16.zeu.alcatel-lucent.com>',NULL),('<0188459475FD674DAC9410DF62394F6133FC89@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 04:34:51',0,'2014-02-20 04:34:51',NULL,'[openstack-dev] [Neutron] Disscussion about to allow specific\n	floating IP Address','Hi, folks.\n\nI have posted a patch to allow specific IP address of floating IP. [1]\n\nMy motivation is to rescue some cases.\n\nIn the below case, the floating IP address should be specified.\n\n An organization wants to migrate the system to the private cloud (OpenStack).\n The system  has an in-office public IP address that is accessed by the network in the office.\n There is a case where we cannot change the IP address for some reasons.\n\nI understand that the design decision is prohibiting specific floating IP address.\nBut I hope to rethinking about it.\nI think there are users who want to use the function.\n\nI propose a following solution.([1] is not enabled yet)\n\n* In default, the Specific floating IP address is prohibited even if user is admin.\n* When setting policy.json to allow, it is able to use.\n e.g. if the policy is \"rule:admin_only\", non-admin cannot set.\n\nI would like to get your feedback.\n\n [1] https://review.openstack.org/#/c/70286/\n\nThanks.\n\n\n\n',NULL,NULL),('<0188459475FD674DAC9410DF62394F6134B60A@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-07 04:47:23',0,'2014-03-07 04:47:23',NULL,'[openstack-dev] [ceilometer] FFE Request:\n	monitoring-network-from-opendaylight','Hi,\n\nWe would like to request FFE for monitoring-network-from-opendaylight.[1][2]\nUnfortunately, it was not merged by Icehouse-3.\n\nThis is the first driver of the bp/monitoring-network.(It was merged)[3]\nWe strongly believe this feature will enhance ceilometer\'s value.\n\nBecause many people are interested in the SDN, and the OpenDaylight is one of the Open Source SDN Controllers.\nCollected information from the OpenDaylight will make something of value. E.g. optimization of the resource location, testing route of the virtual network and physical network and etc.\n\nAnd this feature is one of the plugins and doesn\'t change core logic.\nWe feel it is low risk.\n\nThus we would like to merge the BP on Icehouse.\n\nThanks.\n\n[1] https://review.openstack.org/#/c/63890/\n[2] https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network-from-opendaylight\n[3] https://blueprints.launchpad.net/ceilometer/+spec/monitoring-network\n\n\n\n',NULL,NULL),('<0189AFF3-F99A-4413-B88C-8D0AEFA5255D@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 15:32:39',0,'2014-01-24 15:32:39',NULL,'[openstack-dev] [Reminder] - Gate Blocking Bug Day on Monday\n Jan	26th','Being the gate one of those things that we all use (and abuse) everyday whatever \nproject we work on, I wouldn?t sleep well by skipping this call. :-)\n\nMyself and my fellow Cloudbasers ociuhandu and gsamfira are going to join in on Monday. \nWe got our small share of ?learning the hard way? on this topic by working on building the \nHyper-V CI, so hopefully we?ll be of some use!\n\n\nAlessandro\n\n\n\nOn 24 Jan 2014, at 14:40 , Sean Dague <sean at dague.net> wrote:\n\n> It may feel like it\'s been gate bug day all the days, but we would\n> really like to get people together for gate bug day on Monday, and get\n> as many people, including as many PTLs as possible, to dive into issues\n> that we are hitting in the gate.\n> \n> We have 2 goals for the day.\n> \n> ** Fingerprint all the bugs **\n> \n> As of this second, we have fingerprints matching 73% of gate failures,\n> that tends to decay over time, as new issues are introduced, and old\n> ones are fixed. We have a hit list of issues here -\n> http://status.openstack.org/elastic-recheck/data/uncategorized.html\n> \n> Ideally we want to get and keep the categorization rate up past 90%.\n> Basically the process is dive into a failed job, look at how it failed,\n> register a bug (or find an existing bug that was registered), and build\n> and submit a finger print.\n> \n> ** Tackle the Fingerprinted Bugs **\n> \n> The fingerprinted bugs - http://status.openstack.org/elastic-recheck/\n> are now sorted by the # of hits we\'ve gotten in the last 24hrs across\n> all queues, so that we know how much immediate pain this is causing us.\n> \n> We\'ll do this on the #openstack-gate IRC channel, which I just created.\n> We\'ll be helping people through what\'s required to build fingerprints,\n> trying to get lots of eyes on the existing bugs, and see how many of\n> these remaining races we can drive out.\n> \n> Looking forward to Monday!\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> Samsung Research America\n> sean at dague.net / sean.dague at samsung.com\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52E25F2D.50105@dague.net>',NULL),('<0196B551-20EE-4C40-AE56-58F10D2FA633@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-11 14:41:49',0,'2013-10-11 14:41:49',NULL,'[openstack-dev] [Hyper-V] Havana status','\n\nOn Oct 11, 2013, at 17:17 , Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>>\n wrote:\n\nOn 10/11/2013 09:02 AM, Alessandro Pilotti wrote:\nOpenStack is organized differently: there are lots of separate projects (Nova, Neutrom, Glance, etc) instead of a single one (which is a good thing), but I believe that a similar approach can be applied. Specific contributors can be nominated \"core rewievers\" on specific directories in the tree only and that would scale immediately the core review bandwidth.\n\nAs a practical example for Nova: in our case that would simply include the following subtrees: \"nova/virt/hyperv\" and \"nova/tests/virt/hyperv\". Other projects didn\'t hit the review bandwidth limits yet as heavily as Nova did, but the same concept could be applied everywhere.\n\nIf maintainers of a particular driver would prefer this sort of\nautonomy, I\'d rather look at creating new repositories.  I\'m completely\nopen to going that route on a per-driver basis.  Thoughts?\n\nWell, as long as it is an official project this would make definitely sense, at least for Hyper-V.\nStability of the driver\'s interface has never been a particular issue to prevent this to happen IMO.\nWe should think about how to handle the testing, considering that we are getting ready with the CI gate.\n\nFor the main tree, I think we already do something like this in\npractice.  Core reviewers look for feedback (+1/-1) from experts of that\ncode and take it heavily into account when doing the review.\n\n\nThere\'s only one \"small\" issue with the current approach.\n\nCurrent reviews require:\n\n+1 \"de facto\" driver X mantainer(s)\n+2  core reviewer\n+2A  core reviewer\n\nWhile with the proposed scenario we\'d get to a way faster route:\n\n+2  driver X mantainer\n+2A another driver X mantainer or a core reviewer\n\nThis would make a big difference in terms of review time.\n\nThanks,\n\nAlessandro\n\n\n--\nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131011/53ba9d4f/attachment.html>\n\n','<52580888.1010505@redhat.com>',NULL),('<01a84aec7df8437e8d0df73a1099affe@DM2PR42MB014.048d.mgd.msft.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-23 09:06:16',0,'2015-01-23 09:06:16',NULL,'[Openstack] [openstack] Heat autoscaling stack creation failed for\n	normal user','Hello all,\n\nI was trying to launch a autoscaling template from a normal user. But it\'s able to create a vm but not the autoscaling policy with the below error. ( For admin it will work)\n\n2015-01-23 09:22:58.341 14671 INFO heat.engine.stack [-] Stack CREATE FAILED (ms): Resource CREATE failed: Forbidden: You are not authorized to perform the request (HTTP 403)\n2015-01-23 09:22:58.342 14671 INFO heat.engine.service [-] Stack create failed, status FAILED\n\n2015-01-23 09:23:01.599 14671 WARNING heat.common.keystoneclient [req-15384a8a-ed2a-42f4-a5e9-2d3628d4bb8f None] stack_user_domain_id or stack_user_domain_namusing default\n2015-01-23 09:23:01.601 14671 INFO urllib3.connectionpool [req-15384a8a-ed2a-42f4-a5e9-2d3628d4bb8f ] Starting new HTTP connection (1): Control\n2015-01-23 09:23:03.937 14671 WARNING heat.common.keystoneclient [req-a30339d3-9715-4146-b2d9-a08e25d0a45c None] stack_user_domain_id or stack_user_domain_namusing default\n2015-01-23 09:23:03.940 14671 INFO urllib3.connectionpool [req-a30339d3-9715-4146-b2d9-a08e25d0a45c ] Starting new HTTP connection (1): Control\n2015-01-23 09:23:04.012 14671 WARNING heat.common.keystoneclient [req-d66943f2-2037-4d41-ae7a-c75959c074af None] stack_user_domain_id or stack_user_domain_namusing default\n\n>From the dashboard:\n\nWeb_server_scaledown_policy               OS::Heat::ScalingPolicy                25 minutes         Create Failed     Forbidden: You are not authorized to perform the requested action: identity:list_roles (HTTP 403)\n\nHow to create a HEAT_DOMAIN_ID?\n\nWarm Regards,\nMalleshi CN\n\n\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150123/d7248c94/attachment.html>\n\n',NULL,NULL),('<01A96DAD-4074-426F-8CBA-24DDE896FD36@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-17 23:40:27',-25200,'2014-06-18 06:40:27',NULL,'[Openstack] Horizon can\'t not login','You will never use this type of installation in production. But yes it allows you to learn. \n\nRemo\n\nInviato da iPhone (?)\n\n> Il giorno Jun 17, 2014, alle ore 23:25, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Because\n> 1.        there is no need to use Packstack at all.\n> 2.       I want to learn what?s the configuration change in icehouce.\n> 3.       Separate installation processes.\n> 4.       So on ?\n>  \n>  \n> From: Remo Mattei [mailto:remo at italy1.com] \n> Sent: Wednesday, June 18, 2014 2:23 PM\n> To: Li, Chen\n> Cc: <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Horizon can\'t not login\n>  \n> Ouch why? \n>  \n>  \n> \n> Inviato da iPhone (?)\n> \n> Il giorno Jun 17, 2014, alle ore 23:20, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Sorry. I have installed all packages by hand.\n> Not using packstack at all.\n>  \n> Also, without GUI, all commands are working fine.\n>  \n>  \n> From: Remo Mattei [mailto:remo at italy1.com] \n> Sent: Wednesday, June 18, 2014 2:18 PM\n> To: Li, Chen\n> Cc: <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Horizon can\'t not login\n>  \n> It is on your shell where your run the packstack install \n> \n> Inviato da iPhone (?)\n> \n> Il giorno Jun 17, 2014, alle ore 23:09, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Where can I find the keystone_admin file ???\n>  \n> From: Remo Mattei [mailto:remo at italy1.com] \n> Sent: Wednesday, June 18, 2014 2:07 PM\n> To: Li, Chen\n> Cc: <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Horizon can\'t not login\n>  \n> You should have a file called keystone_admin with the pass of your dashboard try that. \n>  \n> Remo\n> \n> Inviato da iPhone (?)\n> \n> Il giorno Jun 17, 2014, alle ore 22:28, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Hi list,\n>  \n> I just installed a fresh new Horizon on CentOS.\n> My kernel is ?2.6.32-358.el6.x86_64?.\n> And the version of horizon:\n> openstack-dashboard.noarch                        2014.1-1.el6    @openstack-icehouse\n>  \n> When I trying to login , I get error.\n> Here is what I get from /var/log/httpd/error_log:\n> http://paste.openstack.org/show/84366/\n>  \n> Based on https://ask.openstack.org/en/question/6180/unable-to-login-to-openstack-dashboard-havana/\n> I already disabled SELinux and also changed  \n> OPENSTACK_KEYSTONE_DEFAULT_ROLE = \"admin\"\n> \n>  \n> Here is my /etc/openstack-dashboard/local_settings:\n> http://paste.openstack.org/show/84365/\n>  \n> Anyone know why this happened ???\n>  \n> Thanks.\n> -chen\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n> !DSPAM:1,53a12fc2148291377437528!\n> !DSPAM:1,53a1310d151812237138763!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140617/b8b68515/attachment.html>\n\n','<988E98D31B01E44893AF6E48ED9DEFD401B3D8F1@SHSMSX101.ccr.corp.intel.com>',NULL),('<01B838A3-AE93-49D7-94E3-2D601D3C52D7@mcclain.xyz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 16:20:28',-18000,'2015-02-02 21:20:28',NULL,'[openstack-dev] [Neutron] Multiple template libraries being\n	used in tree','You?re right that the Mako dependency is really a side effect from Alembic.  We used jinja for tempting radvd because it is used by the projects within the OpenStack ecosystem and also used in VPNaaS.\n\nmark\n\n\n> On Feb 2, 2015, at 3:13 PM, Sean M. Collins <sean at coreitpro.com> wrote:\n> \n> Sorry, I should have done a bit more grepping before I sent the e-mail,\n> since it appears that Mako is being used by alembic.\n> \n> http://alembic.readthedocs.org/en/latest/tutorial.html\n> \n> So, should we switch the radvd templating over to Mako instead?\n> \n> -- \n> Sean M. Collins\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<0000014b4beccf61-f985d1d9-de03-442f-9037-61abe768f3b2-000000@email.amazonses.com>',NULL),('<01B86A7C-EF35-4711-948D-042EAB5D6738@siliconloons.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 14:25:12',-21600,'2014-02-11 20:25:12',NULL,'[openstack-dev] [neutron] [group-policy] Changing the meeting\n	time','FYI, I?ve made the change on the meeting pages as well [1]. The Neutron\nGroup Policy meeting is now at 1700UTC Thursday?s on #openstack-meeting-alt.\n\nThanks!\nKyle\n\n[1] https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting\n\nOn Feb 11, 2014, at 11:30 AM, Sumit Naiksatam <sumitnaiksatam at gmail.com> wrote:\n\n> Hi Kyle,\n> \n> The new time sounds good to me as well, thanks for initiating this.\n> \n> ~sumit.\n> \n> On Tue, Feb 11, 2014 at 9:02 AM, Stephen Wong <s3wong at midokura.com> wrote:\n>> Hi Kyle,\n>> \n>>    Almost missed this - sounds good to me.\n>> \n>> Thanks,\n>> - Stephen\n>> \n>> \n>> \n>> On Mon, Feb 10, 2014 at 7:30 PM, Kyle Mestery <mestery at siliconloons.com>\n>> wrote:\n>>> \n>>> Folks:\n>>> \n>>> I\'d like to propose moving the Neutron Group Policy meeting going\n>>> forward, starting with this Thursday. The meeting has been at 1600\n>>> UTC on Thursdays, I\'d like to move this to 1700UTC Thursdays\n>>> on #openstack-meeting-alt. If this is a problem for anyone who\n>>> regularly attends this meeting, please reply here. If I don\'t hear\n>>> any replies by Wednesday, I\'ll officially move the meeting.\n>>> \n>>> Thanks!\n>>> Kyle\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAMWrLvid8xATS5yHbLP3qtzpitPehqUKSzAFpYARR3Rk_7JV1Q@mail.gmail.com>',NULL),('<01B98BEE-38D1-4E2D-A763-D6ABCC8EB345@av.it.pt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-26 20:31:18',3600,'2014-05-26 19:31:18',NULL,'[openstack-dev] [ceilometer] Unit Testing for Agents','Hello Stackers,\n\nDisclaimer: I\'m on a quest to develop a new agent, already have coding a few lines. The next step is Unit Testing and enabling me to create a patch to test on a devstack. So, this is what brings me here, the need to understand and learn the best-pratices or rules to develop Unit Tests on the Ceilometer project.\n\nI probably should mention that my Unit Tests knowledge should be classified as Basic (on a Java environment). I could synthesise it as: \"I need to create a block the code and assert the output against with I expected\". \nIn this project seems a little bit more complex.\nI have read it about Mock and Fixtures, the first one nevertheless the complexity it\'s much more easy to read and understand.\n\nI will try to put this problem simply as possible.\nI have analyze several files:\nceilometer/central/test_manager.py\nceilometer/compute/test_manager.py\nceilometer/compute/pollsters/test_cpu.py\nceilometer/agentbase.py\nceilometer/base.py\nAnd I need to confess I\'m a little lost on this part. I have realised that I should create a test for the manager and for every pollster and to the plugin if I think it is necessary.\nSo that being said, I infered the following topics:\non my test_manager.py I should declare two classes: TestManager and TestRunTasks\nthe first one should be responsible by test the manager.py of my agent, with \'test_load_plugins\' verify if there is any pollster associated to this agent (seems to be straightforward)\nthe second one should be responsible by test the pollsters/*.py of my agent and in this case the things complicate a little bit...\nHave I infered correctly? Anyone disagrees?\n\nMoving forward...\nFollowing the code on ceilometer/{central, compute}/test_manager.py, the method setUp(...) raises some questions, why to use setUp if we have already have a create_manager(...)? Should be for creating samples/alarms?\nI have already figure out that .useFixture() comes from fixtures package: \"The method useFixture will use another fixture, call setUp on it, call self.addCleanup(thefixture.cleanUp), attach any details from it and return the fixture. This allows simple composition of different fixtures.\"\nAgain, lost! Where are declarations of agents/ceilometer fixtures? How should I use them?\n\nAfter that every test_* in TestRunTasks should execute a different test on which data? In every of them I must create the sample?\n\nWhere do I test the get_samples(), publish(), pipepline(sources, sinks) matters? In this files too?\n\nI appreciate a lot your atention and patience with me. Thank you in advance.\nBest Regards,\nPaulo J. Nascimento Oliveira\nhttp://about.me/pnascimento\nAdvanced Telecommunications and Networks Group - http://atnog.av.it.pt\nFollow us - @ATNoG_ITAv\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140526/5cbd6041/attachment.html>\n\n',NULL,NULL),('<01B99F98-D06E-4599-8B43-A39B9AF0A420@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-04 17:31:19',-25200,'2012-09-05 00:31:19',NULL,'[openstack-dev] Is volume attachment to an LXC instance is\n	broken?','Potential fix here: https://review.openstack.org/#/c/12384/\n\nVish\n\nOn Sep 4, 2012, at 1:18 PM, David Kang <dkang at isi.edu> wrote:\n\n> \n> \n> mysql DB shows that \'root_device_name\' of an LXC instance is set as \"/dev/a\".\n> I believe it is a bug.\n> Let me file it as a bug.\n> \n> David\n> \n> ----- Original Message -----\n>> This looks like a recent bug. Lxc may not be setting root_device_path\n>> in the block device mapping table. It is now using root_device_path to\n>> set the path for the volumes. We may need to supply a fallback if it\n>> isn\'t set.\n>> \n>> Vish\n>> \n>> On Sep 4, 2012, at 11:00 AM, David Kang <dkang at isi.edu> wrote:\n>> \n>>> \n>>> Is volume attachment to an LXC instance is broken?\n>>> \n>>> I\'m trying to run the following command:\n>>> $ euca-attach-volume vol-00000007 -i i-0000000b -d /dev/vdc\n>>> \n>>> It fails and the nova-compute log is copied and pasted below.\n>>> The error message is :\n>>>  \"InvalidDevicePath: The supplied device path (/dev/a) is invalid.\"\n>>> The device name given is \"/dev/vdc\", but it looks like that\n>>> get_device_name_for_instance()\n>>> changes it to \'/dev/a\'.\n>>> And it ends up the error of \"InvalidDevicePath\".\n>>> \n>>> Is it bug or my mistake?\n>>> I pulled the nova from github on August 29th.\n>>> And the followings are configured in /etc/nova/nova.conf file.\n>>>  use_cow_images=True\n>>>  libvirt_type=lxc\n>>> \n>>> Thanks,\n>>> David\n>>> \n>>> ------------- log of nova-compute ---------------\n>>> \n>>> 2012-09-04 13:37:46 DEBUG nova.utils\n>>> [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Got semaphore\n>>> \"f3fb4350-a72e-404f-a21f-10f333fe67e8\" for method \"do_reserve\"...\n>>> from (pid=13108) inner /usr/local/nova/nova/utils.py:712\n>>> 2012-09-04 13:37:46 DEBUG nova.utils\n>>> [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Attempting to\n>>> grab semaphore \"compute_resources\" for method\n>>> \"update_load_stats_for_instance\"... from (pid=13108) inner\n>>> /usr/local/nova/nova/utils.py:708\n>>> 2012-09-04 13:37:46 DEBUG nova.utils\n>>> [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Got semaphore\n>>> \"compute_resources\" for method \"update_load_stats_for_instance\"...\n>>> from (pid=13108) inner /usr/local/nova/nova/utils.py:712\n>>> 2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.amqp [-]\n>>> Exception during message handling\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp Traceback\n>>> (most recent call last):\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in\n>>> _process_data\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp rval =\n>>> self.proxy.dispatch(ctxt, version, method, **args)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145,\n>>> in dispatch\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp return\n>>> getattr(proxyobj, method)(ctxt, **kwargs)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp temp_level,\n>>> payload)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> self.gen.next()\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp return\n>>> f(*args, **kw)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 211, in\n>>> decorated_function\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp pass\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> self.gen.next()\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 204, in\n>>> decorated_function\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp return\n>>> function(self, context, *args, **kwargs)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 237, in\n>>> decorated_function\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> instance_uuid, e, sys.exc_info())\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> self.gen.next()\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 226, in\n>>> decorated_function\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp return\n>>> function(self, context, *args, **kwargs)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 2057, in\n>>> reserve_block_device_name\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp return\n>>> do_reserve()\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/utils.py\", line 733, in inner\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp retval =\n>>> f(*args, **kwargs)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 2051, in do_reserve\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp device)\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp File\n>>> \"/usr/local/nova/nova/compute/utils.py\", line 56, in\n>>> get_device_name_for_instance\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp raise\n>>> exception.InvalidDevicePath(path=mappings[\'root\'])\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> InvalidDevicePath: The supplied device path (/dev/a) is invalid.\n>>> 2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n>>> 2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.common [-]\n>>> Returning exception The supplied device path (/dev/a) is invalid. to\n>>> caller\n>>> 2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.common [-]\n>>> [\'Traceback (most recent call last):\\n\', \' File\n>>> \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in\n>>> _process_data\\n rval = self.proxy.dispatch(ctxt, version, method,\n>>> **args)\\n\', \' File\n>>> \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145,\n>>> in dispatch\\n return getattr(proxyobj, method)(ctxt, **kwargs)\\n\', \'\n>>> File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\\n\n>>> temp_level, payload)\\n\', \' File\n>>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n\n>>> self.gen.next()\\n\', \' File \"/usr/local/nova/nova/exception.py\", line\n>>> 92, in wrapped\\n return f(*args, **kw)\\n\', \' File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 211, in\n>>> decorated_function\\n pass\\n\', \' File\n>>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n\n>>> self.gen.next()\\n\', \' File\n>>> \"/usr/local/nova/nova/compute/manager.py\", line 204, in\n>>> decorated_function\\n return function(self!\n>> , context, *args, **kwargs)\\n\', \' File\n>> \"/usr/local/nova/nova/compute/manager.py\", line 237, in\n>> decorated_function\\n instance_uuid, e, sys.exc_info())\\n\', \' File\n>> \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n\n>> self.gen.next()\\n\', \' File \"/usr/local/nova/nova/compute/manager.py\",\n>> line 226, in decorated_function\\n return function(self, context,\n>> *args, **kwargs)\\n\', \' File \"/usr/local/nova/nova/compute/manager.py\",\n>> line 2057, in reserve_block_device_name\\n return do_reserve()\\n\', \'\n>> File \"/usr/local/nova/nova/utils.py\", line 733, in inner\\n retval =\n>> f(*args, **kwargs)\\n\', \' File\n>> \"/usr/local/nova/nova/compute/manager.py\", line 2051, in do_reserve\\n\n>> device)\\n\', \' File \"/usr/local/nova/nova/compute/utils.py\", line 56,\n>> in get_device_name_for_instance\\n raise\n>> exception.InvalidDevicePath(path=mappings[\\\'root\\\'])\\n\',\n>> \'InvalidDevicePath: The supplied device path (/dev/a) is invalid.\\n\']\n>>> \n>>> \n>>> \n>>> ----------------------\n>>> Dr. Dong-In \"David\" Kang\n>>> Computer Scientist\n>>> USC/ISI\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1934057091.882849.1346789892388.JavaMail.root@zm.isi.edu>',NULL),('<01ba01ce9171$8945ad60$9bd10820$@mxs.nes.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-05 09:20:06',32400,'2013-08-05 00:20:06',NULL,'[openstack-dev] [Nova] Review request: Blurprint of API\n	validation','\nHi Russell, Doug,\n\nThanks for your comments, I\'m really glad to talk about this with you.\n\n> -----Original Message-----\n> From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com]\n> Sent: Saturday, August 03, 2013 6:14 AM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Nova] Review request: Blurprint of API validation\n> \n> \n> \n> \n> On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant <rbryant at redhat.com> wrote:\n> \n> \n> 	On 07/09/2013 07:45 AM, Ken\'ichi Ohmichi wrote:\n> 	>\n> 	> Hi,\n> 	>\n> 	> The blueprint \"nova-api-validation-fw\" has not been approved yet.\n> 	> I hope the core patch of this blueprint is merged to Havana-2,\n> 	> because of completing comprehensive API validation of Nova v3 API\n> 	> for Havana release. What should we do for it?\n> \n> \n> 	I apologize for taking so long to address this.\n> \n> 	Here is my current take on this based on reviewing discussions, code,\n> 	and talking to others about it.\n> \n> 	From a high level, API input validation is obviously a good thing.\n> 	Having a common framework to do it is better.  What complicates this\n> 	submission is the effort to standardize on Pecan/WSME for APIs\n> 	throughout OpenStack.\n> \n> 	We\'ve discussed WSME and jsonschema on the mailing list.  There are\n> 	perhaps some things that can be expressed using jsonschema, but not WSME\n> 	today.  So, there are some notes on\n> 	https://etherpad.openstack.org/NovaApiValidationFramework showing how\n> 	the two could be used together at some point.  However, I don\'t think\n> 	it\'s really desirable long term.  It seems a bit awkward, and some\n> 	information gets duplicated.\n> \n> 	We had previously established that using WSME was the long term goal\n> 	here.  Going forward with jsonschema with the current nova APIs is a\n> 	benefit in the short term, but I do not think it\'s necessarily in\n> 	support of the long term goal if there isn\'t consensus that combining\n> 	WSME+jsonschema is a good idea.\n> \n> 	This sort of thing affects a lot of code, so the direction is important.\n> 	 I do not think we should proceed with this.  It seems like the best\n> 	thing to do that helps the long term goal is to work on migrating our\n> 	API to WSME.   In particular, I think we could do this for the v3 API,\n> 	since it\'s not going to be locked down until Icehouse.  At the same\n> 	time, we should contribute back to WSME to add the features we feel are\n> 	missing to allow the types of validation we would like to do.\n> \n> 	If there is significant disagreement with this decision, I\'m happy to\n> 	continue talking about it.  However, I really want to see consensus on\n> 	this and how it fits in with the long term goals before moving forward.\n> \n> \n> \n> When we discussed this earlier, there was concern about moving to a\n> completely new toolset for the new API in Havana because of other\n> changes going on at the same time (something to do with extensions, IIRC).\n> I agreed it made sense to stick with our current tools to avoid adding\n> risk to the schedule. If that schedule has slipped into the next release,\n> or if you feel there is time after all, then I would also prefer to go\n> ahead with the general consensus reached at the Havana summit and use WSME.\n> \n> Given a little time, I think we can come up with something better than the\n> method of combining WSME and jsonschema proposed in the etherpad linked\n> above, which effectively requires us to declare the types of the parameters\n> twice in different formats. As Russell said, if we need to add to WSME to\n> make it easier to use, we should do that.\n\nThat\'s a good point. The sample code on the etherpad[1] requires to\ndefine API schema twice for single API, and that would be workload\nagainst implementing API schema when Pecan/WSME has been used.\n\nSo how about adding jsonschema support to WSME?\n\nIf doing that, we will be able to use good validation based on jsonschema\nonly by defining a single API schema.\n\n\n> I am working on getting WSME onto stackforge, to make contributions easier\n> (it\'s on bitbucket now, but using hg and pull requests is pretty different\n> from our normal review process and may add friction for some people).\n\nThat would be good info, if the above idea gets consensus.\nI will start investigating how to implement jsonschema support for WSME\nafter this discussion, and try contributing the above stackforge WSME.\n\n\n> We ran into a few tricky spots because of the wide variety of test configu-\n> rations in play, and that caused some delays. I think those issues are\n> worked out (especially with the Python 3.3 build systems available now),\n> so I will be picking that work up in a week or two (I\'m traveling next week).\n\nHave a good travell:-)\n\nThanks\nKen\'ichi Ohmichi\n\n---\n[1]: https://etherpad.openstack.org/NovaApiValidationFramework\n\n\n\n',NULL,NULL),('<01BB72CA-262A-456F-9656-6B95E330DAF3@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 12:10:00',-14400,'2014-08-27 16:10:00',NULL,'[openstack-dev] [oslo] review priorities','I *believe* we have started work on all of the graduations we are likely to complete during Juno. I suggest we start focusing our efforts on reviews related to the other outstanding blueprints and critical bugs. I see a lot of open patches for taskflow, for example.\n\nDoug\n\n\n\n',NULL,NULL),('<01C6D68B-1EC6-42B0-B3D2-600EE10042F8@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 23:32:23',25200,'2014-05-05 16:32:23',NULL,'[openstack-dev] [mistral] Community meeting minutes/log - 05/05/2014','Thanks for joining us today.\n\nMeeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-05-05-16.00.html\nFull log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-05-05-16.00.log.html\n\nMy suggestion would be to skip the next two meetings due to Summit activities and have the next meeting on May 26th. Thoughts?\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140505/cb4bcfd8/attachment.html>\n\n',NULL,NULL),('<01CA1FD9677640E586E174A42623CDA6@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 16:23:00',-14400,'2013-04-26 20:23:00',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','> \n> HMAC(metadata, Ea(SEK, Eb(SEK)))\n> \n\nThe problem is that Eb(SEK) isn\'t signed. You sign Ea(), but you can\'t send that to B, because B can\'t decrypt it. Thus, you\'re only sending Eb(SEK).\n\nWhen B receives Eb(SEK), it cannot validate it.  You would need to receive from the keyserver:\n\nSa(metadata, Ea(SEK, Sb(Eb(SEK))))\n\nThen, you can send to B:  Sb(Eb(SEK)))\n\nRegards,\nEric Windisch\n\n\n\n\n\n','<1367006727.10084.417.camel@willson.li.ssimo.org>',NULL),('<01D0284A-D81C-402E-893D-CB13DED53AAA@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 18:13:19',-18000,'2014-12-05 23:13:19',NULL,'[openstack-dev] Mike Bayer 20141205','1. Alembic release - I worked through some regressions introduced by Alembic 0.7.0 and the subsequent 0.7.1 with the Neutron folks.  This started on Monday with https://review.openstack.org/#/c/137989/, and by Wednesday I had identified enough small regressions in 0.7.0 that I had to put 0.7.1 out, so that review got expedited with https://review.openstack.org/#/c/138998/ following from Neutron devs to continue fixing.   Version 0.7.1 includes the foreign key autogenerate support first proposed by Ann Kamyshnikova.  Changelog at http://alembic.readthedocs.org/en/latest/changelog.html#change-0.7.1.\n\n2. MySQL driver stuff.   I have a SQLAlchemy user who is running some kind of heavy load with gevent and PyMySQL.  While this user is not openstack-specific, the thing he is doing is a lot like what we might be doing if and when we move our MySQL drivers to MySQL-connector-Python, which is compatible with eventlet in that it is pure Python and can be monkeypatched.    The issue observed by this user applies to both PyMySQL and MySQL-connector, and I can reproduce it *without* using SQLAlchemy, though it does use a very makeshift connection pool designed to approximate what SQLAlchemy?s does.   The issue is scary because it illustrates Python code that should have been killed being invoked on a database connection that should have been dead, calling commit(), and then actually *succeeding* in committing only *part* of the data.   This is not an issue that impacts Openstack right now but if the same thing applies to eventlet, then this would definitely be something we?d need to worry about if we start using MySQL-connector in a high load scenario (which has been the plan) so I?ve forwarded my findings onto openstack-dev to see if anyone can help me understand it.  The intro + test case for this issue starts at http://lists.openstack.org/pipermail/openstack-dev/2014-December/052344.html. \n\n3. enginefacade - The engine facade as I described in https://review.openstack.org/#/c/125181/, which we also talked about on the Nova compute call this week, is now built!  I spent monday and tuesday on the buildout for this, and that can be seen and reviewed here: https://review.openstack.org/#/c/138215/  As of today I?m still nursing it through CI, as even with projects using the ?legacy? APIs, they are still finding lots of little silly things that I keep having to fix (people calling the old EngineFacade with arguments I didn?t expect, people importing from oslo.db in an order I did not expect, etc).  While these consuming projects could be fixed to not have these little issues, for now I am trying to push everything to work as identically as possible to how it was earlier, when the new API is not explicitly invoked.   I?ll be continuing to get this to pass all tempest runs through next week.\n\nFor enginefacade I?d like the folks from the call to take a look, and in particular if Matthew Booth wants to look into it, this is ready to start being used for prototyping Nova with it.\n\n4. Connectivity stuff - today I worked a bunch with Viktor Sergeyev who has been trying to fix an issue with MySQL OperationalErrors that are raised when the database is shut off entirely; in oslo.db we have logic that wraps all exceptions unconditionally, including that it identifies disconnect exceptions.  In the case where the DB throws a disconnect, and we loop around to ?retry? this query in order to get it to reconnect, then that reconnect continues to fail, the second run doesn?t get wrapped.   So today I?ve fixed both the upstream issue for SQLAlchemy 1.0, and also made a series of adjustments to oslo.db to accommodate SQLAlchemy 1.0?s system correctly as well as to work around the issue when SQLAlchemy < 1.0 is present.   That?s a three-series of patches that are unsurprisingly going to take some nursing to get through the gate, so I?ll be continuing with that next week.  This series starts at https://review.openstack.org/139725 https://review.openstack.org/139733 https://review.openstack.org/139738 .\n\n5. SQLA 1.0 stuff. - getting SQLAlchemy 1.0 close to release is becoming critical so I?ve been moving around issues and priorities to expedite this.  There?s many stability enhancements oslo.db would benefit from as well as some major performance-related features that I?ve been planning all along to introduce to projects.   1.0 is very full of lots of changes that aren?t really being tested outside of my own CI, so getting something out the door on it is key, otherwise it will just be too different from 0.9 in order for people to have smooth upgrades.   I do run SQLA 1.0 in CI against a subset of Neutron, Nova, Keystone and Oslo tests so we should be in OK shape, but there is still a lot to go.  Work completed so far can be seen at http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html.  \n\n\n\n',NULL,NULL),('<01D0E2E6-6AC6-4DA8-B297-CFFB0DA16F55@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 10:48:13',-14400,'2014-08-26 14:48:13',NULL,'[openstack-dev] [all] [ptls] The Czar system,\n	or how to scale PTLs','\nOn Aug 26, 2014, at 10:10 AM, Kyle Mestery <mestery at mestery.com> wrote:\n\n> On Fri, Aug 22, 2014 at 8:19 PM, John Dickinson <me at not.mn> wrote:\n>> I think Anne makes some excellent points about the pattern being proposed being unlikely to be commonly implemented across all the programs (or, at best, very difficult). Let\'s not try to formalize another \"best practice\" that works many times and force it to work every time. Here\'s an alternate proposal:\n>> \n>> Let\'s let PTLs be PTLs and effectively coordinate and manage the activity in their respective projects. And let\'s get the PTLs together for one or two days every cycle to discuss project issues. Just PTLs, and let\'s focus on the project management stuff and some cross-project issues.\n>> \n>> Getting the PTLs together would allow them to discuss cross-project issues, share frustrations and solutions about what does and doesn\'t work. Basically, think of it as a mid-cycle meetup, but for PTLs. (Perhaps we could even ask the Foundation to sponsor it.)\n>> \n> +100\n> \n> I think John nails the key point here: PTLs are likely already doing a\n> lot of what Thierry originally proposed here. I know that I work with\n> many people in Neutron to help offload things like bug triaging, gate\n> failure analysis, etc. Without that, Neutron wouldn\'t scale. In effect\n> what\'s proposed here is something we\'re already doing a lot of. I\n> don\'t think forcing this on each project is a good way of doing this,\n> because each project has different challenges and needs.\n\nThis proposal isn?t about how teams are organized internally; it?s about how they interface with the other OpenStack teams.\n\nThe cross-project teams need more direct coordination and participation than we are getting from some projects, and so we want the projects and PTLs to recognize that the areas Thierry has listed are responsibilities that need to be met. Someone needs to do these basic coordination tasks in order for the overall project to be successful. It?s up to each team to decide who fills a given role, but by identifying these points of contact the other teams don?t have to know that you make those decisions by asking for volunteers, holding an election, or drawing straws.\n\nDoug\n\n> \n> Thanks,\n> Kyle\n> \n>> --John\n>> \n>> \n>> \n>> \n>> \n>> On Aug 22, 2014, at 6:02 PM, Anne Gentle <anne at openstack.org> wrote:\n>> \n>>> \n>>> \n>>> \n>>> On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober <rochelle.grober at huawei.com> wrote:\n>>> /flame-on\n>>> Ok, this is funny to some of us in the community.  The general populace of this community is so against the idea of management that they will use the term for a despotic dictator as a position name rather than \"manager\".  Sorry, but this needed to be said.\n>>> /flame-off\n>>> \n>>> Specific comments in line:\n>>> \n>>> Thierry Carrez wrote:\n>>>> \n>>>> Hi everyone,\n>>>> \n>>>> We all know being a project PTL is an extremely busy job. That\'s\n>>>> because\n>>>> in our structure the PTL is responsible for almost everything in a\n>>>> project:\n>>>> \n>>>> - Release management contact\n>>>> - Work prioritization\n>>>> - Keeping bugs under control\n>>>> - Communicate about work being planned or done\n>>>> - Make sure the gate is not broken\n>>>> - Team logistics (run meetings, organize sprints)\n>>>> - ...\n>>>> \n>>> \n>>> Point of clarification:  I\'ve heard PTL=Project Technical Lead and PTL=Program Technical Lead. Which is it?  It is kind of important as OpenStack grows, because the first is responsible for *a* project, and the second is responsible for all projects within a program.\n>>> \n>>> \n>>> Now Program, formerly Project.\n>>> \n>>> I\'d also like to set out as an example of a Program that is growing to encompass multiple projects, the Neutron Program.  Look at how it is expanding:\n>>> \n>>> Multiple sub-teams for:  LBAAS, DNAAS, GBP, etc.  This model could be extended such that:\n>>> - the subteam is responsible for code reviews, including the first +2 for design, architecture and code of the sub-project, always also keeping an eye out that the sub-project code continues to both integrate well with the program, and that the program continues to provide the needed code bits, architecture modifications and improvements, etc. to support the sub-project.\n>>> - the final +2/A would be from the Program reviewers to ensure that all integrate nicely together into a single, cohesive program.\n>>> - This would allow sub-projects to have core reviewers, along with the program and be a good separation of duties.  It would also help to increase the number of reviews moving to merged code.\n>>> - Taken to a logical stepping stone, you would have project technical leads for each project, and they would make up a program council, with the program technical lead being the chair of the council.\n>>> \n>>> This is a way to offload a good chunk of PTL tactical responsibilities and help them focus more on the strategic.\n>>> \n>>>> They end up being completely drowned in those day-to-day operational\n>>>> duties, miss the big picture, can\'t help in development that much\n>>>> anymore, get burnt out. Since you\'re either \"the PTL\" or \"not the PTL\",\n>>>> you\'re very alone and succession planning is not working that great\n>>>> either.\n>>>> \n>>>> There have been a number of experiments to solve that problem. John\n>>>> Garbutt has done an incredible job at helping successive Nova PTLs\n>>>> handling the release management aspect. Tracy Jones took over Nova bug\n>>>> management. Doug Hellmann successfully introduced the concept of Oslo\n>>>> liaisons to get clear point of contacts for Oslo library adoption in\n>>>> projects. It may be time to generalize that solution.\n>>>> \n>>>> The issue is one of responsibility: the PTL is ultimately responsible\n>>>> for everything in a project. If we can more formally delegate that\n>>>> responsibility, we can avoid getting up to the PTL for everything, we\n>>>> can rely on a team of people rather than just one person.\n>>>> \n>>>> Enter the Czar system: each project should have a number of liaisons /\n>>>> official contacts / delegates that are fully responsible to cover one\n>>>> aspect of the project. We need to have Bugs czars, which are\n>>>> responsible\n>>>> for getting bugs under control. We need to have Oslo czars, which serve\n>>>> as liaisons for the Oslo program but also as active project-local oslo\n>>>> advocates. We need Security czars, which the VMT can go to to progress\n>>>> quickly on plugging vulnerabilities. We need release management czars,\n>>>> to handle the communication and process with that painful OpenStack\n>>>> release manager. We need Gate czars to serve as first-line-of-contact\n>>>> getting gate issues fixed... You get the idea.\n>>>> \n>>> /flame-on\n>>> Let\'s call spades, spades here.  Czar is not only overkill, but the wrong metaphor.\n>>> /flame-off\n>>> \n>>> I\'m with Rocky on the anti-czar-as-a-word camp. We all like clever names to shed the \"corporate\" stigma but this word ain\'t it. Liaison or lead?\n>>> \n>>> Also wanted to point to https://wiki.openstack.org/wiki/PTLguide as it\'s quite nice.\n>>> \n>>> I think PTLs tend to find help when they absolutely are ready to fall over, and I\'m all for a plan that helps us not fall over. I\'ve had people step up for bug triaging, gate work, tests, and oslo, sometimes one person did three or four at once. I certainly can\'t do it all for cross-project. Based on what I\'ve seen, I doubt that we can add this much formality to this across 20+ programs. It\'s the \"bigger more integrated project\" vs. \"smaller more focused project\" difference that won\'t let us do a pattern here. We can certainly document the responsibilities and let programs know there are some best practices.\n>>> \n>>> Anne\n>>> \n>>> \n>>> Each position suggested here exists in corporate development projects:\n>>> - Bug czar == bug manager/administrator/QA engineer/whatever - someone in charge of making sure bugs get triages, assigned and completed\n>>> - Oslo czar == systems engineers/project managers who make sure that the project is in line with the rest of the projects that together make an integrated release.  This position needs to stretch beyond just Oslo to encompass all the cross-project requirements and will likely be its own \"committee\"\n>>> - Gate Czar == integration engineer(manager)/QA engineer(manager)/build-release engineer.  This position would also likely be a liaison to Infra.\n>>> - Security Czar == security guru (that name takes me back ;-)\n>>> - Release management Czar == Project release manager\n>>> - Doc Czar == tech editor\n>>> - Tempest Czar == QA engineer(manager)\n>>> \n>>> Yes, programs are now mostly big enough to require coordination and management.  The roles are long defined, so let\'s just document the definitions and get volunteers.  Each project would be able to decide which roles needed to be filled and whether individuals are capable of filling multiple roles.\n>>> \n>>> These roles need to be transparent in a governance sense and should be increasing communication between projects, community and contributors.\n>>> \n>>>> Some people can be czars of multiple areas. PTLs can retain some czar\n>>>> activity if they wish. Czars can collaborate with their equivalents in\n>>>> other projects to share best practices. We just need a clear list of\n>>>> areas/duties and make sure each project has a name assigned to each.\n>>>> \n>>>> Now, why czars ? Why not rely on informal activity ? Well, for that\n>>>> system to work we\'ll need a lot of people to step up and sign up for\n>>>> more responsibility. Making them \"czars\" makes sure that effort is\n>>>> recognized and gives them something back. Also if we don\'t formally\n>>>> designate people, we can\'t really delegate and the PTL will still be\n>>>> directly held responsible. The Release management czar should be able\n>>>> to\n>>>> sign off release SHAs without asking the PTL. The czars and the PTL\n>>>> should collectively be the new \"project drivers\".\n>>>> \n>>>> At that point, why not also get rid of the PTL ? And replace him with a\n>>>> team of czars ? If the czar system is successful, the PTL should be\n>>>> freed from the day-to-day operational duties and will be able to focus\n>>>> on the project health again. We still need someone to keep an eye on\n>>>> the\n>>>> project-wide picture and coordinate the work of the czars. We need\n>>>> someone to pick czars, in the event multiple candidates sign up. We\n>>>> also\n>>>> still need someone to have the final say in case of deadlocked issues.\n>>>> \n>>>> People say we don\'t have that many deadlocks in OpenStack for which the\n>>>> PTL ultimate power is needed, so we could get rid of them. I\'d argue\n>>>> that the main reason we don\'t have that many deadlocks in OpenStack is\n>>>> precisely *because* we have a system to break them if they arise. That\n>>>> encourages everyone to find a lazy consensus. That part of the PTL job\n>>>> works. Let\'s fix the part that doesn\'t work (scaling/burnout).\n>>>> \n>>> \n>>> Perhaps, the crux of the issue with PTLs is that we still need PTLs, but they should be *Project* Technical Leads and the role currently defined as PTL should really become a Program Manager - someone who coordinates all the projects, their issues, needs, communications and leave the deep technical work to the project leads and individual developers.  Consider the project technical leads seeing the trees and the program manager sees the forest.  Let the program manager gather the technical requirements and wishes for the next release and track those, let the team of project technical leads determine the design, architecture, tools, etc.\n>>> \n>>>> --\n>>>> Thierry Carrez (ttx)\n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> Great idea Thierry, just thought I\'d propose a slight twist on your concept.\n>>> And sorry for the flames, but I\'m in Jay Pipe\'s camp when it comes to needing to ensure inclusiveness, openness and transparency for the community and I think even the name czars are a slippery slope to something less open.\n>>> \n>>> --Rocky Grober\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAL3VkVxy3JxCAKc_2_ni1Mf7hrjAA6v+qv0NpDCCoWKW1ur3bg@mail.gmail.com>',NULL),('<01d101ceea84$c2915490$47b3fdb0$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-26 17:51:56',32400,'2013-11-26 08:51:56',NULL,'[Openstack] multipath - EMC vs NetApp','Hello Xing,\n\nThank you for your reply.\n\nYou wrote:\n> What OpenStack release are you running?  iSCSI multipath support was added\nvery late in Grizzly release and there were patches regarding multipath\nadded even after the Grizzly release.  EMC VNX5300 should work with iSCSI\nmultipath with Grizzly and beyond.\n\nWe tested with \'master\' code (nova:1dca95a74788667e52cab664c8a1dd942222d9c8\nand cinder:9b599d092ffa168a73ab7fa98ff20cb2cb48fe0b) last month, \nbut iSCSI multipath could not be configured.\n\nOur configuration was as follows.\n(IP addresses, passwords, prefixes are masked.)\n\n----------------------------------------------------------------\n- /etc/nova/nova.conf\nvolume_api_class = nova.volume.cinder.API\nlibvirt_iscsi_use_multipath = True\n\n- /etc/cinder/cinder.conf\nuse_multipath_for_image_xfer = true\niscsi_target_prefix = iqn.1992-04.com.emc:cx.fcn00XXXXXXXX\niscsi_ip_address = XX.XX.XX.11\nvolume_driver = cinder.volume.drivers.emc.emc_smis_iscsi.EMCSMISISCSIDriver\ncinder_emc_config_file = /etc/cinder/cinder_emc_config.xml\n\n- /etc/cinder/cinder_emc_config.xml\n\n<?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<EMC>\n<StorageType>Pool0</StorageType>\n<EcomServerIp>XX.XX.XX.XX</EcomServerIp>\n<EcomServerPort>5988</EcomServerPort>\n<EcomUserName>admin</EcomUserName>\n<EcomPassword>xxxxxxxx</EcomPassword>\n</EMC>\n\n- cinder-volume host\nA python-pywbem package(Version 0.7.0-4) was installed on the cinder-volume\nhost.\n\n- SMI-S Provider\nEMC SMI-S Provider V4.6.1.1 was set up on RHEL 6.3.\nand configured by following the SMI-S Provider Release notes.\n\n- VNX5300\nThin Provisioning enabler was installed.\nThin pool \'Pool0\' was created.\n\nAnd \"Register with VNX\" by Unisphere\n(See\nhttp://docs.openstack.org/grizzly/openstack-block-storage/admin/content/emc-\nsmis-iscsi-driver.html)\n----------------------------------------------------------------\n\nWhen copy_image_to_volume was executed, the following log was outputed.\n(Target IQN and portal IP addresses are masked.)\n\n---\n2013-10-31 11:27:43.322 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.13,3260]\nLogin to [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6,\nportal: XX.XX.XX.13,3260]: successful\n2013-10-31 11:27:45.680 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.17,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.17,3260]:\n2013-10-31 11:27:47.945 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.12,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.12,3260]:\n2013-10-31 11:27:50.144 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.15,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.15,3260]:\n2013-10-31 11:27:52.374 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.11,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.11,3260]:\n2013-10-31 11:27:54.621 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.16,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.16,3260]:\n2013-10-31 11:27:56.914 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.18,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.18,3260]:\n2013-10-31 11:27:59.174 26080 DEBUG cinder.brick.initiator.connector\n[req-18a3433e-561b-4f04-b3be-b5d5956780f9 59b7221e2f8041e39f643520b78ba533\n964613d2565a4a069da9658e44b544ae] iscsiadm (\'--login\',): stdout=Logging in\nto [iface: default, target: iqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal:\nXX.XX.XX.14,3260]\n stderr=iscsiadm: Could not login to [iface: default, target:\niqn.1992-04.com.emc:cx.fcn00XXXXXXXX.a6, portal: XX.XX.XX.14,3260]:\n---\n\nIn cinder.brick.initiator.connector, it is using a single iSCSI target(IQN)\nfor login to multiple (different) portal IP addresses.\nVNX5300 has multiple iSCSI ports with different iSCSI target (IQN)s.\n(Normally it should use a different iSCSI target(IQN) for each IP address.)\n\nIf our settings was wrong, could you please let us know what are the correct\nsettings?\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\n> -----Original Message-----\n> From: yang, xing [mailto:xing.yang at emc.com]\n> Sent: Tuesday, November 26, 2013 12:12 AM\n> To: Takashi Natsume; openstack at lists.openstack.org\n> Subject: RE: [Openstack] multipath - EMC vs NetApp\n> \n> Hi Takashi,\n> \n> What OpenStack release are you running?  iSCSI multipath support was added\n> very late in Grizzly release and there were patches regarding multipath\n> added even after the Grizzly release.  EMC VNX5300 should work with iSCSI\n> multipath with Grizzly and beyond.\n> \n> Thanks,\n> Xing\n> \n> \n> \n> -----Original Message-----\n> From: Takashi Natsume [mailto:natsume.takashi at lab.ntt.co.jp]\n> Sent: Monday, November 25, 2013 6:07 AM\n> To: yang, xing; openstack at lists.openstack.org\n> Subject: RE: [Openstack] multipath - EMC vs NetApp\n> \n> Hello Xing and all,\n> \n> We tried to set up iSCSI multipath with EMC VNX5300.\n> However, we had some problems with setting the iSCSI multipath with EMC\n> VNX5300.\n> So, we analyzed the logs and source codes, and found out that nova-compute\n> (cinder-volume also same) is using a single iSCSI target(IQN) for login\n> to multiple (different) portal IP addresses.\n> VNX5300 has multiple iSCSI ports with different iSCSI target (IQN)s.\n> (Normally it should use a different iSCSI target(IQN) for each IP\naddress.)\n> \n> So, we realized that, iSCSI multipath cannot be configured with VNX5300.\n> But we would like to use iSCSI multipath with EMC VNX5300.\n> \n> Regards,\n> Takashi Natsume\n> NTT Software Innovation Center\n> Tel: +81-422-59-4399\n> E-mail: natsume.takashi at lab.ntt.co.jp\n> \n> From: yang, xing [mailto:xing.yang at emc.com]\n> Sent: Friday, November 22, 2013 7:25 AM\n> To: Carlos Alvarez; openstack at lists.openstack.org\n> Subject: Re: [Openstack] multipath - EMC vs NetApp\n> \n> Hi Carlos,\n> \n> We are working on this issue and will keep you informed.\n> \n> Thanks,\n> Xing\n> \n> \n> From: Carlos Alvarez [mailto:cbalvarez at gmail.com]\n> Sent: Monday, November 18, 2013 1:19 PM\n> To: openstack at lists.openstack.org\n> Subject: [Openstack] multipath - EMC vs NetApp\n> \n> Hi All.\n> \n> I recently added a EMC V-Max storage system, and realized the multipath\n> is not working. The device is called /dev/mapper/XXXX but when I see the\n> multipath -ll output, I see just one path. It is working fine with a\nNetApp\n> 3250.\n> \n> Looking into differences, I see the output of the iscsiadm discovery\n> differs:\n> \n> Netapp output:\n> root at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p 10.33.5.10\n> 10.33.5.10:3260,1030\n> iqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n> 10.33.5.11:3260,1031\n> iqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n> \n> Emc output:\n> root at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p 10.33.5.25\n> 10.33.5.25:3260,1 iqn.1992-04.com.emc:50000973f00bcd44\n> \n> \n> Looking into the code, the former is clearly what the connect_volume\nmethod\n> is expecting: a single ip which returns both path. I reported it to EMC\n> and the answer is that it works with netapp because the 3250 has a feature\n> EMC lacks (called multipath groups).\n> \n> Is anybody using multipath with a V-Max?. It should work or EMC is not\n> supported?\n> \n> Thanks!\n> Carlos\n> \n> \n\n\n\n\n\n','<35804680EDCC5640AFC7C590814F48F50115EDBB4CFC@MX40A.corp.emc.com>',NULL),('<01d201d0024c$1592d9e0$40b88da0$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 17:51:38',28800,'2014-11-17 09:51:38',NULL,'[openstack-dev] 答复:  Ceilometer memory.usage can not get info from	libvirt','As described in the document: http://docs.openstack.org/developer/ceilometer/measurements.html#measurements\n\n \n\n???\n\nNote\n\n \n\nTo enable the libvirt memory.usage supporting, you need libvirt version 1.1.1+, qemu version 1.5+, and you need to prepare suitable balloon driver in the image, particularly for Windows guests, most modern Linuxes have it built in. The memory.usage meters can?t be fetched without image balloon driver.\n\n \n\n???\n\n:)\n\n \n\n \n\n \n\n  _____  \n\nE_mail:  <mailto:raodingyuan at chinacloud.com.cn> raodingyuan at chinacloud.com.cn\n\n \n\n???: Du Jun [mailto:dj199008 at gmail.com] \n????: 2014?11?17? 16:57\n???: OpenStack Development Mailing List (not for usage questions)\n??: [openstack-dev] Ceilometer memory.usage can not get info from libvirt\n\n \n\nHi all,\n\n2014-11-17 16:04:01.563 5162 INFO ceilometer.agent [-] Polling pollster memory.usage in the context of meter_source                              \n140000 2014-11-17 16:04:01.564 5162 DEBUG ceilometer.compute.pollsters.memory [-] Checking memory usage for instance 7e53172c-f05f-4fda-9855-af6775c1f4a8 get_samples /opt/stack/ceilometer/ceilometer/compute/pollsters/memory.py:31\n140002 2014-11-17 16:04:01.573 5162 WARNING ceilometer.compute.virt.libvirt.inspector [-] Failed to inspect memory usage of instance-00000002, can not get info from libvirt\n140003 2014-11-17 16:04:01.574 5162 ERROR ceilometer.compute.pollsters.memory [-] Could not get Memory Usage for 7e53172c-f05f-4fda-9855-af6775c1f4a8: \'NoneType\' object has no attribute \'usage\'\n140004 2014-11-17 16:04:01.574 5162 TRACE ceilometer.compute.pollsters.memory Traceback (most recent call last):\n140005 2014-11-17 16:04:01.574 5162 TRACE ceilometer.compute.pollsters.memory   File \"/opt/stack/ceilometer/ceilometer/compute/pollsters/memory.py\", line 37, in get_samples\n140006 2014-11-17 16:04:01.574 5162 TRACE ceilometer.compute.pollsters.memory     \'usage\': memory_info.usage}))\n140007 2014-11-17 16:04:01.574 5162 TRACE ceilometer.compute.pollsters.memory AttributeError: \'NoneType\' object has no attribute \'usage\'\n\nWhen \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/e1f9d1ab/attachment.html>\n\n','<CABvddo5wV5xOo10tHovn5MJUHS2UYxzF71PBuU4qR9UvHVwOBg@mail.gmail.com>',NULL),('<01E21198-B5F7-40A7-AEB5-8C942F8F40AA@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-06 12:57:22',3600,'2014-11-06 11:57:22',NULL,'[OpenStack-docs] Training guides second meet','im in the very back by the column\n\n~ sean\n\n> On Nov 6, 2014, at 12:36 AM, Sean Roberts <seanroberts66 at gmail.com> wrote:\n> \n> See you then!\n> \n> ~sean\n> \n> On Nov 5, 2014, at 10:25 PM, Anne Gentle <anne at openstack.org <mailto:anne at openstack.org>> wrote:\n> \n>> Got it on my calendar and will defend the time with my ninja skills.\n>> Anne\n>> \n>> On Wed, Nov 5, 2014 at 11:40 AM, Sean Roberts <seanroberts66 at gmail.com <mailto:seanroberts66 at gmail.com>> wrote:\n>> Thursday 1pm at the docs table in the back of the developer lounge\n>> \n>> See you there!\n>> \n>> ~sean\n>> \n>> _______________________________________________\n>> OpenStack-docs mailing list\n>> OpenStack-docs at lists.openstack.org <mailto:OpenStack-docs at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs>\n>> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141106/2ac31113/attachment.html>\n\n','<2BB3A154-2732-4AD6-BFA7-FC2928ADD060@gmail.com>',NULL),('<01ED811F-A9BF-4902-B0A3-A7239E2E006E@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 14:28:09',0,'2013-08-06 14:28:09',NULL,'[openstack-dev] [Keystone] V3 Extensions Discoverability','\nOn Aug 6, 2013, at 8:36 AM, Adam Young wrote:\n\n> On 08/06/2013 01:19 AM, Jamie Lennox wrote:\n>> Hi all,\n>> \n>> Partially in response to the trusts API review in keystoneclient\n>> (https://review.openstack.org/#/c/39899/ ) and my work on keystone API\n>> version discoverability (spell-check disagrees but I\'m going to assume\n>> that\'s a word - https://review.openstack.org/#/c/38414/ ) I was thinking\n>> about how we should be able to know what/if an extension is available. I\n>> even made a basic blueprint for how i think it should work:\n>> https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API.\n> \n> I\'m not certain that the extensions should really be in the v2 or v3.  It always seemed to me that Extensions should be parallel to, and separate from, the core API.\n\n\nI agree. Extensions should not be in core, but the mechanism by which extensions are discovered should be part of the core...right?\n\n-jOrGe W.\n\n\n\n','<5200FBC1.3040002@redhat.com>',NULL),('<01fd01ce0889$500c7ae0$f02570a0$@gmail.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2013-02-11 19:55:07',3600,'2013-02-11 18:55:07',NULL,'[User-committee] FW: OpenStack User Co... - Does this mean we would\n	select member...',' \n\nRyan,\n\n \n\nI\'m fine with an initial round of some more nominations in order to increase\nthe scope. We can schedule elections post-summit. We should at least be able\nto identify\n\n \n\n-          3 representatives of the geographies (US, EMEA, Asia)\n\n-          A small number of industry representatives in the key areas that\nthe foundation wants to focus on in 2013\n\n \n\nWe should try to avoid elections at the end of the year since this would\ncause extra confusion w.r.t. individual member board elections.\n\n \n\nTim\n\n \n\nFrom: Ryan Lane (Google Docs)\n[mailto:k+MTEzMDgzMzEyODExNDQ5NTUwOTY3-MTExMjE0NDA2OTcyNjcyMzQ4MTY3 at docs.goo\ngle.com] \nSent: 11 February 2013 07:37\nTo: noggin143 at gmail.com\nSubject: OpenStack User Co... - Does this mean we would select member...\n\n \n\nRyan Lane replied to a comment on\n<https://docs.google.com/presentation/d/1fL6IMVGRELQZfhXPdNVMpdF1glj91u2rbQG\nciCXKYmU/edit?disco=AAAAAFNKzPQ> OpenStack User Committee Update\n\n\n \n<https://lh5.googleusercontent.com/-oqkO7QS6Rm4/AAAAAAAAAAI/AAAAAAAADpA/Y8Hp\nN1wIu-E/s75/photo.jpg> \n\nTim Bell\n\nFinalize structure of committee Begin inviting new committee members Send\ninitial user poll\n\nDoes this mean we would select members or that we would hold elections?\n\n\n \n<https://lh6.googleusercontent.com/-Z7LVY2rk16Y/AAAAAAAAAAI/AAAAAAAAACM/oEGc\n2Wyh_U0/s75/photo.jpg> \n\nRyan Lane\n\nI think we need to have more discussion on this. Elections will be difficult\nif we\'re trying to ensure the membership coverage areas we\'ve set up. I do\nthink elections are the right way to go, but setting them up properly is\ngoing to be difficult.\n\n \n\n\n \n<https://lh6.googleusercontent.com/-Z7LVY2rk16Y/AAAAAAAAAAI/AAAAAAAAACM/oEGc\n2Wyh_U0/s75/photo.jpg> \n\nRyan Lane\n\nMarked as resolved\n\n\nYou received this email because you are mentioned in this thread.\n<https://docs.google.com/comments/u/113083312811449550967/docos/notify?id=AA\nHRpnXurc10KsQzQVaFWi06iE1FbyLEJoxStQXMWfeN2Zkeb2YHsGxxGuW5Y3ETNTxqrY6Fr1wh7R\nPeDaAGCejt42m7UQ6vR44b02xXG1d_PGtniWw9Qe5o&title=OpenStack+User+Committee+Up\ndate> Change what Google Docs sends you.You can reply to this email to reply\nto the comment.\n\n\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20130211/dd49c76f/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: logo.png\nType: image/png\nSize: 3733 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20130211/dd49c76f/attachment.png>\n\n','<gOwSgRLTUeTEh4BWvmTUtA@notifications.google.com>',NULL),('<01FFEF1ABF1C864AAA16C9B5CFEE589A0ABFF72D@IRSMSX107.ger.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 15:46:58',0,'2014-11-17 15:46:58',NULL,'[openstack-dev] [horizon] Changing \"Host marked for maintenance\" BP\n target milestone','Hi guys,\nI\'ve start working on this BP: https://blueprints.launchpad.net/horizon/+spec/mark-host-down-for-maintenance\nOne of the reviews from this BP has been already merged (in juno).\nAnother one has to be finalized.\n\nSo I have a question: is it possible to change milestone target for this BP feature into Kilo release?\n\n- Bart\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/2ef22c2e/attachment.html>\n\n',NULL,NULL),('<0200BC81-B655-4145-B127-558993307D25@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 07:57:50',0,'2013-11-22 07:57:50',NULL,'[openstack-dev] [Solum] Command Line Interface for Solum','I have updated the blueprint for this feature, and approved the direction for the v0.1 milestone:\n\nhttps://blueprints.launchpad.net/solum/+spec/command-line\n\nThe specification for the CLI is not intended to be complete at this stage. It only specified what I expect we will need for v0.1. Additional commands can be added as we add support for additional features in subsequent releases.\n\nAdrian\n\nOn Nov 15, 2013, at 12:00 PM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:\n\n\n\n\nOn Thu, Nov 14, 2013 at 2:28 AM, Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at rackspace.com>> wrote:\nDoug,\n\nOn Nov 13, 2013, at 9:28 AM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:\n\n\n\n\nOn Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M <noorul at noorul.com<mailto:noorul at noorul.com>> wrote:\n\nHello all,\n\nI registered a new blueprint [1] for command line client interface for\nSolum. We need to decide whether we should have a separate repository\nfor this or go with new unified CLI framework [2]. Since Solum is not\npart of OpenStack I think it is not the right time to go with the\nunified CLI.\n\nOne of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example:\n\n  $ pip install python-solumclient\n  $ pip install python-openstackclient\n  $ openstack solum make me a paas\n\nDean has done a lot of work to design a consistent \"noun-followed-by-verb\" command structure, so please look at that work when picking subcommand names (for example, you shouldn\'t use solum as a prefix as I did in my example above, since we are removing the project names from the commands).\n\nAre you referring to \"openstack solum ?\" in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs?\n\nI could imagine the following verb/noun combinations off the bat:\n\ndeploy app\n\nlist assemblies\nlist plans\nlist services\n\nget assembly <assembly_name|uri>\nget plan <plan_name|uri>\nget service <service_name|uri>\n\nscale assembly <assembly_name|uri> (+|-n)\nresize du <assembly_name|uri>\nstart assembly\nstop assembly\n\ndelete assembly\ndelete app\n\nWhat about using combined noun+verb combinations, so you would end up with commands like:\n\ndeploy_app\n\n?etc. That might be more specific and require less processing logic.\n\nThere is a namespace for the nouns, and each noun has a namespace with verbs. So you might say \"openstack app deploy\", \"openstack assembly show\", etc.\nPlacing the noun first lets us use tab completion to help the user figure out what options they have (\"openstack assembly <tab>\" would show scale, resize, start, and stop as completion options).\n\n\nAs far as processing logic, that\'s all handled by the framework already. The commands are registered as multi-word names pointing to a single class, and cliff figures out which one to run based on the input command line.\n\nDoug\n\n\n\nThanks,\n\nAdrian\n\n\n\n\nDoug\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/c35b2099/attachment.html>\n\n','<CADb+p3R5Tq32ugX-SMx2x2HKgv6rW4=Nke--HwyXaZ-nqoFhnw@mail.gmail.com>',NULL),('<020DDB7C-0192-4768-9657-31799064A652@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-08 17:02:27',-14400,'2014-06-08 21:02:27',NULL,'[openstack-dev] [Oslo] [Ironic] DB migration woes','\nOn Jun 8, 2014, at 11:46 AM, Roman Podoliaka <rpodolyaka at mirantis.com> wrote:\n\n> \n> Overall, the approach with executing a test within a transaction and\n> then emitting ROLLBACK worked quite well. The only problem I ran into\n> were tests doing ROLLBACK on purpose. But you\'ve updated the recipe\n> since then and this can probably be solved by using of save points.\n\nyup, I went and found the gist, that is here:\n\nhttps://gist.github.com/zzzeek/8443477\n\n\n\n\n','<CAKA_ueA_HbO-EmR5zg6RJznDaFXbRiJQTT9avOL-v8ZAaKCNeg@mail.gmail.com>',NULL),('<0216cf8ae8b351691ff3d992fe04cf9c@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-20 12:53:29',10800,'2014-06-20 09:53:29',NULL,'[Openstack] Tenant List',' Indeed there is available and in principle it should work as an \n admin...but it doesn\'t.\n\n\n Best,\n\n G.\n\n\n On Fri, 20 Jun 2014 12:30:31 +0300, M?rti?? Jakubovi?s wrote:\n> Look command as \"nova help list\", there is such option --tenant and I\n> can confirm, it didn\'t work for me either.\n>\n> On 2014.06.20. 12:16, Deepak Shetty wrote:\n>> I think --tenant is not a supported option for nova\n>> I don\'t see it under nova -h\n>>\n>> What i see is this...\n>> --os-tenant-name <auth-tenant-name>\n>>\n>> So maybe --tenant is just being ignored and hence the cmd reduces to \n>> `nova\n>> list` hence it shows only admin instance as u r logged in as admin\n>>\n>>\n>> On Fri, Jun 13, 2014 at 6:40 PM, Georgios Dimitrakakis \n>> <giorgis at acmac.uoc.gr\n>>> wrote:\n>>\n>>> I am in IceHouse and as an ADMIN I am trying to list the instances \n>>> on a\n>>> specific tenant.\n>>>\n>>> I have the following tenants:\n>>>\n>>> # keystone tenant-list\n>>> +----------------------------------+---------+---------+\n>>> |                id                |   name  | enabled |\n>>> +----------------------------------+---------+---------+\n>>> | 4746936e9e4b49e382ad41d0b98f3644 |  admin  |   True  |\n>>> | 965bd35fbef24133951a6bee429cd5be |   demo  |   True  |\n>>> | ad1473de92c1496fa4dea3fb93101b8b | service |   True  |\n>>> +----------------------------------+---------+---------+\n>>>\n>>> Both the commands\n>>>\n>>> # nova list --tenant demo\n>>> # nova list --tenant 965bd35fbef24133951a6bee429cd5be\n>>>\n>>>\n>>> produce the wrong output since they list the instances for the \n>>> admin\n>>> tenant.\n>>>\n>>> Using\n>>>\n>>> # nova list --all-tenants\n>>>\n>>> shows everything but why the specific tenants cannot be shown?\n>>>\n>>> Does anyone else have seen this??\n>>>\n>>>\n>>> Best,\n>>>\n>>>\n>>> G.\n>>> --\n>>>\n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/\n>>> openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/\n>>> openstack\n>>>\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n --\n\n\n','<53A3FF37.2090500@vertigs.lv>',NULL),('<021AEB5D-FBDC-41A6-8620-D732CF0A74AD@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 00:06:03',-25200,'2014-09-19 07:06:03',NULL,'[openstack-dev] battling stale .pyc files','\nOn Sep 15, 2014, at 4:34 AM, Lucas Alvares Gomes <lucasagomes at gmail.com> wrote:\n\n> So, although I like the fix proposed and I would +1 that idea, I\'m\n> also not very concerned if most of the people don\'t want that. Because\n> as you just said we can fix it locally easily. I didn\'t set it to my\n> .local but the way I do nowadays is to have a small bash function in\n> my .bashrc to delete the pyc files from the current directory:\n> \n> function delpyc () {\n>   find . -name \"*.pyc\" -exec rm -rf {} \\;\n> }\n> \n> So I just invoke it when needed :)\n\nfyi there is a -delete option to find which is probably a little safer then exec with a rm -rf. Also it is really convienient to do this as a git alias so it happens automatically when switching branches:\n\nIn ~/.gitconfig:\n\n[alias]\n    cc = !\"TOP=$(git rev-parse --show-toplevel) find $TOP -name \'*.pyc\' -delete; git-checkout?\n\nnow you can git cc <branch> instead of git checkout <branch>.\n\nVish\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140919/e009696d/attachment.pgp>\n\n','<CAB1EZBondRQ1fnEOQr=BmjDKNKONJTmeozKrdmbWpE1XpeoEsw@mail.gmail.com>',NULL),('<021cc2d3.0000142c.00000011@cw-lap-8TWXLX1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 14:21:01',0,'2014-01-21 14:21:01',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','\n> Exactly - that\'s why I wanted to start this debate about the way forward \n> for the\n> Pcloud Blueprint, which was heading into some kind of middle ground.  As \n> per\n> my original post, and it sounds like the three of us are at least aligned \n> I\'m\n> proposing to spilt this into two streams:\n>\n> i) A new BP that introduces the equivalent of AWS dedicated instances.\n\nWhy do you want to transform pCloud into AWS dedicated instances? As I see \nit,\npCloud is for requesting physical hosts (HostFlovors as in pcloud wiki) on \nwhich\nusers can create their own instances (theoretically in unlimited number). \nTherefore it should be charged per physical server\n(HostFlavor), not by instances. It is completely different from AWS \ndedicated instances\nwhich is charged per instance. IMO, pcloud resembles Godrid Dedicated \nServer, not\nAWS Dedicated Instance.\n\nIf you want to provide AWS dedicated instances  typed service, then it would \nnot be\nPcloud, nor it is a continuation of the WholeHostAllocaiton blueprint, which \n,\nIMO, is damned well designed. It\'ll be just another scheduler job. Well, I \ndid not say\nthat it\'s not worth pursuing ; I just say that WholeHostAllocation is worth \nbeing\nkept pcloud.\n\n> 	User - Only has to specify that at boot time that the instance must be on\n> a host used exclusively by that tenant.\n> 	Scheduler - ether finds a hoist which matches this constraint or it\n> doesn\'t.   No linkage to aggregates (other than that from other filters), \n> no need\n> for the aggregate to have been pre-configured\n> 	Compute Manager - has to check the constraint (as with any other\n> scheduler limit) and add the info that this is a dedicated instance to \n> notification\n> messages\n> 	Operator - has to manage capacity as they do for any other such\n> constraint (it is a significant capacity mgmt issue, but no worse in my \n> mind that\n> having flavors that can consume most of a host) , and work out how they \n> want\n> to charge for such a model (flat rate additional charge for first such \n> instance,\n> charge each time a new host is used, etc).\n>\n\nHow about using migration for releasing compute hosts for new allocation? In \nstandard\nconfiguration, admin would use LoadBalancing for his computes. Thus if we \ndon\'t have\na dedicated resources pool (this comes back to aggregate configuration), \nthen all hosts\nwould be used, which leaves no host empty for hosting dedicated instances.\n\n> I think there is clear water between this and the existing aggregate based\n> isolation.  I also think this is a different use case from reservations. \n> It\'s\n> *mostly* like a new scheduler hint, but because it has billing impacts I \n> think it\n> needs to be more than just that - for example the ability to request a \n> dedicated\n> instance is something that should be controlled by a specific role.\n\nAgreed. The billing is rather the problem here. Nova can handle this all \nright, but how\nthis new functionality cope with the billing model. Basically, which \ninformation is\nrecorded, and where.\n\n>\n> ii) Leave the concept of \"private clouds within a cloud\"  to something \n> that can be\n> handled at the region level.  I think there are valid use cases here, but \n> it doesn?t\n> make sense to try and get this kind of granularity within Nova.\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F895F7@G6W2490.americas.hpqcorp.net>',NULL),('<021d01cf96a3$7b5a12d0$720e3870$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 17:45:10',28800,'2014-07-03 09:45:10',NULL,'[Openstack] [Ceilometer] Question regarding the meter \"cpu time\n	used\"','Hi folks,\n\n \n\nI found that the ?cpu time used? meter actually means ?cpu time used *since last boot-up*?, at least in libvirt environments. It will be reset to ZERO after VM restart. As far as I understand, a cumulative type meter should be strictly increasing, so it looks very strange to me.\n\n \n\nMy questions are:\n\n1, Since I have libvirt environment only, I haven?t tested on vsphere or any others. Does it behave the same in other environments?\n\n2, Is it intended to be like this?\n\n2, What should a billing system do to correctly use this meter?\n\n \n\nPlease help :)\n\n \n\nThanks a lot!\n\n \n\n \n\nKurt Rao\n\nChinaCloud Information Technology Co., Ltd.\n\nE_mail: raodingyuan at chinacloud.com.cn <mailto:raodingyuan at chinacloud.com.cn> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140703/36b3f2fc/attachment.html>\n\n',NULL,NULL),('<021f01ccaf88$cd431380$67c93a80$@twinstrata.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-30 12:52:17',-18000,'2011-11-30 17:52:17',NULL,'[Openstack-operators] FW: Question about swauth','Hello,\n\n \n\n                I am trying to install OpenStack for the first time locally\nwithin my environment and ran into an issue which I hope someone can\naddress.\n\n \n\nMy Config:\n\nI have created 6 servers all running Ubuntu 10.04 LTS.  Five of the six\nservers I have configured as the storage nodes.  The sixth is my Proxy/Auth\nnode.  I have followed the admin guide step by step.  On the proxy node  I\nhave done the following:\n\n \n\nApt-get install python-software-properties\n\nAdd-apt-repository ppa:swift-core/ppa\n\nApt-get update\n\nApt-get install swift openssh-server\n\nMkdir -p /etc/swift\n\nChown -R swift:swift /etc/swift/\n\n \n\nCreated the swift.conf with the following entries\n\n[swift-hash]\n\nSwift_hash_path_suffix = theactualhash\n\n \n\nNow the instructions tell me to install swauth from\nhttps://github.com/gholt/swauth.  I downloaded the package and untarred it\ninto a dir and installed it.  One of the steps during installation involves\nrunning this command:\n\n \n\nswauth-prep -K swauthkey\n\n \n\nI run that command get the following error:\n\n \n\n\n\n \n\nDoes anyone know what this error indicates and how to resolve it.  Thanks.\n\n \n\nManu Dargan\nServices & Support Manager\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111130/2923d849/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.png\nType: image/png\nSize: 11500 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111130/2923d849/attachment.png>\n\n',NULL,NULL),('<022916A2-FD45-43AB-B06B-627C391A8D09@not.mn>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2013-07-02 06:29:38',-25200,'2013-07-02 13:29:38',NULL,'[openstack-announce] [Swift] Swift 1.9.0 released: global clusters\n	and more','I\'m pleased to announce that Swift 1.9.0 has been released. This has\nbeen a great release with major features added, thanks to the combined\neffort of 37 different contributors.\n\nFull release notes: https://github.com/openstack/swift/blob/master/CHANGELOG\nDownload: https://launchpad.net/swift/havana/1.9.0\n\nFeature Summary\n===============\n\nFull global clusters support\n----------------------------\n\nWith this release, Swift fully supports global clusters. A single\nSwift cluster can now be deployed a wide geographic area (eg across an\nocean or continent) and still provide high durability and\navailability. This feature has four major parts:\n\n    * Region tier for data placement\n    * Adjustable replica counts\n    * Separate replication network support\n    * Affinity on reads and writes\n\nImprovements in disk performance\n--------------------------------\n\nThe object server can now be configured to use threadpools to increase\nperformance and smooth out latency on storage nodes. Also, many disk\noperations were reordered to increase reliablility and improve\nperformance. This work is a direct result of the design summit\nsessions in Portland.\n\nSupport for config directories\n------------------------------\n\nSwift now supports conf.d style config directories. This allows config\nsnippets to be managed independently and composed into the full config\nfor a Swift process. For example, a deployer can have a config snippet\nfor each piece of proxy middleware.\n\nMultiple TempURL keys\n---------------------\n\nThe TempURL feature (temporary, signed URLs) now supports two signing\nkeys. This allows users to safely rotate keys without invalidating\nexisting signed URLs.\n\nOther\n-----\n\nThere\'s a ton of \"other\" stuff in this release including features,\nsecurity fixes, general polishing, and bug fixes. I encourage you to\ncheck out the full release notes for more info\n(https://github.com/openstack/swift/blob/master/CHANGELOG).\n\nNew Contributors\n================\n\nTwelve of the 37 total contributors are first-time contributors to\nSwift. They are:\n\n    * Fabien Boucher (fabien.boucher at enovance.com)\n    * Brian D. Burns (iosctr at gmail.com)\n    * Alex Gaynor (alex.gaynor at gmail.com)\n    * Edward Hope-Morley (opentastic at gmail.com)\n    * Matthieu Huin (mhu at enovance.com)\n    * Shri Javadekar (shrinand at maginatics.com)\n    * Sergey Kraynev (skraynev at mirantis.com)\n    * Dieter Plaetinck (dieter at vimeo.com)\n    * Chuck Short (chuck.short at canonical.com)\n    * Dmitry Ukov (dukov at mirantis.com)\n    * Vladimir Vechkanov (vvechkanov at mirantis.com)\n    * niu-zglinux (Niu.ZGlinux at gmail.com)\n\nThank you to everyone who contributed.\n\n--John\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4082 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20130702/06a5de13/attachment.bin>\n\n',NULL,NULL),('<022916A2-FD45-43AB-B06B-627C391A8D09@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 06:29:38',-25200,'2013-07-02 13:29:38',NULL,'[openstack-dev] [Swift] Swift 1.9.0 released: global clusters and\n	more','I\'m pleased to announce that Swift 1.9.0 has been released. This has\nbeen a great release with major features added, thanks to the combined\neffort of 37 different contributors.\n\nFull release notes: https://github.com/openstack/swift/blob/master/CHANGELOG\nDownload: https://launchpad.net/swift/havana/1.9.0\n\nFeature Summary\n===============\n\nFull global clusters support\n----------------------------\n\nWith this release, Swift fully supports global clusters. A single\nSwift cluster can now be deployed a wide geographic area (eg across an\nocean or continent) and still provide high durability and\navailability. This feature has four major parts:\n\n    * Region tier for data placement\n    * Adjustable replica counts\n    * Separate replication network support\n    * Affinity on reads and writes\n\nImprovements in disk performance\n--------------------------------\n\nThe object server can now be configured to use threadpools to increase\nperformance and smooth out latency on storage nodes. Also, many disk\noperations were reordered to increase reliablility and improve\nperformance. This work is a direct result of the design summit\nsessions in Portland.\n\nSupport for config directories\n------------------------------\n\nSwift now supports conf.d style config directories. This allows config\nsnippets to be managed independently and composed into the full config\nfor a Swift process. For example, a deployer can have a config snippet\nfor each piece of proxy middleware.\n\nMultiple TempURL keys\n---------------------\n\nThe TempURL feature (temporary, signed URLs) now supports two signing\nkeys. This allows users to safely rotate keys without invalidating\nexisting signed URLs.\n\nOther\n-----\n\nThere\'s a ton of \"other\" stuff in this release including features,\nsecurity fixes, general polishing, and bug fixes. I encourage you to\ncheck out the full release notes for more info\n(https://github.com/openstack/swift/blob/master/CHANGELOG).\n\nNew Contributors\n================\n\nTwelve of the 37 total contributors are first-time contributors to\nSwift. They are:\n\n    * Fabien Boucher (fabien.boucher at enovance.com)\n    * Brian D. Burns (iosctr at gmail.com)\n    * Alex Gaynor (alex.gaynor at gmail.com)\n    * Edward Hope-Morley (opentastic at gmail.com)\n    * Matthieu Huin (mhu at enovance.com)\n    * Shri Javadekar (shrinand at maginatics.com)\n    * Sergey Kraynev (skraynev at mirantis.com)\n    * Dieter Plaetinck (dieter at vimeo.com)\n    * Chuck Short (chuck.short at canonical.com)\n    * Dmitry Ukov (dukov at mirantis.com)\n    * Vladimir Vechkanov (vvechkanov at mirantis.com)\n    * niu-zglinux (Niu.ZGlinux at gmail.com)\n\nThank you to everyone who contributed.\n\n--John\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4082 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130702/06a5de13/attachment.bin>\n\n',NULL,NULL),('<0229347F-894C-41A7-ACA3-754E2281AF94@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 21:05:48',0,'2014-05-21 21:05:48',NULL,'[openstack-dev] [neutron] Proposed changes to core team','\nOn May 21, 2014, at 4:59 PM, Kyle Mestery <mestery at noironetworks.com> wrote:\n\n> \n> Neutron cores, please vote +1/-1 for the proposed addition of Carl\n> Baldwin to Neutron core.\n> \n\nCarl has been a great contributor. +1 to adding to core team\n\nmark\n\n\n\n','<CADEmHi10Z-y2t=M7Jm=sOXy8fM_JpAGJqmTMv5dK-L_zcOsDOg@mail.gmail.com>',NULL),('<023201ce8873$22d712a0$688537e0$@wirelessconnections.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-24 09:38:52',-14400,'2013-07-24 13:38:52',NULL,'[Openstack-operators] Best practice suggestions','I am putting together my first lab cloud and would like any suggestions as\nto best practices.\n\n \n\nHere is the network proposed in a Grizzly guide I found online.\n\n \n\n\nNode Role:\n\nNICs\n\n\nControl Node:\n\neth0 (10.10.10.51), eth1 (192.168.100.51)\n\n\nNetwork Node:\n\neth0 (10.10.10.52), eth1 (10.20.20.52), eth2 (192.168.100.52)\n\n\nCompute Node:\n\neth0 (10.10.10.53), eth1 (10.20.20.53)\n\n \n\nThis appears to map the 192.168.100.x subnet to the Openvswitch for public\nIP addresses.\n\n \n\nSo  should I map the horizon front end to a public IP address on the vswitch\nor just put a public IP secondary address on the Control Node?\n\n \n\nDoes this type of network make sense or is it just a lab style network.\n\n\nDavid\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130724/b3a54f0d/attachment.html>\n\n',NULL,NULL),('<02356D41-6B72-4CD5-A1FE-4A93F328196D@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 09:00:26',-25200,'2013-10-17 16:00:26',NULL,'[openstack-dev] [savanna] team meeting October 17 1800 UTC','Hi folks,\n\nWe\'ll be having the Savanna team meeting as usual in #openstack-meeting-alt channel.\n\nAgenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_October.2C_17\n\nhttp://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20131017T18\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\n\n\n',NULL,NULL),('<0238145DC5F197479BA49AF538359A0874A4DEE5@ORSMSX115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-12 22:10:44',0,'2014-05-12 22:10:44',NULL,'[openstack-dev] Introducing Project Graffiti','Alex,\n\nThe concepts for Graffiti are very general and are not really tied to a specific use case like application-catalog. It is fundamentally a way to annotate any resource with metadata. For example, what standard way can we use to describe the capabilities of a compute host? How can that capability be referenced on images, host-aggregates, policies, flavors, etc. How can ISVs, vendors declare their unique capabilities and have it be associated with various objects? Say I create a machine image that uses certain libraries that can benefit from some specific HW capability? How can I declare that requirement and have it be applied during scheduling? What Graffiti allows a person to do is tag various resources in openstack with known metadata, and the metadata can then be used for any purpose. We demonstrate it being used to deal with extra specs in flavors, images etc.\n\nYou are welcome to our design session @ the summit http://youtu.be/f0SZtPgcxk4 and we can discuss more, and talk about the demo code that we have working. If you are not able to make it to the session, please just email me and we can still meet and discuss this.\n\nThanks,\nMurali\n\n\n-----Original Message-----\nFrom: Alexander Tivelkov [mailto:ativelkov at mirantis.com] \nSent: Tuesday, May 06, 2014 2:31 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Introducing Project Graffiti\n\nHi Travis,\n\nIt will be great to have your team join the artifact repository initiative. We are going to have a session at the summit ([1]) to discuss the design, and you most welcome to join. We\'ll publish the etherpad with brief agenda for this session later this week.\n\n\nSpeaking about Murano you\'ve got a very good point: currently Murano\'s application catalog is very tightly coupled with the workflow engine.\nIt happens because Murano aims not only to provide the pure catalog capabilities, but also to manage the lifecycle of the deployed\napplications: provide ways to handle external and internal events, maintain the applications\' state, report usage statistics etc - all of this usually requires workflows, and these workflows have to be aware about the applications\' data structure and interdependencies. That\'s where the idea of Murano\'s workflow engine came from.\n\nHowever, it turned out to be overcomplicated and having some potential overlaps with existing OpenStack projects (you probably saw a very long discussions here about it) - and we are now working hard to fix this, by establishing a clean separation between plain catalog functionality of Murano and the workflow-related processes: some of them should go to different projects, some will remain in Murano but in more unified and clear manner. We\'ll have a couple of design sessions on this as well - at the \"cross-project workshop\" ([2], [3])\n- feel free to join as well, if you are interested.\n\nSpeaking about the data storage for Murano, currently we look forward to the Glance Artifact Repository: we expect murano application packages (being composed out of Heat templates, workflows, binary files and other stuff) to be stored as composite multi-part artifacts in Glance. Each part of this artifact will be an \"entry-point\" for some action is some OpenStack service (like you said: boot sources for Nova, templates for Heat etc), while the workflow which coordinates this various services and tells them which part of artifact to boot from will be run as the higher-level layer service.\nHope this answer your questions. If you have more to ask, please feel free to join our weekly meeting in IRC ([4]) - the nearest one is today (Tuesday), at 17:00 UTC\n\nThanks!\n\n\n[1] http://junodesignsummit.sched.org/event/b0e1f0cbefffa942e276f1add9f85d03#.U2h8JF6nDWU\n[2] http://junodesignsummit.sched.org/event/b7f067ff055ff7db9c92867f3febe1d9#.U2iAd16nDWU\n[3] http://junodesignsummit.sched.org/event/556d10915a1a0a2f1aee3ba286826b60#.U2iAeF6nDWU\n[4] https://wiki.openstack.org/wiki/Meetings/MuranoAgenda\n--\nRegards,\nAlexander Tivelkov\n\n\nOn Tue, May 6, 2014 at 9:37 AM, Tripp, Travis S <travis.tripp at hp.com> wrote:\n> Hi Angus,\n>\n>> This seems neat, but also seems to have some overlap with glance\'s \n>> new catalog and some of the things Murano are doing. Have you had a look at those efforts?\n>\n> Thanks! We have been keeping an eye on the Glance work and the Murano work, and your email reminded me to catch back up on both of them. I think in both cases that the Graffiti concepts are complementary. However, strictly speaking from a bird\'s eye view on application categorization, there is some reconciliation to work out on that aspect.\n>\n> Regarding the Glance artifact repository, this looks like a nice revamp of its concepts. Most of it seems to be very related to handling artifacts, dependencies, versions, and relationships associated with packaging in a generic way so that external services can use it in a variety of ways. There is one feature that was discussed in the last Glance meeting logs that I think we might be able to leverage for some of the Graffiti concepts. That is a dynamic schemas API. Perhaps, we can build the Graffiti dictionary concepts on top of it.  We\'re definitely interested in anything that creates less moving parts for us and is already part of the standard OpenStack ecosystem.\n>\n> For Murano, the pure application catalog UI is an interesting concept that today still seems to be intertwined with the Murano workflow engine. It isn\'t clear to me if the intent is for it to eventually become the UI for everything application related, including Solum and pure Heat templates? From the mailing list discussions, it seems that this is still a rather unresolved question.\n>\n> For us we\'d like to be able to provide end user help with even the existing launch instance UI. Also, one of the goals of the Graffiti concepts is to be able to directly \"tag\" resources with metadata that comes from multiple sources, whether that is system provided (e.g. various compute capabilities) or user provided (e.g. categories or software tags) and then be able to search on them. This can be used for boot sources, flavors, host aggregates, etc, and perhaps even networks in the future.  It seems possible that Murano may just be a consumer of some of the same data?\n>\n> -Travis\n>\n>> -----Original Message-----\n>> From: Angus Salkeld [mailto:angus.salkeld at rackspace.com]\n>> Sent: Monday, May 05, 2014 8:16 PM\n>> To: openstack-dev at lists.openstack.org\n>> Subject: Re: [openstack-dev] Introducing Project Graffiti\n>> Importance: High\n>>\n>> On 05/05/14 20:26 +0000, Tripp, Travis S wrote:\n>> >Hello Everybody,\n>> >\n>> >A challenge we\'ve experienced with using OpenStack is discovering, \n>> >sharing,\n>> and correlating metadata across services and different types of \n>> resources. We believe this affects both end users and administrators.\n>>\n>> Hi\n>>\n>> This seems neat, but also seems to have some overlap with glance\'s \n>> new catalog and some of the things Murano are doing. Have you had a look at those efforts?\n>>\n>> -Angus\n>>\n>> >\n>> >For end users, the UI can be too technical and require too much \n>> >pre-existing\n>> knowledge of OpenStack concepts. For example, when you launch \n>> instances, you should be able to just specify categories like \"Big Data\" or an \"OS Family\"\n>> and let the system find the boot source for you, whether that is an \n>> image, snapshot, or volume.  It should also allow finer grained \n>> filtering such as choosing specific versions of software that you want.\n>> >\n>> >For administrators, we\'d like there to be an easier way to \n>> >meaningfully\n>> collaborate on properties across host aggregates, flavors, images, \n>> volumes, or other cloud resources. Today, this often involves \n>> searching wikis and opening the source code.\n>> >\n>> >We, HP and Intel, believe that both of the above problems come back \n>> >to\n>> needing a better way for users to collaborate on metadata across \n>> services and resource types.  We started project Graffiti to explore \n>> ideas and concepts for how to make this easier and more approachable \n>> for end users. We\'re asking for your input and participation to help us move forward!\n>> >\n>> >To help explain the ideas of the project, we have created a quick \n>> >screencast\n>> demonstrating the concepts running under POC code. Please take a look!\n>> >\n>> >\n>> >*         Graffiti Concepts Overview:\n>> >\n>> >o   http://youtu.be/f0SZtPgcxk4\n>> >\n>> >Please join with us to help refine the concepts and identify where \n>> >we can best\n>> fit in to the ecosystem. We have a few blueprints, but they need \n>> additional support outside of the Horizon UI. We believe our best \n>> path is one where we can contribute the Graffiti service as either a \n>> new project in an existing program or as a series of enhancements to \n>> existing projects.  Your insight and feedback is important to us and we look forward to growing this initiative with you!\n>> >\n>> >We have a design session at the summit where we\'d love to have open\n>> discussion with all who can attend:\n>> >\n>> >Juno Summit Design Session\n>> >http://sched.co/1m7wghx\n>> >\n>> >For more info, please visit our wiki:\n>> >\n>> >Project Wiki\n>> >https://wiki.openstack.org/wiki/Graffiti\n>> >\n>> >IRC\n>> >#graffiti on  Freenode<http://freenode.net/>\n>> >\n>> >Related Blueprints\n>> >https://blueprints.launchpad.net/horizon/+spec/instance-launch-using\n>> >-ca\n>> >pability-filtering\n>> >https://blueprints.launchpad.net/horizon/+spec/faceted-search\n>> >https://blueprints.launchpad.net/horizon/+spec/tagging\n>> >https://blueprints.launchpad.net/horizon/+spec/host-aggregate-update\n>> >-me\n>> >tadata\n>> >https://blueprints.launchpad.net/python-cinderclient/+spec/support-v\n>> >olu\n>> >me-image-metadata\n>> >\n>> >Thank you,\n>> >Travis Tripp\n>> >\n>> >\n>>\n>> >_______________________________________________\n>> >OpenStack-dev mailing list\n>> >OpenStack-dev at lists.openstack.org\n>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAM6FM9R4XDWHd08qtkH8cKkxg5pmG16bPi_RJ3HsVYe1xfcyDg@mail.gmail.com>',NULL),('<02393678-8B5B-424E-B723-24E89C1A6915@not.mn>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-07-30 06:52:43',-25200,'2013-07-30 13:52:43',NULL,'[openstack-tc] Update on Spider \"What is Core\" Discussion > F2F\n	meetings at OSCON','This was my biggest concern as well, and I agree that \"reference implementation\" is much better.\n\nOne of my other concerns is coding requirements put onto a particular project (ie Tempest). In an open-source development model, this cannot be coerced, so what is the proposal for how to actually get people to dedicate time to adding functionality? In an extreme sense, what\'s the incentive to go beyond the following implementation?\n\ndef test_is_openstack(self, *a, **kw):\n    \"\"\"Returns True if the target cluster conforms to the OpenStack brand\"\"\"\n    return True\n\nIt would certainly reduce the number if things I need to spend energy thinking about.\n\n\nI will not be able to attend either meeting today. Thierry, you and I need to work together tomorrow on 1.9.1.\n\n--John\n\n\nOn Jul 30, 2013, at 6:00 AM, Rob_Hirschfeld at Dell.com wrote:\n\n> +1  after discussions at OSCON this matches consensus and improves clarity. \n> \n> \n> ----- Original Message -----\n> From: Thierry Carrez [mailto:thierry at openstack.org]\n> Sent: Tuesday, July 30, 2013 03:57 AM\n> To: openstack-tc at lists.openstack.org <openstack-tc at lists.openstack.org>\n> Cc: Hirschfeld, Rob\n> Subject: Re: [openstack-tc] Update on Spider \"What is Core\" Discussion > F2F meetings at OSCON\n> \n> Mark Washenberger wrote:\n>> I am concerned that the wording of item #1 in this list is legislating\n>> from current practice, and in effect would stifle some important types\n>> of innovation and improvement in our architecture.\n>> \n>> I\'m struggling a bit to come up with an improved alternative, but I\n>> think the issue is essentially with the definition of a plugin as\n>> residing behind common code that implements an API. In particular, I\n>> don\'t think plugins necessarily live behind APIs, for example, I could\n>> imagine a plugin implementing a periodic cleanup task on a worker node.\n>> I can also imagine an application or framework that would enable plugins\n>> to directly expose HTTP api routes--in such a case there would be no\n>> common code implementing the API controller in the common sense of the\n>> term. \n>> \n>> Can we use a more generic definition of plugin? To me, a plugin is a\n>> library component that implements a defined interface and can be loaded\n>> into an existing application via that application\'s proper configuration\n>> settings. That definition doesn\'t restrict the sense of a plugin to any\n>> specific technological flavor.\n> \n> I don\'t think the key issue with the current wording is that it reduces\n> the definition of \"plug-in\"... I think the problem is it uses the word\n> \"plug-in\" to designate what ends up being an alternative implementation\n> model.\n> \n> \"Plug-in\" is one of multiple technical strategies to implement optional\n> code paths (to replace or extend functionality). As you mention, plug-in\n> techniques could be used in other parts of the software that have\n> nothing to do with alternative implementation (could be used to\n> implement add-ons as well).\n> \n> I would rather use \"reference implementation\" and \"alternative\n> implementation\" rather than the current \"plug-in\" wording. It would\n> remove the ambiguity and avoid bleeding into technical territory:\n> \n> \"\"\"\n> SINGLE API / MULTIPLE IMPLEMENTATION MODEL DESIRED FOR PROJECTS\n> \n> 1. OpenStack will require an open source reference implementation for\n> projects (if not part of OpenStack, license model for reference\n> implementation must be compatible).\n> \n> 2. Alternate backend implementations must use the common API framework\n> by using common _code_ to implement the API\n> \n> 3. This expects that projects (where technically feasible) are expected\n> to implement a way to plug in alternate implementations.\n> \n> [...]\n> \n> 5. Reference implementations are, by definition, the complete capability\n> set.  It is not acceptable to have \"core\" features that are not\n> functional in the reference implementation\n> \n> [...]\n> \n> 2. This will enable alternate implementations to offer innovative or\n> differentiated features without forcing changes to the reference\n> implementation\n> \n> 3. This will enable the reference to expand without forcing alternatives\n> to match all features and recertify\n> \"\"\"\n> \n> etc.\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130730/77fe815a/attachment.pgp>\n\n','<8ECF809A9B9C9D4190291BA3E1B55E2732856059@AUSX7MCPS301.AMER.DELL.COM>',NULL),('<0239431E587EFB4AAC571DD74E73204B151A2F06@G01JPEXMBYT04>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 02:47:44',0,'2014-07-23 02:47:44',NULL,'[openstack-dev] [swift] Use FQDN in Ring files instead of \"ip\"','Hi,\n\nI want to use FQDN in Ring files instead of \"ip\".\nI tried the following Swift APIs with using FQDN and it succeeded.\n(I used swift1.13.1.)\n\n  - PUT Container\n  - PUT Object\n\nIn some documents there is no info for using FQDN in Ring files.\n\n  - swift 1.13.1 documentation The Rings > List of Devices\n      http://docs.openstack.org/developer/swift/1.13.1/overview_ring.html#list-of-devices\n      -------------------------------------------------------------\n      The IP address of the server containing the device.\n      -------------------------------------------------------------\n  - swift-ring-builder\'s USAGE\n      -------------------------------------------------------------\n      swift-ring-builder <builder_file> add\n          [--region <region>] --zone <zone> --ip <ip> --port <port>\n          --replication-ip <r_ip> --replication-port <r_port>\n          --device <device_name> --meta <meta> --weight <weight>\n      -------------------------------------------------------------\n\nI would like to know whether FQDN in Ring files supports and/or how to evaluate to support FQDN in Ring files.\n\nCould you please advise me for it?\n\nBest Regards,\nKenichiro Matsuda.\n\n\n\n',NULL,NULL),('<0239431E587EFB4AAC571DD74E73204B151A31C8@G01JPEXMBYT04>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 09:29:48',0,'2014-07-23 09:29:48',NULL,'[openstack-dev] [swift] Use FQDN in Ring files instead of \"ip\"','Hi,\n\nThank you for the info.\nI was able to understand that hostname support is under developing.\n\nBest Regards,\nKenichiro Matsuda.\n\n\n\n','<OFB81A423C.FE5498A2-ON48257D1E.0010436C-48257D1E.00109552@cn.ibm.com>',NULL),('<0239431E587EFB4AAC571DD74E73204B1524C64E@G01JPEXMBYT04>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-20 09:28:52',0,'2014-11-20 09:28:52',NULL,'[openstack-dev] [swift] a way of checking replicate completion on\n	swift cluster','Hi,\n\nI would like to know about a way of checking replicate completion on swift cluster.\n(e.g. after rebalanced Ring)\n\nI found the way of using swift-dispersion-report from Administrator\'s Guide.\nBut, this way is not enough, because swift-dispersion-report can\'t checking \nreplicate completion for other data that made by not swift-dispersion-populate.\n\nAnd also, I found the way of using replicator\'s logs from Q&A.\nBut, I would like to more easy way, because check of below logs is very heavy.\n\n  (account/container/object)-replicator * All storage node on swift cluster\n\nCould you please advise me for it?\n\nFindings:\n  Administrator\'s Guide  Cluster Health\n    http://docs.openstack.org/developer/swift/admin_guide.html#cluster-health\n  how to check replicator work complete\n    https://ask.openstack.org/en/question/18654/how-to-check-replicator-work-complete/\n\nBest Regards,\nKenichiro Matsuda.\n\n\n\n',NULL,NULL),('<0239431E587EFB4AAC571DD74E73204B1524DEF2@G01JPEXMBYT04>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-21 05:32:56',0,'2014-11-21 05:32:56',NULL,'[openstack-dev] [swift] a way of checking replicate completion\n on swift cluster','Hi,\n\nThank you for the info.\n\nI was able to get replication info easily by swift-recon API.\nBut, I wasn\'t able to judge whether no failure from recon info of object-replicator.\n\nCould you please advise me for a way of get object-replicator\'s failure info?\n\n[replication info from recon]\n* account\n------------------------------------------------------------------------------\n# curl http://192.168.1.11:6002/recon/replication/account | python -mjson.tool\n{\n    \"replication_last\": 1416354262.7157061,\n    \"replication_stats\": {\n        \"attempted\": 20,\n        \"diff\": 0,\n        \"diff_capped\": 0,\n        \"empty\": 0,\n        \"failure\": 20,\n        \"hashmatch\": 0,\n        \"no_change\": 40,\n        \"remote_merge\": 0,\n        \"remove\": 0,\n        \"rsync\": 0,\n        \"start\": 1416354240.9761429,\n        \"success\": 40,\n        \"ts_repl\": 0\n    },\n    \"replication_time\": 21.739563226699829\n}\n------------------------------------------------------------------------------\n\n* container\n------------------------------------------------------------------------------\n# curl http://192.168.1.11:6002/recon/replication/container | python -mjson.tool\n{\n    \"replication_last\": 1416353436.9448521,\n    \"replication_stats\": {\n        \"attempted\": 13346,\n        \"diff\": 0,\n        \"diff_capped\": 0,\n        \"empty\": 0,\n        \"failure\": 870,\n        \"hashmatch\": 0,\n        \"no_change\": 1908,\n        \"remote_merge\": 0,\n        \"remove\": 0,\n        \"rsync\": 0,\n        \"start\": 1416349377.3627851,\n        \"success\": 1908,\n        \"ts_repl\": 0\n    },\n    \"replication_time\": 4059.5820670127869\n}\n------------------------------------------------------------------------------\n\n* object\n------------------------------------------------------------------------------\n# curl http://192.168.1.11:6002/recon/replication | python -mjson.tool\n{\n    \"object_replication_last\": 1416334368.60865,\n    \"object_replication_time\": 2316.5563162644703 \n} \n# curl http://192.168.1.11:6002/recon/replication/object | python -mjson.tool\n{\n    \"object_replication_last\": 1416334368.60865,\n    \"object_replication_time\": 2316.5563162644703 \n}\n------------------------------------------------------------------------------\n\nBest Regards,\nKenichiro Matsuda.\n\n\nFrom: Clay Gerrard [mailto:clay.gerrard at gmail.com] \nSent: Friday, November 21, 2014 4:22 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster\n\nYou might check if the swift-recon tool has the data you\'re looking for.? It can report the last completed replication pass time across nodes in the ring.\n\nOn Thu, Nov 20, 2014 at 1:28 AM, Matsuda, Kenichiro <matsuda_kenichi at jp.fujitsu.com> wrote:\nHi,\n\nI would like to know about a way of checking replicate completion on swift cluster.\n(e.g. after rebalanced Ring)\n\nI found the way of using swift-dispersion-report from Administrator\'s Guide.\nBut, this way is not enough, because swift-dispersion-report can\'t checking\nreplicate completion for other data that made by not swift-dispersion-populate.\n\nAnd also, I found the way of using replicator\'s logs from Q&A.\nBut, I would like to more easy way, because check of below logs is very heavy.\n\n? (account/container/object)-replicator * All storage node on swift cluster\n\nCould you please advise me for it?\n\nFindings:\n? Administrator\'s Guide? Cluster Health\n? ? http://docs.openstack.org/developer/swift/admin_guide.html#cluster-health\n? how to check replicator work complete\n? ? https://ask.openstack.org/en/question/18654/how-to-check-replicator-work-complete/\n\nBest Regards,\nKenichiro Matsuda.\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CA+_JKzq22wQP3AG32M_0f4d1nsA8h=ekFt=KYeT4yzd2AbNP-A@mail.gmail.com>',NULL),('<0239431E587EFB4AAC571DD74E73204B1525EB02@G01JPEXMBYT04>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 07:37:07',0,'2014-11-25 07:37:07',NULL,'[openstack-dev] [swift] a way of checking replicate completion\n on swift cluster','Hi,\n\nThanks for your advice.\n\nI understood that the logs are necessary to judge whether no failure on \nobject-replicator.\nAnd also, I thought that the recon info of object-replicator having failure \n(just like the recon info of account-replicator and container-replicator) \nis useful.\nAre there any reason to not included failure in recon?\n\nKenichiro Matsuda.\n\n> -----Original Message-----\n> From: Clay Gerrard [mailto:clay.gerrard at gmail.com] \n> Sent: Tuesday, November 25, 2014 5:53 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster\n>\n> replication logs\n>\n> On Thu, Nov 20, 2014 at 9:32 PM, Matsuda, Kenichiro <matsuda_kenichi at jp.fujitsu.com> wrote:\n> Hi,\n>\n> Thank you for the info.\n>\n> I was able to get replication info easily by swift-recon API.\n> But, I wasn\'t able to judge whether no failure from recon info of object-replicator.\n>\n> Could you please advise me for a way of get object-replicator\'s failure info?\n\n\n','<CA+_JKzrppJN_AjL5pZCa2nzaYFHd3HZmAuZ+BV-u9C0x4asb2Q@mail.gmail.com>',NULL),('<023d01d00a24$e3fea040$abfbe0c0$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-27 16:31:11',25200,'2014-11-27 09:31:11',NULL,'[Openstack] OpenStack Regions','Hello \n\n \n\nI have a question regarding regions. We have the initial \"RegionOne\" in our\ncurrent setup and want to and a second one \"RegionTwo\".\n\nIt seems like the shared services between different regions are Keystone and\nHorizon. The separate services for each region includes Nova, Neutron etc.\nPlease correct me here if I\'m wrong.\n\n \n\nWhat about the database, does the services from RegionTwo use the initial\ndatabase from RegionOne or does RegionTwo also needs a new database?   \n\n \n\nCheers\n\nChris\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141127/1af0ce60/attachment.html>\n\n',NULL,NULL),('<024782F3-8164-42BB-9D5D-79F6C937EC79@owncloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 21:01:21',-14400,'2014-07-04 01:01:21',NULL,'[Openstack] ownCloud and openstack','Hi everyone,\n\n\nTom Fifield recommended that I send a message to this list.\n\nAs some of you might know we at ownCloud just added Swift support as primary storage to ownCloud. This will be released as part of our upcoming release 7 in about 3 weeks.\n\nThe code can be seen here.\nhttps://github.com/owncloud/core/pull/8383\n\n\nownCloud is a fully open source solution that can be used a self hosted Dropbox or Google Drive alternative. The new Swift backend is an important step for us to mask ownCloud more scalable, easier to deploy in bigger setups and integrate it better into OpenStack.\n\nTom suggested to ask here for testers who are willing to try ownCloud 7 together with Swift.\nWe just announced the RC1 a few minutes ago:\nhttp://mailman.owncloud.org/pipermail/announcements/2014-July/000049.html\n\n\nSo it would be great if you guys could give it a test and give some feedback.\n\n\nThanks a lot\n\n\nCheers\nFrank\n\n',NULL,NULL),('<025301cfbb57$0463c530$0d2b4f90$@progbau.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-19 09:40:59',25200,'2014-08-19 02:40:59',NULL,'[Openstack] Routed management network','Hello,\n\n \n\nIs it possible to have a routed management network, especially in terms of\nthe neutron dhcp server and metadata agent?\n\n \n\nThanks in advance!\n\n \n\nGreetings\n\nChris\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140819/f5f953af/attachment.html>\n\n',NULL,NULL),('<025601cfc2a5$2e75acd0$8b610670$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-28 17:48:11',28800,'2014-08-28 09:48:11',NULL,'[Openstack] [openstack] Documents of Notifications','Hi folks,\n\nI\'m working on a program which receives all error/warn notifications from\nopenstack and translate them into human readable notifications. So I\ndesperately need a document describing all notifications. I\'ve found one\ndocument on wiki (https://wiki.openstack.org/wiki/SystemUsageData) but it\'s\nincomplete. And there\'s a list of nova \"event_type\"\n(http://paste.openstack.org/show/54140/) but lack of events from\ncinder/neutron/glance.\n\nI wonder if there are documents that can cover most of the notifications.\nCan anyone please kindly tell me where to look? Or maybe just tell me\n\"there\'s no such a thing, just face it!\" so that I can save my time and try\nsome other approaches.\n\n\nThanks a lot!!\nKurt Rao\n\n\n\n\n',NULL,NULL),('<025763C8-A050-4D85-865E-67598FAB25F1@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 10:30:06',0,'2014-07-07 10:30:06',NULL,'[openstack-dev] [TripleO] [Windows] New Windows Disk Image\n Builder Project','Hi Om,\n\nGreat news! Looking forward for a link to a repo to check it out.\n\nThanks,\n\nAlessandro\n\nOn 07.07.2014, at 11:03, \"Kumar, Om (Cloud OS R&D)\" <om.kumar at hp.com<mailto:om.kumar at hp.com>> wrote:\n\nHi All,\n\nWe have just finished 1st version of Windows Disk Image Builder tool. This tool is written in PowerShell and uses Batch scripts. Currently, it runs on Windows. The silent features of the tool are as follows:\n\n1.       Uses Windows ISO/user provided WIM files to create VHD file.\n\n2.       Can generate GPT/MBR Disk Images.\n\n3.       Injects Cloud-base Init.\n\n4.       Injects third party drivers (Out of Box Drivers) for use with Baremetal servers.\n\n5.       Pulls all Windows updates and applies on the image being created.\n\n6.       The Image can be used for KVM/Hyper-V/Baremetal (Subject to appropriate drivers being injected).\n\n7.       It can generate Images for Windows 7 and above and Windows 2008 and above.\n\n8.       All this is done without spawning/standing up a VM.\n\nWe would like to contribute this to OpenStack for adoption under TripleO Umbrella as a new Windows Disk image builder project.\n\nPlease let me know your thoughts/suggestions on the same. Also if there is anything that needs to be addressed before adoption under TripleO.\n\nRegards,\nOm\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/82307929/attachment.html>\n\n','<6DD8EBD06D54DE4AB28A4D10B7FA3B38756D1FBA@G9W0341.americas.hpqcorp.net>',NULL),('<025b50da0b22aca72191ce39776cc329@mail.gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-11-02 09:17:16',39600,'2013-11-01 22:17:16',NULL,'[openstack-community] Setting up an OpenStack User Group in\n	Bulgaria','Hello Ina,\n\n\n\nA warm welcome to you and your new community in Bulgaria! I am sure the\ncommunity managers on the list can arrange for you to be included in the\nUser Group listing. I am suspecting a lot of people on this list are very\nbusy this weekend preparing for the Hong Kong Summit next week but I am\nsure they will get to it as soon as they can! Do you have a URL that your\nnew user group site that they can post? If you need other assistance please\ndon?t hesitate to ask.\n\n\n\nCheers\n\nTristan\n\nAustralian UG organizer\n\nhttp://aosug.openstack.org.au/\n\n\n\n\n\n*From:* Ina Dobrilova [mailto:Ina.Dobrilova at telerik.com]\n*Sent:* Friday, 1 November 2013 8:42 PM\n*To:* community at lists.openstack.org\n*Cc:* Alexandra Mechkova\n*Subject:* [openstack-community] Setting up an OpenStack User Group in\nBulgaria\n\n\n\nHello,\n\n\n\nMy name is Ina Dobrilova and I am an Administrative and Marketing Associate\nat Telerik, an end-to-end provider of application development tools and\nsolutions for building and analyzing cross-platform and mobile\napplications. As a leading software development provider, Telerik is very\nenthusiastic about setting up the first OpenStack user group in Bulgaria to\nnurture a vibrant local OpenStack community. We followed the guidelines on\nthe OpenStack website for starting a user group, including subscribing to\nthe community mailing list, and adding information and contact details on\nthe OpenStack website <https://wiki.openstack.org/wiki/OpenStackUserGroups>.\n\n\nNext, we are planning to create a special website, entirely dedicated to\nthe OpenStack UserGroup, and to start recruiting and building the OpenStack\ncommunity in Bulgaria. Before the public announcement of the Bulgarian\nOpenStack Group, however, we wanted to verify with you whether or not any\nadditional steps need to be taken. Also, we?d like to inquire about how we\ncould be included in the first list on the\nwebsite<https://wiki.openstack.org/wiki/OpenStackUsersGroup> and\non the official map <http://www.openstack.org/community/> of OpenStack\nGroups worldwide.\n\n\n\nWe are looking forward to your reply and would be happy to answer any\nquestions you might have.\n\n\n\nBest Regards,\n\nIna Dobrilova\n\n\n\n\n\n*INA DOBRILOVA*\n\nADMINISTRATIVE AND MARKETING\n\nASSOCIATE | TELERIK CORP.\n\n* *\n\n*email: ina.dobrilova at telerik.com***\n\n*mobile: *+359.887.402.155\n\n*address:* 31 Alexander Malinov Blvd.,\n\n              Sofia 1729, Bulgaria, floor 2\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131102/538cc63c/attachment.html>\n\n','<EE286587048BE44AAA134695B98C70090502D093@EXCHBG02.telerik.com>',NULL),('<025DCAD3-C1FF-4F16-963B-8867E7DFE2CF@not.mn>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-15 08:09:57',-28800,'2013-12-15 16:09:57',NULL,'[openstack-community] Bringing focus to the Operators and Users\n	at the next summit','We had a really good (and unexpected) experiment with something similar during the Swift sessions in Hong Kong. One of the technical sessions was led by a Swift contributor who brought a use case and a set of very practical questions about what using Swift as part of the entire storage system would look like. In this particular case, it was exploring the use of Swift as storage for the LINE messaging app <http://en.wikipedia.org/wiki/Line_(application)>.\n\nWhen considering any OpenStack project in production system, many factors must be considered. These are the sort of questions that come up every day as part of a sales process (even if that sales process is simply convincing other internal people to use something). Questions like: What\'s the pain point with the system it\'s replacing? How does it integrate with existing policies and procedures? Does it functionally meet all current requirements, or is additional development work needed? etc.\n\nIn the case of LINE discussion for Swift, we had to consider questions around global distribution, hot content, supporting a billion users (ie auth questions), and other questions related to supporting a massively popular mobile application. One thing I liked about the discussion is that it wasn\'t a slam-dunk traditional use case. There were areas where Swift was a great fit for the LINE app, and there were areas where new functionality would be required to better support their use case.\n\nThese sort of discussions happen every day as vendors are pitching their OpenStack wares to potential new users. The good parts about the discussion in HK was that it was an engineer-to-engineer discussion (with no related product sales pitch), and it exposed the active Swift contributors gathered in HK to the varied use cases that face real-world deployments. It\'s this kind of feedback that is essential for keeping the code relevant and the vision fresh.\n\nI got lots of positive feedback after the LINE session in HK, and it\'s something I\'ll be actively seeking out for Atlanta. It\'s got to be balanced so it doesn\'t turn into a vendor honeypot, but I definitely want to have one session during the Swift technical track at the next summit focused on sussing out requirements for a hard real-world use case. I\'d encourage other OpenStack projects to do the same.\n\n--John\n\n\n\n\n\nOn Dec 14, 2013, at 11:29 PM, Tristan Goode <tristan at aptira.com> wrote:\n\n> That\'s a bunch of talks. What I\'m trying to establish is a feedback loop.\n> \n> \n>> -----Original Message-----\n>> From: Jeremy Stanley [mailto:fungi at yuggoth.org]\n>> Sent: Sunday, 15 December 2013 10:41 AM\n>> To: community at lists.openstack.org\n>> Subject: Re: [openstack-community] Bringing focus to the Operators and\n> Users at\n>> the next summit\n>> \n>> On 2013-12-13 18:26:43 +0300 (+0300), Adam Nelson wrote:\n>> [...]\n>>> a track dedicated to those managing existing clouds or installing them\n>>> could really benefit from sharing their experiences in a dedicated\n>>> way.\n>> \n>> Perhaps I\'m misunderstanding, but at the last summit (as at previous\n> ones) we had\n>> an \"Operations\" track. It ran pretty much solid for three days\n> straight...\n>> \n>> http://openstacksummitnovember2013.sched.org/overview/type/operations\n>> \n>> It sounds like energy would be best directed into improving and\n> redirecting that, if\n>> it\'s not meeting the current needs of deployer/operator attendees?\n>> --\n>> Jeremy Stanley\n>> \n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131215/2e21788a/attachment.pgp>\n\n','<4738afcc6c272932c0a684eb61572e38@mail.gmail.com>',NULL),('<026501cf90f8$3ab62b20$b0228160$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 13:36:42',32400,'2014-06-26 04:36:42',NULL,'[openstack-dev] [Keystone] Token invalidation in deleting role\n	assignments','Dolph,\n\nThank you so much.\nI understand that using OS-REVOKE Extension will solve these issues.\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\nFrom: Dolph Mathews [mailto:dolph.mathews at gmail.com] \nSent: Thursday, June 26, 2014 12:11 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Keystone] Token invalidation in deleting role assignments\n\nThis is a known limitation of the token backend and the token revocation list: we don\'t index tokens in the backend by roles (and we don\'t want to iterate the token table to find matching tokens).\n\nHowever, if we land support for token revocation events [1] in the auth_token [2] middleware, we\'ll be able to deny tokens with invalid roles as they are presented to other services.\n\n[1] https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-revoke-ext.md\n[2] https://launchpad.net/keystonemiddleware\n\nOn Wed, Jun 25, 2014 at 1:19 AM, Takashi Natsume <natsume.takashi at lab.ntt.co.jp> wrote:\nHi all,\n\nWhen deleting role assignments, not only tokens that are related with\ndeleted role assignments but also other tokens that the(same) user has are\ninvalidated in stable/icehouse(2014.1.1).\n\nFor example,\nA) Role assignment between domain and user by OS-INHERIT(*1)\n1. Assign a role(For example,\'Member\') between \'Domain1\' and \'user\' by\nOS-INHERIT\n2. Assign the role(\'Member\') between \'Domain2\' and \'user\' by OS-INHERIT\n3. Get a token with specifying \'user\' and \'Project1\'(in \'Domain1\')\n4. Get a token with specifying \'user\' and \'Project2\'(in \'Domain2\')\n5. Create reources(For example, cinder volumes) in \'Project1\' with the token\nthat was gotten in \"3.\"\n    it is possible to create them.\n6. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is possible to create them.\n7. Delete the role assignment between \'Domain1\' and \'user\' (that was added\nin \"1.\")\n\n(After validated token cache is expired in cinder, etc.)\n8. Create reources in \'Project1\' with the token that was gotten in \"3.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n9. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n\nIn \"9.\", my expectation is that it is possible to create resources with the\ntoken that was gotten in \"4.\".\n\n*1:\nv3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_\nto_projects\n\nB) Role assignment between project and user\n1. Assign a role(For example,\'Member\') between \'Project1\' and \'user\'\n2. Assign the role(\'Member\') between \'Project2\' and \'user\'\n3. Get a token with specifying \'user\' and \'Project1\'\n4. Get a token with specifying \'user\' and \'Project2\'\n5. Create reources(For example, cinder volumes) in \'Project1\' with the token\nthat was gotten in \"3.\"\n    it is possible to create them.\n6. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is possible to create them.\n7. Delete the role assignment between \'Project1\' and \'user\' (that was added\nin \"1.\")\n\n(After validated token cache is expired in cinder, etc.)\n8. Create reources in \'Project1\' with the token that was gotten in \"3.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n9. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n\nIn \"9.\", my expectation is that it is possible to create resources with the\ntoken that was gotten in \"4.\".\n\n\nAre these bugs?\nOr are there any reasons to implement these ways?\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n',NULL,NULL),('<02692FAC-4742-4B76-A5C8-674C9A4D273C@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-07 19:15:05',0,'2013-08-07 19:15:05',NULL,'[Openstack-docs] validate.py error','validate.py is excluding openstack-training in build_all_books as well. Should I be changing\n\nBOOK_EXCEPTIONS = [\'openstack-training\']\nto\nBOOK_EXCEPTIONS = []\n\nas well as\n\ndef main(rootdir):\n    validate_individual_files(rootdir, FILE_EXCEPTIONS)\n    build_all_books(rootdir, BOOK_EXCEPTIONS)\n\nto\n\ndef main(rootdir):\n    \"\"\" validate_individual_files(rootdir, FILE_EXCEPTIONS) \"\"\"\n    build_all_books(rootdir, BOOK_EXCEPTIONS)\n\n\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com> (925) 980-4729\n\nOn Aug 7, 2013, at 11:58 AM, Lorin Hochstein <lorin at nimbisservices.com<mailto:lorin at nimbisservices.com>>\n wrote:\n\nSean:\n\nIf the XML validation is giving a false positive, I suggest we turn it off. The validate.py script now uses maven to build all of the books.  Just remove the call to validate_individual_files in the \"main\" function.\n\n\nLorin\n\n\nOn Wed, Aug 7, 2013 at 2:38 PM, Sean Roberts <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\nI have a validate.py problem, anyone up for debugging with me?\nLocal maven runs clean\n\njenkins fails http://logs.openstack.org/50/40550/1/check/gate-openstack-manuals-validate/e3d606e/console.html\n\n...\n\n+ ./tools/validate.py\n/home/jenkins/workspace/gate-openstack-manuals-validate/doc/src/docbkx/openstack-training/bk001-ch003-associate-general.xml:5:0:ERROR:RELAXNGV:RELAXNG_ERR_ELEMNAME: Expecting element section, got chapter\n/home/jenkins/workspace/gate-openstack-manuals-validate/doc/src/docbkx/openstack-training/bk001-ch003-associate-general.xml:13:0:ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element chapter has extra content: include\n/home/jenkins/workspace/gate-openstack-manuals-validate/doc/src/docbkx/openstack-training/bk001-ch003-associate-general.xml:9:0:ERROR:RELAXNGV:RELAXNG_ERR_ELEMWRONG: Did not expect element para there\n/home/jenkins/workspace/gate-openstack-manuals-validate/doc/src/docbkx/openstack-training/bk001-ch003-associate-general.xml:5:0:ERROR:RELAXNGV:RELAXNG_ERR_ELEMWRONG: Did not expect element chapter there\n/home/jenkins/workspace/gate-openstack-manuals-validate/doc/src/docbkx/openstack-training/bk001-ch003-associate-general.xml:5:0:ERROR:RELAXNGV:RELAXNG_ERR_ELEMNAME: Expecting element set, got chapter\n...\n\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com> (925) 980-4729\n\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com<http://www.nimbisservices.com/>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130807/92fbf1ad/attachment-0001.html>\n\n','<CADzpNMVg6CBwmxBmb+0ySN4FCTFCDL0JdxRigsY+vSMRTTa68Q@mail.gmail.com>',NULL),('<0269603E-3C03-4A56-B99C-C824FF69ACD5@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 15:54:32',0,'2014-08-21 15:54:32',NULL,'[openstack-dev] [Congress] Policy Enforcement logic','Hi Madhu,\n\nFor the alpha release (due soon), we?re focusing on just monitoring policy violations?we?ve disabled all the enforcement code in master.  (Though we never actually hooked up the enforcement policy to the real world, so all Congress has ever done is compute what actions to take to enforce policy.)  There?s a ton of interest in enforcement, so we?re planning to add enforcement features to the beta release.\n\nTim\n\n\nOn Aug 21, 2014, at 7:07 AM, Madhu Mohan <mmohan at mvista.com<mailto:mmohan at mvista.com>> wrote:\n\nHi,\n\nI am quite new to the Congress and Openstack as well and this question may seem very trivial and basic.\n\nI am trying to figure out the policy enforcement logic,\n\nCan some body help me understand how exactly, a policy enforcement action is taken.\n\n>From the example policy there is an action defined as:\n\naction(\"disconnect_network\")\nnova:network-(vm, network) :- disconnect_network(vm, network)\n\nI assume that this statement when applied would translate to deletion of entry in the database.\n\nBut, how does this affect the actual setup (i.e) How is this database update translated to actual disconnection of the VM from the network.\nHow does nova know that it has to disconnect the VM from the network ?\n\nThanks and Regards,\nMadhu Mohan\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/9169fb0e/attachment.html>\n\n','<CAGwXsr1--7h9XPiDHoZUZqe4_SEBwbvAcd6G=-aqBvYZnpQ0KA@mail.gmail.com>',NULL),('<02702FCB-3176-49FF-8B14-1FC8FC94F4E4@intel.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-12 15:41:29',0,'2013-08-12 15:41:29',NULL,'[Openstack-operators] OVS vswitchd log warnings','I noticed this over the weekend as well.  I believe this is OVS trying to manipulate the tap device that is created for quantum-dhcp-agent.  If you have namespaces enabled, the tap device is not configurable from outside the netns, and that\'s what OVS is trying to do repeatedly.\n\nI\'m not sure if it\'s harmful or not - it doesn\'t appear to be.   The DHCP agent is working just fine.\n\nCheers,\nJim Chamings\n\n\nOn Aug 12, 2013, at 7:41 AM, Samuel Winchenbach <swinchen at gmail.com> wrote:\n\n> Hi all, I posted a message a while ago in the openstack@ mailing list about some warnings I am getting with openvswitch.\n> \n> This is the post I made:  https://lists.launchpad.net/openstack/msg24745.html\n> \n> Does the first response make sense?  Are other people seeing warnings such as:\n> \n> /var/log/openvswitch/ovs-vswitchd.log:Aug 12 10:33:36|80611|netdev|WARN|Dropped 159 log messages in last 12 seconds (most recently, 1 seconds ago) due to excessive rate\n> /var/log/openvswitch/ovs-vswitchd.log:Aug 12 10:33:36|80612|netdev|WARN|failed to get flags for network device tap37874e8e-0e: No such device\n> \n> \n> When using ovs with grizzly?\n> \n> Thanks,\n> Sam\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130812/cf647086/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 5093 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130812/cf647086/attachment.bin>\n\n','<CAK9s_NyNt_esnojhNAOh6Zv65qh5_gg5Yefou+d+4yw9SZO6+g@mail.gmail.com>',NULL),('<02716D55-F211-4734-A635-34A254FBDDEC@not.mn>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-21 15:49:58',-25200,'2014-03-21 22:49:58',NULL,'[openstack-tc] Meeting to develop a straw man set of designated\n	sections','I have a couple of questions that came to mind while I was reviewing the wiki and figuring out what to put into the etherpad.\n\nFirst, it seems that all of the \"core capabilities\" are exposed by a [\"single\"|\"set of\"] tempest tests. This means that 6.13 (\"Consumers must have a way to determine how the system is different from reference (posted, discovered, etc)\") must be something that is able to be determined by tempest, right?\n\nIf that is the case, here is my question: How does this work? Doesn\'t tempest do functional tests of the API? So what if a \"designated section\" isn\'t visible to the API? How is it tested by tempest and how is it therefore in or out of core?\n\nThese questions lead me to one of two possibilities: (1) \"OpenStack Core\" is only related to an external API or (2) Tempest will significantly change to do more invasive tests[1]. Can someone provide some guidance here?\n\n(I hesitate to provide a specific use case here, although I do have one, because I\'d like the answer to the general case.)\n\nSecond, and more of a high-level issue, section 8.1 says that there will be an OpenStack body which recommends which tests are \"must-pass\". Section 9.1 implies that the DefCore team has some influence here (the recommendations pass through this group). Who is this group, and why is it not automatically the core-team/PTLs (passing through the TC)?\n\n--John\n\n\n\n[1] By \"invasive tests\" I mean tests that know about (and perhaps modify) internal cluster state in the course of testing. These types of tests are extremely valuable, but are not what tempest does today, AFAIK.\n\n\nOn Mar 21, 2014, at 6:41 AM, Anne Gentle <anne at openstack.org> wrote:\n\n> \n> \n> \n> On Fri, Mar 21, 2014 at 4:10 AM, Thierry Carrez <thierry at openstack.org> wrote:\n> Michael Still wrote:\n> > So, the defcore committee just had a meeting and I have to say it was\n> > a lot more productive than the previous one. I\'m sure the recording\n> > will appear on YouTube at some point, but I am not sure when that will\n> > be.\n> >\n> > There is a desire to have a voice chat to interactively produce an\n> > etherpad that contains straw man designated sections for the various\n> > integrated projects. I personally think this is a good idea, because I\n> > think it will be more productive than yet another email thread.\n> >\n> > So... Who is available for either of these time slots next week?\n> >\n> >  * Wednesday 26 March at 8pm UTC\n> >  * Friday 28 March at 8pm UTC\n> \n> Shouldn\'t this call also be directed to the integrated projects PTLs,\n> rather than just the TC members ? IMHO the PTLs are the final authority\n> for producing this information, with the TC providing guidance and\n> encouraging some homogeneity.\n> \n> Here is a list of people that need to be looped in (Icehouse release):\n> David Lyle (Horizon)\n> Dolph Mathews (Keystone)\n> John Dickinson (Swift)\n> Julien Danjou (Ceilometer)\n> Mark Washenberger (Glance)\n> Michael Basnight (Trove)\n> Steve Baker (Heat)\n> \n> The other integrated projects PTLs (Nova, Cinder, Oslo, Neutron) also\n> seat on the TC.\n> \n> \n> Thanks for the list, Thierry. Adding them to this thread. (There\'s no all-PTL mailing list I should use, right?)\n> \n> The request: we\'re looking for designated sections of your program\'s code to help define criteria for \"core definition\" where core definition is part of our governance docs at https://wiki.openstack.org/wiki/Governance/CoreDefinition. \n> \n> Who wants it: The board members working on core definition\n> \n> What does it get them: Forward movement on defining the OpenStack mark use policies\n> How will they know if they have it: The etherpad at https://etherpad.openstack.org/p/openstack-designated-sections will have your project\'s name in it with simple definitions of what parts of your code base should be run. (Do not overthink this: simple outlines will suffice.)\n> \n> When do they need it by: 3/31 (I know this is a busy time for everyone with the release. Please raise your hand if you need help, we will find it for you.)\n> \n> Who might be exempt: We do not need all projects to designate sections, only the ones that are likely to have capabilities flagged by required tests. If you think yours lands in this exempt category, just ask. \n> \n> What happens if this doesn\'t get done: We continue to struggle with the definition of an OpenStack cloud. Probably someone else will define for you (which is also likely just fine).\n> \n> Let me know if this request outline is useful and feel free to ask any questions as you go.\n> \n> Anne\n>  \n> --\n> Thierry Carrez (ttx)\n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140321/76ab0e60/attachment.pgp>\n\n','<CAD0KtVH=5tBdcH7JX1cSZpfuYWR=Ck956djBFmYkjTPTGSWEng@mail.gmail.com>',NULL),('<027285C8-8B35-476D-AF01-8502804B7BA2@RACKSPACE.COM>','http://lists.openstack.org/pipermail/user-committee',NULL,'2013-04-24 19:27:08',0,'2013-04-24 19:27:08',NULL,'[User-committee] Weekly community newsletter - deployment news','On Apr 24, 2013, at 1:44 PM, Stefano Maffulli wrote:\n\n> I hate to answer with a question: which newsletter are you referring to? The weekly newsletter that I send out on Friday\'s is a simple email message that goes to 3 mailing lists (openstack-announce, openstack General and openstack-community) and the blog. It\'s titled \"OpenStack Community Weekly Newsletter\". There is no way to have demographic of email addresses that subscribe to those lists or any meaningful number.\n\nI did mean the OpenStack Community Weekly Newsletter. I guess I thought that since you also published it as a blog post on openstack.org that you might have some analytics from that.\n\n','<517827F4.7030000@openstack.org>',NULL),('<0278CFEE-057E-4FD4-A1C9-089D07703DE5@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 07:44:51',-28800,'2013-12-13 15:44:51',NULL,'[openstack-dev] [Solum] Using Zuul in the Git-pull blueprint','On Dec 12, 2013, at 1:39 PM, devdatta kulkarni <devdatta.kulkarni at rackspace.com> wrote:\n\n> We followed on the Zuul question in this week\'s git-integration working group meeting.\n> \n> mordred has created an etherpad with a high-level description of Zuul and how it might\n> fit with Solum\'t git integration workflow\n> \n> https://etherpad.openstack.org/p/ZuulSolum\n> \n> The working group seemed to be coming to the consensus that we want to use a single workflow\n> engine, as far as possible, for all of Solum\'s workflow needs.\n> This brought up the question about, what are really Solum\'s workflow requirements. \n\nHi\n\nI had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group.\nI have also included answers to the questions below.\n\n> \n> At a high-level, I think that Solum has three different kinds of workflows.\n> \n> 1) Workflow around getting user code into Solum\n>   - This is the git integration piece being worked out in the git-integration\n>     working group.\n\nThis is possible using the Zuul workflows. Would potentially require a little work in Zuul.\n\n> \n> 2) Workflow around creating language pack(s).\n>   - The main workflow requirement here involves ability to run tests before creating a language pack.\n>     There was some discussion in language-pack working group about this requirement.\n\nThis is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows\nthat could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git \nand a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc.\nThis would be possible through Zuul without having to reinvent it on the other workflow engine.\n\n> \n> 3) Workflow around deploying created language pack(s) in order to instantiate an assembly.\n>   - The deployment may potentially contain several steps, some of which may be long running, such as\n>   populating a database. Further, there may be a need to checkpoint intermediate steps\n>   and retry the workflow from the failed point.\n\nThis is probably not a very good fit for Zuul. It can handle simple workflow but won?t be able to do the\ncomplex checkpointing, rollback, retry logic etc.\n\n> \n> \n> mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum)\n> We want to know if #2 and #3 can also be achieved by Zuul.\n> If not, we want to know what are the available options.\n> \n> mordred, thanks for the etherpad; looking forward to the digram :)\n\n\nZuul is workflow engine capable of running simple workflows. It is probably not suitable for all of Solum but would\nmanage the source -> DU flow quite nicely. Initially my thoughts were that I wanted to avoid having 2 workflow\nengines in Solum but there is another way to look at it?\n\nDuring out F2F, we had said that we should have a Solum API where we could just post DU images. This would\nallow someone to build the DU outside Solum and just provide it. We could use this same API as a clean interface to\nseparated out the DU build flow from the DU deploy flow. Once this is done, the DU build flow (#1, #2 above)\ncould be cleanly handled by Zuul and the DU deploy flow by whatever complex engine the rest of Solum would\nuse.\n\nThis approach has a few advantages:\n	* Re-uses what Openstack already uses but its build & CI process (and potentially makes it better)\n	* Allows operations who deploy Solum to customize their build process without having to change Solum\n	* Allows us to leverage the Zuul/OpenStack-infra team to help us solve the DU build flow instead of having \n	  to go alone\n\n?Krishna\n\n> \n> \n> thanks,\n> devkulkarni\n> \n> \n> -----Original Message-----\n> From: \"Roshan Agrawal\" <roshan.agrawal at RACKSPACE.COM>\n> Sent: Monday, December 9, 2013 10:57am\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n> \n> \n>> -----Original Message-----\n>> From: Krishna Raman [mailto:kraman at gmail.com]\n>> Sent: Sunday, December 08, 2013 11:24 PM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n>> \n>> Hi all,\n>> \n>> We had a very good meeting last week around the git-pull blueprint. During\n>> the discussion, Monty suggested using Zuul to manage the git repository\n>> access and workflow.\n>> While he is working on sending the group a diagram and description of what\n>> he has in mind, I had a couple of other questions which I am hoping the\n>> extended group will be able to answer.\n>> \n>> 1) Zuul is currently an infrastructure project.\n>> 	- Is there anything that prevents us from using it in Solum?\n>> 	- Does it need to be moved to a normal OpenStack project?\n>> \n>> 2) Zuul provides a sort of workflow engine. This workflow engine could\n>> potentially be used to initiate and manage: API Post -> git flow -> lang pack\n>> flow.\n>> 	- Have there been any discussion after the F2F where we have\n>> discussed using some other workflow engine?\n> \n> There hasn\'t been further discussion since F2F.\n> Most of the processes in Solum will really be customizable workflows, and use of a generic workflow engine is definitely worth discussing. We may still use to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow needs beyond that. \n> \n>> 	- Is Zuul\'s engine generic enough to be used in Solum? (Hoping\n>> Monty can help with this one)\n>> 		- Perhaps only use it to manage the API post -> git flow\n>> stages?\n>> \n>> Thanks\n>> -Krishna\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1386884397.072212175@apps.rackspace.com>',NULL),('<027a01cdd398$774b84a0$65e28de0$@com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-06 18:00:05',28800,'2012-12-06 10:00:05',NULL,'[openstack-dev] openstack floating ip problem','Hi all, I encountered one problem about floating IP.\n\n \n\nMy node has two eth cards, eth0 for br100 and eth1 for floating ip, and I\nallocated one public IP (220.X.X.X) to one vm as a floating IP, but when I\npinged from another computer, the packets do arrive at eth1, but the icmp\npackets did not transfer to br100 due to NAT.\n\n \n\nAnyone can help me? I am really frustrated\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121206/fab13fda/attachment.html>\n\n','<CAC=h7gWxF_6ycW4zv1BS9ajvw27UqZXEYAUG65r4bFA784=47w@mail.gmail.com>',NULL),('<027f01cdee50$862f65e0$928e31a0$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-09 14:03:06',14400,'2013-01-09 10:03:06',NULL,'[openstack-dev] [quantum][LBaaS] need to\n	do	corresponding	changes in LBaaS API doc','Hi Youcef,\n\nI?m not sure if it would be possible to call LBaaS API without keystyone AuthN. If it is than I think tenant_id is required ? at least it should be verified that tenant_id is the same as tenant_id which the pool belongs to (or it is admin tenant id).\n\nOtherwise I agree that for the case of associating a health monitor with a pool tenant_id is redundant.\n\n \n\nThanks,\n\nOleg\n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Thursday, December 27, 2012 3:08 AM\nTo: OpenStack Development Mailing List\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc\n\n \n\nOleg,\n\n \n\nIn this case, we are not creating resources. The pool has already been created and we know to which tenant it belongs. Same thing for health monitor. So what does specifying a tenant Id accomplish in this call (associating a health monitor with a pool)?\n\n \n\nThanks\n\nYoucef\n\n\nOn Dec 25, 2012, at 0:20, \"Oleg Bondarev\" <obondarev at mirantis.com> wrote:\n\nHi Youcef,\n\n \n\nI think that tenant_id should be present in every resource and sub-resource as it is verified by framework for any API call - so for creating a sub-resource too.\n\nI ?ve also looked through the updated API doc and still think we should add ?health_monitors? to the list of updatable attributes of a pool. What do you think?\n\n \n\nThanks,\n\nOleg\n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Tuesday, December 25, 2012 7:54 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc\n\n \n\nThanks Oleg. For associating a health monitor with pool with this call.\n\n \n\nPOST pools/<pool_id>/health_monitors\n\n{\n\n                ?id?: <health_monitor_id>,\n\n                ?tenant_id?: <tenant_id>\n\n}\n\n \n\nI believe the ?tenant_id? in the request body is not needed, since both the pool and the health monitor are already created. What do you think?\n\n \n\nYoucef\n\n \n\n \n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Saturday, December 22, 2012 5:29 AM\nTo: \'OpenStack Development Mailing List\'\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc\n\n \n\nHi Oleg,\n\n \n\nThanks, I have reviewed these, and require some clarification from you.\n\n \n\n-          add default values for fields not specified while VIP creation\n\n \n\nDo you mean ?description? and ?connection_limit? fields? For ?description?, the default value if not specified by the user is an empty string, while ?connection_limit? if not specified by the user is not used (internally and in DB, you can store it as ?-1? meaning there is no connection limit). \n\n[obondarev] Agree\n\n \n\n-          add ?description? and ?connection_limit? fields with default values to the response of Create VIP Example\n\n \n\nIn the response, if description is an empty string and if ?connection_limit? is set to -1, we do not return them, as it means the user has not set these, and they have got a NULL value.\n\n[obondarev] Agree\n\n \n\n-          add ?lb_method? field to the request of Create Pool Example as it is required\n\n \n\nYes, good catch! I?ll add this.\n\n \n\n-          remove ?members? filed from the request of Create Pool Example\n\n-          add ?health_monitors? to the list of updatable attributes of a pool\n\n-          remove ?List all Members of a specific Pool? and ?List Health Monitors associated with a Pool? REST calls from the API\n\n \n\nYes, since we have agreed now on an approach for dealing with sub-resources, I can now update the spec.\n\n \n\n-          add ?pool_id? to the must list when creating a member\n\nYep.\n\n \n\n-          add appropriate values to the request of Associate Health Monitors with a Pool Example\n\n \n\nI thought that associating/dissociating pools and health_monitors is now done when creating or updating a pool (by specification a collection attribute). Can you clarify for me what the current implementation does?\n\n[obondarev] It?s true but we also still have an opportunity to associate/disassociate monitors with pools using sub-resource concept: \n\nPOST pools/<pool_id>/health_monitors {body}\n\nDELETE pools/<pool_id>/health_monitors/<health_monitor_id>\n\nWhere body is:\n\n{\n\n                ?id?: <health_monitor_id>,\n\n                ?tenant_id?: <tenant_id>\n\n}\n\n- to add one monitor to a pool ? this avoids user from doing two roundtrips where he needs first to do GET and then PUT on a pool resource.\n\n \n\nThanks\n\nYoucef \n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Thursday, December 20, 2012 1:49 AM\nTo: Youcef Laribi; \'OpenStack Development Mailing List\'\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do corresponding changes in LBaaS API doc\n\n \n\nSure Youcef, here?s the list of updates:\n\n \n\n-          add default values for fields not specified while VIP creation\n\n-          add ?description? and ?connection_limit? fields with default values to the response of Create VIP Example\n\n-          add ?lb_method? field to the request of Create Pool Example as it is required\n\n-          remove ?members? filed from the request of Create Pool Example\n\n-          add ?health_monitors? to the list of updatable attributes of a pool\n\n-          remove ?List all Members of a specific Pool? and ?List Health Monitors associated with a Pool? REST calls from the API\n\n-          add ?pool_id? to the must list when creating a member\n\n-          add appropriate values to the request of Associate Health Monitors with a Pool Example\n\n \n\nThanks,\n\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Wednesday, December 19, 2012 11:42 PM\nTo: Oleg Bondarev; OpenStack Development Mailing List\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do carresponding changes in LBaaS API doc\n\n \n\nOleg,\n\n \n\nCan you outline what those changes are?\n\n \n\nThanks,\n\nYoucef\n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Wednesday, December 19, 2012 5:39 AM\nTo: Youcef Laribi; OpenStack Development Mailing List\nSubject: [openstack-dev][quantum][LBaaS] need to do carresponding changes in LBaaS API doc\n\n \n\nHi Youcef,\n\n \n\nNow after LBaaS API extension patch was merged we need to do several corresponding changes in the API doc. \n\nI can do it if you provide me rights on editing the page (http://wiki.openstack.org/Quantum/LBaaS/API_1.0).\n\n \n\nThanks,\n\nOleg\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130109/fa2ad0db/attachment.html>\n\n','<2EF06EF5-1D11-4638-BC7F-F16EB9700F57@eu.citrix.com>',NULL),('<027F9BAF-EE9A-4F32-921C-CA29F5D3A023@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 17:25:24',10800,'2013-07-23 14:25:24',NULL,'[openstack-dev] [Stackalytics] 0.1 release','I still think counting lines of code is evil because it might encourage some developers to write longer code just for statistics.\n\nOn Jul 23, 2013, at 16:58 , Herman Narkaytis <hnarkaytis at mirantis.com> wrote:\n\n> Hello everyone!\n> \n> Mirantis is pleased to announce the release of Stackalytics 0.1. You can find complete details on the Stackalytics wiki page, but here are the brief release notes:\n> Changed the internal architecture. Main features include advanced real time processing and horizontal scalability.\n> Got rid of all 3rd party non-Apache libraries and published the source on StackForge under the Apache2 license.\n> Improved release cycle tracking by using Git tags instead of approximate date periods.\n> Changed project classification to a two-level structure: OpenStack (core, incubator, documentation, other) and StackForge.\n> Implemented correction mechanism that allows users to tweak metrics for particular commits.\n> Added a number of new projects (Tempest, documentation, Puppet recipes).\n> Added company affiliated contribution breakdown to the user\'s profile page.\n> We welcome you to read, look it over, and comment.\n> \n> Thank you!\n> \n> -- \n> Herman Narkaytis\n> DoO Ru, PhD\n> Tel.: +7 (8452) 674-555, +7 (8452) 431-555\n> Tel.: +7 (495) 640-4904 \n> Tel.: +7 (812) 640-5904\n> Tel.: +38(057)728-4215 \n> Tel.: +1 (408) 715-7897\n> ext 2002\n> http://www.mirantis.com\n> \n> This email (including any attachments) is confidential. If you are not the intended recipient you must not copy, use, disclose, distribute or rely on the information contained in it. If you have received this email in error, please notify the sender immediately by reply email and delete the email from your system. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of mistaken delivery to you. Mirantis does not guarantee (that this email or the attachment\'s) are unaffected by computer virus, corruption or other defects. Mirantis may monitor incoming and outgoing emails for compliance with its Email Policy. Please note that our servers may not be located in your country.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/4b6cf09b/attachment.html>\n\n','<CAPFmEhY0=bq7tgEdSC8oxCLhPSU6ryBdFFikL0Ju59MXtAqXsg@mail.gmail.com>',NULL),('<027FA24E-5B05-47C5-A67B-4E224357E638@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 23:00:01',0,'2013-12-12 23:00:01',NULL,'[openstack-dev] [keystone] domain admin role query','Hi\n\nSo the idea wasn\'t the you create a domain with the id of \'domain_admin_id\', rather that you create the domain that you plan to use for your admin domain, and then paste its (auto-generated) domain_id into the policy file.\n\nHenry\nOn 12 Dec 2013, at 03:11, Paul Belanger <paul.belanger at polybeacon.com> wrote:\n\n> On 13-12-11 11:18 AM, Lyle, David wrote:\n>> +1 on moving the domain admin role rules to the default policy.json\n>> \n>> -David Lyle\n>> \n>> From: Dolph Mathews [mailto:dolph.mathews at gmail.com]\n>> Sent: Wednesday, December 11, 2013 9:04 AM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: Re: [openstack-dev] [keystone] domain admin role query\n>> \n>> \n>> On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox <jamielennox at redhat.com> wrote:\n>> Using the default policies it will simply check for the admin role and not care about the domain that admin is limited to. This is partially a left over from the V2 api when there wasn\'t domains to worry > about.\n>> \n>> A better example of policies are in the file etc/policy.v3cloudsample.json. In there you will see the rule for create_project is:\n>> \n>>   \"identity:create_project\": \"rule:admin_required and domain_id:%(project.domain_id)s\",\n>> \n>> as opposed to (in policy.json):\n>> \n>>   \"identity:create_project\": \"rule:admin_required\",\n>> \n>> This is what you are looking for to scope the admin role to a domain.\n>> \n>> We need to start moving the rules from policy.v3cloudsample.json to the default policy.json =)\n>> \n>> \n>> Jamie\n>> \n>> ----- Original Message -----\n>>> From: \"Ravi Chunduru\" <ravivsn at gmail.com>\n>>> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n>>> Sent: Wednesday, 11 December, 2013 11:23:15 AM\n>>> Subject: [openstack-dev] [keystone] domain admin role query\n>>> \n>>> Hi,\n>>> I am trying out Keystone V3 APIs and domains.\n>>> I created an domain, created a project in that domain, created an user in\n>>> that domain and project.\n>>> Next, gave an admin role for that user in that domain.\n>>> \n>>> I am assuming that user is now admin to that domain.\n>>> Now, I got a scoped token with that user, domain and project. With that\n>>> token, I tried to create a new project in that domain. It worked.\n>>> \n>>> But, using the same token, I could also create a new project in a \'default\'\n>>> domain too. I expected it should throw authentication error. Is it a bug?\n>>> \n>>> Thanks,\n>>> --\n>>> Ravi\n>>> \n> \n> One of the issues I had this week while using the policy.v3cloudsample.json was I had no easy way of creating a domain with the id of \'admin_domain_id\'.  I basically had to modify the SQL directly to do it.\n> \n> Any chance we can create a 2nd domain using \'admin_domain_id\' via keystone-manage sync_db?\n> \n> -- \n> Paul Belanger | PolyBeacon, Inc.\n> Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)\n> Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/e5170e17/attachment.pgp>\n\n','<52A9295C.7040700@polybeacon.com>',NULL),('<028601cf903d$62db0780$28911680$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-25 15:19:14',32400,'2014-06-25 06:19:14',NULL,'[openstack-dev] [Keystone] Token invalidation in deleting role\n	assignments','Hi all,\n\nWhen deleting role assignments, not only tokens that are related with\ndeleted role assignments but also other tokens that the(same) user has are\ninvalidated in stable/icehouse(2014.1.1).\n\nFor example,\nA) Role assignment between domain and user by OS-INHERIT(*1)\n1. Assign a role(For example,\'Member\') between \'Domain1\' and \'user\' by\nOS-INHERIT\n2. Assign the role(\'Member\') between \'Domain2\' and \'user\' by OS-INHERIT\n3. Get a token with specifying \'user\' and \'Project1\'(in \'Domain1\')\n4. Get a token with specifying \'user\' and \'Project2\'(in \'Domain2\')\n5. Create reources(For example, cinder volumes) in \'Project1\' with the token\nthat was gotten in \"3.\"\n    it is possible to create them.\n6. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is possible to create them.\n7. Delete the role assignment between \'Domain1\' and \'user\' (that was added\nin \"1.\")\n\n(After validated token cache is expired in cinder, etc.)\n8. Create reources in \'Project1\' with the token that was gotten in \"3.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n9. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n\nIn \"9.\", my expectation is that it is possible to create resources with the\ntoken that was gotten in \"4.\".\n\n*1:\nv3/OS-INHERIT/domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_\nto_projects\n\nB) Role assignment between project and user\n1. Assign a role(For example,\'Member\') between \'Project1\' and \'user\'\n2. Assign the role(\'Member\') between \'Project2\' and \'user\'\n3. Get a token with specifying \'user\' and \'Project1\'\n4. Get a token with specifying \'user\' and \'Project2\'\n5. Create reources(For example, cinder volumes) in \'Project1\' with the token\nthat was gotten in \"3.\"\n    it is possible to create them.\n6. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is possible to create them.\n7. Delete the role assignment between \'Project1\' and \'user\' (that was added\nin \"1.\")\n\n(After validated token cache is expired in cinder, etc.)\n8. Create reources in \'Project1\' with the token that was gotten in \"3.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n9. Create reources in \'Project2\' with the token that was gotten in \"4.\"\n    it is not possible to create them. \"401 Unauthorized.\"\n\nIn \"9.\", my expectation is that it is possible to create resources with the\ntoken that was gotten in \"4.\".\n\n\nAre these bugs?\nOr are there any reasons to implement these ways?\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\n\n\n\n\n',NULL,NULL),('<028F0E7F-9202-40CD-A0BE-D1882AAC75D4@godaddy.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-18 03:26:45',0,'2014-12-18 03:26:45',NULL,'[Openstack] [openstack] HTTPS for spice console','(This is probably more appropriate for the openstack at lists.openstack.org list, so moving there for others? visibility.)\n\nFor the most part, the config is fairly straightforward.  The settings I add are:\n\n\nDEFAULT/ssl_only\nDEFAULT/cert\nDEFAULT/key\n\nYou?ll also need the spice-html5 package (that is the name of it under RedHat/CentOS, it may be different for Debian/Ubuntu.)  I had to make a modification to the spice_auto.html from that package to use HTTPS:\n\n\n--- spice_auto.html.nossl       2014-08-12 17:09:55.000000000 -0600\n+++ spice_auto.html.ssl 2014-08-12 17:09:55.000000000 -0600\n@@ -81,7 +81,7 @@\n\n             function connect()\n             {\n-                var host, port, password, scheme = \"ws://\", uri;\n+                var host, port, password, scheme = \"wss://\", uri;\n\n                 // By default, use the host and port of server that served this file\n                 host = spice_query_var(\'host\', window.location.hostname);\n\n\n\n\n\n\n\n\n\n\nI hope you find this to be helpful.\n\nMike\n\n\n\n\nFrom: Akshik DBK <akshik at outlook.com<mailto:akshik at outlook.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Wednesday, December 17, 2014 at 3:29 PM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: [openstack-dev] HTTPS for spice console\n\nAre there any recommended approach to configure spice console proxy on a secure [https], could not find proper documentation for the same.\n\ncan someone point me to the rigt direction\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141218/b6641f19/attachment.html>\n\n',NULL,NULL),('<0292D58E723E4BF1B83B49A4C3F4A1AD@dewey.ws>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-14 09:53:50',-25200,'2014-08-14 16:53:50',NULL,'[Openstack-operators] memcached redundancy','Interesting.  I haven?t seen that happen before, and have setup memcached in a similar fashion as you.  The memcached client consistently hashes each key across your set of active memcached servers.  So killing memcached on server x, should only result in failures for data stored on server x.  However, the client should account for this and rehash.  \n\nIt sounds to me like another component is causing you grief, and the editing of memcached servers + restart clears it up.  Instead of taking down the entire system, have you tried stopping memcached on a single server, and verify the delay is still present?  \n\n\nOn Thursday, August 14, 2014 at 9:30 AM, Joe Topjian wrote:\n\n> Hi Abel,\n>  \n> I\'m petty confident that the delays are coming from the the openstack server components. For example, Keystone. So when a client tries to authenticate, Keystone is not marking a memcached server as dead and will continue to try it and time out. At least that was my impression when I tested removing the dead node from the config files.  \n>  \n> I fully agree about everything going back to normal after a short time. If the timeout delay didn\'t exist, I\'d still try to implement some sort of replication just because, as an end-user, being randomly logged out is really annoying.  \n>  \n> Thanks,\n> Joe\n>  \n>  \n>  \n> On Thu, Aug 14, 2014 at 10:23 AM, Abel Lopez <alopgeek at gmail.com (mailto:alopgeek at gmail.com)> wrote:\n> > I played with this in the lab for a little bit, it didn?t seem to be a huge deal.\n> > My setup was three ?controller? nodes each running Multi-master Percona DB, rabbit-ha cluster, and memcached. Killing DB, no worries as it?s behind LB, killing rabbit? Usually not a problem especially after 3.2.x. Memcached? I noticed a brief period of invalid tokens, but within a few seconds, everything goes back to normal. I think the client software has a built-in retry when auth fails, or at least that was the observation. This was on Havana 1\n> >  \n> > On Aug 14, 2014, at 9:09 AM, Joe Topjian <joe at topjian.net (mailto:joe at topjian.net)> wrote:\n> >  \n> > > Hello,\n> > >\n> > > I have an OpenStack cloud with two HA cloud controllers. Each controller runs the standard controller components: glance, keystone, nova minus compute and network, cinder, horizon, mysql, rabbitmq, and memcached.\n> > >\n> > > Everything except memcached is accessed through haproxy and everything is working great (well, rabbit can be finicky ... I might post about that if it continues).\n> > >\n> > > The problem I currently have is how to effectively work with memcached in this environment. Since all components are load balanced, they need access to the same memcached servers. That\'s solved by the ability to specify multiple memcached servers in the various openstack config files.\n> > >\n> > > But if I take a server down for maintenance, I notice a 2-3 second delay in all requests. I\'ve confirmed it\'s memcached by editing the list of memcached servers in the config files and the delay goes away.\n> > >\n> > > I\'m wondering how people deploy memcached in environments like this? Are you using some type of memcached replication between servers? Or if a memcached server goes offline are you reconfiguring OpenStack to remove the offline memcached server?\n> > >\n> > > Thanks,\n> > > Joe\n> > > _______________________________________________\n> > > OpenStack-operators mailing list\n> > > OpenStack-operators at lists.openstack.org (mailto:OpenStack-operators at lists.openstack.org)\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> >  \n>  \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org (mailto:OpenStack-operators at lists.openstack.org)\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>  \n>  \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140814/7efb23c6/attachment.html>\n\n','<CA+y7hvjyhBHHm56wNa2z__Cb67NNSy4F1ow2sq-M7dTW5Ku28w@mail.gmail.com>',NULL),('<02962D17-D3DA-498F-A2BD-74081E93C28F@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-22 06:05:22',0,'2013-08-22 06:05:22',NULL,'[openstack-dev] [Oslo.db] Configuration options','Thx mark, good to know this happens before it is librarized. Is there any place where these common set of refactoring tasks is written down (so that info can be referred to instead of a question on the mailing list)?\n\nSent from my really tiny device...\n\nOn Aug 21, 2013, at 10:20 PM, \"Mark McLoughlin\" <markmc at redhat.com> wrote:\n\n> On Thu, 2013-08-22 at 01:14 +0000, Joshua Harlow wrote:\n>> Agreed, any thoughts from the oslo folks on how this could be done\n>> (without a major refactoring??). Can it even be done?\n>> \n>> It will be a continuous problem for libraries which want to be\n>> integrated with the various openstack projects, especially if those\n>> libraries use oslo code, since there is now a weird \'action at a\n>> distance\' on config shared between the project and the library. To me\n>> this is one of the pain points in a global CFG object, maybe for\n>> things that oslo will \'librarize\' those libraries should not have a\n>> strong coupling to said global CFG but should prefer a local config\n>> \'object\' to be passed in (of which the project using the oslo library\n>> can by default pass in the global CFG object to it, if the project\n>> desires to use it this way).\n> \n> Take a look at the oslo.messaging API:\n> \n> http://docs.openstack.org/developer/oslo.messaging/transport.html\n> \n> See? No dependence on a global config object. And the ability to connect\n> to alternate brokers via a transport_url.\n> \n> So, yes - moving any API out of oslo-incubator into a standalone library\n> is all about cleaning up issues like this.\n> \n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1377148608.6522.86.camel@sorcha>',NULL),('<02993841e28701235a43d4c4a2113f9e@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-05 16:40:48',7200,'2014-04-05 14:40:48',NULL,'[Openstack-docs] Icehouse installation guide support for\n neutron plug-ins','Hi,\n\nLe 2014-04-03 18:42, Matt Kassawara a ?crit?:\n> Around inception of the installation guide networking updates\n> project, the neutron developers decided to replace the Open vSwitch\n> (OVS) plug-in with the Modular Layer 2 (ML2) plug-in in Icehouse.\n> However, issues with the migration process from OVS to ML2 apparently\n> reverted this decision late in the development cycle. According to the\n> blueprint, RC1 includes the first rendition of the migration process:\n> \n> https://blueprints.launchpad.net/neutron/+spec/ml2-deprecated-plugin-migration\n> [1]\n> \n> Given proximity to the final release date, shall we support both OVS\n> and ML2 in the installation guide and reconsider removing OVS in Juno?\n> \n\nKeeping OVS around means additional testing and maintenance to make \nsure it works. And from what I can see on Ubuntu, the packages default \nto ML2+OVS, and configuring OVS only is not that easy (I managed to make \nit work but with a few \"workarounds\").\n\nI am in favor of keeping ML2 only.\n\nGauvain\n\n\n','<CABA+jQoRqfsb_UwLACFF-GkD64DuZTtq871y4AVVYR7dGcxeQw@mail.gmail.com>',NULL),('<02999DB8-D2EE-4061-82E8-256F5FB4B371@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-03 11:33:26',-18000,'2013-11-03 16:33:26',NULL,'[openstack-dev] [Solum] Choice of API infrastructure','\n\n> On Nov 3, 2013, at 9:02 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n>> On 11/02/2013 11:26 PM, Russell Bryant wrote:\n>>> On 11/02/2013 11:54 AM, Adrian Otto wrote:\n>>> Noorul,\n>>> \n>>> I agree that key decisions should be tracked in blueprints. This is the\n>>> one for this decision which was made in our 2013-10-18 public meeting.\n>>> Jay\'s submission is consistent with the direction indicated by the team.\n>>> \n>>> https://blueprints.launchpad.net/solum/+spec/rest-api-base\n>>> \n>>> Transcript log:\n>>> http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html\n>>> <http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html>\n>> \n>> Heh, not much discussion there.  :-)\n> \n> Agreed. I actually didn\'t know anything about the discussion -- I wasn\'t at the meeting. I just figured I would throw some example code up to Gerrit that shows how Falcon can be used for the API plumbing. Like I mentioned in a previous email, I believe it\'s much easier to discuss things when there is sample code...\n> \n>> Here\'s my take ... Pecan+WSME has been pushed as the thing to\n>> standardize on across most OpenStack APIs.  Ceilometer (and maybe\n>> others?) are already using it.  Others, such as Nova, are planning to\n>> use it this cycle. [1][2]\n> \n> I\'ve used both actually, and I\'ve come to prefer Falcon because of its simplicity and specifically because of the following things:\n> \n> * It\'s lack of integration with WSME, which I don\'t care for. I don\'t care for WSME because I believe it tries to put the model at the view layer, instead of where it belongs, at the model layer.\n\nWell, there are domain models, and API models.  Being able to map the domain model to a slightly different representation (although wsme isn\'t necessarily the best example of this), or to introduce virtual fields that exist solely for the benefit of a client, has been useful for us in practice over the years. \n\nThe biggest benefit of the API model from my perspective is separating the concern of validating fields and reporting those validations consistently and correctly to a client, from the underlying persistence translations.  Tying json serialization too closely to a domain model will cause other coupling problems later on.\n\nIf I understand correctly from looking at the nova code this mapping (and of other domain model actions) is a goal of the \'objects\' work, so if we end up versioning our domain model, not just the API, there\'s less of a need to for anything more that a light API translation.\n\nAll my 2 cents - I generally prefer having a light API model on top of my domain model for anything more complicated than a simple crud resource.\n\n> * It doesn\'t need a configuration file, specifically a configuration file that is a Python file as opposed to an .ini file.\n> \n>> I care less about the particular choice and more about consistency.  It\n>> brings a lot of value, such as making it a lot easier for developers to\n>> jump around between the OpenStack projects.  Can we first at least agree\n>> that there is value in standardizing on *something* for most OpenStack APIs?\n> \n> I completely understand the need for consistency. I pushed my patch as an example of how to do things the Falcon way. While I would prefer Falcon over Pecan (and certainly over Pecan+WSME), I will respect the push towards consistency if that\'s what is most important.\n> \n> That said, I also believe that the projects in Stackforge should be the \"laboratories of experiment\", and these projects may serve as a good playground for various implementations of things. I remind the reader that over time, the development community has standardized on various things, only to find a better implementation in an incubated project. Pecan+WSME is actually an example of that experimentation turned accepted standard.\n> \n> Best,\n> -jay\n> \n>> I understand that there may be cases where the needs for an API justify\n>> being different.  Marconi being more of a data-plane API vs\n>> control-plane means that performance concerns are much higher, for example.\n>> \n>> If we agree that consistency is good, does Solum have needs that make it\n>> different than the majority of OpenStack APIs?  IMO, it does not.\n>> \n>> Can someone lay out a case for why all OpenStack projects should be\n>> using Falcon, if that\'s what you think Solum should use?\n>> \n>> Also, is anyone willing to put up the equivalent of Jay\'s review [3],\n>> but with Pecan+WSME, to help facilitate the discussion?\n>> \n>> [1]\n>> http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee\n>> [2]\n>> http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2\n>> [3] https://review.openstack.org/#/c/55040/\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<527663B6.8040807@gmail.com>',NULL),('<029E3612-1350-48EE-A598-5102D93B4F1F@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-13 11:25:11',-14400,'2014-10-13 15:25:11',NULL,'[openstack-dev] [all][oslo] projects still using obsolete oslo\n	modules','\nOn Oct 13, 2014, at 11:06 AM, Steven Hardy <shardy at redhat.com> wrote:\n\n> On Mon, Oct 13, 2014 at 09:20:38AM -0400, Doug Hellmann wrote:\n>> I?ve put together a little script to generate a report of the projects using modules that used to be in the oslo-incubator but that have moved to libraries [1]. These modules have been deleted, and now only exist in the stable/juno branch of the incubator. We do not anticipate back-porting fixes except for serious security concerns, so it is important to update all projects to use the libraries where the modules now live.\n>> \n>> Liaisons, please look through the list below and file bugs against your project for any changes needed to move to the new libraries and start working on the updates. We need to prioritize this work for early in Kilo to ensure that your projects do not fall further out of step. K-1 is the ideal target, with K-2 as an absolute latest date. I anticipate having several more libraries by the time the K-2 milestone arrives.\n> \n> Thanks for the heads-up Doug, I\'ve raised this bug to track the heat fixes:\n> \n> https://bugs.launchpad.net/heat/+bug/1380629\n> \n> I\'ll try to get patches posted this week addressing the issues identified.\n\nThanks, Steve! Let us know if you run into any issues or need help with code reviews.\n\nDoug\n\n> \n> Steve\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20141013150606.GA25903@t430slt.redhat.com>',NULL),('<02A0D4FF-A504-451D-A127-59AE88CAF607@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 09:42:41',-14400,'2014-10-28 13:42:41',NULL,'[openstack-dev] [nova] pci pass through turing complete config\n	options?','\nOn Oct 28, 2014, at 7:34 AM, Sean Dague <sean at dague.net> wrote:\n\n> We\'re dealing with some issues on devstack pass through with really\n> complicated config option types, the fixes are breaking other things.\n> \n> The issue at hand is the fact that the pci pass through device listing\n> is an olso MultiStrOpt in which each option value is fully valid json\n> document, which must parse as such. That leads to things like:\n> \n> pci_passthrough_whitelist = {\"address\":\"*:0a:00.*\",\n> \"physical_network\":\"physnet1\"}\n> pci_passthrough_whitelist = {\"vendor_id\":\"1137\",\"product_id\":\"0071\"}\n> \n> Which, honestly, seems a little weird for configs.\n> \n> We\'re talking about a small number of fixed fields here, so the use of a\n> full json doc seems weird. I\'d like to reopen why this was the value\n> format, and if we could have a more simple one.\n> \n> We\'re probably going to revert the attempted devstack support for pass\n> through of these things anyway, because it\'s breaking variable\n> interpolation in other config options. And the complexity added by\n> trying to add support for things like that in local.conf has shown to be\n> too much for the current ini parser structure.\n\nAnother way to do this, which has been used in some other projects, is to define one option for a list of ?names? of things, and use those names to make groups with each field in an individual option. This similar to the logging config file. For example,\n\n  [DEFAULT]\n  pci_passthrough_rules = by_address, by_vendor_id\n\n  [pci_passthrough_by_address]\n  address = *:0a:00.*\n  physical_network = physnet1\n\n  [pci_passthrough_by_vendor_id]\n  vendor_id 1137\n  product_id 0071\n\nThe options for each ?pci_passthrough_*? group can be registered multiple times as long as the group name is different. You would access the values as cfg.CONF.pci_passthrough_by_address.address, etc., and that places some naming restrictions on the groups.\n\nOTOH, oslo.config is not the only way we have to support configuration. This looks like a good example of settings that are more complex than what oslo.config is meant to handle, and that might be better served in a separate file with the location of that file specified in an oslo.config option.\n\nDoug\n\n\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<544F7F33.6090405@dague.net>',NULL),('<02A6E672-ED47-4823-9DB2-C4B3041FAF15@subbu.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-13 08:55:15',-14400,'2014-05-13 12:55:15',NULL,'[openstack-dev] Hierarchical administrative boundary [keystone]','Hi Arvind,\n\nThis seems to be covering one of the use cases listed by https://wiki.openstack.org/wiki/Blueprint-VPC. Others to isolate between VPCs include shared resources like networks, images, roles, and other configuration. \n\nSubbu\n\nOn May 8, 2014, at 7:55 PM, Tiwari, Arvind <arvind.tiwari at hp.com> wrote:\n\n> Hi All,\n>  \n> Below is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancysession of Atlanta design summit.\n>  \n> https://wiki.openstack.org/wiki/Hierarchical_administrative_boundary\n>  \n> Please take a look.\n>  \n> Thanks,\n> Arvind\n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<0EF5F110A32BED44A0C6438BB5C35B3907000AF2@G4W3210.americas.hpqcorp.net>',NULL),('<02ABA90F-5658-428D-98CE-D07DF42BFE6F@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-14 14:12:49',0,'2014-06-14 14:12:49',NULL,'[openstack-dev] [nova] Distributed locking','Are the details of that implementation described on wiki or elsewhere? (Partially for my own curiosity). I think I understand how it works but write ups usually clear that right up.\n\nSent from my really tiny device...\n\n> On Jun 14, 2014, at 12:15 AM, \"Robert Collins\" <robertc at robertcollins.net> wrote:\n> \n>> On 13 June 2014 02:30, Matthew Booth <mbooth at redhat.com> wrote:\n>> We have a need for a distributed lock in the VMware driver, which I\n>> suspect isn\'t unique. Specifically it is possible for a VMware datastore\n>> to be accessed via multiple nova nodes if it is shared between\n>> clusters[1]. Unfortunately the vSphere API doesn\'t provide us with the\n>> primitives to implement robust locking using the storage layer itself,\n>> so we\'re looking elsewhere.\n> \n> Perhaps I\'m missing something, but I didn\'t see anything in your\n> description about actually needing a *distributed* lock, just needing\n> a local that can be held by remote systems. As Devananda says, a\n> centralised lock that can be held by agents has been implemented in\n> Ironic - such a thing is very simple and quite easy to reason about...\n> but its not suitable for all problems. HA and consistency requirements\n> for such a thing are delivered through e.g. galera in the DB layer.\n> \n> -Rob\n> \n> \n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJ3HoZ2WxHa-DDs9b-PcKEOaQX+VscYMK-=HGMUvi5tn8wF=Ug@mail.gmail.com>',NULL),('<02b301cf7bde$1ce06d60$56a14820$@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 11:06:48',10800,'2014-05-30 08:06:48',NULL,'[openstack-dev] [neutron][L3] VM Scheduling v/s Network as\n	input any consideration ?','Carl,\n\n \n\nA new routing protocol is certainly of great interest.   Are you working with IETF or can you share more here?\n\n \n\nWRT:Nova Schedule - There still are requirements for the Schedule to taking into consideration network as a resource.   My focus is to figure out how to add network capabilities to the Scheduler?s algorithm while still maintaining clean separation of concerns between Nova and Neutron.   We wouldn?t want to get back into the nova-network situation.  \n\n \n\nJohn\n\n \n\n \n\nFrom: Carl Baldwin [mailto:carl at ecbaldwin.net] \nSent: Friday, May 30, 2014 12:05 AM\nTo: A, Keshava\nCc: jcsf31459 at gmail.com; Armando M.; OpenStack Development Mailing List (not for usage questions); Kyle Mestery\nSubject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?\n\n \n\nKeshava,\n\n \n\nHow much of a problem is routing prefix fragmentation for you?  Fragmentation causes routing table bloat and may reduce the performance of the routing table.  It also increases the amount of information traded by the routing protocol.  Which aspect(s) is (are) affecting you?  Can you quantify this effect?\n\n \n\nA major motivation for my interest in employing a dynamic routing protocol within a datacenter is to enable IP mobility so that I don\'t need to worry about doing things like scheduling instances based on their IP addresses.  Also, I believe that it can make floating ips more \"floaty\" so that they can cross network boundaries without having to statically configure routers.\n\n \n\nTo get this mobility, it seems inevitable to accept the fragmentation in the routing prefixes.  This level of fragmentation would be contained to a well-defined scope, like within a datacenter.  Is it your opinion that trading off fragmentation for mobility a bad trade-off?  Maybe it depends on the capabilities of the TOR switches and routers that you have.  Maybe others can chime in here.\n\n \n\nCarl\n\n \n\nOn Wed, May 28, 2014 at 10:11 PM, A, Keshava <keshava.a at hp.com> wrote:\n\nHi,\n\nMotivation behind this  requirement is ? to achieve VM prefix aggregation  using routing protocol ( BGP/OSPF)?.\n\nSo that prefix advertised from cloud to upstream will be aggregated.\n\n \n\nI do not have idea how the current scheduler is implemented. \n\nBut schedule to  maintain some kind of the ?Network to Node mapping to VM? ..\n\nBased on that mapping to if any new VM  getting hosted to give prefix in those Nodes based one input preference.\n\n \n\nIt will be great help us from routing side if this is available in the infrastructure.\n\nI am available for review/technical discussion/meeting. \n\n \n\n \n\nThanks & regards,\n\nKeshava.A\n\n \n\nFrom: jcsf31459 at gmail.com [mailto:jcsf31459 at gmail.com] \nSent: Thursday, May 29, 2014 9:14 AM\nTo: openstack-dev at lists.openstack.org; Carl Baldwin; Kyle Mestery; OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?\n\n \n\nHi keshava,\n\n \n\nThis is an area that I am interested in.   I\'d be happy to collaborate with you on a blueprint.    This would require enhancements to the scheduler as you suggested.   \n\n \n\nThere are a number of uses cases for this.  \n\n  \n\n \n\n?John. \n\n \n\nSent from my  smartphone.\n\n\nFrom: A, Keshava?\n\nSent: Tuesday, May 27, 2014 10:58 AM\n\nTo: Carl Baldwin; Kyle Mestery; OpenStack Development Mailing List (not for usage questions)\n\nReply To: OpenStack Development Mailing List (not for usage questions)\n\nSubject: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input any consideration ?\n\n \n\nHi,\n\nI have one of the basic question about the Nova Scheduler in the following below scenario.\n\nWhenever a new VM to be hosted is there any consideration of network attributes ? \n\nExample let us say all the VMs with 10.1.x is under TOR-1, and 20.1.xy are under TOR-2.\n\nA new CN nodes is inserted under TOR-2 and at same time a new  tenant VM needs to be  hosted for 10.1.xa network.\n\n \n\nThen is it possible to mandate the new VM(10.1.xa)   to hosted under TOR-1 instead of it got scheduled under TOR-2 ( where there CN-23 is completely free from resource perspective ) ? \n\nThis is required to achieve prefix/route aggregation and to avoid network broadcast (incase if they are scattered across different TOR/Switch) ? \n\n \n\n \n\n \n\n\n\n \n\nThanks & regards,\n\nKeshava.A\n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/f6e0b4a9/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 30014 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/f6e0b4a9/attachment.png>\n\n','<CALiLy7qsi+gaFG+sYOZzy27BAOE1YbgM5QfnAiEOAt1D=4pF3Q@mail.gmail.com>',NULL),('<02ba85a87d554aec8c6481be8f6bf157@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-01 06:59:57',0,'2014-08-01 06:59:57',NULL,'[openstack-dev] [Neutron] tox -e pep8 fails at requirements.txt','Hi -\n\nWhen I run tox to check pep8 on the newly cloned neutron from openstack git , I get the following error.\n\npep8 create: /root/fw_code_base/neutron_01082014/.tox/pep8\npep8 installdeps: -r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt\nERROR: invocation failed, logfile: /root/fw_code_base/neutron_01082014/.tox/pep8/log/pep8-1.log\nERROR: actionid=pep8\nmsg=getenv\ncmdargs=[local(\'/root/fw_code_base/neutron_01082014/.tox/pep8/bin/pip\'), \'install\', \'-U\', \'-r/root/fw_code_base/neutron_01082014/requirements.txt\', \'-r/root/fw_code_base/neutron_01082014/test-requirements.txt\']\nenv={\'PYTHONIOENCODING\': \'utf_8\', \'XDG_RUNTIME_DIR\': \'/run/user/0\', \'VIRTUAL_ENV\': \'/root/fw_code_base/neutron_01082014/.tox/pep8\', \'LESSOPEN\': \'| /usr/bin/lesspipe %s\', \'SSH_CLIENT\': \'10.232.84.77 61736 22\', \'LOGNAME\': \'root\', \'USER\': \'root\', \'HOME\': \'/root/fw_code_base/neutron_01082014/.tox/pep8/tmp/pseudo-home\', \'PATH\': \'/root/fw_code_base/neutron_01082014/.tox/pep8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'XDG_SESSION_ID\': \'19\', \'_\': \'/usr/bin/tox\', \'SSH_CONNECTION\': \'10.232.84.77 61736 10.232.90.26 22\', \'LANG\': \'en_IN\', \'TERM\': \'xterm\', \'SHELL\': \'/bin/bash\', \'LESSCLOSE\': \'/usr/bin/lesspipe %s %s\', \'LANGUAGE\': \'en_IN:en\', \'SHLVL\': \'1\', \'SSH_TTY\': \'/dev/pts/0\', \'OLDPWD\': \'/root/fw_code_base\', \'PWD\': \'/root/fw_code_base/neutron_01082014\', \'PYTHONHASHSEED\': \'0\', \'MAIL\': \'/var/mail/root\', \'LS_COLORS\': \'rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:\'}\nDownloading/unpacking pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\n  Cannot fetch index base URL https://pypi.python.org/simple/\n  Could not find any downloads that satisfy the requirement pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\nCleaning up...\nNo distributions at all found for pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\nStoring debug log for failure in /root/fw_code_base/neutron_01082014/.tox/pep8/tmp/pseudo-home/.pip/pip.log\n\nERROR: could not install deps [-r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt]\n__________________________________________________________ summary __________________________________________________________\nERROR:   pep8: could not install deps [-r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt]\n\nCan anyone help me on resolving this issue.\n\nKindly please help me in this regard.\n\nThanks in advance.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140801/449c6e1a/attachment.html>\n\n',NULL,NULL),('<02ba85a87d554aec8c6481be8f6bf157@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-01 06:59:57',0,'2014-08-01 06:59:57',NULL,'[OpenStack-Infra] [Neutron] tox -e pep8 fails at requirements.txt','Hi -\n\nWhen I run tox to check pep8 on the newly cloned neutron from openstack git , I get the following error.\n\npep8 create: /root/fw_code_base/neutron_01082014/.tox/pep8\npep8 installdeps: -r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt\nERROR: invocation failed, logfile: /root/fw_code_base/neutron_01082014/.tox/pep8/log/pep8-1.log\nERROR: actionid=pep8\nmsg=getenv\ncmdargs=[local(\'/root/fw_code_base/neutron_01082014/.tox/pep8/bin/pip\'), \'install\', \'-U\', \'-r/root/fw_code_base/neutron_01082014/requirements.txt\', \'-r/root/fw_code_base/neutron_01082014/test-requirements.txt\']\nenv={\'PYTHONIOENCODING\': \'utf_8\', \'XDG_RUNTIME_DIR\': \'/run/user/0\', \'VIRTUAL_ENV\': \'/root/fw_code_base/neutron_01082014/.tox/pep8\', \'LESSOPEN\': \'| /usr/bin/lesspipe %s\', \'SSH_CLIENT\': \'10.232.84.77 61736 22\', \'LOGNAME\': \'root\', \'USER\': \'root\', \'HOME\': \'/root/fw_code_base/neutron_01082014/.tox/pep8/tmp/pseudo-home\', \'PATH\': \'/root/fw_code_base/neutron_01082014/.tox/pep8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'XDG_SESSION_ID\': \'19\', \'_\': \'/usr/bin/tox\', \'SSH_CONNECTION\': \'10.232.84.77 61736 10.232.90.26 22\', \'LANG\': \'en_IN\', \'TERM\': \'xterm\', \'SHELL\': \'/bin/bash\', \'LESSCLOSE\': \'/usr/bin/lesspipe %s %s\', \'LANGUAGE\': \'en_IN:en\', \'SHLVL\': \'1\', \'SSH_TTY\': \'/dev/pts/0\', \'OLDPWD\': \'/root/fw_code_base\', \'PWD\': \'/root/fw_code_base/neutron_01082014\', \'PYTHONHASHSEED\': \'0\', \'MAIL\': \'/var/mail/root\', \'LS_COLORS\': \'rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:\'}\nDownloading/unpacking pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\n  Cannot fetch index base URL https://pypi.python.org/simple/\n  Could not find any downloads that satisfy the requirement pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\nCleaning up...\nNo distributions at all found for pbr>=0.6,!=0.7,<1.0 (from -r /root/fw_code_base/neutron_01082014/requirements.txt (line 1))\nStoring debug log for failure in /root/fw_code_base/neutron_01082014/.tox/pep8/tmp/pseudo-home/.pip/pip.log\n\nERROR: could not install deps [-r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt]\n__________________________________________________________ summary __________________________________________________________\nERROR:   pep8: could not install deps [-r/root/fw_code_base/neutron_01082014/requirements.txt, -r/root/fw_code_base/neutron_01082014/test-requirements.txt]\n\nCan anyone help me on resolving this issue.\n\nKindly please help me in this regard.\n\nThanks in advance.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140801/449c6e1a/attachment-0001.html>\n\n',NULL,NULL),('<02BCC0F1-FC9C-4393-9DE3-4588496E6897@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-05 18:07:48',-21600,'2015-01-06 00:07:48',NULL,'[openstack-dev] [nova] review closure for nova blueprint\n	review.openstack.org/#/c/140133/','Prefixing subject with [nova] so folks? mail rules catch this.\n\n- Joe\n\n> On Jan 5, 2015, at 1:47 PM, Kenneth Burger <burgerk at us.ibm.com> wrote:\n> \n> Hi, I am trying to get approval on this nova blueprint, https://review.openstack.org/#/c/140133/ <https://review.openstack.org/#/c/140133/>.   There was a +2 from Michael Still ( twice in prior patches ) and a +1 from Jay Bryant from a cinder perspective.    The only changes from the patches receiving the +2  was related to a directory change of the spec location in the repository.   \n> \n> Is it still possible to get approval for this blueprint?\n> \n> Thanks,\n> Ken Burger\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150105/c7db7b0f/attachment.html>\n\n','<OFC0CFA55F.71FAC78A-ON87257DC4.006CB0A5-86257DC4.006CC240@us.ibm.com>',NULL),('<02BF0B55-0356-436F-9674-8B33A39233D1@overstock.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-01 17:21:34',0,'2013-11-01 17:21:34',NULL,'[Openstack] Creating nova-network in Havana with doesn\'t respect\n specified VLAN number','I?m using nova-network with Havana and noticed an odd thing when creating networks.  When I create a network, either with ?nova network-create? or ?nova-manage network-create?, the VLAN number I specify isn?t being used.  Instead, it seems to be assigning only odd-numbered VLANs, which is causing my numbering to be off.  This is causing me problems, because I haven?t tagged those random VLANs on my equipment.\n\nFor example, the following command caused this network to be added with br811 and vlan811 bridge and interface instead of the expected br806 and vlan806:\n\n# nova network-create ?fixed-range-v4=10.14.126.0/24 ?vlan=806 --dns1=10.14.4.21 --project-id=fbb371b9c5cb4f849c40a45eaacc4457 my_new_tenant\n\n\n# ifconfig -a\n?\nbr811     Link encap:Ethernet  HWaddr FA:16:3E:9E:89:64\n          inet addr:10.14.126.1  Bcast:10.14.126.255  Mask:255.255.255.0\n\nvlan811   Link encap:Ethernet  HWaddr FA:16:3E:9E:89:64\n          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1\n\n\n# nova-manage network list\nid      IPv4                    IPv6            start address   DNS1            DNS2            VlanID          project         uuid\n?\n7       10.14.126.0/24          None            10.14.126.3     10.14.4.21      None            811             fbb371b9c5cb4f849c40a45eaacc4457        20ab5507-abe3-457f-b66c-1891d1e62f87\n\nThis does not happen with my Folsom installation.   Any help would be appreciated.\n\n\n\n\n\n________________________________\n\nCONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you.\n\n\n',NULL,NULL),('<02d301cf979f$e3e56690$abb033b0$@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-04 08:51:57',-25200,'2014-07-04 15:51:57',NULL,'[openstack-dev] How introduction of SDN controllers impact\n	OpenStack','Hi Thulasi,\n\n \n\nYour question is a very good one.    One that is very welcome for a long conversation.\n\n \n\nThe answer is that not all SDN controllers are solely based on openflow.   The Neutron API (not code) provides contract for SDN controller to provision the network on behalf of Nova requests and other parts of OpenStack.  This is how it Neutron was conceived/designed and this is how SDN controller developers think about the demarcation.   Provisioning multi-vendor network equipment in a multi-technology world is a difficult thing to accomplish.   This is why no one technology solution will work for all cases.    \n\n \n\nSDN controller developers specialize in thinking about this problem and use a wide range of technologies to accomplish this.   OpenFlow is very effective at end-points (OVS) but is not proven as a mid-point substrate as of yet.  Traditional technologies ? VLANs, IP/OSPF/BGP, MPLS, Optical and software subsystems (e.g. proprietary EMS?s) make up the midpoint landscape.  Accessing/provisioning these midpoint requires a multitude of technologies spanning the control-plane and management-plane (e.g.  netconf/yang, tl1, cli,  vendor-specific proprietary APis).   The job of the SDN controller is to service the contract provided by Neutron by ensuring the end-to-end connection is available for Nova.   How this is accomplished is subject to the actual topology and equipment used.\n\n \n\nAlso, it is perhaps better for the Neutron code to be developed with this in mind.  Pluggable and modular code is more effective that dictating a particular solution/situation.   Allowing the Controller plugin to create the OVS ports and other EMS function is better than dictating that the neutron code always do it.   Of course, neutron should provide the modules to create the port (re-usable code) but not harden where it is called in the call-chain.\n\n \n\nHope this answers your question ? and provokes discussion. \n\n \n\n \n\n \n\n \n\n \n\nFrom: Thulasi ram Valleru [mailto:thulasiram.valleru at gmail.com] \nSent: Friday, July 4, 2014 6:57 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] How introduction of SDN controllers impact OpenStack\n\n \n\nGuys,\n\n        What tasks SDN controller plugin do. Consider we are not installing ML2 plugin, we have only one plugin ie, SDN controller one on Neutron. \n\n \n\n         SDN plugin can manage SDN controller and ovs on hypervisor. Neutron is now able to create a port on Hypervisor and gives the information to Neutron server. Neutron server gives these details to SDn controller. SDN controller now knows which port belong to which physical server. here i am able to see only thing SDN controller can do is update the flow tables on ovs.If open flow physical devices are there in network, then it can gather information like which port is attached to which physical device on physical server. So it can install flows on physical network devices also.\n\n \n\n         What about physical devices which doesn\'t support open flow. how does SDn controller take care of network provisioning by neutron.\n\n \n\n         \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140704/912013bd/attachment.html>\n\n','<CABXZqF3UiCjonTHF-EFGbGgFUywV1LzwbYx=JYWLjThetjkHHg@mail.gmail.com>',NULL),('<02db3751-69ec-4883-a766-09ba4d740bce@aptira.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 08:42:21',39600,'2012-10-10 21:42:21',NULL,'[OpenStack Foundation] Use of the word \"certified\" and protecting\n	brand OpenStack','Dear Foundation Members,\n \nI believe a key role of the Foundation is to protect the brand that is OpenStack.\n \nAfter raising the issue with Rackspace and Jonathan Bryce several days ago, yesterday I sought my fellow Foundation Board members opinion on Rackspace\'s use of the word \"certified\" in media releases 6 days ago, tweets from their staff, and as late as yesterday in this mail out to the summit attendees below. I emailed my Board colleagues because I thought raising this with the elected representatives of the OpenStack Community would alert them to the potential ramifications of this issue. As I see it Rackspace have jumped the gun and are ambush marketing. \n \nThe main problems I see:\n \n1. The timing is unfortunate because there is no clear Board/Foundation policy as yet. \n2. I believe it is the Foundation\'s right to determine what is certified and what is not under the terms of the Foundation\'s trademarks.\n3. This type of activity is clearly open to abuse. Any operator regardless of size, integrity or professionalism could adopt a similar approach. Therefore it needs to be dealt with urgently.\n \nLeaving Rackspace\'s actions aside, I made a suggestion for a certification process for training materials and deliverables that they be offered to a community sourced committee for review and approval. If this proposal is accepted then I would ask Rackspace that they offer up their course materials for this review, and that this might form a baseline for establishing the certification benchmark.\n \nIf certified qualifications are not valued in the USA, courses that present an official certification are highly valued in Australia, Asia and Europe as clear markers of achievement. Integrity of that certification is key.\n \nIf this was a mistake, and I sincerely hope it was, it is able to be, and should be, corrected.\n \nIf we cannot gather enough support to resist such opportunistic behaviour then we (as a community) risk letting this run away on us. The Foundation needs to formulate a considered and effective response on this very important topic. It needs your help. Make your opinions known.\n \nCheers\nTristan\n \n \n \nFrom: Jim Curry [mailto:jim.curry at rackspace.com] \nSent: Wednesday, 10 October 2012 1:08 PM\nTo: Randy Bias; Tristan Goode\nCc: foundation-board at lists.openstack.org\nSubject: Re: [Foundation Board] Use of the word \"certified\" and guidelines around use of words like \"official\"\n \nTristan,\n \nThe email was an unfortunate mistake by our marketing team.  It does not represent the official branding or positioning of our offer.  We aren\'t perfect, and for any confusion that created I apologize.\n \nTo be clear, our offer is a \"Rackspace Certified\" training program for OpenStack, not \"OpenStack certified\" for OpenStack.  We are putting our brand behind the training, not representing the brand of the project itself.  It has never been part of our launch messaging or positioning, and if that was ever done it was an unfortunate mistake and not the company position.\n \nI 100% agree with you that should someone wish to have \"OpenStack Certified\" training that there should be rules governing such usage.  We do need to agree whether or not training certification is a mission the foundation should pursue or not.  Are there good examples in the open source community we believe we should emulate?\n \nJim\n \nFrom: \"Randy L. Bias\" <randyb at cloudscaling.com>\nDate: Tuesday, October 9, 2012 9:46 PM\nTo: Tristan Goode <tristan at aptira.com>\nCc: \"foundation-board at lists.openstack.org\" <foundation-board at lists.openstack.org>\nSubject: Re: [Foundation Board] Use of the word \"certified\" and guidelines around use of words like \"official\"\n \nI generally concur and I think this is a good catch.  Clearly the discussion isn\'t about RAX, but what the interim strategy is while things like what \"certification\" means are ironed out. \n \nHowever, I do want to point out that it might take a while to resolve that issue and I\'m inclined to avoid retarding the adoption of OpenStack.  Is it possible to allow for some kind of interim usage in a way that allows for revisiting this later with folks already using \"certified\" and also closing the door on potential abusers in the short term?  We need to be shown taking some control of this, but I suspect that it will take a while for definitions.\n \n \nhanks,\n \n\n--Randy\n\nCo-Founder & CTO, Cloudscaling\n+1 (415) 787-2253 [78-SCALE for SMS or voice] \nTWITTER: twitter.com/randybias\nLINKEDIN: linkedin.com/in/randybias\n \n \n \n \n \nOn Oct 9, 2012, at 6:12 PM, Tristan Goode <tristan at aptira.com> wrote:\n\n\nDear Board,\n \nI am very concerned at the use of the word \"certified\" in recent media releases by Rackspace for their training offerings, and most recently in this mail out below.\n \nI\'ve no doubt Rackspace\'s course is worthy of being OpenStack certified when there is such a thing, but until there is formality around this then I do not believe anyone should use this word or any other word that implies endorsement from OpenStack even loosely (as this is in some contexts) to describe any commercial offering.\n \nWith no formal certification guidelines in place or policy on use of such words, this has a real danger of de-valuing the OpenStack brand if (when) less reputable organisations or basically anyone gratuitously use the word. My reading of media releases around this in the last few days is that media have picked up the Rackspace offering as OpenStack certified.\n \nAfter mentioning this to Jonathan several days ago to his credit \"certified\" was removed from parts of the Rackspace web site, but not all, and today this email below has gone out to the conference attendee list.\n \nAfter following up with Jonathan yesterday he advised:\n \n\'Theoretically, this has always been an allowed usage under the \"built for OpenStack\" license, which Rackspace among others has signed up for (http://www.openstack.org/brand/built-for-openstack-logo/). The requirement is to provide a clear indication that the product is a company\'s offering FOR OpenStack, not FROM OpenStack (i.e. Foundation).\'\n \nThis is far too loose and allows anyone use of such terms, the result is that OpenStack \"certified\" training soon means nothing.\n \nI\'m 100% for having officially certified courses asap. Perhaps a solution is that any company that wishes to have certified or official or similar (Rackspace, Hastexo, Mirantis immediately come to mind) submits their curriculum and clear deliverables to a review panel of some type drawn from the Membership? This would ensure that OpenStack people get training that they want and the certified term is used appropriately.\n \nUntil then statements like below should not be permissible and should probably be retracted. By acting on this decisively I see the Foundation truly protecting the brand that is OpenStack.\n \nI welcome your discussion.\n \nThanks\nTristan\n \n \n \n \n \n \nFrom: Rackspace - OpenStack Summit Sponsor [mailto:redcarpetevents at rackspace.com] \nSent: Wednesday, 10 October 2012 11:11 AM\nTo: tristan at aptira.com\nSubject: Launch Your Career Into The Clouds\n \nDear OpenStack Summit Attendee --\nRackspace has a lot going on during the upcoming OpenStack Summit and we hope you will join us for our lively- and always informative- conference sessions.\nKeynote and Sessions for Wednesday, October 17:\n9:30 a.m.\nKEYNOTE: Running the World\'s Largest Open Cloud (Troy Toman, Senior Director of Engineering for Cloud Compute)\n11:00 a.m.\nThis is Your Career. This is Your Career on OpenStack. (Niki Acosta, Product Evangelist)\n11:50 a.m.\nBig Data on OpenStack: A Rackspace Use Case (Natasha Gajic, Enterprise, Business Intelligence Lead)\nStop by the Rackspace booth to talk all things open cloud with our team of experts. And while you\'re there, learn how you can accelerate your career by becoming one of the first Certified OpenStack technicians. OpenStack public training classes are now posted at www.rackspacetraining.com. Certification exams begin in December so be sure to stop by the Rackspace booth to get more information.\nAnd of course it wouldn\'t be a Rackspace-sponsored summit without an evening of fun to top it all off...\nReach for the Clouds Rooftop Party\nTuesday October 16\n6:00 p.m. - 8:00 p.m. Altitude Sky Lounge\nRSVP NOW\nCatch a ride to the celebration via the complimentary Rackspace pedicabs outside the Hyatt from 5:45 p.m. - 6:45 p.m. or enjoy the short walk to the lounge located atop the Marriott Gaslamp.\nSee you soon,\nYour Friends At Rackspace\n--------------------------------------------------------------------------------\nThis email was sent to OpenStack Summit attendees by Rackspace, a sponsor of the event.\nIf you do not want to receive a handful of emails from the Summit organizers and sponsors this week, please click here to unsubscribe ( [unsubscribe] )\nRackspace - OpenStack Summit Sponsor\n5000 Walzem, San Antonio, TX, 78218\n_______________________________________________\nFoundation-board mailing list\nFoundation-board at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121011/7640ee84/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.gif\nType: image/gif\nSize: 43 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121011/7640ee84/attachment-0001.gif>\n\n',NULL,NULL),('<02e001cf7be3$c509cc20$4f1d6460$@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 11:47:18',10800,'2014-05-30 08:47:18',NULL,'[openstack-dev] [neutron][L3] VM Scheduling v/s Network as\n	input any consideration ?','Sylvain,\n\n \n\nThank you for the background ? I will educate myself on this work.\n\n \n\nThanks,\n\nJohn\n\n \n\n \n\nFrom: Sylvain Bauza [mailto:sbauza at redhat.com] \nSent: Friday, May 30, 2014 11:31 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: jcsf; \'Carl Baldwin\'; \'A, Keshava\'\nSubject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as\ninput any consideration ?\n\n \n\nLe 30/05/2014 10:06, jcsf a ?crit :\n\nCarl,\n\n \n\nA new routing protocol is certainly of great interest.   Are you working\nwith IETF or can you share more here?\n\n \n\nWRT:Nova Schedule - There still are requirements for the Schedule to taking\ninto consideration network as a resource.   My focus is to figure out how to\nadd network capabilities to the Scheduler?s algorithm while still\nmaintaining clean separation of concerns between Nova and Neutron.   We\nwouldn?t want to get back into the nova-network situation.  \n\n \n\nJohn\n\n\nAs it was previously mentioned, there are already different kinds of\ngrouping for VMs in Nova that probably don\'t require to add new\nnetwork-specific features :\n - aggregates and user-facing AZs allow to define a common set of\ncapabilities for physical hosts upon which you can boot VMs\n - ServerGroups with Affinity/Anti-Affinity filters allow you to enforce a\ncertain level of network proximity for VMs\n\n\nOnce that said, there is also another effort of forking the Nova Scheduler\ncode into a separate project so that cross-projects scheduling could happen\n(and consequently Neutron could use it). This project is planned to be\ndelivered by K release, and will be called Gantt.\n\n\nSo, could you please mention which features do you need for Nova, so we\ncould discuss that here before issuing a spec ?\n\n-Sylvain\n\n\n\n\n\n\n\n \n\n \n\nFrom: Carl Baldwin [mailto:carl at ecbaldwin.net] \nSent: Friday, May 30, 2014 12:05 AM\nTo: A, Keshava\nCc: jcsf31459 at gmail.com; Armando M.; OpenStack Development Mailing List (not\nfor usage questions); Kyle Mestery\nSubject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as\ninput any consideration ?\n\n \n\nKeshava,\n\n \n\nHow much of a problem is routing prefix fragmentation for you?\nFragmentation causes routing table bloat and may reduce the performance of\nthe routing table.  It also increases the amount of information traded by\nthe routing protocol.  Which aspect(s) is (are) affecting you?  Can you\nquantify this effect?\n\n \n\nA major motivation for my interest in employing a dynamic routing protocol\nwithin a datacenter is to enable IP mobility so that I don\'t need to worry\nabout doing things like scheduling instances based on their IP addresses.\nAlso, I believe that it can make floating ips more \"floaty\" so that they can\ncross network boundaries without having to statically configure routers.\n\n \n\nTo get this mobility, it seems inevitable to accept the fragmentation in the\nrouting prefixes.  This level of fragmentation would be contained to a\nwell-defined scope, like within a datacenter.  Is it your opinion that\ntrading off fragmentation for mobility a bad trade-off?  Maybe it depends on\nthe capabilities of the TOR switches and routers that you have.  Maybe\nothers can chime in here.\n\n \n\nCarl\n\n \n\nOn Wed, May 28, 2014 at 10:11 PM, A, Keshava <keshava.a at hp.com> wrote:\n\nHi,\n\nMotivation behind this  requirement is ? to achieve VM prefix aggregation\nusing routing protocol ( BGP/OSPF)?.\n\nSo that prefix advertised from cloud to upstream will be aggregated.\n\n \n\nI do not have idea how the current scheduler is implemented. \n\nBut schedule to  maintain some kind of the ?Network to Node mapping to VM?\n..\n\nBased on that mapping to if any new VM  getting hosted to give prefix in\nthose Nodes based one input preference.\n\n \n\nIt will be great help us from routing side if this is available in the\ninfrastructure.\n\nI am available for review/technical discussion/meeting. \n\n \n\n \n\nThanks & regards,\n\nKeshava.A\n\n \n\nFrom: jcsf31459 at gmail.com [mailto:jcsf31459 at gmail.com] \nSent: Thursday, May 29, 2014 9:14 AM\nTo: openstack-dev at lists.openstack.org; Carl Baldwin; Kyle Mestery; OpenStack\nDevelopment Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as\ninput any consideration ?\n\n \n\nHi keshava,\n\n \n\nThis is an area that I am interested in.   I\'d be happy to collaborate with\nyou on a blueprint.    This would require enhancements to the scheduler as\nyou suggested.   \n\n \n\nThere are a number of uses cases for this.  \n\n  \n\n \n\n?John. \n\n \n\nSent from my  smartphone.\n\n\nFrom: A, Keshava?\n\nSent: Tuesday, May 27, 2014 10:58 AM\n\nTo: Carl Baldwin; Kyle Mestery; OpenStack Development Mailing List (not for\nusage questions)\n\nReply To: OpenStack Development Mailing List (not for usage questions)\n\nSubject: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as input\nany consideration ?\n\n \n\nHi,\n\nI have one of the basic question about the Nova Scheduler in the following\nbelow scenario.\n\nWhenever a new VM to be hosted is there any consideration of network\nattributes ? \n\nExample let us say all the VMs with 10.1.x is under TOR-1, and 20.1.xy are\nunder TOR-2.\n\nA new CN nodes is inserted under TOR-2 and at same time a new  tenant VM\nneeds to be  hosted for 10.1.xa network.\n\n \n\nThen is it possible to mandate the new VM(10.1.xa)   to hosted under TOR-1\ninstead of it got scheduled under TOR-2 ( where there CN-23 is completely\nfree from resource perspective ) ? \n\nThis is required to achieve prefix/route aggregation and to avoid network\nbroadcast (incase if they are scattered across different TOR/Switch) ? \n\n \n\n \n\n \n\n\n\n \n\nThanks & regards,\n\nKeshava.A\n\n \n\n \n\n \n\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/9fb3d391/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 30014 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/9fb3d391/attachment-0001.png>\n\n','<538841AB.7030502@redhat.com>',NULL),('<02E0DE0D-D531-491C-BF3D-9AE361017298@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 11:42:11',-25200,'2014-07-02 18:42:11',NULL,'[openstack-dev] [nova] Two questions about \'backup\' API','\nOn Jun 26, 2014, at 6:58 PM, wu jiang <wingwj at gmail.com> wrote:\n\n> Hi Vish, thanks for your reply.\n> \n> About Q1, I mean that Nova doesn\'t have extra processions/works for \'daily\'/\'weekly\' than other backup_types like \'123\'/\'test\'.\n> The \'daily\' & \'weekly\' don\'t have unique places in the API than any other else.\n> \n> But we gave them as examples in code comments especially in novaclient.\n> \n> A few users asked me why their instances were not backup-ed automatically, they thought we have a timing task to do this if the \'backup_type\' equals to \'daily\'/\'weekly\' because we prompt them to use it.. \n> Therefore, it\'s useless and inclined to make confusion for this API IMO. No need to show them in code comments & novaclient.\n> \n> P.S. So maybe \'backup_name\'/\'backup_tag\' is a better name, but we can\'t modify the API for compatibility..\n\nYes the name is confusing.\n\nVish\n\n> \n> \n> Thanks.\n> \n> WingWJ\n> \n> \n> On Fri, Jun 27, 2014 at 5:20 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> On Jun 26, 2014, at 5:07 AM, wu jiang <wingwj at gmail.com> wrote:\n> \n> > Hi all,\n> >\n> > I tested the \'backup\' API recently and got two questions about it:\n> >\n> > 1. Why \'daily\' & \'weekly\' appear in code comments & novaclient about \'backup_type\' parameter?\n> >\n> > The \'backup_type\' parameter is only a tag for this backup(image).\n> > And there isn\'t corresponding validation for \'backup_type\' about these two types.\n> >\n> > Moreover, there is also no periodic_task for \'backup\' in compute host.\n> > (It\'s fair to leave the choice to other third-parts system)\n> >\n> > So, why we leave \'daily | weekly\' example in code comments and novaclient?\n> > IMO it may lead confusion that Nova will do more actions for \'daily|weekly\' backup request.\n> \n> The tag affects the cleanup of old copies, so if you do a tag of ?weekly? and\n> the rotation is 3, it will insure you only have 3 copies that are tagged weekly.\n> You could also have 3 copies of the daily tag as well.\n> \n> >\n> > 2. Is it necessary to backup instance when \'rotation\' is equal to 0?\n> >\n> > Let\'s look at related codes in nova/compute/manager.py:\n> > #     def backup_instance(self, context, image_id, instance, backup_type, rotation):\n> > #\n> > #        self._do_snapshot_instance(context, image_id, instance, rotation)\n> > #        self._rotate_backups(context, instance, backup_type, rotation)\n> >\n> > I knew Nova will delete all backup images according the \'backup_type\' parameter when \'rotation\' equals to 0.\n> >\n> > But according the logic above, Nova will generate one new backup in _do_snapshot_instance(), and delete it in _rotate_backups()..\n> >\n> > It\'s weird to snapshot a useless backup firstly IMO.\n> > We need to add one new branch here: if \'rotation\' is equal to 0, no need to backup, just rotate it.\n> \n> That makes sense I suppose.\n> \n> Vish\n> \n> >\n> >\n> > So, what\'s your opinions? Look forward to your suggestion.\n> > Thanks.\n> >\n> > WingWJ\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/2ecaacae/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/2ecaacae/attachment.pgp>\n\n','<CAEfJYtR-B8UtPNAu=vC30zORBLQNXEOqMd2ALAv56aSn=GLx8Q@mail.gmail.com>',NULL),('<02E997406E378C40A23F6C3C0536DBAE11A5C800@xmb-aln-x12.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 18:53:26',0,'2014-10-27 18:53:26',NULL,'[openstack-dev] [all] Key signing at the summit?','I\'m relatively new to the keysigning *event* concept - can someone give a little more detail on this and where it comes into play? Does anyone else use a service (e.g., keybase.io) for this purpose?\n\n - Marty Falatic\n\n\n\n\n-----Original Message-----\nFrom: Clint Byrum [mailto:clint at fewbar.com] \nSent: Sunday, October 26, 2014 5:01 PM\nTo: openstack-dev\nSubject: [openstack-dev] [all] Key signing at the summit?\n\nHi everyone! We have a summit rapidly approaching, and to my knowledge, no key signing event planned. That is unfortunate, as the web of trust that we started building in Atlanta would be quite stronger as we add more European developers who I\'m sure will be present in large numbers due to proximity.\n\nI believe we may be too late to do a mass keysigning, though if others feel we have time to gather fingerprints and disseminate a list for printing, then I will try to devote some time to it in the next 24 hours. However, I want to encourage everyone to print out your signature en-masse (hint hint: print it on your business cards) so that you can do an impromptu verification of identity with somebody. It may also be valuable to arrange a time where everyone can be present with their government issued IDs even if there isn\'t a mass list.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1414340295-sup-5599@fewbar.com>',NULL),('<02ec01cbb011$81e25ee0$85a71ca0$@openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-01-09 09:25:54',-21600,'2011-01-09 15:25:54',NULL,'[Openstack-operators] Fresh installation','I would suggest starting by checking the IP info in all of your etc/swift\nconf files, a typo in there could do it. After that I would restart each\nserver in the ring and the proxy/auth servers. Verify all services are\nrunning after the reboot and try again. If that doesn\'t work let me know and\nwe will start to walk through your config. Also, be sure to check file\nownership. make sure everything in /etc/swift is set to swift:swift since\nthere is a permissions issue noted in the auth configuration that I have\nseen skipped over a number of times.\n\n \n\nFrom: openstack-operators-bounces at lists.openstack.org\n[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of\nJeffrey Taylor\nSent: Sunday, January 09, 2011 2:39 AM\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Fresh installation\n\n \n\nHi folks,\n\nI just started working on the guide located here:\nhttp://swift.openstack.org/howto_installmultinode.html#prerequisites\n\nand finally made it to the section regarding \" \n\n\nCreate Swift admin account and test\"\n\n\n\nWhen I execute the first command:\n\nswift-auth-add-user -K *myauthhere* -a system root *myrootuserpasswordhere*\n\nI get the following error:\nUpdate failed: 503 Service Unavailable\n\n\nI\'m at a bit of a loss as to why this may be, but here is the tail output\nfor /var/log/syslog:\n\nJan  9 08:18:16 auth auth-server 127.0.0.1 - - [09/Jan/2011:08:18:16 +0000]\n\"PUT /account/system/root HTTP/1.0\" 503 - \"-\" \"-\" - - - - - - - - - \"-\"\n\"127.0.0.1\" \"-\" 0.0168\nJan  9 08:18:36 auth auth-server SIGTERM received\nJan  9 08:18:36 auth auth-server Exited\nJan  9 08:18:37 auth auth-server Started child 7650\nJan  9 08:18:39 auth auth-server ERROR attempting to create account\nhttps://173.255.233.9:8080/v1/AUTH_eb0e9aa341674105ab0635ec8c064662: 500\nInternal Server Error\nJan  9 08:18:39 auth auth-server FAILED create_user(\'system\', \'root\', _,\nTrue, False) [0.02]\nJan  9 08:18:39 auth auth-server 127.0.0.1 - - [09/Jan/2011:08:18:39 +0000]\n\"PUT /account/system/root HTTP/1.0\" 503 - \"-\" \"-\" - - - - - - - - - \"-\"\n\"127.0.0.1\" \"-\" 0.0216\nJan  9 08:21:45 auth auth-server ERROR attempting to create account\nhttps://173.255.233.9:8080/v1/AUTH_6622656bf74b49b9b11cf371c12c1ae8: 500\nInternal Server Error\nJan  9 08:21:45 auth auth-server FAILED create_user(\'system\', \'root\', _,\nTrue, False) [0.02]\nJan  9 08:21:45 auth auth-server 127.0.0.1 - - [09/Jan/2011:08:21:45 +0000]\n\"PUT /account/system/root HTTP/1.0\" 503 - \"-\" \"-\" - - - - - - - - - \"-\"\n\"127.0.0.1\" \"-\" 0.0195\n\n\nSo, any help would be greatly appreciate. Thanks in advance!\n\n\n\n\n\n-- \nRegards,\n \nJeffrey Taylor\nCTO\nZipgrid\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110109/0a85a665/attachment.html>\n\n','<4D297437.6090505@zipgrid.com>',NULL),('<02f2affebcf1414c8021d3ebe5689eaa@BY2PR02MB377.namprd02.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-15 01:19:57',0,'2014-02-15 01:19:57',NULL,'[Openstack] Keystone Token Issue','All,\n\n\n\nRan into an issue.\n\n\n\nBackground: Installed Keystone Version: 1:2014.1~b1-0ubuntu1. Got busy with other things and came back to project. I am testing the install which was suppose to be successful but now I have a token issue.\n\nThis was working in early to mid December.\n\n\n\ncurl -H \"X-Auth-Token:XXXXXXXXXXXXXXXXXXX\" http://localhost:5000/v2.0/tenants\n{\"error\": {\"message\": \"The request you have made requires authentication.\", \"code\": 401, \"title\": \"Unauthorized\"/etc/keystone<mailto:%7D%7Droot@:/etc/keystone>#  curl -H \"X-Aup://localhost:5000/v2.0/tenants\n\n\n\nI am a little confused because I thought I did not think I set up a time limit on the token. Now Keystone token is breaking.\n\n\n\nI am looking for suggestions as to why the token expired and has no authentication now.  Also I need a better testing plan for the time lapse so I am open to suggestions. Thanks in advance.\n\n\n\nSincerely\n\n\n\nThomas McLaughlin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140215/f5ef3435/attachment.html>\n\n',NULL,NULL),('<02F614C2-2AFB-42F8-B7C8-FD6A5C416D6A@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-19 11:00:49',-18000,'2013-02-19 16:00:49',NULL,'[openstack-dev] [quantum] ImportError oslo.config when run_tests.sh\n	-f','I updated my development branch today with the latest from master, and then ran unit tests with -f to rebuild my environment. I\'m getting the following error:\n\nCleaning virtualenv...\nNo virtual environment found...create one? (Y/n) y\nTraceback (most recent call last):\n  File \"tools/install_venv.py\", line 31, in <module>\n    import install_venv_common as install_venv\n  File \"/opt/stack/quantum/tools/install_venv_common.py\", line 35, in <module>\n    from oslo.config import cfg\nImportError: No module named oslo.config\ntools/with_venv.sh: line 21: tools/../.venv/bin/activate: No such file or directory\ntools/with_venv.sh: line 21: tools/../.venv/bin/activate: No such file or directory\n\n\nThere is no oslo directory anywhere in the quantum tree. I double checked and did a second pull from master, but same issue.  Am I missing something?  I saw some e-mail about some tar ball for oslo-config. Do I need that? If so, shouldn\'t it be part of the pull for master though?\n\n\nThanks in advance,\n\nPCM (Paul Michali)\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130219/8e495f19/attachment.pgp>\n\n',NULL,NULL),('<02F65592-794E-4F67-9256-0249E791D846@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-29 09:54:59',-14400,'2012-10-29 13:54:59',NULL,'[openstack-dev] [quantum] Understanding DHCP Agent','You have the correct data flow for data requests initiated by the agent.\n\nmark\n\nOn Oct 26, 2012, at 10:31 PM, Trinath Somanchi <trinath.somanchi at gmail.com> wrote:\n\n> Hi-\n> \n> Please help me understand the data flow in the source code of the DHCP agent.\n> \n>> I was trying to understand how the Quantum DHCP agent Daemon works.  As I walk through the code, to understand the working on the Daemon,\n>> \n>> I found it to be using rpc cast and call. But was lost into the code to find the correct data flow.\n>> \n>> In my study I found this:\n>> \n>> \n>> \n>> \n>> quantum/agent/dhcp_agent.py     <--- the actual daemon agent, which makes the rpc.cast/rpc.call to fetch the data.\n>> \n>>            A                  |                  <------ (Flow representing arrows)\n>>             |                  V\n>> quantum/db/dhcp_rpc_base.py     <---- which implements the QuantumPluginV2 to process the rpc.cast/rpc.call by the above agent.\n>> \n>>              A                |                   <------ (Flow representing arrows)\n>>               |                V\n>> quantum/db/db_base_plugin_v2.py    <--- where the actual DB processing happens for the requests.     \n>> \n>> \n>>    \n>> \n>> [1] Am I in a right path of understanding the dhcp agent daemon working.\n>> \n>> Kindly please help me understand the processes flow\n>> \n> --\n> Trinath\n> \n> \n> On Fri, Oct 26, 2012 at 10:45 PM, Trinath Somanchi <trinath.somanchi at gmail.com> wrote:\n> Mark-\n> \n> First, thanks for the informative reply.\n> \n> True Said, I understood the flow. But then, I want to look into this scenario by means of the Source Code. \n> \n> As described in the mail by me, I\'m understanding How the Data flow inside the code.\n> \n> Hence, I have put forward my understanding in the RPC call and cast of the dhcp agent. \n> \n> as below.\n> \n>> quantum/agent/dhcp_agent.py     <--- the actual daemon agent, which makes the rpc.cast/rpc.call to fetch the data.\n>> \n>>            A                  |                  <------ (Flow representing arrows)\n>>             |                  V\n>> quantum/db/dhcp_rpc_base.py     <---- which implements the QuantumPluginV2 to process the rpc.cast/rpc.call by the above agent.\n>> \n>>              A                |                   <------ (Flow representing arrows)\n>>               |                V\n>> quantum/db/db_base_plugin_v2.py    <--- where the actual DB processing happens for the requests.     \n> \n> \n> Here, (I\'m new to the folsom code) i have outlined how the data flow between the files is happening from my understanding.\n> \n> Can you kindly please help me on the validity of my understanding. Were there any other files which help to achieve this in dhcp agent ?\n> \n> Thanking you..\n> \n> -\n> Trinath\n> \n> \n> On Fri, Oct 26, 2012 at 9:07 PM, Mark McClain <mark.mcclain at dreamhost.com> wrote:\n> Trinath-\n> \n> The DHCP agent uses both RPC and Notifications.  The general rule is that information originated by the Server flows via notifications and the agent uses RPC to request information from the Quantum server or notify the server of lease renewals. \n> \n> In a cold start situation, the agent will:\n> \n> Make RPC call for active networks (the RPC flow is as your described below)\n> Start any DHCP services for active networks\n> Enter Notification Processing Loop\n> 	- Wait for changes to Networks, Subnets, Ports\n> 	- Modify DHCP daemon configs in response to those changes\n> 		(If notification payload does not have enough information use RPC to clarify current state)\n> \n> Does this clarify how the agent works?\n> \n> mark\n> \n> On Oct 26, 2012, at 11:10 AM, Trinath Somanchi <trinath.somanchi at gmail.com> wrote:\n> \n>> Hi-\n>> \n>> I was trying to understand how the Quantum DHCP agent Daemon works.  As I walk through the code, to understand the working on the Daemon,\n>> \n>> I found it to be using rpc cast and call. But was lost into the code to find the correct data flow.\n>> \n>> In my study I found this:\n>> \n>> \n>> \n>> \n>> quantum/agent/dhcp_agent.py     <--- the actual daemon agent, which makes the rpc.cast/rpc.call to fetch the data.\n>> \n>>            A                  |                  <------ (Flow representing arrows)\n>>             |                  V\n>> quantum/db/dhcp_rpc_base.py     <---- which implements the QuantumPluginV2 to process the rpc.cast/rpc.call by the above agent.\n>> \n>>              A                |                   <------ (Flow representing arrows)\n>>               |                V\n>> quantum/db/db_base_plugin_v2.py    <--- where the actual DB processing happens for the requests.     \n>> \n>> \n>>    \n>> \n>> I have some doubts here, (though there very preliminary)\n>> \n>> [1] The RPC cast and call are sent to the Quantum server ?\n>> [2] Am I in a right path of understanding the dhcp agent daemon working.\n>> \n>> Kindly please help me understand the processes flow\n>> \n>> Thanks in advance. \n>> \n>> -- \n>> Regards,\n>> ----------------------------------------------\n>> Trinath Somanchi,\n>> +91 9866 235 130\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Regards,\n> ----------------------------------------------\n> Trinath Somanchi,\n> +91 9866 235 130\n> \n> \n> \n> \n> -- \n> Regards,\n> ----------------------------------------------\n> Trinath Somanchi,\n> +91 9866 235 130\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121029/a1427a56/attachment-0001.html>\n\n','<CAH8Hgmaqv-dp_6WvCS7LHbLVzJ9vthNwR9uowOb057H8HH+j0Q@mail.gmail.com>',NULL),('<02FA4C5C-DF6A-482E-A56C-8DB26C37A3FD@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 07:24:11',-25200,'2014-08-25 14:24:11',NULL,'[openstack-dev] [Swift] 2.1.0-rc tagged','Swift 2.1.0.rc1 has been tagged as our release candidate for 2.1.0. The plan is to let this RC soak for a week and then do the final release on Sept 1.\n\nPlease check it out and report any issues that you find.\n\n\nTag applied:\nhttp://git.openstack.org/cgit/openstack/swift/commit/?id=8d02147d04a41477383de8e13bea6ac3fd2cade0\n\nTarball built:\nhttp://tarballs.openstack.org/swift/swift-2.1.0.rc1.tar.gz\n\nBugfixes marked released at:\nhttps://launchpad.net/swift/+milestone/2.1.0\n\n\n\n--John\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/7791a53b/attachment.pgp>\n\n',NULL,NULL),('<02FC13F8-83B9-4D95-9138-4FF3B1EA2D6B@gmail.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-02 09:03:09',-25200,'2012-10-02 16:03:09',NULL,'[openstack-tc] Designation of TC Chair','\nOn Oct 2, 2012, at 7:22 AM, Thierry Carrez wrote:\n\n> Mark McLoughlin wrote:\n>> On Mon, 2012-10-01 at 11:24 +0200, Thierry Carrez wrote:\n>>> I have been filling the TC Chair duties during all the TC setup phase,\n>>> and would be happy to continue to do so. I happen to know the TC rules\n>>> well, since I wrote them. If someone else is interested by the role (or\n>>> more people), please say so and we can have a quick vote to decide this.\n>> \n>> FWIW, I think it makes perfect sense for you to be TC Chair.\n> \n> Thanks all for your support!\n> \n> Brian, Vish, John D.: please let us know your thoughts on the matter so\n> that we can pass the recommendation to the BoD asap.\n\nI\'d love for you to chair this committee, Thierry.\n\n\n\n','<506AF8AE.8090802@openstack.org>',NULL),('<0301C916-83F6-49E2-AF47-39C9556A56AA@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-28 11:20:52',-25200,'2014-03-28 18:20:52',NULL,'[Openstack-operators] Help on Iptables in Openstack','IPtables rules are automatically generated based on your configuration.\nThey also get deleted and recreated every time you restart a service.\nIf you want to test something though, you coud run\niptables-save > /root/iptables.rules\n\nvi /root/iptables.rules\n\niptables-restore < /root/iptables.rules\n\n\nOn Mar 28, 2014, at 10:05, shiva m <anjaneya2 at gmail.com> wrote:\n\n> Hi,\n> \n> I installed devstack-havana on ubuntu-13.10. I see iptables-save with all iptable rules. Can any one please help me how do I  add a new rule  or edit iptables-save  on  Openstack?\n> \n> Thanks\n> Shiva\n> \n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140328/dc34696c/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 535 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140328/dc34696c/attachment.pgp>\n\n','<CAGm0vUoJ2c=-C=RJDZLg_pbLh5Hd1fKzEO1eR1wAiXUtoxb0jA@mail.gmail.com>',NULL),('<0302302E-9FF2-409F-87F1-547FB2639E10@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 17:27:03',3600,'2015-01-27 16:27:03',NULL,'[openstack-dev] [Fuel] removing single mode','+1, long awaited\n\n\n> On 27 Jan 2015, at 14:05, Aleksandr Didenko <adidenko at mirantis.com> wrote:\n> \n> Hi,\n> \n> After starting implementing granular deployment we\'ve faced a bunch of issues that would make further development of this feature much more complicated if we have to support both Simple and HA deployment modes. For example: simple mode does not require cluster (corosync, pacemaker, vips, etc), so we had to skip this task for Simple mode somehow - we can use conditional tasks, or conditional manifests in our tasks, or create separate task graphs for different deployment modes, etc - either way it\'s pretty much doubling the amount of work for some parts of Fuel and our development cycle.\n> \n> At the moment, CI blocks us from further development of fuel-library modularization BP [2] because we still use Simple mode in CI. So in order to proceed with this BP we have two options:\n> \n> 1) remove Simple mode from CI/QA and thus drop it completely from Fuel\n> 2) double our efforts to support both Simple and HA modes in granular deployment\n> \n> We have a BP about single-controller HA [1]. HA with single controller works just fine at the moment. So if you want to test Fuel on a minimum set of nodes, you can do this on 3 nodes (Fuel master, controller, compute), just like with Simple mode before. I suppose, it\'s time to finally drop support for Simple mode in Fuel :)\n> \n> [1] https://blueprints.launchpad.net/fuel/+spec/single-controller-ha\n> [2] https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization\n> \n> --\n> Regards,\n> Aleksandr Didenko\n> \n> \n> On Tue, Aug 26, 2014 at 9:25 AM, Mike Scherbakov <mscherbakov at mirantis.com> wrote:\n> Definitely fuel spec is needed :)\n> \n> \n> On Mon, Aug 25, 2014 at 8:45 PM, Evgeniy L <eli at mirantis.com> wrote:\n> Hi Andrew, \n> \n> I have some comments regarding to you action items\n> \n> >> 2) Removing simple mode from the ui and tests\n> >> 3) Removing simple mode support from nailgun (maybe we leave it) and cli\n> \n> We shouldn\'t do it, because nailgun should handle both versions of cluster.\n> What we have to do here is to use openstack.yaml to keep all possible modes.\n> For new release there will be only ha, to manage previous releases we have\n> to create data migrations in nailgun to create the filed with modes i.e. multinode\n> and ha.\n> \n> Also fixes for ui are required too, I think it mostly related to wizard, \'mode\' tab\n> where use can chose ha or non ha cluster in case of new release there should\n> be only ha, and in case of old releases there should be ha and multinode.\n> \n> Thanks,\n> \n> \n> \n> On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward <xarses at gmail.com> wrote:\n> Started a new thread so that we don\'t hijack the older thread.\n>  as \n>  \n> Andrew, will you work on it in 6.0? What are remaining items there? Also, it might affect our tests - simple mode runs faster so we use it for smoke ISO test. Anastasia, please confirm that we can switch smoke to one-ha-controller model, or even drop smoke at all and use BVT only (running CentOS 3 HA controllers and same with Ubuntu).\n> \n> The primary reason that we haven\'t disabled single yet is was due to [0] where we where having problems adding additional controllers. With the changes to galera and rabbit clustering it appears that we ended up fixing it already.\n> \n> The remaining issues are:\n> 1) Ensuring we have good test coverage for the cases we expect to support [1]\n> 2) Removing simple mode from the ui and tests\n> 3) Removing simple mode support from nailgun (maybe we leave it) and cli\n> 4) Updating documentation\n> \n> [0] https://bugs.launchpad.net/fuel/+bug/1350266\n> [1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7\n> \n> -- \n> Andrew\n> Mirantis\n> Ceph community\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Mike Scherbakov\n> #mihgen\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nTomasz \'Zen\' Napierala\nSr. OpenStack Engineer\ntnapierala at mirantis.com\n\n\n\n\n\n\n\n\n','<CAOe9ns4yzCc6yUnyyeEMC0h1haFpsgyJbbB6i3==4w1WaF08dQ@mail.gmail.com>',NULL),('<032DADF2-2ED5-42BB-9BD0-63AE0A5C349F@justwriteclick.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-17 12:32:32',-25200,'2013-04-17 19:32:32',NULL,'[openstack-dev] Source for the Swift API spec?','Yes, that is correct.\n\nAnne Gentle\nContent Stacker\nanne at openstack.org\n\n\nOn Apr 17, 2013, at 11:04 AM, Adrian Smith <adrian_f_smith at dell.com> wrote:\n\n> I think this it the repo Pete, https://github.com/openstack/object-api\n> \n> Adrian\n> \n> On 17 April 2013 18:26, Pete Zaitcev <zaitcev at redhat.com> wrote:\n>> Just curious after Anne joined a breakfast table and talked about helping\n>> with the docs: where is the source of the Swift API spec? I\'m talking\n>> about this:\n>> http://docs.openstack.org/api/openstack-object-storage/1.0/content/\n>> \n>> I have manuals repo cloned, but apparently it\'s not there.\n>> (this - git://github.com/openstack/openstack-manuals.git)\n>> \n>> Obviously it\'s not in doc/source/ of Swift repo either. But it has to\n>> be _somewhere_, right?\n>> \n>> -- Pete\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAKgbHu29F0VH0CzkswMaJZaaqPxjSRnZP0y6JsX7C90Pwz6Reg@mail.gmail.com>',NULL),('<032F976D-FB33-427C-8A60-98080BC6E431@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 07:28:39',-28800,'2013-11-25 15:28:39',NULL,'[openstack-dev] [nova] remote debugging','Hi Folks - i am trying to add a patch to enable remote debugging in the nova services.  I can make this work very simply, but it requires a change to monkey_patching - i.e.\n\n    eventlet.monkey_patch(os=False, select=True, socket=True, thread=False,\n                      time=True, psycopg=True)\n\nI?m working with some folks from the debugger vendor (pycharm) on why this is needed.   However - i?ve been using it with nova-compute for a month or so and do not see any issues which changing the monkey-patching.  Since this is done only when someone wants to use the debugger - is making this change so bad?\n\n https://review.openstack.org/56287\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/5ab7a451/attachment.html>\n\n','<30371470-E2D0-4583-A827-63F4BFC42C90@vmware.com>',NULL),('<033601cee9ce$7e3dfed0$7ab9fc70$@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-25 20:07:13',32400,'2013-11-25 11:07:13',NULL,'[Openstack] multipath - EMC vs NetApp','Hello Xing and all,\n\nWe tried to set up iSCSI multipath with EMC VNX5300.\nHowever, we had some problems with setting the iSCSI multipath with EMC\nVNX5300.\nSo, we analyzed the logs and source codes, and found out that nova-compute\n(cinder-volume also same) is using a single iSCSI target(IQN) for login to\nmultiple (different) portal IP addresses.\nVNX5300 has multiple iSCSI ports with different iSCSI target (IQN)s.\n(Normally it should use a different iSCSI target(IQN) for each IP address.)\n\nSo, we realized that, iSCSI multipath cannot be configured with VNX5300.\nBut we would like to use iSCSI multipath with EMC VNX5300.\n\nRegards,\nTakashi Natsume\nNTT Software Innovation Center\nTel: +81-422-59-4399\nE-mail: natsume.takashi at lab.ntt.co.jp\n\nFrom: yang, xing [mailto:xing.yang at emc.com] \nSent: Friday, November 22, 2013 7:25 AM\nTo: Carlos Alvarez; openstack at lists.openstack.org\nSubject: Re: [Openstack] multipath - EMC vs NetApp\n\nHi Carlos,\n\nWe are working on this issue and will keep you informed.\n\nThanks,\nXing\n\n\nFrom: Carlos Alvarez [mailto:cbalvarez at gmail.com] \nSent: Monday, November 18, 2013 1:19 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] multipath - EMC vs NetApp\n\nHi All.\n\nI recently added a EMC V-Max storage system, and realized the multipath is\nnot working. The device is called /dev/mapper/XXXX but when I see the\nmultipath -ll output, I see just one path. It is working fine with a NetApp\n3250.?\n\nLooking into differences, I see the output of the iscsiadm discovery\ndiffers:\n\nNetapp output:\nroot at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p 10.33.5.10\n10.33.5.10:3260,1030\niqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n10.33.5.11:3260,1031\niqn.1992-08.com.netapp:sn.0e3c22d9f2ea11e2a2f2123478563412:vs.10\n\nEmc output:\nroot at grizzly-dev04:~# iscsiadm -m discovery -t sendtargets -p 10.33.5.25\n10.33.5.25:3260,1 iqn.1992-04.com.emc:50000973f00bcd44\n\n\nLooking into the code, the former is clearly what the connect_volume method\nis expecting: a single ip which returns both path. I reported it to EMC and\nthe answer is that it works with netapp because the 3250 has a feature EMC\nlacks (called multipath groups).?\n\nIs anybody using multipath with a V-Max?. It should work or EMC is not\nsupported?\n\nThanks!\nCarlos\n\n\n\n\n','<35804680EDCC5640AFC7C590814F48F50115EDBB4A87@MX40A.corp.emc.com>',NULL),('<033779B9-3612-45B7-B919-AD233BA8FBBE@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-04-26 23:43:33',7200,'2013-04-26 21:43:33',NULL,'[Openstack-operators] Monitoring Openstack','Zabbix user here :)\nThe 1.8 version is rock stable and with little imagination you can monitor your cloud easily.\nTakes time when you want to monitor more than running processes, let\'s say parsing logs, checking processes \"status\" and various outputs \nregards\nRazique\n\nLe 26 avr. 2013 ? 20:52, Tim Bell <Tim.Bell at cern.ch> a ?crit :\n\n>  \n> One of the things I like about Nagios plug-ins is that they are relatively simple to understand.\n>  \n> Redhat?s RDO is already using some basic Nagios plugins but I think this would make sense as a stackforge project (as the puppet configuration recipes are now available). Other monitoring systems can often use Nagios plugins (or the logic can be easily adapted).\n>  \n> Having a ?best of breed? plug in set would greatly help deployments. Ultimately, identifying cases such as RabbitMQ queues with lots of messages or fatal error messages in the logs would be very useful to build up.\n>  \n> Tim\n>  \n>  \n> From: Joe Topjian [mailto:joe.topjian at cybera.ca] \n> Sent: 26 April 2013 20:47\n> To: Tim Bell\n> Cc: Jay Pipes; openstack-operators at lists.openstack.org\n> Subject: Re: [Openstack-operators] Monitoring Openstack\n>  \n> In addition to that, one of the great many items on my todo list is to write alerts for \"can an instance launch without error?\" or \"can a snapshot be created\"?\n>  \n> \n> On Fri, Apr 26, 2013 at 12:40 PM, Tim Bell <Tim.Bell at cern.ch> wrote:\n> \n> Is there a repository for nagios probes for OpenStack ?\n> \n> I\'m thinking of more than just \'is this process running\' but also \'is this REST API service responding correctly\'\n> \n> Tim\n> \n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 26 April 2013 19:41\n> > To: openstack-operators at lists.openstack.org\n> > Subject: Re: [Openstack-operators] Monitoring Openstack\n> >\n> > Nagios for monitoring. Graphite/Diamond, Logstash, Kibana for graphing and log analysis.\n> >\n> > -jay\n> >\n> > On 04/26/2013 03:29 AM, Sylvain Bauza wrote:\n> > > Nagios/Centreon with eventhandlers for automating basic troubleshooting.\n> > > Centreon is pretty cool for graphing RRD databases populated thru NDO\n> > > driver.\n> > >\n> > > -Sylvain\n> > >\n> > >\n> > > Le 25/04/2013 18:38, Stefano Zilli a ?crit :\n> > >> Hi list,\n> > >>\n> > >> we are planning to deploy a monitoring system to check Openstack services availability so I would like to do a quick survey on\n> what you\n> > currently use. I found several pages regarding this topic but they all end up in a war of religion between Nagios/Icinga, Zabbix\n> and other\n> > systems users.\n> > >>\n> > >> It would be nice to see what are in your opinion the strong and weak points of these products based on your daily experience\n> with\n> > them.\n> > >>\n> > >> Thanks,\n> > >> Stefano.\n> > >>\n> > >>\n> > >> _______________________________________________\n> > >> OpenStack-operators mailing list\n> > >> OpenStack-operators at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operato\n> > >> rs\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-operators mailing list\n> > > OpenStack-operators at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator\n> > > s\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n> \n>  \n> -- \n> Joe Topjian\n> Systems Administrator\n> Cybera Inc.\n>  \n> www.cybera.ca\n>  \n> Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130426/ca714b75/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5A87C29B9@CERNXCHG01.cern.ch>',NULL),('<033EBFF0-0718-423C-B2CB-E11167E614F1@minuteware.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 14:40:55',7200,'2014-01-13 12:40:55',NULL,'[Openstack] [Openstack-docs] Very Simple step-by-step Openstack\n	Havana/Neutron/Openvswitch Installation guide','Hi Marco,\n\nThanks for your great work! I have one question though. Could you please explain why are you using another method of adding the havana Ubuntu packages than the official guide? In the official guide they do \"apt-get install python-software-properties\" and then \"add-apt-repository cloud-archive:havana\", whereas you do it differently here https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst#21-preparing-ubuntu\n\nThanks.\n\n---\nRegards,\nAndriy Yurchuk\n\n\nOn Jan 9, 2014, at 12:03 PM, Marco Fornaro <Marco.Fornaro at huawei.com> wrote:\n\n> Hi All,\n>  \n> I wrote an unofficial as-easy-as-possible and step-by-step Installation guide for Openstack Havana+Neutron+Openvswitch:\n> https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst\n>  \n> Please let me know what you think about and if it can be useful to anyone\n>  \n> My Idea is to first check this guide ?easily? published on github with users, and then propose a similar guide structure for some part of the official documentation (for instance as an example of complete installation)\n>  \n>  \n>  \n> Best Regards\n>  \n> Marco\n>  \n>  \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n','<C24481BC2FAA754ABE58127FA2A6273748B66D7C@lhreml508-mbx>',NULL),('<033EBFF0-0718-423C-B2CB-E11167E614F1@minuteware.net>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-13 14:40:55',7200,'2014-01-13 12:40:55',NULL,'[Openstack-docs] Very Simple step-by-step Openstack\n	Havana/Neutron/Openvswitch Installation guide','Hi Marco,\n\nThanks for your great work! I have one question though. Could you please explain why are you using another method of adding the havana Ubuntu packages than the official guide? In the official guide they do \"apt-get install python-software-properties\" and then \"add-apt-repository cloud-archive:havana\", whereas you do it differently here https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst#21-preparing-ubuntu\n\nThanks.\n\n---\nRegards,\nAndriy Yurchuk\n\n\nOn Jan 9, 2014, at 12:03 PM, Marco Fornaro <Marco.Fornaro at huawei.com> wrote:\n\n> Hi All,\n>  \n> I wrote an unofficial as-easy-as-possible and step-by-step Installation guide for Openstack Havana+Neutron+Openvswitch:\n> https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst\n>  \n> Please let me know what you think about and if it can be useful to anyone\n>  \n> My Idea is to first check this guide ?easily? published on github with users, and then propose a similar guide structure for some part of the official documentation (for instance as an example of complete installation)\n>  \n>  \n>  \n> Best Regards\n>  \n> Marco\n>  \n>  \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n','<C24481BC2FAA754ABE58127FA2A6273748B66D7C@lhreml508-mbx>',NULL),('<034162D9-D5F0-424A-9AC5-F59749D33C1A@rackspace.co.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-02 21:36:26',0,'2012-05-02 21:36:26',NULL,'[Openstack-operators] Question Regarding Swift\n	Distribution	Statistics','You can use swift-get-nodes to see how a swift ring would distribute specific objects, this gives you the curl to query the appropriate service on each node directly to confirm whether they\'re actually there. A more useful tool might be the swift-dispersion-report and -populate tools which is designed to place objects across the cluster and report on the replica availability and cluster health from a cron or something.\n\nhttp://swift.openstack.org/admin_guide.html#cluster-health\n\nOn 2 May 2012, at 21:48, Duncan McGreggor wrote:\n\ncc\'ing openstack list\n\nOn Wed, May 2, 2012 at 4:45 PM, Richard Raseley <Richard at raseley.com<mailto:Richard at raseley.com>> wrote:\nI am trying to figure out the best way to see view the distribution of a\nfile or files across my test swift setup. I want to basically upload a file\nor files to containers and then be able to run a command or script that will\ntell me \"See, these files *are* actually distributed over these particular\nzones / nodes.\"\n\nIs there anything built into Swift like this? Thank you in advance for your\nanswers.\n\n\n\n\nAndrew Hale\nLinux Systems Engineer  [experience Fanatical Support]\n\nTel:    +442087342500\nMob:    +447720948819\nWeb:    www.rackspace.co.uk<http://www.rackspace.co.uk>\n        [Rackspace]\n\n\n\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120502/a05d6111/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image60e44f.JPG\nType: image/jpeg\nSize: 2877 bytes\nDesc: image60e44f.JPG\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120502/a05d6111/attachment-0004.jpe>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image21c6ca.JPG\nType: image/jpeg\nSize: 990 bytes\nDesc: image21c6ca.JPG\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120502/a05d6111/attachment-0005.jpe>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image71eb67.JPG\nType: image/jpeg\nSize: 8223 bytes\nDesc: image71eb67.JPG\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120502/a05d6111/attachment-0006.jpe>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image22886f.JPG\nType: image/jpeg\nSize: 1074 bytes\nDesc: image22886f.JPG\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120502/a05d6111/attachment-0007.jpe>\n\n','<CAG_87Ok+pAqDcJbU0jDYESex1yeovb1-R8Z8jmpXYOAyPg6m5Q@mail.gmail.com>',NULL),('<034801cef762$06118430$12348c90$@ait.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-12 12:45:46',-18000,'2013-12-12 17:45:46',NULL,'[Openstack] HA OpenStack','I have a 90% complete Openstack env running cinder,nova,quantum and glance.\nI am running into some issues but can\'t seem to find any reasonable\nconsulting firms so I am looking for someone with some decent experience to\nhelp out. Feel free to email me back directly for more details.\n\n \n\nByron Briggs\n\nSystems Engineering\n\nAdvanced Internet Technologies\n\n910-222-4467\n\n \n\nFrom: trinath.somanchi at freescale.com [mailto:trinath.somanchi at freescale.com]\n\nSent: Thursday, December 12, 2013 2:19 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] [FWaaS] FWaaS in Horizon\n\n \n\nHi-\n\n \n\nWith respect to the following Openstack Wiki,\nhttps://wiki.openstack.org/wiki/Quantum/FWaaS/HowToInstall\n\n \n\nI have installed and configured FWaaS, but then I haven\'t got the Horizon\nscreens shown in the Wiki link above.\n\n \n\nIs there any other installation required for the FWaaS Screens ??\n\n \n\nPlease help me with the required instructions.\n\n \n\n--\n\nTrinath Somanchi - B39208\n\ntrinath.somanchi at freescale.com <mailto:trinath.somanchi at freescale.com>  |\nextn: 4048\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131212/75bd0c4f/attachment.html>\n\n',NULL,NULL),('<034895C7-E986-42C5-8E7F-BDDE32D2CCF3@rackspace.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-24 17:41:16',0,'2014-01-24 17:41:16',NULL,'[openstack-tc] Discussion about a new umbrella / project for\n consumer / user experience','Hi all; please excuse my newbness. Despite being involved in a lot of other OSS/Foundations/etc - I?m still adapting to the OpenStack way.\n\nBased on the unified client discussion on the -dev list, as well as discussions I?ve had with many others over the past two months, some on the TC, some PTLs, etc there seems to be a general consensus that:\n\n1: The end-user (consumer) experience for the CLI tools / clients is sub-optimal\n2: The developer experience for consuming openstack clouds is sub optimal\n3: Oslo is not the right place for this work\n\nIf you look at the current structure of the projects - a few things pop out - most of them are focused on operators / deployers of OpenStack or, the services themselves. The standouts in this are Horizon and openstack client which have a different audience focus (consumers).\n\nWorking through the unified SDK plan, this audience focus again comes around - we are discussing:\n\n1: Creating a unified software development kit for openstack\n2: This SDK is aimed at making consumers of openstack clouds lives simpler - single namespace, etc.\n3: This would centralize a lot of the code and work on the Python APIs to consume OpenStack services \n4: This would mean that the individual python-* clients would be ideally lightweight front-ends to this SDK\n5: Openstackclient would be able to act like item 4: it would be a command line only wrapper to the main SDK\n\nGiven the schism in audiences, it looks like Horizon, this project, a unified CLI project and management of the individual CLI tools would fall under a Consumer / User Experience umbrella. \n\nIf you look at the governance setup:\n\n	http://git.openstack.org/cgit/openstack/governance/commit/\n\nIt seems to make sense that the UX proposal potentially be revived; but have actionable items under 3-4 sub teams:\n\n1: Unified SDK / Consumer-Developer tools\n2: Unified Client tools (CLI)\n3: Horizon (UI)\n4: Security\n5: i18n \n\nThe last two are sort of tied into this as well, as well as potentially Accessibility - but that?s more of a line item deliverable for Horizon.\n\nI?d appreciate your thoughts: currently I am heads down on a Unified SDK wiki page + blueprints but taking a step back and looking at it holistically, this may be one piece of the overall User Experience of OpenStack. However I think that 1, 2 and 3 stay in their own repositories (and not be pushed into an oslo-like incubator) while 4 & 5 work on deliverable timelines under this umbrella.\n\nI have gotten feedback from HP, others at Rackspace, Dreamhost and users / maintainers that a goal like this is desirable and would greatly help openstack in the eyes of the consumer. However my lack of familiarity and background as a programmer means my gut is to write a spec and then go do that versus discussing the bigger view :)\n\nJesse\n\n',NULL,NULL),('<034b01ce523e$ef1ae410$cd50ac30$@opennetworking.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-16 08:09:08',-21600,'2013-05-16 14:09:08',NULL,'[openstack-community] Community Post: Open Networking Foundation\n	has launched the first Open-Source \"OpenFlow Driver\" Contest\n	with $50K award','Dear OpenStack Community:\n\nWhile we announced this via the press and to our 100+ members, we wanted to\nmake certain that you heard the news about our Driver Contest. The award for\nthe best driver is US $50,000 (not selling anything, just passing the word\nalong to a great community; nothing to buy, no salesman will call). Like\nOpenStack, we wanted our environment (which strongly relates to cloud\ncomputing) to be FOSS. \n\nPlease feel free to circulate this notice anywhere you like, especially to\nany development portals or communities in which you or your company\nparticipates. If you have any questions, or are considering a submission,\nplease feel free to contact me.\n\nAbout ONF\n\nLaunched in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon,\nand Yahoo!, the Open Networking Foundation (ONF) is a growing nonprofit\norganization with more than 90 members whose mission is to advance the\ncommercialization and use of SDN and the OpenFlow protocol. ONF will\naccelerate the delivery and use of SDN and OpenFlow technologies and\nstandards while fostering a vibrant market of products, services,\napplications, customers, and users. For further details visit the ONF\nwebsite at:  <http://www.opennetworking.org> http://www.opennetworking.org.\n\n \n\n \n\nGood luck!\n\n \n\nRick\nRick Bauer\nTechnical Programs Manager\nOpen Networking Foundation\n\n---------------------------------------------------------- \n\n\n\n\nPress Releases\n\nOpen Networking Foundation Launches Industry\'s First Open-Source \"OpenFlowT\nDriver\" Contest\n\n \n\nCompetition to Encourage Implementation, Interoperability of the OpenFlow\nStandard\n\n \n\nOPEN NETWORKING SUMMIT, Santa Clara, Calif., April 17, 2013 - The Open\nNetworking Foundation (ONF), a non-profit organization dedicated to\npromoting Software-Defined Networking (SDN), today announced the industry\'s\nfirst competition to create an open-source \"OpenFlowT Driver.\" The\ncompetition is open to the worldwide development community to create an\ninteroperable open-source implementation of the latest OpenFlow standard.\nONF intends the competition to produce an OpenFlow driver that everyone from\nnetwork equipment vendors and ISVs to operators, and larger open-source\nprojects can use for easy transitions between different implementations of\nthe OpenFlow protocol. The winner of the \"OpenFlow Driver\" competition will\nbe awarded one grand prize of $50,000.\n\n \n\n\"ONF is committed to solving market needs in very practical ways,\" said Dan\nPitt, executive director of the Open Networking Foundation. \"This\ncompetition is designed to encourage additional SDN innovation by seeking\nadditional open-sourced technology solutions. We want this OpenFlow Driver\nto be of use for global developers of OpenFlow products, making it easier\nfor them to build value around and easily update the OpenFlow protocol\ncomponent with the latest ONF specifications as they evolve.\"\n\n \n\nThe competition is open to all organizations and individuals worldwide\ninterested in developing an OpenFlow driver that any developer can use in a\ncontroller or switch to maintain compatibility among switches and\ncontrollers. The contest will open for submissions on April 16, 2013 at\n12:00 a.m. Pacific Daylight Time, and will close on August 15, 2013 at 11:59\np.m. PDT. Judges, who will be selected by the Foundation, will critique on\nthe following:\n\n \n\n*         Compliance with the OpenFlow specification standard\n\n*         Correctness of operation with test harness\n\n*         Ease with which the submission can be integrated into a controller\n\n*         Completeness of the implementation\n\n*         Clarity of the code and architecture\n\n*         Memory footprint\n\n*         Potential performance and scaling of the architecture\n\n*         Portability of the code\n\n*         Modularity of the code\n\n*         Extensibility and maintainability of the code\n\n*         Integration with multiple programming languages\n\n*         Performance and scalability of the code\n\n \n\nThe winner will be announced on September 30, 2013. The winning entry will\nbe provided under both Apache 2.0 and GPL dual-licenses for maximum\ncompatibility with both open-source projects and commercial ones. For more\ninformation about the open-source \"OpenFlow Driver\" competition and\nsubmission guidelines, please visit www.opennetworking.org/competition\n<http://www.opennetworking.org/competition> . Competition terms and rules\ncan be found at:\nwww.opennetworking.org/images/stories/downloads/misc/openflow-driver-competi\ntion-terms-conditions.pdf\n<http://www.opennetworking.org/images/stories/downloads/misc/openflow-driver\n-competition-terms-conditions.pdf> . \n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130516/d3ec48db/attachment.html>\n\n',NULL,NULL),('<034c01cdb01e$8e0a4e80$aa1eeb80$@renski.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-21 23:28:42',-25200,'2012-10-22 06:28:42',NULL,'[OpenStack Foundation] Call for volunteers:\n	cloudcomputingexpo.com , Santa Clara Convention Center','Stefano, we are local and would be glad to help. \n\n-Boris \n\n-----Original Message-----\nFrom: Stefano Maffulli [mailto:stefano at openstack.org] \nSent: Friday, October 19, 2012 12:14 PM\nTo: foundation at lists.openstack.org; kathyc at openstack.org\nSubject: [OpenStack Foundation] Call for volunteers: cloudcomputingexpo.com\n, Santa Clara Convention Center\n\nHello folks,\n\nthe OpenStack Foundation will have a booth at cloudcomputingexpo.com Santa\nClara Convention Center.\n\nThis is a great opportunity to show off your membership to the OpenStack\nFoundation and demonstrate how OpenStack is shaping the future of computing.\n\nWe\'re looking for (local) volunteers to organise the presence at Cloud\nComputing Expo, setup a demo and be at the booth to answer questions about\nOpenStack and the Foundation. We will provide collaterals and equipment.\nYou\'ll need to show up and be available at the booth.\n\nDemo needs\n----------\n\n    * 1-2 people with laptop(s) running live OpenStack code and dashboard.\n    * Great communications skills, to talk to business users, developers and\npotential new ecosystem partners\n    * Technical knowledge to setup and run the software, answer any level of\nquestion, show each visitor what they want to see and how to get started\nwith OpenStack.\n\nWhen\n----\n\nDemo setup\n   * Mon Nov 5 8:00am-4:30pm\n\nExpo Hall open\n\n    * Mon Nov 5, 6:30-8pm (welcome reception)\n    * Tues Nov 6 and Wed Nov 7, 10-12:30, 3-6\n    * Thurs Nov 8, 10-12, 2:30-5\n\nIf interested, please reply to Kathy Cacciatore, in cc. She will be the\ncontact point for this activity.\n\nThank you very much,\nStefano\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n','<5081A67C.4070100@openstack.org>',NULL),('<0350DC55A7B4224EBFD3ADD31C2D43FC12F673BA@xmb-aln-x08.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-18 18:12:23',0,'2014-11-18 18:12:23',NULL,'[openstack-dev] [neutron][stable] Review request','Neutron cores:\n\nI submitted a bug fix a bit over a month ago which is waiting for one\nmore core (+2) review.  The changes are rather simple which affects\nthe ovs/ofa code.  Could a core person take the time to review?\n\nHere are the pointers to the changes:\nhttps://review.openstack.org/127654\n\nhttps://bugs.launchpad.net/neutron/+bug/1367697\n\nCarol\n[http://wwwin.cisco.com/marketing/corporate/brand/intelbrand/brandstrat/signature/none]\n\nCarol Bouchard\nTECHNICAL LEADER.ENGINEERING\n\ncaboucha at cisco.com<mailto:caboucha at cisco.com>\nWebEx Social profile<http://iwe.cisco.com/web/caboucha>\nPhone: +1 978 936 2124\n\n\nCisco.com<http://www.cisco.com>\n\n\n\n[Description: Think before you print.]Think before you print.\n\nThis email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.\nFor corporate legal information go to:\nhttp://www.cisco.com/web/about/doing_business/legal/cri/index.html\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/02d360c8/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.png\nType: image/png\nSize: 191 bytes\nDesc: image003.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/02d360c8/attachment-0002.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.png\nType: image/png\nSize: 901 bytes\nDesc: image004.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/02d360c8/attachment-0003.png>\n\n',NULL,NULL),('<035187EA-1C5D-470E-9852-755D5D787693@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-03 20:30:01',-18000,'2014-04-04 01:30:01',NULL,'[Openstack] [Glance,\n	Horizon&Neutron] Question About Uploading AMI Image And Router\n	Between Nets','Hi Stackers,\nI have some questions about Glance, Horizon and Neutron.\n1. When using Horizon to upload the image, how to specify the kernel and ramdisk image for a AMI image? No options are found in Horizon to specify these properties.\ni know we can using ?property to do it when using CLI, but how to do from Horizon?\nI use the default configuration for Horizon. Do I need to change the configuration for Horizon to support AMI?\n\n2. Is there any possible to communicate between two nets?\nWe create two nets under the same tenant and a router that connects these two.\nBut we cannot ping from one net to another net.\n\nI would appreciate any feedback.\n\nThanks,\nLichao Yin\n\n',NULL,NULL),('<03562FF4-F551-41F0-97C1-2E7C900E58E6@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 16:34:13',0,'2013-11-14 16:34:13',NULL,'[openstack-dev] [Neutron] Port mirroring','On Nov 14, 2013, at 8:46 AM, Rossella Sblendido <rossella at midokura.com> wrote:\n> \n> Hello devs,\n> \n> I\'d like to start working at this blueprint:\n> \n> https://blueprints.launchpad.net/neutron/+spec/port-mirroring\n> \n> I didn\'t receive much feedback so please have a look at it.\n> \n> It was not approved yet. What\'s the usual workflow? Shall I wait for approval before I start implementing it? Sorry for the trivial question but I\'m new here.\n> \nWelcome Rossella!\n\nOne issue I have with the design document linked in the blueprint is the testing section has nothing in it all. Given we\'re trying hard to focus on quality and testing, I\'d like you to add some specific testing information to the document before we approve it. It would be ideal to have Tempest tests which test out the new API functionality as well. That\'s my main issue with this BP as seen now, but I\'d like others to comment on this as well.\n\nThanks!\nKyle\n\n> thanks,\n> \n> Rossella\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAOSL_f-ZhJruGBDtxNKS8twqwRDE905KFiY2wDVF3MOfDHDbXw@mail.gmail.com>',NULL),('<036383EFF1315C40A7A1F24FDE699843078E08A7@usnc-mbx-p4.corp.extremenetworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 18:44:31',0,'2014-04-16 18:44:31',NULL,'[openstack-dev] Running neutron in child cells','Hello,\n\nI am trying to figure out if an instance of neutron can be run on the controllers of each child cell and if neutron commands sent to the master node would then be routed to the child cell similar to how the nova commands get routed. I have searched online and as well as in the documentation and I have not found any good resource on this.\n\nHas this been done? What is the current OpenStack model to scale networks in Havana and IceHouse?\n\nThanks,\n\nRamkumar\n\n________________________________\n\nDISCLAIMER:\nThis e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140416/9d54a03e/attachment.html>\n\n',NULL,NULL),('<036383EFF1315C40A7A1F24FDE699843100716@usnc-mbx-p4.corp.extremenetworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 20:17:51',0,'2014-04-01 20:17:51',NULL,'[openstack-dev] why does Opendaylight mechanism driver only support\n	local/vxlan/gre?','Hi,\n\nI am looking at the ODL mechanism driver implemented in IceHouse and it seems that this driver only supports networks of type local/vxlan/gre. Is there a reason that VLAN and flat were explicitly excluded?\n\nThanks,\n\nRamkumar\n\n________________________________\n\nDISCLAIMER:\nThis e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/c3c5213a/attachment.html>\n\n',NULL,NULL),('<03687721-10A8-47E5-8076-795F6567B0B2@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 02:14:12',0,'2013-03-06 02:14:12',NULL,'[openstack-dev] keystone: running a single test','...hmm, I think something\'s got busted...I just merged up to master and now I am having the same problem that running the test files individually is problematic....investigating...\n\nHenry\nOn 6 Mar 2013, at 01:18, Bhandaru, Malini K wrote:\n\n> Thanks Adam and Henry.\n>  \n> Failure:  ?ImportError (No module name test_v3)\n>  \n> And actually it also touches on yet another model test_content_types.py\n>  \n>  \n>  \n>  \n> From: Adam Young [mailto:ayoung at redhat.com] \n> Sent: Tuesday, March 05, 2013 4:59 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] keystone: running a single test\n>  \n> On 03/05/2013 06:56 PM, Bhandaru, Malini K wrote:\n> Hello Keystone Developers!\n>  \n> How might I run  a single test .. for focused debugging of a failure. Happy if I could just even run only the tests in test_v3_auth.py.\n>  \n> Example test_v3_auth.py test_auth_with_id (tests.test_v3_auth.TestAuthXML)\n>  \n>  \n> Thanks\n> Malini\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> The general pattern is package.subpackage:Class.function so \n> \n> \n> ./run_test.sh test_v3_auth:TestAuthXML.test_auth_with_id\n> \n> \n> (there is no package name  test)\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130306/81175b3d/attachment.html>\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E52094BC1@FMSMSX105.amr.corp.intel.com>',NULL),('<036FA1BC4A80D448AB7D9C3AAFBBCAF59F87769A@AVMB1.qlogic.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 02:42:25',0,'2015-01-22 02:42:25',NULL,'[openstack-dev] ML2 port binding?','Hello,\nI?m a newbie here. Can someone please explain to me as to what exactly is\ninvolved in ?port_binding? in ML2 mechanism driver and any specific\npointers? Is it just an association with its corresponding L2 agent? What\nis mechanism driver expected to return back to port_bind?\n\nThanks\n\nHarish\n\n\n\n\n________________________________\n\nThis message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.\n\n',NULL,NULL),('<036FA1BC4A80D448AB7D9C3AAFBBCAF59F877FE0@AVMB1.qlogic.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 07:31:15',0,'2015-01-23 07:31:15',NULL,'[openstack-dev] ML2 port binding?','>\n\n>Hi Harish,\n>\n>Port binding in ML2 is the process by which a mechanism driver (or once\n>https://blueprints.launchpad.net/openstack/?searchtext=ml2-hierarchical-po\n>rt-binding\n>is merged, potentially a set of mechanism drivers) is selected for the\n>port, determining how connectivity is provided for that port. Since ML2\n>is designed to support heterogeneous deployments, its possible for\n>different ports to be bound using different mechanism drivers.\n>\n>The end results of port binding visible outside ML2 are the values of\n>the binding:vif_type and binding:vif_details port attributes that\n>control the Nova VIF driver behavior.  The inputs to the port binding\n>process are the port and the network to which the port belongs,\n>including the network\'s set of segments, as well as the values of the\n>binding:host_id, binding:vnic_type, and binding:profile port attributes.\n>Nova (or any L3, DHCP, or service agent owning the port) sets\n>binding:host_id to indicate the host on which the port is being bound.\n>The setting of this attribute triggers the port binding process.\n>\n>During port binding, the bind_port() method is called by ML2 on each\n>registered mechanism driver until one driver indicates it has succeeded\n>by calling PortContext.set_binding(). The driver calls\n>PortContext.set_binding()  with the identity of the network segment it\n>bound, and the values for the binding:vif_type and binding:vif_details\n>attributes. Typical mechanism drivers for L2 agents decide whether they\n>can bind the port by looking through the list of network segment for one\n>with a network_type value that the agent on the host identified by\n>binding:host_id can handle, and if relevant, a physical_network value\n>for which that agent has connectivity. The current L2 agent mechanism\n>drivers use agents_db info sent from the agents to the service via RPC,\n>including the agent\'s health and the bridge_mappings or\n>interface_mappings value that describes its connectivity to\n>physical_networks.\n>\n>The doc strings in neutron.plugins.ml2.driver_api provide more detail on\n>port binding and the classes and methods involved.\n>\n>Hope this helps,\n\nSure it does, thanks very much Bob.\n\n>\n>-Bob\n>\n>On 1/21/15 9:42 PM, Harish Patil wrote:\n>> Hello,\n>> I?m a newbie here. Can someone please explain to me as to what exactly\n>>is\n>> involved in ?port_binding? in ML2 mechanism driver and any specific\n>> pointers? Is it just an association with its corresponding L2 agent?\n>>What\n>> is mechanism driver expected to return back to port_bind?\n>>\n>> Thanks\n>>\n>> Harish\n>>\n>>\n>>\n>>\n>> ________________________________\n>>\n>> This message and any attached documents contain information from the\n>>sending company or its parent company(s), subsidiaries, divisions or\n>>branch offices that may be confidential. If you are not the intended\n>>recipient, you may not read, copy, distribute, or use this information.\n>>If you have received this transmission in error, please notify the\n>>sender immediately by reply e-mail and then delete this message.\n>>\n>>_________________________________________________________________________\n>>_\n>> OpenStack Development Mailing List (not for usage questions)\n>> Unsubscribe:\n>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>__________________________________________________________________________\n>OpenStack Development Mailing List (not for usage questions)\n>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n________________________________\n\nThis message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.\n\n','<54C06C20.5010500@noironetworks.com>',NULL),('<037723FB-F799-4A65-8FF2-012F9A7485C8@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 23:12:27',14400,'2013-06-06 19:12:27',NULL,'[openstack-dev] [Savanna] Savanna meeting minutes','Thanks everyone who have joined today\'s Savanna meeting.\n\nHere are the logs from today\'s meeting:\n\nMinutes: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-06-06-18.06.html\nMinutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-06-06-18.06.txt\nLog: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-06-06-18.06.log.html\n\nSincerely yours,\nSergey Lukjanov\n\n\n\n',NULL,NULL),('<037FB33A-5692-45C3-8907-C1D83C280230@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-20 10:54:54',-14400,'2013-05-20 14:54:54',NULL,'[openstack-dev] A few questions on using COE puppet/cobbler...','Update inline @PCM\n\nOn May 20, 2013, at 10:43 AM, Paul Michali wrote:\n\n> Hi!\n> \n> We\'re trying to setup multiple build servers (in VMs) in the lab, so that we can automatically provision different types of hardware (have HP Pro Liant, Eclipse, and now UCS boxes). With the current setup we have an operational build server that provisions the HP Pro Liants with either COE or Devstack. Works well.  Here are the questions, related to the second build server VM that we are setting up (and later will do a third for the Eclipse boxes):\n> \n> With this build server, I ran puppet apply and am getting this error:\n> \n> err: /Stage[main]//Node[master-node]/Exec[pip-cache]/returns: change from notrun to 0 failed: /usr/bin/env http_proxy=http://proxy-wsa.esl.cisco.com:80 https_proxy=http://proxy-wsa.esl.cisco.com:80 /usr/local/bin/pip2pi /var/www/packages collectd xenapi django-tagging graphite-web carbon whisper returned 1 instead of one of [0] at /etc/puppet/manifests/core.pp:421\n> \n> It appears to be a proxy issue, but I\'m not sure what is wrong as this build server has the same thing as the other (working build server).  The site.pp has:\n> \n> $proxy                  = \"http://proxy-wsa.esl.cisco.com:80\"\n> $location               = \"http://128.107.252.163/openstack/cisco\"\n> \n> The /etc/apt/sources.list.d/cisco-openstack-mirror_folsom has:\n> \n> # cisco-openstack-mirror_folsom\n> deb http://128.107.252.163/openstack/cisco folsom main\n> deb-src http://128.107.252.163/openstack/cisco folsom main\n> \n> This command fails with a timeout, when run manually as well.\n> \n> Q: Any idea as to what I\'m doing wrong on the proxy setup here?\n\n@PCM I tried manually installing again, only skipping collectd and the other packages all installed. Any idea why collectd is not installing (and how to install it - or can I ignore it)?\n\nPCM\n\n\n> \n> \n> The second question relates to idea that we want both of these build server VMs running at the same time. The build servers are on the 192.168.220.0/24 network. The UCS boxes will have power management IPs on 13.0.0.0/16 and management IP will be on 14.0.0.0/16 network, using host part of .30 to .39 for the ten systems.\n> \n> Currently, the HP boxes power and management ports are on the 192.168.220.0 network, but the intent is to move these to the 13.0.0.0 and 14.0.0.0 networks as well using host IP parts (.10 to .19). In the future, we\'ll alter the Exclipe boxes too, to use .20 to .29 in these same IP ranges (only we\'ll need to use a managed APS for these).\n> \n> We\'ve statically set the IPs for the power management ports and will rely on the MAC addresses to assign the IPs via cobbler/puppet.\n> \n> Q: Will we run into an issue with the IP addresses for the management interfaces given we\'ll have two build servers, each with DHCP servers handling the PXE boots?\n> \n> Q: Should we create subnets and partition up the space?\n> \n> Q: Any other issues that you see with this plan?\n> \n> \n> Thanks in advance!\n> \n> \n> PCM (Paul Michali)\n> \n> Contact info for Cisco users http://twiki.cisco.com/Main/pcm\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/db8f49c5/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/db8f49c5/attachment.pgp>\n\n','<3B543B45-A551-4A57-A1D6-94004E4D60EA@cisco.com>',NULL),('<038D0A51-F4D4-4822-8B62-85BE1DD33071@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 09:57:41',7200,'2013-08-20 07:57:41',NULL,'[Openstack] SSH permissions (was: Re: Error during live\n	migration)','It\'s getting weird really?\nnow can you run a live migration from the command line?\n\nLe 20 ao?t 2013 ? 00:20, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n\n> Yes:\n> \n> nova-manage service list\n> Binary           Host                                 Zone             Status     State Updated_At\n> nova-cert        hemera                               internal         enabled    :-)   2013-08-19 22:20:14\n> nova-scheduler   hemera                               internal         enabled    :-)   2013-08-19 22:20:14\n> nova-consoleauth hemera                               internal         enabled    :-)   2013-08-19 22:20:17\n> nova-conductor   hemera                               internal         enabled    :-)   2013-08-19 22:20:14\n> nova-compute     caos                                 nova             enabled    :-)   2013-08-19 22:20:17\n> nova-compute     tiresias                             nova             enabled    :-)   2013-08-19 22:20:17\n> \n> \n> \n> 2013/8/19 Razique Mahroua <razique.mahroua at gmail.com>\n> Can you run nova-manage service list ?\n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 19 ao?t 2013 ? 22:27, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n> \n>> Hello again Razique, I was trying to migrate through the terminal and I\'m getting this line from my controller node:\n>> \n>> nova live-migration f18b6d2b-f685-4476-a7c0-e735db5113cf 192.168.3.3\n>> ERROR: Compute service of 192.168.3.3 is unavailable at this time. (HTTP 400) (Request-ID: req-454960fb-6652-46ed-9080-6d23b384cbb3)\n>> \n>> Haven\'t found anything yet. Any ideas?\n>> \n>> Regards.\n>> \n>> Guilherme.\n>> \n>> \n>> 2013/8/19 Guilherme Russi <luisguilherme.cr at gmail.com>\n>> I\'m migrating it through the dashboard with the admin user. Is it wrong?\n>> \n>> Thank you.\n>> \n>> Guilherme.\n>> \n>> \n>> 2013/8/19 Razique Mahroua <razique.mahroua at gmail.com>\n>> quick question, how do you migrate the instance ? and does it belong to the tenant?\n>> \n>> \n>> Le 19 ao?t 2013 ? 15:36, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>> \n>>> The VM looks to be there:\n>>> \n>>> du -h instances/\n>>> 4,0K	instances/keys\n>>> 1,9G	instances/_base\n>>> 0	instances/locks\n>>> 310M	instances/edca1460-9c97-475e-997b-3266b235e797\n>>> 260M	instances/0fe59b28-04a3-41bb-9926-b7d139a70548\n>>> 323M	instances/aeda1c56-72ba-40a7-9857-01a622540505\n>>> 7,0M	instances/f4af662d-ae55-4346-82cf-a997192706b5\n>>> 264M	instances/483f98e3-8ef5-43e2-8c3a-def55abdabcd\n>>> 268M	instances/eeb81e32-32ce-49fa-8249-afc572f26233\n>>> 268M	instances/c0224f0d-d7e8-4621-8c1a-af68740a3267\n>>> 188M	instances/72ec37a3-b209-4729-b628-005fdcea5a3c\n>>> 12M	instances/2c7c123b-456a-4c70-a991-80efee541324\n>>> 11M	instances/c9e1c5ed-a108-4196-bfbc-24495e2e71bd\n>>> 6,5M	instances/96d8f2de-a72d-40b5-b083-1f5e511f91ce\n>>> 531M	instances/1b35a4a6-e158-48d3-a804-44b05ec171d0\n>>> 529M	instances/1a2b6146-6ef0-4d76-a603-e4715b4dfb62\n>>> 514M	instances/f6cb9f81-9281-419f-9e20-adaa6a07cea3\n>>> 2,7G	instances/75e479cf-37a4-4511-b2a5-d4f3027702d4_resize\n>>> 2,4G	instances/75e479cf-37a4-4511-b2a5-d4f3027702d4\n>>> 11G	instances/\n>>> \n>>> \n>>> It\'s still running, no Error messagem from dashboard (it is showing Status: Resize/Migrate - Task: Resizing or Migrating - Power State: Running). The logs are not showing that permission error anymore. Should I wait to see if it will migrate or returns another error status? One thing is true, the machine is really slow now :P\n>>> \n>>> Regards.\n>>> \n>>> Guilherme.\n>>> \n>>> \n>>> 2013/8/19 Razique Mahroua <razique.mahroua at gmail.com>\n>>> Looks like the file doesn\'t exist.\n>>> Can you spawn a new instance and try to migrate it again?\n>>> thanks\n>>> \n>>> Razique Mahroua - Nuage & Co\n>>> razique.mahroua at gmail.com\n>>> Tel : +33 9 72 37 94 15\n>>> \n>>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>>> \n>>> Le 19 ao?t 2013 ? 13:41, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>>> \n>>>> Hello Peter,\n>>>> \n>>>>  Thank you for your help too :)\n>>>>  I\'ve changed the permission and now I\'m getting another error when I try to migrate:\n>>>> \n>>>> cat /var/log/nova/nova-compute.log | grep -E ERROR\n>>>> 2013-08-19 08:17:19.990 12667 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: Unexpected error while running command.\n>>>> 2013-08-19 08:23:40.309 12667 ERROR nova.network.quantumv2 [-] _get_auth_token() failed\n>>>> 2013-08-19 08:24:27.013 12667 ERROR nova.virt.libvirt.driver [-] Getting disk size of instance-000000bc: [Errno 2] No such file or directory: \'/var/lib/nova/instances/75e479cf-37a4-4511-b2a5-d4f3027702d4/disk\'\n>>>> \n>>>> \n>>>> cat /var/log/nova/nova-compute.log | grep -E TRACE\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Traceback (most recent call last):\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/manager.py\", line 241, in periodic_tasks\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     task(self, context)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 4020, in _run_image_cache_manager_pass\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self.driver.manage_image_cache(context, filtered_instances)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3401, in manage_image_cache\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self.image_cache_manager.verify_base_images(context, all_instances)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagecache.py\", line 588, in verify_base_images\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self._handle_base_image(img, base_file)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagecache.py\", line 553, in _handle_base_image\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     virtutils.chown(base_file, os.getuid())\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py\", line 449, in chown\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     execute(\'chown\', owner, path, run_as_root=True)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py\", line 47, in execute\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     return utils.execute(*args, **kwargs)\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     cmd=\' \'.join(cmd))\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager ProcessExecutionError: Unexpected error while running command.\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Command: sudo nova-rootwrap /etc/nova/rootwrap.conf chown 123 /var/lib/nova/instances/_base/b0d90eb60f048f6de16c3efbc0eb4c16cbac77a6\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Exit code: 1\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Stdout: \'\'\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Stderr: \'Traceback (most recent call last):\\n  File \"/usr/bin/nova-rootwrap\", line 108, in <module>\\n    os.getlogin(), pwd.getpwuid(os.getuid())[0],\\nOSError: [Errno 22] Invalid argument\\n\'\n>>>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager \n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2 Traceback (most recent call last):\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2   File \"/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py\", line 40, in _get_auth_token\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2     httpclient.authenticate()\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2   File \"/usr/lib/python2.7/dist-packages/quantumclient/client.py\", line 198, in authenticate\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2     raise exceptions.Unauthorized(message=body)\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2 Unauthorized: Request Timeout\n>>>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2\n>>>> \n>>>> Any ideas?\n>>>> \n>>>> Regards.\n>>>> \n>>>> Guilherme.\n>>>> \n>>>> \n>>>> 2013/8/19 Peter Funk <pf at artcom-gmbh.de>\n>>>> Guilherme Russi wrote 16.08.2013 um 09:53:\n>>>> >  Here is my directory configs:\n>>>> >\n>>>> > drwxrwxrwx  2 nova nova     76 Ago 15 14:54 .ssh\n>>>> >\n>>>> > I made chmod a+xwr at the folder at all computers, I made it because I\n>>>> > couldn\'t find the reason I was no allowed to migrate, can it be like that?\n>>>> \n>>>> For SSH to work the permissions of $HOME/.ssh should look like this:\n>>>>   drwx------  2 nova nova     76 Ago 15 14:54 .ssh\n>>>> \n>>>> Use:\n>>>>   chmod -R go-rwx .ssh\n>>>> \n>>>> Regards, Peter Funk\n>>>> --\n>>>> Peter Funk, home: ?Oldenburger Str.86, D-27777 Ganderkesee\n>>>> mobile:+49-179-640-8878 phone:+49-421-20419-0 <http://www.artcom-gmbh.de/>\n>>>> office: ArtCom GmbH, ?Haferwende 2, D-28357 Bremen, Germany\n>>>> \n>>>> _______________________________________________\n>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> \n>>>> _______________________________________________\n>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> \n>>> \n>> \n>> \n>> \n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/233b2cbb/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 535 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/233b2cbb/attachment.pgp>\n\n','<CAKz5Ux8g=tXwDdpU=A75gAk8P499KXte6s8dbrnuk_U5Rd2peA@mail.gmail.com>',NULL),('<03974E7E-4E13-4804-A0D3-DCBDE53966D3@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-05 16:25:55',0,'2014-11-05 16:25:55',NULL,'[openstack-dev] [Barbican] Nominating Steve Heyman for\n barbican-core','+1 for me as well.\n\nFrom: Douglas Mendizabal <douglas.mendizabal at RACKSPACE.COM<mailto:douglas.mendizabal at RACKSPACE.COM>>\nReply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Wednesday, November 5, 2014 at 4:29 PM\nTo: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core\n\n+1\n--------------------\nDouglas Mendiz?bal\nIRC: redrobot\nPGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C\n\nFrom: Chad Lung <chad.lung at gmail.com<mailto:chad.lung at gmail.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Wednesday, November 5, 2014 at 4:17 PM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: [openstack-dev] [Barbican] Nominating Steve Heyman for barbican-core\n\nGreetings ,\n\nI would like to nominate Steve Heyman for the barbican-core team.\n\nSteve is very active in Barbican code reviews and has been a regular contributor of test related change requests as well as documentation.\n\nAs a reminder to barbican-core members, we use the voting process outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add members to our team.\n\nThanks,\n\nChad Lung\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141105/699f70a0/attachment.html>\n\n','<D0800096.369F2%douglas.mendizabal@rackspace.com>',NULL),('<03992F28-CF7D-4AB7-AF33-8350126F5094@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-09 21:17:29',0,'2015-01-09 21:17:29',NULL,'[openstack-dev] [api] API Definition Formats','One thing that has come up in the past couple of API WG meetings [1] is just how useful a proper API definition would be for the OpenStack projects.\n\nBy API definition I mean a format like Swagger, RAML, API Blueprint, etc. These formats are a machine/human readable way of describing your API. Ideally they drive the implementation of both the service and the client, rather than treating the format like documentation where it?s produced as a by product of the implementation.\n\nI think this blog post [2] does an excellent job of summarizing the role of API definition formats.\n\nSome of the other benefits include validation of requests/responses, easier review of API design/changes, more consideration given to client design, generating some portion of your client code, generating documentation, mock testing, etc. \n\nIf you have experience with an API definition format, how has it benefitted your prior projects?\n\nDo you think it would benefit your current OpenStack project?\n\nThanks,\nEverett\n\n[1] https://wiki.openstack.org/wiki/Meetings/API-WG\n[2] http://apievangelist.com/2014/12/21/making-sure-the-most-important-layers-of-api-space-stay-open/\n\n\n\n',NULL,NULL),('<039AD53E-FD1B-44C9-8926-18BA8E5C7B30@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-23 16:47:39',0,'2012-10-23 16:47:39',NULL,'[openstack-dev] [Openstack] Fwd: [keystone] Tokens representing\n authorization to projects/tenants in the Keystone V3 API','I\'m okay with \"Starting Tokens\".\n\n-jOrGe W.\n\nOn Oct 23, 2012, at 7:25 AM, Adam Young wrote:\n\nOn 10/23/2012 01:25 AM, Jorge Williams wrote:\nHere\'s my view:\n\nOn making the default token a configuration option:  Like the idea.  Disabling the option by default.  That\'s fine too.\n\nOn scoping a token to a specific endpoint:  That\'s fine, though I believe that that\'s in the API today.  Currently, the way that we scope tokens to endpoints is by validating against the service catalog. I\'m not sure if the default middleware checks for this yet, but the Repose middleware does.  If you try to use a token in an endpoint that\'s not in the service catalog the request fails -- well, if the check is turned on.\n\nObviously, I\'d like the idea of scoping a single token to multiple tenants / endpoints.\n\nI don\'t like the idea of calling tokens \"sloppy tokens\" -- it\'s confusing.   All you have to say is that a token has a scope -- and the scope of the token is the set of resources that the token can provide access to.  You can limit the scope of a token to a tenant, to a endpoint, to a set of endpoints or tenants etc -- what limits you place on the scope of an individual token should be up to the operator.\n\nKeep in mind that as we start digging into delegation and fine grained authorization (after Grizzly, I\'m sure), we\'ll end up with tokens that have a scope of a subset of resources in a single or multiple tenants.  So calling them sloppy now is just confusing.  Simply stating that a token has a scope (as I\'ve defined above) should suffice.  This is part of the reason why I\'ve never liked the term \"unscoped\" token, because an unscoped token does have a scope. It just so happens that the scope of that token is the resource that provides a list of available tenants.\nThis is a pretty good distinction.  What we were calling \"Unscoped\" is, to me, the equivalent of a TGT in Kerberos:  a starting point, that has not been specified to any resources.  I\'d be willing to entertain a different name than \"Unscoped.\"  Let me throw out \"Starting Tokens\" as a straw man, and we can beat it up to come up with a better term.\n\n\"Sloppy\" was never meant seriously, but more a way to tweak the noses of the project members named \"Joe.\"\n\n\n\n-jOrGe W.\n\nOn Oct 22, 2012, at 9:57 PM, Adam Young wrote:\n\nAre you guys +1 ing the original Idea, my suggestion to make it optional, the fact that I think we should call these sloppy tokens?\n\nOn 10/22/2012 03:40 PM, Jorge Williams wrote:\n+1 here too.\n\nAt the end of the day, we\'d like the identity API to be flexible enough to allow the token to be scoped in a manner that the deployer sees fit.  What the keystone implementation does by default is a different matter -- and disabling multiple tenant  scope by default would be fine by me.\n\n-jOrGe W.\n\n\nOn Oct 21, 2012, at 11:10 AM, Joe Savak wrote:\n\n+1. ;)\n\nSo the issue is that the v2 API contract allows a token to be scoped to multiple tenants. For v3, I\'d like to have the same flexibility. I don\'t see security issues, as if a token were to be sniffed you can change the password of the account using it and use those creds to scope tokens to any tenant you wish.\nScope should always be kept as limited as possible. Personally, I don\'t feel like limiting the tenant list makes much difference.  THe more I think about it, the real benefit comes from limiting the  endpoints.\n\n\n\n\n\nOn Oct 20, 2012, at 21:07, \"Adam Young\" <ayoung at redhat.com<mailto:ayoung at redhat.com>> wrote:\n\nOn 10/20/2012 01:50 PM, heckj wrote:\nI sent this to the openstack-dev list, and thought I\'d double post this onto the openstack list at Launchpad for additional feedback.\n\n-joe\n\nBegin forwarded message:\nFrom: heckj <heckj at mac.com<mailto:heckj at mac.com>>\nSubject: [openstack-dev] [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API\nDate: October 19, 2012 1:51:16 PM PDT\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n\nThe topic of what a token can or can\'t represent for the upcoming V3 Keystone API  came up - and I wanted to share the conversation a bit more broadly to get feedback.\n\n\nA bit of history:\n\nIn the V2 API, when you authenticated with just a username and password, the token that was provided wasn\'t entirely clearly defined. The reference implementation that Keystone used was to create what\'s been called an \'unscoped\' token - which was generally limited to only being able to get a list of possible tenants/projects and the capability of getting a token specific to a user & tenant/project (what\'s been called a \"scoped\" token)\n\nLikewise, the reference implementation of the rest of the OpenStack projects all require a tenant information to be included within the token as that token was the identity refernce inforoamtion - and most OpenStack services were wanting to know the tenant associated with the token for authorization/ownership purposes.\n\nApparently Rackspace\'s internal implementation provided a token that was immediately valid for all possible tenants to which the user was associated, and presumably their internal implementations of openstack do whatever work is appropriate to discern and provide that information to the various openstack services.\n\nThe quandary:\n\nIn the V3 API, we started off with, and currently define the token as being specifically mandated to a single tenant, with a new requirement that if you authorize with just a username and password, a \"default tenant\" is used. If for some reason you have no tenant associated with the userid, the authorization is to be refused. If the user is associated with more than one tenant/project, it\'s possible to use the token to get a list of other tenants/projects and request a new token specific to one of those other tenant/projects, but the implementation is expected to respect and provide a default.\n\nI would like to make \"default tenant\" a configuration option, and have it disabled by default.  Unscoped tokens are a very useful construct.  In the case where the user has many roles across a multitude of projects, it is possible to create huge tokens.  I would prefer unscoped tokens to remain, and to be associated with no tenant.  The only operation Keystone should provide with them is the ability to enumerate tenants, so something like Horizon can then request an appropriately scoped token.\n\nI am also in favor of limiting the scope of a token to an endpoint.  Even more-so than tenants, scoping a token to an end point increases security.  Once a token has been scoped to an endpoint, it can only be used on that endpoint.  If an endpoint gets compromised, the damage is limited to resources that endpoint already has access to.  This, in conjunction with pre-auths, could allow a user to perform an action with a minimum of risk in a public cloud environment.\n\n\n\nA few folks from Rackspace touched on this at the very tail end of the V3 API review session on Thursday, bringing up that they had an issue with the token being scoped to a single tenant. Since this has significant implications to both security and a potential user experience flow, I wanted to bring the issue up across the broader community for discussion.\n\nThe request outstanding:\n\nRackspace folks are requesting that the token not be limited to a single tenant/project, but instead provides a list of potential tenants against which the token should be considered valid.\nI would like the world to know that we are affectionately calling such tokens \"sloppy tokens\" and Joe Savak has adopted the nickname of \"Sloppy Joe\" for championing them.  Allowing it as an option is fine, but I would not recommend that this become the norm, or that we enable this feature by default.\n\nBrief (maybe shoddy) analysis:\n\nThis would potentially imply changes to what gets passed as a part of the authentication reference in the context passed using auth_token middleware - multiple tenants possible instead of the currently expected single value - so using that as information for create() style mechanisms would need to provide some alternative means of clearly defining what tenant/project should be owner. It  would provide anyone compromising that particular token with a broader spectrum of impact on a replay style attack. Likewise, the impact of tenant enable/disable or role changes would necessarily mean a broader invalidation of all tokens associated with the user.\n\nOn the flip side, it has the potential to remove the token-reissuance that currently exists when switching contexts from one project to another (primarily through horizon or other client/UI/dashboard mechanisms that cache the token).\n\nFeedback and Input desired!\n\n-joe\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nMailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nPost to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>\nUnsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nMore help   : https://help.launchpad.net/ListHelp\n\n\n_______________________________________________\nMailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nPost to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>\nUnsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nMore help   : https://help.launchpad.net/ListHelp\n_______________________________________________\nMailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nPost to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>\nUnsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>\nMore help   : https://help.launchpad.net/ListHelp\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121023/3b47bba0/attachment-0001.html>\n\n','<50868CCF.7020605@redhat.com>',NULL),('<039b01ccf1d1$70a3e5b0$51ebb110$@renski.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-22 18:18:30',-28800,'2012-02-23 02:18:30',NULL,'[OpenStack Foundation] Technical committee','Thierry, \n\nGood job overall. I agree with 9 members and abandoning auto appointment of\nPTLs. \n\nI am a little fuzzy on the revocation clause and subsequently convoluted\nsystem for electing a prospective substitute. Seems like a lot of\ncomplication is injected with this clause with little meaningful outcome. Do\nwe know that non-participation in the meetings is likely to be such a\nrecurring issue (has it been in the past)?\n\nI assume that 95% of the time substitute will not end up having to\nsubstitute. Hence, are there any actionable responsibilities that this\nsubstitute will have while he/she remains in inactive substitute role and\nwhat is the chance that the substitute himself has become a non-viable\nreplacement candidate by the time he/she ends up having to substitute? \n\nPerhaps, it would make sense to simplify and do away with the substitute and\nrevocation deal altogether? Everyone on the committee is getting\nreconsidered every 6 to 12 months already; I think that is a powerful enough\nmechanism to keep everyone motivated and ivolved as is. The idea is to start\nwith the simplest and most efficient structure. We can always make it more\ncomplicated later. \n\n-Boris  \n\n\n\n-----Original Message-----\nFrom: foundation-bounces at lists.openstack.org\n[mailto:foundation-bounces at lists.openstack.org] On Behalf Of Thierry Carrez\nSent: Monday, February 20, 2012 8:46 AM\nTo: foundation at lists.openstack.org\nSubject: [OpenStack Foundation] Technical committee\n\nHi everyone,\n\nThe current structure document is quite open on the Technical committee\norganization. Here are my proposals to keep it efficient... Please comment.\n\n\n= Technical committee =\n\n== Mission ==\n\nThe Technical Committee (TC) is tasked with providing the technical\nleadership for the OpenStack project. It enforces OpenStack core projects\nideals (Openness, Transparency, Commonality, Integration, Respect of release\ndeadlines, Facilitation of downstream distribution [0]), decides on issues\naffecting multiple projects, and generally forms an ultimate appeals board\nfor technical decisions.\n\n== Members ==\n\nThe TC is composed of 9 elected members. You can cumulate other roles\n(Project technical lead, Foundation board member...) with a TC seat.\nNote that Project technical leads do not get appointed seats to the TC:\nthey should run for election[1].\n\n== Meeting ==\n\nTC meetings happen publicly, weekly on IRC. The TC maintains an open agenda\non the wiki. A TC meeting is called if anything is posted to that wiki at\nleast one day before the meeting time. For a meeting to be actually held, at\nleast two thirds of the members need to be present (6 people). Non-members,\nin particular unelected PTLs or release manager, are more than welcome to\nparticipate to the meeting and voice their opinion, though they can\'t\nultimately vote.\n\n== Motions ==\n\nBefore being put to a vote, motions presented before the TC should be\ndiscussed publicly on the mailing-list[2] for a minimum of 5 days to give a\nchance to the wider community to express their opinion. Members can vote\npositively, negatively, or abstain. Decisions need more positive votes than\nnegative votes, and a minimum of 3 positive votes.\n\n== Election ==\n\nThe TC is renewed every 6 months using staggered elections: 5 seats are\nrenewed every 6 months. People ranking 1st to 4th get elected for a one-year\nterm. The 5th person gets elected for a 6-month term. People ranking after\n6th are retained as potential substitute members (see \"Revocation\").\n\n== Voters ==\n\nTechnical members of the Foundation, as determined by the Technical\nmembership committee[3], are able to participate in this election.\n\n== Revocation ==\n\nTC members are expected to be available and participate to weekly meetings.\nIf a particular TC member misses 3 of the last 5 called meetings, he should\nautomatically be revoked. He would be replaced by the top substitute (person\nranking 6th and after in previous election).\nEven when replacing someone elected for 1 year, the substitute inherits from\nthe shortest term; the highest ranking elected person inherits from the\npotential longer term[4].\n\n== Initial election ==\n\nTo initially populate the TC, all 9 seats are up for election. People\nranking 1st to 4th get elected for one year. People ranking 5th to 9th get\nelected for 6 months[5].\n\n\n[0] From http://wiki.openstack.org/ProjectTypes\n\n[1] The idea is that we want to de-correlate the number of PTLs (and the\nrelative importance of their projects) from the TC composition, to reduce\ncommittee bloat and be more fair. Influential PTLs from large projects\nshould get elected anyway.\n\n[2] Could be the openstack ML or a specific TC ML. The idea is to avoid\nsurprising the community with a decision, and avoid the usual kabbale\ncritics.\n\n[3] More on this later.\n\n[4] Example: Fx got elected in Fall 2012, while Sx got elected in Spring\n2013. Current board as F1, F2, F3, F4, S5 elected until Fall 2013, and S1,\nS2, S3, S4 elected until Spring 2014. S2 is a slacker is is revoked.\nS6 is called as a substitute. He should not get a longer term than S5\nthough. So S5 inherits from the 1-year-long term and S6 from the\n6-month-long term. Resulting board is: F1, F2, F3, F4, S6 elected until Fall\n2013, and S1, S3, S4, S5 elected until Spring 2014.\n\n[5] We may want to re-align elections with release cycles. Example: If TC is\ncreated in July 2012, we may want to align elections with the next design\nsummits, so the first term only be 2 months or 8 months.\n\n--\nThierry Carrez (ttx)\nRelease Manager, OpenStack\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n','<4F4278CD.9030406@openstack.org>',NULL),('<03A9C223-2D2B-4B09-A805-4652880FBCC4@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 13:11:55',-18000,'2014-11-13 18:11:55',NULL,'[openstack-dev] [Horizon] the future of angularjs development\n	in Horizon','\n> On Nov 13, 2014, at 12:38 PM, Thomas Goirand <zigo at debian.org> wrote:\n> \n> On 11/13/2014 10:56 PM, Martin Geisler wrote:\n>> Maybe a silly question, but why insist on this? Why would you insist on\n>> installing a JavaScript based application using your package manager?\n>> \n>> I\'m a huge fan of package managers and typically refuse to install\n>> anything globally if it doesn\'t come as a package.\n>> \n>> However, the whole JavaScript ecosystem seems to be centered around the\n>> idea of doing local installations. That means that you no longer need\n>> the package manager to install the software -- you only need a package\n>> manager to install the base system (NodeJs and npm for JavaScript).\n> \n> Yeah... Just like for Java, PHP, Perl, Python, you-name-it...\n> \n> In what way Javascript will be any different from all of these languages?\n\nNode.js, and npm in particular tends to solve the dependency hell problem\nby making it possible to install multiple versions of a particular thing\nand use them all within the same process. As far as I know the OS tooling\ndoesn?t really handle SxS installs of the same thing in multiple versions\nvery well, I think the closest that you can do is multiple separate packages\nwith version numbers in the package name? \n\nIn other words it?s entirely possible that a particular set of npm packages\ncan not be resolved to a single version per library.\n\n> \n>> Notice that Python has been moving rapidly in the same direction for\n>> years: you only need Python and pip to bootstrap yourself. After getting\n>> used to virtualenv, I\'ve mostly stopped installing Python modules\n>> globally and that is how the JavaScript world expects you to work too.\n> \n> Fine for development. Not for deployments. Not for distributions. Or you\n> just get a huge mess of every library installed 10 times, with 10\n> different versions, and then a security issue needs to be fixed?\n\nEh, I wouldn?t say it?s not fine for deployments. Generally I find that\nthe less I tie the things where I care about versions to my OS the happier\nmy life gets. It?s not fine for distributions wanting to offer it though,\nthat is correct.\n\n> \n>> So maybe the Horizon package should be an installer package like the\n>> ones that download fonts or Adobe?\n> \n> This is a horrible design which will *never* make it to distributions.\n> Please think again. What is it that makes Horizon so special? Answer:\n> nothing. It\'s \"just a web app\", so it doesn\'t need any special care. It\n> should be packaged, just like the rest of everything, with .deb/.rpm and\n> so on.\n> \n>> That package would get the right version of node and which then runs the\n>> npm and bower commands to download the rest plus (importantly and much\n>> appreciated) puts the files in a sensible location and gives them good\n>> permissions.\n> \n> Fine for your development environment. But that\'s it.\n> \n> Also, does your $language-specific-package--manager has enough checks so\n> that there\'s no man in the middle attack possible? Is it secured enough?\n> Can a replay attack be done on it? Does it supports any kind of\n> cryptography checks like yum or apt does? I\'m almost sure that\'s not the\n> case. pip is really horrible in this regard. I haven\'t checked, but I\'m\n> almost sure what we\'re proposing (eg: npm and such) have the same\n> weakness. And here, I\'m only scratching security concerns. There\'s other\n> concerns, like how good is the dependency solver and such (remember: it\n> took *years* for apt to be as good as it is right now, and it still has\n> some defects).\n\nAs far as I?m aware npm supports TLS the same as pip does. That secures the\ntransport between the end users and the repository so you can be assured\nthat there is no man in the middle. Security wise npm (and pip) are about\n~95% (mad up numbers, but you can get the gist) of the effectiveness as the\nOS package managers.\n\n> \n> On 11/14/2014 12:59 AM, Martin Geisler wrote:\n>> It seems to me that it should be possible translate the node module\n>> into system level packages in a mechanical fashion, assuming that\n>> you\'re willing to have a system package for each version of the node\n>> module\n> \n> Sure! That\'s how I do most of my Python modules these days. I don\'t just\n> create them from scratch, I use my own \"debpypi\" script, which generates\n> a template for packaging. But it can\'t be fully automated. I could\n> almost do it in a fully automated manner for PEAR packages for PHP (see\n> \"debpear\" in the Debian archive), but it\'s harder with Python and pip/PyPi.\n\nI would be interested to know what makes Python harder in this regard, I\nwould like to fix it.\n\n> \n> Stuff like debian/copyright files have to be processed by hand, and each\n> package is different (How to run unit tests? nose, testr, pytest? Does\n> it support python3? Is there a sphinx doc? How good is upstream short\n> and long description?). I guess it\'s going to be the same for Javascript\n> packages: it will be possible to do automation for some parts, but\n> manual work will always be needed.\n> \n> On 11/14/2014 12:59 AM, Martin Geisler wrote:\n>> The guys behind npm has written a little about how that could work\n>> here:\n>> \n>> http://nodejs.org/api/modules.html#modules_addenda_package_manager_tips\n> \n> It\'s fun to read, but very naive. First thing that is very shocking is\n> that arch independent things gets installed into /usr/lib, where they\n> belong in /usr/share. If that is what the NPM upstream produces, that\'s\n> scary: he doesn\'t even know how the FSHS (FileSystem Hierarchy Standard)\n> works.\n\nI may be wrong, but doesn?t the FHS state that /usr/share is for arch\nindependent *data* that is read only? I believe it also states that\n/usr/lib is for object files, libraries, and internal binaries. As far as\nI?m aware the things that npm installs are libraries the same as what\npip installs and should go under /usr/lib yea?\n\n> \n>> Has anyone written such wrapper packages? Not the xstatic system which\n>> seems to incur a porting effort -- but really a wrapper system that\n>> can translate any node module into a system package.\n> \n> The xstatic packages are quite painless, from my view point. What\'s\n> painful is to link an existing xstatic package with an already existing\n> libjs-* package that may have a completely different directory\n> structure. You can then end-up with a forest of symlinks, but there\'s no\n> way around that. No wrapper can solve that problem either. And more\n> generally, a wrapper that writes a $distribution source package out of a\n> $language-specific package manager will never solve all, it will only\n> reduce the amount of packaging work.\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n---\nDonald Stufft\nPGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n\n\n','<5464EC98.1010404@debian.org>',NULL),('<03B0265C-1C7F-4804-95CA-E712E6C6A1DC@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 22:48:11',0,'2013-12-12 22:48:11',NULL,'[openstack-dev] [Neutron][ML2] Unit test coverage','Mathieu,\n\nHere are my results for running the unit tests for the agents.\n\nI ran `tox -e cover neutron.tests.unit.openvswitch.test_ovs_neutron_agent` at 3b4233873539bad62d202025529678a5b0add412 with the following result:\n\nName                                                             Stmts   Miss Branch BrMiss  Cover\n?\nneutron/plugins/openvswitch/agent/ovs_neutron_agent                639    257    237    123    57%\n?\n\nand `tox -e cover neutron.tests.unit.linuxbridge.test_lb_neutron_agent` with the following result:\n\n...\nneutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent        607    134    255     73    76%\n...\n\nAmir\n\n\nOn Dec 11, 2013, at 3:01 PM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n\n> the coverage is quite good on the ML2 plugin.\n> it looks like the biggest effort should be done on the ovs and lb agents, no?\n> \n> On Wed, Dec 11, 2013 at 9:00 PM, Amir Sadoughi\n> <amir.sadoughi at rackspace.com> wrote:\n>> From today?s ML2 meeting, I had an action item to produce coverage report\n>> for ML2 unit tests.\n>> \n>> Here is the command line output of the tests and report I produced:\n>> \n>> http://paste.openstack.org/show/54845/\n>> \n>> Amir Sadoughi\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAAfiWQrodACU1=5pH=nFPCkv6Ei=Sj_L51Z6+zm=rznWpk3ecQ@mail.gmail.com>',NULL),('<03B054D28E391C4A8DE5DD8AB5030F3B015DC5C3F0@KSTLMEXCP04MBX.CORP.CHARTERCOM.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-22 09:51:05',-18000,'2014-09-22 14:51:05',NULL,'[Openstack] Neutron Network Paths','I believe there is an error in figure 12.2 on the Operations Guide<http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#neutron_network_traffic_in_cloud>, looking to confirm.  The install guide frequently references eth2 as the internet facing interface off of neutron yet, the figure has eth0.  It seems like eth0 and eth2 may just be reversed on the diagram.  Can anyone confirm if that\'s the case?\n\nThanks,\nRob\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140922/4b214512/attachment.html>\n\n',NULL,NULL),('<03B054D28E391C4A8DE5DD8AB5030F3B015DC5C958@KSTLMEXCP04MBX.CORP.CHARTERCOM.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-22 12:14:38',-18000,'2014-09-22 17:14:38',NULL,'[Openstack] Neutron Network Paths','Anne,\n\nThanks for the clarification and apologies.  I didn?t realize the install guide topology was different from the operations guide topology.\n\nThanks,\nRob\n\n\nFrom: annegentle at justwriteclick.com [mailto:annegentle at justwriteclick.com] On Behalf Of Anne Gentle\nSent: Monday, September 22, 2014 11:04 AM\nTo: Mengert, Robert\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Neutron Network Paths\n\n\n\nOn Mon, Sep 22, 2014 at 9:51 AM, Mengert, Robert <Robert.Mengert at charter.com<mailto:Robert.Mengert at charter.com>> wrote:\nI believe there is an error in figure 12.2 on the Operations Guide<http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#neutron_network_traffic_in_cloud>, looking to confirm.  The install guide frequently references eth2 as the internet facing interface off of neutron yet, the figure has eth0.  It seems like eth0 and eth2 may just be reversed on the diagram.  Can anyone confirm if that?s the case?\n\n\nHi Robert,\n\nThe install guide architecture is specifically different from the two architectures in the Operations Guide. I\'ve opened a doc bug [1] just to be sure we\'re accurate, and yes, we are accurate in the text and image in the Ops Guide.\n\nHope that explanation helps -\nAnne\n\n\n1. https://bugs.launchpad.net/openstack-manuals/+bug/1372516\n\nThanks,\nRob\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140922/184de5b4/attachment.html>\n\n','<CAD0KtVG=JMO9vTN6oE5mH6hpVS-TYqMGVvExQqagZSZg_xp4Vw@mail.gmail.com>',NULL),('<03B054D28E391C4A8DE5DD8AB5030F3B015E1557BD@KSTLMEXCP04MBX.CORP.CHARTERCOM.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-26 08:44:15',-18000,'2014-09-26 13:44:15',NULL,'[Openstack] understanding flows of ovs in openstack','Hey Srinivas,\n\nI?m an OpenStack newbie but just started working through some of the same questions (experienced folks, please chime in if I?m spurting nonsense here).  I?ve found that reading up on Open vSwitch independently has been very helpful, their documentation can be found here<http://openvswitch.org/support/>.  Their FAQ<http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=FAQ;hb=HEAD> is quite extensive but is a good read thus far (I?m only about halfway through it).\n\nSome of the commands to view flows are well documented in the FAQ:\n\nQ: Why are there so many different ways to dump flows?\n\nA: Open vSwitch has two kinds of flows (see the previous question), so\n   it has commands with different purposes for dumping each kind of\n   flow:\n\n      - \"ovs-ofctl dump-flows <br>\" dumps OpenFlow flows, excluding\n        hidden flows.  This is the most commonly useful form of flow\n        dump.  (Unlike the other commands, this should work with any\n        OpenFlow switch, not just Open vSwitch.)\n\n      - \"ovs-appctl bridge/dump-flows <br>\" dumps OpenFlow flows,\n        including hidden flows.  This is occasionally useful for\n        troubleshooting suspected issues with in-band control.\n\n      - \"ovs-dpctl dump-flows [dp]\" dumps the datapath flow table\n        entries for a Linux kernel-based datapath.  In Open vSwitch\n        1.10 and later, ovs-vswitchd merges multiple switches into a\n        single datapath, so it will show all the flows on all your\n        kernel-based switches.  This command can occasionally be\n        useful for debugging.\n\n      - \"ovs-appctl dpif/dump-flows <br>\", new in Open vSwitch 1.10,\n        dumps datapath flows for only the specified bridge, regardless\n        of the type.\n\nI haven?t gotten to how Open vSwitch populates the flows yet without the use of an SDN controller.  I?m a network guy by trade so I imagine there?s some type of learning at layer 2 happening similar to standard Ethernet switching.  Can anyone confirm?\n\nThanks,\nRob\n\nFrom: Srinivasreddy R [mailto:srinivasreddy4390 at gmail.com]\nSent: Friday, September 26, 2014 7:19 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] understanding flows of ovs in openstack\n\nhi ,\ni want to understand  the role of openvswitch  in openstack .\nhow and what flows are configured  in both compute and networknode .\nplease suggest .\nthanks,\nsrinivas.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140926/7aff3ee7/attachment.html>\n\n','<CAJP4VWgrph2A1Kq2L+_+dsGddcif01ONLikqu4MufRBd=bPq8w@mail.gmail.com>',NULL),('<03B054D28E391C4A8DE5DD8AB5030F3B01620A3C0F@KSTLMEXCP04MBX.CORP.CHARTERCOM.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-27 14:43:16',-18000,'2014-10-27 19:43:16',NULL,'[Openstack] Question about \"tenant_network_types\"','Is there a way to list both tenant types in all of the config files and then select which protocol to use when creating a network?\n\nThanks,\nRob\n\nFrom: Danny Choi (dannchoi) [mailto:dannchoi at cisco.com]\nSent: Thursday, October 09, 2014 6:38 AM\nTo: Remo Mattei\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Question about \"tenant_network_types\"\n\nHow to do that?  I don?t see the option to specify the network type when creating a network.\n\n\nlocaladmin at qa4:~/devstack$ neutron help net-create\n\nusage: neutron net-create [-h] [-f {shell,table,value}] [-c COLUMN]\n\n                          [--max-width <integer>] [--prefix PREFIX]\n\n                          [--request-format {json,xml}]\n\n                          [--tenant-id TENANT_ID] [--admin-state-down]\n\n                          [--shared]\n\n                          NAME\n\n\n\nCreate a network for a given tenant.\n\n\n\npositional arguments:\n\n  NAME                  Name of network to create.\n\n\n\noptional arguments:\n\n  -h, --help            show this help message and exit\n\n  --request-format {json,xml}\n\n                        The XML or JSON request format.\n\n  --tenant-id TENANT_ID\n\n                        The owner tenant ID.\n\n  --admin-state-down    Set admin state up to false.\n\n  --shared              Set the network as shared.\n\n\n\noutput formatters:\n\n  output formatter options\n\n\n\n  -f {shell,table,value}, --format {shell,table,value}\n\n                        the output format, defaults to table\n\n  -c COLUMN, --column COLUMN\n\n                        specify the column(s) to include, can be repeated\n\n\n\ntable formatter:\n\n  --max-width <integer>\n\n                        Maximum display width, 0 to disable\n\n\n\nshell formatter:\n\n  a format a UNIX shell can parse (variable=\"value\")\n\n\n\n  --prefix PREFIX       add a prefix to all variable names\n\n\n\n\n\nThanks,\n\nDanny\n\nFrom: Remo Mattei <remo at italy1.com<mailto:remo at italy1.com>>\nDate: Wednesday, October 8, 2014 at 11:21 PM\nTo: Danny Choi <dannchoi at cisco.com<mailto:dannchoi at cisco.com>>\nCc: \"openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\" <openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>>\nSubject: Re: [Openstack] Question about \"tenant_network_types\"\n\nYou can use any of these to create networks.\n\nInviato da iPhone (?)\n\nIl giorno 08/ott/2014, alle ore 17:02, Danny Choi (dannchoi) <dannchoi at cisco.com<mailto:dannchoi at cisco.com>> ha scritto:\nHi,\n\nIn ml2_conf.ini file, what does it mean when the attribute ?tenant_network_types? is set to multiple values?\n\nE.g. tenant_network_types = vlan,gre,vxlan\n\nThanks,\nDanny\n!DSPAM:1,5435d1b8166764788126840!\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n!DSPAM:1,5435d1b8166764788126840!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141027/7151cf26/attachment.html>\n\n','<D05BF958.1B6A%dannchoi@cisco.com>',NULL),('<03B054D28E391C4A8DE5DD8AB5030F3B0169FEC2BD@KSTLMEXCP04MBX.CORP.CHARTERCOM.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-16 16:09:55',-21600,'2014-12-16 22:09:55',NULL,'[Openstack] Upgrade Procedure from Icehouse to Juno','Hello All,\n\nIs there an official upgrade procedure from Icehouse to Juno?  I stumbled across Thiago\'s procedure here<http://lists.openstack.org/pipermail/openstack/2014-November/010184.html>, has this been entered into the official OS canon so to speak?  Any help is much appreciated.\n\nThanks,\nRob\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141216/f041c015/attachment.html>\n\n',NULL,NULL),('<03B28A0E-1E87-4C9A-9A55-EEA9C8C91C08@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 12:49:45',-18000,'2015-01-23 17:49:45',NULL,'[openstack-dev] [oslo] [nova] [all] potential enginefacade\n	adjustment - can everyone live with this?','\n\nMike Bayer <mbayer at redhat.com> wrote:\n\n> \n> \n> Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n> \n>> On 01/23/2015 05:38 PM, Mike Bayer wrote:\n>>> Doug Hellmann <doug at doughellmann.com> wrote:\n>>> \n>>>> We put the new base class for RequestContext in its own library because\n>>>> both the logging and messaging code wanted to influence it\'s API. Would\n>>>> it make sense to do this database setup there, too?\n>>> whoa, where?s that? is this an oslo-wide RequestContext class ? that would\n>>> solve everything b.c. right now every project seems to implement\n>>> RequestContext themselves.\n\n\nso Doug -\n\nHow does this ?influence of API? occur, would oslo.db import\noslo_context.context and patch onto RequestContext at that point? Or the\nother way around? Or? ?\n\n\nI?m almost joyful that this is here.   Assuming we can get everyone to use it, should be straightforward for that right?\n\n\n\n\n','<289D9FAA-FD40-473E-B637-892491564573@redhat.com>',NULL),('<03b7913678214de4884a861133c7b649@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-07 06:55:07',0,'2014-01-07 06:55:07',NULL,'[Openstack] [Openstack-dev][Tempest] Writing Tempest testcases for\n Neutron ML2 mechanism drivers','Hi  -\n\nWith respect to writing testcases with Tempest for Neutron,\n\nI have a Freescale Mechanism Driver which support a Cloud Resource Discovery (CRD) Service .\n\nThe complete data flow is show below.\n\n[cid:image001.png at 01CF0BA3.7DB6CAE0]\n\nThe FSL Mechanism driver partly depends on ML2 Plug-in (_pre_commint and _post_commit definitions) and Partly depends on CRD Service (with CRD client calls in _post_commit definitions).\n\nI want to write Tempest test cases for the FSL Mechanism driver.\n\nKindly please help me on how to write the Tempest test cases for these kind of mechanism drivers.\n\nAlso, help me on how to submit the BP document, Code base and Test cases for review.\n\nThanking you all..\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140107/1acbca05/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 19718 bytes\nDesc: image001.png\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140107/1acbca05/attachment.png>\n\n',NULL,NULL),('<03B9AA4F-975F-4FDB-B314-707BC6C35796@justwriteclick.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-28 08:33:43',-18000,'2014-09-28 13:33:43',NULL,'[openstack-dev] [nova] where can i get all notifications spec\n	for nova','For the next release we will work on automating these into the docs so it stays up to date and is easier to find.\n\nSee \nlists.openstack.org/pipermail/openstack-docs/2014-September/005207.html \nAnne Gentle\nContent Stacker\nanne at openstack.org\n\n\n> On Sep 28, 2014, at 4:55 AM, \"Li Tianqing\" <jazeltq at 163.com> wrote:\n> \n> Yes. But it\'s just a part of notifications. Should we collect all notifications and display them in documents? Or is there an elegant way to get all notifications?\n> \n> Thanks.\n> \n> --\n> Best\n>     Li Tianqing\n> \n> At 2014-09-28 17:17:57, \"Liping Mao -X (limao - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at Cisco)\" <limao at cisco.com> wrote:\n> You may find part of them here?\n> \n> https://wiki.openstack.org/wiki/SystemUsageData\n> \n>  \n> \n> Regards,\n> \n> Liping Mao\n> \n>  \n> \n>  \n> \n> From: Li Tianqing [mailto:jazeltq at 163.com] \n> Sent: 2014?9?28? 16:30\n> To: openstack-dev at lists.openstack.org\n> Subject: [openstack-dev] [nova] where can i get all notifications spec for nova\n> \n>  \n> \n> Hello,\n> \n>     Is there some documents to display all notifications in nova? Thanks.\n> \n> \n> \n> \n> \n> --\n> \n> Best\n> \n>     Li Tianqing\n> \n>  \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140928/d823f00b/attachment.html>\n\n','<15dd5632.14014.148bbaf93c3.Coremail.jazeltq@163.com>',NULL),('<03bb01cdc69b$5d6c46a0$1844d3e0$@renski.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-19 13:18:03',-28800,'2012-11-19 21:18:03',NULL,'[openstack-dev] The future of Incubation and Core - a motion','Since we are talking about OpenStack core and respective roles of TC and\nboard in helping define this, I have a matter up for discussion that\'s been\nbothering me for some time. \n\nToday we have two types of projects that are core. Those where the bigger\nemphasis is on the API and APIs are loosely coupled with the implementation\nor even third party functionality or plug-ins (Nova, Quantum, Cinder) and\nthose that are really opinioned implementations of certain functionality -\nSwift (probably the most pronounced member of the second category), Horizon\netc. \n\nFor instance, similar to Quantum, Swift could have been designed as an API\ncentric service with implementations as plug-ins; but it is not. And largely\ndue to the history of how OpenStack evolved, Swift now became the monopoly\nimplementation on object store, indefinitely enjoying core project status.\nIt is not unlikely that Swift could become less active and its opinionated\narchitecture - less relevant to the newer paradigms of storage. More\nimportantly, because something like Swift is core, nobody in the community\nwould even consider developing a different, competing implementation.... \n\nI am not trying to pick on Swift in particular (so John, don\'t get mad) but\nam using it to illustrate a scenario. \n\nI feel that as we rethink project categories, it make sense to incorporate\nthe distinction between developing an API standard and the underlying\nimplementation. And there are several ways we can go: \n\n1. We can say we don\'t care about the rigidity of coupling between API and\nimplementation in general. All we care about is if the project is mature\nenough and if it solves a substantial IaaS problem.... in that case we need\nto have a mechanism to deprecate projects from core when a particular\nimplementation is no longer optimal or if the project becomes inactive. \n\n2. We can say that we DO care about this and want to decouple APIs and\nimplementations as the underlying philosophy of all OpenStack projects. In\nthat case we need to make sure that ALL core (nucleus) projects are API\nfocused and designed to support various implementations as plug-ins, and\nthen have a separate, rather inclusive, category of projects that constitute\nvarious mature implementations of the nucleus APIs that can be certified as\ncore, support etc.  \n\nI haven\'t heard any of the core vs. not core discussion rotate around API\nvs. implementation concept and would like to hear what people think. \n\n-Boris      \n\n\nAnne Gentle wrote:\n> I think there are projects that should be held to the requirements an\n> integrated release has. They\'re probably all in nuclear and core.\n> Perhaps nuclear is only helpful to scope release management, CI,\n> integration testing, and doc. Hm. I would want \"core\" projects to get\n> benefits from the systems we provide but not overwhelm them.\n\nSo, if I understand correctly, your motion would be a variation on\nMark\'s proposal where we would split the \"services\" category into two:\n\"core\" and \"nuclear\", which would be prioritized slightly differently in\nterms of associated common resources.\n\nThose would still be technically-defined (under the authority of the TC)\nin a way that is disconnected from trademark usage (although I suspect\nit would be a good thing if Nuclear projects were all in the BoD\ntrademark scope).\n\nI think that\'s definitely acceptable. A bit more bureaucracy on one side\n(one additional project category) but it might end up being useful to\nprioritize our resources if we grow the number of projects. Whether we\nend up with one or two (or more) project categories is not actually that\nimportant at this stage, that\'s just a technical way to name project\ntypes under the TC\'s responsibility.\n\nWhat we really need is a view on how to handle incubation and core\nprocess together with the BoD, and on that point your motion is very\naligned with Mark\'s, as far as I can tell: separate the areas of\nresponsibility by handling trademark issues separately from which\nproject we grow under the OpenStack development umbrella.\n\nMaybe we can merge the two motions by leaving the question of the number\nof project categories for a future discussion ? I\'m not sure it makes\nsense to decide between the two variants until we know if the rest of\nour position is acceptable by the BoD.\n\n-- \nThierry Carrez (ttx)\n\n\n\n\n',NULL,NULL),('<03BCC46C-3CCE-4531-AA89-332D9E0AE604@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-30 20:33:44',-25200,'2014-07-01 03:33:44',NULL,'[Openstack] difference of default tenant?','Admin is used for external network services is used for communication like rabbit keystone MySQL etc. \n\nInviato da iPhone (?)\n\n> Il giorno Jun 30, 2014, alle ore 20:24, Yugang LIU <zzzz88.aaaa at gmail.com> ha scritto:\n> \n> Hi\n> \n> By default Openstack will create two tenant, \"admin\" and \"service\".\n> \n> Who may tell me what is difference?\n> \n> With installation guide, it use \"admin\"\n> \n> With administrator guide, it use \"service\"\n> \n> Which one should I use when I create external network?\n> \n> -- \n> Best regards\n> \n> Yugang LIU\n> \n> Keep It Simple, Stupid\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> !DSPAM:1,53b22b85253381187118924!\n> \n\n\n','<53B229D4.8030505@gmail.com>',NULL),('<03c801cefaaf$fd2c4200$f784c600$@students.waikato.ac.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 11:41:37',46800,'2013-12-16 22:41:37',NULL,'[openstack-dev] a time-based resource management system','Hi everyone,\n\n \n\nMy name is Alan and I am from the Cyber Security Lab in University of\nWaikato. \n\n \n\nWe have recently started deploying and using Openstack in our experimental\nprivate cloud testbed. The cloud testbed is mainly used in running our\nresearch and teaching purposes. However, we notice that current Openstack\nlacks the ability to control and manage user\'s access to resources in a\ntime-based manner. \n\n \n\nI.e. Current model for private clouds requires either the user to release\ntheir resources (VMs) voluntarily or for the administrators to manually\nremove the resources (VMs).\n\n \n\nThis makes capacity management a laborious effort in private clouds that\nhave a large user base. Hence, we have come up with the idea of an automatic\ntime-based resource management system that manages user access to resources\nin a time slot booking style. We have detailed our plans and design in the\nfollowing wiki page. We would love to hear feedbacks from the community and\nhopefully gather some interest in our project.\n\n \n\n <https://wiki.openstack.org/wiki/Cafe> https://wiki.openstack.org/wiki/Cafe\n\n \n\nWe look forward to hearing from you. We can be contacted via email. Our\naddresses are listed on the wiki page. \n\n \n\nThanks and have a good day.\n\n \n\nCheers,\n\nAlan\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131217/9560590e/attachment.html>\n\n',NULL,NULL),('<03CABDD4-27F5-4720-BA96-F61C7F82E768@subbu.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-12 16:58:45',-14400,'2014-05-12 20:58:45',NULL,'[openstack-dev] [Fuel] useful deployment related talks','We should perhaps clarify that these etherpads are about deployment/operations of OpenStack discussed under https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Ops, and not Fuel.\n\nSubbu\n\nOn May 12, 2014, at 2:33 PM, Vladimir Kuklin <vkuklin at mirantis.com> wrote:\n\n> Guys\n> \n> It would be awesome if we shared links on useful talks/meetups that can be related to FUEL and deployment/operations of Openstack. \n> \n> These are for setting optimal config options and upgrades:\n> \n> https://etherpad.openstack.org/p/juno-summit-ops-upgradesdeployment\n> https://etherpad.openstack.org/p/juno-summit-ops-reasonabledefaults\n> \n> -- \n> Yours Faithfully,\n> Vladimir Kuklin,\n> Fuel Library Tech Lead,\n> Mirantis, Inc.\n> +7 (495) 640-49-04\n> +7 (926) 702-39-68\n> Skype kuklinvv\n> 45bk3, Vorontsovskaya Str.\n> Moscow, Russia,\n> www.mirantis.com\n> www.mirantis.ru\n> vkuklin at mirantis.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAHAWLf2y01f6Bc5D=CQvnvDXO4fwsdJ61hdML3vPtH4DOoh+8Q@mail.gmail.com>',NULL),('<03CD7B40-73C7-4938-99CB-C6196AD598F2@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-28 12:29:12',-28800,'2015-01-28 20:29:12',NULL,'[Openstack-operators] [Keystone] Deprecation of LDAP Assignment\n	(Only Affects Project/Tenant/Role/Assignment info in LDAP)','To make it perfectly clear: We are NOT removing nor plan to remove the ability to use LDAP for users and groups in Keystone.\n\nNOTE: Please be sure to read the whole email AND FAQ before worrying about the impact of this deprecation.\n\n\nLDAP is used in Keystone as a backend for both the Identity (Users and groups) and assignments (assigning roles to users) backend. \n\nWhere did the LDAP Assignment backend come from? We originally had a single backend for Identity (users, groups, etc) and Assignment (Projects/Tenants, Domains, Roles, and everything else not-users-and-groups). When we did the split of Identity and Assignment we needed to support the organizations that deployed everything in the LDAP backend. This required both a driver for Identity and Assignment.\n\n We are planning on keeping support for identity while deprecating support for assignment.  There is only one known organization that this will impact (CERN) and they have a transition plan in place already. \n\nNow before anyone starts worrying about this please read the whole email and FAQ at the end. Let me be perfectly clear. LDAP assignment is *not*  referring to using LDAP for user and groups. That highly popular feature remains in Keystone.This change should have no impact for other users of LDAP in Keystone.\n\n\nThe Problem\n??????\nThe SQL Assignment backend has become significantly more feature rich and due to the limitations of the basic LDAP schemas available (most LDAP admins wont let someone load custom schemas), the LDAP assignment backend has languished and fallen further and further behind. It turns out almost no deployments use LDAP to house projects/tenants, domains, roles, etc. A lot of deployments use LDAP for users and groups.\n\nWe explored many options on this front and it boiled down to three:\n\n1. Try and figure out how to wedge all the new features into a sub-optimal data store (basic/standard LDAP schemas)\n2. Create a custom schema for LDAP Assignment. This would require convincing LDAP admins (or Active Directory admins) to load a custom schema. This also was a very large amount of work for a very small deployment base.\n3. Deprecate the LDAP Assignment backend and work with the community to support (if desired) an out-of-tree LDAP driver (supported by those who need it).\n\n\nBased upon interest, workload, and general maintainability issues, we have opted to deprecate the LDAP Assignment backend. What does this mean?\n\n1. This means effective as of Kilo, the LDAP assignment backend is deprecated and Frozen.\n1.a. No new code/features will be added to the LDAP Assignment backend.\n1.b. Only exception to 1.a is security-related fixes.\n\n2.The LDAP Assignment backend (\"[assignment]/driver? config option set to ?keystone.assignment.backends.ldap.Assignment? or a subclass) will remain in-tree with plans to be removed in the ?M?-release.\n2.a. This is subject to support beyond the ?M?-release based upon what the keystone development team and community require.\n\n\nFAQ\n??\n\nQ: Will Keystone still support Users and Groups in LDAP?\nA: Absolutely! There are no plans to deprecate utilizing LDAP (or Active Directory) to store users and groups. The Keystone team is committed to maintaining and improving the LDAP Identity driver.\n\nQ: Will there be a migration from LDAP Assignment to SQL Assignment for the deployers that are still using LDAP Assignment backend?\nA: Each deployment is highly specific to the LDAP data store used and schema defined by the organization. The Keystone team has spoken with the deployers that have stated they are using LDAP Assignment (and plan to move to SQL assignment). Most deployers using LDAP Assignment already have plans on how to Migrate. The Keystone team will be happy to provide advice (come chat with us in #openstack-keystone on Freenode) but we do not expect to provide a canned script to make the migration happen.\n\nQ: Why not just keep Assignment in LDAP as an option, but freeze it like the V2 API?\nA: We explored this option, but with all of the new functionality (including identity federation), code fixes, and maintenance issues, it just doesn?t make sense from a cloud-interoperability standpoint to maintain a second-class [at best barely implementing feature parity] driver for Assignment. We would rather support a clear interoperable OpenStack world where a user doesn?t need to guess / know a ton about the deployment to successfully utilize the cloud resources.\n\n\nThanks for reading through the whole email! Please feel free to chat with the development team on IRC or via the Mailing List to discuss any other issues / concerns  related to this change.\n\nCheers,\nMorgan Fainberg\nKeystone PTL\n\n\n',NULL,NULL),('<03D04E30-EDF9-466C-85E3-1798CFA16A7B@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 19:16:44',-18000,'2012-08-03 00:16:44',NULL,'[OpenStack Foundation] Nomination Process Updates','I like this line of thinking. \n\nOn Aug 2, 2012, at 7:13 PM, Duncan McGreggor <duncan at dreamhost.com> wrote:\n\n> What about checkboxes for areas in which one has contributed?\n> \n> [ ] commits to one or more projects\n> [ ] updates to wiki pages\n> [ ] attendance at conferences\n> [ ] participation in hack-ins/bug-squash days\n> [ ] community/project infrastructure support\n> [ ] advocacy in social media (blog posts, tweets, etc.)\n> [ ] ... other options?\n> \n> I would hope that not checking these wouldn\'t prevent one from\n> becoming a member, but it would provide *a* gauge to assess certain\n> levels of involvement.\n> \n> I do like the idea of requiring a certain amount of text to describe\n> one\'s interest in OpenStack and intentions for use and/or planned\n> contributions. Maybe the text provided should be longer than 100-200\n> chars?\n> \n> d\n> \n> On Thu, Aug 2, 2012 at 4:34 PM, Lauren Sell <lauren at openstack.org> wrote:\n>> What questions should be required for the public profile?  The current signup process asks for affiliation, statement of interest and which projects you\'re working on.\n>> \n>> A couple of ideas on what the additional questions could be -- (1) how long have you been working on OpenStack or (2) what have you or do you plan to contribute to the project.  We could also force more long form answers afround the affiliation or statement of interest with a minimum character requirement.  Again, just looking for ideas here.\n>> \n>> The goal is to make sure everyone voting is really serious.\n>> \n>> On Aug 2, 2012, at 1:21 PM, Matt Joyce wrote:\n>> \n>>> I like laurens idea as well.  Making folks jump through a few hoops to\n>>> demonstrate their loyalty to the party will cut back on the\n>>> astroturfing comrades.\n>>> \n>>> On Thu, Aug 2, 2012 at 5:50 AM, Mark Collier <mark at openstack.org> wrote:\n>>>> I like Lauren\'s idea as well. I think we can act on it pretty quickly as well.\n>>>> \n>>>> On Aug 2, 2012, at 7:46 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>>>> \n>>>>> Just a random thought on the criteria for being an individual member ...\n>>>>> \n>>>>> On Wed, 2012-08-01 at 22:16 -0400, Mark Collier wrote:\n>>>>> \n>>>>>> \n>>>>>> The definition of \"individual members\"\n>>>>> [...]\n>>>>>> \n>>>>>> The wiki:\n>>>>> [...]\n>>>>>> Characteristics of Individual Members:\n>>>>>> \n>>>>>> Contribute to OpenStack in a variety of ways such as code,\n>>>>>> documentation, translations, bug reports, testing, project\n>>>>>> infrastructure, advocacy, marketing, community management, legal\n>>>>>> guidance\n>>>>> [...]\n>>>>>> and in the by laws [...]\n>>>>>> \n>>>>>> \"2.2 Individual Members.\n>>>>>> \n>>>>>> (a) Individual Members must be natural persons. Individual Members may\n>>>>>> be any natural person who has an interest in the purpose of the\n>>>>>> Foundation\n>>>>> [...]\n>>>>> \n>>>>> The wiki clearly says that individual members should have contributed to\n>>>>> OpenStack in some form. I like that, and I have no problem with the\n>>>>> definition of \"contributed\" being extremely inclusive.\n>>>>> \n>>>>> However, the bylaws watered that down to \"has an interest\" and AFAIK\n>>>>> we\'re taking \"applied for membership\" as enough to demonstrate an\n>>>>> interest.\n>>>>> \n>>>>> Given the 700+ RAX and HP members, was this too inclusive? Would all of\n>>>>> those meet the criteria in the wiki? If not, how can we correct the\n>>>>> process now or in the future?\n>>>>> \n>>>>> I like Lauren\'s idea of making people fill in a \"why you\'re interested\n>>>>> in OpenStack\" blurb and publishing it. I also like the approach of\n>>>>> having an open membership committee[1] with clear guidelines.\n>>>>> \n>>>>> Cheers,\n>>>>> Mark.\n>>>>> \n>>>>> [1] - e.g. https://live.gnome.org/MembershipCommittee/\n>>>> \n>>>> _______________________________________________\n>>>> Foundation mailing list\n>>>> Foundation at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>> \n>>> _______________________________________________\n>>> Foundation mailing list\n>>> Foundation at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>> \n>> \n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n','<CAG_87Ok8qAxOA7OU6GO4-ic_5MSBrtsRt--GoaSpFYBAoE7d-A@mail.gmail.com>',NULL),('<03D54A59-B1A8-4309-92B6-4BCCDA5CF1E1@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-22 09:16:39',-28800,'2013-02-22 17:16:39',NULL,'[openstack-dev] RFC: Namespacing for hardware related glance\n	image properties','+1 to prefix.\n\nI slightly prefer the : just because it is consistent with other ways that we namespace things.\n\nVish\n\nOn Feb 22, 2013, at 5:41 AM, Daniel P. Berrange <berrange at redhat.com> wrote:\n\n> In the following two commits\n> \n>  commit 99ddc0d2ad7f2f9c27deaac08559eb794845afc3\n>  Author: Daniel P. Berrange <berrange at redhat.com>\n>  Date:   Fri Feb 8 16:59:32 2013 +0000\n> \n>    Allow VIF model to be chosen per image\n> \n>  commit 66a7f044f5143feaf7046cebafea3df3ea95e04b\n>  Author: Daniel P. Berrange <berrange at redhat.com>\n>  Date:   Wed Jan 16 12:38:23 2013 +0000\n> \n>    Allow disk driver to be chosen per image\n> \n> \n> I introduced support for the Nova libvirt driver to read glance image\n> properties for customizing the hardware of a guest.\n> \n> eg the user would set\n> \n>      # glance image-update \\\n>               --property disk_bus=ide \\\n>               --property cdrom_bus=ide \\\n>               --property vif_model=e1000 \\\n>               f16-x86_64-openstack-sda\n> \n> These properties are equally applicable to other hypervisor drivers and\n> thus ought to be documented as \"standard\" metadata properties, so we\n> don\'t get each driver doing its own thing [1]\n> \n> It was suggested to me on IRC that we might want to first change the\n> names I used here to have some kind of standard \"prefix\" to group all\n> hardware config properties together, eg prefix then with \'hw_\' or \'hw:\'.\n> \n> So instead of the above names, use\n> \n>      # glance image-update \\\n>               --property hw_disk_bus=ide \\\n>               --property hw_cdrom_bus=ide \\\n>               --property hw_vif_model=e1000 \\\n>               f16-x86_64-openstack-sda\n> \n> \n> Obviously if we\'re going to make such a change we need todo it real\n> soon before Grizzly goes GA, otherwise we have backcompat pain to\n> deal with.\n> \n> Thoughts ?\n> \n> Regards,\n> Daniel\n> \n> [1] Sadly VMWare already has some vmware specific property names\n> -- \n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20130222134148.GI11782@redhat.com>',NULL),('<03E7B78B-B5C0-486C-BBCC-97AD4C21237D@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-27 13:48:16',-21600,'2014-01-27 19:48:16',NULL,'[Openstack] [glance] problem with glance registry','What os are you running? Maybe they cannot reach each other i would check that \n\nInviato da IPad (?)\n\n> Il giorno Jan 27, 2014, alle ore 13:28, \"gustavo panizzo <gfa>\" <gfa at zumbi.com.ar> ha scritto:\n> \n> Hello\n>    since today our glance install is not working, we are not able to boot\n> new machines\n> \n> \n> the only thing i see in logs is\n> \n> 2014-01-27 16:10:43.364 9237 INFO glance.registry.client.v1.client\n> [29e031a9-cb1c-4b20-8a7f-100ed10f3785 184136c2674746b5a4b27d3b13ca91f8\n> af41371701004068b2532695ed57f16f] Registry client request GET\n> /images/detail raised ServerError\n> \n> on glance-registry log there is nothing like an error\n> \n> 2014-01-27 16:10:43.333 8771 INFO glance.registry.api.v1.images\n> [7c168813-dc04-4b65-ad00-0cc171afb10a 184136c2674746b5a4b27d3b13ca91f8\n> af41371701004068b2532695ed57f16f] Returning detailed image list\n> \n> \n> glance index fails. but it always failed for us with more than 10\n> images, is it expected?\n> \n> # glance --debug index\n> \n> [ snip snip ]\n> \n> size\": 3280732160}, {\"status\": \"active\", \"name\": \"Win7x86\", \"deleted\":\n> false, \"container_format\": \"ovf\", \"created_at\":\n> \"2014-01-13T21:32:39.412830\", \"disk_format\": \"qcow2\", \"updated_at\":\n> \"2014-01-14T14:38:09.932192\", \"min_disk\": 40, \"protected\": true, \"id\":\n> \"d0d3b1f4-3e9e-430e-a60a-42de277291da\", \"min_ram\": 2048, \"checksum\":\n> \"f44b61df38f3d1de775a989eccc1798f\", \"owner\":\n> \"af41371701004068b2532695ed57f16f\", \"is_public\": true, \"deleted_at\":\n> null, \"properties\": {\"protected\": null}, \"size\": 3374317568}]}\n> \n> f31c2938-89b4-4fed-b78c-0d5a633313de debian-wheezy-amd64_2014-01-17\n> qcow2                ovf                       996999168\n> 16ec85ff-6451-4d36-8908-c5c3b57c862b wheezy-cristian-snap           ami\n>                 ami                      1067450368\n> 7fbd62fd-72e6-4f18-ba26-3df9f8295f60 couchdb-snapshot               ami\n>                 ami                      1150812160\n> 6051f420-c590-43f3-a3b1-2802a74d6dc4 vmlinuz-3.2.0-4-amd64          aki\n>                 aki                         2827712\n> 680680ef-0207-44fe-ad9f-6e01a4e0147a initrd-3.2.0-4-amd64           ari\n>                 ari                        10486978\n> 11339ff2-9240-4c44-ad8b-091192e0301b wheezy_postgresql\n> qcow2                bare                     1071448064\n> 44d691b8-57e3-44df-9d29-14a6c1f4a431 Win2012-sql\n> qcow2                ovf                     13241942016\n> 784e7546-d101-4cb0-92e0-26faf7f6dfaf Win2012\n> qcow2                ovf                      4284743680\n> 25e38d31-cf2b-4a13-b1bd-90936d90eab4 Win2008r2\n> qcow2                ovf                      3280732160\n> d0d3b1f4-3e9e-430e-a60a-42de277291da Win7x86\n> qcow2                ovf                      3374317568\n> curl -i -X GET -H \'X-Auth-Token: c88edf81cae841f4a5638f7267074160\' -H\n> \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\'\n> http://10.17.10.34:9292/v1/images/detail?marker=d0d3b1f4-3e9e-430e-a60a-42de277291da&limit=10\n> \n> HTTP/1.1 500 Internal Server Error\n> date: Mon, 27 Jan 2014 19:14:28 GMT\n> content-length: 0\n> content-type: text/plain\n> connection: close\n> \n> Request returned failure status.\n> HTTPInternalServerError (HTTP 500)\n> \n> \n> we use rbd as backend storage and pgsql as db\n> our install runs havana 2013.2.1-2\n> keystone uses memcached backend and uuid, we have tried restarting\n> glance-api and registry, keystone and memcached, but nothing.\n> db looks exactly the same as friday\n> \n> no changes were made during the weekend. friday we were running smoothly\n> \n> \n> PS: i can send logs, config files, whatever, but they are pretty default\n> \n> thanks!\n> \n> \n> -- \n> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> !DSPAM:1,52e6b60e31611208556276!\n> \n\n\n','<52E6B37A.5090801@zumbi.com.ar>',NULL),('<03EDCACB-AEA2-4763-B54C-A34CBA2902EE@not.mn>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2014-07-22 09:41:08',-25200,'2014-07-22 16:41:08',NULL,'[openstack-announce] python-swiftclient 2.2.0 release','I\'m happy to announce that python-swiftclient 2.2.0 has been released.\n\nThis release has the following significant features:\n\n* Ability to set a storage policy on container and object upload\n* Ability to generate Swift temporary URLs from the CLI and SDK\n* Added context-sensitive help to the CLI commands\n\nThis release is available on PyPI at https://pypi.python.org/pypi/python-swiftclient/2.2.0\n\n--John\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20140722/1606f548/attachment.pgp>\n\n',NULL,NULL),('<03EDCACB-AEA2-4763-B54C-A34CBA2902EE@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 09:41:08',-25200,'2014-07-22 16:41:08',NULL,'[openstack-dev] python-swiftclient 2.2.0 release','I\'m happy to announce that python-swiftclient 2.2.0 has been released.\n\nThis release has the following significant features:\n\n* Ability to set a storage policy on container and object upload\n* Ability to generate Swift temporary URLs from the CLI and SDK\n* Added context-sensitive help to the CLI commands\n\nThis release is available on PyPI at https://pypi.python.org/pypi/python-swiftclient/2.2.0\n\n--John\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140722/1606f548/attachment.pgp>\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<03f284723a2943f7ad45a768ddf421f8@HKNPR01MB241.apcprd01.prod.exchangelabs.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 08:44:18',0,'2014-07-22 08:44:18',NULL,'[openstack-dev] [Cinder] Integrated with iSCSI target Question','Dear Jay,\n\nYes, it\'s answer my question.\nBecause I have problem to launch an instance from an image, I can not do \"nova volume-attach\" to check if iSCSI LUN mechanism is work.\n\nThanks for your reply.\n\nRegards,\nJohnson\n\n-----Original Message-----\nFrom: Jay S. Bryant [mailto:jsbryant at electronicjungle.net] \nSent: Monday, July 21, 2014 11:53 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question\n\nJohnson,\n\nI am not sure what you mean by \'attach volume manually\'.  Do you mean when you do a \'nova volume-attach\'?  If so, then, yes, the process will use the appropriate iscsi_helper and iscsi_ip_address to configure the attachment.\n\nDoes that answer your question?\n\nJay\n\nOn Mon, 2014-07-21 at 12:23 +0000, Johnson Cheng wrote:\n> Dear Thomas,\n> \n> Thanks for your reply.\n> So when I attach volume manually, will iSCSI LUN be automatically setup via cinder.conf (iscsi_helper and iscsi_ip_address)?\n> \n> \n> Regards,\n> Johnson\n> \n> -----Original Message-----\n> From: Duncan Thomas [mailto:duncan.thomas at gmail.com]\n> Sent: Monday, July 21, 2014 6:16 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target \n> Question\n> \n> The iSCSI lun won\'t be set up until you try to attach the volume\n> \n> On 17 July 2014 12:44, Johnson Cheng <Johnson.Cheng at qsantechnology.com> wrote:\n> > Dear All,\n> >\n> >\n> >\n> > I installed iSCSI target at my controller node (IP: 192.168.106.20),\n> >\n> > #>iscsitarget open-iscsi iscsitarget-dkms\n> >\n> >\n> >\n> > then modify my cinder.conf at controller node as below,\n> >\n> > [DEFAULT]\n> >\n> > rootwrap_config = /etc/cinder/rootwrap.conf\n> >\n> > api_paste_confg = /etc/cinder/api-paste.ini\n> >\n> > #iscsi_helper = tgtadm\n> >\n> > iscsi_helper = ietadm\n> >\n> > volume_name_template = volume-%s\n> >\n> > volume_group = cinder-volumes\n> >\n> > verbose = True\n> >\n> > auth_strategy = keystone\n> >\n> > #state_path = /var/lib/cinder\n> >\n> > #lock_path = /var/lock/cinder\n> >\n> > #volumes_dir = /var/lib/cinder/volumes\n> >\n> > iscsi_ip_address=192.168.106.20\n> >\n> >\n> >\n> > rpc_backend = cinder.openstack.common.rpc.impl_kombu\n> >\n> > rabbit_host = controller\n> >\n> > rabbit_port = 5672\n> >\n> > rabbit_userid = guest\n> >\n> > rabbit_password = demo\n> >\n> >\n> >\n> > glance_host = controller\n> >\n> >\n> >\n> > enabled_backends=lvmdriver-1,lvmdriver-2\n> >\n> > [lvmdriver-1]\n> >\n> > volume_group=cinder-volumes-1\n> >\n> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n> >\n> > volume_backend_name=LVM_iSCSI\n> >\n> > [lvmdriver-2]\n> >\n> > volume_group=cinder-volumes-2\n> >\n> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n> >\n> > volume_backend_name=LVM_iSCSI_b\n> >\n> > [database]\n> >\n> > connection = mysql://cinder:demo at controller/cinder\n> >\n> >\n> >\n> > [keystone_authtoken]\n> >\n> > auth_uri = http://controller:5000\n> >\n> > auth_host = controller\n> >\n> > auth_port = 35357\n> >\n> > auth_protocol = http\n> >\n> > admin_tenant_name = service\n> >\n> > admin_user = cinder\n> >\n> > admin_password = demo\n> >\n> >\n> >\n> > Now I use the following command to create a cinder volume, and it \n> > can be created successfully.\n> >\n> > #> cinder create --volume-type lvm_controller --display-name vol 1\n> >\n> >\n> >\n> > Unfortunately it seems not attach to a iSCSI LUN automatically \n> > because I can not discover it from iSCSI initiator,\n> >\n> > #> iscsiadm -m discovery -t st -p 192.168.106.20\n> >\n> >\n> >\n> > Do I miss something?\n> >\n> >\n> >\n> >\n> >\n> > Regards,\n> >\n> > Johnson\n> >\n> >\n> >\n> >\n> >\n> > From: Manickam, Kanagaraj [mailto:kanagaraj.manickam at hp.com]\n> > Sent: Thursday, July 17, 2014 1:19 PM\n> >\n> >\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target \n> > Question\n> >\n> >\n> >\n> > I think, It should be on the cinder node which is usually deployed \n> > on the controller node\n> >\n> >\n> >\n> > From: Johnson Cheng [mailto:Johnson.Cheng at QsanTechnology.com]\n> > Sent: Thursday, July 17, 2014 10:38 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: [openstack-dev] [Cinder] Integrated with iSCSI target \n> > Question\n> >\n> >\n> >\n> > Dear All,\n> >\n> >\n> >\n> > I have three nodes, a controller node and two compute nodes(volume node).\n> >\n> > The default value for iscsi_helper in cinder.conf is ?tgtadm?, I \n> > will change to ?ietadm? to integrate with iSCSI target.\n> >\n> > Unfortunately I am not sure that iscsitarget should be installed at \n> > controller node or compute node?\n> >\n> > Have any reference?\n> >\n> >\n> >\n> >\n> >\n> > Regards,\n> >\n> > Johnson\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> \n> --\n> Duncan Thomas\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<1405957982.8270.1.camel@bluejungle.ibm.com>',NULL),('<03f799af160240f0bd9bdc5bd52db0a9@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 02:14:47',0,'2014-08-14 02:14:47',NULL,'[openstack-dev] [OpenStack-Infra] [infra] Third Party CI naming\n and contact (action	required)','Hi-\n\nI have updated the page for \'Freescale CI\'.\n\nNeed a change in the CI display name, Can you change \'Freescale CI\' to \'Freescale Neutron CI\'. \n\nHere is the page I added, https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI and the Index page https://wiki.openstack.org/wiki/ThirdPartySystems\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-----Original Message-----\nFrom: James E. Blair [mailto:corvus at inaugust.com] \nSent: Wednesday, August 13, 2014 11:54 PM\nTo: openstack-infra at lists.openstack.org\nCc: openstack-dev at lists.openstack.org\nSubject: [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)\n\nHi,\n\nWe\'ve updated the registration requirements for third-party CI systems\nhere:\n\n  http://ci.openstack.org/third_party.html\n\nWe now have 86 third-party CI systems registered and have undertaken an effort to make things more user-friendly for the developers who interact with them.  There are two important changes to be aware of:\n\n1) We now generally name third-party systems in a descriptive manner including the company and product they are testing.  We have renamed currently-operating CI systems to match these standards to the best of our abilities.  Some of them ended up with particularly bad names (like \"Unknown Function...\").  If your system is one of these, please join us in #openstack-infra on Freenode to establish a more descriptive name.\n\n2) We have established a standard wiki page template to supply a description of the system, what is tested, and contact information for each system.  See https://wiki.openstack.org/wiki/ThirdPartySystems for an index of such pages and instructions for creating them.  Each third-party CI system will have its own page in the wiki and it must include a link to that page in every comment that it leaves in Gerrit.\n\nIf you operate a third-party CI system, please ensure that you register a wiki page and update your system to link to it in every new Gerrit comment by the end of August.  Beginning in September, we will disable systems that have not been updated.\n\nThanks,\n\nJim\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n','<87oavoi6yu.fsf@meyer.lemoncheese.net>',NULL),('<03f799af160240f0bd9bdc5bd52db0a9@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-14 02:14:47',0,'2014-08-14 02:14:47',NULL,'[OpenStack-Infra] [infra] Third Party CI naming and contact\n (action	required)','Hi-\n\nI have updated the page for \'Freescale CI\'.\n\nNeed a change in the CI display name, Can you change \'Freescale CI\' to \'Freescale Neutron CI\'. \n\nHere is the page I added, https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI and the Index page https://wiki.openstack.org/wiki/ThirdPartySystems\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-----Original Message-----\nFrom: James E. Blair [mailto:corvus at inaugust.com] \nSent: Wednesday, August 13, 2014 11:54 PM\nTo: openstack-infra at lists.openstack.org\nCc: openstack-dev at lists.openstack.org\nSubject: [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)\n\nHi,\n\nWe\'ve updated the registration requirements for third-party CI systems\nhere:\n\n  http://ci.openstack.org/third_party.html\n\nWe now have 86 third-party CI systems registered and have undertaken an effort to make things more user-friendly for the developers who interact with them.  There are two important changes to be aware of:\n\n1) We now generally name third-party systems in a descriptive manner including the company and product they are testing.  We have renamed currently-operating CI systems to match these standards to the best of our abilities.  Some of them ended up with particularly bad names (like \"Unknown Function...\").  If your system is one of these, please join us in #openstack-infra on Freenode to establish a more descriptive name.\n\n2) We have established a standard wiki page template to supply a description of the system, what is tested, and contact information for each system.  See https://wiki.openstack.org/wiki/ThirdPartySystems for an index of such pages and instructions for creating them.  Each third-party CI system will have its own page in the wiki and it must include a link to that page in every comment that it leaves in Gerrit.\n\nIf you operate a third-party CI system, please ensure that you register a wiki page and update your system to link to it in every new Gerrit comment by the end of August.  Beginning in September, we will disable systems that have not been updated.\n\nThanks,\n\nJim\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n','<87oavoi6yu.fsf@meyer.lemoncheese.net>',NULL),('<03f817c4039bdd6b842ad58de6371277@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-23 10:56:22',7200,'2014-08-23 08:56:22',NULL,'[Openstack-docs] Reviewer change,\n release plan for clouddocs-maven-plugin','Le 2014-08-21 18:55, Anne Gentle a ?crit?:\n> Hi all,?\n> \n> Sam Harwell is a Rackspace developer helping us with the releases for\n> the stackforge/clouddocs-maven-plugin publication tool. Today he?added\n> openstack-doc-core to clouddocs-maven-plugin-core so that the\n> OpenStack docs-core team can review patches\n> in?stackforge/clouddocs-maven-plugin?and +2 them and merge as needed.\n> \n> Sam still does the actual release steps, so I\'m working with him now\n> to get the next grouping together. Here\'s what I\'m proposing for the\n> next release by 8/31:\n> \n> Must haves:\n> API References: Add the title of the service\n> Add fanatiguy to Rackspace API Ref\n> Fix css padding-top for Rackspace output\n> \n> Must haves (need updates):\n> Add support for yaml syntax\n> highlighting:?https://review.openstack.org/#/c/111219/1 [1]\n\nI\'m not sure that this needs an update, unless I missed something. The \nlicensing question seems resolved, right?\n\nGauvain\n\n\n> \n> Nice to haves:\n> Allow error phrase to be listed with response code:\n> https://review.openstack.org/106173 [2]\n> \n> Epub fixes:?https://review.openstack.org/#/c/107825/ [3]\n> \n>  Let me know if you have any questions.?\n> Anne\n> \n> Links:\n> ------\n> [1] https://review.openstack.org/#/c/111219/1\n> [2] https://review.openstack.org/106173\n> [3] https://review.openstack.org/#/c/107825/\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<CAD0KtVGv+-VP7LKCy7ms6DLt5fZGeWu9AwfR4PCXYkjJAR69gQ@mail.gmail.com>',NULL),('<03fb01cf10ab$cf7ef610$6e7ce230$@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 11:07:07',46800,'2014-01-13 22:07:07',NULL,'[openstack-dev] [climate][cafe] Climate and Cafe teams meeting','Hi guys,\n\n \n\nThanks for accommodating to our time. UTC 0600 sounds good for us. I was\nwondering if Friday (17th Jan) UTC 0600 will be a good time for everyone\nelse?\n\n \n\nCheers,\n\nAlan\n\n \n\n \n\nDate: Mon, 13 Jan 2014 19:52:28 +0400\n\nFrom: Dina Belova <dbelova at mirantis.com <mailto:dbelova at mirantis.com> >\n\nTo: \"OpenStack Development Mailing List (not for usage questions)\"\n\n                <openstack-dev at lists.openstack.org\n<mailto:openstack-dev at lists.openstack.org> >\n\nSubject: Re: [openstack-dev] [climate][cafe] Climate and Caf? teams\n\n                meeting\n\nMessage-ID:\n\n \n<CACsCO2zx6WEzkZnBEU5040fUeF91dDX27OA6nN08KpCeqN3tmQ at mail.gmail.com\n<mailto:CACsCO2zx6WEzkZnBEU5040fUeF91dDX27OA6nN08KpCeqN3tmQ at mail.gmail.com>\n>\n\nContent-Type: text/plain; charset=\"iso-8859-1\"\n\n \n\nGuys from Cafe command are from New Zealand - UTC+13 :)\n\n \n\n \n\nOn Mon, Jan 13, 2014 at 6:58 PM, Sergey Lukjanov\n\n<slukjanov at mirantis.com <mailto:slukjanov at mirantis.com> >wrote:\n\n \n\n> Are there any guys from PST timezone?\n\n> \n\n> \n\n> On Mon, Jan 13, 2014 at 5:32 PM, Sylvain Bauza\n\n<sylvain.bauza at gmail.com <mailto:sylvain.bauza at gmail.com> >wrote:\n\n> \n\n>> I can propose anytime at 0600 UTC, I can make efforts for waking up \n\n>> earlier :-) I can yet understand that other EU people couldn\'t attend \n\n>> the call, so I will aggregate and feedback all the topics for my \n\n>> French peers.\n\n>> \n\n>> -Sylvain\n\n>> \n\n>> \n\n>> 2014/1/13 Nikolay Starodubtsev <nstarodubtsev at mirantis.com\n<mailto:nstarodubtsev at mirantis.com> >\n\n>> \n\n>>> Hi, all!\n\n>>>  Guys, both our teams (Climate and Cafe) want to make a cross-team \n\n>>> meeting to discuss our future plans. If you want to participate \n\n>>> please\n\ntip\n\n>>> us with good time for you.\n\n>>> \n\n>>> Useful links:\n\n>>> * Climate https://launchpad.net/climate\n\n>>> * Cafe https://wiki.openstack.org/wiki/Cafe\n\n>>> \n\n>>> \n\n>>> \n\n>>> \n\n>>> Nikolay Starodubtsev\n\n>>> \n\n>>> Software Engineer\n\n>>> \n\n>>> Mirantis Inc.\n\n>>> \n\n>>> \n\n>>> Skype: dark_harlequine1\n\n>>> \n\n>>> _______________________________________________\n\n>>> OpenStack-dev mailing list\n\n>>> OpenStack-dev at lists.openstack.org\n<mailto:OpenStack-dev at lists.openstack.org> \n\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n>>> \n\n>>> \n\n>> \n\n>> _______________________________________________\n\n>> OpenStack-dev mailing list\n\n>> OpenStack-dev at lists.openstack.org\n<mailto:OpenStack-dev at lists.openstack.org> \n\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n>> \n\n>> \n\n> \n\n> \n\n> --\n\n> Sincerely yours,\n\n> Sergey Lukjanov\n\n> Savanna Technical Lead\n\n> Mirantis Inc.\n\n> \n\n> _______________________________________________\n\n> OpenStack-dev mailing list\n\n> OpenStack-dev at lists.openstack.org\n<mailto:OpenStack-dev at lists.openstack.org> \n\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n> \n\n> \n\n \n\n \n\n-- \n\n \n\nBest regards,\n\n \n\nDina Belova\n\n \n\nSoftware Engineer\n\n \n\nMirantis Inc.\n\n \n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/88324208/attachment.html>\n\n',NULL,NULL),('<03FC2583-79C1-40DA-ADDB-2E7D0233CE3E@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 14:38:15',25200,'2014-02-26 07:38:15',NULL,'[openstack-dev] [Mistral] Renaming action types','Folks,\n\nI?m proposing to rename these two action types REST_API and MISTRAL_REST_API to HTTP and MISTRAL_HTTP. Words ?REST? and ?API? don?t look correct to me, if you look at\n\nServices:\n  Nova:\n    type: REST_API\n    parameters:\n      baseUrl: {$.novaURL}\n    actions:\n      createVM:\n        parameters:\n          url: /servers/{$.vm_id}\n          method: POST\n   \nThere?s no information about ?REST? or ?API? here. It?s just a spec how to form an HTTP request.\n\nThoughts?\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140226/60d30a31/attachment.html>\n\n',NULL,NULL),('<0412823C-4C18-474D-A456-150B20D5B575@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-01 17:09:17',-28800,'2013-03-02 01:09:17',NULL,'[openstack-dev] [Oslo] FFE request for memorycache','Yes, please, +1\n\nOn Mar 1, 2013, at 5:06 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n\n> Hi everyone,\n> \n> Based on feedback from my other email[1] it sounds like the best plan is to move memorycache into oslo and sync it. Since this is officially a new feature it needs an FFE, so I\'d like to request one. It is just a move of code from nova and it causes a noticable performance improvement. Doing it through oslo saves us from the technical debt of duplicated code in multiple projects.\n> \n> Vish\n> \n> [1] http://lists.openstack.org/pipermail/openstack-dev/2013-March/006146.html\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<97D686F7-843B-4998-915C-ACA3589B2A97@gmail.com>',NULL),('<04175F89-D59B-475A-ADB9-0678748F23B8@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-01-12 16:56:08',3600,'2013-01-12 15:56:08',NULL,'[Openstack-docs] Happy new year Openstack doc\'ers','Something unique for that year, that is an excellent question....leme think about it hehe\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 12 janv. 2013 ? 16:31, Anne Gentle <anne at openstack.org> a ?crit :\n\n> Happy New Year to all of you and yours as well! 2013, the first year with all unique numbers since 1987, what can we make of it? \n> \n> Anne\n> \n> \n> On Fri, Jan 11, 2013 at 7:01 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n> A bit late, \n> but both heart and intention are there :)\n> \n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130112/e3735636/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130112/e3735636/attachment-0001.jpg>\n\n','<CAD0KtVGPBg6ZjLBup27xNjgk6hLBS9XcaQOuDhiYpTborT0Dww@mail.gmail.com>',NULL),('<041BF604-6F91-4115-9B8A-21143293FC9F@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-04 16:26:19',32400,'2013-12-04 07:26:19',NULL,'[Openstack] instance block migration','you have to turn off the ?config disk? feature in nova.conf \n\n2013. 12. 4., ?? 7:41, Paras pradhan <pradhanparas at gmail.com> ??:\n\n> I have this flag in compute nodes\' nova.conf file\n> \n> --\n> block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC\n> --\n> \n> When I try to migrate an instance I see the following error. Basically it says the instance\'s files are not found in destination compute node. Should\'nt it copy and create it self?\n> \n> Stderr: \"qemu-nbd: Failed to bdrv_open \'/var/lib/nova/instances/ae8b4bb2-1c87-46d5-9e75-b6f5a619d6ca/disk\': No such file or directory\\n\"\n> \n> \n> What am I missing?\n> \n> Thanks\n> Paras.\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<CADyt5gk3hRnSTp+3ywc8syYAkMt5HnvJep0tDhKWqvfoS9NHPA@mail.gmail.com>',NULL),('<04206E84-31C5-4258-ACFD-B055F0A9EFA1@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 14:17:17',-25200,'2014-05-20 21:17:17',NULL,'[openstack-dev] [Mistral] Mistral roadmap notes,\n	from Atlanta summit (rough)','We shared and discussed the directions on Mistral development session,\nand work through the list of smaller post POC steps, placing them on the roadmap.\n\nThe notes are here: https://etherpad.openstack.org/p/juno-summit-mistral.\nRenat and I developed shared understanding on most of them. \n\nNext steps: create the blueprints, prioritize, implement. \n\nDZ.\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/115dc900/attachment.html>\n\n',NULL,NULL),('<0420FA25-FFD8-4E32-86D4-AC7FC2C6825A@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 22:31:10',-18000,'2013-11-05 03:31:10',NULL,'[openstack-dev] [Solum] Choice of API infrastructure','\n\n> On Nov 5, 2013, at 11:26 AM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n> \n> \n> \n> \n>> On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>> Doug, I respect you very much as an engineer and as a community member, so I want to preface this with a very important dislaimer: don\'t take these opinions as anything more than what they are...a discussion of differing viewpoints.\n> \n> Ditto. :-)\n>  \n>> \n>> Comments inline.\n>> \n>> \n>>> On 11/04/2013 06:58 PM, Doug Hellmann wrote:\n>>> On Sun, Nov 3, 2013 at 10:54 PM, Jay Pipes <jaypipes at gmail.com\n>>> <mailto:jaypipes at gmail.com>> wrote:\n>>> \n>>>     On 11/02/2013 11:26 PM, Russell Bryant wrote:\n>>> \n>>>         On 11/02/2013 11:54 AM, Adrian Otto wrote:\n>>> \n>>>             Noorul,\n>>> \n>>>             I agree that key decisions should be tracked in blueprints.\n>>>             This is the\n>>>             one for this decision which was made in our 2013-10-18\n>>>             public meeting.\n>>>             Jay\'s submission is consistent with the direction indicated\n>>>             by the team.\n>>> \n>>>             https://blueprints.launchpad.__net/solum/+spec/rest-api-base\n>>>             <https://blueprints.launchpad.net/solum/+spec/rest-api-base>\n>>> \n>>>             Transcript log:\n>>>             http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html\n>>>             <http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html>\n>>>             <http://irclogs.solum.io/2013/__solum.2013-10-08-16.01.log.__html\n>>> \n>>>             <http://irclogs.solum.io/2013/solum.2013-10-08-16.01.log.html>>\n>>> \n>>> \n>>>         Heh, not much discussion there.  :-)\n>>> \n>>> \n>>>     Agreed. I actually didn\'t know anything about the discussion -- I\n>>>     wasn\'t at the meeting. I just figured I would throw some example\n>>>     code up to Gerrit that shows how Falcon can be used for the API\n>>>     plumbing. Like I mentioned in a previous email, I believe it\'s much\n>>>     easier to discuss things when there is sample code...\n>>> \n>>> \n>>>         Here\'s my take ... Pecan+WSME has been pushed as the thing to\n>>>         standardize on across most OpenStack APIs.  Ceilometer (and maybe\n>>>         others?) are already using it.  Others, such as Nova, are\n>>>         planning to\n>>>         use it this cycle. [1][2]\n>>> \n>>> \n>>>     I\'ve used both actually, and I\'ve come to prefer Falcon because of\n>>>     its simplicity and specifically because of the following things:\n>>> \n>>>     * It\'s lack of integration with WSME, which I don\'t care for. I\n>>>     don\'t care for WSME because I believe it tries to put the model at\n>>>     the view layer, instead of where it belongs, at the model layer.\n>>> \n>>> \n>>> The \"models\" defined in WSME are completely different from the database\n>>> models, and should not be used outside of the API code. Think of them as\n>>> declaring the models for the consumer of the API, rather than the\n>>> implementer of the API.\n>> \n>> I don\'t really see the point of the distinction. At the end of the day, the consumer of the API is using the API to manipulate and retrieve data. That data is really the model, with some syntactic sugar like Atom links, etc. Even in a control API -- as opposed to a data API like Glance, Ceilometer or Swift -- the benefits of a heavy API layer like Pecan and WSME are pretty small, IMO.\n> \n> That approach binds your API tightly to the database representation, which we were trying to avoid.\n>  \n>> \n>> I would much rather see the Ceilometer models [1] actually be models that can validate the data that is used to construct the model object instead of having duplicated WSME \"models\" repeated in the WSGI controller code [2]. The reason is because if/when I decide to make a Ceilometer API that uses a different protocol, say AMQP, instead of HTTP, now I need to duplicate all of the validation code that WSME is providing on the data model layer... however if the validation was in the models themselves, I could easily create an API on a different protocol using just the models for validation.\n> \n> We do that in some cases. However, there is also a difference in some cases between the validation at the API layer (a value must be a number, or a UUID, etc.) and the validation in the database layer (a number must fall within a range or a UUID must refer to an existing object). So there is a place for both, and the validation done in the WSME classes is not meant to be the only validation performed.\n\n+1 here - translation of a string to a uuid for use with a domain model is a good example of why a view model and a domain model exist.  This is a practical concern that almost always comes up during API evolution.\n\n>  \n>> \n>> \n>>> The benefits of declaring WSME classes include automatic serialization\n>>> in JSON and XML, generating WADL files to be included in the API docs\n>>> (work is already happening to make this available for everyone), and\n>>> consistent input and output types for API endpoints (making it easier\n>>> for consumers of the API to use it and for implementers to validate\n>>> inputs and assume consistent defaults).\n>> \n>> I can\'t stand XML. I believe it should be retired to the dustbin of coding history, like Basic.\n> \n> You\'ve made that clear in the past. :-) I agree, for what it\'s worth. Some of our users do seem to want it, and with WSME *you don\'t have to care*.\n>  \n>> \n>> That said, consumers of a RESTful API don\'t care how the API is implemented. They care that it\'s documented and consistent, and if WSME makes API documentation easier, then that\'s A Good Thing, agreed.\n>> \n>> It\'s true that WSME includes some stuff to make validating inputs \"easier\", but it does so, IMHO, at the expense of readability because everything is decorated and hidden away somewhere other than the models themselves. See note above...\n> \n> I\'m not sure what that means. Hidden where? The validation is either described in the attribute specifier for the model, or in the model\'s class, or in the controller (depending on the scope of the rule being applied). \n>  \n>> \n>> \n>>> And, to be clear, Pecan and WSME are integrated by Pecan can definitely\n>>> be used without WSME. I included WSME in the proposal to replace the\n>>> home-grown WSGI framework because I thought it added significant\n>>> benefits, but it is not going to be appropriate for all situations\n>>> (streaming large image files is one example).\n>>> \n>>>     * It doesn\'t need a configuration file, specifically a configuration\n>>>     file that is a Python file as opposed to an .ini file.\n>>> \n>>> Pecan does not require a configuration file. It can use one, but we set\n>>> up the WSGI app factory in ceilometer to not use one and I expect the\n>>> other projects to work the same way.\n>> \n>> OK, that\'s good to know.\n>> \n>> Here\'s a third reason I don\'t care for Pecan/WSME: it uses Webob. Other than eventlet, I don\'t know of a single library that OpenStack projects have used over the years that we\'ve had more issues with than Webob.\n> \n> Yes, I felt the pain of updating us to the latest WebOb. The project has evolved since those days, and the current maintainers are committed to not breaking the API. That new attitude, combined with the long history of addressing edge cases from misbehaving web client libraries makes m e less reluctant to use WebOb than in the past.\n>  \n>> \n>> \n>>> Tuesday (today) at 2:00 there is a session in the Oslo track\n>>> (http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee)\n>>> to discuss tips and pain points with Pecan & WSME.\n>> \n>> Unfortunately, I won\'t be at the summit. :(\n> \n> OK, we\'ll be updating the etherpad and obviously we can continue this via email.\n>  \n>> \n>> \n>> >I didn\'t intend to\n>>> revisit the decision to start adopting either (we\'ve spent an hour at\n>>> each of the last summits going over that, as well as many email\n>>> threads),\n>> \n>> Yeah, you know the argument that a couple dozen folks have discussed something at one or two of the past summits and therefore it should be considered settled fact is a bit annoying to me.\n> \n> \"as well as many email threads\".\n>  \n>> \n>> Partly it is annoying because the summit has a vast number of sessions, with many tracks going simultaneously, making it impossible to get to all the sessions that people feel strongly about. I wish I could have been at several design summit discussions, especially around database issues, at the last couple summits, but I was in the QA track most of the summit, for good or bad.\n> \n> Yep. There is not a single time slot this week where I don\'t want to be in fewer than 3 places at one time.\n>  \n>> \n>> Secondly, it is the sign of strength that a contributor community consider -- and continually consider -- alternative libraries or implementations of various things. Change is good, and projects that are just starting off are a good place to experiment with newer libraries and see if something is better than what existed previously. I seem to remember that was your position on Pecan when the community was considering whether to standardize on some WSGI pipeline. Why didn\'t you just use what was in other projects instead of Pecan and WSME? Likely the same reasons that I\'m saying \"let\'s give Falcon a chance\".\n> \n> My main arguments were \"do not build something new from scratch when there are working tools\" and \"the existing library is too hard to use\". We can argue about whether Falcon or Pecan solves the second issue better, but Pecan was used in production deployments far earlier than Falcon even existed.\n>  \n>> \n>> I believe we discussed why Bazaar and Launchpad merge proposals were the code contribution platform at length for the Austin, Bexar and Cactus summits, with GitHub fans at every one of those discussions, and lo and behold, the community switched to Git and GitHub and Gerrit during the Diablo timeframe. So, long story short, stuff changes, opinions change, and that\'s totally fine...\n> \n> Agreed.\n> \n> Doug\n>  \n>> \n>> \n>> > but I do want to clear up any other misconceptions and discuss\n>>> issues with either tool so that feedback can be incorporated upstream.\n>>> Now that both Pecan and WSME are on stackforge, we have already had a\n>>> few patches from OpenStack developers intended to improve and adjust\n>>> them to meet our needs better.\n>> \n>> I think that is a fine thing to continue, and I don\'t believe this particular debate by the Solum project should affect that at all.\n>> \n>> Best,\n>> -jay\n>> \n>> [1] https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/models.py\n>> [2] https://github.com/openstack/ceilometer/blob/master/ceilometer/api/controllers/v2.py\n>> \n>>> Doug\n>>> \n>>> \n>>> \n>>>         I care less about the particular choice and more about\n>>>         consistency.  It\n>>>         brings a lot of value, such as making it a lot easier for\n>>>         developers to\n>>>         jump around between the OpenStack projects.  Can we first at\n>>>         least agree\n>>>         that there is value in standardizing on *something* for most\n>>>         OpenStack APIs?\n>>> \n>>> \n>>>     I completely understand the need for consistency. I pushed my patch\n>>>     as an example of how to do things the Falcon way. While I would\n>>>     prefer Falcon over Pecan (and certainly over Pecan+WSME), I will\n>>>     respect the push towards consistency if that\'s what is most important.\n>>> \n>>>     That said, I also believe that the projects in Stackforge should be\n>>>     the \"laboratories of experiment\", and these projects may serve as a\n>>>     good playground for various implementations of things. I remind the\n>>>     reader that over time, the development community has standardized on\n>>>     various things, only to find a better implementation in an incubated\n>>>     project. Pecan+WSME is actually an example of that experimentation\n>>>     turned accepted standard.\n>>> \n>>> \n>>>     Best,\n>>>     -jay\n>>> \n>>> \n>>>         I understand that there may be cases where the needs for an API\n>>>         justify\n>>>         being different.  Marconi being more of a data-plane API vs\n>>>         control-plane means that performance concerns are much higher,\n>>>         for example.\n>>> \n>>>         If we agree that consistency is good, does Solum have needs that\n>>>         make it\n>>>         different than the majority of OpenStack APIs?  IMO, it does not.\n>>> \n>>>         Can someone lay out a case for why all OpenStack projects should be\n>>>         using Falcon, if that\'s what you think Solum should use?\n>>> \n>>>         Also, is anyone willing to put up the equivalent of Jay\'s review\n>>>         [3],\n>>>         but with Pecan+WSME, to help facilitate the discussion?\n>>> \n>>>         [1]\n>>>         http://icehousedesignsummit.__sched.org/event/__b2680d411aa7f5d432438a435ac21f__ee\n>>>         <http://icehousedesignsummit.sched.org/event/b2680d411aa7f5d432438a435ac21fee>\n>>>         [2]\n>>>         http://icehousedesignsummit.__sched.org/event/__4a7316a4f5c6f783e362cbba2644ba__e2\n>>>         <http://icehousedesignsummit.sched.org/event/4a7316a4f5c6f783e362cbba2644bae2>\n>>>         [3] https://review.openstack.org/#__/c/55040/\n>>>         <https://review.openstack.org/#/c/55040/>\n>>> \n>>> \n>>> \n>>>     _________________________________________________\n>>>     OpenStack-dev mailing list\n>>>     OpenStack-dev at lists.openstack.__org\n>>>     <mailto:OpenStack-dev at lists.openstack.org>\n>>>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>>> \n>>> \n>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131104/ad21d7f1/attachment.html>\n\n','<CADb+p3Sd8ABDxCLcGb1GdebW9jmNBX3-9UZZqvP9_Zw4ecfM2Q@mail.gmail.com>',NULL),('<042301cdddee$381b7190$a85254b0$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-19 17:39:04',14400,'2012-12-19 13:39:04',NULL,'[openstack-dev] [quantum][LBaaS] need to do carresponding changes\n	in LBaaS API doc','Hi Youcef,\n\n \n\nNow after LBaaS API extension patch was merged we need to do several\ncorresponding changes in the API doc. \n\nI can do it if you provide me rights on editing the page\n(http://wiki.openstack.org/Quantum/LBaaS/API_1.0).\n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121219/412cfea1/attachment.html>\n\n',NULL,NULL),('<0426566C-AC83-4F53-B325-6E7A9782B030@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 20:37:27',25200,'2014-03-17 13:37:27',NULL,'[openstack-dev] [Mistral][Taskflow][all] Mistral + taskflow','Left my comments in https://etherpad.openstack.org/p/taskflow-mistral.\n\n@Changbin, I think the most interesting section for you is ?What?s Different?. Thanks. Hope this helps. If it doesn?t then let us know your specific questions.\n\n@Joshua, thanks for your input on architecture. At a high-level it makes sense. We need to keep discussing it and switch to details. For that reason, like I said before, we want to create a very very simple taskflow based prototype (in progress). Then we?ll have a chance to think how to evolve TaskFlow properly so that it fits Mistral needs.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\nOn 15 Mar 2014, at 00:31, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n\n> Sure, I can try to help,\n> \n> I started https://etherpad.openstack.org/p/taskflow-mistral so that we can all work on this.\n> \n> Although I\'d rather not make architecture for mistral (cause that doesn\'t seem like an appropriate thing to do, for me to tell mistral what to do with its architecture), but I\'m all for working on it together as a community (instead of me producing something that likely won\'t have much value).\n> \n> Let us work on the above etherpad together and hopefully get some good ideas flowing :-)\n> \n> From: Stan Lagun <slagun at mirantis.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Date: Friday, March 14, 2014 at 12:11 AM\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Mistral][Taskflow][all] Mistral + taskflow\n> \n>> Joshua,\n>> \n>> why wait? Why not just help Renat with his research on that integration and bring your own vision to the table? Write some 1-page architecture description on how Mistral can be built on top of TaskFlow and we discuss pros and cons. In would be much more productive.\n>> \n>> \n>> On Fri, Mar 14, 2014 at 11:35 AM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>>> Thanks Renat,\n>>> \n>>> I\'ll keep waiting, and hoping that we can figure this out for everyone\'s benefit. Because in the end we are all much stronger working together and much weaker when not.\n>>> \n>>> Sent from my really tiny device...\n>>> \n>>> On Mar 13, 2014, at 11:41 PM, \"Renat Akhmerov\" <rakhmerov at mirantis.com> wrote:\n>>> \n>>>> Folks,\n>>>> \n>>>> Mistral and TaskFlow are significantly different technologies. With different set of capabilities, with different target audience.\n>>>> \n>>>> We may not be doing enough to clarify all the differences, I admit that. The challenge here is that people tend to judge having minimal amount of information about both things. As always, devil in the details. Stan is 100% right, ?seems? is not an appropriate word here. Java seems to be similar to C++ at the first glance for those who have little or no knowledge about them.\n>>>> \n>>>> To be more consistent I won?t be providing all the general considerations that I?ve been using so far (in etherpads, MLs, in personal discussions), it doesn?t seem to be working well, at least not with everyone. So to make it better, like I said in that different thread: we?re evaluating TaskFlow now and will share the results. Basically, it?s what Boris said about what could and could not be implemented in TaskFlow. But since the very beginning of the project I never abandoned the idea of using TaskFlow some day when it?s possible. \n>>>> \n>>>> So, again: Joshua, we hear you, we?re working in that direction.\n>>>> \n>>>>>>>> \n>>>>>>>> I\'m reminded of\n>>>>>>>> http://www.slideshare.net/RenatAkhmerov/mistral-hong-kong-unconference-trac\n>>>>>>>> k/2 where it seemed like we were doing much better collaboration, what has\n>>>>>>>> happened to break this continuity?\n>>>> \n>>>> Not sure why you think something is broken. We just want to finish the pilot with all the ?must? things working in it. This is a plan. Then we can revisit and change absolutely everything. Remember, to the great extent this is research. Joshua, this is what we talked about and agreed on many times. I know you might be anxious about that given the fact it?s taking more time than planned but our vision of the project has drastically evolved and gone far far beyond the initial Convection proposal. So the initial idea of POC is no longer relevant. Even though we finished the first version in December, we realized it wasn?t something that should have been shared with the community since it lacked some essential things.\n>>>> \n>>>> \n>>>> Renat Akhmerov\n>>>> @ Mirantis Inc.\n>>>> \n>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> \n>> \n>> -- \n>> Sincerely yours\n>> Stanislav (Stan) Lagun\n>> Senior Developer\n>> Mirantis\n>> 35b/3, Vorontsovskaya St.\n>> Moscow, Russia\n>> Skype: stanlagun\n>> www.mirantis.com\n>> slagun at mirantis.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/a5122c1a/attachment.html>\n\n','<CF488987.597EA%harlowja@yahoo-inc.com>',NULL),('<0427B3D3-46F8-4C10-87D5-6B8C07075196@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 10:04:49',-14400,'2014-09-18 14:04:49',NULL,'[openstack-dev] Oslo final releases ready','All of the final releases for the Oslo libraries for the Juno cycle are available on PyPI. I?m working on a couple of patches to the global requirements list to update the baseline in the applications. In all cases, the final release is a second tag on a previously released version.\n\n- oslo.config - 1.4.0 (same as 1.4.0.0a5)\n- oslo.db - 1.0.0 (same as 0.5.0)\n- oslo.i18n - 1.0.0 (same as 0.4.0)\n- oslo.messaging - 1.4.0 (same as 1.4.0.0a5)\n- oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3)\n- oslo.serialization - 1.0.0 (same as 0.3.0)\n- oslosphinx - 2.2.0 (same as 2.2.0.0a3)\n- oslotest - 1.1.0 (same as 1.1.0.0a2)\n- oslo.utils - 1.0.0 (same as 0.3.0)\n- cliff - 1.7.0 (previously tagged, so not a new release)\n- stevedore - 1.0.0 (same as 1.0.0.0a2)\n\nCongratulations and *Thank You* to the Oslo team for doing an amazing job with graduations this cycle!\n\nDoug\n\n\n\n',NULL,NULL),('<042B604BD713B94BA623CDC4C38576E7F553F0@G5W2718.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 11:07:45',0,'2013-10-14 11:07:45',NULL,'[openstack-dev] [Swift] container forwarding/cluster\n	federation	blueprint','Hi,\n\nWith a global cluster, you can have your replicas stored in different regions within your cluster whereas container forwarding is about storing all objects within a container in a different swift cluster than the one you contacted in the first place.  These two clusters could well be co-located.  The swift cluster forwarded to may have a different replica count than the other clusters so that you can provide different QoS for different containers or it may just be there to give you extra space to accommodate a large account across several clusters but within a single namespace. The forwarding is happening between proxies of the clusters involved and each cluster is a regular cluster with its own configuration.\n\nMore details on container-forwarding  can be found in this wiki page:\n\nhttps://wiki.openstack.org/wiki/Swift/ClusterFederationBlueprint\n\nEric\n\nOn 14/10/2013 03:31, Sam Morrison wrote:\nHi,\n\nI\'d be interested in the differences this has to using swift global clusters?\n\nCheers,\nSam\n\n\n\nOn 12/10/2013, at 3:49 AM, \"Coles, Alistair\" <alistair.coles at hp.com<mailto:alistair.coles at hp.com>> wrote:\n\nWe?ve just committed a first set of patches to gerrit that address this blueprint:\n\nhttps://blueprints.launchpad.net/swift/+spec/cluster-federation\n\nQuoting from that page: ?The goal of this work is to enable account contents to be dispersed across multiple clusters, motivated by (a) accounts that might grow beyond the remaining capacity of a single cluster and (b) clusters offering differentiated service levels such as different levels of redundancy or different storage tiers. Following feedback at the Portland summit, the work is initially limited to dispersal at the container level, i.e. each container within an account may be stored on a different cluster, whereas every object within a container will be stored on the same cluster.?\n\nIt is work in progress, but we?d welcome feedback on this thread, or in person for anyone who might be at the hackathon in Austin next week.\n\nThe bulk of the new features are in this patch:\nhttps://review.openstack.org/51236 (Middleware module for container forwarding.)\n\nThere?s a couple of patches refactoring/adding support to existing modules:\nhttps://review.openstack.org/51242 (Refactor proxy/controllers obj & base http code)\nhttps://review.openstack.org/51228 (Store x-container-attr-* headers in container db.)\n\nAnd some tests?\nhttps://review.openstack.org/51245 (Container-forwarding unit and functional tests)\n\n\nRegards,\nAlistair Coles, Eric Deliot, Aled Edwards\n\nHP Labs, Bristol, UK\n-------------------------\nHewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN . Registered No: 690597 England\nThe contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender.\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n',NULL,NULL),('<042B604BD713B94BA623CDC4C38576E7F7746D@G5W2718.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-08 16:56:32',0,'2013-11-08 16:56:32',NULL,'[openstack-dev] [Swift] cluster federation: Austin hackathon\n	follow-up','Hi,\n\nJust before the Austin hackathon, we uploaded 5 patches related to the cluster federation blueprint\n\nhttps://blueprints.launchpad.net/swift/+spec/cluster-federation\n\none of those patches, https://review.openstack.org/51242 dealt with the mechanics of forwarding data from a middleware component to/from a different cluster.  This patch had two goals:\n1. Maximize code reuse while minimizing core code change: any new code is simple and doesn\'t impact connection management, or  the way the core handles data proxying between connections.\n2. Refactor at the level of the ring and introduce the concept of a TargetRing to show that container-forwarding can be seen as a kind of storage policy while, again, minimizing core code change.\n\nI have just pushed a new patch, https://review.openstack.org/55674  which presents an alternative way to achieve the code reuse objective by creating a swift/common/http_utils module that can be used by both middleware and core proxy-server code (and possibly other code as well such as backend daemons, container-sync being a possible candidate).\nLike the first patch, it also includes a very basic piece of middleware that forwards all requests to a configured target cluster.\n\nI am including more details about the patch further down so if you\'re interested, please keep reading.\n\nI am interested in finding out which approach people prefer and get feedback on the patch itself.\n\nEric\n\n\nMore details\n--\nMost of the code complexity in http_utils comes from the fact that for object PUT data must be transferred between the client connection and the backends/target connection and, at the moment, this uses decoupling queues and extra threads to produce to / consume from the queues.  It is basically very close to the code from helper methods already in base.py and obj.py so reusing the code from http_utils in proxy-server means that the following code can be removed (only commented out for now):\nbase.py:  _make_app_iter\nobj.py: _send_file plus a chunk of code embedded in PUT\n\nUnlike the previous patch, this alternative patch has basic support for ssl based on the httplib.HTTPSConnection class used by bufferedhttp.py.  It may form a good basis for more generic use, in particular by the container-sync daemon which must interact with proxies from other clusters.  I understand there is a wish to remove the dependency on swiftclient in this daemon and the code in http_utils could be a good step forward towards that objective.\n\nBoth patches rely on a callback from proxy/server.py (just like already exists for calling back the authorization middleware) to give  a handle on the controller object that is created anew for each request.  The app given to a middleware at instantiation time is the next filter in the pipeline and only maps to the proxy-server application if the middleware is placed just before proxy-server in the paste-deploy config pipeline.  As far as I know, a callback from server.py is the only way a middleware can have a handle on proxy-server or a controller while being flexible about its placement in the pipeline.\nIn the case of the original patch, the handle on the controller is needed to be able to call reused controller methods such as make_requests, etc.  In the case of the alternative patch, only a handle on the proxy-server application is needed for http purposes so that configuration values (timeouts, queue depth, etc.) can be reused.  However, in both cases, a fully functional container-forwarding will require a handle on the controller to implement complex multi-container use cases (COPY, SLO, DLO, versioning) where forwarded containers could reside in different clusters.\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131108/d65494ad/attachment.html>\n\n',NULL,NULL),('<0431A635-AE6A-4EFC-9BE4-C940ACBB1540@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-19 15:06:26',0,'2013-07-19 15:06:26',NULL,'[openstack-dev] [Heat] Long-term,\n how do we make heat image/flavor name agnostic?','Gabriel,\n\nOn Jul 18, 2013, at 5:18 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:\n\n> Generally spot-on with what Adrian said, but I have one question from that email:\n> \n>> Mappings is one of the high level concepts in CFN that I think can be\n>> completely eliminated with auto-discovery.\n> \n> What do you mean by this? What kind of autodiscovery, and where? I\'m all for eliminating mappings someday if possible, but I haven\'t heard this proposal before. Enlighten me?\n\nThe concept works by using a set of declared requirements, which are matched by the model interpreter in the orchestration system to resources/services that provide them. For example, one template may declare that it needs \"linux\", and the resource/service Nova can provide that.\n\nThis is something that has been worked on quite a bit in the open standards community. Namely, both the TOSCA and CAMP spec drafts have these concepts to some extent.\n\nAFAIK, Heat does not yet have a sophisticated model interpreter, so this concept is something that we could iterate towards over time. What I am sure exists today is that resources have specific names that you can use to order any of the OpenStack services. You can declare you want a particular resource name when authoring your template. This does work within a single cloud, but it does not eliminate the need for mappings in order to make anything portable, because there is no guarantee that the resource name will exist innaother cloud, or that it will work the same.\n\nThere is more to this concept than what fits in a couple of paragraphs, but this should give you a general idea.\n\nAdrian\n\n','<f09379424c3849078bd292d22b7bd964@BN1PR05MB169.namprd05.prod.outlook.com>',NULL),('<043B56D0417E4D80A1950BAD955DAFF6@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-31 10:16:56',-14400,'2012-10-31 14:16:56',NULL,'[openstack-dev] Configuration Options, APIs, Class Paths, Oh my!','> \n> So that\'s the problem. You are expecting these APIs to be stable, at\n> least within a release. We are doing absolutely nothing to ensure that\n> is the case right now. The fact that these config options were there\n> gave you that expectation, which is unfortunate, and I\'d like to fix it.\n> \nForking is such a better option?  Stability of the API is secondary to its availability.\n\nOnce a stable release is made, I don\'t expect significant changes due to the general contract of what \'stable\' implies. However, I don\'t expect there won\'t be a change, either. If this needs to be documented and clarified, fine.\n\nAs for Cloudscaling, we\'ve run our own custom schedulers, networking code, and queuing/rpc mechanism through Nova\'s *_backend options. This has allowed us to address deficits in the stable releases within the context of our customer deployments. Many of those improvements were then rolled into the next-stable release.\n\nFor instance, a number of scheduler improvements we had been running in-house against Essex were eliminated through the release of general host aggregates and aggregate-based scheduling.  Of course, we\'re also using the ZeroMQ driver, which we rolled-out as a plugin against stable for Essex, prior to being merged into Folsom.\n\nMy design intention for the matchmaker, which the ServiceGroup API might prove to eliminate, was to have it pluggable so that lookups of hosts could be offloaded. One reason for this was that what we could scope in the Essex timeframe would not include dynamic host memberships (something the ServiceGroup API promises).  The thought being, that if it were pluggable, we could extend upon it in Folsom as a new feature and backport the changes as a plugin.\n\nEven with the ServiceGroup API, there are backends that people will want to develop or backport out of H into Grizzly. I don\'t expect this code to mature enough within Grizzly that this won\'t happen.\n\nAdditionally, my plan for secure messaging will be to have it be extensible.  In particular, a pluggable keyserver component will be available, so users will be able to public key and CRL lookups against various backends. It is a design goal that the community and vendors can plugin here. There are many keyserver solutions and I don\'t want to dictate this to the users. Can these go upstream? Sure, for the most part, if not entirely.  However, with the rapid development cycle of OpenStack, we\'ll cut stable with pluggable backends and /THEN/ the backends will trickle into H and as plugins to then-stable Grizzly.\n\nYou\'ll notice that I\'m not generally advocating long-lived cross-release plugins. Most (but not all) of our out-of-branch code is for a single stable release. Then, such code is no longer needed because of improvements subsequently made in trunk and merged into the next stable release.\n\nThe code that does cross releases does need to get updated and these changes are not necessarily minor, and yes these modules sometimes break within a release. It has happened. We\'re kind of okay with it. Might we be happier if it didn\'t break? Sure, but we\'d be much less happy if we couldn\'t plugin at all.\n\nI suggest it might be useful if thread were cross-posted to the operators/users list.\n\nRegards,\nEric Windisch\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/59f45981/attachment.html>\n\n','<509128D1.6020004@redhat.com>',NULL),('<043d01cc1110$4393a440$cabaecc0$@openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-05-12 20:51:22',-18000,'2011-05-13 01:51:22',NULL,'[Openstack-operators] Nova/openvswitch','That should work, it tells all of the nova services to attach their virtual\nnics to that bridge name. Essentially the same as doing it through brctl. If\nthat doesn\'t work please let me know.\n\n \n\nFrom: openstack-operators-bounces at lists.openstack.org\n[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of manel\nmedhioub\nSent: Wednesday, May 11, 2011 5:03 PM\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Nova/openvswitch\n\n \n\nhi\nI have installed Nova and i have my instances running , I\'m working on the\nintegration of openvswitch with openstack.\nI want to know what should i modify in nova.conf to allow new instances to\nsee my openvswitch bridge \'br0\' which is already configured.\nDoes flat_network_bridge resolves my problem and how?\nthanks.\nManel Medhioub\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110512/e2b4ebe9/attachment-0001.html>\n\n','<SNT117-W1D3BEBB9694876A773B1A9B860@phx.gbl>',NULL),('<044278B9-5C0E-473A-AD05-094F4D075630@lookout.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-21 14:19:03',-25200,'2013-10-21 21:19:03',NULL,'[Openstack] openstack & network HA - 10GbE bonding?','Wondering what others have used for multi homed OpenStack nodes on 10GbE. Linux bonding? Something else?\n\nIn past lives I\'ve encountered performance issues with 10GbE on Linux bonding and have used Myricom cards for active/failover.\n\nWhat are others using?\n\n--\nmatthew zeier | Dir. Operations | Lookout | https://twitter.com/mrz\n\n\n\n',NULL,NULL),('<044E1075-DE4E-4E0C-9F0F-56D801E21902@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-23 11:43:47',36000,'2013-05-23 01:43:47',NULL,'[openstack-dev] [Cinder] Backups using iscsi based drivers','I can\'t commit at the moment but should be better placed in about a month to do something in this space.\n\nI\'ll add a blueprint for now.\n\nCheers,\nSam\n\n\nOn 21/05/2013, at 6:30 PM, Avishay Traeger <AVISHAY at il.ibm.com> wrote:\n\n> Sam,\n> Yes, definitely.  Do you want to volunteer? :)\n> \n> Note that the iSCSI attach code will hopefully be refactored soon:\n> https://blueprints.launchpad.net/cinder/+spec/cinder-refactor-attach\n> \n> Thanks,\n> Avishay\n> \n> \n> \n> From:	Sam Morrison <sorrison at gmail.com>\n> To:	OpenStack Development Mailing List\n>            <openstack-dev at lists.openstack.org>,\n> Date:	05/21/2013 04:36 AM\n> Subject:	[openstack-dev] [Cinder] Backups using iscsi based drivers\n> \n> \n> \n> Hi,\n> \n> Was wondering if there was any plans to get some backup support for iscsi\n> based drivers?\n> \n> For a generic solution we could do it in a similar fashion to how copy to\n> image works by attaching the iscsi device to the host running cinder-backup\n> then copy it off to swift.\n> \n> What do people think?\n> \n> Cheers,\n> Sam\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<OF557582C3.62420026-ONC2257B72.002E8A36-C2257B72.002EC57F@il.ibm.com>',NULL),('<045301cfe16e$9d17d270$d7477750$@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 16:05:40',7200,'2014-10-06 14:05:40',NULL,'[openstack-dev] [Openstack-docs] Contributing to docs without\n	Docbook -- YES you can!','Bonjour Gauvain,\n\nUn gros bravo pour cette documentation sur Heat qui est tr?s compl?te.\n\nEst-ce que par hasard vous auriez d?j? une version fran?aise ? ;)\n\nBest,\n\nF.\n\n-----Message d\'origine-----\nDe : Gauvain Pocentek [mailto:gauvain.pocentek at objectif-libre.com] \nEnvoy? : lundi 6 octobre 2014 07:06\n? : Tom Fifield\nCc : OpenStack Development Mailing List (not for usage questions); openstack-docs at lists.openstack.org\nObjet : Re: [openstack-dev] [Openstack-docs] Contributing to docs without Docbook -- YES you can!\n\nLe 2014-10-06 05:26, Tom Fifield a ?crit :\n> On 04/10/14 04:03, Nick Chase wrote:\n>> \n>> On Fri, Oct 3, 2014 at 3:07 PM, Stefano Maffulli \n>> <stefano at openstack.org <mailto:stefano at openstack.org>> wrote:\n>>     >  1. Pick an existing topic or create a new topic. For new \n>> topics,\n>>     we\'re\n>>     >     primarily interested in deployment scenarios.\n>>     >  2. Develop content (text and/or diagrams) in a format that\n>>     supports at\n>>     >     least basic markup (e.g., titles, paragraphs, lists, etc.).\n>>     >  3. Provide a link to the content (e.g., gist on github.com\n>>     <http://github.com>, wiki page,\n>>     >     blog post, etc.) under the associated topic.\n>> \n>>     Points 1-3 seem to be oriented at removing Launchpad from the \n>> equation.\n>>     Is that all there is? I guess it makes sense to remove obstacles,\n>>     although editing the wiki (since it requires a launchpad account\n>> anyway)\n>>     may not be the best way to track progress and see assignments.\n>> \n>> \n>> No, really, the main change is in step 5.  Launchpad isn\'t the \n>> problem, as far as we can tell; Docbook is.\n> \n> Hi Nick,\n> \n> As best I can tell - \'step 5\' has been in place for at least the last \n> few summits at least, so this is not a change :) We have had a policy \n> where anyone can dump text in bug reports and we\'ll wrangle it. This \n> has been popular, see eg Marco Cossoni\'s contributions, but in my \n> opinion not widely enough communicated - so thanks for your efforts.\n\nWe actually have another way to work with developers, although it\'s been only available for the new HOT guide. This guide is temporary, it will become a part of the user guide. The interesting point is that it\'s written in RST, and uses gerrit for reviews. So far we\'ve had 2 core members of the heat team contributing content, and this content has been reviewed by other members of the team.\n\nThe devs patches focused on content, not on the form of the content. I suggested to accept the patches rapidly - as long as they\'re technically correct - and to rework them later (what I\'ve started to do a couple days ago). The fact that we\'re using gerrit and that the developers review each other work makes me more comfortable with the quality of the content.\n\nI\'d really like to see this process extended to a larger part of the documentation, although this might not be needed everywhere.\n\nI had this workflow in mind:\n\n* a dev sends a review to a temporary repo\n* other devs can validate the information, and give their +1 when the patch is ready\n* a doc reviewer either requests more technical detail, or gives his \n+2/accept\n* the doc team reworks the patch and integrates it to the doc repository\n\nI really think that the process worked for the HOT guide, and I\'m convinced that it could work for other parts of the doc (Cinder and Neutron drivers doc for instance).\n\nAs a side note, we have a tool that converts RST to docbook. The hot guide is automatically built using this tool (http://docs.openstack.org/hot-guide/content/hot_guide_hot-guide.html).\n\nGauvain\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<2aae4d0ed09b03421baf7a748776af81@objectif-libre.com>',NULL),('<045401d03a20$73849e60$5a8ddb20$@eurecom.fr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-27 12:00:24',3600,'2015-01-27 11:00:24',NULL,'[Openstack-operators] Configuration file validator','An external tool is probably able to cross-check across different openstack services. But in any form I would welcome something that tells me:\n\n-          OK this configuration is consistent and makes sense\n\n-          This option doesn?t do anything in this context\n\n-          Setting X is missing, feature Y will not work\n\n-          This is totally broken\n\n \n\nDan\n\n \n\nFrom: j [mailto:j at no-io.net] \nSent: Tuesday 27 January 2015 09:02\nTo: Christian Berendt\nCc: OpenStack Operators\nSubject: Re: [Openstack-operators] Configuration file validator\n\n \n\nIMHO this should be built in per daemon. ex: apachectl -t\n\n \n\n \n\nOn 2015-01-27 02:45, Christian Berendt wrote:\n\nDo you think there is a need for a configuration file validator?\n \nSometimes I have nasty issues in manual created configuration files\n(e.g. a parameter in a wrong section or a mistyped name of a section or\nparameter).\n \nThe services themself to not validate the configuration files for\nlogical issues. They check if the syntax is valid. They do not check if\nthe parameter or section names makes sense (e.g. from time to time\nparameters change the sections or are deprecated in a new release) or if\nthe used values for a parameter are correct.\n \nI started implementing a quick and dircty proof of concept script (I\ncalled it validus) to validate configuration files based on oslo.config\nand stevedore.\n \nIf there exists a need I will cleanup, complete, and publish my proof of\nconcept script on Stackforge. Just want to clarify first whether a need\nexists or not.\n \nChristian.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150127/65434a91/attachment.html>\n\n','<48f6d02f265931d993586fd50b82a931@no-io.net>',NULL),('<046493EA-788E-4A0D-9E0C-9A66B1D8D7F1@microsoft.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 16:25:57',0,'2014-04-15 16:25:57',NULL,'[openstack-dev] Hyper-V Meeting Minutes','Hi Everyone,\nHere are the minutes from today?s Hyper-V Meeting.\n\nMinutes:        http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.html\nMinutes (text): http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.txt\nLog:            http://eavesdrop.openstack.org/meetings/hyper_v/2014/hyper_v.2014-04-15-16.02.log.html\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/bc6fee38/attachment.html>\n\n',NULL,NULL),('<046B1432-BEC5-4B6B-8633-EA125409AD9A@mattei.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-31 12:28:01',-25200,'2013-07-31 19:28:01',NULL,'[Openstack] devstack with neutron/quantum','Hi everyone, I wonder if anyone has seen this error where neutron does \nnot start. here is the error I get with devstack. Any suggestions are \nwelcomed.\n\n\nRemo\n\nremo at openstack-ub:~/devstack$ cd /opt/stack/neutron && python =\n/usr/local/bin/neutron-l3-agent --config-file /etc/neutron/neutron.conf =\n--config-file=3D/etc/neutron/l3_agent.ini || touch =\n\"/opt/stack/status/stack/q-l3.failure\"\n2013-07-31 13:05:07.698 18378 INFO neutron.common.config [-] Logging =\nenabled!\n2013-07-31 13:05:07.703 18378 ERROR neutron.common.legacy [-] Skipping =\nunknown group key: firewall_driver\n2013-07-31 13:05:07.703 18378 DEBUG neutron.common.utils [-] Reloading =\ncached file /etc/neutron/policy.json read_cached_file =\n/opt/stack/neutron/neutron/common/utils.py:55\n2013-07-31 13:05:07.704 18378 DEBUG neutron.policy [-] loading policies =\nfrom file: /etc/neutron/policy.json _set_rules =\n/opt/stack/neutron/neutron/policy.py:88\n2013-07-31 13:05:07.705 18378 CRITICAL neutron [-]\n2013-07-31 13:05:07.705 18378 TRACE neutron Traceback (most recent call =\nlast):\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/usr/local/bin/neutron-l3-agent\", line 10, in <module>\n2013-07-31 13:05:07.705 18378 TRACE neutron     sys.exit(main())\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/l3_agent.py\", line 833, in main\n2013-07-31 13:05:07.705 18378 TRACE neutron     =\nmanager=3D\'neutron.agent.l3_agent.L3NATAgentWithStateReport\')\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/service.py\", line 204, in create\n2013-07-31 13:05:07.705 18378 TRACE neutron     =\nperiodic_fuzzy_delay=3Dperiodic_fuzzy_delay)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/service.py\", line 137, in __init__\n2013-07-31 13:05:07.705 18378 TRACE neutron     self.manager =3D =\nmanager_class(host=3Dhost, *args, **kwargs)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/l3_agent.py\", line 756, in __init__\n2013-07-31 13:05:07.705 18378 TRACE neutron     =\nsuper(L3NATAgentWithStateReport, self).__init__(host=3Dhost, conf=3Dconf)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/l3_agent.py\", line 213, in __init__\n2013-07-31 13:05:07.705 18378 TRACE neutron     =\nself._destroy_router_namespaces(self.conf.router_id)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/l3_agent.py\", line 228, in =\n_destroy_router_namespaces\n2013-07-31 13:05:07.705 18378 TRACE neutron     root_ip =3D =\nip_lib.IPWrapper(self.root_helper)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/linux/ip_lib.py\", line 82, in __init__\n2013-07-31 13:05:07.705 18378 TRACE neutron     namespace=3Dnamespace)\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/neutron/neutron/agent/linux/ip_lib.py\", line 39, in __init__\n2013-07-31 13:05:07.705 18378 TRACE neutron     self.force_root =3D =\ncfg.CONF.ip_lib_force_root\n2013-07-31 13:05:07.705 18378 TRACE neutron   File =\n\"/opt/stack/oslo.config/oslo/config/cfg.py\", line 1626, in __getattr__\n2013-07-31 13:05:07.705 18378 TRACE neutron     raise AttributeError\n2013-07-31 13:05:07.705 18378 TRACE neutron AttributeError\n2013-07-31 13:05:07.705 18378 TRACE neutron=\n\n\n',NULL,NULL),('<047d7b160159bae2d004fb6fda78@google.com>','http://lists.openstack.org/pipermail/fits',NULL,'2014-06-09 23:48:56',0,'2014-06-09 23:48:56',NULL,'[Fits] Invitation: refstack F2F @ Piston @ Wed Jun 11,\n	2014 12pm - 6pm (forrest@pistoncloud.com)','You have been invited to the following event.\n\nTitle: refstack F2F @ Piston\nPiston Cloud Computing\n126 Post St, Fifth Floor\nSan Francisco, CA 94108\nWhen: Wed Jun 11, 2014 12pm - 6pm Pacific Time\nWhere: Panama\nVideo call: https://plus.google.com/hangouts/_/piston.cc/david-forrest  \n<https://plus.google.com/hangouts/_/piston.cc/david-forrest?hceid=Zm9ycmVzdEBwaXN0b25jbG91ZC5jb20.qoti72gdmusea1q4tk2mdi0k8c>\nCalendar: forrest at pistoncloud.com\nWho:\n     * Forrest Carpenter - organizer\n     * David Lenwell\n     * fits at lists.openstack.org\n\nEvent details:  \nhttps://www.google.com/calendar/event?action=VIEW&eid=cW90aTcyZ2RtdXNlYTFxNHRrMm1kaTBrOGMgZml0c0BsaXN0cy5vcGVuc3RhY2sub3Jn&tok=MjMjZm9ycmVzdEBwaXN0b25jbG91ZC5jb21kMjExY2MyZmY0NGMxMjliYzk2NmUwYjllYWMxYjJhMDQ2N2M4ODVm&ctz=America/Los_Angeles&hl=en\n\nInvitation from Google Calendar: https://www.google.com/calendar/\n\nYou are receiving this courtesy email at the account  \nfits at lists.openstack.org because you are an attendee of this event.\n\nTo stop receiving future notifications for this event, decline this event.  \nAlternatively you can sign up for a Google account at  \nhttps://www.google.com/calendar/ and control your notification settings for  \nyour entire calendar.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140609/ad3c9fcb/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: not available\nType: text/calendar\nSize: 1449 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140609/ad3c9fcb/attachment.ics>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: invite.ics\nType: application/ics\nSize: 1484 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20140609/ad3c9fcb/attachment.bin>\n\n',NULL,NULL),('<04867A083C09694985E4171FD38905ED41C13C46@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 22:53:23',0,'2014-07-30 22:53:23',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hello John, Avishay, Duncan, Mike,\n\nThank you for your discussion for my BP of shared LVM support at\nprevious cinder meeting. I had some action items to explain my\nproposal from John.\n\n  - Make clear a purpose of this proposal\n  - Compare performance with other drivers(using 8VMs)\n    Describe test environment, test conditions.\n\nI have updated attached document including these AIs.\nIf you have a chance, could you review the attachment again?\n\n- Related blueprints and patches.\n  https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\n  https://review.openstack.org/#/c/92479/\n\n  https://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\n  https://review.openstack.org/#/c/92443/\n  https://review.openstack.org/#/c/97602/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n\nFrom: Avishay Traeger [mailto:avishay at stratoscale.com]\nSent: Sunday, May 25, 2014 3:06 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Tomoki Sekiyama\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nHello Mitsuhiro,\nI\'m sorry, but I remain unconvinced.  Is there a customer demand for this feature?\nIf you\'d like, feel free to add this topic to a Cinder weekly meeting agenda, and join the meeting so that we can have an interactive discussion.\nhttps://wiki.openstack.org/wiki/CinderMeetings\n\nThanks,\nAvishay\n\nOn Sat, May 24, 2014 at 12:31 AM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHi Avishay-san,\n\nThank you for your review and comments for my proposal. I commented in-line.\n\n>>So the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n\nA generic ?driver for any storage is an one of benefit.\nBut main benefit of proposed driver is as follows.\n- Reduce hardware based storage workload by offloading the workload to software based volume operation.\n\nConventionally, operations to an enterprise storage such as volume creation, deletion, snapshot, etc\nare only permitted system administrator and they handle these operations after carefully examining.\nIn OpenStack cloud environment, every user have a permission to execute these storage operations\nvia cinder. As a result, workloads of storages have been increasing and it is difficult to manage\nthe workloads.\n\nIf we have two drivers in regards to a storage, we can use both way as the situation demands.\nEx.\n  As for \"Standard\" type storage, use proposed software based LVM cinder driver.\n  As for \"High performance\" type storage, use hardware based cinder driver.\n\nAs a result, we can offload the workload of standard type storage from physical storage to cinder host.\n\n>>1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.\n>>  Every time a host is rebooted,\n\nI thinks current FC-based cinder drivers using scsi scan to find created LU.\n# echo \"- - -\" > /sys/class/scsi_host/host#/scan\n\nThe admin can find additional LU using this, so host reboot are not required.\n\n>> or introduced, the admin must do manual work. This is one of the things OpenStack should be trying\n>> to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n\nYes. Some admin manual work is required and can?t be automated.\nI would like to know whether these operations are acceptable range to enjoy benefits from\nmy proposed driver.\n\n>>2. You lose on performance to volumes by adding another layer in the stack.\n\nI think this is case by case.  When user use a cinder volume for DATA BASE, they prefer\nraw volume and proposed driver can?t provide raw cinder volume.\nIn this case, I recommend \"High performance\" type storage.\n\nLVM is a default feature in many Linux distribution. Also LVM is used many enterprise\nsystems and I think there is not critical performance loss.\n\n>>3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots\n>> than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n>> (Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nI agree that storage has efficient COW snapshot feature, so we can create new Boot Volume\nfrom glance quickly. In this case, I recommend \"High performance\" type storage.\nLVM can?t create nested snapshot with shared LVM now. Therefore, we can?t assign\nwritable LVM snapshot to instances.\n\nIs this answer for your comment?\n\n>> In short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy\n>> their storage like this?\n\nPlease consider above main benefit.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\nFrom: Avishay Traeger [mailto:avishay at stratoscale.com<mailto:avishay at stratoscale.com>]\nSent: Wednesday, May 21, 2014 4:36 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Tomoki Sekiyama\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nSo the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.  Every time a host is rebooted, or introduced, the admin must do manual work. This is one of the things OpenStack should be trying to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n2. You lose on performance to volumes by adding another layer in the stack.\n3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n\n(Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nIn short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy their storage like this?\n\nThanks,\nAvishay\nOn Tue, May 20, 2014 at 6:31 PM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHello All,\n\nI?m proposing a feature of LVM driver to support LVM on a shared LU.\nThe proposed LVM volume driver provides these benefits.\n  - Reduce hardware based storage workload by offloading the workload to software based volume operation.\n  - Provide quicker volume creation and snapshot creation without storage workloads.\n  - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver.\n  - Better I/O performance using direct volume access via Fibre channel.\n\nIn the attachment pdf, following contents are explained.\n  1. Detail of Proposed LVM volume driver\n  1-1. Big Picture\n  1-2. Administrator preparation\n  1-3. Work flow of volume creation and attachment\n  2. Target of Proposed LVM volume driver\n  3. Comparison of Proposed LVM volume driver\n\nCould you review the attachment?\nAny comments, questions, additional ideas would be appreciated.\n\n\nAlso there are blueprints, wiki and patches related to the slide.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nhttps://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder\nhttps://review.openstack.org/#/c/92479/\nhttps://review.openstack.org/#/c/92443/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/ed848339/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Cinder-Support_LVM_on_a_sharedLU-v3.pdf\nType: application/pdf\nSize: 1167048 bytes\nDesc: Cinder-Support_LVM_on_a_sharedLU-v3.pdf\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/ed848339/attachment-0001.pdf>\n\n','<04867A083C09694985E4171FD38905EDB56982@USINDEM103.corp.hds.com>',NULL),('<04867A083C09694985E4171FD38905ED41C14858@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-01 16:15:23',0,'2014-08-01 16:15:23',NULL,'[openstack-dev] [Nova] Nominating Jay Pipes for nova-core','+1\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n\n> -----Original Message-----\n> From: Russell Bryant [mailto:rbryant at redhat.com]\n> Sent: Thursday, July 31, 2014 7:58 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core\n> \n> On 07/30/2014 05:10 PM, Russell Bryant wrote:\n> > On 07/30/2014 05:02 PM, Michael Still wrote:\n> >> Greetings,\n> >>\n> >> I would like to nominate Jay Pipes for the nova-core team.\n> >>\n> >> Jay has been involved with nova for a long time now.  He\'s previously\n> >> been a nova core, as well as a glance core (and PTL). He\'s been\n> >> around so long that there are probably other types of core status I\n> >> have missed.\n> >>\n> >> Please respond with +1s or any concerns.\n> >\n> > +1\n> >\n> \n> Further, I\'d like to propose that we treat all of existing +1 reviews as\n> +2 (once he\'s officially added to the team).  Does anyone have a problem\n> with doing that?  I think some folks would have done that anyway, but I wanted to clarify that\n> it\'s OK.\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53DA2F2A.7000006@redhat.com>',NULL),('<04867A083C09694985E4171FD38905ED41C4F471@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-14 20:13:44',0,'2014-11-14 20:13:44',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hello, Duncan, Mike,\n\n>>11:13 (DuncanT) <DuncanT> mtanino, You can and should submit the code even if\n>>the spec isn\'t approved as long as it isn\'t looking contentious, but I will certainly take a look\n\nBase on the comment at cinder__unofficial_meeting at Wednesday,\nI posted both updated cinder-spec and the code.\nCould you review the spec and code?\n\n Spec:  https://review.openstack.org/#/c/129352/\n Code:  https://review.openstack.org/#/c/92479/\n\nThe code is still work in progress, but most of functions are\nalready implemented. Please check whether the code doesn\'t break\nexisting cinder code.\n\nFor your reference, here are whole links related to this proposal.\n\n Blueprints:\n  * https://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\n  * https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\n Spec:\n  * nova:   https://review.openstack.org/#/c/127318/\n  * cinder: https://review.openstack.org/#/c/129352/\n Gerrit Review:\n  * nova:   https://review.openstack.org/#/c/92443/\n  * cinder: https://review.openstack.org/#/c/92479/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\nHITACHI DATA SYSTEMS\n\n','<04867A083C09694985E4171FD38905EDB56982@USINDEM103.corp.hds.com>',NULL),('<04867A083C09694985E4171FD38905EDB3BAC2@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-10 18:44:26',0,'2014-04-10 18:44:26',NULL,'[openstack-dev] [Cinder] Support LVM on a volume attached to\n	multiple nodes','Hi John-san,\n\nThank you for your review of my summit suggestion and I understand your indication.\nCould you see my following comments?\n\n-------------\nhttp://summit.openstack.org/cfp/details/166\nThere\'s a lot here, based on conversations in IRC and the excellent wiki you put together\nI\'m still trying to get a clear picture here.\nLet\'s start by taking transport protocol out of the mix; I believe what you\'re proposing\nis a shared, multi-attach LV (over iscsi, fibre or whatever). That seems to fall under\nthe multi-attach feature.\n-------------\n\nSo both my BP and BP of \"multi-attach-volume\" need multi attach feature, but\nin my understanding, the target layer and goals are different .\n\nLet me explain the additional point.\n* \"multi-attach-volume\": Implement the volume  multi attach feature.\n     Main target layers is Nova layer. (and a little cinder layer implement?).\n\n* My BP : Implement a generic LVM volume driver using LVM  on\n   a storage volume(over iscsi, fibre or whatever) attached to multi compute nodes.\n   Target layers are both Nova and Cinder layer.\n\n  The different point is the former case, the cinder volume is needed to create\n  by other cinder storage driver with supported storage, and after that the\n  feature can attach a volume to multiple instances.(and also hosts)\n\n  On the other hands, my BP targets generic LVM driver and  not depends on\n  specific vendor storage. The driver just provide features to create/delete/snapshot\n volume, etc from a volume group on multi attached storage.\n  The point is user needs to create a storage volume using own storage management tool,\n  attach the created volume to multiple compute nodes, create VG on the volume and\n  configure it to cinder.conf as a \"volume_group\".\n  So, multi-attach feature is not a target feature to implement. The driver just\n  requires an environment of LVM on a storage attached to multi compute nodes.\n\n  I think my proposed LVM driver is orthogonal to the \"multi-attach-volume\"\n  and we can use \"multi-attach-volume\" and my BP in combination.\n\nHere is my additional understanding for both BPs.\n[A] My BP\n  https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\n  The goal of my BP is supporting a volume group on a volume which is attached to\n  multiple compute nodes.\n  So the proposed driver just provide a feature to create/delete/snapshot, etc from\n  volume group same as existing LVMiSCSI driver.\n  But the difference from LVMiSCSI driver, the prepared volume group on a storage\n  volume is required to be attached to multiple compute nodes in order to recognize\n  multiple compute nodes simultaneously instead of using iSCSI target.\n\n  The multi attached storage and volume group on it is needed to prepare before cinder\n  configuration by user without any cinder features because the target of my driver is\n  generic LVM driver and my driver targets to support a storages environment which\n  does not have cinder storage driver.\n\n  [Preparation of volume_group]\n   (a) An user create a storage volume using \"storage management tool\".(not cinder feature)\n   (b) Export a created volume to multiple compute nodes.(using FC host group or iSCSI target feature)\n    (c) Create volume group on a exported storage volume.\n   (d) Configure the volume group for the cinder \"volume_group\".\n\n[B] BP of multi-attach-volume\n  https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume\n  The goal of this BP is attaching a cinder volume to multiple instances.\n  In my understanding, providing a cinder volume multi-attach feature is\n  a goal of this BP.\n\nSteps to multi attach\n  (1) Create a volume using \"cinder volume driver\" with \"supported storage\".\n     Driver and supported driver is required.\n  (2) Export a created volume to multiple compute nodes via FC, iSCSI, etc.\n  (3) Attach a created volume to multiple instances with RO/RW mode.\n  (4) As a result, multiple instances can recognize a single cinder volume\n     simultaneously.\n\n\n-------------\nI\'m also trying to understand your statements about improved performance. Could you maybe\nadd some more detail or explanation around this things or maybe grab me on IRC when convenient?\n-------------\n  This explains a comparison between LVMiSCSI and my BP driver.\n  Current LVMiSCSI driver uses a cinder node as a \"virtual storage\" using software iSCSI target.\n  This is useful and not depends on storage arrangement, but we have to access a volume group\n  via network even if we have FC environment. If we have multi attached FC volume, it is better\n  to access the volume via FC instead of iSCSI target.\n  As a result, we expect better I/O performance and latency to access multi attached FC volume\n  to compute nodes.  This is a point which I mentioned.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140410/3d210358/attachment.html>\n\n',NULL,NULL),('<04867A083C09694985E4171FD38905EDB523D3@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 15:31:03',0,'2014-05-20 15:31:03',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hello All,\n\nI\'m proposing a feature of LVM driver to support LVM on a shared LU.\nThe proposed LVM volume driver provides these benefits.\n  - Reduce hardware based storage workload by offloading the workload to software based volume operation.\n  - Provide quicker volume creation and snapshot creation without storage workloads.\n  - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver.\n  - Better I/O performance using direct volume access via Fibre channel.\n\nIn the attachment pdf, following contents are explained.\n  1. Detail of Proposed LVM volume driver\n  1-1. Big Picture\n  1-2. Administrator preparation\n  1-3. Work flow of volume creation and attachment\n  2. Target of Proposed LVM volume driver\n  3. Comparison of Proposed LVM volume driver\n\nCould you review the attachment?\nAny comments, questions, additional ideas would be appreciated.\n\n\nAlso there are blueprints, wiki and patches related to the slide.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nhttps://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder\nhttps://review.openstack.org/#/c/92479/\nhttps://review.openstack.org/#/c/92443/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/a0ec22b0/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: [Cinder]Support_LVM_on_a_sharedLU.pdf\nType: application/pdf\nSize: 1017871 bytes\nDesc: [Cinder]Support_LVM_on_a_sharedLU.pdf\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/a0ec22b0/attachment-0001.pdf>\n\n',NULL,NULL),('<04867A083C09694985E4171FD38905EDB54308@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 21:31:14',0,'2014-05-23 21:31:14',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hi Avishay-san,\n\nThank you for your review and comments for my proposal. I commented in-line.\n\n>>So the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n\nA generic ?driver for any storage is an one of benefit.\nBut main benefit of proposed driver is as follows.\n- Reduce hardware based storage workload by offloading the workload to software based volume operation.\n\nConventionally, operations to an enterprise storage such as volume creation, deletion, snapshot, etc\nare only permitted system administrator and they handle these operations after carefully examining.\nIn OpenStack cloud environment, every user have a permission to execute these storage operations\nvia cinder. As a result, workloads of storages have been increasing and it is difficult to manage\nthe workloads.\n\nIf we have two drivers in regards to a storage, we can use both way as the situation demands.\nEx.\n  As for \"Standard\" type storage, use proposed software based LVM cinder driver.\n  As for \"High performance\" type storage, use hardware based cinder driver.\n\nAs a result, we can offload the workload of standard type storage from physical storage to cinder host.\n\n>>1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.\n>>  Every time a host is rebooted,\n\nI thinks current FC-based cinder drivers using scsi scan to find created LU.\n# echo \"- - -\" > /sys/class/scsi_host/host#/scan\n\nThe admin can find additional LU using this, so host reboot are not required.\n\n>> or introduced, the admin must do manual work. This is one of the things OpenStack should be trying\n>> to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n\nYes. Some admin manual work is required and can?t be automated.\nI would like to know whether these operations are acceptable range to enjoy benefits from\nmy proposed driver.\n\n>>2. You lose on performance to volumes by adding another layer in the stack.\n\nI think this is case by case.  When user use a cinder volume for DATA BASE, they prefer\nraw volume and proposed driver can?t provide raw cinder volume.\nIn this case, I recommend \"High performance\" type storage.\n\nLVM is a default feature in many Linux distribution. Also LVM is used many enterprise\nsystems and I think there is not critical performance loss.\n\n>>3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots\n>> than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n>> (Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nI agree that storage has efficient COW snapshot feature, so we can create new Boot Volume\nfrom glance quickly. In this case, I recommend \"High performance\" type storage.\nLVM can?t create nested snapshot with shared LVM now. Therefore, we can?t assign\nwritable LVM snapshot to instances.\n\nIs this answer for your comment?\n\n>> In short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy\n>> their storage like this?\n\nPlease consider above main benefit.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\nFrom: Avishay Traeger [mailto:avishay at stratoscale.com]\nSent: Wednesday, May 21, 2014 4:36 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Tomoki Sekiyama\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nSo the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.  Every time a host is rebooted, or introduced, the admin must do manual work. This is one of the things OpenStack should be trying to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n2. You lose on performance to volumes by adding another layer in the stack.\n3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n\n(Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nIn short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy their storage like this?\n\nThanks,\nAvishay\nOn Tue, May 20, 2014 at 6:31 PM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHello All,\n\nI?m proposing a feature of LVM driver to support LVM on a shared LU.\nThe proposed LVM volume driver provides these benefits.\n  - Reduce hardware based storage workload by offloading the workload to software based volume operation.\n  - Provide quicker volume creation and snapshot creation without storage workloads.\n  - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver.\n  - Better I/O performance using direct volume access via Fibre channel.\n\nIn the attachment pdf, following contents are explained.\n  1. Detail of Proposed LVM volume driver\n  1-1. Big Picture\n  1-2. Administrator preparation\n  1-3. Work flow of volume creation and attachment\n  2. Target of Proposed LVM volume driver\n  3. Comparison of Proposed LVM volume driver\n\nCould you review the attachment?\nAny comments, questions, additional ideas would be appreciated.\n\n\nAlso there are blueprints, wiki and patches related to the slide.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nhttps://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder\nhttps://review.openstack.org/#/c/92479/\nhttps://review.openstack.org/#/c/92443/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/7462715e/attachment.html>\n\n','<CAHph7JoMpyCvLLtT8nmBXq6iyN-4bQUaGOfG8EV3JaX5=SAD7A@mail.gmail.com>',NULL),('<04867A083C09694985E4171FD38905EDB56982@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 02:37:26',0,'2014-05-30 02:37:26',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hi Avishay-san,\nThank you for your comment. I commented in-line.\n\n>> I\'m sorry, but I remain unconvinced.  Is there a customer demand for this feature?\nCurrently, we do not have specific customer?s demand for this feature.\nBut I believe this feature provides benefits to both customers and cloud providers.\n\n>> If you\'d like, feel free to add this topic to a Cinder weekly meeting agenda,\n>> and join the meeting so that we can have an interactive discussion.\nIf possible, I would like to continue discussions on the ML.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\nFrom: Avishay Traeger [mailto:avishay at stratoscale.com]\nSent: Sunday, May 25, 2014 3:06 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Tomoki Sekiyama\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nHello Mitsuhiro,\nI\'m sorry, but I remain unconvinced.  Is there a customer demand for this feature?\nIf you\'d like, feel free to add this topic to a Cinder weekly meeting agenda, and join the meeting so that we can have an interactive discussion.\nhttps://wiki.openstack.org/wiki/CinderMeetings\n\nThanks,\nAvishay\n\nOn Sat, May 24, 2014 at 12:31 AM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHi Avishay-san,\n\nThank you for your review and comments for my proposal. I commented in-line.\n\n>>So the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n\nA generic ?driver for any storage is an one of benefit.\nBut main benefit of proposed driver is as follows.\n- Reduce hardware based storage workload by offloading the workload to software based volume operation.\n\nConventionally, operations to an enterprise storage such as volume creation, deletion, snapshot, etc\nare only permitted system administrator and they handle these operations after carefully examining.\nIn OpenStack cloud environment, every user have a permission to execute these storage operations\nvia cinder. As a result, workloads of storages have been increasing and it is difficult to manage\nthe workloads.\n\nIf we have two drivers in regards to a storage, we can use both way as the situation demands.\nEx.\n  As for \"Standard\" type storage, use proposed software based LVM cinder driver.\n  As for \"High performance\" type storage, use hardware based cinder driver.\n\nAs a result, we can offload the workload of standard type storage from physical storage to cinder host.\n\n>>1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.\n>>  Every time a host is rebooted,\n\nI thinks current FC-based cinder drivers using scsi scan to find created LU.\n# echo \"- - -\" > /sys/class/scsi_host/host#/scan\n\nThe admin can find additional LU using this, so host reboot are not required.\n\n>> or introduced, the admin must do manual work. This is one of the things OpenStack should be trying\n>> to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n\nYes. Some admin manual work is required and can?t be automated.\nI would like to know whether these operations are acceptable range to enjoy benefits from\nmy proposed driver.\n\n>>2. You lose on performance to volumes by adding another layer in the stack.\n\nI think this is case by case.  When user use a cinder volume for DATA BASE, they prefer\nraw volume and proposed driver can?t provide raw cinder volume.\nIn this case, I recommend \"High performance\" type storage.\n\nLVM is a default feature in many Linux distribution. Also LVM is used many enterprise\nsystems and I think there is not critical performance loss.\n\n>>3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots\n>> than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n>> (Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nI agree that storage has efficient COW snapshot feature, so we can create new Boot Volume\nfrom glance quickly. In this case, I recommend \"High performance\" type storage.\nLVM can?t create nested snapshot with shared LVM now. Therefore, we can?t assign\nwritable LVM snapshot to instances.\n\nIs this answer for your comment?\n\n>> In short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy\n>> their storage like this?\n\nPlease consider above main benefit.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\nFrom: Avishay Traeger [mailto:avishay at stratoscale.com<mailto:avishay at stratoscale.com>]\nSent: Wednesday, May 21, 2014 4:36 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Tomoki Sekiyama\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nSo the way I see it, the value here is a generic driver that can work with any storage.  The downsides:\n1. The admin has to manually provision a very big volume and attach it to the Nova and Cinder hosts.  Every time a host is rebooted, or introduced, the admin must do manual work. This is one of the things OpenStack should be trying to avoid. This can\'t be automated without a driver, which is what you\'re trying to avoid.\n2. You lose on performance to volumes by adding another layer in the stack.\n3. You lose performance with snapshots - appliances will almost certainly have more efficient snapshots than LVM over network (consider that for every COW operation, you are reading synchronously over the network).\n\n(Basically, you turned your fully-capable storage appliance into a dumb JBOD)\n\nIn short, I think the cons outweigh the pros.  Are there people deploying OpenStack who would deploy their storage like this?\n\nThanks,\nAvishay\nOn Tue, May 20, 2014 at 6:31 PM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHello All,\n\nI?m proposing a feature of LVM driver to support LVM on a shared LU.\nThe proposed LVM volume driver provides these benefits.\n  - Reduce hardware based storage workload by offloading the workload to software based volume operation.\n  - Provide quicker volume creation and snapshot creation without storage workloads.\n  - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver.\n  - Better I/O performance using direct volume access via Fibre channel.\n\nIn the attachment pdf, following contents are explained.\n  1. Detail of Proposed LVM volume driver\n  1-1. Big Picture\n  1-2. Administrator preparation\n  1-3. Work flow of volume creation and attachment\n  2. Target of Proposed LVM volume driver\n  3. Comparison of Proposed LVM volume driver\n\nCould you review the attachment?\nAny comments, questions, additional ideas would be appreciated.\n\n\nAlso there are blueprints, wiki and patches related to the slide.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nhttps://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder\nhttps://review.openstack.org/#/c/92479/\nhttps://review.openstack.org/#/c/92443/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/0c6430fc/attachment.html>\n\n','<CAHph7JpHc5c7WpJ-J_zTBVEVa4Wisd3xBzOZNaqHUEVkZHQkoA@mail.gmail.com>',NULL),('<04867A083C09694985E4171FD38905EDB577C9@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-02 16:06:15',0,'2014-06-02 16:06:15',NULL,'[openstack-dev] [Cinder] Support LVM on a shared LU','Hi Deepak-san,\n\nThank you for your comment. Please see following comments.\n\n>>1) There is a lof of manual work needed here.. like every time the new host added.. admin needs to do FC zoning to ensure that LU is visible by the host.\n\nRight. Compared to LVMiSCSI driver, proposed driver are needed some manual admin works.\n\n>>Also the method you mentioend for refreshing (echo \'---\' > ...) doesn\'t work reliably across all storage types does it ?\n\nThe \"echo\" command is already used in rescan_hosts() at linuxfc.py before connecting new volume to a instance.\nAs you mentioned,  whether this command works properly or not depends on storage types.\nTherefore, admin needs to confirm the command working properly.\n\n>>2) In Slide 1-1 .. how ( and who?) ensures that the compute nodes don\'t step on each other is using the LVs ? In other words.. how is it ensured that LV1 is not used by compute nodes 1 and 2 at the same time ?\n\nIn my understanding, Nova can\'t assign single cinder volume(ex. VOL1) to multiple instances.\nAfter attaching the VOL1 to an instance, a status of the VOL1 is changed to \"in-use\" and\nuser can?t attach the VOL1 to other instances.\n\n>>3) In slide 1-2, you show that the LU1 is seen as /dev/sdx on all the nodes.. this is wrong.. it can be seen as anything (/dev/sdx on control node, sdn on compute 1, sdz on compute 2) so assumign sdx on all nodes is wrong. How does this different device names handled.. in short, how does compute node 2 knows that LU1 is actually sdn and not sdz (assuming you had > 1 LUs provisioned)\n\nRight. Same device name may not be assigned on all nodes.\nAt my proposed driver, admin needs to create PV and VG manually.\nTherefore, all nodes do not have to recognize the LU1 as /dev/sdx.\n\n>>4) What abt multipath ? In most prod env.. the FC storage will be multipath\'ed.. hence you will actually see sdx and sdy on each node and you actually need to use mpathN (which is multipathe\'d to sdx anx sdy) device and NOT the sd? device to take adv of the customer multipath env. How does the nodes know which mpath? device to use and which mpath? device maps to which LU on the array ?\n\nAs I mentioned above, admin creates PV and VG manually at my proposed driver. If a product environment\nuses multipath, admin can create a PV and VG on top of mpath device, using \"pvcreate /dev/mpath/mpathX\".\n\n>>5) Doesnt this new proposal also causes the compute nodes to be physcially connected (via FC) to the array, which means more wiring and need for FC HBA on compute nodes. With LVMiSCSI, we don\'t need FC HBA on compute nodes so you are actualluy adding cost of each FC HBA to the compute nodes and slowly turning commodity system to non-commodity ;-) (in a way)\n\nI think this is depends on a customer\'s or cloud provider\'s requirement.(In slide P9)\nIf the requirement is low cost and none FC cloud environment, LVMiSCSI is appropriate driver.\nIf better I/O performance is required, proposed driver or vendor cinder storage driver with FC\nare appropriate, because these drivers can directly issue I/O to volumes via FC.\n\n>>6) Last but not the least... since you are using 1 BIG LU on the array to host multiple volumes, you cannot possibly take adv of the premium, efficient snapshot/clone/mirroring features of the array, since they are at LU level, not at the LV level. LV snapshots have limitations (as mentioned by you in other thread) and are always in-efficient compared to array snapshots. Why would someone want to use less efficient method when they invested on a expensive array ?\n\nRight. If user uses array volume directly, user can take adv of efficient snapshot/clone/mirroring features.\n\nAs I wrote in a reply e-mail to Avishay-san, in OpenStack cloud environment, workloads of\nstorages have been increasing and it is difficult to manage the workloads because every user\nhave a  permission to execute storage operations via cinder.\nIn order to use expensive array more efficient, I think it is better to reduce hardware based storage\nworkload by offloading the workload to software based volume operation on a case by case.\n\nIf we have two drivers in regards to a storage, we can provide volume both way as the situation demands.\nEx.\n  As for \"Standard\" type storage, use proposed software based LVM cinder driver.\n  As for \"High performance\" type storage, use hardware based cinder driver.(Ex. Higher charge than \"Standard\" volume)\n\nThis is one of use-case of my proposed driver.\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\nFrom: Deepak Shetty [mailto:dpkshetty at gmail.com]\nSent: Wednesday, May 28, 2014 3:11 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Cinder] Support LVM on a shared LU\n\nMitsuhiro,\n  Few questions that come to my mind based on your proposal\n\n1) There is a lof of manual work needed here.. like every time the new host added.. admin needs to do FC zoning to ensure that LU is visible by the host. Also the method you mentioend for refreshing (echo \'---\' > ...) doesn\'t work reliably across all storage types does it ?\n2) In Slide 1-1 .. how ( and who?) ensures that the compute nodes don\'t step on each other is using the LVs ? In other words.. how is it ensured that LV1 is not used by compute nodes 1 and 2 at the same time ?\n3) In slide 1-2, you show that the LU1 is seen as /dev/sdx on all the nodes.. this is wrong.. it can be seen as anything (/dev/sdx on control node, sdn on compute 1, sdz on compute 2) so assumign sdx on all nodes is wrong.\nHow does this different device names handled.. in short, how does compute node 2 knows that LU1 is actually sdn and not sdz (assuming you had > 1 LUs provisioned)\n4) What abt multipath ? In most prod env.. the FC storage will be multipath\'ed.. hence you will actually see sdx and sdy on each node and you actually need to use mpathN (which is multipathe\'d to sdx anx sdy) device and NOT the sd? device to take adv of the customer multipath env. How does the nodes know which mpath? device to use and which mpath? device maps to which LU on the array ?\n5) Doesnt this new proposal also causes the compute nodes to be physcially connected (via FC) to the array, which means more wiring and need for FC HBA on compute nodes. With LVMiSCSI, we don\'t need FC HBA on compute nodes\nso you are actualluy adding cost of each FC HBA to the compute nodes and slowly turning commodity system to non-commodity ;-) (in a way)\n6) Last but not the least... since you are using 1 BIG LU on the array to host multiple volumes, you cannot possibly take adv of the premium, efficient snapshot/clone/mirroring features of the array, since they are at LU level, not at the LV level. LV snapshots have limitations (as mentioned by you in other thread) and are always in-efficient compared to array snapshots. Why would someone want to use less efficient method when they invested on a expensive array ?\nthanx,\ndeepak\n\n\nOn Tue, May 20, 2014 at 9:01 PM, Mitsuhiro Tanino <mitsuhiro.tanino at hds.com<mailto:mitsuhiro.tanino at hds.com>> wrote:\nHello All,\n\nI?m proposing a feature of LVM driver to support LVM on a shared LU.\nThe proposed LVM volume driver provides these benefits.\n  - Reduce hardware based storage workload by offloading the workload to software based volume operation.\n  - Provide quicker volume creation and snapshot creation without storage workloads.\n  - Enable cinder to any kinds of shared storage volumes without specific cinder storage driver.\n  - Better I/O performance using direct volume access via Fibre channel.\n\nIn the attachment pdf, following contents are explained.\n  1. Detail of Proposed LVM volume driver\n  1-1. Big Picture\n  1-2. Administrator preparation\n  1-3. Work flow of volume creation and attachment\n  2. Target of Proposed LVM volume driver\n  3. Comparison of Proposed LVM volume driver\n\nCould you review the attachment?\nAny comments, questions, additional ideas would be appreciated.\n\n\nAlso there are blueprints, wiki and patches related to the slide.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nhttps://wiki.openstack.org/wiki/Cinder/NewLVMbasedDriverForSharedStorageInCinder\nhttps://review.openstack.org/#/c/92479/\nhttps://review.openstack.org/#/c/92443/\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com<http://mitsuhiro.tanino at hds.com>>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/be1d2509/attachment.html>\n\n','<CAOXiiM=zn-9_mLWWpkNHJdLV3zeWiaBk0DsJMMaRskDnnhc0bw@mail.gmail.com>',NULL),('<04867A083C09694985E4171FD38905EDB6CD36@USINDEM103.corp.hds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 22:07:10',0,'2014-07-17 22:07:10',NULL,'[openstack-dev] [Nova] Requesting spec freeze exception: \"LVM:\n Support a volume-group on shared storage\" spec','Hi Nova cores,\n\nI would like to request a spec freeze exception for my spec on\n\"LVM: Support a volume-group on shared storage\".\n\nPlease see the spec here:\nhttps://review.openstack.org/#/c/97602/4/specs/juno/lvm-driver-for-shared-storage.rst\n\nThis is for the blueprint:\nhttps://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage.\n\nThis feature request is related to both nova and cinder pieces.\nCinder piece is following BP.\nhttps://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\n\nBoth nova-spec and blue print of cinder were once approved, however I had some\ndiscussion about cinder piece and the blueprint was changed to discussion status\nfrom approved. Therefore I\'m preparing to explain benefits of my proposal at\ncinder community again.\n\nAs for the patch of nova piece, I have already got +2 from core reviewer, so once\nI will get \"approved\" again for cinder piece, I think I am able to move forward\nboth cinder piece and nova piece to get into Juno release.\n\n- Nova piece\nBlue print   : https://blueprints.launchpad.net/nova/+spec/lvm-driver-for-shared-storage\nnova-spec    : https://review.openstack.org/97602\nnova patch   : https://review.openstack.org/92443\n\n- Cinder piece\nBlue print   : https://blueprints.launchpad.net/cinder/+spec/lvm-driver-for-shared-storage\ncinder patch : https://review.openstack.org/92479\n\nRegards,\nMitsuhiro Tanino <mitsuhiro.tanino at hds.com>\n     HITACHI DATA SYSTEMS\n     c/o Red Hat, 314 Littleton Road, Westford, MA 01886\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/dc28b4b1/attachment.html>\n\n',NULL,NULL),('<048DF4A0-C4B9-4AAB-84C9-63A697EDCAC0@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 22:45:38',-14400,'2014-09-18 02:45:38',NULL,'[openstack-dev] pbr alpha and dev version handling','\n> On Sep 17, 2014, at 10:42 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> \n> I\'m more in favor of option 2. Semver doesn\'t really support _ANY_ of\n> the PEP440 things we\'re doing - and I\'m fine with that personally. The\n> dev version of an alpha _is_ supported by PEP440.\n> \n> If we considered the logic to be:\n> \n> \"The most recent tag is a pre-release tag, we no longer need to GENERATE\n> pre-release versions, but instead start emitting post-release versions\n> of the human-generated pre-release\" - then I think we\'re good. I also\n> think that since they are post-release versions of the most recent\n> human-generated pre-release, the deb/rpm translation logic is likely\n> largely untouched.\n> \n> 1.3.0.0a3.dev10 would become 1.3.0.0~a3.dev10 in debian world - which\n> would sort as desired.\n\nUnrelated, but for the record, PEP 440 allows 1.3.0.a3.dev10 now, you don?t\nneed the extra zero anymore.\n\n> \n> I do think that we should a) release oslo more frequently than the cycle\n> and b) ditch pre-versioning altogether, but I do not think that is\n> feasible right now. It is a conversation to have in Paris though.\n> \n>> What do you all think?\n>> \n>> Doug\n>> \n>> \n>> [1] https://bugs.launchpad.net/pbr/+bug/1370608 <https://bugs.launchpad.net/pbr/+bug/1370608> \n>> _______________________________________________ OpenStack-dev mailing\n>> list OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org> \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n---\nDonald Stufft\nPGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140917/2ed9ab75/attachment.html>\n\n','<541A468F.8040208@inaugust.com>',NULL),('<0495E480-D7A7-48B4-A776-9048251069A6@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 16:30:55',0,'2014-10-29 16:30:55',NULL,'[openstack-dev] [Solum] Solum Design Session at OpenStack Summit','Team,\n\nSee below. For those of us attending the OpenStack Summit in Paris, please be sure to plan your schedule so you can attend this session.\n\nThanks,\n\nAdrian\n\nBegin forwarded message:\n\n> From: Chris Hoge <chris at openstack.org>\n> Subject: Solum Design Session at OpenStack Summit\n> Date: October 22, 2014 at 11:09:55 AM PDT\n> To: Adrian Otto <adrian.otto at rackspace.com>\n> \n> Hi,\n> \n> Here is the latest schedule information for the Solum Design Session at the OpenStack Summit.\n> \n> Thanks,\n> Chris\n> \n> http://kilodesignsummit.sched.org/event/4e2033ced61b8dadf7a2db1aee6d8123\n\n\n\n',NULL,NULL),('<049AE599-108F-44F9-A22B-02CACC136D36@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 16:52:57',0,'2014-06-30 16:52:57',NULL,'[openstack-dev] [infra][oslo][neutron] Need help getting\n oslo.messaging 1.4.0.0a2 in global requirements','I have out for review 103536 to add this version to global requirements, so that Neutron has an oslo fix (review 102909) for encoding failure, which affects some gate runs. This review for global requirements is failing requirements check (http://logs.openstack.org/36/103536/1/check/check-requirements-integration-dsvm/6d9581c/console.html#_2014-06-30_12_34_56_921). I did a recheck bug 1334898, but see the same error, with the release not found, even though it is in PyPI. Infra folks say this is a known issue with pushing out pre-releases.\n\nDo we have a work-around?\nAny proposed solution to try?\n\nThanks!\n\n \nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140630/6c578964/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140630/6c578964/attachment.pgp>\n\n',NULL,NULL),('<04A97BF9-43EA-46DC-8D27-377497501BFE@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-09-13 18:40:41',0,'2013-09-13 18:40:41',NULL,'[OpenStack-Infra] merge problem','I am confused, can someone help me with this merge problem\n\n  *   this patch was merged https://review.openstack.org/#/c/46182/\n  *   Github has the correct xml https://github.com/openstack/openstack-manuals/blob/master/doc/training-guide/operator-editing-code.xml\n  *   BUT, the code prior to the merged patch is still published at http://docs.openstack.org/trunk/openstack-training/\n  *   and when I update my local repo with git pull origin master, I get the code prior to the merged patch also.\n  *   If I go back to the patch that was merged https://review.openstack.org/#/c/46182/ and create a branch off of it, the correct XML is there and then create the HTML source and review it, it is correct as well.\n\nAm I losing it or is there something broken here? I\'m on the infra channel as @sarob if you want to respond that way.\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com> (925) 980-4729\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20130913/652a0e76/attachment.html>\n\n',NULL,NULL),('<04B039CD-29B2-4B52-A23A-D43D6B65AF59@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 12:05:15',-14400,'2014-10-07 16:05:15',NULL,'[openstack-dev] [all][oslo][db][docs] RFC: drop support for\n	libpq < 9.1','\nOn Oct 7, 2014, at 8:29 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n\n> \n> That said, I wonder how we\'re going to manage cases when those\n> *global* settings for the whole server should be really limited to\n> specific databases. Isn\'t it better to enforce utf8 on service side,\n> since we already know that we always run against utf8 database?\n\nI think whenever we do a ?CREATE DATABASE?, we should make sure the desired encodings are set up at that level.  I?ve seen lots of migration scripts that are listing through tables and setting each table individually to utf-8, and that?s less than ideal, though I suppose that?s more of a retroactive fix.\n\n> \n> Please let me clarify... Do you say that setting client encoding on\n> oslo.db side is actually ok? I haven\'t suggested to enforce utf8 per\n> column/table, though I guess we\'re already there.\n\nThe way we are setting client encoding now should be fine, if you could clarify what about that isn?t working for PG 8.4 that would be helpful.    IMHO especially on Postgresql we should be able to get away with not having it.   MySQLdb is not as nicely implemented as far as encoding (including the use_unicode speed issues) so it may be more necessary there.\n\nBut yes what I really *dont* want is the encoding set up on every column definition, e.g. ?VARCHAR(20) CHARACTER SET ?utf-8??, that?s been suggested before and that would be terrible.   I don?t think Postgresql has quite the same thing available (only collation per column).\n\n> \n> Forgoing, again, means some users running with utf8 client encoding,\n> others without it.\n> I strive towards consistency here, that\'s why I try\n> to find a way to set the setting for all clients we support (and the\n> question is *which* of those clients we really support).\n> \n> The thing that is not supported in psql < 9.1 is a connection option\n> added to libpq as of:\n> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192\n\nOK but that is just the connection parameter, when you pass client_encoding to SQLAlchemy?s psycopg2 dialect, the encoding is set using psycopg2?s set_client_encoding() method: http://initd.org/psycopg/docs/connection.html#connection.set_client_encoding.  This ultimately emits ?SET client_encoding TO ?utf8?? on the connection:\n\nconn_set_client_encoding -> https://github.com/psycopg/psycopg2/blob/master/psycopg/connection_int.c#L1188\n\npq_set_guc_locked -> https://github.com/psycopg/psycopg2/blob/master/psycopg/pqpath.c#L709\n\n?SET client_encoding TO <value>? is supported in all Postgresql versions, here?s 8.0: http://www.postgresql.org/docs/8.0/static/multibyte.html\n\nSo there?s no issue with Postgresql 8.2 here as far as client encoding, the libpq feature isn?t used for that.   Also, it defaults to the encoding that is set for the database (e.g. server side), so if we make sure CREATE DATABASE is emitted with the encoding, then we wouldn?t even need to set it (and perhaps we shouldn?t if the database is set to a different encoding).\n\n\n\n\n\n\n','<5433DC9F.40207@redhat.com>',NULL),('<04B3E422-FBAC-4130-BD9A-C0CABFB046DF@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 06:55:08',-14400,'2012-08-07 10:55:08',NULL,'[openstack-dev] openstack-common library release [was Re:\n	[Netstack] Request for comments on a pep8 problem]','\n\nOn Aug 7, 2012, at 3:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n> On Fri, 2012-08-03 at 13:40 -0400, Jay Pipes wrote:\n>> I\'d prefer smaller, reusable libs as well. Unfortunately, the decision\n>> to use global CONF objects has essentially made the config module an\n>> interdependency between all the other common code, so at a minimum, the\n>> config module would need to be a dep in the other libs.\n> \n> Yes, most openstack-common modules depend on cfg.\n> \n> But this isn\'t because of the global config object. The dependency is\n> there because we want to allow modules to define configuration options.\n\nUnfortunately it means the modules are going to be harder to reuse outside of OpenStack because instead of providing a class-based API that takes individual arguments that can come from another application\'s config, or even a single config object as argument, the global object needs to be initialized correctly.\n\nDoug\n\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1344323288.3319.23.camel@sorcha>',NULL),('<04B61CA1-C901-4ACF-B5DF-3783571B9588@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 17:43:17',25200,'2014-04-01 10:43:17',NULL,'[openstack-dev] [Mistral][TaskFlow] Long running actions','\nOn 25 Mar 2014, at 01:51, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n\n> The first execution model I would call the local execution model, this model involves forming tasks and flows and then executing them inside an application, that application is running for the duration of the workflow (although if it crashes it can re-establish the task and flows that it was doing and attempt to resume them). This could also be what openstack projects would call the \'conductor\' approach where nova, ironic, trove have a conductor which manages these long-running actions (the conductor is alive/running throughout the duration of these workflows, although it may be restarted while running). The restarting + resuming part is something that openstack hasn\'t handled so gracefully currently, typically requiring either some type of cleanup at restart (or by operations), with taskflow using this model the resumption part makes it possible to resume from the last saved state (this connects into the persistence model that taskflow uses, the state transitions, how execution occurrs itself...). \n> \n> The second execution model is an extension of the first, whereby there is still a type of \'conductor\' that is managing the life-time of the workflow, but instead of locally executing tasks in the conductor itself tasks are now executed on remote-workers (see http://tinyurl.com/lf3yqe4\n> ). The engine currently still is \'alive\' for the life-time of the execution, although the work that it is doing is relatively minimal (since its not actually executing any task code, but proxying those requests to others works). The engine while running does the conducting of the remote-workers (saving persistence details, doing state-transtions, getting results, sending requests to workers?).\n\nThese two execution models are special cases of what you call ?lazy execution model? (or passive as we call it). To illustrate this idea we can take a look at the first sequence diagram at [0], we basically will see the following interaction:\n\n1) engine --(task)--> queue --(task)--> worker\n2) execute task\n3) worker --(result)--> queue --(result)--> engine\n\nThis is how TaskFlow worker based model works.\n\nIf we loosen the requirement in 3) and assume that not only worker can send a task result back to engine we?ll get our passive model. Instead of worker it can be anything else (some external system) that knows how to make this call. A particular way is not too important, it can be a direct message or it can be hidden behind an API method. In Mistral it?s now a REST API method however we?re about to decouple engine from REST API so that engine is a standalone process and listens to a queue. So worker-based model is basically the same with the only strict requirement that only worker sends a result back.\n\nIn order to implement local execution model on top of ?lazy execution model? we just need to abstract a transport (queue) so that we can use an in-process transport. That?s it. It?s what Mistral already has implemented. Again, we see that ?lazy execution model? is more universal.\n\nIMO this ?lazy execution model? should be the main execution model that TaskFlow supports, others can be easily implemented on top of it. But the opposite assertion is wrong. IMO this is the most important obstacle in all our discussions, the reason why we don?t always understand each other well enough. I know it may be a lot of work to shift a paradigm in TaskFlow team but if we did that we would get enough freedom for using TaskFlow in lots of cases.\n\nLet me know what you think. I might have missed something.\n\n> === HA ===\n> \n> So this is an interesting question, and to me is strongly connected to how your engines are executing (and the persistence and state-transitions that they go through while running). Without persistence of state and transitions there is no good way (a bad way of course can be created, by just redoing all the work, but that\'s not always feasible or the best option) to accomplish resuming in a sane manner and there is also imho no way to accomplish any type of automated HA of workflows. \n\nSure, no questions here.\n\n> Let me describe:\n> \n> When you save the states of a workflow and any intermediate results of a workflow to some database (for example) and the engine (see above models) which is being used (for example the conductor type from above) the application containing that engine may be prone to crashes (or just being powered off due to software upgrades...). Since taskflows key primitives were made to allow for resuming when a crash occurs, it is relatively simple to allow another application (also running a conductor) to resume whatever that prior application was doing when it crashed. Now most users of taskflow don\'t want to have to do this resumption manually (although they can if they want) so it would be expected that the other versions of that application would be running would automatically \'know\' how to \'take-over\' the work of the failed application. This is where the concept of the taskflows \'jobboard\' (http://tinyurl.com/klg358j) comes into play, where a jobboard can be backed by something like zookeeper (which provides notifications of lock lose/release to others automatically). The jobboard is the place where the other applications would be looking to \'take-over\' the other failed applications work (by using zookeeper \'atomic\' primitives designed for this type of usage) and they would also be releasing the work back for others to \'take-over\' when there own zookeeper connection is lost (zookeeper handles this this natively).\n\nInstead of inventing this jobboard built with Zookeeper which is not always welcome in the community, why not just use a queue with message acknowledgements? In case if engine instance is processing a task and it fails a message broker just resubmits the corresponding message automatically. This is a standard, e.g. RabbitMQ feature. Am I missing something important?\n\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n[0] https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/818b815c/attachment-0001.html>\n\n','<CF55CCA1.5A48B%harlowja@yahoo-inc.com>',NULL),('<04BE3DAF-1589-4615-80FF-9DFB27B32CDA@gmail.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-01-14 12:50:48',-28800,'2014-01-14 20:50:48',NULL,'[User-committee] 3 volunteers for Travel Committee','Stefano,\n\nIf you are short in candidates, let me know, i might be able to help, however, my schedule is tight. \n\nThanks,\n\nJC\nOn Jan 13, 2014, at 5:32 PM, Stefano Maffulli <stefano at openstack.org> wrote:\n\n> Hello folks,\n> \n> we\'re getting ready to assemble the Travel Committee that will help\n> decide who will be granted support to travel to Atlanta. We\'re looking\n> for a 2-3 of volunteers from the User Committee.\n> \n> Being a member of the committee requires a few hours of work to vote on\n> candidates\' applications between March 3rd and 24th.\n> \n> More details on the wiki:\n> https://wiki.openstack.org/wiki/Travel_Support_Program#Who_decides\n> \n> Please reply privately if you\'re willing to volunteer some time to help\n> fellows get to Atlanta without breaking the piggy bank.\n> \n> Cheers,\n> stef\n> \n> -- \n> Ask and answer questions on https://ask.openstack.org\n> \n> _______________________________________________\n> User-committee mailing list\n> User-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n\n\n','<52D49391.7040605@openstack.org>',NULL),('<04C12CE7-A794-42CD-BBC7-05E1172C2ABB@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-26 17:15:58',-14400,'2014-09-26 21:15:58',NULL,'[openstack-dev] [all] concrete proposal on changing the library\n	testing model with devstack-gate','\nOn Sep 26, 2014, at 4:50 PM, Sean Dague <sean at dague.net> wrote:\n\n> On 09/26/2014 04:22 PM, Doug Hellmann wrote:\n>> \n>> On Sep 26, 2014, at 2:27 PM, Sean Dague <sean at dague.net> wrote:\n>> \n>>> As we\'ve been talking about the test disaggregation the hamster wheels\n>>> in the back of my brain have been churning on the library testing\n>>> problem I think we currently have. Namely, openstack components mostly\n>>> don\'t rely on released library versions, they rely on git master of\n>>> them. Right now olso and many clients are open masters (their\n>>> stable/juno versions are out), but we\'ve still not cut RCs on servers.\n>>> So we\'re actually going to have a time rewind event as we start cutting\n>>> stables.\n>>> \n>>> We did this as a reaction to the fact that library releases were often\n>>> cratering the world. However, I think the current pattern leads us into\n>>> a much more dangerous world where basically the requirements.txt is invalid.\n>>> \n>>> So here is the particular unwind that I think would be useful here:\n>>> \n>>> 1) Change setup_library in devstack to be able to either setup the\n>>> library from git or install via pip. This would apply to all libraries\n>>> we are installing from oslo, the python clients, stackforge, etc.\n>>> Provide a mechanism to specify LIBRARIES_FROM_GIT (or something) so that\n>>> you can selectively decide to use libraries from git for development\n>>> purposes.\n>>> \n>>> 2) Default devstack to use pip released versions.\n>> \n>> These first 2 suggestions seem good. It makes our test configuration more accurate, and frees the Oslo team to have our dev cycle a little out of phase without worrying about breaking things. It means app developers will have to wait for fixes and features longer than they would otherwise, but Thierry has improved the automation for release tracking so we could release more often.\n>> \n>>> \n>>> 3) Change the job definition on the libraries to test against devstack\n>>> in check, not in gate. The library teams can decide if they want their\n>>> forward testing to be voting or not, but this is basically sniff testing\n>>> that when they release a new library they won\'t ruin the world for\n>>> everyone else.\n>> \n>> The other suggestions only work if we also have some job that does still use the source version of the libraries. A voting check job is good. Why would we not also do the test in the gate?\n> \n> Right, so the oslo-config devstack job sets\n> LIBRARIES_FROM_GIT=oslo.config. It tests with everything else from pip.\n> \n> So, honestly, we did this experiment with tempest. We voting check on a\n> lot more than we gate on. The only reason to rerun these same tests on\n> gate is if you believe compounding changes in your code can produce a\n> failure that was not found by testing the two patches independently.\n> Which, for something like Nova, has some really likelyhood. But I think\n> for libraries the likelihood is quite small. Small enough that you\n> relieve the pain of something completely outside of your control killing\n> a merge.\n> \n> If it was really an issue, then all future patches would fail check. So\n> you\'d be stuck there. But that just means you just need to make that\n> your next fix patch. I actually think in the library case it would be a\n> good high throughput model.\n\nOK, that makes sense.\n\n> \n>>> 4) If a ruin the world event happens, figure out how to prevent that\n>>> kind of event in local project testing, unit or functional. Basically an\n>>> unknown contract was broken. We should bring that contract back into the\n>>> project itself, or yell at the consuming project about why they were\n>>> using code in a crazy pants way.\n>>> \n>>> Additionally, I\'d like us to consider: No more alpha libraries. The\n>>> moment we\'ve bumped global requirements in projects we\'ve actually\n>>> released these libraries to production, as people are CDing the servers.\n>>> We should just be honest about that and just give things a real version.\n>>> Version numbers are cheap.\n>> \n>> Anyone following trunk is already expecting some pain, but the folks that follow the stable branches do it because we call them stable. We have been using alpha versions as a way to avoid throwing development versions of libraries into the stable branch test and production environments before they have had some runtime against master. It?s not so much an indication of the quality of the content of the package as a hack taking advantage of pip behaviors that don?t install pre-release packages unless specifically told do so, and a signal to distros that they don?t necessarily have to package those releases (I don?t know if they?re receiving that signal or not). If we stop using alpha version numbers, we need some other way to avoid having development releases end up in the stable test environments. Or to say explicitly that it?s OK if they do, I guess. \n> \n> So it seems to me that if you are running stable, you are probably not\n> going out of your way to run pip install -U on all the dependencies\n> every day. Honestly, you are probably not upgrading your dependencies\n> unless we issue a security alert on one of them. So I\'m not sure we\n> should make the \'I\'m running stable, but I blindly update all my\n> dependencies nightly\' a common use case.\n\nWell, no, that?s not it.\n\nThe stable branch tests in OUR environment use pip. We use an alpha version packaged as a wheel so old pips don?t see it and so new pips don?t install it because they have a version specifier that doesn?t include the alpha. Moving away from alphas makes it more likely OUR stable test environment will break.\n\nDistros, I hope/expect, do not package the alphas because, well, they?re marked as alpha. That means anyone installing distro updates won?t get new versions of the libs and can safely accept whatever updates the distros do deliver. Moving away from alphas makes it more likely the distros will package more frequent updates to the libraries, potentially breaking stable deployments. Now, there are a lot of other ways to test for that and deal with regressions, so maybe the solution is to put more testing into place. But we seem to be on a tear to reduce the number of actual test jobs we?re running, so we need to decide what balance to strike.\n\n\n> \n> Alternatively, we could actually semver cap on stable (yes we\'ve gone\n> around this mulberry bush before, but I think it might be time to\n> again), so new feature releases aren\'t impacting stable. That would\n> actually simplify a bunch of other oddities we end up having to handle\n> with stable requirements files.\n\nYes, that?s another alternative. I think we didn?t do that because of upgrades, though? Or maybe it was because we don?t assume that the next release of oslo.foo after 1.1 is 2.0, so how do we know where to cap it? I honestly can?t remember. If we can figure out a versioning scheme that allows us to cap safely and support upgrades and whatever else might have been the problem before, then we can put that on the table as an option, too.\n\n> \n>> I would also like to hear some from the distro packaging folks about what it would mean for us to be releasing regular version libraries frequently (expect at least one release every week for the entire cycle). Would you package all of those, or would you wait until closer to the end of the cycle and package the ?final? versions?\n> \n> Yep, I\'d definitely like to hear that as well.\n\nTo be clear, we would not release every library weekly, but we would have at least one library ready for a release every week. Likely more some weeks and fewer others, but one per week seems like a fair guess at an average.\n\nDoug\n\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5425D1AB.9040004@dague.net>',NULL),('<04C2AD0CCE86DD45B466F1979610144E46E214@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2014-01-15 16:57:34',0,'2014-01-15 16:57:34',NULL,'[openstack-qa] [Tempest - Stress Test] : implement a full SSH\n connection on \"ssh_floating.py\" and improve it','Hi everyone,\n\nI\'m quite new on OpenStack / Tempest and I\'m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test :)\n\nAt the moment the \"ssh_floating.py\" stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don\'t allow us to check if this instance is really available. I\'m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered \"ACTIVE\" but actually unusable.\n\nSo I\'m implementing a full SSH connection test using the \"paramiko\" SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don\'t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this \"ssh_floating.py\" script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[3DS Logo]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140115/cebd311b/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.gif\nType: image/gif\nSize: 5091 bytes\nDesc: image003.gif\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140115/cebd311b/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.jpg\nType: image/jpeg\nSize: 877 bytes\nDesc: image004.jpg\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140115/cebd311b/attachment.jpg>\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E470C72@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2014-01-16 17:20:02',0,'2014-01-16 17:20:02',NULL,'[openstack-qa] [Tempest - Stress Tests] : cleanup() removing\n resources for all tenants with an admin_manager','Hi everyone,\n\nI would like to discuss about the cleanup() process used right after a stress test run in Tempest.\n\nFor what I see now by using it and by reading the code, the cleanup() seems a bit rough since it is using an \"admin_manager\" in order to get all kind of test resources actually available : servers, key pairs, volumes, .etc...\nMore precisely, when it comes to clean servers, it is searching for servers on all tenants. I find this behavior a little rough since it will blow all objects on the target OpenStack, even object unrelated to the stress tests that just ran.\n\nActually before reading the cleanup() I had a problem when one of my stress test erased all the servers and volumes on another tenant, which impaired other people working on our OpenStack.\n\nI can imagine that for some scenarios, using an admin user to deeply clean an OpenStack is required, but I believe that most of the time the cleanup() process should focus only on the tenant used during the stress test and leave the other tenants alone.\n\nAm I doing something wrong ? Is there a way to restrain the cleanup() process ?\n\nIf no parameters or configuration allows me to do so, should I improve the cleanup() code in order to have this kind of configuration ?\nI do not wish to make this kind of code if the OpenStack community believe that the present behavior is totally intended and should not be modified.\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[3DS Logo]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140116/4bf7b85e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.gif\nType: image/gif\nSize: 5091 bytes\nDesc: image003.gif\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140116/4bf7b85e/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.jpg\nType: image/jpeg\nSize: 877 bytes\nDesc: image004.jpg\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140116/4bf7b85e/attachment.jpg>\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E471242@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 10:52:11',0,'2014-01-17 10:52:11',NULL,'[openstack-dev] [qa] RE: [Tempest - Stress Test] : implement a\n full SSH connection on \"ssh_floating.py\" and improve it','Hello Marc,\n\nThanks for your answer.\n\nAt the moment I\'m willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test.\nDoes this means that all stress tests available in \"tempest/stress\" should be ported as scenario tests with this decorator ?\n\nI do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks.\nI don\'t know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n\nBest Regards,\n\nJulien LELOUP\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 9:45 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Juilen,\n\nI forwarded your mail to the correct mailing list. Please do not use the qa list any longer.\n\nI am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55).\nUnfortunately it\'s not yet used for scenarios like you describe. I\'d suggest to build a scenario test in tempest/scenario and use this decorator on it.\n\nAny patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting\n(https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n\nRegards\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Wednesday, January 15, 2014 5:57 PM\nTo: openstack-qa at lists.openstack.org\nSubject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi everyone,\n\nI?m quite new on OpenStack / Tempest and I?m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ?\n\nAt the moment the ?ssh_floating.py? stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don?t allow us to check if this instance is really available. I?m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered ?ACTIVE? but actually unusable.\n\nSo I?m implementing a full SSH connection test using the ?paramiko? SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don?t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this ?ssh_floating.py? script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[cid:image003.gif at 01CF1216.D43ECE20]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n','<FD9023AAE9C10145BD4DDD6CB11F8D580D466F1FFC@QEO40075.de.t-online.corp>',NULL),('<04C2AD0CCE86DD45B466F1979610144E47132F@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 14:49:02',0,'2014-01-17 14:49:02',NULL,'[openstack-dev] [Tempest - Stress Test] : implement a full SSH\n connection on \"ssh_floating.py\" and improve it','Hi Marc,\n\nThe Etherpad you provided was helpful to know the current state of the stress tests.\n\nI admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology and a lot more on OpenStack/Tempest :) ).\nI used to run my test using \"./run_stress.py -t <JSON configuration pointing at my action/.py script> -d <duration>\", which allowed me to run only one test with a dedicated configuration (number of threads, ...)\n\nFor what I understand now in Tempest, I only managed to run all tests, using \"./run_tests.sh\" and the only configuration I found related to stress tests was the [stress] section in tempest.conf.\n\nFor example : let say I ported my SSH stress test as a scenario test with the @stresstest decorator.\nHow can I launch this test (and only this one) and use a dedicated configuration file like ones we can found in \"tempest/stress/etc\" ?\n\nAnother question I have now : in the case that I have to use \"run_test.sh\" and not \"run_stress.py\" anymore, how do I get the test runs statistics I used to have, and where should I put some code to improve them ?\n\nWhen I will have cleared my mind with all these kinds of practical details, maybe I should add some content on the Wiki about stress tests in Tempest.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 3:07 PM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Julien,\n\nmost of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them.\n\nBTW here is the Etherpad from the summit talk that we had:\nhttps://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests\n\nIt possible help to understand the state. I didn\'t managed to work on the action items that are left.\n\nYour suggestions sound good. So I\'d happy so see some patches :)\n\nRegards\nMarc\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 11:52 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks for your answer.\n\nAt the moment I\'m willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test.\nDoes this means that all stress tests available in \"tempest/stress\" should be ported as scenario tests with this decorator ?\n\nI do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks.\nI don\'t know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n\nBest Regards,\n\nJulien LELOUP\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 9:45 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Juilen,\n\nI forwarded your mail to the correct mailing list. Please do not use the qa list any longer.\n\nI am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55).\nUnfortunately it\'s not yet used for scenarios like you describe. I\'d suggest to build a scenario test in tempest/scenario and use this decorator on it.\n\nAny patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting\n(https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n\nRegards\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Wednesday, January 15, 2014 5:57 PM\nTo: openstack-qa at lists.openstack.org\nSubject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi everyone,\n\nI?m quite new on OpenStack / Tempest and I?m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ?\n\nAt the moment the ?ssh_floating.py? stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don?t allow us to check if this instance is really available. I?m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered ?ACTIVE? but actually unusable.\n\nSo I?m implementing a full SSH connection test using the ?paramiko? SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don?t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this ?ssh_floating.py? script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[cid:image003.gif at 01CF1216.D43ECE20]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E4718D9@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 10:54:48',0,'2014-01-20 10:54:48',NULL,'[openstack-dev] [qa] [Tempest - Stress Test] : implement a full\n SSH connection on \"ssh_floating.py\" and improve it','Hello Marc,\n\nThanks again for your help, your blog post is helpful.\n\nSo I will start writing a new scenario test to get this full SSH stress test on newly created VM.\nI will put more details about it in the blueprint I created for this : https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Saturday, January 18, 2014 10:11 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Julien,\n\nmaybe my blog post helps you with some more details:\n\nhttp://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html\n\nYou can run single test if you add a new json file with the test function you want to test. Like:\nhttps://github.com/openstack/tempest/blob/master/tempest/stress/etc/sample-unit-test.json\n\nWith that you can launch them with the parameters you already described.\n\nRegards,\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 3:49 PM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Marc,\n\nThe Etherpad you provided was helpful to know the current state of the stress tests.\n\nI admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology and a lot more on OpenStack/Tempest :) ).\nI used to run my test using \"./run_stress.py -t <JSON configuration pointing at my action/.py script> -d <duration>\", which allowed me to run only one test with a dedicated configuration (number of threads, ...)\n\nFor what I understand now in Tempest, I only managed to run all tests, using \"./run_tests.sh\" and the only configuration I found related to stress tests was the [stress] section in tempest.conf.\n\nFor example : let say I ported my SSH stress test as a scenario test with the @stresstest decorator.\nHow can I launch this test (and only this one) and use a dedicated configuration file like ones we can found in \"tempest/stress/etc\" ?\n\nAnother question I have now : in the case that I have to use \"run_test.sh\" and not \"run_stress.py\" anymore, how do I get the test runs statistics I used to have, and where should I put some code to improve them ?\n\nWhen I will have cleared my mind with all these kinds of practical details, maybe I should add some content on the Wiki about stress tests in Tempest.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 3:07 PM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Julien,\n\nmost of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them.\n\nBTW here is the Etherpad from the summit talk that we had:\nhttps://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests\n\nIt possible help to understand the state. I didn\'t managed to work on the action items that are left.\n\nYour suggestions sound good. So I\'d happy so see some patches :)\n\nRegards\nMarc\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 11:52 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks for your answer.\n\nAt the moment I\'m willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test.\nDoes this means that all stress tests available in \"tempest/stress\" should be ported as scenario tests with this decorator ?\n\nI do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks.\nI don\'t know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n\nBest Regards,\n\nJulien LELOUP\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 9:45 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Juilen,\n\nI forwarded your mail to the correct mailing list. Please do not use the qa list any longer.\n\nI am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55).\nUnfortunately it\'s not yet used for scenarios like you describe. I\'d suggest to build a scenario test in tempest/scenario and use this decorator on it.\n\nAny patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting\n(https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n\nRegards\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Wednesday, January 15, 2014 5:57 PM\nTo: openstack-qa at lists.openstack.org\nSubject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi everyone,\n\nI?m quite new on OpenStack / Tempest and I?m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ?\n\nAt the moment the ?ssh_floating.py? stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don?t allow us to check if this instance is really available. I?m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered ?ACTIVE? but actually unusable.\n\nSo I?m implementing a full SSH connection test using the ?paramiko? SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don?t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this ?ssh_floating.py? script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[cid:image003.gif at 01CF1216.D43ECE20]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n','<FD9023AAE9C10145BD4DDD6CB11F8D580D466F2001@QEO40075.de.t-online.corp>',NULL),('<04C2AD0CCE86DD45B466F1979610144E471A89@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 16:32:18',0,'2014-01-20 16:32:18',NULL,'[openstack-dev] [Tempest - Stress test] : cleanup() removing\n resources for all tenants with an admin_manager','Hi everyone,\n\nI\'m forwarding my own email previously posted on the QA list.\n\nI would like to discuss about the cleanup() process used right after a stress test run in Tempest.\n\nFor what I see now by using it and by reading the code, the cleanup() seems a bit rough since it is using an \"admin_manager\" in order to get all kind of test resources actually available : servers, key pairs, volumes, .etc...\nMore precisely, when it comes to clean servers, it is searching for servers on all tenants. I find this behavior a little rough since it will blow all objects on the target OpenStack, even object unrelated to the stress tests that just ran.\n\nActually before reading the cleanup() I had a problem when one of my stress test erased all the servers and volumes on another tenant, which impaired other people working on our OpenStack.\n\nI can imagine that for some scenarios, using an admin user to deeply clean an OpenStack is required, but I believe that most of the time the cleanup() process should focus only on the tenant used during the stress test and leave the other tenants alone.\n\nAm I doing something wrong ? Is there a way to restrain the cleanup() process ?\n\nIf no parameters or configuration allows me to do so, should I improve the cleanup() code in order to allow it to remove only the test resources created for the test?\nI do not wish to make this kind of code if the OpenStack community believe that the present behavior is totally intended and should not be modified.\n\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/61f2b1a7/attachment.html>\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E471C6D@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 10:34:03',0,'2014-01-21 10:34:03',NULL,'[openstack-dev] [Tempest - Stress test] : cleanup() removing\n resources for all tenants with an admin_manager','Hello Boris,\n\nI\'ll check Rally in order to see what tool is the best for my tests.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\nFrom: Boris Pavlovic [mailto:bpavlovic at mirantis.com]\nSent: Monday, January 20, 2014 5:52 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Tempest - Stress test] : cleanup() removing resources for all tenants with an admin_manager\n\nJulien,\n\nProbably you should try to use Rally for benchmarking.\nhttps://wiki.openstack.org/wiki/Rally\n\nThere is already working generic cleanup...\n\nThere is already implemented framework that allows parametrized benchmarks:\nhttps://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L32-L39\n\nSimple way to configure load using json (load will be created from real users, no admin, that will be pre created for each benchmark):\nhttps://github.com/stackforge/rally/blob/master/doc/samples/tasks/nova/boot-and-delete.json\n\n\nAnd simple CLI interface (now we are working around Web UI)\n\n\nBest regards,\nBoris Pavlovic\n\nOn Mon, Jan 20, 2014 at 8:32 PM, LELOUP Julien <Julien.LELOUP at 3ds.com<mailto:Julien.LELOUP at 3ds.com>> wrote:\nHi everyone,\n\nI\'m forwarding my own email previously posted on the QA list.\n\nI would like to discuss about the cleanup() process used right after a stress test run in Tempest.\n\nFor what I see now by using it and by reading the code, the cleanup() seems a bit rough since it is using an \"admin_manager\" in order to get all kind of test resources actually available : servers, key pairs, volumes, .etc...\nMore precisely, when it comes to clean servers, it is searching for servers on all tenants. I find this behavior a little rough since it will blow all objects on the target OpenStack, even object unrelated to the stress tests that just ran.\n\nActually before reading the cleanup() I had a problem when one of my stress test erased all the servers and volumes on another tenant, which impaired other people working on our OpenStack.\n\nI can imagine that for some scenarios, using an admin user to deeply clean an OpenStack is required, but I believe that most of the time the cleanup() process should focus only on the tenant used during the stress test and leave the other tenants alone.\n\nAm I doing something wrong ? Is there a way to restrain the cleanup() process ?\n\nIf no parameters or configuration allows me to do so, should I improve the cleanup() code in order to allow it to remove only the test resources created for the test?\nI do not wish to make this kind of code if the OpenStack community believe that the present behavior is totally intended and should not be modified.\n\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com<mailto:julien.leloup at 3ds.com>\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140121/31a9d411/attachment.html>\n\n','<CAD85om2pZmaYk_+o7RUQ_HLj_Zk+8hVTi9aiPUL0aMA+oeESOw@mail.gmail.com>',NULL),('<04C2AD0CCE86DD45B466F1979610144E4738B7@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 14:55:38',0,'2014-01-27 14:55:38',NULL,'[openstack-dev] [Tempest - Stress test] : cleanup() removing\n resources for all tenants with an admin_manager','Hello Boris,\n\nRally seemes to be a really interesting tool and I will eventually using it for full scale benchmarking.\n\nHowever I will focus on tempest based tests for the time being in order to have these tests replayed regularly during the integration process.\nI believe that my needs are covered by both Tempest and Rally and if time allow me to do so, I will submit the same kind of scenario for full scale benchmarking.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\nFrom: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\nSent: Tuesday, January 21, 2014 11:34 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Tempest - Stress test] : cleanup() removing resources for all tenants with an admin_manager\n\nHello Boris,\n\nI\'ll check Rally in order to see what tool is the best for my tests.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com<mailto:julien.leloup at 3ds.com>\n\n\nFrom: Boris Pavlovic [mailto:bpavlovic at mirantis.com]\nSent: Monday, January 20, 2014 5:52 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Tempest - Stress test] : cleanup() removing resources for all tenants with an admin_manager\n\nJulien,\n\nProbably you should try to use Rally for benchmarking.\nhttps://wiki.openstack.org/wiki/Rally\n\nThere is already working generic cleanup...\n\nThere is already implemented framework that allows parametrized benchmarks:\nhttps://github.com/stackforge/rally/blob/master/rally/benchmark/scenarios/nova/servers.py#L32-L39\n\nSimple way to configure load using json (load will be created from real users, no admin, that will be pre created for each benchmark):\nhttps://github.com/stackforge/rally/blob/master/doc/samples/tasks/nova/boot-and-delete.json\n\n\nAnd simple CLI interface (now we are working around Web UI)\n\n\nBest regards,\nBoris Pavlovic\n\nOn Mon, Jan 20, 2014 at 8:32 PM, LELOUP Julien <Julien.LELOUP at 3ds.com<mailto:Julien.LELOUP at 3ds.com>> wrote:\nHi everyone,\n\nI\'m forwarding my own email previously posted on the QA list.\n\nI would like to discuss about the cleanup() process used right after a stress test run in Tempest.\n\nFor what I see now by using it and by reading the code, the cleanup() seems a bit rough since it is using an \"admin_manager\" in order to get all kind of test resources actually available : servers, key pairs, volumes, .etc...\nMore precisely, when it comes to clean servers, it is searching for servers on all tenants. I find this behavior a little rough since it will blow all objects on the target OpenStack, even object unrelated to the stress tests that just ran.\n\nActually before reading the cleanup() I had a problem when one of my stress test erased all the servers and volumes on another tenant, which impaired other people working on our OpenStack.\n\nI can imagine that for some scenarios, using an admin user to deeply clean an OpenStack is required, but I believe that most of the time the cleanup() process should focus only on the tenant used during the stress test and leave the other tenants alone.\n\nAm I doing something wrong ? Is there a way to restrain the cleanup() process ?\n\nIf no parameters or configuration allows me to do so, should I improve the cleanup() code in order to allow it to remove only the test resources created for the test?\nI do not wish to make this kind of code if the OpenStack community believe that the present behavior is totally intended and should not be modified.\n\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com<mailto:julien.leloup at 3ds.com>\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140127/2d9ff69d/attachment.html>\n\n','<04C2AD0CCE86DD45B466F1979610144E471C6D@EU-DCC-MBX11.dsone.3ds.com>',NULL),('<04C2AD0CCE86DD45B466F1979610144E4738CF@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 15:01:08',0,'2014-01-27 15:01:08',NULL,'[openstack-dev] [Tempest - Stress Test] : some improvements /\n issues on the stress test framework','Hi everyone,\n\nI would like to discuss some ideas / behavior that seems broken in the stress test part of Tempest.\n\nI opened some tickets in Launchpad and I would like to get the feedback of the community on these ideas / issues :\n\n- Provide kwargs from UnitTest to stress test scenarios (https://bugs.launchpad.net/tempest/+bug/1273186 )\n\n- Stress Test - tearDown() not called if an exception occurred  (https://bugs.launchpad.net/tempest/+bug/1273245 )\n\n- Stress Test - cleanUp() removing all test resources as an admin (https://bugs.launchpad.net/tempest/+bug/1273254 )\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E473E3F@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 08:40:50',0,'2014-01-28 08:40:50',NULL,'[openstack-dev] [qa] [Tempest - Stress Test] : some\n improvements / issues on the stress test framework','Hi Marc,\n\nRight I won\'t forget the [qa] tag anymore :)\n\nConcerning #1273186, actually I wasn\'t thinking of a change in the CLI, only provide the \"kwargs\" instance used in \"UnitTest\" to the stress test scenario during the setUpClass() call.\nFor now \"setUpClass()\" is called without any arguments : by calling it this way \"setUpClass(**kwargs)\" I believe we will be able to provide some configuration parameters in the JSON file stored in \"stress/etc/\" in the stress test scenario through the \"UnitTest\" instance.\nWhat do you think ?\n\nI didn\'t made any code for the two other reports by now, I wanted to get a feedback before doing anything.\nEven if I won\'t have a lot of time to work on Tempest in the near future, I believe these two patches are small enough for me to push and follow them.\nI will assign one first and after fighting with Gerrit I will see for getting through the second one :)\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Monday, January 27, 2014 6:33 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: LELOUP Julien\nSubject: RE: [qa] [Tempest - Stress Test] : some improvements / issues on the stress test framework\n\nHi Julien,\n\nplease don\'t forget the [qa] tag - otherwise your lost in the ML noise ;)\n\nOk thanks for the bug reports. I confirmed 1273245 and 1273254 but I am not totally sure with 1273186.\nCould you give some more details how the CLI interface will look like? Or simply propose a patch.\nIt could end up in a quite confusing interface.. if you allow kwargs for such a generic case.\n\nAre you already working on those bugs? If yes, could you assign them to you?\n\nRegards,\nMarc\n\n> ________________________________________\n> From: LELOUP Julien [Julien.LELOUP at 3ds.com]\n> Sent: Monday, January 27, 2014 4:01 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: [openstack-dev] [Tempest - Stress Test] : some improvements / issues on the stress test framework\n>\n> Hi everyone,\n>\n> I would like to discuss some ideas / behavior that seems broken in the stress test part of Tempest.\n>\n> I opened some tickets in Launchpad and I would like to get the feedback of the community on these ideas / issues :\n>\n> - Provide kwargs from UnitTest to stress test scenarios (https://bugs.launchpad.net/tempest/+bug/1273186 )\n>\n> - Stress Test - tearDown() not called if an exception occurred  (https://bugs.launchpad.net/tempest/+bug/1273245 )\n>\n> - Stress Test - cleanUp() removing all test resources as an admin (https://bugs.launchpad.net/tempest/+bug/1273254 )\n>\n> Best Regards,\n>\n> Julien LELOUP\n> julien.leloup at 3ds.com\n>\n>\n> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n>\n> If you are not one of the named recipients or have received this email in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n\n','<FD9023AAE9C10145BD4DDD6CB11F8D580D466F200A@QEO40075.de.t-online.corp>',NULL),('<04C2AD0CCE86DD45B466F1979610144E479F1F@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 16:01:40',0,'2014-02-17 16:01:40',NULL,'[openstack-dev] [qa] [Tempest - Stress Test] : implement a full\n SSH connection on \"ssh_floating.py\" and improve it','Hello Marc,\n\nI\'m raising this subject again since I have pushed a patch set implementing this SSH stress test in Tempest.\nAs you suggested, I wrote it as a scenario test : I\'m currently using it to check the ability of my stack to launch x servers at the same time and having them fully available to use.\n\nAs a reminder, here is the Blueprint : https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip\n\nPlese feel free to check it and make feedback :)\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\nSent: Monday, January 20, 2014 11:55 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks again for your help, your blog post is helpful.\n\nSo I will start writing a new scenario test to get this full SSH stress test on newly created VM.\nI will put more details about it in the blueprint I created for this : https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Saturday, January 18, 2014 10:11 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Julien,\n\nmaybe my blog post helps you with some more details:\n\nhttp://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html\n\nYou can run single test if you add a new json file with the test function you want to test. Like:\nhttps://github.com/openstack/tempest/blob/master/tempest/stress/etc/sample-unit-test.json\n\nWith that you can launch them with the parameters you already described.\n\nRegards,\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 3:49 PM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Marc,\n\nThe Etherpad you provided was helpful to know the current state of the stress tests.\n\nI admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology and a lot more on OpenStack/Tempest :) ).\nI used to run my test using \"./run_stress.py -t <JSON configuration pointing at my action/.py script> -d <duration>\", which allowed me to run only one test with a dedicated configuration (number of threads, ...)\n\nFor what I understand now in Tempest, I only managed to run all tests, using \"./run_tests.sh\" and the only configuration I found related to stress tests was the [stress] section in tempest.conf.\n\nFor example : let say I ported my SSH stress test as a scenario test with the @stresstest decorator.\nHow can I launch this test (and only this one) and use a dedicated configuration file like ones we can found in \"tempest/stress/etc\" ?\n\nAnother question I have now : in the case that I have to use \"run_test.sh\" and not \"run_stress.py\" anymore, how do I get the test runs statistics I used to have, and where should I put some code to improve them ?\n\nWhen I will have cleared my mind with all these kinds of practical details, maybe I should add some content on the Wiki about stress tests in Tempest.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 3:07 PM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Julien,\n\nmost of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them.\n\nBTW here is the Etherpad from the summit talk that we had:\nhttps://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests\n\nIt possible help to understand the state. I didn\'t managed to work on the action items that are left.\n\nYour suggestions sound good. So I\'d happy so see some patches :)\n\nRegards\nMarc\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 11:52 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks for your answer.\n\nAt the moment I\'m willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test.\nDoes this means that all stress tests available in \"tempest/stress\" should be ported as scenario tests with this decorator ?\n\nI do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks.\nI don\'t know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n\nBest Regards,\n\nJulien LELOUP\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 9:45 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Juilen,\n\nI forwarded your mail to the correct mailing list. Please do not use the qa list any longer.\n\nI am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55).\nUnfortunately it\'s not yet used for scenarios like you describe. I\'d suggest to build a scenario test in tempest/scenario and use this decorator on it.\n\nAny patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting\n(https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n\nRegards\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Wednesday, January 15, 2014 5:57 PM\nTo: openstack-qa at lists.openstack.org\nSubject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi everyone,\n\nI?m quite new on OpenStack / Tempest and I?m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ?\n\nAt the moment the ?ssh_floating.py? stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don?t allow us to check if this instance is really available. I?m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered ?ACTIVE? but actually unusable.\n\nSo I?m implementing a full SSH connection test using the ?paramiko? SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don?t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this ?ssh_floating.py? script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[cid:image003.gif at 01CF1216.D43ECE20]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n','<04C2AD0CCE86DD45B466F1979610144E4718D9@EU-DCC-MBX11.dsone.3ds.com>',NULL),('<04C2AD0CCE86DD45B466F1979610144E47B511@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 10:18:17',0,'2014-02-24 10:18:17',NULL,'[openstack-dev] [qa] : error during\n \"gate-tempest-dsvm-neutron-large-ops\" when attaching floating IP','Hello everyone,\n\nI\'m currently pushing a stress test in Tempest which at some point tries to attach a floating IP to newly started servers . The change I\'m talking about is available here : https://review.openstack.org/#/c/74067/ .\n\nThis test runs fine on my local devstack, but I have an issue during Jenkins tests, on the gate \'gate-tempest-dsvm-neutron-large-ops\'.\nThe error happen when my test wants to attach a floating IP using the Neutron API :\n\n*         Last week, the error was about the fact that no ports was attached to my servers : I wasn\'t specifying any nics during the server creation, but since there was only one network available from the nova point of view, I believed it was automatically attached to my server, thus creating a port for it. This explains why this code is working on my local devstack and openstack deployment.\n\n*         In order to resolve this I\'m currently forcing the \'nics\' parameter during the server creation in order to have my server attached to the \'private\' network and so have a port to use later during floating IP attachment. This triggers a new error : I can request Neutron to get the UUID of the network named \'private\', but when I\'m specifying this UUID in the \'nics\' parameter, I get an error saying that this network is not found.\n\nI don\'t know if the issue is related to my code, the tempest configuration used in the gate or the devstack deployed for the gate.\n\nCan someone give me some insights about this gate ? Is there something peculiar in the devstack deployment used for this gate that can explain the errors I\'m having ?\n\nThanks in advance for your time :)\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/04482e7b/attachment.html>\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E47E196@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 10:20:32',0,'2014-03-03 10:20:32',NULL,'[openstack-dev] [Tempest - Stress Test][qa] : implement a full SSH\n connection on \"ssh_floating.py\" and improve it','Hello,\n\nIt tourns out that this stress test maybe not implemented in the right place.\n\nAt ther moment I have put the SSH stress test in large_ops but Joe Gordon pointed (in https://review.openstack.org/#/c/74067/) that the large_ops gates are not meant to launch real servers.\n\nSo where should I put this test ? I\'m thinking of creating a new scenario file inheriting of the class specified in the large_ops file (TestLargeOpsScenario) in order to avoid duplicating the \"nova_boot\" method.\nIs it OK for you ?\n\nIs there a better place where I should put my test ?\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\n-----Original Message-----\nFrom: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\nSent: Monday, February 17, 2014 5:02 PM\nTo: OpenStack Development Mailing List (not for usage questions); Koderer, Marc\nSubject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nI\'m raising this subject again since I have pushed a patch set implementing this SSH stress test in Tempest.\nAs you suggested, I wrote it as a scenario test : I\'m currently using it to check the ability of my stack to launch x servers at the same time and having them fully available to use.\n\nAs a reminder, here is the Blueprint : https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip\n\nPlese feel free to check it and make feedback :)\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\nSent: Monday, January 20, 2014 11:55 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks again for your help, your blog post is helpful.\n\nSo I will start writing a new scenario test to get this full SSH stress test on newly created VM.\nI will put more details about it in the blueprint I created for this : https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floating-ip\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Saturday, January 18, 2014 10:11 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Julien,\n\nmaybe my blog post helps you with some more details:\n\nhttp://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html\n\nYou can run single test if you add a new json file with the test function you want to test. Like:\nhttps://github.com/openstack/tempest/blob/master/tempest/stress/etc/sample-unit-test.json\n\nWith that you can launch them with the parameters you already described.\n\nRegards,\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 3:49 PM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Marc,\n\nThe Etherpad you provided was helpful to know the current state of the stress tests.\n\nI admit that I have some difficulties to understand how I can run a single test built with the @stresstest decorator (even not a beginner in Python, I still have things to learn on this technology and a lot more on OpenStack/Tempest :) ).\nI used to run my test using \"./run_stress.py -t <JSON configuration pointing at my action/.py script> -d <duration>\", which allowed me to run only one test with a dedicated configuration (number of threads, ...)\n\nFor what I understand now in Tempest, I only managed to run all tests, using \"./run_tests.sh\" and the only configuration I found related to stress tests was the [stress] section in tempest.conf.\n\nFor example : let say I ported my SSH stress test as a scenario test with the @stresstest decorator.\nHow can I launch this test (and only this one) and use a dedicated configuration file like ones we can found in \"tempest/stress/etc\" ?\n\nAnother question I have now : in the case that I have to use \"run_test.sh\" and not \"run_stress.py\" anymore, how do I get the test runs statistics I used to have, and where should I put some code to improve them ?\n\nWhen I will have cleared my mind with all these kinds of practical details, maybe I should add some content on the Wiki about stress tests in Tempest.\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 3:07 PM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi Julien,\n\nmost of the cases in tempest/stress are already covered by exiting tests in /api or /scenario. The only thing that is missing is the decorator on them.\n\nBTW here is the Etherpad from the summit talk that we had:\nhttps://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests\n\nIt possible help to understand the state. I didn\'t managed to work on the action items that are left.\n\nYour suggestions sound good. So I\'d happy so see some patches :)\n\nRegards\nMarc\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Friday, January 17, 2014 11:52 AM\nTo: Koderer, Marc\nCc: openstack-dev at lists.openstack.org\nSubject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Marc,\n\nThanks for your answer.\n\nAt the moment I\'m willing to spend some time on this kind of scenario so I will see how to use the stress decorator inside a scenario test.\nDoes this means that all stress tests available in \"tempest/stress\" should be ported as scenario tests with this decorator ?\n\nI do have some ideas about features on stress test that I find useful for my own use case : like adding more statistics on stress test runs in order to use them as benchmarks.\nI don\'t know if this kind of feature was already discussed in the OpenStack community but since stress tests are a bit deprecated now, maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n\nBest Regards,\n\nJulien LELOUP\n\n-----Original Message-----\nFrom: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Friday, January 17, 2014 9:45 AM\nTo: LELOUP Julien\nCc: openstack-dev at lists.openstack.org\nSubject: [qa] RE: [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHello Juilen,\n\nI forwarded your mail to the correct mailing list. Please do not use the qa list any longer.\n\nI am happy that you are interested in stress tests. All the tests in tempest/stress/actions are more or less deprecated. So what you should use instead is the stress decorator (e.g. https://github.com/openstack/tempest/blob/master/tempest/api/volume/test_volumes_actions.py#L55).\nUnfortunately it\'s not yet used for scenarios like you describe. I\'d suggest to build a scenario test in tempest/scenario and use this decorator on it.\n\nAny patch like that is welcome on gerrit. If you are planning to work in that area for more than just a patch, a blueprint would be nice. A good way to coordinate your efforts is also in the QA meeting\n(https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n\nRegards\nMarc\n\n________________________________________\nFrom: LELOUP Julien [Julien.LELOUP at 3ds.com]\nSent: Wednesday, January 15, 2014 5:57 PM\nTo: openstack-qa at lists.openstack.org\nSubject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\nHi everyone,\n\nI?m quite new on OpenStack / Tempest and I?m actually working on stress tests. I want to suggest a new feature in a currently available stress test.\nNot sure if this email should be posted on the QA mailing list or the dev mailing list, but I give it a try here since it is about a Tempest stress test ?\n\nAt the moment the ?ssh_floating.py? stress test seems really interesting but I would like to improve it a bit.\n\nBy now this script is simulating an SSH connection by binding a TCP socket on the newly created instance. But this test don?t allow us to check if this instance is really available. I?m mostly thinking about the metadata service unable to provide the SSH key pair to the instance, but surely other scenarios can lead to an instance considered ?ACTIVE? but actually unusable.\n\nSo I?m implementing a full SSH connection test using the ?paramiko? SSH library and a key pair generated in the same way the other test resources are managed in this script : either one SSH key pair for every test runs or a new key pair for each run (depends on the JSON configuration file).\nI don?t plan to remove the old test (TCP socket binding), rather move this one on a separate test function and put the full SSH connection test code instead.\n\nIs this feature interesting for the OpenStack community ?\nShould I create a blueprint on the Tempest project on Launchpad in order to provide my code through Gerrit ?\n\nOn a second time, I plan to overhaul improve this ?ssh_floating.py? script by clean the code a little bit, and add more cleaning code in order to avoid leaving instances/security groups/floating IP behind : I do have this kind of behavior right now and I already improved the teardown() on this way.\n\nShould I consider this code as a new functionality (thus create a blueprint) or should I create a defect and assign it to myself ?\n\nCordialement / Best Regards,\n\nJulien LELOUP\n\nR&D 3DExperience Platform IaaS Factory Technology Engineer\n\n\n\n\n\njulien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n\n[cid:image003.gif at 01CF1216.D43ECE20]\n\n3DS.COM<http://www.3ds.com/>\n\n\nDassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-Villacoublay Cedex | France\n\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n',NULL,NULL),('<04C2AD0CCE86DD45B466F1979610144E47E784@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 10:34:12',0,'2014-03-04 10:34:12',NULL,'[openstack-dev] [Tempest - Stress Test][qa] : implement a full\n SSH connection on \"ssh_floating.py\" and improve it','From: Koderer, Marc [mailto:m.koderer at telekom.de]\nSent: Tuesday, March 04, 2014 10:41 AM\nTo: LELOUP Julien; OpenStack Development Mailing List (not for usage questions)\nSubject: AW: [Tempest - Stress Test][qa] : implement a full SSH connection on \"ssh_floating.py\" and improve it\n\n>>\n>> So where should I put this test ? I\'m thinking of creating a new\n>> scenario file inheriting of the class specified in the large_ops file\n>> (TestLargeOpsScenario) in order to avoid duplicating the \"nova_boot\"\n>> method.\n>> Is it OK for you ?\n>>\n>> Is there a better place where I should put my test ?\n\n>I mean we still have the tempest/stress/actions/ and we could put something like that in there. In general I would like to discuss this topic in the next QA meeting..\n>@Julien: are you able to join the next meeting? It would be 22:00 UTC.\n\n@Marc : so next Thrusday (3/6/2014) ? Yes I can be there.\n\n>\n> Best Regards,\n>\n> Julien LELOUP\n> julien.leloup at 3ds.com\n>\n\nRegards,\nMarc\n\n\n>\n> -----Original Message-----\n> From: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\n> Sent: Monday, February 17, 2014 5:02 PM\n> To: OpenStack Development Mailing List (not for usage questions);\n> Koderer, Marc\n> Subject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement\n> a full SSH connection on \"ssh_floating.py\" and improve it\n>\n> Hello Marc,\n>\n> I\'m raising this subject again since I have pushed a patch set\n> implementing this SSH stress test in Tempest.\n> As you suggested, I wrote it as a scenario test : I\'m currently using\n> it to check the ability of my stack to launch x servers at the same\n> time and having them fully available to use.\n>\n> As a reminder, here is the Blueprint :\n> https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floatin\n> g-ip\n>\n> Plese feel free to check it and make feedback :)\n>\n> Best Regards,\n>\n> Julien LELOUP\n> julien.leloup at 3ds.com\n>\n> -----Original Message-----\n> From: LELOUP Julien [mailto:Julien.LELOUP at 3ds.com]\n> Sent: Monday, January 20, 2014 11:55 AM\n> To: Koderer, Marc\n> Cc: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [qa] [Tempest - Stress Test] : implement\n> a full SSH connection on \"ssh_floating.py\" and improve it\n>\n> Hello Marc,\n>\n> Thanks again for your help, your blog post is helpful.\n>\n> So I will start writing a new scenario test to get this full SSH\n> stress test on newly created VM.\n> I will put more details about it in the blueprint I created for this :\n> https://blueprints.launchpad.net/tempest/+spec/stress-test-ssh-floatin\n> g-ip\n>\n> Best Regards,\n>\n> Julien LELOUP\n> julien.leloup at 3ds.com\n>\n>\n> -----Original Message-----\n> From: Koderer, Marc [mailto:m.koderer at telekom.de]\n> Sent: Saturday, January 18, 2014 10:11 AM\n> To: LELOUP Julien\n> Cc: openstack-dev at lists.openstack.org\n> Subject: RE: [qa] [Tempest - Stress Test] : implement a full SSH\n> connection on \"ssh_floating.py\" and improve it\n>\n> Hello Julien,\n>\n> maybe my blog post helps you with some more details:\n>\n> http://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-\n> testing.html\n>\n> You can run single test if you add a new json file with the test\n> function you want to test. Like:\n> https://github.com/openstack/tempest/blob/master/tempest/stress/etc/sa\n> mple\n> -unit-test.json\n>\n> With that you can launch them with the parameters you already described.\n>\n> Regards,\n> Marc\n>\n> ________________________________________\n> From: LELOUP Julien [Julien.LELOUP at 3ds.com]\n> Sent: Friday, January 17, 2014 3:49 PM\n> To: Koderer, Marc\n> Cc: openstack-dev at lists.openstack.org\n> Subject: RE: [Tempest - Stress Test] : implement a full SSH connection\n> on \"ssh_floating.py\" and improve it\n>\n> Hi Marc,\n>\n> The Etherpad you provided was helpful to know the current state of the\n> stress tests.\n>\n> I admit that I have some difficulties to understand how I can run a\n> single test built with the @stresstest decorator (even not a beginner\n> in Python, I still have things to learn on this technology and a lot\n> more on OpenStack/Tempest :) ).\n> I used to run my test using \"./run_stress.py -t <JSON configuration\n> pointing at my action/.py script> -d <duration>\", which allowed me to\n> run only one test with a dedicated configuration (number of threads,\n> ...)\n>\n> For what I understand now in Tempest, I only managed to run all tests,\n> using \"./run_tests.sh\" and the only configuration I found related to\n> stress tests was the [stress] section in tempest.conf.\n>\n> For example : let say I ported my SSH stress test as a scenario test\n> with the @stresstest decorator.\n> How can I launch this test (and only this one) and use a dedicated\n> configuration file like ones we can found in \"tempest/stress/etc\" ?\n>\n> Another question I have now : in the case that I have to use \"run_test.sh\"\n> and not \"run_stress.py\" anymore, how do I get the test runs statistics\n> I used to have, and where should I put some code to improve them ?\n>\n> When I will have cleared my mind with all these kinds of practical\n> details, maybe I should add some content on the Wiki about stress\n> tests in Tempest.\n>\n> Best Regards,\n>\n> Julien LELOUP\n> julien.leloup at 3ds.com\n>\n> -----Original Message-----\n> From: Koderer, Marc [mailto:m.koderer at telekom.de]\n> Sent: Friday, January 17, 2014 3:07 PM\n> To: LELOUP Julien\n> Cc: openstack-dev at lists.openstack.org\n> Subject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH\n> connection on \"ssh_floating.py\" and improve it\n>\n> Hi Julien,\n>\n> most of the cases in tempest/stress are already covered by exiting\n> tests in /api or /scenario. The only thing that is missing is the\n> decorator on them.\n>\n> BTW here is the Etherpad from the summit talk that we had:\n> https://etherpad.openstack.org/p/icehouse-summit-qa-stress-tests\n>\n> It possible help to understand the state. I didn\'t managed to work on\n> the action items that are left.\n>\n> Your suggestions sound good. So I\'d happy so see some patches :)\n>\n> Regards\n> Marc\n> ________________________________________\n> From: LELOUP Julien [Julien.LELOUP at 3ds.com]\n> Sent: Friday, January 17, 2014 11:52 AM\n> To: Koderer, Marc\n> Cc: openstack-dev at lists.openstack.org\n> Subject: RE: [qa] RE: [Tempest - Stress Test] : implement a full SSH\n> connection on \"ssh_floating.py\" and improve it\n>\n> Hello Marc,\n>\n> Thanks for your answer.\n>\n> At the moment I\'m willing to spend some time on this kind of scenario\n> so I will see how to use the stress decorator inside a scenario test.\n> Does this means that all stress tests available in \"tempest/stress\"\n> should be ported as scenario tests with this decorator ?\n>\n> I do have some ideas about features on stress test that I find useful\n> for my own use case : like adding more statistics on stress test runs\n> in order to use them as benchmarks.\n> I don\'t know if this kind of feature was already discussed in the\n> OpenStack community but since stress tests are a bit deprecated now,\n> maybe there is some room for this kind of improvement on \"fresh\" stress tests.\n>\n> Best Regards,\n>\n> Julien LELOUP\n>\n> -----Original Message-----\n> From: Koderer, Marc [mailto:m.koderer at telekom.de]\n> Sent: Friday, January 17, 2014 9:45 AM\n> To: LELOUP Julien\n> Cc: openstack-dev at lists.openstack.org\n> Subject: [qa] RE: [Tempest - Stress Test] : implement a full SSH\n> connection on \"ssh_floating.py\" and improve it\n>\n> Hello Juilen,\n>\n> I forwarded your mail to the correct mailing list. Please do not use\n> the qa list any longer.\n>\n> I am happy that you are interested in stress tests. All the tests in\n> tempest/stress/actions are more or less deprecated. So what you should\n> use instead is the stress decorator (e.g.\n> https://github.com/openstack/tempest/blob/master/tempest/api/volume/te\n> st_v\n> olumes_actions.py#L55).\n> Unfortunately it\'s not yet used for scenarios like you describe. I\'d\n> suggest to build a scenario test in tempest/scenario and use this\n> decorator on it.\n>\n> Any patch like that is welcome on gerrit. If you are planning to work\n> in that area for more than just a patch, a blueprint would be nice. A\n> good way to coordinate your efforts is also in the QA meeting\n> (https://wiki.openstack.org/wiki/Meetings/QATeamMeeting)\n>\n> Regards\n> Marc\n>\n> ________________________________________\n> From: LELOUP Julien [Julien.LELOUP at 3ds.com]\n> Sent: Wednesday, January 15, 2014 5:57 PM\n> To: openstack-qa at lists.openstack.org\n> Subject: [openstack-qa] [Tempest - Stress Test] : implement a full SSH\n> connection on \"ssh_floating.py\" and improve it\n>\n> Hi everyone,\n>\n> I?m quite new on OpenStack / Tempest and I?m actually working on\n> stress tests. I want to suggest a new feature in a currently available\n> stress test.\n> Not sure if this email should be posted on the QA mailing list or the\n> dev mailing list, but I give it a try here since it is about a Tempest\n> stress test ?\n>\n> At the moment the ?ssh_floating.py? stress test seems really\n> interesting but I would like to improve it a bit.\n>\n> By now this script is simulating an SSH connection by binding a TCP\n> socket on the newly created instance. But this test don?t allow us to\n> check if this instance is really available. I?m mostly thinking about\n> the metadata service unable to provide the SSH key pair to the\n> instance, but surely other scenarios can lead to an instance\n> considered ?ACTIVE? but actually unusable.\n>\n> So I?m implementing a full SSH connection test using the ?paramiko?\n> SSH library and a key pair generated in the same way the other test\n> resources are managed in this script : either one SSH key pair for\n> every test runs or a new key pair for each run (depends on the JSON configuration file).\n> I don?t plan to remove the old test (TCP socket binding), rather move\n> this one on a separate test function and put the full SSH connection\n> test code instead.\n>\n> Is this feature interesting for the OpenStack community ?\n> Should I create a blueprint on the Tempest project on Launchpad in\n> order to provide my code through Gerrit ?\n>\n> On a second time, I plan to overhaul improve this ?ssh_floating.py?\n> script by clean the code a little bit, and add more cleaning code in\n> order to avoid leaving instances/security groups/floating IP behind :\n> I do have this kind of behavior right now and I already improved the\n> teardown() on this way.\n>\n> Should I consider this code as a new functionality (thus create a\n> blueprint) or should I create a defect and assign it to myself ?\n>\n> Cordialement / Best Regards,\n>\n> Julien LELOUP\n>\n> R&D 3DExperience Platform IaaS Factory Technology Engineer\n>\n>\n>\n>\n>\n> julien.leloup at 3ds.com<mailto:Julien.LELOUP at 3ds.com>\n>\n> [cid:image003.gif at 01CF1216.D43ECE20]\n>\n> 3DS.COM<http://www.3ds.com/>\n>\n>\n> Dassault Syst?mes | 10 rue Marcel Dassault, CS 40501 | 78946 V?lizy-\n> Villacoublay Cedex | France\n>\n>\n>\n>\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n>\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> This email and any attachments are intended solely for the use of the\n> individual or entity to whom it is addressed and may be confidential\n> and/or privileged.\n>\n> If you are not one of the named recipients or have received this email\n> in error,\n>\n> (i) you should not read, disclose, or copy it,\n>\n> (ii) please notify sender of your receipt by reply email and delete\n> this email and all attachments,\n>\n> (iii) Dassault Systemes does not accept or assume any liability or\n> responsibility for any use of or reliance on this email.\n>\n> For other languages, go to http://www.3ds.com/terms/email-disclaimer\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n','<FD9023AAE9C10145BD4DDD6CB11F8D580D4692AE98@QEO40075.de.t-online.corp>',NULL),('<04C2AD0CCE86DD45B466F1979610144E47EE92@EU-DCC-MBX11.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-05 13:02:33',0,'2014-03-05 13:02:33',NULL,'[openstack-dev] [Tempest - Stress Test][qa] : implement a full\n SSH connection on \"ssh_floating.py\" and improve it','>>I mean we still have the tempest/stress/actions/ and we could put something like that in there. In general I would like to discuss this topic in the next QA meeting..\n>>@Julien: are you able to join the next meeting? It would be 22:00 UTC.\n\n>@Marc : so next Thrusday (3/6/2014) ? Yes I can be there.\n\nI have a last minute hindrance preventing me to attend to the next QA meeting.\n\nI will see to attend the one at 1700 UTC Thursday 13 march.\n\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n','<04C2AD0CCE86DD45B466F1979610144E47E784@EU-DCC-MBX11.dsone.3ds.com>',NULL),('<04C2AD0CCE86DD45B466F1979610144E4910EE@EU-DCC-MBX12.dsone.3ds.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 09:48:31',0,'2014-04-02 09:48:31',NULL,'[openstack-dev] [Tempest][qa] : backporting \"Test Security Groups\n Basic Ops\" in stable/havana ?','Hi everyone,\n\nI\'m interested in having the Tempest scenario \"Test Security Groups Basic Ops\" available in the stable/Havana branch .\nThis scenario is nice for acceptance tests and it\'s running fine with an Havana deployment.\n\nCan  someone in the Stable-maint team can backport it from master to stable/Havana ? If it\'s OK for you of course :)\n\nBest Regards,\n\nJulien LELOUP\njulien.leloup at 3ds.com\n\n\nThis email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.\n\nIf you are not one of the named recipients or have received this email in error,\n\n(i) you should not read, disclose, or copy it,\n\n(ii) please notify sender of your receipt by reply email and delete this email and all attachments,\n\n(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.\n\nFor other languages, go to http://www.3ds.com/terms/email-disclaimer\n\n\n',NULL,NULL),('<04C50145D87E4D14B0E86B9F1D36DC60@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-07 13:16:53',-18000,'2012-11-07 18:16:53',NULL,'[openstack-dev] Less of coding standard for i18n of LOG messages','> 1. The tools which extract strings to be translated expect those\n> strings to be wrapped in _().\n> \n> \n\nThis is a very good reason, unfortunately.\n\nThanks,\nEric Windisch\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121107/005498b0/attachment.html>\n\n','<1352310993.2959.32.camel@einstein>',NULL),('<04C72D41-6A84-444F-8BDA-3A308FA4F21D@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 11:56:21',25200,'2014-06-18 04:56:21',NULL,'[openstack-dev] [Mistral] Cleaning up configuration settings','Ooh, alright :) It passed by me why I was off.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 18 Jun 2014, at 01:20, W Chan <m4d.coder at gmail.com> wrote:\n\n> I figured.  I implemented it in https://review.openstack.org/#/c/97684/.\n> \n> \n> On Mon, Jun 16, 2014 at 9:35 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> I don?t think we have them. You can write them I think as a part of what you?re doing.\n> \n> Renat Akhmerov\n> @ Mirantis Inc.\n> \n> \n> \n> On 31 May 2014, at 04:26, W Chan <m4d.coder at gmail.com> wrote:\n> \n>> Is there an existing unit test for testing enabling keystone middleware in pecan (setting cfg.CONF.pecan.auth_enable = True)?  I don\'t seem to find one.  If there\'s one, it\'s not obvious.  Can someone kindly point me to it?\n>> \n>> \n>> On Wed, May 28, 2014 at 9:53 AM, W Chan <m4d.coder at gmail.com> wrote:\n>> Thanks for following up.  I will publish this change as a separate patch from my current config cleanup.\n>> \n>> \n>> On Wed, May 28, 2014 at 2:38 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n>> \n>> On 28 May 2014, at 13:51, Angus Salkeld <angus.salkeld at RACKSPACE.COM> wrote:\n>> \n>> > -----BEGIN PGP SIGNED MESSAGE-----\n>> > Hash: SHA1\n>> >\n>> > On 17/05/14 02:48, W Chan wrote:\n>> >> Regarding config opts for keystone, the keystoneclient middleware already\n>> >> registers the opts at\n>> >> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325\n>> >> under a keystone_authtoken group in the config file.  Currently, Mistral\n>> >> registers the opts again at\n>> >> https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108 under a\n>> >> different configuration group.  Should we remove the duplicate from Mistral and\n>> >> refactor the reference to keystone configurations to the keystone_authtoken\n>> >> group?  This seems more consistent.\n>> >\n>> > I think that is the only thing that makes sense. Seems like a bug\n>> > waiting to happen having the same options registered twice.\n>> >\n>> > If some user used to other projects comes and configures\n>> > \"keystone_authtoken\" then will their config take effect?\n>> > (how much confusion will that generate)..\n>> >\n>> > I\'d suggest just using the one that is registered keystoneclient.\n>> \n>> Ok, I had a feeling it was needed for some reason. But after having another look at this I think this is really a bug. Let?s do it.\n>> \n>> Thanks guys\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/24e0703e/attachment.html>\n\n','<CABNy8O5rXeC4ASnh6xGSfJ-oRFFg9POewrU11iHwBqDP7iA7EA@mail.gmail.com>',NULL),('<04D5F8F2-5A09-475D-B005-776B96523821@scottlowe.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-18 00:42:44',-25200,'2014-11-18 07:42:44',NULL,'[Openstack] Content Delivery Network','Please see my response below.\n\n\nOn Nov 17, 2014, at 3:12 PM, Sandhya S <coolssandy at gmail.com> wrote:\n\n> Hi all,\n> \n> I am currently working for CDN environment.\n> Is there someone here who already worked on the above?\n> \n> I would like to know how to make VM\'s on different compute nodes to communicate as well as how to define REST interface.\n\n\nHi Sandy, OpenStack Neutron has the ability to create logical networks that can connect instances on different compute nodes. This might provide the functionality you\'re seeking.\n\nMore information on using Neutron can be found here (among other places):\n\n<http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html>\n\nAs for your question regarding how to define a REST interface, are you asking about how to interact with OpenStack\'s APIs, or how to define a REST interface for an application running on OpenStack?\n\n-- \nScott\n\n\n\n','<CAANYUcEdr2coxK5wC6M4Fb557bQ2w=FSwaZvN17A-joiP4vP8g@mail.gmail.com>',NULL),('<04DDFFAF-5DE2-4440-AB58-A11CB6351ED0@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-10 15:40:19',0,'2014-10-10 15:40:19',NULL,'[openstack-dev] Unable to install devstack','I?m assuming you?ve verified that your proxy server settings are correct. Try setting GIT_BASE to https://github.com\n\nYou should be able to manually try the commands. For example, set your proxy env variables and then do:\n\ncurl -o /home/shruti/devstack/files/get-pip.py https://bootstrap.pypa.io/get-pip.py\n\nFor my setup (behind a proxy), I set both the upper and lower case proxy env variables:\n\nexport PROXY_HOST=<MY_PROXY_SERVER>:80\nexport http_proxy=http://$PROXY_HOST/\nexport https_proxy=http://$PROXY_HOST/\nexport ftp_proxy=http://$PROXY_HOST/\nexport no_proxy=\"14.0.3.30,...\"\nexport HTTP_PROXY=http://$PROXY_HOST/\nexport HTTPS_PROXY=http://$PROXY_HOST/\nexport FTP_PROXY=http://$PROXY_HOST/\n\nMaybe overkill..\n\nRegards,\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Oct 10, 2014, at 9:54 AM, Shruti Sharma <shrutisharma0810 at gmail.com> wrote:\n\n> \n> \n> Hello All,\n> \n> I am new to Openstack and trying to setup Devstack.\n> I am using ubuntu desktop 14.04 as os. I have cloned devstack sucessfully from github.But while installing I am facing error :\n> \n> It gives http error 407 and finally gives unable to download get-pip.py failed.\n> \n> which i found is error due to proxy authentication and all.\n> So I changed my local.config file to give proxy variables. I have already set my apt.conf and environment files. I am attaching my local.config for better understanding. Then i copied both local.config and local.sh from sample to devstack folder as well still no success.\n> I have made changes according to the link:\n> http://www.rushiagr.com/blog/2014/08/05/devstack-behind-proxy/\n> \n> Here is my terminal output when it fails:\n> http://pastebin.com/hj7Bhmzk\n> \n> Suggestion Please!!!!!!!!\n> \n> \n> Shruti Sharma, Final Year, Computer Engineering\n> Malaviya National Institute of Technology\n> \n> <local.conf>_______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/26ab1c17/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/26ab1c17/attachment.pgp>\n\n','<CAJC1mty1UHYMrChoF5W835zGmZ1egWQ-WPbCdh=xk8qcV-9xWA@mail.gmail.com>',NULL),('<04E5B140-8354-46C5-A485-5E453C77E81C@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-15 10:55:00',-28800,'2014-01-15 18:55:00',NULL,'[Openstack] CentOS Network Create problem','What network (ip address) are you using to ssh into the cirrors box?\n\nJust to make sure since you may not have a route to it. \n\nRemo \n\nOn Jan 15, 2014, at 10:29 AM, Dimitri Maziuk <dmaziuk at bmrb.wisc.edu> wrote:\n\n> On 01/15/2014 08:23 AM, Georgios Dimitrakakis wrote:\n>> Hi again...Long day with OpenStack today...\n>> \n>> It seems that the problem with the br100 interface has been solved\n>> partially since I can launch an instance but I am not able to ssh nor\n>> ping the machine (although I have configured the security group rules).\n> \n> Here\'s what I have on a working node with 2 instances running. Ignore\n> virbr0, it\'s created by libvirt, vnet0 & 1 are the openstack instances:\n> \n> # brctl show\n> bridge name     bridge id               STP enabled     interfaces\n> br100           8000.003048c53032       no              eth0\n>                                                        vnet0\n>                                                        vnet1\n> virbr0          8000.52540025455f       yes             virbr0-nic\n> \n> # ip a\n> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n>    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n>    inet 127.0.0.1/8 scope host lo\n>    inet6 ::1/128 scope host\n>       valid_lft forever preferred_lft forever\n> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast\n> state UNKNOWN qlen 1000\n>    link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff\n>    inet6 fe80::230:48ff:fec5:3032/64 scope link\n>       valid_lft forever preferred_lft forever\n> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000\n>    link/ether 00:30:48:c5:30:33 brd ff:ff:ff:ff:ff:ff\n> 4: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state\n> UNKNOWN\n>    link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff\n>    inet X.X.X.X/25 brd X.X.X.X scope global br100\n>    inet6 fe80::230:48ff:fec5:3032/64 scope link\n>       valid_lft forever preferred_lft forever\n> 5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue\n> state UNKNOWN\n>    link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff\n>    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0\n> 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500\n>    link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff\n> 10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast\n> state UNKNOWN qlen 500\n>    link/ether fe:16:3e:48:30:5c brd ff:ff:ff:ff:ff:ff\n>    inet6 fe80::fc16:3eff:fe48:305c/64 scope link\n>       valid_lft forever preferred_lft forever\n> 38: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast\n> state UNKNOWN qlen 500\n>    link/ether fe:16:3e:16:b3:55 brd ff:ff:ff:ff:ff:ff\n>    inet6 fe80::fc16:3eff:fe16:b355/64 scope link\n>       valid_lft forever preferred_lft forever\n> \n> # lsmod | grep _net\n> vhost_net              30520  2\n> macvtap                 9980  1 vhost_net\n> tun                    17095  6 vhost_net\n> \n> (\"modprobe vhost_net\" if you don\'t have it.)\n> \n> # route -n\n> Kernel IP routing table\n> Destination   Gateway      Genmask         Flags Metric Ref  Use Iface\n> X.X.X.X       0.0.0.0      255.255.255.128 U     0      0    0   br100\n> 192.168.122.0 0.0.0.0      255.255.255.0   U     0      0    0   virbr0\n> 169.254.0.0   0.0.0.0      255.255.0.0     U     1004   0    0   br100\n> 0.0.0.0       X.X.X.X      0.0.0.0         UG    0      0    0   br100\n> \n> You should have a route to your nova network in there (I use flat\n> network so my nova net is X.X.X.X, same as my \"real\" subnet).\n> \n> With all that in place try disabling iptables in the instance and\n> pinging the host. On the host, run tcpdump on vnet0 and br100 to see if\n> you get any traffic. I didn\'t initially, I think modprobe vhost_net was\n> what fixed it. (I was poking at & restarting several things at once, so\n> I\'m not 100% sure exactly which of them did it.)\n> \n> -- \n> Dimitri Maziuk\n> Programmer/sysadmin\n> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,52d6d70217101936618038!\n\n\n\n','<52D6D38A.1020301@bmrb.wisc.edu>',NULL),('<04E8A3D3-4E1E-4954-BC54-F9E9CA097E0D@codestud.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 18:28:03',-28800,'2013-11-14 02:28:03',NULL,'[openstack-dev] [style] () vs \\ continuations','For this example, I\'d look at using parens on the left side to see if that helps.  I also, like Sean, really dislike the look of \\.\n\n> On Nov 13, 2013, at 5:08 PM, Robert Collins <robertc at robertcollins.net> wrote:\n> \n>> On 14 November 2013 13:59, Sean Dague <sean at dague.net> wrote:\n>> \n>> This is an area where we actually have consensus in our docs (have had\n>> for a while), the reviewer was being consistent with them, and it feels\n>> like you are reopening that for personal preference.\n> \n> Sorry that it feels that way. My personal code also uses ()\n> overwhelmingly - so this isn\'t a personal agenda issue. I brought it\n> up because the person that wrote the code had chosen to use \\, and as\n> far as I knew we didn\'t have a hard decision either way - and the\n> style guide we have talks preference not requirement, but the review\n> didn\'t distinguish between whether it\'s a suggestion or a requirement.\n> I\'m seeking clarity so I can review more effectively and so that our\n> code doesn\'t end up consistent but hard to read.\n> \n>> Honestly I find \\ at the end of a line ugly as sin, and completely\n>> jarring to read. I actually do like the second one better. I don\'t care\n>> enough to change a policy on it, but we do already have a policy, so it\n>> seems pretty pedantic, and not useful.\n> \n> Ok, thats interesting. Readability matters, and if most folk find that\n> even this case - which is pretty much the one case where I would argue\n> for \\ - is still easier to read with (), then thats cool.\n> \n>> Bringing up for debate the style guide every time it disagrees with your\n>> personal preference isn\'t a very effective use of people\'s time.\n>> Especially on settled matters.\n> \n> Totally not what I\'m doing. I\'ve been told that much of our style\n> guide was copied lock stock and barrel from some Google Python style\n> guide, so I can\'t tell what is consensus and what is \'what someone\n> copied down one day\'. Particularly when there is no rationale included\n> against the point - its a black box and entirely opaque.\n> \n> -Rob\n> \n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJ3HoZ20eOFdDMyYdmDCWR-_JY22Qov2mH7oU5NMzT-cFm1F2g@mail.gmail.com>',NULL),('<04E9874C-46F3-446D-B308-39261B6521CC@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-12 09:45:37',-28800,'2012-12-12 17:45:37',NULL,'[openstack-dev] New python dependency - extras-0.0.1','\nOn Dec 12, 2012, at 7:15 AM, P?draig Brady wrote:\n\n> On 11/23/2012 07:29 AM, Mark McLoughlin wrote:\n>> Hey,\n>> \n>> A new Oslo dependency is proposed here:\n>> \n>>   https://review.openstack.org/16789\n>> \n>> The library is called \'extras\' and released its first version nearly a\n>> month ago:\n> \n> Sorry for being late to this.\n> Packaging python-extras popped up on my radar today.\n> \n>>   http://pypi.python.org/pypi/extras/0.0.1\n>>   https://github.com/testing-cabal/extras\n>> \n>> I don\'t forsee any objections apart from perhaps \'is a separate library\n>> for just try_import() really worth it?\'\n> \n> It really seems like overkill to have a separate package for this.\n> Also \'extras\' is far too generic a name anyway which at best\n> is non descriptive and at worst becoming a dumping ground for whatever.\n\nI want to agree loudly with this - the name \'extras\' is a little silly. I\'m fine with the underlying code, but it needs a much more descriptive name.\n\n>> I\'m inclined to approve it, just want to give folks a chance to express\n>> an opinion.\n> \n> How about pulling try_import() into olso for the moment?\n\nThis seems like a good compromise to forcing you (and others) to package something not everybody really agrees on.\n\n','<50C89F7C.9040104@draigBrady.com>',NULL),('<04EFB5BD-DD41-412A-B718-3E30AF6C6B00@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 03:35:48',0,'2012-11-01 03:35:48',NULL,'[openstack-dev] Billing for OpenStack - Naming proposals','Moolah?\n\nOn Oct 31, 2012, at 9:57 PM, Ray Pekowski wrote:\n\nBaggins :)\n\nOn Wed, Oct 31, 2012 at 2:06 PM, Monsyne Dragon <mdragon at rackspace.com<mailto:mdragon at rackspace.com>> wrote:\nToucan?\n\nOn Oct 31, 2012, at 12:46 PM, Endre Karlson wrote:\n\n> Hi, I\'m working on making a billing system and wondering if someone has some cool names for it ? :)\n>\n> I named it \"billistix\" originally but some folks (I won\'t tell names) taunted me by saying \"I\'ll just call mine BillyJean then\".\n>\n> Come up with suggestions and let\'s pick the best one\n>\n> Endre.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/edb159f5/attachment.html>\n\n','<CAJcv3CQU0K1qvM8mcoAWeGwyxm0-5-smZfQRRimnnc1vH3en8g@mail.gmail.com>',NULL),('<04F86071-E9FE-46D7-AA41-E53861D76CC2@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-05 18:11:56',-25200,'2014-08-06 01:11:56',NULL,'[Openstack-operators] I shot myself in the foot trying to\n	install the block storage service','You can simply run a SQL query based on the service ID:\n\nuse keystone;\nUPDATE endpoints SET adminURL=?etc?. WHERE service=?ID?;\n\nI don?t remember the exact name of the fields, but it?s the simplest option IMO\n\nOn 05 Aug 2014, at 18:05, Fischer, Matt <matthew.fischer at twcable.com> wrote:\n\n> Yes, you\'ve messed it up good. When the endpoint URL is bad Keystone cannot do anything. I filed a bug on this last week and the fix is being back ported. The only resolution that I know of is to fix the endpoint in the Keystone database. I think based on what I see that you\'re missing an \"s\" on the end of that. %(foo)s is how python does string substitution. Here\'s how I fixed it before:\n> \n> http://www.mattfischer.com/blog/?p=532\n> \n> From: Jeff Silverman <jeff at sweetlabs.com>\n> Date: Tuesday, August 5, 2014 6:42 PM\n> To: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org>\n> Subject: [Openstack-operators] I shot myself in the foot trying to install the block storage service\n> \n> I am in http://docs.openstack.org/icehouse/install-guide/install/yum/content/cinder-controller.html  step 8. The problem began when I didn\'t notice that the word controller was in italics in the documentation. I wish it were in ALL CAPS, such as for the CINDER_PASS/. However, I went back and repeated the commands correctly, I think, and I am still getting a 500 internal server error.\n> I used keystone with the --debug switch and tried using the generated curl command:\n> root at controller1-prod.controller1-prod:~# curl -i -X POST http://controller1-prod.sea.opencandy.com:35357/v2.0/tokens -H \"Content-Type: application/json\" -H \"Accept: application/json\" -H \"User-Agent: python-keystoneclient\" \\\n> -d \'{\"auth\": {\"tenantName\": \"admin\", \"passwordCredentials\": {\"username\": \"admin\", \"password\": \"f8d67f756e057918ef25dca59de79778\"}}}\'\n> HTTP/1.1 500 Internal Server Error\n> Vary: X-Auth-Token\n> Content-Type: application/json\n> Date: Tue, 05 Aug 2014 23:51:10 GMT\n> Transfer-Encoding: chunked\n> {\"error\": {\"message\": \"Malformed endpoint URL (see ERROR log for details):http://controller:8776/v1/%(tenant_id)\", \"code\": 500, \"title\": \"Internal Server Error\"}}root at controller1-prod.controller1-prod:~#\n> from /var/log/keystone/keystone.log:\n> 2014-08-05 16:51:10 ERROR [keystone.catalog.core] Malformed endpoint http://controller:8776/v1/%(tenant_id) - incomplete format (are you missing a type notifier ?)\n> 2014-08-05 16:51:10 WARNING [keystone.common.wsgi] Malformed endpoint URL (see ERROR log for details): http://controller:8776/v1/%(tenant_id)\n> I looked at the transfer with wireshark and I confirm that the service endpoint is really sending http://controller:8776 in the error message. I don\'t know what port 8776 or why the server thinks that there is traffic on port 8776.\n> Whatever I did wrong, it has messed up keystone but good:\n> # keystone catalog\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.6/site-packages/keystoneclient/v2_0/client.py\", line 172, in get_raw_token_from_identity_service\n>     return a.get_auth_ref(self.session)\n>   File \"/usr/lib/python2.6/site-packages/keystoneclient/auth/identity/v2.py\", line 84, in get_auth_ref\n>     authenticated=False)\n>   File \"/usr/lib/python2.6/site-packages/keystoneclient/session.py\", line 334, in post\n>     return self.request(url, \'POST\', **kwargs)\n>   File \"/usr/lib/python2.6/site-packages/keystoneclient/utils.py\", line 324, in inner\n>     return func(*args, **kwargs)\n>   File \"/usr/lib/python2.6/site-packages/keystoneclient/session.py\", line 275, in request\n>     raise exceptions.from_response(resp, method, url)\n> InternalServerError: Malformed endpoint URL (see ERROR log for details):http://controller:8776/v1/%(tenant_id) (HTTP 500)\n> not all arguments converted during string formatting\n> root at controller1-prod.controller1-prod:/var/log/httpd#\n> I found something similar on launchpad, bug 1291672 https://bugs.launchpad.net/openstack-manuals/+bug/1291672 which was closed for lack of activity.\n> \n> Thank you\n> Jeff Silverman\n> \n> -- \n> Jeff Silverman\n> Systems Engineer\n> (253) 459-2318 (c)\n> \n> \n> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140805/162eccb0/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 536 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140805/162eccb0/attachment.pgp>\n\n','<D006DA63.68FF%matthew.fischer@twcable.com>',NULL),('<050634348121501b49e5a21cfb91c4ec@mail.gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-08-09 10:41:59',36000,'2013-08-09 00:41:59',NULL,'[openstack-community] First OpenStack community\'s meeting in\n Caracas, Venezuela.','A warm welcome to the Stackers in Caracas! :-)\n\n\n\nCheers\n\nTristan\n\n\n\n\n\n\n\n*From:* Ender Mujica [mailto:emujicad at gmail.com]\n*Sent:* Friday, 9 August 2013 7:42 AM\n*To:* Community User Groups, OpenStack\n*Subject:* [openstack-community] First OpenStack community\'s meeting in\nCaracas, Venezuela.\n\n\n\nHello,\n\nWe are pleased to announce the first OpenStack community\'s meeting in\nCaracas, Venezuela.\n\nIt is scheduled on August 24, 2013 (Saturday) at 9:00 (VET).\n\nMore details at:\n\nhttps://plus.google.com/u/0/communities/118105990522935078913\n\n-- \nThanks\n\nIng. Ender A. Mujica D.\nCel.: +58 (416) 9003013\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130809/5c99f636/attachment.html>\n\n','<CAOehM_V5nL2PUYRvf692m74p3vqA-s49aFjZOfTgA_93NJBWgA@mail.gmail.com>',NULL),('<050e01cf40c4$e0f0aa30$a2d1fe90$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-03-15 20:07:21',-25200,'2014-03-16 03:07:21',NULL,'[openstack-community] OpenStack Northwest User Group Meetup this\n	Thu Mar 20 in Portland','OpenStack + Ceph = A match made in heaven\n\nThursday Mar 20, 2014 @ 6:30PM PST\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nYou don\'t get too many second chances in life, but if you missed Ian Colle\'s\npresentation in Denver this February, and you happen to be in Portland on\nMarch 19, then you\'re in luck.\n\nIan is the Director of Engineering at Inktank, the company delivering\nInktank Ceph Enterprise. He will be flying over to discuss Ceph integration\nwith OpenStack at a deep technical level, and also for the beer.\n\nCeph is a fully open source distributed object store, network block device,\nand file system designed for reliability, performance, and scalability from\nterabytes to exabytes. Ceph offers a Swift and S3-compatible REST API for\nseamless data access, a network block device for large images or volumes,\nand native support for Qemu/KVM, libvirt, CloudStack, and OpenStack which\nmakes it quite a versatile storage platform.  Join us for a walkthrough of\nthe Ceph architecture, its current status, how it integrates with OpenStack,\nand plans for future development.\n\nPrior to Inktank, Ian held positions in Intel\'s High Performance Data\nDivision and Whamcloud\'s High Performance Computing team. He is an avid\ntrail runner who thinks running up the sides of mountains is an enjoyable\nway to exercise.\n\nPlease RSVP so we can ensure food and drinks are adequate.\n\nSee you then. \n\nhttp://www.meetup.com/OpenStack-Northwest/events/164592302/\n\nFollow #OSNW on Twitter for  livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140315/c99802a6/attachment.html>\n\n',NULL,NULL),('<050e01cf40c4$e0f0aa30$a2d1fe90$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-15 20:07:21',-25200,'2014-03-16 03:07:21',NULL,'[Openstack] OpenStack Northwest User Group Meetup this Thu Mar 20\n	in Portland','OpenStack + Ceph = A match made in heaven\n\nThursday Mar 20, 2014 @ 6:30PM PST\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nYou don\'t get too many second chances in life, but if you missed Ian Colle\'s\npresentation in Denver this February, and you happen to be in Portland on\nMarch 19, then you\'re in luck.\n\nIan is the Director of Engineering at Inktank, the company delivering\nInktank Ceph Enterprise. He will be flying over to discuss Ceph integration\nwith OpenStack at a deep technical level, and also for the beer.\n\nCeph is a fully open source distributed object store, network block device,\nand file system designed for reliability, performance, and scalability from\nterabytes to exabytes. Ceph offers a Swift and S3-compatible REST API for\nseamless data access, a network block device for large images or volumes,\nand native support for Qemu/KVM, libvirt, CloudStack, and OpenStack which\nmakes it quite a versatile storage platform.  Join us for a walkthrough of\nthe Ceph architecture, its current status, how it integrates with OpenStack,\nand plans for future development.\n\nPrior to Inktank, Ian held positions in Intel\'s High Performance Data\nDivision and Whamcloud\'s High Performance Computing team. He is an avid\ntrail runner who thinks running up the sides of mountains is an enjoyable\nway to exercise.\n\nPlease RSVP so we can ensure food and drinks are adequate.\n\nSee you then. \n\nhttp://www.meetup.com/OpenStack-Northwest/events/164592302/\n\nFollow #OSNW on Twitter for  livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140315/c99802a6/attachment.html>\n\n',NULL,NULL),('<05100f1e-65aa-4645-a1da-3a0328248d58@radiantworlds.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-27 12:17:31',3600,'2014-08-27 11:17:31',NULL,'[Openstack] High Latency to VMs','I\'ve been trying to figure this one out for a while, so I\'ll try and be as thorough as possible in this post but apologies if I miss anything pertinent out.\n \nFirst off, I\'m running a set up with one control node and 5 compute nodes, all created using the Stackgeek scripts - http://www.stackgeek.com/guides/gettingstarted.html. The first two (compute1 and compute 2) were created at the same time, compute3, 4 and 5 were added as needed later. My VMs are predominantly CentOS, while my Openstack nodes are Ubuntu 14.04.1\n \nThe symptom: irregular high latency/packet loss to VMs on all compute boxes except compute3. Mostly a pain when trying to do anything via ssh on a VM because the lag makes it difficult to do anything, but it shows itself quite nicely through pings as well:\n--- 10.0.102.47 ping statistics ---\n111 packets transmitted, 103 received, 7% packet loss, time 110024ms\nrtt min/avg/max/mdev = 0.096/367.220/5593.100/1146.920 ms, pipe 6\n \n\nI have tested these pings:\nVM to itself (via its external IP) seems fine\nVM to another VM is not fine\nHosting compute node to VM is not fine\nMy PC to VM is not fine (however the other way round works fine)\n \n \nTop on a (32 core) compute node with laggy VMs:\ntop - 12:09:20 up 33 days, 21:35,  1 user,  load average: 2.37, 4.95, 6.23\nTasks: 431 total,   2 running, 429 sleeping,   0 stopped,   0 zombie\n%Cpu(s):  0.6 us,  3.4 sy,  0.0 ni, 96.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st\nKiB Mem:  65928256 total, 44210348 used, 21717908 free,   341172 buffers\nKiB Swap:  7812092 total,  1887864 used,  5924228 free.  7134740 cached Mem\n \nAnd for comparison, on the one compute node that doesn\'t seem to be suffering from this:\ntop - 12:12:20 up 33 days, 21:38,  1 user,  load average: 0.28, 0.18, 0.15\nTasks: 399 total,   3 running, 396 sleeping,   0 stopped,   0 zombie\n%Cpu(s):  0.3 us,  0.1 sy,  0.0 ni, 98.9 id,  0.6 wa,  0.0 hi,  0.0 si,  0.0 st\nKiB Mem:  65928256 total, 49986064 used, 15942192 free,   335788 buffers\nKiB Swap:  7812092 total,   919392 used,  6892700 free. 39272312 cached Mem\n \nTop on a laggy VM:\ntop - 11:02:53 up 27 days, 33 min,  3 users,  load average: 0.00, 0.00, 0.00\nTasks:  91 total,   1 running,  90 sleeping,   0 stopped,   0 zombie\nCpu(s):  0.2%us,  0.1%sy,  0.0%ni, 99.5%id,  0.1%wa,  0.0%hi,  0.0%si,  0.0%st\nMem:   1020400k total,   881004k used,   139396k free,   162632k buffers\nSwap:  1835000k total,    14984k used,  1820016k free,   220644k cached\n \nhttp://imgur.com/blULjDa shows the hypervisor panel of Horizon. As you can see, Compute 3 has fewer resources used, but none of the compute nodes should be anywhere near overloaded from what I can tell.\n \nAny ideas? Let me know if I\'m missing anything obvious that would help with figuring this out! \n \nHannah\n\n\n***********\n\nRadiant Worlds Limited is registered in England (company no: 07822337). This message is intended solely for the addressee and may contain confidential information. If you have received this message in error please send it back to us and immediately and permanently delete it from your system. Do not use, copy or disclose the information contained in this message or in any attachment. Please also note that transmission cannot be guaranteed to be secure or error-free.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140827/dfa83f09/attachment.html>\n\n',NULL,NULL),('<05207FD7-25C6-4A80-8815-7D9B5A475D93@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-08 22:31:25',-25200,'2013-07-09 05:31:25',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','\nOn Jul 8, 2013, at 20:34, Jamie Lennox <jlennox at redhat.com> wrote:\n\n> On Mon, 2013-07-08 at 21:55 -0400, Adam Young wrote:\n>> \n>> Tokens are, for the most part, immutable.  Once they are written, they\n>> don\'t change except if they get revoked.  This is a fairly rare\n>> occurance, but it does happen.\n>> \n>> Deleting tokens based on age should be fairly straight forward, and\n>> locks should not need to be held for a significant amount of time.\n>> \n>> My guess, however, is that the problem is SQL Alchemy:\n>> \n>>        query = session.query(TokenModel)\n>>        query = query.filter(TokenModel.expires < timeutils.utcnow())\n>>        query.delete(synchronize_session=False)\n>> \n>> If it is doing a fetch and then the delete, then the rows would be\n>> held for a short period of time.\n>> \n>> Direct SQL might be a better approach:  prepare a statement:\n>> \n>> \"delete from token where expires < $1\"\n> \n> Sqlalchemy already generates this statement.  \n> \n>> and then bind and execute in one command.\n>> \n>> However, it seems to me that the conflict detection is the problem.  I\n>> don\'t know if there is a way to state \"ignore any future queries that\n>> would match this criteria.\"   It does seem to me that even doing this\n>> degree of conflict detection is somewhat violating the principal of\n>> Isolation.\n>> \n>> There might be an approach using table partitioning as well, where you\n>> only write to partition one, and delete from partition 2, and then\n>> swap.\n>> \n>> \n>> \n>> \n>> \n>> On 07/08/2013 09:13 PM, Robert Collins wrote:\n>> \n>>> On 9 July 2013 12:32, Adam Young <ayoung at redhat.com> wrote:\n>>> \n>>>                * I am asking about MySQL.. presumably a \"real\"\n>>>                database.\n>>>         I have to admit I am a bit of a Postgresql Bigot. I don\'t\n>>>        really consider MySQL a real database, althought it has\n>>>        improved a lot over the years.  I am not up to speed\n>>>        on\"InnoDB\'s gap locking behavior\" but it is not something I\n>>>        would expect to be a problem in Postgresql.\n>>> \n>>> PostgreSQL has similar but different characteristics, particular the\n>>> latest iteration of isolation behaviour where locks are held on *the\n>>> result of a query*, not on \'specific rows returned\' - the difference\n>>> being that adding a new row that matches the query for rows to\n>>> delete, would encounter a conflict. You also need to delete small\n>>> numbers of rows at a time, though the reason in the plumbing is\n>>> different. There are some nasty interlocks you can cause with very\n>>> large deletes and autovacuum too - if you trigger deadlock detection\n>>> it still takes /minutes/ to detect and cleanup, whereas we want\n>>> sub-second liveness.\n>>> \n>>>        once every second would be strange indeed.  I would think\n>>>        maybe once every five minutes or so.  Schedule your clean up\n>>>        IAW your deployment and usage.\n>>> \n>>> 5m intervals exacerbate the issue until it\'s solved. If the cleanup\n>>> deletes no more than (say) 1000 rows per iteration, it could run\n>>> every 5 minutes but when run keep going until the db is cleaned.\n>>> \n>>>        Deleting a chunk of tokens in bulk would be preferable to\n>>>        doing client side iteration, I can;t see how that would not\n>>>        be the case.\n>>> \n>>> right, so I think Clint prefers that too, the question is how to get\n>>> sqlalchemy to output the appropriate sql for postgresql and mysql,\n>>> which is different.\n> \n> I\'m not experienced with large databases but i wrote the token_flush so\n> i\'m interested. What am i missing that we can\'t just add a --limit\n> parameter to the command line tool so \"keystone-manage token_flush\n> --limit=1000\" which is (as was mentioned) deleting 1000 in a command. \n> \n> SA will be able to generate a nested query like:\n> \"delete from token where id in (select id from token limit 1000)\" \n> for all databases. What sort of hit is something nested like that? Then\n> you tweak the limit and the frequency but i would suggest 1000 every 5\n> minutes should result in a net negative token count and wouldn\'t come\n> close to the locks. \n> \n\nThat is exactly what I tried. MySQL doesn\'t allow LIMIT on sub queries which feed into the IN() construct. :-(\n\nMySQL does have an SQL extension which allows LIMIT in the DELETE statement, but this presents the challenge I originally was asking about.\n\n','<1373340851.5657.29.camel@dhcp-40-102.bne.redhat.com>',NULL),('<0521788C2E6B0A4CA80B71BCC8B790570241335C@EXCH01.service.hisoft.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-24 07:45:08',0,'2014-03-24 07:45:08',NULL,'[OpenStack-Infra] Apply a 3rd part testing account','Hi,\nI want to apply a 3rd part testing account.There are account information:\n\n1.SSH-KEY:\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3hE1/IpORdrqHDP9IIhZqpqO7sqoslAaxBltBkX1evOvUwHObnOjKdFWuv9pg6uUaUCUp8XKcP4WzSDY3GMxkwYgvnpKBqhUOp4pooTCdOIAttP9OSo4OyCYfh8C6b2bsgJ2sTUi9PQ12+bTKM0ODFE1WcQcYgkZPqKJK31N+P9Zjtl+9je8QCDtdcWi5OHDWr8hR8Kr8Yh81EKxfQlBsEa8h2Z1QNlB4QZ1X38sIDOL20SWbzOHGsnuEYJh+cPhglLKXEAGK56GN/ONVmRNrkWngFpLo6JHvv9ua/+qWP1O9ysXfuXGe5vAypX61KaeHLo2GOMrL2RS28O5aIDmwQ== root at cnt12\n\n2.Username:\nyjiang\n\n3.Readable name:\nIntel-PCI-CI\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140324/55f72399/attachment.html>\n\n',NULL,NULL),('<052511c0-bf33-4db8-b6a6-aacc2851d4fd@email.android.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-30 08:02:31',28800,'2014-09-30 00:02:31',NULL,'[Openstack-operators] [Openstack] [OSSA 2014-031] Admin-only\n	network attributes may be reset to defaults by non-privileged\n	users (CVE-2014-6414)','icehouse will be supported 18 months IIRC\n\ni don\'t have a link here. it was mentioned on Thierry presentation (mid cycle state of the project ) a few months ago\n\nOn September 30, 2014 7:39:08 AM GMT+08:00, George Shuklin <george.shuklin at gmail.com> wrote:\n>\n>On 09/30/2014 01:55 AM, Jeremy Stanley wrote:\n>> On 2014-09-29 21:59:32 +0300 (+0300), George Shuklin wrote:\n>>> Means no fixes for havana?\n>> [...]\n>>\n>> Yes, that should have just said \"Versions: up to 2014.1.2\" as havana\n>> is already past the end of support from the OpenStack vulnerability\n>> management team and stable branch managers. I\'m presently working on\n>> the patches to our CI to tear out testing for it, and the\n>> stable/havana branches of all our projects will most likely be\n>> tagged \"havana-eol\" and deleted some time this week.\n>I think this is just _NOT_RIGHT_. I\'m understand \'end of bugfixes\'\n>idea. \n>Or software suites you perfectly, or you upgrade.\n>\n>But security and data loss bugs are different from normal. They can hit\n>\n>even if user completely happy with software functionality and harm \n>really badly not only user, but everyone around.\n>\n>Saying \'you should upgrade your all infrastructure at least once every \n>year\' is bad idea. Lot of stuff changed at every new release and it not\n>\n>like \'upgrade nginx from 1.1 to 1.4 - no one will notice\'. Openstack \n>upgrade is always huge: changes in configuration, sometimes manual \n>database migration, deprecation and \'new recommended\' stuff in all\n>places.\n>\n>Security fixes should be continued at least twice longer than normal \n>bugfixes.\n>\n>This model (all important bugfixes released and than no any kind of \n>security fixes at all) is just looking like yummy cake for \n>\'redistributors\' - but no one know if they are capable to backport all \n>new fixes or not...\n>\n>You can say \'go and upgrade\', but usually fresh version of openstack is\n>\n>just too raw and buggy. Example: bug in neutron (havana) which cause \n>instances to loose networking on reboot was fixed year after initial \n>release. And security support was dropped right after that release.\n>\n>\n>\n>\n>\n>_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-- \nSent from mobile.\n1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140930/40e6f829/attachment.html>\n\n','<5429ED9C.2010404@gmail.com>',NULL),('<052BAA77-A189-44FA-BC6B-D83F85D80B74@cern.ch>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-18 10:16:24',0,'2014-12-18 10:16:24',NULL,'[Openstack-operators] cinder service-delete?','Hi,\n\nWhen migrating our Cinder service to new hosts, I noticed that there seems\nto be no ?cinder service-delete? subcommand (RDO Icehouse & Juno).\n\nI couldn?t find a bug or blueprint entry for this ? is that worth opening one or\ndid I miss something?\n\nThanks,\n Arne\n\n?\nArne Wiebalck\nCERN IT\n\n\n\n\n',NULL,NULL),('<053201cf4170$179de4c0$46d9ae40$@detacloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-16 16:33:05',-25200,'2014-03-16 23:33:05',NULL,'[Openstack] Date Correction: OpenStack Northwest User Group Meetup\n	this Thu Mar 20 in Portland','OpenStack + Ceph = A match made in heaven\n\nThursday Mar 20, 2014 @ 6:30PM PST\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nYou don\'t get too many second chances in life, but if you missed Ian Colle\'s\npresentation in Denver this February, and you happen to be in Portland on\nMarch 20th, then you\'re in luck.\n\nIan is the Director of Engineering at Inktank, the company delivering\nInktank Ceph Enterprise. He will be flying over to discuss Ceph integration\nwith OpenStack at a deep technical level, and also for the beer.\n\nCeph is a fully open source distributed object store, network block device,\nand file system designed for reliability, performance, and scalability from\nterabytes to exabytes. Ceph offers a Swift and S3-compatible REST API for\nseamless data access, a network block device for large images or volumes,\nand native support for Qemu/KVM, libvirt, CloudStack, and OpenStack which\nmakes it quite a versatile storage platform.  Join us for a walkthrough of\nthe Ceph architecture, its current status, how it integrates with OpenStack,\nand plans for future development.\n\nPrior to Inktank, Ian held positions in Intel\'s High Performance Data\nDivision and Whamcloud\'s High Performance Computing team. He is an avid\ntrail runner who thinks running up the sides of mountains is an enjoyable\nway to exercise.\n\nPlease RSVP so we can ensure food and drinks are adequate.\n\nSee you then. \n\nhttp://www.meetup.com/OpenStack-Northwest/events/164592302/\n\nFollow #OSNW on Twitter for  livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140316/b52a2a4d/attachment.html>\n\n',NULL,NULL),('<0532c0d1ff7fa2d79327213d9fe8bf6b@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 11:02:57',-21600,'2013-11-11 17:02:57',NULL,'[openstack-dev] [openstack-tc] Proposal to recognize indirect\n	contributions to our code base','On 2013-11-11 10:49, Davanum Srinivas wrote:\n> @Ben,\n> \n> Metrics tools i believe are already using information in the .mailmap\n> file (see nova\'s for example).\n\nHaving just been through this process, I\'m afraid not. :-)  Stackalytics \nuses \nhttps://github.com/stackforge/stackalytics/blob/master/etc/default_data.json and Activity Board uses https://github.com/openstack-infra/activity-board/blob/master/browser/data/affs/openstack-community-affs.csv\n\nAlso, the mailmaps for some projects (oslo-incubator for example) are so \nincomplete that they would require massive updates to be useful for \nthis.\n\nThere was actually a discussion about the proliferation of affiliation \ndata not too long ago: \nhttp://lists.openstack.org/pipermail/openstack-dev/2013-October/016900.html\n\n-Ben\n\n\n','<CANw6fcFsbbePpH3MvxhsKkTw-sS-f+zPMokWWdVhPrROdaCkyQ@mail.gmail.com>',NULL),('<053701cf4170$2a40b4e0$7ec21ea0$@detacloud.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-03-16 16:33:40',-25200,'2014-03-16 23:33:40',NULL,'[openstack-community] Date Correction: OpenStack Northwest User\n	Group Meetup this Thu Mar 20 in Portland','OpenStack + Ceph = A match made in heaven\n\nThursday Mar 20, 2014 @ 6:30PM PST\n\nJama Software (South) 334 NW 11th Ave, Portland, OR\n\nYou don\'t get too many second chances in life, but if you missed Ian Colle\'s\npresentation in Denver this February, and you happen to be in Portland on\nMarch 20th, then you\'re in luck.\n\nIan is the Director of Engineering at Inktank, the company delivering\nInktank Ceph Enterprise. He will be flying over to discuss Ceph integration\nwith OpenStack at a deep technical level, and also for the beer.\n\nCeph is a fully open source distributed object store, network block device,\nand file system designed for reliability, performance, and scalability from\nterabytes to exabytes. Ceph offers a Swift and S3-compatible REST API for\nseamless data access, a network block device for large images or volumes,\nand native support for Qemu/KVM, libvirt, CloudStack, and OpenStack which\nmakes it quite a versatile storage platform.  Join us for a walkthrough of\nthe Ceph architecture, its current status, how it integrates with OpenStack,\nand plans for future development.\n\nPrior to Inktank, Ian held positions in Intel\'s High Performance Data\nDivision and Whamcloud\'s High Performance Computing team. He is an avid\ntrail runner who thinks running up the sides of mountains is an enjoyable\nway to exercise.\n\nPlease RSVP so we can ensure food and drinks are adequate.\n\nSee you then. \n\nhttp://www.meetup.com/OpenStack-Northwest/events/164592302/\n\nFollow #OSNW on Twitter for  livestream/recording links.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140316/a2d5f724/attachment.html>\n\n',NULL,NULL),('<053801cfc8f0$a7eff1a0$f7cfd4e0$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 18:03:34',28800,'2014-09-05 10:03:34',NULL,'[openstack-dev] [ceilometer] Compute agent local VM inspector -\n	potential enhancement','Hi folks,\n\nIs there anybody working on this?\n\nIn most of our cloud environments, business networks are isolated from management network. So, we are thinking about making *an agent in guest machine to send metrics to compute node using virtual serial port*. And then, compute node could send those data to ceilometer. That seems a general solution for all kinds of network topologies, and can send metrics without knowing any credentials.\n\n\nBR\nKurt Rao\n\n\n-----Original Message-----\n???: boden [mailto:boden at linux.vnet.ibm.com] \n????: 2014?8?1? 20:37\n???: openstack-dev at lists.openstack.org\n??: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector - potential enhancement\n\nOn 8/1/2014 4:37 AM, Eoghan Glynn wrote:\n>\n>\n>> Heat cfntools is based on SSH, so I assume it requires TCP/IP \n>> connectivity between VM and the central agent(or collector). But in \n>> the cloud, some networks are isolated from infrastructure layer \n>> network, because of security reasons. Some of our customers even \n>> explicitly require such security protection. Does it mean those \n>> isolated VMs cannot be monitored by this proposed-VM-agent?\n>\n> Yes, that sounds plausible to me.\n\nMy understanding is that this VM agent for ceilometer would need connectivity to nova API as well as to the AMQP broker. IMHO the infrastructure requirements from a network topology POV will differ from provider to provider and based on customer reqs / env.\n\n>\n> Cheers,\n> Eoghan\n>\n>> I really wish we can figur out how it could work for all VMs but with \n>> no security issues.\n>>\n>> I\'m not familiar with heat-cfntools, so, correct me if I am wrong :)\n>>\n>>\n>> Best regards!\n>> Kurt\n>>\n>> -----????-----\n>> ???: Eoghan Glynn [mailto:eglynn at redhat.com]\n>> ????: 2014?8?1? 14:46\n>> ???: OpenStack Development Mailing List (not for usage questions)\n>> ??: Re: [openstack-dev] [ceilometer] Compute agent local VM inspector \n>> - potential enhancement\n>>\n>>\n>>\n>>> Disclaimer: I\'m not fully vested on ceilometer internals, so bear with me.\n>>>\n>>> For consumers wanting to leverage ceilometer as a telemetry service \n>>> atop non-OpenStack Clouds or infrastructure they don\'t own, some \n>>> edge cases crop up. Most notably the consumer may not have access to \n>>> the hypervisor host and therefore cannot leverage the ceilometer \n>>> compute agent on a per host basis.\n>>\n>> Yes, currently such access to the hypervisor host is required, least \n>> in the case of the libvirt-based inspector.\n>>\n>>> In such scenarios it\'s my understanding the main option is to employ \n>>> the central agent to poll measurements from the monitored resources \n>>> (VMs, etc.).\n>>\n>> Well, the ceilometer central agent is not generally concerned with \n>> with polling related *directly* to VMs - rather it handles acquiring \n>> data from RESTful API (glance, neutron etc.) that are not otherwise \n>> available in the form of notifications, and also from host-level interfaces such as SNMP.\n>>\n\nThanks for additional clarity. Perhaps this proposed local VM agent fills additional use cases whereupon ceilometer is being used without openstack proper (e.g. not a full set of openstack complaint services like neutron, glance, etc.).\n\n>>> However this approach requires Cloud APIs (or other mechanisms) \n>>> which allow the polling impl to obtain the desired measurements (VM \n>>> memory, CPU, net stats, etc.) and moreover the polling approach has \n>>> it\'s own set of pros / cons from a arch / topology perspective.\n>>\n>> Indeed.\n>>\n>>> The other potential option is to setup the ceilometer compute agent \n>>> within the VM and have each VM publish measurements to the collector\n>>> -- a local VM agent / inspector if you will. With respect to this \n>>> local VM agent approach:\n>>> (a) I haven\'t seen this documented to date; is there any desire / \n>>> reqs to support this topology?\n>>> (b) If yes to #a, I whipped up a crude PoC here:\n>>> http://tinyurl.com/pqjgotv  Are folks willing to consider a BP for \n>>> this approach?\n>>\n>> So in a sense this is similar to the Heat cfn-push-stats utility[1] \n>> and seems to suffer from the same fundamental problem, i.e. the need \n>> for injection of credentials (user/passwds, keys, whatever) into the \n>> VM in order to allow the metric datapoints be pushed up to the \n>> infrastructure layer (e.g. onto the AMQP bus, or to a REST API endpoint).\n>>\n>> How would you propose to solve that credentialing issue?\n>>\n\nMy initial approximation would be to target use cases where end users do not have direct guest access or have limited guest access such that their UID / GID cannot access the conf file. For example instances which only provide app access provisioned using heat SoftwareDeployments\n(http://tinyurl.com/qxmh2of) or trove database instances.\n\nIn general I don\'t see this approach from a security POV much different than whats done with the trove guest agent (http://tinyurl.com/ohvtmtz).\n\nLonger term perhaps credentials could be mitigated using Barbican as suggested here: https://bugs.launchpad.net/nova/+bug/1158328\n\n>> Cheers,\n>> Eoghan\n>>\n>> [1]\n>> https://github.com/openstack/heat-cfntools/blob/master/bin/cfn-push-s\n>> tats\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n',NULL,NULL),('<053F0E67-7EF7-4431-8FD6-1CDA0DB6C330@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 06:39:13',-25200,'2014-08-19 13:39:13',NULL,'[openstack-dev] [Swift] Can gatekeeper middleware be removed\n	from pipeline?','If you do not have the gatekeeper explicitly referenced in your proxy pipeline, Swift will automatically add it.\n\n--John\n\n\n\nOn Aug 19, 2014, at 3:09 AM, Daisuke Morita <morita.daisuke at lab.ntt.co.jp> wrote:\n\n> \n> Hi,\n> \n> Can gatekeeper middleware be removed from pipeline?\n> This does not mean that i want to use Swift without gatekeeper because\n> it can be security risk, but i just want to make it clear whether it is\n> configurable or not.\n> \n> \n> Thanks,\n> \n> -- \n> Daisuke Morita <morita.daisuke at lab.ntt.co.jp>\n> NTT Software Innovation Center, NTT Corporation\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140819/5e9b5e5f/attachment.pgp>\n\n','<53F3225B.4030202@lab.ntt.co.jp>',NULL),('<0545CD046FA0FC4198AC808CA43D32812AC7766C@BLUPRD0511MB438.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 21:50:09',0,'2012-11-13 21:50:09',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','Chatting with Kevin on IRC today - he has a review up (https://review.openstack.org/#/c/16002) that started the conversation, but it all generally boils down to how we accept data in through auth_token middleware and pass it down to subsequent WSGI pipeline components.\n\nThe general issue is that there\'s some extended token data that they\'re using now that doesn\'t get translated and pushed down the WSGI pipeline after receiving the authorization token. His current path with the review is to strip these arbitrary data segments out and add them as HTTP headers. One of the goals that he\'s trying to accomplish is to make it easier to subclass auth_token middleware for use beyond what it does today.\n\nGuang brought up the same need (and I think his team at HP is alrealdy doing it) - so I wanted to get some feedback on the contracts that you (Kevin & Guang) are after to support making auth_token something that\'s stable enough to be subclassed (and to nail down those interfaces so we don\'t accidentally break them in the future). What hooks or methods do your needs for subclasses have today?\n\nGuang mentioned how keystone handles EC2 token validation today - perhaps breaking auth_token middleware into two separate filters, token_validator and context_builder.\n\nCan you illustrate what you\'re after and what methods would help make that most effective?\n\n-joe\n\n\n\n\n\n',NULL,NULL),('<0545CD046FA0FC4198AC808CA43D32812B653098@BN1PRD0512MB667.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-02 18:15:53',0,'2013-01-02 18:15:53',NULL,'[openstack-dev] [keystone] recommending Henry Nash to Keystone core','WIth the new year, I\'d like to recommend Henry Nash (hnash) to Keystone core. He\'s only recently been active in contributions, but has very actively picked up into Keystone development.\n\n-joe\n\n\n\n\n',NULL,NULL),('<0546D784-A958-4B2A-9038-B2337C14E661@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 13:08:20',-14400,'2014-09-05 17:08:20',NULL,'[openstack-dev] oslotest 1.1.0.0a2 released','The Oslo team is pleased to announce the release of oslotest 1.1.0.0a2, the latest version of the oslo library with test base classes and fixtures.\n\nThis release includes:\n\n* Add fixture for mock.patch.multiple\n* Ensure that mock.patch.stopall is called last\n* Remove differences between Python 2.x and 3.x versions\n* Require six\n* Add documentation for running oslo_debug_heler.sh\n* Restructure oslotest docs\n* Add pdb support to tox with debug helper shell script\n* Updated from global requirements\n* Cleaning up index.rst file\n* Add known issue about time.time mocking\n* Updated from global requirements\n* Add API documentation\n* Moving to use the mock module found in Python3\n\nOf particular importance are the Python 2/3 changes related to making oslotest usable by projects that gate on python 3. We are now packaging version independent universal wheels and installing mox3 but not mox by default. If your project uses oslotest and mox, you may need to update your test-requirements.txt to ensure mox is installed. Alternately, you can use the fixtures in oslotest, which now use mox3 instead.\n\nIf you encounter problems with this release today, please report them in #openstack-oslo for quick turn-around.\n\nAfter today, please file bugs in the launchpad bug tracker: https://bugs.launchpad.net/oslotest\n\nDoug\n\n\n\n',NULL,NULL),('<054B1EFE-4BF6-4897-AF7A-C26FC3B2A010@pd.infn.it>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-12 10:42:50',3600,'2014-03-12 09:42:50',NULL,'[Openstack-operators] Experimenting with DHCP Agent redundancy','Hi,\nI\'ve installed 2 Network nodes running only neutron agents (the neutron server is located in the controller node).\nI see this:\n\n# neutron agent-list\n+--------------------------------------+--------------------+-----------------------------+-------+----------------+\n| id                                   | agent_type         | host                        | alive | admin_state_up |\n+--------------------------------------+--------------------+-----------------------------+-------+----------------+\n| 215324e6-f19a-41ce-b967-40089388f9ed | Open vSwitch agent | network-02.cloud.pd.infn.it | :-)   | True           |\n| 55d8c998-2557-4cac-abbc-4a85d9f190a0 | DHCP agent         | network-01.cloud.pd.infn.it | :-)   | True           |\n| 5c03007b-6b02-4260-9f5c-7f1e951cf1b0 | Open vSwitch agent | compute.cloud.pd.infn.it    | :-)   | True           |\n| 97ec9951-5c7b-45e0-9de6-40d4efeccd6b | L3 agent           | network-01.cloud.pd.infn.it | :-)   | True           |\n| c96ab5a0-2ef4-4f44-90bb-686bbaef4f55 | DHCP agent         | network-02.cloud.pd.infn.it | :-)   | True           |\n| cbe4e6bc-0dda-46df-b170-93f6d324a0a5 | Open vSwitch agent | network-01.cloud.pd.infn.it | :-)   | True           |\n| dedc11e7-c1c5-4db3-be90-d218f210a00a | L3 agent           | network-02.cloud.pd.infn.it | :-)   | True           |\n+--------------------------------------+--------------------+-----------------------------+-------+----------------+\n\nI\'ve created 2 networks (one is external -\"esterna\"-, the other one is not - \"interna\"-):\n\n# neutron net-list\n+--------------------------------------+---------+------------------------------------------------------+\n| id                                   | name    | subnets                                              |\n+--------------------------------------+---------+------------------------------------------------------+\n| 6cd46839-c434-42e2-9b9e-a3b2a7fae470 | esterna | 08c33f86-c34a-4fa3-8295-5f9866d9527d 192.135.16.0/24 |\n| e1cd28e4-83da-4dc8-bae8-f50600baeff9 | interna | 7ec2317c-40c5-4daf-9997-1242fd4f78b0 192.168.70.0/24 |\n+--------------------------------------+---------+------------------------------------------------------+\n\nI\'ve added the net \"interna\" to both dhcp-agents:\n\n# neutron dhcp-agent-list-hosting-net interna\n+--------------------------------------+-----------------------------+----------------+-------+\n| id                                   | host                        | admin_state_up | alive |\n+--------------------------------------+-----------------------------+----------------+-------+\n| 55d8c998-2557-4cac-abbc-4a85d9f190a0 | network-01.cloud.pd.infn.it | True           | :-)   |\n| c96ab5a0-2ef4-4f44-90bb-686bbaef4f55 | network-02.cloud.pd.infn.it | True           | :-)   |\n+--------------------------------------+-----------------------------+----------------+-------+\n\nVM creation goes smoothly well (I\'m using the cirros 0.3.1).\n\nNow, if I disable one of the two dhcp agents (using the command \"neutron agent-update 55d8c998-2557-4cac-abbc-4a85d9f190a0 --admin_state_up=false\") I\'d expect that the second dhcp agent can take care of the (new) VMs asking for dhcp address... \nI disabled the first (network-01) dhcp agent.\nIf I create a new VM it will never get its IP address. So it seems to me that the second dhcp agent (running on network-02) is not actually doing its job... \nIf I re-enable the first dhcp agent, new VMs get their IPs.\n\nWhat could I have missed in the procedure ?\n\nthanks,\n\n  Alvise\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 1756 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140312/108837ff/attachment.bin>\n\n',NULL,NULL),('<054B3033-D174-4DB3-A634-B95639304403@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 17:09:54',-18000,'2013-12-06 22:09:54',NULL,'[openstack-dev] [neutron] Questions on logging setup for development','Hi,\n\nFor Neutron, I\'m creating a module (one of several eventually) as part of a new blueprint I\'m working on, and the associated unit test module. I\'m in really early development, and just running this UT module as a standalone script (rather than through tox). It allows me to do TDD pretty quickly on the code I\'m developing (that\'s the approach I\'m taking right now - fingers crossed :).\n\nIn the module, I did an import of the logging package and when I run UTs I can see messaging that would occur, if desired.\n\nI have the following hack to turn off/on the logging for debug level:\n\nif False:  # Debugging\n    logging.basicConfig(format=\'%(asctime)-15s [%(levelname)s] %(message)s\',\n                        level=logging.DEBUG)\n\nI made the log calls the same as what would be in other Neutron code, so that I don\'t have to change the code later, as I start to fold it into the Neutron code. However, I\'d like to import the neutron.openstack.common.log package in my code, so that the code will be identical to what is needed once I start running this code as part of a process, but I had some questions?\n\nWhen using neutron.openstack.common.log, how do I toggle the debug level logging on, if I run this standalone, as I\'m doing now?\nIs there a way to do it, without adding in the above conditional logic to the production code? Maybe put something in the UT module?\n\nI can always continue as is, and then switch things over later (changing the import line and pulling the if clause), once I have things mostly done, and want to run as part of Neutron, but it would be nice if I can find a way to do that up front to avoid changes later.\n\nThoughts? Suggestions?\n\nThanks!\n\n\nPCM (Paul Michali)\n\nMAIL          pcm at cisco.com\nIRC            pcm_  (irc.freenode.net)\nTW            @pmichali\nGPG key    4525ECC253E31A83\nFingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/62a427b4/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 841 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/62a427b4/attachment-0001.pgp>\n\n',NULL,NULL),('<054CF30FE34F4A52A710A5972215AEF9@dewey.ws>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 20:03:16',-25200,'2013-07-30 03:03:16',NULL,'[Openstack] nova list failure when quantum_url points to HTTPS\n	endpoint','Was curious if anyone else has run into this issue, and could provide some feedback.\n\nhttps://bugs.launchpad.net/nova/+bug/1206330\n\nThanks -\nJohn\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/cabb9184/attachment.html>\n\n',NULL,NULL),('<054E73BE-7CC7-4F58-8014-E9ED8D610C21@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 16:32:17',-28800,'2014-02-26 00:32:17',NULL,'[openstack-dev] [Mistral]','I have created a blueprint to capture the intention to simplify calling standard actions:\n\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-shorthand-action-in-dsl\n\nDZ> \n\nOn Feb 11, 2014, at 7:40 AM, Dmitri Zimine <dz at stackstorm.com> wrote:\n\n> Yes it makes sense, let\'s draft how it may look;\n> \n> and also think over implementation implications - now we separate task parameters, action parameters, and service parameters, we may need to merge them when instantiating the action. \n> \n> DZ. \n> \n> On Feb 11, 2014, at 6:19 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> \n>> Dmitry, I think you are right here. I think for simple case we should be able to use in-place action definition without having to define the action separately. Like you said it?s only valuable if we need to reuse it.\n>> \n>> The only difference I see between std:send-email and something like REST_API is that a set of parameters for the latter is dynamic (versus std:send-email where it?s always ?recipients?, ?subject?, ?body?). Even though it?s still the same protocol (HTTP) but a particular request representation may be different (i.e. query string, headers, the structure of body in case POST etc.). But I think that doesn?t cancel the idea of being able to define the action along with the task itself.\n>> \n>> So good point. As for the syntax itself, we need to think it over. In the snippet you provided ?action: std:REST_API?, so we need to make sure not to have ambiguities in the ways how we can refer actions. A convention could be ?if we don?t use a namespace we assume that there?s a separate action definition included into the same workbook, otherwise it should be considered in-place action definition and task property ?action? refers to an action type rather than the action itself?. Does that make sense?\n> \n>> \n>> Renat Akhmerov\n>> @ Mirantis Inc.\n>> \n>> On 11 Feb 2014, at 16:23, Dmitri Zimine <dz at stackstorm.com> wrote:\n>> \n>>> Do we have (or think about) a shorthand to calling REST_API action, without defining a service? \n>>> \n>>> FULL  DSL:\n>>> \n>>> Services:\n>>> TimeService:\n>>> 	type: REST_API\n>>> 	parameters:\n>>> 	  baseUrl:http://api.timezonedb.com\n>>> 	  key:<my_api_key>\n>>> 	actions:\n>>> 	  get-time:\n>>> 	    task-parameters:\n>>> 	      zone:\n>>> Workflow:\n>>> tasks:\n>>>    timeInToronto:\n>>>       action: TimeService:get-time\n>>>       parameters:\n>>>         zone: \"America/Toronto\"\n>>> \n>>> SHORTCUT - may look something like this: \n>>> \n>>> Workflow:\n>>> tasks:\n>>>     timeInToronto:\n>>> 	    action:std:REST_API\n>>> 	    parameters:\n>>> 	      baseUrl: \"http://api.timezonedb.com\"\n>>> 	      method: \"GET\"\n>>> 	      parameters: \"zone=/America/Toronto&key=<my_api_key>\"\n>>> 	      \n>>> Why asking:  \n>>> \n>>> 1) analogy with std:send-email action. I wonder do we have to make user define Service for std:send-email? and I think that for standard tasks we shouldn\'t have to. If there is any thinking on REST_API, it may apply here. \n>>> \n>>> 2) For a one-off web service calls the complete syntax is may be overkill (but yes, it comes handy for reuse). See examples below. \n>>> \n>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/9850b1ea/attachment.html>\n\n','<7C136F15-A5C8-4A71-9008-F3AD537B9B61@stackstorm.com>',NULL),('<055DDECD-FE53-4499-80B8-CABC2785426B@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-18 11:48:03',-28800,'2012-12-18 19:48:03',NULL,'[openstack-dev] Novaclient and Extensions','\nOn Dec 18, 2012, at 11:26 AM, Matt Dietz <matt.dietz at rackspace.com> wrote:\n\n> I agree with this\n> \n> The only thing I would add is it would be ideal if the extensions were treated explicitly as extensions. More specifically, if the client documentation made it clear that extension X might not be available across all openstack clouds. That the client currently sorts the extensions docstrings in with the rest of the core functionality could lead to some confusion down the road. \n\nI think we are on the same page here. I\'d like to outline a few steps:\n\na) Add some logic in novaclient to only show extensions which have a matching endpoint if nova help is called with credentials\nb) Move all existing extension functionality into the novaclient/v1_1/contrib/ dir\nc) Update the client documentation to make it clear which functionality is extension based.\n\nThis should be fairly easy for the large blocks of extension functionality (e.g. os-networks) but it will be tricky for the extensions that add extra parameters to existing commands. We may be able to figure out how to tag which options are enabled by which extensions, but if not we could at the very least add some comments to the help text like (requires os-keypairs extension)\n\nWe should be careful about moving around classes for people using python-novaclient as a library as well.\n\nVish\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121218/88cf11a8/attachment.html>\n\n','<CCF61F00.28E75%matt.dietz@rackspace.com>',NULL),('<0560CF36-BF60-4793-AD52-DCE852BA8132@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 08:49:23',-25200,'2013-09-26 15:49:23',NULL,'[openstack-dev] [trove] Configuration API BP','On Sep 25, 2013, at 7:16 PM, Craig Vyvial wrote:\n\n> So we have a blueprint for this and there are a couple things to point out that have changed since the inception of this BP.\n> \n> https://blueprints.launchpad.net/trove/+spec/configuration-management\n> \n> This is an overview of the API calls for \n> \n> POST /configurations - create config\n> GET  /configurations - list all configs\n> PUT  /configurations/{id} - update all the parameters\n> \n> GET  /configurations/{id} - get details on a single config\n> GET  /configurations/{id}/{key} - get single parameter value that was set for the configuration\n> \n> PUT  /configurations/{id}/{key} - update/insert a single parameter\n> DELETE  /configurations/{id}/{key} - delete a single parameter\n> \n> GET  /configurations/{id}/instances - list of instances the config is assigned to\n> GET  /configurations/parameters - list of all configuration parameters\n> \n> GET  /configurations/parameters/{key} - get details on a configuration parameter\n> \n> There has been talk about using PATCH http action instead of PUT action for thie update of individual parameter(s).\n> \n> PUT  /configurations/{id}/{key} - update/insert a single parameter\n> and/or\n> PATCH  /configurations/{id} - update/insert parameter(s)\n> \n> \n> I am not sold on the idea of using PATCH unless its widely used in other projects across Openstack. What does everyone think about this?\n> \n> If there are any concerns around this please let me know.\n\nIm a fan of PATCH. Id rather have a different verb on the same resource than creating a new sub-resource just to do the job of what PATCH defines. Im not sure the [1] gives us any value, and i think its only around because of [2]. I can see PATCH removing the need for [1], simplifying the API. And of course removing the need for [2] since it _is_ the updating of a single kv pair. And i know keystone and glance use PATCH for \"updates\" in their API as well. \n\n[1]  GET /configurations/{id}/{key} \n[2] PUT  /configurations/{id}/{key} \n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/8cb1c258/attachment.pgp>\n\n','<CAOK58XRZ4oZgNxV7Nf0gPnQCOopCDQJW7gEc9zPbbR1cS4Mo_A@mail.gmail.com>',NULL),('<0561F0388A5B49F4B9B784F6947E4DFD@dewey.ws>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-26 14:25:10',-25200,'2013-10-26 21:25:10',NULL,'[Openstack-operators] havana keystone and memcache tokens','Follow-up on my own thread.\n\nhttps://bugs.launchpad.net/bugs/1245060\n\nJohn  \n\n\nOn Friday, October 25, 2013 at 3:56 PM, John Dewey wrote:\n\n> Has anyone configured havana keystone with memcached.  It looks to be configured much differently than grizzly.  \n>  \n> I am looking at the docs [1], but am running into issues.  Keystone does not parse the URL.  Returns an error about the port needing specified, however, no matter which options I pass to URL it doesn?t seem to work.\n>  \n> The config looks as follows:\n>  \n> [token]\n> driver = keystone.token.backends.memcache.Token\n>  \n> [cache]\n> backend = dogpile.cache.memcached\n> backend_argument = url:10.10.10.26\n>  \n>  \n>  \n> [1] http://docs.openstack.org/developer/keystone/_sources/configuration.txt\n>  \n> John  \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131026/89cf176a/attachment.html>\n\n','<DA3BF032C72342F09924CA7DF3697D65@dewey.ws>',NULL),('<0593A7D3-1772-4EC4-832E-80222017ABB4@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-18 01:11:54',0,'2014-04-18 01:11:54',NULL,'[openstack-dev] [Neutron][LBaaS] HA functionality discussion','\nOn Apr 17, 2014, at 5:49 PM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>>\n wrote:\n\nHeyas, y\'all!\n\nSo, given both the prioritization and usage info on HA functionality for Neutron LBaaS here:  https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing\n\nIt\'s clear that:\n\nA. HA seems to be a top priority for most operators\nB. Almost all load balancer functionality deployed is done so in an Active/Standby HA configuration\n\nI know there\'s been some round-about discussion about this on the list in the past (which usually got stymied in \"implementation details\" disagreements), but it seems to me that with so many players putting a high priority on HA functionality, this is something we need to discuss and address.\n\nThis is also apropos, as we\'re talking about doing a major revision of the API, and it probably makes sense to seriously consider if or how HA-related stuff should make it into the API. I\'m of the opinion that almost all the HA stuff should be hidden from the user/tenant, but that the admin/operator at the very least is going to need to have some visibility into HA-related functionality. The hope here is to discover what things make sense to have as a \"least common denominator\" and what will have to be hidden behind a driver-specific implementation.\n\nI certainly have a pretty good idea how HA stuff works at our organization, but I have almost no visibility into how this is done elsewhere, leastwise not enough detail to know what makes sense to write API controls for.\n\nSo! Since gathering data about actual usage seems to have worked pretty well before, I\'d like to try that again. Yes, I\'m going to be asking about implementation details, but this is with the hope of discovering any \"least common denominator\" factors which make sense to build API around.\n\nFor the purposes of this document, when I say \"load balancer devices\" I mean either physical or virtual appliances, or software executing on a host somewhere that actually does the load balancing. It need not directly correspond with anything physical... but probably does. :P\n\nAnd... all of these questions are meant to be interpreted from the perspective of the cloud operator.\n\nHere\'s what I\'m looking to learn from those of you who are allowed to share this data:\n\n1. Are your load balancer devices shared between customers / tenants, not shared, or some of both?\n     If by shared you mean the ability to add and delete loadbalancer Our loadbalancers are not shared by different customers which we call accounts. If your referring to networking then yes they are on the same clan. Our clusters are basically a physical grouping of 4 or 5 stingray devices that share IPs on the vip side. The configs are created on all stingray nodes in a cluster. If a stingray loadbalancer goes down all its vips will be taken over by one of the other 4 or 5 machines. We achieve HA by moving noisy customers IPs to another stingray node. The machine taking over an ip will send a gratuitous ARP response for the router to train its arp table on.  Usually we have 2 stingray nodes available for fail over. We could have spread the load across all boxes evenly but we felt that if we were near the end of the capacity for a given cluster if one of the nodes tanked this would have degraded performance as the other nodes were already nearing capacity.\n\n    We also have the usual dual switch dual router set up incase one dies config.\n\n1a. If shared, what is your strategy to avoid or deal with collisions of customer rfc1918 address space on back-end networks? (For example, I know of no load balancer device that can balance traffic for both customer A and customer B if both are using the 10.0.0.0/24<http://10.0.0.0/24> subnet for their back-end networks containing the nodes to be balanced, unless an extra layer of NATing is happening somewhere.)\n\n    We order a set of CIDR blocks from our backbone and route them to our Cluster via a 10Gig/s link which In our bigger clusters can be upgraded via link bonding.\ndownstream we have two routes to one route for our own internal ServiceNet 10.0.0.0/8 space and the public Internet for everything not on our service net. Our pool members are specified by CIDR block only with no association to a layer 2 network. When customers create their cloud servers they will be assigned an IP with in the address space of 10.0.0.0/24 and also get a publicly routable IP address. At that point the customer cane achieve isolation via IP tables or what ever tools their VM supports. In theory a user could mistaking punch in an IP address in a node that doesn\'t belong to them but that just means the lb will route to only one machine but the loadbalancer would be useless at that point. We don\'t charge our users for bandwidth going across service net since each DC has its own service net and our customers want to have the LoadBalancer close to their servers anyways. If they want to host back end servers on say Amazon hostgater or what ever then then the loadbalancer will unfortunately route over the public interet for those. I\'m not sure why customers would want to do this but we were flexible enough to support it. In short HA is achieved through shared ips between our Stingray Nodes.\nWe have 2 fail over nodes that basically do nothing on standby just in case an active node suddenly dies. So I guess you could call this HA n+1. We also divide the cluster into two cabinets with a failover in each one heaven forbid a whole cabinet should sudden fail. We\'ve never seen this happen Knock on wood.\n\n\n2. What kinds of metrics do you use in determining load balancing capacity?\n\n    so far we\'ve been measuring bandwidth for the most part as it usually caps out before CPU does. Out newest Stingray nodes have 24 cores. We of course gather metrics for IP space left (So we can order more ahead of time) We have noticed that we are limited to horizontal scaling of around 6 stingray nodes. CPU load goes up after 6 nodes which we have determined to be due to the rapidly changing configs must be synced across all the stingray nodes, stingray has a pretty nasty flaw in how it sends its configs to its other stingray nodes in cluster.\n\n    In the case of SSL if an SSL user uses SSL in mixed mode (meaning http and https not sure why\'ed they do) we actually set up two virtual servers transparent to the customers so we track the ssl bandwidth separately but using the same SNMP call.\n\n3. Do you operate with a pool of unused load balancer device capacity (which a cloud OS would need to keep track of), or do you spin up new capacity (in the form of virtual servers, presumably) on the fly?\n\n    Kind of answered in question 1. This doesn\'t apply to much to us as we use physical loadbalancers behind our API. For CLB2.0 we would like to see how we would achieve the same level of HA in the virtual space world.\n\n3a. If you\'re operating with a availability pool, can you describe how new load balancer devices are added to your availability pool?  Specifically, are there any steps in the process that must be manually performed (ie. so no API could help with this)?\n\n    The API could help with some aspects of this. For example we have and are advocating a separate management API thats separate from the public one that can do things like tell the provisioner(What your calling a scheduler) when new capacity is available how to route to it and store this in the database for the public API to use in determing how to allocate resources. Our management API in particular is used to add IPv4 address space to our database once backbone routes them to us. So its like our current process involves the classic Hey Back bone I\'d like to order a new /22 were running low on ips. Then the management interface could then be called to add the CIDR block so that it can track the ips in its database.\n\n\n4. How are new devices \'registered\' with the cloud OS? How are they removed or replaced?\n\n5. What kind of visibility do you (or would you) allow your user base to see into the HA-related aspects of your load balancing services?\n    We don\'t. We view HA in terms of redundant hardware and floating IPs and being that end users don\'t control those its not visible. We do state our 4 nines uptime which hasten\'t been broken as well as compensation for violations of our end of the SLA agreement.\n\nhttp://www.rackspace.com/information/legal/cloud/sla\nhttps://status.rackspace.com/\n\n6. What kind of functionality and visibility do you need into the operations of your load balancer devices in order to maintain your services, troubleshoot, etc.? Specifically, are you managing the infrastructure outside the purview of the cloud OS? Are there certain aspects which would be easier to manage if done within the purview of the cloud OS?\n\n     We wrote SNMP tools to monitor the Stingray nodes which our executed by  our Api nodes. Stingray offers a rich oid MIB that allows us to track pretty much anything. But we only look at Bandwidth In, Bandwidth out,  and the number of concurrent connections. I\'m considering adding CPU statistics now actually.\n\n\n7. What kind of network topology is used when deploying load balancing functionality? (ie. do your load balancer devices live inside or outside customer firewalls, directly on tenant networks? Are you using layer-3 routing? etc.)\n\nJust pure layer3. This limitation has left us wanting a private networking solution and during that investigation we arrived here in Neutron/Lbaas.\n\n\n\n8. Is there any other data you can share which would be useful in considering features of the API that only cloud operators would be able to perform?\n\n   Shared and failoverable IPs is desired. but much of the HA stuff will come from the driver/provider. I just think floating IPs just needs to be supported by the api or at least query able to see if it supports floating ips.\n\nAnd since we\'re one of these operators, here are my responses:\n\n1. We have both shared load balancer devices and private load balancer devices.\n\n1a. Our shared load balancers live outside customer firewalls, and we use IPv6 to reach individual servers behind the firewalls \"directly.\" We have followed a careful deployment strategy across all our networks so that IPv6 addresses between tenants do not overlap.\n\nyea us too. We hash the tenant_id into 32bits and use it in bits 64-96 leaving the customer with 32 bits to play for their hosts. If they need more then 4 billion then we have bigger problems. Our cluster is a /48 so were wasting 16 bits on nothing in the middle.\nCluster, Tenant id, host_id\nCCCC:CCCC:CCCC:0000:TTTT:TTTT:HHHH:HHHH\n\n\n\n2. The most useful ones for us are \"number of appliances deployed\" and \"number and type of load balancing services deployed\" though we also pay attention to:\n* Load average per \"active\" appliance\n* Per appliance number and type of load balancing services deployed\n* Per appliance bandwidth consumption\n* Per appliance connections / sec\n* Per appliance SSL connections / sec\n\nSince our devices are software appliances running on linux we also track OS-level metrics as well, though these aren\'t used directly in the load balancing features in our cloud OS.\n\n3. We operate with an availability pool that our current cloud OS pays attention to.\n\n3a. Since the devices we use correspond to physical hardware this must of course be rack-and-stacked by a datacenter technician, who also does initial configuration of these devices.\n\n4. All of our load balancers are deployed in an active / standby configuration. Two machines which make up an active / standby pair are registered with the cloud OS as a single unit that we call a \"load balancer cluster.\" Our availability pool consists of a whole bunch of these load balancer clusters. (The devices themselves are registered individually at the time the cluster object is created in our database.) There are a couple manual steps in this process (currently handled by the datacenter techs who do the racking and stacking), but these could be automated via API. In fact, as we move to virtual appliances with these, we expect the entire process to become automated via API (first cluster primitive is created, and then \"load balancer device objects\" get attached to it, then the cluster gets added to our availability pool.)\n\nRemoval of a \"cluster\" object is handled by first evacuating any customer services off the cluster, then destroying the load balancer device objects, then the cluster object. Replacement of a single load balancer device entails removing the dead device, adding the new one, synchronizing configuration data to it, and starting services.\n\n5. At the present time, all our load balancing services are deployed in an active / standby HA configuration, so the user has no choice or visibility into any HA details. As we move to Neutron LBaaS, we would like to give users the option of deploying non-HA load balancing capacity. Therefore, the only visibility we want the user to get is:\n\n* Choose whether a given load balancing service should be deployed in an HA configuration (\"flavor\" functionality could handle this)\n* See whether a running load balancing service is deployed in an HA configuration (and see the \"hint\" for which physical or virtual device(s) it\'s deployed on)\n* Give a \"hint\" as to which device(s) a new load balancing service should be deployed on (ie. for customers looking to deploy a bunch of test / QA / etc. environments on the same device(s) to reduce costs).\n\nNote that the \"hint\" above corresponds to the \"load balancing cluster\" alluded to above, not necessarily any specific physical or virtual device. This means we retain the ability to switch out the underlying hardware powering a given service at any time.\n\nUsers may also see usage data, of course, but that\'s more of a generic stats / billing function (which doesn\'t have to do with HA at all, really).\n\n6. We need to see the status of all our load balancing devices, including availability, current role (active or standby), and all the metrics listed under 2 above. Some of this data is used for creating trend graphs and business metrics, so being able to query the current metrics at any time via API is important. It would also be very handy to query specific device info (like revision of software on it, etc.) Our current cloud OS does all this for us, and having Neutron LBaaS provide visibility into all of this as well would be ideal. We do almost no management of our load balancing services outside the purview of our current cloud OS.\n\n7. Shared load balancers must live outside customer firewalls, private load balancers typically live within customer firewalls (sometimes in a DMZ). In any case, we use layer-3 routing (distributed using routing protocols on our core networking gear and static routes on customer firewalls) to route requests for \"service IPs\" to the \"highly available routing IPs\" which live on the load balancers themselves. (When a fail-over happens, at a low level, what\'s really going on is the \"highly available routing IPs\" shift from the active to standby load balancer.)\n\nWe have contemplated using layer-2 topology (ie. directly connected on the same vlan / broadcast domain) and are building a version of our appliance which can operate in this way, potentially reducing the reliance on layer-3 routes (and making things more friendly for the OpenStack environment, which we understand probably isn\'t ready for layer-3 routing just yet).\n\n8. I wrote this survey, so none come to mind for me. :)\n\nStephen\n\n--\nStephen Balukoff\nBlue Box Group, LLC\n(800)613-4305 x807\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/f1d24ef3/attachment.html>\n\n','<CAAGw+Zrmnv8_74K6KHGa48VU_TJHtETKVFh1khDxni0wpVqdxg@mail.gmail.com>',NULL),('<0596A414-D154-4643-91DF-20C9E8B744D2@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 15:35:23',0,'2013-08-06 15:35:23',NULL,'[openstack-dev] [DevStack] Python dependencies: PyPI vs\n	distro	packages','I think jay your usage also was before anvil started to build all the *missing* dependencies automatically (something u inspired me to get going in the first place) so hopefully said updates to rhel.yaml are only now needed for exceptions and not the common path :)\n\nSent from my really tiny device...\n\nOn Aug 6, 2013, at 8:28 AM, \"Jay Buffington\" <me at jaybuff.com<mailto:me at jaybuff.com>> wrote:\n\nOn Tue, Aug 6, 2013 at 4:36 AM, Ian Wienand <iwienand at redhat.com<mailto:iwienand at redhat.com>> wrote:\nOn Mon, Aug 05, 2013 at 03:37:24PM -0700, Jay Buffington wrote:\n> I used Anvil for the first three months, but it required constant\n> updating of dependency versions and it didn\'t support quantum.\n\nWhat do you mean by \"updating\" here?  The rpm packages being updated\ncausing a lot of churn, or some manual intervention required on your\nbehalf?\n\nUpdating Anvil\'s conf/distros/rhel.yaml\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130806/c6885c86/attachment.html>\n\n','<CAGezO6FQuKUkjpF+bOs99AxTXQs2Xw9-DQSC2QyRW5DQ=J51OQ@mail.gmail.com>',NULL),('<05A7DD2E-A93B-4154-871D-88B12B575CA3@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 17:02:28',0,'2014-02-19 17:02:28',NULL,'[openstack-dev] [python-openstacksdk] REMINDER: First meeting\n scheduled','\n\nOn Feb 11, 2014, at 2:40 PM, Jesse Noller <jesse.noller at RACKSPACE.COM> wrote:\n\n> As I said last week; we?re ready to kickoff and have regular meetings for the ?unified python SDK? project. The initial meeting is scheduled on the wiki:\n> \n> https://wiki.openstack.org/wiki/Meetings#python-openstacksdk_Meeting\n> \n> Date/Time: Feb. 19th - 19:00 UTC / 1pm CST \n> \n> IRC channel: #openstack-meeting-3\n> \n> Meeting Agenda: \n> 	https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK\n> \n> About the project: \n> 	https://wiki.openstack.org/wiki/PythonOpenStackSDK\n> \n> If you have questions, all of us lurk in #openstack-sdks on freenode!\n> \n> See you then.\n> \n> Jesse\n\nReminder: today?s meeting is on!\n\n\n\n','<21F2BFD1-F814-4791-B688-26A1C7044C90@rackspace.com>',NULL),('<05b1d9437c44dd36cbf82dc77cd6b5a3@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 17:13:13',-21600,'2013-12-03 23:13:13',NULL,'[openstack-dev] creating a default for oslo config variables  within a project?','On 2013-12-03 17:09, Sean Dague wrote:\n> On 12/03/2013 05:50 PM, Mark McLoughlin wrote:\n>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:\n>>> On 2013-12-03 15:56, Sean Dague wrote:\n>>>> This cinder patch - https://review.openstack.org/#/c/48935/\n>>>> \n>>>> Is blocked on failing upgrade because the updated oslo lockutils \n>>>> won\'t\n>>>> function until there is a specific configuration variable added to \n>>>> the\n>>>> cinder.conf.\n>>>> \n>>>> That work around is proposed here -\n>>>> https://review.openstack.org/#/c/52070/3\n>>>> \n>>>> However I think this is exactly the kind of forward breaks that we \n>>>> want\n>>>> to prevent with grenade, as cinder failing to function after a \n>>>> rolling\n>>>> upgrade because a config item wasn\'t added is exactly the kind of \n>>>> pain\n>>>> we are trying to prevent happening to ops.\n>>>> \n>>>> So the question is, how is this done correctly so that a default can \n>>>> be\n>>>> set in the cinder code for this value, and it not require a config\n>>>> change to work?\n>> \n>> You\'re absolutely correct, in principle - if the default value for\n>> lock_path worked for users before, we should absolutely continue to\n>> support it.\n>> \n>>> I don\'t know that I have a good answer on how to handle this, but for\n>>> context this change is the result of a nasty bug in lockutils that \n>>> meant\n>>> external locks were doing nothing if lock_path wasn\'t set.  Basically\n>>> it\'s something we should never have allowed in the first place.\n>>> \n>>> As far as setting this in code, it\'s important that all of the \n>>> processes\n>>> for a service are using the same value to avoid the same bad \n>>> situation\n>>> we were in before.  For tests, we have a lockutils wrapper\n>>> (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282) that sets an environment variable to address this, but that only works if all of the processes are going to be spawned from within the same wrapper, and I\'m not sure how secure that is for production deployments since it puts all of the lock files in a temporary directory.\n>> \n>> Right, I don\'t think the previous default really \"worked\" - if you \n>> used\n>> the default, then external locking was broken.\n>> \n>> I suspect most distros do set a default - I see RDO has this in its\n>> default nova.conf:\n>> \n>>   lock_path = /var/lib/nova/tmp\n>> \n>> So, yes - this is all terrible.\n>> \n>> IMHO, rather than raise an exception we should log a big fat warning\n>> about relying on the default and perhaps just treat the lock as an\n>> in-process lock in that case ... since that\'s essentially what it was\n>> before, right?\n> \n> So a default of lock_path = /tmp will work (FHS says that path has to \n> be\n> there), even if not optimal. Could we make it a default value like that\n> instead of the current default which is null (and hence the problem).\n\nIIRC, my initial fix was something similar to that, but it got shot down \nbecause putting the lock files in a known world writeable location was a \nsecurity issue.\n\nAlthough maybe if we put them in a subdirectory of /tmp and ensured that \nthe permissions were such that only the user running the service could \nuse that directory, it might be acceptable?  We could still log a \nwarning if we wanted.\n\nThis seems like it would have implications for people running services \non Windows too, but we can probably find a way to make that work if we \ndecide on a solution.\n\n-Ben\n\n\n','<529E64A2.1020502@dague.net>',NULL),('<05BA3FD4-B587-4BBA-B069-240B62FB802A@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-27 09:12:01',-25200,'2012-07-27 16:12:01',NULL,'[openstack-dev] [nova] [quantum] [cinder] Deprecating usage of\n	root_helper=\"sudo\"','\nOn Jul 27, 2012, at 6:08 AM, Thierry Carrez wrote:\n\n> For Folsom, we could mark usage of root_helper as deprecated (but\n> obviously still support it) so that we can get rid of it during Grizzly.\n> It would be replaced with rootwrap_path and rootwrap_conf options. For\n> Grizzly, you would *have to* use those new rootwrap_* options.\n\nSeems perfectly reasonable to me.\n\nVish\n\n\n\n','<501292C9.7070100@openstack.org>',NULL),('<05c4ca295a54425f83b8398375a6a615@BL2PR03MB452.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-28 04:44:13',0,'2014-02-28 04:44:13',NULL,'[Openstack] linuxbridge and vxlan set up','Hi ,\nDid you add the following lines in neutron.conf\n\ncore_plugin = neutron.plugins.ml2.plugin.Ml2Plugin\nservice_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin\n\nAdd above mentioned service plugins.\n\nAnd check ypur network node is reachable from outside world (i.e br-ex).\n\nRegards,\nVeera.\n\n-----Original Message-----\nFrom: Li Ma [mailto:mali at awcloud.com] \nSent: Friday, February 28, 2014 8:25 AM\nTo: Openstack Milis; openstack-operators at lists.openstack.org\nSubject: [Openstack] linuxbridge and vxlan set up\n\nHi all, I\'m trying to build a testbed for Linux Bridge + VXLAN + ML2 plugin, 1 controller, 1 network, 1 compute node.\n\nRight now, the fixed IPs are all working well because I can ping each other inside the namespace on the network node, but floating IPs are not working. I cannot reach instances via floating IP from outside.\n\nIt seems that my network node(l3-agent, dhcp-agent, linuxbridge-agent) is not set properly.\n\nCould someone provide a guide for how to configure linuxbridge using vxlan? (The official doc seems not available.)\n\nThanks a lot,\n--\ncheers,\nLi Ma\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<530FFA94.2090107@awcloud.com>',NULL),('<05C73190-6B48-4155-827A-9655E46CA6A3@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-08 10:16:13',-21600,'2012-02-08 16:16:13',NULL,'[OpenStack Foundation] Foundation Mission Update','On Feb 8, 2012, at 5:15 AM, Thierry Carrez wrote:\n> Just noticed a typo:\n> \"Responsibilties\" -> \"Responsibilities\"\n\nFixed\n\n\n','<4F325957.4070802@openstack.org>',NULL),('<05DBCB67-C0BB-4AFB-92DF-C4F636B6F22A@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 15:09:35',25200,'2014-03-13 08:09:35',NULL,'[openstack-dev] [Mistral] Error on running tox','Ok, awesome. Btw, when I was writing tests for Data Flow I didn?t make assumptions about order of tasks. You can take a look at how it?s achieved.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 13 Mar 2014, at 02:04, Manas Kelshikar <manas at stackstorm.com> wrote:\n\n> Works ok if I directly run nosetests from the virtual environment or even in the IDE. I see this error only when I run tox.\n> \n> In anycase after looking at the specific testcases I can tell that the test makes some ordering assumptions which may not be required. I will send out a patch soon and we can move the conversation to the review.\n> \n> Thanks!\n> \n> \n> On Wed, Mar 12, 2014 at 11:00 AM, Manas Kelshikar <manas at stackstorm.com> wrote:\n> I pasted only for python 2.6 but exact same errors with 2.7. Also, I posted this question after I nuked my entire dev folder so this was being run on a new environment.\n> \n> /Manas\n> \n> \n> On Wed, Mar 12, 2014 at 4:44 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> I would just try to recreate virtual environments. We haven?t been able to reproduce this problem so far.\n> \n> Renat Akhmerov\n> @ Mirantis Inc.\n> \n> \n> \n> On 12 Mar 2014, at 16:32, Nikolay Makhotkin <nmakhotkin at mirantis.com> wrote:\n> \n>> maybe something wrong with python2.6? \n>> \n>> .tox/py26/lib/python2.6/site-packages/mock.py\", line 1201, in patched\n>> \n>> what if you try it on py27?\n>> \n>> \n>> On Wed, Mar 12, 2014 at 10:08 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n>> Ok. I might be related with oslo.messaging change that we merged in yesterday but I don?t see at this point how exactly.\n>> \n>> Renat Akhmerov\n>> @ Mirantis Inc.\n>> \n>> \n>> \n>> On 12 Mar 2014, at 12:38, Manas Kelshikar <manas at stackstorm.com> wrote:\n>> \n>>> Yes it is 100% reproducible.\n>>> \n>>> Was hoping it was environmental i.e. missing some dependency etc. but since that does not seem to be the case I shall debug locally and report back.\n>>> \n>>> Thanks!\n>>> \n>>> \n>>> On Tue, Mar 11, 2014 at 9:54 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n>>> Hm.. Interesting. CI wasn?t able to reveal this for some reason.\n>>> \n>>> My first guess is that there?s a race condition somewhere. Did you try to debug it? And is this error 100% repeatable?\n>>> \n>>> Renat Akhmerov\n>>> @ Mirantis Inc.\n>>> \n>>> \n>>> \n>>> On 12 Mar 2014, at 11:18, Manas Kelshikar <manas at stackstorm.com> wrote:\n>>> \n>>>> I see this error when I run tox. I pulled down a latest copy of master and tried to setup the environment. Any ideas?\n>>>> \n>>>> See http://paste.openstack.org/show/73213/ for details. Any help is appreciated.\n>>>> \n>>>> \n>>>> \n>>>> Thanks,\n>>>> \n>>>> Manas\n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> \n>> -- \n>> Best Regards,\n>> Nikolay\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/632b7867/attachment.html>\n\n','<CAH4gZZm+PyzMS9qenQf8uEYO7s3MTYV7mtv8hX1ov8nfCesdZA@mail.gmail.com>',NULL),('<05DE6916-605E-4893-867F-7F6ABEDCCFE4@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 14:41:57',0,'2014-03-31 14:41:57',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','I tinkered with the Nova create call and things are (sort of) working)?\n\nI changed the plugging to do this:\n\nport_id = port[\'port\'][\'id\']\n\ninstance = {\'uuid\': vm_uuid}\nnetwork = {\'bridge\': \'br-int\'}\n\nclass VeryDangerousHack(network_model.VIF):\n    def __init__(self, port_id, mac_addr, network):\n        super(VeryDangerousHack, self).__init__(\n            id=port_id, address=mac_addr, network=network,\n            type=network_model.VIF_TYPE_OVS,\n            details={\'ovs_hybrid_plug\': False, \'port_filter\': False},\n            active=True)\n\nvif = VeryDangerousHack(port_id, mac_addr, network)\n\n# For ML2 plugin\ndriver = vif_driver.LibvirtGenericVIFDriver({})\ndriver.plug(instance, vif)\n\nIt completed without errors, the interface is up, and I can ping over it. (Yay!) However, it still seems to show the hybrid plug and port filtering:\n\nopenstack at devstack-32:~/devstack$ neutron port-show private_p\n+-----------------------+---------------------------------------------------------------------------------+\n| Field                 | Value                                                                           |\n+-----------------------+---------------------------------------------------------------------------------+\n| admin_state_up        | True                                                                            |\n| allowed_address_pairs |                                                                                 |\n| binding:host_id       | devstack-32                                                                     |\n| binding:profile       | {}                                                                              |\n| binding:vif_details   | {\"port_filter\": true, \"ovs_hybrid_plug\": true}                                  |\n| binding:vif_type      | ovs                                                                             |\n| binding:vnic_type     | normal                                                                          |\n| device_id             | 999a76ef-1111-2689-1234-b12a3c4d2a00                                            |\n| device_owner          | compute:None                                                                    |\n| extra_dhcp_opts       |                                                                                 |\n| fixed_ips             | {\"subnet_id\": \"5255dd92-ebd6-43ea-aff8-46f97349eb99\", \"ip_address\": \"10.1.0.6\"} |\n| id                    | 267a9936-4bc2-4838-9c06-22d84309596f                                            |\n| mac_address           | 42:0c:c9:cb:4e:9f                                                               |\n| name                  | private_p                                                                       |\n| network_id            | df8305f2-9797-41ed-bd76-6f083575e0f7                                            |\n| security_groups       | 365a63ea-149c-4ff9-9aa2-8bcfe9dfb7e3                                            |\n| status                | ACTIVE                                                                          |\n| tenant_id             | 78fe6c3b72a64595aa7d3c6c25d58c51                                                |\n+-----------------------+????????????????????????????????????????+\n\nCan anyone enlightened me on what these settings imply?\n\n>From the review Irena mentioned:\n\"Neutron can include \'ovs_hybrid_plug\' and \'port_filter\' boolean keys in\nthe binding:vif_details port attribute. \'port_filter\' indicates whether\nor not neutron is handling port filtering for nova to determine if it needs\nto filter for that port. \'ovs_hybrid_plug\' can be set to True to indicate\nthat the neutron plugin still requires the bridge plugging strategy to attach\nfirewall rules.?\n\n\nI have security groups disabled for Neutron and am using Nova (with ICMP and SSH allowed). Does that mean the port_filter is ignored?\nIs the same true for the ovs_hybrid_plug, for the same reason?\n\nAny idea why my settings for details are being ignored in the call?\n\nI still have more checking, as the public_ip, although I can ping the local and remote Neutron routers (172.24.4.11 and 172.24.4.21), I cannot ping the far end VM that is running the same setup (outside of Nova, hooked into Neutron - though using the older versions and original scripts). May just be a setup issue.\n\nLooking better though!\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pcm_ (irc.freenode.com<http://irc.freenode.com>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Mar 31, 2014, at 9:56 AM, Paul Michali (pcm) <pcm at cisco.com<mailto:pcm at cisco.com>> wrote:\n\nHi Darragh,\n\nYes (I should included more background), I have a VM started in KVM, and it has I/Fs associated with scripts for I/F up and down:\n\nIFNAME_ETH0=$NAME\"__mgmt\"\nIFNAME_ETH1=$NAME\"__public\"\nIFNAME_ETH2=$NAME\"__private\"\n\nkvm -m 8192 -name $NAME \\\n-smp 4 \\\n-serial telnet:$TELNET_ACCESS,server,nowait \\\n-net nic,macaddr=$MACADDR_ETH0,model=e1000,vlan=0 \\\n-net tap,ifname=$IFNAME_ETH0,vlan=0,script=osn-ifup-mgmt,downscript=osn-ifdown-mgmt \\\n-net nic,macaddr=$MACADDR_ETH1,model=e1000,vlan=1 \\\n-net tap,ifname=$IFNAME_ETH1,vlan=1,script=osn-ifup-br-ex,downscript=osn-ifdown-br-ex \\\n-net nic,macaddr=$MACADDR_ETH2,model=e1000,vlan=2 \\\n-net tap,ifname=$IFNAME_ETH2,vlan=2,script=osn-ifup-br-int,downscript=osn-ifdown-br-int \\\n-drive file=$IMAGE \\\n-boot c \\\n-vga cirrus \\\n-vnc $VNC_ACCESS\n\nETH2, using osn-ifup-br-int, does this:\n\n#!/bin/bash\n\nsource config.ini\n\n/sbin/ifconfig $1 0.0.0.0 up\nif_mac=`ifconfig $1 | awk \'{ if ($4 == \"HWaddr\") print $5 }\'`\ninfo_str=`./plug_vif.py ${HOST} ${USER} ${PASSWORD} ${TENANT} ${UUID} ${if_mac} ${HOSTNAME} $1`\nif [ \"$info_str\" == \"\" ]; then\n   echo \"VIF plugging failed ($1)! Exiting ...\" >&2\n   exit 1\nfi\n\n# Write for file for later clean-up by osn-ifdown\necho \"$1 ${if_mac} ${UUID} $info_str\" >> .instance_info\n\nIFS=\' \' read -a info <<< \"$info_str\"\nswitch=${info[0]}\necho \"Plugging interface: $1 into switch: ${switch}\"\novs-vsctl add-port ${switch} $1\n\nNote: T original that used Nova for the plugging of VIF used this for the last line, instead of ovs-vsctl:\n\nbrctl addif ${switch} $1\n\n\nRegards,\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pcm_ (irc.freenode.com<http://irc.freenode.com/>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Mar 31, 2014, at 9:26 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com<mailto:dara2002-openstack at yahoo.com>> wrote:\n\nHi Paul,\n\ntbh I\'m not exactly sure what you are trying to do overall. But from your script it seems to me that you are trying to create an OVS port so a libvirt instance outside of Nova control can use it. And you don\'t need the linux bridge for security group iptables.\n\nAFAIK the tap must be created first using the ip command. Then when \'ovs-vsctl add-port\' is called with the same name as the tap device for the port name, the tap device will be enslaved properly in the OVS bridge.\n\nhttps://github.com/openstack/nova/blob/304df046eaaad6d64ee16898b1eaa76918e98878/nova/virt/libvirt/vif.py#L420-L423\n\nRegards, Darragh.\nOn Monday, 31 March 2014, 12:36, Paul Michali (pcm) <pcm at cisco.com<mailto:pcm at cisco.com>> wrote:\nHi Darragh,\n\nCan you elaborate on what the ?set interface? arguments do in OVS? Just trying to understand why it is not desired, when plugging into this interface (note I have a management interface on the br-int and it works fine?this one, which is also on br-int, but needs to tie to the existing ?private? network that devstack sets up, does not work.\n\nRegards,\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pcm_ (irc.freenode.com<http://irc.freenode.com/>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Mar 31, 2014, at 4:20 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com<mailto:dara2002-openstack at yahoo.com>> wrote:\n\nHi Paul,\n\nthe OVSInterfaceDriver creates interfaces with type internal so agents like DHCP/L3 etc can put IP addresses on them. But I don\'t think type internal will work for instances. You could try subclassing and overriding so it does not do this:\n\n https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150\n\nRegards,\nDarragh.\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/4f018fc2/attachment.html>\n\n','<8D1EB645-BAEA-450F-8550-5486301FCBD1@cisco.com>',NULL),('<05ECD61E184949829603467D6F787C81@PC201007301138>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-19 16:14:19',28800,'2012-11-19 08:14:19',NULL,'[openstack-dev] [Quantum]How to contribute LBaas driver?','Thanks for Sachin\'s kindly reply.\nJust one more question: \nI saw F5 published their driver code on github. And LBaas proposal also mentioned F5 bigip.\nBut there is no F5 driver in LBaas source on github.\nAnd I also did not found F5 name in company list of CLA at http://wiki.openstack.org/Contributors/Corporate\n----- Original Message ----- \nFrom: \"Sachin Thakkar\" <sthakkar at vmware.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, November 19, 2012 3:47 PM\nSubject: Re: [openstack-dev] [Quantum]How to contribute LBaas driver?\n\n\n> Hi Hu,\n> \n> Yes, that is the correct process. We initially were having separate LBaaS discussions during/after the summit but it has now been separated into distinct work items. If you\'re interested in helping, ping us when we discuss LBaaS during the quantum meeting\n> \n> Cheers,\n> Sachin\n> \n> ----- Original Message -----\n> From: \"HuYanrui\" <huyr at arraynetworks.com.cn>\n> To: openstack-dev at lists.openstack.org\n> Sent: Sunday, November 18, 2012 11:28:26 PM\n> Subject: [openstack-dev] [Quantum]How to contribute LBaas driver?\n> \n> \n> \n> Guys, \n> Just want to make sure how to contribue LBaas driver (commercial)? \n> Is this process same with contribute plugin in quantum like this page? - \n> http://wiki.openstack.org/QuantumDevelopment \n> \n> \n> \n> Hu Yanrui \n> \n> Array Networks Inc. \n> \n> Tel: 86 010-84446688 ext 259 \n> \n> E-mail : huyr at arraynetworks.com.cn \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n',NULL,NULL),('<05F28257-70CA-4B61-A995-464E05E45B65@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-11 10:04:05',-18000,'2015-01-11 15:04:05',NULL,'[OpenStack-Infra] Error while stackforge project setup request','A new version of python-daemon was released that doesn?t properly declare its dependency on docutils. I?ve reported the problem to the author, but if you want to work around the problem you could add docutils to the requirements list for the virtualenv being used in that build step.\n\n> On Jan 10, 2015, at 3:03 PM, Mohammad Hanif <mhanif at brocade.com> wrote:\n> \n> Hi all,\n> \n> Not sure if this is the right forum to ask this question.  I have submitted a spec (https://review.openstack.org/#/c/145160/ <https://review.openstack.org/#/c/145160/>) to request the creation of the stackforge project.  The Jenkins review is failing on it and am not sure what might be going wrong here.  Any help on resolving/guiding will be greatly appreciated.\n> \n> To look at the error, you can either follow the link above or use the following link.\n> \n> http://logs.openstack.org/60/145160/3/check/gate-project-config-layout/50ca1c9/console.html <http://logs.openstack.org/60/145160/3/check/gate-project-config-layout/50ca1c9/console.html>\n> \n> Thanks,\n> --Hanif. \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150111/d67816ed/attachment.html>\n\n','<B3C30D2C-2FCC-4A2A-BEB1-74589B6FA163@brocade.com>',NULL),('<05FD62ED-2980-423B-92FB-6132ABEA3D80@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-24 20:31:50',7200,'2013-07-24 18:31:50',NULL,'[Openstack-operators] Shared storage HA question',':-)\nActually I had to remove all my instances running on it (especially the windows ones), yah unfortunately my network backbone wasn\'t fast enough to support the load induced by GFS - especially the numerous operations performed by the self-healing agents :(\n\nI\'m currently considering MooseFS, it has the advantage to have a pretty long list of companies using it in production\n\ntake care\n\n\nLe 24 juil. 2013 ? 16:40, Jacob Godin <jacobgodin at gmail.com> a ?crit :\n\n> A few things I found were key for I/O performance:\n> Make sure your network can sustain the traffic. We are using a 10G backbone with 2 bonded interfaces per node.\n> Use high speed drives. SATA will not cut it.\n> Look into tuning settings. Razique, thanks for sending these along to me a little while back. A couple that I found were useful:\n> KVM cache=writeback (a little risky, but WAY faster)\n> Gluster write-behind-window-size (set to 4MB in our setup)\n> Gluster cache-size (ideal values in our setup were 96MB-128MB)\n> Hope that helps!\n> \n> \n> \n> On Wed, Jul 24, 2013 at 11:32 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n> I had much performance issues myself with Windows instances, and I/O demanding instances. Make sure it fits your env. first before deploying it in production\n> \n> Regards,\n> Razique\n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 24 juil. 2013 ? 16:25, Jacob Godin <jacobgodin at gmail.com> a ?crit :\n> \n>> Hi Denis,\n>> \n>> I would take a look into GlusterFS with a distributed, replicated volume. We have been using it for several months now, and it has been stable. Nova will need to have the volume mounted to its instances directory (default /var/lib/nova/instances), and Cinder has direct support for Gluster as of Grizzly I believe.\n>> \n>> \n>> \n>> On Wed, Jul 24, 2013 at 11:11 AM, Denis Loshakov <dloshakov at gmail.com> wrote:\n>> Hi all,\n>> \n>> I have issue with creating shared storage for Openstack. Main idea is to create 100% redundant shared storage from two servers (kind of network RAID from two servers).\n>> I have two identical servers with many disks inside. What solution can any one provide for such schema? I need shared storage for running VMs (so live migration can work) and also for cinder-volumes.\n>> \n>> One solution is to install Linux on both servers and use DRBD + OCFS2, any comments on this?\n>> Also I heard about Quadstor software and it can create network RAID and present it via iSCSI.\n>> \n>> Thanks.\n>> \n>> P.S. Glance uses swift and is setuped on another servers\n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130724/5b041b06/attachment.html>\n\n','<CA+WiSK4x9cu-7oGwmV3bDYBh7cyKU4t7KhvPTALgsMRvMdHvGw@mail.gmail.com>',NULL),('<0603747F-965F-4C72-9A02-7003309F8267@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 12:48:02',-14400,'2013-08-27 16:48:02',NULL,'[openstack-dev] [Neutron] Attribute validation questions (from\n	review comments on 43559)','Hi!\n\nFor VPNaaS there are some attributes, like the Dead Peer Detection interval and timeout, that have some dependencies (timeout should be > interval).  Another example, is the minimum value for the MTU attribute, which would differ, depending upon whether IPv4 or IPv6 is being used.\n\nI see that api/v2/attributes.py allows one to check an individual attribute. I have these questions:\n\nIs there a way to validate an attribute that has a dependency?\nIf so, is that using some other mechanism than the validators in attributes.py?\nFor the DPD example, those two attributes are part of a dict. Is there a way to validate the dict, in addition to the individual attributes (can I have a validator on the dict)?\nWhat about validating un-related attributes, like MTU? I\'m not sure yet, how I\'ll know whether IPv4 or IPv6 is selected (I assume by checking the peer_cidr attribute), as the user could specify MTU first.\nIf we don\'t test the MTU based on IPv4/6, then what do I use for a lower limit - the IPv4 limit of 68?\n\nThanks!\n\nPCM (Paul Michali)\n\nMAIL pcm at cisco.com\nIRC   pcm_  (irc.freenode.net)\nTW   @pmichali\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/197d8d35/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/197d8d35/attachment.pgp>\n\n',NULL,NULL),('<06133B10-F290-4B92-8363-B7E44311F897@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 13:52:00',3600,'2013-06-17 12:52:00',NULL,'[openstack-dev] [keystone] Inherited domain roles: Options for\n	Havana and beyond','Hi\n\nI have amended the etherpad to summarize the two proposed paths:\n\na) Full \"role-assignment as a first class entity\" for Havana\nb) Stepping stone approach, for Havana and \"I\"\n\nSo you can see what is involved in b), I have amended the two in-flight bp identity proposals to match what this would look like:\n\nhttps://review.openstack.org/#/c/29781/14\nhttps://review.openstack.org/#/c/32394/7\n\n[Ok, technically I should have done this is 3 bp, one for changing the current apis, one for the new GET /role-assignment api (that supports groups but not inherited roles) and then an updated GET /role-assigment api that now supports the inherited roles as well, and would be dependant on the other two bps.....but in the interests of time I kept it simple.] \n\nWe need to make a call on whether we take a) or b) at tomorrows keystone IRC meeting, if not before.  We are running out of time. \n\nHenry\n\n\n',NULL,NULL),('<06166DBA-1BAB-44D6-A751-4F8C6F8EEDB9@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-14 14:09:09',-28800,'2013-02-14 22:09:09',NULL,'[openstack-dev] [Ceilometer] Supporting Swift Client < 1.7.5','\nOn Feb 14, 2013, at 1:44 PM, Sandy Walsh <sandy.walsh at RACKSPACE.COM> wrote:\n\n> Hey!\n> \n> I\'m working on getting CM HACKING Compliant and ran into this little gem:\n> https://github.com/openstack/ceilometer/blob/master/ceilometer/objectstore/swift_middleware.py#L34\n> \n> There\'s no easy way to have the correct order of imports and these tests for specific Swift client versions. \n> \n> I could disable Hacking checking for this file, but that feels wrong. It could be easier to just not support Swift clients < 1.7.5 \n> \n> So, which option is best?\n> 1. Drop support for Swift < 1.7.5 in CM?\n\nSince CM hasn\'t been released as part of OpenStack (or ever?) yet, this seems like a viable alternative, IMO. Of course, this limits the existing clusters you can deploy CM in. Although we recommend that all deployers upgrade to each Swift release, I know it doesn\'t always happen.\n\nFWIW, Swift 1.7.5 was released Tue Nov 13 (ie post-folsom). We have had once release since then and will have another before grizzly is final.\n\n> 2. Solicit ideas for crafting an elegant way to make that code Hacking Compliant?\n> 3. Disable Hacking checks for this file?\n\nI\'m not familiar with what a hacking check does, but it seems to depend on the answer to 1.\n\n> \n> Thoughts?\n> -S\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388867D91A2@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0617F1C1-3ED8-4131-A6B1-76FEBF88CCA5@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 17:27:12',-14400,'2014-08-27 21:27:12',NULL,'[openstack-dev] [all] gate debugging','\nOn Aug 27, 2014, at 2:54 PM, Sean Dague <sean at dague.net> wrote:\n\n> Note: thread intentionally broken, this is really a different topic.\n> \n> On 08/27/2014 02:30 PM, Doug Hellmann wrote:>\n>> On Aug 27, 2014, at 1:30 PM, Chris Dent <chdent at redhat.com> wrote:\n>> \n>>> On Wed, 27 Aug 2014, Doug Hellmann wrote:\n>>> \n>>>> I have found it immensely helpful, for example, to have a written set\n>>>> of the steps involved in creating a new library, from importing the\n>>>> git repo all the way through to making it available to other projects.\n>>>> Without those instructions, it would have been much harder to split up\n>>>> the work. The team would have had to train each other by word of\n>>>> mouth, and we would have had constant issues with inconsistent\n>>>> approaches triggering different failures. The time we spent building\n>>>> and verifying the instructions has paid off to the extent that we even\n>>>> had one developer not on the core team handle a graduation for us.\n>>> \n>>> +many more for the relatively simple act of just writing stuff down\n>> \n>> \"Write it down.? is my theme for Kilo.\n> \n> I definitely get the sentiment. \"Write it down\" is also hard when you\n> are talking about things that do change around quite a bit. OpenStack as\n> a whole sees 250 - 500 changes a week, so the interaction pattern moves\n> around enough that it\'s really easy to have *very* stale information\n> written down. Stale information is even more dangerous than no\n> information some times, as it takes people down very wrong paths.\n> \n> I think we break down on communication when we get into a conversation\n> of \"I want to learn gate debugging\" because I don\'t quite know what that\n> means, or where the starting point of understanding is. So those\n> intentions are well meaning, but tend to stall. The reality was there\n> was no road map for those of us that dive in, it\'s just understanding\n> how OpenStack holds together as a whole and where some of the high risk\n> parts are. And a lot of that comes with days staring at code and logs\n> until patterns emerge.\n> \n> Maybe if we can get smaller more targeted questions, we can help folks\n> better? I\'m personally a big fan of answering the targeted questions\n> because then I also know that the time spent exposing that information\n> was directly useful.\n> \n> I\'m more than happy to mentor folks. But I just end up finding the \"I\n> want to learn\" at the generic level something that\'s hard to grasp onto\n> or figure out how we turn it into action. I\'d love to hear more ideas\n> from folks about ways we might do that better.\n\nYou and a few others have developed an expertise in this important skill. I am so far away from that level of expertise that I don?t know the questions to ask. More often than not I start with the console log, find something that looks significant, spend an hour or so tracking it down, and then have someone tell me that it is a red herring and the issue is really some other thing that they figured out very quickly by looking at a file I never got to.\n\nI guess what I?m looking for is some help with the patterns. What made you think to look in one log file versus another? Some of these jobs save a zillion little files, which ones are actually useful? What tools are you using to correlate log entries across all of those files? Are you doing it by hand? Is logstash useful for that, or is that more useful for finding multiple occurrences of the same issue?\n\nI realize there?s not a way to write a how-to that will live forever. Maybe one way to deal with that is to write up the research done on bugs soon after they are solved, and publish that to the mailing list. Even the retrospective view is useful because we can all learn from it without having to live through it. The mailing list is a fairly ephemeral medium, and something very old in the archives is understood to have a good chance of being out of date so we don?t have to keep adding disclaimers.\n\nDoug\n\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<53FE297F.3000007@dague.net>',NULL),('<062c94f13b560aa2f70102fc046e5070@qmail.com.bd>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-18 12:43:21',21600,'2014-09-18 06:43:21',NULL,'[Openstack-operators] Glance Image Upload error',' \n\nHi, \n\nI am facing glance image upload problem on open stack\ninstallation in OpenSuse 13.1. When i run \n\ncontroller:/tmp/images #\nglance image-create --name \"cirros-0.3.2-x86_64\" --disk-format qcow2 \n>\n--container-format bare --is-public True --progress <\ncirros-0.3.2-x86_64-disk.img\n[==> ] 8% \n\nthis command this image not\nupload after 8% . \n\nPlease help me . How can i solve this problem\n\n\nThanks All \n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140918/66ac9319/attachment.html>\n\n',NULL,NULL),('<062F530F-1199-4767-B5BF-71708DC1A4DA@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-21 21:29:45',-21600,'2014-12-22 03:29:45',NULL,'[openstack-dev] [nova] Evacuate instance which in server group\n	with affinity policy','This is another great example of a use case in which these blueprints [1, 2] would be handy.  They didn?t make the clip line for Kilo, but we?ll try again for L.  I personally don?t think the scheduler should have ?special case? rules about when/when not to apply affinity policies, as that could be confusing for administrators.  It would be simple to just remove it from the group, thereby allowing the administrator to rebuild the VM anywhere s/he wants? and then re-add the VM to the group once the environment is operational once again.\n\n[1] https://review.openstack.org/#/c/136487/\n[2] https://review.openstack.org/#/c/139272/\n\n- Joe\n\nOn Dec 21, 2014, at 8:36 PM, Lingxian Kong <anlin.kong at gmail.com> wrote:\n\n> 2014-12-22 9:21 GMT+08:00 Alex Xu <soulxu at gmail.com>:\n>> \n>> \n>> 2014-12-22 9:01 GMT+08:00 Lingxian Kong <anlin.kong at gmail.com>:\n>>> \n> \n>>> \n>>> but what if the compute node is back to normal? There will be\n>>> instances in the same server group with affinity policy, but located\n>>> in different hosts.\n>>> \n>> \n>> If operator decide to evacuate the instance from the failed host, we should\n>> fence the failed host first.\n> \n> Yes, actually. I mean the recommandation or prerequisite should be\n> emphasized somewhere, e.g. the Operation Guide, otherwise it\'ll make\n> things more confused. But the issue you are working around is indeed a\n> problem we should solve.\n> \n> -- \n> Regards!\n> -----------------------------------\n> Lingxian Kong\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CALjNAZ1h8CbH8eBmbiYq-74=JOLFSMAptvZC_B4ah5BFQaqLaA@mail.gmail.com>',NULL),('<06367CB7-4601-49E0-9D8D-8D459C8F7B1C@it.uu.se>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-12 21:50:26',3600,'2014-03-12 20:50:26',NULL,'[Openstack-operators] Connection/authentication problem using\n	Swift command-line-tool (time difference).','Hi, \n\nOk My setup is working no error no connection problem, everything work OK. But still the time stamp is one hour behind ... \n\nThe problem was solved once I put \n\ndevices = /srv/node\n\nmount_check = false\n\n\n\nin the .conf files.\n\n[root at mist images]#clock\nWed Mar 12 21:36:36 2014  -0.594092 seconds\n\n[root at mist images]# swift --debug stat\nREQ: curl -i -X POST http://mist.xxx.xx:5000/v2.0/tokens -H \"Content-Type: application/json\" -H \"User-Agent: python-keystoneclient\"\nDEBUG:keystoneclient.httpclient:REQ: curl -i -X POST http://mist.xxx.xx:5000/v2.0/tokens -H \"Content-Type: application/json\" -H \"User-Agent: python-keystoneclient\"\nREQ BODY: {\"auth\": {\"tenantName\": \"Local-Experiments\", \"passwordCredentials\": {\"username\": \"myone\", \"password\": \"myone\"}}}\n\nDEBUG:keystoneclient.httpclient:REQ BODY: {\"auth\": {\"tenantName\": \"Local-Experiments\", \"passwordCredentials\": {\"username\": \"myone\", \"password\": \"myone\"}}}\n\nINFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\nDEBUG:urllib3.connectionpool:\"POST /v2.0/tokens HTTP/1.1\" 200 6649\nRESP: [200] {\'date\': \'Wed, 12 Mar 2014 20:39:34 GMT\', \'content-type\': \'application/json\', \'content-length\': \'6649\', \'vary\': \'X-Auth-Token\'}\nRESP BODY: {\"access\": {\"token\": {\"issued_at\": \"2014-03-12T20:39:34.715083\", \"expires\": \"2014-03-13T20:39:34Z\", \"id\": \"--- XXXX ---\", \"tenant\": {\"description\": null, \"enabled\": true, \"id\": \"32accaa0a629423395f7003902795ee2\", \"name\": \"Local-Experiments\"}}, \"serviceCatalog\": [{\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"196f3b8321c644fa8a60743813d02567\", \"publicURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"compute\", \"name\": \"nova\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"1a60ea81e99d47fe897656a13f605f1b\", \"publicURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volumev2\", \"name\": \"cinderv2\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:9292\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:9292\", \"id\": \"1a1c7b415d184462ad5d1ca51859d5be\", \"publicURL\": \"http://mist.xxx.xx:9292\"}], \"endpoints_links\": [], \"type\": \"image\", \"name\": \"glance\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"id\": \"0cea17ee4a654a5b9e5b331321f0a2da\", \"publicURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volume\", \"name\": \"cinder\"}, {\"endpoints\": [{\"adminURL\": \"http://mist-os.uppmax.uu.se:8888\", \"region\": \"regionOne\", \"internalURL\": \"http://mist-os.uppmax.uu.se:8888/v1/AUTH_32accaa0a629423395f7003902795ee2\", \"id\": \"081c5e1a147e4a708130dd2993958656\", \"publicURL\": \"http://mist-os.uppmax.uu.se:8888/v1/AUTH_32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"object-store\", \"name\": \"swift\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:35357/v2.0\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:5000/v2.0\", \"id\": \"3cb9c393a893499dbcea7bf85db96375\", \"publicURL\": \"http://mist.xxx.xx:5000/v2.0\"}], \"endpoints_links\": [], \"type\": \"identity\", \"name\": \"keystone\"}], \"user\": {\"username\": \"myone\", \"roles_links\": [], \"id\": \"e8be74e1714e41d0847fec51aa466a50\", \"roles\": [{\"name\": \"_member_\"}, {\"name\": \"admin\"}], \"name\": \"myone\"}, \"metadata\": {\"is_admin\": 0, \"roles\": [\"9fe2ff9ee4384b1894a90878d3e92bab\", \"5ccc6a705ca74c81812e77b2694ea12c\"]}}}\n\nDEBUG:keystoneclient.httpclient:RESP: [200] {\'date\': \'Wed, 12 Mar 2014 20:39:34 GMT\', \'content-type\': \'application/json\', \'content-length\': \'6649\', \'vary\': \'X-Auth-Token\'}\nRESP BODY: {\"access\": {\"token\": {\"issued_at\": \"2014-03-12T20:39:34.715083\", \"expires\": \"2014-03-13T20:39:34Z\", \"id\": \" --- XXXX --- \", \"tenant\": {\"description\": null, \"enabled\": true, \"id\": \"32accaa0a629423395f7003902795ee2\", \"name\": \"Local-Experiments\"}}, \"serviceCatalog\": [{\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"196f3b8321c644fa8a60743813d02567\", \"publicURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"compute\", \"name\": \"nova\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"1a60ea81e99d47fe897656a13f605f1b\", \"publicURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volumev2\", \"name\": \"cinderv2\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:9292\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:9292\", \"id\": \"1a1c7b415d184462ad5d1ca51859d5be\", \"publicURL\": \"http://mist.xxx.xx:9292\"}], \"endpoints_links\": [], \"type\": \"image\", \"name\": \"glance\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"id\": \"0cea17ee4a654a5b9e5b331321f0a2da\", \"publicURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volume\", \"name\": \"cinder\"}, {\"endpoints\": [{\"adminURL\": \"http://mist-os.uppmax.uu.se:8888\", \"region\": \"regionOne\", \"internalURL\": \"http://mist-os.uppmax.uu.se:8888/v1/AUTH_32accaa0a629423395f7003902795ee2\", \"id\": \"081c5e1a147e4a708130dd2993958656\", \"publicURL\": \"http://mist-os.uppmax.uu.se:8888/v1/AUTH_32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"object-store\", \"name\": \"swift\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:35357/v2.0\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:5000/v2.0\", \"id\": \"3cb9c393a893499dbcea7bf85db96375\", \"publicURL\": \"http://mist.xxx.xx:5000/v2.0\"}], \"endpoints_links\": [], \"type\": \"identity\", \"name\": \"keystone\"}], \"user\": {\"username\": \"myone\", \"roles_links\": [], \"id\": \"e8be74e1714e41d0847fec51aa466a50\", \"roles\": [{\"name\": \"_member_\"}, {\"name\": \"admin\"}], \"name\": \"myone\"}, \"metadata\": {\"is_admin\": 0, \"roles\": [\"9fe2ff9ee4384b1894a90878d3e92bab\", \"5ccc6a705ca74c81812e77b2694ea12c\"]}}}\n\nDEBUG:iso8601.iso8601:Parsed 2014-03-13T20:39:34Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'20\', \'tz_hour\': None, \'month\': u\'03\', \'timezone\': u\'Z\', \'second\': u\'34\', \'tz_minute\': None, \'year\': u\'2014\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'39\'} with default timezone <iso8601.iso8601.Utc object at 0x26b3dd0>\nDEBUG:iso8601.iso8601:Got u\'2014\' for \'year\' with default None\nDEBUG:iso8601.iso8601:Got u\'03\' for \'month\' with default None\nDEBUG:iso8601.iso8601:Got u\'13\' for \'day\' with default None\nDEBUG:iso8601.iso8601:Got u\'20\' for \'hour\' with default None\nDEBUG:iso8601.iso8601:Got u\'39\' for \'minute\' with default None\nDEBUG:iso8601.iso8601:Got u\'34\' for \'second\' with default None\nINFO:urllib3.connectionpool:Starting new HTTP connection (1): mist-os.uppmax.uu.se\nDEBUG:urllib3.connectionpool:\"HEAD /v1/AUTH_32accaa0a629423395f7003902795ee2 HTTP/1.1\" 204 0\nDEBUG:swiftclient:REQ: curl -i http://mist-os.uppmax.uu.se:8888/v1/AUTH_32accaa0a629423395f7003902795ee2 -I -H \"X-Auth-Token: --- XXXX ---\"\nDEBUG:swiftclient:RESP STATUS: 204 No Content\nDEBUG:swiftclient:RESP HEADERS: [(\'content-length\', \'0\'), (\'accept-ranges\', \'bytes\'), (\'x-timestamp\', \'1394656673.71816\'), (\'date\', \'Wed, 12 Mar 2014 20:39:34 GMT\'), (\'x-account-bytes-used\', \'0\'), (\'x-account-container-count\', \'1\'), (\'content-type\', \'text/plain; charset=utf-8\'), (\'x-account-object-count\', \'0\')]\n       Account: AUTH_32accaa0a629423395f7003902795ee2\n    Containers: 1\n       Objects: 0\n         Bytes: 0\n Accept-Ranges: bytes\n   X-Timestamp: 1394656673.71816\n  Content-Type: text/plain; charset=utf-8\n\n\nIn red you can still notice that the time is different. \n\n/Salman. \n\n\nSalman Toor, PhD\nsalman.toor at it.uu.se\n\n\n\nOn Mar 12, 2014, at 12:07 PM, Salman Toor wrote:\n\n> Hi, \n> \n> I am trying to deploy SWIFT with the following versions of rpm: \n> \n> openstack-swift-1.10.0-2.el6.noarch\n> openstack-swift-container-1.10.0-2.el6.noarch\n> openstack-swift-plugin-swift3-1.7-1.el6.noarch\n> openstack-swift-proxy-1.10.0-2.el6.noarch\n> openstack-swift-object-1.10.0-2.el6.noarch\n> openstack-swift-account-1.10.0-2.el6.noarch\n> \n> Deployment seems to be working fine but the test commends are not. \n> \n> Following is the schema \n> \n> 1- proxy-server + storage ->  mist-os.xxx.xx\n> 2 - storage ->  mist1.xxx.xx\n> 3 - keystone -> mist.xxx.xx\n> \n> All the services are running and no service level error in the logs. \n> \n> using an ordinary account (myone)\n> \n> # swift stat\n> [Errno 111] Connection refused\n> \n> [root at mist openstack-user]# clock\n> Wed Mar 12 11:50:36 2014  -0.609708 seconds\n> # swift --debug stat\n> REQ: curl -i -X POST http://mist.xxx.xx:5000/v2.0/tokens -H \"Content-Type: application/json\" -H \"User-Agent: python-keystoneclient\"\n> DEBUG:keystoneclient.httpclient:REQ: curl -i -X POST http://mist.xxx.xx:5000/v2.0/tokens -H \"Content-Type: application/json\" -H \"User-Agent: python-keystoneclient\"\n> REQ BODY: {\"auth\": {\"tenantName\": \"Local-Experiments\", \"passwordCredentials\": {\"username\": \"myone\", \"password\": \"myone\"}}}\n> \n> DEBUG:keystoneclient.httpclient:REQ BODY: {\"auth\": {\"tenantName\": \"Local-Experiments\", \"passwordCredentials\": {\"username\": \"myone\", \"password\": \"myone\"}}}\n> \n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> DEBUG:urllib3.connectionpool:\"POST /v2.0/tokens HTTP/1.1\" 200 6628\n> RESP: [200] {\'date\': \'Wed, 12 Mar 2014 10:51:16 GMT\', \'content-type\': \'application/json\', \'content-length\': \'6628\', \'vary\': \'X-Auth-Token\'}\n> \n> DEBUG:keystoneclient.httpclient:REQ BODY: {\"auth\": {\"tenantName\": \"Local-Experiments\", \"passwordCredentials\": {\"username\": \"myone\", \"password\": \"myone\"}}}\n> \n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> DEBUG:urllib3.connectionpool:\"POST /v2.0/tokens HTTP/1.1\" 200 6628\n> RESP: [200] {\'date\': \'Wed, 12 Mar 2014 10:51:16 GMT\', \'content-type\': \'application/json\', \'content-length\': \'6628\', \'vary\': \'X-Auth-Token\'}\n> RESP BODY: {\"access\": {\"token\": {\"issued_at\": \"2014-03-12T10:51:16.248840\", \"expires\": \"2014-03-13T10:51:16Z\", \"id\": \"--- XXXXX ----\", \"tenant\": {\"description\": null, \"enabled\": true, \"id\": \"32accaa0a629423395f7003902795ee2\", \"name\": \"Local-Experiments\"}}, \"serviceCatalog\": [{\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"196f3b8321c644fa8a60743813d02567\", \"publicURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"compute\", \"name\": \"nova\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"1a60ea81e99d47fe897656a13f605f1b\", \"publicURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volumev2\", \"name\": \"cinderv2\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:9292\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:9292\", \"id\": \"1a1c7b415d184462ad5d1ca51859d5be\", \"publicURL\": \"http://mist.xxx.xx:9292\"}], \"endpoints_links\": [], \"type\": \"image\", \"name\": \"glance\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"id\": \"0cea17ee4a654a5b9e5b331321f0a2da\", \"publicURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volume\", \"name\": \"cinder\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8080\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8080/v1/AUTH_32accaa0a629423395f7003902795ee2\", \"id\": \"059911754bab471c92351c0e1844c7a6\", \"publicURL\": \"http://mist.xxx.xx:8080/v1/AUTH_32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"object-store\", \"name\": \"swift\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:35357/v2.0\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:5000/v2.0\", \"id\": \"3cb9c393a893499dbcea7bf85db96375\", \"publicURL\": \"http://mist.xxx.xx:5000/v2.0\"}], \"endpoints_links\": [], \"type\": \"identity\", \"name\": \"keystone\"}], \"user\": {\"username\": \"myone\", \"roles_links\": [], \"id\": \"e8be74e1714e41d0847fec51aa466a50\", \"roles\": [{\"name\": \"_member_\"}, {\"name\": \"admin\"}], \"name\": \"myone\"}, \"metadata\": {\"is_admin\": 0, \"roles\": [\"9fe2ff9ee4384b1894a90878d3e92bab\", \"5ccc6a705ca74c81812e77b2694ea12c\"]}}}\n> \n> DEBUG:keystoneclient.httpclient:RESP: [200] {\'date\': \'Wed, 12 Mar 2014 10:51:16 GMT\', \'content-type\': \'application/json\', \'content-length\': \'6628\', \'vary\': \'X-Auth-Token\'}\n> RESP BODY: {\"access\": {\"token\": {\"issued_at\": \"2014-03-12T10:51:16.248840\", \"expires\": \"2014-03-13T10:51:16Z\", \"id\": \"---- XXXX ----\", \"tenant\": {\"description\": null, \"enabled\": true, \"id\": \"32accaa0a629423395f7003902795ee2\", \"name\": \"Local-Experiments\"}}, \"serviceCatalog\": [{\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"196f3b8321c644fa8a60743813d02567\", \"publicURL\": \"http://mist.xxx.xx:8774/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"compute\", \"name\": \"nova\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\", \"id\": \"1a60ea81e99d47fe897656a13f605f1b\", \"publicURL\": \"http://mist.xxx.xx:8776/v2/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volumev2\", \"name\": \"cinderv2\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:9292\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:9292\", \"id\": \"1a1c7b415d184462ad5d1ca51859d5be\", \"publicURL\": \"http://mist.xxx.xx:9292\"}], \"endpoints_links\": [], \"type\": \"image\", \"name\": \"glance\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\", \"id\": \"0cea17ee4a654a5b9e5b331321f0a2da\", \"publicURL\": \"http://mist.xxx.xx:8776/v1/32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"volume\", \"name\": \"cinder\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:8080\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:8080/v1/AUTH_32accaa0a629423395f7003902795ee2\", \"id\": \"059911754bab471c92351c0e1844c7a6\", \"publicURL\": \"http://mist.xxx.xx:8080/v1/AUTH_32accaa0a629423395f7003902795ee2\"}], \"endpoints_links\": [], \"type\": \"object-store\", \"name\": \"swift\"}, {\"endpoints\": [{\"adminURL\": \"http://mist.xxx.xx:35357/v2.0\", \"region\": \"regionOne\", \"internalURL\": \"http://mist.xxx.xx:5000/v2.0\", \"id\": \"3cb9c393a893499dbcea7bf85db96375\", \"publicURL\": \"http://mist.xxx.xx:5000/v2.0\"}], \"endpoints_links\": [], \"type\": \"identity\", \"name\": \"keystone\"}], \"user\": {\"username\": \"myone\", \"roles_links\": [], \"id\": \"e8be74e1714e41d0847fec51aa466a50\", \"roles\": [{\"name\": \"_member_\"}, {\"name\": \"admin\"}], \"name\": \"myone\"}, \"metadata\": {\"is_admin\": 0, \"roles\": [\"9fe2ff9ee4384b1894a90878d3e92bab\", \"5ccc6a705ca74c81812e77b2694ea12c\"]}}}\n> \n> DEBUG:iso8601.iso8601:Parsed 2014-03-13T10:51:16Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'10\', \'tz_hour\': None, \'month\': u\'03\', \'timezone\': u\'Z\', \'second\': u\'16\', \'tz_minute\': None, \'year\': u\'2014\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'51\'} with default timezone <iso8601.iso8601.Utc object at 0x1baadd0>\n> DEBUG:iso8601.iso8601:Got u\'2014\' for \'year\' with default None\n> DEBUG:iso8601.iso8601:Got u\'03\' for \'month\' with default None\n> DEBUG:iso8601.iso8601:Got u\'13\' for \'day\' with default None\n> DEBUG:iso8601.iso8601:Got u\'10\' for \'hour\' with default None\n> DEBUG:iso8601.iso8601:Got u\'51\' for \'minute\' with default None\n> DEBUG:iso8601.iso8601:Got u\'16\' for \'second\' with default None\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> INFO:urllib3.connectionpool:Starting new HTTP connection (1): mist.xxx.xx\n> ERROR:swiftclient:[Errno 111] Connection refused\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.6/site-packages/swiftclient/client.py\", line 1192, in _retry\n>     rv = func(self.url, self.token, *args, **kwargs)\n>   File \"/usr/lib/python2.6/site-packages/swiftclient/client.py\", line 460, in head_account\n>     conn.request(method, parsed.path, \'\', headers)\n>   File \"/usr/lib/python2.6/site-packages/swiftclient/client.py\", line 187, in request\n>     files=files, **self.requests_args)\n>   File \"/usr/lib/python2.6/site-packages/swiftclient/client.py\", line 176, in _request\n>     return requests.request(*arg, **kwarg)\n>   File \"/usr/lib/python2.6/site-packages/requests/api.py\", line 44, in request\n>     return session.request(method=method, url=url, **kwargs)\n>   File \"/usr/lib/python2.6/site-packages/requests/sessions.py\", line 279, in request\n>     resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)\n>   File \"/usr/lib/python2.6/site-packages/requests/sessions.py\", line 374, in send\n>     r = adapter.send(request, **kwargs)\n>   File \"/usr/lib/python2.6/site-packages/requests/adapters.py\", line 206, in send\n>     raise ConnectionError(sockerr)\n> ConnectionError: [Errno 111] Connection refused\n> [Errno 111] Connection refused\n> \n> I think one of the problem is the time difference. There is of one hour difference.  All the server are running ntpd and the clocks are synchronize.. Have no clue from where this new time is coming.  All the other services are fine and clients (glance, nova, cinder) returning correct timings ... \n> \n> For example \n> \n> ---------------------------------------\n> # glance  --debug image-list \n> \n> HTTP/1.1 200 OK\n> date: Wed, 12 Mar 2014 11:05:05 GMT\n> content-length: 927\n> content-type: application/json; charset=UTF-8\n> x-openstack-request-id: req-29190e4f-23fa-45d2-a1e0-711687ebcae3\n> \n> {\"images\": [{\"status\": \"active\", \"name\": \"CirrOS-NEW 0.3.1\", \"deleted\": false, \"container_format\": \"bare\", \"created_at\": \"2014-03-05T11:47:33\", \"disk_format\": \"qcow2\", \"updated_at\": \"2014-03-05T11:47:34\", \"min_disk\": 0, \"protected\": false, \"id\": \"93b5efe1-ac39-4070-bd47-557bd554c228\", \"min_ram\": 0, \"checksum\": \"d972013792949d0d3ba628fbe8685bce\", \"owner\": \"e8fe1cc1567d4cb2bf50a24b0174c1c4\", \"is_public\": true, \"deleted_at\": null, \"properties\": {}, \"size\": 13147648}, {\"status\": \"active\", \"name\": \"Ubuntu 12.04 LTS\", \"deleted\": false, \"container_format\": \"bare\", \"created_at\": \"2014-03-06T11:23:24\", \"disk_format\": \"qcow2\", \"updated_at\": \"2014-03-11T14:26:05\", \"min_disk\": 0, \"protected\": false, \"id\": \"f060e305-163f-4e1c-b7ea-e79c4d876890\", \"min_ram\": 0, \"checksum\": \"73c5b7fa57ba32092e80e172b384ff6c\", \"owner\": \"f0bc8ee49a7f4eccb0f5945f409863b8\", \"is_public\": true, \"deleted_at\": null, \"properties\": {}, \"size\": 258015744}]}\n> ---------------------------------------\n> \n> \n> Can anybody please give me a hint that what causes this problem?\n> \n> Thanks in advance. \n> \n> Regards..\n> Salman. \n> \n> \n> \n> \n> \n> Salman Toor, PhD\n> salman.toor at it.uu.se\n> \n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140312/e4da6089/attachment.html>\n\n','<E70C19EB-85B1-44D5-93C3-82B5ABFB572B@it.uu.se>',NULL),('<063d6ffdd70f439afebc5e65ee660bb4@students.iiit.ac.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-13 13:39:07',19800,'2014-11-13 08:09:07',NULL,'[Openstack] Fwd: Ironic configuration for Baremetal','thank you peeyush,\nbut as that guide says it need nova,horizon,neutron,keystone and other \nopenstack components as pre-requesite so we thought of doing it with \ndevstack.\n\nCan you give some more details on how and what exactly to follow.\nAlso we are less in resources.we had a compute node for openstack \ninstallation and only one more machine which we is for physical \ninstallation.\n\n\nOn 2014-11-13 13:27, Peeyush Gupta wrote:\n> Hi,\n>\n>  The devstack guide is not targeted for physical development. It\'s\n> developed for test environments and doesn\'t support physical bare\n> metal installation out of the box, though that doesn\'t mean you can\'t\n> tweak it for your use!\n>\n>  I would recommend using devstack guide only for testing purposes and\n> follow this guide\n> http://docs.openstack.org/developer/ironic/deploy/install-guide.html\n> [3] for baremetal installation.\n>\n>  Good luck!\n> On 11/13/2014 12:34 PM, aayush.asawa wrote:\n>\n>> hello all,\n>>\n>> We are a team of IIIT,Hyderabad trying to configure openstack with \n>> Ironic and provision a bare node.\n>> as you can see in the snapshot Ironic is enabled.\n>>\n>> we followed this document of openstack.\n>> http://docs.openstack.org/develop?/?/dev/dev-quickstart.html [2]\n>>\n>> Now we are not getting how to create a BareMetal instance on a \n>> physical\n>> node.How openastack Ironic will detect that bare machine and how to\n>> create it through Horizon.\n>>\n>> Our target is to provision a Bare node and launch a coreos instance\n>> with docker.\n>>\n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n>> Post to : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n>\n> --\n> Peeyush Gupta\n> gpeeyush at linux.vnet.ibm.com\n>\n>\n> Links:\n> ------\n> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [2] \n> http://docs.openstack.org/develop&#8230;/&#8230;/dev/dev-quickstart.html\n> [3] \n> http://docs.openstack.org/developer/ironic/deploy/install-guide.html\n\n\n\n','<54646462.1030003@linux.vnet.ibm.com>',NULL),('<065080C8-D609-4141-8BB1-130F2A79E83E@openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-14 10:03:15',-25200,'2012-04-14 17:03:15',NULL,'[Openstack-operators] [Openstack] Health & Monitoring Blueprints','This is an awesome and elegant workaround. We\'ll do this.\n\nLet\'s meet on Sunday afternoon at Rackspace SF to complete this task. Let me know if you want to join.\n\nStef\n\n--\nOn the road, expect brevity and typos\nIn giro, errori e brevit? inclusi\n\nOn Apr 14, 2012, at 9:23 AM, \"Jorge O. Castro\" <jorge at ubuntu.com> wrote:\n\n> On Sat, Apr 14, 2012 at 1:35 AM, Duncan McGreggor <duncan at dreamhost.com> wrote:\n>> \n>> What about running on a LiveCD? You should be able to install Webex,\n>> as long as the file system is mounted.\n>> \n>> Jorge, is that correct? It\'s been a while since I\'ve used LiveCD.\n> \n> This will work (I\'ve done this sort of thing in the past.). What might\n> work better is running off of a liveUSB stick with persistence\n> enabled, so you can set them one prior to the event with everything\n> you need and then just clone them; then you\'d be able to reuse them if\n> you need to swap out hardware.\n> \n> -- \n> Jorge Castro\n> Canonical Ltd.\n> http://cloud.ubuntu.com\n\n','<CA+6NWtt5Qd8P5xcOrZLc53R8pNanS7_WMdngmsTm4yr-KYc+LA@mail.gmail.com>',NULL),('<065182F0-231B-49AA-9A78-B6979785F0F9@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-15 18:26:19',14400,'2013-07-15 14:26:19',NULL,'[openstack-dev] [savanna]error while accessing Savanna UI','Congratulations!\n\nOn Jul 15, 2013, at 6:13 PM, Arindam Choudhury <arindam at live.com> wrote:\n\n> Its solved. \n> \n> I started a cluster and then its working.\n> \n>> Date: Mon, 15 Jul 2013 09:57:20 -0400\n>> From: matt at redhat.com\n>> To: openstack-dev at lists.openstack.org\n>> CC: arindam at live.com; savanna-all at lists.launchpad.net\n>> Subject: Re: [openstack-dev] [savanna]error while accessing Savanna UI\n>> \n>> On 07/15/2013 08:45 AM, Arindam Choudhury wrote:\n>>> Hi,\n>>> \n>>> I did:\n>>> \n>>> git clone https://github.com/stackforge/savanna-dashboard.git\n>>> \n>>> cd savanna-dashboard\n>>> \n>>> python setup.py install\n>>> \n>>> pip show savannadashboard\n>>> ---\n>>> Name: savannadashboard\n>>> Version: 0.2.rc2\n>>> Location:\n>>> /usr/lib/python2.6/site-packages/savannadashboard-0.2.rc2-py2.6.egg\n>>> Requires:\n>>> \n>>> then in /usr/share/openstack-dashboard/openstack_dashboard/settings.py\n>>> \n>>> HORIZON_CONFIG = {\n>>> \'dashboards\': (\'project\', \'admin\', \'settings\', \'savanna\',),\n>>> \n>>> \n>>> INSTALLED_APPS = (\n>>> \'openstack_dashboard\',\n>>> \'savannadashboard\',\n>>> \n>>> and in\n>>> /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py\n>>> \n>>> SAVANNA_URL = \'http://localhost:8386/v1.0\'\n>>> \n>>> But whenever I try to access savanna dashboard I get the following error\n>>> in httpd error_access log:\n>>> \n>>> [Mon Jul 15 07:44:35 2013] [error] ERROR:django.request:Internal Server\n>>> Error: /dashboard/savanna/\n>>> [Mon Jul 15 07:44:35 2013] [error] Traceback (most recent call last):\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/django/core/handlers/base.py\", line\n>>> 111, in get_response\n>>> [Mon Jul 15 07:44:35 2013] [error] response = callback(request,\n>>> *callback_args, **callback_kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/decorators.py\", line 38, in dec\n>>> [Mon Jul 15 07:44:35 2013] [error] return view_func(request, *args,\n>>> **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/decorators.py\", line 54, in dec\n>>> [Mon Jul 15 07:44:35 2013] [error] return view_func(request, *args,\n>>> **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/decorators.py\", line 38, in dec\n>>> [Mon Jul 15 07:44:35 2013] [error] return view_func(request, *args,\n>>> **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/django/views/generic/base.py\", line\n>>> 48, in view\n>>> [Mon Jul 15 07:44:35 2013] [error] return self.dispatch(request,\n>>> *args, **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/django/views/generic/base.py\", line\n>>> 69, in dispatch\n>>> [Mon Jul 15 07:44:35 2013] [error] return handler(request, *args,\n>>> **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/tables/views.py\", line 155, in get\n>>> [Mon Jul 15 07:44:35 2013] [error] handled = self.construct_tables()\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/tables/views.py\", line 146, in\n>>> construct_tables\n>>> [Mon Jul 15 07:44:35 2013] [error] handled = self.handle_table(table)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/tables/views.py\", line 118, in\n>>> handle_table\n>>> [Mon Jul 15 07:44:35 2013] [error] data = self._get_data_dict()\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/horizon/tables/views.py\", line 182, in\n>>> _get_data_dict\n>>> [Mon Jul 15 07:44:35 2013] [error] self._data =\n>>> {self.table_class._meta.name: self.get_data()}\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/savannadashboard-0.2.rc2-py2.6.egg/savannadashboard/clusters/views.py\",\n>>> line 40, in get_data\n>>> [Mon Jul 15 07:44:35 2013] [error] clusters = savanna.clusters.list()\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/savannadashboard-0.2.rc2-py2.6.egg/savannadashboard/api/clusters.py\",\n>>> line 74, in list\n>>> [Mon Jul 15 07:44:35 2013] [error] return self._list(\'/clusters\',\n>>> \'clusters\')\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/savannadashboard-0.2.rc2-py2.6.egg/savannadashboard/api/base.py\",\n>>> line 84, in _list\n>>> [Mon Jul 15 07:44:35 2013] [error] resp = self.api.client.get(url)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/savannadashboard-0.2.rc2-py2.6.egg/savannadashboard/api/httpclient.py\",\n>>> line 28, in get\n>>> [Mon Jul 15 07:44:35 2013] [error] headers={\'x-auth-token\': self.token})\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/requests/api.py\", line 55, in get\n>>> [Mon Jul 15 07:44:35 2013] [error] return request(\'get\', url, **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/requests/api.py\", line 44, in request\n>>> [Mon Jul 15 07:44:35 2013] [error] return\n>>> session.request(method=method, url=url, **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/requests/sessions.py\", line 335, in\n>>> request\n>>> [Mon Jul 15 07:44:35 2013] [error] resp = self.send(prep, **send_kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/requests/sessions.py\", line 438, in send\n>>> [Mon Jul 15 07:44:35 2013] [error] r = adapter.send(request, **kwargs)\n>>> [Mon Jul 15 07:44:35 2013] [error] File\n>>> \"/usr/lib/python2.6/site-packages/requests/adapters.py\", line 327, in send\n>>> [Mon Jul 15 07:44:35 2013] [error] raise ConnectionError(e)\n>>> [Mon Jul 15 07:44:35 2013] [error] ConnectionError:\n>>> HTTPConnectionPool(host=\'localhost\', port=8386): Max retries exceeded\n>>> with url: /v1.0/96b716ba9ce84ef7947d3c42ad185eae/clusters (Caused by\n>>> <class \'socket.error\'>: [Errno 111] Connection refused)\n>> \n>> Do you have any associated (in time) errors in the savanna-api debug log?\n>> \n>> Best,\n>> \n>> \n>> matt\n>> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<DUB116-W28ED1C0C61FEA957FEBB1CDF670@phx.gbl>',NULL),('<0651E2BB-AF52-40CB-852D-81CC41BB2769@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-29 15:45:51',-25200,'2013-07-29 22:45:51',NULL,'[openstack-dev] [horizon] namespace error in unit test','I got the following error in running unit test. \n\n======================================================================\nERROR: Failure: NoReverseMatch (u\'firewalls\' is not a registered namespace inside \'horizon:project\')\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/home/nova/horizon/.venv/local/lib/python2.7/site-packages/nose/loader.py\", line 413, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/home/nova/horizon/.venv/local/lib/python2.7/site-packages/nose/importer.py\", line 47, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/home/nova/horizon/.venv/local/lib/python2.7/site-packages/nose/importer.py\", line 94, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/home/nova/horizon/openstack_dashboard/dashboards/project/firewalls/tests.py\", line 42, in <module>\n    class FirewallTests(test.TestCase):\n  File \"/home/nova/horizon/openstack_dashboard/dashboards/project/firewalls/tests.py\", line 51, in FirewallTests\n    INDEX_URL = reverse(\'horizon:%s:firewalls:index\' % DASHBOARD)\n  File \"/home/nova/horizon/.venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\", line 489, in reverse\n    (key, \':\'.join(resolved_path)))\nNoReverseMatch: u\'firewalls\' is not a registered namespace inside \'horizon:project\'\n\n\nThe urls.py syntax I used is consistent with other panels:\n\n?.\nurlpatterns = patterns(\n    \'openstack_dashboard.dashboards.project.firewalls.views\',\n    url(r\'^$\', IndexView.as_view(), name=\'index\'),\n?.\n\nAny advice what\'s wrong?\n\nThanks!\nKC\n\n\n\n',NULL,NULL),('<065D784F-0B38-438D-90F1-66761EDE7C5E@openstack.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 14:51:39',-18000,'2013-08-20 19:51:39',NULL,'[openstack-dev] [oslo.db] Proposal: Get rid of deleted column','On Aug 20, 2013, at 2:33 PM, Chris Behrens <cbehrens at codestud.com>\nwrote:\n\n> For instances table, we want to make sure \'uuid\' is unique.  But we can\'t put a unique constraint on that alone.  If that instance gets deleted.. we should be able to create another entry with the same uuid without a problem.  So we need a unique constraint on uuid+deleted.  But if \'deleted\' is only 0 or 1? we can only have 1 entry deleted and 1 entry not deleted.  Using deleted=`id` to mark deletion solves that problem.  You could use deleted_at? but 2 creates and deletes within the same second would not work. :)\n\nThis creates another problem if you ever need to delete this second instance, because now you have two with the same uuid and the same deleted status. \'deleted_at\' is slightly better, as the only place it would fail is if all of this happened within the same unit of precision for that time value.\n\n\n-- Ed Leafe\n\n\n','<469607E2-94CD-42D5-A1CF-E9DA961224D5@codestud.com>',NULL),('<066176B6-6F85-4EC5-B8D9-085CA0E04B38@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 18:24:57',-18000,'2013-12-19 23:24:57',NULL,'[openstack-dev] [Neutron][IPv6] Meeting time - change to 1300\n	UTC or 1500 UTC?','I cannot do 13:00UTC, but 14:00 or 15:00 UTC should work for me.\n\n\n\n> On Dec 19, 2013, at 5:12 PM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n> \n> Thoughts? I know we have people who are not able to attend at our\n> current time.\n> \n> -- \n> Sean M. Collins\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<7EB180D009B1A6428D376906754127CB297872F3@PACDCEXMB22.cable.comcast.com>',NULL),('<0666D5D8-EB63-47F1-B8A8-983818244BC8@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 13:54:56',-28800,'2013-03-04 21:54:56',NULL,'[openstack-dev] Nova PTL Candidacy','\nOn Mar 4, 2013, at 12:58 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> \n> I haven\'t noticed such a freeze. AFAIK, there was lots of work done in\n> Grizzly timeframe to add networking management API calls to Nova to\n> remove the need to use nova-manage for a lot of stuff, which would be a\n> welcome improvement, but unless I am badly mistaken, this work was in\n> contradiction to any freeze on nova-network. Vish, please correct me if\n> I am wrong.\n\nWe have had a soft freeze. A few minor features have gone in, but mostly it is just bugfixes and cleanup. We did do an optimization pass. The api calls are part of an effort to get rid of nova-manage which only required very minor changes to nova-network. That way the effort to remove nova-network and the effort to remove nova-manage aren\'t dependent on one another.\n\nVish\n\n','<51350AF1.4040707@gmail.com>',NULL),('<06681238D8946F44A60AA400760A1CBF0103E337@SHSMSX101.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-13 16:36:12',0,'2013-05-13 16:36:12',NULL,'[openstack-dev] [Swift] Proposal for Light weight Erasure code\n	framework of swift','Hi folks,\n\nWe went through this very quickly on last summit. Here we have some updates:\nhttps://etherpad.openstack.org/SwiftEC\n\nIn general, we try to isolated the Erasure code with original Swift code. All of the functions are designed as add-ons for Swift, , and they can be turned off easily.\n\nBP link: https://blueprints.launchpad.net/swift/+spec/swift-ec\n\nAny feedback on this are welcome!\n\nRegards,\n-yuanz\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130513/395fdcde/attachment.html>\n\n',NULL,NULL),('<06681238D8946F44A60AA400760A1CBF01A33958@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 03:57:48',0,'2013-07-03 03:57:48',NULL,'[openstack-dev] [Swift] failure node muting not working','Hi lists,\n\nWe\'re trying to evaluate the node failure performance in Swift.\nAccording the docs Swift should be able to mute the failed nodes:\n\'if a storage node does not respond in a reasonable about of time, the proxy considers it to be unavailable and will not attempt to communicate with it for a while.\'\n\nWe did a simple test on a 5 nodes cluster:\n\n1.       Using COSBench to keep downloading files from the clusters.\n\n2.       Stop the networking on SN1, there are lots of \'connection timeout 0.5s\' error occurs in Proxy\'s log\n\n3.       Keep workload running and wait for about 1hour\n\n4.       The same error still occurs in Proxy, which means the node is not muted, but we expect the SN1 is muted in proxy side and there is no \'connection  timeout \' error in Proxy\n\nSo is there any special works needs to be done to use this feature?\n\nRegards, -yuanz\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130703/a091127c/attachment.html>\n\n',NULL,NULL),('<06681238D8946F44A60AA400760A1CBF01A347C2@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-04 01:18:08',0,'2013-07-04 01:18:08',NULL,'[openstack-dev] [Swift] failure node muting not working','Got it. So Swift will try to enable the muted nodes after 60 seconds by default. Thanks.\n\n-yuanz\n\n-----Original Message-----\nFrom: John Dickinson [mailto:me at not.mn] \nSent: Thursday, July 04, 2013 1:23 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Swift] failure node muting not working\n\nTake a look at the proxy config, starting here: https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L70\n\nThe error_suppression_interval and error_suppression_limit control the window you are looking for. With the default values, 10 errors in 60 seconds will prevent the proxy from using that particular storage node for another 60 seconds.\n\n--John\n\n\n\nOn Jul 2, 2013, at 8:57 PM, \"Zhou, Yuan\" <yuan.zhou at intel.com> wrote:\n\n> Hi lists,\n>  \n> We\'re trying to evaluate the node failure performance in Swift.\n> According the docs Swift should be able to mute the failed nodes:\n> \'if a storage node does not respond in a reasonable about of time, the proxy considers it to be unavailable and will not attempt to communicate with it for a while.\'\n>  \n> We did a simple test on a 5 nodes cluster:\n> 1.       Using COSBench to keep downloading files from the clusters.\n> 2.       Stop the networking on SN1, there are lots of \'connection timeout 0.5s\' error occurs in Proxy\'s log\n> 3.       Keep workload running and wait for about 1hour\n> 4.       The same error still occurs in Proxy, which means the node is not muted, but we expect the SN1 is muted in proxy side and there is no \'connection  timeout \' error in Proxy\n>  \n> So is there any special works needs to be done to use this feature?\n>  \n> Regards, -yuanz\n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<6565862B-FBF7-4837-8723-C7A019EAB2D0@not.mn>',NULL),('<06681238D8946F44A60AA400760A1CBF01A737AC@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 06:40:53',0,'2013-08-29 06:40:53',NULL,'[Openstack] [SWIFT] PUTs and GETs getting slower','Hi Klaus,\n\nWe\'ve done some tests on replication in Swift before. Mostly the bottleneck is in the internal network bandwidth between your storage nodes.\nAlso please have a check on your rsyncd.conf to make sure the value of \'max connections\' is not too small.\nHope this can help.\n\nRegards, -yuanz\nSDE @ INTC/SSG/STO/DCST\n\n\nFrom: Klaus Sch?rmann [mailto:klaus.schuermann at mediabeam.com]\nSent: Tuesday, August 20, 2013 3:04 PM\nTo: Maximiliano Venesio; Robert van Leeuwen\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] [SWIFT] PUTs and GETs getting slower\n\nHi,\n\nafter adding additional disks and storing the account- and container-server on SSDs the performance is much better:\n\nBefore:\nGETs      average               620 ms\nPUTs     average               1900 ms\n\nAfter:\nGETs      average               280 ms\nPUTs     average               1100 ms\n\nOnly the rebalance process took days to sync all the data to the additional five disks (before each storage node had 3 disks). I used a concurrency of 4. One round to replicate all partitions took over 24 hours. After five days the replicate process takes only 300 seconds.\nEach additional disk has now 300 GB data stored. Is such duration normal to sync the data?\n\nThanks\nKlaus\n\n\nVon: Maximiliano Venesio [mailto:maximiliano.venesio at mercadolibre.com]\nGesendet: Donnerstag, 8. August 2013 17:26\nAn: Robert van Leeuwen\nCc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nBetreff: Re: [Openstack] [SWIFT] PUTs and GETs getting slower\n\nHi Robert,\n\nI was reading your post and is interesting because we have similar swift deployments and uses cases.\nWe are storing millons of small images in our swift cluster, 32 Storage nodes w/12 - 2TB HDD + 2 SSD each one, and we are having an total average of 200k rpm in whole cluster.\nIn terms of % of util. of our disks,  we have an average of 50% of util in all our disks but we just are using a 15% of the total capacity of them.\nWhen I look at used inodes on our object nodes with \"df -i\" we hit about 17 million inodes per disk.\n\nSo it seems a big number of inodes considering that we are using just a 15% of the total capacity. A different thing here is that we are using 512K of inode size and we have a big amount of memory .\nAlso we always have one of our disks close to 100% of util, and this is caused by the object-auditor that scans all our disks continuously.\n\nSo we was also thinking in the possibility to change the kind of disks that we are using, to use smaller and faster disks.\nWill be really util to know what kind of disks are you using in your old and new storage nodes, and compare that with our case.\n\n\nCheers,\nMax\n\n\n[http://s14.postimage.org/sg1lztqep/cloudbuilders_Logo_last_small.png]\n\nMaximiliano Venesio\n#melicloud CloudBuilders\nArias 3751, Piso 7 (C1430CRG)\nCiudad de Buenos Aires - Argentina\nCel: +549(11) 15-3770-1853\nTel : +54(11) 4640-8411\n\nOn Tue, Aug 6, 2013 at 11:54 AM, Robert van Leeuwen <Robert.vanLeeuwen at spilgames.com<mailto:Robert.vanLeeuwen at spilgames.com>> wrote:\nCould you check your disk IO on the container /object nodes?\n\nWe have quite a lot of files in swift and for comparison purposes I played a bit with COSbench to see where we hit the limits.\nWe currently max out at about 200 - 300 put request/second and the bottleneck is the disk IO on the object nodes\nOur account / container nodes are on SSD\'s and are not a limiting factor.\n\nYou can look for IO bottlenecks with e.g. \"iostat -x 10\" (this will refresh the view every 10 seconds.)\nDuring the benchmark is see some of the disks are hitting 100% utilization.\nThat it is hitting the IO limits with just 200 puts a second has to do with the number of files on the disks.\nWhen I look at used inodes on our object nodes with \"df -i\" we hit about 60 million inodes per disk.\n(a significant part of that are actually directories I calculated about 30 million files based on the number of files in swift)\nWe use flashcache in front of those disks and it is still REALLY slow, just doing a \"ls\" can take up to 30 seconds.\nProbably adding lots of memory should help caching the inodes in memory but that is quite challenging:\nI am not sure how big a directory is in the xfs inode tree but just the files:\n30 million x 1k inodes =  30GB\nAnd that is just one disk :)\n\nWe still use the old recommended inode size of 1k and the default of 256 can be used now with recent kernels:\nhttps://lists.launchpad.net/openstack/msg24784.html\n\nSo sometime ago we decided to go for nodes with more,smaller & faster disks with more memory.\nThose machines are not even close to their limits however we still have more \"old\" nodes\nso performance is limited by those machines.\nAt this moment it is sufficient for our use case but I am pretty confident we would be able to\nsignificantly improve performance by adding more of those machines and doing some re-balancing of the load.\n\nCheers,\nRobert van Leeuwen\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/4ebe099d/attachment.html>\n\n','<A10F7A7B4917A54192E18ECDC4945ACF076F3848@EXCHANGE01.mediabeam.loc>',NULL),('<06681238D8946F44A60AA400760A1CBF01A77CF0@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-05 03:43:21',0,'2013-09-05 03:43:21',NULL,'[Openstack] Help - swift with low IOPS','Hi Pang,\n\nWould you have a check on the iostat data of  your storage nodes? There seems like to be another bottleneck in the disks.\nWith 3k tps, assuming there\'s no bottleneck in the network and CPU part, the IOPS for each disk would be:\n3000 * 3(3-replicas) / 50(# of disks) = 180\n\nThat\'s really a heavy load given that the average object size in your application is 500KB. I\'d suggest adding more disks to the cluster in addition.\n\n\nRegards, -yuanz\n\n-----Original Message-----\nFrom: Jonathan Lu [mailto:jojokururu at gmail.com] \nSent: Wednesday, September 04, 2013 5:04 PM\nTo: pangj\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Help - swift with low IOPS\n\nHi,\n     If all your requests are PUT, then the expected network bandwidth should be:\n         3000*500/1024*8 = 11718.75Mbps , which means more than 10Gbps\n\n     According to your environment, there are 2 proxies ( giga network?) and that is far away from the expectation.\n     For example, in our production there are also 2 proxies with giga network bandwith, 5 nodes each with 3T*12. The limit of the performance is about 600Mbps. We think that hit the bottleneck of the network. \nUploading large objects will consume more network bandwidth and lower CPU, so 1st step you\'d better improve your network to meet your requirement.\n\nBest Regards,\nJonathan Lu\n\nOn 2013/9/4 16:18, pangj wrote:\n> Hi,\n>\n> How does a setup make swift have the capability of 3000 TPS, for the \n> average size 500KB of files? What architecture, hardware, network etc \n> will be expected? Thanks for any suggestion.\n>\n> On 2013-9-3 17:11, pangj wrote:\n>>\n>> Thanks for the info. I have checked this one days ago.\n>> Given the case, in the production environment, we have 3 nodes with \n>> SSD for account/container servers, 5 nodes each with 2T * 10 for \n>> object storage servers. Currently having two proxies. All servers are \n>> 16 core CPU powered, storage server (account/container/object) has \n>> 48GB memory, proxy has 16GB memory. The average size for an object is \n>> about 500KB, there are many containers (more than 100 millions), but \n>> objects under each container are few (less than 20). There is only \n>> one account for TempAuth.\n>> Is there any better way to optimize the architecture?\n>>\n>> Regards.\n>\n>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<5226F795.9070005@gmail.com>',NULL),('<06681238D8946F44A60AA400760A1CBF01A94036@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-12 03:24:27',0,'2013-09-12 03:24:27',NULL,'[Openstack] Regarding replicator behavior with single replica','Hi Tushar,\n\nOne possible reason is that one of your devices is unavailable when you\'re uploading ? \nThis makes some of objects are uploaded to handoff devices actually and obj-replicator will try to move them back to primary devices.\n\nRegards, \n-Yuan\n\n\n-----Original Message-----\nFrom: Vengurlekar, Tushar V (USD-SWD) [mailto:tushar.vengurlekar at hp.com] \nSent: Wednesday, September 11, 2013 8:02 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Regarding replicator behavior with single replica\n\nHello everyone,\n\nI was trying a Swift setup having single replica configured with 4 devices added to the ring with different IP addresses.\nLater (after all replication/rebalance completed) I uploaded many objects in a multiple containers.\nI observe the data movement across these devices through rsync replicator daemon.\n\nI understand that the object rebalance (using rsync) should happen only when we add devices or change weight value in ring (and if multiple replicas configured). \nSo what is a reason that it performs data movement (of newly uploaded objects) without any ring changes and single replica?\n\nThanks in advance,\nTushar\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<35ABFEB7ADB58A4AADA790A3DC6391626C716C82@G4W3305.americas.hpqcorp.net>',NULL),('<06681238D8946F44A60AA400760A1CBF01A9702D@SHSMSX104.ccr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-13 02:06:37',0,'2013-09-13 02:06:37',NULL,'[Openstack] Regarding replicator behavior with single replica','Not that I know of..\n\nThe object location(including handoff) is provided by swift-get-nodes:\n\n$ swift-get-nodes -a /etc/swift/object.ring.gz a c o\n\nDid you observed which object is moving and its moving path? was it moving from handoff to primary?\n\nBR, \n-Yuan\n\n-----Original Message-----\nFrom: Vengurlekar, Tushar V (USD-SWD) [mailto:tushar.vengurlekar at hp.com] \nSent: Friday, September 13, 2013 1:02 AM\nTo: Zhou, Yuan; openstack at lists.openstack.org\nSubject: RE: Regarding replicator behavior with single replica\n\nHi Yuan,\n\nAll my devices are up. Will replicator try to move object even though I have single replica?\n\nThanks,\nTushar\n\n-----Original Message-----\nFrom: Zhou, Yuan [mailto:yuan.zhou at intel.com] \nSent: Thursday, September 12, 2013 8:54 AM\nTo: Vengurlekar, Tushar V (USD-SWD); openstack at lists.openstack.org\nSubject: RE: Regarding replicator behavior with single replica\n\nHi Tushar,\n\nOne possible reason is that one of your devices is unavailable when you\'re uploading ? \nThis makes some of objects are uploaded to handoff devices actually and obj-replicator will try to move them back to primary devices.\n\nRegards, \n-Yuan\n\n\n-----Original Message-----\nFrom: Vengurlekar, Tushar V (USD-SWD) [mailto:tushar.vengurlekar at hp.com] \nSent: Wednesday, September 11, 2013 8:02 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Regarding replicator behavior with single replica\n\nHello everyone,\n\nI was trying a Swift setup having single replica configured with 4 devices added to the ring with different IP addresses.\nLater (after all replication/rebalance completed) I uploaded many objects in a multiple containers.\nI observe the data movement across these devices through rsync replicator daemon.\n\nI understand that the object rebalance (using rsync) should happen only when we add devices or change weight value in ring (and if multiple replicas configured). \nSo what is a reason that it performs data movement (of newly uploaded objects) without any ring changes and single replica?\n\nThanks in advance,\nTushar\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<35ABFEB7ADB58A4AADA790A3DC6391626C7184C6@G4W3305.americas.hpqcorp.net>',NULL),('<066A4650-4731-4A4C-9CB1-B9268F4D306E@rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-14 16:16:54',0,'2013-11-14 16:16:54',NULL,'[Openstack] [Heat] Locked Outputs','\nOn Nov 13, 2013, at 3:51 PM, Zane Bitter <zbitter at redhat.com> wrote:\n\n> On 13/11/13 18:14, Randall Burt wrote:\n>> \n>> On Nov 13, 2013, at 9:18 AM, Zane Bitter <zbitter at redhat.com>\n>>  wrote:\n>> \n>>> On 13/11/13 04:08, Andrew Plunk wrote:\n>>>> 2).Provide a way to express metadata about stack outputs returned from heat.\n>>> \n>>> This could involve something like a \"Sensitive: true\" field in the Output schema. Heat would ignore it but pass it on to clients so that something like the dashboard could e.g. require an extra click to show it, and hide it again after a timeout.\n>>> \n>>> Alternatively, as lifeless points out, you could pass the password in using a hidden input. That\'s the currently supported way, and I suspect the better one in most cases.\n>> \n>> I mostly agree with this suggestion. For symmetry with parameters, we could simply add a key to outputs \"hidden: true\". For things like stack-list, the default would be to display a masked value like we do for parameters. I think we should then add the ability to retrieve the unmasked values for parameters and outputs.\n> \n> I think that would work well for the CLI client, but if I were the dashboard I don\'t think that is the way I would want to fetch the data. There\'s no actual security benefit to returning a masked value.\n> \n> - ZB\n\nI think it could work for dashboards as well. The behavior would be to display the masked value and add a control that once activated, retrieves the unmasked value. Since one hopes this dashboard would be using some library like python-heatclient, its not that much work.\n\nAs to there being no security value in masking sensitive data, we already have a precedent for this in parameters without having the ability to get the unmasked values IIRC. The fact that those are user-supplied sensitive data versus system generated sensitive data is irrelevant since its the template author (which isn\'t always the person deploying the template) that determines a value\'s sensitivity, not some inherent property of the value.\n\n\n\n','<5283F46D.1070809@redhat.com>',NULL),('<066DC88E-CDB8-4F51-AC43-38738DB5F4A2@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 14:44:59',-28800,'2015-01-15 22:44:59',NULL,'[openstack-dev] [neutron] Changes to the core team','+1 to Doug?s addition.  He?s been a workhorse in moving lbaas and the services split forward and his being able to finally merge code in the main repo should be a boon to our merge velocity.\n\nMany thanks to Sumit for his long-serving dedication as a core reviewer.  I hope to see him return to the fold soon!\n\n\nMaru\n\n> On Jan 15, 2015, at 2:31 PM, Kyle Mestery <mestery at mestery.com> wrote:\n> \n> The last time we looked at core reviewer stats was in December [1]. In looking at the current stats, I\'m going to propose some changes to the core team. Reviews are the most important part of being a core reviewer, so we need to ensure cores are doing reviews. The stats for the 90 day period [2] indicate some changes are needed for core reviewers who are no longer reviewing on pace with the other core reviewers.\n> \n> First of all, I\'m removing Sumit Naiksatam from neutron-core. Sumit has been a core reviewer for a long time, and his past contributions are very much thanked by the entire OpenStack Neutron team. If Sumit jumps back in with thoughtful reviews in the future, we can look at getting him back as a Neutron core reviewer. But for now, his stats indicate he\'s not reviewing at a level consistent with the rest of the Neutron core reviewers.\n> \n> As part of the change, I\'d like to propose Doug Wiegley as a new Neutron core reviewer. Doug has been actively reviewing code across not only all the Neutron projects, but also other projects such as infra. His help and work in the services split in December were the reason we were so successful in making that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as well as helping to merge code in the other neutron service repositories.\n> \n> I\'d also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I\'d also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer.\n> \n> Existing neutron cores, please vote +1/-1 for the addition of Doug to the core team.\n> \n> Thanks!\n> Kyle\n> \n> [1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html\n> [2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAL3VkVx99ru5uSEbHXPkDAneWvVzcAWgVojsxR1kr6Ew6iDVTA@mail.gmail.com>',NULL),('<0673daeb4a7e19d68988a5dc847ee201@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-08 18:51:24',7200,'2014-12-08 16:51:24',NULL,'[Openstack] Scheduler Filters Ignored',' Thx Jay!\n\n I \'ll try that!\n\n Best,\n\n George\n\n On Fri, 28 Nov 2014 11:32:38 -0500, Jay Pipes wrote:\n> On 11/28/2014 11:22 AM, Georgios Dimitrakakis wrote:\n>> Jay,\n>>\n>> you were right!\n>>\n>> If I remove the \"availability zone\" parameter then filters are \n>> applied!!!\n>>\n>> Do you know if this is an expected behavior?\n>\n> Honestly, the way our filter scheduler works with regards to\n> aggregates is so wonky that I wouldn\'t be surprised to learn that \n> this\n> is \"expected\". :(\n>\n> Try adjusting the cpu_allocation_ratio and ram_allocation_ratio of\n> the host aggregate that has the same availability zone in its\n> metadata. That should allow you to get the same behaviour when you \n> use\n> the availability zone scheduler hint in the boot command.\n>\n> Best,\n> -jay\n\n\n','<5478A3A6.1090506@gmail.com>',NULL),('<0684A179-0389-489C-A5B3-05133C9048D8@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-05 18:50:26',-28800,'2014-03-06 02:50:26',NULL,'[openstack-dev] [Mistral] Crack at a \"Real life\" workflow','Folks, \n\nI took a crack at using our DSL to build a real-world workflow. \nJust to see how it feels to write it. And how it compares with alternative tools. \n\nThis one automates a page from OpenStack operation guide: http://docs.openstack.org/trunk/openstack-ops/content/maintenance.html#planned_maintenance_compute_node \n\nHere it is https://gist.github.com/dzimine/9380941\nor here http://paste.openstack.org/show/72741/\n\nI have a bunch of comments, implicit assumptions, and questions which came to mind while writing it. Want your and other people\'s opinions on it. \n\nBut gist and paste don\'t let annotate lines!!! :(\n\nMay be we can put it on the review board, even with no intention to check in,  to use for discussion? \n\nAny interest?\n\nDZ> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140305/1e907f14/attachment.html>\n\n',NULL,NULL),('<0687aad87a9c2f2d105c22ac232e8aad@sileht.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 15:17:51',3600,'2014-12-04 14:17:51',NULL,'[openstack-dev] oslo.messaging 1.5.1 released','\nThe Oslo team is pleased to announce the release of\noslo.messaging 1.5.1: Oslo Messaging API\n\nThis release reintroduces the \'fake_rabbit\' config option.\n\nFor more details, please see the git log history below and\n  https://launchpad.net/oslo.messaging//+milestone/1.5.1\n\nPlease report issues through launchpad:\n  https://bugs.launchpad.net/oslo.messaging/\n\n----------------------------------------\n\nChanges in openstack/oslo.messaging  1.5.0..1.5.1\n\n712f6e3 Reintroduces fake_rabbit config option\n554ad9d Imported Translations from Transifex\n\n   diffstat (except docs and test files):\n\n  .../locale/de/LC_MESSAGES/oslo.messaging.po           |  8 ++++++--\n  .../locale/en_GB/LC_MESSAGES/oslo.messaging.po        |  8 ++++++--\n  .../locale/fr/LC_MESSAGES/oslo.messaging.po           |  8 ++++++--\n  oslo.messaging/locale/oslo.messaging.pot              |  8 ++++++--\n  oslo/messaging/_drivers/impl_rabbit.py                | 13 \n++++++++++++-\n  tests/drivers/test_impl_rabbit.py                     | 19 \n+++++++++++++++++++\n  6 files changed, 55 insertions(+), 9 deletions(-)\n\n   Requirements updates: N/A\n\n\n-- \nMehdi Abaakouk\nmail: sileht at sileht.net\nirc: sileht\n\n\n',NULL,NULL),('<0689420E-6382-47DF-97A1-B17DE3549E07@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 10:06:22',-28800,'2013-11-12 18:06:22',NULL,'[openstack-dev] [Nova] Configuration validation','Thanks folks for the interesting suggestions on this topic!  I?ll b updating the BP this week with this and other info i am gathering. \n\nPlease let me know if you are interested in being involved in brainstorming on this issue and I will set up an irc meeting to discuss it further\n\nOn Nov 11, 2013, at 3:08 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n> Hi Nikola,\n> \n> On Mon, 2013-11-11 at 12:44 +0100, Nikola ?ipanov wrote:\n>> Hey all,\n>> \n>> During the summit session on the the VMWare driver roadmap, a topic of\n>> validating the passed configuration prior to starting services came up\n>> (see [1] for more detail on how it\'s connected to that specific topic).\n>> \n>> Several ideas were thrown around during the session mostly documented in\n>> [1].\n>> \n>> There are a few more cases when something like this could be useful (see\n>> bug [2] and related patch [3]), and I was wondering if a slightly\n>> different approach might be useful. For example use an already existing\n>> validation hook in the service class [4] to call into a validation\n>> framework that will potentially stop the service with proper\n>> logging/notifications. The obvious benefit would be that there is no\n>> pre-run required from the user, and the danger of running a\n>> misconfigured stack is smaller.\n> \n> One thing worth trying would be to encode the validation rules in the\n> config option declaration.\n> \n> Some rules could be straightforward, like:\n> \n> opts = [\n>  StrOpt(\'foo_url\',\n>         validate_rule=cfg.MatchesRegexp(\'(git|http)://\')),\n> ]\n> \n> but the rule you describe is more complex e.g.\n> \n> def validate_proxy_url(conf, group, key, value):\n>    if not conf.vnc_enabled:\n>        return\n>    if conf.ssl_only and value.startswith(\"http://\"):\n>        raise ValueError(\'ssl_only option detected, but ...\')\n> \n> opts = [\n>  StrOpt(\'novncproxy_base_url\',\n>         validate_rule=validate_proxy_url),\n>  ...\n> ]\n> \n> I\'m not sure I love this yet, but it\'s worth experimenting with.\n> \n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/cc1809e2/attachment.html>\n\n','<1384211314.3753.148.camel@sorcha>',NULL),('<068D4C883F2240C891055C7AFC8F02AA@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-02 21:22:19',-18000,'2013-03-03 02:22:19',NULL,'[openstack-dev] ServiceGroup code in Nova','\n\n\nOn Saturday, March 2, 2013 at 16:05 PM, Endre Karlson wrote:\n\n> Would it be possible to get the Zookeeper code and so on moved out of Nova and into Oslo?\n> \nTo me, it seems inappropriate to do this during the feature-freeze. However, I do think that this should be done in Havana.\n\nPresently however, in Oslo, there does exist similar functionality in the \"matchmaker\" which is presently part and parcel with the RPC drivers. We\'re only using this for ZeroMQ messaging at the present, but it could be used in place of Nova\'s service group API. In fact, I even have a patch to back Nova\'s service group API with the matchmaker. The Matchmaker presently supports lookups via a static, file-based service directory and via a Redis server. If you\'re looking for Service Group API functionality in oslo-incubator today, without waiting for Havana, I do suggest looking at openstack.common.rpc.matchmaker.\n\nI will be proposing a session on bridging the gap between the matchmaker service-group features at the Havana summit.\n\nMy opinion at present is that the matchmaker should gain Zookeeper and Memcache drivers, ported from the work done with the Service Group API, and introduce a service-group driver that is supported by the matchmaker.  This will simplify the option of using the database and nova-conductor, which are more difficult to support in Oslo itself, while also supporting these alternative solutions (Zookeeper, Redis, Memcache, etc). We have discussed going the other way around as well, and arguably we could do that. However, I think the matchmaker presently offers a superset of features, has the advantage of already being in oslo-incubator, and will now have been in two stable releases. Of course, I\'m more than biased, as the principal author of the matchmaker code.\n\nRegards,\nEric Windisch\n\n\n\n\n\n','<CAFxO1NS9nf86nD_KZ2aKOR0PB7HNv6AeXUzWdDigmEH6zVgoQw@mail.gmail.com>',NULL),('<068F06DC4D106941B297C0C5F9F446EA4AF105CA24@aplesstripe.dom1.jhuapl.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 09:26:03',-18000,'2014-01-20 14:26:03',NULL,'[openstack-dev] [Nova] Can someone from the Nova core team please\n take a look at patch 40467','Hello Nova core team,\n\nI have three small patches implementing ephemeral storage encryption for LVM backed instances.\n\nhttps://review.openstack.org/#/c/40467/\nhttps://review.openstack.org/#/c/60621/\nhttps://review.openstack.org/#/c/61544/\n\nThe patches have been under review for a couple months now and have gone through several rounds of revisions. There are already a number of +1\'s and the patches are only awaiting +2\'s, and in one case a +1, from the core team.\n\nThank you for your help,\nDan\n\n','<1390227817.2281.7.camel@serialcoder>',NULL),('<068f331b9aac4bcb8356f35fb8db3442@HKXPR04MB183.apcprd04.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-11 11:05:52',0,'2014-10-11 11:05:52',NULL,'[Openstack] [icehouse][HA]','Hi,\n\nI have a requirement to install openstack icehouse HA setup with 10 nodes running Ubuntu 14.04 operating system.\nPlease suggest a suitable deployment tool for the above requirement. Any documents or url\'s would be helpful.\n\n\nRegards,\nSubbareddy,\nPersistent systems ltd.\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141011/bb0859e4/attachment.html>\n\n',NULL,NULL),('<06913960-0E1F-4463-BF92-DB6611DE7B23@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-21 13:56:27',0,'2014-03-21 13:56:27',NULL,'[openstack-dev] [Heat] Resource dependencies','Thanks for the explanation, Thomas. Appreciate it!\n\nShaunak\n\nOn Mar 21, 2014, at 12:37 AM, Thomas Spatzier <thomas.spatzier at de.ibm.com> wrote:\n\n> Shaunak Kashyap <shaunak.kashyap at RACKSPACE.COM> wrote on 21/03/2014\n> 05:26:50:\n> \n>> From: Shaunak Kashyap <shaunak.kashyap at RACKSPACE.COM>\n>> To: \"openstack-dev at lists.openstack.org\"\n> <openstack-dev at lists.openstack.org>\n>> Date: 21/03/2014 05:29\n>> Subject: [openstack-dev] [Heat] Resource dependencies\n>> \n>> Hi,\n>> \n>> In a Heat template, what does it mean for a resource to depend on\n>> another resource? As in, what is the impact of creating a dependency?\n> \n> When a resource depends on another resource, this means that the Heat\n> engine will only start processing this resource as soon as the other\n> resource it depends on has been created. If a resource depends on multiple\n> resources, all those other resources have to be created before processing\n> the depedent resource.\n> \n>> \n>> I read http://docs.openstack.org/developer/heat/template_guide/\n>> hot_spec.html#resources-section and found this definition of the\n>> ?depends_on? attribute:\n>> \n>>> This optional attribute allows for specifying dependencies of the\n>> current resource on one or more other resources. Please refer to\n>> section hot_spec_resources_dependencies for details.\n>> \n>> \n>> Unfortunately, I can?t seem to find the referenced\n>> ?hot_spec_resources_dependencies? section anywhere.\n> \n> I just checked the source in github and the section is there:\n> \n> https://github.com/openstack/heat/blob/master/doc/source/template_guide/hot_spec.rst#L452\n> \n> It only looks like the wrong heading markup is used. Nice spotting\n> actually; I will fix it.\n> \n>> \n>> Thank you,\n>> \n>> Shaunak\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<OF5C8FDD84.2CC3CAB1-ONC1257CA2.00299FFC-C1257CA2.0029E850@de.ibm.com>',NULL),('<069A17FF-555B-47A5-83EF-CA3519AD05E8@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-09 14:14:43',28800,'2013-11-09 06:14:43',NULL,'[openstack-dev] Shall backward compatibility env. vars be\n	removed from python-clients?','I think you need to do option 2 and print deprecation warnings, then the question becomes for how long.\n\nI think there is a policy for this and that it is deprecate in N remove in N+1\nClients are a bit different so maybe keep it for ~6 months?\n\nSam\n\n\n\nOn 8 Nov 2013, at 10:49 am, Leandro Costantino <leandro.i.costantino at intel.com> wrote:\n\n> Hi all,\n> \n> Clients like python-novaclient/cinderclient/trove still support NOVA_*, CINDER_*, TROVE_* variables for \n> backward compatibility support,while clients like python-neutronclient/keystoneclient only supports OS_* env vars.\n> \n> \n> The following bug (#1061491, see review), mentions that it may be confusing if novaclient for instance, \n> silently accept those variables without even being mentioned on the current help/documentation neither warning the user at all. \n> (User has exported NOVA_USERNAME/CINDER_USERNAME/etc instead of OS_USERNAME etc.)\n> \n> As Kevin suggested on the review, (https://review.openstack.org/#/c/55588/) \n> ?we need to make sure that we have consensus that enough time has  passed to drop the old variables?.\n> \n> I would like to hear opinions about this. Some options that i can think of are:\n> \n> 1) Remove NOVA_USERNAME, NOVA_PASSWORD and NOVA_PROJECT_ID support \n>   from novaclient. Same for other clients allowing vars other than OS_USERNAME,\n>   OS_PASSWORD, OS_TENANT_ID for this specific options.\n> 2) Warn about deprecation if they are being used.\n> 3) Ignore this topic, keep everything as today and just close the \'bug/suggestion\'.\n> 4) Other?\n> \n> Best Regards\n> -Leandro\n> \n> PS: shall this message belong to another ML, please, let me know.\n> \n> \n> \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<527C514C.4040109@intel.com>',NULL),('<069D30DA-9CBE-4F81-A0E7-070E172B2F75@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-27 10:09:17',-25200,'2013-06-27 17:09:17',NULL,'[openstack-dev] feature to attach USB on Guest VM','The property is hw_disk_bus. See https://bugs.launchpad.net/nova/+bug/1132739\n\nNote that this will force the root disk to be on the usb bus instead of using virtio. I\'m not sure if this is what you want, but it should work in grizzly.\n\nVish\n\nOn Jun 27, 2013, at 5:14 AM, Shyam Goud <shyam.todeti at oneconvergence.com> wrote:\n\n> \n> All,\n> \n> Please ignore if its a wrong alias.\n> \n> I am using grizzly. I have a requirement to attach USB to guest VM. Is this feature committed yet ?\n> Tried following link, but not succeeded. \n> \n> https://bugs.launchpad.net/openstack-manuals/+bug/1106421\n> \n> root at nvp:/home/nvp# glance image-update 59ce4586-0c57-426c-a181-819ec8b3ee91 --property disk_bus=usb\n> +---------------------+--------------------------------------+\n> | Property            | Value                                |\n> +---------------------+--------------------------------------+\n> | Property \'disk_bus\' | usb                                  |\n> | checksum            | d97251713cbf11ff1f86b6bf203defcd     |\n> | container_format    | bare                                 |\n> | created_at          | 2013-06-15T14:10:02                  |\n> | deleted             | False                                |\n> | deleted_at          | None                                 |\n> | disk_format         | qcow2                                |\n> | id                  | 59ce4586-0c57-426c-a181-819ec8b3ee91 |\n> | is_public           | True                                 |\n> | min_disk            | 0                                    |\n> | min_ram             | 0                                    |\n> | name                | CentosImage                          |\n> | owner               | 7cf64e15cb1349d6a5e81ed0d0bbd6fb     |\n> | protected           | False                                |\n> | size                | 5368709120                           |\n> | status              | active                               |\n> | updated_at          | 2013-06-27T10:05:21                  |\n> +---------------------+--------------------------------------+\n> root at nvp:/home/nvp# \n> \n> Appreciate your help,\n> Shyam.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130627/786004d5/attachment.html>\n\n','<51CC2C9D.6070200@oneconvergence.com>',NULL),('<069D30DA-9CBE-4F81-A0E7-070E172B2F75@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-06-27 10:09:17',-25200,'2013-06-27 17:09:17',NULL,'[Openstack-operators] [openstack-dev] feature to attach USB on\n	Guest VM','The property is hw_disk_bus. See https://bugs.launchpad.net/nova/+bug/1132739\n\nNote that this will force the root disk to be on the usb bus instead of using virtio. I\'m not sure if this is what you want, but it should work in grizzly.\n\nVish\n\nOn Jun 27, 2013, at 5:14 AM, Shyam Goud <shyam.todeti at oneconvergence.com> wrote:\n\n> \n> All,\n> \n> Please ignore if its a wrong alias.\n> \n> I am using grizzly. I have a requirement to attach USB to guest VM. Is this feature committed yet ?\n> Tried following link, but not succeeded. \n> \n> https://bugs.launchpad.net/openstack-manuals/+bug/1106421\n> \n> root at nvp:/home/nvp# glance image-update 59ce4586-0c57-426c-a181-819ec8b3ee91 --property disk_bus=usb\n> +---------------------+--------------------------------------+\n> | Property            | Value                                |\n> +---------------------+--------------------------------------+\n> | Property \'disk_bus\' | usb                                  |\n> | checksum            | d97251713cbf11ff1f86b6bf203defcd     |\n> | container_format    | bare                                 |\n> | created_at          | 2013-06-15T14:10:02                  |\n> | deleted             | False                                |\n> | deleted_at          | None                                 |\n> | disk_format         | qcow2                                |\n> | id                  | 59ce4586-0c57-426c-a181-819ec8b3ee91 |\n> | is_public           | True                                 |\n> | min_disk            | 0                                    |\n> | min_ram             | 0                                    |\n> | name                | CentosImage                          |\n> | owner               | 7cf64e15cb1349d6a5e81ed0d0bbd6fb     |\n> | protected           | False                                |\n> | size                | 5368709120                           |\n> | status              | active                               |\n> | updated_at          | 2013-06-27T10:05:21                  |\n> +---------------------+--------------------------------------+\n> root at nvp:/home/nvp# \n> \n> Appreciate your help,\n> Shyam.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130627/786004d5/attachment.html>\n\n','<51CC2C9D.6070200@oneconvergence.com>',NULL),('<06A16589-9AAB-44C0-8C5E-7C5895F0F60E@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-08 08:14:08',-25200,'2013-10-08 15:14:08',NULL,'[openstack-dev] [trove]','> On Oct 8, 2013, at 4:16 AM, Denis Makogon <dmakogon at mirantis.com> wrote:\n> \n> Hi, guys, i\'d like to make few questions clear to all of us.\n> \n> First one is resource clean-up in Trove.\n> \n> According to few previous meetings we decided not to rollback each of resources which is under trove-quota-management controll.\n\nCorrect. The delete call will clean up a tenants resources. \n\n> \n> Let\'s go deeper. I\'m going to cover security groups rollback process if instance didn\'t became active.\n> \n> As compute instance part security groups are controled be Tenants Quotas, so if quota is exceeded there is no chanse to create new one.\n\nAs you stated, we covered this. The only way the user would see this was if their trove limits were higher than their nova limits. That would constitute a bad configuration on the part of the operator, not something we would try to deal with in code. The delete call removes resources. \n\n\n\n','<CAPR0WpJ4fiPyHrvvRZ8-cHzkFEHE1DhwaWBCuP00noi+VbZgGQ@mail.gmail.com>',NULL),('<06A45DEA-69CF-47CA-92A7-F744D526E25D@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-22 17:26:06',-28800,'2014-12-23 01:26:06',NULL,'[openstack-dev] [Mistral] Access to worklfow/task results without\n	implicit publish','The problem:\n\nRefer to workflow / action output without explicitly re-publishing the output values. Why we want it: to reduce repetition, and to make modifications in the place values are used, not where they are obtained (and not in multiple places). E.g., as an editor of a workflow, when I just realized that I need a value of some task down the line, I want to make change right here in the tasks that consumes the data (and only those which need this data), without finding and modifying the task that supplies the data.\n\nReasons:\n\nWe don\'t have a concept of workflow or action ?results\': it\'s the task which produces and publishes results. Different tasks call same actions/workflows, produce same output variables with diff values. We don\'t want to publish this output with output name as a key, to the global context: they will conflict and mess up. Instead, we can namespace them by the task (as specific values are the attributes of the tasks, and we want to refer to tasks, not actions/workflows).\n\nSolution:\n\nTo refer the output of a particular task (aka raw result of action execution invoked by this task), use the_task prefix:\n\n $_task.<taskname>.<path.to.variable>\n $_task.my_task.my_task_result.foo.bar\n\n\nExpanded example\n \nmy_sublfow:\n   output:\n        - foo # << declare output here\n        - bar \n   tasks:\n       my_task:\n         action: get_foo\n         publish: \n             foo: $foo # << define output in a task\n             bar: $bar\n         ...\nmain_flow_with_explicit_publishing:\n    tasks:\n        t1: \n           workflow: my_subflow \n        publish: \n           # Today, you must explicitly publish to make data \n           # from action available for other tasks\n            foo: $foo # << re-plublish, else you can\'t use it\n            bar: $bar\n        t2: \n            action: echo output=\"$foo and $bar\" # << use it from task t1\n\nmain_flow_with_implicit_publishing:\n    tasks:\n        t1: \n           workflow: my_subflow \n        t2: \n            action: echo output=\"$_task.t1.foo and $_task.t1.bar\"\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141222/c9ef4822/attachment.html>\n\n',NULL,NULL),('<06ae16e4daee6b093b3ad88eb55b7d0c@secure.spamaps.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 11:02:48',-25200,'2013-05-03 18:02:48',NULL,'[openstack-dev] [Heat] A concrete proposal for Heat Providers','On 2013-05-02 10:39, Tripp, Travis S wrote:\n>> -----Original Message-----\n>> From: Thomas Spatzier [mailto:thomas.spatzier at de.ibm.com]\n>> Sent: Thursday, May 02, 2013 1:25 AM\n>> To: OpenStack Development Mailing List\n>> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat \n>> Providers\n>> \n>> Clint Byrum <clint at fewbar.com> wrote on 29.04.2013 19:50:22:\n>> \n>>> From: Clint Byrum <clint at fewbar.com>\n>>> To: openstack-dev <openstack-dev at lists.openstack.org>,\n>>> Date: 29.04.2013 19:51\n>>> Subject: Re: [openstack-dev] [Heat] A concrete proposal for Heat\n>> Providers\n>>> \n>>> So I think the message here is that there are two concepts that \n>>> should\n>>> be expressable separately:\n>>> \n>>> * I have app X, which needs informational bits a,b, and c, from \n>>> other\n>>> parts of my stack.\n>>> \n>>> * I want to run app X on a compute resource with properties y and z.\n>>> \n>>> So, it would be useful if the DSL is able to express things things\n>>> separately.\n>> \n>> I did not fully get the two points above. Can you elaborate more or \n>> give an\n>> example?\n>> \n>>> \n>>> As another data point, the juju project still struggles with this\n>> concept,\n>>> and it has been a real sticking point for a lot of users to not be\n>>> able to assemble their apps separate from their resources.\n>>> \n> \n> [Tripp, Travis S]\n> I agree with Clint.  This essentially boils down to being able to\n> describe my application(s) and how to deploy them separately from the\n> resources where I want to deploy them. Then based on the target\n> environment, I have a way to deploy my app to different resources\n> without having to modify / copy paste my app model everywhere.  In\n> TOSCA terms, this is what the \"relationship\" concept provides. For\n> example, I can design my application in one template and\n> infrastructure(s) in another template. Then I essentially can have\n> different deployments where I use the relationship to establish a\n> source and a target for these relationship (App part A is associated\n> to Infra part X). I just spoke with Thomas Spatzier and I think he is\n> going to provide a simplified JSON or YAML representation of this\n> concept.\n> \n> I attached a quick diagram to illustrate the scenario.\n> \n\nIndeed, the diagram did communicate the scenario exactly as I see it.\n\n\n\n','<AD38C991545E8641B21449D96872D72E36C0EB57@G9W0343.americas.hpqcorp.net>',NULL),('<06B2F50C-9425-4C23-8B8B-D9AD28A64C52@radware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 18:17:27',0,'2013-12-09 18:17:27',NULL,'[openstack-dev] [Neutron][LBaaS] L7 model - an alternative','Sorry for the broken link\nHere is a better one:\n\nhttps://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/pub?w=960&h=720\n\nSent from my iPhone\n\nOn 8 ???? 2013, at 17:31, \"Avishay Balderman\" <AvishayB at Radware.com<mailto:AvishayB at Radware.com>> wrote:\n\nHi\nI was thinking about a different way for L7 modeling.\nThe key points are:\n- The Rule has no action attribute\n- A Policy is a collection of rules\n- Association keep a reference to a Vip and to a Policy\n- Association holds the action (what to do if the Policy \"return\" True)\n- Association holds (optional) the Pool ID. When the action is redirection to a pool\nSee:\nhttps://docs.google.com/drawings/d/119JV_dG_odWVVKTcn51qyRh3rW-253uUqfcg9CFQDtg/edit?usp=sharing\n\nPlease let me know what do you think about this model.\n\nThanks\n\nAvishay\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/4951a3bb/attachment.html>\n\n','<A76C8379B2FE0645A7E296ED7B8D46D10108E2CC@ILMB1.corp.radware.com>',NULL),('<06BD0EE7-C8B1-495D-8A99-8C635CB781E3@juniper.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 18:27:02',0,'2013-08-14 18:27:02',NULL,'[openstack-dev] Blueprint for Amazon VPC API support','In addition there is one more change:\n\nNew euca2ools commands have been added to support all the\nVPC related CLI.\n\nThanks,\nRudra\n\nOn Aug 13, 2013, at 10:38 PM, Rudra Rugge <rrugge at juniper.net<mailto:rrugge at juniper.net>> wrote:\n\nHi All,\n\nA blueprint has been registered to add Amazon VPC API support.\nCurrently Amazon EC2 API support already exists in Openstack.\nPlease review the blueprint and the attached specification. The\nspecification covers all the VPC APIs and describes how it maps\nto the Openstack constructs.\n\nBlueprint\nhttps://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n\nSpecification\nhttps://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n\nThe changes are orthogonal to Amazon EC2 APIs but follow the\nsame model as the EC2 API source code. In addition new unit\ntests have been added to cover all the VPC tests.\n\nPlease review the blueprint - all comments are welcome.\n\nThank you,\nRudra\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130814/b91cd6b2/attachment.html>\n\n','<132DC00E-2F06-4111-8302-38545C5D924B@juniper.net>',NULL),('<06BEC8F1-ABE5-49E5-B5D1-6BA91885E0BA@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 16:26:45',-14400,'2014-08-15 20:26:45',NULL,'[openstack-dev] [oslo][db] Nominating Mike Bayer for the\n	oslo.db core reviewers team','\nOn Aug 15, 2014, at 10:00 AM, Ben Nemec <openstack at nemebean.com> wrote:\n\n> On 08/15/2014 08:20 AM, Russell Bryant wrote:\n>> On 08/15/2014 09:13 AM, Jay Pipes wrote:\n>>> On 08/15/2014 04:21 AM, Roman Podoliaka wrote:\n>>>> Hi Oslo team,\n>>>> \n>>>> I propose that we add Mike Bayer (zzzeek) to the oslo.db core\n>>>> reviewers team.\n>>>> \n>>>> Mike is an author of SQLAlchemy, Alembic, Mako Templates and some\n>>>> other stuff we use in OpenStack. Mike has been working on OpenStack\n>>>> for a few months contributing a lot of good patches and code reviews\n>>>> to oslo.db [1]. He has also been revising the db patterns in our\n>>>> projects and prepared a plan how to solve some of the problems we have\n>>>> [2].\n>>>> \n>>>> I think, Mike would be a good addition to the team.\n>>> \n>>> Uhm, yeah... +10 :)\n>> \n>> ^2 :-)\n>> \n> \n> What took us so long to do this? :-)\n> \n> +1 obviously.\n\nI did think it would be a good idea to wait a *little* while and make sure we weren?t going to scare him off. ;-)\n\nSeriously, Mike has been doing a great job collaborating with the existing team and helping us make oslo.db sane.\n\n+1\n\nDoug\n\n\n\n','<53EE1267.5090700@nemebean.com>',NULL),('<06C08FB9-F9E5-4ADF-B4F7-A66DC4F1E8FF@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-01-17 12:14:54',-21600,'2014-01-17 18:14:54',NULL,'[OpenStack Foundation] 2014 Individual Director election results','Hello everyone,\n\nThe 2014 election of Individual Directors has closed. Results are available at the following link:\n\nhttps://www.bigpulse.com/pollresults?code=36403DCmZevPaCKyfNXeAE6Q\n\nThe elected and appointed directors will be seated at 12:00pm PST on January 30th (https://wiki.openstack.org/wiki/Governance/Foundation/30Jan2014BoardMeeting).\n\nThank you to everyone who participated in this year\'s Individual Director election and congratulations to our new and returning directors.\n\nJonathan\n210-317-2438\n\n\nIndividual Directors\n-----------------------------------------\nTim Bell\nYujie Du\nAlex Freedland\nRob Hirschfeld\nVishvananda Ishaya\nMark McLoughlin\nMonty Taylor\nTroy Toman\n\nPlatinum Directors\n-----------------------------------------\nAlan Clark\nEileen Evans\nToby Ford\nChris Kemp\nVan Lindberg\nTodd Moore\nBrian Stevens\nJohn Zannos\n\nGold Directors\n-----------------------------------------\nSimon Anderson\nRandy Bias\nTristan Goode\nJoshua McKenty\nBoris Renski\nSean Roberts\nImad Sousou\nLew Tucker\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140117/0b2dd745/attachment.html>\n\n',NULL,NULL),('<06CAC436-2467-42E3-BF4B-D66EEA69655E@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-11 01:40:54',0,'2014-10-11 01:40:54',NULL,'[openstack-dev] Any ideas on why nova-novncproxy is failing to\n start on devstack?','Well, I deleted /usr/local/lib/python2.7/dist-packages/websockify* and then stacked and it worked!\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Oct 10, 2014, at 8:46 PM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n\n> I had a system with devstack, which I restack with reclone, with the intention of then patching in my review diffs to update and test. Well, the stack is failing in n-nonvc, with this message:\n> \n> openstack at devstack-33:~/devstack$ /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC & echo $! >/opt/stack/status/stack/n-novnc.pid; fg || echo \"n-novnc failed to start\" | tee \"/opt/stack/status/stack/n-novnc.failure\"\n> [1] 826\n> /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC\n> Traceback (most recent call last):\n>  File \"/usr/local/bin/nova-novncproxy\", line 6, in <module>\n>    from nova.cmd.novncproxy import main\n>  File \"/opt/stack/nova/nova/cmd/novncproxy.py\", line 29, in <module>\n>    from nova.console import websocketproxy\n>  File \"/opt/stack/nova/nova/console/websocketproxy.py\", line 110, in <module>\n>    websockify.ProxyRequestHandler):\n> AttributeError: \'module\' object has no attribute \'ProxyRequestHandler\'\n> n-novnc failed to start\n> \n> The websockify package is installed:\n> \n> openstack at devstack-33:~/devstack$ pip show websockify\n> ---\n> Name: websockify\n> Version: 0.5.1\n> Location: /usr/local/lib/python2.7/dist-packages\n> Requires: numpy\n> \n> However, the version required is:\n> \n> openstack at devstack-33:/opt/stack/nova$ grep websockify requirements.txt\n> websockify>=0.6.0,<0.7\n> \n> Any ideas why is does not have the right version and how to best correct?\n> \n> Thanks!\n> \n> \n> PCM (Paul Michali)\n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pcm_ (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141011/aad1a675/attachment.pgp>\n\n','<A61144FE-9C8F-4E56-BA6C-60E770B0A5EE@cisco.com>',NULL),('<06CB4D3D-3B0C-4A15-B71C-B774871CC3A9@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 20:49:16',36000,'2013-07-16 10:49:16',NULL,'[openstack-dev] [Keystone] Memcache user token index and PKI\n	tokens','\nHi Morgan,\n\nOn 16/07/2013, at 1:02 AM, Morgan Fainberg <m at metacloud.com> wrote:\n> On Mon, Jul 15, 2013 at 1:06 AM, Kieran Spear <kispear at gmail.com> wrote:\n> \n> Hi Kieran,\n> \n> I\'d be happy to help you with the backporting of this fix if you need any assistance.\n> \n> Here are some quick answers to your questions:\n> \n> 1. The individual tokens are stored in independent keys in their entirety, since the memcache backend replaces the SQL backend.  In the usertoken-<userid> we should only be storing the hashed value.  It looks like there is a bug there (I\'ll check and get a fix proposed in gerrit today to address this).\n\nThat\'s what it looks like. I\'ve pushed out a one-line fix to hash the token data on our cloud and it works well.\n\n> \n> 2.  There has been a lot of discussion on this topic and some other solutions have been proposed (such as use a clock-mechanism to expire tokens, etc).  However, to stay compatible with the current business logic, which requires the ability to revoke subsets of tokens for the user (instead. all tokens for the user on every change to the user\'s roles/project associations, etc), a list of current tokens for the user must be maintained.  Ideally, the token list shouldn\'t ever be massive, meaning the extra calls to memcache should be limited.  The general plan is to develop another approach to solve this issue without the need of keeping a user-token-list, but it just wasn\'t viewed as possible for Havana.  Checking the first two tokens wouldn\'t exactly solve the issue, as tokens can in theory be requested with varying expiration times; this means that tokens in the middle of the list could be expired whereas the tokens at the start of the list are invalid.\n\nThanks for your work in this area. Good point on the expiry times. I\'m probably guilty of premature optimisation here anyway. Will work on back porting this shortly.\n\nKieran\n\n> \n> Keeping the expiry time low is definitely a good idea.\n> \n> \n> Let me know if you want any further details.  I\'d be happy to elaborate / fill-in more.\n> \n> Cheers,\n> Morgan Fainberg\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130716/d2c66c19/attachment.html>\n\n','<CABEb+dRgh50=HVP9Dz9BEzKD6TBVQR8EB4AGR_gifJXJwB4N=Q@mail.gmail.com>',NULL),('<06d05c8b40e4dd069268347171e13799@japones.lsd.ufcg.edu.br>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-17 23:32:56',-10800,'2014-06-18 02:32:56',NULL,'[Openstack] How to specify networks for new instances using OCCI interface?','Hi everyone,\n\nI\'m working at a federation cloud project that must run on OpenStack \nclouds. Currently, one of the pre-requirements of this project is to use \nOCCI interface. We are developing this project using devstack \n(http://devstack.org/) with OCCI interface \n(https://github.com/tmetsch/occi-os) following instructions available \nhere.\n\nWe can create new instances using OCCI interface following instructions, \nbut, when there are more than one network at the new instance OpenStack \nproject, we can\'t. At this scenario, there was a HTTP Bad Request asking \nto use network ID. Then, we would like to know how to specify the \nnetworks for new instance using OCCI interface. Something similar to\n$nova boot --image <img> --flavor <flavor> --nic net-id=<net1-id> --nic \nnet-id=<net2-id> <vm-name>\n\nwhen using nova command line.\n\nThanks for help,\nGiovanni\n\n\n',NULL,NULL),('<06D2830D-C520-46F6-AD04-2E0020E3AC56@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-11 22:23:33',0,'2013-03-11 22:23:33',NULL,'[openstack-dev] glance db upgrades question','+1 -- Can\'t wait to talk about this more. This is a big blocker across all projects from a CI/CD standpoint.\n\n\nOn Mar 11, 2013, at 5:25 PM, Mark Washenberger <mark.washenberger at markwash.net> wrote:\n\n> Hi Tom,\n> \n> Unfortunately, Glance does not support rolling db upgrades. Actually,\n> I\'m not aware of any OpenStack project that supports such upgrades. So\n> far, I believe that deployments that require very high uptime are\n> advised to carefully manage and even at times rewrite the database\n> migrations.\n> \n> I\'m not happy with this situation, and supporting rolling upgrades in\n> Glance is on my personal roadmap. However, there are number of\n> difficult issues we need to tackle to make that work. First we\'ll need\n> to refactor the code away from the use of declarative sqlalchemy\n> models, towards an approach that allows the domain models and database\n> schemas to be versioned independently. Second, we\'ll need to come up\n> with a testing procedure that can enforce the practices that make\n> rolling upgrades possible. Last (that I know of) we\'ll need to figure\n> out a way to communicate the relative significance of each commit to\n> deployers, as each can have potentially different strategies for the\n> best way to distribute the change out into their cluster. If we do\n> eventually provide support for rolling upgrades, its going to be a\n> daunting task, made much harder by the variety of possible OpenStack\n> deployments that need to be considered.\n> \n> This is a subject I\'m very excited about. If there are others with\n> ideas for how we might make progress towards rolling upgrades, I\'m\n> very happy to brainstorm about ways to incorporate these ideas into\n> Glance. I anticipate adding support will be easier in Glance, due to\n> the relative simplicity of the project and its data model.\n> \n> Thanks,\n> markwash\n> \n> On Mon, Mar 11, 2013 at 4:55 AM, Hancock, Tom (HP Cloud Services)\n> <Tom.Hancock at hp.com> wrote:\n>> I?m happy to be corrected on this as I?m basing it on reading a diff, not an\n>> actual test.\n>> \n>> It looks like glance migration 19 could introduce a non backwards compatible\n>> change\n>> \n>> to the glance database. In principle, how should such an upgrade be managed?\n>> \n>> \n>> \n>> A ?rolling? upgrade would be an ideal way to minimize disruptive updates.\n>> \n>> It looks like there would need to be a bounce upgrade (stop the service on\n>> all nodes;\n>> \n>> upgrade sw; start service) as old and new db clients don?t look like they\n>> will co-exist.\n>> \n>> \n>> \n>> thanks,\n>> \n>> Tom\n>> \n>> \n>> \n>> ---\n>> \n>> Tomas Hancock, HP Cloud Services, Hewlett Packard, Galway. Ireland\n>> +353-91-754765\n>> \n>> Postal Address   : Hewlett Packard Galway Limited, European Software Centre,\n>> Ballybrit Business Park, Galway, Ireland\n>> Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson\'s\n>> Quay, Dublin 2 Registered Number: 361933\n>> \n>> The contents of this message and any attachments to it are confidential and\n>> may be legally privileged. If you have received this message in error you\n>> should delete it from your system immediately and advise the sender. To any\n>> recipient of this message within HP, unless otherwise stated, you should\n>> consider this message and attachments as \"HP CONFIDENTIAL\".\n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAJyP2C-heGHovqstL826R2oLSC7asc6rqLr6_swd-35g9UUwAQ@mail.gmail.com>',NULL),('<06D6C90C-1CFC-40BC-ACFF-E1D1E80CAE75@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-10 14:20:21',0,'2014-02-10 14:20:21',NULL,'[openstack-dev] [nova] Possible Hyper-V false CI failures','Here?s the Zuul error for this specific patch from the logs. Looks like Zuul reports back the ?please rebase? message independently from the error it encounters.\nGiven that, we?re looking into how to improve resiliency and error reporting. \n\nAlessandro\n\nOn 10 Feb 2014, at 12:45 , Gabriel Samfira <gsamfira at cloudbasesolutions.com> wrote:\n\n> 2014-02-09 20:09:12,190 INFO zuul.Gerrit: Updating information for 72197,1 \n> 2014-02-09 20:09:19,551 ERROR zuul.Merger: Unable to reset repo <zuul.merger.Repo object at 0x1617c10> \n> Traceback (most recent call last): \n>   File \"/usr/local/lib/python2.7/dist-packages/zuul/merger.py\", line 241, in mergeChanges \n>     repo.reset() \n>   File \"/usr/local/lib/python2.7/dist-packages/zuul/merger.py\", line 71, in reset \n>     self.update() \n>   File \"/usr/local/lib/python2.7/dist-packages/zuul/merger.py\", line 138, in update \n>     origin.update() \n>   File \"/usr/local/lib/python2.7/dist-packages/git/remote.py\", line 510, in update \n>     self.repo.git.remote(\"update\", self.name) \n>   File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 227, in <lambda> \n>     return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) \n>   File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 456, in _call_process \n>     return self.execute(call, **_kwargs) \n>   File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 377, in execute \n>     raise GitCommandError(command, status, stderr_value) \n> GitCommandError: \'git remote update origin\' returned exit status 1: ssh: connect to host review.openstack.org port 29418: Network is unreachable \n> fatal: The remote end hung up unexpectedly \n> error: Could not fetch origin\n\n\n\nOn 10 Feb 2014, at 04:21 , Alessandro Pilotti <apilotti at cloudbasesolutions.com> wrote:\n\n> Hi guys,\n> \n> \n> On 10 Feb 2014, at 03:59 , Jay Pipes <jaypipes at gmail.com> wrote:\n> \n>> On Sun, 2014-02-09 at 18:17 -0700, Christopher Yeoh wrote:\n>>> Hi,\n>>> \n>>> \n>>> I think  the hyper-v CI system is sometimes failing with this message\n>>> incorrectly:\n>>> \n>>> \"This change was unable to be automatically merged with the current\n>>> state of the repository. Please rebase your change and upload a new\n>>> patchset.\"\n>>> \n>>> \n>>> I only mention it because its the second time I\'ve seen it. An example\n>>> here:\n>>> \n>>> https://review.openstack.org/#/c/72197/\n>>> \n>>> \n>>> The changeset was made off a very fresh git update and there doesn\'t\n>>> appear to be any updates merged since then.  The last time this error\n>>> appeared for me the rebase had no conflicts and Jenkins did not have\n>>> any trouble testing the same patchset that the Hyper-V one failed to\n>>> merge.\n>> \n>> Yeah, it may not be a rebase issue at all. The problem may be that the\n>> failure-message setting on the Zuul pipeline that is being triggered or\n>> Jenkins Gerrit trigger plugin is set to the above message, regardless of\n>> whether the failure is indeed due to the failure of a rebase?\n>> \n> \n> Hi guys, looking into this. We had a similar issue some days ago due to a corrupted Nova local git repo, which clearly had nothing to do with a rebase. Checking out what?s going on this time.\n> \n>> Octavius, is it possible to pastebin your Zuul layout.yaml?\n>> \n> \n> Here?s the zuul layout that we?re using:\n> \n> https://github.com/cloudbase/ci-overcloud-init-scripts/blob/master/zuul_layout.yaml\n> \n>> Best,\n>> -jay\n>> \n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<A4AF6764-FA93-45B5-81E0-B66C4E774EFD@cloudbasesolutions.com>',NULL),('<06EA17A4-9F48-44F0-90D2-C916FE9673E8@yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 09:04:51',32400,'2013-08-07 00:04:51',NULL,'[Openstack] Quantum agent-list not present in Debian Grizzly\n	packages','Try ->     neutron agent-list\n\n\n\nOn 2013/08/07, at 5:20, \"guillaume at cheramy.name\" <guillaume at cheramy.name> wrote:\n\n> Hello,\n> \n>    I try too install Openstack Grizzly on Debian Wheezy serveurs with\n> http://archive.gplhost.com/debian repos. My installation is a 3 node\n> with OVS plugins like this :\n> https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst\n> \n> So when I arrive in last part, in network creation \"Add the router to\n> the running l3 agent \" the command quantum agent-list doesn\'t exist.\n> \n> Thanks for your help\n> -- \n>                         \'\'~``\n>                        ( o o )\n> +------------------.oooO--(_)--Oooo.---------------------+\n> | Guillaume Ch?ramy - Guidtz                             |\n> | French open source system administrator                |\n> | E-Mail : guillaume at cheramy.name                        |\n> | Website : http://blog.cheramy.name                     |\n> |                                                        |\n> |                    (   )                               |\n> +---------------------\\ (----(   )-----------------------+\n>                       \\_)    ) /\n>                             (_/\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<52015A85.7020404@cheramy.name>',NULL),('<06EF5418-B2BA-455D-830A-CA2D33E9B0C1@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 14:31:33',-14400,'2014-08-26 18:31:33',NULL,'[openstack-dev] [all] [ptls] The Czar system,\n	or how to scale PTLs','\nOn Aug 26, 2014, at 11:28 AM, Matthew Treinish <mtreinish at kortar.org> wrote:\n\n> On Tue, Aug 26, 2014 at 10:04:41AM -0400, Doug Hellmann wrote:\n>> \n>> On Aug 26, 2014, at 5:13 AM, Thierry Carrez <thierry at openstack.org> wrote:\n>> \n>>> OK, now that we have evacuated the terminology issue (we\'ll use liaison\n>>> or janitor or secretary, not czar), and side-stepped the offtopic\n>>> development (this is not about suppressing PTLs, just a framework to let\n>>> them delegate along predetermined lines if they want to)... which of\n>>> those unnamed roles do we need ?\n>>> \n>>> In the thread were mentioned:\n>>> - Bugs janitor (keep reported bugs under control)\n>>> - Oslo liaison (already in place)\n>>> - Security mule (VMT first point of contact)\n>>> - Release secretary (communication with integrated release management)\n>>> - Infrastructure contact (for gate and other infra issues)\n>>> - Docs lieutenant (docs point of contact)\n>>> \n>>> Anita mentioned the \"3rd party space\" person, but I wonder if it would\n>>> not be specific to some projects. Would it actually be separate from the\n>>> \"Infra contact\" role ?\n>>> \n>>> Do we need someone to cover the QA space ? Anything else missing ?\n>> \n>> It seems the QA team is also feeling pressure due to the growing community, so it seems wise to ensure every team has someone designated to help with coordinating work on QA projects.\n>> \n> \n> Yes I agree, I was actually planning to start a liaison (I guess I\'ll have to\n> come up with a different name...) system similar to oslo at some point soon. We\n> discussed it during the QA meeting last week. [1] My plan was actually going\n> to be starting a thread on that this week before Thierry beat me to it.\n\nIn the spirit of collaboration, the Oslo team is willing to share the term ?liaison? with the QA team if you would like to use it. ;-)\n\nDoug\n\n> \n> -Matt Treinish\n> \n> [1] http://eavesdrop.openstack.org/meetings/qa/2014/qa.2014-08-21-22.01.html\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20140826152813.GA13106@zgok>',NULL),('<06F0CFBB-0862-4BD6-89E4-77AF29AD69A7@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-04-24 18:21:15',7200,'2013-04-24 16:21:15',NULL,'[Openstack-operators] Distributed Filesystem','I feel you Jacob, \nLoring I had the exact same issue ! Using both Argonaut and Bobtail, on high I/O load the mount crashed the server - well the server wasn\'t crashing, the mount went crazy, and impossible to unmount the disk, kill the process, so I always ended up rebooting the nodes. What is interesting though is that the reason why it is not still considered as production-ready is because of the way metadata is currently implemented, rather than the code itself....\n\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 24 avr. 2013 ? 17:36, Lorin Hochstein <lorin at nimbisservices.com> a ?crit :\n\n> Razique:\n> \n> Out of curiosity, what kinds of problems did you see with CephFS? I\'ve heard it\'s not ready for production yet, but I haven\'t heard anybody talk about specific experiences with it.\n> \n> Lorin\n> \n> \n> On Sat, Apr 20, 2013 at 8:14 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n> Hi Paras, \n> that\'s the kind of setup I\'ve always seen myself. After unsuccessful tests with CephFS, I\'ll move to the following strategy:\n> - GlusterFS as a shared storage for the instances (check the official doc, we wrote about its deployment for OpenStack)\n> - Ceph cluster wit the direct RBD gateway from nova to RADOS\n> - Ceph cluster as well the imaging service (Glance)\n> \n> Some others use MooseFS as well the the stared storage (we wrote a deployment guide as well)\n> Best regards,\n> Razique\n> \n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 19 avr. 2013 ? 17:05, Paras pradhan <pradhanparas at gmail.com> a ?crit :\n> \n>> Well I am not sure if we would like to do it since it is marked as deprecated. So this is what I am thinking. For shared storage, I will be using glusterfs and use cinder just for extra block disk on the instances. This what the Openstack operators doing typically ? \n>> \n>> Thanks\n>> Paras.\n>> \n>> \n>> On Fri, Apr 19, 2013 at 12:10 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>> More infos here:\n>> http://osdir.com/ml/openstack-cloud-computing/2012-08/msg00293.html\n>> \n>> But I\'m not sure about the last updates - you can still use it at the moment \n>> Razique\n>> \n>> Razique Mahroua - Nuage & Co\n>> razique.mahroua at gmail.com\n>> Tel : +33 9 72 37 94 15\n>> \n>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>> \n>> Le 18 avr. 2013 ? 17:13, Paras pradhan <pradhanparas at gmail.com> a ?crit :\n>> \n>>> Regarding block migration, this is what confuses me. This is from the Openstack operations manual\n>>> \n>>> --\n>>> Theoretically live migration can be done with non-shared storage, using\n>>> a feature known as KVM live block migration. However, this is a littleknown feature in OpenStack, with limited testing when compared to live migration, and is slated for deprecation in KVM upstream.\n>>> --\n>>> \n>>> Paras.\n>>> \n>>> \n>>> On Thu, Apr 18, 2013 at 3:00 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>>> Sure :)\n>>> Great feedbacks around. Many technologies do pretty much everything on the paper - but I guess in the end it\'s more about if the tech. does the job and if it does it well.\n>>> For such critical implementation, reliable solution is a must-have - ie that have proven through years they can be used and are stable enough for us to enjoy our week-ends :)\n>>> \n>>> Razique\n>>> \n>>> Le 18 avr. 2013 ? 00:14, Paras pradhan <pradhanparas at gmail.com> a ?crit :\n>>> \n>>>> Thanks for the replies Razique. We are doing a test installation and looking for options for live migration. Looks like both cinder and shared file stirage are options. Among these two which one do you guys recommended considering the Cinder block will be typical lvm based commodity hardware.\n>>>> \n>>>> Thanks\n>>>> Paras.\n>>>> \n>>>> \n>>>> On Wed, Apr 17, 2013 at 5:03 PM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>>>> Definitely, use the \"--block_migrate\" flag along the nova migrate command so you don\'t need a shared storage.\n>>>> You can boot from Cinder, depending on which version of OPS you run \n>>>> \n>>>> Razique Mahroua - Nuage & Co\n>>>> razique.mahroua at gmail.com\n>>>> Tel : +33 9 72 37 94 15\n>>>> \n>>>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>>>> \n>>>> Le 17 avr. 2013 ? 23:55, Paras pradhan <pradhanparas at gmail.com> a ?crit :\n>>>> \n>>>>> Can we do live migration without using shared storage like glusterfs and using cinder to boot the volume from? \n>>>>> \n>>>>> Sorry little off topic \n>>>>> \n>>>>> Thanks\n>>>>> Paras.\n>>>>> \n>>>>> \n>>>>> On Wed, Apr 17, 2013 at 4:53 PM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>>>>> Many use either a proprietary backend or the good old LVM\n>>>>> I\'ll go with Ceph for it since there is a native integration between cinder/ nova-volume and Ceph\n>>>>> \n>>>>> Razique Mahroua - Nuage & Co\n>>>>> razique.mahroua at gmail.com\n>>>>> Tel : +33 9 72 37 94 15\n>>>>> \n>>>>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>>>>> \n>>>>> Le 17 avr. 2013 ? 23:49, Paras pradhan <pradhanparas at gmail.com> a ?crit :\n>>>>> \n>>>>>> What do people use for cinder?\n>>>>>> \n>>>>>> Thanks\n>>>>>> Paras.\n>>>>>> \n>>>>>> \n>>>>>> On Wed, Apr 17, 2013 at 4:41 PM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>>>>>> I was about to use CephFS (Bobtail) but the I can\'t resize the instances without having CephFS crashing.\n>>>>>> I\'m currently considering GlusterFS which not only provides great performance, it\'s also pretty much easy to administer  :)\n>>>>>> \n>>>>>> Le 17 avr. 2013 ? 22:07, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> a ?crit :\n>>>>>> \n>>>>>>> Glance and Nova with MooseFS.\n>>>>>>> Reliable, good performance and easy configuration.\n>>>>>>> \n>>>>>>> ---\n>>>>>>> JuanFra\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/4/17 Jacob Godin <jacobgodin at gmail.com>\n>>>>>>> Hi all,\n>>>>>>> \n>>>>>>> Just a quick survey for all of you running distributed file systems for nova-compute instance storage. What are you running? Why are you using that particular file system?\n>>>>>>> \n>>>>>>> We are currently running CephFS and chose it because we are already using Ceph for volume and image storage. It works great, except for snapshotting, where we see slow performance and high CPU load.\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-operators mailing list\n>>>>>>> OpenStack-operators at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-operators mailing list\n>>>>>>> OpenStack-operators at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-operators mailing list\n>>>>>> OpenStack-operators at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>>> \n>>>>>> \n>>>>> \n>>>>> \n>>>> \n>>>> \n>>> \n>>> \n>> \n>> \n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n> \n> \n> -- \n> Lorin Hochstein\n> Lead Architect - Cloud Services\n> Nimbis Services, Inc.\n> www.nimbisservices.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130424/2e70c0e8/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130424/2e70c0e8/attachment-0001.jpg>\n\n','<CADzpNMWM747CADS2GjgVZexJdhW_T9_xuyGBG6BCia6hzfy++w@mail.gmail.com>',NULL),('<06f101cdde97$49e3db70$ddab9250$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-20 13:49:21',14400,'2012-12-20 09:49:21',NULL,'[openstack-dev] [quantum][LBaaS] need to do corresponding\n	changes in LBaaS API doc','Sure Youcef, here\'s the list of updates:\n\n \n\n-          add default values for fields not specified while VIP creation\n\n-          add \"description\" and \"connection_limit\" fields with default\nvalues to the response of Create VIP Example\n\n-          add \"lb_method\" field to the request of Create Pool Example as it\nis required\n\n-          remove \"members\" filed from the request of Create Pool Example\n\n-          add \"health_monitors\" to the list of updatable attributes of a\npool\n\n-          remove \"List all Members of a specific Pool\" and \"List Health\nMonitors associated with a Pool\" REST calls from the API\n\n-          add \"pool_id\" to the must list when creating a member\n\n-          add appropriate values to the request of Associate Health\nMonitors with a Pool Example\n\n \n\nThanks,\n\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Wednesday, December 19, 2012 11:42 PM\nTo: Oleg Bondarev; OpenStack Development Mailing List\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do carresponding\nchanges in LBaaS API doc\n\n \n\nOleg,\n\n \n\nCan you outline what those changes are?\n\n \n\nThanks,\n\nYoucef\n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Wednesday, December 19, 2012 5:39 AM\nTo: Youcef Laribi; OpenStack Development Mailing List\nSubject: [openstack-dev][quantum][LBaaS] need to do carresponding changes in\nLBaaS API doc\n\n \n\nHi Youcef,\n\n \n\nNow after LBaaS API extension patch was merged we need to do several\ncorresponding changes in the API doc. \n\nI can do it if you provide me rights on editing the page\n(http://wiki.openstack.org/Quantum/LBaaS/API_1.0).\n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121220/224bdad6/attachment.html>\n\n',NULL,NULL),('<06fe01cbc56c$1a5b9320$4f12b960$@openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-05 13:37:19',-21600,'2011-02-05 19:37:19',NULL,'[Openstack-operators] Power saving','This should be turned in to a blueprint... we would need some BMC/IPMI\ninterfaces coded in to do this but once we have live migration in OpenStack\nit is a totally feasible feature (pending algorithms below but those should\nbe modular anyways). If you want to create a blueprint for it Mario/Ken feel\nfree, otherwise let me know and we can discuss it and I can put a blueprint\ntogether. It might not make cactus but it is a good enterprise level feature\nto have on the roadmap.\n\n-----Original Message-----\nFrom: openstack-operators-bounces at lists.openstack.org\n[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of Ken\nPepple\nSent: Saturday, February 05, 2011 1:27 PM\nTo: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Power saving\n\nOn Feb 5, 2011, at 4:00 AM, openstack-operators-request at lists.openstack.org\nwrote:\n> I have tried to find answer myself but I have not found it.\n> \n> I would like to build a cloud where several server are powered down \n> and I will power them on only on peak hours.\n> \n> I need that virtual machines migrate to new servers and the migrate \n> back when I power down them.\n> \n> Is it possible?\n\nWith the current OpenStack Bexar release, I don\'t think that is feasible.\n\nAssuming that your power down algorithm was something like:\n	1. find all hosts with < x runnning VMs (where x is threshold of VMs\nfeasible to migrate)\n	2. consolidate/migrate those VMs onto other hosts (chosen by load)\n	3. alert the scheduler that these VM-less hosts are powering down\n	4. power down the hosts\n\nWe would need the live migration feature\n(https://blueprints.launchpad.net/nova/+spec/cactus-migration-live) that is\ncoming in Cactus (April timeframe) and probably some changes to the\nscheduler (or maybe not ?) and instance monitor.  \n\nAnd, of course, we would need actually code the algorithm that I have above\n:)\n\n/k\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<5D183543-6146-448F-B7C5-70B1D6D8DD00@gmail.com>',NULL),('<06FF377397785A4781BD13272EBF3D58231D6DF1E3@HQ1-EXCH02.corp.brocade.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-25 12:36:41',-28800,'2014-02-25 20:36:41',NULL,'[OpenStack-Infra] Service Accound needed for CI (Brocade)','Hi,\n\nI need a service account for the CI Test Environment that will be used for Neutron/LBaaS.\n\nEmail Address to use for the System Account: pattabi.ayyasami at gmail.com<mailto:pattabi.ayyasami at gmail.com>\nUser Name: pattabi-ayyasami-ci\nLonger Account Name:  Brocade ADX CI\nIRC Handle: pattabi\nEmail Address: pattabi at brocade.com<mailto:pattabi at brocade.com>\n\nGerrit Public Key\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDXb9rpNNiA0NT/i8ryvmmwf6gpCbN/SvuIDXIEmJG7zRN/m8UuHkfxf7C7APz8ojjxM/xhBRUgI4JJLsIGymLo+U0eCfIvOwyuui+CO304oo88FvGDhsUJSMMrZ7lzPKl8bgC5ufyj4dVUl7kzBCBLMKhagAtwcPwaWNS4FSMPBQ== root at ubuntu-pattabi\n\nThanks.\nPattabi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140225/6ebb5352/attachment.html>\n\n',NULL,NULL),('<06FF377397785A4781BD13272EBF3D58231D6DFA0F@HQ1-EXCH02.corp.brocade.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-06 14:37:19',-28800,'2014-03-06 22:37:19',NULL,'[OpenStack-Infra] Service Accound needed for CI (Brocade)','\nHi,\n\nI had sent this email couple of weeks back requesting for a Service account. I plan to use this service account for setting up the CI Test Infrastructure that will be used for the Neutron/LBaaS.\nI have not heard any further updates on this.\nWill I be getting any confirmation email on this from the infra mailer?\n\nPlease help.\n\nThanks.\nPattabi\nFrom: Pattabi Ayyasami\nSent: Tuesday, February 25, 2014 12:37 PM\nTo: \'openstack-infra at lists.openstack.org\'\nSubject: Service Accound needed for CI (Brocade)\n\nHi,\n\nI need a service account for the CI Test Environment that will be used for Neutron/LBaaS.\n\nEmail Address to use for the System Account: pattabi.ayyasami at gmail.com<mailto:pattabi.ayyasami at gmail.com>\nUser Name: pattabi-ayyasami-ci\nLonger Account Name:  Brocade ADX CI\nIRC Handle: pattabi\nEmail Address: pattabi at brocade.com<mailto:pattabi at brocade.com>\n\nGerrit Public Key\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDXb9rpNNiA0NT/i8ryvmmwf6gpCbN/SvuIDXIEmJG7zRN/m8UuHkfxf7C7APz8ojjxM/xhBRUgI4JJLsIGymLo+U0eCfIvOwyuui+CO304oo88FvGDhsUJSMMrZ7lzPKl8bgC5ufyj4dVUl7kzBCBLMKhagAtwcPwaWNS4FSMPBQ== root at ubuntu-pattabi\n\nThanks.\nPattabi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140306/be966d70/attachment-0001.html>\n\n',NULL,NULL),('<070EAB0B-392B-43AC-A290-8FB8CA3F5889@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-28 12:55:11',-25200,'2014-07-28 19:55:11',NULL,'[Openstack-operators]\n	oslo.messaging.transport.DriverLoadFailure: Failed to load\n	transport driver \"rabbitmq\": No \'oslo.messaging.drivers\'\n	driver found, looking for \'rabbitmq\'','Let me rephrase that,\n?rpc_backend = rabbitmq? is wrong.\nJust take it out of your config to use the default nova.openstack.common.rpc.impl_kombu\n\nOn Jul 28, 2014, at 12:38 PM, Abel Lopez <alopgeek at gmail.com> wrote:\n\n> Based on other reports of this, It sounds like your distro might be missing kombu.\n> The error changzhi1990 reported seems like a typo (rabbit vs rabbitmq)\n> Try taking out rpc_backend from the conf, it should default to nova.openstack.common.rpc.impl_kombu\n> \n> On Jul 28, 2014, at 11:46 AM, Jeff Silverman <jeff at sweetlabs.com> wrote:\n> \n>> I have rabbitmq 3.3.4-1 running on all of my nodes, and I am getting the same error message that changzhi1990 at gmail reported July 17th, except that I am using the python nova-manage db sync nova command.\n>> \n>> root at controller1-prod.controller1-prod:~# python /usr/bin/nova-manage db sync nova\n>> Traceback (most recent call last):\n>>   File \"/usr/bin/nova-manage\", line 10, in <module>\n>>     sys.exit(main())\n>>   File \"/usr/lib/python2.6/site-packages/nova/cmd/manage.py\", line 1321, in main\n>>     config.parse_args(sys.argv)\n>>   File \"/usr/lib/python2.6/site-packages/nova/config.py\", line 38, in parse_args\n>>     rpc.init(cfg.CONF)\n>>   File \"/usr/lib/python2.6/site-packages/nova/rpc.py\", line 63, in init\n>>     aliases=TRANSPORT_ALIASES)\n>>   File \"/usr/lib/python2.6/site-packages/oslo/messaging/transport.py\", line 185, in get_transport\n>>     raise DriverLoadFailure(url.transport, ex)\n>> oslo.messaging.transport.DriverLoadFailure: Failed to load transport driver \"rabbitmq\": No \'oslo.messaging.drivers\' driver found, looking for \'rabbitmq\'\n>> root at controller1-prod.controller1-prod:~# \n>> \n>> root at controller1-prod.controller1-prod:~# nova-manage --version\n>> 2014.1.1\n>> root at controller1-prod.controller1-prod:~# \n>> \n>> ?The changes I made in /etc/nova./nova.conf file are:\n>> \n>> root at controller1-prod.controller1-prod:~# diff /etc/nova/nova.conf  /etc/nova/nova.conf_ORIGINAL\n>> 253c253\n>> < my_ip=controller1-prod.sea.opencandy.com\n>> ---\n>> > #my_ip=10.0.0.1\n>> 1129c1129\n>> < glance_host=controller1-prod.sea.opencandy.com\n>> ---\n>> > #glance_host=$my_ip\n>> 2044,2050c2044\n>> < vncserver_listen=controller1-prod.sea.opencandy.com\n>> < service_neutron_metadata_proxy = true\n>> < neutron_metadata_proxy_shared_secret = 4c2be21d2d4a879ab2569484b5ee589d6fe15524\n>> < rabbit_userid = RabbitMQ\n>> < rabbit_password = j6hpCDnMs7qjzw==\n>> < rabbitmq_hostname = controller1-prod.sea.opencandy.com\n>> < rpc_backend = rabbitmq\n>> ---\n>> > #vncserver_listen=127.0.0.1\n>> 2054c2048\n>> < #vncserver_proxyclient_address=controller1-prod.sea.opencandy.com\n>> ---\n>> > #vncserver_proxyclient_address=127.0.0.1\n>> 2481c2475\n>> < connection=mysql://nova:Ph1aizyAIAXZUPMhdLzvl8hs at controller1-prod.sea.opencandy.com/nova\n>> ---\n>> > #connection=mysql://nova:nova at localhost/nova\n>> 2693c2687\n>> < auth_host=controller1-prod.sea.opencandy.com\n>> ---\n>> > #auth_host=127.0.0.1\n>> 2737c2731\n>> < admin_password=CxRF7a7wYSzMvNyAFEqa8BKv\n>> ---\n>> > #admin_password=%SERVICE_PASSWORD%\n>> root at controller1-prod.controller1-prod:~# \n>> ?\n>> \n>> ?Thank you\n>> \n>> \n>> Jeff Silverman\n>> ?\n>> ?jeff at sweetlabs d0t c0m?\n>> \n>> \n>> -- \n>> Jeff Silverman\n>> Systems Engineer\n>> (253) 459-2318 (c)\n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140728/9a5f5a48/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140728/9a5f5a48/attachment.pgp>\n\n','<351F28B0-27CC-4BD9-BE60-851EA11288F8@gmail.com>',NULL),('<070f01cd7639$d9ff8ef0$8dfeacd0$@jp.nec.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-09 23:18:30',32400,'2012-08-09 14:18:30',NULL,'[openstack-dev] [Quantum]NEC OpenFlow Plugin: Agent and Packet\n	Filter','Hi all,\n\n\nI pushed NEC OpenFlow Plugin to gerrit.\nhttps://review.openstack.org/#/c/10664/\nI got some comments, and I\'m wondering next action. Comments are welcomed.\n\n[Agent or VIFDriver]\nThis plugin has an agent that corrects only port information. Another solution is plugin-specific VIFDriver/InterfaceDriver that\nplugs interface, gets port information and sends it to Quantum Server.\nThe reason why I modified agent: there are some discussions about plugging a network interface around F summit.  1. Plugin specific\ncodes should be separate from nova.  2. VIFDriver should be focused on only plugging (work something required to plug: e.g..\nVIFDriver for Cisco plugin finds which device to plug).\nBut, Ryu plugin has plugin-specific VIFDriver(and InterfaceDriver) that plugs VIF and corrects port information. It is similar to\nNEC Plugin\'s VIFDriver for Essex.  Is this acceptable?\nOr, plugin developer can choice it with considering trade-off between code separation and behavior simplification.\n\n[Packet Filter extension]\nThis patch includes a new extension \"Packet Filter\". It is intended to expose functionality of packet filtering provided by Trema\n(OpenFlow Controller). I put this extension for the following reasons:  1. This plugin for quantum v1.x (not in quantum tree)\nsupports packet filtering.  2. This will help baremetal people who cannot use netfilter(iptables) on nova-compute nodes.\nThis could be an element of Security Groups. I feel we need discussion including Security Group API in two points;\n1. What is the position of this extension? I think we need some \"Internal\" Security Group API for adopting a FW Appliance instead of\nnetfilter(iptables), and this extension could be a starting-point of the discussion.\n2. Is it acceptable that put this extension until Security Group API is ready? (This extension should be internal methods after\nSecurity Group API is ready.)\nShould I keep it in the patch or separate it and write new bp?\n\n\nThanks,\n\nRyota MIBU\n\n\n\n\n',NULL,NULL),('<07109C1E-07E9-45AE-9AD8-A585AB8D6F8C@triliodata.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-02 13:19:57',0,'2013-09-02 13:19:57',NULL,'[openstack-dev] Proposal for Raksha,\n a Data Protection As a Service project','I am not an expert in Heat but the way I understood the Heat project is that it is an orchestration layer that instantiate a composite application based on a template definition. The template may identify the vms, networks and storage resources needed to instantiate the composite application. Using the template, a tenant may instantiate one of more instances of composite application. \n\nBackup service such as Raksha has to backup composite application instances in their entirety. It can look into Heat meta data to understand the application definition and correctly backup the application.\n\n I am not sure Heat can manage individual application instances once they are created. I need to do more research on Heat, but I also defer comments to Heat experts.\n\nOther way to integrate Heat with Raskha is to make a backup policy part of Heat template and let Heat setup correct backup policy by calling Rakha Apis during composite application instantiation.\n\nThanks,\nMurali Balcha\n\nOn Sep 2, 2013, at 7:13 AM, \"Zane Bitter\" <zbitter at redhat.com> wrote:\n\n> On 01/09/13 23:11, Alex Rudenko wrote:\n>> Hello everyone,\n>> \n>> I would like to ask a question. But, first of all, I would like to say\n>> that I\'m new to OpenStack so the question might be irrelevant. From what\n>> I\'ve understood, the idea is to back up an entire stack including VMs,\n>> volumes, networks etc. Let\'s call the information about how these pieces\n>> are interconnected - a topology. This topology also has to be backed up\n>> along with VMs, volumes, networks, right? And then this topology can be\n>> used to restore the entire stack. As for me, it looks very similar to\n>> what the Heat project does. Am I right? So maybe it\'s possible to use\n>> the Heat project for this kind of backup/restore functionality?\n>> \n>> Best regards,\n>> Alex\n> \n> That\'s actually an excellent question.\n> \n> One of the things that\'s new in Heat for the Havana release is Suspend/Resume operations on stacks. Basically this involves going through the stack in (reverse) dependency order and calling suspend/resume APIs for each resource where that makes sense. Steve Hardy has written the code for this in such a way as to be pretty generic and allow us to add more operations quite easily in the future.\n> \n> So to the extent that you just require something to go through every resource in a stack in dependency order and call an *existing* backup API, then Heat could fit the bill. If you require co-ordination between e.g. Nova and Cinder then Heat is probably not a good vehicle for implementing that.\n> \n> cheers,\n> Zane.\n> \n> \n>> On Sun, Sep 1, 2013 at 10:23 PM, Giri Basava <giri.basava at triliodata.com\n>> <mailto:giri.basava at triliodata.com>> wrote:\n>> \n>>    Dear All,\n>> \n>>    This is a great discussion. If I understand this correctly, this is\n>>    a proposal for data protection as a whole for the OpenStack cloud,\n>>    however this is not yet an official \"incubation\" request. We are\n>>    having a good discussion on how we can better serve the adoption of\n>>    OpenStack.\n>> \n>>    Having said that, the proposal will reuse the existing API and\n>>    contributions by the community that are already in place. For\n>>    example, Catlin\'s point is very valid... the Cinder storage vendor\n>>    knows the best way to implement snapshots for their storage\n>>    platforms. No doubt, Raksha should be leveraging that IP. Similarly\n>>    Raksha will be leveraging Nova, Swift as well as Glance. Don\'t\n>>    forget Neutron.... networking is very critical part of data\n>>    protection for any VM or set of VMs.\n>> \n>>    No one project has one single answer for a comprehensive data\n>>    protection. The capabilities for backup and recovery exist in silos\n>>    in various projects...\n>> \n>>    1. Images are backed-up by Nova\n>>    2. Volumes are backed-up by Cinder\n>>    3. I am not aware of a solution that can backup network configuration.\n>>    4. Not sure if we have something that can backup the resources of a\n>>    VM ( vCPUs, Memory Configuration etc.)\n>>    5. One can\'t schedule and automate the above very easily.\n>> \n>>    Ronen\'s point about consistency groups is right on the mark. We need\n>>    to treat an application as an unit that may span multiple VMs, one\n>>    or more images and one or more volumes.\n>> \n>>    Just to reiterate, some form of these capabilities exist in the\n>>    current projects, however as a user of OpenStack, I may not have a\n>>    simple one click solution.\n>> \n>>    With this proposal, the ask is to engage in a discussion to address\n>>    the above use cases. IMHO we are on the right track with these\n>>    discussions. We will be submitting the code in few days and looking\n>>    forward for your feedback. I would also suggest a design summit\n>>    where we can flush out more details.\n>> \n>>    Regards,\n>>    Giri\n>> \n>>    -----Original Message-----\n>>    From: Avishay Traeger [mailto:AVISHAY at il.ibm.com\n>>    <mailto:AVISHAY at il.ibm.com>]\n>>    Sent: Saturday, August 31, 2013 10:53 PM\n>>    To: OpenStack Development Mailing List\n>>    Subject: Re: [openstack-dev] Proposal for Raksha, a Data Protection\n>>    As a Service project\n>> \n>>    +1\n>> \n>> \n>> \n>>    From:   Ronen Kat/Haifa/IBM at IBMIL\n>>    To:     OpenStack Development Mailing List\n>>                 <openstack-dev at lists.openstack.org\n>>    <mailto:openstack-dev at lists.openstack.org>>,\n>>    Date:   09/01/2013 08:02 AM\n>>    Subject:        Re: [openstack-dev] Proposal for Raksha, a Data\n>>    Protection As a\n>>                 Service project\n>> \n>> \n>> \n>>    Hi Murali,\n>> \n>>    Thanks for answering. I think the issues you raised indeed make\n>>    sense, and important ones.\n>> \n>>    We need to provide backup both for:\n>>    1. Volumes\n>>    2. VM instances (VM image, VM metadata, and attached volumes)\n>> \n>>    While the Cinder-backup handles (1), and is a very mature service,\n>>    it does not provide (2), and for Cinder-backup it does not make\n>>    sense to handle (2) as well.\n>>    Backup of VMs (as a package) is beyond the scope of Cinder, which\n>>    implies that indeed something beyond Cinder should take this task.\n>>    I think this can be done by having Nova orchestrate or assist the\n>>    backup, either of volumes or VMs.\n>> \n>>    I think that from a backup perspective, there is also a need for\n>>    \"consistency groups\" - the set of entities (volumes) that are\n>>    considered a single logical unit and should be backup together.\n>>    This logical consistency group could be larger than a VM, but a VM\n>>    is a good starting point.\n>> \n>>    In any case, we should adopt the \"off-load\" approach:\n>>    1. Handle application consistency issues using Nova as it manages\n>>    the VMs.\n>>    Add to Nova functionality to support live and consistent backup -\n>>    including orchestrating volume backup using Cinder 2. Have Cinder do\n>>    the volume \"backup\", and Cinder then can delegate the task to the\n>>    Storage/hypervisor or anyone else who provide a backup driver\n>> \n>>    While a new project is a neat package that addresses the issues, but\n>>    does it worth the work?\n>>    OpenStack projects are complex, and successful projects require a\n>>    lot of work and long-term maintenance, which is the real pain for\n>>    open source projects, as the team tend to be very dynamic.\n>> \n>>    My two cents is to adopt the \"nova-networking\" and \"nova-volume\"\n>>    approach, try to extend the current work within Nova and Cinder, and\n>>    if we find out it does not make sense anymore, explain the issues,\n>>    and split the work to a new project.\n>>    This way it, if a backup project is indeed needed, you already have\n>>    the community to support the effort, and you already have a mature\n>>    solution.\n>> \n>>    Regards,\n>>    __________________________________________\n>>    Ronen I. Kat\n>>    Storage Research\n>>    IBM Research - Haifa\n>>    Phone: +972.3.7689493 <tel:%2B972.3.7689493>\n>>    Email: ronenkat at il.ibm.com <mailto:ronenkat at il.ibm.com>\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<522472A2.70005@redhat.com>',NULL),('<07142DEF-6CE1-41BB-B6E7-F2C8B5A49701@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-11 05:34:28',-25200,'2013-10-11 12:34:28',NULL,'[openstack-dev] Newbie python novaclient question','Is that actually doing something or parsing the sub commands?\n\nI think after args is initialized it is probably the args.func calls that actually does something. For example the following line in the main:\n\nargs.func(self.cs, args) \n\nWhat do you think is the .func method?\n\nRegards\nAl\n\nOn Oct 11, 2013, at 3:07 AM, Noorul Islam K M <noorul at noorul.com> wrote:\n\n> Alex <la6470 at gmail.com> writes:\n> \n>> Yes , this method seems to look for the corresponding action but still doesn\'t seem to be the one actually calling them.\n>> \n> \n> Are you looking for this which is inside **main** method?\n> \n> args = subcommand_parser.parse_args(argv)\n> \n> Thanks and Regards\n> Noorul\n> \n>> Regards\n>> Al\n>> \n>> \n>> \n>> On Oct 10, 2013, at 11:07 PM, Noorul Islam K M <noorul at noorul.com> wrote:\n>> \n>>> Alex <la6470 at gmail.com> writes:\n>>> \n>>>> Thank you Noorul. I looked at the review. My question is that in openstackcomputeshell.main which line call the v1_1/ shell.py.<function>?\n>>>> \n>>> \n>>> I would look at get_subcommand_parser() method.\n>>> \n>>> Thanks and Regards\n>>> Noorul\n>>> \n>>>> \n>>>> \n>>>> On Oct 10, 2013, at 9:03 PM, Noorul Islam K M <noorul at noorul.com> wrote:\n>>>> \n>>>>> A L <la6470 at gmail.com> writes:\n>>>>> \n>>>>>> Dear Openstack Dev Gurus,\n>>>>>> \n>>>>>> I am trying to understand the python novaclient code. Can someone please\n>>>>>> point me to where in openstackcomputeshell class in shell.py does the\n>>>>>> actual function or class related to an argument gets called?\n>>>>>> \n>>>>> \n>>>>> This review [1] is something I submitted and it adds a sub command. May\n>>>>> be this will give you some clue.\n>>>>> \n>>>>> [1] https://review.openstack.org/#/c/40181/\n>>>>> \n>>>>> Thanks and Regards\n>>>>> Noorul\n\n\n','<87bo2wruhu.fsf@noman.maa.corp.collab.net>',NULL),('<071627B8-3D83-4AE5-ADD7-AC681050D260@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-27 08:48:39',-25200,'2014-10-27 15:48:39',NULL,'[Openstack-operators] Glance Image Upload error','This sounds like a packaging error. What linux distribution are you using?\nThe quick fix is to just install the oslo.config module manually, not sure why it wasn\'t included.\n\n`sudo pip install oslo.config` should help\n\n\nOn Oct 26, 2014, at 1:26 AM, mohib at qmail.com.bd wrote:\n\n> \n> Hi ,\n> \n> I am facing keystone configuration problem. My problem is give in bellow.\n> \n>  \n> keystone-manage pki_setup --keystone-user keystone --keystone-group keystone\n> Traceback (most recent call last):\n>   File \"/usr/bin/keystone-manage\", line 30, in <module>\n>     from keystone import cli\n>   File \"/usr/lib/python2.7/site-packages/keystone/cli.py\", line 19, in <module>\n>     from oslo.config import cfg\n> ImportError: No module named oslo.config\n> \n>  \n> Please help me for solution this problem.\n> \n> \n> Thanks\n> \n>  \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141027/cce95ac9/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141027/cce95ac9/attachment.pgp>\n\n','<6a96b3f46045474a3bd06b092571b6d4@qmail.com.bd>',NULL),('<0717177498c4b46292f765f0fb8a191c@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-31 14:09:13',10800,'2014-05-31 11:09:13',NULL,'[Openstack] Nova-network Bug??',' Hi!\n\n For some days now I am trying to figure out what is the problem and \n IceHouse instances don\'t get internet access (you can have a look here: \n https://www.mail-archive.com/openstack at lists.openstack.org/msg07138.html \n )\n\n Today I \'ve discovered that I have to put a NAT-firewall rule in the \n compute node every time I start an instance. The rule that is needed is:\n\n iptables -t nat -I POSTROUTING -o  eth0 -j MASQUERADE\n\n\n If I put the rule and then I start an instance then the instance \n doesn\'t have internet connectivity unless I put the rule again. The same \n applies if I start a second instance! All of them are loosing \n internet-connectivity. Putting the rule again and all of them are \n connected again. And the same happens again and again.\n\n Is this a bug somewhere??? Am I missing something??\n\n You all understand that it\'s not convenient at all to have to execute \n this every time an instance is started!\n\n Looking forward to hear your thoughts!\n\n Regards,\n\n\n G.\n\n-- \n\n\n',NULL,NULL),('<07195F7B-F45F-4C26-9532-67ACEF00A78E@gmail.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-25 17:55:50',-25200,'2013-04-26 00:55:50',NULL,'[openstack-tc] Reddwarf application for incubation','To your point, our first major, and majorly technically challenging implementation is MySQL. I totally agree that it is considerable work. :) I\'m also glad we agree in the vision of what it will be. I have always maintained at rackspace that this is a service for multiple data stores, and will continue to try my best to achieve this. \n\nTo the point of major architecture rewrite, I\'d like to say no, it won\'t be a complete overhaul, but as we know in software, no one can predict the future. I understand that seeing things like the cinder split semi-recently (in OpenStack terms of course) have been shown to cause considerable pain in the community. I also believe that there is interest to add other data stores from companies, soonish. In the grand scheme of things we are still, from an API perspective, a rather small service, and this contributes to our ability to be \"agile\" (so overloaded) in our approach to the design of more data stores without significant rewrites. \n\nFwiw, from a leadership perspective, I see the need to maintain a consistent API and to keep the pain of operation to a minimum. I have operators at rackspace that would not be happy with major rewrites and shifting dependencies, and it is my duty to serve them, and equally as much, all operators of this infrastructure as it grows and matures. \n\n/me apologizes for rambling a bit after a long few days at percona conf. I also love the conversation so far :)\n\nOn Apr 25, 2013, at 4:44 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:\n\n> Yeah, there?s definitely a big difference between DBaaS and MySQLaaS, though right now technically RedDwarf *is* the latter with future plans towards the former. The latter is immensely technically complicated and does warrant pause on the typical incubation question: ?Is the architecture likely to be massively refactored in the near-ish future??\n>  \n> I also like Monty?s points about installing OpenStack in terms of OpenStack, and providing the common tools developers need. I also can?t help but see the explosion of ?AWS has this so OpenStack should too? projects and wonder whether that?s a good model or not, but maybe that?s just me.\n>  \n> I appreciate the discussion so far,\n>  \n> -          Gabriel\n>  \n> From: Mark Washenberger [mailto:mark.washenberger at markwash.net] \n> Sent: Thursday, April 25, 2013 2:57 PM\n> To: openstack-tc at lists.openstack.org\n> Subject: Re: [openstack-tc] Reddwarf application for incubation\n>  \n> Ah, good to know. Thanks!\n>  \n> \n> On Thu, Apr 25, 2013 at 2:46 PM, Michael Basnight <mbasnight at gmail.com> wrote:\n> I\'d like to point out that reddwarf is meant to be seen as a database/datastore as a service, not hosted MySQL as a service. We are initially targeting MySQL due to its lion share of interest. \n>  \n> Being at the percona conference this week, we have gotten a ton of support/ feedback from implementers of solutions that fit on top of MySQL, and there is interest by companies such as tungsten, galera, percona, and Maria to help us define what it means to have a clusterable database solution, as well as a generic replication service. But by no means do we want to imply that this is a MySQL solution. We are trying to make a generic, operator configurable service that allows an installer to define what database as a service means for them.  We aren\'t picking a technology, persay, but instead enabling said technologies to reside in the common ecosystem. \n> \n> \n> Sent from my digital shackles\n> \n> On Apr 25, 2013, at 2:39 PM, Mark Washenberger <mark.washenberger at markwash.net> wrote:\n> \n> I\'m in much the same boat as Gabriel.\n>  \n> I would also ask, does it adversely affect other DBaaS projects built on top of OpenStack for RedDwarf to be part of OpenStack? In other core projects, we tend to use drivers to expose alternate implementations to try to be inclusive, does RedDwarf take a similar approach? What about other DBaaS projects that don\'t work principally through a MySQL interface? Please correct me if I\'m wildly mistaken about RedDwarf\'s implementation.\n>  \n> \n> On Thu, Apr 25, 2013 at 1:26 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:\n> I totally agree that the application deserves consideration by the TC.\n> \n> Throwing thoughts out there:\n> \n> RedDwarf strikes me as a project that is an important part of the OpenStack ecosystem, has significant value and the potential for significant adoption, yet perhaps is not appropriate for the scope of OpenStack proper...\n> \n> Since we\'re talking about Integrated Release and not \"Core\" doesn\'t it ultimately comes down to \"is RedDwarf of sufficient value and significance to justify the allocation of the limited resources of CI, Docs, Release Management, summit time, etc.?\" I have little doubt that RedDwarf is capable of matching the OpenStack release process and their code mostly looks sane. So this is more about whether this is an appropriate allocation of priority and impact on the ecosystem.\n> \n> I don\'t know that I have any answers here, but those are the ideas I\'m ruminating on.\n> \n>     - Gabriel\n> \n> > -----Original Message-----\n> > From: Monty Taylor [mailto:mordred at inaugust.com]\n> > Sent: Thursday, April 25, 2013 6:40 AM\n> > To: openstack-tc at lists.openstack.org\n> > Subject: Re: [openstack-tc] Reddwarf application for incubation\n> >\n> > I do not believe that we are waiting on anything from the BoD at the\n> > moment. The outcome of the IncUp joint subcommittee was to affirm the\n> > TC\'s power and oversight over deciding what goes into the Integrated\n> > Release. The committee, and then subsequently the TC and the BoD all were\n> > on board with that outcome.\n> >\n> > Effectively, this means that the responsibility for deciding the scope of the\n> > OpenStack Integrated Release falls on our shoulders as the technical\n> > leadership of the project. I think that\'s great.\n> >\n> > That said, it\'s entirely possible that we, as the TC, could develop a set of\n> > guidelines describing what we think OpenStack is and isn\'t ...\n> > but I don\'t think that\'s particularly necessary. OpenStack is what we say it is,\n> > and further its scope is the scope of the things that the community of\n> > participants show up to work on.\n> >\n> > I see no reason to not consider the reddwarf application on Tuesday.\n> >\n> > I will say, however, that given summit sessions, reddwarf is almost certainly\n> > going to need to change its name...\n> >\n> > On 04/25/2013 12:55 AM, John Dickinson wrote:\n> > > AFAIK, we have yet to receive any direction from the OpenStack BoD on\n> > > the question of the scope of OpenStack. As such, especially with\n> > > somethink like Red Dwarf which appears to be completely built on top\n> > > of existing OpenStack projects, should we wait to consider the\n> > > application?\n> > >\n> > > Perhaps having somewhat of a backup in incubation considerations will\n> > > put some pressure on the BoD to more quickly answer the \"what is\n> > > OpenStack\" question.\n> > >\n> > > --John\n> > >\n> > >\n> > >\n> > >\n> > > On Apr 22, 2013, at 5:16 AM, Thierry Carrez <thierry at openstack.org>\n> > > wrote:\n> > >\n> > >> Michael Basnight wrote:\n> > >>> The following wiki page has the Reddwarf database as a service\n> > >>> application for incubation. Thank you for your consideration!\n> > >>>\n> > >>> https://wiki.openstack.org/wiki/ReddwarfAppliesForIncubation\n> > >>\n> > >> Hi!\n> > >>\n> > >> I\'d like to give more time for the Technical Committee members to\n> > >> recover from the Summit and look into this, so we should consider\n> > >> this application at the meeting next week (April 30).\n> > >>\n> > >> In the mean time, could you repost your application for incubation\n> > >> link to the openstack-dev ML ASAP, so that it can openly be discussed\n> > >> there ?\n> > >>\n> > >> Thanks,\n> > >>\n> > >> -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee\n> > >>\n> > >> _______________________________________________ OpenStack-\n> > TC mailing\n> > >> list OpenStack-TC at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> > >\n> > >\n> > > _______________________________________________ OpenStack-\n> > TC mailing\n> > > list OpenStack-TC at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-TC mailing list\n> > OpenStack-TC at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> \n> \n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n>  \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n>  \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20130425/a4a582dc/attachment-0001.html>\n\n','<BD35DBE010D5B64589500D43F775F2365B327C57@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<071F926C-7746-45B7-BFB6-E60CD9298E9A@tenshu.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 22:43:31',0,'2014-01-07 22:43:31',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Hi\n\n> On 7 Jan 2014, at 22:18, Clint Byrum <clint at fewbar.com> wrote:\n> Packages do the opposite,\n> and encourage entropy by promising to try and update software \n\nBuilding with packages doesn\'t require updating running systems with packages and more than building with git requires updating running systems with git pull.\nOne can simply build (and test!) a new image with updated packages and rebuild/takeover nodes.\n\nCheers,\nChris\n\n','<1389131172-sup-9417@clint-HP>',NULL),('<0724FB3B-616B-45DE-B3C4-A1E10B8921C1@imaginary.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-16 18:57:15',-18000,'2012-08-16 23:57:15',NULL,'[openstack-dev] [Quantum] About XML support in Quantum v2 API','I would say the lack of XML support by default makes it half-baked.\n\n-George\n\nOn Aug 16, 2012, at 6:33 PM, Paul McMillan <Paul.McMillan at Nebula.com> wrote:\n\n> On 08/16/2012 04:20 PM, Edgar Magana (eperdomo) wrote:\n>> So, is there any rush on having XML support for Folsom? I would say NO.\n>> I think we should carefully review what we are supporting for Folsom\n>> because it?s going to be our ?debut? as core project and the last thing\n>> that we want is a service that offers a lot of features but with bugs.\n> \n> As Edgar said, it makes sense to add XML support when it\'s feature complete and stable, rather than rushing in a half-baked API which then must be supported.\n> \n> -Paul\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n--\nGeorge Reese (george.reese at imaginary.com)\nt: @GeorgeReese               m: +1(207)956-0217               Skype: nspollution\ncal: http://tungle.me/GeorgeReese   \n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120816/b0c6c98f/attachment.html>\n\n','<502D8356.2030905@Nebula.com>',NULL),('<0726A9CC-17CE-41D3-A778-8C278B32436E@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 13:22:06',-25200,'2013-07-10 20:22:06',NULL,'[openstack-dev] Distro defaults [was Re: [oslo.config] Config\n	files overriding CLI: The path of most surprise.]','\nOn Jul 10, 2013, at 5:01 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n\n> \n> \n> \n> On Tue, Jul 2, 2013 at 8:43 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> On Tue, 2013-07-02 at 17:48 +0000, Jeremy Stanley wrote:\n> > On 2013-07-01 15:10:26 -0700 (-0700), Mark Washenberger wrote:\n> > [...]\n> > > The talk about permanence confuses me, unless we mean that more\n> > > permanent values are overridden by less permanent ones.\n> > [...]\n> >\n> > I think the \"permanence\" counter argument (which I don\'t agree with,\n> > just recounting it for completeness) was that command-line arguments\n> > may be embedded in init scripts by some distributions and then\n> > administrators would be surprised when their modifications to the\n> > configuration files weren\'t respected.\n> \n> Yes, that was what the \"permanence\" discussion related to. The example I\n> was thinking of was \'--logfile /var/log/nova/api.log\' which doesn\'t seem\n> like a ridiculous thing to pass via the command line.\n> \n> Since we\'ve clearly moved on, I\'m not sure replaying old points is very\n> constructive, but you have hit on an interesting topic, so ... :)\n> \n> > Ultimately, however, any time\n> > distribution defaults which could be set in packaged configuration\n> > are instead being set with the service command-line in packaged init\n> > scripts, I would tend to just consider that a (serious) packaging\n> > bug and certainly nothing we should be catering to as a project.\n> \n> That\'s very ... stringent. But I do mostly agree. Distros shouldn\'t\n> stick a tonne of distro defaults on the command line of services.\n> \n> The two principles that matter IMHO are:\n> \n>   1) users should be able to override defaults\n> \n>   2) if a user deletes their config file, they get back to the defaults\n> \n> Something we\'ve experimented with in Red Hat OpenStack is to put distro\n> defaults in e.g. /usr/share/nova/nova-dist.conf. You can see some of the\n> thinking here, for example:\n> \n>   https://bugzilla.redhat.com/show_bug.cgi?id=887334#c4\n> \n> The alternative approach would be to patch the code with distro\n> defaults.\n> \n> Now, you could say that distros shouldn\'t need to modify the defaults.\n> That\'s fair, but I don\'t think there\'s anything too crazy in our distro\n> defaults either:\n> \n>   https://github.com/redhat-openstack/openstack-nova/blob/master/nova.conf\n> \n> \n> I took a look at those and most of the values you have are already the current defaults. The only one that stands out is:\n> \n> \n> force_dhcp_release = True\n> \n> So my question here, is do you think \'force_dhcp_release = False\' is a sane default or should the default be True like you have it?\n\nI would like to see this as True for sure. Historically it was was false because it requires a special binary from dnsmasq that wasn\'t packaged by the distros.\n\nVish\n\n> \n> \n> \n>  \n> Anyone got other thoughts on how distros should handle this?\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/525ffc65/attachment.html>\n\n','<CAHXdxOdM+0KcG4fMAKvE0h6FbW-__PTxZM8q7wW36z7-3zHTbg@mail.gmail.com>',NULL),('<0730F70F-553F-4238-942A-E4D93583BF81@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-23 20:23:17',-18000,'2014-11-24 01:23:17',NULL,'[openstack-dev] [oslo] Add a new aiogreen executor for Oslo\n	Messaging','\n> On Nov 23, 2014, at 7:55 PM, Mike Bayer <mbayer at redhat.com> wrote:\n> \n>> \n>> On Nov 23, 2014, at 7:30 PM, Donald Stufft <donald at stufft.io> wrote:\n>> \n>> \n>>> On Nov 23, 2014, at 7:21 PM, Mike Bayer <mbayer at redhat.com> wrote:\n>>> \n>>> Given that, I?ve yet to understand why a system that implicitly defers CPU use when a routine encounters IO, deferring to other routines, is relegated to the realm of ?magic?.   Is Python reference counting and garbage collection ?magic??    How can I be sure that my program is only declaring memory, only as much as I expect, and then freeing it only when I absolutely say so, the way async advocates seem to be about IO?   Why would a high level scripting language enforce this level of low-level bookkeeping of IO calls as explicit, when it is 100% predictable and automatable ?\n>> \n>> The difference is that in the many years of Python programming I?ve had to think about garbage collection all of once. I?ve yet to write a non trivial implicit IO application where the implicit context switch didn?t break something and I had to think about adding explicit locks around things.\n> \n> that?s your personal experience, how is that an argument?  I deal with the Python garbage collector, memory management, etc. *all the time*.   I have a whole test suite dedicated to ensuring that SQLAlchemy constructs tear themselves down appropriately in the face of gc and such: https://github.com/zzzeek/sqlalchemy/blob/master/test/aaa_profiling/test_memusage.py .   This is the product of tons of different observed and reported issues about this operation or that operation forming constructs that would take up too much memory, wouldn?t be garbage collected when expected, etc.  \n> \n> Yet somehow I still value very much the work that implicit GC does for me and I understand well when it is going to happen.  I don?t decide that that whole world should be forced to never have GC again.  I?m sure you wouldn?t be happy if I got Guido to drop garbage collection from Python because I showed how sometimes it makes my life more difficult, therefore we should all be managing memory explicitly.\n\nEh, Maybe you need to do that, that?s fine I suppose. Though the option isn?t between something with a very clear failure condition and something with a ?weird things start happening? error condition. It?s between ?weird things start happening? and ?weird things start happening, just they are less likely to happen less?. Implicit context switches introduce a new harder to debug failure mode over blocking code that explicit context switches do not.\n\n> \n> I?m sure my agenda here is pretty transparent.  If explicit async becomes the only way to go, SQLAlchemy basically closes down.   I?d have to rewrite it completely (after waiting for all the DBAPIs that don?t exist to be written, why doesn?t anyone ever seem to be concerned about that?) , and it would run much less efficiently due to the massive amount of additional function call overhead incurred by the explicit coroutines.   It?s a pointless amount of verbosity within a scripting language.  \n\nI don?t really take performance issues that seriously for CPython. If you care about performance you should be using PyPy. I like that argument though because the same argument is used against the GCs which you like to use as an example too.\n\nThe verbosity isn?t really pointless, you have to be verbose in either situation, either explicit locks or explicit context switches. If you don?t have explicit locks you just have buggy software instead.\n\n---\nDonald Stufft\nPGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n\n\n','<BCA7C5CB-DD43-442B-B95F-8AB24512BF8D@redhat.com>',NULL),('<0734a905cf3b4cde8a0c0b5b79eb9191@BY2PR05MB144.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 16:43:13',0,'2014-03-20 16:43:13',NULL,'[openstack-dev] Display images/icon in Horizon Tables','Thanks,\n\nThat worked perfectly.\n\nI defined a method like this:\n\ndef get_image_url(stack):\n    template_name = \'openwave/stack_catalogue/_icon.html\'\n    context = {\"stack\" : stack }\n    return template.loader.render_to_string(template_name, context)\n\nStack is my class that has a field called image_icon.\n\nWith in the _icon.html template, I simply wrote:\n<img src=\"{{stack.image_icon}}\"  alt=\"Application Icon\" height=\"42\" width=\"42\">\n\n\n________________________________________\nFrom: Lyle, David <david.lyle at hp.com>\nSent: 20 March 2014 15:45\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Display images/icon in Horizon Tables\n\nThis is easy to accomplish by creating a custom template for a cell.  In your table, instead of providing a data field for the column, provide a method name, have that method load a custom HTML template.\n\nHere is an example of this without an image of this method: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/tables.py#L653\n\nBut adding an <img> in the HTML template works fine.\n\nDavid\n\nFrom: Dave Johnston [mailto:Dave.Johnston at owmobility.com]\nSent: Thursday, March 20, 2014 9:20 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] Display images/icon in Horizon Tables\n\n?Hi,\n\nI\'m creating a custom panel for horizon.  I have developed a table that displays some information, and I would like to add a \'icon\' to each row.\nIdeally, I want to be able to specify the URL of a remote image, and have it displayed using the <img> tag.\n\nCan this be acheived with filters, or some other mechanism ?\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<4B426E467B8B9B41B25AC389B257C7CB4716828E@G9W0747.americas.hpqcorp.net>',NULL),('<0735CAAA-5C09-4E50-8942-04561135968D@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 22:56:12',21600,'2014-11-17 16:56:12',NULL,'[openstack-dev] [mistral] Team meeting minutes/log - 11/17/2014','Thanks for joining us today,\n\nHere are the links to the meeting minutes and full log:\nMinutes - http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-17-16.00.html <http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-17-16.00.html>\nFull log - http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-17-16.00.log.html <http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-17-16.00.log.html>\n\nThe next meeting will be next Monday Nov 24 at 16.00 UTC.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/d9093631/attachment.html>\n\n',NULL,NULL),('<073ca1d2688eb0e954b27706c0a767f0@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-12 08:25:19',7200,'2014-08-12 06:25:19',NULL,'[Openstack-docs] New blueprint: Reorganize gating-setup','Le 2014-08-11 14:01, Christian Berendt a ?crit?:\n> On 11/08/14 13:20, Andreas Jaeger wrote:\n>> And then you need to click on the link for details - like you do \n>> today -\n>> but also to read out which check failed,\n> \n> Is it possible to improve the output of the results? For example that \n> we\n> have a nice index page showing failed and passed tests with links\n> pointing to the logs for the specific tests.\n\nDoes this mean that results would not appear as gerrit comment (and \nmail) anymore? I really don\'t want to have to follow links from my mails \nor from the web UI to see the results of the build.\n\nThanks,\nGauvain\n\n\n','<53E8B092.7030809@b1-systems.de>',NULL),('<0744270B-2B05-4EC1-8A2B-075B51E2A112@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 12:21:54',-14400,'2014-09-03 16:21:54',NULL,'[openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x','\nOn Sep 3, 2014, at 11:57 AM, Clark Boylan <cboylan at sapwetik.org> wrote:\n\n> On Wed, Sep 3, 2014, at 08:22 AM, Doug Hellmann wrote:\n>> \n>> On Sep 2, 2014, at 3:17 PM, Clark Boylan <cboylan at sapwetik.org> wrote:\n>> \n>>> On Tue, Sep 2, 2014, at 11:30 AM, Yuriy Taraday wrote:\n>>>> Hello.\n>>>> \n>>>> Currently for alpha releases of oslo libraries we generate either\n>>>> universal\n>>>> or Python 2.x-only wheels. This presents a problem: we can\'t adopt alpha\n>>>> releases in projects where Python 3.x is supported and verified in the\n>>>> gate. I\'ve ran into this in change request [1] generated after\n>>>> global-requirements change [2]. There we have oslotest library that can\'t\n>>>> be built as a universal wheel because of different requirements (mox vs\n>>>> mox3 as I understand is the main difference). Because of that py33 job in\n>>>> [1] failed and we can\'t bump oslotest version in requirements.\n>>>> \n>>>> I propose to change infra scripts that generate and upload wheels to\n>>>> create\n>>>> py3 wheels as well as py2 wheels for projects that support Python 3.x (we\n>>>> can use setup.cfg classifiers to find that out) but don\'t support\n>>>> universal\n>>>> wheels. What do you think about that?\n>>>> \n>>>> [1] https://review.openstack.org/117940\n>>>> [2] https://review.openstack.org/115643\n>>>> \n>>>> -- \n>>>> \n>>>> Kind regards, Yuriy.\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> We may find that we will need to have py3k wheels in addition to the\n>>> existing wheels at some point, but I don\'t think this use case requires\n>>> it. If oslo.test needs to support python2 and python3 it should use mox3\n>>> in both cases which claims to support python2.6, 2.7 and 3.2. Then you\n>>> can ship a universal wheel. This should solve the immediate problem.\n>> \n>> That sounds like a good solution to that specific issue. It may also\n>> require changes in the application test suites, but those changes can be\n>> made as we move them to use oslotest.\n>> \n>>> \n>>> It has been pointed out to me that one case where it won\'t be so easy is\n>>> oslo.messaging and its use of eventlet under python2. Messaging will\n>>> almost certainly need python 2 and python 3 wheels to be separate. I\n>>> think we should continue to use universal wheels where possible and only\n>>> build python2 and python3 wheels in the special cases where necessary.\n>>> \n>>> The setup.cfg classifiers should be able to do that for us, though PBR\n>>> may need updating? We will also need to learn to upload potentially >1\n>> \n>> How do you see that working? We want all of the Oslo libraries to,\n>> eventually, support both python 2 and 3. How would we use the classifiers\n>> to tell when to build a universal wheel and when to build separate\n>> wheels?\n>> \n> The classifiers provide info on the versions of python we support. By\n> default we can build python2 wheel if only 2 is supported, build python3\n> wheel if only 3 is supported, build a universal wheel if both are\n> supported. Then we can add a setup.cfg flag to override the universal\n> wheel default to build both a python2 and python3 wheel instead. Dstufft\n> and mordred should probably comment on this idea before we implement\n> anything.\n\nOK. I?m not aware of any python-3-only projects, and the flag to override the universal wheel is the piece I was missing. I think there?s already a setuptools flag related to whether or not we should build universal wheels, isn?t there?\n\n>> \n>>> wheel in our wheel jobs. That bit is likely straight foward. The last\n>>> thing that we need to make sure we do is that we have some testing in\n>>> place for the special wheels. We currently have the requirements\n>>> integration test which runs under python2 checking that we can actually\n>>> install all the things together. This ends up exercising our wheels and\n>>> checking that they actually work. We don\'t have a python3 equivalent for\n>> \n>> We only know the wheels can be installed. We don?t actually have a test\n>> that installs our code and runs it any more (devstack uses ?develop? mode\n>> which bypasses some of the installation steps, as we found while fixing\n>> the recent neutron/pbr issue with a missing config file in their\n>> packaging instructions).\n>> \n> Yup, this would be a second level of testing that we should consider as\n> well. The post install can it do stuff test. We moved our unittesting\n> away from using sdist installs in preference for setup.py develop\n> equivalent which means that our unittests no longer cover some of this\n> stuff for us. Sorry if I hijacked this thread into a \"how do we test\n> release artifacts?\" thread.\n\nI wonder if we should have a flag in devstack to control whether we install in develop or ?regular? mode? That would let us test real installations, but still have editable versions for local developer systems.\n\n>> \n>>> that job. It may be better to work out some explicit checking of the\n>>> wheels we produce that applies to both versions of python. I am not\n>>> quite sure how we should approach that yet.\n>> \n>> To fix the asymmetric gating we have between pbr and everything else,\n>> Robert suggested setting up some sort of job to install pbr and then\n>> build and install a package for the project being tested. We already, as\n>> you point out, have a job that does this for all of the projects to test\n>> changes to pbr itself. Maybe we can run the same test under python 2 and\n>> 3 as part of the same job?\n>> \n> And to get that extra level of tested we can run the unittests in that\n> package install. We won\'t be able to run everything against python3\n> because of missing support (well we can test installs but the second\n> level testing will break if a project doesn\'t support python3 properly)\n> so we will need some way of selecting that. Using two jobs may be\n> simplest. But that is an implementation detail.\n\nIf we?re going to do that, we could also just have the test job remove the instruction in tox.ini to disable creating the sdist and installing the package.\n\nDoug\n\n>> \n>> Doug\n>> \n>>> \n>>> Clark\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1409759868.1760590.163203209.60DD5232@webmail.messagingengine.com>',NULL),('<074729CE-981E-443B-BDB2-AD543F5A8375@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 22:10:14',3600,'2013-08-06 21:10:14',NULL,'[openstack-dev] Change in openstack/keystone[master]: Implement\n	domain specific Identity backends','Hi Mark,\n\nOf particular interest are your views on the changes to keystone/common/config.py.  The requirement is that we need to be able to instantiate multiple conf objects (built from different sets of config files).  We tried two approaches to this:\n\nhttps://review.openstack.org/#/c/39530/11 which attempts to keep the current keystone config helper apps (register_bool() etc.) by passing on the conf instance, and\nhttps://review.openstack.org/#/c/39530/12 which removes these helper apps and just calls the methods on the conf itself (conf.register_opt())\n\nBoth functionally work, but interested in your views on both approaches.\n\nHenry\nOn 6 Aug 2013, at 19:26, ayoung (Code Review) wrote:\n\n> Hello Mark McLoughlin,\n> \n> I\'d like you to do a code review.  Please visit\n> \n>   https://review.openstack.org/39530\n> \n> to review the following change.\n> \n> Change subject: Implement domain specific Identity backends\n> ......................................................................\n> \n> Implement domain specific Identity backends\n> \n> A common scenario in shared clouds will be that a cloud provider will\n> want to be able to offer larger customers the ability to interface to\n> their chosen identity provider. In the base case, this might well be\n> their own corporate LDAP/AD directory.  A cloud provider might also\n> want smaller customers to have their identity managed solely\n> within the OpenStack cloud, perhaps in a shared SQL database.\n> \n> This patch allows domain specifc backends for identity objects\n> (namely User and groups), which are specified by creation of a domain\n> configuration file for each domain that requires its own backend.\n> \n> A side benefit of this change is that it clearly separates the\n> backends into those that are domain-aware and those that are not,\n> allowing, for example, the removal of domain validation from the\n> LDAP identity backend.\n> \n> Implements bp multiple-ldap-servers\n> \n> Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab\n> ---\n> M doc/source/configuration.rst\n> M etc/keystone.conf.sample\n> M keystone/auth/plugins/password.py\n> M keystone/catalog/backends/templated.py\n> M keystone/common/config.py\n> M keystone/common/controller.py\n> M keystone/common/ldap/fakeldap.py\n> M keystone/common/utils.py\n> M keystone/config.py\n> M keystone/identity/backends/kvs.py\n> M keystone/identity/backends/ldap.py\n> M keystone/identity/backends/pam.py\n> M keystone/identity/backends/sql.py\n> M keystone/identity/controllers.py\n> M keystone/identity/core.py\n> M keystone/test.py\n> M keystone/token/backends/memcache.py\n> M keystone/token/core.py\n> A tests/backend_multi_ldap_sql.conf\n> A tests/keystone.Default.conf\n> A tests/keystone.domain1.conf\n> A tests/keystone.domain2.conf\n> M tests/test_backend.py\n> M tests/test_backend_ldap.py\n> 24 files changed, 1,028 insertions(+), 372 deletions(-)\n> \n> \n> git pull ssh://review.openstack.org:29418/openstack/keystone refs/changes/30/39530/12\n> --\n> To view, visit https://review.openstack.org/39530\n> To unsubscribe, visit https://review.openstack.org/settings\n> \n> Gerrit-MessageType: newchange\n> Gerrit-Change-Id: I489e8e50035f88eca4235908ae8b1a532645daab\n> Gerrit-PatchSet: 12\n> Gerrit-Project: openstack/keystone\n> Gerrit-Branch: master\n> Gerrit-Owner: henry-nash <henryn at linux.vnet.ibm.com>\n> Gerrit-Reviewer: Brant Knudson <bknudson at us.ibm.com>\n> Gerrit-Reviewer: Dolph Mathews <dolph.mathews at gmail.com>\n> Gerrit-Reviewer: Jenkins\n> Gerrit-Reviewer: Mark McLoughlin <markmc at redhat.com>\n> Gerrit-Reviewer: Sahdev Zala <spzala at us.ibm.com>\n> Gerrit-Reviewer: SmokeStack\n> Gerrit-Reviewer: ayoung <ayoung at redhat.com>\n> Gerrit-Reviewer: henry-nash <henryn at linux.vnet.ibm.com>\n> \n\n\n\n\n','<1915BC70-BE87-488F-99F8-49473F49114E@linux.vnet.ibm.com>',NULL),('<07551B40-577D-4AE2-8771-290CA94A1C20@cgoncalves.pt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 17:19:51',0,'2014-02-17 17:19:51',NULL,'[openstack-dev] [Neutron] Group Policy questions','Hi,\n\nFirstly, I would like to thank you all for your replies!\n\nI am very much interested in taking some kind of participation on this subject, especially on service chain. I?m a entry-level guy on Neutron, but you can count on me to discuss and develop these BPs. Besides BP documents, I?ve been reading meeting logs and reviewing patches on Gerrit hoping to have a better understanding on where the group stands as of now.\n\nMy nickname on IRC is (surprise, surprise!) ?cgoncalves?.\n\nThanks,\nCarlos Goncalves\n\nOn 17 Feb 2014, at 07:10, Sumit Naiksatam <sumitnaiksatam at gmail.com> wrote:\n\n> Hi, Apologies for chiming in late on this. Yes, we have been\n> incubating the service insertion and chaining features [2] for some\n> time now. The plan was to have a FW-VPN chain working by Icehouse\n> release. Towards that end the first step was to introduce the notion\n> of a service insertion context which forms the foundation for the\n> service chain resource. The following patch aims to address the\n> service insertion context:\n> https://review.openstack.org/#/c/62599/\n> \n> and we hope to get the above merged into Icehouse. However, it does\n> not seem like we will be able to land the service chaining in\n> Icehouse. That said we are hoping to introduce WIP patches soon that\n> will implement the ideas so far discussed.\n> \n> We had regular IRC meetings earlier on the topic of \"advanced\n> services\", but we suspended those temporarily so as not to distract\n> from the Neutron stabilization and parity work underway in Icehouse.\n> We hope to get back to those meetings once the critical bugs and\n> features slated for Icehouse are out of the way.\n> \n> Per your question in the context of the Group Policy work, these two\n> features are indeed complementary. As pointed out in this thread, one\n> of the options for rendering the Groups Policies is on top of\n> elemental Neutron abstractions as service chains expressed in [2].\n> Also as pointed out in another email thread, we will specifically\n> touch on this topic in the upcoming Group Policy meetings.\n> \n> Thanks,\n> ~Sumit.\n> \n> \n> \n> On Wed, Feb 12, 2014 at 10:21 AM, Stephen Wong <s3wong at midokura.com> wrote:\n>> Hi Carlos,\n>> \n>> \n>> On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gon?alves <mail at cgoncalves.pt>\n>> wrote:\n>>> \n>>> Hi,\n>>> \n>>> I\'ve a couple of questions regarding the ongoing work on Neutron Group\n>>> Policy proposed in [1].\n>>> \n>>> 1. One of the described actions is redirection to a service chain. How do\n>>> you see BPs [2] and [3] addressing service chaining? Will this BP implement\n>>> its own service chaining mechanism enforcing traffic steering or will it\n>>> make use of, and thus depending on, those BPs?\n>> \n>> \n>>    We plan to support both specifying Neutron \"native\" service chain\n>> (reference [2] from your email below) as the object to \'redirect\' traffic to\n>> as well as actually setting an ordered chain of services specified directly\n>> via the \'redirect\' list. In the latter case we would need the plugins to\n>> perform traffic steering across these services.\n>> \n>> \n>>> 2. In the second use case presented in the BP document, \"Tired application\n>>> with service insertion/chaining\", do you consider that the two firewalls\n>>> entities can represent the same firewall instance or two running and\n>>> independent instances? In case it\'s a shared instance, how would it support\n>>> multiple chains? This is, HTTP(s) traffic from Inet group would be\n>>> redirected to the firewall and then passes through the ADC; traffic from App\n>>> group with destination DB group would also be redirected to the very same\n>>> firewall instance, although to a different destination group as the chain\n>>> differs.\n>> \n>> \n>>    We certainly do not restrict users from setting the same firewall\n>> instance on two different \'redirect\' list - but at this point, since the\n>> group-policy project has no plan to perform actual configurations for the\n>> services, it is therefore the users\' responsibility to set the rules\n>> correctly on the firewall instance such that the correct firewall rules will\n>> be applied for traffic from group A -> B as well as group C -> D.\n>> \n>> - Stephen\n>> \n>>> \n>>> \n>>> Thanks.\n>>> \n>>> Cheers,\n>>> Carlos Gon?alves\n>>> \n>>> [1]\n>>> https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction\n>>> [2]\n>>> https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering\n>>> [3]\n>>> https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAMWrLvi44pju_ZfPb2aMU--oaA8MtmLknm7au6fu9v2Pm8NpAA@mail.gmail.com>',NULL),('<075D59AC-F146-48A9-B9E2-DB9580085448@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-05-22 13:23:41',7200,'2013-05-22 11:23:41',NULL,'[Openstack-operators] Windows 2012 KVM Image Creation','thanks for that!\nLe 22 mai 2013 ? 12:55, Pedro Navarro P?rez <pednape at gmail.com> a ?crit :\n\n> Hi Jesse,\n> \n> Have you tried the \"official\" OpenStack Windows Server 2012 image from\n> cloudbase?\n> \n> http://www.cloudbase.it/ws2012/\n> \n> \n> On Wed, May 22, 2013 at 11:44 AM, Thomas Black <thomas at babelgeek.com> wrote:\n>> Hi Jesse\n>> \n>> Have you tried the \"stable\" virtio driver set, I\'ve also had issues with the\n>> \"latest\" set on older Windows versions:\n>> \n>> http://alt.fedoraproject.org/pub/alt/virtio-win/stable/\n>> \n>> -Thomas\n>> \n>> \n>> \n>> On Wed, May 22, 2013 at 11:40 AM, Jesse Pretorius\n>> <jesse.pretorius at gmail.com> wrote:\n>>> \n>>> On 22 May 2013 09:15, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>>>> \n>>>> Yah it worked here, I had to test a couple of drivers though, which\n>>>> version are you using?\n>>> \n>>> \n>>> I\'m trying to build Windows 2012 Standard Edition, for now.\n>>> \n>>> I\'ve been using the basic process used for Windows 2008:\n>>> \n>>> wget\n>>> http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/virtio-win-0.1-59.iso\n>>> \n>>> kvm-img create -f qcow2 WindowsServer2012StandardEdition.qcow2 20G\n>>> \n>>> kvm -m 4096 -cdrom WindowsServer2012Standard+DatacentreEdition.iso -drive\n>>> file=WindowsServer2012StandardEdition.qcow2,if=virtio -drive\n>>> file=virtio-win-0.1-59.iso,index=3,media=cdrom -net nic,model=virtio -net\n>>> user -nographic -vnc :10\n>>> \n>>> Using VNC, go through the installation process until you get to the hard\n>>> drive selection. No hard drives show, so use the \"Load Driver\" dialogue to\n>>> browse to E:\\WLH\\AMD64 for the VirtIO driver. Select the only driver that\n>>> shows: \"Red Hat VirtIO SCSI controller\".\n>>> \n>>> Continue the installation process until completion.\n>>> \n>>> That all works fine, but the NIC isn\'t operational. As soon as I try to\n>>> update the driver through the Device Manager the server crashes. When I did\n>>> manage to get through to browse, the drivers in E:\\WLH\\AMD64 didn\'t show\n>>> anything compatible.\n>>> \n>>> I\'m about to restart the process, but instead will be doing the initial\n>>> build with IDE and a standard NIC emulation. From there I\'ll add the drivers\n>>> and other useful mods using https://github.com/jordanrinke/openstack\n>>> \n>>> I\'m just hoping that someone who\'s successfully done this can share some\n>>> wisdom and shortcut my trial-and-error testing.\n>>> \n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<CAC-AF12aSHo2ORb9ttn8W4XO0A13d7M0JkXorhp_-xg9S4Kczw@mail.gmail.com>',NULL),('<07634B3F57AB49B6AC98F9CF77120603@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-17 10:10:44',-14400,'2012-07-17 14:10:44',NULL,'[openstack-dev] no-db-compute blueprint status?','> \n> Have you done anything on this since the initial draft you posted? \nNo.\n \n> My\n> major design concerns with this are:\n> \n> 1) How do you ensure that this new db service isn\'t a bottleneck?\n> \n> 2) If the answer to #1 is to allow running more than a single instance\n> of it, how do you ensure database updates are done in order?\n\n\nIt is certainly a best-practice to run more than a single instance of the daemon, I\'d even go so far as to say it would be necessary (especially if an eventlet threadpool was not re-introduced).\n\nUpdates would be implemented through rpc \'call\', which would provide synchronous writes from the perspective of the client making a series of related updates. Other cothreads and processes would already be lacking any guarantees of order amongst themselves, so I would see no difference there.\n\nRegards, \nEric Windisch\n\n\n\n','<50054745.4080209@redhat.com>',NULL),('<07643130-A0AE-4A11-AD01-4A94D097F53F@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 22:54:05',-25200,'2014-09-26 05:54:05',NULL,'[openstack-dev] [Manila] ./run_tests issue','On Sep 21, 2014, at 23:31, Deepak Shetty <dpkshetty at gmail.com> wrote:\n\n> Even better, whenever ./run_tests fail... maybe put a msg stating the following C libs needs to be installed, have the user check the same..something like that would help too.\n\nI don\'t think it should be a human-maintained list, otherwise it\'s prone to fall out of date or be incomplete in some way.\n\nFWIW, simply typing the error message in google and taking the first result e.g. \"fatal error: my_config.h: No such file or directory\" solves these obstacles in seconds, at least for me.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/5636e946/attachment.pgp>\n\n','<CAOXiiMnspufsZ+J5HOc7n9SPqML7RekjNhQReFMbd4ETaYmaPg@mail.gmail.com>',NULL),('<07744DAF-4245-4725-802D-F326ECA9551A@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 16:03:17',0,'2014-01-24 16:03:17',NULL,'[openstack-dev] [Horizon] Upstream help needed (django-compressor)','Hi All;\n\nJannis Leidel, author of Django-Compressor which Horizon relies on recently sent out a message saying that he needs help maintaining/releasing django_compressor:\n\nhttps://twitter.com/jezdez/status/423559915660382209\n\nIf we have people willing to help upstream dependencies, this would be a great place to help out. If you need help getting in contact with him let me know.\n\nJesse\n\n',NULL,NULL),('<07842C408EC94BF6AF01626D17E4D742@dewey.ws>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 10:41:33',-28800,'2015-01-27 18:41:33',NULL,'[openstack-dev] [Openstack-operators] [openstack-operators]\n [Keystone] flush expired tokens and moves deleted instance','This is one reason to use the memcached backend. Why replicate these tokens in the first place. \n\n\nOn Tuesday, January 27, 2015 at 10:21 AM, Clint Byrum wrote:\n\n> \n> Excerpts from Tim Bell\'s message of 2015-01-25 22:10:10 -0800:\n> > This is often mentioned as one of those items which catches every OpenStack cloud operator at some time. It\'s not clear to me that there could not be a scheduled job built into the system with a default frequency (configurable, ideally).\n> > \n> > If we are all configuring this as a cron job, is there a reason that it could not be built into the code ?\n> It has come up before.\n> \n> The main reason not to build it into the code as it\'s even better to\n> just _never store tokens_:\n> \n> https://blueprints.launchpad.net/keystone/+spec/non-persistent-tokens\n> http://git.openstack.org/cgit/openstack/keystone-specs/plain/specs/juno/non-persistent-tokens.rst\n> \n> or just use certs:\n> \n> https://blueprints.launchpad.net/keystone/+spec/keystone-tokenless-authz-with-x509-ssl-client-cert\n> \n> The general thought is that putting lots of things in the database that\n> don\'t need to be stored anywhere is a bad idea. The need for the cron\n> job is just a symptom of that bug.\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150127/15f28c5b/attachment.html>\n\n','<1422382664-sup-3287@fewbar.com>',NULL),('<078CB4DB-14D8-42AB-82F5-CDCCBB7E36F2@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 10:55:59',-18000,'2014-12-09 15:55:59',NULL,'[openstack-dev] new library oslo.context released','The Oslo team is pleased to announce the release of oslo.context 0.1.0. This is the first version of oslo.context, the library containing the base class for the request context object. This is a relatively small module, but we?ve placed it in a separate library so oslo.messaging and oslo.log can both influence its API without ?owning? it or causing circular dependencies.\n\nThis initial release includes enough support for projects to start adopting the oslo_context.RequestContext as the base class for existing request context implementations. The documentation [1] covers the basic API that is present now. We expect to find a few holes as we start integrating the library into existing projects, so liaisons please work with us to identify and plug the holes by reporting bugs or raising issues in #openstack-oslo.\n\nThere are a few more API additions planned for the library, but those will come later in the release cycle. Please see the spec for details if you are interested [2].\n\nThanks!\nDoug\n\n[1] http://docs.openstack.org/developer/oslo.context/\n[2] http://specs.openstack.org/openstack/oslo-specs/specs/kilo/graduate-oslo-context.html\n\n\n\n',NULL,NULL),('<078F41C1-0386-40CE-B75A-F846C9D8CB69@zeroaccess.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-04-10 02:55:42',0,'2011-04-10 02:55:42',NULL,'[Openstack-operators] *****SPAM***** Re: Swift - usage of JAVA apis\n	bindings from rackspace ??','Shashidhar,\n\nI\'m don\'t think the java-cloudfiles API currently works with openstack- \nswift authentication system. I tried to use the latest version 1.8.1  \nand also 1.8.0 but was encountering other problems that was  \nprohibiting me from even reaching my openstack-swift SAIO system.\n\nSo I decided to give it a try on an older version I already had  \ninstalled (1.5.3 ... I know it\'s old)  ...\n\nProblem #1 : Using SSL with java sucks ..\n	I didn\'t feel like troubleshooting java keytool, so I changed my SAIO  \nsetup to no longer use SSL in my proxy-server.\n\nProblem #2: Had to hack two files in order to make authentication work\n\nFILE #1 = src/main/java/com/rackspacecloud/client/cloudfiles/ \nFilesClient.java\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n377-openstack/src/main/java/com/rackspacecloud/client/cloudfiles/ \nFilesClient.java\n--- rackspace-java-cloudfiles-0ce9377/src/main/java/com/rackspacecloud/ \nclient/cloudfiles/FilesClient.java       2010-02-08 17:46:42.000000000  \n-0600\n+++ rackspace-java-cloudfiles-0ce9377-openstack/src/main/java/com/ \nrackspacecloud/client/cloudfiles/FilesClient.java     2011-04-09  \n21:36:32.110095891 -0500\n@@ -115,8 +115,10 @@\n          this.username = username;\n          this.password = password;\n          this.account = account;\n+\n          if (account != null && account.length() > 0) {\n-               this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\")+VERSION+\"/\"+account \n+FilesUtil.getProperty(\"auth_url_post\");\n+               this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\");\n+            this.username = account+\":\"+username;\n          }\n          else {\n                 this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\");\n@@ -192,7 +194,7 @@\n      {\n          this.account = account;\n          if (account != null && account.length() > 0) {\n-               this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\")+VERSION+\"/\"+account \n+FilesUtil.getProperty(\"auth_url_post\");\n+               this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\");\n          }\n          else {\n                 this.authenticationURL =  \nFilesUtil.getProperty(\"auth_url\");\n\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n\n\nFILE #2 = src/main/java/com/rackspacecloud/client/cloudfiles/ \nFilesResponse.java\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\ne9377-openstack/src/main/java/com/rackspacecloud/client/cloudfiles/ \nFilesResponse.java\n--- rackspace-java-cloudfiles-0ce9377/src/main/java/com/rackspacecloud/ \nclient/cloudfiles/FilesResponse.java     2010-02-08 17:46:42.000000000  \n-0600\n+++ rackspace-java-cloudfiles-0ce9377-openstack/src/main/java/com/ \nrackspacecloud/client/cloudfiles/FilesResponse.java   2011-04-09  \n20:56:22.826095729 -0500\n@@ -51,7 +51,8 @@\n         if (getStatusCode() == HttpStatus.SC_UNAUTHORIZED )\n                 return false;\n\n-       if (getStatusCode() == HttpStatus.SC_NO_CONTENT)\n+       /* Marcelo if (getStatusCode() == HttpStatus.SC_NO_CONTENT)     \n*/\n+       if (getStatusCode() == HttpStatus.SC_OK)\n                 return true;\n\n         return false;\n--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n\n\nOnce I was done with modifying the files I compiled it with \"ant  \ncompile\"\n\nThen I  created my \"cloudfiles.properties\" file\n----------------------------------------------------------------------------------------------\nversion=v1\nconnection_timeout=5000\n\n# Auth info\nauth_url=http://MY_IP_ADDRR:8080/auth/v1.0\nauth_token_name=X-Auth-Token\n#auth_user_header=X-Auth-User\n#auth_pass_header=X-Auth-Key\n----------------------------------------------------------------------------------------------\n\nThen I tested the java api using the run_cli.sh\n\nbtorch at stone:~/src/rackspace-java-cloudfiles-0ce9377-openstack$ bash  \nrun_cli.sh\nUsername: marcelo\nPassword: XXXXXXXXXX\nAccount (return if using Mosso directly): external\nLogged in!\nType \'help\' for assistance\nexternal: get\nThe account has 3 containers\n    glance\n    images\n    test\nexternal: head\nAccount information:\n   Number of Containers: 3\n     Total Account Size: 1938161664\n\nexternal: head glance\nInformation for glance\n   Object Count: 2\n     Total Size: 1,938,161,664 bytes\n....\n\n\n\nThen I ran the test unit... I also expected any CDN test units to fail  \nsince openstack-swift does not have CDN:\n\nbtorch at stone:~/src/rackspace-java-cloudfiles-0ce9377-openstack$ ant test\nBuildfile: build.xml\n\ninit:\n      [echo] -------------------------------------------------\n      [echo]            Building Cloudfiles\n      [echo] -------------------------------------------------\n\ncompile:\n      [echo] Compiling the source\n\ncompile-test:\n      [echo] Compiling the test source\n     [javac] Compiling 2 source files to /home/btorch/src/rackspace- \njava-cloudfiles-0ce9377-openstack/classes\n      [copy] Copying 2 files to /home/btorch/src/rackspace-java- \ncloudfiles-0ce9377-openstack/classes\n       [jar] Building jar: /home/btorch/src/rackspace-java- \ncloudfiles-0ce9377-openstack/dist/java-cloudfiles-test.jar\n\ntest:\n     [junit] Running  \ncom.rackspacecloud.client.cloudfiles.FilesClientTestCase\n     [junit] Testsuite:  \ncom.rackspacecloud.client.cloudfiles.FilesClientTestCase\n     [junit] Tests run: 38, Failures: 8, Errors: 0, Time elapsed:  \n30.824 sec\n     [junit] Tests run: 38, Failures: 8, Errors: 0, Time elapsed:  \n30.824 sec\n     [junit]\n     [junit] Testcase:  \ntestConstructor \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):         \nFAILED\n     [junit] expected:<...> but was:<baz:...>\n     [junit] junit.framework.ComparisonFailure: expected:<...> but  \nwas:<baz:...>\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase.testConstructor(FilesClientTestCase.java:49)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestNoArgConstructor \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):   FAILED\n     [junit] expected:<...> but was:<external:...>\n     [junit] junit.framework.ComparisonFailure: expected:<...> but  \nwas:<external:...>\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase.testNoArgConstructor(FilesClientTestCase.java:59)\n     [junit]\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestCDNContainerList \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):   FAILED\n     [junit] host parameter is null\n     [junit] junit.framework.AssertionFailedError: host parameter is  \nnull\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase.testCDNContainerList(FilesClientTestCase.java:1242)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestCDNContainerListLimitMarker \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):         \nFAILED\n     [junit] host parameter is null\n     [junit] junit.framework.AssertionFailedError: host parameter is  \nnull\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase \n.testCDNContainerListLimitMarker(FilesClientTestCase.java:1268)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestCDNContainerFullListing \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):    FAILED\n     [junit] host parameter is null\n     [junit] junit.framework.AssertionFailedError: host parameter is  \nnull\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase \n.testCDNContainerFullListing(FilesClientTestCase.java:1293)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestCDNContainerFullListingAll \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase): FAILED\n     [junit] host parameter is null\n     [junit] junit.framework.AssertionFailedError: host parameter is  \nnull\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles \n.FilesClientTestCase \n.testCDNContainerFullListingAll(FilesClientTestCase.java:1307)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestCDNApi \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):     FAILED\n     [junit] host parameter is null\n     [junit] junit.framework.AssertionFailedError: host parameter is  \nnull\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles.FilesClientTestCase.testCDNApi(FilesClientTestCase.java: \n1366)\n     [junit]\n     [junit]\n     [junit] Testcase:  \ntestURLs \n(com.rackspacecloud.client.cloudfiles.FilesClientTestCase):       FAILED\n     [junit] null\n     [junit] junit.framework.AssertionFailedError\n     [junit]     at  \ncom \n.rackspacecloud \n.client \n.cloudfiles.FilesClientTestCase.testURLs(FilesClientTestCase.java:1526)\n     [junit]\n     [junit]\n     [junit] Test  \ncom.rackspacecloud.client.cloudfiles.FilesClientTestCase FAILED\n\nBUILD SUCCESSFUL\nTotal time: 34 seconds\n\n-----\n\nbtorch at stone:~/src/rackspace-java-cloudfiles-0ce9377-openstack$ ant  \ntest-report\nBuildfile: build.xml\n\ninit:\n      [echo] -------------------------------------------------\n      [echo]            Building Cloudfiles\n      [echo] -------------------------------------------------\n\ncompile:\n      [echo] Compiling the source\n       [jar] Building jar: /home/btorch/src/rackspace-java- \ncloudfiles-0ce9377-openstack/dist/java-cloudfiles.jar\n\ncompile-test:\n      [echo] Compiling the test source\n\ntest-report:\n     [mkdir] Created dir: /home/btorch/src/rackspace-java- \ncloudfiles-0ce9377-openstack/testreport\n     [junit] Test  \ncom.rackspacecloud.client.cloudfiles.FilesClientTestCase FAILED\n[junitreport] Processing /home/btorch/src/rackspace-java- \ncloudfiles-0ce9377-openstack/testreport/TESTS-TestSuites.xml to /tmp/ \nnull971541946\n[junitreport] Loading stylesheet jar:file:/usr/share/ant/lib/ant- \njunit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit- \nframes.xsl\n[junitreport] Transform time: 1172ms\n[junitreport] Deleting: /tmp/null971541946\n\nBUILD SUCCESSFUL\nTotal time: 32 seconds\n\n\n\n\nI\'m not sure why the newer versions of the java-cloudfiles API were  \nfailing, perhaps I was doing something wrong! I hope this helps a bit  \nor perhaps sends you to the right track. If I have an update about  \njava-cloudfiles and openstack-swift compatibility I\'ll let you know.\n\n\n-\nMarcelo\n?Knowledge is the wings on which our aspirations take flight and soar.  \nWhen it comes to surfing and life if you know what to do you can do  \nit. If you desire anything become educated about it and succeed. ?\n\nOn Apr 6, 2011, at 1:53 AM, shashidhar v wrote:\n\n>\n> Hi,\n>\n> I am trying to build the \"rackspace-java-cloudfiles\" package (JAVA  \n> apis)  and run the unit tests ... but getting the errors\n>\n>\n>\n> [shashi at shashi rackspace-java-cloudfiles-1fb920d]$ cat src/test/ \n> resources/cloudfiles.properties\n>\n> # user properties\n> username=tester\n> password=testing\n> account=test\n>\n> # Auth Info, including two headers that can change for different  \n> auth services\n> #auth_url=http://test1:8080/auth/v1\n>\n> auth_token_name=X-Auth-Token\n> auth_url=http://192.168.62.63:8080/v1/AUTH_74ac0809-6c3f-4a0b-a6c8-6a664477b32a\n> auth_user_header=tester\n> auth_pass_header=testing\n> auth_user_header=X-Storage-User\n> auth_pass_header=X-Storage-Pass\n>\n> # cloudfs properties\n> version=v1\n> connection_timeout=15000\n>\n>\n>\n>\n>\n>\n> [shashi at shashi rackspace-java-cloudfiles-1fb920d]$ ant test\n> Buildfile: build.xml\n>\n> init:\n>      [echo] -------------------------------------------------\n>      [echo]            Building Cloudfiles\n>      [echo] -------------------------------------------------\n>\n> compile:\n>      [echo] Compiling the source\n>       [jar] Building jar: /home/shashi/Desktop/rackspace-java- \n> cloudfiles-1fb920d/dist/java-cloudfiles.jar\n>\n> compile-test:\n>      [echo] Compiling the test source\n>      [copy] Copying 1 file to /home/shashi/Desktop/rackspace-java- \n> cloudfiles-1fb920d/classes\n>       [jar] Building jar: /home/shashi/Desktop/rackspace-java- \n> cloudfiles-1fb920d/dist/java-cloudfiles-test.jar\n>\n> test:\n>     [junit] Running  \n> com.rackspacecloud.client.cloudfiles.FilesClientTestCase\n>     [junit] Testsuite:  \n> com.rackspacecloud.client.cloudfiles.FilesClientTestCase\n>     [junit] Tests run: 44, Failures: 42, Errors: 0, Time elapsed:  \n> 1.606 sec\n>     [junit] Tests run: 44, Failures: 42, Errors: 0, Time elapsed:  \n> 1.606 sec\n>     [junit]\n>     [junit] ------------- Standard Error -----------------\n>     [junit] java.lang.IllegalStateException: Target host must not be  \n> null, or set in parameters.\n>     [junit]     at  \n> org \n> .apache \n> .http \n> .impl \n> .client \n> .DefaultRequestDirector.determineRoute(DefaultRequestDirector.java: \n> 651)\n>     [junit]     at  \n> org \n> .apache \n> .http \n> .impl \n> .client.DefaultRequestDirector.execute(DefaultRequestDirector.java: \n> 353)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 641)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 576)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 554)\n>     [junit]     at  \n> com \n> .rackspacecloud.client.cloudfiles.FilesClient.login(FilesClient.java: \n> 278)\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles \n> .FilesClientTestCase.testUnicodeContainer(FilesClientTestCase.java: \n> 1401)\n>     [junit]     at  \n> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n>     [junit]     at  \n> sun \n> .reflect \n> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)\n>     [junit]     at  \n> sun \n> .reflect \n> .DelegatingMethodAccessorImpl \n> .invoke(DelegatingMethodAccessorImpl.java:25)\n>     [junit]     at java.lang.reflect.Method.invoke(Method.java:597)\n>     [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)\n>     [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)\n>     [junit]     at junit.framework.TestResult \n> $1.protect(TestResult.java:106)\n>     [junit]     at  \n> junit.framework.TestResult.runProtected(TestResult.java:124)\n>     [junit]     at junit.framework.TestResult.run(TestResult.java:109)\n>     [junit]     at junit.framework.TestCase.run(TestCase.java:120)\n>     [junit]     at junit.framework.TestSuite.runTest(TestSuite.java: \n> 230)\n>     [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant \n> .taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java: \n> 1245)\n>     [junit]     at  \n> org \n> .apache \n> .tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java: \n> 814)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java: \n> 1657)\n>     [junit]     at  \n> org \n> .apache \n> .tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java: \n> 765)\n>     [junit]     at  \n> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)\n>     [junit]     at  \n> sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)\n>     [junit]     at  \n> sun \n> .reflect \n> .DelegatingMethodAccessorImpl \n> .invoke(DelegatingMethodAccessorImpl.java:25)\n>     [junit]     at java.lang.reflect.Method.invoke(Method.java:597)\n>     [junit]     at  \n> org \n> .apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: \n> 105)\n>     [junit]     at org.apache.tools.ant.Task.perform(Task.java:348)\n>     [junit]     at org.apache.tools.ant.Target.execute(Target.java: \n> 357)\n>     [junit]     at  \n> org.apache.tools.ant.Target.performTasks(Target.java:385)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeTarget(Project.java:1298)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeTargets(Project.java:1181)\n>     [junit]     at org.apache.tools.ant.Main.runBuild(Main.java:698)\n>     [junit]     at org.apache.tools.ant.Main.startAnt(Main.java:199)\n>     [junit]     at  \n> org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)\n>     [junit]     at  \n> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)\n>     [junit] java.lang.IllegalStateException: Target host must not be  \n> null, or set in parameters.\n>     [junit]     at  \n> org \n> .apache \n> .http \n> .impl \n> .client \n> .DefaultRequestDirector.determineRoute(DefaultRequestDirector.java: \n> 651)\n>     [junit]     at  \n> org \n> .apache \n> .http \n> .impl \n> .client.DefaultRequestDirector.execute(DefaultRequestDirector.java: \n> 353)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 641)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 576)\n>     [junit]     at  \n> org \n> .apache \n> .http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java: \n> 554)\n>     [junit]     at  \n> com \n> .rackspacecloud.client.cloudfiles.FilesClient.login(FilesClient.java: \n> 278)\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles.FilesClientTestCase.testUnicode(FilesClientTestCase.java: \n> 1432)\n>     [junit]     at  \n> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\n>     [junit]     at  \n> sun \n> .reflect \n> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)\n>     [junit]     at  \n> sun \n> .reflect \n> .DelegatingMethodAccessorImpl \n> .invoke(DelegatingMethodAccessorImpl.java:25)\n>     [junit]     at java.lang.reflect.Method.invoke(Method.java:597)\n>     [junit]     at junit.framework.TestCase.runTest(TestCase.java:164)\n>     [junit]     at junit.framework.TestCase.runBare(TestCase.java:130)\n>     [junit]     at junit.framework.TestResult \n> $1.protect(TestResult.java:106)\n>     [junit]     at  \n> junit.framework.TestResult.runProtected(TestResult.java:124)\n>     [junit]     at junit.framework.TestResult.run(TestResult.java:109)\n>     [junit]     at junit.framework.TestCase.run(TestCase.java:120)\n>     [junit]     at junit.framework.TestSuite.runTest(TestSuite.java: \n> 230)\n>     [junit]     at junit.framework.TestSuite.run(TestSuite.java:225)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant \n> .taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java: \n> 1245)\n>     [junit]     at  \n> org \n> .apache \n> .tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java: \n> 814)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java: \n> 1657)\n>     [junit]     at  \n> org \n> .apache \n> .tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java: \n> 765)\n>     [junit]     at  \n> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)\n>     [junit]     at  \n> sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)\n>     [junit]     at  \n> sun \n> .reflect \n> .DelegatingMethodAccessorImpl \n> .invoke(DelegatingMethodAccessorImpl.java:25)\n>     [junit]     at java.lang.reflect.Method.invoke(Method.java:597)\n>     [junit]     at  \n> org \n> .apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: \n> 105)\n>     [junit]     at org.apache.tools.ant.Task.perform(Task.java:348)\n>     [junit]     at org.apache.tools.ant.Target.execute(Target.java: \n> 357)\n>     [junit]     at  \n> org.apache.tools.ant.Target.performTasks(Target.java:385)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeTarget(Project.java:1298)\n>     [junit]     at  \n> org \n> .apache \n> .tools \n> .ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)\n>     [junit]     at  \n> org.apache.tools.ant.Project.executeTargets(Project.java:1181)\n>     [junit]     at org.apache.tools.ant.Main.runBuild(Main.java:698)\n>     [junit]     at org.apache.tools.ant.Main.startAnt(Main.java:199)\n>     [junit]     at  \n> org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)\n>     [junit]     at  \n> org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)\n>     [junit] ------------- ---------------- ---------------\n>     [junit] Testcase:  \n> testLogin \n> (com.rackspacecloud.client.cloudfiles.FilesClientTestCase):       \n> FAILED\n>     [junit] null\n>     [junit] junit.framework.AssertionFailedError\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles.FilesClientTestCase.testLogin(FilesClientTestCase.java:68)\n>     [junit]\n>     [junit]\n>     [junit] Testcase:  \n> testAccountInfo \n> (com.rackspacecloud.client.cloudfiles.FilesClientTestCase):         \n> FAILED\n>     [junit] null\n>     [junit] junit.framework.AssertionFailedError\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles \n> .FilesClientTestCase.testAccountInfo(FilesClientTestCase.java:92)\n>     [junit]\n>     [junit]\n>     [junit] Testcase:  \n> testMultipleFilesNotThere \n> (com.rackspacecloud.client.cloudfiles.FilesClientTestCase):       \n> FAILED\n>     [junit] null\n>\n>  ===============\n> =======\n> =====\n>\n>\n>     [junit]\n>     [junit] Testcase:  \n> testFilesObjectPath \n> (com.rackspacecloud.client.cloudfiles.FilesClientTestCase):    FAILED\n>     [junit] null\n>     [junit] junit.framework.AssertionFailedError\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles \n> .FilesClientTestCase.testFilesObjectPath(FilesClientTestCase.java: \n> 1783)\n>     [junit]\n>     [junit]\n>     [junit] Testcase:  \n> testURLs \n> (com.rackspacecloud.client.cloudfiles.FilesClientTestCase):        \n> FAILED\n>     [junit] null\n>     [junit] junit.framework.AssertionFailedError\n>     [junit]     at  \n> com \n> .rackspacecloud \n> .client \n> .cloudfiles.FilesClientTestCase.testURLs(FilesClientTestCase.java: \n> 1826)\n>     [junit]\n>     [junit]\n>     [junit] Test  \n> com.rackspacecloud.client.cloudfiles.FilesClientTestCase FAILED\n>\n> BUILD SUCCESSFUL\n> Total time: 5 seconds\n> [shashi at shashi rackspace-java-cloudfiles-1fb920d]$\n>\n>\n> I was not clear about the properties to be set for running the \"unit  \n> tests\" of rackspace cloud files - java apis package , kindly help me  \n> for usage of java apis w.r.t swift\n>\n>\n> Thanks & Regards,\n> shashi\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- \n> operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110410/d483a734/attachment.html>\n\n','<BANLkTinR_kJdeH7PVo8RNhri39ttLHn6Hg@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA71F050BD0@INCHEAM-MBX02.ad.csscorp.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-29 07:21:26',0,'2012-07-29 07:21:26',NULL,'[OpenStack Foundation] [Openstack] Individual Member Elections','Hi,\n\nThe OpenStack Foundation has already attracted over 2,000 Individual Members in a little over a week. It\'s a very exciting moment for all of us involved in this effort, but also brings responsibility for each Individual and Corporate member.\n\nAwesome and kudos to everyone making it successful.\n\n\nWe\'ve learned that someone may have violated the basic principles that hold this community together by trying to affect the nominations for the Individual Member elections. This is not what our community stands for, and we do not want to let the actions of one or a few tarnish the reputation of the thousands of individuals who are working to make OpenStack a great place to develop open source software. We are so determined to uphold our values that every member--individual or corporate--agrees to a code of conduct that prohibits abusive behavior and attempts to manipulate our elections.\n\nOur bylaws and election process have been defined and overseen by very experienced, independent legal counsel, Mark Radcliffe. We are completely committed to ensuring this process is open, fair and legitimate in accordance with our bylaws and Delaware corporate law. To ensure that the process is open, fair and legitimate, we are looking for individuals who would like to volunteer to be inspectors through the duration of the election to certify the outcome along with our counsel. No more than two affiliated members (working for the same company) can be inspectors, and any candidates who wish to run for election are also ineligible to be inspectors. As stated in the bylaws, \"Each inspector, before entering upon the discharge of his duties, shall take and sign an oath to faithfully execute the duties of inspector with strict impartiality and according to the best of his ability.\" This will require a firm time commitment from any volunteers, as they will need to be available at a\n  number of points through the process to fulfill their duties in a timely manner. If you are interested in being an inspector, let me know.\n\nAny complaints or concerns about the election process are taken extremely seriously. Each complaint will be reviewed by our independent counsel and addressed or brought before the full Board at its first meeting as appropriate. To facilitate reporting we have created an email address that is received only by the Foundation\'s independent counsel for review: electionmonitor at openstack.org\n\nWe are also working on process improvements for nominations and elections--more details on that coming soon. In the meantime, please speak up or contact me or Mark Radcliffe directly if you have any concerns. We have all come a very long way in establishing the OpenStack Foundation--our Foundation--and are right on the threshold of having it up and running. Now is the time for us all to pull together and to make sure we continue to build the kind of inclusive, supportive community that has come so far in the last 2 years.\n\n+1\n\nCheers!!\n\nAtul Jha aka koolhead17\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<A4CFE554-80D8-4BB7-888D-F24939A2CF20@openstack.org>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73E26440C@INCHEAM-MBX02.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 05:55:05',0,'2012-11-05 05:55:05',NULL,'[openstack-dev] [Openstack] Announcing Moniker - DNS Services\n	for OpenStack','Awesome!!\n\n________________________________________\nFrom: openstack-bounces+atul.jha=csscorp.com at lists.launchpad.net [openstack-bounces+atul.jha=csscorp.com at lists.launchpad.net] on behalf of Kiall Mac Innes [kiall at managedit.ie]\nSent: Monday, November 05, 2012 5:45 AM\nTo: OpenStack Development Mailing List; openstack at lists.launchpad.net (openstack at lists.launchpad.net)\nCc: Galbraith, Patrick; tom_creighton at cable.comcast.com; monty.taylor at hp.com; Martin, JC\nSubject: [Openstack] Announcing Moniker - DNS Services for OpenStack\n\nHi all,\n\nMoniker has recently found a new home on StackForge, and has started generating some interest from the community - so - time for an official announcement!\n\nMoniker provides DNSaaS services for OpenStack:\n\n  *   REST API for domain/record management\n  *   Multi-tenant\n  *   Integrated with Keystone for authentication\n  *   Framework in place to integrate with Nova and Quantum notifications (for auto-generated records)\n  *   Support for Bind9 out of the box (Refactoring this to be more pluggable will be complete in the next few days)\n  *   .. I\'ve probably missed lot\'s more off this list!\n\nThe code is available via the StackForge GitHub organization[1], bugs are at launchpad[2] and (currently incomplete) docs are on pypi[3]. Contributions are welcome via the usual OpenStack methods i.e. Gerrit[4].\n\nFinally - We have our second weekly meeting scheduled for this Wednesday at 18:00 UTC in #openstack-meeting, anyone with an interest in DNSaaS is welcome to attend.\n\nThanks,\nKiall\n\n[1]: https://github.com/stackforge/moniker\n[2]: https://launchpad.net/moniker\n[3]: http://packages.python.org/moniker\n[4]: http://wiki.openstack.org/GerritWorkflow\n\nCheers!!\n\nAtul Jha\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CAGSj+QsE0hD7bTCDg6c3vuQ9pV0uRHPCsCwyuk2_FRH9XgyDnQ@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73E2794DD@INCHEAM-MBX02.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-11 08:56:59',0,'2012-11-11 08:56:59',NULL,'[openstack-dev] openstack dev','https://www.github.com/openstack\nhttps://docs.openstack.org\n________________________________________\nFrom: V?n Tu?n Nguy?n [contactnewsky at gmail.com]\nSent: Monday, October 29, 2012 11:56 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] openstack dev\n\ni\'m very interesting about  penstack. i\'m a developer\ni want to ask you some question about develope on openstack\nplease send to me code  document about openstack on window os/ linux os\n\nthanks  alot\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n','<CAG8-uHDZ7iyFzbQ=h-YWLJB=OMnBH4z6re6ztQqwed4R=5uxXA@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F91037E@INCHEAM-MBX02.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2012-12-11 19:13:15',0,'2012-12-11 19:13:15',NULL,'[openstack-community] How to start a community?','Sergios,\n\nGreat initiative.\nSo this is what most of us have done.\n\n1. Add your name and country to this list. http://wiki.openstack.org/OpenStackUserGroups?action=show&redirect=OpenStackUsersGroup\n2. Create a meetup page for specific country/region you want to start with.\n3. Social media twitter/linkedin/FB pages\n4. Spread the word about organizing meetup in the mailinglist.\n\n\n<SNIP>\nHello,\n\nI am from Cyprus and want to make a community based in Cyprus and in future expand it in Greece and Lebanon.\n\nHow can I do it? Please help me\n\nThank you,\nSergios Charalambous\n\n\nHope it helps.\n</SNIP>\n\nThanks.\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<DF15A9606AEA9A44A100A3C0824C37B51E900171@DB3PRD0104MB153.eurprd01.prod.exchangelabs.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F91C1F9@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2012-12-31 11:31:52',0,'2012-12-31 11:31:52',NULL,'[openstack-community] Hi','Hi,\n\n<snip>\nPlease let me know any community events which is going to conduct in Bangalore.\n\nI would like to join the community meeting\n\n</snip>\n\nhttp://www.meetup.com/Indian-OpenStack-User-Group\n\nSee you in our January meet up. :)\n\nCheers!!\n\nAtul Jha\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20121231/b960641c/attachment.html>\n\n','<CAK6Dtt_ayxuedgTa52KuKXmHM6KZmxEavufsd10AOe1_NASnWg@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F920E30@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-01-15 07:03:23',0,'2013-01-15 07:03:23',NULL,'[openstack-community] [Openstack] Calling all user group and\n meetup organizers','Hi All,\n\n<snip>\nHi,\nI am sorry that I may not able to join the meeting but the Hong Kong OpenStack User Group and Hong Kong Cyberport will be updating you any information if necessary.\n\nMay I have a bit comment on the following agenda:\n\nCan the Foundation start working with some Universities for meeting space, sponsorship, and student participation? Is the Foundation interested in Phd thesis sponsorship\nI strongly agree on this point, since there is getting more university students and researchers who starts to explore the open source cloud softwares as most commercial cloud softwares/services on market are really expensive for them to get start.   Also, university students and researchers are usually more sincere to explore the open source software because it is free and cloud computing is quite new for them.  And this is a good starting point to educate them to contribute to open source stuffs rather than just using it as freeware.\n\nShould there be an OpenStack user group and/or meetup approval process? How do we clean up user groups and meetups that are abandoned?\nI think there must be have an official central coordinator to manage all the user groups.\n\nThank you for the attention, and wish you all the best in year 2013.\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\nTel: +852 3166-3728\nFax: +852 3027-0099\n\n\nFrom: Sean Roberts [mailto:seanrob at yahoo-inc.com]\nSent: Tuesday, 15 January, 2013 07:26\nTo: OpenStack community; openstack\nCc: Rob_Hirschfeld at Dell.com; Kamesh_Pemmaraju at dell.com; Andi_Abes at dell.com; trevor.lowing at gmail.com; stephon.striplin at dreamhost.com; carlp at hq.newdream.net; brent.scotten at rackspace.com; kmestery at cisco.com; lloydostack at gmail.com; freedomhui at gmail.com; duyujie.dyj at gmail.com; santiagoc120 at outlook.com; sc360 at kent.ac.uk; mohamed at egyptcloudforum.com; Ilkka.Turunen at jamk.fi; berendt at b1-systems.de; Bruce Lok; marton.kiss at xemeti.com; deepakgarg.iitg at gmail.com; frans at meruvian.org; tim.horgan at cit.ie; fenris at ubuntu.com; mypapit at gmail.com; muharem at lbox.cc; hang.tran at dtt.vn\nSubject: Re: [openstack-community] Calling all user group and meetup organizers\n\nAgenda for tomorrow\'s user group / meetup planning meeting\n\n  *\n  *   Review of user group and meetup template\n  *   Meetups fit into the larger plan of user committee and summit to summit development how?\n  *   Where would be the location for social materials like videos, meetup logs, and other meeting related items?\n  *   Where do operators go to figure out how to run OpenStack in production?\n  *   Can the Foundation start working with some Universities for meeting space, sponsorship, and student participation? Is the Foundation interested in Phd thesis sponsorship?\n  *   If possible I like to get some supporters for a groups.openstack.org site, including content writers and some developer resources from the community. We have a lot of knowledge about running / starting an user group, and need to write it down, publish on the site and share it with newcomers.  I think this is answered by the user group template information that will be published to http://wiki.openstack.org/OpenStackUserGroups.\n  *   Should there be an OpenStack user group and/or meetup approval process? How do we clean up user groups and meetups that are abandoned?\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/14/13 2:07 PM, \"Sean Roberts\" <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\nReminder for the global user group planning meetup, tomorrow, Tuesday, 15 Jan 2012 11:00am to 1:00pm PST  http://www.meetup.com/openstack/events/93593062/\nJoin us!\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/9/13 1:05 PM, \"Tim Horgan\" <tim.horgan at cit.ie<mailto:tim.horgan at cit.ie>> wrote:\n\nHi S?an,\n\nI run the OpenStack Ireland meetup group, just wondering if your meeting is targeting only groups in the East Coast of the USA?\n\nKind Regards,\nTim\n\nOn 9 Jan 2013, at 00:54, Sean Roberts <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\n\nWe are going to have a planning meeting on Tuesday, 15 Jan 2012 11:00am to 1:00pm PST. RSVP via  http://www.meetup.com/openstack/events/93593062/  Connect remotely via webex https://yahoomeetings.webex.com/yahoomeetings/j.php?ED=160663792&UID=492396097&RT=MiM0\nIf this time doesn\'t work for you, get ahold of me directly via skype:seanroberts66, email, mobile, irc:sarob, twitter:sarob, or carrier pigeon.\n\nStefano and Thierry will be joining us. I want to get input from people that run user groups and meetups.\n\nSee you then!\n</snip>\n\nJust a request, everyone might not be able to attend the meeting, it will be nice if a MOM or recorded audio of the meeting is available somewhere to understand what all was discussed and roadmap for the same.\n\nAlso I would like to let you all  know about OpenStack India and activities we undertook over last one year or so.\n\nCurrent state\n\n1. Over 550 plus member\n2. Meetings happen every month in one of the cities in the country.\n3. Organized over  12 meetups &  mini-conf.\n\nReference : http://www.meetup.com/Indian-OpenStack-User-Group/\n\nThanks!!\n\nAtul Jha\nOne of the coordinator -- OpenStack India User Group.\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<0D8D9EBD1BBE224F8AEE23E5837A99C709812CAA@FSI-EX7.cyberport.hk>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F92A3ED@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-24 08:45:29',0,'2013-01-24 08:45:29',NULL,'[openstack-dev] Fw: performance evaluation of distributed\n storage	systems','Sogand,\n\nWhat tools/technology you used for this?\n\n\n________________________________________\nFrom: Sogand Shirinbab [sogand.shirinbab at bth.se]\nSent: Wednesday, January 23, 2013 4:46 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] Fw: performance evaluation of distributed storage      systems\n\n----- Forwarded by Sogand Shirinbab/Staff/BTH on 2013-01-23 12:16 -----\n\nFrom:        Sogand Shirinbab/Staff/BTH\nTo:        openstack at lists.launchpad.net\nDate:        2013-01-22 10:45\nSubject:        Fw: performance evaluation of distributed storage systems\n________________________________\n\n\n\n----- Forwarded by Sogand Shirinbab/Staff/BTH on 2013-01-22 10:45 -----\n\nFrom:        Sogand Shirinbab/Staff/BTH\nTo:        openstack at lists.launchpad.net\nDate:        2013-01-16 14:45\nSubject:        performance evaluation of distributed storage systems\n________________________________\n\n\n\nHi,\n\nI\'m a phd student and as a part of my research I\'ve compared performance of different distributed storage systems (Gluster, Openstack, Compuverde). I would like you as an expert in your product to give me feedback on my work. What do you think about the way we\'ve setup the system? does it affects the Openstack\'s swift performance?\n\nplease find my paper as attachment to this mail!\n\nBest Regards,\nSogandShirinbab\n\n\nBlekinge Tekniska H?gskolan\n371 79 Karlskrona\n0455 -385709\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<OFB9E6A6E2.E9530488-ONC1257AFC.003DEABD-C1257AFC.003DECDE@bth.se>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F92E659@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-02-06 07:59:30',0,'2013-02-06 07:59:30',NULL,'[Openstack-docs] Restructuring OpenStack-doc for Grizzly','Hi All,\n\nI had a suggestion and wanted to put forward.\n\nCurrently our complete doc structure looks like this\n\nInstalling OS\n       -- Contains install information on Ubuntu and Fedora\nRunning OS\n       -- Contains concepts about OS components and install steps as well for Debian/Suse/Ubunu/Fedora to some extent\nDeveloping OS\nOS CLI\nOS API\nGlossary\n\n\nWill it be good idea to restructure Running OS and Installing OS this way\n\nInstalling OS\n    -- On Ubuntu\n          -- Basic\n          -- Advanced\n\n    -- On Redhat/Centos/Fedora\n          -- Basic\n          -- Advanced\n   -- On Other OS\n          -- Basic\n          -- Advance\n\nToo an extent its already existing, my real concern is with the  \"Running OS\" part which has overlapping contents as in install instructions.\n\nKeeping Nova/Swift/Quantum guide with conf files and basic concepts behind it and updating it on regular basis will be much better. Lets take compute admin guide for example. I find it like having too much data and to an extent replication of our Install OS components in it.\n\nCompute administration guide\n       -- Concept of nova\n       -- Architecture\n       -- Hypervisor based config change\n       -- Available config flags\n\n\nWhat do you guys think?\n\nThanks!!\n\nAtul Jha\n@koolhead17\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n',NULL,NULL),('<0790F7C009AF7C40B43D459485FC7CA73F9303E7@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-02-11 07:38:33',0,'2013-02-11 07:38:33',NULL,'[Openstack-docs] Restructuring OpenStack-doc for Grizzly','Lorin,\n\nhttp://docs.openstack.org/folsom/openstack-compute/admin/content/ch_installing-openstack-compute.html\nhttp://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-openstack-compute-basics.html\n\n________________________________________\n\nFrom: Lorin Hochstein [lorin at nimbisservices.com]\nSent: Monday, February 11, 2013 3:38 AM\nTo: Atul Jha\nCc: openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Restructuring OpenStack-doc for Grizzly\n\nHi Atul:\n\n\nOn Wed, Feb 6, 2013 at 2:59 AM, Atul Jha <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>> wrote:\nHi All,\n\nI had a suggestion and wanted to put forward.\n\nCurrently our complete doc structure looks like this\n\nInstalling OS\n       -- Contains install information on Ubuntu and Fedora\nRunning OS\n       -- Contains concepts about OS components and install steps as well for Debian/Suse/Ubunu/Fedora to some extent\nDeveloping OS\nOS CLI\nOS API\nGlossary\n\n\nWill it be good idea to restructure Running OS and Installing OS this way\n\nInstalling OS\n    -- On Ubuntu\n          -- Basic\n          -- Advanced\n\n    -- On Redhat/Centos/Fedora\n          -- Basic\n          -- Advanced\n   -- On Other OS\n          -- Basic\n          -- Advance\n\nToo an extent its already existing, my real concern is with the  \"Running OS\" part which has overlapping contents as in install instructions.\n\nKeeping Nova/Swift/Quantum guide with conf files and basic concepts behind it and updating it on regular basis will be much better. Lets take compute admin guide for example. I find it like having too much data and to an extent replication of our Install OS components in it.\n\nCompute administration guide\n       -- Concept of nova\n       -- Architecture\n       -- Hypervisor based config change\n       -- Available config flags\n\n\nWhat do you guys think?\n\nCan you give an example of some content that currently is in the compute admin guide that you think shouldn\'t be there because of the overlap with the installation manuals?\n\nI\'m not opposed to a refactor on principle, but I also worry about users needing to jump around across many different manuals, because the current task they are trying to perform cuts across multiple doc guides. I think some content overlap might be unavoidable. If you could provide some specific examples about content that you recommend be removed from the admin guide, it would help me understand this better.\n\nTake care,\n\nLorin\n\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com<http://www.nimbisservices.com>\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CADzpNMWLrOBwvtU2G3aDeFasXTL7gO2YPhPrfU5BXGkkujA7Bg@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA73F9304C9@INCHEAM-MBX01.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-02-11 08:00:25',0,'2013-02-11 08:00:25',NULL,'[Openstack-docs] Git commit msg to list','Hi,\n\nIs there a way not to receive mails for every git commit in docs.\n\n\n\nThanks,\n\nAtul Jha\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n',NULL,NULL),('<0790F7C009AF7C40B43D459485FC7CA74D5EB5BC@INCHEAM-MBX02.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-02-19 08:33:20',0,'2013-02-19 08:33:20',NULL,'[Openstack-docs] Git commit msg to list','Tom,\nIt was DocImpact-triggered. I understood it after going through some of those as its needed for us in order to update our doc . :)\n\n\n________________________________________\nFrom: Tom Fifield [fifieldt at unimelb.edu.au]\nSent: Monday, February 18, 2013 6:41 AM\nTo: openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Git commit msg to list\n\nAtul,\n\nWere you referring to the watched projects, or the DocImpact-triggered\nresponses which get sent to this mailing list ?\n\nRegards,\n\nTom\n\nOn 12/02/13 00:52, Lorin Hochstein wrote:\n> Hi Atul:\n>\n> Assuming these emails are coming from gerrit, you can can configure\n> email notifications\n>\n> 1. Browse to https://review.openstack.org\n> 2. Click on \"Settings\" at the top-right\n> 3. Click on \"Watched Projects\" from the left menu\n> 4. Uncheck the email notifications that you don\'t want\n>\n> I don\'t think you can selectively turn off the commit-related emails,\n> but you can turn off \"All comments\".\n>\n> Take care,\n>\n> Lorin\n>\n>\n>\n> On Mon, Feb 11, 2013 at 3:00 AM, Atul Jha <Atul.Jha at csscorp.com\n> <mailto:Atul.Jha at csscorp.com>> wrote:\n>\n>     Hi,\n>\n>     Is there a way not to receive mails for every git commit in docs.\n>\n>\n>\n>     Thanks,\n>\n>     Atul Jha\n>     http://www.csscorp.com/common/email-disclaimer.php\n>\n>     _______________________________________________\n>     Openstack-docs mailing list\n>     Openstack-docs at lists.openstack.org\n>     <mailto:Openstack-docs at lists.openstack.org>\n>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n>\n>\n>\n> --\n> Lorin Hochstein\n> Lead Architect - Cloud Services\n> Nimbis Services, Inc.\n> www.nimbisservices.com <http://www.nimbisservices.com>\n>\n>\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n\nCheers!!\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<51217FCD.6000401@unimelb.edu.au>',NULL),('<0790F7C009AF7C40B43D459485FC7CA74D61B058@INCHEAM-MBX101.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-03-19 04:30:09',0,'2013-03-19 04:30:09',NULL,'[openstack-community] New OpenStack Venezuela User Group','Hi,\n\n<snip>\nHello,\n\nWe are deploying the first Private Open Cloud using OpenStack in Venezuela. 5 Cisco UCS (2x10 core and 128 GB RAM) + 20 TB on Netapp to store Images and VM (using live migration).\n\nWith OpenStack we are going to get reduce highly the lapse between a Virtual Machine is requested and the VM is delivered.\n\nMy team and I have been working hard to learn from scratch about OpenStack. We started our lab using Essex over 3 servers, first with ubuntu 12.04 and later with Centos 6 . When Folsom came out in October 2012 we reconfigured the lab to implement Quantum (to replace the nova-network).\n\nWe presented the project to our staff (Manager and Coordinators) and they approved to deploy the cloud in our company. At this time, we have ready and automated the Operative System and OpenStack installation through scripts and the plan to configure and deploy a production enviroment has begun.\n\nAlso, we\'ve started the Venezuela OpenStack User Group because want to share our knowledment and experience but need to know how or some help to include the group inside https://wiki.openstack.org/wiki/OpenStack_User_Groups\n\nWe have:\n\nGoogle+\n\nhttps://plus.google.com/communities/118105990522935078913\n\ntweeter: @openstackve\n\nGoogle Groups\n\nhttps://groups.google.com/d/forum/openstack-ve\n\nAlso, we reserve the domain openstack.org.ve<http://openstack.org.ve>.  The next step will be hire a web server and with help of the Venezuelan\'s community to keep growing the group)\n\n\nThis project and the Venezuela Group is a big and good challenge.\n\nIng. Ender Mujica.\nEmail:  emujicad at gmail.com<http://gmail.com>\n</snip>\n\nGreat initiative, looking forward to know more about it.\nLet us know how we can help.\n\nCheers!!\n\nAtul Jha\n\n@koolhead17\n\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CAOehM_Vxo6fHxGbVco_d89QFc1cjXqyV_6qaz75Ck7rY2W9gFA@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA74D61DB76@INCHEAM-MBX101.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-03-26 11:20:06',0,'2013-03-26 11:20:06',NULL,'[openstack-community] Openstack user group in Singapore','Billy,\n\nThis link has the info you are looking for https://wiki.openstack.org/wiki/OpenStackUserGroups/HowTo\n\n<snip>\n\nHi Everyone ,\n\n                   I would like to know if there is any openstack user group in Singapore? I can\'t seem to be able to find one on the wiki. If not, how can I go about starting one? Thanks!\n\nRegards\nBilly\n\n</snip>\n\nLooking forward to see the first OpenStack meetup in Singapore. :)\n\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CAJ_FNV5PXz8Ju0xLsyXbhVS0uqG6hB8was+-_9s3dK3db4o3Kw@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA74D61DBA2@INCHEAM-MBX101.ad.csscorp.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-03-26 12:41:58',0,'2013-03-26 12:41:58',NULL,'[openstack-community] Openstack user group in Singapore','Billy,\n\n<snip>\n\nThanks Atul. How can i go about starting one? Do i have to register at a site or must have a specific domain name or such rules?\n</snip>\n\nWe for India group created a meetup page which solves almost all of our needs apart from that we have social media presence on twitter/Fb/G+/Linkedin\n\nAfter that we added out community list with contact persons in here https://wiki.openstack.org/wiki/OpenStack_User_Groups\n\nLet me know if that helps.\n\n\n\nThanks!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CAJ_FNV7PvOYCN6fo0gh8-kJ+3nsXkXOKcHbu91Ers2CkNXsT1g@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7525A057B@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 21:07:10',0,'2013-05-09 21:07:10',NULL,'[openstack-dev] graph rendering problem in openstack doc','Yun,\n\n<snip>\n\nHi,\n\nit seems that the doc engine stops rendering digraph anymore.. Here is one example:\n\nhttp://docs.openstack.org/developer/nova/devref/vmstates.html\n\nIt used to have a graph rendered based on graphviz I believe. Does anyone know what happened? Is it possible to get it back? Thanks,\n\nYun\n\n</snip>\n\nIts rendering well for me, am using chrome. Kindly check your browser cache & see if it works.\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CADcnTpvN486vPghE3+VACA00Jek9C5t_FN-A7sMfm5f=6J2CiA@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7525A05BD@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 21:25:49',0,'2013-05-09 21:25:49',NULL,'[openstack-dev] graph rendering problem in openstack doc','Yun,\n\nI wish i had access to your network & system, since i don`t have that i am attaching the screenshot for.\nLet me know if it helps.\n\nCheers!!\n\nAtul\n________________________________________\nFrom: Yun Mao [yunmao at gmail.com]\nSent: Friday, May 10, 2013 2:48 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] graph rendering problem in openstack doc\n\nHi Atul,\n\nthere are about 5 graphs in the page. Only the first graph is rendered by graphviz. Others are just png files which look fine. I tried multiple browsers and no cache it still doesn\'t work for me. :(\n\nYun\n\n\nOn Thu, May 9, 2013 at 5:07 PM, Atul Jha <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>> wrote:\nYun,\n\n<snip>\n\nHi,\n\nit seems that the doc engine stops rendering digraph anymore.. Here is one example:\n\nhttp://docs.openstack.org/developer/nova/devref/vmstates.html\n\nIt used to have a graph rendered based on graphviz I believe. Does anyone know what happened? Is it possible to get it back? Thanks,\n\nYun\n\n</snip>\n\nIts rendering well for me, am using chrome. Kindly check your browser cache & see if it works.\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot1.png\nType: image/png\nSize: 101696 bytes\nDesc: Screenshot1.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/3a3b4895/attachment-0005.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot2.png\nType: image/png\nSize: 124173 bytes\nDesc: Screenshot2.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/3a3b4895/attachment-0006.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot3.png\nType: image/png\nSize: 132714 bytes\nDesc: Screenshot3.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/3a3b4895/attachment-0007.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot4.png\nType: image/png\nSize: 105675 bytes\nDesc: Screenshot4.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/3a3b4895/attachment-0008.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot5.png\nType: image/png\nSize: 80157 bytes\nDesc: Screenshot5.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130509/3a3b4895/attachment-0009.png>\n\n','<CADcnTpvLmVMZq2FeYSGR-YQj_x+sVdbuW6xEnG5=2eCWvUDEAQ@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7525A07CF@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 21:50:18',0,'2013-05-09 21:50:18',NULL,'[openstack-dev] graph rendering problem in openstack doc','Yun,\n\nReporting it as doc bug. I thought you are not able to see any of those there.\n\nCheers!!\n\nAtul\n________________________________________\nFrom: Yun Mao [yunmao at gmail.com]\nSent: Friday, May 10, 2013 3:02 AM\nTo: Atul Jha\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] graph rendering problem in openstack doc\n\nHi Atul,\n\nI see those pictures too. But the text above them used to be a picture too, starting from digraph states {....}\nYun\n\n\n\nOn Thu, May 9, 2013 at 5:25 PM, Atul Jha <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>> wrote:\nYun,\n\nI wish i had access to your network & system, since i don`t have that i am attaching the screenshot for.\nLet me know if it helps.\n\nCheers!!\n\nAtul\n________________________________________\nFrom: Yun Mao [yunmao at gmail.com<mailto:yunmao at gmail.com>]\nSent: Friday, May 10, 2013 2:48 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] graph rendering problem in openstack doc\n\nHi Atul,\n\nthere are about 5 graphs in the page. Only the first graph is rendered by graphviz. Others are just png files which look fine. I tried multiple browsers and no cache it still doesn\'t work for me. :(\n\nYun\n\n\nOn Thu, May 9, 2013 at 5:07 PM, Atul Jha <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com><mailto:Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>>> wrote:\nYun,\n\n<snip>\n\nHi,\n\nit seems that the doc engine stops rendering digraph anymore.. Here is one example:\n\nhttp://docs.openstack.org/developer/nova/devref/vmstates.html\n\nIt used to have a graph rendered based on graphviz I believe. Does anyone know what happened? Is it possible to get it back? Thanks,\n\nYun\n\n</snip>\n\nIts rendering well for me, am using chrome. Kindly check your browser cache & see if it works.\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org><mailto:OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CADcnTpv_7hL52VDcoGfXStZC97rFurTOgc76HCznikDmui-aQw@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7525A0EA7@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-05-12 19:56:29',0,'2013-05-12 19:56:29',NULL,'[Openstack-docs] Openstack HA updated document','Hi Deepak,\n\nGlad for your help.\n\nThe step by step way to contribute to OpenStack Doc is mentioned here https://wiki.openstack.org/wiki/Documentation/HowTo\n\n<snip>\nDear Sir ,\n\nPresently i am working to build a high availability for openstack using Fedora 18 . I was referring your document which you submitted by you to openstack community\n\nbut i found that CRM shell is not supported by fedora 18 it is replaced by PCS Shell .\nPCS shell used to build and manage Pacemaker and corosync system also.\n\nI need to submit my updated document\n\nCan you guide me how i can submit updated document to openstack community\n\nWaiting for reply\n\nThanks\nDeepak\n\nDeepak Shripat Mane\nTata Consultancy Services\nMailto: deepak.mane at tcs.com\n\n</snip>\n\nWould love to get your contribtion on the HA doc.\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<OFEA40E7AE.6A8F19A1-ON65257B69.0028EC9C-65257B69.002945D5@tcs.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7525CE16D@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-21 10:00:33',0,'2013-05-21 10:00:33',NULL,'[openstack-community] OpenStack in Africa (specifically Nairobi)','Adam,\n\n<snip>\nHello,\n\nWe\'re building a public OpenStack implementation in Nairobi and over time, the rest of the continent.  Is anybody on the list interested in talking about OpenStack in the African context or in starting a virtual meetup about it?  I\'d like to get more feedback about it and meet more people who are interested in the logistics of launching a cloud platform here.  I\'m also excited to get people not on the continent in the group if they have an interest.\n\nBased on feedback, I\'ll try to set up some sort of Hangout or something along those lines.  Just shoot me a line.\n\nCheers,\nAdam\n</snip>\n\nToo late to jump in the thread but sounds like great initiative. Keep us updated & let us know how can we help.\n\nCheers!!\n\nAtul\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130521/b3fc4477/attachment.html>\n\n','<CAGTm15=uKxnDMm846bk+dNUH=nr6LaY+_-jb9t-X=khf4Ohumg@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA7526BD31C@INCHEAM-MBX101>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-06-26 10:49:46',0,'2013-06-26 10:49:46',NULL,'[Openstack-docs] Nice work Lorin - Python APIs on DeveloperWorks','Lorin,\n\nLooks really nice & informative. :)\n________________________________\nFrom: Lorin Hochstein [lorin at nimbisservices.com]\nSent: Wednesday, June 26, 2013 8:31 AM\nTo: Anne Gentle\nCc: openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Nice work Lorin - Python APIs on DeveloperWorks\n\nThanks, Anne. I regain copyright of the work 30 days after publication, so I could add the content into the official docs if there\'s interest.\n\n\nLorin\n\n\nOn Tue, Jun 25, 2013 at 10:43 AM, Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>> wrote:\nGreat job on this article Lorin, and thanks for mentioning that you work on the documentation!\n\nhttp://www.ibm.com/developerworks/cloud/library/cl-openstack-pythonapis/index.html\n\nAnne\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com<http://www.nimbisservices.com>\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130626/d67b12fe/attachment.html>\n\n','<CADzpNMX3SAp6=RVVmcyFSSZDN39Tgm0XJv6h+AYk2FJt51VjGA@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA75305EC33@INCHEAMVW033.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 08:20:33',0,'2013-07-12 08:20:33',NULL,'[Openstack-docs] Linking to external install guides','Hi,\n\n<snip>\n________________________________________\nFrom: Steve Gordon [sgordon at redhat.com]\nSent: Thursday, July 11, 2013 7:39 PM\nTo: Shaun McCance\nCc: openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Linking to external install guides\n\n----- Original Message -----\n> From: \"Shaun McCance\" <shaunm at gnome.org>\n> To: \"Tom Fifield\" <tom at openstack.org>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, July 11, 2013 9:16:28 AM\n> Subject: Re: [Openstack-docs] Linking to external install guides\n>\n> On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:\n> > On 10/07/13 15:40, Andreas Jaeger wrote:\n> > > On 07/10/2013 02:34 AM, Tom Fifield wrote:\n> > >> I\'ll take a bullish line, which may not necessarily be achievable:\n> > >>\n> > >> \"\"\"\n> > >> On the day that the press release for Havana is sent out, we need -by\n> > >> hook or by crook!- to have installation instructions for RHEL and\n> > >> Ubuntu, and ideally SUSE and Debian too.\n> > >> \"\"\"\n> > >\n> > > What kind of instructions are you looking at? The \"Basic installation\"\n> > > ones, the current \"installation guides\" - or both?\n> > >\n> > > Andreas\n> >\n> > Thanks for the reply!!\n> >\n> > I think the answer is: \"something\" ;)\n> >\n> > My personal impression is:\n> > * the basic install guide is too basic right now\n> > * the install guides are too heavy\n> >\n> > so ideally what I would be looking for as a deployer is something that\n> > gives me a basic installation, with a bit of explanation on why the\n> > steps are being taken.\n> >\n> >\n> > However, I believe Shaun McCance is taking a very serious look at the\n> > installation guides right now and should be able to provide an\n> > authoritative answer.\n>\n> That\'s more or less my impression. I don\'t like that there\'s two guides.\n> It\'s asking readers to make an upfront decision that they\'re probably\n> not in a position to make. My preference would be a single install guide\n> that\'s structured such that you get a basic, working install within the\n> first few chapters, and can choose your own adventure after that.\n\nRight, I agree that the fact that there are two guides is a problem both for readers and for the writers attempting to keep them up to date. I think that there is some debate around what a \"basic, working install\" looks like though and in part that\'s what led to there being two guides in the first place. From my point of view a basic working install means you can run up an instance and it will have network connectivity, but that statement still leaves questions like:\n\n- Do you omit block storage (Cinder) setup because strictly speaking you don\'t need volumes to run a VM?\n- Do you omit object storage (Swift) setup because it\'s not strictly needed or do you use it as the backend for image storage (Glance)?\n\nAnother key point raised in the previous review of the basic-install guide was that while it gets the user up and running in a more streamlined fashion it can leave them in a bit of a bind when it comes to expanding [1]. So I think on top of my statement that a basic working install means \"you can run up an instance and it will have network connectivity\" there probably needs to be some consideration of ensuring the initial deployment allows for easy expansion without having to go back and rework the original endpoints etc. when it comes to the choose your own adventure part.\n\n> The current full install guide feels random, like pieces were added to\n> it over time without a lot of thought to the overall narrative. The\n> basic install guide is nice for what it is. I\'d just prefer it were\n> incorporated into a larger work.\n>\n> And I believe very strongly that your docs should be ready on release\n> day. They\'re part of your fanfare, and should be linked to from your\n> marketing materials.\n\nI am +1 on this but am concerned about expending too much effort on \"install from source\" instructions if most users are ultimately going to install from packages (even if there is a 1-2 day lag for packaging, which is the advice I am getting on rdo-list). My perhaps unrealistic suggestion is that we conditionalize such that we can have \"source\", \"debian;ubuntu\", and \"rhel;fedora;centos\" paths through a single installation guide (I provide these as examples, obviously where other distros such as SuSE differ and need an additional path they would also be more than welcome). The package-based options would be contingent on someone being willing to maintain them though - obviously I would be looking to be heavily involved from an RPM side. The \"from source\" path would be the only one that would be considered release blocking/must have though because ultimately it\'s the only one likely to be there on 0-day of the release. Thoughts?\n\nThanks,\n\nSteve\n\n[1] http://lists.openstack.org/pipermail/openstack-docs/2013-April/001510.html\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n</snip>\n\nI am one of the guy from the documentation team working on the basic install guide. But i found things getting changed after Essex.\n\n1. We had other distros supporting Openstack as well.\n2. Many new projects got added <quantum/nuetron> which requires additional hardware to get things in place.\n\nNow what my suggestion is/was :--\n\n1. Identify One person who is a distribution expert & can work with us & help us in getting the basic install setup in place. I think we already have one from each distribution for same.\n\n2. Create a basic install guide which will cover every component (YES  Swift & Cinder included) per distribution.\n\n3. Distribution like RedHat has extended documentation resource am sure Suse/Ubuntu/Debian would be having same. To get more fine grind distro level configuration accomplishment point them to distributed distro. They have their own best way or suggested way of deployment packstack/Juju & one who wants to explore those should visit respective site.\n\nWe should focus on adding/documenting new features which are incorporated with every release in every component i.e fiber channel/scheduler & many goodness coming in new release. This will save a lot of time & we can spend it in adding the features in doc rather than running after distro based install steps.\n\nAlso Ubuntu has cloud archive from long time which keeps testing packages[1], so i personally don`t think we could/should/would have difficulty is publishing basic install doc same day of our release. We have done this before as well. :)\n\nWhat do you people think?\n\nThanks!!\n\nAtul Jha\n(@koolhead17)\n\n[1] https://wiki.ubuntu.com/ServerTeam/CloudArchive\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<1246767659.3125818.1373551783603.JavaMail.root@redhat.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA75305EFE4@INCHEAMVW033.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 12:27:13',0,'2013-07-12 12:27:13',NULL,'[Openstack-docs] Linking to external install guides','Hi,\n\n<snip>\n\nI agree. It\'s not reasonable to expect us to cover everything on Day 0, but a set of basic install docs is reasonable. (Besides, if we don\'t document the foundation, how can we expect the distros to put things together so they CAN do their own?)\n\n</snip>\n\n\nThe basic install guide, per distro  will be done with help of the people working/familiar on the particular distribution.\n\n\n<snip>\n\nOn the other hand, we are here to document OpenStack, not all of the independent distros, so there\'s no shame in removing that from our launch day scope.\n\n</snip>\n\n\nAre you saying we should have only announcement about new release & no install instruction?\n\nIs it?\n\n\nAtul\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130712/1f241242/attachment.html>\n\n','<CA+p99GmNU-2mUKMkpuGfa2xkmo6tBNtrKEfrqeSZaD8mk+Rs6A@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA75305F007@INCHEAMVW033.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 12:49:09',0,'2013-07-12 12:49:09',NULL,'[Openstack-docs] Linking to external install guides','Hi,\n\n\n\nOn Jul 12, 2013 8:27 AM, \"Atul Jha\" <Atul.Jha at csscorp.com<mailto:Atul.Jha at csscorp.com>> wrote:\n>\n> Hi,\n>\n> <snip>\n>\n> I agree. It\'s not reasonable to expect us to cover everything on Day 0, but a set of basic install docs is reasonable. (Besides, if we don\'t document the foundation, how can we expect the distros to put things together so they CAN do their own?)\n>\n> </snip>\n>\n>\n> The basic install guide, per distro  will be done with help of the people working/familiar on the particular distribution.\n>\n\nRight.\n\n> <snip>\n>\n> On the other hand, we are here to document OpenStack, not all of the independent distros, so there\'s no shame in removing that from our launch day scope.\n>\n> </snip>\n>\n>\n> Are you saying we should have only announcement about new release & no install instruction?\n>\n> Is it?\n\n\n<snip>\n\nNo, just the opposite. I\'m saying we should have A basic, fairly distro- neutral set of install instructions. We Can then leave the distros to do their own thing.\n\n</snip>\n\nKindly clarify. I just hope we are not putting install from source instruction i.e distro-neutral install instruction.\n\n\nAtul\n\n\n> Atul\n>\n> http://www.csscorp.com/common/email-disclaimer.php\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130712/171ed4b2/attachment.html>\n\n','<CA+p99GmLbzBdW3oHTF3NjznNne+RB+q=SWmTbycFzRZkYsn7Vw@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA75305F072@INCHEAMVW033.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 14:23:13',0,'2013-07-12 14:23:13',NULL,'[Openstack-docs] Linking to external install guides','Nick,\n\n<snip>\n> Kindly clarify. I just hope we are not putting install from source instruction i.e distro-neutral install instruction.\n\nIf that\'s that\'s the only true \"distro neutral\" way, and it\'s not desirable, is there another option? Are you saying Canonical is usually caught up for Ubuntu? I\'m not suggesting any particular way, just that we provide enough information to give people the general idea, then send them on their way. I don\'t have any preferece for what that looks like.\n\n</snip>\n\nThe idea as we have always done is come up with basic distro install guides. Jaju/packstack can be handled in the distro oriented docs. When am saying basic install i meant step by step with command for minimum installation of OpenStack on X/Y/Z distros, which will make any user ready to get OpenStack running.\n\nLet me know if am still not able to clarify.\n\nAtul\n\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CA+p99GmLOzTSUNtYxPfM85U5wgjUgbgV9WO55gKuT5_UuLBLGA@mail.gmail.com>',NULL),('<0790F7C009AF7C40B43D459485FC7CA753063D9C@INCHEAMVW033.ad.csscorp.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-20 18:22:34',0,'2013-07-20 18:22:34',NULL,'[Openstack-docs] Welcome Sean Roberts and Colin McNamara\n	to	docs-core','\nHi,\n\n<snip>\nHi all,\nI wanted to let you all know that I\'ve invited Sean Roberts and Colin McNamara to join docs-core. Their focus is on building training docs that can be used at various user meetups. So their work will mostly be done by building docs that point to existing manuals.\n\nThanks Sean and Colin for this focus, I\'m pretty excited to see where you take it.\n</snip>\n\nWelcome Sean/Colin.\n\n\nCheers!!\n\nAtul Jha\n\nhttp://www.csscorp.com/common/email-disclaimer.php\n\n\n','<CAD0KtVGaJjbJFzhZU+18TWQMC3jjvMRW+4dTDK52Gt8LHxFsXw@mail.gmail.com>',NULL),('<07971BC8-E1E0-40EE-AAF1-EC8DA35E7505@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 09:24:33',-25200,'2014-06-18 16:24:33',NULL,'[openstack-dev] [nova] Reducing quota below utilisation','\nOn Jun 17, 2014, at 12:53 PM, Jan van Eldik <Jan.van.Eldik at cern.ch> wrote:\n\n> Just\n> \n> On 06/17/2014 08:18 PM, Tim Bell wrote:\n>> We have some projects which are dynamically creating VMs up to their\n>> quota. Under some circumstances, as cloud administrators, we would like\n>> these projects to shrink and make room for other higher priority work.\n>> \n>> We had investigated setting the project quota below the current\n>> utilisation (i.e. effectively delete only, no create). This will\n>> eventually match the desired level of VMs as the dynamic workload leads\n>> to old VMs being deleted and new ones cannot be created.\n>> \n>> However, OpenStack does not allow a quota to be set to below the current\n>> usage.\n> \n> Just to add that \"nova help quota-update\" suggests that the \"--force\" option should do the trick:\n> \n>  --force               Whether force update the quota even if the\n>                        already used and reserved exceeds the new quota\n> \n> However, when trying to lower the quota below the current usage value,\n> we get:\n> \n> \n> $ nova absolute-limits --te $ID|grep -i core\n> | totalCoresUsed          | 11    |\n> | maxTotalCores           | 20    |\n> $ nova quota-update --cores 2 $ID\n> ERROR: Quota value 2 for cores are greater than already used and reserved 11 (HTTP 400) (Request-ID: req-c1dd6add-772c-4cd5-9a13-c33940698f93)\n> $ nova quota-update --cores 2 --force $ID\n> ERROR: Quota limit must greater than 11. (HTTP 400) (Request-ID: req-cfc58810-35af-46a3-b554-59d34c647e40)\n> \n> Am I misunderstanding what \"--force\" does?\n\nThat was my understanding of force as well. This looks like a bug to me.\n\nVish\n\n> \n> BTW: I believe the first error message is wrong, and will propose\n> a patch.\n> \n>       cheers, Jan\n> \n> \n> \n>> \n>> This seems a little restrictive ? any thoughts from others ?\n>> \n>> Tim\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/c486a6b5/attachment.pgp>\n\n','<53A09CC6.80305@cern.ch>',NULL),('<07992DEA-2CE4-4FC1-B786-C2DA04F52BD8@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 08:40:40',-18000,'2015-01-27 13:40:40',NULL,'[openstack-dev] oslo.i18n 1.3.1 released','The Oslo team is pleased to announce the release of:\n\noslo.i18n 1.3.1: oslo.i18n library\n\nThe primary reason for this release is a packaging issue\nreported and fixed by Dan Smith.\n\nFor more details, please see the git log history below and:\n\nhttp://launchpad.net/oslo.i18n/+milestone/1.3.1\n\nPlease report issues through launchpad:\n\nhttp://bugs.launchpad.net/oslo.i18n\nChanges in /home/dhellmann/repos/openstack/oslo.i18n 1.3.0..1.3.1\n-----------------------------------------------------------------\n\nd9b3ca6 Clear global cache in test_get_available_languages\ne934009 Make setup.cfg packages include oslo.i18n\n\nDiffstat (except docs and test files)\n-------------------------------------\n\nsetup.cfg                            | 1 +\n2 files changed, 4 insertions(+)\n\n\n',NULL,NULL),('<07A0804B-23B9-438D-BE8A-B9D99790F915@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-04 11:18:11',-18000,'2013-02-04 16:18:11',NULL,'[openstack-dev] [quantum] Ensuring plugin agent configs are\n	present for server (bug-1059923)','Anyone have thoughts on my questions, below?\n\nThanks\n\nPCM (Paul Michali)\n\n\nOn Feb 1, 2013, at 1:51 PM, Paul Michali wrote:\n\n> Seeking some suggestions/comments/guidance on this?\n> \n> Issue was that user started quantum server with the core config file specified, but not any plugin config file. As a result, it used sqlite, though the setup was using mysql.  The goal is to try to prevent this issue.  From some discussion already, it appears that the approach should be to \"validate\" the plugin config options, rather than checking for any file, as a user could aggregate config settings into one file, with both core and plugin config settings.\n> \n> I\'ve got a few questions for plugin agent developers (this is my first bug, so I\'m trying to get up to speed).\n> \n> Would we be able to identify a set of plugin configuration options that all plugins must contain, or will they vary per plugin?\n> If there is a single set of config options that can be considered \"mandatory\" would we be able to change their definition and mark them as \"required\" so that exclusion of them is automatically detected by cfg, or will that cause issues (it seems like the cfg is shared by the server and  plugin agents)?\n> If the \"required\" configuration options vary per plugin, is it possible to push the validation of config down to the plugin (agent)?\n> If we do push down the validation, though, is there a way that this can be checked at the quantum server? IOW does the server invoke the agent(s) validator function?\n> Is this bug even worth pursuing, or should the proper configuration inclusion be something handled by provisioning tools? IOW rely on tooling to make sure the right files are included and \"expect\" that the user knows what they are doing, if they do this manually? Guess I need to ask that \"is it worth fixing this\" question :)\n> \n> Thanks in advance for any guidance!\n> \n> \n> PCM (Paul Michali)\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130204/0c866795/attachment.html>\n\n','<B7BB42E6-B628-4A7E-A712-810436944AAC@cisco.com>',NULL),('<07A204E9-D3B8-46C8-9FDB-6363F78EA995@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 20:09:03',0,'2014-06-09 20:09:03',NULL,'[openstack-dev] [neutron] blueprint ovs-firewall-driver: OVS\n implementation of security groups','Carl,\n\nYou are correct in both distinctions. Like I mentioned to Paul, beyond explicit configuration for the cloud operator, documentation and API validation for the end user, is there anything specific you would like to see as a ?warning label??\n\nAmir\n\nOn Jun 3, 2014, at 9:01 AM, Carl Baldwin <carl at ecbaldwin.net<mailto:carl at ecbaldwin.net>> wrote:\n\n\nHow does ovs handle tcp flows?  Does it include stateful tracking of tcp -- as your wording below implies -- or does it do stateless inspection of returning tcp packets?  It appears it is the latter.  This isn\'t the same as providing a stateful ESTABLISHED feature.  Many users may not fully understand the differences.\n\nOne of the most basic use cases, which is to ping an outside Ip address from inside a nova instance would not work without connection tracking with the default security groups which don\'t allow ingress except related and established.  This may surprise many.\n\nCarl\n\nHi all,\n\nIn the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us \"80%\" of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won?t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the ?20%\" difference more explicit to the operator and end user, we have proposed feature configuration to provide security group rules API validation that would validate based on connection tracking ability, for example.\n\nSeveral ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include:\n- marking ovs-firewall-driver as experimental in Juno\n- What does it mean to be marked as ?experimental??\n- performance improvements under a new OVS firewall driver untested so far (vthapar is working on this)\n- incomplete implementation will cause confusion, educational burden\n- debugging OVS is new to users compared to debugging old iptables\n- waiting for upstream OVS to implement (OpenStack K- or even L- cycle)\n\nIn my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today.\n\nAmir\n\n\n[0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html\n[1] https://review.openstack.org/#/c/89712/\n[2] http://openvswitch.org/pipermail/dev/2014-May/040567.html\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/0036b15f/attachment.html>\n\n','<CALiLy7o1Jvv+aEGRtfM04Ak0m9WSpTsavZ=Oow=nWbbrQG0SDw@mail.gmail.com>',NULL),('<07a6964195d3b90d0c8b56a355b110bd@li.nux.ro>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-02-07 08:43:51',0,'2013-02-07 08:43:51',NULL,'[Openstack-operators] Inject public IP address in the VM','On 08.01.2013 02:02, Akihiro MOTOKI wrote:\n> Hi,\n> \n> Quantum supports your scenario without NAT.\n> It can be done by creating \'shared network\' which has public IP range.\n> http://docs.openstack.org/trunk/openstack-network/admin/content/use_cases_single_flat.html\n> \n> The following command by the admin user will create such network.\n> # quantum net-create --shared public_net\n> # quantum subnet-create --allocation-pools\n> start=10.2.0.100,end=10.2.0.199 public_net 10.2.0.0/24\n\nThanks. Can you have multiple \"allocation pools\" for a public_net? \nAlso, would the security groups allow a VM to use a statically routed \naddress (one not in the allocated subnet)? I think this is not possible \nwith nova-network.\n\n-- \nSent from the Delta quadrant using Borg technology!\n\nNux!\nwww.nux.ro\n\n\n','<m2zk0kph3m.wl%motoki@da.jp.nec.com>',NULL),('<07A7FBFD-315A-43F4-A774-A36351451DE9@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 17:27:06',0,'2014-09-04 17:27:06',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out virt drivers','Hi all,\n\nThis is an issue that has been discussed quite a few times. As I was fearing the\nbottleneck effect is getting worse with each release.\n\nNova grew simply too much and even though features like networking and block\nstorage have been spun off at some point in time, it still lacks the cohesion\nnecessary for a successful long term lifecycle, or in other terms, it?s just too big to\nbe properly maintained by a handful of amazing and overworked people.\n\nCompute drivers are easy to identify as decoupled sub-projects and are among\nthose which suffer to a bigger extent the lack of an independent development\nprocess. \n\nNova is a mature project (at least relatively to the OpenStack?s context) and as\nsuch new features and bug fixes need to go through a very thorough screening and\nreview before being approved and merged, which does not work well with\nsub-projects that need to grow faster, especially when introduced later in the\nlifecycle (e.g the current Hyper-V driver introduced in Folsom) or when being\npushed by more aggressive market requirements. \n\nJust as an example, only 3 out of 8 Hyper-V blueprint specs have been approved\nand implemented in Juno, the rest will simply get bumped to Kilo, which means\nthat new additional specs will need to be bumped to L and so on introducing\nfurther delays. We ended up privileging feature parity blueprints, delaying\nalmost anything else.\n\nBug fixes landing time in stable releases is also another issue for the user\nbase since merging in master takes a long time and backporting requires another\nlong review process, e.g. more than four months in some cases [1]. \nAs a result we ended up releasing the fixes in a project fork that became our de\nfacto stable release in place of upstream, while waiting for upstream merge.\n\nWe never experienced similar issues in smaller projects like Neutron, Cinder,\nCeilometer or Horizon where we are involved as well, which can be a practical\nexample of the potential benefits of splitting Nova.\n\nOpenStack has a clear process for incubation, letting new projects grow as fast\nas they need during their youth and integrating them into core only when a\nmature stage is reached [2]. Unfortunately this process applies to projects, but\nnot to subprojects (Hyper-V and VMWare drivers in particular, but not only)\nresulting in a way slower development pace compared to what a project lead by an\nindependent team could have allowed. On the other hand, Docker is an example of\na driver going the StackForge way, but its ultimate potential inclusion in Nova\nwill just increase the current pain points.\n\n>From an Hyper-V team perspective, in the late Havana cycle the same reasons\nhighlighted in this thread almost lead us to ask for removal of the driver from\nNova in order to improve our development process, even at the cost of the\nsubsequent fall from (core) grace and StackForge incubation Purgatory period, so\nI?m definitely happy that the conversation has been resumed with a bigger\nconsensus.\n\nThe main factor that blocked the Hyper-V driver?s exit from Nova was the\nintroduction of the Hyper-V CI during the same cycle. Regressions are a very\nsensitive topic when you run OpenStack components on an operating system which\nis not Linux and the CI helped a lot in blocking or discovering issues in a\ntimely fashion. Beside that, the size of the Hyper-V team increased considerably\nduring Icehouse and Juno [3], so the Hyper-V CI became a mandatory and almost\nirreplaceable tool in our review process, leading us to reach an excellent level\nof stability of the driver on every supported version of Hyper-V (and\nprogressive CI voting stability as well, but that?s another topic [4]).\n\nThis means that if we reach a point in which we agree to spin off the drivers in\nseparate core projects, we need to consider how driver related CIs will be still\nincluded in the Nova review process, possibly with voting rights when the\nindividual CI stability allows it. Having each third party CI to vote only on\nits spin-off driver project is not an option IMO, as it won?t catch regressions\nintroduced in Nova that affect the drivers, including race conditions [5]\n\nAn interesting area of discussion is who is going to be part of the initial core\nteams for each new subproject. I truly appreciated the experience and help of\nthe Nova core guys, so in order to allow a smoother transition I?d suggest to\nhave for each new project (e.g. nova-compute-hyperv, nova-compute-vmware, etc)\nan initial core team consisting in one or two members of the current Nova\nsub-team and one Nova core, with ideally each patch reviewed by both the domain\nexperts and the Nova core. The team could then go on its way by voting its own\nmembers as any other OpenStack project does.\n\nAnother point of discussion is the stabilization and documentation of the driver\ninterface. There are simply too many areas where the behavior between drivers\ndiffers, and looking at some other driver?s behavior was in too many cases the\nonly source of documentation we had. \n\nAs an alternative, I?m personally not against the option of keeping Nova the way\nit is, giving more autonomy (aka +2 rights) on selected subtrees to sub-teams,\nbut that sounds to me like a half baked solution that will lead to problems like\nblueprint spec approval rights and other issues.\n\nOne of the additional very positive side effects that I can foresee, is that by\nfreeing up our resources from the continuous \"submit-code ->\nwait-long-time-for-review -> rebase -> repeat\" cycle that defines the current\nNova development cycle, we?ll be able to assign more people to review patches in\nNova itself, resulting hopefully in a long term benefit for everybody.\n\nAs another clear advantage, separate projects would allow growth and new\nfeatures, while allowing Nova to focus on stability and concentrate on reducing\nits technical debt, another related and recurring topic of discussion.\n\n\nTo recap this post, if this proposal goes on:\n\n1) As Hyper-V Nova sub-team we are definitely in favour of the spin-off of Nova\n    core sub-projects, including the compute drivers.\n2) We need to agree on how to handle the driver CIs reporting in Nova\n3) We need to define the members of the new projects core teams\n4) We need to document better the compute driver interface\n\nWe are fully aware of the great efforts pulled by the nova core team and the\npoints above do not imply in any way that they are not doing their best. It?s\njust a matter of removing unnecessary bottlenecks for the benefit of the entire\nOpenStack community.\n\n\nThanks Dan for raising this topic!\n\nAlessandro\n\n\n[1] https://review.openstack.org/#/c/83143/\n[2] http://robhirschfeld.com/2014/08/18/ugly-baby/\n[3] http://stackalytics.com/?company=cloudbase%20solutions&module=nova&metric=commits&release=all\n[4] http://ci-stats.cloudbase.it\n[5] https://bugs.launchpad.net/nova/+bug/1276772\n\n\n\nOn 04 Sep 2014, at 15:59, Thierry Carrez <thierry at openstack.org> wrote:\n\n> Like I mentioned before, I think the only way out of the Nova death\n> spiral is to split code and give control over it to smaller dedicated\n> review teams. This is one way to do it. Thanks Dan for pulling this\n> together :)\n> \n> A couple comments inline:\n> \n> Daniel P. Berrange wrote:\n>> [...]\n>> This is a crisis. A large crisis. In fact, if you got a moment, it\'s\n>> a twelve-storey crisis with a magnificent entrance hall, carpeting\n>> throughout, 24-hour portage, and an enormous sign on the roof,\n>> saying \'This Is a Large Crisis\'. A large crisis requires a large\n>> plan.\n>> [...]\n> \n> I totally agree. We need a plan now, because we can\'t go through another\n> cycle without a solution in sight.\n> \n>> [...]\n>> This has quite a few implications for the way development would\n>> operate.\n>> \n>> - The Nova core team at least, would be voluntarily giving up a big\n>>   amount of responsibility over the evolution of virt drivers. Due\n>>   to human nature, people are not good at giving up power, so this\n>>   may be painful to swallow. Realistically current nova core are\n>>   not experts in most of the virt drivers to start with, and more\n>>   important we clearly do not have sufficient time to do a good job\n>>   of review with everything submitted. Much of the current need\n>>   for core review of virt drivers is to prevent the mis-use of a\n>>   poorly defined virt driver API...which can be mitigated - See\n>>   later point(s)\n>> \n>> - Nova core would/should not have automatic +2 over the virt driver\n>>   repositories since it is unreasonable to assume they have the\n>>   suitable domain knowledge for all virt drivers out there. People\n>>   would of course be able to be members of multiple core teams. For\n>>   example John G would naturally be nova-core and nova-xen-core. I\n>>   would aim for nova-core and nova-libvirt-core, and so on. I do not\n>>   want any +2 responsibility over VMWare/HyperV/Docker drivers since\n>>   they\'re not my area of expertize - I only look at them today because\n>>   they have no other nova-core representation.\n>> \n>> - Not sure if it implies the Nova PTL would be solely focused on\n>>   Nova common. eg would there continue to be one PTL over all virt\n>>   driver implementation projects, or would each project have its\n>>   own PTL. Maybe this is irrelevant if a Czars approach is chosen\n>>   by virt driver projects for their work. I\'d be inclined to say\n>>   that a single PTL should stay as a figurehead to represent all\n>>   the virt driver projects, acting as a point of contact to ensure\n>>   we keep communication / co-operation between the drivers in sync.\n>> [...]\n> \n> At this point it may look like our current structure (programs, one PTL,\n> single core teams...) prevents us from implementing that solution. I\n> just want to say that in OpenStack, organizational structure reflects\n> how we work, not the other way around. If we need to reorganize\n> \"official\" project structure to work in smarter and long-term healthy\n> ways, that\'s a really small price to pay.\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5408623F.6060707@openstack.org>',NULL),('<07A9234D-90F5-4131-9FA0-1A5D6BCF119C@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 09:19:26',-18000,'2014-12-01 14:19:26',NULL,'[openstack-dev] [oslo] change to Oslo release process to support\n	stable branch requirement caps','As part of setting up version caps for Oslo and client libraries in the stable branches, we discovered that the fact that we do not always create stable branches of the Oslo libraries means the check-requirements-integration-dsvm job in stable branches is actually looking at the requirements in master branches of the libraries, and failing in a lot of cases. With the move away from alpha version numbers toward version caps and patch releases, we?re going to change the Oslo release processes so that at the end of a cycle we always create a stable branch from the final version of each library released in the cycle. \n\nThanks to Clark and Thierry for helping by creating stable/icehouse and stable/juno branches for most of the libraries, though we?ve discovered one or two that we missed so we?re still working on a few cases.\n\nFor Kilo, we will branch all of the library repositories at the end of the cycle, probably following the same process as is used for the other projects (though the details remain to be worked out).\n\nThanks,\nDoug\n\n',NULL,NULL),('<07AC732E-CF27-4B8A-B124-C29831BF5E4F@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-28 21:46:33',14400,'2013-03-28 17:46:33',NULL,'[openstack-dev] [Savanna] Weekly meeting (#openstack-meeting-alt)','Hi,\n\nToday there will be our third weekly community meeting about Savanna at 18:00 UTC on irc channel #openstack-meeting-alt at freenode.\n\nCome along.\n\nSergey Lukjanov\n\n',NULL,NULL),('<07B8BE90-7EEF-463A-B66E-655B1A793507@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 14:33:37',-25200,'2014-06-26 21:33:37',NULL,'[openstack-dev] [nova] should we have a stale data indication\n	in \"nova list/show\"?','\nOn Jun 26, 2014, at 3:58 AM, Day, Phil <philip.day at hp.com> wrote:\n\n>> -----Original Message-----\n>> From: Ahmed RAHAL [mailto:arahal at iweb.com]\n>> Sent: 25 June 2014 20:25\n>> To: openstack-dev at lists.openstack.org\n>> Subject: Re: [openstack-dev] [nova] should we have a stale data indication in\n>> \"nova list/show\"?\n>> \n>> Le 2014-06-25 14:26, Day, Phil a ?crit :\n>>>> -----Original Message-----\n>>>> From: Sean Dague [mailto:sean at dague.net]\n>>>> Sent: 25 June 2014 11:49\n>>>> To: OpenStack Development Mailing List (not for usage questions)\n>>>> Subject: Re: [openstack-dev] [nova] should we have a stale data\n>>>> indication in \"nova list/show\"?\n>>>> \n>>>> \n>>> +1 that the state shouldn\'t be changed.\n>>> \n>>> What about if we exposed the last updated time to users and allowed\n>> them to decide if its significant or not ?\n>> \n>> \n>> This would just indicate the last operation\'s time stamp.\n>> There already is a field in nova show called \'updated\' that has some kind of\n>> indication. I honestly do not know who updates that field, but if anything,\n>> this existing field could/should be used.\n>> \n>> \n> Doh ! - yes that is the updated_at value in the DB.    \n> \n> I\'d missed the last bit of my train of thought on this, which was that we could make the periodic task which checks (and corrects) the instance state update the updated_at timestamp even if the state is unchanged.\n> \n> However that does add another DB update per instance every 60 seconds, and I\'m with Joe that I\'m really not convinced this is taking the Nova view of Status in the right direction.   Better to educate / document the limitation of status as they stand than to try and change it I think.\n> \n> Phil\n\nWe have an external check that updates the state of instances if the nova-compute fails. We currently put them into ERROR state which is kind of confusing because (as stated earlier in the thread) the instance may be running. It would be nice to have an UNKNOWN state which could be used for this purpose, even if it is an external system that is setting it.\n\nVish\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/2c761600/attachment.pgp>\n\n','<BD26CCD58723F74AA8E6BCB31052A1F007146E38@G6W2490.americas.hpqcorp.net>',NULL),('<07BB6084-681B-4749-B3B4-CE2D5BC91CA4@prophetstor.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-31 10:39:14',28800,'2014-07-31 02:39:14',NULL,'[OpenStack-Infra] Requesting a Service Account for Third Party\n	CI System','Hi Anita\n\nThis has been pending for quite a while now, are you able to help us forward this request to the relevant people or do you have the email of who should we contact for this? \n\nThanks!\nSteve\n\n> On Jul 31, 2014, at 10:18 AM, Anita Kuno <anteaya at anteaya.info> wrote:\n> \n>> On 07/31/2014 11:24 AM, Rick Chen wrote:\n>> HI All:\n>>    I saw the third-pard CI members still increased, but our account is\n>> not accepted. Can you tell me why? Or how to solve this problem?\n> Sure, one of the infra members with permissions to create the account\n> hasn\'t had the time to do it yet.\n> \n> You are welcome to join the #openstack-infra irc channel or follow along\n> in the logs: http://eavesdrop.openstack.org/irclogs/%23openstack-infra/\n> \n> Thanks Rick,\n> Anita.\n>> \n>> 1.      Attached file.\n>> 2.      A preferred username: prophetstor\n>> 3.      A human-readable: ProphetStor-CI\n>> 4.      Email address: prophetstor.ci at prophetstor.com\n>> 5.      For cinder volume driver certificate. BP:\n>> https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n>> \n>>>    Please help us to create service account. Thanks.\n>> -----Original Message-----\n>> From: Rick Chen [mailto:rick.chen at prophetstor.com] \n>> Sent: Monday, July 28, 2014 10:41 PM\n>> To: \'Anita Kuno\'; \'openstack-infra at lists.openstack.org\'\n>> Cc: \'steve tan\'; \'Albert Lin\'\n>> Subject: RE: [OpenStack-Infra] Requesting a Service Account for Third Party\n>> CI System\n>> \n>> HI Anita:\n>>    Does our service account ready?\n>>    I need change below information, please help me to correct? Or tell\n>> me how to change it?\n>>>> 3.      A human-readable: Prophetstor-CI --> ProphetStor-CI\n>> \n>> \n>> -----Original Message-----\n>> From: Anita Kuno [mailto:anteaya at anteaya.info]\n>> Sent: Monday, July 28, 2014 3:43 AM\n>> To: Rick Chen; openstack-infra at lists.openstack.org\n>> Cc: \'steve tan\'; Albert Lin\n>> Subject: Re: [OpenStack-Infra] Requesting a Service Account for Third Party\n>> CI System\n>> \n>>> On 07/27/2014 01:07 PM, Rick Chen wrote:\n>>> Hi Anita:\n>>>    Prophetstor is my company name. I plan to verify our cinder volume \n>>> driver.\n>>>    BP:\n>>> https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver\n>>>    Please help us to create service account. Thanks.\n>> Great, thanks Rick. Linking the blueprint really helps.\n>> \n>> We are working on getting me permissions to create accounts, which is soon\n>> but hasn\'t happened yet. In the meantime one of my infra colleagues may get\n>> the account created before I do.\n>> \n>> Thanks,\n>> Anita.\n>>> \n>>> -----Original Message-----\n>>> From: Anita Kuno [mailto:anteaya at anteaya.info]\n>>> Sent: Saturday, July 26, 2014 9:08 PM\n>>> To: openstack-infra at lists.openstack.org\n>>> Subject: Re: [OpenStack-Infra] Requesting a Service Account for Third \n>>> Party CI System\n>>> \n>>>> On 07/25/2014 08:36 PM, Rick Chen wrote:\n>>>> Hi Sir:\n>>>> \n>>>>        Please help us to create service account, Thanks.\n>>>> \n>>>> \n>>>> \n>>>> 1.      Attached file.\n>>>> \n>>>> 2.      A preferred username: prophetstor\n>>>> \n>>>> 3.      A human-readable: Prophetstor-CI\n>>>> \n>>>> 4.      Email address: prophetstor.ci at prophetstor.com\n>>>> \n>>>> \n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-Infra mailing list\n>>>> OpenStack-Infra at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>> Hi Rick:\n>>> \n>>> We are changing our documentation around requesting a service account, \n>>> the patch hasn\'t been merged yet:\n>>> https://review.openstack.org/#/c/101013/11/doc/source/third_party.rst\n>>> \n>>> So Prophetstor is the name of your company, what details can you give \n>>> me about what you intend to be verifying with your third party ci account?\n>>> It might be a piece of software or hardware or something else.\n>>> The more details you can offer, the better. If you have a blueprint or \n>>> spec for it, linking to the blueprint or spec in your reply is really\n>> helpful.\n>>> \n>>> Thanks Rick,\n>>> Anita.\n>>> \n>>> _______________________________________________\n>>> OpenStack-Infra mailing list\n>>> OpenStack-Infra at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>> \n\n\n','<53D9A78A.8000005@anteaya.info>',NULL),('<07BC4A91-C0A7-4B64-B29E-97BC1537D4BF@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-25 21:57:25',36000,'2014-06-25 11:57:25',NULL,'[Openstack] Renewing keystone signing certs','\nOn 25 Jun 2014, at 9:05 am, Adam Young <ayoung at redhat.com> wrote:\n\n> On 06/23/2014 07:37 PM, Sam Morrison wrote:\n>> Hi Adam,\n>> \n>> Thanks for the advice, I?ve tested it out and it is possible to switch over pretty seamlessly.\n>> \n>> Here is what I did (spelt out in full for others reading):\n>> \n>> 1. Generate a new signing key\n>> 2. Generate a new certificate request\n>> 3. Sign this with the existing CA to generate a new signing_cert.\n>> 4. Append the new signing cert to the old signing cert. Make sure the old cert is first in the file.\n>> 5. Remove all signing certs from all your hosts to force nova etc to download the new signing_cert(s)\n>> 6. Replace the signing key with the new signing key AND at the same time flip the signing_cert file so the new signing cert is now first in the file.\n>> \n>> After the old cert has expired you can safely remove the old signing cert from the file.\n>> \n>> It would be great if keystoneclient could have a max_age on the signing_cert so it would periodically download a fresh one. I would think if it downloaded a new one every 7 days or so would suffice.\n> \n> Even better would be for it to look at the expiration date of the certificate and look for a fresh download if we are close to expired.    Tweakable params would be how often to check, and how big a window to consider for a download.\n\nYeah that would be great. I?m starting to think signing_cert should be split into two functions. The signing cert on the keystone server that is used by keystone to sign tokens.\nThen a signing trusts file which is what all the openstack services download.\n\nThen you can add all the certs you?re using for signing. Would support having different signing keys if you?re using multiple keystone servers. Plus easier to support renewing keys.\nOf course this is all possible now except you just need to get your ordering right as when keystone is signing it uses the first cert in the file.\n\nSam\n\n\n\n','<53AA0454.4020600@redhat.com>',NULL),('<07C2E56A-98F3-4A3A-99F7-38E560BE683C@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-09 17:30:30',-21600,'2012-03-09 23:30:30',NULL,'[OpenStack Foundation] Foundation Structure: An Alternative','On Mar 9, 2012, at 5:00 PM, Devin Carlen wrote:\n> Mark, one thing that I am curious about - there doesn\'t seem to be language in the foundation structure document that would prevent \"individual\" members from organizations that are also \"strategic\" members from also being on the board.   Is there any language that prevents board stacking?\n> \n> Devin\n\nWe hadn\'t put language in the overall structure summary around this, but have mentioned that this was something the Bylaws would probably cover. Setting the specific limitations is probably somewhat dependent on the Board size. I think it makes sense to have some limit (one company cannot employ more than X percentage of the Board members), but not say that it can only be one per company. If there are really good candidates who happen to share an employer, eliminating them completely could be counterproductive. Also, Individual Member seats would be tied to the individual instead of an organization, meaning the member would retain the seat even if he or she changed employers.\n\n\n','<D23A8CA925A140E398F6E94AC439687D@me.com>',NULL),('<07C33932-FCDD-4BA7-B7BE-4F3925F06109@2cups.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-08 14:30:42',28800,'2013-11-08 06:30:42',NULL,'[openstack-dev] L3 advanced features blueprint mapping to IETF\n	and IEEE standards','That time works for me (I fly back to America the night before)\nRegards,\n\nColin\n\nColin McNamara\nPeople | Process | Technology\n--------------------------------------------\nMobile: 	858-208-8105\nTwitter:	@colinmcnamara\nLinkedin:	www.linkedin.com/colinmcnamara\nBlog:	www.colinmcnamara.com\nEmail:	colin at 2cups.com	\n\n\n\n\n\n\nOn Nov 8, 2013, at 2:01 PM, Pedro Roque Marques <pedro.r.marques at gmail.com> wrote:\n\n> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m in Japan and 6 a.m CET on the 20th.\n> It is not ideal but i suspect we will have interest in participating from both Europe and Asia.\n> I volunteer myself and Nachi Ueno nachi at ntti3.com (the author of the BGP MPLS blueprint) as agenda organizers; please drop us a note if you intend to attend and wether you would like to present something to the group.\n> \n>   Pedro.\n> \n> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober <Rochelle.Grober at huawei.com> wrote:\n> \n>>  \n>>  \n>> From: Pedro Roque Marques [mailto:pedro.r.marques at gmail.com]\n>> Colin,\n>> \"The nice thing about standards is that there are so many of them to choose from.\"\n>>  \n>> For instance, if you take this Internet Draft:\n>> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on RFC4364.\n>>  \n>> It has already been implemented as a Neutron plugin via OpenContrail (http://juniper.github.io/contrail-vnc/README.html); With this implementation each OpenStack cluster can be configured as its own Autonomous System.\n>>  \n>> There is a blueprint\n>> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn\n>> that is discussing adding the provisioning of the autonomous system and peering to Neutron.\n>>  \n>> Please note that the work above does interoperate with 4364 using option B. Option C is possible but not that practical (as an operator you probably don\'t want to expose your internal topology between clusters).\n>>  \n>> If you want to give it a try you can use this devstack fork: https://github.com/dsetia/devstack.\n>> You can use it to interoperate with a standard router that implements 4364 and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.\n>>  \n>> I believe that the work i\'m referencing implements interoperability while having very minimal changes to Neutron. It is based on the same concept of neutron virtual network and it hides the BGP/MPLS functionality from the user by translating policies that establish connectivity between virtual networks into RFC 4364 concepts.\n>> Please refer to: https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>>  \n>> Would it make sense to have an IRC/Web meeting around interoperability with RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work that has already been done there by multiple vendors as well as some carriers.\n>>  \n>> +1  And it should be scheduled and announced a reasonable time in advance developers can plan to participate.\n>>  \n>> --Rocky\n>>  \n>>   Pedro.\n>>  \n>> On Nov 7, 2013, at 12:35 AM, Colin McNamara <colin at 2cups.com> wrote:\n>> I have a couple concerns that I don?t feel I clearly communicated during the L3 advanced features session. I?d like to take this opportunity to both clearly communicate my thoughts, as well as start a discussion around them.\n>>  \n>> Building to the edge of the \"autonomous system\"\n>> The current state of neutron implementation is functionally the l2 domain and simple l3 services that are part of a larger autonomous system. The routers and switches northbound of the OpenStack networking layer handled the abstraction and integration of the components.\n>> Note, I use the term ?Autonomous System? to describe more then the notion of BGP AS, but more broadly in the term of a system that is controlled within a common framework and methodology, and integrates with a peer system that doesn?t not share that same scope or method of control\n>> These components that composed the autonomous system boundary implement protocols and standards that map into IETF and IEEE standards. The reasoning for this is interoperability. Before vendors utilize IETF for interoperability at this layer, the provider experience was horrible (this was my personal experience in the late 90?s).\n>>  \n>> Wednesdays discussions in the Neutron Design Sessions\n>> A couple of the discussions, most notably the extension of l3 functionality fell within the scope of starting the process of extending Neutron with functionality that will result (eventually) in the ability for an OpenStack installation to operate as it?s own Autonomous System.\n>> The discussions that occurred to support L3 advanced functionality (northbound boundary), and the QOS extension functionality both fell into the scope of Northbound and Southbound boundaries of this system.\n>> My comments in the session\n>> My comments in the session, while clouded with jet-lag were specifically around two concepts that are used when integrating other types of systems \n>> 1. In a simple (1-8) tenant environment integration with a northbound AS is normally done in a PE-CE model that generally centers around mapping dot1q tags into the appropriate northbound l3 segments and then handling the availability of the L2 path that traverses with port channeling, MLAG, STP, Etc.\n>> 2. In a complex environment (8+ for discussion) different Carrier Supporting Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are used. These allow the mapping of segregated tenant networks together and synchronizing between distributed systems. This normally extends the tagging or tunneling mechanism and then allows for BGP to synchronize NLRI information between AS?s.\n>> These are the standard ways of integrating between carriers, but also components of these implementations are used to integrate and scale inside of a single web scale data center. Commonly when you scale beyond a certain physical port boundary (1000is edge ports in many implementations, much larger in current implementations) the same designs for C2C integrations are used to create network availability zones inside a web scale data center. \n>> Support of these IETF and IEEE standard integrations are necessary for brown field installations\n>> In a green field installation, diverging from IETF and IEEE standards on the north bound edge while not a great idea, can result in a functional implementation. In a brown field implementation where OpenStack Neutron will be integrated into an existing network core. This boundary layer is where we move from a controlled system into a distributed system. The cleanly integrate into this system, IETF and IEEE protocols and standards have to be followed. \n>>  \n>> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>When we diverge from this standards based integration at the north edge of our autonomous system we lose the ability to integrate without introducing major changes (and risk), into our core. In my experience this is sufficient to either slow or stall adoption. This is a major risk, that I believe can be mitigated.\n>> My thoughts on mitigating this risk\n>> We need to at least map and track the relevant IETF RFC?s that define the internet standards for integration at the AS boundary. I know that many of the network vendor developers that contribute to Neutron have access to people who both have deep knowledge of these standards, and also participate in the IETF working groups. I would hope that these resources could be leveraged to at least give a sanity check, at best ensure a compliant northbound interface to other systems.\n>> Side benefit of engaging IETF members in this discussion\n>> The other side benefit of this is that inventions inside of Neutron can also be communicated as standards to the rest of the world in the form of net new RFC?s. In OVS this has already happened, as OVS has emerged to be a common component in many network devices, and the need to establish and reference a common standard has risen it?s head. I would think that inventions within Neutron would follow this same path.\n>>  \n>> Regards,\n>> Colin\n>> Colin McNamara\n>> People | Process | Technology\n>> --------------------------------------------\n>> Mobile:             858-208-8105\n>> Twitter: @colinmcnamara\n>> Linkedin:          www.linkedin.com/colinmcnamara\n>> Blog:    www.colinmcnamara.com\n>> Email:  colin at 2cups.com         \n>>  \n>>  \n>>  \n>>  \n>> \n>>  \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>  \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131108/729a42d1/attachment.html>\n\n','<00C88327-1E87-4CA5-B4C2-6299A36FEA41@gmail.com>',NULL),('<07C86D94-C838-419E-B193-CD21DB88A13E@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 08:14:12',-14400,'2014-07-24 12:14:12',NULL,'[openstack-dev] [oslo.cfg] Dynamically load in options/groups\n	values from the configuration files','\nOn Jul 23, 2014, at 11:10 PM, Baohua Yang <yangbaohua at gmail.com> wrote:\n\n> Hi, all\n>      The current oslo.cfg module provides an easy way to load name known options/groups from he configuration files.\n>       I am wondering if there\'s a possible solution to dynamically load them?\n> \n>       For example, I do not know the group names (section name in the configuration file), but we read the configuration file and detect the definitions inside it.\n> \n> #Configuration file:\n> [group1]\n> key1 = value1\n> key2 = value2\n> \n>        Then I want to automatically load the group1. key1 and group2. key2, without knowing the name of group1 first.\n\nIf you don?t know the group name, how would you know where to look in the parsed configuration for the resulting options?\n\nDoug\n\n> \n>         Thanks a lot!\n> \n> -- \n> Best wishes!\n> Baohua\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/02689746/attachment.html>\n\n','<CACbo-EDAawkkziVda62BBkT3JyHOqaY3LOAzheqc-f4o7HXc=g@mail.gmail.com>',NULL),('<07D1F17E-5708-4F98-93DF-F48039387761@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-30 13:34:41',0,'2013-12-30 13:34:41',NULL,'[Openstack-docs] Why is identity-api v3 not published?','Right. Do not publish.  \n\nSent from my iPhone\n\n> On Dec 30, 2013, at 6:52 AM, \"Andreas Jaeger\" <aj at suse.com> wrote:\n> \n>> On 12/30/2013 01:20 PM, Diane Fleming wrote:\n>> It\'s published on API reference page, but there is no book version for the API.  \n> \n> I see.\n> \n> so, the file\n> identity-api/openstack-identity-api/v3/src/markdown/identity-api-v3.md\n> is not published at all - correct?\n> \n> Shouldn\'t we do this?\n> \n> Andreas\n> \n>> Sent from my iPhone\n>> \n>>> On Dec 30, 2013, at 4:40 AM, \"Andreas Jaeger\" <aj at suse.com> wrote:\n>>> \n>>> I noticed that the identity-api has a v3 in its repo but this one is not\n>>> gated or published. Is there any specific reason for this?\n>>> \n>>> Otherwise I\'ll fix the gating and publishing,\n>>> \n>>> Andreas\n>>> -- \n>>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>>>  GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>>>   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n>>> \n>>> _______________________________________________\n>>> Openstack-docs mailing list\n>>> Openstack-docs at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>> \n>> _______________________________________________\n>> Openstack-docs mailing list\n>> Openstack-docs at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n> -- \n> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n\n','<52C16C90.6090205@suse.com>',NULL),('<07D7C16F-C6E0-4401-899C-4B82D7D956A0@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-29 13:12:51',-28800,'2013-12-29 21:12:51',NULL,'[openstack-dev] [All] tagged commit messages','I\'ve seen several disconnected messages about tags in commit messages. I\'ve seen what is possible with the DocImpact tag, and I\'d like to have some more flexible tagging things too. I\'d like to use tags for things like keeping track of config defaults changing, specific ongoing feature work, and tracking changes come release time.\n\nI put together a little commit hook this afternoon. https://gist.github.com/notmyname/8174779 I think it would be nice to integrate this into jeepyb and gerrit. My script isn\'t much more than the code to parse a commit message (and I\'ve only tested it against a test repo), but I think the mechanics already present in something like notify_impact.py (in jeepyb) may take care of common actions like filing bugs and emailing a list of people.\n\n--John\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131229/f87aaede/attachment.pgp>\n\n',NULL,NULL),('<07E6AD6B-DB1E-4C1C-8774-6EBCEC30B463@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-06 00:23:44',0,'2013-11-06 00:23:44',NULL,'[openstack-dev] [Neutron] IPv6 sub-team?','On Nov 5, 2013, at 5:50 PM, \"Collins, Sean (Contractor)\" <Sean_Collins2 at cable.comcast.com> wrote:\n> Hi,\n> \n> Is there any interest in organizing a IPv6 sub-team, similar to how\n> there are sub-teams for FwaaS, VPNaas, ML2, etc?\n\n\n+1, lets do it!\n\n','<7EB180D009B1A6428D376906754127CB28DA3338@PACDCEXMB05.cable.comcast.com>',NULL),('<07F28E72-B71D-4206-8F53-B1621DC40324@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-08-20 22:00:30',-14400,'2012-08-21 02:00:30',NULL,'[Openstack-docs] Compute admin guid broken?','Is anybody able to build the compute admin guide on their local machines? Tom hit a problem in master <https://bugs.launchpad.net/openstack-manuals/+bug/1038546>, and I think there are additional problems, because I can\'t build stable/essex either <https://bugs.launchpad.net/openstack-manuals/+bug/1039305>.\n\nIs Jenkins able to build the latest commits?\n\nTake care,\n\nLorin\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20120820/0fcc89c4/attachment.html>\n\n',NULL,NULL),('<07F4081FF032A44994850701DFF6CABE230F5B4C@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-30 21:26:05',0,'2012-10-30 21:26:05',NULL,'[openstack-dev] Quantum awareness to VM live migration event','Dan,\n\nThis is an example of use of \"endpoint\" abstraction (with attribute \"host\" for example). Issuing a \"PUT\" on this attribute would indicate VM motion (request) and request for port reassignment (quantum response).\n\nThanks,\nSasha\n\n-----Original Message-----\nFrom: Dan Wendlandt [mailto:dan at nicira.com] \nSent: Tuesday, October 30, 2012 10:08 AM\nTo: Salvatore Orlando\nCc: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)\nSubject: Re: [openstack-dev] Quantum awareness to VM live migration event\n\nOn Tue, Oct 30, 2012 at 2:28 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n> Hi Irena,\n>\n> I do apologise for not having been more clear.\n> I was wondering if you are planning to extend the Quantum API, besides \n> the module that interfaces nova to quantum, in order to accomodate \n> migration events.\n> At a first glance, I believe this process could be entirely managed \n> using the existing Quantum API, but I have not explored the problem in \n> detail, so I might be missing something.\n>\n> Salvatore\n\nAt the summit, we talked about adding calls to the Quantum admin API for a service to tell Quantum what host a particular port is being placed on (or removed from).  This helps solve some of the vif-plugging issues gary was talking about, but could also be seen as a mechanism by which nova could indicate that a port have been removed from one host, and placed on another as a result of a VM migration.\n\ndan\n\n\n>\n>\n> On 30 October 2012 09:20, Irena Berezovsky <irenab at mellanox.com> wrote:\n>>\n>> Moving the ongoing discussion to the openstack-dev mailing list\n>>\n>>\n>>\n>> Salvatore,\n>>\n>> Thank you for comments.\n>>\n>> I would like to add additional methods to quantum API corresponding \n>> the VM migration methods defined at nova/network/api.\n>>\n>> I am not sure what do you mean by server side calls to quantum.\n>>\n>> Just to be sure how to proceed, shall we create the blueprint for \n>> this task?\n>>\n>>\n>>\n>> Regards,\n>>\n>> Irena\n>>\n>>\n>>\n>> On 30 October 2012 08:16, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>\n>> Hi Irena,\n>>\n>>\n>>\n>> I am afraid you\'re correct. VM migration events were not addressed in \n>> the nova-quantum api for Folsom.\n>>\n>> We definitely want to add those calls - and help would be extremely \n>> appreciated.\n>>\n>>\n>>\n>> I think the nova-to-quantum API was mostly implemented by Yong - with \n>> some contribution from Dan, me, and other Quantum devs.\n>>\n>>\n>>\n>> Are you planning to add also server-side calls to Quantum for \n>> migration awareness?\n>>\n>>\n>>\n>> Salvatore\n>>\n>>\n>>\n>>\n>>\n>> On 30 October 2012 08:13, Irena Berezovsky <irenab at mellanox.com> wrote:\n>>\n>> Hi guys,\n>> I have troubles to follow the flow of events in case of VMlive migration.\n>> Can I ask  you for clarifications?\n>> What I see from the code is that there is no additions to  Quantum \n>> API for migration awareness.\n>> At\n>> https://github.com/openstack/nova/blob/master/nova/network/quantumv2/\n>> api.py\n>> there is just empty implementation.\n>> Is there an intension to add Quantum API calls for live migration? Is \n>> it only nova related actions? Is some help needed?\n>>\n>> I am looking for a way to be aware of live migration at quantum \n>> plugin (due to the need to configure physical server that attached to \n>> the host that hosts VM).\n>> Thanks a lot,\n>> Irena\n>>\n>>\n>>\n>> -----Original Message-----\n>> From: Gary Kotton [mailto:gkotton at redhat.com]\n>> Sent: Sunday, October 28, 2012 10:34 AM\n>> To: Irena Berezovsky\n>>\n>> Cc: Dan Wendlandt; Salvatore Orlando\n>> Subject: Re: Quantum awareness to VM live migration event\n>>\n>> On 10/28/2012 10:27 AM, Irena Berezovsky wrote:\n>> > Hi Dan,\n>> > Thank you very much for your response.\n>> > Salvatore, Gary may I ask few questions regarding this  change?\n>> > 1. Is there some blueprint covering support for VM migration calls \n>> > to quantum API (data passed by nova) and DB model changes (if any)?\n>>\n>> Not that I am aware of\n>> > 2. Is there some description of VM migration  flow from nova \n>> > perspective?\n>>\n>> Ditto\n>> > 3. Is it part of Folsom release?\n>>\n>> Yes, this should be supported and working.\n>> > 4. Does it handle case when VM Migration fails?\n>>\n>> I would hope so.\n>> > 5. As far as I understand,  in migrate_instance_finish there is a \n>> > \'dest \' attribute. I believe its destination Physical host UUID. In \n>> > migrate_instance_start there is a \'host\' attribute. Is it source \n>> > Physical Host UUID?\n>>\n>> I am not familiar with this.\n>> >\n>> > Thank you in advance,\n>> > Irena\n>> >\n>> >\n>> > -----Original Message-----\n>> > From: Dan Wendlandt [mailto:dan at nicira.com]\n>> > Sent: Saturday, October 27, 2012 2:46 AM\n>> > To: Irena Berezovsky\n>> > Cc: Salvatore Orlando; Gary Kotton\n>> > Subject: Re: Quantum awareness to VM live migration event\n>> >\n>> > Hi Irena,\n>> >\n>> > Sorry, just now starting to catch up on email post-summit.\n>> >\n>> > I\'m CC\'ing Salvatore and Gary, as they are also involved in this, I \n>> > believe.\n>> >\n>> > Salvatore was involved with discussions with Vish and the Nova team \n>> > around the addition of migration hooks to the network api within \n>> > nova,\n>> > see:\n>> > https://github.com/openstack/nova/blob/master/nova/network/api.py#L\n>> > 337\n>> >\n>> > Gary\'s talk on the summit also touches on this, and would likely \n>> > add the admin calls to the Quantum API that indicate that a port is \n>> > about to be provisioned on a particular physical host (this would \n>> > probably be sent to quantum from nova when a VM is started/stopped, or migrated.\n>> >\n>> > Dan\n>> >\n>> >\n>> >\n>> >\n>> > On Mon, Oct 15, 2012 at 11:01 AM, Irena \n>> > Berezovsky<irenab at mellanox.com>\n>> > wrote:\n>> >> Dan,\n>> >> Continuing our talk today, please let me know if there is some \n>> >> work about Quantum awareness to VM live migration event (before \n>> >> and after on source and destination nodes).\n>> >>\n>> >> I would lie to be part of it,\n>> >>\n>> >> Thanks,\n>> >> Irena\n>> >\n>> >\n>> > --\n>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>> > Dan Wendlandt\n>> > Nicira, Inc: www.nicira.com\n>> > twitter: danwendlandt\n>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n>>\n>>\n>>\n>>\n>\n>\n\n\n\n--\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\nDan Wendlandt\nNicira, Inc: www.nicira.com\ntwitter: danwendlandt\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CA+0XJm8JACJG2Q-jFD6XOUX_1AZ7NKDxC6s9Gs_eTWmUrK4hjw@mail.gmail.com>',NULL),('<07F4081FF032A44994850701DFF6CABE230F7A05@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 21:03:16',0,'2012-11-01 21:03:16',NULL,'[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion','Eugene, Salvatore, thanks for great discussion!\n\nI am also looking forward to the answer regarding the semantics of associating \"service\" to (logical) \"router\".\n\nI also have some questions/clarifications below inline (way below, hence in green) , related to your earlier exchanges ?\n\nThanks,\nSasha\n\nFrom: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 1, 2012 5:20 AM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nHi Salvatore,\n\nLet me answer those to points.\n> 1) Defining how advanced service implementations (plugin or drivers) will serve API requests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\nThat part of \"service insertion\" seems to be quite clear.\n\n> 2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\nWhen I was talking about device management I primarily meant \"informing LBaaS about LB device: where it is located and how it is connected\".\nI still feel that\'s related to what you\'re talking about in (2). Our view is based on existing LBaaS workflow and I\'m trying to map it to your proposal or understand the basic differences.\n\nSo the questions will be:\n1) Why do we want to extend router resource?\nWhy do we need to know whether router provides certain resource or not?\nCurrently LBaaS can provide LB service if it has appropriate device, it doesn\'t depend on any router.\nIs it for adv svc quota management only?\n\n2) Why do we need to associate adv. service with a certain router?\nDid you mean we associate particular adv service appliance with a router?\nE.g. say we have device LB1 associated with router1, device LB2 associated with router2, is that what you meant?\nIf so, doest it makes sense to have many-to-many relationship between adv service appliances and routers?\nIf that\'s what you meant, then it\'s a part of \"device management\", e.g. \"informing LBaaS about LB device: where it is located and how it is connected\".\nIn this case when tenant request LB for certain network, Quantum will collect all available devices for the network (e.g. all devices attached to corresponding router) and chose the device to deploy LB for the tenant.\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 11:49 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nA few more comments inline!\n\nSalvatore\n\nOn 31 October 2012 19:21, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nSalvatore, thanks for detailed reply.\n\nBut still there are unclear points for me :(\n\n1. What does mean \"advanced service is created\". Don\'t we always have all advanced services which are provided by plugins configured in quantum.conf? I mean if we configured lbaas plugin in quantum.conf then tenant may call corresponding tenant API to request LB service. Is my understanding correct?\n\nMy mistake - english is not my language, unfortunately! I was referring to a tenant creating an instance of an advanced service, e.g.: POST /{whatever-the-prefix-is}/lb\n\n2. What happens when tenant calls /routers/<r_id>/enable_service ?\n\nThis is the most optional bit of the service insertion specification.\nAssume we have a router associated with a service type which gives you LB & Firewall. This means you can in theory create Load Balancers and Firewall associated with that router. A tenant however might decide to turn off that capability; frankly I do not see this as something necessary - it was in the specification just for completeness.\n\n\nOnce again, I\'ve tried to map this \"insertion\" to the workflow of how a tenant gets a service, but you\'re saying it\'s not about it, so I\'m trying to understand how services insertion affects our design and code at all.\n\nOh well - as you were talking about \"device management\" I understood you were talking about managing the pool of resources, physical or virtual, which provide the service to the tenant. If this is actually what you meant, I can confirm service insertion has nothing to do with it.\nService insertion tries to address the following problems\n\n1) Defining how advanced service implementations (plugin or drivers) will serve APIrequests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\n2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\n\nLet me explain the above two points with an example (sorry if that\'s boring)\n\n1) When a requests for a LB comes in, we need to understand how to dispatch it in the Quantum\'s plugin layer so that ultimately results in the configuration of the appropriate type of device (e.g.: a NetScaler or an HA Proxy instance).\n2) When a tenant creates a load balancer, we might want to associate it with a logical router (and hence the load balancer and the default gateway are the same thing) or we want to have it kind of standalone, acting independently from any logical router. Also when a LB is created we might specify a \"service type\" which could map to things such as Bronze, Silver, and Gold - which ultimately will lead to the selection of a provider versus another one.\n\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 9:14 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nHi Eugene,\n\nthanks for your feedback.\nPlease see my replies inline.\n\nOn 31 October 2012 13:32, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nHi Salvatore,\n\nI\'d like to give some feedback/questions based on yesterday\'s meeting discussion and your renewed http://wiki.openstack.org/Quantum/ServiceInsertion page.\n\nFirst of all, I think it\'s worth to fix the terminology just to avoid any confusion:\n\n- extension (API extension) - set of REST calls\n- plugin - code that implements certain API, works with quantum database, pushes calls to agents\n- core plugin - code that implements core API (networks, subnets, ports, L3)\n- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent\n- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices.\n\nEverything agreed, with the only exception that some flexibility might be allowed in the definition of agents/drivers. It is possible to think of a plugin which directly dispatches commands to drivers, rather than relying on agents. But this is probably just a detail.\n\n\nAnd very important detail, I think. Given the mention of \"layer\" in Eugene\'s terminology ( btw, thanks Eugene for initiating the \"terminology\" discussion ), was the intention that agent would expose \"device_type\" APIs (service resource abstraction) and drivers would map that to \"device_type_vendor\" API?  This essentially takes this \"multi service\" insertion discussion into equally important \"multi vendor\" discussion.\n\n\n\nSome thoughts on the Service Insertion proposal:\n\n1. It seems that multiplugin approach is the right way to move further compared to \"mixin\" approach where we inject and modify code of the core plugin.\nThis will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).\n\nI agree on the changes to the infrastructure. I\'d like to understand a little bit better what degree o plugin independency you\'d like to achieve.\n\nIf \"multi plugin\" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. ( Say \"port\" in core API is sort of extended in LBaaS as \"pool member\" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern?\n\n\n2. Having several implementations of the same service type.\nIf all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.\nThe options include:\n  1)  passing particular service impl as a url parameter\n  2)  having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json\n  3)  having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available\n\nIn the list above there\'s no mention of the service_type concept we discuss at the summit and which is also presented on the serviceinsertion wiki page. Do you deem it totally unreasonable?\n\n\nMy preference is (2): first of all, it \"splits\" whole API between core API and Adv Svc API, and also does so for different service type implementations.\nAlthough URIs may not be so short as we want them, that could prevent from naming collisions between different service types.\n\nI have some concerns about this approach, and the length of the URI is not one of them. The particular implementation of a load balancing plugin is directly surfaced, meaning that a user cannot transparently move from one plugin to another without having to rewrite their client applications - as this proposal implies that /lb_svc/lbaas_impl1 might have different spec from /lb_svc/lbaas_impl2. Also, one might wonder what\'s the point in this case of going through quantum at all: one can just send the calls to an endpoint which performs URL rewriting and then forwards the call to appropriate final endpoint. Finally, it is my opinion that this solution is tantamount to saying that you want multiple LBaaS solutions at the same time in the same cloud; I won\'t argue that this is not a reasonable use case, but I\'d prefer Quantum to present a single LBaaS interface rather than harbouring multiple solutions.\n\nIs is viable to have these different service implementations \"advertise\" properties  of that implementation, via an attribute (TBD) of the service object (VIF in case of LBaaS) so that tenant uses that information to chose implementation? In other words, choosing that property of the \"service\" object indicates the hint as to which implementation to use. Plugin then does the routing, and there are no APIs/URIs per implementation.\n\n\n\n\n3. Service Insertion:\nI was thinking about routed/floating-mode insertion and there is a certain thing I don\'t understand: the workflow.\nIt seems that the whole thing is somehow close to what we used to call \"device management\" in mirantis implementaion of lbaas, but it doesn\'t look like solving all device management tasks.\n\nActually, I don\'t think it is related at all to device management - assuming that I understand what you mean by device management. We are using this terminology to talk about insertion in the logical model, not the physical model. I think I clarified in the specification that we don\'t want to address device management in the service insertion blueprint. It is my opinion that this task is specific to particular advances services. For the LBaaS case, it necessarily requires a knowledge of physical and virtual appliance that I honestly do not have... so I\'ll gladly leave it to the load balancing experts :)\n\n\nSo in our implementation of LBaaS the workflow was as following:\n1) admin creates the device. Essentially it\'s just an instruction to LBaaS of where is the device (it\'s address), which type is it and credentials to manage it.\n2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration\n\nI think it is a reasonable workflow and goes back to the discussion around \"capabilities\" we were having during last week\'s call. I hope we agree that this is specific to LBaaS - I don\'t think service insertion has anything to do with it, as it looks just after the \"logical\" topology.\n\n\nIf we\'re talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):\n1) admin creates the device. The same as in lbaas - address, type, credentials\n2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration),\nconfigures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network\n\nThe solutions for \"stiching\" a device to a quantum network vary with the nature of the device, and with the way in which the service is inserted in the logical topology. I think what you said above is valid; in addition to that you might consider also other possibilities:\n1) using nova to plug services in quantum - which would work nicely for physical appliances\n2) leveraging an underlying layer-2 agent (which would be the same thing the l3 agent does)\n3) using the \"provider networks\" capability. This capability, in a nutshell, will allow you map a Quantum network, regardless of the technology Quantum uses.\n4) having a \"translator\" across service types (for instance GRE to VLAN or VXLAN to VLAN) - we don\'t have yet this on Quantum, but Kyle from Cisco has a very interesting blueprint on this topic: https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation\n\nIf we\'re talking about private balancer with Quantum, then:\n1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.\n2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required\n\nYeah... I agree there might be a case where a tenant creates a device. This is why we never make a clear distinction between tenant and admin APIs, but leave it configurable through the policy engine.\n\n\nIt would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be.\n\nI hope my explanation is satisfactory - which basically is that service insertion and device management have nothing in common.\n\n\nThanks,\nEugene.\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/d51235eb/attachment.html>\n\n','<CAJfiwORMgPdY+7ozLP6w96FbEbp19awBSXDwQsPEixearMZk7Q@mail.gmail.com>',NULL),('<07F4081FF032A44994850701DFF6CABE230FAEED@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 05:52:04',0,'2012-11-02 05:52:04',NULL,'[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion','Let me try to summarize the discussion below (possibly restating the obvious for some/most of the people). Salvatore and Eugene please validate and please propose terminology.\n\n  1.  \"Service insertion\" is about expressing services available to tenant (service catalog)\n  2.  Associating it (service catalog) with a \"router\" gives a hint as to how/where the service will be implemented. This hint is only consumed by plugin, but this association is not mandatory (in the absence of it you get a \"floating\"mode) as some plugins may not require this hint.\n  3.  There is a separate \"device lifecycle\" API dealing with plugging in physical/virtual devices and expressing their capabilities to support one or more services from the catalog.  This is then consumed by plugin for mapping tenant API \"service request\" to device configurations. \"Device lifecycle\" API may be also invoked from within the plugin (for instantiating virtual devices).\n  4.  Tenant API is about specifying a \"service request\" for one of the services from the catalog. It results in plugin configuring one or more physical/virtual devices, at the discretion of plugin and using whatever hints are specified during \"service catalog insertion\" and \"device lifecycle\" API calls. ( Actually my proposal at the summit was about tenant APIs, not service catalog insertion ).\n\nNow regarding:\n\nIf \"multi plugin\" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. ( Say \"port\" in core API is sort of extended in LBaaS as \"pool member\" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern?\n\n\n  *   Salvatore: I agree it\'s an important point, but probably not a huge concern. The plugins will be independent but not ignore each other. So I think it is still ok for a LB pool member to reference a port id from Quantum core. In Quantum core you can use the device_owner and the device_id fields to mark that port as used by a specific advanced service. We currently use those fields to prevent tenants from performing operations on the core API which will cause disruption to other services.\n\n  *   Eugene That\'s a good question. Deleting port could effectively disable a pool member while LBaaS will not know about it. We can think of some kind of NotifierAPI for such cases: plugins will subscribe to core resource changes and make corresponding changes in their DBs as well as changes in affected device configurations.\n\nSasha: Having plugins \"not ignore\" each other or subscribe to notifications from each other may get progressively more complex as new services/plugins are introduced. The root cause of this issue is that \"port\" and \"pool member\" are essentially two representations of the same resource ( in RESTful terms ), resource being VM (\"endpoint\"). This same VM is in quantum core given connectivity by plugging into network and in LBaaS it is indicated to be a member of a pool (group) which in turn is associated with VIF (LBPolicy/service). But with separate plugin databases they are two distinct resources, and additional integration overhead (notification mechanism above for example) is then introduced to actually keep them in sync. Instead of integration happening through single common data service shared among plugins, (N interfaces for N plugins) we may end up with N*(N-1) interfaces between each of the plugins, introducing potentially more complexity and tighter coupling as plugins will have to understand each other\'s data models. Something to consider but hopefully not at a cost of interfering with the quick progress based on the great work of the LBaaS team.\n\n( Food for thought: this same VM is going to be subject of security policies, and the question is how will security service model it in its APIs? . Adding new pool member will result in (at least) 3 calls: to Core, LBaaS and Security, each involving different representations of the same VM, and utilizing 6 subscriptions to keep them in sync. Hopefully I am missing a knowledge of some existing mechanism that makes this whole discussion \"false alarm\"  )\n\nThanks,\nSasha\n\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 1, 2012 4:35 PM\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nSasha,\nthanks for contributing to the discussion! I will start with answering Eugene\'s questions. Some comments on the points you\'ve raised can be found inline.\n\nEugene: When I was talking about device management I primarily meant \"informing LBaaS about LB device: where it is located and how it is connected\".\nI still feel that\'s related to what you\'re talking about in (2). Our view is based on existing LBaaS workflow and I\'m trying to map it to your proposal or understand the basic differences.\n\nSalvatore: While to some extent it is true that the \"service type\" ultimately determines the LB device, this does not happen directly. The service type identifies a \"class\" of devices, whereas the actual mapping of a logical load balancer to its concrete realization (which at some point must happen) is left to the plugin. From the tenant perspective, there is no interest in knowing any detail of the device serving the request (physical or virtual, vendor X vs vendor Y, etc.); all the tenant needs to know is that the chosen device satisfies its requirements.\n\nEugene: So the questions will be:\n1) Why do we want to extend router resource?\n\nSalvatore: We are not looking for extending the router resource. When we say that we insert an advanced service on a router, what we are really saying, to borrow Sasha\'s terminology, is that we are providing LB capabilities in a given L3 domain. The load balancer attached to a router will have access to the L3 domain of that router.\n\nEugene: Why do we need to know whether router provides certain resource or not?\n\nSalvatore: Not sure I understand this question. The router does not provide any kind of resource; more specifically we are not proposing that advanced services should be provided as a sub-resource of a router. The point we\'re making is that if one chooses to attach a service in routed mode - this means that service will run where the default gateway for your logical topology is, and so all the other services attached in routed mode. Then the service type should be the same for all the services, and can easily be specified by the router itself.\n\nConcrete examples are a VM that provides a bunch of services, from L3 forwarding to Load Balancing; as an example thing of the cloudstack\'s \"Virtual Router\"; another possible example is an integrated appliance such as an application delivery controller; the simple possible example is to think about Quantum\'s l3 agent augmented with more agents which perform firewall configuration with iptables and load balancing with haproxy.\n\nEugene: Currently LBaaS can provide LB service if it has appropriate device, it doesn\'t depend on any router.\nIs it for adv svc quota management only?\n\nSalvatore: From my understanding the current LBaaS API proposal (http://wiki.openstack.org/Quantum/LBaaS/API_1.0) focuses exclusively on the tenant-side APIs, where device details are hidden, as one might expect. Unfortunately I\'ve not been involved with LBaaS discussion as I should have so far, so I\'m not aware of any API proposal or POC code for device management. Nevertheless I am confident that none of what we\'re proposing we\'ll add unwanted constraints on tenant-facing APIs\n.\nEugene: 2) Why do we need to associate adv. service with a certain router?\n\nSalvatore: This is not necessary; it\'s an alternative to the \"standalone\", \"out-of-path\", or \"floating\" mode.\n\nEugene: Did you mean we associate particular adv service appliance with a router?\nE.g. say we have device LB1 associated with router1, device LB2 associated with router2, is that what you meant?\n\nSalvatore: Yes, but none of this would surface to tenant. Also the choice of LB1 and LB2 is up to the plugin, rather than to the Quantum API layer.\nFor instance a plugin might decide to not allocate any device to a router until a load balancer has actually been associated with it; another plugin might instead spin up a \"router VM\" for each logical Quantum router and then configure advanced services such as load balancing on that VM.\n\nEugene: If so, doest it makes sense to have many-to-many relationship between adv service appliances and routers?\nIf that\'s what you meant, then it\'s a part of \"device management\", e.g. \"informing LBaaS about LB device: where it is located and how it is connected\".\nIn this case when tenant request LB for certain network, Quantum will collect all available devices for the network (e.g. all devices attached to corresponding router) and chose the device to deploy LB for the tenant.\n\nSalvatore: I think your workflow is quite correct. I just was not regarding the process of selecting a particular device as \"device management\" as well.\nWith the only exception that the strategy for finding available devices should be left to the plugin rather than to the Quantum service. Also I don\'t want to risk confusion between logical and physical realms. \"all devices attached to the corresponding router\" sounds like you\'re referring to your physical infrastructure, and that is not the case.\nSo the same workflow you described, might be translated as:\n- tenant creates LB using Quantum LBaaS API\n- Quantum analyzes service type in tenant request\n- Quantum forwards request to appropriate plugin or driver (the or is mandatory as this is another design point still under review)\n- The selected plugin or driver chooses the appropriate device and associates tenant\'s logical LB with its concrete realization\n- The selected plugin or driver configures load balancing using device-specific interface\n\n\nOn 1 November 2012 21:03, Sasha Ratkovic <sasharatkovic at juniper.net<mailto:sasharatkovic at juniper.net>> wrote:\nEugene, Salvatore, thanks for great discussion!\n\nI am also looking forward to the answer regarding the semantics of associating \"service\" to (logical) \"router\".\n\nI also have some questions/clarifications below inline (way below, hence in green) , related to your earlier exchanges ?\n\nThanks,\nSasha\n\nFrom: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 1, 2012 5:20 AM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nHi Salvatore,\n\nLet me answer those to points.\n> 1) Defining how advanced service implementations (plugin or drivers) will serve API requests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\nThat part of \"service insertion\" seems to be quite clear.\n\n> 2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\nWhen I was talking about device management I primarily meant \"informing LBaaS about LB device: where it is located and how it is connected\".\nI still feel that\'s related to what you\'re talking about in (2). Our view is based on existing LBaaS workflow and I\'m trying to map it to your proposal or understand the basic differences.\n\nSo the questions will be:\n1) Why do we want to extend router resource?\nWhy do we need to know whether router provides certain resource or not?\nCurrently LBaaS can provide LB service if it has appropriate device, it doesn\'t depend on any router.\nIs it for adv svc quota management only?\n\n2) Why do we need to associate adv. service with a certain router?\nDid you mean we associate particular adv service appliance with a router?\nE.g. say we have device LB1 associated with router1, device LB2 associated with router2, is that what you meant?\nIf so, doest it makes sense to have many-to-many relationship between adv service appliances and routers?\nIf that\'s what you meant, then it\'s a part of \"device management\", e.g. \"informing LBaaS about LB device: where it is located and how it is connected\".\nIn this case when tenant request LB for certain network, Quantum will collect all available devices for the network (e.g. all devices attached to corresponding router) and chose the device to deploy LB for the tenant.\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 11:49 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nA few more comments inline!\n\nSalvatore\n\nOn 31 October 2012 19:21, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nSalvatore, thanks for detailed reply.\n\nBut still there are unclear points for me :(\n\n1. What does mean \"advanced service is created\". Don\'t we always have all advanced services which are provided by plugins configured in quantum.conf? I mean if we configured lbaas plugin in quantum.conf then tenant may call corresponding tenant API to request LB service. Is my understanding correct?\n\nMy mistake - english is not my language, unfortunately! I was referring to a tenant creating an instance of an advanced service, e.g.: POST /{whatever-the-prefix-is}/lb\n\n2. What happens when tenant calls /routers/<r_id>/enable_service ?\n\nThis is the most optional bit of the service insertion specification.\nAssume we have a router associated with a service type which gives you LB & Firewall. This means you can in theory create Load Balancers and Firewall associated with that router. A tenant however might decide to turn off that capability; frankly I do not see this as something necessary - it was in the specification just for completeness.\n\n\nOnce again, I\'ve tried to map this \"insertion\" to the workflow of how a tenant gets a service, but you\'re saying it\'s not about it, so I\'m trying to understand how services insertion affects our design and code at all.\n\nOh well - as you were talking about \"device management\" I understood you were talking about managing the pool of resources, physical or virtual, which provide the service to the tenant. If this is actually what you meant, I can confirm service insertion has nothing to do with it.\nService insertion tries to address the following problems\n\n1) Defining how advanced service implementations (plugin or drivers) will serve APIrequests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\n2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\n\nLet me explain the above two points with an example (sorry if that\'s boring)\n\n1) When a requests for a LB comes in, we need to understand how to dispatch it in the Quantum\'s plugin layer so that ultimately results in the configuration of the appropriate type of device (e.g.: a NetScaler or an HA Proxy instance).\n2) When a tenant creates a load balancer, we might want to associate it with a logical router (and hence the load balancer and the default gateway are the same thing) or we want to have it kind of standalone, acting independently from any logical router. Also when a LB is created we might specify a \"service type\" which could map to things such as Bronze, Silver, and Gold - which ultimately will lead to the selection of a provider versus another one.\n\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 9:14 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nHi Eugene,\n\nthanks for your feedback.\nPlease see my replies inline.\n\nOn 31 October 2012 13:32, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nHi Salvatore,\n\nI\'d like to give some feedback/questions based on yesterday\'s meeting discussion and your renewed http://wiki.openstack.org/Quantum/ServiceInsertion page.\n\nFirst of all, I think it\'s worth to fix the terminology just to avoid any confusion:\n\n- extension (API extension) - set of REST calls\n- plugin - code that implements certain API, works with quantum database, pushes calls to agents\n- core plugin - code that implements core API (networks, subnets, ports, L3)\n- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent\n- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices.\n\nEverything agreed, with the only exception that some flexibility might be allowed in the definition of agents/drivers. It is possible to think of a plugin which directly dispatches commands to drivers, rather than relying on agents. But this is probably just a detail.\n\n\nAnd very important detail, I think. Given the mention of \"layer\" in Eugene\'s terminology ( btw, thanks Eugene for initiating the \"terminology\" discussion ), was the intention that agent would expose \"device_type\" APIs (service resource abstraction) and drivers would map that to \"device_type_vendor\" API?  This essentially takes this \"multi service\" insertion discussion into equally important \"multi vendor\" discussion.\n\nIn a nutshell, the goal is to make Quantum both multi service and multi vendor. The terminology between agent and drivers needs to be explained better, and I would look like to use Quantum DHCP as an example. DHCP directly depends from the Quantum core plugin. It has an agent, which receives notification from the core plugin, and retrieves detailed information from it (such as IP allocation ranges); the agent then uses drivers for performing the actual configuration that will bring the DHCP service up. At the moment we only have a dnsmasq driver, but it is my understanding that a driver for ISC DHCP is underway too.\n\n\n\n\nSome thoughts on the Service Insertion proposal:\n\n1. It seems that multiplugin approach is the right way to move further compared to \"mixin\" approach where we inject and modify code of the core plugin.\nThis will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).\n\nI agree on the changes to the infrastructure. I\'d like to understand a little bit better what degree o plugin independency you\'d like to achieve.\n\nIf \"multi plugin\" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. ( Say \"port\" in core API is sort of extended in LBaaS as \"pool member\" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern?\n\nI agree it\'s an important point, but probably not a huge concern. The plugins will be independent but not ignore each other. So I think it is still ok for a LB pool member to reference a port id from Quantum core. In Quantum core you can use the device_owner and the device_id fields to mark that port as used by a specific advanced service. We currently use those fields to prevent tenants from performing operations on the core API which will cause disruption to other services.\n\n\n\n2. Having several implementations of the same service type.\nIf all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.\nThe options include:\n  1)  passing particular service impl as a url parameter\n  2)  having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json\n  3)  having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available\n\nIn the list above there\'s no mention of the service_type concept we discuss at the summit and which is also presented on the serviceinsertion wiki page. Do you deem it totally unreasonable?\n\n\nMy preference is (2): first of all, it \"splits\" whole API between core API and Adv Svc API, and also does so for different service type implementations.\nAlthough URIs may not be so short as we want them, that could prevent from naming collisions between different service types.\n\nI have some concerns about this approach, and the length of the URI is not one of them. The particular implementation of a load balancing plugin is directly surfaced, meaning that a user cannot transparently move from one plugin to another without having to rewrite their client applications - as this proposal implies that /lb_svc/lbaas_impl1 might have different spec from /lb_svc/lbaas_impl2. Also, one might wonder what\'s the point in this case of going through quantum at all: one can just send the calls to an endpoint which performs URL rewriting and then forwards the call to appropriate final endpoint. Finally, it is my opinion that this solution is tantamount to saying that you want multiple LBaaS solutions at the same time in the same cloud; I won\'t argue that this is not a reasonable use case, but I\'d prefer Quantum to present a single LBaaS interface rather than harbouring multiple solutions.\n\nIs is viable to have these different service implementations \"advertise\" properties  of that implementation, via an attribute (TBD) of the service object (VIF in case of LBaaS) so that tenant uses that information to chose implementation? In other words, choosing that property of the \"service\" object indicates the hint as to which implementation to use. Plugin then does the routing, and there are no APIs/URIs per implementation.\n\nI like the idea that different providers might advertise special properties of their implementation. In Quantum we use API extensions for plugin-specific features, and it is my opinion that this mechanisms can be extended (with some work) to advanced services. The tenant could query the \"service type\" to see what extensions are supported.\nThen using them as a mechanism for selecting the appropriate provider is something we can discuss. Surely if only \"provider X\" supports extension \"fooX\" and then it makes sense that if you use fooX in your request you want to use provider X. But there will still be cases of ambiguity, where a requests might be served by several providers... and I do not know how we should handle them.\n\n\n\n\n\n\n\n3. Service Insertion:\nI was thinking about routed/floating-mode insertion and there is a certain thing I don\'t understand: the workflow.\nIt seems that the whole thing is somehow close to what we used to call \"device management\" in mirantis implementaion of lbaas, but it doesn\'t look like solving all device management tasks.\n\nActually, I don\'t think it is related at all to device management - assuming that I understand what you mean by device management. We are using this terminology to talk about insertion in the logical model, not the physical model. I think I clarified in the specification that we don\'t want to address device management in the service insertion blueprint. It is my opinion that this task is specific to particular advances services. For the LBaaS case, it necessarily requires a knowledge of physical and virtual appliance that I honestly do not have... so I\'ll gladly leave it to the load balancing experts :)\n\n\nSo in our implementation of LBaaS the workflow was as following:\n1) admin creates the device. Essentially it\'s just an instruction to LBaaS of where is the device (it\'s address), which type is it and credentials to manage it.\n2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration\n\nI think it is a reasonable workflow and goes back to the discussion around \"capabilities\" we were having during last week\'s call. I hope we agree that this is specific to LBaaS - I don\'t think service insertion has anything to do with it, as it looks just after the \"logical\" topology.\n\n\nIf we\'re talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):\n1) admin creates the device. The same as in lbaas - address, type, credentials\n2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration),\nconfigures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network\n\nThe solutions for \"stiching\" a device to a quantum network vary with the nature of the device, and with the way in which the service is inserted in the logical topology. I think what you said above is valid; in addition to that you might consider also other possibilities:\n1) using nova to plug services in quantum - which would work nicely for physical appliances\n2) leveraging an underlying layer-2 agent (which would be the same thing the l3 agent does)\n3) using the \"provider networks\" capability. This capability, in a nutshell, will allow you map a Quantum network, regardless of the technology Quantum uses.\n4) having a \"translator\" across service types (for instance GRE to VLAN or VXLAN to VLAN) - we don\'t have yet this on Quantum, but Kyle from Cisco has a very interesting blueprint on this topic: https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation\n\nIf we\'re talking about private balancer with Quantum, then:\n1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.\n2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required\n\nYeah... I agree there might be a case where a tenant creates a device. This is why we never make a clear distinction between tenant and admin APIs, but leave it configurable through the policy engine.\n\n\nIt would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be.\n\nI hope my explanation is satisfactory - which basically is that service insertion and device management have nothing in common.\n\n\nThanks,\nEugene.\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121102/fa093b7a/attachment.html>\n\n','<CAGR=i3gdr2ntGyaOkOW=ELj=f9kYE2ssM7ncTNcnYAeNZLocJA@mail.gmail.com>',NULL),('<07F4081FF032A44994850701DFF6CABE230FB610@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 19:03:53',0,'2012-11-02 19:03:53',NULL,'[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion','\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Friday, November 2, 2012 2:23 AM\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\nOn 2 November 2012 05:52, Sasha Ratkovic <sasharatkovic at juniper.net<mailto:sasharatkovic at juniper.net>> wrote:\nLet me try to summarize the discussion below (possibly restating the obvious for some/most of the people). Salvatore and Eugene please validate and please propose terminology.\n\n  1.  \"Service insertion\" is about expressing services available to tenant (service catalog)\n\n+2\n\n  1.  Associating it (service catalog) with a \"router\" gives a hint as to how/where the service will be implemented. This hint is only consumed by plugin, but this association is not mandatory (in the absence of it you get a \"floating\"mode) as some plugins may not require this hint.\n\n+1, but I\'d say that any plugin does not necessarily need this hint, as you may have a default one.\n\n  1.  There is a separate \"device lifecycle\" API dealing with plugging in physical/virtual devices and expressing their capabilities to support one or more services from the catalog.  This is then consumed by plugin for mapping tenant API \"service request\" to device configurations. \"Device lifecycle\" API may be also invoked from within the plugin (for instantiating virtual devices).\n\n+2. Indeed I think that at this stage we\'re under no pressure at the moment for defining and implementing this API, as we should focus on the tenant API (as we\'re doing).\n\n  1.  Tenant API is about specifying a \"service request\" for one of the services from the catalog. It results in plugin configuring one or more physical/virtual devices, at the discretion of plugin and using whatever hints are specified during \"service catalog insertion\" and \"device lifecycle\" API calls. ( Actually my proposal at the summit was about tenant APIs, not service catalog insertion ).\n\n+2 - and yes I too was definitely under the impression that we were both talking about tenant APIs.\n\nNow regarding:\n\nIf \"multi plugin\" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. ( Say \"port\" in core API is sort of extended in LBaaS as \"pool member\" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern?\n\n\n  *   Salvatore: I agree it\'s an important point, but probably not a huge concern. The plugins will be independent but not ignore each other. So I think it is still ok for a LB pool member to reference a port id from Quantum core. In Quantum core you can use the device_owner and the device_id fields to mark that port as used by a specific advanced service. We currently use those fields to prevent tenants from performing operations on the core API which will cause disruption to other services.\n\n  *   Eugene That\'s a good question. Deleting port could effectively disable a pool member while LBaaS will not know about it. We can think of some kind of NotifierAPI for such cases: plugins will subscribe to core resource changes and make corresponding changes in their DBs as well as changes in affected device configurations.\n\nSasha: Having plugins \"not ignore\" each other or subscribe to notifications from each other may get progressively more complex as new services/plugins are introduced. The root cause of this issue is that \"port\" and \"pool member\" are essentially two representations of the same resource ( in RESTful terms ), resource being VM (\"endpoint\").\n\nI might argue that actual the \"pool member\" concept is a decorator of the \"port\" concept, and hence it might make sense to have a \"reference\" to it. The interesting point is that a pool member port is however a regular tenant port, and before that port was used for Load Balancing, it was a regular tenant port. So the device_owner concept won\'t probably work here. I agree notifications are complex, and might get more and more complex as the plugin grows. I am wondering whether this is the same case as a file opened by several processes, and hence we could solve it adding a reference count to resources.\n\n\nDecorator is good, and its semantics (decorates something) imply that there is some underlying mechanism that ensures referential integrity. I don\'t think there is such mechanism (yet) in quantum.\n\n\nThis same VM is in quantum core given connectivity by plugging into network and in LBaaS it is indicated to be a member of a pool (group) which in turn is associated with VIF (LBPolicy/service). But with separate plugin databases they are two distinct resources, and additional integration overhead (notification mechanism above for example) is then introduced to actually keep them in sync.\n\nI agree. You will end up with a reference to a port-id which could not be validated in terms of referential integrity. So when you delete the port either you have some logic as the notifications proposed by Eugene, or you\'ll end up with the LB service reporting a non-functional pool member, which perhaps isn\'t 100% bad after all.\n\n\nIf customers can live with that, so can I :)\n\nInstead of integration happening through single common data service shared among plugins, (N interfaces for N plugins) we may end up with N*(N-1) interfaces between each of the plugins, introducing potentially more complexity and tighter coupling as plugins will have to understand each other\'s data models. Something to consider but hopefully not at a cost of interfering with the quick progress based on the great work of the LBaaS team.\n\nThat would be just bad, and probably unnecessary.\n\nWhat I meant is that quantum may end up having to implement these dependencies - so \"bad\" may become necessary, unless the previous point (customer doesn\'t care) obsoletes this issue.\n\n\n\n( Food for thought: this same VM is going to be subject of security policies, and the question is how will security service model it in its APIs? . Adding new pool member will result in (at least) 3 calls: to Core, LBaaS and Security, each involving different representations of the same VM, and utilizing 6 subscriptions to keep them in sync. Hopefully I am missing a knowledge of some existing mechanism that makes this whole discussion \"false alarm\"  )\n\nThe only security mechanism we have so far are \"security groups\" which have just been merged into the API. They\'re really just an attribute of the port at the API level. At the moment, we\'re supposing that this service is provided by the core plugin, which probably make sense. However, there is an argument for separating it into its own plugin.\n\nGot it. In the end what matters is if plugins share the data model/db or not and in the current architecture they don\'t. With all associated pluses and minuses.\n\nIs there published API for \"security groups\" APIs ( the presentation on the blueprint has it, is that the one?  )\n\nThanks!\n\n\n\nThanks,\nSasha\n\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\n\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 1, 2012 4:35 PM\n\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nSasha,\nthanks for contributing to the discussion! I will start with answering Eugene\'s questions. Some comments on the points you\'ve raised can be found inline.\n\nEugene: When I was talking about device management I primarily meant \"informing LBaaS about LB device: where it is located and how it is connected\".\nI still feel that\'s related to what you\'re talking about in (2). Our view is based on existing LBaaS workflow and I\'m trying to map it to your proposal or understand the basic differences.\n\nSalvatore: While to some extent it is true that the \"service type\" ultimately determines the LB device, this does not happen directly. The service type identifies a \"class\" of devices, whereas the actual mapping of a logical load balancer to its concrete realization (which at some point must happen) is left to the plugin. From the tenant perspective, there is no interest in knowing any detail of the device serving the request (physical or virtual, vendor X vs vendor Y, etc.); all the tenant needs to know is that the chosen device satisfies its requirements.\n\nEugene: So the questions will be:\n1) Why do we want to extend router resource?\n\nSalvatore: We are not looking for extending the router resource. When we say that we insert an advanced service on a router, what we are really saying, to borrow Sasha\'s terminology, is that we are providing LB capabilities in a given L3 domain. The load balancer attached to a router will have access to the L3 domain of that router.\n\nEugene: Why do we need to know whether router provides certain resource or not?\n\nSalvatore: Not sure I understand this question. The router does not provide any kind of resource; more specifically we are not proposing that advanced services should be provided as a sub-resource of a router. The point we\'re making is that if one chooses to attach a service in routed mode - this means that service will run where the default gateway for your logical topology is, and so all the other services attached in routed mode. Then the service type should be the same for all the services, and can easily be specified by the router itself.\n\nConcrete examples are a VM that provides a bunch of services, from L3 forwarding to Load Balancing; as an example thing of the cloudstack\'s \"Virtual Router\"; another possible example is an integrated appliance such as an application delivery controller; the simple possible example is to think about Quantum\'s l3 agent augmented with more agents which perform firewall configuration with iptables and load balancing with haproxy.\n\nEugene: Currently LBaaS can provide LB service if it has appropriate device, it doesn\'t depend on any router.\nIs it for adv svc quota management only?\n\nSalvatore: From my understanding the current LBaaS API proposal (http://wiki.openstack.org/Quantum/LBaaS/API_1.0) focuses exclusively on the tenant-side APIs, where device details are hidden, as one might expect. Unfortunately I\'ve not been involved with LBaaS discussion as I should have so far, so I\'m not aware of any API proposal or POC code for device management. Nevertheless I am confident that none of what we\'re proposing we\'ll add unwanted constraints on tenant-facing APIs\n.\nEugene: 2) Why do we need to associate adv. service with a certain router?\n\nSalvatore: This is not necessary; it\'s an alternative to the \"standalone\", \"out-of-path\", or \"floating\" mode.\n\nEugene: Did you mean we associate particular adv service appliance with a router?\nE.g. say we have device LB1 associated with router1, device LB2 associated with router2, is that what you meant?\n\nSalvatore: Yes, but none of this would surface to tenant. Also the choice of LB1 and LB2 is up to the plugin, rather than to the Quantum API layer.\nFor instance a plugin might decide to not allocate any device to a router until a load balancer has actually been associated with it; another plugin might instead spin up a \"router VM\" for each logical Quantum router and then configure advanced services such as load balancing on that VM.\n\nEugene: If so, doest it makes sense to have many-to-many relationship between adv service appliances and routers?\nIf that\'s what you meant, then it\'s a part of \"device management\", e.g. \"informing LBaaS about LB device: where it is located and how it is connected\".\nIn this case when tenant request LB for certain network, Quantum will collect all available devices for the network (e.g. all devices attached to corresponding router) and chose the device to deploy LB for the tenant.\n\nSalvatore: I think your workflow is quite correct. I just was not regarding the process of selecting a particular device as \"device management\" as well.\nWith the only exception that the strategy for finding available devices should be left to the plugin rather than to the Quantum service. Also I don\'t want to risk confusion between logical and physical realms. \"all devices attached to the corresponding router\" sounds like you\'re referring to your physical infrastructure, and that is not the case.\nSo the same workflow you described, might be translated as:\n- tenant creates LB using Quantum LBaaS API\n- Quantum analyzes service type in tenant request\n- Quantum forwards request to appropriate plugin or driver (the or is mandatory as this is another design point still under review)\n- The selected plugin or driver chooses the appropriate device and associates tenant\'s logical LB with its concrete realization\n- The selected plugin or driver configures load balancing using device-specific interface\n\n\nOn 1 November 2012 21:03, Sasha Ratkovic <sasharatkovic at juniper.net<mailto:sasharatkovic at juniper.net>> wrote:\nEugene, Salvatore, thanks for great discussion!\n\nI am also looking forward to the answer regarding the semantics of associating \"service\" to (logical) \"router\".\n\nI also have some questions/clarifications below inline (way below, hence in green) , related to your earlier exchanges ?\n\nThanks,\nSasha\n\nFrom: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 1, 2012 5:20 AM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nHi Salvatore,\n\nLet me answer those to points.\n> 1) Defining how advanced service implementations (plugin or drivers) will serve API requests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\nThat part of \"service insertion\" seems to be quite clear.\n\n> 2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\nWhen I was talking about device management I primarily meant \"informing LBaaS about LB device: where it is located and how it is connected\".\nI still feel that\'s related to what you\'re talking about in (2). Our view is based on existing LBaaS workflow and I\'m trying to map it to your proposal or understand the basic differences.\n\nSo the questions will be:\n1) Why do we want to extend router resource?\nWhy do we need to know whether router provides certain resource or not?\nCurrently LBaaS can provide LB service if it has appropriate device, it doesn\'t depend on any router.\nIs it for adv svc quota management only?\n\n2) Why do we need to associate adv. service with a certain router?\nDid you mean we associate particular adv service appliance with a router?\nE.g. say we have device LB1 associated with router1, device LB2 associated with router2, is that what you meant?\nIf so, doest it makes sense to have many-to-many relationship between adv service appliances and routers?\nIf that\'s what you meant, then it\'s a part of \"device management\", e.g. \"informing LBaaS about LB device: where it is located and how it is connected\".\nIn this case when tenant request LB for certain network, Quantum will collect all available devices for the network (e.g. all devices attached to corresponding router) and chose the device to deploy LB for the tenant.\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 11:49 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nA few more comments inline!\n\nSalvatore\n\nOn 31 October 2012 19:21, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nSalvatore, thanks for detailed reply.\n\nBut still there are unclear points for me :(\n\n1. What does mean \"advanced service is created\". Don\'t we always have all advanced services which are provided by plugins configured in quantum.conf? I mean if we configured lbaas plugin in quantum.conf then tenant may call corresponding tenant API to request LB service. Is my understanding correct?\n\nMy mistake - english is not my language, unfortunately! I was referring to a tenant creating an instance of an advanced service, e.g.: POST /{whatever-the-prefix-is}/lb\n\n2. What happens when tenant calls /routers/<r_id>/enable_service ?\n\nThis is the most optional bit of the service insertion specification.\nAssume we have a router associated with a service type which gives you LB & Firewall. This means you can in theory create Load Balancers and Firewall associated with that router. A tenant however might decide to turn off that capability; frankly I do not see this as something necessary - it was in the specification just for completeness.\n\n\nOnce again, I\'ve tried to map this \"insertion\" to the workflow of how a tenant gets a service, but you\'re saying it\'s not about it, so I\'m trying to understand how services insertion affects our design and code at all.\n\nOh well - as you were talking about \"device management\" I understood you were talking about managing the pool of resources, physical or virtual, which provide the service to the tenant. If this is actually what you meant, I can confirm service insertion has nothing to do with it.\nService insertion tries to address the following problems\n\n1) Defining how advanced service implementations (plugin or drivers) will serve APIrequests, keeping in mind that for the same kind of service there might be multiple implementations available at the same time\n2) Defining the APIs and related logic for defining how advanced service fit in the logical topology (service insertion modes) and which services (type and nature) should be available to tenants.\n\nLet me explain the above two points with an example (sorry if that\'s boring)\n\n1) When a requests for a LB comes in, we need to understand how to dispatch it in the Quantum\'s plugin layer so that ultimately results in the configuration of the appropriate type of device (e.g.: a NetScaler or an HA Proxy instance).\n2) When a tenant creates a load balancer, we might want to associate it with a logical router (and hence the load balancer and the default gateway are the same thing) or we want to have it kind of standalone, acting independently from any logical router. Also when a LB is created we might specify a \"service type\" which could map to things such as Bronze, Silver, and Gold - which ultimately will lead to the selection of a provider versus another one.\n\n\nThanks,\nEugene.\n\n\nOn Wed, Oct 31, 2012 at 9:14 PM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nHi Eugene,\n\nthanks for your feedback.\nPlease see my replies inline.\n\nOn 31 October 2012 13:32, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\nHi Salvatore,\n\nI\'d like to give some feedback/questions based on yesterday\'s meeting discussion and your renewed http://wiki.openstack.org/Quantum/ServiceInsertion page.\n\nFirst of all, I think it\'s worth to fix the terminology just to avoid any confusion:\n\n- extension (API extension) - set of REST calls\n- plugin - code that implements certain API, works with quantum database, pushes calls to agents\n- core plugin - code that implements core API (networks, subnets, ports, L3)\n- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent\n- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices.\n\nEverything agreed, with the only exception that some flexibility might be allowed in the definition of agents/drivers. It is possible to think of a plugin which directly dispatches commands to drivers, rather than relying on agents. But this is probably just a detail.\n\n\nAnd very important detail, I think. Given the mention of \"layer\" in Eugene\'s terminology ( btw, thanks Eugene for initiating the \"terminology\" discussion ), was the intention that agent would expose \"device_type\" APIs (service resource abstraction) and drivers would map that to \"device_type_vendor\" API?  This essentially takes this \"multi service\" insertion discussion into equally important \"multi vendor\" discussion.\n\nIn a nutshell, the goal is to make Quantum both multi service and multi vendor. The terminology between agent and drivers needs to be explained better, and I would look like to use Quantum DHCP as an example. DHCP directly depends from the Quantum core plugin. It has an agent, which receives notification from the core plugin, and retrieves detailed information from it (such as IP allocation ranges); the agent then uses drivers for performing the actual configuration that will bring the DHCP service up. At the moment we only have a dnsmasq driver, but it is my understanding that a driver for ISC DHCP is underway too.\n\n\n\n\nSome thoughts on the Service Insertion proposal:\n\n1. It seems that multiplugin approach is the right way to move further compared to \"mixin\" approach where we inject and modify code of the core plugin.\nThis will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).\n\nI agree on the changes to the infrastructure. I\'d like to understand a little bit better what degree o plugin independency you\'d like to achieve.\n\nIf \"multi plugin\" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. ( Say \"port\" in core API is sort of extended in LBaaS as \"pool member\" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern?\n\nI agree it\'s an important point, but probably not a huge concern. The plugins will be independent but not ignore each other. So I think it is still ok for a LB pool member to reference a port id from Quantum core. In Quantum core you can use the device_owner and the device_id fields to mark that port as used by a specific advanced service. We currently use those fields to prevent tenants from performing operations on the core API which will cause disruption to other services.\n\n\n\n2. Having several implementations of the same service type.\nIf all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.\nThe options include:\n  1)  passing particular service impl as a url parameter\n  2)  having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json\n  3)  having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available\n\nIn the list above there\'s no mention of the service_type concept we discuss at the summit and which is also presented on the serviceinsertion wiki page. Do you deem it totally unreasonable?\n\n\nMy preference is (2): first of all, it \"splits\" whole API between core API and Adv Svc API, and also does so for different service type implementations.\nAlthough URIs may not be so short as we want them, that could prevent from naming collisions between different service types.\n\nI have some concerns about this approach, and the length of the URI is not one of them. The particular implementation of a load balancing plugin is directly surfaced, meaning that a user cannot transparently move from one plugin to another without having to rewrite their client applications - as this proposal implies that /lb_svc/lbaas_impl1 might have different spec from /lb_svc/lbaas_impl2. Also, one might wonder what\'s the point in this case of going through quantum at all: one can just send the calls to an endpoint which performs URL rewriting and then forwards the call to appropriate final endpoint. Finally, it is my opinion that this solution is tantamount to saying that you want multiple LBaaS solutions at the same time in the same cloud; I won\'t argue that this is not a reasonable use case, but I\'d prefer Quantum to present a single LBaaS interface rather than harbouring multiple solutions.\n\nIs is viable to have these different service implementations \"advertise\" properties  of that implementation, via an attribute (TBD) of the service object (VIF in case of LBaaS) so that tenant uses that information to chose implementation? In other words, choosing that property of the \"service\" object indicates the hint as to which implementation to use. Plugin then does the routing, and there are no APIs/URIs per implementation.\n\nI like the idea that different providers might advertise special properties of their implementation. In Quantum we use API extensions for plugin-specific features, and it is my opinion that this mechanisms can be extended (with some work) to advanced services. The tenant could query the \"service type\" to see what extensions are supported.\nThen using them as a mechanism for selecting the appropriate provider is something we can discuss. Surely if only \"provider X\" supports extension \"fooX\" and then it makes sense that if you use fooX in your request you want to use provider X. But there will still be cases of ambiguity, where a requests might be served by several providers... and I do not know how we should handle them.\n\n\n\n\n\n\n\n3. Service Insertion:\nI was thinking about routed/floating-mode insertion and there is a certain thing I don\'t understand: the workflow.\nIt seems that the whole thing is somehow close to what we used to call \"device management\" in mirantis implementaion of lbaas, but it doesn\'t look like solving all device management tasks.\n\nActually, I don\'t think it is related at all to device management - assuming that I understand what you mean by device management. We are using this terminology to talk about insertion in the logical model, not the physical model. I think I clarified in the specification that we don\'t want to address device management in the service insertion blueprint. It is my opinion that this task is specific to particular advances services. For the LBaaS case, it necessarily requires a knowledge of physical and virtual appliance that I honestly do not have... so I\'ll gladly leave it to the load balancing experts :)\n\n\nSo in our implementation of LBaaS the workflow was as following:\n1) admin creates the device. Essentially it\'s just an instruction to LBaaS of where is the device (it\'s address), which type is it and credentials to manage it.\n2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration\n\nI think it is a reasonable workflow and goes back to the discussion around \"capabilities\" we were having during last week\'s call. I hope we agree that this is specific to LBaaS - I don\'t think service insertion has anything to do with it, as it looks just after the \"logical\" topology.\n\n\nIf we\'re talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):\n1) admin creates the device. The same as in lbaas - address, type, credentials\n2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration),\nconfigures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network\n\nThe solutions for \"stiching\" a device to a quantum network vary with the nature of the device, and with the way in which the service is inserted in the logical topology. I think what you said above is valid; in addition to that you might consider also other possibilities:\n1) using nova to plug services in quantum - which would work nicely for physical appliances\n2) leveraging an underlying layer-2 agent (which would be the same thing the l3 agent does)\n3) using the \"provider networks\" capability. This capability, in a nutshell, will allow you map a Quantum network, regardless of the technology Quantum uses.\n4) having a \"translator\" across service types (for instance GRE to VLAN or VXLAN to VLAN) - we don\'t have yet this on Quantum, but Kyle from Cisco has a very interesting blueprint on this topic: https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation\n\nIf we\'re talking about private balancer with Quantum, then:\n1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.\n2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required\n\nYeah... I agree there might be a case where a tenant creates a device. This is why we never make a clear distinction between tenant and admin APIs, but leave it configurable through the policy engine.\n\n\nIt would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be.\n\nI hope my explanation is satisfactory - which basically is that service insertion and device management have nothing in common.\n\n\nThanks,\nEugene.\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121102/cfb33262/attachment.html>\n\n','<CAGR=i3hOX6j5Q6qBZLQ81JGaODJ2RMPAXxToQt3fSRq2L+-LwA@mail.gmail.com>',NULL),('<07F4081FF032A44994850701DFF6CABE2310F5F7@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 20:06:12',0,'2012-11-05 20:06:12',NULL,'[openstack-dev] [Quantum] Advanced service insertion','Edgar,\n\nOne question inline below:\n\nFrom: Edgar Magana (eperdomo) [mailto:eperdomo at cisco.com]\nSent: Monday, November 05, 2012 8:36 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum] Advanced service insertion\n\nSalvatore,\n\nFirst, let\'s do not focus this framework on just one kind of Service, I know that is your plan but I wanted to make an emphasizes  on that.\n\nAll agreed on the \"routed mode\".. Good job!\n\nOn the \"in-path\": From the networking point of view, a VM (service) could be connected between two networks in the same L2 domain and it is NOT considered \"routing\", basic networking concept. I did run this example last year with a Web Optimization service, the two interfaces in the service should be in \"stitching mode\" (IP is not needed). So, let\'s keep this insertion mode in our proposal.\n\n[Sasha] I think we need to be careful when we talk about \"service appliance (VM)\" and \"services\". Given that you say \"VM (service)\" which one are you implying? If it is \"service appliance\" should this be part of \"device lifecycle management\" API?\n\nOn the \"out-of-path\": This use case is too different from the previous one, in this one, we need L3 domain. The reason on having these three modes in because some services are available for any of these models, we need to be Generic in our proposal, otherwise we will let some services out of the picture for Quantum.\n\nI have already sent you a  webex meeting details for tomorrow at 10:00am PST right after the LBaaS meeting. Let me know if you can attend it.\n\nBTW. If you send me your figures in an editable format, I can draw the new ones and we could actually merged these two wikis in only one. I think we should do that.\n\nhttp://wiki.openstack.org/QuantumServicesInsertion\nhttp://wiki.openstack.org/Quantum/ServiceInsertion\n\nThanks,\n\nEdgar\n\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Monday, November 5, 2012 7:59 AM\nTo: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum] Advanced service insertion\n\nHi Edgar,\n\nplease see my replies inline.\nOn 2 November 2012 23:16, Edgar Magana (eperdomo) <eperdomo at cisco.com<mailto:eperdomo at cisco.com>> wrote:\nSalvatore,\n\nI am sorry it took me few days in collecting all the feedback for our team about the changes in your proposal but there are few guys here interested in this framework and instead of having multiples emails back and for, I decided to collect all the feedback. Actually, I think we are getting closer to an agreement but few things are not completely clear yet.\n\n1. The \"routed mode\" is just great. This is something that we missed in our proposal and we completely agree on it but this is not \"in-path\" service insertion, we can called routed mode or embedded mode but it is not the \"in-path\" one. Another question on this mode, how does the router know which networks will be affected for the respective service, or just all of the network behind that router entity will be affected?\n\nIt depends on what do you mean by \"affected\". What I meant is actually just that the router defines the \"scope\" of the advanced service being attached. And the scope in that case would be the L3 domain defined by the router and all subnets attached to it. However, whether an advanced service \"affects\" or not those subnets or particular ports on them is probably something that pertains the service itself. For instance, with Load Balancing, you explicitly nominate the ports that you want to be load balanced (pool members concepts). Similarly, I believe that an edge firewall service might apply to the entire domain; but it is completely normal that might be a service that applies only to a specific subnet (I\'m think of VPN hear, but bear in mind that I\'m thinking aloud!)\n\n\n\n2. Actually, the next mode in your wiki, the one that you call \"floating\" is the \"In-path\"  but you caveat, it should be just one L2 domain covered instead of two like in your diagram.\n\nI think there a slight difference as what we\'re describing here is both your \'in-path\' mode or another mode, where the advanced service is placed between two subnets and still does routing, but is not associated with the default gateway for your network. John Gruber has a good discussion of this an other use cases on his wiki page (http://wiki.openstack.org/NetworkLoadBalancingIntegrationsWithQuantum).\n\n3. The \"out-of-path\" insertion mode is missing, we need to have one case were the routing entity is forwarding packages to the \"Advance Service\", they get processed and then sent back to the router entity that will be delivering them to their final network(s).\n\nIsn\'t that what I\'m describing above? Could it be that in-path and out-of-path can be merged in the same use case? Or is there something fundamentally different?\n\n4. For the API definition, having a new resource just named \"Service\" should be fine, I think we should merge \"serviceType\" and \"ServiceDefinition\" in only one dictionary.\n\nI put them as two dicts to simplify the discussion, but I too do not see ServiceDefinition as worth becoming a resource on its own,\n\n\nPersonally, I want to understand more about it and maybe having a call between us will help, what do you think? Should we schedule a Service Insertion meeting to finalize the design this Monday?\n\nI think it makes sense to chat about this on Tuesday either during or after the LBaaS call. This is because in that call you\'ll find all the other people interested in this topic.\nI\'d like however to establish a reasonable subset of topic on which there\'s widespread agreement and start straight with the implementation. We need to give people implementing advanced service for Quantum a minimum framework for deploying them; once we have a minimum, but reasonable, set of framework to implement, we should keep having discussion on the remaining topic on which we have been unable to agree so far.\n\nI think that the choices to make, with regards to G-1 are:\n1) Which insertion modes support (this is from the tenant\'s perspective)\n2) What should be the best solution for dispatching API calls to the plugin (or plugins)?\n\nSalvatore\n\n\n\nThanks a lot,\n\nEdgar\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, October 30, 2012 8:11 AM\nTo: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum] Advanced service insertion\n\nHi,\n\nI have updated the specification for the service insertion trying the feedback from the community [3].\nI did my best to listen to the concerns expressed by Eugene and his team, which came out with this alternative spec [1].\nAlso, I did explicitly take into account also the thoughts contained in a presentation from Edgar at the Boston summit (related wiki page at [2])\n\nI am finishing up the last details, including a list of work items that reasonably needs to be addressed.\nI would like to leverage today\'s LBaaS meeting to sort out priorities, as load balancing is depending on this feature; but feel free to comment on this email thread or reach out to me on the IRC channel.\n\nRegards,\nSalvatore\n\n[1] wiki.openstack.org/Quantum/ServiceIntegration<http://wiki.openstack.org/Quantum/ServiceIntegration>\n[2] wiki.openstack.org/QuantumServicesInsertion<http://wiki.openstack.org/QuantumServicesInsertion>\n[3] http://wiki.openstack.org/Quantum/ServiceInsertion\nOn 27 October 2012 09:53, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\n\nOn 27 October 2012 02:29, Edgar Magana (eperdomo) <eperdomo at cisco.com<mailto:eperdomo at cisco.com>> wrote:\nSalvatore,\n\nIt would be great if you could include in this proposal the previous Services Insertion BP:\nhttps://blueprints.launchpad.net/quantum/+spec/services-insertion-wrapper\n\nIt is also fully described here:\nhttp://wiki.openstack.org/QuantumServicesInsertion\n\nI am aware of this blueprint, which was presented at the Essex summit in Boston. Within certain limits, the work that we\'ve done for presenting this new blueprint includes also the thoughts in that blueprint.\n\n\nI see a lot of common work between these two proposals, actually this one should be an extension of previous BP instead of having a new one. The mayor point of contribution in your BP is the API side that in the previous summit we decided to not targeted but for Grizzly is a great opportunity. So, in terms of common areas I found these ones:\n\nI looked for your blueprint, but could not find it. The reason for this, now that I see it, is that the blueprint is marked as implemented.\nI guess the code is in the Cisco plugin only?\n\nAnd I do apologise again for not giving you the right credit for this work. It was not our intention to \"steal\" work performed by other members of the community.\n\n\nYou described three insertion points: network-level, router-level and port-level. The first and the second ones are exactly on the same lines that what is explained in the previous BP named as: In-Path (Bump in the Wire) and Out-of-Path (Redirection) insertion models, the third one is a new one and I completely agree with it.\n\nAnd actually the port-level insertion is a bit out of topic in my blueprint as I think it is best described as attributes you apply to ports.\nI know the models are similar - you might now believe it, but I\'ve actually looked at your work :) - but also slightly different as the advanced services are not independent objects which are inserted in the topology. We left the topology very simple (logical routers + logical switches), which is also equivalent to the concepts of L3 domains and L2 domains proposed by Sasha.\n\n\nI don\'t think that floating IPs is really a good example of Services Insertion, it is just a functionality that it was needed for nova parity but a formal L3 service is indeed required. We could also take a look to the work that Sumit presented last summit:\nhttp://wiki.openstack.org/quantum-l3\n\n\nI\'m trying to be very programatic, and consider as L3 only the mere Layer-3 forwarding. This will allow us to define service offerings which can potentially have different providers for every possible functionality. This unless we decide that SNAT/DNAT are capabilities that should be offered by the basic L3 service. I think most, if not all, of the thoughts in Sumit\'s presentation are faithfully represented by the implementation that is shipped as an extension in Folsom.\n\nIn terms of Tenant vs Provider perspective, what is exactly the proposal? Is this API tenant facing, provider or both?\nI believe it should be for both, you can have services insertion at SP level and also per tenants.\n\nOn this topic I am also fairly open. We give a default policy, but then the actual roles will vary from deployment to deployment.\nThe idea is that admin will define the \"service offerings\", whereas tenants insert services in their logical L2/L3 networks. So for instance a tenant creates a router and chooses the service offering. In that service offering, the provider has specified which services the tenant can enable, and has also specified how those service should be provide (a detail that the tenant should not be concerned wide)\n\n\nAPI description in slide 10 is not really clear, I think we should just have one resource, SERVICE with all required CRUD operations, what do you think? Could you explain a little bit more on this area?\n\nScenario 1 in slide 14 is great, actually this is what we call In-Path service insertion, so we are in the same page.\n\nCorrect. The only difference is that the idea here is to not actually \"plug\" the service into the path between the router and the networks, but rather \"attach\" the service to the router itself.\nIt might seem only a technical detail, but the goal is to avoid the sprawling of complex virtual topologies which end up replicating the complexity of the physical data centre.\nThe L2/L3 topology which came out of the Folsom release, together with service insertion, represent a \"blueprint\" for a virtual network topology with rich capabilties; tenant can then define arbitrary topologies by replicating this \"blueprint\" (but this is post-grizzly work).\n\n\nScenario 2 in slide 15 is not very clear, how the traffic is redirected to the LB services in this example? Could you bring some light on this?\n\nYeah, as I said in the summit session I love to make things more complex than what they should be. The scenario I am describing on the right part of the slide would be one where you perform load balancing across ports on the same network (basically both the VIPs and the services are on the same network). This is what happens when you do load balancing in a \"Flat\" network - if you do that (one-arm) on a Quantum network, you\'ll end up with scenario 3.\n\n\nScenario 3 is actually the realistic one, is what we call Out-of-Path service insertion, so we are good there.\n\nYes. One difference I\'ve noticed is that in you blueprint all the services behind a gateway, which I believe is still part of the topology itself. In the slides you\'re referring to instead, the router providing load balancing only has VIPs attached directly to the external network.\n\n\nI think the API should be exclusively for managing services insertion but in slide 18 you mention \"Tenant APIs for handling services types\" what do you mean with that? How different is that one from the SP one?\n\nI am referring to the API for enabling or disabling services that the provider has made available within a service type.\n\n\nWe did not have enough time during the summit to discuss about this but I hope we can continue this discussion over the mailing list. This is a very exiting work and we want to work together on the development.\n\nThanks,\n\nEdgar Magana\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, October 23, 2012 5:15 PM\nTo: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n\nSubject: [openstack-dev] [Quantum] Advanced service insertion\n\nHi all,\n\nThe blueprint for advanced services insertion has been registered and can be found here: https://blueprints.launchpad.net/quantum/+spec/quantum-service-insertion\nThe design specification is about 75% complete - your feedback is more than welcome.\n\nPlease use this email thread for discussing design details, unless you feel there\'s a more suitable medium.\n\nRegards,\nSalvatore\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121105/26135d19/attachment.html>\n\n','<B95CD213E9A1E547966EE2BC016EEEB40E366A@xmb-aln-x05.cisco.com>',NULL),('<07F4081FF032A44994850701DFF6CABE23112FD5@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-08 20:14:55',0,'2012-11-08 20:14:55',NULL,'[openstack-dev] Quantum L3 router, mixin or plugin?','+1\n\nI would like to use Youcef\'s slide to illustrate this\n\nhttp://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+LBaaS+plugin+with+providers.png\n\nThe way I see it, the ask is for a Core plugin (containing L3 functionality) to support similar structure as advanced services plugin, I.e support different drivers (including physical devices).\n\n\n\nFrom: Gary Kotton <gkotton at redhat.com<mailto:gkotton at redhat.com>>\nOrganization: Red Hat\nReply-To: \"gkotton at redhat.com<mailto:gkotton at redhat.com>\" <gkotton at redhat.com<mailto:gkotton at redhat.com>>, OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 8, 2012 6:01 AM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] Quantum L3 router, mixin or plugin?\n\nOn 11/08/2012 03:33 PM, Bob Melander (bmelande) wrote:\nIn the wake of the recent discussion about service insertion, which seems to have landed in a decision to make each type of service (like LBaaS, FW, ?) a separate plugin, I want to raise the issue whether this approach shouldn\'t also be adopted for L3 router functionality. This is not the case now, where instead the server side is implemented as a L3_NAT_db_mixin class that basically each plugin inherits. The actual routing is implemented through the separate L3 agent (L3NATagent class) that relies on linux namespaces, the kernel IP forwarding functionality and IP tables.\n\n\nMy concern about this is the following: Suppose one would like to replace (or complement) that router implementation with something else, e.g., use a separate hardware-based router or add additional features like VRRP to the implementation.\n\nYay! VRRP will save endless amount of problems with the HA that we have the with the layer 3 agents. It would be great if we could add an open source solution and it would be beneficial for OpenStack as a whole.\n\n\nAs long as the changes can be contained within the l3 agent (while honoring the normal interface), it is fairly simple to just replace the default one with the extended l3 agent in the deployment.\n\nAgreed. This is just a matter of implementing the API\'s and this could be done today.\n\n\nHowever, if the desired functionality requires changes to the \"server side\", i.e.,  the L3_NAT_db_mixin class, the situation gets much more tricky since the mixin is essentially baked into the core plugin.\n\nI think that we need to discuss this further and see how we can provide a generic base to build upon.\n\n\n\nA way around this problem could be to provide the l3 routing functionality as a separate plugin, just as there will be separate plugins for LBaaS, FW, etc. With L3 routing also as a separate plugin, it seems to me it would be simpler to provide different such implementations, largely independent of (L2) core plugin but also to introduce additional L3 specific extensions.\n\nIt is a nice idea. We just need to ensure that we support the current l3 functionality.\n\n\n\nWhat is your view on this?\n\n/ Bob\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121108/b5006432/attachment.html>\n\n','<509BBB3E.1080702@redhat.com>',NULL),('<07F4081FF032A44994850701DFF6CABE23118EA1@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 23:37:37',0,'2012-11-15 23:37:37',NULL,'[openstack-dev] [quantum] Quantum extension framework issue','One comment: even though health_monitor is introduced as part of LB effort, it has more general applicability. So having it under LB specific resource may pose usability problems down the road when new services are introduced, if health monitor is to be re-used for that purpose.  One solution is to make it \"first class\" citizen with relationship to \"pool\" and/or make \"pool\" assume more abstract pooling semantics, reusable as well across multiple services in the future. (yes, I am talking about \"groups\" here :) ).\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 15, 2012 7:40 AM\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nThis is exactly what I was talking about.\nOne thing you might want to consider before choosing for one direction or the other is that at the moment Quantum API does not use sub resources at all.\nThere was a long discussion on this regard while designing the v2 API. The gist of the discussion was that if a resource needed sub-resources then there was a case for a sub-resource to become a \'first citizen\' in the API. I am pretty sure you already have mulled over whether health_monitors should be a resource of their own, a sub resource of the pool, or a multi-valued attribute of the pool, but I wanted to give you a heads-up anyway.\n\nOn your technical questions I have some answers inline.\n\nSalvatore\n\nOn 15 November 2012 15:40, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi folks,\n\nAs Salvatore said there is a way to specify parent for a resource (see quantum.extensions.extensions.ResourceExtension) which allows route mapping for rest calls like:\n\nPOST /v1.0/pools/{pool_id}/health_monitors\nDELETE /v1.0/pools/{pool_id}/health_monitors/{id}\n?\n\nIn this case corresponding resource controller should be aware of resource parent and be able to handle CRUD operations with an additional parent_id parameter.  Currently it doesn?t. Actually I am speaking about quantum.api.v2.base.Controller ? so, Salvatore, do you think it is the right place to include sub-resource/parent handling?\n\nWorking on controllers in quantum.api.v2 is the best option in my opinion.\nThis however depends on how the route mapper associates controllers with sub resources. Currently, the extension framework and the core API use two distinct code paths: the former uses quantum.extensions.extensions.ExtensionMiddleware whereas the latter uses quantum.api.v2.router.APIRouter (this is for historical reasons only; as far as I can recall, there\'s no technical reason for this). The Extension Middleware has a mechanism for mapping associating parent resources to a mapped resource, whereas the APIRouter does not have such mechanism.\n\nAs the controller does not care about how URI paths are mapped on its methods, the only thing we probably need to worry about is how to make sure that the parent resource id is passed to the controller for the sub-resource. To this aim, I would probably define a new controller which extends the base one rather than modifying quantum.api.v2.base.Controller.\nBtw, there is of course the hackish way of skipping base.create_resource and passing to ResourceExtension an object providing implementation for the appropriate methods. I am totally sure you\'re aware of this option too, but I would consider it only a last resort.\n\n\n\nAnd also how do you guys think should this improvement be done as a separate patch?\n\nSeparate patches in these cases are always preferred.\n\n\nThanks,\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>]\nSent: Wednesday, November 14, 2012 11:03 PM\n\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nOleg,\n\nThe ?/pools/{pool_id}/health_monitors? REST resource is intended to be a collection sub-resource of the ?/pools/{pool_id}? resource, so if the Quantum WSGI framework can be improved to support REST sub-resources that would be better and cleaner.\n\nYoucef\n\n\nFrom: Salvatore Orlando [mailto:sorlando at nicira.com]<mailto:[mailto:sorlando at nicira.com]>\nSent: Wednesday, November 14, 2012 10:00 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nWhen I read your first email, I had the same impression as Dan.\nhealth_monitors look more like a subresource than an action.\n\nThe WSGI framework at the moment is not able to manage subresources; this does not mean we cannot improve it though. Nevertheless, in this case the route mapping is not performed by the API classes in quantum/api, but by the extension manager. I think there should already be a way for specifying parent resources with extensions, but that needs to be explored.\n\nIt seems however that you are now trying to map operations on health monitors using distinct member actions (add_health_monitor, get_health_monitors). This is similar to what happens with the L3 API for router interfaces.\nHowever, it seems the original idea behind the API design was to treat health_monitors as an explicit collection, which would also be probably a more \'restful\' way of doing it. I think ultimately the question should be directed to Youcef and the team which contributed to the design of the LBaaS API.\nOn 14 November 2012 17:18, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi Dan,\nThanks for your comment here.\nJust wanted to correct a mistake in my first email: of course there can?t be a dict with duplicate keys. The idea was to use list of pairs, like:\nmember_actions = [{?health_monitors?: ?GET?},\n                                         {?health_monitors?: ?POST?}]\nto have an ability of using same function name with different request actions. Initially I thought that the framework provides such ability but does not dispatch requests correctly. I was wrong.\nActually there is no issue with the framework as it assumes using unique action names for different request methods.\n\nI believe we should update LBaaS REST API doc and use ?get_health_monitors?, ?add_health_monitors?, etc. to fit in the framework.\n\nThanks,\nOleg\n\nFrom: Dan Wendlandt [mailto:dan at nicira.com<mailto:dan at nicira.com>]\nSent: Wednesday, November 14, 2012 7:27 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nFolks from the API-subteam can correct me, but I believe this use model is outside of what the API framework was trying to enable with \"actions\".  The idea is that you use POST/DELETE to create an delete API \"resources\" (which actually have UUIDs, for example, the \"pool\" in your example below) and then do a PUT to an \"action\" to cause some kind of change that you can affect on a resource (e.g., \"add_health_monitor\" or \"remove_health_monitor\").  It sounds like what you are proposing is more treating \"health_monitors\" almost as a \"sub-resource\", which is not really what the \"actions\" stuff was designed for.\n\nI haven\'t been deeply involved in the LBaaS api design discussion though, so I\'d also like to hear from Salvatore, et al. on the API sub-team.\n\nDan\n\n\nOn Wed, Nov 14, 2012 at 6:05 AM, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi guys,\n\nWhile working on the API extension for LBaaS I didn?t find a way to use custom member actions if they have the same name and differ only by request method, for example\n\nList all health monitors of a specific pool: GET /pool/pool_id/health_monitors\nAssociate health monitors with a pool: POST /pool/pool_id/health_monitors\n\nIn quantum extension framework we pass ?health_monitors? as member actions for a controller (quantum.api.v2.base.create_resource())\n\nmember_actions = {\'health_monitors\': \'GET\',\n                                        \'health_monitors\': \'POST\'}\n\ncontroller = base.create_resource(collection_name,\n                                    resource_name,\n                                    plugin, params,\n                                    member_actions=member_actions)\n\nAccording to the Controller implementation it dispatches all custom member actions to its plugin attr:\n\ndef __getattr__(self, name):\n        if name in self._member_actions:\n            def _handle_action(request, id, body=None):\n                return getattr(self._plugin, name)(request.context, id, body)\n            return _handle_action\n        else:\n            raise AttributeError\n\nWhere request.context is of type quantum.context.Context and does not contain info about request method.\nAs a result there is no way to distinguish two custom actions in the plugin.\nIs it an issue in the framework?\n\nPossible solution may be in concatenation of request method and action name (?get_health_monitors?, ?post_health_monitors?) in a controller before dispatching them to a plugin.\nWhat do you think?\n\nThanks,\nOleg\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\nDan Wendlandt\nNicira, Inc: www.nicira.com<http://www.nicira.com>\ntwitter: danwendlandt\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121115/cb1c98df/attachment.html>\n\n','<CAGR=i3gbVM3N1LcFWqfpbRcfAiZeEFdBWaParf-h-VrXV=Ro7g@mail.gmail.com>',NULL),('<07F4081FF032A44994850701DFF6CABE231194F3@CH1PRD0511MB444.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 17:24:15',0,'2012-11-16 17:24:15',NULL,'[openstack-dev] [quantum] [LBaaS] Health monitors REST resource','Given that operations are clearly defined, I wouldn\'t change the name (and yes it would look ugly with \"_references\" ).\n\nFrom: Youcef Laribi <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Friday, November 16, 2012 9:04 AM\nTo: \'OpenStack Development Mailing List\' <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [quantum] [LBaaS] Health monitors REST resource\n\nChanging the subject line?\n\nHealth monitors ?/health_monitors/? are a top resource in the API and are retrieved/added/removed/updated through their CRUD operations on this top resource.\n\nThe subresource ?/pools/{pool_id}/health_monitors? is used for associating already existing health monitors (created above) with an existing pool, or for retrieving the health monitors associated with a pool. It is a collection (list) that only contain IDs of health monitors not the health monitors themselves. We can call this resource ?/pools/{pool_id}/health_monitor_references? or ?/pools/{pool_id}/pool_health_monitors? if we like, but I felt this was ugly and  I think there is no issue or ambiguity in the definition of API itself as all operations are clearly described. But if you think changing its name helps, I can do that :) Would like to hear what others in the team think.\n\nYoucef\n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com]\nSent: Friday, November 16, 2012 1:12 AM\nTo: Youcef Laribi; \'OpenStack Development Mailing List\'\nSubject: RE: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi guys,\n\nI just want to clarify some things regarding health monitors in LBaaS API: actually it is not completely a sub-resource of pool objects.\nAccording to the API it is a separate resource which can be added/showed/updated/deleted (with GET/POST.. ?/v1.0/health_monitors/..? rest calls) in order to be reusable in different pools and probably anywhere else as Sasha mentioned. Youcef please correct me if I am wrong here.\nSpeaking about sub-resources I think following rest call:\n\nPOST /v1.0/pools/{pool_id}/health_monitors\n\nis intended to create a sub-resource of health monitor for the pool and not to add an existing health monitor to the pool.\nAlso I think having health monitors as a separate resource and as a sub-resource of a pool at the same time is not correct.\nSo my vision is to leave health monitors as a separate resource and to use member actions for the purpose of getting/associating/disassociating health monitors with a pool:\nGet health monitors of a pool:\nGET /v1.0/pools/{pool_id}/get_health_monitors\nAssociate health monitors with a pool:\nPUT /v1.0/pools/{pool_id}/add_health_monitors\n\n{\n\n    \"health_monitors\" : [\n\n                         \"f3eeab00-8367-4524-b662-55e64d4cacb5\"\n\n                       ]\n\n}\nDisassociate health monitors from a pool:\nPUT /v1.0/pools/{pool_id}/delete_health_monitors\n\n{\n\n    \"health_monitors\" : [\n\n                         \"f3eeab00-8367-4524-b662-55e64d4cacb5\"\n\n                       ]\n\n}\n\nPlease share your thoughts.\n\nThanks,\nOleg\n\nFrom: Sasha Ratkovic [mailto:sasharatkovic at juniper.net]\nSent: Friday, November 16, 2012 3:38 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nOne comment: even though health_monitor is introduced as part of LB effort, it has more general applicability. So having it under LB specific resource may pose usability problems down the road when new services are introduced, if health monitor is to be re-used for that purpose.  One solution is to make it \"first class\" citizen with relationship to \"pool\" and/or make \"pool\" assume more abstract pooling semantics, reusable as well across multiple services in the future. (yes, I am talking about \"groups\" here :) ).\n\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, November 15, 2012 7:40 AM\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nThis is exactly what I was talking about.\nOne thing you might want to consider before choosing for one direction or the other is that at the moment Quantum API does not use sub resources at all.\nThere was a long discussion on this regard while designing the v2 API. The gist of the discussion was that if a resource needed sub-resources then there was a case for a sub-resource to become a \'first citizen\' in the API. I am pretty sure you already have mulled over whether health_monitors should be a resource of their own, a sub resource of the pool, or a multi-valued attribute of the pool, but I wanted to give you a heads-up anyway.\n\nOn your technical questions I have some answers inline.\n\nSalvatore\nOn 15 November 2012 15:40, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi folks,\n\nAs Salvatore said there is a way to specify parent for a resource (see quantum.extensions.extensions.ResourceExtension) which allows route mapping for rest calls like:\n\nPOST /v1.0/pools/{pool_id}/health_monitors\nDELETE /v1.0/pools/{pool_id}/health_monitors/{id}\n?\n\nIn this case corresponding resource controller should be aware of resource parent and be able to handle CRUD operations with an additional parent_id parameter.  Currently it doesn?t. Actually I am speaking about quantum.api.v2.base.Controller ? so, Salvatore, do you think it is the right place to include sub-resource/parent handling?\n\nWorking on controllers in quantum.api.v2 is the best option in my opinion.\nThis however depends on how the route mapper associates controllers with sub resources. Currently, the extension framework and the core API use two distinct code paths: the former uses quantum.extensions.extensions.ExtensionMiddleware whereas the latter uses quantum.api.v2.router.APIRouter (this is for historical reasons only; as far as I can recall, there\'s no technical reason for this). The Extension Middleware has a mechanism for mapping associating parent resources to a mapped resource, whereas the APIRouter does not have such mechanism.\n\nAs the controller does not care about how URI paths are mapped on its methods, the only thing we probably need to worry about is how to make sure that the parent resource id is passed to the controller for the sub-resource. To this aim, I would probably define a new controller which extends the base one rather than modifying quantum.api.v2.base.Controller.\nBtw, there is of course the hackish way of skipping base.create_resource and passing to ResourceExtension an object providing implementation for the appropriate methods. I am totally sure you\'re aware of this option too, but I would consider it only a last resort.\n\n\n\nAnd also how do you guys think should this improvement be done as a separate patch?\n\nSeparate patches in these cases are always preferred.\n\n\nThanks,\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>]\nSent: Wednesday, November 14, 2012 11:03 PM\n\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nOleg,\n\nThe ?/pools/{pool_id}/health_monitors? REST resource is intended to be a collection sub-resource of the ?/pools/{pool_id}? resource, so if the Quantum WSGI framework can be improved to support REST sub-resources that would be better and cleaner.\n\nYoucef\n\n\nFrom: Salvatore Orlando [mailto:sorlando at nicira.com]<mailto:[mailto:sorlando at nicira.com]>\nSent: Wednesday, November 14, 2012 10:00 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nWhen I read your first email, I had the same impression as Dan.\nhealth_monitors look more like a subresource than an action.\n\nThe WSGI framework at the moment is not able to manage subresources; this does not mean we cannot improve it though. Nevertheless, in this case the route mapping is not performed by the API classes in quantum/api, but by the extension manager. I think there should already be a way for specifying parent resources with extensions, but that needs to be explored.\n\nIt seems however that you are now trying to map operations on health monitors using distinct member actions (add_health_monitor, get_health_monitors). This is similar to what happens with the L3 API for router interfaces.\nHowever, it seems the original idea behind the API design was to treat health_monitors as an explicit collection, which would also be probably a more \'restful\' way of doing it. I think ultimately the question should be directed to Youcef and the team which contributed to the design of the LBaaS API.\nOn 14 November 2012 17:18, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi Dan,\nThanks for your comment here.\nJust wanted to correct a mistake in my first email: of course there can?t be a dict with duplicate keys. The idea was to use list of pairs, like:\nmember_actions = [{?health_monitors?: ?GET?},\n                                         {?health_monitors?: ?POST?}]\nto have an ability of using same function name with different request actions. Initially I thought that the framework provides such ability but does not dispatch requests correctly. I was wrong.\nActually there is no issue with the framework as it assumes using unique action names for different request methods.\n\nI believe we should update LBaaS REST API doc and use ?get_health_monitors?, ?add_health_monitors?, etc. to fit in the framework.\n\nThanks,\nOleg\n\nFrom: Dan Wendlandt [mailto:dan at nicira.com<mailto:dan at nicira.com>]\nSent: Wednesday, November 14, 2012 7:27 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\nHi Oleg,\n\nFolks from the API-subteam can correct me, but I believe this use model is outside of what the API framework was trying to enable with \"actions\".  The idea is that you use POST/DELETE to create an delete API \"resources\" (which actually have UUIDs, for example, the \"pool\" in your example below) and then do a PUT to an \"action\" to cause some kind of change that you can affect on a resource (e.g., \"add_health_monitor\" or \"remove_health_monitor\").  It sounds like what you are proposing is more treating \"health_monitors\" almost as a \"sub-resource\", which is not really what the \"actions\" stuff was designed for.\n\nI haven\'t been deeply involved in the LBaaS api design discussion though, so I\'d also like to hear from Salvatore, et al. on the API sub-team.\n\nDan\n\n\nOn Wed, Nov 14, 2012 at 6:05 AM, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\nHi guys,\n\nWhile working on the API extension for LBaaS I didn?t find a way to use custom member actions if they have the same name and differ only by request method, for example\n\nList all health monitors of a specific pool: GET /pool/pool_id/health_monitors\nAssociate health monitors with a pool: POST /pool/pool_id/health_monitors\n\nIn quantum extension framework we pass ?health_monitors? as member actions for a controller (quantum.api.v2.base.create_resource())\n\nmember_actions = {\'health_monitors\': \'GET\',\n                                        \'health_monitors\': \'POST\'}\n\ncontroller = base.create_resource(collection_name,\n                                    resource_name,\n                                    plugin, params,\n                                    member_actions=member_actions)\n\nAccording to the Controller implementation it dispatches all custom member actions to its plugin attr:\n\ndef __getattr__(self, name):\n        if name in self._member_actions:\n            def _handle_action(request, id, body=None):\n                return getattr(self._plugin, name)(request.context, id, body)\n            return _handle_action\n        else:\n            raise AttributeError\n\nWhere request.context is of type quantum.context.Context and does not contain info about request method.\nAs a result there is no way to distinguish two custom actions in the plugin.\nIs it an issue in the framework?\n\nPossible solution may be in concatenation of request method and action name (?get_health_monitors?, ?post_health_monitors?) in a controller before dispatching them to a plugin.\nWhat do you think?\n\nThanks,\nOleg\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\nDan Wendlandt\nNicira, Inc: www.nicira.com<http://www.nicira.com>\ntwitter: danwendlandt\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121116/cef10c1f/attachment-0001.html>\n\n','<7B14C05615DB43488B85E143995BD5490108201BE534@LONPMAILBOX01.citrite.net>',NULL),('<07FA9861-27BA-485D-B026-6067C5C79164@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-28 23:28:23',-25200,'2013-10-29 06:28:23',NULL,'[Openstack] Can\'t connect to RabbitMQ','Interesting, \nnever know about that\nthanks!\n\nOn Oct 28, 2013, at 13:44, Craig E. Ward <cward at isi.edu> wrote:\n\n> On the RabbitMQ server, are vhost and user id setup correctly?\n> \n> % rabbitmqctl list_users\n> \n> % rabbitmqctl list_vhosts\n> \n> The user and vhost should match what is in the OpenStack configurations.\n> \n> \n> \n> On 10/28/13 1:14 PM, Florian Lindner wrote:\n>> Am Montag, 28. Oktober 2013, 12:04:02 schrieb Razique Mahroua:\n>>> hey\n>>> is ?controller? a hostame all ur servers can resolve?\n>> \n>> Yes, set in /etc/hosts.\n>> \n>> Regards,\n>> Florian\n>> \n>>> \n>>> - Razique\n>>> \n>>> On Oct 28, 2013, at 11:40, Florian Lindner <mailinglists at xgm.de> wrote:\n>>>> Hello,\n>>>> \n>>>> I\'ve installed OpenStack on a Ubuntu 12.04 VM according to the install\n>>>> guide. It worked fine until I created the compute node on a second VM and\n>>>> tried to set up nova networking:\n>>>> \n>>>> http://docs.openstack.org/havana/install-guide/install/apt/content/nova-ne\n>>>> twork.html\n>>>> \n>>>> # nova network-create vmnet --fixed-range-v4=10.0.0.0/24 --bridge-\n>>>> interface=br100 --multi-host=T\n>>>> \n>>>> just does nothing until canceled. I tried on the controller and compute1\n>>>> node.\n>>>> \n>>>> nova-api.log shows:\n>>>> \n>>>> ERROR nova.openstack.common.rpc.common AMQP server on controller:5672 is\n>>>> unreachable: Socket closed. Trying again in 1 seconds.\n>>>> INFO nova.openstack.common.rpc.common Reconnecting to AMQP server on\n>>>> controller:5672\n>>>> \n>>>> controller:~# netstat -lpn | grep beam\n>>>> tcp        0      0 0.0.0.0:36595           0.0.0.0:*               LISTEN\n>>>> 1045/beam\n>>>> tcp6       0      0 :::5672                 :::*                    LISTEN\n>>>> 1045/beam\n>>>> \n>>>> It listens on this port, but IPv6. IMO on linux listing on an IPv6 port\n>>>> also means listening on the same v4 port.\n>>>> \n>>>> What\'s wrong with the installation?\n>>>> \n>>>> Thanks a lot!\n>>>> \n>>>> Florian\n>>>> \n>>>> _______________________________________________\n>>>> Mailing list:\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe :\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n> \n> -- \n> Craig E. Ward\n> University of Southern California\n> Information Sciences Institute\n> cward at ISI.EDU\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 535 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131028/84c69e33/attachment.pgp>\n\n','<526ECC90.6060800@ISI.EDU>',NULL),('<07FB92D3-E699-499B-974D-3F9AE296FB02@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-28 13:54:37',-28800,'2013-01-28 21:54:37',NULL,'[openstack-dev] orchestration of putting host in maintenance','\nOn Jan 28, 2013, at 12:58 PM, Alex Glikson <GLIKSON at il.ibm.com> wrote:\n\n> Hi all, \n> \n> As (some of) you know, a host can be put into maintenance mode by invoking \"host_update <host-xx> ?maintenance enable/disable\", which would disable future provisioning on this host, and would trigger migration of guest VMs to other hosts (e.g., within a host aggregate). Such requests are currently routed directly to the nova-compute on the corresponding node. The only implementation is available for Xen, delegating to XenAPI pool operations. \n> We have recently submitted a small patch directing the host maintenance requests to scheduler instead of nova-compute, aiming to enable wider range of implementations. A rather straightforward implementation that we had in mind could leverage the scheduler capabilities to find placement for VMs, and live migration capabilities to evacuate them. \n> During the review, an interesting perspective has been brought up, suggesting that such an orchestration is better to be implemented in the recently introduced nova-conductor, rather than in scheduler. \n> While I personally agree that scheduler might not be the best place for orchestration, I wonder whether nova-conductor is the right place, whether people think that it is mature enough to start becoming an orchestration component, and what would make most sense in the short term, to enable a more flexible host evacuation (in Grizzly, hopefully). I am aware of many use-cases where such capability would be of great value. \n> \n> https://review.openstack.org/#/c/19636/ \n> \n> Would appreciate your thoughts. \n\nI agree that it might not be the right long-term place for functionality like this but we haven\'t yet added any top-down calls to the conductor (everything is from the compute-node up), and until we move live-migration logic into the conductor I don\'t see any reason to put this functionality there. This seems closely tied with the migration code and I think both should be in the same place wherever they end up.\n\nVish\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130128/27b21c35/attachment.html>\n\n','<OFDD7846B9.BB0F3C70-ON85257B01.004E5599-C2257B01.00733F8C@il.ibm.com>',NULL),('<07FE7E51-9F06-46E9-BB7B-E6F9820DCE9A@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 07:58:06',-14400,'2014-09-18 11:58:06',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','\n> On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:\n> \n>> \n>> Linux distributions are not the end be all of distribution models and\n>> they don?t get to dictate to upstream.\n> \n> Well, distributions is where the final user is, and where software gets\n> consumed. Our priority should be the end users.\n\n\nDistributions are not the only place that people get their software from,\nunless you think that the ~3 million downloads requests has received\non PyPI in the last 30 days are distributions downloading requests to\npackage in their OSs.\n\n---\nDonald Stufft\nPGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140918/f4397b7f/attachment.html>\n\n','<541AC7E8.5040101@debian.org>',NULL),('<0807FF08-5BE0-4B59-B969-D4E2F3D555E5@bit-isle.co.jp>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2015-01-27 13:15:43',32400,'2015-01-27 04:15:43',NULL,'[OpenStack-docs] [Ambassadors] [training-guides][trainers] SF\n	User Group Training session','Hi Sean,\n\nWhen we translated these documents to Japanese, we?ve changed some part.\nBasically we added some detail procedure to the documents.\nBut we still not have merged it to upstream.\nAfter our next training, we will give some feedback.\nAnd if possible, we will use your survey on the next training.\n\nWe would like to add a script to the ppt document.\nCause the interpretation differs with different persons.\nIt?s better to be clear each slide what messages included etc..\n\nRegards,\n\nAkihiro\n\n> 2015/01/26 15:15?Sean Roberts <seanroberts66 at gmail.com> ?????\n> \n> I\'d love to know what changes you have made to the upstream training from current trunk. If you could use a similar survey we are using for your sessions, we could figure out how to make improvements. \n> \n> ~sean\n> \n>> On Jan 25, 2015, at 6:16 PM, Akihiro Hasegawa <hasegawa at bit-isle.co.jp> wrote:\n>> \n>> Hi Sean,\n>> \n>>> I am very interested in how the planning on the Tokyo Upstream Training is going.\n>> \n>> We\'ve just started our 3rd Tokyo Upstream Training event.\n>> On the next week, 3rd-4th Feb. , we have our annual event names OpenStack Days Tokyo.\n>> \n>> http://openstackdays.com/index_e.html\n>> \n>> In this event , we are planing to do the Tokyo Upstream Training again.\n>> On this time, we got 25 participants and 1st and 2nd time participants will be helping as the mentor.\n>> We?ve already announced the participants to prepare the training.\n>> The upstream training itself is deeply rooted in the Japanese community.\n>> But to increase contribution , we still need some support to the members of participant after a training.\n>> Takashi Torii from NEC, he is contributing a lot for this great success of Tokyo Upstream Training.\n>> Thanks Torii-san. ;)\n>> \n>> Regards,\n>> \n>> Akihiro \n>> \n>>> 2015/01/24 10:07?sean roberts <seanroberts66 at gmail.com> ?????\n>>> \n>>> We held our 4th training session using the training guides with about 110 trainees. The survey results are mixed so far, but I feel strongly we are moving in the right direction.http://www.meetup.com/openstack/photos/25865986/ I got a lot of very positive reviews in person. I will be running the next sessions using our camera and mics with google on-air, so the video will get uploaded to youtube directly. \n>>> \n>>> Survey results from the 22 Jan training session https://www.surveymonkey.com/results/SM-M9BQ5GZV/\n>>> \n>>> I am very interested in how the planning on the Tokyo Upstream Training is going.\n>>> \n>>> ~ sean\n>>> _______________________________________________\n>>> Ambassadors mailing list\n>>> Ambassadors at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/ambassadors\n>> \n\n\n\n','<A080AECF-0737-4BE7-9E9D-A12BA146C1EF@gmail.com>',NULL),('<0808BAF8-0841-4036-8618-35D2F9745F8B@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-25 16:45:47',-25200,'2013-10-25 23:45:47',NULL,'[openstack-dev] Remove vim modelines?','Interesting Background Information:\n\nWhy do we have modelines?\n\nTermie put them in all the files of the first version of nova\n\nWhy did he put in modelines instead of configuring his editor?\n\nTermie does a lot of python coding and he prefers a tabstop of 2 on all his personal projects[1]\n\nI really don\'t see much value outside of people who prefer other tabstops\n\n+1 to remove them\n\nVish\n\n[1] https://github.com/termie/git-bzr-ng/blob/master/git-bzr\nOn Oct 24, 2013, at 5:38 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n\n> Since the beginning of OpenStack we have had vim modelines all over the codebase, but after seeing this patch https://review.opeenstack.org/#/c/50891/ I took a further look into vim modelines and think we should remove them. Before going any further, I should point out these lines don\'t bother me too much but I figured if we could get consensus, then we could shrink our codebase by a little bit.\n> \n> Sidenote: This discussion is being moved to the mailing list because it \'would be better to have a mailing list thread about this rather than bits and pieces of discussion in gerrit\' as this change requires multiple patches.  https://review.openstack.org/#/c/51295/.\n> \n> \n> Why remove them?\n> \n> * Modelines aren\'t supported by default in debian or ubuntu due to security reasons: https://wiki.python.org/moin/Vim\n> * Having modelines for vim means if someone wants we should support modelines for emacs (http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables) etc. as well.  And having a bunch of headers for different editors in each file seems like extra overhead.\n> * There are other ways of making sure tabstop is set correctly for python files, see  https://wiki.python.org/moin/Vim.  I am a vIm user myself and have never used modelines.\n> * We have vim modelines in only 828 out of 1213 python files in nova (68%), so if anyone is using modelines today, then it only works 68% of the time in nova\n> * Why have the same config 828 times for one repo alone?  This violates the DRY principle (Don\'t Repeat Yourself).\n> \n> \n> Related Patches:\n> https://review.openstack.org/#/c/51295/\n> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z\n> \n> best,\n> Joe\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131025/934e3ed9/attachment.html>\n\n','<CAHXdxOfmuZyXeaCdxfBer_Kdg++1NChgrEUGjm9UYPq7vyD2FA@mail.gmail.com>',NULL),('<080AF6E2-A320-4E5B-9006-635CF9A618BD@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-28 14:11:58',25200,'2013-11-28 07:11:58',NULL,'[openstack-dev] [Mistral] Mistral PoC design','Hi Stackers,\n\nAs we recently wrote, we started working on Mistral PoC where we would like to demonstrate the very basic capabilities related to Task Orchestration and Scheduling. We now have a suggestion of a breakdown of Mistral PoC into high-level components and we?d like to discuss it with the community.\n\nPlease go to https://wiki.openstack.org/wiki/Mistral/Blueprints/PoC to take a look at the high-level picture of how we can approach PoC development. To check out DSL and API specifications (drafts) in order to understand better what Mistral is going to be please go to https://etherpad.openstack.org/p/MistralDSLSpecification and https://etherpad.openstack.org/p/MistralAPISpecification.\n\nLet us know what you agree with and, more important, you don?t agree with so that we could alter required things and continue to move in the right direction.\n\nAs usually, anyone is welcome to participate and contribute!\n\nThanks!\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131128/c5d86577/attachment.html>\n\n',NULL,NULL),('<080B8821CB979E47898DBADD01889AB339DAECCDD3@MSX8.ITRI.DS>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-13 09:38:20',28800,'2012-03-13 01:38:20',NULL,'[OpenStack Foundation] [Openstack] Foundation Structure:\n	An	Alternative','Just a thought? since you mentioned ?parliamentary structure?, how about a ?congress-like? structure which owns by two houses ? one (Senate-like) represents the interests of commercial companies (tiered corporate seats) and the other one (House of Representatives-like) represents the interests of development community (user seats, dev seats). Any policy could be proposed within each house but has to get approval by the other house. Each house could have the same seats (around 9~12) or maybe we can offer more corporate seats to get more funds but it still can be constrained and balanced by the other house no matter how many seats it is.\n\nToo complicated or not??\n\nSincerely,\n\nYoyo Chiang\n\nStrategy & Business Division\nCCMA / ITRI\nTel : +886-3-591-4561\nFax : +886-3-583-8246\nMobile : +886-988-580-206\nEmail : yoyochiang at itri.org.tw<mailto:yoyochiang at itri.org.tw>\n\nFrom: openstack-bounces+yoyochiang=itri.org.tw at lists.launchpad.net [mailto:openstack-bounces+yoyochiang=itri.org.tw at lists.launchpad.net] On Behalf Of Sean Roberts\nSent: Tuesday, March 13, 2012 7:04 AM\nTo: Joshua McKenty\nCc: foundation at lists.openstack.org; OpenStack; Thierry Carrez; Dallas Kashuba\nSubject: Re: [Openstack] [OpenStack Foundation] Foundation Structure: An Alternative\n\nAh, right. You are referring to a more parliamentary structure, where the membership of the board would be based on annual schedule and if a vote of no confidence is taken. I guess that could work, if that was what you meant. I would want a minimum of 6 months or so term as to keep the board from see sawing back and forth. We would want a high bar for the no confidence vote as well.\nI like having 9-12 people max in a meeting as a general rule. 20 generally means either a few speak or chaos.\nsean\nroberts\n\ninfrastructure strategy\n\nseanrob at yahoo-inc.com<applewebdata://2E35986A-DC2A-436F-BB4A-C451982006C2/seanrob at yahoo-inc.com>\ndirect 408-349-5234    mobile 925-980-4729\n\n701 first avenue, sunnyvale, ca, 94089-0703, us\nphone (408) 349 3300    fax (408) 349 3301\n\n\nOn 3/12/12 3:39 PM, \"Joshua McKenty\" <joshua at pistoncloud.com<mailto:joshua at pistoncloud.com>> wrote:\n\nI\'m on the look-out for emergent points of consensus, and I think I see one - Sean, you highlighted a 12-member board as being a target, and Dallas mentioned a concern about keeping the board a manageable size as well. Setting aside for a moment the composition (user seats, dev seats, tiered corporate seats vs. all elected, etc) - is a 12-seat board the target?\n\nA second question - how would you define a self-affiliated block of companies? I can imagine throwing my vote behind a shared candidate, but would I have the right to pull support during their term, or would I need to wait for the next election? Can we have a vote of no-confidence for such a representative? (I suppose we could always draft a side letter, but I\'m hoping for a general-purpose solution).\n\nHeidi\'s name is dirty enough as it is.\n\n--\nJoshua McKenty, CEO\nPiston Cloud Computing, Inc.\nw: (650) 24-CLOUD\nm: (650) 283-6846\nhttp://www.pistoncloud.com\n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\n\nOn Monday, March 12, 2012 at 11:55 AM, Sean Roberts wrote\n\n\n====================================================================\n???????????????????????????????????????????? \nThis email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20120313/380bd888/attachment-0001.html>\n\n','<CB83CD14.2030C%seanrob@yahoo-inc.com>',NULL),('<080E2CA6-0711-47A1-9386-4B57C4E997EA@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 13:34:20',-25200,'2014-04-07 20:34:20',NULL,'[openstack-dev] [oslo] use of the \"oslo\" namespace package','I dealt with this myself the other day and it was a huge pain. That said,\nchanging all the packages seems like a nuclear option. Is there any way\nwe could change python that would make it smarter about searching multiple\nlocations for namespace packages?\n\nVish\n\nOn Apr 7, 2014, at 12:24 PM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n\n> Some of the production Oslo libraries are currently being installed\n> into the \"oslo\" namespace package (oslo.config, oslo.messaging,\n> oslo.vmware, oslo.rootwrap, and oslo.version). Over the course of the\n> last 2 release cycles, we have seen an increase in the number of\n> developers who end up with broken systems, where an oslo library (most\n> often oslo.config) cannot be imported. This is usually caused by\n> having one copy of a library installed normally (via a system package\n> or via pip) and another version in \"development\" (a.k.a., \"editable\")\n> mode as installed by devstack. The symptom is most often an error\n> about importing oslo.config, although that is almost never the library\n> causing the problem.\n> \n> We have already worked around this issue with the non-production\n> libraries by installing them into their own packages, without using\n> the namespace (oslotest, oslosphinx, etc.). We have also changed the\n> way packages are installed in nova\'s tox.ini, to force installation of\n> packages into the virtualenv (since exposing the global site-packages\n> was a common source of the problem). And very recently, Sean Dague\n> changed devstack to install the oslo libraries not in editable mode,\n> so that installing from source should replace any existing installed\n> version of the same library.\n> \n> However, the problems seem to persist, and so I think it\'s time to\n> revisit our decision to use a namespace package.\n> \n> After experimenting with non-namespace packages, I wasn\'t able to\n> reproduce the same import issues. I did find one case that may cause\n> us some trouble, though. Installing a package and then installing an\n> editable version from source leaves both installed and the editable\n> version appears first in the import path. That might cause surprising\n> issues if the source is older than the package, which happens when a\n> devstack system isn\'t updated regularly and a new library is released.\n> However, surprise due to having an old version of code should occur\n> less frequently than, and have less of an impact than, having a\n> completely broken set of oslo libraries.\n> \n> We can avoid adding to the problem by putting each new library in its\n> own package. We still want the Oslo name attached for libraries that\n> are really only meant to be used by OpenStack projects, and so we need\n> a naming convention. I\'m not entirely happy with the \"crammed\n> together\" approach for oslotest and oslosphinx. At one point Dims and\n> I talked about using a prefix \"oslo_\" instead of just \"oslo\", so we\n> would have \"oslo_db\", \"oslo_i18n\", etc. That\'s also a bit ugly,\n> though. Opinions?\n> \n> Given the number of problems we have now (I help about 1 dev per week\n> unbreak their system), I think we should also consider renaming the\n> existing libraries to not use the namespace package. That isn\'t a\n> trivial change, since it will mean updating every consumer as well as\n> the packaging done by distros. If we do decide to move them, I will\n> need someone to help put together a migration plan. Does anyone want\n> to volunteer to work on that?\n> \n> Before we make any changes, it would be good to know how bad this\n> problem still is. Do developers still see issues on clean systems, or\n> are all of the problems related to updating devstack boxes? Are people\n> figuring out how to fix or work around the situation on their own? Can\n> we make devstack more aggressive about deleting oslo libraries before\n> re-installing them? Are there other changes we can make that would be\n> less invasive?\n> \n> Doug\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140407/90e82882/attachment.pgp>\n\n','<CADb+p3QsCq+TuxKdkKYNVbDuxJo6XVeRkXwE5zmh8WeHy9+nTg@mail.gmail.com>',NULL),('<080FC5F8-94A8-45C3-A181-35184314A447@adesso-mobile.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 09:29:48',0,'2013-08-12 09:29:48',NULL,'[Openstack] OpenStack without Floating IPs in Multi Host Setup','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/9b500b26/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: banner_signatur_dmexco2013_625x77.jpg\nType: image/jpeg\nSize: 59351 bytes\nDesc: banner_signatur_dmexco2013_625x77.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/9b500b26/attachment.jpg>\n\n','<CAO5CbpBcKvcU11z-ZxES=T37K8sxCRk0ptSsS_s+XM0NjDNfGg@mail.gmail.com>',NULL),('<08160C58-9E00-4F2F-9D1F-341C66F9ABD4@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 13:44:07',-14400,'2014-08-28 17:44:07',NULL,'[openstack-dev] [all] gate debugging','\nOn Aug 28, 2014, at 1:00 PM, Dean Troyer <dtroyer at gmail.com> wrote:\n\n> On Thu, Aug 28, 2014 at 11:48 AM, Doug Hellmann <doug at doughellmann.com> wrote:\n> In my case, a neutron call failed. Most of the other services seem to have a *-api.log file, but neutron doesn?t. It took a little while to find the API-related messages in screen-q-svc.txt (I?m glad I?ve been around long enough to know it used to be called ?quantum?). I get that screen-n-*.txt would collide with nova. Is it necessary to abbreviate those filenames at all?\n> \n> Cleaning up the service names has been a background conversation for some time and came up again last night in IRC.  I abbreviated them in the first place to try to get them all in my screen status bar, so that was a while ago...\n> \n> I don\'t think the current ENABLED_SERVICES is scaling well and using full names (nova-api, glance-registry, etc) will make it even harder to read.  May that is misplaced concern? I do think though that making the logfile names and locations more obvious in the gate results will be helpful.\n\nI usually use the functions for editing ENABLED_SERVICES. Is it still common to edit the variable directly?\n\n> \n> I\'ve started scratching out a plan to migrate to full names and will get it into an Etherpad soon.  Also simplifying the log file configuration vars and locations.\n\nCool. Let us know if we can make any changes in oslo.log to simplify that work.\n\nDoug\n\n> \n> dt\n> \n> -- \n> \n> Dean Troyer\n> dtroyer at gmail.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140828/e2690f87/attachment.html>\n\n','<CAOJFoEsav-NBGN55MqLTt0jZ+6MGCacpHd9o8NgdxgELwKkPaA@mail.gmail.com>',NULL),('<082755E8-FAF7-403A-836F-9876F0F5C5B5@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 00:03:45',25200,'2014-04-07 17:03:45',NULL,'[openstack-dev] [mistral] Community meeting minutes - 04/07/2014','Thanks for joining today?s meeting!\n\nAs usually,\n\nMinutes: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-07-16.00.html\nFull log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-04-07-16.00.log.html\n\nLet?s meet next time on April 14th.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/32dc9bb6/attachment.html>\n\n',NULL,NULL),('<082C649ED35F4209979AB8AD2306C671@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-14 07:33:26',3600,'2014-11-14 06:33:26',NULL,'[openstack-dev] [neutron] Is this fix introducing another\n different bug to dhcp-agent?','Wow Xu!, that was fast,  \n\nThank you very much.  \n\n\nMiguel ?ngel\najo @ freenode.net\n\n\nOn Friday, 14 de November de 2014 at 04:01, Xu Han Peng wrote:\n\n> I opened a new bug and submitted a fix for this problem since it was introduced by my previous patch.\n>  \n> https://bugs.launchpad.net/neutron/+bug/1392564\n> https://review.openstack.org/#/c/134432/\n>  \n> It will be great if you can have a look at the fix and comment. Thanks!\n>  \n> Xu Han\n>  \n> On 11/14/2014 05:54 AM, Ihar Hrachyshka wrote:\n> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert, Miguel, do you plan to take care of the bug and the fix, or you need help? RDO depends on the fix, also we should introduce the fix before the next Juno release that includes the bad patch, so I would be glad to step in if you don\'t have spare cycles. /Ihar On 13/11/14 16:44, Robert Li (baoli) wrote:  \n> > > Nice catch. Since it?s already merged, a new bug may be in order. ?Robert On 11/13/14, 10:25 AM, \"Miguel ?ngel Ajo\" <majopela at redhat.com (mailto:majopela at redhat.com) <mailto:majopela at redhat.com> (mailto:majopela at redhat.com)> wrote: I believe this fix to IPv6 dhcp spawn breaks isolated metadata when we have a subnet combination like this on a network: 1) IPv6 subnet, with DHCP enabled 2) IPv4 subnet, with isolated metadata enabled. https://review.openstack.org/#/c/123671/1/neutron/agent/dhcp_agent.py I haven?t been able to test yet, but wanted to share it before I forget. Miguel ?ngel ajo @ freenode.net (http://freenode.net)  \n> > >  \n> >  \n> > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUZSioAAoJEC5aWaUY1u57WvIH/0pEFnXwPF9dKGbmWGvxgURW Fec0SMxl544DUyKXfhy/fEJPiedAm63TcBbBRkcLrwrGrAI23iMvAi96tCuH/eb7 uYbgoDF16b6DGUg0V2bXh8OufpgoIn4T38Vwwr0MFhfxOLbux4QfK1MshsRF1XWx LnzmLLnDuJvEYF/gq9ifAA0ekQ+OdwYaKpTEyoVXZNuSJzJOkY8BnwjPQTuRStYG M1oBsIxO9j9C/fw1/lkIKasaq9Vmy5LtG+neOyQDzM6EjZrVKO+Z9ZbJnhlkIoaF fL8dKqDBzDbFbHpE/pHcUSR5lMnBkHWjsfqC6w8NKpEKnPW6UN88oipSoB9h7U4= =NfOp -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev  \n> >  \n>  \n>  \n> -- Thanks, Xu Han  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org)\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>  \n>  \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/67c1d49e/attachment.html>\n\n','<5465709D.9050205@gmail.com>',NULL),('<083ACD36-2CD2-426F-BBEE-82D55C4B581C@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-09 16:32:07',-28800,'2012-11-10 00:32:07',NULL,'[openstack-dev] Specifying Tenant-ID in Openstack REST API URLs\n	and Quatum 2.0 APIs','\nOn Nov 9, 2012, at 4:00 PM, David Hadas <david.hadas at gmail.com> wrote:\n> \n> Bottom line is that we can have authentication and authorization based on headers rather than the URI, but it is important to preserve the ability to create separate per-tenant name-spaces that do not rely on the resource URI to be supplied by the service. The natural way to do that is to keep tenant_id as part of the URI. \n> Otherwise the server would needs to concatenate the authenticated tenant_id, provided by the identity service with whatever the URI is, in order to reach a unique id of a resource... :/\n> \n> DH\n\nThis makes sense if uris are namable by users, but in order for this to be functional, we would have to allow users to choose a unique namespace for their objects (tenant-name?). I don\'t think that this should be the canonical name of the resource because it precludes the transfer of ownership of objects. The canonical url of the object should be unique, and in some cases this should involve namespacing, but for the objects that have a uuid, a uuid is sufficient. Note that this doesn\'t preclude us from having aliases that are more friendly.\n\nGET https://nova.example.com/servers/4fcd7e91-f532-4a12-98fa-d55e941aa87c could refer to the same object as:\n\nGET https://nova.example.com/servers/<tenant-id>/4fcd7e91-f532-4a12-98fa-d55e941aa87c\nGET https://nova.example.com/servers/<tenant-id>/myserver\nGET https://nova.example.com/servers/vishvananda/4fcd7e91-f532-4a12-98fa-d55e941aa87c\nGET https://nova.example.com/servers/vishvananda/myserver\n\nwhere my tenant-name is vishvanananda and the (tenant-unique) name of my server is myserver\n\nVish\n\n','<CALpPfV3TB5AT-zq=+j7MvXNsqLU_C=dWDXh_cELZytxXrO5M3A@mail.gmail.com>',NULL),('<083B614F-2FC0-4140-9DD9-43D97A1B4939@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-12 08:15:25',-25200,'2013-08-12 15:15:25',NULL,'[openstack-dev] Extension to volume creation (filesystem and\n	label)','This would need to happen on the cinder side on creation. I don\'t think it is safe for nova to be modifying the contents of the volume on attach. That said nova does currently set the serial number on attach (for libvirt at least) so the volume will show up as:\n\n/dev/disk/by-id/virtio-<uuid>\n\nAlthough the uuid gets truncated.\n\nVish\n\nOn Aug 10, 2013, at 10:11 PM, Greg Poirier <greg.poirier at opower.com> wrote:\n\n> Since we can\'t guarantee that a volume, when attached, will become a specified device name, we would like to be able to create a filesystem and label it (so that we can programmatically interact with it when provisioning systems, services, etc).\n> \n> What we are trying to decide is whether this should be the responsibility of Nova or Cinder. Since Cinder essentially has all of the information about the volume and is already responsible for creating the volume (against the configured backend), why not also give it the ability to mount the volume (assuming support for it on the backend exists), run mkfs.<filesystem_type>, and then use tune2fs to label the volume with (for example) the volume\'s UUID?\n> \n> This way we can programmatically do:\n> \n> mount /dev/disk/by-label/<UUID> /mnt/point\n> \n> This is more or less a functional requirement for our provisioning service, and I\'m wondering also:\n> \n> - Is anyone else doing this already?\n> - Has this been considered before?\n> \n> We will gladly implement this and submit a patch against Cinder or Nova. We\'d just like to make sure we\'re heading in the right direction and making the change in the appropriate part of Openstack.\n> \n> Thanks,\n> \n> Greg Poirier\n> Opower - Systems Engineering\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CANpjuCtEgYUsE7ti2ZD_2uRYbvbFO8zYneBvjAhpHGp+j2v6-g@mail.gmail.com>',NULL),('<083B6832-6C60-482A-8DF4-4C30ACF5AFFD@tenshu.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 20:48:51',0,'2014-01-07 20:48:51',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Hi\n\nAssuming we want to do this, but not necessarily agreeing that we do want to, I would suggest:\n\n1) I think it would be nice if we could avoid separate dpkg/rpm types by having a package type and reusing the package map facility.\n\n2) Clear up the source-repositories inconsistency by making it clear that multiple repositories of the same type do not work in source-repositories-nova (this would be a behaviour change, but would mesh more closely with the docs, and would require refactoring the 4 elements we ship atm with multiple git repos listed)\n\n3) extend arg_to_element to parse element names like \"nova/package\", \"nova/tar\", \"nova/file\" and \"nova/source\" (defaulting to source), storing the choice for later.\n\n4) When processing the nova element, apply only the appropriate entry in source-repositories-nova\n\n5) Keep install.d as-is and make the scripts be aware of the previously stored choice of element origin in the elements (as they add support for a package origin)\n\n6) Probably rename source-repositories to something more appropriate.\n\nAs for whether we should do this or not... like Clint I want to say no, but I\'m also worried about people forking t-i-e and not pushing their fixes/improvements and new elements back up to us because we\'re too diverged.\n\nIf this is a real customer need, I would come down in favour of doing it if the cost of the above implementation (or an alternate one) isn\'t too high.\n\nCheers,\n--\nChris Jones\n\n> On 7 Jan 2014, at 20:01, James Slagle <james.slagle at gmail.com> wrote:\n> \n> Hi,\n> \n> I\'d like to discuss some possible ways we could install the OpenStack\n> components from packages in tripleo-image-elements.  As most folks are\n> probably aware, there is a \"fork\" of tripleo-image-elements called\n> tripleo-puppet-elements which does install using packages, but it does\n> so using Puppet to do the installation and for managing the\n> configuration of the installed components.  I\'d like to kind of set\n> that aside for a moment and just discuss how we might support\n> installing from packages using tripleo-image-elements directly and not\n> using Puppet.\n> \n> One idea would be to add support for a new type (or likely 2 new\n> types: rpm and dpkg) to the source-repositories element.\n> source-repositories already knows about the git, tar, and file types,\n> so it seems somewhat natural to have additional types for rpm and\n> dpkg.\n> \n> A complication with that approach is that the existing elements assume\n> they\'re setting up everything from source.  So, if we take a look at\n> the nova element, and specifically install.d/74-nova, that script does\n> stuff like install a nova service, adds a nova user, creates needed\n> directories, etc.  All of that wouldn\'t need to be done if we were\n> installing from rpm or dpkg, b/c presumably the package would take\n> care of all that.\n> \n> We could fix that by making the install.d scripts only run if you\'re\n> installing a component from source.  In that sense, it might make\n> sense to add a new hook, source-install.d and only run those scripts\n> if the type is a source type in the source-repositories configuration.\n> We could then have a package-install.d to handle the installation\n> from the packages type.   The install.d hook could still exist to do\n> things that might be common to the 2 methods.\n> \n> Thoughts on that approach or other ideas?\n> \n> I\'m currently working on a patchset I can submit to help prove it out.\n> But, I\'d like to start discussion on the approach now to see if there\n> are other ideas or major opposition to that approach.\n> \n> -- \n> -- James Slagle\n> --\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAHV77z_NdriW5tqjnMAD-A7nzRPnaZo6ReO_zSRhttsmLo1x_g@mail.gmail.com>',NULL),('<0844DA1E-7D9E-4655-B470-0985BA117BCC@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 11:17:40',-18000,'2014-01-22 16:17:40',NULL,'[openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure\n	Management UI - Icehouse scoped wireframes','\nOn Jan 20, 2014, at 3:02 AM, Jaromir Coufal <jcoufal at redhat.com> wrote:\n\n> Hello everybody,\n> \n> based on feedback which I received last week, I am sending updated wireframes. They are still not completely final, more use-cases and smaller updates will occur, but I believe that we are going forward pretty well.\n> \n> http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-20_tripleo-ui-icehouse.pdf\n> \n> What has changed?\n> * \'Architecture\' dropdown was added for all node descriptions\n> * New views for Deployed and Free nodes\n> * Removed Configuration part from Deployment Overview page (will be happening under Configuration tab (under construction))\n> * Added progressing page of overcloud being deployed + Deployment Log\n> * Added Overcloud Horizon UI link to Deployment Overview page\n> * Added view for down-scaling (need more work)\n> * Added Implementation guide for developers\n> \n> New versions of wireframes, supporting other use-cases will occur in time, but I hope that without huge changes.\n> \n\nHi Jarda,\n\nNice job keeping up with all of the changes on these. They definitely look to me like they are getting to a state of reality for this release. Just a few nitpicks:\n\n1) Looking at page 6, the user can see that 1 node is down. I think it?s important that they can click on the link and be taken to the table to view details about this node. Would the table be filtered on the nodes that are down (just this one in this example)? I wonder if we should be consistent and add in a 33% of nodes are down?\n\n2) How does the user get back to the list of registered nodes after they?ve clicked on the ?Deployment Overview? section of navigation? It seems like they are floating a little bit in the navigation in pages 2-8. Would it make sense to have this be some sort of subsection of the Deployment Overview?\n\n3) Would the ?See and change defaults? link switch the user over to the configuration tab? I?m not sure this section even needs to be here if the user doesn?t see anything here in line.\n\nBest,\nLiz\n\n\n> Cheers\n> -- Jarda\n> \n> On 2014/16/01 01:50, Jaromir Coufal wrote:\n>> Hi folks,\n>> \n>> thanks everybody for feedback. Based on that I updated wireframes and\n>> tried to provide a minimum scope for Icehouse timeframe.\n>> \n>> http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf\n>> \n>> \n>> Hopefully we are able to deliver described set of features. But if you\n>> find something what is missing which is critical for the first release\n>> (or that we are implementing a feature which should not have such high\n>> priority), please speak up now.\n>> \n>> The wireframes are very close to implementation. In time, there will\n>> appear more views and we will see if we can get them in as well.\n>> \n>> Thanks all for participation\n>> -- Jarda\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52DCD80A.2010204@redhat.com>',NULL),('<0857543A-BD3A-47F4-A19D-37F358B3CCA6@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-25 11:51:36',21600,'2014-12-25 05:51:36',NULL,'[openstack-dev] [Mistral] Converging discussions on WF context\n	and WF/task/action inputs','\n> On 24 Dec 2014, at 23:37, W Chan <m4d.coder at gmail.com> wrote:\n> > 2) Retuning to first example:\n> > ...\n> >  action: std.sql conn_str={$.env.conn_str} query={$.query}\n> > ...\n> > $.env - is it a name of environment or it will be a registered syntax to getting access to values from env ?\n> I was actually thinking the environment will use the reserved word \"env\" in the WF context.  The value for the \"env\" key will be the dict supplied either DB lookup by name, by dict, or by JSON from CLI.\nOk, probably here?s the place where I didn?t understand you before. I thought ?env? here is just a arbitrary key that users themselves may want to have to just group some variables under a single umbrella. What you?re saying is that whatever is under ?$.env? is just the exact same environment that we passed when we started the workflow? If yes then it definitely makes sense to me (it just allows to explicitly access environment, not through the implicit variable lookup). Please confirm.\n\nOne thing that I strongly suggest is that we clearly define all reserved keys like ?env?, ?__actions? etc. I think it?d be better if they all started with the same prefix, for example, double underscore.\n\n> The nested dict for \"__actions\" (and all other keys with double underscore) is special system purpose, in this case declaring defaults for action inputs.  Similar to \"__execution\" where it\'s for containing runtime data for the WF execution.\n\nYes, that?s clear\n\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141225/3db6ea6a/attachment.html>\n\n','<CABNy8O6JD4KfavdNJjNDpLjiPckmQC2Ynkm6KzmCrurPF0YGqA@mail.gmail.com>',NULL),('<085B99ECA3DD455388354E0420A3D9DF@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 14:22:08',-14400,'2013-04-26 18:22:08',NULL,'[openstack-dev] Welcome to the \"OpenStack-dev\" mailing list','\n\nOn Friday, April 26, 2013 at 14:16 PM, JIANGANG Zhang wrote:\n\n> Hi Simo,\n> \n> Nice writeup. A couple of comments I have just in case:\n> \n\n\n+1\n\nAlso, welcome to the list.\n\nRegards,\nEric Windisch\n\n\n\n\n\n','<SNT142-W13FA9AA2F0782D1A78F006B8B70@phx.gbl>',NULL),('<08705036655b402b80d595641dc493f2@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 14:42:22',0,'2014-08-13 14:42:22',NULL,'[openstack-dev] [neutron] Rotating the weekly Neutron meeting','+1  and Like\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-----Original Message-----\nFrom: Gary Kotton [mailto:gkotton at vmware.com] \nSent: Wednesday, August 13, 2014 8:07 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting\n\nHuge +1\n\nOn 8/13/14, 5:19 PM, \"Paul Michali (pcm)\" <pcm at cisco.com> wrote:\n\n>+1\n>\n>PCM (Paul Michali)\n>\n>MAIL ?..?. pcm at cisco.com\n>IRC ??..? pcm_ (irc.freenode.com)\n>TW ???... @pmichali\n>GPG Key ? 4525ECC253E31A83\n>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>\n>\n>\n>On Aug 13, 2014, at 10:05 AM, Kyle Mestery <mestery at mestery.com> wrote:\n>\n>> Per this week\'s Neutron meeting [1], it was decided that offering a \n>> rotating meeting slot for the weekly Neutron meeting would be a good \n>> thing. This will allow for a much easier time for people in \n>> Asia/Pacific timezones, as well as for people in Europe.\n>> \n>> So, I\'d like to propose we rotate the weekly as follows:\n>> \n>> Monday 2100UTC\n>> Tuesday 1400UTC\n>> \n>> If people are ok with these time slots, I\'ll set this up and we\'ll \n>> likely start with this new schedule in September, after the FPF.\n>> \n>> Thanks!\n>> Kyle\n>> \n>> [1]\n>>http://eavesdrop.openstack.org/meetings/networking/2014/networking.201\n>>4-0\n>>8-11-21.00.html\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D01152D1.1F36F%gkotton@vmware.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540027609@BY2PRD0810MB391.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 16:25:06',0,'2013-05-30 16:25:06',NULL,'[openstack-dev] [Ask OpenStack] \"How does openstack handle\n	blade server?\"','Tom,\nThanks for your answer.\nMy idea would be\nIf we can have an open interface to the blade server/chassis following the open ATCA spec:\n\nhttp://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=2\n\nto take advantage of the good features of ATCA and  at the same time treat the multiple entities in the chassis as a whole (e.g. HostAggregates). HostAggregates, or MultiClusterZones seem a little weak here.\n\nThanks,\n\nQing\n\nFrom: openstack at ask.openstack.org [mailto:openstack at ask.openstack.org]\nSent: Thursday, May 30, 2013 3:07 AM\nTo: Qing He\nSubject: [Ask OpenStack] \"How does openstack handle blade server?\"\n\n\n\nfifieldt<https://ask.openstack.org/users/64/fifieldt/> posted an answer<https://ask.openstack.org/question/1502/how-does-openstack-handle-blade-server/?answer=1719#post-id-1719>.\n\nAnswered by fifieldt:\n\nHi,\n\nThe simple answer is that right now, OpenStack does not treat blades in any special way.\n\nIf the hypervisor in use is blade aware, this may make a difference, but in general each server appears as a server. It is possible to group servers together into HostAggregates (http://docs.openstack.org/trunk/openstack-compute/admin/content/host-aggregates.html) to take some different action scheduling-wise, or manage taking entire blade chassis offline at the same time.\n\nIt sounds like you have a good idea of the actions that can be performed with blade servers that OpenStack could be taking advantage of. It would be great to get you to share your ideas with the OpenStack developers to improve the current situation. The development mailing list is found here: https://wiki. openstac k.org/wiki/MailingLists#Future_Development<https://wiki.openstack.org/wiki/MailingLists#Future_Development>\n\nIn reply to qhe\'s question: How does openstack handle blade server?\n\nTags: blade_server, hirarchical_scheme.\n\nA blade server host a chasis of blades, computing, networking, storage, etc. These blades are managed as awhole usually. Does openstack have hirarchical management/operational scheme? Does it handle plugin such a scheme?\n\n======= Full thread summary =======\n\nQuestion : How does openstack handle blade server?\n\nTags: blade_server, hirarchical_scheme.\n\nA blade server host a chasis of blades, computing, networking, storage, etc. These blades are managed as awhole usually. Does openstack have hirarchical management/operational scheme? Does it handle plugin such a scheme?\n\ncomment:\n\nCommented by qhe:\n\nFurther more, how does the openstack know if two blades are configured in a redundancy group (one is a hot standy of the other)?\n\nPlease note - you can easily change<https://ask.openstack.org/users/583/qhe/subscriptions/> how often you receive these notifications or unsubscribe. Thank you for your interest in our forum!\n\n\n________________________________\n\nSincerely,\nAdministrator\n\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130530/b4ca53a5/attachment.html>\n\n','NA-1719-openstack@ask.openstack.org',NULL),('<08751C58B8AC2D45AC34FC099D5DD54002D042@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 20:14:54',0,'2013-05-31 20:14:54',NULL,'[openstack-dev] [Nova] Proposal to add Brian Elliott\n	to	nova-core','+1\n\n\n\n\n\n','<51A90403.9060601@draigBrady.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD54002F21A@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-03 22:02:22',0,'2013-06-03 22:02:22',NULL,'[openstack-dev] Horizon Core Nominees','+1\n\n-----Original Message-----\nFrom: Gabriel Hurley [mailto:Gabriel.Hurley at nebula.com] \nSent: Monday, June 03, 2013 2:57 PM\nTo: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)\nSubject: [openstack-dev] Horizon Core Nominees\n\nI\'d like to nominate the following two developers to Horizon Core status:\n\nDavid Lyle\nLin Hua Cheng\n\nThey\'ve both been doing great work both in terms of development themselves and code review for others, and they have consistently demonstrated their engagement and commitment to the OpenStack community at large.\n\nIf anyone objects you may reply either publicly or privately to me. Shows of support are also welcome, as they always make people feel good. :-)\n\nIf there are no objections I will add them to the core list by the end of the week.\n\nThanks!\n\n    - Gabriel\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<ca48f7948ff44bedab7dde1ee98e024e@BN1PR05MB044.namprd05.prod.outlook.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD54003D3E3@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 20:50:14',0,'2013-06-17 20:50:14',NULL,'[openstack-dev] [metrics] Code contribution by 3rd party\n consultant on behalf of a corporation','[Qing] my  one cent:\n\n-----Original Message-----\nFrom: Monty Taylor [mailto:mordred at inaugust.com] \nSent: Monday, June 17, 2013 1:39 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [metrics] Code contribution by 3rd party consultant on behalf of a corporation\n\nIt depends on a little bit on where you want the stats to show up.\n\nIn gitdm, there is already a place you can put a date range on a person to attach them to a company. I\'d start with just putting an entry into the gitdm files showing that, for instance, Contractor A worked for Company B for the Month of May.\n\nIf you think it\'s conceivable that a single contractor might be working in parallel for more than one company at the same time and that we might want to track that patch C was done for Company B but patch D was done for Company E, we might need to look in to something more complex - but honestly, that seems like a kindof unlikley situation, no?\n\n[Qing] In one situation this could happen: Contractor A gets work from multiple companies and deals out tasks (e.g., offshore) and all the tasks dealt out would be checked in under contractor A when finished.\n\nOn 06/17/2013 04:33 PM, Chan, Winson C wrote:\n> Metrics team,\n> \n>  \n> \n> Is there a best practice for counting commits made by a 3^rd party \n> consultants/contractors (with multiple affiliations) on behalf of \n> another corporation?  I recently had a conversation with Stefano and \n> he suggested adding a \"Contributed for: <affiliation>\" in the commit \n> message.  Stefano recommended that I get the dialog started here...\n> \n>  \n> \n> Thanks.\n> \n> Winson\n> \n>  \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<51BF73CF.7060800@inaugust.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD54003FFAB@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 16:18:43',0,'2013-06-19 16:18:43',NULL,'[openstack-dev] Quantum\'s new name is….','The rationale behind it would be interesting ...\n\n-----Original Message-----\nFrom: Mark McClain [mailto:mark.mcclain at dreamhost.com] \nSent: Wednesday, June 19, 2013 9:14 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] Quantum\'s new name is?.\n\nAll-\n\nThe OpenStack Networking team is happy to announce that the Quantum project will be changing its name to Neutron. You\'ll soon see Neutron in lots of places as we work to implement the name change within OpenStack.\n\nmark\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<6E602D07-A738-4277-AE2A-E6835DC0D8AB@dreamhost.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540040113@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 20:33:25',0,'2013-06-19 20:33:25',NULL,'[openstack-dev] Quantum\'s new name is….','Thanks.  I?m wondering if the original maker of QNX ?Quantum software Systems, had a problem with the hard drive maker too:\n\nhttp://www.princeton.edu/~achaney/tmve/wiki100k/docs/QNX.html\n\nFrom: Jay Buffington [mailto:me at jaybuff.com]\nSent: Wednesday, June 19, 2013 10:55 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Quantum\'s new name is?.\n\nOn Wed, Jun 19, 2013 at 9:18 AM, Qing He <Qing.He at radisys.com<mailto:Qing.He at radisys.com>> wrote:\nThe rationale behind it would be interesting ...\n\nMy understanding is that the Quantum corporation (harddrive manufacturer) asserted\ntheir trademark rights, so the name had to be changed.\n\nSee https://lists.launchpad.net/openstack/msg22544.html\n\nJay\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/b1d9b9c1/attachment.html>\n\n','<CAGezO6FfwohwfR=b47C7Zz45pr-KmYuLUvt=chCyWmwYwWJ+=Q@mail.gmail.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540041487@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-21 18:10:30',0,'2013-06-21 18:10:30',NULL,'[openstack-dev] Efficiently pin running VMs to physical CPUs\n automatically','\nRussell,\nThat\'s great initiative!  I\'m wondering if a framework/abstraction layer can be built so that different algorithms can be plugged in. I\'m sure we can learn from the none-vm world:\nhttp://en.wikipedia.org/wiki/Processor_affinity\n\nThanks,\nQing\n\n> \n> -----Original Message-----\n> From: Russell Bryant [mailto:rbryant at redhat.com]\n> Sent: 20 June 2013 17:48\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] Efficiently pin running VMs to physical \n> CPUs automatically\n> \n> On 06/20/2013 10:36 AM, Giorgio Franceschi wrote:\n>> Hello, I created a blueprint for the implementation of:\n>> \n>> A tool for pinning automatically each running virtual CPU to a \n>> physical one in the most efficient way, balancing load across \n>> sockets/cores and maximizing cache sharing/minimizing cache misses. \n>> Ideally able to be run on-demand, as a periodic job, or be triggered \n>> by events on the host (vm spawn/destroy).\n>> \n>> Find it at \n>> https://blueprints.launchpad.net/nova/+spec/auto-cpu-pinning\n>> \n>> Any inputappreciated!\n> \n> I\'m actually surprised to see a new tool for this kind of thing.\n> \n> Have you seen numad?\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<FB548EBF-7105-4E02-8108-997269F99D4B@cloudbasesolutions.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540042646@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 17:16:29',0,'2013-06-25 17:16:29',NULL,'[openstack-dev] Should RPC consume_in_thread() be more fault\n tolerant?','In this case, the exception is just hard to debug, and not something we expected in our design. The thorough solution would be to debug further to see the root cause, and deal with it as I suggested in the code review. \n\nHowever, If it is time consuming to debug, we can put the patch in there with logging to record the circumstances the \'unexpected\' exception occurs, so that we can put in new patches to deal it when it becomes expected. After all, this is an iterative process. When the software evolves, a lot of unexpected has become expected. \n\n-----Original Message-----\nFrom: Raymond Pekowski (Code Review) [mailto:review at openstack.org] \nSent: Tuesday, June 25, 2013 9:52 AM\nCc: Dirk Mueller; Andrea Rosa; Ben Nemec; Chris Behrens; Eric Windisch; Russell Bryant; Qing He\nSubject: Change in openstack/oslo-incubator[master]: Make AMQP based RPC consumer threads more robust\n\nRaymond Pekowski has posted comments on this change.\n\nChange subject: Make AMQP based RPC consumer threads more robust ......................................................................\n\n\nPatch Set 12:\n\nBy definition, unexpected exceptions are unexpected, so there is nothing yet to do root cause analysis on.  We could argue as to what the appropriate action to take is, but that has already been discussed on the mailing list started by this thread: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010040.html\nPlease comment on that thread since you don\'t agree with the consensus that was reached.\n\n--\nTo view, visit https://review.openstack.org/32235\nTo unsubscribe, visit https://review.openstack.org/settings\n\nGerrit-MessageType: comment\nGerrit-Change-Id: I0d6ec8a5e3a310314da201656ee862bb40b41616\nGerrit-PatchSet: 12\nGerrit-Project: openstack/oslo-incubator\nGerrit-Branch: master\nGerrit-Owner: Raymond Pekowski <raymond_pekowski at dell.com>\nGerrit-Reviewer: Andrea Rosa <andrea.rosa at hp.com>\nGerrit-Reviewer: Ben Nemec <openstack at nemebean.com>\nGerrit-Reviewer: Chris Behrens <cbehrens at codestud.com>\nGerrit-Reviewer: Dirk Mueller <dirk at dmllr.de>\nGerrit-Reviewer: Eric Windisch <eric at cloudscaling.com>\nGerrit-Reviewer: Jenkins\nGerrit-Reviewer: Qing He <qing.he at radisys.com>\nGerrit-Reviewer: Raymond Pekowski <raymond_pekowski at dell.com>\nGerrit-Reviewer: Russell Bryant <rbryant at redhat.com>\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD5400426A8@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 18:06:35',0,'2013-06-25 18:06:35',NULL,'[openstack-dev] Should RPC consume_in_thread() be more fault\n tolerant?','Basically, when \'unexpected\' happens, someone (e.g., operator) needs to know about it and look into it to see if it is something benign or fatal. If it is masked, the system may degrade overtime unnoticed into unusable.\n\n-----Original Message-----\nFrom: Qing He \nSent: Tuesday, June 25, 2013 10:16 AM\nTo: \'raymond_pekowski at dell.com\'; openstack-dev at lists.openstack.org\nCc: Dirk Mueller; Andrea Rosa; Ben Nemec; Chris Behrens; Eric Windisch; Russell Bryant\nSubject: re: [openstack-dev] Should RPC consume_in_thread() be more fault tolerant?\n\nIn this case, the exception is just hard to debug, and not something we expected in our design. The thorough solution would be to debug further to see the root cause, and deal with it as I suggested in the code review. \n\nHowever, If it is time consuming to debug, we can put the patch in there with logging to record the circumstances the \'unexpected\' exception occurs, so that we can put in new patches to deal it when it becomes expected. After all, this is an iterative process. When the software evolves, a lot of unexpected has become expected. \n\n-----Original Message-----\nFrom: Raymond Pekowski (Code Review) [mailto:review at openstack.org] \nSent: Tuesday, June 25, 2013 9:52 AM\nCc: Dirk Mueller; Andrea Rosa; Ben Nemec; Chris Behrens; Eric Windisch; Russell Bryant; Qing He\nSubject: Change in openstack/oslo-incubator[master]: Make AMQP based RPC consumer threads more robust\n\nRaymond Pekowski has posted comments on this change.\n\nChange subject: Make AMQP based RPC consumer threads more robust ......................................................................\n\n\nPatch Set 12:\n\nBy definition, unexpected exceptions are unexpected, so there is nothing yet to do root cause analysis on.  We could argue as to what the appropriate action to take is, but that has already been discussed on the mailing list started by this thread: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010040.html\nPlease comment on that thread since you don\'t agree with the consensus that was reached.\n\n--\nTo view, visit https://review.openstack.org/32235\nTo unsubscribe, visit https://review.openstack.org/settings\n\nGerrit-MessageType: comment\nGerrit-Change-Id: I0d6ec8a5e3a310314da201656ee862bb40b41616\nGerrit-PatchSet: 12\nGerrit-Project: openstack/oslo-incubator\nGerrit-Branch: master\nGerrit-Owner: Raymond Pekowski <raymond_pekowski at dell.com>\nGerrit-Reviewer: Andrea Rosa <andrea.rosa at hp.com>\nGerrit-Reviewer: Ben Nemec <openstack at nemebean.com>\nGerrit-Reviewer: Chris Behrens <cbehrens at codestud.com>\nGerrit-Reviewer: Dirk Mueller <dirk at dmllr.de>\nGerrit-Reviewer: Eric Windisch <eric at cloudscaling.com>\nGerrit-Reviewer: Jenkins\nGerrit-Reviewer: Qing He <qing.he at radisys.com>\nGerrit-Reviewer: Raymond Pekowski <raymond_pekowski at dell.com>\nGerrit-Reviewer: Russell Bryant <rbryant at redhat.com>\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD5400427B5@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 20:07:54',0,'2013-06-25 20:07:54',NULL,'[openstack-dev] Should RPC consume_in_thread() be more fault\n tolerant?','Agree! Let someone know and keep going unless someone wants to interrupt it or do something. (Does there exist a mechanism already to do this?)\n\n-----Original Message-----\nFrom: Russell Bryant [mailto:rbryant at redhat.com] \nSent: Tuesday, June 25, 2013 12:21 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Should RPC consume_in_thread() be more fault tolerant?\n\nOn 06/25/2013 03:15 PM, Ray Pekowski wrote:\n> \n> On Jun 25, 2013 1:09 PM, \"Qing He\" <Qing.He at radisys.com \n> <mailto:Qing.He at radisys.com>> wrote:\n>>\n>> Basically, when \'unexpected\' happens, someone (e.g., operator) needs\n> to know about it and look into it to see if it is something benign or \n> fatal. If it is masked, the system may degrade overtime unnoticed into \n> unusable.\n> \n> The approach implemented in the patch is to log the exception and \n> retry at a rate of one per second.  An alternative would be a log and \n> a\n> sys.exit() to kill the entire process.  Be aware that the code \n> affected by this patch is rpc created dispatcher like threads.  Let\'s \n> have a vote on which option is preferrable.\n\nI like it how it\'s implemented, *not* killing the process ...\n\n--\nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<51C9ED8B.1030204@redhat.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD5400427C1@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 20:08:50',0,'2013-06-25 20:08:50',NULL,'[openstack-dev] Should RPC consume_in_thread() be more\n	fault	tolerant?','Does the log alert operator? Something like SNMP trap?\n\nFrom: Ray Pekowski [mailto:pekowski at gmail.com]\nSent: Tuesday, June 25, 2013 12:16 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Should RPC consume_in_thread() be more fault tolerant?\n\n\nOn Jun 25, 2013 1:09 PM, \"Qing He\" <Qing.He at radisys.com<mailto:Qing.He at radisys.com>> wrote:\n>\n> Basically, when \'unexpected\' happens, someone (e.g., operator) needs to know about it and look into it to see if it is something benign or fatal. If it is masked, the system may degrade overtime unnoticed into unusable.\n\nThe approach implemented in the patch is to log the exception and retry at a rate of one per second.  An alternative would be a log and a sys.exit() to kill the entire process.  Be aware that the code affected by this patch is rpc created dispatcher like threads.  Let\'s have a vote on which option is preferrable.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130625/81860084/attachment.html>\n\n','<CAJcv3CQ5nTnTc=R6QWspMSsthefap7-UO_6RTNLfa+ig89tZNw@mail.gmail.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540042852@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 20:59:45',0,'2013-06-25 20:59:45',NULL,'[openstack-dev] Should RPC consume_in_thread() be more\n	fault	tolerant?','Clarify, operator does not have to go through a long log to find the issue. Instead, he/she needs to be notified that something severe/unexpected just happened and he/she needs to check it out.\n\nFrom: Qing He\nSent: Tuesday, June 25, 2013 1:09 PM\nTo: \'OpenStack Development Mailing List\'\nSubject: RE: [openstack-dev] Should RPC consume_in_thread() be more fault tolerant?\n\nDoes the log alert operator? Something like SNMP trap?\n\nFrom: Ray Pekowski [mailto:pekowski at gmail.com]<mailto:[mailto:pekowski at gmail.com]>\nSent: Tuesday, June 25, 2013 12:16 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Should RPC consume_in_thread() be more fault tolerant?\n\n\nOn Jun 25, 2013 1:09 PM, \"Qing He\" <Qing.He at radisys.com<mailto:Qing.He at radisys.com>> wrote:\n>\n> Basically, when \'unexpected\' happens, someone (e.g., operator) needs to know about it and look into it to see if it is something benign or fatal. If it is masked, the system may degrade overtime unnoticed into unusable.\n\nThe approach implemented in the patch is to log the exception and retry at a rate of one per second.  An alternative would be a log and a sys.exit() to kill the entire process.  Be aware that the code affected by this patch is rpc created dispatcher like threads.  Let\'s have a vote on which option is preferrable.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130625/ae52e014/attachment.html>\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540043C57@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 16:00:50',0,'2013-06-26 16:00:50',NULL,'[openstack-dev] [Nova] Nominating John Garbutt for nova-core','+1\n\n-----Original Message-----\nFrom: Dan Smith [mailto:dms at danplanet.com] \nSent: Wednesday, June 26, 2013 8:25 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core\n\n> Please respond with +1s or any concerns.\n\n+1 from me.\n\n--Dan\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20130626082529.25944613@caffeine.danplanet.com>',NULL),('<08751C58B8AC2D45AC34FC099D5DD540045783@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 23:29:30',0,'2013-07-01 23:29:30',NULL,'[openstack-dev] Email is not registered problem','The emails from this list stopped coming to my email address, is this related?\n\n-----Original Message-----\nFrom: Jeremy Stanley [mailto:fungi at yuggoth.org] \nSent: Wednesday, June 26, 2013 7:38 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Email is not registered problem\n\nOn 2013-06-26 17:31:26 +0800 (+0800), Wenhao Xu wrote:\n> I am reworking on on one of my old patch today. After that, when I \n> tried to do \"git review\", I got the following error message:\n[...]\n> remote: ERROR:  committer email address wenhao at zelin.io\n> remote: ERROR:  does not match your user account.\n> remote: ERROR:\n> remote: ERROR:  The following addresses are currently registered:\n> remote: ERROR:    xuwenhao2008 at gmail.com\n[...]\n> I have updated my primary email address to wenhao at zelin.io in \n> launchpad, Gerrit and openstack foundation profile as well. I am \n> wondering is there anything I missed?\n\nIt\'s possible you\'ve got two accounts in Gerrit, one you\'re updating through the WebUI (tied to your current Launchpad OpenID) and another which is associated with your SSH username but has the same SSH key along with your old E-mail address. We\'ve run into a few like that which needed cleaning up, usually following LP account/OpenID changes. I\'ll look into it and follow up with you privately to resolve the issue.\n--\nJeremy Stanley\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20130626143822.GV1472@yuggoth.org>',NULL),('<08751C58B8AC2D45AC34FC099D5DD5400476C1@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-08 22:21:06',0,'2013-07-08 22:21:06',NULL,'[openstack-community] closing a question','I\'m wondering what is the process or criteria for someone other than the one who asked the question to close a question?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130708/3e37fc03/attachment.html>\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540047733@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-08 23:51:28',0,'2013-07-08 23:51:28',NULL,'[openstack-community] [User-committee] [OpenStack\n Marketing][openstack-dev] openstack only deployment','\nHi All,\nI\'m wondering if anyone has deployed openstack without any proprietary software/component?\nThanks,\n\nQing \n\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540047733@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-08 23:51:28',0,'2013-07-08 23:51:28',NULL,'[openstack-dev] [openstack-community] [User-committee] [OpenStack\n Marketing] openstack only deployment','\nHi All,\nI\'m wondering if anyone has deployed openstack without any proprietary software/component?\nThanks,\n\nQing \n\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540047824@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-09 05:46:38',0,'2013-07-09 05:46:38',NULL,'[openstack-community] [User-committee] [OpenStack\n Marketing][openstack-dev] difference between Nebula Cosmos software and\n OpenStack','I\'m wondering what is lacking in OpenStack so that people would still need Nebula Cosmos software to build their private cloud?\n\n \n\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540047824@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 05:46:38',0,'2013-07-09 05:46:38',NULL,'[openstack-dev] [openstack-community] [User-committee]\n [OpenStack Marketing] difference between Nebula Cosmos software and\n OpenStack','I\'m wondering what is lacking in OpenStack so that people would still need Nebula Cosmos software to build their private cloud?\n\n \n\n\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD5400558B2@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-13 00:12:34',0,'2013-07-13 00:12:34',NULL,'[openstack-dev]  Event Service','All,\nDoes open stack have pub/sub event service? I would like to be notified of the event of VM creation/deletion/Migration etc. What is the best way to do this?\n\nThanks,\n\nQing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130713/8d9415a6/attachment.html>\n\n',NULL,NULL),('<08751C58B8AC2D45AC34FC099D5DD540055957@BLUPRD0810MB390.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-13 02:43:30',0,'2013-07-13 02:43:30',NULL,'[openstack-dev] Event Service','Thanks Michael!\nI found it:\nhttps://wiki.openstack.org/wiki/NotificationEventExamples\n\n-----Original Message-----\nFrom: Michael Still [mailto:mikal at stillhq.com] \nSent: Friday, July 12, 2013 6:38 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Event Service\n\nOpenStack has a system called notifications which does what you\'re looking for. I\'ve never used it, but I am sure its documented.\n\nCheers,\nMichael\n\nOn Sat, Jul 13, 2013 at 10:12 AM, Qing He <Qing.He at radisys.com> wrote:\n> All,\n>\n> Does open stack have pub/sub event service? I would like to be \n> notified of the event of VM creation/deletion/Migration etc. What is \n> the best way to do this?\n>\n>\n>\n> Thanks,\n>\n>\n> Qing\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n--\nRackspace Australia\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAEd1pt5Htfk=AHqXyzC0FWuJkiSRkd01HiAB3CT=7djvoeTq4Q@mail.gmail.com>',NULL),('<08764892-9B5F-4D18-843F-4B845CC36911@hortonworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 09:53:08',-18000,'2013-11-18 14:53:08',NULL,'[openstack-dev] [Savanna] Definition of template','I\'d like to suggest that we take a step back and identify the actual requirement(s) we\'re trying address, independent of the actual implementation (current or otherwise).  Once that requirement is clearly stated, we can think of viable approaches and then, lastly, how the current architecture can be re-configured or modified to accommodate those approaches.  Right now this conversation has the feel of a nebulous requirement being addressed with a kludged approach.\n\n-- Jon\n\nOn Nov 13, 2013, at 5:54 PM, Andrey Lazarev <alazarev at mirantis.com> wrote:\n\n> John,\n> \n> I think we should either select one of the listed border approaches (no validation or full validation) or define some strict rules on what is allowed and what is not. Otherwise phrases like \"at a minimum a cluster template would contain node groups\" is a speculation and we will not be able to determine right way to solve them. I can easily suggest any number of concerns like listed above (\"cluster template with tt without jt has no sense\" , \"cluster template should contain at least namenode\", etc.). \n> \n> I like idea of no validation for template. If I want to save anti-affinity params in cluster template, but don\'t know which nodegroups will be used, why can\'t I do that?      \n> \n> Thanks,\n> Andrew.\n> \n> \n> On Wed, Nov 13, 2013 at 12:23 PM, John Speidel <jspeidel at hortonworks.com> wrote:\n> I strongly agree that we should try to keep templates as flexible as possible by allowing some values to be omitted and provided at a later time.  But, in this case, we are talking about cluster templates without any node groups being specified.  I think that at a minimum a cluster template would contain node groups but could omit the node group counts which could be provided at launch time.  This makes a lot of sense.  But, in my opinion, without at least specifying the set of node groups in a cluster template, configuration really wouldn\'t make sense and therefore the template would not be of much/any value.\n> \n> \n> On Wed, Nov 13, 2013 at 10:08 AM, Alexander Ignatov <aignatov at mirantis.com> wrote:\n> Hi, Andrew\n> \n> Agreed with your opinion. Initially Savanna?s templates approach is the option 1 you are talking about. \n> This was designed at the start of Savanna 0.2 release cycle. It was also documented here: https://wiki.openstack.org/wiki/Savanna/Templates . \n> Maybe some points are outdated but the idea is the same as the option 1: user can create cluster template and don?t need to specify all fields, for example ?node_groups? field. And these fields, both required and optional, can be overwritten in the cluster object even if it contains ?cluster_template_id?.\n> \n> I see you raised this question because of patch https://review.openstack.org/#/c/56060/. I think it?s just a bug in the validation level not in api.\n> \n> I also agree that we should change UI part accordingly, at least add an ability for users to override fields set in cluster and node group templates during the cluster creation.\n> \n> Regards,\n> Alexander Ignatov\n> \n> \n> \n> On 12 Nov 2013, at 23:20, Andrey Lazarev <alazarev at mirantis.com> wrote:\n> \n>> Hi all,\n>> \n>> I want to raise the question \"What template is\". Answer to this question could influence UI, validation and user experience significantly. I see two possible answers:\n>> 1. Template is a simplification for object creation. It allows to keep common params in one place and not specify them each time. \n>> 2. Template is a full description of object. User should be able to create object from template without specifying any params.\n>> \n>> As I see the current approach is the option 1, but UI is done mostly for option 2. This leads to situations when user creates incomplete template (backend allows it because of option 1), but can\'t use it later (UI doesn\'t allow to work with incomplete templates).\n>> \n>> Let\'s define common vision on how will we treat templates and document this somehow.\n>> \n>> My opinion is that we should proceed with the option 1 and change UI accordingly.    \n>> \n>> Thanks,\n>> Andrew\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> CONFIDENTIALITY NOTICE\n> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-- \nCONFIDENTIALITY NOTICE\nNOTICE: This message is intended for the use of the individual or entity to \nwhich it is addressed and may contain information that is confidential, \nprivileged and exempt from disclosure under applicable law. If the reader \nof this message is not the intended recipient, you are hereby notified that \nany printing, copying, dissemination, distribution, disclosure or \nforwarding of this communication is strictly prohibited. If you have \nreceived this communication in error, please contact the sender immediately \nand delete it from your system. Thank You.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/d3e65452/attachment.html>\n\n','<CANzyysgsqZ5VJX=i4sLjBk5t6i-RTOkXZMQ99WG+s0=hwQcKXg@mail.gmail.com>',NULL),('<08795F26-0F2C-45E3-86D3-C6FCBC4451A3@unimelb.edu.au>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-24 14:43:10',0,'2013-07-24 14:43:10',NULL,'[Openstack-operators] Shared storage HA question','Hi Denis,\n\nBefore designing & implementing and shared storage for OpenStack you should think carefully about the workload your shared storage needs to be built for. How many VMs is it servicing? What sort of workloads are they? DBs? Web servers? File servers? etc. Then design according to that spec.\n\nSteven.\n\n\nOn 24/07/2013, at 10:32 PM, Razique Mahroua <razique.mahroua at gmail.com<mailto:razique.mahroua at gmail.com>>\n wrote:\n\nI had much performance issues myself with Windows instances, and I/O demanding instances. Make sure it fits your env. first before deploying it in production\n\nRegards,\nRazique\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com<mailto:razique.mahroua at gmail.com>\nTel : +33 9 72 37 94 15\n\n<NUAGECO-LOGO-Fblan_petit.jpg>\n\nLe 24 juil. 2013 ? 16:25, Jacob Godin <jacobgodin at gmail.com<mailto:jacobgodin at gmail.com>> a ?crit :\n\nHi Denis,\n\nI would take a look into GlusterFS with a distributed, replicated volume. We have been using it for several months now, and it has been stable. Nova will need to have the volume mounted to its instances directory (default /var/lib/nova/instances), and Cinder has direct support for Gluster as of Grizzly I believe.\n\n\n\nOn Wed, Jul 24, 2013 at 11:11 AM, Denis Loshakov <dloshakov at gmail.com<mailto:dloshakov at gmail.com>> wrote:\nHi all,\n\nI have issue with creating shared storage for Openstack. Main idea is to create 100% redundant shared storage from two servers (kind of network RAID from two servers).\nI have two identical servers with many disks inside. What solution can any one provide for such schema? I need shared storage for running VMs (so live migration can work) and also for cinder-volumes.\n\nOne solution is to install Linux on both servers and use DRBD + OCFS2, any comments on this?\nAlso I heard about Quadstor software and it can create network RAID and present it via iSCSI.\n\nThanks.\n\nP.S. Glance uses swift and is setuped on another servers\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130724/1bf056ad/attachment.html>\n\n','<45284E7C-C102-47EA-AF5A-D133592B6540@gmail.com>',NULL),('<0879B4C5-A82F-4D87-8430-A5086BE135B8@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 09:45:28',-18000,'2013-10-31 14:45:28',NULL,'[OpenStack Foundation] OpenStack core and interoperability','+1\n\n> On Oct 31, 2013, at 9:41 AM, Monty Taylor <mordred at inaugust.com> wrote:\n> \n> \n> \n>> On 10/31/2013 07:36 AM, Dave Neary wrote:\n>> Hi,\n>> \n>>> On 10/31/2013 10:06 AM, Thierry Carrez wrote:\n>>> Mark McLoughlin posted a very interesting view at:\n>>> http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/\n>> \n>> Awesome summary & more or less exactly what I think.\n>> \n>>> I agree with him. \"Core\" is not a goal, it\'s just a means to an end. A\n>>> \"market of interoperable OpenStack clouds\" is the goal. By focusing on\n>>> the means rather than the end goal, we face the risk of missing the target.\n>> \n>> The goal is: allow someone using one OpenStack cloud to move *his* stuff\n>> to another OpenStack cloud easily. Also allow someone to burst from a\n>> private OpenStack cloud to a public OpenStack cloud easily on demand.\n>> That could be achieved by interoperability, but the definition of\n>> interoperability could also be too narrow to allow that.\n>> \n>>> If you focus on the end goal, you realize there is a choice between two\n>>> approaches: the common denominator approach (aim for a small set to make\n>>> sure most current \"OpenStack clouds\" will stay \"OpenStack clouds\"), and\n>>> the prescriptive approach (define what would make a \"complete\" OpenStack\n>>> cloud, and use the power of the trademark to encourage everyone to\n>>> converge towards that). There is no way around that choice and we should\n>>> have the courage to tackle it early rather than late.\n>> \n>> Third option: standardise on interfaces and behaviour, and ignore\n>> implementation.\n> \n> There is a VERY specific and strong reason why this is not the approach,\n> and that\'s because it disincentivies people from working on OpenStack\n> itself. We already have the problem with Neutron where not enough\n> companies are working on the core of neutron because they\'re all only\n> working on their vendor plugins. If OpenStack all of a sudden became a\n> set of interfaces, then the goal of an Open cloud would, I\'m pretty\n> certain, become lost.\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n','<52726C06.9010408@inaugust.com>',NULL),('<08876636-6053-433F-9A99-B8697C4EA3A8@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-06 11:13:42',-18000,'2014-02-06 16:13:42',NULL,'[Openstack] Odd Keystone Behaviour','I agree that?s why I was saying to try a different user. If you add a user it will not be part of the admin anyhow, by default.\n\nRemo \n\nOn Feb 6, 2014, at 11:09, Craig Jellick <cjellick at godaddy.com> wrote:\n\n> If you\'re using the default policy.json file, this seems to be the\n> expected behavior.\n> The \"list_user_projects\" method has an access rule of \"admin_or_owner\".\n> All the other calls you mentioned have a rule of \"admin_required\".\n> \n> So, I\'d say that most likely the user you are using does not have the role\n> \"admin\".\n> \n> \n> /Craig J\n> \n> \n> \n> \n> On 2/6/14 8:19 AM, \"Remo Mattei\" <remo at italy1.com> wrote:\n> \n>> Seems a permissions issue did you try a different user?\n>> \n>> Remo\n>> \n>> On Feb 6, 2014, at 10:09, Daniel Ellison <daniel at syrinx.net> wrote:\n>> \n>>> Hey all,\n>>> \n>>> I\'ve run into an issue with a Havana Keystone install on CentOS 6.3.\n>>> When I issue a command such as:\n>>> \n>>>   keystone user-list\n>>> \n>>> I get in response:\n>>> \n>>>   Unable to authorize user\n>>> \n>>> This happens with service-list, endpoint-list, role-list, etc. Oddly,\n>>> it does NOT happen with tenant-list; I get a proper list of tenants in\n>>> response.\n>>> \n>>> Running the commands with \"--debug\", the response body to a \"/tokens\"\n>>> request for all was identical aside from the token itself and\n>>> timestamps. The difference came after that, where most of the *-list\n>>> commands returned \"Unable to authorize user\" except for tenant-list,\n>>> which returned the list of tenants.\n>>> \n>>> There is one reference to this issue at\n>>> http://docs.openstack.org/havana/install-guide/install/yum/content/keysto\n>>> ne-verify.html#comment-1143923155 so I know I\'m not the only one having\n>>> this issue. The key is that ONE of the commands works while all the rest\n>>> don\'t.\n>>> \n>>> Any ideas?\n>>> _______________________________________________\n>>> Mailing list: \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe : \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> \n>>> \n>>> \n>> \n>> \n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,52f3b3e674461390257870!\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140206/72e94282/attachment.html>\n\n','<CF19005E.9ECE%cjellick@godaddy.com>',NULL),('<08907F81-1621-49FF-A834-A0EB7CA5FAE7@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-01-17 14:46:39',3600,'2013-01-17 13:46:39',NULL,'[Openstack-operators] Can\'t add flavour','Oh so sorry,  my bad, the table is called \"instance_types\"\n sorry man\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 17 janv. 2013 ? 14:40, Nux! <nux at li.nux.ro> a ?crit :\n\n> On 17.01.2013 13:32, Razique Mahroua wrote:\n>> Hi Nux!\n>> Ca you run that query?\n>> \n>>> mysql -u $mysql-user -p -e \"use nova; select * from flavors;\"\n>> \n>> Cheers\n> \n> ERROR 1146 (42S02) at line 1: Table \'nova.flavors\' doesn\'t exist\n> \n> Right, I take it should exist. I wonder how it managed to disappear. I\'ll check my backups, thanks.\n> \n> \n> -- \n> Sent from the Delta quadrant using Borg technology!\n> \n> Nux!\n> www.nux.ro\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130117/b8a0914a/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO_logo_complet.gif\nType: image/gif\nSize: 9524 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130117/b8a0914a/attachment.gif>\n\n','<7408b4270e763c7d9f9212f5b32c132d@li.nux.ro>',NULL),('<089349C0-F956-450C-910B-DB71B9FE2FDE@isi.edu>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-04-15 13:31:34',-14400,'2013-04-15 17:31:34',NULL,'[openstack-hpc] [HPC] Anyone interested in an HPC-themed\n	unconference?','Hi,\n\nWe missed the deadline for an HPC related design summit session, but there\'s still time to sign up for an unconference if anyone\'s interested.  Anyone interested?  I\'d propose one of the Wednesday slots.\n\nbest,\nJP\n\n',NULL,NULL),('<0894AE5E-66B3-48F6-8C77-02090C5C4561@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 16:38:22',3600,'2014-11-19 15:38:22',NULL,'[openstack-dev] [Fuel] Power management in Cobbler','\n> On 19 Nov 2014, at 16:10, Vladimir Kozhukalov <vkozhukalov at mirantis.com> wrote:\n> \n> I am absolutely -1 for using Cobbler for that. Lastly, Ironic guys became much more open for adopting new features (at least if they are implemented in terms of Ironic drivers). Currently, it looks like we are  probably able to deliver zero step Fuel Ironic driver by 6.1. Ironic already has working IPMI stuff and they don\'t oppose ssh based power management any more. Personally, I\'d prefer to focus our efforts towards  Ironic stuff and keeping in mind that Cobbler will be removed in the nearest future. \n\nI know that due to time constraints we would be better to go with Cobbler, but I also think we should be closer to the community and switch to Ironic as soon as possible. \n\nRegards,\n-- \nTomasz \'Zen\' Napierala\nSr. OpenStack Engineer\ntnapierala at mirantis.com\n\n\n\n\n\n\n\n\n','<CAFLqvG7vD6CUwvJ4s+WKFbC+TH=8tZfAj2w_wwj8q4exQJzeSg@mail.gmail.com>',NULL),('<0899CD9D-EF5C-4DDA-B7FA-EF45272EAA0F@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 19:31:31',0,'2014-04-07 19:31:31',NULL,'[openstack-dev] [Heat] [TripleO] Better handling of lists in\n Heat - a proposal to add a map function','\nOn Apr 4, 2014, at 1:56 PM, Zane Bitter <zbitter at redhat.com>\n wrote:\n\n> On 19/02/14 02:48, Clint Byrum wrote:\n>> Since picking up Heat and trying to think about how to express clusters\n>> of things, I\'ve been troubled by how poorly the CFN language supports\n>> using lists. There has always been the Fn::Select function for\n>> dereferencing arrays and maps, and recently we added a nice enhancement\n>> to HOT to allow referencing these directly in get_attr and get_param.\n>> \n>> However, this does not help us when we want to do something with all of\n>> the members of a list.\n>> \n>> In many applications I suspect the template authors will want to do what\n>> we want to do now in TripleO. We have a list of identical servers and\n>> we\'d like to fetch the same attribute from them all, join it with other\n>> attributes, and return that as a string.\n>> \n>> The specific case is that we need to have all of the hosts in a cluster\n>> of machines addressable in /etc/hosts (please, Designate, save us,\n>> eventually. ;). The way to do this if we had just explicit resources\n>> named NovaCompute0, NovaCompute1, would be:\n>> \n>>   str_join:\n>>     - \"\\n\"\n>>     - - str_join:\n>>         - \' \'\n>>         - get_attr:\n>>           - NovaCompute0\n>>           - networks.ctlplane.0\n>>         - get_attr:\n>>           - NovaCompute0\n>>           - name\n>>       - str_join:\n>>         - \' \'\n>>         - get_attr:\n>>           - NovaCompute1\n>>           - networks.ctplane.0\n>>         - get_attr:\n>>           - NovaCompute1\n>>           - name\n>> \n>> Now, what I\'d really like to do is this:\n>> \n>> map:\n>>   - str_join:\n>>     - \"\\n\"\n>>     - - str_join:\n>>       - \' \'\n>>       - get_attr:\n>>         - \"$1\"\n>>         - networks.ctlplane.0\n>>       - get_attr:\n>>         - \"$1\"\n>>         - name\n>>   - - NovaCompute0\n>>     - NovaCompute1\n>> \n>> This would be helpful for the instances of resource groups too, as we\n>> can make sure they return a list. The above then becomes:\n>> \n>> \n>> map:\n>>   - str_join:\n>>     - \"\\n\"\n>>     - - str_join:\n>>       - \' \'\n>>       - get_attr:\n>>         - \"$1\"\n>>         - networks.ctlplane.0\n>>       - get_attr:\n>>         - \"$1\"\n>>         - name\n>>   - get_attr:\n>>       - NovaComputeGroup\n>>       - member_resources\n>> \n>> Thoughts on this idea? I will throw together an implementation soon but\n>> wanted to get this idea out there into the hive mind ASAP.\n> \n> Apparently I read this at the time, but completely forgot about it. Sorry about that! Since it has come up again in the context of the \"TripleO Heat templates and merge.py\" thread, allow me to contribute my 2c.\n> \n> Without expressing an opinion on this proposal specifically, consensus within the Heat core team has been heavily -1 on any sort of for-each functionality. I\'m happy to have the debate again (and TBH I don\'t really know what the right answer is), but I wouldn\'t consider the lack of comment on this as a reliable indicator of lazy consensus in favour; equivalent proposals have been considered and rejected on multiple occasions.\n> \n> Since it looks like TripleO will soon be able to move over to using AutoscalingGroups (or ResourceGroups, or something) for groups of similar servers, maybe we could consider baking this functionality into Autoscaling groups instead of as an intrinsic function.\n> \n> For example, when you do get_attr on an autoscaling resource it could fetch the corresponding attribute from each member of the group and return them as a list. (It might be wise to prepend \"Output.\" or something similar - maybe \"Members.\" - to the attribute names, as AWS::CloudFormation::Stack does, so that attributes of the autoscaling group itself can remain in a separate namespace.)\n\nFWIW, ResourceGroup supports this now as well as getting the attribute value from a given indexed member of the group.\n\n> \n> Since members of your NovaComputeGroup will be nested stacks anyway (using ResourceGroup or some equivalent feature - preferably autoscaling with rolling updates), in the case above you\'d define in the scaled template:\n> \n>  outputs:\n>    hosts_entry:\n>      description: An /etc/hosts entry for the NovaComputeServer\n>      value:\n>        - str_join:\n>          - \' \'\n>          - - get_attr:\n>              - NovaComputeServer\n>              - networks\n>              - ctlplane\n>              - 0\n>            - get_attr:\n>              - NovaComputeServer\n>              - name\n> \n> And then in the main template (containing the autoscaling group):\n> \n>    str_join:\n>      - \"\\n\"\n>      - get_attr:\n>        - NovaComputeGroup\n>        - Members.hosts_entry\n> \n> would give the same output as your example would.\n> \n> IMHO we should do something like this regardless of whether it solves your use case, because it\'s fairly easy, requires no changes to the template format, and users have been asking for ways to access e.g. a list of IP addresses from a scaling group. That said, it seems very likely that making the other changes required for TripleO to get rid of merge.py (i.e. switching to scaling groups of templates instead of by multiplying resources in templates) will make this a viable solution for TripleO\'s use case as well.\n> \n> cheers,\n> Zane.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<533F005D.6020702@redhat.com>',NULL),('<089e0111b99a7c5ee204f99c7130@google.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-05-17 18:10:21',0,'2014-05-17 18:10:21',NULL,'[Openstack-docs] Google Analytics: Pages','For your perusal, the Pages report from Google Analytics is attached,  \nshowing the Pageviews, Bounce Rate, %Exit and more for pages on the  \nhttp://docs.openstack.org site.\n\nAnne\n\n\n----------------------------------------\nThis is a report email from Google Analytics. You received this email  \nbecause annegentle at gmail.com requested this report be sent to you. If you  \nwould like to opt out of emails from this user, go to  \nhttps://www.google.com/analytics/web/optout?token=52rfpUYBAAA.PXlfi93zuPDcITpdeJeHPjn5Jt8i6hAKPw6q4lsZdoKd9lHq5BdZkEkA1djaWc-TU_un2AulG82SCEmJ7v5Dol5Id1PGOwOxv8TFlzhhjPQ.L3lSrep-0fqxiQ_TAuFaFg&email=openstack-docs%40lists.openstack.org&hl=en_US\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Analytics Docs Pages 20140417-20140516.pdf\nType: application/pdf\nSize: 108704 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140517/2f533ba3/attachment-0001.pdf>\n\n',NULL,NULL),('<089e013a2a3407425604e132afdc@google.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 01:55:07',0,'2013-07-11 01:55:07',NULL,'[openstack-dev] Invitation: OpenStack Swift deep dive code overview\n of DiskFile objec... @ Wed Jul 17,\n 2013 3pm - 4pm (peter.a.portante@gmail.com)','You have been invited to the following event.\n\nTitle: OpenStack Swift deep dive code overview of DiskFile object  \nrefactoring\nWhen: Wed Jul 17, 2013 3pm ? 4pm Eastern Time\nWhere: G+ Hangouts\nCalendar: peter.a.portante at gmail.com\nWho:\n     * Peter Portante - organizer\n     * openstack-dev at lists.openstack.org\n\nEvent details:  \nhttps://www.google.com/calendar/event?action=VIEW&eid=bWxldjgydDBuOWZnMmNmcmU0dTdoYTd0ZDQgb3BlbnN0YWNrLWRldkBsaXN0cy5vcGVuc3RhY2sub3Jn&tok=MjYjcGV0ZXIuYS5wb3J0YW50ZUBnbWFpbC5jb21iMTY4Mjk5NTczYTBiMDRiM2Q0ZmJhMDE0MzNhMjA0N2U3ZTdhODA3&ctz=America/New_York&hl=en\n\nInvitation from Google Calendar: https://www.google.com/calendar/\n\nYou are receiving this courtesy email at the account  \nopenstack-dev at lists.openstack.org because you are an attendee of this event.\n\nTo stop receiving future notifications for this event, decline this event.  \nAlternatively you can sign up for a Google account at  \nhttps://www.google.com/calendar/ and control your notification settings for  \nyour entire calendar.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/6ad068f7/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: not available\nType: text/calendar\nSize: 1157 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/6ad068f7/attachment.ics>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: invite.ics\nType: application/ics\nSize: 1187 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/6ad068f7/attachment.bin>\n\n',NULL,NULL),('<08A0B182-DCCC-4B47-8021-C753F2872885@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-02 13:43:32',0,'2015-01-02 13:43:32',NULL,'[openstack-dev] [neutron] Need help getting DevStack setup\n working	for VPN testing','To summarize what I?m trying to do with option (A)?\n\nI want to test VPN in DevStack by setting up two private networks, two routers, and a shared public network. The VMs created in the private networks should be able to access the public network, but not the other private network (e.g. VM on private-A subnet can ping public interface of router2 on private-B subnet)\n\n  |\nVM-a\n\n\nDo I need to create the second router and private network using a different tenant?\nDo I need to setup security group rules to allow the access desired?\nWhat local.conf settings do I need for this setup (beyond what I have below)?\n\nI?ve been trying so many different combinations (using both single and two devstack setups, trying provider net, using single/multiple tenants) and have been getting a variety of different results, from unexpected ping results, to VMs stuck in power state PAUSED, that I?m lost as to how to set this up. I think I?m hung up on the security group rules and how to setup the bridges.\n\nWhat I?d like to do, is just focus on this option (A) - using a single devstack with multiple routers, and see if that works. If not, I can focus on option (B), using two devstacks/hosts.\n\nSince I?m pretty much out of ideas on how to fix this for now, I?m going to try to see if I can get on a bare metal setup, which has worked in the past.\n\nAny ideas? I?d like to verify VPNaaS reference implementation with the new repo changes. Been spending some time over the holiday vacation playing with this, with no joy. :(\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pc_m (irc.freenode.com<http://irc.freenode.com>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n\nOn Dec 31, 2014, at 2:35 PM, Paul Michali (pcm) <pcm at cisco.com<mailto:pcm at cisco.com>> wrote:\n\nJust more data?\n\nI keep consistently seeing that on private subnet, the VM can only access router (as expected), but on privateB subnet, the VM can access the private I/F of router1 on private subnet. From the router?s namespace, I cannot ping the local VM (why not?). Oddly, I can ping router1?s private IP from router2 namespace!\n\nI tried these commands to create security group rules (are they wrong?):\n\n# There are two default groups created by DevStack\ngroup=`neutron security-group-list | grep default | cut -f 2 -d\' \' | head -1`\nneutron security-group-rule-create --protocol ICMP $group\nneutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 $group\ngroup=`neutron security-group-list | grep default | cut -f 2 -d\' \' | tail -1`\nneutron security-group-rule-create --protocol ICMP $group\nneutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 $group\n\nThe only change that happens, when I do these commands, is that the VM in privateB subnet can now ping the VM from private subnet, but not vice versa. From router1 namespace, it can then access local VMs. From router2 namespace it can access local VMs and VMs in private subnet (all access).\n\nIt seems like I have some issue with security groups, and I need to square that away, before I can test VPN out.\n\nAm I creating the security group rules correctly?\nMy goal is that the private nets can access the public net, but not each other (until VPN connection is established).\n\nLastly, in this latest try, I set OVS_PHYSICAL_BRIDGE=br-ex. In earlier runs w/o that, there were QVO interfaces, but no QVB or QBR interfaces at all. It didn?t seem to change connectivity, however.\n\nIdeas?\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pc_m (irc.freenode.com<http://irc.freenode.com/>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n\nOn Dec 31, 2014, at 10:33 AM, Paul Michali (pcm) <pcm at cisco.com<mailto:pcm at cisco.com>> wrote:\n\nI?ve been playing a bit with trying to get VPNaaS working post-repo split, and haven?t been successful. I?m trying it a few ways with DevStack, and I?m not sure whether I have a config error, setup issue, or there is something due to the split.\n\nIn the past (and it?s been a few months since I verified VPN operation), I used two bare metal machines and an external switch connecting them. With a DevStack cloud running on each. That configuration is currently setup for a vendor VPN solution, so I wanted to try different methods to test the reference VPN implementation. I?ve got two ideas to do this:\n\nA) Run DevStack and create two routers with a shared ?public? network, and two private networks, setting up a VPN connection between the private nets.\nB) Run two DevStack instances (on two VMs) and try to setup a provider network between them.\n\nI?m starting with A (though I did try B quickly, but it didn?t work), and I spun up the stack, added a second router (all under the same tenant), created another private network, and booted a Cirros VM in each private net.\n\nBefore even trying VPN, I checked pings. From the first private net VM (10.1.0.4), I could ping on the pubic net, including the public IP of the second private net?s public interface for its router. I cannot ping the VM from the host. That seems all expected to me.\n\nWhat seems wrong is the other VM (this is on the post stack net I created). Like the other VM, I can ping public net IPs. However, I can also ping the private net address of the first network?s router (10.1.0.1)! Shouldn?t that have failed (at least that was what I was expecting)? I can?t ping the VM on that side though. Another curiosity is that the VM got the second IP on the subnet (10.2.0.2), unlike the other private net, where DHCP and a compute probe got the 2nd and 3rd IPs. There is DHCP enabled on this private network.\n\nWhen I tried VPN, both connections show as DOWN, and all I see are phase 1 ident packets. I cannot ping from VM to VM. I don?t see any logging for the OpenSwan processes, so not to sure how to debug. Maybe I can try some ipsec show command?\n\nI?m not too sure what is wrong with this setup.\n\nFor a comparison, I decided to do the same thing, using stable/juno. So, I fired up a VM and cloned DevStack with stable/juno and stacked. This time, things are even worse! When I try to boot a VM, and then check the status, the VM is in PAUSED power state. I can?t seem to unpause (nor do I know why it is in this state). Verified this with both Cirros 3.3, 3.2, and Ubuntu cloud images:\n\n+--------------------------------------+----------------------------------------------------------------+\n| Property                             | Value                                                          |\n+--------------------------------------+----------------------------------------------------------------+\n| OS-DCF:diskConfig                    | MANUAL                                                         |\n| OS-EXT-AZ:availability_zone          | nova                                                           |\n| OS-EXT-SRV-ATTR:host                 | juno                                                           |\n| OS-EXT-SRV-ATTR:hypervisor_hostname  | juno                                                           |\n| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                              |\n| OS-EXT-STS:power_state               | 3                                                              |\n| OS-EXT-STS:task_state                | -                                                              |\n| OS-EXT-STS:vm_state                  | active                                                         |\n| OS-SRV-USG:launched_at               | 2014-12-31T15:15:33.000000                                     |\n| OS-SRV-USG:terminated_at             | -                                                              |\n| accessIPv4                           |                                                                |\n| accessIPv6                           |                                                                |\n| config_drive                         |                                                                |\n| created                              | 2014-12-31T15:15:24Z                                           |\n| flavor                               | m1.tiny (1)                                                    |\n| hostId                               | 5b0c48250ccc0ac3fca8a821e29e4b154ec0b101f9cc0a0b27071a3f       |\n| id                                   | ec5c8d70-ae80-4cc3-a5bb-b68019170dd6                           |\n| image                                | cirros-0.3.3-x86_64-uec (797e4dee-8c03-497f-8dac-a44b9351dfa3) |\n| key_name                             | -                                                              |\n| metadata                             | {}                                                             |\n| name                                 | peter                                                          |\n| os-extended-volumes:volumes_attached | []                                                             |\n| private network                      | 10.0.0.4                                                       |\n| progress                             | 0                                                              |\n| security_groups                      | default                                                        |\n| status                               | ACTIVE                                                         |\n| tenant_id                            | 7afb5bc1d88d462c8d57178437d3c277                               |\n| updated                              | 2014-12-31T15:15:34Z                                           |\n| user_id                              | 4ff18bdbeb4d436ea4ff1bcd29e269a9                               |\n+--------------------------------------+????????????????????????????????+\n\n+--------------------------------------+-------+--------+------------+-------------+------------------+\n| ID                                   | Name  | Status | Task State | Power State | Networks         |\n+--------------------------------------+-------+--------+------------+-------------+------------------+\n| ec5c8d70-ae80-4cc3-a5bb-b68019170dd6 | peter | ACTIVE | -          | Paused      | private=10.0.0.4 |\n+--------------------------------------+-------+--------+------------+-------------+?????????+\n\nAny ideas why the VM won?t start up correctly? I didn?t see anything on a google search.\n\nFor reference, here is my local.conf currently:\n\n[[local|localrc]]\nGIT_BASE=https://github.com<https://github.com/>\nDEST=/opt/stack\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service neutron\nenable_service q-vpn\n\n# FIXED_RANGE=10.1.0.0/24\n# FIXED_NETWORK_SIZE=256\n# NETWORK_GATEWAY=10.1.0.1\n# PRIVATE_SUBNET_NAME=privateA\n\nPUBLIC_SUBNET_NAME=public-subnet\n# FLOATING_RANGE=172.24.4.0/24\n# PUBLIC_NETWORK_GATEWAY=172.24.4.10\n# Q_FLOATING_ALLOCATION_POOL=\"start=172.24.4.11,end=172.24.4.29\"\n# Q_USE_SECGROUP=True # was False\n\n# VIRT_DRIVER=libvirt\nIMAGE_URLS=\"http://cloud-images.ubuntu.com/releases/14.04.1/release/ubuntu-14.04-server-cloudimg-amd64.tar.gz,http://download.cirros-cloud.net/0.3.3/cirros-0.3.3-x86_64-uec.tar.gz\"\n\nSCREEN_LOGDIR=/opt/stack/screen-logs\nSYSLOG=True\nLOGFILE=~/devstack/stack.sh.log\n\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=tokentoken\n\nQ_USE_DEBUG_COMMAND=True\n\nRECLONE=No\n# RECLONE=yes\nOFFLINE=False\n\nOriginally, I had floating pool lines and net names, but even with all these commented out, I have the same issue with the VM (didn?t think they were related).\n\nFor this stable/juno, Devstack is using commit 817e9b6, and Neutron is using 57e8ea8.\n\n\nI?ll try to play with option B some more as well, though I need to figure out how to setup the provider network correctly. If I can get time, I?ll reconfigure the bare metal setup I have in the lab to try stable/juno and then kilo reference VPN as well.\n\nIf anyone has done this with a VM (either one or two), using juno or kilo, please pass along your local.conf, so I can compare.\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pc_m (irc.freenode.com<http://irc.freenode.com/>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150102/292e05ea/attachment.html>\n\n','<C0AF3339-EFC6-4EE6-B837-A5A5FBF142AF@cisco.com>',NULL),('<08a1d0e603404fe39da0879176aad2e9@CO2PR05MB732.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 19:57:48',0,'2013-12-16 19:57:48',NULL,'[openstack-dev] Project-Scoped Service Catalog Entries','I\'ve run into a use case that doesn\'t currently seem to have a great solution:\n\n\nLet\'s say my users want to use a \"top-of-stack\" OpenStack project such as Heat, Trove, etc. that I don\'t currently support in my deployment. There\'s absolutely no reason these services can\'t live happily in a VM talking to Nova, etc. via the normal APIs. However, in order to have a good experience (Horizon integration, seamless CLI integration) the service needs to be in the Service Catalog. One user could have their service added to the catalog by an admin, but then everyone in the cloud would be using their VM. And if you have multiple users all doing the same thing in their own projects, you\'ve got collisions!\n\n\nSo, I submit to you all that there is value in having a way to scope Service Catalog entries to specific projects, and to allow users with appropriate permissions on their project to add/remove those project-level service catalog entries.\n\nThis could be accomplished in a number of ways:\n\n  * Adding a new field to the model to store a Project ID.\n  * Adding it in a standardized manner to \"service metadata\" as with https://blueprints.launchpad.net/keystone/+spec/service-metadata\n  * Adding it as an \"additional requirement\" as proposed by https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-services\n  * Use the existing Region field to track project scope as a hack.\n  * Something else...\n\nI see this as analogous to Nova\'s concept of per-project flavors, or Glance\'s private/public/shared image capabilities. Allowing explicit \"sharing\" would even be an interesting option for service endpoints. It all depends how far we would want to go with it.\n\nFeel free to offer feedback or other suggestions.\n\nThanks!\n\n     - Gabriel\n\n\n',NULL,NULL),('<08a4f98621f74d7abade5dabf5c2411c@BL2PR03MB227.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 11:59:38',0,'2014-03-03 11:59:38',NULL,'[Openstack] [openstack-dev] Need unique ID for every Network\n Service','Hi Nikanorov,\nPlease add the below requirement to the agenda of coming weekly discussion on Thursday.\n\nRegards,\nSrikanth.\n\nFrom: Srikanth Kumar Lingala [mailto:srikanth.lingala at freescale.com]\nSent: Monday, March 03, 2014 5:18 PM\nTo: Stephen Balukoff; Veera Reddy\nCc: openstack-dev at lists.openstack.org; openstack\nSubject: Re: [openstack-dev] [Openstack] Need unique ID for every Network Service\n\nYes..I will send a mail to Eugene Nikanorov, requesting to add this to the agenda in the coming weekly discussion.\nDetailed requirement is as follows:\nIn the current implementation, only one LBaaS configuration is possible per tenant. It is better to have multiple LBaaS configurations for each tenant.\nWe are planning to configure haproxy as VM in a Network Service Chain. In a chain, there may be possibility of multiple Network Services of the same type (For Eg: Haproxy). For that, each Network Service should have a Unique ID (UUID) for a tenant.\n\nRegards,\nSrikanth.\n\nFrom: Stephen Balukoff [mailto:sbalukoff at bluebox.net]\nSent: Saturday, March 01, 2014 1:22 AM\nTo: Veera Reddy\nCc: Lingala Srikanth Kumar-B37208; openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>; openstack\nSubject: Re: [Openstack] Need unique ID for every Network Service\n\nHi y\'all!\n\nThe ongoing debate in the LBaaS group is whether the concept of a \'Loadbalancer\' needs to exist  as an entity. If it is decided that we need it, I\'m sure it\'ll have a unique ID. (And please feel free to join the discussion on this as well, eh!)\n\nStephen\n\nOn Thu, Feb 27, 2014 at 10:27 PM, Veera Reddy <veeraready at gmail.com<mailto:veeraready at gmail.com>> wrote:\nHi,\n\nGood idea to have unique id for each entry of network functions.\nSo that we can configure multiple network function with different configuration.\n\n\nRegards,\nVeera.\n\nOn Fri, Feb 28, 2014 at 11:23 AM, Srikanth Kumar Lingala <srikanth.lingala at freescale.com<mailto:srikanth.lingala at freescale.com>> wrote:\nHi-\nIn the existing Neutron, we have FWaaS, LBaaS, VPNaaS ?etc.\nIn FWaaS, each Firewall has its own UUID.\nIt is good to have a unique ID [UUID] for LBaaS also.\n\nPlease share your comments on the above.\n\nRegards,\nSrikanth.\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n--\nStephen Balukoff\nBlue Box Group, LLC\n(800)613-4305 x807\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/ccf6fac5/attachment.html>\n\n','<fa3a98e93f744e99ac118a2bd7126f7a@BL2PR03MB227.namprd03.prod.outlook.com>',NULL),('<08a4f98621f74d7abade5dabf5c2411c@BL2PR03MB227.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 11:59:38',0,'2014-03-03 11:59:38',NULL,'[openstack-dev] [Openstack] Need unique ID for every Network\n Service','Hi Nikanorov,\nPlease add the below requirement to the agenda of coming weekly discussion on Thursday.\n\nRegards,\nSrikanth.\n\nFrom: Srikanth Kumar Lingala [mailto:srikanth.lingala at freescale.com]\nSent: Monday, March 03, 2014 5:18 PM\nTo: Stephen Balukoff; Veera Reddy\nCc: openstack-dev at lists.openstack.org; openstack\nSubject: Re: [openstack-dev] [Openstack] Need unique ID for every Network Service\n\nYes..I will send a mail to Eugene Nikanorov, requesting to add this to the agenda in the coming weekly discussion.\nDetailed requirement is as follows:\nIn the current implementation, only one LBaaS configuration is possible per tenant. It is better to have multiple LBaaS configurations for each tenant.\nWe are planning to configure haproxy as VM in a Network Service Chain. In a chain, there may be possibility of multiple Network Services of the same type (For Eg: Haproxy). For that, each Network Service should have a Unique ID (UUID) for a tenant.\n\nRegards,\nSrikanth.\n\nFrom: Stephen Balukoff [mailto:sbalukoff at bluebox.net]\nSent: Saturday, March 01, 2014 1:22 AM\nTo: Veera Reddy\nCc: Lingala Srikanth Kumar-B37208; openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>; openstack\nSubject: Re: [Openstack] Need unique ID for every Network Service\n\nHi y\'all!\n\nThe ongoing debate in the LBaaS group is whether the concept of a \'Loadbalancer\' needs to exist  as an entity. If it is decided that we need it, I\'m sure it\'ll have a unique ID. (And please feel free to join the discussion on this as well, eh!)\n\nStephen\n\nOn Thu, Feb 27, 2014 at 10:27 PM, Veera Reddy <veeraready at gmail.com<mailto:veeraready at gmail.com>> wrote:\nHi,\n\nGood idea to have unique id for each entry of network functions.\nSo that we can configure multiple network function with different configuration.\n\n\nRegards,\nVeera.\n\nOn Fri, Feb 28, 2014 at 11:23 AM, Srikanth Kumar Lingala <srikanth.lingala at freescale.com<mailto:srikanth.lingala at freescale.com>> wrote:\nHi-\nIn the existing Neutron, we have FWaaS, LBaaS, VPNaaS ?etc.\nIn FWaaS, each Firewall has its own UUID.\nIt is good to have a unique ID [UUID] for LBaaS also.\n\nPlease share your comments on the above.\n\nRegards,\nSrikanth.\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n--\nStephen Balukoff\nBlue Box Group, LLC\n(800)613-4305 x807\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/ccf6fac5/attachment.html>\n\n','<fa3a98e93f744e99ac118a2bd7126f7a@BL2PR03MB227.namprd03.prod.outlook.com>',NULL),('<08B00C0F32FC924592309F565EAF5FAA93403D1F@EXHQ1.corp.stratus.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-05 13:28:24',0,'2014-06-05 13:28:24',NULL,'[Openstack] Legacy Application Run on top of OpenStack','All,\n\nAs Amrith noted, Stratus is focusing on ways to run highly-available, legacy applications that are hosted on OpenStack.\n\nFor more info, please check out the Stratus presentations from the recent OpenStack summit in Atlanta:\n\nhttps://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/demo-theater-stratus-software-defined-availability-for-openstack\n\nThanks\nPG\n--\nSr. Technical Consultant, Stratus Technologies, Inc.\n111 Powdermill Rd, Maynard, MA 02154\nVoice: (978) 461-7557 | Twitter: stratuspaulg\n\n\n\n-----Original Message-----\nFrom: Amrith Kumar [mailto:amrith at tesora.com] \nSent: Thursday, May 29, 2014 2:39 PM\nTo: Jay Pipes; openstack at lists.openstack.org; hossein zabolzadeh\nSubject: Re: [Openstack] Legacy Application Run on top of OpenStack\n\nHi Hossein,\n\nYou can get HA on OpenStack for things like storage just as you would in\nyour existing data center. Unless you are running some highly available or\nfault tolerant hardware in your data center, I believe you will see\ncomparable reliability in an OpenStack cloud, at least with respect to\ncomputing.\n\nI am interpreting Jay\'s answer below to say that you can build additional\navailability through scale-out paradigms but that may be inconsistent with\nyour desire to make no change to your applications.\n\nIf what you are looking for is a fault tolerant offering in the OpenStack\ncloud, maybe you want to look at something like Stratus (I\'m sure someone\nfrom Stratus can respond and tell you more).\n\n-amrith\n\n| -----Original Message-----\n| From: Jay Pipes [mailto:jaypipes at gmail.com]\n| Sent: Thursday, May 29, 2014 1:56 PM\n| To: openstack at lists.openstack.org\n| Subject: Re: [Openstack] Legacy Application Run on top of OpenStack\n| \n| On 05/29/2014 05:12 AM, hossein zabolzadeh wrote:\n| > Hi there.\n| > I am baffling between Cloudstack and Openstack to select. My\n| > Datacenter has more than 10 legacy application, which need to be run\n| > on top of the best matched CMP(Cloud Management Platform). I am search\n| > a lot and I select openStack and CloudStack at the end. But, I can not\n| > make a final decision about these two CMPs. I don\'t want to make any\n| > change to my legacy application codebase. So, my exact concern is:\n| > \"How legacy applications can be run on OpenStack without any HA and\n| > resiliancy problems?\" As we know cloud-ready applications are fully\n| > awared from underlying infrastucture, but what about non-cloud-ready\n| > apps(Legacy Applications)?\n| > CloudStack is DC virtualization cloud solution(Vcloud Like Cloud\n| > Solution) that handle all of the HA and resiliancy in the\n| > infrastructure layer, but the paradigm in openStack is infrastructure\n| > provisioning(AWS like cloud), which the HA problems shoud be addressed\n| in application layer.\n| > So at general, how openStack support legacy applications to run\n| > without any HA problems?\n| > Thanks in advance.\n| \n| Hi Hossein,\n| \n| The short answer is that the idea behind \"legacy\" applications -- i.e.\n| that applications should rely on infrastructure to handle reliability of\n| the application in a scale-up-only manner -- is not something that the\n| OpenStack platform really encourages.\n| \n| We encourage scale-out behaviour and application development methodologies\n| that give the scaling, reliability, and resiliency control to the\n| application deployer to implement as they see fits best their application.\n| It\'s not a one-size-fits-all world, and as such, there are plenty of\n| application architectures and deployment methodologies that are supported\n| in cloudy environments; OpenStack doesn\'t pick or choose one over another.\n| \n| Best,\n| -jay\n| \n| _______________________________________________\n| Mailing list: http://lists.openstack.org/cgi-\n| bin/mailman/listinfo/openstack\n| Post to     : openstack at lists.openstack.org\n| Unsubscribe : http://lists.openstack.org/cgi-\n| bin/mailman/listinfo/openstack\n\n\n','<9f0123acd7fe4b94b46db70417634061@SN2PR07MB029.namprd07.prod.outlook.com>',NULL),('<08B00C0F32FC924592309F565EAF5FAA934280F0@EXHQ1.corp.stratus.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 16:51:52',0,'2014-07-03 16:51:52',NULL,'[Openstack] Nova test case failures','I just ran the Icehouse Nova self-tests under Devstack under VirtualBox, and found that 75 of them failed. Is there a list anywhere of the known failing tests, or should all of them have passed? Or am I doing something dumb?\n\nI\'m using Ubuntu Trusty (14.04) and the current copy of devstack.\n\nI started the tests as follows:\n                cd devstack\n     ./stack.sh\n     cd /opt/stack/nova\n     ./run_tests.sh -V\n\nHere are the first few tests that failed:\n\ngrep ^failure: subunit.log\nfailure: nova.tests.integrated.test_api_samples.MultinicSampleXmlTest.test_add_fixed_ip [ multipart\nfailure: nova.tests.integrated.test_api_samples.MultipleCreateJsonTest.test_multiple_create [ multipart\nfailure: nova.tests.integrated.test_api_samples.MultipleCreateJsonTest.test_multiple_create_without_reservation_id [ multipart\nfailure: nova.tests.integrated.test_api_samples.MultipleCreateXmlTest.test_multiple_create [ multipart\nfailure: nova.tests.integrated.test_api_samples.MultipleCreateXmlTest.test_multiple_create_without_reservation_id [ multipart\nfailure: nova.tests.integrated.test_api_samples.RescueJsonTest.test_server_rescue [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersActionsAllXmlTest.test_server_confirm_resize [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersActionsAllXmlTest.test_server_create_image [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersActionsAllXmlTest.test_server_password [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersActionsAllXmlTest.test_server_reboot_hard [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersSampleJsonTest.test_servers_details [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersSampleJsonTest.test_servers_get [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersSampleJsonTest.test_servers_list [ multipart\nfailure: nova.tests.integrated.test_api_samples.ServersSampleJsonTest.test_servers_post [ multipart\nfailure: nova.tests.integrated.test_servers.ServersTest.test_create_multiple_servers [ multipart\n...\n\nThanks\nPG\n--\nSr. Technical Consultant, Stratus Technologies, Inc.\n111 Powdermill Rd, Maynard, MA 02154\nVoice: (978) 461-7557 | Twitter: stratuspaulg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140703/0231c79a/attachment.html>\n\n',NULL,NULL),('<08B00C0F32FC924592309F565EAF5FAA93428221@EXHQ1.corp.stratus.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 18:14:18',0,'2014-07-03 18:14:18',NULL,'[Openstack] Nova test case failures','Thanks, Clint. I\'ll give that a try.\n\nPG\n\n\n\n','<1404409392-sup-5487@fewbar.com>',NULL),('<08B1ABF0-28FF-4CA3-A83E-254CAB2547EE@huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-16 08:11:13',0,'2015-01-16 08:11:13',NULL,'[openstack-dev] [neutron] Changes to the core team','Dear all,\n\n+1 for Doug.\n\n\nThank you,\nTina\n\nOn Jan 16, 2015, at 4:07 PM, Oleg Bondarev <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:\n\n+1 for Doug, he does a great job!\n\nThanks,\nOleg\n\nOn Fri, Jan 16, 2015 at 9:59 AM, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\nI agree with the proposed changes.\n\nI would also like to take a chance to thank Sumit for the effort he has put in this project over several years - he has been in the core team since the project\'s inception and has been a witness of all its developments - both the good and the bad ones!\n\nSalvatore\n\nOn 16 January 2015 at 04:38, Henry Gessau <gessau at cisco.com<mailto:gessau at cisco.com>> wrote:\nOn Thu, Jan 15, 2015, Kyle Mestery <mestery at mestery.com<mailto:mestery at mestery.com>> wrote:\n> As part of the change, I\'d like to propose Doug Wiegley as a new Neutron core\n> reviewer. Doug has been actively reviewing code across not only all the\n> Neutron projects, but also other projects such as infra. His help and work in\n> the services split in December were the reason we were so successful in making\n> that happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout,\n> as well as helping to merge code in the other neutron service repositories.\n\n+1 for Doug.\n\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/12781b3a/attachment.html>\n\n','<CAO_ZGNE2HKRGrkyxEK+LcG05x0nf-zbFT+JO37E5qjNBa5wnvg@mail.gmail.com>',NULL),('<08B3050F4AC648968AC410E59B722AFC@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-17 12:50:33',14400,'2013-09-17 08:50:33',NULL,'[openstack-dev] [savanna] Savanna usability','Erik,  \n\nMost of these issues have corresponding blueprints/bugs filed in Launchpad:\n\n1. https://bugs.launchpad.net/savanna/+bug/1204943\n2. https://blueprints.launchpad.net/savanna/+spec/modifying-cluster-template\n    https://blueprints.launchpad.net/savanna/+spec/modifying-node-group-template\n3. https://bugs.launchpad.net/savanna/+bug/1174612\n4. https://bugs.launchpad.net/savanna/+bug/1183387\n\n\nI agree that these are really usability issues and need to be resolved eventually.\n\nIssue #4 is the most complicated. As a first step we need to implement common code which would gather detailed cluster status with info about each node. Once it\'s done we\'ll be able to apply policies you\'re suggesting.\n\n\nRuslan  \n\n\nOn Monday, September 16, 2013 at 8:43 PM, Erik Bergenholtz wrote:\n\n> I want to start a dialog around adding some usability features to Savanna, now that I have had a chance to spend a fair amount of time provisioning, scaling and changing clusters. Here is a list of items that I believe are important to address; comments welcomed:  \n> 1. Changing an OpenStack flavor associated with a node-group template has a ripple effect on both node group and cluster templates. The reason for this is that OpenStack does not support modification of flavors; when a flavor is modified (RAM, CPU, Root Disk, etc.) the flavor is deleted and a new one is created resulting in a new flavor id. The implication is that both node-group referencing the flavor [id] and any cluster templates referencing the affected node-group become stale and unusable. A user then has to start from scratch, creating new node-groups and cluster templates for a simple flavor change.\n> a. A possible solution to this is to internally associate flavor name with node-group and look up the flavor id based on flavor name when provisioning instances\n> b. At a minimum it should be possible to change the flavor id associated with a node-group. See #2.\n>  \n> 2. Cluster templates and node group templates are immutable. This is more of an issue at the node-group level as I often times want to make changes to a node-group and want to affect all cluster templates that make use of that node-group. I see this as being fairly commonplace.\n>  \n> 3. Before provisioning a cluster, quotas should be checked to make sure that enough quota exists. I know this can be done transactionally (check quota, spawn cluster), but a basic check would go a long way.\n>  \n> 4. Spawning a large cluster comes with some problems today, as Savanna will abort if a single VM fails. In deploying large clusters (100?s to x1000), which will be commonplace, having a single slave VM (i.e. data node) not spawn properly should not necessarily be a reason to abort the entire deployment, in particular in a scaling operation. Obviously the failing VM cannot be a master service. This applies both to the plugin as well as controller as they are both involved in the deployment. I could see a possible solution being the creation of an error/fault policy allowing a user to specify (perhaps optionally) a % or hard number for minimum # of nodes that need to come up without aborting deployment.\n> a. This also applies to scaling the cluster by larger increments\n>  \n> Just some thoughts based on my experience last week; comments welcomed.\n>  \n> Best,\n>  \n> Erik\n>  \n>  \n> CONFIDENTIALITY NOTICE\n> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org (mailto:OpenStack-dev at lists.openstack.org)\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<82A63151-FDB0-45A3-9F63-59359D556B74@hortonworks.com>',NULL),('<08B59792F3F22F449DE8F6390F7587EF37FC6B42@CERNXCHG73.cern.ch>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-09 18:46:35',0,'2015-01-09 18:46:35',NULL,'[openstack-dev] [nova] Request for Spec Freeze Exception for: Quota\n Management in Nested Projects','Hi....\n       We\'d like to ask for a spec freeze exception for the Blue Print on \"Quota Management in Nested Projects\",kindly  see:  https://review.openstack.org/#/c/129420/\nThe required keystone related bits are already in Kilo, and this proposal will allow people to actually exploit this new feature and make it useful. Nested projects are very important for large organizations like CERN who are waiting for this code to be released, and many people have already given a +1 to this proposal.\nThe code is ready and can be provided immediately.The nested quota driver is made by extending the  current DbQuotaDriver and it can support One to N levels of projects. Therefore ,there is no issue with backward compatibility. It can work with hierarchical as well as non-hierarchical projects.\nKindly consider this blue print for inclusion in Kilo.\n\n      best regards,\n       Sajeesh\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150109/5957bc92/attachment.html>\n\n',NULL,NULL),('<08B8C188-1157-4A52-9D19-08DC028AF6A4@sawalha.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-18 12:07:37',-18000,'2013-04-18 17:07:37',NULL,'[openstack-dev] [Heat] Future Vision for Heat','We looked at SpiffWorkflow for nova a while back and we\'ve been using it at Rackspace. It\'s not WFaaS, but it\'s a solid library if you want a simple workflow engine inside your application. \n\n\nTypoed on an autocorrecting mobile device...\n\nOn Apr 18, 2013, at 9:34 AM, \"Joshua Harlow\" <harlowja at yahoo-inc.com> wrote:\n\n> Ok good to know! \n> \n> My major concern here though is that nova IMHO needs a solution right now and although it would be nice to wait for this common library and placement in oslo and so on. There might be paths that can be taken that don\'t require waiting for the optimal final solution to be perfected by heat. \n> \n> Any thoughts on how quickly said library can be carved out of heat (or created?) \n> \n> I would like to see how we fix nova now in all honesty, while designing said fixes so that they can be easily moved to this convection library when it\'s ready instead of waiting to fix nova until said convection library has matured.\n> \n> Sent from my really tiny device...\n> \n> On Apr 18, 2013, at 12:54 AM, \"Adrian Otto\" <adrian.otto at rackspace.com> wrote:\n> \n>> Joshua,\n>> \n>> On Apr 17, 2013, at 10:37 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>> \n>>> I\'d be very interested in having \'Scheduler & Workflow Service\' part there\n>>> be a library.\n>>> \n>>> Pretty much every application is a workflow in some way, and using said\n>>> library in nova for the orc work there would be very neat.\n>> \n>> We had an unconference session today when we discussed this concept:\n>> \n>> https://wiki.openstack.org/wiki/Convection\n>> \n>> The idea is that this could start as a library in Heat, and then be moved to Oslo upon achievement of a reasonable level of maturity.\n>> \n>>> As long as it doesn\'t change the use-case that heat desires of course (or\n>>> overload that use-case and make everything complex when it doesn\'t need to\n>>> be)?\n>> \n>> It should actually simplify Heat.\n>> \n>>> It would be very neat to use those 2 services as a library, where I can\n>>> submit arbitrary code to (the state transitions that nova does) and have\n>>> it handle calling those states, coordinating, rolling back (or at least\n>>> calling a method to rollback, since rollback is usually very specific to\n>>> what has occurred). Basically submitting jobs, but not via a DSL/CEP (or\n>>> the like), not via a model interpreter, but directly via code. Is there\n>>> any documentation on how heat handles task resumption (if 1 engine fails,\n>>> another should be able to continue the work), how are said engines made HA\n>>> and reliable?\n>> \n>> At the very least, we should expect a solution that will allow you to submit a callback in some form (possibly a web hook, or a function) so that you can act upon state transitions in the workflow. There are ways to deal with rollback. Chances are that a rather simple early implementation would shift that to the client, but there are way to deal with it in the service too.\n>> \n>>> Such a engine library would make sense as the core \'engine\' for a lot of\n>>> the openstack core projects imho.\n>> \n>> Yes, if the vision is achieved, you would use Heat for Orchestration purposes, and Convection for simple task executions. The first use case for Convection would be a task that has a start, a sequence of tasks, followed by a termination. This could be very useful in Nova when you care about kicking off a workflow and be able to get a callback upon completion of the job/task.\n>> \n>> For jobs that would benefit from parallel execution and coordination of multiple tasks, you would use Heat as an Orchestration instrument, which would in turn use multiple workflows.\n>> \n>>> Thoughts?\n>> \n>> The first implementation is likely to be library within the Heat project that the Heat engine uses. Next, an Oslo library, and then a standalone service with a REST API that uses the Oslo library for general purpose uses from applications outside Openstack, perhaps those deployed by Heat, etc. This gives us the opportunity to offer the service in an fault tolerant HA configuration for use cases that require reliable workflow execution. If you are interested in contributing, I urge you to connect with Keith Bray <keith.bray at racksopace.com> to coordinate efforts.\n>> \n>> Cheers,\n>> \n>> Adrian\n>> \n>>> \n>>> On 4/17/13 2:47 PM, \"Zane Bitter\" <zbitter at redhat.com> wrote:\n>>> \n>>>> Thanks Adrian!\n>>>> \n>>>> We should probably make it clear for those who can\'t be at Summit that\n>>>> this is not intended to be a record of the design summit discussions.\n>>>> I\'d describe this as a snapshot of Adrian\'s evolving vision for Heat,\n>>>> taken after the design summit sessions. In particular, I think it\n>>>> reflects a couple of misconceptions about the current architecture of\n>>>> Heat, and it also contains some stuff that hasn\'t been discussed at all\n>>>> at Summit (e.g. the CEP part... btw my initial reaction to this is that\n>>>> it should probably talk to Ceilometer rather than the Autoscaling\n>>>> service).\n>>>> \n>>>> That said, there certainly *is* consensus that we want to evolve Heat\n>>>> toward being able to orchestrate whole applications rather than just\n>>>> services. We\'ll be doing further work throughout the week and\n>>>> subsequently on the mailing list to refine some of these architectural\n>>>> ideas, and we\'re looking forward to working with Adrian and his team at\n>>>> Rackspace to make it happen :)\n>>>> \n>>>> cheers,\n>>>> Zane.\n>>>> \n>>>> On 16/04/13 01:56, Adrian Otto wrote:\n>>>>> Heaters,\n>>>>> \n>>>>> I attended the various sessions at the Design Summit today in Portland,\n>>>>> and assembled as many of the ideas for future planning as I could.  For\n>>>>> the benefit of those who are not attending, or who were not in these\n>>>>> sessions, I created this Wiki page to express what I think is an early\n>>>>> consensus on where we could take things. Let\'s tweak this if it\'s not a\n>>>>> good direction.\n>>>>> \n>>>>> https://wiki.openstack.org/wiki/Heat/Vision\n>>>>> \n>>>>> Keith will be doing an Unconference session on the Workflow Service\n>>>>> idea? I believe on Wednesday afternoon.\n>>>>> \n>>>>> Thanks,\n>>>>> \n>>>>> Adrian\n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<E136F08E-5E72-43C2-8749-C2C9A7D895A8@yahoo-inc.com>',NULL),('<08D65BE3-C62B-4832-9106-C832781B8509@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 12:09:52',10800,'2013-06-19 09:09:52',NULL,'[openstack-dev] [ironic] Legal issue with the name \"Ironic\"','Hi folks!\n\nRecently was trying to Google the launchpad page of Ironic project and found a company named Ironic Software (http://www.ironicsoftware.com).\nI\'m not a lawyer but I think we might experience legal issues unless we give Ironic a different name.\n\n\n- Roman Prykhodchenko\n\n\n\n',NULL,NULL),('<08D7EE3D-CD8E-45FF-A27C-543608ED1744@zeroaccess.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-03-31 09:55:55',-18000,'2011-03-31 14:55:55',NULL,'[Openstack-operators] failed to run the auth-server deamon for\n	SAIO setup','Hi Shashi,\n\nThe first thing I would do to troubleshoot this is stop every swift  \nservice you have started up.\n\n1. Problem #1 relates to proxy-server not able to bind to 8080. So I  \nwould run a \"sudo netstat -tnpl\"  to make sure that is actually not  \nbeing used by any other app you might lreaday have running. If nothing  \nis using that 8080 port, then try \"swift-init proxy-server start\" and  \nsee if you still get the error (try it running as the swift user and  \nalso as root)\n\n2. The 1.3 dev docs provide a setup using swauth for authentication,  \ntherefore there is no reason to run devauth. Unless you decided to use  \ndevauth instead of swauth.\n\n\n> swift at test3:~$ startmain\n> WARNING: Unable to increase file descriptor limit.  Running as non- \n> root?\n> Starting proxy-server...(/etc/swift/proxy-server.conf)\n> Starting container-server...(/etc/swift/container-server/1.conf)\n> Starting container-server...(/etc/swift/container-server/2.conf)\n> Starting container-server...(/etc/swift/container-server/3.conf)\n> Starting container-server...(/etc/swift/container-server/4.conf)\n> Starting account-server...(/etc/swift/account-server/1.conf)\n> Starting account-server...(/etc/swift/account-server/2.conf)\n> Starting account-server...(/etc/swift/account-server/3.conf)\n> Starting account-server...(/etc/swift/account-server/4.conf)\n> Starting object-server...(/etc/swift/object-server/1.conf)\n> Starting object-server...(/etc/swift/object-server/2.conf)\n> Starting object-server...(/etc/swift/object-server/3.conf)\n> Starting object-server...(/etc/swift/object-server/4.conf)\n> Traceback (most recent call last):\n>   File \"/usr/local/bin/swift-proxy-server\", line 7, in <module>\n>     execfile(__file__)\n>   File \"/home/swift/swift/trunk/bin/swift-proxy-server\", line 22, in  \n> <module>\n>     run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>   File \"/home/swift/swift/trunk/swift/common/wsgi.py\", line 123, in  \n> run_wsgi\n>     sock = get_socket(conf, default_port=kwargs.get(\'default_port\',  \n> 8080))\n>   File \"/home/swift/swift/trunk/swift/common/wsgi.py\", line 89, in  \n> get_socket\n>     bind_addr)\n> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>\n> WARNING: Unable to increase file descriptor limit.  Running as non- \n> root?\n> Starting auth-server...(/etc/swift/auth-server.conf)\n> Traceback (most recent call last):\n>   File \"/usr/local/bin/swift-auth-server\", line 5, in <module>\n>     pkg_resources.run_script(\'swift==1.3-dev\', \'swift-auth-server\')\n>   File \"/usr/lib/python2.6/dist-packages/pkg_resources.py\", line  \n> 461, in run_script\n>     self.require(requires)[0].run_script(script_name, ns)\n>   File \"/usr/lib/python2.6/dist-packages/pkg_resources.py\", line  \n> 1188, in run_script\n>     raise ResolutionError(\"No script named %r\" % script_name)\n> pkg_resources.ResolutionError: No script named \'swift-auth-server\'\n>\n> swift at test3:~$\n\n\n\n\nMarcelo\nhttp://www.zeroaccess.org/\nbtorch @ IRC#openstack\n\n\nOn Mar 31, 2011, at 4:33 AM, shashidhar v wrote:\n\n> HI,\n>\n> I am trying to install and test the Swift tool by following the SAIO\n> I have set up the repos and downloaded the code as per the steps  \n> given in SAIO\n>\n> swift at test3:~/swift$ cd ~/swift/trunk; sudo python setup.py develop\n> running develop\n> running egg_info\n> creating swift.egg-info\n> writing swift.egg-info/PKG-INFO\n> writing top-level names to swift.egg-info/top_level.txt\n> writing dependency_links to swift.egg-info/dependency_links.txt\n> writing entry points to swift.egg-info/entry_points.txt\n> writing manifest file \'swift.egg-info/SOURCES.txt\'\n> reading manifest file \'swift.egg-info/SOURCES.txt\'\n> reading manifest template \'MANIFEST.in\'\n> warning: no files found matching \'ChangeLog\'\n> writing manifest file \'swift.egg-info/SOURCES.txt\'\n> running build_ext\n> Creating /usr/local/lib/python2.6/dist-packages/swift.egg-link (link  \n> to .)\n> Removing swift 1.3-dev from easy-install.pth file\n> Adding swift 1.3-dev to easy-install.pth file\n> Installing st script to /usr/local/bin\n> Installing swift-account-auditor script to /usr/local/bin\n> Installing swift-account-audit script to /usr/local/bin\n> Installing swift-account-reaper script to /usr/local/bin\n> Installing swift-account-replicator script to /usr/local/bin\n> Installing swift-account-server script to /usr/local/bin\n> Installing swift-container-auditor script to /usr/local/bin\n> Installing swift-container-replicator script to /usr/local/bin\n> Installing swift-container-server script to /usr/local/bin\n> Installing swift-container-updater script to /usr/local/bin\n> Installing swift-drive-audit script to /usr/local/bin\n> Installing swift-get-nodes script to /usr/local/bin\n> Installing swift-init script to /usr/local/bin\n> Installing swift-object-auditor script to /usr/local/bin\n> Installing swift-object-info script to /usr/local/bin\n> Installing swift-object-replicator script to /usr/local/bin\n> Installing swift-object-server script to /usr/local/bin\n> Installing swift-object-updater script to /usr/local/bin\n> Installing swift-proxy-server script to /usr/local/bin\n> Installing swift-ring-builder script to /usr/local/bin\n> Installing swift-stats-populate script to /usr/local/bin\n> Installing swift-stats-report script to /usr/local/bin\n> Installing swift-bench script to /usr/local/bin\n> Installing swift-log-uploader script to /usr/local/bin\n> Installing swift-log-stats-collector script to /usr/local/bin\n> Installing swift-account-stats-logger script to /usr/local/bin\n> Installing swauth-add-account script to /usr/local/bin\n> Installing swauth-add-user script to /usr/local/bin\n> Installing swauth-cleanup-tokens script to /usr/local/bin\n> Installing swauth-delete-account script to /usr/local/bin\n> Installing swauth-delete-user script to /usr/local/bin\n> Installing swauth-list script to /usr/local/bin\n> Installing swauth-prep script to /usr/local/bin\n> Installing swauth-set-account-service script to /usr/local/bin\n>\n> Installed /home/swift/swift/trunk\n> Processing dependencies for swift==1.3-dev\n> Finished processing dependencies for swift==1.3-dev\n> swift at test3:~/swift/trunk$\n>\n>\n> swift at test3:~$ startmain\n> WARNING: Unable to increase file descriptor limit.  Running as non- \n> root?\n> Starting proxy-server...(/etc/swift/proxy-server.conf)\n> Starting container-server...(/etc/swift/container-server/1.conf)\n> Starting container-server...(/etc/swift/container-server/2.conf)\n> Starting container-server...(/etc/swift/container-server/3.conf)\n> Starting container-server...(/etc/swift/container-server/4.conf)\n> Starting account-server...(/etc/swift/account-server/1.conf)\n> Starting account-server...(/etc/swift/account-server/2.conf)\n> Starting account-server...(/etc/swift/account-server/3.conf)\n> Starting account-server...(/etc/swift/account-server/4.conf)\n> Starting object-server...(/etc/swift/object-server/1.conf)\n> Starting object-server...(/etc/swift/object-server/2.conf)\n> Starting object-server...(/etc/swift/object-server/3.conf)\n> Starting object-server...(/etc/swift/object-server/4.conf)\n> Traceback (most recent call last):\n>   File \"/usr/local/bin/swift-proxy-server\", line 7, in <module>\n>     execfile(__file__)\n>   File \"/home/swift/swift/trunk/bin/swift-proxy-server\", line 22, in  \n> <module>\n>     run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>   File \"/home/swift/swift/trunk/swift/common/wsgi.py\", line 123, in  \n> run_wsgi\n>     sock = get_socket(conf, default_port=kwargs.get(\'default_port\',  \n> 8080))\n>   File \"/home/swift/swift/trunk/swift/common/wsgi.py\", line 89, in  \n> get_socket\n>     bind_addr)\n> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>\n> WARNING: Unable to increase file descriptor limit.  Running as non- \n> root?\n> Starting auth-server...(/etc/swift/auth-server.conf)\n> Traceback (most recent call last):\n>   File \"/usr/local/bin/swift-auth-server\", line 5, in <module>\n>     pkg_resources.run_script(\'swift==1.3-dev\', \'swift-auth-server\')\n>   File \"/usr/lib/python2.6/dist-packages/pkg_resources.py\", line  \n> 461, in run_script\n>     self.require(requires)[0].run_script(script_name, ns)\n>   File \"/usr/lib/python2.6/dist-packages/pkg_resources.py\", line  \n> 1188, in run_script\n>     raise ResolutionError(\"No script named %r\" % script_name)\n> pkg_resources.ResolutionError: No script named \'swift-auth-server\'\n>\n> swift at test3:~$\n>\n> Kindly help me to resolve the above error\n>\n> Thanks & Regards,\n> shashi\n>\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack- \n> operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110331/e01908cb/attachment.html>\n\n','<AANLkTi==PuOU4gbs91i7sXRHOO5pCJcpv5e5C9iMhW4Y@mail.gmail.com>',NULL),('<08E09AF0-7B4C-44FD-9EA9-CB515DF4050D@motorolasolutions.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 00:52:44',0,'2014-02-11 00:52:44',NULL,'[Openstack] Neutron (Havana) configuration on Ubuntu','If this issue has already been discussed, please excuse.\n\nI?m somewhat confused about neutron configuration and tenancy. Correct me if I?m wrong.\n\nFirst, I?ve create a private network under the ?admin? tenant named ?admin-net\'. I?ve associated a subnet named admin-net.1 with the admin-net with a CIDR of 10.0.1.0/24.\n\nNext, I created a network with router:external set to True associated with our campus network named ?campus-net?.  This network was created under the ?service? tenant?. I also create a router named ?campus-gw? under the ?service? tenant and set it?s gateway to be the ?campus-net? network.\n\nFinally, I create a floating address pool under the ?admin? tenant named ?admin-net.float\', and add it as an interface to the ?campus-gw? router.  I also create a default security group under the ?admin? tenant to allow SSH and ICMP access.\n\nWhen I boot an image, as a member of the admin tenant, the instance is correctly assigned an IP address from the admin tenant?s private network.  I next allocate (nova floating-ip-create admin-net.float) a floating IP address and associated it my running instance.\n\nHowever, I?m unable to ping the running instance, and I see no indication of the end of the tunnel being established on the network/controller node.\n\nI?m not that well versed with network namespaces nor the openvswitch commands.\n\n2 questions.  Does my overall configuration sound correct? And how best to diagnose what?s going on here?  Any pointers would be helpful. Additional details can be provided as needed.  Thanks loads in advance.\n\nRegards,\n/ross\n\n?\n\n(neutron) net-list\n+--------------------------------------+------------+----------------------------------------------------+\n| id                                   | name       | subnets                                            |\n+--------------------------------------+------------+----------------------------------------------------+\n| 2426f4d8-a983-4f50-ab5a-fd2a37e5cd94 | campus-net | a948538d-c2c2-4c02-9116-b89a79f0c73a 173.23.0.0/16 |\n| e6984375-f35b-4636-a293-43d0d296e0ff | admin-net  | 2ced890b-944f-4f6e-8f7a-3f5a4d07c2bb 10.0.1.0/24   |\n+--------------------------------------+------------+----------------------------------------------------+\n(neutron) subnet-list\n+--------------------------------------+--------------------+---------------+---------------------------------------------------+\n| id                                   | name               | cidr          | allocation_pools                                  |\n+--------------------------------------+--------------------+---------------+---------------------------------------------------+\n| 2ced890b-944f-4f6e-8f7a-3f5a4d07c2bb | admin-net.1        | 10.0.1.0/24   | {\"start\": \"10.0.1.2\", \"end\": \"10.0.1.254\"}        |\n| a948538d-c2c2-4c02-9116-b89a79f0c73a | admin-net.floating | 173.23.0.0/16 | {\"start\": \"173.23.182.2\", \"end\": \"173.23.182.15\"} |\n+--------------------------------------+--------------------+---------------+---------------------------------------------------+\n(neutron) router-list\n+--------------------------------------+-----------+-----------------------------------------------------------------------------+\n| id                                   | name      | external_gateway_info                                                       |\n+--------------------------------------+-----------+-----------------------------------------------------------------------------+\n| 43c596c4-65fe-4c22-a48a-0a6e200abf78 | campus-gw | {\"network_id\": \"2426f4d8-a983-4f50-ab5a-fd2a37e5cd94\", \"enable_snat\": true} |\n+--------------------------------------+-----------+-----------------------------------------------------------------------------+\n(neutron) router-show campus-gw\n+-----------------------+-----------------------------------------------------------------------------+\n| Field                 | Value                                                                       |\n+-----------------------+-----------------------------------------------------------------------------+\n| admin_state_up        | True                                                                        |\n| external_gateway_info | {\"network_id\": \"2426f4d8-a983-4f50-ab5a-fd2a37e5cd94\", \"enable_snat\": true} |\n| id                    | 43c596c4-65fe-4c22-a48a-0a6e200abf78                                        |\n| name                  | campus-gw                                                                   |\n| routes                |                                                                             |\n| status                | ACTIVE                                                                      |\n| tenant_id             | service                                                                     |\n+-----------------------+-----------------------------------------------------------------------------+\n(neutron) security-group-list\n+--------------------------------------+---------+-------------+\n| id                                   | name    | description |\n+--------------------------------------+---------+-------------+\n| 0d66a3e2-7a0f-4caf-8b63-c3c8f3106242 | default | default     |\n| c87230fa-9193-47a7-8ade-cec5f7f6b958 | default | default     |\n+--------------------------------------+---------+-------------+\n(neutron)\nroot at cirrus3:/var/log/neutron# nova list\n+--------------------------------------+------+--------+------------+-------------+----------------------------------+\n| ID                                   | Name | Status | Task State | Power State | Networks                         |\n+--------------------------------------+------+--------+------------+-------------+----------------------------------+\n| ccdf7541-3a74-4289-a8ce-9fe5cffe9dbd | tvm1 | ACTIVE | None       | Running     | admin-net=10.0.1.2, 173.23.182.3 |\n+--------------------------------------+------+--------+------------+-------------+----------------------------------+\nroot at cirrus3:/var/log/neutron# nova show tvm1\n+--------------------------------------+----------------------------------------------------------+\n| Property                             | Value                                                    |\n+--------------------------------------+----------------------------------------------------------+\n| status                               | ACTIVE                                                   |\n| updated                              | 2014-02-11T00:03:25Z                                     |\n| OS-EXT-STS:task_state                | None                                                     |\n| OS-EXT-SRV-ATTR:host                 | cn1                                                      |\n| key_name                             | root                                                     |\n| image                                | cirros (57a9f5d6-8b07-4bdb-b8a0-900de339d804)            |\n| admin-net network                    | 10.0.1.2, 173.23.182.3                                   |\n| hostId                               | 982cd20cde9c5f8514c95b5ca8530258fa9454cdc988a8b007a6d20b |\n| OS-EXT-STS:vm_state                  | active                                                   |\n| OS-EXT-SRV-ATTR:instance_name        | instance-00000021                                        |\n| OS-SRV-USG:launched_at               | 2014-02-11T00:03:25.000000                               |\n| OS-EXT-SRV-ATTR:hypervisor_hostname  | cn1                                                      |\n| flavor                               | m1.tiny (1)                                              |\n| id                                   | ccdf7541-3a74-4289-a8ce-9fe5cffe9dbd                     |\n| security_groups                      | [{u\'name\': u\'default\'}]                                  |\n| OS-SRV-USG:terminated_at             | None                                                     |\n| user_id                              | 090a2de6e74b4573bd29318d4f494191                         |\n| name                                 | tvm1                                                     |\n| created                              | 2014-02-11T00:02:47Z                                     |\n| tenant_id                            | ec54b7cadcab4620bbb6d568be7bd4a8                         |\n| OS-DCF:diskConfig                    | MANUAL                                                   |\n| metadata                             | {}                                                       |\n| os-extended-volumes:volumes_attached | []                                                       |\n| accessIPv4                           |                                                          |\n| accessIPv6                           |                                                          |\n| progress                             | 0                                                        |\n| OS-EXT-STS:power_state               | 1                                                        |\n| OS-EXT-AZ:availability_zone          | nova                                                     |\n| config_drive                         |                                                          |\n+--------------------------------------+----------------------------------------------------------+\nroot at cirrus3:/var/log/neutron#\n\n--\nRoss Lillie\nDistinguished Member of Technical Staff\nMotorola Solutions, Inc.\n\nmotorolasolutions.com<http://motorolasolutions.com>\nO: +1.847.576.0012\nM: +1.847.980.2241\nE: ross.lillie at motorolasolutions.com\n\n\n[cid:75FF7557-F6FD-4406-A0BB-5CBD9BE3780A at comm.mot.com]\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/96f6598e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: MSI-Email-Identity-sm.png\nType: image/png\nSize: 10441 bytes\nDesc: MSI-Email-Identity-sm.png\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/96f6598e/attachment.png>\n\n',NULL,NULL),('<08E3B183-8191-4D5A-A208-77E3B3700410@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 14:08:22',-25200,'2014-05-06 21:08:22',NULL,'[openstack-dev] [sahara] bug triage day after summit','++ Let?s do it on Monday\n\nRegards,\nAlexander Ignatov\n\n\n\nOn 06 May 2014, at 12:13, Sergey Lukjanov <slukjanov at mirantis.com> wrote:\n\n> Hey sahara folks,\n> \n> let\'s make a Bug Triage Day after the summit.\n> \n> I\'m proposing the May, 26 for it.\n> \n> Any thoughts/objections?\n> \n> Thanks.\n> \n> -- \n> Sincerely yours,\n> Sergey Lukjanov\n> Sahara Technical Lead\n> (OpenStack Data Processing)\n> Mirantis Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CA+GZd7-G3DmddcDA7=MfpfOsygabwzkxCMc9kCXMtLoY0=t0Bg@mail.gmail.com>',NULL),('<08EEF7E2-0EB6-4D72-808B-24AC789EAEC8@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-09-22 12:17:20',-14400,'2014-09-22 16:17:20',NULL,'[Openstack-stable-maint] Stable check of openstack/tempest\n	failed','\nOn Sep 22, 2014, at 11:47 AM, Maxim Kulkin <mkulkin at mirantis.com> wrote:\n\n> Looks like somewhere new oslo.config module is used with old configuration\n> options. I\'m not sure how this is possible. Could be some\n> serialization/deserialization code that has constructed config options from\n> old data and thus bypassing normal construction and lacking some new object\n> properties.\n\nThe keystone client library is using a feature that is not available in the old version of oslo.config. It?s not clear why the old version of oslo.config is present for some jobs and the new one is present for others.\n\nDoug\n\n> \n> Unfortunately, I do not have cycles currently to look into this in more\n> detail.\n> \n> On Mon, Sep 22, 2014 at 2:40 PM, Ihar Hrachyshka <ihrachys at redhat.com>\n> wrote:\n> \n>> -----BEGIN PGP SIGNED MESSAGE-----\n>> Hash: SHA512\n>> \n>> (Fixing the wrong Doug\'s email address.)\n>> \n>> On 22/09/14 11:23, Alan Pevec wrote:\n>>> 2014-09-22 10:52 GMT+02:00 Ihar Hrachyshka <ihrachys at redhat.com>:\n>>>> Havana jobs failed, probably due to new oslo.config release.\n>>>> Since tags for the last release are already created, we won\'t\n>>>> fix those failures.\n>>> \n>>> That\'s correct, 2013.2.4 tags have been pushed and we\'re not fixing\n>>> this in Havana but it should be investigated. Oslo releases are\n>>> supposed to be backward compatible so we need to understand if\n>>> that\'s an oslo.config regression or not.\n>>> \n>> \n>> I suspect this may be due to oslo-config-options-validation work done\n>> in 1.4.0 [1]. That said, the failure is observed in glance/havana\n>> only, and logs are not very informative. The only thing that is\n>> present is the following critical error in glance-api log (no traceback):\n>> \n>> 2014-09-22 06:27:04.281 13352 CRITICAL glance [-] \'StrOpt\' object has\n>> no attribute \'type\'\n>> \n>> [1]:\n>> \n>> https://review.openstack.org/gitweb?p=openstack%2Foslo.config.git;a=commitdiff;h=2422d4118c97734067ea0b37ae159bc2e3c492c5\n>> \n>> /Ihar\n>> -----BEGIN PGP SIGNATURE-----\n>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n>> \n>> iQEcBAEBCgAGBQJUH/yhAAoJEC5aWaUY1u57WDoIAMMYBpio1k0iYVoQyFAi5BdI\n>> 306BXUsywij1DBdTdbEwqiRET2yAmFPuD4IaYXX0aeVu2quHvRxvzGCLRZQa6jXS\n>> I5ICFlOzBdCBqdauVXzqiipNr7ADSTIJ/QLexPLG3JbEsJ+F1LaFx+SsO+oI0J86\n>> 64MbbjORpr0nF5PNp5MaDbrCLvlnYyJEag76Am9UQsqTnS6YYsFyCLD45uBd223T\n>> c3x5+gPuw/20qh2dakcOoe242JcINJbNuWbDUC81mf99NAHuS0xvwatlll+rW2xS\n>> o9aKFB3sCK8J92GyHY/vDdiZGrRbsLgzLGjYo5teULSgV8b5qkcbF36egFd/5LM=\n>> =dOJu\n>> -----END PGP SIGNATURE-----\n>> \n\n\n\n','<CA+DxPih+rb-15NDMr8amJ9fwXtA9Nu7Jp+hHqX4a6DofokK7iQ@mail.gmail.com>',NULL),('<08F00EB9-AB94-47CB-9CA3-BA593A03EABE@not.mn>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-30 10:37:14',-25200,'2014-04-30 17:37:14',NULL,'[Openstack] [openstack][SWIFT] I want to talk about costs !!\n	(against amazon S3)','Alejandro,\n\nWe blogged about this recently at https://swiftstack.com/blog/2014/04/24/about-those-public-cloud-price-drops/. I\'ve asked around the office here at SwiftStack to see if we can put together some more public cost details (specifically in response to you question), so I hope we can share some more info soon.\n\n--John\n\n\n\nOn Apr 30, 2014, at 5:11 AM, Alejandro Comisario <alejandro.comisario at mercadolibre.com> wrote:\n\n> Hi guys.\n> After amazon dropped its prices among other things, on S3 its seems that i need in my compa?y to justify/analyze if swift keeps being the most cost convenient solution (we have it in house)\n> \n> When we decided going with swift one year ago, one of the main constraints was \"keeping the data in our datacenter\" so we did\'nt do the excercice of costs, but today since \"seems\" that this constraint might be no more i need to go through this excercise (of course i want to stay with swift)\n> \n> So, im reaching the community to ask experiences of people that went through the same scenario, things to take into account and recent results.\n> \n> I bumped with a great aticle from Amar Kapadia at: http://www.buildcloudstorage.com/2012/01/can-openstack-swift-hit-amazon-s3-like.html and since i belive is a great place to start, the calculations an variables might be outdated.\n> \n> help is more than apreciated!!\n> \n> \n> ?best.\n> alejandrito?\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140430/5e4c7fdd/attachment.pgp>\n\n','<CAMrG31z385KJa3cdfA68bFaJJ_CY+AJSURcqoZq=5=kV=Jv6jw@mail.gmail.com>',NULL),('<08F00EB9-AB94-47CB-9CA3-BA593A03EABE@not.mn>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-30 10:37:14',-25200,'2014-04-30 17:37:14',NULL,'[Openstack-operators] [Openstack] [openstack][SWIFT] I want to\n	talk about costs !! (against amazon S3)','Alejandro,\n\nWe blogged about this recently at https://swiftstack.com/blog/2014/04/24/about-those-public-cloud-price-drops/. I\'ve asked around the office here at SwiftStack to see if we can put together some more public cost details (specifically in response to you question), so I hope we can share some more info soon.\n\n--John\n\n\n\nOn Apr 30, 2014, at 5:11 AM, Alejandro Comisario <alejandro.comisario at mercadolibre.com> wrote:\n\n> Hi guys.\n> After amazon dropped its prices among other things, on S3 its seems that i need in my compa?y to justify/analyze if swift keeps being the most cost convenient solution (we have it in house)\n> \n> When we decided going with swift one year ago, one of the main constraints was \"keeping the data in our datacenter\" so we did\'nt do the excercice of costs, but today since \"seems\" that this constraint might be no more i need to go through this excercise (of course i want to stay with swift)\n> \n> So, im reaching the community to ask experiences of people that went through the same scenario, things to take into account and recent results.\n> \n> I bumped with a great aticle from Amar Kapadia at: http://www.buildcloudstorage.com/2012/01/can-openstack-swift-hit-amazon-s3-like.html and since i belive is a great place to start, the calculations an variables might be outdated.\n> \n> help is more than apreciated!!\n> \n> \n> ?best.\n> alejandrito?\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140430/5e4c7fdd/attachment.pgp>\n\n','<CAMrG31z385KJa3cdfA68bFaJJ_CY+AJSURcqoZq=5=kV=Jv6jw@mail.gmail.com>',NULL),('<090E0206-CEEE-4273-B1C1-8C9E5F92B0AB@pilotti.it>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 20:16:33',7200,'2013-03-05 18:16:33',NULL,'[openstack-dev] Configuration files group/section case consistency\n	between projects','Hi guys,\n\nWe recently moved the nova.conf Hyper-V options to a dedicated group and we ended up having different casings for the options group in Nova and Quantum, as section casing conventions differs between the projects. E.g.:\n\nnova.conf:\n[hyperv]\n\nquantum.conf:\n[HYPERV] \n\nThis inconsistency can lead to a lot of issues from a user perspective, as it\'s quite difficult to troubleshoot this type of configuration file errors. IMHO a common convention should be decided and applied consistently across all OpenStack projects. Since the [DEFAULT] group is uppercase, I\'d go with this casing, but anything else is fine as long as it is consistent.  \n\nIn a recent chat on the #openstack-nova channel, markmc proposed to do case insensitive group names matching, which IMO would be a perfect solution.\nThis is also supported by the fact that historically sections (groups) names are case insensitive in the INI format used by OpenStack: http://en.wikipedia.org/wiki/INI_file#Case_insensitivity  \n\n\nThanks,\n\nAlessandro\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130305/9becafaf/attachment.html>\n\n',NULL,NULL),('<091241A8-790C-40E0-A6DD-1DFFF8FCC472@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 14:33:04',25200,'2014-02-17 07:33:04',NULL,'[openstack-dev] [Murano] Need a new DSL for Murano','Clint, \n\nWe\'re collaborating with Murano. We may need to do it in a way that others could see it though. There are several things here:\nMurano doesn?t really have a ?workflow engine? similar to Mistral?s. People get confused with that but it?s just a legacy terminology, I think Murano folks were going to rename this component to be more precise about it.\nMistral DSL doesn?t seem to be a good option for solving tasks that Murano is intended to solve. Specifically I mean things like complex object composition, description of data types, contracts and so on. Like Alex and Stan mentioned Murano DSL tends to grow into a full programming language.\nMost likely Mistral will be used in Murano for implementation, at least we see where it would be valuable. But Mistral is not so matured yet, we need to keep working hard and be patient :)\n\nAnyway, we keep thinking on how to make both languages look similar or at least the possibility to use them seamlessly, if needed (call Mistral workflows from Murano DSL or vice versa).\n\nRenat Akhmerov\n@ Mirantis Inc.\n\nOn 16 Feb 2014, at 05:48, Clint Byrum <clint at fewbar.com> wrote:\n\n> Excerpts from Alexander Tivelkov\'s message of 2014-02-14 18:17:10 -0800:\n>> Hi folks,\n>> \n>> Murano matures, and we are getting more and more feedback from our early\n>> adopters. The overall reception is very positive, but at the same time\n>> there are some complaints as well. By now the most significant complaint is\n>> is hard to write workflows for application deployment and maintenance.\n>> \n>> Current version of workflow definition markup really have some design\n>> drawbacks which limit its potential adoption. They are caused by the fact\n>> that it was never intended for use for Application Catalog use-cases.\n>> \n> \n> Just curious, is there any reason you\'re not collaborating on Mistral\n> for this rather than both having a workflow engine?\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140217/23aef715/attachment.html>\n\n','<1392504455-sup-9685@fewbar.com>',NULL),('<09128868ccbd641e678ff6e44cda6544@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-28 18:22:25',7200,'2014-11-28 16:22:25',NULL,'[Openstack] Scheduler Filters Ignored',' Jay,\n\n you were right!\n\n If I remove the \"availability zone\" parameter then filters are \n applied!!!\n\n Do you know if this is an expected behavior?\n\n Best,\n\n George\n\n On Fri, 28 Nov 2014 09:44:08 -0500, Jay Pipes wrote:\n> On 11/27/2014 02:29 PM, Georgios Dimitrakakis wrote:\n>> Does it has anything to do with the fact that I am specifically\n>> requesting that node through the availability zone parameter?\n>\n> If you run the boot command without the availability zone hint, does\n> it change the behaviour?\n>\n> -jay\n>\n>\n>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-- \n\n\n','<54788A38.60502@gmail.com>',NULL),('<091967B5-EAB9-432E-9110-8EEB7404B5C1@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 20:12:55',-14400,'2014-09-09 00:12:55',NULL,'[openstack-dev] memory usage in devstack-gate (the oom-killer\n	strikes again)','Hi All - \n\nJoe had me do some quick memory profiling on nova, just an FYI if anyone wants to play with this technique, I place a little bit of memory profiling code using Guppy into nova/api/__init__.py, or anywhere in your favorite app that will definitely get imported when the thing first runs:\n\nfrom guppy import hpy\nimport signal\nimport datetime\n\ndef handler(signum, frame):\n    print \"guppy memory dump\"\n\n    fname = \"/tmp/memory_%s.txt\" % datetime.datetime.now().strftime(\"%Y%m%d_%H%M%S\")\n    prof = hpy().heap()\n    with open(fname, \'w\') as handle:\n        prof.dump(handle)\n    del prof\n\nsignal.signal(signal.SIGUSR2, handler)\n\n\n\nThen, run nova-api, run some API calls, then you hit the nova-api process with a SIGUSR2 signal, and it will dump a profile into /tmp/ like this:\n\nhttp://paste.openstack.org/show/108536/\n\nNow obviously everyone is like, oh boy memory lets go beat up SQLAlchemy again?..which is fine I can take it.  In that particular profile, there?s a bunch of SQLAlchemy stuff, but that is all structural to the classes that are mapped in Nova API, e.g. 52 classes with a total of 656 attributes mapped.   That stuff sets up once and doesn?t change.   If Nova used less ORM,  e.g. didn?t map everything, that would be less.  But in that profile there?s no ?data? lying around.\n\nBut even if you don?t have that many objects resident, your Python process might still be using up a ton of memory.  The reason for this is that the cPython interpreter has a model where it will grab all the memory it needs to do something, a time consuming process by the way, but then it really doesn?t ever release it  (see http://effbot.org/pyfaq/why-doesnt-python-release-the-memory-when-i-delete-a-large-object.htm for the ?classic? answer on this, things may have improved/modernized in 2.7 but I think this is still the general idea).\n\nSo in terms of SQLAlchemy, a good way to suck up a ton of memory all at once that probably won?t get released is to do this:\n\n1. fetching a full ORM object with all of its data\n\n2. fetching lots of them all at once\n\n\nSo to avoid doing that, the answer isn?t necessarily that simple.   The quick wins to loading full objects are to ?not load the whole thing!   E.g. assuming we can get Openstack onto 0.9 in requirements.txt, we can start using load_only():\n\nsession.query(MyObject).options(load_only(?id?, ?name?, ?ip?))\n\nor with any version, just load those columns - we should be using this as much as possible for any query that is row/time intensive and doesn?t need full ORM behaviors (like relationships, persistence):\n\nsession.query(MyObject.id, MyObject.name, MyObject.ip)\n\nAnother quick win, if we *really* need an ORM object, not a row, and we have to fetch a ton of them in one big result, is to fetch them using yield_per():\n\n   for obj in session.query(MyObject).yield_per(100):\n        # work with obj and then make sure to lose all references to it\n\nyield_per() will dish out objects drawing from batches of the number you give it.   But it has two huge caveats: one is that it isn?t compatible with most forms of eager loading, except for many-to-one joined loads.  The other is that the DBAPI, e.g. like the MySQL driver, does *not* stream the rows; virtually all DBAPIs by default load a result set fully before you ever see the first row.  psycopg2 is one of the only DBAPIs that even offers a special mode to work around this (server side cursors).\n\nWhich means its even *better* to paginate result sets, so that you only ask the database for a chunk at a time, only storing at most a subset of objects in memory at once.  Pagination itself is tricky, if you are using a naive LIMIT/OFFSET approach, it takes awhile if you are working with a large OFFSET.  It?s better to SELECT into windows of data, where you can specify a start and end criteria (against an indexed column) for each window, like a timestamp.\n\nThen of course, using Core only is another level of fastness/low memory.  Though querying for individual columns with ORM is not far off, and I?ve also made some major improvements to that in 1.0 so that query(*cols) is pretty competitive with straight Core (and Core is?well I?d say becoming visible in raw DBAPI?s rear view mirror, at least?.).\n\nWhat I?d suggest here is that we start to be mindful of memory/performance patterns and start to work out naive ORM use into more savvy patterns; being aware of what columns are needed, what rows, how many SQL queries we really need to emit, what the ?worst case? number of rows will be for sections that really need to scale.  By far the hardest part is recognizing and reimplementing when something might have to deal with an arbitrarily large number of rows, which means organizing that code to deal with a ?streaming? pattern where you never have all the rows in memory at once - on other projects I?ve had tasks that would normally take about a day, but in order to organize it to ?scale?, took weeks - such as being able to write out a 1G XML file from a database (yes, actual use case - not only do you have to stream your database data, but you also have to stream out your DOM nodes for which I had to write some fancy SAX extensions).   \n\nI know that using the ORM makes SQL development ?easy?, and so many anti-ORM articles insist that this lulls us all into not worrying about what is actually going on (as much as SQLAlchemy eschews that way of working)?but I remain optimistic that it *is* possible to use tools that save a vast amount of effort, code verbosity and inconsistency that results from doing everything ?by hand?, while at the same time not losing our ability to understand how we?re talking to the database.   It?s a cake and eat it too, situation, I know.\n\nThis is already what I?m here to contribute on, I?ve been working out some new SQLAlchemy patterns that hopefully will help, but in the coming weeks I may try to find time to spot some more of these particular things within current Nova code without getting too much into a total rewrite as of yet.\n\n\n\n\n\nOn Sep 8, 2014, at 6:24 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n\n> Hi All,\n> \n> We have recently started seeing assorted memory issues in the gate including the oom-killer [0] and libvirt throwing memory errors [1]. Luckily we run ps and dstat on every devstack run so we have some insight into why we are running out of memory. Based on the output from job taken at random [2][3] a typical run consists of:\n> \n> * 68 openstack api processes alone\n> * the following services are running 8 processes (number of CPUs on test nodes)\n>   * nova-api (we actually run 24 of these, 8 compute, 8 EC2, 8 metadata)\n>   * nova-conductor\n>   * cinder-api\n>   * glance-api\n>   * trove-api\n>   * glance-registry\n>   * trove-conductor\n> * together nova-api, nova-conductor, cinder-api alone take over 45 %MEM (note: some of that is memory usage is counted multiple times as RSS includes shared libraries)\n> * based on dstat numbers, it looks like we don\'t use that much memory before tempest runs, and after tempest runs we use a lot of memory.\n> \n> Based on this information I have two categories of questions:\n> \n> 1) Should we explicitly set the number of workers that services use in devstack? Why have so many workers in a small all-in-one environment? What is the right balance here?\n> \n> 2) Should we be worried that some OpenStack services such as nova-api, nova-conductor and cinder-api take up so much memory? Does there memory usage keep growing over time, does anyone have any numbers to answer this? Why do these processes take up so much memory?\n> \n> best,\n> Joe\n> \n> \n> [0] http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwib29tLWtpbGxlclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDEwMjExMjA5NzY3fQ==\n> [1] https://bugs.launchpad.net/nova/+bug/1366931\n> [2] http://paste.openstack.org/show/108458/\n> [3] http://logs.openstack.org/83/119183/4/check/check-tempest-dsvm-full/ea576e7/logs/screen-dstat.txt.gz\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140908/f563be97/attachment.html>\n\n','<CAHXdxOf+Tfk_UFrvhjKcHPk8TSzQAcWi2+pGSJJqm+qxrtoM1Q@mail.gmail.com>',NULL),('<091F77DB-8E42-4910-9619-EA360EE9279D@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-12-18 10:27:17',3600,'2012-12-18 09:27:17',NULL,'[Openstack-docs] [Basic-Install] Doc Update','Thanks a lot for that update Emilien. Will test it :)\nregards,\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 15 d?c. 2012 ? 14:49, Emilien Macchi <emilien at enovance.com> a ?crit :\n\n> Hi,\n> \n> I finally found the time to update my basic-install documentation, and I hope you will like the work :\n> \n> https://review.openstack.org/18168\n> \n> I think it\'s really a good start for any beginner in OpenStack. By the way, next week in Paris I organize an OpenStack Workshop with 30 people, and guys will use this doc. I would love to see the doc online before Thursday. Please let me know if something\'s wrong and I\'ll fix it.\n> \n> Enjoy your week-end,\n> \n> \n> Cheers !\n> \n> PS : Thank\'s to Martin Loschwitz (Hastexo) for the help :)\n> \n> --\n> Emilien Macchi\n> OpenStack Engineer\n> \n> <eNovance_petit.png>\n> \n> EMAIL : emilien.macchi at enovance.com ? SKYPE : enovance-emilien.macchi - PHONE : +33 (0)1 49 70 99 80\n> WEB : www.enovance.com\n> \n> <eNoCloud_petit.png>\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20121218/0f5549eb/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20121218/0f5549eb/attachment-0001.jpg>\n\n','<4f333e63-8d64-45e3-826d-93b1838658bb@mail-1.enovance.com>',NULL),('<092B6EE3-3BB7-4A64-B3CC-EB6594528046@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2012-09-10 12:06:17',-14400,'2012-09-10 16:06:17',NULL,'[openstack-hpc] [Openstack] [HPC] Reminder monthly telecon Sep.\n	10','OK.  Standing by.\n\n-------------------------------------------------\nBrian Schott, CTO\nNimbis Services, Inc.\nbrian.schott at nimbisservices.com\nph: 443-274-6064  fx: 443-274-6060\n\n\n\nOn Sep 10, 2012, at 12:02 PM, David Kang <dkang at isi.edu> wrote:\n\n> \n> Hello,\n> \n> We will use different webex host today because of some technical problem.\n> Sorry for that.\n> \n> David\n> \n> ----------------------\n> Dr. Dong-In \"David\" Kang\n> Computer Scientist\n> USC/ISI\n> \n> ----- Original Message -----\n>> I am guessing your intent is to determine the maximum available\n>> bandwidth and lowest latency (commonly implemented as least hops) path\n>> between hosts. In other platforms there is the notion of Cell, Zone,\n>> Row, Rack etc where the host that you are running your workload has\n>> the topology encoded in the host meta information itself.\n>> \n>> \n>> In instances where this is not encoded within some sort of meta of the\n>> host either shortest path first or constrained shortest path first can\n>> be run to determine the network, topology and either distributed to\n>> the nodes. The challenge here is that it is really hard to take into\n>> account available bandwidth between nodes vs hops.\n>> \n>> \n>> \n>> \n>> \n>> \n>> Regards,\n>> \n>> Colin\n>> \n>> If you would like to schedule a time to speak with me, please click\n>> here to see my calendar and pick a time that works for your schedule.\n>> The system will automatically send us both an outlook meeting invite.\n>> Colin McNamara\n>> (858)208-8105\n>> CCIE #18233,VCP\n>> http://www.colinmcnamara.com\n>> http://www.linkedin.com/in/colinmcnamara\n>> \n>> \"The difficult we do immediately, the impossible just takes a little\n>> longer\"\n>> \n>> \n>> \n>> \n>> \n>> \n>> \n>> On Sep 7, 2012, at 9:54 AM, Joseph Suh < jsuh at isi.edu > wrote:\n>> \n>> \n>> All,\n>> \n>> I have a blue print on proximity scheduler at\n>> http://wiki.openstack.org/ProximityScheduler , and would like to get\n>> feedback on it.\n>> \n>> Thanks,\n>> \n>> Joseph\n>> \n>> ----- Original Message -----\n>> From: \"John Paul Walters\" < jwalters at isi.edu >\n>> To: openstack at lists.launchpad.net\n>> Cc: openstack-hpc at lists.openstack.org\n>> Sent: Friday, September 7, 2012 12:12:20 PM\n>> Subject: [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10\n>> \n>> \n>> Hi,\n>> \n>> \n>> This is a reminder that we\'ll hold our next monthly HPC telecon this\n>> coming Monday, Sep. 10 and 12:00 noon Eastern Time. We\'ll use webex\n>> (details below). The agenda is somewhat open. Our default will be to\n>> start the conversation about HPC features that folks are interested in\n>> adding to the Grizzly release. If anyone has any other specific agenda\n>> items, they\'re welcome to propose them.\n>> \n>> \n>> I\'m unable to attend, so my colleague David Kang will be hosting this\n>> meeting. We look forward to talking to you!\n>> \n>> \n>> best,\n>> JP\n>> \n>> \n>> John Paul Walters invites you to attend this online meeting.\n>> \n>> Topic: HPC Monthly Telecon\n>> Date: Monday, September 10, 2012\n>> Time: 12:00 pm, Eastern Daylight Time (New York, GMT-04:00)\n>> Meeting Number: 927 246 497\n>> Meeting Password: hpcmonthly\n>> \n>> \n>> -------------------------------------------------------\n>> To join the online meeting (Now from mobile devices!)\n>> -------------------------------------------------------\n>> 1. Go to\n>> https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&RT=MiMxMQ%3D%3D\n>> 2. If requested, enter your name and email address.\n>> 3. If a password is required, enter the meeting password: hpcmonthly\n>> 4. Click \"Join\".\n>> \n>> To view in other time zones or languages, please click the link:\n>> https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&ORT=MiMxMQ%3D%3D\n>> \n>> \n>> _______________________________________________\n>> OpenStack-HPC mailing list\n>> OpenStack-HPC at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n>> \n>> _______________________________________________\n>> Mailing list: https://launchpad.net/~openstack\n>> Post to : openstack at lists.launchpad.net\n>> Unsubscribe : https://launchpad.net/~openstack\n>> More help : https://help.launchpad.net/ListHelp\n>> \n>> \n>> _______________________________________________\n>> OpenStack-HPC mailing list\n>> OpenStack-HPC at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n> \n> _______________________________________________\n> OpenStack-HPC mailing list\n> OpenStack-HPC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20120910/ce449361/attachment.html>\n\n','<786763063.897118.1347292946861.JavaMail.root@zm.isi.edu>',NULL),('<092e5c4188ff6a4571bb74e83eb7dd6d@li.nux.ro>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 16:46:28',0,'2012-11-20 16:46:28',NULL,'[openstack-dev] openstack using glusterfs to store vm instance\n images get error','On 20.11.2012 03:34, fengdong wrote:\n> The error is \"libvirtError: internal error Process exited while \n> reading\n> console log output: chardev: opening backend \"file\" failed\"\n>\n>\n>\n> I have changed the /etc/libvirt/qemu.conf user & group to root, but \n> still\n> get such error.\n>\n>\n>\n> Anyone can help ?\n\nTry to do it with selinux in permissive mode, see if it helps.\n\n\n-- \nSent from the Delta quadrant using Borg technology!\n\nNux!\nwww.nux.ro\n\n\n','<000001cdc6cf$f6056110$e2102330$@com>',NULL),('<0943A8EB-6B72-41AA-AFF7-446BC09026CC@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 23:02:37',32400,'2013-12-09 14:02:37',NULL,'[openstack-dev] [oslo][neutron] Post-mortem debugging for tests?','Are any other projects interested in adding back the post-mortem debugging support we lost in the move away from nose?  I have a patch in review for neutron and salv-orlando asked whether oslo might be the better place for it.\n\nhttps://review.openstack.org/#/c/43776/\n\n\nm.\n\n',NULL,NULL),('<09470AA7-BA0D-43E3-A83C-8D58A5A13A18@cit.ie>','http://lists.openstack.org/pipermail/community',NULL,'2013-01-09 21:05:51',0,'2013-01-09 21:05:51',NULL,'[openstack-community] Calling all user group and meetup\n	organizers','Hi S?an,\n\nI run the OpenStack Ireland meetup group, just wondering if your meeting is targeting only groups in the East Coast of the USA?\n\nKind Regards,\nTim\n\nOn 9 Jan 2013, at 00:54, Sean Roberts <seanrob at yahoo-inc.com> wrote:\n\n> We are going to have a planning meeting on Tuesday, 15 Jan 2012 11:00am to 1:00pm PST. RSVP via  http://www.meetup.com/openstack/events/93593062/  Connect remotely via webex https://yahoomeetings.webex.com/yahoomeetings/j.php?ED=160663792&UID=492396097&RT=MiM0\n> If this time doesn\'t work for you, get ahold of me directly via skype:seanroberts66, email, mobile, irc:sarob, twitter:sarob, or carrier pigeon.\n> \n> Stefano and Thierry will be joining us. I want to get input from people that run user groups and meetups.\n> \n> See you then!\n> \n> Sean Roberts\n> Infrastructure Strategy\n> seanrob at yahoo-inc.com\n> Direct (408) 349-5234  Mobile (925) 980-4729\n>  \n> 701 First Avenue, Sunnyvale, CA, 94089-0703, US\n> Phone (408) 349-3300  Fax (408) 349-3301\n>  \n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\nRegards,\nTim\n\n\n---------------------------------------------------------------------------------------------\nTIM HORGAN\nHead of Cloud Computing Centre of Excellence\nExtended Campus Office\nCork Institute of Technology, Cork, Ireland\nphone: +353 214335120 | mobile: +353 87 9439333\ntwitter: @timhorgan | skype: timothy.horgan\nlinkedin: http://ie.linkedin.com/in/timhorgan | web: http://cloud.cit.ie\n---------------------------------------------------------------------------------------------\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130109/778ffbd8/attachment-0001.html>\n\n','<CD11FFD5.8C6CE%seanrob@yahoo-inc.com>',NULL);
INSERT INTO `messages` VALUES ('<0948E55F-3058-46FD-9004-EF04795BE8FA@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-06 13:51:37',-25200,'2014-08-06 20:51:37',NULL,'[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the\n	way forward','\nOn Aug 6, 2014, at 1:27 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> However, it seems to me that the end-goal of the GBP effort is *actually* to provide a higher-layer API to Neutron that would essentially enable proprietary vendors to entirely swap out all of Neutron core for a new set of drivers that spoke proprietary device APIs.\n> \n> If this is the end-goal, it should be stated more clearly, IMO.\n\nI believe that people should be considered innocent until proven otherwise. Is there a reason to believe there is some hidden reason behind this proposal ? It seems to me that this is uncalled for.\n\nNeutron allows vendors to speak to proprietary device APIs, it was designed to do so, AFAIK. It is also possibly to \"entirely swap out all of the Neutron core\"... the proponents of the group based policy didn\'t have to go through so much trouble if that was their intent. As far as i know most plugins talk to a proprietary API.\n\nI happen to disagree technically with a couple of choices made by this proposal; but the blueprint was approved. Which means that i lost the argument, or didn\'t raise it on time, or didn\'t argue convincingly... regardless of the reason, the time to argue about the goal has passed. The decision of the community was to approve the spec and that decision should be respected.\n\n  Pedro.\n\n','<53E28F96.6090300@gmail.com>',NULL),('<0952654E-ACE5-4AF9-8EED-C17AC336D31E@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-29 21:28:09',-14400,'2012-07-30 01:28:09',NULL,'[openstack-dev] Hiding complexity of paste config files from\n	operators','All:\n\nI wanted to discuss the usability of the paste config files from an operator\'s point of view. The paste config files are opaque to administrators who are trying to stand an OpenStack cloud for the first time, since they expose a lot of implementation details about the middleware. I can follow the instructions in the Install and Deploy guide, but I have no idea what the options I don\'t edit are, and if the documentation has deviated from the implementation, I\'m pretty much stuck.\n\nAs an example, the install and deploy guide says to add authtoken to the pipeline:glance-api section in glance-api-paste.ini <http://docs.openstack.org/essex/openstack-compute/install/content/configure-glance-files.html>, the example in the docs looks like this:\n\n[pipeline:glance-api]\npipeline = versionnegotiation authtoken auth-context apiv1app\n\nIf I install from packages on precise, there\'s also some lines that look like this:\n\n[pipeline:glance-api-keystone]\npipeline = versionnegotiation authtoken context apiv1app\n\n\nIt looks similar, and it has \"keystone\" in there, so maybe that\'s intended to be used for keystone? And it looks pretty similar, but there\'s a \"auth-context\" instead of \"context\". Maybe the pipeline:glance-api-keystone is used for something else in glance? In the end, I\'m just going to slavishly follow the documentation, and I have no mental model of what these options do. \n\nOn the other hand, the traditional configuration files (e.g., nova.conf) are (relatively) well-documented, have default values, and everything that\'s exposed is something that could potentially be changed by an administrator. In particular, there\'s generally a one-to-one correspondence between changing a configuration setting and changing the behavior of the system in a way that\'s meaningful for the operator. For example, enabling FlatDHCP in nova.conf is just setting a config option to one value:\n\nnetwork_manager=nova.network.manager.FlatDHCPManager\n\n\nAssuming that the *-paste.ini files always need to be there, is there some way we could avoid requiring admins to edit these files, and instead make it more like editing the .conf files? For example, could the paste.ini files be generated from the corresponding .conf file as needed?\n\n\nTake care,\n\nLorin\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120729/96fd9f6f/attachment.html>\n\n',NULL,NULL),('<095A459E-6332-44CD-ACB5-6008FFD3101A@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-08-10 13:41:45',-14400,'2012-08-10 17:41:45',NULL,'[Openstack-docs] openstack-hpc on lists.openstack.org','Is it appropriate to setup an openstack-hpc list using lists.openstack.org? If so, how do you request a list? I sent a request to the mailman administrator account earlier this week, but don\'t know if that is actively monitored.  \n\nThanks,\nBrian\n\n-------------------------------------------------\nBrian Schott, CTO\nNimbis Services, Inc.\nbrian.schott at nimbisservices.com\nph: 443-274-6064  fx: 443-274-6060\n\n\n\n\n\n',NULL,NULL),('<0964680E34135E448EAD3748C6769FD6653A28@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 12:03:20',0,'2013-11-15 12:03:20',NULL,'[openstack-dev] [Glance] Version about Glance cache manage API','Hi, Glance developers\n\nLet me know about Glance cache manage API.\n\nIn \"__init__\" method of glance/api/middleware/cache_manage.py,\nThere are \"/v1/XXXX\" string.but There is\'nt \"/v2/XXXX\" string.\n\nif \"enable_v1_api\" is False in glance-api.conf, \nI guess it is disable to use Glance cache manage API.\n\nIs it correct? \nAnd if my assumption is true, is this action intentional?\n\n(if this is bug, I will report bug in launchpad.)\n\nBest Regards,\n-- Noboru Arai\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 6535 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/1cff109e/attachment.bin>\n\n',NULL,NULL),('<0964680E34135E448EAD3748C6769FD6654921@BPXM06GP.gisp.nec.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 11:08:39',0,'2013-11-18 11:08:39',NULL,'[openstack-dev] [Glance] Version about Glance cache manage API','Hi Flavio,\n\nThank you for your reply.\n\nI\'m going to read the blueprint.\n\n\n-----Original Message-----\nFrom: Flavio Percoco [mailto:flavio at redhat.com] \nSent: Friday, November 15, 2013 9:37 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Glance] Version about Glance cache manage API\n\nOn 15/11/13 12:03 +0000, Noboru Arai wrote:\n>Hi, Glance developers\n>\n>Let me know about Glance cache manage API.\n>\n>In \"__init__\" method of glance/api/middleware/cache_manage.py,\n>There are \"/v1/XXXX\" string.but There is\'nt \"/v2/XXXX\" string.\n>\n>if \"enable_v1_api\" is False in glance-api.conf, I guess it is disable \n>to use Glance cache manage API.\n>\n>Is it correct?\n>And if my assumption is true, is this action intentional?\n\nThat\'s correct and it\'s not the behavior we want to move forward.\nThere\'s a blueprint for that, which is currently assigned to me. I haven\'t worked on this yet because we need to discuss it a bit\nfurther. However, I intend to do so.\n\nBP: https://blueprints.launchpad.net/glance/+spec/glance-cache-path\n\nCheers,\nFF\n\n\n--\n@flaper87\nFlavio Percoco\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 6535 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/971a0fc1/attachment.bin>\n\n','<20131115123718.GG32325@redhat.com>',NULL),('<096BA77B-FAF6-46F3-9E83-FBEE72D898B4@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-12 12:54:29',3600,'2014-12-12 11:54:29',NULL,'[openstack-dev] [Fuel] Hard Code Freeze for 6.0','Hi,\n\nAs with 5.1.x, please inform the list if you are rising priority to critical in any bugs targeted to 6.0.\n\nRegards,\n\n> On 09 Dec 2014, at 23:43, Mike Scherbakov <mscherbakov at mirantis.com> wrote:\n> \n> Hi all,\n> I\'m glad to announce that we\'ve reached Hard Code Freeze (HCF) [1] criteria for 6.0 milestone. \n> \n> stable/6.0 branches for our repos were created.\n> \n> Bug reporters, please do not forget to target both 6.1 (master) and 6.0 (stable/6.0) milestones since now. If the fix is merged to master, it has to be backported to stable/6.0 to make it available in 6.0. Please ensure that you do NOT merge changes to stable branch first. It always has to be a backport with the same Change-ID. Please see more on this at [2].\n> \n> I hope Fuel DevOps team can quickly update nightly builds [3] to reflect changes.\n> \n> [1] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze\n> [2] https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series\n> [3] https://fuel-jenkins.mirantis.com/view/ISO/\n> \n> Thanks,\n> -- \n> Mike Scherbakov\n> #mihgen\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nTomasz \'Zen\' Napierala\nSr. OpenStack Engineer\ntnapierala at mirantis.com\n\n\n\n\n\n\n\n\n','<CAKYN3rMtHbQN9jjqZvcdfwbx8Xcgbhr29sKWBotDA=gTSExWcA@mail.gmail.com>',NULL),('<096DE3A060628644893976A610FDE6F26B7C1D51@ORSMSX107.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 20:11:14',0,'2013-06-05 20:11:14',NULL,'[openstack-dev] about the ovs plugin & ovs setup for the tunnel\n	network type','Hi there,\n\nI am little new to the openstack networking project, previously known as quantum:)\n\nAnyway I have few simple questions regarding the way ovs gets configured the way it is in the current form in kvm!!\n\nHere it goes,\n\n\n-          As I understand, OVS setups two datapaths instances br-int & br-tun & uses patch port to connect them. Additionally it uses local vlans in the br-int for the vm-vm traffic!!\n\no   I understand the reason behind the current setup but I am not sure why it needs to be like it?\n\n?  can\'t the same features can be supported with single instance like br-int & fllows are setup correctly to get things right including quantum security groups?\n\n\nI know there must be some technical reasons behind all these but I just want get some history & also want to know whether anyone is planning to enhance it in future?\n\nThx,\n\nNrupal.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130605/105d6e32/attachment.html>\n\n',NULL,NULL),('<096DE3A060628644893976A610FDE6F26B89A300@FMSMSX154.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 21:14:55',0,'2014-01-27 21:14:55',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','Hi,\n\nThere are two possibilities for the hybrid compute nodes\n\n-          In the first case, a compute node has two NICs,  one SRIOV NIC & the other NIC for the VirtIO\n\n-          In the 2nd case, Compute node has only one SRIOV NIC, where VFs are used for the VMs, either macvtap or direct assignment.  And the PF is used for the uplink to the linux bridge or OVS!!\n\nMy question to the team is whether we consider both of these deployments or not?\n\nThx,\n\nNrupal\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Monday, January 27, 2014 1:01 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Robert,\nPlease see inline\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 10:29 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Irena,\n\nI agree on your first comment.\n\nsee inline as well.\n\nthanks,\nRobert\n\nOn 1/27/14 10:54 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nMy comments inline\n\nRegards,\nIrena\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 5:05 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Folks,\n\nIn today\'s meeting, we discussed a scheduler issue for SRIOV. The basic requirement is for coexistence of the following compute nodes in a cloud:\n      -- SRIOV only compute nodes\n      -- non-SRIOV only compute nodes\n      -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of a proper name, let\'s call them compute nodes with hybrid NICs support, or simply hybrid compute nodes.\n\nI\'m not sure if it\'s practical in having hybrid compute nodes in a real cloud. But it may be useful in the lab to bench mark the performance differences between SRIOV, non-SRIOV, and coexistence of both.\n[IrenaB]\nI would like to clarify a bit on the requirements you stated below.\nAs I see it, the hybrid compute nodes actually can be preferred in the real cloud, since one can define VM with one vNIC attached via SR-IOV virtual function while the other via some vSwitch.\nBut it definitely make sense to land VM with \'virtio\' vNICs only on the non-SRIOV compute node.\n\nMaybe there should be some sort of preference order of suitable nodes in scheduler choice, based on vnic types required for the VM.\n\nIn a cloud that supports SRIOV in some of the compute nodes, a request such as:\n\n     nova boot -flavor m1.large -image <image-uuid> --nic net-id=<net-uuid> vm\n\ndoesn\'t require a SRIOV port. However, it\'s possible for the nova scheduler to place it on a compute node that supports sriov port only. Since neutron plugin runs on the controller, port-create would succeed unless neutron knows the host doesn\'t support non-sriov port. But connectivity on the node would not be established since no agent is running on that host to establish such connectivity.\n[IrenaB] I\nHaving ML2 plugin as neutron backend, will fail to bind the port, in no agent is running on the Host\n\n[ROBERT] If a host supports SRIOV only, and there is an agent running on the host to support SRIOV, would binding succeed in ML2 plugin for the above \'nova boot\' request?\n[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will bind the port only if it supports vic_type and there is live agent on this host. So it should work\n\nOn a hybrid compute node, can we run multiple neutron L2 agents on a single host? It seems possible.\n\nIrena brought up the idea of using host aggregate. This requires creation of a non-SRIOV host aggregate, and use that in the above \'nova boot\' command. It should work.\n\nThe patch I had introduced a new constraint in the existing PCI passthrough filter.\n\nThe consensus seems to be having a better solution in a later release. And for now, people can either use host aggregate or resort to their own means.\n\nLet\'s keep the discussion going on this.\n\nThanks,\nRobert\n\n\n\n\n\nOn 1/24/14 4:50 PM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nHi Folks,\n\nBased on Thursday\'s discussion and a chat with Irena, I took the liberty to add a summary and discussion points for SRIOV on Monday and onwards. Check it out https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to update it. Let\'s try to finalize it next week. The goal is to determine the BPs that need to get approved, and to start coding.\n\nthanks,\nRobert\n\n\nOn 1/22/14 8:03 AM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nSounds great! Let\'s do it on Thursday.\n\n--Robert\n\nOn 1/22/14 12:46 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nI would suggest not to delay the SR-IOV discussion to the next week.\nLet\'s try to cover the SRIOV side and especially the nova-neutron interaction points and interfaces this Thursday.\nOnce we have the interaction points well defined, we can run parallel patches to cover the full story.\n\nThanks a lot,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Wednesday, January 22, 2014 12:02 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV\n\nHi Folks,\n\nAs the debate about PCI flavor versus host aggregate goes on, I\'d like to move forward with the SRIOV side of things in the same time. I know that tomorrow\'s IRC will be focusing on the BP review, and it may well continue into Thursday. Therefore, let\'s start discussing SRIOV side of things on Monday.\n\nBasically, we need to work out the details on:\n        -- regardless it\'s PCI flavor or host aggregate or something else, how to use it to specify a SRIOV port.\n        -- new parameters for -nic\n        -- new parameters for neutron net-create/neutron port-create\n        -- interface between nova and neutron\n        -- nova side of work\n        -- neutron side of work\n\nWe should start coding ASAP.\n\nThanks,\nRobert\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140127/7ee6c352/attachment-0001.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E77882FBCA6@MTLDAG02.mtl.com>',NULL),('<096DE3A060628644893976A610FDE6F26B89E97E@ORSMSX107.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 16:55:11',0,'2014-01-28 16:55:11',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','My comments inline below.\n\nNrupal.\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Tuesday, January 28, 2014 8:32 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi,\n\nFor the second case, supposed that the PF is properly configured on the host, is it a matter of configuring it as you normally do with a regular ethernet interface to add it to the linux bridge or OVS?\n[nrj] yes. While technically it is possible, we as a team can decide about the final recommendation:)  Given that VFs are going to be used for the high-performance VMs, mixing VMs with virtio & VFs may not be a good option.  Initially we can use PF interface for the management traffic and/or VF configuration!!\n\n--Robert\n\nOn 1/28/14 1:03 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Nrupal,\nWe definitely consider both these cases.\nAgree with you that we should aim to support both.\n\nBR,\nIrena\n\n\nFrom: Jani, Nrupal [mailto:nrupal.jani at intel.com]\nSent: Monday, January 27, 2014 11:17 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi,\n\nThere are two possibilities for the hybrid compute nodes\n\n-          In the first case, a compute node has two NICs,  one SRIOV NIC & the other NIC for the VirtIO\n\n-          In the 2nd case, Compute node has only one SRIOV NIC, where VFs are used for the VMs, either macvtap or direct assignment.  And the PF is used for the uplink to the linux bridge or OVS!!\n\nMy question to the team is whether we consider both of these deployments or not?\n\nThx,\n\nNrupal\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Monday, January 27, 2014 1:01 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Robert,\nPlease see inline\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 10:29 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Irena,\n\nI agree on your first comment.\n\nsee inline as well.\n\nthanks,\nRobert\n\nOn 1/27/14 10:54 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nMy comments inline\n\nRegards,\nIrena\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 5:05 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Folks,\n\nIn today\'s meeting, we discussed a scheduler issue for SRIOV. The basic requirement is for coexistence of the following compute nodes in a cloud:\n      -- SRIOV only compute nodes\n      -- non-SRIOV only compute nodes\n      -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of a proper name, let\'s call them compute nodes with hybrid NICs support, or simply hybrid compute nodes.\n\nI\'m not sure if it\'s practical in having hybrid compute nodes in a real cloud. But it may be useful in the lab to bench mark the performance differences between SRIOV, non-SRIOV, and coexistence of both.\n[IrenaB]\nI would like to clarify a bit on the requirements you stated below.\nAs I see it, the hybrid compute nodes actually can be preferred in the real cloud, since one can define VM with one vNIC attached via SR-IOV virtual function while the other via some vSwitch.\nBut it definitely make sense to land VM with \'virtio\' vNICs only on the non-SRIOV compute node.\n\nMaybe there should be some sort of preference order of suitable nodes in scheduler choice, based on vnic types required for the VM.\n\nIn a cloud that supports SRIOV in some of the compute nodes, a request such as:\n\n     nova boot -flavor m1.large -image <image-uuid> --nic net-id=<net-uuid> vm\n\ndoesn\'t require a SRIOV port. However, it\'s possible for the nova scheduler to place it on a compute node that supports sriov port only. Since neutron plugin runs on the controller, port-create would succeed unless neutron knows the host doesn\'t support non-sriov port. But connectivity on the node would not be established since no agent is running on that host to establish such connectivity.\n[IrenaB] I\nHaving ML2 plugin as neutron backend, will fail to bind the port, in no agent is running on the Host\n\n[ROBERT] If a host supports SRIOV only, and there is an agent running on the host to support SRIOV, would binding succeed in ML2 plugin for the above \'nova boot\' request?\n[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will bind the port only if it supports vic_type and there is live agent on this host. So it should work\n\nOn a hybrid compute node, can we run multiple neutron L2 agents on a single host? It seems possible.\n\nIrena brought up the idea of using host aggregate. This requires creation of a non-SRIOV host aggregate, and use that in the above \'nova boot\' command. It should work.\n\nThe patch I had introduced a new constraint in the existing PCI passthrough filter.\n\nThe consensus seems to be having a better solution in a later release. And for now, people can either use host aggregate or resort to their own means.\n\nLet\'s keep the discussion going on this.\n\nThanks,\nRobert\n\n\n\n\n\nOn 1/24/14 4:50 PM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nHi Folks,\n\nBased on Thursday\'s discussion and a chat with Irena, I took the liberty to add a summary and discussion points for SRIOV on Monday and onwards. Check it out https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to update it. Let\'s try to finalize it next week. The goal is to determine the BPs that need to get approved, and to start coding.\n\nthanks,\nRobert\n\n\nOn 1/22/14 8:03 AM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nSounds great! Let\'s do it on Thursday.\n\n--Robert\n\nOn 1/22/14 12:46 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nI would suggest not to delay the SR-IOV discussion to the next week.\nLet\'s try to cover the SRIOV side and especially the nova-neutron interaction points and interfaces this Thursday.\nOnce we have the interaction points well defined, we can run parallel patches to cover the full story.\n\nThanks a lot,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Wednesday, January 22, 2014 12:02 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV\n\nHi Folks,\n\nAs the debate about PCI flavor versus host aggregate goes on, I\'d like to move forward with the SRIOV side of things in the same time. I know that tomorrow\'s IRC will be focusing on the BP review, and it may well continue into Thursday. Therefore, let\'s start discussing SRIOV side of things on Monday.\n\nBasically, we need to work out the details on:\n        -- regardless it\'s PCI flavor or host aggregate or something else, how to use it to specify a SRIOV port.\n        -- new parameters for -nic\n        -- new parameters for neutron net-create/neutron port-create\n        -- interface between nova and neutron\n        -- nova side of work\n        -- neutron side of work\n\nWe should start coding ASAP.\n\nThanks,\nRobert\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/3d620a13/attachment.html>\n\n','<CF0D3C3E.3CF8E%baoli@cisco.com>',NULL),('<096DE3A060628644893976A610FDE6F26B8A098E@ORSMSX107.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 16:56:01',0,'2014-01-28 16:56:01',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','Thx Irena.\n\nNrupal\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Monday, January 27, 2014 10:04 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Jani, Nrupal\nSubject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Nrupal,\nWe definitely consider both these cases.\nAgree with you that we should aim to support both.\n\nBR,\nIrena\n\n\nFrom: Jani, Nrupal [mailto:nrupal.jani at intel.com]\nSent: Monday, January 27, 2014 11:17 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi,\n\nThere are two possibilities for the hybrid compute nodes\n\n-          In the first case, a compute node has two NICs,  one SRIOV NIC & the other NIC for the VirtIO\n\n-          In the 2nd case, Compute node has only one SRIOV NIC, where VFs are used for the VMs, either macvtap or direct assignment.  And the PF is used for the uplink to the linux bridge or OVS!!\n\nMy question to the team is whether we consider both of these deployments or not?\n\nThx,\n\nNrupal\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Monday, January 27, 2014 1:01 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Robert,\nPlease see inline\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 10:29 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Irena,\n\nI agree on your first comment.\n\nsee inline as well.\n\nthanks,\nRobert\n\nOn 1/27/14 10:54 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nMy comments inline\n\nRegards,\nIrena\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, January 27, 2014 5:05 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV\n\nHi Folks,\n\nIn today\'s meeting, we discussed a scheduler issue for SRIOV. The basic requirement is for coexistence of the following compute nodes in a cloud:\n      -- SRIOV only compute nodes\n      -- non-SRIOV only compute nodes\n      -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of a proper name, let\'s call them compute nodes with hybrid NICs support, or simply hybrid compute nodes.\n\nI\'m not sure if it\'s practical in having hybrid compute nodes in a real cloud. But it may be useful in the lab to bench mark the performance differences between SRIOV, non-SRIOV, and coexistence of both.\n[IrenaB]\nI would like to clarify a bit on the requirements you stated below.\nAs I see it, the hybrid compute nodes actually can be preferred in the real cloud, since one can define VM with one vNIC attached via SR-IOV virtual function while the other via some vSwitch.\nBut it definitely make sense to land VM with \'virtio\' vNICs only on the non-SRIOV compute node.\n\nMaybe there should be some sort of preference order of suitable nodes in scheduler choice, based on vnic types required for the VM.\n\nIn a cloud that supports SRIOV in some of the compute nodes, a request such as:\n\n     nova boot -flavor m1.large -image <image-uuid> --nic net-id=<net-uuid> vm\n\ndoesn\'t require a SRIOV port. However, it\'s possible for the nova scheduler to place it on a compute node that supports sriov port only. Since neutron plugin runs on the controller, port-create would succeed unless neutron knows the host doesn\'t support non-sriov port. But connectivity on the node would not be established since no agent is running on that host to establish such connectivity.\n[IrenaB] I\nHaving ML2 plugin as neutron backend, will fail to bind the port, in no agent is running on the Host\n\n[ROBERT] If a host supports SRIOV only, and there is an agent running on the host to support SRIOV, would binding succeed in ML2 plugin for the above \'nova boot\' request?\n[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will bind the port only if it supports vic_type and there is live agent on this host. So it should work\n\nOn a hybrid compute node, can we run multiple neutron L2 agents on a single host? It seems possible.\n\nIrena brought up the idea of using host aggregate. This requires creation of a non-SRIOV host aggregate, and use that in the above \'nova boot\' command. It should work.\n\nThe patch I had introduced a new constraint in the existing PCI passthrough filter.\n\nThe consensus seems to be having a better solution in a later release. And for now, people can either use host aggregate or resort to their own means.\n\nLet\'s keep the discussion going on this.\n\nThanks,\nRobert\n\n\n\n\n\nOn 1/24/14 4:50 PM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nHi Folks,\n\nBased on Thursday\'s discussion and a chat with Irena, I took the liberty to add a summary and discussion points for SRIOV on Monday and onwards. Check it out https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to update it. Let\'s try to finalize it next week. The goal is to determine the BPs that need to get approved, and to start coding.\n\nthanks,\nRobert\n\n\nOn 1/22/14 8:03 AM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nSounds great! Let\'s do it on Thursday.\n\n--Robert\n\nOn 1/22/14 12:46 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert, all,\nI would suggest not to delay the SR-IOV discussion to the next week.\nLet\'s try to cover the SRIOV side and especially the nova-neutron interaction points and interfaces this Thursday.\nOnce we have the interaction points well defined, we can run parallel patches to cover the full story.\n\nThanks a lot,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Wednesday, January 22, 2014 12:02 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV\n\nHi Folks,\n\nAs the debate about PCI flavor versus host aggregate goes on, I\'d like to move forward with the SRIOV side of things in the same time. I know that tomorrow\'s IRC will be focusing on the BP review, and it may well continue into Thursday. Therefore, let\'s start discussing SRIOV side of things on Monday.\n\nBasically, we need to work out the details on:\n        -- regardless it\'s PCI flavor or host aggregate or something else, how to use it to specify a SRIOV port.\n        -- new parameters for -nic\n        -- new parameters for neutron net-create/neutron port-create\n        -- interface between nova and neutron\n        -- nova side of work\n        -- neutron side of work\n\nWe should start coding ASAP.\n\nThanks,\nRobert\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/e2896860/attachment-0001.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E77882FD34D@MTLDAG02.mtl.com>',NULL),('<098ccf61.00001600.00000064@sawad-w7nb.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 01:47:18',-25200,'2013-06-26 08:47:18',NULL,'[openstack-dev] C# .NET SDK','Hello all,\n\nI investigated a few forums/lists before asking this here to this list, I\napologize if this question was already covered and I missed it somehow.\n\n \n\nWe are investigating an SDK for C# bindings to openstack.\n\n \n\n-          The one recommended by openstack.org is the Rackspace\nopenstack.net\nThis library is highly dependent on Rackspace, and does not work out of\nthe box with open flavors of openstack.\nI filed a question and a bug for them, I received only one helpful\nresponse, which recommended opening a bug on their github.\n\n\n\n-          I experimented on an SDK by cloudbase, it seems incomplete, and\nnot highly maintained missing functionality.\n\n \n\nThe objective: An SDK that would be not too generic, yet one which would\nallow connectivity to openstack and to Rackspace if possible.\n\n \n\nThanks in advance,\n\n \n\n__________________________________________________________\n\n <mailto:sawad at vmware.com> Sinan Awad | Manager, R&D | VMware\n\n <mailto:sawad at vmware.com> 16A \"G.M. Dimitrov\" Blvd, 7th floor, 1797\nSofia, BULGARIA\n\n <mailto:sawad at vmware.com> Office: +359 2 804 1306  Mobile: +359 888\n585254\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130626/0ccc4e1b/attachment.html>\n\n',NULL,NULL),('<098F2540-DC87-4287-87EF-88E54541B057@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 21:40:01',-28800,'2014-02-25 05:40:01',NULL,'[openstack-dev] [Mistral] Local vs. Scalable Engine','I agree with Winson\'s points. Inline.\n\nOn Feb 24, 2014, at 8:31 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n\n> \n> On 25 Feb 2014, at 07:12, W Chan <m4d.coder at gmail.com> wrote:\n> \n>> As I understand, the local engine runs the task immediately whereas the scalable engine sends it over the message queue to one or more executors.  \n> \n> Correct.\n\nNote: that \"local\" is confusing here, \"in process\" will reflect what it is doing better. \n\n> \n>> In what circumstances would we see a Mistral user using a local engine (other than testing) instead of the scalable engine?\n> \n> Yes, mostly testing we it could be used for demonstration purposes also or in the environments where installing RabbitMQ is not desirable.\n> \n>> If we are keeping the local engine, can we move the abstraction to the executor instead, having drivers for a local executor and remote executor?  The message flow from the engine to the executor would be consistent, it\'s just where the request will be processed.  \n> \n> I think I get the idea and it sounds good to me. We could really have executor in both cases but the transport from engine to executor can be different. Is that what you?re suggesting? And what do you call driver here?\n\n+1 to \"abstraction to the executor\", indeed the local and remote engines today differ only by how they invoke executor, e.g. transport / driver.\n\n> \n>> And since we are porting to oslo.messaging, there\'s already a fake driver that allows for an in process Queue for local execution.  The local executor can be a derivative of that fake driver for non-testing purposes.  And if we don\'t want to use an in process queue here to avoid the complexity, we can have the client side module of the executor determine whether to dispatch to a local executor vs. RPC call to a remote executor.\n> \n> Yes, that sounds interesting. Could you please write up some etherpad with details explaining your idea?\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<A04D8ECF-576E-48CF-81CE-23F27A26BECC@mirantis.com>',NULL),('<0995BA11-2ABC-41B7-AF4D-50BFF5513136@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-04 12:40:35',3600,'2014-11-04 11:40:35',NULL,'[OpenStack-docs] [training-guides] REMINDER meeting in the Docs POD\n	at 13:00','If this time has gotten away from a few of us, let me know and I can follow up with you later in the week. Some of us were discussing Thursday. Session details \n\nhttps://etherpad.openstack.org/p/docstopicsparissummit <https://etherpad.openstack.org/p/docstopicsparissummit>\n\n~ sean\n\n\n\n\n~ sean\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141104/5bdc0a55/attachment.html>\n\n',NULL,NULL),('<0996C955-8A92-4A87-9C46-A97D83190D9E@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 09:35:21',-28800,'2012-11-13 17:35:21',NULL,'[openstack-dev] [Openstack] Fwd: [keystone] Tokens representing\n authorization to projects/tenants in the Keystone V3 API','So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. \n\nRight now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they\'d need a different middleware there. Keystone as a service *doesn\'t* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user.\n\nAll that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. \n\n- joe\n\n\nOn Nov 13, 2012, at 9:17 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:\n> Hi Guang\n> \n> On 13/11/2012 16:14, Yee, Guang wrote:\n>> An unscoped token is basically implicitly scoped to Keystone service right?\n>> One should be able to use an unscoped token to reset his password, and ask\n>> Keystone for information pertaining to himself, such as what are his roles,\n>> what services/endpoints are available to him, and what are his tenants, etc.\n>> This is helpful for administration UIs such as MC.\n> \n> agreed\n> \n>> There\'s a blueprint to address the need to scope the token down to the\n>> service or endpoint level. Basically, service and endpoint isolation.\n> \n> I have read your blueprint and I have some comments/questions on it. How do you want these to be addressed? By email, or by edits to you blueprint?\n> \n> regards\n> \n> David\n> \n>> \n>> https://blueprints.launchpad.net/keystone/+spec/service-isolation-and-roles-\n>> delegation\n>> http://wiki.openstack.org/Keystone/Service-Isolation-And-Roles-Delegation\n>> \n>> It also addresses the intricacies of role delegation, which should be very\n>> beneficial for cloud services.\n>> \n>> \n>> \n>> Guang\n>> \n>> \n>> \n>> -----Original Message-----\n>> From: openstack-bounces+guang.yee=hp.com at lists.launchpad.net\n>> [mailto:openstack-bounces+guang.yee=hp.com at lists.launchpad.net] On Behalf Of\n>> David Chadwick\n>> Sent: Tuesday, November 13, 2012 7:32 AM\n>> To: Adam Young\n>> Cc: OpenStack Development Mailing List; openstack at lists.launchpad.net\n>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing\n>> authorization to projects/tenants in the Keystone V3 API\n>> \n>> Hi Adam\n>> \n>> you have pointed out an important difference between an unscoped token\n>> and a scoped one. The former can only be used with keystone, the latter\n>> with a cloud service. This also implies that a scoped token can only\n>> have the scope of a single service, and not multiple services. The user\n>> must swap the unscoped token for a set of scoped tokens if he wishes to\n>> access a set of cloud services.\n>> \n>> This model is clean and consistent.\n>> \n>> Concerning your attack scenario, then the best point of attack is either\n>> the client (steal his token(s)) or Keystone (get access to any service)\n>> \n>> regards\n>> \n>> David\n>> \n>> On 13/11/2012 14:38, Adam Young wrote:\n>>> On 11/10/2012 10:58 AM, David Chadwick wrote:\n>>>> I agree with the vast majority of what Jorge says below. The idea I\n>>>> would like to bounce around is that of the unscoped token.\n>>>> \n>>>> What does it mean conceptually? What is its purpose? Why do we need\n>>>> it? Why should a user be given an unscoped token to exchange at a\n>>>> later time for a scoped token?\n>>>> \n>>>> My view is as follows:\n>>>> i) a user is authenticated and identified, and from this, keystone can\n>>>> see that the user has access to a number of different tenants and\n>>>> services. Keystone creates an unscoped token to encapsulate this. Note\n>>>> that the unscoped token is scoped to the services/tenants available to\n>>>> this user, and consequently it is different for each identified user.\n>>>> Thus it does have some scope i.e. it cannot be swapped for access to\n>>>> any service by any tenant.\n>>>> ii) the user must choose which service/tenant he wishes to activate.\n>>>> This is in line with the principle of least privileges.\n>>>> iii) the user informs keystone which service(s) and tenant(s) he\n>>>> wishes to access and Keystone swaps the unscoped token for one that is\n>>>> scoped to the choice of the user.\n>>>> \n>>>> The issue then becomes, what is the allowable scope of a scoped token?\n>>>> Jorge below believes it should cover multiple\n>>>> services/endpoints/tenants. So one must then ask, what is the\n>>>> difference between the most widely scoped scoped-token and the\n>>>> unscoped token? Surely they will have the same scope won\'t they? In\n>>>> which case there is no need for both concepts.\n>>> \n>>> let\'s compare with Kerberos:  In my view an unscoped token is\n>>> comparaable with a ticket granting ticket:  it cannot be used with any\n>>> service other than the KDC, and it can only be used to get service\n>>> tickets. A service ticket can only be used with a specific service.  If\n>>> that service gets compromised, any tickets it has are useless for access\n>>> to other resources.\n>>> \n>>> \n>>> If an unscoped token can be used against a wide array of services, we\n>>> have just provided a path for an elevation of privileges attack. If I\n>>> know that a service consumes tokens which can be used on a wide number\n>>> of other services, I can target my attacks against that service in order\n>>> to get access everywhere.\n>>> \n>>> If we are going to provide this functionality, it should be turned off\n>>> by default.\n>>> \n>>>> \n>>>> Comments please\n>>>> \n>>>> regards\n>>>> \n>>>> David\n>>>> \n>>>> On 23/10/2012 06:25, Jorge Williams wrote:\n>>>>> Here\'s my view:\n>>>>> \n>>>>> On making the default token a configuration option:  Like the idea.\n>>>>>   Disabling the option by default.  That\'s fine too.\n>>>>> \n>>>>> On scoping a token to a specific endpoint:  That\'s fine, though I\n>>>>> believe that that\'s in the API today.  Currently, the way that we scope\n>>>>> tokens to endpoints is by validating against the service catalog. I\'m\n>>>>> not sure if the default middleware checks for this yet, but the Repose\n>>>>> middleware does.  If you try to use a token in an endpoint that\'s not in\n>>>>> the service catalog the request fails -- well, if the check is turned\n>>>>> on.\n>>>>> \n>>>>> Obviously, I\'d like the idea of scoping a single token to multiple\n>>>>> tenants / endpoints.\n>>>>> \n>>>>> I don\'t like the idea of calling tokens \"sloppy tokens\" -- it\'s\n>>>>> confusing.   All you have to say is that a token has a scope -- and the\n>>>>> scope of the token is the set of resources that the token can provide\n>>>>> access to.  You can limit the scope of a token to a tenant, to a\n>>>>> endpoint, to a set of endpoints or tenants etc -- what limits you place\n>>>>> on the scope of an individual token should be up to the operator.\n>>>>> \n>>>>> Keep in mind that as we start digging into delegation and fine grained\n>>>>> authorization (after Grizzly, I\'m sure), we\'ll end up with tokens that\n>>>>> have a scope of a subset of resources in a single or multiple tenants.\n>>>>>   So calling them sloppy now is just confusing.  Simply stating that a\n>>>>> token has a scope (as I\'ve defined above) should suffice.  This is part\n>>>>> of the reason why I\'ve never liked the term \"unscoped\" token, because an\n>>>>> unscoped token does have a scope. It just so happens that the scope of\n>>>>> that token is the resource that provides a list of available tenants.\n>>>>> \n>>>>> -jOrGe W.\n>>>>> \n>>>>> On Oct 22, 2012, at 9:57 PM, Adam Young wrote:\n>>>>> \n>>>>>> Are you guys +1 ing the original Idea, my suggestion to make it\n>>>>>> optional, the fact that I think we should call these sloppy tokens?\n>>>>>> \n>>>>>> On 10/22/2012 03:40 PM, Jorge Williams wrote:\n>>>>>>> +1 here too.\n>>>>>>> \n>>>>>>> At the end of the day, we\'d like the identity API to be flexible\n>>>>>>> enough to allow the token to be scoped in a manner that the deployer\n>>>>>>> sees fit.  What the keystone implementation does by default is a\n>>>>>>> different matter -- and disabling multiple tenant  scope by default\n>>>>>>> would be fine by me.\n>>>>>>> \n>>>>>>> -jOrGe W.\n>>>>>>> \n>>>>>>> \n>>>>>>> On Oct 21, 2012, at 11:10 AM, Joe Savak wrote:\n>>>>>>> \n>>>>>>>> +1. ;)\n>>>>>>>> \n>>>>>>>> So the issue is that the v2 API contract allows a token to be scoped\n>>>>>>>> to multiple tenants. For v3, I\'d like to have the same flexibility.\n>>>>>>>> I don\'t see security issues, as if a token were to be sniffed you\n>>>>>>>> can change the password of the account using it and use those creds\n>>>>>>>> to scope tokens to any tenant you wish.\n>>>>>> Scope should always be kept as limited as possible. Personally, I\n>>>>>> don\'t feel like limiting the tenant list makes much difference.  THe\n>>>>>> more I think about it, the real benefit comes from limiting the\n>>>>>> endpoints.\n>>>>>> \n>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> On Oct 20, 2012, at 21:07, \"Adam Young\" <ayoung at redhat.com\n>>>>>>>> <mailto:ayoung at redhat.com>> wrote:\n>>>>>>>> \n>>>>>>>>> On 10/20/2012 01:50 PM, heckj wrote:\n>>>>>>>>>> I sent this to the openstack-dev list, and thought I\'d double post\n>>>>>>>>>> this onto the openstack list at Launchpad for additional feedback.\n>>>>>>>>>> \n>>>>>>>>>> -joe\n>>>>>>>>>> \n>>>>>>>>>> Begin forwarded message:\n>>>>>>>>>>> *From: *heckj <heckj at mac.com <mailto:heckj at mac.com>>\n>>>>>>>>>>> *Subject: **[openstack-dev] [keystone] Tokens representing\n>>>>>>>>>>> authorization to projects/tenants in the Keystone V3 API*\n>>>>>>>>>>> *Date: *October 19, 2012 1:51:16 PM PDT\n>>>>>>>>>>> *To: *OpenStack Development Mailing List\n>>>>>>>>>>> <openstack-dev at lists.openstack.org\n>>>>>>>>>>> <mailto:openstack-dev at lists.openstack.org>>\n>>>>>>>>>>> *Reply-To: *OpenStack Development Mailing List\n>>>>>>>>>>> <openstack-dev at lists.openstack.org\n>>>>>>>>>>> <mailto:openstack-dev at lists.openstack.org>>\n>>>>>>>>>>> \n>>>>>>>>>>> The topic of what a token can or can\'t represent for the upcoming\n>>>>>>>>>>> V3 Keystone API  came up - and I wanted to share the conversation\n>>>>>>>>>>> a bit more broadly to get feedback.\n>>>>>>>>>>> \n>>>>>>>>>>> \n>>>>>>>>>>> A bit of history:\n>>>>>>>>>>> \n>>>>>>>>>>> In the V2 API, when you authenticated with just a username and\n>>>>>>>>>>> password, the token that was provided wasn\'t entirely clearly\n>>>>>>>>>>> defined. The reference implementation that Keystone used was to\n>>>>>>>>>>> create what\'s been called an \'unscoped\' token - which was\n>>>>>>>>>>> generally limited to only being able to get a list of possible\n>>>>>>>>>>> tenants/projects and the capability of getting a token specific\n>>>>>>>>>>> to a user & tenant/project (what\'s been called a \"scoped\" token)\n>>>>>>>>>>> \n>>>>>>>>>>> Likewise, the reference implementation of the rest of the\n>>>>>>>>>>> OpenStack projects all require a tenant information to be\n>>>>>>>>>>> included within the token as that token was the identity refernce\n>>>>>>>>>>> inforoamtion - and most OpenStack services were wanting to know\n>>>>>>>>>>> the tenant associated with the token for authorization/ownership\n>>>>>>>>>>> purposes.\n>>>>>>>>>>> \n>>>>>>>>>>> Apparently Rackspace\'s internal implementation provided a token\n>>>>>>>>>>> that was immediately valid for all possible tenants to which the\n>>>>>>>>>>> user was associated, and presumably their internal\n>>>>>>>>>>> implementations of openstack do whatever work is appropriate to\n>>>>>>>>>>> discern and provide that information to the various openstack\n>>>>>>>>>>> services.\n>>>>>>>>>>> \n>>>>>>>>>>> The quandary:\n>>>>>>>>>>> \n>>>>>>>>>>> In the V3 API, we started off with, and currently define the\n>>>>>>>>>>> token as being specifically mandated to a single tenant, with a\n>>>>>>>>>>> new requirement that if you authorize with just a username and\n>>>>>>>>>>> password, a \"default tenant\" is used. If for some reason you have\n>>>>>>>>>>> no tenant associated with the userid, the authorization is to be\n>>>>>>>>>>> refused. If the user is associated with more than one\n>>>>>>>>>>> tenant/project, it\'s possible to use the token to get a list of\n>>>>>>>>>>> other tenants/projects and request a new token specific to one of\n>>>>>>>>>>> those other tenant/projects, but the implementation is expected\n>>>>>>>>>>> to respect and provide a default.\n>>>>>>>>> \n>>>>>>>>> I would like to make \"default tenant\" a configuration option, and\n>>>>>>>>> have it disabled by default.  Unscoped tokens are a very useful\n>>>>>>>>> construct.  In the case where the user has many roles across a\n>>>>>>>>> multitude of projects, it is possible to create huge tokens.  I\n>>>>>>>>> would prefer unscoped tokens to remain, and to be associated with\n>>>>>>>>> no tenant.  The only operation Keystone should provide with them is\n>>>>>>>>> the ability to enumerate tenants, so something like Horizon can\n>>>>>>>>> then request an appropriately scoped token.\n>>>>>>>>> \n>>>>>>>>> I am also in favor of limiting the scope of a token to an\n>>>>>>>>> endpoint.  Even more-so than tenants, scoping a token to an end\n>>>>>>>>> point increases security.  Once a token has been scoped to an\n>>>>>>>>> endpoint, it can only be used on that endpoint.  If an endpoint\n>>>>>>>>> gets compromised, the damage is limited to resources that endpoint\n>>>>>>>>> already has access to.  This, in conjunction with pre-auths, could\n>>>>>>>>> allow a user to perform an action with a minimum of risk in a\n>>>>>>>>> public cloud environment.\n>>>>>>>>> \n>>>>>>>>> \n>>>>>>>>>>> \n>>>>>>>>>>> A few folks from Rackspace touched on this at the very tail end\n>>>>>>>>>>> of the V3 API review session on Thursday, bringing up that they\n>>>>>>>>>>> had an issue with the token being scoped to a single tenant.\n>>>>>>>>>>> Since this has significant implications to both security and a\n>>>>>>>>>>> potential user experience flow, I wanted to bring the issue up\n>>>>>>>>>>> across the broader community for discussion.\n>>>>>>>>>>> \n>>>>>>>>>>> The request outstanding:\n>>>>>>>>>>> \n>>>>>>>>>>> Rackspace folks are requesting that the token not be limited to a\n>>>>>>>>>>> single tenant/project, but instead provides a list of potential\n>>>>>>>>>>> tenants against which the token should be considered valid.\n>>>>>>>>> I would like the world to know that we are affectionately calling\n>>>>>>>>> such tokens \"sloppy tokens\" and Joe Savak has adopted the nickname\n>>>>>>>>> of \"Sloppy Joe\" for championing them.  Allowing it as an option is\n>>>>>>>>> fine, but I would not recommend that this become the norm, or that\n>>>>>>>>> we enable this feature by default.\n>>>>>>>>>>> \n>>>>>>>>>>> Brief (maybe shoddy) analysis:\n>>>>>>>>>>> \n>>>>>>>>>>> This would potentially imply changes to what gets passed as a\n>>>>>>>>>>> part of the authentication reference in the context passed using\n>>>>>>>>>>> auth_token middleware - multiple tenants possible instead of the\n>>>>>>>>>>> currently expected single value - so using that as information\n>>>>>>>>>>> for create() style mechanisms would need to provide some\n>>>>>>>>>>> alternative means of clearly defining what tenant/project should\n>>>>>>>>>>> be owner. It  would provide anyone compromising that particular\n>>>>>>>>>>> token with a broader spectrum of impact on a replay style attack.\n>>>>>>>>>>> Likewise, the impact of tenant enable/disable or role changes\n>>>>>>>>>>> would necessarily mean a broader invalidation of all tokens\n>>>>>>>>>>> associated with the user.\n>>>>>>>>>>> \n>>>>>>>>>>> On the flip side, it has the potential to remove the\n>>>>>>>>>>> token-reissuance that currently exists when switching contexts\n>>>>>>>>>>> from one project to another (primarily through horizon or other\n>>>>>>>>>>> client/UI/dashboard mechanisms that cache the token).\n>>>>>>>>>>> \n>>>>>>>>>>> Feedback and Input desired!\n>>>>>>>>>>> \n>>>>>>>>>>> -joe\n>>>>>>>>>>> \n>>>>>>>>>>> \n>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>> OpenStack-dev mailing list\n>>>>>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>>>>> \n>>>>>>>>>> \n>>>>>>>>>> \n>>>>>>>>>> _______________________________________________\n>>>>>>>>>> Mailing list:https://launchpad.net/~openstack\n>>>>>>>>>> Post to     :openstack at lists.launchpad.net\n>>>>>>>>>> Unsubscribe :https://launchpad.net/~openstack\n>>>>>>>>>> More help   :https://help.launchpad.net/ListHelp\n>>>>>>>>> \n>>>>>>>>> _______________________________________________\n>>>>>>>>> Mailing list: https://launchpad.net/~openstack\n>>>>>>>>> <https://launchpad.net/%7Eopenstack>\n>>>>>>>>> Post to     : openstack at lists.launchpad.net\n>>>>>>>>> <mailto:openstack at lists.launchpad.net>\n>>>>>>>>> Unsubscribe : https://launchpad.net/~openstack\n>>>>>>>>> <https://launchpad.net/%7Eopenstack>\n>>>>>>>>> More help   : https://help.launchpad.net/ListHelp\n>>>>>>>> _______________________________________________\n>>>>>>>> Mailing list: https://launchpad.net/~openstack\n>>>>>>>> <https://launchpad.net/%7Eopenstack>\n>>>>>>>> Post to     : openstack at lists.launchpad.net\n>>>>>>>> <mailto:openstack at lists.launchpad.net>\n>>>>>>>> Unsubscribe : https://launchpad.net/~openstack\n>>>>>>>> <https://launchpad.net/%7Eopenstack>\n>>>>>>>> More help   : https://help.launchpad.net/ListHelp\n>>>>>>> \n>>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>> \n>> \n>> _______________________________________________\n>> Mailing list: https://launchpad.net/~openstack\n>> Post to     : openstack at lists.launchpad.net\n>> Unsubscribe : https://launchpad.net/~openstack\n>> More help   : https://help.launchpad.net/ListHelp\n>> \n> \n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n\n\n\n','<50A280A6.5090602@kent.ac.uk>',NULL),('<09A6B878-946C-4FF0-89C2-93D4C1FFE458@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-25 09:59:00',-14400,'2013-07-25 13:59:00',NULL,'[openstack-dev] Usage of mox through out the Openstack project.','\nOn Jul 25, 2013, at 4:01 AM, Julien Danjou <julien at danjou.info> wrote:\n\n> On Wed, Jul 24 2013, Russell Bryant wrote:\n> \n>> A practical approach would probably be:\n>> \n>> 1) Prefer mock for new tests.\n>> \n>> 2) Use suggestion #2 above to mitigate the Python 3 concern.\n>> \n>> 3) Convert tests to mock over time, opportunistically, as tests are\n>> being updated anyway.  (Or if someone *really* wants to take this on as\n>> a project ...)\n> \n> Agreed. I will -1 every new patch coming with mox inside. :-)\n> \n> And I\'ll probably do some conversion for Oslo anyway.\n\nThe Neutron project has been enforcing this approach for about a year now.  We\'re down to 8 files that still rely on Mox.\n\nmark\n\n\n\n\n','<87r4en83vf.fsf@dex.adm.naquadah.org>',NULL),('<09A9A399-BC7B-41A4-90D6-1523F8F40203@mattei.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-17 09:06:46',-25200,'2013-09-17 16:06:46',NULL,'[Openstack] Translation Push - get the dashboard in your\n	language by Sep 24 - Join Openstack Kannada Language Dashboard Group','Please contact me offline so I can get the info sources etc to help out\n\nCiao\n\nInviato da iPad (?)\n\nIl giorno Sep 17, 2013, alle ore 8:41, <raghavendra.lad at accenture.com> ha scritto:\n\n> Awesome.. \n> \n> Remo,  Thank you.  Italian language team now has another Translation member.\n> \n> \n> Regards,\n> Raghavendra Lad\n>  \n> -----Original message-----\n> From: Remo Mattei\n> Sent:  17/09/2013, 7:29  PM\n> To: Lad, Raghavendra\n> Cc: \"<ilyaalekseyev at acm.org>\" <ilyaalekseyev at acm.org>; \"<maksimov at gmail.com>\" <maksimov at gmail.com>; \"<akoppad at gmail.com>\" <akoppad at gmail.com>; openstack at lists.openstack.org\n> Subject: Re: [Openstack] Translation Push - get the dashboard in your language by Sep 24 - Join Openstack Kannada Language Dashboard Gro\n> Hello all I will be happy to support the Italian dashboard if needed. \n> Remo\n> \n> Inviato da iPad (?)\n> \n> Il giorno Sep 17, 2013, alle ore 0:14, <raghavendra.lad at accenture.com> ha scritto:\n> \n>>  \n>> Hi All,\n>>  \n>> Welcome Translators, Reviewers, Freelancers and Openstack enthusiasts to the Kannada (IN) Language dashboard translation work.\n>> You can also CC us on the translation group mailing list\n>> kanndabalaga at transifex.com\n>>  \n>> ?Bandhugale Kannada Bashe Ulisi Belesalu ondu sadavakasha..? Banni Kannadakke Jai.. yendu Kai Yathona Kalpavruksha vagisona?\n>>  \n>>  \n>> The link to join the Kannada Language team is provided below:\n>>  \n>> https://www.transifex.com/projects/p/kannada-dashboard-yallarigu/language/kn/\n>>  \n>> Regards,\n>> Raghavendra Lad\n>>  \n>> From: Ilya Alekseyev [mailto:ilyaalekseyev at acm.org] \n>> Sent: Thursday, September 12, 2013 6:37 PM\n>> To: Stas Maksimov\n>> Cc: openstack at lists.openstack.org\n>> Subject: Re: [Openstack] Translation Push - get the dashboard in your language by Sep 24\n>>  \n>> Working for it in Russian.\n>>  \n>> Kind regards,\n>> Ilya Alekseyev\n>>  \n>> 2013/9/12 Stas Maksimov <maksimov at gmail.com>\n>> In for Russian.\n>>  \n>> \n>> On 12 September 2013 13:36, Marcelo Dieder <marcelodieder at gmail.com> wrote:\n>> Hello Tom,\n>> \n>> Translating to Brazilian Portuguese....\n>> \n>> Marcelo Dieder\n>>  \n>> \n>> On 09/12/2013 05:16 AM, Tom Fifield wrote:\n>> Do you write Spanish, Italian, Russian, German or Dutch? \n>> \n>> How about Portuguese? Indonesian? Arabic? Hindi? \n>> \n>> Actually, if you can write in any language other than English, you have the ability to help get the OpenStack Dashboard into your language. \n>> \n>> Find your language on: \n>> \n>>  https://www.transifex.com/projects/p/horizon/ \n>> \n>> and join the team. \n>> \n>> \n>> It\'s actually a lot of fun, all done through an easy web interface. \n>> \n>> If we can get 100% completion in your language by September 24th, your text will be included in the next release of OpenStack for thousands around the world to see. \n>> \n>> So, why not get your friends together and make it happen? :) \n>> \n>> \n>> Thanks, \n>> \n>> from your friendly Internationalisation Team \n>> https://wiki.openstack.org/wiki/I18nTeam \n>> \n>> _______________________________________________ \n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>> Post to     : openstack at lists.openstack.org \n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>  \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>>  \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>>  \n>> \n>> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the  original. Any other use of the e-mail by you is prohibited.\n>> \n>> Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n>> \n>> ______________________________________________________________________________________\n>> \n>> www.accenture.com\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> \n>> !DSPAM:2,523805ea118594987512804!\n> !DSPAM:2,52387917203192003330191!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130917/87186b7a/attachment.html>\n\n','<gYyNnHn6Lj22@hB1T8Jsc>',NULL),('<09B2503B-3679-46C1-82F8-1D06718AADC6@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 11:09:33',-28800,'2014-03-03 19:09:33',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n	maximum from 64 to 255','\nOn Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:\n>> Having done some work with MySQL (specifically around similar data\n>> sets) and discussing the changes with some former coworkers (MySQL\n>> experts) I am inclined to believe the move from varchar  to binary\n>> absolutely would increase performance like this.\n>> \n>> \n>> However, I would like to get some real benchmarks around it and if it\n>> really makes a difference we should get a smart \"UUID\" type into the\n>> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this\n>> conversation. Should be split off from the keystone one at hand - I\n>> don\'t want valuable information / discussions to get lost.\n> \n> No disagreement on either point. However, this should be done after the\n> standardization to a UUID user_id in Keystone, as a separate performance\n> improvement patch. Agree?\n> \n> Best,\n> -jay\n\n-1\n\nThe expectation in other projects has been that project_ids and user_ids are opaque strings. I need to see more clear benefit to enforcing stricter typing on these, because I think it might break a lot of things.\n\nVish\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140303/87807dee/attachment.pgp>\n\n','<1393858111.2742.0.camel@sleepy>',NULL),('<09BB99DA-27DF-4441-8BCE-2CDCF68417ED@codestud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-23 00:50:11',-25200,'2014-04-23 07:50:11',NULL,'[Openstack] Instance Name in DB','In the DB, that should be the display_name column of instances table.\n\n- Chris\n\n> On Apr 22, 2014, at 11:56 PM, Reza Bakhshayeshi <reza.b2008 at gmail.com> wrote:\n> \n> Hi,\n> \n> How I can find the \"instance_name\" in database?\n> (it appears in the result of nova show)\n> I have checked the instances table in nova database but I couldn\'t find it.\n> \n> Thanks,\n> Reza\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140423/2b4da1af/attachment.html>\n\n','<CAMGoRG37ytAn9MwJCHs2s0nn4=PRtMbF2MDXJtOeBDeDwmky_Q@mail.gmail.com>',NULL),('<09C00313-8BD0-4814-8B8B-9DD18BF47AF7@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-02 09:24:32',10800,'2014-08-02 06:24:32',NULL,'[openstack-dev] [Trove] Backup/restore namespace config move\n	has leftovers','\n\nSent from my iPhone\n\n> On Aug 2, 2014, at 8:04, Mark Kirkwood <mark.kirkwood at catalyst.net.nz> wrote:\n> \n>> On 01/08/14 21:35, Denis Makogon wrote:\n>> \n>> I\'d suggest to file a bug\n>> report and fix given issue.\n> \n> Done.\n> \n> https://bugs.launchpad.net/trove/+bug/1351545\n> \n> \n> I also took the opportunity to check if all the currently defined datastores had backup/restore_namespace set - they didn\'t, so I noted that too (I\'m guessing they now actually *need* to have something set to avoid breakage)...\n> \n\nMark, we don\'t have to add backup/restore namespace options to datastores that does\'t support backup/restore feature.\nYou should take a look how backup procedure is being executed at Trove-API service site, see \nhttps://github.com/openstack/trove/blob/master/trove/backup/models.py\n(Method called _validate_can_perform_action)\n\nIf you\'ll have another questions, feel free to catch me up at IRC (denis_makogon).\n\nBest regards,\nDenis Makogon\n\n> regards\n> \n> Mark\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53DC7167.5040507@catalyst.net.nz>',NULL),('<09C7442D-B5FC-4448-A80A-B0DF3381FB60@hp.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 02:53:46',0,'2014-10-02 02:53:46',NULL,'[openstack-dev] [neutron] [IPv6] [ironic] New API format\n	for	extra_dhcp_opts','As a \'heads up\', adding ironic to the thread since they are a \'key\' consumer of this api.\n\n\nOn Oct 1, 2014, at 3:15 AM, Xu Han Peng <pengxuhan at gmail.com<mailto:pengxuhan at gmail.com>> wrote:\n\nip_version sounds great.\n\nCurrently the opt-names are written into the configuration file of dnsmasq directly. So I would say yes, they are coming from dnsmasq definitions.\n\nIt will make more sense when ip_version is missing or null, the option apply to both since we could have only ipv6 or ipv4 address on the port. However, the validation of opt-value should rule out the ones which are not suitable for the current address. For example, an IPv6 dns server should not be specified for IPv4 address port, etc...\n\nXu Han\n\nOn 09/30/2014 08:41 PM, Robert Li (baoli) wrote:\nXu Han,\n\nThat looks good to me. To keep it consistent with existing CLI, we should use ip-version instead of ?version?. It seems to be identical to prefixing the option_name with v4 or v6, though.\n\nJust to clarify, are the available opt-names coming from dnsmasq definitions?\n\nWith regard to the default, your suggestion \"version is optional (no version means version=4).\" seems to be different from Mark?s:\nI?m -1 for both options because neither is properly backwards compatible.  Instead we should add an optional 3rd value to the dictionary: ?version?.  The version key would be used to make the option only apply to either version 4 or 6.  If the key is missing or null, then the option would apply to both.\n\nThanks,\nRobert\n\nOn 9/30/14, 1:46 AM, \"Xu Han Peng\" <pengxuhan at gmail.com<mailto:pengxuhan at gmail.com>> wrote:\n\nRobert,\n\nI think the CLI will look something like based on Mark\'s suggestion:\n\nneutron port-create extra_dhcp_opts opt_name=<dhcp_option_name>,opt_value=<value>,version=4(or 6) <network>\n\nThis extra_dhcp_opts can be repeated and version is optional (no version means version=4).\n\nXu Han\n\nOn 09/29/2014 08:51 PM, Robert Li (baoli) wrote:\nHi Xu Han,\n\nMy question is how the CLI user interface would look like to distinguish between v4 and v6 dhcp options?\n\nThanks,\nRobert\n\nOn 9/28/14, 10:29 PM, \"Xu Han Peng\" <pengxuhan at gmail.com<mailto:pengxuhan at gmail.com>> wrote:\n\nMark\'s suggestion works for me as well. If no one objects, I am going to start the implementation.\n\nThanks,\nXu Han\n\nOn 09/27/2014 01:05 AM, Mark McClain wrote:\n\nOn Sep 26, 2014, at 2:39 AM, Xu Han Peng <pengxuhan at gmail.com<mailto:pengxuhan at gmail.com>> wrote:\n\nCurrently the extra_dhcp_opts has the following API interface on a port:\n\n{\n    \"port\":\n    {\n        \"extra_dhcp_opts\": [\n            {\"opt_value\": \"testfile.1\",\"opt_name\": \"bootfile-name\"},\n            {\"opt_value\": \"123.123.123.123\", \"opt_name\": \"tftp-server\"},\n            {\"opt_value\": \"123.123.123.45\", \"opt_name\": \"server-ip-address\"}\n        ],\n        ....\n     }\n}\n\nDuring the development of DHCPv6 function for IPv6 subnets, we found this format doesn\'t work anymore because an port can have both IPv4 and IPv6 address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. ( https://bugs.launchpad.net/neutron/+bug/1356383)\n\nHere are some thoughts about the new format:\n\nOption1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so we can distinguish opts for v4 or v6 by parsing the opt_name. For backward compatibility, no prefix means IPv4 dhcp opt.\n\n        \"extra_dhcp_opts\": [\n            {\"opt_value\": \"testfile.1\",\"opt_name\": \"bootfile-name\"},\n            {\"opt_value\": \"123.123.123.123\", \"opt_name\": \"v4:tftp-server\"},\n            {\"opt_value\": \"[2001:0200:feed:7ac0::1]\", \"opt_name\": \"v6:dns-server\"}\n        ]\n\nOption2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward compatibility, both old format and new format are acceptable, but old format means IPv4 dhcp opts.\n\n        \"extra_dhcp_opts\": {\n             \"ipv4\": [\n                    {\"opt_value\": \"testfile.1\",\"opt_name\": \"bootfile-name\"},\n                    {\"opt_value\": \"123.123.123.123\", \"opt_name\": \"tftp-server\"},\n             ],\n             \"ipv6\": [\n                    {\"opt_value\": \"[2001:0200:feed:7ac0::1]\", \"opt_name\": \"dns-server\"}\n             ]\n        }\n\nThe pro of Option1 is there is no need to change API structure but only need to add validation and parsing to opt_name. The con of Option1 is that user need to input prefix for every opt_name which can be error prone. The pro of Option2 is that it\'s clearer than Option1. The con is that we need to check two formats for backward compatibility.\n\nWe discussed this in IPv6 sub-team meeting and we think Option2 is preferred. Can I also get community\'s feedback on which one is preferred or any other comments?\n\n\nI?m -1 for both options because neither is properly backwards compatible.  Instead we should add an optional 3rd value to the dictionary: ?version?.  The version key would be used to make the option only apply to either version 4 or 6.  If the key is missing or null, then the option would apply to both.\n\nmark\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<542BD45B.70007@gmail.com>',NULL),('<09D1A365-9899-4EA3-9290-894F248E8073@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-15 15:18:42',7200,'2013-07-15 13:18:42',NULL,'[openstack-dev] Tempest testing for optional middlewares','Thank you Sean.\n\nIn case someone checks this in the future, it\'s worth mentioning that any\nnew field added to the conf file has to be declared in tempest/config.py \nfirst.\n\nJoe\n\nOn Jul 12, 2013, at 8:26 PM, Sean Dague <sean at dague.net> wrote:\n\n> On 07/12/2013 02:15 PM, Joe Hakim Rahme wrote:\n>> Hello everyone,\n>> \n>> I\'m addressing this email to the dev list because I couldn\'t find a way\n>> to get in touch with the testing team. Hopefully someone here will have\n>> the answer to my question or can point me to the correct people to ask.\n>> \n>> I am writing Tempest tests that cover the behavior of some optional\n>> Swift middlewares (precisely account_quota and container_quota).\n>> It occurs to me that these middlewares are optional and may not be\n>>  present in every Swift installation. In this case, I\'d like Tempest to skip\n>> this test rather than fail it.\n>> \n>> What\'s the correct way of detecting the presence of the middleware\n>> before launching the test?\n> \n> In the tempest.conf you should create a variable for \"foo_available\", defaulting to false. Then if someone wants to test it we set it to true. Then you can decorate your tests (or class) to skip if that variable is false.\n> \n> This is an example of it in the code - https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_server_actions.py#L150\n> \n> 	-Sean\n> \n> -- \n> Sean Dague\n> http://dague.net\n\n\n\n','<51E04A55.9040100@dague.net>',NULL),('<09D42CCF-E896-40CC-B326-75730CC6A479@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-18 13:04:05',-25200,'2012-08-18 20:04:05',NULL,'[openstack-dev] [openstack-common] Add auth_token.py from\n keystone middleware to openstack-common','Hi Yaguang,\n\nI agree that it looks like a close fit for pushing into openstack-common, but I don\'t have a solid sense of what the boundary is between stuff that\'s somewhat common and stuff that\'s project specific. auth_token is in one of those grey areas - it\'s used by glance, quantum, nova (and keystone), but not swift - swift extended that basic setup to include some additional context and such detail specific to swift. That auth-token-middleware-for-swift code is now in the swift repository (https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py)\n\nThe other part of this is how we do updates - right now a change to Keystone (such as adding PKI support for signed tokens) means updating in a single location (keystone), where if we moved it to OpenStack common, we\'d need to update it in more than one location. If it were really locked down and not changing, then I think maybe it would make sense to shift in there, but right now (especially with advancements in PKI/signed tokens) and looking forward to the V3 API set, I don\'t know that it makes as much sense. My intuition is telling me that it\'s not sufficiently unchanging and \"common\" enough to move into common, although getting it there is actually something of a goal.\n\nMark - how and where have you been drawing the line on what and when to shift code into OpenStack common?\n\n- joe\n\nOn Aug 18, 2012, at 12:45 AM, heut2008 <heut2008 at gmail.com> wrote:\n> auth_token.py is a middleware of keystone  used by\n> nova-api,glance-api, and quantum to authenticate request token. now,\n> we have to install\n> keystone to make all openstack api services which use keystone as auth\n> strategy.but is not necessary to install keystone,only auth_token.py\n> is\n> needed,(nova-api may alse need  ec2_token.py) ,so I suggest we put\n> keystone/middleware/auth_token.py into openstack-common/middleware.\n> \n> \n> \n> Yaguang\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAPP2CaVNLZ2L4ZkTyrC-BV1fiM5DHg1BNS37Lko1NjrW4RD49g@mail.gmail.com>',NULL),('<09DB3A7D-E1AE-42E2-A539-CB11F951F420@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 13:01:14',-25200,'2013-05-15 20:01:14',NULL,'[openstack-dev] [Swift] meeting minutes','Meeting minutes from today\'s meeting\n\nhttp://eavesdrop.openstack.org/meetings/swift/2013/swift.2013-05-15-19.01.html\n\n--John\n\n\n\n\n\n',NULL,NULL),('<09dbc36e147549e3aee89f0fb1a5f70e@BN1PR05MB044.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-07 23:11:48',0,'2013-06-07 23:11:48',NULL,'[openstack-dev] [Horizon] HACKING.rst and import standards','> A topic not discussed is module-level import vs object-level import.\n> While other core projects only use module-level import, Horizon uses both\n> and object-level imports are widely used like below.\n\nYep, I had left that one out on purpose for a few reasons:\n\n1. I (personally) find this to be a rule based more on dogma than actual improvement to readability/code quality. It often results in having to alias modules to shorter names, etc. to try and keep line lengths down, or having to type the name of module before a function every time you want to use it. I understand the arguments in favor of it, but it doesn\'t do much for me.\n\n2. It would require a tremendous amount of rewriting (far more so than any of the fixes I *would* like to see turned on) for no practical gain.\n\n3.  It\'s mostly a matter of taste. To that point, PEP8 indicates that both are completely valid and acceptable styles. Strictly enforcing it where it\'s actively making things less readable or less convenient is precisely the warning of \"A Foolish Consistency is the Hobgoblin of Little Minds.\"\n\n4.  Alphabetical one-import-per-line importing fixes most of the practical issues that module-level-only importing is supposed to fix, and most modern editors make it trivial to see where something was defined so the \"know where things are defined\" argument doesn\'t hold much weight.\n\nIf the rest of the contributor-base for Horizon strongly prefers that we enforce module-level-only importing then I am willing to listen, but without strong reason to do so I think we have much more fruitful things we could be working on.\n\nThat\'s mostly my personal two cents, and should not be taken as a commandment or decision upon the project.\n\nAll the best,\n\n    - Gabriel\n\n\n','<m2mwr24d0d.wl%motoki@da.jp.nec.com>',NULL),('<09E6A0F5-71E4-4B7A-83D1-5584C91AD58B@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 03:23:52',0,'2014-05-08 03:23:52',NULL,'[openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert\n implementation for LBaaS and VPN','    I thought the requirement was from the need to ensure the backend was secure. IE people would throw a fit if they find out your storing keys in sqllite or MySQL. Wasn\'t the purpose to find \"A Secure repository\"?\n\nOn May 7, 2014, at 10:38 AM, Zang MingJie <zealot0630 at gmail.com> wrote:\n\n> +1 to implement a modular framework where user can choose whether to\n> use barbican or sqldb\n> \n> On Fri, May 2, 2014 at 4:28 AM, John Wood <john.wood at rackspace.com> wrote:\n>> Hello Samuel,\n>> \n>> Just noting that the link below shows current-state Barbican. We are in the\n>> process of designing SSL certificate support for Barbican via blueprints\n>> such as this one:\n>> https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates\n>> We intend to discuss this feature in Atlanta to enable coding in earnest for\n>> Juno.\n>> \n>> The Container resource is intended to capture/store the final certificate\n>> details.\n>> \n>> Thanks,\n>> John\n>> \n>> \n>> ________________________________\n>> From: Samuel Bercovici [SamuelB at Radware.com]\n>> Sent: Thursday, May 01, 2014 12:50 PM\n>> To: OpenStack Development Mailing List (not for usage questions);\n>> os.vbvs at gmail.com\n>> Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert\n>> implementation for LBaaS and VPN\n>> \n>> Hi Vijay,\n>> \n>> \n>> \n>> I have looked at the Barbican APIs ?\n>> https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface\n>> \n>> I was no able to see a ?native? API that will accept an SSL certificate\n>> (private key, public key, CSR, etc.) and will store it.\n>> \n>> We can either store the whole certificate as a single file as a secret or\n>> use a container and store all the certificate parts as secrets.\n>> \n>> \n>> \n>> I think that having LBaaS reference Certificates as IDs using some service\n>> is the right way to go so this might be achived by either:\n>> \n>> 1.       Adding to Barbican and API to store / generate certificates\n>> \n>> 2.       Create a new ?module? that might start by being hosted in neutron\n>> or keystone that will allow to manage certificates and will use Barbican\n>> behind the scenes to store them.\n>> \n>> 3.       Decide on a container structure to use in Babican but implement the\n>> way to access and arrange it as a neutron library\n>> \n>> \n>> \n>> Was any decision made on how to proceed?\n>> \n>> \n>> \n>> Regards,\n>> \n>>                -Sam.\n>> \n>> \n>> \n>> \n>> \n>> \n>> \n>> \n>> \n>> From: Vijay B [mailto:os.vbvs at gmail.com]\n>> Sent: Wednesday, April 30, 2014 3:24 AM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for\n>> LBaaS and VPN\n>> \n>> \n>> \n>> Hi,\n>> \n>> \n>> \n>> It looks like there are areas of common effort in multiple efforts that are\n>> proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in\n>> neutron.\n>> \n>> \n>> \n>> Two relevant efforts are listed below:\n>> \n>> \n>> \n>> \n>> \n>> https://review.openstack.org/#/c/74031/\n>> (https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)\n>> \n>> \n>> \n>> https://review.openstack.org/#/c/58897/\n>> (https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)\n>> \n>> \n>> \n>> \n>> \n>> \n>> \n>> Both VPN and LBaaS will use SSL certificates and keys, and this makes it\n>> better to implement SSL entities as first class citizens in the OS world.\n>> So, three points need to be discussed here:\n>> \n>> \n>> \n>> 1. The VPN SSL implementation above is putting the SSL cert content in a\n>> mapping table, instead of maintaining certs separately and referencing them\n>> using IDs. The LBaaS implementation stores certificates in a separate table,\n>> but implements the necessary extensions and logic under LBaaS. We propose\n>> that both these implementations move away from this and refer to SSL\n>> entities using IDs, and that the SSL entities themselves are implemented as\n>> their own resources, serviced either by a core plugin or a new SSL plugin\n>> (assuming neutron; please also see point 3 below).\n>> \n>> \n>> \n>> 2. The actual data store where the certs and keys are stored should be\n>> configurable at least globally, such that the SSL plugin code will\n>> singularly refer to that store alone when working with the SSL entities. The\n>> data store candidates currently are Barbican and a sql db. Each should have\n>> a separate backend driver, along with the required config values. If further\n>> evaluation of Barbican shows that it fits all SSL needs, we should make it a\n>> priority over a sqldb driver.\n>> \n>> \n>> \n>> 3. Where should the primary entries for the SSL entities be stored? While\n>> the actual certs themselves will reside on Barbican or SQLdb, the entities\n>> themselves are currently being implemented in Neutron since they are being\n>> used/referenced there. However, we feel that implementing them in keystone\n>> would be most appropriate. We could also follow a federated model where a\n>> subset of keys can reside on another service such as Neutron. We are fine\n>> with starting an initial implementation in neutron, in a modular manner, and\n>> move it later to keystone.\n>> \n>> \n>> \n>> \n>> \n>> Please provide your inputs on this.\n>> \n>> \n>> \n>> \n>> \n>> Thanks,\n>> \n>> Regards,\n>> \n>> Vijay\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAOrge3pUkk8WdF0oJ1p-R-LXvw45R-xBgdNHvDcWyC0VrxnaLA@mail.gmail.com>',NULL),('<09F9D927-1DD8-4D60-AFBF-32E7ABB7513A@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-16 14:06:03',-18000,'2015-01-16 19:06:03',NULL,'[openstack-dev] [horizon] static files handling, bower/','\n> On Jan 16, 2015, at 12:55 PM, Matthew Farina <matt at mattfarina.com> wrote:\n> \n> Doug, there still is one open question. Distributing JavaScript libraries via system packages is unusual. Because of that, most of the JavaScript libraries used by horizon don\'t have existing packages. Who will create and maintain the packages for these JavaScript libraries for production? For example, most of the libraries aren\'t available as debian or ubuntu packages.\n> \n> Updating a JavaScript dependency, such as angular, would mean each of the system packages needs to be updated as well as the Horizon project. Would would this process look like with packages on different systems needing updates?\n> \n> Using bower for development and system packages for production doesn\'t appear to be ready to start using.\n\nWe have, so far, relied on the distributors to build packages in whatever way works for their tools. What is it about JavaScript libraries that makes packaging them ?unusual??\n\nIf we?re going to continue to rely on distributors to handle the packaging, the next step is to get some of the distribution packagers to chime in on what else might be useful to make their jobs easier.  We?ve collaborated in the past by adding features or writing some of our own tools (that?s part of what led to pbr being created for python packages, for example). This thread is fairly long, so you might want to start a new one with an appropriate subject line to attract the right input.\n\nWas there a spec for this work? If not, that would be useful to have.\n\n> \n> On Fri, Jan 16, 2015 at 12:09 PM, Doug Hellmann <doug at doughellmann.com <mailto:doug at doughellmann.com>> wrote:\n> \n> > On Jan 16, 2015, at 11:33 AM, Drew Fisher <drew.fisher at oracle.com <mailto:drew.fisher at oracle.com>> wrote:\n> >\n> > On 1/16/15 9:08 AM, Doug Hellmann wrote:\n> >> We are, and as this conversation has veered off in a destructive\n> >> direction, I think we should back up and look at the compromise Radomir\n> >> posted [1] to see if that solves the original technical problem we all have.\n> >>\n> >> Does having the requirements specified in a JSON file, without requiring\n> >> a specific build tool to install the files, solve the packaging,\n> >> testing, and deployment issue on platforms where node.js isn?t supported\n> >> natively right now?\n> >\n> > For Solaris, yes.  We can make that work.  Thanks, Radomir for the\n> > suggestion.\n> \n> Great!\n> \n> Doug\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request at lists.openstack.org/?subject:unsubscribe>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150116/846b5913/attachment.html>\n\n','<CABgOrS=C7nXWAtZs4z0eXdvB88Nni=wB72Zo9PPX5UvXn2sr9g@mail.gmail.com>',NULL),('<0A0DD858-EF82-453F-BDCE-667B6D74B940@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-26 21:41:03',0,'2013-10-26 21:41:03',NULL,'[openstack-dev] [nova] Thoughs please on how to\n	address	a	problem with mutliple deletes leading to\n	a	nova-compute	thread pool problem','There is at least 1 such effort being discussed in cinder, other projects I can not say. I am hoping to gain more traction there as taskflow[1] I think can provide (or help provide) a foundation to help here. Taskflow itself has a well defined state machine [2]. But it\'s in the end up to the projects themselves to see the issue and have a desire to move to a more formalized and managed model...\n\n1. https://wiki.openstack.org/wiki/TaskFlow\n2. https://wiki.openstack.org/wiki/TaskFlow/States_of_Task_and_Flow\n\nSent from my really tiny device...\n\nOn Oct 26, 2013, at 12:22 PM, \"Abhishek Lahiri\" <aviostack at gmail.com<mailto:aviostack at gmail.com>> wrote:\n\nThis is a bit off topic , but in general it seems to me that the state transitions as you said are not clearly defined for many openstack components. Is there any effort underway to define these? As the software gets bigger and bigger this will help both developers and operators.\n\nThanks & Regards\nAbhishek Lahiri\n\nOn Oct 26, 2013, at 9:52 AM, Joshua Harlow <harlowja at yahoo-inc.com<mailto:harlowja at yahoo-inc.com>> wrote:\n\nPotentially,\n\nAlthough I think the lack of formalization and visibility (and the ability to easily change its transitions) into the state machine is at this point causing part of this pain.\n\nIf the state machine was well defined (and adjustable - to a degree...) then you could imagine only allowing delete transitions from the powered off state while another deployer may prefer a more \"experimental\" allow delete transition at any time (with associated side effects).\n\nWithout the underlying state machine being in a more formalized state it\'s hard to do either in a manageable (and recoverable & resumable...) manner IMHO.\n\nSent from my really tiny device...\n\nOn Oct 26, 2013, at 9:12 AM, \"Abhishek Lahiri\" <aviostack at gmail.com<mailto:aviostack at gmail.com>> wrote:\n\nDeletes should only be allowed when the vm is in a power off state. This will allow consistent state transition.\n\nThanks\nAl\n\n\nOn Oct 26, 2013, at 8:55 AM, Joshua Harlow <harlowja at yahoo-inc.com<mailto:harlowja at yahoo-inc.com>> wrote:\n\nI think I will try to have a unconference at the HK summit about ideas the cinder developers (and the taskflow developers, since it\'s not a concept that is unique /applicable to just cinder) are having about said state machine (and it\'s potential usage).\n\nSo look out for that, be interesting to have some nova folks involved there also :-)\n\nSent from my really tiny device...\n\nOn Oct 26, 2013, at 3:14 AM, \"Alex Glikson\" <GLIKSON at il.ibm.com<mailto:GLIKSON at il.ibm.com>> wrote:\n\n+1\n\nRegards,\nAlex\n\n\nJoshua Harlow <harlowja at yahoo-inc.com<mailto:harlowja at yahoo-inc.com>> wrote on 26/10/2013 09:29:03 AM:\n>\n> An idea that others and I are having for a similar use case in\n> cinder (or it appears to be similar).\n>\n> If there was a well defined state machine/s in nova with well\n> defined and managed transitions between states then it seems like\n> this state machine could resume on failure as well as be interrupted\n> when a \"dueling\" or preemptable operation arrives (a delete while\n> being created for example). This way not only would it be very clear\n> the set of states and transitions but it would also be clear how\n> preemption occurs (and under what cases).\n>\n> Right now in nova there is a distributed and ad-hoc state machine\n> which if it was more formalized it could inherit some if the\n> described useful capabilities. It would also be much more resilient\n> to these types of locking problems that u described.\n>\n> IMHO that\'s the only way these types of problems will be fully be\n> fixed, not by more queues or more periodic tasks, but by solidifying\n> & formalizing the state machines that compose the work nova does.\n>\n> Sent from my really tiny device...\n>\n> > On Oct 25, 2013, at 3:52 AM, \"Day, Phil\" <philip.day at hp.com<mailto:philip.day at hp.com>> wrote:\n> >\n> > Hi Folks,\n> >\n> > We\'re very occasionally seeing problems where a thread processing\n> a create hangs (and we\'ve seen when taking to Cinder and Glance).\n> Whilst those issues need to be hunted down in their own rights, they\n> do show up what seems to me to be a weakness in the processing of\n> delete requests that I\'d like to get some feedback on.\n> >\n> > Delete is the one operation that is allowed regardless of the\n> Instance state (since it\'s a one-way operation, and users should\n> always be able to free up their quota).   However when we get a\n> create thread hung in one of these states, the delete requests when\n> they hit the manager will also block as they are synchronized on the\n> uuid.   Because the user making the delete request doesn\'t see\n> anything happen they tend to submit more delete requests.   The\n> Service is still up, so these go to the computer manager as well,\n> and eventually all of the threads will be waiting for the lock, and\n> the compute manager will stop consuming new messages.\n> >\n> > The problem isn\'t limited to deletes - although in most cases the\n> change of state in the API means that you have to keep making\n> different calls to get past the state checker logic to do it with an\n> instance stuck in another state.   Users also seem to be more\n> impatient with deletes, as they are trying to free up quota for other things.\n> >\n> > So while I know that we should never get a thread into a hung\n> state into the first place, I was wondering about one of the\n> following approaches to address just the delete case:\n> >\n> > i) Change the delete call on the manager so it doesn\'t wait for\n> the uuid lock.  Deletes should be coded so that they work regardless\n> of the state of the VM, and other actions should be able to cope\n> with a delete being performed from under them.  There is of course\n> no guarantee that the delete itself won\'t block as well.\n> >\n> > ii) Record in the API server that a delete has been started (maybe\n> enough to use the task state being set to DELETEING in the API if\n> we\'re sure this doesn\'t get cleared), and add a periodic task in the\n> compute manager to check for and delete instances that are in a\n> \"DELETING\" state for more than some timeout. Then the API, knowing\n> that the delete will be processes eventually can just no-op any\n> further delete requests.\n> >\n> > iii) Add some hook into the ServiceGroup API so that the timer\n> could depend on getting a free thread from the compute manager pool\n> (ie run some no-op task) - so that of there are no free threads then\n> the service becomes down. That would (eventually) stop the scheduler\n> from sending new requests to it, and make deleted be processed in\n> the API server but won\'t of course help with commands for other\n> instances on the same host.\n> >\n> > iv) Move away from having a general topic and thread pool for all\n> requests, and start a listener on an instance specific topic for\n> each running instance on a host (leaving the general topic and pool\n> just for creates and other non-instance calls like the hypervisor\n> API).   Then a blocked task would only affect request for a specificinstance.\n> >\n> > I\'m tending towards ii) as a simple and pragmatic solution in the\n> near term, although I like both iii) and iv) as being both generally\n> good enhancments - but iv) in particular feels like a pretty seismic change.\n> >\n> > Thoughts please,\n> >\n> > Phil\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131026/12bdd139/attachment.html>\n\n','<1685E8A3-EB46-4070-BF4A-0BF0302BDC5B@gmail.com>',NULL),('<0A1BF6C3-0E80-4062-AC72-59A008327593@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 13:52:22',-25200,'2014-03-19 20:52:22',NULL,'[openstack-dev] [openstack][Mistral] Adding new core reviewers','+1 for Nikolay - he\'s indeed the most involved in all aspect.\nand yes I am up to doing it. \n\nDZ.\n\nOn Mar 19, 2014, at 4:35 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n\n> Team,\n> \n> So far I?ve been just the only one core member of the team. I started feeling lonely :) Since the project team and the project itself has now grown (thanks to StackStorm and Intel) I think it?s time to think about extending the core team.\n> \n> I would propose:\n> Nikolay Makhotkin (nmakhotkin at launchpad). He\'s been working on the project since almost the very beginning and made significant contribution (design, reviews, code).\n> Dmitri Zimine (i-dz at launchpad). Dmitri joined the project about 2 months ago. Since then he?s made a series of important high-quality commits, a lot of valuable reviews and, IMO most importantly, he has a solid vision of the project in general (requirements, use cases, comparison to other technologies) and has a pro-active viewpoint in all our discussions.\n> \n> Thoughts?\n> \n> Renat Akhmerov\n> @ Mirantis Inc.\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140319/963c6ad5/attachment.html>\n\n','<2D020060-6601-4D65-980C-6BD96664C9DF@mirantis.com>',NULL),('<0a2124b55e504769b2ac1c03c204c959@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-11 08:43:19',0,'2013-12-11 08:43:19',NULL,'[Openstack] [FWaaS] Doubts with FWaaS','Yes..\nI have controller + network + compute node in a single machine.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\nFrom: ??? [mailto:guolongcang.work at gmail.com]\nSent: Wednesday, December 11, 2013 2:08 PM\nTo: Somanchi Trinath-B39208\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] [FWaaS] Doubts with FWaaS\n\nall-in-one deploy ?  qr-{xxx} device is created on the network node .\n\n2013/12/11 trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>>\nHi-\n\nI have the following chains in the iptables.\n\nroot at havana:~# iptables -L -n -v\nChain INPUT (policy ACCEPT 6021 packets, 474K bytes)\npkts bytes target     prot opt in     out     source               destination\n 5921  465K nova-api-INPUT  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            udp dpt:53\n    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            tcp dpt:53\n    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            udp dpt:67\n    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            tcp dpt:67\n\nChain FORWARD (policy ACCEPT 0 packets, 0 bytes)\npkts bytes target     prot opt in     out     source               destination\n    0     0 nova-filter-top  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n    0     0 nova-api-FORWARD  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0<http://0.0.0.0/0>            192.168.122.0/24<http://192.168.122.0/24>     ctstate RELATED,ESTABLISHED\n    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24<http://192.168.122.0/24>     0.0.0.0/0<http://0.0.0.0/0>\n    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            reject-with icmp-port-unreachable\n    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>            reject-with icmp-port-unreachable\n\nChain OUTPUT (policy ACCEPT 6746 packets, 462K bytes)\npkts bytes target     prot opt in     out     source               destination\n 6614  452K nova-filter-top  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n 6614  452K nova-api-OUTPUT  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n\nChain nova-api-FORWARD (1 references)\npkts bytes target     prot opt in     out     source               destination\n\nChain nova-api-INPUT (1 references)\npkts bytes target     prot opt in     out     source               destination\n    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            10.10.10.100         tcp dpt:8775\n\nChain nova-api-OUTPUT (1 references)\npkts bytes target     prot opt in     out     source               destination\n\nChain nova-api-local (1 references)\npkts bytes target     prot opt in     out     source               destination\n\nChain nova-filter-top (2 references)\npkts bytes target     prot opt in     out     source               destination\n 6614  452K nova-api-local  all  --  *      *       0.0.0.0/0<http://0.0.0.0/0>            0.0.0.0/0<http://0.0.0.0/0>\n\n\nI find none with the names suggested below. Am I missing any of the configurations required.\n\nKindly help me in this regard.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> | extn: 4048\n\nFrom: ??? [mailto:guolongcang.work at gmail.com<mailto:guolongcang.work at gmail.com>]\nSent: Wednesday, December 11, 2013 1:46 PM\nTo: Somanchi Trinath-B39208\nCc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] [FWaaS] Doubts with FWaaS\n\nFWaaS is implemented through iptables on qr-{xxx} device , one inbound chain named like neutron-l3-agent-iv{xxx} and one outbound chain named like  neutron-l3-agent-ov{xxx}  .\n\nYou can check the qr-{xxx} device\'s iptables rules.\n\n2013/12/11 trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>>\nHi stackers-\n\nI have configured FWaas with Neutron.\n\nAlso, I have created a simple firewall rule, added the same to a policy and created a firewall with this policy from CLI\n\nThe firewall is in ERROR state.\n\nThe rules and the policies were added to the DB.\n\nHow do I debug to find the error. Also, will these rules be added to the iptables?\n\nHelp be troubleshoot and understand the same.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> | extn: 4048\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131211/52400a15/attachment.html>\n\n','<CACkq0KJknjkk=aeAkk3k2QUjxbVUPkLfcgVArbV0NFn9cQa0aQ@mail.gmail.com>',NULL),('<0a23fc4f364c52f294f8700df3d77d76.squirrel@webmail.andrew.cmu.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-23 19:44:41',-18000,'2014-11-24 00:44:41',NULL,'[openstack-dev] Integrating Barbican with KMIP','Hello\n\nI am new with openstack and I would like to use a KMIP server for key\nstorage and key retieval. I have lloking for different documentation but I\nhave had difficulties to change the default behavior of barbican.\n\nRight now I am modifying the barbican-api.conf file.\nI am replacing enabled_secretstore_plugins = store_crypto by\nenabled_secretstore_plugins = kmip_secret_store.\nI also modified the secret_store.py to change DEFAULT_PLUGINS =\n[\'store_crypto\'] to DEFAULT_PLUGINS = [\'kmip_secret_store\']\n\nHowever it looks barbican is not calling the KMIPServer and is doing it\nlocally.\nIf I want to use the kmip_secret_store implementation, what could be\nmissing in my aproach?\n\nThanks in advance any help\n\nKind regards\nMarcelo\n\n\n\n',NULL,NULL),('<0a29efdcd49f4e439418af1642d6fb0b@31L-EX02.eurogiciel.fr>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-02-04 15:51:21',0,'2015-02-04 15:51:21',NULL,'[OpenStack-Infra] Code Review needs another verified','Hi all\n\nWe committed some change on a newly created project and the review (https://review.openstack.org/#/c/147182/\n)  needs another +1 verified, Jenkins gave +1 but how give another +1 ?\nIt seems that others projects do not need a +2 verified to pass to the next step  (example here : https://review.openstack.org/#/c/140517/)\nDoes it missing some configuration somewhere, here are our Here are the project-config files :\nhttps://review.openstack.org/#/c/131989/\n\nThanks a lot for your response\nRegards\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150204/f6935b14/attachment.html>\n\n',NULL,NULL),('<0A32AE9F-51CE-44DC-84DC-0CAAD58614E7@cisco.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-11-05 03:36:53',0,'2013-11-05 03:36:53',NULL,'[OpenStack-Infra] Gerrit Service Account Please','Ok, so it does appear that cisco_infra is dead and can be removed.\n\nI\'ll try the other account now, and let you know, thanks!\n\nRobert\n\nSent from a device\n\n> On Nov 5, 2013, at 11:31 AM, \"Jeremy Stanley\" <fungi at yuggoth.org> wrote:\n> \n>> On 2013-10-31 17:40:31 +0000 (+0000), Robert Starmer (starmer) wrote:\n>> I haven\'t found anyone who claims ownership to the cisco_infra\n>> account.\n> \n> I have a lead for you... according to my IRC client logs,\n> dendrobates (Rick Clark) requested it back in March of this year.\n> Hope that helps track it down, and please let us know whether it\'s\n> still in use if you\'re able to find out.\n> \n>> Can we set up the cisco-openstack-ci user, and at least until I\n>> can confirm 100% that there\'s nothing using the other address,\n>> leave the cisco_infra user around?\n> \n> Done. Try it out and let us know if you need anything else for this.\n> \n>> Can we also change the cisco_infra user e-mail to\n>> cisco-openstack-infra at external.cisco.com, so that any messages\n>> actually go somewhere rather than bouncing?\n> \n> Done as well.\n> -- \n> Jeremy Stanley\n\n\n','<20131105033137.GV2304@yuggoth.org>',NULL),('<0a41c4f7e72b5319662d7a2eb009c53c@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-07 21:32:27',-25200,'2014-10-08 04:32:27',NULL,'[Openstack] Tapping physical interfaces',' \n\nThat\'s the issue most probably. You cannot have br-eth1:br-eth1\n\n\nWill not work. \n\nOn 2014-10-05 22:41, Irena Berezovsky wrote: \n\n> Hi\nDon, \n> \n> Seems that there is a problem at neutron side, that ML2\nrefuses to bind the port. \n> \n> Can you please share the error you get\nat neutron server? \n> \n> I am not sure, but seems that neutron ml2\nconfiguration is not accurate. \n> \n> With commands you share, I think\nyou should change it as following: \n> \n> [ovs]\n> bridge_mappings =\nphysnet1:br-ex, br-eth1:br-eth1 \n> \n> The convention is <physical\nnetwork label>: <bridge>\n> \n> Hope it helps, \n> \n> Irena \n> \n> FROM: Don\nWaterloo [mailto:don.waterloo at gmail.com] \n> SENT: Monday, October 06,\n2014 5:37 AM\n> TO: openstack at lists.openstack.org\n> SUBJECT: Re:\n[Openstack] Tapping physical interfaces \n> \n> the vxlan part is\ndefinitely working, its the \'flat\' part that i\'ve just added which is\nnot.\n> \n> and, more specifically, its the ability to attach a nova\ninstance to it. I\'m not sure what i can do for screen shots, the error\nis the kind of generic:\n> \n> [req-d7df11f2-0a13-49e6-acf4-69fff926519f\n6f5b7388bbce42f7a53a2af62fb43f06 4ef0f0caa0884594b3fd5d39efc892dc]\n[instance: fba1b229-5e5e-429d-8e4f-fa6fd7898d21] Error from last host:\namazing.sandvine.rocks (node amazing.sandvine.rocks): [u\'Traceback (most\nrecent call last):n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1329,\nin _build_instancen set_access_ip=set_access_ip)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 393, in\ndecorated_functionn return function(self, context, *args, **kwargs)n\',\nu\' File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line\n1741, in _spawnn LOG.exception(_(\'Instance failed to spawn\'),\ninstance=instance)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py\",\nline 68, in __exit__n six.reraise(self.type_, self.value, self.tb)n\', u\'\nFile \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line\n1738, in _spawnn block_device_info)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n2284, in spawnn write_to_disk=True)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n3478, in to_xmln disk_info, rescue, block_device_info)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n3292, in get_guest_confign flavor)n\', u\' File\n\"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384,\nin get_confign _(\"Unexpected vif_type=%s\") % vif_type)n\',\nu\'NovaException: Unexpected vif_type=binding_failedn\'] \n> \n> the\n\'unexpected vif_type\' covers a wide variety of problems. I get this if i\nadd boot with a port-id on the new flat network, or if i boot with the\nnet-id of the new flat network. \n> \n> On 5 October 2014 21:49, Don\nWaterloo <don.waterloo at gmail.com> wrote: \n> \n> I have a system which is\nhappily using vxlan type driver on icehouse\n> on ml2 / ovs.\n> \n> I would\nnow like to take on of the physical interfaces (eth1) and make\n> it\navailable in a \'tap\' to a specific instance. Imagine running\n> \'snort\'\nhere.\n> \n> So i added the \'type_driver\' flat:\n> [ml2]\n> type_drivers =\nvxlan,flat,local\n> tenant_network_types = vxlan\n> mechanism_drivers =\nopenvswitch\n> \n> I added the bridge_mapping in ovs (this i\'m not sure of\ngiven the\n> tunnel_type=vxlan?)\n> [ovs]\n> tenant_network_type = vxlan\n>\ntunnel_type = vxlan\n> tunnel_id_ranges = 1:1000\n> integration_bridge =\nbr-int\n> tunnel_bridge = br-tun\n> local_ip = 172.16.100.2\n>\nbridge_mappings = physnet1:br-ex,eth1:br-eth1,eth3:br-eth3\n>\nenable_tunneling=True\n> \n> I ran\n> ovs-vsctl add-br br-eth1\n> ovs-vsctl\nadd-port br-eth1 eth1\n> \n> and I ran:\n> neutron net-create --shared\n--provider:network_type=flat\n> --provider:physical_network=br-eth1\neth1\n> \n> so far so good.\n> But i cannot get an instance to bind to this\nnetwork. I\'ve tried\n> manually creating a port and using --nic port-id=,\ni\'ve tried letting\n> it add it. But i get Unexpected\nvif_type=binding_failed no matter what\n> i do.\n> \n> In nova.conf I\nhave\n>\nlibvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver\n>\n\n> and i have port security disable fwiw.\n> \n> Do someone have a recipe\nthey want to share for this? Obviously this\n> works best on an\n\'all-in-one\' which is what I have. Is someone else\n> out there having an\ninstance directly bound to a physical port via a\n> bridge? \n> \n>\n!DSPAM:1,54322e75229429685119039!\n> \n>\n_______________________________________________\n> Mailing list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n> Post\nto : openstack at lists.openstack.org\n> Unsubscribe :\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n> \n>\n!DSPAM:1,54322e75229429685119039!\n\n \n\nLinks:\n------\n[1]\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141007/2ca49bac/attachment.html>\n\n','<270a847aea0642d8a3bee9a610d814f6@AMSPR05MB406.eurprd05.prod.outlook.com>',NULL),('<0A43146B-8A43-4413-8234-4062DE786E8E@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 08:06:42',-18000,'2014-03-04 13:06:42',NULL,'[openstack-dev] Neutron: Need help with tox failure in VPN code','Bo,\n\nI did that change, and it passes when I run neutron.tests.unit.services.vpn, but not when I run full tox or neutron.tetss.unit.services.  I still get failures (either error code 10 or test fails with no info).\n\nIrene,\n\nAny thoughts on why the driver is not loading (even with the mod that Bo suggests)?\n\nNachi,\n\nI just tried run_tests.sh and it fails to run the test (haven\'t used that in a very long time, so not sure I\'m running it correctly). Do I need any special args, when running that? I tried \'./run_tests.sh -f -V -P\' but it ran 0 tests.\n\n\nAll,\n\nThe bottom line here is that I can\'t seem to get the loading of service driver from neutron.conf, irrespective of the blueprint change set. If I use a hard coded driver (as is on master branch and used in the latest patch for 74144), all the tests work. But for this blueprint we need to be able to load the service driver (so that the blueprint driver can be loaded). The issue is unrelated to the blueprint functionality, as shown by the latest patch and by previous versions where I had the full service type framework implementation. It seems like there is some problem with this partial application of STF to load the service driver.\n\nI took the (working) 74144 patch and made the changes below to load the service plugin from neutron.conf, and see tox failures. I\'ve also patched this into the master branch, and I see the same issue!  IOW, there is something wrong with the method I\'m using to setup the service driver at least with respect to the current test suite.\n\ndiff --git a/neutron/services/vpn/plugin.py b/neutron/services/vpn/plugin.py\nindex 5d818a3..41cbff0 100644\n--- a/neutron/services/vpn/plugin.py\n+++ b/neutron/services/vpn/plugin.py\n@@ -18,11 +18,9 @@\n #\n # @author: Swaminathan Vasudevan, Hewlett-Packard\n \n-# from neutron.db import servicetype_db as st_db\n from neutron.db.vpn import vpn_db\n-# from neutron.plugins.common import constants\n-# from neutron.services import service_base\n-from neutron.services.vpn.service_drivers import ipsec as ipsec_driver\n+from neutron.plugins.common import constants\n+from neutron.services import service_base\n \n \n class VPNPlugin(vpn_db.VPNPluginDb):\n@@ -41,12 +39,10 @@ class VPNDriverPlugin(VPNPlugin, vpn_db.VPNPluginRpcDbMixin):\n     #TODO(nati) handle ikepolicy and ipsecpolicy update usecase\n     def __init__(self):\n         super(VPNDriverPlugin, self).__init__()\n-        self.ipsec_driver = ipsec_driver.IPsecVPNDriver(self)\n-        # Currently, if the following code is used, there are UT failures\n-#         self.service_type_manager = st_db.ServiceTypeManager.get_instance()\n-#         drivers, default_provider = service_base.load_drivers(\n-#             constants.VPN, self)\n-#         self.ipsec_driver = drivers[default_provider]\n+        # Dynamically load the current service driver\n+        drivers, default_provider = service_base.load_drivers(\n+            constants.VPN, self)\n+        self.ipsec_driver = drivers[default_provider]\n \n     def _get_driver_for_vpnservice(self, vpnservice):\n         return self.ipsec_driver\ndiff --git a/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py b/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py\nindex 8c25d7e..9531938 100644\n--- a/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py\n+++ b/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py\n@@ -17,6 +17,7 @@\n import contextlib\n \n import mock\n+from oslo.config import cfg\n \n from neutron.common import constants\n from neutron import context\n@@ -44,6 +45,12 @@ class TestVPNDriverPlugin(test_db_vpnaas.TestVpnaas,\n         self.driver = mock.Mock()\n         self.driver.service_type = ipsec_driver.IPSEC\n         driver_cls.return_value = self.driver\n+        vpnaas_provider = (p_constants.VPN +\n+                           \':vpnaas:neutron.services.vpn.\'\n+                           \'service_drivers.ipsec.IPsecVPNDriver:default\')\n+        cfg.CONF.set_override(\'service_provider\',\n+                              [vpnaas_provider],\n+                              \'service_providers\')\n         super(TestVPNDriverPlugin, self).setUp(\n             vpnaas_plugin=VPN_DRIVER_CLASS)\n\n\nAny advise?\n\n\nPCM (Paul Michali)\n\nMAIL          pcm at cisco.com\nIRC            pcm_  (irc.freenode.net)\nTW            @pmichali\nGPG key    4525ECC253E31A83\nFingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\nOn Mar 4, 2014, at 1:31 AM, Bo Lin <linb at vmware.com> wrote:\n\n> I don\'t know whether i got your point. But try to modify /neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py like the following, the error would be fixed:\n> --- a/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py\n> +++ b/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py\n> @@ -17,6 +17,7 @@\n> import contextlib\n> \n> import mock\n> +from oslo.config import cfg\n> \n> from neutron.common import constants\n> from neutron import context\n> @@ -44,6 +45,11 @@ class TestVPNDriverPlugin(test_db_vpnaas.TestVpnaas,\n> self.driver = mock.Mock()\n> self.driver.service_type = ipsec_driver.IPSEC\n> driver_cls.return_value = self.driver\n> + vpnaas_provider = (p_constants.VPN +\n> + \':vpnaas:neutron.services.vpn.\'\n> + \'service_drivers.ipsec.IPsecVPNDriver:default\' )\n> + cfg.CONF.set_override(\'service_provider\',\n> + [vpnaas_provider], \'service_providers\')\n> super(TestVPNDriverPlugin, self).setUp(\n> vpnaas_plugin=VPN_DRIVER_CLASS)\n> \n> \n> \n> From: \"Paul Michali\" <pcm at cisco.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, March 4, 2014 1:28:48 PM\n> Subject: [openstack-dev] Neutron: Need help with tox failure in VPN code\n> \n> Hi,\n> \n> I\'m stuck and can use some guidance here?please!\n> \n> I have a change set out for review that used the VPN Service Type Framework ( https://review.openstack.org/74144). Everything worked fine, passed Jenkins, etc.\n> \n> Found out that the STF won\'t make it to I-3, so I removed the dependency from my change set and tried to modify the plugin.py file to use some STF logic (like LBaaS uses) to load the desired service driver that is specified as the default. Adjusted the code to no longer use provider info.\n> \n> Well, in doing so, tox fails, and unfortunately there little info on the failure. This can be seen by running a subset of the tests, where 2 fail:\n> \n> tox -e py27 -v -- neutron.tests.unit.services.vpn\n> \n> only the name of a failing test case for one, and a mention of return code 10 on another and no other info on the failure reason. I didn\'t see this on a full tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running the above subset of the suite (thanks!).\n> \n> \n> I\'ve narrow it down a bit, but have no idea why it fails?\n> \n> One, it seems to be some interaction between test_vpnaas_driver_plugin.py and the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either one of the service driver tests cases, and it will still fail with the other one (so even the reference code fails).\n> \n> Two, if I change plugin.py to set self.driver to the reference device driver (as is done in the latest patch set) it works fine with all test cases.\n> \n> Three, it seems to be a test only issue, because I can run devstack with the login I have in plugin.py, currently commented out in __init__(), and successfully load either the reference or cisco service driver, by changing neutron.conf.\n> \n> It seems like I\'m doing something wrong in the loading of the service driver, or using this implementation, is somehow interacting with the tests.\n> \n> If anyone has ideas on what is wrong, or a better way to load the service driver, please let me know. I was thinking I could read and parse neutron.conf manually and then load the service driver, but there must be a better way!\n> \n> Thanks!\n> \n> PCM (Paul Michali)\n> \n> MAIL          pcm at cisco.com\n> IRC            pcm_  (irc.freenode.net)\n> TW            @pmichali\n> GPG key    4525ECC253E31A83\n> Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=J3ghWIVLPZdVsutjofb71dKYtoj4XxhrER%2FD8VzKRX0%3D%0A&s=09cf53ed99065938661b61453a717d77ba3b1ec069c48e356b358d472d3b526a\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/aa9cc509/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 841 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/aa9cc509/attachment.pgp>\n\n','<2067356572.47502322.1393914710876.JavaMail.root@vmware.com>',NULL),('<0A4465F5-B0F8-4B36-8234-478D9863E890@rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-19 14:45:05',0,'2013-12-19 14:45:05',NULL,'[Openstack] [DevStack] Using create-stack-user.sh','Hey Sean,\n\nThanks for sharing this.\n\nOn Dec 19, 2013, at 5:41 AM, Sean Dague wrote:\n\n> The crux being that devstack is really intended to be started from a\n> non-priv user. There is nothing special about that user, you just add it\n> and put it in you sudoers group.\n> \n> useradd -m -G sudo -s /bin/bash -p \'biguglyhashpassword value\' stack\n> \n> Does this correctly on Ubuntu on a Rackspace cloud instance.\n> \n> I suspect part of the collision of expectations is the Rackspace public\n> cloud isn\'t setting up the default user, but instead the root user.\n> Which is an oddity for Ubuntu images. I\'ve been writing some local\n> automation around this recently, so been running into that.\n\nI\'d be interested in this \"local automation\" if your open sourcing it or blogging about it.\n\nI wrote mine up at http://blog.phymata.com/2013/12/18/devstack-havana-on-the-rackspace-cloud/\n\nIt\'s geared towards newbies without a lot of automation skills so I keep everything manual. It\'d be easy enough to automate though.\n\nCheers,\nEverett\n\n','<52B2DB4C.4060904@dague.net>',NULL),('<0A466BD5-4FBE-483C-BD93-E3C9CAD91297@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 19:29:08',14400,'2014-05-22 15:29:08',NULL,'[openstack-dev] [Mistral] Cleaning up configuration settings','I tend to disagree with the whole idea. Not sure 100% though yet. Could you please explain the point of scattering configuration all over the code? In my opinion, we?re mixing different application concerns. With the current approach I always know where to look at in order to find all my configuration option definitions (types, descriptions etc.) but with this refactoring it seems to be a tricky task.\n\nThoughts? What benefits of doing that?\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 16 May 2014, at 21:32, Dmitri Zimine <dz at stackstorm.com> wrote:\n\n> +1 for breaking down the configuration by modules. \n> \n> Not sure about names for configuration group. Do you mean just using the same group name? or more? \n> \n> IMO groups are project specific; it doesn?t always make sense to use the same group name in the context of different projects. Our requirement is 1) auto-generate mistral.conf.example from the config.py and 2) sections make sense in the product context.\n> \n> For example: how do we deal with rpc_backend and transport_url for oslo messaging? Should we do something like CONF.import(_transport_opts, ?oslo.messaging.transport?, ?transport?)? And use it by passing the group, not entire contfig, like:\n> \n> 	transport = messaging.get_transport(cfg.messaging.CONF)\n> instead of\n> 	transport = messaging.get_transport(cfg.CONF)\n> \n> DZ> \n> \n> \n> On May 16, 2014, at 12:46 PM, W Chan <m4d.coder at gmail.com> wrote:\n> \n>> Regarding config opts for keystone, the keystoneclient middleware already registers the opts at https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L325 under a keystone_authtoken group in the config file.  Currently, Mistral registers the opts again at https://github.com/stackforge/mistral/blob/master/mistral/config.py#L108 under a different configuration group.  Should we remove the duplicate from Mistral and refactor the reference to keystone configurations to the keystone_authtoken group?  This seems more consistent.\n>> \n>> \n>> On Thu, May 15, 2014 at 1:13 PM, W Chan <m4d.coder at gmail.com> wrote:\n>> Currently, the various configurations are registered in ./mistral/config.py.  The configurations are registered when mistral.config is referenced.  Given the way the code is written, PEP8 throws referenced but not used error if mistral.config is referenced but not called in the module.  In various use cases, this is avoided by using importutils to import mistral.config (i.e. https://github.com/stackforge/mistral/blob/master/mistral/tests/unit/engine/test_transport.py#L34).  I want to break down registration code in ./mistral/config.py into separate functions for api, engine, db, etc and move the registration closer to the module where the configuration is needed.  Any objections?\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140522/f9de66c8/attachment.html>\n\n','<C89A7E79-17F8-42E6-993D-2FE6B458A78B@stackstorm.com>',NULL),('<0a4e01cef2d4$72abe6e0$5803b4a0$@gmail.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-12-06 17:42:30',-18000,'2013-12-06 22:42:30',NULL,'[openstack-hpc] FW: Internet2 + HPC','> I am a Ph.D student at university of florida with research interest in \n> HPC and multi-core systems. I am wondering how I can explore more \n> about openstack in the area of high-performance computing in order to \n> possibly kick start research.\n\n-----Original Message-----\nFrom: Stefano Maffulli [mailto:stefano at openstack.org] \nSent: Friday, December 06, 2013 5:38 PM\nTo: Dave Ojika\nSubject: Re: Internet2 + HPC\n\nHi Dave,\n\nyou wrote to the owner of the list. I\'d suggest you to write to the list itself: openstack-hpc at lists.openstack.org\n\nCheers,\nstef\n\nOn Fri 06 Dec 2013 12:24:09 AM PST, Dave Ojika wrote:\n> I am a Ph.D student at university of florida with research interest in \n> HPC and multi-core systems. I am wondering how I can explore more \n> about openstack in the area of high-performance computing in order to \n> possibly kick start research in this area for my independent study \n> after I discuss with my advisor. thank you\n\n--\nAsk and answer questions on https://ask.openstack.org\n\n\n\n','<52A251E1.8030206@openstack.org>',NULL),('<0a5301cde1ac$40a0d8c0$c1e28a40$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-24 11:56:58',14400,'2012-12-24 07:56:58',NULL,'[openstack-dev] [quantum][LBaaS] need to do corresponding\n	changes in LBaaS API doc','Hi Youcef,\n\nPlease see my comments inline\n\n \n\nThanks,\n\nOleg\n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Saturday, December 22, 2012 5:29 AM\nTo: \'OpenStack Development Mailing List\'\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding\nchanges in LBaaS API doc\n\n \n\nHi Oleg,\n\n \n\nThanks, I have reviewed these, and require some clarification from you.\n\n \n\n-          add default values for fields not specified while VIP creation\n\n \n\nDo you mean \"description\" and \"connection_limit\" fields? For \"description\",\nthe default value if not specified by the user is an empty string, while\n\"connection_limit\" if not specified by the user is not used (internally and\nin DB, you can store it as \"-1\" meaning there is no connection limit). \n\n[obondarev] Agree\n\n \n\n-          add \"description\" and \"connection_limit\" fields with default\nvalues to the response of Create VIP Example\n\n \n\nIn the response, if description is an empty string and if \"connection_limit\"\nis set to -1, we do not return them, as it means the user has not set these,\nand they have got a NULL value.\n\n[obondarev] Agree\n\n \n\n-          add \"lb_method\" field to the request of Create Pool Example as it\nis required\n\n \n\nYes, good catch! I\'ll add this.\n\n \n\n-          remove \"members\" filed from the request of Create Pool Example\n\n-          add \"health_monitors\" to the list of updatable attributes of a\npool\n\n-          remove \"List all Members of a specific Pool\" and \"List Health\nMonitors associated with a Pool\" REST calls from the API\n\n \n\nYes, since we have agreed now on an approach for dealing with sub-resources,\nI can now update the spec.\n\n \n\n-          add \"pool_id\" to the must list when creating a member\n\nYep.\n\n \n\n-          add appropriate values to the request of Associate Health\nMonitors with a Pool Example\n\n \n\nI thought that associating/dissociating pools and health_monitors is now\ndone when creating or updating a pool (by specification a collection\nattribute). Can you clarify for me what the current implementation does?\n\n[obondarev] It\'s true but we also still have an opportunity to\nassociate/disassociate monitors with pools using sub-resource concept: \n\nPOST pools/<pool_id>/health_monitors {body}\n\nDELETE pools/<pool_id>/health_monitors/<health_monitor_id>\n\nWhere body is:\n\n{\n\n                \'id\': <health_monitor_id>,\n\n                \'tenant_id\': <tenant_id>\n\n}\n\n- to add one monitor to a pool - this avoids user from doing two roundtrips\nwhere he needs first to do GET and then PUT on a pool resource.\n\n \n\nThanks\n\nYoucef \n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Thursday, December 20, 2012 1:49 AM\nTo: Youcef Laribi; \'OpenStack Development Mailing List\'\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do corresponding\nchanges in LBaaS API doc\n\n \n\nSure Youcef, here\'s the list of updates:\n\n \n\n-          add default values for fields not specified while VIP creation\n\n-          add \"description\" and \"connection_limit\" fields with default\nvalues to the response of Create VIP Example\n\n-          add \"lb_method\" field to the request of Create Pool Example as it\nis required\n\n-          remove \"members\" filed from the request of Create Pool Example\n\n-          add \"health_monitors\" to the list of updatable attributes of a\npool\n\n-          remove \"List all Members of a specific Pool\" and \"List Health\nMonitors associated with a Pool\" REST calls from the API\n\n-          add \"pool_id\" to the must list when creating a member\n\n-          add appropriate values to the request of Associate Health\nMonitors with a Pool Example\n\n \n\nThanks,\n\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Wednesday, December 19, 2012 11:42 PM\nTo: Oleg Bondarev; OpenStack Development Mailing List\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do carresponding\nchanges in LBaaS API doc\n\n \n\nOleg,\n\n \n\nCan you outline what those changes are?\n\n \n\nThanks,\n\nYoucef\n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Wednesday, December 19, 2012 5:39 AM\nTo: Youcef Laribi; OpenStack Development Mailing List\nSubject: [openstack-dev][quantum][LBaaS] need to do carresponding changes in\nLBaaS API doc\n\n \n\nHi Youcef,\n\n \n\nNow after LBaaS API extension patch was merged we need to do several\ncorresponding changes in the API doc. \n\nI can do it if you provide me rights on editing the page\n(http://wiki.openstack.org/Quantum/LBaaS/API_1.0).\n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121224/3c46f198/attachment.html>\n\n','<7B14C05615DB43488B85E143995BD549010A5B16FAD9@LONPMAILBOX01.citrite.net>',NULL),('<0A543AC3-548B-425B-824A-F0B19F5FEA95@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 12:57:04',0,'2014-11-19 12:57:04',NULL,'[openstack-dev] Dynamic Policy','Hi Adam,\n\nSo a comprehensive write-up...although I\'m not sure we have made the case for why we need a complete rewrite of how policy is managed.  We seemed to have lept into a solution without looking at other possible solutions to the problems we are trying to solve.  Here\'s a start at an alternative approach:\n\nProblem 1: The current services don\'t use the centralised policy store/fetch of keystone, meaning that a) policy file management is hard, and b) we can\'t support the policy-per-endpoint style of working\nSolution: Let\'s get the other services using it!  No code changes required in Keytsone.  The fact that we haven\'t succeeded before, just means we haven\'t tried hard enough.\n\nProblem 2: Different domains want to be able to create their own \"roles\" which are more meaningful to their users...but our \"roles\" are global and are directly linked to the rules in the policy file - something only a cloud operator is going to want to own.\nSolution: Have some kind of domain-scoped role-group (maybe just called \"domain-roles\"?) that a domain owner can define, that maps to a set of underlying roles that a policy file understands (see: https://review.openstack.org/#/c/133855/). [As has been pointed out, what we are really doing with this is finally doing real RBAC, where what we call roles today are really capabilities and domain-roles are really just roles].  As this evolves, cloud providers could slowly migrate to the position where each service API is effectively a role (i.e. a capability) and at the domain level there exists the \"abstraction that makes sense for the users of that domain\" into the underlying capabilities. No code changes...this just uses policy files as they are today (plus domain-groups) - and tokens as they are too. And I think that level of functionality would satisfy a lot of people. Eventually (as pointed out by samuelmz) the policy \"file\" could even simply become the definition of the service capabilities (and whether each capability is \"open\", \"closed\" or \"is a role\")...maybe just registered and stored in the service entity the keystone DB (allowing dynamic service registration). My point being, that we really didn\'t require much code change (nor really any conceptual changes) to get to this end point...and certainly no rewriting of policy/token formats etc.  [In reality, this last point would cause problems with token size (since a broad admin capability would need a lot of capabilities), so some kind a collections of capabilities would be required.]\n\nProblem 3: A cloud operator wants to be able to enable resellers to white label her services (who in turn may resell to others) - so needs some kind of inheritance model so that service level agreements can be supported by policy (e.g. let the reseller give the support expert from the cloud provider have access to their projects).\nSolution: We already have hierarchical inheritance in the works...so that we would allow a reseller to assign roles to a user/group from the parent onto their own domain/project. Further, domain-roles are just another thing that can (optionally) be inherited and used in this fashion.\n\nMy point about all the above is that I think while what you have laid out is a great set of steps....I don\'t think we have conceptual agreement as to whether that path is the only way we could go to solve out problems.\n\nHenry\nOn 18 Nov 2014, at 23:40, Adam Young <ayoung at redhat.com> wrote:\n\n> There is a lot of discussion about policy.  I\'ve attempted to pull the majority of the work into a single document that explains the process in a step-by-step manner:\n> \n> \n> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/\n> \n> Its really long, so I won\'t bother reposting the whole article here.  Instead, I will post the links to the topic on Gerrit.\n> \n> https://review.openstack.org/#/q/topic:dynamic-policy,n,z\n> \n> \n> There is one additional review worth noting:\n> \n> https://review.openstack.org/#/c/133855/\n> \n> Which is for \"private groups of roles\"  specific to a domain.  This is related, but not part of the critical path for the things I wrote above.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/bf75e3e4/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/bf75e3e4/attachment.pgp>\n\n','<546BD907.3060709@redhat.com>',NULL),('<0A5F07A1-C337-4490-90CC-E592445F7821@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:38:13',-18000,'2014-01-22 15:38:13',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival #1\n	-	Roles','\nOn Jan 22, 2014, at 7:09 AM, Jaromir Coufal <jcoufal at redhat.com> wrote:\n\n> \n> \n> On 2014/22/01 10:00, Jaromir Coufal wrote:\n>> \n>> \n>> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:\n>>> Hiya - Resource is actually a Heat term that corresponds to what we\'re\n>>> deploying within\n>>> the Overcloud Stack - i.e., if we specify that we want an Overcloud\n>>> with 1 Controller\n>>> and 3 Compute, Heat will create a Stack that contains 1 Controller and\n>>> 3 Compute\n>>> Resources.\n>> \n>> Then a quick question - why do we design deployment by\n>> increasing/decreasing number of *instances* instead of resources?\n>> \n>> -- Jarda\n> \n> And one more thing - Resource is very broad term as well as Role is. The only difference is that Heat accepted \'Resource\' as specific term for them (you see? they used broad term for their concept). So I am asking myself, where is difference between generic term Resource and Role? Why cannot we accept Roles? It\'s short, well describing...\n> \n> I am leaning towards Role. We can be more specific with adding some extra word, e.g.:\n> * Node Role\n\n+1 to Node Role. I agree that ?role? is being used as a generic term here. I?m still convinced it?s important to use ?Node? in the name since this is the item we are describing by assigning it a certain type of role.\n\nLiz\n\n> * Deployment Role\n> ... and if we are in the context of undercloud, people can shorten it to just Roles. But \'Resource Category\' seems to me that it doesn\'t solve anything.\n> \n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52DFB50B.70400@redhat.com>',NULL),('<0A60C1D1-6D99-4646-A242-280028F55ED2@gridcentric.ca>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-28 12:27:48',-14400,'2013-10-28 16:27:48',NULL,'[Openstack-operators] vms pool','Thanks for the plug Jay :-)\n\nLet me explain a tiny bit: \n\nStep 1. Boot VM\nStep 2. Create \"live image\", which is a snapshot of disk, RAM, etc.\nStep 3. Boot from \"live image\"\n\nInstances booted from the same \"live image\" share RAM and start in the state they were snapshotted at in Step 2, thus skipping the OS boot and any common application setup you did beforehand.\n\nTherefore, Adri?n, VMS addresses your problem not by having a pool of virtual machines ready to run, but by reducing virtual machine creation time (more precisely, reducing the time between requesting a new instance and the time it?s ready to start doing work).\n\nCheers,\nPeter\n\nOn Oct 28, 2013, at 11:56 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> Check out GridCentric\'s stuff:\n> \n> http://gridcentric.com/technology/vms/\n> \n> Best,\n> -jay\n> \n> On 10/28/2013 11:53 AM, George Shuklin wrote:\n>> Ok, I understand it.\n>> \n>> You want them be available for specified tenant or for \'any tenant\n>> requested next instance\'? For single tenant just create required amount\n>> of instances (and keep that amount at certain level - simple 1-2 lines\n>> script) , for cross-tenant pool - I think it not clearly possible\n>> because of image access rights.\n>> \n>> On 28.10.2013 19:13, Adri?n Norte wrote:\n>>> I think that tenants is the other name of projects.\n>>> \n>>> I want to have a X number of VMs always idle waiting to be called\n>>> because I don\'t want to wait for it to start.\n>>> \n>>> El 28/10/13 13:08, George Shuklin escribi?:\n>>>> Yep. They (guests) are called tenants in openstack terminology.\n>>>> \n>>>> On 28.10.2013 15:20, Adri?n Norte wrote:\n>>>>> Hi, is possible to have a pool of guests in openstack?\n>>>>> \n>>>>> Thanks.\n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-operators mailing list\n>>>>> OpenStack-operators at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-operators mailing list\n>>>> OpenStack-operators at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<526E891D.9000405@gmail.com>',NULL),('<0A6A69BC-6555-4B21-AA65-69F3D4C26369@a10networks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-07 19:03:57',0,'2014-11-07 19:03:57',NULL,'[openstack-dev] [neutron][lbaas] meeting day/time change','Hi all,\n\nNeutron LBaaS meetings are now going to be Tuesdays at 16:00 UTC.\n\nSafe travels. \n\nThanks,\nDoug\n\n\n\n',NULL,NULL),('<0A70B897-5539-4B9A-9EA7-A14ED63E8567@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 11:25:07',-25200,'2013-08-16 18:25:07',NULL,'[openstack-dev] Gate breakage process - Let\'s fix! (related but not\n	specific to neutron)','Neutron has been in and out of the gate for the better part of the past month, and it didn\'t slow the pace of development one bit.  Most Neutron developers kept on working as if nothing was wrong, blithely merging changes with no guarantees that they weren\'t introducing new breakage.  New bugs were indeed merged, greatly increasing the time and effort required to get Neutron back in the gate.  I don\'t think this is sustainable, and I\'d like to make a suggestion for how to minimize the impact of gate breakage.\n\nFor the record, I don\'t think consistent gate breakage in one project should be allowed to hold up the development of other projects.  The current approach of skipping tests or otherwise making a given job non-voting for innocent projects should continue.  It is arguably worth taking the risk of relaxing gating for those innocent projects rather than halting development unnecessarily.\n\nHowever, I don\'t think it is a good idea to relax a broken gate for the offending project.  So if a broken job/test is clearly Neutron related, it should continue to gate Neutron, effectively preventing merges until the problem is fixed.  This would both raise the visibility of breakage beyond the person responsible for fixing it, and prevent additional breakage from slipping past were the gating to be relaxed.\n\nThoughts?\n\n\nm.\n\n\n\n\n\n\n',NULL,NULL),('<0A738C1F-CA30-4F1D-B850-EF9530001F78@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-15 22:18:17',0,'2014-03-15 22:18:17',NULL,'[Openstack-docs] back-end,\n back end or backend in OPS Guide and openstack-manuals?','Anne, according to our editor at Rackspace, it\'s \"back end\" for a noun and \"back-end\" for an adjective.\n\nSent from my iPhone\n\nOn Mar 15, 2014, at 4:50 PM, \"Anne Gentle\" <annegentle at justwriteclick.com<mailto:annegentle at justwriteclick.com>> wrote:\n\nDiane - you just ran into this, what do you think?\n\nAnne Gentle\nContent Stacker\nanne at openstack.org<mailto:anne at openstack.org>\n\n\nOn Mar 15, 2014, at 4:32 PM, Andreas Jaeger <aj at suse.com<mailto:aj at suse.com>> wrote:\n\nOn 15. M?rz 2014 21:38:58 MEZ, Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>> wrote:\nSorry, hit send too soon. I am seeing \"back-end\" as a markup by double-clicking the red dash and seeing the whole word corrected to back-end using Adobe Reader in multiple locations.\n\nHowever, I see http://chimera.labs.oreilly.com/books/1230000000969/ch04.html as backend so I\'m sending this to our copy editor John Pierce. John, can you comment?\n\nThanks,\nAnne\n\n\nOn Sat, Mar 15, 2014 at 3:34 PM, Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>> wrote:\nHe intends it to be changed to back-end.\n\n\nOn Sat, Mar 15, 2014 at 1:51 PM, Andreas Jaeger <aj at suse.com<mailto:aj at suse.com>> wrote:\nOn 03/15/2014 07:33 PM, Matt Kassawara wrote:\n> I thought we were only supposed to tackle \"AU\" comments.\n>\n\nThere\'re yellow sticky notes with AU in it and there are blue edits. I\'m\ntackling all blue edits,\n\nAndreas\n--\n Andreas Jaeger aj@{suse.com<http://suse.com>,opensuse.org<http://opensuse.org>} Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n\n\nSo, it\'s backend - how shall we handle openstack-manuals and especially the glossary?\n\nI would prefer to use the same spelling everywhere and minimize divergence,\n\nAndreas\n--\nAndreas Jaeger\naj@{suse.com<http://suse.com>,novell.com<http://novell.com>,opensuse.org<http://opensuse.org>} Twitter / Identica: jaegerandi\nSUSE LINUX Products GmbH , Maxfeldstr. 5, 90409 N?rnberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)\nThis email was sent from my phone\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140315/801e0ecd/attachment.html>\n\n','<6901C193-5019-4F27-B65E-E81A0E0B54EC@justwriteclick.com>',NULL),('<0A787479-670F-4B72-8288-B4B03594EBB5@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 16:21:27',0,'2014-06-18 16:21:27',NULL,'[openstack-dev] [Congress] Use Cases','Hi all,\n\nWe?ve been working on developing a list of use cases for Congress, which we?ve also started voting on so as to prioritize our efforts.  Please feel free take a look, leave feedback, add to the list, vote, whatever.\n\nhttps://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit\n\nIf you add a use case, please use the one called ?Public/private networks with group membership? as a guide.  The policy doesn?t need to be written in the policy language syntax, but it needs to be precise enough for us to figure out if it can be written in that language.\n\nFor those of you who have already contributed use cases, could you take a look at ?Public/private networks with group membership? to see what info I believe we need for each use case?  And then if your use case is missing something, could you add it (or leave a note explaining why the info is unnecessary/unknown)?\n\nThanks,\nTim\n\n',NULL,NULL),('<0A7B6DD7-254E-4E11-875E-FDC936399E61@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-10 08:40:18',-28800,'2013-01-10 16:40:18',NULL,'[openstack-dev] [Openstack][Nova] Slow Nova API Calls from\n	periodic-tempest-devstack-vm-check-hourly','One more thing, we can also optimize get_instance_nw_info to skip the rpc, but once again we have to be careful about where it is called from a place where we don\'t have db access. Perhaps we could initially add an extra parameter local (defaulting to False) that makes it do the db request locally. As we move the calls to get_instance_nw_info up into compute.api, we can add local=True.\n\nVish\n\nOn Jan 10, 2013, at 8:34 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n\n> \n> On Jan 9, 2013, at 6:56 PM, Joe Gordon <jogo at cloudscaling.com> wrote:\n> \n>> I have started to go through everyone\'s suggestions, but I thought I would share some more preliminary findings.\n>> \n>> Now that millisecond logging is enabled, the logs show a clearer picture of what is going on.\n>> \n>> Here is stack trace from devstack for the command DisassociateAddress, (the slowest REST call triggered by the openstack exercises): \n>> \n>> http://paste.openstack.org/show/29103/ (from local build)\n>> http://paste.openstack.org/show/29104/ (from logs.openstack.org)\n>> \n>> Note: neither pastebin have entire RPC message contents in them.\n>> \n>> \n>> Analysis:\n>> \n>> http://paste.openstack.org/show/29103/ \n>> \n>> Total time: 4.8428030 seconds\n>> \n>> * the 3 RPC calls take: 65ms, 50ms and 107ms\n>> \n>> * RPC msg 79bbafe8079841e694640a7435f5d52f takes 1.174 seconds (7.080-5.906) to perform network_api.get_instance_id_by_floating_address, which consists of 3 just 3 DB calls.\n> \n> This can be optimized heavily (although we should probably make a new method get_instance_uuid? for compatibility):\n>  a) the note is incorrect, we can return the uuid and skip the last call \n>  b) the two calls can be converted into a single db call with a join (we only need the instance uuid)\n>  c) we can move this up to network.api and skip rpc completely (see my coments below about associate)\n> \n>> \n>> * RPC msg 4c9055aa7a034d6f85e99df7dc0a8fcc takes 3.109 seconds (10.191-7.082) to perform network_api.disassociate_floating_ip\n>> \n>> * RPC msg 45841e95f05d4003a00bc059fade10b0 takes 0.3359 (10.527-10.191) to perform  network_api.get_instance_nw_info\n>> \n>> * in RPC msg 4c9055aa7a034d6f85e99df7dc0a8fcc, n-net waits 0.604 seconds (8.410-7.806) Attempting to grab file lock \"iptables\", but n-net log shows nothing else is running (bad lock, or lack of logging?)  [Note: I added in logging when release a  file lock, and nothing is releases the file lock between attempting and got.]\n> \n> The iptables lock is external so it is possible that n-cpu has the lock during this time.\n> \n>> \n>> * iptables commands take 2.52 seconds (10.93-8.41)\n> \n> This seems like the best place to start optimizing. Looks like we might be able to optimize the iptables code a bit. For example we could save and restore all tables at once instead of doing each of them individually. It appears that most of the time is spent doing the actual shell command as opposed to in the python code.\n> \n>> \n>> \n>> Further Questions:\n>> \n>> * Why is network_api.get_instance_id_by_floating_address so slow? Why do we even need it, if its just doing DB calls?\n> \n> This is probably leftover from when quantum was on the recieving end of the api call. Now that quantum replaces network.api, we could move these calls up to the api layer and save an rpc round trip. There is actually quite a bit of optimization here. Another big slowdown is in multihost mode the message is sent to \'any\' network host and then it is rebroadcast to the right host.  \n> We can actually send the message to the right host on the api side and avoid the rebroadcast.  This should save us a lot unnecessary traffic and time. It can be done for associate_floating and disassociate_floating trivially. Allocate and deallocate network can be done as well, although we have to move the calling side up to compute.api where it has db access.\n> \n>> * Why are all three calls synchronous, can we do the iptables commands asynchronously?\n> \n> We may be able to fire off the disassociate at the same time. The nw info call has to happen afterwards\n>> \n>> * How much time is spent in nova.db.api vs what sql itself reports (aka sqlalchemy overhead).\n> \n> When I last looked it was mostly sqlalchemy, especially where it is hydrating multiple models.\n> \n>> \n>> Patches for better logging/debugging:\n>> \n>> * https://review.openstack.org/#/c/19354/ - properly format milliseconds \n>> * https://review.openstack.org/#/c/19076/ - enable mysql slow log in devstack\n>> * https://review.openstack.org/#/c/19358/ - log when release file lock\n>> \n>> best,\n>> Joe\n>> \n>> \n>> On Mon, Jan 7, 2013 at 12:18 AM, Monty Taylor <mordred at inaugust.com> wrote:\n>> \n>> \n>> On 01/07/2013 07:55 AM, Monty Taylor wrote:\n>> >\n>> >\n>> > On 01/07/2013 06:46 AM, Mark McLoughlin wrote:\n>> >> On Fri, 2013-01-04 at 11:58 -0800, Joe Gordon wrote:\n>> >>> Conclusion\n>> >>> =========\n>> >>>\n>> >>> Nova REST calls take way long, even in small scale devstack/tempest\n>> >>> testing.  We should spend resources on fixing this for Grizzly.  I would\n>> >>> like to start a dialog on how we can fix this and see if anyone wants to\n>> >>> volunteer help.  Below are a few possible ideas of things that will help us\n>> >>> make the REST calls faster.\n>> >>>\n>> >>> * Continuously track REST API times of devstack/tempest jobs, to identify\n>> >>> slow API calls and watch for trends.  (logstash + statsd?)\n>> >>> * Identify the underlying cause of the slow performance.  It looks like\n>> >>> nova.db.api may be partially responsible, but not the only issue?  What\n>> >>> else is a bottleneck?\n>> >>> * Enable millisecond level time logging\n>> >>> https://review.openstack.org/#/c/18933/\n>> >>> * Add an option in devstack to enable python profiling?  Whats best way to\n>> >>> do this?\n>> >>> * Make more REST API related code asynchronous (via RPC)\n>> >>\n>> >> Summary is we\'re randomly seeing a multi-second delay in nova-api\n>> >> between the time a HTTP request is received and we send an AMQP message?\n>> >>\n>> >> Suspecting the DB calls is a good first guess. The ability to log slow\n>> >> DB calls would be nice. Perhaps MySQL has something we can use here,\n>> >> assuming we log some sort of client ID on the nova-api side that we can\n>> >> use to correlate with the MySQL logs.\n>> >\n>> > There is, you\'ll be happy to know, a MySQL feature called the slow query\n>> > log. You can enable it by adding:\n>> >\n>> > log_slow_queries       = /var/log/mysql/mysql-slow.log\n>> >\n>> > To the my.cnf. Additionally, you can put in the following:\n>> >\n>> > long_query_time = 1\n>> > log-queries-not-using-indexes\n>> >\n>> > The first is a threshold, in seconds, of how long a query needs to last\n>> > before it\'s considered slow. The second will cause all queries that did\n>> > not use indexes as part of their run to be logged.\n>> \n>> https://review.openstack.org/19075\n>> https://review.openstack.org/19076\n>> \n>> > Getting client ids passed to the db log for correlation will be\n>> > trickier. A lot of the big web properties will do tricks in their db\n>> > layer where they will add embedded comments into the sql passed in that\n>> > include information like client ids. I\'m not sure how hard that sort of\n>> > tracing would be to do on our end -but turning on the slow query log\n>> > while doing these sorts of things is probably a great starting place.\n>> >\n>> >> External processes we run is also another place to look. Again, logging\n>> >> those processes that take longer than a certain threshold to run might\n>> >> be good.\n>> >>\n>> >> I\'d also investigate whether it\'s some other greenthread blocking the\n>> >> API request thread from running. What would be really nice would be some\n>> >> way of logging when a particular greenthread ran for a long time while\n>> >> other greenthreads are pending.\n>> >>\n>> >> It would also be good to see some system level stats and see if it\'s\n>> >> just that the system is generally CPU or I/O bound while these slow\n>> >> calls are happening. Maybe logging CPU, memory, disk and network usage\n>> >> along with the top few processes every tenth of a second.\n>> >\n>> > Running dstat in a window while doing the other thing is fairly easy.\n>> > Perhaps we should add a dstat screen to devstack?\n>> >\n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130110/9ab08579/attachment.html>\n\n','<B4FD3D6A-5F79-47E6-9276-03EDBE062C90@gmail.com>',NULL),('<0A7DD3A6-974D-4FF9-8F42-6EA48C25EB68@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-27 11:57:11',-18000,'2014-10-27 16:57:11',NULL,'[OpenStack Foundation] Board Meeting Summary - Oct 20','Hi everyone,\n\nLast Monday, October 20, the Board participated in a two-hour phone meeting. The primary topics were next steps in DefCore and reviewing the process for selecting a new Platinum member, since we will have our first vacancy in 2015. During that meeting, the Board approved the following:\n\n- Minutes from the September 18 board meeting: https://wiki.openstack.org/wiki/Governance/Foundation/18Sept2014BoardMinutes\n\n- The new Platinum Member Selection Procedure submitted for review by the Membership Committee. The Board expects to hear several presentations from prospective Platinum and Gold Members at the next meeting happening November 2.\n\n- A new framework proposed by the DefCore Committee and Foundation Staff that includes both platform and component level commercial trademark licensing programs. The framework allows the DefCore committee to propose new component level programs in the future, as well as update the technical requirements (core capabilities and designated sections) with each new version of the software. Initial programs will include Platform, Object Storage and a new Compute program. Under the new framework, the DefCore Committee plans to present the Havana Advisory Designated Sections for approval at the next meeting.\n\nOur next Board meeting will happen in Paris, Sunday, November 2, starting at 9 am local time. It will be immediately followed by a joint Board / Technical Committee meeting starting at 2 pm. Any community members wishing to attend the meeting in person should check in at the OpenStack Summit Registration Information Desk at Palais des Congr?s, in order to pick up a wristband to access the room in Level 2.\n\nThanks,\nJonathan\n\n\n\n\n',NULL,NULL),('<0A89B25B-86D5-46B5-B407-892E6A3EF4D3@hortonworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 14:38:43',-18000,'2013-12-03 19:38:43',NULL,'[openstack-dev] [savanna] neutron floating IP assignment unexpected','Hi,\n\n  I have the following configuration in savanna.conf:\n\n# If set to True, Savanna will use floating IPs to communicate\n# with instances. To make sure that all instances have\n# floating IPs assigned in Nova Network set\n# \"auto_assign_floating_ip=True\" in nova.conf.If Neutron is\n# used for networking, make sure that all Node Groups have\n# \"floating_ip_pool\" parameter defined. (boolean value)\nuse_floating_ips=false\n\n# Use Neutron or Nova Network (boolean value)\nuse_neutron=true\n\n# Use network namespaces for communication (only valid to use in conjunction\n# with use_neutron=True)\nuse_namespaces=true\n\n  My nova.conf file DOES NOT have auto_assign_floating_ip set to \"True\".\n\n  My dashboard local settings file explicitly sets AUTO_ASSIGNMENT_ENABLED = False\n\n  Yet, the spawned VMs are generated with a floating IP:\n\n[root at cn082 savanna(keystone_demo)]# nova list\n+--------------------------------------+----------------+--------+---------------------------------+\n| ID                                   | Name           | Status | Networks                        |\n+--------------------------------------+----------------+--------+---------------------------------+\n| e32572ae-397b-4a61-9562-7a52fe6cd738 | dc1-master-001 | ACTIVE | private=10.0.0.14, 172.24.4.232 |\n| da50a103-0f64-4b33-9bd1-586e8b1c981c | dc1-slave-001  | ACTIVE | private=10.0.0.15, 172.24.4.233 |\n+--------------------------------------+----------------+--------+---------------------------------+\n\n  Any idea how this may be the case?\n\n-- Jon\n\n\n-- \nCONFIDENTIALITY NOTICE\nNOTICE: This message is intended for the use of the individual or entity to \nwhich it is addressed and may contain information that is confidential, \nprivileged and exempt from disclosure under applicable law. If the reader \nof this message is not the intended recipient, you are hereby notified that \nany printing, copying, dissemination, distribution, disclosure or \nforwarding of this communication is strictly prohibited. If you have \nreceived this communication in error, please contact the sender immediately \nand delete it from your system. Thank You.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/c56e0a48/attachment.html>\n\n',NULL,NULL),('<0a9501cda735$cd434468$f901a8c0@dlt.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-10 18:22:52',-14400,'2012-10-10 22:22:52',NULL,'[OpenStack Foundation] Foundation Digest, Vol 11, Issue 8','\n\nT-Mobile. America\'s First Nationwide 4G Network\n\n\"foundation-request at lists.openstack.org\" <foundation-request at lists.openstack.org> wrote:\n\nSend Foundation mailing list submissions to\n	foundation at lists.openstack.org\n\nTo subscribe or unsubscribe via the World Wide Web, visit\n	http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\nor, via email, send a message with subject or body \'help\' to\n	foundation-request at lists.openstack.org\n\nYou can reach the person managing the list at\n	foundation-owner at lists.openstack.org\n\nWhen replying, please edit your Subject line so it is more specific\nthan \"Re: Contents of Foundation digest...\"\n\n\nToday\'s Topics:\n\n   1. Re: Board meeting minutes before the Summit? (Monty Taylor)\n   2. Re: Congrats Lauren Sell, OpenStack Foundation hire!\n      (Mark McLoughlin)\n   3. Re: Congrats Lauren Sell,	OpenStack Foundation hire! (Matt Joyce)\n   4. Re: Board meeting minutes before the Summit? (Jonathan Bryce)\n   5. Use of the word \"certified\" and protecting	brand OpenStack\n      (Tristan Goode)\n\n\n----------------------------------------------------------------------\n\nMessage: 1\nDate: Wed, 10 Oct 2012 10:27:11 -0700\nFrom: Monty Taylor <mordred at inaugust.com>\nTo: foundation at lists.openstack.org\nSubject: Re: [OpenStack Foundation] Board meeting minutes before the\n	Summit?\nMessage-ID: <5075AFEF.9020205 at inaugust.com>\nContent-Type: text/plain; charset=ISO-8859-1\n\nI second this.\n\n\nOn 10/09/2012 11:27 PM, Vincent Untz wrote:\n> Hi,\n> \n> Unless I missed them, I haven\'t seen minutes of any of the meetings\n> published so far.\n> \n> I know we already had a thread about this a month ago, but it\'d be great\n> to have public minutes of all meetings that happened before the Summit;\n> the Summit is a nice opportunity for members to talk to the board, and\n> having the latest news is kind of nice for that :-)\n> \n> Cheers,\n> \n> Vincent\n> \n\n\n\n------------------------------\n\nMessage: 2\nDate: Wed, 10 Oct 2012 19:59:59 +0100\nFrom: Mark McLoughlin <markmc at redhat.com>\nTo: Jonathan Bryce <jonathan at openstack.org>\nCc: foundation at lists.openstack.org\nSubject: Re: [OpenStack Foundation] Congrats Lauren Sell, OpenStack\n	Foundation hire!\nMessage-ID: <1349895599.19587.218.camel at sorcha>\nContent-Type: text/plain; charset=\"UTF-8\"\n\nOn Tue, 2012-10-09 at 18:45 -0500, Jonathan Bryce wrote:\n> We\'re very excited Lauren will continue working on OpenStack as the\n> OpenStack Foundation Director of Marketing.\n\nExcellent news! And more excellent news from Stefano\'s blog:\n\n  http://maffulli.net/2012/10/05/new-job-same-job-at-openstack-foundation-new-laptop/\n\nthat Stefano, Thierry and Mark have also moved to the Foundation.\n\nCongrats to all involved!\n\nThere\'s definitely a lot of interest in appointments like these. Could\nwe have appointments announced by the Foundation as a matter of course\nin future?\n\nCheers,\nMark.\n\n\n\n\n------------------------------\n\nMessage: 3\nDate: Wed, 10 Oct 2012 12:38:57 -0700\nFrom: Matt Joyce <matt at nycresistor.com>\nTo: Mark McLoughlin <markmc at redhat.com>\nCc: foundation at lists.openstack.org\nSubject: Re: [OpenStack Foundation] Congrats Lauren Sell,	OpenStack\n	Foundation hire!\nMessage-ID:\n	<CAP_sDUHMMENGusWyvD=Hxogj-R3tB4f54EZhXFw5HhG8v7vXQQ at mail.gmail.com>\nContent-Type: text/plain; charset=ISO-8859-1\n\nStefano was an obvious choice.  Glad he got picked up.\n\nOn Wed, Oct 10, 2012 at 11:59 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> On Tue, 2012-10-09 at 18:45 -0500, Jonathan Bryce wrote:\n>> We\'re very excited Lauren will continue working on OpenStack as the\n>> OpenStack Foundation Director of Marketing.\n>\n> Excellent news! And more excellent news from Stefano\'s blog:\n>\n>   http://maffulli.net/2012/10/05/new-job-same-job-at-openstack-foundation-new-laptop/\n>\n> that Stefano, Thierry and Mark have also moved to the Foundation.\n>\n> Congrats to all involved!\n>\n> There\'s definitely a lot of interest in appointments like these. Could\n> we have appointments announced by the Foundation as a matter of course\n> in future?\n>\n> Cheers,\n> Mark.\n>\n>\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n------------------------------\n\nMessage: 4\nDate: Wed, 10 Oct 2012 14:48:32 -0500\nFrom: Jonathan Bryce <jonathan at openstack.org>\nTo: foundation at lists.openstack.org\nSubject: Re: [OpenStack Foundation] Board meeting minutes before the\n	Summit?\nMessage-ID: <536C4D29-F701-473E-AA70-6F804FD16142 at openstack.org>\nContent-Type: text/plain; charset=us-ascii\n\nWe\'ve just recently gotten full approval of the first two meeting minutes and will post to the wiki shortly.\n\nJonathan\n\n\nOn Oct 10, 2012, at 12:27 PM, Monty Taylor wrote:\n\n> I second this.\n> \n> \n> On 10/09/2012 11:27 PM, Vincent Untz wrote:\n>> Hi,\n>> \n>> Unless I missed them, I haven\'t seen minutes of any of the meetings\n>> published so far.\n>> \n>> I know we already had a thread about this a month ago, but it\'d be great\n>> to have public minutes of all meetings that happened before the Summit;\n>> the Summit is a nice opportunity for members to talk to the board, and\n>> having the latest news is kind of nice for that :-)\n>> \n>> Cheers,\n>> \n>> Vincent\n>> \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n------------------------------\n\nMessage: 5\nDate: Thu, 11 Oct 2012 08:42:21 +1100\nFrom: Tristan Goode <tristan at aptira.com>\nTo: foundation at lists.openstack.org\nCc: foundation-board at lists.openstack.org\nSubject: [OpenStack Foundation] Use of the word \"certified\" and\n	protecting	brand OpenStack\nMessage-ID: <02db3751-69ec-4883-a766-09ba4d740bce at aptira.com>\nContent-Type: text/plain; charset=\"us-ascii\"\n\nDear Foundation Members,\n \nI believe a key role of the Foundation is to protect the brand that is OpenStack.\n \nAfter raising the issue with Rackspace and Jonathan Bryce several days ago, yesterday I sought my fellow Foundation Board members opinion on Rackspace\'s use of the word \"certified\" in media releases 6 days ago, tweets from their staff, and as late as yesterday in this mail out to the summit attendees below. I emailed my Board colleagues because I thought raising this with the elected representatives of the OpenStack Community would alert them to the potential ramifications of this issue. As I see it Rackspace have jumped the gun and are ambush marketing. \n \nThe main problems I see:\n \n1. The timing is unfortunate because there is no clear Board/Foundation policy as yet. \n2. I believe it is the Foundation\'s right to determine what is certified and what is not under the terms of the Foundation\'s trademarks.\n3. This type of activity is clearly open to abuse. Any operator regardless of size, integrity or professionalism could adopt a similar approach. Therefore it needs to be dealt with urgently.\n \nLeaving Rackspace\'s actions aside, I made a suggestion for a certification process for training materials and deliverables that they be offered to a community sourced committee for review and approval. If this proposal is accepted then I would ask Rackspace that they offer up their course materials for this review, and that this might form a baseline for establishing the certification benchmark.\n \nIf certified qualifications are not valued in the USA, courses that present an official certification are highly valued in Australia, Asia and Europe as clear markers of achievement. Integrity of that certification is key.\n \nIf this was a mistake, and I sincerely hope it was, it is able to be, and should be, corrected.\n \nIf we cannot gather enough support to resist such opportunistic behaviour then we (as a community) risk letting this run away on us. The Foundation needs to formulate a considered and effective response on this very important topic. It needs your help. Make your opinions known.\n \nCheers\nTristan\n \n \n \nFrom: Jim Curry [mailto:jim.curry at rackspace.com] \nSent: Wednesday, 10 October 2012 1:08 PM\nTo: Randy Bias; Tristan Goode\nCc: foundation-board at lists.openstack.org\nSubject: Re: [Foundation Board] Use of the word \"certified\" and guidelines around use of words like \"official\"\n \nTristan,\n \nThe email was an unfortunate mistake by our marketing team.  It does not represent the official branding or positioning of our offer.  We aren\'t perfect, and for any confusion that created I apologize.\n \nTo be clear, our offer is a \"Rackspace Certified\" training program for OpenStack, not \"OpenStack certified\" for OpenStack.  We are putting our brand behind the training, not representing the brand of the project itself.  It has never been part of our launch messaging or positioning, and if that was ever done it was an unfortunate mistake and not the company position.\n \nI 100% agree with you that should someone wish to have \"OpenStack Certified\" training that there should be rules governing such usage.  We do need to agree whether or not training certification is a mission the foundation should pursue or not.  Are there good examples in the open source community we believe we should emulate?\n \nJim\n \nFrom: \"Randy L. Bias\" <randyb at cloudscaling.com>\nDate: Tuesday, October 9, 2012 9:46 PM\nTo: Tristan Goode <tristan at aptira.com>\nCc: \"foundation-board at lists.openstack.org\" <foundation-board at lists.openstack.org>\nSubject: Re: [Foundation Board] Use of the word \"certified\" and guidelines around use of words like \"official\"\n \nI generally concur and I think this is a good catch.  Clearly the discussion isn\'t about RAX, but what the interim strategy is while things like what \"certification\" means are ironed out. \n \nHowever, I do want to point out that it might take a while to resolve that issue and I\'m inclined to avoid retarding the adoption of OpenStack.  Is it possible to allow for some kind of interim usage in a way that allows for revisiting this later with folks already using \"certified\" and also closing the door on potential abusers in the short term?  We need to be shown taking some control of this, but I suspect that it will take a while for definitions.\n \n \nhanks,\n \n\n--Randy\n\nCo-Founder & CTO, Cloudscaling\n+1 (415) 787-2253 [78-SCALE for SMS or voice] \nTWITTER: twitter.com/randybias\nLINKEDIN: linkedin.com/in/randybias\n \n \n \n \n \nOn Oct 9, 2012, at 6:12 PM, Tristan Goode <tristan at aptira.com> wrote:\n\n\nDear Board,\n \nI am very concerned at the use of the word \"certified\" in recent media releases by Rackspace for their training offerings, and most recently in this mail out below.\n \nI\'ve no doubt Rackspace\'s course is worthy of being OpenStack certified when there is such a thing, but until there is formality around this then I do not believe anyone should use this word or any other word that implies endorsement from OpenStack even loosely (as this is in some contexts) to describe any commercial offering.\n \nWith no formal certification guidelines in place or policy on use of such words, this has a real danger of de-valuing the OpenStack brand if (when) less reputable organisations or basically anyone gratuitously use the word. My reading of media releases around this in the last few days is that media have picked up the Rackspace offering as OpenStack certified.\n \nAfter mentioning this to Jonathan several days ago to his credit \"certified\" was removed from parts of the Rackspace web site, but not all, and today this email below has gone out to the conference attendee list.\n \nAfter following up with Jonathan yesterday he advised:\n \n\'Theoretically, this has always been an allowed usage under the \"built for OpenStack\" license, which Rackspace among others has signed up for (http://www.openstack.org/brand/built-for-openstack-logo/). The requirement is to provide a clear indication that the product is a company\'s offering FOR OpenStack, not FROM OpenStack (i.e. Foundation).\'\n \nThis is far too loose and allows anyone use of such terms, the result is that OpenStack \"certified\" training soon means nothing.\n \nI\'m 100% for having officially certified courses asap. Perhaps a solution is that any company that wishes to have certified or official or similar (Rackspace, Hastexo, Mirantis immediately come to mind) submits their curriculum and clear deliverables to a review panel of some type drawn from the Membership? This would ensure that OpenStack people get training that they want and the certified term is used appropriately.\n \nUntil then statements like below should not be permissible and should probably be retracted. By acting on this decisively I see the Foundation truly protecting the brand that is OpenStack.\n \nI welcome your discussion.\n \nThanks\nTristan\n \n \n \n \n \n \nFrom: Rackspace - OpenStack Summit Sponsor [mailto:redcarpetevents at rackspace.com] \nSent: Wednesday, 10 October 2012 11:11 AM\nTo: tristan at aptira.com\nSubject: Launch Your Career Into The Clouds\n \nDear OpenStack Summit Attendee --\nRackspace has a lot going on during the upcoming OpenStack Summit and we hope you will join us for our lively- and always informative- conference sessions.\nKeynote and Sessions for Wednesday, October 17:\n9:30 a.m.\nKEYNOTE: Running the World\'s Largest Open Cloud (Troy Toman, Senior Director of Engineering for Cloud Compute)\n11:00 a.m.\nThis is Your Career. This is Your Career on OpenStack. (Niki Acosta, Product Evangelist)\n11:50 a.m.\nBig Data on OpenStack: A Rackspace Use Case (Natasha Gajic, Enterprise, Business Intelligence Lead)\nStop by the Rackspace booth to talk all things open cloud with our team of experts. And while you\'re there, learn how you can accelerate your career by becoming one of the first Certified OpenStack technicians. OpenStack public training classes are now posted at www.rackspacetraining.com. Certification exams begin in December so be sure to stop by the Rackspace booth to get more information.\nAnd of course it wouldn\'t be a Rackspace-sponsored summit without an evening of fun to top it all off...\nReach for the Clouds Rooftop Party\nTuesday October 16\n6:00 p.m. - 8:00 p.m. Altitude Sky Lounge\nRSVP NOW\nCatch a ride to the celebration via the complimentary Rackspace pedicabs outside the Hyatt from 5:45 p.m. - 6:45 p.m. or enjoy the short walk to the lounge located atop the Marriott Gaslamp.\nSee you soon,\nYour Friends At Rackspace\n--------------------------------------------------------------------------------\nThis email was sent to OpenStack Summit attendees by Rackspace, a sponsor of the event.\nIf you do not want to receive a handful of emails from the Summit organizers and sponsors this week, please click here to unsubscribe ( [unsubscribe] )\nRackspace - OpenStack Summit Sponsor\n5000 Walzem, San Antonio, TX, 78218\n_______________________________________________\nFoundation-board mailing list\nFoundation-board at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121011/7640ee84/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.gif\nType: image/gif\nSize: 43 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121011/7640ee84/attachment.gif>\n\n------------------------------\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\nEnd of Foundation Digest, Vol 11, Issue 8\n*****************************************\n\n\n',NULL,NULL),('<0a9feb2212c40694427d40b2b02ac0db@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 11:18:08',-21600,'2014-02-27 17:18:08',NULL,'[openstack-dev] packstack support for DRBD based installation',' \n\nOn 2014-02-26 16:52, Curious Human wrote: \n\n> Hi , \n> \n> We are using packstack based openstack installation. I am working on providing HA support for Openstack services and dependent 3rd part services like mysql etc . I will be using DRBD and pacemaker based HA functionality. \n> Is there any support for installing DRBD based installation using packstack , or is there any document suggesting how to do it ? \n> \n> Thanks in advance. \n> Rohit\n\nThis is a development list, and your question sounds more suited to the\nusers list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\nOr possibly rdo-list since you\'re using packstack:\nhttp://www.redhat.com/mailman/listinfo/rdo-list \n\nThanks. \n\n-Ben \n\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/97effe92/attachment.html>\n\n','<CAH08Zmb2PevyU=jghJkoah-7adcc1ZYCrgb_6K8A+BxX5nRARA@mail.gmail.com>',NULL),('<0AA24BC7-F932-4C24-BF8B-C105F3C4EA31@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 09:37:35',-28800,'2013-11-07 17:37:35',NULL,'[openstack-dev] Bad review patterns','Radomir,\nAn extra issue that i don\'t believe you\'ve covered so far is about comment ownership. I\'ve just read an email on the list that follows a pattern that i\'ve heard many complaints about:\n	-1 with a reasonable comment, submitter addresses the comment, reviewer never comes back.\n\nReviewers do need to allocate time to come back and follow up on the answers to their comments.\n\nPerhaps there is an issue with the incentive system. You can earn karma by doing a code review... certainly you want to incentivise developers that help the project by improving the code quality. But if the incentive system allows for \"drive by shooting\" code reviews that can be a problem.\n\nbtw: this is not at all exclusive to OpenStack. The issues you have pointed out exist for instance in code reviews inside company\'s proprietary code bases when different teams are involved. I\'m yet to see a perfect solution to the problem.\n\n  Pedro.\n\nOn Nov 7, 2013, at 3:02 AM, Radomir Dopieralski <openstack at sheep.art.pl> wrote:\n\n> On 06/11/13 09:34, Radomir Dopieralski wrote:\n>> Hello,\n>> \n>> I\'m quite new in the OpenStack project, but I love it already. What is\n>> especially nifty is the automated review system -- I\'m really impressed.\n>> I\'m coming from a project in which we also did reviews of every change\n>> -- although it was mostly manual, and just one review was enough to\n>> merge -- and at some point in that project I noticed that it is very\n>> easy to give reviews that are unhelpful, frustrating and just get in the\n>> way of the actual work. I started paying attention to how I am reviewing\n>> code, and I managed to come up with several patterns that are bad. Once\n>> I know the patterns, it\'s easier to recognize when I\'m doing something\n>> wrong and rethink the review. I would like to share the patterns that I\n>> noticed.\n> \n> I created a page on the wiki,\n> https://wiki.openstack.org/wiki/CodeReviewGuidelines\n> \n> I put some initial content there, based on the discussion in this\n> thread. Please feel free to discuss those points further here, and to\n> amend that page and add to it.\n> \n> Any ideas of where we could put a link to it? I\'m thinking about the\n> Gerrit Workflow page, maybe also some pages specific to particular teams\n> (I\'ve seen there is a page with review tips for Nova).\n> \n> -- \n> Radomir Dopieralski\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<527B7349.7050401@sheep.art.pl>',NULL),('<0AA6D37B-F825-448F-A494-0119F9AA1AF9@mirantis.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-07-16 23:59:24',14400,'2013-07-16 19:59:24',NULL,'[OpenStack-Infra] Savanna at pypi','Are there any thoughts about why incorrect version has been generated in jenkins? Maybe jenkins jobs for this tag should be just restarted?\n\nThank you!\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\nOn Jul 16, 2013, at 2:30, Sergey Lukjanov <slukjanov at mirantis.com> wrote:\n\n> It\'s very strange that incorrect version has been generated?\n> \n> It works correct for me:\n> \n> [/tmp] ?  git clone https://github.com/stackforge/savanna-dashboard.git                                                     [2:28:02]\n> Cloning into \'savanna-dashboard\'...\n> remote: Counting objects: 1083, done.\n> remote: Compressing objects: 100% (455/455), done.\n> remote: Total 1083 (delta 803), reused 876 (delta 620)\n> Receiving objects: 100% (1083/1083), 185.39 KiB | 175.00 KiB/s, done.\n> Resolving deltas: 100% (803/803), done.\n> [/tmp] ?  cd savanna-dashboard                                                                                              [2:28:10]\n> [/tmp/savanna-dashboard] ?  git checkout dbb57b098ad793c19d3544517377730d76e85b96                                  [master] [2:28:13]\n> Note: checking out \'dbb57b098ad793c19d3544517377730d76e85b96\'.\n> \n> You are in \'detached HEAD\' state. You can look around, make experimental\n> changes and commit them, and you can discard any commits you make in this\n> state without impacting any branches by performing another checkout.\n> \n> If you want to create a new branch to retain commits you create, you may\n> do so (now or later) by using -b with the checkout command again. Example:\n> \n>   git checkout -b new_branch_name\n> \n> HEAD is now at dbb57b0... Project name fixed\n> [/tmp/savanna-dashboard] ?  python setup.py sdist                                                                 [dbb57b0] [2:28:29]\n> running sdist\n> running egg_info\n> creating savanna_dashboard.egg-info\n> writing savanna_dashboard.egg-info/PKG-INFO\n> writing top-level names to savanna_dashboard.egg-info/top_level.txt\n> writing dependency_links to savanna_dashboard.egg-info/dependency_links.txt\n> writing manifest file \'savanna_dashboard.egg-info/SOURCES.txt\'\n> writing manifest file \'savanna_dashboard.egg-info/SOURCES.txt\'\n> warning: LocalSDist: standard file not found: should have one of README, README.rst, README.txt\n> \n> running check\n> creating savanna-dashboard-0.2\n> ...\n> hard linking tools/test-requires -> savanna-dashboard-0.2/tools\n> copying setup.cfg -> savanna-dashboard-0.2\n> Writing savanna-dashboard-0.2/setup.cfg\n> creating dist\n> Creating tar archive\n> removing \'savanna-dashboard-0.2\' (and everything under it)\n> [/tmp/savanna-dashboard] ?  ls -la dist                                                                           [dbb57b0] [2:28:40]\n> total 88\n> drwxr-xr-x   3 frostman  wheel    102 Jul 16 02:28 .\n> drwxr-xr-x  16 frostman  wheel    544 Jul 16 02:28 ..\n> -rw-r--r--   1 frostman  wheel  41463 Jul 16 02:28 savanna-dashboard-0.2.tar.gz\n> \n> Sincerely yours,\n> Sergey Lukjanov\n> Savanna Technical Lead\n> Mirantis Inc.\n> \n> On Jul 15, 2013, at 23:52, Sergey Lukjanov <slukjanov at mirantis.com> wrote:\n> \n>> I fix project name and push new tag, but now incorrect version has been generated for tarball :(\n>> \n>> https://jenkins.openstack.org/job/savanna-dashboard-tarball/7/\n>> \n>> But head is correct? HEAD is now at dbb57b0 Project name fixed\n>> https://github.com/stackforge/savanna-dashboard/commit/dbb57b0\n>> \n>> Sincerely yours,\n>> Sergey Lukjanov\n>> Savanna Technical Lead\n>> Mirantis Inc.\n>> \n>> On Jul 15, 2013, at 23:35, Monty Taylor <mordred at inaugust.com> wrote:\n>> \n>>> Done.\n>>> \n>>> On 07/15/2013 03:15 PM, Sergey Lukjanov wrote:\n>>>> Thank you!\n>>>> \n>>>> I have no permissions to delete reference :( Could you, please, remove tag?\n>>>> \n>>>> ?  git push gerrit :refs/tags/0.2                                                 \n>>>> remote: Processing changes: refs: 1, done\n>>>> To ssh://slukjanov at review.openstack.org:29418/stackforge/savanna-dashboard.git\n>>>> ! [remote rejected] 0.2 (can not delete references)\n>>>> error: failed to push some refs to \'ssh://slukjanov at review.openstack.org:29418/stackforge/savanna-dashboard.git\'\n>>>> \n>>>> Sincerely yours,\n>>>> Sergey Lukjanov\n>>>> Savanna Technical Lead\n>>>> Mirantis Inc.\n>>>> \n>>>> On Jul 15, 2013, at 20:46, Monty Taylor <mordred at inaugust.com> wrote:\n>>>> \n>>>>> I\'ve made the pypi project, so releasing will work now.\n>>>>> \n>>>>> To delete and re-create the tag (should be done only in rare\n>>>>> circumstances such as this)\n>>>>> \n>>>>> Do:\n>>>>> \n>>>>> git tag -d 0.2\n>>>>> git push gerrit :refs/tags/0.2\n>>>>> git tag -s 0.2\n>>>>> git push gerrit 0.2\n>>>>> \n>>>>> On 07/15/2013 11:57 AM, Sergey Lukjanov wrote:\n>>>>>> Savanna hosted in OpenStack pypi account, so, I have no access to it. The version tag has been already pushed to the repo, is it ok to commit correct project name and repush tag?\n>>>>>> \n>>>>>> Thank you!\n>>>>>> \n>>>>>> P.S. I\'m planning to move Savanna to pbr asap after this release :)\n>>>>>> \n>>>>>> Sincerely yours,\n>>>>>> Sergey Lukjanov\n>>>>>> Savanna Technical Lead\n>>>>>> Mirantis Inc.\n>>>>>> \n>>>>>> On Jul 15, 2013, at 19:34, Monty Taylor <mordred at inaugust.com> wrote:\n>>>>>> \n>>>>>>> Yes. Three things:\n>>>>>>> \n>>>>>>> a) change project=\'savannadashboard\' in your setup.py to\n>>>>>>> project=\'savanna-dashboard\'  (and then later we should pbr you)\n>>>>>>> \n>>>>>>> b) run \"python setup.py register\" to register the project on pypi\n>>>>>>> \n>>>>>>> c) go to pypi, log in, and add \'openstackci\' as an owner of the project\n>>>>>>> \n>>>>>>> At that point, releases should work.\n>>>>>>> \n>>>>>>> On 07/15/2013 11:11 AM, Rafael Folco wrote:\n>>>>>>>> Tarball name is different from what you have in the repo... not sure the\n>>>>>>>> reason though.\n>>>>>>>> \n>>>>>>>> I see a tarball without \"-\" at\n>>>>>>>> http://tarballs.openstack.org/savanna-dashboard/savannadashboard-0.2.tar.gz...\n>>>>>>>> \n>>>>>>>> and curl is trying to retrieve with savanna-dashboard (with \"-\")\n>>>>>>>> \n>>>>>>>> curl --fail -o savanna-dashboard-0.2.tar.gz http://tarballs.openstack.org/savanna-dashboard/savanna-dashboard-0.2.tar....gz <http://tarballs.openstack.org/savanna-dashboard/savanna-dashboard-0.2.tar...gz>\n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> On Mon, Jul 15, 2013 at 11:54 AM, Sergey Lukjanov\n>>>>>>>> <slukjanov at mirantis.com <mailto:slukjanov at mirantis.com>> wrote:\n>>>>>>>> \n>>>>>>>>  Hi Infra team,\n>>>>>>>> \n>>>>>>>>  today we released Savanna 0.2 version, but there are some problems\n>>>>>>>>  with uploading savanna-dashboard to pypi.\n>>>>>>>> \n>>>>>>>>  savanna-dashboard isn\'t uploaded to pypi at all :( It looks like\n>>>>>>>>  that it\'s no project create for it -\n>>>>>>>>  https://jenkins.openstack.org/job/savanna-dashboard-pypi-upload/1/console\n>>>>>>>> \n>>>>>>>>  Could you please help us?\n>>>>>>>> \n>>>>>>>>  Thank you.\n>>>>>>>> \n>>>>>>>>  Sincerely yours,\n>>>>>>>>  Sergey Lukjanov\n>>>>>>>>  Savanna Technical Lead\n>>>>>>>>  Mirantis Inc.\n>>>>>>>> \n>>>>>>>> \n>>>>>>>>  _______________________________________________\n>>>>>>>>  OpenStack-Infra mailing list\n>>>>>>>>  OpenStack-Infra at lists.openstack.org\n>>>>>>>>  <mailto:OpenStack-Infra at lists.openstack.org>\n>>>>>>>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> _______________________________________________\n>>>>>>>> OpenStack-Infra mailing list\n>>>>>>>> OpenStack-Infra at lists.openstack.org\n>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-Infra mailing list\n>>>>>>> OpenStack-Infra at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>>>>> \n>>>>>> \n>>>> \n>>>> \n>> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20130716/1b9ded92/attachment.html>\n\n','<5B6EBFB9-B557-4564-B676-24FC9B925B1B@mirantis.com>',NULL),('<0AA7FD91-9622-4CF8-83D8-BD889053D242@minuteware.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-17 23:08:11',7200,'2014-01-17 21:08:11',NULL,'[Openstack] How OpenStack projects codenames are chosen?','Hi!\n\nI\'m wondering what is the process of choosing a codename for an OpenStack project (I mean Nova, Glance etc.)? Is there a public/internal voting held or is it a decision of a project lead?\n\n---\nRegards,\nAndriy Yurchuk\n\n\n\n\n',NULL,NULL),('<0AAB4E48-98DD-48ED-A50B-681338178896@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-17 05:13:19',0,'2013-09-17 05:13:19',NULL,'[Openstack-docs] Use of XML xi:include with xpointer','i found this example on http://wiki.docbook.org/Using%20XInclude\n\n<xi:include href=\"path/to/source/file/source-docbook.xml\"\n             xmlns:xi=\"http://www.w3.org/2001/XInclude\"\n             xpointer=\"xpointer(//section[@id=\'IdOfTheSourceSection\']/title/following-sibling::*)\"/>\n\nmy version of this\n    <xi:include href=\"../install-guide/basic-install-files/basic-install_architecture.xml\"\n      xpointer=\"xpointer(//chapter[@id=\'basic-install_architecture\']/title/following-sibling::*)\"/>\n\nfails on build with same SEVERE: 100:40:err:XD0023:Expression could not be evaluated\n\nDavid and Shaun: Should we just dump trying to use xpointer and xpath?  I\'d really like to be able to include and parse content, but maybe this \"working draft\" isn\'t the way to go.\n\nShaun: should the training-guides just make it simple by using a solid release version of the install guide and scrape content while providing a backllink to the original?\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com> (925) 980-4729\n\nOn Sep 16, 2013, at 9:44 PM, Sean Roberts <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>>\n wrote:\n\nI was able to get <xi:include href=\"../install-guide/basic-install-files/basic-install_architecture.xml\" xpointer=\"xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = \'basic-install_architecture\'])\"> to work where the xml:id matches an xml:id in the included file.\n\nbut what I really like to do is something like\n<xi:include href=\"../install-guide/basic-install-files/basic-install_architecture.xml\" xpointer=\"xmlns(db=http://docbook.org/ns/docbook) xpath(//*[@xml:id = \'basic-install_architecture\']/*[not(self:db:chapter)])\">\n\nwhere I could include content, but strip out the source path hierarchy and replace it with new.\nThe reasoning is to change source chapters or sections into just raw content that could be inserted into an existing section or chapter.\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com> (925) 980-4729\n\nOn Aug 6, 2013, at 1:37 PM, David Cramer <david.cramer at rackspace.com<mailto:david.cramer at rackspace.com>> wrote:\n\nOn 08/06/2013 02:41 PM, Sean Roberts wrote:\noxygen is complaining about pointer scheme xpath is not supported and\nthat a well-formed document requires a root element\nmaven fails with expression could not be evaluated.\n\n<chapterxmlns=\"http://docbook.org/ns/docbook\"\n xmlns:xi=\"http://www.w3.org/2001/XInclude\"\n xmlns:xlink=\"http://www.w3.org/1999/xlink\"version=\"5.0\"\n xml:id=\"bk001-ch003-associate-general\">\n <title>Associate General</title>\n<xi:includehref=\"../basic-install/src/basic-install_controller-common.xml\"xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\nxpath(//*[@xml:id = \'controller-os\']/*[not(self::db::title)])\">\n\nOk, change self::db::title to self::db:title (just a single colon\nbetween the namespace prefix and the element name).\n\nYou will see that warning in Oxygen, but it\'s just a warning (not a\nvalidation error). This is because Oxygen doesn\'t recognize the xpointer\nschemes. I\'ll contact Oxygen to ask if they plan to add support for the\nxmlns and xpath schemes.\n\nBtw., it looks like the content you\'re including uses conditional\ntext/profiling. So you\'ll want to add to the configuration section of\nyour pom a param to indicate which profile you want (e.g. ubuntu).\nOtherwise you get all conditions:\n\n<profileOs>ubuntu</profileOs>\n\nDavid\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130917/1ed5c3eb/attachment.html>\n\n','<AB9897DC-0248-4643-8FD1-C8FC4CC8E608@yahoo-inc.com>',NULL),('<0AAF67CC-23D0-4605-84D9-EE5E68A5446D@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-03 20:40:50',-28800,'2013-03-04 04:40:50',NULL,'[openstack-dev] Client logging?','Recently I have been writing python scripts using the various openstack clients and I was wondering if any has been successful in getting there logging to work when using the clients in python vs using them via the cli.\n\nMaybe I am not doing it correctly, has anyone else managed this?\n\nSent from my really tiny device...\n\n',NULL,NULL),('<0AAFEE5F-26D2-48F8-887C-D0248919C86A@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 06:46:55',-25200,'2013-09-30 13:46:55',NULL,'[openstack-dev] [Swift] python-swiftclient 1.7.0 released','I tagged and released a new version of python-swiftclient this morning, specifically to get around some painful dependency issues (especially on older systems). Find the new version at https://pypi.python.org/pypi/python-swiftclient/1.7.0 on pypi. Below is the tag message:\n\nThis release is promted by a dependency change that should avoid\npainful dependency management issues. The main issue was the\nrequirement for d2to1. By removing it we resolve some issues related\nto upstream changes in distribute and pip, especially on older systems\n(see http://lists.openstack.org/pipermail/openstack-dev/2013-July/011425.html).\n\n\n--John\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130930/990451e1/attachment.pgp>\n\n',NULL,NULL),('<0AB243CE-3B22-478D-B05F-235A62BF60EC@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 14:19:29',-18000,'2014-01-09 19:19:29',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n	support','Ian,\n\nThe idea of pci flavors is a great and using vendor_id and product_id make sense, but I could see a case for adding the class name such as \'VGA compatible controller\'. Otherwise, slightly different generations of hardware will mean custom whitelist setups on each compute node.  \n\n01:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GTX] (rev a1)\n\nOn the flip side, vendor_id and product_id might not be sufficient.  Suppose I have two identical NICs, one for nova internal use and the second for guest tenants?  So, bus numbering may be required.  \n\n01:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GTX] (rev a1)\n02:00.0 VGA compatible controller: NVIDIA Corporation G71 [GeForce 7900 GTX] (rev a1)\n\nSome possible combinations:\n\n# take 2 gpus\npci_passthrough_whitelist=[\n	{ \"vendor_id\":\"NVIDIA Corporation G71\",\"product_id\":\"GeForce 7900 GTX\", \"name\":\"GPU\"},\n]\n\n# only take the GPU on PCI 2\npci_passthrough_whitelist=[\n	{ \"vendor_id\":\"NVIDIA Corporation G71\",\"product_id\":\"GeForce 7900 GTX\", \'bus_id\': \'02:\', \"name\":\"GPU\"},\n]\npci_passthrough_whitelist=[\n	{\"bus_id\": \"01:00.0\", \"name\": \"GPU\"},\n	{\"bus_id\": \"02:00.0\", \"name\": \"GPU\"},\n]\n\npci_passthrough_whitelist=[\n	{\"class\": \"VGA compatible controller\", \"name\": \"GPU\"},\n]\n\npci_passthrough_whitelist=[\n	{ \"product_id\":\"GeForce 7900 GTX\", \"name\":\"GPU\"},\n]\n\nI know you guys are thinking of PCI devices, but any though of mapping to something like udev rather than pci?  Supporting udev rules might be easier and more robust rather than making something up.\n\nBrian\n\n-------------------------------------------------\nBrian Schott, CTO\nNimbis Services, Inc.\nbrian.schott at nimbisservices.com\nph: 443-274-6064  fx: 443-274-6060\n\n\n\nOn Jan 9, 2014, at 12:47 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:\n\n> I think I\'m in agreement with all of this.  Nice summary, Robert.\n> \n> It may not be where the work ends, but if we could get this done the rest is just refinement.\n> \n> \n> On 9 January 2014 17:49, Robert Li (baoli) <baoli at cisco.com> wrote:\n> Hi Folks,\n> \n> \n> With John joining the IRC, so far, we had a couple of productive meetings in an effort to come to consensus and move forward. Thanks John for doing that, and I appreciate everyone\'s effort to make it to the daily meeting. Let\'s reconvene on Monday. \n> \n> But before that, and based on our today\'s conversation on IRC, I\'d like to say a few things. I think that first of all, we need to get agreement on the terminologies that we are using so far. With the current nova PCI passthrough\n> \n>         PCI whitelist: defines all the available PCI passthrough devices on a compute node. pci_passthrough_whitelist=[{\n>  \"vendor_id\":\"xxxx\",\"product_id\":\"xxxx\"}] \n>         PCI Alias: criteria defined on the controller node with which requested PCI passthrough devices can be selected from all the PCI passthrough devices available in a cloud. \n>                 Currently it has the following format: pci_alias={\"vendor_id\":\"xxxx\",\n>  \"product_id\":\"xxxx\", \"name\":\"str\"}\n>         \n>         nova flavor extra_specs: request for PCI passthrough devices can be specified with extra_specs in the format for example:\"pci_passthrough:alias\"=\"name:count\"\n> \n> As you can see, currently a PCI alias has a name and is defined on the controller. The implications for it is that when matching it against the PCI devices, it has to match the vendor_id and product_id against all the available PCI devices until one is found. The name is only used for reference in the extra_specs. On the other hand, the whitelist is basically the same as the alias without a name.\n> \n> What we have discussed so far is based on something called PCI groups (or PCI flavors as Yongli puts it). Without introducing other complexities, and with a little change of the above representation, we will have something like:\n>         \n> pci_passthrough_whitelist=[{ \"vendor_id\":\"xxxx\",\"product_id\":\"xxxx\",\n>  \"name\":\"str\"}] \n> \n> By doing so, we eliminated the PCI alias. And we call the \"name\" in above as a PCI group name. You can think of it as combining the definitions of the existing whitelist and PCI alias. And believe it or not, a PCI group is actually a PCI alias. However, with that change of thinking, a lot of benefits can be harvested:\n> \n>          * the implementation is significantly simplified\n>          * provisioning is simplified by eliminating the PCI alias\n>          * a compute node only needs to report stats with something like: PCI group name:count. A compute node processes all the PCI passthrough devices against the whitelist, and assign a PCI group based on the whitelist definition.\n>          * on the controller, we may only need to define the PCI group names. if we use a nova api to define PCI groups (could be private or public, for example), one potential benefit, among other things (validation, etc),  they can be owned by the tenant that creates them. And thus a wholesale of PCI passthrough devices is also possible.\n>          * scheduler only works with PCI group names. \n>          * request for PCI passthrough device is based on PCI-group\n>          * deployers can provision the cloud based on the PCI groups\n>          * Particularly for SRIOV, deployers can design SRIOV PCI groups based on network connectivities.\n> \n> Further, to support SRIOV, we are saying that PCI group names not only can be used in the extra specs, it can also be used in the ?nic option and the neutron commands. This allows the most flexibilities and functionalities afforded by SRIOV.\n> \n> Further, we are saying that we can define default PCI groups based on the PCI device\'s class.\n> \n> For vnic-type (or nic-type), we are saying that it defines the link characteristics of the nic that is attached to a VM: a nic that\'s connected to a virtual switch, a nic that is connected to a physical switch, or a nic that is connected to a physical switch, but has a host macvtap device in between. The actual names of the choices are not important here, and can be debated.\n> \n> I\'m hoping that we can go over the above on Monday. But any comments are welcome by email.\n> \n> Thanks,\n> Robert\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/b0d2c351/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 3662 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/b0d2c351/attachment.bin>\n\n','<CAPoubz7s2WHO7xor_9MwR12+cEZA6jy6jZJ4W5M=nC1AR=bGEw@mail.gmail.com>',NULL),('<0ABC295BE5E440168C9D4D58897D94C7@googlemail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-08-19 09:15:57',7200,'2011-08-19 07:15:57',NULL,'[Openstack-operators] Setting up Openstack Swift','Hello Marcelo,\nthat did it. Thank you very much.\nDavdi\n\n\n\n-- \nDavid Pusch\nSent with Sparrow (http://www.sparrowmailapp.com/?sig)\n\nOn Freitag, 19. August 2011 at 08:30, Marcelo Martins wrote:\n\n> Hi David,\n> \n> Yes, that would be the problem. I don\'t use tempauth at all, but on the proxy-server config you have the StorageUrl for the account set to \"https://10.10.50.200:8080/v1/AUTH_system\" .. So when you auth against swift, that\'s the storageUrl received back which is a private IP address. \n> \n> So you have 213.178.68.200 <- > 10.10.50.200 ... \n> You could try creating another admin account for external usage\n> \n> > > user_external_root = testpass .admin https://213.178.68.200:8080/v1/AUTH_external\n> \n> See if that works ! I think that is correct for tempauth.\n> \n> Try authenticating using curl first and make sure that the StorageURL returned will be reachable from your remote box. Then try using the swift tool.\n> \n> \n> \n> Marcelo Martins\n> Openstack-swift\n> btorch-os at zeroaccess.org (mailto:btorch-os at zeroaccess.org)\n> \n> ?Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. ?\n> \n> \n> \n> \n> On Aug 18, 2011, at 4:04 PM, David Pusch wrote:\n> > Hello Marcelo,\n> > It is not on the same network, but accesses the proxy through a router that has been natted to translate the external IP (213.178.68.200) to the internal one.\n> >  Could this be the root of the Problem?\n> > Regards,\n> > \n> > David Pusch\n> > From: Marcelo Martins\n> > Sent: 18.08.2011 22:30\n> > To: David Pusch\n> > Cc: openstack-operators at lists.openstack.org (mailto:openstack-operators at lists.openstack.org)\n> > Subject: Re: [Openstack-operators] Setting up Openstack Swift\n> > \n> > Hi David,\n> > \n> > is your remote client on the same 10.10.50.X network ? \n> > \n> > \n> > Marcelo Martins\n> > Openstack-swift\n> > btorch-os at zeroaccess.org (mailto:btorch-os at zeroaccess.org)\n> > \n> > ?Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. ? \n> > \n> > \n> > \n> > \n> > On Aug 18, 2011, at 9:25 AM, David Pusch wrote:\n> > > Hi,\n> > > the prior problem has been solved, I can start the proxy, and it works. But now I can\'t upload files from a remote client. Uploading from the proxy itself works fine when using \"sudo swift -A https://10.10.50.200:8080/auth/v1.0 -U system:root -K testpass download myfiles test100mb\", but wen doing the same from another server, it fails with the following message: [Errno 111] ECONNREFUSED\n> > > This is my current proxyserver.conf:\n> > > [DEFAULT]\n> > > cert_file = /etc/swift/cert.crt\n> > > key_file = /etc/swift/cert.key\n> > > bind_port = 8080\n> > > workers = 8\n> > > user = swift\n> > > \n> > > [pipeline:main]\n> > > pipeline = healthcheck cache tempauth proxy-server\n> > > \n> > > [app:proxy-server]\n> > > use = egg:swift#proxy\n> > > allow_account_management = true\n> > > \n> > > [filter:tempauth]\n> > > use = egg:swift#tempauth\n> > > user_system_root = testpass .admin https://10.10.50.200:8080/v1/AUTH_system\n> > > \n> > > [filter:healthcheck]\n> > > use = egg:swift#healthcheck\n> > > \n> > > [filter:cache]\n> > > use = egg:swift#memcache\n> > > memcache_servers = 10.10.50.200:11211 (http://10.10.50.200:11211/)\n> > > \n> > > Please tell me which logs would help you, and I shall provide them.\n> > > Regards\n> > > David\n> > > \n> > > \n> > > \n> > > \n> > > -- \n> > > David Pusch\n> > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)\n> > > \n> > > On Mittwoch, 17. August 2011 at 22:43, Marcelo Martins wrote:\n> > > \n> > > > Hi David, \n> > > > \n> > > > Please provide a bit more information. \n> > > > \n> > > > - What version of swift \n> > > > - proxy-server.conf \n> > > > - what do they logs show ? \n> > > > \n> > > > \n> > > > Marcelo Martins\n> > > > Openstack-swift\n> > > > btorch-os at zeroaccess.org (mailto:btorch-os at zeroaccess.org)\n> > > > \n> > > > ?Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. ?\n> > > > \n> > > > \n> > > > \n> > > > \n> > > > On Aug 16, 2011, at 4:45 AM, David Pusch wrote:\n> > > > \n> > > > > Hello all,\n> > > > > I\'m having a bit of a problem setting up a Swift Cluster. The base\n> > > > > system is Ubuntu 10.04, and I have followed the steps laid down in\n> > > > > http://swift.openstack.org/howto_installmultinode.html, but I seem to\n> > > > > have done something wrong. When I run swift-init proxy start it says\n> > > > > that it is starting the proxy and assigning a new pid, but when i\n> > > > >  ps/grep for it, nothing has happened. Also when I try to do the admin\n> > > > > test and run \"curl -k -v -H \'X-Storage-User: system:root\' -H\n> > > > > \'X-Storage-Pass: testpass\' https://$PROXY_LOCAL_NET_IP:8080/auth/v1.0\"\n> > > > >  it can\'t connect. Netstat also shows nothing listening on port 8080.\n> > > > > If anyone of you could make something of this and point me in the\n> > > > > right direction, I would be very grateful.\n> > > > > Regards\n> > > > > David\n> > > > > _______________________________________________\n> > > > >  Openstack-operators mailing list\n> > > > > Openstack-operators at lists.openstack.org (mailto:Openstack-operators at lists.openstack.org)\n> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> > > \n> > \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110819/274acb45/attachment-0001.html>\n\n','<A2D7541F-21E9-4B4D-B9F2-D94DCA503078@zeroaccess.org>',NULL),('<0ABE5AA2-D2AC-466F-8E84-8DF9D8EE5E30@rackspace.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-02-14 21:51:59',0,'2014-02-14 21:51:59',NULL,'[User-committee] Proposed “Application Development and Operations\" section for the User Survey','Hello User Committee,\n\nI propose we add a new section to the User Survey focused on application developers and operators simply titled ?Application Development and Operations\". This has already been discussed extensively [1] so nothing below should come as a surprise.\n\nOn the About You page [2] we update the \"What best describes your involvement with OpenStack?\" section as follows\n\n[ ] OpenStack cloud service provider - provides public or hosted private cloud services for other organizations\n[ ] Ecosystem vendor - provides software or solutions that enable others to build or run OpenStack clouds\n[ ] Private cloud operator - runs an OpenStack private cloud for their own organization\n[ ] Application developer - has API or dashboard credentials and deploys/maintains an application running on an OpenStack powered cloud\n[ ] Application operator - has API or dashboard credentials and develops an application running on an OpenStack powered cloud\n\nIf a respondent to the survey chooses either Application developer or Application operator, they are shown the ?Application Development and Operations? section. If their only selections are between Application developer or Application operator, they are not shown the Deployments section.\n\nBelow are the Q&A for the section. No questions are required. All answers are multi-select. The last answer is simply a text area for free form answers.\n\n1. What toolkits do you use or plan on using to interact with the OpenStack API?\n 1. deltacloud (HTTP API)\n 2. fog (Ruby)\n 3. jclouds (Java)\n 4. openstack.net (C#)\n 5. OpenStack clients (Python)\n 6. php-opencloud (PHP)\n 7. pkgcloud (Node.js)\n 8. Other (please specify)\n 9. None (wrote our own)\n\n2. If you wrote your own code for interacting with the OpenStack API, what programming language did you write it in?\n 1. C/C++\n 2. C#\n 3. Java\n 4. Node.js\n 5. Ruby\n 6. Perl\n 7. PHP\n 8. Python\n 9. Other (please specify)\n\n3. If you wrote your own code for interacting with the OpenStack API, what wire format are you using?\n 1. JSON\n 2. XML\n\n4. What development environment do you use or plan on using?\n 1. Eclipse or Eclipse based IDE\n 2. Intellij IDEA or IDEA based IDE\n 3. Sublime\n 4. Vim\n 5. Visual Studio\n 6. Other (please specify)\n\n5. What operating systems are you using or plan on using to develop/deploy your applications?\n  1. Linux \n  2. Mac OS X\n  3. Windows\n  4. Other (please specify)\n\n6. What tools are you using or plan on using to deploy/configure your applications?\n 1. Ansible\n 2. Chef\n 3. Cloud Foundry and/or BOSH\n 4. Docker\n 5. OpenStack Orchestration (Heat)\n 6. Puppet\n 7. SaltStack\n 8. Other (please specify)\n\n7. Share your thoughts with us on the state of applications on OpenStack. Here are some questions to consider:\n 1. What do you struggle with when developing and deploying applications on OpenStack? \n 2. What?s missing that would make your life easier?\n 3. Why did you choose a particular tool?\n 4. Why didn?t you choose a particular tool?\n\nText area for answers.\n\nThat?s everything for now. We hope to see this section in the next iteration of the User Survey. And we look forward to the aggregate answers!\n\nThanks,\nEverett\n\n\n[1] http://lists.openstack.org/pipermail/user-committee/2014-January/000208.html\n[2] https://www.openstack.org/user-survey/OrgInfo\n\n',NULL,NULL),('<0ABEDA5C-CCED-4D4E-8CDC-97A09C0BAC5B@cgoncalves.pt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 11:00:39',3600,'2014-06-18 10:00:39',NULL,'[openstack-dev] [Nova][neutron][NFV] Mid cycle sprints','I?ve added Joao Soares (Portugal Telecom) and myself (Instituto de Telecomunicacoes) to https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 for a Neutron and NFV meetup.\nPlease add yourselves as well so that we can have a better idea of who?s showing interest in participating.\n\nThanks,\nCarlos Goncalves\n\nOn 17 Jun 2014, at 18:20, Sylvain Afchain <sylvain.afchain at enovance.com> wrote:\n\n> Hi,\n> \n> +1 for Paris, since a mid-cycle sprint is already being hosted and organised by eNovance :)\n> \n> Sylvain\n> \n> ----- Original Message -----\n>> From: \"Dmitry\" <meytin at gmail.com>\n>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>> Sent: Sunday, June 15, 2014 3:40:43 PM\n>> Subject: Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints\n>> \n>> +1 for Paris/Lisbon\n>> \n>> On Sun, Jun 15, 2014 at 4:27 PM, Gary Kotton <gkotton at vmware.com> wrote:\n>>> \n>>> \n>>> On 6/14/14, 1:05 AM, \"Anita Kuno\" <anteaya at anteaya.info> wrote:\n>>> \n>>>> On 06/13/2014 05:58 PM, Carlos Gon?alves wrote:\n>>>>> Let me add to what I\'ve said in my previous email, that Instituto de\n>>>>> Telecomunicacoes and Portugal Telecom are also available to host and\n>>>>> organize a mid cycle sprint in Lisbon, Portugal.\n>>>>> \n>>>>> Please let me know who may be interested in participating.\n>>>>> \n>>>>> Thanks,\n>>>>> Carlos Goncalves\n>>>>> \n>>>>> On 13 Jun 2014, at 10:45, Carlos Gon?alves <mail at cgoncalves.pt> wrote:\n>>>>> \n>>>>>> Hi,\n>>>>>> \n>>>>>> I like the idea of arranging a mid cycle for Neutron in Europe\n>>>>>> somewhere in July. I was also considering inviting folks from the\n>>>>>> OpenStack NFV team to meet up for a F2F kick-off.\n>>>>>> \n>>>>>> I did not know about the sprint being hosted and organised by eNovance\n>>>>>> in Paris until just now. I think it is a great initiative from eNovance\n>>>>>> even because it?s not being focused on a specific OpenStack project.\n>>>>>> So, I\'m interested in participating in this sprint for discussing\n>>>>>> Neutron and NFV. Two more people from Instituto de Telecomunicacoes and\n>>>>>> Portugal Telecom have shown interested too.\n>>>>>> \n>>>>>> Neutron and NFV team members, who?s interested in meeting in Paris, or\n>>>>>> if not available on the date set by eNovance in other time and place?\n>>>>>> \n>>>>>> Thanks,\n>>>>>> Carlos Goncalves\n>>>>>> \n>>>>>> On 13 Jun 2014, at 08:42, Sylvain Bauza <sbauza at redhat.com> wrote:\n>>>>>> \n>>>>>>> Le 12/06/2014 15:32, Gary Kotton a ?crit :\n>>>>>>>> Hi,\n>>>>>>>> There is the mid cycle sprint in July for Nova and Neutron. Anyone\n>>>>>>>> interested in maybe getting one together in Europe/Middle East around\n>>>>>>>> the same dates? If people are willing to come to this part of the\n>>>>>>>> world I am sure that we can organize a venue for a few days. Anyone\n>>>>>>>> interested. If we can get a quorum then I will be happy to try and\n>>>>>>>> arrange things.\n>>>>>>>> Thanks\n>>>>>>>> Gary\n>>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> Hi Gary,\n>>>>>>> \n>>>>>>> Wouldn\'t it be more interesting to have a mid-cycle sprint *before*\n>>>>>>> the Nova one (which is targeted after juno-2) so that we could discuss\n>>>>>>> on some topics and make a status to other folks so that it would allow\n>>>>>>> a second run ?\n>>>>>>> \n>>>>>>> There is already a proposal in Paris for hosting some OpenStack\n>>>>>>> sprints, see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014\n>>>>>>> \n>>>>>>> -Sylvain\n>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> _______________________________________________\n>>>>>>>> OpenStack-dev mailing list\n>>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>> Neutron already has two sprints scheduled:\n>>>> https://wiki.openstack.org/wiki/Sprints\n>>> \n>>> Those sprints are both in the US. It is a very long way to travel. If\n>>> there are a group of people that can get together in Europe then it would\n>>> be great.\n>>> \n>>>> \n>>>> Thanks,\n>>>> Anita.\n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/7f92447c/attachment.html>\n\n','<26315869.1613603.1403025606312.JavaMail.zimbra@enovance.com>',NULL),('<0ac2e0c6.000016f8.00000222@munshed7.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 14:17:45',-28800,'2013-12-10 22:17:45',NULL,'[openstack-dev]  [nova]','Hello,\n\n \n\nI was wondering, what is the reason behind having nova audit resources as\nopposed to using usage stats directly from what is reported by the compute\ndriver. The available resources reported from the audit can be incorrect\nin some cases. Also, in many cases the reported usage stats from the\ndriver are correct, so auditing periodically while having the usage stats\nfrom the driver is inefficient. One of the which result in an incorrect\naudit is: existing VMs on a hypervisor that are created prior to deploying\nnova. As a result, the scheduler will see more available resources than\nwhat actually is available. I am aware that Nova shouldn\'t be managing VMs\nthat it hasn\'t created, but the reported available resources should be as\naccurate as possible. \n\n \n\nI have proposed the following blueprint to provide the option of using\nusage stats directly from the driver :\n\nhttps://blueprints.launchpad.net/nova/+spec/use-driver-usage-stats\n\n \n\nI would like to know what your thoughts are and would appreciate feedback.\n\n \n\nRegards,\n\nMaithem\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/58a31445/attachment-0001.html>\n\n',NULL,NULL),('<0AC7A1AE4CF0F441BFB83181010D122F299FF45F@fmsmsx115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 20:30:04',0,'2014-06-04 20:30:04',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Hi Brandon, hi Kyle!\nI\'m a bit confused about the deprecation (btw, thanks for sending this Brandon!), as I (wrongly) assumed #1 would be the chosen path for the new API implementation. I understand the proposal and #2 sounds actually cleaner. \n\nJust out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from Neutron?\n\n(Nit question, I must clarify)\n\nThank you!\nAndres\n\n-----Original Message-----\nFrom: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \nSent: Wednesday, June 04, 2014 2:18 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n\nThanks for your feedback Kyle.  I will be at that meeting on Monday.\n\nThanks,\nBrandon\n\nOn Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n> On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan \n> <brandon.logan at rackspace.com> wrote:\n> > This is an LBaaS topic bud I\'d like to get some Neutron Core members \n> > to give their opinions on this matter so I\'ve just directed this to \n> > Neutron proper.\n> >\n> > The design for the new API and object model for LBaaS needs to be \n> > locked down before the hackathon in a couple of weeks and there are \n> > some questions that need answered.  This is pretty urgent to come on \n> > to a decision on and to get a clear strategy defined so we can \n> > actually do real code during the hackathon instead of wasting some \n> > of that valuable time discussing this.\n> >\n> >\n> > Implementation must be backwards compatible\n> >\n> > There are 2 ways that have come up on how to do this:\n> >\n> > 1) New API and object model are created in the same extension and \n> > plugin as the old.  Any API requests structured for the old API will \n> > be translated/adapted to the into the new object model.\n> > PROS:\n> > -Only one extension and plugin\n> > -Mostly true backwards compatibility -Do not have to rename \n> > unchanged resources and models\n> > CONS:\n> > -May end up being confusing to an end-user.\n> > -Separation of old api and new api is less clear -Deprecating and \n> > removing old api and object model will take a bit more work -This is \n> > basically API versioning the wrong way\n> >\n> > 2) A new extension and plugin are created for the new API and object \n> > model.  Each API would live side by side.  New API would need to \n> > have different names for resources and object models from Old API \n> > resources and object models.\n> > PROS:\n> > -Clean demarcation point between old and new -No translation layer \n> > needed -Do not need to modify existing API and object model, no new \n> > bugs -Drivers do not need to be immediately modified -Easy to \n> > deprecate and remove old API and object model later\n> > CONS:\n> > -Separate extensions and object model will be confusing to end-users \n> > -Code reuse by copy paste since old extension and plugin will be \n> > deprecated and removed.\n> > -This is basically API versioning the wrong way\n> >\n> > Now if #2 is chosen to be feasible and acceptable then there are a \n> > number of ways to actually do that.  I won\'t bring those up until a \n> > clear decision is made on which strategy above is the most acceptable.\n> >\n> Thanks for sending this out Brandon. I\'m in favor of option #2 above, \n> especially considering the long-term plans to remove LBaaS from \n> Neutron. That approach will help the eventual end goal there. I am \n> also curious on what others think, and to this end, I\'ve added this as \n> an agenda item for the team meeting next Monday. Brandon, it would be \n> great to get you there for the part of the meeting where we\'ll discuss \n> this.\n> \n> Thanks!\n> Kyle\n> \n> > Thanks,\n> > Brandon\n> >\n> >\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1401902257.3955.0.camel@localhost>',NULL),('<0AC7A1AE4CF0F441BFB83181010D122F299FF7FD@fmsmsx115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 12:07:33',0,'2014-06-05 12:07:33',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Hi Brandon, thanks for your reply. Your explanation makes total sense to me. So, let\'s see what the consensus is. :)\n\nRegards and have a nice day!\nAndres\n\n-----Original Message-----\nFrom: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \nSent: Wednesday, June 04, 2014 6:28 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n\nHi Andres,\nI\'ve assumed (and we know how assumptions work) that the deprecation would take place in Juno and after a cyle or two it would totally be removed from the code.  Even if #1 is the way to go, the old /vips resource would be deprecated in favor of /loadbalancers and /listeners.\n\nI agree #2 is cleaner, but I don\'t want to start on an implementation (though I kind of already have) that will fail to be merged in because of the strategy.  The strategies are pretty different so one needs to be decided on.\n\nAs for where LBaaS is intended to end up, I don\'t want to speak for Kyle, so this is my understanding; It will end up outside of the Neutron code base but Neutron and LBaaS and other services will all fall under a Networking (or Network) program.  That is my understanding and I could be totally wrong.\n\nThanks,\nBrandon\n\nOn Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:\n> Hi Brandon, hi Kyle!\n> I\'m a bit confused about the deprecation (btw, thanks for sending this Brandon!), as I (wrongly) assumed #1 would be the chosen path for the new API implementation. I understand the proposal and #2 sounds actually cleaner. \n> \n> Just out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from Neutron?\n> \n> (Nit question, I must clarify)\n> \n> Thank you!\n> Andres\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n> Sent: Wednesday, June 04, 2014 2:18 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n> \n> Thanks for your feedback Kyle.  I will be at that meeting on Monday.\n> \n> Thanks,\n> Brandon\n> \n> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan \n> > <brandon.logan at rackspace.com> wrote:\n> > > This is an LBaaS topic bud I\'d like to get some Neutron Core \n> > > members to give their opinions on this matter so I\'ve just \n> > > directed this to Neutron proper.\n> > >\n> > > The design for the new API and object model for LBaaS needs to be \n> > > locked down before the hackathon in a couple of weeks and there \n> > > are some questions that need answered.  This is pretty urgent to \n> > > come on to a decision on and to get a clear strategy defined so we \n> > > can actually do real code during the hackathon instead of wasting \n> > > some of that valuable time discussing this.\n> > >\n> > >\n> > > Implementation must be backwards compatible\n> > >\n> > > There are 2 ways that have come up on how to do this:\n> > >\n> > > 1) New API and object model are created in the same extension and \n> > > plugin as the old.  Any API requests structured for the old API \n> > > will be translated/adapted to the into the new object model.\n> > > PROS:\n> > > -Only one extension and plugin\n> > > -Mostly true backwards compatibility -Do not have to rename \n> > > unchanged resources and models\n> > > CONS:\n> > > -May end up being confusing to an end-user.\n> > > -Separation of old api and new api is less clear -Deprecating and \n> > > removing old api and object model will take a bit more work -This \n> > > is basically API versioning the wrong way\n> > >\n> > > 2) A new extension and plugin are created for the new API and \n> > > object model.  Each API would live side by side.  New API would \n> > > need to have different names for resources and object models from \n> > > Old API resources and object models.\n> > > PROS:\n> > > -Clean demarcation point between old and new -No translation layer \n> > > needed -Do not need to modify existing API and object model, no \n> > > new bugs -Drivers do not need to be immediately modified -Easy to \n> > > deprecate and remove old API and object model later\n> > > CONS:\n> > > -Separate extensions and object model will be confusing to \n> > > end-users -Code reuse by copy paste since old extension and plugin \n> > > will be deprecated and removed.\n> > > -This is basically API versioning the wrong way\n> > >\n> > > Now if #2 is chosen to be feasible and acceptable then there are a \n> > > number of ways to actually do that.  I won\'t bring those up until \n> > > a clear decision is made on which strategy above is the most acceptable.\n> > >\n> > Thanks for sending this out Brandon. I\'m in favor of option #2 \n> > above, especially considering the long-term plans to remove LBaaS \n> > from Neutron. That approach will help the eventual end goal there. I \n> > am also curious on what others think, and to this end, I\'ve added \n> > this as an agenda item for the team meeting next Monday. Brandon, it \n> > would be great to get you there for the part of the meeting where \n> > we\'ll discuss this.\n> > \n> > Thanks!\n> > Kyle\n> > \n> > > Thanks,\n> > > Brandon\n> > >\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1401917272.3236.4.camel@localhost>',NULL),('<0AC7A1AE4CF0F441BFB83181010D122F299FFA02@fmsmsx115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 15:28:10',0,'2014-06-05 15:28:10',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Thanks, Kyle. Great.\n\n-----Original Message-----\nFrom: Kyle Mestery [mailto:mestery at noironetworks.com] \nSent: Thursday, June 05, 2014 11:27 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n\nOn Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan <brandon.logan at rackspace.com> wrote:\n> Hi Andres,\n> I\'ve assumed (and we know how assumptions work) that the deprecation \n> would take place in Juno and after a cyle or two it would totally be \n> removed from the code.  Even if #1 is the way to go, the old /vips \n> resource would be deprecated in favor of /loadbalancers and /listeners.\n>\n> I agree #2 is cleaner, but I don\'t want to start on an implementation \n> (though I kind of already have) that will fail to be merged in because \n> of the strategy.  The strategies are pretty different so one needs to \n> be decided on.\n>\n> As for where LBaaS is intended to end up, I don\'t want to speak for \n> Kyle, so this is my understanding; It will end up outside of the \n> Neutron code base but Neutron and LBaaS and other services will all \n> fall under a Networking (or Network) program.  That is my \n> understanding and I could be totally wrong.\n>\nThat\'s my understanding as well, I think Brandon worded it perfectly.\n\n> Thanks,\n> Brandon\n>\n> On Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:\n>> Hi Brandon, hi Kyle!\n>> I\'m a bit confused about the deprecation (btw, thanks for sending this Brandon!), as I (wrongly) assumed #1 would be the chosen path for the new API implementation. I understand the proposal and #2 sounds actually cleaner.\n>>\n>> Just out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from Neutron?\n>>\n>> (Nit question, I must clarify)\n>>\n>> Thank you!\n>> Andres\n>>\n>> -----Original Message-----\n>> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n>> Sent: Wednesday, June 04, 2014 2:18 PM\n>> To: openstack-dev at lists.openstack.org\n>> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n>>\n>> Thanks for your feedback Kyle.  I will be at that meeting on Monday.\n>>\n>> Thanks,\n>> Brandon\n>>\n>> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n>> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan \n>> > <brandon.logan at rackspace.com> wrote:\n>> > > This is an LBaaS topic bud I\'d like to get some Neutron Core \n>> > > members to give their opinions on this matter so I\'ve just \n>> > > directed this to Neutron proper.\n>> > >\n>> > > The design for the new API and object model for LBaaS needs to be \n>> > > locked down before the hackathon in a couple of weeks and there \n>> > > are some questions that need answered.  This is pretty urgent to \n>> > > come on to a decision on and to get a clear strategy defined so \n>> > > we can actually do real code during the hackathon instead of \n>> > > wasting some of that valuable time discussing this.\n>> > >\n>> > >\n>> > > Implementation must be backwards compatible\n>> > >\n>> > > There are 2 ways that have come up on how to do this:\n>> > >\n>> > > 1) New API and object model are created in the same extension and \n>> > > plugin as the old.  Any API requests structured for the old API \n>> > > will be translated/adapted to the into the new object model.\n>> > > PROS:\n>> > > -Only one extension and plugin\n>> > > -Mostly true backwards compatibility -Do not have to rename \n>> > > unchanged resources and models\n>> > > CONS:\n>> > > -May end up being confusing to an end-user.\n>> > > -Separation of old api and new api is less clear -Deprecating and \n>> > > removing old api and object model will take a bit more work -This \n>> > > is basically API versioning the wrong way\n>> > >\n>> > > 2) A new extension and plugin are created for the new API and \n>> > > object model.  Each API would live side by side.  New API would \n>> > > need to have different names for resources and object models from \n>> > > Old API resources and object models.\n>> > > PROS:\n>> > > -Clean demarcation point between old and new -No translation \n>> > > layer needed -Do not need to modify existing API and object \n>> > > model, no new bugs -Drivers do not need to be immediately \n>> > > modified -Easy to deprecate and remove old API and object model \n>> > > later\n>> > > CONS:\n>> > > -Separate extensions and object model will be confusing to \n>> > > end-users -Code reuse by copy paste since old extension and \n>> > > plugin will be deprecated and removed.\n>> > > -This is basically API versioning the wrong way\n>> > >\n>> > > Now if #2 is chosen to be feasible and acceptable then there are \n>> > > a number of ways to actually do that.  I won\'t bring those up \n>> > > until a clear decision is made on which strategy above is the most acceptable.\n>> > >\n>> > Thanks for sending this out Brandon. I\'m in favor of option #2 \n>> > above, especially considering the long-term plans to remove LBaaS \n>> > from Neutron. That approach will help the eventual end goal there. \n>> > I am also curious on what others think, and to this end, I\'ve added \n>> > this as an agenda item for the team meeting next Monday. Brandon, \n>> > it would be great to get you there for the part of the meeting \n>> > where we\'ll discuss this.\n>> >\n>> > Thanks!\n>> > Kyle\n>> >\n>> > > Thanks,\n>> > > Brandon\n>> > >\n>> > >\n>> > >\n>> > >\n>> > >\n>> > >\n>> > > _______________________________________________\n>> > > OpenStack-dev mailing list\n>> > > OpenStack-dev at lists.openstack.org \n>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >\n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi3Ta3CAjczTCd6HKs=pNYrT5jJ=Fc15=6fnBfgveL1OKw@mail.gmail.com>',NULL),('<0AC7A1AE4CF0F441BFB83181010D122F29A01A21@fmsmsx115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 20:34:59',0,'2014-06-10 20:34:59',NULL,'[openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal','Hi, we have been struggling with getting a meaningful set of metrics from LB stats thru ceilometer, and from a discussion about module responsibilities for providing data, an interesting idea came up. (Thanks Pradeep!)\nThe proposal is to consolidate some kinds of metrics as pool up time (hours) and average or historic response times of VIPs and listeners, to avoid having ceilometer querying for the state so frequently. There is a trade-off between fast response time (high sampling rate) and reasonable* amount of cumulative samples.\nThe next step in order to give more detail to the idea is to work on a use cases list to better explain / understand the benefits of this kind of data grouping.\n\nWhat dou you think about this?\nDo you find it will be useful to have some processed metrics on the loadbalancer side instead of the ceilometer side?\nDo you identify any measurements about the load balancer that could not be obtained/calculated from ceilometer?\nPerhaps this could be the base for other stats gathering solutions that may be under discussion?\n\nAndres\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/3bb494c4/attachment.html>\n\n',NULL,NULL),('<0AC7A1AE4CF0F441BFB83181010D122F29A06983@fmsmsx115.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 15:06:05',0,'2014-06-16 15:06:05',NULL,'[openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal','Hi Jorge, thanks for your reply! You are right about summarizing too much. The idea is to identify which kinds of data could be retrieved in a summarized way without losing detail (i.e.: uptime can be better described with start-end timestamps than with lots of samples with up/down status) or simply to provide different levels of granularity and let the user decide (yes, it can be sometimes dangerous).\nHaving said this, how could we share the current metrics intended to be exposed? Is there a document or should I follow the \"Requirements around statistics and billing\" thread?\n\nThank you!\nAndres\n\nFrom: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]\nSent: Thursday, June 12, 2014 6:35 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal\n\nHey Andres,\n\nIn my experience with usage gathering consolidating statistics at the root layer is usually a bad idea. The reason is that you lose potentially useful information once you consolidate data. When it comes to troubleshooting issues (such as billing) this lost information can cause problems since there is no way to \"replay\" what had actually happened. That said, there is no free lunch and keeping track of huge amounts of data can be a huge engineering challenge. We have a separate thread on what kinds of metrics we want to expose from the LBaaS service so perhaps it would be nice to understand these in more detail.\n\nCheers,\n--Jorge\n\nFrom: <Buraschi>, Andres <andres.buraschi at intel.com<mailto:andres.buraschi at intel.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, June 10, 2014 3:34 PM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: [openstack-dev] [Neutron][LBaaS] Consolidated metrics proposal\n\nHi, we have been struggling with getting a meaningful set of metrics from LB stats thru ceilometer, and from a discussion about module responsibilities for providing data, an interesting idea came up. (Thanks Pradeep!)\nThe proposal is to consolidate some kinds of metrics as pool up time (hours) and average or historic response times of VIPs and listeners, to avoid having ceilometer querying for the state so frequently. There is a trade-off between fast response time (high sampling rate) and reasonable* amount of cumulative samples.\nThe next step in order to give more detail to the idea is to work on a use cases list to better explain / understand the benefits of this kind of data grouping.\n\nWhat dou you think about this?\nDo you find it will be useful to have some processed metrics on the loadbalancer side instead of the ceilometer side?\nDo you identify any measurements about the load balancer that could not be obtained/calculated from ceilometer?\nPerhaps this could be the base for other stats gathering solutions that may be under discussion?\n\nAndres\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/fda11eca/attachment.html>\n\n','<CFBF85E7.12DF5%jorge.miramontes@rackspace.com>',NULL),('<0AC881639BF225468258D8D5044F979611AB28BA@BL2PRD0310MB350.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/community',NULL,'2012-08-02 14:46:27',0,'2012-08-02 14:46:27',NULL,'[Community] Cannot pass hint to Nova Scheduler','Hi folks:\nI am new to openstack, I am current trying to test the json filter, I changed my /etc/nova/nova.conf as follow\n\nscheduler_driver=nova.\nscheduler.multi.MultiScheduler\ncompute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\nvolume_scheduler_driver=nova.scheduler.chance.ChanceScheduler\nscheduler_available_filters=nova.scheduler.filters.standard_filters\nscheduler_default_filters=JsonFilter\nleast_cost_functions=nova.scheduler.least_cost.compute_fill_first_cost_fn\ncompute_fill_first_cost_fn_weight=-1.0\n\n\nso I can use the json filter\nhowever, when I was using it, if I boot a vm without any --hint to the scheduler, then the vm started fine, but if I use\n\nnova --debug boot --image 827d564a-e636-4fc4-a376-\nd36f7ebe1747 --flavor 1 --hint query=[\'>=\',\'$free_ram_mb\',1024] server1\n\nmy vm started with error, and the following were output from the command above\n\n+-----------------------------\n--------+--------------------------------------+\n| Property                            | Value                                |\n+-------------------------------------+--------------------------------------+\n| OS-DCF:diskConfig                   | MANUAL                               |\n| OS-EXT-SRV-ATTR:host                | None                                 |\n| OS-EXT-SRV-ATTR:hypervisor_hostname | None                                 |\n| OS-EXT-SRV-ATTR:instance_name       | instance-0000002b                    |\n| OS-EXT-STS:power_state              | 0                                    |\n| OS-EXT-STS:task_state               | scheduling                           |\n| OS-EXT-STS:vm_state                 | error                                |\n| accessIPv4                          |                                      |\n| accessIPv6                          |                                      |\n| adminPass                           | dKvrsv4MZtfc                         |\n| config_drive                        |                                      |\n| created                             | 2012-08-02T14:25:10Z                 |\n| flavor                              | m1.tiny                              |\n| hostId                              |                                      |\n| id                                  | 9d4a5855-3c69-40ba-b50d-3a2aa6a92edc |\n| image                               | cirros-0.3.0-x86_64-uec              |\n| key_name                            |                                      |\n| metadata                            | {}                                   |\n| name                                | server1                              |\n| progress                            | 0                                    |\n| status                              | BUILD                                |\n| tenant_id                           | d99ffa1b0c43455ab8dbbd81cf4380a7     |\n| updated                             | 2012-08-02T14:25:10Z                 |\n| user_id                             | d5e02f1810a44575b99a147f94507da1     |\n+-------------------------------------+--------------------------------------+\n\nas you can see, the vm is in error, this also happens whenever I need to pass a hint to the scheduler, as in samehostfilter and differenthostfilter,\n\nDoes anyone know what\'s going on, thanks in advance.\nHeng\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120802/b857a07b/attachment.html>\n\n',NULL,NULL),('<0ACF3416-3C73-4DAD-9CB6-7C85B3BE6EE2@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-23 17:19:41',-14400,'2014-10-23 21:19:41',NULL,'[openstack-dev] [oslo] python 2.6 support for oslo libraries','\nOn Oct 23, 2014, at 12:30 PM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:\n\n> On Thu, 2014-10-23 at 18:56 +0300, Andrey Kurilin wrote:\n>> Just a joke: Can we drop supporting Python 2.6, when several project\n>> still have hooks for Python 2.4?\n>> \n>> https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203\n>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155\n> \n> It may have been intended as a joke, but it\'s worth pointing out that\n> the Xen plugins for nova (at least) have to be compatible with Python\n> 2.4, because they run on the Xenserver, which has an antiquated Python\n> installed :)\n> \n> As for the clients, we could probably drop that segment now; it\'s not\n> like we *test* against 2.4, right?  :)\n\nI?m not aware of any Oslo code that presents a problem for those plugins. We wouldn?t want to cause a problem, but as you say, we don?t have anywhere to test 2.4 code. Do you know if the Xen driver uses any of the Oslo code?\n\nDoug\n\n\n\n','<1414081804.3248.2.camel@einstein.kev>',NULL),('<0ad9013d-3a9f-472a-a8f3-d38db78df060@zimbra>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-30 09:21:16',3600,'2013-10-30 08:21:16',NULL,'[Openstack-operators] Image rootfs-resize tool, updated','Yes I can see usefulness of you suggestion. Will look into it if I can come up with some simple solution.\n\n- Robert\n\n----- Original Message -----\nFrom: \"Joe Topjian\" <joe.topjian at cybera.ca>\nTo: \"Robert Plestenjak\" <robert.plestenjak at xlab.si>\nCc: openstack-operators at lists.openstack.org\nSent: Tuesday, October 29, 2013 4:05:55 PM\nSubject: Re: [Openstack-operators] Image rootfs-resize tool, updated\n\n\nNice - thanks! \n\n\nJust thinking out loud (I haven\'t looked into this yet), but is it possible to add a tool like this as a hook every time a new kernel is installed? \n\n\nI have a grow-able CentOS image and what I\'ve found is that users will create a CentOS instance, update all packages (including the kernel), and then create a personal snapshot of the result. When they launch a new instance based on their snapshot, the root disk is not the correct size. \n\n\nThe workaround is to boot with the original kernel either one time or permanently. \n\n\nThinking out loud again: this is one of those issues that might seem small in grand scope of things, but very big from a support / front-line perspective... \n\n\n\n\n\n\n\nOn Tue, Oct 29, 2013 at 8:43 AM, Robert Plestenjak < robert.plestenjak at xlab.si > wrote: \n\n\nHello, \n\nI have reworked my previous tool I\'ve made for CentOS. New tool supports CentOS, Debian 6 and Debian 7, other distros can be added without much work (I hope). \n\nAs before, LVM is not supported (yet), but I\'m working on it(TM). \n\nhttps://github.com/flegmatik/linux-rootfs-resize.git \n\n- Robert \n\n_______________________________________________ \nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n\n\n\n-- \n\nJoe Topjian \nSystems Architect \nCybera Inc. \n\n\nwww.cybera.ca \n\n\nCybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. \n\n\n','<CAD07=DexfPs1Yb7AVptgQvLW4JJjY7h7bjpuSCw5qexUnrpq6A@mail.gmail.com>',NULL),('<0ADC2362-7FD6-4B06-93C2-5D1B828D4356@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-07-25 16:30:03',-14400,'2013-07-25 20:30:03',NULL,'[openstack-hpc] Looking for practical Openstack + Ceph guidance\n	for shared HPC','Joshua,\n\nIt is something those of us working the gap between HPC and cloud have struggled with.  We lack a strong project team within OpenStack IMHO, although there are several small groups doing HPC with OpenStack.  Hopefully others will chime in on some other topics, such as Infiniband support, but we did some testing with a GRID K2 card for GPU pass-through with different hypervisors.  A talk I gave at the OpenStack DC meetup is here:\nhttp://www.slideshare.net/bfschott/nimbis-schott-openstackgpustatus20130618\n\nThe short GPU answer is that it is possible with Xen, XenCenter, and XCP to passthrough GPUs today, but OpenStack doesn\'t have support by default in Nova.  This is still in a roll-your-own mode for deployment.\n\nBrian\n\n-------------------------------------------------\nBrian Schott, CTO\nNimbis Services, Inc.\nbrian.schott at nimbisservices.com\nph: 443-274-6064  fx: 443-274-6060\n\n\n\nOn Jul 25, 2013, at 4:06 PM, Joshua Dotson <josh at knoesis.org> wrote:\n\n> Hello.\n> \n> A contingent of my organization, the Kno.e.sis Center @ Wright State University, recently received a grant award which we intend to use to support a handful of mid-size HPC-style workloads (MPI <-- definitely, GPGPU <-- if possible/plausible) in addition to many mid-size IaaS-style workloads (MongoDB, Storm, Hadoop, many others).  As a third layer, I\'m playing with the idea of evaluating an elastic OpenShift Origin atop the same infrastructure.  Approximately $400k to $500k will hopefully be available for this deployment, though exact numbers are not yet available to me.  \n> \n> While I\'m prepared to build a home-grown small-to-mid-size \"classical\" HPC, using modern hardware, and a smaller silo for home-grown Openstack for the minority stakeholders, I am hoping to find ways of making proponents of both workloads simultaneously happy, or close to it.  That is, I would like to give my computer scientist users a friendly method of running their HPC-style jobs on a combined performance-tuned silo of Openstack.  Doing so would load-balance the procured hardware and infrastructure with the users who want a Tomcat or a Virtuoso instance.\n> \n> I see a number of serious issues realizing such a goal.  For example, the state of Infiniband vs. Openstack seems not quite ready/available/documented/accessible for such use in production, unless I\'m just blind to the right blogs.  The added myriad abstractions and latency virtualization might impose on an HPC task, not to mention cloud software defined networking (Quantum, especially when sans hardware acceleration), seem likely to really get in the way of practicality, economics and efficiency.  That said, most of what we do here isn\'t HPC, so I believe such trade-offs can be agreed upon, if a reasonable job scheduling and workload management mechanism can be found and agreed upon by all stake holders, grant proposal majority (HPC) and minority (IaaS) alike.  \n> \n> I get the impression from my readings that HPC-style deployment (separate from job queuing) against the EC2 API should work.  I don\'t have a good feeling that the experience would be particularly friendly, however, without paying for closed source applications.  I\'m thinking a high-performance Ceph install would help bring up the storage end of things in a modern open-source CoTS way.  I\'ve not done specific research on Lustre + Openstack, but no reports of such a setup have presented themselves to me, either.\n> \n> These blue sky ideas matter nil, it seems, if a sufficiently-large high-performance production-quality Openstack deployment is beyond the funds to be allotted, which is something else I\'m working on.  I\'ve built smallish but useful virt-manager, oVirt and Openstack environments here already, but none of them are enough for the very-important HPC job proposed for this grant.  The scientist running the proposed computation gave me following information to clarify what would parity (for his job only) his experience running the computation with an external HPC service provider.\n> MPI\n> 20 Gbps Infiniband compute interconnect\n> 600 cores (those currently used are probably G4 Opteron 2.4 Ghz)\n> 4 GB RAM per core\n> at lest 2 TB shared storage, though I\'m thinking we need much more for use by our general community\n> unsure of the storage networking topology\n> We\'re in the shopping phase for this grant award and are still playing with ideas.  It seems likely to snap back into an old-school HPC, at this time.  I\'ve fielded communication about our needs to a number of Openstack and hardware providers, on the hope that they can bring something helpful to the table.\n> Please let know if you can point me in the right direction(s). I\'m up to reading whatever text is thrown at me on this topic.  :-)\n> \n> Thanks,\n> Joshua\n> -- \n> Joshua M. Dotson\n> Systems Administrator\n> Kno.e.sis Center\n> Wright State University - Dayton, OH\n> _______________________________________________\n> OpenStack-HPC mailing list\n> OpenStack-HPC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20130725/deebf568/attachment.html>\n\n','<CANLzmLiAvU3srJjkr6zMi5n9+y4B2e9+UN_NL_3bK2rWObb4Kw@mail.gmail.com>',NULL),('<0ADD04A8-2AB2-4711-854E-21B819247F49@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 16:02:18',0,'2014-01-18 16:02:18',NULL,'[openstack-dev] [Diesel] Proposal for new project','Rob,\n\nPlease contact me, You have completely misunderstood the Solum project.\n\nThanks,\n\nAdrian\n\nOn Jan 17, 2014, at 9:31 PM, \"Raymond, Rob\" <rob.raymond at hp.com>\n wrote:\n\n> \n> Hi Raj\n> \n> As I see it, Solum is a set of utilities aimed at developers to use\n> OpenStack clouds but will not be part of OpenStack proper.\n> While Diesel is meant to be a service that is provided by an OpenStack\n> cloud (and at some point becoming part of OpenStack itself). It defines a\n> contract and division of responsibility between developer and cloud.\n> \n> Rob\n> \n> -------- Original message --------\n> From: Rajesh Ramchandani\n> Date:01/17/2014 8:04 PM (GMT-08:00)\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> Cc: openstack-dev at lists.openstack.org\n> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n> Subject: Re: [openstack-dev] [Diesel] Proposal for new project\n> \n> Hi Rob - there seems be overlap with project Solum. Can you please outline\n> high level differences between Diesel and Solum?\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CEFF5FD1.22F4%rob.raymond@hp.com>',NULL),('<0AF99AF1-70ED-42ED-B58A-6046BF85BC28@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 14:59:31',14400,'2014-02-20 10:59:31',NULL,'[openstack-dev] [savanna] Nominate Andrew Lazarew for\n	savanna-core','+1\n\nRegards,\nAlexander Ignatov\n\n\n\nOn 20 Feb 2014, at 03:02, John Speidel <jspeidel at hortonworks.com> wrote:\n\n> +1 \n> Andrew would be a good addition.\n> \n> -John\n> \n> \n> \n> \n> On Wed, Feb 19, 2014 at 5:40 PM, Sergey Lukjanov <slukjanov at mirantis.com> wrote:\n> Hey folks,\n> \n> I\'d like to nominate Andrew Lazarew (alazarev) for savanna-core.\n> \n> He is among the top reviewers of Savanna subprojects. Andrew is working on Savanna full time since September 2013 and is very familiar with current codebase. His code contributions and reviews have demonstrated a good knowledge of Savanna internals. Andrew have a valuable knowledge of both core and EDP parts, IDH plugin and Hadoop itself. He\'s working on both bugs and new features implementation.\n> \n> Some links:\n> \n> http://stackalytics.com/report/reviews/savanna-group/30\n> http://stackalytics.com/report/reviews/savanna-group/90\n> http://stackalytics.com/report/reviews/savanna-group/180\n> https://review.openstack.org/#/q/owner:alazarev+savanna+AND+-status:abandoned,n,z\n> https://launchpad.net/~alazarev\n> \n> Savanna cores, please, reply with +1/0/-1 votes.\n> \n> Thanks.\n> \n> -- \n> Sincerely yours,\n> Sergey Lukjanov\n> Savanna Technical Lead\n> Mirantis Inc.\n> \n> \n> CONFIDENTIALITY NOTICE\n> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You._______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/55f9b15d/attachment.html>\n\n','<CACo3+3TUr2aCOGeaVmyEjD2oE84K5FGB59fAm=WddugdFpce3Q@mail.gmail.com>',NULL),('<0B00AFFEED664443A3946C55C0884F14@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 09:57:53',3600,'2014-02-24 08:57:53',NULL,'[openstack-dev] [Neutron] \"Auto-created ports count against port\n quota\" bug status','Hello all, \n\nI have the following bug assigned for icehouse~3 milestone: https://bugs.launchpad.net/neutron/+bug/1212338\n\nI proposed a (maybe too much) trivial solution in the launchpad comments, but I haven\'t received a confirmation that solution would solve the issue. Could a more experienced neutron developer confirm me that is the path to follow or propose another one, please?\n\nThanks!\n-- \nJaume Devesa\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/6e635bdd/attachment.html>\n\n',NULL,NULL),('<0b0201cde277$48cdb9c0$da692d40$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-25 12:10:20',14400,'2012-12-25 08:10:20',NULL,'[openstack-dev] [quantum][LBaaS] need to do\n	corresponding	changes in LBaaS API doc','Hi Youcef,\n\n \n\nI think that tenant_id should be present in every resource and sub-resource\nas it is verified by framework for any API call - so for creating a\nsub-resource too.\n\nI \'ve also looked through the updated API doc and still think we should add\n\"health_monitors\" to the list of updatable attributes of a pool. What do you\nthink?\n\n \n\nThanks,\n\nOleg\n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Tuesday, December 25, 2012 7:54 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding\nchanges in LBaaS API doc\n\n \n\nThanks Oleg. For associating a health monitor with pool with this call.\n\n \n\nPOST pools/<pool_id>/health_monitors\n\n{\n\n                \'id\': <health_monitor_id>,\n\n                \'tenant_id\': <tenant_id>\n\n}\n\n \n\nI believe the \"tenant_id\" in the request body is not needed, since both the\npool and the health monitor are already created. What do you think?\n\n \n\nYoucef\n\n \n\n \n\n \n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Saturday, December 22, 2012 5:29 AM\nTo: \'OpenStack Development Mailing List\'\nSubject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding\nchanges in LBaaS API doc\n\n \n\nHi Oleg,\n\n \n\nThanks, I have reviewed these, and require some clarification from you.\n\n \n\n-          add default values for fields not specified while VIP creation\n\n \n\nDo you mean \"description\" and \"connection_limit\" fields? For \"description\",\nthe default value if not specified by the user is an empty string, while\n\"connection_limit\" if not specified by the user is not used (internally and\nin DB, you can store it as \"-1\" meaning there is no connection limit). \n\n[obondarev] Agree\n\n \n\n-          add \"description\" and \"connection_limit\" fields with default\nvalues to the response of Create VIP Example\n\n \n\nIn the response, if description is an empty string and if \"connection_limit\"\nis set to -1, we do not return them, as it means the user has not set these,\nand they have got a NULL value.\n\n[obondarev] Agree\n\n \n\n-          add \"lb_method\" field to the request of Create Pool Example as it\nis required\n\n \n\nYes, good catch! I\'ll add this.\n\n \n\n-          remove \"members\" filed from the request of Create Pool Example\n\n-          add \"health_monitors\" to the list of updatable attributes of a\npool\n\n-          remove \"List all Members of a specific Pool\" and \"List Health\nMonitors associated with a Pool\" REST calls from the API\n\n \n\nYes, since we have agreed now on an approach for dealing with sub-resources,\nI can now update the spec.\n\n \n\n-          add \"pool_id\" to the must list when creating a member\n\nYep.\n\n \n\n-          add appropriate values to the request of Associate Health\nMonitors with a Pool Example\n\n \n\nI thought that associating/dissociating pools and health_monitors is now\ndone when creating or updating a pool (by specification a collection\nattribute). Can you clarify for me what the current implementation does?\n\n[obondarev] It\'s true but we also still have an opportunity to\nassociate/disassociate monitors with pools using sub-resource concept: \n\nPOST pools/<pool_id>/health_monitors {body}\n\nDELETE pools/<pool_id>/health_monitors/<health_monitor_id>\n\nWhere body is:\n\n{\n\n                \'id\': <health_monitor_id>,\n\n                \'tenant_id\': <tenant_id>\n\n}\n\n- to add one monitor to a pool - this avoids user from doing two roundtrips\nwhere he needs first to do GET and then PUT on a pool resource.\n\n \n\nThanks\n\nYoucef \n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Thursday, December 20, 2012 1:49 AM\nTo: Youcef Laribi; \'OpenStack Development Mailing List\'\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do corresponding\nchanges in LBaaS API doc\n\n \n\nSure Youcef, here\'s the list of updates:\n\n \n\n-          add default values for fields not specified while VIP creation\n\n-          add \"description\" and \"connection_limit\" fields with default\nvalues to the response of Create VIP Example\n\n-          add \"lb_method\" field to the request of Create Pool Example as it\nis required\n\n-          remove \"members\" filed from the request of Create Pool Example\n\n-          add \"health_monitors\" to the list of updatable attributes of a\npool\n\n-          remove \"List all Members of a specific Pool\" and \"List Health\nMonitors associated with a Pool\" REST calls from the API\n\n-          add \"pool_id\" to the must list when creating a member\n\n-          add appropriate values to the request of Associate Health\nMonitors with a Pool Example\n\n \n\nThanks,\n\nOleg\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com] \nSent: Wednesday, December 19, 2012 11:42 PM\nTo: Oleg Bondarev; OpenStack Development Mailing List\nSubject: RE: [openstack-dev][quantum][LBaaS] need to do carresponding\nchanges in LBaaS API doc\n\n \n\nOleg,\n\n \n\nCan you outline what those changes are?\n\n \n\nThanks,\n\nYoucef\n\n \n\nFrom: Oleg Bondarev [mailto:obondarev at mirantis.com] \nSent: Wednesday, December 19, 2012 5:39 AM\nTo: Youcef Laribi; OpenStack Development Mailing List\nSubject: [openstack-dev][quantum][LBaaS] need to do carresponding changes in\nLBaaS API doc\n\n \n\nHi Youcef,\n\n \n\nNow after LBaaS API extension patch was merged we need to do several\ncorresponding changes in the API doc. \n\nI can do it if you provide me rights on editing the page\n(http://wiki.openstack.org/Quantum/LBaaS/API_1.0).\n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121225/ef8432dc/attachment.html>\n\n','<7B14C05615DB43488B85E143995BD549010A5B16FB4A@LONPMAILBOX01.citrite.net>',NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A48F5DFB4B@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-22 14:16:15',-14400,'2013-05-22 18:16:15',NULL,'[openstack-dev] [Swift] Isilon support feedback','Hi all,\n\nI wanted to get some feedback about the best way to implement support for Isilon storage clusters within Swift. I\'ve taken the Swift code and hacked on it a bit to build a prototype that works with Isilon, but I don\'t think that my changes would make sense to integrate into the main Swift codebase because they are very much hack-ish/prototype-ish changes and even if they weren\'t they would be very specific to the needs of an Isilon device and as such probably wouldn\'t make sense to someone not using an Isilon storage device in the Swift cluster.\n\nI was thinking that perhaps the way that makes the most sense and would be easiest for us (Isilon) to maintain would be to add some type of plugin/extension capability to Swift so that portions of the functionality could be overridden. I was thinking that I could probably draw up a blueprint for this and do the work of implementing it. That\'s just my thought, but I wanted to hear what the members of the list have to say concerning this.\n\nBTW, the primary thing that I had to deal with in order to make Isilon work with Swift was the fact that each node in an Isilon cluster shares a single storage volume by virtue of the OneFS operating system that Isilon nodes run on. So, for example, I had to modify the Swift proxy server so that it doesn\'t do things like simultaneously write to two nodes in the same Isilon cluster. Also, I had to modify the replicators so that they do not attempt to replicate between nodes in the Isilon cluster, etc, etc.\n\nIsilon, as a company, feels that OpenStack has a bright future and we want to make sure that we can be a part of that, so I would appreciate any feedback you can give me concerning the best way to support Isilon and OpenStack integration for the long term.\n\nThanks for your time and consideration.\n\nAlex Pecoraro\nSr. Software Engineer\nEMC Isilon\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130522/079cba80/attachment.html>\n\n',NULL,NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A48F5DFCDF@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-23 13:16:32',-14400,'2013-05-23 17:16:32',NULL,'[openstack-dev] [Swift] Isilon support feedback','I start the replicators for replication between multiple Isilon clusters. Or actually in my test setup I had a mixed environment with some nodes that were just normal Ubuntu Linux boxes and some nodes that were part of an Isilon cluster. So the replicators would replicate from the Isilon nodes to the Ubuntu nodes.\n\nI\'ll look into opening the source.\n\nAlex\n\n-----Original Message-----\nFrom: Pete Zaitcev [mailto:zaitcev at redhat.com] \nSent: Thursday, May 23, 2013 8:11 AM\nTo: OpenStack Development Mailing List\nCc: Pecoraro, Alex\nSubject: Re: [openstack-dev] [Swift] Isilon support feedback\n\nOn Wed, 22 May 2013 14:16:15 -0400\n\"Pecoraro, Alex\" <Alex.Pecoraro at emc.com> wrote:\n\n> I\'ve taken the Swift code and hacked on it a bit to build a prototype \n> that works with Isilon [...]\n\nIt would help a lot if you opened the source and not just described what it does.\n\n> So, for example, I had to modify the Swift proxy server so that it \n> doesn\'t do things like simultaneously write to two nodes in the same Isilon cluster.\n\nYeah, I did that too, like this:\n https://github.com/zaitcev/swift-lfs\nOr you could create a fake ring with 1 node, like Gluster does.\n\n> Also, I had to modify the replicators so that they do not attempt to \n> replicate between nodes in the Isilon cluster, etc, etc.\n\nWhy do you even start those?\n\n-- Pete\n\n\n\n','<20130523091041.2cd3ae85@lembas.zaitcev.lan>',NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A491BEA037@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 14:02:22',-14400,'2013-06-12 18:02:22',NULL,'[openstack-dev] code changes feedback','Hi, I\'ve been working on some changes to Swift that I\'m not quite done with, but I wanted to request some feedback on the path I\'m taking to make sure it is correct/acceptable. My changes don\'t add any new features per se, their purpose is to make the code a little more flexible so that it is easier to add custom behavior by subclassing base Swift classes and overriding key functions. The reason that I want to do this is so that I can create extensions to Swift either through monkey-patching or some other method that make it possible for Swift to work with Isilon storage devices. The main change that I needed to make was to how nodes are iterated in the proxy server, replicators, updaters, and the container synchronizer. So I created a class called NodeIterator and another class called NodeIteratorFactory, which are used for iterating the primary and handoff nodes rather than simply iterating the list of nodes returned by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the proxy server the code for iterating through nodes to satisfy a GET request  changes from this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nfor node in self.iter_nodes(ring, partition):\n\nto (more or less) this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nnode_iter = self.node_iterator_factory.create(ring, part)\nfor node in node_iter:\n\nMy plan is to create a subclass of NodeIteratorFactory and override the create function to have it return a subclass of NodeIterator that iterates the nodes in a way that is compatible with Isilon devices.\n\nI\'ve attached a patch file showing what I\'ve done so far. Please take a look and let me know what you think.\n\nAlso, I\'m not sure if I created the patch file correctly, it seems to show every change that I\'ve committed rather than just my most recent changes (this is my first time using git). I\'ve been committing locally and then pulling in changes from the origin/source as I go in order to lessen the chance of conflicts. Hopefully that\'s not too confusing.\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/5dd646e6/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: node_iterator_changes.patch\nType: application/octet-stream\nSize: 149070 bytes\nDesc: node_iterator_changes.patch\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/5dd646e6/attachment-0001.obj>\n\n',NULL,NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A491BEA038@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 14:03:44',-14400,'2013-06-12 18:03:44',NULL,'[openstack-dev] [Swift] code changes feedback','Forgot to put the [Swift] on the subject of this email - resubmitting so it doesn\'t get missed.\n\nFrom: Pecoraro, Alex\nSent: Wednesday, June 12, 2013 11:02 AM\nTo: OpenStack Development Mailing List\nSubject: code changes feedback\n\nHi, I\'ve been working on some changes to Swift that I\'m not quite done with, but I wanted to request some feedback on the path I\'m taking to make sure it is correct/acceptable. My changes don\'t add any new features per se, their purpose is to make the code a little more flexible so that it is easier to add custom behavior by subclassing base Swift classes and overriding key functions. The reason that I want to do this is so that I can create extensions to Swift either through monkey-patching or some other method that make it possible for Swift to work with Isilon storage devices. The main change that I needed to make was to how nodes are iterated in the proxy server, replicators, updaters, and the container synchronizer. So I created a class called NodeIterator and another class called NodeIteratorFactory, which are used for iterating the primary and handoff nodes rather than simply iterating the list of nodes returned by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the proxy server the code for iterating through nodes to satisfy a GET request  changes from this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nfor node in self.iter_nodes(ring, partition):\n\nto (more or less) this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nnode_iter = self.node_iterator_factory.create(ring, part)\nfor node in node_iter:\n\nMy plan is to create a subclass of NodeIteratorFactory and override the create function to have it return a subclass of NodeIterator that iterates the nodes in a way that is compatible with Isilon devices.\n\nI\'ve attached a patch file showing what I\'ve done so far. Please take a look and let me know what you think.\n\nAlso, I\'m not sure if I created the patch file correctly, it seems to show every change that I\'ve committed rather than just my most recent changes (this is my first time using git). I\'ve been committing locally and then pulling in changes from the origin/source as I go in order to lessen the chance of conflicts. Hopefully that\'s not too confusing.\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/ad55148b/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: node_iterator_changes.patch\nType: application/octet-stream\nSize: 149070 bytes\nDesc: node_iterator_changes.patch\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/ad55148b/attachment.obj>\n\n',NULL,NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A491BEA0B4@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 16:38:05',-14400,'2013-06-12 20:38:05',NULL,'[openstack-dev] [Swift] code changes feedback','I think I did the patch format correctly this time. So sending again.\n\nAlex\n\nFrom: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]\nSent: Wednesday, June 12, 2013 11:04 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [Swift] code changes feedback\n\nForgot to put the [Swift] on the subject of this email - resubmitting so it doesn\'t get missed.\n\nFrom: Pecoraro, Alex\nSent: Wednesday, June 12, 2013 11:02 AM\nTo: OpenStack Development Mailing List\nSubject: code changes feedback\n\nHi, I\'ve been working on some changes to Swift that I\'m not quite done with, but I wanted to request some feedback on the path I\'m taking to make sure it is correct/acceptable. My changes don\'t add any new features per se, their purpose is to make the code a little more flexible so that it is easier to add custom behavior by subclassing base Swift classes and overriding key functions. The reason that I want to do this is so that I can create extensions to Swift either through monkey-patching or some other method that make it possible for Swift to work with Isilon storage devices. The main change that I needed to make was to how nodes are iterated in the proxy server, replicators, updaters, and the container synchronizer. So I created a class called NodeIterator and another class called NodeIteratorFactory, which are used for iterating the primary and handoff nodes rather than simply iterating the list of nodes returned by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the proxy server the code for iterating through nodes to satisfy a GET request  changes from this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nfor node in self.iter_nodes(ring, partition):\n\nto (more or less) this:\n\ndef GETorHEAD_base(self, req, server_type, ring, partition, path):\n...\nnode_iter = self.node_iterator_factory.create(ring, part)\nfor node in node_iter:\n\nMy plan is to create a subclass of NodeIteratorFactory and override the create function to have it return a subclass of NodeIterator that iterates the nodes in a way that is compatible with Isilon devices.\n\nI\'ve attached a patch file showing what I\'ve done so far. Please take a look and let me know what you think.\n\nAlso, I\'m not sure if I created the patch file correctly, it seems to show every change that I\'ve committed rather than just my most recent changes (this is my first time using git). I\'ve been committing locally and then pulling in changes from the origin/source as I go in order to lessen the chance of conflicts. Hopefully that\'s not too confusing.\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/0f804af5/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: node_iterator_changes.patch\nType: application/octet-stream\nSize: 104380 bytes\nDesc: node_iterator_changes.patch\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130612/0f804af5/attachment.obj>\n\n','<0B0DC37E1D749C4CAE907CB0D568C2A491BEA038@MX06A.corp.emc.com>',NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A491BEA1FB@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 14:59:24',-14400,'2013-06-13 18:59:24',NULL,'[openstack-dev] [Swift] code changes feedback','I can submit code to gerrit that is not ready to be checked in (hasn\'t been fully tested, unit tests aren\'t fully written yet, etc)?  Mainly I\'m just looking for feedback so that I can be sure that I\'m headed in a direction that will be acceptable when I am done.\n\nThanks.\n\nAlex\n\n-----Original Message-----\nFrom: John Dickinson [mailto:me at not.mn] \nSent: Wednesday, June 12, 2013 5:29 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Swift] code changes feedback\n\nI\'m happy to see your interest in contributing. Now that the patch is squashed (as gerrit requires), and since you actually already have the code, submitting it to gerrit would be the best way to get feedback. Gerrit will allow us to comment line-by-line and recommend any changes, if needed. I\'d suggest adding a second paragraph to your commit message with some of the info from your original email about the reasons for this and problems it solves for you.\n\nLooking forward to seeing the patch in gerrit.\n\n--John\n\n\n\n\nOn Jun 12, 2013, at 1:38 PM, \"Pecoraro, Alex\" <Alex.Pecoraro at emc.com> wrote:\n\n> I think I did the patch format correctly this time. So sending again.\n>  \n> Alex\n>  \n> From: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]\n> Sent: Wednesday, June 12, 2013 11:04 AM\n> To: OpenStack Development Mailing List\n> Subject: [openstack-dev] [Swift] code changes feedback\n>  \n> Forgot to put the [Swift] on the subject of this email - resubmitting so it doesn\'t get missed.\n>  \n> From: Pecoraro, Alex\n> Sent: Wednesday, June 12, 2013 11:02 AM\n> To: OpenStack Development Mailing List\n> Subject: code changes feedback\n>  \n> Hi, I\'ve been working on some changes to Swift that I\'m not quite done with, but I wanted to request some feedback on the path I\'m taking to make sure it is correct/acceptable. My changes don\'t add any new features per se, their purpose is to make the code a little more flexible so that it is easier to add custom behavior by subclassing base Swift classes and overriding key functions. The reason that I want to do this is so that I can create extensions to Swift either through monkey-patching or some other method that make it possible for Swift to work with Isilon storage devices. The main change that I needed to make was to how nodes are iterated in the proxy server, replicators, updaters, and the container synchronizer. So I created a class called NodeIterator and another class called NodeIteratorFactory, which are used for iterating the primary and handoff nodes rather than simply iterating the list of nodes returned by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the proxy server the code for iterating through nodes to satisfy a GET request  changes from this:\n>  \n> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n> ...\n> for node in self.iter_nodes(ring, partition):\n>  \n> to (more or less) this:\n>  \n> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n> ...\n> node_iter = self.node_iterator_factory.create(ring, part) for node in \n> node_iter:\n>  \n> My plan is to create a subclass of NodeIteratorFactory and override the create function to have it return a subclass of NodeIterator that iterates the nodes in a way that is compatible with Isilon devices.\n>  \n> I\'ve attached a patch file showing what I\'ve done so far. Please take a look and let me know what you think.\n>  \n> Also, I\'m not sure if I created the patch file correctly, it seems to show every change that I\'ve committed rather than just my most recent changes (this is my first time using git). I\'ve been committing locally and then pulling in changes from the origin/source as I go in order to lessen the chance of conflicts. Hopefully that\'s not too confusing.\n>  \n> Thanks.\n>  \n> Alex\n> <node_iterator_changes.patch>_________________________________________\n> ______\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<8E409A37-C15A-499B-8783-F2EF327344E8@not.mn>',NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A491ECBCC5@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 20:35:03',-14400,'2013-06-18 00:35:03',NULL,'[openstack-dev] [Swift] code changes feedback','Is there, by chance, a way to submit a patch file to gerrit via a web interface? Just wondering because I\'m having a heck of time submitting my changes. My desktop computer seems to be blocked by the corporate firewall and when I try on my laptop connected to an external network I get an error from git review: ValueError: too many values to unpack.\n\nThanks.\n\nAlex\n\n-----Original Message-----\nFrom: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com] \nSent: Thursday, June 13, 2013 11:59 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Swift] code changes feedback\n\nI can submit code to gerrit that is not ready to be checked in (hasn\'t been fully tested, unit tests aren\'t fully written yet, etc)?  Mainly I\'m just looking for feedback so that I can be sure that I\'m headed in a direction that will be acceptable when I am done.\n\nThanks.\n\nAlex\n\n-----Original Message-----\nFrom: John Dickinson [mailto:me at not.mn] \nSent: Wednesday, June 12, 2013 5:29 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Swift] code changes feedback\n\nI\'m happy to see your interest in contributing. Now that the patch is squashed (as gerrit requires), and since you actually already have the code, submitting it to gerrit would be the best way to get feedback. Gerrit will allow us to comment line-by-line and recommend any changes, if needed. I\'d suggest adding a second paragraph to your commit message with some of the info from your original email about the reasons for this and problems it solves for you.\n\nLooking forward to seeing the patch in gerrit.\n\n--John\n\n\n\n\nOn Jun 12, 2013, at 1:38 PM, \"Pecoraro, Alex\" <Alex.Pecoraro at emc.com> wrote:\n\n> I think I did the patch format correctly this time. So sending again.\n>  \n> Alex\n>  \n> From: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]\n> Sent: Wednesday, June 12, 2013 11:04 AM\n> To: OpenStack Development Mailing List\n> Subject: [openstack-dev] [Swift] code changes feedback\n>  \n> Forgot to put the [Swift] on the subject of this email - resubmitting so it doesn\'t get missed.\n>  \n> From: Pecoraro, Alex\n> Sent: Wednesday, June 12, 2013 11:02 AM\n> To: OpenStack Development Mailing List\n> Subject: code changes feedback\n>  \n> Hi, I\'ve been working on some changes to Swift that I\'m not quite done with, but I wanted to request some feedback on the path I\'m taking to make sure it is correct/acceptable. My changes don\'t add any new features per se, their purpose is to make the code a little more flexible so that it is easier to add custom behavior by subclassing base Swift classes and overriding key functions. The reason that I want to do this is so that I can create extensions to Swift either through monkey-patching or some other method that make it possible for Swift to work with Isilon storage devices. The main change that I needed to make was to how nodes are iterated in the proxy server, replicators, updaters, and the container synchronizer. So I created a class called NodeIterator and another class called NodeIteratorFactory, which are used for iterating the primary and handoff nodes rather than simply iterating the list of nodes returned by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the proxy server the code for iterating through nodes to satisfy a GET request  changes from this:\n>  \n> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n> ...\n> for node in self.iter_nodes(ring, partition):\n>  \n> to (more or less) this:\n>  \n> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n> ...\n> node_iter = self.node_iterator_factory.create(ring, part) for node in \n> node_iter:\n>  \n> My plan is to create a subclass of NodeIteratorFactory and override the create function to have it return a subclass of NodeIterator that iterates the nodes in a way that is compatible with Isilon devices.\n>  \n> I\'ve attached a patch file showing what I\'ve done so far. Please take a look and let me know what you think.\n>  \n> Also, I\'m not sure if I created the patch file correctly, it seems to show every change that I\'ve committed rather than just my most recent changes (this is my first time using git). I\'ve been committing locally and then pulling in changes from the origin/source as I go in order to lessen the chance of conflicts. Hopefully that\'s not too confusing.\n>  \n> Thanks.\n>  \n> Alex\n> <node_iterator_changes.patch>_________________________________________\n> ______\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<0B0DC37E1D749C4CAE907CB0D568C2A491BEA1FB@MX06A.corp.emc.com>',NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A4E34B4CAE@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 17:42:11',-18000,'2013-11-07 22:42:11',NULL,'[openstack-dev] [Swift] log line length','Is there any way for me to change the logging so that it doesn\'t truncate the output - so basically the length of the line printed to the log is not limited to a certain length?\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/c1467c69/attachment.html>\n\n',NULL,NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A4F54AB582@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-17 13:21:05',-14400,'2014-04-17 17:21:05',NULL,'[openstack-dev] [Swift] Elastic Recheck failure?','Yesterday I re-submitted a patchset to Gerrit after updating the some comments in a function header and the documentation in docs. So I didn\'t make any code changes and my previous changeset passed all the Jenkins tests, but this time it failed the check-grenade-dsvm-neutron and the check-tempest-dsvm-postgres-full tests and then it had the following message in the comments section:\n\nElasticRecheck\nPatch Set 3:\n\nI noticed jenkins failed, I think you hit bug(s):\n\n    check-grenade-dsvm-neutron: https://bugs.launchpad.net/bugs/1307344\n    check-tempest-dsvm-postgres-full: https://bugs.launchpad.net/bugs/1253896\n\nWe don\'t automatically recheck or reverify, so please consider doing that manually if someone hasn\'t already. For a code review which is not yet approved, you can recheck by leaving a code review comment with just the text:\n\nrecheck bug 1307344\nFor bug details see: http://status.openstack.org/elastic-recheck/\n\nDoes that mean that my test failed because of a bug in the test system? If so then how do I get around the issue so that my changeset passes all the tests?\n\nHere\'s my patchset for reference:\n\nhttps://review.openstack.org/#/c/80421/\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/e9b15418/attachment.html>\n\n',NULL,NULL),('<0B0DC37E1D749C4CAE907CB0D568C2A4F54AB587@MX06A.corp.emc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-17 13:32:33',-14400,'2014-04-17 17:32:33',NULL,'[openstack-dev] [Swift] Elastic Recheck failure?','Doh!\n\nNevermind, I think I figured it out with more careful reading, sorry for the unnecessary email.\n\nFrom: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]\nSent: Thursday, April 17, 2014 10:21 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [Swift] Elastic Recheck failure?\n\nYesterday I re-submitted a patchset to Gerrit after updating the some comments in a function header and the documentation in docs. So I didn\'t make any code changes and my previous changeset passed all the Jenkins tests, but this time it failed the check-grenade-dsvm-neutron and the check-tempest-dsvm-postgres-full tests and then it had the following message in the comments section:\n\nElasticRecheck\nPatch Set 3:\n\nI noticed jenkins failed, I think you hit bug(s):\n\n    check-grenade-dsvm-neutron: https://bugs.launchpad.net/bugs/1307344\n    check-tempest-dsvm-postgres-full: https://bugs.launchpad.net/bugs/1253896\n\nWe don\'t automatically recheck or reverify, so please consider doing that manually if someone hasn\'t already. For a code review which is not yet approved, you can recheck by leaving a code review comment with just the text:\n\nrecheck bug 1307344\nFor bug details see: http://status.openstack.org/elastic-recheck/\n\nDoes that mean that my test failed because of a bug in the test system? If so then how do I get around the issue so that my changeset passes all the tests?\n\nHere\'s my patchset for reference:\n\nhttps://review.openstack.org/#/c/80421/\n\nThanks.\n\nAlex\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/070b076a/attachment.html>\n\n','<0B0DC37E1D749C4CAE907CB0D568C2A4F54AB582@MX06A.corp.emc.com>',NULL),('<0b0f01cf0d70$bad76410$30862c30$@inaugust.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-01-09 11:26:42',-28800,'2014-01-09 19:26:42',NULL,'[OpenStack-Infra] An idea to scale Zuul','+100 (apologies for top-post - laptop was stolen, limping along on Windows\nfor a few days. Ew.)\n\n> -----Original Message-----\n> From: Robert Collins [mailto:robertc at robertcollins.net]\n> Sent: Wednesday, January 08, 2014 11:52 PM\n> To: James E. Blair\n> Cc: <openstack-infra at lists.openstack.org>\n> Subject: Re: [OpenStack-Infra] An idea to scale Zuul\n> \n> Looks good to me.\n> \n> On 9 January 2014 19:59, James E. Blair <jeblair at openstack.org> wrote:\n> > Hi,\n> >\n> > When Zuul gets very busy, it can end up launching hundreds of jobs\n> > nearly simultaneously.  Each of them has to perform several git fetch\n> > operations to obtain the changes needed for testing.  They fetch from\n> > the git repos on the Zuul server because Zuul itself is creating those\n> > commits by locally merging several changes together according to\n> > what\'s in the queue.\n> >\n> > The acts of fetching and merging git patchsets (which is single\n> > threaded) adds some load to the server, but in particular, serving\n> > those git refs to 400 Jenkins nodes nearly simultaneously can also be\n> > a bit of a burden.  It was too much for our previous server; we\'ve\n> > moved Zuul to a faster server now, but it would be nice to have a more\n> > scalable solution for the future.\n> >\n> > I\'d like to move the Zuul git merging component into a separate\n> > process that can be located on a separate host (or hosts) and scaled\nout.\n> >\n> > The current zuul-server would continue to manage the queue and launch\n> > jobs, but as it processes the queue and decides which changes should\n> > be composed and built into zuul git refs, it would package the info\n> > about each ref and put it on the gearman queue as a work item.  An\n> > instance of the new component (zuul-merger) would fetch that job and\n> > fetch the needed refs from Gerrit, and merge them.  It would also\n> > serve the resulting git repo in the same way that Zuul does now.\n> >\n> > Zuul would not have to wait for a response before continuing to\n> > process the queue, and since it\'s not doing any actual work, will be\n> > able to move through the queue _much_ faster than currently.  Once\n> > Zuul _does_ receive a completion response from a zuul-merger, it can\n> > then launch the jobs for that change.  It will pass the URL for that\n> > particular zuul-merger (as ZUUL_URL) to the jobs so that they know\n> > from which merger to fetch the zuul ref.  We can also use the cancel\n> > job functionality in gearman if Zuul decides to reorder the queue.\n> >\n> > We can scale out the mergers horizontally and they can operate in\n> > parallel, which should also improve the responsiveness of overall\n> > queue processing.\n> >\n> > The only downside I currently foresee is that if we scale out the\n> > mergers too much, we will see a performance impact on gerrit;\n> > therefore we should anticipate having a reasonably small number of\n> > these (2-8, perhaps).\n> >\n> > Since this is already quite modular, I think the implementation should\n> > be relatively simple.\n> >\n> > How does that sound?\n> >\n> > -Jim\n> >\n> > _______________________________________________\n> > OpenStack-Infra mailing list\n> > OpenStack-Infra at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n> \n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n\n','<CAJ3HoZ3xThLqGu1pJGVk-1DX6JPx=WQKxNmjp+JqqR9KkykZhw@mail.gmail.com>',NULL),('<0b139a7a0275634bd5ed03524f6d7fa6@secure.spamaps.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 13:59:07',-25200,'2013-04-30 20:59:07',NULL,'[openstack-dev] Continuous deployment - significant process\n	change','On 2013-04-30 13:12, Sean Dague wrote:\n> On 04/30/2013 03:55 PM, Clint Byrum wrote:\n> <snip>\n>> \n>> I understand that this is a straw-man. I know that other things can\n>> happen. But I see a lot of development happen under the stable \n>> release\n>> process scenario above. I fail to see where having new code arrive\n>> incrementally in small batches and protected by feature flags is \n>> going\n>> to make anything worse. Those things, however, should make continuous\n>> delivery of OpenStack much smoother.\n> \n> Right, it\'s a straw man, which doesn\'t help generate any clarity. :)\n> \n> I think instead of discussing philosophy here we should talk about\n> specifics that happened in the source tree that caused deployers pain,\n> and take lessons learned out of them.\n> \n> I think the reality is that openstack tree and process is very close\n> to what the CD folks want. The only thing that\'s causing some allergy\n> among the core teams is the idea of features coming in in an off\n> state, versus coming in default on so they get exercised by our normal\n> system.\n> \n\nThats exactly my point. Large changes are not being exercised by any \nlarge scale system now while they\'re baking in a branch, so making them \nenabled by feature flags versus by commit to trunk does not regress \nthat, but it does allow deployers to test both code paths and deploy \nboth without having to maintain branches of the software.\n\n\n','<518025C0.5060801@dague.net>',NULL),('<0B183BB6-1BC3-42B6-9F8C-7C2B70E9B52D@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 00:28:48',-18000,'2014-03-04 05:28:48',NULL,'[openstack-dev] Neutron: Need help with tox failure in VPN code','Hi,\n\nI\'m stuck and can use some guidance here?please!\n\nI have a change set out for review that used the VPN Service Type Framework ( https://review.openstack.org/74144). Everything worked fine, passed Jenkins, etc.\n\nFound out that the STF won\'t make it to I-3, so I removed the dependency from my change set and tried to modify the plugin.py file to use some STF logic (like LBaaS uses) to load the desired service driver that is specified as the default. Adjusted the code to no longer use provider info.\n\nWell, in doing so, tox fails, and unfortunately there little info on the failure. This can be seen by running a subset of the tests, where 2 fail:\n\ntox -e py27 -v -- neutron.tests.unit.services.vpn\n\nonly the name of a failing test case for one, and a mention of return code 10 on another and no other info on the failure reason. I didn\'t see this on a full tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running the above subset of the suite (thanks!).\n\n\nI\'ve narrow it down a bit, but have no idea why it fails?\n\nOne, it seems to be some interaction between test_vpnaas_driver_plugin.py and the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either one of the service driver tests cases, and it will still fail with the other one (so even the reference code fails).\n\nTwo, if I change plugin.py to set self.driver to the reference device driver (as is done in the latest patch set) it works fine with all test cases.\n\nThree, it seems to be a test only issue, because I can run devstack with the login I have in plugin.py, currently commented out in __init__(), and successfully load either the reference or cisco service driver, by changing neutron.conf.\n\nIt seems like I\'m doing something wrong in the loading of the service driver, or using this implementation, is somehow interacting with the tests.\n\nIf anyone has ideas on what is wrong, or a better way to load the service driver, please let me know. I was thinking I could read and parse neutron.conf manually and then load the service driver, but there must be a better way!\n\nThanks!\n\nPCM (Paul Michali)\n\nMAIL          pcm at cisco.com\nIRC            pcm_  (irc.freenode.net)\nTW            @pmichali\nGPG key    4525ECC253E31A83\nFingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/dc73a1f7/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 841 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/dc73a1f7/attachment.pgp>\n\n',NULL,NULL),('<0B239652-1DA7-4EE9-9390-18775D47BA4C@aristanetworks.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-29 14:18:55',-28800,'2013-01-29 22:18:55',NULL,'[openstack-dev] [quantum] Blueprint Announcement: OVSPlugin\n	Support for Hardware Devices','Reposting the review to the correct topic (turned out that git-review has a regex match on the word \'blueprint describes\' in my commit description ;-)\n\nHere\'s the new link:\n\nhttps://review.openstack.org/#/c/20754/\n\nSatish\n\nOn Jan 29, 2013, at 12:23 PM, Satish Mohan <satish at aristanetworks.com> wrote:\n\n> Thanks Dan. Yes this should be inline with what we discussed.\n> \n> Here\'s the code for review:\n> \n> https://review.openstack.org/#/c/20745/\n> \n> We are providing an Arista driver with this implementation (and a dummy driver class). But the solution should be vendor neutral.\n> \n> We have tested these changes with OpenStack/Grizzly in our test labs and it is undergoing final qualification.\n> \n> Regards\n> Satish\n\n\n\n','<9E1BB124-406C-4A0C-AB6A-FD41A9D0A477@aristanetworks.com>',NULL),('<0b3fe43277254ed7826743b83d19eac9@HKXPR04MB183.apcprd04.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-29 01:55:47',0,'2014-07-29 01:55:47',NULL,'[Openstack] issue with multiple floating ip pools for\n	neutron	network','Hi,\n\n\nWhat about  the handle_internal_only_routers option ?\n\n\n\nYou need to make sure one should be true and remaining should be false like ,\n\n\n\nFor the first agent\n\n\nhandle_internal_only_routers = True\n\ngateway_external_network_id = 2118b11c-011e-4fa5-a6f1-2ca34d372c35\n\nexternal_network_bridge = br-ex\n\nFor the second (or later) agent\n\n\nhandle_internal_only_routers = False\n\ngateway_external_network_id = e828e54c-850a-4e74-80a8-8b79c6a285d8\n\nexternal_network_bridge = br-ex-2\n\n\n\nBefore starting L3 agents, you need to create routers and external networks, then update the configuration files with UUID of external networks and start L3 agents.\n\n\n\nRegards,\n\nSubbareddy,\n\nPersistent systems ltd.\n\n\nFrom: Zhi-Wei Lu [mailto:zwlu at ucdavis.edu]\nSent: Monday, July 28, 2014 10:43 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] issue with multiple floating ip pools for neutron network\n\nHi all,\n\nI have been testing multiple floating ip pools with neutron network on CentOS 6.5 with icehouse.  The single floating ip pool set up worked fine, but I encountered many problems setting up multiple floating IP pools.  I now enabled l3-agent with empty string (in /etc/neutron/l3-agent.ini) for multiple\ngateway_external_network_id =\nexternal_network_bridge =\n\nThe external bridges, br-ex and br-ex2, do not have the qg-* port at all, these qg-* interfaces are now in the br-int, therefore the floating ips do not work anymore.  Is there any way to move \"qg\" port from br-int to br-ex, and br-ex2?  I don\'t know how I ended up with such a mess, do I have to remove the network set up and reconfigure neutron?\n\nThank you very much for your help.\n\nZhi-Wei Lu\nIET-CR-Network Operations Center\nUniversity of California, Davis\n(530) 752-0155\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140729/2240da18/attachment.html>\n\n','<675b4b344a5343cea04073825c66d654@BLUPR08MB517.namprd08.prod.outlook.com>',NULL),('<0B46AFDC-F569-47A2-8F3F-3113361A2E55@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 18:26:44',25200,'2013-11-14 11:26:44',NULL,'[openstack-dev] [heat][mistral] EventScheduler vs Mistral\n	scheduling','\nOn 14 Nov 2013, at 18:03, Zane Bitter <zbitter at redhat.com> wrote:\n\n> What might be a downside is that sharing a back-end may not be technically convenient - one thing we have been reminded of in Heat is that a service with timed tasks has to be scaled out in a completely different way to a service that avoids them. This may or may not be an issue for Mistral, but it could be resolved by having different back-end services that communicate over RPC. The front-end API can remain shared though.\n\nNot sure I?m 100% following here. Could you please provide more details on this? Seems to be an important topic to me. Particularly, what did you mean when you said ?sharing a back-end?? Sharing by which components?\n\nThanks.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/b5516c3e/attachment.html>\n\n','<5284AE0D.9080606@redhat.com>',NULL),('<0B6FBD96EC0DA448AD21BEC27401EDE233B7E3489D@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 15:49:41',-25200,'2013-08-30 22:49:41',NULL,'[Openstack] Is \"melange\" alive or dead?','\nI came across this interesting \"officially incubated\" project for OpenStack called \"Melange\".  In a nutshell:c\n\n	\"Melange is intended to provide network information services for use across OpenStack services.\"\n\nHowever, it appears the project is ... well, dead.  The last code check-ins were over a year ago.  Am I missing where it might have been moved to, if it\'s still alive?   Related sites I\'ve found:\n\n	https://launchpad.net/melange\n	https://github.com/openstack/melange \n	https://wiki.openstack.org/wiki/Melange \n\nTIA! \n\n~~shane \n\n\n\n',NULL,NULL),('<0B6FBD96EC0DA448AD21BEC27401EDE233B7E348F4@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 16:44:29',-25200,'2013-08-30 23:44:29',NULL,'[Openstack] Is \"melange\" alive or dead?','\nGot it - thx for the reply, Wayne (and to racker Justin Hammond as well)... \n\nGuess that was a great naming \"miss\" ... Melatum ... or Qualange ... boo ... \n\n~~shane \n\n> -----Original Message-----\n> From: Wayne A. Walls [mailto:wayne at openstack.org]\n> Sent: Friday, August 30, 2013 4:26 PM\n> To: Shane Gibson\n> Cc: openstack at lists.openstack.org\n> Subject: Re: [Openstack] Is \"melange\" alive or dead?\n> \n> Hey Shane, melange and quantum have essentially merged into one project,\n> neutron.  There\'s some history there, but I believe neutron will provide what\n> you\'re looking for.\n> \n> Cheers,\n> \n> \n> wayne\n> \n> \n> \n> > On 30 Aug 2013, at 17:49, Shane Gibson <Shane_Gibson at symantec.com>\n> wrote:\n> >\n> >\n> > I came across this interesting \"officially incubated\" project for OpenStack\n> called \"Melange\".  In a nutshell:c\n> >\n> >    \"Melange is intended to provide network information services for use\n> across OpenStack services.\"\n> >\n> > However, it appears the project is ... well, dead.  The last code check-ins\n> were over a year ago.  Am I missing where it might have been moved to, if it\'s\n> still alive?   Related sites I\'ve found:\n> >\n> >    https://launchpad.net/melange\n> >    https://github.com/openstack/melange\n> >    https://wiki.openstack.org/wiki/Melange\n> >\n> > TIA!\n> >\n> > ~~shane\n> >\n> >\n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<9414B8E2-2022-4D6A-A493-1134383FA683@openstack.org>',NULL),('<0B70DF75-4482-4769-9C4F-70859041C578@yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-21 23:05:10',32400,'2013-08-21 14:05:10',NULL,'[Openstack] Use of VIPs in Openstack','\n\nOn 2013/08/21, at 19:30, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> wrote:\n\n> Hi:\n> \n> Can the LbaaS extension meet your need?\n> http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html \n> \n> \n> \n> ---\n> JuanFra\n> \n> \n> 2013/8/21 Jake G. <dj_dark_junglist at yahoo.com>\n>> Great job! that looks awesome.  Cant wait for the patch to release.  \n>> \n>> From: Aaron Rosen <arosen at nicira.com>\n>> To: Jake G. <dj_dark_junglist at yahoo.com> \n>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>> Sent: Wednesday, August 21, 2013 12:04 PM\n>> Subject: Re: [Openstack] Use of VIPs in Openstack\n>> \n>> Hi Jake, \n>> \n>> This patch implements that exact usecase: https://review.openstack.org/#/c/38230/ . Hopefully, we\'ll get this in by the end of the week. \n>> \n>> Best, \n>> \n>> Aaron\n>> \n>> \n>> On Tue, Aug 20, 2013 at 7:47 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>> Hi!\n>> \n>> I was wondering if it is possible to use a Virtual IP or VIP for clustering services (LVS, SQL, etc...) or for 3rd party load balancers?\n>> I dont see a way to assign an IP address to multiple instances for this purpose.\n>> \n>> Thanks,\n>> Jake\n>> \n>> \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\nNo I don\'t think that will work, because I need to be able for two servers to have a way to share a single IP.\n\nThis is commonly used for cluster services, LVS, VRRP etc... \n\nPlus I already have the LBaas service enabled and do not see a possible way to do this.\n\nThanks \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130821/4f8577a7/attachment.html>\n\n','<CAGXO4kzGnpWHHjGZJrrwGt-iVJti7i63mmj+-r1FHL10HAeczw@mail.gmail.com>',NULL),('<0B7114F8-A94A-4397-B483-AC2BCD9B9EB6@cisco.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-20 13:01:59',-25200,'2012-04-20 20:01:59',NULL,'[Openstack-operators] Nova API Help','\nWhat are the nova logs showing?\n\nRegards,\nDaneyon Hansen\nCCIE 9950, CISSP, TOGAF 9 Foundation, VMware Certified Professional\nCustomer Solutions Architect\nCisco Systems, Inc.\nMobile: 303-718-0400\nOffice: 720-875-2936\nEmail: danehans at cisco.com\n\nOn Apr 20, 2012, at 12:50 PM, \"mpedersen at choopa.com\" <mpedersen at choopa.com> wrote:\n\n> Hello all. I\'m having issues with the nova-api component, and haven\'t been\n> able to make this work for days. It should be simple, but ...\n> \n> We\'re using OpenStack Essex. It was installed in a single node\n> configuration for development, and we used this installer script to\n> accomplish it: https://github.com/uksysadmin/OpenStackInstaller\n> \n> I can use curl to authenticate to keystone (port 5000). I can use curl to\n> create a new user (admin, port 35357). I can use curl to retrieve a list of\n> images (glance, port 9292).\n> \n> Nothing in the nova-api (port 8774) works, though.\n> \n> I have tried the following (ADMIN and IP.ADDRESS are masked, of course):\n> \n> curl -v -H \"X-Auth-Token: ADMIN\" http://IP>ADDRESS:8774/flavors <-- gives\n> me HTTP 300, tells me to look at the next URL I try\n> \n> curl -v -H \"X-Auth-Token: ADMIN\" http://IP>ADDRESS:8774/v2/flavors <--\n> gives me HTTP 404\n> \n> curl -v -H \"X-Auth-Token: ADMIN\"\n> http://IP.ADDRESS:8774/v2/openstack/flavors <-- gives me HTTP 400,\n> malformed URL\n> \n> curl -v -H \"X-Auth-Token: ADMIN\" http://IP.ADDRESS:8774/openstack/flavors\n> <-- gives me HTTP 300, tells me to look at the above, which gives 400\n> \n> I\'ve tried digging through the code, and am drawing a blank. Can anybody\n> tell me what\'s wrong, or what I\'m doing wrong?\n> \n> Thank you!\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<f158e758f13783106dda56308a2e106d@127.0.0.1>',NULL),('<0b716f7800284c43bcbae77298586b1e@BY2PR06MB105.namprd06.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-09-02 20:15:23',0,'2014-09-02 20:15:23',NULL,'[OpenStack-Infra] [infra] Third Party CI naming and contact\n (action required)','Still waiting for CI account.  Any updates on when new accounts might be created from requests sent in last week?\n\nRichard\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info] \nSent: Tuesday, September 02, 2014 2:10 PM\nTo: openstack-infra at lists.openstack.org; third-party-announce-owner at lists.openstack.org\nSubject: Re: [OpenStack-Infra] [infra] Third Party CI naming and contact (action required)\n\nOn 08/13/2014 02:23 PM, James E. Blair wrote:\n> Hi,\n> \n> We\'ve updated the registration requirements for third-party CI systems\n> here:\n> \n>   http://ci.openstack.org/third_party.html\n> \n> We now have 86 third-party CI systems registered and have undertaken \n> an effort to make things more user-friendly for the developers who \n> interact with them.  There are two important changes to be aware of:\n> \n> 1) We now generally name third-party systems in a descriptive manner \n> including the company and product they are testing.  We have renamed \n> currently-operating CI systems to match these standards to the best of \n> our abilities.  Some of them ended up with particularly bad names \n> (like \"Unknown Function...\").  If your system is one of these, please \n> join us in #openstack-infra on Freenode to establish a more descriptive name.\n> \n> 2) We have established a standard wiki page template to supply a \n> description of the system, what is tested, and contact information for \n> each system.  See https://wiki.openstack.org/wiki/ThirdPartySystems \n> for an index of such pages and instructions for creating them.  Each \n> third-party CI system will have its own page in the wiki and it must \n> include a link to that page in every comment that it leaves in Gerrit.\n> \n> If you operate a third-party CI system, please ensure that you \n> register a wiki page and update your system to link to it in every new \n> Gerrit comment by the end of August.  Beginning in September, we will \n> disable systems that have not been updated.\n> \n> Thanks,\n> \n> Jim\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \nCurrently we have 48 gerrit accounts that do not have a wikipage as specified above: http://paste.openstack.org/show/104875/\n\n10624	pattabi-ayyasami-ci	Brocade ADX CI	pattabi.ayyasami at gmail.com\n9753	brocade_jenkins	Brocade BNA CI	shivharis at gmail.com\n13051	brocade-lbaas-ci	Brocade LBaaS CI\nDL-GRP-ENG-brocade-adx-openstack-ci at Brocade.com\n10193	compass_ci	Compass CI	dev-team at syscompass.org\n13049	coraid-ci	Coraid CI	coraid-openstack-ci-all at mirantis.com\n5171	citrixjenkins	Deprecated Citrix CI	n/a\n10240	designate-jenkins	Deprecated Designate CI	dnsaas at hp.com\n11016	raxheatci	Deprecated RAX Heat CI	heat-ops at lists.rackspace.com\n7092	reddwarf	Deprecated Trove CI	reddwarf-jenkins at googlegroups.com\n10183	docker-ci	Docker CI	openstack-ci at docker.com\n12018	emc-vipr-ci	EMC ViPR CI	emc.vipr.ci at emc.com\n9885	eci	Embrane CI	marco.chirico at embrane.com\n10808	fuel-watcher	Fuel Bot	afedorova+watcher at mirantis.com\n8971	fuel-ci	Fuel CI	fuel-ci-bot at mirantis.com\n12489	fusionio-ci	Fusion-io CI	openstack-cinder-iocontrol at fusionio.com\n12368	globallogic-ci	GlobalLogic CI	openstack-ci at globallogic.com\n12251	ib-ipam-ci	IB IPAM CI	sramanathan at infoblox.com\n9751	ibmdb2	IBM DB2 CI	scecd at cn.ibm.com\n12499	ibm-ds8k-ci	IBM DS8000 CI	edlin at us.ibm.com\n12370	ibm-flashsystem-ci	IBM FlashSystem CI	ibmfsci at cn.ibm.com\n9752	ibmpwrvc	IBM PowerVC CI	pwrdrvci at cn.ibm.com\n10623	ibm-zvm-ci	IBM ZVM CI	ibmzvmci at 163.com\n12081	ibm-xcat-ci	IBM xCAT CI	xcat at cn.ibm.com\n10307	jaypipes-testing	Jay Pipes Testing CI	jpipes at mirantis.com\n10867	lvstest	LVS CI	lbaastest at gmail.com\n10712	jenkins-magnetodb	MagnetoDB CI	jenkins-magnetodb at mirantis.com\n10621	netapp-ci	NetApp CI	xdl-openstack-jenkins at netapp.com\n7246	nicirabot	Nicira Bot	n/a\n11611	nimbleci	Nimble Storage CI	openstack-ci at nimblestorage.com\n12250	open-attic-ci	Open Attic CI	community at open-attic.org\n9682	contrail	OpenContrail CI	n/a\n10386	odl-jenkins	OpenDaylight CI	odl-openstack at opendaylight.org\n10117	plumgrid-ci	PLUMgrid CI	plumgrid-ci-os at plumgrid.com\n7360	puppet-openstack-ci-user	Puppet CI	puppet.openstack.ci at gmail.com\n9133	puppetceph	Puppet Ceph CI	loic-puppetceph at dachary.org\n12369	purestorage-cinder-ci	Pure Storage CI	openstack-dev at purestorage.com\n9681	neutronryu	Ryu CI	ryu-openstack-review at lists.sourceforge.net\n12494	suse-cloud-ci	SUSE Cloud CI	bwiedemann+openstackgerritci at suse.de\n12034	sacharya-ci	Sacharya CI	info at sacharya.com\n7213	savanna-ci	Sahara Hadoop Cluster CI	elastic-hadoop-ci at mirantis.com\n2166	smokestack	SmokeStack CI	n/a\n12019	snabb-nfv-ci	Snabb NFV CI	openstack-ci at snabb.co\n10622	sfci	SolidFire CI	openstack.ci at solidfire.com\n11258	thstack-ci	THSTACK CI	openstack-ci at thstack.com\n13050	vmware-congress-ci	VMWare Congress CI	congressci at gmail.com\n7584	vanillabot	Vanilla Bot	vanillabot at vanillastack.org\n9884	wherenowjenkins	Wherenow.org CI	jenkins at wherenow.org\n10119	varmourci	vArmour CI	openstack-ci-test at varmour.com\n\nFollow the instructions in the original email and ensure your account has a wikipage entry to avoid having your gerrit account disabled. These accounts have now passed the deadline and can be disabled at any time.\n\nHaving a wikipage entry for your gerrit account is a requirement of retaining a gerrit account enabled:\nhttp://ci.openstack.org/third_party.html#requirements\n\nThank you,\nAnita.\n\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n','<54062418.8070109@anteaya.info>',NULL),('<0B721217-9698-40D6-BE7C-41C503494EF1@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 22:21:14',0,'2014-06-19 22:21:14',NULL,'[openstack-dev] [Heat] fine grained quotas','On Jun 19, 2014, at 4:17 PM, Clint Byrum <clint at fewbar.com> wrote:\n\n> I was made aware of the following blueprint today:\n> \n> http://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat\n> http://review.openstack.org/#/c/96696/14\n> \n> Before this goes much further.. I want to suggest that this work be\n> cancelled, even though the code looks excellent. The reason those limits\n> are in the config file is that these are not billable items and they\n> have a _tiny_ footprint in comparison to the physical resources they\n> will allocate in Nova/Cinder/Neutron/etc.\n> \n> IMO we don\'t need fine grained quotas in Heat because everything the\n> user will create with these templates will cost them and have its own\n> quota system. The limits (which I added) are entirely to prevent a DoS\n> of the engine.\n\nWhat\'s more, I don\'t think this is something we should expose via API other than to perhaps query what those quota values are. It is possible that some provider would want to bill on number of stacks, etc (I personally agree with Clint here), it seems that is something that could/should be handled external to Heat itself.\n\n','<1403212533-sup-8874@fewbar.com>',NULL),('<0B7C5581-DD2F-41E6-BC0A-5C66F77FCD15@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 16:43:02',3600,'2013-05-15 15:43:02',NULL,'[openstack-dev] [keystone] v3-aware keystone client','Hi\n\nWanted to review what our plans were to get to a full v3-aware client for keystone.  I *think* the plan was:\n\n- enable the keystone client for v3 classes - which is done I think except for v3 auth (for which I saw Dolphm just restore a change (https://review.openstack.org/#/c/21942/6)\n- enable the openstack client to use the v3 client classes to provide full v3 cli support (much of this is done, I think).\n\nMy question is whether we have a clear list of what\'s left to do - and the timeline to complete (or requests for help).  I believe we originally stated we were aiming for the v3 client capability by the time the Havana m1 release was cut....is that still our plan?\n\nHenry\n\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E150119F49@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-06 12:50:56',-18000,'2013-05-06 17:50:56',NULL,'[openstack-dev] how to configure cisco plugin in devstack\n	environment','Hi All,\n\n\n\nI\'m new to devstack and would need to configure cisco plugin to work in devstack environment. I followed the instruction in the webpage (https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Grizzly_Release.29) to configure cisco plugin. However, devstack seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n\n\n\nI tried to set up Q_plugin in localrc. However, it seems cisco is not one of the plugins supported under /opt/stack/devstack/lib/quantum_plugins...do I need to configure this variable in localrc? If not, what else I need to do in order for openstack to pick up Cisco plugin in devstack environment?\n\n\n\nThanks,\n\n\n\nYuLing\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130506/186288e1/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A18E@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-06 19:58:12',-18000,'2013-05-07 00:58:12',NULL,'[openstack-dev] how to configure cisco plugin in devstack\n environment','Thanks Kyle and Robert very much for all these information.\n\nSo, it seems that the new devstack version that contains Cisco plugin support is already available at https://review.openstack.org/#/c/25378/? Should I just use \'git fetch\' to download it and install? Is this Havana version(release)?\n\nAfter I download, can I just use Q_plugin to configure the core plugin? Do I still need to follow the manual set up steps on https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29?\n\nThanks,\n\nYuLing\n\n\n-----Original Message-----\nFrom: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com] \nSent: Monday, May 06, 2013 2:09 PM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: Re: [openstack-dev] how to configure cisco plugin in devstack environment\n\nI should note Robert\'s review for adding support to devstack for the Cisco plugin is here:\n\nhttps://review.openstack.org/#/c/25378/\n\nI\'ve been running with it for a few weeks and it works great!\n\nThanks,\nKyle\n\nOn May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n\n> Hi YuLing,\n> \n> My guess is that you pulled the code from the master. So please follow this link https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29 instead.\n> \n> Currently, configuring Q_PLUGIN to use cisco plugin is not available in devstack yet, and it\'s being worked on. Therefore you have to manually configure it with instructions given in the above link. \n> \n> Thanks,\n> Robert\n> \n> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n> \n>> Hi All,\n>>  \n>> I\'m new to devstack and would need to configure cisco plugin to work in devstack environment. I followed the instruction in the webpage (https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Grizzly_Release.29) to configure cisco plugin. However, devstack seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>  \n>> I tried to set up Q_plugin in localrc. However, it seems cisco is not one of the plugins supported under /opt/stack/devstack/lib/quantum_plugins...do I need to configure this variable in localrc? If not, what else I need to do in order for openstack to pick up Cisco plugin in devstack environment?\n>>  \n>> Thanks,\n>>  \n>> YuLing\n>>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CC6516285E165D48ACB2CF4D9266006C213EC57E@xmb-aln-x05.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A411@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 12:39:29',-18000,'2013-05-07 17:39:29',NULL,'[openstack-dev] how to configure cisco plugin in devstack\n environment','No, I was not able to run the following git fetch command published on https://review.openstack.org/#/c/25378/\n\ngit fetch https://review.openstack.org/openstack-dev/devstack refs/changes/78/25378/8 && git checkout FETCH_HEAD\n\nSo, I just downloaded one file lib/quantum_plugins/cisco and copied to my devstack environment, but hit the problem.\n\nHere I attach my cisco_plugins.ini file. I didn\'t change this file after I installed devstack. I also tried to change this file according to the instructions on https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29, but still hit the same issue.\n\n\nThanks very much,\n\nYuLing\n-----Original Message-----\nFrom: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com] \nSent: Tuesday, May 07, 2013 6:07 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: Re: [openstack-dev] how to configure cisco plugin in devstack environment\n\nDid you do a \"git fetch\"? I think you may want to do that to ensure you get the entire change set.\n\nCan you paste the contents of your /etc/quantum/plugins/cisco/cisco_plugins.ini file?\n\nOn May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n\n> Actually, I just followed the instruction on devstack grizzly \n> installation \n> link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n> ck/ and installed again. I copied over the \'cisco\' file from the link \n> https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and set Q_plugin = cisco.\n> \n> However, when I run stack.sh, Quantum server was not able to start with the following error in screen-q-svc.log:\n> \n>    __import__(mod_str)\n>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\", line 30, in <module>\n>    from quantum.plugins.cisco.common import cisco_utils as cutil  File \n> \"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>    from quantum.plugins.cisco.db import l2network_db as cdb  File \n> \"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line 24, in <module>\n>    from quantum.plugins.cisco import l2network_plugin_configuration as \n> conf  File \"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.py\", line 21, in <module>\n>    from quantum.plugins.cisco.common import cisco_configparser as \n> confp  File \"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\", line 19, in <module>\n>    from configobj import ConfigObj\n> ImportError: No module named configobj\n> ERROR: Unable to load quantum from configuration file /etc/quantum/api-paste.ini.\n> \n> Any idea why there\'s an input error for loading \'configobj\'? this file should be under /usr/lib/python2.7/dist-packages/landscape/lib. Why quantum cannot load this file?\n> \n> Thanks,\n> \n> YuLing\n> \n> ________________________________________\n> From: C, Yuling\n> Sent: Monday, May 06, 2013 7:58 PM\n> To: openstack-dev at lists.openstack.org\n> Cc: rcurran at cisco.com\n> Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n> environment\n> \n> Thanks Kyle and Robert very much for all these information.\n> \n> So, it seems that the new devstack version that contains Cisco plugin support is already available at https://review.openstack.org/#/c/25378/? Should I just use \'git fetch\' to download it and install? Is this Havana version(release)?\n> \n> After I download, can I just use Q_plugin to configure the core plugin? Do I still need to follow the manual set up steps on https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29?\n> \n> Thanks,\n> \n> YuLing\n> \n> \n> -----Original Message-----\n> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n> Sent: Monday, May 06, 2013 2:09 PM\n> To: OpenStack Development Mailing List\n> Cc: Rich Curran (rcurran)\n> Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n> environment\n> \n> I should note Robert\'s review for adding support to devstack for the Cisco plugin is here:\n> \n> https://review.openstack.org/#/c/25378/\n> \n> I\'ve been running with it for a few weeks and it works great!\n> \n> Thanks,\n> Kyle\n> \n> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n> \n>> Hi YuLing,\n>> \n>> My guess is that you pulled the code from the master. So please follow this link https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29 instead.\n>> \n>> Currently, configuring Q_PLUGIN to use cisco plugin is not available in devstack yet, and it\'s being worked on. Therefore you have to manually configure it with instructions given in the above link.\n>> \n>> Thanks,\n>> Robert\n>> \n>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>> \n>>> Hi All,\n>>> \n>>> I\'m new to devstack and would need to configure cisco plugin to work in devstack environment. I followed the instruction in the webpage (https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Grizzly_Release.29) to configure cisco plugin. However, devstack seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>> \n>>> I tried to set up Q_plugin in localrc. However, it seems cisco is not one of the plugins supported under /opt/stack/devstack/lib/quantum_plugins...do I need to configure this variable in localrc? If not, what else I need to do in order for openstack to pick up Cisco plugin in devstack environment?\n>>> \n>>> Thanks,\n>>> \n>>> YuLing\n>>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: cisco_plugins.ini\nType: application/octet-stream\nSize: 266 bytes\nDesc: cisco_plugins.ini\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130507/bad5afc7/attachment.obj>\n\n','<CC6516285E165D48ACB2CF4D9266006C213F7C9D@xmb-aln-x05.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A41D@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 12:46:15',-18000,'2013-05-07 17:46:15',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Thanks very much for the information... I just tried commenting out #QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I still hit the same issue.\n\n>From reading the log, I can see quantum was trying to pick up cisco plugin. However, it failed at importing configobj at cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t see any instructions for changing this environment variable)\n\nWhen you mentioned that\n>\' this assumes another \n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly\'. \n\nDo I need to pick up this change as well? The only thing I picked up was Robert\'s file of lib/quantum_plugins/cisco...the rest running on my environment was devstack grizzly release...\n\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com] \nSent: Tuesday, May 07, 2013 6:42 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another \n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please \n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that \n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you \n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly  \n>>installation  \n>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link  \n>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and \n>>set Q_plugin = cisco.\n>> \n>> However, when I run stack.sh, Quantum server was not able to start \n>>with the following error in screen-q-svc.log:\n>> \n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil  \n>>File  \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File  \n>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line \n>>24, in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration \n>>as  conf  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as  \n>>confp  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file \n>>/etc/quantum/api-paste.ini.\n>> \n>> Any idea why there\'s an input error for loading \'configobj\'? this \n>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib. \n>>Why quantum cannot load this file?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> Thanks Kyle and Robert very much for all these information.\n>> \n>> So, it seems that the new devstack version that contains Cisco plugin \n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this \n>>Havana version(release)?\n>> \n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on \n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>_fo \n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>ava\n>>na_Release.29?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> \n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> I should note Robert\'s review for adding support to devstack for the \n>>Cisco plugin is here:\n>> \n>> https://review.openstack.org/#/c/25378/\n>> \n>> I\'ve been running with it for a few weeks and it works great!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> \n>>> Hi YuLing,\n>>> \n>>> My guess is that you pulled the code from the master. So please \n>>>follow this link \n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>k_f \n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>8Ha\n>>>vana_Release.29 instead.\n>>> \n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available \n>>>in devstack yet, and it\'s being worked on. Therefore you have to \n>>>manually configure it with instructions given in the above link.\n>>> \n>>> Thanks,\n>>> Robert\n>>> \n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>> \n>>>> Hi All,\n>>>> \n>>>> I\'m new to devstack and would need to configure cisco plugin to \n>>>>work in devstack environment. I followed the instruction in the \n>>>>webpage \n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>ork\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack \n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>> \n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is \n>>>>not one of the plugins supported under \n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure \n>>>>this variable in localrc? If not, what else I need to do in order \n>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>> \n>>>> Thanks,\n>>>> \n>>>> YuLing\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1705659276F6A540A34DBC191957998410161462@xmb-rcd-x03.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A463@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 13:30:50',-18000,'2013-05-07 18:30:50',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','It worked!  Thanks very much Rich.  The \'OFFLINE=False RECLONE=yes\' really did the trick.\n\nI can see that core_plugin has already been cisco plugin in quantum service log.\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Rich Curran (rcurran) [mailto:rcurran at cisco.com] \nSent: Tuesday, May 07, 2013 11:13 AM\nTo: OpenStack Development Mailing List; C, Yuling\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHI Yuling -\n\nActually if you change the localrc as described below you won\'t have to install configobj (I don\'t think).\nSo change the localrc first, unstack, stack. I don\'t think at that point you\'ll have the configobj issue.\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Rich Curran (rcurran)\nSent: Tuesday, May 07, 2013 2:09 PM\nTo: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling -\n\nHere are instructions I found on installing configobj: http://www.voidspace.org.uk/python/articles/configobj.shtml\n\nAlso, you didn\'t get the latest (master) cisco quantum code.\nIn localrc please add/change:\nOFFLINE=False\nRECLONE=yes\n\nAlso, are you using a nexus hardware switch in your topology?\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, May 07, 2013 1:46 PM\nTo: openstack-dev at lists.openstack.org\nCc: Rich Curran (rcurran)\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nThanks very much for the information... I just tried commenting out #QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I still hit the same issue.\n\n>From reading the log, I can see quantum was trying to pick up cisco plugin. However, it failed at importing configobj at cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t see any instructions for changing this environment variable)\n\nWhen you mentioned that\n>\' this assumes another\n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly\'.\n\nDo I need to pick up this change as well? The only thing I picked up was Robert\'s file of lib/quantum_plugins/cisco...the rest running on my environment was devstack grizzly release...\n\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Tuesday, May 07, 2013 6:42 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another \n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please \n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that \n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you \n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly \n>>installation \n>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link \n>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and \n>>set Q_plugin = cisco.\n>> \n>> However, when I run stack.sh, Quantum server was not able to start \n>>with the following error in screen-q-svc.log:\n>> \n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line \n>>24, in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration \n>>as  conf  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as \n>>confp  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file \n>>/etc/quantum/api-paste.ini.\n>> \n>> Any idea why there\'s an input error for loading \'configobj\'? this \n>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>Why quantum cannot load this file?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> Thanks Kyle and Robert very much for all these information.\n>> \n>> So, it seems that the new devstack version that contains Cisco plugin \n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this \n>>Havana version(release)?\n>> \n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on \n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>_fo\n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>ava\n>>na_Release.29?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> \n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> I should note Robert\'s review for adding support to devstack for the \n>>Cisco plugin is here:\n>> \n>> https://review.openstack.org/#/c/25378/\n>> \n>> I\'ve been running with it for a few weeks and it works great!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> \n>>> Hi YuLing,\n>>> \n>>> My guess is that you pulled the code from the master. So please \n>>>follow this link \n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>k_f\n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>8Ha\n>>>vana_Release.29 instead.\n>>> \n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available \n>>>in devstack yet, and it\'s being worked on. Therefore you have to \n>>>manually configure it with instructions given in the above link.\n>>> \n>>> Thanks,\n>>> Robert\n>>> \n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>> \n>>>> Hi All,\n>>>> \n>>>> I\'m new to devstack and would need to configure cisco plugin to \n>>>>work in devstack environment. I followed the instruction in the \n>>>>webpage \n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>ork\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack \n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>> \n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is \n>>>>not one of the plugins supported under \n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure \n>>>>this variable in localrc? If not, what else I need to do in order \n>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>> \n>>>> Thanks,\n>>>> \n>>>> YuLing\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<96B198D1930C1D489CDF84797AC8170E21113A@xmb-rcd-x13.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A481@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 13:39:47',-18000,'2013-05-07 18:39:47',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','B.T.W.,  I\'m not planning to use a Nexus switch in my testing environment for now...just would like to use the fake driver to see how it goes...will plugin a real switch later:-)\n\nThanks very much,\n\nYuLing\n\n-----Original Message-----\nFrom: Rich Curran (rcurran) [mailto:rcurran at cisco.com] \nSent: Tuesday, May 07, 2013 11:13 AM\nTo: OpenStack Development Mailing List; C, Yuling\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHI Yuling -\n\nActually if you change the localrc as described below you won\'t have to install configobj (I don\'t think).\nSo change the localrc first, unstack, stack. I don\'t think at that point you\'ll have the configobj issue.\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Rich Curran (rcurran)\nSent: Tuesday, May 07, 2013 2:09 PM\nTo: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling -\n\nHere are instructions I found on installing configobj: http://www.voidspace.org.uk/python/articles/configobj.shtml\n\nAlso, you didn\'t get the latest (master) cisco quantum code.\nIn localrc please add/change:\nOFFLINE=False\nRECLONE=yes\n\nAlso, are you using a nexus hardware switch in your topology?\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, May 07, 2013 1:46 PM\nTo: openstack-dev at lists.openstack.org\nCc: Rich Curran (rcurran)\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nThanks very much for the information... I just tried commenting out #QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I still hit the same issue.\n\n>From reading the log, I can see quantum was trying to pick up cisco plugin. However, it failed at importing configobj at cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t see any instructions for changing this environment variable)\n\nWhen you mentioned that\n>\' this assumes another\n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly\'.\n\nDo I need to pick up this change as well? The only thing I picked up was Robert\'s file of lib/quantum_plugins/cisco...the rest running on my environment was devstack grizzly release...\n\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Tuesday, May 07, 2013 6:42 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another \n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please \n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that \n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you \n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly \n>>installation \n>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link \n>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and \n>>set Q_plugin = cisco.\n>> \n>> However, when I run stack.sh, Quantum server was not able to start \n>>with the following error in screen-q-svc.log:\n>> \n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line \n>>24, in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration \n>>as  conf  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as \n>>confp  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file \n>>/etc/quantum/api-paste.ini.\n>> \n>> Any idea why there\'s an input error for loading \'configobj\'? this \n>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>Why quantum cannot load this file?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> Thanks Kyle and Robert very much for all these information.\n>> \n>> So, it seems that the new devstack version that contains Cisco plugin \n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this \n>>Havana version(release)?\n>> \n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on \n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>_fo\n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>ava\n>>na_Release.29?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> \n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> I should note Robert\'s review for adding support to devstack for the \n>>Cisco plugin is here:\n>> \n>> https://review.openstack.org/#/c/25378/\n>> \n>> I\'ve been running with it for a few weeks and it works great!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> \n>>> Hi YuLing,\n>>> \n>>> My guess is that you pulled the code from the master. So please \n>>>follow this link \n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>k_f\n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>8Ha\n>>>vana_Release.29 instead.\n>>> \n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available \n>>>in devstack yet, and it\'s being worked on. Therefore you have to \n>>>manually configure it with instructions given in the above link.\n>>> \n>>> Thanks,\n>>> Robert\n>>> \n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>> \n>>>> Hi All,\n>>>> \n>>>> I\'m new to devstack and would need to configure cisco plugin to \n>>>>work in devstack environment. I followed the instruction in the \n>>>>webpage \n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>ork\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack \n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>> \n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is \n>>>>not one of the plugins supported under \n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure \n>>>>this variable in localrc? If not, what else I need to do in order \n>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>> \n>>>> Thanks,\n>>>> \n>>>> YuLing\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<96B198D1930C1D489CDF84797AC8170E21113A@xmb-rcd-x13.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E1501519BE@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 01:39:08',-18000,'2013-05-07 06:39:08',NULL,'[openstack-dev] how to configure cisco plugin in devstack\n environment','Actually, I just followed the instruction on devstack grizzly installation link:http://networkstatic.net/installing-openstack-grizzly-with-devstack/\nand installed again. I copied over the \'cisco\' file from the link https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and set Q_plugin = cisco.\n\nHowever, when I run stack.sh, Quantum server was not able to start with the following error in screen-q-svc.log:\n\n    __import__(mod_str)\n  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\", line 30, in <module>\n    from quantum.plugins.cisco.common import cisco_utils as cutil\n  File \"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n    from quantum.plugins.cisco.db import l2network_db as cdb\n  File \"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line 24, in <module>\n    from quantum.plugins.cisco import l2network_plugin_configuration as conf\n  File \"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.py\", line 21, in <module>\n    from quantum.plugins.cisco.common import cisco_configparser as confp\n  File \"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\", line 19, in <module>\n    from configobj import ConfigObj\nImportError: No module named configobj\nERROR: Unable to load quantum from configuration file /etc/quantum/api-paste.ini.\n\nAny idea why there\'s an input error for loading \'configobj\'? this file should be under /usr/lib/python2.7/dist-packages/landscape/lib. Why quantum cannot load this file?\n\nThanks,\n\nYuLing\n\n________________________________________\nFrom: C, Yuling\nSent: Monday, May 06, 2013 7:58 PM\nTo: openstack-dev at lists.openstack.org\nCc: rcurran at cisco.com\nSubject: Re: [openstack-dev] how to configure cisco plugin in devstack environment\n\nThanks Kyle and Robert very much for all these information.\n\nSo, it seems that the new devstack version that contains Cisco plugin support is already available at https://review.openstack.org/#/c/25378/? Should I just use \'git fetch\' to download it and install? Is this Havana version(release)?\n\nAfter I download, can I just use Q_plugin to configure the core plugin? Do I still need to follow the manual set up steps on https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29?\n\nThanks,\n\nYuLing\n\n\n-----Original Message-----\nFrom: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\nSent: Monday, May 06, 2013 2:09 PM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: Re: [openstack-dev] how to configure cisco plugin in devstack environment\n\nI should note Robert\'s review for adding support to devstack for the Cisco plugin is here:\n\nhttps://review.openstack.org/#/c/25378/\n\nI\'ve been running with it for a few weeks and it works great!\n\nThanks,\nKyle\n\nOn May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n\n> Hi YuLing,\n>\n> My guess is that you pulled the code from the master. So please follow this link https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29 instead.\n>\n> Currently, configuring Q_PLUGIN to use cisco plugin is not available in devstack yet, and it\'s being worked on. Therefore you have to manually configure it with instructions given in the above link.\n>\n> Thanks,\n> Robert\n>\n> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>\n>> Hi All,\n>>\n>> I\'m new to devstack and would need to configure cisco plugin to work in devstack environment. I followed the instruction in the webpage (https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Grizzly_Release.29) to configure cisco plugin. However, devstack seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>\n>> I tried to set up Q_plugin in localrc. However, it seems cisco is not one of the plugins supported under /opt/stack/devstack/lib/quantum_plugins...do I need to configure this variable in localrc? If not, what else I need to do in order for openstack to pick up Cisco plugin in devstack environment?\n>>\n>> Thanks,\n>>\n>> YuLing\n>>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0B87C97B6D8E0B43BAF497C2B90FA0F3E15011A18E@AUSX7MCPC101.AMER.DELL.COM>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E1501DCF39@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-14 16:51:35',-18000,'2013-05-14 21:51:35',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Hi Rich,\n\nI was able to use Robert\'s file of lib/quantum_plugins/cisco to run cisco plugin in devstack environment. However, I\'m not sure if everything was set up correctly in my environment. I thought this configuration using Q_plugin=cisco in localrc would set up exactly the same environment as what the instructions on the following attached link describes. However, I was not able to see the \'quantum_l2network\' database at all. All I saw was database \'cisco_quantum\'.  Is there anything wrong in my set up? Should I see \'quantum_l2network\' at all?\n \nhttps://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: C, Yuling \nSent: Tuesday, May 07, 2013 11:40 AM\nTo: \'Rich Curran (rcurran)\'; OpenStack Development Mailing List\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nB.T.W.,  I\'m not planning to use a Nexus switch in my testing environment for now...just would like to use the fake driver to see how it goes...will plugin a real switch later:-)\n\nThanks very much,\n\nYuLing\n\n-----Original Message-----\nFrom: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\nSent: Tuesday, May 07, 2013 11:13 AM\nTo: OpenStack Development Mailing List; C, Yuling\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHI Yuling -\n\nActually if you change the localrc as described below you won\'t have to install configobj (I don\'t think).\nSo change the localrc first, unstack, stack. I don\'t think at that point you\'ll have the configobj issue.\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Rich Curran (rcurran)\nSent: Tuesday, May 07, 2013 2:09 PM\nTo: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling -\n\nHere are instructions I found on installing configobj: http://www.voidspace.org.uk/python/articles/configobj.shtml\n\nAlso, you didn\'t get the latest (master) cisco quantum code.\nIn localrc please add/change:\nOFFLINE=False\nRECLONE=yes\n\nAlso, are you using a nexus hardware switch in your topology?\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, May 07, 2013 1:46 PM\nTo: openstack-dev at lists.openstack.org\nCc: Rich Curran (rcurran)\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nThanks very much for the information... I just tried commenting out #QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I still hit the same issue.\n\n>From reading the log, I can see quantum was trying to pick up cisco plugin. However, it failed at importing configobj at cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t see any instructions for changing this environment variable)\n\nWhen you mentioned that\n>\' this assumes another\n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly\'.\n\nDo I need to pick up this change as well? The only thing I picked up was Robert\'s file of lib/quantum_plugins/cisco...the rest running on my environment was devstack grizzly release...\n\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Tuesday, May 07, 2013 6:42 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another \n>change (cisco-single-config blueprint) that was committed to the \n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please \n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that \n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack \n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you \n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly \n>>installation \n>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link \n>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and \n>>set Q_plugin = cisco.\n>> \n>> However, when I run stack.sh, Quantum server was not able to start \n>>with the following error in screen-q-svc.log:\n>> \n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line \n>>24, in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration \n>>as  conf  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as \n>>confp  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file \n>>/etc/quantum/api-paste.ini.\n>> \n>> Any idea why there\'s an input error for loading \'configobj\'? this \n>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>Why quantum cannot load this file?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> Thanks Kyle and Robert very much for all these information.\n>> \n>> So, it seems that the new devstack version that contains Cisco plugin \n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this \n>>Havana version(release)?\n>> \n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on \n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>_fo\n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>ava\n>>na_Release.29?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> \n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in \n>> devstack environment\n>> \n>> I should note Robert\'s review for adding support to devstack for the \n>>Cisco plugin is here:\n>> \n>> https://review.openstack.org/#/c/25378/\n>> \n>> I\'ve been running with it for a few weeks and it works great!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> \n>>> Hi YuLing,\n>>> \n>>> My guess is that you pulled the code from the master. So please \n>>>follow this link \n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>k_f\n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>8Ha\n>>>vana_Release.29 instead.\n>>> \n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available \n>>>in devstack yet, and it\'s being worked on. Therefore you have to \n>>>manually configure it with instructions given in the above link.\n>>> \n>>> Thanks,\n>>> Robert\n>>> \n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>> \n>>>> Hi All,\n>>>> \n>>>> I\'m new to devstack and would need to configure cisco plugin to \n>>>>work in devstack environment. I followed the instruction in the \n>>>>webpage \n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>ork\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack \n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>> \n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is \n>>>>not one of the plugins supported under \n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure \n>>>>this variable in localrc? If not, what else I need to do in order \n>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>> \n>>>> Thanks,\n>>>> \n>>>> YuLing\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15022F002@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 20:19:14',-18000,'2013-05-16 01:19:14',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Hi Rich,\n\nThe original problem that I had was if I do not enable Q_PLUGIN=cisco, the core_plugin will always be OVS plugin instead of Cisco plugin.\n\nI don\'t have a Cisco device yet, however, I will eventually test on Cisco Nexus switch.  I do want to go as far as possible with Nexus fake driver. So, do you think with Q_PLUGIN=cisco, am  I going to see pretty much the same environment as that of plugging a real device? I thought at least the data base tables would be the same as what I will see with a real switch...\n\nSo, if I would like to go as far as possible, do I need to follow your instruction to set subplugins, i.e. declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)?\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\nSent: Tuesday, May 14, 2013 5:42 PM\nTo: C, Yuling; openstack-dev at lists.openstack.org; Robert Li (baoli)\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling -\n\nAre you now using either an external nexus switch and/or the Nexus 1000 in your topology?\nIf not then I don\'t know why you would enable Q_PLUGIN=cisco in devstack\'s localrc.\n\nBut if you want to move forward regardless of available Cisco devices then you would have to follow the instructions listed in that web link below or you can add some additional information to the localrc file. Robert has put this info on a Cisco internal webpage so I\'ll cut/paste here. At some point (if he hasn\'t already) we should add this info to the devstack.org documentation.\n=====================================================\nCustomization in localrc\n\nIn addition to existing DevStack variables, DevStack with Cisco plugin supports the following bash variables that can be defined in localrc.\ndeclare -a Q_CISCO_PLUGIN_SUBPLUGINS\n\nSupported values are:\n    (openvswitch)\n    (openvswitch nexus)\n    (n1kv)\n    (n1kv nexus)\n\nDefines the subplugins that will be deployed with this DevStack. For example:\n\ndeclare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)\n------------------------------------------------------\ndeclare -A Q_CISCO_PLUGIN_SWITCH_INFO\n\nThe value has the following format:\n ({<switch_ip>=<username>:<password>:<ssh_port>[:<compute-host-name>:<nexus-port-connected-with>] })\n\nDefines the nexus switch information used in the deployment. This is a bash associative array with nexus switch ip addresses as keys. Essentially, it defines the switch\'s access information, and the compute hosts that are connected to the switch. An example looks like\n             declare -A Q_CISCO_PLUGIN_SWITCH_INFO= ([1.1.1.1]=admin:mySecretPassword:22:compute1:1/1:compute2:1/2)\n\nIf Q_CISCO_PLUGIN_SWITCH_INFO is not defined in localrc, it assumes no switch is used in the deployment. In that case, if the nexus subplugin is deployed (as indicated by the Q_CISCO_PLUGIN_SUBPLUGINS array), a fake switch (with a fake driver) will be deployed.\n\n**** - Note - since you\'re not using any cisco devices I wouldn\'t declare this variable and have the fake nexus driver configured.\n======================================================\nThanks,\nRich\n\n-----Original Message-----\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, May 14, 2013 5:52 PM\nTo: Rich Curran (rcurran); openstack-dev at lists.openstack.org\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Rich,\n\nI was able to use Robert\'s file of lib/quantum_plugins/cisco to run cisco plugin in devstack environment. However, I\'m not sure if everything was set up correctly in my environment. I thought this configuration using Q_plugin=cisco in localrc would set up exactly the same environment as what the instructions on the following attached link describes. However, I was not able to see the \'quantum_l2network\' database at all. All I saw was database \'cisco_quantum\'.  Is there anything wrong in my set up? Should I see \'quantum_l2network\' at all?\n\nhttps://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: C, Yuling\nSent: Tuesday, May 07, 2013 11:40 AM\nTo: \'Rich Curran (rcurran)\'; OpenStack Development Mailing List\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nB.T.W.,  I\'m not planning to use a Nexus switch in my testing environment for now...just would like to use the fake driver to see how it goes...will plugin a real switch later:-)\n\nThanks very much,\n\nYuLing\n\n-----Original Message-----\nFrom: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\nSent: Tuesday, May 07, 2013 11:13 AM\nTo: OpenStack Development Mailing List; C, Yuling\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHI Yuling -\n\nActually if you change the localrc as described below you won\'t have to install configobj (I don\'t think).\nSo change the localrc first, unstack, stack. I don\'t think at that point you\'ll have the configobj issue.\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Rich Curran (rcurran)\nSent: Tuesday, May 07, 2013 2:09 PM\nTo: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling -\n\nHere are instructions I found on installing configobj: http://www.voidspace.org.uk/python/articles/configobj.shtml\n\nAlso, you didn\'t get the latest (master) cisco quantum code.\nIn localrc please add/change:\nOFFLINE=False\nRECLONE=yes\n\nAlso, are you using a nexus hardware switch in your topology?\n\nThanks,\nRich\n\n-----Original Message-----\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, May 07, 2013 1:46 PM\nTo: openstack-dev at lists.openstack.org\nCc: Rich Curran (rcurran)\nSubject: RE: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nThanks very much for the information... I just tried commenting out #QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I still hit the same issue.\n\n>From reading the log, I can see quantum was trying to pick up cisco plugin. However, it failed at importing configobj at cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t see any instructions for changing this environment variable)\n\nWhen you mentioned that\n>\' this assumes another\n>change (cisco-single-config blueprint) that was committed to the\n>openstack master branch but didn\'t make it into stable/grizzly\'.\n\nDo I need to pick up this change as well? The only thing I picked up was Robert\'s file of lib/quantum_plugins/cisco...the rest running on my environment was devstack grizzly release...\n\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Tuesday, May 07, 2013 6:42 AM\nTo: OpenStack Development Mailing List\nCc: Rich Curran (rcurran)\nSubject: [openstack-dev] FW: how to configure cisco plugin in devstack environment\n\nHi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack\n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another\n>change (cisco-single-config blueprint) that was committed to the\n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please\n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that\n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you\n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly\n>>installation\n>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link\n>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and\n>>set Q_plugin = cisco.\n>>\n>> However, when I run stack.sh, Quantum server was not able to start\n>>with the following error in screen-q-svc.log:\n>>\n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil File\n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line 23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File\n>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line\n>>24, in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration\n>>as  conf  File\n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as\n>>confp  File\n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file\n>>/etc/quantum/api-paste.ini.\n>>\n>> Any idea why there\'s an input error for loading \'configobj\'? this\n>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>Why quantum cannot load this file?\n>>\n>> Thanks,\n>>\n>> YuLing\n>>\n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>> devstack environment\n>>\n>> Thanks Kyle and Robert very much for all these information.\n>>\n>> So, it seems that the new devstack version that contains Cisco plugin\n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this\n>>Havana version(release)?\n>>\n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on\n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>_fo\n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>ava\n>>na_Release.29?\n>>\n>> Thanks,\n>>\n>> YuLing\n>>\n>>\n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>> devstack environment\n>>\n>> I should note Robert\'s review for adding support to devstack for the\n>>Cisco plugin is here:\n>>\n>> https://review.openstack.org/#/c/25378/\n>>\n>> I\'ve been running with it for a few weeks and it works great!\n>>\n>> Thanks,\n>> Kyle\n>>\n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>>\n>>> Hi YuLing,\n>>>\n>>> My guess is that you pulled the code from the master. So please\n>>>follow this link\n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>k_f\n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>8Ha\n>>>vana_Release.29 instead.\n>>>\n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available\n>>>in devstack yet, and it\'s being worked on. Therefore you have to\n>>>manually configure it with instructions given in the above link.\n>>>\n>>> Thanks,\n>>> Robert\n>>>\n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>>\n>>>> Hi All,\n>>>>\n>>>> I\'m new to devstack and would need to configure cisco plugin to\n>>>>work in devstack environment. I followed the instruction in the\n>>>>webpage\n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>ork\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack\n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>>\n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is\n>>>>not one of the plugins supported under\n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure\n>>>>this variable in localrc? If not, what else I need to do in order\n>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>>\n>>>> Thanks,\n>>>>\n>>>> YuLing\n>>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<96B198D1930C1D489CDF84797AC8170E212DDF@xmb-rcd-x13.cisco.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E15439A8EC@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 02:09:38',-18000,'2013-06-10 07:09:38',NULL,'[openstack-dev] [Quantum] VM instances created on two devstack\n instances cannot ping each other','Hi All,\n\nI installed two devstack instances on two physical servers. Both physical servers connect to a same physical switch. I configured cisco plugin overlay on top of ovs plugin. I also turned on VLAN network type. I created one VM instance on physical server 1, and another VM instance on physical server 2. However, I was not able to ping from VM1 to VM2.\n\nOn each physical server, I\n\n\n1.      manually created br-eth1, which connects to physical NIC eth1.\n\novs-vsctl add-br br-eth1\n\novs-vsctl add-port br-eth1 eth1\n\n\n\neth1 on each physical server connects to the data network.\n\n\n2.      I configured the physical switch port to be tagged vlan with the same vlan id as what was allocated to both VM instances on these two devstack servers.\n\n3.      Both of the VM instances were created on the same network with same vlan id.\n\nI\'m not sure why VM1 could not ping VM2? Did I miss any steps?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130610/39395ede/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E1543EA1BA@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 00:26:54',-18000,'2013-06-14 05:26:54',NULL,'[openstack-dev] [Quantum] cannot receive icmp request in vm\n instance from different network(vlan)?','Hi All,\n\nWe encountered a problem that the icmp ping request could not reach vm instance from different network(vlan). When we created two vm instances on two different compute nodes (using cirros image), the icmp ping request reached the physical server of the compute node, but could not get icmp reply. Just wondering if the vm instance created using cirros is capable of supporting icmp ping request from different vlans? Any configuration needed in the vm instance for supporting that?\n\nThanks,\n\nYuLing\n\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E1543EA1BC@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 00:44:05',-18000,'2013-06-14 05:44:05',NULL,'[openstack-dev] [Quantum] cannot receive icmp request in vm\n instance from different network(vlan)?','I just checked the \'ip a |grep state\' and the physical bridge seems to be in \'unknown\' state. Would this be an issue?\n\n9: br-eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN\n10: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN\n\nThanks,\n\nYuLing\n-----Original Message-----\nFrom: C, Yuling \nSent: Thursday, June 13, 2013 10:27 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Quantum] cannot receive icmp request in vm instance from different network(vlan)?\n\nHi All,\n\nWe encountered a problem that the icmp ping request could not reach vm instance from different network(vlan). When we created two vm instances on two different compute nodes (using cirros image), the icmp ping request reached the physical server of the compute node, but could not get icmp reply. Just wondering if the vm instance created using cirros is capable of supporting icmp ping request from different vlans? Any configuration needed in the vm instance for supporting that?\n\nThanks,\n\nYuLing\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0B87C97B6D8E0B43BAF497C2B90FA0F3E1543EA1BA@AUSX7MCPC101.AMER.DELL.COM>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E1543EA1C4@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 01:45:01',-18000,'2013-06-14 06:45:01',NULL,'[openstack-dev] [Quantum] cannot receive icmp request in vm\n instance from different network(vlan)?','Hi All,\n\nIn order to ping between two vm instances on two vlans, do I need to create two physical bridges for the two vlans and associate(tag) the two vlans to these two physical bridges?\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: C, Yuling \nSent: Thursday, June 13, 2013 10:27 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Quantum] cannot receive icmp request in vm instance from different network(vlan)?\n\nHi All,\n\nWe encountered a problem that the icmp ping request could not reach vm instance from different network(vlan). When we created two vm instances on two different compute nodes (using cirros image), the icmp ping request reached the physical server of the compute node, but could not get icmp reply. Just wondering if the vm instance created using cirros is capable of supporting icmp ping request from different vlans? Any configuration needed in the vm instance for supporting that?\n\nThanks,\n\nYuLing\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0B87C97B6D8E0B43BAF497C2B90FA0F3E1543EA1BA@AUSX7MCPC101.AMER.DELL.COM>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E16FB6AA87@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 01:18:08',-18000,'2013-08-20 06:18:08',NULL,'[Openstack]  \'sudo ovs-vsctl\' hit no tty issue','Hi All,\n\nI\'m developing a Quantum plugin and need to run \'sudo ovs-vsctl\' command in my python code. When I run it as a script on Ubuntu, it was OK. However, if I run it as a background service(process), I hit the following error:\n\n\nYuLing debug -->line=sudo: no tty present and no askpass program specified\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=Sorry, try again.\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=sudo: no tty present and no askpass program specified\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=Sorry, try again.\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=sudo: no tty present and no askpass program specified\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=Sorry, try again.\n2013-08-19 23:12:29    DEBUG [quantum.plugins.dell.agent.dell_ovs_quantum_agent] YuLing debug -->line=sudo: 3 incorrect password attempts\n\nI tried to play around with /etc/sudoers to turn off requiretty parameter. However it didn\'t help...any idea?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/308a627d/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E172A94218@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-03 01:27:56',-21600,'2013-11-03 07:27:56',NULL,'[Openstack] Keystone commands time out. Cannot log onto openstack\n	horizon GUI','Dell - Internal Use - Confidential\nHi All,\n\nWe have been using openstack pretty well for quite a few months. Suddenly, after a controller server reboot, we were not able to log onto horizon GUI. The login page was prompted. However, after we typed the correct user name and password, we got error message saying \"Something went wrong\".\n\nI guess it is the keystone issue. When I tried the commands \'keystone user-list\' and \'keystone role-list\', I got \'[Error 110]Connection time out\' after some time. I tried to sync db by executing \'keystone-manage db_sync\'. The command went through fine, but the issue still stayed the same.\n\nI turned on debug in keystone.conf. However, I was not able to find any useful info in the keystone.log.\n\nAny ideas? We are using Grizzly version of openstack.\n\nThanks very much,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131103/eddbda80/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175AC69E4@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-17 20:46:39',-21600,'2013-12-18 02:46:39',NULL,'[Openstack] vm instances could not get ip address from dhcp agent','Hi All,\n\nI have an openstack installation environment of two nodes. One node contains Controller, Network, Nova, Glance, Keystone, Client, and Cinder. The other node is just a nova_compute node.   Everything worked very well before. Suddenly we hit the issue that vm instances could not get ip addresses from dhcp agent.  I looked into dhcp-agent.log, but didn\'t find much useful information. Just wondering if someone could shed some light on this issue.\n\nThe behavior is that even the VMs created on node1, which contains Controller, Network, Nova, Glance, keystone, Client and Cinder could not get the IP from dhcp agent. When I use tcpdump -i br-ehter1, or tcpdump -i < physical Ethernet port id>, I was able to see the DHCP requests, but no reply from dhcp agent.\n\nAny idea?\n\nThanks,\n\nYuLing\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131217/f0acb132/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175AC6A01@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-17 23:37:23',-21600,'2013-12-18 05:37:23',NULL,'[Openstack] vm instances could not get ip address from dhcp\n	agent','B.T.W, I just noticed that \'brctl show\' command does not show any attached interface on this test bed. Could this be the root cause?\n# brctl show\nbridge name     bridge id               STP enabled     interfaces\nvirbr0          8000.525400046ff3       yes             virbr0-nic\n\nAlso, I saw error message as \'2013-12-17 21:33:47.586 32628 ERROR nova.virt.libvirt.driver [-] Getting disk size of foreman: [Errno 2] No such file or directory: \'/var/lib/libvirt/images/foreman.img\'\'.\n\nAny clue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 6:47 PM\nTo: openstack at lists.openstack.org\nSubject: vm instances could not get ip address from dhcp agent\n\nHi All,\n\nI have an openstack installation environment of two nodes. One node contains Controller, Network, Nova, Glance, Keystone, Client, and Cinder. The other node is just a nova_compute node.   Everything worked very well before. Suddenly we hit the issue that vm instances could not get ip addresses from dhcp agent.  I looked into dhcp-agent.log, but didn\'t find much useful information. Just wondering if someone could shed some light on this issue.\n\nThe behavior is that even the VMs created on node1, which contains Controller, Network, Nova, Glance, keystone, Client and Cinder could not get the IP from dhcp agent. When I use tcpdump -i br-ehter1, or tcpdump -i < physical Ethernet port id>, I was able to see the DHCP requests, but no reply from dhcp agent.\n\nAny idea?\n\nThanks,\n\nYuLing\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131217/f4f4af80/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175AC6A08@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 01:41:07',-21600,'2013-12-18 07:41:07',NULL,'[Openstack] vm instances could not get ip address from dhcp\n	agent','Actually, I found that the tcpdump -i \'tapf9884dcb-e5\' got dhcp reply. However, tcpdump -i br-int only has dhcp request.\n\nAlso, when I tried to get ip address on the dhcp agent, I was not able to see \'tapf9884dcb-e5\'\n\nip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333\nNo cmd specified\n[root at blade04 quantum]# ip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333 ip address\n15: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8 scope host lo\n    inet6 ::1/128 scope host\n       valid_lft forever preferred_lft forever\n18: ns-f9884dcb-e5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000\n    link/ether fa:16:3e:a1:d5:e2 brd ff:ff:ff:ff:ff:ff\n    inet 30.0.0.3/24 brd 30.0.0.255 scope global ns-f9884dcb-e5\n    inet6 fe80::f816:3eff:fea1:d5e2/64 scope link\n       valid_lft forever preferred_lft forever\n\nWould this be an issue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 9:37 PM\nTo: \'openstack at lists.openstack.org\'\nSubject: RE: vm instances could not get ip address from dhcp agent\n\nB.T.W, I just noticed that \'brctl show\' command does not show any attached interface on this test bed. Could this be the root cause?\n# brctl show\nbridge name     bridge id               STP enabled     interfaces\nvirbr0          8000.525400046ff3       yes             virbr0-nic\n\nAlso, I saw error message as \'2013-12-17 21:33:47.586 32628 ERROR nova.virt.libvirt.driver [-] Getting disk size of foreman: [Errno 2] No such file or directory: \'/var/lib/libvirt/images/foreman.img\'\'.\n\nAny clue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 6:47 PM\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: vm instances could not get ip address from dhcp agent\n\nHi All,\n\nI have an openstack installation environment of two nodes. One node contains Controller, Network, Nova, Glance, Keystone, Client, and Cinder. The other node is just a nova_compute node.   Everything worked very well before. Suddenly we hit the issue that vm instances could not get ip addresses from dhcp agent.  I looked into dhcp-agent.log, but didn\'t find much useful information. Just wondering if someone could shed some light on this issue.\n\nThe behavior is that even the VMs created on node1, which contains Controller, Network, Nova, Glance, keystone, Client and Cinder could not get the IP from dhcp agent. When I use tcpdump -i br-ehter1, or tcpdump -i < physical Ethernet port id>, I was able to see the DHCP requests, but no reply from dhcp agent.\n\nAny idea?\n\nThanks,\n\nYuLing\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131218/bea7d953/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175AC6BBD@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 14:07:35',-21600,'2013-12-18 20:07:35',NULL,'[Openstack] vm instances could not get ip address from dhcp\n agent','Hi Pranav,\n\nThanks for the reply. Actually I\'m using Redhat. Do you think we can execute the same command to recompile the Kernal?\n\nAlso, another behavior that really concerned me was that \'brctl show\' does not list anything when we create the VM instances. Does this indicate that integration bridge is not functioning?\n\nThanks,\n\nYuLing\n\nFrom: Pranav Salunke [mailto:pranav at aptira.com]\nSent: Wednesday, December 18, 2013 7:04 AM\nTo: C, Yuling\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] vm instances could not get ip address from dhcp agent\n\nHi Yuling,\nI am getting similar issues with Havana, but in my case I saw that OVS 1.10 shows build error while compiling its packages. Can you do\n# dpkg-reconfigure openvswitch-datapath-dmks\n(assuming you are using ubuntu/debian)\nor something similar and check the output, esp. when its recompiling the kernel.\nRegards,\nPranav\n\n--\n\nPranav Salunke\nCloud Engineer\n[http://aptira.com/images/logo.jpg]\n+91 97129 29850\n+612 8030 2333\n1800 APTIRA\naptira.com<http://aptira.com/>\nFollow @aptira<https://twitter.com/#!/aptira>\n\nOn 18 December 2013 13:11, <Yuling_C at dell.com<mailto:Yuling_C at dell.com>> wrote:\nActually, I found that the tcpdump -i \'tapf9884dcb-e5\' got dhcp reply. However, tcpdump -i br-int only has dhcp request.\n\nAlso, when I tried to get ip address on the dhcp agent, I was not able to see \'tapf9884dcb-e5\'\n\nip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333\nNo cmd specified\n[root at blade04 quantum]# ip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333 ip address\n15: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8<http://127.0.0.1/8> scope host lo\n    inet6 ::1/128 scope host\n       valid_lft forever preferred_lft forever\n18: ns-f9884dcb-e5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000\n    link/ether fa:16:3e:a1:d5:e2 brd ff:ff:ff:ff:ff:ff\n    inet 30.0.0.3/24<http://30.0.0.3/24> brd 30.0.0.255 scope global ns-f9884dcb-e5\n    inet6 fe80::f816:3eff:fea1:d5e2/64 scope link\n       valid_lft forever preferred_lft forever\n\nWould this be an issue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 9:37 PM\nTo: \'openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\'\nSubject: RE: vm instances could not get ip address from dhcp agent\n\nB.T.W, I just noticed that \'brctl show\' command does not show any attached interface on this test bed. Could this be the root cause?\n# brctl show\nbridge name     bridge id               STP enabled     interfaces\nvirbr0          8000.525400046ff3       yes             virbr0-nic\n\nAlso, I saw error message as \'2013-12-17 21:33:47.586 32628 ERROR nova.virt.libvirt.driver [-] Getting disk size of foreman: [Errno 2] No such file or directory: \'/var/lib/libvirt/images/foreman.img\'\'.\n\nAny clue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 6:47 PM\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: vm instances could not get ip address from dhcp agent\n\nHi All,\n\nI have an openstack installation environment of two nodes. One node contains Controller, Network, Nova, Glance, Keystone, Client, and Cinder. The other node is just a nova_compute node.   Everything worked very well before. Suddenly we hit the issue that vm instances could not get ip addresses from dhcp agent.  I looked into dhcp-agent.log, but didn\'t find much useful information. Just wondering if someone could shed some light on this issue.\n\nThe behavior is that even the VMs created on node1, which contains Controller, Network, Nova, Glance, keystone, Client and Cinder could not get the IP from dhcp agent. When I use tcpdump -i br-ehter1, or tcpdump -i < physical Ethernet port id>, I was able to see the DHCP requests, but no reply from dhcp agent.\n\nAny idea?\n\nThanks,\n\nYuLing\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131218/5a49d92a/attachment.html>\n\n','<CABTxxEF7J5if5+sTsQtR3izm431xgpe6Prq3PKY-VBCsHzpAOQ@mail.gmail.com>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175AC6C1F@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 15:47:01',-21600,'2013-12-18 21:47:01',NULL,'[Openstack] vm instances could not get ip address from dhcp\n agent','Thanks Remo for the reply. The first question that I probably need to ask is that if I should recompile the Kernal  when I see this ?brctl show? issue? If I do, do you know the command to run on Redhat for re-compiling the Kernal?\n\nThanks,\n\nYuLing\n\nFrom: Remo Mattei [mailto:remo at mattei.org]\nSent: Wednesday, December 18, 2013 12:36 PM\nTo: C, Yuling\nCc: <pranav at aptira.com>; openstack at lists.openstack.org\nSubject: Re: [Openstack] vm instances could not get ip address from dhcp agent\n\nThat command does not work on yum\nYou may have to compile it.\n\nRemo\nInviato da iPhone (?)\n\nIl giorno Dec 18, 2013, alle ore 12:07, <Yuling_C at DELL.com<mailto:Yuling_C at DELL.com>> ha scritto:\nHi Pranav,\n\nThanks for the reply. Actually I?m using Redhat. Do you think we can execute the same command to recompile the Kernal?\n\nAlso, another behavior that really concerned me was that ?brctl show? does not list anything when we create the VM instances. Does this indicate that integration bridge is not functioning?\n\nThanks,\n\nYuLing\n\nFrom: Pranav Salunke [mailto:pranav at aptira.com]\nSent: Wednesday, December 18, 2013 7:04 AM\nTo: C, Yuling\nCc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] vm instances could not get ip address from dhcp agent\n\nHi Yuling,\nI am getting similar issues with Havana, but in my case I saw that OVS 1.10 shows build error while compiling its packages. Can you do\n# dpkg-reconfigure openvswitch-datapath-dmks\n(assuming you are using ubuntu/debian)\nor something similar and check the output, esp. when its recompiling the kernel.\nRegards,\nPranav\n\n--\n\nPranav Salunke\nCloud Engineer\n[http://aptira.com/images/logo.jpg]\n+91 97129 29850\n+612 8030 2333\n1800 APTIRA\naptira.com<http://aptira.com/>\nFollow @aptira<https://twitter.com/#!/aptira>\n\nOn 18 December 2013 13:11, <Yuling_C at dell.com<mailto:Yuling_C at dell.com>> wrote:\nActually, I found that the tcpdump ?i ?tapf9884dcb-e5? got dhcp reply. However, tcpdump ?i br-int only has dhcp request.\n\nAlso, when I tried to get ip address on the dhcp agent, I was not able to see ?tapf9884dcb-e5?\n\nip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333\nNo cmd specified\n[root at blade04 quantum]# ip netns exec qdhcp-7e73481a-d100-46d4-8dd1-9b3bb7949333 ip address\n15: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8<http://127.0.0.1/8> scope host lo\n    inet6 ::1/128 scope host\n       valid_lft forever preferred_lft forever\n18: ns-f9884dcb-e5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000\n    link/ether fa:16:3e:a1:d5:e2 brd ff:ff:ff:ff:ff:ff\n    inet 30.0.0.3/24<http://30.0.0.3/24> brd 30.0.0.255 scope global ns-f9884dcb-e5\n    inet6 fe80::f816:3eff:fea1:d5e2/64 scope link\n       valid_lft forever preferred_lft forever\n\nWould this be an issue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 9:37 PM\nTo: \'openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\'\nSubject: RE: vm instances could not get ip address from dhcp agent\n\nB.T.W, I just noticed that ?brctl show? command does not show any attached interface on this test bed. Could this be the root cause?\n# brctl show\nbridge name     bridge id               STP enabled     interfaces\nvirbr0          8000.525400046ff3       yes             virbr0-nic\n\nAlso, I saw error message as ?2013-12-17 21:33:47.586 32628 ERROR nova.virt.libvirt.driver [-] Getting disk size of foreman: [Errno 2] No such file or directory: \'/var/lib/libvirt/images/foreman.img\'?.\n\nAny clue?\n\nThanks,\n\nYuLing\nFrom: C, Yuling\nSent: Tuesday, December 17, 2013 6:47 PM\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: vm instances could not get ip address from dhcp agent\n\nHi All,\n\nI have an openstack installation environment of two nodes. One node contains Controller, Network, Nova, Glance, Keystone, Client, and Cinder. The other node is just a nova_compute node.   Everything worked very well before. Suddenly we hit the issue that vm instances could not get ip addresses from dhcp agent.  I looked into dhcp-agent.log, but didn?t find much useful information. Just wondering if someone could shed some light on this issue.\n\nThe behavior is that even the VMs created on node1, which contains Controller, Network, Nova, Glance, keystone, Client and Cinder could not get the IP from dhcp agent. When I use tcpdump ?i br-ehter1, or tcpdump ?i < physical Ethernet port id>, I was able to see the DHCP requests, but no reply from dhcp agent.\n\nAny idea?\n\nThanks,\n\nYuLing\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n!DSPAM:2,52b20461325531044020254!\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n!DSPAM:2,52b20461325531044020254!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131218/54dcbe83/attachment.html>\n\n','<4B65261A-3D0B-463F-B15F-0E289BCF7E18@mattei.org>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175C540F0@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-21 21:27:09',-21600,'2013-12-22 03:27:09',NULL,'[Openstack] Does LibvirtOpenVswitchVirtualPortDriver work with DHCP\n agent/dnsmasq?','Hi All,\n\nDoes anyone know if LibvirtOpenVswitchVirtualPortDriver work with DHCP agent/dnsmasq on Grizzly?  If it does, is there any special configuration needed? I have a test bed with  LibvirtHybridOVSBridgeDriver configured and working well with DHCP. After I switch to LibvirtOpenVswitchVirtualPortDriver, VMs could not get ip address anymore. Any ideas?\n\nThanks very much,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131221/5f5e1297/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E175C540F2@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-22 00:29:44',-21600,'2013-12-22 06:29:44',NULL,'[openstack-dev] LibvirtOpenVswitchVirtualPortDriver work with DHCP','Hi All,\n\nDoes anyone know if LibvirtOpenVswitchVirtualPortDriver work with DHCP agent/dnsmasq on Grizzly?  If it does, is there any special configuration needed? I have a test bed with  LibvirtHybridOVSBridgeDriver configured and working well with DHCP. After I switch to LibvirtOpenVswitchVirtualPortDriver, VMs could not get ip address anymore. Any ideas?\n\nThanks very much,\n\nYuLing\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131222/ff14bf6e/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E28FC2EFFC@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 01:17:00',-18000,'2014-07-16 06:17:00',NULL,'[openstack-dev] heat stack-create with two vm instances always got\n	one failed','Dell Customer Communication\n\nHi,\nI\'m using heat to create a stack with two instances. I always got one of them successful, but the other would fail. If I split the template into two and each of them contains one instance then it worked. However, I thought Heat template would allow multiple instances being created?\n\nHere I attach the heat template:\n{\n    \"AWSTemplateFormatVersion\" : \"2010-09-09\",\n    \"Description\" : \"Sample Heat template that spins up multiple instances and a private network (JSON)\",\n    \"Resources\" : {\n    \"test_net\" : {\n             \"Type\" : \"OS::Neutron::Net\",\n             \"Properties\" : {\n             \"name\" : \"test_net\"\n              }\n          },\n          \"test_subnet\" : {\n              \"Type\" : \"OS::Neutron::Subnet\",\n              \"Properties\" : {\n              \"name\" : \"test_subnet\",\n              \"cidr\" : \"120.10.9.0/24\",\n              \"enable_dhcp\" : \"True\",\n              \"gateway_ip\" : \"120.10.9.1\",\n              \"network_id\" : { \"Ref\" : \"test_net\" }\n              }\n          },\n         \"test_net_port\" : {\n             \"Type\" : \"OS::Neutron::Port\",\n             \"Properties\" : {\n             \"admin_state_up\" : \"True\",\n             \"network_id\" : { \"Ref\" : \"test_net\" }\n             }\n         },\n         \"instance1\" : {\n             \"Type\" : \"OS::Nova::Server\",\n             \"Properties\" : {\n             \"name\" : \"instance1\",\n             \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n             \"flavor\": \"tvm-tt_lite\",\n             \"networks\" : [\n                 {\"port\" : { \"Ref\" : \"test_net_port\" }}\n             ]\n           }\n       },\n         \"instance2\" : {\n             \"Type\" : \"OS::Nova::Server\",\n             \"Properties\" : {\n             \"name\" : \"instance2\",\n             \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n             \"flavor\": \"tvm-tt_lite\",\n             \"networks\" : [\n                 {\"port\" : { \"Ref\" : \"test_net_port\" }}\n             ]\n           }\n       }\n    }\n}\nThe error that I got from heat-engine.log is as follows:\n\n2014-07-16 01:49:50.514 25101 DEBUG heat.engine.scheduler [-] Task resource_action complete step /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n2014-07-16 01:49:50.515 25101 DEBUG heat.engine.scheduler [-] Task stack_task from Stack \"teststack\" sleeping _sleep /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:108\n2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task stack_task from Stack \"teststack\" running step /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task resource_action running step /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n2014-07-16 01:49:51.960 25101 DEBUG urllib3.connectionpool [-] \"GET /v2/b64803d759e04b999e616b786b407661/servers/7cb9459c-29b3-4a23-a52c-17d85fce0559 HTTP/1.1\" 200 1854 _make_request /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295\n2014-07-16 01:49:51.963 25101 ERROR heat.engine.resource [-] CREATE : Server \"instance1\"\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Traceback (most recent call last):\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource   File \"/usr/lib/python2.6/site-packages/heat/engine/resource.py\", line 371, in _do_action\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource     while not check(handle_data):\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource   File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 239, in check_create_complete\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource     return self._check_active(server)\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource   File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 255, in _check_active\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource     raise exc\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Error: Creation of server instance1 failed.\n2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource\n2014-07-16 01:49:51.996 25101 DEBUG heat.engine.scheduler [-] Task resource_action cancelled cancel /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:187\n2014-07-16 01:49:52.004 25101 DEBUG heat.engine.scheduler [-] Task stack_task from Stack \"teststack\" complete step /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n2014-07-16 01:49:52.005 25101 WARNING heat.engine.service [-] Stack create failed, status FAILED\n2014-07-16 01:50:29.218 25101 DEBUG heat.openstack.common.rpc.amqp [-] received {u\'_context_roles\': [u\'Member\', u\'admin\'], u\'_msg_id\': u\'9aedf86fda304cfc857dc897d8393427\', u\'_context_password\': \'<SANITIZED>\', u\'_context_auth_url\': u\'http://172.17.252.60:5000/v2.0\', u\'_unique_id\': u\'f02188b068de4a4aba0ec203ec3ad54a\', u\'_reply_q\': u\'reply_f841b6a2101d4af9a9af59889630ee77\', u\'_context_aws_creds\': None, u\'args\': {}, u\'_context_tenant\': u\'TVM\', u\'_context_trustor_user_id\': None, u\'_context_trust_id\': None, u\'_context_auth_token\': \'<SANITIZED>\', u\'_context_is_admin\': True, u\'version\': u\'1.0\', u\'_context_tenant_id\': u\'b64803d759e04b999e616b786b407661\', u\'namespace\': None, u\'method\': u\'list_stacks\', u\'_context_username\': None} _safe_log /usr/lib/python2.6/site-packages/heat/openstack/common/rpc/common.py:277\n\nAny idea?\n\nThanks,\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/a21bbea3/attachment.html>\n\n',NULL,NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E28FC2F19D@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 17:07:10',-18000,'2014-07-16 22:07:10',NULL,'[openstack-dev] heat stack-create with two vm instances always\n got one failed','Dell Customer Communication\nThanks very much Qiming. It was the problem and I got it fixed by creating another port for the instance2.\n\nB.T.W., another question. When I delete the stack, how come the network was not deleted? It seems only the instance was deleted. How do I clean up the networks and subnets associated with the instance using heat?\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Qiming Teng [mailto:tengqim at linux.vnet.ibm.com]\nSent: Wednesday, July 16, 2014 3:59 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] heat stack-create with two vm instances always got one failed\n\nIt seems that you are sharing one port between two instances, which won\'t be a legal configuration.\n\nOn Wed, Jul 16, 2014 at 01:17:00AM -0500, Yuling_C at DELL.com wrote:\n> Dell Customer Communication\n>\n> Hi,\n> I\'m using heat to create a stack with two instances. I always got one of them successful, but the other would fail. If I split the template into two and each of them contains one instance then it worked. However, I thought Heat template would allow multiple instances being created?\n>\n> Here I attach the heat template:\n> {\n> \"AWSTemplateFormatVersion\" : \"2010-09-09\",\n> \"Description\" : \"Sample Heat template that spins up multiple instances and a private network (JSON)\",\n> \"Resources\" : {\n> \"test_net\" : {\n> \"Type\" : \"OS::Neutron::Net\",\n> \"Properties\" : {\n> \"name\" : \"test_net\"\n> }\n> },\n> \"test_subnet\" : {\n> \"Type\" : \"OS::Neutron::Subnet\",\n> \"Properties\" : {\n> \"name\" : \"test_subnet\",\n> \"cidr\" : \"120.10.9.0/24\",\n> \"enable_dhcp\" : \"True\",\n> \"gateway_ip\" : \"120.10.9.1\",\n> \"network_id\" : { \"Ref\" : \"test_net\" }\n> }\n> },\n> \"test_net_port\" : {\n> \"Type\" : \"OS::Neutron::Port\",\n> \"Properties\" : {\n> \"admin_state_up\" : \"True\",\n> \"network_id\" : { \"Ref\" : \"test_net\" }\n> }\n> },\n> \"instance1\" : {\n> \"Type\" : \"OS::Nova::Server\",\n> \"Properties\" : {\n> \"name\" : \"instance1\",\n> \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n> \"flavor\": \"tvm-tt_lite\",\n> \"networks\" : [\n> {\"port\" : { \"Ref\" : \"test_net_port\" }}\n> ]\n> }\n> },\n> \"instance2\" : {\n> \"Type\" : \"OS::Nova::Server\",\n> \"Properties\" : {\n> \"name\" : \"instance2\",\n> \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n> \"flavor\": \"tvm-tt_lite\",\n> \"networks\" : [\n> {\"port\" : { \"Ref\" : \"test_net_port\" }}\n> ]\n> }\n> }\n> }\n> }\n> The error that I got from heat-engine.log is as follows:\n>\n> 2014-07-16 01:49:50.514 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action complete step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n> 2014-07-16 01:49:50.515 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" sleeping _sleep\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:108\n> 2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" running step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n> 2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action running step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n> 2014-07-16 01:49:51.960 25101 DEBUG urllib3.connectionpool [-] \"GET\n> /v2/b64803d759e04b999e616b786b407661/servers/7cb9459c-29b3-4a23-a52c-1\n> 7d85fce0559 HTTP/1.1\" 200 1854 _make_request\n> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295\n> 2014-07-16 01:49:51.963 25101 ERROR heat.engine.resource [-] CREATE : Server \"instance1\"\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Traceback (most recent call last):\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resource.py\", line 371, in _do_action\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource while not check(handle_data):\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 239, in check_create_complete\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource return self._check_active(server)\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 255, in _check_active\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource raise exc\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Error: Creation of server instance1 failed.\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource\n> 2014-07-16 01:49:51.996 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action cancelled cancel\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:187\n> 2014-07-16 01:49:52.004 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" complete step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n> 2014-07-16 01:49:52.005 25101 WARNING heat.engine.service [-] Stack\n> create failed, status FAILED\n> 2014-07-16 01:50:29.218 25101 DEBUG heat.openstack.common.rpc.amqp [-]\n> received {u\'_context_roles\': [u\'Member\', u\'admin\'], u\'_msg_id\':\n> u\'9aedf86fda304cfc857dc897d8393427\', u\'_context_password\':\n> \'\', u\'_context_auth_url\':\n> u\'http://172.17.252.60:5000/v2.0\', u\'_unique_id\':\n> u\'f02188b068de4a4aba0ec203ec3ad54a\', u\'_reply_q\':\n> u\'reply_f841b6a2101d4af9a9af59889630ee77\', u\'_context_aws_creds\':\n> None, u\'args\': {}, u\'_context_tenant\': u\'TVM\',\n> u\'_context_trustor_user_id\': None, u\'_context_trust_id\': None,\n> u\'_context_auth_token\': \'\', u\'_context_is_admin\': True,\n> u\'version\': u\'1.0\', u\'_context_tenant_id\':\n> u\'b64803d759e04b999e616b786b407661\', u\'namespace\': None, u\'method\':\n> u\'list_stacks\', u\'_context_username\': None} _safe_log\n> /usr/lib/python2.6/site-packages/heat/openstack/common/rpc/common.py:2\n> 77\n>\n> Any idea?\n>\n> Thanks,\n> YuLing\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/3973b0a1/attachment.html>\n\n','<20140716105908.GA29879@localhost>',NULL),('<0B87C97B6D8E0B43BAF497C2B90FA0F3E28FC2F1EC@AUSX7MCPC101.AMER.DELL.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 18:53:39',-18000,'2014-07-16 23:53:39',NULL,'[openstack-dev] heat stack-create with two vm instances always\n got one failed','Dell Customer Communication\nMy mistake. It deletes well all the networks in the stack too.\n\nThanks,\nYuLing\n\nFrom: C, Yuling\nSent: Wednesday, July 16, 2014 3:07 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: RE: [openstack-dev] heat stack-create with two vm instances always got one failed\n\n\nDell Customer Communication\nThanks very much Qiming. It was the problem and I got it fixed by creating another port for the instance2.\n\nB.T.W., another question. When I delete the stack, how come the network was not deleted? It seems only the instance was deleted. How do I clean up the networks and subnets associated with the instance using heat?\n\nThanks,\n\nYuLing\n\n-----Original Message-----\nFrom: Qiming Teng [mailto:tengqim at linux.vnet.ibm.com]\nSent: Wednesday, July 16, 2014 3:59 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] heat stack-create with two vm instances always got one failed\n\nIt seems that you are sharing one port between two instances, which won\'t be a legal configuration.\n\nOn Wed, Jul 16, 2014 at 01:17:00AM -0500, Yuling_C at DELL.com<mailto:Yuling_C at DELL.com> wrote:\n> Dell Customer Communication\n>\n> Hi,\n> I\'m using heat to create a stack with two instances. I always got one of them successful, but the other would fail. If I split the template into two and each of them contains one instance then it worked. However, I thought Heat template would allow multiple instances being created?\n>\n> Here I attach the heat template:\n> {\n> \"AWSTemplateFormatVersion\" : \"2010-09-09\",\n> \"Description\" : \"Sample Heat template that spins up multiple instances and a private network (JSON)\",\n> \"Resources\" : {\n> \"test_net\" : {\n> \"Type\" : \"OS::Neutron::Net\",\n> \"Properties\" : {\n> \"name\" : \"test_net\"\n> }\n> },\n> \"test_subnet\" : {\n> \"Type\" : \"OS::Neutron::Subnet\",\n> \"Properties\" : {\n> \"name\" : \"test_subnet\",\n> \"cidr\" : \"120.10.9.0/24\",\n> \"enable_dhcp\" : \"True\",\n> \"gateway_ip\" : \"120.10.9.1\",\n> \"network_id\" : { \"Ref\" : \"test_net\" }\n> }\n> },\n> \"test_net_port\" : {\n> \"Type\" : \"OS::Neutron::Port\",\n> \"Properties\" : {\n> \"admin_state_up\" : \"True\",\n> \"network_id\" : { \"Ref\" : \"test_net\" }\n> }\n> },\n> \"instance1\" : {\n> \"Type\" : \"OS::Nova::Server\",\n> \"Properties\" : {\n> \"name\" : \"instance1\",\n> \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n> \"flavor\": \"tvm-tt_lite\",\n> \"networks\" : [\n> {\"port\" : { \"Ref\" : \"test_net_port\" }}\n> ]\n> }\n> },\n> \"instance2\" : {\n> \"Type\" : \"OS::Nova::Server\",\n> \"Properties\" : {\n> \"name\" : \"instance2\",\n> \"image\" : \"8e2b4c71-448c-4313-8b41-b238af31f419\",\n> \"flavor\": \"tvm-tt_lite\",\n> \"networks\" : [\n> {\"port\" : { \"Ref\" : \"test_net_port\" }}\n> ]\n> }\n> }\n> }\n> }\n> The error that I got from heat-engine.log is as follows:\n>\n> 2014-07-16 01:49:50.514 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action complete step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n> 2014-07-16 01:49:50.515 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" sleeping _sleep\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:108\n> 2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" running step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n> 2014-07-16 01:49:51.516 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action running step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:164\n> 2014-07-16 01:49:51.960 25101 DEBUG urllib3.connectionpool [-] \"GET\n> /v2/b64803d759e04b999e616b786b407661/servers/7cb9459c-29b3-4a23-a52c-1\n> 7d85fce0559 HTTP/1.1\" 200 1854 _make_request\n> /usr/lib/python2.6/site-packages/urllib3/connectionpool.py:295\n> 2014-07-16 01:49:51.963 25101 ERROR heat.engine.resource [-] CREATE : Server \"instance1\"\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Traceback (most recent call last):\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resource.py\", line 371, in _do_action\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource while not check(handle_data):\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 239, in check_create_complete\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource return self._check_active(server)\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource File \"/usr/lib/python2.6/site-packages/heat/engine/resources/server.py\", line 255, in _check_active\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource raise exc\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource Error: Creation of server instance1 failed.\n> 2014-07-16 01:49:51.963 25101 TRACE heat.engine.resource\n> 2014-07-16 01:49:51.996 25101 DEBUG heat.engine.scheduler [-] Task\n> resource_action cancelled cancel\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:187\n> 2014-07-16 01:49:52.004 25101 DEBUG heat.engine.scheduler [-] Task\n> stack_task from Stack \"teststack\" complete step\n> /usr/lib/python2.6/site-packages/heat/engine/scheduler.py:170\n> 2014-07-16 01:49:52.005 25101 WARNING heat.engine.service [-] Stack\n> create failed, status FAILED\n> 2014-07-16 01:50:29.218 25101 DEBUG heat.openstack.common.rpc.amqp [-]\n> received {u\'_context_roles\': [u\'Member\', u\'admin\'], u\'_msg_id\':\n> u\'9aedf86fda304cfc857dc897d8393427\', u\'_context_password\':\n> \'\', u\'_context_auth_url\':\n> u\'http://172.17.252.60:5000/v2.0\', u\'_unique_id\':\n> u\'f02188b068de4a4aba0ec203ec3ad54a\', u\'_reply_q\':\n> u\'reply_f841b6a2101d4af9a9af59889630ee77\', u\'_context_aws_creds\':\n> None, u\'args\': {}, u\'_context_tenant\': u\'TVM\',\n> u\'_context_trustor_user_id\': None, u\'_context_trust_id\': None,\n> u\'_context_auth_token\': \'\', u\'_context_is_admin\': True,\n> u\'version\': u\'1.0\', u\'_context_tenant_id\':\n> u\'b64803d759e04b999e616b786b407661\', u\'namespace\': None, u\'method\':\n> u\'list_stacks\', u\'_context_username\': None} _safe_log\n> /usr/lib/python2.6/site-packages/heat/openstack/common/rpc/common.py:2\n> 77\n>\n> Any idea?\n>\n> Thanks,\n> YuLing\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/a86c2f14/attachment.html>\n\n',NULL,NULL),('<0B9006F4-BAC6-4A6E-96AC-079935767A0A@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-20 09:20:27',-25200,'2013-05-20 16:20:27',NULL,'[openstack-dev] Dynamic Flavors Support','\nOn May 17, 2013, at 1:20 PM, Michael J Fork <mjfork at us.ibm.com> wrote:\n\n> Russell Bryant <rbryant at redhat.com> wrote on 05/16/2013 11:38:46 PM:\n> \n> > From: Russell Bryant <rbryant at redhat.com>\n> > To: openstack-dev at lists.openstack.org, \n> > Date: 05/16/2013 11:42 PM\n> > Subject: Re: [openstack-dev] Dynamic Flavors Support\n> > \n> > On 05/16/2013 10:16 PM, Dan Smith wrote:\n> > > I think that the general consensus is that the notion of dynamic\n> > > flavors is an unfavorable approach. Since we happen to be having this\n> > > discussion while an API redesign is happening, I\'d say the more\n> > > productive path forward is to figure out how we want per-instance usage\n> > > to be exposed which makes sense both with and without fine-grained\n> > > resource tweaks. Perhaps a flavorRef is the wrong way.\n> > > \n> > > Right now, if you create an instance from flavor 1, then change the\n> > > parameters of flavor 1, the flavorRef will be wrong anyway. Before I\n> > > moved instance_type information to system_metadata, doing that would\n> > > even cause billing stuff to be incorrect. Lets figure out how to\n> > > represent the actual instance parameters in APIv3, which I think will\n> > > serve everyone\'s needs.\n> > \n> > Sounds like a good plan to me.\n> > \n> > As you said, given the timing with the v3 API work, we have an\n> > opportunity to do some refactoring here and do it \"right\".\n> \n> Before we make any substantial changes, should we query the user-committee (or similar group) to get feedback on the impact to operators and users of the API?  I think the basic question here is do we retain the 1:1 linkage between Server and Flavor where a Server links to a Flavor that can be referenced by ID or do we move to a model where Flavor is the initial template and post-provision the allocation is through a data structure that is essentially the content of a Flavor today (but without the referenceable ID).\n> \n\nThere clearly needs to be a way to get this information for an instance. One possibility is simply to do a GET flavors/<instance-uuid> which would return the exact same information as a regular flavors request (w/o a flavor name i suppose). This should make it easy for end users who were depending on the existing flavor-ref idea. This is sort of a hybrid approach, where internally we don\'t have dynamic flavors but we provide a \"compatibility\" api for users who expect them to be separate. The other possibility is to add the entire flavor object to the instance get. This actually gives us a nice path forward in regards to v2/v3 as well where v2 could keep the flavor-ref and use the above method for retrieving information and v3 could abandon flavor-ref for full flavor data in instance get.\n\nVish\n\n> \n> > -- \n> > Russell Bryant\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> Michael\n> \n> -------------------------------------------------\n> Michael Fork\n> Architect, OpenStack Development\n> IBM Systems & Technology Group\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/4f0a6775/attachment.html>\n\n','<OFAB5126F8.D68D1505-ON85257B6E.006C5443-85257B6E.006FB3ED@us.ibm.com>',NULL),('<0B919F29-01B5-4D2A-B42D-DEE7779ABE20@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-14 13:49:11',7200,'2014-05-14 11:49:11',NULL,'[Openstack] pacemaker would be wrong when both node have same\n	hostname','Hi,\n\nin attachment you can find our modified resource agent?we have noticed that the network namespaces (router and dhcp) are automatically re-created on the new node when the resource manager migrates the network controller on the other physical node (we have grouped all the services related to the network node).\n\nPlease, note that the attached script contains also other patches wrt to the RA available at https://raw.githubusercontent.com/madkiss/openstack-resource-agents/master/ocf/neutron-agent-l3 because we found some issues with the resource agent parameters and the port used to check the established connection with the server; moreover we have added the start/stop operations for the neutron-plugin-openvswitch-agent since there is no available RA at the moment for this service.  \n\nCheers, \nMarica\n---------------------------\ndhcp117:~ marica$ diff -w -b neutron-agent-l3 neutron-agent-l3.1\n20c20\n< #   OCF_RESKEY_agent_config\n---\n> #   OCF_RESKEY_plugin_config\n37c37\n< OCF_RESKEY_agent_config_default=\"/etc/neutron/l3_agent.ini\"\n---\n> OCF_RESKEY_plugin_config_default=\"/etc/neutron/l3_agent.ini\"\n40c40\n< OCF_RESKEY_neutron_server_port_default=\"5672\"\n---\n> OCF_RESKEY_neutron_server_port_default=\"9696\"\n44c44\n< : ${OCF_RESKEY_agent_config=${OCF_RESKEY_agent_config_default}}\n---\n> : ${OCF_RESKEY_plugin_config=${OCF_RESKEY_plugin_config_default}}\n98c98\n< <parameter name=\"agent_config\" unique=\"0\" required=\"0\">\n---\n> <parameter name=\"plugin config\" unique=\"0\" required=\"0\">\n103c103\n< <content type=\"string\" default=\"${OCF_RESKEY_agent_config_default}\" />\n---\n> <content type=\"string\" default=\"${OCF_RESKEY_plugin_config_default}\" />\n241,247d240\n<     # Aleita\n<     # change hostname\n<     hostname network-controller\n< \n<     #Marant: temporary patch - restart neutron-plugin-openvswitch-agent\n<     service neutron-plugin-openvswitch-agent start \n< \n251c244\n<        --config-file=$OCF_RESKEY_agent_config --log-file=/var/log/neutron/l3-agent.log $OCF_RESKEY_additional_parameters\"\' >> \\\n---\n>        --config-file=$OCF_RESKEY_plugin_config --log-file=/var/log/neutron/l3-agent.log $OCF_RESKEY_additional_parameters\"\' >> \\\n320,325d312\n<     # Aleita\n<     # restore old hostname\n<     hostname node1\n< \n<     #Marant: \n<     service neutron-plugin-openvswitch-agent stop\n\n\n\n \n\n\nIl giorno 14/mag/2014, alle ore 13:04, walterxj <walterxj at gmail.com> ha scritto:\n\n> Hi Marica:\n>    Can you give me your modified RA to me?And is that with your RA you configure the pacemaker just like the guide?I mean I notice that when the former network node down,the l3-agent of the back node must bind the router which belong to the former node.\n>  \n> walterxj\n>  \n> From: Marica Antonacci\n> Date: 2014-05-14 18:55\n> To: walterxj\n> CC: openstack\n> Subject: Re: [Openstack] pacemaker would be wrong when both node have same hostname\n> Hi all,\n> \n> we are currently using pacemaker to manage 2 network nodes (node1, node2) and we have modified the neutron L3 agent RA in order to dynamically change the hostname of the active network node: start() function sets the hostname ?network-controller\" to be used by the scheduler; the stop() function restores the old hostname (?node1? or ?node2?). It seems to work, yet it?s a rude patch :) A more general solution that exploits neutron functionalities would be very appreciated!\n> \n> Best,\n> Marica      \n> \n> Il giorno 14/mag/2014, alle ore 12:34, walterxj <walterxj at gmail.com> ha scritto:\n> \n>> hi:\n>>       the high-availability-guide (http://docs.openstack.org/high-availability-guide/content/ch-network.html) says that Both nodes should have the same hostname since the Networking scheduler will be aware of one node, for example a virtual router attached to a single L3 node.\n>> \n>>      But when I test it on two servers with same hostname,after installing corosync and pacemaker service on them(with no resource configured),the crm_mon output goes into endless loop.And in the log of corosync,there are so many messages like:May 09 22:25:40 [2149] TEST crmd: warning: crm_get_peer: Node \'TEST\' and \'TEST\' share the same cluster nodeid: 1678901258.After this I set diffrent nodeid in /etc/corosync/corosync.conf of each test node,but it didn\'t help.\n>>     So,I set diffrent hostname for each server,and then configure pacemaker just like the manual except the hostname,the neutron-dhcp-agent and neutron-metadata-agent works well,but neutron-l3-agent not(VM instance can\'t not access the external net,further more the gateway of the VM instance can\'t be accessed either).\n>>     After two days checking,finally I found that we can use \"netron l3-agent-router-remove network1_l3_agentid external-routeid\" and \"netron l3-agent-router-add network2_l3_agentid external-routeid\" to let the backup l3-agent to work when the former network node is down.(assume the two node\'s names are network1 and network2),alternatively,we can update the mysql table routerl3agentbindings in neutron base directly.If it make sense,I think we can change the scrip neutron-agent-l3 , in it\'s neutron_l3_agent_start() function,only need few lines to make it work well.\n>> \n>> Walter Xu\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140514/d690e905/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: neutron-agent-l3\nType: application/octet-stream\nSize: 12038 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140514/d690e905/attachment.obj>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140514/d690e905/attachment-0001.html>\n\n','<2014051419042917241325@gmail.com>',NULL),('<0b9601d015e6$ce3510f0$6a9f32d0$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-12 16:37:03',28800,'2014-12-12 08:37:03',NULL,'[openstack-dev] [Openstack] [Ceilometer] [API] Batch alarm creation','Hi Eoghan and folks,\n\nI\'m thinking of adding an API to create multiple alarms in a batch.\n\nI think adding an API to create multiple alarms is a good option to solve the problem that once an *alarm target* (a vm or a new group of vms) is created, multiple requests will be fired because multiple alarms are to be created.\n\nIn the our current project, this requiement is specially urgent since our alarm target is one VM, and 6 alarms are to be created when one VM is created.\n\nWhat do you guys think?\n\n\nBest Regards,\nKurt Rao\n\n\n\n----- Original -----\n???: Eoghan Glynn [mailto:eglynn at redhat.com] \n????: 2014?12?3? 20:34\n???: Rao Dingyuan\n??: openstack at lists.openstack.org\n??: Re: [Openstack] [Ceilometer] looking for alarm best practice - please help\n\n\n\n> Hi folks,\n> \n> \n> \n> I wonder if anyone could share some best practice regarding to the \n> usage of ceilometer alarm. We are using the alarm \n> evaluation/notification of ceilometer and we don?t feel very well of \n> the way we use it. Below is our\n> problem:\n> \n> \n> \n> ============================\n> \n> Scenario:\n> \n> When cpu usage or memory usage above a certain threshold, alerts \n> should be displayed on admin?s web page. There should be a 3 level \n> alerts according to meter value, namely notice, warning, fatal. Notice \n> means the meter value is between 50% ~ 70%, warning means between 70% \n> ~ 85% and fatal means above 85%\n> \n> For example:\n> \n> * when one vm?s cpu usage is 72%, an alert message should be displayed \n> saying\n> ?Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above 70%?.\n> \n> * when one vm?s memory usage is 90%, another alert message should be \n> created saying ?Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] memory \n> usage is above 85%?\n> \n> \n> \n> Our current Solution:\n> \n> We used ceilometer alarm evaluation/notification to implement this. To \n> distinguish which VM and which meter is above what value, we?ve \n> created one alarm for each VM by each condition. So, to monitor 1 VM, \n> 6 alarms will be created because there are 2 meters and for each meter there are 3 levels.\n> That means, if there are 100 VMs to be monitored, 600 alarms will be \n> created.\n> \n> \n> \n> Problems:\n> \n> * The first problem is, when the number of meters increases, the \n> number of alarms will be multiplied. For example, customer may want \n> alerts on disk and network IO rates, and if we do that, there will be \n> 4*3=12 alarms for each VM.\n> \n> * The second problem is, when one VM is created, multiple alarms will \n> be created, meaning multiple http requests will be fired. In the case \n> above, 6 HTTP requests will be needed once a VM is created. And this \n> number also increases as the number of meters goes up.\n\nOne way of reducing both the number of alarms and the volume of notifications would be to group related VMs, if such a concept exists in your use-case.\n\nThis is effectively how Heat autoscaling uses ceilometer, alarming on the average of some statistic over a set of instances (as opposed to triggering on individual instances).\n\nThe VMs could be grouped by setting user-metadata of form:\n\n  nova boot ... --meta metering.my_server_group=foobar\n\nAny user-metadata prefixed with \'metering.\' will be preserved by ceilometer in the resource_metadata.user_metedata stored for each sample, so that it can used to select the statistics on which the alarm is based, e.g.\n\n  ceilometer alarm-threshold-create --name cpu_high_foobar \\\n    --description \'warning: foobar instance group running hot\' \\\n    --meter-name cpu_util --threshold 70.0 \\\n    --comparison-operator gt --statistic avg \\\n    ...\n    --query metadata.user_metedata.my_server_group=foobar\n\nThis approach is of course predicated on the there being some natural grouping relation between instances in your environment.\n\nCheers,\nEoghan\n\n\n> =============================\n> \n> \n> \n> Do anyone have any suggestions?\n> \n> \n> \n> \n> \n> \n> \n> Best Regards!\n> \n> Kurt Rao\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n\n\n\n',NULL,NULL),('<0B98B832-34E1-4D63-BF58-9F872AB9C3EB@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-02 12:53:48',0,'2015-01-02 12:53:48',NULL,'[openstack-dev] [nova] boot images in power state PAUSED\n	for	stable/juno','No other tools. Running a stock Ubuntu 14.04 server, installed devstack, created local.conf, stacked, and tried to create a VM.  I?ve since seen this on another VM I have running with Kilo code, so it is not specifically a Juno issue.\n\nI don?t see what the difference is between a working and non-working setup. :(\n\nOn all instances, virsh -v shows 1.2.2.\n\nBaffled.\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pc_m (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n\nOn Jan 2, 2015, at 4:48 AM, Kevin Benton <blak111 at gmail.com> wrote:\n\n> Ah, doesn\'t seem to be a Neutron issue then since the\n> \'network-vif-plugged\' event is showing up and it\'s attempting to\n> resume.\n> \n> The red flag looks like that \"Instance is paused unexpectedly.\n> Ignore.\". If you grep the nova code base for that, it brings up a note\n> linking to bug 1097806.[1] The VM is paused when Nova didn\'t expect it\n> to be. Do you have any other tools running that might be affecting\n> kvm?\n> \n> 1. https://bugs.launchpad.net/nova/+bug/1097806\n> \n> On Thu, Jan 1, 2015 at 8:09 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>> Hi Kevin,\n>> \n>> No exceptions/tracebacks/errors in Neutron at all. In the Nova logs, it\n>> seems to create the instance, pause, and then resume, but it looks like\n>> maybe it is not resuming?\n>> \n>> 2015-01-01 14:44:30.716 3516 DEBUG nova.openstack.common.processutils [-]\n>> Running cmd (subprocess): sudo nova-rootwrap /etc/nova/rootwrap.conf\n>> ovs-vsctl --timeout=120 -- --if-exists del-port qvoded0d35f-20 -- add-port\n>> br-int qvoded0d35\\\n>> f-20 -- set Interface qvoded0d35f-20\n>> external-ids:iface-id=ded0d35f-204f-4ca8-a85b-85decb53d9fe\n>> external-ids:iface-status=active external-ids:attached-mac=fa:16:3e:81:ab:12\n>> external-ids:vm-uuid=c32ac737-1788-4420-b200-2a107d5ad335 exec\\\n>> ute /opt/stack/nova/nova/openstack/common/processutils.py:161\n>> 2015-01-01 14:44:30.786 3516 DEBUG nova.openstack.common.processutils [-]\n>> Result was 0 execute\n>> /opt/stack/nova/nova/openstack/common/processutils.py:195\n>> 2015-01-01 14:44:31.542 3516 DEBUG nova.virt.driver [-] Emitting event\n>> <LifecycleEvent: 1420123471.54, c32ac737-1788-4420-b200-2a107d5ad335 =>\n>> Started> emit_event /opt/stack/nova/nova/virt/driver.py:1298\n>> 2015-01-01 14:44:31.543 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] VM Started (Lifecycle Event)\n>> 2015-01-01 14:44:31.584 DEBUG nova.compute.manager\n>> [req-77c13ae6-ccf9-48ee-881a-8bb7f04ee4bc None None] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Synchronizing instance power state\n>> after lifecycle event \"Started\"; current vm_sta\\\n>> te: building, current task_state: spawning, current DB power_state: 0, VM\n>> power_state: 1 handle_lifecycle_event\n>> /opt/stack/nova/nova/compute/manager.py:1105\n>> 2015-01-01 14:44:31.629 INFO nova.compute.manager\n>> [req-77c13ae6-ccf9-48ee-881a-8bb7f04ee4bc None None] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] During sync_power_state the instance\n>> has a pending task (spawning). Skip.\n>> 2015-01-01 14:44:31.630 3516 DEBUG nova.virt.driver [-] Emitting event\n>> <LifecycleEvent: 1420123471.54, c32ac737-1788-4420-b200-2a107d5ad335 =>\n>> Paused> emit_event /opt/stack/nova/nova/virt/driver.py:1298\n>> 2015-01-01 14:44:31.630 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] VM Paused (Lifecycle Event)\n>> 2015-01-01 14:44:31.670 3516 DEBUG nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Synchronizing instance power state\n>> after lifecycle event \"Paused\"; current vm_state: building, current\n>> task_state: spawning, c\\\n>> urrent DB power_state: 0, VM power_state: 3 handle_lifecycle_event\n>> /opt/stack/nova/nova/compute/manager.py:1105\n>> 2015-01-01 14:44:31.714 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] During sync_power_state the instance\n>> has a pending task (spawning). Skip.\n>> 2015-01-01 14:44:38.293 DEBUG nova.compute.manager\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Received event\n>> network-vif-plugged-ded0d35f-204f-4ca8-a85b-85decb53d9fe externa\\\n>> l_instance_event /opt/stack/nova/nova/compute/manager.py:6180\n>> 2015-01-01 14:44:38.293 DEBUG nova.openstack.common.lockutils\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] Created new\n>> semaphore \"c32ac737-1788-4420-b200-2a107d5ad335-events\" internal_lock\n>> /opt/stack/nova/nova/openstack/comm\\\n>> on/lockutils.py:206\n>> 2015-01-01 14:44:38.294 DEBUG nova.openstack.common.lockutils\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] Acquired semaphore\n>> \"c32ac737-1788-4420-b200-2a107d5ad335-events\" lock\n>> /opt/stack/nova/nova/openstack/common/lockutils\\\n>> .py:229\n>> 2015-01-01 14:44:38.294 DEBUG nova.openstack.common.lockutils\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] Got semaphore / lock\n>> \"_pop_event\" inner /opt/stack/nova/nova/openstack/common/lockutils.py:271\n>> 2015-01-01 14:44:38.294 DEBUG nova.openstack.common.lockutils\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] Releasing semaphore\n>> \"c32ac737-1788-4420-b200-2a107d5ad335-events\" lock\n>> /opt/stack/nova/nova/openstack/common/lockutil\\\n>> s.py:238\n>> 2015-01-01 14:44:38.295 DEBUG nova.openstack.common.lockutils\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] Semaphore / lock\n>> released \"_pop_event\" inner\n>> /opt/stack/nova/nova/openstack/common/lockutils.py:275\n>> 2015-01-01 14:44:38.295 DEBUG nova.compute.manager\n>> [req-0dc50994-e997-41b5-99f2-0a0333f1ea11 nova service] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Processing event\n>> network-vif-plugged-ded0d35f-204f-4ca8-a85b-85decb53d9fe _proc\\\n>> ess_instance_event /opt/stack/nova/nova/compute/manager.py:6166\n>> 2015-01-01 14:44:38.309 3516 DEBUG nova.virt.libvirt.driver [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Instance is running spawn\n>> /opt/stack/nova/nova/virt/libvirt/driver.py:2622\n>> 2015-01-01 14:44:38.310 3516 DEBUG nova.virt.driver [-] Emitting event\n>> <LifecycleEvent: 1420123478.31, c32ac737-1788-4420-b200-2a107d5ad335 =>\n>> Resumed> emit_event /opt/stack/nova/nova/virt/driver.py:1298\n>> 2015-01-01 14:44:38.311 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] VM Resumed (Lifecycle Event)\n>> 2015-01-01 14:44:38.315 3516 INFO nova.virt.libvirt.driver [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Instance spawned successfully.\n>> 2015-01-01 14:44:38.315 3516 DEBUG nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Checking state _get_power_state\n>> /opt/stack/nova/nova/compute/manager.py:1156\n>> 2015-01-01 14:44:38.348 3516 DEBUG nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Synchronizing instance power state\n>> after lifecycle event \"Resumed\"; current vm_state: building, current\n>> task_state: spawning, \\\n>> current DB power_state: 0, VM power_state: 1 handle_lifecycle_event\n>> /opt/stack/nova/nova/compute/manager.py:1105\n>> 2015-01-01 14:44:38.391 3516 DEBUG nova.openstack.common.lockutils [-]\n>> Releasing semaphore \"c32ac737-1788-4420-b200-2a107d5ad335\" lock\n>> /opt/stack/nova/nova/openstack/common/lockutils.py:238\n>> 2015-01-01 14:44:38.394 3516 DEBUG nova.virt.driver [-] Emitting event\n>> <LifecycleEvent: 1420123478.31, c32ac737-1788-4420-b200-2a107d5ad335 =>\n>> Resumed> emit_event /opt/stack/nova/nova/virt/driver.py:1298\n>> 2015-01-01 14:44:38.394 3516 DEBUG nova.openstack.common.lockutils [-]\n>> Semaphore / lock released \"_locked_do_build_and_run_instance\" inner\n>> /opt/stack/nova/nova/openstack/common/lockutils.py:275\n>> 2015-01-01 14:44:38.396 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] VM Resumed (Lifecycle Event)\n>> 2015-01-01 14:44:38.441 3516 DEBUG nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Synchronizing instance power state\n>> after lifecycle event \"Resumed\"; current vm_state: active, current\n>> task_state: None, curren\\\n>> t DB power_state: 1, VM power_state: 1 handle_lifecycle_event\n>> /opt/stack/nova/nova/compute/manager.py:1105\n>> 2015-01-01 14:44:38.489 3516 DEBUG nova.virt.driver [-] Emitting event\n>> <LifecycleEvent: 1420123478.33, c32ac737-1788-4420-b200-2a107d5ad335 =>\n>> Paused> emit_event /opt/stack/nova/nova/virt/driver.py:1298\n>> 2015-01-01 14:44:38.490 3516 INFO nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] VM Paused (Lifecycle Event)\n>> 2015-01-01 14:44:38.535 3516 DEBUG nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Synchronizing instance power state\n>> after lifecycle event \"Paused\"; current vm_state: active, current\n>> task_state: None, current\\\n>> DB power_state: 1, VM power_state: 3 handle_lifecycle_event\n>> /opt/stack/nova/nova/compute/manager.py:1105\n>> 2015-01-01 14:44:38.643 3516 WARNING nova.compute.manager [-] [instance:\n>> c32ac737-1788-4420-b200-2a107d5ad335] Instance is paused unexpectedly.\n>> Ignore.\n>> \n>> I think I saw this in one of my Kilo based VMs too.\n>> \n>> \n>> Regards,\n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pc_m (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> \n>> On Dec 31, 2014, at 7:57 PM, Kevin Benton <blak111 at gmail.com> wrote:\n>> \n>> Any exceptions on the Neutron side? It might not be notifying nova\n>> that the network is ready.\n>> \n>> On Wed, Dec 31, 2014 at 8:41 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>> \n>> Not sure if I?m going crazy or what. I?m using DevStack and, after stacking\n>> I tried booting a Cirros 3.2, 3.3, and Ubuntu cloud 14.04 image. Each time,\n>> the image ends up in PAUSED power state:\n>> \n>> ubuntu at juno:/opt/stack/neutron$ nova show peter\n>> +--------------------------------------+----------------------------------------------------------------+\n>> | Property                             | Value\n>> |\n>> +--------------------------------------+----------------------------------------------------------------+\n>> | OS-DCF:diskConfig                    | MANUAL\n>> |\n>> | OS-EXT-AZ:availability_zone          | nova\n>> |\n>> | OS-EXT-SRV-ATTR:host                 | juno\n>> |\n>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | juno\n>> |\n>> | OS-EXT-SRV-ATTR:instance_name        | instance-00000001\n>> |\n>> | OS-EXT-STS:power_state               | 3\n>> |\n>> | OS-EXT-STS:task_state                | -\n>> |\n>> | OS-EXT-STS:vm_state                  | active\n>> |\n>> | OS-SRV-USG:launched_at               | 2014-12-31T15:15:33.000000\n>> |\n>> | OS-SRV-USG:terminated_at             | -\n>> |\n>> | accessIPv4                           |\n>> |\n>> | accessIPv6                           |\n>> |\n>> | config_drive                         |\n>> |\n>> | created                              | 2014-12-31T15:15:24Z\n>> |\n>> | flavor                               | m1.tiny (1)\n>> |\n>> | hostId                               |\n>> 5b0c48250ccc0ac3fca8a821e29e4b154ec0b101f9cc0a0b27071a3f       |\n>> | id                                   |\n>> ec5c8d70-ae80-4cc3-a5bb-b68019170dd6                           |\n>> | image                                | cirros-0.3.3-x86_64-uec\n>> (797e4dee-8c03-497f-8dac-a44b9351dfa3) |\n>> | key_name                             | -\n>> |\n>> | metadata                             | {}\n>> |\n>> | name                                 | peter\n>> |\n>> | os-extended-volumes:volumes_attached | []\n>> |\n>> | private network                      | 10.0.0.4\n>> |\n>> | progress                             | 0\n>> |\n>> | security_groups                      | default\n>> |\n>> | status                               | ACTIVE\n>> |\n>> | tenant_id                            | 7afb5bc1d88d462c8d57178437d3c277\n>> |\n>> | updated                              | 2014-12-31T15:15:34Z\n>> |\n>> | user_id                              | 4ff18bdbeb4d436ea4ff1bcd29e269a9\n>> |\n>> +--------------------------------------+----------------------------------------------------------------+\n>> ubuntu at juno:/opt/stack/neutron$ nova list\n>> +--------------------------------------+-------+--------+------------+-------------+------------------+\n>> | ID                                   | Name  | Status | Task State | Power\n>> State | Networks         |\n>> +--------------------------------------+-------+--------+------------+-------------+------------------+\n>> | ec5c8d70-ae80-4cc3-a5bb-b68019170dd6 | peter | ACTIVE | -          |\n>> Paused      | private=10.0.0.4 |\n>> \n>> \n>> I don?t see this with Kilo latest images. Any idea what I may be doing\n>> wrong, or if there is an issue (I didn?t see anything on Google search)?\n>> \n>> IMAGE_ID=`nova image-list | grep \'cloudimg-amd64 \' | cut -d\' \' -f 2`\n>> PRIVATE_NET=`neutron net-list | grep \'private \' | cut -f 2 -d\' ?`\n>> \n>> nova boot peter --flavor 3 --image $IMAGE_ID --user-data\n>> ~/devstack/user_data.txt --nic net-id=$PRIVATE_NET\n>> nova boot --flavor 1 --image cirros-0.3.3-x86_64-uec --nic\n>> net-id=$PRIVATE_NET paul\n>> \n>> Thanks.\n>> \n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pc_m (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> \n>> --\n>> Kevin Benton\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> \n> \n> -- \n> Kevin Benton\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150102/f157e35e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150102/f157e35e/attachment.pgp>\n\n','<CAO_F6JMe=qPAWW5WA9EbCUavyS1ravbvEn2r=tf7FZimfwo2XQ@mail.gmail.com>',NULL),('<0B9A4E09-BCE1-44C6-8CB6-D20134652EF2@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 20:35:46',0,'2013-11-13 20:35:46',NULL,'[openstack-dev] [neutron] Group-based Policy Sub-team Meetings','On Nov 13, 2013, at 12:57 PM, Tim Hinrichs <thinrichs at vmware.com>\n wrote:\n\n> Are there plans for a concrete policy language (e.g. a grammar and semantics) to be part of the proposal, or does each plugin to Neutron supply its own policy language?\n> \nThere are no concrete plans for this right now, though I suspected this would come up.\n\n> I\'m trying to envision how Heat would utilize the policy API.  If there\'s a concrete policy language, then Heat can take an app template, extract the networking-relevant policy, and express that policy in the concrete language.  Then whatever plugin we\'re using for Neutron can implement that policy in any way it sees fit as long as it obeys the policy\'s semantics (according to the language--the semantics Heat intended).\n> \n> But if there\'s no concrete policy language, how does Heat know which policy statements to send?  It doesn\'t know which plugin is being used for Neutron.  So it doesn\'t even know which strings are valid policy statements.  Or are we assuming that Heat knows which plugin is being used for Neutron?  Or am I missing something?\n> \nThe APIs alone provide a mechanism for utilizing the new constructs, but the specific policy intent is left to the underlying plugin. This would be a good thing to discuss at our meeting next week.\n\nThanks,\nKyle\n\n> Thanks,\n> Tim\n> \n> ----- Original Message -----\n> | From: \"Kyle Mestery (kmestery)\" <kmestery at cisco.com>\n> | To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> | Sent: Wednesday, November 13, 2013 9:57:54 AM\n> | Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings\n> | \n> | On Nov 13, 2013, at 10:36 AM, Stephen Wong <s3wong at midokura.com>\n> |  wrote:\n> | \n> | > Hi Kyle,\n> | > \n> | >    So no meeting this Thursday?\n> | > \n> | I am inclined to skip this week\'s meeting due to the fact I haven\'t\n> | heard many\n> | replies yet. I think a good starting point for people would be to\n> | review the\n> | BP [1] and Design Document [2] and provide feedback where\n> | appropriate.\n> | We should start to formalize what the APIs will look like at next\n> | week\'s meeting,\n> | and the Design Document has a first pass at this.\n> | \n> | Thanks,\n> | Kyle\n> | \n> | [1]\n> | https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction\n> | [2]\n> | https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing\n> | \n> | > Thanks,\n> | > - Stephen\n> | > \n> | > On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery)\n> | > <kmestery at cisco.com> wrote:\n> | >> On Nov 13, 2013, at 8:58 AM, \"Stein, Manuel (Manuel)\"\n> | >> <manuel.stein at alcatel-lucent.com> wrote:\n> | >> \n> | >>> Kyle,\n> | >>> \n> | >>> I\'m afraid your meeting vanished from the Meetings page [2] when\n> | >>> user amotiki reworked neutron meetings ^.^\n> | >>> Is the meeting for Thu 1600 UTC still on?\n> | >>> \n> | >> Ack, thanks for the heads up here! I have re-added the meeting. I\n> | >> only heard\n> | >> back from one other person other than yourself, so at this point\n> | >> I\'m inclined\n> | >> to wait until next week to hold our first meeting unless I hear\n> | >> back from others.\n> | >> \n> | >>> A few heads-up questions (couldn\'t attend the HK design summit\n> | >>> Friday meeting):\n> | >>> \n> | >>> 1) In the summit session Etherpad [3], ML2 implementation\n> | >>> mentions insertion of arbitrary metadata to hint to underlying\n> | >>> implementation. Is that (a) the plug-ing reporting its\n> | >>> policy-bound realization? (b) the user further specifying what\n> | >>> should be used? (c) both? Or (d) none of that but just some\n> | >>> arbitrary message of the day?\n> | >>> \n> | >> I believe that would be (a).\n> | >> \n> | >>> 2) Would policies _always_ map to the old Neutron entities?\n> | >>> E.g. when I have policies in place, can I query related\n> | >>> network/port, subnet/address, router elements on the API or are\n> | >>> there no equivalents created? Would the logical topology created\n> | >>> under the policies be exposed otherwise? for e.g.\n> | >>> monitoring/wysiwyg/troubleshoot purposes.\n> | >>> \n> | >> No, this is up to the plugin/MechanismDriver implementation.\n> | >> \n> | >>> 3) Do the chain identifier in your policy rule actions match to\n> | >>> \"Service Chain UUID\" in Service Insertion, Chaining and API [4]\n> | >>> \n> | >> That\'s one way to look at this, yes.\n> | >> \n> | >>> 4) Are you going to describe L2 services the way group policies\n> | >>> work? I mean, why would I need a LoadBalancer or Firewall\n> | >>> instance before I can insert it between two groups when all that\n> | >>> load balancing/firewalling requires is nothing but a policy for\n> | >>> group communication itself? - regardless the service instance\n> | >>> used to carry out the service.\n> | >>> \n> | >> These are things I\'d like to discuss at the IRC meeting each week.\n> | >> The goal\n> | >> would be to try and come up with some actionable items we can\n> | >> drive towards\n> | >> in both Icehouse-1 and Icehouse-2. Given how close the closing of\n> | >> Icehouse-1\n> | >> is, we need to focus on this very fast if we want to have a\n> | >> measurable impact in\n> | >> Icehouse-1.\n> | >> \n> | >> Thanks,\n> | >> Kyle\n> | >> \n> | >> \n> | >>> Best, Manuel\n> | >>> \n> | >>> [2]\n> | >>> https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting\n> | >>> [3]\n> | >>> https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron\n> | >>> [4]\n> | >>> https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#\n> | >>> \n> | >>>> -----Original Message-----\n> | >>>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n> | >>>> Sent: Montag, 11. November 2013 19:41\n> | >>>> To: OpenStack Development Mailing List (not for usage questions)\n> | >>>> Subject: [openstack-dev] [neutron] Group-based Policy\n> | >>>> Sub-team Meetings\n> | >>>> \n> | >>>> Hi folks! Hope everyone had a safe trip back from Hong Kong.\n> | >>>> Friday afternoon in the Neutron sessions we discussed the\n> | >>>> \"Group-based Policy Abstraction\" BP [1]. It was decided we\n> | >>>> would try to have a weekly IRC meeting to drive out further\n> | >>>> requirements with the hope of coming up with a list of\n> | >>>> actionable tasks to begin working on by December.\n> | >>>> I\'ve tentatively set the meeting [2] for Thursdays at 1600\n> | >>>> UTC on the #openstack-meeting-alt IRC channel. If there are\n> | >>>> serious conflicts with this day and time, please speak up\n> | >>>> soon. Otherwise, we\'ll host our first meeting on Thursday this\n> | >>>> week.\n> | >>>> \n> | >>>> Thanks!\n> | >>>> Kyle\n> | >>>> \n> | >>>> [1]\n> | >>>> https://blueprints.launchpad.net/neutron/+spec/group-based-pol\n> | >>> icy-abstraction\n> | >>>> [2]\n> | >>>> https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_\n> | >>>> Sub-Team_Meeting\n> | >>>> _______________________________________________\n> | >>>> OpenStack-dev mailing list\n> | >>>> OpenStack-dev at lists.openstack.org\n> | >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | >>>> \n> | >>> _______________________________________________\n> | >>> OpenStack-dev mailing list\n> | >>> OpenStack-dev at lists.openstack.org\n> | >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | >> \n> | >> \n> | >> _______________________________________________\n> | >> OpenStack-dev mailing list\n> | >> OpenStack-dev at lists.openstack.org\n> | >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | > \n> | > _______________________________________________\n> | > OpenStack-dev mailing list\n> | > OpenStack-dev at lists.openstack.org\n> | > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | \n> | \n> | _______________________________________________\n> | OpenStack-dev mailing list\n> | OpenStack-dev at lists.openstack.org\n> | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<16745078.3313.1384369055622.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>',NULL),('<0b9e6bfbf2ac44c88eba7ecba8af120d@HKNPR01MB241.apcprd01.prod.exchangelabs.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 16:59:37',0,'2014-07-22 16:59:37',NULL,'[openstack-dev] [nova] The image status is always \'BUILD\'','Dear Dan,\n\nI understand.\nThanks for your information.\n\nRegards,\nJohnson\n\n-----Original Message-----\nFrom: Dan Genin [mailto:daniel.genin at jhuapl.edu] \nSent: Tuesday, July 22, 2014 9:14 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [nova] The image status is always \'BUILD\'\n\nIt seems that there already are posts out there explaining how to resolve your issue https://ask.openstack.org/en/question/6196/programmingerror-programmingerror-1146-table-novaservices-doesnt-exist/.\n\nGenerally, usage questions should be directed to other fora such as ask.openstack.org. This mailing list is reserved for questions and discussions dealing exclusively with Openstack development.\n\nDan\n\nOn 07/22/2014 05:12 AM, Johnson Cheng wrote:\n> ProgrammingError: (ProgrammingError) (1146, \"Table \'nova.services\' \n> doesn\'t exist\")\n\n\n\n\n','<53CE6391.3020505@jhuapl.edu>',NULL),('<0BAA1CBC-4D1E-459D-A7B3-86B11223CA7F@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 17:48:48',-14400,'2014-09-15 21:48:48',NULL,'[openstack-dev] [oslo] final review push for releases thursday','We?re down to 2 bugs, both of which have patches up for review.\n\nJames Carey has a fix for the decoding error we?re seeing in mask_password(). It needs to land in oslo.utils and oslo-incubator:\n\n- utils: https://review.openstack.org/#/c/121657/\n- incubator: https://review.openstack.org/#/c/121632/\n\nRobert Collins has a fix for pbr breaking on tags that don?t look like version numbers, with 1 dependency:\n\n- https://review.openstack.org/#/c/114403/\n- https://review.openstack.org/#/c/108271/ (dependency)\n\nIf we knock these out Tuesday we can cut releases of the related libs to give us a day or so with unit tests running before the final versions are tagged on Thursday.\n\nDoug\n\n\n\n',NULL,NULL),('<0BB97717-F009-4B2D-A98A-AE79E477DB76@openstack.org>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-07-11 12:05:43',-18000,'2014-07-11 17:05:43',NULL,'[openstack-tc] OpenStack 4th Birthday Party at OSCON','Hi everyone, \n\nDuring July, we are celebrating the OpenStack community and user growth over the past year with user group celebrations around the world, and a party in a few weeks during OSCON in Portland. \n\nIf you are attending OSCON in a couple of weeks, I would like to invite you to join the Foundation in celebrating the OpenStack 4th Birthday on July 22nd at Union/Pine, which is walking distance from the convention center. You can register for free here and find walking directions from the conference to the venue here. The doors officially open at 7pm PDT, but we would like to invite TC members to arrive early at 6:30pm to mingle with Foundation staff and the board of directors. \n\nIf you are unable to attend the party in Portland, we have more than 50 user groups around the world throwing events during July, so find out if your local user group is planning a celebration.\n\nPlease let me know if you have any questions! \n\nCheers,\nAllison\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140711/05ace2eb/attachment.html>\n\n',NULL,NULL),('<0BB98E9D-62DC-473E-AD8A-82730D33F091@imaginary.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-10 07:07:44',-18000,'2012-08-10 12:07:44',NULL,'[openstack-dev] [nova] Call for Help -- OpenStack API XML\n	Support','There\'s a real problem with the truth on this list.\n\nOn Aug 10, 2012, at 12:28 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n> On Thu, 2012-08-09 at 18:20 -0500, George Reese wrote:\n>> It goes to the complete clown show that Nebula team is running with\n>> respect to OpenStack development.\n> \n> Tone it down on this list or we\'ll have to start actively enforcing our\n> code of conduct[1]. Do you want to be the first person censured under\n> it? We could name the \"be respectful\" clause after you if you like?\n> \n> These kind of attacks are completely out of line on a mailing list where\n> people are trying to work together and get stuff done.\n> \n> Mark.\n> \n> [1] - http://wiki.openstack.org/Governance/Foundation/CommunityCodeOfConduct\n> \n\n--\nGeorge Reese (george.reese at imaginary.com)\nt: @GeorgeReese               m: +1(207)956-0217               Skype: nspollution\ncal: http://tungle.me/GeorgeReese   \n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120810/22660767/attachment.html>\n\n','<1344576501.4956.77.camel@sorcha>',NULL),('<0bc48b7da0338705244185b045f2a2a5@mail.gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 12:29:30',-25200,'2012-11-01 19:29:30',NULL,'[openstack-dev] Some idea on device assignment support','Hi All,\n\nIn next couple of days we will resume our PCI passthrough/SR-IOV proposal.\nWith the help from Cisco folks I\'m sure we will be able to propose it\npretty soon.\n\nI suppose that on the first stage it might be enough to use\ninstance_types\'s extra specs to specify what exactly should be assigned to\nthe instance. I don\'t think that cloud users should have a control about\nwhat and when should be attached (for sure not physical USBs). IMHO,\nhaving special instance types (like with X PCI devices of type Y or with\nGPU, etc) will be enough.\n\nWe can easily propagate information about device availability to the\nscheduler and on scheduler level to make a decision about proper host.\n\nRegarding querying HW resources - we implemented it on host settings\nlevel. Of course we can add something on virt driver level, but it will be\nquite different per each installation type.\n\nRegards,\n-Vladimir\n\n\n-----Original Message-----\nFrom: Vishvananda Ishaya [mailto:vishvananda at gmail.com]\nSent: Thursday, November 01, 2012 11:22 AM\nTo: OpenStack Development Mailing List\nCc: Ian Wells; vladimir at zadarastorage.com\nSubject: Re: [openstack-dev] Some idea on device assignment support\n\n\nOn Nov 1, 2012, at 8:39 AM, heut2008 <heut2008 at gmail.com> wrote:\n\n>\n> should  we create  a new table to  manage all these  devices? or  each\n> nova-compute node manage their own devices allocation,if there is no\n> new table to record this.  we need each kind of passthrough  devices\n> has a driver to keep track of how many resources is free and how many\n> is in use,  these info  is updated to schedule  by sending capability\n> info periodly.\n\nI would prefer to avoid adding new tables unless we have to. It seems like\nthe HostState class in host_manager needs to be able to support arbitrary\nkeys for counting resources. Then we could create filter and weighting\nfunctions based on these arbitrary keys and update the consume method to\nconsume resources from these keys based on instance_type_extra_specs.\n\nPerhaps we need some kind of compute_metadata. there is a compute stats\ntable which we might be able to abuse for this purpose.\n\nVish\n\n\n','<97941D6A-8A1E-4897-9078-F0863B80388B@gmail.com>',NULL),('<0bc9dde0e8e09f9d23472c42c62fee47@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-18 13:33:23',-18000,'2013-10-18 18:33:23',NULL,'[openstack-dev] Building on Debian: Havana unit tests at build\n	time report','On 2013-10-18 03:37, Thomas Goirand wrote:\n> On 10/18/2013 02:06 AM, Clint Byrum wrote:\n>> A link to instructions on setting up a wheezy box for this testing \n>> would\n>> be helpful.\n> \n> Just install a minimal Wheezy machine, add my repositories (using the\n> Jenkins one at \"*.pkgs.enovance.com\"), then do \"apt-get install\n> openstack-toaster\". I\'ll be trying to provide a new preseed script so\n> that just running the script will be enough. I have that already, \n> though\n> it needs to be updated for Havana. I\'ll post instructions when it is \n> ready.\n> \n>>> No unit test failure / error (in both Sid and Wheezy). However, Heat\n>>> doesn\'t include a -P option in ./run_tests.sh, and insists on running\n>>> the PEP8 checks, which fails because Sid has pyflakes 0.7.3, and Heat\n>>> wants 0.7.2:\n>>> \n>> \n>> run_tests.sh is there for _your_ convenience. And by you I mean\n>> packagers and others who want to run the tests with system python.\n> \n> And it\'s been very helpful, though there\'s room for improvement.\n> \n>> IMO you\'d be better off adding a --no-venv option to tox to run the\n>> prescribed commands with system python, or even just parsing tox.ini \n>> to\n>> do that yourself. You\'ll find that the commands in tox.ini are better\n>> maintained, since they are gated.\n>> \n>> Anyway, I\'d gladly accept a patch to add -P.\n> \n> I wonder: are the different run_tests.sh scripts maintained in Oslo? It\n> feels strange that do we have different options for different OpenStack\n> projects (like missing -P and -N options sometimes).\n> \n> On the nit-picking details side, an option to disable color output \n> would\n> be great (it\'s ugly to read [32mOK  0.03 ...). Different\n> projects have different behaviors in this regard. (for example, Glance\n> always display in colors, while Cinder doesn\'t)\n\nI believe there was some work done around getting run_tests.sh into \nOslo, but I don\'t know that it was ever finished, and if it was it \nobviously isn\'t being used in the other projects.  Glancing through \noslo-incubator I don\'t see anything that looks related so I\'m guessing \nit just didn\'t happen.\n\n-Ben\n\n\n','<5260F356.1050101@debian.org>',NULL),('<0BCFD776-AA49-4178-8D90-7487723A2E22@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 12:37:19',32400,'2013-12-04 03:37:19',NULL,'[openstack-dev] [Neutron] DHCP Agent Reliability','\nOn Dec 4, 2013, at 11:57 AM, Clint Byrum <clint at fewbar.com> wrote:\n\n> Excerpts from Maru Newby\'s message of 2013-12-03 08:08:09 -0800:\n>> I\'ve been investigating a bug that is preventing VM\'s from receiving IP addresses when a Neutron service is under high load:\n>> \n>> https://bugs.launchpad.net/neutron/+bug/1192381\n>> \n>> High load causes the DHCP agent\'s status updates to be delayed, causing the Neutron service to assume that the agent is down.  This results in the Neutron service not sending notifications of port addition to the DHCP agent.  At present, the notifications are simply dropped.  A simple fix is to send notifications regardless of agent status.  Does anybody have any objections to this stop-gap approach?  I\'m not clear on the implications of sending notifications to agents that are down, but I\'m hoping for a simple fix that can be backported to both havana and grizzly (yes, this bug has been with us that long).\n>> \n>> Fixing this problem for real, though, will likely be more involved.  The proposal to replace the current wsgi framework with Pecan may increase the Neutron service\'s scalability, but should we continue to use a \'fire and forget\' approach to notification?  Being able to track the success or failure of a given action outside of the logs would seem pretty important, and allow for more effective coordination with Nova than is currently possible.\n>> \n> \n> Dropping requests without triggering a user-visible error is a pretty\n> serious problem. You didn\'t mention if you have filed a bug about that.\n> If not, please do or let us know here so we can investigate and file\n> a bug.\n\nThere is a bug linked to in the original message that I am already working on.  The fact that that bug title is \'dhcp agent doesn\'t configure ports\' rather than \'dhcp notifications are silently dropped\' is incidental.\n\n> \n> It seems to me that they should be put into a queue to be retried.\n> Sending the notifications blindly is almost as bad as dropping them,\n> as you have no idea if the agent is alive or not.\n\nThis is more the kind of discussion I was looking for.  \n\nIn the current architecture, the Neutron service handles RPC and WSGI with a single process and is prone to being overloaded such that agent heartbeats can be delayed beyond the limit for the agent being declared \'down\'.  Even if we increased the agent timeout as Yongsheg suggests, there is no guarantee that we can accurately detect whether an agent is \'live\' with the current architecture.  Given that amqp can ensure eventual delivery - it is a queue - is sending a notification blind such a bad idea?  In the best case the agent isn\'t really down and can process the notification.  In the worst case, the agent really is down but will be brought up eventually by a deployment\'s monitoring solution and process the notification when it returns.  What am I missing? \n\nPlease consider that while a good solution will track notification delivery and success, we may need 2 solutions:\n\n1. A \'good-enough\', minimally-invasive stop-gap that can be back-ported to grizzly and havana.\n\n2. A \'best-effort\' refactor that maximizes the reliability of the DHCP agent.\n\nI\'m hoping that coming up with a solution to #1 will allow us the breathing room to work on #2 in this cycle.\n\n\nm.\n\n\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1386123927-sup-3010@clint-HP>',NULL),('<0BD3E26D-C360-480E-AB52-975063C409E1@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 14:35:52',14400,'2014-01-29 10:35:52',NULL,'[openstack-dev] [savanna] How to handle diverging EDP job\n	configuration settings','Thank you for bringing this up, Trevor.\n\nEDP gets more diverse and it\'s time to change its model.\nI totally agree with your proposal, but one minor comment.\nInstead of \"savanna.\" prefix in job_configs wouldn\'t it be better to make it\nas \"edp.\"? I think \"savanna.\" is too more wide word for this.\n\nAnd one more bureaucratic thing... I see you already started implementing it [1], \nand it is named and goes as new EDP workflow [2]. I think new bluprint should be \ncreated for this feature to track all code changes as well as docs updates. \nDocs I mean public Savanna docs about EDP, rest api docs and samples.\n\n[1] https://review.openstack.org/#/c/69712\n[2] https://blueprints.launchpad.net/openstack/?searchtext=edp-oozie-streaming-mapreduce\n\nRegards,\nAlexander Ignatov\n\n\n\nOn 28 Jan 2014, at 20:47, Trevor McKay <tmckay at redhat.com> wrote:\n\n> Hello all,\n> \n> In our first pass at EDP, the model for job settings was very consistent\n> across all of our job types. The execution-time settings fit into this\n> (superset) structure:\n> \n> job_configs = {\'configs\': {}, # config settings for oozie and hadoop\n> 	       \'params\': {},  # substitution values for Pig/Hive\n> 	       \'args\': []}    # script args (Pig and Java actions)\n> \n> But we have some things that don\'t fit (and probably more in the\n> future):\n> \n> 1) Java jobs have \'main_class\' and \'java_opts\' settings\n>   Currently these are handled as additional fields added to the\n> structure above.  These were the first to diverge.\n> \n> 2) Streaming MapReduce (anticipated) requires mapper and reducer\n> settings (different than the mapred.xxxx.class settings for\n> non-streaming MapReduce)\n> \n> Problems caused by adding fields\n> --------------------------------\n> The job_configs structure above is stored in the database. Each time we\n> add a field to the structure above at the level of configs, params, and\n> args, we force a change to the database tables, a migration script and a\n> change to the JSON validation for the REST api.\n> \n> We also cause a change for python-savannaclient and potentially other\n> clients.\n> \n> This kind of change seems bad.\n> \n> Proposal: Borrow a page from Oozie and add \"savanna.\" configs\n> -------------------------------------------------------------\n> I would like to fit divergent job settings into the structure we already\n> have.  One way to do this is to leverage the \'configs\' dictionary.  This\n> dictionary primarily contains settings for hadoop, but there are a\n> number of \"oozie.xxx\" settings that are passed to oozie as configs or\n> set by oozie for the benefit of running apps.\n> \n> What if we allow \"savanna.\" settings to be added to configs?  If we do\n> that, any and all special configuration settings for specific job types\n> or subtypes can be handled with no database changes and no api changes.\n> \n> Downside\n> --------\n> Currently, all \'configs\' are rendered in the generated oozie workflow.\n> The \"savanna.\" settings would be stripped out and processed by Savanna,\n> thereby changing that behavior a bit (maybe not a big deal)\n> \n> We would also be mixing \"savanna.\" configs with config_hints for jobs,\n> so users would potentially see \"savanna.xxxx\" settings mixed with oozie\n> and hadoop settings.  Again, maybe not a big deal, but it might blur the\n> lines a little bit.  Personally, I\'m okay with this.\n> \n> Slightly different\n> ------------------\n> We could also add a \"\'savanna-configs\': {}\" element to job_configs to\n> keep the configuration spaces separate.\n> \n> But, now we would have \'savanna-configs\' (or another name), \'configs\',\n> \'params\', and \'args\'.  Really? Just how many different types of values\n> can we come up with? :)\n> \n> I lean away from this approach.\n> \n> Related: breaking up the superset\n> ---------------------------------\n> \n> It is also the case that not every job type has every value type.\n> \n>             Configs   Params    Args\n> Hive            Y         Y        N\n> Pig             Y         Y        Y\n> MapReduce       Y         N        N\n> Java            Y         N        Y\n> \n> So do we make that explicit in the docs and enforce it in the api with\n> errors?\n> \n> Thoughts? I\'m sure there are some :)\n> \n> Best,\n> \n> Trevor\n> \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1390927627.22978.46.camel@tmckaylt.rdu.redhat.com>',NULL),('<0BF6DA91-B388-488B-8BA3-265743A3AEF5@nebula.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-18 19:15:15',0,'2012-02-18 19:15:15',NULL,'[OpenStack Foundation] Foundation Structure Draft','My impression from the documents written so far, as well as my own personal desire, is that the \"OpenStack Technical Community\" are the people who are contributing to openstack - reporting bugs, developing code, writing docs, helping folks on IRC, etc. The gist of the bar to pass is \"do you give your time to the community to improve the overall health of OpenStack as a product\".\n\n- joe\n\nOn Feb 15, 2012, at 8:21 AM, \"Jim Jagielski\" <jimjag at gmail.com> wrote:\n\n> On Wed, Feb 15, 2012 at 11:01 AM, Dave Neary <dave at neary-consulting.com> wrote:\n> It may also make sense to discuss growing the size of the TB to\n>> reflect the increasing diversity of the OpenStack technical community.\n>> \n> \n> This may sound like a loaded question, but it isn\'t.\n> \n> Who *is* the OpenStack technical community? Is it the developer\n> community? Or the corporate end-user community?\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n','<CAJWaTXRFq7FGnUW3CPxTP8Kqhzf+m_EDA-vZmC1W4ROpRreYHA@mail.gmail.com>',NULL),('<0BFD24A8-919C-4352-9FF3-565DF001512A@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-12 10:48:44',-28800,'2014-02-12 18:48:44',NULL,'[openstack-dev] [qa][neutron] API tests in the Neutron tree','At the last 2 summits, I\'ve suggested that API tests could be maintained in the Neutron tree and reused by Tempest.  I\'ve finally submitted some patches that demonstrate this concept:\n\nhttps://review.openstack.org/#/c/72585/  (implements a unit test for the lifecycle of the network resource)\nhttps://review.openstack.org/#/c/72588/  (runs the test with tempest rest clients)\n\nMy hope is to make API test maintenance a responsibility of the Neutron team.  The API compatibility of each Neutron plugin has to be validated by Neutron tests anyway, and if the tests are structured as I am proposing, Tempest can reuse those efforts rather than duplicating them.\n\nI\'ve added this topic to this week\'s agenda, and I would really appreciate it interested parties would take a look at the patches in question to prepare themselves to participate in the discussion.\n\n\nm.\n\n',NULL,NULL),('<0c094735ec0f4482b7022528d9e2e432@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 14:19:52',0,'2014-02-25 14:19:52',NULL,'[openstack-dev] Devstack Error','Hi Stackers-\n\nWhen I configured Jenkins to run the Sandbox tempest testing, While devstack is running,\nI have seen error\n\n\"ERROR: Invalid Openstack Nova credentials\"\n\nand another error\n\n\"ERROR: HTTPConnection Pool(host=\'127.0.0.1\', port=8774): Max retries exceeded wuth url: /v2/91dd....(caused by <class \'socket.error\'>: [Errno 111] Connection refused)\n\nI feel devstack automates the openstack environment.\n\nKindly guide me resolve the issue.\n\nThanks in advance.\n\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/cca9d01f/attachment.html>\n\n',NULL,NULL),('<0c094735ec0f4482b7022528d9e2e432@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-25 14:19:52',0,'2014-02-25 14:19:52',NULL,'[OpenStack-Infra] Devstack Error','Hi Stackers-\n\nWhen I configured Jenkins to run the Sandbox tempest testing, While devstack is running,\nI have seen error\n\n\"ERROR: Invalid Openstack Nova credentials\"\n\nand another error\n\n\"ERROR: HTTPConnection Pool(host=\'127.0.0.1\', port=8774): Max retries exceeded wuth url: /v2/91dd....(caused by <class \'socket.error\'>: [Errno 111] Connection refused)\n\nI feel devstack automates the openstack environment.\n\nKindly guide me resolve the issue.\n\nThanks in advance.\n\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140225/cca9d01f/attachment.html>\n\n',NULL,NULL),('<0C0B7EC1-BA7C-4D56-AB53-2FF083EB52C5@me.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-30 09:17:33',-25200,'2012-07-30 16:17:33',NULL,'[openstack-dev] [Keystone] Agenda items for this week','Sounds good Adam - \n\nConsider it so scheduled (updated http://wiki.openstack.org/Meetings/KeystoneMeeting)\n\n-joe\n\nOn Jul 30, 2012, at 8:56 AM, Adam <adam at younglogic.com> wrote:\n> I\'d like to propose some items for this weeks agenda.\n> \n> \n> 1. Domains:  lets get an agreement on what we want for it, and decision to submite to Folsom or cut. (gyee,  your presence will greatly help)\n> \n> 2.  Acceptance criteria for PKI as the default auth mechanism.  I think I\'d like to label it as \"Tech preview\" for now,  until we have more people beating on it.\n> \n> 3.  Dealing with API/REturn code breakages.  Should we label the Folsom API  2.1  or something?\n> \n> 4.  Summit:  we should be generating a list of sessions for the Summit.\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5016AEA4.90702@younglogic.com>',NULL),('<0C165BFF-8159-4C2E-B2A9-B4E5F1E5499A@egon.cc>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-23 10:07:20',-25200,'2014-04-23 17:07:20',NULL,'[Openstack] How to recover my vms after devstack was unstacked?','\nOn Apr 23, 2014, at 9:04 AM, Michael Monette <mmonette at 2keys.ca> wrote:\n\n> I\'m locked out of horizon right now and I don\'t really care about making openstack work. I just need to bring up the vms to pul off some data. (postgres database). Then I can get rid of all the vms\n\nIf you really just need some data, guestfish might be the way to go. That way you can just extract the files you need, and you don?t run the risk of any number of bad things happening to the VM.\n\nCheers,\n-j\n\n','<97c65b81-fd64-4390-a0c8-06e9e6f08c6e@email.android.com>',NULL),('<0C26B053-CE28-4E93-BAA8-5345680D8DD9@Radware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-12 20:52:58',0,'2014-05-12 20:52:58',NULL,'[openstack-dev] [Neutron][LBaaS] Meetup?','During our brief meeting today, we tentatively scheduled to meet today at 5:30 PM.\nIs this still on?\nWhere should we meet?\n\nRegards,\n             -Sam.\n\nOn May 12, 2014, at 1:10 PM, \"Adam Harwell\" <adam.harwell at RACKSPACE.COM<mailto:adam.harwell at RACKSPACE.COM>> wrote:\n\n\nSome of us are at a table towards the back by the B3b door (and a large restrooms sign).\n\nOn May 12, 2014 12:24 PM, Adam Harwell <adam.harwell at RACKSPACE.COM<mailto:adam.harwell at RACKSPACE.COM>> wrote:\n\nYeah, I guess we\'ll try to catch people after this session (lunch officially starts at 12:45 apparently).\n\nOn May 12, 2014 11:48 AM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\n\nI\'m going to attend the next nw session @b103, we can meet in between. Im in b103 too.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140512/2324206f/attachment.html>\n\n','<63EB41988CA88745B3CB007CB448F154147AA44A@ORD1EXD03.RACKSPACE.CORP>',NULL),('<0c36b478a13d4aa8a57db3fcf95a657d@BN1PR07MB022.namprd07.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 23:46:15',0,'2014-04-14 23:46:15',NULL,'[openstack-dev] [trove] Blueprint Review: \"Allow volume snapshot as\n another way for data backuping\"','At the blueprint review for the Trove team on April 14th, we reviewed \"Allow volume snapshot as another way for data backuping\" (https://blueprints.launchpad.net/trove/+spec/volume-snapshot).\n\n\n\nThe detailed specification is available at https://wiki.openstack.org/wiki/Trove/volume-data-snapshot-design\n\n\n\nIn this blueprint, the intent is to provide a mechanism by which a snapshot of the data store can be generated for the purpose of backup.\n\n\n\nThe theory is that the backup workflow would be in three steps:\n\n\n\n1. flush database and mark read-only\n\n2. take snapshot\n\n3. revert database to normal operation\n\n\n\nIn practice, if using something like LVM, the database need be read-only only for enough time to start the snapshot as LVM would ensure that the snapshot is consistent as of some point in time. However, even with that, many details remain that are potentially very important.\n\n\n\nIMHO the blueprint should be significantly revised before re-review.\n\n\n\n(a) In particular, it would be good to understand exactly what the limitations of the proposed implementation are likely to be. This could include things like configurations that would work, storage engines that would be supported (or not), performance considerations, etc.,\n\n\n\n(b) It would also be important in this particular case to understand (for datastores that will be implemented in this iteration) how the system will achieve step 1 above.\n\n\n\n(c) Given that this is supposed to be a feature that would work for multiple datastores, ease of implementing a new data store should be given some consideration. It would be worthwhile if the blueprint included information on how this would be for a datastore to be implemented in the future.\n\n\n\nOne recommendation is that a simple illustration of the framework being implemented here (that could be shared across datastores) is provided, as well as details about the implementation (maybe only at pseudo-code level) of the datastores that will be implemented in the initial phase. One could easily conceive of a framework that provided default stubs that meaningfully responded with a \"Not Supported\" error, and an implementer could provide the appropriate code for the datastore in question and things would Just Work(tm)\n\n\n\n(d) Some more information about how the \'restore\' would be orchestrated would be valuable. Similar information as requested above for the \'backup\' would be worthwhile adding to the blueprint.\n\n\n\n(e) With respect to \'restore\', [this point was brought up during the review by dougshelley66 and vgnbkr] the \"point in time recovery\" blueprint review just before this one yielded a significant discussion around restoring a backup over top of the running instance. The concerns were that doing this could result in the loss of user data. In the end, that feature was removed from the blueprint. It seems like this blueprint has the same property on restore - that being - that restoring the snapshot would eliminate the volume that currently houses the user\'s data. Why wouldn\'t that be a concern for this approach?\n\n\n\nI\'m not intending to summarize the discussion, nor present feedback from all parties to the review; others at the review had other concerns as well and I\'ll let them contribute those to this mail thread if they so desire.\n\n-amrith\n\n--\n\nAmrith Kumar, CTO, Tesora\n\nTwitter: @amrithkumar\nEmail: amrith at tesora.com\nSkype: amrith.skype\nWeb: http://www.tesora.com\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140414/132e744b/attachment-0001.html>\n\n',NULL,NULL),('<0c4bbe7ae2c34983859306543b2b141a@e15be-01.zdv.Uni-Mainz.DE>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-26 22:20:49',0,'2014-11-26 22:20:49',NULL,'[Openstack] Nova DB sync Operational error','Hi Amit,\n\nCan you verify the GRANTS allowed on the nova database? By GRANTS, I mean the privileges / permissions for the nova database.\n\nRegards,\nKrishnaprasad\nFrom: Amit Anand [mailto:aanand at viimed.com]\nSent: Mittwoch, 26. November 2014 22:56\nTo: Jay Pipes\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Nova DB sync Operational error\n\nWell created a new controller on a whole new machine and get all the way up until compute and get same error again. I have to think it something with my nova.conf but I cant figure it out. Ive pasted here so if anyone can take a look and see maybe what Im doing incorrect I would appreciate it...\n\nhttp://paste.openstack.org/show/139079/\n\n\n\n\nOn Wed, Nov 26, 2014 at 4:09 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:\nIm going to try building a new controller on a whole new nuc see if I get the same I will keep yall abreast if it works or not. In any case thank you very much for all your help!!!\n\nOn Wed, Nov 26, 2014 at 3:56 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:\n\nPassword is viimed1\n\n\n\nOn Wed, Nov 26, 2014 at 3:55 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:\nGeorge\n\nThanks. Yeah there no other nova.conf I went as far as to do a find in case I put somewhere nothing turned up except the proper one. I did have a nova.conf.orig (I always make a backup so i can always start over) and was hoping maybe you hit the nail on the head so I moved that out to my  /home/amit dir but alas that failed as well  :-(\n\nPermissions I made rwrwrw still same.\n\n\n\n\n\nOn Wed, Nov 26, 2014 at 3:42 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:\nGeo\n\nError logs are here:\n\nhttp://paste.openstack.org/show/139035/\n\nWhen I run your command with password nova it fails - when I run it with the real password it works fine\n\n[root at controller ~]# mysql -u nova -p -h controller nova\nEnter password:\nI entered nova here\nERROR 1045 (28000): Access denied for user \'nova\'@\'controller\' (using password: YES)\n\n\n[root at controller ~]# mysql -u nova -p -h controller nova\nEnter password:\nI entered real password here\nWelcome to the MariaDB monitor.  Commands end with ; or \\g.\nYour MariaDB connection id is 13\nServer version: 5.5.40-MariaDB MariaDB Server\n\nCopyright (c) 2000, 2014, Oracle, Monty Program Ab and others.\n\nType \'help;\' or \'\\h\' for help. Type \'\\c\' to clear the current input statement.\n\nMariaDB [nova]> quit\nBye\n\n\n\n\n\nOn Wed, Nov 26, 2014 at 3:36 PM, Amit Anand <aanand at viimed.com<mailto:aanand at viimed.com>> wrote:\nJay,\n\nSo this is the command that u sent, works just fine connect to Nova DB:\n\n[root at controller nova]# mysql -unova -hlocalhost -p -Dnova\nEnter password:\nWelcome to the MariaDB monitor.  Commands end with ; or \\g.\nYour MariaDB connection id is 8\nServer version: 5.5.40-MariaDB MariaDB Server\n\nCopyright (c) 2000, 2014, Oracle, Monty Program Ab and others.\n\nType \'help;\' or \'\\h\' for help. Type \'\\c\' to clear the current input statement.\n\nMariaDB [nova]>\n\n\nI also changed in nvoa.conf connection=mysql://nova:__PASSWORD at localhost/nova (I tried with both a space and a _ as I was not sure exactly what you meant - still same error) :-(\n\nI also took a look at a command you ran and I tried it, would this be correct output (notice I didnt specify a DB in command)?\n\nMariaDB [mysql]> SELECT * FROM db WHERE User = \'root\'\\G\n*************************** 1. row ***************************\n                 Host: %\n                   Db: nova\n                 User: root\n          Select_priv: Y\n          Insert_priv: Y\n          Update_priv: Y\n          Delete_priv: Y\n          Create_priv: Y\n            Drop_priv: Y\n           Grant_priv: Y\n      References_priv: Y\n           Index_priv: Y\n           Alter_priv: Y\nCreate_tmp_table_priv: Y\n     Lock_tables_priv: Y\n     Create_view_priv: Y\n       Show_view_priv: Y\n  Create_routine_priv: Y\n   Alter_routine_priv: Y\n         Execute_priv: Y\n           Event_priv: Y\n         Trigger_priv: Y\n1 row in set (0.01 sec)\n\nAlso this is the output for user Nova:\n\nMariaDB [mysql]> SELECT * FROM db WHERE User = \'nova\'\\G;\n*************************** 1. row ***************************\n                 Host: localhost\n                   Db: nova\n                 User: nova\n          Select_priv: Y\n          Insert_priv: Y\n          Update_priv: Y\n          Delete_priv: Y\n          Create_priv: Y\n            Drop_priv: Y\n           Grant_priv: N\n      References_priv: Y\n           Index_priv: Y\n           Alter_priv: Y\nCreate_tmp_table_priv: Y\n     Lock_tables_priv: Y\n     Create_view_priv: Y\n       Show_view_priv: Y\n  Create_routine_priv: Y\n   Alter_routine_priv: Y\n         Execute_priv: Y\n           Event_priv: Y\n         Trigger_priv: Y\n*************************** 2. row ***************************\n                 Host: %\n                   Db: nova\n                 User: nova\n          Select_priv: Y\n          Insert_priv: Y\n          Update_priv: Y\n          Delete_priv: Y\n          Create_priv: Y\n            Drop_priv: Y\n           Grant_priv: N\n      References_priv: Y\n           Index_priv: Y\n           Alter_priv: Y\nCreate_tmp_table_priv: Y\n     Lock_tables_priv: Y\n     Create_view_priv: Y\n       Show_view_priv: Y\n  Create_routine_priv: Y\n   Alter_routine_priv: Y\n         Execute_priv: Y\n           Event_priv: Y\n         Trigger_priv: Y\n2 rows in set (0.00 sec)\n\n\nOn Wed, Nov 26, 2014 at 3:12 PM, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:\nOn 11/26/2014 02:36 PM, Amit Anand wrote:\nSame error - also tried with 127.0.0.1. Even crazier I removed all\nkeystone nova (user, service, etc) and dropped the nova DB and recreated\nthat, then recreated keystone nova with a new different password,\nupdated nova.conf with new password and still get the same error (notice\nbelow now nova has the different password):\n\nPermissions for a user are not affected by the removal of a database. You can even add permissions for a user to operate on a database that doesn\'t exist:\n\nmysql> SHOW DATABASES;\n+--------------------+\n| Database           |\n+--------------------+\n| information_schema |\n| mysql              |\n| performance_schema |\n| test               |\n+--------------------+\n4 rows in set (0.03 sec)\n\nmysql> GRANT ALL ON foo.* TO root at localhost;\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> GRANT ALL ON test.* TO root at localhost;\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> USE mysql\nDatabase changed\nmysql> SELECT * FROM db WHERE User = \'root\' AND Db = \'foo\'\\G\n*************************** 1. row ***************************\n                 Host: localhost\n                   Db: foo\n                 User: root\n          Select_priv: Y\n          Insert_priv: Y\n          Update_priv: Y\n          Delete_priv: Y\n          Create_priv: Y\n            Drop_priv: Y\n           Grant_priv: N\n      References_priv: Y\n           Index_priv: Y\n           Alter_priv: Y\nCreate_tmp_table_priv: Y\n     Lock_tables_priv: Y\n     Create_view_priv: Y\n       Show_view_priv: Y\n  Create_routine_priv: Y\n   Alter_routine_priv: Y\n         Execute_priv: Y\n           Event_priv: Y\n         Trigger_priv: Y\n1 row in set (0.00 sec)\n\nGo figure :)\n\nIf you manually specify the host on the command line, do you still get in to the MySQL server?\n\ni.e., if you do this on the command line, does it work?\n\nmysql -unova -hlocalhost -p -Dnova\n\nBest,\n-jay\nMariaDB [mysql]> SELECT user,password,host FROM user;\n+----------+-------------------------------------------+-----------+\n| user     | password                                  | host      |\n+----------+-------------------------------------------+-----------+\n| root     | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n| root     | *7088873CEA983CB57491834389F9BB9369B9D756 | 127.0.0.1 |\n| root     | *7088873CEA983CB57491834389F9BB9369B9D756 | ::1       |\n| keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n| keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n| glance   | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n| glance   | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n| nova     | *3DA97D7423D54524806BFF6A19D94F78EEF97338 | localhost |\n| nova     | *3DA97D7423D54524806BFF6A19D94F78EEF97338 | %         |\n| root     | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n+----------+-------------------------------------------+-----------+\n10 rows in set (0.00 sec)\n\n\nOn Wed, Nov 26, 2014 at 2:26 PM, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>\n<mailto:jaypipes at gmail.com<mailto:jaypipes at gmail.com>>> wrote:\n\n    On 11/26/2014 02:21 PM, Amit Anand wrote:\n\n        Hi Jay - I believe so below is the part that is in the nova.conf\n\n        # The SQLAlchemy connection string used to connect to the\n        # bare-metal database (string value)\n        connection=mysql://nova:__PASSWORD at controller/nova\n\n        The PASSWORD is exactly the same what I have in the conf file\n        and what I\n        have in the nova.conf\n\n        Im doing this manually via the Juno instruction guide for CentOs 7.\n\n\n    try:\n\n    connection=mysql://nova:__PASSWORD at localhost/nova\n\n    Best,\n    -jay\n\n\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141126/0162cc3a/attachment.html>\n\n','<CAAvmQat6oy7QcPykhroHbgksgz8qQODOYT_J_Et2q_5=cG1hYQ@mail.gmail.com>',NULL),('<0C5692D0-C14A-4108-AC5A-C9C2AC29FDBC@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-09-06 17:14:59',-14400,'2012-09-06 21:14:59',NULL,'[Openstack-operators] Launching new instances failing despite\n	free resources','\nOn Sep 6, 2012, at 9:18 AM, Jonathan Proulx <jon at jonproulx.com> wrote:\n\n> On Thu, Sep 6, 2012 at 9:00 AM, Jonathan Proulx <jon at jonproulx.com> wrote:\n>> running Essex (as packaged) on Ubuntu 12.04 launching new instances\n>> has stopped working. They almost imediately enter Error Spawning state\n>> which is consistent with my experience of resource starvation in the\n>> cluster or scheduling errors.  Most recently I was /var/lib/nova on\n>> one of the compute nodes filled but the schedule kept trying to run\n>> new instances there (which is it\'s own issue, but I fixed that for me\n>> simply by expanding that partition).  Though in that case they were\n>> assigned to that node and then failing, in this case there is no\n>> compute node associated with the failed instance.\n> \n> I tell a lie, there are all trying to run on the same compute node and\n> in this case it has in sufficient memory to run the instance, so it\n> shouldn\'t try to do so.  here are my scheduler options:\n> \n> --scheduler_available_filters=nova.scheduler.filters.standard_filters\n> --scheduler_default_filters=AvailabilityZoneFilter,RamFilter,CoreFilter,ComputeFilter\n> --least_cost_functions=nova.scheduler.least_cost.compute_fill_first_cost_fn\n> --compute_fill_first_cost_fn_weight=1.0\n> \n> My intention (and what it seems to have been doing) is filling nodes\n> based on RAM capacity rather than spreading as the default is.  I do\n> believe it shouldn\'t try and run instances requiring 2G of ram when\n> there are only 600M free.\n> \n> \n\nBy default, Essex tries to over provision based on memory. Try setting:\n--ram_allocation_ratio=1\n\nSee http://docs.openstack.org/essex/openstack-compute/admin/content/scheduler-filters.html#ramfilter for more details (including why the over provisioning behavior is actually broken in Essex).\n\n\n> I can\'t seem to figure out how to map from id in the compute_nodes\n> table to host name or IP though there must be a way,\n> hypervisor_hostname seems most likely but that is all NULL, any\n> pointers there\n\n\nOooh, I\'m pretty sure there\'s a way to do this, but don\'t remember offhand. Does \"nova show <id>\" give you this info? \n\n\nTake care,\n\nLorin\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com\n\n\n\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120906/1f930812/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4897 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120906/1f930812/attachment-0001.bin>\n\n','<CABZB-sjLSf6NwZZ12=99fZPw3bamzpKWNbO7oCwvwU47b20B+Q@mail.gmail.com>',NULL),('<0C735BF3-271E-4097-9A27-BD55244962F8@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 15:58:06',-14400,'2014-06-09 19:58:06',NULL,'[openstack-dev] [Oslo] [Ironic] DB migration woes','\nOn Jun 9, 2014, at 1:08 PM, Mike Bayer <mbayer at redhat.com> wrote:\n\n> \n> On Jun 9, 2014, at 12:50 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:\n> \n>> There may be some problems with MySQL when testing parallel writes in\n>> different non-committing transactions, even in READ COMMITTED mode,\n>> due to InnoDB locking, if the queries use non-unique secondary indexes\n>> for UPDATE or SELECT..FOR UPDATE queries. This is done by the\n>> \"with_lockmode(\'update\')\" SQLAlchemy phrase, and is used in ~10 places\n>> in Nova. So I would not recommend this approach, even though, in\n>> principle, I agree it would be a much more efficient way of testing\n>> database reads/writes.\n>> \n>> More details here:\n>> http://dev.mysql.com/doc/refman/5.5/en/innodb-locks-set.html and\n>> http://dev.mysql.com/doc/refman/5.5/en/innodb-record-level-locks.html\n> \n> OK, but just to clarify my understanding, what is the approach to testing writes in parallel right now, are we doing CREATE DATABASE for two entirely distinct databases with some kind of generated name for each one?  Otherwise, if the parallel tests are against the same database, this issue exists regardless (unless autocommit mode is used, is FOR UPDATE accepted under those conditions?)\n\nTook a look and this seems to be the case, from oslo.db:\n\n	def create_database(engine):\n	    \"\"\"Provide temporary user and database for each particular test.\"\"\"\n	    driver = engine.name\n\n	    auth = {\n	        \'database\': \'\'.join(random.choice(string.ascii_lowercase)\n	                            for i in moves.range(10)),\n	        # ...\n\n	    sqls = [\n	        \"drop database if exists %(database)s;\",\n	        \"create database %(database)s;\"\n	    ]\n        \nJust thinking out loud here, I?ll move these ideas to a new wiki page after this post.    My idea now is that OK, we provide ad-hoc databases for tests, but look into the idea that we create N ad-hoc databases, corresponding to parallel test runs - e.g. if we are running five tests concurrently, we make five databases.   Tests that use a database will be dished out among this pool of available schemas.   In the *typical* case (which means not the case that we?re testing actual migrations, that?s a special case) we build up the schema on each database via migrations or even create_all() just once, run tests within rolled-back transactions one-per-database, then the DBs are torn down when the suite is finished.\n\nSorry for the thread hijack.\n\n\n\n\n','<60AABF54-5870-429D-B0A9-CE8A7E8249AC@redhat.com>',NULL),('<0C794314-637C-4F18-93E1-0B14DDE681BD@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 18:31:09',0,'2014-04-04 18:31:09',NULL,'[openstack-dev] [Nova] Hosts within two Availability Zones :\n possible or not ?','I am fine with taking the approach of user passing multiple avail. zones Az1,Az2 if he wants vm to be in (intersection of AZ1 and Az2).\nIt will be more cleaner.\n\nBut, similar approach should also be used while setting the default_scheduling_zone.\n\nSince, we will not be able to add host to multiple zones,\nonly way to guarantee even distribution across zones when user does not pass any zone,\nis to allow multiple zones in default_scheduling_zone param.\n\nThanks,\nMeghal\n\nOn Apr 4, 2014, at 2:38 AM, Sylvain Bauza <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>> wrote:\n\n\n\n\n2014-04-04 10:30 GMT+02:00 Sylvain Bauza <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>>:\nHi all,\n\n\n\n2014-04-03 18:47 GMT+02:00 Meghal Gosalia <meghal at yahoo-inc.com<mailto:meghal at yahoo-inc.com>>:\n\nHello folks,\n\nHere is the bug [1] which is currently not allowing a host to be part of two availability zones.\nThis bug was targeted for havana.\n\nThe fix in the bug was made because it was assumed\nthat openstack does not support adding hosts to two zones by design.\n\nThe assumption was based on the fact that ---\nif hostX is added to zoneA as well as zoneB,\nand if you boot a vm vmY passing zoneB in boot params,\nnova show vmY still returns zoneA.\n\nIn my opinion, we should fix the case of nova show\nrather than changing aggregate api to not allow addition of hosts to multiple zones.\n\nI have added my comments in comments #7 and #9 on that bug.\n\nThanks,\nMeghal\n\n[1] Bug - https://bugs.launchpad.net/nova/+bug/1196893\n\n\n\n\n\nThanks for the pointer, now I see why the API is preventing host to be added to a 2nd aggregated if there is a different AZ. Unfortunately, this patch missed the fact that aggregates metadata can be modified once the aggregate is created, so we should add a check when updating metadate in order to cover all corner cases.\n\nSo, IMHO, it\'s worth providing a patch for API consistency so as we enforce the fact that a host should be in only one AZ (but possibly 2 or more aggregates) and see how we can propose to user ability to provide 2 distincts AZs when booting.\n\nDoes everyone agree ?\n\n\n\n\nWell, I\'m replying to myself. The corner case is even trickier. I missed this patch [1] which already checks that when updating an aggregate to set an AZ, its hosts are not already part of another AZ. So, indeed, the coverage is already there... except for one thing :\n\nIf an operator is creating an aggregate with an AZ set to the default AZ defined in nova.conf and adds an host to this aggregate, nova availability-zone-list does show the host being part of this default AZ (normal behaviour). If we create an aggregate \'foo\' without AZ,  then we add the same host to that aggregate, and then we update the metadata of the aggregate to set an AZ \'foo\', then the AZ check won\'t notice that the host is already part of an AZ and will allow the host to be part of two distinct AZs.\n\nProof here : http://paste.openstack.org/show/75066/\n\nI\'m on that bug.\n-Sylvain\n\n[1] : https://review.openstack.org/#/c/36786\n-Sylvain\n\nOn Apr 3, 2014, at 9:05 AM, Steve Gordon <sgordon at redhat.com<mailto:sgordon at redhat.com>> wrote:\n\n----- Original Message -----\n\nCurrently host aggregates are quite general, but the only ways for an\nend-user to make use of them are:\n\n1) By making the host aggregate an availability zones (where each host\nis only supposed to be in one availability zone) and selecting it at\ninstance creation time.\n\n2) By booting the instance using a flavor with appropriate metadata\n(which can only be set up by admin).\n\n\nI would like to see more flexibility available to the end-user, so I\nthink we should either:\n\nA) Allow hosts to be part of more than one availability zone (and allow\nselection of multiple availability zones when booting an instance), or\n\nWhile changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with multi-AZ environments - \"I\'m OK with this instance running in AZ1 and AZ2, but not AZ*\".\n\n-Steve\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/1c6dc0b0/attachment.html>\n\n','<CANWE-C=nZgdUOKoRMvbaw2t1pE6XDmeejFDihYL6rL62dz_zaA@mail.gmail.com>',NULL),('<0C7DE9B4-750C-4AE8-A7A8-3FB29A135841@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 02:03:58',0,'2013-07-02 02:03:58',NULL,'[openstack-dev] [Openstack] Keystone store-quota-data blueprint','This topic came up at the last summit in Portland at [1] and [2].\n\nYehia and another colleague of his from HP had a design that was discussed and it seemed like they were going to start work on it. Another developer from CERN expressed interest too. I\'m not sure if anything ever really got started on it.\n\nI think you\'ll want to wait until Dolph gets back (next week?) before doing any major work on it. Ask him before moving forward.\n\nRegards,\nEverett\n\n[1] http://openstacksummitapril2013.sched.org/event/c0c6befcb4361e54d5c7e45b2f772de7\n[2] http://openstacksummitapril2013.sched.org/event/7bf2cdde2dfad733b499d9c2a3f60b08\n\nP.S. This email really belongs in openstack-dev\n\nOn Jul 1, 2013, at 10:24 AM, Dmitry Stepanenko wrote:\n\nHi folks,\n\nwe\'re going to work on store-quota-data blueprint\n(https://blueprints.launchpad.net/keystone/+spec/store-quota-data). Did anyone already work on it?\n\nThanks & regards,\nDmitry\n_______________________________________________\nMailing list: https://launchpad.net/~openstack\nPost to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>\nUnsubscribe : https://launchpad.net/~openstack\nMore help   : https://help.launchpad.net/ListHelp\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130702/2040aee1/attachment.html>\n\n','<CANWSOK-0vK=GK5Sk1UB_JjT7--oAzrNzJZB8H3-ROrZVKP3mmw@mail.gmail.com>',NULL),('<0C7DF581-7871-4478-A883-882400C58E91@kent.ac.uk>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-14 12:57:31',3600,'2013-05-14 11:57:31',NULL,'[openstack-dev] [Keystone] Authentication and password length','Hi All,\n\nWhen we performance tested our federated authentication middleware recently we found that the time to authenticate (internal time measurement) / get an unscoped token (JMeter network time measurement) increases by some 50% with a password of 28 characters when compared to a password of 9 characters, I\'ve detailed our results below for reference.\n\n100ms longer processing time seems quite a lot and we were hoping someone could explain this.\n\nMany thanks,\n\nKristy\n\nOn server measurements\n\nMean (Time taken MS)\n\nUsername\n\n9\n\n28\n\nID\n\nID\n\n9\n\n32\n\n9\n\n32\n\nPassword\n\n9\n\n175.15\n\n175.5\n\n176.1\n\n175.95\n\n28\n\n315.6\n\n314.4\n\n315.15\n\n317.25\n\nStandard deviation (MS)\n\nUsername\n\n9\n\n28\n\nID\n\nID\n\n9\n\n32\n\n9\n\n32\n\nPassword\n\n9\n\n6.968160673\n\n11.01912214\n\n8.866851337\n\n8.035939011\n\n28\n\n9.366482486\n\n7.450891858\n\n8.604007634\n\n8.925864251\n\n \n\n JMeter measurements\n\nMean (Time Taken MS)\n\nUsername\n\n9\n\n28\n\nID\n\nID\n\n9\n\n32\n\n9\n\n32\n\nPassword\n\n9\n\n222.2\n\n220.85\n\n221.85\n\n221.85\n\n28\n\n362.4\n\n359.65\n\n362.95\n\n362.95\n\nStandard deviation (MS)\n\nUsername\n\n9\n\n28\n\nID\n\nID\n\n9\n\n32\n\n9\n\n32\n\nPassword\n\n9\n\n30.7067625\n\n34.64143397\n\n30.18064036\n\n30.18064036\n\n28\n\n30.68382434\n\n32.59685971\n\n30.97448016\n\n30.97448016\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130514/59953405/attachment.html>\n\n',NULL,NULL),('<0C862BC9-287A-41C5-843F-1D5C27A56170@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-24 07:29:28',28800,'2014-05-23 23:29:28',NULL,'[Openstack] Openvswitch agent down','Does the time is synced between compute node and controller?\n\n????\nBest Regards\nTrump Zhang\n\n> ? 2014?5?23????5:58?Kiran Kumar <kirankumarkuvvarapu at gmail.com> ???\n> \n> Hi Kumar,\n> \n>       Reason might be  \"ovs_neutron_plugin.ini\" config file.. send me the config file so that we can rectify the problem.\n> \n> \n>> On Fri, May 23, 2014 at 9:53 AM, <yalla.gnan.kumar at accenture.com> wrote:\n>> Hi All,\n>> \n>>  \n>> \n>> I have a three node Havana setup. The neutron agent-list is showing the plugin agent in compute node as down:\n>> \n>> ---------------\n>> \n>> root at compute:/var/log/neutron# neutron agent-list\n>> \n>> +--------------------------------------+--------------------+---------+-------+----------------+\n>> \n>> | id                                   | agent_type         | host    | alive | admin_state_up |\n>> \n>> +--------------------------------------+--------------------+---------+-------+----------------+\n>> \n>> | 421c6c3c-c13a-414e-a9df-e8059c39b257 | DHCP agent         | neutron | :-)   | True           |\n>> \n>> | 6471090c-1c28-4bd7-aac0-dd2968adfec9 | Open vSwitch agent | compute | xxx   | True           |\n>> \n>> | 88b75990-8ec7-4835-b6e8-ecadaac41833 | Open vSwitch agent | neutron | :-)   | True           |\n>> \n>> | c4d44fe7-fdd0-4ee7-967d-85db45fbcd25 | L3 agent           | neutron | :-)   | True           |\n>> \n>> +--------------------------------------+--------------------+---------+-------+----------------+\n>> \n>>  \n>> \n>> -----------------------\n>> \n>>  \n>> \n>> But I checked it in compute . It is running fine.\n>> \n>>  \n>> \n>> ------------\n>> \n>> root at compute:/var/log/neutron# /etc/init.d/neutron-plugin-openvswitch-agent  status\n>> \n>> Rather than invoking init scripts through /etc/init.d, use the service(8)\n>> \n>> utility, e.g. service neutron-plugin-openvswitch-agent status\n>> \n>>  \n>> \n>> Since the script you are attempting to invoke has been converted to an\n>> \n>> Upstart job, you may also use the status(8) utility, e.g. status neutron-plugin-openvswitch-agent\n>> \n>> neutron-plugin-openvswitch-agent start/running, process 20774\n>> \n>> ---------------------\n>> \n>>  \n>> \n>>  \n>> \n>> What could be the reason ?\n>> \n>>  \n>> \n>>  \n>> \n>>  \n>> \n>> Thanks\n>> \n>> Kumar\n>> \n>> \n>> \n>> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. \n>> ______________________________________________________________________________________\n>> \n>> www.accenture.com\n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140524/be3bf9cd/attachment.html>\n\n','<CAN-BYWvjsC5DD7M5Mf0_QaB5Or_V3jh1T=Ate7Qap2gmUpy6xA@mail.gmail.com>',NULL),('<0C87C8A2-B3C7-47E3-A708-803D41270E37@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-27 10:10:51',-25200,'2012-09-27 17:10:51',NULL,'[openstack-dev] Problem with debugging program	having\n	eventlet.monkey_patch() code','\nOn Sep 27, 2012, at 10:05 AM, Adam Young <ayoung at redhat.com> wrote:\n\n> \n>> As a quick workaround you can change monkey patching at nova-scheduler script:\n>> \n>> eventlet.monkey_patch(thread=False)\n> \n> In Keystone, we have been moving toward a command line switch --no_monkeypatch that as of now is in the test runner, and I would like to submit for the keystone-all code as well.  I origianlly thought I would be removing all of the monkeypatching, until I realized that it was just the thread monkeypatch that was causing the debugging problem.\n> \n> \n> Can we standardize a name for this, and use it across all projects? Something like:\n> \n> --standard_threading?\n\nSure if we avoid an underscore --standard-threading ? --standard-threads ?\n\nVish\n\n\n\n','<50648774.4000504@redhat.com>',NULL),('<0C8B170E-F0F6-48AD-AC19-1F980CBE89D6@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 13:27:28',-14400,'2013-05-15 17:27:28',NULL,'[openstack-dev] VPNaaS strongswan questions...','Just FYI,\n\nI was able to get a site to site strongswan with IPSEC with PSKs setup (shown in the URL from my previous post) working on Ubuntu nodes running in VirtualBox VMs. The sticking points were loading socket-raw, instead of socket-default (as shown in the example), and setting IPv4 forwarding.\n\nNext, I\'ll look at Nachi\'s BP for API and look more into the strongswan wiki for info on setup (need to see how to set up via CLI). I\'ve gotta look at Swami\'s API/module wiki too! \n\n\nAny comments/suggestions welcome...\n\nPCM (Paul Michali)\n\n\nOn May 14, 2013, at 9:49 PM, Paul Michali wrote:\n\n> Hi guys? very slow process here?\n> \n> I finally was able to get four VMs running in Virtual box, with a topology and config set up like this:\n> \n> http://www.strongswan.org/uml/testresults/ikev2/net2net-psk/\n> \n> Only difference is that I have a NAT I/F (to do S/W installs), which shows as eth0.\n> \n> I restarted ipsec service on each GW. On moon,  it indicated that the pkcs11 plugging failed to load (thinking that is OK, as not using smart cards).  On sun, it indicated that the socket-default plugin failed to load. Though, I did the restart again and now it only mentions the pkcs11 plugin.\n> \n> I tried ipsec start on each GW. On sun, I see:\n> !! Your strongswan.conf contains manual plugin load options for\n> !! pluto and/or charon. This is recommended for experts only, see\n> !! http://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad\n> \n> Q: Is that possibly a problem?\n> \n> \n> I did ipsec up net-net on each side and I see messages of retransmitting:\n> \n> openstack at sun:/var/log$ sudo ipsec up net-net\n> initiating IKE_SA net-net[1] to 192.168.0.1\n> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]\n> sending packet: from 192.168.0.2[500] to 192.168.0.1[500]\n> retransmit 1 of request with message ID 0\n> sending packet: from 192.168.0.2[500] to 192.168.0.1[500]\n> retransmit 2 of request with message ID 0\n> sending packet: from 192.168.0.2[500] to 192.168.0.1[500]\n> \n> If I look at status, I see that it is connecting, but not completing:\n> \n> openstack at moon:/var/log$ sudo ipsec statusall\n> 000 Status of IKEv1 pluto daemon (strongSwan 4.5.2):\n> 000 interface lo/lo ::1:500\n> 000 interface lo/lo 127.0.0.1:500\n> 000 interface eth0/eth0 10.0.2.15:500\n> 000 interface eth1/eth1 10.1.0.1:500\n> 000 interface eth2/eth2 192.168.0.1:500\n> 000 %myid = \'%any\'\n> 000 loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem openssl gmp hmac xauth attr kernel-netlink resolve \n> 000 debug options: none\n> 000 \n> Status of IKEv2 charon daemon (strongSwan 4.5.2):\n>   uptime: 72 seconds, since May 14 21:32:21 2013\n>   malloc: sbrk 270336, mmap 0, used 237648, free 32688\n>   worker threads: 7 idle of 16, job queue load: 0, scheduled events: 1\n>   loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 revocation constraints pubkey pkcs1 pgp pem openssl fips-prf gmp agent pkcs11 xcbc hmac ctr ccm gcm attr kernel-netlink resolve socket-raw farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc dhcp led addrblock \n> Listening IP addresses:\n>   10.0.2.15\n>   10.1.0.1\n>   192.168.0.1\n> Connections:\n>      net-net:  192.168.0.1...192.168.0.2\n>      net-net:   local:  [moon.strongswan.org] uses pre-shared key authentication\n>      net-net:   remote: [sun.strongswan.org] uses any authentication\n>      net-net:   child:  10.1.0.0/16 === 10.2.0.0/16 \n> Security Associations:\n>      net-net[1]: CONNECTING, 192.168.0.1[%any]...192.168.0.2[%any]\n>      net-net[1]: IKE SPIs: 95f2e9c6f5315397_i* 0000000000000000_r\n>      net-net[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTHENTICATE IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME \n> \n> Q: Any idea why the SA is not connecting? Any debugging tips? I tried tcpdump on the I/F, but see no output during the startup. Installing wireshark on one node and will see what it shows.\n> \n> \n> Goal here is to get this going and then see what the commands are to setup and start the tunnels. Then, I\'d guess trying to see how that maps to the APIs.\n> \n> Comments/suggestions welcome!\n> \n> \n> PCM (Paul Michali)\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130515/4f0541d2/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130515/4f0541d2/attachment.pgp>\n\n','<2D05808D-3DBD-4377-B177-E881F3D95679@cisco.com>',NULL),('<0C8EEA55-A103-4A2C-BB92-EB75E3A1E334@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-29 14:32:31',-25200,'2014-09-29 21:32:31',NULL,'[openstack-dev] [Congress] PTL Non-Candidacy + Nomination','+1\n\n~sean\n\n> On Sep 29, 2014, at 2:20 PM, Peter Balland <pballand at vmware.com> wrote:\n> \n> It has been an honor to serve as the interim PTL for the Congress project during Juno.  Due to other commitments I have during the Kilo timeframe, I feel I would not be able to commit the time needed by the growing project.  In my place, I would like to nominate Tim Hinrichs for PTL of Congress.\n> \n> Tim has been involved in the Congress project since its inception, and has been serving as its chief architect.  He is very active in policy research, code, and community, and has a great strategic vision for the project.\n> \n> - Peter\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D04F1B40.B68C%pballand@vmware.com>',NULL),('<0c970abc20af4b198488fd85fc71e23e@BY2PR42MB101.048d.mgd.msft.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-11 07:12:02',0,'2014-12-11 07:12:02',NULL,'[openstack-dev] [Murano] Oslo.messaging error','\n\n\nHI Team,\n\nI am installing Murano on the Ubuntu 14.04 Juno setup and when I try the below install murano-api I encounter the below error. Please assist.\n\nWhen I install\n\nI am using the Murano guide link provided below:\nhttps://murano.readthedocs.org/en/latest/install/manual.html\n\n\nI am trying to execute the section 7\n\n1.    Open a new console and launch Murano API. A separate terminal is required because the console will be locked by a running process.\n2. $ cd ~/murano/murano\n3. $ tox -e venv -- murano-api \\\n4. > --config-file ./etc/murano/murano.conf\n\n\nI am getting the below error : I have a Juno Openstack ready and trying to integrate Murano\n\n\n2014-12-11 12:28:03.676 9524 INFO eventlet.wsgi [-] (9524) wsgi starting up on http://0.0.0.0:8082/\n2014-12-11 12:28:03.677 9524 DEBUG murano.common.statservice [-] Updating statistic information. update_stats /root/murano/murano/murano/common/statservice.py:57\n2014-12-11 12:28:03.677 9524 DEBUG murano.common.statservice [-] Stats object: <murano.api.v1.request_statistics.RequestStatisticsCollection object at 0x7ff72837d410> update_stats /root/murano/murano/murano/common/statservice.py:58\n2014-12-11 12:28:03.677 9524 DEBUG murano.common.statservice [-] Stats: Requests:0  Errors: 0 Ave.Res.Time 0.0000\nPer tenant: {} update_stats /root/murano/murano/murano/common/statservice.py:64\n2014-12-11 12:28:03.692 9524 DEBUG oslo.db.sqlalchemy.session [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION _check_effective_sql_mode /root/murano/murano/.tox/venv/local/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509\n2014-12-11 12:28:06.721 9524 ERROR oslo.messaging._drivers.impl_rabbit [-] AMQP server 192.168.x.x:5672 closed the connection. Check login credentials: Socket closed\n\nWarm Regards,\nRaghavendra Lad\n\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141211/85b0f01a/attachment.html>\n\n',NULL,NULL),('<0C97C280-4227-43B9-BCC4-2979DE9D5925@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-21 15:58:14',0,'2013-06-21 15:58:14',NULL,'[openstack-dev] [Heat][State-Management] Task/Workflow\n requirements for Heat','Sweet, thx Zane. \n\nLooking forward to figuring out how we can make this all work. Fun times ahead ;)\n\nSent from my really tiny device...\n\nOn Jun 21, 2013, at 1:24 AM, \"Zane Bitter\" <zbitter at redhat.com> wrote:\n\n> On 20/06/13 21:34, Joshua Harlow wrote:\n>> Thanks Adrian for adding that,\n>> \n>> Zane, it would be great if you could show up. I have a few questions about\n>> said heat requirements, especially about how the current mechanism\n>> accomplishes those requirements.\n> \n> Sorry for missing that meeting, I left the house right after sending that email. Unfortunately (for you ;) I won\'t be around for the next couple of weeks, but let\'s definitely sync when I get back.\n> \n>> IMHO I\'d rather not have 2 workflow libraries (aka your scheduler.py) and\n>> taskflow. It would be advantageous I think to focus on one way if we can.\n>> This would be beneficial to all and if we can merge those ideas into\n>> taskflow I\'m all for it personally. Since one of the possible\n>> ending-points for taskflow is in oslo, that would seem like a useful merge\n>> of ideas and code instead of a divergent approach.\n> \n> +1\n> \n> I wanted to wait until I had tested it with some more complicated use cases before trying to push it outside of Heat. Now that that is done and I have a reasonable level of confidence in it, it would be good to explore which parts can be rolled into TaskFlow and which can be replaced by existing stuff in TaskFlow. Documenting the requirements that it is currently satisfying in Heat was the first step in that process.\n> \n> cheers,\n> Zane.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<51C40C96.2000304@redhat.com>',NULL),('<0CB2CF7C-83FA-4F17-BF94-78FC3C717B27@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-29 08:24:16',-25200,'2013-09-29 15:24:16',NULL,'[Openstack] Implementing DB as a Service','> \n> On Sep 29, 2013, at 8:02 AM, Ali Nazemian <alinazemian at gmail.com> wrote:\n> \n> Hi,\n> I am looking for a way to run dbaas in our organization. I want to know that is there any way to do that using open stack? If yes how that is possible?\n> Regards.\n> \n\nHi, I believe you are looking for the Trove project. It\'s currently incubated and we will have the first integrated release in icehouse. See [1][2] for more info\n\n[1] https://launchpad.net/trove\n[2] https://wiki.openstack.org/wiki/Trove\n\n\n','<CAEYSxhUtD4c+KQ7O3B=qFLQZwdPZJ64R32tdG4DZOPnRLPWcoQ@mail.gmail.com>',NULL),('<0CBC3FDA-7CA6-48C1-AAC7-AEEBED3A1267@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-10-02 08:45:16',0,'2014-10-02 08:45:16',NULL,'[OpenStack-Infra] desperate to get zuul works again,\n see layout setting at the end of email','Hi,\n\nIt seems that the actual problem is the connection between Jenkins and Zuul. We have had a similar issue once and reinstalling the gearman jenkins plugin fixed the problem for us.\n\nThe error actually says, from what I know, that the job it tries to start is not registered with Zuul.\n\nOctavian.\n\nOn 2 Oct 2014, at 03:10, Phan, Van <tphan at paypal.com<mailto:tphan at paypal.com>> wrote:\n\nThanks Doug very much for your quick reply.\nRan your ruby check and no error in layout.yaml file.\n\nI also did check the syntax yaml file using zuul-server cmd:\n\n/usr/bin/python /usr/bin/zuul-server -c /etc/zuul/zuul.conf -l /etc/zuul/layout.yaml -t\n\nThe syntax is all ok.\n\nThe ERROR is a hint?\nERROR zuul.Gearman: Job <gear.Job 0x21b8f50 handle: None name: build:openstack-build-job unique: 51ea00c330c84cf9b40\nea38ad6c3f9e6> is not registered with Gearman\n\nThanks again, any inputs is much apprecicated.\n\nVan\n\n\nFrom: Doug Wiegley [mailto:dougw at a10networks.com]\nSent: Wednesday, October 01, 2014 4:59 PM\nTo: Phan, Van; openstack-infra at lists.openstack.org<mailto:openstack-infra at lists.openstack.org>\nSubject: Re: [OpenStack-Infra] desperate to get zuul works again, see layout setting at the end of email\n\nThis might not be your problem, but all of my silent zuul stoppages have been YAML syntax errors.  Try running this; if it?s prints something dictionary like, the syntax is fine.  If it throws an exception, the yaml file is wrong.\n\necho \"require \'yaml\'; z=YAML.load(File.open(\'/etc/zuul/layout.yaml\').read); print z\" | ruby\n\n\nFrom: <Phan>, Van <tphan at paypal.com<mailto:tphan at paypal.com>>\nDate: Wednesday, October 1, 2014 at 5:36 PM\nTo: \"openstack-infra at lists.openstack.org<mailto:openstack-infra at lists.openstack.org>\" <openstack-infra at lists.openstack.org<mailto:openstack-infra at lists.openstack.org>>\nSubject: [OpenStack-Infra] desperate to get zuul works again, see layout setting at the end of email\n\nHi,\nCould you please give me a hint how to fix the problem?\n\nWe had review/build/approve pipeline working well.\n\nSuddenly, all review requests got zuul reported back as LOST.  Restarted zuul/ Jenkins a few times and it still has GEARMAN reported ERROR?\n\n2014-10-01 22:53:37,631 ERROR zuul.Gearman: Job <gear.Job 0x7f5100010a90 handle: None name: build:openstack-review-job unique: 701cc4fa52c54\n462935bcaa276880b99> is not registered with Gearman\n2014-10-01 22:53:37,632 INFO zuul.Gearman: Build <gear.Job 0x7f5100010a90 handle: None name: build:openstack-review-job unique: 701cc4fa52c5\n4462935bcaa276880b99> complete, result LOST\nERROR zuul.Gearman: Job <gear.Job 0x21b8f50 handle: None name: build:openstack-build-job unique: 51ea00c330c84cf9b40\nea38ad6c3f9e6> is not registered with Gearman\n2014-10-01 22:53:37,633 INFO zuul.Gearman: Build <gear.Job 0x21b8f50 handle: None name: build:openstack-build-job unique: 51ea00c330c84cf9b4\n0ea38ad6c3f9e6> complete, result LOST\n\nHere are the errors in zuul log:\n\n2014-10-01 22:53:16,240 INFO zuul.Gerrit: Updating information for 2366,1\n2014-10-01 22:53:33,063 INFO zuul.Gerrit: Updating information for 2511,1\n2014-10-01 22:53:34,934 INFO zuul.Scheduler: Adding C3/keystone-plugins, <Change 0x1e742d0 2511,1> to <Pipeline review>\n2014-10-01 22:53:34,935 INFO zuul.IndependentPipelineManager: Troubleshooting addChange\n2014-10-01 22:53:34,935 INFO zuul.IndependentPipelineManager: Reporting start, action [<ActionReporter <zuul.reporter.gerrit.Reporter object\nat 0x21bbe90>, {\'code-review\': 0}>] change <Change 0x1e742d0 2511,1>\n2014-10-01 22:53:36,028 INFO zuul.Gerrit: Updating information for 2511,1\n2014-10-01 22:53:36,044 INFO zuul.IndependentPipelineManager: Change <Change 0x1e742d0 2511,1> depends on changes []\n2014-10-01 22:53:37,628 INFO zuul.IndependentPipelineManager: Change <Change 0x1e742d0 2511,1> depends on changes []\n2014-10-01 22:53:37,629 INFO zuul.Gearman: Launch job openstack-review-job for change <Change 0x1e742d0 2511,1> with dependent changes []\n2014-10-01 22:53:37,631 ERROR zuul.Gearman: Job <gear.Job 0x7f5100010a90 handle: None name: build:openstack-review-job unique: 701cc4fa52c54\n462935bcaa276880b99> is not registered with Gearman\n2014-10-01 22:53:37,632 INFO zuul.Gearman: Build <gear.Job 0x7f5100010a90 handle: None name: build:openstack-review-job unique: 701cc4fa52c5\n4462935bcaa276880b99> complete, result LOST\n2014-10-01 22:53:37,632 INFO zuul.Gearman: Launch job openstack-build-job for change <Change 0x1e742d0 2511,1> with dependent changes []\n2014-10-01 22:53:37,633 ERROR zuul.Gearman: Job <gear.Job 0x21b8f50 handle: None name: build:openstack-build-job unique: 51ea00c330c84cf9b40\nea38ad6c3f9e6> is not registered with Gearman\n2014-10-01 22:53:37,633 INFO zuul.Gearman: Build <gear.Job 0x21b8f50 handle: None name: build:openstack-build-job unique: 51ea00c330c84cf9b4\n0ea38ad6c3f9e6> complete, result LOST\n2014-10-01 22:53:37,634 INFO zuul.IndependentPipelineManager: Reporting change <Change 0x1e742d0 2511,1>, actions: [<ActionReporter <zuul.re\nporter.smtp.Reporter object at 0x21bbed0>, {\'to\': \'tphan at paypal.com<mailto:\'tphan at paypal.com>\', \'from\': \'cicdzuul at paypal.com<mailto:\'cicdzuul at paypal.com>\'}>, <ActionReporter <zuul.reporter.gerrit\n.Reporter object at 0x21bbe90>, {\'code-review\': -1}>]\n\nSample of project settings in layout.yaml:\n\nproject-templates:\n  - name: openstack-template\n    review:\n     - \'openstack-review-job\'\n     - \'openstack-build-job\'\n    approval:\n     - \'openstack-approval-job\'\nprojects:\n  - name: C3/nova-scheduler\n    template:\n     - name: openstack-template\n  - name: C3/keystone-plugins\n    template:\n     - name: openstack-template\n  - name: C3/nova\n    template:\n     - name: openstack-template\n\nThanks very much.\nVan\n_______________________________________________\nOpenStack-Infra mailing list\nOpenStack-Infra at lists.openstack.org<mailto:OpenStack-Infra at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20141002/50927e4b/attachment-0001.html>\n\n','<441396AFF01C5F47B293E43ECDF8650A03D479AA@PHX-EXRDA-S61.corp.ebay.com>',NULL),('<0cc00afd9d5363a15d94fb9b5dce5805@secure.spamaps.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-02 14:57:55',-25200,'2013-05-02 21:57:55',NULL,'[openstack-dev] Continuous deployment - significant process\n	change','On 2013-05-02 03:19, Thierry Carrez wrote:\n> Clint Byrum wrote:\n>> On 2013-05-01 02:46, Thierry Carrez wrote:\n>>> I think the root of the problem with shipping incomplete features\n>>> disabled by default is the stable maintenance expectations. Is that\n>>> incomplete feature considered a bug in the stable branch ?\n>> \n>> Definitely not. Those features are experimental, and intended for \n>> early\n>> adopters who are running trunk.\n>> \n>>> The code\n>>> might be disabled, it can still be enabled... Could we mark that \n>>> code in\n>>> a way that make it sufficiently clear it\'s not supported by the \n>>> stable\n>>> branch team ?\n>> \n>> We would definitely do well to keep a list of on-going experimental\n>> features.\n> \n> So, if a promised feature ends up not being \"completed\" by feature\n> freeze, your suggestion would be to keep it in as \"experimental\", or \n> to\n> remove it ?\n> \n\nKeep it.\n\n> I now think you mean the former, but in the case you mean the latter,\n> what do you think of my suggestion to only allow incremental feature\n> landing up until a given point in the release cycle (havana-2 ?) to \n> give\n> us extra time to remove the incomplete bits before release ?\n> \n\nThe removal would be all pain for almost no gain. In fact, I would \nthink that the stable maintenance team would appreciate that the code is \nmore like trunk when they have to backport patches in areas adjacent to \nexperimental code paths. The inverse is true too (if the experimental \nbit has been made the default, then they\'ll have more burden). But I \nthink we can expect this to be at worst a tie in terms of maintenance \nburden.\n\n>> Perhaps a call in oslo.config could be used to flag\n>> experimental things, and then one can produce a report at release \n>> freeze\n>> time to enumerate the flags which have been marked experimental. We\n>> could even go further and introduce a warning if one turns on any\n>> experimental features in a tagged release.\n> \n> FTR, I\'m not opposed to this as long as we somehow solve the user\n> expectations issue (\"bugs in experimental/incomplete features are to \n> be\n> expected and not fixed\"). But I don\'t think this policy can be \n> mandated,\n> it has to be accepted by PTLs and review teams in the various \n> projects.\n> For this to work, project people need to be convinced that it\'s the\n> right trade-off.\n> \n\nAgreed. Thats what we\'re doing here, trying to get everyone on board \nwith the idea.\n\n> Maybe one (convinced) project could play with that (in the same way\n> Keystone played with feature branches while working on v3) and push \n> some\n> features for marking parts of the code incomplete/experimental into \n> Oslo ?\n\nYes, oslo.config would be the place for an experimental config control \nfacility.\n\n\n','<51823DC8.4020800@openstack.org>',NULL),('<0CC0587B-4292-459B-93CB-2D02595ACB4F@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-01 11:55:43',-14400,'2013-07-01 15:55:43',NULL,'[openstack-qa] Refactoring Tempest service clients','\n\nOn Jul 1, 2013, at 11:45 AM, Daryl Walleck <daryl.walleck at RACKSPACE.COM> wrote:\n\n> Based on my previous experiences, I have to advocate the opposite. My quick bullet point list about language bindings:\n> 	? Are too helpful (re-tries, re-auth)\n> 	? Hide specifics about the response from the tester\n> 	? Stop the tester from manipulating a request in meaningful ways\n> 	? Block the tester from injecting useful logging/timing of requests etc\n> For simple, positive testing I can see the argument that language bindings provide a quick and dirty way to get started, but the downsides are too great for anything beyond basic smoke API testing.\n\nIf we are talking about doing this _properly_, it should be possible to generate bindings (both official and for testing) automatically from a machine-readable spec.  For all the negatives of something like WSDL, the alternative is surely worse.\n\n\nm. \n\n\n> Daryl\n> ________________________________________\n> From: Monty Taylor [mordred at inaugust.com]\n> Sent: Monday, July 01, 2013 9:15 AM\n> To: openstack-qa at lists.openstack.org\n> Subject: Re: [openstack-qa] Refactoring Tempest service clients\n> \n> \n> I think that if you do this, you will wind up implementing a parallel\n> set of client libraries.\n> \n> I\'m going to take this moment to advocate for just using the client\n> libraries in tempest instead of direct HTTP, btw. 2 reasons - one - what\n> Martina brings up - it\'s hard to write things with the direct HTTP. Two\n> - we have integration testing for real at this point, whereas we did not\n> have it when tempest was first written/designed. So the fact that the\n> client libs are part of the gate should mitigate that.\n> \n> But - as always- only my $0.02.\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C6954C9DF@ORD1EXD04.RACKSPACE.CORP>',NULL),('<0CC80A55-0068-4BBC-9C82-FD85A6525F43@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 09:11:14',-28800,'2013-11-07 17:11:14',NULL,'[openstack-dev] L3 advanced features blueprint mapping to IETF\n	and IEEE standards','Colin,\n\"The nice thing about standards is that there are so many of them to choose from.\"\n\nFor instance, if you take this Internet Draft:\nhttp://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on RFC4364.\n\nIt has already been implemented as a Neutron plugin via OpenContrail (http://juniper.github.io/contrail-vnc/README.html); With this implementation each OpenStack cluster can be configured as its own Autonomous System.\n\nThere is a blueprint\nhttps://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn\nthat is discussing adding the provisioning of the autonomous system and peering to Neutron.\n\nPlease note that the work above does interoperate with 4364 using option B. Option C is possible but not that practical (as an operator you probably don\'t want to expose your internal topology between clusters).\n\nIf you want to give it a try you can use this devstack fork: https://github.com/dsetia/devstack.\nYou can use it to interoperate with a standard router that implements 4364 and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.\n\nI believe that the work i\'m referencing implements interoperability while having very minimal changes to Neutron. It is based on the same concept of neutron virtual network and it hides the BGP/MPLS functionality from the user by translating policies that establish connectivity between virtual networks into RFC 4364 concepts.\nPlease refer to: https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n\nWould it make sense to have an IRC/Web meeting around interoperability with RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work that has already been done there by multiple vendors as well as some carriers.\n\n  Pedro.\n\nOn Nov 7, 2013, at 12:35 AM, Colin McNamara <colin at 2cups.com> wrote:\n> I have a couple concerns that I don?t feel I clearly communicated during the L3 advanced features session. I?d like to take this opportunity to both clearly communicate my thoughts, as well as start a discussion around them.\n> \n> Building to the edge of the \"autonomous system\"\n> The current state of neutron implementation is functionally the l2 domain and simple l3 services that are part of a larger autonomous system. The routers and switches northbound of the OpenStack networking layer handled the abstraction and integration of the components.\n> Note, I use the term ?Autonomous System? to describe more then the notion of BGP AS, but more broadly in the term of a system that is controlled within a common framework and methodology, and integrates with a peer system that doesn?t not share that same scope or method of control\n> These components that composed the autonomous system boundary implement protocols and standards that map into IETF and IEEE standards. The reasoning for this is interoperability. Before vendors utilize IETF for interoperability at this layer, the provider experience was horrible (this was my personal experience in the late 90?s).\n>  \n> Wednesdays discussions in the Neutron Design Sessions\n> A couple of the discussions, most notably the extension of l3 functionality fell within the scope of starting the process of extending Neutron with functionality that will result (eventually) in the ability for an OpenStack installation to operate as it?s own Autonomous System.\n> The discussions that occurred to support L3 advanced functionality (northbound boundary), and the QOS extension functionality both fell into the scope of Northbound and Southbound boundaries of this system.\n> My comments in the session\n> My comments in the session, while clouded with jet-lag were specifically around two concepts that are used when integrating other types of systems \n> 1. In a simple (1-8) tenant environment integration with a northbound AS is normally done in a PE-CE model that generally centers around mapping dot1q tags into the appropriate northbound l3 segments and then handling the availability of the L2 path that traverses with port channeling, MLAG, STP, Etc.\n> 2. In a complex environment (8+ for discussion) different Carrier Supporting Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are used. These allow the mapping of segregated tenant networks together and synchronizing between distributed systems. This normally extends the tagging or tunneling mechanism and then allows for BGP to synchronize NLRI information between AS?s.\n> These are the standard ways of integrating between carriers, but also components of these implementations are used to integrate and scale inside of a single web scale data center. Commonly when you scale beyond a certain physical port boundary (1000is edge ports in many implementations, much larger in current implementations) the same designs for C2C integrations are used to create network availability zones inside a web scale data center. \n> Support of these IETF and IEEE standard integrations are necessary for brown field installations\n> In a green field installation, diverging from IETF and IEEE standards on the north bound edge while not a great idea, can result in a functional implementation. In a brown field implementation where OpenStack Neutron will be integrated into an existing network core. This boundary layer is where we move from a controlled system into a distributed system. The cleanly integrate into this system, IETF and IEEE protocols and standards have to be followed. \n>  \n> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>When we diverge from this standards based integration at the north edge of our autonomous system we lose the ability to integrate without introducing major changes (and risk), into our core. In my experience this is sufficient to either slow or stall adoption. This is a major risk, that I believe can be mitigated.\n> My thoughts on mitigating this risk\n> We need to at least map and track the relevant IETF RFC?s that define the internet standards for integration at the AS boundary. I know that many of the network vendor developers that contribute to Neutron have access to people who both have deep knowledge of these standards, and also participate in the IETF working groups. I would hope that these resources could be leveraged to at least give a sanity check, at best ensure a compliant northbound interface to other systems.\n> Side benefit of engaging IETF members in this discussion\n> The other side benefit of this is that inventions inside of Neutron can also be communicated as standards to the rest of the world in the form of net new RFC?s. In OVS this has already happened, as OVS has emerged to be a common component in many network devices, and the need to establish and reference a common standard has risen it?s head. I would think that inventions within Neutron would follow this same path.\n> \n> Regards,\n> \n> Colin\n> \n> Colin McNamara\n> People | Process | Technology\n> --------------------------------------------\n> Mobile: 	858-208-8105\n> Twitter:	@colinmcnamara\n> Linkedin:	www.linkedin.com/colinmcnamara\n> Blog:	www.colinmcnamara.com\n> Email:	colin at 2cups.com	\n> \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/f3718bd8/attachment.html>\n\n','<9924F170-96AB-441C-AED8-71CA7816BCC0@2cups.com>',NULL),('<0CCE2F29-6B2A-4933-86C3-BCE1859D9D49@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-26 23:15:13',0,'2014-01-26 23:15:13',NULL,'[Openstack-docs] hypenation-pattern and image error message','No this is an ongoing problem. I think David Cramer knows how to fix!\n\nSent from my iPhone\n\nOn Jan 26, 2014, at 1:07 PM, \"Anne Gentle\" <anne at openstack.org<mailto:anne at openstack.org>> wrote:\n\nIs what you\'re seeing different from the bug we used to have, fixed in 1.9.4?\nhttps://bugs.launchpad.net/openstack-manuals/+bug/1193491\n\nCould be a new bug or could be a recurring old one, just wanted to double-check.\n\nCan you log a new bug with the tag doc-builds if it\'s new? There may be two, one for ImagePreloader and one for Hyphenator.\n\nI\'m also seeing an error that a Rackspace glossary.xml is not found, and I\'ll log a bug for that next time it happens and I can give more info.\nThanks,\nAnne\n\n\nOn Sun, Jan 26, 2014 at 12:42 PM, Andreas Jaeger <aj at suse.com<mailto:aj at suse.com>> wrote:\nLooking at the output of building openstack-manuals, I regularly see\nthese two:\n\nSEVERE: Image not available. URI: . Reason:\norg.apache.xmlgraphics.image.loader.ImageException: The file format is\nnot supported. No ImagePreloader found for  (See position 13:-1)\nJan 26, 2014 7:21:32 PM org.apache.fop.hyphenation.Hyphenator\ngetHyphenationTree\nSEVERE: Couldn\'t find hyphenation pattern en\n\nCan we fix those two somehow?\n\nAndreas\n--\n Andreas Jaeger aj@{suse.com<http://suse.com>,opensuse.org<http://opensuse.org>} Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140126/6aa928d6/attachment.html>\n\n','<CAD0KtVEw2XMPHk28L9Fis4tKfxmkWnyga8DU=VWeHy7fOjrE2A@mail.gmail.com>',NULL),('<0CD6529E-DC33-4726-B726-4421E1AC4413@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 07:42:44',-25200,'2013-05-07 14:42:44',NULL,'[openstack-dev] [openstack-tc] [Reddwarf] integration points as\n	per tc meeting','\nOn May 7, 2013, at 3:17 AM, Steven Hardy wrote:\n\n> On Mon, May 06, 2013 at 07:51:38AM -0700, Michael Basnight wrote:\n>> As mentioned, below is the wiki article ive written to discuss reddwarf heat interaction.\n>> \n>> https://wiki.openstack.org/wiki/ReddwarfUsingHeat\n> \n> Couple of comments/questions, I\'m referencing lines from the wiki page\n> below:\n> \n>> Heat is going through a refactor in the next cycle\n> \n> This is not true - the community have told us they want specific new\n> functionality, which we are aiming to provide, but we are not doing a full\n> refactor or rewrite - there will be incremental additions leading to new\n> features, probably including the ability for users to specify resource\n> definitions via templates, and probably initial support for an alternate\n> template syntax (the dsl discussion you mention)\n> \n> We will not be dropping support for our existing CFN-compatible template\n> format, and any changes made to our internal data-model will be incremental\n> to minimise the risk of regressions - ie we absolutely will maintain our\n> existing functionality.\n\nMakes sense.\n\n> \n>> heat installs guest, heat signals to task manager its finished\n>> guest takes over\n> \n> Can you clarify what \"guest takes over\" means - do you have a special\n> in-instance agent which handles securing the DB?\n> \n> I\'m interested in understanding why you see the initial\n> install/configuration (which can be handled by Heat) as a separate step\n> from the subsequent \"secures db\" step.\n\nYes our guest agent runs a set of queries, removes some databases, etc. This is different from editing the my.cnf. If heat can do all this, then thats one less thing the guest has to do. [1]\n\n[1] https://github.com/stackforge/reddwarf/blob/master/reddwarf/guestagent/manager/mysql.py#L753\n\n','<20130507101721.GD21384@t430slt.redhat.com>',NULL),('<0CD6529E-DC33-4726-B726-4421E1AC4413@gmail.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-07 07:42:44',-25200,'2013-05-07 14:42:44',NULL,'[openstack-tc] [Reddwarf] integration points as per tc meeting','\nOn May 7, 2013, at 3:17 AM, Steven Hardy wrote:\n\n> On Mon, May 06, 2013 at 07:51:38AM -0700, Michael Basnight wrote:\n>> As mentioned, below is the wiki article ive written to discuss reddwarf heat interaction.\n>> \n>> https://wiki.openstack.org/wiki/ReddwarfUsingHeat\n> \n> Couple of comments/questions, I\'m referencing lines from the wiki page\n> below:\n> \n>> Heat is going through a refactor in the next cycle\n> \n> This is not true - the community have told us they want specific new\n> functionality, which we are aiming to provide, but we are not doing a full\n> refactor or rewrite - there will be incremental additions leading to new\n> features, probably including the ability for users to specify resource\n> definitions via templates, and probably initial support for an alternate\n> template syntax (the dsl discussion you mention)\n> \n> We will not be dropping support for our existing CFN-compatible template\n> format, and any changes made to our internal data-model will be incremental\n> to minimise the risk of regressions - ie we absolutely will maintain our\n> existing functionality.\n\nMakes sense.\n\n> \n>> heat installs guest, heat signals to task manager its finished\n>> guest takes over\n> \n> Can you clarify what \"guest takes over\" means - do you have a special\n> in-instance agent which handles securing the DB?\n> \n> I\'m interested in understanding why you see the initial\n> install/configuration (which can be handled by Heat) as a separate step\n> from the subsequent \"secures db\" step.\n\nYes our guest agent runs a set of queries, removes some databases, etc. This is different from editing the my.cnf. If heat can do all this, then thats one less thing the guest has to do. [1]\n\n[1] https://github.com/stackforge/reddwarf/blob/master/reddwarf/guestagent/manager/mysql.py#L753\n\n','<20130507101721.GD21384@t430slt.redhat.com>',NULL),('<0CE1E362-76F0-43A1-B7F3-7D4FB9CCB5D8@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-13 17:12:49',0,'2015-01-13 17:12:49',NULL,'[openstack-dev] [barbican] Kilo Mid-Cycle Sprint','Hi openstack-dev!\n\nI just wanted to send a reminder that the Barbican mid-cycle Sprint will be taking place on February 16-18 in Austin, TX, which is just five weeks away.  There?ll be an overlap of a couple of days with the OSSG Mid-Cycle Sprint, which will hopefully give us a chance to collaborate remotely with the OSSG folks.  For more information and RSVP follow the link:\n\nhttps://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint\n\nThanks,\n-Douglas Mendiz?bal\n\n--------------------\nDouglas Mendiz?bal\nIRC: redrobot\nPGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150113/57173cbb/attachment.html>\n\n',NULL,NULL),('<0CE97C0D-267F-4C51-B298-CA6741D6BF76@pistoncloud.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-17 10:08:46',-25200,'2013-09-17 17:08:46',NULL,'[Openstack] Making the Hong Kong Summit as inclusive as possible','David - yes, the ombudsperson office is one of the goals of the Transparency Committee, and we\'ve got an agenda item to dig into again at the next board meeting.\n--\n\nJoshua McKenty\nChief Technology Officer\nPiston Cloud Computing, Inc.\n+1 (650) 242-5683\n+1 (650) 283-6846\nhttp://www.pistoncloud.com\n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\nOn Sep 15, 2013, at 5:18 PM, David Mortman <launchpad at mortman.com> wrote:\n\n> Joshua,\n> \n> I\'ll leave it up to the event staff to determine how they want to handle it in this on-site case. Certainly someone needs to be empowered or the exercise is pointless. For the community as a whole, does the Board of Directors have the authority to create an ombuds office?\n> \n> -DM\n> \n> \n> On Sun, Sep 15, 2013 at 12:44 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:\n> David, while I think having an onsite group able to field complaints and address incidents is critical, we need to make sure that such a group has the ability to address any complaints. So I\'d suggest we pass this directly to the foundation staff, and make sure that the event coordination team is coached appropriately. Having community members act as ombudsperson is both complicated from a legal standpoint, and potentially inappropriate.\n> \n> Lauren, can you make sure the on-site events team is briefed on the proposed code-of-conduct, and is ready to respond to any complaints that might arise?\n> \n> --\n> \n> Joshua McKenty\n> Chief Technology Officer\n> Piston Cloud Computing, Inc.\n> +1 (650) 242-5683\n> +1 (650) 283-6846\n> http://www.pistoncloud.com\n> \n> \"Oh, Westley, we\'ll never survive!\"\n> \"Nonsense. You\'re only saying that because no one ever has.\"\n> \n> On Sep 15, 2013, at 3:59 AM, David Mortman <launchpad at mortman.com> wrote:\n> \n>> On Thu, Sep 12, 2013 at 4:26 PM, David Mortman <launchpad at mortman.com> wrote:\n>>  Agreed. There should be at least a small group, especially for events, so that one person doesn\'t get hammered but also so there\'s a committee to make judgement calls etc. Love the idea of some training too.\n>> \n>> Given the closeness of the summit (only 2 months away), it\'s seems like a good idea to put together the initial group of folks who can be the onsite committee to help address any issues that hopefully won\'t arise. While I\'ll continue to participate in this effort, unfortunately, I won\'t be attending the summit myself so I can\'t help onsite. I will however like  nominate both Anne Gentle and George Reese be initial members of the committee. Anyone else interested? A group of three is probably plenty.\n>> \n>> thanks\n>> -David\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130917/6bd82cac/attachment.html>\n\n','<CAPDpzpMowOTfDqioOMuyicVPM5meHq07ik+f_Bg8LLXCoeo_6g@mail.gmail.com>',NULL),('<0d10c09ababe31cae35bc8939067d6d5@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-23 10:26:14',-21600,'2013-12-23 16:26:14',NULL,'[openstack-dev] Fwd: [openstack-community] A bug on OpenStack',' \n\nThis sounds more appropriate for the openstack list:\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\nIt\'s not clear to me at this point whether this is a bug or a\nmisconfiguration, and the configuration discussion should happen there. \n\nThanks. \n\n-Ben \n\nOn 2013-12-22 12:26, Sean Roberts wrote: \n\n> I\'ve reposted your query below to openstack-dev for a greater pool of eyeballs. \n> \n> ~sean \n> \n> Begin forwarded message:\n> \n>> FROM: ?? ?? <hisayuki.takeda at oceanearth-corp.com>\n>> DATE: December 22, 2013 at 6:17:28 PST\n>> TO: <community at lists.openstack.org>\n>> SUBJECT: [OPENSTACK-COMMUNITY] A BUG ON OPENSTACK\n> \n>> Hi OpenStack experts, \n>> \n>> Could you please, help me out on this? I need your experts advice. \n>> \n>> I am trying to build VlanManager environment with OpenStack grizzly on Cent OS 6.4, but it doesn\'t work. \n>> \n>> I am using all-in-one architecture (single-host). FlatDHCPManager successfully worked. \n>> \n>> So, I am assuming that there is any bug/defect that VlanManager can\'t work with single-host architecture. \n>> \n>> Does anyone know if there is such a bug related to VlanManager on single-host architecture? \n>> \n>> Any pointer or letting me know anyone who is familiar with this would be highly appreciated. \n>> \n>> Thank you so much in advance, \n>> \n>> Bird Kafka\n> \n>> _______________________________________________\n>> Community mailing list\n>> Community at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/community [1]\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]\n\n \n\nLinks:\n------\n[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131223/ae9fa3fc/attachment.html>\n\n','<D451DF50-6DC9-462D-955B-CD099111327A@yahoo-inc.com>',NULL),('<0D1B0C62A4A3BC4181D065E1AB698BAC2B60D7415C@EXCH-CMS.hlit.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-29 21:26:20',-25200,'2014-06-30 04:26:20',NULL,'[openstack-dev] [nova][baremetal] Scheduling baremetal deployment\n on different hw model','Hi,\n\nI am working on deploying images to bare-metal machines using nova bare-metal. My datacenter has 2 types of hw models, IBM and Dell. In existing implementation, if I want to deploy image on specified type of hw model, I need to setup 2 baremetal compute nodes, one for container of IBM machine, the other for Dell machine. Then baremetal register machines to their corresponding compute node. Finally use nova flavor and heterogeneous group to map specified compute node so I can explicitly specify the hw model to deploy, as illustrated as following flow chart:\n\nFlavor_IBM -> (mapping by flavor extra_spec) -> Heterogeneous_Group_IBM -> Compute_Node_IBM -> IBM machines\nFlavor_Dell -> (mapping by flavor extra_spec) -> Heterogeneous_Group_Dell -> Compute_Node_Dell -> Dell machines\n\nThe existing approach has a drawback: I need to setup 1 baremetal compute node for each hw model. If I have 10 hw models in my datacenter, I need to setup 10 baremetal compute node, which would be a high overhead. Is there any update in ironic to tackle this?\n\nI think one of the possible enhancement is adding a field like hw_model in nova.bm_nodes DB and passing to nova scheduler, so different hw models of machine can under the same baremetal compute node and heterogeneous group. Just using different extra_spec in nova flavor to specifiy hw_model. Is it a good idea?\n\nRegards,\nTaurus\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140629/be4bb518/attachment.html>\n\n',NULL,NULL),('<0D1B0C62A4A3BC4181D065E1AB698BAC2B60D74163@EXCH-CMS.hlit.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-29 22:18:56',-25200,'2014-06-30 05:18:56',NULL,'[openstack-dev] [nova][baremetal] Scheduling baremetal\n deployment on different hw model','Hi Rob,\n\nThanks your reply.\n\nAs I know, Ironic not yet \"graduate\". It is still under rapid development as replied by Chris Krelle in Feb-2014: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026647.html . Or I should change to Ironic now?\n\nNo - I am not group IBM and Dell machines together. They are under the same datacenter and I want to provision them under a single OpenStack controller, which I think a very common use case. What I want to do is to choose specified hw model (IBM or Dell) when I deploy image in baremetal style.\n\nRegards,\nTaurus\n\n-----Original Message-----\nFrom: Robert Collins [mailto:robertc at robertcollins.net] \nSent: Monday, June 30, 2014 12:46 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Taurus Cheung\nSubject: Re: [openstack-dev] [nova][baremetal] Scheduling baremetal deployment on different hw model\n\nFirstly, use Ironic. Nova BM is deprecated.\n\nSecondly, yes, you can use extra-specs, but you only need to do that if your machines are identical in CPU, disk and memory - which the scheduler will look at anyway. Why do you need to group IBM and Dell machines together?\n\n\n\n-Rob\n\nOn 30 June 2014 16:26, Taurus Cheung <Taurus.Cheung at harmonicinc.com> wrote:\n> Hi,\n>\n>\n>\n> I am working on deploying images to bare-metal machines using nova \n> bare-metal. My datacenter has 2 types of hw models, IBM and Dell. In \n> existing implementation, if I want to deploy image on specified type \n> of hw model, I need to setup 2 baremetal compute nodes, one for \n> container of IBM machine, the other for Dell machine. Then baremetal \n> register machines to their corresponding compute node. Finally use \n> nova flavor and heterogeneous group to map specified compute node so I \n> can explicitly specify the hw model to deploy, as illustrated as following flow chart:\n>\n>\n>\n> Flavor_IBM -> (mapping by flavor extra_spec) -> \n> Heterogeneous_Group_IBM -> Compute_Node_IBM -> IBM machines\n>\n> Flavor_Dell -> (mapping by flavor extra_spec) -> \n> Heterogeneous_Group_Dell -> Compute_Node_Dell -> Dell machines\n>\n>\n>\n> The existing approach has a drawback: I need to setup 1 baremetal \n> compute node for each hw model. If I have 10 hw models in my \n> datacenter, I need to setup 10 baremetal compute node, which would be \n> a high overhead. Is there any update in ironic to tackle this?\n>\n>\n>\n> I think one of the possible enhancement is adding a field like \n> hw_model in nova.bm_nodes DB and passing to nova scheduler, so \n> different hw models of machine can under the same baremetal compute node and heterogeneous group.\n> Just using different extra_spec in nova flavor to specifiy hw_model. \n> Is it a good idea?\n>\n>\n>\n> Regards,\n>\n> Taurus\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n--\nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n','<CAJ3HoZ1ogqqFVYL6HVUtcN7dyBBwA6hKAbQfjS7ceR3RnZ7bmw@mail.gmail.com>',NULL),('<0D1B0C62A4A3BC4181D065E1AB698BAC2B60D7416E@EXCH-CMS.hlit.local>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-29 23:40:53',-25200,'2014-06-30 06:40:53',NULL,'[Openstack-operators] [nova][baremetal] Is it proper to deploy\n hybrid KVM + baremetal instances under a single OpenStack controller','Hi,\n\nIn my datacenter, I have some application use case that requires both VM and baremetal instances. So I have setup KVM compute nodes and baremetal compute nodes under a single OpenStack controller. As a result, by using a single Heat template, with corresponding nova flavor for instances, I can have a single Heat stack that is mix of KVM VM and baremetal instances.\n\nI would like to verify whether it is a proper use case to deploy hybrid KVM + baremetal instances under a single OpenStack controller? Any example setup that is similar with what I am doing? Thanks.\n\nRegards,\nTaurus\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140629/41e906f9/attachment.html>\n\n',NULL,NULL),('<0D21E5E2-2629-49BA-9F53-755C6850D938@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 11:04:09',-25200,'2013-06-26 18:04:09',NULL,'[openstack-dev] [Nova] Nominating John Garbutt for nova-core','+1\nOn Jun 26, 2013, at 8:09 AM, Russell Bryant <rbryant at redhat.com> wrote:\n\n> Greetings,\n> \n> I would like to nominate John Garbutt for the nova-core team.\n> \n> John has been involved with nova for a long time now.  He\'s primarily\n> known for his great work on the xenapi driver.  However, he has been\n> contributing and reviewing in other areas, as well.  Based on my\n> experience with him I think he would be a good addition, so it would be\n> great to have him on board to help keep up with the review load.\n> \n> Please respond with +1s or any concerns.\n> \n> References:\n> \n>  https://review.openstack.org/#/dashboard/782\n> \n>  https://review.openstack.org/#/q/reviewer:782,n,z\n> \n>  https://launchpad.net/~johngarbutt/+specs?role=assignee\n> \n>  https://launchpad.net/~johngarbutt/+bugs?role=assignee\n> \n> Thanks,\n> \n> -- \n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<51CB042E.5080802@redhat.com>',NULL),('<0D23360A-F51D-496A-BE50-3C600C1C2EC3@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 15:11:32',-18000,'2015-01-29 20:11:32',NULL,'[openstack-dev] [all][tc] SQL Schema Downgrades and Related\n	Issues','\n\nMorgan Fainberg <morgan.fainberg at gmail.com> wrote:\n\n> \n> Are downward migrations really a good idea for us to support? Is this downward migration path a sane expectation? In the real world, would any one really trust the data after migrating downwards?\n\nIt?s a good idea for a migration script to include a rudimentary downgrade operation to complement the upgrade operation, if feasible.  The purpose of this downgrade is from a practical standpoint helpful when locally testing a specific, typically small series of migrations.\n\nA downgrade however typically only applies to schema objects, and not so much data.   It is often impossible to provide downgrades of data changes as it is likely that a data upgrade operation was destructive of some data.  Therefore, when dealing with a full series of real world migrations that include data migrations within them, downgrades are typically impossible.   I?m getting the impression that our migration scripts have data migrations galore in them.   \n\nSo I am +1 on establishing a policy that the deployer of the application would not have access to any ?downgrade? migrations, and -1 on removing ?downgrade? entirely from individual migrations.   Specific migration scripts may return NotImplemented for their downgrade if its really not feasible, but for things like table and column changes where autogenerate has already rendered the downgrade, it?s handy to keep at least the smaller ones working.\n\n\n\n\n\n\n','<B6AC25D8-E41E-4D8E-A126-29EF983207A4@gmail.com>',NULL),('<0D27624F-DFE6-4CB4-B37C-E4EE46BF17B6@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 12:00:39',-14400,'2014-09-08 16:00:39',NULL,'[openstack-dev] Kilo Cycle Goals Exercise','\nOn Sep 8, 2014, at 11:30 AM, Anita Kuno <anteaya at anteaya.info> wrote:\n\n> Wow, we are really taking liberties with my question today.\n> \n> What part of any of my actions current or previous have led you to\n> believe that I want to now or ever have silenced anyone? I am curious\n> what led you to believe that silencing users was the motivation for my\n> question of Angus.\n\nI was only replying to your single message in isolation of the full conversation; the notion that one would not want to send traffic to a blog because they disagree with it, at face value seems like a bad idea.  Apparently that isn?t the meaning you wished to convey, so I apologize for missing the larger context.\n\n\n\n\n\n','<540DCBA2.6090805@anteaya.info>',NULL),('<0d2fba0cdd4b479fb31aec05a4b0d429@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-17 11:13:45',0,'2014-01-17 11:13:45',NULL,'[Openstack] [Neutron] ML2 Mechanism driver unit Testing Failed','Hi Stackers-\n\nI have written an mechanism driver and an unit test case to it.\n\nWith I run the Unit test case with \'tox\', I get the following Error.\n\nroot at havana:~/neutron_icehouse/neutron-2014.1.b1# tox -epy27 neutron.tests.unit.ml2.drivers.test_fslsdn_mech.TestFslSdnMechanismDriver.test_create_network_postcommit\nGLOB sdist-make: /root/neutron_icehouse/neutron-2014.1.b1/setup.py\npy27 create: /root/neutron_icehouse/neutron-2014.1.b1/.tox/py27\nERROR: invocation failed, logfile: /root/neutron_icehouse/neutron-2014.1.b1/.tox/py27/log/py27-0.log\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[\'/usr/bin/python2.7\', \'/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\', \'--setuptools\', \'--python\', \'/usr/bin/python2.7\', \'py27\']\nenv={\'LESSOPEN\': \'| /usr/bin/lesspipe %s\', \'SSH_CLIENT\': \'10.232.85.40 54873 22\', \'LOGNAME\': \'root\', \'USER\': \'root\', \'PATH\': \'/root/neutron_icehouse/neutron-2014.1.b1/.tox/py27/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HOME\': \'/root\', \'LANG\': \'en_US.UTF-8\', \'TERM\': \'xterm\', \'SHELL\': \'/bin/bash\', \'SHLVL\': \'1\', \'PWD\': \'/root/neutron_icehouse/neutron-2014.1.b1\', \'OS_USERNAME\': \'admin\', \'VIRTUAL_ENV\': \'/root/neutron_icehouse/neutron-2014.1.b1/.tox/py27\', \'OS_TENANT_NAME\': \'admin\', \'OS_PASSWORD\': \'password\', \'_\': \'/usr/local/bin/tox\', \'SSH_CONNECTION\': \'10.232.85.40 54873 10.232.91.84 22\', \'LESSCLOSE\': \'/usr/bin/lesspipe %s %s\', \'SSH_TTY\': \'/dev/pts/31\', \'OLDPWD\': \'/root/neutron_icehouse\', \'OS_AUTH_URL\': \'http://10.10.10.100:35357/v2.0\', \'MAIL\': \'/var/mail/root\', \'LS_COLORS\': \'rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:\'}\nAlready using interpreter /usr/bin/python2.7\nNew python executable in py27/bin/python2.7\nAlso creating executable in py27/bin/python\nInstalling setuptools, pip...\n  Complete output from command /root/neutron_icehou...x/py27/bin/python2.7 -c \"import sys, pip; pip...ll\\\"] + sys.argv[1:])\" setuptools pip:\n  Traceback (most recent call last):\n  File \"<string>\", line 1, in <module>\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/__init__.py\", line 9, in <module>\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/pip-1.5-py2.py3-none-any.whl/pip/log.py\", line 8, in <module>\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 2696, in <module>\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 429, in __init__\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 443, in add_entry\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 1722, in find_in_zip\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 1298, in has_metadata\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 1614, in _has\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/pkg_resources.py\", line 1488, in _zipinfo_name\nAssertionError: /usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/EGG-INFO/PKG-INFO is not a subpath of /usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv_support/setuptools-2.0.2-py2.py3-none-any.whl/\n----------------------------------------\n...Installing setuptools, pip...done.\nTraceback (most recent call last):\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\", line 2334, in <module>\n    main()\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\", line 820, in main\n    symlink=options.symlink)\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\", line 988, in create_environment\n    install_wheel(to_install, py_executable, search_dirs)\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\", line 956, in install_wheel\n    \'PIP_NO_INDEX\': \'1\'\n  File \"/usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py\", line 898, in call_subprocess\n    % (cmd_desc, proc.returncode))\nOSError: Command /root/neutron_icehou...x/py27/bin/python2.7 -c \"import sys, pip; pip...ll\\\"] + sys.argv[1:])\" setuptools pip failed with error code 1\n\nERROR: InvocationError: /usr/bin/python2.7 /usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py --setuptools --python /usr/bin/python2.7 py27 (see /root/neutron_icehouse/neutron-2014.1.b1/.tox/py27/log/py27-0.log)\n__________________________________________________________ summary __________________________________________________________\nERROR:   py27: InvocationError: /usr/bin/python2.7 /usr/local/lib/python2.7/dist-packages/virtualenv-1.11-py2.7.egg/virtualenv.py --setuptools --python /usr/bin/python2.7 py27 (see /root/neutron_icehouse/neutron-2014.1.b1/.tox/py27/log/py27-0.log)\n\n\n\nKindly help me trouble shoot the issue.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140117/488a39e9/attachment.html>\n\n',NULL,NULL),('<0D334089-BCF3-4E36-8219-5DC6A1EB5F74@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 15:40:43',-14400,'2014-08-28 19:40:43',NULL,'[openstack-dev] [all] gate debugging','\nOn Aug 28, 2014, at 2:15 PM, Sean Dague <sean at dague.net> wrote:\n\n> On 08/28/2014 01:48 PM, Doug Hellmann wrote:\n>> \n>> On Aug 28, 2014, at 1:17 PM, Sean Dague <sean at dague.net> wrote:\n>> \n>>> On 08/28/2014 12:48 PM, Doug Hellmann wrote:\n>>>> \n>>>> On Aug 27, 2014, at 5:56 PM, Sean Dague <sean at dague.net> wrote:\n>>>> \n>>>>> On 08/27/2014 05:27 PM, Doug Hellmann wrote:\n>>>>>> \n>>>>>> On Aug 27, 2014, at 2:54 PM, Sean Dague <sean at dague.net> wrote:\n>>>>>> \n>>>>>>> Note: thread intentionally broken, this is really a different topic.\n>>>>>>> \n>>>>>>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:>\n>>>>>>>> On Aug 27, 2014, at 1:30 PM, Chris Dent <chdent at redhat.com> wrote:\n>>>>>>>> \n>>>>>>>>> On Wed, 27 Aug 2014, Doug Hellmann wrote:\n>>>>>>>>> \n>>>>>>>>>> I have found it immensely helpful, for example, to have a written set\n>>>>>>>>>> of the steps involved in creating a new library, from importing the\n>>>>>>>>>> git repo all the way through to making it available to other projects.\n>>>>>>>>>> Without those instructions, it would have been much harder to split up\n>>>>>>>>>> the work. The team would have had to train each other by word of\n>>>>>>>>>> mouth, and we would have had constant issues with inconsistent\n>>>>>>>>>> approaches triggering different failures. The time we spent building\n>>>>>>>>>> and verifying the instructions has paid off to the extent that we even\n>>>>>>>>>> had one developer not on the core team handle a graduation for us.\n>>>>>>>>> \n>>>>>>>>> +many more for the relatively simple act of just writing stuff down\n>>>>>>>> \n>>>>>>>> \"Write it down.? is my theme for Kilo.\n>>>>>>> \n>>>>>>> I definitely get the sentiment. \"Write it down\" is also hard when you\n>>>>>>> are talking about things that do change around quite a bit. OpenStack as\n>>>>>>> a whole sees 250 - 500 changes a week, so the interaction pattern moves\n>>>>>>> around enough that it\'s really easy to have *very* stale information\n>>>>>>> written down. Stale information is even more dangerous than no\n>>>>>>> information some times, as it takes people down very wrong paths.\n>>>>>>> \n>>>>>>> I think we break down on communication when we get into a conversation\n>>>>>>> of \"I want to learn gate debugging\" because I don\'t quite know what that\n>>>>>>> means, or where the starting point of understanding is. So those\n>>>>>>> intentions are well meaning, but tend to stall. The reality was there\n>>>>>>> was no road map for those of us that dive in, it\'s just understanding\n>>>>>>> how OpenStack holds together as a whole and where some of the high risk\n>>>>>>> parts are. And a lot of that comes with days staring at code and logs\n>>>>>>> until patterns emerge.\n>>>>>>> \n>>>>>>> Maybe if we can get smaller more targeted questions, we can help folks\n>>>>>>> better? I\'m personally a big fan of answering the targeted questions\n>>>>>>> because then I also know that the time spent exposing that information\n>>>>>>> was directly useful.\n>>>>>>> \n>>>>>>> I\'m more than happy to mentor folks. But I just end up finding the \"I\n>>>>>>> want to learn\" at the generic level something that\'s hard to grasp onto\n>>>>>>> or figure out how we turn it into action. I\'d love to hear more ideas\n>>>>>>> from folks about ways we might do that better.\n>>>>>> \n>>>>>> You and a few others have developed an expertise in this important skill. I am so far away from that level of expertise that I don?t know the questions to ask. More often than not I start with the console log, find something that looks significant, spend an hour or so tracking it down, and then have someone tell me that it is a red herring and the issue is really some other thing that they figured out very quickly by looking at a file I never got to.\n>>>>>> \n>>>>>> I guess what I?m looking for is some help with the patterns. What made you think to look in one log file versus another? Some of these jobs save a zillion little files, which ones are actually useful? What tools are you using to correlate log entries across all of those files? Are you doing it by hand? Is logstash useful for that, or is that more useful for finding multiple occurrences of the same issue?\n>>>>>> \n>>>>>> I realize there?s not a way to write a how-to that will live forever. Maybe one way to deal with that is to write up the research done on bugs soon after they are solved, and publish that to the mailing list. Even the retrospective view is useful because we can all learn from it without having to live through it. The mailing list is a fairly ephemeral medium, and something very old in the archives is understood to have a good chance of being out of date so we don?t have to keep adding disclaimers.\n>>>>> \n>>>>> Sure. Matt\'s actually working up a blog post describing the thing he\n>>>>> nailed earlier in the week.\n>>>> \n>>>> Yes, I appreciate that both of you are responding to my questions. :-)\n>>>> \n>>>> I have some more specific questions/comments below. Please take all of this in the spirit of trying to make this process easier by pointing out where I?ve found it hard, and not just me complaining. I?d like to work on fixing any of these things that can be fixed, by writing or reviewing patches for early in kilo.\n>>>> \n>>>>> \n>>>>> Here is my off the cuff set of guidelines:\n>>>>> \n>>>>> #1 - is it a test failure or a setup failure\n>>>>> \n>>>>> This should be pretty easy to figure out. Test failures come at the end\n>>>>> of console log and say that tests failed (after you see a bunch of\n>>>>> passing tempest tests).\n>>>>> \n>>>>> Always start at *the end* of files and work backwards.\n>>>> \n>>>> That?s interesting because in my case I saw a lot of failures after the initial ?real? problem. So I usually read the logs like C compiler output: Assume the first error is real, and the others might have been caused by that one. Do you work from the bottom up to a point where you don?t see any more errors instead of reading top down?\n>>> \n>>> Bottom up to get to problems, then figure out if it\'s in a subprocess so\n>>> the problems could exist for a while. That being said, not all tools do\n>>> useful things like actually error when they fail (I\'m looking at you\n>>> yum....) so there are always edge cases here.\n>>> \n>>>>> \n>>>>> #2 - if it\'s a test failure, what API call was unsuccessful.\n>>>>> \n>>>>> Start with looking at the API logs for the service at the top level, and\n>>>>> see if there is a simple traceback at the right timestamp. If not,\n>>>>> figure out what that API call was calling out to, again look at the\n>>>>> simple cases assuming failures will create ERRORS or TRACES (though they\n>>>>> often don\'t).\n>>>> \n>>>> In my case, a neutron call failed. Most of the other services seem to have a *-api.log file, but neutron doesn?t. It took a little while to find the API-related messages in screen-q-svc.txt (I?m glad I?ve been around long enough to know it used to be called ?quantum?). I get that screen-n-*.txt would collide with nova. Is it necessary to abbreviate those filenames at all?\n>>> \n>>> Yeh... service naming could definitely be better, especially with\n>>> neutron. There are implications for long names in screen, but maybe we\n>>> just get over it as we already have too many tabs to be in one page in\n>>> the console anymore anyway.\n>>> \n>>>>> Hints on the service log order you should go after are on the footer\n>>>>> over every log page -\n>>>>> http://logs.openstack.org/76/79776/15/gate/gate-tempest-dsvm-full/700ee7e/logs/\n>>>>> (it\'s included as an Apache footer) for some services. It\'s been there\n>>>>> for about 18 months, I think people are fully blind to it at this point.\n>>>> \n>>>> Where would I go to edit that footer to add information about the neutron log files? Is that Apache footer defined in an infra repo?\n>>> \n>>> Note the following at the end of the footer output:\n>>> \n>>> About this Help\n>>> \n>>> This help file is part of the openstack-infra/config project, and can be\n>>> found at modules/openstack_project/files/logs/help/tempest_logs.html .\n>>> The file can be updated via the standard OpenStack Gerrit Review process.\n>> \n>> /me smacks forehead\n> \n> :)\n> \n> Also note an early version of this base email is at the top level for\n> all runs - (i.e. -\n> http://logs.openstack.org/76/79776/15/gate/gate-tempest-dsvm-full/700ee7e/)\n> \n> It\'s been there about 18 months. People look right past it. Which is\n> part of where my skepticism on just writing things down being the\n> solution. Because a bunch of it has been written down. But until people\n> are in a mode of pulling the information in, pushing it out doesn\'t help.\n\nFair enough.\n\n> \n>>>> Another specific issue I?ve seen is a message that says something to the effect ?the setup for this job failed, check the appropriate log?. I found 2 files with ?setup? in the name, but the failure was actually logged in a different file (devstacklog.txt). Is the job definition too far ?removed? from the scripts to know what the real filename is? Is it running scripts that log to multiple files during the setup phase, and so it doesn?t know which to refer me to? Or maybe I overlooked a message about when logging to a specific file started.\n>>> \n>>> Part of the issue here is that devstack-gate runs a lot of different\n>>> gate_hooks. So that\'s about as specific as we can get unless you can\n>>> figure out how to introspect that info in bash... which I couldn?t.\n>> \n>> Are all of the hooks logging to the same file? If not, why not? Would it make sense to change that so the error messages could be more specific?\n> \n> They are not, output direction is actually typically a function of the\n> hook script and not devstack gate.\n> \n> Some of this is because the tools when run locally need to be able to\n> natively support logging. Some of this is because processing logs into\n> elastic search requires that we know we understand the log format (a\n> generic gate_hook log wouldn\'t work well there). Some of it is historical.\n\nOK, that makes sense.\n\n> \n> I did spend a bunch of time cleaning up the grenade summary log so in\n> the console you get some basic idea of what\'s going on, and what part\n> you failed in. Definitely could be better. Taking some of those summary\n> lessons into devstack wouldn\'t hurt either.\n\nI don\'t think I\'ve hit a grenade issue, so I haven?t seen that.\n\n> \n> So patches here are definitely accepted. Which is very much not a blow\n> off, but in cleaning d-g up over the last 6 months ?the setup for this\n\nYep, I?m asking if I?m even thinking in the right directions, and that sounds like a ?yes? rather than a blow off.\n\n> job failed, check the appropriate log? was about as good as we could\n> figure out. Previously the script just died and people usually blamed an\n> error message about uploading artifacts in the jenkins output for the\n> failure. So if you can figure out a better UX given the constraints\n> we\'re in, definitely appreciated.\n\nI?ll look at the job definitions and see if I can come up with a way to parameterize them or automate the step of figuring out which file is meant for each phase.\n\n> \n>>>>> If nothing jumps out at ERROR or TRACE, go back to DEBUG level and\n>>>>> figure out what\'s happening at the time of failure, especially keeping\n>>>>> an eye out of areas where other workers are doing interesting things at\n>>>>> the same time, possibly indicating state corruption in OpenStack as a race.\n>>>>> \n>>>>> #3 - if it\'s a console failure, start at the end and work backwards\n>>>>> \n>>>>> devstack and grenade run under set -o errexit so that they will\n>>>>> critically exit if a command fails. They will typically dump some debug\n>>>>> when they do that. So the failing command won\'t be the last line in the\n>>>>> file, but it will be close. The words \'error\' typically aren\'t useful at\n>>>>> all in shell because lots of things say error when they aren\'t, we mask\n>>>>> their exit codes if their failure is generally irrelevant.\n>>>>> \n>>>>> #4 - general principle the closer to root cause the better\n>>>>> \n>>>>> If we think of exposure of bugs as layers we probably end up\n>>>>> withsomething like this\n>>>>> \n>>>>> - Console log\n>>>>> - Test Name + Failure\n>>>>> - Failure inside an API service\n>>>>> - Failure inside a worker process\n>>>>> - Actual failure figured out in OpenStack code path\n>>>>> - Failure in something below OpenStack (kernel, libvirt)\n>>>>> \n>>>>> This is why signatures that are just test names aren\'t all that useful\n>>>>> much of the time (and why we try not to add those to ER), as that\'s\n>>>>> going to be hitting an API, but the why of things is very much still\n>>>>> undiscovered.\n>>>>> \n>>>>> #5 - if it\'s an infrastructure level setup bug (failing to download or\n>>>>> install something) figure out if there are other likewise events at the\n>>>>> same time (i.e. it\'s a network issue, which we can\'t fix) vs. a\n>>>>> structural issue.\n>>>>> \n>>>>> \n>>>>> I find Elastic Search good for step 5, but realistically for all other\n>>>>> steps it\'s manual log sifting. I open lots of tabs in Chrome, and search\n>>>>> by timestamp.\n>>>> \n>>>> This feels like something we could improve on. If we had a tool to download the logs and interleave the messages using their timestamps, would that make it easier? We could probably make the job log everything to a single file, but I can see where sometimes only having part of the data to look at would be more useful.\n>>> \n>>> Maybe, I find the ability to change the filtering level dynamically to\n>>> be pretty important. We actually did some of this once when we used\n>>> syslog. Personally I found it a ton harder to get to the bottom of things.\n>>> \n>>> A gate run has 25+ services running, it\'s a rare issue that combines\n>>> interactions between > 4 of them to get to a solution. So I expect you\'d\n>>> exchange context jumping, for tons of irrelevancy. That\'s a personal\n>>> opinion based on personal workflow, and why I never spent time on it.\n>>> Instead I built os-loganalyze that does the filtering and coloring\n>>> dynamically on the server side, as it was a zero install solution that\n>>> provided additional benefits of being able to link to a timestamp in a\n>>> log for sharing purposes.\n>> \n>> Sure, that makes sense.\n>> \n>>> \n>>>> \n>>>>> \n>>>>> \n>>>>> A big part of the experience also just comes from a manual bayesian\n>>>>> filter. Certain scary looking things in the console log aren\'t, but you\n>>>>> don\'t know that unless you look at setup logs enough (either in gate or\n>>>>> in your own devstacks) to realize that. Sanitizing the output of that\n>>>>> part of the process is pretty intractable... because shell (though I\'ve\n>>>>> put some serious effort into it over the last 6 months).\n>>>> \n>>>> Maybe our scripts can emit messages to explain the scary stuff? ?This is going to report a problem, but you can ignore it unless X happens.??\n>>> \n>>> Maybe, like I said it\'s a lot better than it used to be. But very few\n>>> people are putting in effort here, and I\'m not convinced it\'s really\n>>> solveable in bash.\n>> \n>> OK, well, if the answers to these questions are ?yes? then I should have time to help, which is why I?m exploring options.\n> \n> Yeh, the issue is you\'d need a couple hundred different messages like\n> that, and realistically I think they\'d lead to more confusion rather\n> than less.\n> \n> Honestly, I did a huge amount of selective filtering out of xtrace logs\n> in the last six months and was able to drop the size of the devstack\n> logs by over 50% getting rid of some of the more confusing trace bits.\n> But it\'s something that you make progress on 1% at a time.\n> \n> At some point we do need to say \"you have to understand OpenStack and\n> the Test run process ^this much^ to be able to ride\", because cleaning\n> up every small thing isn\'t really possible.\n> \n> Now, providing a better flow explaining the parts here might be good. We\n> do it during Infra bootcamps, and people find it helpful. But again,\n> that\'s a mostly pull model because the people showing up did so\n> specifically to learn, so are much more receptive to gaining the\n> information at hand.\n> \n>>>>> Sanitizing the OpenStack logs to be crisp about actual things going\n>>>>> wrong, vs. not, shouldn\'t be intractable, but it feels like it some\n>>>>> times. Which is why all operators run at DEBUG level. The thing that\n>>>>> makes it hard for developers to see the issues here is the same thing\n>>>>> that makes it *really* hard for operators to figure out failures. It\'s\n>>>>> also why I tried (though executed poorly on, sorry about that) getting\n>>>>> log cleanups rolling this cycle.\n>>>> \n>>>> I would like to have the TC back an official cross-project effort to clean up the logs for Kilo, and get all of the integrated projects to commit to working on it as a priority.\n>>>> \n>>>> Doug\n>>>> \n>>>>> \n>>>>> 	-Sean\n>>>>> \n>>>>> -- \n>>>>> Sean Dague\n>>>>> http://dague.net\n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>>> \n>>> -- \n>>> Sean Dague\n>>> http://dague.net\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> \n> -- \n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<53FF71CA.9060206@dague.net>',NULL),('<0D335F44-8B26-4F9A-A066-6DF2E1FAA0FF@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-19 16:28:59',-28800,'2012-11-20 00:28:59',NULL,'[openstack-dev] Pep8 versions??','\nOn Nov 19, 2012, at 4:16 PM, Chuck Short wrote:\n\n> On 12-11-19 06:40 PM, Joe Gordon wrote:\n>> \n>> \n>> On Mon, Nov 19, 2012 at 3:06 PM, Monty Taylor <mordred at inaugust.com <mailto:mordred at inaugust.com>> wrote:\n>> \n>>    I think these are orthogonal. In general I believe we\'re in\n>>    agreement that we should be targetting the same version of pep8,\n>>    and that we should pin that version early in the cycle. However we\n>>    install that version of pep8 is a different argument.\n>> \n>> \n>> Targeting the same version of pep8 is only part of the problem, we would also need to agree on what rules to ignore. For example:\n>> \n>> glance (pep8 1.3.3) ignores: E125,E126,E711,E712\n>> nova (pep8 1.2) ignores: E12,E711,E721\n>> keystone (pep8 1.3.3) ignores: ---\n> \n> Is there a reason why these were ignored?\n\nI just ran glance\'s pep8 check without ignoring any errors, and it appears most of them are just arbitrary spacing. I\'ll attempt to minimize the number of pep8 violations we ignore.\n\n','<50AACBD6.1070409@canonical.com>',NULL),('<0D36179E-2F6B-4B45-83F2-7B2026F059A7@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 11:42:04',-14400,'2014-09-22 15:42:04',NULL,'[openstack-dev] [Keystone][Oslo] Federation and Policy','\nOn Sep 21, 2014, at 9:59 PM, Adam Young <ayoung at redhat.com> wrote:\n\n> On 09/19/2014 01:43 PM, Doug Hellmann wrote:\n>> On Sep 19, 2014, at 6:56 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:\n>> \n>>> \n>>> On 18/09/2014 22:14, Doug Hellmann wrote:\n>>>> On Sep 18, 2014, at 4:34 PM, David Chadwick <d.w.chadwick at kent.ac.uk>\n>>>> wrote:\n>>>> \n>>>>> \n>>>>> On 18/09/2014 21:04, Doug Hellmann wrote:\n>>>>>> On Sep 18, 2014, at 12:36 PM, David Chadwick\n>>>>>> <d.w.chadwick at kent.ac.uk> wrote:\n>>>>>> \n>>>>>>> Our recent work on federation suggests we need an improvement\n>>>>>>> to the way the policy engine works. My understanding is that\n>>>>>>> most functions are protected by the policy engine, but some are\n>>>>>>> not. The latter functions are publicly accessible. But there is\n>>>>>>> no way in the policy engine to specify public access to a\n>>>>>>> function and there ought to be. This will allow an\n>>>>>>> administrator to configure the policy for a function to range\n>>>>>>> from very lax (publicly accessible) to very strict (admin\n>>>>>>> only). A policy of \"\" means that any authenticated user can\n>>>>>>> access the function. But there is no way in the policy to\n>>>>>>> specify that an unauthenticated user (i.e. public) has access\n>>>>>>> to a function.\n>>>>>>> \n>>>>>>> We have already identified one function (get trusted IdPs\n>>>>>>> \"identity:list_identity_providers\") that needs to be publicly\n>>>>>>> accessible in order for users to choose which IdP to use for\n>>>>>>> federated login. However some organisations may not wish to\n>>>>>>> make this API call publicly accessible, whilst others may wish\n>>>>>>> to restrict it to Horizon only etc. This indicates that that\n>>>>>>> the policy needs to be set by the administrator, and not by\n>>>>>>> changes to the code (i.e. to either call the policy engine or\n>>>>>>> not, or to have two different API calls).\n>>>>>> I don?t know what list_identity_providers does.\n>>>>> it lists the IDPs that Keystone trusts to authenticate users\n>>>>> \n>>>>>> Can you give a little more detail about why some providers would\n>>>>>> want to make it not public\n>>>>> I am not convinced that many cloud services will want to keep this\n>>>>> list secret. Today if you do federated login, the public web page\n>>>>> of the service provider typically lists the logos or names of its\n>>>>> trusted IDPs (usually Facebook and Google). Also all academic\n>>>>> federations publish their full lists of IdPs. But it has been\n>>>>> suggested that some commercial cloud providers may not wish to\n>>>>> publicise this list and instead require the end users to know which\n>>>>> IDP they are going to use for federated login. In which case the\n>>>>> list should not be public.\n>>>>> \n>>>>> \n>>>>>> if we plan to make it public by default? If we think there?s a\n>>>>>> security issue, shouldn?t we just protect it?\n>>>>>> \n>>>>> Its more a commercial in confidence issue (I dont want the world to\n>>>>> know who I have agreements with) rather than a security issue,\n>>>>> since the IDPs are typically already well known and already protect\n>>>>> themselves against attacks from hackers on the Internet.\n>>>> OK. The weak ?someone might want to? requirement aside, and again\n>>>> showing my ignorance of implementation details, do we truly have to\n>>>> add a new feature to disable the policy check? Is there no way to\n>>>> have an ?always allow? policy using the current syntax?\n>>> You tell me. If there is, then problem solved. If not, then my request\n>>> still stands\n>> From looking at the code, it appears that something like True:?True? (or possibly True:True) would always pass, but I haven?t tested that.\n> \n> Nope;  it errors out before it ever gets to the policy check, when it unpacks the token.\n\nWhich ?token? do you mean, something in the policy parser or the keystone token? Are you saying that the syntax I suggested isn?t valid and so can?t be parsed, or that some other part of the code is throwing an error before the policy module is ever being invoked?\n\n>> \n>> Doug\n>> \n>>> regards\n>>> \n>>> David\n>>> \n>>>> Doug\n>>>> \n>>>>> regards\n>>>>> \n>>>>> David\n>>>>> \n>>>>>>> If we can invent some policy syntax that indicates public\n>>>>>>> access, e.g. reserved keyword of public, then Keystone can\n>>>>>>> always call the policy file for every function and there would\n>>>>>>> be no need to differentiate between protected APIs and\n>>>>>>> non-protected APIs as all would be protected to a greater or\n>>>>>>> lesser extent according to the administrator\'s policy.\n>>>>>>> \n>>>>>>> Comments please\n>>>>>> It seems reasonable to have a way to mark a function as fully\n>>>>>> public, if we expect to really have those kinds of functions.\n>>>>>> \n>>>>>> Doug\n>>>>>> \n>>>>>>> regards\n>>>>>>> \n>>>>>>> David\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________ OpenStack-dev\n>>>>>>> mailing list OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>> _______________________________________________ OpenStack-dev mailing\n>>>>>> list OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>> \n>>> _______________________________________________\n>>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> _______________________________________________ OpenStack-dev mailing\n>>>> list OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<541F827F.9070609@redhat.com>',NULL),('<0d3a871a6bbc429196a66b566f1c1770@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 16:17:05',0,'2014-08-11 16:17:05',NULL,'[openstack-dev] [neutron] [third-party] Freescale CI log site\n is being blocked','Hi-\n\nToday I contacted the service provider regarding the malware in the website. Got a response that website is truly functional and malware free.\n\nI too have verified all the directories, subdirectories and log files manually for any malware injected into the website. I have detected none.\n\nThere is no anonymous login enabled for FTP or cPanel login to the server. The FTP is protected with Strong Passcode.\n\nThis is an update from my end. \n\nLike all other CI\'s now normal browsing of logs is available for view.\n\nThe CI is made down to take the above explained changes to take place. Now the CI is active running the jobs.\n\nAll the old logs are present as in place. \n\nYou may browse the old logs using the url \n\nFor ML2 Mechanism driver : http://fslopenstackci.com/{change_number}/{change_patchset}/Freescale-ML2-Mechanism-Driver\nFor FWaaS Plugin : http://fslopenstackci.com/{change_number}/{change_patchset}/Freescale-FWaaS-Plugin\n\nNow I have updated the CI to create a BUILD directory as well to showcase logs for \"rechecks\".\n\nWith this new change the log URL will be \n\nFor ML2 Mechanism driver : http://fslopenstackci.com/{build_number}/{change_number}/{change_patchset}/Freescale-ML2-Mechanism-Driver\nFor FWaaS Plugin : http://fslopenstackci.com/{build_number}/{change_number}/{change_patchset}/Freescale-FWaaS-Plugin\n\n\nHi Mestery-\n\nKindly please verify the access to the site. \n\nAlso, if it\'s still in blocking mode, kindly mail me the logs with Cisco WSA to verify the reason behind this blocking.\n\nKindly help me with your review on my code at https://review.openstack.org/#/c/109659/\n\nThanking  you all.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | Mob: +91 9866 235 130\n\n-----Original Message-----\nFrom: Anita Kuno [mailto:anteaya at anteaya.info] \nSent: Saturday, August 09, 2014 11:09 AM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [neutron] [third-party] Freescale CI log site is being blocked\n\nOn 08/08/2014 11:27 PM, trinath.somanchi at freescale.com wrote:\n> Thanks anita for the reply.\n> \n> Previously the existing server is accessible by kyle. But now its not being accessible. \n> \n> For the paid hosting I have its administered by godaddy\nIf you are paying godaddy to administer the server, have you asked them why one of your users has acknowledged your site is blacklisted by Cisco WSA appliances?\n\nIf you are paying them to administer your server, answering your question falls within their job.\n\nYou need to find out the reason behind Cisco security blocking, that is what I am asking you to do. It if fine if you don\'t know, but it is your responsibility to find out.\n\nThanks Trinath,\nAnita.\n\n> and the FTP is only accessed by Jenkins. \n> \n> I can try relocating FTP web based file browser script and provide a normal view of files. \n> \n> Don\'t know the reason behind Cisco Security blocking the access where it has given access to view the website before.\n> \n> Thanks a lot again for the brief email.\n> \n> \n> --\n> Trinath Somanchi - B39208\n> trinath.somanchi at freescale.com | extn: 4048\n> \n> -----Original Message-----\n> From: Anita Kuno [mailto:anteaya at anteaya.info]\n> Sent: Saturday, August 09, 2014 10:21 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [neutron] [third-party] Freescale CI log \n> site is being blocked\n> \n> On 08/08/2014 10:06 PM, trinath.somanchi at freescale.com wrote:\n>> Hi Sumit-\n>>\n>> When I try to paste a large log text into paste.openstack, It is giving me image verification and says its spam.\n> Let\'s not confuse paste.openstack.org\'s spam blocker from spam blockers on servers. They are two separate functionalities and the conversation does not move forward if we try to pretend they are the same thing or even remotely related, which they are not.\n> \n> If you recall, Trinath, the first server you had got hacked since you had not hardened it appropriately. Having hosting via go daddy or any other paid hosting service does not absolve you of the responsibility of having a well maintained server. If you need help maintaining your server, I suggest you contract a server administrator to advise you or do the work. We have to assume a certain level of competence here, due to the responsibility involved I don\'t think you are going to get many responses to questions if you don\'t know how to maintain your server.\n> This isn\'t really the the place to ask. Running your third party ci system and copying the logs, sure this is the place, basic server maintenance is your responsibility.\n> \n> If you recall, a basic evaluation of your server logs told you you had been hacked the last time. This might be a place to start now.\n> \n> In any case, please maintain your server and please address Kyle\'s concerns.\n> \n> Thank you Trianth,\n> Anita.\n>>\n>> I don\'t know why its taken as spam/malware. It\'s a paid hosting I had from GODADDY.\n>>\n>> --\n>> Trinath Somanchi - B39208\n>> trinath.somanchi at freescale.com | extn: 4048\n>>\n>> -----Original Message-----\n>> From: Sumit Naiksatam [mailto:sumitnaiksatam at gmail.com]\n>> Sent: Saturday, August 09, 2014 1:12 AM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: Re: [openstack-dev] [neutron] [third-party] Freescale CI log \n>> site is being blocked\n>>\n>> Actually I am able to access the logs in this CI over the internet \n>> and through my service provider. I have copy-pasted the log from the \n>> latest freescale run here (to validate if this is indeed the latest\n>> run):\n>> http://paste.openstack.org/show/92229/\n>>\n>> But good point Kevin, when I was trying to post this on paste, it did complain about the log text appearing like spam.\n>>\n>> On Fri, Aug 8, 2014 at 10:58 AM, Kevin Benton <blak111 at gmail.com> wrote:\n>>> Does your log server allow anonymous uploads that caused it to host \n>>> malware or something that led to it being blocked?\n>>>\n>>>\n>>> On Fri, Aug 8, 2014 at 7:12 AM, Kyle Mestery <mestery at mestery.com> wrote:\n>>>>\n>>>> Trinath:\n>>>>\n>>>> In looking at your FWaaS review [1], I noticed the site you are \n>>>> using for log storage is being blacklisted again, at least by Cisco \n>>>> WSA appliances. Thus, I cannot see the logs for it. Did you change \n>>>> the location of your log storage again? Is anyone else seeing this issue?\n>>>>\n>>>> Thanks,\n>>>> Kyle\n>>>>\n>>>>\n>>>> [1] https://review.openstack.org/#/c/109659/\n>>>>\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>>\n>>>\n>>> --\n>>> Kevin Benton\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53E5B3F8.7090107@anteaya.info>',NULL),('<0d4201d0267f$aa1c0710$fe541530$@cloudbyte.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-02 17:01:31',19800,'2015-01-02 11:31:31',NULL,'[OpenStack-Infra]  [ThirdPartyCI] Tempest test for cinder driver','Hi,\n\n \n\nI am setting up CI for my cinder driver therefore, I want to know that in\ntempest should I have to run all the tests or only cinder related tests can\nbe done. \n\n \n\n \n\nThanks & Regards,\n\nAbhishek Shrivastava\n\n \n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150102/4ca6716a/attachment.html>\n\n',NULL,NULL),('<0d436a8db27442cb8e3dc0bfcb038675@BY2PR42MB101.048d.mgd.msft.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-05 02:22:49',0,'2014-09-05 02:22:49',NULL,'[Openstack] FW:   nova resize error','On Sep 4, 2014 9:54 PM, \"raghavendra.lad at accenture.com\" <raghavendra.lad at accenture.com> wrote:\n\n\nHi All,\n\nI am trying to resize the tiny flavor to small using Cirros image in Openstack Icehouse.\n\nI can go ahead and resize, it says 100% complete when I try the resize-confirm\ncommand it gives the below error:\n\n\nnova resize-confirm xxxxxxxxxxxx\nERROR: Cannot \'confirmResize\' while instance is in vm_state active (HTTP 409)\n\nPlease let me know if we have an option to resize flavor in Icehouse?\n\n\nRegards,\nRaghavendra Lad\n\n\n\n?________________\n\nwww.accenture.com\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140905/9204310e/attachment.html>\n\n','<1409846845471.84278@accenture.com>',NULL),('<0D4CDDDD-D026-4DF7-A676-0D73721B9BC1@lanabrindley.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-10 10:58:47',28800,'2014-01-10 02:58:47',NULL,'[Openstack-docs] Ice House vs Icehouse vs IceHouse vs icehouse','I?ve been writing Icehouse, but only through ignorance. I think we should be true to the name of the street, which would make it Ice House (two words, initcaps). \n\nOf course, there are implications for code, etc, with release names containing special characters, so if that is a consideration I think Icehouse is the next best option. I can?t stand camel case, so I would actively argue against that.\n\nL\n\nOn 10 Jan 2014, at 8:16 am, Tom Fifield <tom at openstack.org> wrote:\n\n> Hi,\n> \n> Just following up from suggestions made in https://review.openstack.org/#/c/65616/ to change \"Ice House\" to \"Icehouse\".\n> \n> So far I\'ve regularly written Ice House or IceHouse, because the proper name of the original street is two separate words, both in Chinese and English.\n> \n> However, I do see that Icehouse/icehouse is in frequent use on the wiki and on launchpad.\n> \n> So, what\'s the standard for documentation? :)\n> \n> \n> Regards,\n> \n> \n> Tom\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n','<52CF3BCA.3060002@openstack.org>',NULL),('<0D4D8837A66F463BADFEDA956EDD888C@PC201007301138>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-26 15:11:17',28800,'2012-12-26 07:11:17',NULL,'[openstack-dev] [Quantum] [cloudpipe] what\'s the direction of\n	cloudpipe?','Stackers,\nAnyone can tell me what\'s the status of cloudpipe status?\nIs that still work in latest Folsom release?\nI found a page on blueprint https://blueprints.launchpad.net/quantum/+spec/nova-vpn-parity\nIs this something improvement of cloudpipe to support other VPN servers(not openvpn)? Like what LBaas did for loadbalancer?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121226/a160da6a/attachment.html>\n\n',NULL,NULL),('<0D4EB934-0079-4384-98A5-147B9A6B83FB@pd.infn.it>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-10 12:14:15',7200,'2014-08-10 10:14:15',NULL,'[Openstack-operators] Flavor ID mismatch','Hi,\nI?ve created a new flavor in my openstack cloud, called xsmall. When I started a new instance with that flavor, I found that it is connected to a non-existing flavor ID, which is resolved to my xsmall new flavor:\n\n\n~>nova flavor-list\n+--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+\n| ID                                   | Name       | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |\n+--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+\n| 1229a10f-5f13-4218-ba21-47a49cb99ae9 | m1.medium  | 2048      | 10   | 0         |      | 2     | 1.0         | True      |\n| 4b5afdbf-8dc3-4b30-938c-864e2da27f00 | m1.small   | 1024      | 5    | 0         |      | 1     | 1.0         | True      |\n| 677e1cc5-0046-4b22-9b17-57483b24030f | m1.xsmall  | 512       | 3    | 0         |      | 1     | 1.0         | True      |\n| 9eb9489a-f116-4282-9ba9-035a9408b3a9 | m1.tiny    | 256       | 1    | 0         |      | 1     | 1.0         | True      |\n| a5618e34-9118-42ec-a404-143f4cf14f86 | m1.large   | 4096      | 40   | 0         |      | 2     | 1.0         | True      |\n| ad49139e-e609-4d18-9962-cfdcf211c235 | m1.xxlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |\n| dfdd707d-5a3f-42a2-be3e-864b548bc536 | m1.xlarge  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |\n+--------------------------------------+------------+-----------+------+-----------+------+-------+-------------+-----------+\n\n~>nova flavor-show m1.xsmall\n+----------------------------+--------------------------------------+\n| Property                   | Value                                |\n+----------------------------+--------------------------------------+\n| name                       | m1.xsmall                            |\n| ram                        | 512                                  |\n| OS-FLV-DISABLED:disabled   | False                                |\n| vcpus                      | 1                                    |\n| extra_specs                | {}                                   |\n| swap                       |                                      |\n| os-flavor-access:is_public | True                                 |\n| rxtx_factor                | 1.0                                  |\n| OS-FLV-EXT-DATA:ephemeral  | 0                                    |\n| disk                       | 3                                    |\n| id                         | 677e1cc5-0046-4b22-9b17-57483b24030f |\n+----------------------------+???????????????????+\n\n ~>nova show 698d493b-0866-4979-9101-e94a2aed9ebc\n+--------------------------------------+----------------------------------------------------------+\n| Property                             | Value                                                    |\n+--------------------------------------+----------------------------------------------------------+\n| status                               | ACTIVE                                                   |\n| updated                              | 2014-08-08T10:17:33Z                                     |\n| OS-EXT-STS:task_state                | None                                                     |\n| OS-EXT-SRV-ATTR:host                 | compute-01.cloud.pd.infn.it                              |\n| key_name                             | None                                                     |\n| image                                | Fedora 20 - x64 (910417c9-de55-45e1-849d-d84f095c8a87)   |\n| hostId                               | 6384c4d4e4d8c298b66ce2f2528f335a16071d6dc2456236e511bba4 |\n| OS-EXT-STS:vm_state                  | active                                                   |\n| OS-EXT-SRV-ATTR:instance_name        | instance-00000026                                        |\n| OS-SRV-USG:launched_at               | 2014-08-08T10:14:25.000000                               |\n| OS-EXT-SRV-ATTR:hypervisor_hostname  | compute-01.cloud.pd.infn.it                              |\n| flavor                               | m1.xsmall (904db668-b018-4563-81a7-189d2206b47e)         |\n| id                                   | 698d493b-0866-4979-9101-e94a2aed9ebc                     |\n| security_groups                      | [{u\'name\': u\'default\'}]                                  |\n| OS-SRV-USG:terminated_at             | None                                                     |\n| user_id                              | 052be1ed98024ae1acb18ff692deef5a                         |\n| name                                 | test-698d493b-0866-4979-9101-e94a2aed9ebc                |\n| created                              | 2014-08-08T10:12:54Z                                     |\n| tenant_id                            | fb310b4d52f14fbbaf337d803576c7e0                         |\n| OS-DCF:diskConfig                    | MANUAL                                                   |\n| metadata                             | {}                                                       |\n| os-extended-volumes:volumes_attached | []                                                       |\n| accessIPv4                           |                                                          |\n| accessIPv6                           |                                                          |\n| progress                             | 0                                                        |\n| OS-EXT-STS:power_state               | 1                                                        |\n| OS-EXT-AZ:availability_zone          | nova                                                     |\n| Admin network                        | 10.0.1.10                                                |\n| config_drive                         |                                                          |\n+--------------------------------------+?????????????????????????????+\n\nas you can see \"nova show? shows an ID for xsmall which is different than that one of the output of flavor-list or flavor-show.\nWhile it seems not to be a problem for the end-user who uses the command-line, it becomes a \'semi-serious\' problem for 3rd party clients using the nova APIs (v2).\n\nIs this a known issue or am I doing something wrong ?\n\n	Alvise\n\n',NULL,NULL),('<0D51280D-134D-4CA5-9DAF-A31D22266C25@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-21 12:24:56',0,'2014-04-21 12:24:56',NULL,'[Openstack-docs] Conventions for OpenStack Networking,\n legacy networking','I am fine either way. But a question- should i doc nova-networks on API site?  \n\nSent from my iPhone\n\n> On Apr 21, 2014, at 12:05 AM, \"Andreas Jaeger\" <aj at suse.com> wrote:\n> \n>> On 04/20/2014 08:01 PM, Diane Fleming wrote:\n>> I made this update on API site in this patch:\n>> \n>> https://review.openstack.org/89265\n> \n> Do we really need this there? I was under the impression that this is a\n> convention especially for the Install Guide where we have both concepts\n> together,\n> \n> Andreas\n> -- \n> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n\n','<5354A6EB.7080807@suse.com>',NULL),('<0d5d6c47b541ad544b8fc4f57307dcb7@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 15:41:35',-21600,'2013-12-04 21:41:35',NULL,'[openstack-dev] [Solum] Unicode strings in Python3',' \n\nI don\'t think so. It looks like ./solum/api/controllers/v1/assembly.py\nis calling unicode(). It will need to be changed to six.text_type() for\nPython 3 compat. \n\n-Ben \n\nOn 2013-12-04 15:41, Adrian Otto wrote: \n\n> Am I interpreting this to mean that WSME is calling unicode()? \n> \n> On Dec 4, 2013, at 1:32 PM, Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> \n> wrote: \n> \n>> Hi, \n>> \n>> I am working on unit tests for Solum as a side effect of new unit tests I found that we use unicode strings in the way which is not compatible with python3. \n>> \n>> Here is an exception form python3 gate: \n>> Server-side error: \"global name \'unicode\' is not defined\". Detail: 2013-12-04 Traceback (most recent call last): File \"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/wsmeext/pecan.py\" \n>> result = f(self, *args, **kwargs) \n>> File \"./solum/api/controllers/v1/assembly.py\", line 59, in get \n>> raise wsme.exc.ClientSideError(unicode(error)) \n>> NameError: global name \'unicode\' is not defined \n>> \n>> Here is a documentation for python3: http://docs.python.org/3.0/whatsnew/3.0.html [1] \n>> \n>> Quick summary: you can\'t use unicode() function and u\' \' strings in Pyhton3. \n>> \n>> Thanks \n>> Georgy _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]\n\n \n\nLinks:\n------\n[1] http://docs.python.org/3.0/whatsnew/3.0.html\n[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131204/6db57de1/attachment.html>\n\n','<4C784F28-3366-4E54-864D-C354C5D94D54@rackspace.com>',NULL),('<0D5E98F9-C5D7-4CE7-9634-B3088E7D944C@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 15:06:27',-25200,'2012-10-11 22:06:27',NULL,'[openstack-dev] [keysstone] External authentication','Hey Boden,\n\nNice setup - we definitely won\'t be having a regular keystone meeting next week (and I missed this week\'s as well). Are you going to be at the summit? Can we catch up there and discuss the blueprint? \n\n- joe\n\nOn Oct 11, 2012, at 1:19 PM, Adam Young <ayoung at redhat.com> wrote:\n> On 10/04/2012 02:13 PM, boden wrote:\n>> I recently pushed my PoC pluggable authN handler code to a personal fork. The commit can be viewed here: https://github.com/BodenRussell/keystone/commit/e794705ad3a4ec2101090490b682690d0863c44d\n>> \n>> It\'s not fully baked, but does the trick.\n>> \n>> To add an authN handler:\n>> a) Implement your handler class which extends the keystone.identity.authn.core.AuthenticationDriver\n>> b) Provide a concrete impl of the \'authenticate(...)\' method from that interface using the semantics noted in the method py doc. Note that the actual request object is in the context so you can access it like: context[\'request\']\n>> c) Make sure your handler class is in the python path for keystone\n>> d) Add your package/class name to the \'[authentication]\' group/section of keystone.conf -- this is a list opt\n>> e) Start keystone\n> \n> Nice work.\n>> \n>> I\'m hoping this sample can help move along the pluggable authN blueprint: https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-authentication-handlers or some form of it.\n>> \n>> I will try to join the keystone weekly meeting next week to sync up on our direction for this support.\n> \n> Next week is the Summit, so the meeting will likely not happen.\n> \n>> \n>> Thanks\n>> \n>> \n>> On 10/3/2012 12:08 PM, boden wrote:\n>>> I agree with the comment made below regarding adding pluggable authN\n>>> handlers to Keystone in addition to HTTPD support...\n>>> \n>>> To me the ideal support for maximal flexibility is:\n>>> (a) We have (optional) HTTPD \'fronting\' support for those consumers who\n>>> wish to proxy a HTTP (WSGI capable) based server in front of the WSGI\n>>> service. In this configuration the fronting server can optionally\n>>> perform authN on behalf of Keystone.\n>>> (b) We continue to support the eventlet based model for those who wish\n>>> to run as-is today, but also add support for pluggable authN handlers\n>>> along the lines with the pluggable authentication handlers blueprint.\n>>> \n>>> Having support for both opens the doors for many schemes.\n>>> \n>>> For example, I currently have a requirement to support conditional authN\n>>> based on a \'simple token\' in the request header (AES encrypted with\n>>> shared key). I\'m not an apache expert, but it appears to handle this\n>>> custom authN via apache I might use the mod_authnz_external module which\n>>> calls my custom handler. As I understand, this approach could (although\n>>> I have no hard evidence yet) introduce performance hits due the external\n>>> module having to create a new process for each request and piping to it.\n>>> I would likely prefer to implement a Python based authN handler and plug\n>>> it into Keystone (which I\'ve already done with a PoC).\n>>> \n>>> BTW -- Based on recent side conversations, I believe some members of the\n>>> Swift community will soon be publishing a blueprint which focuses on\n>>> enabling (optional) HTTPD support for all WSGI services. With that in\n>>> mind maybe we should be working across the OpenStack projects for this\n>>> support so that all services have consistent behavior. The blueprint\n>>> should be published by the Swift team in the next few days, and I\'ll\n>>> post it to this list once it becomes available.\n>>> \n>>> Thx\n>>> \n>>> On 10/3/2012 8:18 AM, ?lvaro L?pez Garc?a wrote:\n>>>> Hi Adam.\n>>>> \n>>>> On Tue 02 Oct 2012 (10:36), Adam Young wrote:\n>>>>> On 10/02/2012 07:51 AM, Alvaro Lopez wrote:\n>>>>> \n>>>>> (...)\n>>>>> \n>>>>>>> 1.  If the user is not in the local store, look in the remote store\n>>>>>>> 2.  If the user is in the local store, still authenticate against\n>>>>>>> the remote store.\n>>>>>> I think this is a key part of the design, that is, how to define the\n>>>>>> rules that apply to either the plugged modules and the identity store\n>>>>>> backend.\n>>>>>> \n>>>>>>> 3.  Use the REMOTE_USER as id, iff there is no other ID specified\n>>>>>>> (gets into the original topic of this thread)\n>>>>>>> 4.  Use the Client Certificate from the SSL connection.\n>>>>>> With the BP in mind I see these as a particular case of two different\n>>>>>> pluggable modules, lets say keystone.identity.authN.external for\n>>>>>> REMOTE_USER and keystone.identity.authN.SSL for client certificates.\n>>>>> \n>>>>> Kerberos is a potential third.  However,  user certs and Kerberos\n>>>>> are both probably best done by Apache HTTPD.  Take a look at how\n>>>>> mod_nss handles the Client Cert code and you will realize that we do\n>>>>> not want to try and reproduce that in Eventlet.\n>>>> \n>>>> Indeed you\'re right. Reinventing the wheel was not my intetion (see\n>>>> below).\n>>>> \n>>>>>>> I am starting to worry that this is more work than justified, as\n>>>>>>> Apache HTTPD already supports this form of authentication.  I am not\n>>>>>>> sure it makes sense to rebuild this functionality.\n>>>>>>> \n>>>>>>> Do the features of Apache HTTPD authentication solve your use cases\n>>>>>>> if they are done in conjunction with REMOTE_USER?  if so, perhaps we\n>>>>>>> should put our effort into making HTTPD the default server instead.\n>>>>>>> Note that I am not saying \"no\"  just want to justify the effort.\n>>>>>>> Even if we go HTTPD, we will still need to address the local/remote\n>>>>>>> split.\n>>>>>> Apache could solve most of the use cases (plain x509 certificates,\n>>>>>> kerberos, etc), but not all of them (I am not too familiar with\n>>>>>> apache authn though). For example, some authN modules could require\n>>>>>> some more logic behind that could difficult to be made in Apache.\n>>>>> \n>>>>> Lets defer that thought until we have the real limit to HTTPD.  I am\n>>>>> not suggesting that we check Eventlet completely just yet, but I\n>>>>> would be surprised to find there was something that we just could\n>>>>> not do completely within the scope of HTTPD.\n>>>> \n>>>> Maybe I was not clear, I didn\'t meant that at all.\n>>>> \n>>>> I agree with you in going HTTPD. What I wanted to state is not to just\n>>>> add support for external authn via REMOTE_USER, but add support for the\n>>>> pluggable authn modules (as described in the the BP) being \"external\n>>>> authN\" one of these modules. This way:\n>>>> \n>>>>  - If there\'s a way to do authN (ldap, X.509, kerberos, etc) in Apache,\n>>>>    the external authn module should be the way to go.\n>>>>  - If there\'s somebody that wants to develop/implement an additional\n>>>>    authentication module provide them with the pluggable infrastructure\n>>>>    needed to do so.\n>>>> \n>>>> Cheers,\n>>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<507729E9.20108@redhat.com>',NULL),('<0D6F5F04-6ACD-4C79-A001-E850B6D097D2@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-23 16:39:16',0,'2013-12-23 16:39:16',NULL,'[Openstack] Openstack achieve the elasticity for computation','Nope, u can over provision on most all of the resources (CPU, ram, disk) u described there. Ram is the tricky one as the Linux oom killer may start to get involved when u push the ram limits to high. But there is nothing stopping u from running 8 or more vms on a box, depending on the over provision ratio u are ok with...\n\nSent from my really tiny device...\n\nOn Dec 23, 2013, at 3:55 AM, \"Vikas Parashar\" <para.vikas at gmail.com<mailto:para.vikas at gmail.com>> wrote:\n\nThanks Cristian,\n\nWill elasticity  be limited to 4 Cores/4GB  (The max capacity of a physical host) ?\n\n\nOn Mon, Dec 23, 2013 at 5:00 PM, Cristian Falcas <cristi.falcas at gmail.com<mailto:cristi.falcas at gmail.com>> wrote:\nHi,\n\n>From what I know you can resize a machine, but this involves\nrebuilding the instance: openstack will create a snapshot of the\nmachine an recreate the instance with the new snapshot and a new\nflavor. This is not very fast from my experience, so you will have a\nconsiderable downtime doing this, depending on the size of the current\ninstance and how fast is your storage.\n\nBest regards,\nCristian Falcas\n\n\n\nOn Mon, Dec 23, 2013 at 12:03 PM, Vikas Parashar <para.vikas at gmail.com<mailto:para.vikas at gmail.com>> wrote:\n> Hi,\n>\n> IaaS is all about elastic computing. I can stretch resources as per my need\n> - increasing/decreasing the number of cores, RAM allocated etc..\n>\n> My question is - how does openStack achieve this elasticity for both\n> computation and RAM.\n>\n> If I create an image with 2 cores and 4 GB RAM (and one day I need to\n> increase this to, lets say - 6 Cores and 12 GB RAM), but all the physical\n> hosts that I currently have (for Compute and RAM) at my disposal have a max\n> of 4 Cores and 4 GB RAM each..\n>\n> Using openStack -\n>\n> a) is this possible (as long as the total cores and total RAM required is\n> less than the group-total) ? If yes, how is this achieved.\n>\n> b) or the elasticity will be limited to 4 Cores/4GB  (The max capacity of a\n> physical host) ? If no, then is it possible to achieve it ?\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/39a1fc70/attachment.html>\n\n','<CAGa4XmzvQdBtTEmx3hDo_oK75kqGB6NjiGzh+ZJXSkPTFyiQ0g@mail.gmail.com>',NULL),('<0D783456-5583-46B4-A00B-2FAE6D04B2B7@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-21 10:35:57',-25200,'2012-08-21 17:35:57',NULL,'[openstack-dev] Glance Folsom Release','As the feature phase of Folsom has closed, I went ahead and wrote up some notes about Glance. I included it all in this email, but you can see the pretty version at http://bcwaldon.cc/2012/08/20/openstack-folsom-glance-overview.html.\n\nBrian Waldon\n\n--\n\nAs we are coming up on the Folsom OpenStack release, I thought it would be a good idea to cover what landed in Glance over the last several months. It is becoming increasingly difficult to keep up with all of our projects, so I hope this overview helps!\n\n## Python Client Rewrite\n\nA new client library, [python-glanceclient](http://github.com/openstack/python-glanceclient), was created during the Folsom release cycle to replace the client that currently lives in the Glance repository. This new client has already been integrated into Nova, Cinder, Horizon and Devstack.\n\nAs a [library project](http://wiki.openstack.org/ProjectTypes), python-glanceclient does not follow the same release cycle as core projects such as Glance. It uses a three-part versioning mechanism and is distributed through OpenStack-supporting distros, [pypi](http://pypi.python.org/pypi/python-glanceclient), and [GitHub](http://github.com/openstack/python-glanceclient).\n\nThe importance bit is that the (now considered \'legacy\') client code in Glance is officially deprecated in favor of this new client. It will still ship with Folsom, but it prints warnings to stderr when used from the command-line and raises `UserWarning` when imported directly in python. Expect the legacy client code to be removed from the Glance repository sometime early in the Grizzly release cycle.\n\nThe new client does maintain 100% CLI compatibility for interactions with the v1 Images API, but that legacy usage will never be updated to work with the v2 API. The python interface does not maintain compatibility with the legacy client, however, the python module does not conflict with that installed by the Glance source. Expect to see more about python-glanceclient in a subsequent post.\n\n## OpenStack Images API v2.0\n\nVersion 2.0 of the OpenStack Images API is largely defined based on the work that was finished in the Folsom release of Glance. Expect a separate post covering the v2.0 API spec itself.\n\nI wanted to specifically thank Mark Washenberger, Alex Meade, Iccha Sethi and Nikhil Komawar of Rackspace for their outstanding work on the v2.0 API implementation!\n\nSee the [super-blueprint on launchpad](https://blueprints.launchpad.net/glance/+spec/api-2).\n\n## High-Profile Bugs\n\nFeatures are always awesome, but the biggest request of the OpenStack community has been to work on stabilization and bug-fixing. The following is a list of major bugs that were fixed in the Folsom release cycle, many more lower-priority bugs were fixed and can be seen on launchpad. Bugs that affect stable/essex have been backported accordingly.\n\n### Keystone Integration\n\n* [1010519](https://bugs.launchpad.net/glance/+bug/1010519): Use a case-insensitive check when determining if a user has admin privileges\n\n### Swift Integration\n\n* [979745](https://bugs.launchpad.net/glance/+bug/979745): Actually delete images from swift when using Keystone authentication.\n* [1002791](https://bugs.launchpad.net/glance/+bug/1002791): Replace usage of `swift.client` with `swiftclient` - swift dependency replaced with python-swiftclient.\n* [994296](https://bugs.launchpad.net/glance/+bug/994296): Allow swift account name to contain the \'@\' character.\n\n### SSL\n\n* [1032451](https://bugs.launchpad.net/glance/+bug/1032451): Allow server to validate client certificate using CA cert specified in `ca_file` config option.\n* [1007093](https://bugs.launchpad.net/glance/+bug/1007093): Images less than 4 KB in size are now uploaded only once; data is no longer duplicated.\n\n### Database\n\n* [1012823](https://bugs.launchpad.net/glance/+bug/1012823): Prevent database auto-creation - configurable using `db_auto_create` config option.\n* [975651](https://bugs.launchpad.net/ubuntu/+source/glance/+bug/975651): Update all image id references in db migration 12; image properties were being ignored.\n\n### Miscellaneous\n\n* [1038994](https://bugs.launchpad.net/glance/+bug/1038994): Maximum image size is now configurable using `image_size_cap` (default 1 TB) and chunked transfer-encoding HTTP requests are now properly validated.\n* [978130](https://bugs.launchpad.net/glance/+bug/978130): Multiprocess-enabled servers now respect CTRL+C.\n* [1031842](https://bugs.launchpad.net/glance/+bug/1031842): Partially-cached images are removed when a client connection is prematurely closed.\n* [1021054](https://bugs.launchpad.net/glance/+bug/1021054), [1021740](https://bugs.launchpad.net/glance/+bug/1021740): Admins can now share images regardless of ownership or existing sharing permissions.\n\n## Show me the Features!\n\n### Tenant-Specific Storage Locations in Swift\n\nThe ability to store image data in the image owner-specific locations has always been an interesting feature on our backlog as storing all users\' images in a single account is a no-go for some deployers. We ended up with a solution that is only implemented for Swift, but done in such a way that we can expand it easily during Grizzly.\n\nThe implementation adds a couple of configuration options: \n\n* `swift_store_multi_tenant`: this must be set to \'True\' to enable this feature (it defaults to \'False\'). \n* `swift_store_admin_tenants`: this is a list of tenants, referenced by id, that should be granted read and write access to all swift containers created by Glance.\n\nAssuming you configured \'swift\' as your `default_store` and you enable this feature as described above, images will be stored in a swift endpoint pulled from the authenticated user\'s service_catalog. The created image data will only be accessible through Glance by the tenant that owns it and any tenants defined in `swift_store_admin_tenants` that are identified as having admin-level accounts.\n\nSpecial thanks to Dan Prince of RedHat for tackling this feature!\n\nSee the [blueprint on launchpad](https://blueprints.launchpad.net/glance/+spec/swift-tenant-specific-storage).\n\n### Image Replication Tool\n\nAt the Folsom OpenStack Design Summit, we decided that the best first-run at image replication would be to write a simple python script that could talk to multiple Glance endpoints and sync images between them. During this release cycle, we developed the `glance-replicator` tool.\n\nIt is currently only available through [GitHub](http://github.com/openstack/glance/tree/master/bin/glance-replicator), but we hope to develop a better distribution method in Grizzly.\n\nOnce you have it installed, you should run the help command to determine specific usage: `glance-replicator help`. The tool already has a great list of features:\n\n* Replicate binary image data along with metadata\n  * Local replication will download image data to a local directory\n  * Live replication can circumvent local disk access\n* Compare Glance endpoints to see what images need to be replicated\n* Determine the effective size of a Glance endpoint\n* Prevent replication of specific metadata attributes\n* Provide separate authentication tokens for master and slave endpoints\n\nThanks a ton to Michael Still of Canonical for his fantastic work on this tool!\n\nSee the [blueprint on launchpad](https://blueprints.launchpad.net/glance/+spec/image-replication).\n\n### Database Driver Pluggability\n\nThe internal pythonic interface used to interact with sqlalchemy models, a.k.a. the database driver, has limited deployers and developers to using only the backends that sqlalchemy itself supported (MySQL, PostgreSQL, SQLite, etc.).\n\nThe database driver has been made pluggable using the `data_api` configuration option. A deployer of Glance can use the default sqlalchemy API, or one could specify any python module path that implements the same interface.\n\nThe in-memory database driver, referred to as the \'simple\' driver, has been promoted from a test helper to the first sqlalchemy alternative. It should only be used for testing and in extremely rare deployment configurations. It doesn\'t write anything to the local filesystem, so expect your data to be lost if you restart your services. It cannot share between services, so you are limited to a single glance-registry and glance-api process (the `workers` config must be 0). Additionally, data will not be shared between the v1 and v2 APIs.\n\nIf you are interested in writing a driver for your favorite backend, you can use the test suite defined in [glance/tests/functional/db/\\_\\_init\\_\\_.py](http://github.com/openstack/glance/tree/master/glance/tests/functional/db/__init__.py). See the test modules [test_simple](https://github.com/openstack/glance/blob/master/glance/tests/functional/db/test_simple.py) and [test_sqlalchemy](https://github.com/openstack/glance/blob/master/glance/tests/functional/db/test_sqlalchemy.py) in that same directory for an example of how to integrate with the tests. Unfortunately, the testing suite is incomplete and cannot yet guarantee complete interface compliance. The sqlalchemy api is the de facto standard as of now, but that responsibility will transition to the test suite in the Grizzly timeframe.\n\nSee the [blueprint on launchpad](https://blueprints.launchpad.net/glance/+spec/refactor-db-layer).\n\n### Store Driver Pluggability\n\nSimilar to how the database driver was made pluggable, the list of available image store drivers has been pushed into a configuration option `known_stores`:\n\n    known_stores = \n        glance.store.filesystem.Store,\n        glance.store.http.Store,\n        glance.store.rbd.Store,\n        glance.store.s3.Store,\n        glance.store.swift.Store,\n\nIf you want to write an additional store driver, you can implement the interface defined by the base class in `glance.store.base.Store` and append the pythonic path of your store class to the `known_store` option. Feel free to use that base class as your super class and define the methods that raise `NotImplementedError`, or write your own from scratch.\n\nTesting is not as straightforward at the moment, so please refer to the [files here](https://github.com/openstack/glance/tree/master/glance/tests/functional/v1) for reference.\n\nThanks to Josh Harlow of Yahoo for making this happen!\n\nSee the [blueprint on launchpad](https://blueprints.launchpad.net/glance/+spec/import-dynamic-stores).\n\n\n## What about Grizzly?\n\nWhile plans are far from being solidified for the next release cycle, I can throw a few teasers out there:\n\n* **Protected Properties**: Deployers will be able to set read/write permissions on individual image properties.\n* **Privileged Services**: Glance endpoints should be able to identify trusted clients (like Nova, Cinder or Horizon) and respond with additional information.\n* **Domain Objects**: The internal APIs of Glance have never been well-defined. We hope to create a proper domain object layer to help minimize code repetition in the API controllers and database drivers.\n* **Images API v2.1+**: Image sharing will make its way into the v2 API, along with several other yet-to-be finalized features.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120821/edfb72fa/attachment-0001.html>\n\n',NULL,NULL),('<0D7BE083-7BC3-4F39-A0F3-9CE6F5C94BA5@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 21:36:48',0,'2014-05-23 21:36:48',NULL,'[openstack-dev] [Neutron] Seeking opinions on scope of\n	code	refactoring...','\nOn May 23, 2014, at 3:35 PM, Robert Kukura <kukura at noironetworks.com> wrote:\n\n> \n> On 5/23/14, 3:07 PM, Paul Michali (pcm) wrote:\n>> Thanks for the comments Gary!\n>> \n>> Typically, the device driver (backend) and service driver, for a provider won?t have any database requirements (at least for VPN). For the Cisco VPN, the service driver has one additional table that it maintains for mapping, but even in that case, there is no modification to the built in tables for the VPN plugin.\n> If these sorts of additional tables might use foreign keys, cascaded deletes, etc., it probably make sense to go with the precommit approach to make these explicitly part of the transactions.\n\nHi Bob,\n\nIn the Cisco case, it is a single table that has a key that is the IPSec site-to-site connection UUID, and then two numerical ID fields that are used to map OpenStack IPSec and IKE policy IDs to Cisco CSR ID numbers (they don?t support UUIDs). It?s the only table I?ve come across so far, so, not a common thing.\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n> \n> -Bob\n>> \n>> So, the action is validation, persist, apply, with the validation possibly having a provider override/extend, the apply always having a provider action, and the persistence always being the ?core? persistence.  It?s a question of being validate, persist/commit, apply, or pre-commit, commit/persist, post-commit, for naming.\n>> \n>> Regards,\n>> \n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pcm_ (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> On May 23, 2014, at 12:40 PM, Gary Duan <garyduan at gmail.com> wrote:\n>> \n>>> Hi, Paul,\n>>> \n>>> If the backend driver maintains its own database, I think the pre_commit and post_commit approach has an advantage. The typical code flow is able to keep the driver and plugin database consistent.\n>>> \n>>> Regarding question 1, where validation methods should be added, I am leaning towards A, but I also agree validation hooks can be added later when they are needed. It\'s more important to get provider and flavor logic officially supported for services.\n>>> \n>>> Thanks,\n>>> Gary\n>>> \n>>> \n>>> \n>>> On Fri, May 23, 2014 at 7:24 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>> Hi,\n>>> \n>>> I?m working on a task for a BP to separate validation from persistence logic in L3 services code (VPN currently), so that providers can override/extend the validation logic (before persistence).\n>>> \n>>> So I?ve separated the code for one of the create APIs, placed the default validation into an ABC class (as a non-abstract method) that the service drivers inherit from, and modified the plugin to invoke the validation function in the service driver, before doing the persistence step.\n>>> \n>>> The flow goes like this?\n>>> \n>>>     def create_vpnservice(self, context, vpnservice):\n>>>         driver = self._get_driver_for_vpnservice(vpnservice)\n>>>         driver.validate_create_vpnservice(context, vpnservice)\n>>>         super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>>>         driver.apply_create_vpnservice(context, vpnservice)\n>>> \n>>> If the service driver has a validation routine, it?ll be invoked, otherwise, the default method in the ABC for the service driver will be called and will handle the ?baseline? validation. I also renamed the service driver method that is used for applying the changes to the device driver as apply_* instead of using the same name as is used for persistence (e.g. create_vpnservice -> apply_create_vpnservice).\n>>> \n>>> The questions I have is?\n>>> \n>>> 1) Should I create new validation methods A) for every create (and update?) API (regardless of whether they currently have any validation logic, B) for resources that have some validation logic already, or C) only for resources where there are providers with different validation needs?  I was thinking (B), but would like to hear peoples? thoughts.\n>>> \n>>> 2) I?ve added validation_* and modified the other service driver call to apply_*. Should I instead, use the ML2 terminology of pre commit_* and post commit_*? I personally favor the former, as it is more descriptive of what is happening in the methods, but I understand the desire for consistency with other code.\n>>> \n>>> 3) Should I create validation methods for code, where defaults are being set for missing (optional) information? For example, VPN IKE Policy lifetime being set to units=seconds, value=3600, if not set. Currently, provider implementations have same defaults, but could potentially use different defaults. The alternative is to leave this in the persistence code and not allow it to be changed. This could be deferred, if 1C is chosen above.\n>>> \n>>> Looking forward to your thoughts...\n>>> \n>>> \n>>> Thanks!\n>>> \n>>> PCM (Paul Michali)\n>>> \n>>> MAIL ?..?. pcm at cisco.com\n>>> IRC ??..? pcm_ (irc.freenode.com)\n>>> TW ???... @pmichali\n>>> GPG Key ? 4525ECC253E31A83\n>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>> \n>>> \n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/3690cfa0/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/3690cfa0/attachment.pgp>\n\n','<537FA2E5.6080006@noironetworks.com>',NULL),('<0d87a251ef541e1e5700787c6a816e96@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-09 12:31:43',10800,'2014-07-09 09:31:43',NULL,'[Openstack] Terminate Instance Error',' Every time I terminate an instance there is an error logged in nova \n compute log file.\n\n You can find it here: http://pastebin.com/KNRHqZJ5\n\n Could you let me know of what this is?\n\n Best,\n\n G.\n\n\n',NULL,NULL),('<0D8915066819A04C9BA55D308E550C740FCFDCD2@G9W0756.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2014-07-28 09:44:41',0,'2014-07-28 09:44:41',NULL,'[openstack-qa] Openstack nova,\n	cinder and neutron drivers are hardware agnostic?','Hi All,\n\nCan you please let me know if the default drivers(Nova libvirt (KVM) driver, Cinder LVM drive and Neutron default driver) of OpenStack are hardware agnostic or dependent on a particular hardware?\n\nAlso can you please let me know which category of tempest tests to run to exercise the sanity of these drivers?\n\nThanks,\nAshraf\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20140728/c663a505/attachment.html>\n\n',NULL,NULL),('<0D8915066819A04C9BA55D308E550C740FD17C4B@G9W0756.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-11 08:21:23',0,'2014-08-11 08:21:23',NULL,'[Openstack] Wordpress template','See if this is helpful for you.\nhttps://github.com/openstack/tempest/blob/master/tempest/api/orchestration/stacks/templates/neutron_basic.yaml\n\nThanks,\nAshraf\n\n\n-----Original Message-----\nFrom: yalla.gnan.kumar at accenture.com [mailto:yalla.gnan.kumar at accenture.com] \nSent: Monday, August 11, 2014 12:58 PM\nTo: clint at fewbar.com; openstack at lists.openstack.org\nSubject: Re: [Openstack] Wordpress template\n\nHi All,\n\nI need help in mentioning the networks in the wordpress template downloaded from the below link:\n\nhttps://raw.github.com/openstack/heat-templates/master/cfn/F17/WordPress_Composed_Instances.template\n\n\nThanks\nKumar\n\n-----Original Message-----\nFrom: Clint Byrum [mailto:clint at fewbar.com]\nSent: Friday, August 08, 2014 7:07 PM\nTo: openstack\nSubject: Re: [Openstack] Wordpress template\n\nYou\'ll find documentation for the OS::Nova::Server resource here:\n\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server\n\nSo you\'ll need to add this to the properties section:\n\n    properties:\n      networks:\n        - { network: public }\n        - { network: private }\n\nExcerpts from yalla.gnan.kumar\'s message of 2014-08-08 06:01:48 -0700:\n> Hi All,\n>\n> Please let me know if anybody knows how to troubleshoot this issue.\n>\n>\n> Thanks\n> Kumar\n>\n> From: Gnan Kumar, Yalla\n> Sent: Friday, August 08, 2014 10:46 AM\n> To: openstack at lists.openstack.org\n> Subject: Wordpress template\n>\n> Hi All,\n>\n> I am trying to launch an instance with wordpress application from the \n> heat  template downloaded from \n> https://raw.github.com/openstack/heat-templates/master/cfn/F17/WordPre\n> ss_Composed_Instances.template\n>\n> But the following error is being shown:\n>\n> Error: Resource CREATE failed: BadRequest: Multiple possible networks found, use a Network ID to be more specific.\n>\n> I have created two networks . One is public for floating point IP and \n> other is private. How to specify the network ID in the above  template ?\n>\n>\n>\n>\n> Thanks\n> Kumar\n>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<67765C71374B974FBFD2AD05AF438EFF0BDEB2D5@048-CH1MPN3-361.048d.mgd.msft.net>',NULL),('<0D8B23A03C084AC08379AA157E8214AB@canonical.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-12 15:43:12',28800,'2014-11-12 07:43:12',NULL,'[Openstack] [zaqar]: ask for latest development info about zaqar','https://wiki.openstack.org/wiki/Zaqar  \n\nBest regards,\n--  \nKevin Huang ???\n\n\nOn Wednesday, November 12, 2014 at 14:13, DUAN Kevin wrote:\n\n> Hi All,\n>   \n> I am working in openstack cloud delivery and looking for zaqar MaaS support.  \n>   \n> Is this the correct mail list for looking for zaqar support? If not, could anyone direct me to the right mailing list?\n>   \n> Thanks,\n> Kevin  \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to : openstack at lists.openstack.org (mailto:openstack at lists.openstack.org)\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>  \n>  \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141112/68f5c77e/attachment.html>\n\n','<37ADB4C1E865AE47A895BB9E0C72D27B3757C94F@CNSHJMBX04.ad4.ad.alcatel.com>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70973F492@FSI-EX4.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2012-09-12 09:21:24',0,'2012-09-12 09:21:24',NULL,'[openstack-community] About Creation of  OpenStack User Group','Dear Sir / Madam,\n\nI would like to know how I can create one more User Group in same region?\nI would appreciate a reply at your earliest convenience.\n\nBest Regards,\nBruce Lok\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\nTel: 3166-3728\nFax: 3027-0099\n\n\n\n\nPlease don\'t print this e-mail unless you really need to\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120912/59df7dd0/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C709740004@FSI-EX4.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2012-09-18 09:08:23',0,'2012-09-18 09:08:23',NULL,'[openstack-community] New Hong Kong OSUG Created','To: Community Manager / All List Members of OpenStack User Group\n\nDear Sir / Madam,\n\nThis is Bruce Lok, from Hong Kong Cyberport Management Company Limited (\"Cyberport\").  The Cyberport which is wholly owned by Hong Kong SAR Government, is actively introducing OpenStack to Hong Kong Community.  We have already created a Hong Kong OpenStack User Group (HKOSUG)<https://groups.google.com/d/forum/hong-kong-cloud-technology-sig> in order to discussing and promoting the OpenStack and cloud technology / trends for Hong Kong community.\n\nThe Cyberport is now going to Introduce and promote the Open source cloud software: OpenStack into Hong Kong ICT community, especially for the small and medium enterprises.  The 1st meet-up called \"Startups Connect: Ubuntu Cloud with OpenStack<http://www.cyberport.hk/en/home/about_cyberport/our_5_centres/entrepreneurship_centre/about_ec_news_events/677>\" which is a co-organized event with Canonical Ubuntu, will be held on 28 September 2012 at Hong Kong Cyberport.  Please visit our HKOSUG<https://groups.google.com/d/forum/hong-kong-cloud-technology-sig> for more upcoming events about OpenStack and Cloud related news in Hong Kong.\n\nWe look forward to a successful working relationship with all OpenStack User Group in the future.\n\nRegards,\nBruce Lok\nHong Kong OpenStack User Group (HKOSUG)<https://groups.google.com/d/forum/hong-kong-cloud-technology-sig>\nHong Kong Cyberport Management Co. Ltd.\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120918/a7d4e487/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C709740AD0@FSI-EX4.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2012-09-24 01:33:55',0,'2012-09-24 01:33:55',NULL,'[openstack-community] The 1st OpenStack Event in Hong Kong','Dear all,\n\nI am pleased to announce that Hong Kong Cyberport will held the 1st Hong Kong OSUG event which is bring Canonical Ubuntu<http://www.ubuntu.com/> to town to give a talk on \"Ubuntu Cloud with OpenStack \"<http://www.cyberport.hk/en/home/about_cyberport/our_5_centres/entrepreneurship_centre/about_ec_news_events/677> on 28 September 2012 (Friday)\n\nThe detail of event can be found at:\nhttp://www.cyberport.hk/en/home/about_cyberport/our_5_centres/entrepreneurship_centre/about_ec_news_events/677\n\nYours sincerely,\nBruce Lok\nHKOSUG Coordinator\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\n\n\n\n\n[Description: Description: Description: Description: https://lh5.googleusercontent.com/-Lj4yANbc54g/UFgfvXDDmTI/AAAAAAAABn4/cftp_UmCV6k/s800/edm%2520visual-1.jpg]\n\n\n\n\n\nUbuntu is the leading cloud computing operating system, based on OpenStack, the most fast growing open source cloud platform, to help enterprises build their private and public cloud. This session will give you an overview of Ubuntu, OpenStack and the technology to deploy workload on cloud platform.\n\nEvent Details:\nDate:\n\n28 September 2012 (Friday)\n\nTime:\n\n12:30-14:00\n\nVenue:\n\nEntrepreneurship Centre, Unit 518, Cyberport 3 (Core F), 100 Cyberport Road, Cyberport\n\nLanguage:\n\nEnglish\n\nFee:\n\nFree-of-charge (with light lunch)\n\n\n\nAbout Speaker:\n\n[Description: Description: Description: Description: Description: https://lh6.googleusercontent.com/-WqhL0_FjDfU/T0Sr7l6XWOI/AAAAAAAABRE/1GS1Gy0_XQg/I/Mak%252520Danny.JPG]\n\n\nShang Wu has been with Canonical for more than 5 years and is responsible for the technical side of the cloud opportunity in the APAC region.\n\n\nTargeted Participants:\nIncubatees, Alumni, CCMF Grantees and ICT startups\n\nTo Register\n\nIf you are interested, please click HERE<http://openclass.hk/activity/ecform/1435?lang=en> for registration.\n\n\n\n\nFor enquiry, please contact\nTel :        +852-3166 3902\nEmail :   ecentre at cyberport.hk<mailto:ecentre at cyberport.hk>\n\n\n\n\n\nContact Us<mailto:ecentre at cyberport.hk> - Unsubscribe<mailto:ecentre at cyberport.hk> - Disclaimer<http://www.cyberport.hk/campaign/cyberlink/disclaimer.html>\n\nCyberport Entrepreneurship Centre, Unit 518, Cyberport 3 (Core F), 100 Cyberport Road, Hong Kong\nTel : +852 3166 3900 Fax : +852 3166 3027\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nPlease don\'t print this e-mail unless you really need to\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120924/867869e5/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 908396 bytes\nDesc: image001.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120924/867869e5/attachment-0002.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.jpg\nType: image/jpeg\nSize: 4073 bytes\nDesc: image002.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20120924/867869e5/attachment-0003.jpg>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C709812CAA@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-01-15 02:12:14',0,'2013-01-15 02:12:14',NULL,'[openstack-community] Calling all user group and meetup\n organizers','Hi,\nI am sorry that I may not able to join the meeting but the Hong Kong OpenStack User Group and Hong Kong Cyberport will be updating you any information if necessary.\n\nMay I have a bit comment on the following agenda:\n\nCan the Foundation start working with some Universities for meeting space, sponsorship, and student participation? Is the Foundation interested in Phd thesis sponsorship\nI strongly agree on this point, since there is getting more university students and researchers who starts to explore the open source cloud softwares as most commercial cloud softwares/services on market are really expensive for them to get start.   Also, university students and researchers are usually more sincere to explore the open source software because it is free and cloud computing is quite new for them.  And this is a good starting point to educate them to contribute to open source stuffs rather than just using it as freeware.\n\nShould there be an OpenStack user group and/or meetup approval process? How do we clean up user groups and meetups that are abandoned?\nI think there must be have an official central coordinator to manage all the user groups.\n\nThank you for the attention, and wish you all the best in year 2013.\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\nTel: +852 3166-3728\nFax: +852 3027-0099\n\n\nFrom: Sean Roberts [mailto:seanrob at yahoo-inc.com]\nSent: Tuesday, 15 January, 2013 07:26\nTo: OpenStack community; openstack\nCc: Rob_Hirschfeld at Dell.com; Kamesh_Pemmaraju at dell.com; Andi_Abes at dell.com; trevor.lowing at gmail.com; stephon.striplin at dreamhost.com; carlp at hq.newdream.net; brent.scotten at rackspace.com; kmestery at cisco.com; lloydostack at gmail.com; freedomhui at gmail.com; duyujie.dyj at gmail.com; santiagoc120 at outlook.com; sc360 at kent.ac.uk; mohamed at egyptcloudforum.com; Ilkka.Turunen at jamk.fi; berendt at b1-systems.de; Bruce Lok; marton.kiss at xemeti.com; deepakgarg.iitg at gmail.com; frans at meruvian.org; tim.horgan at cit.ie; fenris at ubuntu.com; mypapit at gmail.com; muharem at lbox.cc; hang.tran at dtt.vn\nSubject: Re: [openstack-community] Calling all user group and meetup organizers\n\nAgenda for tomorrow\'s user group / meetup planning meeting\n\n  *\n  *   Review of user group and meetup template\n  *   Meetups fit into the larger plan of user committee and summit to summit development how?\n  *   Where would be the location for social materials like videos, meetup logs, and other meeting related items?\n  *   Where do operators go to figure out how to run OpenStack in production?\n  *   Can the Foundation start working with some Universities for meeting space, sponsorship, and student participation? Is the Foundation interested in Phd thesis sponsorship?\n  *   If possible I like to get some supporters for a groups.openstack.org site, including content writers and some developer resources from the community. We have a lot of knowledge about running / starting an user group, and need to write it down, publish on the site and share it with newcomers.  I think this is answered by the user group template information that will be published to http://wiki.openstack.org/OpenStackUserGroups.\n  *   Should there be an OpenStack user group and/or meetup approval process? How do we clean up user groups and meetups that are abandoned?\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/14/13 2:07 PM, \"Sean Roberts\" <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\nReminder for the global user group planning meetup, tomorrow, Tuesday, 15 Jan 2012 11:00am to 1:00pm PST  http://www.meetup.com/openstack/events/93593062/\nJoin us!\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/9/13 1:05 PM, \"Tim Horgan\" <tim.horgan at cit.ie<mailto:tim.horgan at cit.ie>> wrote:\n\nHi S?an,\n\nI run the OpenStack Ireland meetup group, just wondering if your meeting is targeting only groups in the East Coast of the USA?\n\nKind Regards,\nTim\n\nOn 9 Jan 2013, at 00:54, Sean Roberts <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\n\nWe are going to have a planning meeting on Tuesday, 15 Jan 2012 11:00am to 1:00pm PST. RSVP via  http://www.meetup.com/openstack/events/93593062/  Connect remotely via webex https://yahoomeetings.webex.com/yahoomeetings/j.php?ED=160663792&UID=492396097&RT=MiM0\nIf this time doesn\'t work for you, get ahold of me directly via skype:seanroberts66, email, mobile, irc:sarob, twitter:sarob, or carrier pigeon.\n\nStefano and Thierry will be joining us. I want to get input from people that run user groups and meetups.\n\nSee you then!\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org<mailto:Community at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\nRegards,\nTim\n\n\n---------------------------------------------------------------------------------------------\nTIM HORGAN\nHead of Cloud Computing Centre of Excellence\nExtended Campus Office\nCork Institute of Technology, Cork, Ireland\nphone: +353 214335120<callto:+353%2021%204335120> | mobile: +353 87 9439333<callto:+353%2087%209439333>\ntwitter: @timhorgan<https://twitter.com/#%21/timhorgan> | skype: timothy.horgan<https://twitter.com/#%21/timhorgan>\nlinkedin: http://ie.linkedin.com/in/timhorgan | web: http://cloud.cit.ie<http://cloud.cit.ie/>\n---------------------------------------------------------------------------------------------\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130115/cbbb7647/attachment-0001.html>\n\n','<CD19D324.8FEDB%seanrob@yahoo-inc.com>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70995F6AC@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-16 00:59:52',0,'2013-04-16 00:59:52',NULL,'[openstack-community] Quantum installation guide for CentOS','Install OpenStack in CentOS\nhttps://wiki.openstack.org/wiki/NovaInstall/CentOSNotes\n\nOpenStack Install and Deploy Manual - Red Hat/CentOS\nhttp://docs.openstack.org/folsom/openstack-compute/install/yum/content/\n\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nEngineer of Hong Kong Cyberport\n\n\nFrom: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\nSent: Tuesday, 16 April, 2013 08:52\nTo: community at lists.openstack.org\nSubject: [openstack-community] Quantum installation guide for CentOS\n\nHi All,\n\nI\'m new to Openstack quantum...just wondering if Quantum is supported on CentOS? If so, is there documentation for installing Quantum server on CentOS?\n\nThanks,\n\nYuLing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130416/d2187511/attachment.html>\n\n','<00B180B44D70DB429A492069FDE633373F9425E47E@AUSX7MCPC109.AMER.DELL.COM>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C709965F0F@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-06 02:05:00',0,'2013-05-06 02:05:00',NULL,'[openstack-community] “I” release cycle naming with Hong Kong','Hi Stefano,\nHere are my suggestion, I will keep updating to you about the suggestion of release name.\n\niSQUARE\n(Chinese<http://en.wikipedia.org/wiki/Traditional_Chinese_characters>: ????) is a 31-story high shopping mall located at 63 Nathan Road<http://en.wikipedia.org/wiki/Nathan_Road>, Tsim Sha Tsui<http://en.wikipedia.org/wiki/Tsim_Sha_Tsui>, Kowloon<http://en.wikipedia.org/wiki/Kowloon>, Hong Kong<http://en.wikipedia.org/wiki/Hong_Kong>, on the former site of the Hyatt Regency Hotel<http://en.wikipedia.org/wiki/Hyatt_Regency_Hong_Kong,_Tsim_Sha_Tsui>. It was developed by Associated International Hotels Ltd.\nhttp://en.wikipedia.org/wiki/ISQUARE\n\nIFC\nThe International Finance Centre (abbr. IFC, branded as \"ifc\") (Chinese<http://en.wikipedia.org/wiki/Traditional_Chinese_characters>: ??????) is an integrated commercial development on the waterfront of Hong Kong\'s Central District<http://en.wikipedia.org/wiki/Central_and_Western_District>, is a prominent landmark on Hong Kong Island,\nhttp://en.wikipedia.org/wiki/International_Finance_Centre\n\nICC\nThe International Commerce Centre (Chinese<http://en.wikipedia.org/wiki/Traditional_Chinese_characters>: ??????) (abbr. ICC Tower) is a 118-storey<http://en.wikipedia.org/wiki/Storey>, 484 m (1,588 ft)skyscraper<http://en.wikipedia.org/wiki/Skyscraper> completed in 2010 in West Kowloon<http://en.wikipedia.org/wiki/West_Kowloon>, Hong Kong<http://en.wikipedia.org/wiki/Hong_Kong>. It is a part of the Union Square<http://en.wikipedia.org/wiki/Union_Square_(Hong_Kong)> project built on top of Kowloon Station<http://en.wikipedia.org/wiki/Kowloon_Station>.\nhttp://en.wikipedia.org/wiki/International_Commerce_Centre\n\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\nTel: 3166-3728\nFax: 3027-0099\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130506/57040db8/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C7099813A5@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-11 03:20:49',0,'2013-07-11 03:20:49',NULL,'[openstack-community] Pre & Post Summit events in Asia','Hi All,\nThank you for the great help from OpenStack Foundation.\nThe HKOSUG organized by Hong Kong Cyberport will surely provide assistances in some way for the Summit, also we will organize a networking reception at Hong Kong Cyberport campus before or after the Summit in order to drive the OpenStack adoption into Asia ICT community. \n\nRegards,\nBruce Lok\nCoordinator of Hong Kong OpenStack User Group (HKOUSG)\nHong Kong Cyberport Management Co. Ltd.\n\n\n-----Original Message-----\nFrom: Tom Fifield [mailto:tom at openstack.org] \nSent: Thursday, 11 July, 2013 11:11\nTo: community at lists.openstack.org\nSubject: [openstack-community] Pre & Post Summit events in Asia\n\nHi all,\n\nI hope you\'re excited for our upcoming summit in Hong Kong :)\n\nOne of the ideas that has been floating around is that since we\'ll have an incredible mass of OpenStack expertise in the area for the summit, why don\'t we try and arrange some events in Asia before and afterward?\n\nThis will mean that those multitudes in the region who can\'t make it to the summit can get exposure to the experts, and that leads to increased contributions and encourages global collaborations.\n\nOf course, organising this is going to take some work, and it needs to happen quite soon - as people are booking flight tickets early to get the best deal.\n\nWhat do you think about this idea? Will your group help organise an event? How do you think is the best way to make it work?\n\n\nRegards,\n\n\nTom\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n','<51DE2254.9020604@openstack.org>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70998175B@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-11 11:56:37',0,'2013-07-11 11:56:37',NULL,'[openstack-community] Pre & Post Summit events in Asia','Hi Yoyo,\nYou are welcomed to Hong Kong.  I really want to meet you guys in the Summit.\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\n\n________________________________\nFrom: Yoyo Chiang [yoyochiang55 at gmail.com]\nSent: Thursday, July 11, 2013 4:44 PM\nTo: Tom Fifield\nCc: community at lists.openstack.org\nSubject: Re: [openstack-community] Pre & Post Summit events in Asia\n\nAlthough we (Taiwan) would like to see more experts coming, but we will encourage our members to join HK summit at first... since it\'s the closest one we have had^^\n\nCheers,\n\nYoyo\n\n2013/7/11 Tristan Goode <tristan at aptira.com<mailto:tristan at aptira.com>>\nThis is a great idea and I\'d be happy to organise event(s) in Australia pre or post Summit.\n\nWe need to seek volunteers from the \"expertise pool\" that would like to do this, and possibly make it attractive with the help of some airfare/accommodation benefit (Foundation or sponsor contributed) that the person is free to extend or alter at their own expense, (ie they can get a quick holiday in).\n\n\nOn 11 July 2013 13:11, Tom Fifield <tom at openstack.org<mailto:tom at openstack.org>> wrote:\nHi all,\n\nI hope you\'re excited for our upcoming summit in Hong Kong :)\n\nOne of the ideas that has been floating around is that since we\'ll have an incredible mass of OpenStack expertise in the area for the summit, why don\'t we try and arrange some events in Asia before and afterward?\n\nThis will mean that those multitudes in the region who can\'t make it to the summit can get exposure to the experts, and that leads to increased contributions and encourages global collaborations.\n\nOf course, organising this is going to take some work, and it needs to happen quite soon - as people are booking flight tickets early to get the best deal.\n\nWhat do you think about this idea? Will your group help organise an event? How do you think is the best way to make it work?\n\n\nRegards,\n\n\nTom\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org<mailto:Community at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org<mailto:Community at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130711/de7c5425/attachment.html>\n\n','<CAHS404qtPnz3SHUeZQFoWrBhv7e5j9DJu=J9Fv-68+Lc7uk3BQ@mail.gmail.com>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70DAB376D@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-30 01:36:00',0,'2013-07-30 01:36:00',NULL,'[openstack-community] Ask OpenStack - what to do with Orphaned\n Questions','Hi Stefano,\nYes, I agree to retain those unanswered/orphaned questions but we may need to review it first.\n\nThat means it may be necessary to review whether the question is commonly understandable, clear enough, up to date; \nIf not, message to askers to take some actions to edit it more clear.\nIf there are no response from askers or the question is no value to the community, the said questions can be closed or classified as new category \'Abandoned\'\n\nRegards,\nBruce Lok\nHKOSUG\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\n\n\n-----Original Message-----\nFrom: Stefano Maffulli [mailto:stefano at openstack.org] \nSent: Tuesday, 30 July, 2013 05:40\nTo: community at lists.openstack.org\nSubject: Re: [openstack-community] Ask OpenStack - what to do with Orphaned Questions\n\nOn 07/26/2013 05:48 PM, Tom Fifield wrote:\n> In order to retain the usefulness of Ask for searching and listing \n> questions (especially enabling people to find unanswered questions to \n> answer), should we be closing these style of questions after a certain \n> time period?\n\nI\'ve been thinking about this and at the moment the conclusion I came to is not to close these sort of questions. Orphaned questions, that is, questions where the person asking originally has disappeared, can always be edited by others, they can be voted up and in general may provide a way to engage with the community more if they are left open than if they\'re closed.\n\nWhat may be a better way to deal with the problem of questions that cannot be answered because the person asking doesn\'t respond is to publish requests for debugging details in the answer. This will trigger the periodic reminders to accept the best answer (a feature currently disabled but that we can activate). We can define how many reminders to send to accept the best answer (default is 5) and the frequency (default every 3 days).\n\nThe partial answer (like \"try this and let us know\") is better than no answer at all and may help others in the future with similar issues.\n\nWhat do you think?\n/stef\n\n--\nAsk and answer questions on https://ask.openstack.org\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n','<51F6E13D.2080609@openstack.org>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70DABBE48@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-08-20 07:14:00',0,'2013-08-20 07:14:00',NULL,'[openstack-community] Introducing the OpenStack Ambassador\n Program','Hi Tom,\nHow many ambassadors will be selected in one region? (eg: Hong Kong)\n\nRegards,\nBruce Lok\nEngineer | Technology Centre\nHong Kong Cyberport Management Co. Ltd.\nTel: 3166-3728\nFax: 3027-0099\n\nFrom: Tom Fifield [mailto:tom at openstack.org]\nSent: Tuesday, 20 August, 2013 08:06\nTo: community at lists.openstack.org\nSubject: [openstack-community] Introducing the OpenStack Ambassador Program\n\n(This just went up at: http://www.openstack.org/blog/2013/08/ambassador-program/)\n\nI\'m excited to start the discussion on the formation of an OpenStack Ambassador Program, which aims to create a framework of community leaders to sustainably expand the reach of OpenStack around the world.\nWhy we\'re doing this\nOpenStack is one of the fastest-growing open source projects and communities in history. We are fortunate to have more than fifty user groups globally and many passionate community members who are already making a big impact. We would like to recognize and further empower these community members to achieve the OpenStack mission, as well as provide more structure and resources to the growing community and user groups.\nIn addition, the Foundation has become aware that there\'s a need to improve the relationship between user groups and itself - allowing everyone to feel like they\'re part of a globally connected community. For example, many of you who\'ve been to user group meetups have probably heard feedback from people trying to deploy OpenStack - it would be excellent to aggregate this feedback from every group to help make our software and community better.\nHow will this work?\nWe aim to select - initially - a small number of OpenStack Ambassadors, asking volunteers who are already respected members of our communities to be the primary point of contact in a particular region.\nWhat will the ambassadors do?\n\n  *   Act as a liason between user groups, the Foundation, and the general community, for example:\n\n  *   helping to solicit feedback on OpenStack and aggregate it to the global level\n\n  *   promoting key messages into the user communities (eg \"ask questions on ask.openstack.org!\")\n\n  *   finding people to help localise content\n\n  *   helping onboard new users and contributors\n\n  *   Assist in user group best practice - from nurturing new groups to cementing the quality of existing ones\n\n  *   Help people find the \'right people\' to talk to\n\n  *   Represent the community via speaking and visibility opportunities with the official title\n\n  *   Report on the activities in their region\n\n  *   Be a good leader, wranging activity from others and mobilising the global OpenStack community!\n\nWho will the Ambassadors be?\nThe title is designed to recognise those who are already good leaders with a proven track record in the community. With the title, new users, contributors and community members should easily be able to recognize their Ambassador as a go-to resource. While the role provides inherent credibility, it also comes with accountability, meaning decisions and actions made by the Ambassador should benefit the whole community, not just one person or company.\nWe believe that the Ambassadors will already be active participants in our community. Think about those people who are already working across multiple user groups, submitting OpenStack mini-events to related conferences, helping onboard new users and contributors, arranging hackfests or just generally going above and beyond in the name of making Openstack great.\nTo that end, we intend to ask that potential ambassadors provide some information about themselves, namely:\n\n  *   Why are you applying to become an OpenStack Ambassador?\n\n  *   How have you participated in the OpenStack Community to date?\n\n  *   What ideas do you have for your community, that you wish you had time or resources to implement?\nA small number of ambassadors will then be selected based on a set of criteria:\n\n  *   Community participation track record\n\n  *   Geographical location\n\n  *   Potential impact of selection on community\n\n\n\nYour feedback would be excellent! Please leave a reply below. Also: for more specifics on the program, and information about becoming an ambassador, stay tuned for the next post.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130820/068fb2c6/attachment-0001.html>\n\n','<5212B2ED.1000103@openstack.org>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C70DAC5177@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-05 07:43:03',0,'2013-09-05 07:43:03',NULL,'[openstack-community] User Groups: Balancing new and\n experienced	users','Hi guys\n\n\n\nI suggest to launch a Startup resource website with more interesting graphical and simpler contents, may be in Comic style / flash games, which introduce what the OpenStack is and provide startups a standard & easy-understood steps to build a simple OpenStack private cloud. This resource page should also provide in different languages, community leader or coming ambassadors should able to coordinate the languages translation.\n\n\n\nSecondly, we should focus more examples of running applications on OpenStack Private/Public Cloud, covering more business industries, eg: digital entertainment, sales, education, e-marketing, social media, Apps games, and so on.  It is because most of them are carved know to how OpenStack private cloud can be used/applied in their businesses/industries, or improve their running applications or services.\n\n\n\nI have been questioning by some IT guys from different industries, which they have same questions about how OpenStack private cloud can improve their existing server infrastructure and running applications.  Even they have a lot of servers,\n\n*         They do not know how to get start,\n\n*         contents is not centralized and not user-friendly enough to learn or take reference,\n\n*         There is no official-like support in their region\n\n\n\nI have a closed client whom their business is SME, doing digital entertainment and 3D educational games for environment protection. I took almost 2 years to persuade them to change their existing server infrastructure into OpenStack private cloud because they do not how to begin their OpenStack journey.  Obviously OpenStack is very useful and cost-effective for SMEs.  However, there is lack of local support.\n\n\n\nFinally we should an internal training material and resources for community leaders of user groups to conduct standard introduction, familiarization session or training workshops to their region.\n\n\n\nRegards,\n\nBruce Lok\n\nCoordinator of HKOSUG\n\n\n\n-----Original Message-----\nFrom: Tom Fifield [mailto:tom at openstack.org]\nSent: Monday, 02 September, 2013 08:01\nTo: community at lists.openstack.org\nSubject: [openstack-community] User Groups: Balancing new and experienced users\n\n\n\nWith the massive growth of OpenStack, so too have our user groups grown.\n\nNot just in number, or attendance, but also in their skill at delivering material at varying levels of complexity.\n\n\n\nWith this, I felt it was high time we started a discussion on how best to continue to support those attendees just beginning their OpenStack journey while satisfying the needs of the burgeoning number of more advanced users.\n\n\n\nIn talking with the user group leaders around the world, I\'ve heard many different techniques. From running simultaneous parallel topic streams, alternative monthly sessions, or having a \'n00b\' hour prior to the start of the main event.\n\n\n\nI\'m keen to hear your ideas. What do you do to manage the different levels of achievement of those in your community? Do you have content?\n\nWhat would you like to see?\n\n\n\nLooking forward to your thoughts,\n\n\n\nTom\n\n\n\n_______________________________________________\n\nCommunity mailing list\n\nCommunity at lists.openstack.org<mailto:Community at lists.openstack.org>\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130905/54c56e8e/attachment.html>\n\n','<5223D547.3020004@openstack.org>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DEF1B47@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-16 04:13:13',0,'2013-09-16 04:13:13',NULL,'[openstack-community] China & HK OpenStack User Group Meet-up\n	(4-Nov)','Hi,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nWe will have world-class cloud technology pioneers and OpenStack experts talking about the latest in OpenStack, see what the future holds for them and for you, and learn the ins and outs of deploying cloud solutions on the open source cloud platform.\n\nEvent page: http://osug.cyberport.hk\nDate: 4 November 2013\nTime:\n15:00 - 17:00 (Presentation)\n17:00 - 20:00 (Cocktail Networking Reception)\nVenue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130916/7994789f/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DEF4C7E@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-23 05:49:53',0,'2013-09-23 05:49:53',NULL,'[openstack-community] China & HK OpenStack User Group\n	Meet-up	(4-Nov)','Hi,\nThe event page \"China and Hong Kong OpenStack User Group\" at http://osug.cyberport.hk<http://osug.cyberport.hk/> is now ready for registration.  The event is free and followed by a cocktail networking reception with OpenStack Foundation staffs.\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nHong Kong Cyberport Management Co. Ltd.\n\n\nFrom: Bruce Lok [mailto:brucelok at cyberport.hk]\nSent: Monday, 16 September, 2013 12:13\nTo: community at lists.openstack.org\nSubject: [openstack-community] China & HK OpenStack User Group Meet-up (4-Nov)\n\nHi,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nWe will have world-class cloud technology pioneers and OpenStack experts talking about the latest in OpenStack, see what the future holds for them and for you, and learn the ins and outs of deploying cloud solutions on the open source cloud platform.\n\nEvent page: http://osug.cyberport.hk\nDate: 4 November 2013\nTime:\n15:00 - 17:00 (Presentation)\n17:00 - 20:00 (Cocktail Networking Reception)\nVenue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130923/149d9b0a/attachment.html>\n\n','<0D8D9EBD1BBE224F8AEE23E5837A99C72DEF1B47@FSI-EX7.cyberport.hk>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DEFD2DE@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-04 08:42:52',0,'2013-10-04 08:42:52',NULL,'[openstack-community] Register Now! China & Hong Kong OpenStack\n User Group Meet-Up on 4 Nov @ Cyberport','If you cannot view it, please click here<http://osug.cyberport.hk/edm/en/index.html>\n\n[Description: http://osug.cyberport.hk/edm/en/images/edm_01.jpg]\n\n[Description: http://osug.cyberport.hk/edm/en/images/edm_02.jpg]\n\n[Description: http://osug.cyberport.hk/edm/en/images/edm_03.jpg]\n\n[Description: http://osug.cyberport.hk/edm/en/images/edm_04.jpg]\n\n[Description: http://osug.cyberport.hk/edm/en/images/edm_05.jpg]\n\n\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nHong Kong Cyberport Management Co. Ltd.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 110383 bytes\nDesc: image001.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0005.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.jpg\nType: image/jpeg\nSize: 193056 bytes\nDesc: image002.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0006.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.jpg\nType: image/jpeg\nSize: 88948 bytes\nDesc: image003.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0007.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image004.jpg\nType: image/jpeg\nSize: 94833 bytes\nDesc: image004.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0008.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image005.jpg\nType: image/jpeg\nSize: 52399 bytes\nDesc: image005.jpg\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131004/747272ec/attachment-0009.jpg>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DEFF0F9@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-07 01:14:28',0,'2013-10-07 01:14:28',NULL,'[Openstack] Register Now! China & Hong Kong OpenStack User Group\n Meet-Up on 4 Nov @ Cyberport','China & Hong Kong OpenStack User Group Meet-Up on 4 Nov @ Cyberport\n\nWelcome to the landing of the first OpenStack Summit in Hong Kong in the coming November 5-8. It is the first time that the Summit leaves the US and it has chosen Hong Kong as its destination. The OpenStack Summit is a signature event that gathers world-class and local leaders and experts in the open source community under one roof to discuss all things OpenStack.\n\nRiding on this remarkable occasion and the launch of the first community cloud in Hong Kong - the Cyberport Community Cloud - an OpenStack User Group Meet-up will be held by the China and Hong Kong OpenStack User Group prior to the Summit.\n\nThe meet-up will see renowned cloud technology pioneers and OpenStack experts discussing the latest in OpenStack. Topics include the architectural design of OpenStack, case studies on deploying OpenStack solutions, upgrade orchestrations, and the best approaches to identifying user requirements, profiling the user community and supporting ongoing user activities. You will learn the ins and outs of deploying cloud solutions on the open source cloud platform, and see what the future holds for them and for you.\n\n(* Followed by Cocktail Networking Reception)\n\nEvent page: http://osug.cyberport.hk<http://osug.cyberport.hk/>\nDate:     4 November 2013 (Mon)\nTime:     15:00-19:00\nVenue: Ocean View Court, The Arcade,  Hong Kong Cyberport<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\nLanguage: English / Putonghua (Simultaneous interpretation to Putonghua will be provided.)\n\nRegister NOW<http://osug.cyberport.hk/?section=Registration>\nFree Shuttle Bus Service will be provided, pick-up at Admiralty MTR Station, please register first.\n\n---------------------------\nBest regards,\nBruce Lok\nCoordinator of HKOSUG<https://groups.google.com/forum/#!forum/hong-kong-cloud-technology-sig>\nHong Kong Cyberport Management Co. Ltd.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131007/f9f2c744/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF06F62@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-11 01:15:33',0,'2013-10-11 01:15:33',NULL,'[openstack-community] Runners in Hong Kong?','Hi Dave,\n\nHong Kong is really good for hiking especially from November to January, there are a lot of country parks & trails.  It is also safe because sometimes you will see policeman are patrolling in country parks and they are very polite and good service!\n\nHere are some useful information to learn more about the country parks & trails in Hong Kong:\n\n1. http://www.hkwalkers.net/eng/index.htm (this one is also available for iPhone and Android phone)\n\n2. http://www.discoverhongkong.com/eng/see-do/great-outdoors/hikes/index.jsp \n\nFor Lantau Island, I recommend this two trails:\n\nNgong Ping Fun Trail\nhttp://www.hkwalkers.net/eng/trail_list/other_route/ngong_ping_fun/introduction.htm\n\nSouth Lantau Country Trail\nhttp://www.hkwalkers.net/eng/trail_list/country_trail/South_Lantau_Country_Trail/introduction.htm\n\nI want to join you but I am not sure at the moment.  Hope to seeing you in Hong Kong. \n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Co. Ltd.\n\n\n-----Original Message-----\nFrom: Dave Neary [mailto:dneary at redhat.com] \nSent: Friday, 11 October, 2013 00:09\nTo: community at lists.openstack.org\nSubject: [openstack-community] Runners in Hong Kong?\n\nHi all,\n\nI\'m getting ready for a race at the beginning of December and am planning to get in a couple of runs in the hills during the week of OpenStack Summit in Hong Kong - I\'ve been told the trails in Lantau are gorgeous, and well worth the effort.\n\nAnyone else interested in some early morning runs? I\'d be happy to have some company (you\'ll probably need a headlamp).\n\nCheers,\nDave.\n\n--\nDave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com\nPh: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n','<5256D0FF.4090308@redhat.com>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF081A1@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-13 15:54:45',0,'2013-10-13 15:54:45',NULL,'[openstack-community] China & HK OpenStack User Group Meet-up\n	(4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131013/04d8820d/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF081A1@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-13 15:54:45',0,'2013-10-13 15:54:45',NULL,'[Openstack] China & HK OpenStack User Group Meet-up (4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131013/04d8820d/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF11CD5@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-20 13:12:29',0,'2013-10-20 13:12:29',NULL,'[openstack-community] China & HK OpenStack User Group Meet-up\n	(4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131020/e7f96bf7/attachment.html>\n\n','<0D8D9EBD1BBE224F8AEE23E5837A99C72DF081A1@FSI-EX7.cyberport.hk>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF11CD5@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-20 13:12:29',0,'2013-10-20 13:12:29',NULL,'[Openstack] China & HK OpenStack User Group Meet-up (4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131020/e7f96bf7/attachment.html>\n\n','<0D8D9EBD1BBE224F8AEE23E5837A99C72DF081A1@FSI-EX7.cyberport.hk>',NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF166E4@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-26 03:34:31',0,'2013-10-26 03:34:31',NULL,'[openstack-community] Final Call: China & HK OpenStack User Group\n	Meet-up (4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131026/87a487b6/attachment.html>\n\n',NULL,NULL),('<0D8D9EBD1BBE224F8AEE23E5837A99C72DF166E4@FSI-EX7.cyberport.hk>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-26 03:34:31',0,'2013-10-26 03:34:31',NULL,'[Openstack] Final Call: China & HK OpenStack User Group Meet-up\n	(4-Nov)','Hello OpenStackers,\n\nCelebrating the remarkable OpenStack Summit 2013 in Hong Kong and the launch of the Cyberport Community Cloud, the OpenStack User Group Meet-up will be held prior to the Summit at Hong Kong Cyberport Campus\n\nIf you are coming to Hong Kong for the OpenStack Summit, we would like you and all members of your user group to spare some time and please join the meet-up & networking reception at Cyberport\n\n\n?         Event & Registration page: http://osug.cyberport.hk\n\n?         Date: Monday, 4 November 2013\n\n?         Time: 15:00 ? 17:30 (Meet-up), 17:30 ? 19:00 (Cocktail Networking Reception)\n\n?         Venue:  Hong Kong Cyberport Campus<http://www.cyberport.hk/en/about_cyberport/about_getting_here>\n\nThe meet-up is FREE!\nFree shuttle bus service will be provided, please kindly register first: http://osug.cyberport.hk/?section=Registration\nWe hope to see you guys there!\n\nRegards,\nBruce Lok\nCoordinator of HKOSUG\nHong Kong Cyberport Management Company Limited\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131026/87a487b6/attachment.html>\n\n',NULL,NULL),('<0D922CB9-9C0D-4FFC-A5C2-2E34EAA7850C@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-19 10:00:05',-28800,'2013-11-19 18:00:05',NULL,'[Openstack] Directional network performance issues with Neutron\n + OpenvSwitch','Yup :)\n\nOn 18 Nov 2013, at 22:09, Martinx - ????? wrote:\n\n> Guys,\n>\n> Can I fill a BUG about this issue?! If yes, where?! Neutron Launchpad \n> page?\n>\n> Tks,\n> Thiago\n>\n>\n> On 12 November 2013 04:24, Martinx - ????? \n> <thiagocmartinsc at gmail.com>wrote:\n>\n>> At least one guy from Rackspace is aware of this problem, thanks Anne \n>> and\n>> James Denton!   ^_^\n>>\n>> Hope to talk with James Page on IRC tomorrow, today was too \n>> complicated\n>> for me... More experts coming!\n>>\n>> I have a good environment for you guys to test and debug this in \n>> deep, if\n>> desired.\n>>\n>> BTW, hey Ubuntu guys! Please, release the ML2 plugin! ASAP!!  I would \n>> love\n>> to try it!    =D\n>>\n>> Best,\n>> Thiago\n>>\n>>\n>> On 12 November 2013 02:40, Geraint Jones <geraint at koding.com> wrote:\n>>\n>>> I suddenly have the identical situation occurring here - of note I \n>>> am\n>>> using grizzly and there have been two changes to the environment \n>>> that have\n>>> seemingly caused this : upgrade of OVS to 1.11 and upgrade of \n>>> quantum-*\n>>> from 2013.1.2 to 2013.1.3\n>>>\n>>> I haven?t tried the default 1.04 from 12.04 and I can?t as this \n>>> is a prod\n>>> system.\n>>>\n>>> However if the openstack update is causing it then here is the place \n>>> to\n>>> start I suspect : https://launchpad.net/neutron/grizzly/2013.1.3\n>>>\n>>> Performance of 1.04 in my env makes that unusable.\n>>>\n>>>\n>>> --\n>>> Geraint Jones\n>>>\n>>>\n>>>\n>>>\n>>> On 11/11/13 2:47 am, \"Jay Pipes\" <jaypipes at gmail.com> wrote:\n>>>\n>>>> On 11/10/2013 01:35 PM, Martinx - ????? wrote:\n>>>>> Hi Jay!\n>>>>>\n>>>>> Thank you! I\'ll definitely take a look at those cookbooks but, I\n>>>>> already\n>>>>> tried Havana (Cloud Archive) with OVS 1.11.0, same poor results.\n>>>>>\n>>>>> Also, my previous region based on Grizzly / Quantum / GRE, worked\n>>>>> perfectly for months (except with MTU = 1400) and, Havana is \n>>>>> somehow\n>>>>> different.\n>>>>\n>>>> Interesting. Well, we\'re just beginning the process of our Havana\n>>>> deployment testing and changes, so we\'ll certainly be \n>>>> double-checking\n>>>> performance based on the above feedback.\n>>>>\n>>>> Best,\n>>>> -jay\n>>>>\n>>>>\n>>>> _______________________________________________\n>>>> Mailing list:\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe :\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>>\n>>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<CAJSM8J3rDg_NfCPN3urDaJo2h+fTQxUzxpQGEuN6AePn6AyC9w@mail.gmail.com>',NULL),('<0D99EC0A-802D-422B-810A-262DEA77E59C@cgoncalves.pt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 15:00:49',3600,'2014-06-12 14:00:49',NULL,'[openstack-dev] [neutron] Specs repository update and the way\n	forward','Thank you for the update, Kyle.\n\nI was sceptical about this move at first but hopefully I was wrong. The specs repository indeed eases a lot of the work from a submitter and reviewer point of view.\n\nIs there any web page where all approved blueprints are being published to? Jenkins builds such pages I?m looking for but they are linked to each patchset individually (e.g., http://docs-draft.openstack.org/77/92477/6/check/gate-neutron-specs-docs/f05cc1d/doc/build/html/). In addition, listing BPs currently under reviewing and linking to its review.o.o page could potentially draw more attention/awareness to what?s being proposed to Neutron (and other OpenStack projects).\n\nThanks,\nCarlos Goncalves\n\nOn 11 Jun 2014, at 18:25, Kyle Mestery <mestery at noironetworks.com> wrote:\n\n> tl;dr: The specs repository has been great to work with. As a\n> reviewer, it makes reviews easier. As PTL, it makes tracking easier as\n> well.\n> \n> Since Juno-1 is about to close, I wanted to give everyone an update on\n> Neutron\'s usage of the specs repository. These are observations from\n> using this since a few weeks before the Summit. I thought it would be\n> good to share with the broader community to see if other projects\n> using spec repositories had similar thoughts, and I also wanted to\n> share this info for BP submitters and reviewers.\n> \n> Overall, the spec repository has been great as a tool to consolidate\n> where new ideas are documented and made into something we can merge\n> and move forward with. Using gerrit for this has been great. We\'ve\n> merged a good amount of specs [1], and the process of hooking these to\n> Launchpad for milestone tracking has been straightforward. As the PTL\n> of Neutron, I\'ve found the specs repository helps me out immensely,\n> the workflow is great.\n> \n> One of the things I\'ve noticed is that sometimes it\'s hard to get\n> submitters to respond to feedback on the specs repository. If you look\n> at our current queue of open BPs [2], we have a lot which are waiting\n> for feedback from submitters. I don\'t know how to address this issue,\n> any feedback appreciated here.\n> \n> Secondly, with so many open BPs, it\'s unlikely that all of these will\n> make Juno. With what we already have approved and being worked, a lot\n> of these will likely slide to the \"K\" release. At some point in the\n> next few weeks, I may start going through some and marking them as\n> such.\n> \n> So, to summarize, I\'m very happy with the workflow from the specs repository.\n> \n> Thanks for reading!\n> Kyle\n> \n> [1] https://review.openstack.org/#/q/status:merged+project:openstack/neutron-specs,n,z\n> [2] https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/ff49407b/attachment.html>\n\n','<CADEmHi2aP+7-Yy8EEd61zZe-vRUvOsCpXtE1a0QNhL3WOf7WkA@mail.gmail.com>',NULL),('<0DA34FFD9D80064AA01EECDE10E613751334D890@HJ-MBX2.persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-01 10:51:10',0,'2013-10-01 10:51:10',NULL,'[Openstack] [openstack][glance]glance image location','Hello All,\n\nWe have a requirement wherein we want to access stored images as file:// URIs. However, we have noticed that file:// option has been removed for security reasons. It is mentioned in\nusr/lib/python2.6/site-packages/glance/api/v1/images.py .\n\nReferences :\nLine number : 380\nhttps://github.com/openstack/glance/blob/master/glance/api/v1/images.py\nLaunchpad : bug #942118\n\nWe are planning to include a configurable parameter in glance.conf and a flag in openstack python code, which enables the usage of file option according to configurable parameter. Can we go ahead with this ?\n\nThanks,\nSrujana C P\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131001/99983cbe/attachment.html>\n\n',NULL,NULL),('<0DA34FFD9D80064AA01EECDE10E613751334D90E@HJ-MBX2.persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-01 12:17:19',0,'2013-10-01 12:17:19',NULL,'[Openstack] [openstack][glance]glance image location','Hi Stuart,\n\nThanks for the immediate response.\nWe need to refer file store for the image content without copying into configured glance image store. So, we would like to specify the source via location  attribute while creating an image. \nCommand: glance image-create  --name=<image-name> --is-public=true --container-format=<container-format> --disk-format=qcow2 --location=<some-location> \n\nWe found following are the supported  non-local store types.\n1.	S3\n2.	Swift\n3.	Http\n4.	Rbd\n5.	Sheepdog\n6.	Cinder\n\nBut we need to have file as a reference store.  \n\nRegards,\nSrujana C P\n-----Original Message-----\nFrom: stuart.mclaren at hp.com [mailto:stuart.mclaren at hp.com] \nSent: Tuesday, October 01, 2013 5:18 PM\nTo: Srujana C P\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] [openstack][glance]glance image location\n\nHi Srujana,\n\n>From looking at the source I think \'file\' is disallowed only for image uploads using the mechanisms where you specify either a location or copy_from (ie where you do not include the image bytes in your request). This is to prevent users accessing arbitrary files on the glance server.\n\nFor standard image uploads (where you include the image data in the request) the \'file\' backend should work as is I think.\n\n-Stuart\n\nOn Tue, 1 Oct 2013, Srujana C P wrote:\n\n> Hello All,\n>\n> We have a requirement wherein we want to access stored images as \n> file:// URIs. However, we have noticed that file:// option has been removed for security reasons. It is mentioned in usr/lib/python2.6/site-packages/glance/api/v1/images.py .\n>\n> References :\n> Line number : 380\n> https://github.com/openstack/glance/blob/master/glance/api/v1/images.p\n> y\n> Launchpad : bug #942118\n>\n> We are planning to include a configurable parameter in glance.conf and a flag in openstack python code, which enables the usage of file option according to configurable parameter. Can we go ahead with this ?\n>\n> Thanks,\n> Srujana C P\n>\n> DISCLAIMER\n> ==========\n> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n>\n>\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n\n\n','<alpine.DEB.2.02.1310011240160.19032@tc-unix2.ilo.cpqcorp.net>',NULL),('<0DA34FFD9D80064AA01EECDE10E613751335061C@HJ-MBX2.persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-16 09:58:44',0,'2013-10-16 09:58:44',NULL,'[Openstack] [openstack][nova][glance] Avoid Image Copying','Hi,\n\nWe have a requirement wherein we will clone an image and register the cloned image into glance from file location using x-image-meta-location. However, file location option has been removed for security reasons.\nSo, We are planning to include two parameters in glance.conf , which enables file access according to configurable parameter and allow access to specific directories.\nFor Example:\nflag_access = enable/disable\naccess_paths=path1,path2,etc.,\n\nAnd while booting a vm ,we want to avoid copying the image from glance  to the Hypervisor (_base folder) for performance reasons .\nFor this, we are planning to add a new parameter in nova conf file based on which we will skip copying image to the Hypervisor and boot from image location which is registered in glance.\nFor Example:\nskip_copy_toHypervisor=enable/disable\n\nAny suggestions/thoughts on this would be very helpful.\n\nThanks,\nSrujana C P\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131016/7cf8501a/attachment.html>\n\n',NULL,NULL),('<0DA34FFD9D80064AA01EECDE10E6137513548958@HJ-MBX2.persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-13 08:13:36',0,'2013-11-13 08:13:36',NULL,'[Openstack] OPENSTACK[KEYSTONE]- MS SQL as Backend Store','Hello All,\n\nWe are planning to use MS SQL Server as keystone backend store . Has anybody tried this? Can someone  share the information regarding the steps to be followed and required configurations and drivers to be installed.\n\nThank You,\nSrujana C P\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131113/46f17d01/attachment.html>\n\n',NULL,NULL),('<0DA79305-7A0F-410D-8A16-4BB00CCACE11@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 23:45:48',0,'2014-09-04 23:45:48',NULL,'[openstack-dev] [all] Alpha release of Congress','Congress isn?t incubated yet, so it won?t be a part of the official release.\n\nThere?s a command-line interface in review right now.  The horizon integration will be along not long after.\n\nTim\n\nOn Sep 3, 2014, at 7:28 PM, Baohua Yang <yangbaohua at gmail.com<mailto:yangbaohua at gmail.com>> wrote:\n\nCongrats!\nWill appear in J or K?\nAnd will there\'s an interface in horizon?\nThanks!\n\n\nOn Thu, Sep 4, 2014 at 5:41 AM, Tim Hinrichs <thinrichs at vmware.com<mailto:thinrichs at vmware.com>> wrote:\nHi all,\n\nThe alpha release of Congress is now available!  We\'d love any and all feedback.\n\nComponents and Features\n- Support for policy monitoring\n- Policy engine implementation\n- Message-passing architecture\n- Drivers for Nova and Neutron\n- Devstack integration\n- Documentation\n- REST API\n\nREADME (with install instructions):\nhttps://github.com/stackforge/congress/blob/master/README.rst<https://urldefense.proofpoint.com/v1/url?u=https://github.com/stackforge/congress/blob/master/README.rst&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=6iCMeALTCrx1m6hWlIjoRMUKoRQoAX1IF1NOgy3X2Mo%3D%0A&s=b457bfe87b47b60df3fc9e8e2e5ebcbaa930693a5eb3d948210792ec428c83bd>\n\nTutorial:\nhttps://github.com/stackforge/congress/blob/master/doc/source/tutorial-tenant-sharing.rst<https://urldefense.proofpoint.com/v1/url?u=https://github.com/stackforge/congress/blob/master/doc/source/tutorial-tenant-sharing.rst&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=6iCMeALTCrx1m6hWlIjoRMUKoRQoAX1IF1NOgy3X2Mo%3D%0A&s=2780defe2dde27a72faff00ba4120122e9954511d66f9a2b1b802e8d2e00f8c4>\n\nTroubleshooting:\nhttps://github.com/stackforge/congress/blob/master/doc/source/troubleshooting.rst<https://urldefense.proofpoint.com/v1/url?u=https://github.com/stackforge/congress/blob/master/doc/source/troubleshooting.rst&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=6iCMeALTCrx1m6hWlIjoRMUKoRQoAX1IF1NOgy3X2Mo%3D%0A&s=da150867c461b3e743a3e32560417e454fbcbf42f8a2217ecb8576176daae325>\n\nContributors (IRC, Reviews, Code):\nSergio Cazzolato (sjcazzol)\nPeter Balland (pballand)\nMohammad Banikazemi (banix)\nRajdeep Dua (rajdeep)\nConner Ferguson (Radu)\nTim Hinrichs (thinrichs)\nGokul Kandiraju (gokul)\nHarrison Kelly (harrisonkelly)\nPrabhakar Kudva (kudva)\nSusanta Nanda (skn)\nSean Roberts (sarob)\nIben Rodriguez (iben)\nAaron Rosen (arosen)\nDerick Winkworth (cloudtoad)\nAlex Yip (alexsyip)\n\n\nSincerely,\nThe Congress team\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nBest wishes!\nBaohua\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140904/5fde2bb2/attachment.html>\n\n','<CACbo-EC27G_ryZ7NMX-8GuwaA5r39_hb1KtkY1TUhimFFyUEiA@mail.gmail.com>',NULL),('<0DB938CC-3A26-4895-903C-9BC566C3E40B@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 20:59:22',-28800,'2013-11-19 04:59:22',NULL,'[openstack-dev] Introducing the new OpenStack service for\n	Containers','\nOn Nov 18, 2013, at 6:05 PM, Russell Bryant <rbryant at redhat.com> wrote:\n\n> On 11/18/2013 07:58 PM, Krishna Raman wrote:\n>> I have also set up a doodle poll\n>> at http://doodle.com/w7y5qcdvq9i36757 to gather a times when a majority \n>> of us are available to discuss on IRC.\n> \n> What time zone are these times in?\n> \n\nSorry forgot to mention. These times are in Pacific time zone.\nhttp://www.time.gov/timezone.cgi?Pacific/d/-8\n\n?Krishna\n\n> -- \n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/12bc31dc/attachment.html>\n\n','<528AC77D.4080402@redhat.com>',NULL),('<0DBB753F-10B7-4679-A40E-773BECB8EE68@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-02 10:15:28',-28800,'2013-01-02 18:15:28',NULL,'[openstack-dev] [keystone] Suggesting promoting guang yee (gyee) to\n	Keystone-core','WIth the new year, I\'d like to recommend Guang Yee to Keystone core. He\'s been active in reviews and contributions from Essex.\n\n\n\n\n',NULL,NULL),('<0DC896E9-0D18-4CB6-8047-770CAA8C7EFE@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 09:49:34',-14400,'2014-03-19 13:49:34',NULL,'[openstack-dev] [magnetodb] Using gevent in MagnetoDB.\n	OpenStack standards and approaches','Dmitriy,\n\nGunicorn + gevent + pecan play nicely together, and they?re a combination I?ve used to good success in the past.  Pecan even comes with some helpers for integrating with gunicorn:\n\n$ gunicorn_pecan pecan_config.py -k gevent -w4\nhttp://pecan.readthedocs.org/en/latest/deployment.html?highlight=gunicorn#gunicorn\n\n---\nRyan Petrello\nSenior Developer, DreamHost\nryan.petrello at dreamhost.com\n\nOn Mar 18, 2014, at 2:51 PM, Dmitriy Ukhlov <dukhlov at mirantis.com> wrote:\n\n> Hello openstackers,\n> \n> We are working on MagnetoDB project and trying our best to follow OpenStack standards.\n> \n> So, MagnetoDB is aimed to be high performance scalable OpenStack based WSGI application which provide interface to high available distributed reliable key-value storage. We investigated best practices and separated the next points:\n> 	? to avoid problems with GIL our application should be executed in single thread mode with non-blocking IO (using greenlets or another python specific approaches to rich this)\n> 	? to make MagnetoDB scalable it is necessary to make MagnetoDB stateless. It allows us run a lot of independent MagnetoDB processes and switch all requests flow between them:\n> 		? at single node to load all CPU?s cores\n> 		? at the different nodes for horizontal scalability\n> 	? use Cassandra as most reliable and mature distributed key-value storage\n> 	? use datastax python-driver as most modern cassandra python client which supports newest CQL3 and Cassandra native binary protocol features set\n> \n> So, considering this points The next technologies was chosen:\n> 	? gevent as one of the fastest non-blocking single-thread WSGI server. It is based on greenlet library and supports monkey patching of standard threading library. It is necessary because of datastax python driver uses threading library and it?s backlog has task to add gevent backlog. (We patched python-driver ourselves to enable this feature as temporary solution and waiting for new python-driver releases). It makes gevent more interesting to use than other analogs (like eventlet for example)\n> 	? gunicorn as WSGI server which is able to run a few worker processes and master process for workers managing and routing request between them. Also it has integration with gevent               and can run gevent based workers. We also analyzed analogues, such as uWSGI. It looks like more faster but unfortunately we didn?t manage to work uWSGI in multi process mode with MagnetoDB application.\n> \n> Also I want to add that currently oslo wsgi framework is used for organizing request routing. I know that current OpenStack trend is to migrate WSGI services to Pecan wsgi framework. Maybe is it reasonable for MagnetoDB too.\n> \n> We would like to hear your opinions about the libraries and approaches we have chosen and would appreciate you help and support in order to find the best balance between performance, developer friendness  and OpenStack standards.\n> -- \n> Best regards,\n> Dmitriy Ukhlov\n> Mirantis Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<532895A0.6000802@mirantis.com>',NULL),('<0DCA0429-B23A-4FF3-917B-E1D61155AA94@siliconloons.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 09:25:39',-21600,'2014-01-16 15:25:39',NULL,'[openstack-dev] Hat Tip to fungi','\nOn Jan 16, 2014, at 9:17 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On Thu, 2014-01-16 at 08:44 -0500, Anita Kuno wrote:\n>> Thank you, fungi.\n>> \n>> You have kept openstack-infra running for that last 2 weeks as the sole\n>> plate-spinner whilst the rest of us were conferencing, working on the\n>> gerrit upgrade or getting our laptop stolen.\n>> \n>> You spun up and configured two new Jenkinses (Jenkinsii?) and then deal\n>> with the consequences of one expansion of our system slowing down\n>> another. With Jim\'s help from afar, Zuul is now on a faster server. [0]\n>> \n>> All this while dealing with the every day business of keeping -infra\n>> operating.\n>> \n>> I am so grateful for all you do.\n>> \n>> I tip my hat to you, sir.\n> \n> Seconded.\n> \nThird?ed? Either way, thank you Fungi for all that you do for OpenStack!\n\nKyle\n\n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1389885469.2174.6.camel@serialcoder>',NULL),('<0dd7d80e7776495db18d18ba41ea32b0@EX13-MBX-012.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-04 19:47:03',0,'2014-08-04 19:47:03',NULL,'[openstack-dev] [Congress] data-source renovation','Hi all,\n\nI favor the first approach because it solves the usability problem of wide tables without limiting Congress\' ability to use wide tables, or adding extra complexity.\n\nThere are legitimate uses for wide tables, so Congress should be able to support them.  For example, Congress will need to support very large data sources in the future (TB in size).  It is best if Congress uses those databases in place, without creating a local copy of the database, so supporting wide tables and making them easy to use in the policy language will be a win for the future.\n\nFor Con (i) (we will need to invert the preprocessor when showing rules/traces/etc. to the user), we can keep the translated policies hidden from the user.  The user should only see policies that he wrote.\n\nFor Con (ii) (a layer of translation makes debugging difficult), the translation layer would be akin to a C preprocessor.  It will be possible to match up items on both sides of the translation layer.\n\n- Alex\n\n\n> Option 2 looks like a better idea keeping in mind the data model\n> consistency with Neutron/Nova.\n> Could we write something similar to a view which becomes a layer on top if\n> this data model?\n\n________________________________________\nFrom: Tim Hinrichs\nSent: Tuesday, July 29, 2014 3:03 PM\nTo: openstack-dev at lists.openstack.org\nCc: Alex Yip\nSubject: [Congress] data-source renovation\n\nHi all,\n\nAs I mentioned in a previous IRC, when writing our first few policies I had trouble using the tables we currently use to represent external data sources like Nova/Neutron.\n\nThe main problem is that wide tables (those with many columns) are hard to use.  (a) it is hard to remember what all the columns are, (b) it is easy to mistakenly use the same variable in two different tables in the body of the rule, i.e. to create an accidental join, (c) changes to the datasource drivers can require tedious/error-prone modifications to policy.\n\nI see several options.  Once we choose something, I?ll write up a spec and include the other options as alternatives.\n\n\n1) Add a preprocessor to the policy engine that makes it easier to deal with large tables via named-argument references.\n\nInstead of writing a rule like\n\np(port_id, name) :-\n    neutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts, binding_cap, status, name, admin_state_up, network_id, tenant_id, binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host)\n\nwe would write\n\np(id, nme) :-\n    neutron:ports(port_id=id, name=nme)\n\nThe preprocessor would fill in all the missing variables and hand the original rule off to the Datalog engine.\n\nPros: (i) leveraging vanilla database technology under the hood\n      (ii) policy is robust to changes in the fields of the original data b/c the Congress data model is different than the Nova/Neutron data models\nCons: (i) we will need to invert the preprocessor when showing rules/traces/etc. to the user\n      (ii) a layer of translation makes debugging difficult\n\n2) Be disciplined about writing narrow tables and write tutorials/recommendations demonstrating how.\n\nInstead of a table like...\nneutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts, binding_cap, status, name, admin_state_up, network_id, tenant_id, binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host)\n\nwe would have many tables...\nneutron:ports(port_id)\nneutron:ports.addr_pairs(port_id, addr_pairs)\nneutron:ports.security_groups(port_id, security_groups)\nneutron:ports.extra_dhcp_opts(port_id, extra_dhcp_opts)\nneutron:ports.name(port_id, name)\n...\n\nPeople writing policy would write rules such as ...\n\np(x) :- neutron:ports.name(port, name), ...\n\n[Here, the period e.g. in ports.name is not an operator--just a convenient way to spell the tablename.]\n\nTo do this, Congress would need to know which columns in a table are sufficient to uniquely identify a row, which in most cases is just the ID.\n\nPros: (i) this requires only changes in the datasource drivers; everything else remains the same\n      (ii) still leveraging database technology under the hood\n      (iii) policy is robust to changes in fields of original data\nCons: (i) datasource driver can force policy writer to use wide tables\n      (ii) this data model is much different than the original data models\n      (iii) we need primary-key information about tables\n\n3) Enhance the Congress policy language to handle objects natively.\n\nInstead of writing a rule like the following ...\n\np(port_id, name, group) :-\n    neutron:ports(port_id, addr_pairs, security_groups, extra_dhcp_opts, binding_cap, status, name, admin_state_up, network_id, tenant_id, binding_vif, device_owner, mac_address, fixed_ips, router_id, binding_host),\n    neutron:ports.security_groups(security_group, group)\n\nwe would write a rule such as\np(port_id, name) :-\n    neutron:ports(port),\n    port.name(name),\n    port.id(port_id),\n    port.security_groups(group)\n\nThe big difference here is that the period (.) is an operator in the language, just as in C++/Java.\n\nPros:\n(i) The data model we use in Congress is almost exactly the same as the data model we use in Neutron/Nova.\n\n(ii) Policy is robust to changes in the Neutron/Nova data model as long as those changes only ADD fields.\n\n(iii) Programmers may be slightly more comfortable with this language.\n\nCons:\n\n(i) The obvious implementation (changing the engine to implement the (.) operator directly is quite a change from traditional database technology.  At this point, that seems risky.\n\n(ii) It is unclear how to implement this via a preprocessor (thereby leveraging database technology).  The key problem I see is that we would need to translate port.name(...) into something like option (2) above.  The difficulty is that TABLE could sometimes be a port, sometimes be a network, sometimes be a subnet, etc.\n\n(iii) Requires some extra syntactic restrictions to ensure we don\'t lose decidability.\n\n(iv) Because the Congress and Nova/Neutron models are the same, changes to the Nova/Neutron model can require rewriting policy.\n\n\n\nThoughts?\nTim\n\n\n','<6B9CE1C5-0C68-490E-98A0-362AF4AD6A08@vmware.com>',NULL),('<0DDEA11A-D791-402B-BE9B-561825084836@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 19:15:58',-18000,'2013-11-27 00:15:58',NULL,'[openstack-dev] [Solum] Definition feedback','\n\n> On Nov 26, 2013, at 6:30 PM, Adrian Otto <adrian.otto at rackspace.com> wrote:\n> \n> Tom, \n> \n> On Nov 26, 2013, at 12:09 PM, \"Tom Deckers (tdeckers)\" <tdeckers at cisco.com>\n> wrote:\n> \n>> Hi All,\n>> \n>> Few comments on the Definitions blueprint [1]:\n>> \n>> 1. I\'d propose to alter the term \'Application\' to either \'Application Package\' or \'Package\'.  Application isn\'t very descriptive and can be confusing to some with the actual deployed instance, etc.\n> \n> I think that\'s a sensible suggestion. I\'m open to using Package, as that\'s an accurate description of what an Application is currently conceived of.\n\nPackage is a bit fraught given its overlap with other programming concepts:\n\nPython Dev: How do I get my django app up in production?\nAdmin: You can create a new package for it.\nPython Dev: You mean with an __init__.py file?\n\nAdmin: Go create your package in horizon so you can deploy it.\nJava Dev: Ok, I ran Create Package from eclipse\n(Hours of humorous miscommunication ensue)\n\nSolum Admin: Go update the package for Bob\'s app.\nOther Admin: I ran \"yum update\" but nothing happened...\n\nIf application is generic, that might be a good thing.  I\'m not sure there are too many words that can accurately describe a Java WAR, a Ruby on Rails site, a Jenkins server, a massive service oriented architecture, or a worker queue processing log data at the same time.  Server and site are too specific or in use in openstack already, program is too singular.\n\nAt the end of the day someone has to explain these terms to a large number of end users (developers) - would hope we can pick a name that is recognizable to most of them immediately, because they\'re going to pick the option that looks the most familiar to them and try it first.\n\n>> \n>> 2. It should be possible for the package to be self-contained, in order to distribute application definitions.   As such, instead of using a repo, source code might come with the package itself.  Has this been considered as a blueprint: deploy code/binaries that are in a zip, rather than a repo?  Maybe Artifact serves this purpose?\n> \n> The API should allow you to deploy something directly from a source code repo without packaging anything up. It should also allow you to present some static deployment artifacts (container image, zip file, etc.) for code that has already been built/tested.\n> \n>> 3. Artifact has not been called out as a top-level noun.  It probably should and get a proper definition.\n> \n> Good idea, I will add a definition for it.\n> \n>> 4. Plan is described as deployment plan, but then it\'s also referenced in the description of \'Build\'.  Plan seems to have a dual meaning, which is fine, but that should be called out explicitly.  Plan is not synonymous with deployment plan, rather we have a deployment plan and a build plan.  Those two together can be \'the plan\'.\n> \n> Currently Plan does have a dual meaning, but it may make sense to split each out if they are different enough. I\'m open to considering ideas on this.\n> \n>> 5. Operations.  The definition states that definitions can be added to a Service too.  Since the Service is provided by the platform, I assume it already comes with operations predefined.\n> \n> Yes, the service provider owns services that are provided by the Platform, and can extend them, where users may not. However, a user may register his/her own Services within the context of a given tenant account, and those can be extended and managed. In that case, you can actually connect Operations to Services as a tenant. So this is really a question of what scope the Service belongs to.\n> \n>> 6. Operations. A descriptor should exist that can be used for registration of the deployed assembly into a catalog.  The descriptor should contain basic information about the exposed functional API and management API (e.g. Operations too).  \n> \n> An Assembly is a running group of cloud resources (a whole networked application\n\nOr a part of one.\n\n> ). A listing of those is exposed through the Assemblies resource.\n> \n> A Plan is a rubber stamp for producing new Assemblies, and can also be listed through the Plans resource. Any plan can be easily converted to an Assembly with an API call.\n> \n> Were you thinking that we should have a catalog beyond these listings? Please elaborate on what you have in mind. I agree that any catalog should provide a way to resolve through to a resources registered Operations. If the current design prohibits this in any way, then I\'d like to revise that.\n> \n>> This leads to the next point:\n>> \n>> 7. Package blueprint.  The Application Package might require its own blueprint to define how it\'s composed.  I can see how the Package is used to distribute/share an application.  The blueprint should define a well-known format.\n> \n> Yes, we have a concept of this that I\'m working to express in writing. Think of the relation between HOT files and Heat. We will have a similar relation of Plan files to Solum. I will be borrowing concepts from CAMP, which has fully specified a format from an open standards perspective that should be well suited for this purpose.\n> \n> Thanks,\n> \n> Adrian\n> \n>> If the above makes sense, I can take a stab at an revised diagram.\n>> \n>> Regards,\n>> Tom Deckers.\n>> \n>> [1] https://blueprints.launchpad.net/solum/+spec/definitions\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<FDFCFC44-9B2D-4A3B-BE93-BF480A46FA31@rackspace.com>',NULL),('<0DEC0D41-F0C7-448C-A594-CC109E04FB05@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 09:36:19',36000,'2013-08-01 23:36:19',NULL,'[openstack-dev] [Ceilometer] Ceilometer and nova compute cells','\nOn 31/07/2013, at 6:45 PM, Julien Danjou <julien at danjou.info> wrote:\n\n> On Wed, Jul 31 2013, Sam Morrison wrote:\n> \n> Hi Sam,\n> \n>> Does everything that gets stored in the datastore go through the\n>> ceilometer.collector.metering queue?\n> \n> If you only use the RPC publisher (which is the default), yes.\n> \n>> If so maybe the collector could instead of storing the message forward these\n>> messages to another rabbit server where another collector is running who in\n>> turn either forwards it up or stores it in the datastore (or both maybe)\n>> I think the confusing thing to me is how notification messages get into\n>> ceilometer. The collector does 2 things I think? And it seems to leave the\n>> messages on the notification.info queue to build up?\n> \n> Yes, the collector has 2 purposes right now:\n> 1. It listens for notifications on the RPC bus and converts them into\n>   Samples;\n> 2. It publishes these Samples according to your pipeline.yaml file to\n>   different conduct, the default being a RPC call on a collector for\n>   storing these samples.\n\nThanks for the info, looking at the code I think the way to do this would be to create a new dispatcher that instead of recording the metering data just forwards it on to another RPC server for another collector to consume.\nDo you think that\'s the way to go?\n\nCheers,\nSam\n\n\n\n> \n> -- \n> Julien Danjou\n> ;; Free Software hacker ; freelance consultant\n> ;; http://julien.danjou.info\n\n\n\n','<8761vrdsnt.fsf@dex.adm.naquadah.org>',NULL),('<0DF97EED-425F-4E9F-8B3C-1633BDB0AAE1@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-23 13:34:14',-25200,'2014-10-23 20:34:14',NULL,'[openstack-dev] [Neutron] Killing connection after security\n	group rule deletion','If you exec conntrack inside the namespace with ip netns exec does it still show both connections?\n\nVish\n\nOn Oct 23, 2014, at 3:22 AM, Elena Ezhova <eezhova at mirantis.com> wrote:\n\n> Hi!\n> \n> I am working on a bug \"ping still working once connected even after related security group rule is deleted\" (https://bugs.launchpad.net/neutron/+bug/1335375). The gist of the problem is the following: when we delete a security group rule the corresponding rule in iptables is also deleted, but the connection, that was allowed by that rule, is not being destroyed.\n> The reason for such behavior is that in iptables we have the following structure of a chain that filters input packets for an interface of an istance:\n> \n> Chain neutron-openvswi-i830fa99f-3 (1 references)\n>  pkts bytes target     prot opt in     out     source               destination         \n>     0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            state INVALID /* Drop packets that are not associated with a state. */\n>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */\n>     0     0 RETURN     udp  --  *      *       10.0.0.3             0.0.0.0/0            udp spt:67 dpt:68\n>     0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set IPv43a0d3610-8b38-43f2-8 src\n>     0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22      <---- rule that allows ssh on port 22                    \n>     1    84 RETURN     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           \n>     0     0 neutron-openvswi-sg-fallback  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* Send unmatched traffic to the fallback chain. */\n> \n> So, if we delete rule that allows tcp on port 22, then all connections that are already established won\'t be closed, because all packets would satisfy the rule: \n> 0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED /* Direct packets associated with a known session to the RETURN chain. */\n> \n> I seek advice on the way how to deal with the problem. There are a couple of ideas how to do it (more or less realistic):\n> Kill the connection using conntrack\n>           The problem here is that it is sometimes impossible to tell which connection should be killed. For example there may be two instances running in different namespaces that have the same ip addresses. As a compute doesn\'t know anything about namespaces, it cannot distinguish between the two seemingly identical connections: \n>          $ sudo conntrack -L  | grep \"10.0.0.5\"\n>          tcp      6 431954 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60723 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60723 [ASSURED] mark=0 use=1\n>          tcp      6 431976 ESTABLISHED src=10.0.0.3 dst=10.0.0.5 sport=60729 dport=22 src=10.0.0.5 dst=10.0.0.3 sport=22 dport=60729 [ASSURED] mark=0 use=1\n> \n> I wonder whether there is any way to search for a connection by destination MAC?\n> Delete iptables rule that directs packets associated with a known session to the RETURN chain\n>            It will force all packets to go through the full chain each time and this will definitely make the connection close. But this will strongly affect the performance. Probably there may be created a timeout after which this rule will be restored, but it is uncertain how long should it be.\n> \n> Please share your thoughts on how it would be better to handle it.\n> \n> Thanks in advance,\n> Elena\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/be2556b6/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141023/be2556b6/attachment.pgp>\n\n','<CAFZxAhh71QLTMrHyGEmjowsbS1SvPknXyvgQmAHo7gUq+4Q80w@mail.gmail.com>',NULL),('<0E0C6D95-F2FC-4591-9BEC-33545E6EC58F@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-16 08:25:32',7200,'2014-02-16 06:25:32',NULL,'[openstack-dev] [Trove] Trove-Gate timeouts','Hello, Mathew.\n\nI\'m seeing same issues with the gate.\nI also tried to found out why gate job is failing. First ran into issue related to cinder installation failure in devstack. But then I found same problem as you described. The best option is to increase job time range. \nThanks for such research. I hope gate will be fixed in the easiest way and for the shortest period of time.\n\nBest regards\nDenis Makogon.\nSent from an iPad\n\n> 16 ????. 2014, ? 00:46, \"Lowery, Mathew\" <mlowery at ebay.com> ???????(?):\n> \n> Hi all,\n> \n> Issue #1: Jobs that need more than one hour\n> \n> Of the last 30 Trove-Gate builds (spanning three days), 7 have failed due to a Jenkins job-level timeout (not a proboscis timeout). These jobs had no failed tests when the timeout occurred.\n> \n> Not having access to the job config to see what the job looks like, I used the console output to guess what was going on. It appears that a Jenkins plugin named boot-hpcloud-vm is booting a VM and running the commands given, including redstack int-tests. From the console output, it states that it was supplied with an ssh_shell_timeout=\"7200\". This is passed down to another library called net-ssh-simple. net-ssh-simple has two timeouts: an idle timeout and an operation timeout.\n> \n> In the latest boot-hpcloud-vm, ssh_shell_timeout is passed down to net-ssh-simple for both the idle timeout and the operation timeout. But in older versions of boot-hp-cloud-vm, ssh_shell_timeout is passed down to net-ssh-simple for only the idle timeout, leaving a default operation timeout of 3600. This is why I believe these jobs are failing after exactly one hour.\n> \n> FYI: Here are the jobs that failed due to the Jenkins job-level timeout (and had no test failures when the timeout occurred) along with their associated patch sets:\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2532/console (http://review.openstack.org/73786)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2530/console (http://review.openstack.org/73736)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2517/console (http://review.openstack.org/63789)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2514/console (https://review.openstack.org/50944)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2513/console (https://review.openstack.org/50944)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2504/console (https://review.openstack.org/73147)\n> https://rdjenkins.dyndns.org/job/Trove-Gate/2503/console (https://review.openstack.org/73147)\n> \n> Suggested action items:\n> If it is acceptable to have jobs that run over one hour, then install the latest boot-hpcloud-vm plugin for Jenkins which will increase the make the operation timeout match the idle timeout.\n> \n> Issue #2: The running time of all jobs is 1 hr 1 min\n> \n> While the Jenkins job-level timeout will end the job after one hour, it also appears to keep every job running for a minimum of one hour.  To be more precise, the timeout (or minimum running time) occurs on the part of the Jenkins job that runs commands on the VM; the VM provision (which takes about one minute) is excluded from this timeout which is why the running time of all jobs is around 1 hr 1 min. A sampling of console logs showing the time the int-tests completed and when the timeout kicks in:\n> \n> https://rdjenkins.dyndns.org/job/Trove-Gate/2531/console (00:01:03 wasted)\n> 04:51:12 COMMAND_0: echo refs/changes/36/73736/2\n> ...\n> 05:50:10     335.41     proboscis.case.MethodTest (test_instance_created)\n> 05:50:10     194.05     proboscis.case.MethodTest (test_instance_returns_to_active_after_resize)\n> 05:51:13 **************************************\n> 05:51:13 ****** STDERR-BEGIN ******\n> \n> https://rdjenkins.dyndns.org/job/Trove-Gate/2521/console (00:06:44 wasted)\n> 21:11:44 COMMAND_0: echo refs/changes/89/63789/13\n> ...\n> 22:05:00     195.11     proboscis.case.MethodTest (test_instance_returns_to_active_after_resize)\n> 22:05:00     186.89     proboscis.case.MethodTest (test_resize_down)\n> 22:11:44 **************************************\n> 22:11:44 ****** STDERR-BEGIN ******\n> \n> https://rdjenkins.dyndns.org/job/Trove-Gate/2518/consoleFull (00:06:01 wasted)\n> 17:46:59 COMMAND_0: echo refs/changes/02/64302/20\n> ...\n> 18:40:57     210.03     proboscis.case.MethodTest (test_instance_returns_to_active_after_resize)\n> 18:40:57     187.89     proboscis.case.MethodTest (test_resize_down)\n> 18:46:58 **************************************\n> 18:46:58 ****** STDERR-BEGIN ******\n> \n> Suggested action items:\n> Given that the minimum running time is one hour, I assume the problem is in the net-ssh-simple library. Needs more investigation.\n> \n> Issue #3: Jenkins console log line timestamps different between full and truncated views\n> \n> I assume this is due to JENKINS-17779.\n> \n> Suggested action items:\n> Upgrade the timestamper plugin.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/39a31bc5/attachment.html>\n\n','<CF254A5E.1DFF5%mlowery@ebay.com>',NULL),('<0E0CFF16-8142-4B27-AC5D-253DCE16AC15@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 18:54:15',0,'2014-05-08 18:54:15',NULL,'[openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert\n implementation for	LBaaS and VPN','\nOn May 8, 2014, at 1:41 PM, \"Eichberger, German\" <german.eichberger at hp.com<mailto:german.eichberger at hp.com>>\n wrote:\n\nHi,\n\nSome of our users are not that organized and certificate expirations seem to sneak up on them. So they are looking for a single place where they can ?manage? their certificates. I am not sure if splitting storage between Barbican and Neutron will allow that. I am also wondering if Barbican is aspiring to become that central place?\n\n    Ok but in our implementation we may decide to duplicate the X509s in our database so that we can search and do searches on them with out going over a separate API service. So we don\'t mind storing them in both locations. We just worry about case were people update their (x509,priv_key) via barbican but existing loadbalancers in neutron would then be unaware of the new updated cert. This would seem to imply that barbican would need to trigger an update on neutron/lbaas. :(\n\n\n\nGerman\n\nFrom: Carlos Garza [mailto:carlos.garza at rackspace.com<http://rackspace.com>]\nSent: Thursday, May 08, 2014 9:54 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN\n\n\nOn May 8, 2014, at 5:19 AM, Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>\n wrote:\n\n\nHi,\n\nPlease note as commented also by other XaaS services that managing SSL certificates is not a sole LBaaS challenge.\nThis calls for either an OpenStack wide service or at least a Neutron wide service to implement such use cases.\n\nSo it here are the options as far as I have seen so far.\n1.       Barbican as a central service to store and retrieve SSL certificates. I think the Certificates generation is currently a lower priority requirement\n2.       Using Heat as a centralized service\n3.       Implementing such service in Neutron\n4.       LBaaS private implementation\n\nBTW, on all the options above, Barbican can optionally be used to store the certificates or the private part of the certificates.\n\n   Is your statement equivalent to \"On all the options above, Babican can optionally be used to store the (X509,private_key) or just the private_key.\nIf thats what you mean then we are on the same page. \"private part of a certificate\" is not a valid statement for me since x509 certs don\'t contain private parts.\n\nI\'m advocating the latter where barbican stores the key only and we store the X509 on our own database.\n\n\nI think that we either follow option 3 if SSL management is only a Neutron requirement (LBaaS, VPNaaS, FWaaS) and maybe as a transition project to an OpenStack wide solution (1 or 2).\nOption 1 or 2 might be the ultimate goal.\n\nRegards,\n                -Sam.\n\n\n\n\n\nFrom: Clark, Robert Graham [mailto:robert.clark at hp.com<http://hp.com>]\nSent: Thursday, May 08, 2014 12:43 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN\n\nThe certificate management that LBaaS requires might be slightly different to the normal flow of things in OpenStack services, after all you are talking about externally provided certificates and private keys.\n\nThere?s already a standard for a nice way to bundle those two elements together, it?s described in PKCS#12 and you?ve likely come across it in the form of ?.pfx? files. I?d suggest that perhaps it would make sense for LBaaS to store pfx files in the LBaaS DB and store the key for the pfx files in Barbican. You could probably store them together in Barbican, using containers if you really wanted to (https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)\n\n-Rob\n\nFrom: Carlos Garza [mailto:carlos.garza at rackspace.com]\nSent: 08 May 2014 04:30\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN\n\n\nOn May 7, 2014, at 10:53 AM, Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>> wrote:\n\nHi John,\n\nIf the user already has an SSL certificate that was acquired outside of the barbican Ordering system, how can he store it securely in Barbican as a SSL Certificate?\nThe Container stored this information in a very generic way, I think that there should be an API that formalizes a specific way in which SSL certificates can be stored and read back as SSL Certificates and not as loosely coupled container structure.\nThis such API should have RBAC that allows getting back only the public part of an SSL certificate vs. allowing to get back all the details of the SSL certificate.\n\n    Why the need for that complexity? The X509s are public by nature and don\'t need to be stored in Barbican so there isn\'t really a private part of the certificate. The actual private key itself is what needs to be secured so I would advocate that the private key is what will be stored in barbican. I also think we should also declare that the private key need not be an RSA key as x509 supports other asymmetric encryption types so storing as a generic blob in barbican is probably a good idea.\n\n\n\n\n\n-Sam.\n\n\n\nFrom: John Wood [mailto:john.wood at RACKSPACE.COM<http://RACKSPACE.COM>]\nSent: Thursday, May 01, 2014 11:28 PM\nTo: OpenStack Development Mailing List (not for usage questions);os.vbvs at gmail.com<mailto:os.vbvs at gmail.com>\nSubject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN\n\nHello Samuel,\n\nJust noting that the link below shows current-state Barbican. We are in the process of designing SSL certificate support for Barbican via blueprints such as this one: https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates\nWe intend to discuss this feature in Atlanta to enable coding in earnest for Juno.\n\nThe Container resource is intended to capture/store the final certificate details.\n\nThanks,\nJohn\n\n\n________________________________\nFrom: Samuel Bercovici [SamuelB at Radware.com<mailto:SamuelB at Radware.com>]\nSent: Thursday, May 01, 2014 12:50 PM\nTo: OpenStack Development Mailing List (not for usage questions); os.vbvs at gmail.com<mailto:os.vbvs at gmail.com>\nSubject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN\nHi Vijay,\n\nI have looked at the Barbican APIs ?https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface\nI was no able to see a ?native? API that will accept an SSL certificate (private key, public key, CSR, etc.) and will store it.\nWe can either store the whole certificate as a single file as a secret or use a container and store all the certificate parts as secrets.\n\nI think that having LBaaS reference Certificates as IDs using some service is the right way to go so this might be achived by either:\n1.       Adding to Barbican and API to store / generate certificates\n2.       Create a new ?module? that might start by being hosted in neutron or keystone that will allow to manage certificates and will use Barbican behind the scenes to store them.\n3.       Decide on a container structure to use in Babican but implement the way to access and arrange it as a neutron library\n\nWas any decision made on how to proceed?\n\nRegards,\n                -Sam.\n\n\n\n\nFrom: Vijay B [mailto:os.vbvs at gmail.com]\nSent: Wednesday, April 30, 2014 3:24 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for LBaaS and VPN\n\nHi,\n\nIt looks like there are areas of common effort in multiple efforts that are proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron.\n\nTwo relevant efforts are listed below:\n\n\nhttps://review.openstack.org/#/c/74031/   (https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)\n\nhttps://review.openstack.org/#/c/58897/   (https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)\n\n\n\nBoth VPN and LBaaS will use SSL certificates and keys, and this makes it better to implement SSL entities as first class citizens in the OS world. So, three points need to be discussed here:\n\n1. The VPN SSL implementation above is putting the SSL cert content in a mapping table, instead of maintaining certs separately and referencing them using IDs. The LBaaS implementation stores certificates in a separate table, but implements the necessary extensions and logic under LBaaS. We propose that both these implementations move away from this and refer to SSL entities using IDs, and that the SSL entities themselves are implemented as their own resources, serviced either by a core plugin or a new SSL plugin (assuming neutron; please also see point 3 below).\n\n2. The actual data store where the certs and keys are stored should be configurable at least globally, such that the SSL plugin code will singularly refer to that store alone when working with the SSL entities. The data store candidates currently are Barbican and a sql db. Each should have a separate backend driver, along with the required config values. If further evaluation of Barbican shows that it fits all SSL needs, we should make it a priority over a sqldb driver.\n\n3. Where should the primary entries for the SSL entities be stored? While the actual certs themselves will reside on Barbican or SQLdb, the entities themselves are currently being implemented in Neutron since they are being used/referenced there. However, we feel that implementing them in keystone would be most appropriate. We could also follow a federated model where a subset of keys can reside on another service such as Neutron. We are fine with starting an initial implementation in neutron, in a modular manner, and move it later to keystone.\n\n\nPlease provide your inputs on this.\n\n\nThanks,\nRegards,\nVijay\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/390c0434/attachment.html>\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C332A25@G1W3651.americas.hpqcorp.net>',NULL),('<0E121C08-DBA5-4378-BABB-7B312C225D7A@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 07:54:20',-18000,'2014-11-25 12:54:20',NULL,'[openstack-dev] [all] Versioned objects cross project sessions\n	next steps','\nOn Nov 24, 2014, at 4:06 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On 11/24/2014 03:11 PM, Joshua Harlow wrote:\n>> Dan Smith wrote:\n>>>> 3. vish brought up one draw back of versioned objects: the difficulty in\n>>>> cherry picking commits for stable branches - Is this a show stopper?.\n>>> \n>>> After some discussion with some of the interested parties, we\'re\n>>> planning to add a third .z element to the version numbers and use that\n>>> to handle backports in the same way that we do for RPC:\n>>> \n>>> https://review.openstack.org/#/c/134623/\n>>> \n>>>> Next steps:\n>>>> - Jay suggested making a second spec that would lay out what it would\n>>>> look like if we used google protocol buffers.\n>>>> - Dan: do you need some help in making this happen, do we need some\n>>>> volunteers?\n>>> \n>>> I\'m not planning to look into this, especially since we discussed it a\n>>> couple years ago when deciding to do what we\'re currently doing. If\n>>> someone else does, creates a thing that is demonstrably more useful than\n>>> what we have, and provides a migration plan, then cool. Otherwise, I\'m\n>>> not really planning to stop what I\'m doing at the moment.\n>>> \n>>>> - Are there any other concrete things we can do to get this usable by\n>>>> other projects in a timely manner?\n>>> \n>>> To be honest, since the summit, I\'ve not done anything with the current\n>>> oslo spec, given the potential for doing something different that was\n>>> raised. I know that cinder folks (at least) are planning to start\n>>> copying code into their tree to get moving.\n>>> \n>>> I think we need a decision to either (a) dump what we\'ve got into the\n>>> proposed library (or incubator) and plan to move forward incrementally\n>>> or (b) each continue doing our own thing(s) in our own trees while we\n>>> wait for someone to create something based on GPB that does what we want.\n>> \n>> I\'d prefer (a); although I hope there is a owner/lead for this library\n>> (dan?) and it\'s not just dumped on the oslo folks as that won\'t work out\n>> so well I think. It\'d be nice if said owner could also look into (b) but\n>> that\'s at there own (or other library supporter) time I suppose (I\n>> personally think (b) would probably allow for a larger community of\n>> folks to get involved in this library, would potentially reduce the\n>> amount of custom/overlapping code and other similar benefits...).\n> \n> I gave some comments at the very end of the summit session on this, and I want to be clear about something. I definitely like GPB, and there\'s definite overlap with some things that GPB does and things that nova.objects does.\n> \n> That said, I don\'t think it\'s wise to make oslo-versionedobjects be a totally new thing. I think we should use nova.objects as the base of a new oslo-versionedobjects library, and we should evolve oslo-versionedobjects slowly over time, eventually allowing for nova, ironic, and whomever else is currently using nova/objects, to align with an Oslo library vision for this.\n> \n> So, in short, I also think a) is the appropriate path to take.\n\n+1\n\nWhen Dan and I talked about this, I said I would take care of exporting the nova objects git history into a new repository. We?ve had some other things blocking work in Oslo that I needed to handle, but I expect to be able to pick up this work soon. If someone else wants to jump in, I?ll be happy to give a brain dump of what I planned to do for the export, since the existing Oslo tool that we use on the incubator isn?t quite right for the job.\n\nDoug\n\n> \n> Best,\n> -jay\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<54739DE3.2000301@gmail.com>',NULL),('<0E1FAEBCE1F04C16B90EB1C435A2B6E1@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-24 09:54:52',-14400,'2012-10-24 13:54:52',NULL,'[openstack-dev] Secure RPC','> \n> None of us can compare to Bruce I\'m sure (all praise Schneier!) and I\'m\n\nEverything I know is from his book. This palliwan has not surpassed his master. \n> \n> regularly guilty of running off down crypto rabbit holes - allow me to bring \n> this back up to the high level momentarily. Is it likely that signing and \n> encryption would both be predicated on a-symmetric cryptography? If that\'s the \n> case then the primitives in use will likely be the same and perhaps we should \n> come to a point where signing/encryption are both options that pivot on the \n> same extension? Or perhaps look a little more closely at the work Eric has \n> already done on extending RPC so that we can come up with something flexible \n> enough to support both.\n> \n> \n> \n\n\nI hope nobody questions if we need signing. Even with encryption, we\'d want signing. This is what will allow us to bring in RBAC.  Additionally, if we\'re going to sign, the signature should be inside of the encrypted message.\n\nThe locations of the hooks will be the same. The key management and crypto bits will be largely the same. We\'re also going to use this from several modules (impl_kombu, _qpid, and _zmq), so the goal is to make these bits reusable as possible.\n\nAdding crypto should \"just\" be another change to the wire format. We\'d encrypt the whole message, signature and all, and possibly sign the cryptotext as well to verify that the encryption was performed by the trusted party. (more about S/E/S patterns: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html)\n\nAlso, signing is something that when enabled, must be vetted on the receiver end. Receivers will not accept any unsigned messages in a trusted environment. However, encryption enforcement is sender-end. Receivers will still be able to opt into trusting signed messages that aren\'t encrypted, it will be the responsibility of the sender to encrypt before sending. (We might want to put a receiver restriction here too for additional security, but it wouldn\'t be strictly necessary -- S/E/S would make it really difficult for someone to launch a MITM, but signing-only does a decent job on its own)\n\nRegards,\nEric Windisch\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121024/0dde774f/attachment-0001.html>\n\n','<A0C170085C37664D93EE1604364858A10B307AA5@G4W3202.americas.hpqcorp.net>',NULL),('<0E311152-F6B5-4D2E-AA27-D8D8D6E7CB98@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 23:17:27',0,'2014-04-16 23:17:27',NULL,'[openstack-dev] [Neutron][LBaaS] Requirements and API\n	revision	progress','\nOn Apr 16, 2014, at 4:31 PM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:\n\nHi folks,\n\nI\'ve briefly looked over the doc.\n\nI think whole idea to base the API on Atlas misses the content switching use case, which is very important:\nWe need multiple pools within loadbalancer, and API doesn\'t seem to allow that.\nIf it would, then you\'ll face another problem: you need to reference those pools somehow inside the json you use in POST.\nThere are two options here: use names or IDs, both are putting constraints and create complexity for both user of such API and for the implementation.\n\nThat particular problem becomes worse when it comes to objects which might not have names while it\'s better to not provide ID in POST and rely on their random generation. E.g. when you need to create references between objects in json input - you\'ll need to create artificial attributes just for the parser to understand that such input means.\n\nSo that makes me think that right now a \'single-call API\' is not flexible enough to comply with our requirements.\n\n    We have demonstrated that you can create loadbalancers in separate transactions and in a single call fashion using both reference_ids to previous pools and as well as using a transient names to create objects in the same single call and reference them later on in other objects. The single call API is very flexible in that it allows you to create sub objects(We proposed transient ids to allow the user to avoid creating duplicate objects with different ids) on the fly as well as reference preexisting objects by id. The allowance for transient ids is adding flexibility to the api not taking away from it as you declared. I would like you to really be clear on what \"our requirements\"? What requirement is our single API call violating?\n\n    We have thus far attempted to support a single call API that doesn\'t interfere with multiple smaller object creation calls. If we are just adding to the API  in a demonstrably workable fashion what is the real objection.\n\n\nWhile I understand that it might be simpler to use such API for some cases, it makes complex configurations fall back to our existing approach which is creating configuration on per object basis.\nWhile the problem with complex configurations is not sorted out, I\'d prefer if we focus on existing \'object-oriented\' approach.\n\n    Your basically saying\nP1: \"The single API call proposal doesn\'t support *ALL* complex configurations\"\nP2: \" if the single API proposal doesn\'t support *ALL* complex configurations the proposal should be rejected\"\n\nWe have demonstrated that the proposed single API call can handle complex configurations via transient ids. So we already disagree with preposition 1.\n\nWe don\'t agree with preposition 2 either:\n    We believe it is unfair to punish the API end user due to the religious belief that \"The single API calls must support all possible configurations or you as the customer can\'t be allowed to use the single API call even for simpler configurations.\"\n\nWe want the single API call proposal to be as useful as possible so we are like wise looking at ways to have it solve ALL complex configurations and so far we feel transient IDs solve this problem already.\n\n    Is the real objection that a single API call makes the implementation too complex? We are advocating that a single API makes it easier on the end user of the API and are of the impression that its better to have a complex implementation inside our neutron/lbaas code rather then passing that complexity down to the end user of the API.\n\n    We don\'t object to multiple smaller object creation transactions we just want the addition of having single API call.\n\n\nOn the other hand, without single-call API the rest of proposal seems to be similar to approaches discussed in https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion\n    Since you linked the object model proposals could you also link the \"rest of the proposals\" or are you referring to our draft as \"rest of proposal\"?\n\n\nThanks,\nEugene.\n\n\n\n\n\nOn Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:\nSorry about that.  It should be readable now.\n________________________________\nFrom: Eugene Nikanorov [enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>]\nSent: Wednesday, April 16, 2014 3:51 PM\n\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress\n\nHi Brandon,\n\nSeems that doc has not been made public, so please share.\n\nThanks,\nEugene.\n\n\nOn Thu, Apr 17, 2014 at 12:39 AM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:\nHere is Jorge and team?s API proposal based on Atlas.  The document has some questions and answers about why decisions were made.  Feel free to open up a discussion about these questions and answers and really about anything.   This can be changed up to fit any flaws or use cases we missed that this would not support.\n\nThere is a CLI example at the bottom along with a possible L7 switching API model.\n\nhttps://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit\n\nThanks,\nBrandon Logan\n\nFrom: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>\nReply-To: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, April 15, 2014 at 7:00 AM\nTo: \"openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n\nSubject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress\n\nHi Stephen,\n\nThanks for a good summary. Some comments inline.\n\n\nOn Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:\n\nSo! On this front:\n\n1. Does is make sense to keep filling out use cases in Samuel\'s document above? I can think of several more use cases that our customers actually use on our current deployments which aren\'t considered in the 8 cases in Samuel\'s document thus far. Plus nobody has create any use cases from the cloud operator perspective yet.\n\nI treat Sam\'s doc as a source of use cases to triage API proposals. If you think you have use cases that don\'t fit into existing API or into proposed API, they should certainly be brought to attention.\n\n\n2. It looks like we\'ve started to get real-world data on Load Balancer features in use in the real world. If you\'ve not added your organization\'s data, please be sure to do so soon so we can make informed decisions about product direction. On this front, when will we be making these decisions?\nI\'d say we have two kinds of features - one kind is features that affect or even define the object model and API.\nOther kind are features that are implementable within existing/proposed API or require slight changes/evolution.\nFirst kind is the priority: while some of such features may or may not be implemented in some particular release, we need to implement proper infrastructure for them (API, obj model)\n\nOleg Bondarev (he\'s neutron core) and me are planning and mostly interested to work on implementing generic stuff like API/obj model and adopt haproxy driver to it. So our goal is to make implementation of particular features simpler for contributors and also make sure that proposed design fits in general lbaas architecture. I believe that everyone who wants to see certain feature may start working on it - propose design, participate in discussions and start actually writing the code.\n\n\n\n3. Jorge-- I know an action item from the last meeting was to draft a revision of the API (probably starting from something similar to the Atlas API). Have you had a chance to get started on this, and are you open for collaboration on this document at this time? Alternatively, I\'d be happy to take a stab at it this week (though I\'m not very familiar with the Atlas API-- so my proposal might not look all that similar).\n\n+1, i\'d like to see something as well.\n\n\nWhat format or template should we be following to create the API documentation?  (I see this here:  http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html  but this seems like it might be a little heavy for an API draft that is likely to get altered significantly, especially given how this discussion has gone thus far. :/ )\n\nAgree, that\'s too heavy for API sketch. I think a set of resources with some attributes plus a few cli calls is what could show the picture.\n\nThanks,\nEugene.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140416/8ab4cc08/attachment.html>\n\n','<CAJfiwORNWbbTxWT-71coexuJMcd3yE10Z6xpcRBT2E3m+S2Sjg@mail.gmail.com>',NULL),('<0E341857-AC4A-44B6-AC3F-0226F5AB1F61@openstack.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-03 09:58:24',-18000,'2013-10-03 14:58:24',NULL,'[Openstack] Making the Hong Kong Summit as inclusive as possible','Hi Anne, David,\n\nYes, the transparency committee update is on the board meeting agenda, but I think the code of conduct for our Summit is a different issue.\n\nThe transparency committee had three main tasks: develop a written policy documenting our approach to transparency, investigate creating an independent ombudsman, and figuring out a way to move non-confidential Board communications to a public mailing list. I circulated the transparency policy on the Foundation mailing list (http://lists.openstack.org/pipermail/foundation/2013-July/001447.html) for comment, and we\'re hoping to review the policy in today\'s Board meeting. You can see the latest version here (https://docs.google.com/a/openstack.org/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit).\n\nRegarding the Summit code of conduct, I have an update since my last email about working on reporting/response procedures. We have a draft going here (https://etherpad.openstack.org/reporting-response-procedures) and had a good call with the Ada Initiative last week for input. We\'re also planning to engage with them to train our event staff before the Summit.  I\'d welcome any feedback on the procedures, as well as if there are any other policies we should be looking at (our procedures are based largely on PyCon, also influenced by Ada Initiative) or other organizations we should be engaging with along these lines.\n\nWhile we won\'t be able to change the official code of conduct before the Summit, we can wrap it with more specific behavior examples like David had suggested and publicize the reporting/response procedures on our website, in a pre-event email to attendees and on-site.  If there are any issues in the meantime, the Foundation staff, including Jonathan, Stef, Tom and me, are always available and happy to get involved. \n\nAs a reminder, I encourage anyone who is interested to dial into the board meeting. The meeting invites are always posted to the Foundation mailing list, and there\'s a link to register in the agenda: https://wiki.openstack.org/wiki/Governance/Foundation/3Oct2013BoardMeeting\n\nThanks,\nLauren\n\nOn Oct 1, 2013, at 12:53 PM, David Mortman <launchpad at mortman.com> wrote:\n\n> Thanks Anne!\n> \n> \n> On Tue, Oct 1, 2013 at 1:37 PM, Anne Gentle <anne at openstack.org> wrote:\n> Hi David and list and everybody, \n> \n> The Board meets Oct 3, and Josh has an agenda item for the Transparency WorkGroup. https://wiki.openstack.org/wiki/Governance/Foundation/3Oct2013BoardMeeting \n> \n> Anne\n> \n> On Tue, Oct 1, 2013 at 12:25 PM, David Mortman <launchpad at mortman.com> wrote:\n> So given that it\'s been nearly two weeks since anyone has responded is it time to rebrand it the Opacity Committee?\n> \n> \n> On Wed, Sep 18, 2013 at 8:23 PM, David Mortman <launchpad at mortman.com> wrote:\n> Joshua,\n> \n> I found this answer hilariously short and opaque especially given the context of it being part of the Transparency Committee. Can you go into more details about what has been discussed in the past as well as what might be proposed at the next board meeting. Speaking of which, when is the next board meeting anyways?\n> \n> thanks\n> \n> -David\n> \n> \n> \n> On Tue, Sep 17, 2013 at 1:08 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:\n> David - yes, the ombudsperson office is one of the goals of the Transparency Committee, and we\'ve got an agenda item to dig into again at the next board meeting.\n> \n> --\n> \n> Joshua McKenty\n> Chief Technology Officer\n> Piston Cloud Computing, Inc.\n> +1 (650) 242-5683\n> +1 (650) 283-6846\n> http://www.pistoncloud.com\n> \n> \"Oh, Westley, we\'ll never survive!\"\n> \"Nonsense. You\'re only saying that because no one ever has.\"\n> \n> On Sep 15, 2013, at 5:18 PM, David Mortman <launchpad at mortman.com> wrote:\n> \n>> Joshua,\n>> \n>> I\'ll leave it up to the event staff to determine how they want to handle it in this on-site case. Certainly someone needs to be empowered or the exercise is pointless. For the community as a whole, does the Board of Directors have the authority to create an ombuds office?\n>> \n>> -DM\n>> \n>> \n>> On Sun, Sep 15, 2013 at 12:44 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:\n>> David, while I think having an onsite group able to field complaints and address incidents is critical, we need to make sure that such a group has the ability to address any complaints. So I\'d suggest we pass this directly to the foundation staff, and make sure that the event coordination team is coached appropriately. Having community members act as ombudsperson is both complicated from a legal standpoint, and potentially inappropriate.\n>> \n>> Lauren, can you make sure the on-site events team is briefed on the proposed code-of-conduct, and is ready to respond to any complaints that might arise?\n>> \n>> --\n>> \n>> Joshua McKenty\n>> Chief Technology Officer\n>> Piston Cloud Computing, Inc.\n>> +1 (650) 242-5683\n>> +1 (650) 283-6846\n>> http://www.pistoncloud.com\n>> \n>> \"Oh, Westley, we\'ll never survive!\"\n>> \"Nonsense. You\'re only saying that because no one ever has.\"\n>> \n>> On Sep 15, 2013, at 3:59 AM, David Mortman <launchpad at mortman.com> wrote:\n>> \n>>> On Thu, Sep 12, 2013 at 4:26 PM, David Mortman <launchpad at mortman.com> wrote:\n>>>  Agreed. There should be at least a small group, especially for events, so that one person doesn\'t get hammered but also so there\'s a committee to make judgement calls etc. Love the idea of some training too.\n>>> \n>>> Given the closeness of the summit (only 2 months away), it\'s seems like a good idea to put together the initial group of folks who can be the onsite committee to help address any issues that hopefully won\'t arise. While I\'ll continue to participate in this effort, unfortunately, I won\'t be attending the summit myself so I can\'t help onsite. I will however like  nominate both Anne Gentle and George Reese be initial members of the committee. Anyone else interested? A group of three is probably plenty.\n>>> \n>>> thanks\n>>> -David\n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> \n> \n> \n> \n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131003/7d17ffbb/attachment.html>\n\n','<CAPDpzpP95-qm1AdX1NYb82SxPWVkJcZBPqPfd+34AyyDtBC_RA@mail.gmail.com>',NULL),('<0E3BD191-FE39-4FF3-A86C-1C62FB3DD5D6@av.it.pt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 17:10:08',3600,'2014-05-07 16:10:08',NULL,'[openstack-dev]  Monitoring as a Service','Hello everyone,\n\nMe and my team have been following this subject and similar ones related to Monitoring. IHMO, seems to be very logical to aggregate monitoring with Ceilometer. Others have been working on similar features, like ICC Lab: Nagios/Ceilometer Integration and SNMP Support\n\nThe best choice, is to enhance Ceilometer with monitoring features.\n\nAre you planning on talking about this on following IRC meetings? For further discussion.\n\nBest regards,\nPaulo J. Nascimento Oliveira\nhttp://about.me/pnascimento\nAdvanced Telecommunications and Networks Group - http://atnog.av.it.pt\nFollow us - @ATNoG_ITAv\n\n\n> From: Eoghan Glynn <eglynn at redhat.com>\n> Subject: Re: [openstack-dev] Monitoring as a Service\n> Date: 7 May 2014 09:57:38 GMT+1\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Reply-To: \"OpenStack Development Mailing List \\(not for usage questions\\)\" <openstack-dev at lists.openstack.org>\n> \n> \n> Hi Alexandre,\n> \n> I wanted to let this discussion develop a little before jumping in, as\n> we\'ve already had many circular debates about the cross-over between\n> ceilometer and monitoring infrastructure in general.\n> \n> Personally I\'m in favor of the \"big tent/broad church\" interpretation of\n> ceilometer\'s project mandate, and would welcome further development of\n> our capabilities in this area (whether directly within the ceilometer\n> code-tree itself, or within a parallel repo aligned with the Telemetry\n> program).\n> \n> In terms of furthering the discussion, unfortunately you\'ve missed the\n> boat in terms of securing a slot in the design summit next week in\n> Atlanta (proposal deadline was April 20th, and the scheduling has all\n> been finalized at this stage).\n> \n> However, we do have a project pod space available for ad-hoc overflow\n> sessions. I would suggest that we organize something on this theme\n> after the main ceilometer track[1] has completed, say on the Thursday\n> or Friday. Please reach out on IRC to discuss availability for this\n> and we\'ll work out something around remote participation.\n> \n> Thanks,\n> Eoghan\n> \n> [1] http://junodesignsummit.sched.org/overview/type/ceilometer\n> \n> ----- Original Message -----\n>> Thanks to everyone for the feedback. I agree that this falls under the\n>> Telemetry Program and I have moved the blueprint.\n>> \n>> You can find it here:\n>> https://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service\n>> Wiki page: https://wiki.openstack.org/wiki/MaaS\n>> Etherpad: https://etherpad.openstack.org/p/MaaS\n>> \n>>> I can go over the project with you as well as others that are interested.\n>>> We would like to start working with other open-source developers. I\'ll\n>>> also be at the Summit next week.\n>> Roland,\n>> \n>> I currently have no plans to be at the Summit next week. However, I\n>> would be interested in exploring what you have already done and learn\n>> from it.  Maybe we can schedule a meeting? You can always contact me on\n>> IRC (aviau) or by e-mail at alexandre.viau at savoirfairelinux.com\n>> \n>> For now, I think we should focus on the use cases. I invite all of you\n>> to help us list them on the Etherpad.\n>> \n>> Alexandre\n>> \n>> \n>> \n>> On 14-05-05 12:00 PM, Hochmuth, Roland M wrote:\n>>> Alexandre, Great timing on this question and I agree with your proposal. I\n>>> work for HP and we are just about to open-source a project for Monitoring\n>>> as a Service (MaaS), called \"Jahmon\". Jahmon is based on our\n>>> customer-facing monitoring as a service solution and internal monitoring\n>>> projects.\n>>> \n>>> \n>>> Jahmon is a multi-tenant, highly performant, scalable, reliable and\n>>> fault-tolerant monitoring solution that scales to service provider levels\n>>> of metrics throughput. It has a RESTful API that is used for\n>>> storing/querying metrics, creating compound alarms, querying alarm\n>>> state/history, sending notifications and more.\n>>> \n>>> I can go over the project with you as well as others that are interested.\n>>> We would like to start working with other open-source developers. I\'ll\n>>> also be at the Summit next week.\n>>> \n>>> Regards --Roland\n>>> \n>>> \n>>> On 5/4/14, 1:37 PM, \"John Dickinson\" <me at not.mn> wrote:\n>>> \n>>>> One of the advantages of the program concept within OpenStack is that\n>>>> separate code projects with complementary goals can be managed under the\n>>>> same program without needing to be the same codebase. The most obvious\n>>>> example across every program are the \"server\" and \"client\" projects under\n>>>> most programs.\n>>>> \n>>>> This may be something that can be used here, if it doesn\'t make sense to\n>>>> extend the ceilometer codebase itself.\n>>>> \n>>>> --John\n>>>> \n>>>> \n>>>> \n>>>> \n>>>> \n>>>> On May 4, 2014, at 12:30 PM, Denis Makogon <dmakogon at mirantis.com> wrote:\n>>>> \n>>>>> Hello to All.\n>>>>> \n>>>>> I also +1 this idea. As I can see, Telemetry program (according to\n>>>>> Launchpad) covers the process of the infrastructure metrics (networking,\n>>>>> etc) and in-compute-instances metrics/monitoring.\n>>>>> So, the best option, I guess, is to propose add such great feature to\n>>>>> Ceilometer. In-compute-instance monitoring will be the great value-add\n>>>>> to upstream Ceilometer.\n>>>>> As for me, it\'s a good chance to integrate well-known production ready\n>>>>> monitoring systems that have tons of specific plugins (like Nagios etc.)\n>>>>> \n>>>>> Best regards,\n>>>>> Denis Makogon\n>>>>> \n>>>>> ???????????, 4 ??? 2014 ?. ???????????? John Griffith ???????:\n>>>>> \n>>>>> \n>>>>> \n>>>>> On Sun, May 4, 2014 at 9:37 AM, Thomas Goirand <zigo at debian.org> wrote:\n>>>>> On 05/02/2014 05:17 AM, Alexandre Viau wrote:\n>>>>>> Hello Everyone!\n>>>>>> \n>>>>>> My name is Alexandre Viau from Savoir-Faire Linux.\n>>>>>> \n>>>>>> We have submited a Monitoring as a Service blueprint and need\n>>>>> feedback.\n>>>>>> Problem to solve: Ceilometer\'s purpose is to track and\n>>>>> *measure/meter* usage information collected from OpenStack components\n>>>>> (originally for billing). While Ceilometer is usefull for the cloud\n>>>>> operators and infrastructure metering, it is not a *monitoring* solution\n>>>>> for the tenants and their services/applications running in the cloud\n>>>>> because it does not allow for service/application-level monitoring and\n>>>>> it ignores detailed and precise guest system metrics.\n>>>>>> Proposed solution: We would like to add Monitoring as a Service to\n>>>>> Openstack\n>>>>>> Just like Rackspace\'s Cloud monitoring, the new monitoring service -\n>>>>> lets call it OpenStackMonitor for now -  would let users/tenants keep\n>>>>> track of their ressources on the cloud and receive instant notifications\n>>>>> when they require attention.\n>>>>>> This RESTful API would enable users to create multiple monitors with\n>>>>> predefined checks, such as PING, CPU usage, HTTPS and SMTP or custom\n>>>>> checks performed by a Monitoring Agent on the instance they want to\n>>>>> monitor.\n>>>>>> Predefined checks such as CPU and disk usage could be polled from\n>>>>> Ceilometer. Other predefined checks would be performed by the new\n>>>>> monitoring service itself. Checks such as PING could be flagged to be\n>>>>> performed from multiple sites.\n>>>>>> Custom checks would be performed by an optional Monitoring Agent.\n>>>>> Their results would be polled by the monitoring service and stored in\n>>>>> Ceilometer.\n>>>>>> If you wish to collaborate, feel free to contact me at\n>>>>> alexandre.viau at savoirfairelinux.com\n>>>>>> The blueprint is available here:\n>>>>> https://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-servi\n>>>>> ce\n>>>>>> Thanks!\n>>>>> I would prefer if monitoring capabilities was added to Ceilometer rather\n>>>>> than adding yet-another project to deal with.\n>>>>> \n>>>>> What\'s the reason for not adding the feature to Ceilometer directly?\n>>>>> \n>>>>> Thomas\n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>>> ?I\'d also be interested in the overlap between your proposal and\n>>>>> Ceilometer.  It seems at first thought that it would be better to\n>>>>> introduce the monitoring functionality in to Ceilometer and make that\n>>>>> project more diverse as opposed to yet another project.?\n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/a5641cba/attachment-0001.html>\n\n',NULL,NULL),('<0E4EA239-1FE5-4E9F-9FDC-0407309BF06D@kent.ac.uk>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 15:31:33',0,'2012-11-20 15:31:33',NULL,'[openstack-dev] Adding Identity Providers to the Keystone\n	Service Catalog','Hi All,\n\nI\'ve put the document on Google docs and added the URL.\n\nKristy\n\nOn 20 Nov 2012, at 15:07, David Chadwick wrote:\n\n> Hi Adam\n> \n> we dont know how to create a full blueprint doc that the URL can point to. YOu did this for me for the federation one\n> \n> regards\n> \n> David\n> \n> \n> On 19/11/2012 21:55, Adam Young wrote:\n>> On 11/19/2012 03:34 PM, K.W.S.Siu wrote:\n>>> Hello,\n>>> \n>>> We have added a blueprint regarding including Identity Providers in\n>>> the service catalog.\n>>> \n>>> Many thanks,\n>>> \n>>> Kristy\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> Interesting concept.  It makes sense.  I would like to see more details\n>> in the blueprint.\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<50AB9CB2.5000603@kent.ac.uk>',NULL),('<0E504D36-0992-477E-BB6E-22A841313696@rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-03 22:42:04',0,'2014-02-03 22:42:04',NULL,'[Openstack] [User-committee] Formulate application developer\n oriented questions for the user survey','Some more potential questions.\n\n1. What development environment do you use?\n[ ] Eclipse\n[ ] Intellij IDEA\n[ ] Visual Studio\n[ ] Sublime\n[ ] vim\nOther\n\n2. What tools are you using to deploy/configure your application?\n[ ] Ansible\n[ ] Chef\n[ ] Puppet\n[ ] SaltStack\nOther\n\n3. What do you struggle with when developing and deploying applications on OpenStack?\nFree form answers.\n\nI?ll try to aggregate all of the Q&A into one list this week.\n\nThanks,\nEverett\n\n\nOn Jan 21, 2014, at 11:55 AM, Everett Toews <everett.toews at rackspace.com> wrote:\n\n> On Jan 21, 2014, at 10:29 AM, Dave Neary wrote:\n> \n>> On 01/21/2014 02:25 AM, Everett Toews wrote:\n>>> There are a number of issues that stand out to me but before getting\n>>> into them some quick definitions to be clear what I\'m talking about.\n>>> \n>>> OpenStack developer = developer working on OpenStack itself\n>>> OpenStack operator = operator deploying/maintaining an OpenStack cloud\n>>> application developer = developer working on application being deployed\n>>> on an OpenStack cloud\n>>> application operator = operator deploying/maintaining an application on\n>>> an OpenStack cloud\n>>> users = any of OpenStack operator, application developer, application\n>>> operator\n>> \n>> It would be really useful, I think, to match these up with some of the\n>> personas we have, so that we are all talking about the same thing\n>> (there\'s a big difference between someone deploying a small private\n>> cloud and someone operating a large public cloud, for example).\n> \n> I attended your session on personas at the HK Summit. I was the guy ranting about SDKs from the back. ;)\n> \n> The personas are definitely useful and I think we could use them to help inform the definitions of the above. Here\'s what I\'m starting to envision for the survey.\n> \n> On the About You page [1] we update the What best describes your involvement with OpenStack? section as follows\n> \n> [ ] OpenStack cloud service provider - provides public or hosted private cloud services for other organizations\n> [ ] Ecosystem vendor - provides software or solutions that enable others to build or run OpenStack clouds\n> [ ] Private cloud operator - runs an OpenStack private cloud for their own organization\n> [ ] Application developer - has API or dashboard credentials and deploys/maintains an application running on an OpenStack cloud\n> [ ] Application operator - has API or dashboard credentials and develops an application running on an OpenStack cloud\n> \n> If the survey taker checks Application developer or Application operator then they are shown a survey page with the questions we are formulating here instead of/in addition to the About Your OpenStack Deployments page.\n> \n> I don\'t think we want to have the role definitions above too long but anything can help.\n> \n> Can you link us to the personas work and how they might map to the roles as above?\n> \n> [sidebar]\n> It seems the About You page already makes the distinction between someone deploying a small private cloud and someone operating a large public cloud. However, I think the line between \"...or hosted private cloud services for other organizations\" and \"runs an OpenStack private cloud for their own organization\" is pretty thin. \"hosted private cloud services for other organizations\" sounds like a small-scale public cloud to me. The real distinction being whether you\'re doing it for your org or for others. The questions on the About Your OpenStack Deployments page make the distinction between scale.\n> \n> They could be reworded as\n> \n> [ ] OpenStack operator for a public cloud - provides public or hosted private cloud services for other organizations\n> [ ] OpenStack operator for a private cloud - runs an OpenStack private cloud for their own organization\n> \n> This is apart from the app dev oriented discussion and hence the sidebar.\n> [/sidebar]\n> \n> Thanks,\n> Everett\n> \n> [1] https://www.openstack.org/user-survey/OrgInfo\n> _______________________________________________\n> User-committee mailing list\n> User-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n\n\n','<2D8A6842-2568-4EB5-BB46-33B1713A109F@RACKSPACE.COM>',NULL),('<0E504D36-0992-477E-BB6E-22A841313696@rackspace.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-02-03 22:42:04',0,'2014-02-03 22:42:04',NULL,'[User-committee] [Openstack] Formulate application developer\n oriented questions for the user survey','Some more potential questions.\n\n1. What development environment do you use?\n[ ] Eclipse\n[ ] Intellij IDEA\n[ ] Visual Studio\n[ ] Sublime\n[ ] vim\nOther\n\n2. What tools are you using to deploy/configure your application?\n[ ] Ansible\n[ ] Chef\n[ ] Puppet\n[ ] SaltStack\nOther\n\n3. What do you struggle with when developing and deploying applications on OpenStack?\nFree form answers.\n\nI?ll try to aggregate all of the Q&A into one list this week.\n\nThanks,\nEverett\n\n\nOn Jan 21, 2014, at 11:55 AM, Everett Toews <everett.toews at rackspace.com> wrote:\n\n> On Jan 21, 2014, at 10:29 AM, Dave Neary wrote:\n> \n>> On 01/21/2014 02:25 AM, Everett Toews wrote:\n>>> There are a number of issues that stand out to me but before getting\n>>> into them some quick definitions to be clear what I\'m talking about.\n>>> \n>>> OpenStack developer = developer working on OpenStack itself\n>>> OpenStack operator = operator deploying/maintaining an OpenStack cloud\n>>> application developer = developer working on application being deployed\n>>> on an OpenStack cloud\n>>> application operator = operator deploying/maintaining an application on\n>>> an OpenStack cloud\n>>> users = any of OpenStack operator, application developer, application\n>>> operator\n>> \n>> It would be really useful, I think, to match these up with some of the\n>> personas we have, so that we are all talking about the same thing\n>> (there\'s a big difference between someone deploying a small private\n>> cloud and someone operating a large public cloud, for example).\n> \n> I attended your session on personas at the HK Summit. I was the guy ranting about SDKs from the back. ;)\n> \n> The personas are definitely useful and I think we could use them to help inform the definitions of the above. Here\'s what I\'m starting to envision for the survey.\n> \n> On the About You page [1] we update the What best describes your involvement with OpenStack? section as follows\n> \n> [ ] OpenStack cloud service provider - provides public or hosted private cloud services for other organizations\n> [ ] Ecosystem vendor - provides software or solutions that enable others to build or run OpenStack clouds\n> [ ] Private cloud operator - runs an OpenStack private cloud for their own organization\n> [ ] Application developer - has API or dashboard credentials and deploys/maintains an application running on an OpenStack cloud\n> [ ] Application operator - has API or dashboard credentials and develops an application running on an OpenStack cloud\n> \n> If the survey taker checks Application developer or Application operator then they are shown a survey page with the questions we are formulating here instead of/in addition to the About Your OpenStack Deployments page.\n> \n> I don\'t think we want to have the role definitions above too long but anything can help.\n> \n> Can you link us to the personas work and how they might map to the roles as above?\n> \n> [sidebar]\n> It seems the About You page already makes the distinction between someone deploying a small private cloud and someone operating a large public cloud. However, I think the line between \"...or hosted private cloud services for other organizations\" and \"runs an OpenStack private cloud for their own organization\" is pretty thin. \"hosted private cloud services for other organizations\" sounds like a small-scale public cloud to me. The real distinction being whether you\'re doing it for your org or for others. The questions on the About Your OpenStack Deployments page make the distinction between scale.\n> \n> They could be reworded as\n> \n> [ ] OpenStack operator for a public cloud - provides public or hosted private cloud services for other organizations\n> [ ] OpenStack operator for a private cloud - runs an OpenStack private cloud for their own organization\n> \n> This is apart from the app dev oriented discussion and hence the sidebar.\n> [/sidebar]\n> \n> Thanks,\n> Everett\n> \n> [1] https://www.openstack.org/user-survey/OrgInfo\n> _______________________________________________\n> User-committee mailing list\n> User-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n\n\n','<2D8A6842-2568-4EB5-BB46-33B1713A109F@RACKSPACE.COM>',NULL),('<0E545CAD-0859-47B7-87C9-01D63A12AF56@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-02 14:09:24',0,'2014-05-02 14:09:24',NULL,'[openstack-dev] [neutron] explanations on the current state\n	of	config file handling','\nOn May 2, 2014, at 7:39 AM, Sean Dague <sean at dague.net> wrote:\n\n> Some non insignificant number of devstack changes related to neutron\n> seem to be neutron plugins having to do all kinds of manipulation of\n> extra config files. The grenade upgrade issue in neutron was because of\n> some placement change on config files. Neutron seems to have *a ton* of\n> config files and is extremely sensitive to their locations/naming, which\n> also seems like it ends up in flux.\n\nWe have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited.  One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2].  We?re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file.  This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script.  I?d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2.\n\n> \n> Is there an overview somewhere to explain this design point?\n\nSadly no.  It?s a historical convention that needs to be reconsidered.\n\n> \n> All the other services have a single config config file designation on\n> startup, but neutron services seem to need a bunch of config files\n> correct on the cli to function (see this process list from recent\n> grenade run - http://paste.openstack.org/show/78430/ note you will have\n> to horiz scroll for some of the neutron services).\n> \n> Mostly it would be good to understand this design point, and if it could\n> be evolved back to the OpenStack norm of a single config file for the\n> services.\n> \n\n+1 to evolving into a more limited set of files.  The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don?t consolidate and use config-dir more.  In some cases, the files share a set of common options and in other cases there are divergent options [3][4].   Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone.  \n\nTo throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files.  \n\nNeutron Servers/Network Nodes\n/etc/neutron.d\n	neutron.conf  (Common Options)\n	server.d (all plugin/service config files )\n	service.d (all service config files)\n\n\nHypervisor Agents\n/etc/neutron\n	neutron.conf\n	agent.d (Individual agent config files)\n\n\nThe invocations would then be static:\n\nneutron-server ?config-file /etc/neutron/neutron.conf ?config-dir /etc/neutron/server.d\n\nService Agents:\nneutron-l3-agent ?config-file /etc/neutron/neutron.conf ?config-dir /etc/neutron/service.d\n\nHypervisors (assuming the consolidates L2 is finished this cycle):\nneutron-l2-agent ?config-file /etc/neutron/neutron.conf ?config-dir /etc/neutron/agent.d\n\nThoughts?\n\nmark\n\n[1] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/\n[2] http://packages.ubuntu.com/search?keywords=neutron&searchon=names&suite=trusty&section=all\n[3] https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2\n[4]https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3\n\n','<536383EA.5090401@dague.net>',NULL),('<0E59E240-1A79-40DF-BD63-64CF5E206C3E@mbl.edu>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-20 13:42:00',-18000,'2011-11-20 18:42:00',NULL,'[Openstack-operators] nova-volume / iSCSI backed LVM','Hi all,\nI have a question relating to nova-volume, and provisioning block devices as storage for VMs. As I understand it from the documentation, nova-volume will take a block device with LVM on it, and then become an iSCSI target to share the logical volumes to compute nodes. I also understand that there is another process for using an HP lefthand SAN or solaris iSCSI setup, whereby nova-volume can interact with APIs for volume creation on the SAN itself.\n\nI have a dell iSCSI SAN, and I can see that I\'d be able to mount a LUN from the SAN on my nova-volume node, then go through the documented process of creating an LVM on this LUN and having nova-volume re-share it over iSCSI to the compute nodes, but what I\'m wondering is whether I can have the compute nodes simple connect to the iSCSI SAN to access these volumes (which would be created and managed by nova-volume still), rather than connect each compute node to the iSCSI target which nova-volume presents? I imagine with this setup, I could take advantage of the SAN\'s HA and performance benefits.\n\nHope that makes sense..\n\nCheers,\nAnthony\n\n\n---\nAnthony Goddard\nWoods Hole Marine Biological Laboratory\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111120/5d6deea1/attachment.html>\n\n',NULL,NULL),('<0E665E82-3475-4282-BD3D-47A46B6FDD1B@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-18 14:05:04',-18000,'2014-11-18 19:05:04',NULL,'[openstack-dev] Quota management and enforcement across projects','\nOn Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:\n\n> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:\n>> I?ve spent a bit of time thinking about the resource ownership issue.\n>> The challenge there is we don?t currently have any libraries that\n>> define tables in the schema of an application. I think that?s a good\n>> pattern to maintain, since it avoids introducing a lot of tricky\n>> issues like how to manage migrations for the library, how to ensure\n>> they are run by the application, etc. The fact that this common quota\n>> thing needs to store some data in a schema that it controls says to me\n>> that it is really an app and not a library. Making the quota manager\n>> an app solves the API definition issue, too, since we can describe a\n>> generic way to configure quotas and other applications can then use\n>> that API to define specific rules using the quota manager?s API.\n>> \n>> I don?t know if we need a new application or if it would make sense\n>> to, as with policy, add quota management features to keystone. A\n>> single well-defined app has some appeal, but there?s also a certain\n>> amount of extra ramp-up time needed to go that route that we wouldn?t\n>> need if we added the features directly to keystone.\n> \n> I\'ll also point out that it was largely because of the storage needs\n> that I chose to propose Boson[1] as a separate app, rather than as a\n> library.  Further, the dimensions over which quota-covered resources\n> needed to be tracked seemed to me to be complicated enough that it would\n> be better to define a new app and make it support that one domain well,\n> which is why I didn\'t propose it as something to add to Keystone.\n> Consider: nova has quotas that are applied by user, other quotas that\n> are applied by tenant, and even some quotas on what could be considered\n> sub-resources?a limit on the number of security group rules per security\n> group, for instance.\n> \n> My current feeling is that, if we can figure out a way to make the quota\n> problem into an acceptable library, that will work; it would probably\n> have to maintain its own database separate from the client app and have\n> features for automatically managing the schema, since we couldn\'t\n> necessarily rely on the client app to invoke the proper juju there.  If,\n> on the other hand, that ends up failing, then the best route is probably\n> to begin by developing a separate app, like Boson, as a PoC; then, after\n> we have some idea of just how difficult it is to actually solve the\n> problem, we can evaluate whether it makes sense to actually fold it into\n> a service like Keystone, or whether it should stand on its own.\n> \n> (Personally, I think Boson should be created and should stand on its\n> own, but I also envision using it for purposes outside of OpenStack?)\n\nThanks for mentioning Boson again. I?m embarrassed that I completely forgot about the fact that you mentioned this at the summit.\n\nI?ll have to look at the proposal more closely before I comment in any detail, but I take it as a good sign that we?re coming back around to the idea of solving this with an app instead of a library.\n\nDoug\n\n> \n> Just my $.02?\n> \n> [1] https://wiki.openstack.org/wiki/Boson\n> -- \n> Kevin L. Mitchell <kevin.mitchell at rackspace.com>\n> Rackspace\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1416269934.3223.27.camel@einstein.kev>',NULL),('<0E7FD18E-E446-43C6-B94D-4493D161475F@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-11 09:41:53',-28800,'2013-02-11 17:41:53',NULL,'[openstack-dev] DirectConsumer\'s mirrored queue declaration','Kei/Ray:\n\nI recieved this response from Eugene about the mirrored queue but I just noticed it never hit the list. It was cc\'d to the list but i think it was sent from an email that is not subscribed. It looks like we are fine making it mirrrored.\n\nVish\n\nOn Feb 1, 2013, at 9:05 PM, Eugene Kirpichov <ekirpichov at gmail.com> wrote:\n\n> Hi,\n> \n> Sorry, I haven\'t been paying much attention to the openstack-dev mailing lists lately, as I changed company.\n> \n> So, on the topic: Yes, all queues, including reply queues, must be mirrored; if some aren\'t, that\'s a bug.\n> \n> \n> On Fri, Feb 1, 2013 at 7:32 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> It was Eugene Kirpichov,\n> \n> I\'ve added him to the cc in case he is filtering the -dev mail.\n> \n> Vish\n> \n> On Jan 31, 2013, at 9:33 PM, Ray Pekowski <pekowski at gmail.com> wrote:\n> \n>> On Thu, Jan 31, 2013 at 7:51 PM, <masumotok at nttdata.co.jp> wrote:\n>> What I am trying to say is, TopicConsumer\'s queue is declared with\n>> {\'x-ha-policy\': \'all\'}\n>> <snip> \n>> We can see same declaration at FanoutConsumer, but not DirectConsumer.\n>> As you know, rpc.call() send request through TopicConsumer, and return values  thorough DirectConsumer. So if TopicConsumer is mirrored, DirectConsumer also should be mirrored, I think.\n>> \n>> Does anyone know who made the changes for this x-ha-policy/mirroring code in impl_kombu.py?  We want to know if leaving mirror off of the RPC reply queue was intended or an oversight?  And if intended, why?\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Eugene Kirpichov\n> http://www.linkedin.com/in/eugenekirpichov\n> http://jkff.info/software/timeplotters - my performance visualization tools\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130211/cd978a57/attachment.html>\n\n','<CANVKUrVCGWc1q-3kvNezLx8=2-WLSnw68oDQTrH0vYdeCJqbcw@mail.gmail.com>',NULL),('<0E856257-0A0B-4BB1-B08A-A7831E6D697F@jamezpolley.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 19:04:15',39600,'2014-02-26 08:04:15',NULL,'[openstack-dev] [Tripleo] tripleo-cd-admins team update /\n	contact info question','I\'m not sure how well it would work here, but I\'ve used Pagerduty.com for something similar before.\n\nThe big up side of pagerduty is that it is pretty good at contacting people who aren\'t at their computers. \n\nIt supports email notifications and webhooks for people who want to lots of control over what to do with alerts; push notifications to iOS or Android; and SMS or phone call as a last resort. Each person can configure their own alerts to suit them\n\nIt handles escalating unhandled alerts, including looping back to the start if it can\'t reach anyone.\n\nIt allows incidents to be handed over to arbitrary people regardless of who the roster says is on call, and for schedule overrides when a shift has to be reassigned.\n\nIncidents can be created via REST, email, or (I think) webhooks, so it\'s easy for users or for automated systems to raise an alarm\n\nIt has some drawbacks: it would force us to define a rotation (or several rotations, one for each region, if we want to follow the sun), and someone needs to pay for it.\n\nI think it handles most of what we want though. It gives infra admins a bat-signal to request urgent help, and it gives us a way to ping other team members when we need to hand over. It isn\'t very good for $randoms asking for low-priority issues though - it treats every incident as equally urgent.\n\nI haven\'t used it, but opsgenie seems to have a similar set of features (more, if https://www.opsgenie.com/pagerduty is to be believed) \n\n\n> On 26 Feb 2014, at 9:30 am, Robert Collins <robertc at robertcollins.net> wrote:\n> \n> In the tripleo meeting today we re-affirmed that the tripleo-cd-admins\n> team is aimed at delivering production-availability clouds - thats how\n> we know the the tripleo program is succeeding (or not !).\n> \n> So if you\'re a member of that team, you\'re on the hook - effectively\n> on call, where production issues will take precedence over development\n> / bug fixing etc.\n> \n> We have the following clouds today:\n> cd-undercloud (baremetal, one per region)\n> cd-overcloud (KVM in the HP region, not sure yet for the RH region) -\n> multi region.\n> ci-overcloud (same as cd-overcloud, and will go away when cd-overcloud\n> is robust enough).\n> \n> And we have two users:\n> - TripleO ATCs, all of whom are eligible for accounts on *-overcloud\n> - TripleO reviewers, indirectly via openstack-infra who provide 99%\n> of the load on the clouds\n> \n> Right now when there is a problem, there\'s no clearly defined \'get\n> hold of someone\' mechanism other than IRC in #tripleo.\n> \n> And thats pretty good since most of the admins are on IRC most of the time.\n> \n> But.\n> \n> There are two holes - a) what if its sunday evening :) and b) what if\n> someone (for instance Derek) has been troubleshooting a problem, but\n> needs to go do personal stuff, or you know, sleep. There\'s no reliable\n> defined handoff mechanism.\n> \n> So - I think we need to define two things:\n>  - a stock way for $randoms to ask for support w/ these clouds that\n> will be fairly low latency and reliable.\n>  - a way for us to escalate to each other *even if folk happen to be\n> away from the keyboard at the time*.\n> And possibly a third:\n>  - a way for openstack-infra admins to escalate to us in the event of\n> OMG things happening. Like, we send 1000 VMs all at once at their git\n> mirrors or something.\n> \n> And with that lets open the door for ideas!\n> \n> -Rob\n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140226/bb584067/attachment.html>\n\n','<CAJ3HoZ1NP9XDRv-9YZnQqWfX-h2N-2dCo2_xMmKQmw6DUyhXaA@mail.gmail.com>',NULL),('<0e8901d018cf$e6eddeb0$b4c99c10$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 09:30:39',28800,'2014-12-16 01:30:39',NULL,'[openstack-dev] [Openstack] [Ceilometer] [API] Batch alarm\n	creation','Yes Ryan, that\'s exactly what I\'m thinking. Glad to know that we have the same opinion :)\n\n\nBR\nKurt\n\n\n-----????-----\n???: Ryan Brown [mailto:rybrown at redhat.com] \n????: 2014?12?12? 23:30\n???: openstack-dev at lists.openstack.org\n??: Re: [openstack-dev] [Openstack] [Ceilometer] [API] Batch alarm creation\n\nOn 12/12/2014 03:37 AM, Rao Dingyuan wrote:\n> Hi Eoghan and folks,\n> \n> I\'m thinking of adding an API to create multiple alarms in a batch.\n> \n> I think adding an API to create multiple alarms is a good option to solve the problem that once an *alarm target* (a vm or a new group of vms) is created, multiple requests will be fired because multiple alarms are to be created.\n> \n> In the our current project, this requiement is specially urgent since our alarm target is one VM, and 6 alarms are to be created when one VM is created.\n> \n> What do you guys think?\n> \n> \n> Best Regards,\n> Kurt Rao\n\nAllowing batch operations is definitely a good idea, though it may not be a solution to all of the problems you outlined.\n\nOne way to batch object creations would be to give clients the option to POST a collection of alarms instead of a single alarm. Currently your API looks like[1]:\n\nPOST /v2/alarms\n\nBODY:\n{\n  \"alarm_actions\": ...\n  ...\n}\n\nFor batches you could modify your API to accept a body like:\n\n{\n  \"alarms\": [\n    {\"alarm_actions\": ...},\n    {\"alarm_actions\": ...},\n    {\"alarm_actions\": ...},\n    {\"alarm_actions\": ...}\n  ]\n}\n\nIt could (pretty easily) be a backwards-compatible change since the schemata don\'t conflict, and you can even add some kind of a \"batch\":true flag to make it explicit that the user wants to create a collection. The API-WG has a spec[2] out right now explaining the rationale behind collection representations.\n\n\n[1]:\nhttp://docs.openstack.org/developer/ceilometer/webapi/v2.html#post--v2-alarms\n[2]:\nhttps://review.openstack.org/#/c/133660/11/guidelines/representation_structure.rst,unified\n> \n> \n> \n> ----- Original -----\n> ???: Eoghan Glynn [mailto:eglynn at redhat.com]\n> ????: 2014?12?3? 20:34\n> ???: Rao Dingyuan\n> ??: openstack at lists.openstack.org\n> ??: Re: [Openstack] [Ceilometer] looking for alarm best practice - \n> please help\n> \n> \n> \n>> Hi folks,\n>>\n>>\n>>\n>> I wonder if anyone could share some best practice regarding to the \n>> usage of ceilometer alarm. We are using the alarm \n>> evaluation/notification of ceilometer and we don?t feel very well of \n>> the way we use it. Below is our\n>> problem:\n>>\n>>\n>>\n>> ============================\n>>\n>> Scenario:\n>>\n>> When cpu usage or memory usage above a certain threshold, alerts \n>> should be displayed on admin?s web page. There should be a 3 level \n>> alerts according to meter value, namely notice, warning, fatal. \n>> Notice means the meter value is between 50% ~ 70%, warning means \n>> between 70% ~ 85% and fatal means above 85%\n>>\n>> For example:\n>>\n>> * when one vm?s cpu usage is 72%, an alert message should be \n>> displayed saying\n>> ?Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above 70%?.\n>>\n>> * when one vm?s memory usage is 90%, another alert message should be \n>> created saying ?Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] \n>> memory usage is above 85%?\n>>\n>>\n>>\n>> Our current Solution:\n>>\n>> We used ceilometer alarm evaluation/notification to implement this. \n>> To distinguish which VM and which meter is above what value, we?ve \n>> created one alarm for each VM by each condition. So, to monitor 1 VM,\n>> 6 alarms will be created because there are 2 meters and for each meter there are 3 levels.\n>> That means, if there are 100 VMs to be monitored, 600 alarms will be \n>> created.\n>>\n>>\n>>\n>> Problems:\n>>\n>> * The first problem is, when the number of meters increases, the \n>> number of alarms will be multiplied. For example, customer may want \n>> alerts on disk and network IO rates, and if we do that, there will be\n>> 4*3=12 alarms for each VM.\n>>\n>> * The second problem is, when one VM is created, multiple alarms will \n>> be created, meaning multiple http requests will be fired. In the case \n>> above, 6 HTTP requests will be needed once a VM is created. And this \n>> number also increases as the number of meters goes up.\n> \n> One way of reducing both the number of alarms and the volume of notifications would be to group related VMs, if such a concept exists in your use-case.\n> \n> This is effectively how Heat autoscaling uses ceilometer, alarming on the average of some statistic over a set of instances (as opposed to triggering on individual instances).\n> \n> The VMs could be grouped by setting user-metadata of form:\n> \n>   nova boot ... --meta metering.my_server_group=foobar\n> \n> Any user-metadata prefixed with \'metering.\' will be preserved by ceilometer in the resource_metadata.user_metedata stored for each sample, so that it can used to select the statistics on which the alarm is based, e.g.\n> \n>   ceilometer alarm-threshold-create --name cpu_high_foobar \\\n>     --description \'warning: foobar instance group running hot\' \\\n>     --meter-name cpu_util --threshold 70.0 \\\n>     --comparison-operator gt --statistic avg \\\n>     ...\n>     --query metadata.user_metedata.my_server_group=foobar\n> \n> This approach is of course predicated on the there being some natural grouping relation between instances in your environment.\n> \n> Cheers,\n> Eoghan\n> \n> \n>> =============================\n>>\n>>\n>>\n>> Do anyone have any suggestions?\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>> Best Regards!\n>>\n>> Kurt Rao\n>>\n>>\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n--\nRyan Brown / Software Engineer, Openstack / Red Hat, Inc.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n',NULL,NULL),('<0E9D888C-4BB8-4924-9B85-45DB52C4CD34@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 11:33:27',-18000,'2014-12-02 16:33:27',NULL,'[openstack-dev] cliff 1.9.0 released','The Oslo team is pleased to announce release 1.9.0 of cliff.\n\nThis is primarily a bug-fix release, but does include a requirements update.\n\nFor more details, please see the git log history below and\n https://launchpad.net/python-cliff/+milestone/1.9.0\n\nPlease report issues through launchpad:\n https://bugs.launchpad.net/python-cliff\n\n----------------------------------------\n\nChanges in openstack/cliff  1.8.0..1.9.0\n\nf6e9bbd print the real error cmd argument\na5fd24d Updated from global requirements\n\n  diffstat (except docs and test files):\n\n cliff/commandmanager.py            | 3 ++-\n requirements.txt                   | 2 +-\n 3 files changed, 5 insertions(+), 2 deletions(-)\n\n  Requirements updates:\n\n diff --git a/requirements.txt b/requirements.txt\n index 4d3ccc9..bf06e82 100644\n --- a/requirements.txt\n +++ b/requirements.txt\n @@ -10 +10 @@ six>=1.7.0\n -stevedore>=0.14\n +stevedore>=1.1.0  # Apache-2.0\n\n\n',NULL,NULL),('<0EA5C4C0-A249-4C4B-9F5A-AFE865D5FEB7@enovance.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-02 13:11:08',7200,'2013-07-02 11:11:08',NULL,'[Openstack-operators] HA configuration in OpenStack','Thanks a lot Jay!\n\n????\nS?bastien Han\nCloud Engineer\n\n\"Always give 100%. Unless you\'re giving blood.\"\n\n\n\n\n\n\n\n\n\n\nPhone : +33 (0)1 49 70 99 72 ? Mobile : +33 (0)6 52 84 44 70\nEmail : sebastien.han at enovance.com ? Skype : han.sbastien\nAddress : 10, rue de la Victoire ? 75009 Paris\nWeb : www.enovance.com ? Twitter : @enovance\n\nOn Jun 18, 2013, at 6:44 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On 06/18/2013 09:07 AM, Sebastien Han wrote:\n>> Hi Jay,\n>> \n>> Could you please elaborate on this one:\n>> \n>>> * do NOT use the SQL driver for Keystone catalog. Use the templated\n>>> catalog driver.\n> \n> If you have multiple regions and availability zones returning the same service types  -- e.g. compute -- and you point your nova|quantum|cinder|glanceclient to a Keystone endpoint in one of those zones that is sharing the identity database with other zones, then the Keystone endpoint will return the service catalog for all of the regions and zones. At this point, the X-client will happily go to the first matching service type endpoint for its service type, irrespective of which region or availability zone you actually originally hit.\n> \n> Using the templated catalog driver means you can set up your Keystone endpoint to only return the region and availability zone that that particular endpoint is in, and not everything in the services and endpoints tables.\n> \n> It\'s the reason that I brought up at the design summit that the service catalog is pretty much a broken model, and proposed what I thought was a relatively minor fix/change to the API:\n> \n> https://review.openstack.org/#/c/27563/\n> \n> That was subsequently poo-poo\'d.\n> \n> Best,\n> -jay\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130702/f51ad71c/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image.png\nType: image/png\nSize: 6560 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130702/f51ad71c/attachment.png>\n\n','<51C08E5C.9030807@gmail.com>',NULL),('<0EAB70AF-7D05-4510-BB29-E5865583926F@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 18:37:09',0,'2014-05-27 18:37:09',NULL,'[openstack-dev] [Neutron] Seeking opinions on scope\n	of	code	refactoring...','So I hit some more complexity, when I got to the IPSec connection resource?s update API?\n\nI was doing code like this:\n\nIn VPN plugin:\n    def create_ipsec_site_connection(self, context, ipsec_site_connection):\n        driver = self._get_driver_for_ipsec_site_connection(\n            context, ipsec_site_connection)\n        driver.validate_create_ipsec_site_connection(context,\n                                                     ipsec_site_connection)\n        ipsec_site_connection = super(\n            VPNDriverPlugin, self).create_ipsec_site_connection(\n                context, ipsec_site_connection)\n        driver.apply_create_ipsec_site_connection(context,\n                                                  ipsec_site_connection)\n        return ipsec_site_connection\n\n\nIn ABC for service drvier:\n\n    def validate_create_ipsec_site_connection(self, context,\n                                              ipsec_site_connection):\n        ipsec_sitecon = ipsec_site_connection[\'ipsec_site_connection\']\n        dpd = ipsec_sitecon.get(\'dpd\', {})\n        ipsec_sitecon[\'dpd_action\'] = dpd.get(\'action\', \'hold\')\n        ipsec_sitecon[\'dpd_interval\'] = dpd.get(\'interval\', 30)\n        ipsec_sitecon[\'dpd_timeout\'] = dpd.get(\'timeout\', 120)\n        self._check_dpd(ipsec_sitecon)\n        self._check_mtu(context,\n                        ipsec_sitecon[\'mtu\'],\n                        ipsec_sitecon[\'vpnservice_id\'])\n\nHowever, when considering the update_ipsec_site_connection() API, I realized that there could be multiple requests coming in to change the same connection?s attributes. In this case, validating and then persisting has the issue of incompatible changes being committed (e.g. one client changes DPD interval, and another client changes DPD timeout, such that they fail the _check_mtu() call).\n\nI?m wondering what the thoughts are, regarding how to handle this. One way, I guess, may be do call the service driver validation from within the database logic, like this:\n\nIn VPN plugin\n    def create_ipsec_site_connection(self, context, ipsec_site_connection):\n        driver = self._get_driver_for_ipsec_site_connection(\n            context, ipsec_site_connection)\n        ipsec_site_connection = super(\n            VPNDriverPlugin, self).create_ipsec_site_connection(\n                context, ipsec_site_connection)\n        driver.apply_create_ipsec_site_connection(context,\n                                                  ipsec_site_connection)\n        return ipsec_site_connection\n\nIn Database (pseudo-code)\n    def create_ipsec_site_connection(self, context, ipsec_site_connection):\n        ipsec_sitecon = ipsec_site_connection[\'ipsec_site_connection\']\n        tenant_id = self._get_tenant_id_for_create(context, ipsec_sitecon)\n        with context.session.begin(subtransactions=True):\n            # I guess this would actually call the child class method to\n            # get the driver?\n            driver = self._get_driver_for_ipsec_site_connection(\n                context, ipsec_sitecon)\n            driver.validate_create_ipsec_site_connection(context, ipsec_sitecon)\n\nThe database method is a base class of the VPN plugin class, so I?m thinking, although awkward, it could work. Can?t say I?m comfortable with the call flow here.  Probably could add an abstract method for _get_driver_for_ipsec_site_connection(), so that it cannot be called with an instance of the database class.\n\nI?m not seeing a really clean solution here.\n\n\nAny thoughts?\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn May 27, 2014, at 7:37 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n\n> Thanks for the comments Mandeep!  Responses in-line #PCM\n> \n> On May 23, 2014, at 8:57 PM, Mandeep Dhami <dhami at noironetworks.com> wrote:\n> \n>> My preferences:\n>> \n>> For where, I\'d go with Gary\'s recommendation (A) for two reasons (1) Consistency and (2) I don\'t think it will create any boilerplate requirements since the abstract class provides the default implementation.\n> \n> #PCM Actually, (A) requires a lot of additional code that doesn?t currently exist today. ABC methods would be needed for each validation. In addition, to be consistent, there should be an abstract method for the apply function, and a ?pass? implementation on each of the concrete classes. Overall, it is adding a lot of code, for arguably little benefit.\n> \n> \n>> \n>> For naming, I\'d prefer to go with ML2 terminology for two reasons (1) Again Consistency, and (2) it is then clear what actions are happening within a transaction or outside of it. With a \"validation function\" no \"transaction fence\" is implied by it\'s name - but for any validation that depends on what currently exists in the database, these transaction semantics are important.\n> \n> #PCM I?m still struggling with the naming for question #2.  I must admit, I like the naming of validate/apply because it makes it clear as to what is happening with the calls. With pre-commit/post-commit, it doesn?t indicate what the functions are actually doing, and in one case (for the Cisco VPN service driver) the post-commit will actually be doing a database commit in addition to applying the changes to the device driver (so both the postcommt and apply naming don?t clearly indicate the actions - an alternative would be to call the driver for the commit phase too, but this is a rare case).\n> \n> To muddy it up a bit more, the main functions have no indication in the name that they deal with persisting to the database. The hierarchy currently is (using create_vpnservice...\n> \n> class VPNPluginBase(service_base.ServicePluginBase):   # ABC with Northbound API definition\n>     @abc.abstractmethod\n>     def create_vpnservice(self, context, vpnservice):\n>         pass\n> \n> class VPNPluginDb(vpnaas.VPNPluginBase, base_db.CommonDbMixin):  # DBase concrete class\n>     def create_vpnservice(self, context, vpnservice):\n>         vpns = vpnservice[\'vpnservice\']\n>         tenant_id = self._get_tenant_id_for_create(context, vpns)\n>         with context.session.begin(subtransactions=True):\n>             ?\n> \n> class VPNPlugin(vpn_db.VPNPluginDb):\n>     ?\n> class VPNDriverPlugin(VPNPlugin, vpn_db.VPNPluginRpcDbMixin):  # Plugin child class\n>     def create_vpnservice(self, context, vpnservice):\n>         driver = self._get_driver_for_vpnservice(vpnservice)\n>         super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>         driver.create_vpnservice(context, vpnservice)\n> \n> class VpnDriver(object):  # ABC for service driver\n>     # Nothing for create_vpnservice()\n> \n> class IPsecVPNDriver(service_drivers.VpnDriver):  # Service driver class\n>     # Nothing for create_vpnservice()\n> \n> \n> In the proposals, we talking about a sequence of this (2X) at the plugin:\n> \n>     def create_vpnservice(self, context, vpnservice):\n>         driver = self._get_driver_for_vpnservice(vpnservice)\n>         driver.create_vpnservice_precommit(vpnservice)\n>         super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>         driver.create_vpnservice_postcommit(context, vpnservice)\n> \n> versus this (2Y)?\n> \n>     def create_vpnservice(self, context, vpnservice):\n>         driver = self._get_driver_for_vpnservice(vpnservice)\n>         driver.validate_create_vpnservice(vpnservice)\n>         super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>         driver.apply_create_vpnservice(context, vpnservice)\n> \n> \n> The former makes is clearer that there is a database operation in-between (implied by the naming). The latter makes it clearer what the service driver is doing before and after.  In both cases, the ABC for the service driver (VpnDriver) could have the default validation/precommit actions, and the service driver (IPsecVPNDriver) could optionally have any provider validation/precommit and would have the mandatory apply/post-commit actions.\n> \n> Maybe I could do a WIP patch out for review to give something for concrete commenting?\n> \n> \n> Regards,\n> \n> PCM\n> \n> \n> \n>> \n>> Regards,\n>> Mandeep\n>> \n>> \n>> \n>> On Fri, May 23, 2014 at 4:25 PM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>> Thanks for the comment Carl. See @PCM inline\n>> \n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pcm_ (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> On May 23, 2014, at 6:09 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:\n>> \n>>> Paul,\n>>> \n>>> On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>>> Hi,\n>>>> \n>>>> I?m working on a task for a BP to separate validation from persistence logic\n>>>> in L3 services code (VPN currently), so that providers can override/extend\n>>>> the validation logic (before persistence).\n>>>> \n>>>> So I?ve separated the code for one of the create APIs, placed the default\n>>>> validation into an ABC class (as a non-abstract method) that the service\n>>>> drivers inherit from, and modified the plugin to invoke the validation\n>>>> function in the service driver, before doing the persistence step.\n>>>> \n>>>> The flow goes like this?\n>>>> \n>>>>    def create_vpnservice(self, context, vpnservice):\n>>>>        driver = self._get_driver_for_vpnservice(vpnservice)\n>>>>        driver.validate_create_vpnservice(context, vpnservice)\n>>>>        super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>>>>        driver.apply_create_vpnservice(context, vpnservice)\n>>>> \n>>>> If the service driver has a validation routine, it?ll be invoked, otherwise,\n>>>> the default method in the ABC for the service driver will be called and will\n>>>> handle the ?baseline? validation. I also renamed the service driver method\n>>>> that is used for applying the changes to the device driver as apply_*\n>>>> instead of using the same name as is used for persistence (e.g.\n>>>> create_vpnservice -> apply_create_vpnservice).\n>>>> \n>>>> The questions I have is?\n>>>> \n>>>> 1) Should I create new validation methods A) for every create (and update?)\n>>>> API (regardless of whether they currently have any validation logic, B) for\n>>>> resources that have some validation logic already, or C) only for resources\n>>>> where there are providers with different validation needs?  I was thinking\n>>>> (B), but would like to hear peoples? thoughts.\n>>> \n>>> I think B.  C may leave a little too much inconsistency.  A feels like\n>>> extra boiler-plate.  Would there be any benefit to creating a higher\n>>> level abstraction for the create/update API calls?  I\'m not suggesting\n>>> you do so but if you did then you could add a validation method to\n>>> that interface with a default pass.  Otherwise, I\'d stick with B until\n>>> there is a need for more.\n>> \n>> @PCM Yeah, there is somewhat of an abstraction. In VPN, for the service drivers, they all inherit from an ABC. For the apply, there are already abstract methods in the ABC, so that the service driver is forced to provide a function (of course it is inconsistent currently - they are there for VPN services, but not for IPSec connections, which are provided in the service driver). For the validation, I was creating methods in the ABC, with implementations, but not abstract, so that the service driver could provide a function, if it wanted to extend or override (and call super, if desired), or leave it out and the base class function would be used.\n>> \n>> So, I guess it?s at two points, the validate and apply methods, where we should probably be consistent with providing base class methods for all that present in the service driver.\n>> \n>> \n>>> \n>>>> 2) I?ve added validation_* and modified the other service driver call to\n>>>> apply_*. Should I instead, use the ML2 terminology of pre commit_* and post\n>>>> commit_*? I personally favor the former, as it is more descriptive of what\n>>>> is happening in the methods, but I understand the desire for consistency\n>>>> with other code.\n>>> \n>>> I\'m on the fence.  ML2 is not where I\'m most familiar and I don\'t know\n>>> the history behind that design.  Without considering ML2 and\n>>> consistency, I think I like your terminology better.\n>> \n>> @PCM I?m in the same camp. I don?t know ML2 well, and I like the explicit terminology. It *seems* like ML2 is dealing with this all at the same level of abstraction (pre-commit, commit, post-commit all for the same plugin or driver), whereas with L3 services, it is at two levels (validate at service driver and then plugin, commit at plugin, apply at service driver only). I guess I can leave it and see what happens at review?I have some asbestos here somewhere.\n>> \n>> \n>>> \n>>>> 3) Should I create validation methods for code, where defaults are being set\n>>>> for missing (optional) information? For example, VPN IKE Policy lifetime\n>>>> being set to units=seconds, value=3600, if not set. Currently, provider\n>>>> implementations have same defaults, but could potentially use different\n>>>> defaults. The alternative is to leave this in the persistence code and not\n>>>> allow it to be changed. This could be deferred, if 1C is chosen above.\n>>> \n>>> I\'m tempted to say punt on this until there is a need for it.\n>> \n>> @PCM I think you?re right. It may turn out to be YAGNI.\n>> \n>> Thanks!\n>> \n>> PCM\n>> \n>> \n>>> \n>>> Carl\n>>> \n>>>> Looking forward to your thoughts...\n>>>> \n>>>> \n>>>> Thanks!\n>>>> \n>>>> PCM (Paul Michali)\n>>>> \n>>>> MAIL ?..?. pcm at cisco.com\n>>>> IRC ??..? pcm_ (irc.freenode.com)\n>>>> TW ???... @pmichali\n>>>> GPG Key ? 4525ECC253E31A83\n>>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>>> \n>>>> \n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/81b323e9/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/81b323e9/attachment.pgp>\n\n','<7CA8AE17-4D72-424A-B9A5-C5548022B6D0@cisco.com>',NULL),('<0EABBE0B-487A-41DC-82B9-329F53A0A1CF@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-21 13:55:40',21600,'2014-11-21 07:55:40',NULL,'[openstack-dev] [mistral] New blueprints created based on Paris\n	Summit results','Hi,\n\nThanks for providing us great feedback at the summit in Paris! It was really great to see so many people coming to our sessions and interested in Mistral capabilities. I?ve tried to do my best to digest all I heard from you and materialise all the wishes in form of blueprints at Launchpad.\n\nSo here they are:\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-execution-visualization <https://blueprints.launchpad.net/mistral/+spec/mistral-execution-visualization>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-install-docs <https://blueprints.launchpad.net/mistral/+spec/mistral-install-docs>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-dashboard-crud-operations <https://blueprints.launchpad.net/mistral/+spec/mistral-dashboard-crud-operations>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-yaml-request-body <https://blueprints.launchpad.net/mistral/+spec/mistral-yaml-request-body>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-alternative-rpc <https://blueprints.launchpad.net/mistral/+spec/mistral-alternative-rpc>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values <https://blueprints.launchpad.net/mistral/+spec/mistral-default-input-values>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-for-each-cardinality <https://blueprints.launchpad.net/mistral/+spec/mistral-for-each-cardinality>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-javascript-action <https://blueprints.launchpad.net/mistral/+spec/mistral-javascript-action>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-mysql-configuration-docs <https://blueprints.launchpad.net/mistral/+spec/mistral-mysql-configuration-docs>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-no-op-task <https://blueprints.launchpad.net/mistral/+spec/mistral-no-op-task>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-non-distributable-actions <https://blueprints.launchpad.net/mistral/+spec/mistral-non-distributable-actions>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-separate-executor-packaging <https://blueprints.launchpad.net/mistral/+spec/mistral-separate-executor-packaging>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-zaqar-integration <https://blueprints.launchpad.net/mistral/+spec/mistral-zaqar-integration>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-workbook-builder <https://blueprints.launchpad.net/mistral/+spec/mistral-workbook-builder>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-systemd-trigger <https://blueprints.launchpad.net/mistral/+spec/mistral-systemd-trigger>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment <https://blueprints.launchpad.net/mistral/+spec/mistral-execution-environment>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-workflow-decider <https://blueprints.launchpad.net/mistral/+spec/mistral-workflow-decider>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-multicloud <https://blueprints.launchpad.net/mistral/+spec/mistral-multicloud>\nhttps://blueprints.launchpad.net/mistral/+spec/mistral-standalone <https://blueprints.launchpad.net/mistral/+spec/mistral-standalone>\n\nFeel free to join the discussion about whatever related to them. If you find yourself interested in helping us implement some of them please don?t hesitate reaching us out in IRC (#openstack-mistral) or email.\n\nThanks!\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/3009112f/attachment.html>\n\n',NULL,NULL),('<0EB71A60-C897-44BC-BAC2-45CEBA05DB4B@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 21:04:03',25200,'2014-02-26 14:04:03',NULL,'[openstack-dev] [Mistral] Renaming action types','Ooh, I was wrong. Sorry. We use dash naming. We have ?on-success?, ?on-error? and so forth.\n\nPlease let us know if you see other inconsistencies.\n\nThanks\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 26 Feb 2014, at 21:00, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n\n> Thanks Jay.\n> \n> Regarding underscore naming. If you meant using underscore naming for ?createVM? and ?novaURL? then yes, ?createVM? is just a task name and it?s a user preference. The same about ?novaURL? which will be defined by users. As for keywords, seemingly we follow underscore naming.\n> \n> Renat Akhmerov\n> @ Mirantis Inc.\n> \n> \n> \n> On 26 Feb 2014, at 17:58, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n>> On Wed, 2014-02-26 at 14:38 +0700, Renat Akhmerov wrote:\n>>> Folks,\n>>> \n>>> I?m proposing to rename these two action types REST_API and\n>>> MISTRAL_REST_API to HTTP and MISTRAL_HTTP. Words ?REST? and ?API?\n>>> don?t look correct to me, if you look at\n>>> \n>>> \n>>> Services:\n>>> Nova:\n>>>   type: REST_API\n>>>   parameters:\n>>>     baseUrl: {$.novaURL}\n>>>   actions:\n>>>     createVM:\n>>>       parameters:\n>>>         url: /servers/{$.vm_id}\n>>>         method: POST\n>>> \n>>> There?s no information about ?REST? or ?API? here. It?s just a spec\n>>> how to form an HTTP request.\n>> \n>> +1 on HTTP and MISTRAL_HTTP.\n>> \n>> On an unrelated note, would it be possible to use under_score_naming\n>> instead of camelCase naming?\n>> \n>> Best,\n>> -jay\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n','<6E8F2F92-FF60-4D73-9808-595EB52707B3@mirantis.com>',NULL),('<0eb8f671-db4d-461b-a752-e998096ac9da@zimbra>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-23 16:41:51',7200,'2013-07-23 14:41:51',NULL,'[Openstack-operators] CentOS image','Yeah, that should work, great idea :)\n\n- Robert\n\n----- Original Message -----\nFrom: \"Robert van Leeuwen\" <Robert.vanLeeuwen at spilgames.com>\nTo: \"Joe Topjian\" <joe.topjian at cybera.ca>, openstack-operators at lists.openstack.org\nSent: Tuesday, July 23, 2013 2:42:48 PM\nSubject: Re: [Openstack-operators] CentOS image\n\n> Dean Troyer has some great CentOS build scripts here. These scripts will build a CentOS\n> image on the fly from start to finish. The only issue I ran into was with udev: On first boot, \n> udev will record the MAC addresses of the virtual NIC(s) in the instance. If you create a \n> snapshot, these records are not removed and so udev renames the interfaces to something else.\n\nMaybe not the most elegant solution but it works (at least for machines with one interface):\nsymlink  /etc/udev/rules.d/75-persistent-net-generator.rules to /dev/null :)\n\nCheers,\nRobert van Leeuwen\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<79E00D9220302D448C1D59B5224ED12D8D8629D4@FoxtrotDB01.spil.local>',NULL),('<0ECE4D8B-F1FD-4DBC-B4C8-D983BCA85874@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 14:19:54',25200,'2014-04-15 07:19:54',NULL,'[openstack-dev] [Mistral][TaskFlow] Mistral-TaskFlow Summary','Some notes:\nEven though we use YAQL now our design is flexible enough to plug other ELs in.\nIf it tells you something in Amazon SWF a component that makes a decision about a further route is called Decider. \nThis discussion about conditionals is surely important but it doesn?t matter too much if we don?t agree on that lazy execution model.\n\n> Of course I\'m trying to make the above not be its own micro-language as much as possible (a switch object starts to act like one, sadly).\n\nWhy do you think it?s going to be a micro-language?\n\n> [1] http://www.cs.cmu.edu/~aldrich/papers/onward2009-concurrency.pdf\n> [2] http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Literature/DataFlowProgrammingLanguages.pdf\n\nCool, thanks!\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140415/ef198ddc/attachment.html>\n\n','<CF71FBCC.5C27B%harlowja@yahoo-inc.com>',NULL),('<0EE35713-FAFA-4DBF-8C6A-2EBB9FE4B4A3@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-05-09 13:39:33',7200,'2013-05-09 11:39:33',NULL,'[Openstack-operators] Novnc problem get-vnc-console','Hi, \nno this information is only within nova.conf\nHere are my settings : \n> # NOVNC CONSOLE\n> vncserver_proxyclient_address=192.168.2.20\n> novnc_enabled=true\n> novncproxy_port=6080\n> novncproxy_base_url=http://PUBLIC-IP:6080/vnc_auto.html\n> vncserver_listen=0.0.0.0\n> root_helper=sudo nova-rootwrap\n> verbose=True\n\nMake sure to update the proxy client_address so it matches every node IP, the rest should remain unchanged and restart the following services afterwards:\nnova-api\nnova-consoleauth\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 9 mai 2013 ? 04:39, Juan Jos? Pavlik Salles <jjpavlik at gmail.com> a ?crit :\n\n> I\'ve two compute nodes, and both of them have this in nova.conf\n> \n> novncproxy_base_url=http://172.16.16.170:6080/vnc_auto.html\n> \n> Is this information saved somewhere else? maybe in the nova database?\n> \n> 2013/5/8 Razique Mahroua <razique.mahroua at gmail.com>\n> Hi, \n> looks for the /etc/nova/nova.conf file on your compute nodes :)\n> how many nodes do you have?\n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 8 mai 2013 ? 22:34, Juan Jos? Pavlik Salles <jjpavlik at gmail.com> a ?crit :\n> \n>> I\'ve created 3 different instances and they have differents novnc URL (two of them)\n>> \n>> root at locro:/etc/nova# nova --os-username=admin --os-tenant-name=admin --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0 get-vnc-console 68c770a7-2678-4c1e-8028-7c9401f5319d  novnc\n>> +-------+-------------------------------------------------------------------------------------+\n>> | Type  | Url                                                                                 |\n>> +-------+-------------------------------------------------------------------------------------+\n>> | novnc | http://172.19.136.170:6080/vnc_auto.html?token=4ac35743-3f06-4000-b039-706d82cb4dd4 |\n>> +-------+-------------------------------------------------------------------------------------+\n>> root at locro:/etc/nova# nova --os-username=admin --os-tenant-name=admin --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0 get-vnc-console 8014674a-6c5b-462c-abd2-eea82cd03dcd novnc\n>> +-------+------------------------------------------------------------------------------------+\n>> | Type  | Url                                                                                |\n>> +-------+------------------------------------------------------------------------------------+\n>> | novnc | http://172.16.16.170:6080/vnc_auto.html?token=6b3629a2-1c0f-4410-93d9-da12931f2e30 |\n>> +-------+------------------------------------------------------------------------------------+\n>> root at locro:/etc/nova# nova --os-username=admin --os-tenant-name=admin --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0 get-vnc-console cd7f99be-a962-40e2-bc01-66f4274df736 novnc\n>> +-------+-------------------------------------------------------------------------------------+\n>> | Type  | Url                                                                                 |\n>> +-------+-------------------------------------------------------------------------------------+\n>> | novnc | http://172.19.136.170:6080/vnc_auto.html?token=4189f6a2-0905-49a4-a66f-2a4e6dc496ff |\n>> +-------+-------------------------------------------------------------------------------------+\n>> root at locro:/etc/nova# \n>> \n>> Where dose this URL come from? Thankss\n>> \n>> \n>> 2013/5/7 Juan Jos? Pavlik Salles <jjpavlik at gmail.com>\n>> Here i come with a new problem, this time with novnc and dashboard. When i try to connect to the vnc of a running instance from the dashboard i get a wrong url, but is the same one i get when i run nova get-vnc-console:\n>> \n>> root at locro:/etc# nova --os-username=admin --os-tenant-name=admin --os-password=XXX --os-auth-url=http://172.19.136.1:35357/v2.0 get-vnc-console f0fc0fc6-e4c2-4518-a0e0-589ce4cc8903  novnc\n>> +-------+-------------------------------------------------------------------------------------+\n>> | Type  | Url                                                                                 |\n>> +-------+-------------------------------------------------------------------------------------+\n>> | novnc | http://172.19.136.170:6080/vnc_auto.html?token=c7921e91-a325-45d4-817d-e3f742d710bd |\n>> +-------+-------------------------------------------------------------------------------------+\n>> \n>> I don\'t have any host running on 172.19.136.170, this is my nova.conf:\n>> \n>> # novnc #\n>> novnc_enable=true\n>> novncproxy_base_url=http://172.16.16.170:6080/vnc_auto.html\n>> vncserver_proxyclient_address=172.19.136.11\n>> #Para que tenga migracion en vivo hay que usar la 0.0.0.0\n>> vncserver_listen=0.0.0.0\n>> \n>> Where 172.16.16.170 is my controller node, and 172.19.136.11 is a compute node. Does anybody know where this link come from? Because it\'s not taking novncproxy_base_url.\n>> \n>> -- \n>> Pavlik Juan Jos?\n>> \n>> \n>> \n>> -- \n>> Pavlik Salles Juan Jos?\n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n> \n> \n> -- \n> Pavlik Salles Juan Jos?\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130509/e5706cbb/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130509/e5706cbb/attachment.jpg>\n\n','<CAKCETkf7oWfEaCLqeW5ssQQzw-vf3qCTC-nc7aM12Ydzf=F8QA@mail.gmail.com>',NULL),('<0EE569BA-2CC8-41B7-A3BE-7232857FAC4C@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-18 10:53:09',-25200,'2013-09-18 17:53:09',NULL,'[Openstack] [Trove] - Clustering capabilities','On Sep 18, 2013, at 8:59 AM, Giuseppe Galeota <giuseppegaleota at gmail.com> wrote:\n\n> Dear all,\n> I would use TROVE in order to implement database clustering, even only on MySQL DBMS. How can I do this? I have not found any documentation or active projects about this.\n\nWe are in the process of implementing a clustering API and implementation[1]. While we are working on it now, I suspect there will be much discussion during the summit. \n\n[1] https://blueprints.launchpad.net/trove/+spec/reddwarf-replication\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130918/c94fbda0/attachment.html>\n\n','<CAAUgiAi9bOVV0zixw4E+vuH+j4QuyyfGRcu1=RMnhiWZnhp8Nw@mail.gmail.com>',NULL),('<0ef312c03c191c238aa5ed2c68b2e700@mail.gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-19 18:16:35',39600,'2013-10-19 07:16:35',NULL,'[openstack-community] Country/region stats','Hi Community,\n\nI\'ve been wondering how the community would feel about (more) stats. I\'m\nparticularly interested in country/regional contribution stats, in the\nshort term for the summit and longer term for the Foundation membership.\nIt\'s great to see company contribution stats but I think there\'s another\nset of stats that could be made available to help build our community.\n\nBecause of the imminent HK Summit, the last cupla months I\'ve constantly\nbeen asked \"How many folks are going from <insert country or region\nhere>?\". I have to say I don\'t know other than the few people I\'m in\npersonal contact with. I think having some sort of country/region stats\nwill help individuals and businesses make a decision to get involved. For\na startup or small org considering summit sponsorship, seeing some stats\non country attendance would be something that I would like to know if\ntheir market was regional.\n\nIt might also be great to see country/region stats for the Foundation\nmembership to see how successful we are in having our local UG members\njoin up. As an example, if we have 600 UG members and only 50 are OSF\nmembers, then we have might have work to do to find out why.\n\nAnother reason (and this is fresh in mind whilst I\'ve been engaging with\nsomeone recently in Paraguay to start a UG there), it might help all of us\nwith membership drives around the world and encourage people to form UGs\nif they can see there are actually others in their country/region/city\nthat are members, or if there aren\'t. This is justification alone IMHO.\n\nI can\'t actually think of any reasons not to publish country/regional\nstats.\n\nCheers\nTristan\n\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390518B273@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 22:02:33',0,'2013-06-06 22:02:33',NULL,'[openstack-dev] [keystone] Inherited domain roles','Hi Henry,\n\n\n\nI am totally agree with David Chadwick that roleDefs itself should have enough info so that underline system (role assignment) can make some decision whether roleDef is inheritable or not. Below is my proposal which is extensible and pretty much aligned with David\'s thoughts.\n\n\n\nI want to introduce wild card character (may be *) to handle inheritance behavior.\n\n\n\n\n\n\nType\n\n\n          RoleDef structure\n\n\nDescription\n\n\nRole Assignment examples\n\n\n1.\n\n\nInheritable non-project roleDef\n\n\n\n\n{\n\n  \"id\": \"1111\",\n\n  \"links\": {1111},\n\n  \"name\": \"domain-admin\",\n\n  \"domainId\": \"*\",\n\n  \"projectId\": \"\"\n\n}\n\n\n\n\ndomainId=* which means this roleDef is inheritable to any domain.\n\n\n\nprojectId=\"\" means it is not a project specific roleDef and cannot be used for role assignment where project is involved.\n\n\n\nE.g. domain-admin or domain-user\n\n\n1. An inherited role assignment for a cloud provider\'s user (basically a cloudadmin) wd look as below and says \"cloud-admin-userId has domain-admin role in all the domains\"\n\n\n\n{\n\n   \"roleId\": \"1111\",\n\n   \"domainId\": \"*\", <<< Inherited by all domains\n\n   \"subjectId\": \"cloud-admin-userId from cloud providers domains\" << it can be a groupId\n\n}\n\n\n\n2. Below is an example of non-inheritance role assignment, which says \"userId from domain XXXX has role domain-admin in domain xxxx\"\n\n{\n\n   \"roleId\": \"1111\",\n\n   \"domainId\": \"XXXX\", <<< (Concrete domain binding)\n\n   \"subjectId\": \"userId from XXXX domain\" << it can be a groupId\n\n}\n\n\n\n3. This approach can be extensible to cross domain role assignments.\n\n\"user from YYYY domain has domain-admin role in domain XXXX\"\n\n\n\n{\n\n   \"roleId\": \"1111\",\n\n   \"domainId\": \"XXXX\",\n\n   \"subjectId\": \"userId from YYYY domain\" << it can be a groupId\n\n}\n\n\n\n\n2.\n\n\nNon-inheritable non-project role\n\n\n\n\n{\n\n   \"id\": \"2222\",\n\n   \"links\": {2222},\n\n   \"name\": \"XXXX-domain-admin\",\n\n   \"domainId\": \"XXXX\",\n\n   \"projectId\": \"\"\n\n}\n\n\n\n\n\n\nIn case of public cloud environment we have to provide APIs to customer so that they can define *IAM* roles and this is to support that use case.\n\n\n\nThis roleDef is bind to \"domainId\": \"XXXX\" which means this roleDef should be used for role assignment in XXXX domain.\n\n\n\nprojectId=\"\" means it is not a project specific roleDef and cannot be used for role assignment where project is involved.\n\n\n\n\n\nNote: this may be not a use case of private cloud\n\n\n\n\n1.  Non- Cross domain role assignments\n\n{\n\n   \"roleId\": \"2222\",\n\n   \"domainId\": \"XXXX\", <<<< (* or YYYY is not possible)\n\n   \"subjectId\": \"userId from XXXX domain\" << it can be a groupId\n\n}\n\n\n\n2. Cross domain role assignments are even possible\n\n{\n\n   \"roleId\": \"2222\",\n\n   \"domainId\": \"XXXX\", <<<< (* or YYYY is not possible)\n\n   \"subjectId\": \"userId from YYYY domain\" << it can be a groupId\n\n}\n\n\n\n\n\n\n3.\n\n\nInheritable project roleDef\n\n\n{\n\n  \"id\": \"3333\",\n\n  \"links\": {3333},\n\n  \"name\": \"nova-net-admin\",\n\n  \"domainId\": \"*\",\n\n  \"projectId\": \"*\"\n\n}\n\n\n\n\n\"domainId\": \"*\" and  \"projectId\": \"*\" means this roleDef can be used for inherited role assignment but with a context of (1 or *) projects.\n\n\n\nAll the Open Stack service role can fall under this category e.g. Nova-admin, swift-admin etc...\n\n\n1.  Cloud provider want to maintain \"nova-net-admin\" on all customer domains and on all projects. (Roles inherited by all projects in all domains)\n\n{\n\n   \"roleId\": \"3333\",\n\n   \"domainId\": \"*\",\n\n   \"projectId\": \"*\", <<< (projectId cannot be concrete if domain is *)\n\n   \"subjectId\": \"cloud-admin-userId\" << it can be a groupId\n\n}\n\n\n\n2.  Below is the example of inheritance with in a domain, which says \"userId from XXXX domain has nova-net-admin role on all the projects\"\n\n{\n\n   \"roleId\": \"3333\",\n\n   \"domainId\": \"XXXX\",\n\n   \"projectId\": \"*\",\n\n   \"subjectId\": \"userId from XXXX domain\" << it can be a groupId\n\n}\n\n\n\n3    Below is an example of concrete project binding with in a domain, which says \"userId from XXXX domain has nova-net-admin role on Proj1 projects in domain XXXX\"\n\n{\n\n   \"roleId\": \"3333\",\n\n   \"domainId\": \"XXXX\",\n\n   \"projectId\": \"Proj1\",\n\n   \"subjectId\": \"userId from XXXX domain\" << it can be a groupId\n\n}\n\n\n\n\n\nNote: this can be extensible  for cross domain role assignment\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nIf we follow this approach to address inheritance which is extensible and give least impact on the existing APIs and to the role data structure. Only thing we need is proper use of wild card to represent domain or project.\n\n\n\n\n\n\nAPI usage\n\n\n\n\n\n1\n\n\nPUT /domains/*/users/user_id/roles/role_id\n\nPUT /domains/{domain_id}/users/user_id/roles/role_id\n\n\n\n\n\n2\n\n\nGET /domains/*/users/{user_id}/roles\n\nGET /domains/{domain_id}/users/{user_id}/roles\n\n\nBy default this will list all the role (inherited and bound to domain) for user_id.\n\nWe can add filter to list just inherited one.\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n3\n\n\nPUT /projects/*/users/{user_id}/roles/{role_id}\n\nPUT /projects/{proj_id}/users/{user_id}/roles/{role_id}\n\n\n\n\n\n4\n\n\nGET /projects/*/users/{user_id}/roles\n\nGET /projects/{proj_id}/users/{user_id}/roles\n\n\nBy default this will list all the role (inherited and bound to specific project)  for user_id.\n\nWe can add filter to list just inherited one.\n\n\n\n\nNote: Did not mentioned the group apis but that goes along with users.\n\n\n\n\n\nThought???\n\n\n\n\n\nThanks,\n\nArvind\n\n\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\nSent: Thursday, June 06, 2013 4:49 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Inherited domain roles\n\n\n\nHi Henry\n\n\n\nMy take on this is that whether a role is automatically inheritable or\n\nnot should be an attribute of the role itself, and should be independent\n\nof who the role is assigned to. Therefore when the role is initially\n\ndefined, it should be stated by the Keystone admin whether it is an\n\ninherited role or not.\n\n\n\nRole assignment is a separate issue and should not be confused with the\n\nbasic definition of the role. Role assignment should simply be a matter\n\nof naming the subject (domain, project or user) and the role. If you\n\ndont want the role to be inherited then use a non-inheritable role.\n\n\n\nThe problem with all the APIs below is that they conflate role\n\ndefinition and role assignment together in the same API call. There\n\nshould be no need to have user_ids in the definition of a role.\n\nSimilarly there should be no mention of inherited in the assignment of a\n\nrole to a user.\n\n\n\nregards\n\n\n\nDavid\n\n\n\n\n\nOn 05/06/2013 15:31, Henry Nash wrote:\n\n> Hi\n\n>\n\n> As per the discussion during the keystone IRC meeting yesterday, I have been reviewing the proposals for this functionality.  There have been two objections to the current proposal (which can be found here: https://review.openstack.org/#/c/29781/10), which are:\n\n>\n\n> 1) The api changes should allow for a logical, generic future extension for support of inherited roles across all domains etc., should we chose to go that route\n\n> 2) The use of a single api to list the various grants, filtered by a query string if necessary.\n\n>\n\n> My proposal for handling these two objections is as follows:\n\n>\n\n> 1) API extensions.\n\n>\n\n> There are several aspects of inherited roles that we are trying to cement, which are:\n\n>\n\n> a) The are dynamic - i.e. this isn\'t a case of a short hand for saying add this role to all the current projects in the domain - rather it is a role assignment that is attached to the domain but is added to the effective roles of any project (now and in the future) that exists in this domain\n\n> b) The are separate from a role that is on the domain itself - i.e.  we need to ensure that we keep separate inherited and non-inherited roles.\n\n> c) Maintain the philosophy that If you can create a role assignment with a given API, there should be an equivalent to read it back and delete it (i.e. you mustn\'t have the case where, for instance you can list a grant, but can\'t delete it at the conceptual level)\n\n>\n\n> The current proposal had been to do this by adding an \"inherited\" component of the url for create, check and delete grants to a domain, e.g.\n\n>\n\n> PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}\n\n> PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited\n\n> GET /domains/{domain_id}/users/{user_id}/roles/{role_id}\n\n> GET /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited\n\n> DELETE /domains/{domain_id}/users/{user_id}/roles/{role_id}\n\n> DELETE /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited\n\n> etc.\n\n>\n\n> A counter proposal has been made to expand this, along this lines of:\n\n>\n\n> Role applicable to all projects within a domain\n\n> PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/projects\n\n>\n\n> Roles inherited by all projects in all domains\n\n> PUT /usrs/{user_id}/roles/{role_id}/projects\n\n>\n\n> Roles inherited by all domains, at the domain level\n\n> PUT /usrs/{user_id}/roles/{role_id}/domains\n\n>\n\n> While I understand the desire to have extensibility if we wish to provide more \"global-ness\" of roles, I think the above proposal is less clear about whether these assignments are dynamic (see item a) above).  How about this as a counter proposal:\n\n>\n\n> Role applicable inherited by all projects within a domain (this is the same as the current proposal)\n\n> PUT  /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited\n\n>\n\n> Roles inherited by all projects in all domains - if we were to ever support this (not part of the current proposal)\n\n> PUT  /domains/users/{user_id}/roles/{role_id}/inherited\n\n>\n\n> Roles inherited by all domains, at the domain level - if we were to ever support this (not part of the current proposal)\n\n> PUT  /domains/users/{user_id}/roles/{role_id}/inherited\n\n>\n\n> To go along with the above, you would have the respective GET, CHECK & DELETE versions of those apis.\n\n>\n\n> 2) Single vs multiple apis\n\n> I think this comment is actually misplaced in the gerrit review, and is intended to directed at the api extensions I proposed to allow the list of a users \"effective\" roles on a project (i.e. directly assigned, those by virtue of group membership and inheritance from the parent domain).  For this, I proposed adding an optional \"effective\" query parameter to each of:\n\n>\n\n> List user\'s roles on project: `GET /projects/{project_id}/users/{user_id}/roles\n\n> List group\'s roles on project: `GET /projects/{project_id}/groups/{group_id}/roles\n\n> Check user\'s role on project: `GET /projects/{project_id}/users/{user_id}/role/{role_id}\n\n> Check group\'s roles on project: `GET /projects/{project_id}/groups/{group_id}/role/{role_id}\n\n>\n\n> e.g. GET /projects/{project_id}/users/{user_id}/roles?effective\n\n> ...would get you the effective roles the user has on that project, as opposed to only the directly assigned ones if you issue the call without the \"effective\" query parameter.\n\n>\n\n> Dolph and I had already been discussing that the existing v3 api of:\n\n>\n\n> GET /users/{user_id}/roles\n\n>\n\n> ...which is meant to return all the role assignments for a user, but is in fact broken in the current Grizzly code (it always returns an error).  So I agree with the proposal that we should scrap the \"effective\" query parameter for the specific list/check calls for the project - and instead properly implement the \"get all assignments for a user\" call.  I propose the amended spec for this call is:\n\n>\n\n> #### List a user\'s effective role assignments: `GET /users/{user_id}/role-assignments`\n\n>\n\n> query_string: page (optional)\n\n> query_string: per_page (optional, default 30)\n\n> query_string: id, project_id, domain_id\n\n>\n\n> Response:\n\n>\n\n>      Status: 200 OK\n\n>\n\n>      [\n\n>          {\n\n>              \"id\": \"--role-id--\",\n\n>              \"name\": \"--role-name--\",\n\n>              \"project_id\": \"--project-id--\",\n\n>              \"source\":\n\n>              {\n\n>                  \"direct\": true,  (optional)\n\n>                  \"domain_inherited: \"--domain-id--\", (optional)\n\n>                  \"group_membership: \"--group-id--\" (optional)\n\n>              }\n\n>          },\n\n>          {\n\n>              \"domain_id\": \"--domain-id--\",\n\n>              \"id\": \"--role-id--\",\n\n>              \"name\": \"--role-name--\",\n\n>              \"source\":\n\n>              {\n\n>                  \"direct\": true, (optional)\n\n>                  \"group_membership: \"--group-id--\" (optional)\n\n>              }\n\n>          }\n\n>      ]\n\n>\n\n> The \"source\" structure must have at least one of the values given above (and could have more than one, e.g. both domain_inherited and global_membership for a project where the role is due to a group role that is inherited from the domain).  If were even to support global roles across all domains, then we would extend the \"source structure\" accordingly.   I\'m open to other options for the above format. however, so comments welcome.\n\n>\n\n> Does this sounds like a reasonable plan overall?\n\n>\n\n> Henry\n\n>\n\n>\n\n>\n\n> _______________________________________________\n\n> OpenStack-dev mailing list\n\n> OpenStack-dev at lists.openstack.org\n\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n>\n\n\n\n_______________________________________________\n\nOpenStack-dev mailing list\n\nOpenStack-dev at lists.openstack.org\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/26f58b63/attachment.html>\n\n','<51B0690A.5020900@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905192CEF@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-11 20:18:21',0,'2013-06-11 20:18:21',NULL,'[openstack-dev] [keystone] More on inherited domain roles','Hi All,\n\nRole inheritance is very cool feature and we need this in product, but letting RoleDef to drive the inheritance behavior seem wrong to me as it will cause roleDef explosion and complex policy for services to support.\n\nLet\'s assume a requirement\n\n\n1.       Cloud admin should have XYZ capability on all the projects, all domains for Sev1. (Global inheritance)\n\n2.       Domain admin should have XYZ capability only on the projects in specific domain for Sev1. (inheritance scoped to a domain)\n\n\nWith the current approach (having inherited to in roleDef) we have to have following two roleDefs to support the requirement and hence you have to adjust the policy around these two roleDefs but end result is XYZ capability.\n{\n    \"role\": {\n        \"id\": \"---id---\",\n        \"inheritedTo\": \"domain=all and project=all\", (This means, holder of this role has XYZ capability in all projects in all domains) (Lets not worry about the how we implement it enum / Boolean flag)\n        \"links\": {\n            \"self\": \"http://identity:35357/v3/roles/76e72a\"\n        },\n        \"name\": \"XYZ-Role-4-cloud-admin\"\n    }\n}\n\n{\n    \"role\": {\n        \"id\": \"---id---\",\n        \"inheritedTo\": \"project=all\", (This means, holder of this role has XYZ capability in all projects in specific domain)\n        \"links\": {\n            \"self\": \"http://identity:35357/v3/roles/76e72a\"\n        },\n        \"name\": \" XYZ-Role-4-domain-admin \"\n    }\n}\n\nThink about growing number of service and above mentioned requirement, we will end up with so many  roleDefs which will have duplicate capability and hence redundant info to maintain in policy. At the same time this solution does not address separation of concerns, we are unnecessary overloading the roleDefs to impose role inheritance behavior which is not its concern. The above mentioned requirement can be easily achievable by single roleDef (may be XYZ-role-Svc1) if we remove inheritedTo concern from roleDef and place it some ware else, role assignment is the right place to address this concern, how that we need to figure out.\n\nLet me know if the issue I mentioned looks legitimate.\n\n\n\nThanks,\nArvind\n\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com]\nSent: Monday, June 10, 2013 4:30 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [keystone] More on inherited domain roles\n\nHi\n\nSo I ave submitted two new api reviews around this:\n\n1) Defining inherited roles - this is now done on the role def itself, as suggested by David. See: https://review.openstack.org/#/c/29781/12\n2) The two un-implmented user/role apis have been replaces with a more flexible way of listing role-assignments. See:https://review.openstack.org/#/c/32394/2\n\nI\'d like to push to get this nailed asap, so we can have a  shot at getting the code in!\n\nBoth of these extensions are designed to give us the option to to expand this support for inheritance to all domains in the future if we chose.\n\nHenry\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130611/e6a8208c/attachment.html>\n\n','<1081CC4D-5D04-45B5-B4BB-A01EC6148549@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390519338D@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 16:29:17',0,'2013-06-12 16:29:17',NULL,'[openstack-dev] [keystone] More on inherited domain roles','Hi Henry,\n\nThanks for looking in to my comments, I was trying to raise #3 from your list.  Any ways lets discuss this topic on etherpad from here onwards.\n\nThanks,\nArvind\n________________________________________\nFrom: Henry Nash [henryn at linux.vnet.ibm.com]\nSent: Wednesday, June 12, 2013 10:58 AM\nTo: Tiwari, Arvind\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] More on inherited domain roles\n\nHi\n\nSo what you have described is correct, in terms of needing multiple roles IF you want one role that only goes to projects and one that doesn\'t (e.g. maybe goes to just domains). Role explosion was the issue raised against using the role def to hold inheritance behaviour, when it was first discussed.  However, I\'d make the following comments:\n\n1) Most services don\'t need to be concerned about domains, just projects - in fact, today, only keystone understands domains.  Hence there really won\'t be a role explosion  in terms \"Number of Services\" x \"Multiple roles due to inheritance to projects or domains\"\n2) In addition, I can imagine than often a cloud provider will create  roles that are project related separate from those that are domain related - they tend to be different people doing those roles (e.g. user_group_admin vs VM_admin etc.), so again, I think there won\'t be much of any additional role explosion due to the inheritance rules between these roles\n3) What there might be, is some role explosions between roles that go to all domains vs roles that go to individual domains - for that, you will need multiple roles.\n4) For correctness (since we spend 40 mins on IRC on this :-) ), the \"inherited to:\" field you use wasn\'t one of the discussed options - I agree this is not the email to discuss that, but I don\'t want anyone thinking that the structure below was one we looked at.\n\nFor all:  The options being discussed are continuing on an etherpad, see: https://etherpad.openstack.org/keystone-role-inheritance.  This contains all the various options being considered, including links to the previous ones we looked at (e.g. not using the role def)\n\nHenry\nOn 11 Jun 2013, at 21:18, Tiwari, Arvind wrote:\n\nHi All,\n\nRole inheritance is very cool feature and we need this in product, but letting RoleDef to drive the inheritance behavior seem wrong to me as it will cause roleDef explosion and complex policy for services to support.\n\nLet?s assume a requirement\n\n1.       Cloud admin should have XYZ capability on all the projects, all domains for Sev1. (Global inheritance)\n2.       Domain admin should have XYZ capability only on the projects in specific domain for Sev1. (inheritance scoped to a domain)\n\nWith the current approach (having inherited to in roleDef) we have to have following two roleDefs to support the requirement and hence you have to adjust the policy around these two roleDefs but end result is XYZ capability.\n{\n    \"role\": {\n        \"id\": \"---id---\",\n        \"inheritedTo\": \"domain=all and project=all\", (This means, holder of this role has XYZ capability in all projects in all domains) (Lets not worry about the how we implement it enum / Boolean flag)\n        \"links\": {\n            \"self\": \"http://identity:35357/v3/roles/76e72a\"\n        },\n        \"name\": \"XYZ-Role-4-cloud-admin\"\n    }\n}\n\n{\n    \"role\": {\n        \"id\": \"---id---\",\n        \"inheritedTo\": ?project=all\", (This means, holder of this role has XYZ capability in all projects in specific domain)\n        \"links\": {\n            \"self\": \"http://identity:35357/v3/roles/76e72a\"\n        },\n        \"name\": \" XYZ-Role-4-domain-admin \"\n    }\n}\n\nThink about growing number of service and above mentioned requirement, we will end up with so many  roleDefs which will have duplicate capability and hence redundant info to maintain in policy. At the same time this solution does not address separation of concerns, we are unnecessary overloading the roleDefs to impose role inheritance behavior which is not its concern. The above mentioned requirement can be easily achievable by single roleDef (may be XYZ-role-Svc1) if we remove inheritedTo concern from roleDef and place it some ware else, role assignment is the right place to address this concern, how that we need to figure out.\n\nLet me know if the issue I mentioned looks legitimate.\n\n\nThanks,\nArvind\n\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com]\nSent: Monday, June 10, 2013 4:30 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [keystone] More on inherited domain roles\n\nHi\n\nSo I ave submitted two new api reviews around this:\n\n1) Defining inherited roles - this is now done on the role def itself, as suggested by David. See: https://review.openstack.org/#/c/29781/12\n2) The two un-implmented user/role apis have been replaces with a more flexible way of listing role-assignments. See:https://review.openstack.org/#/c/32394/2\n\nI\'d like to push to get this nailed asap, so we can have a  shot at getting the code in!\n\nBoth of these extensions are designed to give us the option to to expand this support for inheritance to all domains in the future if we chose.\n\nHenry\n\n\n\n','<D5432D2A-DF88-4927-88CA-059AA832C5D4@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905196AA4@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 17:33:32',0,'2013-06-17 17:33:32',NULL,'[openstack-dev] [keystone] Inherited domain roles: Options\n	for	Havana and beyond','Thanks Henry for putting it all together.\n\nIn my opinion we should go with option \"a\" (role-assignment as a first class citizen) which seems correct to me, looking in to time constraint, option \'b\' is OK as an EXTENSION but SHOULD NOT BE implemented as part of core API.\n\nThoughts???\n\n\nArvind\n\n-----Original Message-----\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com] \nSent: Monday, June 17, 2013 6:52 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [keystone] Inherited domain roles: Options for Havana and beyond\n\nHi\n\nI have amended the etherpad to summarize the two proposed paths:\n\na) Full \"role-assignment as a first class entity\" for Havana\nb) Stepping stone approach, for Havana and \"I\"\n\nSo you can see what is involved in b), I have amended the two in-flight bp identity proposals to match what this would look like:\n\nhttps://review.openstack.org/#/c/29781/14\nhttps://review.openstack.org/#/c/32394/7\n\n[Ok, technically I should have done this is 3 bp, one for changing the current apis, one for the new GET /role-assignment api (that supports groups but not inherited roles) and then an updated GET /role-assigment api that now supports the inherited roles as well, and would be dependant on the other two bps.....but in the interests of time I kept it simple.] \n\nWe need to make a call on whether we take a) or b) at tomorrows keystone IRC meeting, if not before.  We are running out of time. \n\nHenry\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<06133B10-F290-4B92-8363-B7E44311F897@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905198956@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 22:12:40',0,'2013-06-19 22:12:40',NULL,'[openstack-dev] [keystone] Inherited domain roles','I think we need to revisit the problem in the Henry\'s BP, as per the BP \"cloud provider would like to ensure that they maintain some specific admin roles across all their customers\' projects\" and as per David\'s scenario that is exactly what mentioned in BP\'s scope. So AFA cloud admin front is concern the solution make perfect sense.\n\nLet\'s not talk about cloud admin use cases, if you do not want a user in your domain (you as domain owner/domain admin) to get automatic role on new projects (or all existing projects) than better do not give him inherited role on domain rather give him role scoped role assignment on a particular project. \n\nIn my opinion inherited role and solution we agreed on makes sense even for domain admin (non cloud admin) use case. E.g. suppose you are the owner of a domain, you want to have a role all over your domain across all projects and the inherited role is way to go, you don\'t want to create one-off role per project.\n\nHope I am not missing your point.\n\nArvind \n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Wednesday, June 19, 2013 3:38 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Inherited domain roles\n\nHi Adam\n\n\nOn 19/06/2013 15:36, Adam Young wrote:\n> The more I think about it, the more I think that tying the inheritance\n> to the domain assignment is the wrong solution.\n\nI tend to agree with you. Unless I have misunderstood Henry\'s API \nchanges, it means that when a new project is created, existing users \nwith existing inherited roles in existing projects, automatically get \nthe same roles in the new project. I would have thought that usually \ndifferent projects would have had different users working on them, and \nso you would not want this automatic role assignment to take place.\n\nregards\n\nDavid\n\n>\n> David/Kristy originally had the Mapping blueprint and patch.  It\n> contained the ability to provide arbitrary rules for mapping from the\n> identity attributes to the roles.  I think that it is time to implement\n> that.\n>\n> It would be more correct to say that all users in a specific group\n> (fetched out of Identity/LDAP) would get a specific role in a project\n> than to say that a user with a domain role should therefore inherit a\n> role in all projects.\n>\n> When creating a scoped token, we need to query a subset of the users\n> identity information.  I think that the right direction for this query\n> to flow would be:\n>\n> project->roles->role-mappings->groups\n>\n> as opposed to what we do now, which is to do a global query: give me all\n> groups for this user and select which ones apply.  For LDAP/SQL Identity\n> backends we want to trigger the miniaml query which is \"let me know if\n> the user is in groups G1, G2, G3...\"  as those are the groups that\n> potentially apply to role assignments for this project.\n>\n>\n> So I\'d like to redefine the problem definition here:\n>\n> \"Provide a mechanism by which role assignments can be specified for more\n> than one project.\"  One such rule would obviously be \"all projects in\n> domain D1\"\n>\n> But it should be based on groups, not on domain role assignments.\n>\n>\n>\n>\n> On 06/10/2013 11:41 AM, David Chadwick wrote:\n>>\n>>\n>> On 10/06/2013 16:02, Henry Nash wrote:\n>>> Hi David,\n>>>\n>>> I wasn\'t suggesting that we encode \"inhertitness\" in the name, just\n>>> that if you want to have a role that is non-inherited and one that is\n>>> inherited that relate to the same type of permission, then since role\n>>> name must be globally unique, then the two roles must have different\n>>> names....hence potentially leading to the complication in the policy\n>>> file.\n>>\n>> I dont see why different role names would lead to complications in the\n>> policy file, since policies are there to assign different permissions\n>> to different roles.\n>>\n>> What can happen is that policy files can get very large and complex,\n>> but that can happen regardless of whether roles are inherited or not,\n>> and mistakes can be made by assigning the wrong roles to users or the\n>> wrong permissions to roles, but again this is independent of the role\n>> definition.\n>>\n>> regards\n>>\n>> David\n>>>\n>>> Henry On 10 Jun 2013, at 15:57, David Chadwick wrote:\n>>>\n>>>> Hi Henry\n>>>>\n>>>> on the definition of inherited roles, I dont think this should be\n>>>> part of the role name, but rather, each role should have meta\n>>>> information attached to it, in its role table definition, that\n>>>> indicates the properties of the role definition. In this way, you\n>>>> can make the role definition extensible by adding new columns to\n>>>> the table as and when needed e.g. if in future you want to have\n>>>> global roles inherited by domains, you add a new column, say\n>>>> GlobalToDomain, which could be a boolean with a default value of\n>>>> false, and with a value true indicating that it is inherited from\n>>>> global to domain. All pre-existing roles would not be of this type,\n>>>> and therefore all pre-existing code would work without this new\n>>>> inheritance.\n>>>>\n>>>> I would not alter the role-user assignment API as this should\n>>>> simply specify the role and user and project. The code may need\n>>>> enhancing in the future, if new types of inheritance are added, in\n>>>> order to cater for cases where the role is wrongly specified by the\n>>>> administrator i.e. it does not apply to the project in question\n>>>> through lack of inheritance.\n>>>>\n>>>> regards\n>>>>\n>>>> David\n>>>>\n>>>> On 08/06/2013 11:38, Henry Nash wrote:\n>>>>> So on the idea of using the role def for inheritance definition,\n>>>>> there were a couple of things that concerned me about it:\n>>>>>\n>>>>> 1) While it definitely can simply the api changes required for\n>>>>> the current requirements, I worry that we are passing the\n>>>>> complexity on to the creation of the policy file.  Since the role\n>>>>> names of an inherited and non-inherited role will obviously have\n>>>>> to be different, is there a danger that policy files end up with\n>>>>> lots of rules that have \"role: xxxx and role: xxxx_inherited\"?  I\n>>>>> guess we can make the argument that since (with today\'s\n>>>>> requirements at least) the only objects that will end of\n>>>>> inheriting an assignment will be projects, the likelihood is that\n>>>>> the api lines in the policy file that contains inherited and\n>>>>> non-inherited will be different, hence avoiding the problem.\n>>>>> However, if, in the future, we were to expand inheritance to\n>>>>> support all domains, or all projects in all domains, then this\n>>>>> problem would arise for domain-relevant apis lines in the policy\n>>>>> file.\n>>>>>\n>>>>> 2) If, again, in the future we support inheritance across all\n>>>>> domains/projects - would we need to more fine grained control of\n>>>>> the inheritance?  For instance, we want a role that was inherited\n>>>>> by all domains, but not the projects in each domain? Perhaps,\n>>>>> one could imagine expanding the role-def to somehow indicate this\n>>>>> (maybe rather than just having a simple \"inherited\" boolean, we\n>>>>> specify \"project_inherited\", to which we could, in the future,\n>>>>> add \"domain_inherited\"?).  We also have the problem of how you\n>>>>> assign such a role?  I guess you would still need some kind of\n>>>>> modification to the assignment APIs to indicate \"all domains\"\n>>>>> (perhaps the \"domains/*\" that was suggested)?\n>>>>>\n>>>>> I\'d be interested in views on the above - I\'m Ok fi we decide\n>>>>> that role-def is the right way to go, but want to make sure we\n>>>>> clearly understand how we would expand this in the future.\n>>>>>\n>>>>> Henry On 7 Jun 2013, at 18:12, Dolph Mathews wrote:\n>>>>>\n>>>>>>\n>>>>>>\n>>>>>> On Thu, Jun 6, 2013 at 5:48 AM, David Chadwick\n>>>>>> <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>>\n>>>>>> wrote:\n>>>>>>\n>>>>>> Hi Henry\n>>>>>>\n>>>>>> My take on this is that whether a role is automatically\n>>>>>> inheritable or not should be an attribute of the role itself,\n>>>>>> and should be independent of who the role is assigned to.\n>>>>>> Therefore when the role is initially defined, it should be\n>>>>>> stated by the Keystone admin whether it is an inherited role or\n>>>>>> not.\n>>>>>>\n>>>>>> Role assignment is a separate issue and should not be confused\n>>>>>> with the basic definition of the role. Role assignment should\n>>>>>> simply be a matter of naming the subject (domain, project or\n>>>>>> user) and the role. If you dont want the role to be inherited\n>>>>>> then use a non-inheritable role.\n>>>>>>\n>>>>>> The problem with all the APIs below is that they conflate role\n>>>>>> definition and role assignment together in the same API call.\n>>>>>> There should be no need to have user_ids in the definition of\n>>>>>> a role. Similarly there should be no mention of inherited in\n>>>>>> the assignment of a role to a user.\n>>>>>>\n>>>>>> regards\n>>>>>>\n>>>>>> David\n>>>>>>\n>>>>>> +1; I really like the simplicity of this approach, and it\n>>>>>> sounds like something we can migrate to easily (e.g. default\n>>>>>> inheritable=False for existing roles). Then global role\n>>>>>> assignments would follow an API like:\n>>>>>>\n>>>>>> GET /users/{user_id}/roles  # list global roles HEAD\n>>>>>> /users/{user_id}/roles/{inheritable_role_id}  # check if a\n>>>>>> global role is assigned PUT\n>>>>>> /users/{user_id}/roles/{inheritable_role_id}  # assign a global\n>>>>>> role DELETE /users/{user_id}/roles/{inheritable_role_id} #\n>>>>>> revoke a global role\n>>>>>>\n>>>>>> where a non-inheritable role assigned a user without a domain\n>>>>>> or project for context wouldn\'t make any sense. In fact,\n>>>>>> assigning an inheritable role to a user on a project wouldn\'t\n>>>>>> be very useful (as it wouldn\'t inherit to anything in the core\n>>>>>> API), but I don\'t see a reason to deny it.\n>>>>>>\n>>>>>>\n>>>>>> On 05/06/2013 15:31, Henry Nash wrote:\n>>>>>>\n>>>>>> Hi\n>>>>>>\n>>>>>> As per the discussion during the keystone IRC meeting\n>>>>>> yesterday, I have been reviewing the proposals for this\n>>>>>> functionality.  There have been two objections to the current\n>>>>>> proposal (which can be found here:\n>>>>>> https://review.openstack.org/#__/c/29781/10\n>>>>>> <https://review.openstack.org/#/c/29781/10>), which are:\n>>>>>>\n>>>>>> 1) The api changes should allow for a logical, generic future\n>>>>>> extension for support of inherited roles across all domains\n>>>>>> etc., should we chose to go that route 2) The use of a single\n>>>>>> api to list the various grants, filtered by a query string if\n>>>>>> necessary.\n>>>>>>\n>>>>>> My proposal for handling these two objections is as follows:\n>>>>>>\n>>>>>> 1) API extensions.\n>>>>>>\n>>>>>> There are several aspects of inherited roles that we are trying\n>>>>>> to cement, which are:\n>>>>>>\n>>>>>> a) The are dynamic - i.e. this isn\'t a case of a short hand for\n>>>>>> saying add this role to all the current projects in the domain\n>>>>>> - rather it is a role assignment that is attached to the domain\n>>>>>> but is added to the effective roles of any project (now and in\n>>>>>> the future) that exists in this domain b) The are separate from\n>>>>>> a role that is on the domain itself - i.e.  we need to ensure\n>>>>>> that we keep separate inherited and non-inherited roles. c)\n>>>>>> Maintain the philosophy that If you can create a role\n>>>>>> assignment with a given API, there should be an equivalent to\n>>>>>> read it back and delete it (i.e. you mustn\'t have the case\n>>>>>> where, for instance you can list a grant, but can\'t delete it\n>>>>>> at the conceptual level)\n>>>>>>\n>>>>>> The current proposal had been to do this by adding an\n>>>>>> \"inherited\" component of the url for create, check and delete\n>>>>>> grants to a domain, e.g.\n>>>>>>\n>>>>>> PUT /domains/{domain_id}/users/{__user_id}/roles/{role_id} PUT\n>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited\n>>>>>>\n>>>>>>\n>> GET /domains/{domain_id}/users/{__user_id}/roles/{role_id}\n>>>>>> GET\n>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited\n>>>>>>\n>>>>>>\n>> DELETE /domains/{domain_id}/users/{__user_id}/roles/{role_id}\n>>>>>> DELETE\n>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited\n>>>>>>\n>>>>>>\n>> etc.\n>>>>>>\n>>>>>> A counter proposal has been made to expand this, along this\n>>>>>> lines of:\n>>>>>>\n>>>>>> Role applicable to all projects within a domain PUT\n>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__projects\n>>>>>>\n>>>>>>\n>>>>>>\n>> Roles inherited by all projects in all domains\n>>>>>> PUT /usrs/{user_id}/roles/{role___id}/projects\n>>>>>>\n>>>>>> Roles inherited by all domains, at the domain level PUT\n>>>>>> /usrs/{user_id}/roles/{role___id}/domains\n>>>>>>\n>>>>>> While I understand the desire to have extensibility if we wish\n>>>>>> to provide more \"global-ness\" of roles, I think the above\n>>>>>> proposal is less clear about whether these assignments are\n>>>>>> dynamic (see item a) above).  How about this as a counter\n>>>>>> proposal:\n>>>>>>\n>>>>>> Role applicable inherited by all projects within a domain (this\n>>>>>> is the same as the current proposal) PUT\n>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited\n>>>>>>\n>>>>>>\n>>>>>>\n>> Roles inherited by all projects in all domains - if we were to\n>>>>>> ever support this (not part of the current proposal) PUT\n>>>>>> /domains/users/{user_id}/__roles/{role_id}/inherited\n>>>>>>\n>>>>>> Roles inherited by all domains, at the domain level - if we\n>>>>>> were to ever support this (not part of the current proposal)\n>>>>>> PUT  /domains/users/{user_id}/__roles/{role_id}/inherited\n>>>>>>\n>>>>>> To go along with the above, you would have the respective GET,\n>>>>>> CHECK & DELETE versions of those apis.\n>>>>>>\n>>>>>> 2) Single vs multiple apis I think this comment is actually\n>>>>>> misplaced in the gerrit review, and is intended to directed at\n>>>>>> the api extensions I proposed to allow the list of a users\n>>>>>> \"effective\" roles on a project (i.e. directly assigned, those\n>>>>>> by virtue of group membership and inheritance from the parent\n>>>>>> domain).  For this, I proposed adding an optional \"effective\"\n>>>>>> query parameter to each of:\n>>>>>>\n>>>>>> List user\'s roles on project: `GET\n>>>>>> /projects/{project_id}/users/{__user_id}/roles List group\'s\n>>>>>> roles on project: `GET\n>>>>>> /projects/{project_id}/groups/__{group_id}/roles Check user\'s\n>>>>>> role on project: `GET\n>>>>>> /projects/{project_id}/users/{__user_id}/role/{role_id} Check\n>>>>>> group\'s roles on project: `GET\n>>>>>> /projects/{project_id}/groups/__{group_id}/role/{role_id}\n>>>>>>\n>>>>>> e.g. GET\n>>>>>> /projects/{project_id}/users/{__user_id}/roles?effective\n>>>>>> ...would get you the effective roles the user has on that\n>>>>>> project, as opposed to only the directly assigned ones if you\n>>>>>> issue the call without the \"effective\" query parameter.\n>>>>>>\n>>>>>> Dolph and I had already been discussing that the existing v3\n>>>>>> api of:\n>>>>>>\n>>>>>> GET /users/{user_id}/roles\n>>>>>>\n>>>>>> ...which is meant to return all the role assignments for a\n>>>>>> user, but is in fact broken in the current Grizzly code (it\n>>>>>> always returns an error).  So I agree with the proposal that we\n>>>>>> should scrap the \"effective\" query parameter for the specific\n>>>>>> list/check calls for the project - and instead properly\n>>>>>> implement the \"get all assignments for a user\" call. I propose\n>>>>>> the amended spec for this call is:\n>>>>>>\n>>>>>> #### List a user\'s effective role assignments: `GET\n>>>>>> /users/{user_id}/role-__assignments`\n>>>>>>\n>>>>>> query_string: page (optional) query_string: per_page (optional,\n>>>>>> default 30) query_string: id, project_id, domain_id\n>>>>>>\n>>>>>> Response:\n>>>>>>\n>>>>>> Status: 200 OK\n>>>>>>\n>>>>>> [ { \"id\": \"--role-id--\", \"name\": \"--role-name--\", \"project_id\":\n>>>>>> \"--project-id--\", \"source\": { \"direct\": true,  (optional)\n>>>>>> \"domain_inherited: \"--domain-id--\", (optional)\n>>>>>> \"group_membership: \"--group-id--\" (optional) } }, {\n>>>>>> \"domain_id\": \"--domain-id--\", \"id\": \"--role-id--\", \"name\":\n>>>>>> \"--role-name--\", \"source\": { \"direct\": true, (optional)\n>>>>>> \"group_membership: \"--group-id--\" (optional) } } ]\n>>>>>>\n>>>>>> The \"source\" structure must have at least one of the values\n>>>>>> given above (and could have more than one, e.g. both\n>>>>>> domain_inherited and global_membership for a project where the\n>>>>>> role is due to a group role that is inherited from the domain).\n>>>>>> If were even to support global roles across all domains, then\n>>>>>> we would extend the \"source structure\" accordingly.   I\'m open\n>>>>>> to other options for the above format. however, so comments\n>>>>>> welcome.\n>>>>>>\n>>>>>> Does this sounds like a reasonable plan overall?\n>>>>>>\n>>>>>> Henry\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> _________________________________________________ OpenStack-dev\n>>>>>> mailing list OpenStack-dev at lists.openstack.__org\n>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev\n>>>>>>\n>>>>>>\n>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>>>>>>\n>>>>>>\n>>>>>> _________________________________________________ OpenStack-dev\n>>>>>> mailing list OpenStack-dev at lists.openstack.__org\n>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev\n>>>>>>\n>>>>>>\n>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>>>>>>\n>>>>>>\n>>>>>> _______________________________________________ OpenStack-dev\n>>>>>> mailing list OpenStack-dev at lists.openstack.org\n>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>>\n>> _______________________________________________\n>>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>\n>>>>\n>>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<51C224C1.8060506@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051989DD@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 22:41:28',0,'2013-06-19 22:41:28',NULL,'[openstack-dev] New BP - ServiceId binding with role definition','All,\n\nI have added a new BP, which advocates service id binding with role definition\n\nhttps://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition\n\nPlease look at it and share your comments.\n\n\nArvind\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/8cdc13f4/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390519C272@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 22:18:50',0,'2013-06-24 22:18:50',NULL,'[openstack-dev] New BP - ServiceId binding with role definition','All,\n\nAdded etherpad link, please share your comments  or suggestion\n\nhttps://etherpad.openstack.org/serviceid-binding-with-role-definition\n\nArvind\n\n\nFrom: Tiwari, Arvind\nSent: Wednesday, June 19, 2013 4:42 PM\nTo: OpenStack Development Mailing List\nSubject: New BP - ServiceId binding with role definition\n\nAll,\n\nI have added a new BP, which advocates service id binding with role definition\n\nhttps://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition\n\nPlease look at it and share your comments.\n\n\nArvind\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130624/f76217d0/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390519E822@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-27 16:46:59',0,'2013-06-27 16:46:59',NULL,'[openstack-dev] New BP - ServiceId binding with role definition','All,\n\nI have added my comments to the questions raised in below etherpad, please take a look and share your feedback.\n\nArvind\n\nFrom: Tiwari, Arvind\nSent: Monday, June 24, 2013 4:19 PM\nTo: \'OpenStack Development Mailing List\'\nSubject: RE: New BP - ServiceId binding with role definition\n\nAll,\n\nAdded etherpad link, please share your comments  or suggestion\n\nhttps://etherpad.openstack.org/serviceid-binding-with-role-definition\n\nArvind\n\n\nFrom: Tiwari, Arvind\nSent: Wednesday, June 19, 2013 4:42 PM\nTo: OpenStack Development Mailing List\nSubject: New BP - ServiceId binding with role definition\n\nAll,\n\nI have added a new BP, which advocates service id binding with role definition\n\nhttps://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition\n\nPlease look at it and share your comments.\n\n\nArvind\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130627/6daf01ca/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051AB222@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 16:55:19',0,'2013-07-02 16:55:19',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','Hi Simo,\n\nI am lost.\n \nDoes Barbican is product came out of https://wiki.openstack.org/wiki/KeyManager BP?\n\nIf yes, then why it is deviating from the BP which says Key Manager will be separate service but not a part of Keystone.\n\nIf no, then why we are thinking about new Key manager (which seems to me a subset of above BP)? \n\n\nArvind\n\n-----Original Message-----\nFrom: Simo Sorce [mailto:simo at redhat.com] \nSent: Tuesday, July 02, 2013 8:57 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Move keypair management out of Nova and into Keystone?\n\nOn Tue, 2013-07-02 at 10:07 -0400, Jay Pipes wrote:\n> On 07/02/2013 09:49 AM, Jarret Raim wrote:\n> > I\'ve spent some time thinking about how Barbican (Key Management) can help\n> > in this workflow.\n> >\n> > We will have the ability to generate SSH keys (and a host of other key &\n> > certificate types). This is backed by cryptographically sound code and\n> > we\'ve spent some time figuring out the entropy problem and HSM support. If\n> > the keys are stored in Barbican, we\'d get the audit / logging and other\n> > functionality needed for compliance.\n> \n> What does the above mean? What about Barbican is audited/logged that \n> isn\'t in Keystone and why wouldn\'t such auditing/logging be added to \n> Keystone if it were needed for compliance? I\'m trying to figure out why \n> there is yet another OpenStack-related project for storing \n> keys/credentials when Keystone already exists.\n\nBarbican is meant to store primarily private/simmetric keys in a way\nthat allows user to get access to them after proper keystone\nintegration. This material is particularly sensitive and it was felt\nthat we needed a specific service that would have a higher level of\nscrutiny and security. This is better achieved if the tool does only one\nthing with a smallest code footprint than if it is merged together with\nunrelated code. Auditing of code is expensive (mostly in terms of\ntime/eyes), so keeping a specialized service for these keys makes sense.\n\n>  > We also get federation which will\n> > allow customers of public Clouds (or shared private Clouds) to maintain\n> > custody of their own keys rather than storing them in the provider.\n> \n> I don\'t understand. Users already have custody of their own keys. The \n> only thing that Keystone/Nova has is the public key fingerprint [1], not \n> the private key...\n\nYou acatually have the public key, not just the fingerprint, but indeed\nI do not see why abrbican should be involved here.  apublic key does not\nneed the same level of protection of a private key or a symmetric\nencryption key, so by storing this data in barbican we would only\nneedlessly expose barbican to more access patternsand more\nlogging/auditing volume than is needed. \n\n> > There seem to be a couple of ways to take advantage of this functionality.\n> > If a key is specific to a user, then Keystone could store a URI to the key\n> > in Barbican and Nova could request it on server creation. Alternatively,\n> > the user could pass a URI to a key into Nova directly. If we want to move\n> > to always enabling SSH key access only on boot, Nova could create a key\n> > under the requesting tenant in Barbican and use it on server create.\n> \n> OK, so the above would basically be a \"driver\" in Keystone parlance for \n> the credentials module, where Keystone would just store the key in \n> Barbican and retrieve said key.\n> \n> At this point, though, what exactly is the point of Barbican over a \n> simple database or KVS driver?\n\nNot much, and perhaps even worsen the situation as I hinted above, but I\nthink Jared assumed you were talking about generating/storing private\nkeys, and as you noted it is not the case.\n\n> > Things get more interesting when we are talking about IPSec certificates\n> > and the like. Barbican seems a more logical place to generate / store /\n> > share these types of keys than Keystone.\n> \n> Generate...perhaps. Store... I doubt it. Share...I think Keystone is the \n> most logical place to share credentials. After all, it\'s the \n> authentication/identity component in OpenStack.\n\nNope, if you need to store private keys that you need to routinely\nretrieve and re-distribute then barbican is the right and only place.\n\n> While encryption and key generation are interesting topics, they are \n> tangential to the fact that credentials are an attribute of the \n> identity/user, and that information is in Keystone.\n\nIf \'access credentials\' remain buried (as in they cannot never be\nretrieved) in Keystone (or whatever IdM service it bridges to) then it\nis probably the right place as it performs authentication anyway and\nneeds direct access to these credentials internally in some cases.\n\nBut Keystone is not the right place to function as storage and retrieval\nsystem for private keys that\'s barbican\'s turf.\n\nSo for the nova keypairs I think Keystone is the natural place, as that\ninformation doesn\'t need strong protection, it\'s just public keys.\nFor private keys Keystone wouldn\'t do, and a URL redirection scheme as\nproposed by Jarret makes a lot of sense in this case.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1372777007.30537.42.camel@willson.li.ssimo.org>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051CE844@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-22 16:22:04',0,'2013-07-22 16:22:04',NULL,'[openstack-dev] [barbican]','Hi All,\n\nI am following Barbican project and I have some question around it, I would appreciate if someone  can answer them or point me to the correct resource\n\n\n1.       What is the state of the project, is it in the state where it can be utilized in production deployments?\n\n2.        Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on.\n\n3.        Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far?\n\n\nThanks,\nArvind\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130722/b44d6d1a/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051D11FB@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 16:46:19',0,'2013-07-23 16:46:19',NULL,'[openstack-dev] [barbican]','Thanks Jarret for all the good information.\n\nIt seems KMIP is getting lots of enterprise attention, so I think it may be good candidate for future (as you already mentioned in your email below) Barbican feature,  as per the link below it seems our community also expects KMIP to be integrated with OpenStack line of products.\n\nhttps://wiki.openstack.org/wiki/KMIPclient\n\nWould you mind sharing the Barbican product roadmap (if it is public) as I did not find one?\n\nFollowing are some of thoughts on your previous email about KMIP\n(*) That is true but it is getting lots of recognition which means in future we will see more HSM product with KMIP compatibility.\n(**) I think Barbican will act as a KMS proxy in this case, which does not fulfill the KMIP protocol philosophy which build around interaction between KMIP client and server.\n\n\nRegards,\nArvind\n\n\n\nFrom: Jarret Raim [mailto:jarret.raim at RACKSPACE.COM]\nSent: Monday, July 22, 2013 2:38 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [barbican]\n\nI\'m the product owner for Barbican at Rackspace. I\'ll take a shot an answering your questions.\n\n> 1. What is the state of the project, is it in the state where it can be utilized in production deployments?\n\nWe currently in active development and pushing for our 1.0 release for Havana. As to production deployments, the answer right now is none. We are currently working on enabling Barbican to use hardware security modules for key storage. Once this code is complete, we should be close to a place where the first production deployment is feasible. At Rack, we are building out the infrastructure to do so and I hope to have good news once we get towards the Summit.\n\n> 2. Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on.\n\nWe are inspired by the blueprint you linked. That blueprint was a bit more limited than we were planning and we have changed quite a bit. For a more detailed version, you can find lots of documentation on our wiki here:\n\nhttps://github.com/cloudkeep/barbican/wiki/Blueprint:-Technical-Approach\nhttps://github.com/cloudkeep/barbican\nhttps://github.com/cloudkeep/barbican/wiki\n\n> 3. Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far?\n\nNot right now. As I mentioned in a previous email (I\'ll copy the contents below), KMIP is not the greatest protocol for this use case. Our current plans are to expose the Barbican API to all consumers. This is a standard OpenStack API using ReST / JSON, authing through keystone, etc. If there is enough interest, I am planning on supporting KMIP inside Barbican to talk to various HSM type providers. This would most likely not be exposed to customers.\n\nI haven\'t heard from anyone who needs KMIP support at this point. Mostly the questions have just been whether we are planning on supporting it. If you have a strong use case as to why you want / need it, I\'d love to hear it. You can respond here or reach out to me at jarret.raim at rackspace.com<mailto:jarret.raim at rackspace.com>\n\nThanks,\nJarret\n\n\nHere is the previous email relating to KMIP for additional reading:\n\nI\'m not sure that I agree with this direction. In our investigation, KMIP is a problematic protocol for several reasons:\n\n  *   We haven\'t found an implementation of KMIP for Python. (Let us know if there is one!)\n  *   Support for KMIP by HSM vendors is limited. (*)\n  *   We haven\'t found software implementations of KMIP suitable for use as an HSM replacement. (e.g. Most deployers wanting to use KMIP would have to spend a rather large amount of money to purchase HSMs)\n  *   From our research, the KMIP spec and implementations seem to lack support for multi-tenancy. This makes managing keys for thousands of users difficult or impossible.\nThe goal for the Barbican system is to provide key management for OpenStack. It uses the standard interaction mechanisms for OpenStack, namely ReST and JSON. We integrate with keystone and will provide common features like usage events, role-based access control, fine grained control, policy support, client libs, Celiometer support, Horizon support and other things expected of an OpenStack service. If every product is forced to implement KMIP, these features would most likely not be provided by whatever vendor is used for the Key Manager. Additionally, as mentioned in the blueprint, I have concerns that vendor specific data will be leaked into the rest of OpenStack for things like key identifiers, authentication and the like.\n\n(**) I would propose that rather than each product implement KMIP support, we implement KMIP support into Barbican. This will allow the products to speak ReST / JSON using our client libraries just like any other OpenStack system and Barbican will take care of being a good OpenStack citizen. On the backend, Barbican will support the use of KMIP to talk to whatever device the provider wishes to deploy. We will also support other interaction mechanisms including PKCS through OpenSSH, a development implementation and a fully free and open source software implementation. This also allows some advanced uses cases including federation. Federation will allow customers of public clouds like Rackspace\'s to maintain custody of their keys while still being able to delegate their use to the Cloud for specific tasks.\n\nI\'ve been asked about KMIP support at the Summit and by several of Rackspace\'s partners. I was planning on getting to it at some point, probably after Icehouse. This is mostly due to the fact that we didn\'t find a suitable KMIP implementation for Python so it looks like we\'d have to write one. If there is interest from people to create that implementation, we\'d be happy to help do the work to integrate it into Barbican.\n\nWe just released our M2 milestone and we are on track for our 1.0 release for Havana. I would encourage anyone interested to check our what we are working on and come help us out. We use this list for most of our discussions and we hang out on #openstack-cloudkeep on free node.\n\n\n\n\nFrom: Tiwari, Arvind [mailto:arvind.tiwari at hp.com]\nSent: Monday, July 22, 2013 11:22 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [barbican]\n\nHi All,\n\nI am following Barbican project and I have some question around it, I would appreciate if someone  can answer them or point me to the correct resource\n\n\n1.       What is the state of the project, is it in the state where it can be utilized in production deployments?\n\n2.        Dose Barbican is an implementation of https://wiki.openstack.org/wiki/KeyManager BP? If not please point me to the correct design/BP resource on which Barbican is based on.\n\n3.        Is it KMIP (KMIP 1.1 spec https://www.oasis-open.org/standards#kmipspecv1.1) complaint? If not, what are the plans any initiative so far?\n\n\nThanks,\nArvind\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/c47499d4/attachment.html>\n\n','<6824C20A6CE7A44A939B31B7084E55962246F81E@ORD1EXD03.RACKSPACE.CORP>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051D177B@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 23:08:46',0,'2013-07-23 23:08:46',NULL,'[openstack-dev] [keystone] Extending policy checking to\n	include	target entities','Hi Henry,\n\nDo you have etherpad to capture these stuff?   \n\nArvind\n\n-----Original Message-----\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com] \nSent: Tuesday, July 23, 2013 4:48 PM\nTo: David Chadwick\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities\n\n...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)....so how do we know wether to lie or not?\n\nHenry\nOn 23 Jul 2013, at 21:23, David Chadwick wrote:\n\n> \n> \n> On 23/07/2013 19:02, Henry Nash wrote:\n>> One thing we could do is:\n>> \n>> - Return Forbidden or NotFound if we can determine the correct answer\n>> - When we can\'t (i.e. the object doesn\'t exist), then return NotFound\n>> unless a new config value \'policy_harden\' (?) is set to true (default\n>> false) in which case we translate NotFound into Forbidden.\n> \n> I am not sure that this achieves your objective of no data leakage through error codes, does it?\n> \n> Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not\n> \n> regards\n> \n> David\n>> \n>> Henry\n>> On 23 Jul 2013, at 18:31, Adam Young wrote:\n>> \n>>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n>>>> When writing a previous ISO standard the approach we took was as follows\n>>>> \n>>>> Lie to people who are not authorised.\n>>> \n>>> Is that your verbage?  I am going to reuse that quote, and I would\n>>> like to get the attribution correct.\n>>> \n>>>> \n>>>> So applying this approach to your situation, you could reply Not\n>>>> Found to people who are authorised to see the object if it had\n>>>> existed but does not, and Not Found to those not authorised to see\n>>>> it, regardless of whether it exists or not. In this case, only those\n>>>> who are authorised to see the object will get it if it exists. Those\n>>>> not authorised cannot tell the difference between objects that dont\n>>>> exist and those that do exist\n>>> \n>>> So, to try and apply this to a semi-real example:  There are two types\n>>> of URLs.  Ones that are like this:\n>>> \n>>> users/55FEEDBABECAFE\n>>> \n>>> and ones like this:\n>>> \n>>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n>>> \n>>> \n>>> In the first case, you are selecting against a global collection, and\n>>> in the second, against a scoped collection.\n>>> \n>>> For unscoped, you have to treat all users as equal, and thus a 404\n>>> probably makes sense.\n>>> \n>>> For a scoped collection we could return a 404 or a 403 Forbidden\n>>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users\n>>> credentials:  all resources under domain/66DEADBEEF0000  would show up\n>>> as 403s regardless of existantce or not if the user had no roles in\n>>> the domain 66DEADBEEF0000.  A user that would be allowed access to\n>>> resources in 66DEADBEEF0000  would get a 403 only for an object that\n>>> existed but that they had no permission to read, and 404 for a\n>>> resource that doesn\'t exist.\n>>> \n>>> \n>>> \n>>> \n>>>> \n>>>> regards\n>>>> \n>>>> David\n>>>> \n>>>> \n>>>> On 23/07/2013 16:40, Henry Nash wrote:\n>>>>> Hi\n>>>>> \n>>>>> As part of bp\n>>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n>>>>> I have uploaded some example WIP code showing a proposed approach\n>>>>> for just a few API calls (one easy, one more complex). I\'d\n>>>>> appreciate early feedback on this before I take it any further.\n>>>>> \n>>>>> https://review.openstack.org/#/c/38308/\n>>>>> \n>>>>> A couple of points:\n>>>>> \n>>>>> - One question is on how to handle errors when you are going to get\n>>>>> a target object before doing you policy check.  What do you do if\n>>>>> the object does not exist?  If you return NotFound, then someone,\n>>>>> who was not authorized  could troll for the existence of entities by\n>>>>> seeing whether they got NotFound or Forbidden. If however, you\n>>>>> return Forbidden, then users who are authorized to, say, manage\n>>>>> users in a domain would aways get Forbidden for objects that didn\'t\n>>>>> exist (since we can know where the non-existant object was!).  So\n>>>>> this would modify the expected return codes.\n>>>>> \n>>>>> - I really think we need some good documentation on how to bud\n>>>>> keystone policy files.  I\'m happy to take a first cut as such a\n>>>>> thing - what do you think the right place is for such documentation\n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<00A4FC5C-3BA3-4B4E-BAA9-D83FDD72C3A3@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051D35F1@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 22:26:56',0,'2013-07-24 22:26:56',NULL,'[openstack-dev] [keystone] Extending policy checking to\n	include	target entities','I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target.\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com] \nSent: Wednesday, July 24, 2013 8:46 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities\n\nI think we should transfer this discussion to the etherpad for this blueprint: https://etherpad.openstack.org/api_policy_on_target\n\nI have summarised the views of this thread there already, so let\'s make any further comments there, rather than here.\n\nHenry\nOn 24 Jul 2013, at 00:29, Simo Sorce wrote:\n\n> On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote:\n>> ...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)....so how do we know wether to lie or not?\n> \n> If the error you return is always \'Not Found\', why do you care ?\n> \n> Simo.\n> \n>> Henry\n>> On 23 Jul 2013, at 21:23, David Chadwick wrote:\n>> \n>>> \n>>> \n>>> On 23/07/2013 19:02, Henry Nash wrote:\n>>>> One thing we could do is:\n>>>> \n>>>> - Return Forbidden or NotFound if we can determine the correct answer\n>>>> - When we can\'t (i.e. the object doesn\'t exist), then return NotFound\n>>>> unless a new config value \'policy_harden\' (?) is set to true (default\n>>>> false) in which case we translate NotFound into Forbidden.\n>>> \n>>> I am not sure that this achieves your objective of no data leakage through error codes, does it?\n>>> \n>>> Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not\n>>> \n>>> regards\n>>> \n>>> David\n>>>> \n>>>> Henry\n>>>> On 23 Jul 2013, at 18:31, Adam Young wrote:\n>>>> \n>>>>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n>>>>>> When writing a previous ISO standard the approach we took was as follows\n>>>>>> \n>>>>>> Lie to people who are not authorised.\n>>>>> \n>>>>> Is that your verbage?  I am going to reuse that quote, and I would\n>>>>> like to get the attribution correct.\n>>>>> \n>>>>>> \n>>>>>> So applying this approach to your situation, you could reply Not\n>>>>>> Found to people who are authorised to see the object if it had\n>>>>>> existed but does not, and Not Found to those not authorised to see\n>>>>>> it, regardless of whether it exists or not. In this case, only those\n>>>>>> who are authorised to see the object will get it if it exists. Those\n>>>>>> not authorised cannot tell the difference between objects that dont\n>>>>>> exist and those that do exist\n>>>>> \n>>>>> So, to try and apply this to a semi-real example:  There are two types\n>>>>> of URLs.  Ones that are like this:\n>>>>> \n>>>>> users/55FEEDBABECAFE\n>>>>> \n>>>>> and ones like this:\n>>>>> \n>>>>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n>>>>> \n>>>>> \n>>>>> In the first case, you are selecting against a global collection, and\n>>>>> in the second, against a scoped collection.\n>>>>> \n>>>>> For unscoped, you have to treat all users as equal, and thus a 404\n>>>>> probably makes sense.\n>>>>> \n>>>>> For a scoped collection we could return a 404 or a 403 Forbidden\n>>>>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users\n>>>>> credentials:  all resources under domain/66DEADBEEF0000  would show up\n>>>>> as 403s regardless of existantce or not if the user had no roles in\n>>>>> the domain 66DEADBEEF0000.  A user that would be allowed access to\n>>>>> resources in 66DEADBEEF0000  would get a 403 only for an object that\n>>>>> existed but that they had no permission to read, and 404 for a\n>>>>> resource that doesn\'t exist.\n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>>> \n>>>>>> regards\n>>>>>> \n>>>>>> David\n>>>>>> \n>>>>>> \n>>>>>> On 23/07/2013 16:40, Henry Nash wrote:\n>>>>>>> Hi\n>>>>>>> \n>>>>>>> As part of bp\n>>>>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n>>>>>>> I have uploaded some example WIP code showing a proposed approach\n>>>>>>> for just a few API calls (one easy, one more complex). I\'d\n>>>>>>> appreciate early feedback on this before I take it any further.\n>>>>>>> \n>>>>>>> https://review.openstack.org/#/c/38308/\n>>>>>>> \n>>>>>>> A couple of points:\n>>>>>>> \n>>>>>>> - One question is on how to handle errors when you are going to get\n>>>>>>> a target object before doing you policy check.  What do you do if\n>>>>>>> the object does not exist?  If you return NotFound, then someone,\n>>>>>>> who was not authorized  could troll for the existence of entities by\n>>>>>>> seeing whether they got NotFound or Forbidden. If however, you\n>>>>>>> return Forbidden, then users who are authorized to, say, manage\n>>>>>>> users in a domain would aways get Forbidden for objects that didn\'t\n>>>>>>> exist (since we can know where the non-existant object was!).  So\n>>>>>>> this would modify the expected return codes.\n>>>>>>> \n>>>>>>> - I really think we need some good documentation on how to bud\n>>>>>>> keystone policy files.  I\'m happy to take a first cut as such a\n>>>>>>> thing - what do you think the right place is for such documentation\n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> -- \n> Simo Sorce * Red Hat, Inc * New York\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CED09336-925F-4D80-A5E9-CE66CF8F4E1C@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051D3E17@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-25 15:18:26',0,'2013-07-25 15:18:26',NULL,'[openstack-dev]  [keystone] Does authorization not needed on “/auth/tokens” API??','Thanks David.\n\nSince we are discussing authorization and access control, I would like to gain little attention on the below bug which basically propose authorization check on  identity:check_token, identity:validate_token and identity:revoke_token APIs\n \nhttps://bugs.launchpad.net/keystone/+bug/1186059\n\nDue to absence of a target on such API calls Auth is  not possible, I would appreciate community\'s thoughts on the bug.  \n\nThanks,\nArvind\n\n\n\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Thursday, July 25, 2013 4:10 AM\nTo: OpenStack Development Mailing List\nCc: Tiwari, Arvind\nSubject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities\n\nI have responded to your post, as I dont think it solves the identified \nproblem\n\nregards\n\nDavid\n\nOn 24/07/2013 23:26, Tiwari, Arvind wrote:\n> I have added my proposal @ https://etherpad.openstack.org/api_policy_on_target.\n>\n> Thanks,\n> Arvind\n>\n> -----Original Message-----\n> From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]\n> Sent: Wednesday, July 24, 2013 8:46 AM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities\n>\n> I think we should transfer this discussion to the etherpad for this blueprint: https://etherpad.openstack.org/api_policy_on_target\n>\n> I have summarised the views of this thread there already, so let\'s make any further comments there, rather than here.\n>\n> Henry\n> On 24 Jul 2013, at 00:29, Simo Sorce wrote:\n>\n>> On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote:\n>>> ...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)....so how do we know wether to lie or not?\n>>\n>> If the error you return is always \'Not Found\', why do you care ?\n>>\n>> Simo.\n>>\n>>> Henry\n>>> On 23 Jul 2013, at 21:23, David Chadwick wrote:\n>>>\n>>>>\n>>>>\n>>>> On 23/07/2013 19:02, Henry Nash wrote:\n>>>>> One thing we could do is:\n>>>>>\n>>>>> - Return Forbidden or NotFound if we can determine the correct answer\n>>>>> - When we can\'t (i.e. the object doesn\'t exist), then return NotFound\n>>>>> unless a new config value \'policy_harden\' (?) is set to true (default\n>>>>> false) in which case we translate NotFound into Forbidden.\n>>>>\n>>>> I am not sure that this achieves your objective of no data leakage through error codes, does it?\n>>>>\n>>>> Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not\n>>>>\n>>>> regards\n>>>>\n>>>> David\n>>>>>\n>>>>> Henry\n>>>>> On 23 Jul 2013, at 18:31, Adam Young wrote:\n>>>>>\n>>>>>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n>>>>>>> When writing a previous ISO standard the approach we took was as follows\n>>>>>>>\n>>>>>>> Lie to people who are not authorised.\n>>>>>>\n>>>>>> Is that your verbage?  I am going to reuse that quote, and I would\n>>>>>> like to get the attribution correct.\n>>>>>>\n>>>>>>>\n>>>>>>> So applying this approach to your situation, you could reply Not\n>>>>>>> Found to people who are authorised to see the object if it had\n>>>>>>> existed but does not, and Not Found to those not authorised to see\n>>>>>>> it, regardless of whether it exists or not. In this case, only those\n>>>>>>> who are authorised to see the object will get it if it exists. Those\n>>>>>>> not authorised cannot tell the difference between objects that dont\n>>>>>>> exist and those that do exist\n>>>>>>\n>>>>>> So, to try and apply this to a semi-real example:  There are two types\n>>>>>> of URLs.  Ones that are like this:\n>>>>>>\n>>>>>> users/55FEEDBABECAFE\n>>>>>>\n>>>>>> and ones like this:\n>>>>>>\n>>>>>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n>>>>>>\n>>>>>>\n>>>>>> In the first case, you are selecting against a global collection, and\n>>>>>> in the second, against a scoped collection.\n>>>>>>\n>>>>>> For unscoped, you have to treat all users as equal, and thus a 404\n>>>>>> probably makes sense.\n>>>>>>\n>>>>>> For a scoped collection we could return a 404 or a 403 Forbidden\n>>>>>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users\n>>>>>> credentials:  all resources under domain/66DEADBEEF0000  would show up\n>>>>>> as 403s regardless of existantce or not if the user had no roles in\n>>>>>> the domain 66DEADBEEF0000.  A user that would be allowed access to\n>>>>>> resources in 66DEADBEEF0000  would get a 403 only for an object that\n>>>>>> existed but that they had no permission to read, and 404 for a\n>>>>>> resource that doesn\'t exist.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>\n>>>>>>> regards\n>>>>>>>\n>>>>>>> David\n>>>>>>>\n>>>>>>>\n>>>>>>> On 23/07/2013 16:40, Henry Nash wrote:\n>>>>>>>> Hi\n>>>>>>>>\n>>>>>>>> As part of bp\n>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n>>>>>>>> I have uploaded some example WIP code showing a proposed approach\n>>>>>>>> for just a few API calls (one easy, one more complex). I\'d\n>>>>>>>> appreciate early feedback on this before I take it any further.\n>>>>>>>>\n>>>>>>>> https://review.openstack.org/#/c/38308/\n>>>>>>>>\n>>>>>>>> A couple of points:\n>>>>>>>>\n>>>>>>>> - One question is on how to handle errors when you are going to get\n>>>>>>>> a target object before doing you policy check.  What do you do if\n>>>>>>>> the object does not exist?  If you return NotFound, then someone,\n>>>>>>>> who was not authorized  could troll for the existence of entities by\n>>>>>>>> seeing whether they got NotFound or Forbidden. If however, you\n>>>>>>>> return Forbidden, then users who are authorized to, say, manage\n>>>>>>>> users in a domain would aways get Forbidden for objects that didn\'t\n>>>>>>>> exist (since we can know where the non-existant object was!).  So\n>>>>>>>> this would modify the expected return codes.\n>>>>>>>>\n>>>>>>>> - I really think we need some good documentation on how to bud\n>>>>>>>> keystone policy files.  I\'m happy to take a first cut as such a\n>>>>>>>> thing - what do you think the right place is for such documentation\n>>>>>>>>\n>>>>>>>> _______________________________________________\n>>>>>>>> OpenStack-dev mailing list\n>>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>>>\n>>>>>>>\n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>\n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>\n>>>>>\n>>>>>\n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>\n>>>>\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>> --\n>> Simo Sorce * Red Hat, Inc * New York\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<51F0F98B.7040300@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39051D415A@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-25 17:03:40',0,'2013-07-25 17:03:40',NULL,'[openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??','Thanks David for your comments.\n\nI will try to fix it as per my suggestion in bug. \n\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Thursday, July 25, 2013 10:27 AM\nTo: Tiwari, Arvind\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Does authorization not needed on ?/auth/tokens? API??\n\nHi Arvind\n\nthanks for pointing me to this issue, which I was not aware of. I have \nposted my twopence worth to the bug. Basically I agree with you, that if \nyou want audit of third parties revoking tokens, then you need the token \nof the subject to be revoked and the third party requesting it.\n\nregards\n\nDavid\n\nOn 25/07/2013 16:18, Tiwari, Arvind wrote:\n> Thanks David.\n>\n> Since we are discussing authorization and access control, I would\n> like to gain little attention on the below bug which basically\n> propose authorization check on  identity:check_token,\n> identity:validate_token and identity:revoke_token APIs\n>\n> https://bugs.launchpad.net/keystone/+bug/1186059\n>\n> Due to absence of a target on such API calls Auth is  not possible, I\n> would appreciate community\'s thoughts on the bug.\n>\n> Thanks, Arvind\n>\n>\n>\n>\n> -----Original Message----- From: David Chadwick\n> [mailto:d.w.chadwick at kent.ac.uk] Sent: Thursday, July 25, 2013 4:10\n> AM To: OpenStack Development Mailing List Cc: Tiwari, Arvind Subject:\n> Re: [openstack-dev] [keystone] Extending policy checking to include\n> target entities\n>\n> I have responded to your post, as I dont think it solves the\n> identified problem\n>\n> regards\n>\n> David\n>\n> On 24/07/2013 23:26, Tiwari, Arvind wrote:\n>> I have added my proposal @\n>> https://etherpad.openstack.org/api_policy_on_target.\n>>\n>> Thanks, Arvind\n>>\n>> -----Original Message----- From: Henry Nash\n>> [mailto:henryn at linux.vnet.ibm.com] Sent: Wednesday, July 24, 2013\n>> 8:46 AM To: OpenStack Development Mailing List Subject: Re:\n>> [openstack-dev] [keystone] Extending policy checking to include\n>> target entities\n>>\n>> I think we should transfer this discussion to the etherpad for this\n>> blueprint: https://etherpad.openstack.org/api_policy_on_target\n>>\n>> I have summarised the views of this thread there already, so let\'s\n>> make any further comments there, rather than here.\n>>\n>> Henry On 24 Jul 2013, at 00:29, Simo Sorce wrote:\n>>\n>>> On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote:\n>>>> ...the problem is that if the object does not exists we might\n>>>> not be able tell whether the use is authorized or not (since\n>>>> authorization might depend on attributes of the object\n>>>> itself)....so how do we know wether to lie or not?\n>>>\n>>> If the error you return is always \'Not Found\', why do you care ?\n>>>\n>>> Simo.\n>>>\n>>>> Henry On 23 Jul 2013, at 21:23, David Chadwick wrote:\n>>>>\n>>>>>\n>>>>>\n>>>>> On 23/07/2013 19:02, Henry Nash wrote:\n>>>>>> One thing we could do is:\n>>>>>>\n>>>>>> - Return Forbidden or NotFound if we can determine the\n>>>>>> correct answer - When we can\'t (i.e. the object doesn\'t\n>>>>>> exist), then return NotFound unless a new config value\n>>>>>> \'policy_harden\' (?) is set to true (default false) in which\n>>>>>> case we translate NotFound into Forbidden.\n>>>>>\n>>>>> I am not sure that this achieves your objective of no data\n>>>>> leakage through error codes, does it?\n>>>>>\n>>>>> Its not a question of determining the correct answer or not,\n>>>>> its a question of whether the user is authorised to see the\n>>>>> correct answer or not\n>>>>>\n>>>>> regards\n>>>>>\n>>>>> David\n>>>>>>\n>>>>>> Henry On 23 Jul 2013, at 18:31, Adam Young wrote:\n>>>>>>\n>>>>>>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n>>>>>>>> When writing a previous ISO standard the approach we\n>>>>>>>> took was as follows\n>>>>>>>>\n>>>>>>>> Lie to people who are not authorised.\n>>>>>>>\n>>>>>>> Is that your verbage?  I am going to reuse that quote,\n>>>>>>> and I would like to get the attribution correct.\n>>>>>>>\n>>>>>>>>\n>>>>>>>> So applying this approach to your situation, you could\n>>>>>>>> reply Not Found to people who are authorised to see the\n>>>>>>>> object if it had existed but does not, and Not Found to\n>>>>>>>> those not authorised to see it, regardless of whether\n>>>>>>>> it exists or not. In this case, only those who are\n>>>>>>>> authorised to see the object will get it if it exists.\n>>>>>>>> Those not authorised cannot tell the difference between\n>>>>>>>> objects that dont exist and those that do exist\n>>>>>>>\n>>>>>>> So, to try and apply this to a semi-real example:  There\n>>>>>>> are two types of URLs.  Ones that are like this:\n>>>>>>>\n>>>>>>> users/55FEEDBABECAFE\n>>>>>>>\n>>>>>>> and ones like this:\n>>>>>>>\n>>>>>>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n>>>>>>>\n>>>>>>>\n>>>>>>> In the first case, you are selecting against a global\n>>>>>>> collection, and in the second, against a scoped\n>>>>>>> collection.\n>>>>>>>\n>>>>>>> For unscoped, you have to treat all users as equal, and\n>>>>>>> thus a 404 probably makes sense.\n>>>>>>>\n>>>>>>> For a scoped collection we could return a 404 or a 403\n>>>>>>> Forbidden <https://en.wikipedia.org/wiki/HTTP_403> based\n>>>>>>> on the users credentials:  all resources under\n>>>>>>> domain/66DEADBEEF0000  would show up as 403s regardless\n>>>>>>> of existantce or not if the user had no roles in the\n>>>>>>> domain 66DEADBEEF0000.  A user that would be allowed\n>>>>>>> access to resources in 66DEADBEEF0000  would get a 403\n>>>>>>> only for an object that existed but that they had no\n>>>>>>> permission to read, and 404 for a resource that doesn\'t\n>>>>>>> exist.\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>\n>>>>>>>> regards\n>>>>>>>>\n>>>>>>>> David\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> On 23/07/2013 16:40, Henry Nash wrote:\n>>>>>>>>> Hi\n>>>>>>>>>\n>>>>>>>>> As part of bp\n>>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n>>>>>>>>>\n>>>>>>>>>\nI have uploaded some example WIP code showing a proposed approach\n>>>>>>>>> for just a few API calls (one easy, one more\n>>>>>>>>> complex). I\'d appreciate early feedback on this\n>>>>>>>>> before I take it any further.\n>>>>>>>>>\n>>>>>>>>> https://review.openstack.org/#/c/38308/\n>>>>>>>>>\n>>>>>>>>> A couple of points:\n>>>>>>>>>\n>>>>>>>>> - One question is on how to handle errors when you\n>>>>>>>>> are going to get a target object before doing you\n>>>>>>>>> policy check.  What do you do if the object does not\n>>>>>>>>> exist?  If you return NotFound, then someone, who was\n>>>>>>>>> not authorized  could troll for the existence of\n>>>>>>>>> entities by seeing whether they got NotFound or\n>>>>>>>>> Forbidden. If however, you return Forbidden, then\n>>>>>>>>> users who are authorized to, say, manage users in a\n>>>>>>>>> domain would aways get Forbidden for objects that\n>>>>>>>>> didn\'t exist (since we can know where the\n>>>>>>>>> non-existant object was!).  So this would modify the\n>>>>>>>>> expected return codes.\n>>>>>>>>>\n>>>>>>>>> - I really think we need some good documentation on\n>>>>>>>>> how to bud keystone policy files.  I\'m happy to take\n>>>>>>>>> a first cut as such a thing - what do you think the\n>>>>>>>>> right place is for such documentation\n>>>>>>>>>\n>>>>>>>>> _______________________________________________\n>>>>>>>>> OpenStack-dev mailing list\n>>>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>\n_______________________________________________\n>>>>>>>> OpenStack-dev mailing list\n>>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>>\n>>>>>>>\n>>>>>>>>\n_______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> <mailto:OpenStack-dev at lists.openstack.org>\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>\n_______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>>>>\n_______________________________________________\n>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>>\n>>>>\n--\n>>> Simo Sorce * Red Hat, Inc * New York\n>>>\n>>>\n>>> _______________________________________________ OpenStack-dev\n>>> mailing list OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>\n>>\n>>\n>>>\n_______________________________________________\n>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________ OpenStack-dev\n>> mailing list OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n\n\n','<51F151E1.4020004@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052CFC41@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 00:01:08',0,'2013-11-19 00:01:08',NULL,'[openstack-dev]  [keystone] Service scoped role definition','Hi,\n\nBased on our discussion in design summit , I have redone the service_id binding with roles BP<https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>. I have added a new BP (link below) along with detailed use case to support this BP.\nhttps://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\nBelow etherpad link has some proposals for Role REST representation and pros and cons analysis\n\nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\nPlease take look and let me know your thoughts.\n\nIt would be awesome if we can discuss it in tomorrow\'s meeting.\n\nThanks,\nArvind\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131119/3c74eb23/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052E8BB6@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 23:07:59',0,'2013-11-26 23:07:59',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nThanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n\nLet me know your thoughts, please feel free to update below etherpad   \nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\nThanks again,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Monday, November 25, 2013 12:12 PM\nTo: Tiwari, Arvind; OpenStack Development Mailing List\nCc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Arvind\n\nI have just added some comments to your blueprint page\n\nregards\n\nDavid\n\n\nOn 19/11/2013 00:01, Tiwari, Arvind wrote:\n> Hi,\n> \n>  \n> \n> Based on our discussion in design summit , I have redone the service_id\n> binding with roles BP\n> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n> I have added a new BP (link below) along with detailed use case to\n> support this BP.\n> \n> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n> \n> Below etherpad link has some proposals for Role REST representation and\n> pros and cons analysis\n> \n>  \n> \n> https://etherpad.openstack.org/p/service-scoped-role-definition\n> \n>  \n> \n> Please take look and let me know your thoughts.\n> \n>  \n> \n> It would be awesome if we can discuss it in tomorrow\'s meeting.\n> \n>  \n> \n> Thanks,\n> \n> Arvind\n> \n\n\n','<5293A0F8.6010906@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052E8C7B@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 23:57:13',0,'2013-11-26 23:57:13',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi Adam,\n\nBased on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n\nhttps://etherpad.openstack.org/p/service-scoped-role-definition \n\nPlease take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea. \n\nFeel free to update the etherpad.\n\nRegards,\nArvind\n\n\n-----Original Message-----\nFrom: Tiwari, Arvind \nSent: Tuesday, November 26, 2013 4:08 PM\nTo: David Chadwick; OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi David,\n\nThanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n\nLet me know your thoughts, please feel free to update below etherpad   \nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\nThanks again,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Monday, November 25, 2013 12:12 PM\nTo: Tiwari, Arvind; OpenStack Development Mailing List\nCc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Arvind\n\nI have just added some comments to your blueprint page\n\nregards\n\nDavid\n\n\nOn 19/11/2013 00:01, Tiwari, Arvind wrote:\n> Hi,\n> \n>  \n> \n> Based on our discussion in design summit , I have redone the service_id\n> binding with roles BP\n> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n> I have added a new BP (link below) along with detailed use case to\n> support this BP.\n> \n> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n> \n> Below etherpad link has some proposals for Role REST representation and\n> pros and cons analysis\n> \n>  \n> \n> https://etherpad.openstack.org/p/service-scoped-role-definition\n> \n>  \n> \n> Please take look and let me know your thoughts.\n> \n>  \n> \n> It would be awesome if we can discuss it in tomorrow\'s meeting.\n> \n>  \n> \n> Thanks,\n> \n> Arvind\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0EF5F110A32BED44A0C6438BB5C35B39052E8BB6@G9W0721.americas.hpqcorp.net>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052EC845@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-02 23:21:41',0,'2013-12-02 23:21:41',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi Adam and David,\n\nThank you so much for all the great comments, seems we are making good progress.\n\nI have replied to your comments and also added some to support my proposal\n\nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\nDavid, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B.\n\nPlease let me know if David\'s proposal for role-def scoping is cool for everybody?\n\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: Adam Young [mailto:ayoung at redhat.com] \nSent: Wednesday, November 27, 2013 8:44 AM\nTo: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\n\n\nOn 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n> Hi Adam,\n>\n> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n\nUpdated.  I made my changes Green.  It isn\'t easy being green.\n\n>\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>\n> Feel free to update the etherpad.\n>\n> Regards,\n> Arvind\n>\n>\n> -----Original Message-----\n> From: Tiwari, Arvind\n> Sent: Tuesday, November 26, 2013 4:08 PM\n> To: David Chadwick; OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi David,\n>\n> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>\n> Let me know your thoughts, please feel free to update below etherpad\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Thanks again,\n> Arvind\n>\n> -----Original Message-----\n> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n> Sent: Monday, November 25, 2013 12:12 PM\n> To: Tiwari, Arvind; OpenStack Development Mailing List\n> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi Arvind\n>\n> I have just added some comments to your blueprint page\n>\n> regards\n>\n> David\n>\n>\n> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>> Hi,\n>>\n>>   \n>>\n>> Based on our discussion in design summit , I have redone the service_id\n>> binding with roles BP\n>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>> I have added a new BP (link below) along with detailed use case to\n>> support this BP.\n>>\n>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>\n>> Below etherpad link has some proposals for Role REST representation and\n>> pros and cons analysis\n>>\n>>   \n>>\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>>   \n>>\n>> Please take look and let me know your thoughts.\n>>\n>>   \n>>\n>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>\n>>   \n>>\n>> Thanks,\n>>\n>> Arvind\n>>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5296134E.8060104@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052F4799@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 23:58:29',0,'2013-12-03 23:58:29',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nI have added my comments underneath line # 97 till line #110, it is mostly aligned with your proposal with some modification.\n \nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\n\nThanks for your time,\nArvind\n\n\n\n-----Original Message-----\nFrom: Tiwari, Arvind \nSent: Monday, December 02, 2013 4:22 PM\nTo: Adam Young; OpenStack Development Mailing List (not for usage questions); David Chadwick\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Adam and David,\n\nThank you so much for all the great comments, seems we are making good progress.\n\nI have replied to your comments and also added some to support my proposal\n\nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\nDavid, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B.\n\nPlease let me know if David\'s proposal for role-def scoping is cool for everybody?\n\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: Adam Young [mailto:ayoung at redhat.com] \nSent: Wednesday, November 27, 2013 8:44 AM\nTo: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\n\n\nOn 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n> Hi Adam,\n>\n> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n\nUpdated.  I made my changes Green.  It isn\'t easy being green.\n\n>\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>\n> Feel free to update the etherpad.\n>\n> Regards,\n> Arvind\n>\n>\n> -----Original Message-----\n> From: Tiwari, Arvind\n> Sent: Tuesday, November 26, 2013 4:08 PM\n> To: David Chadwick; OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi David,\n>\n> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>\n> Let me know your thoughts, please feel free to update below etherpad\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Thanks again,\n> Arvind\n>\n> -----Original Message-----\n> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n> Sent: Monday, November 25, 2013 12:12 PM\n> To: Tiwari, Arvind; OpenStack Development Mailing List\n> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi Arvind\n>\n> I have just added some comments to your blueprint page\n>\n> regards\n>\n> David\n>\n>\n> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>> Hi,\n>>\n>>   \n>>\n>> Based on our discussion in design summit , I have redone the service_id\n>> binding with roles BP\n>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>> I have added a new BP (link below) along with detailed use case to\n>> support this BP.\n>>\n>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>\n>> Below etherpad link has some proposals for Role REST representation and\n>> pros and cons analysis\n>>\n>>   \n>>\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>>   \n>>\n>> Please take look and let me know your thoughts.\n>>\n>>   \n>>\n>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>\n>>   \n>>\n>> Thanks,\n>>\n>> Arvind\n>>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0EF5F110A32BED44A0C6438BB5C35B39052EC845@G9W0721.americas.hpqcorp.net>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052F5728@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 17:21:29',0,'2013-12-04 17:21:29',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi Adam,\n\nI have added my comments in line. \n\nAs per my request yesterday and David\'s proposal, following role-def data model is looks generic enough and seems innovative to accommodate future extensions.\n\n{\n  \"role\": {\n    \"id\": \"76e72a\",\n    \"name\": \"admin\", (you can give whatever name you like)\n    \"scope\": {\n      \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource in type and must be immutable value)\n      \"type\": \"service | file | domain etc.\", (Type can be any type of resource which explains the scoping context)\n      \"interface\":\"--interface--\"  (We are still need working on this field. My idea of this optional field is to indicate the interface of the resource (endpoint for service, path for File,....) for which the role-def is 						created and can be empty.)\n    }\n  }\n}\n\nBased on above data model two admin roles for nova for two separate region wd be as below\n\n{\n  \"role\": {\n    \"id\": \"76e71a\",\n    \"name\": \"admin\",\n    \"scope\": {\n      \"id\": \"110\", (suppose 110 is Nova serviceId)\n      \"interface\": \"1101\", (suppose 1101 is Nova region East endpointId)\n      \"type\": \"service\"\n    }\n  }\n}\n\n{\n  \"role\": {\n    \"id\": \"76e72a\",\n    \"name\": \"admin\",\n    \"scope\": {\n      \"id\": \"110\", \n      \"interface\": \"1102\",(suppose 1102 is Nova region West endpointId)\n      \"type\": \"service\"\n    }\n  }\n}\n\nThis way we can keep role-assignments abstracted from resource on which the assignment is created. This also open doors to have service and/or endpoint scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq.\n\nDavid, I have updated https://etherpad.openstack.org/p/service-scoped-role-definition line #118 explaining the rationale behind the field.\nI wd also appreciate your vision on https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: Adam Young [mailto:ayoung at redhat.com] \nSent: Tuesday, December 03, 2013 6:52 PM\nTo: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nI\'ve been thinking about your comment that \"nested roles are confusing\"\nAT: Thanks for considering my comment about nested role-def.\n\nWhat if we backed off and said the following:\n\n\n\"Some role-definitions are owned by services.  If a Role definition is \nowned by a service, in role assignment lists in tokens, those roles we \nbe prefixd by the service name.  / is a reserved cahracter and weill be \nused as the divider between segments of the role definition \"\n\nThat drops arbitrary nesting, and provides a reasonable namespace.  Then \na role def would look like:\n\n\"glance/admin\"  for the admin role on the glance project.\n\nAT: It seems this approach is not going to help, service rename would impact all the role-def for a particular service. And we are back to the same problem.\n\nIn theory, we could add the domain to the namespace, but that seems \nunwieldy.  If we did, a role def would then look like this\n\n\n\"default/glance/admin\"  for the admin role on the glance project.\n\nIs that clearer than the nested roles?\nAT: It is defiantly clearer but it will create same problems as what we are trying to fix. \n\n\n\nOn 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n> Hi Adam,\n>\n> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n>\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>\n> Feel free to update the etherpad.\n>\n> Regards,\n> Arvind\n>\n>\n> -----Original Message-----\n> From: Tiwari, Arvind\n> Sent: Tuesday, November 26, 2013 4:08 PM\n> To: David Chadwick; OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi David,\n>\n> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>\n> Let me know your thoughts, please feel free to update below etherpad\n> https://etherpad.openstack.org/p/service-scoped-role-definition\n>\n> Thanks again,\n> Arvind\n>\n> -----Original Message-----\n> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n> Sent: Monday, November 25, 2013 12:12 PM\n> To: Tiwari, Arvind; OpenStack Development Mailing List\n> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>\n> Hi Arvind\n>\n> I have just added some comments to your blueprint page\n>\n> regards\n>\n> David\n>\n>\n> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>> Hi,\n>>\n>>   \n>>\n>> Based on our discussion in design summit , I have redone the service_id\n>> binding with roles BP\n>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>> I have added a new BP (link below) along with detailed use case to\n>> support this BP.\n>>\n>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>\n>> Below etherpad link has some proposals for Role REST representation and\n>> pros and cons analysis\n>>\n>>   \n>>\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>>   \n>>\n>> Please take look and let me know your thoughts.\n>>\n>>   \n>>\n>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>\n>>   \n>>\n>> Thanks,\n>>\n>> Arvind\n>>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<529E8AB9.1080704@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052F575D@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 17:28:59',0,'2013-12-04 17:28:59',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David, \n\nThanks for your valuable comments. \n\nI have updated https://etherpad.openstack.org/p/service-scoped-role-definition line #118 explaining the rationale behind the field.\n\nI wd also appreciate your thoughts on https://etherpad.openstack.org/p/1Uiwcbfpxq too, which is support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Wednesday, December 04, 2013 2:16 AM\nTo: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions); Adam Young\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nI have added comments 111 to 122\n\ndavid\n\nOn 03/12/2013 23:58, Tiwari, Arvind wrote:\n> Hi David,\n> \n> I have added my comments underneath line # 97 till line #110, it is mostly aligned with your proposal with some modification.\n>  \n> https://etherpad.openstack.org/p/service-scoped-role-definition\n> \n> \n> Thanks for your time,\n> Arvind\n> \n> \n> \n> -----Original Message-----\n> From: Tiwari, Arvind \n> Sent: Monday, December 02, 2013 4:22 PM\n> To: Adam Young; OpenStack Development Mailing List (not for usage questions); David Chadwick\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> Hi Adam and David,\n> \n> Thank you so much for all the great comments, seems we are making good progress.\n> \n> I have replied to your comments and also added some to support my proposal\n> \n> https://etherpad.openstack.org/p/service-scoped-role-definition\n> \n> David, I like your suggestion for role-def scoping which can fit in my Plan B and I think Adam is cool with plan B.\n> \n> Please let me know if David\'s proposal for role-def scoping is cool for everybody?\n> \n> \n> Thanks,\n> Arvind\n> \n> -----Original Message-----\n> From: Adam Young [mailto:ayoung at redhat.com] \n> Sent: Wednesday, November 27, 2013 8:44 AM\n> To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\n> Cc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> \n> \n> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>> Hi Adam,\n>>\n>> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n> \n> Updated.  I made my changes Green.  It isn\'t easy being green.\n> \n>>\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>>\n>> Feel free to update the etherpad.\n>>\n>> Regards,\n>> Arvind\n>>\n>>\n>> -----Original Message-----\n>> From: Tiwari, Arvind\n>> Sent: Tuesday, November 26, 2013 4:08 PM\n>> To: David Chadwick; OpenStack Development Mailing List\n>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>\n>> Hi David,\n>>\n>> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>>\n>> Let me know your thoughts, please feel free to update below etherpad\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>> Thanks again,\n>> Arvind\n>>\n>> -----Original Message-----\n>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>> Sent: Monday, November 25, 2013 12:12 PM\n>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>\n>> Hi Arvind\n>>\n>> I have just added some comments to your blueprint page\n>>\n>> regards\n>>\n>> David\n>>\n>>\n>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>> Hi,\n>>>\n>>>   \n>>>\n>>> Based on our discussion in design summit , I have redone the service_id\n>>> binding with roles BP\n>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>> I have added a new BP (link below) along with detailed use case to\n>>> support this BP.\n>>>\n>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>\n>>> Below etherpad link has some proposals for Role REST representation and\n>>> pros and cons analysis\n>>>\n>>>   \n>>>\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>>   \n>>>\n>>> Please take look and let me know your thoughts.\n>>>\n>>>   \n>>>\n>>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>\n>>>   \n>>>\n>>> Thanks,\n>>>\n>>> Arvind\n>>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<529EF2CA.6030304@kent.ac.uk>',NULL);
INSERT INTO `messages` VALUES ('<0EF5F110A32BED44A0C6438BB5C35B39052F58C6@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 19:04:45',0,'2013-12-04 19:04:45',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nThe biggest problems in my opinion are, \n\n1. We are overloading and adding extra complexities on role name to maintain the generalization for role-def data model. \n2. Name spacing the role name is not going to resolve all the issues listed in BP.\n3. All the namespaces are derived from mutable string  (domain name, project name, service name etc...) which makes the role name fragile.\n\nI think it is time to break generic role-def data model to accommodate more specialized use cases.\n\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Wednesday, December 04, 2013 10:41 AM\nTo: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Adam\n\nI understand your problem: having projects and services which have the\nsame name, then the lineage of a role containing this name is not\ndeterministically known without some other rule or syntax that can\ndifferentiate between the two.\n\nSince domains contain projects which contain services then isnt the\ncontainment hierarchy already known and predetermined? If it is then:\n\n4 name components mean it is a service specified role\n3 name components mean it is a project specified role\n2 name components mean it is a domain specified role\n1 name component means it is globally named role (from the default domain)\n\na null string means the default domain or all projects in a domain. You\nwould never have null for a service name.\n\nadmin means the global admin role\n/admin ditto\nx/admin means the admin of the X domain\nx/y/admin means the admin role for the y project in domain x\n//x/admin means admin for service x from the default domain\netc.\n\nwill that work?\n\nregards\n\nDavid\n\n\nOn 04/12/2013 15:04, Adam Young wrote:\n> On 12/04/2013 04:08 AM, David Chadwick wrote:\n>> I am happy with this as far as it goes. I would like to see it being\n>> made more general, where domains, services and projects can also own and\n>> name roles\n> Domains should be OK, but services would confuse the matter.  You\'d have\n> to end up with something like LDAP\n> \n> role=  domain=default,service=glance\n> \n> vs\n> \n> role=  domain=default,project=glance\n> \n> unless we have unambiguous implicit ordering, we\'ll need to make it\n> explicit, which is messy.\n> \n> I\'d rather do:\n> \n> One segment: globally defined roles.  These could also be considered\n> roles defined in the default domain.\n> Two segments service defined roles in the default domain\n> Three Segments, service defined roles from non-default domain\n> \n> To do domain scoped roles we could do something like:\n> \n> domX//admin\n> \n> \n> But It seems confusing.\n> \n> Perhaps a better approach for project roles is to have the rule that the\n> default domain can show up as an empty string.  Thus, project scoped\n> roles from the default domain  would be:\n> \n> \\glance\\admin\n> \n> and from a non default domain\n> \n> domX\\glance\\admin\n> \n> \n> \n> \n> \n> \n> \n>>\n>> regards\n>>\n>> David\n>>\n>>\n>> On 04/12/2013 01:51, Adam Young wrote:\n>>> I\'ve been thinking about your comment that \"nested roles are confusing\"\n>>>\n>>>\n>>> What if we backed off and said the following:\n>>>\n>>>\n>>> \"Some role-definitions are owned by services.  If a Role definition is\n>>> owned by a service, in role assignment lists in tokens, those roles we\n>>> be prefixd by the service name.  / is a reserved cahracter and weill be\n>>> used as the divider between segments of the role definition \"\n>>>\n>>> That drops arbitrary nesting, and provides a reasonable namespace.  Then\n>>> a role def would look like:\n>>>\n>>> \"glance/admin\"  for the admin role on the glance project.\n>>>\n>>>\n>>>\n>>> In theory, we could add the domain to the namespace, but that seems\n>>> unwieldy.  If we did, a role def would then look like this\n>>>\n>>>\n>>> \"default/glance/admin\"  for the admin role on the glance project.\n>>>\n>>> Is that clearer than the nested roles?\n>>>\n>>>\n>>>\n>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>>> Hi Adam,\n>>>>\n>>>> Based on our discussion over IRC, I have updated the below etherpad\n>>>> with proposal for nested role definition\n>>>>\n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I\n>>>> am sorry if I could not catch your idea.\n>>>>\n>>>> Feel free to update the etherpad.\n>>>>\n>>>> Regards,\n>>>> Arvind\n>>>>\n>>>>\n>>>> -----Original Message-----\n>>>> From: Tiwari, Arvind\n>>>> Sent: Tuesday, November 26, 2013 4:08 PM\n>>>> To: David Chadwick; OpenStack Development Mailing List\n>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>\n>>>> Hi David,\n>>>>\n>>>> Thanks for your time and valuable comments. I have replied to your\n>>>> comments and try to explain why I am advocating to this BP.\n>>>>\n>>>> Let me know your thoughts, please feel free to update below etherpad\n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>> Thanks again,\n>>>> Arvind\n>>>>\n>>>> -----Original Message-----\n>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>>> Sent: Monday, November 25, 2013 12:12 PM\n>>>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>\n>>>> Hi Arvind\n>>>>\n>>>> I have just added some comments to your blueprint page\n>>>>\n>>>> regards\n>>>>\n>>>> David\n>>>>\n>>>>\n>>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>>> Hi,\n>>>>>\n>>>>>   Based on our discussion in design summit , I have redone the\n>>>>> service_id\n>>>>> binding with roles BP\n>>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>>>\n>>>>>\n>>>>> I have added a new BP (link below) along with detailed use case to\n>>>>> support this BP.\n>>>>>\n>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>>\n>>>>>\n>>>>>\n>>>>> Below etherpad link has some proposals for Role REST representation\n>>>>> and\n>>>>> pros and cons analysis\n>>>>>\n>>>>>   https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>\n>>>>>   Please take look and let me know your thoughts.\n>>>>>\n>>>>>   It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>>>\n>>>>>   Thanks,\n>>>>>\n>>>>> Arvind\n>>>>>\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<529F691D.1000007@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052F5937@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 19:42:25',0,'2013-12-04 19:42:25',NULL,'[openstack-dev] [keystone] Service scoped role definition','Thanks David,\n\nAppended line # 119 with my reply. \"endpoint\" sounds perfect to me.\n\nIn a nutshell we are agreeing on following new data model for role-def. \n\n{\n  \"role\": {\n    \"id\": \"76e72a\",\n    \"name\": \"admin\", (you can give whatever name you like)\n    \"scope\": {\n      \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource in type and must be immutable value)\n      \"type\": \"service | file | domain etc.\", (Type can be any type of resource which explains the scoping context)\n      \"endpoint\":\"-- endpoint--\"  (An optional field to indicate the interface of the resource (endpoint for service, path for File,....) for which the role-def is created.)\n    }\n  }\n}\n\nIf other community members are cool with this, I will start drafting the API specs?\n\n\nRegards,\nArvind\n\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Wednesday, December 04, 2013 11:42 AM\nTo: Tiwari, Arvind; Adam Young\nCc: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\n\n\nOn 04/12/2013 17:28, Tiwari, Arvind wrote:\n> Hi David,\n> \n> Thanks for your valuable comments.\n> \n> I have updated\n> https://etherpad.openstack.org/p/service-scoped-role-definition line\n> #118 explaining the rationale behind the field.\n\n#119 for my reply\n\n> \n> I wd also appreciate your thoughts on\n> https://etherpad.openstack.org/p/1Uiwcbfpxq too,\n\nI have added a comment to the original bug report -\nhttps://bugs.launchpad.net/keystone/+bug/968696\n\nI think you should be going for simplifying Keystone\'s RBAC model rather\nthan making it more complex. In essence this would mean that assigning\npermissions to roles and users to roles are separate and independent\nprocesses and that roles on creation do not have to have any baggage or\nrestrictions tied to them. Here are my suggestions:\n\n1. Allow different entities to create roles, and use hierarchical role\nnaming to maintain global uniqueness and to show which entity created\n(owns) the role definition. Creating a role does not imply anything\nabout a role\'s subsequent permissions unless a scope field is included\nin the definition.\n\n2. When a role is created allow the creator to optionally add a scope\nfield which will limit the permissions that can be assigned to the role\nto the prescribed scope.\n\n3. Permissions will be assigned to roles in policy files by resource\nowners. The can assign any permissions to their resources to the role\nthat they want to, except that they cannot override the scope field (ie.\ngrant permissions to resources which are out of the role\'s scope).\n\n4. Remove any linkage of roles to tenants/projects on creation. This is\nunnecessary baggage and only complicates the model for no good\nfunctional reason.\n\nregards\n\nDavid\n\n\n which is support\n> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens\n> BP.\n> \n> \n> Thanks, Arvind\n> \n> -----Original Message----- From: David Chadwick\n> [mailto:d.w.chadwick at kent.ac.uk] Sent: Wednesday, December 04, 2013\n> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not\n> for usage questions); Adam Young Subject: Re: [openstack-dev]\n> [keystone] Service scoped role definition\n> \n> I have added comments 111 to 122\n> \n> david\n> \n> On 03/12/2013 23:58, Tiwari, Arvind wrote:\n>> Hi David,\n>> \n>> I have added my comments underneath line # 97 till line #110, it is\n>> mostly aligned with your proposal with some modification.\n>> \n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>> \n>> \n>> Thanks for your time, Arvind\n>> \n>> \n>> \n>> -----Original Message----- From: Tiwari, Arvind Sent: Monday,\n>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development\n>> Mailing List (not for usage questions); David Chadwick Subject: Re:\n>> [openstack-dev] [keystone] Service scoped role definition\n>> \n>> Hi Adam and David,\n>> \n>> Thank you so much for all the great comments, seems we are making\n>> good progress.\n>> \n>> I have replied to your comments and also added some to support my\n>> proposal\n>> \n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>> \n>> David, I like your suggestion for role-def scoping which can fit in\n>> my Plan B and I think Adam is cool with plan B.\n>> \n>> Please let me know if David\'s proposal for role-def scoping is cool\n>> for everybody?\n>> \n>> \n>> Thanks, Arvind\n>> \n>> -----Original Message----- From: Adam Young\n>> [mailto:ayoung at redhat.com] Sent: Wednesday, November 27, 2013 8:44\n>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for\n>> usage questions) Cc: Henry Nash; dolph.mathews at gmail.com; David\n>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped\n>> role definition\n>> \n>> \n>> \n>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>> Hi Adam,\n>>> \n>>> Based on our discussion over IRC, I have updated the below\n>>> etherpad with proposal for nested role definition\n>> \n>> Updated.  I made my changes Green.  It isn\'t easy being green.\n>> \n>>> \n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>> \n>>> Please take a look @ \"Proposal (Ayoung) - Nested role\n>>> definitions\", I am sorry if I could not catch your idea.\n>>> \n>>> Feel free to update the etherpad.\n>>> \n>>> Regards, Arvind\n>>> \n>>> \n>>> -----Original Message----- From: Tiwari, Arvind Sent: Tuesday,\n>>> November 26, 2013 4:08 PM To: David Chadwick; OpenStack\n>>> Development Mailing List Subject: Re: [openstack-dev] [keystone]\n>>> Service scoped role definition\n>>> \n>>> Hi David,\n>>> \n>>> Thanks for your time and valuable comments. I have replied to\n>>> your comments and try to explain why I am advocating to this BP.\n>>> \n>>> Let me know your thoughts, please feel free to update below\n>>> etherpad \n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>> \n>>> Thanks again, Arvind\n>>> \n>>> -----Original Message----- From: David Chadwick\n>>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Monday, November 25, 2013\n>>> 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List \n>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee,\n>>> Guang Subject: Re: [openstack-dev] [keystone] Service scoped role\n>>> definition\n>>> \n>>> Hi Arvind\n>>> \n>>> I have just added some comments to your blueprint page\n>>> \n>>> regards\n>>> \n>>> David\n>>> \n>>> \n>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>> Hi,\n>>>> \n>>>> \n>>>> \n>>>> Based on our discussion in design summit , I have redone the\n>>>> service_id binding with roles BP \n>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>>\n>>>> \nI have added a new BP (link below) along with detailed use case to\n>>>> support this BP.\n>>>> \n>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>\n>>>>\n>>>> \nBelow etherpad link has some proposals for Role REST representation and\n>>>> pros and cons analysis\n>>>> \n>>>> \n>>>> \n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>>\n>>>> \n>>>> \n>>>> Please take look and let me know your thoughts.\n>>>> \n>>>> \n>>>> \n>>>> It would be awesome if we can discuss it in tomorrow\'s\n>>>> meeting.\n>>>> \n>>>> \n>>>> \n>>>> Thanks,\n>>>> \n>>>> Arvind\n>>>> \n>>> _______________________________________________ OpenStack-dev\n>>> mailing list OpenStack-dev at lists.openstack.org \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>> \n_______________________________________________\n>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n\n\n','<529F778D.5050004@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052FA806@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 16:21:21',0,'2013-12-05 16:21:21',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nLet me capture these details in ether pad. I will drop an email after adding these details in etherpad.\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Thursday, December 05, 2013 4:15 AM\nTo: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Arvind\n\nwe are making good progress, but what I dont like about your proposal\nbelow is that the role name is not unique. There can be multiple roles\nwith the same name, but different IDs, and different scopes. I dont like\nthis, and I think it would be confusing to users/administrators. I think\nthe role names should be different as well. This is not difficult to\nengineer if the names are hierarchically structured based on the name of\nthe role creator. The creator might be owner of the resource that is\nbeing scoped, but it need not necessarily be. Assuming it was, then in\nyour examples below we might have role names of NovaEast.admin and\nNovaWest.admin. Since these are strings, policies can be easily adapted\nto match on NovaWest.admin instead of admin.\n\nregards\n\ndavid\n\nOn 04/12/2013 17:21, Tiwari, Arvind wrote:\n> Hi Adam,\n> \n> I have added my comments in line. \n> \n> As per my request yesterday and David\'s proposal, following role-def data model is looks generic enough and seems innovative to accommodate future extensions.\n> \n> {\n>   \"role\": {\n>     \"id\": \"76e72a\",\n>     \"name\": \"admin\", (you can give whatever name you like)\n>     \"scope\": {\n>       \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource in type and must be immutable value)\n>       \"type\": \"service | file | domain etc.\", (Type can be any type of resource which explains the scoping context)\n>       \"interface\":\"--interface--\"  (We are still need working on this field. My idea of this optional field is to indicate the interface of the resource (endpoint for service, path for File,....) for which the role-def is 						created and can be empty.)\n>     }\n>   }\n> }\n> \n> Based on above data model two admin roles for nova for two separate region wd be as below\n> \n> {\n>   \"role\": {\n>     \"id\": \"76e71a\",\n>     \"name\": \"admin\",\n>     \"scope\": {\n>       \"id\": \"110\", (suppose 110 is Nova serviceId)\n>       \"interface\": \"1101\", (suppose 1101 is Nova region East endpointId)\n>       \"type\": \"service\"\n>     }\n>   }\n> }\n> \n> {\n>   \"role\": {\n>     \"id\": \"76e72a\",\n>     \"name\": \"admin\",\n>     \"scope\": {\n>       \"id\": \"110\", \n>       \"interface\": \"1102\",(suppose 1102 is Nova region West endpointId)\n>       \"type\": \"service\"\n>     }\n>   }\n> }\n> \n> This way we can keep role-assignments abstracted from resource on which the assignment is created. This also open doors to have service and/or endpoint scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq.\n> \n> David, I have updated https://etherpad.openstack.org/p/service-scoped-role-definition line #118 explaining the rationale behind the field.\n> I wd also appreciate your vision on https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n> \n> \n> Thanks,\n> Arvind\n> \n> -----Original Message-----\n> From: Adam Young [mailto:ayoung at redhat.com] \n> Sent: Tuesday, December 03, 2013 6:52 PM\n> To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\n> Cc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> I\'ve been thinking about your comment that \"nested roles are confusing\"\n> AT: Thanks for considering my comment about nested role-def.\n> \n> What if we backed off and said the following:\n> \n> \n> \"Some role-definitions are owned by services.  If a Role definition is \n> owned by a service, in role assignment lists in tokens, those roles we \n> be prefixd by the service name.  / is a reserved cahracter and weill be \n> used as the divider between segments of the role definition \"\n> \n> That drops arbitrary nesting, and provides a reasonable namespace.  Then \n> a role def would look like:\n> \n> \"glance/admin\"  for the admin role on the glance project.\n> \n> AT: It seems this approach is not going to help, service rename would impact all the role-def for a particular service. And we are back to the same problem.\n> \n> In theory, we could add the domain to the namespace, but that seems \n> unwieldy.  If we did, a role def would then look like this\n> \n> \n> \"default/glance/admin\"  for the admin role on the glance project.\n> \n> Is that clearer than the nested roles?\n> AT: It is defiantly clearer but it will create same problems as what we are trying to fix. \n> \n> \n> \n> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>> Hi Adam,\n>>\n>> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n>>\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>>\n>> Feel free to update the etherpad.\n>>\n>> Regards,\n>> Arvind\n>>\n>>\n>> -----Original Message-----\n>> From: Tiwari, Arvind\n>> Sent: Tuesday, November 26, 2013 4:08 PM\n>> To: David Chadwick; OpenStack Development Mailing List\n>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>\n>> Hi David,\n>>\n>> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>>\n>> Let me know your thoughts, please feel free to update below etherpad\n>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>\n>> Thanks again,\n>> Arvind\n>>\n>> -----Original Message-----\n>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>> Sent: Monday, November 25, 2013 12:12 PM\n>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>\n>> Hi Arvind\n>>\n>> I have just added some comments to your blueprint page\n>>\n>> regards\n>>\n>> David\n>>\n>>\n>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>> Hi,\n>>>\n>>>   \n>>>\n>>> Based on our discussion in design summit , I have redone the service_id\n>>> binding with roles BP\n>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>> I have added a new BP (link below) along with detailed use case to\n>>> support this BP.\n>>>\n>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>\n>>> Below etherpad link has some proposals for Role REST representation and\n>>> pros and cons analysis\n>>>\n>>>   \n>>>\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>>   \n>>>\n>>> Please take look and let me know your thoughts.\n>>>\n>>>   \n>>>\n>>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>\n>>>   \n>>>\n>>> Thanks,\n>>>\n>>> Arvind\n>>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52A0602B.2080004@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39052FCB4F@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 18:20:43',0,'2013-12-05 18:20:43',NULL,'[openstack-dev] [keystone] Service scoped role definition','All,\n\nI have captured almost all the email conversation (between Arvind, David and Adam) in the etherpad (line #54 - 126 ) and moved old conversation under line #130.\n\nhttps://etherpad.openstack.org/p/service-scoped-role-definition\n\n\nIn the beginning (line # 1 to 51), I have captured where we are right now and open questions along with my thoughts.\n\nPlease take a look and share your comments/suggestion.\n\nRegards,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Thursday, December 05, 2013 5:45 AM\nTo: Tiwari, Arvind; Adam Young\nCc: OpenStack Development Mailing List (not for usage questions); dolph.mathews at gmail.com\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nAlmost, but not quite. The role name cannot be anything you like. It\nmust be globally unique, and named hierarchically. There is a proposal\nin another message of this thread for what this could be, based on a 4\ncomponent naming scheme with / separators.\n\nregards\ndavid\n\nOn 04/12/2013 19:42, Tiwari, Arvind wrote:\n> Thanks David,\n> \n> Appended line # 119 with my reply. \"endpoint\" sounds perfect to me.\n> \n> In a nutshell we are agreeing on following new data model for role-def. \n> \n> {\n>   \"role\": {\n>     \"id\": \"76e72a\",\n>     \"name\": \"admin\", (you can give whatever name you like)\n>     \"scope\": {\n>       \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource in type and must be immutable value)\n>       \"type\": \"service | file | domain etc.\", (Type can be any type of resource which explains the scoping context)\n>       \"endpoint\":\"-- endpoint--\"  (An optional field to indicate the interface of the resource (endpoint for service, path for File,....) for which the role-def is created.)\n>     }\n>   }\n> }\n> \n> If other community members are cool with this, I will start drafting the API specs?\n> \n> \n> Regards,\n> Arvind\n> \n> \n> -----Original Message-----\n> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \n> Sent: Wednesday, December 04, 2013 11:42 AM\n> To: Tiwari, Arvind; Adam Young\n> Cc: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> \n> \n> On 04/12/2013 17:28, Tiwari, Arvind wrote:\n>> Hi David,\n>>\n>> Thanks for your valuable comments.\n>>\n>> I have updated\n>> https://etherpad.openstack.org/p/service-scoped-role-definition line\n>> #118 explaining the rationale behind the field.\n> \n> #119 for my reply\n> \n>>\n>> I wd also appreciate your thoughts on\n>> https://etherpad.openstack.org/p/1Uiwcbfpxq too,\n> \n> I have added a comment to the original bug report -\n> https://bugs.launchpad.net/keystone/+bug/968696\n> \n> I think you should be going for simplifying Keystone\'s RBAC model rather\n> than making it more complex. In essence this would mean that assigning\n> permissions to roles and users to roles are separate and independent\n> processes and that roles on creation do not have to have any baggage or\n> restrictions tied to them. Here are my suggestions:\n> \n> 1. Allow different entities to create roles, and use hierarchical role\n> naming to maintain global uniqueness and to show which entity created\n> (owns) the role definition. Creating a role does not imply anything\n> about a role\'s subsequent permissions unless a scope field is included\n> in the definition.\n> \n> 2. When a role is created allow the creator to optionally add a scope\n> field which will limit the permissions that can be assigned to the role\n> to the prescribed scope.\n> \n> 3. Permissions will be assigned to roles in policy files by resource\n> owners. The can assign any permissions to their resources to the role\n> that they want to, except that they cannot override the scope field (ie.\n> grant permissions to resources which are out of the role\'s scope).\n> \n> 4. Remove any linkage of roles to tenants/projects on creation. This is\n> unnecessary baggage and only complicates the model for no good\n> functional reason.\n> \n> regards\n> \n> David\n> \n> \n>  which is support\n>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens\n>> BP.\n>>\n>>\n>> Thanks, Arvind\n>>\n>> -----Original Message----- From: David Chadwick\n>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Wednesday, December 04, 2013\n>> 2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not\n>> for usage questions); Adam Young Subject: Re: [openstack-dev]\n>> [keystone] Service scoped role definition\n>>\n>> I have added comments 111 to 122\n>>\n>> david\n>>\n>> On 03/12/2013 23:58, Tiwari, Arvind wrote:\n>>> Hi David,\n>>>\n>>> I have added my comments underneath line # 97 till line #110, it is\n>>> mostly aligned with your proposal with some modification.\n>>>\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>>\n>>> Thanks for your time, Arvind\n>>>\n>>>\n>>>\n>>> -----Original Message----- From: Tiwari, Arvind Sent: Monday,\n>>> December 02, 2013 4:22 PM To: Adam Young; OpenStack Development\n>>> Mailing List (not for usage questions); David Chadwick Subject: Re:\n>>> [openstack-dev] [keystone] Service scoped role definition\n>>>\n>>> Hi Adam and David,\n>>>\n>>> Thank you so much for all the great comments, seems we are making\n>>> good progress.\n>>>\n>>> I have replied to your comments and also added some to support my\n>>> proposal\n>>>\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>> David, I like your suggestion for role-def scoping which can fit in\n>>> my Plan B and I think Adam is cool with plan B.\n>>>\n>>> Please let me know if David\'s proposal for role-def scoping is cool\n>>> for everybody?\n>>>\n>>>\n>>> Thanks, Arvind\n>>>\n>>> -----Original Message----- From: Adam Young\n>>> [mailto:ayoung at redhat.com] Sent: Wednesday, November 27, 2013 8:44\n>>> AM To: Tiwari, Arvind; OpenStack Development Mailing List (not for\n>>> usage questions) Cc: Henry Nash; dolph.mathews at gmail.com; David\n>>> Chadwick Subject: Re: [openstack-dev] [keystone] Service scoped\n>>> role definition\n>>>\n>>>\n>>>\n>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>>> Hi Adam,\n>>>>\n>>>> Based on our discussion over IRC, I have updated the below\n>>>> etherpad with proposal for nested role definition\n>>>\n>>> Updated.  I made my changes Green.  It isn\'t easy being green.\n>>>\n>>>>\n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>> Please take a look @ \"Proposal (Ayoung) - Nested role\n>>>> definitions\", I am sorry if I could not catch your idea.\n>>>>\n>>>> Feel free to update the etherpad.\n>>>>\n>>>> Regards, Arvind\n>>>>\n>>>>\n>>>> -----Original Message----- From: Tiwari, Arvind Sent: Tuesday,\n>>>> November 26, 2013 4:08 PM To: David Chadwick; OpenStack\n>>>> Development Mailing List Subject: Re: [openstack-dev] [keystone]\n>>>> Service scoped role definition\n>>>>\n>>>> Hi David,\n>>>>\n>>>> Thanks for your time and valuable comments. I have replied to\n>>>> your comments and try to explain why I am advocating to this BP.\n>>>>\n>>>> Let me know your thoughts, please feel free to update below\n>>>> etherpad \n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>> Thanks again, Arvind\n>>>>\n>>>> -----Original Message----- From: David Chadwick\n>>>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Monday, November 25, 2013\n>>>> 12:12 PM To: Tiwari, Arvind; OpenStack Development Mailing List \n>>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee,\n>>>> Guang Subject: Re: [openstack-dev] [keystone] Service scoped role\n>>>> definition\n>>>>\n>>>> Hi Arvind\n>>>>\n>>>> I have just added some comments to your blueprint page\n>>>>\n>>>> regards\n>>>>\n>>>> David\n>>>>\n>>>>\n>>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>>> Hi,\n>>>>>\n>>>>>\n>>>>>\n>>>>> Based on our discussion in design summit , I have redone the\n>>>>> service_id binding with roles BP \n>>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>>>\n>>>>>\n> I have added a new BP (link below) along with detailed use case to\n>>>>> support this BP.\n>>>>>\n>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>>\n>>>>>\n>>>>>\n> Below etherpad link has some proposals for Role REST representation and\n>>>>> pros and cons analysis\n>>>>>\n>>>>>\n>>>>>\n>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>> Please take look and let me know your thoughts.\n>>>>>\n>>>>>\n>>>>>\n>>>>> It would be awesome if we can discuss it in tomorrow\'s\n>>>>> meeting.\n>>>>>\n>>>>>\n>>>>>\n>>>>> Thanks,\n>>>>>\n>>>>> Arvind\n>>>>>\n>>>> _______________________________________________ OpenStack-dev\n>>>> mailing list OpenStack-dev at lists.openstack.org \n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>>\n>>>>\n> _______________________________________________\n>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n\n\n','<52A07564.70207@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390530F021@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 15:54:19',0,'2013-12-09 15:54:19',NULL,'[openstack-dev] [keystone] Service scoped role definition','Thanks David,\n\nLet me update the etherpad with this proposal.\n\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Friday, December 06, 2013 2:44 AM\nTo: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nAnother alternative is to change role name into role display name,\nindicating that the string is only to be used in GUIs, is not guaranteed\nto be unique, is set by the role creator, can be any string in any\ncharacter set, and is not used by the system anywhere. Only role ID is\nused by the system, in policy evaluation, in user-role assignments, in\npermission-role assignments etc.\n\nregards\n\nDavid\n\nOn 05/12/2013 16:21, Tiwari, Arvind wrote:\n> Hi David,\n> \n> Let me capture these details in ether pad. I will drop an email after adding these details in etherpad.\n> \n> Thanks,\n> Arvind\n> \n> -----Original Message-----\n> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \n> Sent: Thursday, December 05, 2013 4:15 AM\n> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)\n> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> Hi Arvind\n> \n> we are making good progress, but what I dont like about your proposal\n> below is that the role name is not unique. There can be multiple roles\n> with the same name, but different IDs, and different scopes. I dont like\n> this, and I think it would be confusing to users/administrators. I think\n> the role names should be different as well. This is not difficult to\n> engineer if the names are hierarchically structured based on the name of\n> the role creator. The creator might be owner of the resource that is\n> being scoped, but it need not necessarily be. Assuming it was, then in\n> your examples below we might have role names of NovaEast.admin and\n> NovaWest.admin. Since these are strings, policies can be easily adapted\n> to match on NovaWest.admin instead of admin.\n> \n> regards\n> \n> david\n> \n> On 04/12/2013 17:21, Tiwari, Arvind wrote:\n>> Hi Adam,\n>>\n>> I have added my comments in line. \n>>\n>> As per my request yesterday and David\'s proposal, following role-def data model is looks generic enough and seems innovative to accommodate future extensions.\n>>\n>> {\n>>   \"role\": {\n>>     \"id\": \"76e72a\",\n>>     \"name\": \"admin\", (you can give whatever name you like)\n>>     \"scope\": {\n>>       \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource in type and must be immutable value)\n>>       \"type\": \"service | file | domain etc.\", (Type can be any type of resource which explains the scoping context)\n>>       \"interface\":\"--interface--\"  (We are still need working on this field. My idea of this optional field is to indicate the interface of the resource (endpoint for service, path for File,....) for which the role-def is 						created and can be empty.)\n>>     }\n>>   }\n>> }\n>>\n>> Based on above data model two admin roles for nova for two separate region wd be as below\n>>\n>> {\n>>   \"role\": {\n>>     \"id\": \"76e71a\",\n>>     \"name\": \"admin\",\n>>     \"scope\": {\n>>       \"id\": \"110\", (suppose 110 is Nova serviceId)\n>>       \"interface\": \"1101\", (suppose 1101 is Nova region East endpointId)\n>>       \"type\": \"service\"\n>>     }\n>>   }\n>> }\n>>\n>> {\n>>   \"role\": {\n>>     \"id\": \"76e72a\",\n>>     \"name\": \"admin\",\n>>     \"scope\": {\n>>       \"id\": \"110\", \n>>       \"interface\": \"1102\",(suppose 1102 is Nova region West endpointId)\n>>       \"type\": \"service\"\n>>     }\n>>   }\n>> }\n>>\n>> This way we can keep role-assignments abstracted from resource on which the assignment is created. This also open doors to have service and/or endpoint scoped token as I mentioned in https://etherpad.openstack.org/p/1Uiwcbfpxq.\n>>\n>> David, I have updated https://etherpad.openstack.org/p/service-scoped-role-definition line #118 explaining the rationale behind the field.\n>> I wd also appreciate your vision on https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n>>\n>>\n>> Thanks,\n>> Arvind\n>>\n>> -----Original Message-----\n>> From: Adam Young [mailto:ayoung at redhat.com] \n>> Sent: Tuesday, December 03, 2013 6:52 PM\n>> To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\n>> Cc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\n>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>\n>> I\'ve been thinking about your comment that \"nested roles are confusing\"\n>> AT: Thanks for considering my comment about nested role-def.\n>>\n>> What if we backed off and said the following:\n>>\n>>\n>> \"Some role-definitions are owned by services.  If a Role definition is \n>> owned by a service, in role assignment lists in tokens, those roles we \n>> be prefixd by the service name.  / is a reserved cahracter and weill be \n>> used as the divider between segments of the role definition \"\n>>\n>> That drops arbitrary nesting, and provides a reasonable namespace.  Then \n>> a role def would look like:\n>>\n>> \"glance/admin\"  for the admin role on the glance project.\n>>\n>> AT: It seems this approach is not going to help, service rename would impact all the role-def for a particular service. And we are back to the same problem.\n>>\n>> In theory, we could add the domain to the namespace, but that seems \n>> unwieldy.  If we did, a role def would then look like this\n>>\n>>\n>> \"default/glance/admin\"  for the admin role on the glance project.\n>>\n>> Is that clearer than the nested roles?\n>> AT: It is defiantly clearer but it will create same problems as what we are trying to fix. \n>>\n>>\n>>\n>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>> Hi Adam,\n>>>\n>>> Based on our discussion over IRC, I have updated the below etherpad with proposal for nested role definition\n>>>\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\", I am sorry if I could not catch your idea.\n>>>\n>>> Feel free to update the etherpad.\n>>>\n>>> Regards,\n>>> Arvind\n>>>\n>>>\n>>> -----Original Message-----\n>>> From: Tiwari, Arvind\n>>> Sent: Tuesday, November 26, 2013 4:08 PM\n>>> To: David Chadwick; OpenStack Development Mailing List\n>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>\n>>> Hi David,\n>>>\n>>> Thanks for your time and valuable comments. I have replied to your comments and try to explain why I am advocating to this BP.\n>>>\n>>> Let me know your thoughts, please feel free to update below etherpad\n>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>\n>>> Thanks again,\n>>> Arvind\n>>>\n>>> -----Original Message-----\n>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>> Sent: Monday, November 25, 2013 12:12 PM\n>>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>\n>>> Hi Arvind\n>>>\n>>> I have just added some comments to your blueprint page\n>>>\n>>> regards\n>>>\n>>> David\n>>>\n>>>\n>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>> Hi,\n>>>>\n>>>>   \n>>>>\n>>>> Based on our discussion in design summit , I have redone the service_id\n>>>> binding with roles BP\n>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>> I have added a new BP (link below) along with detailed use case to\n>>>> support this BP.\n>>>>\n>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>\n>>>> Below etherpad link has some proposals for Role REST representation and\n>>>> pros and cons analysis\n>>>>\n>>>>   \n>>>>\n>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>\n>>>>   \n>>>>\n>>>> Please take look and let me know your thoughts.\n>>>>\n>>>>   \n>>>>\n>>>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>>\n>>>>   \n>>>>\n>>>> Thanks,\n>>>>\n>>>> Arvind\n>>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n\n\n','<52A19C72.3030603@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905310663@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 20:36:46',0,'2013-12-09 20:36:46',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nI have updated the ether pad with below comments.\n\nRegards, \nArvind\n\n\n\n\"Another alternative is to change role name into role display name, indicating that the string is only to be used in GUIs, is not guaranteed to be unique, is set by the role creator, can be any string in any character set, and is not used by the system anywhere (AT1). Only role ID is used by the system, in policy evaluation, in user-role assignments, in permission-role assignments etc. (AT2)\"\n\nAT1 - \n1.	Display name proposal does not seems to work because, we cannot enforce service (e.g. Nova, Swift) to use role_id to define their policy.\nAT2 - \n1.	Using role_id for policy evaluation is doable but it will be an enormous impact on token data structure, policy etc...., which won\'t be acceptable to community.\n2.	permission-role assignments goes with policy file which is  again not acceptable due to same reason as #1.\n3.	user-role (or group-role) assignments uses the role_id, so there won\'t be any change.\n\nI think we should consider composite key to make the role  entity unique and keep having duplicate role_names in system. Something as below\n\n{\n  \"role\": {\n    \"id\": \"76e72a\",\n    \"name\": \"---role_name---\",     (resource name spaced name e.g. nova.east.admin)\n\"scope\": {\n      \"id\": \"---id---\", (resource_id)\n      \"type\": \"service | file | domain etc.\",\n      \"endpoint\":\"---endpoint---\" \n    }\n \"domain_id\" = \"--id--\",	(optional)\n \"project_id\" = \"--id--\"	(optional)\n  }\n}\nFields name, scope.id, domain_id and project_id makes the composite key.\n\n\n\n-----Original Message-----\nFrom: Adam Young [mailto:ayoung at redhat.com] \nSent: Monday, December 09, 2013 1:28 PM\nTo: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nOn 12/09/2013 03:04 PM, David Chadwick wrote:\n>\n> On 09/12/2013 19:37, Adam Young wrote:\n>> On 12/06/2013 04:44 AM, David Chadwick wrote:\n>>> Another alternative is to change role name into role display name,\n>>> indicating that the string is only to be used in GUIs, is not guaranteed\n>>> to be unique, is set by the role creator, can be any string in any\n>>> character set, and is not used by the system anywhere. Only role ID is\n>>> used by the system, in policy evaluation, in user-role assignments, in\n>>> permission-role assignments etc.\n>> That will make policy much harder to read.  I\'d recommend that the role\n>> name continue to be the \"good\" name, for both UI and for policy\n>> enforcement.\n> in which case all role names must be unique\n>\n> David\n\nHat is my understanding, yes, and I think that your proposal covers \nthat.  A role name for policy will be the full name, for example \n\"domain/project/role\" in the 3 portion version you posted.\n\n>\n>>\n>>\n>>\n>>> regards\n>>>\n>>> David\n>>>\n>>> On 05/12/2013 16:21, Tiwari, Arvind wrote:\n>>>> Hi David,\n>>>>\n>>>> Let me capture these details in ether pad. I will drop an email after\n>>>> adding these details in etherpad.\n>>>>\n>>>> Thanks,\n>>>> Arvind\n>>>>\n>>>> -----Original Message-----\n>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>>> Sent: Thursday, December 05, 2013 4:15 AM\n>>>> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List\n>>>> (not for usage questions)\n>>>> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\n>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>\n>>>> Hi Arvind\n>>>>\n>>>> we are making good progress, but what I dont like about your proposal\n>>>> below is that the role name is not unique. There can be multiple roles\n>>>> with the same name, but different IDs, and different scopes. I dont like\n>>>> this, and I think it would be confusing to users/administrators. I think\n>>>> the role names should be different as well. This is not difficult to\n>>>> engineer if the names are hierarchically structured based on the name of\n>>>> the role creator. The creator might be owner of the resource that is\n>>>> being scoped, but it need not necessarily be. Assuming it was, then in\n>>>> your examples below we might have role names of NovaEast.admin and\n>>>> NovaWest.admin. Since these are strings, policies can be easily adapted\n>>>> to match on NovaWest.admin instead of admin.\n>>>>\n>>>> regards\n>>>>\n>>>> david\n>>>>\n>>>> On 04/12/2013 17:21, Tiwari, Arvind wrote:\n>>>>> Hi Adam,\n>>>>>\n>>>>> I have added my comments in line.\n>>>>>\n>>>>> As per my request yesterday and David\'s proposal, following role-def\n>>>>> data model is looks generic enough and seems innovative to\n>>>>> accommodate future extensions.\n>>>>>\n>>>>> {\n>>>>>     \"role\": {\n>>>>>       \"id\": \"76e72a\",\n>>>>>       \"name\": \"admin\", (you can give whatever name you like)\n>>>>>       \"scope\": {\n>>>>>         \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource\n>>>>> in type and must be immutable value)\n>>>>>         \"type\": \"service | file | domain etc.\", (Type can be any type\n>>>>> of resource which explains the scoping context)\n>>>>>         \"interface\":\"--interface--\"  (We are still need working on\n>>>>> this field. My idea of this optional field is to indicate the\n>>>>> interface of the resource (endpoint for service, path for File,....)\n>>>>> for which the role-def is                         created and can be\n>>>>> empty.)\n>>>>>       }\n>>>>>     }\n>>>>> }\n>>>>>\n>>>>> Based on above data model two admin roles for nova for two separate\n>>>>> region wd be as below\n>>>>>\n>>>>> {\n>>>>>     \"role\": {\n>>>>>       \"id\": \"76e71a\",\n>>>>>       \"name\": \"admin\",\n>>>>>       \"scope\": {\n>>>>>         \"id\": \"110\", (suppose 110 is Nova serviceId)\n>>>>>         \"interface\": \"1101\", (suppose 1101 is Nova region East\n>>>>> endpointId)\n>>>>>         \"type\": \"service\"\n>>>>>       }\n>>>>>     }\n>>>>> }\n>>>>>\n>>>>> {\n>>>>>     \"role\": {\n>>>>>       \"id\": \"76e72a\",\n>>>>>       \"name\": \"admin\",\n>>>>>       \"scope\": {\n>>>>>         \"id\": \"110\",\n>>>>>         \"interface\": \"1102\",(suppose 1102 is Nova region West\n>>>>> endpointId)\n>>>>>         \"type\": \"service\"\n>>>>>       }\n>>>>>     }\n>>>>> }\n>>>>>\n>>>>> This way we can keep role-assignments abstracted from resource on\n>>>>> which the assignment is created. This also open doors to have\n>>>>> service and/or endpoint scoped token as I mentioned in\n>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq.\n>>>>>\n>>>>> David, I have updated\n>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition line\n>>>>> #118 explaining the rationale behind the field.\n>>>>> I wd also appreciate your vision on\n>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support\n>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n>>>>>\n>>>>>\n>>>>>\n>>>>> Thanks,\n>>>>> Arvind\n>>>>>\n>>>>> -----Original Message-----\n>>>>> From: Adam Young [mailto:ayoung at redhat.com]\n>>>>> Sent: Tuesday, December 03, 2013 6:52 PM\n>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List (not for\n>>>>> usage questions)\n>>>>> Cc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\n>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>\n>>>>> I\'ve been thinking about your comment that \"nested roles are confusing\"\n>>>>> AT: Thanks for considering my comment about nested role-def.\n>>>>>\n>>>>> What if we backed off and said the following:\n>>>>>\n>>>>>\n>>>>> \"Some role-definitions are owned by services.  If a Role definition is\n>>>>> owned by a service, in role assignment lists in tokens, those roles we\n>>>>> be prefixd by the service name.  / is a reserved cahracter and weill be\n>>>>> used as the divider between segments of the role definition \"\n>>>>>\n>>>>> That drops arbitrary nesting, and provides a reasonable namespace.\n>>>>> Then\n>>>>> a role def would look like:\n>>>>>\n>>>>> \"glance/admin\"  for the admin role on the glance project.\n>>>>>\n>>>>> AT: It seems this approach is not going to help, service rename\n>>>>> would impact all the role-def for a particular service. And we are\n>>>>> back to the same problem.\n>>>>>\n>>>>> In theory, we could add the domain to the namespace, but that seems\n>>>>> unwieldy.  If we did, a role def would then look like this\n>>>>>\n>>>>>\n>>>>> \"default/glance/admin\"  for the admin role on the glance project.\n>>>>>\n>>>>> Is that clearer than the nested roles?\n>>>>> AT: It is defiantly clearer but it will create same problems as what\n>>>>> we are trying to fix.\n>>>>>\n>>>>>\n>>>>>\n>>>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>>>>> Hi Adam,\n>>>>>>\n>>>>>> Based on our discussion over IRC, I have updated the below etherpad\n>>>>>> with proposal for nested role definition\n>>>>>>\n>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>\n>>>>>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\",\n>>>>>> I am sorry if I could not catch your idea.\n>>>>>>\n>>>>>> Feel free to update the etherpad.\n>>>>>>\n>>>>>> Regards,\n>>>>>> Arvind\n>>>>>>\n>>>>>>\n>>>>>> -----Original Message-----\n>>>>>> From: Tiwari, Arvind\n>>>>>> Sent: Tuesday, November 26, 2013 4:08 PM\n>>>>>> To: David Chadwick; OpenStack Development Mailing List\n>>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>>\n>>>>>> Hi David,\n>>>>>>\n>>>>>> Thanks for your time and valuable comments. I have replied to your\n>>>>>> comments and try to explain why I am advocating to this BP.\n>>>>>>\n>>>>>> Let me know your thoughts, please feel free to update below etherpad\n>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>\n>>>>>> Thanks again,\n>>>>>> Arvind\n>>>>>>\n>>>>>> -----Original Message-----\n>>>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>>>>> Sent: Monday, November 25, 2013 12:12 PM\n>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>>>>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>>\n>>>>>> Hi Arvind\n>>>>>>\n>>>>>> I have just added some comments to your blueprint page\n>>>>>>\n>>>>>> regards\n>>>>>>\n>>>>>> David\n>>>>>>\n>>>>>>\n>>>>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>>>>> Hi,\n>>>>>>>\n>>>>>>>    \n>>>>>>> Based on our discussion in design summit , I have redone the\n>>>>>>> service_id\n>>>>>>> binding with roles BP\n>>>>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>>>>>\n>>>>>>> I have added a new BP (link below) along with detailed use case to\n>>>>>>> support this BP.\n>>>>>>>\n>>>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>>>>\n>>>>>>>\n>>>>>>> Below etherpad link has some proposals for Role REST\n>>>>>>> representation and\n>>>>>>> pros and cons analysis\n>>>>>>>\n>>>>>>>    \n>>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>>\n>>>>>>>    \n>>>>>>> Please take look and let me know your thoughts.\n>>>>>>>\n>>>>>>>    \n>>>>>>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>>>>>\n>>>>>>>    \n>>>>>>> Thanks,\n>>>>>>>\n>>>>>>> Arvind\n>>>>>>>\n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52A627D6.1060705@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39053107EE@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 22:31:17',0,'2013-12-09 22:31:17',NULL,'[openstack-dev] [keystone] Service scoped role definition','I think that make sense, how does below data model looks?\n\n{\n   \"role\": {\n     \"id\": \"76e72a\",\n     \"name\": \"---role_name---\",     (resource name spaced name e.g. nova.east.admin)\n     \"scope\": {\n       \"id\": \"---id---\", (resource_id)\n       \"type\": \"service | file | domain etc.\",\n       \"endpoint\":\"---endpoint---\" \n     }\n  \"domain_id\" = \"--id--\",	(optional)\n  \"project_id\" = \"--id--\",	(optional)\n  \"service_id\" = \"--id--\"	(optional)\n   }\n }\n\nQ. what if two (or more) endpoints want to have same role_name for a service (nova.east.admin, nova.west.admin, nova.north.admin .....)?\n\nRegards,\nArvind\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Monday, December 09, 2013 3:15 PM\nTo: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Arvind\n\nthis is still mixing up two separate concepts: naming and policy\nconstraints. Scope is a policy constraint but in the proposal below is\nalso part of the unique naming of the role. The fields making up both\nconcepts need to be separate (e.g. what if 2 different roles from the\nsame domain and project applied to two different scopes but it just so\nhappened that the ids of the two resources were the same? They would end\nup still having the same unique name.)\n\nI would therefore add \"service_id\" = \"--id--\"	(optional)\nafter project_id. This can assure that (composite) role names (keys) are\nunique\n\nregards\n\nDavid\n\n\nOn 09/12/2013 20:36, Tiwari, Arvind wrote:\n> Hi David,\n> \n> I have updated the ether pad with below comments.\n> \n> Regards, \n> Arvind\n> \n> \n> \n> \"Another alternative is to change role name into role display name, indicating that the string is only to be used in GUIs, is not guaranteed to be unique, is set by the role creator, can be any string in any character set, and is not used by the system anywhere (AT1). Only role ID is used by the system, in policy evaluation, in user-role assignments, in permission-role assignments etc. (AT2)\"\n> \n> AT1 - \n> 1.	Display name proposal does not seems to work because, we cannot enforce service (e.g. Nova, Swift) to use role_id to define their policy.\n> AT2 - \n> 1.	Using role_id for policy evaluation is doable but it will be an enormous impact on token data structure, policy etc...., which won\'t be acceptable to community.\n> 2.	permission-role assignments goes with policy file which is  again not acceptable due to same reason as #1.\n> 3.	user-role (or group-role) assignments uses the role_id, so there won\'t be any change.\n> \n> I think we should consider composite key to make the role  entity unique and keep having duplicate role_names in system. Something as below\n> \n> {\n>   \"role\": {\n>     \"id\": \"76e72a\",\n>     \"name\": \"---role_name---\",     (resource name spaced name e.g. nova.east.admin)\n> \"scope\": {\n>       \"id\": \"---id---\", (resource_id)\n>       \"type\": \"service | file | domain etc.\",\n>       \"endpoint\":\"---endpoint---\" \n>     }\n>  \"domain_id\" = \"--id--\",	(optional)\n>  \"project_id\" = \"--id--\"	(optional)\n>   }\n> }\n> Fields name, scope.id, domain_id and project_id makes the composite key.\n> \n> \n> \n> -----Original Message-----\n> From: Adam Young [mailto:ayoung at redhat.com] \n> Sent: Monday, December 09, 2013 1:28 PM\n> To: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\n> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\n> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n> \n> On 12/09/2013 03:04 PM, David Chadwick wrote:\n>>\n>> On 09/12/2013 19:37, Adam Young wrote:\n>>> On 12/06/2013 04:44 AM, David Chadwick wrote:\n>>>> Another alternative is to change role name into role display name,\n>>>> indicating that the string is only to be used in GUIs, is not guaranteed\n>>>> to be unique, is set by the role creator, can be any string in any\n>>>> character set, and is not used by the system anywhere. Only role ID is\n>>>> used by the system, in policy evaluation, in user-role assignments, in\n>>>> permission-role assignments etc.\n>>> That will make policy much harder to read.  I\'d recommend that the role\n>>> name continue to be the \"good\" name, for both UI and for policy\n>>> enforcement.\n>> in which case all role names must be unique\n>>\n>> David\n> \n> Hat is my understanding, yes, and I think that your proposal covers \n> that.  A role name for policy will be the full name, for example \n> \"domain/project/role\" in the 3 portion version you posted.\n> \n>>\n>>>\n>>>\n>>>\n>>>> regards\n>>>>\n>>>> David\n>>>>\n>>>> On 05/12/2013 16:21, Tiwari, Arvind wrote:\n>>>>> Hi David,\n>>>>>\n>>>>> Let me capture these details in ether pad. I will drop an email after\n>>>>> adding these details in etherpad.\n>>>>>\n>>>>> Thanks,\n>>>>> Arvind\n>>>>>\n>>>>> -----Original Message-----\n>>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>>>> Sent: Thursday, December 05, 2013 4:15 AM\n>>>>> To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List\n>>>>> (not for usage questions)\n>>>>> Cc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\n>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>\n>>>>> Hi Arvind\n>>>>>\n>>>>> we are making good progress, but what I dont like about your proposal\n>>>>> below is that the role name is not unique. There can be multiple roles\n>>>>> with the same name, but different IDs, and different scopes. I dont like\n>>>>> this, and I think it would be confusing to users/administrators. I think\n>>>>> the role names should be different as well. This is not difficult to\n>>>>> engineer if the names are hierarchically structured based on the name of\n>>>>> the role creator. The creator might be owner of the resource that is\n>>>>> being scoped, but it need not necessarily be. Assuming it was, then in\n>>>>> your examples below we might have role names of NovaEast.admin and\n>>>>> NovaWest.admin. Since these are strings, policies can be easily adapted\n>>>>> to match on NovaWest.admin instead of admin.\n>>>>>\n>>>>> regards\n>>>>>\n>>>>> david\n>>>>>\n>>>>> On 04/12/2013 17:21, Tiwari, Arvind wrote:\n>>>>>> Hi Adam,\n>>>>>>\n>>>>>> I have added my comments in line.\n>>>>>>\n>>>>>> As per my request yesterday and David\'s proposal, following role-def\n>>>>>> data model is looks generic enough and seems innovative to\n>>>>>> accommodate future extensions.\n>>>>>>\n>>>>>> {\n>>>>>>     \"role\": {\n>>>>>>       \"id\": \"76e72a\",\n>>>>>>       \"name\": \"admin\", (you can give whatever name you like)\n>>>>>>       \"scope\": {\n>>>>>>         \"id\": \"---id--\", (ID should be  1 to 1 mapped with resource\n>>>>>> in type and must be immutable value)\n>>>>>>         \"type\": \"service | file | domain etc.\", (Type can be any type\n>>>>>> of resource which explains the scoping context)\n>>>>>>         \"interface\":\"--interface--\"  (We are still need working on\n>>>>>> this field. My idea of this optional field is to indicate the\n>>>>>> interface of the resource (endpoint for service, path for File,....)\n>>>>>> for which the role-def is                         created and can be\n>>>>>> empty.)\n>>>>>>       }\n>>>>>>     }\n>>>>>> }\n>>>>>>\n>>>>>> Based on above data model two admin roles for nova for two separate\n>>>>>> region wd be as below\n>>>>>>\n>>>>>> {\n>>>>>>     \"role\": {\n>>>>>>       \"id\": \"76e71a\",\n>>>>>>       \"name\": \"admin\",\n>>>>>>       \"scope\": {\n>>>>>>         \"id\": \"110\", (suppose 110 is Nova serviceId)\n>>>>>>         \"interface\": \"1101\", (suppose 1101 is Nova region East\n>>>>>> endpointId)\n>>>>>>         \"type\": \"service\"\n>>>>>>       }\n>>>>>>     }\n>>>>>> }\n>>>>>>\n>>>>>> {\n>>>>>>     \"role\": {\n>>>>>>       \"id\": \"76e72a\",\n>>>>>>       \"name\": \"admin\",\n>>>>>>       \"scope\": {\n>>>>>>         \"id\": \"110\",\n>>>>>>         \"interface\": \"1102\",(suppose 1102 is Nova region West\n>>>>>> endpointId)\n>>>>>>         \"type\": \"service\"\n>>>>>>       }\n>>>>>>     }\n>>>>>> }\n>>>>>>\n>>>>>> This way we can keep role-assignments abstracted from resource on\n>>>>>> which the assignment is created. This also open doors to have\n>>>>>> service and/or endpoint scoped token as I mentioned in\n>>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq.\n>>>>>>\n>>>>>> David, I have updated\n>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition line\n>>>>>> #118 explaining the rationale behind the field.\n>>>>>> I wd also appreciate your vision on\n>>>>>> https://etherpad.openstack.org/p/1Uiwcbfpxq too which is support\n>>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> Thanks,\n>>>>>> Arvind\n>>>>>>\n>>>>>> -----Original Message-----\n>>>>>> From: Adam Young [mailto:ayoung at redhat.com]\n>>>>>> Sent: Tuesday, December 03, 2013 6:52 PM\n>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List (not for\n>>>>>> usage questions)\n>>>>>> Cc: Henry Nash; dolph.mathews at gmail.com; David Chadwick\n>>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>>\n>>>>>> I\'ve been thinking about your comment that \"nested roles are confusing\"\n>>>>>> AT: Thanks for considering my comment about nested role-def.\n>>>>>>\n>>>>>> What if we backed off and said the following:\n>>>>>>\n>>>>>>\n>>>>>> \"Some role-definitions are owned by services.  If a Role definition is\n>>>>>> owned by a service, in role assignment lists in tokens, those roles we\n>>>>>> be prefixd by the service name.  / is a reserved cahracter and weill be\n>>>>>> used as the divider between segments of the role definition \"\n>>>>>>\n>>>>>> That drops arbitrary nesting, and provides a reasonable namespace.\n>>>>>> Then\n>>>>>> a role def would look like:\n>>>>>>\n>>>>>> \"glance/admin\"  for the admin role on the glance project.\n>>>>>>\n>>>>>> AT: It seems this approach is not going to help, service rename\n>>>>>> would impact all the role-def for a particular service. And we are\n>>>>>> back to the same problem.\n>>>>>>\n>>>>>> In theory, we could add the domain to the namespace, but that seems\n>>>>>> unwieldy.  If we did, a role def would then look like this\n>>>>>>\n>>>>>>\n>>>>>> \"default/glance/admin\"  for the admin role on the glance project.\n>>>>>>\n>>>>>> Is that clearer than the nested roles?\n>>>>>> AT: It is defiantly clearer but it will create same problems as what\n>>>>>> we are trying to fix.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:\n>>>>>>> Hi Adam,\n>>>>>>>\n>>>>>>> Based on our discussion over IRC, I have updated the below etherpad\n>>>>>>> with proposal for nested role definition\n>>>>>>>\n>>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>>\n>>>>>>> Please take a look @ \"Proposal (Ayoung) - Nested role definitions\",\n>>>>>>> I am sorry if I could not catch your idea.\n>>>>>>>\n>>>>>>> Feel free to update the etherpad.\n>>>>>>>\n>>>>>>> Regards,\n>>>>>>> Arvind\n>>>>>>>\n>>>>>>>\n>>>>>>> -----Original Message-----\n>>>>>>> From: Tiwari, Arvind\n>>>>>>> Sent: Tuesday, November 26, 2013 4:08 PM\n>>>>>>> To: David Chadwick; OpenStack Development Mailing List\n>>>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>>>\n>>>>>>> Hi David,\n>>>>>>>\n>>>>>>> Thanks for your time and valuable comments. I have replied to your\n>>>>>>> comments and try to explain why I am advocating to this BP.\n>>>>>>>\n>>>>>>> Let me know your thoughts, please feel free to update below etherpad\n>>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>>\n>>>>>>> Thanks again,\n>>>>>>> Arvind\n>>>>>>>\n>>>>>>> -----Original Message-----\n>>>>>>> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]\n>>>>>>> Sent: Monday, November 25, 2013 12:12 PM\n>>>>>>> To: Tiwari, Arvind; OpenStack Development Mailing List\n>>>>>>> Cc: Henry Nash; ayoung at redhat.com; dolph.mathews at gmail.com; Yee, Guang\n>>>>>>> Subject: Re: [openstack-dev] [keystone] Service scoped role definition\n>>>>>>>\n>>>>>>> Hi Arvind\n>>>>>>>\n>>>>>>> I have just added some comments to your blueprint page\n>>>>>>>\n>>>>>>> regards\n>>>>>>>\n>>>>>>> David\n>>>>>>>\n>>>>>>>\n>>>>>>> On 19/11/2013 00:01, Tiwari, Arvind wrote:\n>>>>>>>> Hi,\n>>>>>>>>\n>>>>>>>>    \n>>>>>>>> Based on our discussion in design summit , I have redone the\n>>>>>>>> service_id\n>>>>>>>> binding with roles BP\n>>>>>>>> <https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition>.\n>>>>>>>>\n>>>>>>>> I have added a new BP (link below) along with detailed use case to\n>>>>>>>> support this BP.\n>>>>>>>>\n>>>>>>>> https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> Below etherpad link has some proposals for Role REST\n>>>>>>>> representation and\n>>>>>>>> pros and cons analysis\n>>>>>>>>\n>>>>>>>>    \n>>>>>>>> https://etherpad.openstack.org/p/service-scoped-role-definition\n>>>>>>>>\n>>>>>>>>    \n>>>>>>>> Please take look and let me know your thoughts.\n>>>>>>>>\n>>>>>>>>    \n>>>>>>>> It would be awesome if we can discuss it in tomorrow\'s meeting.\n>>>>>>>>\n>>>>>>>>    \n>>>>>>>> Thanks,\n>>>>>>>>\n>>>>>>>> Arvind\n>>>>>>>>\n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52A640E4.6090403@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905312729@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 16:42:49',0,'2013-12-10 16:42:49',NULL,'[openstack-dev] [keystone] Service scoped role definition','Hi David,\n\nI am cool with the proposal, just wanted to grad you attention on may question which I asked in my last email (which is below)\n\nQ. what if two (or more) endpoints want to have same role_name for a service (nova.east.admin, nova.west.admin, nova.north.admin .....)? \n\n(Can we think of adding an optional endpoint_id attribute in role data model to allow such role, which is also needed to envision endpoint scoped tokens for our use case)\n\n{\n     \"role\": {\n      \"id\": \"76e72a\",\n      \"domain_id\" = \"--id--\",    (optional, if present, role is named by specific domain)\n      \"project_id\" = \"--id--\",    (optional, if present, role is named by project)\n      \"service_id\" = \"--id--\",    (optional, if present, role is named by service)\n      \"endpoint_id\" = \"--id--\",    (optional, if present, role is named by service)\n      \"name\": \"---role_name---\",  (must be unique when combined with domain, project and service ids)\n      \"scope\": {\"id\": \"---id---\", (resource_id)\n         \"type\": \"service | file | domain etc.\",\n         \"endpoint\":\"---endpoint---\"\n       }\n    }\n }\n\nFor Adam\'s question \" We are not linking role names to service id.\" (email attached)\nAT: These attributes are all optional and will not stop anyone how don\'t want to included service_id or (any other attribute) for role name uniqueness. So in particular deployment want to keep just the role name unique, this model will not restrict you.\n\nThoughts? \n\n\n\nThanks,\nArvind\n\n\n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Tuesday, December 10, 2013 1:30 AM\nTo: Adam Young; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHow about the following which clearly separates naming and scoping\nconstraints\n\n {\n     \"role\": {\n      \"id\": \"76e72a\",\n      \"domain_id\" = \"--id--\",    (optional, if present, role is named by specific domain)\n      \"project_id\" = \"--id--\",    (optional, if present, role is named by project)\n      \"service_id\" = \"--id--\",    (optional, if present, role is named by service)\n      \"name\": \"---role_name---\",  (must be unique when combined with domain, project and service ids)\n      \"scope\": {\"id\": \"---id---\", (resource_id)\n         \"type\": \"service | file | domain etc.\",\n         \"endpoint\":\"---endpoint---\"\n       }\n    }\n }\n\nregards\n\nDavid\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Adam Young <ayoung at redhat.com>\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\nDate: Tue, 10 Dec 2013 03:02:58 +0000\nSize: 16632\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/047bf015/attachment.mht>\n\n','<52A6D106.7010302@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905313D58@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 21:55:09',0,'2013-12-10 21:55:09',NULL,'[openstack-dev] [keystone] Service scoped role definition','Yes, it is required to address one of public cloud use case where we want regional service admins and to support https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens BP. \n\nBased on our discussion I am going to start API specs and submit for review.\n\n{\n     \"role\": {\n      \"id\": \"76e72a\",\n      \"domain_id\" = \"--id--\",    (optional, if present, role is named by specific domain)\n      \"project_id\" = \"--id--\",    (optional, if present, role is named by project)\n      \"service_id\" = \"--id--\",    (optional, if present, role is named by service)\n      \"endpoint_id\" = \"--id--\",    (optional, if present, role is named by service)\n      \"name\": \"---role_name---\",  (must be unique when combined with domain, project and service ids)\n      \"scope\": {\"id\": \"---id---\", (resource_id)\n         \"type\": \"service | file | domain etc.\",\n         \"endpoint\":\"---endpoint---\"\n       }\n    }\n }\n\n\nFor Adam\'s Concern, \"You are over designing.  Services and Endpoints have no business in this design.  That is enforcement, not definition or assignment of the Roles.  We need a clean namespace, and mixing services and endpoints in there adds no benefit.\"\nAT: To support following two BPs and these are the basic requirements for public cloud deployment with Keystone otherwise we are locked.  I  am asking for endpoint_id extension in role data model to support endpoint scoped tokens which you mentioned in IRC around a week back. \n\n1. https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\n2. https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.\n\n\nThanks.\nArvind \n\n-----Original Message-----\nFrom: David Chadwick [mailto:d.w.chadwick at kent.ac.uk] \nSent: Tuesday, December 10, 2013 2:27 PM\nTo: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nHi Arvind\n\nthe granularity in naming can be as fine as required i.e. a naming\nhierarchy can be as deep as required. So if there is a requirement for\nindividual endpoints to name their own roles, then the addition of\nendpoint_id to the naming structure is fine.\n\nregards\n\nDavid\n\nOn 10/12/2013 16:42, Tiwari, Arvind wrote:\n> Hi David,\n> \n> I am cool with the proposal, just wanted to grad you attention on may\n> question which I asked in my last email (which is below)\n> \n> Q. what if two (or more) endpoints want to have same role_name for a\n> service (nova.east.admin, nova.west.admin, nova.north.admin .....)?\n> \n> (Can we think of adding an optional endpoint_id attribute in role\n> data model to allow such role, which is also needed to envision\n> endpoint scoped tokens for our use case)\n> \n> { \"role\": { \"id\": \"76e72a\", \"domain_id\" = \"--id--\",    (optional, if\n> present, role is named by specific domain) \"project_id\" = \"--id--\",\n> (optional, if present, role is named by project) \"service_id\" =\n> \"--id--\",    (optional, if present, role is named by service) \n> \"endpoint_id\" = \"--id--\",    (optional, if present, role is named by\n> service) \"name\": \"---role_name---\",  (must be unique when combined\n> with domain, project and service ids) \"scope\": {\"id\": \"---id---\",\n> (resource_id) \"type\": \"service | file | domain etc.\", \n> \"endpoint\":\"---endpoint---\" } } }\n> \n> For Adam\'s question \" We are not linking role names to service id.\"\n> (email attached) AT: These attributes are all optional and will not\n> stop anyone how don\'t want to included service_id or (any other\n> attribute) for role name uniqueness. So in particular deployment want\n> to keep just the role name unique, this model will not restrict you.\n> \n> Thoughts?\n> \n> \n> \n> Thanks, Arvind\n> \n> \n> \n> -----Original Message----- From: David Chadwick\n> [mailto:d.w.chadwick at kent.ac.uk] Sent: Tuesday, December 10, 2013\n> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing\n> List (not for usage questions) Cc: Henry Nash;\n> dolph.mathews at gmail.com; Yee, Guang Subject: Re: [openstack-dev]\n> [keystone] Service scoped role definition\n> \n> How about the following which clearly separates naming and scoping \n> constraints\n> \n> { \"role\": { \"id\": \"76e72a\", \"domain_id\" = \"--id--\",    (optional, if\n> present, role is named by specific domain) \"project_id\" = \"--id--\",\n> (optional, if present, role is named by project) \"service_id\" =\n> \"--id--\",    (optional, if present, role is named by service) \"name\":\n> \"---role_name---\",  (must be unique when combined with domain,\n> project and service ids) \"scope\": {\"id\": \"---id---\", (resource_id) \n> \"type\": \"service | file | domain etc.\", \"endpoint\":\"---endpoint---\" \n> } } }\n> \n> regards\n> \n> David\n> \n\n\n','<52A78721.5040003@kent.ac.uk>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905313E19@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 22:34:12',0,'2013-12-10 22:34:12',NULL,'[openstack-dev] [keystone] Service scoped role definition','My Comments in line.\n\nArvind\n\n-----Original Message-----\nFrom: Adam Young [mailto:ayoung at redhat.com] \nSent: Tuesday, December 10, 2013 2:54 PM\nTo: David Chadwick; Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)\nCc: Henry Nash; dolph.mathews at gmail.com; Yee, Guang\nSubject: Re: [openstack-dev] [keystone] Service scoped role definition\n\nOn 12/10/2013 04:26 PM, David Chadwick wrote:\n> Hi Arvind\n>\n> the granularity in naming can be as fine as required i.e. a naming\n> hierarchy can be as deep as required. So if there is a requirement for\n> individual endpoints to name their own roles, then the addition of\n> endpoint_id to the naming structure is fine.\n>\n> regards\n>\n> David\n>\n> On 10/12/2013 16:42, Tiwari, Arvind wrote:\n>> Hi David,\n>>\n>> I am cool with the proposal, just wanted to grad you attention on may\n>> question which I asked in my last email (which is below)\n>>\n>> Q. what if two (or more) endpoints want to have same role_name for a\n>> service (nova.east.admin, nova.west.admin, nova.north.admin .....)?\n>>\n>> (Can we think of adding an optional endpoint_id attribute in role\n>> data model to allow such role, which is also needed to envision\n>> endpoint scoped tokens for our use case)\n>>\n>> { \"role\": { \"id\": \"76e72a\", \"domain_id\" = \"--id--\",    (optional, if\n>> present, role is named by specific domain) \"project_id\" = \"--id--\",\n>> (optional, if present, role is named by project) \"service_id\" =\n>> \"--id--\",    (optional, if present, role is named by service)\n>> \"endpoint_id\" = \"--id--\",    (optional, if present, role is named by\n>> service) \"name\": \"---role_name---\",  (must be unique when combined\n>> with domain, project and service ids) \"scope\": {\"id\": \"---id---\",\n>> (resource_id) \"type\": \"service | file | domain etc.\",\n>> \"endpoint\":\"---endpoint---\" } } }\n>>\n>> For Adam\'s question \" We are not linking role names to service id.\"\n>> (email attached) AT: These attributes are all optional and will not\n>> stop anyone how don\'t want to included service_id or (any other\n>> attribute) for role name uniqueness. So in particular deployment want\n>> to keep just the role name unique, this model will not restrict you.\n\nUnnecessary.  You are basically putting in documentation about how they \nare to be enforced, which does not belong there.\nJust do the basic:  allow for the role naming to be nested under \nprojects and domains, and use that to support your use case.\nThis discussion is taking up too much time and effort.  Please stop \ntrying to make it more complex than necessary.\n\nAT: We are not putting in documentation but we are trying to come up with generic role data model so that it will support all (private and public cloud) of our role needs as explained in BP and extensible.\nIf you really have a solution for all the problems listed in below BPs, please draft it and present in detail.\nSo far, two high level ideas (nested role-def and name space) proposed by you are not helping which is clear.\n\nhttps://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition\nhttps://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens.\n\nI will appreciate and definitely consider them if they will resolve our problems.\n\n\n  \n\n>>\n>> Thoughts?\n>>\n>>\n>>\n>> Thanks, Arvind\n>>\n>>\n>>\n>> -----Original Message----- From: David Chadwick\n>> [mailto:d.w.chadwick at kent.ac.uk] Sent: Tuesday, December 10, 2013\n>> 1:30 AM To: Adam Young; Tiwari, Arvind; OpenStack Development Mailing\n>> List (not for usage questions) Cc: Henry Nash;\n>> dolph.mathews at gmail.com; Yee, Guang Subject: Re: [openstack-dev]\n>> [keystone] Service scoped role definition\n>>\n>> How about the following which clearly separates naming and scoping\n>> constraints\n>>\n>> { \"role\": { \"id\": \"76e72a\", \"domain_id\" = \"--id--\",    (optional, if\n>> present, role is named by specific domain) \"project_id\" = \"--id--\",\n>> (optional, if present, role is named by project) \"service_id\" =\n>> \"--id--\",    (optional, if present, role is named by service) \"name\":\n>> \"---role_name---\",  (must be unique when combined with domain,\n>> project and service ids) \"scope\": {\"id\": \"---id---\", (resource_id)\n>> \"type\": \"service | file | domain etc.\", \"endpoint\":\"---endpoint---\"\n>> } } }\n>>\n>> regards\n>>\n>> David\n>>\n\n\n\n','<52A78D8A.5030809@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390531C339@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 17:19:06',0,'2013-12-18 17:19:06',NULL,'[openstack-dev] API spec for OS-NS-ROLES extension','Hi Adam,\n\nI would like to request you to revisit the below link and provide your opinion, so that we can move forward and try to find a common ground where everyone.\n\nhttps://review.openstack.org/#/c/61897\n\n\nBelow is my justification for service_id in role model:\nIn a public cloud deployment model, service teams (or service deployers) defines the roles along with other artifacts (service and endpoint) and they need full control on these artifacts including roles. This way they can control the life cycle of these artifacts without depending on IAM service providers. (more details in https://blueprints.launchpad.net/keystone/+spec/name-spaced-roles)\nAs an IAM service provider in a public cloud deployment, it is our responsibility to facilitate them so that they can control full life cycle of their service specific artifacts. To make it happen we need tight access control on these artifacts, so that a service deployer accidently or maliciously not able to mess-up with other services.\nTo achieve that level fine granularity and to isolate service deployers from artifacts, we need to associate entity models (service, endpoints and roles) with a service.  This way we can define entity ownership and define access control policy based on service. Currently, role data model  does not support any association and that is why I am requesting  to introduce some way to associate a role with domain, project and service. This association also helps to define a namespace for making the role name globally unique.\n\nPreviously I was trying achieve tight linking of roles with service_id and that might be offending for some community members. Now after much effort and help from David Chadwick, we have generalized the role model and come up with generic design, so that it can fit in with every once use case. As I mentioned in the spec it will be backward compatible so that it won\'t break the existing deployments\n\nI would appreciate if you can revisit the link and provide comments and suggestions, there might be still some room for improvements and I am open for them.\n\n\nDolph, I would also like you to review the specs, so that we can make some progress.\n\n\nRegards,\nArvind\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/6a0e6198/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390535DD0B@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 16:08:47',0,'2014-01-16 16:08:47',NULL,'[openstack-dev] Domain ID in Policy_dict','\nI think you have to define rule as below\n\n\"domain-admin\": \"role:domain_admin and domain_id:%(target.domain.domain_id)s\"\n\nAssociate this rule with APIS which you want to scope to domain admin.\n\nTry and let us know.\n\nArvind\n\n-----Original Message-----\nFrom: bounces at canonical.com [mailto:bounces at canonical.com] On Behalf Of Telles Mota Vidal N?brega\nSent: Thursday, January 16, 2014 6:30 AM\nTo: Tiwari, Arvind\nSubject: Domain ID in Policy_dict\n\nHi, i\'m working on some new features for openstack and this merge that\nyou submitted https://review.openstack.org/#/c/50488/ does most of what\nI need. I updated the code here but I couldn\'t make it work, my idea is\nto create a role called domain_admin, to check this we would need to\ncheck if the user is admin and is owner of the domain and for that we\nwould need the domain_id t o be checked at the policy.json which by the\nexamples you posted works. Unfortunetly I wasn\'t able to do so, can you\nhelp me out, give me some tips on how to get this working?\n\nThanks\n-- \nThis message was sent from Launchpad by\n=?utf-8?q?Telles_Mota_Vidal_N=C3=B3brega?= (https://launchpad.net/~tellesmvn)\nusing the \"Contact this user\" link on your profile page\n(https://launchpad.net/~arvind-tiwari).\nFor more information see\nhttps://help.launchpad.net/YourAccount/ContactingPeople\n\n\n','<20140116132959.650.29475.launchpad@gac.canonical.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905380DFE@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 19:54:09',0,'2014-02-04 19:54:09',NULL,'[openstack-dev] [keystone][nova] Re: Hierarchicical\n Multitenancy	Discussion','Hi Vish,\n\nI am sorry as I am proposing just a solution approach below but no code so far. \n\n### Problem and Requirement ###\nAs per the problem description it seems to me that \"Martha, the owner of ProductionIT\" is not a cloud provider (correct me if wrong) and she uses someone else cloud infrastructure (like public cloud) to provide services to multiple Enterprise clients.\n\nAfter reading further it seems to me that we want different administrative boundaries and isolation among them, so that \"Joe can manage/mess-up resource for WidgetMaster and Sam for SuperDevShop but not each other\" at the same time \"Martha should be allowed to manage resources from both\".\n\n### Requirements based on my understanding ###\n1. Joe can manage/mess-up resource for WidgetMaster and Sam for SuperDevShop but not each other.\n2. Martha should be able to manage resources from both.\n\n### Solution ### (*This solution is backed-up by production working implementation*)\n\nIn a nutshell, We need ability to setup hierarchicical administrative boundaries within a cloud deployment, so that multiple service providers (like  Martha) can be created and have administrative privilege across multiple domains which falls under their administrative boundary.\n\nNote: There will be only one level of hierarchy as multi level hierarchy is complex to implement and does not perform well. Give that, \"Martha/ProductionIT\" will be at root of hierarchy, Joe and Sam will stand at leaf of the hierarchy.  \n\n(Solution for Req#1) Keystone has concept of domains which is nothing but a notion of an administrative boundary where admin of one domain is allowed to manage resources within a specific domain but not across domains, provided correct policy is in place. This is already in place so there will be no change needed to support Req #1.\n\n(Solution for Req#2)\nWe can extend the notion of domains further to define a root (parent/super) domain and leaf (child/sub) domains, one set of root and leaf domains will define a hierarchicical administrative boundary. Glue between root and leafs will be different roles, that way \"Matha\" can become \"NovaAdmin\" (or any other role) in WidgetMaster or SuperDevShop.\n\n\n### Pros ###\nComplete IAM based solution.\nMore logically fits in hierarchicical model.\nAbsolutely no (or minimal) changes to services (Nova, Swift ....)\n\n### Cons ###\nMost of the changes is needed in Keystone and its data model (Domain, Roles).\nSome change required in OSLO policy engine for policy evaluation.\nService (Nova, Swift ....) may have define new roles.\n\n\nLet me know if I am not making sense here or have any questions.\n\n \nArvind\n\n-----Original Message-----\nFrom: Vishvananda Ishaya [mailto:vishvananda at gmail.com] \nSent: Monday, February 03, 2014 2:58 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion\n\nHello Again!\n\nAt the meeting last week we discussed some options around getting true multitenancy in nova. The use case that we are trying to support can be described as follows:\n\n\"Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users, projects, and quotas, as well as the ability to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for both WidgetMaster and SuperDevShop; manage users, projects, and objects across the entire system; and set quotas for the client companies as a whole. She also needs to ensure that Joe can\'t see or mess with anything owned by Sam.\"\n\nAs per the plan I outlined in the meeting I have implemented a Proof-of-Concept that would allow me to see what changes were required in nova to get scoped tenancy working. I used a simple approach of faking out heirarchy by prepending the id of the larger scope to the id of the smaller scope. Keystone uses uuids internally, but for ease of explanation I will pretend like it is using the name. I think we can all agree that \'orga.projecta\' is more readable than \'b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8\'.\n\nThe code basically creates the following five projects:\n\norga\norga.projecta\norga.projectb\norgb\norgb.projecta\n\nI then modified nova to replace everywhere where it searches or limits policy by project_id to do a prefix match. This means that someone using project \'orga\' should be able to list/delete instances in orga, orga.projecta, and orga.projectb.\n\nYou can find the code here:\n\n  https://github.com/vishvananda/devstack/commit/10f727ce39ef4275b613201ae1ec7655bd79dd5f\n  https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c205c7a3c372412f\n\nKeeping in mind that this is a prototype, but I\'m hoping to come to some kind of consensus as to whether this is a reasonable approach. I\'ve compiled a list of pros and cons.\n\nPros:\n\n  * Very easy to understand\n  * Minimal changes to nova\n  * Good performance in db (prefix matching uses indexes)\n  * Could be extended to cover more complex scenarios like multiple owners or multiple scopes\n\nCons:\n\n  * Nova has no map of the hierarchy\n  * Moving projects would require updates to ownership inside of nova\n  * Complex scenarios involving delegation of roles may be a bad fit\n  * Database upgrade to hierarchy could be tricky\n\nIf this seems like a reasonable set of tradeoffs, there are a few things that need to be done inside of nova bring this to a complete solution:\n\n  * Prefix matching needs to go into oslo.policy\n  * Should the tenant_id returned by the api reflect the full \'orga.projecta\', or just the child \'projecta\' or match the scope: i.e. the first if you are authenticated to orga and the second if you are authenticated to the project?\n  * Possible migrations for existing project_id fields\n  * Use a different field for passing ownership scope instead of overloading project_id\n  * Figure out how nested quotas should work\n  * Look for other bugs relating to scoping\n\nAlso, we need to decide how keystone should construct and pass this information to the services. The obvious case that could be supported today would be to allow a single level of hierarchy using domains. For example, if domains are active, keystone could pass domain.project_id for ownership_scope. This could be controversial because potentially domains are just for grouping users and shouldn\'t be applied to projects.\n\nI think the real value of this approach would be to allow nested projects with role inheritance. When keystone is creating the token, it could walk the tree of parent projects, construct the set of roles, and construct the ownership_scope as it walks to the root of the tree.\n\nFinally, similar fixes will need to be made in the other projects to bring this to a complete solution.\n\nPlease feel free to respond with any input, and we will be having another Hierarchical Multitenancy Meeting on Friday at 1600 UTC to discuss.\n\nVish\n\nOn Jan 28, 2014, at 10:35 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n\n> Hi Everyone,\n> \n> I apologize for the obtuse title, but there isn\'t a better succinct term to describe what is needed. OpenStack has no support for multiple owners of objects. This means that a variety of private cloud use cases are simply not supported. Specifically, objects in the system can only be managed on the tenant level or globally.\n> \n> The key use case here is to delegate administration rights for a group of tenants to a specific user/role. There is something in Keystone called a \"domain\" which supports part of this functionality, but without support from all of the projects, this concept is pretty useless.\n> \n> In IRC today I had a brief discussion about how we could address this. I have put some details and a straw man up here:\n> \n> https://wiki.openstack.org/wiki/HierarchicalMultitenancy\n> \n> I would like to discuss this strawman and organize a group of people to get actual work done by having an irc meeting this Friday at 1600UTC. I know this time is probably a bit tough for Europe, so if we decide we need a regular meeting to discuss progress then we can vote on a better time for this meeting.\n> \n> https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Meeting\n> \n> Please note that this is going to be an active team that produces code. We will *NOT* spend a lot of time debating approaches, and instead focus on making something that works and learning as we go. The output of this team will be a MultiTenant devstack install that actually works, so that we can ensure the features we are adding to each project work together.\n> \n> Vish\n\n\n\n','<BFA9750F-9913-4F39-B18C-7BCE47D8AD4D@gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905381DF4@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 17:13:33',0,'2014-02-05 17:13:33',NULL,'[openstack-dev] [keystone][nova] Re:\n	Hierarchicical	Multitenancy Discussion','Hi Chris,\n\nLooking at your requirements, seems my solution (see attached email) is pretty much aligned. What I am trying to propose is\n\n1. One root domain as owner of \"virtual cloud\". Logically linked to \"n\" leaf domains. \n2. All leaf domains falls under admin boundary of \"virtual cloud\" owner.\n3. No sharing of resources at project level, that will keep the authorization model simple.\n4. No sharing of resources at domain level either.\n5. Hierarchy or admin boundary will be totally governed by roles. \n\nThis way we can setup a true virtual cloud/Reseller/wholesale model.\n\nThoughts?\n\nThanks,\nArvind\n\n-----Original Message-----\nFrom: Chris Behrens [mailto:cbehrens at codestud.com] \nSent: Wednesday, February 05, 2014 1:27 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy Discussion\n\n\nHi Vish,\n\nI\'m jumping in slightly late on this, but I also have an interest in this. I\'m going to preface this by saying that I have not read this whole thread yet, so I apologize if I repeat things, say anything that is addressed by previous posts, or doesn\'t jive with what you\'re looking for. :) But what you describe below sounds like exactly a use case I\'d come up with.\n\nEssentially I want another level above project_id. Depending on the exact use case, you could name it \'wholesale_id\' or \'reseller_id\'...and yeah, \'org_id\' fits in with your example. :) I think that I had decided I\'d call it \'domain\' to be more generic, especially after seeing keystone had a domain concept.\n\nYour idea below (prefixing the project_id) is exactly one way I thought of doing this to be least intrusive. I, however, thought that this would not be efficient. So, I was thinking about proposing that we add \'domain\' to all of our models. But that limits your hierarchy and I don\'t necessarily like that. :)  So I think that if the queries are truly indexed as you say below, you have a pretty good approach. The one issue that comes into mind is that if there\'s any chance of collision. For example, if project ids (or orgs) could contain a \'.\', then \'.\' as a delimiter won\'t work.\n\nMy requirements could be summed up pretty well by thinking of this as \'virtual clouds within a cloud\'. Deploy a single cloud infrastructure that could look like many multiple clouds. \'domain\' would be the key into each different virtual cloud. Accessing one virtual cloud doesn\'t reveal any details about another virtual cloud.\n\nWhat this means is:\n\n1) domain \'a\' cannot see instances (or resources in general) in domain \'b\'. It doesn\'t matter if domain \'a\' and domain \'b\' share the same tenant ID. If you act with the API on behalf of domain \'a\', you cannot see your instances in domain \'b\'.\n2) Flavors per domain. domain \'a\' can have different flavors than domain \'b\'.\n3) Images per domain. domain \'a\' could see different images than domain \'b\'.\n4) Quotas and quota limits per domain. your instances in domain \'a\' don\'t count against quotas in domain \'b\'.\n5) Go as far as using different config values depending on what domain you\'re using. This one is fun. :)\n\netc.\n\nI\'m not sure if you were looking to go that far or not. :) But I think that our ideas are close enough, if not exact, that we can achieve both of our goals with the same implementation.\n\nI\'d love to be involved with this. I am not sure that I currently have the time to help with implementation, however.\n\n- Chris\n\n\n\nOn Feb 3, 2014, at 1:58 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n\n> Hello Again!\n> \n> At the meeting last week we discussed some options around getting true multitenancy in nova. The use case that we are trying to support can be described as follows:\n> \n> \"Martha, the owner of ProductionIT provides it services to multiple Enterprise clients. She would like to offer cloud services to Joe at WidgetMaster, and Sam at SuperDevShop. Joe is a Development Manager for WidgetMaster and he has multiple QA and Development teams with many users. Joe needs the ability create users, projects, and quotas, as well as the ability to list and delete resources across WidgetMaster. Martha needs to be able to set the quotas for both WidgetMaster and SuperDevShop; manage users, projects, and objects across the entire system; and set quotas for the client companies as a whole. She also needs to ensure that Joe can\'t see or mess with anything owned by Sam.\"\n> \n> As per the plan I outlined in the meeting I have implemented a Proof-of-Concept that would allow me to see what changes were required in nova to get scoped tenancy working. I used a simple approach of faking out heirarchy by prepending the id of the larger scope to the id of the smaller scope. Keystone uses uuids internally, but for ease of explanation I will pretend like it is using the name. I think we can all agree that \'orga.projecta\' is more readable than \'b04f9ea01a9944ac903526885a2666dec45674c5c2c6463dad3c0cb9d7b8a6d8\'.\n> \n> The code basically creates the following five projects:\n> \n> orga\n> orga.projecta\n> orga.projectb\n> orgb\n> orgb.projecta\n> \n> I then modified nova to replace everywhere where it searches or limits policy by project_id to do a prefix match. This means that someone using project \'orga\' should be able to list/delete instances in orga, orga.projecta, and orga.projectb.\n> \n> You can find the code here:\n> \n>  \n> https://github.com/vishvananda/devstack/commit/10f727ce39ef4275b613201\n> ae1ec7655bd79dd5f  \n> https://github.com/vishvananda/nova/commit/ae4de19560b0a3718efaffb6c20\n> 5c7a3c372412f\n> \n> Keeping in mind that this is a prototype, but I\'m hoping to come to some kind of consensus as to whether this is a reasonable approach. I\'ve compiled a list of pros and cons.\n> \n> Pros:\n> \n>  * Very easy to understand\n>  * Minimal changes to nova\n>  * Good performance in db (prefix matching uses indexes)\n>  * Could be extended to cover more complex scenarios like multiple \n> owners or multiple scopes\n> \n> Cons:\n> \n>  * Nova has no map of the hierarchy\n>  * Moving projects would require updates to ownership inside of nova\n>  * Complex scenarios involving delegation of roles may be a bad fit\n>  * Database upgrade to hierarchy could be tricky\n> \n> If this seems like a reasonable set of tradeoffs, there are a few things that need to be done inside of nova bring this to a complete solution:\n> \n>  * Prefix matching needs to go into oslo.policy\n>  * Should the tenant_id returned by the api reflect the full \'orga.projecta\', or just the child \'projecta\' or match the scope: i.e. the first if you are authenticated to orga and the second if you are authenticated to the project?\n>  * Possible migrations for existing project_id fields\n>  * Use a different field for passing ownership scope instead of \n> overloading project_id\n>  * Figure out how nested quotas should work\n>  * Look for other bugs relating to scoping\n> \n> Also, we need to decide how keystone should construct and pass this information to the services. The obvious case that could be supported today would be to allow a single level of hierarchy using domains. For example, if domains are active, keystone could pass domain.project_id for ownership_scope. This could be controversial because potentially domains are just for grouping users and shouldn\'t be applied to projects.\n> \n> I think the real value of this approach would be to allow nested projects with role inheritance. When keystone is creating the token, it could walk the tree of parent projects, construct the set of roles, and construct the ownership_scope as it walks to the root of the tree.\n> \n> Finally, similar fixes will need to be made in the other projects to bring this to a complete solution.\n> \n> Please feel free to respond with any input, and we will be having another Hierarchical Multitenancy Meeting on Friday at 1600 UTC to discuss.\n> \n> Vish\n> \n> On Jan 28, 2014, at 10:35 AM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> \n>> Hi Everyone,\n>> \n>> I apologize for the obtuse title, but there isn\'t a better succinct term to describe what is needed. OpenStack has no support for multiple owners of objects. This means that a variety of private cloud use cases are simply not supported. Specifically, objects in the system can only be managed on the tenant level or globally.\n>> \n>> The key use case here is to delegate administration rights for a group of tenants to a specific user/role. There is something in Keystone called a \"domain\" which supports part of this functionality, but without support from all of the projects, this concept is pretty useless.\n>> \n>> In IRC today I had a brief discussion about how we could address this. I have put some details and a straw man up here:\n>> \n>> https://wiki.openstack.org/wiki/HierarchicalMultitenancy\n>> \n>> I would like to discuss this strawman and organize a group of people to get actual work done by having an irc meeting this Friday at 1600UTC. I know this time is probably a bit tough for Europe, so if we decide we need a regular meeting to discuss progress then we can vote on a better time for this meeting.\n>> \n>> https://wiki.openstack.org/wiki/Meetings#Hierarchical_Multitenancy_Me\n>> eting\n>> \n>> Please note that this is going to be an active team that produces code. We will *NOT* spend a lot of time debating approaches, and instead focus on making something that works and learning as we go. The output of this team will be a MultiTenant devstack install that actually works, so that we can ensure the features we are adding to each project work together.\n>> \n>> Vish\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: \"Tiwari, Arvind\" <arvind.tiwari at hp.com>\nSubject: RE: [openstack-dev] [keystone][nova] Re: Hierarchicical Multitenancy	Discussion\nDate: Tue, 4 Feb 2014 19:54:09 +0000\nSize: 9728\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/261a87d1/attachment.mht>\n\n','<53D9EA30-F921-4407-B951-8111FF6C814B@codestud.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3905392C0E@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 19:26:34',0,'2014-02-14 19:26:34',NULL,'[openstack-dev] VPC Proposal','Hi JC,\n\nI have proposed BP to address VPC using domain hierarchy and hierarchical administrative boundary.\n\nhttps://blueprints.launchpad.net/keystone/+spec/hierarchical-administrative-boundary\n\n\nThanks,\nArvind\n-----Original Message-----\nFrom: Martin, JC [mailto:jch.martin at gmail.com] \nSent: Friday, February 14, 2014 12:09 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] VPC Proposal\n\n\nThere is a Blueprint targeted for Icehouse-3 that is aiming to implement the AWS VPC api. I don\'t think that this blueprint is providing the necessary constructs to really implement a VPC, and it is not taking into account the domains, or proposed multi tenant hierarchy. In addition, I could not find a discussion about this topic leading to the approval.\n\nFor this reason, I wrote an \'umbrella\' blueprint to hopefully start the discussion on how to really implement VPC, and eventually split it into multiple real blueprints for each area.\n\nPlease, provide feedback on the following document, and on the best way to move this forward.\n\nhttps://wiki.openstack.org/wiki/Blueprint-VPC\n\nThanks,\n\nJC.\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<7F8C3C3F-91D4-4FB2-9B5B-E2BB9BDFEEE9@gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390539E42E@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 15:45:50',0,'2014-02-19 15:45:50',NULL,'[openstack-dev] [Nova] Including Domains in Nova','Hi Henrique,\n\nI agree with your thoughts and in my opinion every OpenStack service has to be Domain aware. Specially it will be more helpful in large scale OpenStack deployments where IAM resources are scoped to a domain but other services (e.g. Nova) are just not aware of domains.\n\nThanks,\nArvind\n\n\n\nFrom: Henrique Truta [mailto:henriquecostatruta at gmail.com]\nSent: Wednesday, February 19, 2014 5:21 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Nova] Including Domains in Nova\n\n\nHi everyone.\n\n\n\nIt is necessary to make Nova support the Domain quotas and create a new administrative perspective. Here are some reasons why Nova should support domains:\n\n\n\n1 - It\'s interesting to keep the main Openstack components sharing the same concept, once it has already been made in Keystone. In Keystone, the domain defines more administrative boundaries and makes management of its entities easier.\n\n\n\n2 - Nova shouldn\'t be so tied in to projects. Keystone was created to abstract concepts like these to other modules, like Nova. In addition, Nova needs to be flexible enough to work with the new functionalities that Keystone will provide. If we keep the Nova tied in to projects (or domains), we will be far from the Nova focus which is providing compute services.\n\n\n\n3 - There is also the Domain Quota Driver BP (https://blueprints.launchpad.net/nova/+spec/domain-quota-driver), which implementation has already began. This Blueprint allows the user to handle quotas at domain level. Nova requires domains to make this feature work properly, right above the project level. There is also an implementation that includes the domain information on the token context. This implementation have to be included as well: https://review.openstack.org/#/c/55870/ .\n\n\n\n4 - The Nova API must be extended in order to enable domain-level operations, that only work at project-level such as:\n\n    - Listing, viewing and deleting images;\n\n    - Deleting and listing servers;\n\n    - Perform server actions like changing passwords, reboot, rebuild and resize;\n\n    - CRUD and listing on server metadata;\n\nIn addition to provide quota management through the API and establishment of a new administrative scope.\n\n\n\nIn order to accomplish these features, the token must contain the domain informations, which will be included as mentioned in item 3. Then, the Nova API calls will be changed to consider the domain information and when a call referent to a project is made (e.g. servers).\n\n\n\nWhat do you think about it? Any additional suggestions?\n\n\n\nAT: Keystone also has to enforce the domain scoping more strongly, as in the current model Keystone resources are not required to be scoped  a domain.\n\n\n\nThanks.\n\n\n\nHenrique Truta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/756d72fe/attachment.html>\n\n','<CABj-22hzCWhUVJ9Vhg9s77FZ=Ar7XUXFWPC023t4jYokVhCFqw@mail.gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39053C324F@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 01:08:07',0,'2014-03-05 01:08:07',NULL,'[Openstack] [Barbican] HTTPS Connection Question','Hi Mark,\n\nBarbican does not support SSL , I have added BP for the same.\nhttps://blueprints.launchpad.net/barbican/+spec/transport-layer-security-is-needed-in-barbican\n\nI have added this page which uses NginX (I like better than APache) to provide SSL support\nhttps://github.com/cloudkeep/barbican/wiki/Deploy-OpenStack-Barbican-with-Nginx-web-server\n\nHope this will help.\n\nThanks,\nArvind\n\n\nFrom: Miller, Mark M (EB SW Cloud - R&D - Corvallis)\nSent: Tuesday, March 04, 2014 4:34 PM\nTo: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello Doug,\n\nThank you for the information. I will keep you informed if we decide to use Apache2 as a front end.\n\nRegards,\n\nMark\n\nFrom: Douglas Mendizabal [mailto:douglas.mendizabal at RACKSPACE.COM]\nSent: Tuesday, March 04, 2014 2:47 PM\nTo: Miller, Mark M (EB SW Cloud - R&D - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHi Mark,\n\nI hope I can answer your questions:\n\n1. HTTP support should be provided by the web server used to host barbican, not by barbican itself.  The files where you noticed the ?protocol = http? settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development.  The settings are just default development settings, and should be tuned to your particular situation.  You can find more information about uwsgi config options on their official documentation. [1]  In particular, you may be interested in enabling HTTPS support documentation. [2]\n\n2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican.  This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a WSGI app.  That said, we have not actually built environments with alternative web servers, so we don?t currently have any documentation on how to set that up.   If you decide to deploy Barbican using Apache, we?d love to hear about your experience and help out in any way we can (join us at #openstack-barbican on Freenode).  I would encourage you to contribute to our documentation wiki if you are successful.\n\nRegards,\n-Doug Mendizabal\n\n[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html\n[2] http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-support-from-1-3\n\n\nFrom: <Miller>, \"Mark M (EB SW Cloud - R&D - Corvallis)\" <mark.m.miller at hp.com<mailto:mark.m.miller at hp.com>>\nDate: Tuesday, March 4, 2014 at 12:44 PM\nTo: \"Ferreira, Rafael\" <raf at io.com<mailto:raf at io.com>>, Remo Mattei <remo at italy1.com<mailto:remo at italy1.com>>, Wyllys Ingersoll <wyllys.ingersoll at evault.com<mailto:wyllys.ingersoll at evault.com>>, \"openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\" <openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello,\n\nI?ve been digging and digging and I have not been able to locate the following information:\n\n\n1.      Does Barbican provide support for HTTPS connections to it? I noticed  ?protocol=http? in several .ini files and a .conf file, but no information on how to configure Barbican to use it.\n\n2.      The quickstart wiki shows how to install Barbican behind the uwsgi server. Is it possible to install Barbican behind Apache2? Is there any documentation or example configuration guides?\n\nThanks,\n\nMark\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/49828da3/attachment.html>\n\n','<D6182642CE6D2D4FBFCDF99946E249883B49009F@G9W0729.americas.hpqcorp.net>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39053C94BF@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 17:57:03',0,'2014-03-07 17:57:03',NULL,'[Openstack] [Barbican] HTTPS Connection Question','Just to confirm which ?barbican-api-paste.ini? you are making the below change?\n\n\nArvind\n\nFrom: Miller, Mark M (EB SW Cloud - R&D - Corvallis)\nSent: Friday, March 07, 2014 10:38 AM\nTo: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello Doug,\n\nI have been able to configure Barbican with Apache2 via WSGI thereby removing the middle ?HTTPS -> uWSGI -> Barbican? step. By removing the middle ?uWSGI? step, the insecure uwsgi connection is also removed. How do I contribute to the wiki page?\n\nI have also installed Keystone and attempted to configure Barbican to use Keystone for authentication but have been unsuccessful. Barbican performs the requested API without checking the token. What am I missing?\n\nMark\n\nFile barbican-api-paste.ini:\n\n# Use this pipeline for Barbican API - DEFAULT no authentication\n[pipeline:main]\n#pipeline = unauthenticated-context apiapp\npipeline = keystone_v3_authtoken context apiapp\n####pipeline = simple apiapp\n\n#Use this pipeline to activate a repoze.profile middleware and HTTP port,\n#  to provide profiling information for the REST API processing.\n[pipeline:barbican-profile]\npipeline = unauthenticated-context egg:Paste#cgitb egg:Paste#httpexceptions profile apiapp\n\n#Use this pipeline for keystone auth\n[pipeline:barbican-api-keystone]\npipeline = keystone_authtoken context apiapp\n\n[app:apiapp]\npaste.app_factory = barbican.api.app:create_main_app\n\n[filter:simple]\npaste.filter_factory = barbican.api.middleware.simple:SimpleFilter.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory = barbican.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:context]\npaste.filter_factory = barbican.api.middleware.context:ContextMiddleware.factory\n\n[filter:keystone_authtoken]\npaste.filter_factory = keystoneclient.middleware.auth_token:filter_factory\nsigning_dir = /tmp/barbican/cache\nauth_host = localhost\n#need ability to re-auth a token, thus admin url\nauth_port = 35357\nauth_protocol = http\nadmin_tenant_name = service\nadmin_user = barbican\nadmin_password = secret\n#admin_password = orange\nauth_version = v2.0\n#delay failing perhaps to log the unauthorized request in barbican ..\n#delay_auth_decision = true\n\n[filter:keystone_v3_authtoken]\npaste.filter_factory = keystoneclient.middleware.auth_token:filter_factory\nsigning_dir = /tmp/barbican/cache\nauth_host = localhost\n#need ability to re-auth a token, thus admin url\nauth_port = 35357\nauth_protocol = http\nadmin_tenant_name = service\nadmin_user = barbican\nadmin_password = secret\n#admin_password = orange\nauth_version = v3.0\n#delay failing perhaps to log the unauthorized request in barbican ..\n#delay_auth_decision = true\n\n[filter:profile]\nuse = egg:repoze.profile\nlog_filename = myapp.profile\ncachegrind_filename = cachegrind.out.myapp\ndiscard_first_request = true\npath = /__profile__\nflush_at_shutdown = true\nunwind = false\n\n\n\nFrom: Douglas Mendizabal [mailto:douglas.mendizabal at RACKSPACE.COM]\nSent: Tuesday, March 04, 2014 2:47 PM\nTo: Miller, Mark M (EB SW Cloud - R&D - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHi Mark,\n\nI hope I can answer your questions:\n\n1. HTTP support should be provided by the web server used to host barbican, not by barbican itself.  The files where you noticed the ?protocol = http? settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development.  The settings are just default development settings, and should be tuned to your particular situation.  You can find more information about uwsgi config options on their official documentation. [1]  In particular, you may be interested in enabling HTTPS support documentation. [2]\n\n2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican.  This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a WSGI app.  That said, we have not actually built environments with alternative web servers, so we don?t currently have any documentation on how to set that up.   If you decide to deploy Barbican using Apache, we?d love to hear about your experience and help out in any way we can (join us at #openstack-barbican on Freenode).  I would encourage you to contribute to our documentation wiki if you are successful.\n\nRegards,\n-Doug Mendizabal\n\n[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html\n[2] http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-support-from-1-3\n\n\nFrom: <Miller>, \"Mark M (EB SW Cloud - R&D - Corvallis)\" <mark.m.miller at hp.com<mailto:mark.m.miller at hp.com>>\nDate: Tuesday, March 4, 2014 at 12:44 PM\nTo: \"Ferreira, Rafael\" <raf at io.com<mailto:raf at io.com>>, Remo Mattei <remo at italy1.com<mailto:remo at italy1.com>>, Wyllys Ingersoll <wyllys.ingersoll at evault.com<mailto:wyllys.ingersoll at evault.com>>, \"openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\" <openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello,\n\nI?ve been digging and digging and I have not been able to locate the following information:\n\n\n1.      Does Barbican provide support for HTTPS connections to it? I noticed  ?protocol=http? in several .ini files and a .conf file, but no information on how to configure Barbican to use it.\n\n2.      The quickstart wiki shows how to install Barbican behind the uwsgi server. Is it possible to install Barbican behind Apache2? Is there any documentation or example configuration guides?\n\nThanks,\n\nMark\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140307/8840cc87/attachment.html>\n\n','<D6182642CE6D2D4FBFCDF99946E249883B49AE3B@G4W3299.americas.hpqcorp.net>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B39053C95E9@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 18:34:04',0,'2014-03-07 18:34:04',NULL,'[Openstack] [Barbican] HTTPS Connection Question','Comment in line.\n\nArvind\n\nFrom: Miller, Mark M (EB SW Cloud - R&D - Corvallis)\nSent: Friday, March 07, 2014 10:53 AM\nTo: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello,\n\nI want to ask the following question of the Barbican community:\n\n?How does Barbican store secrets today? Does it rely on special hardware to assure encryption of secrets is done. Does it also have an option to use SW encryption before storing secrets.?\n\n1.       It encrypt the secret before storing to DB, using a Key encryption key which is generated per tenant.\n\n2.       It is not mandatory to use special hardware for key encryption keys but can utilize a HSM for this purpose.\n\n3.       By default it generated the Key encryption keys by itself.\n\nThanks,\n\nMark\n\nFrom: Miller, Mark M (EB SW Cloud - R&D - Corvallis)\nSent: Friday, March 07, 2014 9:38 AM\nTo: Douglas Mendizabal; Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello Doug,\n\nI have been able to configure Barbican with Apache2 via WSGI thereby removing the middle ?HTTPS -> uWSGI -> Barbican? step. By removing the middle ?uWSGI? step, the insecure uwsgi connection is also removed. How do I contribute to the wiki page?\n\nI have also installed Keystone and attempted to configure Barbican to use Keystone for authentication but have been unsuccessful. Barbican performs the requested API without checking the token. What am I missing?\n\nMark\n\nFile barbican-api-paste.ini:\n\n# Use this pipeline for Barbican API - DEFAULT no authentication\n[pipeline:main]\n#pipeline = unauthenticated-context apiapp\npipeline = keystone_v3_authtoken context apiapp\n####pipeline = simple apiapp\n\n#Use this pipeline to activate a repoze.profile middleware and HTTP port,\n#  to provide profiling information for the REST API processing.\n[pipeline:barbican-profile]\npipeline = unauthenticated-context egg:Paste#cgitb egg:Paste#httpexceptions profile apiapp\n\n#Use this pipeline for keystone auth\n[pipeline:barbican-api-keystone]\npipeline = keystone_authtoken context apiapp\n\n[app:apiapp]\npaste.app_factory = barbican.api.app:create_main_app\n\n[filter:simple]\npaste.filter_factory = barbican.api.middleware.simple:SimpleFilter.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory = barbican.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:context]\npaste.filter_factory = barbican.api.middleware.context:ContextMiddleware.factory\n\n[filter:keystone_authtoken]\npaste.filter_factory = keystoneclient.middleware.auth_token:filter_factory\nsigning_dir = /tmp/barbican/cache\nauth_host = localhost\n#need ability to re-auth a token, thus admin url\nauth_port = 35357\nauth_protocol = http\nadmin_tenant_name = service\nadmin_user = barbican\nadmin_password = secret\n#admin_password = orange\nauth_version = v2.0\n#delay failing perhaps to log the unauthorized request in barbican ..\n#delay_auth_decision = true\n\n[filter:keystone_v3_authtoken]\npaste.filter_factory = keystoneclient.middleware.auth_token:filter_factory\nsigning_dir = /tmp/barbican/cache\nauth_host = localhost\n#need ability to re-auth a token, thus admin url\nauth_port = 35357\nauth_protocol = http\nadmin_tenant_name = service\nadmin_user = barbican\nadmin_password = secret\n#admin_password = orange\nauth_version = v3.0\n#delay failing perhaps to log the unauthorized request in barbican ..\n#delay_auth_decision = true\n\n[filter:profile]\nuse = egg:repoze.profile\nlog_filename = myapp.profile\ncachegrind_filename = cachegrind.out.myapp\ndiscard_first_request = true\npath = /__profile__\nflush_at_shutdown = true\nunwind = false\n\n\n\nFrom: Douglas Mendizabal [mailto:douglas.mendizabal at RACKSPACE.COM]\nSent: Tuesday, March 04, 2014 2:47 PM\nTo: Miller, Mark M (EB SW Cloud - R&D - Corvallis); Ferreira, Rafael; Remo Mattei; Wyllys Ingersoll; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHi Mark,\n\nI hope I can answer your questions:\n\n1. HTTP support should be provided by the web server used to host barbican, not by barbican itself.  The files where you noticed the ?protocol = http? settings are uwsgi configuration files the Barbican team uses to run Barbican using uwsgi during development.  The settings are just default development settings, and should be tuned to your particular situation.  You can find more information about uwsgi config options on their official documentation. [1]  In particular, you may be interested in enabling HTTPS support documentation. [2]\n\n2. As I mentioned above, the dev team uses uwsgi to run Barbican, however there are no dependencies on uwsgi built into barbican.  This means that, in theory, you should be able to run Barbican using Apache + mod_uwsgi, or Nginx + gunicorn, or any other web server capable of hosting a WSGI app.  That said, we have not actually built environments with alternative web servers, so we don?t currently have any documentation on how to set that up.   If you decide to deploy Barbican using Apache, we?d love to hear about your experience and help out in any way we can (join us at #openstack-barbican on Freenode).  I would encourage you to contribute to our documentation wiki if you are successful.\n\nRegards,\n-Doug Mendizabal\n\n[1] http://uwsgi-docs.readthedocs.org/en/latest/Options.html\n[2] http://uwsgi-docs.readthedocs.org/en/latest/HTTPS.html?highlight=ssl#https-support-from-1-3\n\n\nFrom: <Miller>, \"Mark M (EB SW Cloud - R&D - Corvallis)\" <mark.m.miller at hp.com<mailto:mark.m.miller at hp.com>>\nDate: Tuesday, March 4, 2014 at 12:44 PM\nTo: \"Ferreira, Rafael\" <raf at io.com<mailto:raf at io.com>>, Remo Mattei <remo at italy1.com<mailto:remo at italy1.com>>, Wyllys Ingersoll <wyllys.ingersoll at evault.com<mailto:wyllys.ingersoll at evault.com>>, \"openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\" <openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>>\nSubject: Re: [Openstack] [Barbican] HTTPS Connection Question\n\nHello,\n\nI?ve been digging and digging and I have not been able to locate the following information:\n\n\n1.      Does Barbican provide support for HTTPS connections to it? I noticed  ?protocol=http? in several .ini files and a .conf file, but no information on how to configure Barbican to use it.\n\n2.      The quickstart wiki shows how to install Barbican behind the uwsgi server. Is it possible to install Barbican behind Apache2? Is there any documentation or example configuration guides?\n\nThanks,\n\nMark\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140307/976e560a/attachment-0001.html>\n\n','<D6182642CE6D2D4FBFCDF99946E249883B49AE63@G4W3299.americas.hpqcorp.net>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3906FF4C32@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 16:22:02',0,'2014-05-05 16:22:02',NULL,'[openstack-dev] [barbican] Atlanta Summit Etherpads for Review','Hi Chad,\n\nWe are working on following topics and expecting some time to discuss in the summit. Can we accommodate them in the summit?\n\nhttps://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level (We are working on POC + API change proposal)\nhttps://blueprints.launchpad.net/barbican/+spec/api-remove-uri-tenant-id (API change proposal)\nhttps://blueprints.launchpad.net/barbican/+spec/ability-to-hard-delete-barbican-entities (API change proposal)\n\nThanks,\nArvind\n\n\nFrom: Chad Lung [mailto:chad.lung at gmail.com]\nSent: Monday, May 05, 2014 10:06 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review\n\n\nThe Barbican team has placed a few etherpads on our wiki for the community to review. We plan to work on these at the Atlanta summit next week in our sessions and throughout the week.\n\nhttps://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads\nThanks,\nChad Lung\nhttp://giantflyingsaucer.com/blog/\n@chadlung\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140505/82bc601d/attachment.html>\n\n','<CAEvMfcrw0wzirjKCE3BduV6N-6-Fi0zuDgpEYtWoHCp6YO0K=w@mail.gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3906FF4C53@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 16:24:46',0,'2014-05-05 16:24:46',NULL,'[openstack-dev] [barbican] Atlanta Summit Etherpads for Review','Chad,\n\nPlease let me know if you want me to start etherpads for them?\n\nRegards,\nArvind\n\nFrom: Tiwari, Arvind\nSent: Monday, May 05, 2014 10:22 AM\nTo: openstack-dev at lists.openstack.org\nSubject: RE: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review\n\nHi Chad,\n\nWe are working on following topics and expecting some time to discuss in the summit. Can we accommodate them in the summit?\n\nhttps://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level (We are working on POC + API change proposal)\nhttps://blueprints.launchpad.net/barbican/+spec/api-remove-uri-tenant-id (API change proposal)\nhttps://blueprints.launchpad.net/barbican/+spec/ability-to-hard-delete-barbican-entities (API change proposal)\n\nThanks,\nArvind\n\n\nFrom: Chad Lung [mailto:chad.lung at gmail.com]\nSent: Monday, May 05, 2014 10:06 AM\nTo: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review\n\n\nThe Barbican team has placed a few etherpads on our wiki for the community to review. We plan to work on these at the Atlanta summit next week in our sessions and throughout the week.\n\nhttps://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads\nThanks,\nChad Lung\nhttp://giantflyingsaucer.com/blog/\n@chadlung\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140505/f845d490/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B3907000AF2@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 23:55:45',0,'2014-05-08 23:55:45',NULL,'[openstack-dev] Hierarchical administrative boundary [keystone]','Hi All,\n\nBelow is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9> session of Atlanta design summit.\n\nhttps://wiki.openstack.org/wiki/Hierarchical_administrative_boundary\n\nPlease take a look.\n\nThanks,\nArvind\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140508/3eaa5a58/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B3907001A09@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-09 18:23:17',0,'2014-05-09 18:23:17',NULL,'[openstack-dev] Hierarchical administrative boundary [keystone]','Hi All,\n\nThanks for looking in to my proposal. Below are my comments and answers to questions which is based on ?my personal opinion?.\n\nWhy domain hierarchy, why not project hierarchy? Because project hierarchy is more impactful and need cross project changes.\n\nAs per my understanding we all are trying to solve one business use problem, which is ?how to support VPC or Reseller? model on OS based cloud deployment.  As per problem described in different proposals, it is purely a IAM use case, where different identities (users, admins, reseller ?.) has different perception about the system/resources (IAM and non IAM) and they want ability to manage them.\n\nKeystone (OS IAM service) abstracts all the IAM complexity  from lower level services (Nova, Swift, cinder ?) by providing unified integration model (auth token and verification by auth middleware). Lover level services trusts Keystone and allow access (for particular requests) to actual resource based on subject?s roles provided by keystone.\n\nEach service supports multi tenancy and tenancy mapping is establish by keystone through projects.  If hierarchy enforced at project level then we need to propagate the hierarchy info to all lower level services, where the hierarchy  info is not serving any good purpose but just used to map one tenant. Enforcing the hierarchy at project level is more impactful because all services have to change their implementation to consume the notion of hierarchy. Propagating project hierarchy to services would make sense if end resources (VMs, cinder volumes , swift resource ?.) does obey the hierarchy based on projects, I think that is not the case.\n\nAs per definition domains are container for projects, users and groups and maps well with a business entities (ProductionIT, SuperDevShop, WidgetMaster, SPI, reseller .....). Using domain to establish hierarchy (as per my design) will abstract the complexity from lower level services. Services don?t have to worry about the domain hierarchy and we can retain the current integration (Keystone project <-> service Tenant ) model and no need to make big change in different service. Mostly one place change which is Keystone.\n\nServices has to be domain aware\n\nIMO services (Nova, Swift ?) don?t have to be domain aware (Unless I am missing something) as they manage resources for keystone projects. Domain is IAM concept which used to scope IAM resources and not very useful for end services. I think what we are lacking is unique role (role name) per service, having unique role names for each service (IAM, Nova, Swift ?.)  will resolve the problem mentioned below by  Yaguang Tang.\n\nPlease let me know why services have to be domain aware?\n\nThoughts?\n\nThanks,\nArvind\n\nNote:\nIAM Resources ? Users, groups, projects ?\nNon IAM resources ? VMs, Swift objects, ??.\n\nFrom: Yaguang Tang [mailto:yaguang.tang at canonical.com]\nSent: Friday, May 09, 2014 4:33 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Hierarchical administrative boundary [keystone]\n\nFrittoli,\n\nI think for other services we could achieve that by  modifying  the policy.json( add domain admin role and control what the cloud admin can do ) so that domain admin user is able to manage resources belong to\nusers and projects in that domain.\n\n2014-05-09 15:24 GMT+08:00 Frittoli, Andrea (HP Cloud) <frittoli at hp.com<mailto:frittoli at hp.com>>:\nFrom: Adam Young [mailto:ayoung at redhat.com<mailto:ayoung at redhat.com>]\nSent: 09 May 2014 04:19\nTo: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] Hierarchical administrative boundary [keystone]\n\nOn 05/08/2014 07:55 PM, Tiwari, Arvind wrote:\nHi All,\n\nBelow is my proposal to address VPC use case using hierarchical administrative boundary. This topic is scheduled in Hierarchical Multitenancy<http://junodesignsummit.sched.org/event/20465cd62e9054d4043dda156da5070e#.U2wYXXKLR_9> session of Atlanta design summit.\n\nhttps://wiki.openstack.org/wiki/Hierarchical_administrative_boundary\n\nPlease take a look.\n\nThanks,\nArvind\n\n\n\n\n_______________________________________________\n\nOpenStack-dev mailing list\n\n\n\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nLooks very good.  One question:  Why hierarchical domains and not Projects.  I\'m not disagreeing, mind you, just that I think the Nova team is going for hierarchical Projects.\n\n________________________________\nLooks good, thank you!\n\nBut for this to be even more interesting nova (and other services) should be domain aware ? e.g. so that a domain admin could have control on all resources which belong to users and projects in that domain.\n\nandrea\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nTang Yaguang\n\nCanonical Ltd. | www.ubuntu.com<http://www.ubuntu.com/> | www.canonical.com<http://www.canonical.com/>\nMobile:  +86 152 1094 6968\ngpg key: 0x187F664F\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140509/905511e4/attachment.html>\n\n','<CA+GwYPcL_OC7mB9vTJm2a51fOasB-8yhQ35274uWkfw3rTyX7g@mail.gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B3907006928@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-15 12:21:02',0,'2014-05-15 12:21:02',NULL,'[openstack-dev] [keystone] [barbican] Protecting user specific\n secrets in Barbican','Barbcan will be used as secret store (or Key Manager) in Open Stack deployments. That means users can store any kind for secrets (ssh keys , access keys, password .....) in Barbican these secrets are not shared secrets.\n\nIn below scenario it seems secrets are not well protected in Barbican\n\n\n1.       Barbican in integrated a OS based cloud deployment.\n\n2.       In particular domain there is one (or multiple) project.\n\n3.       Users are associated with the project through role (two coworker can have same role e.g. creator) or a admin user have higher role.\n\n4.       Users have their secrets (ssh keys , access keys, password .....) for services (VMs per users, resources) saved in Barbican.\n\n\nProblem\n\n\n1.       Users with the same role or Admin on project can see each other secrets which are not a shared secrets.\n\n2.       Multiple projects (or project hierarchy) per user just to store secrets is not going to help as it will lead to project exposition and confusing. At the same time projects are not meant to go 1 to 1 with user.\n\n3.       Project hierarchy is also not a good solution as user on top of the hierarchy (reseller admin) can inherits role and able to steal the secrets.\n\n\nNote, Barbican is designed for secret storage and protection, we need better management on secrets in Barbican. We also need better solution to address this problem.\n\n\nKeystone and Barbican (or interested party) team, can we have a meeting today to brainstorm this issue and come up with better solution?\n\n\nThanks\nArvind\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140515/ed5bc044/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390705815A@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 19:54:46',0,'2014-06-09 19:54:46',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n Integration Ideas','As per current implementation, containers are immutable. \nDo we have any use case to make it mutable? Can we live with new container instead of updating an existing container?\n\nArvind \n\n-----Original Message-----\nFrom: Samuel Bercovici [mailto:SamuelB at Radware.com] \nSent: Monday, June 09, 2014 1:31 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas\n\nAs far as I understand the Current Barbican implementation is immutable.\nCan anyone from Barbican comment on this?\n\n-----Original Message-----\nFrom: Jain, Vivek [mailto:VIVEKJAIN at ebay.com]\nSent: Monday, June 09, 2014 8:34 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas\n\n+1 for the idea of making certificate immutable.\nHowever, if Barbican allows updating certs/containers then versioning is a must.\n\nThanks,\nVivek\n\n\nOn 6/8/14, 11:48 PM, \"Samuel Bercovici\" <SamuelB at Radware.com> wrote:\n\n>Hi,\n>\n>I think that option 2 should be preferred at this stage.\n>I also think that certificate should be immutable, if you want a new \n>one, create a new one and update the listener to use it.\n>This removes any chance of mistakes, need for versioning etc.\n>\n>-Sam.\n>\n>-----Original Message-----\n>From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM]\n>Sent: Friday, June 06, 2014 10:16 PM\n>To: OpenStack Development Mailing List (not for usage questions)\n>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS \n>Integration Ideas\n>\n>Hey everyone,\n>\n>Per our IRC discussion yesterday I\'d like to continue the discussion on \n>how Barbican and Neutron LBaaS will interact. There are currently two \n>ideas in play and both will work. If you have another idea please free \n>to add it so that we may evaluate all the options relative to each other.\n>Here are the two current ideas:\n>\n>1. Create an eventing system for Barbican that Neutron LBaaS (and other\n>services) consumes to identify when to update/delete updated secrets \n>from Barbican. For those that aren\'t up to date with the Neutron LBaaS \n>API Revision, the project/tenant/user provides a secret (container?) id \n>when enabling SSL/TLS functionality.\n>\n>* Example: If a user makes a change to a secret/container in Barbican \n>then Neutron LBaaS will see an event and take the appropriate action.\n>\n>PROS:\n> - Barbican is going to create an eventing system regardless so it will \n>be supported.\n> - Decisions are made on behalf of the user which lessens the amount of \n>calls the user has to make.\n>\n>CONS:\n> - An eventing framework can become complex especially since we need to \n>ensure delivery of an event.\n> - Implementing an eventing system will take more time than option #2?I \n>think.\n>\n>2. Push orchestration decisions to API users. This idea comes with two \n>assumptions. The first assumption is that most providers\' customers use \n>the cloud via a GUI, which in turn can handle any orchestration \n>decisions that need to be made. The second assumption is that power API \n>users are savvy and can handle their decisions as well. Using this \n>method requires services, such as LBaaS, to \"register\" in the form of \n>metadata to a barbican container.\n>\n>* Example: If a user makes a change to a secret the GUI can see which \n>services are registered and opt to warn the user of consequences. Power \n>users can look at the registered services and make decisions how they \n>see fit.\n>\n>PROS:\n> - Very simple to implement. The only code needed to make this a \n>reality is at the control plane (API) level.\n> - This option is more loosely coupled that option #1.\n>\n>CONS:\n> - Potential for services to not register/unregister. What happens in \n>this case?\n> - Pushes complexity of decision making on to GUI engineers and power \n>API users.\n>\n>\n>I would like to get a consensus on which option to move forward with \n>ASAP since the hackathon is coming up and delivering Barbican to \n>Neutron LBaaS integration is essential to exposing SSL/TLS \n>functionality, which almost everyone has stated is a #1/#2 priority.\n>\n>I\'ll start the decision making process by advocating for option #2. My \n>reason for choosing option #2 has to deal mostly with the simplicity of \n>implementing such a mechanism. Simplicity also means we can implement \n>the necessary code and get it approved much faster which seems to be a \n>concern for everyone. What option does everyone else want to move \n>forward with?\n>\n>\n>\n>Cheers,\n>--Jorge\n>\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F36E8145F2571242A675F56CF60964560E9F5EEA@ILMB1.corp.radware.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A99542B@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 22:16:19',0,'2014-06-12 22:16:19',NULL,'[openstack-dev] Message level security plans. [barbican]','Some thoughts out of the context of this email thread.\n\nAs per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs?\n\nThoughts?\n\nArvind\n\n-----Original Message-----\nFrom: Nathan Kinder [mailto:nkinder at redhat.com] \nSent: Thursday, June 12, 2014 3:32 PM\nTo: openstack-dev at lists.openstack.org\nCc: Jamie Lennox\nSubject: Re: [openstack-dev] Message level security plans.\n\nHi Tim,\n\nJamie Lennox (cc\'d) has been the main developer working on Kite.  I\'m sure he would appreciate you getting involved in reviews [1] and any other development help you\'re willing to contribute.  Patches have slowly been landing in the kite repo. [2]\n\nFor others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine:\n\n  https://blog-nkinder.rhcloud.com/?p=62\n\nThanks,\n-NGK\n\n[1] https://review.openstack.org/#/q/status:open+project:stackforge/kite,n,z\n[2] https://github.com/stackforge/kite\n\n\nOn 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:\n> Hello OpenStack folks,\n> \n> First please allow me to introduce myself, my name is Tim Kelsey and I\'m a security developer working at HP. I am very interested in projects like Kite and the work that\'s being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what\'s being worked on or planned in blueprints.\n> \n> Many Thanks,\n> \n> --\n> Tim Kelsey\n> Cloud Security Engineer\n> HP Helion\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<539A1C49.5070108@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A99552C@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 23:22:15',0,'2014-06-12 23:22:15',NULL,'[openstack-dev] Message level security plans. [barbican]','Thanks Nathan for your response.  \n\nStill not very convinced for two separate service.\n\nKeystone authentication is not a mandatory requirement for Barbican, as per design it can work without Keystone authentication. Rest (temporary session key generation, long-term keys ...) are feature gap which can be easily developed in barbican. \n\nIf Barbican has to store long term keys on behalf of Kite users than IMO it is good to merge these two services. We can develop separate plug-in to achieve KDC (or Kite plug-in). One can have two separate barbican deployments one of KDC another for KMS (or may be only one with enhanced barbican API). \n\nThoughts?\n\nArvind\n\n\n-----Original Message-----\nFrom: Nathan Kinder [mailto:nkinder at redhat.com] \nSent: Thursday, June 12, 2014 4:41 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Message level security plans. [barbican]\n\n\n\nOn 06/12/2014 03:16 PM, Tiwari, Arvind wrote:\n> Some thoughts out of the context of this email thread.\n> \n> As per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs?\n\nThat\'s not a true statement.  This was also something that was discussed at the Atlanta Summit in the Kite session with the Barbican development team, and agreement was reached that they are different use-cases and feature sets that should remain separate.\n\nTo (over) simplify, Barbican allows OpenStack users (or services) identified by Keystone tokens to archive and later retrieve keys.  In contrast, Kite is generating and issuing temporary session keys to communicating parties that are using the message queue in the underlying OpenStack infrastructure.  These parties are not identified by Keystone.\n These session keys are also not archived by a service.  Kite generates them, issues them in the form of a ticket, and forgets them immediately.\n You never want to be able to retrieve a key after a ticket is issued.\nIn addition, the key generation is not purely random as I\'ve outlined in my blog post (see the details around how HKDF is used if you\'re interested).\n\nThere are areas for integration between Kite and Barbican.  The most obvious would be to utilize Baribican to store the long-term keys used to authenticate the communicating party.\n\nThanks,\n-NGK\n\n> \n> Thoughts?\n> \n> Arvind\n> \n> -----Original Message-----\n> From: Nathan Kinder [mailto:nkinder at redhat.com]\n> Sent: Thursday, June 12, 2014 3:32 PM\n> To: openstack-dev at lists.openstack.org\n> Cc: Jamie Lennox\n> Subject: Re: [openstack-dev] Message level security plans.\n> \n> Hi Tim,\n> \n> Jamie Lennox (cc\'d) has been the main developer working on Kite.  I\'m \n> sure he would appreciate you getting involved in reviews [1] and any \n> other development help you\'re willing to contribute.  Patches have \n> slowly been landing in the kite repo. [2]\n> \n> For others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine:\n> \n>   https://blog-nkinder.rhcloud.com/?p=62\n> \n> Thanks,\n> -NGK\n> \n> [1] \n> https://review.openstack.org/#/q/status:open+project:stackforge/kite,n\n> ,z [2] https://github.com/stackforge/kite\n> \n> \n> On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:\n>> Hello OpenStack folks,\n>>\n>> First please allow me to introduce myself, my name is Tim Kelsey and I\'m a security developer working at HP. I am very interested in projects like Kite and the work that\'s being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what\'s being worked on or planned in blueprints.\n>>\n>> Many Thanks,\n>>\n>> --\n>> Tim Kelsey\n>> Cloud Security Engineer\n>> HP Helion\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<539A2C6E.7020305@redhat.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A9C4122@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-01 22:52:11',0,'2014-07-01 22:52:11',NULL,'[openstack-dev] Inter Cloud Resource Federation (Alliance)','All,\n\nI am working on a new service to address the problems of \"Inter Cloud Resource Federation\" use cases (e.g. multi region, cloud bursting, resource sharing across clouds, etc ..... ).\n\nThe new service will integrate multiple OpenStack cloud to work in alliance to provide resource federation and resource sharing across clouds.\n\nPlease take a look at link below which explains use cases for resource federation and solution. This link also explains high level components of the new service.\n\nhttps://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation\n\nPlease share your thoughts and  comments.\n\nThanks,\nArvind\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/4e10a2b7/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A9D81E4@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 17:33:42',0,'2014-07-09 17:33:42',NULL,'[openstack-dev] Inter cloud resource federation [Alliance]','Hi All,\n\nI am investigating on inter cloud resource federation across OS based cloud deployments, this is needed to support multi regions, cloud bursting, VPC and more use cases. I came up with a design (link below) which advocate a new service (a.k.a. Alliance), this service sits close to Keystone and help abstracting all the inter cloud concerns from Keystone. This service will be abstracted from end users and there won\'t be any direct interactions between user and Alliance service. Keystone will be delegating all inter cloud concerns to Alliance.\n\nhttps://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation\n\nApart from basic resource federation use cases, Alliance service will add following features\n\n\n1.       UUID token support across cloud\n\n2.       PKI Token support\n\n3.       Inter Cloud Token Validation\n\n4.       Inter Cloud Communication to allow\n\n*        Region/endpoint Discovery\n\n*        Service Discovery\n\n*        Remote Resource Provisioning\n\n5.       Resource Access Across Clouds\n\n6.       SSO Across Cloud\n\n7.       SSOut Across Cloud (or Inter Cloud Token Revocation)\n\n8.       Notification to propagate meter info, resource de-provisioning ....\n\nI would appreciate if you guys take a look and share your perspective. I am open to any questions, suggestions, discussions on the same.\n\nThanks for your time,\nArvind\n\n\nPlease excuse any typographical error.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140709/8a01a514/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A9D92C6@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 15:31:01',0,'2014-07-10 15:31:01',NULL,'[openstack-dev] Inter cloud resource federation [Alliance]','Hi Raildo,\n\nYes, I am trying to separate out the resource federation concerns through Alliance, Identity federation will be intact with Keystone. At the same time Alliance will play as delegate for keystone wherever resource federation across clouds concern need to be addressed.\nI would love to work with you on this and anyone who is interested. I am putting together a POC and will keep you and community informed on the same.\n\nThanks,\nArvind\n\nFrom: Raildo Mascena [mailto:raildom at gmail.com]\nSent: Wednesday, July 09, 2014 1:16 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Inter cloud resource federation [Alliance]\n\nHi Arvind,\n\nFirst, I quite liked the idea and I am very interested in helping you with that.\n\nSecond, I have some doubts. What is the similarity (and differences) with Keystone to Keystone blueprint? https://review.openstack.org/#/c/100023/<https://blueprints.launchpad.net/keystone/+spec/keystone-to-keystone-federation>\n\nThe federation will be migrated to this new service?\n\nRegards,\n\n2014-07-09 14:33 GMT-03:00 Tiwari, Arvind <arvind.tiwari at hp.com<mailto:arvind.tiwari at hp.com>>:\nHi All,\n\nI am investigating on inter cloud resource federation across OS based cloud deployments, this is needed to support multi regions, cloud bursting, VPC and more use cases. I came up with a design (link below) which advocate a new service (a.k.a. Alliance), this service sits close to Keystone and help abstracting all the inter cloud concerns from Keystone. This service will be abstracted from end users and there won?t be any direct interactions between user and Alliance service. Keystone will be delegating all inter cloud concerns to Alliance.\n\nhttps://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation\n\nApart from basic resource federation use cases, Alliance service will add following features\n\n\n1.       UUID token support across cloud\n\n2.       PKI Token support\n\n3.       Inter Cloud Token Validation\n\n4.       Inter Cloud Communication to allow\n\n?        Region/endpoint Discovery\n\n?        Service Discovery\n\n?        Remote Resource Provisioning\n\n5.       Resource Access Across Clouds\n\n6.       SSO Across Cloud\n\n7.       SSOut Across Cloud (or Inter Cloud Token Revocation)\n\n8.       Notification to propagate meter info, resource de-provisioning ?.\n\nI would appreciate if you guys take a look and share your perspective. I am open to any questions, suggestions, discussions on the same.\n\nThanks for your time,\nArvind\n\n\nPlease excuse any typographical error.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nRaildo Mascena\nBachelor of Computer Science.\nSoftware Engineer at Laboratory of Distributed Systems - UFCG\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140710/0ce4327f/attachment.html>\n\n','<CA+o+YkrxqXz4Qg7kU4D7AKkLzM0BuXjn57Nk2-WczgeAJLv-Xg@mail.gmail.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A9D92F7@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 15:36:55',0,'2014-07-10 15:36:55',NULL,'[openstack-dev] Inter cloud resource federation [Alliance]','Hi Matt,\n\nIt is not about identity federation (which is handled in Keystone), this is about resource federation across clouds, Nova resources are one of them.\n\nI don\'t know much about Nova cells right now, I will try to understand it soon.\n\nThanks,\nArvind   \n\n-----Original Message-----\nFrom: Matt Riedemann [mailto:mriedem at linux.vnet.ibm.com] \nSent: Wednesday, July 09, 2014 2:30 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Inter cloud resource federation [Alliance]\n\n\n\nOn 7/9/2014 12:33 PM, Tiwari, Arvind wrote:\n> Hi All,\n>\n> I am investigating on inter cloud resource federation across OS based \n> cloud deployments, this is needed to support multi regions, cloud \n> bursting, VPC and more use cases. I came up with a design (link below) \n> which advocate a new service (a.k.a. Alliance), this service sits \n> close to Keystone and help abstracting all the inter cloud concerns \n> from Keystone. This service will be abstracted from end users and \n> there won\'t be any direct interactions between user and Alliance \n> service. Keystone will be delegating all inter cloud concerns to Alliance.\n>\n> https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation\n>\n> Apart from basic resource federation use cases, Alliance service will \n> add following features\n>\n> 1.UUID token support across cloud\n>\n> 2.PKI Token support\n>\n> 3.Inter Cloud Token Validation\n>\n> 4.Inter Cloud Communication to allow\n>\n> *Region/endpoint Discovery\n>\n> *Service Discovery\n>\n> *Remote Resource Provisioning\n>\n> 5.Resource Access Across Clouds\n>\n> 6.SSO Across Cloud\n>\n> 7.SSOut Across Cloud (or Inter Cloud Token Revocation)\n>\n> 8.Notification to propagate meter info, resource de-provisioning ....\n>\n> I would appreciate if you guys take a look and share your perspective. \n> I am open to any questions, suggestions, discussions on the same.\n>\n> Thanks for your time,\n>\n> Arvind\n>\n> *Please excuse any typographical error.***\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\nIs this only identity (keystone) are other things like booting instances in nova from public/private clouds which are abstracted from the client, and if so have you heard of nova-cells?\n\n-- \n\nThanks,\n\nMatt Riedemann\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53BDA64F.6070801@linux.vnet.ibm.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390A9EB0A6@G9W0721.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 20:22:54',0,'2014-07-22 20:22:54',NULL,'[openstack-dev]  [barbican] Need opinion on bug 1347101','I have logged below bug to enforce \'content-type\' check before RBAC enforcement on POST requests, but seems we have difference in opinion.\n\nhttps://bugs.launchpad.net/barbican/+bug/1347101\n\nPlease look at the above bug and share your thoughts.\n\n\"IMO\" -\n\"content-type\" enforcement is concern of REST subsystem (Pecan in this case) and RBAC is the applications concern.  Application resides a level below REST subsystem, so these checks and response should also follow this notion.\nRBAC enforcement should be done only after all the necessary checks related REST aspect has been performed.  This way we can save costly RBAC validation, at the same time returning a legitimate \"unauthorized\" response for a request with bad \"content type\" does not makes sense.\n\n\nThanks,\nArvind\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140722/44b26309/attachment.html>\n\n',NULL,NULL),('<0EF5F110A32BED44A0C6438BB5C35B390AA96303@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 16:42:32',0,'2014-10-01 16:42:32',NULL,'[openstack-dev] [all] [tc] Multi-clouds integration by\n OpenStack cascading','Hi Chaoyi,\n\nThanks for sharing these information.\n\nSometime back I have stared a project called ?Alliance? which trying to address the same concerns (see the link below). Alliance service is designed to provide \"Inter-Cloud Resource Federation\" which will enable resource sharing across cloud in distributed multi-site OpenStack clouds deployments. This service will run on top of OpenStack Cloud and fabricate different cloud (or data centers) instances in distributed cloud setup. This service will work closely with OpenStack components (Keystone, Nova, Cinder....) to manage and provision different resources (token, VM, images, network .....). Alliance service will provide abstraction to hide interoperability and integration complexities from underpinning cloud instance and enable following business use cases.\n\n- Multi Region Capability\n- Virtual Private Cloud\n- Cloud Bursting\n\nThis service will provide true plug & play model for region expansion, VPC like use case, conceptual design can be found at  https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation. We are working on POC using this concept which is in WIP.\n\nI will be happy to coordinate with you on this and try to come up with common solution, seems we both are trying to address same issues.\n\nThoughts?\n\nThanks,\nArvind\n\nFrom: joehuang [mailto:joehuang at huawei.com]\nSent: Wednesday, October 01, 2014 6:56 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\n\nHello,  Alex,\n\nThank you very much for your mail about remote cluster hypervisor.\n\nOne of the inspiration for OpenStack cascading is from the remote clustered hypervisor like vCenter. The difference between the remote clustered hypervisor and OpenStack cascading is that not only Nova involved in the cascading, but also Cinder, Neutron, Ceilometer, and even Glance(optional).\n\nPlease refer to https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Inspiration,\nhttps://wiki.openstack.org/wiki/OpenStack_cascading_solution#Architecture for more detail information.\n\nBest Regards\n\nChaoyi Huang ( joehuang )\n\n________________________________\nFrom: Alex Glikson [GLIKSON at il.ibm.com]\nSent: 01 October 2014 12:51\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\nThis sounds related to the discussion on the \'Nova clustered hypervisor driver\' which started at Juno design summit [1]. Talking to another OpenStack should be similar to talking to vCenter. The idea was that the Cells support could be refactored around this notion as well.\nNot sure whether there have been any active progress with this in Juno, though.\n\nRegards,\nAlex\n\n\n[1] http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c#<http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c>\n[2] https://etherpad.openstack.org/p/juno-nova-clustered-hypervisor-support\n\n\n\n\nFrom:        joehuang <joehuang at huawei.com<mailto:joehuang at huawei.com>>\nTo:        \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate:        30/09/2014 04:08 PM\nSubject:        [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\n________________________________\n\n\n\nHello, Dear TC and all,\n\nLarge cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons:\n\n1) Multiple data centers distributed geographically;\n2) Multi-vendor business policy;\n3) Server nodes scale up modularized from 00\'s up to million;\n4) Fault and maintenance isolation between zones (only REST interface);\n\nAt the same time, they also want to integrate these OpenStack instances into one cloud. Instead of proprietary orchestration layer, they want to use standard OpenStack framework for Northbound API compatibility with HEAT/Horizon or other 3rd ecosystem apps.\n\nWe call this pattern as \"OpenStack Cascading\", with proposal described by [1][2]. PoC live demo video can be found[3][4].\n\nNova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the OpenStack cascading.\n\nKindly ask for cross program design summit session to discuss OpenStack cascading and the contribution to Kilo.\n\nKindly invite those who are interested in the OpenStack cascading to work together and contribute it to OpenStack.\n\n(I applied for ?other projects? track [5], but it would be better to have a discussion as a formal cross program session, because many core programs are involved )\n\n\n[1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution\n[2] PoC source code: https://github.com/stackforge/tricircle\n[3] Live demo video at YouTube: https://www.youtube.com/watch?v=OSU6PYRz5qY\n[4] Live demo video at Youku (low quality, for those who can\'t access YouTube)?http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html\n[5] http://www.mail-archive.com/openstack-dev at lists.openstack.org/msg36395.html\n\nBest Regards\nChaoyi Huang ( Joe Huang )\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141001/4ea97d24/attachment.html>\n\n','<5E7A3D1BF5FD014E86E5F971CF446EFF541CA2A6@szxema505-mbx.china.huawei.com>',NULL),('<0EF5F110A32BED44A0C6438BB5C35B390AA976EC@G4W3210.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 15:13:50',0,'2014-10-02 15:13:50',NULL,'[openstack-dev] [all] [tc] Multi-clouds integration by\n OpenStack cascading','Hi Huang,\n\nThanks for looking in to my proposal.\n\nYes, Alliance is will be utilizing/retain all Northbound service APIs, in addition it will expose APIs for inter Alliance (inter cloud) communication. Alliance will be running at topmost layer on each individual OpenStack Cloud of multi-site distributed cloud setup. Additionally Alliance will provide loosely coupled integration among multiple clouds or cloudyfied data center.\n\nIn case of multi regions setup ?regional Alliance? (RA) will orchestrate the resource (project, VMs, volumes, network ?.) provisioning and state synchronization through its peers RA. In case cross enterprise integration (Enterprise/VPC/bursting like scenario) <-----> multi site public cloud) ?global Alliance? (GA) will be interface for external integration point and communicating with individual RAs.  I will update the wiki to make it more clear.\n\nI will love to coordinate with your team and solve this issue together,  I will be reaching there in Paris on 1 Nov and we can site f2f before session. Let?s plan a time to meet, Monday will be easy for me.\n\n\nThanks,\nArvind\n\n\n\nFrom: joehuang [mailto:joehuang at huawei.com]\nSent: Wednesday, October 01, 2014 5:01 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\n\n\nHi, Tiwari,\n\n\n\nGreat to know you are also trying to address similar issues. For sure we are happy to work out a common solution for these issues.\n\n\n\nI just go through the wiki page, the question for me is \"will the Alliance provide/retain current north bound OpenStack API ?\". It\'s very important for the cloud still expose OpenStack API so that the OpenStack API ecosystem will not be lost.\n\n\n\nAnd currently OpenStack cascading has not covered the hybrid cloud (private cloud and public cloud federation), so your project will be a good supplement.\n\n\n\nMay we have a f2f workshop before the formal Paris design summit, so that we can exchange ideas completely. 40 minutes design summit session is not enough for deep diving. PoC team will stay at Paris from Oct.29 to Nov.8.\n\n\n\nBest Regards\n\n\n\nChaoyi Huang ( joehuang )\n\n\n\n________________________________\nFrom: Tiwari, Arvind [arvind.tiwari at hp.com]\nSent: 02 October 2014 0:42\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\nHi Chaoyi,\n\nThanks for sharing these information.\n\nSometime back I have stared a project called ?Alliance? which trying to address the same concerns (see the link below). Alliance service is designed to provide \"Inter-Cloud Resource Federation\" which will enable resource sharing across cloud in distributed multi-site OpenStack clouds deployments. This service will run on top of OpenStack Cloud and fabricate different cloud (or data centers) instances in distributed cloud setup. This service will work closely with OpenStack components (Keystone, Nova, Cinder....) to manage and provision different resources (token, VM, images, network .....). Alliance service will provide abstraction to hide interoperability and integration complexities from underpinning cloud instance and enable following business use cases.\n\n- Multi Region Capability\n- Virtual Private Cloud\n- Cloud Bursting\n\nThis service will provide true plug & play model for region expansion, VPC like use case, conceptual design can be found at  https://wiki.openstack.org/wiki/Inter_Cloud_Resource_Federation. We are working on POC using this concept which is in WIP.\n\nI will be happy to coordinate with you on this and try to come up with common solution, seems we both are trying to address same issues.\n\nThoughts?\n\nThanks,\nArvind\n\nFrom: joehuang [mailto:joehuang at huawei.com]\nSent: Wednesday, October 01, 2014 6:56 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\n\nHello,  Alex,\n\nThank you very much for your mail about remote cluster hypervisor.\n\nOne of the inspiration for OpenStack cascading is from the remote clustered hypervisor like vCenter. The difference between the remote clustered hypervisor and OpenStack cascading is that not only Nova involved in the cascading, but also Cinder, Neutron, Ceilometer, and even Glance(optional).\n\nPlease refer to https://wiki.openstack.org/wiki/OpenStack_cascading_solution#Inspiration,\nhttps://wiki.openstack.org/wiki/OpenStack_cascading_solution#Architecture for more detail information.\n\nBest Regards\n\nChaoyi Huang ( joehuang )\n\n________________________________\nFrom: Alex Glikson [GLIKSON at il.ibm.com]\nSent: 01 October 2014 12:51\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\nThis sounds related to the discussion on the \'Nova clustered hypervisor driver\' which started at Juno design summit [1]. Talking to another OpenStack should be similar to talking to vCenter. The idea was that the Cells support could be refactored around this notion as well.\nNot sure whether there have been any active progress with this in Juno, though.\n\nRegards,\nAlex\n\n\n[1] http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c#<http://junodesignsummit.sched.org/event/a0d38e1278182eb09f06e22457d94c0c>\n[2] https://etherpad.openstack.org/p/juno-nova-clustered-hypervisor-support\n\n\n\n\nFrom:        joehuang <joehuang at huawei.com<mailto:joehuang at huawei.com>>\nTo:        \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate:        30/09/2014 04:08 PM\nSubject:        [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading\n________________________________\n\n\n\nHello, Dear TC and all,\n\nLarge cloud operators prefer to deploy multiple OpenStack instances(as different zones), rather than a single monolithic OpenStack instance because of these reasons:\n\n1) Multiple data centers distributed geographically;\n2) Multi-vendor business policy;\n3) Server nodes scale up modularized from 00\'s up to million;\n4) Fault and maintenance isolation between zones (only REST interface);\n\nAt the same time, they also want to integrate these OpenStack instances into one cloud. Instead of proprietary orchestration layer, they want to use standard OpenStack framework for Northbound API compatibility with HEAT/Horizon or other 3rd ecosystem apps.\n\nWe call this pattern as \"OpenStack Cascading\", with proposal described by [1][2]. PoC live demo video can be found[3][4].\n\nNova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the OpenStack cascading.\n\nKindly ask for cross program design summit session to discuss OpenStack cascading and the contribution to Kilo.\n\nKindly invite those who are interested in the OpenStack cascading to work together and contribute it to OpenStack.\n\n(I applied for ?other projects? track [5], but it would be better to have a discussion as a formal cross program session, because many core programs are involved )\n\n\n[1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution\n[2] PoC source code: https://github.com/stackforge/tricircle\n[3] Live demo video at YouTube: https://www.youtube.com/watch?v=OSU6PYRz5qY\n[4] Live demo video at Youku (low quality, for those who can\'t access YouTube)?http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html\n[5] http://www.mail-archive.com/openstack-dev at lists.openstack.org/msg36395.html\n\nBest Regards\nChaoyi Huang ( Joe Huang )\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141002/f66b0bfc/attachment.html>\n\n','<5E7A3D1BF5FD014E86E5F971CF446EFF541CA4B6@szxema505-mbx.china.huawei.com>',NULL),('<0EFA67D6-D35A-4F48-9AAD-1583030D0B1F@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 12:12:04',-25200,'2014-09-25 19:12:04',NULL,'[openstack-dev] Thoughts on OpenStack Layers and a Big Tent\n	model','\nOn Sep 24, 2014, at 10:55 AM, Zane Bitter <zbitter at redhat.com> wrote:\n\n> On 18/09/14 14:53, Monty Taylor wrote:\n>> Hey all,\n>> \n>> I\'ve recently been thinking a lot about Sean\'s Layers stuff. So I wrote\n>> a blog post which Jim Blair and Devananda were kind enough to help me edit.\n>> \n>> http://inaugust.com/post/108\n> \n> I think there are a number of unjustified assumptions behind this arrangement of things. I\'m going to list some here, but I don\'t want anyone to interpret this as a personal criticism of Monty. The point is that we all suffer from biases - not for any questionable reasons but purely as a result of our own experiences, who we spend our time talking to and what we spend our time thinking about - and therefore we should all be extremely circumspect about trying to bake our own mental models of what OpenStack should be into the organisational structure of the project itself.\n\nI think there were some assumptions that lead to the Layer1 model. Perhaps a little insight into the in-person debate[1] at OpenStack-SV might help explain where monty was coming from.\n\nThe initial thought was a radical idea (pioneered by Jay) to completely dismantle the integrated release and have all projects release independently and functionally test against their real dependencies. This gained support from various people and I still think it is a great long-term goal.\n\nThe worry that Monty (and others) had are two-fold:\n\n1. When we had no co-gating in the past, we ended up with a lot of cross-project breakage. If we jump right into this we could end up in the wild west were different projects expect different keystone versions and there is no way to deploy a functional cloud.\n2. We have set expectations in our community (and especially with distributions), that we release a set of things that all work together. It is not acceptable for us to just pull the rug out from under them.\n\nThese concerns show that we must (in the short term) provide some kind of integrated testing and release. I see the layer1 model as a stepping stone towards the long term goal of having the projects release independently and depend on stable interfaces. We aren?t going to get there immediately, so having a smaller, integrated set of services representing our most common use case seems like a good first step. As our interfaces get more stable and our testing gets better it could move to a (once every X months) release that just packages the current version of the layer1 projects or even be completely managed by distributions.\n\nWe need a way to move forward, but I?m hoping we can do it without a concept of ?specialness? around layer1 projects. I actually see it as a limitation of these projects that we have to take this stepping stone and cannot disaggregate completely. Instead it should be seen as a necessary evil so that we don?t break our users.\n\nIn addition, we should encourage other shared use cases in openstack both for testing (functional tests against groups of services) and for releases (shared releases of related projects).\n\n[1] Note this wasn?t a planned debate, but a spontaneous discussion that included (at various points) Monty Taylor, Jay Pipes, Joe Gordon, John Dickenson, Myself, and (undoubtedly) one or two people I?m forgetting.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/a02f9abe/attachment.pgp>\n\n','<542305AD.802@redhat.com>',NULL),('<0EFAD0EB-5FB1-48E0-B70F-0F770E1C3957@icloud.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 19:41:22',28800,'2013-11-15 11:41:22',NULL,'[openstack-dev] [Horizon] Use icon set instead of instance Action','Hi all\n\nWould you consider to change the drop-down action list of a instances to some common button icon set? \n\nSome actions like ?run, pause, restart, shutdown, terminate ?, even like \"create Snapshot\", can use button instead? which like the pic below:\n\n\n\nThink icon set may has better user experience.\n\nRegards\nGarry\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/6c46df79/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screen Shot 2013-11-15 at 4.09.08 PM.png\nType: image/png\nSize: 18657 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/6c46df79/attachment.png>\n\n',NULL,NULL),('<0EFAD2CE-4F80-4762-80F5-7085DF736D43@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 14:32:27',-14400,'2014-09-08 18:32:27',NULL,'[openstack-dev] [oslo] Anticipated Final Release Versions for Juno','I spent some time today looking over our current set of libraries trying to anticipate which will be ready for 1.0 (or later) and which are still considered pre-release. I came up with this set of anticipated version numbers for our final juno releases. Please let me know if you see any surprises on the list.\n\n1.0 or later\n\noslo.config - 1.4.0\noslo.i18n - 1.0.0\noslo.messaging - 1.4.0\noslo.rootwrap - 1.3.0\noslo.serialization - 1.0.0\noslosphinx - 2.2.0\noslotest - 1.1.0\noslo.utils - 1.0.0\ncliff - 1.7.x\nstevedore - 1.0.0\n\nAlphas or Pre-releases (Trying for 1.0 for Kilo)\n\noslo.concurrency - < 1.0\noslo.log - 0.1.0\noslo.middleware - 0.1.0\npbr - < 1.0\ntaskflow - < 1.0\n\nUnknown\n\noslo.db - I think we said 1.0.0 but I need to confirm.\noslo.vmware - I?ll need to talk to the vmware team to see where things stand with their release plans.\n\n\n\n\n',NULL,NULL),('<0EFB587C-03F5-46DB-A53D-C91C2DA22E38@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-30 17:54:01',0,'2013-03-30 17:54:01',NULL,'[openstack-dev] [Openstack] Announcing Climate,\n OpenStack Capacity Leasing project','Interested. Will post. Cheer!\n\n~sean\n\nOn Mar 25, 2013, at 9:49 AM, \"Julien Danjou\" <julien at danjou.info> wrote:\n\n> Hi there,\n> \n> I\'d like to announce a new project named Climate.\n> \n> The project\n> aims to provide a capacity leasing service inside OpenStack\n> cloud platforms,\n> via the reservation of various resources in a calendar\n> based view.\n> \n> The\n> project is still as its early draft stage, but anyone with ideas\n> and\n> interest is welcome!\n> \n> Homepage:\n> https://launchpad.net/climate\n> \n> Cheers,\n> --\n> Julien Danjou\n> ;; Free Software\n> hacker ; freelance consultant\n> ;; http://julien.danjou.info\n> \n> \n> <ATT00001.bin>\n> <ATT00002.txt>\n\n\n','<<87hajz8lyq.fsf@dex.adm.naquadah.org>>',NULL),('<0F07E503-931F-4838-8235-F4CC9408C8E2@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-18 12:08:49',-25200,'2014-04-18 19:08:49',NULL,'[Openstack] RDO cinder upgrading havana to icehouse','Interesting solution I m curious to see if it works. I do not see why but maybe code changed to much to make it seamless. \n\n \nInviato da iPhone (?)\n\n> Il giorno Apr 18, 2014, alle ore 11:51, Dimitri Maziuk <dmaziuk at bmrb.wisc.edu> ha scritto:\n> \n> Hi all,\n> \n> I\'m thinking of adding a cinder storage node to our centos 6/rdo/havana\n> setup & I wonder if I should go icehouse on that. Anyone tried mixing\n> icehouse cinder storage node w/ havana controller (and the rest)? Any\n> gotchas or reasons I shouldn\'t do that?\n> \n> TIA\n> -- \n> Dimitri Maziuk\n> Programmer/sysadmin\n> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,535176a833621865462940!\n\n\n','<53517435.6090807@bmrb.wisc.edu>',NULL),('<0F0BB0CBD263A74DA32AFD20A58A097E3AA95066@000S-EX-MBX-QS4.unimelb.edu.au>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-09-23 13:12:24',0,'2012-09-23 13:12:24',NULL,'[Openstack-docs] Config option wrangling for Folsom','Hi all,\n\nIf anyone\'s looking for an easy job to do, there are a ton of configuration options that are missing from the documentation right now.\n\nI\'ve updated these spreadsheets to mark in red the ones currently missing from the docs:\n\n* Swift: https://docs.google.com/spreadsheet/ccc?key=0ArysOOuLgF_PdFV0cFV2VkE2WkZUY1RNYjZBd204a0E\n* Glance: https://docs.google.com/spreadsheet/ccc?key=0ArysOOuLgF_PdFU1ZUdnUFpzcmxkaXVoMkpKVGEwOGc\n* Nova: https://docs.google.com/spreadsheet/ccc?key=0ArysOOuLgF_PdF9MNVFrUngwUjhPbnlfbFc2eDFSYWc\n\nIt\'s a pretty straightforward task: \n1. Find a config option on the spreadsheet\n2. Gather information about what it does (and default values) from the code project (grep -R <option> works usually!)\n3. Put it into the appropriate section in the docs, submit the patch\n\n\nIt would be great to get as many of these done before the release as possible, but it just takes so much time! :)\n\nIf you need any help setting up an environment to do all of this, let us know. Thanks for reading!\n\n\nRegards,\n\nTom\n\n\n',NULL,NULL),('<0F0BB0CBD263A74DA32AFD20A58A097E621798FE@000S-EX-MBX-QS4.unimelb.edu.au>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-03-12 10:59:25',0,'2013-03-12 10:59:25',NULL,'[Openstack-docs] Doc Team meeting Tuesday 1300 UTC\n #openstack-meeting','If my time zone math is correct, the meeting is in 2 hours time - see you there!\n\nRegards,\n\nTom\n________________________________\nFrom: annegentle at justwriteclick.com [annegentle at justwriteclick.com] on behalf of Anne Gentle [anne at openstack.org]\nSent: Tuesday, 12 March 2013 12:42 AM\nTo: Tom Fifield\nCc: openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Doc Team meeting Tuesday 1300 UTC #openstack-meeting\n\nYep, #openstack-meeting because it has the ability to help us take notes.\n\nAnne\n\n\nOn Mon, Mar 11, 2013 at 12:25 AM, Tom Fifield <fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>> wrote:\nWiki is at:\n\nhttp://wiki.openstack.org/Meetings/DocTeamMeeting\n\nJust confirming - we\'re meeting at #openstack-meeting, rather than the\nnew #openstack-docs, unless otherwise advised ...\n\nRegards,\n\nTom\n\nOn 11/03/13 15:01, Anne Gentle wrote:\n> Hi all,\n>\n> We will hold our monthly Doc Team meeting this week on IRC at 1300. With\n> the time change be on the alert for what that means in your time zone,\n> for me it means an 8:00am start which means surely I can be on time. :)\n>\n> Looking forward to it,\n> Anne\n\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org<mailto:Openstack-docs at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130312/e6a05465/attachment.html>\n\n','<CAD0KtVHLur3gh1Ba7j3Ht7iSigmqGHKnydqqYxo8EMB=7sKp3Q@mail.gmail.com>',NULL),('<0F0BB0CBD263A74DA32AFD20A58A097E623517A2@000S-EX-MBX-QS4.unimelb.edu.au>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-05-14 01:21:17',0,'2013-05-14 01:21:17',NULL,'[Openstack-docs] Tom\'s Tables','Hi Joe,\n\nThanks for starting the discussion. Also looping in Anne\'s and Lorin\'s comments.\n\n\n  *   * Should there be the ability to override or append the description of an option in case the current description is not clear? Or should the proper fix be to patch the source file where the option is defined?\n\nI think the only sustainable way to do this is for the source code to be the definitive place for the option text. For Grizzly we might have to fake it, but I believe that for Havana we (plus the entire developer army) need to be patching the strings in the code, before the string freeze sets in.\n\n\n  *   * [ What about ] the ability to group configuration options into \"config sets\" such as an \"HA config set requires these options\" or \"A Quantum agent needs these\".\n\nSo, the initial manual groupings took some work, but were fairly straightforward since each has a single group (where options are in multiple groups, they have multiple entries). There is the potential to expand on this infinitely, and to some degree it will make sense. However, I believe the most important aspect of this work is sustainability, and it would be my desire that eventually the manually created group mappings are derived from code - meaning the entire process could be automated. There is functionality in oslo.config that could be used to start this work. Until that happens, however, we\'re free to play to see what groupings make sense :)\n\n\n  *   If possible, can the script put a <!-- --> comment in the XML at the top of the file to indicate the source file?\n\nI found this comment a little ambiguous, so I\'m assuming: what is desired is for the ability to find where a particular option is defined in the code of the product from which it comes. Each table typically has multiple places in the code used to make it, so it would need to be per-option, rather than per table. Unfortunately, the short term answer here is no. When pulling in a module\'s config you tend to pull in those of every other module in the product that the particular module relies on, so it\'s not possible to split stuff out by file without some work. Personally, I just grep -R <option_name> * ;)\n\n\n\n  *   Comments about \"context\" of options.\n\nAnne made some comments about specific options in OpenStack Networking such as \"host\" or \"server auth\". I believe that the solution here is just to fix the crap text, pure and simple. So far I have lodged several bugs about missing or misleading option text and got good response from developers involved - again along the idea that we shouldn\'t have to do all of this ourselves.\n\n\nI also believe that this configuration tables should - at a minimum - be included in a file with a paragraph at the top that has an context-providing explanation. \"These are the options for the CISCO Quantum Plugin.\n\n\nThis plugin implementation provides the following capabilities:\n\n    A reference implementation for a Quantum Plugin Framework (For details see: http://wiki.openstack.org/quantum-multi-switch-plugin)\n     Supports multiple switches in the network\n     Supports multiple models of switches concurrently\n     Supports use of multiple L2 technologies\n     Supports the Cisco Nexus family of switches (Verified with Nexus 3000, 5000 and 7000 series)\n    If you are using a Nexus switch in your topology, you\'ll need the following NX-OS version and packages to enable Nexus support:\n         NX-OS 5.2.1 (Delhi) Build 69 or above.\n        paramiko library - SSHv2 protocol library for python\n        ncclient v0.3.1 - Python library for NETCONF clients\"\n\n\n\n  *\n\nI think this is a good idea, to point out what information is missing.\n\nYes, indeed - and this is I think where our work is. Instead of constantly fixing things ourselves, we should be (I have been already, yay) lodging bugs about missing/misleading text.\n\n\n\nHTH!\n\n\n\n\n\nRegards,\n\n\nTom\n________________________________\nFrom: Joe Topjian [joe.topjian at cybera.ca]\nSent: Tuesday, 14 May 2013 1:18 AM\nTo: openstack-docs at lists.openstack.org\nSubject: [Openstack-docs] Tom\'s Tables\n\nHello,\n\nI figured I\'d send an email about Tom\'s table creation rather than commenting on each (or just one) of the patch sets that he submitted.\n\nI think the tables are great. Even if they were published as they are right now, I think just having the ability to create accurate tables like that is a great feature.\n\nShould there be the ability to override or append the description of an option in case the current description is not clear? Or should the proper fix be to patch the source file where the option is defined? I can see pros and cons to both. Pro being a single source of information. Con being the amount of time/effort it would take to backport a description to an older release.\n\nThe only thing I find missing from the tables is how they can be used beyond a reference point (although beyond a reference point is more of a \"feature request\"). Looking through Tom\'s github repo, I see that the groupings have to be done manually. I\'m curious about what others would think about expanding on that idea. For example, the ability to group configuration options into \"config sets\" such as an \"HA config set requires these options\" or \"A Quantum agent needs these\".\n\nThanks,\nJoe\n\n--\nJoe Topjian\nSystems Administrator\nCybera Inc.\n\nwww.cybera.ca<http://www.cybera.ca>\n\nCybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130514/5ac05aa7/attachment.html>\n\n','<CAD07=De8eiRf8vamdU=YTN+3hFYfwB4hRygrpXzw-K5H=7cauw@mail.gmail.com>',NULL),('<0F0BB0CBD263A74DA32AFD20A58A097E623527A1@000S-EX-MBX-QS4.unimelb.edu.au>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-05-14 02:39:41',0,'2013-05-14 02:39:41',NULL,'[Openstack-docs] Tom\'s Tables','One important clarification I need to make is that these aren\'t actually just \"Tom\'s Tables\" ;)\n\nI\'ve had some awesome help from Steven Deaton at Rackspace, who\'s been cleaning and extending my poor-quality original code and doing a ton of conceptual work.\n\nThanks, Steven :)\n\n\nRegards,\n\nTom\n\n\n________________________________\nFrom: Tom Fifield [fifieldt at unimelb.edu.au]\nSent: Tuesday, 14 May 2013 11:21 AM\nTo: Joe Topjian; openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] Tom\'s Tables\n\nHi Joe,\n\nThanks for starting the discussion. Also looping in Anne\'s and Lorin\'s comments.\n\n\n  *   * Should there be the ability to override or append the description of an option in case the current description is not clear? Or should the proper fix be to patch the source file where the option is defined?\n\nI think the only sustainable way to do this is for the source code to be the definitive place for the option text. For Grizzly we might have to fake it, but I believe that for Havana we (plus the entire developer army) need to be patching the strings in the code, before the string freeze sets in.\n\n\n  *   * [ What about ] the ability to group configuration options into \"config sets\" such as an \"HA config set requires these options\" or \"A Quantum agent needs these\".\n\nSo, the initial manual groupings took some work, but were fairly straightforward since each has a single group (where options are in multiple groups, they have multiple entries). There is the potential to expand on this infinitely, and to some degree it will make sense. However, I believe the most important aspect of this work is sustainability, and it would be my desire that eventually the manually created group mappings are derived from code - meaning the entire process could be automated. There is functionality in oslo.config that could be used to start this work. Until that happens, however, we\'re free to play to see what groupings make sense :)\n\n\n  *   If possible, can the script put a <!-- --> comment in the XML at the top of the file to indicate the source file?\n\nI found this comment a little ambiguous, so I\'m assuming: what is desired is for the ability to find where a particular option is defined in the code of the product from which it comes. Each table typically has multiple places in the code used to make it, so it would need to be per-option, rather than per table. Unfortunately, the short term answer here is no. When pulling in a module\'s config you tend to pull in those of every other module in the product that the particular module relies on, so it\'s not possible to split stuff out by file without some work. Personally, I just grep -R <option_name> * ;)\n\n\n\n  *   Comments about \"context\" of options.\n\nAnne made some comments about specific options in OpenStack Networking such as \"host\" or \"server auth\". I believe that the solution here is just to fix the crap text, pure and simple. So far I have lodged several bugs about missing or misleading option text and got good response from developers involved - again along the idea that we shouldn\'t have to do all of this ourselves.\n\n\nI also believe that this configuration tables should - at a minimum - be included in a file with a paragraph at the top that has an context-providing explanation. \"These are the options for the CISCO Quantum Plugin.\n\n\nThis plugin implementation provides the following capabilities:\n\n    A reference implementation for a Quantum Plugin Framework (For details see: http://wiki.openstack.org/quantum-multi-switch-plugin)\n     Supports multiple switches in the network\n     Supports multiple models of switches concurrently\n     Supports use of multiple L2 technologies\n     Supports the Cisco Nexus family of switches (Verified with Nexus 3000, 5000 and 7000 series)\n    If you are using a Nexus switch in your topology, you\'ll need the following NX-OS version and packages to enable Nexus support:\n         NX-OS 5.2.1 (Delhi) Build 69 or above.\n        paramiko library - SSHv2 protocol library for python\n        ncclient v0.3.1 - Python library for NETCONF clients\"\n\n\n\n  *\n\nI think this is a good idea, to point out what information is missing.\n\nYes, indeed - and this is I think where our work is. Instead of constantly fixing things ourselves, we should be (I have been already, yay) lodging bugs about missing/misleading text.\n\n\n\nHTH!\n\n\n\n\n\nRegards,\n\n\nTom\n________________________________\nFrom: Joe Topjian [joe.topjian at cybera.ca]\nSent: Tuesday, 14 May 2013 1:18 AM\nTo: openstack-docs at lists.openstack.org\nSubject: [Openstack-docs] Tom\'s Tables\n\nHello,\n\nI figured I\'d send an email about Tom\'s table creation rather than commenting on each (or just one) of the patch sets that he submitted.\n\nI think the tables are great. Even if they were published as they are right now, I think just having the ability to create accurate tables like that is a great feature.\n\nShould there be the ability to override or append the description of an option in case the current description is not clear? Or should the proper fix be to patch the source file where the option is defined? I can see pros and cons to both. Pro being a single source of information. Con being the amount of time/effort it would take to backport a description to an older release.\n\nThe only thing I find missing from the tables is how they can be used beyond a reference point (although beyond a reference point is more of a \"feature request\"). Looking through Tom\'s github repo, I see that the groupings have to be done manually. I\'m curious about what others would think about expanding on that idea. For example, the ability to group configuration options into \"config sets\" such as an \"HA config set requires these options\" or \"A Quantum agent needs these\".\n\nThanks,\nJoe\n\n--\nJoe Topjian\nSystems Administrator\nCybera Inc.\n\nwww.cybera.ca<http://www.cybera.ca>\n\nCybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130514/5d827c48/attachment-0001.html>\n\n','<0F0BB0CBD263A74DA32AFD20A58A097E623517A2@000S-EX-MBX-QS4.unimelb.edu.au>',NULL),('<0F1F99F4-B514-4615-894A-856502E0661A@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-20 14:51:12',-18000,'2014-11-20 19:51:12',NULL,'[openstack-dev] Where should Schema files live?','\nOn Nov 20, 2014, at 8:12 AM, Sandy Walsh <sandy.walsh at rackspace.com> wrote:\n\n> Hey y\'all,\n> \n> To avoid cross-posting, please inform your -infra / -operations buddies about this post. \n> \n> We\'ve just started thinking about where notification schema files should live and how they should be deployed. Kind of a tricky problem.  We could really use your input on this problem ...\n> \n> The assumptions:\n> 1. Schema files will be text files. They\'ll live in their own git repo (stackforge for now, ideally oslo eventually). \n\nWhy wouldn?t they live in the repo of the application that generates the notification, like we do with the database schema and APIs defined by those apps?\n\n> 2. Unit tests will need access to these files for local dev\n> 3. Gating tests will need access to these files for integration tests\n> 4. Many different services are going to want to access these files during staging and production. \n> 5. There are going to be many different versions of these files. There are going to be a lot of schema updates. \n> \n> Some problems / options:\n> a. Unlike Python, there is no simple pip install for text files. No version control per se. Basically whatever we pull from the repo. The problem with a git clone is we need to tweak config files to point to a directory and that\'s a pain for gating tests and CD. Could we assume a symlink to some well-known location?\n>    a\': I suppose we could make a python installer for them, but that\'s a pain for other language consumers.\n> b. In production, each openstack service could expose the schema files via their REST API, but that doesn\'t help gating tests or unit tests. Also, this means every service will need to support exposing schema files. Big coordination problem.\n> c. In production, We could add an endpoint to the Keystone Service Catalog to each schema file. This could come from a separate metadata-like service. Again, yet-another-service to deploy and make highly available. \n> d. Should we make separate distro packages? Install to a well known location all the time? This would work for local dev and integration testing and we could fall back on B and C for production distribution. Of course, this will likely require people to add a new distro repo. Is that a concern?\n> \n> Personally, I\'m leaning towards option D but I\'m not sure what the implications are. \n> \n> We\'re early in thinking about these problems, but would like to start the conversation now to get your opinions. \n> \n> Look forward to your feedback.\n> \n> Thanks\n> -Sandy\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A535151D@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0F200976-BADA-49AC-87FF-C180A788A823@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-02 19:23:19',0,'2013-12-02 19:23:19',NULL,'[openstack-dev] VMware Workstation / Fusion / Player Nova driver','\nOn 02 Dec 2013, at 04:52 , Kyle Mestery (kmestery) <kmestery at cisco.com> wrote:\n\n> On Dec 1, 2013, at 4:10 PM, Alessandro Pilotti <apilotti at cloudbasesolutions.com> wrote:\n>> \n>> Hi all,\n>> \n>> At Cloudbase we are heavily using VMware Workstation and Fusion for development, demos and PoCs, so we thought: why not replacing our automation scripts with a fully functional Nova driver and use OpenStack APIs and Heat for the automation? :-)\n>> \n>> Here?s the repo for this Nova driver project: https://github.com/cloudbase/nova-vix-driver/\n>> \n>> The driver is already working well and supports all the basic features you?d expect from a Nova driver, including a VNC console accessible via Horizon. Please refer to the project README for additional details.\n>> The usage of CoW images (linked clones) makes deploying images particularly fast, which is a good thing when you develop or run demos. Heat or Puppet, Chef, etc make the whole process particularly sweet of course. \n>> \n>> \n>> The main idea was to create something to be used in place of solutions like Vagrant, with a few specific requirements:\n>> \n>> 1) Full support for nested virtualization (VMX and EPT).\n>> \n>> For the time being the VMware products are the only ones supporting Hyper-V and KVM as guests, so this became a mandatory path, at least until EPT support will be fully functional in KVM.\n>> This rules out Vagrant as an option. Their VMware support is not free and beside that they don?t support nested virtualization (yet, AFAIK). \n>> \n>> Other workstation virtualization options, including VirtualBox and Hyper-V are currently ruled out due to the lack of support for this feature as well.\n>> Beside that Hyper-V and VMware Workstation VMs can work side by side on Windows 8.1, all you need is to fire up two nova-compute instances.\n>> \n>> 2) Work on Windows, Linux and OS X workstations\n>> \n>> Here?s a snapshot of Nova compute  running on OS X and showing Novnc connected to a Fusion VM console:\n>> \n>> https://dl.dropboxusercontent.com/u/9060190/Nova-compute-os-x.png\n>> \n>> 3) Use OpenStack APIs\n>> \n>> We wanted to have a single common framework for automation and bring OpenStack on the workstations. \n>> Beside that, dogfooding is a good thing. :-) \n>> \n>> 4) Offer a free alternative for community contributions\n>> \n>> VMware Player is fair enough, even with the ?non commercial use? limits, etc.\n>> \n>> Communication with VMware components is based on the freely available Vix SDK libs, using ctypes to call the C APIs. The project provides a library to easily interact with the VMs, in case it sould be needed, e.g.:\n>> \n>> from vix import vixutils\n>> with vixutils.VixConnection() as conn:\n>>    with conn.open_vm(vmx_path) as vm:\n>>        vm.power_on()\n>> \n>> We though about using libvirt, since it has support for those APIs as well, but it was way easier to create a lightweight driver from scratch using the Vix APIs directly.\n>> \n>> TODOs:\n>> \n>> 1) A minimal Neutron agent for attaching networks (now all networks are attached to the NAT interface).\n>> 2) Resize disks on boot based on the flavor size\n>> 3) Volume attach / detach (we can just reuse the Hyper-V code for the Windows case)\n>> 4) Same host resize\n>> \n>> Live migration is not making particularly sense in this context, so the implementation is not planned. \n>> \n>> Note: we still have to commit the unit tests. We?ll clean them during next week and push them.\n>> \n>> \n>> As usual, any idea, suggestions and especially contributions are highly welcome!\n>> \n>> We?ll follow up with a blog post with some additional news related to this project quite soon. \n>> \n>> \n> This is very cool Alessandro, thanks for sharing! Any plans to try and get this\n> nova driver upstreamed?\n\nThanks Kyle!\n\nMy personal opinion is that drivers should stay outside of Nova in a separate project. Said that, this driver is way easier to mantain than the Hyper-V one for example, so I wouldn?t have objections if this is what the community prefers.\nOn the other side, this driver will hardly have a CI as it?s not a requirement for the expected usage and this wouldn?t fit with the current (correct IMO) decision that only drivers with a CI gate will stay in Nova starting with Icehouse.\nSaid that, I would?t have of course anything against somebody (VMware?) volunteering for the CI. ;-)\n\nIMO, as also Chmouel suggested in this thread, a Stackforge project could be a good start. This should make it easier for people to contribute and we?ll have a couple of release cycles to decide what to do with it.\n\nAlessandro\n\n\n> Thanks,\n> Kyle\n> \n>> Thanks,\n>> \n>> Alessandro\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<BEB6CEB9-B64F-425C-A4FC-AF140852F13A@cisco.com>',NULL),('<0F21D0B1-B322-4667-A74B-BA77BBFBEF5B@leafe.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 08:30:01',-21600,'2015-01-20 14:30:01',NULL,'[openstack-dev] [gantt] Scheduler sub-group meeting agenda 1/70','On Jan 20, 2015, at 12:07 AM, Dugger, Donald D <donald.d.dugger at intel.com> wrote:\n> \n> Note, I expect we?ll spend most of the time talking about 1.  If we can come to agreement on that BP I?ll be ecstatic.\n\nAnd if we can\'t, it will be very difficult, if not impossible, to get the spec freeze exception.\n\n\n-- Ed Leafe\n\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150120/06ed504d/attachment.pgp>\n\n','<6AF484C0160C61439DE06F17668F3BCB5348B865@ORSMSX114.amr.corp.intel.com>',NULL),('<0f2a0d4b43ec00fdbd719200cc40ac79@mail.gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 16:49:25',19800,'2014-02-28 11:19:25',NULL,'[openstack-dev] openstack java sdk','Hi,\n\nPlease check following link for maven artifacts.\nhttp://mvnrepository.com/artifact/com.woorea/openstack-java-sdk/3.2.1\nInclude this in your maven project pom.xml.\n\nHowever if you need latest one download and compile your-self as it\ncontains lot of fixes on top of above ones.\n\nThanks,\nMurali G D\n\n-----Original Message-----\nFrom: rash g [mailto:rashg164 at gmail.com]\nSent: Friday, February 28, 2014 4:13 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] openstack java sdk\n\nHello,\n        I am working on a project which uses openstack.I want to connect\nmy java code to openstack.For that I was thinking of using openstack-java\nsdk.But I did not find any jar files for the same to import in my java\ncode.\n        Can anyone tell me where I can get jar files for openstack-java\nsdk?\n\nThanks,\nRashmi\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAsbHRwM+72zP2bBid8gELVi3nmktnEPjTdwnohj=BCA-GBePA@mail.gmail.com>',NULL),('<0f3301cf0d71$15a16d00$40e44700$@inaugust.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-01-09 11:29:15',-28800,'2014-01-09 19:29:15',NULL,'[OpenStack-Infra] Laptop stolen, please disable my ssh keys','Hey guys!\n\nMy laptop was stolen from a car in the middle of San Fran. I\'m 99% sure it\nwill be broken down and sold for parts as part of the drug trade, so I\'m not\nACTUALLY concerned with someone hacking information off of it.\n\nHOWEVER - better safe than sorry. So would someone in infra-core please\nremove my ssh keys from the ability to do anything. As soon as I get back up\nand going with a new real laptop, I\'ll re-submit a patch adding a new key\nback.\n\nThanks!\nMonty\n\n\n\n',NULL,NULL),('<0F4070EF-E1E0-4C33-9A2A-0A87F59ACAFD@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 23:15:19',0,'2014-02-07 23:15:19',NULL,'[openstack-dev] [python-openstacksdk] Initial meeting scheduling','Hi Everyone:\n	Circling back to the client tools / SDK discussion - we?ve gotten a critical mass of people involved/interesting in the unified/common SDK back end for application developers and other end-users. From the wiki page:\n\n	\"This is a proposed OpenStack project that is designed to improve the experience of OpenStack end-users by consolidating the various OpenStack python-* client back-ends and common code into a unified, well designed and user focused SDK (\"Software Development Toolkit?).?\n\n	Given the interest many have expressed, we feel it?s time to kick off an initial meeting to discuss design, goals and other things that are pertinent prior to all of us running off and coding. \n\nWe have not determined the date/time for the meeting, and have instead set up a doodle to find a time slice that can maximize participation:\n\nhttp://doodle.com/qe6v2ssr28x8urqe\n\nAgenda:\n	https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK\n\nThe Wiki pages are still in development, but give a high level view of what problem we are trying to solve, and the target audience. Feedback, thoughts, etc are *greatly* welcome. We?re still sorting through mounds of mail threads discussing things and taking things into account.\n\nWiki Pages:\n	https://wiki.openstack.org/wiki/PythonOpenStackSDK\n	https://wiki.openstack.org/wiki/SDK-Development\n\nCode:\n	https://github.com/stackforge/python-openstacksdk\n\n\nJesse\n\n',NULL,NULL),('<0F4301C6-796B-4277-BC11-F72B30A20217@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-23 23:50:21',25200,'2013-12-23 16:50:21',NULL,'[openstack-dev] [Mistral] Community meeting minutes - 12/23/2013','Hi,\n\nHere the links to minutes and logs for the IRC meeting that we had today:\n\nMinutes: http://eavesdrop.openstack.org/meetings/mistral/2013/mistral.2013-12-23-16.00.html\nLog: http://eavesdrop.openstack.org/meetings/mistral/2013/mistral.2013-12-23-16.00.log.html\n\nFeel free to join us next time.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131223/391f72c0/attachment.html>\n\n',NULL,NULL),('<0F45CF5B-A350-447C-B517-1CBC96E1EFC4@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-31 22:54:57',7200,'2013-07-31 20:54:57',NULL,'[Openstack-docs] Welcome Stephen Gordon to docs-core','Hi Stephen, and welcome!\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 31 juil. 2013 ? 20:10, Anne Gentle <anne at openstack.org> a ?crit :\n\n> Hi all, \n> Stephen Gordon has been doing a great job with reviews and I\'ve invited him to join docs-core. Thanks for bringing more RedHat to docs!\n> Anne\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130731/154dff31/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130731/154dff31/attachment-0001.jpg>\n\n','<CAD0KtVFUmJA3tNhAEw4OMWAwDyt6Jdq1OBNW==NKp+9v7UfZPA@mail.gmail.com>',NULL),('<0F473699-C0FB-40DC-BA73-87EF05504918@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-24 22:25:34',25200,'2014-10-24 15:25:34',NULL,'[openstack-dev] [mistral] New screencasts for Mistral 0.1','Hi,\n\nIn addition to MIstral 0.1.1 bugfix release here are the first two videos from the series of screencasts that we started this week aiming to highlight new functionality introduced in Mistral 0.1 released in the end of Sept.\n\nMIstral 0.1, part 1: http://www.youtube.com/watch?v=9kaac_AfNow <http://www.youtube.com/watch?v=9kaac_AfNow>\nMIstral 0.1, part 2: http://www.youtube.com/watch?v=u6ki_DIpsg0 <http://www.youtube.com/watch?v=u6ki_DIpsg0>\n\nMore screencasts coming soon...\n\nThanks\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/0aa0f922/attachment.html>\n\n',NULL,NULL),('<0F4C4221-21EC-466E-B114-B6BA2E2B69AA@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 08:40:50',0,'2014-02-24 08:40:50',NULL,'[openstack-dev] Win 2008 R2 VMDK upload to glance','Hi,\n\nDid you install the VMWare tools and sysprepped the image before adding it to Glance?\n\nHere\'s how we automate the creation of Windows OpenStack images for KVM, Hyper-V and VMWare (unattended setup, hypervisor drivers, windows updates, Cloudbase-Init and sysprep):\n\nhttps://github.com/cloudbase/windows-openstack-imaging-tools\n\nMore details:\n\nhttp://www.cloudbase.it/create-windows-openstack-images/\n\nAlessandro\n\n> On 24.02.2014, at 09:29, \"Abhishek Soni\" <virtualserver4 at gmail.com> wrote:\n> \n> Hi All,\n> \n> I wanted to upload a new Win 2k8 R2 VMDK file to glance. \n> \n> I have created a new windows VM with 20 GB hdd on ESXi 5.1 and then uploaded the flat file to Glance. But when ever VM boots from openstack, it goes to recovery mode.\n> \n> Any help or point to correct solution document will be of great help! I am facing this issue only with Windows VMs.\n> \n> Thanks!\n> \n> Abhishek\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CANr-iLg99fvW46xTddz+DFmyQ2aksytw3a-ZWNFNcT42L30Qow@mail.gmail.com>',NULL),('<0F5776D8-60FF-4F62-9F44-5E4D1CE1D28E@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 15:22:52',0,'2014-10-14 15:22:52',NULL,'[openstack-dev] [api] Forming the API Working Group','On Oct 14, 2014, at 8:57 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> I personally think proposing patches to an openstack-api repository is the most effective way to make those proposals. Etherpads and wiki pages are fine for dumping content, but IMO, we don\'t need to dump content -- we already have plenty of it. We need to propose guidelines for *new* APIs to follow.\n\n+1\n\nI?m all for putting a stake in the ground (in the form of docs in a repo) and having people debate that. I think it results in a much more focused discussion as opposed to dumping content into an etherpad/wiki page and trying to wade through it. If people want to dump content somewhere and use that to help inform their contributions to the repo, that?s okay too.\n\nAnother big benefit of putting things in a repo is provenance. Guidelines like these can be...contentious...at times. Having a clear history of how a guideline got into a repo is very valuable as you can link newcomers who challenge a guideline to the history of how it got there, who approved it, and the tradeoffs that were considered during the review process. Of course, this is possible with etherpad/wiki too but it?s more difficult to reconstruct the history.\n\nEverett\n\n\n\n','<543D2BAD.5050600@gmail.com>',NULL),('<0F57BD0A-8D0F-4879-8DD0-335E26BD0199@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 11:49:56',0,'2014-05-27 11:49:56',NULL,'[openstack-dev] How to implement and configure a new Neutron\n vpnaas driver from scratch?','\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn May 25, 2014, at 3:09 PM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n\n> Hi again.\n> \n> You were right, I was committing 2 mistakes. One, was not adding q-vpn service to my localrc (newbie error) and two, I had some python errors. Everything is solved, now my devstack boots using my plugin (service driver and device driver)!!! I\'m experiencing some problems, but now they are related with code. Anyway, these errors are good news, because now I need to develop my plugin, m first original goal.\n> \n> Taking as reference Cisco IPsec plugin, I see this code in device driver file, line 547 (https://github.com/openstack/neutron/blob/master/neutron/services/vpn/device_drivers/ipsec.py#L547):\n\nPCM: Actually, that is the code for the reference (OpenSwan) implementation of IPsec driver (file cisco_ipsec.py is the Cisco device driver)\n\n\n> \n> \n> \n>     @abc.abstractmethod\n> \n> \n>     def create_process(self, process_id, vpnservice, namespace):\n> \n> \n>         pass\n> \n> \n> \n> \n> \n> It is simply an abstract method, and obviously, it is not possible to instantiate a class with abstract methods. So I got this error when I tried to reboot q-vpn service:\n> \n> CRITICAL neutron [req-ead47120-c5c0-4db2-b2b3-3ae58b047e63 None None] Can\'t instantiate abstract class VPNaaSDriver with abstract methods create_process\n> \n> It is difficult to me developing a VPN plugin, specially the connection between service driver and device driver. How can Cisco IPsec plugin work with this code? Do I need to extend neutron.services.vpn.device_drivers.DeviceDriver class as they do?\n\nPCM: The Cisco plugin doesn?t use this code. What is done here, is that they have an IPSec class with all of the ?generic? functionality, except for create_process(), which is implemented in a subclass that creates an OpenSwan process: https://github.com/openstack/neutron/blob/master/neutron/services/vpn/device_drivers/ipsec.py#L708. I think this was done at a time when there was a StrongSwan and OpenSwan implementation for the reference and there was some transitioning between the two versions. I think StrongSwan was initially selected and then a change was made to use OpenSwan for the final solution.\n\nEssentially, you have full control of the implementation for the service and device drivers, and can implement any protocol/method desired.  For the reference implementation, it uses a signal and sync mechanism, and then has processes to handle the VPN connection. For the Cisco implementation, the same signal and sync (currently) is used, and then a REST client is used to talk to the Cisco CSR to handle the VPN connection.\n\nRegards,\n\nPCM\n\n\n\n> \n> Once again, thank you very much Paul.\n> \n> Regards,\n>  \n> \n> \n> \n> \n> \n> Julio C. Barrera Juez\n> Office phone: +34 93 357 99 27\n> Distributed Applications and Networks Area (DANA)\n> i2CAT Foundation, Barcelona, Spain\n> http://dana.i2cat.net\n> \n> \n> On 22 May 2014 18:15, Paul Michali (pcm) <pcm at cisco.com> wrote:\n> \n> On May 22, 2014, at 10:06 AM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n> \n>> OK, I modified my neutron.conf file adding your service_plugins line (and commenting the old ones). I unstacked clear, stacked again, applied both files and restarted q-svc and q-l3, but VPN plugin seems to be not applied at all.\n> \n> By ?applied both files? do you mean you modified the /etc/neutron/neutron.conf and /etc/neutron/vpn_agent.ini files after stacking?\n> \n> \n>> These lines continue appearing in q-svc log file:\n>> \n>> 2014-05-22 06:53:08.523 DEBUG neutron.service [-] service_plugins                = [\'neutron.services.l3_router.l3_router_plugin.L3RouterPlugin\'] from (pid=15626) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py:1952\n>> \n>> May I restart other services?\n> \n> What I do is:\n> \n> 1) Make sure that localrc has q-vpn service enabled  (my guess is that you are missing this!)\n> 2) Ensure that /opt/stack/neutron/etc/vpn_agent.ini has my device driver line included\n> 3) Apply the following patch to devstack, so that my service driver is automatically selected (you can replace with yours) when DevStack starts things up:\n> \n> patch -p 1 << EOT\n> diff --git a/lib/neutron b/lib/neutron\n> index 02dcaf6..452281b 100644\n> --- a/lib/neutron\n> +++ b/lib/neutron\n> @@ -728,6 +728,7 @@ function _configure_neutron_fwaas {\n>  function _configure_neutron_vpn {\n>      neutron_vpn_install_agent_packages\n>      neutron_vpn_configure_common\n> +    neutron_vpnaas_configure_driver\n>  }\n> \n>  # _configure_neutron_plugin_agent() - Set config files for neutron plugin agent\n> diff --git a/lib/neutron_plugins/services/vpn b/lib/neutron_plugins/services/vpn\n> index d920ba6..a676fdc 100644\n> --- a/lib/neutron_plugins/services/vpn\n> +++ b/lib/neutron_plugins/services/vpn\n> @@ -18,6 +18,10 @@ function neutron_vpn_configure_common {\n>      _neutron_service_plugin_class_add $VPN_PLUGIN\n>  }\n> \n> +function neutron_vpnaas_configure_driver() {\n> +    iniset_multiline $NEUTRON_CONF service_providers service_provider \"VPN:cisco:neutron.services.vpn.service_drivers.cisco_ipsec.CiscoCsrIPsecVPNDriver:default\"\n> +}\n> +\n>  function neutron_vpn_stop {\n>      local ipsec_data_dir=$DATA_DIR/neutron/ipsec\n>      local pids\n> EOT\n> \n> 4) Run stack.sh\n> 5) Check screen-q-svc.log to ensure service_plugins has VPN plugin and it is loaded, service_providers has my service provider and it is loaded.\n> 6) Check screen-q-vpn.log to ensure that my device driver is there.\n> \n> HTHs,\n> \n> PCM (Paul Michali)\n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pcm_ (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n>> \n>> \n>> \n>> Julio C. Barrera Juez\n>> Office phone: +34 93 357 99 27\n>> Distributed Applications and Networks Area (DANA)\n>> i2CAT Foundation, Barcelona, Spain\n>> http://dana.i2cat.net\n>> \n>> \n>> On 22 May 2014 13:15, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>> One difference I see in log is that with my setup, I see:\n>> \n>> 2014-05-22 10:53:13.107 20564 DEBUG routes.middleware [-] Matched GET /vpn/vpnservices.json __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:100\n>> 2014-05-22 10:53:13.108 20564 DEBUG routes.middleware [-] Route path: \'/vpn/vpnservices.:(format)\', defaults: {\'action\': u\'index\', \'controller\': <wsgify at 58423632 wrapping <function resource at 0x37b8050>>} __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:102\n>> 2014-05-22 10:53:13.108 20564 DEBUG routes.middleware [-] Match dict: {\'action\': u\'index\', \'controller\': <wsgify at 58423632 wrapping <function resource at 0x37b8050>>, \'format\': u\'json\'} __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:103\n>> 2014-05-22 10:53:13.113 20564 INFO neutron.wsgi [req-81180687-3173-4960-b33d-9031c5e57f74 None] 14.0.3.33 - - [22/May/2014 10:53:13] \"GET /v2.0/vpn/vpnservices.json HTTP/1.1\" 200 208 0.020912\n>> \n>> Whereas, in your log I see:\n>> \n>> 2014-05-22 03:26:33.427  [00;32mDEBUG routes.middleware [ [00;36m- [00;32m]  [01;35m [00;32mNo route matched for GET /vpn/vpnservices.json [00m  [00;33mfrom (pid=37367) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:97 [00m\n>> 2014-05-22 03:26:33.436  [00;32mDEBUG routes.middleware [ [00;36m- [00;32m]  [01;35m [00;32mNo route matched for GET /vpn/vpnservices.json [00m  [00;33mfrom (pid=37367) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:97 [00m\n>> 2014-05-22 03:26:33.444  [00;36mINFO neutron.wsgi [ [01;36mreq-d9a6b5c3-4165-4c9f-83c0-1e87f3d43749  [00;36madmin 4e7b8bf6fcfd47028fd63b0bd2f943b3 [00;36m]  [01;35m [00;36m127.0.0.1 - - [22/May/2014 03:26:33] \"GET /v2.0/vpn/vpnservices.json HTTP/1.1\" 404 242 0.235507\n>>  [00m\n>> It looks like you don?t have the VPN plugin enabled. In neutron.conf, you should have:\n>> \n>> service_plugins = neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron.services.vpn.plugin.VPNDriverPlugin\n>> service_provider = VPN:junos_vpnaas:neutron.services.vpn.junos_vpnaas.service_drivers.vpnaas_service_driver.VPNaaSServiceDriver:default\n>> \n>> The log provided does not show the VPN plugin...\n>> \n>> 2014-05-22 03:22:56.071  [00;32mDEBUG neutron.service [ [00;36m- [00;32m]  [01;35m [00;32mservice_plugins                = [\'neutron.services.l3_router.l3_router_plugin.L3RouterPlugin\'] [00m  [00;33mfrom (pid=37367) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py:1952 [00m\n>> 2014-05-22 03:22:56.076  [00;32mDEBUG neutron.service [ [00;36m- [00;32m]  [01;35m [00;32mservice_providers.service_provider = [\'VPN:junos_vpnaas:neutron.services.vpn.junos_vpnaas.service_drivers.vpnaas_service_driver.VPNaaSServiceDriver:default\'] [00m  [00;33mfrom (pid=37367) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py:1960 [00m\n>> \n>> So the requests are never getting to the core VPN plugin code (let along getting to your service driver).\n>> \n>> \n>> Regards,\n>> \n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pcm_ (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> On May 22, 2014, at 6:31 AM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>> \n>>> Thank you for your dedication Paul.\n>>> \n>>> I forgot to edit these file, you were right. I modified it and now I see in the log:\n>>> \n>>> 2014-05-22 03:22:56.076 [00;32mDEBUG neutron.service [ [00;36m- [00;32m] [01;35m [00;32mservice_providers.service_provider = [\'VPN:junos_vpnaas:neutron.services.vpn.junos_vpnaas.service_drivers.vpnaas_service_driver.VPNaaSServiceDriver:default\'] [00m [00;33mfrom (pid=37367) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py:1960 [00m\n>>> \n>>> This is just my configuration, it seems correct. but I continue getting this:\n>>> \n>>> neutron vpn-service-list\n>>> 404 Not Found\n>>> \n>>> The resource could not be found.\n>>> \n>>> This is my log file: http://pastebin.com/raw.php?i=6SZ2Xatg\n>>> \n>>> I don\'t know how to proceed, this is being a nightmare to me...\n>>> \n>>> Regards,\n>>> \n>>> \n>>> Julio C. Barrera Juez\n>>> Office phone: +34 93 357 99 27\n>>> Distributed Applications and Networks Area (DANA)\n>>> i2CAT Foundation, Barcelona, Spain\n>>> http://dana.i2cat.net\n>>> \n>>> \n>>> On 21 May 2014 18:19, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>> You have to have your service driver specified (as default) in neutron.conf, and your device_driver specified in vpn_agent.ini. For the former, you can either modify it after the devstack run and then restart the server, or you can tweak the devstack scripts to modify neutron.conf and add in the service driver. For the device driver, you can modify it in /opt/stack/neutron/etc/vpn_agent.ini and it?ll get copied to /etc/neutron/ with the change.\n>>> \n>>> The log below only shows the reference service driver:\n>>> \n>>> 2014-05-21 08:28:46.703  [00;32mDEBUG neutron.service [ [00;36m- [00;32m]  [01;35m [00;32mservice_providers.service_provider = [\'LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default\', \'VPN:openswan:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default\'] [00m  [00;33mfrom (pid=2199) log_opt_values /usr/local/lib/python2.7/dist-packages/oslo/config/cfg.py:1960 [00m\n>>> \n>>> PCM (Paul Michali)\n>>> \n>>> MAIL ?..?. pcm at cisco.com\n>>> IRC ??..? pcm_ (irc.freenode.com)\n>>> TW ???... @pmichali\n>>> GPG Key ? 4525ECC253E31A83\n>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>> \n>>> \n>>> \n>>> On May 21, 2014, at 11:43 AM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>> \n>>>> First of all, excuse me for the silent days. I have made some changes in my devstack instance. I took current master branch of devstack repository and applied your patch to it with my plugin files defined (see it in GitHub https://github.com/logoff/devstack/tree/junos-vpnaas). I used a localrc file like this: http://pastebin.com/dE5bYkTE and when I execute this command, it works:\n>>>> \n>>>> neutron subnet-list\n>>>> +--------------------------------------+----------------+---------------+------------------------------------------------+\n>>>> | id                                   | name           | cidr          | allocation_pools                               |\n>>>> +--------------------------------------+----------------+---------------+------------------------------------------------+\n>>>> | 7f8e23ef-be53-423e-8fb9-ea6b4f2b5d6b | private-subnet | 10.254.1.0/24 | {\"start\": \"10.254.1.2\", \"end\": \"10.254.1.254\"} |\n>>>> | f3b85fcc-1c01-4ac8-9950-1f45157c6887 | public-subnet  | 172.24.4.0/24 | {\"start\": \"172.24.4.2\", \"end\": \"172.24.4.254\"} |\n>>>> +--------------------------------------+----------------+---------------+------------------------------------------------+\n>>>> \n>>>> but when I execute this command, it fails:\n>>>> \n>>>> neutron vpn-service-list\n>>>> 404 Not Found\n>>>> \n>>>> The resource could not be found.\n>>>> \n>>>>    \n>>>> Here you can find my q-svc log file (it is big, only 10 minutes of execution: http://pastebin.com/raw.php?i=hqBzg8ED\n>>>> I can not see my plugin anywhere. What do I need to do to achieve adding my single provider VPNaaS plugin to a devstack instance?\n>>>> \n>>>> \n>>>> Julio C. Barrera Juez\n>>>> Office phone: +34 93 357 99 27\n>>>> Distributed Applications and Networks Area (DANA)\n>>>> i2CAT Foundation, Barcelona, Spain\n>>>> http://dana.i2cat.net\n>>>> \n>>>> \n>>>> On 9 May 2014 14:33, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>>> Not really sure from the log snippet. Can you make available the full log (not sure where you can post it)?\n>>>> \n>>>> The q-svc log should indicate that your service driver was found and loaded.\n>>>> \n>>>> \n>>>> PCM (Paul Michali)\n>>>> \n>>>> MAIL ?..?. pcm at cisco.com\n>>>> IRC ??..? pcm_ (irc.freenode.com)\n>>>> TW ???... @pmichali\n>>>> GPG Key ? 4525ECC253E31A83\n>>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>>> \n>>>> \n>>>> \n>>>> On May 6, 2014, at 3:13 PM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>>> \n>>>>> Hi!\n>>>>> \n>>>>> First of all thnak you for your guidance.\n>>>>> \n>>>>> I have followed your instructions with Cisco CSR VPN plugin and my not finished plugin. I got same results on both cases\n>>>>> I invoked this command on CLI:\n>>>>> \n>>>>> neutron vpn-service-list\n>>>>> \n>>>>> and the result was:\n>>>>> \n>>>>> 404 Not Found\n>>>>> \n>>>>> The resource could not be found.\n>>>>> \n>>>>> Looking in the log of q-svc I see:\n>>>>> \n>>>>> \n>>>>> 02014-05-06 12:05:04.119 INFO neutron.wsgi [req-8e9b50d1-4f6a-4f32-aa3d-db792ba744d5 admin 1798cd11ee304907aa463e6fea7a09bb] (3743) accepted (\'10.0.1.10\', 52672)\n>>>>> \n>>>>> 2014-05-06 12:05:04.119 DEBUG keystoneclient.middleware.auth_token [-] Authenticating user token from (pid=3743) __call__ /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:603\n>>>>> 2014-05-06 12:05:04.120 DEBUG keystoneclient.middleware.auth_token [-] Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role from (pid=3743) _remove_auth_headers /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:662\n>>>>> 2014-05-06 12:05:04.138 DEBUG keystoneclient.middleware.auth_token [-] Storing token in cache from (pid=3743) _cache_put /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:1121\n>>>>> 2014-05-06 12:05:04.139 DEBUG keystoneclient.middleware.auth_token [-] Received request from user: cbf59516f8c64a10966b0df843a58608 with project_id : 1798cd11ee304907aa463e6fea7a09bb and roles: admin  from (pid=3743) _build_user_headers /opt/stack/python-keystoneclient/keystoneclient/middleware/auth_token.py:910\n>>>>> 2014-05-06 12:05:04.140 DEBUG routes.middleware [-] No route matched for GET /vpn/vpnservices.json from (pid=3743) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:97\n>>>>> 2014-05-06 12:05:04.140 DEBUG routes.middleware [-] No route matched for GET /vpn/vpnservices.json from (pid=3743) __call__ /usr/lib/python2.7/dist-packages/routes/middleware.py:97\n>>>>> 2014-05-06 12:05:04.148 INFO neutron.wsgi [req-481d6f8b-c0f4-4862-965f-a0468c37a582 admin 1798cd11ee304907aa463e6fea7a09bb] 10.0.1.10 - - [06/May/2014 12:05:04] \"GET /v2.0/vpn/vpnservices.json HTTP/1.1\" 404 176 0.028534\n>>>>> \n>>>>> I don\'t know why the service was \"Not found\".\n>>>>> \n>>>>> May you give me some help to solve this problem?\n>>>>> \n>>>>> Thank you.\n>>>>> \n>>>>> \n>>>>> \n>>>>> Julio C. Barrera Juez\n>>>>> Office phone: +34 93 357 99 27\n>>>>> Distributed Applications and Networks Area (DANA)\n>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>> http://dana.i2cat.net\n>>>>> \n>>>>> \n>>>>> On 28 April 2014 14:10, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>>>> \n>>>>> On Apr 26, 2014, at 7:39 AM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>>>> \n>>>>>> I\'m trying to configure any VPNaaS plugin in single-provider mode. I\'m not able to achieve this goal. I\'m using a devstack installation and I\'m editing /etc/neutron/neutron.conf file, modifying this line:\n>>>>>> \n>>>>>> ...\n>>>>>> service_provider=VPN:cisco_csr:neutron.services.vpn.service_drivers.ipsec.IPsecVPNDriver:default\n>>>>>> ...\n>>>>>> \n>>>>>> and /etc/neutron/vpn_agent.ini modifyin gthis line:\n>>>>>> \n>>>>>> ...\n>>>>>> vpn_device_driver=neutron.services.vpn.device_drivers.ipsec.IPsecDriver?\n>>>>> \n>>>>> PCM: So what are you modifying these lines to? Are they pointing to valid modules?\n>>>>> \n>>>>> \n>>>>>> \n>>>>>> I\'m not sure if this configuration is OK. I have some doubts:\n>>>>>> \n>>>>>> - Is this configuration a valid one taking into account that plugin are available in Python modules path?\n>>>>> \n>>>>> PCM: Sorry, I don?t understand what you?re asking here.\n>>>>> \n>>>>> \n>>>>>> - Where are the log files located to check valid neutron configuration?\n>>>>> \n>>>>> PCM: There is a variable in DevStacks localrc to set where the logs are placed. For example:\n>>>>> \n>>>>> SCREEN_LOGDIR=/opt/stack/screen-logs\n>>>>> \n>>>>> I don?t know what the default is (disabled?).\n>>>>> \n>>>>> \n>>>>>> - What services should I restart each time I change this configuration?\n>>>>> \n>>>>> PCM: q-svc for the service_driver, and q-vpn for the device_driver (and maybe q-aft?).\n>>>>> \n>>>>> \n>>>>> What I do, is modify vpn_agent.ini in /opt/stack/neutron/etc/ and then, using a newer DevStack that has my commit for VPN (https://review.openstack.org/#/c/86567/), /etc/neutron/vpn_agent.ini will be set with the desired device driver and that will be loaded at start up.\n>>>>> \n>>>>> Also, I do a patch to DevStack?s lib/neutron and lib/neutron_plugins/services/vpn to setup neutron.conf as well, so that, again, /etc/neutron/neutron.conf is set up and stack.sh will do the right thing. The patch is:\n>>>>> \n>>>>> patch -p 1 << EOT\n>>>>> diff --git a/lib/neutron b/lib/neutron\n>>>>> index 02dcaf6..452281b 100644\n>>>>> --- a/lib/neutron\n>>>>> +++ b/lib/neutron\n>>>>> @@ -728,6 +728,7 @@ function _configure_neutron_fwaas {\n>>>>>  function _configure_neutron_vpn {\n>>>>>      neutron_vpn_install_agent_packages\n>>>>>      neutron_vpn_configure_common\n>>>>> +    neutron_vpnaas_configure_driver\n>>>>>  }\n>>>>> \n>>>>>  # _configure_neutron_plugin_agent() - Set config files for neutron plugin agent\n>>>>> diff --git a/lib/neutron_plugins/services/vpn b/lib/neutron_plugins/services/vpn\n>>>>> index d920ba6..a676fdc 100644\n>>>>> --- a/lib/neutron_plugins/services/vpn\n>>>>> +++ b/lib/neutron_plugins/services/vpn\n>>>>> @@ -18,6 +18,10 @@ function neutron_vpn_configure_common {\n>>>>>      _neutron_service_plugin_class_add $VPN_PLUGIN\n>>>>>  }\n>>>>> \n>>>>> +function neutron_vpnaas_configure_driver() {\n>>>>> +    iniset_multiline $NEUTRON_CONF service_providers service_provider \"VPN:cisco:neutron.services.vpn.service_drivers.cisco_ipsec.CiscoCsrIPsecVPNDriver:default\"\n>>>>> +}\n>>>>> +\n>>>>>  function neutron_vpn_stop {\n>>>>>      local ipsec_data_dir=$DATA_DIR/neutron/ipsec\n>>>>>      local pids\n>>>>> EOT\n>>>>> \n>>>>> \n>>>>> Regards,\n>>>>> \n>>>>> \n>>>>> PCM (Paul Michali)\n>>>>> \n>>>>> MAIL ?..?. pcm at cisco.com\n>>>>> IRC ??..? pcm_ (irc.freenode.com)\n>>>>> TW ???... @pmichali\n>>>>> GPG Key ? 4525ECC253E31A83\n>>>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>>>> \n>>>>> \n>>>>>> \n>>>>>> Thank you very much.\n>>>>>> \n>>>>>> \n>>>>>> Julio C. Barrera Juez\n>>>>>> Office phone: +34 93 357 99 27\n>>>>>> Distributed Applications and Networks Area (DANA)\n>>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>>> http://dana.i2cat.net\n>>>>>> \n>>>>>> \n>>>>>> On 24 April 2014 16:14, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>>>>>> Not sure I quite understand the question, but to configuring VPNaaS in single provider mode, from a user?s perspective is the same (see api.openstack.org).\n>>>>>> \n>>>>>> To bring up a cloud that uses a different vendor?s service and device driver, you need to modify neutron.conf to select the vendor?s service driver (as the default driver), instead of the reference driver, and in vpn_agent.ini you select the vendor?s device driver (instead of or in addition to the reference implementation, doesn?t matter, as it pairs with the service driver).\n>>>>>> \n>>>>>> HTHs,\n>>>>>> \n>>>>>> \n>>>>>> PCM (Paul Michali)\n>>>>>> \n>>>>>> MAIL ?..?. pcm at cisco.com\n>>>>>> IRC ??..? pcm_ (irc.freenode.com)\n>>>>>> TW ???... @pmichali\n>>>>>> GPG Key ? 4525ECC253E31A83\n>>>>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> On Apr 24, 2014, at 3:13 AM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>>>>> \n>>>>>>> OK, thank you guys, I understood that it was not possible to configure and make work any VPNaaS plugin. I don\'t care, by now, because it works in single-provider mode. I knew about the Cisco implementation, but I don\'t know how to configure it, because I didn\'t find enough documentation about that topic. I need some help on the basics configuring a VPNaaS plugin in single provider mode, because I only found information about it in 3rd party blog posts, etc.\n>>>>>>> \n>>>>>>> What are the basic steps?\n>>>>>>> \n>>>>>>> Thank you again.\n>>>>>>> \n>>>>>>> \n>>>>>>> Julio C. Barrera Juez\n>>>>>>> Office phone: +34 93 357 99 27\n>>>>>>> Distributed Applications and Networks Area (DANA)\n>>>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>>>> http://dana.i2cat.net\n>>>>>>> \n>>>>>>> \n>>>>>>> On 18 April 2014 10:50, Bo Lin <linb at vmware.com> wrote:\n>>>>>>> Hi Julio,\n>>>>>>> +1 for Paul\'s response. Multiple-provider VPNaaS support is delayed. But you can take https://review.openstack.org/#/c/74156/ and https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas driver without multi-provider support. If any questions or problems in your codes leading to not work, just upload your codes onto the review board, we can find how to solve it :).\n>>>>>>> \n>>>>>>> Thanks!\n>>>>>>> ---Bo\n>>>>>>> \n>>>>>>> \n>>>>>>> From: \"Paul Michali (pcm)\" <pcm at cisco.com>\n>>>>>>> \n>>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>>>>>>> Sent: Friday, April 11, 2014 2:15:18 AM\n>>>>>>> \n>>>>>>> Subject: Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?\n>>>>>>> \n>>>>>>> By not ?working? do you mean you cannot get the plugin to work in a multi-provider environment? Multi-provider solutions have been tabled until Juno, where more discussion is occurring on what is the best way to support different service providers.\n>>>>>>> \n>>>>>>> However, you should be able to get the plugin to work as the ?sole? VPN service provider, which is what the Cisco solution does currently. You can look at how I?ve done that in the cisco_ipsec.py modules in the service_drivers and device_drivers directories, under neutron/services/vpn/.\n>>>>>>> \n>>>>>>> \n>>>>>>> Regards,\n>>>>>>> \n>>>>>>> PCM (Paul Michali)\n>>>>>>> \n>>>>>>> MAIL ?..?. pcm at cisco.com\n>>>>>>> IRC ??..? pcm_ (irc.freenode.com)\n>>>>>>> TW ???... @pmichali\n>>>>>>> GPG Key ? 4525ECC253E31A83\n>>>>>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> On Apr 10, 2014, at 1:51 PM, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>>>>>> \n>>>>>>> Hi.\n>>>>>>> \n>>>>>>> After 8 months of the patch creation and being abandoned weeks ago (https://review.openstack.org/#/c/41827/) I still don\'t how can we develop a VPNaaS plugin following Bo Lin instructions. Is there any other patch trying to solve the problem? Is there any way to workaround the issue to get a VPNaaS plugin working?\n>>>>>>> \n>>>>>>> Thank you!\n>>>>>>> \n>>>>>>> \n>>>>>>> Julio C. Barrera Juez\n>>>>>>> Office phone: +34 93 357 99 27\n>>>>>>> Distributed Applications and Networks Area (DANA)\n>>>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>>>> http://dana.i2cat.net\n>>>>>>> \n>>>>>>> \n>>>>>>> On 27 February 2014 10:51, Bo Lin <linb at vmware.com> wrote:\n>>>>>>> Hi Julio,\n>>>>>>> You can take https://review.openstack.org/#/c/74156/ and https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas driver. More info about service type framework, you can also refer to neutron/services/loadbalancer codes.\n>>>>>>> \n>>>>>>> From: \"Julio Carlos Barrera Juez\" <juliocarlos.barrera at i2cat.net>\n>>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>>>>>>> Sent: Thursday, February 27, 2014 5:26:32 PM\n>>>>>>> Subject: Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?\n>>>>>>> \n>>>>>>> \n>>>>>>> I\'m following the change you pointed a week ago. It seems that it is working now, and will be eventually approved soon. I will be happy when it is approved.\n>>>>>>> \n>>>>>>> Anyway, I need more information about how to develop a service driver and a device driver for VPN plugin. I realize doing reverse-engineering that I need and RPC agent and and RPC between them to communicate and use a kind of callbacks to answer. Where I can find documentation about it and some examples? Is there any best practise guide of the use of this architecture?\n>>>>>>> \n>>>>>>> Thank you again!\n>>>>>>> \n>>>>>>> \n>>>>>>> Julio C. Barrera Juez\n>>>>>>> Office phone: +34 93 357 99 27\n>>>>>>> Distributed Applications and Networks Area (DANA)\n>>>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>>>> http://dana.i2cat.net\n>>>>>>> \n>>>>>>> \n>>>>>>> On 19 February 2014 09:13, Julio Carlos Barrera Juez <juliocarlos.barrera at i2cat.net> wrote:\n>>>>>>> Thank you very much Bo. I will try all your advices and check if it works!\n>>>>>>> \n>>>>>>> \n>>>>>>> Julio C. Barrera Juez\n>>>>>>> Office phone: +34 93 357 99 27\n>>>>>>> Distributed Applications and Networks Area (DANA)\n>>>>>>> i2CAT Foundation, Barcelona, Spain\n>>>>>>> http://dana.i2cat.net\n>>>>>>> \n>>>>>>> \n>>>>>>> On 18 February 2014 09:18, Bo Lin <linb at vmware.com> wrote:\n>>>>>>> I wonder whether your neutron server codes have added the \" VPNaaS integration with service type framework\" change on https://review.openstack.org/#/c/41827/21 , if not, the service_provider option is useless. You need to include the change before developing your own driver.\n>>>>>>> \n>>>>>>> QA (In my opinion and sth may be missing):\n>>>>>>> - What is the difference between service drivers and device drivers?\n>>>>>>>     service drivers are driven by vpn service plugin and are responsible for casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent.\n>>>>>>>     device drivers are driven by vpn agent and are responsible for implementing specific vpn operations and report vpn running status.\n>>>>>>> \n>>>>>>> - Could I implement only one of them?\n>>>>>>>     device driver must be implemented based on your own device. Unless the default ipsec service driver is definitely appropriate, suggest you implement both of them. After including \"VPNaaS integration with service type framework\", the service driver work is simple. \n>>>>>>> \n>>>>>>> - Where I need to put my Python implementation in my OpenStack instance?\n>>>>>>>    Do you mean let your instance runs your new codes? The default source codes dir is /opt/stack/neutron, you need to put your new changes into the dir and restart the neutron server.\n>>>>>>> \n>>>>>>> - How could I configure my OpenStack instance to use this implementation?\n>>>>>>>    1.  Add your new codes into source dir\n>>>>>>>    2. Add appropriate vpnaas service_provider into neutron.conf and add appropriate \"vpn_device_driver\" option into vpn_agent.ini\n>>>>>>>    3. restart n-svc and q-vpn\n>>>>>>> \n>>>>>>> Hope help you.\n>>>>>>> \n>>>>>>> From: \"Julio Carlos Barrera Juez\" <juliocarlos.barrera at i2cat.net>\n>>>>>>> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n>>>>>>> Sent: Monday, February 17, 2014 7:18:44 PM\n>>>>>>> Subject: [openstack-dev] How to implement and configure a new Neutron vpnaas        driver from scratch?\n>>>>>>> \n>>>>>>> \n>>>>>>> Hi.\n>>>>>>> \n>>>>>>> I have asked in the Q&A website without success (https://ask.openstack.org/en/question/12072/how-to-implement-and-configure-a-new-vpnaas-driver-from-scratch/).\n>>>>>>> \n>>>>>>> I want to develop a vpnaas implementation. It seems that since Havana, there are plugins, services and device implementations. I like the plugin and his current API, then I don\'t need to reimplement it. Now I want yo implement a vpnaas driver, and I see I have two main parts to take into account: the service_drivers and the device_drivers. IPsec/OpenSwan implementation is the unique sample I\'ve found.\n>>>>>>> \n>>>>>>> I\'m using devstack to test my experiments.\n>>>>>>> \n>>>>>>> I tried to implement VpnDriver Python class extending the main API methods like IPsecVPNDriver does. I placed basic implementation files at the same level of IPsec/OpenSwan does and configured Neutron adding this line to /etc/neutron/neutron.conf file:\n>>>>>>> \n>>>>>>> service_provider = VPN:VPNaaS:neutron.services.vpn.service_drivers.our_python_filename.OurClassName:default\n>>>>>>> \n>>>>>>> I restarted Neutron related services in my devstack instance, but it seemed it didn\'t work.\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> - What is the difference between service drivers and device drivers?\n>>>>>>> - Could I implement only one of them?\n>>>>>>> - Where I need to put my Python implementation in my OpenStack instance?\n>>>>>>> - How could I configure my OpenStack instance to use this implementation?\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> I didn\'t find almost any documentation about these topics.\n>>>>>>> \n>>>>>>> Thank you very much.\n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=9uhm%2F59JRfiZ3CXzuhBOpqcTqWk8APswRGJFZ8H2Tos%3D%0A&s=46fe06049efb1d29a85b63f7ce101cd69695a368c3da6ea3a91bcd7d2b71ce59\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=YmmNfPyv1TNDbHlwFZT9xRPhyBxsQW%2B2aJ3daQ8RC%2BI%3D%0A&s=638a7f219d00817d3d17746251a9b5090cce130fed11727be8a4cabd09754657\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=1%2FHmRV%2F3ce%2Bjpzxjfyhv6xjuBhiOBVrajFVFZjco9Zw%3D%0A&s=d81bebe644cccedf66fedc084cf34c54e82b5a62712e12d1b5e2c6c1c6ee2c81\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>>> \n>>>>>>> \n>>>>>>> _______________________________________________\n>>>>>>> OpenStack-dev mailing list\n>>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/2aa09ab8/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/2aa09ab8/attachment-0001.pgp>\n\n','<CA+oBjp-1VxcfCjACY-E1SD_WKMa39hab9BM4o8W3CS2DVcSFrg@mail.gmail.com>',NULL),('<0f5abf0018b744729fd18218e26fa672@BY2PR03MB144.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-10 07:11:29',0,'2014-02-10 07:11:29',NULL,'[openstack-dev] [Neutron] Service VM: irc discussion?','Hi Isaku Yamahata,\n\nWe are at UTC+5.30.[IST]\n\nRegards,\nBalaji.P\n\n> -----Original Message-----\n> From: i y [mailto:yamahataml at gmail.com] On Behalf Of Isaku Yamahata\n> Sent: Monday, February 10, 2014 12:36 PM\n> To: P Balaji-B37839; OpenStack Development Mailing List (not for usage\n> questions)\n> Cc: Isaku Yamahata\n> Subject: Re: [openstack-dev] [Neutron] Service VM: irc discussion?\n> \n> What\'s your timezone?\n> 18.00UTC doesn\'t work for me because my timezone is UTC+9 and it\'s\n> 3:00AM.\n> \n> thanks,\n> \n> On Mon, Feb 10, 2014 at 06:43:05AM +0000, \"Balaji.P at freescale.com\"\n> <Balaji.P at freescale.com> wrote:\n> \n> > Hi Isaku Yamahata,\n> >\n> > Is it possible to move the below time slot a little earlier like\n> 18.00UTC?\n> >\n> > Regards,\n> > Balaji.P\n> >\n> > > -----Original Message-----\n> > > From: i y [mailto:yamahataml at gmail.com] On Behalf Of Isaku Yamahata\n> > > Sent: Monday, February 10, 2014 11:42 AM\n> > > To: openstack-dev at lists.openstack.org\n> > > Cc: isaku.yamahata at gmail.com\n> > > Subject: [Neutron] Service VM: irc discussion?\n> > >\n> > > As the first patch for service vm framework is ready for\n> > > review[1][2], it would be a good idea to have IRC meeting.\n> > > Anyone interested in it? How about schedule?\n> > >\n> > > Schedule candidate\n> > > Monday  22:00UTC-, 23:00UTC-\n> > > Tuesday 22:00UTC-, 23:00UTC-\n> > > (Although the slot of servanced service vm[3] can be resuled,  it\n> > > doesn\'t work for me because my timezone is UTC+9.)\n> > >\n> > > topics for\n> > > - discussion/review on the patch\n> > > - next steps\n> > > - other open issues?\n> > >\n> > > [1]\n> > > https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms\n> > > [2] https://review.openstack.org/#/c/56892/\n> > > [3] https://wiki.openstack.org/wiki/Meetings/AdvancedServices\n> > > --\n> > > Isaku Yamahata <isaku.yamahata at gmail.com>\n> > >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> --\n> Isaku Yamahata <isaku.yamahata at gmail.com>\n> \n\n\n\n','<20140210070536.GC9673@private.email.ne.jp>',NULL),('<0F714C07-0389-46F7-9984-8973DBD7464D@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-07 21:53:57',-28800,'2012-11-08 05:53:57',NULL,'[openstack-dev] The future of Incubation and Core','Here\'s an alternative OpenStack Core project definition:\n\nOpenStack Core projects:\n 1) provide the API and implementation for compute, storage, or network infrastructure-as-a-service\n 2) may be deployed independently\n 3) cooperate to provide a unified OpenStack release\n 4) must be scalable from small private clouds to large public service providers\n\n\n\n--John\n\n\n\nOn Nov 7, 2012, at 8:40 AM, Thierry Carrez <thierry at openstack.org> wrote:\n\n> Hi everyone,\n> \n> Incubation is currently an OpenStack project status that grants a\n> promising project more access to OpenStack shared resources, especially\n> in the CI, release management and QA space. That status lets the\n> promising project prove that it is ready to join other official\n> OpenStack core projects for the next full development cycle.\n> \n> In the past governance the Project Policy Board was the only decider on\n> Incubation and Core inclusion. With the new governance, the Technical\n> Committee is still the only decider on Incubation status and still\n> proposes projects for Core inclusion, but the Board of Directors has the\n> possibility to veto that Core inclusion.\n> \n> This creates an awkward process where a project could go all the way\n> through Incubation and be denied Core inclusion at the end of that\n> process, basically wasting OpenStack resources. We need to evolve the\n> Incubation process so that the question of whether a project belongs in\n> \"Core\" is fully resolved as early as possible. And define how a project\n> can enter, grow or exit the incubation process.\n> \n> This also raises the question of whether \"Core\" should really be the\n> only destination of an Incubated project. Which triggers the very\n> question of what OpenStack Core actually is. For some it\'s the\n> collection of OpenStack projects that work well and complement each\n> other, for others Core should only include the IaaS pieces, for others\n> they should represent the bare minimum you need to implement to be able\n> to be called an \"OpenStack Cloud\"...\n> \n> Once \"Core\" is defined we can evaluate the need for a category that\n> would still be in \"OpenStack\" but not have the \"Core\" label on it.\n> Incubation could then lead two ways.\n> \n> We need to discuss all this in the next two weeks before delegates of\n> the TC will join a committee with Board of Directors delegates to come\n> to a final decision on this. So let the public discussion begin.\n> \n> Cheers,\n> \n> -- \n> Thierry Carrez (ttx)\n> Chair, OpenStack Technical Committee\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4329 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121107/d9459d49/attachment.bin>\n\n','<509A8F09.8000004@openstack.org>',NULL),('<0f7b0cdc62764104b3fb8c8c3dad5d18@hioexcmbx05-prd.hq.netapp.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-16 17:51:26',0,'2014-06-16 17:51:26',NULL,'[OpenStack-Infra] NetApp CI access','Hi,\n    To set up our external 3rd party CI we had opened a bug https://bugs.launchpad.net/openstack-ci/+bug/1284808 It seemed to have been closed but our CI initial connectivity tests are failing. I am furnishing the info again to make sure things get in place.\n\n\nEmail address: xdl-openstack-jenkins at netapp.com\nAccount username: netapp-ci\nA longer name: NetApp CI\nAlternate Email address: singn at netapp.com<mailto:singn at netapp.com>, akerr at netapp.com<mailto:akerr at netapp.com>\nPublic key file: Attached\n\nWe get the following error on git review.\n\nProblem running \'git remote update gerrit\'\nFetching gerrit\nPermission denied (publickey).\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\nerror: Could not fetch gerrit\nProblems encountered installing commit-msg hook\nThe following command failed with exit code 1\n    \"scp -P 29418 netapp-ci at review.openstack.org:hooks/commit-msg<mailto:netapp-ci at review.openstack.org:hooks/commit-msg> .git/hooks/commit-msg\"\n-----------------------\nPermission denied (publickey).\n\nThough there is a NetApp CI on the review with -1 but seems somewhere in the gerrit system workflow access is not proper. Could you please look into it.\n\nThanks!\n\nBest Regards\nNavneet Singh\nSoftware Developer\nCloud Solutions Group\nExtn: 4738\n[Businesses built on NetApp go further, faster.]<http://www.netapp.com/us/?REF_SOURCE=emmbonrunnersignaturehp-us>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140616/00f3e93c/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 51643 bytes\nDesc: image001.jpg\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140616/00f3e93c/attachment-0001.jpg>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: gerrit_key.pub\nType: application/x-mspublisher\nSize: 244 bytes\nDesc: gerrit_key.pub\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140616/00f3e93c/attachment-0001.bin>\n\n',NULL,NULL),('<0F8583BBE82FA449A8B78417CC07559AA31627@SJCEML702-CHM.china.huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-31 17:32:23',0,'2014-07-31 17:32:23',NULL,'[openstack-dev] [neutron][policy] Bridging the 2-group gap in\n group policy','Ryan,\n   So this is intended to associate a contract with a source EPG and a destination EPG ? right?\n\n-          Louis\n\n\nFrom: Mandeep Dhami [mailto:dhami at noironetworks.com]\nSent: Wednesday, July 30, 2014 12:21 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: Subrahmanyam Ongole\nSubject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy\n\nHi Ryan:\n\nAs I stated in the patch review, the suggestion to use a \"profiled API\" like IETF/CCITT is indeed very interesting. As a \"profiled API\" has not been tried with any neutron model before, and as there is no existing design pattern/best practices for how best to structure that, my recommendation is to create a new patch (dependent on this patch) to try that experiment.\n\nThat patch will also clarify what is meant you mean by a \"profiled API\" and how that might interact with other openstack services like Heat and Horizon.\n\nRegards,\nMandeep\n-----\n\n\nOn Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi <hemanthraviml at gmail.com<mailto:hemanthraviml at gmail.com>> wrote:\nHi,\n\nAdding this CLI command seems to be a good way to provide support for the second model. This can be submitted as a new review patch to work through the approaches to implement this. I suggest the current CLI patch [1] be reviewed for the existing spec and completed.\n\nRyan, would it possible for you to start a new review submit for the new command(s). Could you also provide any references for \"profiled\" API in IETF, CCITT.\n\nThanks,\n-hemanth\n\n[1] https://review.openstack.org/#/c/104013\n\nOn Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats <rmoats at us.ibm.com<mailto:rmoats at us.ibm.com>> wrote:\n\nAs promised in Monday\'s Neutron IRC minutes [1], this mail is a \"trip down memory lane\" looking at the history of the\nNeutron GP project..  The original GP google doc [2] included specifying policy via both a produce/consume 1-group\napproach and as a link between two groups.  There was an email thread [3] that discussed the relationship between\nthese models early on, but that discussion petered out and during a later IRC meeting [4] the concept of contracts\nwere added, but without changing the basic use case requirements from the original document.  A followup meeting [5]\nbegan the discussion of how to express the original model from the contract data model but that discussion doesn\'t\nappear to have been completed either.  The PoC in Atlanta raised a set of issues [6],[7] around the complexity of the\nresulting PoC code.\n\nThe good news is that having looked through the proposed GP code commits (links to which can be found at [8) I\nbelieve that folks that want to be able to specify policies via the 2-group approach (and yes, I\'m one of them) can have\nthat without changing the model encoded in those commits. Rather, it can be done via the WiP CLI code commit by\nproviding a \"profiled\" API - this is a technique used by the IETF, CCITT, etc. to allow a rich API to be consumed in\ncommon ways.  In this case, what I\'m envisioning is something like\n\nneutron policy-apply [policy rule] [src group] [destination group]\n\nin this case, the CLI would perform the contract creation for the policy rule, and assigning the proper produce/consume\nedits to the specified source and destination groups.  Note:  this is in addition to the CLI providing direct access to the\nunderlying data model.  I believe that this is the simplest way to \"bridge the gap\" and provide support to folks who want\nto specify policy as something between two groups.\n\nRyan Moats (regXboi)\n\nReferences:\n[1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt\n[2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#<https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit>\n[3] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html\n[4] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html\n[5] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html\n[6] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html\n[7] http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html\n[8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/c2ed9c3d/attachment.html>\n\n','<CACqkTfN4bYk6NPXujNjqgy9qmdtoz299sQ+Jak5pu97BSG86GQ@mail.gmail.com>',NULL),('<0F8583BBE82FA449A8B78417CC07559AA38156@SJCEML702-CHM.china.huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-06 19:17:01',0,'2014-08-06 19:17:01',NULL,'[openstack-dev] [Neutron] Group Based Policy and the way forward','+1\n\nFrom: Edgar Magana [mailto:edgar.magana at workday.com]\nSent: Wednesday, August 06, 2014 10:40 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward\n\nThis is the consequence of a proposal that is not following the standardized terminology (IETF - RFC) for any Policy-based System:\nhttp://tools.ietf.org/html/rfc3198\n\nWell, I did bring  this point during the Hong Kong Summit but as you can see my comments were totally ignored:\nhttps://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit\n\nI clearly saw this kind of issues coming. Let me quote myself what I suggested: \"For instance: \"endpoints\" should be \"enforcement point\"\n\nI do not understand why GBP did not include this suggestion...\n\nEdgar\n\nFrom: Kevin Benton <blak111 at gmail.com<mailto:blak111 at gmail.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Wednesday, August 6, 2014 at 10:22 AM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward\n\n\nWhat I was referring to was also not Keystone\'s definition of an endpoint. It\'s almost as if the term has many uses and was not invented for Keystone. :-)\n\nhttp://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html\n\nDid a similar discussion occur when Heat wanted to use the word \'template\' since this was clearly already in use by Horizon?\nOn Aug 6, 2014 9:24 AM, \"Jay Pipes\" <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:\nOn 08/06/2014 02:12 AM, Kevin Benton wrote:\nGiven that, pointing to the Nova parity work seems a bit like a red\nherring. This new API is being developed orthogonally to the existing\nAPI endpoints\n\nYou see how you used the term endpoints there? :P\n\n-jay\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/9aa5125c/attachment.html>\n\n','<D007B40B.52CF%edgar.magana@workday.com>',NULL),('<0F8583BBE82FA449A8B78417CC07559AA3C2E3@SJCEML702-CHM.china.huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-08 21:01:44',0,'2014-08-08 21:01:44',NULL,'[openstack-dev] [Neutron][policy] Group Based Policy - Renaming','+1 for policy-target\n\n-----Original Message-----\nFrom: Sumit Naiksatam [mailto:sumitnaiksatam at gmail.com] \nSent: Friday, August 08, 2014 12:45 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming\n\nThanks Jay for your constructive feedback on this. I personally think that \'policy-target\' is a good option. I am not sure what the rest of the team thinks, perhaps they can chime in.\n\nOn Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> On 08/07/2014 01:17 PM, Ronak Shah wrote:\n>>\n>> Hi,\n>> Following a very interesting and vocal thread on GBP for last couple \n>> of days and the GBP meeting today, GBP sub-team proposes following \n>> name changes to the resource.\n>>\n>>\n>> policy-point for endpoint\n>> policy-group for endpointgroup (epg)\n>>\n>> Please reply if you feel that it is not ok with reason and suggestion.\n>\n>\n> Thanks Ronak and Sumit for sharing. I, too, wasn\'t able to attend the \n> meeting (was in other meetings yesterday and today).\n>\n> I\'m very happy with the change from endpoint-group -> policy-group.\n>\n> policy-point is better than endpoint, for sure. The only other \n> suggestion I might have would be to use \"policy-target\" instead of \n> \"policy-point\", since the former clearly delineates what the object is \n> used for (a target for a policy).\n>\n> But... I won\'t raise a stink about this. Sorry for sparking long and \n> tangential discussions on GBP topics earlier this week. And thanks to \n> the folks who persevered and didn\'t take too much offense to my questioning.\n>\n> Best,\n> -jay\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAMWrLvje36cmwjUVTcaBwpc-3WWaBnF-ctFkr=CzwkxYPdJe0g@mail.gmail.com>',NULL),('<0f88f80b55c342f4a8aaf3edb20551c9@GURMBXV01.AD.ARICENT.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-01 08:19:06',0,'2014-10-01 08:19:06',NULL,'[Openstack] Unable to assign ip to instance in compute node-2','Hi,\n\nPlease check if DHCP packets on compute and network node using tcpdump and also check that they contain valid VLAN tagging information.\n\nBr,\nArvinder\n\nFrom: Srinivasreddy R [mailto:srinivasreddy4390 at gmail.com]\nSent: Tuesday, September 30, 2014 4:47 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Unable to assign ip to instance in compute node-2\n\nhi,\n\nI have  configured  3 node  setup. Able to access instance form external network and internal network .\ni have attached another compute node in the current 3 node setup .\nLaunched instance in compute-2  but instance is not able to get the internal ip address  through dhcp .\nIs there any additional configuration required when i added new compute node .\nHow can i debug this .\n\n Able to see IP for that instance when launching nova list command on controller node as well on dash board.\nuser at user-ThinkCentre-M73:~$ nova list\n+--------------------------------------+----------------+--------+------------+-------------+--------------------------------+\n| ID                                   | Name           | Status | Task State | Power State | Networks                       |\n+--------------------------------------+----------------+--------+------------+-------------+--------------------------------+\n| a28e3e67-7621-418a-9626-838c2396cd34 | comp2-inst3    | ACTIVE | -          | Running     | demo-net=11.0.0.34, 172.0.0.10 |\n| 83cf5d08-23a0-45b4-9485-07fa035b58b7 | ins1           | ACTIVE | -          | Running     | demo-net=11.0.0.9, 172.0.0.7   |\n| b2b57156-0c7f-4669-9946-b4a0e6ae8c1f | my_instance001 | ACTIVE | -          | Running     | demo-net=11.0.0.2, 172.0.0.3   |\n| 2a311004-76e1-4c71-b043-76ebd306179f | my_instance002 | ACTIVE | -          | Running     | demo-net=11.0.0.5, 172.0.0.4   |\n| 16af4e2e-8247-45eb-93dd-fc1304bf4601 | open-instance1 | ACTIVE | -          | Running     | demo-net=11.0.0.11, 172.0.0.8  |\n\nthanks,\nsrinivas.\n\"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.\"\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141001/cc0e9238/attachment.html>\n\n','<CAJP4VWiFMW0Rofc7yh5FOx0GXsgf8d6Ri6gOYWRrvjpiud7L6A@mail.gmail.com>',NULL),('<0F8BC705-F6E9-4E8C-8C19-A67708322292@mac.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 13:53:41',-28800,'2012-11-14 21:53:41',NULL,'[openstack-dev] [Openstack] Fwd: [keystone] Tokens representing\n authorization to projects/tenants in the Keystone V3 API','If we\'re going to assert it\'s supported, we\'re doing an incredible dis-service to writing a spec to not implement that aspect of the spec, as that kind of set up just leads to incompatibilities and confusion when asserting how the spec should be used to provide interoperability.\n\nIf we accept this as a spec addition, then we MUST have an implementation that makes it clear how we expect to interoperate with that aspect of the specification, even if it\'s a configuration option that we don\'t normally enable. If we don\'t test and validate it to prove interoperability, then the spec is a worthless digital \"piece of paper\".\n\nSo under that pretext, I welcome suggestions on how to interpret the spec you\'re proposing to some concrete implementations that can be verified for interoperability, and that are compatible with the existing and/or upcoming implementations for V3 API.\n\n-joe\n\nOn Nov 14, 2012, at 1:35 PM, Joe Savak <joe.savak at RACKSPACE.COM> wrote:\n> Hi Joe,\n> 	If I\'m working across multiple tenants, I\'d prefer one token that I can securely handle that proves access rights to the tenants I\'m working with. Handling multiple tokens increases the complexity of clients needing to provide multi-tenancy access to an authenticated identity. It also adds more calls to keystone. \n> \n> Again, I think that having the keystone reference implementation restrict tokens to 1 tenant is fine. We shouldn\'t have such arbitrary restrictions in the API contract though. It needs to be extensible and flexible to allow for the all sorts of use cases that are likely to occur.\n> \n> Thanks,\n> joe\n> \n> -----Original Message-----\n> From: heckj [mailto:heckj at mac.com] \n> Sent: Tuesday, November 13, 2012 3:59 PM\n> To: Joe Savak\n> Cc: OpenStack Development Mailing List; openstack at lists.launchpad.net (openstack at lists.launchpad.net)\n> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API\n> \n> Hey Joe:\n> \n> Currently a user scoped token doesn\'t include a service catalog - mostly because I think the service catalog generally requires tenant_id\'s to interpolate into the values to provide it. That doesn\'t mean we can\'t put in/include service catalog endpoints where that value doesn\'t need to be determined.\n> \n> I\'m also questioning the value of providing a token scoped to all tenants associated with a user - that seems to have the same value as just using a user token. \n> \n> In fact, even if we allow some arbitrary set of tenants to be scoped into a token along with a user, what on earth should be in the service catalog? Endpoints relevant to every possible tenant?\n> \n> This just seems to be a potential explosion of data that is poorly scoped from a security perspective.\n> \n> -joe\n> \n> On Nov 13, 2012, at 1:42 PM, Joe Savak <joe.savak at RACKSPACE.COM> wrote:\n>> Will user-scoped token include the full service catalog? \n>> \n>> Also, I thought the consensus was to allow the API contract to be flexible on how many tenants we can scope the token to. The ref impl can enforce 1 tenant-scoped token. Are we diverging from this?\n>> \n>> Thanks,\n>> joe\n>> \n>> -----Original Message-----\n>> From: openstack-bounces+joe.savak=rackspace.com at lists.launchpad.net [mailto:openstack-bounces+joe.savak=rackspace.com at lists.launchpad.net] On Behalf Of heckj\n>> Sent: Tuesday, November 13, 2012 1:34 PM\n>> To: OpenStack Development Mailing List\n>> Cc: openstack at lists.launchpad.net (openstack at lists.launchpad.net)\n>> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing authorization to projects/tenants in the Keystone V3 API\n>> \n>> \n>> On Nov 13, 2012, at 11:01 AM, Jorge Williams <jorge.williams at rackspace.com> wrote:\n>>> On Nov 13, 2012, at 11:35 AM, heckj wrote:\n>>>> So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. \n>>>> \n>>>> Right now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they\'d need a different middleware there. Keystone as a service *doesn\'t* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user.\n>>>> \n>>>> All that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. \n>>> \n>>> I\'m not sure I\'m following you there.  I don\'t see how unscoped tokens obviate the need to scope to multiple tenants, these may be driven by  different concerns. \n>>> \n>>> Again, I think we need to have some flexibility in how we scope tokens. The API should be flexible enough to support different models -- I think that scoping a token to multiple tenants is useful in cases such as delegation -- where a single identity may be issued revokable access to a set of resources in multiple projects.\n>> \n>> The consensus from the folks weighing in on this from a security perspective seems to be that it\'s kosher to restrict tokens further (the least privilege thing). Broadening the scope to multiple tenants or sets of tenants doesn\'t appear to follow those best practices. If you wanted to accept a less-scoped token than the scoped to single tenant, you can accept and use a user-scoped token, at least by my read.\n>> \n>> -joe\n>> \n>> \n>> \n>> _______________________________________________\n>> Mailing list: https://launchpad.net/~openstack\n>> Post to     : openstack at lists.launchpad.net\n>> Unsubscribe : https://launchpad.net/~openstack\n>> More help   : https://help.launchpad.net/ListHelp\n> \n\n\n\n','<B09263D232F6A94488B2189B46F7153671194857@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0F9B4ADE-165D-4DEC-8447-BDC9351CDB4E@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-16 06:17:14',0,'2013-10-16 06:17:14',NULL,'[openstack-dev] Hyper-V meeting Minutes','\n\nOn Oct 16, 2013, at 05:48 , Dan Smith <dms at danplanet.com<mailto:dms at danplanet.com>> wrote:\n\nThe last thing that OpenStack needs ANY more help with is velocity. I\nmean, let\'s be serious - we land WAY more patches in a day than is\neven close to sane.\n\nThanks for saying this -- it doesn\'t get said enough. I find it totally\namazing that we\'re merging 34 changes in a day (yesterday) which is like\n170 per work week (just on nova). More amazing is that we\'re talking\nabout how to make it faster all the time. It\'s definitely the fastest\nmoving extremely complex thing I can recall working on.\n\n\nDan, nobody puts into discussion how good the work that you guys are doing is. You guys are doing an amazing job, that\'s unquestionable.\n\nThe problem is that the review team, in the way in which it is structured today, simply does not scale with the review load (which is quite funny in a project which is all about scalability :-)).\n\nHere\'s a quick analysys over the 90 days Nova review stats published by Russell: http://russellbryant.net/openstack-stats/nova-reviewers-90.txt\n\nRoughly 2/3 of the reviews are done by 20 people, with the top 10 getting close to 50%.\nLet\'s say that we provide out of our sub-team 1 additional Nova core dev that will perform in the top 10, which averages 521 reviewes, 4,6% of the total.\nThis would reduce our stale review queue time by 5%, which is quite far from a practical improvement over the current mess IMO.\n\nThe picture changes if you put this additional resource to do reviews mostly on our sub-project code, but at that point I don\'t see the difference from having somebody with +2 rights on the driver sub-tree only.\n\nThis example applies to any sub-project of course, not only the Hyper-V driver.\n\n\n(I hope that the table formatting will come out decently in the ML email, if not please find the data here: http://paste.openstack.org/show/48539/)\n\nReviewer        Core    Reviews % over total    Partials\nrussellb        yes     888     7,84%\ngaryk           856     7,55%\njogo    yes     475     4,19%\nmikalstill      yes     450     3,97%\ndanms   yes     447     3,94%   23,55%  TOP 5\nndipanov        yes     432     3,81%\nklmitch yes     429     3,79%\ncbehrens        yes     360     3,18%\njohngarbutt     yes     351     3,10%\ncyeoh-0 yes     327     2,89%   44,25%  TOP 10\nmarkmc  yes     304     2,68%\nalaski  yes     289     2,55%\nmriedem         270     2,38%\ncerberus        yes     266     2,35%\ndripton         261     2,30%\nberrange        yes     251     2,21%\njhesketh                250     2,21%\nphilip-day              250     2,21%\nxuhj            237     2,09%\nbelliott        yes     212     1,87%   67,10%  TOP 20\nguohliu         201     1,77%\nboris-42                170     1,50%\nsdague  yes     164     1,45%\np-draigbrady    yes     130     1,15%\nvishvananda     yes     123     1,09%\ntracyajones             112     0,99%\nJayLau          109     0,96%\nhartsocks               108     0,95%\narosen          106     0,94%\ndims-v          101     0,89%   78,79%  TOP 30\n\n\n\n\nWe MUST continue to be vigilent in getting people to care about more\nthan their specific part, or else this big complex mess is going to come\ncrashing down around us.\n\nI totally agree.\n\n--Dan\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/abc1b213/attachment.html>\n\n','<525DFE92.2050402@danplanet.com>',NULL),('<0f9e85e808f24c788383ae41447449b5@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-21 10:37:50',-18000,'2013-08-21 15:37:50',NULL,'[openstack-dev] Osl and dangerous code merging','On 2013-08-21 10:03, Julien Danjou wrote:\n> On Wed, Aug 21 2013, Doug Hellmann wrote:\n> \n>> IIUC, git sub-modules point to a specific revision of the external\n>> repository, right?\n> \n> Yes.\n> \n>> So would projects still have to explicitly update to newer versions of\n>> the incubator code by changing that sub-module reference?\n> \n> Yes.\n> \n>> With the copy process we have now it is possible to update only part \n>> of the\n>> incubator code in a project. Is that a feature we would want to retain \n>> if\n>> using sub-modules?\n> \n> We\'d lose it indeed.\n> \n> OTOH, it seems _relatively_ dangerous to me to update part of\n> Oslo-incubator like we do, considering the possible dependencies \n> between\n> files.\n\nThat can be an issue, but on the other hand when a mass sync is done \nthere\'s almost no way to keep track of all the changes involved, so I \nthink in some circumstances it can be better to do individual modules.  \nAt least that way the person doing the sync is presumably familiar with \nthe code they\'re syncing and has a handle on the dependencies (and \npotential changes needed in the target project).\n\nJust a counterpoint.  Not sure it\'s a sufficient argument to stop this \nif we want to move forward with it.\n\n-Ben\n\n\n\n','<8761uzqe5v.fsf@dex.adm.naquadah.org>',NULL),('<0F9EBAFC-299B-452C-899B-4904D6557278@ebay.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 02:55:14',0,'2012-11-06 02:55:14',NULL,'[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion','Youcef,\n\nIn fact, Chinmay and me are discussing the service definition and it could be the one which addresses this use case. We planned to discuss this in tomorrow\' s meeting.\n\nThanks for your detailed explanation on this. Let us discuss more tomorrow.\n\nThanks\nAnand\n(408)601-7148\n\nOn Nov 5, 2012, at 6:47 PM, \"Youcef Laribi\" <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>> wrote:\n\nAnand,\n\nThis gets us to the discussion of ?service type? that Salvatore has explained in his document, which I think accommodates your scenario.\n\nIf a vendor?s ?adapter? (?driver?) is able to express the type of load-balancing capabilities it is providing through the concept of ServiceDefinition data structures used in Salvatore?s doc (each  ?ServiceDefinition? could simply be a shortcut for things like ?deviceX-version1?, ?deviceX-version2?, ?deviceY?, ?hardware-lb?, ?software-lb?, ?very-fast-lb?, etc.), and then the ?ServiceDefinitions? from all vendors are organized into ?ServiceTypes? by the LBaaS admin, then the same service type can have 2 or more ?ServiceDefinitions? from the same vendor (?adapter?) and/or from different vendors. ServiceDefinitions of the same ?advanced service? (e.g. LB) in the same ?service type? are considered inter-changeable.\n\nWe just need to define the way for an ?adapter? to express its ?ServiceDefinitions?. This could be either a static metadata file that each ?adapter? must have, or the ?adapter? can respond to a call asking it to describe its ?ServiceDefinitions?. There would be a mapping between an ?adapter? (provider ID ?) and all the ?ServiceDefinitions? it provides. When the adapter is called to perform a task, the call should specify the ?ServiceDefinition? ID being picked by the LBaaS plugin.\n\nSay the admin defines a service-type called ?Gold?, and  maps it for LB to either ServiceDefinition (?vendor1?/?deviceX-v1?) or ServiceDefinition (?vendor2?/?deviceZ?), while she maps service-type ?Silver? for LB to only ServiceDefinition (?vendor1?/deviceX-v2?), when the user wants to create a ?vip? using the ?Gold? service type, then  LBaaS plugin would need to pick either ?vendor1?/?device-Xv1? or ?vendor2/deviceZ? to service this request, and would need to remember that ?vip A? was created using ?ServiceDefinition X? in its database.\n\nYoucef\n\nFrom: Palanisamy, Anand [mailto:apalanisamy at paypal.com]\nSent: Monday, November 05, 2012 5:23 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nYoucef/Salvatore,\n\nI hope, the single advanced service (LBaaS) plug-in with multiple adapters or  drivers will address the \"support for multiple-versions of each vendor\" as well. Also, it is the plug-ins responsibility to dispatch the API calls to right adapter with right version.\n\nPlease confirm.\n\nI agree that let us postpone the extension attribute discussion to G2 or G3.\n\nThanks\nAnand\nFrom: Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>\nReply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tue, 6 Nov 2012 02:08:55 +0100\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\nSeems we all agree about having adapters or drivers for various types of devices, and that there will be no need to have multiple, co-existing plugins.\n\nI think Youcef\'s reference to anyAttribute was for allowing a way to expose device-specific features on the tenant API. When you support multiple drivers, this become a bit tricky as some drivers might support a particular feature, whereas some other drivers might not.\nIdeally, I would still use the API extension mechanism to this aim, as I think it\'s feasible and it seems an architecturally clean way of dealing with this problem. API extensions can define new resources, new attributes on existing resources, or add actions to existing resources. However, Quantum\'s extension framework will need to be improved for dealing with extensions that might be supported only by a specific driver. Although some ideas on how to solve this problem have been published at: http://wiki.openstack.org/Quantum/ServiceInsertion, it is my opinion that support for driver-specific capabilities could be delayed to either Grizzly-2 or 3.\n\nSalvatore\n\nOn 6 November 2012 01:02, Sachin Thakkar <sthakkar at vmware.com<mailto:sthakkar at vmware.com>> wrote:\nYes, I think having a vendor specific adapter is very much in the plan. It should remain extensible in this manner. As Youcef mentioned, I doubt it\'ll be XSDs since there isn\'t as much XML in the quantum project but the same model used for L2 should work.\n\nSachin\n\n----- Original Message -----\nFrom: \"Youcef Laribi\" <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSent: Monday, November 5, 2012 1:48:15 PM\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\n\n\nHi Peter,\n\n\n\nI think we all agree that the LBaaS APIs allows for extensions in line with other OpenStack APIs. As I said earlier the use of XSDs to generate the APIs is not an established practice in OpenStack projects (and in Quantum), but we can certainly use XSDs to document the API if it helps. Vendor drivers should be able to support extensions. If the user wants to use a certain LBaaS extension and this extension is only implemented by some vendors drivers, then this could be used to select that vendor?s implementation (using the ?service type? mechanism described by Salvatore?).\n\n\n\nYoucef\n\n\n\n\n\n\n\n\n\nFrom: Mellquist, Peter [mailto:peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>]\nSent: Monday, November 5, 2012 1:16 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\nHi Youcef,\n\n\n\nThis sound good. One question, can the model be extended by a vendor specific adapter? ( In Atlas, you had the XSDs (schema ) allow <anyAttributes> which seemed to allow this )\n\n\n\nThanks\n\nPeter.\n\n\n\n\n\nFrom: Youcef Laribi [ mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com> ]\nSent: Monday, November 05, 2012 1:03 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\nReturning to the LBaaS plugin design, my current assumption (and I want to check if this is shared) is that we don?t want to have a separate LBaaS plugin for each vendor (even though this is of course possible). There is a core functionality in LBaaS that needs to be implemented anyway and therefore if we agree how this is done, it makes sense to have one piece (one plugin) doing this (like the eBay and Atlas services had). This piece (the LBaaS plugin) will for example maintain the LBaaS data model as defined by the API. Then there are the vendor-specific parts (the ones we called ?adapters? in Atlas, others call them ?drivers?, etc.). And we would want to be able to have several of these vendor drivers loaded simultaneously in an LBaaS service.\n\n\nSome of these drivers can also implement several ?advanced services?. So, a vendor?s ?driver? could implement more than one ?advanced service? interface if it wants to (e.g. a firewall + lb) therefore interfacing with several Quantum plugins. I have a picture illustrating this setup ( http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+LBaaS+plugin+with+providers.png ). Would love to hear your thoughts on the above.\n\n\n\nYoucef\n\n\n\n\n\n\n\n\n\n\n\nFrom: Salvatore Orlando [ mailto:sorlando at nicira.com<mailto:sorlando at nicira.com> ]\nSent: Monday, November 5, 2012 8:03 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\nHi Youcef,\n\n\n\n\n\nsorry about the delay in my reply.\n\n\nI think consensus about the right approach is starting to maturing. I totally agree with you on the need for having clear interfaces.\n\n\n\n\n\nFor the L3 functionality, at the summit we decided to regard it as \"core\". And indeed I already have a blueprint for moving the APIs from extensions to core.\n\n\nSo, technically speaking, L3 will become part of the core plugin.\n\n\n\n\n\nHowever, as I also discussed on the wiki page, I\'d like community input to understand how to deal with Floating IPs, which despite being part of the L3 extension kind of represent an \"advanced\" service.\n\n\n\n\n\nSalvatore\n\n\nOn 2 November 2012 20:00, Youcef Laribi < Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com> > wrote:\n\n\n\nThanks Salvatore. I?m also in favor of loading several plugins and have clean interfaces between them.\n\n\n\nDoes this mean the L3 functionality will be factored out in its own plugin if we go with the ?multiple plugins? approach, or will you keep it in the ?core plugin? ?\n\n\n\nYoucef\n\n\n\n\n\n\n\n\n\n\nFrom: Salvatore Orlando [mailto: sorlando at nicira.com<mailto:sorlando at nicira.com> ]\nSent: Friday, November 2, 2012 10:28 AM\n\n\n\n\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\n\n\nYoucef,\n\n\n\n\n\nThe proposals you\'ve described are exactly the ones being considered on the wiki page.\n\n\nI am considering both at the moment, and I\'m evaluating them along the following dimensions:\n\n\n1) Flexibility (and the multiple plugins approach here is a winner, probably)\n\n\n2) Impact on Quantum architecture (single plugin would be the one with the lowest impact)\n\n\n3) Implementation effort (here I am still undecided, as the approach with a single plugin ends up moving the complexity from Quantum server to the plugin)\n\n\n\n\n\nIt seems we have not yet a clear decision, but several people from the community are advocating for clean, separate interfaces among plugins.\n\n\nAnother option we might consider is whether we start adopting 1 plugin per type of service (so 1 core plugin, 1 firewall plugin, 1 load balancing plugin), and update quantum to dispatch the call to the appropriate plugin.\n\n\nOn this single \'LB\' plugin we can immediately start providing an OSS implementation, so that Quantum users will have the ability of testing the feature. Vendor-specific plugin might follow suit. What we will not have immediately (and I mean G-1 or G-2) is the ability of serving multiple providers at the same time, which is one of the fundamental requirements for LBaaS, but we can commit to add this capability by G-3.\n\n\n\n\n\nThanks,\n\n\nSalvatore\n\n\n\n\n\nOn 2 November 2012 16:45, Youcef Laribi < Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com> > wrote:\n\n\n\nThanks Eugene, Salvatore for validating the current situation. Now let me try to understand the changes we are proposing for incorporating LBaaS and other ?advanced services?.\n\n\n\nAll current ?Core plugins? in Quantum like the ?Linux Bridge? plugin implement the L2 core APIs, and some of these plugins also implement the L3 extension. Today, there can only be one ?core plugin? running in Quantum. So, the total of the APIs supported will depend the core plugin that was configured.\n\n\n\nAre we saying, that we will modify some of these core plugins to also implement the LBaaS extension, so they will expose the LBaaS APIs in addition to the L2 and L3 APIs ? If not, is the proposal to modify Quantum to support more than one plugin at a time (a ?core? one + others) ?\n\n\n\nYoucef\n\n\n\n\n\n\n\nFrom: Salvatore Orlando [mailto: sorlando at nicira.com<mailto:sorlando at nicira.com> ]\nSent: Friday, November 2, 2012 2:11 AM\n\n\n\nTo: OpenStack Development Mailing List\n\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\n\n\nYoucef,\n\n\n\n\n\nI think that picture describes quite well the framework Quantum is already adopting for l2/l3 connectivity.\n\n\nWe could do down that route for LBaaS as well. However for supporting multiple providers we\'ll need to keep in mind that we might need some logic, within the Quantum plugin for dispatching to the appropriate agent.\n\n\n\n\n\nWith your permission, I will take your picture and use it in the service insertion wiki page, which I will update with the outcome of the recent discussions we had.\n\n\n\n\n\nSalvatore\n\n\nOn 2 November 2012 07:22, Eugene Nikanorov < enikanorov at mirantis.com<mailto:enikanorov at mirantis.com> > wrote:\n\nHi Youcef,\n\n\n\n\n\nThe picture you\'ve made is quite accurate.\n\n\nMy opinion is that we should adopt the same approach for lbaas, e.g. extension - plugin - agent - drivers.\n\n\n\n\n\nThanks,\n\n\nEugene.\n\n\n\n\nOn Fri, Nov 2, 2012 at 10:44 AM, Youcef Laribi < Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com> > wrote:\n\n\n\n\n\n\n\nEugene, Salvatore,\n\n\n\nIn order to clarify the terminology in our meetings and not get confused, I?m trying to draw a picture that represents how Quantum is organized today (mostly for myself). I have uploaded an attempt here:\n\nhttp://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Internal+components.png\n\n\n\nCan you please check it for accuracy since you are familiar with the code? Once we agree and understand this picture, we can more easily discuss what needs to be changed in Quantum to accommodate LBaaS.\n\n\n\nYoucef\n\n\n\nFrom: Eugene Nikanorov [mailto: enikanorov at mirantis.com<mailto:enikanorov at mirantis.com> ]\nSent: Wednesday, October 31, 2012 6:32 AM\nTo: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\n\n\nHi Salvatore,\n\n\n\n\n\nI\'d like to give some feedback/questions based on yesterday\'s meeting discussion and your renewed http://wiki.openstack.org/Quantum/ServiceInsertion page.\n\n\n\n\n\nFirst of all, I think it\'s worth to fix the terminology just to avoid any confusion:\n\n\n\n\n\n- extension (API extension) - set of REST calls\n\n\n- plugin - code that implements certain API, works with quantum database, pushes calls to agents\n\n\n- core plugin - code that implements core API (networks, subnets, ports, L3)\n\n\n- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent\n\n\n- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices.\n\n\n\n\n\nSome thoughts on the Service Insertion proposal:\n\n\n\n\n\n1. It seems that multiplugin approach is the right way to move further compared to \"mixin\" approach where we inject and modify code of the core plugin.\n\n\nThis will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).\n\n\n\n\n\n2. Having several implementations of the same service type.\n\n\nIf all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.\n\n\nThe options include:\n\n\n1) passing particular service impl as a url parameter\n\n\n2) having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json\n\n\n3) having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available\n\n\n\n\n\nMy preference is (2): first of all, it \"splits\" whole API between core API and Adv Svc API, and also does so for different service type implementations.\n\n\nAlthough URIs may not be so short as we want them, that could prevent from naming collisions between different service types.\n\n\n\n\n\n3. Service Insertion:\n\n\nI was thinking about routed/floating-mode insertion and there is a certain thing I don\'t understand: the workflow.\n\n\nIt seems that the whole thing is somehow close to what we used to call \"device management\" in mirantis implementaion of lbaas, but it doesn\'t look like solving all device management tasks.\n\n\n\n\n\nSo in our implementation of LBaaS the workflow was as following:\n\n\n1) admin creates the device. Essentially it\'s just an instruction to LBaaS of where is the device (it\'s address), which type is it and credentials to manage it.\n\n\n2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration\n\n\n\n\n\nIf we\'re talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):\n\n\n1) admin creates the device. The same as in lbaas - address, type, credentials\n\n\n2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration),\n\n\nconfigures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network\n\n\n\n\n\nIf we\'re talking about private balancer with Quantum, then:\n\n\n1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.\n\n\n2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required\n\n\n\n\n\nIt would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be.\n\n\n\n\n\nThanks,\n\n\nEugene.\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121106/a9967deb/attachment.html>\n\n','<7B14C05615DB43488B85E143995BD54901081F7C9B21@LONPMAILBOX01.citrite.net>',NULL),('<0FA2C522-6905-4393-85B8-8E483949A7AA@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 11:33:34',-18000,'2014-01-18 16:33:34',NULL,'[openstack-dev] a \"common\" client library','\nOn Jan 18, 2014, at 9:58 AM, Jesse Noller <jesse.noller at RACKSPACE.COM> wrote:\n\n> \n> On Jan 18, 2014, at 12:00 AM, Jamie Lennox <jamielennox at redhat.com> wrote:\n> \n>> I can\'t see any reason that all of these situations can\'t be met. \n>> \n>> We can finally take the openstack pypi namespace, move keystoneclient -> openstack.keystone and similar for the other projects. Have them all based upon openstack.base and probably an openstack.transport for transport.\n>> \n>> For the all-in-one users we can then just have openstack.client which depends on all of the openstack.x projects. This would satisfy the requirement of keeping projects seperate, but having the one entry point for newer users. Similar to the OSC project (which could acutally rely on the new all-in-one).\n>> \n>> This would also satisfy a lot of the clients who have i know are looking to move to a version 2 and break compatability with some of the crap from the early days.\n>> \n>> I think what is most important here is deciding what we want from our clients and discussing a common base that we are happy to support - not just renaming the existing ones.\n>> \n>> (I don\'t buy the problem with large amounts of dependencies, if you have a meta-package you just have one line in requirements and pip will figure the rest out.)\n> \n> You?re assuming:\n> \n> 1: Pip works when installing the entire dependency graph (it often doesn?t)\n> 2: For some of these requirements, the user has a compiler installed (they don?t)\n> 3: Installing 1 ?meta package? that install N+K dependencies makes end user consumers happy (it doesn?t)\n> 4: All of these dependencies make shipping a single binary deployment easier (it doesn?t)\n> 5: Installing and using all of these things makes using openstack within my code conceptually simpler (it doesn?t)\n> \n> We can start with *not* renaming the sub clients (meaning) collapsing them into the singular namespace; but the problem is that every one of those sub dependencies is potential liability to someone using this single client. \n> \n> If yes, we could only target fedora, and rely on yum & rpm, I?d agree with you - but for python application dependencies across multiple OSes and developers doing ci/cd using these systems I can?t. I also don?t want user to stumble into the nuanced vagaries of the sub-clients when writing application code; writing glue code to bind them all together does work very well (we know this from experience).\n> \n\nAs much as I would like to say (with my pip developer and PyPI Admin hat on) that depending on 22+ libraries in a single client will be a seamless experience for end users I can?t in good faith say that it would be yet. We?re working on trying to make that true but honestly each dependency in a graph does introduce risk.\n\nAs of right now there is no real dependency solver in pip, so if someone depends on the openstack client themselves, and then depends on something else that depends on one of the sub clients as well if those version specs don?t match up there is a very good chance that the end user will run into a very confusing message at runtime. Openstack itself has run into this problem and it was a big motivator for the global requirements project.\n\nAdditionally it?s not uncommon for users to have policy driven requirements that require them to get every dependency they pull in checked for compliance (License, security etc). Having a 22+ node dependency graph makes this issue much harder in general.\n\nI also believe in general it?s asking for user confusion. It?s much simpler to document a single way of doing it, however splitting the clients up and then wrapping them with a single ?openstack? client means that you have at least two ways of doing something; The direct ?use just a single library? approach and the ?use the openstack wrapper? approach. Don?t underestimate the confusion this will cause end users.\n\nKeeping them all under one project will make it far easier to have a cohesive API amongst all the various services, it will reduce duplication of efforts, as well as make it easier to track security updates and I believe a wholly superior end user experience.\n\n-----------------\nDonald Stufft\nPGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140118/93f08b5d/attachment.pgp>\n\n','<1A6531F0-6118-41FE-97AE-6D06C597F3F4@rackspace.com>',NULL),('<0fa4a5eea442447f9ffa981e713b7db7@BL2PR03MB497.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-17 05:27:46',0,'2014-09-17 05:27:46',NULL,'[Openstack] openstack bug for help','Hello,\n                I have deploy a openstack on powerpc architecture, and the openstack version is Havana,  but I have a problem when create a project, that comes to issue \"Error: Unable to set project quotas\". I want to know is that a bug in Havana or it have resolved in the latter version?\n\nThanks very much!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140917/99260143/attachment.html>\n\n',NULL,NULL),('<0FABB4E9-CF49-494C-947D-3191CC9B3D33@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 18:35:13',-28800,'2014-02-25 02:35:13',NULL,'[openstack-dev] Nova Bug Scrub meeting','Hi all - i have set up the nova bug scrub meeting for Wednesdays at 1630 UTC in the #openstack-meeting-3 IRC channel\n\n\nThe first meeting will be all about triaging the 117 un-triaged bugs (here).  \n\n\nhttps://wiki.openstack.org/wiki/Meetings/NovaBugScrub#Weekly_OpenStack_Nova_Bug_Scrub_Meeting\n\n\nWeekly on Wednesday at 1630 UTC\nIRC channel: #openstack-meeting-3\nChair (to contact for more information): Tracy Jones\nSee Meetings/NovaBugScrub for an agenda\n\n\nCome join the fun!\n\nTracy\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140224/7d021118/attachment.html>\n\n',NULL,NULL),('<0FB3FC4E-58FA-4FE4-BE09-FB56897958A1@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-18 22:47:48',0,'2013-04-18 22:47:48',NULL,'[openstack-dev] [Glance] unconference image transfer\n	Thursday	11:50am','I was unable to make it as well, so if there are any write ups or takeaways I\'d love to see them!\n\nRichard Goodwin\nProduct Manager: Imaging/Glance\nIdeation | Intellection | Activator | Relator | Responsibility\nPhone: (512) 788 5403<tel:(512)%20788%205403> ? Cell: (512) 736-7897<tel:(512)%20736-7897> (Austin)\nSkype: rtgoodwin<file:///callto/::rtgoodwin> - Yahoo: richardtgoodwin<file:///ymsgr/sendim%3Frichardtgoodwin>\nAIM: dellovision - IRC: goody / rgoodwin\n\nOn Apr 18, 2013, at 3:13 PM, \"Mark Washenberger\" <mark.washenberger at markwash.net<mailto:mark.washenberger at markwash.net>> wrote:\n\nJohn,\n\nI\'m so sorry I missed this! I somehow made a mental note that it was sometime between 3 PM and 4 PM, and was just a few minutes ago looking to see again exactly when you were having it. I hope it went well.\n\nSorry again,\nMark\n\n\nOn Mon, Apr 15, 2013 at 12:03 PM, John Bresnahan <jbresnah at redhat.com<mailto:jbresnah at redhat.com>> wrote:\nFor those at the Summit:\n\nI signed up for an unconference time slot on Thursday at 11:50am to talk\nabout image transfer and related issues.  I know that time in the Glance\nsessions is tight so I felt this would be a decent way to have some\noverflow time and also to get cross talk with other components.\n\nFor context I wrote a blog with some thoughts on this area here:\n\nhttp://tropicaldevel.wordpress.com/2013/01/11/an-image-transfers-service-for-openstack/\n\nHope to see you there!\n\nJohn\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130418/7c412a49/attachment.html>\n\n','<CAJyP2C-PUsV+_ZGv1_yrwRMJ-43BPJR3fGMAAt9BMHtSBknUaw@mail.gmail.com>',NULL),('<0FB9040E-EC50-45E7-B548-65E9E1CE2C93@openstack.org>','http://lists.openstack.org/pipermail/transparency',NULL,'2013-10-01 14:28:16',-18000,'2013-10-01 19:28:16',NULL,'[Transparency] Transparency Committee - Quick meeting before\n	Thursday?','Two people have responded, both of which can meet in about an hour and a half. \n\nThe only other time suggested was Thursday morning, which might be a bit late. \n\nAny other takers? :)\n\nOn Oct 1, 2013, at 12:29 PM, Lauren Sell <lauren at openstack.org> wrote:\n\n> Hi everyone --\n> \n> Would it make sense to get together briefly so we have a proper update for the board meeting?\n> \n> I would love to get the transparency policy wrapped up and circulated to the Board, so we can approve it during this week\'s meeting (not sure if it requires a vote), although there are still a few dependencies with the mailing list/doc store and ombudsman plans. We could always publish a v1 and update it once those items are complete.\n> \n> You can see the latest version of the policy here. I spent some time responding to and resolving comments that were made when we originally sent it out to the mailing list for feedback, but there are still a few remaining questions we can discuss: https://docs.google.com/a/openstack.org/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit\n> \n> I know it\'s short notice, but I\'ve set up a doodle to see if we can get together a significant number: http://doodle.com/4x59xhz7xpcsy6u4\n> \n> Also for reference are our rough notes from the Feb 21 meeting: https://etherpad.openstack.org/TransparencyWG-Feb21-Agenda\n> \n> Thanks,\n> Lauren\n> \n> \n\n\n\n','<7627FC23-6C3D-4F27-8B7B-F6D447692B73@openstack.org>',NULL),('<0FBF5631AB7B504D89C7E6929695B62492F7F3F2@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 15:43:45',0,'2014-07-22 15:43:45',NULL,'[openstack-dev] [glance]code review needed for \'changing HTTP\n response code on errors\'','Hey Kent,\n\nAppreciate your effort and being pro-active for your patches. For future review requests please join us at the #openstack-glance channel on Freenode.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Wang, Kent [kent.wang at intel.com]\nSent: Monday, July 21, 2014 1:20 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [glance]code review needed for \'changing HTTP response code on errors\'\n\nHi I?m looking for some reviewers (especially core reviewers!) to review my patch that fixes this bug.\n\nThis is the bug description:\n\nGlance v2: HTTP 404s are returned for unallowed methods\nRequests for many resources in Glance v2 will return a 404 if the request is using an unsupported HTTP verb for that resource. For example, the /v2/images resource does exist but a 404 is returned when attempting a DELETE on that resource. Instead, this should return an HTTP 405 MethodNotAllowed response.\n\n\nMy fix for it can be found here:\nhttps://review.openstack.org/#/c/103959/\n\nThanks!\nKent\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140722/c229cc68/attachment.html>\n\n','<ABFF5BDEC25D344FBBD690260F2578CD9B825F@ORSMSX116.amr.corp.intel.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62492FB8EF7@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 20:56:57',0,'2014-09-25 20:56:57',NULL,'[openstack-dev] [Glance] PTL candidacy','Hi,\n\nI would like to take this opportunity and announce my candidacy for the role of Glance PTL.\n\nI have been part of this program since Folsom release and have had opportunity to work with an awesome team. There have been really challenging changes in the way Glance works and it has been a pleasure to contribute my reviews and code to many of those changes.\n\nWith the change in mission statement [1], that now provides a direction for other services to upload and discover data assets using Glance, it would be my focus to enable new features like \'Artifacts\' to merge smoothly into master. This is a paradigm change in the way Glance is consumed and would be my priority to see this through. In addition, Glance is supporting a few new features like async workers and metadef, as of Juno that could be improved in terms of bugs and their maintainability. Seeing this through would be my next priority.\n\nIn addition to these, there are a few other challenges which Glance project faces - review/feedback time, triaging ever growing bug list, BP \'validation and followup\' etc. I have some ideas to develop more momentum in each of these processes. With the advent of the Artifacts feature, new developers would be contributing to Glance. I would like to encourage and work with them become core members sooner than later. Also, there are many merge propositions which become stale due to lack of reviews from core-reviewers. My plan is to have bi-weekly sync-ups with the core and driver members to keep the review cycle active. As a good learning lesson from Juno, I would like to work closely with all the developers and involved core reviewers to know their sincere intent of accomplishing a feature within the scope of release timeline. There are some really talented people involved in Glance and I would like to keep synthesizing the ecosystem to enable everyone involved to do their best.\n\nLastly, my salutations to Mark. He has provided great direction and leadership to this project. I would like to keep his strategy of rotation of weekly meeting times to accommodate the convenience of people from various time zones.\n\nThanks for reading and I hope you will support my candidacy!\n\n[1] https://github.com/openstack/governance/blob/master/reference/programs.yaml#L26\n\n-Nikhil Komawar\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/82948b9b/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B62492FBC815@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-03 18:52:22',0,'2014-10-03 18:52:22',NULL,'[openstack-dev] [Glance] Let\'s deprecate the GridFS store (Fwd:\n [Openstack] [Glance] GridFS Store: Anyone using it?)','Thanks for bringing this up Flavio! Let\'s wait another week to get some feedback. Also, we can discuss the fate of this driver in our weekly meeting to be on safe side.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Flavio Percoco [flavio at redhat.com]\nSent: Friday, October 03, 2014 4:09 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [Glance] Let\'s deprecate the GridFS store (Fwd: [Openstack] [Glance] GridFS Store: Anyone using it?)\n\nGreetings,\n\nI\'ve sent the email below to the OpenStack users mailing list trying to\nget feedback from users on what to do with the GridFS driver.\n\nWe haven\'t had bugs filed on this driver nor users have provided any\nfeedback. This all leads me to think that it\'s actually not being used\nat all. With that in mind, I propose marking this driver as deprecated\nin Kilo.\n\nI wonder if we could simply remove it based on the above _assumption_\n\nCheers,\nFlavio\n\n\n-------- Original Message --------\nSubject: [Openstack] [Glance] GridFS Store: Anyone using it?\nDate: Fri, 26 Sep 2014 09:56:52 +0200\nFrom: Flavio Percoco <flavio at redhat.com>\nReply-To: flavio at redhat.com\nOrganization: Red Hat\nTo: openstack at lists.openstack.org\n\nGreetings,\n\nI\'m reaching out to see if anyone is using Glance\'s GridFS store driver\nand has any feedback. The driver has been updated with the latest API\nchanges but no fixes or feedback has been received.\n\nIf no one is using it, I\'ll propose removing it for the Kilo release.\nDrivers require maintenance, hence lots of time.\n\nCheers,\nFlavio\n\n--\n@flaper87\nFlavio Percoco\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<542E59AA.40403@redhat.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62492FBD466@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 19:02:44',0,'2014-10-06 19:02:44',NULL,'[openstack-dev] [Openstacl] [Glance] Container format','Adam,\n\ncontainer-format is an essential property within Glance. Specifying \'bare\' is not mandatory however, whatever applicable container-format for your deployment is necessary.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Adam Lawson [alawson at aqorn.com]\nSent: Monday, October 06, 2014 1:05 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [Openstacl] [Glance] Container format\n\nHi all, is there a reason that specifying a \'bare\' container format option is required from the operator given it isn\'t used by any Openstack services? [1]\n\n[1] http://docs.openstack.org/trunk/install-guide/install/apt/content/glance-verify.html (step4)\n\n\nAdam Lawson\n\nAQORN, Inc.\n427 North Tatnall Street\nSte. 58461\nWilmington, Delaware 19801-2230\nToll-free: (844) 4-AQORN-NOW ext. 101\nInternational: +1 302-387-4660\nDirect: +1 916-246-2072\n[http://www.aqorn.com/images/logo.png]\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141006/a77a84e9/attachment.html>\n\n','<CAJfWK4814UWicwXCN2Ciw+nHD=aMdQoAbtgQh3qPuZ7kGJOKsA@mail.gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62492FBFE54@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-10 17:47:32',0,'2014-10-10 17:47:32',NULL,'[openstack-dev] [Glance] Granularity of policies','Eddie,\n\n+1 on glance-spec\n\nWe might want to define the scope. How far are we diverging from Openstack policy structure? Are there any other use cases which need policy changes? - some questions which come to my mind.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Eddie Sheffield [eddie.sheffield at RACKSPACE.COM]\nSent: Monday, October 06, 2014 3:35 PM\nTo: OpenStack Dev List\nSubject: [openstack-dev] [Glance] Granularity of policies\n\nI encountered an interesting situation with Glance policies. Basically we have a situation where users in certain roles are not allowed to make certain calls at all. In this specific case, we don\'t want users in those roles listing or viewing members. When listing members, these users receive a 403 (Forbidden) but when showing an individual member the users receive 404 (Not Found).\n\nSo the problem is that there are a couple of situations here and we don\'t (can\'t?) distinguish the exact intent:\n\n1) A user IS allowed to make the call but isn\'t allowed to see a particular member - in that case 404 makes sense because a 403 could imply the user actually is there, you just can\'t look see them directly.\n\n2) A user IS NOT allowed to make the call at all. In this case a 403 makes more sense because the user is forbidden at the call level.\n\nAt this point I\'m mainly trying to spark some conversation on this. This feels a bit inconsistent if users get 403 for a whole set of calls they are barred from but 404 for others which are \"sub\" calls of the others (e.g. listing members vs. showing a specific one.) But I don\'t have a specific proposals at this time - first I\'m trying to find out if others feel this is a problem which should be addressed. If so I\'m willing to work on a blueprint and implementation.\n\n- Eddie\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/7ac76bc8/attachment.html>\n\n','<9B09B1BDCF89D642BA6C4DA506D20F8532BFC551@ORD1EXD01.RACKSPACE.CORP>',NULL),('<0FBF5631AB7B504D89C7E6929695B62492FDBA21@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 22:02:15',0,'2014-10-15 22:02:15',NULL,'[openstack-dev]  [Glance] Summit Topics','The summit planning etherpad [0] is up and available for discussing topics specifically for Glance during the design sessions.\n\nThe agenda for the contributors\' meetup will be kept open. If you\'ve more suggestions or need input on a topic which you would like to include as a part of the sessions, please ping me (nikhil_k) on IRC or attend the upcoming Glance meetings [1].\n\nFor more information on sessions related to other projects including cross-project sessions please visit the summit planning wiki page [2].\n\n[0] https://etherpad.openstack.org/p/kilo-glance-summit-topics\n[1] https://wiki.openstack.org/wiki/Meetings/Glance\n[2] https://wiki.openstack.org/wiki/Summit/Planning\n\nThanks,\nNikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/f19b38ca/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B62492FDC3BB@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 23:26:33',0,'2014-10-16 23:26:33',NULL,'[openstack-dev]  [Glance] Virtual Mini-Summit','We\'ve planned a online + IRC mini-summit for discussing Glance topics prior to the Paris summit. Please find the agenda as well as the topics which are currently included for the same in this [0] etherpad. If you\'ve a topic in mind just for this virtual summit, please feel free to add so in the same etherpad. I\'m planning to finalize the topics early next week.\n\nIf you\'re interested in attending; there is a doodle poll [1] which asks for your preferred date along with timezone in UTC (please see etherpad). Most likely we will just end up having the sessions spanned over 2 days. However, if you cannot make it both days please let me know your preferred topics in the etherpad [0].\n\nIf you\'ve any questions or concerns please feel free to reach out.\n\n[0] https://etherpad.openstack.org/p/kilo-glance-virtual-mini-summit\n[1] http://doodle.com/e42y2xvrhycqbmu5\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141016/f53bac1a/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B62492FDF7D4@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-22 01:31:56',0,'2014-10-22 01:31:56',NULL,'[openstack-dev] [Glance] Proposal to add reviewers requirement to\n the glance-specs.','Hi,\n\nI would like to propose the requirement of 2 reviewers (at least one of them being Glance core), for a spec in order to be approved.\n\nThis proposal is a step to better plan the development work and help the team prioritize on the reviews and features. The anticipation is that it will help commiters get regular feedback on the active feature-work being done. It will also help us reduce the push for any feature to be merged very late in the cycle that is currently keeping wormhole open for bugs.\n\nIf there are no objections, we will implement this change for all the features sitting in the review queue of glance-specs. The approved blueprints would be discussed with core reviewers to get a sense of their availability.\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141022/36e706cd/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B624930163D7@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-01 04:16:02',0,'2014-11-01 04:16:02',NULL,'[openstack-dev] [Glance] Poll for change in weekly meeting time.','Thanks for voting Louis!\n\nFinding a spot in a channel is always tricky. If we get early votes, we can determine our position for this [0] proposal.\n\n[0] http://osdir.com/ml/openstack-dev/2014-10/msg02119.html\n\n-Nikhil\n\n________________________________________\nFrom: Louis Taylor [kragniz at gmail.com]\nSent: Friday, October 31, 2014 6:08 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Glance] Poll for change in weekly meeting time.\n\nThanks for bringing this up, Nikhil.\n\nOn Fri, Oct 31, 2014, Nikhil Komawar wrote:\n> Here\'s a poll [0] to find what time-slots work best for everyone as well as\n> for the interest to remove the alternating time-slot aspect in the schedule.\n\nCould this poll be expanded with a wider range of times? I\'m sure people will\nbe happy with some time after 17:00 UTC, but not midnight, for example.\n\nAre all these timeslots available in #openstack-meeting*?\n\n> Please be empathetic in your votes, try to suggest all possible options that\n> would work for you and note the changes in your timezone due to day-light\n> savings ending. Please let me know if you\'ve any more questions.\n\nI\'m personally okay with the later time slot if it means some people can attend\nwho otherwise would not, but other commitments make that availability somewhat\nsporadic.\n\n\n','<20141031220843.GA31297@gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249301AA50@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-06 16:24:29',0,'2014-11-06 16:24:29',NULL,'[openstack-dev] [Glance] Paris Kilo summit update on contributors\'\n meetup on Friday','Hi,\n\nAs a result of the team having outstanding questions from the summit sessions as well as discussions prior and during the summit, the contributor\'s meetup has some planned discussion items. The schedule is posted at the etherpad [0]. Please reach out to Brian (cc-ed) herewith for any questions, requests and concerns.\n\n[0] https://etherpad.openstack.org/p/kilo-glance\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/3eb485ab/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B6249301E1E8@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 16:56:56',0,'2014-11-13 16:56:56',NULL,'[openstack-dev] [glance] Policy file not reloaded after changes','Hi Ajaya,\n\nWe\'r making some progress on sync-ing the latest Oslo-incubator code in Glance. It\'s a little more tricky due to the property protection feature so, we\'ve had some impedance. Please give your feedback at: https://review.openstack.org/#/c/127923/3\n\nPlease let me know if you\'ve any concerns.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Ajaya Agrawal [ajku.agr at gmail.com]\nSent: Thursday, November 13, 2014 4:50 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [glance] Policy file not reloaded after changes\n\nHi All,\n\nThe policy file is not reloaded in glance after a change is made to it. You need to restart glance to load the new policy file. I think all other components reload the policy file after a change is made to it. Is it a bug or intended behavior?\n\nCheers,\nAjaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/92a4837d/attachment.html>\n\n','<CAGncKO47q3aNX9VEQbhuyQ2haGzRCRBdw61dvMZJB9R4mZMMEA@mail.gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249301E22F@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 17:32:31',0,'2014-11-13 17:32:31',NULL,'[openstack-dev] [glance] Policy file not reloaded after changes','Forgot to mention the main part - this patch should enable the auto loading of policies.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Nikhil Komawar [nikhil.komawar at RACKSPACE.COM]\nSent: Thursday, November 13, 2014 11:56 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Policy file not reloaded after changes\n\nHi Ajaya,\n\nWe\'r making some progress on sync-ing the latest Oslo-incubator code in Glance. It\'s a little more tricky due to the property protection feature so, we\'ve had some impedance. Please give your feedback at: https://review.openstack.org/#/c/127923/3\n\nPlease let me know if you\'ve any concerns.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Ajaya Agrawal [ajku.agr at gmail.com]\nSent: Thursday, November 13, 2014 4:50 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [glance] Policy file not reloaded after changes\n\nHi All,\n\nThe policy file is not reloaded in glance after a change is made to it. You need to restart glance to load the new policy file. I think all other components reload the policy file after a change is made to it. Is it a bug or intended behavior?\n\nCheers,\nAjaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/515c0177/attachment.html>\n\n','<0FBF5631AB7B504D89C7E6929695B6249301E1E8@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249301FE23@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 18:23:36',0,'2014-11-17 18:23:36',NULL,'[openstack-dev] [stable] [glance] glance_store scheduled release\n 0.1.10','Hi all,\n\nFollowing last week\'s (mentioned) corrections to get Glance and the glance_store library come to stable state, we\'ve got a few changes [0, 1, 2] merged. The library is set for the next release in a couple hours or so.\n\nJust wanted to give a head\'s up and see if there were any concerns.\n\n[0] https://review.openstack.org/#/c/131528/\n[1] https://review.openstack.org/#/c/131838/\n[2] https://review.openstack.org/#/c/130200/\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/e6325976/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B6249301FF33@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 20:19:54',0,'2014-11-17 20:19:54',NULL,'[openstack-dev] [stable] [glance] glance_store scheduled\n release 0.1.10','This is done.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Nikhil Komawar\nSent: Monday, November 17, 2014 1:23 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [stable] [glance] glance_store scheduled release 0.1.10\n\nHi all,\n\nFollowing last week\'s (mentioned) corrections to get Glance and the glance_store library come to stable state, we\'ve got a few changes [0, 1, 2] merged. The library is set for the next release in a couple hours or so.\n\nJust wanted to give a head\'s up and see if there were any concerns.\n\n[0] https://review.openstack.org/#/c/131528/\n[1] https://review.openstack.org/#/c/131838/\n[2] https://review.openstack.org/#/c/130200/\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/53ccb636/attachment.html>\n\n','<0FBF5631AB7B504D89C7E6929695B6249301FE23@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493020590@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-18 18:55:14',0,'2014-11-18 18:55:14',NULL,'[openstack-dev] [Glance] Poll for change in weekly meeting time.','We\'ve had a few responses to this poll however, they do not seem to cover the entire set of developers including many of the cores and developers who are going to be actively working on the features this cycle.\n\nBased on the responses received, I\'d like to propose a (unified - no alternating) time of 14:30UTC on Thursdays (channel(s) TBD). This change will help the vast majority of developers who prefer the current earlier time slot as well as reduce the no-shows in the later one.\n\nIf you\'r not happy with the proposal please vote and (or) please reach out before this week\'s meeting on Thursday. Please let me know if you\'ve any concerns.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Nikhil Komawar\nSent: Friday, October 31, 2014 4:41 PM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Glance] Poll for change in weekly meeting time.\n\nHi all,\n\nIt was noticed in the past few meetings that the participation in the alternating time-slot of Thursday at 20 UTC (or called as \"later time slot\") was low. With the growing interest in Glance of developers from eastern latitudes and their involvement in meetings, please find this email as a proposal to move all meetings to an earlier time-slot.\n\nHere\'s a poll [0] to find what time-slots work best for everyone as well as for the interest to remove the alternating time-slot aspect in the schedule.\n\nPlease be empathetic in your votes, try to suggest all possible options that would work for you and note the changes in your timezone due to day-light savings ending. Please let me know if you\'ve any more questions.\n\n[0] http://doodle.com/nwc26k8satuyvvmz\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/5436c1dc/attachment.html>\n\n','<0FBF5631AB7B504D89C7E6929695B62493016311@ORD1EXD02.RACKSPACE.CORP>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493020C76@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 15:15:18',0,'2014-11-19 15:15:18',NULL,'[openstack-dev] [glance] Parallels loopback disk format support','Hi Maxim,\n\nThanks for showing interest in this aspect. Like nova-specs, Glance also needs a spec to be create for discussion related to the blueprint. \n\nPlease try to create one here [1]. Additionally you may join us at the meeting [2] if you feel stuck or need clarifications.\n\n[1] https://github.com/openstack/glance-specs\n[2] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Maxim Nestratov [mnestratov at parallels.com]\nSent: Wednesday, November 19, 2014 8:27 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [glance] Parallels loopback disk format support\n\nGreetings,\n\nIn scope of these changes [1], I would like to add a new image format\ninto glance. For this purpose there was created a blueprint [2] and\nwould really appreciate if someone from glance team could review this\nproposal.\n\n[1] https://review.openstack.org/#/c/111335/\n[2] https://blueprints.launchpad.net/glance/+spec/pcs-support\n\nBest,\n\nMaxim Nestratov,\nLead Software Developer,\nParallels\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<546C9ACF.6040005@parallels.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493020C97@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 15:27:13',0,'2014-11-19 15:27:13',NULL,'[openstack-dev] [Glance][stable] Review request','This patch is a bit different as it is not a straightforward cherry-pick from the commit in master (that fixes the bug). So, it seemed like a good idea to start the discussion.\n\nNonetheless, it\'s my bad turning into a miscommunication where the email just became a review request; while the intent was of a (possible) discussion/clarification.\n \nThanks,\n-Nikhil\n\n________________________________________\nFrom: Flavio Percoco [flavio at redhat.com]\nSent: Wednesday, November 19, 2014 3:59 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Glance][stable] Review request\n\nPlease, abstain to send review requests to the mailing list\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html\n\nThanks,\nFlavio\n\n>Hi All,\nOn 18/11/14 17:42 +0000, Kekane, Abhishek wrote:\n>\n>Greetings!!!\n>\n>\n>\n>Can anyone please review this patch [1].\n>\n>It requires one more +2 to get merged in stable/juno.\n>\n>\n>\n>We want to use stable/juno in production environment and this patch will fix\n>the blocker bug [1] for restrict download image feature.\n>\n>Please do the needful.\n>\n>\n>\n>[1] https://review.openstack.org/#/c/133858/\n>\n>[2] https://bugs.launchpad.net/glance/+bug/1387973\n>\n>\n>\n>\n>\n>Thank You in advance.\n>\n>\n>\n>Abhishek Kekane\n>\n>\n>______________________________________________________________________\n>Disclaimer: This email and any attachments are sent in strictest confidence\n>for the sole use of the addressee and may contain legally privileged,\n>confidential, and proprietary data. If you are not the intended recipient,\n>please advise the sender by replying promptly to this email and then delete\n>and destroy this email and any attachments without any further use, copying\n>or forwarding.\n\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n--\n@flaper87\nFlavio Percoco\n\n\n','<20141119085945.GM21362@redhat.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B624930211B2@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-20 00:33:13',0,'2014-11-20 00:33:13',NULL,'[openstack-dev] [glance] Parallels loopback disk format support','It would be good to have a small BP for bookkeeping purposes to the very least. (If you ping me on IRC when this is ready, promise to make this less painful). The idea being a good way to \"publish\" the image formats supported by Glance. Besides, this calls for Opt and Doc change which shall be reflected in release notes and such so good to have a spec/BP.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Fei Long Wang [feilong at catalyst.net.nz]\nSent: Wednesday, November 19, 2014 4:39 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [glance] Parallels loopback disk format support\n\nIIUC, the blueprint just want to add a new image format, and no code\nchange in Glance, is it? If that\'s the case, I\'m wondering if we really\nneed a blueprint/spec. Because the image format could be configured in\nglance-api.conf. Please correct me if I missed anything. Cheers.\n\n\nOn 20/11/14 02:27, Maxim Nestratov wrote:\n> Greetings,\n>\n> In scope of these changes [1], I would like to add a new image format\n> into glance. For this purpose there was created a blueprint [2] and\n> would really appreciate if someone from glance team could review this\n> proposal.\n>\n> [1] https://review.openstack.org/#/c/111335/\n> [2] https://blueprints.launchpad.net/glance/+spec/pcs-support\n>\n> Best,\n>\n> Maxim Nestratov,\n> Lead Software Developer,\n> Parallels\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n--\nCheers & Best regards,\nFei Long Wang (???)\n--------------------------------------------------------------------------\nSenior Cloud Software Engineer\nTel: +64-48032246\nEmail: flwang at catalyst.net.nz\nCatalyst IT Limited\nLevel 6, Catalyst House, 150 Willis Street, Wellington\n--------------------------------------------------------------------------\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<546D0E0E.4030509@catalyst.net.nz>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493024211@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 06:04:06',0,'2014-11-25 06:04:06',NULL,'[openstack-dev]  [Glance] Weekly-meeting time change.','Hi all,\n\nHappy Thanksgiving (in advance)! The meeting on Nov. 27th has been cancelled duly. So, we will be having the next meeting on Thursday, December 4th at 1400UTC. The meeting after will be on Dec 11th at 1500 UTC. (channel: #openstack-meeting-4 )\n\nPlease find the new alternating time slots and channel change for Glance weekly meetings here [0]. The weekly meeting details page is here [1]. Reference poll [2] as well as input from certain members have been used to decide on the time change.\n\nThis change has been made effective to help collaborators from different parts of the world be able to participate in the meetings. Hope it helps increase the participation which was going low in the past few weeks for the later time slot.\n\nPlease let me know if anyone has any concerns.\n\n[0] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting\n[1] https://wiki.openstack.org/wiki/Meetings/Glance\n[2] http://doodle.com/nwc26k8satuyvvmz\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141125/433c222d/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B624930246C8@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 20:16:49',0,'2014-11-25 20:16:49',NULL,'[openstack-dev] [Glance] [all] Proposal for new Glance core\n reviewers','Hi all,\n\nPlease consider this email as a nomination for Erno and Alex (CC) for adding them to the list of Glance core reviewers. Over the last cycle, both of them have been doing good work with reviews, participating in the project discussions as well as taking initiatives to creatively improve the project. Their insights into project internals and it\'s future directions has been valuable too.\n\nPlease let me know if anyone has concerns with this change. If there none brought up, I will make this membership change official in about a week.\n\nThanks for your consideration and the hard work, Erno and Alex!\n\nCheers!\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141125/ff6b4596/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B6249302849F@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 02:56:10',0,'2014-12-04 02:56:10',NULL,'[openstack-dev] [glance] Deprecating osprofiler option\n \'enabled\' in favour of \'profiler_enabled\'','Don\'t care either way, let\'s be consistent with other projects and raise this concern in next weekly cross-project meeting [1] to see what \"all\" of the projects mutually agree on. If there is no consensus, let\'s stick to what we have.\n\n@Louis: Can you please add that to the agenda of the cross-project meeting?\n\n[1] https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Ian Cordasco [ian.cordasco at RACKSPACE.COM]\nSent: Tuesday, December 02, 2014 10:32 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Deprecating osprofiler option \'enabled\' in favour of \'profiler_enabled\'\n\nExcept for the fact that the person who implemented this was told to\nchange the option name in other projects because it conflicted with a\ndifferent option. We can keep this if we?re worried about being too\nobvious (to the point of becoming the Department of Redundancy Department)\nwith our naming. I don?t think other projects will be very happy having to\nchange their naming especially if the original name was already a problem.\n\nOn 12/2/14, 06:12, \"Zhi Yan Liu\" <lzy.dev at gmail.com> wrote:\n\n>I totally agreed to make it to be consistent cross all projects, so I\n>propose to change other projects.\n>\n>But I think keeping it as-it is clear enough for both developer and\n>operator/configuration, for example:\n>\n>[profiler]\n>enable = True\n>\n>instead of:\n>\n>[profiler]\n>profiler_enable = True\n>\n>Tbh, the \"profiler\" prefix is redundant to me still from the\n>perspective of operator/configuration.\n>\n>zhiyan\n>\n>\n>On Tue, Dec 2, 2014 at 7:44 PM, Louis Taylor <kragniz at gmail.com> wrote:\n>> On Tue, Dec 02, 2014 at 12:16:44PM +0800, Zhi Yan Liu wrote:\n>>> Why not change other services instead of glance? I see one reason is\n>>> \"glance is the only one service use this option name\", but to me one\n>>> reason to keep it as-it in glance is that original name makes more\n>>> sense due to the option already under \"profiler\" group, adding\n>>> \"profiler\" prefix to it is really redundant, imo, and in other\n>>> existing config group there\'s no one go this naming way. Then in the\n>>> code we can just use a clear way:\n>>>\n>>>     CONF.profiler.enabled\n>>>\n>>> instead of:\n>>>\n>>>     CONF.profiler.profiler_enabled\n>>>\n>>> thanks,\n>>> zhiyan\n>>\n>> I agree this looks nicer in the code. However, the primary consumer of\n>>this\n>> option is someone editing it in the configuration files. In this case, I\n>> believe having something more verbose and consistent is better than the\n>>Glance\n>> code being slightly more elegant.\n>>\n>> One name or the other doesn\'t make all that much difference, but\n>>consistency in\n>> how we turn osprofiler on and off across projects would be best.\n>>\n>> - Louis\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D0A33720.6427%ian.cordasco@rackspace.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249302EBD4@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 21:35:15',0,'2014-12-16 21:35:15',NULL,'[openstack-dev] [glance] Option to skip deleting images in use?','+1\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Jay Pipes [jaypipes at gmail.com]\nSent: Tuesday, December 16, 2014 4:33 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [glance] Option to skip deleting images in use?\n\nOn 12/16/2014 04:23 PM, Chris St. Pierre wrote:\n> The goal here is protection against deletion of in-use images, not a\n> workaround that can be executed by an admin. For instance, someone\n> without admin still can\'t do that, and someone with a fat finger can\n> still delete images in use.\n\nThen set the protected property on the image, which prevents it from\nbeing deleted.\n\n From the glance CLI image-update help output:\n\n--is-protected [True|False]\n                         Prevent image from being deleted.\n\n> \"Don\'t lose your data\" is a fine workaround for taking backups, but most\n> of us take backups anyway. Same deal.\n>\n> On Tue, Dec 16, 2014 at 2:30 PM, Jay Pipes <jaypipes at gmail.com\n> <mailto:jaypipes at gmail.com>> wrote:\n>\n>     Just set the images to is_public=False as an admin and they\'ll\n>     disappear from everyone except the admin.\n>\n>     -jay\n>\n>\n>     On 12/16/2014 03:09 PM, Chris St. Pierre wrote:\n>\n>         Currently, with delay_delete enabled, the Glance scrubber happily\n>         deletes whatever images you ask it to. That includes images that are\n>         currently in use by Nova guests, which can really hose things.\n>         It\'d be\n>         nice to have an option to tell the scrubber to skip deletion of\n>         images\n>         that are currently in use, which is fairly trivial to check for and\n>         provides a nice measure of protection.\n>\n>         Without delay_delete enabled, checking for images in use likely\n>         takes\n>         too much time, so this would be limited to just images that are\n>         scrubbed\n>         with delay_delete.\n>\n>         I wanted to bring this up here before I go to the trouble of\n>         writing a\n>         spec for it, particularly since it doesn\'t appear that glance\n>         currently\n>         talks to Nova as a client at all. Is this something that folks\n>         would be\n>         interested in having? Thanks!\n>\n>         --\n>         Chris St. Pierre\n>\n>\n>         _________________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.__org\n>         <mailto:OpenStack-dev at lists.openstack.org>\n>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev\n>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>\n>\n>     _________________________________________________\n>     OpenStack-dev mailing list\n>     OpenStack-dev at lists.openstack.__org\n>     <mailto:OpenStack-dev at lists.openstack.org>\n>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>\n>\n>\n>\n> --\n> Chris St. Pierre\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5490A50E.4000605@gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249302EC45@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 22:56:22',0,'2014-12-16 22:56:22',NULL,'[openstack-dev] [glance] Option to skip deleting images in use?','Hi Chris,\n\nApologies for not having heard your use case completely. From the description as well as the information you\'ve provided; it is my recommendation to use a protected property in Glance for the Image entity that is in use. You can then use it in the service of your choice (Nova, Cinder) for not deleting the same. It is that service which shall have more accurate information as well as be source of truth for the in-use state of the Image entity. Making a call out to different service (except backend stores) is out of the scope of Glance. (Nova is the client of Glance and we would like to avoid the circular dependency mess there!)\n\nHope it helps. Please let me know if you need more information.\n\nThanks and Regards,\n-Nikhil\n________________________________\nFrom: Chris St. Pierre [chris.a.st.pierre at gmail.com]\nSent: Tuesday, December 16, 2014 5:12 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Option to skip deleting images in use?\n\nNo, I\'m looking to prevent images that are in use from being deleted. \"In use\" and \"protected\" are disjoint sets.\n\nOn Tue, Dec 16, 2014 at 3:36 PM, Fei Long Wang <feilong at catalyst.net.nz<mailto:feilong at catalyst.net.nz>> wrote:\nHi Chris,\n\nAre you looking for the \'protected\' attribute? You can mark an image with \'protected\'=True, then the image can\'t be deleted by accidentally.\n\nOn 17/12/14 10:23, Chris St. Pierre wrote:\nThe goal here is protection against deletion of in-use images, not a workaround that can be executed by an admin. For instance, someone without admin still can\'t do that, and someone with a fat finger can still delete images in use.\n\n\"Don\'t lose your data\" is a fine workaround for taking backups, but most of us take backups anyway. Same deal.\n\nOn Tue, Dec 16, 2014 at 2:30 PM, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:\nJust set the images to is_public=False as an admin and they\'ll disappear from everyone except the admin.\n\n-jay\n\n\nOn 12/16/2014 03:09 PM, Chris St. Pierre wrote:\nCurrently, with delay_delete enabled, the Glance scrubber happily\ndeletes whatever images you ask it to. That includes images that are\ncurrently in use by Nova guests, which can really hose things. It\'d be\nnice to have an option to tell the scrubber to skip deletion of images\nthat are currently in use, which is fairly trivial to check for and\nprovides a nice measure of protection.\n\nWithout delay_delete enabled, checking for images in use likely takes\ntoo much time, so this would be limited to just images that are scrubbed\nwith delay_delete.\n\nI wanted to bring this up here before I go to the trouble of writing a\nspec for it, particularly since it doesn\'t appear that glance currently\ntalks to Nova as a client at all. Is this something that folks would be\ninterested in having? Thanks!\n\n--\nChris St. Pierre\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nChris St. Pierre\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nCheers & Best regards,\nFei Long Wang (???)\n--------------------------------------------------------------------------\nSenior Cloud Software Engineer\nTel: +64-48032246<tel:%2B64-48032246>\nEmail: flwang at catalyst.net.nz<mailto:flwang at catalyst.net.nz>\nCatalyst IT Limited\nLevel 6, Catalyst House, 150 Willis Street, Wellington\n--------------------------------------------------------------------------\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n--\nChris St. Pierre\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141216/72144e51/attachment.html>\n\n','<CAGwiO7ZGujhLBpW7oqBzTn1WW5xnSMGKLVym_ogFLMh3EvaYrg@mail.gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249302F16F@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-17 17:59:07',0,'2014-12-17 17:59:07',NULL,'[openstack-dev] [glance] Option to skip deleting images in use?','That looks like a decent alternative if it works. However, it would be too racy unless we we implement a test-and-set for such properties or there is a different job which queues up these requests and perform sequentially for each tenant.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Chris St. Pierre [chris.a.st.pierre at gmail.com]\nSent: Wednesday, December 17, 2014 10:23 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Option to skip deleting images in use?\n\nThat\'s unfortunately too simple. You run into one of two cases:\n\n1. If the job automatically removes the protected attribute when an image is no longer in use, then you lose the ability to use \"protected\" on images that are not in use. I.e., there\'s no way to say, \"nothing is currently using this image, but please keep it around.\" (This seems particularly useful for snapshots, for instance.)\n\n2. If the job does not automatically remove the protected attribute, then an image would be protected if it had ever been in use; to delete an image, you\'d have to manually un-protect it, which is a workflow that quite explicitly defeats the whole purpose of flagging images as protected when they\'re in use.\n\nIt seems like flagging an image as *not* in use is actually a fairly difficult problem, since it requires consensus among all components that might be using images.\n\nThe only solution that readily occurs to me would be to add something like a filesystem link count to images in Glance. Then when Nova spawns an instance, it increments the usage count; when the instance is destroyed, the usage count is decremented. And similarly with other components that use images. An image could only be deleted when its usage count was zero.\n\nThere are ample opportunities to get out of sync there, but it\'s at least a sketch of something that might work, and isn\'t *too* horribly hackish. Thoughts?\n\nOn Tue, Dec 16, 2014 at 6:11 PM, Vishvananda Ishaya <vishvananda at gmail.com<mailto:vishvananda at gmail.com>> wrote:\nA simple solution that wouldn?t require modification of glance would be a cron job\nthat lists images and snapshots and marks them protected while they are in use.\n\nVish\n\nOn Dec 16, 2014, at 3:19 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com<mailto:Sean_Collins2 at cable.comcast.com>> wrote:\n\n> On Tue, Dec 16, 2014 at 05:12:31PM EST, Chris St. Pierre wrote:\n>> No, I\'m looking to prevent images that are in use from being deleted. \"In\n>> use\" and \"protected\" are disjoint sets.\n>\n> I have seen multiple cases of images (and snapshots) being deleted while\n> still in use in Nova, which leads to some very, shall we say,\n> interesting bugs and support problems.\n>\n> I do think that we should try and determine a way forward on this, they\n> are indeed disjoint sets. Setting an image as protected is a proactive\n> measure, we should try and figure out a way to keep tenants from\n> shooting themselves in the foot if possible.\n>\n> --\n> Sean M. Collins\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nChris St. Pierre\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141217/94e60dfd/attachment.html>\n\n','<CAGwiO7Y+Bs=eNxqZCBSjqrY3=UyFEAGO-Co7QGBgrCrcpoGQHg@mail.gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249302F2A2@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-17 20:33:51',0,'2014-12-17 20:33:51',NULL,'[openstack-dev] [glance] Option to skip deleting images in use?','Guess that\'s a implementation detail. Depends on the way you go about using what\'s available now, I suppose.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Chris St. Pierre [chris.a.st.pierre at gmail.com]\nSent: Wednesday, December 17, 2014 2:07 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Option to skip deleting images in use?\n\nI was assuming atomic increment/decrement operations, in which case I\'m not sure I see the race conditions. Or is atomism assuming too much?\n\nOn Wed, Dec 17, 2014 at 11:59 AM, Nikhil Komawar <nikhil.komawar at rackspace.com<mailto:nikhil.komawar at rackspace.com>> wrote:\nThat looks like a decent alternative if it works. However, it would be too racy unless we we implement a test-and-set for such properties or there is a different job which queues up these requests and perform sequentially for each tenant.\n\nThanks,\n-Nikhil\n________________________________\nFrom: Chris St. Pierre [chris.a.st.pierre at gmail.com<mailto:chris.a.st.pierre at gmail.com>]\nSent: Wednesday, December 17, 2014 10:23 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [glance] Option to skip deleting images in use?\n\nThat\'s unfortunately too simple. You run into one of two cases:\n\n1. If the job automatically removes the protected attribute when an image is no longer in use, then you lose the ability to use \"protected\" on images that are not in use. I.e., there\'s no way to say, \"nothing is currently using this image, but please keep it around.\" (This seems particularly useful for snapshots, for instance.)\n\n2. If the job does not automatically remove the protected attribute, then an image would be protected if it had ever been in use; to delete an image, you\'d have to manually un-protect it, which is a workflow that quite explicitly defeats the whole purpose of flagging images as protected when they\'re in use.\n\nIt seems like flagging an image as *not* in use is actually a fairly difficult problem, since it requires consensus among all components that might be using images.\n\nThe only solution that readily occurs to me would be to add something like a filesystem link count to images in Glance. Then when Nova spawns an instance, it increments the usage count; when the instance is destroyed, the usage count is decremented. And similarly with other components that use images. An image could only be deleted when its usage count was zero.\n\nThere are ample opportunities to get out of sync there, but it\'s at least a sketch of something that might work, and isn\'t *too* horribly hackish. Thoughts?\n\nOn Tue, Dec 16, 2014 at 6:11 PM, Vishvananda Ishaya <vishvananda at gmail.com<mailto:vishvananda at gmail.com>> wrote:\nA simple solution that wouldn?t require modification of glance would be a cron job\nthat lists images and snapshots and marks them protected while they are in use.\n\nVish\n\nOn Dec 16, 2014, at 3:19 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com<mailto:Sean_Collins2 at cable.comcast.com>> wrote:\n\n> On Tue, Dec 16, 2014 at 05:12:31PM EST, Chris St. Pierre wrote:\n>> No, I\'m looking to prevent images that are in use from being deleted. \"In\n>> use\" and \"protected\" are disjoint sets.\n>\n> I have seen multiple cases of images (and snapshots) being deleted while\n> still in use in Nova, which leads to some very, shall we say,\n> interesting bugs and support problems.\n>\n> I do think that we should try and determine a way forward on this, they\n> are indeed disjoint sets. Setting an image as protected is a proactive\n> measure, we should try and figure out a way to keep tenants from\n> shooting themselves in the foot if possible.\n>\n> --\n> Sean M. Collins\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nChris St. Pierre\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n--\nChris St. Pierre\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141217/67e7cf7b/attachment.html>\n\n','<CAGwiO7YyR7Yu=L7WyBGEz62D748gxLz2ZoEhL22j0S5FX8EEqQ@mail.gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493031D52@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-23 21:14:21',0,'2014-12-23 21:14:21',NULL,'[openstack-dev]  [Glance] No meetings for two weeks.','Hi all,\n\nIn the spirit of the holiday season, the next two meetings for Glance have been cancelled i.e. the ones on Dec 25th and Jan 1st [0]. Let\'s meet back on the 7th. Of couse, please feel free to ping me on IRC/email if you\'ve any questions, concerns or suggestions.\n\nHappy holidays!\n\n[0] https://etherpad.openstack.org/p/glance-team-meeting-agenda\n\nCheers!\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141223/c3898168/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B6249303434F@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-05 16:07:48',0,'2015-01-05 16:07:48',NULL,'[openstack-dev] [Glance] IRC logging','Based on the feedback received, we would like to avoid logging on the project channel. My take from the discussion was that it gives many a folks a feeling of informal platform to express their ideas freely in contrast to the meeting channels.\n\nHowever, at the same time I would like to point out that using foul language in the open freenode channels is a bad practice. There are no admins monitoring our project channels however, those channels that are monitored have people kicked out on misbehavior.  The point being, \"no logging\" means freedom of thought for only the creative purposes; please do not take me any other way.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Anita Kuno [anteaya at anteaya.info]\nSent: Monday, January 05, 2015 10:42 AM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [Glance] IRC logging\n\nOn 01/05/2015 06:42 AM, Cindy Pallares wrote:\n> Hi all,\n>\n> I would like to re-open the discussion on IRC logging for the glance\n> channel. It was discussed on a meeting back in November[1], but it\n> didn\'t seem to have a lot of input from the community and it was not\n> discussed in the mailing list. A lot of information is exchanged through\n> the channel and it isn\'t accessible for people who occasionally come\n> into our channel from other projects, new contributors, and people who\n> don\'t want to be reached off-hours or don\'t have bouncers. Logging our\n> channel would  increase our community\'s transparency and make our\n> development discussions publicly accessible to contributors in all\n> time-zones and from other projects. It is very useful to look back on\n> the logs for previous discussions or as well as to refer people to\n> discussions or questions previously answered.\n>\n>\n> --Cindy\n>\n> [1]\n> http://eavesdrop.openstack.org/meetings/glance/2014/glance.2014-11-13-20.03.log.html\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi Cindy:\n\nYou might want to consider offering a patch (you can use this one as an\nexample: https://review.openstack.org/#/c/138965/2) and anyone with a\nstrong perspective can express themselves with a vote and comment.\n\nThanks,\nAnita.\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54AAB0E1.8060605@anteaya.info>',NULL),('<0FBF5631AB7B504D89C7E6929695B624930343C7@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-05 17:04:58',0,'2015-01-05 17:04:58',NULL,'[openstack-dev] [Glance] IRC logging','Appreciate the feedback, Morgan!\n\nCindy: I do not mind if you open up a Merge Prop for this change (link it on this mail loop) and ask for a poll on the gerrit review.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Morgan Fainberg [morgan.fainberg at gmail.com]\nSent: Monday, January 05, 2015 11:57 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Glance] IRC logging\n\n> On Jan 5, 2015, at 08:07, Nikhil Komawar <nikhil.komawar at RACKSPACE.COM> wrote:\n>\n> Based on the feedback received, we would like to avoid logging on the project channel. My take from the discussion was that it gives many a folks a feeling of informal platform to express their ideas freely in contrast to the meeting channels.\n>\n> However, at the same time I would like to point out that using foul language in the open freenode channels is a bad practice. There are no admins monitoring our project channels however, those channels that are monitored have people kicked out on misbehavior.  The point being, \"no logging\" means freedom of thought for only the creative purposes; please do not take me any other way.\n>\n> Thanks,\n> -Nikhil\n>\n\nI just want to point out that keystone has logging enabled for our channel and I do not see it as a hamper to creative discussion / open discussion. The logging is definitely of value. Also a lot of people will locally log a given irc channel, which largely nets the same result.\n\nIt is still not an official meeting, and we have heated debates at times, the logging let\'s us check back on things discussed outside of the official meetings. I do admit it is used less frequently than the meeting logs.\n\n--Morgan\n\nSent via mobile\n> ________________________________________\n> From: Anita Kuno [anteaya at anteaya.info]\n> Sent: Monday, January 05, 2015 10:42 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Glance] IRC logging\n>\n>> On 01/05/2015 06:42 AM, Cindy Pallares wrote:\n>> Hi all,\n>>\n>> I would like to re-open the discussion on IRC logging for the glance\n>> channel. It was discussed on a meeting back in November[1], but it\n>> didn\'t seem to have a lot of input from the community and it was not\n>> discussed in the mailing list. A lot of information is exchanged through\n>> the channel and it isn\'t accessible for people who occasionally come\n>> into our channel from other projects, new contributors, and people who\n>> don\'t want to be reached off-hours or don\'t have bouncers. Logging our\n>> channel would  increase our community\'s transparency and make our\n>> development discussions publicly accessible to contributors in all\n>> time-zones and from other projects. It is very useful to look back on\n>> the logs for previous discussions or as well as to refer people to\n>> discussions or questions previously answered.\n>>\n>>\n>> --Cindy\n>>\n>> [1]\n>> http://eavesdrop.openstack.org/meetings/glance/2014/glance.2014-11-13-20.03.log.html\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> Hi Cindy:\n>\n> You might want to consider offering a patch (you can use this one as an\n> example: https://review.openstack.org/#/c/138965/2) and anyone with a\n> strong perspective can express themselves with a vote and comment.\n>\n> Thanks,\n> Anita.\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<80DAA300-C781-4352-9F27-203D4EEF4EF4@gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249303447A@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-05 19:10:44',0,'2015-01-05 19:10:44',NULL,'[openstack-dev] [Glance] IRC logging','Thanks Cindy!\n\nGlance cores, can you all please pitch in?\n\n-Nikhil\n\n________________________________________\nFrom: Cindy Pallares [cpallares at redhat.com]\nSent: Monday, January 05, 2015 12:28 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [Glance] IRC logging\n\nI\'ve made a patch, we can vote on it there.\n\nhttps://review.openstack.org/#/c/145025/\n\n\nOn 01/05/2015 11:15 AM, Amrith Kumar wrote:\n> I think logging the channel is a benefit even if, as Nikhil points out, it is not an official meeting. Trove logs both the #openstack-trove channel and the meetings when they occur. I have also had some conversations with other ATC\'s on #openstack-oslo and #openstack-security and have found that the eavesdrop logs at http://eavesdrop.openstack.org/irclogs/ to be invaluable in either bug comments or code review comments.\n>\n> The IRC channel is an integral part of communicating within the OpenStack community. The use of foul language and other inappropriate behavior should be monitored not by admins but by other members of the community and called out just as one would call out similar behavior in a non-virtual work environment. I submit to you that profanity and inappropriate conduct in an IRC channel constitutes a hostile work environment just as much as it does in a non-virtual environment.\n>\n> Therefore I submit to you that there is no place for such behavior on an IRC channel irrespective of whether it is logged or not.\n>\n> Thanks,\n>\n> -amrith\n>\n> | -----Original Message-----\n> | From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com]\n> | Sent: Monday, January 05, 2015 11:58 AM\n> | To: OpenStack Development Mailing List (not for usage questions)\n> | Subject: Re: [openstack-dev] [Glance] IRC logging\n> |\n> |\n> |\n> | > On Jan 5, 2015, at 08:07, Nikhil Komawar <nikhil.komawar at RACKSPACE.COM>\n> | wrote:\n> | >\n> | > Based on the feedback received, we would like to avoid logging on the\n> | project channel. My take from the discussion was that it gives many a\n> | folks a feeling of informal platform to express their ideas freely in\n> | contrast to the meeting channels.\n> | >\n> | > However, at the same time I would like to point out that using foul\n> | language in the open freenode channels is a bad practice. There are no\n> | admins monitoring our project channels however, those channels that are\n> | monitored have people kicked out on misbehavior.  The point being, \"no\n> | logging\" means freedom of thought for only the creative purposes; please\n> | do not take me any other way.\n> | >\n> | > Thanks,\n> | > -Nikhil\n> | >\n> |\n> | I just want to point out that keystone has logging enabled for our channel\n> | and I do not see it as a hamper to creative discussion / open discussion.\n> | The logging is definitely of value. Also a lot of people will locally log\n> | a given irc channel, which largely nets the same result.\n> |\n> | It is still not an official meeting, and we have heated debates at times,\n> | the logging let\'s us check back on things discussed outside of the\n> | official meetings. I do admit it is used less frequently than the meeting\n> | logs.\n> |\n> | --Morgan\n> |\n> | Sent via mobile\n> | > ________________________________________\n> | > From: Anita Kuno [anteaya at anteaya.info]\n> | > Sent: Monday, January 05, 2015 10:42 AM\n> | > To: openstack-dev at lists.openstack.org\n> | > Subject: Re: [openstack-dev] [Glance] IRC logging\n> | >\n> | >> On 01/05/2015 06:42 AM, Cindy Pallares wrote:\n> | >> Hi all,\n> | >>\n> | >> I would like to re-open the discussion on IRC logging for the glance\n> | >> channel. It was discussed on a meeting back in November[1], but it\n> | >> didn\'t seem to have a lot of input from the community and it was not\n> | >> discussed in the mailing list. A lot of information is exchanged\n> | >> through the channel and it isn\'t accessible for people who\n> | >> occasionally come into our channel from other projects, new\n> | >> contributors, and people who don\'t want to be reached off-hours or\n> | >> don\'t have bouncers. Logging our channel would  increase our\n> | >> community\'s transparency and make our development discussions\n> | >> publicly accessible to contributors in all time-zones and from other\n> | >> projects. It is very useful to look back on the logs for previous\n> | >> discussions or as well as to refer people to discussions or questions\n> | previously answered.\n> | >>\n> | >>\n> | >> --Cindy\n> | >>\n> | >> [1]\n> | >> http://eavesdrop.openstack.org/meetings/glance/2014/glance.2014-11-13\n> | >> -20.03.log.html\n> | >>\n> | >>\n> | >> _______________________________________________\n> | >> OpenStack-dev mailing list\n> | >> OpenStack-dev at lists.openstack.org\n> | >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | > Hi Cindy:\n> | >\n> | > You might want to consider offering a patch (you can use this one as\n> | > an\n> | > example: https://review.openstack.org/#/c/138965/2) and anyone with a\n> | > strong perspective can express themselves with a vote and comment.\n> | >\n> | > Thanks,\n> | > Anita.\n> | >\n> | > _______________________________________________\n> | > OpenStack-dev mailing list\n> | > OpenStack-dev at lists.openstack.org\n> | > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> | >\n> | > _______________________________________________\n> | > OpenStack-dev mailing list\n> | > OpenStack-dev at lists.openstack.org\n> | > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> |\n> | _______________________________________________\n> | OpenStack-dev mailing list\n> | OpenStack-dev at lists.openstack.org\n> | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54AAC9D3.5060705@redhat.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B624930344D3@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-05 19:25:15',0,'2015-01-05 19:25:15',NULL,'[openstack-dev] [Glance] Participation count for mid-cycle meetup.','Hi all,\n\nFor all those of you planning to be at the Glance kilo-mid-cycle meetup and haven\'t added your name to the list, please do so here https://etherpad.openstack.org/p/kilo-glance-mid-cycle-meetup . We need the info for scheduling purposes.\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150105/72e78715/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B62493063DAF@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-12 15:28:02',0,'2015-01-12 15:28:02',NULL,'[openstack-dev] [Glance] IRC logging','+1 to Flavio\'s proposal.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Flavio Percoco [flavio at redhat.com]\nSent: Monday, January 12, 2015 3:16 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Glance] IRC logging\n\nOn 09/01/15 12:11 -0800, Joshua Harlow wrote:\n>So the only comment I\'ll put in is one that I know not everyone agrees\n>with but might as well throw it out there.\n>\n>http://freenode.net/channel_guidelines.shtml (this page has a bunch of\n>useful advice IMHO).\n>\n>From that; something useful to look/think over at least...\n>\n>\"\"\"\n>If you\'re considering publishing channel logs, think it through. The\n>freenode network is an interactive environment. Even on public\n>channels, most users don\'t weigh their comments with the idea that\n>they\'ll be enshrined in perpetuity. For that reason, few participants\n>publish logs.\n>\n>If you\'re publishing logs on an ongoing basis, your channel topic\n>should reflect that fact. Be sure to provide a way for users to make\n>comments without logging, and get permission from the channel owners\n>before you start. If you\'re thinking of \"anonymizing\" your logs\n>(removing information that identifies the specific users), be aware\n>that it\'s difficult to do it well?replies and general context often\n>provide identifying information which is hard to filter.\n>\n>If you just want to publish a single conversation, be careful to get\n>permission from each participant. Provide as much context as you can.\n>Avoid the temptation to publish or distribute logs without permission\n>in order to portray someone in a bad light. The reputation you save\n>will most likely be your own.\n>\"\"\"\n\n(Joshua, the below is not about what you posted, I really appreciate\nyou bringing the above into the discussion)\n\nFWIW, I kind of feel that channel logging should become an OpenStack\nthing and not a per-project thing. Log all openstack \"official\"\nchannels, make it clear in the\nwiki/homepage/HoToContribute/WhateverYouWannaCallIt and move on.\n\nNothing, absolutely nothing, prevents the above from happening right\nnow. I\'ve local (as in my ZNC server) logs of the last 1y 1/2 and I\ncould just make them public.\n\nReally, IRC is basically(?) public by default and I - I know this is\nprobably personal opinion - don\'t think there\'s a difference between a\nlogged channel and a not logged one. If we wanted to make the channel\nprivate, we should password protect it and invite few people, make\nthem sign a contract where they swear they won\'t publish logs and\nwhatnot.\n\nAnyway, I think a good way to avoid these discussions for future\nprojects is to simply enable logging on all openstack- channels.\n\nCheers,\nFlavio\n\n\n>\n>Brian Rosmaita wrote:\n>>The response on the review is overwhelmingly positive (or, strictly\n>>speaking, unanimously non-negative).\n>>\n>>If anyone has an objection, could you please register it before 12:00\n>>UTC on Monday, January 12?\n>>\n>>https://review.openstack.org/#/c/145025/\n>>\n>>thanks,\n>>brian\n>>------------------------------------------------------------------------\n>>*From:* David Stanek [dstanek at dstanek.com]\n>>*Sent:* Wednesday, January 07, 2015 4:43 PM\n>>*To:* OpenStack Development Mailing List (not for usage questions)\n>>*Subject:* Re: [openstack-dev] [Glance] IRC logging\n>>\n>>It\'s also important to remember that IRC channels are typically not\n>>private and are likely already logged by dozens of people anyway.\n>>\n>>On Tue, Jan 6, 2015 at 1:22 PM, Christopher Aedo <caedo at mirantis.com\n>><mailto:caedo at mirantis.com>> wrote:\n>>\n>>    On Tue, Jan 6, 2015 at 2:49 AM, Flavio Percoco <flavio at redhat.com\n>>    <mailto:flavio at redhat.com>> wrote:\n>>    >  Fully agree... I don\'t see how enable logging should be a limitation\n>>    >  for freedom of thought. We\'ve used it in Zaqar since day 0 and it\'s\n>>    >  bee of great help for all of us.\n>>    >\n>>    >  The logging does not remove the need of meetings where decisions and\n>>    >  more relevant/important topics are discussed.\n>>\n>>    Wanted to second this as well. I\'m strongly in favor of logging -\n>>    looking through backlogs of chats on other channels has been very\n>>    helpful to me in the past, and it sure to help others in the future.\n>>    I don\'t think there is danger of anyone pointing to a logged IRC\n>>    conversation in this context as some statement of record.\n>>\n>>    -Christopher\n>>\n>>    _______________________________________________\n>>    OpenStack-dev mailing list\n>>    OpenStack-dev at lists.openstack.org\n>>    <mailto:OpenStack-dev at lists.openstack.org>\n>>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>\n>>--\n>>David\n>>blog: http://www.traceback.org\n>>twitter: http://twitter.com/dstanek\n>>www: http://dstanek.com\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n--\n@flaper87\nFlavio Percoco\n\n\n','<20150112081633.GI6043@redhat.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B6249306F6C1@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 21:36:16',0,'2015-01-14 21:36:16',NULL,'[openstack-dev] [Glance] Gentle reminder: Glance mid-cycle meetup\n for Kilo.','Hi,\n\nFor those of you, who might have missed my previous announcement [0], please find the venue and tentative schedule for the Glance mid-cycle meetup for Kilo cycle here [1]. It asks for your participation confirmation in the list so, if you are planning to attend please do fill out the needful information.\n\n[0] http://osdir.com/ml/openstack-dev/2015-01/msg00098.html\n[1] https://etherpad.openstack.org/p/kilo-glance-mid-cycle-meetup\n\nThanks again!\n\nCheers,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150114/1b33fa4b/attachment.html>\n\n',NULL,NULL),('<0FBF5631AB7B504D89C7E6929695B62493072CFF@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-19 19:21:12',0,'2015-01-19 19:21:12',NULL,'[openstack-dev] [glance] Replication on image create','Hi Boden,\n\nIt would be great to open up a BP/spec on this.\n\nAs far as the flexibility of adding scripts to tasks is concerned, there are 2 points to be considered:\n\n1. Glance will maintain a _published_ list of acceptable tasks. Meaning, it would be documented somewhere that a task of type \"A\" would work with glance and how to _extend_ it as per deployer use-case. Currently, 3 types namely, import, export and clone tasks have been approved. Clone could fit into your usecase depending on the location where you need the data copied.\n2. We are planning to merge \"TaskFlow\" executor [0] in k2 (or k3) that will enable extending the flows of the tasks.\n\nIt would be best if we can discuss this on the spec to keep stuff documented.\n\n[0] https://review.openstack.org/#/c/130076\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Boden Russell [bodenvmw at gmail.com]\nSent: Monday, January 19, 2015 9:39 AM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [glance] Replication on image create\n\n> On 1/15/15 12:59 AM, Flavio Percoco wrote:\n> All that being said, it\'d be very nice if you could open a spec on\n> this topic so we can discuss over the spec review and one of us (or\n> you) can implement it if we reach consensus.\n\n\nI\'ll create a BP + spec; doing a little homework now...\n\nW / R / T the async task plugins -- are there plans to make the task\ndefinitions more pluggable? Based on what I see right now it appears the\ndefinitions are static[1].\n\nI was expecting to see the list of \"applicable\" tasks to be defined via\nstevedore entry points or via conf file properties.\n\ne.g.\n[entry_points]\nglance.async.tasks =\n        import = glance.common.scripts.image_import\n        replicate = glance.common.scripts.image_repl\n        # etc...\n\n\nPerhaps there\'s already a BP on this topic, but I didn\'t find one.\n\nThanks\n\n[1]\nhttps://github.com/openstack/glance/blob/master/glance/domain/__init__.py#L316\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54BD171D.6000107@gmail.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493073C67@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 21:15:13',0,'2015-01-21 21:15:13',NULL,'[openstack-dev] [all] Cross-project DevRef Was Re: Skipping\n Cross-Project meeting today','>From Glance\' point of view: We can start off with the modifications needed on top of the existing one(s). Prepare a Glance specific doc to share in a Cross Project meeting.\n\nThanks,\n-Nikhil\n\n________________________________________\nFrom: Ian Cordasco [ian.cordasco at RACKSPACE.COM]\nSent: Wednesday, January 21, 2015 3:27 PM\nTo: jsbryant at electronicjungle.net; OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [all] Cross-project DevRef Was Re: Skipping Cross-Project meeting today\n\nOn 1/20/15, 21:21, \"Jay Bryant\" <jsbryant at electronicjungle.net> wrote:\n\n>+2  This topic had come up in Cinder I believe as well.\n>Having a common devref for common content would be good and would make it\n>easier to keep the documentation current.\n>\n>Jay\n>On Jan 20, 2015 4:05 PM, \"Jay Pipes\" <jaypipes at gmail.com> wrote:\n>\n>On 01/20/2015 01:30 PM, Ian Cordasco wrote:\n>On Jan 20, 2015, at 05:23, Thierry Carrez <thierry at openstack.org>\n>wrote:\n>\n>Hi everyone,\n>\n>Given that the agenda docket is pretty slim this week, I\'d like to\n>skip this cross-project meeting and have the next one on Jan 27.\n>\n>sigmavirus24 posted the \"Cross-project DevRef akin to Nova\'s\" item\n>but I\'d prefer if we discussed it on the mailing-list first (not\n>certain it requires everyone\'s attention just yet, and could just\n>be proposed as a spec).\n>\n>Cheers,\n>\n>-- Thierry Carrez (ttx)\n>\n>__________________________________________________________________________\n>\n>\n>\n>\n>\n>\n>OpenStack Development Mailing List (not for usage questions)\n>Unsubscribe:\n>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n><http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n>Hey all,\n>\n>First, let me provide some context. The week before last, an update\n>to sqlalchemy-migrate broke glance?s gate. While helping us fix the\n>problem, Matt Riedemann noticed that the project doesn?t have a\n>Developer Reference document. The document helps new developers\n>determine what system packages they need to build a development\n>environment for the project.\n>\n>We discussed the idea of putting one together for glance at the team\n>meeting last week. While discussing it, we realized a lot of the\n>steps are similar to Nova?s and it might benefit OpenStack as a whole\n>to have one common DevRef that links off to individual ones for\n>further configuration. The list of common steps could be maintained\n>in one place (rather than synchronized between projects) and then\n>individual extensions would be maintained with in each project or\n>wiki.\n>\n>Before we started duplicating content in our own document, we wanted\n>to present the idea to the cross-project team and the community as a\n>whole.\n>\n>Feedback is greatly appreciated, Ian\n>\n>\n>\n>I think a common shared developer reference is a great idea, Ian. ++\n>\n>-jay\n>\n>__________________________________________________________________________\n>OpenStack Development Mailing List (not for usage questions)\n>Unsubscribe:\n>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n><http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nSince no one has expressed distaste for this idea. What?s the best way to\nmove forward? I genuinely have no idea what the right next step is and\nwould appreciate some guidance here.\n\nCheers,\nIan (sigmavirus24)\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D0E56788.814A%ian.cordasco@rackspace.com>',NULL),('<0FBF5631AB7B504D89C7E6929695B62493075519@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 23:11:07',0,'2015-01-22 23:11:07',NULL,'[openstack-dev]  [Glance] New Glance Drivers.','Hi all,\n\nPlease join me in welcoming Flavio and Ian to the Glance Drivers team.\n\nThey have been doing some quality work in Glance; each of them brings in his own skill set to the team. We would be happy to rely on the two main traits of these individuals - they are aware about general workings of OpenStack and are quite active on the Images program. Their feedback on the features as well as bugs has been a motivating factor for the developers and the criticism has been constructive. Their help in the releases of python-glanceclient and glance_store libraries has been great as well.\n\nWelcome Ian and Flavio!\n\nP.S. You both would soon be added to the launchpad team.\n\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150122/d5d29693/attachment.html>\n\n',NULL,NULL),('<0FC3886A-E54F-47A9-B857-80AC5ECF5639@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-13 09:31:30',-14400,'2014-05-13 13:31:30',NULL,'[openstack-dev] [mistral] Inviting everyone to design session at\n	2pm (B306)','I?m inviting everyone interested in Mistral (Workflow Service for OpenStack) to a design session today at 2pm (room B306). We?ll be talking about further Mistral development direction and it?s very important to gather as much feedback as possible.\n\nSession: http://junodesignsummit.sched.org/event/4fb1a7be3d4cb74df9bdd3d4e9a60508#.U3IdsF5RE04\nEtherpad: https://etherpad.openstack.org/p/juno-summit-mistral\n\nI would really recommend to watch a 15 min screencast to have a background for a productive discussion.\n\nScreencast: https://www.youtube.com/watch?v=x-zqz1CRVkI\n\nThanks, looking forward to see you there!\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140513/c770dbf1/attachment.html>\n\n',NULL,NULL),('<0fc401f5b7bd4157bd0f5406fd691aa6@AMSPR05MB406.eurprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-14 08:25:56',0,'2014-09-14 08:25:56',NULL,'[openstack-dev] [Neutron][Architecture]Suggestions for the\n third vendors\' plugin and driver','Hi,\nWhile keeping focused on defining proper approach to deal with Neutron third vendors? plugin and driver, we also need to provide solution for complimentary critical piece of code maintained in the Nova code base.\nIntroducing new vif_type by neutron L2 Plugin/Driver, requires adding vif plugging support at Nova side.\nI think it is very important to enable  virt driver  extensibility to support out of the tree/future vif_types.\nIf the direction is to keep vendor plugins/drivers external to Neutron core, it seems reasonable to impose same policy on the Nova side.\n\nBR,\nIrena\n\nFrom: Kevin Benton [mailto:blak111 at gmail.com]\nSent: Friday, September 12, 2014 12:19 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nCc: tanny.wu at huawei.com\nSubject: Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third vendors\' plugin and driver\n\n> So my suggestion is remove all vendors\' plugins and drivers except opensource as built-in.\n\nYes, I think this is currently the view held by the PTL (Kyle) and some of the other cores so what you\'re suggesting will definitely come up at the summit.\n\n\n> Why do we need a different repo to store vendors\' codes? That\'s not the community business.\n> I think only a proper architecture and normal NB&SB API can bring \"a clear separation between plugins(or drivers) and core code\", not a different repo.\n\nThe problem is that that architecture won\'t stay stable if there is no shared community plugin depending on its stability. Let me ask you the inverse question. Why do you think the reference driver should stay in the core repo?\n\nA separate repo won\'t have an impact on what is packaged and released so it should have no impact on \"user experience\", \"complete versions\", \"providing code examples\",  or \"developing new features\". In fact, it will likely help with the last two because it will provide a clear delineation between what a plugin is responsible for vs. what the core API is responsible for. And, because new cores can be added faster to the open source plugins repo due to a smaller code base to learn, it will help with developing new features by reducing reviewer load.\n\nOn Fri, Sep 12, 2014 at 1:50 AM, Germy Lure <germy.lure at gmail.com<mailto:germy.lure at gmail.com>> wrote:\n\n\nOn Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton <blak111 at gmail.com<mailto:blak111 at gmail.com>> wrote:\n\n> Maybe I missed something, but what\'s the solution?\n\nThere isn\'t one yet. That\'s why it\'s going to be discussed at the summit.\nSo my suggestion is remove all vendors\' plugins and drivers except opensource as built-in.\nBy leaving open source plugins and drivers in the tree , we can resolve such problems:\n  1)release a workable and COMPLETE version\n  2)user experience(especially for beginners)\n  3)provide code example to learn for new contributors and vendors\n  4)develop and verify new features\n\n\n> I think we should release a workable version.\n\nDefinitely. But that doesn\'t have anything to do with it living in the same repository. By putting it in a different repo, it provides smaller code bases to learn for new contributors wanting to become a core developer in addition to a clear separation between plugins and core code.\nWhy do we need a different repo to store vendors\' codes? That\'s not the community business.\nI think only a proper architecture and normal NB&SB API can bring \"a clear separation between plugins(or drivers) and core code\", not a different repo.\nOf course, if the community provides a wiki page for vendors to add hyperlink of their codes, I think it\'s perfect.\n\n> Besides of user experience, the open source drivers are also used for developing and verifying new features, even small-scale case.\n\nSure, but this also isn\'t affected by the code being in a separate repo.\nSee comments above.\n\n> The community should and just need focus on the Neutron core and provide framework for vendors\' devices.\n\nI agree, but without the open source drivers being separated as well, it\'s very difficult for the framework for external drivers to be stable enough to be useful.\nArchitecture and API. The community should ensure core and API stable enough and high quality. Vendors for external drivers.\nWho provides, who maintains(including development, storage, distribution, quality, etc).\n\nOn Thu, Sep 11, 2014 at 7:24 PM, Germy Lure <germy.lure at gmail.com<mailto:germy.lure at gmail.com>> wrote:\nSome comments inline.\n\nBR,\nGermy\n\nOn Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton <blak111 at gmail.com<mailto:blak111 at gmail.com>> wrote:\nThis has been brought up several times already and I believe is going to be discussed at the Kilo summit.\nMaybe I missed something, but what\'s the solution?\n\nI agree that reviewing third party patches eats community time. However, claiming that the community pays 46% of it\'s energy to maintain vendor-specific code doesn\'t make any sense. LOC in the repo has very little to do with ongoing required maintenance. Assuming the APIs for the plugins stay consistent, there should be few \'maintenance\' changes required to a plugin once it\'s in the tree. If there are that many changes to plugins just to keep them operational, that means Neutron is far too unstable to support drivers living outside of the tree anyway.\nYes, you are right. \"Neutron is far too unstable to support drivers living outside of the tree anyway\". So I think this is really our important point.\nThe community should focus on standardizing NB&SB API, introducing and improving new features NOT wasting energy to introduce and maintain vendor-specific codes.\n\nOn a related note, if we are going to pull plugins/drivers out of Neutron, I think all of them should be removed, including the OVS and LinuxBridge ones. There is no reason for them to be there if Neutron has stable enough internal APIs to eject the 3rd party plugins from the repo. They should be able to live in a separate neutron-opensource-drivers repo or something along those lines. This will free up significant amounts of developer/reviewer cycles for neutron to work on the API refactor, task based workflows, performance improvements for the DB operations, etc.\nI think we should release a workable version. User can experience the functions powered by built-in components. And they can replace them with\nthe release of those vendors who cooperate with them. The community should not work for vendor\'s codes.\n\nIf the open source drivers stay in the tree and the others are removed, there is little incentive to keep the internal APIs stable and 3rd party drivers sitting outside of the tree will break on every refactor or data structure change. If that\'s the way we want to treat external driver developers, let\'s be explicit about it and just post warnings that 3rd party drivers can break at any point and that the onus is on the external developers to learn what changed an react to it. At some point they will stop bothering with Neutron completely in their deployments and mimic its public API.\nBesides of user experience, the open source drivers are also used for developing and verifying new features, even small-scale case.\n\nA clear separation of the open source drivers/plugins and core Neutron would give a much better model for 3rd party driver developers to follow and would enforce a stable internal API in the Neutron core.\nThe community should and just need focus on the Neutron core and provide framework for vendors\' devices. Vendors just need adapt Neutron API and focus on their codes\' quality. If not, I think the architecture is not proper. Everyone should only carry their own monkey.\n\n\n\nOn Thu, Sep 11, 2014 at 1:54 AM, Germy Lure <germy.lure at gmail.com<mailto:germy.lure at gmail.com>> wrote:\nHi stackers,\n\nAccording to my statistics(J2), the LOC of vendors\' plugin and driver is about 102K, while the whole under neutron is 220K.\nThat is to say the community has paid and is paying over 46% energy to maintain vendors\' code. If we take mails, bugs,\nBPs  and so on into consideration, this percentage will be more.\n\nMost of these codes are just plugins and drivers implementing almost  the same functions. Every vendor submits a plugin,\nand the community only do the same thing, repeat and repeat. Meaningless.I think it\'s time to move them out.\nLet\'s focus on improving those exist but still weak features, on introducing important and interesting new features.\n\nMy suggestions now:\n1.monopolized plugins\n  1)The community only standards NB API and keeps built-ins, such as ML2, OVS and Linux bridge plugins.\n  2)Vendors maintain their plugins locally.\n  3)Users get neutron from community and plugin from some vendor on demand.\n2.service plugins\n  1)The community standards SB API and keeps open source driver(iptables, openSwan and etc.) as built-in.\n  2)Vendors only provide drivers not plugin. And those drivers also need not deliver to community.\n  3)Like above, Users can get code on demand from vendors or just use open source.\n3.ML2 plugin\n  1)Like service and monopolized plugin, the community just keep open source implementations as built-in.\n  2)L2-population should be kept.\n\nI am very happy to discuss this further.\n\nvendors\' code stat. table(excluding built-in plugins and drivers)\n------------------------------------------------------------\nPath                                                     Size\nneutron-master\\neutron\\plugins\\    63170\nneutron-master\\neutron\\services\\     4052\nneutron-master\\neutron\\tests\\             35756\n\nBR,\nGermy\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nKevin Benton\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nKevin Benton\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nKevin Benton\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140914/52b3d02d/attachment.html>\n\n','<CAO_F6JOzv4G-zsPB5dt67_LcRHHrKg7a0Ji+PPNNugQi+yF0pA@mail.gmail.com>',NULL),('<0FCE6672-6950-4134-96C1-A3D6CCDDFE2A@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 17:22:06',-18000,'2014-09-11 22:22:06',NULL,'[openstack-dev] [nova] Server Groups - remove VM from group?','I would be a little wary about the DB level locking for stuff like that ? it?s certainly doable, but also comes at the expense of things behaving ever-so-slightly different from DBMS to DBMS.  Perhaps there are multiple ?logical efforts? here?i.e., adding some APIs and cleaning up existing code.\n\nIn any case, I?ve started a blueprint on this [1] and we can continue iterating in the nova-spec once kilo opens up.  Thanks all for the good discussion on this thus far.\n\n[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups\n\n- Joe\nOn Sep 11, 2014, at 5:04 PM, Chris Friesen <chris.friesen at windriver.com> wrote:\n\n> On 09/11/2014 03:01 PM, Jay Pipes wrote:\n>> On 09/11/2014 04:51 PM, Matt Riedemann wrote:\n>>> On 9/10/2014 6:00 PM, Russell Bryant wrote:\n>>>> On 09/10/2014 06:46 PM, Joe Cropper wrote:\n>>>>> Hmm, not sure I follow the concern, Russell.  How is that any different\n>>>>> from putting a VM into the group when it?s booted as is done today?\n>>>>>  This simply defers the ?group insertion time? to some time after\n>>>>> initial the VM?s been spawned, so I?m not sure this creates anymore\n>>>>> race\n>>>>> conditions than what?s already there [1].\n>>>>> \n>>>>> [1] Sure, the to-be-added VM could be in the midst of a migration or\n>>>>> something, but that would be pretty simple to check make sure its task\n>>>>> state is None or some such.\n>>>> \n>>>> The way this works at boot is already a nasty hack.  It does policy\n>>>> checking in the scheduler, and then has to re-do some policy checking at\n>>>> launch time on the compute node.  I\'m afraid of making this any worse.\n>>>> In any case, it\'s probably better to discuss this in the context of a\n>>>> more detailed design proposal.\n>>>> \n>>> \n>>> This [1] is the hack you\'re referring to right?\n>>> \n>>> [1]\n>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2014.2.b3#n1297\n>>> \n>> \n>> That\'s the hack *I* had in the back of my mind.\n> \n> I think that\'s the only boot hack related to server groups.\n> \n> I was thinking that it should be possible to deal with the race more cleanly by recording the selected compute node in the database at the time of scheduling.  As it stands, the host is implicitly encoded in the compute node to which we send the boot request and nobody else knows about it.\n> \n> Chris\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/fe5764cf/attachment.html>\n\n','<54121C69.7090208@windriver.com>',NULL),('<0FD26FEB-234D-45FE-ADC4-84023FE114F3@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 20:02:50',0,'2014-11-17 20:02:50',NULL,'[openstack-dev] Hyper-V CI missing logs','Hi all,\n\nWe have experienced a severe hardware failure and the storage for the logs of the CI runs was also being affected. We have recovered all that could be saved on the new dedicated server. \n\nIf you find any patchset that has the logs missing, please issue a ?check hyper-v? command to generate a new run and ensure that the latest logs will be present. \n\nPlease let us know of any other issues you might have regarding the Hyper-V CI.\n\nThanks,\n\nOctavian.\n\n',NULL,NULL),('<0FD26FEB-234D-45FE-ADC4-84023FE114F3@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-11-17 20:02:50',0,'2014-11-17 20:02:50',NULL,'[OpenStack-Infra] Hyper-V CI missing logs','Hi all,\n\nWe have experienced a severe hardware failure and the storage for the logs of the CI runs was also being affected. We have recovered all that could be saved on the new dedicated server. \n\nIf you find any patchset that has the logs missing, please issue a ?check hyper-v? command to generate a new run and ensure that the latest logs will be present. \n\nPlease let us know of any other issues you might have regarding the Hyper-V CI.\n\nThanks,\n\nOctavian.\n\n',NULL,NULL),('<0FD7DB48-AAF7-4949-AFF2-0F9046B0ACEF@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-11 20:58:07',-28800,'2013-02-12 04:58:07',NULL,'[openstack-dev] Help needed with a db query issue','I reported this bug separately and solved it:\n\nhttps://code.launchpad.net/bugs/1122316\n\nI didn\'t notice the thread issue you mentioned so there may be more to be done if you can get a repro case. I only noticed the issue on restarting nova-compute.\n\nFYI the join you want if that is still necessary is:\n\njoinedload_all(\'instances.system_metadata\')\n\nVish\n\nOn Feb 8, 2013, at 10:01 AM, \"Day, Phil\" <philip.day at hp.com> wrote:\n\n> Hi Folks,\n>  \n> I?ve been trying to track down the cause of this bug which is causing us a bit of grief at the moment:\n>  \n> https://bugs.launchpad.net/nova/+bug/1118608\n>  \n> There are two issues in here:\n>  \n> The first is a timing issue between a thread creating an instance and another request which comes back into the compute manager via the network manager to refresh the security group before the original thread has got to the point where it has populated the global ?network_infos? structure inside the firewall driver.\n>  \n> I think I can fix this by adding a synchronisation lock to the incoming call, so it waits for any instance creation to finish.  I?ve posted this fix for review (open to other ideas on how to fix this)\n>  \n>  \n> The second issue is further into this call  _get_instance_network_info in network/api.py is trying to extract the rxtx_factor value from the instance[?instance_type?] ? but the instance record doesn?t seem to have that information.\n>  \n> Looking at the db call that gets the instance data in the first place, db.security_group_get(), it doesn?t look as if it tries to do this join:\n>  \n> result = _security_group_get_query(context, session=session,\n>                                        project_only=True).\\\n>                     filter_by(id=security_group_id).\\\n>                     options(joinedload_all(\'instances\')).\\\n>                     first()\n>  \n> In my naivety I tried adding\n>                  options(joinedload_all(\'instance_type\')).\\\n>  \n> to the query but to no effect.   \n>  \n> It doesn?t look like adding a call to conductor to get the instance_type data inside network/api  is the right way to go -  so can someone suggest another way to make this work ?\n>  \n>  \n> (BTW it?s only the rxtx factor that is trying to be extracted from the instance_type ? which based on a recent thread in here is only used in Xen at the moment.   Looking at the code its not obvious to me why this is even needed at this point).\n>  \n>  \n> Thanks,\n> Phil\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130211/ba63b662/attachment.html>\n\n','<BD26CCD58723F74AA8E6BCB31052A1F001D810B2@G6W2501.americas.hpqcorp.net>',NULL),('<0FDFB953-8677-4E86-B642-88339F84CB07@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-07-30 13:41:56',0,'2014-07-30 13:41:56',NULL,'[Openstack-stable-maint] Patchsets waiting for review since\n 120+ days','Hi Ihar,\n\nOn 30 Jul 2014, at 11:34, Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> On 29/07/14 23:52, Alessandro Pilotti wrote:\n>> Hi guys,\n>> \n>> We have a list of Hyper-V bug backports which are waiting since\n>> April or May to be reviewed / merged.\n>> \n>> Most of them received already a +2.\n>> \n>> It?d be great if somebody could help in getting them approved.\n>> \n>> \n>> https://review.openstack.org/#/c/83520 \n>> https://review.openstack.org/#/c/83361 \n>> https://review.openstack.org/#/c/83370 \n>> https://review.openstack.org/#/c/83371 \n>> https://review.openstack.org/#/c/83527 \n>> https://review.openstack.org/#/c/83428 \n>> https://review.openstack.org/#/c/84144 \n>> https://review.openstack.org/#/c/84145 \n>> https://review.openstack.org/#/c/83229 \n>> https://review.openstack.org/#/c/83360/\n> \n> Most (all?) of those patches have wrong Change-Id. Please make sure\n> you retain the original Change-Id when backporting a patch. Once you\n> resend them with proper Ids, gerrit will create new reviews for those,\n> and you will need to abandon those with wrong Ids. After that, you can\n> reach back here and ask to review those new backports again.\n\nMost of those patches have already a +2, it would have been great to receive\na review about the wrong change Id in the last 3-4 months while the patch\nwere just waiting.\n\nI?ll notify the authors now.\n\nThanks,\n\nAlessandro\n\n> \n>> \n>> \n>> Thanks,\n>> \n>> Alessandro\n>> \n>> \n>> \n>> \n>> _______________________________________________ \n>> Openstack-stable-maint mailing list \n>> Openstack-stable-maint at lists.openstack.org \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n>> \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n> \n> iQEcBAEBCgAGBQJT2K4aAAoJEC5aWaUY1u57pRIIANqWKXlT6B4k5lk/5BEBC8q4\n> 0jdEDU/s5JnydOLM1wERncWy5pVYqg0L7ib9O5+pO9lPmVqaX6XdNTQ2HgMKclyc\n> GqR6MSQGaSyt5QLTWVUql0t8ixOrKOVZiZUVnWQmfcqRUph56fyikXl8rTa2bzDv\n> lDXy5b7q4rOmrjhrgKMPhLxNTG8fgy7aRbGorL//Tzun1SE079C9KbaBxB6Liu4n\n> 3E0VugYBIxq384UysGB3YA47fueDJib5b817j7QCsnfEo+c2O3vIFFXA2OMAjKqL\n> YB6CXZWJ6pdAFS9V9iS70JrJ+rIxaxKpBg0p+6JkUpQE8wyQ2FOnUw4KzA+SDmo=\n> =Mj+2\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n\n','<53D8AE1A.3040001@redhat.com>',NULL),('<0FE8E360-B593-45C8-BCBA-DA6FEE3B0E04@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-15 13:13:57',-18000,'2012-07-15 18:13:57',NULL,'[OpenStack Foundation] board chair == two votes -was- Re:\n	Technical Committee: new draft','Thanks for the feedback everyone. We\'ve removed the chairperson\'s double vote in the final version of the Bylaws. We\'re posting the updates and will send a note when they\'re up.\n\nJonathan\n\n\nOn Jul 12, 2012, at 12:52 PM, Carl Trieloff wrote:\n\n> \n> +1\n> Carl.\n> \n> On 07/12/2012 11:06 AM, Jim Jagielski wrote:\n>> Agreed. Anytime you need someone to forcibly \"break a tie\", you\'ve\n>> created a precedent than driving consensus really isn\'t needed since\n>> the chair will just decide stuff anyway.\n>> \n>> Believe it or not, when a community *really* feels totally empowered,\n>> they understand that it\'s in everyone\'s interest to have collaboration\n>> and consensus.\n>> \n>> On Thu, Jul 12, 2012 at 10:58 AM, Christopher B Ferris\n>> <chrisfer at us.ibm.com> wrote:\n>>> Kurt,\n>>> \n>>> While I fully agree with your description of the goals and the sad state of\n>>> affairs where we have dueling corporate interests that have split the\n>>> community, if the issues really are just about two equally good ideas, then\n>>> you don\'t need a chair making the decision, what you need then is an\n>>> effective chair who understands how to tease consensus out of a group, say\n>>> by asking thinks like \"who cannot live with option X\", etc\n>>> \n>>> My $0.02 USD\n>>> \n>>> Sent from my iPad\n>>> \n>>> \n>>> On Jul 11, 2012, at 5:29 PM, Kurt.Garloff at telekom.de wrote:\n>>> \n>>>> Hi Doug,\n>>>> \n>>>> no reasonable committee of any kind should be happy to pass votes with 50%\n>>>> plus a tie-breaking  double-count ...\n>>>> I have been working in OSS projects for most of my life and reaching\n>>>> consensus or near-consensus was the norm, not the exception in any project\n>>>> that I participated in.\n>>>> \n>>>> That should be the goal for any decision-body as well, and if we end up\n>>>> being in a situation where we often have near 50% decisions, we\'re in\n>>>> serious trouble. I would dare to say that this would rather be an indication\n>>>> that most of our discussions are driven by conflicting corporate interests\n>>>> rather than enthusiasts who try to work out the best solution to a problem.\n>>>> We\'re in deep trouble if this happens and the fact we may have tie-breaking\n>>>> rules that we don\'t like is one of our smallest problems then ...\n>>>> \n>>>> That said, there might be situations where we have two options and one is\n>>>> as good as the other ... if for some reason people can\'t agree, it is\n>>>> sometimes the worst option to not take a decision, so having some\n>>>> tie-breaking capability then is useful. It should be used in exceptional\n>>>> cases only -- if we are afraid that it might be abused, we might want to\n>>>> restrict it. Maybe create a rule that the tie-breaking double vote can\'t be\n>>>> used when a topic is brought up for decision first -- only when we could not\n>>>> come to a decision and need to reconvene a second time to discuss and take a\n>>>> decision on the same topic, then it may be used.\n>>>> \n>>>> Just my 0.02EUR.\n>>>> \n>>>> Best,\n>>>> --\n>>>> Kurt\n>>>> \n>>>> Kurt Garloff | VP Engineering DBU Cloud Services | Products & Innovation |\n>>>> Deutsche Telekom AG | http://www.telekom.com/\n>>>> Landgrabenweg 151 | 53227 Bonn | Germany\n>>>> B2/5.15 | +49 151 6130 9858 (mobile), +49 228 936 17013 (office), +49 228\n>>>> 936 17009 (fax) | kurt.garloff at telekom.de\n>>>> (T-Online-Allee 1 |64295 Darmstadt | Germany | 4B.K26 | +49 6151 680 6312)\n>>>> \n>>>> Life is for sharing.\n>>>> \n>>>> Deutsche Telekom AG | Supervisory Board: Prof. Dr. Ulrich Lehner\n>>>> (Chairman) | Board of Management: Ren? Obermann (Chairman), Reinhard\n>>>> Clemens, Niek Jan van Damme, Timotheus H?ttges, Dr. Thomas Kremer, Claudia\n>>>> Nemat, Prof. Dr. Marion Schick\n>>>> Commercial register: Amtsgericht Bonn HRB 6794 | Registered office: Bonn |\n>>>> WEEE reg. no. DE50478376\n>>>> \n>>>> \n>>>>> -----Original Message-----\n>>>>> From: Doug Davis [mailto:dug at us.ibm.com]\n>>>>> Sent: Thursday, July 05, 2012 10:48 PM\n>>>>> To: Lloyd Dewolf\n>>>>> Cc: foundation at lists.openstack.org\n>>>>> Subject: Re: [OpenStack Foundation] board chair == two votes\n>>>>> -was- Re: Technical Committee: new draft\n>>>>> \n>>>>> Yes, its the tie situation that I\'m preferring to.  To me\n>>>>> either the vote reaches the threshold or it doesn\'t.  50%\n>>>>> isn\'t the threshold so it fails.\n>>>>> \n>>>>> There\'s also the interesting case where multiple people from\n>>>>> the same company get to vote in the same ballot - I think its\n>>>>> because the same company can have  both platinum (or gold -\n>>>>> can\'t remember which right now) as well as individual\n>>>>> members, and that\'s another sore point for me but I\'ll leave\n>>>>> that for another day.  :-)  But its those kinds of rules that\n>>>>> make things seem a lot more complicated than they need to be.\n>>>>> Once company, one vote is much easier.\n>>>>> \n>>>>> thanks\n>>>>> -Doug\n>>>>> ________________________________________________________\n>>>>> STSM |  Standards Architect  |  IBM Software Group\n>>>>> (919) 254-6905  |  IBM 444-6905  |  dug at us.ibm.com The more\n>>>>> I\'m around some people, the more I like my dog.\n>>>>> \n>>>>> \n>>>>> \n>>>>> Lloyd Dewolf <lloydostack at gmail.com>\n>>>>> 07/05/2012 04:35 PM\n>>>>> \n>>>>> To\n>>>>> Doug Davis/Raleigh/IBM at IBMUS\n>>>>> cc\n>>>>> foundation at lists.openstack.org\n>>>>> Subject\n>>>>> board chair == two votes -was- Re: [OpenStack Foundation] Technical\n>>>>> Committee: new draft\n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> On Thu, Jul 5, 2012 at 1:26 PM, Doug Davis <dug at us.ibm.com> wrote:\n>>>>>> For example, I mentioned that I didn\'t like PTLs having\n>>>>> more power than\n>>>>>> anyone else, I think the same goes for the board chair.  In\n>>>>> the current\n>>>>>> foundation by-laws it talks about the chair having more\n>>>>> than one vote.\n>>>>> \n>>>>> Would you point to a specific section(s) where this comes into play?\n>>>>> \n>>>>> My understanding is the two vote only comes up in a scenario that\n>>>>> requires a tie break, often in a scenario when the chair won\'t have\n>>>>> voted in creating the tie, and the fact that it is two votes is just\n>>>>> how Delaware works.\n>>>>> \n>>>>> Thanks,\n>>>>> --\n>>>>> @lloyddewolf\n>>>>> http://www.pistoncloud.com/\n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> Foundation mailing list\n>>>>> Foundation at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>>>> \n>>>> _______________________________________________\n>>>> Foundation mailing list\n>>>> Foundation at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>>> \n>>> \n>>> _______________________________________________\n>>> Foundation mailing list\n>>> Foundation at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>> \n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n','<4FFF0EDC.40607@redhat.com>',NULL),('<0ffd733cc476e5b3ed39bb5be83bd5f7@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 07:17:41',7200,'2014-05-28 05:17:41',NULL,'[openstack-dev] [Openstack-docs] [Heat][Documentation] Heat\n template documentation','Le 2014-05-28 03:04, Steve Baker a ?crit?:\n> On 28/05/14 03:15, Gauvain Pocentek wrote:\n>> Le 2014-05-23 15:57, Anne Gentle a ?crit :\n>>> On Fri, May 23, 2014 at 8:42 AM, Steven Hardy <shardy at redhat.com> \n>>> wrote:\n>>> \n>>>> On Fri, May 23, 2014 at 08:09:06AM -0500, Anne Gentle wrote:\n>>>>> On Fri, May 23, 2014 at 6:19 AM, Steven Hardy <shardy at redhat.com>\n>>>>> wrote:\n>>>>> \n>>>>>> On Fri, May 23, 2014 at 12:38:40PM +0200, Andreas Jaeger wrote:\n>>>>>>> On 05/23/2014 12:13 PM, Steven Hardy wrote:\n>>>>>>>> [...]\n>>>>>>>> I\'ll hold my hand up as one developer who tried to contribute\n>>>>>>>> but ran\n>>>>>> away\n>>>>>>>> screaming due to all the XML-java-ness of the current process.\n>>>>>>>> I don\'t think markup complexity is a major barrier to \n>>>>>>>> contribution.\n>>>>>> Needing\n>>>>>>>> to use a closed source editor and download unfathomably huge\n>>>>>>>> amounts of\n>>>>>>>> java to build locally definitely are though IMO/IME.\n>>>>>>> You do not need a closed sourced editor for XML - I\'m using \n>>>>>>> emacs\n>>>>>>> and\n>>>>>>> others in the team use vi for it.\n>>>>>> Sure, maybe \"need\" was the wrong word to use, my apologies.\n>>>>>>  Regardless,\n>>>>>> the docs refer to a closed source tool being \"encouraged\", which\n>>>>>> immediately discouraged me when trying to figure out the \n>>>>>> workflow.\n>>>>>> I\'ve tried editing XML in vim a few times, and although it\'s\n>>>>>> obviously\n>>>>>> possible, it\'s far less painful when I\'m dealing with other more\n>>>>>> human-friendly formats.\n>>>>>> \n>>>>>>> Yes, it downloads a lot Java once. We also now build the\n>>>>>>> documents as\n>>>>>>> part of the gate, so you can also check changes by clicking the\n>>>>>>> \"checkbuild\" target, it will show you the converted books,\n>>>>>> Sure, that\'s good, but my (and I\'d guess many others) preference\n>>>>>> is for\n>>>>>> formats which can be easily built locally with only\n>>>>>> distro-provided tools,\n>>>>>> not a huge pile of third party java.\n>>>>>> Not trying to start a format-advocacy argument here, just trying\n>>>>>> to provide\n>>>>>> a data-point that, if the success criteria is developer\n>>>>>> participation in\n>>>>>> the docs process, then the current toolchain is definitely a\n>>>>>> barrier to\n>>>>>> participation for some potential contributors.\n>>>>>> \n>>>>> \n>>>>> Thanks for the discussions -- let\'s keep a tone of civility.\n>>>>> Understand\n>>>>> that doc writers have specific tools that work well for them. That\n>>>>> said, we\n>>>>> do want to collaborate more with our end users specifically.\n>>>> My apologies if my remarks have been interpreted as uncivil, that \n>>>> was\n>>>> definitely not my intention.\n>>> Oh no not at all, sorry -- my intent is that we are all staying \n>>> civil\n>>> and it\'s good. :)\n>>> \n>>> \n>>>> The only point I really wanted to convey was +1 on trying out an \n>>>> easier\n>>>> markup, and thanks for bringing up the topic of a user orientated\n>>>> orchestration guide - I would definitely like to contribute to the\n>>>> effort.\n>>> So we\'re still a little stuck on the tradeoffs -- with easier markup\n>>> we lose some features.\n>>> For other generated reference docs, we maintain a set of python\n>>> scripts in openstack-doc-tools. Is it possible for someone to look\n>>> into generating the Heat template reference information outside of\n>>> Sphinx?\n>> \n>> Yes, I can look into that.\n>> \n>> The idea would be to generate some docbook from RST... So why not do\n>> it for the whole to-be-written heat user guide in that case?\n>> \n>> What I get from this thread is that 1) docbook is the best format to\n>> use to generate a nice and feature-rich output, 2) developers don\'t\n>> want to write docbook. Without being able to handle a different \n>> format\n>> developers will no contribute, which is bad because they want, and we\n>> want them to contribute :)\n>> \n>> So my feeling is that we should work on the tools to convert RST (or\n>> whatever format, but RST seems to be the \"norm\" for openstack\n>> projects) to docbook, and generate our online documentation from\n>> there. There are tools that can help us doing that, and I don\'t see \n>> an\n>> other solution that would make us move forward.\n>> \n>> Anne, you talked about experimenting with the end user guide, and\n>> after the discussion and the technical info brought by Doug, Steve \n>> and\n>> Steven, I now think it is worth trying.\n>> \n> In this vein, I enabled the sphinx xml builder in heat:\n> https://review.openstack.org/#/c/95979/\n> \n> And here is a sample of the output:\n> http://paste.openstack.org/show/81811/\n> http://paste.openstack.org/show/81812/\n> \n> This looks like it could be readily transformed into DocBook via XSL.\n\nhttp://ebellot.chez.com/dn2dbk/index.htm could be used as a starting \npoint. It generates docbook 4, but can probably be easily modified to \ngenerate docbook 5, adapted to our conventions. The doc is in french, if \nanyone\'s interested I can do a quick translation of the important parts.\n\n> Alternatively we could write a Docutils writer which writes docbook\n> directly, possibly using this as a starting point:\n> http://docutils.sourceforge.net/sandbox/oliverr/docbook/\n> \n> Any takers to start playing with this?\n\nI need to dive into docutils writers to understand/maintain an internal \ntool of ours, so /me volunteers.\n\nI also looked at how pandoc handles the RST -> docbook conversion, but \nI don\'t think it\'s not good enough for our needs.\n\nI\'ll play with these tools this week to see which one is the best \noption for us.\n\nThanks!\nGauvain\n\n\n','<53853639.2020506@redhat.com>',NULL),('<0ffd733cc476e5b3ed39bb5be83bd5f7@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-05-28 07:17:41',7200,'2014-05-28 05:17:41',NULL,'[Openstack-docs] [openstack-dev] [Heat][Documentation] Heat\n template documentation','Le 2014-05-28 03:04, Steve Baker a ?crit?:\n> On 28/05/14 03:15, Gauvain Pocentek wrote:\n>> Le 2014-05-23 15:57, Anne Gentle a ?crit :\n>>> On Fri, May 23, 2014 at 8:42 AM, Steven Hardy <shardy at redhat.com> \n>>> wrote:\n>>> \n>>>> On Fri, May 23, 2014 at 08:09:06AM -0500, Anne Gentle wrote:\n>>>>> On Fri, May 23, 2014 at 6:19 AM, Steven Hardy <shardy at redhat.com>\n>>>>> wrote:\n>>>>> \n>>>>>> On Fri, May 23, 2014 at 12:38:40PM +0200, Andreas Jaeger wrote:\n>>>>>>> On 05/23/2014 12:13 PM, Steven Hardy wrote:\n>>>>>>>> [...]\n>>>>>>>> I\'ll hold my hand up as one developer who tried to contribute\n>>>>>>>> but ran\n>>>>>> away\n>>>>>>>> screaming due to all the XML-java-ness of the current process.\n>>>>>>>> I don\'t think markup complexity is a major barrier to \n>>>>>>>> contribution.\n>>>>>> Needing\n>>>>>>>> to use a closed source editor and download unfathomably huge\n>>>>>>>> amounts of\n>>>>>>>> java to build locally definitely are though IMO/IME.\n>>>>>>> You do not need a closed sourced editor for XML - I\'m using \n>>>>>>> emacs\n>>>>>>> and\n>>>>>>> others in the team use vi for it.\n>>>>>> Sure, maybe \"need\" was the wrong word to use, my apologies.\n>>>>>>  Regardless,\n>>>>>> the docs refer to a closed source tool being \"encouraged\", which\n>>>>>> immediately discouraged me when trying to figure out the \n>>>>>> workflow.\n>>>>>> I\'ve tried editing XML in vim a few times, and although it\'s\n>>>>>> obviously\n>>>>>> possible, it\'s far less painful when I\'m dealing with other more\n>>>>>> human-friendly formats.\n>>>>>> \n>>>>>>> Yes, it downloads a lot Java once. We also now build the\n>>>>>>> documents as\n>>>>>>> part of the gate, so you can also check changes by clicking the\n>>>>>>> \"checkbuild\" target, it will show you the converted books,\n>>>>>> Sure, that\'s good, but my (and I\'d guess many others) preference\n>>>>>> is for\n>>>>>> formats which can be easily built locally with only\n>>>>>> distro-provided tools,\n>>>>>> not a huge pile of third party java.\n>>>>>> Not trying to start a format-advocacy argument here, just trying\n>>>>>> to provide\n>>>>>> a data-point that, if the success criteria is developer\n>>>>>> participation in\n>>>>>> the docs process, then the current toolchain is definitely a\n>>>>>> barrier to\n>>>>>> participation for some potential contributors.\n>>>>>> \n>>>>> \n>>>>> Thanks for the discussions -- let\'s keep a tone of civility.\n>>>>> Understand\n>>>>> that doc writers have specific tools that work well for them. That\n>>>>> said, we\n>>>>> do want to collaborate more with our end users specifically.\n>>>> My apologies if my remarks have been interpreted as uncivil, that \n>>>> was\n>>>> definitely not my intention.\n>>> Oh no not at all, sorry -- my intent is that we are all staying \n>>> civil\n>>> and it\'s good. :)\n>>> \n>>> \n>>>> The only point I really wanted to convey was +1 on trying out an \n>>>> easier\n>>>> markup, and thanks for bringing up the topic of a user orientated\n>>>> orchestration guide - I would definitely like to contribute to the\n>>>> effort.\n>>> So we\'re still a little stuck on the tradeoffs -- with easier markup\n>>> we lose some features.\n>>> For other generated reference docs, we maintain a set of python\n>>> scripts in openstack-doc-tools. Is it possible for someone to look\n>>> into generating the Heat template reference information outside of\n>>> Sphinx?\n>> \n>> Yes, I can look into that.\n>> \n>> The idea would be to generate some docbook from RST... So why not do\n>> it for the whole to-be-written heat user guide in that case?\n>> \n>> What I get from this thread is that 1) docbook is the best format to\n>> use to generate a nice and feature-rich output, 2) developers don\'t\n>> want to write docbook. Without being able to handle a different \n>> format\n>> developers will no contribute, which is bad because they want, and we\n>> want them to contribute :)\n>> \n>> So my feeling is that we should work on the tools to convert RST (or\n>> whatever format, but RST seems to be the \"norm\" for openstack\n>> projects) to docbook, and generate our online documentation from\n>> there. There are tools that can help us doing that, and I don\'t see \n>> an\n>> other solution that would make us move forward.\n>> \n>> Anne, you talked about experimenting with the end user guide, and\n>> after the discussion and the technical info brought by Doug, Steve \n>> and\n>> Steven, I now think it is worth trying.\n>> \n> In this vein, I enabled the sphinx xml builder in heat:\n> https://review.openstack.org/#/c/95979/\n> \n> And here is a sample of the output:\n> http://paste.openstack.org/show/81811/\n> http://paste.openstack.org/show/81812/\n> \n> This looks like it could be readily transformed into DocBook via XSL.\n\nhttp://ebellot.chez.com/dn2dbk/index.htm could be used as a starting \npoint. It generates docbook 4, but can probably be easily modified to \ngenerate docbook 5, adapted to our conventions. The doc is in french, if \nanyone\'s interested I can do a quick translation of the important parts.\n\n> Alternatively we could write a Docutils writer which writes docbook\n> directly, possibly using this as a starting point:\n> http://docutils.sourceforge.net/sandbox/oliverr/docbook/\n> \n> Any takers to start playing with this?\n\nI need to dive into docutils writers to understand/maintain an internal \ntool of ours, so /me volunteers.\n\nI also looked at how pandoc handles the RST -> docbook conversion, but \nI don\'t think it\'s not good enough for our needs.\n\nI\'ll play with these tools this week to see which one is the best \noption for us.\n\nThanks!\nGauvain\n\n\n','<53853639.2020506@redhat.com>',NULL),('<0hj8mvxw55i5mww0kwtyedis.1326560047691@email.android.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-14 10:55:20',-21600,'2012-01-14 16:55:20',NULL,'[OpenStack Foundation] Linux Foundation as an inspiration','Dont read too much into the linux foundation comment. I just liked the clear writing style on their page, that\'s it. \n\n\n\nThor Wolpert <thor at wolpert.ca> wrote:\n\n>Based on discussions from a few months past, I thought the model was\n>more going to be like the Apache foundation.  A governance body,\n>project meritocracy and the ability allow and guide incubator projects\n>either into full core products, combine with another core project or\n>suggest valid alternatives.\n>\n>It already maps so closely to many of the other needs/wants under\n>OpenStack, that I thought that would be a shoe-in.\n>\n>What\'s changed?\n>\n>On Fri, Jan 13, 2012 at 8:55 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>> Hey,\n>>\n>> This article was re-tweeted by the OpenStack twitter account:\n>>\n>> ?http://www.itworld.com/cloud-computing/241213/openstack-steps-towards-its-foundation-future\n>>\n>> (I\'m guessing that it must be somewhat accurate if it was re-tweeted :-)\n>>\n>> ?\"Interestingly, Collier said the mission statement of the OpenStack\n>> ?Foundation was influenced by the mission statement of another such\n>> ?organization.\n>>\n>> ?The Linux Foundation\'s mission was a inspiration for the theme of the\n>> ?mission statement,\" Collier said. Some elements of the Linux\n>> ?Foundation\'s mission statement fit well for the OpenStack Foundation,\n>> ?he said.\"\n>>\n>> I\'d see the Linux Foundation as a radically different organization from\n>> what I\'d like to see for the OpenStack foundation e.g.\n>>\n>> ?- the Linux project is completely independent from the Linux\n>> ? ?Foundation, the latter is just there to support and promote the\n>> ? ?former\n>>\n>> ? ?the project has a benevolent dictator who decides a release\n>> ? ?schedule, where the code repositories live, what the policies of\n>> ? ?the project are etc.\n>>\n>> ? ?OpenStack clearly doesn\'t (yet) have such a dictator (benevolent or\n>> ? ?otherwise) so I had assumed the foundation board would assume\n>> ? ?ultimate responsibility for the project, but delegate a lot of it to\n>> ? ?a PPB or technical steering committee or the PTLs\n>>\n>> ?- individual Linux contributors aren\'t members of the foundation.\n>> ? ?Membership is split into gold/silver/bronze classes depending on\n>> ? ?how much you pay\n>>\n>> So, could someone highlight which elements of the Linux foundation wiki\n>> are a good fit for OpenStack?\n>>\n>> Thanks,\n>> Mark.\n>>\n>>\n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>_______________________________________________\n>Foundation mailing list\n>Foundation at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n',NULL,NULL),('<0MBP00M3AHMLT8I0@mailout1.samsung.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 02:01:30',0,'2012-10-11 02:01:30',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121011/f60cc448/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 201210111101840_QKNMBDIF.gif\nType: image/gif\nSize: 10014 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121011/f60cc448/attachment-0001.gif>\n\n',NULL,NULL),('<0u5v1wfmfbe8nvxwtyuuq2fa.1387462643949@email.android.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 14:17:25',0,'2013-12-19 14:17:25',NULL,'[openstack-dev] [heat] Nomination for heat-core','+1\n\n\nSent from my Verizon Wireless 4G LTE Smartphone\n\n\n\n-------- Original message --------\nFrom: Steve Baker <sbaker at redhat.com>\nDate: 12/18/2013 8:28 PM (GMT-06:00)\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [heat] Nomination for heat-core\n\n\nI would like to nominate Bartosz G?rski to be a heat-core reviewer. His reviews to date have been valuable and his other contributions to the project have shown a sound understanding of how heat works.\n\nHere is his review history:\nhttps://review.openstack.org/#/q/reviewer:bartosz.gorski%2540ntti3.com+project:openstack/heat,n,z\n\nIf you are heat-core please reply with your vote.\n\ncheers\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131219/15238a52/attachment.html>\n\n','<52B2583A.9000002@redhat.com>',NULL),('<10001CD7-A39B-4071-87A0-C1A5C40FD430@inaugust.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-10-17 09:41:11',-25200,'2014-10-17 16:41:11',NULL,'[Openstack-stable-maint] Stable check of openstack/keystone\n	failed','On October 17, 2014 1:02:08 AM PDT, Dave Walker <email at daviey.com> wrote:\n>On 17 Oct 2014 07:36, <jenkins <jenkins at openstack.org>@\n><jenkins at openstack.org>openstack.org <jenkins at openstack.org>> wrote:\n>>\n>> Build failed.\n>>\n>> - periodic-keystone-docs-icehousehttp\n><http://logs.openstack.org/periodic-stable/periodic-keystone-docs-icehouse/409d2f3>\n>://\n><http://logs.openstack.org/periodic-stable/periodic-keystone-docs-icehouse/409d2f3>\n>logs.openstack.org\n><http://logs.openstack.org/periodic-stable/periodic-keystone-docs-icehouse/409d2f3>\n>/periodic-stable/periodic-keystone-docs-icehouse/409d2f3\n><http://logs.openstack.org/periodic-stable/periodic-keystone-docs-icehouse/409d2f3>\n>:\n>SUCCESS in 3m 22s\n>> - periodic-keystone-python26-icehousehttp\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>://\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>logs.openstack.org\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>/periodic-stable/periodic-keystone-\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>python26\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>-icehouse/75222ab\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python26-icehouse/75222ab>\n>:\n>FAILURE in 29m 51s\n>> - periodic-keystone-python27-icehousehttp\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>://\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>logs.openstack.org\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>/periodic-stable/periodic-keystone-\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>python27\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>-icehouse/a72c727\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727>\n>:\n>FAILURE in 26m 49s\n>>\n>\n>Hi,\n>\n>This looks like a false alarm, looking at the console log it is\n>showing:\n>2014-10-17 06:33:33.294\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727/console.html#_2014-10-17_06_33_33_294>\n>|\n>+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n>2014-10-17 06:33:33.296\n><http://logs.openstack.org/periodic-stable/periodic-keystone-python27-icehouse/a72c727/console.html#_2014-10-17_06_33_33_296>\n>|\n>sudo: unable to resolve host bare-precise-hpcloud-b2-2666447\n>\n>Therefore I think it is an infra bug and not looking further.\n>\n>Thanks\n>\n>--\n>Kind Regards,\n>Daviey Walker\n>\n>\n>------------------------------------------------------------------------\n>\n>_______________________________________________\n>Openstack-stable-maint mailing list\n>Openstack-stable-maint at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\nThe sudo message is just a harmless warning and does not affect the result.  In fact there are many actual test failures shown in the console log apparently related to an inability to import oslo.serialization.\n\n-Jim\n\n\n\n','<CACyjiAh9us_RZvOtbODgr6SvL84kMWChHdq8KCmhSP2gjHE9Gw@mail.gmail.com>',NULL),('<100073612.17523162.1412590275978.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-06 06:11:15',-14400,'2014-10-06 10:11:15',NULL,'[Openstack-operators] Request for feedback on DHCP IP usage','Hi Gustavo,\n\nThanks for the prompt reply, comments inline.\n\nRegards,\nMike\n\n----- Original Message -----\n> \n> \n> On 10/06/2014 04:09 AM, Mike Kolesnik wrote:\n> \n> > Now, I know the 1st solution seems very appealing but thinking of it\n> > further\n> > reveals very serious limitations:\n> > * No HA for DHCP agents is possible (more prone to certain race\n> > conditions).\n> eventually they will be just bugs, bugs can be fixed\n> \n> > * DHCP IP can\'t be reached from outside the cloud.\n> that\'s a feature :)\n> \n> > * You will just see a single port per subnet in Neutron, without\n> > granularity of\n> > the host binding (but perhaps it\'s not that bad).\n> \n> may be an issue for monitoring, i will have more ports deployed that\n> registered in my db.\n> i don\'t know if is *really* an issue, still does not sounds good\n> \n> > * This solution will be tied initially only to OVS mechanism driver, each\n> > other\n> > driver or 3rd party plugin will have to support it individually in some\n> > way.\n> > \n> > So basically my question is - which solution would you prefer as a cloud\n> > op?\n> option 2 is a no go for me, i can\'t waste that many ip\n> \n> > \n> > Is it that bad to consume more than 1 IP, given that we\'re talking about\n> > private\n> > isolated networks?\n> \n> not always, all the vm we deploy in the prod environment have public ip,\n> they speak freely to the internet. no nat, no lbaas.\n\nSo basically the DHCP server is also consuming a public IP?\n\nAlso since you\'re always using the public network, does distributing the\nDHCP agents/servers sound interesting?\n\n> \n> none of the limitations you mention for the first solution sounds\n> problematic to me (if individual dhcp servers can be managed individually)\n> \n\nWell the idea is that the servers be managed automatically by Neutron i.e.\nit will decided which DHCP serves which IP.\n\nWhat plugin are you deploying, ML2+OVS?\n\n> \n> \n> \n> --\n> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n> \n> \n\n\n','<543258F8.9040700@zumbi.com.ar>',NULL),('<1000821012.2.1374991352710.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-28 06:02:32',0,'2013-07-28 06:02:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #300','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/300/>\n\n------------------------------------------\n[...truncated 67 lines...]\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-Jf3Lec/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-Jf3Lec/d2to1-0.2.10/egg-dist-tmp-qo1hDw\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-uCwUGU/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-uCwUGU/setuptools-git-1.0/egg-dist-tmp-rT3QLV\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-Egwu37/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-Egwu37/d2to1-0.2.10/egg-dist-tmp-kX0_02\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-JfxUii/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-JfxUii/setuptools-git-1.0/egg-dist-tmp-dND19k\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-PwlWlK/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-PwlWlK/d2to1-0.2.10/egg-dist-tmp-XvFIh0\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.A26dVlS7RS/easy_install-1OzsZ_/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.A26dVlS7RS/easy_install-1OzsZ_/setuptools-git-1.0/egg-dist-tmp-HlDYjy\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.A26dVlS7RS\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/300\n[SCP] Copying console log.\n\n\n','<114213532.61.1374904974730.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1001132094.262.1368426700081.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-13 06:31:40',0,'2013-05-13 06:31:40',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #224','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/224/>\n\n------------------------------------------\n[...truncated 12596 lines...]\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 6f8eff36c4d1455082aaba21a71ec9c1 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:58680\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:58680/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (8195) wsgi starting up on http://127.0.0.1:58680/\n\nnova.osapi_compute.wsgi.server: INFO: (8195) accepted (\'127.0.0.1\', 37272)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:28] \"GET /v2 HTTP/1.1\" 204 216 0.000774\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-5da6c2a3-28ca-4082-ac98-71f32b1b66ba</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (8195) accepted (\'127.0.0.1\', 37273)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x87e9650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x87e9650>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:58680/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:28 8195 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:58680/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:28] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.247855\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for e43700faab2443f7a8cc2db5583cad17 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43712\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43712/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (8195) wsgi starting up on http://127.0.0.1:43712/\n\nnova.osapi_compute.wsgi.server: INFO: (8195) accepted (\'127.0.0.1\', 38330)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:29] \"GET /v2 HTTP/1.1\" 204 216 0.001008\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-51c0ed9f-3a83-4a76-9d64-730615e89bea</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (8195) accepted (\'127.0.0.1\', 38331)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x90a4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x90a4d10>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43712/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     name)\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:29 8195 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43712/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:29] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.258772\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.UHuwGiMf1s\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/224\n[SCP] Copying console log.\n\n\n','<1939653177.247.1368340243119.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1001205468.78904.1368303834356.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-11 16:23:54',-14400,'2013-05-11 20:23:54',NULL,'[openstack-qa] Tempest core cleanup','It is a big sudden change in our process.\nI have no objection against removing the completely inactive members.\n\n\'dwalleck\' has more reviews than the average and attending the QA meetings.\n\'mordred\' has commits from the past 90 days.\n\nI would preserve their membership for now.\nWe can discuss more stricter criteria for future usage.\n\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-qa at lists.openstack.org\n> Sent: Saturday, May 11, 2013 1:34:25 AM\n> Subject: [openstack-qa] Tempest core cleanup\n> \n> I was asked today about some possible tempest core adds, and using\n> russell\'s handy review-o-metric generator here is what the last 90 days\n> look like:\n> \n> +----------------------+-----------------------------------+\n> |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |\n> +----------------------+-----------------------------------+\n> |      sdague **       |      171 (4|56|0|111) (64.9%)     |\n> |      cyeoh-0 **      |      162 (0|52|15|95) (67.9%)     |\n> |     afazekas **      |      107 (1|18|25|63) (82.2%)     |\n> |    david-kranz **    |       93 (0|14|6|73) (84.9%)      |\n> |     treinish **      |       83 (1|35|2|45) (56.6%)      |\n> |     jaypipes **      |       56 (0|12|2|42) (78.6%)      |\n> |       ivan-zhu       |       35 (0|8|27|0) (77.1%)       |\n> |   andrea-frittoli    |       23 (0|1|22|0) (95.7%)       |\n> |         jogo         |       20 (0|4|16|0) (80.0%)       |\n> |      donald-ngo      |       18 (0|5|13|0) (72.2%)       |\n> | ravikumar-venkatesan |       15 (0|1|14|0) (93.3%)       |\n> |     dwalleck **      |        13 (0|4|5|4) (69.2%)       |\n> |       adalbas        |       13 (0|1|12|0) (92.3%)       |\n> |       psedlak        |        11 (0|2|9|0) (81.8%)       |\n> |        lauria        |       11 (0|0|11|0) (100.0%)      |\n> |       prekarat       |        10 (0|4|6|0) (60.0%)       |\n> |       gfidente       |       10 (0|0|10|0) (100.0%)      |\n> |        igawa         |        6 (0|0|6|0) (100.0%)       |\n> |       maurosr        |        5 (0|0|5|0) (100.0%)       |\n> |        fungi         |        5 (0|0|5|0) (100.0%)       |\n> |     rohitkarajgi     |        4 (0|1|3|0) (75.0%)        |\n> |       dachary        |        3 (0|2|1|0) (33.3%)        |\n> |         maru         |        3 (0|1|2|0) (66.7%)        |\n> |    jerome-gallard    |        3 (0|0|3|0) (100.0%)       |\n> |        ayoung        |        2 (0|1|1|0) (50.0%)        |\n> |       unknown        |        2 (0|0|2|0) (100.0%)       |\n> |     johngarbutt      |         1 (0|1|0|0) (0.0%)        |\n> |    doug-hellmann     |         1 (0|1|0|0) (0.0%)        |\n> |       cboylan        |         1 (0|1|0|0) (0.0%)        |\n> |  armando-migliaccio  |         1 (0|1|0|0) (0.0%)        |\n> |        akuno         |         1 (0|1|0|0) (0.0%)        |\n> |        ymzk37        |        1 (0|0|1|0) (100.0%)       |\n> |        tmello        |        1 (0|0|1|0) (100.0%)       |\n> |       mriedem        |        1 (0|0|1|0) (100.0%)       |\n> |       mpavlase       |        1 (0|0|1|0) (100.0%)       |\n> |       mkollaro       |        1 (0|0|1|0) (100.0%)       |\n> |        heckj         |        1 (0|0|1|0) (100.0%)       |\n> |       dperaza        |        1 (0|0|1|0) (100.0%)       |\n> |       bob-ball       |        1 (0|0|1|0) (100.0%)       |\n> |        aloga         |        1 (0|0|1|0) (100.0%)       |\n> +----------------------+-----------------------------------+\n> \n> There remains a pretty distinct line between the 6 core members at the\n> top, and the rest of the pack, so now doesn\'t feel like the right time\n> to add more folks. However, I\'d really like to see more folks actively\n> participating in reviews.\n> \n> It also turns out our core count isn\'t 6, it\'s 12, and with only 1/2 the\n> core members being active at this point, I\'d like to clean up the group\n> a little. I think historically we\'ve been in an add only mode, but it\'s\n> important to realize this isn\'t an honor society, but it\'s a working\n> role. And if folks aren\'t actively reviewing a lot of code it\'s better\n> to remove them from the list. People can come back later if they start\n> getting active in the community again through normal nomination process:\n> \n> So I suggest we remove the following people from openstack-qa-core to\n> have the group more reflective of those doing the core reviewing:\n> \n>          \"blamar\",\n>          \"bcwaldon\",\n>          \"dwalleck\",\n>          \"westmaas\",\n>          \"corvus\",\n>          \"mordred\",\n> \n> \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<518D8401.2080006@dague.net>',NULL),('<10012CFBC5B0B642BF6477E44971D6F37A7E88FB4F@MBX-MSG-SV06.msg.nttdata.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 21:41:35',32400,'2013-08-06 12:41:35',NULL,'[openstack-dev] [Swift] container-sync problems in global data sync\n	senario','Hi,\n\n\nI?m interested in container-sync to take a snapshot of swift.\n\nI want to sync data between two swift clusters distributed in multiple locations.\nIt is assumed that there are two swift clusters located in two places,\nand the container-sync syncs data from one cluster to the other cluster through WAN.\n\nI tried container-sync with Folsom in this case, and faced one problem with this scenario.\nContainer-sync always sends multiple PUT request with whole object transfer,\nwhich puts pressure on network bandwidth between swift clusters.\n\nI checked Grizzly and latest 1.9.0, but I cannot find any progress with the issues.\nDoes anyone experiences similar issues or tackled to improve performance?\n\nIMHO, it may be fixed with a little changes to the container-sync.\nIf it can be, I\'d like to try it. :-)\n\nDoes anybody have any idea or suggestions?\n\nThanks in advance.\nTakashi Kajinami\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130806/5792296a/attachment.html>\n\n',NULL,NULL),('<1001628727.252.1368341550421.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:52:30',0,'2013-05-12 06:52:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #38','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/38/>\n\n------------------------------------------\n[...truncated 17776 lines...]\ntempest.tests.object_storage.test_object_services.ObjectTest.test_create_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_metadata[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_object_without_using_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_with_another_user_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_version.ContainerTest.test_versioned_container[smoke] ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[smoke] ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot ... ok\n\n======================================================================\nERROR: tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_server_actions.py\", line 180, in test_resize_server_revert\n    self.client.wait_for_server_status(self.server_id, \'VERIFY_RESIZE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/servers_client.py\", line 284, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 5071cb1a-b983-4c29-87db-7b22782fea16 failed to build and is in ERROR status\n\n-------------------- >> begin captured logging << --------------------\n2013-05-12 06:32:00,335 Request: GET http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\n2013-05-12 06:32:00,336 Request Headers: {\'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-05-12 06:32:00,406 Response Status: 200\n2013-05-12 06:32:00,407 Response Headers: {\'content-length\': \'1757\', \'content-location\': u\'http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\', \'date\': \'Sun, 12 May 2013 06:32:00 GMT\', \'x-compute-request-id\': \'req-5c905bff-a489-4bdf-9d34-3d38898131df\', \'content-type\': \'application/xml\'}\n2013-05-12 06:32:00,407 Response Body: <?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<server xmlns:OS-DCF=\"http://docs.openstack.org/compute/ext/disk_config/api/v1.1\" xmlns:atom=\"http://www.w3.org/2005/Atom\" xmlns:OS-EXT-IPS=\"http://docs.openstack.org/compute/ext/extended_ips/api/v1.1\" xmlns:OS-EXT-STS=\"http://docs.openstack.org/compute/ext/extended_status/api/v1.1\" xmlns:OS-EXT-AZ=\"http://docs.openstack.org/compute/ext/extended_availability_zone/api/v2\" xmlns=\"http://docs.openstack.org/compute/api/v1.1\" status=\"ACTIVE\" updated=\"2013-05-12T06:32:00Z\" hostId=\"900d69fbb780cabfca323605d9740513ff2a6dce02f417ce88f9c9e9\" name=\"server354614\" created=\"2013-05-12T06:31:08Z\" userId=\"2eae6b3ce8c342e7bd3955876eb75719\" tenantId=\"8d73593f873c442db9e31c22dcb3eb56\" accessIPv4=\"\" accessIPv6=\"\" progress=\"0\" id=\"5071cb1a-b983-4c29-87db-7b22782fea16\" key_name=\"None\" config_drive=\"\" OS-EXT-STS:vm_state=\"active\" OS-EXT-STS:task_state=\"None\" OS-EXT-STS:power_state=\"1\" OS-EXT-AZ:availability_zone=\"nova\" OS-DCF:diskConfig=\"MANUAL\"><image id=\"22316024-7233-4d53-a87e-ac433fdf06d5\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/images/22316024-7233-4d53-a87e-ac433fdf06d5\" rel=\"bookmark\"/></image><flavor id=\"84\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/flavors/84\" rel=\"bookmark\"/></flavor><metadata/><addresses><network id=\"private\"><ip OS-EXT-IPS:type=\"fixed\" version=\"4\" addr=\"10.1.0.7\"/></network></addresses><atom:link href=\"http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"self\"/><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"bookmark\"/><security_groups><security_group name=\"default\"/></security_groups></server>\n2013-05-12 06:32:00,407 Request: GET http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\n2013-05-12 06:32:00,407 Request Headers: {\'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-05-12 06:32:00,467 Response Status: 200\n2013-05-12 06:32:00,467 Response Headers: {\'content-length\': \'1757\', \'content-location\': u\'http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\', \'date\': \'Sun, 12 May 2013 06:32:00 GMT\', \'x-compute-request-id\': \'req-ce8dd959-f99c-4d0c-8e49-579cdf844b68\', \'content-type\': \'application/xml\'}\n2013-05-12 06:32:00,467 Response Body: <?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<server xmlns:OS-DCF=\"http://docs.openstack.org/compute/ext/disk_config/api/v1.1\" xmlns:atom=\"http://www.w3.org/2005/Atom\" xmlns:OS-EXT-IPS=\"http://docs.openstack.org/compute/ext/extended_ips/api/v1.1\" xmlns:OS-EXT-STS=\"http://docs.openstack.org/compute/ext/extended_status/api/v1.1\" xmlns:OS-EXT-AZ=\"http://docs.openstack.org/compute/ext/extended_availability_zone/api/v2\" xmlns=\"http://docs.openstack.org/compute/api/v1.1\" status=\"ACTIVE\" updated=\"2013-05-12T06:32:00Z\" hostId=\"900d69fbb780cabfca323605d9740513ff2a6dce02f417ce88f9c9e9\" name=\"server354614\" created=\"2013-05-12T06:31:08Z\" userId=\"2eae6b3ce8c342e7bd3955876eb75719\" tenantId=\"8d73593f873c442db9e31c22dcb3eb56\" accessIPv4=\"\" accessIPv6=\"\" progress=\"0\" id=\"5071cb1a-b983-4c29-87db-7b22782fea16\" key_name=\"None\" config_drive=\"\" OS-EXT-STS:vm_state=\"active\" OS-EXT-STS:task_state=\"None\" OS-EXT-STS:power_state=\"1\" OS-EXT-AZ:availability_zone=\"nova\" OS-DCF:diskConfig=\"MANUAL\"><image id=\"22316024-7233-4d53-a87e-ac433fdf06d5\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/images/22316024-7233-4d53-a87e-ac433fdf06d5\" rel=\"bookmark\"/></image><flavor id=\"84\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/flavors/84\" rel=\"bookmark\"/></flavor><metadata/><addresses><network id=\"private\"><ip OS-EXT-IPS:type=\"fixed\" version=\"4\" addr=\"10.1.0.7\"/></network></addresses><atom:link href=\"http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"self\"/><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"bookmark\"/><security_groups><security_group name=\"default\"/></security_groups></server>\n2013-05-12 06:32:00,468 Request: POST http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16/action\n2013-05-12 06:32:00,468 Request Headers: {\'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-05-12 06:32:00,468 Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<resize flavorRef=\"42\" xmlns=\"http://docs.openstack.org/compute/api/v1.1\"/>\n2013-05-12 06:32:00,657 Response Status: 202\n2013-05-12 06:32:00,657 Response Headers: {\'date\': \'Sun, 12 May 2013 06:32:00 GMT\', \'content-length\': \'0\', \'content-type\': \'text/html; charset=UTF-8\'}\n2013-05-12 06:32:00,657 Request: GET http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\n2013-05-12 06:32:00,657 Request Headers: {\'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-05-12 06:32:00,736 Response Status: 200\n2013-05-12 06:32:00,736 Response Headers: {\'content-length\': \'1764\', \'content-location\': u\'http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\', \'date\': \'Sun, 12 May 2013 06:32:00 GMT\', \'x-compute-request-id\': \'req-71096d6a-e683-4f2a-8d17-e980f93ed149\', \'content-type\': \'application/xml\'}\n2013-05-12 06:32:00,736 Response Body: <?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<server xmlns:OS-DCF=\"http://docs.openstack.org/compute/ext/disk_config/api/v1.1\" xmlns:atom=\"http://www.w3.org/2005/Atom\" xmlns:OS-EXT-IPS=\"http://docs.openstack.org/compute/ext/extended_ips/api/v1.1\" xmlns:OS-EXT-STS=\"http://docs.openstack.org/compute/ext/extended_status/api/v1.1\" xmlns:OS-EXT-AZ=\"http://docs.openstack.org/compute/ext/extended_availability_zone/api/v2\" xmlns=\"http://docs.openstack.org/compute/api/v1.1\" status=\"RESIZE\" updated=\"2013-05-12T06:32:00Z\" hostId=\"900d69fbb780cabfca323605d9740513ff2a6dce02f417ce88f9c9e9\" name=\"server354614\" created=\"2013-05-12T06:31:08Z\" userId=\"2eae6b3ce8c342e7bd3955876eb75719\" tenantId=\"8d73593f873c442db9e31c22dcb3eb56\" accessIPv4=\"\" accessIPv6=\"\" progress=\"0\" id=\"5071cb1a-b983-4c29-87db-7b22782fea16\" key_name=\"None\" config_drive=\"\" OS-EXT-STS:vm_state=\"active\" OS-EXT-STS:task_state=\"resize_prep\" OS-EXT-STS:power_state=\"1\" OS-EXT-AZ:availability_zone=\"nova\" OS-DCF:diskConfig=\"MANUAL\"><image id=\"22316024-7233-4d53-a87e-ac433fdf06d5\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/images/22316024-7233-4d53-a87e-ac433fdf06d5\" rel=\"bookmark\"/></image><flavor id=\"84\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/flavors/84\" rel=\"bookmark\"/></flavor><metadata/><addresses><network id=\"private\"><ip OS-EXT-IPS:type=\"fixed\" version=\"4\" addr=\"10.1.0.7\"/></network></addresses><atom:link href=\"http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"self\"/><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"bookmark\"/><security_groups><security_group name=\"default\"/></security_groups></server>\n2013-05-12 06:32:03,738 Request: GET http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\n2013-05-12 06:32:03,738 Request Headers: {\'Content-Type\': \'application/xml\', \'Accept\': \'application/xml\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-05-12 06:32:03,805 Response Status: 200\n2013-05-12 06:32:03,805 Response Headers: {\'content-length\': \'1754\', \'content-location\': u\'http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\', \'date\': \'Sun, 12 May 2013 06:32:03 GMT\', \'x-compute-request-id\': \'req-99d0e2bf-08ca-493b-9f5c-30af21569255\', \'content-type\': \'application/xml\'}\n2013-05-12 06:32:03,805 Response Body: <?xml version=\'1.0\' encoding=\'UTF-8\'?>\n<server xmlns:OS-DCF=\"http://docs.openstack.org/compute/ext/disk_config/api/v1.1\" xmlns:atom=\"http://www.w3.org/2005/Atom\" xmlns:OS-EXT-IPS=\"http://docs.openstack.org/compute/ext/extended_ips/api/v1.1\" xmlns:OS-EXT-STS=\"http://docs.openstack.org/compute/ext/extended_status/api/v1.1\" xmlns:OS-EXT-AZ=\"http://docs.openstack.org/compute/ext/extended_availability_zone/api/v2\" xmlns=\"http://docs.openstack.org/compute/api/v1.1\" status=\"ERROR\" updated=\"2013-05-12T06:32:03Z\" hostId=\"900d69fbb780cabfca323605d9740513ff2a6dce02f417ce88f9c9e9\" name=\"server354614\" created=\"2013-05-12T06:31:08Z\" userId=\"2eae6b3ce8c342e7bd3955876eb75719\" tenantId=\"8d73593f873c442db9e31c22dcb3eb56\" accessIPv4=\"\" accessIPv6=\"\" id=\"5071cb1a-b983-4c29-87db-7b22782fea16\" key_name=\"None\" config_drive=\"\" OS-EXT-STS:vm_state=\"error\" OS-EXT-STS:task_state=\"resize_migrating\" OS-EXT-STS:power_state=\"1\" OS-EXT-AZ:availability_zone=\"nova\" OS-DCF:diskConfig=\"MANUAL\"><image id=\"22316024-7233-4d53-a87e-ac433fdf06d5\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/images/22316024-7233-4d53-a87e-ac433fdf06d5\" rel=\"bookmark\"/></image><flavor id=\"84\"><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/flavors/84\" rel=\"bookmark\"/></flavor><metadata/><addresses><network id=\"private\"><ip OS-EXT-IPS:type=\"fixed\" version=\"4\" addr=\"10.1.0.7\"/></network></addresses><atom:link href=\"http://127.0.0.1:8774/v2/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"self\"/><atom:link href=\"http://127.0.0.1:8774/8d73593f873c442db9e31c22dcb3eb56/servers/5071cb1a-b983-4c29-87db-7b22782fea16\" rel=\"bookmark\"/><security_groups><security_group name=\"default\"/></security_groups></server>\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 800 tests in 2318.117s\n\nFAILED (SKIP=73, errors=1)\nERROR: InvocationError: \'/usr/local/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-full.xml -sv tempest\'\nfull runtests: commands[1]\nWARNING:test command found but not installed in testenv\n  cmd: /usr/local/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/full\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... SKIP: version is empty, bug 1138844\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-cli.xml\n----------------------------------------------------------------------\nRan 54 tests in 53.346s\n\nOK (SKIP=4)\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/rabbitmq/rabbit at devstack-1368300710-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/rabbitmq/rabbit at devstack-1368300710.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/38/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<348628565.228.1368252761177.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1003254746.1659898.1385128187231.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 14:49:47',3600,'2013-11-22 13:49:47',NULL,'[openstack-dev] [horizon] Javascript development improvement','>There is at least one bug open against Ubuntu[1], asking to install\n>python-lesscpy as well, as customers \"often\" need to re-create or change\n>stylesheets.\n>\n>This would imply nodejs in a production environment, when going back to\n>less.\n\nAs long as the css will be the only one included into the package, we cannot run into this issue. If someone wants to modify the less file he could compile it and just copy paste the result into the proper directory.\n\n>It seems a bit crazy to me to introduce NodeJS as a dependency just for\n>the sake of an easy way to run jslint. There are other options\n>available that run without NodeJS as a dependency.\n\nSadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it.\n\n>There are more implications to running NodeJS even only for\n>development. It will likely have an impact on our infrastructure as\n>well, since we\'ll want these checks running on patches up for\n>review. Then if it\'s there for development it increases the risk it\n>will creep in as a dependency for our runtime.\n\nThat is a good point, but Selenium also provides external dependencies, like a browser to run into. I do not really know the infrastructure used by jenkins and how we can integrate our solution into, but I do not think it is impossible (I have never got any trouble with the installation of node with the sources in any distro). \n\n>As for Selenium, are you talking about rewriting our existing Selenium\n>tests in Javascript? If so I am opposed to this. The strength of our\n>community is in Python, if we want to encourage people to write more\n>tests we should make it easy for them to do so.\n\nCurrently we have two Selenium tests in pure python, and all the others are running in a page with qUnit, which is a javascript unit testing framework.\n\nLastly, we will start using angularjs as a front-end framework, it provides an advanced testing framework which allows us to get rid of selenium.\n\n\n','<528F4ABA.1080109@redhat.com>',NULL),('<1003951378.268.1366526203222.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-21 06:36:43',0,'2013-04-21 06:36:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/>\n\n------------------------------------------\n[...truncated 17651 lines...]\n2013-04-21 06:33:30,560 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,560 Request: GET http://127.0.0.1:9292/v2/images/7e25d80f-2833-49c9-81e0-08bd06316d67\n2013-04-21 06:33:30,560 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:33:30,568 Response Status: 404\n2013-04-21 06:33:30,568 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:33:30 GMT\', \'content-length\': \'74\', \'content-type\': \'text/plain; charset=UTF-8\', \'x-openstack-request-id\': \'req-0ebe242b-246a-4f0a-8c2b-83356461ca09\'}\n2013-04-21 06:33:30,568 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,568 Request: GET http://127.0.0.1:9292/v2/images/a235342b-c747-425f-b1bc-85d002332f59\n2013-04-21 06:33:30,568 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:33:30,577 Response Status: 404\n2013-04-21 06:33:30,577 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:33:30 GMT\', \'content-length\': \'74\', \'content-type\': \'text/plain; charset=UTF-8\', \'x-openstack-request-id\': \'req-3b612343-f97b-4188-87dd-52eb9e3c9566\'}\n2013-04-21 06:33:30,577 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,577 Request: GET http://127.0.0.1:9292/v2/images/a235342b-c747-425f-b1bc-85d002332f59\n2013-04-21 06:33:30,577 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:33:30,585 Response Status: 404\n2013-04-21 06:33:30,585 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:33:30 GMT\', \'content-length\': \'74\', \'content-type\': \'text/plain; charset=UTF-8\', \'x-openstack-request-id\': \'req-71aca233-4d2d-4346-814f-f33fb1fec792\'}\n2013-04-21 06:33:30,585 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,585 Request: GET http://127.0.0.1:9292/v2/images/bb480119-fe36-4da7-8462-613885ae73f5\n2013-04-21 06:33:30,585 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:33:30,593 Response Status: 404\n2013-04-21 06:33:30,593 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:33:30 GMT\', \'content-length\': \'74\', \'content-type\': \'text/plain; charset=UTF-8\', \'x-openstack-request-id\': \'req-24666d58-9d64-4294-b73a-e863efde48e8\'}\n2013-04-21 06:33:30,593 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,593 Request: GET http://127.0.0.1:9292/v2/images/bb480119-fe36-4da7-8462-613885ae73f5\n2013-04-21 06:33:30,593 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:33:30,601 Response Status: 404\n2013-04-21 06:33:30,601 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:33:30 GMT\', \'content-length\': \'74\', \'content-type\': \'text/plain; charset=UTF-8\', \'x-openstack-request-id\': \'req-11b68c31-6d98-4381-8ee8-69f68c786551\'}\n2013-04-21 06:33:30,601 Response Body: 404 Not Found\n\nAn object with the specified identifier was not found.\n\n   \n2013-04-21 06:33:30,602 Starting new HTTP connection (1): 127.0.0.1\n2013-04-21 06:33:30,728 \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n2013-04-21 06:33:30,731 Starting new HTTP connection (1): 127.0.0.1\n2013-04-21 06:33:30,854 \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\ntempest.tests.object_storage.test_account_services.AccountTest.test_create_account_metadata[smoke] ... ok\ntempest.tests.object_storage.test_account_services.AccountTest.test_delete_account_metadata[smoke] ... ok\ntempest.tests.object_storage.test_account_services.AccountTest.test_list_account_metadata[smoke] ... ok\ntempest.tests.object_storage.test_account_services.AccountTest.test_list_containers[smoke] ... ok\ntempest.tests.object_storage.test_account_services.AccountTest.test_list_containers_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_container_services.ContainerTest.test_container_metadata[smoke] ... ok\ntempest.tests.object_storage.test_container_services.ContainerTest.test_create_container[smoke] ... ok\ntempest.tests.object_storage.test_container_services.ContainerTest.test_delete_container[smoke] ... ok\ntempest.tests.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[smoke] ... ok\ntempest.tests.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization ... SKIP: Until Bug 1093743 is resolved.\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_container_object_without_using_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_object_with_another_user_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_create_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_metadata[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_object_without_using_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_with_another_user_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_version.ContainerTest.test_versioned_container[smoke] ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[smoke] ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot ... ok\n\n======================================================================\nFAIL: tempest.tests.identity.admin.test_roles.RolesTestJSON.test_remove_user_role_request_without_token\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_roles.py\", line 172, in test_remove_user_role_request_without_token\n    (user, tenant, role) = self._get_role_params()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_roles.py\", line 35, in _get_role_params\n    self.data.setup_test_role()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 104, in setup_test_role\n    resp, self.role = self.client.create_role(self.test_role)\n  File \"/opt/stack/new/tempest/tempest/services/identity/json/identity_client.py\", line 33, in create_role\n    resp, body = self.post(\'OS-KSADM/roles\', post_body, self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 177, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 302, in request\n    resp, resp_body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 353, in _error_checker\n    raise exceptions.Duplicate(resp_body)\nDuplicate: An object with that identifier already exists\nDetails: {u\'error\': {u\'message\': u\'Conflict occurred attempting to store role. (1062, \"Duplicate entry \\\'role363781\\\' for key \\\'name\\\'\")\', u\'code\': 409, u\'title\': u\'Conflict\'}}\n\n-------------------- >> begin captured logging << --------------------\n2013-04-21 06:32:50,676 Request: POST http://127.0.0.1:35357/v2.0/tenants\n2013-04-21 06:32:50,676 Request Headers: {\'Content-Type\': \'application/json\', \'Accept\': \'application/json\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:32:50,676 Request Body: {\"tenant\": {\"enabled\": true, \"name\": \"test_tenant_98558\", \"description\": \"desc_250701\"}}\n2013-04-21 06:32:50,686 Response Status: 200\n2013-04-21 06:32:50,686 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:32:50 GMT\', \'content-length\': \'130\', \'vary\': \'X-Auth-Token\', \'content-type\': \'application/json\'}\n2013-04-21 06:32:50,686 Response Body: {\"tenant\": {\"description\": \"desc_250701\", \"enabled\": true, \"id\": \"80e83e399f8e41df97f8a2ed027c7407\", \"name\": \"test_tenant_98558\"}}\n2013-04-21 06:32:50,686 Request: POST http://127.0.0.1:35357/v2.0/users\n2013-04-21 06:32:50,686 Request Headers: {\'Content-Type\': \'application/json\', \'Accept\': \'application/json\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:32:50,686 Request Body: {\"user\": {\"email\": \"test_user_472406 at testmail.tm\", \"password\": \"pass_102337\", \"name\": \"test_user_472406\", \"tenantId\": \"80e83e399f8e41df97f8a2ed027c7407\"}}\n2013-04-21 06:32:50,738 Response Status: 200\n2013-04-21 06:32:50,739 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:32:50 GMT\', \'content-length\': \'186\', \'vary\': \'X-Auth-Token\', \'content-type\': \'application/json\'}\n2013-04-21 06:32:50,739 Response Body: {\"user\": {\"name\": \"test_user_472406\", \"id\": \"cf295ad146aa4ac7a8da4ce4f9d5d6e6\", \"tenantId\": \"80e83e399f8e41df97f8a2ed027c7407\", \"enabled\": true, \"email\": \"test_user_472406 at testmail.tm\"}}\n2013-04-21 06:32:50,739 Request: POST http://127.0.0.1:35357/v2.0/OS-KSADM/roles\n2013-04-21 06:32:50,739 Request Headers: {\'Content-Type\': \'application/json\', \'Accept\': \'application/json\', \'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-21 06:32:50,739 Request Body: {\"role\": {\"name\": \"role363781\"}}\n2013-04-21 06:32:50,748 Response Status: 409\n2013-04-21 06:32:50,748 Response Headers: {\'date\': \'Sun, 21 Apr 2013 06:32:50 GMT\', \'content-length\': \'159\', \'vary\': \'X-Auth-Token\', \'content-type\': \'application/json\'}\n2013-04-21 06:32:50,748 Response Body: {\"error\": {\"message\": \"Conflict occurred attempting to store role. (1062, \\\"Duplicate entry \'role363781\' for key \'name\'\\\")\", \"code\": 409, \"title\": \"Conflict\"}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 800 tests in 1602.391s\n\nFAILED (SKIP=73, failures=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/rabbitmq/rabbit at devstack-1366330310-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/rabbitmq/rabbit at devstack-1366330310.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/17/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1004119153.13009727.1395854254837.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 17:17:34',0,'2014-03-26 17:17:34',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','\n\n----- Original Message -----\n> From: \"Sangeeta Singh\" <singhs at yahoo-inc.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, March 25, 2014 9:50:00 PM\n> Subject: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..\n> \n> Hi,\n> \n> The availability Zones filter states that theoretically a compute node can be\n> part of multiple availability zones. I have a requirement where I need to\n> make a compute node part to 2 AZ. When I try to create a host aggregates\n> with AZ I can not add the node in two host aggregates that have AZ defined.\n> However if I create a host aggregate without associating an AZ then I can\n> add the compute nodes to it. After doing that I can update the\n> host-aggregate an associate an AZ. This looks like a bug.\n> \n> I can see the compute node to be listed in the 2 AZ with the\n> availability-zone-list command.\n> \n\nYes it appears a bug to me (apparently the AZ metadata indertion is considered as a normal metadata so no check is done), and so does the message in the AvailabilityZoneFilter. I don\'t know why you need a compute node that belongs to 2 different availability-zones. Maybe I\'m wrong but for me it\'s logical that availability-zones do not share the same compute nodes. The \"availability-zones\" have the role of partition your compute nodes into \"zones\" that are physically separated (in large term it would require separation of physical servers, networking equipments, power sources, etc). So that when user deploys 2 VMs in 2 different zones, he knows that these VMs do not fall into a same host and if some zone falls, the others continue working, thus the client will not lose all of his VMs. It\'s smaller than Regions which ensure total separation at the cost of low-layer connectivity and central management (e.g. scheduling per region).\n\nSee: http://www.linuxjournal.com/content/introduction-openstack\n\nThe former purpose of regouping hosts with the same characteristics is ensured by host-aggregates.\n\n> The problem that I have is that I can still not boot a VM on the compute node\n> when I do not specify the AZ in the command though I have set the default\n> availability zone and the default schedule zone in nova.conf.\n> \n> I get the error ?ERROR: The requested availability zone is not available?\n> \n> What I am  trying to achieve is have two AZ that the user can select during\n> the boot but then have a default AZ which has the HV from both AZ1 AND AZ2\n> so that when the user does not specify any AZ in the boot command I scatter\n> my VM on both the AZ in a balanced way.\n> \n\nI do not understand your goal. When you create two availability-zones and put ALL of your compute nodes into these AZs, then if you don\'t specifies the AZ in your request, then AZFilter will automatically accept all hosts.\nThe defaut weigher (RalWeigher) will then distribute the workload fairely among these nodes regardless of AZ it belongs to. Maybe it is what you want?\n\n> Any pointers.\n> \n> Thanks,\n> Sangeeta\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<CF573A06.4DB5E%singhs@yahoo-inc.com>',NULL),('<1004845954.10479072.1396370932399.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 12:48:52',-14400,'2014-04-01 16:48:52',NULL,'[openstack-dev] [nova] Questions about\n	guest	NUMA	and	memory	binding policies','----- Original Message -----\n> Hi Liuji,\n> \n> I\'m the owner of bp support-libvirt-vcpu-topology,\n> There are four main reasons that I did not continue to work on it:\n> 1. the design proposal has not confirmed by core developers of nova\n> 2. this bp is not accepted in Icehouse development stage\n> 3. Daniel expects that this bp should consider together with the other one\n> numa-aware-cpu-binding, but I have no idea to do this for now\n\nThis is probably only the tip of the iceberg, and I notice Dan has now raised a new BP [1] to try and consolidate these efforts, but in the first instance it may be desirable for the image to specific a cell, socket, core, and thread based topology - not just a socket, core, and thread based topology as previously proposed. There are of course still questions to be answered about how to ensure the scheduler has enough knowledge of NUMA cell layout from Libvirt to place these guests ideally and what ideal NUMA placement might actually look like in both these cases and the more general case where no specific topology is requested.\n\n-Steve\n\n[1] https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology\n\n> 4. I have no enough time to do this at this moment\n> \n> 2014-03-05\n> \n> \n> \n> Wangpan\n> \n> \n> \n> ????\"Liuji (Jeremy)\" <jeremy.liu at huawei.com>\n> ?????2014-03-05 15:02\n> ???Re: [openstack-dev] [nova] Questions about guest NUMA and memory binding\n> policies\n> ????\"OpenStack Development Mailing List (not for usage\n> questions)\"<openstack-dev at lists.openstack.org>\n> ???\"Luohao \\(brian\\)\"<brian.luohao at huawei.com>,\"Yuanjing\n> \\(D\\)\"<yj.yuan at huawei.com>\n> \n> Hi Steve,\n> \n> Thanks for your reply.\n> \n> I didn\'t know why the blueprint numa-aware-cpu-binding seems to have no more\n> progress until read the two mails mentioned in your mail.\n> \n> The use case analysis in the mails are very clear, they are also what I\n> concern about.\n> I agree that we shouldn\'t provide pCPU/vCPU mapping for the ending user and\n> how to provide them for the user need more consideration.\n> \n> The use cases I concern more are the pCPU\'s exclusively use(pCPU:vCPU=1:1)\n> and the guest numa.\n> \n> \n> Thanks,\n> Jeremy Liu\n> \n> \n> > -----Original Message-----\n> > From: Steve Gordon [mailto:sgordon at redhat.com]\n> > Sent: Tuesday, March 04, 2014 10:29 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Cc: Luohao (brian); Yuanjing (D)\n> > Subject: Re: [openstack-dev] [nova] Questions about guest NUMA and memory\n> > binding policies\n> >  \n> > ----- Original Message -----\n> > > Hi, all\n> > > \n> > > I search the current blueprints and old mails in the mail list, but\n> > > find nothing about Guest NUMA and setting memory binding policies.\n> > > I just find a blueprint about vcpu topology and a blueprint about CPU\n> > > binding.\n> > > \n> > > https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topol\n> > > ogy https://blueprints.launchpad.net/nova/+spec/numa-aware-cpu-binding\n> > > \n> > > Is there any plan for the guest NUMA and memory binding policies setting?\n> > > \n> > > Thanks,\n> > > Jeremy Liu\n> >  \n> > Hi Jeremy,\n> >  \n> > As you\'ve discovered there have been a few attempts at getting some work\n> > started in this area. Dan Berrange outlined some of the possibilities in\n> > this area\n> > in a previous mailing list post [1] though it\'s multi-faceted, there are a\n> > lot of\n> > different ways to break it down. If you dig into the details you will note\n> > that the\n> > support-libvirt-vcpu-topology blueprint in particular got a fair way along\n> > but\n> > there were some concerns noted in the code reviews and on the list [2]\n> > around\n> > the design.\n> >  \n> > It seems like this is an area that there is a decent amount of interest in\n> > and we\n> > should work on list to flesh out a design proposal, ideally this would be\n> > presented for further discussion at the Juno design summit. What are your\n> > particular needs/desires from a NUMA aware nova scheduler?\n> >  \n> > Thanks,\n> >  \n> > Steve\n> >  \n> > [1]\n> > http://lists.openstack.org/pipermail/openstack-dev/2013-November/019715.h\n> > tml\n> > [2]\n> > http://lists.openstack.org/pipermail/openstack-dev/2013-December/022940.h\n> > tml\n> >  \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nProduct Manager, Red Hat Enterprise Linux OpenStack Platform\nRed Hat Canada (Toronto, Ontario)\n\n\n','<1529359307.68657.1394011342151.JavaMail.hzwangpan@corp.netease.com>',NULL),('<1005185443.31.1371191013061.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-14 06:23:33',0,'2013-06-14 06:23:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #256','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/256/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43774\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43774/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (26270) wsgi starting up on http://127.0.0.1:43774/\n\nnova.osapi_compute.wsgi.server: INFO: (26270) accepted (\'127.0.0.1\', 42054)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [14/Jun/2013 06:18:14] \"GET /v2 HTTP/1.1\" 204 216 0.000775\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-ea281cbf-e14b-4c0c-b821-125782db6584</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (26270) accepted (\'127.0.0.1\', 42055)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x6f59050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x6f59050>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43774/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-14 06:18:14 26270 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43774/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [14/Jun/2013 06:18:14] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.265084\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 0df7df0183844b159cb0724bcdc0ca98 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:51832\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:51832/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (26270) wsgi starting up on http://127.0.0.1:51832/\n\nnova.osapi_compute.wsgi.server: INFO: (26270) accepted (\'127.0.0.1\', 36493)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [14/Jun/2013 06:18:14] \"GET /v2 HTTP/1.1\" 204 216 0.000989\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-ded2c0fb-08c8-450e-bd36-e5f5fa0c4c67</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (26270) accepted (\'127.0.0.1\', 36494)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x600ce50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x600ce50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:51832/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     name)\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-14 06:18:15 26270 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:51832/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [14/Jun/2013 06:18:15] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.423044\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.16\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.DuQvPkJkPA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/256\n[SCP] Copying console log.\n\n\n','<1331149883.29.1371104800119.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1005512524.100.1384495216071.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-15 06:00:15',0,'2013-11-15 06:00:15',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #53','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/53/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-659612 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/ws/>\n[periodic-tempest-devstack-vm-stress] $ /bin/bash -xe /tmp/hudson5593130733881816593.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: Failed to connect to 2001:4800:780d:509:3bc3:d7f6:ff04:39f0: Network is unreachable while accessing https://review.openstack.org/p/openstack-infra/devstack-gate/info/refs\nfatal: HTTP request failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-659612\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-659612/53\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1006443029.34.1383372171247.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:02:51',0,'2013-11-02 06:02:51',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-keystone-docs-stable-folsom #53','See <https://jenkins01.openstack.org/job/periodic-keystone-docs-stable-folsom/53/>\n\n\n\n',NULL,NULL),('<1007073706.50.1365488201054.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-09 06:16:41',0,'2013-04-09 06:16:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-folsom #190','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/190/>\n\n------------------------------------------\n[...truncated 11910 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\nRuntimeError: maximum recursion depth exceeded while calling a Python object\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: S3 Objectstore listening on 127.0.0.1:3333\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Test key operations on buckets.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/tests/test_objectstore.py\",> line 65, in setUp\n    port=FLAGS.s3_port)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/wsgi.py\",> line 72, in __init__\n    self._socket = eventlet.listen((host, port), backlog=backlog)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/convenience.py\",> line 38, in listen\n    sock.bind(addr)\n  File \"/usr/lib/python2.7/socket.py\", line 224, in meth\n    return getattr(self._sock,name)(*args)\nerror: [Errno 98] Address already in use\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure we are starting with no buckets.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/tests/test_objectstore.py\",> line 65, in setUp\n    port=FLAGS.s3_port)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/wsgi.py\",> line 72, in __init__\n    self._socket = eventlet.listen((host, port), backlog=backlog)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/convenience.py\",> line 38, in listen\n    sock.bind(addr)\n  File \"/usr/lib/python2.7/socket.py\", line 224, in meth\n    return getattr(self._sock,name)(*args)\nerror: [Errno 98] Address already in use\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_unknown_bucket (nova.tests.test_objectstore.S3APITestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/tests/test_objectstore.py\",> line 65, in setUp\n    port=FLAGS.s3_port)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/wsgi.py\",> line 72, in __init__\n    self._socket = eventlet.listen((host, port), backlog=backlog)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/convenience.py\",> line 38, in listen\n    sock.bind(addr)\n  File \"/usr/lib/python2.7/socket.py\", line 224, in meth\n    return getattr(self._sock,name)(*args)\nerror: [Errno 98] Address already in use\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 26.05 secs:\n    7.97    ComputeTestCase.test_state_revert\n    5.39    CloudTestCase.test_instance_initiated_shutdown_behavior\n    5.06    StorwizeSVCDriverTestCase.test_storwize_svc_flashcopy\n    4.50    ServersTest.test_create_multiple_servers\n    3.12    ServersTest.test_create_and_rebuild_server\n----------------------------------------------------------------------\nRan 3726 tests in 628.153s\n\nFAILED (SKIP=7, errors=11)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==1.0.4\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosehtmloutput==0.0.4\nnova==2012.2.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nova/tests/nose_results.html\n+ \'[\' -f ./nova/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nova/tests/nose_results.html\n+ passcount=457\n+ \'[\' 457 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.6ZyMajtKXI\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-folsom/190\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-nova-python27-stable-folsom/190/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1007864355.7.1375941968973.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-08 06:06:08',0,'2013-08-08 06:06:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-grizzly #2','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/2/>\n\n\n\n','<866203150.6.1375855632515.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1008867068.232.1356653291243.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-28 00:08:11',0,'2012-12-28 00:08:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #88','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/88/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.66 secs:\n    2.49    Kc11TestCase.test_admin_requires_adminness\n    2.38    KcEssex3TestCase.test_admin_requires_adminness\n    2.20    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 48.819s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b2\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.0oOPk7DnJ0\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/88\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/88/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2060628959.213.1356566980829.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1008932208.21445205.1408444474343.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 06:34:34',-14400,'2014-08-19 10:34:34',NULL,'[openstack-dev] [qa] Using any username/password to create\n tempest clients','Hi Andrea,\n\nI tried adding the tenant to the credentials I supply - and it didn\'t change the results I am getting. I opened a bug on this issue:\nhttps://bugs.launchpad.net/tempest/+bug/1356759\n\nCan you devote some time to this bug, or let me know how to fix it and I will do it myself? \n\nThanks a lot for your help,\nUdi.\n\n----- Original Message -----\nFrom: \"Andrea Frittoli\" <andrea.frittoli at gmail.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, August 13, 2014 7:24:42 PM\nSubject: Re: [openstack-dev] [qa] Using any username/password to create tempest clients\n\nHello Udi, \n\nI don\'t see anything wrong in principle with your code. \nThis said, the main use case I had in mind when I wrote the auth providers and credentials classes was to abstract authentication for all tests, so that it is possible to configure and target identity api version to be used for authentication, and all tests will use that to obtain a token. \n\nIdentity tests are a bit different though, because when running an identity tests you typically want to specify which version of the identity API is to be used - like you did in your code. \nNonetheless you you should be able to use the same code from auth provider and credentials classes - but because identity tests have use more complex scenarios you may find issues or restrictions in the current implementation. \nI see that your credentials do not have a tenant - even though there is a simple unit test for that case, that case is not used in any other test atm, so you may as well have hit a bug. \n\nI think it would be helpful if you could push a WIP change - it would be easier to see what is going wrong. \n\nandrea \n\n\n\nOn 13 August 2014 10:41, Udi Kalifon < ukalifon at redhat.com > wrote: \n\n\nHello. \n\nI am writing a tempest scenario for keystone. In this scenario I create a domain, project and a user with admin rights on the project. I then try to instantiate a Manager so I can call keystone using the new user credentials: \n\ncreds = KeystoneV3Credentials(username=dom1proj1admin_name, password=dom1proj1admin_name, domain_name=dom1_name, user_domain_name=dom1_name) \nauth_provider = KeystoneV3AuthProvider(creds) \ncreds = auth_provider.fill_credentials() \nadmin_client = clients.Manager(interface=self._interface, credentials=creds) \n\nThe problem is that I get \"unauthorized\" return codes for every call I make with this client. I verified that the user is created properly and has the needed credentials, by manually authenticating and getting a token with his credentials and then using that token. Apparently, in my code I don\'t create the creds properly or I\'m missing another step. How can I use the new user in tempest properly? \n\nThanks in advance, \nUdi Kalifon. \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAB7WYGVnvfe+pRu-cYwxw1E+BYb_gtFcPQJUyx-kAS9sWfW2Fw@mail.gmail.com>',NULL),('<1009685140.10584407.1405338838029.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 07:53:58',-14400,'2014-07-14 11:53:58',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n\n> > So what we need to figure out is how exactly this common structure can be\n> > accommodated without reverting back to what Sandy called the \"wild west\"\n> > in another post.\n> \n> I got the impression that \"wild west\" is what we\'ve already got\n> (within the payload)?\n\nYeah, exactly, that was my interpretation too.\n\nSo basically just to ensure that the lightweight-schema/common-structure\nnotion doesn\'t land us back not too far beyond square one (if there are\ntoo many degrees-of-freedom in that declaration of \"a list of dicts with\ncertain required fields\" that you had envisaged in an earlier post).\n \n> > For example you could write up a brief wiki walking through how an\n> > existing widely-consumed notification might look under your vision,\n> > say compute.instance.start.end. Then post a link back here as an RFC.\n> >\n> > Or, possibly better, maybe submit up a strawman spec proposal to one\n> > of the relevant *-specs repos and invite folks to review in the usual\n> > way?\n> \n> Would oslo-specs (as in messaging) be the right place for that?\n\nThat\'s a good question.\n\nAnother approach would be to hone in on the producer-side that\'s\ncurrently the heaviest user of notifications, i.e. nova, and propose\nthe strawman to nova-specs given that (a) that\'s where much of the\nchange will be needed, and (b) many of the notification patterns\noriginated in nova and then were subsequently aped by other projects\nas they were spun up.\n\n> My thinking is the right thing to do is bounce around some questions\n> here (or perhaps in a new thread if this one has gone far enough off\n> track to have dropped people) and catch up on some loose ends.\n\nAbsolutely!\n \n> For example: It appears that CADF was designed for this sort of thing and\n> was considered at some point in the past. It would be useful to know\n> more of that story if there are any pointers.\n> \n> My initial reaction is that CADF has the stank of enterprisey all over\n> it rather than \"less is more\" and \"worse is better\" but that\'s a\n> completely uninformed and thus unfair opinion.\n\nTBH I don\'t know enough about CADF, but I know a man who does ;)\n\n(gordc, I\'m looking at you!)\n \n> Another question (from elsewhere in the thread) is if it is worth, in\n> the Ironic notifications, to try and cook up something generic or to\n> just carry on with what\'s being used.\n\nWell, my gut instinct is that the content of the Ironic notifications\nis perhaps on the outlier end of the spectrum compared to the more\ntraditional notifications we see emitted by nova, cinder etc. So it\nmay make better sense to concentrate initially on how contractizing\nthese more established notifications might play out.\n\n> > This feels like something that we should be thinking about with an eye\n> > to the K* cycle - would you agree?\n> \n> Yup.\n> \n> Thanks for helping to tease this all out and provide some direction on\n> where to go next.\n\nWell thank *you* for picking up the baton on this and running with it :)\n\nCheers,\nEoghan\n\n\n','<alpine.OSX.2.00.1407141144260.95036@crank.home>',NULL),('<1009717727.8187787.1393257496658.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 10:58:16',-18000,'2014-02-24 15:58:16',NULL,'[openstack-dev] [Neutron] L3 HA VRRP concerns','Hi everyone,\n\nA few concerns have popped up recently about [1] which I\'d like to share and discuss,\nand would love to hear your thoughts Sylvain.\n\n1) Is there a way through the API to know, for a given router, what agent is hosting\nthe active instance? This might be very important for admins to know.\n\n2) The current approach is to create an administrative network and subnet for VRRP traffic per router group /\nper router. Is this network counted in the quota for the tenant? (Clearly it shouldn\'t). Same\nquestion for the HA ports created for each router instance.\n\n3) The administrative network is created per router and takes away from the VLAN ranges if using\nVLAN tenant networks (For a tunneling based deployment this is a non-issue). Maybe we could\nconsider a change that creates an administrative network per tenant (Which would then limit\nthe solution to up to 255 routers because of VRRP\'d group limit), or an admin network per 255\nrouters?\n\n4) Maybe the VRRP hello and dead times should be configurable? I can see admins that would love to\nup or down these numbers.\n\n5) The administrative / VRRP networks, subnets and ports that are created - Will they be marked in any way\nas an \'internal\' network or some equivalent tag? Otherwise they\'d show up when running neutron net-list,\nin the Horizon networks listing as well as the graphical topology drawing (Which, personally, is what\nbothers me most about this). I\'d love them tagged and hidden from the normal net-list output,\nand something like a \'neutron net-list --all\' introduced.\n\n6) The IP subnet chosen for VRRP traffic is specified in neutron.conf. If a tenant creates a subnet\nwith the same range, and attaches a HA router to that subnet, the operation will fail as the router\ncannot have different interfaces belonging to the same subnet. Nir suggested to look into using\nthe 169.254.0.0/16 range as the default because we know it will (hopefully) not be allocated by tenants.\n\n[1] https://blueprints.launchpad.net/neutron/+spec/l3-high-availability\n\n\nAssaf Muller, Cloud Networking Engineer \nRed Hat \n\n\n','<1614970387.8178810.1393256618157.JavaMail.zimbra@redhat.com>',NULL),('<1009748473.19404998.1377781137302.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-29 08:58:57',-14400,'2013-08-29 12:58:57',NULL,'[openstack-dev] Glance revert to fix image deletes on F19','\n\n----- Original Message -----\n> From: \"Matt Riedemann\" <mriedem at us.ibm.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, August 28, 2013 9:24:21 PM\n> Subject: Re: [openstack-dev] Glance revert to fix image deletes on F19\n> \n> Dan,\n> \n> I saw you abandoned the patch because:\n> \n> \"Using Sqlalchemy 0.8.2 or downgrading to 0.7.10 seems to fix this issue.\"\n> \n> Given the glance requirement on SQLAlchemy:\n> \n> https://github.com/openstack/glance/blob/master/requirements.txt#L9\n> \n> Why were you at those levels to begin with?\n\nThat file is certainly helpful but doesn\'t explicitly mention 0.8.1 (or 0.8.2). So this was just new territory.\n\nBefore that commit Glance seemed to (functionally) work fine with SQLAlchemy 0.8.1.\n\nI just switched SmokeStack over to Fedora 19 last week. I had it as a work in progress for a couple weeks now and new that previously it was working... so perhaps this caught me a bit off guard.\n\nIn any case upgrading to 0.8.2 is the solution on Fedora 19 and we already have that fix in place.\n\nDan\n\n> \n> \n> \n> Thanks,\n> \n> MATT RIEDEMANN\n> Advisory Software Engineer\n> Cloud Solutions and OpenStack Development\n> \n> Phone: 1-507-253-7622 | Mobile: 1-507-990-1889\n> E-mail: mriedem at us.ibm.com\n> \n> \n> 3605 Hwy 52 N\n> Rochester, MN 55901-1407\n> United States\n> \n> \n> \n> \n> From:   Dan Prince <dprince at redhat.com>\n> To:     OpenStack Development Mailing List\n> <openstack-dev at lists.openstack.org>,\n> Date:   08/26/2013 07:21 AM\n> Subject:        [openstack-dev] Glance revert to fix image deletes on F19\n> \n> \n> \n> Hi all,\n> \n> I\'d like to highlight this Glance revert for an issue I started seeing on\n> Fedora 19 last week.\n> \n>   https://review.openstack.org/#/c/43542/\n> \n> A revert like this should be a very safe thing to do so long as we do it\n> quickly. Especially given this is a performance improvement...\n> \n> Dan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OF7FB88C88.A1257A70-ON86257BD6.00079807-86257BD6.0007BA07@us.ibm.com>',NULL),('<1009828486.414023.1415785593687.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 10:46:33',3600,'2014-11-12 09:46:33',NULL,'[openstack-dev] [Horizon] the future of angularjs\n	development	in Horizon','Thanks Martin, I remember that eslint was mentioned at some point to replace jshint. Maybe, it can be interesting to look at this, the extension possibility is a major point for a switch.\n\n----- Original Message -----\nFrom: \"Martin Geisler\" <martin at geisler.net>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, November 12, 2014 10:37:15 AM\nSubject: Re: [openstack-dev] [Horizon] the future of angularjs development	in Horizon\n\nRichard Jones <r1chardj0n3s at gmail.com> writes:\n\n> Hi all,\n>\n> At the summit last week, we developed a plan for moving forward with\n> modernising Horizon\'s UI using AngularJS. If you weren\'t at that meeting\n> and are interested in helping out with this effort please let me know!\n\nI have been working on an interface for Swift written in Angular. You\'ll\nfind a ready-to-deploy tarball and zip file here:\n\n  https://github.com/zerovm/swift-browser/releases/\n\nThis will eventually be an interface for starting ZeroVM instances on a\nSwift cluster, but for now it\'s a pure Swift interface.\n\nI don\'t know if this is something that can be used in Horizon, but maybe\nthere are useful bits.\n\nOne thing interesting thing in Swift Browser is its testing: I wrote a\n\"Swift simulator\" that is injected into the application for end-to-end\ntesting with Protractor. Is is basically an in-memory (and in-browser)\nSwift that responds to queries made against the Swift REST API. I\'ve\nfound that very useful in the development:\n\n  https://github.com/zerovm/swift-browser/blob/master/app/js/test/swift-simulator.js\n\nI don\'t know the other OpenStack components and their APIs very well,\nbut I guess that this kind of mocking might be too much for a full\nOpenStack dashboard.\n\n-- \nMartin Geisler\n\nhttp://google.com/+MartinGeisler\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<87oasclpys.fsf@hbox.dyndns.org>',NULL),('<100B6985-37D6-4346-931C-0409505D8B73@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 18:44:16',-14400,'2014-07-24 22:44:16',NULL,'[openstack-dev] debug logs and defaults was (Thoughts on the\n	patch test failure rate and moving forward)','\nOn Jul 24, 2014, at 6:05 PM, Robert Collins <robertc at robertcollins.net> wrote:\n\n> On 25 July 2014 08:01, Sean Dague <sean at dague.net> wrote:\n> \n>>> I\'d like us to think about whether they is anything we can do to make\n>>> life easier in these kind of hard debugging scenarios where the regular\n>>> logs are not sufficient.\n>> \n>> Agreed. Honestly, though we do also need to figure out first fail\n>> detection on our logs as well. Because realistically if we can\'t debug\n>> failures from those, then I really don\'t understand how we\'re ever going\n>> to expect large users to.\n> \n> \n> I\'m so glad you said that :). In conversations with our users, and\n> existing large deployers of Openstack, one thing has come through very\n> consistently: our default logs are insufficient.\n> \n> We had an extensive discussion about this in the TripleO mid-cycle\n> meetup, and I think we reached broad consensus on the following:\n> - the defaults should be what folk are running in production\n> - we don\'t want to lead on changing defaults - its a big enough thing\n> we want to drive the discussion but not workaround it by changing our\n> defaults\n> - large clouds are *today* running debug (with a few tweaks to remove\n> the most egregious log spammers and known security issues [like\n> dumping tokens into logs]\n> - AFAICT productised clouds (push-button deploy etc) are running\n> something very similar\n> - we would love it if developers *also* saw what users will see by\n> default, since that will tend to both stop things getting to spammy,\n> and too sparse.\n> \n> So - I know thats brief - what we\'d like to do is to poll a slightly\n> wider set of deployers - e.g. via a spec, perhaps some help from Tom\n\nThis one would be a good place for that conversation to start: https://review.openstack.org/#/c/91446/\n\n> with the users and ops groups - and get a baseline of things that\n> there is consensus on and things that aren\'t, and then just change the\n> defaults to match. Further, to achieve the \'developers see the same\n> thing as users\' bit, we\'d like to make devstack do what TripleO does -\n> use defaults for logging levels, particularly in the gate.\n> \n> Its totally true that we have a good policy about logging and we\'re\n> changing things to fit it but thats the long term play: short term,\n> making the default meet our deployments seems realtively easy and\n> immensely sane.\n> \n> -Rob\n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAJ3HoZ3gJgSJGAKw7sVkjcPZ4hMKKi0TPnwLR1mvLx6UWc=8Bw@mail.gmail.com>',NULL),('<1010496329.239583.1415865368789.JavaMail.yahoo@jws100110.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 07:56:08',0,'2014-11-13 07:56:08',NULL,'[openstack-dev] [all] Versioned objects cross project sessions\n next steps','Neat,\nDidn\'t know that existed.\nhttp://kentonv.github.io/capnproto/language.html does look pretty nice...\n\n-Josh      From: Robert Collins <robertc at robertcollins.net>\n To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \n Sent: Wednesday, November 12, 2014 10:12 PM\n Subject: Re: [openstack-dev] [all] Versioned objects cross project sessions next steps\n   \nOn 11 November 2014 13:30, Angus Salkeld <asalkeld at mirantis.com> wrote:\n> Hi all\n>\n> I just wanted to make sure we are all under the same understanding of the\n> outcomes and what the next steps for the versioned objects session are.\n>\n> 1. There is a lot of interest in other projects using oslo versioned objects\n> and it is worth progressing with this\n> (https://review.openstack.org/#/c/127532).\n> 2. jpipes and jharlow suggested experimenting/investigating google protocol\n> buffers (https://developers.google.com/protocol-buffers/) instead of? the\n> custom serialization and version code. This *could* be an implementation\n> detail, but also could make the adoption by nova more complicated (as it has\n> a different mechanism in place).\n> 3. vish brought up one draw back of versioned objects: the difficulty in\n> cherry picking commits for stable branches - Is this a show stopper?.\n>\n> Next steps:\n> - Jay suggested making a second spec that would lay out what it would look\n> like if we used google protocol buffers.\n> - Dan: do you need some help in making this happen, do we need some\n> volunteers?\n> - Are there any other concrete things we can do to get this usable by other\n> projects in a timely manner?\n\n+1 on protocol buffers, but perhaps\nhttp://kentonv.github.io/capnproto/ could be considered: its protocol\nbuffers v2 basically - from one of the originators of protocol\nbuffers. It has Python support available too, just like protocol\nbuffers.\n\n-Rob\n\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n  \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141113/701e950e/attachment.html>\n\n','<CAJ3HoZ0yr=1R7GBpjz6uy7ca0Mbc=9AYRfw3Zj=PEwiTAx+Rxg@mail.gmail.com>',NULL),('<1010773922.120366.1414239818385.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-10-25 08:23:38',-14400,'2014-10-25 12:23:38',NULL,'[User-committee] Telcom Working Group','----- Original Message -----\n> From: \"Andrew Mitry\" <amitry at gmail.com>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> \n> Hello all,\n> \n> I spoke with Carol today and wanted to detail what the original thought\n> around the telco working group was.  At the Atlanta summit we saw a\n> proliferation of vendors trying to address the telco/service provider space\n> and much of the value add they were claiming to offer was around making\n> OpenStack operate at \"carrier grade\" scale with key functionality such as\n> IPv6.  When I discussed this with my peers at DT, Orange, TWC and AT&T we\n> agreed that would rather work towards maturing OpenStack by providing\n> feedback and develop support directly in the community.\n> \n> There are many use cases that are unique to telco/service providers that\n> don\'t always get represented in the community as much as we thought they\n> should.  Some examples maybe IPv6, support for apps with high connections\n> per second (DNS, Voice), high bandwidth apps (CDN, Video).  We were hoping\n> to flesh these use cases out in the working group and coordinate how we\n> could bring the appropriate developer support and operator feedback to move\n> things along.\n> \n> We did see this working group as primarily operator rather than vendor\n> driven, but vendors of course would be welcome.\n> \n> I hope that helps provide some context.\n> \n> Thanks,\n> Andrew\n\nHi Andrew,\n\nWhat I am still looking for is some explanation of how this new group would differ from the existing one, and as importantly if the answer is not significantly what the barriers were to operator participation in the existing group? The issues you outline above actually overlap with the goals the existing effort more so than Carol\'s original outline.\n\nThe BoF meetings where the existing group was formed in Atlanta were well attended by operators, equipment providers, and vendors (and this is reflected on the membership page) though it would admittedly have been great to see more participation particularly from operators throughout the cycle.\n\nIf the only issue is who facilitates the group I am (very) open to someone else taking that role, but it is important that whoever does facilitate understands how to productively engage the development community.\n\nThanks,\n\nSteve\n\n\n> On Thu, Oct 23, 2014 at 4:22 PM, Steve Gordon <sgordon at redhat.com> wrote:\n> \n> > Hi all,\n> >\n> > I spoke with Carol on the phone earlier to try and clarify the situation\n> > but wanted to ensure my thoughts are recorded on the list as well. By way\n> > of background I currently facilitate the existing NFV sub team with the\n> > help of a couple of others (volunteers welcome!) which consists of people\n> > from service providers, network equipment providers, and OpenStack vendors\n> > interested in this space:\n> >\n> >     https://wiki.openstack.org/wiki/Meetings/NFV\n> >\n> > It\'s thus far been primarily focussed on identifying use\n> > cases/requirements for NFV, turning these into actionable OpenStack\n> > blueprints, and finally implementing these. This effort started in Atlanta,\n> > made some progress in Juno, and is now hoping to regroup in Paris to drive\n> > further improvements in Kilo.\n> >\n> > > -------- Forwarded Message --------\n> > > Subject:      [User-committee] Telcom Working Group\n> > > Date:         Wed, 22 Oct 2014 19:28:48 +0000\n> > > From:         Barrett, Carol L <carol.l.barrett at intel.com>\n> > > To:   user-committee at lists.openstack.org\n> > > <user-committee at lists.openstack.org>\n> > >\n> > >\n> > >\n> > > Hi All ? I?m glad to see the interest in forming a Telco Work group. I?d\n> > > like to propose a charter and scope as a starting point for discussion:\n> > >\n> > > Charter (if one is already in development pls let me know):\n> > >\n> > >   * Foster discussion amongst Telco users of OpenStack to share BKMs,\n> > >     resolve issues, etc.\n> > >   * Gather information on add?l features, functions, capabilities,\n> > >     services needed to increase OpenStack deployments by Telco users and\n> > >     engage OpenStack community developers to discuss/implement\n> > >   * Understand business, market and ecosystem barriers to OpenStack\n> > >     deployments and work with the community to create action plans to\n> > >     address them.\n> >\n> > As I may have indicated above I see (1) and (2) as largely being the\n> > combination of the efforts of the existing group and ETSI NFV (see\n> > https://wiki.openstack.org/w/images/c/c7/NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf\n> > for the latest copy of the OpenStack gap analysis provided by ETSI NFV).\n> > How other initiatives like OPNFV might fit into this is unknown but it\n> > seems like (3) is the item raised that is currently not directly addressed\n> > in the context of OpenStack at least by the Foundation, the Board, or\n> > community driven initiatives like the existing working group.\n> >\n> > It\'s not immediately clear whether addressing this requires a completely\n> > new working group, and the inherent confusion from having two groups\n> > working in the same space in the same community or some way to address\n> > within the auspices of existing frameworks with some loose but defined\n> > coupling to the requirement identification and development activities\n> > occurring in the community.\n> >\n> > > Scope:\n> > >\n> > >   * Include the current NFV Work Group into this team bringing community\n> > >     developers\n> >\n> > It\'s important to note that it can\'t be assumed that developers from the\n> > existing community will necessarily follow, particularly if the effort is\n> > seen to be too marketing/business centric and a distraction from actually\n> > implementing the required functionality. Building a developer community\n> > around this space has been non-trivial precisely because of the gap between\n> > the marketing hype around NFV and the current realities of implementation.\n> > I understand the desire to make the marketing story more specific to\n> > OpenStack, but simply wanted to highlight that if there is one thing NFV\n> > can\'t be accused of it\'s not having enough marketing!\n> >\n> > Certainly when I raised the topic in the weekly meeting on Wednesday there\n> > was some scepticism about any attempt to combine efforts here distracting\n> > from laying out design and implementation priorities for Kilo which is\n> > front and centre for the existing group. The reason I had raised it however\n> > remains valid, per some conversation on the community list it appears to be\n> > more difficult at this venue to informally obtain space for BoF style\n> > activities then it has been in the past.\n> >\n> > In Atlanta we used one of the development pods but due to the number of\n> > interested parties this proved quite difficult to manage, it was also hard\n> > to identify exactly where we would be and what time until we were on the\n> > ground at the event. We got plenty of feedback that there was not enough\n> > notice for everyone to attend.\n> >\n> > For this reason if there is consensus that there really does need to be a\n> > separate effort to address the marketing/business side of the coin I would\n> > still be interested in the idea of co-locating in the space scheduled for\n> > this working group on the Wednesday afternoon and effectively splitting the\n> > room. This would allow all of those interested in this space to attend a\n> > single venue, which we can get out in advance, and self select which area\n> > they are interested in assisting with.\n> >\n> > Thanks,\n> >\n> > Steve\n> >\n> > >   * Create a Marketing/Business team in the work group to work on\n> > >     messaging framework, customer whitepapers, reference architectures,\n> > >     etc. This group could also interact with OPNFV, ETSI NFV and other\n> > >     groups where there?s common interests.\n> > >   * Create an Ecosystem team in the work group to develop the\n> > >     Marketplace and create reference materials to support OpenStack\n> > >     deployments\n> > >\n> > > Is there interest in meeting in Paris to kick-off this work group?\n> > > Regards.\n> > > Carol\n> >\n> >\n> > _______________________________________________\n> > User-committee mailing list\n> > User-committee at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n> >\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<CAAGm4fO2=8y3Uh-TDFVgXGxjcX3QNPTbqXxo=ddvwrOfiQ=PsA@mail.gmail.com>',NULL),('<1010827326.11.1387260611175.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-17 06:10:11',0,'2013-12-17 06:10:11',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-nova-docs-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-nova-docs-grizzly/8/changes>\n\n\n\n','<685708970.3.1387001131537.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<10118352.3769.1351586201784.JavaMail.sthakkar@sthakkar-mbair.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-30 01:36:43',-25200,'2012-10-30 08:36:43',NULL,'[openstack-dev] [Quantum] [LBaaS] Re: LBaaS & Quantum - Grizzly\n	Work Planning','Hi Anand,\n\nThanks for setting this up. My suggested expansion to the agenda would be:\n\n(1) Specifying the blueprints for G1/G2/G3. There are several blueprints we have discussed, the key will be separating them into the phases. Here are a few topics:\n- Tenant API\n- Base Plugin\n- Plugin Interface / Service Insertion integration\n- Device Management\n- Vendor Plugins\n- API scale out\n- etc.\n\n(2) Ironing out the discussion points regarding the API as mentioned on the mailer\n\n(3) Ironing out the discussion regarding Service Insertion & LBaaS also started on the mailer\n\n(4) Work distribution for blueprints / Resourcing\n\nIn my opinion, it\'s in our interest initially to keep things simple and straight-forward to remove all impediments for progress (over-complicating API, implementation logic, corner cases etc.).\n\nLook forward to discussing more with the team tomorrow.\n\nThanks,\nSachin\n\n----- Original Message -----\nFrom: \"Anand Palanisamy\" <apalanisamy at paypal.com>\nSent: Monday, October 29, 2012 8:47:37 PM\nSubject: Re: LBaaS & Quantum - Grizzly Work Planning\n\n\nHello All, \n\n\nFind the \"Quantum-LBaaS\" meeting details at http://wiki.openstack.org/Network/Meetings . \n\n\nPlease subscribe to openstack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\nLet us decide tomorrow about moving from conference bridge to IRC Team Meeting. \n\n\nThanks \nAnand \n\nFrom: apalanisamy at paypal.com \nWhen: 9:00 AM - 10:00 AM October 30, 2012 \nSubject: LBaaS & Quantum - Grizzly Work Planning \nLocation: (855) 227-1767(USA) - Conf. Code 7152259 \n\n\n\n\n\n\n\n\nAgenda: \n\n    * Blue Prints \n    * Service Insertion with Quantum \n    * LBaaS Implementation Components \n\nhttps://myroom-na.adobeconnect.com/anandpalanisamy/ \n\n\n(855) 227-1767(USA) - 08003765931(UK) Conf. Code 7152259 \n\n\n0008006103229 (India ? Toll Free) \n81080024322044(Moscow) 4992701688(Moscow) \n\n\nhttps://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7152259&name=&email=&selectedProduct=joinMeeting\n\n\n','<555471ADD78F124AB598DADE6A32B3771FF020@DEN-EXDDA-S12.corp.ebay.com>',NULL),('<1013024802.1867848.1414545970669.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-28 21:26:10',-14400,'2014-10-29 01:26:10',NULL,'[OpenStack-docs] Can we push stable/juno out a day or two?','----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> \n> Several of the core service packages skipped RC1 and went from milestone 3\n> to RC2. I generally avoid mixing packages with a difference of more than\n> one milestone/RC version... especially milestones given significant changes\n> to the services.\n\nI understand that practice when it comes to the milestone builds, but I don\'t think it really makes sense when it comes to the RCs. Either way, we had packaged builds of the final release available on the 22nd/23rd. This probably went under the radar as we held off on the formal announcement, but nobody asked me about it so I didn\'t realize that the formal email was a blocker for docs.\n\n> P.S. - Does anyone from RH work on the installation guide these days?\n\nDeepti is available to work on upstream guides, I think when she had discussed priorities with Anne the main ones that came up were identity federation and some other keystone issues that she has been trying to work on. If you need assistance feel free to ask her for help.\n\nThanks,\n\nSteve\n\n> On Tue, Oct 28, 2014 at 7:28 PM, Steve Gordon <sgordon at redhat.com> wrote:\n> \n> > ----- Original Message -----\n> > > From: \"Steve Gordon\" <sgordon at redhat.com>\n> > > To: \"Matt Kassawara\" <mkassawara at gmail.com>\n> > >\n> > > ----- Original Message -----\n> > > > From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> > > > To: \"Steve Gordon\" <sgordon at redhat.com>\n> > > >\n> > > > While OpenStack RC code often sufficiently tests services, packaging\n> > > > concerns such as dependencies and default configuration options tend\n> > to lag\n> > > > by one or more milestone/RC cycles. The RDO repository only contained\n> > > > milestone 3 packages until just prior to the official release of Juno\n> > when\n> > > > RC2 packages appeared in it.\n> > >\n> > > RC2 tarballs themselves only became available just prior to the official\n> > > release (e.g. Oct 9th for Cinder, Oct 10th for Neutron) and were put into\n> > > the repo on the 13th. The gap between RC1 tarballs being available and\n> > being\n> > > put in the repo was similar.\n> > >\n> > > > Testing packages (even just the core services), writing patches,\n> > reviewing\n> > > > patches, and general time allocation\n> > > > issues can delay a functional installation guide by a week or more\n> > beyond\n> > > > the package release date. Furthermore, the RDO packages require\n> > testing on\n> > > > RHEL/CentOS and Fedora plus the neutron and nova-network variations. I\n> > > > would like to provide users with a mostly functional installation\n> > guide on\n> > > > the official release date which would require availability of at least\n> > RC\n> > > > packages at least one week prior to the official release date.\n> > > > release packages becoming available yesterday afternoon and the plan\n> > to cut\n> > > > juno/stable for openstack-manuals tomorrow gives us about one day to\n> > > > install the packages on two distributions each with two variants,\n> > determine\n> > > > the issues, write patches, test them, and run them through the review\n> > > > process before all changes involve backports.\n> > >\n> > > As a result of user feedback from previous test days we stage and test\n> > the\n> > > RDO packages to ensure basic sanity before putting them into the repo,\n> > this\n> > > takes time but ensures that we have at least some level of confidence in\n> > the\n> > > packages being deployed and avoids user frustration caused by basic\n> > issues\n> > > that can be easily prevented. If you wish to access the staged packages\n> > in\n> > > future while they are still undergoing testing, just ask (they are\n> > public,\n> > > just not in the main repo).\n> >\n> > Going back through the repo [1] we pushed builds based on the final\n> > release into the repo on the 22nd/23rd and held off formally announcing\n> > while we fixed a few more bugs over the weekend.\n> >\n> > Thanks,\n> >\n> > Steve\n> >\n> > [1]\n> > https://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/?C=M;O=A\n> > > > On Tue, Oct 28, 2014 at 4:23 PM, Steve Gordon <sgordon at redhat.com>\n> > wrote:\n> > > >\n> > > > > ----- Original Message -----\n> > > > > > From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> > > > > > To: \"Anne Gentle\" <anne at openstack.org>\n> > > > > >\n> > > > > > If other reasons (outside of the installation guide) exist to move\n> > it\n> > > > > > on\n> > > > > > the 29th rather than wait until after the summit, I can deal... but\n> > > > > > backporting patches for RHEL/CentOS/Fedora will take more time and\n> > > > > effort.\n> > > > > > Not our fault RDO can\'t push release packages out in a reasonable\n> > > > > > amount\n> > > > > of\n> > > > > > time.\n> > > > >\n> > > > > Can you elaborate on what\'s reasonable so we can endeavour to\n> > accommodate\n> > > > > in future? Our aim this time around was for +2 weeks on upstream\n> > release\n> > > > > to\n> > > > > allow some level of smoke testing to occur, despite that M-3 and RC\n> > > > > packages that could have been used were available leading up to this.\n> > > > >\n> > > > > We\'ve been communicating this to users @\n> > > > > https://www.redhat.com/archives/rdo-list/\n> > > > >\n> > > > > Thanks,\n> > > > >\n> > > > > Steve\n> > > > >\n> > > > > > On Mon, Oct 27, 2014 at 9:45 PM, Anne Gentle <anne at openstack.org>\n> > > > > > wrote:\n> > > > > >\n> > > > > > >\n> > > > > > > On Mon, Oct 27, 2014 at 9:34 PM, Matt Kassawara\n> > > > > > > <mkassawara at gmail.com>\n> > > > > > > wrote:\n> > > > > > >\n> > > > > > >> The RDO Juno release packages for RHEL/CentOS/Fedora only became\n> > > > > > >> available today [1] which leaves very little time for testing\n> > and\n> > > > > patching\n> > > > > > >> the installation guide prior to cutting juno/stable for\n> > > > > openstack-manuals\n> > > > > > >> on the 29th. Can we push it out a day or two?\n> > > > > > >>\n> > > > > > >\n> > > > > > > I think if we don\'t do the 29th it\'ll be after Nov 7th due to\n> > > > > > > Andreas\'s\n> > > > > > > and my travel schedules, is that an okay solution?\n> > > > > > >\n> > > > > > >\n> > > > > > >>\n> > > > > > >> [1]\n> > > > > > >>\n> > > > >\n> > https://openstack.redhat.com/forum/discussion/992/rdo-juno-packages-available\n> > > > > > >>\n> > > > > > >> _______________________________________________\n> > > > > > >> OpenStack-docs mailing list\n> > > > > > >> OpenStack-docs at lists.openstack.org\n> > > > > > >>\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > > > > > >>\n> > > > > > >>\n> > > > > > >\n> > > > > >\n> > > > > > _______________________________________________\n> > > > > > OpenStack-docs mailing list\n> > > > > > OpenStack-docs at lists.openstack.org\n> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > > > > >\n> > > > >\n> > > > > --\n> > > > > Steve Gordon, RHCE\n> > > > > Sr. Technical Product Manager,\n> > > > > Red Hat Enterprise Linux OpenStack Platform\n> > > > >\n> > > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-docs mailing list\n> > > OpenStack-docs at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > >\n> >\n> > --\n> > Steve Gordon, RHCE\n> > Sr. Technical Product Manager,\n> > Red Hat Enterprise Linux OpenStack Platform\n> >\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<CABA+jQqTkn8cLZnrZfEmRVBZz5dqTeEgkh+KRq+rMkmM7JHqfw@mail.gmail.com>',NULL),('<1013494263.411.1359417717597.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 00:01:57',0,'2013-01-29 00:01:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-folsom #120','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/120/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric4 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/>\nCheckout:periodic-swift-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/> - hudson.remoting.Channel at 7ed9a08f:oneiric4\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.1.1\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson6558359278585164562.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.RigEnn4u76\n+ TMPDIR=/tmp/tmp.RigEnn4u76\n+ trap \'rm -rf /tmp/tmp.RigEnn4u76\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/120/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python26-stable-folsom-120\', \'SSH_CLIENT\': \'198.101.231.203 56756 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1358004656.871334-577647899\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric4\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.RigEnn4u76\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-29_00-01-21\', \'BUILD_NUMBER\': \'120\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'2212f0dc-228c-4057-96f9-3a8a0849496a\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric4\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 56756 166.78.31.217 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.RigEnn4u76\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-folsom/120\n[SCP] Copying console log.\n\n\n','<513904507.393.1359331318481.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1014102952.5634599.1410435164855.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 07:32:44',-14400,'2014-09-11 11:32:44',NULL,'[openstack-dev] Kilo Cycle Goals Exercise','\n\n> As you all know, there has recently been several very active discussions\n> around how to improve assorted aspects of our development process. One idea\n> that was brought up is to come up with a list of cycle goals/project\n> priorities for Kilo [0].\n> \n> To that end, I would like to propose an exercise as discussed in the TC\n> meeting yesterday [1]:\n> Have anyone interested (especially TC members) come up with a list of what\n> they think the project wide Kilo cycle goals should be and post them on this\n> thread ...\n\nHere\'s my list of high-level cycle goals, for consideration ...\n\n\n1. Address our usability debts\n\nWith some justification, we\'ve been saddled with the perception\nof not caring enough about the plight of users and operators. The\nfrustrating thing is that much of this is very fixable, *if* we take\ntime out from the headlong rush to add features. Achievable things\nlike documentation completeness, API consistency, CLI intuitiveness,\nlogging standardization, would all go a long way here.\n\nThese things are of course all not beyond the wit of man, but we\nneed to take the time out to actually do them. This may involve\na milestone, or even longer, where we accept that the rate of\nfeature addition will be deliberately slowed down. \n\n\n2. Address the drags on our development velocity\n\nDespite the Trojan efforts of the QA team, the periodic brownouts\nin the gate are having a serious impact on our velocity. Over the\npast few cycles, we\'ve seen the turnaround time for patch check/\nverification spike up unacceptably long multiple times, mostly\naround the milestones.\n\nWhatever we can do to smoothen out these spikes, whether it be\nmoving much of the Tempest coverage into the project trees, or\nswitching focus onto post-merge verification as suggested by\nSean on this thread, or even considering some more left-field\napproaches such as staggered milestones, we need to grasp this\nnettle as a matter of urgency.\n\nFurther back in the pipeline, the effort required to actually get\nsomething shepherded through review is steadily growing. To the\npoint that we need to consider some radical approaches that\nretain the best of our self-organizing model, while setting more\nreasonable & reliable expectations for patch authors, and making\nit more likely that narrow domain expertise is available to review\ntheir contributions in timely way. For the larger projects, this\nis likely to mean something different (along the lines of splits\nor sub-domains) than it does for the smaller projects.\n\n\n3. Address the long-running \"what\'s in and what\'s out\" questions\n\nThe way some of the discussions about integration and incubation \nplayed out this cycle have made me sad. Not all of these discussions\nhave been fully supported by the facts on the ground IMO. And not\nall of the issues that have been held up as justifications for\nwhatever course of exclusion or inclusion would IMO actually be\nsolved in that way.\n\nI think we need to move the discussion around a new concept of\nlayering, or redefining what it means to be \"in the tent\", to a\nmore constructive and collaborative place than heretofore.\n\n\n4. Address the fuzziness in cross-service interactions\n\nIn a semi-organic way, we\'ve gone and built ourselves a big ol\'\nservice-oriented architecture. But without necessarily always\nfollowing the strong contracts, loose coupling, discoverability,\nand autonomy that a SOA approach implies.\n\nWe need to take the time to go back and pay down some of the debt\nthat has accreted over multiple cycles around these these\ncross-service interactions. The most pressing of these would\ninclude finally biting the bullet on the oft-proposed but never\ndelivered-upon notion of stabilizing notifications behind a\nwell-defined contract. Also, the more recently advocated notions\nof moving away from coarse-grained versioning of the inter-service\nAPIs, and supporting better introspection and discovery of\ncapabilities.\n\n> by end of day Wednesday, September 10th.\n\nOh, yeah, and impose fewer arbitrary deadlines ;)\n\nCheers,\nEoghan\n\n> After which time we can\n> begin discussing the results.\n> The goal of this exercise is to help us see if our individual world views\n> align with the greater community, and to get the ball rolling on a larger\n> discussion of where as a project we should be focusing more time.\n> \n> \n> best,\n> Joe Gordon\n> \n> [0]\n> http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html\n> [1]\n> http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHXdxOc_xm2zeWHhk9MzCZcEfjR9pioGMWJ5SLnQPm4JMXGKzQ@mail.gmail.com>',NULL),('<1014152328.26740540.1402755745959.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-14 10:22:25',-14400,'2014-06-14 14:22:25',NULL,'[openstack-dev] [nova][ceilometer] FloatingIp pollster spamming\n n-api logs (bug 1328694)','\n\n> On 6/12/2014 10:31 AM, John Garbutt wrote:\n> > On 11 June 2014 20:07, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> >> On Wed, Jun 11, 2014 at 11:38 AM, Matt Riedemann\n> >> <mriedem at linux.vnet.ibm.com> wrote:\n> >>> On 6/11/2014 10:01 AM, Eoghan Glynn wrote:\n> >>>> Thanks for bringing this to the list Matt, comments inline ...\n> >>>>\n> >>>>> tl;dr: some pervasive changes were made to nova to enable polling in\n> >>>>> ceilometer which broke some things and in my opinion shouldn\'t have\n> >>>>> been\n> >>>>> merged as a bug fix but rather should have been a blueprint.\n> >>>>>\n> >>>>> ===\n> >>>>>\n> >>>>> The detailed version:\n> >>>>>\n> >>>>> I opened bug 1328694 [1] yesterday and found that came back to some\n> >>>>> changes made in ceilometer for bug 1262124 [2].\n> >>>>>\n> >>>>> Upon further inspection, the original ceilometer bug 1262124 made some\n> >>>>> changes to the nova os-floating-ips API extension and the database API\n> >>>>> [3], and changes to python-novaclient [4] to enable ceilometer to use\n> >>>>> the new API changes (basically pass --all-tenants when listing floating\n> >>>>> IPs).\n> >>>>>\n> >>>>> The original nova change introduced bug 1328694 which spams the\n> >>>>> nova-api\n> >>>>> logs due to the ceilometer change [5] which does the polling, and right\n> >>>>> now in the gate ceilometer is polling every 15 seconds.\n> >>>>\n> >>>>\n> >>>> IIUC that polling cadence in the gate is in the process of being\n> >>>> reverted\n> >>>> to the out-of-the-box default of 600s.\n> >>>>\n> >>>>> I pushed a revert in ceilometer to fix the spam bug and a separate\n> >>>>> patch\n> >>>>> was pushed to nova to fix the problem in the network API.\n> >>>>\n> >>>>\n> >>>> Thank you for that. The revert is just now approved on the ceilometer\n> >>>> side,\n> >>>> and is wending its merry way through the gate.\n> >>>>\n> >>>>> The bigger problem I see here is that these changes were all made under\n> >>>>> the guise of a bug when I think this is actually a blueprint.  We have\n> >>>>> changes to the nova API, changes to the nova database API, CLI changes,\n> >>>>> potential performance impacts (ceilometer can be hitting the nova\n> >>>>> database a lot when polling here), security impacts (ceilometer needs\n> >>>>> admin access to the nova API to list floating IPs for all tenants),\n> >>>>> documentation impacts (the API and CLI changes are not documented),\n> >>>>> etc.\n> >>>>>\n> >>>>> So right now we\'re left with, in my mind, two questions:\n> >>>>>\n> >>>>> 1. Do we just fix the spam bug 1328694 and move on, or\n> >>>>> 2. Do we revert the nova API/CLI changes and require this goes through\n> >>>>> the nova-spec blueprint review process, which should have happened in\n> >>>>> the first place.\n> >>>>\n> >>>>\n> >>>> So just to repeat the points I made on the unlogged #os-nova IRC channel\n> >>>> earlier, for posterity here ...\n> >>>>\n> >>>> Nova already exposed an all_tenants flag in multiple APIs (servers,\n> >>>> volumes,\n> >>>> security-groups etc.) and these would have:\n> >>>>\n> >>>>     (a) generally pre-existed ceilometer\'s usage of the corresponding\n> >>>>     APIs\n> >>>>\n> >>>> and:\n> >>>>\n> >>>>     (b) been tracked and proposed at the time via straight-forward LP\n> >>>> bugs,\n> >>>>         as  opposed to being considered blueprint material\n> >>>>\n> >>>> So the manner of the addition of the all_tenants flag to the\n> >>>> floating_ips\n> >>>> API looks like it just followed existing custom & practice.\n> >>>>\n> >>>> Though that said, the blueprint process and in particular the nova-specs\n> >>>> aspect, has been tightened up since then.\n> >>>>\n> >>>> My preference would be to fix the issue in the underlying API, but to\n> >>>> use\n> >>>> this as \"a teachable moment\" ... i.e. to require more oversight (in the\n> >>>> form of a reviewed & approved BP spec) when such API changes are\n> >>>> proposed\n> >>>> in the future.\n> >>>>\n> >>>> Cheers,\n> >>>> Eoghan\n> >>>>\n> >>>>> Are there other concerns here?  If there are no major objections to the\n> >>>>> code that\'s already merged, then #2 might be excessive but we\'d still\n> >>>>> need docs changes.\n> >>>>>\n> >>>>> I\'ve already put this on the nova meeting agenda for tomorrow.\n> >>>>>\n> >>>>> [1] https://bugs.launchpad.net/ceilometer/+bug/1328694\n> >>>>> [2] https://bugs.launchpad.net/nova/+bug/1262124\n> >>>>> [3] https://review.openstack.org/#/c/81429/\n> >>>>> [4] https://review.openstack.org/#/c/83660/\n> >>>>> [5] https://review.openstack.org/#/c/83676/\n> >>>>>\n> >>>>> --\n> >>>>>\n> >>>>> Thanks,\n> >>>>>\n> >>>>> Matt Riedemann\n> >>>>>\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>\n> >>> While there is precedent for --all-tenants with some of the other APIs,\n> >>> I\'m concerned about where this stops.  When ceilometer wants polling on\n> >>> some\n> >>> other resources that the nova API exposes, will it need the same thing?\n> >>> Doing all of this polling for resources in all tenants in nova puts an\n> >>> undue\n> >>> burden on the nova API and the database.\n> >>>\n> >>> Can we do something with notifications here instead?  That\'s where the\n> >>> nova-spec process would have probably caught this.\n> >>\n> >> ++ to notifications and not polling.\n> >\n> > Yeah, I think we need to revert this, and go through the specs\n> > process. Its been released in Juno-1 now, so this revert feels bad,\n> > but perhaps its the best of a bad situation?\n> >\n> > Word of caution, we need to get notifications versioned correctly if\n> > we want this as a more formal external \"API\". I think Heat have\n> > similar issues in this area, efficiently knowing about something\n> > happening in Nova. So we do need to \"solve this\".\n> >\n> > Some kind of callback to ceilometer\'s REST API sounds attractive, but\n> > messes up dependencies. Maybe implemented as a plugin to a Nova\n> > \"notification system\", could work better somehow? A versioned\n> > interface that issues \"server life cycle\" events (some versioned\n> > subset of notifications), and allow services to implement their own\n> > plugins to that interface. But maybe we should probably just version\n> > the current notifications, rather than re-invent another interface.\n> >\n> > Thanks,\n> > John\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> The revert patch is here:\n> \n> https://review.openstack.org/#/c/99938/\n\nAs stated on gerrit ...\n\nI would disagree with jumping to revert this API flag, for the following reasons:\n\n1. the underlying bug has a fix under review:\n   https://review.openstack.org/83667\n\n2. reverting has the effect of retroactively applying the policy introduced in:\n   http://lists.openstack.org/pipermail/openstack-dev/2014-June/037536.html\n\n3. there are existing all_tenants flags on other nova APIs\n\n4. surely the core problem here is the *rate* at which this API was called by\n   ceilometer in the gate, and the statndard way to protect a service in that\n   case is to use rate-limiting, as opposed to just removing the API?\n\nThanks,\nEoghan\n\n\n','<539AFD84.2040209@linux.vnet.ibm.com>',NULL),('<1014934844.2812700.1371539572696.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-18 03:12:52',-14400,'2013-06-18 07:12:52',NULL,'[openstack-qa] I need some information about the lab things','Hi Jaroslav,\n\n1. When will the memory arrive ? Did you get new promise ?\n\n2. Do we have an official statement about the available \"rack space\" ?\n\n3. The swich where the R200 machines connected has a (at least one) 10G free port ?\n\n4. Can you tell me tenant/private switch type number max. vlan/multicast and mac support ?\n\nBest Regards,\nAttila\n\n\n','<1172423107.2810597.1371539267175.JavaMail.root@redhat.com>',NULL),('<1015544702.3403058.1420577816260.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-06 21:56:56',3600,'2015-01-06 20:56:56',NULL,'[openstack-dev] [nova]nova not work with eventlet 0.16.0','Hi,\n\n> I set up nova environment with latest upstream code.\n> nova-compute can not boot up due to failed to load libvirt driver.\n> by further debugging. found that eventlet (0.16.0) remove util which is\n> referenced by libvirt driver.\n> after I downgrade to (0.15.2) it works.\n\nCan you please try my following change?\nhttps://review.openstack.org/#/c/145335/\n\nIt changes the libvirt driver to stop using the deprecated (and now removed) eventlet.util module.\n\nVictor\n\n\n','<54ABA873.7020509@linux.vnet.ibm.com>',NULL),('<1015688582.755958.1414420287053.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 10:31:27',-14400,'2014-10-27 14:31:27',NULL,'[openstack-dev] [Glance][Artifacts] Glance Artifacts Repository\n as	a standalone service','Just my two cents, since I won\'t be able to make it to summit:\n\nWhen the artifact repository was proposed, I personally really liked the idea that images\nwere just another artifact type eventually, even if they stayed separate for the time being.\n\nHowever, the pros that you bring up do seem to make a lot of sense -- being able to design an\nAPI \"from scratch\" can lead to nicer APIs, and having the ability to use different backends\nfor images vs artifacts could be quite useful from a performance perspective.\n\nThus, let me propose this: what if you allowed different \"pools\" of artifacts to be housed on\ndifferent backends and/or endpoints?  This way, you could still put images in their own little bubble\nwithout losing the image --> artifact abstraction.  It would also allow you to extend some of the \"pros\"\nof the split to other artifact types, since a cloud admin could have other artifacts besides images that\nneeded to be in their own little bubble for performance reasons.\n\nFor instance, a cloud administrator could define three \"pools\" (for lack of a better term ATM): \"images\", \"general\", and \"critical-data\", \"images\" and \"critical-data\" might be stored on specially-tuned high-performance backends, while \"critical-data\" might be on a large general-purpose backend.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Alexander Tivelkov\" <ativelkov at mirantis.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, October 27, 2014 8:08:47 AM\n> Subject: [openstack-dev] [Glance][Artifacts] Glance Artifacts Repository as	a standalone service\n> \n> Hi stackers,\n> \n> It has been some time since the announcement of Artifacts initiative\n> within the Glance. The feature was not complete in Juno, but is being\n> actively developed now and has good chances for landing in Kilo.\n> However, recently on the Glance Virtual Mini-summit we had a\n> discussions which lead to an idea to change one of the core design\n> concepts of the Glance Artifact repository [1]\n> \n> Initially we planned to run Artifact repository as part of existing\n> Glance service(s): all the APIs to handle artifacts were supposed to\n> be hosted by glance-api service, with glance-registry as optional\n> backend. Artifact-related endpoints were designed to be in the /v2/\n> branch of the API hierarchy, and were supposed to be similar in syntax\n> and semantics to the existing v2/images endpoints.\n> \n> Now it is suggested to host artifacts as a standalone process\n> listening to a different port (and probably deployed on a different\n> host) and registered in the keystone as a separate service type.\n> The code will be still part of the primary Glance repo - so this is\n> not the question of starting another project or program, this is just\n> about having a new daemon in the openstack deployment.\n> \n> This approach has some obvious pros and some less-obvious cons.\n> Most important is the ability to load-balance images and artifacts\n> independenly, being sure that any load on artifacts repo does no\n> affect the performance of images - and vice versa. Also, this will\n> allow us to provide different configuration options (including\n> different backing storages) to these different components which will\n> increase the overall flexibility and customizability of the system.\n> We\'ll be able to design the artifacts API \"from scratch\" without the\n> need to comply with the existing semantics and architecture of\n> images-part, reusing only the components which are really needed.\n> \n> At the same time we\'ll loose the transparency between the concepts of\n> \"image\" and \"artifact\": initially we planned to make them very\n> similar, so when we are finally ready to make images just one of the\n> available artifact types, the migration may be trivial. If we now\n> separate them into different services, we draw a strict border and\n> potentially complicate the migration.\n> \n> IMHO, the pros outweigh the cons, so I personally like the idea of\n> service separation - and all the participants of our virtual summit\n> seemed to share the same opinion. However, it is a serious design\n> change, so I\'d like to hear the opinions of the wider audience.\n> \n> We have planned a design session in Paris  ([2]) to discuss this\n> change in more details (the topic is applicable not only to Artifacta,\n> but to other initiatives under the hood of Glance as well, e.g.\n> metadef catalog, index service etc) - please feel free to join and\n> discuss. And please do not hesitate to share any concerns in the\n> mailing list before the summit starts: the more opinions we have, the\n> better solution we will make.\n> \n> \n> \n> [1]\n> https://etherpad.openstack.org/p/kilo-glance-artifacts-current-state-of-development\n> [2] https://etherpad.openstack.org/p/kilo-glance-summit-topics-final\n> \n> --\n> Regards,\n> Alexander Tivelkov\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAM6FM9Rb8JEJN9h7SKMoke5MQW6afFPhZnAewUErOAL8mwOYQQ@mail.gmail.com>',NULL),('<1015963914.57.1383458521650.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:02:01',0,'2013-11-03 06:02:01',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-heat-python26-stable-grizzly #45','See <https://jenkins02.openstack.org/job/periodic-heat-python26-stable-grizzly/45/>\n\n\n\n','<1868616926.34.1383372119652.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1016060275.20.1378112417145.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-02 09:00:16',0,'2013-09-02 09:00:16',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #13','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/13/>\n\n------------------------------------------\n[...truncated 17254 lines...]\n2013-09-02 06:06:26 # The above administrative user\'s password\n2013-09-02 06:06:26 password =secret\n2013-09-02 06:06:26 # The above administrative user\'s tenant name\n2013-09-02 06:06:26 tenant_name =\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [image]\n2013-09-02 06:06:26 # This section contains configuration options used when executing tests\n2013-09-02 06:06:26 # against the OpenStack Images API\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The type of endpoint for an Image API service. Unless you have a\n2013-09-02 06:06:26 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-02 06:06:26 # this value as \"image\"\n2013-09-02 06:06:26 catalog_type = image\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The version of the OpenStack Images API to use\n2013-09-02 06:06:26 api_version = 1\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # HTTP image to use for glance http image testing\n2013-09-02 06:06:26 http_image = http://127.0.0.1/\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [network]\n2013-09-02 06:06:26 # This section contains configuration options used when executing tests\n2013-09-02 06:06:26 # against the OpenStack Network API.\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Version of the Neutron API\n2013-09-02 06:06:26 api_version = 2.0\n2013-09-02 06:06:26 # Catalog type of the Neutron Service\n2013-09-02 06:06:26 catalog_type = network\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # A large private cidr block from which to allocate smaller blocks for\n2013-09-02 06:06:26 # tenant networks.\n2013-09-02 06:06:26 tenant_network_cidr = 10.100.0.0/16\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The mask bits used to partition the tenant block.\n2013-09-02 06:06:26 tenant_network_mask_bits = 28\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # If tenant networks are reachable, connectivity checks will be\n2013-09-02 06:06:26 # performed directly against addresses on those networks.\n2013-09-02 06:06:26 tenant_networks_reachable = false\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Id of the public network that provides external connectivity.\n2013-09-02 06:06:26 public_network_id = \n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Id of a shared public router that provides external connectivity.\n2013-09-02 06:06:26 # A shared public router would commonly be used where IP namespaces\n2013-09-02 06:06:26 # were disabled.  If namespaces are enabled, it would be preferable\n2013-09-02 06:06:26 # for each tenant to have their own router.\n2013-09-02 06:06:26 public_router_id = \n2013-09-02 06:06:26 \n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [volume]\n2013-09-02 06:06:26 # This section contains the configuration options used when executing tests\n2013-09-02 06:06:26 # against the OpenStack Block Storage API service\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-02 06:06:26 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-02 06:06:26 # probably want to leave this value as \"volume\"\n2013-09-02 06:06:26 catalog_type = volume\n2013-09-02 06:06:26 # Number of seconds to wait while looping to check the status of a\n2013-09-02 06:06:26 # volume that is being made available\n2013-09-02 06:06:26 build_interval = 1\n2013-09-02 06:06:26 # Number of seconds to time out on waiting for a volume\n2013-09-02 06:06:26 # to be available or reach an expected status\n2013-09-02 06:06:26 build_timeout = 400\n2013-09-02 06:06:26 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-02 06:06:26 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-02 06:06:26 # have to be different)\n2013-09-02 06:06:26 multi_backend_enabled = false\n2013-09-02 06:06:26 backend1_name = BACKEND_1\n2013-09-02 06:06:26 backend2_name = BACKEND_2\n2013-09-02 06:06:26 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-02 06:06:26 # You should update to reflect those exported by configured backend driver.\n2013-09-02 06:06:26 storage_protocol = iSCSI\n2013-09-02 06:06:26 vendor_name = Open Source\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [object-storage]\n2013-09-02 06:06:26 # This section contains configuration options used when executing tests\n2013-09-02 06:06:26 # against the OpenStack Object Storage API.\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # You can configure the credentials in the compute section\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-02 06:06:26 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-02 06:06:26 # this value as \"object-store\"\n2013-09-02 06:06:26 catalog_type = object-store\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Number of seconds to time on waiting for a container to container\n2013-09-02 06:06:26 # synchronization complete\n2013-09-02 06:06:26 container_sync_timeout = 120\n2013-09-02 06:06:26 # Number of seconds to wait while looping to check the status of a\n2013-09-02 06:06:26 # container to container synchronization\n2013-09-02 06:06:26 container_sync_interval = 5\n2013-09-02 06:06:26 # Set to True if the Account Quota middleware is enabled\n2013-09-02 06:06:26 accounts_quotas_available = True\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Set operator role for tests that require creating a container\n2013-09-02 06:06:26 operator_role = Member\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [boto]\n2013-09-02 06:06:26 ssh_user = cirros\n2013-09-02 06:06:26 # This section contains configuration options used when executing tests\n2013-09-02 06:06:26 # with boto.\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # EC2 URL\n2013-09-02 06:06:26 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-02 06:06:26 # S3 URL\n2013-09-02 06:06:26 s3_url = http://127.0.0.1:3333\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-02 06:06:26 aws_access =\n2013-09-02 06:06:26 aws_secret =\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Image materials for S3 upload\n2013-09-02 06:06:26 # ALL content of the specified directory will be uploaded to S3\n2013-09-02 06:06:26 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-02 06:06:26 # Subdirectories not allowed!\n2013-09-02 06:06:26 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-02 06:06:26 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-02 06:06:26 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-02 06:06:26 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Instance type\n2013-09-02 06:06:26 instance_type = m1.nano\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # TCP/IP connection timeout\n2013-09-02 06:06:26 http_socket_timeout = 30\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Number of retries actions on connection or 5xx error\n2013-09-02 06:06:26 num_retries = 1\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Status change wait timout\n2013-09-02 06:06:26 build_timeout = 400\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Status change wait interval\n2013-09-02 06:06:26 build_interval = 1\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [orchestration]\n2013-09-02 06:06:26 # Status change wait interval\n2013-09-02 06:06:26 build_interval = 1\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Status change wait timout. This may vary across environments as some some\n2013-09-02 06:06:26 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-02 06:06:26 build_timeout = 300\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Instance type for tests. Needs to be big enough for a\n2013-09-02 06:06:26 # full OS plus the test workload\n2013-09-02 06:06:26 instance_type = m1.micro\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-02 06:06:26 # If not specified, tests that spawn instances will not run\n2013-09-02 06:06:26 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-02 06:06:26 # any key, which will generate a keypair for each test class\n2013-09-02 06:06:26 #keypair_name = heat_key\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [dashboard]\n2013-09-02 06:06:26 # URL where to find the dashboard home page\n2013-09-02 06:06:26 dashboard_url = http://127.0.0.1/\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # URL where to submit the login form\n2013-09-02 06:06:26 login_url = http://127.0.0.1/auth/login/\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [scenario]\n2013-09-02 06:06:26 # Directory containing image files\n2013-09-02 06:06:26 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # AMI image file name\n2013-09-02 06:06:26 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # ARI image file name\n2013-09-02 06:06:26 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # AKI image file name\n2013-09-02 06:06:26 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # ssh username for the image file\n2013-09-02 06:06:26 ssh_user = cirros\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 # specifies how many resources to request at once. Used for large operations\n2013-09-02 06:06:26 # testing.\"\n2013-09-02 06:06:26 large_ops_number = 0\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [cli]\n2013-09-02 06:06:26 # Enable cli tests\n2013-09-02 06:06:26 enabled = True\n2013-09-02 06:06:26 # directory where python client binaries are located\n2013-09-02 06:06:26 cli_dir = /usr/local/bin\n2013-09-02 06:06:26 # Number of seconds to wait on a CLI timeout\n2013-09-02 06:06:26 timeout = 15\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [service_available]\n2013-09-02 06:06:26 # Whether or not cinder is expected to be available\n2013-09-02 06:06:26 cinder = True\n2013-09-02 06:06:26 # Whether or not neutron is expected to be available\n2013-09-02 06:06:26 neutron = False\n2013-09-02 06:06:26 # Whether or not glance is expected to be available\n2013-09-02 06:06:26 glance = True\n2013-09-02 06:06:26 # Whether or not swift is expected to be available\n2013-09-02 06:06:26 swift = True\n2013-09-02 06:06:26 # Whether or not nova is expected to be available\n2013-09-02 06:06:26 nova = True\n2013-09-02 06:06:26 # Whether or not Heat is expected to be available\n2013-09-02 06:06:26 heat = True\n2013-09-02 06:06:26 # Whether or not horizon is expected to be available\n2013-09-02 06:06:26 horizon = True\n2013-09-02 06:06:26 \n2013-09-02 06:06:26 [stress]\n2013-09-02 06:06:26 # Maximum number of instances to create during test\n2013-09-02 06:06:26 max_instances = 32\n2013-09-02 06:06:26 # Time (in seconds) between log file error checks\n2013-09-02 06:06:26 log_check_interval = 60\n2013-09-02 06:06:26 # The default number of threads created while stress test\n2013-09-02 06:06:26 default_thread_number_per_action=4\n2013-09-02 06:06:26 ++ IFS=\' 	\n2013-09-02 06:06:26 \'\n2013-09-02 06:06:26 ++ set +o errexit\n2013-09-02 06:06:26 ++ init_tempest\n2013-09-02 06:06:26 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-02 06:06:26 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-02 06:06:26 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-02 06:06:26 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-02 06:06:26 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1660.ga87b64d.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n./safe-devstack-vm-gate-wrap.sh: line 444:  2694 Terminated              $GATE_SCRIPT_DIR/devstack-vm-gate.sh\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167/13\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167/13/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167/13/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167/13/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-200167/13/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1200097925.16.1378015619350.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1016979670.6729722.1390075497397.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-18 15:04:57',-18000,'2014-01-18 20:04:57',NULL,'[Openstack-docs] Automated CLI Reference','----- Original Message -----\n> From: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>\n> To: \"Anne Gentle\" <anne at openstack.org>, openstack-docs at lists.openstack.org\n> Sent: Friday, January 17, 2014 5:10:59 PM\n> Subject: Re: [Openstack-docs] Automated CLI Reference\n> \n> I think I\'m the owner, but I haven\'t done any work with it yet.\n> \n> There is mention of it in this blueprint:\n> https://wiki.openstack.org/wiki/Blueprint-os-user-docs#APPENDIX_A._OpenStack_Command_Reference_2\n> \n> If someone else wants to work on it, let me know!\n> \n> \n> Diane\n\nMy memory is a bit vague but I think at the relevant session in Hong Kong we discussed concentrating any such effort on the unified OpenStack CLI project that\'s currently development - someone (my recollection is it was Monty) suggested that we might also be able to get some changes made as part of that project to simplify this.\n\nIncidentally I noticed we have this bug in the queue:\n\n    https://bugs.launchpad.net/openstack-manuals/+bug/1208038\n\nI think if we were doing the automation *today* it would still make sense to base it on the normal split out commands (nova, cinder, etc.) but if nobody gets to it until some time in the Juno cycle perhaps basing it on the unified CLI will make sense? Just my 2c.\n\nThanks,\n\nSteve\n\n\n','<CEFF05F6.21110%diane.fleming@rackspace.com>',NULL),('<1017034483.4.1377497803071.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-26 06:16:42',0,'2013-08-26 06:16:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #13','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/13/>\n\n------------------------------------------\n[...truncated 3739 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 254.54 secs:\n    93.32    KcEssex3TestCase.test_admin_requires_adminness\n    92.00    KcMasterTestCase.test_admin_requires_adminness\n    54.05    Kc11TestCase.test_admin_requires_adminness\n    7.82    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    7.35    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1300 tests in 779.782s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==2.0.1\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.13\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.XGTo8tFe7S\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/13/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-3/13\n[SCP] Copying console log.\n\n\n','<886305679.6.1377326012050.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1017153213.32222903.1387364725734.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 06:05:25',-18000,'2013-12-18 11:05:25',NULL,'[openstack-dev] [Nova] Support for Pecan in Nova','I attempted this in keystone as part of a very simple extension [1]. I understand that it is a much simpler case but nesting the Pecan within the existing routing infrastructure, rather than have a single Pecan app was fairly simple (though there are some limiting situations).\n\nAny reason you decided to go this way rather than the one in my review? \n\n[1] https://review.openstack.org/#/c/62810/\n\n----- Original Message -----\n> From: \"Ryan Petrello\" <ryan.petrello at dreamhost.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, 18 December, 2013 7:08:09 AM\n> Subject: Re: [openstack-dev] [Nova] Support for Pecan in Nova\n> \n> So any additional feedback on this patch?  I?d love to start working on\n> porting some of the other extensions to pecan, but want to make sure I?ve\n> got approval on this approach first.\n> \n> https://review.openstack.org/#/c/61303/7\n> \n> ---\n> Ryan Petrello\n> Senior Developer, DreamHost\n> ryan.petrello at dreamhost.com\n> \n> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <doug.hellmann at dreamhost.com>\n> wrote:\n> \n> > \n> > \n> > \n> > On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbkyeoh at gmail.com>\n> > wrote:\n> > \n> > On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann\n> > <doug.hellmann at dreamhost.com> wrote:\n> > That covers routes. What about the properties of the inputs and outputs?\n> > \n> > \n> > I think the best way for me to describe it is that as the V3 API core and\n> > all the extensions\n> > are written, both the routes and input and output parameters are from a\n> > client\'s perspective fixed at application\n> > startup time. Its not an inherent restriction of the framework (an\n> > extension could for\n> > example dynamically load another extension at runtime if it really wanted\n> > to), but we just don\'t do that.\n> > \n> > OK, good.\n> > \n> >  \n> > \n> > Note that values of parameters returned can be changed by an extension\n> > though. For example os-hide-server-addresses\n> > can based on a runtime policy check and the vm_state of the server, filter\n> > whether the values in the\n> > addresses field are filtered out or not when returning information about a\n> > server. This isn\'t a new thing in the\n> > V3 API though, it already existed in the V2 API.\n> > \n> > OK, it seems like as long as the fields are still present that makes the\n> > API at least consistent for a given deployment\'s configuration.\n> > \n> > Doug\n> > \n> >  \n> > \n> > Chris\n> >  \n> > \n> > On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello\n> > <ryan.petrello at dreamhost.com> wrote:\n> > Unless there?s some other trickiness going on that I?m unaware of, the\n> > routes for the WSGI app are defined at application startup time (by\n> > methods called in the WSGI app?s __init__).\n> > \n> > ---\n> > Ryan Petrello\n> > Senior Developer, DreamHost\n> > ryan.petrello at dreamhost.com\n> > \n> > On Dec 13, 2013, at 12:56 PM, Doug Hellmann <doug.hellmann at dreamhost.com>\n> > wrote:\n> > \n> > >\n> > >\n> > >\n> > > On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <cbkyeoh at gmail.com>\n> > > wrote:\n> > > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > > On 12/11/2013 11:47 PM, Mike Perez wrote:\n> > > On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:\n> > > On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann\n> > > <doug.hellmann at dreamhost.com\n> > > <mailto:doug.hellmann at dreamhost.com>>wrote:\n> > >\n> > >\n> > >\n> > >\n> > > On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <\n> > > ryan.petrello at dreamhost.com\n> > > <mailto:ryan.petrello at dreamhost.com>>\n> > > wrote:\n> > >\n> > > Hello,\n> > >\n> > > I?ve spent the past week experimenting with using Pecan for\n> > > Nova?s\n> > > API\n> > > and have opened an experimental review:\n> > >\n> > >\n> > > https://review.openstack.org/#/c/61303/6\n> > >\n> > > ?which implements the `versions` v3 endpoint using pecan (and\n> > > paves the\n> > > way for other extensions to use pecan).  This is a *potential*\n> > >\n> > > approach\n> > > I\'ve considered for gradually moving the V3 API, but I?m open\n> > > to other suggestions (and feedback on this approach).  I?ve\n> > > also got a few open questions/general observations:\n> > >\n> > > 1.  It looks like the Nova v3 API is composed *entirely* of\n> > > extensions (including ?core? API calls), and that extensions\n> > > and their routes are discoverable and extensible via installed\n> > > software that registers\n> > > itself\n> > > via stevedore.  This seems to lead to an API that?s composed of\n> > >\n> > > installed\n> > > software, which in my opinion, makes it fairly hard to map out\n> > > the\n> > > API (as\n> > > opposed to how routes are manually defined in other WSGI\n> > > frameworks).  I\n> > > assume at this time, this design decision has already been\n> > > solidified for\n> > > v3?\n> > >\n> > >\n> > > Yeah, I brought this up at the summit. I am still having some\n> > > trouble understanding how we are going to express a stable core\n> > > API for compatibility testing if the behavior of the API can be\n> > > varied so significantly by deployment decisions. Will we just\n> > > list each\n> > > \"required\"\n> > > extension, and forbid any extras for a compliant cloud?\n> > >\n> > >\n> > > Maybe the issue is caused by me misunderstanding the term\n> > > \"extension,\" which (to me) implies an optional component but is\n> > > perhaps reflecting a technical implementation detail instead?\n> > >\n> > >\n> > > Yes and no :-) As Ryan mentions, all API code is a plugin in the V3\n> > > API. However, some must be loaded or the V3 API refuses to start\n> > > up. In nova/api/openstack/__init__.py we have\n> > > API_V3_CORE_EXTENSIONS which hard codes which extensions must be\n> > > loaded and there is no config option to override this (blacklisting\n> > > a core plugin will result in the V3 API not starting up).\n> > >\n> > > So for compatibility testing I think what will probably happen is\n> > > that we\'ll be defining a minimum set (API_V3_CORE_EXTENSIONS) that\n> > > must be implemented and clients can rely on that always being\n> > > present\n> > > on a compliant cloud. But clients can also then query through\n> > > /extensions what other functionality (which is backwards compatible\n> > > with respect to core) may also be present on that specific cloud.\n> > >\n> > > This really seems similar to the idea of having a router class, some\n> > > controllers and you map them. From my observation at the summit,\n> > > calling everything an extension creates confusion. An extension\n> > > \"extends\" something. For example, Chrome has extensions, and they\n> > > extend the idea of the core features of a browser. If you want to do\n> > > more than back/forward, go to an address, stop, etc, that\'s an\n> > > extension. If you want it to play an audio clip \"stop, hammer time\"\n> > > after clicking the stop button, that\'s an example of an extension.\n> > >\n> > > In OpenStack, we use extensions to extend core. Core are the\n> > > essential feature(s) of the project. In Cinder for example, core is\n> > > volume. In core you can create a volume, delete a volume, attach a\n> > > volume, detach a volume, etc. If you want to go beyond that, that\'s\n> > > an extension. If you want to do volume encryption, that\'s an example\n> > > of an extension.\n> > >\n> > > I\'m worried by the discrepancies this will create among the programs.\n> > > You mentioned maintainability being a plus for this. I don\'t think\n> > > it\'ll be great from the deployers perspective when you have one\n> > > program that thinks everything is an extension and some of them have\n> > > to be enabled that the deployer has to be mindful of, while the rest\n> > > of the programs consider all extensions to be optional.\n> > >\n> > > +1. I agree with most of what Mike says above. The idea that there are\n> > > core \"extensions\" in Nova\'s v3 API doesn\'t make a whole lot of sense to\n> > > me.\n> > >\n> > >\n> > > So would it help if we used the term \"plugin\" to talk about the framework\n> > > that the API is implemented with,\n> > > and extensions when talking about things which extend the core API? So\n> > > the whole of the API is implemented\n> > > using plugins, while the core plugins are not considered to be\n> > > extensions.\n> > >\n> > > That distinction does help.\n> > >\n> > > Are the extensions enabled at startup time, or at runtime when an API\n> > > call is made? That is, could 2 different users of the same cloud service\n> > > instance see different fields in the value returned from the call\n> > > because of some runtime decision made inside either an extension (where\n> > > the extension might not add fields for some reason) or a bit of core\n> > > code (by deciding not to call an extension at all)?\n> > >\n> > > Doug\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<2C7AB829-75C5-4064-8CB6-34AEBF12DD55@dreamhost.com>',NULL),('<1017396830.1912020.1348587770885.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 11:42:50',-14400,'2012-09-25 15:42:50',NULL,'[openstack-dev] [nova][cinder] heads-up on a tgtd/iscsiadm issue','\n\nFolks,\n\nOn the Fedora OpenStack testday[1] we ran into problems with tgtd\npicking up iscsi target config files for volumes.\n\nSince these commits[2],[3] the --conf option is used explicitly\nwith \'tgt-admin update\', with the result that it appears there is\nno problem with the target config being picked up by tgtd from \n/etc/cinder/volumes.\n\nHowever, if tgtd is then restarted, we see subsequent attempts to use\n(e.g. attach) pre-existing volumes fail with iscsiadm login timeouts.\n\nThe issue can be worked around by adding the line:\n\n  include /etc/cinder/volumes/*\n\nto the tgt targets config file (/etc/tgt/targets.conf).\n\nIt would be preferable[4] if this failed fast from the get-go, as\nopposed to only blowing up on tgtd restart.\n\nCheers,\nEoghan \n\n[1] https://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack\n[2] https://github.com/openstack/nova/commit/0a09bf5f\n[3] https://github.com/openstack/cinder/commit/09036039\n[4] https://bugs.launchpad.net/cinder/+bug/1056246\n\n\n','<1126675099.1907837.1348587127468.JavaMail.root@redhat.com>',NULL),('<1017631426.136.1358148453004.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-14 07:27:32',0,'2013-01-14 07:27:32',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #67','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/67/>\n\n------------------------------------------\n[...truncated 15970 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 14 Jan 2013 07:23:33 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-393ca050-ad6a-4006-be20-ad3efb12468c\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNFQwNzoyMzoxMS44NDAyNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE1VDA3OjIzOjExWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImFmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAiaWQiOiAiZTM3NGM2NGM5OTJiNDE1Yjk4NjdiZmNiMTE2NzMyZWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZDlmYjM1YTI4Y2M0MDEyYmI2NmMxNjkxYzA2ZDY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGZlMzRjM2E2OGRhNDQ0Mjk0ZTQ1ODkxMDk5N2EwZjgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJpZCI6ICI3NTRiYmZmOGQ0ODM0YTRhYWMyN2JlODk3ZDMwZDIzZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI4MjY3NmM4MWUzNGY0NTFkYTEyZmZjMTZiODU1NDExMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIiwgImlkIjogImQ5NGZlZjU3NGI1NzRmOWNhZjQzODVmOTM4MDA4MDk4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImMyYWJkZDg3ZDUwYjRhNzQ5MTRhNWRmNjNhZWI3MDVhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZkZjIwNWEzMGFkNGNiODk3NWI5NzU1NTNmNmEzYjgiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTYyMGIxN2E4NzA1NDYzY2I3YmNiZWY1MTY4ZTY3MmMiLCAiYTY4NWUxMTQ2ZjE1NGQ0N2E5NDk1NmJjZTI0NTkxNTQiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYDBatCFkS9YatTPGGkT53KshAfb+MQXSiI5G+pYBd57jVzSb8C2FwfT68miqRXs1shkRLOnbzXVF+bCM84F3RMV-tJjPvNOcZ4xuRNWu+y5dgfO0HytG17Bgxbtw87B0fYs8iZnVqdcAtH8fJV37MCO7r862hmrxNLcA3b5-m0Hmg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/983f24b8-456a-447d-9406-3ea3f7f07dae\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 14 Jan 2013 07:23:34 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-61d51119-f457-4318-86e3-44e2804ca1da\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNFQwNzoyMzoxMS44NDAyNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE1VDA3OjIzOjExWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImFmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAiaWQiOiAiZTM3NGM2NGM5OTJiNDE1Yjk4NjdiZmNiMTE2NzMyZWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZDlmYjM1YTI4Y2M0MDEyYmI2NmMxNjkxYzA2ZDY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGZlMzRjM2E2OGRhNDQ0Mjk0ZTQ1ODkxMDk5N2EwZjgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJpZCI6ICI3NTRiYmZmOGQ0ODM0YTRhYWMyN2JlODk3ZDMwZDIzZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI4MjY3NmM4MWUzNGY0NTFkYTEyZmZjMTZiODU1NDExMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIiwgImlkIjogImQ5NGZlZjU3NGI1NzRmOWNhZjQzODVmOTM4MDA4MDk4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImMyYWJkZDg3ZDUwYjRhNzQ5MTRhNWRmNjNhZWI3MDVhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZkZjIwNWEzMGFkNGNiODk3NWI5NzU1NTNmNmEzYjgiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTYyMGIxN2E4NzA1NDYzY2I3YmNiZWY1MTY4ZTY3MmMiLCAiYTY4NWUxMTQ2ZjE1NGQ0N2E5NDk1NmJjZTI0NTkxNTQiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYDBatCFkS9YatTPGGkT53KshAfb+MQXSiI5G+pYBd57jVzSb8C2FwfT68miqRXs1shkRLOnbzXVF+bCM84F3RMV-tJjPvNOcZ4xuRNWu+y5dgfO0HytG17Bgxbtw87B0fYs8iZnVqdcAtH8fJV37MCO7r862hmrxNLcA3b5-m0Hmg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f9144270-bf4b-4ffc-820c-be6f71e8bf33\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 14 Jan 2013 07:23:35 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-bc422f63-503d-4790-bc97-33d3245d6829\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNFQwNzoyMzoxMS44NDAyNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE1VDA3OjIzOjExWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImFmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYWZiZGE0YmM2MDk5NGFjM2EwM2RmNzU4YzMxMzU2M2QiLCAiaWQiOiAiZTM3NGM2NGM5OTJiNDE1Yjk4NjdiZmNiMTE2NzMyZWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZDlmYjM1YTI4Y2M0MDEyYmI2NmMxNjkxYzA2ZDY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGZlMzRjM2E2OGRhNDQ0Mjk0ZTQ1ODkxMDk5N2EwZjgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCIsICJpZCI6ICI3NTRiYmZmOGQ0ODM0YTRhYWMyN2JlODk3ZDMwZDIzZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI4MjY3NmM4MWUzNGY0NTFkYTEyZmZjMTZiODU1NDExMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2FmYmRhNGJjNjA5OTRhYzNhMDNkZjc1OGMzMTM1NjNkIiwgImlkIjogImQ5NGZlZjU3NGI1NzRmOWNhZjQzODVmOTM4MDA4MDk4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hZmJkYTRiYzYwOTk0YWMzYTAzZGY3NThjMzEzNTYzZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImMyYWJkZDg3ZDUwYjRhNzQ5MTRhNWRmNjNhZWI3MDVhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZkZjIwNWEzMGFkNGNiODk3NWI5NzU1NTNmNmEzYjgiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTYyMGIxN2E4NzA1NDYzY2I3YmNiZWY1MTY4ZTY3MmMiLCAiYTY4NWUxMTQ2ZjE1NGQ0N2E5NDk1NmJjZTI0NTkxNTQiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYDBatCFkS9YatTPGGkT53KshAfb+MQXSiI5G+pYBd57jVzSb8C2FwfT68miqRXs1shkRLOnbzXVF+bCM84F3RMV-tJjPvNOcZ4xuRNWu+y5dgfO0HytG17Bgxbtw87B0fYs8iZnVqdcAtH8fJV37MCO7r862hmrxNLcA3b5-m0Hmg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/861e41c6-02a3-421b-88e4-2c9ea5e7c423\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 14 Jan 2013 07:23:36 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-4108a2fe-5cf7-471b-af93-efbd4456a405\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n======================================================================\nFAIL: test_create_image_specify_uuid_35_characters_or_less (tempest.tests.compute.images.test_images.ImagesTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 136, in test_create_image_specify_uuid_35_characters_or_less\n    self.fail(\"Should return 404 Not Found if server uuid is 35\"\nAssertionError: Should return 404 Not Found if server uuid is 35 characters or less\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 35 characters or less\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d25127942a2a49f2ac292fdc196ed447/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: {\"createImage\": {\"name\": \"test-snap-102503\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 14 Jan 2013 06:36:42 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-5995ce16-78bc-4092-be37-993b52721730\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_37_characters_or_more (tempest.tests.compute.images.test_images.ImagesTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 148, in test_create_image_specify_uuid_37_characters_or_more\n    self.fail(\"Should return 404 Not Found if server uuid is 37\"\nAssertionError: Should return 404 Not Found if server uuid is 37 characters or more\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 37 characters or more\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d25127942a2a49f2ac292fdc196ed447/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: {\"createImage\": {\"name\": \"test-snap-242804\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 14 Jan 2013 06:36:42 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-dcb02562-ca20-40a5-9145-7c602d2cb187\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_35_characters_or_less (tempest.tests.compute.images.test_images.ImagesTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 136, in test_create_image_specify_uuid_35_characters_or_less\n    self.fail(\"Should return 404 Not Found if server uuid is 35\"\nAssertionError: Should return 404 Not Found if server uuid is 35 characters or less\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 35 characters or less\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/b6ae78e5c1774db09de26111abe0a73c/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<createImage name=\"test-snap-121391\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 14 Jan 2013 06:38:13 GMT\', \'status\': \'500\', \'content-length\': \'192\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-5254265c-0a62-45b3-b1b7-00ccb6b4ba68\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'The server has either erred or is incapable of performing the requested operation.\', \'code\': \'500\'}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_37_characters_or_more (tempest.tests.compute.images.test_images.ImagesTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 148, in test_create_image_specify_uuid_37_characters_or_more\n    self.fail(\"Should return 404 Not Found if server uuid is 37\"\nAssertionError: Should return 404 Not Found if server uuid is 37 characters or more\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 37 characters or more\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/b6ae78e5c1774db09de26111abe0a73c/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<createImage name=\"test-snap-363886\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 14 Jan 2013 06:38:13 GMT\', \'status\': \'500\', \'content-length\': \'192\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-6c5b9562-6fc8-49bf-9adc-5c7f2b75659a\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'The server has either erred or is incapable of performing the requested operation.\', \'code\': \'500\'}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 641 tests in 3376.199s\n\nFAILED (SKIP=82, failures=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/rabbitmq/rabbit at devstack-1358132486-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/rabbitmq/rabbit at devstack-1358132486.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/67/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1213620845.116.1358057727039.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1017881424.19709080.1413391912093.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 12:51:52',-14400,'2014-10-15 16:51:52',NULL,'[openstack-dev] [api] API recommendation','\n\n----- Original Message -----\n> Thoughts?\n\n\nI like this idea. From my experience with the Sahara project I think there is definite opportunity for this mechanic especially with regards to cluster creation and job executions.\n\nregards,\nmike\n\n\n','<1413388156.4059.5.camel@einstein.kev>',NULL),('<101839964.342932.1398979032532.JavaMail.root@mail>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 17:17:12',-14400,'2014-05-01 21:17:12',NULL,'[openstack-dev] Monitoring as a Service','Hello Everyone!\n\nMy name is Alexandre Viau from Savoir-Faire Linux.\n\nWe have submited a Monitoring as a Service blueprint and need feedback.\n\nProblem to solve: Ceilometer\'s purpose is to track and *measure/meter* usage information collected from OpenStack components (originally for billing). While Ceilometer is usefull for the cloud operators and infrastructure metering, it is not a *monitoring* solution for the tenants and their services/applications running in the cloud because it does not allow for service/application-level monitoring and it ignores detailed and precise guest system metrics.\n\nProposed solution: We would like to add Monitoring as a Service to Openstack\n\nJust like Rackspace\'s Cloud monitoring, the new monitoring service - lets call it OpenStackMonitor for now -  would let users/tenants keep track of their ressources on the cloud and receive instant notifications when they require attention.\n\nThis RESTful API would enable users to create multiple monitors with predefined checks, such as PING, CPU usage, HTTPS and SMTP or custom checks performed by a Monitoring Agent on the instance they want to monitor.\n\nPredefined checks such as CPU and disk usage could be polled from Ceilometer. Other predefined checks would be performed by the new monitoring service itself. Checks such as PING could be flagged to be performed from multiple sites.\n\nCustom checks would be performed by an optional Monitoring Agent. Their results would be polled by the monitoring service and stored in Ceilometer.\n\nIf you wish to collaborate, feel free to contact me at alexandre.viau at savoirfairelinux.com\nThe blueprint is available here: https://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-service\n\nThanks!\n\n\n','<1429247357.327710.1398978038682.JavaMail.root@mail>',NULL),('<101910613.397.1367042881386.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:08:01',0,'2013-04-27 06:08:01',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/>\nCheckout:periodic-horizon-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/> - hudson.remoting.Channel at 1792f987:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nChecking out Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\n[periodic-horizon-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson349683065220002774.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.myYDwuIjWA\n+ TMPDIR=/tmp/tmp.myYDwuIjWA\n+ trap \'rm -rf /tmp/tmp.myYDwuIjWA\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\n2012.2.5\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python26-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 42745 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182612.410129-2007222732\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric1\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.myYDwuIjWA\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-04-38\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'9815c4aa-d42f-4cf4-85e3-0d8e3ecb4d68\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric1\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 42745 166.78.27.36 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\nNo distributions at all found for Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.myYDwuIjWA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1019402913.9.1367561306547.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-03 06:08:26',0,'2013-05-03 06:08:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #23','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/23/>\n\n------------------------------------------\n[...truncated 5087 lines...]\n2013-05-03 06:08:20    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:20,782 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:20,783 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:20,783 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,784 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,785 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-03 06:08:20,786 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:08:20,787 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:08:20  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:08:20,788 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:20    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:20,789 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,794 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.794807\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.794807\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20,796 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,796 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,797 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,799 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20,800 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.799212\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.799212\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20,801 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,802 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,802 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:20,803 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,804 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,806 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20,807 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.806071\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.806071\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20,808 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,809 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,810 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:20,811 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,812 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,813 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20,814 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.813731\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.813731\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20,815 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,816 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,817 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:20,818 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,819 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,820 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:20,822 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:20,823 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.822100\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:20.822100\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:20,824 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,825 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20,826 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:20,826 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:20,827 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:20    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.985s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.2\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.23\ncliff==1.3.3\ncmd2==0.6.5.1\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a96.gcc938e2\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a491.g8bb1cc2\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.AKSP5CyICZ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/23\n[SCP] Copying console log.\n\n\n','<1983440492.552.1367474863276.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1019563385.36967305.1377010622407.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 07:57:02',-25200,'2013-08-20 14:57:02',NULL,'[openstack-dev] VMwareAPI sub-team status update 2013-08-19','The script is stupid. If my name isn\'t on the list of reviewers, sometimes it fails to catch the patch. I\'ll add myself to these.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Gary Kotton\" <gkotton at vmware.com>\n> To: \"Shawn Hartsock\" <hartsocks at vmware.com>, openstack-dev at lists.openstack.org\n> Sent: Tuesday, August 20, 2013 10:15:11 AM\n> Subject: RE: VMwareAPI sub-team status update 2013-08-19\n> \n> Hi,\n> You have omitted the following which are very critical for our tempest runs:\n> 1. https://review.openstack.org/#/c/39046/ (VMware: fix rescue/unrescue\n> instance)\n> 2. https://review.openstack.org/#/c/41058/ (VMware: Add driver support for\n> hypervisor uptime)\n> 3. [Included below] https://review.openstack.org/#/c/40298/ (Fix snapshot in\n> VMWwareVCDriver)\n> \n> In addition to this we a critical issue with Neutron and Nova which has been\n> in review for a very long time:\n> 1. https://review.openstack.org/#/c/37389/ (VMware: Ensure Neutron networking\n> works with VMware drivers)\n> \n> If it would help the core reviewers we can provide tempest runs for each of\n> the reviews below. I understand that one may find it difficult to review or\n> approve code if she/he cannot run it. So if the tempest results will help\n> then we can provide them.\n> \n> Thanks\n> Gary\n> \n> > -----Original Message-----\n> > From: Shawn Hartsock [mailto:hartsocks at vmware.com]\n> > Sent: Tuesday, August 20, 2013 6:44 AM\n> > To: openstack-dev at lists.openstack.org\n> > Subject: [openstack-dev][nova][vmware] VMwareAPI sub-team status\n> > update 2013-08-19\n> > \n> > \n> > Greetings stackers!\n> > \n> > August 22nd is fast approaching. Here\'s the reviews in flight. We have 5\n> > ready for a core reviewer to take a look. One needing some attention from\n> > someone who knows VMware\'s APIs and 8 that are in need of\n> > work/discussion. I noticed that there was some issues with Jenkins earlier,\n> > some of you may have been caught in that. Don\'t use \'recheck no bug\' until\n> > you\'ve read the failures and made sure it has nothing to do with your\n> > patch.\n> > \n> > Ready for core reviewer:\n> > * NEW, https://review.openstack.org/#/c/37819/ ,\'VMware image clone\n> > strategy settings and overrides\'\n> >     https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-\n> > strategy\n> >     core votes,0, non-core votes,4, down votes, 0\n> > * NEW, https://review.openstack.org/#/c/33100/ ,\'Fixes host stats for\n> > VMWareVCDriver\'\n> >     https://bugs.launchpad.net/nova/+bug/1190515\n> >     core votes,0, non-core votes,5, down votes, 0\n> > * NEW, https://review.openstack.org/#/c/30628/ ,\'Fix VCDriver to pick the\n> > datastore that has capacity\'\n> >     https://bugs.launchpad.net/nova/+bug/1171930\n> >     core votes,0, non-core votes,7, down votes, 0\n> > * NEW, https://review.openstack.org/#/c/33504/ ,\'VMware: nova-compute\n> > crashes if VC not available\'\n> >     https://bugs.launchpad.net/nova/+bug/1192016\n> >     core votes,0, non-core votes,5, down votes, 0\n> > * NEW, https://review.openstack.org/#/c/40298/ ,\'Fix snapshot in\n> > VMWwareVCDriver\'\n> >     https://bugs.launchpad.net/nova/+bug/1184807\n> >     core votes,0, non-core votes,6, down votes, 0\n> > \n> > Needs VMware API expert review:\n> > * NEW, https://review.openstack.org/#/c/42024/ ,\'VMWare: Disabling\n> > linked clone doesn\'t cache images\'\n> >     https://bugs.launchpad.net/nova/+bug/1207064\n> >     core votes,0, non-core votes,0, down votes, 0\n> > \n> > Needs discussion/work (has -1):\n> > * NEW, https://review.openstack.org/#/c/37659/ ,\'Enhance VMware Hyper\n> > instance disk usage\'\n> >     https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-\n> > usage\n> >     core votes,0, non-core votes,2, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/39720/ ,\'VMware: Added check for\n> > datastore state before selection\'\n> >     https://bugs.launchpad.net/nova/+bug/1194078\n> >     core votes,0, non-core votes,4, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/40105/ ,\'VMware: use VM uuid for\n> > volume attach and detach\'\n> >     https://bugs.launchpad.net/nova/+bug/1208173\n> >     core votes,1, non-core votes,7, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/41387/ ,\'VMware: Nova boot from\n> > cinder volume\'\n> >     https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-\n> > support\n> >     core votes,0, non-core votes,2, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/40245/ ,\'Nova support for vmware\n> > cinder driver\'\n> >     https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-\n> > support\n> >     core votes,0, non-core votes,2, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/41657/ ,\'Fix VMwareVCDriver to\n> > support multi-datastore\'\n> >     https://bugs.launchpad.net/nova/+bug/1104994\n> >     core votes,0, non-core votes,0, down votes, -1\n> > * NEW, https://review.openstack.org/#/c/30282/ ,\'Multiple Clusters using\n> > single compute service\'\n> >     https://blueprints.launchpad.net/nova/+spec/multiple-clusters-\n> > managed-by-one-service\n> >     core votes,0, non-core votes,2, down votes, -2\n> > * NEW, https://review.openstack.org/#/c/34903/ ,\'Deploy vCenter\n> > templates\'\n> >     https://blueprints.launchpad.net/nova/+spec/deploy-vcenter-templates-\n> > from-vmware-nova-driver\n> >     core votes,0, non-core votes,2, down votes, -2\n> > \n> > Meeting info:\n> > * https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n> > \n> > \n> > # Shawn Hartsock\n> \n\n\n','<D9AD1F0A0B678548BB8FF40C740D177202599406F8@exch-mbx-122.vmware.com>',NULL),('<1019869167.119.1384581746434.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-16 06:02:26',0,'2013-11-16 06:02:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #63','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/63/>\n\n------------------------------------------\n[...truncated 638 lines...]\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 12.008s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.17.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.63\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.5\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.12.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.8\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.b7PWixO5Nr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise34/63\n[SCP] Copying console log.\n\n\n','<709403188.115.1384409000142.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1020114142.395.1367042877947.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-04-27 06:07:57',0,'2013-04-27 06:07:57',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #109','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/109/>\n\n------------------------------------------\n[...truncated 1919 lines...]\n2013-04-27 06:04:02 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:04:02 + [[ -z install mysql-server ]]\n2013-04-27 06:04:02 + local sudo=sudo\n2013-04-27 06:04:02 ++ id -u\n2013-04-27 06:04:02 + [[ 1006 = \\0 ]]\n2013-04-27 06:04:02 + sudo DEBIAN_FRONTEND=noninteractive http_proxy= https_proxy= no_proxy= apt-get --option Dpkg::Options::=--force-confold --assume-yes install mysql-server\n2013-04-27 06:04:02 Reading package lists...\n2013-04-27 06:04:02 Building dependency tree...\n2013-04-27 06:04:02 Reading state information...\n2013-04-27 06:04:02 The following extra packages will be installed:\n2013-04-27 06:04:02   libdbd-mysql-perl libdbi-perl libhtml-template-perl libnet-daemon-perl\n2013-04-27 06:04:02   libplrpc-perl mysql-client-5.5 mysql-client-core-5.5 mysql-common\n2013-04-27 06:04:02   mysql-server-5.5 mysql-server-core-5.5\n2013-04-27 06:04:02 Suggested packages:\n2013-04-27 06:04:02   libipc-sharedcache-perl libterm-readkey-perl tinyca\n2013-04-27 06:04:02 The following NEW packages will be installed:\n2013-04-27 06:04:02   libdbd-mysql-perl libdbi-perl libhtml-template-perl libnet-daemon-perl\n2013-04-27 06:04:02   libplrpc-perl mysql-client-5.5 mysql-client-core-5.5 mysql-server\n2013-04-27 06:04:02   mysql-server-5.5 mysql-server-core-5.5\n2013-04-27 06:04:02 The following packages will be upgraded:\n2013-04-27 06:04:02   mysql-common\n2013-04-27 06:04:02 1 upgraded, 10 newly installed, 0 to remove and 7 not upgraded.\n2013-04-27 06:04:02 Need to get 25.3 MB/26.4 MB of archives.\n2013-04-27 06:04:02 After this operation, 93.7 MB of additional disk space will be used.\n2013-04-27 06:04:02 Get:1 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-common all 5.5.31-0ubuntu0.12.04.1 [13.4 kB]\n2013-04-27 06:04:02 Get:2 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-client-core-5.5 amd64 5.5.31-0ubuntu0.12.04.1 [1,936 kB]\n2013-04-27 06:04:02 Get:3 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-client-5.5 amd64 5.5.31-0ubuntu0.12.04.1 [8,350 kB]\n2013-04-27 06:04:02 Get:4 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-server-core-5.5 amd64 5.5.31-0ubuntu0.12.04.1 [6,085 kB]\n2013-04-27 06:04:02 Get:5 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-server-5.5 amd64 5.5.31-0ubuntu0.12.04.1 [8,877 kB]\n2013-04-27 06:04:02 Get:6 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/main mysql-server all 5.5.31-0ubuntu0.12.04.1 [11.6 kB]\n2013-04-27 06:04:02 Preconfiguring packages ...\n2013-04-27 06:04:02 Fetched 25.3 MB in 1s (24.6 MB/s)\n2013-04-27 06:04:02 (Reading database ... 102334 files and directories currently installed.)\n2013-04-27 06:04:02 Preparing to replace mysql-common 5.5.29-0ubuntu0.12.04.2 (using .../mysql-common_5.5.31-0ubuntu0.12.04.1_all.deb) ...\n2013-04-27 06:04:02 Unpacking replacement mysql-common ...\n2013-04-27 06:04:02 Selecting previously unselected package libnet-daemon-perl.\n2013-04-27 06:04:02 Unpacking libnet-daemon-perl (from .../libnet-daemon-perl_0.48-1_all.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package libplrpc-perl.\n2013-04-27 06:04:02 Unpacking libplrpc-perl (from .../libplrpc-perl_0.2020-2_all.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package libdbi-perl.\n2013-04-27 06:04:02 Unpacking libdbi-perl (from .../libdbi-perl_1.616-1build2_amd64.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package libdbd-mysql-perl.\n2013-04-27 06:04:02 Unpacking libdbd-mysql-perl (from .../libdbd-mysql-perl_4.020-1build2_amd64.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package mysql-client-core-5.5.\n2013-04-27 06:04:02 Unpacking mysql-client-core-5.5 (from .../mysql-client-core-5.5_5.5.31-0ubuntu0.12.04.1_amd64.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package mysql-client-5.5.\n2013-04-27 06:04:02 Unpacking mysql-client-5.5 (from .../mysql-client-5.5_5.5.31-0ubuntu0.12.04.1_amd64.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package mysql-server-core-5.5.\n2013-04-27 06:04:02 Unpacking mysql-server-core-5.5 (from .../mysql-server-core-5.5_5.5.31-0ubuntu0.12.04.1_amd64.deb) ...\n2013-04-27 06:04:02 Processing triggers for man-db ...\n2013-04-27 06:04:02 Setting up mysql-common (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:04:02 Selecting previously unselected package mysql-server-5.5.\n2013-04-27 06:04:02 (Reading database ... 102687 files and directories currently installed.)\n2013-04-27 06:04:02 Unpacking mysql-server-5.5 (from .../mysql-server-5.5_5.5.31-0ubuntu0.12.04.1_amd64.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package libhtml-template-perl.\n2013-04-27 06:04:02 Unpacking libhtml-template-perl (from .../libhtml-template-perl_2.10-1_all.deb) ...\n2013-04-27 06:04:02 Selecting previously unselected package mysql-server.\n2013-04-27 06:04:02 Unpacking mysql-server (from .../mysql-server_5.5.31-0ubuntu0.12.04.1_all.deb) ...\n2013-04-27 06:05:01 Processing triggers for ureadahead ...\n2013-04-27 06:05:01 Processing triggers for man-db ...\n2013-04-27 06:05:01 Setting up libnet-daemon-perl (0.48-1) ...\n2013-04-27 06:05:01 Setting up libplrpc-perl (0.2020-2) ...\n2013-04-27 06:05:01 Setting up libdbi-perl (1.616-1build2) ...\n2013-04-27 06:05:01 Setting up libdbd-mysql-perl (4.020-1build2) ...\n2013-04-27 06:05:01 Setting up mysql-client-core-5.5 (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:05:01 Setting up mysql-client-5.5 (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:05:01 Setting up mysql-server-core-5.5 (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:05:01 Setting up mysql-server-5.5 (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:05:01 mysql start/running, process 25467\n2013-04-27 06:05:01 Setting up libhtml-template-perl (2.10-1) ...\n2013-04-27 06:05:01 Setting up mysql-server (5.5.31-0ubuntu0.12.04.1) ...\n2013-04-27 06:05:01 + is_service_enabled q-agt\n2013-04-27 06:05:01 + services=q-agt\n2013-04-27 06:05:01 + for service in \'${services}\'\n2013-04-27 06:05:01 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,n-net, =~ ,q-agt, ]]\n2013-04-27 06:05:01 + [[ q-agt == \\n\\o\\v\\a ]]\n2013-04-27 06:05:01 + [[ q-agt == \\c\\i\\n\\d\\e\\r ]]\n2013-04-27 06:05:01 + [[ q-agt == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-04-27 06:05:01 + [[ q-agt == \\g\\l\\a\\n\\c\\e ]]\n2013-04-27 06:05:01 + [[ q-agt == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-04-27 06:05:01 + [[ q-agt == \\s\\w\\i\\f\\t ]]\n2013-04-27 06:05:01 + [[ q-agt == s-* ]]\n2013-04-27 06:05:01 + return 1\n2013-04-27 06:05:01 + TRACK_DEPENDS=False\n2013-04-27 06:05:01 + [[ False = True ]]\n2013-04-27 06:05:01 + echo_summary \'Installing OpenStack project source\'\n2013-04-27 06:05:01 + [[ -t 3 ]]\n2013-04-27 06:05:01 + echo -e Installing OpenStack project source\n2013-04-27 06:05:01 + install_keystoneclient\n2013-04-27 06:05:01 Installing OpenStack project source\n2013-04-27 06:05:01 + git_clone https://github.com/openstack/python-keystoneclient.git /opt/stack/new/python-keystoneclient master\n2013-04-27 06:05:01 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:05:01 + GIT_REMOTE=https://github.com/openstack/python-keystoneclient.git\n2013-04-27 06:05:01 + GIT_DEST=/opt/stack/new/python-keystoneclient\n2013-04-27 06:05:01 + GIT_REF=master\n2013-04-27 06:05:01 + echo master\n2013-04-27 06:05:01 + egrep -q \'^refs\'\n2013-04-27 06:05:01 + [[ ! -d /opt/stack/new/python-keystoneclient ]]\n2013-04-27 06:05:01 + [[ \'\' == \\y\\e\\s ]]\n2013-04-27 06:05:01 + setup_develop /opt/stack/new/python-keystoneclient\n2013-04-27 06:05:01 + [[ False = True ]]\n2013-04-27 06:05:01 + SUDO_CMD=sudo\n2013-04-27 06:05:01 + cd /opt/stack/new/python-keystoneclient\n2013-04-27 06:05:01 + python setup.py egg_info\n2013-04-27 06:05:01 running egg_info\n2013-04-27 06:05:01 creating python_keystoneclient.egg-info\n2013-04-27 06:05:01 writing requirements to python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:01 writing python_keystoneclient.egg-info/PKG-INFO\n2013-04-27 06:05:01 writing top-level names to python_keystoneclient.egg-info/top_level.txt\n2013-04-27 06:05:01 writing dependency_links to python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:01 writing entry points to python_keystoneclient.egg-info/entry_points.txt\n2013-04-27 06:05:01 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:05:01 reading manifest template \'MANIFEST.in\'\n2013-04-27 06:05:01 warning: no files found matching \'AUTHORS\'\n2013-04-27 06:05:01 warning: no files found matching \'ChangeLog\'\n2013-04-27 06:05:01 warning: no files found matching \'python-keystoneclient\'\n2013-04-27 06:05:01 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:05:01 ++ awk \'/^.+/ {print \"-f \" $1}\' python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:01 + raw_links=\n2013-04-27 06:05:01 ++ echo\n2013-04-27 06:05:01 ++ xargs\n2013-04-27 06:05:01 + depend_links=\n2013-04-27 06:05:01 ++ \'[\' \'!\' -r python_keystoneclient.egg-info/requires.txt \']\'\n2013-04-27 06:05:01 ++ echo \'-r *-info/requires.txt\'\n2013-04-27 06:05:01 + require_file=\'-r *-info/requires.txt\'\n2013-04-27 06:05:01 + pip_install -r python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:01 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:05:01 + [[ -z -r python_keystoneclient.egg-info/requires.txt ]]\n2013-04-27 06:05:01 + [[ -z deb ]]\n2013-04-27 06:05:01 + [[ False = True ]]\n2013-04-27 06:05:01 + SUDO_PIP=sudo\n2013-04-27 06:05:01 ++ get_pip_command\n2013-04-27 06:05:01 ++ is_fedora\n2013-04-27 06:05:01 ++ [[ -z Ubuntu ]]\n2013-04-27 06:05:01 ++ \'[\' Ubuntu = Fedora \']\'\n2013-04-27 06:05:01 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-04-27 06:05:01 ++ \'[\' Ubuntu = CentOS \']\'\n2013-04-27 06:05:01 ++ which pip\n2013-04-27 06:05:01 + CMD_PIP=/usr/bin/pip\n2013-04-27 06:05:01 + [[ -n is_fedora ]]\n2013-04-27 06:05:01 + [[ precise =~ (rhel6) ]]\n2013-04-27 06:05:01 + PIP_USE_MIRRORS=False\n2013-04-27 06:05:01 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-04-27 06:05:01 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install -r python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:01 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_keystoneclient.egg-info/requires.txt (line 1))\n2013-04-27 06:05:01 Downloading/unpacking prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:01   Cannot fetch index base URL http://pypi.openstack.org/openstack/\n2013-04-27 06:05:01   Could not find any downloads that satisfy the requirement prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:01 No distributions at all found for prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:46 Storing complete log in /opt/stack/new/.pip/pip.log\n2013-04-27 06:05:46 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-04-27 06:05:46 running develop\n2013-04-27 06:05:46 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-04-27 06:05:46 /usr/bin/python -E -c pass\n2013-04-27 06:05:46 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-04-27 06:05:46 running egg_info\n2013-04-27 06:05:46 writing requirements to python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:46 writing python_keystoneclient.egg-info/PKG-INFO\n2013-04-27 06:05:46 writing top-level names to python_keystoneclient.egg-info/top_level.txt\n2013-04-27 06:05:46 writing dependency_links to python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:46 writing entry points to python_keystoneclient.egg-info/entry_points.txt\n2013-04-27 06:05:46 reading manifest template \'MANIFEST.in\'\n2013-04-27 06:05:46 warning: no files found matching \'AUTHORS\'\n2013-04-27 06:05:46 warning: no files found matching \'ChangeLog\'\n2013-04-27 06:05:46 warning: no files found matching \'python-keystoneclient\'\n2013-04-27 06:05:46 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:05:46 running build_ext\n2013-04-27 06:05:46 Creating /usr/local/lib/python2.7/dist-packages/python-keystoneclient.egg-link (link to .)\n2013-04-27 06:05:46 Adding python-keystoneclient 0.2.3.11.g22228f5 to easy-install.pth file\n2013-04-27 06:05:46 Installing keystone script to /usr/local/bin\n2013-04-27 06:05:46 \n2013-04-27 06:05:46 Installed /opt/stack/new/python-keystoneclient\n2013-04-27 06:05:46 Processing dependencies for python-keystoneclient==0.2.3.11.g22228f5\n2013-04-27 06:05:46 Searching for oslo.config>=1.1.0\n2013-04-27 06:05:46 Reading http://pypi.openstack.org/openstack/oslo.config/\n2013-04-27 06:05:46 Download error on http://pypi.openstack.org/openstack/oslo.config/: timed out -- Some packages may not be found!\n2013-04-27 06:05:46 Reading http://pypi.openstack.org/openstack/oslo.config/\n2013-04-27 06:05:46 Download error on http://pypi.openstack.org/openstack/oslo.config/: timed out -- Some packages may not be found!\n2013-04-27 06:05:46 Couldn\'t find index page for \'oslo.config\' (maybe misspelled?)\n2013-04-27 06:05:46 Scanning index of all packages (this may take a while)\n2013-04-27 06:05:46 Reading http://pypi.openstack.org/openstack/\n2013-04-27 06:05:46 Download error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n2013-04-27 06:05:46 No local packages or download links found for oslo.config>=1.1.0\n2013-04-27 06:05:46 error: Could not find suitable distribution for Requirement.parse(\'oslo.config>=1.1.0\')\n2013-04-27 06:05:46 ++ failed\n2013-04-27 06:05:46 ++ local r=1\n2013-04-27 06:05:46 +++ jobs -p\n2013-04-27 06:05:46 ++ kill\n2013-04-27 06:05:46 ++ set +o xtrace\n2013-04-27 06:05:46 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-04-27-060247\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1020272838.28.1371103991186.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-13 06:13:11',0,'2013-06-13 06:13:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #255','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/255/>\n\n------------------------------------------\n[...truncated 956 lines...]\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.02\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.02\nTestChunkReader\n    test_read_all_data                                           OK    0.02\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.02\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.02\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.02\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.21\n    test_request_url_v1                                          OK    0.02\n    test_request_url_v1_0                                        OK    0.02\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.02\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.02\n    test_request_url_v3_unsupported                              OK    0.02\nVersionsTest\n    test_get_version_list                                        OK    0.02\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: Tests creating an queued image then subsequently updating\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 142, in _runner\n    func(*args, **kw)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance.py\",> line 337, in test_update_location\n    self._do_test_update_external_source(\'location\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance.py\",> line 277, in _do_test_update_external_source\n    response, content = http.request(path, \'POST\', headers=headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 74.16 secs:\n    15.84    TestGlanceControl.test_bouncing\n    15.03    TestScrubber.test_delayed_delete\n    14.63    TestGlanceControl.test_reload\n    14.38    TestBinGlanceCacheManage.test_queue\n    14.27    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 926 tests in 611.638s\n\nFAILED (SKIP=89, errors=1)\nUnhandled exception in thread started by <function serve_requests at 0x386db18>\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/store_utils.py\",> line 81, in serve_requests\n    httpd.serve_forever()\n  File \"/usr/lib64/python2.6/SocketServer.py\", line 224, in serve_forever\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-255\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.CHn4Jd7DjZ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/255\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/255/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1020285370.3978440.1352154216196.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 17:23:36',-18000,'2012-11-05 22:23:36',NULL,'[openstack-dev] [Synaps] a more forgiving interpretation of\n	INSUFFICIENT_DATA?','\n\n> Expect to be nagged about any issues I encounter as I get all the\n> components up & running ;)\n\nSo this is taking me a bit longer than expected to get up and running.\nI have a quick question about the storm topology that you may be able\nto help me with.\n\nBasically I see the storm cluster shut down after about 3 mins, in a\nquiescent scenario (i.e. with no metrics flowing). Presumably I\'m\ntripping over:\n\n  https://github.com/spcs/synaps/blob/master/synaps-storm/src/com/spcs/synaps/PutMetricTopology.java#L170\n\nCan you explain the logic behind the deliberate shutdown of the\ncluster? Is it just intended for testing purposes? If so, what\nare the args generally passed to the topology in the non-test\n(i.e. long running) scenario?\n\n[Currently I\'m sparking up the storm topology with:\n\n   storm jar synaps-storm/target/synaps-storm-2012.09.b3.jar  com.spcs.synaps.PutMetricTopology\n]\n\nCheers,\nEoghan\n\n\n','<1713644060.39796504.1351445780707.JavaMail.root@redhat.com>',NULL),('<1020900031.35.1374645733229.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-24 06:02:13',0,'2013-07-24 06:02:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-grizzly #105','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/105/changes>\n\nChanges:\n\n[ryan.petrello] Fix a few visual issues on the network topology diagram.\n\n------------------------------------------\n[...truncated 28 lines...]\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/105/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-grizzly-105\', \'SSH_CLIENT\': \'198.101.231.203 42527 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374091207.59839-207227227\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise2\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-24_06-00-25\', \'BUILD_NUMBER\': \'105\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'6674117c-b871-4f46-abc5-d354cf1529e0\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'b163c97c4cd0fac6d851d5264df823a620e8f67e\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise2\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#105\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 42527 64.49.246.124 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth>=1.0.7,!=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package netaddr\n    \n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-cinderclient>=1.0.2,<2.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-C3iTL5/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-C3iTL5/d2to1-0.2.10/egg-dist-tmp-6PNsxn\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-7SAgnu/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7SAgnu/setuptools-git-1.0/egg-dist-tmp-MUaQau\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.12.0,<3 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-DPn9M0/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-DPn9M0/d2to1-0.2.10/egg-dist-tmp-dngRZE\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-O5Shju/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-O5Shju/setuptools-git-1.0/egg-dist-tmp-KGZ0kR\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-FgDxaZ/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-FgDxaZ/d2to1-0.2.10/egg-dist-tmp-MiyuZk\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-V6p4Ry/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-V6p4Ry/setuptools-git-1.0/egg-dist-tmp-I651yy\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-grizzly/105\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1021101099.16.1381904108401.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-16 06:15:08',0,'2013-10-16 06:15:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #32','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/32/>\n\n------------------------------------------\n[...truncated 954 lines...]\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.02\nTestStoreAuthV1\n    test_add                                                     OK    0.03\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.20\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Spin up the api servers with multiprocessing on\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 41, in test_multiprocessing\n    self.assertEqual(response.status, 200)\nAssertionError: 500 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (500, 200))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 140.65 secs:\n    75.73    TestGlanceControl.test_bouncing\n    17.09    TestBinGlanceCacheManage.test_queue\n    16.85    TestBinGlance.test_results_filtering\n    16.16    TestRootApi.test_version_configurations\n    14.82    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 932 tests in 792.988s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-32\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=96\n+ \'[\' 96 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.fjRbdpLylr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/32/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-2/32\n[SCP] Copying console log.\n\n\n','<1414226607.14.1381817488300.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1021845875.41660024.1356005729764.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-20 07:15:29',-18000,'2012-12-20 12:15:29',NULL,'[openstack-dev] Novaclient and Extensions','\n\n> Thinking about this, and what it really might look like to a user. I\n> want to apply some hard data around this issue.\n> \n> There are 32 viable core \"calls\" for the Compute API. [1] There are\n> over 90 viable extension calls.[2] I haven\'t done the complete audit\n> yet for missing docs for extensions, but I know that there\'s about a\n> 3 times factor of core calls to extension calls based on the doc\n> work I\'ve done and managed.\n\nSpeaking of the proliferation of extensions, we even have a case where\none extension partially duplicates another (the absolute limits side of\nos-user-limits versus os-quota-sets show).\n\nSo part of the approach to addressing this may be to set a higher bar for\naccepting extensions, and promote consolidation of related concerns to\neliminate the fragmentation/duplication.\n\nCheers,\nEoghan\n\n\n','<CAD0KtVFCC_HqORYSVZ6HTtJfqqxgwXARtcAMJ4ZvfrbX8EDeMA@mail.gmail.com>',NULL),('<1021940860.26284941.1391762661756.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-07 03:44:21',-18000,'2014-02-07 08:44:21',NULL,'[Openstack-docs] Using Tox','Hi Andreas, \nI ran into the disappearing test.py issue, then went to find out about Tox, and have now updated the wiki (replaced the test.py section): \nhttps://wiki.openstack.org/wiki/Documentation/HowTo#Using_Tox_to_check_builds \n\nBecause it\'s based on your page that I googled (love google), would you please review? \n\nthanks, Summer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140207/f8f76c89/attachment.html>\n\n','<CAEQ9F6XxJp9WHB5-fatELYEfsBROiGSg31Ktnq8S-oJu5ANTpg@mail.gmail.com>',NULL),('<1022584341.776188.1386716379533.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 23:59:39',3600,'2013-12-10 22:59:39',NULL,'[openstack-dev] Unified Guest Agent proposal','\nMaybe it will be useful to use Ovirt guest agent as a base.\n\nhttp://www.ovirt.org/Guest_Agent\nhttps://github.com/oVirt/ovirt-guest-agent\n\nIt is already working well on linux and windows and has a lot of functionality.\nHowever, currently it is using virtio-serial for communication, but I think it can be extended for other bindings.\n\nVladik\n\n----- Original Message -----\n> From: \"Clint Byrum\" <clint at fewbar.com>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, 10 December, 2013 4:02:41 PM\n> Subject: Re: [openstack-dev] Unified Guest Agent proposal\n> \n> Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 12:37:37 -0800:\n> > >> What is the exact scenario you\'re trying to avoid?\n> > \n> > It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server\n> > (Salt / Our own self-written server). Looking at the design, it doesn\'t\n> > look like the attack could be somehow contained within a tenant it is\n> > coming from.\n> > \n> \n> We can push a tenant-specific route for the metadata server, and a tenant\n> specific endpoint for in-agent things. Still simpler than hypervisor-aware\n> guests. I haven\'t seen anybody ask for this yet, though I\'m sure if they\n> run into these problems it will be the next logical step.\n> \n> > In the current OpenStack design I see only one similarly vulnerable\n> > component - metadata server. Keeping that in mind, maybe I just\n> > overestimate the threat?\n> > \n> \n> Anything you expose to the users is \"vulnerable\". By using the localized\n> hypervisor scheme you\'re now making the compute node itself vulnerable.\n> Only now you\'re asking that an already complicated thing (nova-compute)\n> add another job, rate limiting.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1386708760-sup-4586@clint-HP>',NULL),('<1023123863.49118489.1363862930235.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-21 06:48:50',-14400,'2013-03-21 10:48:50',NULL,'[openstack-dev] [Nova] Backportable DB Migrations','\n> Greetings,\n> \n> One of the features we had on the roadmap for Grizzly was the ability\n> to\n> backport DB migrations to stable/grizzly after the release if\n> necessary.\n>  The blueprint became a Havana blueprint, because the implementation\n> turned out to just reserve a range of migrations numbers at the\n> beginning of Havana development.\n> \n>     https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations\n>     https://review.openstack.org/#/c/23759/\n> \n> I wanted to make sure everyone was aware of this when doing\n> reviews of future db migrations.  It means that we must make\n> sure that migrations added for Havana are idempotent.  That way\n> it should be safe to backport them.  \n\nThis is great progress, but one potential nit just occurred to me ...\n\nIt relates to the now-traditional compaction of adjacent nova migrations\nat release time.\n\nSince stable/grizzly will live on post-havana, and say the reserved\nplaceholder range of slots 162-171 haven\'t all been used, would we want\nto keep the option open for security fixes with associated migrations\nto be backported to stable/grizzly *after* havana is released?\n\nIf so, wouldn\'t that preclude doing the migration compaction at \nhavana release time?\n\nCheers,\nEoghan\n\n> When someone upgrades from\n> a stable release that included backportable migrations, they\'re\n> going to get the same migration again at a higher number.\n> \n> Thanks!\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<514A32BF.3050407@redhat.com>',NULL),('<1023244479.100.1357973232955.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-12 06:47:12',0,'2013-01-12 06:47:12',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-full #72','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/72/>\n\n\n\n','<1300487886.79.1357885250693.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1024075100.7243332.1409290911300.JavaMail.zimbra@zimbra.xlab.si>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-29 07:41:51',7200,'2014-08-29 05:41:51',NULL,'[Openstack-operators] Nocna migracija virtualk, Openstack','Migracija opravljena, bi vas pa rad opozoril na \"novi feature\" najnovejsega bugfix-a openstack quantum networkinga. \n\nPo novem openstack filtrira tudi promet med virtualkami znotraj istega projekta. Zaradi tega je treba v Security Groups dodati tudi porte, preko katerih virtualke znotraj projekta komunicirajo med seboj (thanks Matej A.)\n\n- Robert\n\n----- Original Message -----\nFrom: \"Robert Plestenjak\" <robert.plestenjak at xlab.si>\nTo: \"Ales Stimec\" <ales.stimec at xlab.si>, \"Ales Cernivec\" <ales.cernivec at xlab.si>, \"Stas - XLAB\" <stas.strozak at xlab.si>, \"Boris Savi?\" <boris.savic at xlab.si>, \"Matej Arta?\" <matej.artac at xlab.si>, \"Uro? Trebec\" <uros.trebec at xlab.si>, \"Gregor Berginc\" <gregor.berginc at xlab.si>, \"Jure Polutnik\" <jure.polutnik at xlab.si>, \"Simon Ivan?ek\" <simon.ivansek at xlab.si>, \"Anze Brvar\" <anze.brvar at xlab.si>\nCc: \"Justin Cinkelj\" <justin.cinkelj at xlab.si>, openstack-operators at lists.openstack.org\nSent: Thursday, August 28, 2014 3:07:10 PM\nSubject: Nocna migracija virtualk, Openstack\n\nDanes ponoci bi rad zmigriral naslednje virtualke na na novo nadgrajeni openstack-02 server. Lahko se zgodi, da bo virtalka zaradi tega zacasno nedostopna (1-10 minut). Po tej migraciji bomo server ugasnili in ga nadgradili (+1x CPU +148GB RAM). Pri vseh virtualkah bom poskrbel da se bodo zagnale nazaj in da bo delovala mreza.\n\n\nserver: openstack-03\n| ac69bef4-ad6e-49a8-9062-5f22dfae34c9 | GiraffPlus CTX        | ACTIVE | GiraffPlus=10.32.19.5, 10.10.43.115\n| 45ec86c1-d0c4-4841-a654-28bb193883bb | GiraffPlus Mongo 1    | ACTIVE | GiraffPlus=10.32.19.4, 10.10.43.89\n| 7a367f28-277c-43d1-8d09-8814591a6aad | GiraffPlus Mongo 3    | ACTIVE | GiraffPlus=10.32.19.7, 10.10.43.90\n| 789be527-56aa-4bcd-ab1b-2d605efeae55 | GiraffPlus XL Web     | ACTIVE | GiraffPlus=10.32.19.3, 10.10.43.85\n| 1fa04175-40ee-49f7-9889-f374a77eed4d | WD20-gateway          | ACTIVE | XNautica=10.32.17.18, 10.10.43.68\n| 11e2f0aa-ff20-4212-827e-280c1d14799e | Wirecloud             | ACTIVE | finesce-interna=10.32.27.6; finesce-dmz-network=10.32.28.4, 10.10.43.120\n| e9229360-9101-4452-8b3e-ffce0032fbd5 | dmt-db                | ACTIVE | dmt-lan=10.32.10.9, 10.10.43.111\n| f830877e-3325-480d-bedd-de1c8b78cad5 | dmt-logging           | ACTIVE | dmt-lan=10.32.10.10\n| b5c1b8a8-c783-4377-82fe-b0148c8e9f51 | logger                | ACTIVE | olaii=10.32.13.107, 10.10.43.116\n| 43f44f20-12df-4784-91bb-5b359ed2d9c9 | mongodb               | ACTIVE | XNautica=10.32.17.11, 10.10.43.109\n| 894774bb-007c-4124-a29c-2c2dfdd3ccea | olaii-api             | ACTIVE | olaii=10.32.13.106, 10.10.43.65\n| 5a1eb773-4fa7-4a2f-b52a-a7a642833f0a | olaii-solr            | ACTIVE | olaii=10.32.13.104, 10.10.43.99\n| a3eed585-5dd6-4b75-94fa-854a7e002db3 | phov-mongo            | ACTIVE | gaea-crunchers=10.32.21.9, 172.16.95.6\n| 150db7ae-2531-475b-bf2b-a1f5e3cee286 | speu-websvc-analytics | ACTIVE | speu-net=10.32.23.5, 172.16.95.2\n| d8193a12-06ca-43c7-a2d4-95024773461d | speu-x-portal         | ACTIVE | speu-net=10.32.23.4, 172.16.95.33\n| fbcea9e2-3b48-423e-ab25-cc5af17727e2 | teltonika-nosql       | ACTIVE | cloudscale=10.32.11.102, 10.10.43.71\n| a8a79a32-dab1-4acc-9c1f-e0e583516971 | xmarine-stage         | ACTIVE | XNautica=10.32.17.16, 10.10.43.105\n\nLP,\nRobert\n\n\n','<1841563690.7223570.1409231230640.JavaMail.zimbra@zimbra.xlab.si>',NULL),('<1024708230.10.1385016576227.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-21 06:49:35',0,'2013-11-21 06:49:35',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #3','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/3/>\n\n------------------------------------------\n[...truncated 20847 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.api.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization[gate]\ntempest.api.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization[gate] ... skipped u\'Skipped until Bug: 1093743 is resolved.\'\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  212.866\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           99.852\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  78.830\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    42.573\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       40.827\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     40.560\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        40.404\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        37.416\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     34.526\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_confirm[gate,smoke]             33.967\n\n----------------------------------------------------------------------\nRan 1340 tests in 1391.527s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-706014-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-706014.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-706014/3/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1341775716.4.1384929659082.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1024712399.250.1356739495716.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-29 00:04:55',0,'2012-12-29 00:04:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #89','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/89/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/89\n[SCP] Copying console log.\n\n\n','<1695190998.228.1356653065388.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1025112007.39036397.1385120803465.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 06:46:43',-18000,'2013-11-22 11:46:43',NULL,'[openstack-dev] [horizon] Javascript development improvement','\"Maxime Vidori\" <maxime.vidori at enovance.com> wrote:\n> Hi all, I know it is pretty annoying but I have to resurrect this subject.\n> \n> With the integration of Angularjs into Horizon we will encounter a lot of\n> issues with javascript. I ask you to reconsider to bring back Nodejs as a\n> development platform. I am not talking about production, we are all agree\n> that Node is not ready for production, and we do not want it as a backend.\n> But the facts are that we need a lot of its features, which will increase\n> the tests and the development. Currently, we do not have any javascript code\n> quality: jslint is a great tool and can be used easily into node. Angularjs\n> also provides end-to-end testing based on nodejs again, testing is important\n> especially if we start to put more logic into JS. Selenium is used just to\n> run qUnit tests, we can bring back these tests into node and have a clean\n> unified testing platform. Tests will be easier to perform.\n\nIt seems a bit crazy to me to introduce NodeJS as a dependency just for\nthe sake of an easy way to run jslint. There are other options\navailable that run without NodeJS as a dependency.\n\nThere are more implications to running NodeJS even only for\ndevelopment. It will likely have an impact on our infrastructure as\nwell, since we\'ll want these checks running on patches up for\nreview. Then if it\'s there for development it increases the risk it\nwill creep in as a dependency for our runtime.\n\nAs for Selenium, are you talking about rewriting our existing Selenium\ntests in Javascript? If so I am opposed to this. The strength of our\ncommunity is in Python, if we want to encourage people to write more\ntests we should make it easy for them to do so.\n\nI think you bring up great points, we do need to control our Javascript\nquality better especially as we bring in more of it into our\ncodebase. But, style checks, CSS, and unit testing, shouldn\'t require\nNodeJS.\n\nJulie\n \n> Finally, (do not punch me in the face) lessc which is used for bootstrap is\n> completely integrated into it. I am afraid that modern javascript\n> development can not be perform without this tool.\n> \n> Regards\n> \n> Maxime Vidori\n> \n\n\n','<1308279226.1014010.1384963276076.JavaMail.root@enovance.com>',NULL),('<1026879496.49.1352938457323.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-15 00:14:17',0,'2012-11-15 00:14:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-diablo #93','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/93/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric4 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/>\nCheckout:periodic-swift-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/> - hudson.remoting.Channel at 4d8811e0:oneiric4\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson2071193186154773312.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-diablo/93\n[SCP] Copying console log.\n\n\n','<1742005326.21.1352852132636.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1027006200.26741899.1402757706653.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-14 10:55:06',-14400,'2014-06-14 14:55:06',NULL,'[openstack-dev] mysql/mysql-python license \"contamination\" into\n openstack?','\n\n> On Thu Jun 12 14:13:05 2014, Chris Friesen wrote:\n> > Hi,\n> >\n> > I\'m looking for the community viewpoint on whether there is any chance\n> > of license contamination between mysql and nova.  I realize that\n> > lawyers would need to be involved for a proper ruling, but I\'m curious\n> > about the view of the developers on the list.\n> >\n> > Suppose someone creates a modified openstack and wishes to sell it to\n> > others.  They want to keep their changes private.  They also want to\n> > use the mysql database.\n> >\n> > The concern is this:\n> >\n> > nova is apache licensed\n> > sqlalchemy is MIT licensed\n> > mysql-python (aka mysqldb1) is GPLv2 licensed\n> > mysql is GPLv2 licensed\n> >\n> >\n> >\n> > The concern is that since nova/sqlalchemy/mysql-python are all\n> > essentially linked together, an argument could be made that the work\n> > as a whole is a derivative work of mysql-python, and thus all the\n> > source code must be made available to anyone using the binary.\n> >\n> > Does this argument have any merit?\n> \n> the GPL is excepted in the case of MySQL and other MySQL products\n> released by Oracle (can you imagine such a sentence being\n> written.....), see\n> http://www.mysql.com/about/legal/licensing/foss-exception/.   If\n> MySQL-Python itself were an issue, OpenStack could switch to another\n> MySQL library, such as MySQL Connector/Python which is now MySQL\'s\n> official Python driver:\n> http://dev.mysql.com/doc/connector-python/en/index.html\n\nUsual IANAL caveats ...\n\nBut do these concerns about license contamination from the DB service,\nvia the client libraries, have any relevance to the prior discussion\nabout MongoDB licensing?\n\nSubstituting:\n\n  s/mysql is GPLv2/mongodb is AGPLv3/\n  s/sqlalchemy is MIT licensed/pymongo is Apache licensed/\n\nand noting the MongoDB Inc \"promise\" about database and client library\nseparateness.\n\nIf there is some relevance, then some of the conclusions to the prior\nlegal discussion may be useful to recall:\n\n  http://lists.openstack.org/pipermail/legal-discuss/2014-March/000189.html\n\nCheers,\nEoghan\n\n> > Has anyone tested any of the mysql DBAPIs with more permissive licenses?\n> \n> I just mentioned other MySQL drivers the other day; MySQL\n> Connector/Python, OurSQL and pymysql are well tested within SQLAlchemy\n> and these drivers generally pass all tests.   There\'s some concern over\n> compatibility with eventlet, however, I can\'t speak to that just yet.\n> \n> >\n> > Chris\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5399FFB8.9050702@redhat.com>',NULL),('<1027803512.4581393.1369223536738.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-22 07:52:16',-14400,'2013-05-22 11:52:16',NULL,'[openstack-dev] Horizon isn\'t working for me after the D3\n change went in on Fedora','Hi Kyle,\n\n\"Kyle Mestery (kmestery)\" <kmestery at cisco.com> wrote:\n> 1. Rebooting the host and restocking. Same result in that the failure happens\n> again.\n> 2. Restacking the host. Same result, the failure happens again.\n> 3. Reverting to prior to the D3 commit, running the manage.py command below.\n> This results in things working again.\n> 4. Stacking, and then stopping horizon and all httpd process, followed by\n> running horizon directly from /opt/stack/horizong via run_tests.sh. This\n> works as well and I even get the new D3 pie charts.\n> \n> So, there appears to be a cache issue somewhere, but I can\'t seem to figure\n> out where. Clearing the cache on my browsers (I\'ve tried Chrome, Firefox,\n> and Safari to no avail) doesn\'t seem to help either.\n\nI saw something similar on a machine with a long running devstack instance, and upgrading the django_compressor library then restarting httpd fixed it for me.\n\n $ sudo pip -U install django_compressor\n\nI\'m guessing there is something in the d3 javascript that django_compressor 1.2 wasn\'t handling correctly.\n\nHope this helps,\n\nJulie\n\n\n','<CC6516285E165D48ACB2CF4D9266006C2153A11C@xmb-aln-x05.cisco.com>',NULL),('<1028368190.2008436.1415203039492.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-05 10:57:19',-18000,'2014-11-05 15:57:19',NULL,'[Openstack-operators] Full list of Etherpads for Ops Summit','Nevermind, found it:\n\nhttps://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops\n\nWill update the other page.\n\n----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: openstack-operators at lists.openstack.org\n> Sent: Wednesday, November 5, 2014 4:55:51 PM\n> Subject: Full list of Etherpads for Ops Summit\n> \n> Hi all,\n> \n> Is there a full list of etherpads for the ops summit sessions somewhere? I\n> noticed there isn\'t one linked here:\n> \n>     https://wiki.openstack.org/wiki/Summit/Planning\n> \n> Thanks,\n> \n> Steve\n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<267527908.2007508.1415202951056.JavaMail.zimbra@redhat.com>',NULL),('<1028454297.71.1386828116147.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:01:56',0,'2013-12-12 06:01:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-docs-havana #3','See <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/3/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise37 in workspace <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/>\nCheckout:periodic-neutron-docs-havana / <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/> - hudson.remoting.Channel at 35e7c37d:precise37\nUsing strategy: Default\nLast Built Revision: Revision cec8127f0972d20646a8df49c13021174c346e27 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/neutron\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/neutron\nCommencing build of Revision cec8127f0972d20646a8df49c13021174c346e27 (origin/stable/havana)\nChecking out Revision cec8127f0972d20646a8df49c13021174c346e27 (origin/stable/havana)\n[periodic-neutron-docs-havana] $ /bin/bash -xe /tmp/hudson8971630591496515057.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack neutron\n+ org=openstack\n+ project=neutron\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack neutron /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=neutron\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z neutron ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack neutron\n++ org=openstack\n++ project=neutron\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack neutron /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=neutron\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z neutron ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/neutron /opt/requirements/projects.txt\nopenstack/neutron\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/test-requirements.txt,> setuptools_git>=0.4\nvenv inst: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/dist/neutron-jenkins.periodic.neutron.docs.havana.3.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-havana/precise37\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-havana/precise37/3\n[SCP] Copying console log.\n\n\n','<1462430571.64.1386741900552.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1028657662.30.1371190355034.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-14 06:12:35',0,'2013-06-14 06:12:35',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #256','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/256/>\n\n\n\n','<1020272838.28.1371103991186.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1029034916.507.1367302007612.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-30 06:06:47',0,'2013-04-30 06:06:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #20','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/20/>\n\n------------------------------------------\n[...truncated 5087 lines...]\n2013-04-30 06:06:42    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-30 06:06:42,181 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-30 06:06:42,185 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-30 06:06:42,187 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,188 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,189 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-30 06:06:42,190 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-30 06:06:42,192 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-30 06:06:42  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-30 06:06:42,193 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-30 06:06:42    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-30 06:06:42,194 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,201 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.200838\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.200838\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42,202 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,203 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,204 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,206 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42,207 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.206462\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.206462\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42,210 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,214 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,217 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-30 06:06:42,220 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,222 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,225 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42,227 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.225379\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.225379\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42,229 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,230 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,231 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-30 06:06:42,232 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,233 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,236 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42,237 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.236010\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.236010\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42,240 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,242 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,243 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-30 06:06:42,245 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,246 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,249 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-30 06:06:42,253 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-30 06:06:42,255 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.253266\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-30T06:06:42.253266\', resource_metadata={}) from 0 transformer\n2013-04-30 06:06:42,257 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,258 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42,259 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-30 06:06:42,261 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-30 06:06:42,262 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-30 06:06:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 24.601s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.20\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a79.g3acd2a5\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a438.gfeb1b03\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.t6lE2wHs7x\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/20\n[SCP] Copying console log.\n\n\n','<1791339655.490.1367215716376.JavaMail.jenkins@jenkins.openstack.org>',NULL);
INSERT INTO `messages` VALUES ('<1029073497.353.1357258419702.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-04 00:13:39',0,'2013-01-04 00:13:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #95','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/95/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.90 secs:\n    2.84    Kc11TestCase.test_admin_requires_adminness\n    2.32    KcEssex3TestCase.test_admin_requires_adminness\n    2.16    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 49.173s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==3.0.5\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.2bEbPQuuJv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/95\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/95/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<952673507.332.1357171481569.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1029183a-288b-4954-890a-c26bd0915eef@aptira.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-13 10:33:07',39600,'2012-10-12 23:33:07',NULL,'[OpenStack Foundation] [Foundation Board] OpenStack syllabi\n -was- Re: Use of the word \"certified\" and protecting brand OpenStack','Boris this is exactly what we need to do and what I was looking towards by suggesting a panel in my first post, and I would be happy to be part of that.\n \nLloyd it\'s fantastic to hear you are keen to take part.\n \nI\'m looking forward to seeing how this develops from Monday\'s Board meeting.\n \n \n \nFrom: Boris Renski [mailto:brenski at mirantis.com] \nSent: Saturday, 13 October 2012 1:57 AM\nTo: \'Lloyd Dewolf\'; \'Tristan Goode\'\nCc: foundation at lists.openstack.org; foundation-board at lists.openstack.org\nSubject: RE: [Foundation Board] OpenStack syllabi -was- Re: [OpenStack Foundation] Use of the word \"certified\" and protecting brand OpenStack\n \nI second Lloyd\'s comment. We\'ve been running a very popular OpenStack Bootcamp program and have delivered 20+ private and public OpenStack classes during the last 6 months. We\'ve been asked on many occasions about OpenStack certification, but have purposely deferred this, stating that it is a prerogative of the foundation to accredit a certification program. \n \nI\'d like to propose that we form an OpenStack training / certification committee comprised of folks passionate about getting the formal training and certification program underway. \n \nNaturally, I volunteer to chair that committee and help spearhead the initiative. I suppose Tristan and folks from RackSpace, Piston and Hastexo (who already run trainings) would make good committee members as well. We can discuss the details during the upcoming board meeting on Monday.  \n \nWhat does everybody think? \n \nFrom: Lloyd Dewolf [mailto:lloydostack at gmail.com] \nSent: Thursday, October 11, 2012 2:58 PM\nTo: Tristan Goode\nCc: foundation at lists.openstack.org; foundation-board at lists.openstack.org\nSubject: [Foundation Board] OpenStack syllabi -was- Re: [OpenStack Foundation] Use of the word \"certified\" and protecting brand OpenStack\n \nOn Wed, Oct 10, 2012 at 2:42 PM, Tristan Goode <tristan at aptira.com> wrote:\n \nLeaving Rackspace\'s actions aside, I made a suggestion for a certification process for training materials and deliverables that they be offered to a community sourced committee for review and approval. If this proposal is accepted then I would ask Rackspace that they offer up their course materials for this review, and that this might form a baseline for establishing the certification benchmark.\n \nI\'m interested in collaborating on OpenStack course work.\n \nWe\'ve done training for our customers on Piston Enterprise OpenStack, and the European participants particularly have wanted certification. I\'ve been eager to work on this for many months. I\'ve just waiting for the Foundation to get it\'s legs under it.\n \nNear the start of my career I found the lpi.org first course and test helped boost my Linux skill set. The experience encouraged me to play a small role in the IBM team developing a version of the certification testing for IBM DB2 back in the day.\n \nI\'d like to contribute to developing common OpenStack syllabi.\n \n \nThank you,\n--\n@lloyddewolf\nhttp://www.pistoncloud.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121013/c38155be/attachment.html>\n\n','<010f01cda889$d14d4360$73e7ca20$@mirantis.com>',NULL),('<1029288380.6182871.1404719179617.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 03:46:19',-14400,'2014-07-07 07:46:19',NULL,'[openstack-dev] [Heat][Ceilometer] A proposal to enhance\n ceilometer alarm','\n\n> > Alarms in ceilometer may currently only be based on a statistics trend\n> > crossing a threshold, and not on the occurrence of an event such as\n> > compute.instance.delete.end.\n> \n> Right.  I realized this after spending some more time understanding the\n> alarm-evaluator code.  Having \'Statistics\' model to record (even the\n> last sample of) a field will be cumbersome.\n\nYep.\n \n> > Near the end of the Icehouse cycle, there was an attempt to implement\n> > this style of notification-based alarming but the feature did not land.\n> \n> After realizing \'Statistics\' is not the ideal place for extension, I\n> took a step back and asked myself: \"what am I really trying to get from\n> Ceilometer?\" The answer seems to be an Alarm or Event, with some\n> informational fields telling me some context of such an Alarm or Event.\n> So I am now thinking of a EventAlarm in addition to ThresholdAlarm and\n> CombinationAlarm.  The existing alarms are all based on meter samples.\n> Such an event based alarm would be very helpful to implement features\n> like keeping members of a AutoScalingGroup (or other Resource Group)\n> alive.\n\nSo as I mentioned, we did have an attempt to provide notification-based\nalarming at the end of Icehouse:\n\n  https://review.openstack.org/69473\n\nbut that did not land.\n\nIt might be feasible to resurrect this, based on the fact that the events\nAPI will shortly be available right across the range of ceilometer v2\nstorage drivers (i.e. not just for sqlalchemy).\n\nHowever this is not currently a priority item on our roadmap (though\nas always, patches are welcome).\n\nNote though that the Heat-side logic to consume the event-alarm triggered\nby a compute.instance.delete event wouldn\'t be trivial, as Heat would have\nto start remembering which instances it had *itself* deleted as part of\nthe normal growth and shrinkage pattern of an autoscaling group\n\n(so that it can distinguish a intended instance deletion from an accidental\ndeletion)\n\nI\'m open to correction, but AFAIK Heat does not currently record such\nstate.\n \n> > Another option would be for Heat itself to consume notifications and/or\n> > periodically check the integrity of the autoscaling group via nova-api,\n> > to ensure no members have been inadvertently deleted.\n> \n> Yes. That has been considered by the Heat team as well.  The only\n> concern regarding directly subscribing to notification and then do\n> filtering sounds a duplicated work already done in Ceilometer. From the\n> use case of convergence, you can guess that this is acutally not limited\n> to the auto-scaling scenario.\n\nSure, but does convergence sound like it\'s *relevant* to the autoscaling\ncase?\n \n> > This actually smells a little some of the requirements driving the\n> > notion of \"convergence\" in Heat:\n> > \n> >   https://review.openstack.org/#/c/95907/6/specs/convergence.rst\n> > \n> > TL;DR: make reality the source the truth in Heat, as opposed to the\n> >        approximation of reality expressed in the template\n> > \n> > >  - When a VM connected to multiple subnets is experiencing bandwidth\n> > >    problem, an alarm can be generated telling Heat which subnet is to be\n> > >    checked.\n> > \n> > Would such a bandwidth issue be suitable for auto-remediation by the\n> > *auto*scaling logic?\n> > \n> > Or would it require manual intervention?\n> \n> As I have noted above, getting notified by physical resource state\n> changes and then reacting properly is THE requirement.  It is beyond\n> what auto-scaling does today.  There are cases where manual intervention\n> is needed, while there are other cases where Heat can handle given\n> sufficient information.\n\nCan you provide some examples of those latter cases?\n\n(so as to ground this discussion solidly in the here-and-now)\n \n> > > We believe there will be many other use cases expecting an alarm to\n> > > carry some \'useful\' information beyond just a state transition. Below is\n> > > a proposal to solve this.  Any comments are welcomed.\n> > > \n> > > 1. extend the alarm with an optional parameter, say, \'output\', which is\n> > >    a map or an equivalent representation.  A user can specify some\n> > >    key=value pairs using this parameter, where \'key\' is a convenience\n> > >    for user and value is used to specify a field from a Sample whose\n> > >    value will be filled  in here.\n> > > \n> > >    e.g. --output instance=metadata.instance_id;timestamp=timestamp\n> > \n> > While such additional context may be useful, I\'m not sure your examples\n> > would apply in general because:\n> > \n> >  * there wouldn\'t be a *single* distinguished instance ID that caused\n> >    the alarm statistic to go over-threshold (as the cpu_util or whatever\n> >    metric is aggregated across the entire autoscaling group in the alarm\n> >    evaluation)\n> > \n> >  * there wouldn\'t be a discrete timestamp when the statistic crossed the\n> >    alarm threshold due to perioidization and sampling effects\n> \n> Okay.  I admit that if the alarm is evaluated based on Statistics, these\n> are all true concerns.  I didn\'t quite realize that before.  What do you\n> think if Ceilometer provides an EventAlarm then?  If Alarm is generated\n> from an Event, then the above context can be extracted, at least by\n> tweaking event_definitions.yaml?\n\nPossibly, yes.\n\nI\'d imagine that such a feature would include the ability to request\nthat certain event fields (\"traits\") are included in the alarm reason.\n\nCheers,\nEoghan\n \n> > > 2. extend the Ceilometer alarm-evaluator service, so that when an alarm\n> > >    is seen requiring output values, it will try matching the \'value\'\n> > >    specified above to the fields in a sample, and replace the output\n> > >    entry with \'key=<real_value>\'.\n> > > \n> > >    e.g. \"output\": {\n> > >           \"instance\": \"bd56bb53-d07f-49a6-8f60-6f8ef1336060\",\n> > > 	  \"timestamp\": \"2014-07-0102: 21: 13.002155\",\n> > > 	}\n> > > \n> > >    The above data is passed back to the alarm_url as part of its\n> > >    existing payload.\n> > > \n> > >    If alarm-evaluator cannot find a matching field, it can fill in an\n> > >    empty string, or just \"None\".\n> > > \n> > > 3. extend the OS::Ceilometer::Alarm resource type in Heat so that an\n> > >    optional property (say, \'output\') of type map can be used to specify\n> > >    what are expected from the Alarm.\n> > \n> > And would the logic to consume such additional context be baked into\n> > the heat.engine.resources.autoscaling module?\n> > \n> > Or would that be plugable somehow?\n> \n> We have an interest to improve the AutoScalingGroup resource so that\n> member failures can be detected and handled properly.  This may warrant\n> a specs in Heat project.\n> \n> > > Since it is an additional field in the \'details\' argument, the impact to\n> > > existing Heat template/users will be negligible.  However, the\n> > > expressive power of carrying back additional fields would be a great\n> > > help to some scenarios we yet to know.\n> > > \n> > > Because this is a cross-project proposal, comments from both communities\n> > > are valuable and thus appreciated.  If it is a viable approach, should\n> > > we raise two specs in both projects repectively?\n> > \n> > I\'m unconvinced as yet as to the viability, on the basis of my comments\n> > above. Though I\'ll keep an open mind with regard to your responses.\n> > \n> > Thanks,\n> > Eoghan\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140707071532.GA408@localhost>',NULL),('<1029493687.33.1378276287335.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-04 06:31:27',0,'2013-09-04 06:31:27',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #16','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/16/>\n\n------------------------------------------\n[...truncated 17395 lines...]\n2013-09-04 06:30:13 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-04 06:30:13 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-04 06:30:13 # have to be different)\n2013-09-04 06:30:13 multi_backend_enabled = false\n2013-09-04 06:30:13 backend1_name = BACKEND_1\n2013-09-04 06:30:13 backend2_name = BACKEND_2\n2013-09-04 06:30:13 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-04 06:30:13 # You should update to reflect those exported by configured backend driver.\n2013-09-04 06:30:13 storage_protocol = iSCSI\n2013-09-04 06:30:13 vendor_name = Open Source\n2013-09-04 06:30:13 \n2013-09-04 06:30:13 [object-storage]\n2013-09-04 06:30:13 # This section contains configuration options used when executing tests\n2013-09-04 06:30:13 # against the OpenStack Object Storage API.\n2013-09-04 06:30:13 \n2013-09-04 06:30:13 # You can configure the credentials in the compute section\n2013-09-04 06:30:13 \n2013-09-04 06:30:13 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-04 06:30:13 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-04 06:30:13 # this value as \"object-store\"\n2013-09-04 06:30:13 catalog_type = object-store\n2013-09-04 06:30:13 \n2013-09-04 06:30:13 # Number of seconds to time on waiting for a container to container\n2013-09-04 06:30:13 # synchronization complete\n2013-09-04 06:30:14 container_sync_timeout = 120\n2013-09-04 06:30:14 # Number of seconds to wait while looping to check the status of a\n2013-09-04 06:30:14 # container to container synchronization\n2013-09-04 06:30:14 container_sync_interval = 5\n2013-09-04 06:30:14 # Set to True if the Account Quota middleware is enabled\n2013-09-04 06:30:14 accounts_quotas_available = True\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Set operator role for tests that require creating a container\n2013-09-04 06:30:14 operator_role = Member\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [boto]\n2013-09-04 06:30:14 ssh_user = cirros\n2013-09-04 06:30:14 # This section contains configuration options used when executing tests\n2013-09-04 06:30:14 # with boto.\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # EC2 URL\n2013-09-04 06:30:14 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-04 06:30:14 # S3 URL\n2013-09-04 06:30:14 s3_url = http://127.0.0.1:3333\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-04 06:30:14 aws_access =\n2013-09-04 06:30:14 aws_secret =\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Image materials for S3 upload\n2013-09-04 06:30:14 # ALL content of the specified directory will be uploaded to S3\n2013-09-04 06:30:14 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-04 06:30:14 # Subdirectories not allowed!\n2013-09-04 06:30:14 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-04 06:30:14 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-04 06:30:14 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-04 06:30:14 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Instance type\n2013-09-04 06:30:14 instance_type = m1.nano\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # TCP/IP connection timeout\n2013-09-04 06:30:14 http_socket_timeout = 30\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Number of retries actions on connection or 5xx error\n2013-09-04 06:30:14 num_retries = 1\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Status change wait timout\n2013-09-04 06:30:14 build_timeout = 400\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Status change wait interval\n2013-09-04 06:30:14 build_interval = 1\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [orchestration]\n2013-09-04 06:30:14 # Status change wait interval\n2013-09-04 06:30:14 build_interval = 1\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Status change wait timout. This may vary across environments as some some\n2013-09-04 06:30:14 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-04 06:30:14 build_timeout = 300\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Instance type for tests. Needs to be big enough for a\n2013-09-04 06:30:14 # full OS plus the test workload\n2013-09-04 06:30:14 instance_type = m1.micro\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-04 06:30:14 # If not specified, tests that spawn instances will not run\n2013-09-04 06:30:14 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-04 06:30:14 # any key, which will generate a keypair for each test class\n2013-09-04 06:30:14 #keypair_name = heat_key\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [dashboard]\n2013-09-04 06:30:14 # URL where to find the dashboard home page\n2013-09-04 06:30:14 dashboard_url = http://127.0.0.1/\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # URL where to submit the login form\n2013-09-04 06:30:14 login_url = http://127.0.0.1/auth/login/\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [scenario]\n2013-09-04 06:30:14 # Directory containing image files\n2013-09-04 06:30:14 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # AMI image file name\n2013-09-04 06:30:14 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # ARI image file name\n2013-09-04 06:30:14 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # AKI image file name\n2013-09-04 06:30:14 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # ssh username for the image file\n2013-09-04 06:30:14 ssh_user = cirros\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 # specifies how many resources to request at once. Used for large operations\n2013-09-04 06:30:14 # testing.\"\n2013-09-04 06:30:14 large_ops_number = 0\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [cli]\n2013-09-04 06:30:14 # Enable cli tests\n2013-09-04 06:30:14 enabled = True\n2013-09-04 06:30:14 # directory where python client binaries are located\n2013-09-04 06:30:14 cli_dir = /usr/local/bin\n2013-09-04 06:30:14 # Number of seconds to wait on a CLI timeout\n2013-09-04 06:30:14 timeout = 15\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [service_available]\n2013-09-04 06:30:14 # Whether or not cinder is expected to be available\n2013-09-04 06:30:14 cinder = True\n2013-09-04 06:30:14 # Whether or not neutron is expected to be available\n2013-09-04 06:30:14 neutron = False\n2013-09-04 06:30:14 # Whether or not glance is expected to be available\n2013-09-04 06:30:14 glance = True\n2013-09-04 06:30:14 # Whether or not swift is expected to be available\n2013-09-04 06:30:14 swift = True\n2013-09-04 06:30:14 # Whether or not nova is expected to be available\n2013-09-04 06:30:14 nova = True\n2013-09-04 06:30:14 # Whether or not Heat is expected to be available\n2013-09-04 06:30:14 heat = True\n2013-09-04 06:30:14 # Whether or not horizon is expected to be available\n2013-09-04 06:30:14 horizon = True\n2013-09-04 06:30:14 \n2013-09-04 06:30:14 [stress]\n2013-09-04 06:30:14 # Maximum number of instances to create during test\n2013-09-04 06:30:14 max_instances = 32\n2013-09-04 06:30:14 # Time (in seconds) between log file error checks\n2013-09-04 06:30:14 log_check_interval = 60\n2013-09-04 06:30:14 # The default number of threads created while stress test\n2013-09-04 06:30:14 default_thread_number_per_action=4\n2013-09-04 06:30:14 ++ IFS=\' 	\n2013-09-04 06:30:14 \'\n2013-09-04 06:30:14 ++ set +o errexit\n2013-09-04 06:30:14 ++ init_tempest\n2013-09-04 06:30:14 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-04 06:30:14 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-04 06:30:14 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-04 06:30:14 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-04 06:30:14 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n\n\n\nHorizon is now available at http://127.0.0.1/\nHeat has replaced the default flavors. View by running: nova flavor-list\nKeystone is serving at http://127.0.0.1:5000/v2.0/\nExamples on using novaclient command line is in exercise.sh\nThe default users are: admin and demo\nThe password: secret\nThis is your host ip: 10.6.76.129\nRemoving sudo privileges for devstack user\nRunning stress tests\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1666.gcfa91fb.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-209475-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-209475.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-209475/16/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1346642417.18.1377939616097.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1029607256.9197253.1390411044993.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 12:17:24',-18000,'2014-01-22 17:17:24',NULL,'[openstack-dev] [TripleO] our update story: can people live with it?','I\'ve been thinking a bit more about how TripleO updates are developing specifically with regards to compute nodes. What is commonly called the \"update story\" I think.\n\nAs I understand it we expect people to actually have to reboot a compute node in the cluster in order to deploy an update. This really worries me because it seems like way overkill for such a simple operation. Lets say all I need to deploy is a simple change to Nova\'s libvirt driver. And I need to deploy it to *all* my compute instances. Do we really expect people to actually have to reboot every single compute node in their cluster for such a thing. And then do this again and again for each update they deploy?\n\nI understand the whole read only images thing plays into this too... but I\'m wondering if there is a middle ground where things might work better. Perhaps we have a mechanism where we can tar up individual venvs from /opt/stack/ or perhaps also this is an area where real OpenStack packages could shine. It seems like we could certainly come up with some simple mechanisms to deploy these sorts of changes with Heat such that compute host reboot can be avoided for each new deploy.\n\nDan\n\n\n','<1704606429.9169502.1390410147720.JavaMail.root@redhat.com>',NULL),('<1029655480.3750642.1351320638303.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-26 23:50:38',-25200,'2012-10-27 06:50:38',NULL,'[openstack-dev] [Quantum][LBaaS] LBaaS API 1.0 spec draft','Youcef - this looks very extensive; thanks for the effort here... We will review and get back the list with comments. \n\n-Serge \n\n----- Original Message -----\n\nFrom: \"Youcef Laribi\" <Youcef.Laribi at eu.citrix.com> \nTo: \"Sachin Thakkar\" <sthakkar at vmware.com>, \"Serge Maskalik\" <smaskalik at vmware.com>, \"Eugene Nikanorov\" <enikanorov at mirantis.com>, \"Ilya Shakhat\" <ishakhat at mirantis.com>, \"Samuel Bercovici\" <SamuelB at radware.com>, \"Rudra Rugge\" <rrugge at vmware.com>, \"Alex Gosse\" <Alex.Gosse at riverbed.com>, \"Leon Cui\" <lcui at vmware.com>, \"Brent Busby\" <bbusby at ebay.com>, \"Kobi Samoray\" <KobiS at radware.com>, \"Anand Palanisamy\" <apalanisamy at paypal.com>, \"John Gruber\" <J.Gruber at f5.com>, \"Chinmay Naik\" <cnaik at paypal.com>, \"Oleg Bondarev\" <obondarev at mirantis.com>, \"Eugene Kirpichev\" <ekirpichev at mirantis.com>, \"Roman Alekseenkov\" <ralekseenkov at mirantis.com>, \"Salvatore Orlando\" <sorlando at nicira.com>, \"Peter Mellquist\" <peter.mellquist at hp.com>, \"Dan Wendlandt\" <dan at nicira.com>, \"OpenStack Development Mailing List (openstack-dev at lists.openstack.org)\" <openstack-dev at lists.openstack.org> \nSent: Friday, October 26, 2012 8:03:19 PM \nSubject: [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft \n\n\n\nI have put a first draft of the LBaaS API on the wiki page http://wiki.openstack.org/Quantum/LBaaS/API_1.0 , so please have a look before next week?s meeting. There is still some work to be done on it, but the essential details to start the implementation should be there. \n\nThanks, \nYoucef \n\n\n\nFrom: Youcef Laribi \nSent: Friday, October 26, 2012 10:16 AM \nTo: \'Sachin Thakkar\' \nCc: Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan Wendlandt; Serge Maskalik \nSubject: RE: Specifying Tenant-ID in REST API URLs \n\nThanks Sachin for filing a blueprint for this! \n\n\n\nFrom: Sachin Thakkar [ mailto:sthakkar at vmware.com ] \nSent: Friday, October 26, 2012 10:06 AM \nTo: Youcef Laribi \nCc: Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan Wendlandt; Serge Maskalik \nSubject: Re: Specifying Tenant-ID in REST API URLs \n\n\nExcellent, thanks Youcef. I\'ve filed this blueprint for tracking purposes - https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant \n\n\n\nWhen we\'re ready we can formalize the wiki link, object model etc and fill in the specification section. For now, I\'ve simply pointed to the etherpad from the summit. \n\n\n\nAll, please feel free to join the bp. \n\n\n\nThanks, \n\nSachin \n\n\n\nFrom: \"Youcef Laribi\" < Youcef.Laribi at eu.citrix.com > \nTo: \"Serge Maskalik\" < smaskalik at vmware.com > \nCc: \"Eugene Nikanorov\" < enikanorov at mirantis.com >, \"Ilya Shakhat\" < ishakhat at mirantis.com >, \"Samuel Bercovici\" < SamuelB at radware.com >, \"Rudra Rugge\" < rrugge at vmware.com >, \"Alex Gosse\" < Alex.Gosse at riverbed.com >, \"Leon Cui\" < lcui at vmware.com >, \"Brent Busby\" < bbusby at ebay.com >, \"Kobi Samoray\" < KobiS at radware.com >, \"Anand Palanisamy\" < apalanisamy at paypal.com >, \"John Gruber\" < J.Gruber at f5.com >, \"Chinmay Naik\" < cnaik at paypal.com >, \"Oleg Bondarev\" < obondarev at mirantis.com >, \"Eugene Kirpichev\" < ekirpichev at mirantis.com >, \"Roman Alekseenkov\" < ralekseenkov at mirantis.com >, \"Salvatore Orlando\" < sorlando at nicira.com >, \"Peter Mellquist\" < peter.mellquist at hp.com >, \"Sachin Thakkar\" < sthakkar at vmware.com >, \"Dan Wendlandt\" < dan at nicira.com > \nSent: Friday, October 26, 2012 9:55:13 AM \nSubject: RE: Specifying Tenant-ID in REST API URLs \nSerge, \n\nI?m in the process of putting together the API spec by merging your API doc with mine, and following Quantum API style and naming conventions. Should be able to share something by the end of today. \n\nYoucef \n\n\n\nFrom: Serge Maskalik [ mailto:smaskalik at vmware.com ] \nSent: Thursday, October 25, 2012 10:15 PM \nTo: Youcef Laribi; Dan Wendlandt; Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Sachin Thakkar \nSubject: Re: Specifying Tenant-ID in REST API URLs \n\n\nFolks, \n\nI just wanted to get a sense on activity for next week\'s sync-up. Do we have the Blueprints started? If so, can folks respond with active Blueprint URLs. \n\nYoucef - how are the API definition going? Can you point to the latest, if possible? Thanks in advance. \n\n-Serge \n\n\n\nFrom: \"Youcef Laribi\" < Youcef.Laribi at eu.citrix.com > \nTo: \"Salvatore Orlando\" < sorlando at nicira.com >, \"Peter Mellquist\" < peter.mellquist at hp.com > \nCc: \"Dan Wendlandt\" < dan at nicira.com >, \"Eugene Nikanorov\" < enikanorov at mirantis.com >, \"Ilya Shakhat\" < ishakhat at mirantis.com >, \"Leon Cui\" < lcui at vmware.com >, \"Brent Busby\" < bbusby at ebay.com >, \"Kobi Samoray\" < KobiS at radware.com >, \"Anand Palanisamy\" < apalanisamy at paypal.com >, \"John Gruber\" < J.Gruber at f5.com >, \"Samuel Bercovici\" < SamuelB at radware.com >, \"Rudra Rugge\" < rrugge at vmware.com >, \"Alex Gosse\" < Alex.Gosse at riverbed.com >, \"Serge Maskalik\" < smaskalik at vmware.com >, \"Chinmay Naik\" < cnaik at paypal.com >, \"Oleg Bondarev\" < obondarev at mirantis.com >, \"Eugene Kirpichev\" < ekirpichev at mirantis.com >, \"Roman Alekseenkov\" < ralekseenkov at mirantis.com > \nSent: Thursday, October 25, 2012 4:45:46 PM \nSubject: RE: Specifying Tenant-ID in REST API URLs \nThanks Salvatore. \n\nSo Peter, an admin role should be able to access any tenant?s resources by simply using the query string filtering mechanism of the API: \n\nGET /v2.0/vips?tenant_id= 100 (with keystone auth middleware returning tenant_id= 456 , role= admin ) \n\nThis should return the vips of tenant_id 100 even though the caller is actually tenant 456 (who has an admin role). If tenant 456 wasn?t an admin, I suspect he would get an ?empty? result, rather than the usual ?401 Unauthorized? error (that would be the only slight downside to this). \n\nAre we then comfortable with removing the tenant_id from the URLs? \n\nYoucef \n\n\nFrom: Salvatore Orlando [ mailto:sorlando at nicira.com ] \nSent: Thursday, October 25, 2012 4:22 PM \nTo: Youcef Laribi \nCc: Dan Wendlandt; Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov \nSubject: Re: Specifying Tenant-ID in REST API URLs \n\nYes it is correct. \n\nThe default behaviour is that each tenant will get its own object only, unless it is an administrator, in which case it will get all objects. \n\nThis behaviour is actually not enforced by the policy engine, but hardcoded in the db management logic. \n\n\n\nThe policy engine however regulates details such as \"shared\" and \"external\" networks. What you find in policy.json is a default set of policies that you can customize according to your needs; for instance you can specify more roles. \n\nPolicy.json also controls who can perform some operations; as an example the creation of \"shared\" and \"external\" networks is reserved to admins only by default, but you can allow any tenant, or a specific group of tenants, to perform this operations, just by editing the file (you won\'t even need to restart Quantum). \n\n\n\nSalvatore \n\n\n\nOn 26 October 2012 00:16, Youcef Laribi < Youcef.Laribi at eu.citrix.com > wrote: \nSo if I understood the code correctly, in Quantum, there are 2 basic roles: \n\n1. Admin \n2. Normal \n\nIf the user making the request has an \"admin\" role (according to the keystone token in the request header), then when he issues a Quantum API request like: \n\nGET /v2.0/networks \n\nHe will get all the networks of all the tenants. \n\nIf however, the user doesn\'t have an \"admin\" role (normal user), then he will get only his own networks for the same call (the result is filtered). \n\nIs my understanding correct? \n\nYoucef \n\n\n\n\n-----Original Message----- \nFrom: Dan Wendlandt [mailto: dan at nicira.com ] \nSent: Thursday, October 25, 2012 3:38 PM \nTo: Youcef Laribi \nCc: Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov \nSubject: Re: Specifying Tenant-ID in REST API URLs \n\nOn Thu, Oct 25, 2012 at 3:25 PM, Youcef Laribi < Youcef.Laribi at eu.citrix.com > wrote: \n> Yes, they would be. For the sake of consistency I prefer the LBaaS \n> APIs to use a same style and conventions as the Quantum APIs if \n> possible. So, I?m waiting to hear clarifications from Dan or Salvatore \n> on how authorization is handled in Quantum without the tenant-id being in the URL. \n\nHere\'s the standard auth.py code that grabs keystone info from the headers and puts it in the context object: \n\nhttps://github.com/openstack/quantum/blob/master/quantum/auth.py \n\nThis is then returned whenever the context of a request is asked for: \n\nhttps://github.com/openstack/quantum/blob/master/quantum/api/v2/resource.py#L43 \n\nThis context object is then used in validation methods in https://github.com/openstack/quantum/blob/master/quantum/api/v2/base.py \nas well as passed to all plugin methods: \n\nhttps://github.com/openstack/quantum/blob/master/quantum/quantum_plugin_base_v2.py \n\nDan \n\n\n> \n> \n> \n> Youcef \n> \n> \n> \n> From: Mellquist, Peter [mailto: peter.mellquist at hp.com ] \n> Sent: Thursday, October 25, 2012 3:17 PM \n> \n> \n> To: Youcef Laribi; Eugene Nikanorov \n> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt; \n> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex \n> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg \n> Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: RE: Specifying Tenant-ID in REST API URLs \n> \n> \n> \n> Yes this is the question. \n> \n> \n> \n> I am assuming our data model will have resources contained by tenants \n> like you did within Atlas and is common across Openstack. \n> \n> \n> \n> Peter. \n> \n> \n> \n> From: Youcef Laribi [mailto: Youcef.Laribi at eu.citrix.com ] \n> Sent: Thursday, October 25, 2012 2:47 PM \n> To: Mellquist, Peter; Eugene Nikanorov \n> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt; \n> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex \n> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg \n> Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: RE: Specifying Tenant-ID in REST API URLs \n> \n> \n> \n> Peter, \n> \n> \n> \n> Agree. Hence my earlier question to the Quantum people of how they \n> handle Authorization with the absence of ?tenant-id? from the URL for \n> your exact scenario (e.g. admin role finding out the networks of tenant A). \n> \n> \n> \n> Youcef \n> \n> \n> \n> From: Mellquist, Peter [mailto: peter.mellquist at hp.com ] \n> Sent: Thursday, October 25, 2012 2:41 PM \n> To: Youcef Laribi; Eugene Nikanorov \n> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt; \n> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex \n> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg \n> Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: RE: Specifying Tenant-ID in REST API URLs \n> \n> \n> \n> Hi, \n> \n> \n> \n> My point was only to ensure we allow a way to achieve cross tenant \n> access for an admin role. Normally, the Keystone tenantId must match \n> the tenantId in the resource being accessed but for admin roles the \n> keystone tenantId has scope to access all tenants. For example in the \n> Atlas style, for logical load balancers which are owned by the tenant \n> they are not shared unless you have special authorization, like an administrator. \n> \n> \n> \n> Examples: \n> \n> GET /v2/100/loadbalancers ( with keystone auth middleware returning \n> tenantId=100 ) \n> \n> This would be authorized , 100 can access 100?s resources \n> \n> \n> \n> GET /v2/101/loadbalancers ( with keystone auth middleware returning \n> tenantId=100 ) \n> \n> Not authorized, 100 cannot access 101?s resources \n> \n> \n> \n> GET /v2/100/loadbalancers ( with keystone auth middleware returning \n> tenantId=200 , role = admin) \n> \n> Authorized, 200 is admin \n> \n> \n> \n> If you drop the tenantId in the URI you have.. \n> \n> GET /V2/loadbalancers ( with keystone auth middleware returning \n> tenantId=100 , so you can only access 100?s resources) \n> \n> If I am the admin and I need to access a tenants LBs how is this done? \n> \n> \n> \n> Here is a good paper on the topic : \n> \n> https://github.com/RackerWilliams/multi-tenant-accounting/blob/master/ \n> tenants.pdf?raw=true \n> \n> \n> \n> \n> \n> Peter. \n> \n> \n> \n> \n> \n> From: Youcef Laribi [mailto: Youcef.Laribi at eu.citrix.com ] \n> Sent: Thursday, October 25, 2012 11:42 AM \n> To: Eugene Nikanorov; Mellquist, Peter \n> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt; \n> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex \n> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg \n> Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: RE: Specifying Tenant-ID in REST API URLs \n> \n> \n> \n> Peter, Eugene, \n> \n> \n> \n> Changing to the subject to a more appropriate title. \n> \n> \n> \n> Just for information, Quantum changed its API style between 1.0 \n> version (which had tenant-id in the URL, like the rest of OpenStack \n> APIs) and the \n> 2.0 version (which doesn?t): \n> \n> \n> \n> Quantum API 1.0: \n> http://docs.openstack.org/api/openstack-network/1.0/content/index.html \n> \n> Quantum API 2.0: \n> http://docs.openstack.org/api/openstack-network/2.0/content/index.html \n> \n> \n> \n> Can somebody from the Quantum team (Dan or Salvatore) explain the \n> reasoning behind the change and how is Authorization handled in 2.0 vs. 1.0? \n> \n> \n> \n> Thanks \n> \n> Youcef \n> \n> \n> \n> From: Eugene Nikanorov [mailto: enikanorov at mirantis.com ] \n> Sent: Thursday, October 25, 2012 10:52 AM \n> To: Mellquist, Peter \n> Cc: Ilya Shakhat; Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray; \n> Dan Wendlandt; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra \n> Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; \n> Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: Re: ?? : Questions to REST API proposal \n> \n> \n> \n> Hi Peter, \n> \n> \n> \n>> With Keystone middleware the requestors tenantId is injected in the \n>> headers of the request, so the API server can see the tenant of the \n>> client making the request. \n> \n> That\'s correct. That will be used to make authorization decision \n> (whether tenant can access the resource) \n> \n> \n> \n>> For example, If I am the admin of the LB then my tenant may have \n>> access to all LBs. \n> \n> I think we want it in a bit different way: LBs as a devices may be \n> shared \n> (hardware) or private (VMs). \n> \n> LB (VIP, In our new API terminology) deployed on hardware device \n> should be accessed only from the tenant that have deployed it. VIP \n> deployed on the shared device are visible to provider, but tenant sees \n> only those VIPs that it has deployed. \n> \n> If tenant creates it\'s own private device (by launching VM with, say, \n> HAProxy), other tenants can\'t deploy VIPs on that device and can\'t see \n> neither device itself nor VIP deployed on it. \n> \n> \n> \n> Are there reasons to make lbaas API in different style from the Core \n> Quantum API v2.0? \n> \n> \n> \n> Thanks, \n> \n> Eugene. \n> \n> On Thu, Oct 25, 2012 at 8:45 PM, Mellquist, Peter \n> < peter.mellquist at hp.com > \n> wrote: \n> \n> Hi Eugene, \n> \n> \n> \n> With Keystone middleware the requestors tenantId is injected in the \n> headers of the request, so the API server can see the tenant of the \n> client making the request. The middleware resolves a token or signed \n> request to this tenant. Getting rid of the tenantId from the URI will \n> not allow cross tenant access. For example, If I am the admin of the \n> LB then my tenant may have access to all LBs. Also, most all of the \n> other OS APIs have tenant in the URI as resources are organized by tenant. \n> \n> \n> \n> Peter. \n> \n> \n> \n> From: Eugene Nikanorov [mailto: enikanorov at mirantis.com ] \n> Sent: Thursday, October 25, 2012 3:38 AM \n> To: Ilya Shakhat \n> Cc: Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray; Dan \n> Wendlandt; Palanisamy, Anand; John Gruber; Mellquist, Peter; Samuel \n> Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; \n> Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> Subject: Re: ?? : Questions to REST API proposal \n> \n> \n> \n> Folks, \n> \n> \n> \n> I suggest we stick with v2.0 style of calls, where there is no /tenants/XYZ. \n> \n> Our current vision is that API calls should look like following: \n> \n> \n> \n> /v2.0/balancer/lbaas/vips.json?param1=value1&param2=value2 \n> \n> /v2.0/balancer/lbaas/vips/{vip_id}.json?param1=value1&param2=value2 \n> \n> \n> \n> where: \n> \n> - balancer - type of advanced service within quantum \n> \n> - lbaas - particular implementation of service \"balancer\" \n> \n> - flat resource API, like in quantum API v2.0 \n> \n> \n> \n> Additional parameters like tenant_id, lb id, etc, are provided in \n> parameters. \n> \n> If we\'re talking about id of resource being accessed, that it is \n> provided in url, just like in current quantum API, e.g. \n> \n> \n> \n> .../vips/{vip_id}.json?... - for operations on particular vip. \n> \n> \n> \n> Thanks, \n> \n> Eugene. \n> \n> On Thu, Oct 25, 2012 at 2:20 PM, Ilya Shakhat < ishakhat at mirantis.com > wrote: \n> \n> One point for flat URL structure is simplicity of search operations. \n> The use \n> case: \n> \n> * tenant have a large number of back-end servers deployed on several \n> load-balancers; \n> \n> * there is a monitoring system that reports only host-name of \n> back-end; \n> \n> * users needs to put back-end server out of service. \n> \n> In case of flat addressing, user can find backend id by query like \n> this: GET /lbaas/v1.0/tenants/1000/members?name=backendname \n> \n> But if addressing is hierarchical, then he needs to iterate all pools. \n> \n> \n> \n> Thanks, \n> \n> Ilya \n> \n> \n> \n> 2012/10/25 Leon Cui < lcui at vmware.com > \n> \n> Hi Youcef, \n> \n> Both ways looks not good enough in my perspective. The \n> Atlas/Equilibrium style is too deep in hierarchy while the Quantum \n> style is a bit too flat. I think we may consider the following principles in API design: \n> \n> 1. ?part-of? relationship between objects. If object B is ?part of? \n> object A, then the url hierarchy may look like /A/B. \n> \n> 2. Object reuse. Can an object reused by multiple objects? If object \n> B can be referred by both A1 and A2, then B probably should be in the \n> same url level as A. For instance, in our design, do we prevent a \n> pool shared by multiple VIPs? If not, Pool should be in the same url \n> level as VIP. It?s the same for HealthMonitor object. A HealthMonitor \n> object should be able to bind to multiple pools (implicitly there will \n> be multiple healthMonitor instances created and bound to each pool member). \n> \n> \n> \n> Not sure if we have the same understanding against the healthMonitor \n> concept. A healthMonitor object defines a type of monitor (e.g. \n> TCP/HTTP/HTTPS) with generic settings (e.g. interval, timeout). When \n> a healthMonitor is bound to a pool, the LBaaS system will implicitly \n> create a healthMonitorInstance object for each pool member, and by \n> default use the ipAddress/port of the pool member. I believe this is \n> how F5 Big-IP monitor is defined and we may follow this practice. \n> \n> \n> \n> So my suggest would be, assuming all vips/pools/healthmonitors should \n> be only in a single tenant scope, then the following URLs should be used: \n> \n> /lbaas/v1.0/tenants \n> \n> /lbaas/v1.0/tenants/1000/vips \n> \n> /lbaas/v1.0/tenants/1000/pools \n> \n> /lbaas/v1.0/tenants/1000/healthmonitors \n> \n> /lbaas/v1.0/tenants/1000/pools/1/members \n> \n> \n> \n> Please let me know your thoughts. \n> \n> \n> \n> Thanks \n> \n> Leon \n> \n> ??? : Youcef Laribi [mailto: Youcef.Laribi at eu.citrix.com ] \n> ???? : 2012 ? 10 ? 25 ? 9:02 \n> ??? : Leon Cui; \'Busby, Brent\'; \'Ilya Shakhat\' \n> ?? : \'Kobi Samoray\'; \'Dan Wendlandt\'; \'Palanisamy, Anand\'; \'John \n> Gruber\'; \'Peter Mellquist\'; \'Samuel Bercovici\'; \'Rudra Rugge\'; \'Alex \n> Gosse\'; \'Serge Maskalik\'; \'Naik, Chinmay\'; \'Salvatore Orlando\'; \n> \'Eugene Nikanorov\'; \'Oleg Bondarev\'; \'Eugene Kirpichev\'; \'Roman Alekseenkov\' \n> ? ? : RE: Questions to REST API proposal \n> \n> \n> \n> Both are valid ways of expressing the resource model but the payloads \n> for the objects would be different in each case. \n> \n> \n> \n> If we take the Atlas/Equilibrium style, where the context is implied \n> from the URL: \n> \n> \n> \n> http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members \n> \n> \n> \n> Here, we know we are talking about the members of pool 1 which \n> belongs to vip 4 of tenant 1000. There is an implied hierarchy by just \n> looking at the URL. When we create a member, the payload doesn?t need \n> to specify the vip, the pool and the tenant, since these are already \n> specified in the URL (and you can only create members through these \n> form of URLs). So, a member payload here could be: \n> \n> \n> \n> { \n> \n> \"member\": { \n> \n> \"address\": \"192.168.130.51\", \n> \n> \"port\" : 80, \n> \n> \"connectionlimit\": 500, \n> \n> \"weight\" : 2 \n> \n> \"adminState\" : \"ENABLED\" \n> \n> } \n> \n> } \n> \n> \n> \n> Also, the IDs of members can be relative to pools, they don?t need to \n> be unique across pools and across vips and tenants (although you can \n> create unique ones in any case). \n> \n> \n> \n> If we take however the Quantum style, where objects are defined at the \n> top-level, then we need to create a member like this: \n> \n> \n> \n> POST http://lbaas-service/lbaas/v1.0/members \n> \n> \n> \n> { \n> \n> \"member\": { \n> \n> \"tenant-id\" : \"1000\", \n> \n> \"vip-id\" : \"4\", \n> \n> \"pool-id\" : \"1\", \n> \n> \"address\": \"192.168.130.51\", \n> \n> \"port\" : 80, \n> \n> \"connectionlimit\": 500, \n> \n> \"weight\" : 2 \n> \n> \"adminState\" : \"ENABLED\" \n> \n> } \n> \n> } \n> \n> \n> \n> \n> \n> Here we needed to specify all the information that was implied before \n> from the URL, and these attributes are required each time we need to \n> create a member. \n> \n> \n> \n> The advantage of the Quantum-style approach, is you can list all \n> members regardless of which vips, pools or tenants they belong to, by \n> simply doing the following: \n> \n> \n> \n> GET http://lbaas-service/lbaas/v1.0/members \n> \n> \n> \n> This is especially useful for admin roles, where you want to list all \n> vips or all pools regardless of their containing object. This is hard \n> to do in Atlas/Equilibrium style (unless you have a convention that \n> can substitute an ID in the URL with a wildcard). \n> \n> \n> \n> If however, you want to find out the members of pool 4 in vip 1 in \n> Quantum style, then you have to use a query string style of filtering: \n> \n> \n> \n> GET http://lbaas-service/lbaas/v1.0/members?vip-id=1&pool-id=4 \n> \n> \n> \n> In Atlas/Equilibrium, this would simply be: \n> \n> \n> \n> GET \n> http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members \n> \n> \n> \n> So, both approaches are valid (although with the Quantum style, you \n> can do arbitrary filtering on attributes). \n> \n> \n> \n> I think we should adopt the same API style between Quantum and LBaaS, \n> otherwise it will be confusing for people using the API. \n> \n> \n> \n> Youcef \n> \n> \n> \n> From: Leon Cui [mailto: lcui at vmware.com ] \n> Sent: Wednesday, October 24, 2012 4:42 PM \n> To: \'Busby, Brent\'; \'Ilya Shakhat\'; Youcef Laribi \n> Cc: \'Kobi Samoray\'; \'Dan Wendlandt\'; \'Palanisamy, Anand\'; \'John \n> Gruber\'; \'Peter Mellquist\'; \'Samuel Bercovici\'; \'Rudra Rugge\'; \'Alex \n> Gosse\'; \'Serge Maskalik\'; \'Naik, Chinmay\'; \'Salvatore Orlando\'; \n> \'Eugene Nikanorov\'; \'Oleg Bondarev\'; \'Eugene Kirpichev\'; \'Roman Alekseenkov\' \n> Subject: ?? : Questions to REST API proposal \n> \n> \n> \n> I agree with Busby that sometimes we need this ?as-part-of? relationship. \n> Pool:member is a good example. \n> \n> \n> \n> The top class objects should be defined independently and between \n> them, the relationship is much like ?association? which is defined by \n> referring to the objectId. In current LBaaS model, those top objects \n> would be VIP, Pool, HealthMonitor. We should define CRUD APIs for each top objects by root path: \n> \n> /loadbalancer/vips \n> \n> /loadbalancer/pools \n> \n> /loadbalancer/healthmonitors \n> \n> \n> \n> In my perspective, member is not a top class object because it?s only \n> meaningful only if it belong to a pool. The path for members should be: \n> \n> /loadbalancer/pools/members \n> \n> \n> \n> Thanks \n> \n> Leon \n> \n> ??? : Busby, Brent [mailto: bbusby at ebay.com ] \n> ???? : 2012 ? 10 ? 25 ? 0:25 \n> ??? : Ilya Shakhat; Youcef Laribi \n> ?? : Kobi Samoray; Dan Wendlandt; Palanisamy, Anand; John Gruber; Peter \n> Mellquist; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Serge \n> Maskalik; Naik, Chinmay; Salvatore Orlando; Eugene Nikanorov; Oleg \n> Bondarev; Eugene Kirpichev; Roman Alekseenkov \n> ? ? : Re: Questions to REST API proposal \n> \n> \n> \n> For #1 ? Sometimes the relationship between pool and member defines \n> the member. \n> \n> For example: on a netscaler health monitors are bound at the service \n> level, which is the member in this API. If the user defines the \n> health monitors at the pool level, then we need to know what members \n> are part of the pool to bind the health monitor to all pool members. \n> Additional health monitors can be bound to the member individually, \n> but it\'s membership in the pool means that it must also have the \n> pool\'s health monitors bound. Should we show monitors bound to the pool when listing just the member independently? \n> Should we allow the user to remove the health monitors bound to the \n> member via pool membership? \n> \n> \n> \n> There are probably other examples where member inherits some trait \n> from the pool, but this is just the first example that popped in me head. \n> \n> \n> \n> ________________________________ \n> \n> M. Brent Busby \n> \n> eBay, Inc. \n> \n> 602-316-8599 \n> \n> \n> \n> From: Ilya Shakhat < ishakhat at mirantis.com > \n> Date: Wednesday, October 24, 2012 4:17 AM \n> To: Youcef Laribi < Youcef.Laribi at eu.citrix.com > \n> Cc: Kobi Samoray < KobiS at radware.com >, \"M. Brent Busby\" \n> < bbusby at ebay.com >, Dan Wendlandt < dan at nicira.com >, \"Palanisamy, Anand\" \n> < apalanisamy at paypal.com >, John Gruber < J.Gruber at F5.com >, Peter \n> Mellquist < peter.mellquist at hp.com >, Samuel Bercovici \n> < SamuelB at Radware.com >, Rudra Rugge < rrugge at vmware.com >, Alex Gosse \n> < Alex.Gosse at riverbed.com >, Leon Cui < lcui at vmware.com >, Serge Maskalik < smaskalik at vmware.com >, \"Naik, Chinmay\" \n> < cnaik at paypal.com >, Salvatore Orlando < sorlando at nicira.com >, Eugene \n> Nikanorov < enikanorov at mirantis.com >, Oleg Bondarev \n> < obondarev at mirantis.com >, Eugene Kirpichev < ekirpichev at mirantis.com >, \n> Roman Alekseenkov < ralekseenkov at mirantis.com > \n> Subject: Questions to REST API proposal \n> \n> \n> \n> Hi Youcef, \n> \n> \n> \n> We have some questions on REST API discussion. \n> \n> \n> \n> 1) In Quantum API all objects \"live\" independently, even if they \n> depend on each other (like subnet and network). List of subnets can be \n> queried by request \'/v2.0/subnets\' and network_id is optional \n> parameter to request. In LBaaS we had a different style, and dependent \n> objects were accessible by sub-path (loadbalancers/loadbalancer-id/nodes). \n> \n> From our perspective \"plain\" style is more preferable, since it would \n> be easier for client to access object by its id only and parent id is \n> superfluous. If needed the parent id may be set as filter (HTTP parameter). \n> For example, we propose to change: \n> \'/vips/{vipId}/pools/{poolId}/members/{memberId}\' -> \'/members/{memberId}\'. \n> \n> \n> \n> 2) In VIP we have attribute \'networkId\'. It allows LBaaS to create IP \n> address in the specified network, so the user doesn\'t need to do it \n> separately. I see how this will work for HW LB, but how will this work \n> for virtual? If virtual LB is created by user, then user may decide to \n> keep it accessible internal (=leave IP provided by Nova), or make it \n> external (=associate FIP). So in that case LBaaS needs to deal with \n> Quantum Port rather than with Quantum Network object. What do you think about this? \n> \n> \n> \n> 3) For some items we need a way to provide extra parameters, for \n> example \'sessionPersistence\' may have parameter \'http_header_name\'. \n> How will we store them? As json-object under \'extra\' attribute? \n> \n> \n> \n> Thanks, \n> \n> Ilya \n> \n> \n> \n> \n> \n> \n\n\n\n-- \n~~~~~~~~~~~~~~~~~~~~~~~~~~~ \nDan Wendlandt \nNicira, Inc: www.nicira.com \ntwitter: danwendlandt \n~~~~~~~~~~~~~~~~~~~~~~~~~~~ \n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121026/bad7f318/attachment-0001.html>\n\n','<7B14C05615DB43488B85E143995BD54901081F7C8DE8@LONPMAILBOX01.citrite.net>',NULL),('<1030552520.29.1380089143828.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-25 06:05:43',0,'2013-09-25 06:05:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #27','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 7413 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py\",> line 2124, in _parse_cli_opts\n    opt._add_to_cli(self._oparser, group)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py\",> line 1018, in _add_to_cli\n    self.handler(subparsers)\n  File \"./bin/glance-control\", line 274, in add_command_parsers\n    parser = subparsers.add_parser(server, parents=[cmd_parser])\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/argparse.py\",> line 1085, in add_parser\n    parser = self._parser_class(**kwargs)\nTypeError: __init__() got an unexpected keyword argument \'parents\'\n\n\nCONTEXT: ==Core config==\n[DEFAULT]\nverbose = True\ndebug = True\nbind_host = 127.0.0.1\nbind_port = 58682\nlog_file = /tmp/tmp.AhUwEXYayR/tmpe2wyMr/registry.log\ndb_auto_create = False\nsql_connection = sqlite://///tmp/tmp.AhUwEXYayR/tmpe2wyMr/tests.sqlite\nsql_idle_timeout = 3600\napi_limit_max = 1000\nlimit_param_default = 25\nowner_is_tenant = True\nworkers = 0\n[paste_deploy]\nflavor = \n\n==Paste config==\n[pipeline:glance-registry]\npipeline = unauthenticated-context registryapp\n\n[pipeline:glance-registry-fakeauth]\npipeline = fakeauth context registryapp\n\n[app:registryapp]\npaste.app_factory = glance.registry.api.v1:API.factory\n\n[filter:context]\npaste.filter_factory = glance.api.middleware.context:ContextMiddleware.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory =\n glance.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:fakeauth]\npaste.filter_factory = glance.tests.utils:FakeAuthMiddleware.factory\n\n\n======================================================================\nERROR: glance.tests.functional.test_sqlite.TestSqlite.test_big_int_mapping\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 105, in _runner\n    func(*args, **kw)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_sqlite.py\",> line 33, in test_big_int_mapping\n    self.start_servers(**self.__dict__.copy())\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 645, in start_servers\n    **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 612, in start_with_retry\n    **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 143, in start\n    context=overridden)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 198, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command ./bin/glance-control --pid-file=/tmp/tmp.AhUwEXYayR/tmpuwgq1x/registry.pid --capture-output registry start /tmp/tmp.AhUwEXYayR/tmpuwgq1x/etc/registry.conf did not succeed. Returned an exit code of 1.\n\nSTDOUT: \n\nSTDERR: Traceback (most recent call last):\n  File \"./bin/glance-control\", line 312, in <module>\n    config.parse_args(usage=USAGE)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/config.py\",> line 98, in parse_args\n    default_config_files=default_config_files)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py\",> line 1625, in __call__\n    else sys.argv[1:])\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py\",> line 2124, in _parse_cli_opts\n    opt._add_to_cli(self._oparser, group)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py\",> line 1018, in _add_to_cli\n    self.handler(subparsers)\n  File \"./bin/glance-control\", line 274, in add_command_parsers\n    parser = subparsers.add_parser(server, parents=[cmd_parser])\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/argparse.py\",> line 1085, in add_parser\n    parser = self._parser_class(**kwargs)\nTypeError: __init__() got an unexpected keyword argument \'parents\'\n\n\nCONTEXT: ==Core config==\n[DEFAULT]\nverbose = True\ndebug = True\nbind_host = 127.0.0.1\nbind_port = 41118\nlog_file = /tmp/tmp.AhUwEXYayR/tmpuwgq1x/registry.log\ndb_auto_create = False\nsql_connection = sqlite://///tmp/tmp.AhUwEXYayR/tmpuwgq1x/tests.sqlite\nsql_idle_timeout = 3600\napi_limit_max = 1000\nlimit_param_default = 25\nowner_is_tenant = True\nworkers = 0\n[paste_deploy]\nflavor = \n\n==Paste config==\n[pipeline:glance-registry]\npipeline = unauthenticated-context registryapp\n\n[pipeline:glance-registry-fakeauth]\npipeline = fakeauth context registryapp\n\n[app:registryapp]\npaste.app_factory = glance.registry.api.v1:API.factory\n\n[filter:context]\npaste.filter_factory = glance.api.middleware.context:ContextMiddleware.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory =\n glance.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:fakeauth]\npaste.filter_factory = glance.tests.utils:FakeAuthMiddleware.factory\n\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_api.TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1246, in test_unsupported_default_store\n    **self.__dict__.copy())\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 585, in start_server\n    self.assertTrue(re.search(\"Starting glance-[a-z]+ with\", out))\n  File \"/usr/lib64/python2.6/unittest.py\", line 324, in failUnless\n    if not expr: raise self.failureException, msg\nAssertionError\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 37.39 secs:\n    11.75    TestGlanceControl.test_respawn\n    11.71    TestGlanceControl.test_reload\n    5.51    TestMigrations.test_postgresql_opportunistically\n    4.35    TestMigrations.test_version_control_existing_db\n    4.06    TestMigrations.test_walk_versions\n----------------------------------------------------------------------\nRan 1101 tests in 215.751s\n\nFAILED (SKIP=38, errors=81, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.6\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.27\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.0\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=107\n+ \'[\' 107 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.AhUwEXYayR\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/27/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-3/27\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1030682480.11.1379485964261.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-18 06:32:44',0,'2013-09-18 06:32:44',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #18','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/18/>\n\n------------------------------------------\n[...truncated 18614 lines...]\n2013-09-18 06:25:33,506 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:33,527 Response Status: 200\n2013-09-18 06:25:33,527 Glance request id req-cf622ad1-67d5-408a-a11c-5e4cfce65c18\n2013-09-18 06:25:35,530 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:35,550 Response Status: 200\n2013-09-18 06:25:35,551 Glance request id req-ccb9e3c0-de20-4617-83e0-abc3480ed9c6\n2013-09-18 06:25:37,553 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:37,575 Response Status: 200\n2013-09-18 06:25:37,576 Glance request id req-62f1ec84-5687-4990-95aa-abcd3d846acc\n2013-09-18 06:25:39,578 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:39,605 Response Status: 200\n2013-09-18 06:25:39,605 Glance request id req-c4b819db-86c1-4385-a648-e1dc4a3f3290\n2013-09-18 06:25:41,608 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:42,740 Response Status: 200\n2013-09-18 06:25:42,740 Glance request id req-23fdc6ac-9348-48d7-be12-b9efe77dcb65\n2013-09-18 06:25:44,743 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:44,768 Response Status: 200\n2013-09-18 06:25:44,768 Glance request id req-07f498fd-d163-4d1e-a0e5-95625a205002\n2013-09-18 06:25:46,771 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:46,798 Response Status: 200\n2013-09-18 06:25:46,798 Glance request id req-78ca8183-c4b0-43b6-900d-2c9f64e9c6d3\n2013-09-18 06:25:48,801 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:48,830 Response Status: 200\n2013-09-18 06:25:48,830 Glance request id req-6b656075-6c54-4e9a-89e8-d8fb1fc859ad\n2013-09-18 06:25:50,833 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:50,865 Response Status: 200\n2013-09-18 06:25:50,866 Glance request id req-6b9923e3-dbdc-4fb0-ba98-7694765d6d53\n2013-09-18 06:25:52,868 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:52,899 Response Status: 200\n2013-09-18 06:25:52,899 Glance request id req-144af632-31d2-46fe-9d75-7f70b43f76c4\n2013-09-18 06:25:54,902 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:54,927 Response Status: 200\n2013-09-18 06:25:54,927 Glance request id req-16675765-21a7-43f2-871c-c4802c9fe92b\n2013-09-18 06:25:56,929 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:56,951 Response Status: 200\n2013-09-18 06:25:56,951 Glance request id req-66b2a8b8-0d9a-4122-b4ab-5b1122cb1260\n2013-09-18 06:25:58,954 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:25:58,978 Response Status: 200\n2013-09-18 06:25:58,979 Glance request id req-d258cdfc-c012-43fe-bd9e-cf35a0f66f28\n2013-09-18 06:26:00,981 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:01,009 Response Status: 200\n2013-09-18 06:26:01,009 Glance request id req-8d24de3f-e107-4648-a873-30815e78f1bf\n2013-09-18 06:26:03,012 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:03,033 Response Status: 200\n2013-09-18 06:26:03,033 Glance request id req-d23a6a9d-e685-452c-9ee8-c9708adb7e5d\n2013-09-18 06:26:05,036 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:05,064 Response Status: 200\n2013-09-18 06:26:05,064 Glance request id req-8c3d5118-9e47-4400-bedb-6d1c0554965e\n2013-09-18 06:26:07,067 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:07,088 Response Status: 200\n2013-09-18 06:26:07,088 Glance request id req-ee8d972c-5373-4e36-8814-9dc5596f3fb5\n2013-09-18 06:26:09,091 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:09,115 Response Status: 200\n2013-09-18 06:26:09,115 Glance request id req-8bbbaf6a-ade8-4c45-978f-9070f794d54c\n2013-09-18 06:26:11,118 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:11,144 Response Status: 200\n2013-09-18 06:26:11,144 Glance request id req-97f8c889-ac7b-484c-aa8e-665369a07a31\n2013-09-18 06:26:13,147 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:13,172 Response Status: 200\n2013-09-18 06:26:13,172 Glance request id req-7991280e-b35f-44a5-b594-48aa05295875\n2013-09-18 06:26:15,175 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:15,200 Response Status: 200\n2013-09-18 06:26:15,201 Glance request id req-95ac770a-5e16-4d64-accd-1040e28a6ae3\n2013-09-18 06:26:17,204 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:17,230 Response Status: 200\n2013-09-18 06:26:17,230 Glance request id req-9b96b935-1281-48ed-885f-3506c14e0285\n2013-09-18 06:26:19,233 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:19,252 Response Status: 200\n2013-09-18 06:26:19,253 Glance request id req-010aa572-b900-48d1-a8fe-599b0e68ff55\n2013-09-18 06:26:21,255 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:21,284 Response Status: 200\n2013-09-18 06:26:21,284 Glance request id req-2410e44f-21c6-4266-9c7a-a55c7bb28f45\n2013-09-18 06:26:23,287 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:23,312 Response Status: 200\n2013-09-18 06:26:23,313 Glance request id req-7e326d98-6114-4b66-8f94-102971812589\n2013-09-18 06:26:25,315 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:25,339 Response Status: 200\n2013-09-18 06:26:25,339 Glance request id req-f5c64626-0e54-4ac2-913d-d4fcee5d0bc9\n2013-09-18 06:26:27,342 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:27,364 Response Status: 200\n2013-09-18 06:26:27,364 Glance request id req-da274f94-2d78-4800-ba43-2e2d69ed3e25\n2013-09-18 06:26:29,367 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:29,398 Response Status: 200\n2013-09-18 06:26:29,398 Glance request id req-ca4795bb-4725-48cc-a441-ff291a8183b3\n2013-09-18 06:26:31,400 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:31,425 Response Status: 200\n2013-09-18 06:26:31,425 Glance request id req-e5148746-6af3-428f-865d-62115e1f4db5\n2013-09-18 06:26:33,428 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:33,455 Response Status: 200\n2013-09-18 06:26:33,455 Glance request id req-c763b6ae-751e-46c7-a7eb-44b434d5c0ea\n2013-09-18 06:26:35,458 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:35,484 Response Status: 200\n2013-09-18 06:26:35,484 Glance request id req-f7b55363-55bb-4339-9d6b-a1f1035e7fd9\n2013-09-18 06:26:37,487 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:37,510 Response Status: 200\n2013-09-18 06:26:37,510 Glance request id req-fe6bb38d-b4d3-4f55-81e0-5a0a2a055544\n2013-09-18 06:26:39,513 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:39,534 Response Status: 200\n2013-09-18 06:26:39,535 Glance request id req-bbeba765-6f48-45dc-aaa1-01f41408f8ec\n2013-09-18 06:26:41,536 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:41,560 Response Status: 200\n2013-09-18 06:26:41,560 Glance request id req-af4b9fb3-78de-4080-a868-e9d1b8feda51\n2013-09-18 06:26:43,563 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:43,587 Response Status: 200\n2013-09-18 06:26:43,588 Glance request id req-374c8e9e-5ae1-4729-9563-93de5682d454\n2013-09-18 06:26:45,590 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:45,614 Response Status: 200\n2013-09-18 06:26:45,614 Glance request id req-a482e336-e20b-43ec-ac25-f22e46ff6144\n2013-09-18 06:26:47,616 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:47,646 Response Status: 200\n2013-09-18 06:26:47,646 Glance request id req-5bfbb4d1-fa29-4b74-9614-4fa194fdfd4e\n2013-09-18 06:26:49,649 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:49,673 Response Status: 200\n2013-09-18 06:26:49,674 Glance request id req-03c4d8c1-665b-4727-a6eb-58d136b77084\n2013-09-18 06:26:51,676 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:51,703 Response Status: 200\n2013-09-18 06:26:51,704 Glance request id req-c6db2f04-c6bc-4f60-86f6-0c62e7ded520\n2013-09-18 06:26:53,706 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:53,728 Response Status: 200\n2013-09-18 06:26:53,728 Glance request id req-085184f5-80f6-4381-a404-fe4d5d9a45dc\n2013-09-18 06:26:55,731 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:55,750 Response Status: 200\n2013-09-18 06:26:55,751 Glance request id req-e5d273aa-8116-41b8-9d56-77ad231a3c82\n2013-09-18 06:26:57,752 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:57,771 Response Status: 200\n2013-09-18 06:26:57,772 Glance request id req-6aa95c84-8966-4702-91c1-8caba0756c5f\n2013-09-18 06:26:59,774 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:26:59,798 Response Status: 200\n2013-09-18 06:26:59,798 Glance request id req-97dad043-4682-425d-8981-c4b201511e5a\n2013-09-18 06:27:01,801 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:01,823 Response Status: 200\n2013-09-18 06:27:01,823 Glance request id req-90426cb1-7ac0-4415-828a-e6786a9fe982\n2013-09-18 06:27:03,826 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:03,849 Response Status: 200\n2013-09-18 06:27:03,850 Glance request id req-305cce25-7bb5-4672-9cff-4c97986cb3a9\n2013-09-18 06:27:05,851 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:05,878 Response Status: 200\n2013-09-18 06:27:05,878 Glance request id req-4898d1ef-8f51-41e1-a162-ada0ef289267\n2013-09-18 06:27:07,881 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:07,900 Response Status: 200\n2013-09-18 06:27:07,901 Glance request id req-382b57c5-1fc6-49ac-99cd-dd0466ad17f6\n2013-09-18 06:27:09,903 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:09,930 Response Status: 200\n2013-09-18 06:27:09,931 Glance request id req-55e98573-2f00-49f6-af6e-87297b6f43e2\n2013-09-18 06:27:11,933 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:11,970 Response Status: 200\n2013-09-18 06:27:11,971 Glance request id req-98b86396-4961-4eb5-a52a-79388f7ed592\n2013-09-18 06:27:13,974 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:14,000 Response Status: 200\n2013-09-18 06:27:14,001 Glance request id req-8844c240-9e6a-4a8d-beb2-708de1b0ea5d\n2013-09-18 06:27:16,003 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:16,029 Response Status: 200\n2013-09-18 06:27:16,030 Glance request id req-b5e943e8-2db5-4398-a7da-4f6b5154866d\n2013-09-18 06:27:18,032 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:18,066 Response Status: 200\n2013-09-18 06:27:18,067 Glance request id req-2d1b10fb-8cb3-433f-99b6-458ba5056ce0\n2013-09-18 06:27:20,070 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:20,096 Response Status: 200\n2013-09-18 06:27:20,096 Glance request id req-4c326324-1fbf-41a7-b02d-02405a2ecdec\n2013-09-18 06:27:22,099 Request: HEAD http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:22,123 Response Status: 200\n2013-09-18 06:27:22,123 Glance request id req-6c36fb95-f48c-4822-a818-f856ccc89a66\n2013-09-18 06:27:23,129 Request: DELETE http://127.0.0.1:9292/v1/images/5050a72f-e1a7-4291-ae0d-8c8603033ef9\n2013-09-18 06:27:23,197 Response Status: 200\n2013-09-18 06:27:23,197 Glance request id req-7e3acfad-cb20-43f6-b798-6334da524490\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/api/volume/test_volumes_actions.py\", line 112, in test_volume_upload\n    self.image_client.wait_for_image_status(image_id, \'active\')\n  File \"tempest/services/image/v1/json/image_client.py\", line 276, in wait_for_image_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Time Limit Exceeded! (400s)while waiting for active, but we got killed.\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2503 tests in 1454.075s\nFAILED (id=0, failures=2, skips=78)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-316123-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-316123.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-316123/18/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<954900102.6.1379313473452.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1030896658.326.1357090898693.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-02 01:41:38',0,'2013-01-02 01:41:38',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #55','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/55/>\n\n------------------------------------------\n[...truncated 15286 lines...]\ndate: Wed, 02 Jan 2013 01:37:23 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-49b58c12-65cc-4a64-91b7-578b6d1500aa\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wMlQwMTozNjoxOS40Mjk4NjIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTAzVDAxOjM2OjE5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAiaWQiOiAiZjI3YzY0MGUzMTE2NDMxZmI4ZjViYzExZmY2ZWIxYjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjOTZkN2UwMGJiNjg0NTgwOGRkZDcxODM0OThkZjYzNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiZDJkZDE1ZWE3MTdjNGU0M2JmMjE1YTNlMjVhZjJlZDciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJpZCI6ICJiMmQxYjU4OTZlZWM0MGJhYTVhMjgwZmI5ZWFhZmQ5ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxNmIyNWI1ODU5ZGM0NTI0OTY5NmUyMmNlZmM4NDc2NCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5IiwgImlkIjogImJmODI4Mzc3NWY1NDQzZmI5ZGY4NThlOWEyMDgxOGVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjk0YjdhZDBjMzdjYzRjMDNhODliOTUzM2U3MTg1MTMwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMWI5YWJkNTE4YTQ1NDgwMjhiZmZjMDBiMjEyMjlhZTIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDExMWVlODllN2U1NDdlYjhiOTE5YWVlZmM1NGYxNTIiLCAiOTZhYmRiMjFlODNlNGViZmE0ZDk5ZTE1ZGVlZGFmNjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBINR59PcTOkEsFp8dGXvnUe17dG5kYsiSQCV7PgNi8ScKPyf4WXD83+s6kuk21BHcODNbDDGaM1xv4dAxbjuX-ihvK8G79WOI34o4Jug-5b8oRvDAXtVq-3JjYkQMJTPPHaOU8SYoLQ2w80EmvRiprpD4J1wKf9lHr3pi+qx70cg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/d0d962c7-19ab-442b-a65b-c66c4c4f91aa\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 02 Jan 2013 01:37:25 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-50d70b37-6e3a-4383-85bf-b278588c0cc1\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wMlQwMTozNjoxOS40Mjk4NjIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTAzVDAxOjM2OjE5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAiaWQiOiAiZjI3YzY0MGUzMTE2NDMxZmI4ZjViYzExZmY2ZWIxYjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjOTZkN2UwMGJiNjg0NTgwOGRkZDcxODM0OThkZjYzNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiZDJkZDE1ZWE3MTdjNGU0M2JmMjE1YTNlMjVhZjJlZDciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJpZCI6ICJiMmQxYjU4OTZlZWM0MGJhYTVhMjgwZmI5ZWFhZmQ5ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxNmIyNWI1ODU5ZGM0NTI0OTY5NmUyMmNlZmM4NDc2NCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5IiwgImlkIjogImJmODI4Mzc3NWY1NDQzZmI5ZGY4NThlOWEyMDgxOGVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjk0YjdhZDBjMzdjYzRjMDNhODliOTUzM2U3MTg1MTMwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMWI5YWJkNTE4YTQ1NDgwMjhiZmZjMDBiMjEyMjlhZTIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDExMWVlODllN2U1NDdlYjhiOTE5YWVlZmM1NGYxNTIiLCAiOTZhYmRiMjFlODNlNGViZmE0ZDk5ZTE1ZGVlZGFmNjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBINR59PcTOkEsFp8dGXvnUe17dG5kYsiSQCV7PgNi8ScKPyf4WXD83+s6kuk21BHcODNbDDGaM1xv4dAxbjuX-ihvK8G79WOI34o4Jug-5b8oRvDAXtVq-3JjYkQMJTPPHaOU8SYoLQ2w80EmvRiprpD4J1wKf9lHr3pi+qx70cg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/002deecb-da5c-4375-aa1f-f24067464e4b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 02 Jan 2013 01:37:27 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-240be62f-44c0-404e-841a-573a23a7d63a\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wMlQwMTozNjoxOS40Mjk4NjIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTAzVDAxOjM2OjE5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAiaWQiOiAiZjI3YzY0MGUzMTE2NDMxZmI4ZjViYzExZmY2ZWIxYjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjOTZkN2UwMGJiNjg0NTgwOGRkZDcxODM0OThkZjYzNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiZDJkZDE1ZWE3MTdjNGU0M2JmMjE1YTNlMjVhZjJlZDciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJpZCI6ICJiMmQxYjU4OTZlZWM0MGJhYTVhMjgwZmI5ZWFhZmQ5ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxNmIyNWI1ODU5ZGM0NTI0OTY5NmUyMmNlZmM4NDc2NCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5IiwgImlkIjogImJmODI4Mzc3NWY1NDQzZmI5ZGY4NThlOWEyMDgxOGVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjk0YjdhZDBjMzdjYzRjMDNhODliOTUzM2U3MTg1MTMwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMWI5YWJkNTE4YTQ1NDgwMjhiZmZjMDBiMjEyMjlhZTIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDExMWVlODllN2U1NDdlYjhiOTE5YWVlZmM1NGYxNTIiLCAiOTZhYmRiMjFlODNlNGViZmE0ZDk5ZTE1ZGVlZGFmNjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBINR59PcTOkEsFp8dGXvnUe17dG5kYsiSQCV7PgNi8ScKPyf4WXD83+s6kuk21BHcODNbDDGaM1xv4dAxbjuX-ihvK8G79WOI34o4Jug-5b8oRvDAXtVq-3JjYkQMJTPPHaOU8SYoLQ2w80EmvRiprpD4J1wKf9lHr3pi+qx70cg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/bf28746a-7bc6-42bd-8e8c-da6a9090e9d4\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 02 Jan 2013 01:37:28 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-12aeba7b-e3ae-4d12-823e-3bfbce5acf32\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wMlQwMTozNjoxOS40Mjk4NjIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTAzVDAxOjM2OjE5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNTZjNzRhMjJlZGQ1NDllYjhkMzQwN2Q4MTM1MjgzODkiLCAiaWQiOiAiZjI3YzY0MGUzMTE2NDMxZmI4ZjViYzExZmY2ZWIxYjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjOTZkN2UwMGJiNjg0NTgwOGRkZDcxODM0OThkZjYzNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiZDJkZDE1ZWE3MTdjNGU0M2JmMjE1YTNlMjVhZjJlZDciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSIsICJpZCI6ICJiMmQxYjU4OTZlZWM0MGJhYTVhMjgwZmI5ZWFhZmQ5ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxNmIyNWI1ODU5ZGM0NTI0OTY5NmUyMmNlZmM4NDc2NCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzU2Yzc0YTIyZWRkNTQ5ZWI4ZDM0MDdkODEzNTI4Mzg5IiwgImlkIjogImJmODI4Mzc3NWY1NDQzZmI5ZGY4NThlOWEyMDgxOGVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81NmM3NGEyMmVkZDU0OWViOGQzNDA3ZDgxMzUyODM4OSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjk0YjdhZDBjMzdjYzRjMDNhODliOTUzM2U3MTg1MTMwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMWI5YWJkNTE4YTQ1NDgwMjhiZmZjMDBiMjEyMjlhZTIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDExMWVlODllN2U1NDdlYjhiOTE5YWVlZmM1NGYxNTIiLCAiOTZhYmRiMjFlODNlNGViZmE0ZDk5ZTE1ZGVlZGFmNjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBINR59PcTOkEsFp8dGXvnUe17dG5kYsiSQCV7PgNi8ScKPyf4WXD83+s6kuk21BHcODNbDDGaM1xv4dAxbjuX-ihvK8G79WOI34o4Jug-5b8oRvDAXtVq-3JjYkQMJTPPHaOU8SYoLQ2w80EmvRiprpD4J1wKf9lHr3pi+qx70cg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/6d0ab5a8-4b66-4680-a052-df3c80fb3ee7\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 02 Jan 2013 01:37:29 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-6c3d590f-efd0-4342-bd61-b6bb434a83ec\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\nAdd metadata to account ... ok\nDelete metadata from account ... ok\nList all account metadata ... ok\nList of all containers should not be empty ... ok\nUpdate/Retrieve/Delete Container Metadata ... ok\nCreate a container, test responses ... ok\nCreate and Delete a container, test responses ... ok\nAdd metadata to object ... ok\nGET object after expiry time ... SKIP: Until bug 1069849 is resolved.\nAttempt to access the object anonymously, e.g. ... ok\nMake container public-readable, and access the object ... ok\nCopy storage object ... ok\nCopy storage object across containers ... ok\nCopy storage object ... ok\nChange the content type of an existing object ... ok\nCreate storage object, test response ... ok\nCreate and delete a storage object, test responses ... ok\nAttempt to delete the object anonymously, ... ok\nRetrieve object\'s data(in response body) ... ok\nAdd metadata to storage object, test if metadata is retrievable ... ok\nAttempt to write to the object anonymously, e.g. ... ok\nVersioned container responses tests ... ok\nCreate/get/delete volume with volume_type and extra spec. ... ok\nCreate/Delete volume type. ... ok\nCreate/get volume type. ... ok\nList Volume types. ... ok\nCreate/Delete volume type extra spec. ... FAIL\nCreate/get volume type extra spec ... FAIL\nList Volume types extra specs. ... FAIL\nUpdate volume type extra specs ... FAIL\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nFAIL: Create/Delete volume type extra spec.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 91, in test_volume_type_extra_spec_create_delete\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/48b374a5a3bc406594aafa533cf46e98/types/8afe9a8f-cd72-47f6-89e5-474fb2299ca3/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec2\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Wed, 02 Jan 2013 01:38:11 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-5e4796b1-ccd4-4fde-a42b-ea2f5b89b58d\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Create/get volume type extra spec\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 109, in test_volume_type_extra_spec_create_get\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/48b374a5a3bc406594aafa533cf46e98/types/8afe9a8f-cd72-47f6-89e5-474fb2299ca3/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec1\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Wed, 02 Jan 2013 01:38:11 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-087a265d-ae03-438b-825b-0f6c2ed7a028\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: List Volume types extra specs.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 59, in test_volume_type_extra_specs_list\n    self.fail(\"Could not list volume types extra specs\")\nAssertionError: Could not list volume types extra specs\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not list volume types extra specs\')\n    \n\n======================================================================\nFAIL: Update volume type extra specs\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 75, in test_volume_type_extra_specs_update\n    self.fail(\"Couldnt update volume type extra spec\")\nAssertionError: Couldnt update volume type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Couldnt update volume type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/48b374a5a3bc406594aafa533cf46e98/types/8afe9a8f-cd72-47f6-89e5-474fb2299ca3/extra_specs/spec1\ntempest.common.rest_client: ERROR: Request Body: {\"spec1\": \"val2\"}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Wed, 02 Jan 2013 01:38:12 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-b404ab75-7fab-4411-92e4-4a40e13450c0\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 593 tests in 3966.415s\n\nFAILED (SKIP=74, failures=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/rabbitmq/rabbit at devstack-1357047632-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/rabbitmq/rabbit at devstack-1357047632.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/55/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<747334032.305.1357001362249.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1031062701.400.1367042899487.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:08:19',0,'2013-04-27 06:08:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-docs-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal4 in workspace <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/>\nCheckout:periodic-nova-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/> - hudson.remoting.Channel at 3eb69969:quantal4\nUsing strategy: Default\nLast Built Revision: Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\nChecking out Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\n[periodic-nova-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson1106057816880238265.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-nova-docs-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 55083 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-nova-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal4\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-04-36\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'b329e546-f575-4c05-9ea3-6cc8a2768a3a\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9ecd965eaf03dac01f81964a1e782223d2e2d1a8\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal4\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 55083 166.78.137.50 22\'}\nDownloading/unpacking SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires> (line 1))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires> (line 1))\nNo distributions at all found for SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires> (line 1))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1031581482.9438093.1354209879349.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-29 12:24:39',-18000,'2012-11-29 17:24:39',NULL,'[openstack-dev] [Notifications] Glance, Quantum et al.','\n\n----- Original Message -----\n> \n> On Nov 29, 2012, at 7:56 AM, Gary Kotton wrote:\n> \n> > Hi,\n> > Due to the patch https://github.com/openstack/glance/commit/3d532de\n> > we have a problem running Quantum and Glance on devstack. This\n> > just opens a pandoras box of problems. Glance sets the queue as\n> > durable, Quantum uses the default value which is false - this\n> > causes an exception \"AMQPChannelException: (406,\n> > u\"PRECONDITION_FAILED - parameters for queue \'notifications.info\'\n> > in vhost \'/\' not equivalent\", (50, 10)\".\n> > The underlying problem is the way in which the notifications are\n> > implemented. I am not really sure if and how this can be addressed\n> > as I am not familiar with the code.\n> \n> Glance itself will default to non-durable queues (config opt\n> rabbit_durable_queues), but there\'s code in Devstack that will\n> attempt to match Glance\'s durability to that of an existing queue.\n> Can you verify that the relevant code in Devstack is functioning\n> correctly? See \'rabbit_durable_queues()\' in lib/glance.\n\nMaybe I\'ve misread it, but looks slightly dubious:\n\n  https://github.com/openstack-dev/devstack/commit/71cf53a9\n\nWouldn\'t:\n\n  `rabbitmqctl list_queues name durable | grep true | wc -l` -gt 0\n\nbe true if *any* durable queues exist, not specifically the glance ones?\n\nCheers,\nEoghan\n\n\n','<51C17160-1653-448C-B607-A4FF6A1B12E8@gmail.com>',NULL),('<1031791613.30.1375509797394.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-03 06:03:17',0,'2013-08-03 06:03:17',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #55','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/55/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-180946 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #211460 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-all] $ /bin/bash -xe /tmp/hudson6044263931752758710.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-all] $ /bin/bash -xe /tmp/hudson5231748835894118352.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_ALL=1\n+ DEVSTACK_GATE_TEMPEST_ALL=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-180946\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-180946/55\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-180946/55/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-180946/55/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1031845148.1438006.1414589776483.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-29 09:36:16',-14400,'2014-10-29 13:36:16',NULL,'[Openstack] glance error','Hi, \n\nThis part-> Check login credentials .. maybe your user/password for Glance/Rabbitmq aren\'t correct on Glance-api.conf. \nOr on the other hand maybe you don\'t have a user for it on rabbitmq side. \n\nCheck Glance-api.conf \n\n#rabbit_host=localhost\nrabbit_host=x.y.z.w   -> this should be the IP address of your rabbitmq server.    \n#rabbit_port=5672\nrabbit_port=5672\n#rabbit_use_ssl=false\nrabbit_use_ssl=False\n#rabbit_userid=guest\nrabbit_userid=guest -> user might be something other than guest maybe glance.\n#rabbit_password=guest  \nrabbit_password=guest    -> the password for above user. \n#rabbit_virtual_host=/\nrabbit_virtual_host=/   -> this is the vhost \n#rabbit_notification_exchange=glance\nrabbit_notification_exchange=glance\n#rabbit_notification_topic=notifications\nrabbit_notification_topic=notifications\n#rabbit_durable_queues=False\n\n\nNow go to your rabbitmq server (remember IP address above x.y.z.w, oh it might also be localhost)\n\n# rabbitmqctl list_users     -> will show which users you have in my case all services use guest \nListing users ...\nguest   [administrator]\n\n# rabbitmqctl list_permissions  -> check permissions, you may have a dedicated vhost (above -> rabbit_virtual_host=/ ) just for Glance, if so check that the correct user has permissions for correct vhost.  \nListing permissions in vhost \"/\" ...\nguest   .*      .*      .*\n...done.\n\nIf you are not sure about the password on rabbitmq\'s side, just reset it to what you see on rabbit_password=....  \nrabbitmqctl change_password <username> <newpassword>\n\nJust in case I\'d also restart Glance service and try to upload image again.  \n\nBTW if you have rabbitmq related errors (wrong password) they should also show up on rabbitmq\'s log, it\'s a good idea to check it out as well. \ntailf /var/log/rabbitmq/rabbit at server.log\n\n\nHope this helps.  \nTzach\n\n\n\n\n\n\n\n\n----- Original Message -----\nFrom: mohib at qmail.com.bd\nTo: \"xico loco\" <xicoloco at gmail.com>\nCc: openstack at lists.openstack.org\nSent: Wednesday, October 29, 2014 2:30:55 PM\nSubject: [Openstack] glance error\n\n\n\nHi xico loco, \n\nmy /var/log/glance/api.log show this error. Please see in below, \n\n2014-10-29 16:49:29.461 10473 DEBUG oslo.db.sqlalchemy.session [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION _init_events /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:461 \n\n\n\n\n\n2014-10-29 17:39:27.849 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Connecting to AMQP server on localhost:5672 \n2014-10-29 17:39:30.913 2030 ERROR oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed \n2014-10-29 17:39:31.914 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Delaying reconnect for 1.0 seconds... \n2014-10-29 17:39:32.915 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Connecting to AMQP server on localhost:5672 \n2014-10-29 17:39:35.937 2030 ERROR oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed \n2014-10-29 17:39:38.938 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Delaying reconnect for 1.0 seconds... \n2014-10-29 17:39:39.939 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Connecting to AMQP server on localhost:5672 \n2014-10-29 17:39:42.960 2030 ERROR oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] AMQP server localhost:5672 closed the connection. Check login credentials: Socket closed \n2014-10-29 17:39:47.963 2030 INFO oslo.messaging._drivers.impl_rabbit [36cabc2f-5c66-4152-85d2-b126743da212 e06d920ca73b4a57ab6e75fd0637d72c 87e2ff058b9f46589f0b370b552b4d00 - - -] Delaying reconnect for 1.0 seconds... \n\n\n\n\nPlease help me for solution this problem. \n\nThanks for replay \n\n\n\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<b9c190f51d6cd4c2c960673e569ca41e@qmail.com.bd>',NULL),('<1031904140.22961260.1384378190196.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 16:29:50',-18000,'2013-11-13 21:29:50',NULL,'[openstack-dev] [Solum] Create a source repo for the API\n specification?','\n\n----- Original Message -----\n> \n> I like this idea. I\'d also propose that the format of the specification be\n> something machine-readable, such as API-Blueprint (a simple subset of\n> markdown, apiblueprint.org , also what apiary uses, if you\'ve ever seen\n> that) or RAML (a more structured YAML-based syntax, raml.org ).\n> API-Blueprint is closer to what the keystone document uses.\n> \n> Making the documentation machine-readable means that it\'s much easier to\n> verify that, in practice, the implementation of an API matches its\n> specification and documentation, which is a problem that plagues many\n> OpenStack projects right now.\n> \n\nAt the meeting today we discussed putting together an initial seed based around the proposed API and based mostly on the identity-api work.  Are folks ok with api-blueprint [1]\n\n[1] http://apiblueprint.org\n\n\n','<CAPkRfUT_Dk_cXUePjTty=cRSHY7pdQTQEPGN6iUP6TqVgyPuaA@mail.gmail.com>',NULL),('<1032096322.277.1368512644956.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-14 06:24:04',0,'2013-05-14 06:24:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly-centos6 #14','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/14/>\n\n\n\n','<1653451396.261.1368425909166.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1033939609.51978796.1395244480827.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 08:54:40',-25200,'2014-03-19 15:54:40',NULL,'[openstack-dev] [Congress] Policy types','Inline.\n\nTim\n\n----- Original Message -----\n| From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Wednesday, March 19, 2014 7:09:24 AM\n| Subject: Re: [openstack-dev] [Congress] Policy types\n| \n| Hi Tim,\n|  \n| I am good with starting or own the Python __congress__builtin__ proposal, but\n| will need help from the whole team to work through the details.\n| Do you all envision, the data integration API (Pete\'s calls) to be part of\n| this builtin?\n| What are the exact aspects each member is interested in having in this\n| builtin? It\n| would be good to start a list and discuss.\n| 1. Inherit all python builtins\n| 2. Any builtins specific to datalog etc....\n| 3. builtins to test and manage primitives\n|  \n\nI\'d say we should start simple.  The data types we support right now are integers, floats, and strings.  So let\'s add some basic arithmetic and string manipulation functions.  If we design this right, it will be easy to add more later.\n\nArithmetic: +, *, -, /, <, >, =, others?\nStrings: concatenation, substring, indexof, others?\n\nI\'d say we definitely don\'t want class (3)--we don\'t want the policy to change the data upon which policy decisions are made, at least not directly.  Conceptually, the tables derived from nova/Neutron/etc. represent *their* states.  We can change their states but only by executing *their* API calls, which if successful, will change their state, which will eventually be reflected in Congress tables.  The Condition-Action policy that I described below dictates which of their API calls Congress should execute and when; this policy *indirectly* will change the tables of Nova/Neutron/etc.  But I wouldn\'t want to change tables via builtins.\n\n\n\n| Regarding data integration:\n| My concern with periodically pushing the contents is consistency. Having two\n| stores (the nova/OS\n| database and a Congress specific increases the chances of the data being out\n| of sync). For example\n| nova:owner(vm1), might be changed in the nova database if the period is too\n| large.  What would be\n| the benefits of doing this?  The first one: \'ask for contents of the tables\'\n| reduces the consistency\n| issue.  Do you see those API mapping betweeen table entries and OS calls as\n| part of the builtin?\n\nConceptually, data integration handles the problem of grabbing information from other components.  Builtins handle the problem that some tables are  hard/impossible to define within Datalog itself.  \n\nMore practically, I would NOT want a builtin that queries another cloud service because the policy writer does not (and is not supposed to) know the particular algorithms Congress will use to process those rules.  Congress could end up calling a builtin 100 times for a *single* computation of policy violations.    We wouldn\'t want to download all the data about all VM instances 100 times whenever someone asks for all violations.  So builtins are things that compute quickly.\n\nI don\'t see a way around caching the contents of other OS components.  A single policy might utilize the same data but in different ways in multiple places in the policy.  The intent is that we\'ll always be in sync to the extent that is practically feasible.  And even if we were to ask for all the data that we need before each and every query someone asks, that data could still change before we answer the query, before the person asking the query looked at the answer, before the person asking the query made a decision based on the answer, etc.  So staleness is a fact of life, and we\'re setting this up to minimize those problems by enabling cloud services to send us *updates* to their data whenever they get them.  If a cloud service does not send us updates, the best we can do is poll them periodically, which will make staleness a bigger problem.  But I don\'t see what else we can do.\n\n\n|  \n| >>2. The policy engine will need to ask for the contents of tables (or\n| >>updates to tables).  Or have the >>contents/updates pushed to it\n| >>periodically.  The infrastructure for doing this is what Peter (pballand)\n| >>>>volunteered to do in IRC last week.  Let\'s wait on this to see what he\n| >>has to say.\n|  \n| > Date: Tue, 18 Mar 2014 12:56:10 -0700\n| > From: thinrichs at vmware.com\n| > To: openstack-dev at lists.openstack.org\n| > CC: rajdeepd at vmware.com\n| > Subject: Re: [openstack-dev] [Congress] Policy types\n| > \n| > Hi Prabhakar,\n| > \n| > Found time for a more detailed response.  Comments are inline.\n| > \n| > Tim\n| > \n| > ----- Original Message -----\n| > | From: \"Tim Hinrichs\" <thinrichs at vmware.com>\n| > | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | <openstack-dev at lists.openstack.org>\n| > | Sent: Tuesday, March 18, 2014 9:31:34 AM\n| > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | \n| > | Hi Prabhakar,\n| > | \n| > | No IRC meeting this week.  Our IRC is every *other* week, and we had it\n| > | last\n| > | week.\n| > | \n| > | Though there\'s been enough activity of late that maybe we should consider\n| > | making it weekly.\n| > | \n| > | I\'ll address the rest later.\n| > | \n| > | Tim\n| > | \n| > | ----- Original Message -----\n| > | | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | | <openstack-dev at lists.openstack.org>\n| > | | Sent: Monday, March 17, 2014 7:45:53 PM\n| > | | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | \n| > | | Hi Tim,\n| > | |  \n| > | | Definitely would like to learn more about the Data Integration\n| > | | component\n| > | | and how best to contribute. Can\'t find it in the latest git, perhaps we\n| > | | can\n| > | | discuss during the meeting tomorrow. Where can I find some code and/or\n| > | | document?\n| > \n| > There are no docs yet, and the only code in git is a quick-and-dirty\n| > ActiveDirectory integration.  But conceptually there are two pieces of the\n| > data integration story.\n| > \n| > 1. We\'re representing the data stored in each cloud service (that is\n| > pertinent to policy) as a collection of TABLES.  Each table is a\n| > collection of rows that all have the same number of columns.  Each value\n| > in the table is a scalar (number or string).\n| > \n| > If you look at the last IRC, Rajdeep has started working on translating\n| > Neutron data into this table format.  There are a couple of emails on the\n| > mailing list as well where we had some discussion.  Here\'s his change set.\n| > \n| > https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/77835/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=RWImR6mlKm3o%2FPNPGgGI2OQN98S7HyzOfJ6CbK4vcdY%3D%0A&s=eb6f42e062d0b244f442d2745de50865111367c4168237786e717ae13fdef849\n| > \n| > 2. The policy engine will need to ask for the contents of tables (or\n| > updates to tables).  Or have the contents/updates pushed to it\n| > periodically.  The infrastructure for doing this is what Peter (pballand)\n| > volunteered to do in IRC last week.  Let\'s wait on this to see what he has\n| > to say.\n| > \n| > \n| > \n| > | |  \n| > | | I like the idea of using an \'evauate\' wrapper.  And the idea of a\n| > | | builtin\n| > | | library of functions.  Having strict rules for builtins and an evaluate\n| > | | wrapper\n| > | | to do type checking (primitive or builtin) and so on reduces the silent\n| > | | errors or weird outcomes.\n| > | |  \n| > | | I also agree, raw python using methods like \'calleable\' (or other ways\n| > | | of checking if the function can be called in python) may not always\n| > | | give\n| > | | definitive answers. Even the definition of callable says, that a True\n| > | | only\n| > | | says that the object \'appears\' calleable.\n| > | |  \n| > | | So silent and weird problems are possible if we try to execute. On the\n| > | | other\n| > | | hand,\n| > | | if we are looking at module which contains only user defined functions\n| > | | or\n| > | | builtine\n| > | | , i.e., there  are strict rules to what exactly constitute\n| > | | allowed-functions,\n| > | | then there\n| > | | is a higher likelihood that it is correct.  But still a likelihood.\n| > \n| > Agreed: errors will always be possible.  The policy engine will treat them\n| > as failures (i.e. won\'t \"re-throw\" the error), so we just want to help the\n| > policy-writer as much as we can.\n| > \n| > | |  \n| > | | I like the \'evaluate\' idea which could do the checking within\n| > | | to make sure the function is indeed calleable, and silent and weird\n| > | | side\n| > | | effects\n| > | | are filtered inside the \'evaluate\'. In addition, it can do checking if\n| > | | it\n| > | | is\n| > | | a  primitive or some other valid format. Needs more thought on this.\n| > | |  \n| > | | Let\'s discuss implementation paths if possible at the meeting. Would\n| > | | like\n| > | | to\n| > | | carve out a small implementation goal either in the \'data integration\'\n| > | | line\n| > | | or\n| > | | the discussion above.\n| > \n| > \n| > Great!\n| > \n| > One option is to coordinate with rajdeep and see if there\'s an OS component\n| > that you\'d like to try to turn into tables.  His code is an example of\n| > what you\'d be writing.\n| > \n| > Or you could put together a proposal for adding Python builtins to the\n| > policy engine.  One thing to think about is that we\'d want to make it easy\n| > to add additional builtins.  We\'d also need to figure out what the syntax\n| > would look like from the policy-writer\'s point of view.  Here I\'ve seen\n| > two options:\n| > \n| > // +, *, and lt are builtins\n| > p(x, y, z) :- q(x), r(z) (3*x)+2=y, lt(y, z)\n| > \n| > // builtins are forced to look like any other table.\n| > p(x, y, z) :- q(x), r(z), *(3, x, w), +(w, 2, y), lt(y, z)\n| > \n| > \n| > The latter is a bit clunky, but it makes it easier to implement the policy\n| > engine.\n| > \n| > Tim\n| > \n| >    \n| > \n| > | |  \n| > | | Prabhakar\n| > | |  \n| > | |  \n| > | |  \n| > | | \n| > | |  \n| > | | > Date: Mon, 17 Mar 2014 08:57:05 -0700\n| > | | > From: thinrichs at vmware.com\n| > | | > To: openstack-dev at lists.openstack.org\n| > | | > Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > \n| > | | > Hi Prabhakar,\n| > | | > \n| > | | > One big piece we\'re missing in terms of code right now is the Data\n| > | | > Integration component.  The job of this component is to integrate\n| > | | > data\n| > | | > sources available in the cloud so that tables like\n| > | | > nova:virtual_machine,\n| > | | > neutron:owner, etc. reflect the information stored in Nova, Neutron,\n| > | | > etc.\n| > | | > Rajdeep is making progress on that (he\'s got some code up on review\n| > | | > that\n| > | | > we\'re iterating on), and Peter had worked on integrating AD a while\n| > | | > back.\n| > | | > \n| > | | > Typically I\'ve seen the Python functions (which I usually call\n| > | | > \'builtins\')\n| > | | > integrated into a Datalog system have explicit declarations (e.g.\n| > | | > inputs,\n| > | | > outputs, etc.).  This is good if we need to do deeper analysis of the\n| > | | > policy (which is one of the reasons to use a policy language) and\n| > | | > typically requires information about how that builtin works.\n| > | | > \n| > | | > I dug through some old (Lisp) code to see how I\'ve done this in the\n| > | | > past.\n| > | | > \n| > | | > // (defbuiltin <datalog-name> <lisp-function> <list of types of args>\n| > | | > <list\n| > | | > of types of returns> [<internal>])\n| > | | > (defbuiltin plus + (integer integer) integer)\n| > | | > (defbuiltin minus - (integer integer) integer)\n| > | | > (defbuiltin times * (integer integer) integer)\n| > | | > (defbuiltin div (lambda (x y) (floor (/ x y))) (integer integer)\n| > | | > integer)\n| > | | > (defbuiltin lt numlessp (integer integer) nil)\n| > | | > (defbuiltin lte numleqp (integer integer) nil)\n| > | | > (defbuiltin gte numgeqp (integer integer) nil)\n| > | | > (defbuiltin gt numgreaterp (integer integer) nil)\n| > | | > \n| > | | > But maybe you\'re right in that we could do away with these explicit\n| > | | > declarations and just assume that everything that (i) is calleable,\n| > | | > (ii)\n| > | | > not managed by the Data Integration component, and (iii) does not\n| > | | > appear\n| > | | > in the head of a rule is a builtin.  My only worry is that I could\n| > | | > imagine\n| > | | > silent and weird problems showing up, e.g. someone forgot to define a\n| > | | > table with rules and there happens to be a function in Python by that\n| > | | > name.  Or someone supplies the wrong number of arguments, and we just\n| > | | > get\n| > | | > an error from Python, which we\'d have no direct way to communicate to\n| > | | > the\n| > | | > policy-writer, i.e. there\'s no compile-time argument-length checking.\n| > | | > \n| > | | > The other thing I\'ve seen done is to have a single builtin \'evaluate\'\n| > | | > that\n| > | | > lets us call an arbitrary Python function, e.g.\n| > | | > \n| > | | > p(x, y) :- q(x), evaluate(mypyfunc(x), y)\n| > | | > \n| > | | > Then we wouldn\'t need to declare the functions.  Errors would still\n| > | | > be\n| > | | > silent.  But it would be clear whether we were using a Python\n| > | | > function or\n| > | | > not.\n| > | | > \n| > | | > Thoughts?\n| > | | > Tim\n| > | | > \n| > | | > \n| > | | > \n| > | | > \n| > | | > ----- Original Message -----\n| > | | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | | > | <openstack-dev at lists.openstack.org>\n| > | | > | Sent: Saturday, March 15, 2014 8:28:27 PM\n| > | | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | \n| > | | > | \n| > | | > | \n| > | | > | Hi Tim,\n| > | | > | \n| > | | > | Here is a small change I wanted to try in runtime.py\n| > | | > | It may already exist in MaterializedViewTheory, but wasn\'t clear to\n| > | | > | me.\n| > | | > | Checking to see if this is something that:1. makes sense 2. already\n| > | | > | exists\n| > | | > | 3. worth implementing? in that order.\n| > | | > | \n| > | | > | Let\'s take the example from private_public_network.classify\n| > | | > | \n| > | | > | error(vm) :- nova:virtual_machine(vm), nova:network(vm, network),\n| > | | > | not neutron:public_network(network),\n| > | | > | neutron:owner(network, netowner), nova:owner(vm, vmowner), not\n| > | | > | same_group(netowner, vmowner)\n| > | | > | \n| > | | > | same_group(user1, user2) :- cms:group(user1, group),\n| > | | > | cms:group(user2,\n| > | | > | group)\n| > | | > | \n| > | | > | nova:virtual_machine(\"vm1\")\n| > | | > | nova:virtual_machine(\"vm2\")\n| > | | > | nova:virtual_machine(\"vm3\")\n| > | | > | nova:network(\"vm1\", \"net_private\")\n| > | | > | nova:network(\"vm2\", \"net_public\")\n| > | | > | neutron:public_network(\"net_public\")\n| > | | > | nova:owner(\"vm1\", \"tim\")\n| > | | > | nova:owner(\"vm2\", \"pete\")\n| > | | > | nova:owner(\"vm3\", \"pierre\")\n| > | | > | neutron:owner(\"net_private\", \"martin\")\n| > | | > | \n| > | | > | \n| > | | > | In this example, if as in Scenario 1:\n| > | | > | \n| > | | > | Cloud services at our disposal:\n| > | | > | nova:virtual_machine(vm)\n| > | | > | nova:network(vm, network)\n| > | | > | nova:owner(vm, owner)\n| > | | > | neutron:public_network(network)\n| > | | > | neutron:owner(network, owner)\n| > | | > | cms:group(user, group)\n| > | | > | \n| > | | > | are all python functions called through some nova/neutron api,\n| > | | > | then, we just execute them to get a true/false value in runtime.py\n| > | | > | They should be first checked to make sure they are python functions\n| > | | > | and\n| > | | > | not condition primitives using \'callable\' and os.dir or some such\n| > | | > | combination.\n| > | | > | \n| > | | > | If not, and they are assertions made in the file, not directly\n| > | | > | related to OS\n| > | | > | state, then in Scenario 2\n| > | | > | \n| > | | > | nova:owner(\"vm1\", \"tim\")\n| > | | > | nova:owner(\"vm2\", \"pete\")\n| > | | > | nova:owner(\"vm3\", \"pierre\")\n| > | | > | \n| > | | > | Are assertions made in the file. In a dynamic environment,\n| > | | > | a python function could query an OS client to actually find the\n| > | | > | current owner,\n| > | | > | since some other OS command could have been used to change the\n| > | | > | owner\n| > | | > | without an entry being made in this file, i.e., without explicitly\n| > | | > | informing Congres.\n| > | | > | This may not occur currently with vms, but may be implemented\n| > | | > | in a future release. Similar other examples are possible\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=https://ask.openstack.org/en/question/5582/how-to-change-ownership-between-tenants-of-volume/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=6da252434cf8f03e99ab04dcc042d3eb646b7c4ea0390b9d0b96f04534d05574\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/cinder/%2Bspec/volume-transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=dd07239a911392850af6d2ea72ecce3ea39997c1c93c7f235868a4919144296e\n| > | | > | \n| > | | > | \n| > | | > | So, I was thinking that python_nova_owner(\"vm1\"), is first checked\n| > | | > | as\n| > | | > | a python\n| > | | > | function which calls the appropriate OS client to check the current\n| > | | > | owner.\n| > | | > | As in nova:owner(\"vm1\", python_nova_owner(\"vm1\"))\n| > | | > | \n| > | | > | So, in runtime.py, in either scenario, condition primitives are\n| > | | > | first\n| > | | > | checked to\n| > | | > | see if it they are callable\n| > | | > | python functions (by using python \'callable\' with os.dir). In which\n| > | | > | case, it is\n| > | | > | executed to get the name of the owner. All non-callable primitives\n| > | | > | are assumed\n| > | | > | assumed to be congress and/or datalog primitives, and unified\n| > | | > | through\n| > | | > | the\n| > | | > | Materializedviewtheory.\n| > | | > | \n| > | | > | \n| > | | > | Thanks,\n| > | | > | \n| > | | > | \n| > | | > | > Date: Thu, 13 Mar 2014 08:55:24 -0700\n| > | | > | > From: thinrichs at vmware.com\n| > | | > | > To: openstack-dev at lists.openstack.org\n| > | | > | > Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > \n| > | | > | > Hi Prabhakar,\n| > | | > | > \n| > | | > | > I\'m not sure the functionality is split between \'policy\' and\n| > | | > | > \'server\' as cleanly as you describe.\n| > | | > | > \n| > | | > | > The \'policy\' directory contains the Policy Engine. At its core,\n| > | | > | > the\n| > | | > | > policy engine has a generic Datalog implementation that could\n| > | | > | > feasibly be used by other OS components. (I don\'t want to think\n| > | | > | > about pulling it out into Oslo though. There are just too many\n| > | | > | > other things going on and no demand yet.) But there are also\n| > | | > | > Congress-specific things in that directory, e.g. the class\n| > | | > | > Runtime\n| > | | > | > in policy/runtime.py will be the one that we hook up external API\n| > | | > | > calls to.\n| > | | > | > \n| > | | > | > The \'server\' directory contains the code for the API web server\n| > | | > | > that calls into the Runtime class.\n| > | | > | > \n| > | | > | > So if you\'re digging through code, I\'d suggest focusing on the\n| > | | > | > \'policy\' directory and looking at compile.py (responsible for\n| > | | > | > converting Datalog rules written as strings into an internal\n| > | | > | > representation) and runtime.py (responsible for everything else).\n| > | | > | > The docs I mentioned in the IRC should have a decent explanation\n| > | | > | > of the functions in Runtime that the API web server will hook\n| > | | > | > into.\n| > | | > | > \n| > | | > | > Be warned though that unless someone raises some serious\n| > | | > | > objections\n| > | | > | > to the proposal that started this thread, we\'ll be removing some\n| > | | > | > of the more complicated functions from Runtime. The compile.py\n| > | | > | > code won\'t change (much). All of the 3 new theories will be\n| > | | > | > instances of MaterializedViewTheory. That\'s also the code that\n| > | | > | > must change to add in the Python functions we talked about (more\n| > | | > | > specifically see MaterializedViewTheory::propagate_rule(), which\n| > | | > | > calls TopDownTheory::top_down_evaluation(), which is what will\n| > | | > | > need modification).\n| > | | > | > \n| > | | > | > Tim\n| > | | > | > \n| > | | > | > \n| > | | > | > \n| > | | > | > \n| > | | > | > ----- Original Message -----\n| > | | > | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | > | To: \"OpenStack Development Mailing List (not for usage\n| > | | > | > | questions)\" <openstack-dev at lists.openstack.org>\n| > | | > | > | Sent: Wednesday, March 12, 2014 1:38:55 PM\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Tim,\n| > | | > | > | \n| > | | > | > | Thanks for your comments.\n| > | | > | > | Would be happy to contribute to the propsal and code.\n| > | | > | > | \n| > | | > | > | The existing code already reflects the thoughts below, and got\n| > | | > | > | me\n| > | | > | > | in the line of ideas. Please orrect me if I am wrong as I am\n| > | | > | > | learning with these discussions:\n| > | | > | > | \n| > | | > | > | One part (reflected by code in \"policy\" directory is the\n| > | | > | > | generic\n| > | | > | > | \"condition-> action engine\" which could take logic primitives\n| > | | > | > | and\n| > | | > | > | (in the future) python functions, evaluate the conditions and\n| > | | > | > | execute the action. This portable core engine be used for any\n| > | | > | > | kind of\n| > | | > | > | policy enforcement\n| > | | > | > | (as by other OS projects), such as for data center monitoring\n| > | | > | > | and\n| > | | > | > | repair,\n| > | | > | > | service level enforcement, compliance policies, optimization\n| > | | > | > | (energy,\n| > | | > | > | performance) etc... at any level of the stack. This core engine\n| > | | > | > | seems\n| > | | > | > | possibly\n| > | | > | > | a combination of logic reasoning/unification and python\n| > | | > | > | function\n| > | | > | > | evaluation, and python code actions.\n| > | | > | > | \n| > | | > | > | Second part (reflected by code in \"server\") are the\n| > | | > | > | applications\n| > | | > | > | for various purposes. These could be project specific, task\n| > | | > | > | specific.\n| > | | > | > | We could add a diverse set of examples. The example I have\n| > | | > | > | worked\n| > | | > | > | with seems closer to compliance (as in net owner, vm owner\n| > | | > | > | check),\n| > | | > | > | and we will add more.\n| > | | > | > | \n| > | | > | > | Prabhakar\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Date: Wed, 12 Mar 2014 12:33:35 -0700\n| > | | > | > | From: thinrichs at vmware.com\n| > | | > | > | To: openstack-dev at lists.openstack.org\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Prabhakar,\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Thanks for the feedback. I\'d be interested to hear what other\n| > | | > | > | policy\n| > | | > | > | types you have in mind.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | To answer your questions...\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | We\'re planning on extending our policy language in such a way\n| > | | > | > | that\n| > | | > | > | you can use Python functions as conditions (\"<atom>\" in the\n| > | | > | > | grammar)\n| > | | > | > | in rules. That\'s on my todo-list but didn\'t mention it\n| > | | > | > | yesterday\n| > | | > | > | as\n| > | | > | > | we were short on time. There will be some syntactic\n| > | | > | > | restrictions\n| > | | > | > | so\n| > | | > | > | that we can properly execute those Python functions (i.e. we\n| > | | > | > | need\n| > | | > | > | to\n| > | | > | > | always be able to compute the inputs to the function). I had\n| > | | > | > | thought\n| > | | > | > | it was just an implementation detail I hadn\'t gotten around to\n| > | | > | > | (all\n| > | | > | > | Datalog implementations I\'ve seen have such things), but it\n| > | | > | > | sounds\n| > | | > | > | like it\'s worth writing up a proposal and sending it around\n| > | | > | > | before\n| > | | > | > | implementing. If that\'s a pressing concern for you, let me know\n| > | | > | > | and\n| > | | > | > | I\'ll bump it up the stack (a little). If you\'d like, feel free\n| > | | > | > | to\n| > | | > | > | draft a proposal (or remind me to do it once in a while).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | As for actions, I typically think of them as API calls to other\n| > | | > | > | OS\n| > | | > | > | components like Nova. But they could just as easily be Python\n| > | | > | > | functions. But I would want to avoid an action that changes\n| > | | > | > | Congress\'s internal data structures directly (e.g. adding a new\n| > | | > | > | policy statement). Such actions have caused trouble in the past\n| > | | > | > | for\n| > | | > | > | policy languages (though for declarative programming languages\n| > | | > | > | like\n| > | | > | > | Prolog they are less problematic). I don\'t think there\'s anyway\n| > | | > | > | we\n| > | | > | > | can stop people from creating such actions, but I think we\n| > | | > | > | should\n| > | | > | > | advocate against them.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Tim\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | > | To: \"OpenStack Development Mailing List (not for usage\n| > | | > | > | questions)\"\n| > | | > | > | <openstack-dev at lists.openstack.org>\n| > | | > | > | Sent: Wednesday, March 12, 2014 11:34:04 AM\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Tim, All,\n| > | | > | > | \n| > | | > | > | I was in the discussion yesterday (kudva), and would like to\n| > | | > | > | start\n| > | | > | > | gradually\n| > | | > | > | contributing to the code base.\n| > | | > | > | \n| > | | > | > | So, this discussion below is based on my limited exploration of\n| > | | > | > | Congress\n| > | | > | > | code, running it. I am trying some small pieces to implement to\n| > | | > | > | familiarize.\n| > | | > | > | Please view it as such. As I start adding code, I am sure, my\n| > | | > | > | thoughts will\n| > | | > | > | be more evolved.\n| > | | > | > | \n| > | | > | > | I agree with the three types you outline. I also agree that\n| > | | > | > | these\n| > | | > | > | will grow.\n| > | | > | > | We are already thinking of expanding congress for various other\n| > | | > | > | types\n| > | | > | > | of\n| > | | > | > | policies. But those would be a manageable start.\n| > | | > | > | \n| > | | > | > | Regarding the comment below. I was wondering if all conditions,\n| > | | > | > | and\n| > | | > | > | actions\n| > | | > | > | could be both:\n| > | | > | > | 1. python functions (for conditions they eval\n| > | | > | > | 2. policy primitives.\n| > | | > | > | \n| > | | > | > | The advantage of 1, is that it is just executed and a True or\n| > | | > | > | False\n| > | | > | > | returned\n| > | | > | > | by Python for conditions. For actions, python functions are\n| > | | > | > | executed\n| > | | > | > | to respond to conditions.\n| > | | > | > | This controls the growth of policies and adding more\n| > | | > | > | primitives,\n| > | | > | > | and\n| > | | > | > | makes it flexible (say\n| > | | > | > | to use alarms, monitors, os clients, nova actions etc).\n| > | | > | > | \n| > | | > | > | The advantage of 2, is the ability to use unification (as in\n| > | | > | > | unify.py) and do\n| > | | > | > | some logic reduction. This gives us the full strength of\n| > | | > | > | extensive\n| > | | > | > | and mature\n| > | | > | > | logic reasoning and reduction methods.\n| > | | > | > | \n| > | | > | > | One possibility is that it checks which one the two it is and\n| > | | > | > | does\n| > | | > | > | the appropriate\n| > | | > | > | evaluation for condition and action.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | >There are drawbacks to this proposal as well.\n| > | | > | > | >- We will have 3 separate policies that are conceptually very\n| > | | > | > | >similar. As the policies grow larger, it will become\n| > | | > | > | >>increasingly\n| > | | > | > | >difficult to keep the policies synchronized. This problem can\n| > | | > | > | >be\n| > | | > | > | >mitigated to some extent by having >all 3 share a library of\n| > | | > | > | >policy\n| > | | > | > | >statements that they all apply in different ways (and such a\n| > | | > | > | >library mechanism is >already implemented).\n| > | | > | > | >- As cloud services change their behavior, policies may need\n| > | | > | > | >to\n| > | | > | > | >be\n| > | | > | > | >re-written. For example, right now Nova does >not consult\n| > | | > | > | >Congress\n| > | | > | > | >before creating a VM; thus, to enforce policy surrounding VMs,\n| > | | > | > | >the\n| > | | > | > | >best we could do is >write a Condition-Action policy that\n| > | | > | > | >adjusts\n| > | | > | > | >VM configuration when it learns about new VMs being created.\n| > | | > | > | >If\n| > | | > | > | >we\n| > | | > | > | >>later make Nova consult with Congress before creating a VM,\n| > | | > | > | >>we\n| > | | > | > | >need to write an Access-control policy that puts >the proper\n| > | | > | > | >controls in place.\n| > | | > | > | Thanks,\n| > | | > | > | \n| > | | > | > | Prabhakar Kudva\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Date: Wed, 12 Mar 2014 10:05:23 -0700\n| > | | > | > | From: thinrichs at vmware.com\n| > | | > | > | To: openstack-dev at lists.openstack.org\n| > | | > | > | Subject: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi all,\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | We started a discussion on IRC yesterday that I\'d like to\n| > | | > | > | continue.\n| > | | > | > | The main question is what kind of policy does a Congress user\n| > | | > | > | actually write? I can see three options. The first two focus on\n| > | | > | > | actions (API calls that make changes to the state of the cloud)\n| > | | > | > | and\n| > | | > | > | the last focuses on just the cloud state. (By \"state of the\n| > | | > | > | cloud\" I\n| > | | > | > | mean all the information Congress can see about all the cloud\n| > | | > | > | services it is managing, e.g. all the information we can get\n| > | | > | > | through\n| > | | > | > | API calls to Nova, Neutron, Cinder, Heat, ...).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | 1) Access Control (e.g. Linux, XACML, AD): which *actions* can\n| > | | > | > | be\n| > | | > | > | performed by other cloud services (for each state of the cloud)\n| > | | > | > | 2) Condition Action: which *actions* Congress should execute\n| > | | > | > | (for\n| > | | > | > | each state of the cloud)\n| > | | > | > | 3) Classification (currently supported in Congress): which\n| > | | > | > | *states*\n| > | | > | > | violate real-world policy. [For those of you who have read\n| > | | > | > | docs/white-papers/etc. I\'m using \"Classification\" in this note\n| > | | > | > | to\n| > | | > | > | mean the combination of the current \"Classification\" and\n| > | | > | > | \"Action\n| > | | > | > | Description\" policies.]\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | The important observation is that each of these policies could\n| > | | > | > | contain different information from each of the others.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Access Control vs Condition Action. The Access Control policy\n| > | | > | > | tells\n| > | | > | > | *other cloud services* which actions they are *allowed* to\n| > | | > | > | execute.\n| > | | > | > | The Condition Action policy tells *Congress* which actions it\n| > | | > | > | *must*\n| > | | > | > | execute. These policies differ because they constrain different\n| > | | > | > | sets\n| > | | > | > | of cloud services.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Access Control vs. Classification. The Access Control policy\n| > | | > | > | might\n| > | | > | > | permit some users to violate the Classification policy in some\n| > | | > | > | situations (e.g. to fix violation A, we might need to cause\n| > | | > | > | violation B before eliminating both). These policies differ\n| > | | > | > | because\n| > | | > | > | a violation in one policy might be be a violation in the other.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Classification vs. Condition Action. The Classification\n| > | | > | > | policy\n| > | | > | > | might imply which actions *could* eliminate a given violation,\n| > | | > | > | but\n| > | | > | > | the Condition Action policy would dictate which of those\n| > | | > | > | actions\n| > | | > | > | *should* be executed (e.g. the Classification policy might tell\n| > | | > | > | us\n| > | | > | > | that disconnecting a network and deleting a VM would both\n| > | | > | > | eliminate\n| > | | > | > | a particular violation, but the Condition Action policy would\n| > | | > | > | tell\n| > | | > | > | us which to choose). And the Condition Action policy need not\n| > | | > | > | eliminate all the violations present in the Classification\n| > | | > | > | policy.\n| > | | > | > | Again these policies differ because a violation in one policy\n| > | | > | > | might\n| > | | > | > | not be a violation in the other.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | I\'m proposing that for the first release of Congress we support\n| > | | > | > | all 3\n| > | | > | > | of these policies. When a user inserts/deletes a policy\n| > | | > | > | statement,\n| > | | > | > | she chooses which policy it belongs to. All would be written in\n| > | | > | > | basically the same syntax but would be used in 3 different\n| > | | > | > | scenarios:\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Prevention: If a component wants to consult Congress before\n| > | | > | > | taking\n| > | | > | > | action to see if that action is allowed, Congress checks the\n| > | | > | > | Access\n| > | | > | > | Control policy.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Reaction: When Congress learns of a change in the cloud\'s\n| > | | > | > | state, it\n| > | | > | > | checks the Condition Action policy to see which actions should\n| > | | > | > | be\n| > | | > | > | executed (if any).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Monitoring: If a user wants to simply check if the cloud\'s\n| > | | > | > | state is\n| > | | > | > | in compliance and monitor compliance over time, she writes and\n| > | | > | > | queries the Classification policy.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | There are several benefits to this proposal.\n| > | | > | > | - It allows users to choose any of the policy types, if they\n| > | | > | > | only\n| > | | > | > | want one of them. From our discussions with potential users,\n| > | | > | > | most\n| > | | > | > | seem to want one of these 3 policy types (and are uninterested\n| > | | > | > | in\n| > | | > | > | the others).\n| > | | > | > | - It makes the introduction to Congress relatively simple. We\n| > | | > | > | describe 3 different uses of policy (Prevention, Reaction,\n| > | | > | > | Monitoring) and then explain which policy to use in which case.\n| > | | > | > | \n| > | | > | > | - This allows us to focus on implementing a single\n| > | | > | > | policy-engine\n| > | | > | > | technology (a Datalog policy language and evaluation\n| > | | > | > | algorithms),\n| > | | > | > | which gives us the opportunity to make it solid.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | There are drawbacks to this proposal as well.\n| > | | > | > | - We will have 3 separate policies that are conceptually very\n| > | | > | > | similar. As the policies grow larger, it will become\n| > | | > | > | increasingly\n| > | | > | > | difficult to keep the policies synchronized. This problem can\n| > | | > | > | be\n| > | | > | > | mitigated to some extent by having all 3 share a library of\n| > | | > | > | policy\n| > | | > | > | statements that they all apply in different ways (and such a\n| > | | > | > | library\n| > | | > | > | mechanism is already implemented).\n| > | | > | > | - As cloud services change their behavior, policies may need to\n| > | | > | > | be\n| > | | > | > | re-written. For example, right now Nova does not consult\n| > | | > | > | Congress\n| > | | > | > | before creating a VM; thus, to enforce policy surrounding VMs,\n| > | | > | > | the\n| > | | > | > | best we could do is write a Condition-Action policy that\n| > | | > | > | adjusts\n| > | | > | > | VM\n| > | | > | > | configuration when it learns about new VMs being created. If we\n| > | | > | > | later make Nova consult with Congress before creating a VM, we\n| > | | > | > | need\n| > | | > | > | to write an Access-control policy that puts the proper controls\n| > | | > | > | in\n| > | | > | > | place.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | These drawbacks were the original motivation for supporting\n| > | | > | > | only\n| > | | > | > | the\n| > | | > | > | Classification policy and attempting to derive the Access\n| > | | > | > | Control\n| > | | > | > | and Condition Action policies from it. But given that we can\'t\n| > | | > | > | always derive the proper Access Control and Condition Action\n| > | | > | > | policies from the Classification policy, we will eventually\n| > | | > | > | need\n| > | | > | > | support for all 3. In addition, the technical complexity of\n| > | | > | > | supporting all 3 is much lower than supporting just the\n| > | | > | > | Classification policy and deriving the others.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | I\'ll stop there for now.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Comments, thoughts, questions?\n| > | | > | > | Tim\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | _______________________________________________ OpenStack-dev\n| > | | > | > | mailing\n| > | | > | > | list OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | > | _______________________________________________\n| > | | > | > | OpenStack-dev mailing list\n| > | | > | > | OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=4QiYdqIhBIaa%2FY1uu8c2Wq%2F92NWfXkaUvJLsncl4ccI%3D%0A&s=a18a843e031ec87277e04caa8396b5cf71bc7a2e5252247084abacf0b9e51409\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | _______________________________________________ OpenStack-dev\n| > | | > | > | mailing\n| > | | > | > | list OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | > | _______________________________________________\n| > | | > | > | OpenStack-dev mailing list\n| > | | > | > | OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=SMheq3u5q7x9wYFjxnNx6C%2F9lZgxydUP452rygu28MY%3D%0A&s=5c1cf9f3a5adc86ce59d2bf582891e0da033394f43a6ffa72127843c8cf78f80\n| > | | > | > | \n| > | | > | > \n| > | | > | > _______________________________________________\n| > | | > | > OpenStack-dev mailing list\n| > | | > | > OpenStack-dev at lists.openstack.org\n| > | | > | > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | \n| > | | > | _______________________________________________\n| > | | > | OpenStack-dev mailing list\n| > | | > | OpenStack-dev at lists.openstack.org\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=QvFCD7z%2FP29TE6KUtbaOJzeGxlOtxzdiGCdlm1LkcOY%3D%0A&s=8f7ec7cc8312dd84709bc99d725e9934b5403a43e8f1f2d02c638e504009ea71\n| > | | > | \n| > | | > \n| > | | > _______________________________________________\n| > | | > OpenStack-dev mailing list\n| > | | > OpenStack-dev at lists.openstack.org\n| > | | > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | |  		 	   		  \n| > | | _______________________________________________\n| > | | OpenStack-dev mailing list\n| > | | OpenStack-dev at lists.openstack.org\n| > | | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | |\n| > \n| > _______________________________________________\n| > OpenStack-dev mailing list\n| > OpenStack-dev at lists.openstack.org\n| > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=RWImR6mlKm3o%2FPNPGgGI2OQN98S7HyzOfJ6CbK4vcdY%3D%0A&s=6466989986e2d6dc541ae45db3c5418ab567d069bf0025c74f74611d89b868f5\n|  		 	   		  \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=RWImR6mlKm3o%2FPNPGgGI2OQN98S7HyzOfJ6CbK4vcdY%3D%0A&s=6466989986e2d6dc541ae45db3c5418ab567d069bf0025c74f74611d89b868f5\n| \n\n\n','<BLU170-W432BD3A7B2AC91440C21B1D57F0@phx.gbl>',NULL),('<1034068376.18.1369117409288.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-21 06:23:29',0,'2013-05-21 06:23:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #232','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/232/>\n\n------------------------------------------\n[...truncated 12586 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for 9c1d63600c8d4c7085e432f6d604a7bc \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43975\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43975/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (16827) wsgi starting up on http://127.0.0.1:43975/\n\nnova.osapi_compute.wsgi.server: INFO: (16827) accepted (\'127.0.0.1\', 54504)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [21/May/2013 06:18:22] \"GET /v2 HTTP/1.1\" 204 216 0.001070\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-934b0a45-7858-4b87-ae45-f56679adff31</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (16827) accepted (\'127.0.0.1\', 54505)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7810190>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7810190>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43975/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-21 06:18:22 16827 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43975/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [21/May/2013 06:18:22] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.234569\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for a5a5c43e61a547408fac2a63ef5a3b24 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:49173\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:49173/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (16827) wsgi starting up on http://127.0.0.1:49173/\n\nnova.osapi_compute.wsgi.server: INFO: (16827) accepted (\'127.0.0.1\', 40553)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [21/May/2013 06:18:23] \"GET /v2 HTTP/1.1\" 204 216 0.001047\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-d98077d3-bed8-40ff-8ca9-c9cfa1dde9bf</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (16827) accepted (\'127.0.0.1\', 40554)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x63d9510>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x63d9510>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:49173/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     name)\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-21 06:18:23 16827 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:49173/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [21/May/2013 06:18:23] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.250755\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.16\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.1\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.QapgW88tup\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/232\n[SCP] Copying console log.\n\n\n','<1814035722.14.1369030990159.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1034243372.6131810.1353512984418.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 10:49:44',-18000,'2012-11-21 15:49:44',NULL,'[openstack-dev] [nova] versioning scheme for\n	consumable	libraries','\n\n> > I just want to scare up some ideas on what the versioning scheme\n> > should look like for the nova virt library discussed previously[1]\n> > (primarily for ceilometer use).\n> \n> I\'m a bit confused by what you exactly mean by \"nova packages a\n> consumable library\". Would that just be a Python Nova module that\n> ceilometer agents would import ? Or a separate client library that\n> would result in a different binary package ?\n\nI was thinking the latter, i.e. a separately packaged library that\nceilometer would depend on with a versioned dependency. \n\nThe result would be that ceilometer could consume only the nova-virt\nAPI, and not all the other irrelevant aspects of nova. Currently by\ncontrast, the ceilo test-requires pulls in the entire nova tarball:\n\n  http://tarballs.openstack.org/nova/nova-master.tar.gz\n\n \n> In particular, where would that library code live ? In Nova tree ?\n> Or in a separate tree under nova\'s responsibility, like\n> python-novaclient ?\n\nThe former I think, if feasible, as the library would depend on a\nfair chunk of the nova innards, common utils, config options etc.\nso wouldn\'t be trivial to split off.\n\n\n> So far we have a 1:1 relationship between a version number and a\n> code tree, which keeps everything sane from a release management\n> perspective (for example, the corresponding code tarball has a\n> version number that covers everything in it). I\'d like to keep it\n> that way. So if this \"library\" code lives in Nova code, it should\n> just use Nova\'s own versioning.\n\nOK, well the reason I thought an independent version would be useful\nis that the API to this library would well end up being quite slow-\nevolving (i.e. not necessarily change across release cycles). We\ndo have somewhat of a precedent for independently versioned things\nwithin nova (DB migrations, RPC proxies, REST APIs) when the cadence\nof change doesn\'t necessarily match the master release cycle. But\nI guess the difference there is that there are not independent\nreleased artifacts related to DB migrations, RPC proxies, or REST APIs.\n\nOne potential nasty side-effect of the independent versioning that\njust occurred to me, is the circular dependencies that could result,\ne.g. nova-virt depends on some utils or whatever in nova-core, whereas\nnova-core depends on the virt layer provided by nova-virt. It would\nbe good to get a read from one of the nova folks on how feasible\nit would be to pick those dependencies apart.\n\nNow suppose the the *same* versioning was used as you suggest, would\nit still be possible to produce more than one artifact from the nova\nrelease process (e.g. multiple tarballs, binaries)?\n\n\n> If we are talking about a separate library, the versioning can\n> theoretically use anything (like we do with oslo libraries or Python\n> client libraries). But then it\'s better if a given library version\n> can handle /any/ Nova install, in the same way the Python client\n> libraries do. \n\nWell the relationship between the nova code and virt library is quite\na bit more intimate than the python-novaclient library (seeing as the\nlatter is mediated via a slowly evolving versioned REST API).\n\n\n> That option seems to be adding a new corner case\n> category of OpenStack project within the \"library\" project type,\n> with its own release model... \n\nYes, agreed, it does feel like a new thing without a direct precedent.\n\nCheers,\nEoghan\n\n\n','<50ACE445.8050904@openstack.org>',NULL),('<1034414265.894117.1347046167668.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-07 12:29:27',-25200,'2012-09-07 19:29:27',NULL,'[openstack-dev] Isn\'t it better to make cgroups_path\n configurable?','\n?Daniel,\n\n?Here is the modified _attach_lxc_volume() and _detach_lxc_volume().\nI tested _attach_lxc_volume() and it works fine.\nI couldn\'t test _detach_lxc_volume() because detach_volume() reports\nerror before calling it.\nThe error is:\n[\n2012-09-07 15:18:41 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/virt/libvirt/driver.py\", line 669, in detach_volume\n2012-09-07 15:18:41 TRACE nova.openstack.common.rpc.amqp ? ? raise exception.DiskNotFound(location=mount_device)\n2012-09-07 15:18:41 TRACE nova.openstack.common.rpc.amqp DiskNotFound: No disk at i\n]\n?I didn\'t have time to make the code more up-to-date using rootwrap. \n(Sorry for the old style programming.)\nnova version that I tested them with is:\n[\ncommit fb84ed7b32520b11d4a6273eb002b1f1abd2fbe8\nMerge: 4ccc770 5a470f8\nAuthor: Jenkins <jenkins at review.openstack.org>\nDate: ? Wed Sep 5 18:13:34 2012 +0000\n\n?? ?Merge \"fix issues with Nova security groups and Quantum\"\n]\n\n?Thanks,\n?David\n\n\n?? ?def _attach_lxc_volume(self, xml, virt_dom, instance_name):\n?? ? ? ?LOG.info(_(\'ISI: attaching LXC block device\'))\n\n?? ? ? ?lxc_container_root = self.get_lxc_container_root(virt_dom)\n?? ? ? ?lxc_host_volume = self.get_lxc_host_device(xml)\n?? ? ? ?lxc_container_device = self.get_lxc_container_target(xml)\n?? ? ? ?lxc_container_target = \"%s/%s\" % (lxc_container_root,\n?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lxc_container_device)\n\n?? ? ? ?# get id of the virt_dom\n?? ? ? ?spid = str(virt_dom.ID())\n?? ?\n?? ? ? ?# get PID of the init process\n?? ? ? ?ps_command = subprocess.Popen(\"ps -o pid --ppid %s --noheaders\" % \\\n?? ? ? ? ? ? ? ? ? ? ? ? ? spid, shell=True, stdout=subprocess.PIPE)\n?? ? ? ?init_pid = ps_command.stdout.read()\n?? ? ? ?init_pid = str(int(init_pid))\n?? ? ? ?retcode = ps_command.wait()\n?? ? ? ?assert retcode == 0, \"ps command returned %d\" % retcode\n?? ?\n?? ? ? ?# get major, minor number of the device\n?? ? ? ?s = os.stat(lxc_host_volume)\n?? ? ? ?major_num = os.major(s.st_rdev)\n?? ? ? ?minor_num = os.minor(s.st_rdev)\n?? ?\n?? ? ? ?# allow the device\n?? ? ? ?dev_whitelist = os.path.join(\"/cgroup/devices/libvirt/lxc/\",\n?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? instance_name,\n?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \'devices.allow\')\n?? ? ? ?# Allow the disk\n?? ? ? ?perm = \"b %d:%d rwm\" % (major_num, minor_num)\n?? ? ? ?cmd = \"echo %s | sudo tee -a %s\" % (perm, dev_whitelist)\n?? ? ? ?subprocess.Popen(cmd, shell=True)\n?? ?\n?? ? ? ?cmd_lxc = \'sudo lxc-attach -n %s -- \' % init_pid\n?? ? ? ?# check if \'mountpoint\' already exists\n?? ?\n?? ? ? ?cmd = \'/bin/mknod -m 777 /%s b %d %d \'\\\n?? ? ? ? ? ? % (lxc_container_device, major_num, minor_num)\n?? ? ? ?cmd = cmd_lxc + cmd\n?? ? ? ?subprocess.call(cmd, shell=True)\n\n\n?? ?@exception.wrap_exception()\n?? ?def _detach_lxc_volume(self, xml, virt_dom, instance_name):\n?? ? ? ?LOG.info(_(\'ISI: detaching LXC block device\'))\n\n?? ? ? ?lxc_container_root = self.get_lxc_container_root(virt_dom)\n?? ? ? ?lxc_container_device = self.get_lxc_container_target(xml)\n?? ? ? ?lxc_container_target = \"%s/%s\" % (lxc_container_root,\n?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?lxc_container_device)\n\n?? ? ? ?if lxc_container_target:\n?? ? ? ? ? ?disk.unbind(lxc_container_target)\n\n?? ? ? ?# get id of the virt_dom\n?? ? ? ?spid = str(virt_dom.ID())\n?? ? ? ?LOG.info(_(\'detach_volume: pid(%s)\') % spid)\n\n?? ? ? ?# get PID of the init process\n?? ? ? ?ps_command = subprocess.Popen(\"ps -o pid --ppid %s --noheaders\" \\\n?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?% spid, shell=True, stdout=subprocess.PIPE)\n?? ? ? ?init_pid = ps_command.stdout.read()\n?? ? ? ?init_pid = str(int(init_pid))\n?? ? ? ?retcode = ps_command.wait()\n?? ? ? ?assert retcode == 0, \"ps command returned %d\" % retcode\n?? ?\n?? ? ? ?cmd = cmd_lxc + \' /bin/rm \' + \'/\' + lxc_container_device\n?? ? ? ?LOG.info(_(\'detach_volume: cmd(%s)\') % cmd)\n?? ? ? ?subprocess.call(cmd, shell=True)\n\n\n\n\n----- Original Message -----\n> On Fri, Sep 07, 2012 at 08:29:25AM -0700, David Kang wrote:\n> >\n> > ?Hi Daniel,\n> >\n> > ?You are right.\n> > That\'s why we applied a kernel patch to make \'lxc-attach\' work.\n> \n> Ahh, that explains it ! I was worried I had missed something\n> obvious for a minute :-)\n> \n> > Now:\n> > $ ls /proc/self/ns/\n> > ipc mnt net pid uts\n> \n> Yep, that\'s exactly what we\'d need to see.\n> \n> >\n> > Kernel wise, we are using 2.6.38 with the kernel patch.\n> > We are using RHEL6.2.\n> > Initially we wanted to use RHEL6.2\'s default kernel with the kernel\n> > patch.\n> > But, either the patch doesn\'t exist for the default kernel, or the\n> > available patch did not work with the default kernel.\n> > So, we tried a few other kernels and found out that 2.6.38 works\n> > with the available patch.\n> \n> If you don\'t mind, could you post the patch you\'re using somewhere,\n> or mail it to me. I might use it to hack up libvirt support for\n> this while we\'re waiting for upstream kernel acceptance, so we\'ll\n> be ready ahead of time.\n> \n> Daniel\n> --\n> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org -o- http://virt-manager.org :|\n> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|\n\n\n','<20120907153515.GP23416@redhat.com>',NULL),('<1034485988.80.1386830117382.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:35:17',0,'2013-12-12 06:35:17',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-postgres-full-havana #7','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-postgres-full-havana/7/>\n\n\n\n','<468827344.70.1386743745019.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1035293045.207254.1377688649952.JavaMail.mail@webmail07>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-28 11:17:29',0,'2013-08-28 11:17:29',NULL,'[Openstack] Cinder: Creating test volume fails','Greetings,\n\nI\'ve gone through archives and performed searches, etc etc and have been unable to find a fix for this so I\'m hoping someone can shed some light on it for me here... Environment is (quite unfortunately) a desktop PC running VMware Player with an Ubuntu 12.04 LTS VM (kernel 3.2.50-030250-virtual).  I\'ve been successful in getting the identity service and image service both up and running and now I\'m stuck.. Here\'s the error, which FWIW was posted on the cinder-install.html page under the Grizzly install docs too:\n\n2013-08-27 13:04:27 ERROR [cinder.volume.iscsi] Failed to create iscsi target for volume id:volume-dbbeac52-b86a-4ed9-8a31-111f79a79092.\n2013-08-27 13:04:42 ERROR [cinder.volume.manager] volume volume-dbbeac52-b86a-4ed9-8a31-111f79a79092: create failed\n2013-08-27 13:04:42 ERROR [cinder.openstack.common.rpc.amqp] Exception during message handling\nTraceback (most recent call last):\nFile \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py\", line 430, in _process_data\n    rval = self.proxy.dispatch(ctxt, version, method, **args)\nFile \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n    return getattr(proxyobj, method)(ctxt, **kwargs)\nFile \"/usr/lib/python2.7/dist-packages/cinder/volume/manager.py\", line 288, in create_volume\n    LOG.error(_(\"volume %s: create failed\"), volume_ref[\'name\'])\nFile \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n    self.gen.next()\nFile \"/usr/lib/python2.7/dist-packages/cinder/volume/manager.py\", line 281, in create_volume\n    model_update = self.driver.create_export(context, volume_ref)\nFile \"/usr/lib/python2.7/dist-packages/cinder/volume/drivers/lvm.py\", line 487, in create_export\n    chap_auth)\nFile \"/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py\", line 168, in create_iscsi_target\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\nISCSITargetCreateFailed: Failed to create iscsi target for volume volume-dbbeac52-b86a-4ed9-8a31-111f79a79092.\n\nAdditional notes:\n- RabbitMQ is running and can be connected to\n- open-iscsi and iscsitarget are both installed/running\n- already changed the tgt/conf.d/ files as ppl referenced in the comments..\n\nAny help would be greatly appreciated.\n\nThx!\n\n\n',NULL,NULL),('<1035341461.46535741.1410299015275.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 17:43:35',-14400,'2014-09-09 21:43:35',NULL,'[openstack-dev] On an API proxy from baremetal to ironic','With my admittedly limited knowledge of the whole Ironic process, the question seems to me to be: \"If we don\'t implement a proxy, which people are going to have a serious problem?\"\n\nDo we have an data on which users/operators are making use of the baremetal API in any extensive fashion?  If nobody\'s using it, or the people using it aren\'t using in an\nextensive fashion, I think we don\'t need to make a proxy for it.  Strengthening this\nargument is the fact that we would only be proxying the first two calls, so it wouldn\'t\nbe a drop-in replacement anyway.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Michael Still\" <mikal at stillhq.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, September 9, 2014 5:24:11 PM\n> Subject: [openstack-dev] On an API proxy from baremetal to ironic\n> \n> Hi.\n> \n> One of the last things blocking Ironic from graduating is deciding\n> whether or not we need a Nova API proxy for the old baremetal\n> extension to new fangled Ironic API. The TC has asked that we discuss\n> whether we think this functionality is actually necessary.\n> \n> It should be noted that we\'re _not_ talking about migration of\n> deployed instances from baremetal to Ironic. That is already\n> implemented. What we are talking about is if users post-migration\n> should be able to expect their previous baremetal Nova API extension\n> to continue to function, or if they should use the Ironic APIs from\n> that point onwards.\n> \n> Nova had previously thought this was required, but it hasn\'t made it\n> in time for Juno unless we do a FFE, and it has been suggested that\n> perhaps its not needed at all because it is an admin extension.\n> \n> To be super specific, we\'re talking about the \"baremetal nodes\" admin\n> extension here. This extension has the ability to:\n> \n>  - list nodes running baremetal\n>  - show detail of one of those nodes\n>  - create a new baremetal node\n>  - delete a baremetal node\n> \n> Only the first two of those would be supported if we implemented a proxy.\n> \n> So, discuss.\n> \n> Thanks,\n> Michael\n> \n> --\n> Rackspace Australia\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAEd1pt5hDoROLD6UmJwvwj4Jq7xvaH=AWk1QHHmqbbR=bzvJRw@mail.gmail.com>',NULL),('<1035792687.24.1367647618360.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-04 06:06:58',0,'2013-05-04 06:06:58',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python27-stable-grizzly #24','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/24/changes>\n\n\n\n','<1088581464.2.1367561225131.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1036177694.34130556.1386601740912.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 10:09:00',-18000,'2013-12-09 15:09:00',NULL,'[openstack-dev] [Solum] [Security]','\n\n----- Original Message -----\n> I created some relatively high level security best practices that I\n> thought would apply to Solum.  I don\'t think it is ever too early to get\n> mindshare around security so that developers keep that in mind throughout\n> the project.  When a design decision point could easily go two ways,\n> perhaps these guidelines can sway direction towards a more secure path.\n> \n> This is a living document, please contribute and let\'s discuss topics.\n> I\'ve worn a security hat in various jobs so I\'m always interested. :)\n> Also, I realize that many of these features may not directly be\n> encapsulated by Solum but rather components such as KeyStone or Horizon.\n> \n> https://wiki.openstack.org/wiki/Solum/Security\n> \n> I would like to build on this list and create blueprints or tasks based on\n> topics that the community agrees upon.  We will also need to start\n> thinking about timing of these features.\n> \n\nA few suggested additions:\n\n  # Request load management\n\n  A number of proposed Solum operations are computationally/resource expensive.  The fulfilment of those operations should be predictable and linear, and resist denial-of-service or amplification attacks on a per user / project / service basis as needed.  This may involve queueing requests, having high water marks for these queues (where additional requests are rejected until existing requests clear), throttling delays on queue processing, separate work pools, or other load management techniques.  The system must remain available for other tenants even if a subset are targeted or malicious.\n\n  # Secure Storage (addendum)\n\n  Confidential data such as credential information should not be stored unencrypted in non-volatile storage. This is a defense in depth topic to place a barrier in front of attackers in the event that they gain access to some of the Solum control plane. \n\n  ADD: Where possible, distribute security responsibilities to user application storage / execution environments.  Even encrypted data in non-volatile storage is potentially valuable (especially given the possibility bugs in implementation), creating a high value target.  Pushing secure data out as far as possible reduces the value of any individual data store to an attacker.\n\n\n\n','<CEBB7B2A.123DD%paul.montgomery@rackspace.com>',NULL),('<1036432164.18.1380781764346.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-03 06:29:24',0,'2013-10-03 06:29:24',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #29','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/29/>\n\n------------------------------------------\n[...truncated 21062 lines...]\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\nInitialized empty Git repository in /tmp/tempest-unitPfLYMy/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitc6OpxI/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          218.888\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  171.621\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  73.293\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        38.870\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      38.708\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         34.948\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     31.343\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_manual_disk_config[gate]   30.018\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        29.156\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       28.595\n\n----------------------------------------------------------------------\nRan 1291 tests in 1243.182s\n\nOK (skipped=66)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-445134-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-445134.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-445134/29/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<735365874.11.1380522476762.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1036673267.34198951.1386606741776.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 11:32:21',-18000,'2013-12-09 16:32:21',NULL,'[openstack-dev] [Solum] Second working group meeting on language\n	packs today','Hi,\n\nWe will hold our second Git Integration working group meeting on IRC in #solum on Monday, December 9, 2013 1700 UTC / 0900 PST.\n\nAgenda for today\'s meeting:\n	* Administrative:\n		* Decide whether to continue this meeting at the same time in January\n	* Topics:\n		* Determine minimal set of milestone-1 functionality\n                * Get volunteers for milestone-1 example language packs\n                * Discuss names\n	* General discussion\n\n----- Original Message -----\n> Meeting 1 was conducted on Monday and consisted mostly of freeform\n> discussions, clarification, and QA:\n> http://irclogs.solum.io/2013/solum.2013-12-02-17.05.html.  The next meeting\n> is Monday, December 9, 2013 1700 UTC.\n> \n> Wiki:\n> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts\n> \n> Action and open topics:\n> \n> * Updated proposal wiki with personas\n> * Discussed whether a single command or multiple commands are needed to\n> transform an image (one for build+test, or two)\n> ** Believe 1 is sufficient to encapsulate the entire transformation, use\n> cases are needed to justify extras.\n> * The parent blueprint and wiki page represents the general design and\n> philosophy, and specific child blueprints will target exact scenarios for\n> milestones\n> * [NEXT] Helpful discussion on the injection of artifacts such that the\n> transformation script can operator on them.  No clear design, but lots of\n> suggestions\n> * Strong consensus that the the transformation script should depend on Solum\n> or OpenStack concepts - a developer should be able to debug a transformation\n> by using the image themselves, or run it outside of Solum.\n> * Should anticipate that the transformation environment and execution\n> environment might have different resource needs - i.e. Java maven may\n> require more memory than Java execution\n> * [NEXT] Should the transformation happen inside the environment the app is\n> destined for (i.e. able to reach existing deployed resources) or in a\n> special build env?\n> ** No consensus, arguments for and against\n> ** Transformation environments may need external network access, production\n> environments may not allow it\n> * Transformation should remove or disable debugging or compile tools prior to\n> execution for security - this is a recommendation to image authors\n> * The final execution environment may dynamically define exposed ports that\n> Solum must be aware of\n> ** For M1 the recommendation was to focus on upfront definition via metadata\n> * [AGREED] No external metadata service would be part of Solum, any metadata\n> that needs to be provided to the image during transformation would be done\n> via injection and be an argument to prepare\n> ** That might be via userdata or docker environment variables and bind\n> mounted files\n\n\n','<561404262.32084036.1386126760929.JavaMail.root@redhat.com>',NULL),('<1037487772.62.1352766544561.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-13 00:29:04',0,'2012-11-13 00:29:04',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-full #12','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/12/>\n\n\n\n','<1102280166.50.1352686010403.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1037633827.23518829.1350461133439.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-17 04:05:33',-14400,'2012-10-17 08:05:33',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','\n\n> Apache 2.0 License, of cousre. :)\n\nExcellent!\n\nExactly the answer I wanted to hear :)\n\nCheers,\nEoghan\n\n> We want to improve further Synaps as a community project after\n> opening.\n> Thanks,\n> Joonwon\n> \n> ------- Original Message -------\n> Sender : Eoghan Glynn<eglynn at redhat.com>\n> Date : Oct 17, 2012 10:47 (GMT+09:00)\n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> \n> \n> ----- Original Message -----\n> > Endre,\n> > I\'m still trying to early open our Synaps project day by day.\n> > \n> > Good news: we\'ve almost finished our internal review so that we can\n> > upload source codes this week. Hopefully we can begin tomorrow.\n> \n> This quick progress on opening up the source is very welcome.\n> \n> One question - what form of licensing will be applied to the initial\n> source code upload that you\'re planning for this week?\n> \n> Cheers,\n> Eoghan\n> \n> > I hope we can get some feedback from developers gathered in the\n> > Summit\n> > who have interests in Synaps this week. If it\'s possible, I will\n> > try\n> > to\n> > persuade others to hasten to open sources first even without enough\n> > documentation and other preparations.\n> > Personally I\'m really curious what you (esp, developers from\n> > ceilometer\n> > and heat) will talk about our project and current status.\n> > Both positive and negative feedback will be helpful, IMO.\n> > \n> > Thanks,\n> > Joonwon\n> > \n> > \n> > ------- Original Message -------\n> > Sender : Endre Karlson\n> > Date : Oct 16, 2012 16:04 (GMT+09:00)\n> > Title : Re: [openstack-dev] Introducing Synaps project that\n> > provides\n> > AWS CloudWatch compatible API\n> > \n> > Any news on this ? :)\n> > \n> > \n> > Endre.\n> > \n> > \n> > 2012/10/12 Joonwon Lee\n> > \n> > Dear Mark,\n> > Thanks for your kind advice again.\n> > \n> > Now I understand that there is a license issue. I also heard from\n> > inside that we may have a patent issue unless our patent team\n> > verify\n> > Synaps won\'t violate any other patents. We definitely need some\n> > time\n> > for preparing the contribution of our project to the open\n> > community.\n> > Again I will try to shorten it, but I cannot let you see our codes\n> > before the Design Summit next week. I\'m really sorry about that.\n> > \n> > Mark, Eoghan, Steve, Endre, Nick, Doug, Sam, Thierry, thanks you\n> > all\n> > for having interests in our project. We will continue our efforts\n> > to show Synaps to you soon.\n> > \n> > Still I welcome any comments, advices, questions, etc. about\n> > Synaps.\n> > \n> > Regards,\n> > Joonwon Lee\n> > \n> > \n> > \n> > ------- Original Message -------\n> > Sender : Mark McLoughlin\n> > \n> > Date : Oct 12, 2012 20:53 (GMT+09:00)\n> > Title : Re: Re: [openstack-dev] Introducing Synaps project that\n> > provides AWS CloudWatch compatible API\n> > \n> > \n> > On Fri, 2012-10-12 at 11:23 +0000, Joonwon Lee wrote:\n> > \n> > > Hi, Mark.\n> > > I expect that we need a few weeks for opening Synaps. (maybe\n> > > early\n> > > Nov.)\n> > > However, as I completely agree with Mark, I tried my best to find\n> > > a\n> > > way.\n> > \n> > \n> > Thank you for your efforts\n> > \n> > \n> > > We\'re going to send directly the source codes of Synaps to you\n> > > tomorrow:\n> > >     Mark McLoughlin, Eoghan Glynn, Steve Hardy (Heat developers,\n> > >     Red Hat)\n> > > I hope it will help you deciding the direction next week at the\n> > > Summit.\n> > > You may see them and ask any questions, but don\'t make them\n> > > public\n> > > yet.\n> > > (Are there other people who want to see our codes first and work\n> > > with us?)\n> > \n> > \n> > Actually, I don\'t think this is such a good idea. If you shared the\n> > code\n> > outside Samsung, the license you\'re sharing it under would not be\n> > clear\n> > at this point and if the code doesn\'t eventually licensed under the\n> > Apache License it potentially could cause legal trouble.\n> > \n> > Thanks,\n> > Mark.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n\n\n','<26328517.130911350449679468.JavaMail.weblogic@epml10>',NULL),('<1037677350.55.1383458821064.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:07:01',0,'2013-11-03 06:07:01',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-keystone-python27-stable-grizzly #46','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/46/>\n\n\n\n','<1612658066.43.1383372794425.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1037DAD2-3700-4D0D-A56C-16F18BB2B9CF@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-04-27 00:48:01',7200,'2013-04-26 22:48:01',NULL,'[Openstack-docs] OpenStack HA Guide - Moving forward to Active\n	/ Active Setup','Oh the guide as is works perfectly - you mean an update with the latest OpenStack services were considered?\n\n\nLe 27 avr. 2013 ? 00:46, Emilien Macchi <emilien.macchi at enovance.com> a ?crit :\n\n> My opinion would be to keep only Active / Active mode for at least\n> OpenStack services, since current active / passive mode is not\n> completely documented and I have no time to manage it.\n> \n> I think the discussion is now open !\n> \n> Emilien Macchi\n> ----------------------------------------------------\n> # OpenStack Engineer\n> // eNovance Inc.              http://enovance.com\n> // ? emilien at enovance.com     ? +33 (0)1 49 70 99 80\n> // 10 rue de la Victoire 75009 Paris\n> \n> On 04/27/2013 12:17 AM, Razique Mahroua wrote:\n>> Hey Emilien-man, not a time for us to work now hehe\n>> Well I think definitely think keeping that one in place is something important - so I propose a separate section definitely\n>> Active/active explaining as well used packages as well since the current guide doesn\'t make use of the services you use\n>> \n>> Razique\n>> \n>> Le 26 avr. 2013 ? 23:56, Emilien Macchi <emilien.macchi at enovance.com> a ?crit :\n>> \n>>> Hi,\n>>> \n>>> \n>>> Today the OpenStack HA guide written by Florian Haas and my self needs\n>>> to be updated from active / passive to active / active mode.\n>>> Since some services have been updated in Grizzly, I would like to submit\n>>> a new documentation explaining how to configure this setup :\n>>> \n>>> - API nodes (all OpenStack APIs) -> load balanced by HAproxy (I\'ll share\n>>> my running configuration)\n>>> - Scheduler nodes (*-scheduler + nova-conductor) -> Multiple running :\n>>> horizontal scale\n>>> - Compute nodes (nova-compute + Quantum L3 Agent + Quantum DHCP Agent +\n>>> Quantum L2 Agent + Quantum Metadata Agent) : no HA, but scaling of\n>>> Quantum L3 & DHCP agents\n>>> - Storage node (cinder-volume) -> can\'t be run in full HA as far I know.\n>>> - RabbitMQ cluster\n>>> - MySQL Cluster (Galera)\n>>> \n>>> Then, I\'ll like to know what is the best choice :\n>>> - Split the guide in two parts : Active / Active & Active / Passive ?\n>>> - Drop Active / Passive part and updating it for Active / Active setup ?\n>>> \n>>> Before submitting my patches, let me know your thoughts.\n>>> \n>>> Note : Please don\'t hesitate to share your feedback if you also run\n>>> OpenStack in production with HA.\n>>> \n>>> \n>>> Cheers,\n>>> \n>>> -- \n>>> Emilien Macchi\n>>> ----------------------------------------------------\n>>> # OpenStack Engineer\n>>> // eNovance Inc.              http://enovance.com\n>>> // ? emilien at enovance.com     ? +33 (0)1 49 70 99 80\n>>> // 10 rue de la Victoire 75009 Paris\n>>> \n>>> \n>>> _______________________________________________\n>>> Openstack-docs mailing list\n>>> Openstack-docs at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n\n\n\n','<517B03B5.60101@enovance.com>',NULL),('<1038244048.39.1375596173580.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-04 06:02:53',0,'2013-08-04 06:02:53',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #57','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/57/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-181609 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #212082 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-all] $ /bin/bash -xe /tmp/hudson5575053287759239595.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-all] $ /bin/bash -xe /tmp/hudson4208412124089472743.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_ALL=1\n+ DEVSTACK_GATE_TEMPEST_ALL=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-181609\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-181609/57\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-181609/57/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-181609/57/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<10382b02.4e1a.1494f7f9e88.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 10:46:44',28800,'2014-10-27 02:46:44',NULL,'[openstack-dev] [neutron] vm can not transport large file under\n neutron ml2 + linux bridge + vxlan','Thanks, it helps a lot. But i want to know, why the mtu discovery can not find the appropriate mtu to send?\n\n\nIn http://www.chriscowley.me.uk/blog/2014/03/31/openstack-neutron-performance-problems/, it says that\n \"Everything matches, however I was using GRE tunnels, which add a header to each frame. This was pushing them over 1500 on entry to br-tun causing massive network fragmentation, which basically destroyed Openvswitch every time I performed a large transfer. It showed up when deploying an image, because that is hitting the Glance API over http.\"\n\n\nDose it means that the pmtu is not work?\n\n\n\n\n\nAt 2014-10-27 09:51:31, \"Damon Wang\" <damon.devops at gmail.com> wrote:\n\nHi Tangqing,\n\n\nThis is a well-known problem, it is because GRE/VxLan \'s packet header use some bytes, length of data packet should reduced.\n\nYou can get refer to bellow pages:\nhttp://www.chriscowley.me.uk/blog/2014/03/31/openstack-neutron-performance-problems/\nhttps://ask.openstack.org/en/question/25947/openstack-neutron-stability-problems-with-openvswitch/\nhttps://openstack.redhat.com/forum/discussion/302/quantumneutron-and-ip-packet-mtus-questions-answers-and-suggestions/p1\n\n\nHope it helps,\n\nDamon\n\n\n2014-10-27 9:18 GMT+08:00 Li Tianqing <jazeltq at 163.com>:\n\nHello,\n    Right now, we test neutron under havana release. We configured network_device_mtu=1450 in neutron.conf, \n   After create vm, we found the vm interface\'s mtu is 1500, the ping, ssh, is ok. But if we scp large file between vms\n   then scp display \'stalled\'. And iperf is also can not completed.\n   If we configured vm\'s mtu to 1450, then iperf, scp all is ok.\n   If we iperf with -M 1300, then the iperf is ok too.\n   The vms path mtu discovery is set by default. I do not know why the vm whose mtu is 1500 can not send large file.\n\n\n\n\nThanks.\n\n\n\n\n\n--\n\nBest\n    Li Tianqing\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141027/3c367a25/attachment.html>\n\n','<CABZYMH73Wd41zgZNqRUJPGM5BsrGKhiux_qbcZswj1Q2OcyjGw@mail.gmail.com>',NULL),('<1038498484.5.1386915571959.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:19:31',0,'2013-12-13 06:19:31',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-nova-docs-havana #9','See <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/9/changes>\n\n\n\n','<1541093341.66.1386741995572.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1039318145.38028501.1387207445503.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 10:24:05',-18000,'2013-12-16 15:24:05',NULL,'[openstack-dev] [Solum] Third working group meeting on language\n	packs today','Hi,\n\nWe will hold our third Git Integration working group meeting on IRC in #solum on Monday, December 16, 2013 1700 UTC / 0900 PST.  Previous meeting notes are here [4]\n\nAgenda for today\'s meeting:\n	* Administrative:\n	* Topics:\n		* Discuss lang-pack-examples spec for inclusion into M1 [1]\n                * Discuss specify-lang-pack proposal [2] \n                  * Feedback on etherpad items created last week [3]\n                * Discuss alternative names for language-pack and set up a poll\n	* General discussion\n\n[1] https://blueprints.launchpad.net/solum/+spec/lang-pack-examples\n[2] https://blueprints.launchpad.net/solum/+spec/specify-lang-pack\n[3] https://etherpad.openstack.org/p/Solum-Language-pack-json-format\n[4] http://irclogs.solum.io/2013/solum.2013-12-09-17.01.html\n\n\n','<1036673267.34198951.1386606741776.JavaMail.root@redhat.com>',NULL),('<1039FD72-55AF-4677-B1FF-7EF4ED75EC65@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-19 16:35:36',-25200,'2014-05-19 23:35:36',NULL,'[openstack-dev] Request to consider merging OVS ARP responder','The patch in question is doing an invasive runtime check [1] to determine whether arp header modification is supported by ovs.  I seem to remember a lack of consensus on whether invasive runtime checks were acceptable around vxlan detection, and I would appreciate confirmation from other cores that this approach is considered acceptable for this patch.\n\n\nm.\n\n1: https://review.openstack.org/#/c/49227/41/neutron/agent/linux/ovs_lib.py\n\nOn May 19, 2014, at 1:07 PM, Assaf Muller <amuller at redhat.com> wrote:\n\n> Hello Mark, Bob and Kyle,\n> \n> You\'ve all been involved with the OVS ARP responder patch:\n> https://review.openstack.org/#/c/49227/\n> \n> I kindly request that you revisit this patch - It\'s ready from\n> my point of view, if that means anything. The last few patchsets\n> have been nitpicks. Looking at the history, the patch has already\n> had a large amount of +1\'s and +2\'s through it\'s various stages.\n> \n> I think it\'d be technically superior if this patch was merged\n> before further progress is made in the DVR patch series.\n> \n> \n> Thanks for your time,\n> Assaf Muller, Cloud Networking Engineer\n> Red Hat\n\n\n\n','<1377128552.9606939.1400530034065.JavaMail.zimbra@redhat.com>',NULL),('<1040360932.21912369.1406248696208.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-07-24 20:38:16',-14400,'2014-07-25 00:38:16',NULL,'[Openstack-docs] Architecture Design Guide image SVG format.','Hi Vinny,\n\nDo you still have SVG format files for the images you created for the architecture design guide? Would it be possible for you to upload them somewhere so that we can get them into git? Apologies if someone has already followed up on this :).\n\nThanks,\n\nSteve\n\n\n',NULL,NULL),('<1040983847.16.1382854167273.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-27 06:09:27',0,'2013-10-27 06:09:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #46','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/46/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4cc3450>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4cc3450>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3e2ca50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3e2ca50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-707b7e35-6856-4832-94be-89b61179412f\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:09:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:09:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:09:05+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:09:05-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:09:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x560d790>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1708d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.53 secs:\n    13.70    TestGlanceControl.test_bouncing\n    13.36    TestScrubber.test_delayed_delete\n    13.22    TestGlanceControl.test_reload\n    13.08    TestGlanceControl.test_respawn\n    12.17    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 439.271s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-46\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.LqrBXd96zV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/46\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/46/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise36/46\n[SCP] Copying console log.\n\n\n','<196127485.12.1382767903595.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1041038991.4827042.1399581239921.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 16:33:59',-14400,'2014-05-08 20:33:59',NULL,'[openstack-dev] Informal meeting before SR-IOV summit\n	presentation','----- Original Message -----\n> > It would be nice to have an informal discussion / unconference session\n> > before the actual summit session on SR-IOV. During the previous IRC\n> > meeting, we were really close to identifying the different use cases.\n> > There was a dangling discussion on introducing another level of\n> > indirection between the vnic_types exposed via the nova boot API and how\n> > it would be represented internally. It would be ideal to have these 2\n> > discussions converged before the summit session.\n> \n> What would be the purpose of doing that before the session? IMHO, a\n> large part of being able to solve this problem is getting everyone up to\n> speed on what this means, what the caveats are, and what we\'re trying to\n> solve. If we do some of that outside the scope of the larger audience, I\n> expect we\'ll get less interaction (or end up covering it again) in the\n> session.\n> \n> That said, if there\'s something I\'m missing that needs to be resolved\n> ahead of time, then that\'s fine, but I expect the best plan is to just\n> keep the discussion to the session. Afterwards, additional things can be\n> discussed in a one-off manner, but getting everyone on the same page is\n> largely the point of having a session in the first place IMHO.\n\nRight, in spite of my previous response...looking at the etherpad there is nothing there to frame the discussion at the moment:\n\nhttps://etherpad.openstack.org/p/juno-nova-sriov-support\n\nI think populating this should be a priority rather than organizing another session/meeting?\n\nSteve\n\n\n','<536BE96A.8050306@danplanet.com>',NULL),('<1041080310.27.1359701519874.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-01 06:51:59',0,'2013-02-01 06:51:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #123','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/123/>\n\n------------------------------------------\n[...truncated 12313 lines...]\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... ok\nCREATE, GET, DELETE Volume ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nVolume is attached and detached successfully from an instance ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nERROR\nERROR\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 227, in run\n    self.tearDown()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 350, in tearDown\n    self.teardownContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 366, in teardownContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 150, in tearDownClass\n    cls.client.wait_for_resource_deletion(volume)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 260, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\nDetails: Request timed out\n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/7c7c761a878f408286417d50f86651b5/volumes/33864e03-9cb5-4f7c-a879-337357dacc9d\ntempest.common.rest_client: ERROR: Request Body: None\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Fri, 01 Feb 2013 06:33:17 GMT\', \'status\': \'404\', \'content-length\': \'78\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-8ea63d06-b74c-4352-9e9d-c8d97f5eec78\'}\ntempest.common.rest_client: ERROR: Response Body: {\"itemNotFound\": {\"message\": \"The resource could not be found.\", \"code\": 404}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 79, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/new/tempest/tempest/services/volume/json/volumes_client.py\", line 132, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Request timed out\nDetails: Volume volume199812 failed to reach available status within the required time (300.0 s).\n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/7c7c761a878f408286417d50f86651b5/volumes/33864e03-9cb5-4f7c-a879-337357dacc9d\ntempest.common.rest_client: ERROR: Request Body: None\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Fri, 01 Feb 2013 06:33:17 GMT\', \'status\': \'404\', \'content-length\': \'78\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-8ea63d06-b74c-4352-9e9d-c8d97f5eec78\'}\ntempest.common.rest_client: ERROR: Response Body: {\"itemNotFound\": {\"message\": \"The resource could not be found.\", \"code\": 404}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 44 tests in 1619.175s\n\nFAILED (SKIP=8, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/rabbitmq/rabbit at devstack-1359687055-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/rabbitmq/rabbit at devstack-1359687055.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/123/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1041191395.25.1385446683066.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-26 06:18:03',0,'2013-11-26 06:18:03',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-havana #4','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-havana/4/>\n\n\n\n','<682407579.8.1385014648898.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1041241339.155815.1422205856180.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-25 12:10:56',-18000,'2015-01-25 17:10:56',NULL,'[openstack-dev] [fedora] Re: upstream f21 devstack test','I have tried the old \'vmlinuz-3.17.4-301.fc21.x86_64\' kernel in my env,\n with this version volume attachment related tests are failing, but in the test case\nso I do not see the secondary network failures.\n\nIn my env with \'3.17.8-300.fc21.x86_64\' everything passes with nnet,\nI would say 3.17.4-301.fc21.x86_64 version of kernel is buggy.\n\nOn the gate vm the new kernel(3.17.8-300.fc21.x86_64) was installed before the boot,\nbut the boot manager config still picks the old kernel. I tried to switch to the new\nkernel in `your vm`, but the machine failed to reboot, maybe I miss configured the extlinux.conf or we have\nsome environment specific issue.\nI lost your onhold vm. :(\n\nLooks like https://bugs.launchpad.net/nova/+bug/1353939 was always triggered,  ie.\nthe vm failed to delete which caused wrong iptables rules left behind, which caused\nseveral subsequent ssh test failure if the test used the same fixedip as the test_rescued_vm_detach_volume.\n\nTempest could be stricter and fail the test suite at tearDownClass when the vm moves to ERROR state at delete.\n\n\n----- Eredeti ?zenet -----\n> Felad?: \"Attila Fazekas\" <afazekas at redhat.com>\n> C?mzett: \"Ian Wienand\" <iwienand at redhat.com>\n> M?solatot kap: \"Alvaro Lopez Ortega\\\", \\\"Jeremy Stanley\\\", \\\"Sean Dague\\\" <sean at dague.net>, \\\"dean Troyer\\\"\n> <dtroyer at gmail.com>, \\\"OpenStack Development Mailing List\" <fungi at yuggoth.org>\n> Elk?ld?tt ?zenetek: Cs?t?rt?k, 2015. Janu?r 22. 18:16:01\n> T?rgy: [fedora] Re: upstream f21 devstack test\n> \n> \n> \n> ----- Mail original -----\n> > De: \"Attila Fazekas\" <afazekas at redhat.com>\n> > ?: \"Ian Wienand\" <iwienand at redhat.com>\n> > Cc: \"Alvaro Lopez Ortega\" <aortega at redhat.com>, \"Jeremy Stanley\"\n> > <fungi at yuggoth.org>, \"Sean Dague\" <sean at dague.net>,\n> > \"dean Troyer\" <dtroyer at gmail.com>, \"OpenStack Development Mailing List (not\n> > for usage questions)\"\n> > <openstack-dev at lists.openstack.org>\n> > Envoy?: Lundi 19 Janvier 2015 18:02:17\n> > Objet: Re: upstream f21 devstack test\n> > \n> > Per request moving this thread to the openstack-dev list.\n> > \n> > I was not able to reproduce the issue so far either on the\n> > vm you pointed me or in any of my VMs.\n> > \n> > Several things I observed on `your` machine:\n> > 1. The installed kernel is newer then the actually used (No known related\n> > issue)\n> \n> strace on libvirt does not wants to terminate properly on Ctrl+C,\n> probably this not the only miss behavior related to processes.\n> \n> The kernel version and hyper-visor type might be relevant to the\n> \'Exception during message handling: Failed to terminate process 32495 with\n> SIGKILL: Device or resource busy\'\n> \n> According to the strace the signal was sent, and the process was killed,\n> but it is zombie until the strace not killed.\n> \n> \n> > 2. On the First tempest (run logs are collected [0]) lp#1353939 was\n> > triggered, but not related\n> I was wrong.\n> This was related. An exception during instance delete can live behind\n> iptables rules, so not the correct security group rules will be applied.\n> \n> In the other jenkins jobs this situation is rare.\n> \n> On `your` vm \'tox -eall test_rescued_vm_detach_volume\' triggers the issue\n> almost always, in other env I was not able tor reproduce it so far.\n> \n> > 3. After tried to reproduce the use many-many times I hit lp#1411525, the\n> > patch\n> >    which introduced is already reverted.\n> > 4. Once I saw \'Returning 400 to user: No nw_info cache associated with\n> > instance\' what I haven\'t\n> >    seen with nova network for a long time.  (once in 100 run)\n> > 5. I see many annoying iscsi related logging, It also does not related to\n> > the\n> > connection issue,\n> >    IMHO the tgtadm can be considered as DEPRECATED thing, and we should\n> >    switch to lioadm.\n> > \n> > So far, No Log entry found in connection to connection issue\n> >  which would worth to search on logstash.\n> > \n> > The nova network log is not sufficient to figure out the actual netfilter\n> > state at any moment.\n> > According the log it should have update the chains with something, but who\n> > knows..\n> > \n> > With the ssh connection issues you can do very few things as post-mortem\n> > analyses.\n> > Tempest normally deletes the related resources, so less evidences\n> > remaining.\n> > If the issue is reproducible some cases enough to alter the test to do not\n> > destroy evidences,\n> > but very frequently some kind of real debugger required.\n> > \n> > Several suspected thing:\n> > * The vm was able to acquire address via dhcp -> successful boot, has L2\n> > connectivity.\n> > * No evidence found for a dead qemu, no special libvirt operation requested\n> > before failure.\n> > * nnet claims it added the floating ip to the br100\n> > * L3 issue / security group rules ?..\n> > \n> > The basic network debug was removed form tempest[1]. I would like to\n> > recommend to revert that change\n> > in order to have an idea at least the interfaces and netfilter was or\n> > wasn\'t\n> > in a good shape [1].\n> > \n> Full tempest runs was required to reproduce the issue and reverting [1] to\n> see\n> what is really happened.\n> \n> test_rescued_vm_detach_volume + any ssh test can be sufficient to reproduce\n> the issue.\n> \n> > I also created a vm with enabled firewalld (normally it is not in my\n> > devstack\n> > setups), the 3\n> > mentioned test case working fine even after running these tests for hours.\n> > However the \'/var/log/firewalld\' contains COMMAD_FAILURES as in `your` vm.\n> > \n> > I will try run more full tempest+nnet at F21 in my env to have more sample for\n> > success rate.\n> > \n> > So far I reproduced 0 ssh failure,\n> > so I will scan the logs[0] again more carefully on `your` machine,\n> > maybe I missed something, maybe those tests interfered with something less\n> > obvious.\n> > \n> > I\'ll check the other gate f21 logs (~100 job/week),\n> >  does anything happened when the issue started and/or is the issue still\n> >  exists.\n> > \n> > \n> > So, I have nothing useful at the moment, but I did not given up.\n> > \n> > [0]\n> > http://logs.openstack.org/87/139287/14/check/check-tempest-dsvm-f21/5f3d210/console.html.gz\n> > [1] https://review.openstack.org/#/c/140531/\n> > \n> > \n> > PS.:\n> > F21\'s HaProxy is more sensitive to services which stops listening,\n> > and it will not be evenly balanced.\n> > For a working F21 neutron job better listener is required:\n> > https://review.openstack.org/#/c/146039/ .\n> >  \n> > \n> > \n> > ----- Original Message -----\n> > > From: \"Ian Wienand\" <iwienand at redhat.com>\n> > > To: \"Attila Fazekas\" <afazekas at redhat.com>\n> > > Cc: \"Alvaro Lopez Ortega\" <aortega at redhat.com>, \"Jeremy Stanley\"\n> > > <fungi at yuggoth.org>, \"Sean Dague\" <sean at dague.net>,\n> > > \"dean Troyer\" <dtroyer at gmail.com>\n> > > Sent: Friday, January 16, 2015 5:24:38 AM\n> > > Subject: upstream f21 devstack test\n> > > \n> > > Hi Attila,\n> > > \n> > > I don\'t know if you\'ve seen, but upstream f21 testing is happening for\n> > > devstack jobs.  As an experimental job I was getting good runs, but in\n> > > the last day and a bit, all runs have started failing.\n> > > \n> > > The failing tests are varied; a small sample I pulled:\n> > > \n> > > [1]\n> > > tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes\n> > > [2]\n> > > tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n> > > [3]\n> > > tempest.scenario.test_shelve_instance.TestShelveInstance.test_shelve_instance[compute,image,network]\n> > > \n> > > The common thread is that they can\'t ssh to the cirros instance\n> > > started up.\n> > > \n> > > So far I can not replicate this locally.  I know there were some\n> > > firewalld/neutron issues, but this is not a neutron job.\n> > > \n> > > Unfortunately, I\'m about to head out the door on PTO until 2015-01-27.\n> > > I don\'t like the idea of this being broken while I don\'t have time to\n> > > look at it, so I\'m hoping you can help out.\n> > > \n> > > There is a failing f21 machine on hold at\n> > > \n> > >  jenkins at xx.yy.zz.qq\n> > Sanitized.\n> > > \n> > > I\'ve attached a private key that should let you log in.  This\n> > > particular run failed in [4]:\n> > > \n> > >  tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_compute_with_volumes\n> > >  tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\n> > > \n> > > Sorry I haven\'t got very far in debugging this.  Nothing obviously\n> > > jumped out at me in the logs, but I only had a brief look.  I\'m hoping\n> > > as the best tempest guy I know you can find some time to take a look\n> > > at this in my absence :)\n> > > \n> > > Thanks,\n> > > \n> > > -i\n> > > \n> > > [1]\n> > > http://logs.openstack.org/03/147303/1/check/check-tempest-dsvm-f21/3d0c86d/console.html\n> > > [2]\n> > > http://logs.openstack.org/09/147209/2/check/check-tempest-dsvm-f21/83444c9/console.html\n> > > [3]\n> > > http://logs.openstack.org/71/141971/5/check/check-tempest-dsvm-f21/95b1574/console.html\n> > > [4] https://jenkins06.openstack.org/job/check-tempest-dsvm-f21/8/console\n> > > \n> > \n> \n\n\n','<769603908.15379817.1421946961809.JavaMail.zimbra@redhat.com>',NULL),('<10413415.98.1397181462473.JavaMail.Nick@Nick-Laptop>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-11 10:46:02',28800,'2014-04-11 02:46:02',NULL,'[Openstack-operators] Multi Host flag in Havana (neutron),\n central network node is perfect chocking point..','Hi,\n\nYes, there are scheduler options in neutron.conf which can schedule network/router/load balancer to different agents. You also can check neutron/scheduler directory in Icehouse RC, you can find LeastRouterScheduler which will greatly help for resource usage. AFAIK, it is not backported to Havana, but easy to do it by hand.\n\nBy the way, if you distribute all the agents on all compute nodes, all your compute nodes are open to public, meaning that it will be assigned a public IP to make itself as a router gateway.\n\nIt also must be mentioning that when some agent fails, all the resources binded to that agent are down, and you have to re-schedule all of them by hand (command line interface). There\'s a script called neutron-ha-tool can help you deal with this situation. Check it in the following links:\n\nhttps://ask.openstack.org/en/question/10274/best-practice-to-achieve-high-availability-and-scalability-for-neutron/\n\n--\ncheers\nLi Ma\n\n----- Original Message -----\nFrom: \"Zeeshan Ali Shah\" <zashah at kth.se>\nTo: openstack-operators at lists.openstack.org\nSent: ???, 2014? 4 ? 11? ?? 4:08:15\nSubject: [Openstack-operators] Multi Host flag in Havana (neutron), central network node is perfect chocking point..\n\n\n\n\n\n\n\nHi, \nThere used to be a --multi_host flag in nova-network . i.e. to have in-out traffic from compute itself. I think that was more distributed and non-choking model . \n\n\nWe run a dedicated neutron node and public network goes in-out from it. With high traffic app this created a perfect single point of failure . And yes I have tested it with high traffic load. \n\n\nI was thinking to run L3 and l2 agent on all compute nodes . \n\n\nQ1. Does it makes sense ? \n2. Has anyone done it ? We are using Havana release. \n3 and any suggestion for above ? -- \n\n\nRegards \n\n\nZeeshan Ali Shah \nSystem Administrator - PDC HPC \nPhD researcher (IT security) \nKungliga Tekniska Hogskolan \n+46 8 790 9115 \nhttp://www.pdc.kth.se/members/zashah \n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<CABjmtXNBch+Cm9Bq_FRnZ6u0iRWxhaPC2HfNS514idpVGCds3w@mail.gmail.com>',NULL),('<1041900038.83.1380089156479.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-25 06:05:56',0,'2013-09-25 06:05:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #21','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/21/>\n\n------------------------------------------\n[...truncated 5500 lines...]\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 20971\n+ mkdir -p /opt/stack/new/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sudo iptables -S -v\n+ bash\n+ grep \'\\-A\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ sed s/-A/-D/g\n+ awk \'{print \"sudo iptables\",$0}\'\n+ sudo iptables -S -v -t nat\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ bash\n+ sed s/-A/-D/g\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ grep \'\\-A\'\n+ sudo iptables -S -v\n+ grep \'\\-N\'\n+ bash\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ sed s/-N/-X/g\n+ awk \'{print \"sudo iptables\",$0}\'\n+ grep nova\n+ sudo iptables -S -v -t nat\n+ grep \'\\-N\'\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ bash\n+ sed s/-N/-X/g\n++ sudo virsh list --all\n++ grep instance-\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ xargs sudo iscsiadm --mode node --logout\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ sudo iscsiadm --mode node --op delete\niscsiadm: no records found!\niscsiadm: no records found!\n+ true\n+ sudo rm -rf \'/opt/stack/new/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/new/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4,<1.5 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.8.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_compressor%2Fdjango_compressor-1.3.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth<1.1.0 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /opt/stack/new/python-cinderclient (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/new/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /opt/stack/new/python-keystoneclient (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/new/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nRequirement already satisfied (use --upgrade to upgrade): pytz>=2010h in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 10))\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.6.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango-appconf%2Fdjango-appconf-0.6.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): oslo.config>=1.2.0 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing>=1.5.6,<2.0 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2012.2.5 to easy-install.pth file\n\nInstalled /opt/stack/new/horizon\nProcessing dependencies for horizon==2012.2.5\nerror: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-25-060126\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-384353-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-384353.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-384353/21/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1042056859.1.1377411402619.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-25 06:16:42',0,'2013-08-25 06:16:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #13','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/13/>\n\n------------------------------------------\n[...truncated 1173 lines...]\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_api.TestApi.test_limited_images\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 926, in test_limited_images\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.33 secs:\n    26.59    TestScrubber.test_scrubber_app\n    20.91    TestScrubber.test_delayed_delete\n    15.28    TestRootApi.test_version_configurations\n    14.94    TestGlanceControl.test_reload\n    14.61    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 630.809s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.13\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.gwkVSaFTWW\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/13/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-6/13\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1042654059.6514135.1353619946738.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 16:32:26',-18000,'2012-11-22 21:32:26',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n\n> > My read was that the consensus cohered in the follow-up discussion\n> > during the nova IRC meeting[1].\n> \n> Ah, ok - we really should get into the habit of posting summaries of\n> discussion like that to the relevant thread.\n\nYep, you\'re right, I dropped the ball on that.\n\n> Take the DiskIOPollster stuff as an example:\n> \n>   conn = driver.load_compute_driver()\n>   disks = conn.get_disks(instance_name)\n>   for disk in disks:\n>       stats = conn.block_stats(instance_name, disk)\n> \n> The Nova code ceilometer is re-using is the code to connect to\n> libvirt, code to call conn.lookupByName() and domain.XMLDesc() to\n> query libvirt for the XML describing a VM, code to use xpath to\n> extract the disk descriptions from the XML and then code to call\n> domain.blockStats() to get stats about the disk.\n\nYep.\n\n> I really don\'t see much issue with ceilometer just doing those few\n> things directly. The only private implementation assumption you\'d be\n> making about the Nova libvirt driver is that the libvirt VM name is\n> the same as the instance name.\n\nWell I was thinking we\'d also need ComputeDriver.list_instances()\nat least (previously we pulled the instances for the compute node\ndirectly from the nova DB, now we query the nova-api, but neither\nsolution is really optimal).\n\nBut just to confirm I understand the suggestion, by *direct* usage\ndo you mean simply calling the currently installed nova virt code\nbut at a level that is unlikely to change? (say by pushing some\ninternals of the driver implementation into the driver API)\n\n> You\'d be right to be concerned that you\'d need to implement that\n> same code for other hypervisors, but here\'s the thing - the\n> get_disks() and block_stats() methods in the libvirt virt driver\n> aren\'t part of the virt driver abstraction. Other drivers neither\n> implement them, nor do we have common data structures for the values\n> they\'d return. In other words, the abstraction layer with multiple\n> implementations doesn\'t yet exist.\n\nYeah, looking at the inconsistencies in the level of support for the\nComputeDriver.get_diagnostics() function, I was figuring we\'d need to\npotentially live with the API used by ceilo not being universally\nsupported across all hypervisors initially (but it still would be\nless limiting than a direct libvirt dependency).\n\n> You know what\'s weird? The get_disks() and block_stats() methods\n> appear unused in Nova.\n\nYeah, I think pretty much the same logic is re-implemented in\nLibvirtDriver.get_diagnostics.get_io_devices() in the libvirt case\nat least - not good!\n \n> > But in any case, one concern with nova-compute emitting these data\n> > as either notifications or else making direct calls into a ceilo-\n> > provided library was that such a loaded service is likely to\n> > run into timeliness issues.\n> \n> If the data is purely for metering, the timeliness issue isn\'t a\n> concern right?\n\nLess of an issue certainly for pure metering (longer period, less\nsensitive to irregular cadence).\n\n> > There\'s been a fair amount of fuzziness around the distinction\n> > between instrumentation and monitoring, but this falls into the\n> > latter camp for me. Its not so much about the internal dynamics\n> > of nova, as the user-visible behavior (e.g. is my instance running\n> > hot or am I pushing loads of data through the network, as opposed\n> > how long did that API call to update the instance take to service\n> > end-to-end or how many connections are in that pool).\n> \n> Metering vs monitoring/instrumentation, not monitoring vs\n> instrumentation :)\n\nI kinda see the split more as metering/monitoring vs instrumentation.\n\nWell, actually more like metering/user-oriented-monitoring vs \ncloud-operator-oriented-monitoring/instrumentation.\n\nCurrently ceilo is aiming to at least address both metering and \nuser-oriented-monitoring, and possibly more in time.\n\n> If we were just designing a solution for metering, would we go for\n> the notifications option?\n\nProbably, but the scope of ceilo has widened a bit from pure\nmetering.\n\nCheers,\nEoghan\n\n\n','<1353612817.14377.41.camel@sorcha>',NULL),('<1042680138.15.1381817540563.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-15 06:12:20',0,'2013-10-15 06:12:20',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #33','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/33/>\n\n\n\n','<679002578.8.1381731169792.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1043374364.119805.1352219000286.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 08:23:20',-28800,'2012-11-06 16:23:20',NULL,'[openstack-dev] Is snapshot of LXC broken?','\n Hi Jay,\n\n The patch was merged to the git repository on Oct. 23rd.\n\nhttps://review.openstack.org/#/c/13848/\n\n Thanks,\n David \n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n----- Original Message -----\n> Any update on this? David, did you eventually submit a bug or figure\n> out\n> the source of the problem?\n> \n> Best,\n> -jay\n> \n> p.s. Sorry for top-posting...\n> \n> On 09/28/2012 01:27 PM, David Kang wrote:\n> >\n> >  Hi,\n> >\n> >  I\'m testing snapshot of LXC instance using stable/folsom branch.\n> > I got the error messages which I put at the end of this email.\n> > I think it is a bug.\n> >\n> >  Thanks,\n> >  David\n> >\n> > Error message ===============\n> >\n> > 2012-09-28 13:12:06 ERROR nova.openstack.common.rpc.amqp [-]\n> > Exception during message handling\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp Traceback\n> > (most recent call last):\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in\n> > _process_data\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp rval =\n> > self.proxy.dispatch(ctxt, version, method, **args)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145,\n> > in dispatch\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp return\n> > getattr(proxyobj, method)(ctxt, **kwargs)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp temp_level,\n> > payload)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > self.gen.next()\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp return\n> > f(*args, **kw)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/compute/manager.py\", line 181, in\n> > decorated_function\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp pass\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > self.gen.next()\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/compute/manager.py\", line 167, in\n> > decorated_function\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp return\n> > function(self, context, *args, **kwargs)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/compute/manager.py\", line 202, in\n> > decorated_function\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > kwargs[\'instance\'][\'uuid\'], e, sys.exc_info())\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > self.gen.next()\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/compute/manager.py\", line 196, in\n> > decorated_function\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp return\n> > function(self, context, *args, **kwargs)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/compute/manager.py\", line 1163, in\n> > snapshot_instance\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > self.driver.snapshot(context, instance, image_id)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp temp_level,\n> > payload)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > self.gen.next()\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp return\n> > f(*args, **kw)\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp File\n> > \"/usr/local/nova/nova/virt/libvirt/driver.py\", line 822, in snapshot\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp disk_path =\n> > source.get(\'file\')\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> > AttributeError: \'NoneType\' object has no attribute \'get\'\n> > 2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n> >\n> >\n> >\n> > ----------------------\n> > Dr. Dong-In \"David\" Kang\n> > Computer Scientist\n> > USC/ISI\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<50993709.3010001@gmail.com>',NULL),('<1043778827.8451120.1390903454884.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 05:04:14',-18000,'2014-01-28 10:04:14',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival\n	#1	-	Roles','I\'ve spent some time thinking about this, and I have a clarification.\n\nI don\'t like the use of the word \'deployment\', because it\'s not exact\nenough for me.  Future plans for the tuskar-ui include management of the\nundercloud as well, and at that point, \'deployment role\' becomes vague, as\nit could also logically apply to the undercloud.\n\nFor that reason, I think we should call it an \'overcloud deployment role\',\nor \'overcloud role\' for short.\n\nThat being said, I think that the UI could get away with just displaying\n\'Role\', as presumably the user would be in a page with enough context to\nmake it clear that he\'s in the overcloud section.\n\n\nMainn\n\n----- Original Message -----\n> I\'d argue that we should call it \'overcloud role\' - at least from the\n> modeling\n> point of view - since the tuskar-api calls a deployment an overcloud.\n> \n> But I like the general direction of the term-renaming!\n> \n> Mainn\n> \n> ----- Original Message -----\n> > Based on this thread which didn\'t seem to get clear outcome, I have one\n> > last suggestion:\n> > \n> > * Deployment Role\n> > \n> > It looks that it might satisfy participants of this discussion. When I\n> > internally talked to people it got the best reactions from already\n> > suggested terms.\n> > \n> > Depending on your reactions for this suggestion, if we don\'t get to\n> > agreement of majority by the end of the week, I would call for voting\n> > starting next week.\n> > \n> > Thanks\n> > -- Jarda\n> > \n> > On 2014/21/01 15:19, Jaromir Coufal wrote:\n> > > Hi folks,\n> > >\n> > > when I was getting feedback on wireframes and we talked about Roles,\n> > > there were various objections and not much suggestions. I would love to\n> > > call for action and think a bit about the term for concept currently\n> > > known as Role (= Resource Category).\n> > >\n> > > Definition:\n> > > Role is a representation of a group of nodes, with specific behavior.\n> > > Each role contains (or will contain):\n> > > * one or more Node Profiles (which specify HW which is going in)\n> > > * association with image (which will be provisioned on new coming nodes)\n> > > * specific service settings\n> > >\n> > > So far suggested terms:\n> > > * Role *\n> > >    - short name - plus points\n> > >    - quite overloaded term (user role, etc)\n> > >\n> > > * Resource Category *\n> > >    - pretty long (devs already shorten it - confusing)\n> > >    - Heat specific term\n> > >\n> > > * Resource Class *\n> > >    - older term\n> > >\n> > > Are there any other suggestions (ideally something short and accurate)?\n> > > Or do you prefer any of already suggested terms?\n> > >\n> > > Any ideas are welcome - we are not very good in finding the best match\n> > > for this particular term.\n> > >\n> > > Thanks\n> > > -- Jarda\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<48371493.7860857.1390840933031.JavaMail.root@redhat.com>',NULL),('<1044581392.28926824.1385580858877.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 11:34:18',-28800,'2013-11-27 19:34:18',NULL,'[openstack-dev] [nova][vmware] VMwareAPI sub-team status update\n 2011-11-27','Greetings Stackers!\n\nWe have Icehouse-1 on December 5th! Here\'s the reviews that the VMwareAPI team has in flight in order of fitness for review by core reviewers. It\'s also holiday season now so please keep in mind folks may be in and out during this period. Let\'s see if we can\'t get some of these top most patches merged for Icehouse-1 thanks to everyone who is doing reviews and a gentle reminder to some to step up your review output.\n\n--------------------------------------------------------------------------------\nOrdered by fitness for review:\n\n== needs one more +2/approval ==\n* https://review.openstack.org/55505\n	title: \'VMware: Handle cases when there are no hosts in cluster\'\n	votes: +2:2, +1:3, -1:0, -2:0. +20 days in progress, revision: 1 is 20 days old \n* https://review.openstack.org/56746\n	title: \'VMware: Detach volume should not delete vmdk\'\n	votes: +2:1, +1:2, -1:0, -2:0. +11 days in progress, revision: 1 is 9 days old \n* https://review.openstack.org/47743\n	title: \'VMWare: bug fix for Vim exception handling\'\n	votes: +2:1, +1:3, -1:0, -2:0. +66 days in progress, revision: 11 is 4 days old \n* https://review.openstack.org/53109\n	title: \'VMware: enable driver to work with postgres database\'\n	votes: +2:2, +1:9, -1:0, -2:0. +36 days in progress, revision: 2 is 36 days old \n* https://review.openstack.org/55934\n	title: \'VMware: Always upload a snapshot as a preallocated disk\'\n	votes: +2:1, +1:3, -1:0, -2:0. +16 days in progress, revision: 4 is 8 days old \n\n== ready for core ==\n* https://review.openstack.org/53990\n	title: \'VMware ESX: Boot from volume must not relocate vol\'\n	votes: +2:0, +1:6, -1:0, -2:0. +32 days in progress, revision: 3 is 32 days old \n* https://review.openstack.org/54361\n	title: \'VMware: fix datastore selection when token is returned\'\n	votes: +2:0, +1:7, -1:0, -2:0. +29 days in progress, revision: 5 is 28 days old \n* https://review.openstack.org/49692\n	title: \'VMware: iscsi target discovery fails while attaching volumes\'\n	votes: +2:0, +1:6, -1:0, -2:0. +54 days in progress, revision: 9 is 15 days old \n\n== needs review ==\n* https://review.openstack.org/58705\n	title: \'VMware: bug fix for incomplete statistics/datastore reports\'\n	votes: +2:0, +1:1, -1:0, -2:0. +0 days in progress, revision: 2 is 0 days old \n* https://review.openstack.org/58598\n	title: \'VMware: deal with concurrent downloads\'\n	votes: +2:0, +1:1, -1:0, -2:0. +1 days in progress, revision: 2 is 0 days old \n* https://review.openstack.org/58703\n	title: \'VMware: fix snapshot failure when host in maintenance mode\'\n	votes: +2:0, +1:1, -1:0, -2:0. +0 days in progress, revision: 3 is 0 days old \n* https://review.openstack.org/52630\n	title: \'VMware: fix bug when more than one datacenter exists\'\n	votes: +2:0, +1:2, -1:0, -2:0. +40 days in progress, revision: 14 is 3 days old \n* https://review.openstack.org/52630\n	title: \'VMware: fix bug when more than one datacenter exists\'\n	votes: +2:0, +1:2, -1:0, -2:0. +40 days in progress, revision: 14 is 3 days old \n* https://review.openstack.org/52557\n	title: \'VMware Driver update correct disk usage stat\'\n	votes: +2:0, +1:1, -1:0, -2:0. +41 days in progress, revision: 2 is 1 days old \n* https://review.openstack.org/55070\n	title: \'VMware: fix rescue with disks are not hot-addable\'\n	votes: +2:0, +1:3, -1:0, -2:0. +24 days in progress, revision: 2 is 3 days old \n* https://review.openstack.org/58142\n	title: \'VMware: validate data returned by task prior to access\'\n	votes: +2:0, +1:2, -1:0, -2:0. +3 days in progress, revision: 2 is 3 days old \n* https://review.openstack.org/57519\n	title: \'VMware: use .get() to access \'summary.accessible\'\'\n	votes: +2:0, +1:4, -1:0, -2:0. +7 days in progress, revision: 1 is 2 days old \n* https://review.openstack.org/57376\n	title: \'VMware: delete vm snapshot after nova snapshot\'\n	votes: +2:0, +1:4, -1:0, -2:0. +7 days in progress, revision: 4 is 2 days old \n* https://review.openstack.org/55038\n	title: \'VMware: bug fix for VM rescue when config drive is config...\'\n	votes: +2:0, +1:1, -1:0, -2:0. +25 days in progress, revision: 3 is 3 days old \n* https://review.openstack.org/53648\n	title: \'VMware: fix image snapshot with attached volume\'\n	votes: +2:0, +1:4, -1:0, -2:0. +34 days in progress, revision: 1 is 34 days old \n* https://review.openstack.org/54808\n	title: \'VMware: fix bug for exceptions thrown in _wait_for_task\'\n	votes: +2:0, +1:4, -1:0, -2:0. +27 days in progress, revision: 3 is 12 days old \n* https://review.openstack.org/55509\n	title: \'VMware: fix VM resize bug\'\n	votes: +2:0, +1:4, -1:0, -2:0. +20 days in progress, revision: 1 is 20 days old \n* https://review.openstack.org/43270\n	title: \'vmware driver selection of vm_folder_ref.\'\n	votes: +2:0, +1:1, -1:0, -2:0. +97 days in progress, revision: 1 is 97 days old \n* https://review.openstack.org/43270\n	title: \'vmware driver selection of vm_folder_ref.\'\n	votes: +2:0, +1:1, -1:0, -2:0. +97 days in progress, revision: 1 is 97 days old \n\n== needs revision ==\n* https://review.openstack.org/53976\n	title: \'VMware: Fix VSAN datastores cannot be used\'\n	votes: +2:0, +1:0, -1:1, -2:0. +33 days in progress, revision: 5 is 28 days old \n* https://review.openstack.org/48544\n	title: \'VMWare - Fix a image upload is interrupted it\'s not clean...\'\n	votes: +2:0, +1:0, -1:2, -2:0. +62 days in progress, revision: 20 is 9 days old \n* https://review.openstack.org/56278\n	title: \'VMware: bug in rebooting powered off instance\'\n	votes: +2:0, +1:1, -1:2, -2:0. +14 days in progress, revision: 1 is 14 days old \n\n--------------------------------------------------------------------------------\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n* If anything is missing, email me so I can examine it.\n* We hang out in #openstack-vmware if you need to chat & it\'s not worth spamming the whole list\n* Code for these reports: https://github.com/hartsock/nova-reports\n\nHappy stacking!\n\n# Shawn Hartsock\n\n\n','<1179387371.28918550.1385580471024.JavaMail.root@vmware.com>',NULL),('<1045065208.23.1378189126029.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-03 06:18:45',0,'2013-09-03 06:18:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #17','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-folsom/17/>\n\n------------------------------------------\n[...truncated 4430 lines...]\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-simple-tenant-usage\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-cloudpipe\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-security-groups\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-server-diagnostics\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-flavor-access\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-create-server-ext\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-multiple-create\nnova.api.openstack.extensions: AUDIT: Loaded extension: OS-FLV-DISABLED\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-instance_usage_audit_log\nnova.api.openstack.extensions: AUDIT: Loaded extension: OS-SCH-HNT\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-aggregates\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-networks\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-quota-sets\nnova.api.openstack.extensions: AUDIT: Loaded extension: OS-DCF\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-used-limits\nnova.api.openstack.extensions: AUDIT: Loaded extension: OS-FLV-EXT-DATA\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:37499\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:37499/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (29350) wsgi starting up on http://127.0.0.1:37499/\n\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41574)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:02] \"GET /v2 HTTP/1.1\" 204 216 0.000731\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//images/detail\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41575)\n\nroutes.middleware: DEBUG: Matched GET /openstack/images/detail\nroutes.middleware: DEBUG: Route path: \'/{project_id}/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xc4fe8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xc4fe8d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/images/detail\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/images/detail returned with HTTP 200\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:03] \"GET /v2/openstack//images/detail HTTP/1.1\" 200 4992 0.820500\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//flavors/detail\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41576)\n\nroutes.middleware: DEBUG: Matched GET /openstack/flavors/detail\nroutes.middleware: DEBUG: Route path: \'/{project_id}/flavors/detail\', defaults: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xbf40dd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xbf40dd0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/flavors/detail\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/flavors/detail returned with HTTP 200\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:03] \"GET /v2/openstack//flavors/detail HTTP/1.1\" 200 2013 0.013708\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//servers/detail\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41577)\n\nroutes.middleware: DEBUG: Matched GET /openstack/servers/detail\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/detail\', defaults: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/servers/detail\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/detail returned with HTTP 200\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:03] \"GET /v2/openstack//servers/detail HTTP/1.1\" 200 187 0.043466\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack//servers\nnova.tests.integrated.api.client: INFO: Body: {\"server\": {\"flavorRef\": \"http://fake.server/1\", \"name\": \"serverIX2X2AUU\", \"imageRef\": \"http://fake.server/70a599e0-31e7-49b7-b260-868f441e862b\"}}\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41578)\n\nroutes.middleware: DEBUG: Matched POST /openstack/servers\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:37499/v2/openstack/servers\nnova.compute.manager: AUDIT: Starting instance...\nnova.compute.resource_tracker: AUDIT: Attempting claim: memory 512 MB, disk 0 GB, VCPUs 1\nnova.compute.resource_tracker: AUDIT: Total memory: 8192 MB, used: 512 MB, free: 7680 MB\nnova.compute.resource_tracker: AUDIT: Memory limit not specified, defaulting to unlimited\nnova.compute.resource_tracker: AUDIT: Total disk: 1028 GB, used: 0 GB, free: 1028 GB\nnova.compute.resource_tracker: AUDIT: Disk limit not specified, defaulting to unlimited\nnova.compute.resource_tracker: AUDIT: Total VCPUs: 1, used: 0\nnova.compute.resource_tracker: AUDIT: VCPU limit not specified, defaulting to unlimited\nnova.compute.resource_tracker: INFO: Finishing claim: [Claim f0003e69-b882-4e35-93c0-69bd07dc5d9a: 512 MB memory, 0 GB disk, 1 VCPUS]\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers returned with HTTP 202\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:04] \"POST /v2/openstack//servers HTTP/1.1\" 202 659 0.542065\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7168\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 0\nnova.compute.resource_tracker: INFO: Compute_service record updated for 27956ac73df94b1fb456257bb44d901e \nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41579)\n\nnova.compute.manager: INFO: Updating bandwidth usage cache\nroutes.middleware: DEBUG: Matched GET /openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/:(id)\', defaults: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\', \'id\': u\'f0003e69-b882-4e35-93c0-69bd07dc5d9a\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a returned with HTTP 200\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:04] \"GET /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a HTTP/1.1\" 200 1424 0.062518\n\nnova.tests.integrated.api.client: INFO: Doing DELETE on /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41580)\n\nroutes.middleware: DEBUG: Matched DELETE /openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/:(id)\', defaults: {\'action\': u\'delete\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'delete\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\', \'id\': u\'f0003e69-b882-4e35-93c0-69bd07dc5d9a\'}\nnova.api.openstack.wsgi: INFO: DELETE http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a returned with HTTP 204\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:04] \"DELETE /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a HTTP/1.1\" 204 179 0.288814\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41581)\n\nroutes.middleware: DEBUG: Matched GET /openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/:(id)\', defaults: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\', \'id\': u\'f0003e69-b882-4e35-93c0-69bd07dc5d9a\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a returned with HTTP 200\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:04] \"GET /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a HTTP/1.1\" 200 1415 0.069503\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a/action\nnova.tests.integrated.api.client: INFO: Body: {\"restore\": {}}\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41582)\n\nroutes.middleware: DEBUG: Matched POST /openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a/action\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/:(id)/action\', defaults: {\'action\': u\'action\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'action\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\', \'id\': u\'f0003e69-b882-4e35-93c0-69bd07dc5d9a\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a/action\nnova.compute.manager: INFO: Reclaiming deleted instance\nnova.compute.manager: AUDIT: Terminating instance\nnova.compute.manager: INFO: Updating host status\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a/action returned with HTTP 202\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:05] \"POST /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a/action HTTP/1.1\" 202 121 0.402131\n\nnova.tests.integrated.api.client: INFO: Doing GET on /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.osapi_compute.wsgi.server: INFO: (29350) accepted (\'127.0.0.1\', 41583)\n\nroutes.middleware: DEBUG: Matched GET /openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nroutes.middleware: DEBUG: Route path: \'/{project_id}/servers/:(id)\', defaults: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'show\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa2f9b50>, \'project_id\': u\'openstack\', \'id\': u\'f0003e69-b882-4e35-93c0-69bd07dc5d9a\'}\nnova.api.openstack.wsgi: INFO: GET http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a\nnova.api.openstack.wsgi: INFO: HTTP exception thrown: The resource could not be found.\nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37499/v2/openstack/servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a returned with HTTP 404\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Sep/2013 06:15:05] \"GET /v2/openstack//servers/f0003e69-b882-4e35-93c0-69bd07dc5d9a HTTP/1.1\" 404 272 0.043317\n\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 33.15 secs:\n    10.72    ComputeTestCase.test_state_revert\n    7.05    CloudTestCase.test_instance_initiated_shutdown_behavior\n    6.00    ServersTest.test_create_multiple_servers\n    5.07    StorwizeSVCDriverTestCase.test_storwize_svc_flashcopy\n    4.31    ServersTest.test_create_and_rebuild_server\n----------------------------------------------------------------------\nRan 3729 tests in 831.289s\n\nFAILED (SKIP=7, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.5\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-quantumclient==2.2.3\npytz==2013b\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nova/tests/nose_results.html\n+ \'[\' -f ./nova/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nova/tests/nose_results.html\n+ passcount=459\n+ \'[\' 459 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.xDidLuswuY\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/17\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-nova-python26-stable-folsom/17/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/centos6-4/17\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1045138282.211.1368167535603.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-10 06:32:15',0,'2013-05-10 06:32:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #10','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/10/>\n\n------------------------------------------\n[...truncated 12591 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for 7a89b3c587f8455780004bfe714e0539 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:45187\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:45187/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (4266) wsgi starting up on http://127.0.0.1:45187/\n\nnova.osapi_compute.wsgi.server: INFO: (4266) accepted (\'127.0.0.1\', 34347)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [10/May/2013 06:27:07] \"GET /v2 HTTP/1.1\" 204 216 0.001013\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-304906a8-6705-4eeb-b6f0-f69507d1c8bb</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (4266) accepted (\'127.0.0.1\', 34348)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8eb8fd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8eb8fd0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:45187/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-10 06:27:07 4266 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:45187/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [10/May/2013 06:27:07] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.247754\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 39a2b0de37744e33aa87eaf63a6c8ed2 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:34003\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:34003/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (4266) wsgi starting up on http://127.0.0.1:34003/\n\nnova.osapi_compute.wsgi.server: INFO: (4266) accepted (\'127.0.0.1\', 44511)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [10/May/2013 06:27:07] \"GET /v2 HTTP/1.1\" 204 216 0.001038\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-0f24d8a4-0093-462e-aa67-2411a941aef1</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (4266) accepted (\'127.0.0.1\', 44512)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9515850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9515850>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:34003/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     name)\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-10 06:27:08 4266 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:34003/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [10/May/2013 06:27:08] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.298628\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.XIbQoQdxbw\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/10\n[SCP] Copying console log.\n\n\n','<913380384.180.1368080650499.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1046280644.1337488.1392205239157.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-12 06:40:39',-18000,'2014-02-12 11:40:39',NULL,'[openstack-dev] [neutron] [stable/havana] cherry backport,\n multiple external networks, passing tests','Thank you Alan, \n\n   I wasn\'t aware of a stable freeze being active at this moment.\n\n   Then we must target it for 2013.2.3 .\n\n   Cheers,\nMiguel ?ngel\n\n----- Original Message -----\n> From: \"Alan Pevec\" <apevec at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: \"openstack-stable-maint\" <openstack-stable-maint at lists.openstack.org>\n> Sent: Wednesday, February 12, 2014 12:05:29 PM\n> Subject: Re: [openstack-dev] [neutron] [stable/havana] cherry backport, multiple external networks, passing tests\n> \n> 2014-02-12 10:48 GMT+01:00 Miguel Angel Ajo Pelayo <mangelajo at redhat.com>:\n> > Could any core developer check/approve this if it does look good?\n> >     https://review.openstack.org/#/c/68601/\n> >\n> > I\'d like to get it in for the new stable/havana release\n> > if it\'s possible.\n> \n> I\'m afraid it\'s too late for 2013.2.2 (to be released tomorrow after week\n> delay)\n> It would be the same answer as\n> http://lists.openstack.org/pipermail/openstack-stable-maint/2014-February/002124.html\n> - both linked bugs are Medium only and known for long time, so\n> targeting 2013.2.3 is more reasonable.\n> \n> \n> Cheers,\n> Alan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAGi==UWCCwE3FH2+yNXKFRFaKoFgiMKbn1n8rJhpsnKzixzc6Q@mail.gmail.com>',NULL),('<1046280644.1337488.1392205239157.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-02-12 06:40:39',-18000,'2014-02-12 11:40:39',NULL,'[Openstack-stable-maint] [openstack-dev] [neutron]\n [stable/havana] cherry backport, multiple external networks, passing tests','Thank you Alan, \n\n   I wasn\'t aware of a stable freeze being active at this moment.\n\n   Then we must target it for 2013.2.3 .\n\n   Cheers,\nMiguel ?ngel\n\n----- Original Message -----\n> From: \"Alan Pevec\" <apevec at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: \"openstack-stable-maint\" <openstack-stable-maint at lists.openstack.org>\n> Sent: Wednesday, February 12, 2014 12:05:29 PM\n> Subject: Re: [openstack-dev] [neutron] [stable/havana] cherry backport, multiple external networks, passing tests\n> \n> 2014-02-12 10:48 GMT+01:00 Miguel Angel Ajo Pelayo <mangelajo at redhat.com>:\n> > Could any core developer check/approve this if it does look good?\n> >     https://review.openstack.org/#/c/68601/\n> >\n> > I\'d like to get it in for the new stable/havana release\n> > if it\'s possible.\n> \n> I\'m afraid it\'s too late for 2013.2.2 (to be released tomorrow after week\n> delay)\n> It would be the same answer as\n> http://lists.openstack.org/pipermail/openstack-stable-maint/2014-February/002124.html\n> - both linked bugs are Medium only and known for long time, so\n> targeting 2013.2.3 is more reasonable.\n> \n> \n> Cheers,\n> Alan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAGi==UWCCwE3FH2+yNXKFRFaKoFgiMKbn1n8rJhpsnKzixzc6Q@mail.gmail.com>',NULL),('<104631453.27.1378275460014.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:17:40',0,'2013-09-04 06:17:40',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-docs-stable-folsom #15','See <https://jenkins02.openstack.org/job/periodic-glance-docs-stable-folsom/15/>\n\n\n\n',NULL,NULL),('<1046560230.27892265.1402999277848.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-17 06:01:17',-14400,'2014-06-17 10:01:17',NULL,'[openstack-dev] [taskflow] Recommendations for the granularity of\n tasks and their \"stickiness\" to workers','\nFolks,\n\nA question for the taskflow ninjas.\n\nAny thoughts on best practice WRT $subject?\n\nSpecifically I have in mind this ceilometer review[1] which adopts\nthe approach of using very fine-grained tasks (at the level of an\nindividual alarm evaluation) combined with short-term assignments\nto individual workers.\n\nBut I\'m also thinking of future potential usage of taskflow within\nceilometer, to support partitioning of work over a scaled-out array\nof central agents.\n\nDoes taskflow also naturally support a model whereby more chunky\ntasks (possibly including ongoing periodic work) are assigned to\nworkers in a stickier fashion, such that re-balancing of workload\ncan easily be triggered when a change is detected in the pool of\navailable workers?\n\nCheers,\nEoghan\n\n[1] https://review.openstack.org/91763\n\n\n','<1060234822.27887924.1402998838730.JavaMail.zimbra@redhat.com>',NULL),('<1046740922.27584588.1407591177668.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 09:32:57',-14400,'2014-08-09 13:32:57',NULL,'[openstack-dev] [qa][ceilometer] swapping the roles of mongodb\n and sqlalchemy for ceilometer in Tempest','\n\n> Eoghan,\n> \n> Nice work on this. I think that first of all this job should be run on every\n> patch for some period of time (not only in experimental pipe)\n> \n> By the way, If you would like we can help from Rally side.\n> We are running benchmarks on every patch in it\'s gates. Ceilometer is fully\n> turned on in these jobs, so we can be first adopters and switch to mongodb.\n\nHi Boris,\n\nExcellent, that additional coverage would certainly be helpful.\n\nThough in terms of the performance characteristics reported by\nRally, I\'m guessing we wouldn\'t see much change, given the faster\nmetering store access would all be happening asynchronously to\nthe paths measured by Rally, amiright?\n\nCheers,\nEoghan\n\n> This will ensure that everything works stable even under load, and i hope\n> convince people to switch integrate gate to mongo.\n> \n> \n> Best regards,\n> Boris Pavlovic\n> \n> \n> On Sat, Aug 9, 2014 at 3:19 PM, Eoghan Glynn < eglynn at redhat.com > wrote:\n> \n> \n> \n> Hi Folks,\n> \n> Dina Belova has recently landed some infra patches[1,2] to create\n> an experimental mongodb-based Tempest job. This effectively just\n> overrides the ceilometer storage backend config so that mongodb\n> is used instead of sql-alchemy. The new job has been running\n> happily for a few days so I\'d like now to consider the path\n> forwards with this.\n> \n> One of our Juno goals under the TC gap analysis was to more fully\n> gate against mongodb, given that this is the storage backend\n> recommended/supported by many distros. The sql-alchemy backend,\n> on the other hand, is more suited for proofs of concept or small\n> deployments. However up to now we\'ve been hampered from reflecting\n> that reality in the gate, due to the gate being stuck on Precise\n> for a long time, as befits LTS, and the version of mongodb needed\n> by ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu\n> release (in fact it was limited to 2.0.4).\n> \n> So the orientation towards gating on sql-alchemy was mostly\n> driven by legacy issues in the gate\'s usage of Precise, as\n> opposed to this being considered the most logical basket in\n> which to put all our testing eggs.\n> \n> However, we\'re now finally in the brave new world of Trusty :)\n> So I would like to make the long-delayed change over soon.\n> \n> This would involve transposing the roles of sql-alchemy and\n> mongodb in the gate - the mongodb variant becomes the \"blessed\"\n> job run by default, whereas the sql-alchemy based job to\n> relegated to the second tier.\n> \n> So my questions are:\n> \n> (a) would the QA side of the house be agreeable to this switch?\n> \n> and:\n> \n> (b) how long would the mongodb job need to be stable in this\n> experimental mode before we pull the trigger on swicthing?\n> \n> If the answer to (a) is yes, we can get infra patches proposed\n> early next week to make the swap.\n> \n> Cheers,\n> Eoghan\n> \n> [1]\n> https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z\n> [2]\n> https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAD85om3YFBOVsne2GfM-BDyaXHSSA_P-hzu+SkkSNMYk6xGMDA@mail.gmail.com>',NULL),('<1047334922.65.1383544972141.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:02:52',0,'2013-11-04 06:02:52',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-horizon-python26-stable-grizzly #50','See <https://jenkins01.openstack.org/job/periodic-horizon-python26-stable-grizzly/50/>\n\n\n\n','<189638409.35.1383372172660.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1047784310.68.1360135886109.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-06 07:31:25',0,'2013-02-06 07:31:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #128','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/128/>\n\n------------------------------------------\n[...truncated 12211 lines...]\n    s,%IMAGE_PORT%,9292,g;\n    s,%IMAGE_API_VERSION%,1,g;\n    s,%IMAGE_CATALOG_TYPE%,image,g;\n    s,%COMPUTE_ADMIN_USERNAME%,admin,g;\n    s,%COMPUTE_ADMIN_PASSWORD%,secret,g;\n    s,%COMPUTE_ADMIN_TENANT_NAME%,admin,g;\n    s,%IDENTITY_ADMIN_USERNAME%,admin,g;\n    s,%IDENTITY_ADMIN_PASSWORD%,secret,g;\n    s,%IDENTITY_ADMIN_TENANT_NAME%,admin,g;\n    s,%NETWORK_CATALOG_TYPE%,network,g;\n    s,%NETWORK_API_VERSION%,2.0,g;\n    s,%VOLUME_CATALOG_TYPE%,volume,g;\n    s,%VOLUME_BUILD_INTERVAL%,3,g;\n    s,%VOLUME_BUILD_TIMEOUT%,300,g;\n\' -i /opt/stack/new/tempest/etc/tempest.conf\n+ echo \'Created tempest configuration file:\'\nCreated tempest configuration file:\n+ cat /opt/stack/new/tempest/etc/tempest.conf\n[identity]\n# This section contains configuration options that a variety of Tempest\n# test clients use when authenticating with different user/tenant\n# combinations\n\n# Set to True if your test environment\'s Keystone authentication service should\n# be accessed over HTTPS\nuse_ssl = False\n# This is the main host address of the authentication service API\nhost = 127.0.0.1\n# Port that the authentication service API is running on\nport = 5000\n# Version of the authentication service API (a string)\napi_version = v2.0\n# Path to the authentication service tokens resource (do not modify unless you\n# have a custom authentication API and are not using Keystone)\npath = tokens\n# Should typically be left as keystone unless you have a non-Keystone\n# authentication API service\nstrategy = keystone\n\n[compute]\n# This section contains configuration options used when executing tests\n# against the OpenStack Compute API.\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_isolation = True\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_reuse = True\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n# This should be the username of an alternate user WITHOUT\n# administrative privileges\nalt_username = alt_demo\n# The above non-administrative user\'s password\nalt_password = secret\n# The above non-administrative user\'s tenant name\nalt_tenant_name = alt_demo\n\n# Reference data for tests. The ref and ref_alt should be\n# distinct images/flavors.\nimage_ref = 7f83f051-4e7d-408a-9480-9f53658c18ad\nimage_ref_alt = 7f83f051-4e7d-408a-9480-9f53658c18ad\nflavor_ref = 1\nflavor_ref_alt = 2\n\n# Number of seconds to wait while looping to check the status of an\n# instance that is building.\nbuild_interval = 3\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... ok\nCREATE, GET, DELETE Volume ... ERROR\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nERROR\nBuild timed out (after 90 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/128\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/128/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/128/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/128/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1047953906.157.1356307692811.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-24 00:08:12',0,'2012-12-24 00:08:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #84','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/84/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 10.01 secs:\n    2.69    Kc11TestCase.test_admin_requires_adminness\n    2.50    KcEssex3TestCase.test_admin_requires_adminness\n    2.22    KcMasterTestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.09    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 55.606s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.fY8saaB1HL\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/84\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/84/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<225327703.141.1356221436751.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1047990955.21411135.1408069218175.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 22:20:18',-14400,'2014-08-15 02:20:18',NULL,'[openstack-dev] [Sahara] Swift authentication and backwards\n	compatibility','hello Sahara folks,\n\nI am working to get the revamped spec[1] finalized and I\'d like to know the group\'s thoughts on the idea of backward compatibility. It is possible to implement the new authentication method and remain backward compatible, but we will need to keep the username and password inputs in the Swift data forms.\n\nHaving the backward compatibility would also give Sahara a way to react in situations where the proxy domain is not available or the administrator doesn\'t wish to use it. I\'m not sure this is the behavior we want, but I don\'t know if it is proper for Sahara to exit if no proxy domain can be found.\n\nIf we choose not to remain backward compatible then we are requiring Sahara operators to create the new proxy domain needed, and they must update all virtual machine images.\n\nThoughts?\n\nregards,\nmike\n\n[1]: https://review.openstack.org/#/c/113591/\n\n\n','<472675222.21410357.1408068722424.JavaMail.zimbra@redhat.com>',NULL),('<1048318526.306.1358985714318.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-24 00:01:54',0,'2013-01-24 00:01:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-folsom #115','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/115/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise6 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/>\nCheckout:periodic-swift-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/> - hudson.remoting.Channel at 577a2815:precise6\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson7289184625435308839.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.2Le3MCRALj\n+ TMPDIR=/tmp/tmp.2Le3MCRALj\n+ trap \'rm -rf /tmp/tmp.2Le3MCRALj\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/115/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python27-stable-folsom-115\', \'SSH_CLIENT\': \'198.101.231.203 50520 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1357687285.854054-1874355803\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.2Le3MCRALj\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-24_00-01-14\', \'BUILD_NUMBER\': \'115\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'367aae1b-6af4-4949-a34b-6915cf2006e6\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50520 108.166.59.174 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.2Le3MCRALj\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-folsom/115\n[SCP] Copying console log.\n\n\n','<225730616.286.1358899346167.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1048345854.988197.1386249897679.JavaMail.zimbra@csc.fi>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 15:24:57',7200,'2013-12-05 13:24:57',NULL,'[Openstack] Openstack--instance-boot-from-ceph-volume','Thanks for explanation darren , you were correct , looks like qemu does not support RBD \n\nSupported formats: raw cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 qed vhdx parallels nbd blkdebug host_cdrom host_floppy host_device file gluster gluster gluster gluster\n[root at rdo qemu(keystone_admin)]#\n\n\n\nI will try the steps provided by you in last email.\n\n\nIf you\'re using Centos, you\'ll need a qemu-kvm that is built with rbd support.  You can grab this src rpm for qemu-kvm-rhev from Redhat and build it yourself:\n\nhttp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu-kvm-rhev-0.12.1.2-2.415.el6.src.rpm\n\nUsing:\n\nrpmbuild  -ba  --with rhev_features --without guest_agent qemu-kvm.spec\n\n\n\nMany Thanks\nKaran Singh\n\n\n----- Original Message -----\nFrom: \"Darren Birkett\" <darren.birkett at gmail.com>\nTo: \"Karan Singh\" <ksingh at csc.fi>\nCc: \"lad raghavendra\" <lad.raghavendra at gmail.com>, \"Tim Bell\" <Tim.Bell at cern.ch>, \"Openstack Milis\" <openstack at lists.openstack.org>\nSent: Thursday, 5 December, 2013 3:11:11 PM\nSubject: Re: [Openstack] Openstack--instance-boot-from-ceph-volume\n\nOn 5 December 2013 12:55, Karan Singh <ksingh at csc.fi> wrote:\n\n> I am using qemu-kvm provided by ceph repository that have RBD support . Using this i am able to create RBD volumes and its working good.\n\nJust creating cinder volumes doesn\'t actually use qemu-kvm, which is\nwhy that\'s working ok\n\n> could not open disk image rbd:ceph...\n\nIt\'s difficult to say exactly where the issue is.  Which qemu-kvm from\nceph.com are you using?  What\'s the output of:\n\nqemu-img -h\n\nThanks\nDarren\n\n\n','<CAHX4EnOmDEv8ERLgqNw9YBwomb2smayQQHHcPWbZPtNLYWpx9w@mail.gmail.com>',NULL),('<1048511905.15.1385534406578.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-27 06:40:05',0,'2013-11-27 06:40:05',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #5','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/5/>\n\n------------------------------------------\n[...truncated 20905 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   193.988\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]            94.012\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   71.124\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      44.110\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                     42.036\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         37.241\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]         35.051\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                           33.624\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]        33.340\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   33.283\n\n----------------------------------------------------------------------\nRan 1340 tests in 1342.809s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-751951-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-751951.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-751951/5/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<615884949.10.1385361042063.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1048519085.44235195.1409862318720.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 16:25:18',-14400,'2014-09-04 20:25:18',NULL,'[openstack-dev] [Nova] Feature Freeze Exception process for Juno','(see comments inline)\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Thursday, September 4, 2014 2:34:28 PM\n> Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno\n> \n> On 09/03/2014 11:57 AM, Solly Ross wrote:\n> >> I will follow up with a more detailed email about what I believe we are\n> >> missing, once the FF settles and I have applied some soothing creme to\n> >> my burnout wounds, but currently my sentiment is:\n> >>\n> >> Contributing features to Nova nowadays SUCKS!!1 (even as a core\n> >> reviewer) We _have_ to change that!\n> >\n> > I think this is *very* important.\n> >\n> > <rant>\n> > For instance, I have/had two patch series\n> > up. One is of length 2 and is relatively small.  It\'s basically sitting\n> > there\n> > with one \"+2\" on each patch.  I will now most likely have to apply for a\n> > FFE\n> > to get it merged, not because there\'s more changes to be made before it can\n> > get merged\n> > (there was one small nit posted yesterday) or because it\'s a huge patch\n> > that needs a lot\n> > of time to review, but because it just took a while to get reviewed by\n> > cores,\n> > and still only appears to have been looked at by one core.\n> >\n> > For the other patch series (which is admittedly much bigger), it was hard\n> > just to\n> > get reviews (and it was something where I actually *really* wanted several\n> > opinions,\n> > because the patch series touched a couple of things in a very significant\n> > way).\n> >\n> > Now, this is not my first contribution to OpenStack, or to Nova, for that\n> > matter.  I\n> > know things don\'t always get in.  It\'s frustrating, however, when it seems\n> > like the\n> > reason something didn\'t get in wasn\'t because it was fundamentally flawed,\n> > but instead\n> > because it didn\'t get reviews until it was too late to actually take that\n> > feedback into\n> > account, or because it just didn\'t get much attention review-wise at all.\n> > If I were a\n> > new contributor to Nova who had successfully gotten a major blueprint\n> > approved and\n> > the implemented, only to see it get rejected like this, I might get turned\n> > off of Nova,\n> > and go to work on one of the other OpenStack projects that seemed to move a\n> > bit faster.\n> > </rant>\n> \n> I see that you have done 7 reviews in the past 90 days. Doing reviews on\n> other people\'s code goes a long way towards getting some \"core karma\".\n\nSo, I\'ve tried to get in to reviewing, but my experience tends to be that,\neven with tools, I spend most of my time trying to find something to review.\nI\'ve found a few tags that I feel comfortable reviewing (because I know the\ncode paths well enough to give good feedback and not just nits).  However,\nI often find myself on a thread where a couple of cores have already commented,\nin which case I likely have very little to say.  This is not particularly an\nexcuse, just an explanation.\n\nThe other thing, of course, is that I get/got zoned in writing a large patch\nseries, and didn\'t stop much to review.  For me at least,\nI would love to be able to put my name into some sort of pool, and said\n\"ping me if you need a review of X subjects\".  If someone actually asked me for a\nreview, I would gladly put down my work for a bit and do a review, but I need to get\nbetter and stopping on my own and proactively seeking out reviews.\n\nAnyway, I think it would be useful to have some sort of page where people\ncould say \"I\'m an SME in X, ask me for reviews\" and then patch submitters could go\nand say, \"oh, I need an someone to review my patch about storage backends, let me\nask sross\".\n\n> \n> > So, it\'s silly to rant without actually providing any ideas on how to fix\n> > it.\n> > One suggestion would be, for each approved blueprint, to have one or two\n> > cores\n> > explicitly marked as being responsible for providing at least some feedback\n> > on\n> > that patch.  This proposal has issues, since we have a lot of blueprints\n> > and only\n> > twenty cores, who also have their own stuff to work on.  However, I think\n> > the\n> > general idea of having \"guaranteed\" reviewers is not unsound by itself.\n> > Perhaps\n> > we should have a loose tier of reviewers between \"core\" and \"everybody\n> > else\".\n> > These reviewers would be known good reviewers who would follow the\n> > implementation\n> > of particular blueprints if a core did not have the time.  Then, when those\n> > reviewers\n> > gave the \"+1\" to all the patches in a series, they could ping a core, who\n> > could feel\n> > more comfortable giving a \"+2\" without doing a deep inspection of the code.\n> \n> This is exactly the reason I believe there are so many places in Nova\n> that we have such an astonishing amount of technical debt. Core\n> reviewers are so swamped with the review load that they see +1s from\n> folks that they perceive to be SMEs on certain parts of the code and\n> give a less-than-needed-quality review of the patch and end up +2\'ing it\n> too early.\n> \n> It is *precisely* the holistic understanding of multiple parts of the\n> Nova codebase that is the critical piece that having 2 core reviewers\n> sign-off on the patch. Cores are supposed to have a good grasp of\n> multiple parts of the Nova subsystems and be able to tell (sometimes\n> instinctively, sometimes explicitly) when a patch introduces behaviour\n> that will incur more of the aforementioned technical debt. It is for\n> this reason I strongly oppose any loosening of the 2 +2s system.\n\nAh, but here\'s the thing: currently, we don\'t have nearly enough cores\nto maintain our current system.  I think @danpb\'s proposal to split out\nthe virt drivers would help alleviate this, since what is now a\nVMWare SME could become a VMWare core more easily.\n\n> \n> > That\'s just one suggestion, though.  Whatever the solution may be, this is\n> > a\n> > problem that we need to fix.  While I enjoyed going through the blueprint\n> > process\n> > this cycle (not sarcastic -- I actually enjoyed the whole \"structured\n> > feedback\" thing),\n> > the follow up to that was not the most pleasant.\n> >\n> > One final note: the specs referenced above didn\'t get approved until Spec\n> > Freeze, which\n> > seemed to leave me with less time to implement things.  In fact, it seemed\n> > that a lot\n> > of specs didn\'t get approved until spec freeze.  Perhaps if we had more\n> > staggered\n> > approval of specs, we\'d have more staggered submission of patches, and thus\n> > less of a\n> > sudden influx of patches in the couple weeks before feature proposal\n> > freeze.\n> \n> I actually think the last paragraph above contains a good suggestion.\n> This is, I think, similar to the \"slots\" approach that Joe Gordon and a\n> couple other folks were championing at the mid-cycle and I think has\n> quite a bit of merit. We need to find a way of:\n> \n>   * focusing reviewers more effectively\n>   * saying \"no\" more often and with more specific feedback\n>   * being more structured in the way we communicate what is being\n> actively reviewed and what isn\'t\n\nI think one of the issues is that Gerrit doesn\'t seem to have a good\nway to say \"show me some patches that have low review velocity\".  If\na patch submitter could manually say \"looking for reviewer\" (as opposed\nto just having reviewers try to figure out if a patch needs reviewers)\nand reviewers could easily filter on that, it might lower the bar for\n\"normal\" contributors to start reviewing more.\n\n> \n> I think the slots idea at least moves us in the proper direction\n> regarding the above three things.\n> \n> Best,\n> -jay\n> \n> > Best Regards,\n> > Solly Ross\n> >\n> > ----- Original Message -----\n> >> From: \"Nikola ?ipanov\" <ndipanov at redhat.com>\n> >> To: openstack-dev at lists.openstack.org\n> >> Sent: Wednesday, September 3, 2014 5:50:09 AM\n> >> Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for\n> >> Juno\n> >>\n> >> On 09/02/2014 09:23 PM, Michael Still wrote:\n> >>> On Tue, Sep 2, 2014 at 1:40 PM, Nikola ?ipanov <ndipanov at redhat.com>\n> >>> wrote:\n> >>>> On 09/02/2014 08:16 PM, Michael Still wrote:\n> >>>>> Hi.\n> >>>>>\n> >>>>> We\'re soon to hit feature freeze, as discussed in Thierry\'s recent\n> >>>>> email. I\'d like to outline the process for requesting a freeze\n> >>>>> exception:\n> >>>>>\n> >>>>>      * your code must already be up for review\n> >>>>>      * your blueprint must have an approved spec\n> >>>>>      * you need three (3) sponsoring cores for an exception to be\n> >>>>>      granted\n> >>>>\n> >>>> Can core reviewers who have features up for review have this number\n> >>>> lowered to two (2) sponsoring cores, as they in reality then need four\n> >>>> (4) cores (since they themselves are one (1) core but cannot really\n> >>>> vote) making it an order of magnitude more difficult for them to hit\n> >>>> this checkbox?\n> >>>\n> >>> That\'s a lot of numbers in that there paragraph.\n> >>>\n> >>> Let me re-phrase your question... Can a core sponsor an exception they\n> >>> themselves propose? I don\'t have a problem with someone doing that,\n> >>> but you need to remember that does reduce the number of people who\n> >>> have agreed to review the code for that exception.\n> >>>\n> >>\n> >> Michael has correctly picked up on a hint of snark in my email, so let\n> >> me explain where I was going with that:\n> >>\n> >> The reason many features including my own may not make the FF is not\n> >> because there was not enough buy in from the core team (let\'s be\n> >> completely honest - I have 3+ other core members working for the same\n> >> company that are by nature of things easier to convince), but because of\n> >> any of the following:\n> >>\n> >> * Crippling technical debt in some of the key parts of the code\n> >> * that we have not been acknowledging as such for a long time\n> >> * which leads to proposed code being arbitrarily delayed once it makes\n> >> the glaring flaws in the underlying infra apparent\n> >> * and that specs process has been completely and utterly useless in\n> >> helping uncover (not that process itself is useless, it is very useful\n> >> for other things)\n> >>\n> >> I am almost positive we can turn this rather dire situation around\n> >> easily in a matter of months, but we need to start doing it! It will not\n> >> happen through pinning arbitrary numbers to arbitrary processes.\n> >>\n> >> I will follow up with a more detailed email about what I believe we are\n> >> missing, once the FF settles and I have applied some soothing creme to\n> >> my burnout wounds, but currently my sentiment is:\n> >>\n> >> Contributing features to Nova nowadays SUCKS!!1 (even as a core\n> >> reviewer) We _have_ to change that!\n> >>\n> >> N.\n> >>\n> >>> Michael\n> >>>\n> >>>>>      * exceptions must be granted before midnight, Friday this week\n> >>>>> (September 5) UTC\n> >>>>>      * the exception is valid until midnight Friday next week\n> >>>>> (September 12) UTC when all exceptions expire\n> >>>>>\n> >>>>> For reference, our rc1 drops on approximately 25 September, so the\n> >>>>> exception period needs to be short to maximise stabilization time.\n> >>>>>\n> >>>>> John Garbutt and I will both be granting exceptions, to maximise our\n> >>>>> timezone coverage. We will grant exceptions as they come in and gather\n> >>>>> the required number of cores, although I have also carved some time\n> >>>>> out in the nova IRC meeting this week for people to discuss specific\n> >>>>> exception requests.\n> >>>>>\n> >>>>> Michael\n> >>>>>\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5408B0B4.3050207@gmail.com>',NULL),('<1049335029.17.1379744603885.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-21 06:23:23',0,'2013-09-21 06:23:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #27','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 1503 lines...]\n2013-09-21 06:17:08.127 29196 DEBUG glance.common.config [-] config_dir                     = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.127 29196 DEBUG glance.common.config [-] config_file                    = [\'/tmp/tmp.9K7n9KdEtW/tmpjT1V8R/etc/api.conf\'] log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.128 29196 DEBUG glance.common.config [-] data_api                       = glance.db.sqlalchemy.api log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.128 29196 DEBUG glance.common.config [-] db_auto_create                 = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.128 29196 DEBUG glance.common.config [-] debug                          = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.128 29196 DEBUG glance.common.config [-] default_log_levels             = [\'amqplib=WARN\', \'sqlalchemy=WARN\', \'boto=WARN\', \'suds=INFO\', \'keystone=INFO\', \'eventlet.wsgi.server=WARN\'] log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.129 29196 DEBUG glance.common.config [-] default_store                  = file log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.129 29196 DEBUG glance.common.config [-] delayed_delete                 = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.129 29196 DEBUG glance.common.config [-] enable_v1_api                  = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.129 29196 DEBUG glance.common.config [-] enable_v2_api                  = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.130 29196 DEBUG glance.common.config [-] fatal_deprecations             = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.130 29196 DEBUG glance.common.config [-] filesystem_store_datadir       = /tmp/tmp.9K7n9KdEtW/tmpjT1V8R/images log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.130 29196 DEBUG glance.common.config [-] image_size_cap                 = 1099511627776 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.130 29196 DEBUG glance.common.config [-] instance_format                = [instance: %(uuid)s]  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.131 29196 DEBUG glance.common.config [-] instance_uuid_format           = [instance: %(uuid)s]  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.131 29196 DEBUG glance.common.config [-] key_file                       =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.131 29196 DEBUG glance.common.config [-] known_stores                   = [\'glance.store.filesystem.Store\', \'glance.store.http.Store\', \'glance.store.rbd.Store\', \'glance.store.s3.Store\', \'glance.store.swift.Store\'] log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.131 29196 DEBUG glance.common.config [-] limit_param_default            = 25 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.132 29196 DEBUG glance.common.config [-] log_config                     = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.132 29196 DEBUG glance.common.config [-] log_date_format                = %Y-%m-%d %H:%M:%S log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.132 29196 DEBUG glance.common.config [-] log_dir                        = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.132 29196 DEBUG glance.common.config [-] log_file                       = /tmp/tmp.9K7n9KdEtW/tmpjT1V8R/api.log log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.133 29196 DEBUG glance.common.config [-] log_format                     = %(asctime)s %(levelname)8s [%(name)s] %(message)s log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.133 29196 DEBUG glance.common.config [-] logfile_mode                   = 0644 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.133 29196 DEBUG glance.common.config [-] logging_context_format_string  = %(asctime)s.%(msecs)03d %(levelname)s %(name)s [%(request_id)s %(user)s %(tenant)s] %(instance)s%(message)s log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.133 29196 DEBUG glance.common.config [-] logging_debug_format_suffix    = %(funcName)s %(pathname)s:%(lineno)d log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.134 29196 DEBUG glance.common.config [-] logging_default_format_string  = %(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-] %(instance)s%(message)s log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.134 29196 DEBUG glance.common.config [-] logging_exception_prefix       = %(asctime)s.%(msecs)03d %(process)d TRACE %(name)s %(instance)s log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.134 29196 DEBUG glance.common.config [-] metadata_encryption_key        = ******************************** log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.134 29196 DEBUG glance.common.config [-] notifier_strategy              = default log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.135 29196 DEBUG glance.common.config [-] owner_is_tenant                = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.135 29196 DEBUG glance.common.config [-] policy_default_rule            = default log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.135 29196 DEBUG glance.common.config [-] policy_file                    = /tmp/tmp.9K7n9KdEtW/tmpjT1V8R/etc/policy.json log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.135 29196 DEBUG glance.common.config [-] publish_errors                 = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.135 29196 DEBUG glance.common.config [-] pydev_worker_debug_host        = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.136 29196 DEBUG glance.common.config [-] pydev_worker_debug_port        = 5678 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.136 29196 DEBUG glance.common.config [-] rbd_store_ceph_conf            =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.136 29196 DEBUG glance.common.config [-] rbd_store_chunk_size           = 4 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.136 29196 DEBUG glance.common.config [-] rbd_store_pool                 =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.137 29196 DEBUG glance.common.config [-] rbd_store_user                 =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.137 29196 DEBUG glance.common.config [-] registry_client_ca_file        = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.137 29196 DEBUG glance.common.config [-] registry_client_cert_file      = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.137 29196 DEBUG glance.common.config [-] registry_client_insecure       = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.138 29196 DEBUG glance.common.config [-] registry_client_key_file       = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.138 29196 DEBUG glance.common.config [-] registry_client_protocol       = http log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.138 29196 DEBUG glance.common.config [-] registry_client_timeout        = 600 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.138 29196 DEBUG glance.common.config [-] registry_host                  = 127.0.0.1 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.138 29196 DEBUG glance.common.config [-] registry_port                  = 40348 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.139 29196 DEBUG glance.common.config [-] s3_store_access_key            =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.139 29196 DEBUG glance.common.config [-] s3_store_bucket                =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.139 29196 DEBUG glance.common.config [-] s3_store_bucket_url_format     =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.139 29196 DEBUG glance.common.config [-] s3_store_create_bucket_on_put  = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.140 29196 DEBUG glance.common.config [-] s3_store_host                  = s3.amazonaws.com log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.140 29196 DEBUG glance.common.config [-] s3_store_object_buffer_dir     = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.140 29196 DEBUG glance.common.config [-] s3_store_secret_key            =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.140 29196 DEBUG glance.common.config [-] scrub_time                     = 5 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.141 29196 DEBUG glance.common.config [-] scrubber_datadir               = /tmp/tmp.9K7n9KdEtW/tmpjT1V8R/scrubber log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.141 29196 DEBUG glance.common.config [-] show_image_direct_url          = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.141 29196 DEBUG glance.common.config [-] sql_connection                 = ***************************************************** log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.141 29196 DEBUG glance.common.config [-] sql_idle_timeout               = 3600 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.142 29196 DEBUG glance.common.config [-] sql_max_retries                = 60 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.142 29196 DEBUG glance.common.config [-] sql_retry_interval             = 1 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.142 29196 DEBUG glance.common.config [-] swift_enable_snet              = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.143 29196 DEBUG glance.common.config [-] swift_store_admin_tenants      = [\'[]\'] log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.143 29196 DEBUG glance.common.config [-] swift_store_auth_address       =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.143 29196 DEBUG glance.common.config [-] swift_store_auth_version       = 2 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.143 29196 DEBUG glance.common.config [-] swift_store_container          =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.144 29196 DEBUG glance.common.config [-] swift_store_create_container_on_put = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.144 29196 DEBUG glance.common.config [-] swift_store_endpoint_type      = publicURL log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.144 29196 DEBUG glance.common.config [-] swift_store_key                =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.145 29196 DEBUG glance.common.config [-] swift_store_large_object_chunk_size = 200 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.145 29196 DEBUG glance.common.config [-] swift_store_large_object_size  = 5120 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.145 29196 DEBUG glance.common.config [-] swift_store_multi_tenant       = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.145 29196 DEBUG glance.common.config [-] swift_store_region             = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.145 29196 DEBUG glance.common.config [-] swift_store_service_type       = object-store log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.146 29196 DEBUG glance.common.config [-] swift_store_user               =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.146 29196 DEBUG glance.common.config [-] syslog_log_facility            = LOG_USER log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.146 29196 DEBUG glance.common.config [-] tcp_keepidle                   = 600 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.146 29196 DEBUG glance.common.config [-] use_stderr                     = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.147 29196 DEBUG glance.common.config [-] use_syslog                     = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.147 29196 DEBUG glance.common.config [-] verbose                        = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.147 29196 DEBUG glance.common.config [-] workers                        = 0 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1481\n2013-09-21 06:17:08.147 29196 DEBUG glance.common.config [-] paste_deploy.config_file       = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1489\n2013-09-21 06:17:08.148 29196 DEBUG glance.common.config [-] paste_deploy.flavor            =  log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1489\n2013-09-21 06:17:08.148 29196 DEBUG glance.common.config [-] ******************************************************************************** log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py>:1491\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 229, in test_reload\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: Unexpected server launch status for: api, \nstrace:\nselect(0, NULL, NULL, NULL, {0, 82648}) = 0 (Timeout)\ngettimeofday({1379744237, 714581}, NULL) = 0\ngettimeofday({1379744237, 714864}, NULL) = 0\nsocket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 14\nfcntl(14, F_GETFL)                      = 0x2 (flags O_RDWR)\nfcntl(14, F_SETFL, O_RDWR|O_NONBLOCK)   = 0\nsetsockopt(14, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\nbind(14, {sa_family=AF_INET, sin_port=htons(46678), sin_addr=inet_addr(\"127.0.0.1\")}, 16) = -1 EADDRINUSE (Address already in use)\nclose(11)                               = 0\ngettimeofday({1379744237, 716999}, NULL) = 0\ngettimeofday({1379744237, 717277}, NULL) = 0\nselect(0, NULL, NULL, NULL, {0, 99721}) = 0 (Timeout)\ngettimeofday({1379744237, 817873}, NULL) = 0\ngettimeofday({1379744237, 818148}, NULL) = 0\nsocket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 11\nfcntl(11, F_GETFL)                      = 0x2 (flags O_RDWR)\nfcntl(11, F_SETFL, O_RDWR|O_NONBLOCK)   = 0\nsetsockopt(11, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\nbind(11, {sa_family=AF_INET, sin_port=htons(46678), sin_addr=inet_addr(\"127.0.0.1\")}, 16) = -1 EADDRINUSE (Address already in use)\nclose(14)                               = 0\ngettimeofday({1379744237, 819981}, NULL) = 0\ngettimeofday({1379744237, 820251}, NULL) = 0\nselect(0, NULL, NULL, NULL, {0, 99730}) = 0 (Timeout)\ngettimeofday({1379744237, 920809}, NULL) = 0\ngettimeofday({1379744237, 921083}, NULL) = 0\nsocket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 14\nfcntl(14, F_GETFL)                      = 0x2 (flags O_RDWR)\nfcntl(14, F_SETFL, O_RDWR|O_NONBLOCK)   = 0\nsetsockopt(14, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\nbind(14, {sa_family=AF_INET, sin_port=htons(46678), sin_addr=inet_addr(\"127.0.0.1\")}, 16) = -1 EADDRINUSE (Address already in use)\nclose(11)                               = 0\ngettimeofday({1379744237, 922873}, NULL) = 0\ngettimeofday({1379744237, 923191}, NULL) = 0\nselect(0, NULL, NULL, NULL, {0, 99681}) = 0 (Timeout)\ngettimeofday({1379744238, 23738}, NULL) = 0\ngettimeofday({1379744238, 24012}, NULL) = 0\nsocket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 11\nfcntl(11, F_GETFL)                      = 0x2 (flags O_RDWR)\nfcntl(11, F_SETFL, O_RDWR|O_NONBLOCK)   = 0\nsetsockopt(11, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\nbind(11, {sa_family=AF_INET, sin_port=htons(46678), sin_addr=inet_addr(\"127.0.0.1\")}, 16) = -1 EADDRINUSE (Address already in use)\nclose(14)                               = 0\ngettimeofday({1379744238, 25753}, NULL) = 0\ngettimeofday({1379744238, 26010}, NULL) = 0\nselect(0, NULL, NULL, NULL, {0, 99742}\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 129.19 secs:\n    32.20    TestScrubber.test_scrubber_app\n    26.06    TestScrubber.test_delayed_delete\n    25.65    TestRootApi.test_version_configurations\n    25.39    TestBinGlanceCacheManage.test_queue\n    19.88    TestImages.test_image_visibility_to_different_users\n----------------------------------------------------------------------\nRan 1101 tests in 1087.052s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.27\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.9K7n9KdEtW\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/27/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise27\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise27/27\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1049722539.4838070.1418216867816.JavaMail.yahoo@jws10975.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-10 13:07:47',0,'2014-12-10 13:07:47',NULL,'[Openstack] High Latency to VMs','Hi All, \n\nPlease recommend which stable Host OS to use for Controller and Compute node.I have tried Fedora20 seems lot of tweaking is required, corerct me If I am wrong. \nI see that most of it is tested on ubuntu and centos. \nI am planning to use JUNO stable version. \nPlease help on this\n?\nRegards\nNeelu \n\n     On Wednesday, 10 December 2014 5:42 PM, Hannah Fordham <hfordham at radiantworlds.com> wrote:\n   \n\n I\'m afraid we didn\'t, we\'re still struggling with some VMs with this problem. Sorry!\n\nOn 9 December 2014 14:09:32 GMT+00:00, \"Andr? Aranha\" <andre.f.aranha at gmail.com> wrote:\nHi,\nWe are with the same issue here, and already try some solutions that didn\'t work at all. Did you solved this problem?\nThank you,Andre Aranha\nOn 27 August 2014 at 08:17, Hannah Fordham <hfordham at radiantworlds.com> wrote:\n\nI?ve been trying to figure this one out for a while, so I?ll try and be as thorough as possible in this post but apologies if I miss anything pertinent out.?First off, I?m running a set up with one control node and 5 compute nodes, all created using the Stackgeek scripts- http://www.stackgeek.com/guides/gettingstarted.html. The first two (compute1 and compute 2) were created at the same time, compute3, 4 and 5 were added as needed later. My VMs are predominantly CentOS, while my Openstack nodes are Ubuntu 14.04.1?The symptom: irregular high latency/packet loss to VMs on all compute boxes except compute3. Mostly a pain when trying to do anything via ssh on a VM because the lag makes it difficult to do anything, but it shows itself quite nicely through pings as well:--- 10.0.102.47 ping statistics ---111 packets transmitted, 103 received, 7% packet loss, time 110024msrtt min/avg/max/mdev = 0.096/367.220/5593.100/1146.920 ms, pipe 6?\nI have tested these pings:VM to itself (via its external IP) seems fineVM to another VM is not fineHosting compute node to VM is not fineMy PC to VM is not fine (however the other way round works fine)??Top on a (32 core) compute node with laggy VMs:top - 12:09:20 up 33 days, 21:35,? 1 user,? load average: 2.37, 4.95, 6.23Tasks: 431 total,?? 2 running, 429 sleeping,?? 0 stopped,?? 0 zombie%Cpu(s):? 0.6 us,? 3.4 sy,? 0.0 ni, 96.0 id,? 0.0 wa,? 0.0 hi,? 0.0 si,? 0.0 stKiB Mem:? 65928256 total, 44210348 used, 21717908 free,?? 341172 buffersKiB Swap:? 7812092 total,? 1887864 used,? 5924228 free.? 7134740 cached Mem?And for comparison, on the one compute node that doesn?t seem to be suffering from this:top - 12:12:20 up 33 days, 21:38,? 1 user,? load average: 0.28, 0.18, 0.15Tasks: 399 total,?? 3 running, 396 sleeping,?? 0 stopped,?? 0 zombie%Cpu(s):? 0.3 us,? 0.1 sy,? 0.0 ni, 98.9 id,? 0.6 wa,? 0.0 hi,? 0.0 si,? 0.0 stKiB Mem:? 65928256 total, 49986064 used, 15942192 free,?? 335788 buffersKiB Swap:? 7812092 total,?? 919392 used,? 6892700 free. 39272312 cached Mem?Top on a laggy VM:top - 11:02:53 up 27 days, 33 min,? 3 users,? load average: 0.00, 0.00, 0.00Tasks:? 91 total,?? 1 running,? 90 sleeping,?? 0 stopped,?? 0 zombieCpu(s):? 0.2%us,? 0.1%sy,? 0.0%ni, 99.5%id,? 0.1%wa,? 0.0%hi,? 0.0%si,? 0.0%stMem:?? 1020400k total,?? 881004k used,?? 139396k free,?? 162632k buffersSwap:? 1835000k total,??? 14984k used,? 1820016k free,?? 220644k cached?http://imgur.com/blULjDa shows the hypervisor panel of Horizon. As you can see, Compute 3 has fewer resources used, but none of the compute nodes should be anywhere near overloaded fromwhat I can tell.?Any ideas? Let me know if I?m missing anything obvious that would help with figuring this out! ?Hannah????\n\n***********\n\nRadiant Worlds Limited is registered in England (company no: 07822337). This message is intended solely for the addressee and may contain confidential information. If you have received this message in error please send it back to us and immediately and permanently delete it from your system. Do not use, copy or disclose the information contained in this message or in any attachment. Please also note that transmission cannot be guaranteed to be secure or error-free.\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? ?: openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n\n***********\n\nRadiant Worlds Limited is registered in England (company no: 07822337). This message is intended solely for the addressee and may contain confidential information. If you have received this message in error please send it back to us and immediately and permanently delete it from your system. Do not use, copy or disclose the information contained in this message or in any attachment. Please also note that transmission cannot be guaranteed to be secure or error-free.\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141210/ed910d9c/attachment.html>\n\n','<54B5CB71-403D-418B-83F7-FC2CE399F045@radiantworlds.com>',NULL),('<104A9A8A-5843-4BE9-8961-3778ED90E204@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 17:27:56',-14400,'2014-06-10 21:27:56',NULL,'[openstack-dev] [oslo] versioning and releases','\nOn Jun 10, 2014, at 5:19 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n>> \n>> The new CI system can create packages as\n>> Python wheels and publish them to the appropriate servers, which means\n>> projects will no longer need to refer explicitly to pre-release\n>> tarballs.\n> \n> The details are a bit more nuanced here - pip won\'t install alpha\n> libraries unless you explicitly request them with a command line flag to\n> install any alphas available or you explicitly require the alpha\n> version.\n\nIt doesn?t have to explicitly require the alpha, it just has to include pre-releases\nso stuff like >=1.2a0,<1.3 would include 1.2a0 and higher, and ?less than 1.3?.\nUnfortunately that?s a bit wonky still because 1.3a0 is technically < 1.3 so\nit?d match too. At least until we finish implementing PEP 440.\n\n-----------------\nDonald Stufft\nPGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140610/f491bdb1/attachment.pgp>\n\n','<1402435157.9491.19.camel@sorcha>',NULL),('<1051345439.31.1381040926581.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-06 06:28:46',0,'2013-10-06 06:28:46',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #30','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/30/>\n\n------------------------------------------\n[...truncated 19247 lines...]\n    __import__(name)\n  File \"tempest/api/compute/images/test_images_oneserver.py\", line 30, in <module>\n    class ImagesOneServerTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/images/test_images_oneserver.py\", line 69, in ImagesOneServerTestJSON\n    @attr(type=[\'negative\', \'gate\'])\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1006725 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.object_storage.test_container_sync\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.object_storage.test_container_sync\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/object_storage/test_container_sync.py\", line 26, in <module>\n    class ContainerSyncTest(base.BaseObjectTest):\n  File \"tempest/api/object_storage/test_container_sync.py\", line 55, in ContainerSyncTest\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1093743 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.object_storage.test_object_expiry\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.object_storage.test_object_expiry\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/object_storage/test_object_expiry.py\", line 28, in <module>\n    class ObjectExpiryTest(base.BaseObjectTest):\n  File \"tempest/api/object_storage/test_object_expiry.py\", line 46, in ObjectExpiryTest\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1069849 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.servers.test_list_server_filters\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.servers.test_list_server_filters\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/servers/test_list_server_filters.py\", line 27, in <module>\n    class ListServerFiltersTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/servers/test_list_server_filters.py\", line 208, in ListServerFiltersTestJSON\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1170718 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.servers.test_server_actions\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.servers.test_server_actions\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/servers/test_server_actions.py\", line 33, in <module>\n    class ServerActionsTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/servers/test_server_actions.py\", line 91, in ServerActionsTestJSON\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1014647 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_instance_run\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_instance_run\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 35, in <module>\n    class InstanceRunTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 210, in InstanceRunTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1098891 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_keys\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_keys\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_keys.py\", line 30, in <module>\n    class EC2KeysTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_keys.py\", line 50, in EC2KeysTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1072318 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_network\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_network\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_network.py\", line 24, in <module>\n    class EC2NetworkTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_network.py\", line 34, in EC2NetworkTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1080406 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_s3_buckets\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_s3_buckets\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_s3_buckets.py\", line 25, in <module>\n    class S3BucketsTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_s3_buckets.py\", line 34, in S3BucketsTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1076965 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_flavors\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_flavors\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_flavors.py\", line 27, in <module>\n    class FlavorsAdminTestJSON(base.BaseComputeAdminTest):\n  File \"tempest/api/compute/admin/test_flavors.py\", line 198, in FlavorsAdminTestJSON\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1209101 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2497 tests in 1157.127s\nFAILED (id=0, failures=13, skips=46)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-556603-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-556603.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-556603/30/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1051659494.63.1383458635020.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:03:55',0,'2013-11-03 06:03:55',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-cinder-docs-stable-grizzly #46','See <https://jenkins02.openstack.org/job/periodic-cinder-docs-stable-grizzly/46/>\n\n\n\n','<1190225565.44.1383372298366.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1051906819.29.1375509797324.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-03 06:03:17',0,'2013-08-03 06:03:17',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #27','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/27/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-180929 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #211458 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stress] $ /bin/bash -xe /tmp/hudson6345623248142571289.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stress] $ /bin/bash -xe /tmp/hudson6437291175788237709.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_STRESS=1\n+ DEVSTACK_GATE_TEMPEST_STRESS=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-180929\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-180929/27\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-180929/27/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-180929/27/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1051957914.27146298.1402921983591.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 08:33:03',-14400,'2014-06-16 12:33:03',NULL,'[openstack-dev] [Ceilometer][Horizon] Exposing and showing\n associated resource_id within alarms/combined alarms','\n\n> Hello guys,\n> \n> I was taking a look at the proposed alarm-page designs [1] for the bp:\n> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page\n> and I saw that the alarms table has a column named ?Resource Name?. The\n> intention of that column is to show the resources associated within an alarm\n> (also for the case of more complex alarms or ?combined alarm? if you prefer)\n> but right now, ceilometer does only retrieve the associated resources id?s\n> inside the ?query? param (at least, for the threshold alarms, in the case of\n> combined alarms you won?t get any resource id).\n\nI don\'t really understand what you\'re getting at with ...\n\n \"ceilometer does only retrieve the associated resources id?s inside\n  the ?query? param\"\n\nBut I\'ll take a guess that you\'re concerned that ceilometer doesn\'t\nmap eagerly from resource ID to resource names?\n\nOk, let\'s back up a bit here and level-set ...\n\n* A ceilometer alarm *may* include a resource-based constraint\n\n* The resource-based constraint *may* be based on a resource ID,\n  or else on any other aspect of resource metadata that ceilometer\n  persists (e.g. in the case of a Heat autoscaling alarm, resource\n  ID wouldn\'t even enter into the equation, instead a group of\n  instances is referred to via their common user metadata)\n\n* Either way, the resource constraint isn\'t evaluated until the\n  stats query underpinning the alarm is evaluated\n\n* It has to work this way, as for a start the set of matching\n  resources may be different at the time the alarm is evaluated\n  as compared to when the alarm was defined\n\n> From the Horizon POV, getting the resource name represents a lot of work and\n> a huge impact in performance because, if we choose to show this ?Resource\n> Name? column, we would need to do, for each alarm retrieved :\n> \n> 1. Check the query parameter and then extract the resource id\n\nNote the resource ID is not a required constraint. Not all alarms will\ninclude this constraint. So it shouldn\'t be assumed in the UI.\n \n> 2. Then, depending on the type of resource (because it could be a vm, an\n> image, etc.) ask for its name to the appropriate service (not sure if that\n> is right way of doing it)\n> \n> 3. Save that name and then show it on the UI\n> \n> \n> \n> In the case of combined alarms, not only we?ll have to do all that but also:\n> \n> ? Extract the alarms_ids used for the alarm combination (which can be also\n> combined alarms, so take that into account)\n> \n> ? For each threshold alarm, run previous 1-3 steps\n> \n> o In case of step 3, instead of show the name to the UI, store it into a list\n> of resource names that needs to be showed after finishing the processing\n> \n> \n> \n> As you can see, for an alarm table of, let?s say 10 combined alarms (which it\n> could be a valid use case), we would need to do one call to alarm-list, 20\n> calls to alarm-shows and then other 20 calls to each of the service that\n> could give us the name of the resources.\n> \n> \n> \n> I?m seeing a couple of possible solutions:\n> \n> 1) not rendering the ?Resource name? column J (not actually an option)\n> \n> a. but I know it is the ?coward? solution and I also know that showing and\n> filtering alarms based on resources it?s a good and necessary feature.\n\nThis seems like the only sane solution IIUC, because as stated above there\nis *no assumption* of a 1:1 mapping between alarms and resources.\n\nLet me know if I\'ve misunderstood what you\'re getting at here,\n\nCheers,\nEoghan\n \n> 2) Expose the resource_id as we do with ?meter_name?, although we still need\n> to ask for the resource name on the horizon side\n> \n> a. For the combined alarms, expose a list of resources and (why not) a list\n> of meter associated with the combined alarms.\n> \n> 3) Save the resource id in the alarm table in a separated column and then\n> retrieve it\n> \n> a. For combined alarms, save a list of resource_id?s?\n> \n> 4) Any solution that you consider J\n> \n> \n> \n> \n> \n> Any thoughts around this?\n> \n> \n> \n> Thanks for all the help!\n> \n> Christian\n> \n> \n> \n> [1]:\n> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-06-05.pdf\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<6CA8C41F8AA4D6429838D9BD8CC4546C6C20A566@FMSMSX112.amr.corp.intel.com>',NULL),('<1053140071.408712.1415784426881.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 10:27:06',3600,'2014-11-12 09:27:06',NULL,'[openstack-dev] [Horizon] the future of angularjs development\n in Horizon','Hello all,\n\nI will write here some things I have noticed in the mailing list and on which I can contribute.\n\nNpm and Bower: \nbower and npm are here for two separate things, the first one is here to handle the dependencies of the webapp (angular, es5shim, d3.js and so on), meanwhile npm is here to handle the development environment (karma, grunt, jasmine, etc...). There is a possibility to avoid the use of bower by using npm alone, but I never tested that so a POC can be required.\n\nGrunt vs Gulp:\nBoth are equivalent but I have a preference for the second one. It is more powerful than grunt, more customizable, easier to understand for new comers. All the plugins for an angular development exists and are quite stable. Last but not least the angular team is now pushing to replace its infra from grunt to gulp. But like I said both are equivalent and can be switched easily, so if you are more comfortable with grunt it is not a big deal.\n\nTastipy vs Djangular:\nLike it has already been said we will use a restful API to handle the client server exchanges, so Tastipy seems to be preferable over Djangular.\n\nJasmine vs Mocha + Chai:\nI am not really aware of Mocha + Chai features, but I have already used Jasmine for all my angular testing and it feeds all my needs, please use the version 2.0 of it for its powerful features on asynchronous testing and the clean handle of variables in the testings. Last it is only one library which already have plugins for the karma test runner.\n\nI do not know if I addressed all the questions but here is a starting.\n\nCheers \n\nMax\n\n\n----- Original Message -----\nFrom: \"Matthias Runge\" <mrunge at redhat.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, November 12, 2014 9:39:29 AM\nSubject: Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon\n\nOn 12/11/14 09:28, Matthias Runge wrote:\n\n> \n> Looking at es5-shim, it pulls in additional 28 dependent packages, json3\n> has 12 dependencies (including a circular dependency, one circular\n> depencency in dependencies),\nPlease scratch that. I\'ll need to look at that a bit deeper (after\nanother coffee)\n\nMatthias\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54631CC1.6020005@redhat.com>',NULL),('<1053454508.2901770.1349278585125.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-03 11:36:25',-14400,'2012-10-03 15:36:25',NULL,'[openstack-dev] SmokeStack broken?','\n\n----- Original Message -----\n> From: \"Dan Smith\" <danms at us.ibm.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, October 2, 2012 2:40:18 PM\n> Subject: Re: [openstack-dev] SmokeStack broken?\n> \n> RB> I just talked to dprince.  He\'s going to turn off auto-posting of\n> RB> the -1 for unit tests while he works on resolving the issue.\n> \n> After that, do we need to resubmit a trivial change to clear it so\n> that\n> folks will review patches?\n\nHi Dan,\n\nI rekicked most of the failed test runs. The reviews marked as having failed unit tests should now be fixed.\n\nDan\n\n> \n> --\n> Dan Smith\n> IBM Linux Technology Center\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<87626thu0t.fsf@danplanet.com>',NULL),('<1053781981.38.1380263465393.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-27 06:31:05',0,'2013-09-27 06:31:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-neutron-python27-stable-grizzly #23','See <https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/23/>\n\n------------------------------------------\n[...truncated 5437 lines...]\n    test_create_service_type_default_returns_400                 OK    0.14\n    test_create_service_type_no_svcdef_returns_400               OK    0.15\n    test_delete_dummy_decreases_service_type_refcount            OK    0.17\n    test_delete_service_type_in_use_returns_409                  OK    0.17\n    test_get_default_service_type                                OK    0.15\n    test_get_service_type                                        OK    0.16\n    test_list_service_types                                      OK    0.18\n    test_service_type_create                                     OK    0.15\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.16\n    test_service_type_update_name                                OK    0.17\n    test_service_type_update_set_default_returns_400             OK    0.16\n    test_service_type_update_svc_defs                            OK    0.16\nServiceTypeManagerTestCaseXML\n    test_create_dummy_increases_service_type_refcount            OK    0.17\n    test_create_service_type_default_returns_400                 OK    0.14\n    test_create_service_type_no_svcdef_returns_400               OK    0.14\n    test_delete_dummy_decreases_service_type_refcount            OK    0.18\n    test_delete_service_type_in_use_returns_409                  OK    0.17\n    test_get_default_service_type                                OK    0.15\n    test_get_service_type                                        OK    0.17\n    test_list_service_types                                      OK    0.18\n    test_service_type_create                                     OK    0.16\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.16\n    test_service_type_update_name                                OK    0.17\n    test_service_type_update_set_default_returns_400             OK    0.17\n    test_service_type_update_svc_defs                            OK    0.16\nActionDispatcherTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_action_None                                    OK    0.00\n    test_dispatch_default                                        OK    0.00\nDictSerializerTest\n    test_dispatch_default                                        OK    0.00\nFaultTest\n    test_call_fault                                              OK    0.00\nJSONDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nJSONDictSerializerTest\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nMiddlewareTest\n    test_process_response                                        OK    0.01\nRequestDeserializerTest\n    test_deserialize                                             OK    0.00\n    test_get_action_args                                         OK    0.00\n    test_get_body_deserializer_unknown_content_type              OK    0.00\n    test_get_deserializer                                        OK    0.00\n    test_get_expected_content_type                               OK    0.00\nRequestHeadersDeserializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nRequestTest\n    test_content_type_accept_and_query_extension                 OK    0.00\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_accept_with_given_content_types            OK    0.00\n    test_content_type_from_accept                                OK    0.00\n    test_content_type_from_query_extension                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\n    test_content_type_with_given_content_types                   OK    0.00\nResourceTest\n    test_call_resource_class_bad_request                         OK    0.00\n    test_call_resource_class_internal_error                      OK    0.00\n    test_dispatch                                                OK    0.00\n    test_dispatch_unknown_controller_action                      OK    0.00\n    test_malformed_request_body_throws_bad_request               OK    0.00\n    test_type_error                                              OK    0.00\n    test_wrong_content_type_server_error                         OK    0.00\n    test_wrong_content_type_throws_unsupported_media_type_error  OK    0.00\nResponseHeadersSerializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nResponseSerializerTest\n    test_get_body_serializer                                     OK    0.00\n    test_get_serializer                                          OK    0.00\n    test_serialize_json_response                                 OK    0.00\n    test_serialize_response_None                                 OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_response                                  OK    0.00\nSerializerTest\n    test_deserialize_json_content_type                           OK    0.00\n    test_deserialize_raise_bad_request                           OK    0.00\n    test_deserialize_xml_content_type                            OK    0.00\n    test_deserialize_xml_content_type_with_meta                  OK    0.00\n    test_get_deserialize_handler_unknown_content_type            OK    0.00\n    test_serialize_content_type_json                             OK    0.00\n    test_serialize_content_type_xml                              OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_root_is_None                              OK    0.00\n    test_serialize_xml_root_key_is_dict                          OK    0.00\n    test_serialize_xml_root_key_is_list                          OK    0.00\nServerTest\n    test_run_server                                              OK    0.00\nTestWSGIServer\n    test_ipv6_listen_called_with_scope                           OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nTextDeserializerTest\n    test_dispatch_default                                        OK    0.01\nXMLDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_initialization                                          OK    0.00\n    test_xml_empty                                               OK    0.00\n    test_xml_with_utf8                                           OK    0.00\nXMLDictSerializerTest\n    test_None                                                    OK    0.00\n    test_call                                                    OK    0.00\n    test_empty_dic_xml                                           OK    0.00\n    test_non_root_one_item_dic_xml                               OK    0.00\n    test_non_root_two_items_dic_xml                              OK    0.00\n    test_xml                                                     OK    0.00\n    test_xml_meta_contains_node_name_dict                        OK    0.00\n    test_xml_meta_contains_node_name_list                        OK    0.00\n    test_xml_root_key_is_list                                    OK    0.00\n    test_xml_with_unicode                                        OK    0.00\n    test_xml_with_utf8                                           OK    0.00\n\n======================================================================\nERROR: quantum.tests.unit.test_debug_commands.TestDebugCommands.test_list_probe\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{2013-09-27 06:28:05,673    ERROR [cliff.display] (pyparsing 1.5.7 (<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/lib/python2.7/site-packages),> Requirement.parse(\'pyparsing>=2.0.1\'))}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/quantum/tests/unit/test_debug_commands.py\",> line 244, in test_list_probe\n    cmd = commands.ListProbe(self.app, None)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/quantumclient/quantum/v2_0/__init__.py\",> line 277, in __init__\n    super(QuantumCommand, self).__init__(app, app_args)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/cliff/display.py\",> line 21, in __init__\n    self.load_formatter_plugins()\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/cliff/display.py\",> line 38, in load_formatter_plugins\n    if self.app_args.debug:\nAttributeError: \'NoneType\' object has no attribute \'debug\'\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 12.50 secs:\n    2.82    ExtraRouteDBTestCase.test_floatingip_with_assoc\n    2.75    QuotaExtensionDbTestCaseXML.test_update_attributes\n    2.36    ExtraRouteDBTestCase.test_router_remove_interface_wrong_port_returns_404\n    2.30    L3NatDBTestCase.test_router_delete_subnet_inuse_returns_409\n    2.28    TestPortsV2.test_list_ports_with_sort_emulated\n----------------------------------------------------------------------\nRan 5179 tests in 1228.532s\n\nFAILED (SKIP=238, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==1.3.3\nalembic==0.6.0\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\nconfigobj==4.7.2\ncoverage==3.6\nd2to1==0.2.11\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkombu==2.5.14\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npyparsing==1.5.7\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-novaclient==2.15.0\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\npyudev==0.16.1\nquantum==jenkins.periodic.neutron.python27.stable.grizzly.23\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\ntermcolor==1.1.0\ntestrepository==0.0.17\ntesttools==0.9.32\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./quantum/tests/unit/nose_results.html\n+ \'[\' -f ./quantum/tests/unit/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./quantum/tests/unit/nose_results.html\n+ passcount=315\n+ \'[\' 315 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.s3nzomz1es\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-neutron-python27-stable-grizzly/23/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python27-stable-grizzly/precise15/23\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1054229680.5.1376721083582.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-17 06:31:23',0,'2013-08-17 06:31:23',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #9','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/9/>\n\n------------------------------------------\n[...truncated 21183 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=6.13 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 6.130/6.130/6.130/0.000 ms\n++ cinder list\n++ grep ex-vol-2af39bff\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1376720001\n+ cinder create --display_name ex-vol-2af39bff --display_description \'test volume: ex-vol-2af39bff\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-17T06:13:21.914949      |\n| display_description |     test volume: ex-vol-2af39bff     |\n|     display_name    |           ex-vol-2af39bff            |\n|          id         | 2547014a-dd4c-40c1-b556-79016957df79 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2af39bff | grep available; do sleep 1; done\'\n| 2547014a-dd4c-40c1-b556-79016957df79 | available | ex-vol-2af39bff |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376720004\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ get_field 1\n++ read data\n++ head -1\n++ grep ex-vol-2af39bff\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ echo \'| 2547014a-dd4c-40c1-b556-79016957df79 | available | ex-vol-2af39bff |  1   |     None    |  False   |             |\'\n++ read data\n+ VOL_ID=2547014a-dd4c-40c1-b556-79016957df79\n+ die_if_not_set 165 VOL_ID \'Failure retrieving volume ID for ex-vol-2af39bff\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1376720005\n+ nova volume-attach de5e5852-5a58-4951-9094-fa15cc0f4bad 2547014a-dd4c-40c1-b556-79016957df79 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | de5e5852-5a58-4951-9094-fa15cc0f4bad |\n| id       | 2547014a-dd4c-40c1-b556-79016957df79 |\n| volumeId | 2547014a-dd4c-40c1-b556-79016957df79 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2af39bff | grep in-use; do sleep 1; done\'\n| 2547014a-dd4c-40c1-b556-79016957df79 | in-use | ex-vol-2af39bff |  1   |     None    |  False   | de5e5852-5a58-4951-9094-fa15cc0f4bad |\n++ date +%s\n+ end_time=1376720008\n+ echo \'Completed volume-attach in 3 seconds\'\nCompleted volume-attach in 3 seconds\n++ cinder list\n++ grep ex-vol-2af39bff\n++ get_field -1\n++ read data\n++ head -1\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 2547014a-dd4c-40c1-b556-79016957df79 | in-use | ex-vol-2af39bff |  1   |     None    |  False   | de5e5852-5a58-4951-9094-fa15cc0f4bad |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=de5e5852-5a58-4951-9094-fa15cc0f4bad\n+ die_if_not_set 179 VOL_ATTACH \'Failure retrieving ex-vol-2af39bff status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ de5e5852-5a58-4951-9094-fa15cc0f4bad != de5e5852-5a58-4951-9094-fa15cc0f4bad ]]\n++ date +%s\n+ start_time=1376720009\n+ nova volume-detach de5e5852-5a58-4951-9094-fa15cc0f4bad 2547014a-dd4c-40c1-b556-79016957df79\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2af39bff | grep available; do sleep 1; done\'\n| 2547014a-dd4c-40c1-b556-79016957df79 | available | ex-vol-2af39bff |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376720012\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1376720012\n+ cinder delete 2547014a-dd4c-40c1-b556-79016957df79\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-2af39bff; do sleep 1; done\'\n| 2547014a-dd4c-40c1-b556-79016957df79 | deleting | ex-vol-2af39bff |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376720015\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete de5e5852-5a58-4951-9094-fa15cc0f4bad\n+ timeout 60 sh -c \'while nova list | grep -q de5e5852-5a58-4951-9094-fa15cc0f4bad; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1574.g1ac6776.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpbr3U6E\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpjDFMqa\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpzD5hSP\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp68rfFI\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2456 tests in 1004.394s\nFAILED (id=0, failures=2, skips=66)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/rabbitmq/rabbit at devstack-1376701883-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/rabbitmq/rabbit at devstack-1376701883.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-13521/9/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1737033965.5.1376634478738.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1054237863.14777282.1401719373495.JavaMail.zimbra@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-06-02 14:29:33',0,'2014-06-02 14:29:33',NULL,'[Openstack-stable-maint] Instance shelving is broken in Havana :\n	needs backport review','Hi,\nInstance shelving is broken in stable/havana, the instance that will be unshelved is not the one that has been shelved. A bug was filled here https://bugs.launchpad.net/nova/+bug/1257594 and a patch was merged in Icehouse. I\'d like to write a Tempest test to prevent this bug from happening again but in order to do this, I need the patch to be backported in stable/havana. A backport was proposed here : https://review.openstack.org/81214  It needs one more +2. Maybe you could help :)\n\nThanks a lot !\nJordan\n\n\n','<1957471795.14773225.1401719125750.JavaMail.zimbra@cloudwatt.com>',NULL),('<1054509955.424.1367129104446.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:05:04',0,'2013-04-28 06:05:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-docs-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-heat-docs-stable-grizzly/18/>\n\n\n\n','<787290691.361.1367042609378.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1055144733.262.1358752330373.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-21 07:12:10',0,'2013-01-21 07:12:10',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #74','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/74/>\n\n------------------------------------------\n[...truncated 19549 lines...]\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0yMVQwNzowNjozOS4wNDA4MTYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTIyVDA3OjA2OjM4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAiaWQiOiAiNmEwOTU2ZDNmNWVkNDgzZWI0YTYyNDc4MTVhZWNhOGQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjMTc1ZGYwOTdkYmI0MjkxYjhlZjZkNmU4NDQ0Y2M4YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ2Mjk4ZDFkZGIzNDYwZjg4NjI1YWM3NGRlZTI3ZTciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJpZCI6ICI2ZDIyMzgwZmEwYTg0MGVjYmNjNDk2MDNiY2M2MDY0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJlZmFiMmNiZDdjZDM0ZWVjOWY0MmI4ZTYzYjRkNzI5YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5IiwgImlkIjogIjNkNTdkMjRjNzVlMjQ3NDk4OWJiMjBlNzdiY2MwNjQ1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjkxZjQwOTc0YWEwNjRiMWQ5ZDRlOTJmOTUxOGJiMDEyIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmE1NTAwMjU4MWRmNDlkOGFlYjY1MmQwNmM1NGRlNTIiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWNlYTVmZTQ4NjJjNGJlYWFjNGRlOGRlZTUxNjg1N2YiLCAiMWZjNjgxMWU5MmFjNDRjMmJmM2M5MzQyNGQzNGVjNTgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCUI3tZQDKf9-ajPzzcfFroDeQwbR1cPOigpg6SyIIYZZj6Jo2qMRbg58BQd3BV0vm3u-ycG35Zc9wSS+-ATzlTG9rdFw3mEzSSFNpXlNk2xkZ4KP-+4mp4pV5FLmKBg5uM1Ivlq2Q8ATCQd5z10ejj8Rlq0djbh1LYtoOayQ8P7Q==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/09592191-0dbd-428b-9fcd-31ddf2280dfd\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 21 Jan 2013 07:07:55 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-02e0e910-0cae-45ff-8a5d-13452b46ceaf\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0yMVQwNzowNjozOS4wNDA4MTYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTIyVDA3OjA2OjM4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAiaWQiOiAiNmEwOTU2ZDNmNWVkNDgzZWI0YTYyNDc4MTVhZWNhOGQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjMTc1ZGYwOTdkYmI0MjkxYjhlZjZkNmU4NDQ0Y2M4YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ2Mjk4ZDFkZGIzNDYwZjg4NjI1YWM3NGRlZTI3ZTciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJpZCI6ICI2ZDIyMzgwZmEwYTg0MGVjYmNjNDk2MDNiY2M2MDY0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJlZmFiMmNiZDdjZDM0ZWVjOWY0MmI4ZTYzYjRkNzI5YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5IiwgImlkIjogIjNkNTdkMjRjNzVlMjQ3NDk4OWJiMjBlNzdiY2MwNjQ1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjkxZjQwOTc0YWEwNjRiMWQ5ZDRlOTJmOTUxOGJiMDEyIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmE1NTAwMjU4MWRmNDlkOGFlYjY1MmQwNmM1NGRlNTIiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWNlYTVmZTQ4NjJjNGJlYWFjNGRlOGRlZTUxNjg1N2YiLCAiMWZjNjgxMWU5MmFjNDRjMmJmM2M5MzQyNGQzNGVjNTgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCUI3tZQDKf9-ajPzzcfFroDeQwbR1cPOigpg6SyIIYZZj6Jo2qMRbg58BQd3BV0vm3u-ycG35Zc9wSS+-ATzlTG9rdFw3mEzSSFNpXlNk2xkZ4KP-+4mp4pV5FLmKBg5uM1Ivlq2Q8ATCQd5z10ejj8Rlq0djbh1LYtoOayQ8P7Q==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/43d9241e-7361-4509-837b-c92f8e6787e8\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 21 Jan 2013 07:07:57 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-fc463eee-6720-4914-9f03-01cff42f4b45\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0yMVQwNzowNjozOS4wNDA4MTYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTIyVDA3OjA2OjM4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAiaWQiOiAiNmEwOTU2ZDNmNWVkNDgzZWI0YTYyNDc4MTVhZWNhOGQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjMTc1ZGYwOTdkYmI0MjkxYjhlZjZkNmU4NDQ0Y2M4YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ2Mjk4ZDFkZGIzNDYwZjg4NjI1YWM3NGRlZTI3ZTciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJpZCI6ICI2ZDIyMzgwZmEwYTg0MGVjYmNjNDk2MDNiY2M2MDY0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJlZmFiMmNiZDdjZDM0ZWVjOWY0MmI4ZTYzYjRkNzI5YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5IiwgImlkIjogIjNkNTdkMjRjNzVlMjQ3NDk4OWJiMjBlNzdiY2MwNjQ1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjkxZjQwOTc0YWEwNjRiMWQ5ZDRlOTJmOTUxOGJiMDEyIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmE1NTAwMjU4MWRmNDlkOGFlYjY1MmQwNmM1NGRlNTIiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWNlYTVmZTQ4NjJjNGJlYWFjNGRlOGRlZTUxNjg1N2YiLCAiMWZjNjgxMWU5MmFjNDRjMmJmM2M5MzQyNGQzNGVjNTgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCUI3tZQDKf9-ajPzzcfFroDeQwbR1cPOigpg6SyIIYZZj6Jo2qMRbg58BQd3BV0vm3u-ycG35Zc9wSS+-ATzlTG9rdFw3mEzSSFNpXlNk2xkZ4KP-+4mp4pV5FLmKBg5uM1Ivlq2Q8ATCQd5z10ejj8Rlq0djbh1LYtoOayQ8P7Q==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/195767c3-09ed-4fe0-8c06-42c5dd67c9a9\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 21 Jan 2013 07:07:58 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c0ed73b6-c99e-4cd6-8030-7888869c1070\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0yMVQwNzowNjozOS4wNDA4MTYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTIyVDA3OjA2OjM4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzFmNGVlNDM0YmNjNDlkMGFhYWJlNDM1YzZiOGU5YzkiLCAiaWQiOiAiNmEwOTU2ZDNmNWVkNDgzZWI0YTYyNDc4MTVhZWNhOGQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJjMTc1ZGYwOTdkYmI0MjkxYjhlZjZkNmU4NDQ0Y2M4YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ2Mjk4ZDFkZGIzNDYwZjg4NjI1YWM3NGRlZTI3ZTciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSIsICJpZCI6ICI2ZDIyMzgwZmEwYTg0MGVjYmNjNDk2MDNiY2M2MDY0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJlZmFiMmNiZDdjZDM0ZWVjOWY0MmI4ZTYzYjRkNzI5YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzcxZjRlZTQzNGJjYzQ5ZDBhYWFiZTQzNWM2YjhlOWM5IiwgImlkIjogIjNkNTdkMjRjNzVlMjQ3NDk4OWJiMjBlNzdiY2MwNjQ1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83MWY0ZWU0MzRiY2M0OWQwYWFhYmU0MzVjNmI4ZTljOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjkxZjQwOTc0YWEwNjRiMWQ5ZDRlOTJmOTUxOGJiMDEyIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmE1NTAwMjU4MWRmNDlkOGFlYjY1MmQwNmM1NGRlNTIiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWNlYTVmZTQ4NjJjNGJlYWFjNGRlOGRlZTUxNjg1N2YiLCAiMWZjNjgxMWU5MmFjNDRjMmJmM2M5MzQyNGQzNGVjNTgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCUI3tZQDKf9-ajPzzcfFroDeQwbR1cPOigpg6SyIIYZZj6Jo2qMRbg58BQd3BV0vm3u-ycG35Zc9wSS+-ATzlTG9rdFw3mEzSSFNpXlNk2xkZ4KP-+4mp4pV5FLmKBg5uM1Ivlq2Q8ATCQd5z10ejj8Rlq0djbh1LYtoOayQ8P7Q==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/d5f19618-2ef8-4887-b198-d28fba226467\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Mon, 21 Jan 2013 07:08:00 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-02cac976-50bc-461c-abb0-f278044165e3\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers_with_non_authorized_user (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_object_with_another_user_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... SKIP: Until Bug 1091669  is resolved.\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_with_non_authorized_user (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object_using_temp_url (tempest.tests.object_storage.test_object_services.ObjectTest) ... SKIP: Until bug 1097137 is resolved.\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_read_object_with_non_authorized_user (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_with_non_authorized_user (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_public_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... SKIP: Until Bug #1020722 is resolved.\ntest_write_public_with_another_user_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... SKIP: Until Bug #1020722 is resolved.\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n======================================================================\nERROR: test_associate_ip_to_server_without_passing_floating_ip (tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/floating_ips_client.py\", line 73, in associate_floating_ip_to_server\n    resp, body = self.post(url, post_body, self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/2350c4b831864b9080f325c14923fa33/servers/2f9b1036-367f-4bc0-ba9f-7f3adb057780/action\ntempest.common.rest_client: ERROR: Request Body: {\"addFloatingIp\": {\"address\": \"\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 21 Jan 2013 06:35:54 GMT\', \'status\': \'400\', \'content-length\': \'82\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-83db7078-f43b-4d27-9688-da8e8cb0787e\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_associate_ip_to_server_without_passing_floating_ip (tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/floating_ips_client.py\", line 83, in associate_floating_ip_to_server\n    resp, body = self.post(url, str(doc), self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: Bad request\nDetails: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/534808db1df541a29b7b6b569addda77/servers/f3088eef-06b8-458c-8473-283a79bf3f0f/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<addFloatingIp address=\"\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Mon, 21 Jan 2013 06:36:46 GMT\', \'status\': \'400\', \'content-length\': \'144\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-b8456bb8-de1e-4d07-a490-4bc927b5c069\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_update_access_server_address (tempest.tests.compute.servers.test_servers.ServersTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 142, in test_update_access_server_address\n    self.assertEqual(\'::babe:2.2.2.2\', server[\'accessIPv6\'])\nAssertionError: \'::babe:2.2.2.2\' != u\'::babe:202:202\'\n    \"\'::babe:2.2.2.2\' != u\'::babe:202:202\'\" = \'%s != %s\' % (safe_repr(\'::babe:2.2.2.2\'), safe_repr(u\'::babe:202:202\'))\n    \"\'::babe:2.2.2.2\' != u\'::babe:202:202\'\" = self._formatMessage(\"\'::babe:2.2.2.2\' != u\'::babe:202:202\'\", \"\'::babe:2.2.2.2\' != u\'::babe:202:202\'\")\n>>  raise self.failureException(\"\'::babe:2.2.2.2\' != u\'::babe:202:202\'\")\n    \n\n======================================================================\nFAIL: test_update_access_server_address (tempest.tests.compute.servers.test_servers.ServersTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 142, in test_update_access_server_address\n    self.assertEqual(\'::babe:2.2.2.2\', server[\'accessIPv6\'])\nAssertionError: \'::babe:2.2.2.2\' != \'::babe:202:202\'\n    \"\'::babe:2.2.2.2\' != \'::babe:202:202\'\" = \'%s != %s\' % (safe_repr(\'::babe:2.2.2.2\'), safe_repr(\'::babe:202:202\'))\n    \"\'::babe:2.2.2.2\' != \'::babe:202:202\'\" = self._formatMessage(\"\'::babe:2.2.2.2\' != \'::babe:202:202\'\", \"\'::babe:2.2.2.2\' != \'::babe:202:202\'\")\n>>  raise self.failureException(\"\'::babe:2.2.2.2\' != \'::babe:202:202\'\")\n    \n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 667 tests in 2512.785s\n\nFAILED (SKIP=86, errors=2, failures=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/rabbitmq/rabbit at devstack-1358550086-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/rabbitmq/rabbit at devstack-1358550086.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/74/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<246612875.244.1358666168998.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1056394874.39.1352937897843.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-15 00:04:57',0,'2012-11-15 00:04:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-diablo #93','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/93/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/>\nCheckout:periodic-horizon-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/> - hudson.remoting.Channel at 276b998f:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson8576790822246592374.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-diablo/93\n[SCP] Copying console log.\n\n\n','<164465317.12.1352851335020.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<10567D74-39A2-4CA2-A5F9-A28989B19CB5@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-14 11:16:45',-25200,'2013-05-14 18:16:45',NULL,'[openstack-dev] Remove tenant/project ID from Nova v3 API URLs','Can\'t we solve this by putting a attribute on the resource itself (\"owner\")? After all the project_id is really just an attribute on the resource. The policy could then be crafted via attribute matching instead of uri matching.\n\nI don\'t see any reason to make the \"owner\" attribute special vs other attributes like state (policy could allow showing of \"soft-deleted\" vms) or flavor (policy could allow hiding some flavors). Including it in the uri or as a header seems like we are arbitrarily choosing one attribute of the resource and making it extra important. I don\'t really think that is justified.\n\nVish\n\nOn May 14, 2013, at 1:33 AM, Jorge Williams <jorge.williams at rackspace.com> wrote:\n\n> Need access to the project_id outside of the nova source and available via REST somehow. I also need a way of accessing the data from other OpenStack APIs for resources outside of nova.\n> \n> Here\'s the reason why:  Keystone v3 has the concept of polices in arbitrary languages such as XACML. XACML implementations are essentially attribute based access control systems. Usually there is a Policy Enforcement Point (PEP) which is a separate application that intercepts requests to a service and together with a Policy Decision Point (PDP) grants access to a request by taking a look at attributes of the user, the request itself, the resource, or the environment (current-time etc.).\n> \n> Currently the project_id of the resource is an attribute of the request, because it is in the URI.  If you remove it from the URI I lose access to it  all together and that means I can\'t write polices which refer to the project_id of the resource.  I think that\'s a big deal.\n> \n> The default built in policy that says that the project_id that the token is scoped must match the project_id of the resource works fine for most deployments, but operators should be able to define their own polices.\n> \n> -jOrGe W.\n\n\n','<94994F6C-3C0B-48AF-A5E4-DAD8003032C2@rackspace.com>',NULL),('<1056968920.57.1357522324600.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-07 01:32:04',0,'2013-01-07 01:32:04',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-postgres-vm-full #60','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/60/>\n\n\n\n','<688640405.30.1357435915082.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1058079370.354.1357258652147.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-04 00:17:32',0,'2013-01-04 00:17:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #95','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/95/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 10.69 secs:\n    3.29    Kc11TestCase.test_admin_requires_adminness\n    2.48    KcEssex3TestCase.test_admin_requires_adminness\n    2.34    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 53.136s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==3.0.5\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ZLIVqK8OEb\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/95\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/95/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<781831131.337.1357171987182.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1058224566.9242254.1405024007485.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 16:26:47',-14400,'2014-07-10 20:26:47',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n\n> From my perspective, the requirement is to be able to have a consistent and\n> predictable format for notifications that are being sent from all services.\n> This means:\n> 1. a set of required fields that all events contain and have consistent\n> meaning\n> 2. a set of optional fields, you don?t have to include these but if you do\n> then you follow the same format and meaning\n> 3. versioning of events: version is updated whenever the required fields are\n> changed. managing optional fields can be done via a specification\n\nYes, that pretty much sums it up.\n\n> Discovery of events would be interesting from an automated testing\n> perspective, but I am not sure how effective this would be for an\n> application actually consuming the event.s\n\nYes, the motivating usecase was discoverability for testing.\n\n> Not sure how you would use enumerating the consumption of events\n\nDitto, though on reflection I\'m thinking discoverablity of the more\ndownstream thing (the gathering of certain meters in ceilometer\'s case)\nwould be far more meaningful to reason over.\n\nCheers,\nEoghan \n\n> \n> \n> On Jul 10, 2014, at 2:48 AM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> \n> > \n> > TL;DR: do we need to stabilize notifications behind a versioned\n> >       and discoverable contract?\n> > \n> > Folks,\n> > \n> > One of the issues that has been raised in the recent discussions with\n> > the QA team about branchless Tempest relates to some legacy defects\n> > in the OpenStack notification system.\n> > \n> > Now, I don\'t personally subscribe to the PoV that ceilometer, or\n> > indeed any other consumer of these notifications (e.g. StackTach), was\n> > at fault for going ahead and depending on this pre-existing mechanism\n> > without first fixing it.\n> > \n> > But be that as it may, we have a shortcoming here that needs to be\n> > called out explicitly, and possible solutions explored.\n> > \n> > In many ways it\'s akin to the un-versioned RPC that existed in nova\n> > before the versioned-rpc-apis BP[1] was landed back in Folsom IIRC,\n> > except that notification consumers tend to be at arms-length from the\n> > producer, and the effect of a notification is generally more advisory\n> > than actionable.\n> > \n> > A great outcome would include some or all of the following:\n> > \n> > 1. more complete in-tree test coverage of notification logic on the\n> >    producer side\n> > \n> > 2. versioned notification payloads to protect consumers from breaking\n> >    changes in payload format\n> > \n> > 3. external discoverability of which event types a service is emitting\n> > \n> > 4. external discoverability of which event types a service is consuming\n> > \n> > If you\'re thinking that sounds like a substantial chunk of cross-project\n> > work & co-ordination, you\'d be right :)\n> > \n> > So the purpose of this thread is simply to get a read on the appetite\n> > in the community for such an effort. At the least it would require:\n> > \n> > * trashing out the details in say a cross-project-track session at\n> >   the K* summit\n> > \n> > * buy-in from the producer-side projects (nova, glance, cinder etc.)\n> >   in terms of stepping up to make the changes\n> > \n> > * acquiescence from non-integrated projects that currently consume\n> >   these notifications\n> > \n> >   (we shouldn\'t, as good citizens, simply pull the rug out from under\n> >   projects such as StackTach without discussion upfront)\n> > \n> > * dunno if the TC would need to give their imprimatur to such an\n> >   approach, or whether we could simply self-organize and get it done\n> >   without the need for governance resolutions etc.\n> > \n> > Any opinions on how desirable or necessary this is, and how the\n> > detailed mechanics might work, would be welcome.\n> > \n> > Apologies BTW if this has already been discussed and rejected as\n> > unworkable. I see a stalled versioned-notifications BP[2] and some\n> > references to the CADF versioning scheme in the LP fossil-record.\n> > Also an inconclusive ML thread from 2012[3], and a related grizzly\n> > summit design session[4], but it\'s unclear to me whether these\n> > aspirations got much traction in the end.\n> > \n> > Cheers,\n> > Eoghan\n> > \n> > [1] https://blueprints.launchpad.net/nova/+spec/versioned-rpc-apis\n> > [2] https://blueprints.launchpad.net/nova/+spec/versioned-notifications\n> > [3] http://osdir.com/ml/openstack/2012-10/msg00003.html\n> > [4] https://etherpad.openstack.org/p/grizzly-common-messaging\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<2D08261C-2A1F-4C85-AA44-929A8B0433C7@gmail.com>',NULL),('<1058247869.4881114.1361977152946.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 09:59:12',-18000,'2013-02-27 14:59:12',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','\n\n----- Original Message -----\n> From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n> To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, February 27, 2013 9:09:00 AM\n> Subject: Re: [openstack-dev] [keystone] re-ordering of schema migrations\n> \n> This was discussed in #openstack-dev, as I recall.\n> \n> The goal in these migrations was to support folsom <--> grizzly, not\n> necessarily supporting intermediate milestones. I\'m not aware of\n> anyone\n> doing continuous deployments of keystone, if but if migrating commit\n> to\n> commit is the community\'s expectation, I\'m more happy to ensure that\n> happens moving forward -- I just wasn\'t aware that was a concern\n> here.\n\nWe should always support upgrading between the milestones.\n\nAlso, Existing migrations should never be re-ordered.\n\nOne thing you could do is compact the \"released\" (as in part of the previous stable release) migrations into a single (large) migration in a way which doesn\'t break upgrades for previous users. \n\nSo at Folsom keystone had 15 migrations... In order to upgrade to Grizzly users would need to be at migration 15 (or greater). New installations would automatically run the \'compacted\' migration which initializes their schema to version 15 as well so they will be upgraded in a similar fashion. New migrations added in the grizzly timeframe should remain in order and untouched.\n\nMake sense?\n\nDan\n\n> \n> Thanks for the feedback, and apologies for any inconvenience!\n> \n> \n> -Dolph\n> \n> \n> On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n> \n> > On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:\n> > > Folks,\n> > >\n> > > When looking into an error encountered on a keystone db sync,\n> > > I noticed some apparent strangeness in the way keystone schema\n> > > migrations have been managed.\n> > >\n> > > Specifically the *rewriting* of schema migration history, see:\n> > >\n> > >   https://github.com/openstack/keystone/commit/5bc46d86\n> > >\n> > > In my (albeit imperfect) understanding of sqlalchemy-migrate,\n> > > this\n> > > reordering seems to defeat the whole purpose of step-wise\n> > > reversible\n> > > migration.\n> > >\n> > > Would it even be possible to migrate a grizzly-2 deployment to\n> > > grizzly-3 with that re-ordering in place?\n> > >\n> > > Maybe I\'ve missed something here, but I\'d appreciate some clarity\n> > > on what is considered community best practice in terms of changes\n> > > to the migration sequence.\n> > >\n> > > Previously I would have assumed something like ...\n> > >\n> > > Invariants we maintain:\n> > >\n> > >  - DB schemas must always be migrate-able across milestone\n> > >  releases\n> >\n> > (snip good stuff)\n> >\n> > It\'s more than just across milestone releases, we should support\n> > upgrading from commit to commit. In Nova, at least, we\'re trying\n> > hard to\n> > avoid messing up those who are deploying continuously. I\'d expect\n> > any\n> > nova-core member to reject this patch immediately.\n> >\n> > What I really don\'t understand is how this concern wasn\'t raised in\n> > the\n> > review at all:\n> >\n> >   https://review.openstack.org/19780\n> >\n> > Cheers,\n> > Mark.\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAC=h7gWfia0sJJip=pMu_iyFSFn_qvA55CdZCwGBj_wTUCyydA@mail.gmail.com>',NULL),('<10591429.11.1387742160254.JavaMail.yfried@yfried-mobl-rh>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-22 15:00:52',-18000,'2013-12-22 20:00:52',NULL,'[openstack-dev] [Openstack][qa][Tempest][Network] [Infra]Test\n for external connectivity','Hi Guys,\nSo, I\'m done with my patch:\nhttps://review.openstack.org/#/c/55146\n1. ping an external IP\n2. ping a url to test the dns\n3. check VM\'s resolve.conf\n4. change the dns server and recheck resolve.conf\n\nMy issue now (same as before) is that this test cannot be executed (and therefore pass) on the gate unless the gate is configured for external connectivity.\n\nA. How do I get the neutron gate to allow it\'s VM external connectivity (i.e. ping 8.8.8.8)?\n\nConsidering Jeremy\'s comment, I agree that depending on external ip/url introduces an unnecessary point of failure. However IMO, using multiple addresses is not the best way to proceed , I\'d rather test against a local node. Therefore:\n\nB. Can I get the neutron gate to enter it\'s own (local) DNS server? A local url?\nC. I this a change I can push to some project by myself, or do I need someone to change this for me (infra?)?\n\nI would really like your input in this matter, as I am in the final stretch of this patch and cannot move any farther by myself\n\nRegards\nYair Fried\n\n----- Original Message -----\nFrom: \"Jeremy Stanley\" <fungi at yuggoth.org>\nTo: openstack-dev at lists.openstack.org\nSent: Thursday, November 21, 2013 12:17:52 AM\nSubject: Re: [openstack-dev] [Openstack][qa][Tempest][Network] Test for external connectivity\n\nOn 2013-11-20 14:07:49 -0800 (-0800), Sean Dague wrote:\n> On 11/18/2013 02:41 AM, Yair Fried wrote:\n> [...]\n> > 2. add fields in tempest.conf for\n> >      * external connectivity = False/True\n> >      * external ip to test against (ie 8.8.8.8)\n> \n> +1 for #2. In the gate we\'ll need to think about what that address\n> can / should be. It may be different between different AZs. At this\n> point I\'d leave the rest of the options off the table until #2 is\n> working reliably.\n[...]\n\nHaving gone down this path in the past, I suggest the test check for\nno fewer than three addresses, sending several probes to each, and\nbe considered successful if at least one gets a response.\n-- \nJeremy Stanley\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20131120221750.GL2304@yuggoth.org>',NULL),('<1059A368-2006-4C85-8498-1241D072C3EA@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-31 20:10:10',7200,'2013-07-31 18:10:10',NULL,'[Openstack] Configuring Live Migration','chown -r nova. /var/lib/nova \n:)\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 31 juil. 2013 ? 19:36, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n\n> My config file is like that:\n> \n> ls -la /var/lib/nova/.ssh/config \n> -rw-r--r-- 1 nova root 25 Jul 31 10:49 /var/lib/nova/.ssh/config\n> \n> \n> 2013/7/31 Razique Mahroua <razique.mahroua at gmail.com>\n> ok make sure the file \'config\' belongs to the user nova and it\'ll be good :)\n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 31 juil. 2013 ? 18:11, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n> \n>> here is what happened:\n>> \n>>  ssh nova at 10.3.77.48\n>> The authenticity of host \'10.3.77.48 (10.3.77.48)\' can\'t be established.\n>> ECDSA key fingerprint is e3:ca:f7:dd:1e:1f:e3:e3:17:f8:52:09:a4:41:e1:40.\n>> Are you sure you want to continue connecting (yes/no)? yes\n>> Failed to add the host to the list of known hosts (/var/lib/nova/.ssh/known_hosts).\n>> nova at 10.3.77.48\'s password: \n>> \n>> I don\'t remember if I set up a password for nova user, I don\'t know which is it.\n>> \n>> Regards.\n>> \n>> \n>> 2013/7/31 Razique Mahroua <razique.mahroua at gmail.com>\n>> ok can you update the file /etc/passwd\n>> and use /bin/sh as a shell for the nova user\n>> then log as nova : \n>> # su - nova\n>> \n>> after that, try to ssh into the other node : \n>> # ssh nova at 10.3.77.48\n>> \n>> You shouldn\'t be asked for anything, you should just be connected to the host\n>> \n>> \n>> Le 31 juil. 2013 ? 17:07, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>> \n>>> This is the nova-compute.log\'s content from my Compute node \"Caos\" where the VM is first created.\n>>> \n>>> cat /var/log/nova/nova-compute.log | grep -E ERROR\n>>> 2013-07-31 11:18:49.606 ERROR nova.compute.manager [req-017b4047-9ec0-4412-9f9b-6660625f2221 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 96afb354-a6f8-49a8-9136-3fb2ef8bd321] Unexpected error while running command.\n>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>> 2013-07-31 11:18:50.245 ERROR nova.openstack.common.rpc.amqp [req-017b4047-9ec0-4412-9f9b-6660625f2221 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>> 2013-07-31 11:50:47.134 ERROR nova.compute.manager [req-91960dc0-9f6d-44cf-8abb-5b23c95f9850 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 0c729d3b-4e5a-45b8-9e68-1382b321d77e] Unexpected error while running command.\n>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>> 2013-07-31 11:50:47.909 ERROR nova.openstack.common.rpc.amqp [req-91960dc0-9f6d-44cf-8abb-5b23c95f9850 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>> \n>>> \n>>> cat /var/log/nova/nova-compute.log | grep -E TRACE\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line 430, in _process_data\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 117, in wrapped\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 94, in wrapped\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     return f(self, context, *args, **kw)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 209, in decorated_function\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     pass\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 195, in decorated_function\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 260, in decorated_function\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 237, in decorated_function\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     e, sys.exc_info())\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 224, in decorated_function\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 2354, in resize_instance\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     block_device_info)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3467, in migrate_disk_and_power_off\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     inst_base_resize)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3444, in migrate_disk_and_power_off\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     utils.execute(\'ssh\', dest, \'mkdir\', \'-p\', inst_base)\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp     cmd=\' \'.join(cmd))\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp ProcessExecutionError: Unexpected error while running command.\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp Command: ssh 10.3.77.48 mkdir -p /var/lib/nova/instances/96afb354-a6f8-49a8-9136-3fb2ef8bd321\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp Exit code: 255\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp Stdout: \'\'\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp Stderr: \'Host key verification failed.\\r\\n\'\n>>> 2013-07-31 11:18:50.245 19528 TRACE nova.openstack.common.rpc.amqp \n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line 430, in _process_data\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 117, in wrapped\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 94, in wrapped\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     return f(self, context, *args, **kw)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 209, in decorated_function\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     pass\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 195, in decorated_function\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 260, in decorated_function\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 237, in decorated_function\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     e, sys.exc_info())\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 224, in decorated_function\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 2354, in resize_instance\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     block_device_info)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3467, in migrate_disk_and_power_off\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     inst_base_resize)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3444, in migrate_disk_and_power_off\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     utils.execute(\'ssh\', dest, \'mkdir\', \'-p\', inst_base)\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp     cmd=\' \'.join(cmd))\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp ProcessExecutionError: Unexpected error while running command.\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp Command: ssh 10.3.77.48 mkdir -p /var/lib/nova/instances/0c729d3b-4e5a-45b8-9e68-1382b321d77e\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp Exit code: 255\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp Stdout: \'\'\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp Stderr: \'Host key verification failed.\\r\\n\'\n>>> 2013-07-31 11:50:47.909 19528 TRACE nova.openstack.common.rpc.amqp\n>>> \n>>> \n>>> \n>>> \n>>> \n>>> 2013/7/31 Filipe Manco <filipe.manco at gmail.com>\n>>> What\'s your error know when you try to migrate?\n>>> \n>>> Filipe Manco\n>>> http://about.me/fmanco\n>>> \n>>> \n>>> 2013/7/31 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>> I still don\'t know what to do, I\'ve checked again my nova.conf from my compute nodes, checked the public key from authorized_keys, checked the folder /var/lib/nova/instances mapped from my controller to my compute nodes, and checked the uid/gid from nova and libvirt-qemu.\n>>> \n>>> Am I missing anything?\n>>> \n>>> Thank you all.\n>>> \n>>> \n>>> 2013/7/31 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>> Yes, I was doing right so.\n>>> \n>>> \n>>> 2013/7/31 Razique Mahroua <razique.mahroua at gmail.com>\n>>> Pub, always the public key, the private key is?well private and should NEVER be shared :)\n>>> \n>>> Le 31 juil. 2013 ? 16:01, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>>> \n>>>> Just to check, the file to copy and insert into the authorized_keys is from the id_rsa or id_rsa.pub?\n>>>> \n>>>> Thank you.\n>>>> \n>>>> \n>>>> 2013/7/31 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>> Just make a correction on my path, it is in /var/lib/nova/.ssh not in /var/lib/.ssh like I sad before :)\n>>>> \n>>>> \n>>>> 2013/7/31 Razique Mahroua <razique.mahroua at gmail.com>\n>>>> \n>>>> Le 31 juil. 2013 ? 15:40, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>>>> \n>>>>> Hello friends,\n>>>>> \n>>>>>  First from JuanFra: I\'ve alrealdy checked it, they are the same.\n>>>>>  Second from Razique: Could you give me a strictly explanation, I already have the folder in /var/lib/.ssh with the file authorized_keys inside. This file config  must have only StrictHostKeyChecking no inside it?\n>>>> yup that prevents the user nova from being prompted to type \"yes\" if it\'s an unknown server\n>>>>  \n>>>>> \n>>>>> Thank you all.\n>>>>> \n>>>>> Guilherme.\n>>>>> \n>>>>> \n>>>>> 2013/7/31 Razique Mahroua <razique.mahroua at gmail.com>\n>>>>> Hey Guilherme :)\n>>>>> make sure : \n>>>>> ? To exchange pubkey of nova users amongst all nodes\n>>>>> ? Add in /var/lib a directory .ssh/ and create a \"config\" file with into : StrictHostKeyChecking no\n>>>>> \n>>>>> \n>>>>> \n>>>>> \n>>>>> Razique Mahroua - Nuage & Co\n>>>>> razique.mahroua at gmail.com\n>>>>> Tel : +33 9 72 37 94 15\n>>>>> \n>>>>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>>>>> \n>>>>> Le 30 juil. 2013 ? 19:08, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n>>>>> \n>>>>>> Sure, thank you.\n>>>>>> \n>>>>>> cat /var/log/nova/nova-compute.log | grep -E ERROR\n>>>>>> 2013-07-30 13:48:08.074 ERROR nova.compute.manager [req-bb59c9e8-8ef3-4461-8a51-01166ccc758d c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 5061e7a6-2482-4af2-97cf-0074326fb940] Unexpected error while running command.\n>>>>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>>>>> 2013-07-30 13:48:08.747 ERROR nova.openstack.common.rpc.amqp [req-bb59c9e8-8ef3-4461-8a51-01166ccc758d c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>>>>> \n>>>>>> cat /var/log/nova/nova-compute.log | grep -E TRACE\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line 430, in _process_data\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 117, in wrapped\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 94, in wrapped\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     return f(self, context, *args, **kw)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 209, in decorated_function\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     pass\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 195, in decorated_function\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 260, in decorated_function\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 237, in decorated_function\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     e, sys.exc_info())\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 224, in decorated_function\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 2354, in resize_instance\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     block_device_info)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3467, in migrate_disk_and_power_off\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     inst_base_resize)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3444, in migrate_disk_and_power_off\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     utils.execute(\'ssh\', dest, \'mkdir\', \'-p\', inst_base)\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp     cmd=\' \'.join(cmd))\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp ProcessExecutionError: Unexpected error while running command.\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp Command: ssh 10.3.77.48 mkdir -p /var/lib/nova/instances/5061e7a6-2482-4af2-97cf-0074326fb940\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp Exit code: 255\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp Stdout: \'\'\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp Stderr: \'Host key verification failed.\\r\\n\'\n>>>>>> 2013-07-30 13:48:08.747 6254 TRACE nova.openstack.common.rpc.amqp \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Filipe Manco <filipe.manco at gmail.com>\n>>>>>> Can you provide more information (errors and/or logs)?\n>>>>>> \n>>>>>> Filipe Manco\n>>>>>> http://about.me/fmanco\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>> It didn\'t work :(\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>> Ok, testing it.\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Filipe Manco <filipe.manco at gmail.com>\n>>>>>> Basically edit the /etc/passwd and /etc/passwd- files and change /bin/false to /bin/bash on the nova user entry.\n>>>>>> \n>>>>>> I\'m having another problem after this related to libvirt but I have no time to fix it know. Basically the migration ends but then libvirt isn\'t able to boot the machine again. Let me know about your results.\n>>>>>> \n>>>>>> Regards\n>>>>>> \n>>>>>> Filipe Manco\n>>>>>> http://about.me/fmanco\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>> Ok, on my scenario I have 2 Compute nodes and 1 Controller + Network node, how did you change your configs, I can try your idea.\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Filipe Manco <filipe.manco at gmail.com>\n>>>>>> No I just wanted to know what is your scenario. About the mkdir I spend a couple of time looking at it and managed to fix it by changing the shell of the nova user to /bin/bash instead of /bin/false on all the compute nodes. You can try it.\n>>>>>> \n>>>>>> Filipe Manco\n>>>>>> http://about.me/fmanco\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>> Hello Filipe, I followed the manual on the openstack documentation, I shared the /var/lib/nova/instances on my controller, do I need to share another folders?\n>>>>>> \n>>>>>> Regards.\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Filipe Manco <filipe.manco at gmail.com>\n>>>>>> Hi\n>>>>>> \n>>>>>> A couple of messages ago you shown an error where the mkdir command failed. At that time the keys were properly configured. Can you revert your changes?\n>>>>>> \n>>>>>> About the mkdir error, I had a similar one but I wasn\'t able to fix it yet. Do you have shared storage for your instances?\n>>>>>> \n>>>>>> I never used virsh directly because, AFAIK, openstack will not be informed of the changes and will not work correctly (but I may be wrong in this one).\n>>>>>> \n>>>>>> Filipe Manco\n>>>>>> http://about.me/fmanco\n>>>>>> \n>>>>>> \n>>>>>> 2013/7/30 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>> I created the new key, but still getting error: here are the logs:\n>>>>>> \n>>>>>> cat /var/log/nova/nova-compute.log | grep -E ERROR\n>>>>>> 2013-07-30 11:37:51.097 ERROR nova.compute.manager [req-c3441bfc-dcd7-4625-b701-716f152a4bfe c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: bed3c3be-31d6-42c3-9a7f-e40ef9c1c764] Unexpected error while running command.\n>>>>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>>>>> 2013-07-30 11:37:52.463 ERROR nova.openstack.common.rpc.amqp [req-c3441bfc-dcd7-4625-b701-716f152a4bfe c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>>>>> \n>>>>>> \n>>>>>> cat /var/log/nova/nova-compute.log | grep -E TRACE\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line 430, in _process_data\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py\", line 133, in dispatch\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 117, in wrapped\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/exception.py\", line 94, in wrapped\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     return f(self, context, *args, **kw)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 209, in decorated_function\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     pass\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 195, in decorated_function\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 260, in decorated_function\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 237, in decorated_function\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     e, sys.exc_info())\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 224, in decorated_function\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 2354, in resize_instance\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     block_device_info)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3467, in migrate_disk_and_power_off\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     inst_base_resize)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3444, in migrate_disk_and_power_off\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     utils.execute(\'ssh\', dest, \'mkdir\', \'-p\', inst_base)\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp     cmd=\' \'.join(cmd))\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp ProcessExecutionError: Unexpected error while running command.\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp Command: ssh 10.3.77.48 mkdir -p /var/lib/nova/instances/bed3c3be-31d6-42c3-9a7f-e40ef9c1c764\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp Exit code: 255\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp Stdout: \'\'\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp Stderr: \'Host key verification failed.\\r\\n\'\n>>>>>> 2013-07-30 11:37:52.463 6254 TRACE nova.openstack.common.rpc.amqp \n>>>>>> \n>>>>>> I\'ve been trying to migrate directly with virsh, but I got this error and the solutions through the web don\'t help.\n>>>>>> \n>>>>>> virsh migrate --live instance-00000063 qemu+ssh://192.168.3.3/system\n>>>>>> root at 192.168.3.3\'s password: \n>>>>>> erro: internal error cannot load AppArmor profile \'libvirt-bed3c3be-31d6-42c3-9a7f-e40ef9c1c764\'\n>>>>>> \n>>>>>> \n>>>>>> Thank you all.\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> 2013/7/29 <yongiman at gmail.com>\n>>>>>> \n>>>>>> Hi Guilherme,\n>>>>>> \n>>>>>> I suugest making new ssh key and put the public key in the host\n>>>>>> \n>>>>>> # ssh-keygen (you will find id_rsa.pub in your .ssh directory)\n>>>>>> \n>>>>>> Copy the contents of this file and paste at the last line of authorized_keys in the host.\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> On 2013. 7. 29., at ?? 10:40, Guilherme Russi <luisguilherme.cr at gmail.com> wrote:\n>>>>>> \n>>>>>>> Hello Filipe, I created the /var/lib/nova/.ssh/authorized_keys and its content is the keys from the know_hosts, is it right? I\'m still getting the same error when I try to migrate a VM.\n>>>>>>> \n>>>>>>> Thank you.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Filipe Manco <filipe.manco at gmail.com>\n>>>>>>> About the keys it\'s up to you. You can use the same or create a new one. Using the same is easier.\n>>>>>>> \n>>>>>>> But the nova user public key should go into /var/lib/nova/.ssh/authorized_keys not into the know_hosts file. The easier way (as you only have two compute nodes) to add the keys to the know_hosts is to manually ssh and accept the key.\n>>>>>>> \n>>>>>>> Filipe Manco\n>>>>>>> http://about.me/fmanco\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> Ok, Must I create another ssh key to communicate both compute nodes or the current key can work? I\'ve put the plublic key from both compute node in the know_hosts. Which permission should I apply? 644?\n>>>>>>> \n>>>>>>> Thank you.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Filipe Manco <filipe.manco at gmail.com>\n>>>>>>> First you need to check why this \"Failed to add the host to the list of known hosts (/var/lib/nova/.ssh/known_hosts).\" happens. It maybe file permissions or so. Then you need to generate an ssh key for the user nova and add it to the other compute nodes on the authorized_keys file (the password is not really necessary as soon as you have the keys in place).\n>>>>>>> \n>>>>>>> Filipe Manco\n>>>>>>> http://about.me/fmanco\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> sudo -u nova ssh 192.168.3.3\n>>>>>>> The authenticity of host \'192.168.3.3 (192.168.3.3)\' can\'t be established.\n>>>>>>> ECDSA key fingerprint is e3:ca:f7:dd:1e:1f:e3:e3:17:f8:52:09:a4:41:e1:40.\n>>>>>>> Are you sure you want to continue connecting (yes/no)? yes\n>>>>>>> Failed to add the host to the list of known hosts (/var/lib/nova/.ssh/known_hosts).\n>>>>>>> nova at 192.168.3.3\'s password: \n>>>>>>> \n>>>>>>> But I don\'t know the user nova\'s password.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Filipe Manco <filipe.manco at gmail.com>\n>>>>>>> Can you try sudo -u nova ssh <remote-compute-node> form the compute node currently running the VM and check if it works?\n>>>>>>> \n>>>>>>> Filipe Manco\n>>>>>>> http://about.me/fmanco\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> Hello Filipe,\n>>>>>>> \n>>>>>>>  I made the copy from my .ssh/know_hosts to places you told me, but I\'m still getting the same error. Any other ideas?\n>>>>>>> \n>>>>>>> Thank you.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Filipe Manco <filipe.manco at gmail.com>\n>>>>>>> Hi\n>>>>>>> \n>>>>>>> This error means that you cannot ssh into the new compute node because it\'s public key cannot be verified. Add the public keys of the compute nodes to /etc/ssh/know_hosts file (or the nova one, usually under /var/lib/nova/.ssh/) and the problem should be gone.\n>>>>>>> \n>>>>>>> Regards\n>>>>>>> \n>>>>>>> Filipe Manco\n>>>>>>> http://about.me/fmanco\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/26 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> Ok, I\'ll look more carefully the log and it\'s cool this command from libvirt, I didn\'t know it, I\'ll try it and return to you.\n>>>>>>> \n>>>>>>> Thank you again.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/25 Wangpan <hzwangpan at corp.netease.com>\n>>>>>>> That\'s confused me, \"Unexpected error while running command\" will give us what command is running when this error occured, you may check the log more carefully.\n>>>>>>> and you also can migrate the VM directly by libvirt command line like below:\n>>>>>>> virsh  migrate --live --persistent --undefinesource --verbose --domain ${instance-uuid} --desturi qemu+tcp://${the-dest-host-ip}/system\n>>>>>>> then see the output result.\n>>>>>>>  \n>>>>>>> 2013-07-26\n>>>>>>> Wangpan\n>>>>>>> ????Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> ?????2013-07-26 09:30\n>>>>>>> ???Re: Re: Re: Re: Re: [Openstack] Configuring Live Migration\n>>>>>>> ????\"Wangpan\"<hzwangpan at corp.netease.com>\n>>>>>>> ???\"openstack at lists.launchpad.net\"<openstack at lists.launchpad.net>\n>>>>>>>  \n>>>>>>> When I enter the action to migrate, the only two errors showen at this period are these two.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/25 Wangpan <hzwangpan at corp.netease.com>\n>>>>>>> There may have more error logs at this minute 2013-07-25 17:28,\n>>>>>>> you can get the backtrace near the error log you post.\n>>>>>>>  \n>>>>>>> 2013-07-26\n>>>>>>> Wangpan\n>>>>>>> ????Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> ?????2013-07-26 04:48\n>>>>>>> ???Re: Re: Re: Re: [Openstack] Configuring Live Migration\n>>>>>>> ????\"Wangpan\"<hzwangpan at corp.netease.com>,\"openstack at lists.launchpad.net\"<openstack at lists.launchpad.net>\n>>>>>>> ???\n>>>>>>>  \n>>>>>>> Hello guys, I\'m getting problems when trying to migrate a VM.\n>>>>>>> \n>>>>>>> I\'m getting this error on my log:\n>>>>>>> \n>>>>>>> 2013-07-25 17:28:31.582 ERROR nova.compute.manager [req-07d2c8b0-80c3-4ae8-8faf-226a099500e4 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 919f13d2-8116-4714-b2ec-d2e0f3d3c910] Unexpected error while running command.\n>>>>>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>>>>>> 2013-07-25 17:28:32.212 ERROR nova.openstack.common.rpc.amqp [req-07d2c8b0-80c3-4ae8-8faf-226a099500e4 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>>>>>> \n>>>>>>> \n>>>>>>> The user Wangpan was helping me, but I guess his hour is different from mine, can anybody five me an idea?\n>>>>>>> \n>>>>>>> Thank you.\n>>>>>>> \n>>>>>>> Guilherme.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/25 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> Hello Wangpan, I\'ve looking at the logs and I saw one error with my ssh port, and then I fixed the port, but now I\'m getting this error: \n>>>>>>> \n>>>>>>> 2013-07-25 14:09:50.388 ERROR nova.compute.manager [req-6930a2e2-60e7-421f-a560-26a626ecebcb c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: d268d24b-96fc-4450-88d4-19ba83cd8892] Unexpected error while running command.\n>>>>>>> Stderr: \'Host key verification failed.\\r\\n\'. Setting instance vm_state to ERROR\n>>>>>>> 2013-07-25 14:09:51.005 ERROR nova.openstack.common.rpc.amqp [req-6930a2e2-60e7-421f-a560-26a626ecebcb c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>>>>>> \n>>>>>>> What \"host key verification\"? Where should I put this key?\n>>>>>>> \n>>>>>>> Thank you.\n>>>>>>> \n>>>>>>> Guilherme.\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/25 Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> Typed wrong here\n>>>>>>> \n>>>>>>> Em 25/07/2013 00:42, \"Wangpan\" <hzwangpan at corp.netease.com> escreveu:\n>>>>>>> chmod 777 -R /var/lib/nova/instances\n>>>>>>> not the /var/log/nova/instances\n>>>>>>>  \n>>>>>>> 2013-07-25\n>>>>>>> Wangpan\n>>>>>>> ????Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> ?????2013-07-25 10:39\n>>>>>>> ???Re: Re: Re: [Openstack] Configuring Live Migration\n>>>>>>> ????\"Wangpan\"<hzwangpan at corp.netease.com>\n>>>>>>> ???\n>>>>>>>  \n>>>>>>> I\'ve done chmod 777 -R /var/log/nova/instances\n>>>>>>> \n>>>>>>> Does it work?\n>>>>>>> \n>>>>>>> \n>>>>>>> 2013/7/24 Wangpan <hzwangpan at corp.netease.com>\n>>>>>>> I saw this error \"Permission denied: \'/var/lib/nova/instances/\'\" in your logs.\n>>>>>>> you may need to chown the instances path  \'/var/lib/nova/instances/\'\n>>>>>>>  \n>>>>>>> 2013-07-25\n>>>>>>> Wangpan\n>>>>>>> ????Guilherme Russi <luisguilherme.cr at gmail.com>\n>>>>>>> ?????2013-07-25 10:08\n>>>>>>> ???Re: Re: [Openstack] Configuring Live Migration\n>>>>>>> ????\"Wangpan\"<hzwangpan at corp.netease.com>\n>>>>>>> ???\n>>>>>>>  \n>>>>>>> Compute Node 01:\n>>>>>>> \n>>>>>>> cat /var/log/nova/nova-*.log | grep -E ERROR\n>>>>>>> 2013-07-24 08:03:57.262 1820 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 08:43:57.655 1820 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 09:23:57.816 1820 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 10:03:57.993 1820 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 10:20:21.767 ERROR nova.compute.manager [req-c4b2d1db-676c-4398-a5b8-582a76ec6c35 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 55215431-0a42-4fc8-a642-c08d3cc5e2bc] Instance failed to spawn\n>>>>>>> 2013-07-24 10:20:29.326 1820 ERROR nova.virt.libvirt.driver [-] [instance: 55215431-0a42-4fc8-a642-c08d3cc5e2bc] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 10:20:29.511 ERROR nova.compute.manager [req-c4b2d1db-676c-4398-a5b8-582a76ec6c35 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 55215431-0a42-4fc8-a642-c08d3cc5e2bc] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/55215431-0a42-4fc8-a642-c08d3cc5e2bc/\'\\n\"]\n>>>>>>> 2013-07-24 10:33:17.279 ERROR nova.compute.manager [req-f10c5f14-b3ad-4c13-b20f-c53f57379163 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: ca733a02-766e-46e1-9a15-bd2a12b10ebd] Instance failed to spawn\n>>>>>>> 2013-07-24 10:33:36.673 1820 ERROR nova.virt.libvirt.driver [-] [instance: ca733a02-766e-46e1-9a15-bd2a12b10ebd] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 10:33:36.837 ERROR nova.compute.manager [req-f10c5f14-b3ad-4c13-b20f-c53f57379163 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: ca733a02-766e-46e1-9a15-bd2a12b10ebd] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/ca733a02-766e-46e1-9a15-bd2a12b10ebd/\'\\n\"]\n>>>>>>> 2013-07-24 10:40:26.722 ERROR nova.compute.manager [req-5d0289b3-36d7-4046-996c-a1decb922066 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 3b15a4e9-fb2c-452a-8045-16d1f58ebf73] Instance failed to spawn\n>>>>>>> 2013-07-24 10:40:39.402 1820 ERROR nova.virt.libvirt.driver [-] [instance: 3b15a4e9-fb2c-452a-8045-16d1f58ebf73] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 10:40:39.530 ERROR nova.compute.manager [req-5d0289b3-36d7-4046-996c-a1decb922066 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 3b15a4e9-fb2c-452a-8045-16d1f58ebf73] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/3b15a4e9-fb2c-452a-8045-16d1f58ebf73/\'\\n\"]\n>>>>>>> 2013-07-24 10:43:58.194 1820 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 11:03:19.657 ERROR nova.virt.libvirt.driver [req-5441aa83-cc8a-4d25-a17e-9e4f63448451 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Error on \'/var/lib/nova/instances\' while checking direct I/O: \'[Errno 13] Permission denied: \'/var/lib/nova/instances/.directio.test\'\'\n>>>>>>> 2013-07-24 11:03:19.658 ERROR nova.compute.manager [req-5441aa83-cc8a-4d25-a17e-9e4f63448451 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 40c3fb5c-61d9-491a-9bfa-cac824a2887d] Instance failed to spawn\n>>>>>>> 2013-07-24 11:03:32.036 1685 ERROR nova.virt.libvirt.driver [-] [instance: 40c3fb5c-61d9-491a-9bfa-cac824a2887d] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 11:03:32.170 ERROR nova.compute.manager [req-5441aa83-cc8a-4d25-a17e-9e4f63448451 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 40c3fb5c-61d9-491a-9bfa-cac824a2887d] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1510, in spawn\\n    block_device_info=block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2326, in to_xml\\n    disk_info, rescue, block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2244, in get_guest_config\\n    inst_type):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2051, in get_guest_storage_config\\n    inst_type)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2013, in get_guest_disk_config\\n    self.disk_cachemode,\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 355, in disk_cachemode\\n    if not self._supports_direct_io(CONF.instances_path):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1676, in _supports_direct_io\\n    {\\\'path\\\': dirpath, \\\'ex\\\': str(e)})\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1663, in _supports_direct_io\\n    f = os.open(testfile, os.O_CREAT | os.O_WRONLY | os.O_DIRECT)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/.directio.test\'\\n\"]\n>>>>>>> 2013-07-24 11:22:38.103 ERROR nova.compute.manager [req-26522972-c8be-4be5-83d1-f45412718d94 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: fd3ab09d-fc9f-4ee9-b5f5-72540893ecd3] Instance failed to spawn\n>>>>>>> 2013-07-24 11:22:50.791 1685 ERROR nova.virt.libvirt.driver [-] [instance: fd3ab09d-fc9f-4ee9-b5f5-72540893ecd3] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 11:22:50.925 ERROR nova.compute.manager [req-26522972-c8be-4be5-83d1-f45412718d94 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: fd3ab09d-fc9f-4ee9-b5f5-72540893ecd3] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/fd3ab09d-fc9f-4ee9-b5f5-72540893ecd3/\'\\n\"]\n>>>>>>> 2013-07-24 11:26:00.874 ERROR nova.compute.manager [req-43b99187-3d4b-4f42-8ee5-eab58a448d05 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: b60db5a8-92ea-4a81-bd53-d73dc2019b0b] Instance failed to spawn\n>>>>>>> 2013-07-24 11:27:07.567 ERROR nova.compute.manager [req-43b99187-3d4b-4f42-8ee5-eab58a448d05 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: b60db5a8-92ea-4a81-bd53-d73dc2019b0b] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/b60db5a8-92ea-4a81-bd53-d73dc2019b0b/\'\\n\"]\n>>>>>>> 2013-07-24 11:27:08.045 ERROR nova.openstack.common.rpc.amqp [req-43b99187-3d4b-4f42-8ee5-eab58a448d05 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Exception during message handling\n>>>>>>> 2013-07-24 11:34:02.320 1685 ERROR nova.virt.libvirt.driver [-] [instance: b60db5a8-92ea-4a81-bd53-d73dc2019b0b] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 11:38:23.618 ERROR nova.compute.manager [req-d9052cd7-12d2-4df6-94c2-4ed3891e6bbb c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 69a2c512-bea1-46de-91be-c33a07799981] Instance failed to spawn\n>>>>>>> 2013-07-24 11:38:49.087 1685 ERROR nova.virt.libvirt.driver [-] [instance: 69a2c512-bea1-46de-91be-c33a07799981] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 11:38:49.220 ERROR nova.compute.manager [req-d9052cd7-12d2-4df6-94c2-4ed3891e6bbb c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 69a2c512-bea1-46de-91be-c33a07799981] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1517, in spawn\\n    admin_pass=admin_password)\\n\', \'             File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1748, in _create_image\\n    fileutils.ensure_tree(basepath(suffix=\\\'\\\'))\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/fileutils.py\", line 29, in ensure_tree\\n    os.makedirs(path)\\n\', \'  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\\n    mkdir(name, mode)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/69a2c512-bea1-46de-91be-c33a07799981/\'\\n\"]\n>>>>>>> 2013-07-24 11:41:15.017 1685 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 12:45:36.353 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lib/nova/instances/compute_nodes\'\n>>>>>>> 2013-07-24 13:13:09.224 ERROR nova.virt.libvirt.driver [req-4d081c1f-ad11-4b89-904d-700291b47894 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] Error on \'/var/lib/nova/instances\' while checking direct I/O: \'[Errno 13] Permission denied: \'/var/lib/nova/instances/.directio.test\'\'\n>>>>>>> 2013-07-24 13:13:09.225 ERROR nova.compute.manager [req-4d081c1f-ad11-4b89-904d-700291b47894 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: f105be37-d5d9-4234-ba4e-3897d60e97bb] Instance failed to spawn\n>>>>>>> 2013-07-24 13:13:21.636 1694 ERROR nova.virt.libvirt.driver [-] [instance: f105be37-d5d9-4234-ba4e-3897d60e97bb] During wait destroy, instance disappeared.\n>>>>>>> 2013-07-24 13:13:21.729 ERROR nova.compute.manager [req-4d081c1f-ad11-4b89-904d-700291b47894 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: f105be37-d5d9-4234-ba4e-3897d60e97bb] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1510, in spawn\\n    block_device_info=block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2326, in to_xml\\n    disk_info, rescue, block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2244, in get_guest_config\\n    inst_type):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2051, in get_guest_storage_config\\n    inst_type)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2013, in get_guest_disk_config\\n    self.disk_cachemode,\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 355, in disk_cachemode\\n    if not self._supports_direct_io(CONF.instances_path):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1676, in _supports_direct_io\\n    {\\\'path\\\': dirpath, \\\'ex\\\': str(e)})\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1663, in _supports_direct_io\\n    f = os.open(testfile, os.O_CREAT | os.O_WRONLY | os.O_DIRECT)\\n\', \"OSError: [Errno 13] Permission denied: \'/var/lib/nova/instances/.directio.test\'\\n\"]\n>>>>>>> 2013-07-24 13:25:36.702 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 14:05:37.095 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 14:45:37.319 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 14:47:05.364 ERROR nova.compute.manager [req-4b74d886-c5cc-4e28-ac42-824ba815f7ac c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 748277e2-e3b5-4385-9c0e-c8e0ddefa601] Instance failed to spawn\n>>>>>>> 2013-07-24 14:47:26.986 ERROR nova.compute.manager [req-4b74d886-c5cc-4e28-ac42-824ba815f7ac c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 748277e2-e3b5-4385-9c0e-c8e0ddefa601] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1520, in spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2435, in _create_domain_and_network\\n    domain = self._create_domain(xml, instance=instance)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2396, in _create_domain\\n    domain.createWithFlags(launch_flags)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 187, in doit\\n    result = proxy_call(self._autowrap, f, *args, **kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 147, in proxy_call\\n    rv = execute(f,*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 76, in tworker\\n    rv = meth(*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/libvirt.py\", line 711, in createWithFlags\\n    if ret == -1: raise libvirtError (\\\'virDomainCreateWithFlags() failed\\\', dom=self)\\n\', \"libvirtError: internal error cannot load AppArmor profile \'libvirt-748277e2-e3b5-4385-9c0e-c8e0ddefa601\'\\n\"]\n>>>>>>> 2013-07-24 15:25:37.532 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 16:05:37.847 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 16:14:39.249 ERROR nova.compute.manager [req-e0716278-f864-4f70-962a-bf74559fc4c9 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 23cf38cc-797e-40f2-a995-6e181493c913] Instance failed to spawn\n>>>>>>> 2013-07-24 16:14:54.459 ERROR nova.compute.manager [req-e0716278-f864-4f70-962a-bf74559fc4c9 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 23cf38cc-797e-40f2-a995-6e181493c913] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1520, in spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2435, in _create_domain_and_network\\n    domain = self._create_domain(xml, instance=instance)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2396, in _create_domain\\n    domain.createWithFlags(launch_flags)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 187, in doit\\n    result = proxy_call(self._autowrap, f, *args, **kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 147, in proxy_call\\n    rv = execute(f,*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 76, in tworker\\n    rv = meth(*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/libvirt.py\", line 711, in createWithFlags\\n    if ret == -1: raise libvirtError (\\\'virDomainCreateWithFlags() failed\\\', dom=self)\\n\', \"libvirtError: internal error cannot load AppArmor profile \'libvirt-23cf38cc-797e-40f2-a995-6e181493c913\'\\n\"]\n>>>>>>> 2013-07-24 16:43:47.486 ERROR nova.compute.manager [req-5d9b9575-a6eb-4324-b975-78dba69c24ef c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 00497f97-a0fe-4a51-b7f6-6901d0d34791] Instance failed to spawn\n>>>>>>> 2013-07-24 16:43:58.434 ERROR nova.compute.manager [req-5d9b9575-a6eb-4324-b975-78dba69c24ef c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 00497f97-a0fe-4a51-b7f6-6901d0d34791] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1093, in _spawn\\n    LOG.exception(_(\\\'Instance failed to spawn\\\'), instance=instance)\\n\', \'  File \"/usr/lib/python2.7/contextlib.py\", line 24, in __exit__\\n    self.gen.next()\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1089, in _spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 1520, in spawn\\n    block_device_info)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2435, in _create_domain_and_network\\n    domain = self._create_domain(xml, instance=instance)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2396, in _create_domain\\n    domain.createWithFlags(launch_flags)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 187, in doit\\n    result = proxy_call(self._autowrap, f, *args, **kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 147, in proxy_call\\n    rv = execute(f,*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 76, in tworker\\n    rv = meth(*args,**kwargs)\\n\', \'  File \"/usr/lib/python2.7/dist-packages/libvirt.py\", line 711, in createWithFlags\\n    if ret == -1: raise libvirtError (\\\'virDomainCreateWithFlags() failed\\\', dom=self)\\n\', \"libvirtError: internal error cannot load AppArmor profile \'libvirt-00497f97-a0fe-4a51-b7f6-6901d0d34791\'\\n\"]\n>>>>>>> 2013-07-24 16:46:43.408 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 17:26:43.627 1694 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: [Errno 13] Permission denied: \'/var/lock/nova\'\n>>>>>>> 2013-07-24 17:47:46.003 ERROR nova.compute.manager [req-370ac716-203d-43aa-a146-709297c715b3 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 8a4e0c84-07ec-40ab-9585-5433dff92b64] Instance failed to spawn\n>>>>>>> 2013-07-24 17:47:55.194 ERROR nova.compute.manager [req-370ac716-203d-43aa-a146-709297c715b3 c402785616534f2096b34ce132b7d3f2 d532a4fc2e9e4b5f83b6dec7085237e5] [instance: 8a4e0c84-07ec-40ab-9585-5433dff92b64] Error: [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 834, in _run_instance\\n    set_access_ip=set_access_ip)\\n\', \'  File \"/usr/li','<CAKz5Ux_snz62HDvbjXq3MOCpK9_zXmwf=wH3t0mJ-3ijfbPPuQ@mail.gmail.com>',NULL),('<105E32D8-B109-4306-B5FA-A61B31CD5AAE@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-04 14:48:52',0,'2012-12-04 14:48:52',NULL,'[openstack-dev] [keystone] On multiple project & domain scoping','Hi\n\nSo yes, I am expecting that some services to have to become \"domain aware\".  Here\'s the problem:\n\nIn Folsom and before, the concept of a tenant/organization and the collection of items related to a work being run on openstack were merged together in one container (called tenant).  In Grizzly we are enabling a separation (if required) for this into a Domain (that is a container that can represent the organization being hosted within an openstack implementation) and a set of projects that represent the work being done and will come and go with the lifecycle of the applications/work involved).  Such a distinction is a must for any kind of enterprise.  Further, there will be aspects of the openstack implmentation that a cloud provdier will want to manipualte a the group level - e.g. setting a quota for, as well as assigning some logical part of the infrastructure to, an organization (i.e. domain).  In addition, an organization may want some object to be domain-wide, e.g. some standard images that all their projects can use.  An example desired  entity relationship might look like this:\n\n\nI appreciate that we have not yet agreed the items in red, but it appears logical to me that we will need them.  The question is how would we provide authorization backbone for this?  One option is domain scoping would not apply to children of sub-containers like projects (i.e. getting a token to a domain does NOT authorize you to manipulate the projects).  So projects would not be returned in this case....and a project-scoped token would have to be obtained later to work  on a project.  Clearly some more discussion required here.  In fact, conceptually you might say that some of the project CRUD in Keystone should be done with a domain scoped token...but I know that we don\'t use this model in keystone). \n\nOur challenge is to balance the above model, with the current one where a cloud provider wanting to host individuals or SMEs by not using domains (except one big common domain) and each \"customer\" just gets a project to work in.  Do we want to continue to recommend this as a model - or actually, is the recommended model always to create a domain with minimally one project in it?  While that is conceptually nice, maybe too much overhead.\n\nHenry\nOn 29 Nov 2012, at 13:59, Dolph Mathews wrote:\n\n> Are you expecting other services to accept a token \"scoped to a domain\" as having authorization to perform operations on a specific tenant in that domain?\n> \n> If so, this either forces every service to become aware of keystone domains (and look up their containing tenants), or for keystone to return a potentially massive list of tenants as part of the token (making PKI tokens enormous).\n> \n> If not, it seems like a mechanism to provide in conjunction with role grants across domains, in order to produce/exchange tokens for more narrowly scoped tokens... but as a user, I\'d be confused when the auth_token middleware rejected such a broadly scoped token.\n> \n> \n> -Dolph\n> \n> \n> On Thu, Nov 29, 2012 at 2:21 AM, Henry Nash <henryn at linux.vnet.ibm.com> wrote:\n> Hi\n> \n> One of the requests from the summit was for allowing the scoping of a token to multiple projects, and this is being worked on for Grizzly.  However, I would like us to re-visit (or maybe just re-clarify) this requirement - whilst also considering the option of scoping to a domain (see blueprint at : https://blueprints.launchpad.net/keystone/+spec/domain-scoping).\n> \n> Now the whole point of scoping to anything, is to make it possible (and in some cases easier) to execute operations on the granularity that you have \"scoped to\". It seems to me that now we have a domain as the logical container for users and projects, clearly one of the common usages will be operations that want to look at all the projects (or some aspect of projects) in a domain - hence the idea of scoping to a domain.  This would provide a somewhat simpler, both request & response, than an appropriately scoped token than an arbitrary list of projects (where you end up returning a nested set of projects and their domains in the response, for example).  Further, if we had this, would we really need the ability to scope to multiple projects from different domains (which is technically the request on the table right now)?  Remember, scoping is defining the access rights - just allowing a suitable granularity of scope for upcoming operations - so you only really need a complex scope if the you have some operation that needs to carried out across that complex set of objects.  Are there such a set of operations that people have in mind?\n> \n> I raise this so that we just look at whether there is some simplification to the expansion of ability to scoping, before we go too far.\n> \n> Henry\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/65caab3d/attachment-0002.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OpenStack_Enterprise_Entity_Relationships.pdf\nType: application/pdf\nSize: 68206 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/65caab3d/attachment-0001.pdf>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/65caab3d/attachment-0003.html>\n\n','<CAC=h7gVooFVun9VckTP2wPLfcGW3-nOFFws2f81egcDpqOewYg@mail.gmail.com>',NULL),('<1060173090.28599098.1407784751354.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 15:19:11',-14400,'2014-08-11 19:19:11',NULL,'[openstack-dev] [tc][ceilometer] Some background on\n	the	gnocchi	project','\n\n> Hi Eoghan,\n> \n> Thanks for the note below. However, one thing the overview below does not\n> cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many\n> folks feel that this technology is a viable solution for the problem space\n> discussed below.\n\nGreat question Brad!\n\nAs it happens we\'ve been working closely with Paul Dix (lead\ndeveloper of InfluxDB) to ensure that this metrics store would be\nusable as a backend driver. That conversation actually kicked off\nat the Juno summit in Atlanta, but it really got off the ground\nat our mid-cycle meet-up in Paris on in early July.\n\nI wrote a rough strawman version of an InfluxDB driver in advance\nof the mid-cycle to frame the discussion, and Paul Dix traveled\nto the meet-up so we could have the discussion face-to-face. The\nconclusion was that InfluxDB would indeed potentially be a great\nfit, modulo some requirements that we identified during the detailed\ndiscussions:\n\n * shard-space-based retention & backgrounded deletion\n * capability to merge individual timeseries for cross-aggregation\n * backfill-aware downsampling\n\nThe InfluxDB folks have committed to implementing those features in\nover July and August, and have made concrete progress on that score.\n\nI hope that provides enough detail to answer to your question?\n\nCheers,\nEoghan\n\n> Thanks,\n> \n> Brad\n> \n> \n> Brad Topol, Ph.D.\n> IBM Distinguished Engineer\n> OpenStack\n> (919) 543-0646\n> Internet: btopol at us.ibm.com\n> Assistant: Kendra Witherspoon (919) 254-0680\n> \n> \n> \n> From: Eoghan Glynn <eglynn at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>,\n> Date: 08/06/2014 11:17 AM\n> Subject: [openstack-dev] [tc][ceilometer] Some background on the gnocchi\n> project\n> \n> \n> \n> \n> \n> Folks,\n> \n> It\'s come to our attention that some key individuals are not\n> fully up-to-date on gnocchi activities, so it being a good and\n> healthy thing to ensure we\'re as communicative as possible about\n> our roadmap, I\'ve provided a high-level overview here of our\n> thinking. This is intended as a precursor to further discussion\n> with the TC.\n> \n> Cheers,\n> Eoghan\n> \n> \n> What gnocchi is:\n> ===============\n> \n> Gnocchi is a separate, but related, project spun up on stackforge\n> by Julien Danjou, with the objective of providing efficient\n> storage and retrieval of timeseries-oriented data and resource\n> representations.\n> \n> The goal is to experiment with a potential approach to addressing\n> an architectural misstep made in the very earliest days of\n> ceilometer, specifically the decision to store snapshots of some\n> resource metadata alongside each metric datapoint. The core idea\n> is to move to storing datapoints shorn of metadata, and instead\n> allow the resource-state timeline to be reconstructed more cheaply\n> from much less frequently occurring events (e.g. instance resizes\n> or migrations).\n> \n> \n> What gnocchi isn\'t:\n> ==================\n> \n> Gnocchi is not a large-scale under-the-radar rewrite of a core\n> OpenStack component along the lines of keystone-lite.\n> \n> The change is concentrated on the final data-storage phase of\n> the ceilometer pipeline, so will have little initial impact on the\n> data-acquiring agents, or on transformation phase.\n> \n> We\'ve been totally open at the Atlanta summit and other forums\n> about this approach being a multi-cycle effort.\n> \n> \n> Why we decided to do it this way:\n> ================================\n> \n> The intent behind spinning up a separate project on stackforge\n> was to allow the work progress at arms-length from ceilometer,\n> allowing normalcy to be maintained on the core project and a\n> rapid rate of innovation on gnocchi.\n> \n> Note that that the developers primarily contributing to gnocchi\n> represent a cross-section of the core team, and there\'s a regular\n> feedback loop in the form of a recurring agenda item at the\n> weekly team meeting to avoid the effort becoming silo\'d.\n> \n> \n> But isn\'t re-architecting frowned upon?\n> ======================================\n> \n> Well, the architecture of other OpenStack projects have also\n> under-gone change as the community understanding of the\n> implications of prior design decisions has evolved.\n> \n> Take for example the move towards nova no-db-compute & the\n> unified-object-model in order to address issues in the nova\n> architecture that made progress towards rolling upgrades\n> unneccessarily difficult.\n> \n> The point, in my understanding, is not to avoid doing the\n> course-correction where it\'s deemed necessary. Rather, the\n> principle is more that these corrections happen in an open\n> and planned way.\n> \n> \n> The path forward:\n> ================\n> \n> A subset of the ceilometer community will continue to work on\n> gnocchi in parallel with the ceilometer core over the remainder\n> of the Juno cycle and into the Kilo timeframe. The goal is to\n> have an initial implementation of gnocchi ready for tech preview\n> by the end of Juno, and to have the integration/migration/\n> co-existence questions addressed in Kilo.\n> \n> Moving the ceilometer core to using gnocchi will be contingent\n> on it demonstrating the required performance characteristics and\n> providing the semantics needed to support a v3 ceilometer API\n> that\'s fit-for-purpose.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OFCD1BFF0F.3638B242-ON85257D31.0063DD16-85257D31.00646438@us.ibm.com>',NULL),('<1061118813.66.1383458983613.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:09:43',0,'2013-11-03 06:09:43',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-nova-docs-stable-grizzly #45','See <https://jenkins02.openstack.org/job/periodic-nova-docs-stable-grizzly/45/>\n\n\n\n','<2005507894.49.1383372543563.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1061390302.56.1357520984794.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-07 01:09:44',0,'2013-01-07 01:09:44',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-full #67','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/67/>\n\n\n\n','<1787530053.31.1357436014873.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<106140098.19505815.1417029348602.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 14:15:48',-18000,'2014-11-26 19:15:48',NULL,'[openstack-dev] [All] Proposal to add examples/usecase as part\n of new features / cli / functionality patches','----- Original Message -----\n> From: \"Deepak Shetty\" <dpkshetty at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> \n> Hi stackers,\n>    I was having this thought which i believe applies to all projects of\n> openstack (Hence All in the subject tag)\n> \n> My proposal is to have examples or usecase folder in each project which has\n> info on how to use the feature/enhancement (which was submitted as part of\n> a gerrit patch)\n> In short, a description with screen shots (cli, not GUI) which should be\n> submitted (optionally or mandatory) along with patch (liek how testcases\n> are now enforced)\n> \n> I would like to take an example to explain. Take this patch @\n> https://review.openstack.org/#/c/127587/ which adds a default volume type\n> in Manila\n> \n> Now it would have been good if we could have a .txt or .md file alogn with\n> the patch that explains :\n> \n> 1) What changes are needed in manila.conf to make this work\n> \n> 2) How to use the cli with this change incorporated\n> \n> 3) Some screen shots of actual usage (Now the author/submitted would have\n> tested in devstack before sending patch, so just copying those cli screen\n> shots wouldn\'t be too big of a deal)\n> \n> 4) Any caution/caveats that one has to keep in mind while using this\n> \n> It can be argued that some of the above is satisfied via commit msg and\n> lookign at test cases.\n> But i personally feel that those still doesn\'t give a good visualization of\n> how a feature patch works in reality\n> \n> Adding such a example/usecase file along with patch helps in multiple ways:\n> \n> 1) It helps the reviewer get a good picture of how/which clis are affected\n> and how this patch fits in the flow\n> \n> 2) It helps documentor get a good view of how this patch adds value, hence\n> can document it better\n> \n> 3) It may help the author or anyone else write a good detailed blog post\n> using the examples/usecase as a reference\n> \n> 4) Since this becomes part of the patch and hence git log, if the\n> feature/cli/flow changes in future, we can always refer to how the feature\n> was designed, worked when it was first posted by looking at the example\n> usecase\n> \n> 5) It helps add a lot of clarity to the patch, since we know how the author\n> tested it and someone can point missing flows or issues (which otherwise\n> now has to be visualised)\n> \n> 6) I feel this will help attract more reviewers to the patch, since now its\n> more clear what this patch affects, how it affects and how flows are\n> changing, even a novice reviewer can feel more comfortable and be confident\n> to provide comments.\n> \n> Thoughts ?\n\nI would argue that for the projects that use *-specs repositories this is the type of detail we would like to see in the specifications associated with the feature themselves rather than creating another separate mechanism. For the projects that don\'t use specs repositories (e.g. Manila) maybe this demand is an indication they should be considering them?\n\n-Steve\n\n\n','<CAOXiiM=Abb+MUK+bnWX+Hjf5B2tMzZzqqSeDsYpK9E=+o1MgWw@mail.gmail.com>',NULL),('<1061809184.308.1358985733959.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-24 00:02:13',0,'2013-01-24 00:02:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-folsom #115','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/115/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/>\nCheckout:periodic-swift-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/> - hudson.remoting.Channel at 29dee714:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0.3\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson3029180647464733337.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.YExyupJWqJ\n+ TMPDIR=/tmp/tmp.YExyupJWqJ\n+ trap \'rm -rf /tmp/tmp.YExyupJWqJ\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/115/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python26-stable-folsom-115\', \'SSH_CLIENT\': \'198.101.231.203 50178 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1358004605.676584-1419924838\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric2\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.YExyupJWqJ\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-24_00-01-15\', \'BUILD_NUMBER\': \'115\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'e18fa9e3-ab79-441e-a9cf-4e5faec07381\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric2\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50178 166.78.31.224 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.YExyupJWqJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-folsom/115\n[SCP] Copying console log.\n\n\n','<1903892211.287.1358899360165.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1061903141.798351.1380599219250.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-30 23:46:59',-14400,'2013-10-01 03:46:59',NULL,'[Openstack-docs] Hi all','So, am sure there\'s a good reason, but that seems backwards. That is, wouldn\'t the odd piece out be tagged with the condition? That is, the file is slotted under the config reference so shouldn\'t need to have the condition of belonging to the config reference. Any person updating the file for another bug wouldn\'t automatically think to add a tag, and if one is missed, the API will look mighty strange.\n\nWhy not tag with an API condition? Or just split it out into a separate section and include it that way?\n\ncheers, Summer\n\n----- Original Message -----\nFrom: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>\nTo: openstack-docs at lists.openstack.org\nSent: Tuesday, October 1, 2013 1:19:46 PM\nSubject: [Openstack-docs] Hi all\n\nTom Fifield asked me to make you aware of a change I\'m making: \n\nThere\'s a bug that requested that TempURL and FormPost be added to the Object Storage API v2 Reference. (https://bugs.launchpad.net/openstack-manuals/+bug/1224562) \n\nHowever, this information was already moved to the new Configuration Reference. \n\nThen, Anne Gentle asked that I include the TempURL and FormPost information in both books. \n\nSo, I submitted this change: https://review.openstack.org/#/c/49098 / which conditionalizes content in the doc/config-reference/object-storage/section_object-storage-features.xml file in the Config Reference so that TempURL and FormPost are NOT conditionalized (but everything else IS conditionalized). \n\nThen, I updated the Object Storage API v2 Reference to include this file so that it picks up the TempURL and FormPost information. ( https://review.openstack.org/#/c/47917 /) \n\nThe logic is, when I include a direct reference to this file from the Object Storage API v2 Reference, it won\'t pick up the content that is conditionalized, but it will pick up the non-conditionalized content. \n\nBut in order for the second change (47917) to work, the first change (49098) has to be pushed. \n\nThoughts? Comments? \n\nThanks, \n\nDiane \n---------------------------------------------- \nDiane Fleming \nSoftware Developer II - US \ndiane.fleming at rackspace.com \nCell 512.323.6799 \nOffice 512.874.1260 \nSkype drfleming0227 \nGoogle-plus diane.fleming at gmail.com \n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<CE6FA97F.1B9D5%diane.fleming@rackspace.com>',NULL),('<1061974661.53.1374818549941.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-26 06:02:29',0,'2013-07-26 06:02:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #298','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/298/>\n\n------------------------------------------\n[...truncated 56 lines...]\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/298/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python26-stable-folsom-298\', \'SSH_CLIENT\': \'198.101.231.203 36730 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/bin:/bin:/usr/bin\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python26-stable-folsom\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NLSPATH\': \'/usr/dt/lib/nls/msg/%L/%N.cat\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'centos6 centos6-6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.Gjx2GR0482\', \'DEBEMAIL\': \'hudson at openstack.org\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'BUILD_ID\': \'2013-07-26_06-00-29\', \'BUILD_NUMBER\': \'298\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'04e0bbf8-91fa-4b63-842f-c80e704c8842\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'centos6-6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#298\', \'XFILESEARCHPATH\': \'/usr/dt/app-defaults/%L/Dt\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 36730 166.78.7.162 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-ydZyAH/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-ydZyAH/d2to1-0.2.10/egg-dist-tmp-KOReyB\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-ebYo5l/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-ebYo5l/setuptools-git-1.0/egg-dist-tmp-hN4zro\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-MxHYZm/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-MxHYZm/d2to1-0.2.10/egg-dist-tmp-29jXL0\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-kP2LEc/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-kP2LEc/setuptools-git-1.0/egg-dist-tmp-80UGzI\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-cpsogY/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-cpsogY/d2to1-0.2.10/egg-dist-tmp-KZEWKk\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Gjx2GR0482/easy_install-H7d35V/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Gjx2GR0482/easy_install-H7d35V/setuptools-git-1.0/egg-dist-tmp-yYhZW5\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Gjx2GR0482\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/298\n[SCP] Copying console log.\n\n\n','<1515786181.44.1374732147355.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1062209755.32.1383287579470.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-01 06:32:59',0,'2013-11-01 06:32:59',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #48','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/48/>\n\n------------------------------------------\n[...truncated 21172 lines...]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  184.792\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          121.929\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  83.307\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             40.268\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                39.995\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         37.816\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     36.412\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       34.188\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        33.676\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     33.306\n\n----------------------------------------------------------------------\nRan 1427 tests in 1365.629s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-629898-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-629898.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-629898/48/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1609321292.26.1383114732387.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1062389288.66.1379399274360.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-17 06:27:54',0,'2013-09-17 06:27:54',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all #26','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/26/>\n\n\n\n','<918343110.60.1379226697568.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1063024991.265.1356825858463.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-30 00:04:18',0,'2012-12-30 00:04:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #90','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/90/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.52 secs:\n    2.58    Kc11TestCase.test_admin_requires_adminness\n    2.18    KcEssex3TestCase.test_admin_requires_adminness\n    2.17    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.07    KcEssex3TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 47.933s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.hw5joxweQp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/90\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/90/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1487523272.248.1356739463868.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<10640D54-6B73-474D-9B3C-2BE8F0E6232B@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-13 12:05:16',0,'2013-10-13 12:05:16',NULL,'[openstack-dev] [Hyper-V] Havana status','\n\nOn Oct 13, 2013, at 14:54 , Christopher Yeoh <cbkyeoh at gmail.com>\n wrote:\n\n> On Sat, 12 Oct 2013 09:30:30 -0700\n> Dan Smith <dms at danplanet.com> wrote:\n> \n>>> If the idea is to gate with nova-extra-drivers this could lead to a\n>>> rather painful process to change the virt driver API. When all the\n>>> drivers are in the same tree all of them can be updated at the same\n>>> time as the infrastructure. \n>> \n>> Right, and I think if we split those drivers out, then we do *not*\n>> gate on them for the main tree. It\'s asymmetric, which means\n>> potentially more trouble for the maintainers of the extra drivers.\n>> However, as has been said, we *want* the drivers in the tree as we\n>> have them now. Being moved out would be something the owners of a\n>> driver would choose in order to achieve a faster pace of development,\n>> with the consequence of having to place catch-up if and when we\n>> change the driver API.\n> \n> If that\'s what the owners of the driver want to do then I\'ve no problem\n> with supporting that approach. But I very much think that we should aim\n> to have drivers integrated into the Nova tree as they mature so we can\n> gate on them. Or if not in the tree then at least have a system that\n> supports developing in a way that makes gating on them possible without\n> the downside pains of not being able to change internal APIs easily. \n> \n\nFor what the driver\'s interface stability is concerned, I wouldn\'t see it as a major issue as long as Nova and driver devs coordinate the effort.\nBeside that, having a versioned stable driver interface wouldn\'t be IMHO such a hassle, but as I wrote, this is our very last problem.\n\n\n> Chris.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20131013222418.559f1bc8@rockhopper>',NULL),('<106528797.491287.1418857575930.JavaMail.yahoo@jws10687.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-17 23:06:15',0,'2014-12-17 23:06:15',NULL,'[openstack-dev] [Neutron] fixed ip info shown for port even\n when dhcp is disabled','This means whatever tools the operators are using, it need to make sure the IP address assigned inside the VM matches with Openstack has assigned to the port.Bringing the question that i had in another thread on the same topic:\nIf one wants to use the provider DHCP server and not have Openstack\'s DHCP or L3 agent/DVR, it may not be possible to do so even with DHCP disabled in Openstack network. Even if the provider DHCP server is configured with the same start/end range in the same subnet, there\'s no guarantee that it will match with Openstack assigned IP address for bulk VM launches or? when there\'s a failure case.So, how does one deploy external DHCP with Openstack?\nIf Openstack hasn\'t assigned a IP address when DHCP is disabled for a network, can\'t port_update be done with the provider DHCP specified IP address to put the anti-spoofing and security rules?With Openstack assigned IP address, port_update cannot be done since IP address aren\'t in sync and can overlap.\nThanks,Paddu\n\n\n\nOn 12/16/14 4:30 AM, \"Pasquale Porreca\" <pasquale.porreca at dektech.com.au>\nwrote:\n\n>I understood and I agree that assigning the ip address to the port is\n>not a bug, however showing it to the user, at least in Horizon dashboard\n>where it pops up in the main instance screen without a specific search,\n>can be very confusing.\n>\n>On 12/16/14 12:25, Salvatore Orlando wrote:\n>> In Neutron IP address management and distribution are separated\n>>concepts.\n>> IP addresses are assigned to ports even when DHCP is disabled. That IP\n>> address is indeed used to configure anti-spoofing rules and security\n>>groups.\n>> \n>> It is however understandable that one wonders why an IP address is\n>>assigned\n>> to a port if there is no DHCP server to communicate that address.\n>>Operators\n>> might decide to use different tools to ensure the IP address is then\n>> assigned to the instance\'s ports. On XenServer for instance one could\n>>use a\n>> guest agent reading network configuration from XenStore; as another\n>> example, older versions of Openstack used to inject network\n>>configuration\n>> into the instance file system; I reckon that today\'s configdrive might\n>>also\n>> be used to configure instance\'s networking.\n>> \n>> Summarising I don\'t think this is a bug. Nevertheless if you have any\n>>idea\n>> regarding improvements on the API UX feel free to file a bug report.\n>> \n>> Salvatore\n>> \n>> On 16 December 2014 at 10:41, Pasquale Porreca <\n>> pasquale.porreca at dektech.com.au> wrote:\n>>>\n>>> Is there a specific reason for which a fixed ip is bound to a port on a\n>>> subnet where dhcp is disabled? it is confusing to have this info shown\n>>> when the instance doesn\'t have actually an ip on that port.\n>>> Should I fill a bug report, or is this a wanted behavior?\n>>>\n>>> --\n>>> Pasquale Porreca\n>>>\n>>> DEK Technologies\n>>> Via dei Castelli Romani, 22\n>>> 00040 Pomezia (Roma)\n>>>\n>>> Mobile +39 3394823805\n>>> Skype paskporr\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>\n>-- \n>Pasquale Porreca\n>\n>DEK Technologies\n>Via dei Castelli Romani, 22\n>00040 Pomezia (Roma)\n>\n>Mobile +39 3394823805\n>Skype paskporr\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141217/06a229d0/attachment.html>\n\n','<D0B6F6B7.3FE5B%padkrish@cisco.com>',NULL),('<1065954037.2.1377238662152.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-23 06:17:42',0,'2013-08-23 06:17:42',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #7','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/7/>\n\n\n\n','<1287855348.16.1377065845027.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<106645908.6708055.1394119649870.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 16:27:29',3600,'2014-03-06 15:27:29',NULL,'[openstack-dev] [Neutron][L3] FFE request: L3 HA VRRP','Hi all,\n\nI would like to request a FFE for the following patches of the L3 HA VRRP BP :\n\nhttps://blueprints.launchpad.net/neutron/+spec/l3-high-availability\n\nhttps://review.openstack.org/#/c/64553/\nhttps://review.openstack.org/#/c/66347/\nhttps://review.openstack.org/#/c/68142/\nhttps://review.openstack.org/#/c/70700/\n\nThese should be low risk since HA is not enabled by default.\nThe server side code has been developed as an extension which minimizes risk.\nThe agent side code introduces a bit more changes but only to filter whether to apply the\nnew HA behavior.\n\nI think it\'s a good idea to have this feature in Icehouse, perhaps even marked as experimental,\nespecially considering the demand for HA in real world deployments.\n\nHere is a doc to test it :\n\nhttps://docs.google.com/document/d/1P2OnlKAGMeSZTbGENNAKOse6B2TRXJ8keUMVvtUCUSM/edit#heading=h.xjip6aepu7ug\n\n-Sylvain\n\n\n\n','<867819697.6707433.1394119480474.JavaMail.zimbra@enovance.com>',NULL),('<106733781.85.1383717770367.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-06 06:02:50',0,'2013-11-06 06:02:50',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-horizon-python27-stable-grizzly #46','See <https://jenkins02.openstack.org/job/periodic-horizon-python27-stable-grizzly/46/>\n\n\n\n','<779654195.36.1383372152186.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1067717708.2.1384845561222.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-19 07:19:21',0,'2013-11-19 07:19:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-python26-stable-havana #1','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/1/>\n\n------------------------------------------\n[...truncated 399 lines...]\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nERROR:neutron.plugins.linuxbridge.agent.linuxbridge_neutron_agent:Failed reporting state!\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py\",> line 801, in _report_state\n    self.agent_state)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/agent/rpc.py\",> line 74, in report_state\n    return self.cast(context, msg, topic=self.topic)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/proxy.py\",> line 171, in cast\n    rpc.cast(context, self._get_topic(topic), msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/__init__.py\",> line 158, in cast\n    return _get_impl().cast(CONF, context, topic, msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 166, in cast\n    check_serialize(msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 131, in check_serialize\n    json.dumps(msg)\n  File \"/usr/lib64/python2.6/json/__init__.py\", line 230, in dumps\n    return _default_encoder.encode(obj)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 367, in encode\n    chunks = list(self.iterencode(o))\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 317, in _iterencode\n    for chunk in self._iterencode_default(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 323, in _iterencode_default\n    newobj = self.default(o)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 344, in default\n    raise TypeError(repr(o) + \" is not JSON serializable\")\nTypeError: <MagicMock name=\'LinuxBridgeManager().local_ip\' id=\'236079952\'> is not JSON serializable\nERROR:neutron.plugins.linuxbridge.agent.linuxbridge_neutron_agent:Failed reporting state!\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py\",> line 801, in _report_state\n    self.agent_state)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/agent/rpc.py\",> line 74, in report_state\n    return self.cast(context, msg, topic=self.topic)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/proxy.py\",> line 171, in cast\n    rpc.cast(context, self._get_topic(topic), msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/__init__.py\",> line 158, in cast\n    return _get_impl().cast(CONF, context, topic, msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 166, in cast\n    check_serialize(msg)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 131, in check_serialize\n    json.dumps(msg)\n  File \"/usr/lib64/python2.6/json/__init__.py\", line 230, in dumps\n    return _default_encoder.encode(obj)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 367, in encode\n    chunks = list(self.iterencode(o))\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 317, in _iterencode\n    for chunk in self._iterencode_default(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 323, in _iterencode_default\n    newobj = self.default(o)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 344, in default\n    raise TypeError(repr(o) + \" is not JSON serializable\")\nTypeError: <MagicMock name=\'LinuxBridgeManager().local_ip\' id=\'274632272\'> is not JSON serializable\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.M1dc4iHCb7/tmp5HzH8C\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.M1dc4iHCb7/tmpI56JkV\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.M1dc4iHCb7/tmpa78uPr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.M1dc4iHCb7/tmpC40Be9\nRan 9383 tests in 2228.003s\nPASSED (id=0, skips=328)\nSlowest Tests\nTest id                                                                                                                Runtime (s)\n---------------------------------------------------------------------------------------------------------------------  -----------\nneutron.tests.unit.nicira.test_nvp_sync.NvpSyncTestCase.test_sync_chunk_larger_maxpagesize_triggers_multiple_requests  14.961\nneutron.tests.unit.nicira.test_edge_router.ServiceRouterTestCase.test_floatingip_update_different_router               12.476\nneutron.tests.unit.nicira.test_nicira_plugin.TestNiciraPortsV2.test_recycling                                          11.224\nneutron.tests.unit.nicira.test_edge_router.NvpRouterTestCase.test_floatingip_update_different_router                    9.866\nneutron.tests.unit.nec.test_router.NecRouterOpenFlowTestCase.test_floatingip_update_different_router                    8.974\nneutron.tests.unit.ml2.test_ml2_plugin.TestMl2PortsV2.test_recycling                                                    8.619\nneutron.tests.unit.test_extension_extraroute.ExtraRouteDBIntTestCaseXML.test_floatingip_update_different_router         8.258\nneutron.tests.unit.test_l3_plugin.L3NatDBSepTestCaseXML.test_floatingip_update_different_router                         8.135\nneutron.tests.unit.openvswitch.test_openvswitch_plugin.TestOpenvswitchPortsV2.test_recycling                            8.115\nneutron.tests.unit.test_l3_plugin.L3NatDBIntTestCase.test_floatingip_update_different_router                            8.059\n___________________________________ summary ____________________________________\n  py26: commands succeeded\n  congratulations :)\n+ result=0\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==2.0.10\nalembic==0.6.0\namqp==1.3.3\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\ncliff==1.4.5\ncmd2==0.6.7\nconfigobj==4.7.2\ncoverage==3.7\ndiscover==0.4.0\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonrpclib==0.1.3\nkombu==3.0.5\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nneutron==jenkins.periodic.neutron.python26.stable.havana.1\nordereddict==1.1\noslo.config==1.2.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npyflakes==0.7.3\npyparsing==2.0.1\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-subunit==0.0.15\npytz==2013.8\npyudev==0.16.1\nrepoze.lru==0.6\nrequests==2.0.1\nsetuptools-git==1.0\nsimplejson==3.3.1\nsix==1.4.1\nstevedore==0.12\ntestrepository==0.0.18\ntesttools==0.9.33\nwaitress==0.8.7\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nBuild timed out (after 40 minutes). Marking the build as failed.\n/usr/local/jenkins/slave_scripts/run-unittests.sh: line 58: 29690 Terminated              .tox/$venv/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\n+ gzip -9 ./subunit_log.txt\n++ rm -rf /tmp/tmp.M1dc4iHCb7\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-havana\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-havana/centos6-5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-havana/centos6-5/1\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1067992594.8505130.1346707959298.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-03 17:32:39',-14400,'2012-09-03 21:32:39',NULL,'[openstack-dev] [Documentation] Docbuild error','Brilliant. This solves the problems\nThanks\nGary\n\n----- Original Message -----\nFrom: \"Anne Gentle\" <anne at openstack.org>\nTo: gkotton at redhat.com\nCc: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>, \"David Cramer\" <david.cramer at rackspace.com>\nSent: Monday, September 3, 2012 8:00:04 PM\nSubject: Re: [openstack-dev] [Documentation] Docbuild error\n\nHi again Gary -\nThanks for the paste. I can get BUILD SUCCESSFUL on the\nopenstack-network-admin pom.xml in my local environment, so let\'s see\nwhat\'s different in yours. I\'ve got Maven 3.0.3 and you have 3.0.4 but\nI dont\' think that\'s it.\nHere\'s my settings.xml, probably you have to add the same entries and\ntry again, since it seems like maven\'s not finding the repository.\n\n<settings>\n    <activeProfiles>\n        <activeProfile>Rackspace Cloud Research</activeProfile>\n    </activeProfiles>\n    <profiles>\n        <profile>\n            <id>Rackspace Cloud Research</id>\n            <repositories>\n                <repository>\n                    <id>repos.rackspace.cloud.snapshots</id>\n\n<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>\n                    <releases>\n                        <enabled>true</enabled>\n                    </releases>\n                    <snapshots>\n                        <enabled>true</enabled>\n                    </snapshots>\n                </repository>\n            </repositories>\n            <pluginRepositories>\n                <pluginRepository>\n                    <id>repos.rackspace.cloud.snapshots</id>\n\n<url>http://maven.research.rackspacecloud.com/content/groups/public/</url>\n                    <releases>\n                        <enabled>true</enabled>\n                    </releases>\n                    <snapshots>\n                        <enabled>true</enabled>\n                    </snapshots>\n                </pluginRepository>\n            </pluginRepositories>\n        </profile>\n    </profiles>\n</settings>\n\nLet me know how it goes.\n\nLots of people working on docs this (U.S) three-day weekend. :)\nAnne\n\nOn Mon, Sep 3, 2012 at 11:18 AM, Gary Kotton <gkotton at redhat.com> wrote:\n> On 09/03/2012 06:49 PM, Anne Gentle wrote:\n>>\n>> mvn clean generate-sources\n>\n> Can you please look at http://paste.openstack.org/show/20620/.\n> I ran mvn -X\n>\n> Thanks\n> Gary\n\n\n','<CAD0KtVF7idM_9amk-038C+w8dbkkx-spwFMk9NcRDoipkwn5KQ@mail.gmail.com>',NULL),('<1069117742.39796496.1351445402944.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-28 13:30:02',-14400,'2012-10-28 17:30:02',NULL,'[openstack-dev] [ceilometer] alternative publication conduits','\n> Isn\'t this the same topic as the one on Monday that Annie setup?\n> \n> https://lists.launchpad.net/openstack/msg17802.html\n> \n> Lets not redo the same logic in two places.\n\nI\'m not sure this is exactly the same thing. I was proposing an\nextension to the ceilometer infrastructure to make it possible to\nto publish the output of ceilo listeners/pollsters via different\nconduits (other than via the message bus to the ceilo collector).\n\nThe idea would be to re-use the information already harvested by\nceilo, where these data are of interest to multiple sinks.\n\nSo for example, I just proposed a patch to the ceilo libvirt\npollster to estimate the guest CPU utilization %. The idea would\nbe to share this same measurement with both the metering and \nmetrics pipelines, instead of repeating it, seeing as it\'s of\ninterest to both.\n\nWhereas IIUC the Monday meeting is more concerned with the source\nside, i.e producing more fine-grained instrumention/timings/\ntelemetry of a form that we don\'t currently produce in ceilo.\n\nCheers,\nEoghan\n\n\n','<20121027003039.GB10184@redhat.com>',NULL),('<1069302857.141.1364278161940.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-26 06:09:21',0,'2013-03-26 06:09:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #176','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/176/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric7 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/>\nCheckout:periodic-horizon-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/> - hudson.remoting.Channel at 20cb3eea:oneiric7\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.2\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson2561309376852432286.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.ODPHhemdq4\n+ TMPDIR=/tmp/tmp.ODPHhemdq4\n+ trap \'rm -rf /tmp/tmp.ODPHhemdq4\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy26 runtests: commands[0]\nRunning Horizon application tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py>:1235: DeprecationWarning: The syntax for the url template tag is changing. Load the `url` tag from the `future` tag library to start using the new behavior.\n  category=DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/contrib/auth/__init__.py>:26: DeprecationWarning: Authentication backends without a `supports_inactive_user` attribute are deprecated. Please define it in <class \'openstack_auth.backend.KeystoneBackend\'>.\n  DeprecationWarning)\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.58 secs:\n    0.60    UserSettingsTest.test_timezone_offset_is_displayed\n    0.58    ImagesViewTest.test_images_list_get_pagination\n    0.56    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.43    ImagesAndSnapshotsTests.test_index\n    0.41    ImagesAndSnapshotsTests.test_index_error\n----------------------------------------------------------------------\nRan 347 tests in 21.128s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==1.1.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ODPHhemdq4\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/176\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/176/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/176/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<871802610.126.1364191569450.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<106FCB0F-B044-439F-9ABF-282A0B3C85F5@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2014-04-03 11:17:46',-14400,'2014-04-03 15:17:46',NULL,'[openstack-hpc]  Atlanta Summit Unconference session','OK, I\'ve created an Etherpad here so we can collect our thoughts for a session:\nhttps://etherpad.openstack.org/p/juno-hpc-unconference\n\nWhen we get a little content filled in, we can propose an unconference session here:\nhttp://summit.openstack.org\n\nLooks like the deadline is April 10.\n\nBrian\n\n-------------------------------------------------\nBrian Schott, CTO\nNimbis Services, Inc.\nbrian.schott at nimbisservices.com\nph: 443-274-6064  fx: 443-274-6060\n\n\n\nOn Apr 3, 2014, at 10:12 AM, John-Paul Robinson <jpr at uab.edu> wrote:\n\n> Certainly interested in participating.\n> \n> We\'ve been incorporating OpenStack into our HPC environment and would\n> love to learn and share.\n> \n> ~jpr\n> \n> On 04/02/2014 09:10 PM, Daniel Westervelt wrote:\n>> A lot of interest in Openstack-HPC here at Canonical. We would be willing to help pull together something if there is interest.\n>> \n>> - Daniel\n>> \n>> ---\n>> Director, Solutions and Product Engineering\n>> Canonical|Ubuntu\n>> \n>> Sent from my iPhone\n>> \n>>> On Apr 2, 2014, at 8:58 PM, Kitrick Sheets <kbs at cray.com> wrote:\n>>> \n>>> Sounds like a good idea. Perhaps we could reserve one of the session rooms for an evening meetup or reserve an unconference slot.\n>>> \n>>> Kitrick\n>>> ________________________________________\n>>> From: McMillan, Scott A [scott.a.mcmillan at intel.com]\n>>> Sent: Wednesday, April 02, 2014 6:15 PM\n>>> To: Brian Schott\n>>> Cc: openstack-hpc at lists.openstack.org\n>>> Subject: Re: [openstack-hpc] Atlanta Summit\n>>> \n>>>> On 4/2/14, 4:56 PM, \"Brian Schott\" <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>> wrote:\n>>>> That would be a great idea.  Is it still possible to submit official ones?\n>>> Since the program has been announced (http://openstacksummitmay2014atlanta.sched.org/), I assume not?\n>>> \n>>> But if there is interest, we could organize a meetup around a particular booth or session?\n>>> \n>>> Scott\n>>> \n>>> _______________________________________________\n>>> OpenStack-HPC mailing list\n>>> OpenStack-HPC at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n>>> \n>>> _______________________________________________\n>>> OpenStack-HPC mailing list\n>>> OpenStack-HPC at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n>> _______________________________________________\n>> OpenStack-HPC mailing list\n>> OpenStack-HPC at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n> \n> \n> _______________________________________________\n> OpenStack-HPC mailing list\n> OpenStack-HPC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 3662 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20140403/01b1cf1f/attachment.bin>\n\n','<533D6C43.7080703@uab.edu>',NULL),('<1070122017.36772068.1402948763554.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 15:59:23',-14400,'2014-06-16 19:59:23',NULL,'[openstack-dev] [NFV] Specific example NFV use case for a\n	data	plane app','----- Original Message -----\n> From: \"Calum Loudon\" <Calum.Loudon at metaswitch.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> \n> Hello all\n> \n> At Wednesday\'s meeting I promised to supply specific examples to help\n> illustrate the NFV use cases and also show how they map to some of the\n> blueprints.  Here\'s my first example - info on our session border\n> controller, which is a data plane app.  Please let me know if this is\n> the sort of example and detail the group are looking for, then I can\n> add it into the wiki and send out info on the second, a vIMS core.\n>\n> Use case example\n> ----------------\n> \n> Perimeta Session Border Controller, Metaswitch Networks.  Sits on the\n> edge of a service provider\'s network and polices SIP and RTP (i.e. VoIP)\n> control and media traffic passing over the access network between\n> end-users and the core network or the trunk network between the core and\n> another SP.\n> \n> Characteristics relevant to NFV/OpenStack\n> -----------------------------------------\n> \n> Fast & guaranteed performance:\n> -	fast = performance of order of several million VoIP packets (~64-220\n> bytes depending on codec) per second per core (achievable on COTS hardware)\n> -	guaranteed via SLAs.\n> \n> Fully HA, with no SPOFs and service continuity over software and hardware\n> failures.\n> \n> Elastically scalable by adding/removing instances under the control of the\n> NFV orchestrator.\n> \n> Ideally, ability to separate traffic from different customers via VLANs.\n> \n> Requirements and mapping to blueprints\n> --------------------------------------\n> \n> Fast & guaranteed performance - implications for network:\n> \n> -	the packets per second target -> either SR-IOV or an accelerated\n> 	DPDK-like data plane\n> 	-	maps to the SR-IOV and accelerated vSwitch blueprints:\n> 		-	\"SR-IOV Networking Support\"\n> 		(https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)\n> 		-	\"Open vSwitch to use patch ports\"\n> 		(https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)\n> 		-	\"userspace vhost in ovd vif bindings\"\n> 		(https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)\n> 		-	\"Snabb NFV driver\"\n> 		(https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)\n> 		-	\"VIF_SNABB\" (https://blueprints.launchpad.net/nova/+spec/vif-snabb)\n> \n> Fast & guaranteed performance - implications for compute:\n> \n> -	to optimize data rate we need to keep all working data in L3 cache\n> 	-> need to be able to pin cores\n> 	-	\"Virt driver pinning guest vCPUs to host pCPUs\"\n> 	(https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)\n> \n> -	similarly to optimize data rate need to bind to NIC on host CPU\'s bus\n> 	-	\"I/O (PCIe) Based NUMA Scheduling\"\n> 	(https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)\n> \n> -	to offer guaranteed performance as opposed to \'best efforts\' we need\n> 	to control placement of cores, minimise TLB misses and get accurate\n> 	info about core topology (threads vs. hyperthreads etc.); maps to the\n> 	remaining blueprints on NUMA & vCPU topology:\n> 	-	\"Virt driver guest vCPU topology configuration\"\n> 	(https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)\n> 	-	\"Virt driver guest NUMA node placement & topology\"\n> 	(https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)\n> 	-	\"Virt driver large page allocation for guest RAM\"\n> 	(https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)\n> \n> -	may need support to prevent \'noisy neighbours\' stealing L3 cache -\n> 	unproven, and no blueprint we\'re aware of.\n> \n> HA:\n> -	requires anti-affinity rules to prevent active/passive being\n> 	instantiated on same host - already supported, so no gap.\n> \n> Elastic scaling:\n> -	similarly readily achievable using existing features - no gap.\n> \n> VLAN trunking:\n> -	maps straightforwardly to \"VLAN trunking networks for NFV\"\n> (https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).\n> \n> Other:\n> -	being able to offer apparent traffic separation (e.g. service\n> 	traffic vs. application management) over single network is also\n> 	useful in some cases\n> 	-	\"Support two interfaces from one VM attached to the same network\"\n> 	(https://blueprints.launchpad.net/nova/+spec/2-if-1-net)\n> \n> regards\n> \n> Calum\n\nHi Calum,\n\nThanks for contributing this, I think as a concrete example it\'s very helpful and I like the breakdown. I\'ve taken the liberty of adding it to the Wiki for further editing/discussion (it appears Chris has not split the pages as yet so for now on the meetings page):\n\n    https://wiki.openstack.org/wiki/Teams/NFV#Session_Border_Controller\n\nThe content itself seems fine, I think however for brevity - particularly as we add more - we need to come up with a way to condense the amount of space taken up by the requirements list. I notice for the ETSI use cases a column was added to the blueprints table to track how they aligned, I am wondering if the same column should be reused/abused for the user contributed use cases such as the one you provided or we should add another column? \n\nThanks,\n\nSteve\n\n\n','<C227399E0701F545B768C425CD0EC3E0B7045844@ENFIRHMBX1.datcon.co.uk>',NULL),('<1070487309.267.1365055924905.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-04 06:12:04',0,'2013-04-04 06:12:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #185','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/185/>\n\n\n\n','<754381318.250.1364969142407.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1070545338.10004642.1369288378460.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-23 01:52:58',-14400,'2013-05-23 05:52:58',NULL,'[openstack-qa] Tempest core cleanup motions - motion 3\n	-	remove	dwalleck','Nowadays,\n I am thinking a lot about ideas what I heard from many people including you.\nI am trying to compose something like a plan which can contain most idea and \n seams good in most view point.\nI am trying to anticipate the far future possible scope as well.\nProbably lot of idea lost somewhere on the IRC or in a review comment.\nVery easy to mishear or miss understood just few words.\n\nI will ask a general question about design and architecture of tempest,\n to start a brain storming.\n\nOnly one man cannot see everything, I will need lot of input from everyone.\nThe plan should be documented and reviewed multiple times.\n\nI would be very happy if I could get input from you as well.\n\n----- Original Message -----\n> From: \"Daryl Walleck\" <daryl.walleck at RACKSPACE.COM>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Tuesday, May 21, 2013 6:18:06 PM\n> Subject: Re: [openstack-qa] Tempest core cleanup motions - motion 3 -	remove	dwalleck\n> \n> I meant to respond to the initial thread but my intentions got lost in the\n> daily shuffle. I completely agree with the sentiment raised here and want to\n> make sure Tempest has dedicated contributors whose attention is focused on\n> it. I\'m certainly not going anywhere and hopefully should be increasing the\n> time I spend active in the OpenStack testing community, but I think the\n> people most focused on Tempest development should be the ones deciding on\n> code reviews.\n> \n> Daryl\n> ________________________________________\n> From: Sean Dague [sean at dague.net]\n> Sent: Tuesday, May 21, 2013 10:58 AM\n> To: openstack-qa at lists.openstack.org\n> Subject: Re: [openstack-qa] Tempest core cleanup motions - motion 3 - remove\n> dwalleck\n> \n> Remembering that openstack-qa-core isn\'t an honor society, but is a\n> working group of people that are actively engaged in the tempest code\n> base, providing feedback to new contributors, and helping shepherd\n> important features into Tempest. Removal doesn\'t mean judgement on the\n> person, it just means that right now these are not active in driving\n> this project through actively reviewing code.\n> \n> Remove the following folks from openstack-qa-core (the voting group for\n> tempest): dwalleck\n> \n> dwalleck\'s only done 7 reviews in the last 90 days, which is less than\n> 10 non core members for the project (it is also < 1 review / 2 weeks).\n> His focus is clearly elsewhere. Him not being core doesn\'t mean we don\'t\n> listen or engage with him, but Tempest and reviewing code in Tempest\n> isn\'t his primary focus right now.\n> \n> There was previously an objection from Attila in the last round, which\n> is why this is separated out.\n> \n> On 05/21/2013 11:37 AM, Sean Dague wrote:\n> > Ok, so the last thread died out a bit, but I still feel we need to move\n> > forward. I\'m going to break these into 3 separate motions (all will be\n> > responses to this email, so the thread should be easy to follow).\n> >\n> > Voting rules: if you are currently tempest core, please vote +1, 0\n> > (abstain), -1 for any of these. If you aren\'t tempest core, please refrain.\n> >\n> > We\'re going to call quorum 3 +1s (which is 1/2 of the currently active\n> > tempest core folks) and 0 -1s. Any current tempest core out of the 12\n> > (not just the active) that -1s a motion blocks it. Also, I realize that\n> > from IBM we\'re 3 of the active cores, and as extra protection against\n> > anyone feeling that one org is too dominant, I\'m not going to count it\n> > if the only +1s are from IBM, even though that would meet quorum.\n> >\n> > I also reran the 90 day review numbers this morning for reviews in\n> > tempest this morning, they change a little because some chunk of the\n> > prior reviews were apparently about 85 days old previously.\n> >\n> > ** -- tempest-core team member\n> > +----------------------+-----------------------------------+\n> > |       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |\n> > +----------------------+-----------------------------------+\n> > |      sdague **       |      173 (9|48|1|115) (67.1%)     |\n> > |      cyeoh-0 **      |      150 (0|48|7|95) (68.0%)      |\n> > |     afazekas **      |      146 (1|21|26|98) (84.9%)     |\n> > |    david-kranz **    |       90 (0|13|3|74) (85.6%)      |\n> > |     treinish **      |       64 (1|24|0|39) (60.9%)      |\n> > |       ivan-zhu       |       37 (0|8|29|0) (78.4%)       |\n> > |       gfidente       |       35 (0|4|31|0) (88.6%)       |\n> > |     jaypipes **      |       34 (0|5|2|27) (85.3%)       |\n> > |      donald-ngo      |       18 (0|5|13|0) (72.2%)       |\n> > |         jogo         |       17 (0|3|14|0) (82.4%)       |\n> > | ravikumar-venkatesan |       17 (0|1|16|0) (94.1%)       |\n> > |   andrea-frittoli    |       16 (0|1|15|0) (93.8%)       |\n> > |       psedlak        |       13 (0|3|10|0) (76.9%)       |\n> > |       adalbas        |       13 (0|1|12|0) (92.3%)       |\n> > |        lauria        |       11 (0|0|11|0) (100.0%)      |\n> > |       prekarat       |        10 (0|4|6|0) (60.0%)       |\n> > |     dwalleck **      |        7 (0|1|4|2) (85.7%)        |\n> > |        igawa         |        7 (0|0|7|0) (100.0%)       |\n> > |        fungi         |        5 (0|0|5|0) (100.0%)       |\n> > |    jerome-gallard    |        4 (0|0|4|0) (100.0%)       |\n> > |       dachary        |        3 (0|2|1|0) (33.3%)        |\n> > |     rohitkarajgi     |        3 (0|1|2|0) (66.7%)        |\n> > |         maru         |        3 (0|1|2|0) (66.7%)        |\n> > |       mkollaro       |        3 (0|0|3|0) (100.0%)       |\n> > |       maurosr        |        3 (0|0|3|0) (100.0%)       |\n> > |        ayoung        |        2 (0|1|1|0) (50.0%)        |\n> > |       unknown        |        2 (0|0|2|0) (100.0%)       |\n> > |     johngarbutt      |         1 (0|1|0|0) (0.0%)        |\n> > |       cboylan        |         1 (0|1|0|0) (0.0%)        |\n> > |  armando-migliaccio  |         1 (0|1|0|0) (0.0%)        |\n> > |        akuno         |         1 (0|1|0|0) (0.0%)        |\n> > |        ymzk37        |        1 (0|0|1|0) (100.0%)       |\n> > |       mpavlase       |        1 (0|0|1|0) (100.0%)       |\n> > |       dperaza        |        1 (0|0|1|0) (100.0%)       |\n> > |       bob-ball       |        1 (0|0|1|0) (100.0%)       |\n> > |        aloga         |        1 (0|0|1|0) (100.0%)       |\n> > +----------------------+-----------------------------------+\n> >\n> > Previous posting here -\n> > http://lists.openstack.org/pipermail/openstack-qa/2013-May/000340.html\n> >\n> >      -Sean\n> >\n> >\n> \n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C694E94F3@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1070784000.27.1374473149899.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-22 06:05:49',0,'2013-07-22 06:05:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #294','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/294/>\n\n------------------------------------------\n[...truncated 2634 lines...]\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.126.gf702c25 to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.126.gf702c25\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.126.gf702c25\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.8.g2f84a4e to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/rabbitmq/rabbit at devstack-1374472837-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/rabbitmq/rabbit at devstack-1374472837.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/294/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<73726441.17.1374386636373.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1071117268.14348591.1401184740013.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-27 05:59:00',-14400,'2014-05-27 09:59:00',NULL,'[Openstack] openstack - Ceilometer error - [root@compute1\n ceilometer]# ceilometer meter-list Error communicating with\n http://controller:8777 [Errno 111] Connection refused','\n> OperationalError: (OperationalError) unable to open database file None None\n\nYour config file implies mongodb usage for the metering store:\n\n  [database]\n  connection = mongodb://ceilometer:ceilometer at controller:27017/ceilometer\n\nIs mongo installed and running the expected host & port? (controller:27017)\n\n----- Original Message -----\n> Hi\n> \n> please find the log file for ceilometer api\n> \n> [root at controller ceilometer]# tailf /var/log/ceilometer/api.log\n> 2014-05-27 15:16:30.236 4914 WARNING keystoneclient.middleware.auth_token\n> [-] Configuring auth_uri to point to the public identity endpoint is\n> required; clients may not be able to authenticate against an admin endpoint\n> 2014-05-27 15:16:30.237 4914 INFO keystoneclient.middleware.auth_token [-]\n> Using /tmp/keystone-signing-FvjNMu as cache directory for signing\n> certificate\n> 2014-05-27 15:16:30.654 4914 CRITICAL ceilometer [-] OperationalError:\n> (OperationalError) unable to open database file None None\n> \n> 2014-05-27 15:19:08.520 4950 INFO keystoneclient.middleware.auth_token [-]\n> Starting keystone auth_token middleware\n> 2014-05-27 15:19:08.521 4950 WARNING keystoneclient.middleware.auth_token\n> [-] Configuring admin URI using auth fragments. This is deprecated, use\n> \'identity_uri\' instead.\n> 2014-05-27 15:19:08.521 4950 WARNING keystoneclient.middleware.auth_token\n> [-] Configuring auth_uri to point to the public identity endpoint is\n> required; clients may not be able to authenticate against an admin endpoint\n> 2014-05-27 15:19:08.523 4950 INFO keystoneclient.middleware.auth_token [-]\n> Using /tmp/keystone-signing-14uzsO as cache directory for signing\n> certificate\n> 2014-05-27 15:19:08.913 4950 CRITICAL ceilometer [-] OperationalError:\n> (OperationalError) unable to open database file None None\n> \n> please find the log file for ceilometer central.\n> \n> 2014-05-27 15:19:59.182 4969 ERROR ceilometer.openstack.common.threadgroup\n> [-] coercing to Unicode: need string or buffer, NoneType found\n> 2014-05-27 15:19:59.182 4969 TRACE ceilometer.openstack.common.threadgroup\n> Traceback (most recent call last):\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/ceilometer/openstack/common/threadgroup.py\",\n> line 125, in wait\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     x.wait()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/ceilometer/openstack/common/threadgroup.py\",\n> line 47, in wait\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     return self.thread.wait()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line 168, in\n> wait\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     return self._exit_event.wait()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/eventlet/event.py\", line 116, in wait\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     return hubs.get_hub().switch()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py\", line 187, in switch\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     return self.greenlet.switch()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line 194, in\n> main\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     result = function(*args,\n> **kwargs)\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/ceilometer/openstack/common/service.py\",\n> line 486, in run_service\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     service.start()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/ceilometer/agent.py\", line 137, in start\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     self.pipeline_manager =\n> pipeline.setup_pipeline()\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup   File\n> \"/usr/lib/python2.6/site-packages/ceilometer/pipeline.py\", line 524, in\n> setup_pipeline\n> 2014-05-27 15:19:59.182 4969 TRACE\n> ceilometer.openstack.common.threadgroup     with open(cfg_file) as fap:\n> 2014-05-27 15:19:59.182 4969 TRACE ceilometer.openstack.common.threadgroup\n> TypeError: coercing to Unicode: need string or buffer, NoneType found\n> 2014-05-27 15:19:59.182 4969 TRACE ceilometer.openstack.common.threadgroup\n> (END)\n> \n> \n> Regards,\n> Dhanesh\n> \n> \n> On Tue, May 27, 2014 at 2:49 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> \n> >\n> > Set debug=True and verbose=True in your ceilometer.conf.\n> >\n> > Restart the ceilometer API service.\n> >\n> > Check /var/log/ceilometer/api.log for errors.\n> >\n> > Similarly for the central agent.\n> >\n> > ----- Original Message -----\n> > > Hi All,\n> > >\n> > >\n> > > 8777 port is not up i started all the service.\n> > >\n> > > I have followed the icehouse document for fedora.\n> > >\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-api restart\n> > > Stopping openstack-ceilometer-api:                         [FAILED]\n> > > Starting openstack-ceilometer-api:                         [  OK  ]\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-api restart\n> > > Stopping openstack-ceilometer-api:                         [  OK  ]\n> > > Starting openstack-ceilometer-api:                         [  OK  ]\n> > > [root at controller ~]# netstat -atlpn | grep 8777\n> > >\n> > > note: not showing the 8777 port\n> > >\n> > > ceilometer service  status\n> > >\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-api status\n> > > openstack-ceilometer-api dead but pid file exists\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-central status\n> > > openstack-ceilometer-central dead but pid file exists\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-collector status\n> > > openstack-ceilometer-collector (pid  8905) is running...\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-notification\n> > status\n> > > openstack-ceilometer-agent-notification (pid  10307) is running...\n> > >\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-alarm-notifier\n> > status\n> > > openstack-ceilometer-alarm-notifier (pid  8947) is running...\n> > >\n> > > [root at controller ~]# /etc/init.d/openstack-ceilometer-alarm-evaluator\n> > status\n> > > openstack-ceilometer-alarm-evaluator (pid  8926) is running...\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > Attaching the ceilometer.conf file along with this mail. Please fing the\n> > > attachment.\n> > >\n> > >\n> > >\n> > > Verify the Telemetry installation\n> > >\n> > > To test the Telemetry installation, download an image from the Image\n> > > Service, and use the *ceilometer* command to display usage statistics.\n> > >\n> > >    1.\n> > >\n> > >    Use the ceilometer meter-list command to test the access to Telemetry:\n> > >\n> > >    $ ceilometer meter-list\n> > >\n> > >\n> > >\n> > > Error:\n> > >\n> > >  ceilometer meter-list\n> > > Error communicating with http://controller:8777 [Errno 111] Connection\n> > > refused\n> > >\n> > >\n> > > Regards,\n> > > Dhanesh.\n> > >\n> > >\n> > > On Tue, May 20, 2014 at 3:04 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> > >\n> > > >\n> > > > What\'s your configured database connection?\n> > > >\n> > > > (in /etc/ceilometer/ceilometer.conf)\n> > > >\n> > > > If its a sqlalchemy-based URL (e.g. mysql or postgres) have you run\n> > > > ceilometer-dbsync?\n> > > >\n> > > > (either directly, or a side-effect of the installation process)\n> > > >\n> > > >\n> > > > ----- Original Message -----\n> > > > > Hi All,\n> > > > >\n> > > > > ps -fe | grep ceilometer-api\n> > > > >\n> > > > > No process is running.\n> > > > >\n> > > > > status is showing its dead.\n> > > > >\n> > > > >\n> > > > > Api Error log.\n> > > > >\n> > > > > [root at controller ceilometer]# tailf api.log\n> > > > > 2014-05-20 14:42:39.476 10768 WARNING\n> > > > keystoneclient.middleware.auth_token\n> > > > > [-] Configuring auth_uri to point to the public identity endpoint is\n> > > > > required; clients may not be able to authenticate against an admin\n> > > > endpoint\n> > > > > 2014-05-20 14:42:39.477 10768 INFO\n> > keystoneclient.middleware.auth_token\n> > > > [-]\n> > > > > Using /tmp/keystone-signing-w05DPS as cache directory for signing\n> > > > > certificate\n> > > > > 2014-05-20 14:42:39.877 10768 CRITICAL ceilometer [-]\n> > OperationalError:\n> > > > > (OperationalError) unable to open database file None None\n> > > > >\n> > > > > 2014-05-20 14:49:47.686 12502 INFO\n> > keystoneclient.middleware.auth_token\n> > > > [-]\n> > > > > Starting keystone auth_token middleware\n> > > > > 2014-05-20 14:49:47.687 12502 WARNING\n> > > > keystoneclient.middleware.auth_token\n> > > > > [-] Configuring admin URI using auth fragments. This is deprecated,\n> > use\n> > > > > \'identity_uri\' instead.\n> > > > > 2014-05-20 14:49:47.687 12502 WARNING\n> > > > keystoneclient.middleware.auth_token\n> > > > > [-] Configuring auth_uri to point to the public identity endpoint is\n> > > > > required; clients may not be able to authenticate against an admin\n> > > > endpoint\n> > > > >\n> > > > > 2014-05-20 14:49:47.688 12502 INFO\n> > keystoneclient.middleware.auth_token\n> > > > [-]\n> > > > > Using /tmp/keystone-signing-zXbRzr as cache directory for signing\n> > > > > certificate\n> > > > > 2014-05-20 14:49:48.080 12502 CRITICAL ceilometer [-]\n> > OperationalError:\n> > > > > (OperationalError) unable to open database file None None\n> > > > >\n> > > > >\n> > > > >\n> > > > > Regards,\n> > > > > Dhanesh.\n> > > > >\n> > > > >\n> > > > >\n> > > > >\n> > > > > On Tue, May 20, 2014 at 1:29 PM, Eoghan Glynn <eglynn at redhat.com>\n> > wrote:\n> > > > >\n> > > > > >\n> > > > > >\n> > > > > > > Hi All,\n> > > > > > >\n> > > > > > > Please find the error iam getting after finishing the ceilometer\n> > > > > > > configuration in controller and compute.\n> > > > > > >\n> > > > > > > Error:\n> > > > > > >\n> > > > > > > [root at compute1 ceilometer]# ceilometer meter-list\n> > > > > > > Error communicating with http://controller:8777 [Errno 111]\n> > > > Connection\n> > > > > > > refused\n> > > > > > >\n> > > > > > > I have started all the services. I noticed 8777 port is not\n> > > > listening.\n> > > > > > >\n> > > > > > > Please gimme some advice.\n> > > > > >\n> > > > > > Check if the ceilometer-api service is actually running on the\n> > expected\n> > > > > > node.\n> > > > > >\n> > > > > > e.g. on Fedora and derivatives with RPMs installed:\n> > > > > >\n> > > > > >   $ sudo service openstack-ceilometer-api status\n> > > > > >\n> > > > > > elsewhere:\n> > > > > >\n> > > > > >   $ ps -fe | grep ceilometer-api\n> > > > > >\n> > > > > > Also check your firewall rules to ensure that the ceilometer-api\n> > > > endpoint\n> > > > > > (i.e. port 8777) is accessible from the host on which you run the\n> > > > client.\n> > > > > >\n> > > > > > Cheers,\n> > > > > > Eoghan\n> > > > > >\n> > > > > > > I have finished almost all except ceilometer.\n> > > > > > >\n> > > > > > > Attaching the output of #ceilometer --debug meter-list\n> > > > > > >\n> > > > > > > Regards,\n> > > > > > > Dhanesh\n> > > > > >\n> > > > > >\n> > > > >\n> > > >\n> > >\n> >\n> \n\n\n','<CAA0wu4eT=gJ0ho=2C3-5Z7=HSjWWKOe50==uV-28YjnU7XBj9A@mail.gmail.com>',NULL),('<1071449610.24.1385619752936.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-28 06:22:32',0,'2013-11-28 06:22:32',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-havana #6','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-havana/6/changes>\n\n\n\n',NULL,NULL),('<1071609606.69.1375773369415.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-06 07:16:09',0,'2013-08-06 07:16:09',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stress #32','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/32/>\n\n\n\n','<285808663.55.1375682600815.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1072342511.23316657.1370970165983.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 13:02:45',-14400,'2013-06-11 17:02:45',NULL,'[openstack-qa] Data encapsulation within Tempest','\n\n\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-qa at lists.openstack.org\n> Sent: Tuesday, June 11, 2013 6:13:37 PM\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> On 06/11/2013 11:52 AM, Attila Fazekas wrote:\n> >> From: \"Matthew Treinish\" <mtreinish at kortar.org>\n> >> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> >> Sent: Monday, June 10, 2013 4:15:15 PM\n> >> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> >>\n> >> On Mon, Jun 10, 2013 at 09:18:32AM -0400, Tal Kammer wrote:\n> >>> I fail to see how is it close to that model today.\n> >>>\n> >>> We have a lot of duplicate code in pretty much every implementation of\n> >>> XML\n> >>> vs JSON..\n> >>\n> >> So are you suggesting we have a uniform client and just have a\n> >> serializer/deserializer option for XML or JSON. That would actually end up\n> >> not\n> >> saving that much code. The issue is that XML behavior is different enough\n> >> from\n> >> JSON (at least in nova) that we basically have to handle everything\n> >> separately.\n> >> So there isn\'t actually that much to combine. It would just be the\n> >> actually\n> >> request call which is only a few lines per request. (To format the url and\n> >> then\n> >> to make the rest_client call) I feel that keeping them separate makes more\n> >> sense\n> >> because of all the differences it would get more complicated to handle\n> >> everything\n> >> in one class. We looked at this when we initially did the XML work, but it\n> >> ended\n> >> up being more confusing because of how XML is used in the projects.\n> >>\n> >\n> > May be the xml_to_data/xml_to_json  not smart enough.\n> > I suspect a smarter way can exist.\n> >\n> > Not just the serialization could be more generic.\n> > https://github.com/openstack/tempest/commit/d42992849f95ac9a01fc73d2d6216585b6f7d174#L1R312\n> > The above just a small clean up.\n> >\n> > Much more can be done.\n> > May be all of the nova API calls can fit into 1-2 normal sized python file.\n> \n> No one is arguing there aren\'t clean ups here that could be done.\n> However Matt and I spent a lot of time in the Nova API on the Nova side.\n> The XML is not just a direct mapping from JSON. Which is why the XML API\n> was completely broken at Folsom-3 milestone, and why the XML code grew\n> the way it did in Tempest, because the thing that everyone imagines it\n> should be, it isn\'t.\n> \n> We can do better, and incremental improvements are good. But blanket\n> statements assuming that you can factor it all out, without having\n> looked at the details, don\'t really help us more forward. :)\n> \n> So cleanup patches encouraged. Refactoring for cleanliness encouraged.\n> I\'ll happily review any of that.\n\nMay be we need xml->json function instead of a json->xml.\nMay be we need a common model, which automatically transferable to xml and json or to anything else.\n\nI hope Tal can find the real solution.\n \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B74CB1.7000409@dague.net>',NULL),('<1072561485.7879776.1382030141070.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-17 13:15:41',-14400,'2013-10-17 17:15:41',NULL,'[Openstack-docs] Suggestion: Improved styling for \"Replaceable\"\n in	install guide','----- Original Message -----\n> From: \"Solly Ross\" <sross at redhat.com>\n> To: openstack-docs at lists.openstack.org\n> Cc: \"Lars Kellogg-Stedman\" <lkellogg at redhat.com>\n> Sent: Thursday, October 17, 2013 12:21:27 PM\n> Subject: [Openstack-docs] Suggestion: Improved styling for \"Replaceable\" in	install guide\n> \n> I was discussing the new install guide with Lars Kellogg-Stedman, and we were\n> discussing how the underlying docbook metadata gets transformed into the\n> final HTML and PDF products.  The idea came of up having some sort of tool\n> tip show up for text tagged with \"replaceable\" to display more information\n> about a particular \"replaceable\" entry.\n> \n> For instance, the \"EXTERNAL_INTERFACE\" replaceable in the networking section\n> could say something to the effect of \"The external interface is the NIC\n> responsible for enabling communication between your networks and the outside\n> world\".\n\nGenerally this is the kind of explanatory text I feel should be put immediately before a command that uses replaceable values rather than hidden in a tooltip. I suspect part of the issue that leads you to raise this is that we\'re missing such text entirely in many cases - so regardless of style we need to be better at highlighting in the prose what is replaceable, what it\'s replaceable with, and why. Perhaps it would be appropriate to mark these up as callout lists?:\n\n    http://www.docbook.org/tdg/en/html/programlistingco.html\n\n> At the very least, a static tooltip or style that better indicated that\n> something should be replaced with an actual value would perhaps be useful\n> (this could be accomplished pretty trivially in the style sheet for the\n> docs).\n> \n> What do people think?\n\nIn Publican styles we typically apply both bold and italic to replaceable values, I think at some point Summer already got David to add this to the clouddocs-maven styles though so I am unsure how to further proceed to make these \"pop\" as is. I\'d personally be hesitant to use anything that only appears on mouseover because it hinders discoverability somewhat and may not be accessible at all in some output formats.\n\nThanks,\n\nSteve\n\n\n','<1716715584.4580627.1382026887601.JavaMail.root@redhat.com>',NULL),('<1073064991.65.1383458782842.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:06:22',0,'2013-11-03 06:06:22',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-ceilometer-python26-stable-grizzly #44','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/44/>\n\n\n\n','<1422449971.45.1383372378307.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1073365502.85.1365661270353.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-11 06:21:10',0,'2013-04-11 06:21:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-folsom #192','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/192/>\n\n------------------------------------------\n[...truncated 12866 lines...]\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\nRuntimeError: maximum recursion depth exceeded while calling a Python object\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: S3 Objectstore listening on 127.0.0.1:3333\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_unknown_bucket (nova.tests.test_objectstore.S3APITestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/tests/test_objectstore.py\",> line 65, in setUp\n    port=FLAGS.s3_port)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/wsgi.py\",> line 72, in __init__\n    self._socket = eventlet.listen((host, port), backlog=backlog)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/convenience.py\",> line 38, in listen\n    sock.bind(addr)\n  File \"/usr/lib/python2.7/socket.py\", line 224, in meth\n    return getattr(self._sock,name)(*args)\nerror: [Errno 98] Address already in use\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 26.21 secs:\n    8.09    ComputeTestCase.test_state_revert\n    5.40    CloudTestCase.test_instance_initiated_shutdown_behavior\n    5.06    StorwizeSVCDriverTestCase.test_storwize_svc_flashcopy\n    4.31    ServersTest.test_create_multiple_servers\n    3.35    ServersTest.test_create_and_rebuild_server\n----------------------------------------------------------------------\nRan 3726 tests in 629.672s\n\nFAILED (SKIP=7, errors=11)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==1.0.4\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosehtmloutput==0.0.4\nnova==2012.2.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nova/tests/nose_results.html\n+ \'[\' -f ./nova/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nova/tests/nose_results.html\n+ passcount=457\n+ \'[\' 457 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.QCOis0ORSm\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-folsom/192\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-nova-python27-stable-folsom/192/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1487566068.67.1365574580596.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1073D07477801548AA1A9753B51652652EC81CEF@xmb-rcd-x08.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-03 23:03:51',0,'2014-07-03 23:03:51',NULL,'[openstack-dev] [neutron][oslo.messaging]','Thanks Nader for the extra effort and I am glad you made progress here.\n\nMilton\n\nFrom: Nader Lahouti [mailto:nader.lahouti at gmail.com]\nSent: Thursday, July 03, 2014 3:59 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron][oslo.messaging]\n\nThanks a lot Doug and Alexei for your prompt response.\nI used what Doug suggested and worked.\n\nThanks again for the help.\nNader.\n\nOn Thu, Jul 3, 2014 at 12:04 PM, Doug Hellmann <doug.hellmann at dreamhost.com<mailto:doug.hellmann at dreamhost.com>> wrote:\nOn Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko\n<alexei.kornienko at gmail.com<mailto:alexei.kornienko at gmail.com>> wrote:\n> Hi,\n>\n> You can use oslo.messaging._drivers.impl_rabbit instead of impl_kombu\n> It was renamed and slightly change but I think it will work as you expect.\nYou should not depend on using any API defined in that module. The\n_drivers package is a private package inside oslo.messaging, and\nshouldn\'t be used directly. Use the public, documented, API instead to\nensure that future changes to the internal implementation details of\noslo.messaging do not break your code.\n\nDoug\n\n>\n> Regards,\n> Alexei Kornienko\n>\n>\n> On 07/03/2014 08:47 PM, Nader Lahouti wrote:\n>\n> Hi All and Ihar,\n>\n> As part of blueprint oslo-messaging the neutron/openstack/common/rpc tree is\n> removed. I was using impl_kombu module to process notification from keystone\n> with this following code sample:\n> ...\n> from neutron.openstack.common.rpc import impl_kombu\n>        try:\n>            conf = impl_kombu.cfg.CONF\n>             topicname = self._topic_name\n>             exchange = self._exchange_name\n>             connection = impl_kombu.Connection(conf)\n>             connection.declare_topic_consumer(topic,\n>                                               self.callback,\n>                                               topic, exchange)\n>             connection.consume()\n>         except Exception:\n>             connection.close()\n>\n>\n> Can you please let me what needs to be done to replace the above code and\n> make it work with current neutron code?\n>\n>\n> Thanks in advance,\n> Nader.\n>\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140703/7ae97170/attachment.html>\n\n','<CAF5T5jtwh7NUSRJEpkTmuPTw5svpKG8eow+x=mei41NhXAZTAQ@mail.gmail.com>',NULL),('<1073D07477801548AA1A9753B51652652EC972E2@xmb-rcd-x08.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 22:01:00',0,'2014-07-15 22:01:00',NULL,'[openstack-dev] [Neutron] [ML2] kindly request neutron-cores to\n review and approve patch \"Cisco DFA ML2 Mechanism Driver\"','Hi,\n\nThis patch was initially uploaded on Jun 27, 2014 and we have got a number of reviews from the community. A lot of thanks to these who kindly reviewed and provided feedback.\n\nCan the neutron cores please review/approve it so we can make progress here?  Really appreciate your attention and help here.\nI also include the cores who reviewed and approved the spec earlier.\n\nCode patch:\nhttps://review.openstack.org/#/c/103281/\n\nApproved Spec:\nhttps://review.openstack.org/#/c/89740/\n\n\nThanks,\nMilton\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/503ff06a/attachment.html>\n\n',NULL,NULL),('<1073D07477801548AA1A9753B51652652ECF3467@xmb-rcd-x08.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 20:13:24',0,'2014-08-26 20:13:24',NULL,'[openstack-dev] [neutron][OpenDayLight CI] Is this a real\n failure? The failure log is gone','Thanks Salvatore for the quick response for the NSX CI failure!\n\nOpenDayLight CI experts,\nWe are also seeing a failure on OpenDayLight CI but it appears there is no log at the link below.\nThis is an urgent issue for us. Appreciate your prompt help here.\n\n\nOpenDaylight CI\n\n9:35 AM\n\nPatch Set 24: Verified-1\nOpenDaylight Jenkins Build Failed\nhttps://jenkins.opendaylight.org/ovsdb/job/openstack-gerrit/1763/ : FAILURE\n\nThanks,\nMilton\n\nFrom: Salvatore Orlando [mailto:sorlando at nicira.com]\nSent: Tuesday, August 26, 2014 12:44 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron][VMware NSX CI] How to see the log for failure.\n\nHi Nader,\n\nSorry about that failure.\nWe have temporarily stopped mine sweeper for neutron while we update our devstack images.\nHowever, unfortunately some jobs did not complete properly, and therefore you had failures without logs being reported.\n\nThe situation should be back to normal soon, and you should be able to do a recheck.\n\nRegards,\nSalvatore\n\n\nOn 26 August 2014 20:44, Nader Lahouti <nader.lahouti at gmail.com<mailto:nader.lahouti at gmail.com>> wrote:\nHi,\n\nThe VMWare NSX CI is failing and I\'m not able to get any failure log to find the reason of failure.\nThe message that I get is this:\n\nVMware NSX CI has posted comments on this change.\n\n....\n\nPatch Set 24: Verified-1\n\nYou might have hit the following known bug(s):\n\nbug #1271230\n\nAdd review comment \"recheck-vmware\" to retrigger a new build.\n\n....\n\nIs the failure because of bug #1271230 or some other reason?\n\nWould be great if someone can point me to the failure log.\n\n\nThanks,\nNader.\n\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/e82377d8/attachment.html>\n\n',NULL,NULL),('<1074579981.18.1382941595313.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-28 06:26:35',0,'2013-10-28 06:26:35',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #42','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/42/>\n\n------------------------------------------\n[...truncated 18277 lines...]\n2013-10-28 06:06:49 catalog_type = object-store\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # The name of a region for object storage. If empty or commented-out, the\n2013-10-28 06:06:49 # value of identity.region is used instead. If no such region is found in\n2013-10-28 06:06:49 # the service catalog, the first found one is used.\n2013-10-28 06:06:49 #region = RegionOne\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Number of seconds to time on waiting for a container to container\n2013-10-28 06:06:49 # synchronization complete\n2013-10-28 06:06:49 container_sync_timeout = 120\n2013-10-28 06:06:49 # Number of seconds to wait while looping to check the status of a\n2013-10-28 06:06:49 # container to container synchronization\n2013-10-28 06:06:49 container_sync_interval = 5\n2013-10-28 06:06:49 # Set to True if the Account Quota middleware is enabled\n2013-10-28 06:06:49 accounts_quotas_available = True\n2013-10-28 06:06:49 # Set to True if the Container Quota middleware is enabled\n2013-10-28 06:06:49 container_quotas_available = True\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Set operator role for tests that require creating a container\n2013-10-28 06:06:49 operator_role = Member\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [boto]\n2013-10-28 06:06:49 ssh_user = cirros\n2013-10-28 06:06:49 # This section contains configuration options used when executing tests\n2013-10-28 06:06:49 # with boto.\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # EC2 URL\n2013-10-28 06:06:49 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-10-28 06:06:49 # S3 URL\n2013-10-28 06:06:49 s3_url = http://127.0.0.1:3333\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-10-28 06:06:49 aws_access =\n2013-10-28 06:06:49 aws_secret =\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Image materials for S3 upload\n2013-10-28 06:06:49 # ALL content of the specified directory will be uploaded to S3\n2013-10-28 06:06:49 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # The manifest.xml files, must be in the s3_materials_path directory\n2013-10-28 06:06:49 # Subdirectories not allowed!\n2013-10-28 06:06:49 # The filenames will be used as a Keys in the S3 Buckets\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-10-28 06:06:49 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-10-28 06:06:49 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-10-28 06:06:49 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Instance type\n2013-10-28 06:06:49 instance_type = m1.nano\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # TCP/IP connection timeout\n2013-10-28 06:06:49 http_socket_timeout = 30\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Number of retries actions on connection or 5xx error\n2013-10-28 06:06:49 num_retries = 1\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Status change wait timout\n2013-10-28 06:06:49 build_timeout = 400\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Status change wait interval\n2013-10-28 06:06:49 build_interval = 1\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [orchestration]\n2013-10-28 06:06:49 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-10-28 06:06:49 # custom Keystone service catalog implementation, you probably want to leave\n2013-10-28 06:06:49 # this value as \"orchestration\"\n2013-10-28 06:06:49 catalog_type = orchestration\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # The name of a region for orchestration. If empty or commented-out, the value\n2013-10-28 06:06:49 # of identity.region is used instead. If no such region is found in the service\n2013-10-28 06:06:49 # catalog, the first found one is used.\n2013-10-28 06:06:49 #region = RegionOne\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Status change wait interval\n2013-10-28 06:06:49 build_interval = 1\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Status change wait timout. This may vary across environments as some some\n2013-10-28 06:06:49 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-10-28 06:06:49 build_timeout = 300\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Instance type for tests. Needs to be big enough for a\n2013-10-28 06:06:49 # full OS plus the test workload\n2013-10-28 06:06:49 instance_type = m1.micro\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Name of heat-cfntools enabled image to use when launching test instances\n2013-10-28 06:06:49 # If not specified, tests that spawn instances will not run\n2013-10-28 06:06:49 #image_ref = ubuntu-vm-heat-cfntools\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # Name of existing keypair to launch servers with. The default is not to specify\n2013-10-28 06:06:49 # any key, which will generate a keypair for each test class\n2013-10-28 06:06:49 #keypair_name = heat_key\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [dashboard]\n2013-10-28 06:06:49 # URL where to find the dashboard home page\n2013-10-28 06:06:49 dashboard_url = http://127.0.0.1/\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # URL where to submit the login form\n2013-10-28 06:06:49 login_url = http://127.0.0.1/auth/login/\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [scenario]\n2013-10-28 06:06:49 # Directory containing image files\n2013-10-28 06:06:49 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # AMI image file name\n2013-10-28 06:06:49 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # ARI image file name\n2013-10-28 06:06:49 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # AKI image file name\n2013-10-28 06:06:49 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # ssh username for the image file\n2013-10-28 06:06:49 ssh_user = cirros\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 # specifies how many resources to request at once. Used for large operations\n2013-10-28 06:06:49 # testing.\"\n2013-10-28 06:06:49 large_ops_number = 0\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [cli]\n2013-10-28 06:06:49 # Enable cli tests\n2013-10-28 06:06:49 enabled = True\n2013-10-28 06:06:49 # directory where python client binaries are located\n2013-10-28 06:06:49 cli_dir = /usr/local/bin\n2013-10-28 06:06:49 # Number of seconds to wait on a CLI timeout\n2013-10-28 06:06:49 timeout = 15\n2013-10-28 06:06:49 \n2013-10-28 06:06:49 [service_available]\n2013-10-28 06:06:49 # Whether or not cinder is expected to be available\n2013-10-28 06:06:49 cinder = True\nall develop-inst: /opt/stack/new/tempest\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpBINncF\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp4nPS4B\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpO8fFV6\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpn6s_8c\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_hosts_negative\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_hosts_negative\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_hosts_negative.py\", line 23, in <module>\n    class HostsAdminNegativeTestJSON(base.BaseComputeAdminTest):\nAttributeError: \'module\' object has no attribute \'BaseComputeAdminTest\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2861 tests in 1114.047s\nFAILED (id=0, failures=2, skips=76)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-611750-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-611750.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-611750/42/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1309983215.14.1382855289067.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1075338438.13878790.1394775220115.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-14 01:33:40',-14400,'2014-03-14 05:33:40',NULL,'[Openstack-docs] Conventions on naming [clarifications]','Hi,\n\nI apologize for bringing this up a bit late, seeing as the OpenStack project naming conventions have already been discussed last month:\nhttp://lists.openstack.org/pipermail/openstack-docs/2014-February/003804.html\n\nAnyhow, I wanted to clarify:\n\n* Why do \"Identity Service\" and \"Image Service\" have the word \"Service\" as part of their names? I assume that this is the case, seeing as \"Service\" is initcapped? \n* Are there instances where, say, \"the Compute service\" is valid? Or should such instances be replaced with \"the OpenStack Compute service\"? And is the convention for Compute true for Block Storage, Networking, etc?\n\nI\'m asking because, specifically for \"Compute\", the usage is varied across the documentation:\n\n    \"the Compute service\" - 54\n    \"the Compute Service\" - 18\n    \"the OpenStack Compute service\" - 6\n    \"the OpenStack Compute Service\" - 2\n\nI only checked Compute to help illustrate the situation. I haven\'t checked the usage stats yet for the other service names, though I\'m sure we\'ll find similar naming variations with Networking, Block Storage, etc. I can spend time applying the correct convention, but I\'d like to verify exactly what convention to follow in this regard (not just for Compute, but for all of them). \n\nAgain, I apologize for only bringing this up now, a month after it\'s already been discussed. It\'s just that I didn\'t realize the extent of the naming variation until now (I\'ve only started contributing late January 2014). \n\n\nRegards,\nDon Domingo\nContent Author - OpenStack\nEngineering Content Services\nEmail: ddomingo at redhat.com\nIRC: ddomingo\n\n\n','<539707010.13868012.1394768789609.JavaMail.zimbra@redhat.com>',NULL),('<1075481205.1270527.1376351502145.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-08-12 19:51:42',-14400,'2013-08-12 23:51:42',NULL,'[OpenStack Foundation] [Foundation Board] Spider / What is Core\n Discussion opportunity: SJC or SFO 8/27 evening','I could probably get some space in Red Hat\'s office in Mountain View - let me know. It\'s reasonably close to CalTrain - I would need names and affiliations by 8/26. \n\nWe\'re also hosting a Gluster Community workshop at Rackspace\'s SF office that day - I could try to see about getting a space there after we\'re finished (5pm). \n\n-John Mark Walker \nGluster Community Leader, Red Hat \n\n----- Original Message -----\n\n> I\'m in as well and would prefer mid/south bay. If no one offers space in SF,\n> then I can get us space in mid-peninsula at SVForum office in Redwood Shores\n> or in south bay at HP Cloud just off 101/237 . Or I can find us a space near\n> the Caltrain station in Mountain View .\n\n> Anyone else want to attend so we can break the tie?\n\n> Dave\n\n> On Mon, Aug 12, 2013 at 3:50 PM, Sean Roberts < seanrob at yahoo-inc.com >\n> wrote:\n\n> > I\'m available as well. Mid or south bay as preference, but I could make SF.\n> \n\n> > Sean Roberts\n> \n> > Infrastructure Strategy\n> \n> > seanrob at yahoo-inc.com (925) 980-4729\n> \n\n> > On Aug 12, 2013, at 12:24 PM, Rob_Hirschfeld at Dell.com wrote:\n> \n\n> > > All,\n> > \n> \n> > > I?m going to be in the Bay Area and available in the evening on 8/27. Is\n> > > anyone interested in having a face-to-face meeting about core that night?\n> > \n> \n> > > I?ve got a meeting downtown in San Fran until 5, so I?m happy to meet\n> > > there\n> > > or take the train south for a 6:30 meeting.\n> > \n> \n> > > If there?s interest, will someone local take a lead in getting a\n> > > location?\n> > > I\n> > > think it?s reasonable to setup a hangout for remote people too.\n> > \n> \n> > > Rob\n> > \n> \n> > > ______________________________\n> > \n> \n> > > Rob Hirschfeld\n> > \n> \n> > > Sr. Distinguished Cloud Solution Architect\n> > \n> \n> > > Dell | Cloud Edge, Data Center Solutions\n> > \n> \n> > > blog robhirschfeld.com , twitter @zehicle\n> > \n> \n> > > Please note, I am based in the CENTRAL (-6) time zone\n> > \n> \n> > > _______________________________________________\n> > \n> \n> > > Foundation-board mailing list\n> > \n> \n> > > Foundation-board at lists.openstack.org\n> > \n> \n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n> > \n> \n\n> > _______________________________________________\n> \n> > Foundation mailing list\n> \n> > Foundation at lists.openstack.org\n> \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130812/9e6efb13/attachment-0001.html>\n\n','<CALXFWmYh_bf3e4i-sS4XDALuqhnZnAFzsBX1_QVuF=cjtPvZjg@mail.gmail.com>',NULL),('<1077227719.39.1383372181473.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:03:01',0,'2013-11-02 06:03:01',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-horizon-docs-stable-folsom #36','See <https://jenkins02.openstack.org/job/periodic-horizon-docs-stable-folsom/36/>\n\n\n\n',NULL,NULL),('<107772219.4538736.1390547361018.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 02:09:21',-18000,'2014-01-24 07:09:21',NULL,'[openstack-dev] [neutron][ha][agents] host= parameter','Hi!,\n  \n    I want to ask, specifically, about the intended purpose of the\nhost=... parameter in the neutron-agents (undocumented AFAIK).\n\n    I haven\'t found any documentation about it. As far as I discovered,\nit\'s being used to provide Active/Passive replication of agents, as\nyou can manage agent\'s on different hosts to register with the same ID to neutron \n(of course, *never* at the same time).\n \nFor example, if an L3 router host dies somewhere, you can start it\'s passive\nusing the same host=.... id in the agent .ini file, and it will setup\nthe exact same virtual routers and connectivity.\n\n    My main concern, is, as it doesn\'t seem to be documented, is it really\npurposed for this?,\n\n    In that case, I suppose it would be good if I spend a few minutes to document\nthe agent example config files.\n\n    Thanks in advance for any feedback,\n\nCheers,\n    Miguel ?ngel Ajo\n\n\n\n\n\n','<235893966.4537800.1390547086089.JavaMail.root@redhat.com>',NULL),('<1077724944.3747707.1396020493055.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 11:28:13',-14400,'2014-03-28 15:28:13',NULL,'[openstack-dev] Regarding on iptables in openstack','Hi Shiva,\nThis list is for development discussion and questions only.  Please use the Operator List (http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators)\nor the general list for questions about deploying or operating OpenStack.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"shiva m\" <anjaneya2 at gmail.com>\nTo: openstack-dev at lists.openstack.org\nSent: Friday, March 28, 2014 7:50:47 AM\nSubject: [openstack-dev] Regarding on iptables in openstack\n\nHi, \n\nI installed devstack-havana on ubuntu-13.10. I see iptables-save with all iptable rules. Can any one please help me how do I add a new rule or edit iptables-save on Openstack? \n\nThanks \nShiva \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAGm0vUrfTFaGYaPZ=Lsn7TE=Yy82QiUzHYCFZwRvfxe7+vnTrQ@mail.gmail.com>',NULL),('<1077b7a0d9a14d6caa9d384130e67731@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-08 06:56:05',0,'2014-01-08 06:56:05',NULL,'[Openstack] Tempest Testcases for ML2 Mechanism drivers - Help','Hi  -\n\nWith respect to writing test cases with Tempest for Neutron,\n\nI have a Freescale Mechanism Driver which support a Cloud Resource Discovery (CRD) Service .\n\nThe complete data flow is show below.\n\n[cid:image001.png at 01CF0BA3.7DB6CAE0]\n\nThe FSL Mechanism driver partly depends on ML2 Plug-in (_pre_commint and _post_commit definitions) and Partly depends on CRD Service (with CRD client calls in _post_commit definitions).\n\nI want to write Tempest test cases for the FSL Mechanism driver.\n\nKindly please help me on how to write the Tempest test cases for these kind of mechanism drivers.\n\nAlso, help me on how to submit the BP document, Code base and Test cases for review.\n\nThanking you for the help.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140108/5256fb68/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 19718 bytes\nDesc: image001.png\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140108/5256fb68/attachment.png>\n\n',NULL,NULL),('<1077b7a0d9a14d6caa9d384130e67731@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 06:56:05',0,'2014-01-08 06:56:05',NULL,'[openstack-dev] Tempest Testcases for ML2 Mechanism drivers - Help','Hi  -\n\nWith respect to writing test cases with Tempest for Neutron,\n\nI have a Freescale Mechanism Driver which support a Cloud Resource Discovery (CRD) Service .\n\nThe complete data flow is show below.\n\n[cid:image001.png at 01CF0BA3.7DB6CAE0]\n\nThe FSL Mechanism driver partly depends on ML2 Plug-in (_pre_commint and _post_commit definitions) and Partly depends on CRD Service (with CRD client calls in _post_commit definitions).\n\nI want to write Tempest test cases for the FSL Mechanism driver.\n\nKindly please help me on how to write the Tempest test cases for these kind of mechanism drivers.\n\nAlso, help me on how to submit the BP document, Code base and Test cases for review.\n\nThanking you for the help.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/5256fb68/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 19718 bytes\nDesc: image001.png\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/5256fb68/attachment.png>\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1078256087.39.1380266174905.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-27 07:16:14',0,'2013-09-27 07:16:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-neutron-python26-stable-grizzly #19','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 5438 lines...]\n    test_create_service_type_no_svcdef_returns_400               OK    0.15\n    test_delete_dummy_decreases_service_type_refcount            OK    0.18\n    test_delete_service_type_in_use_returns_409                  OK    0.19\n    test_get_default_service_type                                OK    0.16\n    test_get_service_type                                        OK    0.19\n    test_list_service_types                                      OK    0.19\n    test_service_type_create                                     OK    0.16\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.19\n    test_service_type_update_name                                OK    0.18\n    test_service_type_update_set_default_returns_400             OK    0.17\n    test_service_type_update_svc_defs                            OK    0.19\nServiceTypeManagerTestCaseXML\n    test_create_dummy_increases_service_type_refcount            OK    0.18\n    test_create_service_type_default_returns_400                 OK    0.16\n    test_create_service_type_no_svcdef_returns_400               OK    0.16\n    test_delete_dummy_decreases_service_type_refcount            OK    0.20\n    test_delete_service_type_in_use_returns_409                  OK    0.19\n    test_get_default_service_type                                OK    0.16\n    test_get_service_type                                        OK    2.62\n    test_list_service_types                                      OK    0.20\n    test_service_type_create                                     OK    0.16\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.18\n    test_service_type_update_name                                OK    0.19\n    test_service_type_update_set_default_returns_400             OK    0.18\n    test_service_type_update_svc_defs                            OK    0.18\nActionDispatcherTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_action_None                                    OK    0.00\n    test_dispatch_default                                        OK    0.00\nDictSerializerTest\n    test_dispatch_default                                        OK    0.00\nFaultTest\n    test_call_fault                                              OK    0.00\nJSONDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nJSONDictSerializerTest\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nMiddlewareTest\n    test_process_response                                        OK    0.00\nRequestDeserializerTest\n    test_deserialize                                             OK    0.01\n    test_get_action_args                                         OK    0.00\n    test_get_body_deserializer_unknown_content_type              OK    0.00\n    test_get_deserializer                                        OK    0.00\n    test_get_expected_content_type                               OK    0.00\nRequestHeadersDeserializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nRequestTest\n    test_content_type_accept_and_query_extension                 OK    0.00\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_accept_with_given_content_types            OK    0.00\n    test_content_type_from_accept                                OK    0.00\n    test_content_type_from_query_extension                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\n    test_content_type_with_given_content_types                   OK    0.00\nResourceTest\n    test_call_resource_class_bad_request                         OK    0.00\n    test_call_resource_class_internal_error                      OK    0.00\n    test_dispatch                                                OK    0.00\n    test_dispatch_unknown_controller_action                      OK    0.00\n    test_malformed_request_body_throws_bad_request               OK    0.00\n    test_type_error                                              OK    0.00\n    test_wrong_content_type_server_error                         OK    0.00\n    test_wrong_content_type_throws_unsupported_media_type_error  OK    0.00\nResponseHeadersSerializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nResponseSerializerTest\n    test_get_body_serializer                                     OK    0.00\n    test_get_serializer                                          OK    0.00\n    test_serialize_json_response                                 OK    0.00\n    test_serialize_response_None                                 OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_response                                  OK    0.00\nSerializerTest\n    test_deserialize_json_content_type                           OK    0.00\n    test_deserialize_raise_bad_request                           OK    0.00\n    test_deserialize_xml_content_type                            OK    0.00\n    test_deserialize_xml_content_type_with_meta                  OK    0.00\n    test_get_deserialize_handler_unknown_content_type            OK    0.00\n    test_serialize_content_type_json                             OK    0.00\n    test_serialize_content_type_xml                              OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_root_is_None                              OK    0.00\n    test_serialize_xml_root_key_is_dict                          OK    0.00\n    test_serialize_xml_root_key_is_list                          OK    0.00\nServerTest\n    test_run_server                                              OK    0.00\nTestWSGIServer\n    test_ipv6_listen_called_with_scope                           OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nTextDeserializerTest\n    test_dispatch_default                                        OK    0.00\nXMLDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_initialization                                          OK    0.00\n    test_xml_empty                                               OK    0.00\n    test_xml_with_utf8                                           OK    0.00\nXMLDictSerializerTest\n    test_None                                                    OK    0.00\n    test_call                                                    OK    0.00\n    test_empty_dic_xml                                           OK    0.00\n    test_non_root_one_item_dic_xml                               OK    0.00\n    test_non_root_two_items_dic_xml                              OK    0.00\n    test_xml                                                     OK    0.00\n    test_xml_meta_contains_node_name_dict                        OK    0.00\n    test_xml_meta_contains_node_name_list                        OK    0.00\n    test_xml_root_key_is_list                                    OK    0.00\n    test_xml_with_unicode                                        OK    0.00\n    test_xml_with_utf8                                           OK    0.00\n\n======================================================================\nERROR: quantum.tests.unit.test_debug_commands.TestDebugCommands.test_list_probe\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{2013-09-27 07:11:19,042    ERROR [cliff.display] (pyparsing 1.5.7 (<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages),> Requirement.parse(\'pyparsing>=2.0.1\'))}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/quantum/tests/unit/test_debug_commands.py\",> line 244, in test_list_probe\n    cmd = commands.ListProbe(self.app, None)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/quantumclient/quantum/v2_0/__init__.py\",> line 277, in __init__\n    super(QuantumCommand, self).__init__(app, app_args)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/cliff/display.py\",> line 21, in __init__\n    self.load_formatter_plugins()\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/cliff/display.py\",> line 38, in load_formatter_plugins\n    if self.app_args.debug:\nAttributeError: \'NoneType\' object has no attribute \'debug\'\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 17.34 secs:\n    3.62    TestNiciraPortsV2.test_recycling\n    3.57    RouterServiceInsertionTestCase.test_pool_delete_with_router_id\n    3.47    TestDhcpAgentEventHandler.test_subnet_update_end\n    3.36    ExtraRouteDBTestCase.test_floating_ip_direct_port_delete_returns_409\n    3.32    TestNecPortsV2.test_recycling\n----------------------------------------------------------------------\nRan 5179 tests in 1745.766s\n\nFAILED (SKIP=238, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==1.3.3\nalembic==0.6.0\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\nconfigobj==4.7.2\ncoverage==3.6\nd2to1==0.2.11\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\nkombu==2.5.14\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npyparsing==1.5.7\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-novaclient==2.15.0\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\npyudev==0.16.1\nquantum==jenkins.periodic.neutron.python26.stable.grizzly.19\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\ntermcolor==1.1.0\ntestrepository==0.0.17\ntesttools==0.9.32\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./quantum/tests/unit/nose_results.html\n+ \'[\' -f ./quantum/tests/unit/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./quantum/tests/unit/nose_results.html\n+ passcount=315\n+ \'[\' 315 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.iZs6aNdikp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-neutron-python26-stable-grizzly/19/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-grizzly/centos6-11/19\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1078410665.25491345.1352789802382.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-13 01:56:42',-18000,'2012-11-13 06:56:42',NULL,'[openstack-qa] Tempest Boto S3/EC2 tests','Hi Dan,\n\nThank you.\n\nSwift3 is working and passes the basic tests, but it is not under the https://github.com/openstack.\nIt needs at least \"s3_port 8080\" and s3_access_key, s3_secret_key configured in the /etc/nova/nova.conf.\n\nThe nova-api does not delegate credentials to the S3 back-end, it means all user will use the same configured AWS credentials on the S3 back-end for all EC2 requests.\n(https://bugs.launchpad.net/nova/+bug/1075051)\n\nAFAIK nova-objectstore does not validate AWS credentials. Probably it could lead to security issue in production. \nGood to know it is not for public production usage.\n\n\nRegards,\nAttila \n\n----- Original Message -----\nFrom: \"Dan Prince\" <dprince at redhat.com>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nCc: \"Attila Fazekas\" <afazekas at redhat.com>\nSent: Monday, November 12, 2012 6:17:57 PM\nSubject: Re: [openstack-qa] Tempest Boto S3/EC2 tests\n\n\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: \"Attila Fazekas\" <afazekas at redhat.com>\n> Cc: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Monday, November 12, 2012 11:27:20 AM\n> Subject: Re: [openstack-qa] Tempest Boto S3/EC2 tests\n> \n> Attila, after reading through your proposed patches again, I\'m still\n> concerned that we\'re not on the same page.\n> \n> Specifically, OpenStack does *not* have a public S3 API to test. At\n> all.\n\nI think maybe the intent here was to test nova-objectstore. See here:\n\n  https://github.com/openstack/nova/blob/master/nova/objectstore/s3server.py#L20\n\nObjectstore is essentially a small S3 like API backed by local file storage. Its primary purpose was to satisfy the need to test the EC2 API where things like registering images occur (euca-publish-tarball, etc.) It isn\'t meant to be used in production however so I wouldn\'t put too much effort into testing it specifically for S3 compatibility... the primary purpose is just to allow us to test the EC2 API for functional completeness. I\'d stick to tests for things like registering images and leave specific S3 API testing out of Tempest for now.\n\nWe actually have some Smoke tests in Nova (written in Python, using Boto) which do something very similar:\n\nhttps://github.com/openstack/nova/blob/master/smoketests/test_sysadmin.py#L55\n\nWhen I run those via SmokeStack I usually use nova-objectstore to provide the S3 storage.\n\nAnother option would be to use Swift with this middleware installed https://github.com/fujita/swift3.git. I haven\'t tried this recently so I\'m not sure it works as a drop in for these tests at the moment.\n\nHope this helps.\n\nDan\n\n> \n> The EC2 tests we were hoping to add to Tempest were supposed to be\n> tests\n> of the EC2 API, not the S3 API, since Nova supplies an EC2 API\n> endpoint.\n> \n> We are not interested in adding tests for S3 to Tempest -- these\n> tests\n> exist already in Boto and other places. Since Nova has an EC2\n> compatibility API endpoint, we\'re interested in testing that.\n> \n> I\'m not sure how better I can describe this... please find me on IRC\n> if\n> you need to discuss further.\n> \n> Best,\n> -jay\n> \n> On 11/12/2012 10:00 AM, Attila Fazekas wrote:\n> > Hi Jay,\n> > \n> > Can you add some environment variables for configuration creation\n> > in order to get working the\n> > https://review.openstack.org/#/c/14689/ ?\n> > Based on the bash debug output I see in the jenkins logs I created\n> > small script. Probably the parts of the attached scripts can be\n> > merged or at least can help.\n> > \n> > The expected output when it has the s3-materailas:\n> > EC2 run, stop and terminate instance ... ok\n> > EC2 run, terminate immediately ... ok\n> > EC2 create KeyPair ... ok\n> > EC2 delete KeyPair ... SKIP: Skipped until the Bug #1072318 is\n> > resolved\n> > EC2 duplicate KeyPair ... SKIP: Skipped until the Bug #1072762 is\n> > resolved\n> > EC2 get KeyPair ... ok\n> > EC2 Create, get, delete Volume ... SKIP: Skipped until the Bug\n> > #1074901 is resolved\n> > S3 Create, get and delete bucket ... SKIP: Skipped until the Bug\n> > #1076965 is resolved\n> > Register and deregister aki image ... SKIP: Skipped until the Bug\n> > #1074904 is resolved\n> > Register and deregister ami image ... ok\n> > Register and deregister ari image ... SKIP: Skipped until the Bug\n> > #1074908 and #1074904 is resolved\n> > S3 Create, get and delete object ... SKIP: Skipped until the Bug\n> > #1076534 is resolved\n> > \n> > \n> > Best Regards,\n> > Attila\n> > \n> > ----- Original Message -----\n> > From: \"Attila Fazekas\" <afazekas at redhat.com>\n> > To: \"Jay Pipes\" <jaypipes at gmail.com>\n> > Cc: \"Yaniv Kaul\" <ykaul at redhat.com>, \"daryl walleck\"\n> > <daryl.walleck at rackspace.com>, \"Jaroslav Henner\"\n> > <jhenner at redhat.com>, openstack-qa at lists.openstack.org\n> > Sent: Wednesday, November 7, 2012 7:06:47 PM\n> > Subject: Re: [openstack-qa] Tempest Boto S3/EC2 tests\n> > \n> > OK. Some projects push back patches when they are too large.\n> > I will submit the full patch to the refers Gerrint link.\n> > \n> > ----- Original Message -----\n> > From: \"Jay Pipes\" <jaypipes at gmail.com>\n> > To: \"Attila Fazekas\" <afazekas at redhat.com>\n> > Cc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\"\n> > <ykaul at redhat.com>, \"daryl walleck\" <daryl.walleck at rackspace.com>,\n> > openstack-qa at lists.openstack.org\n> > Sent: Wednesday, November 7, 2012 6:19:37 PM\n> > Subject: Re: Tempest Boto S3/EC2 tests\n> > \n> > You won\'t be sending anything... you just need to git review and\n> > your\n> > changes should be pushed to Gerrit.\n> > \n> > Best,\n> > -jay\n> > \n> > On 11/07/2012 12:08 PM, Attila Fazekas wrote:\n> >> Hi Jay,\n> >>\n> >> My patch is more than 1000 line changes, now.\n> >> Can I send it in one commit ?\n> >>\n> >> Regards,\n> >> Attila\n> >>\n> >> ----- Original Message -----\n> >> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> >> To: \"Attila Fazekas\" <afazekas at redhat.com>\n> >> Cc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\"\n> >> <ykaul at redhat.com>, \"daryl walleck\"\n> >> <daryl.walleck at rackspace.com>, openstack-qa at lists.openstack.org\n> >> Sent: Wednesday, November 7, 2012 4:18:21 PM\n> >> Subject: Re: Tempest Boto S3/EC2 tests\n> >>\n> >> On 11/07/2012 07:50 AM, Attila Fazekas wrote:\n> >>> Hi Jay,\n> >>>\n> >>> Is is ok if just send the full patch once?\n> >>> Am I need to split it first ?\n> >>\n> >> I\'m sorry Attila, I don\'t understand your question... are you\n> >> asking\n> >> about how to push updates to your code to Gerrit?\n> >>\n> >> -jay\n> >>\n> >>> ----- Original Message -----\n> >>> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> >>> To: \"Attila Fazekas\" <afazekas at redhat.com>\n> >>> Cc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\"\n> >>> <ykaul at redhat.com>, \"daryl walleck\"\n> >>> <daryl.walleck at rackspace.com>, openstack-qa at lists.openstack.org\n> >>> Sent: Tuesday, November 6, 2012 3:48:07 PM\n> >>> Subject: Re: Tempest Boto S3/EC2 tests\n> >>>\n> >>> Hi again Attila,\n> >>>\n> >>> So, I\'m still having major issues running Tempest due to\n> >>> https://bugs.launchpad.net/tempest/+bug/1072841 which is being\n> >>> held up\n> >>> because of https://bugs.launchpad.net/glance/+bug/1074132. That\n> >>> latter\n> >>> bug is actually preventing me from even getting devstack to\n> >>> complete :(\n> >>>\n> >>> I will work with Brian Waldon to try and get this resolved today.\n> >>> Thanks\n> >>> for your patience.\n> >>>\n> >>> Could you please mark your review\n> >>> (https://review.openstack.org/#/c/14689/) back to Open status --\n> >>> just\n> >>> click the Unabandon button.\n> >>>\n> >>> Thanks!\n> >>> -jay\n> >>>\n> >>> On 11/05/2012 01:36 AM, Attila Fazekas wrote:\n> >>>> Jay,\n> >>>>\n> >>>> I have made many modification on the previous version.\n> >>>> I would really appreciate a little feedback and review.\n> >>>>\n> >>>> You can see the current version of this patch here:\n> >>>> https://github.com/afazekas/tempest/commit/95b09c992bff9143e7808e95b2aac192ce202557\n> >>>>\n> >>>> I really need to know at least the base is acceptable, before\n> >>>> creating more test cases.\n> >>>>\n> >>>> Regards,\n> >>>> Attila\n> >>>>\n> > \n> > _______________________________________________\n> > openstack-qa mailing list\n> > openstack-qa at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> > \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<243767346.13547074.1352740677852.JavaMail.root@redhat.com>',NULL),('<1078EEA6-544A-4796-807A-0B19CCB3A87B@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-12-10 12:32:45',-21600,'2012-12-10 18:32:45',NULL,'[OpenStack Foundation] Missing exhibits in minutes (was Re:\n	Board discussing how to improve the Individual Director\n	election process, community input wanted)','\nOn Dec 5, 2012, at 1:40 PM, Lloyd Dewolf <lloydostack at gmail.com> wrote:\n\n> Also, were the \"Gold Member Sponsor Criteria\" published? \n\nYes, they are published here: http://wiki.openstack.org/Governance/Foundation/PotentialMemberCriteria\n\nThe link was shared in email summary of the October 15 board meeting http://lists.openstack.org/pipermail/foundation/2012-October/001195.html.  For some reason it was knocked off the main Foundation wiki page, so we added it back to the list of documents to make it easier to find http://wiki.openstack.org/Governance/Foundation.\n\nThanks,\nLauren\n\n>  \n> Thank you,\n> --\n> @lloyddewolf\n> http://www.pistoncloud.com/\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121210/67a50dbc/attachment.html>\n\n','<CABN7HMKVbmn6Tey5s8tEWZ8UmU-dHO1Fbm7Ryfz+76iq1rsB5g@mail.gmail.com>',NULL),('<107FB20C-09FC-43B6-B6BE-A3FF5E480F96@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 23:09:09',0,'2013-11-22 23:09:09',NULL,'[openstack-dev] [Solum] Working group on language packs','The breakout meeting schedule poll is published here (dates will be published here once they are selected):\nhttps://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series\n\nIf you would like to join the working group, please:\n\n1) Subscribe to the lang-pack blueprint: https://blueprints.launchpad.net/solum/+spec/lang-pack\n2) Participate in the doodle poll currently published on the wiki page referenced above to help select the best time for the meetings.\n\nThanks,\n\nAdrian\n\n\nFor those interested in joining this working group,\nOn Nov 22, 2013, at 8:34 AM, Clayton Coleman <ccoleman at redhat.com> wrote:\n\n> I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far.  The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance).  These are *DRAFT* and are intended for public debate.  \n> \n> https://blueprints.launchpad.net/solum/+spec/lang-pack\n> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts\n> \n> Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving.\n> \n> [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes\n> \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1788852399.27667197.1385138077079.JavaMail.root@redhat.com>',NULL),('<1080344135.3815365.1380305496256.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-27 14:11:36',-14400,'2013-09-27 18:11:36',NULL,'[openstack-dev] Nova Migrate/Resize Libvirt Methods','Hello Fellow OpenStackers,\n\nI was working on a bug (https://bugzilla.redhat.com/show_bug.cgi?id=975014) involving the Nova resize functionality in the libvirt driver.  So, it turns out that the bug is caused by nova code trying to ssh directly into another compute node.  Since it was not authorized to do so, the command failed.\n\nSo, my question is this: should nova really be SSHing directly into a peer machine to create a directory?  Doesn\'t that kind of defeat the purpose of the centralized RPC mechanism?  However, if this is the intended functionality, should Packstack be smarter about setting up permissions (this was a packstack install) when there are two or more compute nodes listed?\n \nBest Regards,\nSolly Ross\n\nP.S. Yes, I know that was more than one question :-P\n\n\n','<1158847125.3807588.1380304647493.JavaMail.root@redhat.com>',NULL),('<108062365.4.1386915351348.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:15:50',0,'2013-12-13 06:15:50',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-ceilometer-docs-grizzly #8','See <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/8/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise26 in workspace <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/>\nCheckout:periodic-ceilometer-docs-grizzly / <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/> - hudson.remoting.Channel at 8c0ede5:precise26\nUsing strategy: Default\nLast Built Revision: Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/ceilometer\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/ceilometer\nCommencing build of Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\nChecking out Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\n[periodic-ceilometer-docs-grizzly] $ /bin/bash -xe /tmp/hudson4519372425045972137.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack ceilometer\n+ org=openstack\n+ project=ceilometer\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack ceilometer /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=ceilometer\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack ceilometer\n++ org=openstack\n++ project=ceilometer\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack ceilometer /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=ceilometer\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z ceilometer ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/ceilometer /opt/requirements/projects.txt\nopenstack/ceilometer\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/tools/test-requires,> -r<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/tools/pip-requires,> sphinxcontrib-httpdomain\nvenv inst: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/dist/ceilometer-jenkins.periodic.ceilometer.docs.grizzly.8.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/>\nGenerating doc/source/api/ceilometer.agent.rst\nGenerating doc/source/api/ceilometer.api.acl.rst\nGenerating doc/source/api/ceilometer.api.app.rst\nGenerating doc/source/api/ceilometer.api.config.rst\nGenerating doc/source/api/ceilometer.api.controllers.root.rst\nGenerating doc/source/api/ceilometer.api.controllers.v2.rst\nGenerating doc/source/api/ceilometer.api.hooks.rst\nGenerating doc/source/api/ceilometer.api.middleware.rst\nGenerating doc/source/api/ceilometer.api.v1.acl.rst\nGenerating doc/source/api/ceilometer.api.v1.app.rst\nGenerating doc/source/api/ceilometer.api.v1.blueprint.rst\nGenerating doc/source/api/ceilometer.central.manager.rst\nGenerating doc/source/api/ceilometer.central.plugin.rst\nGenerating doc/source/api/ceilometer.collector.meter.rst\nGenerating doc/source/api/ceilometer.collector.service.rst\nGenerating doc/source/api/ceilometer.compute.instance.rst\nGenerating doc/source/api/ceilometer.compute.manager.rst\nGenerating doc/source/api/ceilometer.compute.notifications.rst\nGenerating doc/source/api/ceilometer.compute.nova_notifier.folsom.rst\nGenerating doc/source/api/ceilometer.compute.nova_notifier.grizzly.rst\nGenerating doc/source/api/ceilometer.compute.plugin.rst\nGenerating doc/source/api/ceilometer.compute.pollsters.rst\nGenerating doc/source/api/ceilometer.compute.virt.inspector.rst\nGenerating doc/source/api/ceilometer.compute.virt.libvirt.inspector.rst\nGenerating doc/source/api/ceilometer.counter.rst\nGenerating doc/source/api/ceilometer.energy.kwapi.rst\nGenerating doc/source/api/ceilometer.extension_manager.rst\nGenerating doc/source/api/ceilometer.image.glance.rst\nGenerating doc/source/api/ceilometer.image.notifications.rst\nGenerating doc/source/api/ceilometer.network.floatingip.rst\nGenerating doc/source/api/ceilometer.network.notifications.rst\nGenerating doc/source/api/ceilometer.nova_client.rst\nGenerating doc/source/api/ceilometer.objectstore.swift.rst\nGenerating doc/source/api/ceilometer.objectstore.swift_middleware.rst\nGenerating doc/source/api/ceilometer.openstack.common.context.rst\nGenerating doc/source/api/ceilometer.openstack.common.eventlet_backdoor.rst\nGenerating doc/source/api/ceilometer.openstack.common.excutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.gettextutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.importutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.jsonutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.local.rst\nGenerating doc/source/api/ceilometer.openstack.common.log.rst\nGenerating doc/source/api/ceilometer.openstack.common.loopingcall.rst\nGenerating doc/source/api/ceilometer.openstack.common.network_utils.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.api.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.list_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.policy.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.common.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.matchmaker_redis.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.service.rst\nGenerating doc/source/api/ceilometer.openstack.common.service.rst\nGenerating doc/source/api/ceilometer.openstack.common.setup.rst\nGenerating doc/source/api/ceilometer.openstack.common.threadgroup.rst\nGenerating doc/source/api/ceilometer.openstack.common.timeutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.version.rst\nGenerating doc/source/api/ceilometer.pipeline.rst\nGenerating doc/source/api/ceilometer.plugin.rst\nGenerating doc/source/api/ceilometer.policy.rst\nGenerating doc/source/api/ceilometer.publisher.meter_publish.rst\nGenerating doc/source/api/ceilometer.service.rst\nGenerating doc/source/api/ceilometer.storage.base.rst\nGenerating doc/source/api/ceilometer.storage.impl_hbase.rst\nGenerating doc/source/api/ceilometer.storage.impl_log.rst\nGenerating doc/source/api/ceilometer.storage.impl_mongodb.rst\nGenerating doc/source/api/ceilometer.storage.impl_sqlalchemy.rst\nGenerating doc/source/api/ceilometer.storage.impl_test.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.001_add_meter_table.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.002_remove_duration.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.003_set_utf8_charset.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.004_add_counter_unit.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.005_remove_resource_timestamp.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.006_counter_volume_is_float.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migration.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.models.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.session.rst\nGenerating doc/source/api/ceilometer.tests.api.rst\nGenerating doc/source/api/ceilometer.tests.base.rst\nGenerating doc/source/api/ceilometer.tests.db.rst\nGenerating doc/source/api/ceilometer.tests.skip.rst\nGenerating doc/source/api/ceilometer.transformer.accumulator.rst\nGenerating doc/source/api/ceilometer.utils.rst\nGenerating doc/source/api/ceilometer.volume.notifications.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-docs-grizzly/precise26\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-docs-grizzly/precise26/8\n[SCP] Copying console log.\n\n\n','<691265516.67.1386828328832.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1081965009.1654933.1395173250786.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 16:07:30',-14400,'2014-03-18 20:07:30',NULL,'[openstack-dev] Constructive Conversations','Since I joined the OpenStack community back in May, this is something I\'ve though about.\n\nI think there\'s something to be said for thought-to-text being a lossy encoding algorithm (at least\nthe way most people use it).  I\'ve encountered cases where it appeared the person on the other end was angry or\nbelittling, where in fact they were just surprised (or perhaps were slightly exasperated).\n\nSometimes it\'s seemed like I\'ve had reviews where the first comment feels like\n\"OMG THIS IS THE WORST THING IMAGINABLE YOU SHOULD GO DIE IN A FIRE\" and then I make a change and the next comment\nis \"you\'re an awesome person and should feel proud of yourself\".\n\nTo a certain extent, things like emoji can help to rectify situations like these (that\'s actually why people started using\nthem back in the BBS days), but part of it is simply knowing that certain people talk a certain way.  Could some people\nbe more conscious of how their words could be interpreted?  Certainly, but it\'s difficult to know how one\'s words will\nbe interpreted.  Are there cases of people actually intending to be a dick?  Probably, but I feel like these cases are\ndwarfed by the aforementioned cases.\n\nJust my 0.00003 BTC.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Chris Behrens\" <cbehrens at codestud.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, March 18, 2014 3:25:08 PM\nSubject: Re: [openstack-dev] Constructive Conversations\n\n\nOn Mar 18, 2014, at 11:57 AM, Matt Riedemann < mriedem at linux.vnet.ibm.com > wrote: \n\n\n\n\n[?] \nNot to detract from what you\'re saying, but this is \'meh\' to me. My company has some different kind of values thing every 6 months it seems and maybe it\'s just me but I never really pay attention to any of it. I think I have to put something on my annual goals/results about it, but it\'s just fluffy wording. \n\nTo me this is a self-policing community, if someone is being a dick, the others should call them on it, or the PTL for the project should stand up against it and set the tone for the community and culture his project wants to have. That\'s been my experience at least. \n\nMaybe some people would find codifying this helpful, but there are already lots of wikis and things that people can\'t remember on a daily basis so adding another isn\'t probably going to help the problem. Bully\'s don\'t tend to care about codes, but if people stand up against them in public they should be outcast. \n\nI agree with the goals and sentiment of Kurt?s message. But, just to add a little to Matt?s reply: Let?s face it. Everyone has a bad day now and then. It?s easier for some people to lose their cool over others. Nothing?s going to change that. \n\n- Chris \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<AF0E66B0-1330-492B-89B7-D6E212734437@codestud.com>',NULL),('<1081CC4D-5D04-45B5-B4BB-A01EC6148549@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 23:29:43',3600,'2013-06-10 22:29:43',NULL,'[openstack-dev] [keystone] More on inherited domain roles','Hi\n\nSo I ave submitted two new api reviews around this:\n\n1) Defining inherited roles - this is now done on the role def itself, as suggested by David. See: https://review.openstack.org/#/c/29781/12\n2) The two un-implmented user/role apis have been replaces with a more flexible way of listing role-assignments. See:https://review.openstack.org/#/c/32394/2\n\nI\'d like to push to get this nailed asap, so we can have a  shot at getting the code in!\n\nBoth of these extensions are designed to give us the option to to expand this support for inheritance to all domains in the future if we chose.\n\nHenry\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130610/99b1ea37/attachment.html>\n\n',NULL,NULL),('<1082092789.1713882.1413450115958.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 11:01:55',7200,'2014-10-16 09:01:55',NULL,'[openstack-dev] [Nova] Automatic evacuate','\n> >> This still doesn\'t do away with the requirement to reliably detect\n> >> node failure, and to fence misbehaving nodes. Detecting that a node\n> >> has failed, and fencing it if unsure, is a prerequisite for any\n> >> recovery action. So you need Corosync/Pacemaker anyway.\n> >\n> > Obviously, yes.  My post covered all of that directly ... the tagging\n> > bit was just additional input into the recovery operation.\n> \n> This is essentially why I am saying using the Pacemaker stack is the\n> smarter approach than hacking something into Ceilometer and Heat. You\n> already need Pacemaker for service availability (and all major vendors\n> have adopted it for that purpose), so a highly available cloud that\n> does *not* use Pacemaker at all won\'t be a vendor supported option for\n> some time. So people will already be running Pacemaker ? then why not\n> use it for what it\'s good at?\n\nI may be missing something, but Pacemaker will only provide monitoring of your compute node, right? I think the advantage you would get by using something like Heat is having an instance agent and provide monitoring of your client service, instead of just knowing the status of your hypervisor. Hosts can fail, but there is another array of failures that you can\'t handle with the global deployment monitoring.\n\n-- \nThomas\n\n\n','<CAPUexz85Hrefr2r6KRyiPMy1eFnpsvWVvuugWwu2EdbtZbhUSQ@mail.gmail.com>',NULL),('<1082344967.15218367.1372106646195.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 16:44:06',-14400,'2013-06-24 20:44:06',NULL,'[openstack-dev] resize confirm broken on XenServer','Just started seeing these in SmokeStack:\n\nhttps://bugs.launchpad.net/nova/+bug/1194264\n\nI pushed a revert which should fix the issue:\n\nhttps://review.openstack.org/#/c/34256/\n\nDan\n\n\n','<1693025656.15217975.1372106611867.JavaMail.root@redhat.com>',NULL),('<108238636.58966444.1395934079855.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 08:27:59',-25200,'2014-03-27 15:27:59',NULL,'[openstack-dev] [Congress] Policy types','Hi Prabhakar,\n\nI looked into this a while back.  pydatalog is a cool project, and I\'d like to find time to study some of its algorithms and architecture a bit more.  \n\nThe reason we rolled our own version of Datalog is that we knew we\'d want the freedom to try out non-standard Datalog algorithms, and there are algorithms we will likely need that aren\'t usually included (query rewriting, skolemization, conversion to DNF, etc.).  I suppose we could have modified pydatalog, but given that it is basically an extension to Python, it seemed there would be significant overhead in figuring out the code, making sure to keep our changes compatible with the old, etc.  Rolling our own gives us the freedom to build exactly what we need with minimal distractions, which is important since we won\'t really know what we need until we start getting feedback from users.  \n\nBut like I said, there are probably some good ideas in there, so if the way they deal with builtins is useful to us, great!  I\'d just keep in mind that the benefit of using Datalog instead of Python is mainly that it *limits* what policy authors can say (without limiting it too much).  \n\nTim\n\n----- Original Message -----\n| From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Wednesday, March 26, 2014 9:04:22 AM\n| Subject: Re: [openstack-dev] [Congress] Policy types\n| \n| Hi Tim, All,\n|  \n| As I was preparing the background for the proposal for the\n| __Congress_builtins__,\n| came across this link which uses Datalog with Python, and provides\n| data integration facilities through SQLAlchemy.  The tool seems to have been\n| used (from the web page claim) in production:\n| Just want to run it by everyone to see if this is connected or useful in our\n| builtin\n| capability, and anything we can glean from it:\n|  \n| https://urldefense.proofpoint.com/v1/url?u=https://pypi.python.org/pypi/pyDatalog&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=6028d309c9c709635828e7dd33c3f614db1b6989544e05ad6a21da2e646144fe\n| \n|  https://urldefense.proofpoint.com/v1/url?u=https://sites.google.com/site/pydatalog/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=fb152fdc60b5925bb47145dd54973b8184a2b47fb51c28cc86afd6ecbe02b2c5\n|  \n| https://urldefense.proofpoint.com/v1/url?u=https://sites.google.com/site/pydatalog/home/datalog-applications&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=a4cb6eed4bf9d7d0a0bfa811c3c8d72f64b973924697f0e5e9e00681403a7664\n|  \n| Thanks,\n|  \n| Prabhakar\n|  \n| > Date: Tue, 18 Mar 2014 12:56:10 -0700\n| > From: thinrichs at vmware.com\n| > To: openstack-dev at lists.openstack.org\n| > CC: rajdeepd at vmware.com\n| > Subject: Re: [openstack-dev] [Congress] Policy types\n| > \n| > Hi Prabhakar,\n| > \n| > Found time for a more detailed response.  Comments are inline.\n| > \n| > Tim\n| > \n| > ----- Original Message -----\n| > | From: \"Tim Hinrichs\" <thinrichs at vmware.com>\n| > | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | <openstack-dev at lists.openstack.org>\n| > | Sent: Tuesday, March 18, 2014 9:31:34 AM\n| > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | \n| > | Hi Prabhakar,\n| > | \n| > | No IRC meeting this week.  Our IRC is every *other* week, and we had it\n| > | last\n| > | week.\n| > | \n| > | Though there\'s been enough activity of late that maybe we should consider\n| > | making it weekly.\n| > | \n| > | I\'ll address the rest later.\n| > | \n| > | Tim\n| > | \n| > | ----- Original Message -----\n| > | | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | | <openstack-dev at lists.openstack.org>\n| > | | Sent: Monday, March 17, 2014 7:45:53 PM\n| > | | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | \n| > | | Hi Tim,\n| > | |  \n| > | | Definitely would like to learn more about the Data Integration\n| > | | component\n| > | | and how best to contribute. Can\'t find it in the latest git, perhaps we\n| > | | can\n| > | | discuss during the meeting tomorrow. Where can I find some code and/or\n| > | | document?\n| > \n| > There are no docs yet, and the only code in git is a quick-and-dirty\n| > ActiveDirectory integration.  But conceptually there are two pieces of the\n| > data integration story.\n| > \n| > 1. We\'re representing the data stored in each cloud service (that is\n| > pertinent to policy) as a collection of TABLES.  Each table is a\n| > collection of rows that all have the same number of columns.  Each value\n| > in the table is a scalar (number or string).\n| > \n| > If you look at the last IRC, Rajdeep has started working on translating\n| > Neutron data into this table format.  There are a couple of emails on the\n| > mailing list as well where we had some discussion.  Here\'s his change set.\n| > \n| > https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/77835/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=7ca1c47ce75bd3fd3a4f5792d43bd3f1a74209eae6ea8e41f45aa0832e53c7e4\n| > \n| > 2. The policy engine will need to ask for the contents of tables (or\n| > updates to tables).  Or have the contents/updates pushed to it\n| > periodically.  The infrastructure for doing this is what Peter (pballand)\n| > volunteered to do in IRC last week.  Let\'s wait on this to see what he has\n| > to say.\n| > \n| > \n| > \n| > | |  \n| > | | I like the idea of using an \'evauate\' wrapper.  And the idea of a\n| > | | builtin\n| > | | library of functions.  Having strict rules for builtins and an evaluate\n| > | | wrapper\n| > | | to do type checking (primitive or builtin) and so on reduces the silent\n| > | | errors or weird outcomes.\n| > | |  \n| > | | I also agree, raw python using methods like \'calleable\' (or other ways\n| > | | of checking if the function can be called in python) may not always\n| > | | give\n| > | | definitive answers. Even the definition of callable says, that a True\n| > | | only\n| > | | says that the object \'appears\' calleable.\n| > | |  \n| > | | So silent and weird problems are possible if we try to execute. On the\n| > | | other\n| > | | hand,\n| > | | if we are looking at module which contains only user defined functions\n| > | | or\n| > | | builtine\n| > | | , i.e., there  are strict rules to what exactly constitute\n| > | | allowed-functions,\n| > | | then there\n| > | | is a higher likelihood that it is correct.  But still a likelihood.\n| > \n| > Agreed: errors will always be possible.  The policy engine will treat them\n| > as failures (i.e. won\'t \"re-throw\" the error), so we just want to help the\n| > policy-writer as much as we can.\n| > \n| > | |  \n| > | | I like the \'evaluate\' idea which could do the checking within\n| > | | to make sure the function is indeed calleable, and silent and weird\n| > | | side\n| > | | effects\n| > | | are filtered inside the \'evaluate\'. In addition, it can do checking if\n| > | | it\n| > | | is\n| > | | a  primitive or some other valid format. Needs more thought on this.\n| > | |  \n| > | | Let\'s discuss implementation paths if possible at the meeting. Would\n| > | | like\n| > | | to\n| > | | carve out a small implementation goal either in the \'data integration\'\n| > | | line\n| > | | or\n| > | | the discussion above.\n| > \n| > \n| > Great!\n| > \n| > One option is to coordinate with rajdeep and see if there\'s an OS component\n| > that you\'d like to try to turn into tables.  His code is an example of\n| > what you\'d be writing.\n| > \n| > Or you could put together a proposal for adding Python builtins to the\n| > policy engine.  One thing to think about is that we\'d want to make it easy\n| > to add additional builtins.  We\'d also need to figure out what the syntax\n| > would look like from the policy-writer\'s point of view.  Here I\'ve seen\n| > two options:\n| > \n| > // +, *, and lt are builtins\n| > p(x, y, z) :- q(x), r(z) (3*x)+2=y, lt(y, z)\n| > \n| > // builtins are forced to look like any other table.\n| > p(x, y, z) :- q(x), r(z), *(3, x, w), +(w, 2, y), lt(y, z)\n| > \n| > \n| > The latter is a bit clunky, but it makes it easier to implement the policy\n| > engine.\n| > \n| > Tim\n| > \n| >    \n| > \n| > | |  \n| > | | Prabhakar\n| > | |  \n| > | |  \n| > | |  \n| > | | \n| > | |  \n| > | | > Date: Mon, 17 Mar 2014 08:57:05 -0700\n| > | | > From: thinrichs at vmware.com\n| > | | > To: openstack-dev at lists.openstack.org\n| > | | > Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > \n| > | | > Hi Prabhakar,\n| > | | > \n| > | | > One big piece we\'re missing in terms of code right now is the Data\n| > | | > Integration component.  The job of this component is to integrate\n| > | | > data\n| > | | > sources available in the cloud so that tables like\n| > | | > nova:virtual_machine,\n| > | | > neutron:owner, etc. reflect the information stored in Nova, Neutron,\n| > | | > etc.\n| > | | > Rajdeep is making progress on that (he\'s got some code up on review\n| > | | > that\n| > | | > we\'re iterating on), and Peter had worked on integrating AD a while\n| > | | > back.\n| > | | > \n| > | | > Typically I\'ve seen the Python functions (which I usually call\n| > | | > \'builtins\')\n| > | | > integrated into a Datalog system have explicit declarations (e.g.\n| > | | > inputs,\n| > | | > outputs, etc.).  This is good if we need to do deeper analysis of the\n| > | | > policy (which is one of the reasons to use a policy language) and\n| > | | > typically requires information about how that builtin works.\n| > | | > \n| > | | > I dug through some old (Lisp) code to see how I\'ve done this in the\n| > | | > past.\n| > | | > \n| > | | > // (defbuiltin <datalog-name> <lisp-function> <list of types of args>\n| > | | > <list\n| > | | > of types of returns> [<internal>])\n| > | | > (defbuiltin plus + (integer integer) integer)\n| > | | > (defbuiltin minus - (integer integer) integer)\n| > | | > (defbuiltin times * (integer integer) integer)\n| > | | > (defbuiltin div (lambda (x y) (floor (/ x y))) (integer integer)\n| > | | > integer)\n| > | | > (defbuiltin lt numlessp (integer integer) nil)\n| > | | > (defbuiltin lte numleqp (integer integer) nil)\n| > | | > (defbuiltin gte numgeqp (integer integer) nil)\n| > | | > (defbuiltin gt numgreaterp (integer integer) nil)\n| > | | > \n| > | | > But maybe you\'re right in that we could do away with these explicit\n| > | | > declarations and just assume that everything that (i) is calleable,\n| > | | > (ii)\n| > | | > not managed by the Data Integration component, and (iii) does not\n| > | | > appear\n| > | | > in the head of a rule is a builtin.  My only worry is that I could\n| > | | > imagine\n| > | | > silent and weird problems showing up, e.g. someone forgot to define a\n| > | | > table with rules and there happens to be a function in Python by that\n| > | | > name.  Or someone supplies the wrong number of arguments, and we just\n| > | | > get\n| > | | > an error from Python, which we\'d have no direct way to communicate to\n| > | | > the\n| > | | > policy-writer, i.e. there\'s no compile-time argument-length checking.\n| > | | > \n| > | | > The other thing I\'ve seen done is to have a single builtin \'evaluate\'\n| > | | > that\n| > | | > lets us call an arbitrary Python function, e.g.\n| > | | > \n| > | | > p(x, y) :- q(x), evaluate(mypyfunc(x), y)\n| > | | > \n| > | | > Then we wouldn\'t need to declare the functions.  Errors would still\n| > | | > be\n| > | | > silent.  But it would be clear whether we were using a Python\n| > | | > function or\n| > | | > not.\n| > | | > \n| > | | > Thoughts?\n| > | | > Tim\n| > | | > \n| > | | > \n| > | | > \n| > | | > \n| > | | > ----- Original Message -----\n| > | | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | To: \"OpenStack Development Mailing List (not for usage questions)\"\n| > | | > | <openstack-dev at lists.openstack.org>\n| > | | > | Sent: Saturday, March 15, 2014 8:28:27 PM\n| > | | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | \n| > | | > | \n| > | | > | \n| > | | > | Hi Tim,\n| > | | > | \n| > | | > | Here is a small change I wanted to try in runtime.py\n| > | | > | It may already exist in MaterializedViewTheory, but wasn\'t clear to\n| > | | > | me.\n| > | | > | Checking to see if this is something that:1. makes sense 2. already\n| > | | > | exists\n| > | | > | 3. worth implementing? in that order.\n| > | | > | \n| > | | > | Let\'s take the example from private_public_network.classify\n| > | | > | \n| > | | > | error(vm) :- nova:virtual_machine(vm), nova:network(vm, network),\n| > | | > | not neutron:public_network(network),\n| > | | > | neutron:owner(network, netowner), nova:owner(vm, vmowner), not\n| > | | > | same_group(netowner, vmowner)\n| > | | > | \n| > | | > | same_group(user1, user2) :- cms:group(user1, group),\n| > | | > | cms:group(user2,\n| > | | > | group)\n| > | | > | \n| > | | > | nova:virtual_machine(\"vm1\")\n| > | | > | nova:virtual_machine(\"vm2\")\n| > | | > | nova:virtual_machine(\"vm3\")\n| > | | > | nova:network(\"vm1\", \"net_private\")\n| > | | > | nova:network(\"vm2\", \"net_public\")\n| > | | > | neutron:public_network(\"net_public\")\n| > | | > | nova:owner(\"vm1\", \"tim\")\n| > | | > | nova:owner(\"vm2\", \"pete\")\n| > | | > | nova:owner(\"vm3\", \"pierre\")\n| > | | > | neutron:owner(\"net_private\", \"martin\")\n| > | | > | \n| > | | > | \n| > | | > | In this example, if as in Scenario 1:\n| > | | > | \n| > | | > | Cloud services at our disposal:\n| > | | > | nova:virtual_machine(vm)\n| > | | > | nova:network(vm, network)\n| > | | > | nova:owner(vm, owner)\n| > | | > | neutron:public_network(network)\n| > | | > | neutron:owner(network, owner)\n| > | | > | cms:group(user, group)\n| > | | > | \n| > | | > | are all python functions called through some nova/neutron api,\n| > | | > | then, we just execute them to get a true/false value in runtime.py\n| > | | > | They should be first checked to make sure they are python functions\n| > | | > | and\n| > | | > | not condition primitives using \'callable\' and os.dir or some such\n| > | | > | combination.\n| > | | > | \n| > | | > | If not, and they are assertions made in the file, not directly\n| > | | > | related to OS\n| > | | > | state, then in Scenario 2\n| > | | > | \n| > | | > | nova:owner(\"vm1\", \"tim\")\n| > | | > | nova:owner(\"vm2\", \"pete\")\n| > | | > | nova:owner(\"vm3\", \"pierre\")\n| > | | > | \n| > | | > | Are assertions made in the file. In a dynamic environment,\n| > | | > | a python function could query an OS client to actually find the\n| > | | > | current owner,\n| > | | > | since some other OS command could have been used to change the\n| > | | > | owner\n| > | | > | without an entry being made in this file, i.e., without explicitly\n| > | | > | informing Congres.\n| > | | > | This may not occur currently with vms, but may be implemented\n| > | | > | in a future release. Similar other examples are possible\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=https://ask.openstack.org/en/question/5582/how-to-change-ownership-between-tenants-of-volume/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=6da252434cf8f03e99ab04dcc042d3eb646b7c4ea0390b9d0b96f04534d05574\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/cinder/%2Bspec/volume-transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=dd07239a911392850af6d2ea72ecce3ea39997c1c93c7f235868a4919144296e\n| > | | > | \n| > | | > | \n| > | | > | So, I was thinking that python_nova_owner(\"vm1\"), is first checked\n| > | | > | as\n| > | | > | a python\n| > | | > | function which calls the appropriate OS client to check the current\n| > | | > | owner.\n| > | | > | As in nova:owner(\"vm1\", python_nova_owner(\"vm1\"))\n| > | | > | \n| > | | > | So, in runtime.py, in either scenario, condition primitives are\n| > | | > | first\n| > | | > | checked to\n| > | | > | see if it they are callable\n| > | | > | python functions (by using python \'callable\' with os.dir). In which\n| > | | > | case, it is\n| > | | > | executed to get the name of the owner. All non-callable primitives\n| > | | > | are assumed\n| > | | > | assumed to be congress and/or datalog primitives, and unified\n| > | | > | through\n| > | | > | the\n| > | | > | Materializedviewtheory.\n| > | | > | \n| > | | > | \n| > | | > | Thanks,\n| > | | > | \n| > | | > | \n| > | | > | > Date: Thu, 13 Mar 2014 08:55:24 -0700\n| > | | > | > From: thinrichs at vmware.com\n| > | | > | > To: openstack-dev at lists.openstack.org\n| > | | > | > Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > \n| > | | > | > Hi Prabhakar,\n| > | | > | > \n| > | | > | > I\'m not sure the functionality is split between \'policy\' and\n| > | | > | > \'server\' as cleanly as you describe.\n| > | | > | > \n| > | | > | > The \'policy\' directory contains the Policy Engine. At its core,\n| > | | > | > the\n| > | | > | > policy engine has a generic Datalog implementation that could\n| > | | > | > feasibly be used by other OS components. (I don\'t want to think\n| > | | > | > about pulling it out into Oslo though. There are just too many\n| > | | > | > other things going on and no demand yet.) But there are also\n| > | | > | > Congress-specific things in that directory, e.g. the class\n| > | | > | > Runtime\n| > | | > | > in policy/runtime.py will be the one that we hook up external API\n| > | | > | > calls to.\n| > | | > | > \n| > | | > | > The \'server\' directory contains the code for the API web server\n| > | | > | > that calls into the Runtime class.\n| > | | > | > \n| > | | > | > So if you\'re digging through code, I\'d suggest focusing on the\n| > | | > | > \'policy\' directory and looking at compile.py (responsible for\n| > | | > | > converting Datalog rules written as strings into an internal\n| > | | > | > representation) and runtime.py (responsible for everything else).\n| > | | > | > The docs I mentioned in the IRC should have a decent explanation\n| > | | > | > of the functions in Runtime that the API web server will hook\n| > | | > | > into.\n| > | | > | > \n| > | | > | > Be warned though that unless someone raises some serious\n| > | | > | > objections\n| > | | > | > to the proposal that started this thread, we\'ll be removing some\n| > | | > | > of the more complicated functions from Runtime. The compile.py\n| > | | > | > code won\'t change (much). All of the 3 new theories will be\n| > | | > | > instances of MaterializedViewTheory. That\'s also the code that\n| > | | > | > must change to add in the Python functions we talked about (more\n| > | | > | > specifically see MaterializedViewTheory::propagate_rule(), which\n| > | | > | > calls TopDownTheory::top_down_evaluation(), which is what will\n| > | | > | > need modification).\n| > | | > | > \n| > | | > | > Tim\n| > | | > | > \n| > | | > | > \n| > | | > | > \n| > | | > | > \n| > | | > | > ----- Original Message -----\n| > | | > | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | > | To: \"OpenStack Development Mailing List (not for usage\n| > | | > | > | questions)\" <openstack-dev at lists.openstack.org>\n| > | | > | > | Sent: Wednesday, March 12, 2014 1:38:55 PM\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Tim,\n| > | | > | > | \n| > | | > | > | Thanks for your comments.\n| > | | > | > | Would be happy to contribute to the propsal and code.\n| > | | > | > | \n| > | | > | > | The existing code already reflects the thoughts below, and got\n| > | | > | > | me\n| > | | > | > | in the line of ideas. Please orrect me if I am wrong as I am\n| > | | > | > | learning with these discussions:\n| > | | > | > | \n| > | | > | > | One part (reflected by code in \"policy\" directory is the\n| > | | > | > | generic\n| > | | > | > | \"condition-> action engine\" which could take logic primitives\n| > | | > | > | and\n| > | | > | > | (in the future) python functions, evaluate the conditions and\n| > | | > | > | execute the action. This portable core engine be used for any\n| > | | > | > | kind of\n| > | | > | > | policy enforcement\n| > | | > | > | (as by other OS projects), such as for data center monitoring\n| > | | > | > | and\n| > | | > | > | repair,\n| > | | > | > | service level enforcement, compliance policies, optimization\n| > | | > | > | (energy,\n| > | | > | > | performance) etc... at any level of the stack. This core engine\n| > | | > | > | seems\n| > | | > | > | possibly\n| > | | > | > | a combination of logic reasoning/unification and python\n| > | | > | > | function\n| > | | > | > | evaluation, and python code actions.\n| > | | > | > | \n| > | | > | > | Second part (reflected by code in \"server\") are the\n| > | | > | > | applications\n| > | | > | > | for various purposes. These could be project specific, task\n| > | | > | > | specific.\n| > | | > | > | We could add a diverse set of examples. The example I have\n| > | | > | > | worked\n| > | | > | > | with seems closer to compliance (as in net owner, vm owner\n| > | | > | > | check),\n| > | | > | > | and we will add more.\n| > | | > | > | \n| > | | > | > | Prabhakar\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Date: Wed, 12 Mar 2014 12:33:35 -0700\n| > | | > | > | From: thinrichs at vmware.com\n| > | | > | > | To: openstack-dev at lists.openstack.org\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Prabhakar,\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Thanks for the feedback. I\'d be interested to hear what other\n| > | | > | > | policy\n| > | | > | > | types you have in mind.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | To answer your questions...\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | We\'re planning on extending our policy language in such a way\n| > | | > | > | that\n| > | | > | > | you can use Python functions as conditions (\"<atom>\" in the\n| > | | > | > | grammar)\n| > | | > | > | in rules. That\'s on my todo-list but didn\'t mention it\n| > | | > | > | yesterday\n| > | | > | > | as\n| > | | > | > | we were short on time. There will be some syntactic\n| > | | > | > | restrictions\n| > | | > | > | so\n| > | | > | > | that we can properly execute those Python functions (i.e. we\n| > | | > | > | need\n| > | | > | > | to\n| > | | > | > | always be able to compute the inputs to the function). I had\n| > | | > | > | thought\n| > | | > | > | it was just an implementation detail I hadn\'t gotten around to\n| > | | > | > | (all\n| > | | > | > | Datalog implementations I\'ve seen have such things), but it\n| > | | > | > | sounds\n| > | | > | > | like it\'s worth writing up a proposal and sending it around\n| > | | > | > | before\n| > | | > | > | implementing. If that\'s a pressing concern for you, let me know\n| > | | > | > | and\n| > | | > | > | I\'ll bump it up the stack (a little). If you\'d like, feel free\n| > | | > | > | to\n| > | | > | > | draft a proposal (or remind me to do it once in a while).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | As for actions, I typically think of them as API calls to other\n| > | | > | > | OS\n| > | | > | > | components like Nova. But they could just as easily be Python\n| > | | > | > | functions. But I would want to avoid an action that changes\n| > | | > | > | Congress\'s internal data structures directly (e.g. adding a new\n| > | | > | > | policy statement). Such actions have caused trouble in the past\n| > | | > | > | for\n| > | | > | > | policy languages (though for declarative programming languages\n| > | | > | > | like\n| > | | > | > | Prolog they are less problematic). I don\'t think there\'s anyway\n| > | | > | > | we\n| > | | > | > | can stop people from creating such actions, but I think we\n| > | | > | > | should\n| > | | > | > | advocate against them.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Tim\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | | > | > | To: \"OpenStack Development Mailing List (not for usage\n| > | | > | > | questions)\"\n| > | | > | > | <openstack-dev at lists.openstack.org>\n| > | | > | > | Sent: Wednesday, March 12, 2014 11:34:04 AM\n| > | | > | > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi Tim, All,\n| > | | > | > | \n| > | | > | > | I was in the discussion yesterday (kudva), and would like to\n| > | | > | > | start\n| > | | > | > | gradually\n| > | | > | > | contributing to the code base.\n| > | | > | > | \n| > | | > | > | So, this discussion below is based on my limited exploration of\n| > | | > | > | Congress\n| > | | > | > | code, running it. I am trying some small pieces to implement to\n| > | | > | > | familiarize.\n| > | | > | > | Please view it as such. As I start adding code, I am sure, my\n| > | | > | > | thoughts will\n| > | | > | > | be more evolved.\n| > | | > | > | \n| > | | > | > | I agree with the three types you outline. I also agree that\n| > | | > | > | these\n| > | | > | > | will grow.\n| > | | > | > | We are already thinking of expanding congress for various other\n| > | | > | > | types\n| > | | > | > | of\n| > | | > | > | policies. But those would be a manageable start.\n| > | | > | > | \n| > | | > | > | Regarding the comment below. I was wondering if all conditions,\n| > | | > | > | and\n| > | | > | > | actions\n| > | | > | > | could be both:\n| > | | > | > | 1. python functions (for conditions they eval\n| > | | > | > | 2. policy primitives.\n| > | | > | > | \n| > | | > | > | The advantage of 1, is that it is just executed and a True or\n| > | | > | > | False\n| > | | > | > | returned\n| > | | > | > | by Python for conditions. For actions, python functions are\n| > | | > | > | executed\n| > | | > | > | to respond to conditions.\n| > | | > | > | This controls the growth of policies and adding more\n| > | | > | > | primitives,\n| > | | > | > | and\n| > | | > | > | makes it flexible (say\n| > | | > | > | to use alarms, monitors, os clients, nova actions etc).\n| > | | > | > | \n| > | | > | > | The advantage of 2, is the ability to use unification (as in\n| > | | > | > | unify.py) and do\n| > | | > | > | some logic reduction. This gives us the full strength of\n| > | | > | > | extensive\n| > | | > | > | and mature\n| > | | > | > | logic reasoning and reduction methods.\n| > | | > | > | \n| > | | > | > | One possibility is that it checks which one the two it is and\n| > | | > | > | does\n| > | | > | > | the appropriate\n| > | | > | > | evaluation for condition and action.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | >There are drawbacks to this proposal as well.\n| > | | > | > | >- We will have 3 separate policies that are conceptually very\n| > | | > | > | >similar. As the policies grow larger, it will become\n| > | | > | > | >>increasingly\n| > | | > | > | >difficult to keep the policies synchronized. This problem can\n| > | | > | > | >be\n| > | | > | > | >mitigated to some extent by having >all 3 share a library of\n| > | | > | > | >policy\n| > | | > | > | >statements that they all apply in different ways (and such a\n| > | | > | > | >library mechanism is >already implemented).\n| > | | > | > | >- As cloud services change their behavior, policies may need\n| > | | > | > | >to\n| > | | > | > | >be\n| > | | > | > | >re-written. For example, right now Nova does >not consult\n| > | | > | > | >Congress\n| > | | > | > | >before creating a VM; thus, to enforce policy surrounding VMs,\n| > | | > | > | >the\n| > | | > | > | >best we could do is >write a Condition-Action policy that\n| > | | > | > | >adjusts\n| > | | > | > | >VM configuration when it learns about new VMs being created.\n| > | | > | > | >If\n| > | | > | > | >we\n| > | | > | > | >>later make Nova consult with Congress before creating a VM,\n| > | | > | > | >>we\n| > | | > | > | >need to write an Access-control policy that puts >the proper\n| > | | > | > | >controls in place.\n| > | | > | > | Thanks,\n| > | | > | > | \n| > | | > | > | Prabhakar Kudva\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Date: Wed, 12 Mar 2014 10:05:23 -0700\n| > | | > | > | From: thinrichs at vmware.com\n| > | | > | > | To: openstack-dev at lists.openstack.org\n| > | | > | > | Subject: [openstack-dev] [Congress] Policy types\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Hi all,\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | We started a discussion on IRC yesterday that I\'d like to\n| > | | > | > | continue.\n| > | | > | > | The main question is what kind of policy does a Congress user\n| > | | > | > | actually write? I can see three options. The first two focus on\n| > | | > | > | actions (API calls that make changes to the state of the cloud)\n| > | | > | > | and\n| > | | > | > | the last focuses on just the cloud state. (By \"state of the\n| > | | > | > | cloud\" I\n| > | | > | > | mean all the information Congress can see about all the cloud\n| > | | > | > | services it is managing, e.g. all the information we can get\n| > | | > | > | through\n| > | | > | > | API calls to Nova, Neutron, Cinder, Heat, ...).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | 1) Access Control (e.g. Linux, XACML, AD): which *actions* can\n| > | | > | > | be\n| > | | > | > | performed by other cloud services (for each state of the cloud)\n| > | | > | > | 2) Condition Action: which *actions* Congress should execute\n| > | | > | > | (for\n| > | | > | > | each state of the cloud)\n| > | | > | > | 3) Classification (currently supported in Congress): which\n| > | | > | > | *states*\n| > | | > | > | violate real-world policy. [For those of you who have read\n| > | | > | > | docs/white-papers/etc. I\'m using \"Classification\" in this note\n| > | | > | > | to\n| > | | > | > | mean the combination of the current \"Classification\" and\n| > | | > | > | \"Action\n| > | | > | > | Description\" policies.]\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | The important observation is that each of these policies could\n| > | | > | > | contain different information from each of the others.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Access Control vs Condition Action. The Access Control policy\n| > | | > | > | tells\n| > | | > | > | *other cloud services* which actions they are *allowed* to\n| > | | > | > | execute.\n| > | | > | > | The Condition Action policy tells *Congress* which actions it\n| > | | > | > | *must*\n| > | | > | > | execute. These policies differ because they constrain different\n| > | | > | > | sets\n| > | | > | > | of cloud services.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Access Control vs. Classification. The Access Control policy\n| > | | > | > | might\n| > | | > | > | permit some users to violate the Classification policy in some\n| > | | > | > | situations (e.g. to fix violation A, we might need to cause\n| > | | > | > | violation B before eliminating both). These policies differ\n| > | | > | > | because\n| > | | > | > | a violation in one policy might be be a violation in the other.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Classification vs. Condition Action. The Classification\n| > | | > | > | policy\n| > | | > | > | might imply which actions *could* eliminate a given violation,\n| > | | > | > | but\n| > | | > | > | the Condition Action policy would dictate which of those\n| > | | > | > | actions\n| > | | > | > | *should* be executed (e.g. the Classification policy might tell\n| > | | > | > | us\n| > | | > | > | that disconnecting a network and deleting a VM would both\n| > | | > | > | eliminate\n| > | | > | > | a particular violation, but the Condition Action policy would\n| > | | > | > | tell\n| > | | > | > | us which to choose). And the Condition Action policy need not\n| > | | > | > | eliminate all the violations present in the Classification\n| > | | > | > | policy.\n| > | | > | > | Again these policies differ because a violation in one policy\n| > | | > | > | might\n| > | | > | > | not be a violation in the other.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | I\'m proposing that for the first release of Congress we support\n| > | | > | > | all 3\n| > | | > | > | of these policies. When a user inserts/deletes a policy\n| > | | > | > | statement,\n| > | | > | > | she chooses which policy it belongs to. All would be written in\n| > | | > | > | basically the same syntax but would be used in 3 different\n| > | | > | > | scenarios:\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Prevention: If a component wants to consult Congress before\n| > | | > | > | taking\n| > | | > | > | action to see if that action is allowed, Congress checks the\n| > | | > | > | Access\n| > | | > | > | Control policy.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Reaction: When Congress learns of a change in the cloud\'s\n| > | | > | > | state, it\n| > | | > | > | checks the Condition Action policy to see which actions should\n| > | | > | > | be\n| > | | > | > | executed (if any).\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | - Monitoring: If a user wants to simply check if the cloud\'s\n| > | | > | > | state is\n| > | | > | > | in compliance and monitor compliance over time, she writes and\n| > | | > | > | queries the Classification policy.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | There are several benefits to this proposal.\n| > | | > | > | - It allows users to choose any of the policy types, if they\n| > | | > | > | only\n| > | | > | > | want one of them. From our discussions with potential users,\n| > | | > | > | most\n| > | | > | > | seem to want one of these 3 policy types (and are uninterested\n| > | | > | > | in\n| > | | > | > | the others).\n| > | | > | > | - It makes the introduction to Congress relatively simple. We\n| > | | > | > | describe 3 different uses of policy (Prevention, Reaction,\n| > | | > | > | Monitoring) and then explain which policy to use in which case.\n| > | | > | > | \n| > | | > | > | - This allows us to focus on implementing a single\n| > | | > | > | policy-engine\n| > | | > | > | technology (a Datalog policy language and evaluation\n| > | | > | > | algorithms),\n| > | | > | > | which gives us the opportunity to make it solid.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | There are drawbacks to this proposal as well.\n| > | | > | > | - We will have 3 separate policies that are conceptually very\n| > | | > | > | similar. As the policies grow larger, it will become\n| > | | > | > | increasingly\n| > | | > | > | difficult to keep the policies synchronized. This problem can\n| > | | > | > | be\n| > | | > | > | mitigated to some extent by having all 3 share a library of\n| > | | > | > | policy\n| > | | > | > | statements that they all apply in different ways (and such a\n| > | | > | > | library\n| > | | > | > | mechanism is already implemented).\n| > | | > | > | - As cloud services change their behavior, policies may need to\n| > | | > | > | be\n| > | | > | > | re-written. For example, right now Nova does not consult\n| > | | > | > | Congress\n| > | | > | > | before creating a VM; thus, to enforce policy surrounding VMs,\n| > | | > | > | the\n| > | | > | > | best we could do is write a Condition-Action policy that\n| > | | > | > | adjusts\n| > | | > | > | VM\n| > | | > | > | configuration when it learns about new VMs being created. If we\n| > | | > | > | later make Nova consult with Congress before creating a VM, we\n| > | | > | > | need\n| > | | > | > | to write an Access-control policy that puts the proper controls\n| > | | > | > | in\n| > | | > | > | place.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | These drawbacks were the original motivation for supporting\n| > | | > | > | only\n| > | | > | > | the\n| > | | > | > | Classification policy and attempting to derive the Access\n| > | | > | > | Control\n| > | | > | > | and Condition Action policies from it. But given that we can\'t\n| > | | > | > | always derive the proper Access Control and Condition Action\n| > | | > | > | policies from the Classification policy, we will eventually\n| > | | > | > | need\n| > | | > | > | support for all 3. In addition, the technical complexity of\n| > | | > | > | supporting all 3 is much lower than supporting just the\n| > | | > | > | Classification policy and deriving the others.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | I\'ll stop there for now.\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | Comments, thoughts, questions?\n| > | | > | > | Tim\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | _______________________________________________ OpenStack-dev\n| > | | > | > | mailing\n| > | | > | > | list OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | > | _______________________________________________\n| > | | > | > | OpenStack-dev mailing list\n| > | | > | > | OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=4QiYdqIhBIaa%2FY1uu8c2Wq%2F92NWfXkaUvJLsncl4ccI%3D%0A&s=a18a843e031ec87277e04caa8396b5cf71bc7a2e5252247084abacf0b9e51409\n| > | | > | > | \n| > | | > | > | \n| > | | > | > | \n| > | | > | > | _______________________________________________ OpenStack-dev\n| > | | > | > | mailing\n| > | | > | > | list OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | > | _______________________________________________\n| > | | > | > | OpenStack-dev mailing list\n| > | | > | > | OpenStack-dev at lists.openstack.org\n| > | | > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=SMheq3u5q7x9wYFjxnNx6C%2F9lZgxydUP452rygu28MY%3D%0A&s=5c1cf9f3a5adc86ce59d2bf582891e0da033394f43a6ffa72127843c8cf78f80\n| > | | > | > | \n| > | | > | > \n| > | | > | > _______________________________________________\n| > | | > | > OpenStack-dev mailing list\n| > | | > | > OpenStack-dev at lists.openstack.org\n| > | | > | > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | | > | \n| > | | > | _______________________________________________\n| > | | > | OpenStack-dev mailing list\n| > | | > | OpenStack-dev at lists.openstack.org\n| > | | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=QvFCD7z%2FP29TE6KUtbaOJzeGxlOtxzdiGCdlm1LkcOY%3D%0A&s=8f7ec7cc8312dd84709bc99d725e9934b5403a43e8f1f2d02c638e504009ea71\n| > | | > | \n| > | | > \n| > | | > _______________________________________________\n| > | | > OpenStack-dev mailing list\n| > | | > OpenStack-dev at lists.openstack.org\n| > | | > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | |  		 	   		  \n| > | | _______________________________________________\n| > | | OpenStack-dev mailing list\n| > | | OpenStack-dev at lists.openstack.org\n| > | | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883\n| > | |\n| > \n| > _______________________________________________\n| > OpenStack-dev mailing list\n| > OpenStack-dev at lists.openstack.org\n| > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=c879337f1ccc468fda5b5ff7083a06047d4d202298247be87e4257a84312d77d\n|  		 	   		  \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=WvQzzQA4hxW34TMc13h1FgKQQSxHsa1RgBpgfI5lO2U%3D%0A&s=c879337f1ccc468fda5b5ff7083a06047d4d202298247be87e4257a84312d77d\n| \n\n\n','<BLU170-W63A788D2F7134F0A1077A3D5640@phx.gbl>',NULL),('<1085035552.414.1355357675395.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-13 00:14:35',0,'2012-12-13 00:14:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #73','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/73/>\n\n------------------------------------------\n[...truncated 10864 lines...]\n++ field=\'$2\'\n++ echo \'| 1  | m1.tiny   | 512       | 0    | 0         |      | 1     | 1.0         | True      | {}          |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ INSTANCE_TYPE=1\n+ [[ -z 1 ]]\n+ NAME=ex-vol\n++ nova boot --flavor 1 --image d45c8c55-f718-4208-a208-14ef671068ee ex-vol --security_groups=vol_secgroup\n++ grep \' id \'\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| id                     | 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ VM_UUID=89e5888a-3a49-4cac-8a0f-c3715c72aeb6\n+ die_if_not_set VM_UUID \'Failure launching ex-vol\'\n+ local exitcode=0\n+ set +o xtrace\n+ timeout 60 sh -c \'while ! nova show 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 | grep status | grep -q ACTIVE; do sleep 1; done\'\n++ nova show 89e5888a-3a49-4cac-8a0f-c3715c72aeb6\n++ grep \'private network\'\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| private network        | 10.1.0.3                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.3\n+ die_if_not_set IP \'Failure retrieving IP address\'\n+ local exitcode=0\n+ set +o xtrace\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ \'[\' False = False \']\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.3; do sleep 1; done\'\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n64 bytes from 10.1.0.3: icmp_req=1 ttl=64 time=4.66 ms\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 4.664/4.664/4.664/0.000 ms\n++ openssl rand -hex 4\n+ VOL_NAME=myvol-c46ebc8e\n++ nova volume-list\n++ grep myvol-c46ebc8e\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n+ nova volume-create --display_name myvol-c46ebc8e --display_description \'test volume: myvol-c46ebc8e\' 1\n+---------------------+--------------------------------------+\n| Property            | Value                                |\n+---------------------+--------------------------------------+\n| attachments         | []                                   |\n| availability_zone   | nova                                 |\n| created_at          | 2012-12-13T00:12:54.707775           |\n| display_description | test volume: myvol-c46ebc8e          |\n| display_name        | myvol-c46ebc8e                       |\n| id                  | 5a507763-9935-4ae8-b568-2e5c11e622d7 |\n| metadata            | {}                                   |\n| size                | 1                                    |\n| snapshot_id         | None                                 |\n| status              | creating                             |\n| volume_type         | None                                 |\n+---------------------+--------------------------------------+\n+ [[ 0 != 0 ]]\n++ date +%s\n+ start_time=1355357574\n+ timeout 60 sh -c \'while ! nova volume-list | grep myvol-c46ebc8e | grep available; do sleep 1; done\'\n| 5a507763-9935-4ae8-b568-2e5c11e622d7 | available | myvol-c46ebc8e | 1    | None        |             |\n++ date +%s\n+ end_time=1355357576\n+ echo \'Completed volume-create in 2 seconds\'\nCompleted volume-create in 2 seconds\n++ nova volume-list\n++ grep myvol-c46ebc8e\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 5a507763-9935-4ae8-b568-2e5c11e622d7 | available | myvol-c46ebc8e | 1    | None        |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=5a507763-9935-4ae8-b568-2e5c11e622d7\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for myvol-c46ebc8e\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1355357577\n+ nova volume-attach 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 5a507763-9935-4ae8-b568-2e5c11e622d7 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| id       | 5a507763-9935-4ae8-b568-2e5c11e622d7 |\n| serverId | 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 |\n| volumeId | 5a507763-9935-4ae8-b568-2e5c11e622d7 |\n+----------+--------------------------------------+\n+ timeout 60 sh -c \'while ! nova volume-list | grep myvol-c46ebc8e | grep in-use; do sleep 1; done\'\n| 5a507763-9935-4ae8-b568-2e5c11e622d7 | in-use | myvol-c46ebc8e | 1    | None        | 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 |\n++ date +%s\n+ end_time=1355357582\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ nova volume-list\n++ grep myvol-c46ebc8e\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 5a507763-9935-4ae8-b568-2e5c11e622d7 | in-use | myvol-c46ebc8e | 1    | None        | 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=89e5888a-3a49-4cac-8a0f-c3715c72aeb6\n+ die_if_not_set VOL_ATTACH \'Failure retrieving myvol-c46ebc8e status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 != 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 ]]\n++ date +%s\n+ start_time=1355357582\n+ nova volume-detach 89e5888a-3a49-4cac-8a0f-c3715c72aeb6 5a507763-9935-4ae8-b568-2e5c11e622d7\n+ timeout 60 sh -c \'while ! nova volume-list | grep myvol-c46ebc8e | grep available; do sleep 1; done\'\n| 5a507763-9935-4ae8-b568-2e5c11e622d7 | available | myvol-c46ebc8e | 1    | None        |             |\n++ date +%s\n+ end_time=1355357591\n+ echo \'Completed volume-detach in 9 seconds\'\nCompleted volume-detach in 9 seconds\n++ date +%s\n+ start_time=1355357591\n+ nova volume-delete 5a507763-9935-4ae8-b568-2e5c11e622d7\n+ timeout 60 sh -c \'while ! nova volume-list | grep myvol-c46ebc8e; do sleep 1; done\'\n| 5a507763-9935-4ae8-b568-2e5c11e622d7 | deleting | myvol-c46ebc8e | 1    | None        |             |\n++ date +%s\n+ end_time=1355357592\n+ echo \'Completed volume-delete in 1 seconds\'\nCompleted volume-delete in 1 seconds\n+ nova delete 89e5888a-3a49-4cac-8a0f-c3715c72aeb6\n+ timeout 60 sh -c \'while nova list | grep -q 89e5888a-3a49-4cac-8a0f-c3715c72aeb6; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\nFAILED euca\n=====================================================================\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/rabbitmq/rabbit at devstack-1355337059-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/rabbitmq/rabbit at devstack-1355337059.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-n-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/73/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1085361186.8674742.1370460923540.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 15:35:23',-14400,'2013-06-05 19:35:23',NULL,'[openstack-dev] Nova RPC regression','\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, June 5, 2013 3:15:57 PM\n> Subject: Re: [openstack-dev] Nova RPC regression\n> \n> On 06/05/2013 02:25 PM, Dan Prince wrote:\n> >>\n> >> Just to follow up.  This was caused by a change triggering a limitation\n> >> in qpid.  This is being tracked at\n> >> https://bugs.launchpad.net/nova/+bug/1175808.  The fix which has already\n> >> merged into oslo is now proposed against Nova.\n> >\n> > Thanks Laski.\n> >\n> > To my knowledge we have nothing gating on qpid. Given it is the prefered\n> > deployment option on some distributions (RHEL for example) it seems\n> > important so perhaps we should?\n> >\n> > SmokeStack uses qpid for some configurations but it isn\'t a gate so this\n> > slipped through the cracks.\n> \n> Did SmokeStack -1 this on checks?\n> \n> I\'ve seen people pretty respectful of SmokeStack -1s on the check side,\n> so as long as it was getting back with results within an hour I think it\n> would cover the case fine.\n\nYes. I knew about this ahead of time. I caught patchset 21. Patchset 22 came in while I was out at dinner. Perhaps I need to be more diligent about highlighting these sorts of failures... but as a non-gate SmokeStack is only so scalable. In general I don\'t mind this sort of thing (I\'m used to it), and we can always do a quick revert... until we can\'t when the patch is like 1500 lines long :(.\n\nI\'m happy enough with the turn around here... just wondering if a slight config change to our upstream gating system might help out here. Right now we already spin up two devstack-gate instances for each zul run (one with quantum, one without). Why not take one these and spin it with a Fedora 18 Qpid setup? Seems like a simple change and we\'d have this covered without too much issue.\n\nDan\n\n> \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51AF8E6D.9040907@dague.net>',NULL),('<1085605165.52.1369982263710.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-31 06:37:43',0,'2013-05-31 06:37:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-quantum-python26-stable-grizzly #51','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/51/changes>\n\n\n\n','<1413866845.50.1369895844399.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1085755770.96.1383891089662.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-08 06:11:29',0,'2013-11-08 06:11:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #54','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/54/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6263e50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6263e50>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f9be50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f9be50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-ce138154-e8cb-4ad5-9325-a1b789619719\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:11:01+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:11:01-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6cc9790>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2e86d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.93 secs:\n    14.97    TestGlanceControl.test_bouncing\n    14.18    TestScrubber.test_delayed_delete\n    13.71    TestGlanceControl.test_reload\n    13.56    TestGlanceControl.test_respawn\n    12.51    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 534.371s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-54\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.YcB7Bn8YQT\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/54\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/54/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise2/54\n[SCP] Copying console log.\n\n\n','<1813520414.93.1383804860806.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1086112040.10.1371795495261.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-21 06:18:15',0,'2013-06-21 06:18:15',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-quantum-stable-grizzly #78','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-quantum-stable-grizzly/78/>\n\n\n\n','<412377390.6.1371708687075.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<108650400.142.1366006033881.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-15 06:07:13',0,'2013-04-15 06:07:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #5','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-15 06:07:08    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:07:08,679 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-15 06:07:08,679 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:07:08,680 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,681 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,682 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-15 06:07:08,683 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-15 06:07:08,684 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-15 06:07:08  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-15 06:07:08,684 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:07:08    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:07:08,686 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,691 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.691036\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.691036\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08,692 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,693 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,693 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,695 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08,696 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.695280\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.695280\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08,697 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,698 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,698 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:07:08,699 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,700 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,702 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08,703 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.701905\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.701905\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08,704 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,705 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,705 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:07:08,706 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,707 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,708 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08,709 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.708826\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.708826\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08,710 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,711 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,712 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:07:08,713 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,714 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,715 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:07:08,717 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:07:08,718 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.717003\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:07:08.717003\', resource_metadata={}) from 0 transformer\n2013-04-15 06:07:08,719 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,720 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08,720 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:07:08,721 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:07:08,722 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:07:08    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.371s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.5\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a46.ga0e15fa\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a310.g0fc0588\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Iu1VGb7SGf\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/5\n[SCP] Copying console log.\n\n\n','<1389816709.131.1365919625942.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<108683333.37.1369549324273.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-26 06:22:04',0,'2013-05-26 06:22:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #237','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/237/>\n\n------------------------------------------\n[...truncated 12587 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for 294b2960b892464182eb67425310d2c6 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:46330\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:46330/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (401) wsgi starting up on http://127.0.0.1:46330/\n\nnova.osapi_compute.wsgi.server: INFO: (401) accepted (\'127.0.0.1\', 36213)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/May/2013 06:16:50] \"GET /v2 HTTP/1.1\" 204 216 0.001047\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-f4555633-eb59-4fd6-8d7a-9f198dbe7ae1</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (401) accepted (\'127.0.0.1\', 36214)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa0e8e50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa0e8e50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:46330/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:46330/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/May/2013 06:16:51] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.250231\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 187bbc72c2bd43bfbee2dba3c804c38a \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:34194\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:34194/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (401) wsgi starting up on http://127.0.0.1:34194/\n\nnova.osapi_compute.wsgi.server: INFO: (401) accepted (\'127.0.0.1\', 44765)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/May/2013 06:16:51] \"GET /v2 HTTP/1.1\" 204 216 0.001111\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-07e8bcda-b588-4801-bbea-58800756ecfb</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (401) accepted (\'127.0.0.1\', 44766)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1516d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1516d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:34194/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     name)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-26 06:16:51 401 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:34194/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/May/2013 06:16:51] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.278514\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.TZ2xF3dvtA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/237\n[SCP] Copying console log.\n\n\n','<1203239152.34.1369462916579.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1087889655.16.1374300928889.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-20 06:15:28',0,'2013-07-20 06:15:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #101','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/101/>\n\n------------------------------------------\n[...truncated 1164 lines...]\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_infinite_child_death\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 267, in test_infinite_child_death\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib64/python2.6/unittest.py\", line 324, in failUnless\n    if not expr: raise self.failureException, msg\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 93.03 secs:\n    26.88    TestScrubber.test_scrubber_app\n    20.98    TestScrubber.test_delayed_delete\n    15.42    TestRootApi.test_version_configurations\n    15.03    TestGlanceControl.test_reload\n    14.71    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 645.216s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.8\ncffi==0.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.101\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.18\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.09.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.37RiGcsddR\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/101\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/101/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1656188749.10.1374214585334.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1088581464.2.1367561225131.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-03 06:07:05',0,'2013-05-03 06:07:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #23','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/23/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-05-03 06:07:00    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:07:00,733 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-03 06:07:00,734 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-03 06:07:00,735 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:07:00,736 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:07:00  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:07:00,736 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:07:00    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:07:00,737 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-03 06:07:00,738 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:07:00,739 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,740 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,744 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.744112\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.744112\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00,745 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,745 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00,746 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,747 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.747068\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.747068\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00,748 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,749 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00,750 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:07:00,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,752 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00,753 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.752679\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.752679\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,755 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00,755 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:07:00,756 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,756 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,757 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00,758 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.757703\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.757703\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00,759 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,759 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00,760 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:07:00,761 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,761 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,763 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:07:00,764 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:07:00,765 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.764182\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:07:00.764182\', resource_metadata={}) from 0 transformer\n2013-05-03 06:07:00,766 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,767 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00,768 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:07:00,769 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:07:00,770 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:07:00    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.123s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.2\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.23\ncliff==1.3.3\ncmd2==0.6.5.1\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a96.gcc938e2\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a491.g8bb1cc2\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.GxUnd4KXOw\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/23\n[SCP] Copying console log.\n\n\n','<18196654.550.1367474785289.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1088779172.403.1367042974437.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:09:34',0,'2013-04-27 06:09:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python27-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal16 in workspace <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/>\nCheckout:periodic-quantum-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 743ca07a:quantal16\nUsing strategy: Default\nLast Built Revision: Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/quantum.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/quantum.git\nCommencing build of Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\nChecking out Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\n[periodic-quantum-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson6014114594784827407.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack quantum\n+ version=27\n+ org=openstack\n+ project=quantum\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.TwylpvgXt7\n+ TMPDIR=/tmp/tmp.TwylpvgXt7\n+ trap \'rm -rf /tmp/tmp.TwylpvgXt7\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack quantum\n+ org=openstack\n+ project=quantum\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' quantum == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.quantum.python27.stable.grizzly.17\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires\',> \'setuptools_git>=0.4\']\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-quantum-python27-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 50847 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-quantum-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal16\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.TwylpvgXt7\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-06-30\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'7e16ae09-b0e1-43c4-86d3-5ca06e2b3039\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'92c234b483504b6dc7bddd9338ad9a60dbb849b8\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal16\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50847 166.78.177.214 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking setuptools-git>=0.4\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement setuptools-git>=0.4\nNo distributions at all found for setuptools-git>=0.4\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.TwylpvgXt7\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<108955668.834916.1391509212685.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 11:20:12',3600,'2014-02-04 10:20:12',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates\n	spec	re-written. RFC','\n> > I then feel that using (abusing?) depends_on for update pattern is a bit\n> > weird. Maybe I\'m influenced by the CFN design, but the separate\n> > UpdatePolicy attribute feels better (although I would probably use a\n> > property). I guess my main question is around the meaning of using the\n> > update pattern on a server instance. I think I see what you want to do for\n> > the group, where child_updating would return a number, but I have no idea\n> > what it means for a single resource. Could you detail the operation a bit\n> > more in the document?\n> > \n> \n> I would be o-k with adding another keyword. The idea in abusing depends_on\n> is that it changes the core language less. Properties is definitely out\n> for the reasons Christopher brought up, properties is really meant to\n> be for the resource\'s end target only.\n\nOK. Part of my confusion is that I didn\'t really understand the relationship you\'re trying to build.\n\n> UpdatePolicy in cfn is a single string, and causes very generic rolling\n> update behavior. I want this resource to be able to control multiple\n> groups as if they are one in some cases (Such as a case where a user\n> has migrated part of an app to a new type of server, but not all.. so\n> they will want to treat the entire aggregate as one rolling update).\n\nWe don\'t need to have the same restriction as CFN.\n\n> I\'m o-k with overloading it to allow resource references, but I\'d like\n> to hear more people take issue with depends_on before I select that\n> course.\n> \n> To answer your question, using it with a server instance allows\n> rolling updates across non-grouped resources. In the example the\n> rolling_update_dbs does this.\n\nI think I start to understand. The depends_on implicitly creates a group of children with the parent being your rolling update resource.\n\n> > It also seems that the interface you\'re creating\n> > (child_creating/child_updating) is fairly specific to your use case. For\n> > autoscaling we have a need for more generic notification system, it would\n> > be nice to find common grounds. Maybe we can invert the relationship? Add\n> > a \"notified_resources\" attribute, which would call hooks on the \"parent\"\n> > when actions are happening.\n> > \n> \n> I\'m open to a different interface design. I don\'t really have a firm\n> grasp of the generic behavior you\'d like to model though. This is quite\n> concrete and would be entirely hidden from template authors, though not\n> from resource plugin authors. Attributes sound like something where you\n> want the template authors to get involved in specifying, but maybe that\n> was just an overloaded term.\n> \n> So perhaps we can replace this interface with the generic one when your\n> use case is more clear?\n\nSure, I don\'t want to block you. I think I\'d rather have another name than depends_on, to make it more clear what it means, even if at the implementation detail they are roughly the same. Or maybe we shouldn\'t use depends_on in HOT. Something like \"parent_resources\" would seem closer to what we want.\n\n-- \nThomas\n\n\n','<1391464621-sup-4293@fewbar.com>',NULL),('<1089DA9A-64EB-4008-96EF-FCD9981D60A4@jbryce.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:38:37',-21600,'2014-02-05 17:38:37',NULL,'[openstack-dev] [Openstack-docs] Conventions on naming','On Feb 5, 2014, at 10:18 AM, Steve Gordon <sgordon at redhat.com> wrote:\n\n> ----- Original Message -----\n>> From: \"Andreas Jaeger\" <aj at suse.com>\n>> To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing List (not for usage questions)\"\n>> <openstack-dev at lists.openstack.org>\n>> Cc: \"Jonathan Bryce\" <jonathan at openstack.org>\n>> Sent: Wednesday, February 5, 2014 9:17:39 AM\n>> Subject: Re: [openstack-dev] [Openstack-docs] Conventions on naming\n>> \n>> On 02/05/2014 01:09 PM, Mark McLoughlin wrote:\n>>> On Wed, 2014-02-05 at 11:52 +0100, Thierry Carrez wrote:\n>>>> Steve Gordon wrote:\n>>>>>> From: \"Anne Gentle\" <anne.gentle at rackspace.com>\n>>>>>> Based on today\'s Technical Committee meeting and conversations with the\n>>>>>> OpenStack board members, I need to change our Conventions for service\n>>>>>> names\n>>>>>> at\n>>>>>> https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names\n>>>>>> .\n>>>>>> \n>>>>>> Previously we have indicated that Ceilometer could be named OpenStack\n>>>>>> Telemetry and Heat could be named OpenStack Orchestration. That\'s not\n>>>>>> the\n>>>>>> case, and we need to change those names.\n>>>>>> \n>>>>>> To quote the TC meeting, ceilometer and heat are \"other modules\" (second\n>>>>>> sentence from 4.1 in\n>>>>>> http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/)\n>>>>>> distributed with the Core OpenStack Project.\n>>>>>> \n>>>>>> Here\'s what I intend to change the wiki page to:\n>>>>>> Here\'s the list of project and module names and their official names\n>>>>>> and\n>>>>>> capitalization:\n>>>>>> \n>>>>>> Ceilometer module\n>>>>>> Cinder: OpenStack Block Storage\n>>>>>> Glance: OpenStack Image Service\n>>>>>> Heat module\n>>>>>> Horizon: OpenStack dashboard\n>>>>>> Keystone: OpenStack Identity Service\n>>>>>> Neutron: OpenStack Networking\n>>>>>> Nova: OpenStack Compute\n>>>>>> Swift: OpenStack Object Storage\n>>>> \n>>>> Small correction. The TC had not indicated that Ceilometer could be\n>>>> named \"OpenStack Telemetry\" and Heat could be named \"OpenStack\n>>>> Orchestration\". We formally asked[1] the board to allow (or disallow)\n>>>> that naming (or more precisely, that use of the trademark).\n>>>> \n>>>> [1]\n>>>> https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names\n>>>> \n>>>> We haven\'t got a formal and clear answer from the board on that request\n>>>> yet. I suspect they are waiting for progress on DefCore before deciding.\n>>>> \n>>>> If you need an answer *now* (and I suspect you do), it might make sense\n>>>> to ask foundation staff/lawyers about using those OpenStack names with\n>>>> the current state of the bylaws and trademark usage rules, rather than\n>>>> the hypothetical future state under discussion.\n>>> \n>>> Basically, yes - I think having the Foundation confirm that it\'s\n>>> appropriate to use \"OpenStack Telemetry\" in the docs is the right thing.\n>>> \n>>> There\'s an awful lot of confusion about the subject and, ultimately,\n>>> it\'s the Foundation staff who are responsible for enforcing (and giving\n>>> advise to people on) the trademark usage rules. I\'ve cc-ed Jonathan so\n>>> he knows about this issue.\n>>> \n>>> But FWIW, the TC\'s request is asking for Ceilometer and Heat to be\n>>> allowed use their \"Telemetry\" and \"Orchestration\" names in *all* of the\n>>> circumstances where e.g. Nova is allowed use its \"Compute\" name.\n>>> \n>>> Reading again this clause in the bylaws:\n>>> \n>>>  \"The other modules which are part of the OpenStack Project, but\n>>>   not the Core OpenStack Project may not be identified using the\n>>>   OpenStack trademark except when distributed with the Core OpenStack\n>>>   Project.\"\n>>> \n>>> it could well be said that this case of naming conventions in the docs\n>>> for the entire OpenStack Project falls under the \"distributed with\" case\n>>> and it is perfectly fine to refer to \"OpenStack Telemetry\" in the docs.\n>>> I\'d really like to see the Foundation staff give their opinion on this,\n>>> though.\n\nIn this case, we are talking about documentation that is produced and distributed with the integrated release to cover the Core OpenStack Project and the ?modules\" that are distributed together with the Core OpenStack Project in the integrated release. This is the intended use case for the exception Mark quoted above from the Bylaws, and I think it is perfectly fine to refer to the integrated components in the OpenStack release documentation as OpenStack components.\n\n\n>> What Steve is asking IMO is whether we have to change \"OpenStack\n>> Telemetry\" to \"Ceilometer module\" or whether we can just say \"Telemetry\"\n>> without the OpenStack in front of it,\n>> \n>> Andreas\n> \n> Constraining myself to the topic of what we should be using in the documentation, yes this is what I\'m asking. This makes more sense to me than switching to calling them the \"Heat module\" and \"Ceilometer module\" because:\n> \n> 1) It resolves the issue of using the OpenStack mark where it (apparently) shouldn\'t be used.\n> 2) It means we\'re still using the \"formal\" name for the program as defined by the TC [1] (it is my understanding this remains the purview of the TC, it\'s control of the mark that the board are exercising here).\n> 3) It is a more minor change/jump and therefore provides more continuity and less confusion to readers (and similarly if one of them ever becomes endorsed as core and we need to switch again).\n> \n> Thanks,\n> \n> Steve\n> \n> [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml\n\n\nIt?s possible that in the future the Board may adjust the language to be explicitly more restrictive. In that case, I would agree with Steve that it would still make sense to still use the approved generic names on their own without the mark in the documentation rather than the codenames.\n\nJonathan\n\n\n\n','<1471160553.24225321.1391617098296.JavaMail.root@redhat.com>',NULL),('<1089f8f6aa124928a1dedaae4019d6b3@BLUPR05MB053.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-04 13:03:21',0,'2013-09-04 13:03:21',NULL,'[openstack-dev]  [Neutron] Question about create_port','Hello All,\n\nI am trying to make my neutron plugin  to configure a physical switch(using vlans), while in create_port I am trying to configure the physical switch I see a lot of create_port and delete_port  calls appearing in server.log.\nI am assuming that this may be due to the amount of time required to configure/commit on the physical switch is higher, and nova may be trying multiple times to create port (and deleting port when response does not arrive within a timeout period).\n\nIs there a timeout value in neutron or nova that can be altered so that the client can wait for the create_port to finish instead of sending multiple create/delete port?\n\nThanks\nChandan\n\n\n\n',NULL,NULL),('<1090145752.12.1369030155166.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-20 06:09:15',0,'2013-05-20 06:09:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #231','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/231/>\n\n------------------------------------------\n[...truncated 844 lines...]\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140463117211464:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_verify_signed_token_succeeds_for_unrevoked_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 533, in test_verify_signed_token_succeeds_for_unrevoked_token\n    self.middleware.verify_signed_token(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139663319500616:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_fetch_revocation_list_with_expire (test_auth_token_middleware.StackResponseAuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 422, in test_fetch_revocation_list_with_expire\n    fetched_list = jsonutils.loads(self.middleware.fetch_revocation_list())\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 820, in fetch_revocation_list\n    return self.cms_verify(data[\'signed\'])\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140480776361800:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_default_tenant_signed_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 483, in test_default_tenant_signed_token\n    self.assert_unscoped_default_tenant_auto_scopes(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 476, in assert_unscoped_default_tenant_auto_scopes\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140707427485512:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_memcache_set_expired (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 629, in test_memcache_set_expired\n    self.assertEqual(len(self.middleware._cache.set_value), 2)\nAssertionError: 7 != 2\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.middleware.auth_token: DEBUG: Cached Token 9bba6849c9e1f77727ae7813fd151115 seems expired\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140679707129672:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: DEBUG: Marking token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg== as unauthorized in memcache\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_valid_signed_request (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 461, in test_valid_signed_request\n    self.assert_valid_request_200(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 450, in assert_valid_request_200\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139947412399944:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 23.34 secs:\n    6.98    Kc11TestCase.test_admin_requires_adminness\n    6.71    KcMasterTestCase.test_admin_requires_adminness\n    6.64    KcEssex3TestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.50    KcMasterSqlTestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 701 tests in 84.294s\n\nFAILED (SKIP=11, errors=4, failures=3)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeystone==2012.2.5\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=43\n+ \'[\' 43 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.3gGRmtIQMv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/231\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/231/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<728232181.6.1368943669154.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1090388353.3685708.1373666930081.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-12 18:08:50',-14400,'2013-07-12 22:08:50',NULL,'[openstack-dev] AMQP Version upgrade plans?','\n\n----- Original Message -----\n> On 07/11/2013 12:06 PM, William Henry wrote:\n> > \n> > \n> > ----- Original Message -----\n> >> On 07/08/2013 10:51 AM, Ted Ross wrote:\n> >>> If someone from the Qpid community were to work on integrating the new\n> >>> AMQP 1.0 technology into OpenStack, where would be the right place to\n> >>> start?  Would it be to add a new transport to oslo.messaging?\n> >>\n> >> I think so, yes.  oslo.messaging is new, but it will deprecate the\n> >> existing \'rpc\' library in oslo-incubator.  All projects will need to\n> >> move to oslo.messaging, so for something new I would focus efforts there.\n> > \n> > I think that one of the important points that Ted brought up is that AMQP\n> > 1.0 doesn\'t have the concepts of broker artifacts like exchanges etc.\n> > \n> > A recent change I proposed to the existing impl_qpid.py which focuses more\n> > on addressing and not exchanges is a very important first step to solve\n> > several issues: a recent qpidd leak issue, transitioning to AMQP 1.0\n> > (addressing), and possible HA solutions.\n> > \n> > This is an area I\'d really like to continue to help out in. I\'m back from\n> > some vacation and would like to get stuck in soon.\n> \n> Regarding the qpid exchange leak, that issue is mitigated largely by the\n> fact that the only time we declare a direct exchange is for replies to\n> an rpc.  In previous versions there was a new one of these for *every*\n> method call, which made this problem really bad.  In the current code,\n> we only create a single one.\n> \n> However, we\'re still left with a leak.  The fact that RabbitMQ supports\n> auto-delete on exchanges and Qpid doesn\'t is what got us into this spot,\n> since this code works just like the kombu driver with respect to all of\n> this.\n\nRight you still have the leak. Right auto-delete on exchanges in Qpid would mitigate. \n \nQpid never supported this because, to my knowledge, auto-delete on exchanges didn\'t mean anything or have any value in Qpid. I\'m not sure it was ever mentioned in the old pre AMQP 1.0 spec. (I\'d need to check).\n\nAnd anyway exchanges don\'t mean anything in AMQP anymore. And don\'t mean anything in nonAMQP messaging - though AMQP implementations are not prohibited from implementing the queue/topic/fanout using exchange patterns.\n\n> \n> As for migration to AMQP 1.0, how do these changes help?  Supporting\n> AMQP 1.0 requires an entirely new driver that uses Qpid Proton, right?\n> How does changing addressing in the current Qpid driver (that will never\n> do 1.0) help?\n\nActually Qpid project saw the pending AMQP 1.0 ramifications early on and created an addressing mechanism that supported AMQP 1.0 addressing in Qpid long before Qpid/Proton.\n\nSo the changes I made recently would mean a simplified driver migration process.\n\nBut you are correct, it would still need that migration to a new driver.\n\nIt\'s my opinion that moving from a driver I recently submitted to the new driver would be very simple because of the way I\'ve restructured the addressing.\n\nAll great points you raise Russell.\n\nWilliam\n\n> \n> I\'m curious what you mean by \"possible HA solutions\".  Can you elaborate?\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51DF5991.7000907@redhat.com>',NULL),('<1090561D-6292-46FF-9A28-C745C710CC67@gmail.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-26 07:47:39',-25200,'2013-04-26 14:47:39',NULL,'[openstack-tc] Reddwarf application for incubation','\nOn Apr 26, 2013, at 3:02 AM, Mark McLoughlin wrote:\n\n> On Thu, 2013-04-25 at 17:31 -0400, Monty Taylor wrote:\n>> For me, I think that RedDwarf is a good fit for us, and I see it as an\n>> essential part of a cloud offering. I\'m not sure about where it falls in\n>> the IaaS/PaaS split, and I have to be honest I don\'t care, because I\n>> don\'t think that a user of a cloud ever says \"today I want to use some\n>> IaaS!\" \n> \n> That\'s where I\'m at too, I think.\n> \n> To the point that such services should be based on Heat and that there\n> should be a framework for building similar services - that\'s my instinct\n> too and if there\'s general agreement on that point, I\'d be wary of\n> RedDwarf entering Incubation without progress being made in that\n> direction.\n> \n> I mean, who knows - if someone came along with a new project to\n> implement such a generic framework, I think we\'d want to incubate *that*\n> project and encourage RedDwarf to port to it. I don\'t see why we should\n> decide now that RedDwarf will be the basis that generic framework.\n\nFunny you mention that. We actually began with reddwarf being a generic PaaS project and were told by multiple people in the community to focus instead on database as a service, and not try to tackle PaaS. IIRC some issues around it were 1) do the implementations of said PaaS project live _in_ the skeleton, 2) How would a generic api look for PaaS 3) its too big a concept to focus on...\n\nThat being said, reddwarf _was_ built to be a PaaS product. 2 summits ago i used reddwarf to spin up a apache, nfs, and mysql node and put wordpress on them. If thats what you want, then we already have that. The code was designed in such a way that the DBaaS portion of reddwarf is in a very specific place, and the code that spins up / manages instances is separated. \n\nSo, we are both DBaaS and a first shot at a generic framework for PaaS for applications that need more than just basic instrumenting. Weve got it covered :) I originally wanted to lead what you are referring to Mark, and tried to drive this project as such, even though we focused on DBaaS.\n\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n','<1366970532.16156.75.camel@sorcha>',NULL),('<1091762776.8193455.1388698536250.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-02 16:35:36',-18000,'2014-01-02 21:35:36',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','Hi Salvatore!, \n\n   Good work on this.\n\n   About the quota limit tests, I believe they may be unit-tested, \ninstead of functionally tested.\n\n   When running those tests in parallel with any other tests that rely\non having ports, networks or subnets available into quota, they have\nhigh chances of making those other tests fail.\n\nCheers,\nMiguel ?ngel Ajo\n\n\n\n----- Original Message -----\n> From: \"Kyle Mestery\" <mestery at siliconloons.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, January 2, 2014 7:53:05 PM\n> Subject: Re: [openstack-dev] [Neutron][qa] Parallel testing update\n> \n> Thanks for the updates here Salvatore, and for continuing to push on\n> this! This is all great work!\n> \n> On Jan 2, 2014, at 6:57 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n> > \n> > Hi again,\n> > \n> > I\'ve now run the experimental job a good deal of times, and I\'ve filed bugs\n> > for all the issues which came out.\n> > Most of them occurred no more than once among all test execution (I think\n> > about 30).\n> > \n> > They\'re all tagged with neutron-parallel [1]. for ease of tracking, I\'ve\n> > associated all the bug reports with neutron, but some are probably more\n> > tempest or nova issues.\n> > \n> > Salvatore\n> > \n> > [1] https://bugs.launchpad.net/neutron/+bugs?field.tag=neutron-parallel\n> > \n> > \n> > On 27 December 2013 11:09, Salvatore Orlando <sorlando at nicira.com> wrote:\n> > Hi,\n> > \n> > We now have several patches under review which improve a lot how neutron\n> > handles parallel testing.\n> > In a nutshell, these patches try to ensure the ovs agent processes new,\n> > removed, and updated interfaces as soon as possible,\n> > \n> > These patches are:\n> > https://review.openstack.org/#/c/61105/\n> > https://review.openstack.org/#/c/61964/\n> > https://review.openstack.org/#/c/63100/\n> > https://review.openstack.org/#/c/63558/\n> > \n> > There is still room for improvement. For instance the calls from the agent\n> > into the plugins might be consistently reduced.\n> > However, even if the above patches shrink a lot the time required for\n> > processing a device, we are still hitting a hard limit with the execution\n> > ovs commands for setting local vlan tags and clearing flows (or adding the\n> > flow rule for dropping all the traffic).\n> > In some instances this commands slow down a lot, requiring almost 10\n> > seconds to complete. This adds a delay in interface processing which in\n> > some cases leads to the hideous SSH timeout error (the same we see with\n> > bug 1253896 in normal testing).\n> > It is also worth noting that when this happens sysstat reveal CPU usage is\n> > very close to 100%\n> > \n> > From the neutron side there is little we can do. Introducing parallel\n> > processing for interface, as we do for the l3 agent, is not actually a\n> > solution, since ovs-vswitchd v1.4.x, the one executed on gate tests, is\n> > not multithreaded. If you think the situation might be improved by\n> > changing the logic for handling local vlan tags and putting ports on the\n> > dead vlan, I would be happy to talk about that.\n> > On my local machines I\'ve seen a dramatic improvement in processing times\n> > by installing ovs 2.0.0, which has a multi-threaded vswitchd. Is this\n> > something we might consider for gate tests? Also, in order to reduce CPU\n> > usage on the gate (and making tests a bit faster), there is a tempest\n> > patch which stops creating and wiring neutron routers when they\'re not\n> > needed: https://review.openstack.org/#/c/62962/\n> > \n> > Even in my local setup which succeeds about 85% of times, I\'m still seeing\n> > some occurrences of the issue described in [1], which at the end of the\n> > day seems a dnsmasq issue.\n> > \n> > Beyond the \'big\' structural problem discussed above, there are some minor\n> > problems with a few tests:\n> > \n> > 1) test_network_quotas.test_create_ports_until_quota_hit  fails about 90%\n> > of times. I think this is because the test itself should be made aware of\n> > parallel execution and asynchronous events, and there is a patch for this\n> > already: https://review.openstack.org/#/c/64217\n> > \n> > 2) test_attach_interfaces.test_create_list_show_delete_interfaces fails\n> > about 66% of times. The failure is always on an assertion made after\n> > deletion of interfaces, which probably means the interface is not deleted\n> > within 5 seconds. I think this might be a consequence of the higher load\n> > on the neutron service and we might try to enable multiple workers on the\n> > gate to this aim, or just increase the tempest timeout. On a slightly\n> > different note, allow me to say that the way assertion are made on this\n> > test might be improved a bit. So far one has to go through the code to see\n> > why the test failed.\n> > \n> > Thanks for reading this rather long message.\n> > Regards,\n> > Salvatore\n> > \n> > [1] https://lists.launchpad.net/openstack/msg23817.html\n> > \n> > \n> > \n> > \n> > On 2 December 2013 22:01, Kyle Mestery (kmestery) <kmestery at cisco.com>\n> > wrote:\n> > Yes, this is all great Salvatore and Armando! Thank you for all of this\n> > work\n> > and the explanation behind it all.\n> > \n> > Kyle\n> > \n> > On Dec 2, 2013, at 2:24 PM, Eugene Nikanorov <enikanorov at mirantis.com>\n> > wrote:\n> > \n> > > Salvatore and Armando, thanks for your great work and detailed\n> > > explanation!\n> > >\n> > > Eugene.\n> > >\n> > >\n> > > On Mon, Dec 2, 2013 at 11:48 PM, Joe Gordon <joe.gordon0 at gmail.com>\n> > > wrote:\n> > >\n> > > On Dec 2, 2013 9:04 PM, \"Salvatore Orlando\" <sorlando at nicira.com> wrote:\n> > > >\n> > > > Hi,\n> > > >\n> > > > As you might have noticed, there has been some progress on parallel\n> > > > tests for neutron.\n> > > > In a nutshell:\n> > > > * Armando fixed the issue with IP address exhaustion on the public\n> > > > network [1]\n> > > > * Salvatore has now a patch which has a 50% success rate (the last\n> > > > failures are because of me playing with it) [2]\n> > > > * Salvatore is looking at putting back on track full isolation [3]\n> > > > * All the bugs affecting parallel tests can be queried here [10]\n> > > > * This blueprint tracks progress made towards enabling parallel testing\n> > > > [11]\n> > > >\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<74AB8AE6-805D-4216-AD92-4A12C428E9D0@siliconloons.com>',NULL),('<1091776770.4117476.1403793253263.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 16:34:13',7200,'2014-06-26 14:34:13',NULL,'[openstack-dev] [Ceilometer] [Heat] Ceilometer aware people,\n	please advise us on processing notifications..','> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> On 24/06/14 09:28, Clint Byrum wrote:\n> > Hello! I would like to turn your attention to this specification draft\n> > that I\'ve written:\n> > \n> > https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst\n> > \n> > Angus has suggested that perhaps Ceilometer is a better place to handle\n> > this. Can you please comment on the review, or can we have a brief\n> > mailing list discussion about how best to filter notifications?\n> > \n> > Basically in Heat when a user boots an instance, we would like to act as\n> > soon as it is active, and not have to poll the nova API to know when\n> > that is. Angus has suggested that perhaps we can just tell ceilometer to\n> > hit Heat with a web hook when that happens.\n> \n> We could have a per-resource webhook (either the signal or something like it)\n> that is just a logical notification/kick to go and re-check the resource\n> state.\n> \n> The other part of this is when we turn on continuous convergence, we could\n> get an alarm whenever that resource changes state (or what ever we are\n> interested\n> in - as long as it is in the notification payload).\n> \n> Given the number of resources we want to manage the alarm sub-system will\n> need to\n> be scalable. I\'d rather Ceilometer solve that than Heat.\n\nWhen we talked about that issue in Atlanta, I think we came to the conclusion that one system wouldn\'t solve it, and that we need to be able to provide different pluggable solutions.\n\nThe first solution is just to move the current polling system and create a generic API around it. That\'s something that we\'ll want to keep, even if it\'s only to make standalone mode works. The next solution for me is to subscribe directly to the notification system. We know the shortcomings, but it\'s the obvious improvement we can do in the Juno cycle.\n\nLater on, if/when Ceilometer provides what we need, we can implement a new backend using it.\n\n-- \nThomas\n\n\n','<B8CF6F6CCA9E6749ACCD473169B95B721ACA0E4A@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1092173503.19901663.1402060571885.JavaMail.zimbra@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-06-06 13:16:11',0,'2014-06-06 13:16:11',NULL,'[Openstack-stable-maint] Instance shelving is broken in Havana\n : needs backport review','Hi,\nThanks Vish for the +2 ! So, I am continuing on landing a Tempest patch that effectively test shelve/unshelve. Now the unshelve works great but when the instance is unshelved a property of the instance is not set set back. I get this stacktrace http://logs.openstack.org/65/96165/1/check/check-grenade-dsvm-partial-ncpu-icehouse/2ac603c/logs/new/screen-n-api.txt.gz#_2014-06-04_12_57_04_476 I have been able to track this, and the fix was already proposed in Nova/havana. \n\nSo if some of you could review and eventually approve the backport here : https://review.openstack.org/#/c/72521/ and https://review.openstack.org/#/c/77734/ I think I will then be able to merge my new test in tempest !\n\nThanks a lot, and sorry to bother you if this list is not the right place.\n\nJordan\n\n----- Original Message -----\nFrom: \"Vishvananda Ishaya\" <vishvananda at gmail.com>\nTo: \"Jordan Pittier\" <jordan.pittier at cloudwatt.com>\nCc: openstack-stable-maint at lists.openstack.org\nSent: Monday, June 2, 2014 5:18:59 PM\nSubject: Re: [Openstack-stable-maint] Instance shelving is broken in Havana : needs backport review\n\nThis is a really nasty bug. +2/+a from me.\n\nVish\n\nOn Jun 2, 2014, at 7:29 AM, Jordan Pittier <jordan.pittier at cloudwatt.com> wrote:\n\n> Hi,\n> Instance shelving is broken in stable/havana, the instance that will be unshelved is not the one that has been shelved. A bug was filled here https://bugs.launchpad.net/nova/+bug/1257594 and a patch was merged in Icehouse. I\'d like to write a Tempest test to prevent this bug from happening again but in order to do this, I need the patch to be backported in stable/havana. A backport was proposed here : https://review.openstack.org/81214  It needs one more +2. Maybe you could help :)\n> \n> Thanks a lot !\n> Jordan\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n','<F2BF06CA-A47C-4851-822A-E93AA005C5F3@gmail.com>',NULL),('<1092559066.19392418.1354729133445.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-05 12:38:53',-18000,'2012-12-05 17:38:53',NULL,'[openstack-dev] [ceilometer][synaps] Ceilometer and Synaps\n	joining forces','\n\n> Let\'s have a detailed discussion about the technicalities of managing\n> the two codebases, issue tracking, task prioritization etc.\n\nOk, so lets figure out how were going to do this.\n\nFirst question is how to approach managing the two codebases.\n\nMy instinct to merge the Synaps code into the Ceilo git repo,\nre-packaging as ceilometer.synaps. Thoughts?\n\nSecondly, in terms of issue tracking, the number of bugs\nfiled against https://launchpad.net/synaps is small, so we\ncould easily do a manual migration to a single consolidated\ntracker under https://launchpad.net/ceilometer. Thoughts?\n\nFinally in terms of prioritizing tasks, here\'s my laundry\nlist that I\'m planning to translate to blueprints once the\ninitial transitions are done. Any further input would be\nwelcome.\n\n - clean up the long & awkward dependency chain and allow\n   Synaps be sparked up optionally within devstack\n\n - beef up test coverage, which is currently low and has a\n   strong functional as opposed to unittest orientation\n\n - push the Cassandra usage behind a storage abstraction,\n   to allow for pluggable stores\n\n - add a native API, alongside the AWS CloudWatch API\n   (capturing some of the novel aspects of Synaps,\n    e.g. the concept of overlapping eval periods)\n\n - decouple metric ingestion and alarm evaluation from\n   storm (currently embedded in the storm bolts)\n\n - support alternative non-storm (well, non-Java-oriented)\n   distributed computation frameworks\n\n - switch to a periodic alarm threshold evaluation model\n   (as evaluation on metric ingestion is prone to\n    false positives when outliers report first) \n\nCheers,\nEoghan\n\n\n','<1516994945.9459474.1354211849498.JavaMail.root@redhat.com>',NULL),('<1093030929.422292.1376899560810.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-19 04:06:00',-14400,'2013-08-19 08:06:00',NULL,'[openstack-qa]  Tempest tests on a distributed topology','Hi all,\n\nI\'m not familiar with how Tempest run it\'s tests (Jenkins) and was wondering if Tempest works currently as an \"All in one\", where all components are on the same machine, or if it has the capability of testing a distributed environment.\n\nCan someone give me more details on the matter?\n\nThanks,\nTal\n\n\n','<CAJv9qeTUZnZups-9Qz309=1x4DDjFiU49WGjWvUwn358Mh_mDA@mail.gmail.com>',NULL),('<1093488196.18.1375252114454.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-31 06:28:34',0,'2013-07-31 06:28:34',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all #51','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/51/>\n\n\n\n','<752128295.13.1375165846072.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1096105070.4901999.1396301103488.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 17:25:03',-14400,'2014-03-31 21:25:03',NULL,'[openstack-dev] [Nova] Juno open for development','I should specify that I meant updating the OS version used by the CI.\n\n----- Original Message -----\nFrom: \"Solly Ross\" <sross at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Monday, March 31, 2014 5:24:12 PM\nSubject: Re: [openstack-dev] [Nova] Juno open for development\n\nThere was some talk about updating the CI for Juno.\nHas this been done/when will this be done?\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, March 31, 2014 2:23:32 PM\nSubject: [openstack-dev] [Nova] Juno open for development\n\nWe just merged the change that opens the master branch for Juno development:\n\n    https://review.openstack.org/#/c/83752/\n\nWe will be releasing icehouse-rc1 from the commit that precedes the\nabove patch.  If anything comes up that warrants another release\ncandidates, please get in contact with me directly.\n\nOn the Juno front, we are now ready to start accepting and reviewing\nJuno blueprints.  The process is documented here:\n\n    https://wiki.openstack.org/wiki/Blueprints#Creation\n\nIf you have any questions not answered by that page, please bring them\nup so that we can ensure the process is adequately documented.\n\nThanks,\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1740131110.4901895.1396301052673.JavaMail.zimbra@redhat.com>',NULL),('<1096127061.6198795.1368191184416.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-10 09:06:24',-14400,'2013-05-10 13:06:24',NULL,'[openstack-dev] revert keystone eventlet changes?','\n\n----- Original Message -----\n> From: \"Thierry Carrez\" <thierry at openstack.org>\n> To: openstack-dev at lists.openstack.org\n> Sent: Friday, May 10, 2013 8:28:30 AM\n> Subject: Re: [openstack-dev] revert keystone eventlet changes?\n> \n> Dan Prince wrote:\n> > We made a change to keystone eventlet last night that seems to have ground\n> > SmokeStack to a halt:\n> > \n> > https://review.openstack.org/#/c/28785/\n> > https://bugs.launchpad.net/keystone/+bug/1178646\n> > \n> > Could we get a speedy revert on that patch until we get this figured out?\n> \n> There is also a comment on the original review that observes the same\n> failure: https://review.openstack.org/#/c/28737/\n> \n> Sounds like it should be reverted ASAP, and we need some tests to cover\n> that in the gate.\n> \n> Dan: any idea why SmokeStack was happy with it on the review ?\n\nttx: From what I can see only patchset 3 ran fine in SmokeStack. Patchset 4 did not get a +1 verified (and I didn\'t get around to approving the negative result so it would post a -1).\n\nDan\n\n> \n> --\n> Thierry Carrez (ttx)\n> Release Manager, OpenStack\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<518CE7EE.2000505@openstack.org>',NULL),('<1096237323.7.1382681484815.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-25 06:11:24',0,'2013-10-25 06:11:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #37','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/37/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4cc1310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4cc1310>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3f24450>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3f24450>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-6de96fd6-55e6-4cef-9e2c-71b5051f0c76\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:10:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:10:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:10:52+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'52\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:10:52-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'52\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:10:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52a7e10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x192a6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 72.48 secs:\n    16.29    TestGlanceControl.test_bouncing\n    14.73    TestScrubber.test_delayed_delete\n    14.11    TestGlanceControl.test_reload\n    13.93    TestGlanceControl.test_respawn\n    13.42    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 593.163s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-37\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.chWmFvL8zG\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/37/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-4/37\n[SCP] Copying console log.\n\n\n','<1861266333.1.1382508557148.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1097340841.43.1352678739178.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:05:39',0,'2012-11-12 00:05:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-diablo #90','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/90/>\n\n------------------------------------------\n[...truncated 265 lines...]\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.05\n    test_get_image_details_marker_limit                          OK    0.09\n    test_get_image_details_sort_disk_format_asc                  OK    0.07\n    test_get_image_details_with_maximum_size                     OK    0.06\n    test_get_image_details_with_minimum_size                     OK    0.07\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.05\n    test_get_image_index_limit                                   OK    0.08\n    test_get_image_index_limit_None                              OK    0.07\n    test_get_image_index_marker                                  OK    0.08\n    test_get_image_index_marker_limit                            OK    0.09\n    test_get_image_members                                       OK    0.05\n    test_get_image_members_not_existing                          OK    0.05\n    test_get_image_non_existing                                  OK    0.05\n    test_get_index_sort_container_format_desc                    OK    0.07\n    test_get_index_sort_created_at_asc                           OK    0.17\n    test_get_index_sort_disk_format_asc                          OK    0.07\n    test_get_index_sort_id_desc                                  OK    0.08\n    test_get_index_sort_name_asc                                 OK    0.07\n    test_get_index_sort_size_asc                                 OK    0.07\n    test_get_index_sort_status_desc                              OK    0.08\n    test_get_index_sort_updated_at_desc                          OK    0.07\n    test_get_member_images                                       OK    0.05\n    test_replace_members                                         OK    0.05\n    test_update_image                                            OK    0.07\n    test_update_image_not_existing                               OK    0.04\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.01\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.01\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.21\n    test_version_control_existing_db                             OK    0.79\n    test_walk_versions                                           OK    0.81\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.00\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 39.51 secs:\n    11.80    TestScrubber.test_delayed_delete\n    9.00    TestBinGlance.test_results_filtering\n    7.01    TestBinGlance.test_results_pagination\n    6.26    TestBinGlance.test_results_sorting\n    5.44    TestBinGlance.test_add_clear\n----------------------------------------------------------------------\nRan 338 tests in 102.238s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nimportlib==1.0.2\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\nordereddict==1.1\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.4\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-diablo/90\n[SCP] Copying console log.\n\n\n','<1296654299.31.1352592302310.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1097534679.71.1373609073783.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-12 06:04:33',0,'2013-07-12 06:04:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #284','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/284/>\n\n------------------------------------------\n[...truncated 2680 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.110.ga45c49b to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.110.ga45c49b\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.110.ga45c49b\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.2.gc460ebf to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.2.gc460ebf\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.2.gc460ebf\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/rabbitmq/rabbit at devstack-1373607689-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/rabbitmq/rabbit at devstack-1373607689.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/284/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1505359014.61.1373522817531.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1097834280.477.1367130940826.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:35:40',0,'2013-04-28 06:35:40',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly/18/changes>\n\n\n\n',NULL,NULL),('<1097922358.43.1387174257127.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-16 06:10:57',0,'2013-12-16 06:10:57',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-nova-docs-grizzly #7','See <https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/7/changes>\n\n\n\n','<16305400.31.1387087517107.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1098288809.4029947.1416805288262.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-24 00:01:28',-18000,'2014-11-24 05:01:28',NULL,'[openstack-dev] [nova] Proposal new hacking rules','Whoops, that should say \"assertions\" not \"exceptions\".\n\n----- Original Message -----\n> From: \"Solly Ross\" <sross at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, November 24, 2014 12:00:44 AM\n> Subject: Re: [openstack-dev] [nova] Proposal new hacking rules\n> \n> Well, at least the message for exceptions in Nova says \"expected\" and\n> \"observed\".\n> I suspect that it\'s part of our custom test case classes.\n> \n> Best Regards,\n> Solly Ross\n> \n> \n> ----- Original Message -----\n> > From: \"Matthew Treinish\" <mtreinish at kortar.org>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > <openstack-dev at lists.openstack.org>\n> > Sent: Friday, November 21, 2014 5:23:28 PM\n> > Subject: Re: [openstack-dev] [nova] Proposal new hacking rules\n> > \n> > On Fri, Nov 21, 2014 at 04:15:07PM -0500, Sean Dague wrote:\n> > > On 11/21/2014 01:52 PM, Matthew Treinish wrote:\n> > > > On Fri, Nov 21, 2014 at 07:15:49PM +0100, jordan pittier wrote:\n> > > >> Hey,\n> > > >> I am not a Nova developer but I still have an opinion.\n> > > >>\n> > > >>> Using boolean assertions\n> > > >> I like what you propose. We should use and enforce the assert* that\n> > > >> best\n> > > >> matches the intention. It\'s about semantic and the more precise we\n> > > >> are,\n> > > >> the better.\n> > > >>\n> > > >>> Using same order of arguments in equality assertions\n> > > >> Why not. But I don\'t know how we can write a Hacking rule for this. So\n> > > >> you may fix all the occurrences for this now, but it might get back in\n> > > >> the future.\n> > > > \n> > > > Ok I\'ll bite, besides the enforceability issue which you pointed out,\n> > > > it\n> > > > just\n> > > > doesn\'t make any sense, you\'re asserting 2 things are equal: (A == B)\n> > > > ==\n> > > > (B == A)\n> > > > and I honestly feel that it goes beyond nitpicking because of that.\n> > > > \n> > > > It\'s also a fallacy that there will always be an observed value and an\n> > > > expected value. For example:\n> > > > \n> > > >   self.assertEqual(method_a(), method_b())\n> > > > \n> > > > Which one is observed and which one is expected? I think this proposal\n> > > > is\n> > > > just\n> > > > reading into the parameter names a bit too much.\n> > > \n> > > If you are using assertEqual with 2 variable values... you are doing\n> > > your test wrong.\n> > > \n> > > I was originally in your camp. But honestly, the error message provided\n> > > to the user does say expected and observed, and teaching everyone that\n> > > you have to ignore the error message is a much harder thing to do than\n> > > flip the code to conform to it, creating less confusion.\n> > > \n> > \n> > Uhm, no it doesn\'t, the default error message is \"A != B\". [1][2][3] (both\n> > with\n> > unittest and testtools) If the error message was like that, then sure\n> > saying\n> > one way was right over the other would be fine, (assuming you didn\'t\n> > specify\n> > a\n> > different error message) but, that\'s not what it does.\n> > \n> > \n> > [1]\n> > https://github.com/testing-cabal/testtools/blob/master/testtools/testcase.py#L340\n> > [2]\n> > https://github.com/testing-cabal/testtools/blob/master/testtools/matchers/_basic.py#L85\n> > [3]\n> > https://hg.python.org/cpython/file/301d62ef5c0b/Lib/unittest/case.py#l508\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n\n\n','<1853230639.4029941.1416805244805.JavaMail.zimbra@redhat.com>',NULL),('<1098406565.49.1387346556251.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-18 06:02:36',0,'2013-12-18 06:02:36',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-heat-python27-grizzly #8','See <https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/8/>\n\n\n\n','<2010337451.45.1387260206111.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1099138811.9.1376460584590.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-14 06:09:44',0,'2013-08-14 06:09:44',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python26-stable-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/6/changes>\n\n\n\n','<117473994.4.1376287528772.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1099239531.223.1368252614998.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:10:14',0,'2013-05-11 06:10:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #222','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/222/>\n\n------------------------------------------\n[...truncated 11851 lines...]\n    s,%SSH_TIMEOUT%,4,g;\n    s,%IMAGE_ID%,25061de0-460b-4b14-bae9-ad647453c2f6,g;\n    s,%IMAGE_ID_ALT%,25061de0-460b-4b14-bae9-ad647453c2f6,g;\n    s,%FLAVOR_REF%,1,g;\n    s,%FLAVOR_REF_ALT%,2,g;\n    s,%COMPUTE_CONFIG_PATH%,/etc/nova/nova.conf,g;\n    s,%COMPUTE_SOURCE_DIR%,/opt/stack/new/nova,g;\n    s,%COMPUTE_BIN_DIR%,/usr/bin/nova,g;\n    s,%COMPUTE_PATH_TO_PRIVATE_KEY%,/opt/stack/new/tempest/id_rsa,g;\n    s,%COMPUTE_DB_URI%,mysql://root:secret at localhost/nova,g;\n    s,%IMAGE_HOST%,127.0.0.1,g;\n    s,%IMAGE_PORT%,9292,g;\n    s,%IMAGE_API_VERSION%,1,g;\n    s,%IMAGE_CATALOG_TYPE%,image,g;\n    s,%COMPUTE_ADMIN_USERNAME%,admin,g;\n    s,%COMPUTE_ADMIN_PASSWORD%,secret,g;\n    s,%COMPUTE_ADMIN_TENANT_NAME%,admin,g;\n    s,%IDENTITY_ADMIN_USERNAME%,admin,g;\n    s,%IDENTITY_ADMIN_PASSWORD%,secret,g;\n    s,%IDENTITY_ADMIN_TENANT_NAME%,admin,g;\n    s,%NETWORK_CATALOG_TYPE%,network,g;\n    s,%NETWORK_API_VERSION%,2.0,g;\n    s,%VOLUME_CATALOG_TYPE%,volume,g;\n    s,%VOLUME_BUILD_INTERVAL%,3,g;\n    s,%VOLUME_BUILD_TIMEOUT%,300,g;\n\' -i /opt/stack/new/tempest/etc/tempest.conf\n+ echo \'Created tempest configuration file:\'\nCreated tempest configuration file:\n+ cat /opt/stack/new/tempest/etc/tempest.conf\n[identity]\n# This section contains configuration options that a variety of Tempest\n# test clients use when authenticating with different user/tenant\n# combinations\n\n# Set to True if your test environment\'s Keystone authentication service should\n# be accessed over HTTPS\nuse_ssl = False\n# This is the main host address of the authentication service API\nhost = 127.0.0.1\n# Port that the authentication service API is running on\nport = 5000\n# Version of the authentication service API (a string)\napi_version = v2.0\n# Path to the authentication service tokens resource (do not modify unless you\n# have a custom authentication API and are not using Keystone)\npath = tokens\n# Should typically be left as keystone unless you have a non-Keystone\n# authentication API service\nstrategy = keystone\n\n[compute]\n# This section contains configuration options used when executing tests\n# against the OpenStack Compute API.\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_isolation = True\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_reuse = True\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n# This should be the username of an alternate user WITHOUT\n# administrative privileges\nalt_username = alt_demo\n# The above non-administrative user\'s password\nalt_password = secret\n# The above non-administrative user\'s tenant name\nalt_tenant_name = alt_demo\n\n# Reference data for tests. The ref and ref_alt should be\n# distinct images/flavors.\nimage_ref = 25061de0-460b-4b14-bae9-ad647453c2f6\nimage_ref_alt = 25061de0-460b-4b14-bae9-ad647453c2f6\nflavor_ref = 1\nflavor_ref_alt = 2\n\n# Number of seconds to wait while looping to check the status of an\n# instance that is building.\nbuild_interval = 3\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nERROR: unknown environment \'smoke\'\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/rabbitmq/rabbit at devstack-1368243706-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/rabbitmq/rabbit at devstack-1368243706.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-n-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/screen-swift.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/222/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<109c0c339f7bb2791f4029f63d3e8f19@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-19 16:49:11',7200,'2014-12-19 14:49:11',NULL,'[Openstack] {Disarmed} Re: Fedora/cirros instance failed to set\n root password',' Doing that is changing the password for \"fedora\" user and not \"root\"\n\n\n When you ssh as the \"fedora\" user do \"sudo su\" and you will be able to \n login as \"root\" directly provided that the keys have been correctly \n injected.\n\n You can then set the password for \"root\"\n\n Best,\n\n George\n\n> Hi Girija Sharan,\n>\n> I tried it it is giving me\n>\n> [fedora at blabla ~]$ passwd\n> Changing password for user fedora.\n> Changing password for fedora.\n> (current) UNIX password:\n> passwd: Authentication token manipulation error\n> [fedora at blabla ~]$\n>\n> [fedora at blabla ~]$ su - root\n> Password:\n> su: Authentication failure\n>\n> here is the admin pass as shown below \"uTU3H5er7yZS\"\n>\n> I enter this password gives error\n>\n> i the above commands used the same admin pass\n>\n> stack at celestial-PC-1:~/devstack$ nova boot --flavor 3 --image\n> 9d30b9b5-d648-4af1-ad24-d5792d3f1909 --key-name nnnn --security-group\n> default blabla\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n> | Property | Value |\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n> | OS-DCF:diskConfig | MANUAL |\n> | OS-EXT-AZ:availability_zone | nova |\n> | OS-EXT-SRV-ATTR:host | - |\n> | OS-EXT-SRV-ATTR:hypervisor_hostname | - |\n> | OS-EXT-SRV-ATTR:instance_name | instance-00000001 |\n> | OS-EXT-STS:power_state | 0 |\n> | OS-EXT-STS:task_state | scheduling |\n> | OS-EXT-STS:vm_state | building |\n> | OS-SRV-USG:launched_at | - |\n> | OS-SRV-USG:terminated_at | - |\n> | accessIPv4 | |\n> | accessIPv6 | |\n> | adminPass | uTU3H5er7yZS |\n> | config_drive | |\n> | created | 2014-12-19T12:29:45Z |\n> | flavor | m1.medium (3) |\n> | hostId | |\n> | id | 898a3c21-c1bf-4325-93ac-f14315dd2210 |\n> | image | Fedora-x86_64-20-20140618-sda\n> (9d30b9b5-d648-4af1-ad24-d5792d3f1909) |\n> | key_name | nnnn |\n> | metadata | {} |\n> | name | blabla |\n> | os-extended-volumes:volumes_attached | [] |\n> | progress | 0 |\n> | security_groups | default |\n> | status | BUILD |\n> | tenant_id | 2d51ee7250aa4532801f83fda82468fc |\n> | updated | 2014-12-19T12:29:46Z |\n> | user_id | f923e8ad018a40c4a315fa1c23126eed |\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n>\n> Regards\n> Neelu\n>\n>   On Friday, 19 December 2014 3:25 PM, Girija Sharan  wrote:\n>\n> Hi Som,\n>\n> As you said, you are able to ssh into the instance using keypair, why\n> don\'t you just ssh into that and set root password using \'passwd\'\n> command or create another user with root permissions ?\n>\n> On Fri, Dec 19, 2014 at 3:06 PM, somshekar kadam  wrote:\n>\n>> Hi Girija Sharan,\n>>\n>> Thanks for pointing the link I will try and let me see if it works.\n>>\n>> I just need to set the root pasword so that I can install apache\n>> wbserver on this instance.\n>>\n>> Is there any other best method to do it, which I not know.\n>>\n>> thanks in advance\n>>\n>> Regards\n>> Neelu\n>>\n>> On Friday, 19 December 2014 2:44 PM, Girija Sharan wrote:\n>>\n>> Hi Som,\n>>\n>> Not sure on what you are looking for. But here is a link which\n>> describe\n>>\n>> how to set root password during instance boot up.\n>>\n>>\n> \n> http://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/\n>> [10]\n>>\n>> On Fri, Dec 19, 2014 at 2:19 PM, somshekar kadam wrote:\n>>\n>>> Hi All,\n>>>\n>>> I am trying to set root password on\n>>> Fedora-x86_64-20-20140618-sda/cirros instance it fails .\n>>> DO I need to add anyother security rules, please what I am\n>>> missing.\n>>> I need to install apache webserver on this instance.\n>>>\n>>> Thanks in advance\n>>>\n>>> nova root-password gggg\n>>> New password:\n>>> Again:\n>>> ERROR (HTTPNotImplemented): Unable to set password on instance\n>>> (HTTP 501) (Request-ID: req-6d0eebe3-68c5-4d8d-80b7-8d4639b7c2d4)\n>>>\n>>> I have set all rules for security groups\n>>> PC-1:~/devstack$ nova secgroup-list-rules default\n>>> +-------------+-----------+---------+-----------+--------------+\n>>> | IP Protocol | From Port | To Port | IP Range | Source Group |\n>>> +-------------+-----------+---------+-----------+--------------+\n>>> | icmp | -1 | -1 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [1] | |\n>>> | tcp | 1 | 65535 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [2] | |\n>>> | udp | 1 | 65535 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [3] | |\n>>> | tcp | 22 | 22 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [4] | |\n>>> | tcp | 80 | 80 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [5] | |\n>>> | tcp | 443 | 443 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [6] | |\n>>> | tcp | 3306 | 3306 | MAILSCANNER WARNING: NUMERICAL LINKS ARE\n>>> OFTEN MALICIOUS: 0.0.0.0/0 [7] | |\n>>> | tcp | 53 | 53 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [8] | |\n>>> +-------------+-----------+---------+-----------+--------------+\n>>>\n>>> Regards\n>>> Neelu\n>\n>\n>\n> Links:\n> ------\n> [1] http://0.0.0.0/0\n> [2] http://0.0.0.0/0\n> [3] http://0.0.0.0/0\n> [4] http://0.0.0.0/0\n> [5] http://0.0.0.0/0\n> [6] http://0.0.0.0/0\n> [7] http://0.0.0.0/0\n> [8] http://0.0.0.0/0\n> [9] mailto:girijasharansingh at gmail.com\n> [10]\n> \n> http://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/\n> [11] mailto:som_kadam at yahoo.co.in\n> [12] mailto:som_kadam at yahoo.co.in\n\n\n\n','<500812661.91420.1418994439522.JavaMail.yahoo@jws10901g.mail.sg3.yahoo.com>',NULL),('<10a66adb0836a9a85e117bd3c1f8442b@mail.gmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-10 19:13:35',36000,'2013-09-10 09:13:35',NULL,'[openstack-community] New Community (Nepal)','Sure, add me on Skype if you like and we can have a chat at a mutually\nagreeable time.\n\n\n\nSkype: tristangoode\n\nGoogle Hangout: tristan at aptira.com (not on here so often)\n\n\n\n\n\n*From:* Surit Aryal [mailto:surit.killer at gmail.com]\n*Sent:* Tuesday, 10 September 2013 7:10 PM\n*To:* Tristan Goode\n*Cc:* community at lists.openstack.org\n*Subject:* Re: [openstack-community] New Community (Nepal)\n\n\n\nThat can be a start.\n\nAlso may be if I can get mentored by some experienced OSUG member before\nthe event that would be help for me. It might help me in choosing the\ninvitees and so on.\n\n\n\n\nOn Tue, Sep 10, 2013 at 2:46 PM, Tristan Goode <tristan at aptira.com> wrote:\n\nAh I see... Perhaps if you have reasonably good Internet access at the\nvenue for your first meetup(s), we could do a Google Hangout or Skype call\nand do an introduction to the project over the Internet!? That way we could\ndescribe the project for your attendees, both at technical level and how\nthe Foundation works etc, and have a Q&A session?\n\n\n\n\n\n*From:* Surit Aryal [mailto:surit.killer at gmail.com]\n*Sent:* Tuesday, 10 September 2013 6:47 PM\n*To:* Tristan Goode\n*Cc:* community at lists.openstack.org\n*Subject:* Re: [openstack-community] New Community (Nepal)\n\n\n\nThanks Tristan,\n\nHaving informal talks with related people is skipping steps to me. I think\nI should know what to talk about and how to make people contribute. Total\nnewbie here :) .\n\nAs you have a lot of experience with new community can you help me with all\nthe beginning steps too.\n\nRegrads\n\n\n\nOn Tue, Sep 10, 2013 at 1:52 PM, Tristan Goode <tristan at aptira.com> wrote:\n\nHi Surit,\n\n\n\nWelcome!!! Have you seen the \"How To\" guide at\nhttps://wiki.openstack.org/wiki/OpenStackUserGroups/HowTo ? There is some\nhelpful information and links there to help get started.\n\n\n\nWe (our company Aptira) started off in Australia and India by holding an\ninformal get together and we started by getting in touch with related FOSS\nUGs, NOGs and also educational institutions and inviting them to come eat\nsome food and drink a few beers and talk. From there we invited some\noverseas guests to video conference to talk about specific projects in the\nOpenStack eco system. Lately we have been hooking people into meetups using\nGoogle Hangouts across the world. We also have an AOSUG planning Etherpad\nat https://etherpad.openstack.org/AustralianOpenStackGroupPlanning that\nwe\'ve been using lately to plan events.\n\n\n\nOther than that, please ask and we\'ll do our best to help you get underway.\n\n\n\nI know everyone that has started a group that I\'ve met (so many people in\nthe last couple of years!) have had a great time, and I feel very fortunate\nnow to be part of this community. I look forward to seeing you feel the\nsame way!\n\n\n\nCheers\n\nTristan\n\n\n\nAustralian OpenStack UG co-founder and organizer\n\nIndian OpenStack UG supporter\n\nMember OpenStack oundation BoD\n\n\n\n\n\n*From:* Surit Aryal [mailto:surit.killer at gmail.com]\n*Sent:* Tuesday, 10 September 2013 5:47 PM\n*To:* community at lists.openstack.org\n*Subject:* [openstack-community] New Community (Nepal)\n\n\n\nHi all,\n\nFew days back I was asked to drop an email to this mailing list by Tom\nregarding the subject, But I was busy preparing for SFD in Nepal so I could\nnot send one. I have bought some time to write an email today.\n\n\n\nMy name is Surit and I am from Nepal. I am a student. I am a FOSS\nenthusiast. I am involved with different FOSS related groups in my country\nlike FOSS Nepal, Mozilla Nepal, Nepal Open Source Klub (NOSK) etc. I am\nalso a Mozilla representative for my country.\n\nFew days back I started contributing to openstack by\ntranslating(localization) in Transifex.\n\nNow I would like to open a community here in my country so that I could\nfetch more contributors. I would like to know the necessary process for\ndoing so.\n\nIn addition to that I am also a little naive to this project so it would be\ngreat if I could receive some trainings or something that would help me and\nmy community\n\nRegrads\n\nSurit Aryal\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130910/d06f8b7a/attachment-0001.html>\n\n','<CAPCkUQi6Jsxumctatvmdfk3ksU90KSAontKdM1s+0gJMmv2-6Q@mail.gmail.com>',NULL),('<10a912d410cc43bb9662c4e6b1ba8132@BLUPR03MB150.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-01-31 08:44:54',0,'2014-01-31 08:44:54',NULL,'[OpenStack-Infra] Regarding Third party testing account','Hi-\n\nWe want to contribute code to Openstack Neutron.\n\nSince, it requires a third party test setup so that the code is upstream.\n\nKindly help me with information regarding the same.\n\nThanks in advance.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140131/a2dd577e/attachment.html>\n\n',NULL,NULL),('<10ADF48F-9408-40BB-8B59-8819A4F0ED33@pd.infn.it>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-29 19:01:43',3600,'2014-01-29 18:01:43',NULL,'[Openstack-operators] Virtual Instance can\'t obtain IP address\n	(OpenStack Havana)','Hi David, \n\n> \n> On your network node, check the NIC settings for various offloading\n> \"optimizations\":\n> \n>    $ ethtool -k eth0 | grep offload\n>    tcp-segmentation-offload: off\n>    udp-fragmentation-offload: off [fixed]\n>    generic-segmentation-offload: off\n>    generic-receive-offload: off\n>    large-receive-offload: off [fixed]\n>    rx-vlan-offload: on\n>    tx-vlan-offload: on\n> \n\nI issued that command on my eth2 NIC which is connected to the data-network\n\n[root at network ~]# ethtool -k eth2 | grep offload\ntcp-segmentation-offload: on\nudp-fragmentation-offload: off\ngeneric-segmentation-offload: on\ngeneric-receive-offload: off\nlarge-receive-offload: off\n\nOn network node I?ve 3 networks:\n\npublic\nmanagement\ndata\n\nOn compute I?ve 2 networks:\nmanagement\ndata\n\nDid I do correctly ?\n\nThe offload is on. Should I change it ? how ?\n\n> We recently solved this problem at $WORK by disabling GRO on our network\n> node.\n> \n> The other issue we\'ve come across that may be related is MTUs: since Open\n> vSwitch 1.9+ got rid of Path MTU Discovery, you may need to adjust your\n> MTUs:\n> \n>  http://techbackground.blogspot.ca/2013/06/path-mtu-discovery-and-gre.html\n\nIn that article they talk about a GRE setup, but I choosed local (CONFIG_NEUTRON_OVS_TENANT_NETWORK_TYPE=local). Can I use that guide anyway ?\n\n> \n> There are two ways to fix this: if your network infrastructure has jumbo\n> frames (1500+) enabled, change the hardware NICs to have an MTU of 1546\n> (or larger). If you do not have jumbo frames enabled, configure the guests\n> to have an MTU of 1454 or smaller.\n> \n> One or both of these things (GRO and MTU) will probably be needed for a\n> properly functioning virtual network.\n> \n\n\n\n','<812b7ac708f496837bc0844518e75290.squirrel@webmail.ee.ryerson.ca>',NULL),('<10B6E122-8A1A-47E4-A486-10C2BBCB8810@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 09:56:29',-28800,'2015-01-29 17:56:29',NULL,'[openstack-dev] [api][nova] Openstack HTTP error codes','If you\'re going to make up your own extensions[1] to HTTP, why don\'t you use ones that are already used?\n\nhttp://support.microsoft.com/kb/943891\n\n\n\n[1] ok, what\'s proposed isn\'t technically an \"extension\", it\'s response body context for the response code. But response bodies are hard to modify when you\'re dealing with APIs that aren\'t control-plane APIs.\n\n--John\n\n\n\n> On Jan 29, 2015, at 9:41 AM, Sean Dague <sean at dague.net> wrote:\n> \n> Correct. This actually came up at the Nova mid cycle in a side\n> conversation with Ironic and Neutron folks.\n> \n> HTTP error codes are not sufficiently granular to describe what happens\n> when a REST service goes wrong, especially if it goes wrong in a way\n> that would let the client do something other than blindly try the same\n> request, or fail.\n> \n> Having a standard json error payload would be really nice.\n> \n> {\n>     fault: ComputeFeatureUnsupportedOnInstanceType,\n>     messsage: \"This compute feature is not supported on this kind of\n> instance type. If you need this feature please use a different instance\n> type. See your cloud provider for options.\"\n> }\n> \n> That would let us surface more specific errors.\n> \n> Today.... there is a giant hodgepodge - see:\n> \n> https://github.com/openstack/tempest-lib/blob/master/tempest_lib/common/rest_client.py#L412-L424\n> \n> https://github.com/openstack/tempest-lib/blob/master/tempest_lib/common/rest_client.py#L460-L492\n> \n> Especially blocks like this:\n> \n>                        if \'cloudServersFault\' in resp_body:\n>                            message =\n> resp_body[\'cloudServersFault\'][\'message\']\n>                        elif \'computeFault\' in resp_body:\n>                            message = resp_body[\'computeFault\'][\'message\']\n>                        elif \'error\' in resp_body:\n>                            message = resp_body[\'error\'][\'message\']\n>                        elif \'message\' in resp_body:\n>                            message = resp_body[\'message\']\n> \n> Standardization here from the API WG would be really great.\n> \n> 	-Sean\n> \n> On 01/29/2015 09:11 AM, Roman Podoliaka wrote:\n>> Hi Anne,\n>> \n>> I think Eugeniya refers to a problem, that we can\'t really distinguish\n>> between two different  badRequest (400) errors (e.g. wrong security\n>> group name vs wrong key pair name when starting an instance), unless\n>> we parse the error description, which might be error prone.\n>> \n>> Thanks,\n>> Roman\n>> \n>> On Thu, Jan 29, 2015 at 6:46 PM, Anne Gentle\n>> <annegentle at justwriteclick.com> wrote:\n>>> \n>>> \n>>> On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova\n>>> <ekudryashova at mirantis.com> wrote:\n>>>> \n>>>> Hi, all\n>>>> \n>>>> \n>>>> Openstack APIs interact with each other and external systems partially by\n>>>> passing of HTTP errors. The only valuable difference between types of\n>>>> exceptions is HTTP-codes, but current codes are generalized, so external\n>>>> system can?t distinguish what actually happened.\n>>>> \n>>>> \n>>>> As an example two different failures below differs only by error message:\n>>>> \n>>>> \n>>>> request:\n>>>> \n>>>> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1\n>>>> \n>>>> Host: 192.168.122.195:8774\n>>>> \n>>>> X-Auth-Project-Id: demo\n>>>> \n>>>> Accept-Encoding: gzip, deflate, compress\n>>>> \n>>>> Content-Length: 189\n>>>> \n>>>> Accept: application/json\n>>>> \n>>>> User-Agent: python-novaclient\n>>>> \n>>>> X-Auth-Token: 2cfeb9283d784cfba694f3122ef413bf\n>>>> \n>>>> Content-Type: application/json\n>>>> \n>>>> \n>>>> {\"server\": {\"name\": \"demo\", \"imageRef\":\n>>>> \"171c9d7d-3912-4547-b2a5-ea157eb08622\", \"key_name\": \"test\", \"flavorRef\":\n>>>> \"42\", \"max_count\": 1, \"min_count\": 1, \"security_groups\": [{\"name\": \"bar\"}]}}\n>>>> \n>>>> response:\n>>>> \n>>>>    HTTP/1.1 400 Bad Request\n>>>> \n>>>> Content-Length: 118\n>>>> \n>>>> Content-Type: application/json; charset=UTF-8\n>>>> \n>>>> X-Compute-Request-Id: req-a995e1fc-7ea4-4305-a7ae-c569169936c0\n>>>> \n>>>> Date: Fri, 23 Jan 2015 10:43:33 GMT\n>>>> \n>>>> \n>>>> {\"badRequest\": {\"message\": \"Security group bar not found for project\n>>>> 790f5693e97a40d38c4d5bfdc45acb09.\", \"code\": 400}}\n>>>> \n>>>> \n>>>> and\n>>>> \n>>>> \n>>>> request:\n>>>> \n>>>> POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1\n>>>> \n>>>> Host: 192.168.122.195:8774\n>>>> \n>>>> X-Auth-Project-Id: demo\n>>>> \n>>>> Accept-Encoding: gzip, deflate, compress\n>>>> \n>>>> Content-Length: 192\n>>>> \n>>>> Accept: application/json\n>>>> \n>>>> User-Agent: python-novaclient\n>>>> \n>>>> X-Auth-Token: 24c0d30ff76c42e0ae160fa93db8cf71\n>>>> \n>>>> Content-Type: application/json\n>>>> \n>>>> \n>>>> {\"server\": {\"name\": \"demo\", \"imageRef\":\n>>>> \"171c9d7d-3912-4547-b2a5-ea157eb08622\", \"key_name\": \"foo\", \"flavorRef\":\n>>>> \"42\", \"max_count\": 1, \"min_count\": 1, \"security_groups\": [{\"name\":\n>>>> \"default\"}]}}\n>>>> \n>>>> response:\n>>>> \n>>>> HTTP/1.1 400 Bad Request\n>>>> \n>>>> Content-Length: 70\n>>>> \n>>>> Content-Type: application/json; charset=UTF-8\n>>>> \n>>>> X-Compute-Request-Id: req-87604089-7071-40a7-a34b-7bc56d0551f5\n>>>> \n>>>> Date: Fri, 23 Jan 2015 10:39:43 GMT\n>>>> \n>>>> \n>>>> {\"badRequest\": {\"message\": \"Invalid key_name provided.\", \"code\": 400}}\n>>>> \n>>>> \n>>>> The former specifies an incorrect security group name, and the latter an\n>>>> incorrect keypair name. And the problem is, that just looking at the\n>>>> response body and HTTP response code an external system can?t understand\n>>>> what exactly went wrong. And parsing of error messages here is not the way\n>>>> we?d like to solve this problem.\n>>> \n>>> \n>>> For the Compute API v 2 we have the shortened Error Code in the\n>>> documentation at\n>>> http://developer.openstack.org/api-ref-compute-v2.html#compute_server-addresses\n>>> \n>>> such as:\n>>> \n>>> Error response codes\n>>> computeFault (400, 500, ?), serviceUnavailable (503), badRequest (400),\n>>> unauthorized (401), forbidden (403), badMethod (405), overLimit (413),\n>>> itemNotFound (404), buildInProgress (409)\n>>> \n>>> Thanks to a recent update (well, last fall) to our build tool for docs.\n>>> \n>>> What we don\'t have is a table in the docs saying \"computeFault has this\n>>> longer Description\" -- is that what you are asking for, for all OpenStack\n>>> APIs?\n>>> \n>>> Tell me more.\n>>> \n>>> Anne\n>>> \n>>> \n>>>> \n>>>> \n>>>> Another example for solving this problem is AWS EC2 exception codes [1]\n>>>> \n>>>> \n>>>> So if we have some service based on Openstack projects it would be useful\n>>>> to have some concrete error codes(textual or numeric), which could allow to\n>>>> define what actually goes wrong and later correctly process obtained\n>>>> exception. These codes should be predefined for each exception, have\n>>>> documented structure and allow to parse exception correctly in each step of\n>>>> exception handling.\n>>>> \n>>>> \n>>>> So I?d like to discuss implementing such codes and its usage in openstack\n>>>> projects.\n>>>> \n>>>> \n>>>> [1] -\n>>>> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html\n>>>> \n>>>> __________________________________________________________________________\n>>>> OpenStack Development Mailing List (not for usage questions)\n>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>> \n>>> \n>>> \n>>> --\n>>> Anne Gentle\n>>> annegentle at justwriteclick.com\n>>> \n>>> __________________________________________________________________________\n>>> OpenStack Development Mailing List (not for usage questions)\n>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> \n>> __________________________________________________________________________\n>> OpenStack Development Mailing List (not for usage questions)\n>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150129/a86064b8/attachment.pgp>\n\n','<54CA70D2.5080003@dague.net>',NULL),('<10bad612e2df4488b2c71a37c4607413@HKNPR01MB241.apcprd01.prod.exchangelabs.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 05:30:16',0,'2014-07-17 05:30:16',NULL,'[openstack-dev] [Cinder] Integrated with iSCSI target Question','Dear Kanagaraj,\n\nThanks for your reply.\nI installed it at compute node before, and it doesn\'t work.\nI will try it again at controller node.\n\n\nThanks,\nJohnson\n\nFrom: Manickam, Kanagaraj [mailto:kanagaraj.manickam at hp.com]\nSent: Thursday, July 17, 2014 1:19 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question\n\nI think, It should be on the cinder node which is usually deployed on the controller node\n\nFrom: Johnson Cheng [mailto:Johnson.Cheng at QsanTechnology.com]\nSent: Thursday, July 17, 2014 10:38 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [Cinder] Integrated with iSCSI target Question\n\nDear All,\n\nI have three nodes, a controller node and two compute nodes(volume node).\nThe default value for iscsi_helper in cinder.conf is \"tgtadm\", I will change to \"ietadm\" to integrate with iSCSI target.\nUnfortunately I am not sure that iscsitarget should be installed at controller node or compute node?\nHave any reference?\n\n\nRegards,\nJohnson\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/08a6790f/attachment.html>\n\n','<D829F158B90303479A71BCAA89E1E7602339ECEB@G9W0723.americas.hpqcorp.net>',NULL),('<10c1781f909862ea52af43bdb1d0e768@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-13 16:23:08',3600,'2013-11-13 15:23:08',NULL,'[Openstack-docs] A bit more info about CLI in the install guide?','Le 13/11/2013 15:43, Andreas Jaeger a ?crit?:\n> On 11/13/2013 12:22 AM, Gauvain Pocentek wrote:\n>>\n>>\n>> Le 13/11/2013 04:16, Lorin Hochstein a ?crit :\n>>> On Tue, Nov 12, 2013 at 10:44 AM, Gauvain Pocentek\n>>> <gauvain.pocentek at objectif-libre.com> wrote:\n>>>\n>>>> Hello all,\n>>>>\n>>>> I\'ve started to work on\n>>>> https://bugs.launchpad.net/openstack-manuals/+bug/1245946 [1], but\n>>>> there seems to be a more general problem about the install guide \n>>>> than\n>>>> the problem described in this bug. It\'s not clear in the guide \n>>>> that\n>>>> CLI tools can be used everywhere, including outside of the OS\n>>>> servers. You don\'t want to log on the servers to issue user \n>>>> commands\n>>>> in production :)\n>>>>\n>>>> So I believe this should be documented in the install guide. My\n>>>> question is, where? Does this deserve a small section? Would a \n>>>> note\n>>>> be enough?\n>>>>\n>>>> Would love some advice on this!\n>>>\n>>> My instinct would be to add a chapter before \"Configure the \n>>> Identity\n>>> Service\" that describes how the CLI tools can be run from anywhere,\n>>> assuming that the credentials are set correctly, the relevant API\n>>> service is up and running, and that the API service is reachable \n>>> from\n>>> the client.\n>>\n>> Thanks for your feedback. If there\'s no objection from others I\'ll \n>> get\n>> started on that.\n>\n>\n> The End User Guide has already some content, I suggest you have a \n> look\n> whether you can reuse/share content some like:\n> http://docs.openstack.org/user-guide/content/cli_openrc.html\n\nYep, that was the plan. I\'ll see if I can manage to use common \nfiles/data.\n\nThanks,\nGauvain\n\n\n\n-- \nGauvain Pocentek\n\nObjectif Libre - Infrastructure et Formations Linux\nhttp://www.objectif-libre.com\n\n\n','<52839021.6060909@suse.com>',NULL),('<10c401cdc0b3$aed70ae0$0c8520a0$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-12 12:57:01',14400,'2012-11-12 08:57:01',NULL,'[openstack-dev] [quantum][LBaaS] question on LBaaS API','Hi Youcef,\n\n \n\n>From LBaaS API spec (http://wiki.openstack.org/Quantum/LBaaS/API_1.0) I see\nthat \"connection_limit\" field is not mandatory when creating a vip and is\nnot returned in create responses while is returned in list vips responses.\n\nCould you please clarify the status of this field, is it mandatory or not in\ncreate requests, and if not then what is the default value for it?\n\n \n\nThanks,\n\nOleg\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/356ff5fc/attachment.html>\n\n',NULL,NULL),('<10c5543d2ae944de87aff839e11b8cdf@AMSPR05MB406.eurprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-24 08:51:21',0,'2014-08-24 08:51:21',NULL,'[openstack-dev] [neutron][ml2] Openvswitch agent support for\n non promic mode adapters','Hi Andreas,\nThank you for this initiative.\nWe were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. \nPlease let me know if you would like to collaborate on this effort.\n\nBR,\nIrena\n\n-----Original Message-----\nFrom: Andreas Scheuring [mailto:scheuran at linux.vnet.ibm.com] \nSent: Friday, August 22, 2014 11:16 AM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters\n\nThanks for your feedback. \n\nNo, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. \nBut if that helps I can sit down and start some prototyping while I\'m preparing a blueprint spec in parallel. \n\nThe main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community.\nBut of course advice and feedback of experienced neutron developers is essential!\n\nSo I will proceed like this\n- Create a blueprint\n- Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc)\n- Upload a spec (as soon as the repo is available for K)\n\nDoes that make sense for you?\n\nThanks,\nAndreas\n\n\n\nOn Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:\n> I think this sounds reasonable. Do you have code for this already, or \n> are you looking for a developer to help implement it?\n> \n> \n> On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring \n> <scheuran at linux.vnet.ibm.com> wrote:\n>         Hi,\n>         last week I started discussing an extension to the existing\n>         neutron\n>         openvswitch agent to support network adapters that are not in\n>         promiscuous mode. Now I would like to enhance the round to get\n>         feedback\n>         from a broader audience via the mailing list.\n>         \n>         \n>         The Problem\n>         When driving vlan or flat networking, openvswitch requires an\n>         network\n>         adapter in promiscuous mode.\n>         \n>         \n>         Why not having promiscuous mode in your adapter?\n>         - Admins like to have full control over their environment and\n>         which\n>         network packets enter the system.\n>         - The network adapter just does not have support for it.\n>         \n>         \n>         What to do?\n>         Linux net-dev driver offer an interface to manually register\n>         additional\n>         mac addresses (also called secondary unicast addresses).\n>         Exploiting this\n>         one can register additional mac addresses to the network\n>         adapter. This\n>         also works via a well known ip user space tool.\n>         \n>         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`\n>         \n>         \n>         What to do in openstack?\n>         As neutron is aware of all the mac addresses that are in use\n>         it\'s the\n>         perfect candidate for doing the mac registrations. The idea is\n>         to modify\n>         the neutron openvswitch agent that it does the registration on\n>         \"port\n>         add\" and \"port remove\" via the bridge command.\n>         There would be a new optional configuration parameter,\n>         something like\n>         \'non-promisc-mode\' that is by default set to false. Only when\n>         set to\n>         true, macs get manually registered. Otherwise the agent\n>         behaves like it\n>         does today. So I guess only very little changes to the agent\n>         code are\n>         required. From my current point of view we do not need any\n>         changes to\n>         the ml2 plug-in.\n>         \n>         \n>         Blueprint or a bug?\n>         I guess it\'s a blueprint.\n>         \n>         What\'s the timeframe?\n>         K would be great.\n>         \n>         \n>         \n>         I would be thankful for any feedback on this! Feel free to\n>         contact me\n>         anytime. Thanks in advance!\n>         \n>         Regards,\n>         Andreas\n>         \n>         (irc: scheuran)\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> --\n> Kevin Benton\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1408695384.4496.14.camel@oc5515017671.ibm.com>',NULL),('<10C5B170-013B-4EB8-A97C-D3945842AFF3@yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 12:35:37',28800,'2013-08-20 04:35:37',NULL,'[Openstack] Floating ip to VMs','I am afraid we can not with neutron now\n\n???? iPhone\n\n? 2013-8-19???9:18?Jitendra Bhaskar <jeetuindian at gmail.com> ???\n\n> So is there any other  way or plugin  so that vm will get floating ip at boot time ?\n> \n> \n> On Mon, Aug 19, 2013 at 6:28 PM, Salvatore Orlando <sorlando at nicira.com> wrote:\n>> That is correct - the blueprint that would add this feature is the one linked by Cristian.\n>> \n>> however, please note that now this blueprint has been untargeted from Havana and it has no assignee.\n>> \n>> Salvatore\n>> \n>> \n>> On 19 August 2013 14:46, Cristian Falcas <cristi.falcas at gmail.com> wrote:\n>>> Can\'t be done yet with quantum, from what I know.\n>>> \n>>> \n>>> On Mon, Aug 19, 2013 at 3:45 PM, Jitendra Bhaskar <jeetuindian at gmail.com> wrote:\n>>> > Hi Cristi,\n>>> >\n>>> > Automatically means at boot time..\n>>> >\n>>> >\n>>> >\n>>> >\n>>> > On Mon, Aug 19, 2013 at 5:57 PM, Cristian Falcas <cristi.falcas at gmail.com>\n>>> > wrote:\n>>> >>\n>>> >> automaticaly you mean?\n>>> >>\n>>> >> It looks like it will be available in havana release:\n>>> >> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip\n>>> >>\n>>> >>\n>>> >> On Sun, Aug 18, 2013 at 8:43 PM, Jitendra Bhaskar <jeetuindian at gmail.com>\n>>> >> wrote:\n>>> >> > Hi,\n>>> >> >\n>>> >> > I am using openstack grizzly with three nodes controller, network and\n>>> >> > compute. I want to assign floating ip to vms at boot time, by using\n>>> >> > quantum\n>>> >> > for network. I am unable to get proper document. Can any body suggest\n>>> >> > how to\n>>> >> > proceed.\n>>> >> >\n>>> >> >\n>>> >> > --\n>>> >> >  Thanks & Regards\n>>> >> > Jitendra Kumar Bhaskar\n>>> >> > Cell:- +91 7306311531\n>>> >> >       :- +91 9989743042\n>>> >> >\n>>> >> >\n>>> >> > _______________________________________________\n>>> >> > Mailing list:\n>>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> >> > Post to     : openstack at lists.openstack.org\n>>> >> > Unsubscribe :\n>>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> >> >\n>>> >\n>>> >\n>>> >\n>>> >\n>>> > --\n>>> >  Thanks & Regards\n>>> > Jitendra Kumar Bhaskar\n>>> > Cell:- +91 7306311531\n>>> >       :- +91 9989743042\n>>> >\n>>> \n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n> -- \n>  Thanks & Regards  \n> Jitendra Kumar Bhaskar\n> Cell:- +91 7306311531\n>       :- +91 9989743042\n>          \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/56935e4e/attachment.html>\n\n','<CALucydkvRf+wxtnO9fQty9oivPG8hJpFWr5LD5dZeK9=LiG48A@mail.gmail.com>',NULL),('<10D527F6-FF20-4289-8478-3189FCFF89BC@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 01:16:48',32400,'2013-12-03 16:16:48',NULL,'[openstack-dev] [Neutron] Tuning QueuePool parameters?','I recently ran into this bug while trying to concurrently boot a large number (75) of VMs: \n\nhttps://bugs.launchpad.net/neutron/+bug/1160442\n\nI see that the fix for the bug added configuration of SQLAlchemy QueuePool parameters that should prevent the boot failures I was seeing.  However, I don\'t see a good explanation on the bug as to what values to set the configuration to or why the defaults weren\'t updated to something sane.  If that information is available somewhere, please share!  I\'m not sure why this bug is considered fixed if it\'s still possible to trigger it with no clear path to resolution.\n\n\nMaru\n\n\n\n',NULL,NULL),('<10D8BCBF-4C16-477F-AF0A-F70CB54C5C3B@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 18:05:21',-18000,'2014-01-21 23:05:21',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 -\n	Roles','\nOn Jan 21, 2014, at 9:40 AM, Dougal Matthews <dougal at redhat.com> wrote:\n\n> On 21/01/14 14:19, Jaromir Coufal wrote:\n>> when I was getting feedback on wireframes and we talked about Roles,\n>> there were various objections and not much suggestions. I would love to\n>> call for action and think a bit about the term for concept currently\n>> known as Role (= Resource Category).\n> \n> This indeed a bit confusing, I think Role has mostly been rejected and I\'ve seen Resource Category used the most since.\n> \n> \n>> So far suggested terms:\n>> * Role *\n>>   - short name - plus points\n>>   - quite overloaded term (user role, etc)\n> \n> -1 for Role, I don\'t think short is a good enough reason.\n\nAgreed. Role is overloaded IMO.\n> \n> \n>> * Resource Category *\n>>   - pretty long (devs already shorten it - confusing)\n>>   - Heat specific term\n> \n> +0, I\'ge gotten used to this, its quite long, but its not that bad.\n> \n> \n>> \n>> * Resource Class *\n>>   - older term\n> \n> -0, this strikes me as confusing as what we are defining now is somewhat different to what a Resource Class was. However, if we can clear it up this name is otherwise fine.\n> \n> \n>> Are there any other suggestions (ideally something short and accurate)?\n> \n> I\'ll throw out a couple to start ideas -\n> \n> - Resource Role (people seem to like Resource and role! ;-) )\n> - Resource Group\n> - Role Type\n\nHow about Instance Type? I?m looking at page 10 of the latest wireframes [1] and I see we are using the terms ?Resource?, ?Node?, and ?Instance? to labels certain items. I?m pretty sure Node and Instance are different, but I?m wondering if we need to introduce Resource as a new term.\n\nMy thoughts,\nLiz\n[1]http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-20_tripleo-ui-icehouse.pdf\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<52DE86F0.5000301@redhat.com>',NULL),('<10eb325c19d743fcb2e966e028ea42cd@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-21 11:38:00',-18000,'2014-03-21 16:38:00',NULL,'[openstack-dev] [TripleO] test environment requirements','On 2014-03-21 10:57, Derek Higgins wrote:\n> On 14/03/14 20:16, Ben Nemec wrote:\n>> On 2014-03-13 11:12, James Slagle wrote:\n>>> On Thu, Mar 13, 2014 at 2:51 AM, Robert Collins\n>>> <robertc at robertcollins.net> wrote:\n>>>> So we already have pretty high requirements - its basically a 16G\n>>>> workstation as minimum.\n>>>>\n>>>> Specifically to test the full story:\n>>>>  - a seed VM\n>>>>  - an undercloud VM (bm deploy infra)\n>>>>  - 1 overcloud control VM\n>>>>  - 2 overcloud hypervisor VMs\n>>>> ====\n>>>>    5 VMs with 2+G RAM each.\n>>>>\n>>>> To test the overcloud alone against the seed we save 1 VM, to skip the\n>>>> overcloud we save 3.\n>>>>\n>>>> However, as HA matures we\'re about to add 4 more VMs: we need a HA\n>>>> control plane for both the under and overclouds:\n>>>>  - a seed VM\n>>>>  - 3 undercloud VMs (HA bm deploy infra)\n>>>>  - 3 overcloud control VMs (HA)\n>>>>  - 2 overcloud hypervisor VMs\n>>>> ====\n>>>>    9 VMs with 2+G RAM each == 18GB\n>>>>\n>>>> What should we do about this?\n>>>>\n>>>> A few thoughts to kick start discussion:\n>>>>  - use Ironic to test across multiple machines (involves tunnelling\n>>>> brbm across machines, fairly easy)\n>>>>  - shrink the VM sizes (causes thrashing)\n>>>>  - tell folk to toughen up and get bigger machines (ahahahahaha, no)\n>>>>  - make the default configuration inline the hypervisors on the\n>>>> overcloud with the control plane:\n>>>>    - a seed VM\n>>>>    - 3 undercloud VMs (HA bm deploy infra)\n>>>>    - 3 overcloud all-in-one VMs (HA)\n>>>>   ====\n>>>>      7 VMs with 2+G RAM each == 14GB\n>>>>\n>>>>\n>>>> I think its important that we exercise features like HA and live\n>>>> migration regularly by developers, so I\'m quite keen to have a fairly\n>>>> solid systematic answer that will let us catch things like bad\n>>>> firewall rules on the control node preventing network tunnelling\n>>>> etc... e.g. we benefit the more things are split out like scale\n>>>> deployments are. OTOH testing the micro-cloud that folk may start with\n>>>> is also a really good idea....\n>>>\n>>>\n>>> The idea I was thinking was to make a testenv host available to\n>>> tripleo atc\'s. Or, perhaps make it a bit more locked down and only\n>>> available to a new group of tripleo folk, existing somewhere between\n>>> the privileges of tripleo atc\'s and tripleo-cd-admins.  We could\n>>> document how you use the cloud (Red Hat\'s or HP\'s) rack to start up a\n>>> instance to run devtest on one of the compute hosts, request and lock\n>>> yourself a testenv environment on one of the testenv hosts, etc.\n>>> Basically, how our CI works. Although I think we\'d want different\n>>> testenv hosts for development vs what runs the CI, and would need to\n>>> make sure everything was locked down appropriately security-wise.\n>>>\n>>> Some other ideas:\n>>>\n>>> - Allow an option to get rid of the seed VM, or make it so that you\n>>> can shut it down after the Undercloud is up. This only really gets rid\n>>> of 1 VM though, so it doesn\'t buy you much nor solve any long term\n>>> problem.\n>>>\n>>> - Make it easier to see how you\'d use virsh against any libvirt host\n>>> you might have lying around.  We already have the setting exposed, but\n>>> make it a bit more public and call it out more in the docs. I\'ve\n>>> actually never tried it myself, but have been meaning to.\n>>>\n>>> - I\'m really reaching now, and this may be entirely unrealistic :),\n>>> but....somehow use the fake baremetal driver and expose a mechanism to\n>>> let the developer specify the already setup undercloud/overcloud\n>>> environment ahead of time.\n>>> For example:\n>>> * Build your undercloud images with the vm element since you won\'t be\n>>> PXE booting it\n>>> * Upload your images to a public cloud, and boot instances for them.\n>>> * Use this new mechanism when you run devtest (presumably running from\n>>> another instance in the same cloud)  to say \"I\'m using the fake\n>>> baremetal driver, and here are the  IP\'s of the undercloud instances\".\n>>> * Repeat steps for the overcloud (e.g., configure undercloud to use\n>>> fake baremetal driver, etc).\n>>> * Maybe it\'s not the fake baremetal driver, and instead a new driver\n>>> that is a noop for the pxe stuff, and the power_on implementation\n>>> powers on the cloud instances.\n>>> * Obviously if your aim is to test the pxe and disk deploy process\n>>> itself, this wouldn\'t work for you.\n>>> * Presumably said public cloud is OpenStack, so we\'ve also achieved\n>>> another layer of \"On OpenStack\".\n>>\n>> I actually spent quite a while looking into something like this last\n>> option when I first started on TripleO, because I had only one big\n>> server locally and it was running my OpenStack installation.  I was\n>> hoping to use it for my TripleO instances, and even went so far as to\n>> add support for OpenStack to the virtual power driver in baremetal.  I\n>> was never completely successful, but I did work through a number of\n>> problems:\n>>\n>> 1. Neutron didn\'t like allowing the DHCP/PXE traffic to let my seed\n>> serve to the undercloud.  I was able to get around this by using flat\n>> networking with a local bridge on the OpenStack system, but I\'m not sure\n>> if that\'s going to be possible on most public cloud providers.  There\n>> may very well be a less invasive way to configure Neutron to allow that,\n>> but I don\'t know how to do it.\n>>\n>> 2. Last time I checked, Nova doesn\'t support PXE booting instances so I\n>> had to use iPXE images to do the booting.  This doesn\'t work since we\n>> PXE boot every time an instance reboots and the iPXE image gets\n>> overwritten by the image deploy, so the instance doesn\'t boot properly\n>> after deployment.  This is where I stopped my investigation because I\n>> didn\'t want to start hacking up my OpenStack installation to get around\n>> the problem, but if we decided to go in this direction I don\'t think it\n>> would be terribly difficult to get support for this into Nova.  I know\n>> there have been proposed patches for it before, but I don\'t think there\n>> was ever much push behind them because it isn\'t something most people\n>> need to do.\n>>\n>> So if we can work through a couple of problems then in theory it should\n>> be possible to use OpenStack instances for TripleO development, which\n>> would let us do the cloudy thing and have someone else worry about the\n>> hardware.  The idea certainly has some appeal to me.\n> \n> I\'m tempted to say If we could pull this off it would be great but I\'m\n> worried it would differ too much from our target deployment method. We\n> would be spreading ourselves too thin trying to support this for\n> developers along with our traditional deployment method. Also if using\n> it is adopted by too many people the only thing exercising our target\n> deployment method would be CI. But I\'m interested in what other people\n> think.\n\nTo clarify my suggestion, I want to take James\'s idea a step further and\ndo the full PXE deploy to Nova instances.  So the only difference from\nour workflow now would be that instead of configuring your VM\'s with\nvirsh, you would do it with Nova and Neutron.\n\n-Ben\n\n\n','<532C6164.2060809@redhat.com>',NULL),('<10F3F0B8-EF2B-41E4-9E44-83E5BBD5E59F@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 21:35:10',0,'2014-01-15 21:35:10',NULL,'[openstack-dev] a \"common\" client library','\nOn Jan 15, 2014, at 1:37 PM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n\n> Several people have mentioned to me that they are interested in, or actively working on, code related to a \"common\" client library -- something meant to be reused directly as a basis for creating a common library for all of the openstack clients to use. There\'s a blueprint [1] in oslo, and I believe the keystone devs and unified CLI teams are probably interested in ensuring that the resulting API ends up meeting all of our various requirements.\n> \n> If you\'re interested in this effort, please subscribe to the blueprint and use that to coordinate efforts so we don\'t produce more than one common library. ;-)\n> \n> Thanks,\n> Doug\n> \n> \n> [1] https://blueprints.launchpad.net/oslo/+spec/common-client-library-2\n\n*raises hand* \n\nMe me! \n\nI?ve been talking to many contributors about the Developer Experience stuff I emailed out prior to the holidays and I was starting blueprint work, but this is a great pointer. I?m going to have to sync up with Alexei.\n\nI think solving this for openstack developers and maintainers as the blueprint says is a big win in terms of code reuse / maintenance and consistent but more so for *end-user developers* consuming openstack clouds.\n\nSome background - there?s some terminology mismatch but the rough idea is the same:\n\n* A centralized ?SDK? (Software Development Kit) would be built condensing the common code and logic and operations into a single namespace.\n\n* This SDK would be able to be used by ?downstream? CLIs - essentially the CLIs become a specialized front end - and in some cases, only an argparse or cliff front-end to the SDK methods located in the (for example) openstack.client.api.compute \n\n* The SDK would handle Auth, re-auth (expired tokens, etc) for long-lived clients - all of the openstack.client.api.** classes would accept an Auth object to delegate management / mocking of the Auth / service catalog stuff to. This means developers building applications (say for example, horizon) don?t need to worry about token/expired authentication/etc. \n\n* Simplify the dependency graph & code for the existing tools to enable single binary installs (py2exe, py2app, etc) for end users of the command line tools.\n\nShort version: if a developer wants to consume an openstack cloud; the would have a single SDK with minimal dependencies and import from a single namespace. An example application might look like:\n\nfrom openstack.api import AuthV2\nfrom openstack.api import ComputeV2\n\nmyauth = AuthV2(?., connect=True)\ncompute = ComputeV2(myauth)\n\ncompute.list_flavors()\n\nThis greatly improves the developer experience both internal to openstack and externally. Currently OpenStack has 22+ (counting stackforge) potential libraries a developer may need to install to use a full deployment of OpenStack:\n\n  * python-keystoneclient (identity)\n  * python-glanceclient (image)\n  * python-novaclient (compute)\n  * python-troveclient (database)\n  * python-neutronclient (network)\n  * python-ironicclient (bare metal)\n  * python-heatclient (orchestration)\n  * python-cinderclient (block storage)\n  * python-ceilometerclient (telemetry, metrics & billing)\n  * python-swiftclient (object storage)\n  * python-savannaclient (big data)\n  * python-openstackclient (meta client package)\n  * python-marconiclient (queueing)\n  * python-tuskarclient (tripleo / management)\n  * python-melangeclient (dead)\n  * python-barbicanclient (secrets)\n  * python-solumclient (ALM)\n  * python-muranoclient (application catalog)\n  * python-manilaclient (shared filesystems)\n  * python-libraclient (load balancers)\n  * python-climateclient (reservations)\n  * python-designateclient (Moniker/DNS)\n\nIf you exclude the above and look on PyPI:\n\nOn PyPi (client libraries/SDKs only, excluding the above - not maintained by openstack):\n\n * hpcloud-auth-openstack 1.0\n * python-openstackclient 0.2.2\n * rackspace-auth-openstack 1.1\n * posthaste 0.2.2\n * pyrax 1.6.2\n * serverherald 0.0.1\n * warm 0.3.1\n * vaporize 0.3.2\n * swiftsc (https://github.com/mkouhei/swiftsc)\n * bookofnova 0.007\n * nova-adminclient 0.1.8\n * python-quantumclient 2.2.4.3\n * python-stackhelper 0.0.7.1.gcab1eb0\n * swift-bench 1.0\n * swiftly 1.12\n * txAWS 0.2.3 \n * cfupload 0.5.1\n * python-reddwarfclient 0.1.2\n * python-automationclient 1.2.1\n * rackspace-glanceclient 0.9\n * rackspace-novaclient 1.4\n\nIf you ignore PyPI and just want to install the base say - 7 services, each one of the python-** clients has its own dependency tree and may or may not build from one of the others. If a vendor wants to extend any of them, it?s basically a fork instead of a clean plugin system.\n\nOn the CLI front - this would *greatly* simplify the work openstackclient needs to do - it would be able to import from the main SDK and simply provide the noun-verb command line and any other end-user sugar it wanted to. Even if each service wanted to keep its own python-X client instead of relying on openstackclient it would be minimal to depend on the core SDK and then plugin/extend to build a specialized CLI for the project - if you really wanted, you could also extend openstackclient directly.\n\nRoughly this is the punch list I was looking at:\n\n1: a blueprint that explains the rationale behind unifying the Client code from the openstack clients; using a single REST interface, common object hierarchy, etc. \n2: A path for implementation of the common SDK including operational code\n\n4: dealing with a single binary cross platform for the CLI that derives from the common SDK (hard requirement) \n5: Standardization of names (e.g Compute != Nova, use the real names, not project names)\n6: Allow vendors to alias names for services to match their offerings\n\nI?ll begin working on the blueprint you pointed to - given this is more akin to a horizon-like UX project than a sub project of Oslo itself; does it really belong there? I do see the work within the individual clients:\n\nhttps://review.openstack.org/#/q/topic:bp/common-client-library-2,n,z\n\nJamie?s comments in:\n\nhttps://review.openstack.org/#/c/63164/\n\nDo concern me as I?d like to not do this as a lowest common denominator; in this case the client code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.\n\nthoughts welcome, I think the blueprint is a good start - I shot it out to all of us discussing this to take a look\n\njesse\n\n\n\n\n\n','<CADb+p3T2Az9iVLs8QMhqDU=0itgUVwP1jL6TZ23GmfUCcvoPJg@mail.gmail.com>',NULL),('<10F41464-A30C-4DBB-90FF-9B59776D8763@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-09-15 11:31:55',-18000,'2014-09-15 16:31:55',NULL,'[OpenStack Foundation] Platinum Membership Opening','Hi everyone,\n\nWhen the Foundation was launched, we randomly selected four of the eight Platinum Members to be categorized as Class A Platinum Members and the other four to be in Class B. Normally the Platinum Member term is three years, but for the initial term, Class A members have a slightly shorter term that ends December 31, 2014 per the Platinum Member Agreement (http://www.openstack.org/legal/platinum-member-policy/). Nebula was a Class A Platinum Member who has decided not to renew their membership beyond this year, although they may apply for Gold Membership starting in 2015.\n\nThis will result in an opening for Platinum Membership beginning January 1, 2015. The link referenced above covers the process for New Platinum Members to be elected in broad terms in Section 4. I?d like to have a discussion at the Board meeting on Thursday to determine how to handle new Platinum Member applications and will provide more detail after the meeting. One possible option is to expand the Gold Member Committee to cover Platinum Member openings as well. In reviewing the criteria, it doesn?t look like there is a lot that is extremely specific to the Gold Member class.\n\nThanks,\n\nJonathan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140915/16ab08a0/attachment.html>\n\n',NULL,NULL),('<10F55F0F0B764F4F8CD43FA142775613@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 17:16:56',-14400,'2012-09-25 21:16:56',NULL,'[openstack-dev] Quantum + ZeroMQ (with a sprinkling of Nova) in\n	Folsom','> Ok, how about just removing impl_zmq.py from Quantum?\n> \n> That way, we\'re only allowing zmq to be used in Nova and commit to\n> changing the message format in compatible ways\n> \n> How about zmq in Ceilometer and Cinder? Are they compatible with the\n> current Nova message format?\n> \n\n\nNeither has this patch, so they comply with the old message format. I believe Cinder should be good to go.\n\nCeilometer, at least in part, is using declare_topic_consumer (like Quantum does in one place), which is not supported in the ZeroMQ driver - declare_topic_consumer is a /private/ method part of the AMQP drivers.  Also, these patches signficantly improve the feasibility of using notifications at scale, on which Ceilometer seems to depend.\n\nRegards,\nEric Windisch\n\n\n\n\n\n','<1348606702.2264.53.camel@sorcha>',NULL),('<10f89fa92932c8d5383a363b274ae479@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-24 11:03:23',-18000,'2014-03-24 16:03:23',NULL,'[openstack-dev] Multiple patches in one review','On 2014-03-24 09:31, John Dennis wrote:\n> When a change is complex good practice is to break the change into a\n> series of smaller individual patches that show the individual\n> incremental steps needed to get to the final goal. When partitioned into\n> small steps each change is easier to review and hopefully illustrates\n> the progression.\n> \n> In most cases such a series of patches are interdependent and order\n> dependent, jenkins cannot run tests on any patch unless the previous\n> patch has been applied.\n> \n> I was under the impression gerrit review supported multiple commits. In\n> fact you can submit multiple commits with a single \"git review\" command.\n> \n> But from that point forward it appears as if each commit is handled\n> independently rather than being an ordered list of commits that are\n> grouped together sharing a single review where their relationship is\n> explicit. Also the jenkins tests either needs to apply all the commits\n> in sequence and run the test or it needs to run the test after applying\n> the next commit in the sequence.\n\nI should point out that Jenkins can\'t apply the next patch in sequence\njust to get tests passing.  What happens if the next patch never merges\nor has to be reverted?  Each commit needs to be able to pass tests using\nonly the previous commits in the sequence.  If it relies on a subsequent\ncommit then either the commits need to be reordered or, if there\'s a\ncircular dependency, maybe those commits aren\'t logically separate and\nshould just be squashed together.\n\n> \n> Can someone provide some explanation on how to handle this situation?\n> \n> Or perhaps I\'m just not understanding how the tools work when multiple\n> commits are submitted.\n\n\n','<533041D3.60902@redhat.com>',NULL),('<10FC818F-3E38-496B-9D70-F75F8B74D446@not.mn>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2014-12-19 08:21:36',-28800,'2014-12-19 16:21:36',NULL,'[openstack-announce] Swift 2.2.1 released','I\'m happy to announce the release of Swift 2.2.1. The work of 28 contributors (including 8 first-time contributors), this release is definitely operator-centric. I recommend that you upgrade; as always you can upgrade to this release with no customer downtime.\n\nGet the release: https://launchpad.net/swift/kilo/2.2.1\nFull change log: https://github.com/openstack/swift/blob/master/CHANGELOG\n\nBelow I\'ve highlighted a few of the more significant updates in this release.\n\n* Swift now rejects object names with unicode surrogates. These unicode code points are not able to be encoded as UTF-8, so they are now formally rejected.\n\n* Storage node error limits now survive a ring reload. Each Swift proxy server tracks errors when talking to a storage node. If a storage node sends too many errors, no further requests are sent to that node for a time. However, previously this error tracking was cleared with a ring reload, and a ring reload could happen frequently if some servers were being gradually added to the cluster. Now, the error tracking is not lost on ring reload, and error tracking is aggregated across storage polices. Basically, this means that the proxy server has a more accurate view of the health of the cluster and your cluster will be less stressed when you have failures and capacity adjustments at the same time.\n\n* Clean up empty account and container partitions directories if they are empty. This keeps the system healthy and prevents a large number of empty directories from (significantly) slowing down the replication process.\n\n* Swift now includes a full translation for Simplified Chinese (zh_CN locale).\n\nI\'d like to thank all of the Swift contributors for helping with this release. I\'d especially like to thank the first-time contributors listed below:\n\nCedric Dos Santos\nMartin Geisler\nFilippo Giunchedi\nGregory Haynes\nDaisuke Morita\nHisashi Osanai\nShilla Saebi\nPearl Yajing Tan\n\n\nThank you, and have a happy holiday season.\n\n\nJohn\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20141219/d8e63f8c/attachment.pgp>\n\n',NULL,NULL),('<10FC818F-3E38-496B-9D70-F75F8B74D446@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-19 08:21:36',-28800,'2014-12-19 16:21:36',NULL,'[openstack-dev] Swift 2.2.1 released','I\'m happy to announce the release of Swift 2.2.1. The work of 28 contributors (including 8 first-time contributors), this release is definitely operator-centric. I recommend that you upgrade; as always you can upgrade to this release with no customer downtime.\n\nGet the release: https://launchpad.net/swift/kilo/2.2.1\nFull change log: https://github.com/openstack/swift/blob/master/CHANGELOG\n\nBelow I\'ve highlighted a few of the more significant updates in this release.\n\n* Swift now rejects object names with unicode surrogates. These unicode code points are not able to be encoded as UTF-8, so they are now formally rejected.\n\n* Storage node error limits now survive a ring reload. Each Swift proxy server tracks errors when talking to a storage node. If a storage node sends too many errors, no further requests are sent to that node for a time. However, previously this error tracking was cleared with a ring reload, and a ring reload could happen frequently if some servers were being gradually added to the cluster. Now, the error tracking is not lost on ring reload, and error tracking is aggregated across storage polices. Basically, this means that the proxy server has a more accurate view of the health of the cluster and your cluster will be less stressed when you have failures and capacity adjustments at the same time.\n\n* Clean up empty account and container partitions directories if they are empty. This keeps the system healthy and prevents a large number of empty directories from (significantly) slowing down the replication process.\n\n* Swift now includes a full translation for Simplified Chinese (zh_CN locale).\n\nI\'d like to thank all of the Swift contributors for helping with this release. I\'d especially like to thank the first-time contributors listed below:\n\nCedric Dos Santos\nMartin Geisler\nFilippo Giunchedi\nGregory Haynes\nDaisuke Morita\nHisashi Osanai\nShilla Saebi\nPearl Yajing Tan\n\n\nThank you, and have a happy holiday season.\n\n\nJohn\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141219/d8e63f8c/attachment.pgp>\n\n',NULL,NULL),('<10fd74dbffb42ac1797d74d9093c7879@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-15 23:18:45',7200,'2014-01-15 21:18:45',NULL,'[Openstack] CentOS Network Create problem',' Dear Dimitri and all,\n  do you define the static IP for br100 somewhere or not???\n\n Here is what I have:\n\n COMPUTE NODE\n ------------\n # cat /etc/sysconfig/network-scripts/ifcfg-br100\n DEVICE=\"br100\"\n BOOTPROTO=\"static\"\n NM_CONTROLLED=\"no\"\n ONBOOT=\"yes\"\n TYPE=\"Bridge\"\n NAME=\"System br100\"\n IPADDR=X.X.X.210\n NETMASK=255.255.255.128\n GATEWAY=X.X.X.129\n IPV4_FAILURE_FATAL=\"yes\"\n IPV6INIT=\"no\"\n STP=\"no\"\n\n\n\n # brctl show\n bridge name	bridge id		STP enabled	interfaces\n br100           8000.002590365e70	no		eth0\n 							vnet0\n virbr0		8000.525400b535e0	yes		virbr0-nic\n\n\n\n\n # ifconfig\n br100     Link encap:Ethernet  HWaddr 00:25:90:36:5E:70\n           inet addr:X.X.X.210  Bcast:X.X.X.255  Mask:255.255.255.128\n           inet6 addr: fe80::225:90ff:fe36:5e70/64 Scope:Link\n           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n           RX packets:22423 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:25143 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:0\n           RX bytes:9954532 (9.4 MiB)  TX bytes:7563119 (7.2 MiB)\n\n eth0      Link encap:Ethernet  HWaddr 00:25:90:36:5E:70\n           inet6 addr: fe80::225:90ff:fe36:5e70/64 Scope:Link\n           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n           RX packets:52829 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:31011 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:1000\n           RX bytes:13364272 (12.7 MiB)  TX bytes:8685313 (8.2 MiB)\n           Interrupt:16 Memory:fbce0000-fbd00000\n\n eth1      Link encap:Ethernet  HWaddr 00:25:90:36:5E:71\n           inet addr:192.168.0.11  Bcast:192.168.0.255  \n Mask:255.255.255.0\n           inet6 addr: fe80::225:90ff:fe36:5e71/64 Scope:Link\n           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n           RX packets:90957 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:90884 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:1000\n           RX bytes:27380732 (26.1 MiB)  TX bytes:22160433 (21.1 MiB)\n           Interrupt:17 Memory:fbde0000-fbe00000\n\n lo        Link encap:Local Loopback\n           inet addr:127.0.0.1  Mask:255.0.0.0\n           inet6 addr: ::1/128 Scope:Host\n           UP LOOPBACK RUNNING  MTU:16436  Metric:1\n           RX packets:187 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:187 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:0\n           RX bytes:28747 (28.0 KiB)  TX bytes:28747 (28.0 KiB)\n\n virbr0    Link encap:Ethernet  HWaddr 52:54:00:B5:35:E0\n           inet addr:192.168.122.1  Bcast:192.168.122.255  \n Mask:255.255.255.0\n           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n           RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:0\n           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)\n\n vnet0     Link encap:Ethernet  HWaddr FE:16:3E:D8:FB:75\n           inet6 addr: fe80::fc16:3eff:fed8:fb75/64 Scope:Link\n           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n           RX packets:138 errors:0 dropped:0 overruns:0 frame:0\n           TX packets:488 errors:0 dropped:0 overruns:0 carrier:0\n           collisions:0 txqueuelen:500\n           RX bytes:9056 (8.8 KiB)  TX bytes:38006 (37.1 KiB)\n\n\n\n # route -n\n Kernel IP routing table\n Destination     Gateway         Genmask         Flags Metric Ref    Use \n Iface\n X.X.X.128       0.0.0.0         255.255.255.128 U     0      0        0 \n br100\n 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 \n eth1\n 192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 \n virbr0\n 169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 \n eth0\n 169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 \n eth1\n 169.254.0.0     0.0.0.0         255.255.0.0     U     1008   0        0 \n br100\n 0.0.0.0         X.X.X.129       0.0.0.0         UG    0      0        0 \n br100\n\n\n CONTROLLER NODE\n ------------\n # nova list\n +--------------------------------------+--------+--------+------------+-------------+---------------------+\n | ID                                   | Name   | Status | Task State | \n Power State | Networks            |\n +--------------------------------------+--------+--------+------------+-------------+---------------------+\n | 84bc8a76-6213-4f3c-9ce1-214bc8762dee | cirrOS | ACTIVE | None       | \n Running     | vmnet=X.X.X.210     |\n +--------------------------------------+--------+--------+------------+-------------+---------------------+\n\n # ssh cirros at X.X.X.210\n ssh: connect to host X.X.X.210 port 22: No route to host\n\n # ping X.X.X.209\n PING X.X.X.209 (X.X.X.209) 56(84) bytes of data.\n From X.X.X.190 icmp_seq=2 Destination Host Unreachable\n From X.X.X.190 icmp_seq=3 Destination Host Unreachable\n From X.X.X.190 icmp_seq=4 Destination Host Unreachable\n ....(etc)\n\n\n\n I can ping the X.X.X.210 but that is because the br100 has static IP \n X.X.X.210 and if I flush the iptables I can login to the already \n available node and NOT at the CirrOS instance that should have the \n X.X.X.210 IP.\n\n\n Any ideas???\n\n Best,\n\n\n G.\n\n\n\n\n\n On Wed, 15 Jan 2014 12:29:30 -0600, Dimitri Maziuk wrote:\n> On 01/15/2014 08:23 AM, Georgios Dimitrakakis wrote:\n>> Hi again...Long day with OpenStack today...\n>>\n>> It seems that the problem with the br100 interface has been solved\n>> partially since I can launch an instance but I am not able to ssh \n>> nor\n>> ping the machine (although I have configured the security group \n>> rules).\n>\n> Here\'s what I have on a working node with 2 instances running. Ignore\n> virbr0, it\'s created by libvirt, vnet0 & 1 are the openstack \n> instances:\n>\n> # brctl show\n> bridge name     bridge id               STP enabled     interfaces\n> br100           8000.003048c53032       no              eth0\n>                                                         vnet0\n>                                                         vnet1\n> virbr0          8000.52540025455f       yes             virbr0-nic\n>\n> # ip a\n> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n>     inet 127.0.0.1/8 scope host lo\n>     inet6 ::1/128 scope host\n>        valid_lft forever preferred_lft forever\n> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast\n> state UNKNOWN qlen 1000\n>     link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff\n>     inet6 fe80::230:48ff:fec5:3032/64 scope link\n>        valid_lft forever preferred_lft forever\n> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen \n> 1000\n>     link/ether 00:30:48:c5:30:33 brd ff:ff:ff:ff:ff:ff\n> 4: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue \n> state\n> UNKNOWN\n>     link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff\n>     inet X.X.X.X/25 brd X.X.X.X scope global br100\n>     inet6 fe80::230:48ff:fec5:3032/64 scope link\n>        valid_lft forever preferred_lft forever\n> 5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue\n> state UNKNOWN\n>     link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff\n>     inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0\n> 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN \n> qlen 500\n>     link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff\n> 10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc \n> pfifo_fast\n> state UNKNOWN qlen 500\n>     link/ether fe:16:3e:48:30:5c brd ff:ff:ff:ff:ff:ff\n>     inet6 fe80::fc16:3eff:fe48:305c/64 scope link\n>        valid_lft forever preferred_lft forever\n> 38: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc \n> pfifo_fast\n> state UNKNOWN qlen 500\n>     link/ether fe:16:3e:16:b3:55 brd ff:ff:ff:ff:ff:ff\n>     inet6 fe80::fc16:3eff:fe16:b355/64 scope link\n>        valid_lft forever preferred_lft forever\n>\n> # lsmod | grep _net\n> vhost_net              30520  2\n> macvtap                 9980  1 vhost_net\n> tun                    17095  6 vhost_net\n>\n> (\"modprobe vhost_net\" if you don\'t have it.)\n>\n> # route -n\n> Kernel IP routing table\n> Destination   Gateway      Genmask         Flags Metric Ref  Use \n> Iface\n> X.X.X.X       0.0.0.0      255.255.255.128 U     0      0    0   \n> br100\n> 192.168.122.0 0.0.0.0      255.255.255.0   U     0      0    0   \n> virbr0\n> 169.254.0.0   0.0.0.0      255.255.0.0     U     1004   0    0   \n> br100\n> 0.0.0.0       X.X.X.X      0.0.0.0         UG    0      0    0   \n> br100\n>\n> You should have a route to your nova network in there (I use flat\n> network so my nova net is X.X.X.X, same as my \"real\" subnet).\n>\n> With all that in place try disabling iptables in the instance and\n> pinging the host. On the host, run tcpdump on vnet0 and br100 to see \n> if\n> you get any traffic. I didn\'t initially, I think modprobe vhost_net \n> was\n> what fixed it. (I was poking at & restarting several things at once, \n> so\n> I\'m not 100% sure exactly which of them did it.)\n\n-- \n\n\n','<52D6D38A.1020301@bmrb.wisc.edu>',NULL),('<1100166618.368.1367042671012.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:04:30',0,'2013-04-27 06:04:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal10 in workspace <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/>\nCheckout:periodic-glance-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 4e087ce1:quantal10\nUsing strategy: Default\nLast Built Revision: Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/glance.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/glance.git\nCommencing build of Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\nChecking out Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\n[periodic-glance-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson4206994633729061800.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack glance\n+ version=27\n+ org=openstack\n+ project=glance\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.u29W8IAB89\n+ TMPDIR=/tmp/tmp.u29W8IAB89\n+ trap \'rm -rf /tmp/tmp.u29W8IAB89\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack glance\n+ org=openstack\n+ project=glance\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' glance == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.glance.python27.stable.grizzly.17\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-glance-python27-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 56171 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-glance-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal10\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.u29W8IAB89\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'22270621-9451-4193-a291-998f134b8af4\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'43c5fdacd62ec6f4e78d466ac5905f2b581a476f\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal10\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 56171 166.78.63.171 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires> (line 4))\nNo distributions at all found for greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires> (line 4))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.u29W8IAB89\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1100423263.23367906.1370973733961.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 14:02:13',-14400,'2013-06-11 18:02:13',NULL,'[openstack-qa] Lowest resource hunger VM for parallel execution','The minimal resources we need for VM If does not really touch them (console output, ssh ..)\n- 1 MB RAM\n- 0.5 Mb disk\n- 2 CPU instruction in the VM (cli hlt) lifetime after seabios finishes.\n\nIt would help to minimalise the resources used by VM.\nWe could have much more VM in parallel, with minimal cost.\n\nWe only can use it for the minimalist API tests. ~ 2x 50 times, and for some existing whitebox test.\n\nOn a single thread tempest, but on multicore process these image has minimal benefits,\nOn  multi-thread they probably have more benefits.\n\n\n','<1042407281.23358723.1370973324076.JavaMail.root@redhat.com>',NULL),('<11004393.69.1386829816911.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:30:16',0,'2013-12-12 06:30:16',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-neutron-havana #6','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-havana/6/>\n\n\n\n','<1161040617.53.1386742466146.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1100700689.7.1377239463918.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-23 06:31:03',0,'2013-08-23 06:31:03',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #13','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/13/>\n\n------------------------------------------\n[...truncated 21863 lines...]\n++ head -1\n++ grep ex-vol-2fcef6e8\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1377238310\n+ cinder create --display_name ex-vol-2fcef6e8 --display_description \'test volume: ex-vol-2fcef6e8\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-23T06:11:51.108752      |\n| display_description |     test volume: ex-vol-2fcef6e8     |\n|     display_name    |           ex-vol-2fcef6e8            |\n|          id         | 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2fcef6e8 | grep available; do sleep 1; done\'\n| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | available | ex-vol-2fcef6e8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377238313\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-2fcef6e8\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | available | ex-vol-2fcef6e8 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=867061b7-fbf2-4d14-8ee6-1dfefc7368d9\n+ die_if_not_set 165 VOL_ID \'Failure retrieving volume ID for ex-vol-2fcef6e8\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1377238313\n+ nova volume-attach 396ec0ec-cf4e-4988-9972-dcbcda9bc18d 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 /dev/vdb\nERROR:root:Could not find any typelib for GnomeKeyring\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 396ec0ec-cf4e-4988-9972-dcbcda9bc18d |\n| id       | 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 |\n| volumeId | 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2fcef6e8 | grep in-use; do sleep 1; done\'\n| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | in-use | ex-vol-2fcef6e8 |  1   |     None    |  False   | 396ec0ec-cf4e-4988-9972-dcbcda9bc18d |\n++ date +%s\n+ end_time=1377238318\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ head -1\n++ grep ex-vol-2fcef6e8\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | in-use | ex-vol-2fcef6e8 |  1   |     None    |  False   | 396ec0ec-cf4e-4988-9972-dcbcda9bc18d |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=396ec0ec-cf4e-4988-9972-dcbcda9bc18d\n+ die_if_not_set 179 VOL_ATTACH \'Failure retrieving ex-vol-2fcef6e8 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 396ec0ec-cf4e-4988-9972-dcbcda9bc18d != 396ec0ec-cf4e-4988-9972-dcbcda9bc18d ]]\n++ date +%s\n+ start_time=1377238319\n+ nova volume-detach 396ec0ec-cf4e-4988-9972-dcbcda9bc18d 867061b7-fbf2-4d14-8ee6-1dfefc7368d9\nERROR:root:Could not find any typelib for GnomeKeyring\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-2fcef6e8 | grep available; do sleep 1; done\'\n| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | available | ex-vol-2fcef6e8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377238322\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1377238322\n+ cinder delete 867061b7-fbf2-4d14-8ee6-1dfefc7368d9\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-2fcef6e8; do sleep 1; done\'\n| 867061b7-fbf2-4d14-8ee6-1dfefc7368d9 | deleting | ex-vol-2fcef6e8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377238324\n+ echo \'Completed cinder delete in 2 seconds\'\nCompleted cinder delete in 2 seconds\n+ nova delete 396ec0ec-cf4e-4988-9972-dcbcda9bc18d\nERROR:root:Could not find any typelib for GnomeKeyring\n+ timeout 60 sh -c \'while nova list | grep -q 396ec0ec-cf4e-4988-9972-dcbcda9bc18d; do sleep 1; done\'\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\nERROR:root:Could not find any typelib for GnomeKeyring\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1596.g7395517.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpymas3b\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpu_DIag\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpNZTjHQ\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpODv1XU\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2473 tests in 890.919s\nFAILED (id=0, failures=2, skips=68)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-158705-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-158705.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-158705/13/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1462961421.2.1377169243613.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1101516324.36167.1379102808695.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-13 13:06:48',-25200,'2013-09-13 20:06:48',NULL,'[openstack-dev] [nova] [pci passthrough] how to fill\n instance_type_extra_specs for a pci passthrough?','> From: \"David Kang\" <dkang at isi.edu>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Friday, September 13, 2013 4:03:24 PM\n> Subject: [nova] [pci passthrough] how to fill instance_type_extra_specs for a pci passthrough?\n\n Sorry for the last empty mail.\nI cannot find a good document for how to describe pci passthrough in nova.conf.\n\n As an example, if I have the following entries in nova.conf, how should the instance_type_extra_specs must be?\n(The following entries are just for a test.)\n\npci_alias={\"name\":\"test\", \"product_id\":\"7190\", \"vendor_id\":\"8086\", \"device_type\":\"ACCEL\"}\npci_passthrough_whitelist=[{\"vendor_id\":\"8086\",\"product_id\":\"7190\"}]\n\n I\'ll appreciate any advice and/or pointer for the document.\n\n Thanks,\n David\n\n\n\n','<923432817.36155.1379102604801.JavaMail.root@zm.isi.edu>',NULL),('<1102280166.50.1352686010403.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-12 02:06:50',0,'2012-11-12 02:06:50',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #11','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/11/>\n\n------------------------------------------\n[...truncated 13044 lines...]\nTenant names should be unique ... ok\nCreate a tenant that is enabled ... ok\nCreate a tenant that is not enabled ... ok\nCreate tenant with a description ... ok\nCreate several tenants and delete them ... ok\nNon-admin user should not be able to delete a tenant ... ok\nRequest to delete a tenant without a valid token should fail ... ok\nUpdate description attribute of a tenant ... ok\nUpdate the enabled attribute of a tenant ... ok\nUpdate name attribute of a tenant ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nRegister a new remote image ... ok\nRegister, then upload an image ... ok\nNegative tests for invalid data supplied to POST /images ... ok\nSimple test to see all fixture images returned ... ok\nSKIP: No OpenStack Network API endpoint\nSKIP: No OpenStack Object Storage API endpoint\nSKIP: No OpenStack Object Storage API endpoint\nSKIP: No OpenStack Object Storage API endpoint\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ERROR\nERROR\nERROR\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nERROR: CREATE, GET, DELETE Volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/volumes/test_volumes_get.py\", line 68, in test_volume_create_get_delete\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 268, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\n\n======================================================================\nERROR: CREATE, GET empty metadata dict\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/volumes/test_volumes_get.py\", line 90, in test_volume_get_metadata_none\n    resp, _ = self.client.delete_volume(volume[\'id\'])\n  File \"/opt/stack/tempest/tempest/services/compute/xml/volumes_extensions_client.py\", line 118, in delete_volume\n    return self.delete(\"os-volumes/%s\" % str(volume_id))\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 169, in delete\n    return self.request(\'DELETE\', url, headers)\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 209, in request\n    resp_body = self._parse_resp(resp_body)\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 282, in _parse_resp\n    return xml_to_json(etree.fromstring(body))\n  File \"lxml.etree.pyx\", line 2754, in lxml.etree.fromstring (src/lxml/lxml.etree.c:54631)\n  File \"parser.pxi\", line 1578, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:82748)\n  File \"parser.pxi\", line 1457, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:81546)\n  File \"parser.pxi\", line 965, in lxml.etree._BaseParser._parseDoc (src/lxml/lxml.etree.c:78216)\n  File \"parser.pxi\", line 569, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:74472)\n  File \"parser.pxi\", line 650, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:75363)\n  File \"parser.pxi\", line 590, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:74696)\nXMLSyntaxError: Start tag expected, \'<\' not found, line 1, column 1\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.compute.volumes.test_volumes_list.VolumesTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/compute/volumes/test_volumes_list.py\", line 128, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/compute/json/volumes_extensions_client.py\", line 110, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Volume volume-%s249100json failed to reach available status within the required time (300.0 s).\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.compute.volumes.test_volumes_list.VolumesTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/compute/volumes/test_volumes_list.py\", line 82, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/compute/xml/volumes_extensions_client.py\", line 138, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Volume volume7838xml failed to reach available status within the required time (400.0 s).\n\n======================================================================\nERROR: Create a volume without passing metadata, get details, and delete\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_get.py\", line 95, in test_volume_get_metadata_none\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 268, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_list.py\", line 125, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/volume/json/volumes_client.py\", line 126, in wait_for_volume_status\n    raise exceptions.VolumeBuildErrorException(volume_id=volume_id)\nVolumeBuildErrorException: Volume 45119e38-d3bc-42bf-a700-584dbb7587e7 failed to build and is in ERROR status\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_list.py\", line 79, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/volume/json/volumes_client.py\", line 132, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Volume volume954126 failed to reach available status within the required time (300.0 s).\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 492 tests in 4652.378s\n\nFAILED (SKIP=53, errors=7)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/screen-swift.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/11/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<232663711.38.1352600983633.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<11026308.39221350910100641.JavaMail.weblogic@epml16>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-22 12:48:21',0,'2012-10-22 12:48:21',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','Hi, Eoghan,\nI made Synaps project page on launchpad today, like other projects of \nOpenStack. We\'re going to use its bug tracker and support tracker for \nworking with the community.\n https://launchpad.net/synaps\n\nHi, Endre,\nWe will surely  prepare documents including installation guide soon.\nHowever, we need some time again. Please be patient until it\'s ready.\nI expect that we need a few weeks for everything ready before opening\nSynaps (maybe in early Nov). Again I\'ll try to do my best to be fast.\n\nThanks for understanding,\nJoonwon Lee\n\n\n------- Original Message -------\nSender : Endre Karlson<endre.karlson at gmail.com>\nDate : 2012-10-22 03:46 (GMT+09:00)\nTitle : Re: [openstack-dev] Introducing Synaps project that provides AWS CloudWatch compatible API\n\nCan you please translate the install docs?\nDen 21. okt. 2012 19:42 skrev \"Eoghan Glynn\" <eoghan.glynn at gmail.com> f?lgende:\n\nThanks again for the quick progress on open sourcing this code.\n\nNow that the openstack summit is done & dusted, I\'ll be spending some\ntime standing up Synaps and doing an evaluation. So I should have some\ndetailed feedback during the coming week.\n\nIn the meantime, to get the ball rolling on community collaboration,\nI\'ve submitted a pull request for a small patch to address an issue I\nnoticed when reading the code:\n\n  https://github.com/spcs/synaps/pull/1\n\nBTW do you guys use any form of externally visible issue/bug tracker as yet?\n\nCheers,\nEoghan\n\n------- Original Message -------\n\nHi all,\n\nThank you for all your waiting. Synaps is now open sourced in public.\n\n - code: http://github.com/spcs/synaps\n - documents: http://spcs.github.com/synaps/\n\nI\'ll update the documents soon (including translation in english).\nI think there would be lots of rooms for improvement.\n\nThank you.\nJune Yi\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n',NULL,NULL),('<1102689426.114.1367907283396.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-07 06:14:43',0,'2013-05-07 06:14:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly-centos6 #7','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/7/>\n\n------------------------------------------\n[...truncated 3973 lines...]\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 489, in test_user_list_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:33225/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 823, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:44549/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 842, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:33174/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 496, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:55408/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 512, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:35032/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 34.22 secs:\n    7.40    TestTokenRevoking.test_group_membership_changes_revokes_token\n    7.00    KcEssex3TestCase.test_admin_requires_adminness\n    6.79    KcMasterTestCase.test_admin_requires_adminness\n    6.70    Kc11TestCase.test_admin_requires_adminness\n    6.33    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1272 tests in 464.997s\n\nFAILED (SKIP=82, errors=129)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.centos6.7\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=66\n+ \'[\' 66 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.owpxZi0qzS\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/7\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/7/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1452133997.79.1367820922066.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1103035550.19266689.1406132637232.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 12:23:57',-14400,'2014-07-23 16:23:57',NULL,'[openstack-dev] [NFV] Meeting Summary - 2014-07-23-14.00','Hi all,\n\nPlease find the summaries and full logs for today\'s NFV sub team meeting at these locations:\n\nSummary (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.html\nFull Log (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.log.html\nSummary (TXT): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.log.txt\nFully Log (TXT): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.txt\n\nThanks,\n\nSteve\n\n\n','<1132315458.19265765.1406132498653.JavaMail.zimbra@redhat.com>',NULL),('<1103078338.21.1378188497768.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-03 06:08:17',0,'2013-09-03 06:08:17',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #14','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/14/>\n\n------------------------------------------\n[...truncated 17322 lines...]\n2013-09-03 06:07:43 # This section contains the configuration options used when executing tests\n2013-09-03 06:07:43 # against the OpenStack Block Storage API service\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-03 06:07:43 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-03 06:07:43 # probably want to leave this value as \"volume\"\n2013-09-03 06:07:43 catalog_type = volume\n2013-09-03 06:07:43 # Number of seconds to wait while looping to check the status of a\n2013-09-03 06:07:43 # volume that is being made available\n2013-09-03 06:07:43 build_interval = 1\n2013-09-03 06:07:43 # Number of seconds to time out on waiting for a volume\n2013-09-03 06:07:43 # to be available or reach an expected status\n2013-09-03 06:07:43 build_timeout = 400\n2013-09-03 06:07:43 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-03 06:07:43 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-03 06:07:43 # have to be different)\n2013-09-03 06:07:43 multi_backend_enabled = false\n2013-09-03 06:07:43 backend1_name = BACKEND_1\n2013-09-03 06:07:43 backend2_name = BACKEND_2\n2013-09-03 06:07:43 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-03 06:07:43 # You should update to reflect those exported by configured backend driver.\n2013-09-03 06:07:43 storage_protocol = iSCSI\n2013-09-03 06:07:43 vendor_name = Open Source\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [object-storage]\n2013-09-03 06:07:43 # This section contains configuration options used when executing tests\n2013-09-03 06:07:43 # against the OpenStack Object Storage API.\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # You can configure the credentials in the compute section\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-03 06:07:43 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-03 06:07:43 # this value as \"object-store\"\n2013-09-03 06:07:43 catalog_type = object-store\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Number of seconds to time on waiting for a container to container\n2013-09-03 06:07:43 # synchronization complete\n2013-09-03 06:07:43 container_sync_timeout = 120\n2013-09-03 06:07:43 # Number of seconds to wait while looping to check the status of a\n2013-09-03 06:07:43 # container to container synchronization\n2013-09-03 06:07:43 container_sync_interval = 5\n2013-09-03 06:07:43 # Set to True if the Account Quota middleware is enabled\n2013-09-03 06:07:43 accounts_quotas_available = True\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Set operator role for tests that require creating a container\n2013-09-03 06:07:43 operator_role = Member\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [boto]\n2013-09-03 06:07:43 ssh_user = cirros\n2013-09-03 06:07:43 # This section contains configuration options used when executing tests\n2013-09-03 06:07:43 # with boto.\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # EC2 URL\n2013-09-03 06:07:43 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-03 06:07:43 # S3 URL\n2013-09-03 06:07:43 s3_url = http://127.0.0.1:3333\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-03 06:07:43 aws_access =\n2013-09-03 06:07:43 aws_secret =\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Image materials for S3 upload\n2013-09-03 06:07:43 # ALL content of the specified directory will be uploaded to S3\n2013-09-03 06:07:43 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-03 06:07:43 # Subdirectories not allowed!\n2013-09-03 06:07:43 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-03 06:07:43 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-03 06:07:43 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-03 06:07:43 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Instance type\n2013-09-03 06:07:43 instance_type = m1.nano\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # TCP/IP connection timeout\n2013-09-03 06:07:43 http_socket_timeout = 30\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Number of retries actions on connection or 5xx error\n2013-09-03 06:07:43 num_retries = 1\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Status change wait timout\n2013-09-03 06:07:43 build_timeout = 400\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Status change wait interval\n2013-09-03 06:07:43 build_interval = 1\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [orchestration]\n2013-09-03 06:07:43 # Status change wait interval\n2013-09-03 06:07:43 build_interval = 1\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Status change wait timout. This may vary across environments as some some\n2013-09-03 06:07:43 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-03 06:07:43 build_timeout = 300\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Instance type for tests. Needs to be big enough for a\n2013-09-03 06:07:43 # full OS plus the test workload\n2013-09-03 06:07:43 instance_type = m1.micro\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-03 06:07:43 # If not specified, tests that spawn instances will not run\n2013-09-03 06:07:43 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-03 06:07:43 # any key, which will generate a keypair for each test class\n2013-09-03 06:07:43 #keypair_name = heat_key\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [dashboard]\n2013-09-03 06:07:43 # URL where to find the dashboard home page\n2013-09-03 06:07:43 dashboard_url = http://127.0.0.1/\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # URL where to submit the login form\n2013-09-03 06:07:43 login_url = http://127.0.0.1/auth/login/\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [scenario]\n2013-09-03 06:07:43 # Directory containing image files\n2013-09-03 06:07:43 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # AMI image file name\n2013-09-03 06:07:43 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # ARI image file name\n2013-09-03 06:07:43 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # AKI image file name\n2013-09-03 06:07:43 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # ssh username for the image file\n2013-09-03 06:07:43 ssh_user = cirros\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 # specifies how many resources to request at once. Used for large operations\n2013-09-03 06:07:43 # testing.\"\n2013-09-03 06:07:43 large_ops_number = 0\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [cli]\n2013-09-03 06:07:43 # Enable cli tests\n2013-09-03 06:07:43 enabled = True\n2013-09-03 06:07:43 # directory where python client binaries are located\n2013-09-03 06:07:43 cli_dir = /usr/local/bin\n2013-09-03 06:07:43 # Number of seconds to wait on a CLI timeout\n2013-09-03 06:07:43 timeout = 15\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [service_available]\n2013-09-03 06:07:43 # Whether or not cinder is expected to be available\n2013-09-03 06:07:43 cinder = True\n2013-09-03 06:07:43 # Whether or not neutron is expected to be available\n2013-09-03 06:07:43 neutron = False\n2013-09-03 06:07:43 # Whether or not glance is expected to be available\n2013-09-03 06:07:43 glance = True\n2013-09-03 06:07:43 # Whether or not swift is expected to be available\n2013-09-03 06:07:43 swift = True\n2013-09-03 06:07:43 # Whether or not nova is expected to be available\n2013-09-03 06:07:43 nova = True\n2013-09-03 06:07:43 # Whether or not Heat is expected to be available\n2013-09-03 06:07:43 heat = True\n2013-09-03 06:07:43 # Whether or not horizon is expected to be available\n2013-09-03 06:07:43 horizon = True\n2013-09-03 06:07:43 \n2013-09-03 06:07:43 [stress]\n2013-09-03 06:07:43 # Maximum number of instances to create during test\n2013-09-03 06:07:43 max_instances = 32\n2013-09-03 06:07:43 # Time (in seconds) between log file error checks\n2013-09-03 06:07:43 log_check_interval = 60\n2013-09-03 06:07:43 # The default number of threads created while stress test\n2013-09-03 06:07:43 default_thread_number_per_action=4\n2013-09-03 06:07:43 ++ IFS=\' 	\n2013-09-03 06:07:43 \'\n2013-09-03 06:07:43 ++ set +o errexit\n2013-09-03 06:07:43 ++ init_tempest\n2013-09-03 06:07:43 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-03 06:07:43 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-03 06:07:43 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-03 06:07:43 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-03 06:07:43 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1660.ga87b64d.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-203430-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-203430.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-203430/14/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1016060275.20.1378112417145.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1103105741.469.1367129885643.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:18:05',0,'2013-04-28 06:18:05',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #209','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/209/>\n\n\n\n','<1742086121.374.1367042681587.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1103251932.38947685.1412185596091.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 13:46:36',-14400,'2014-10-01 17:46:36',NULL,'[openstack-dev] [Solum] Core Reviewer Change','+1\n\n----- Original Message -----\nFrom: \"Adrian Otto\" <adrian.otto at rackspace.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, September 30, 2014 10:03:16 AM\nSubject: [openstack-dev] [Solum] Core Reviewer Change\n\nSolum Core Reviewer Team,\n\nI propose the following change to our core reviewer group:\n\n-lifeless (Robert Collins) [inactive]\n+murali-allada (Murali Allada)\n+james-li (James Li)\n\nPlease let me know your votes (+1, 0, or -1).\n\nThanks,\n\nAdrian\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<8CD12D3B-B801-4B2D-BAAB-31123BC4ECD3@rackspace.com>',NULL),('<1103415607.15.1380610282408.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-01 06:51:22',0,'2013-10-01 06:51:22',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-grizzly #22','See <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/22/>\n\n------------------------------------------\n[...truncated 196 lines...]\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/ec2/test_cloud.py\",> line 2275, in test_describe_security_groups_by_id\n    self.cloud.delete_security_group(self.context, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/ec2/cloud.py\",> line 737, in delete_security_group\n    group_id)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 101, in get\n    id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_false\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 231, in test_associate_port_security_enabled_false\n    req, \'1\', body)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 394, in assertRaises\n    self.assertThat(our_callable, matcher)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 406, in assertThat\n    mismatch = matcher.match(matchee)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py\",> line 99, in match\n    mismatch = self.exception_matcher.match(exc_info)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_higherorder.py\",> line 61, in match\n    mismatch = matcher.match(matchee)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 386, in match\n    reraise(*matchee)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py\",> line 92, in match\n    result = matchee()\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 867, in __call__\n    return self._callable_object(*self._args, **self._kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate\ntags: worker-1\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 200, in test_associate\n    self.manager._addSecurityGroup(req, \'1\', body)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_true\ntags: worker-0\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 215, in test_associate_port_security_enabled_true\n    self.manager._addSecurityGroup(req, \'1\', body)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-0\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11328 tests in 246.730s\nFAILED (id=0, failures=13, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.8\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python27.stable.grizzly.22\nnumpy==1.7.1\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==2.0.1\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-quantumclient==2.2.4.2\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py27/bin/subunit-1to2\n+ .tox/py27/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_by_non_existing_security_group_name\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_disassociate\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_disassociate_by_non_existing_security_group_name\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_create_delete_security_group\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_describe_security_groups\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_describe_security_groups_by_id\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_false\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_true\nprocess-returncode\nprocess-returncode\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.wotm2AxKnG\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise36\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise36/22\n[SCP] Copying console log.\n\n\n','<586545786.11.1380521387444.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1103642068.57.1374818564121.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-26 06:02:44',0,'2013-07-26 06:02:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-grizzly #107','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/107/>\n\n------------------------------------------\n[...truncated 28 lines...]\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/107/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-grizzly-107\', \'SSH_CLIENT\': \'198.101.231.203 47218 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374091207.84347-824899917\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-26_06-00-29\', \'BUILD_NUMBER\': \'107\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'b838efd7-0db5-4b13-87b0-83851f194421\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'b163c97c4cd0fac6d851d5264df823a620e8f67e\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#107\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 47218 50.56.249.238 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth>=1.0.7,!=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package netaddr\n    \n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-cinderclient>=1.0.2,<2.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-QxP8Uk/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-QxP8Uk/d2to1-0.2.10/egg-dist-tmp-SDtZ9R\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-qPWEXv/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-qPWEXv/setuptools-git-1.0/egg-dist-tmp-vx2yh4\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.12.0,<3 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-9A4NwX/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-9A4NwX/d2to1-0.2.10/egg-dist-tmp-1koT05\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-dTj8ni/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-dTj8ni/setuptools-git-1.0/egg-dist-tmp-FYkx10\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-RjMhaZ/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-RjMhaZ/d2to1-0.2.10/egg-dist-tmp-9BFDyI\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-jOepwe/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-jOepwe/setuptools-git-1.0/egg-dist-tmp-GCRFUt\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-grizzly/107\n[SCP] Copying console log.\n\n\n','<1249091998.45.1374732149098.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1104064076.210.1354579929525.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-04 00:12:09',0,'2012-12-04 00:12:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #64','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/64/>\n\n------------------------------------------\n[...truncated 901 lines...]\n    test_policy_file_custom_location                             OK    0.01\n    test_policy_file_custom_rules_default_location               OK    0.01\n    test_policy_file_default_rules_default_location              OK    0.01\nTestPolicyEnforcerNoFile\n    test_policy_file_default_not_found                           OK    0.01\n    test_policy_file_specified_but_not_found                     OK    0.01\nTestStore\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.02\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: False is not true\n    \'False is not true\' = self._formatMessage(\'False is not true\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'False is not true\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.98 secs:\n    14.36    TestScrubber.test_delayed_delete\n    14.31    TestGlanceControl.test_bouncing\n    13.89    TestGlanceControl.test_reload\n    13.70    TestGlanceControl.test_respawn\n    12.72    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 913 tests in 483.184s\n\nFAILED (SKIP=100, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.9.1\neventlet==0.9.17\nglance==jenkins-periodic-glance-python27-stable-folsom-64\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\njsonschema==0.7\nkombu==2.5.3\nlxml==3.0.1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==0.14.2\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/64\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/64/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1104484954.83.1353888719542.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-26 00:11:59',0,'2012-11-26 00:11:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #56','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/56/>\n\n------------------------------------------\n[...truncated 900 lines...]\nTestPolicyEnforcer\n    test_policy_file_custom_location                             OK    0.01\n    test_policy_file_custom_rules_default_location               OK    0.01\n    test_policy_file_default_rules_default_location              OK    0.01\nTestPolicyEnforcerNoFile\n    test_policy_file_default_not_found                           OK    0.01\n    test_policy_file_specified_but_not_found                     OK    0.01\nTestStore\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.00\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.02\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: False is not true\n    \'False is not true\' = self._formatMessage(\'False is not true\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'False is not true\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.96 secs:\n    14.17    TestScrubber.test_delayed_delete\n    13.82    TestGlanceControl.test_reload\n    13.63    TestGlanceControl.test_respawn\n    13.63    TestGlanceControl.test_bouncing\n    12.73    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 912 tests in 475.808s\n\nFAILED (SKIP=100, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.9.1\neventlet==0.9.17\nglance==jenkins-periodic-glance-python27-stable-folsom-56\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\njsonschema==0.7\nkombu==2.4.10\nlxml==3.0.1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==0.14.2\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/56\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/56/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1104498257.7465285.1396035403392.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 15:36:43',-14400,'2014-03-28 19:36:43',NULL,'[openstack-dev] [nova] SR-IOV and IOMMU check','----- Original Message -----\n> Hi, all\n> \n> Currently openstack can support SR-IOV device pass-through (at least there\n> are some patches for this), but the prerequisite to this is both IOMMU and\n> SR-IOV must be enabled correctly, it seems there is not a robust way to\n> check this in openstack, I have implemented a way to do this and hope it can\n> be committed into upstream, this can help find the issue beforehand, instead\n> of letting kvm report the issue \"no IOMMU found\" until the VM is started. I\n> didn\'t find an appropriate place to put into this, do you think this is\n> necessary? Where can it be put into? Welcome your advice and thank you in\n> advance.\n\nWhat\'s the mechanism you are using on the host side to determine that IOMMU is supported/enabled?\n\nThanks,\n\nSteve\n\n\n','<79BBBFE6CB6C9B488C1A45ACD284F51910D0E58A@SHSMSX103.ccr.corp.intel.com>',NULL),('<1104700528.54173782.1384542199659.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 14:03:19',-18000,'2013-11-15 19:03:19',NULL,'[openstack-dev] sqlalchemy-migrate needs a new release','\n\n----- Original Message -----\n> From: \"David Ripton\" <dripton at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Friday, November 15, 2013 1:47:58 PM\n> Subject: Re: [openstack-dev] sqlalchemy-migrate needs a new release\n> \n> On 11/15/2013 10:41 AM, David Ripton wrote:\n> \n> > sqlalchemy-migrate-0.8.1 is now up on PyPI.  Thanks fungi for kicking\n> > PyPI for me.\n> \n> So there was a hardcoded version number inside migrate/__init__.py,\n\nCorrect, Here was my fix for Nova earlier today (for sqlalchemy-migrate 0.8.1... now bumped to 0.8.2 though):\n\n https://review.openstack.org/#/c/56667/\n\nIf you use 0.8.2 this shouldn\'t be required... but does eliminate some code so I figure we should probably go on and do it.\n\nDan\n\n\n> which broke things when I didn\'t manually update it to sync with the new\n> release\'s version number.  (DRY violation.)  mordred landed a patch to\n> make it dynamic so we don\'t need to remember to update it before every\n> release in the future.\n> \n> sqlalchemy-migrate-0.8.2 is now on PyPI.\n> \n> --\n> David Ripton   Red Hat   dripton at redhat.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52866C5E.6030005@redhat.com>',NULL),('<1104961875.1314288.1399308669773.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 12:51:09',-14400,'2014-05-05 16:51:09',NULL,'[openstack-dev] [Nova][Heat] Custom Nova Flavor\n	creation	through Heat (pt.2)','----- Original Message -----\n> Excerpts from Solly Ross\'s message of 2014-05-05 08:23:41 -0700:\n> > Just to expand a bit on this, flavors are supposed to be the lowest level\n> > of granularity,\n> > and the general idea is to round to the nearest flavor (so if you have a VM\n> > that requires\n> > 3GB of RAM, go with a 4GB flavor).  Hence, in my mind, it doesn\'t make any\n> > sense to create\n> > flavors on the fly; you should have enough flavors to suit your needs, but\n> > I can\'t really\n> > think of a situation where you\'d need so much granularity that you\'d need\n> > to create new\n> > flavors on the fly (assuming, of course, that you planned ahead and created\n> > enough flavors\n> > that you don\'t have VMs that are extremely over-allocated).\n> \n> I agree with the conclusion you\'re arguing for, but it is a bit more\n> complex than that. Flavor defines at least three things, and possibly 4:\n> RAM, root disk, and vcpu, with an optional ephemeral disk. Because of\n> that, the matrix of possibilities can get extremely large.\n\nIn addition extra specifications may denote the passthrough of additional devices, adding another dimension. This seems likely to be the case in the use case outlined in the original thread [1].\n\nThanks,\n\nSteve\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018744.html\n\n\n','<1399305640-sup-281@fewbar.com>',NULL),('<1104B2D1-0249-466E-9A1C-ED229744E8D9@syrinx.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 14:03:06',-14400,'2013-08-12 18:03:06',NULL,'[Openstack] Best deployment tool for openstack production\n	environment','On Aug 12, 2013, at 1:34 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n> \n> I have been messing around with a few different tools for deploying openstack, but most of them seem they are designed for test environments.\n> \n> Just wonder what everyone\'s opinion is on the best tool for deploying a production quality environment? Or is it best to install each component \n> one by one without using a deployment tool?\n\nI\'ve done both a manual installation and an automated one. Manual installation gives you a good grounding in how all of the pieces fit together. But be prepared to set aside a fair bit of time. I also used Mirantis Fuel (https://fuel.mirantis.com) recently and the deployment went without a hitch. It\'s definitely not aimed at creating test environments, though I guess you could. Fuel is meant to deploy real OpenStack installations for production.\n\n','<1376328872.82227.YahooMailNeo@web163002.mail.bf1.yahoo.com>',NULL),('<1105074012.27759144.1384170866103.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-11 03:54:26',-28800,'2013-11-11 11:54:26',NULL,'[Openstack] Memory utilization meter from ceilometer for libvert','Hi Eoghan,\n\nThanks for the information. In the previous discussion, you had mentioned that providing this memory util meter in ceilometer will depend upon some fix in libvert which will be available in a future release. Can you please let us know whether this is already fixed in libvert and in which release? \n\nThanks,\nPiyush\n\n----- Original Message -----\n> From: \"Eoghan Glynn\" <eglynn at redhat.com>\n> To: \"Piyush Masrani\" <pmasrani at vmware.com>\n> Cc: \"openstack\" <openstack at lists.openstack.org>\n> Sent: Monday, November 11, 2013 2:56:43 PM\n> Subject: Re: [Openstack] Memory utilization meter from ceilometer for libvert\n> \n> \n> \n> \n> ----- Original Message -----\n> > Hey all,\n> > \n> > In an archived conversation\n> > (http://www.mail-archive.com/openstack at lists.launchpad.net/msg24776.html),\n> > I\n> > see that memory utilization meter for libvert was not available in\n> > ceilometer and plans were to support it after a fix is available in a new\n> > release of libvert. Does anyone know if this fix is already available in\n> > libvert and whether ceilometer now supports memory utilization meter? I\n> > didn\'t see any bug for the same as well.\n> > \n> > Thanks,\n> > Piyush\n> \n> Hi Piyush,\n> \n> Ceilometer does not currently meter memory util, but we plan to add this\n> functionality during the Icehouse cycle.\n> \n> It was one of the many topics discussed at the design summit last week:\n> \n>   https://etherpad.openstack.org/p/icehouse-summit-ceilometer-future-of-alarming\n> \n> I intend to file blueprints this week for the design sessions I led in HK,\n> and this requirement will be included in a \"Wider variety of metrics suitable\n> for alarming\" BP.\n> \n> Cheers,\n> Eoghan\n> \n\n\n','<370043137.20102644.1384162003193.JavaMail.root@redhat.com>',NULL),('<110587037.23252066.1370964264391.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 11:24:24',-14400,'2013-06-11 15:24:24',NULL,'[openstack-qa] Data encapsulation within Tempest','+1\n\nI Agree.\n\n\n----- Original Message -----\n> From: \"Tal Kammer\" <tkammer at redhat.com>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Monday, June 10, 2013 3:18:32 PM\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> I fail to see how is it close to that model today.\n> \n> We have a lot of duplicate code in pretty much every implementation of XML vs\n> JSON..\n> what will happen if tomorrow we move to SOAP? do we really want to build a\n> new client for every single component? (as it is now..)\n> \n> if we look at the rest_client module as it is today, let\'s take the\n> \"identity_auth_v3\" for example, what happens when a auth_v4 comes out? v5?\n> do we just keep adding layers?\n> \n> Having a model of a \"Request\" object (or any other name/object, the\n> implementation itself is not relevant for the argument) immediately removes\n> all duplication in clients (which is a lot of code), and a lot more code if\n> we consider add ons in the future. (and I do believe we should consider the\n> future..)\n> \n> Also, all response handling is hard coded, why not separate it into a\n> class/module of it\'s own?\n> Currently, if devs decide to change the response code, there is no graceful\n> way of handling it. everything will pretty much fail..\n> \n> If we agree that things can be cleaner, why not start the cleaning process?\n> If it\'s a matter of time, I am more than willing to volunteer.\n> \n> Regards,\n> Tal\n> \n> ----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Monday, June 10, 2013 3:48:35 PM\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> On 06/09/2013 05:54 PM, Daryl Walleck wrote:\n> >>> Why do we need so many \"if\" statements for username/password/tenant/etc\n> >>> in the Manager class? or a >>better question is \"why is the Manager\n> >>> class dependent on a specific implementation of an Identity >>component\"\n> >>> (keystone)?\n> >\n> >> I don\'t really think we need a Manager class at all. It serves no purpose,\n> >> IMO.\n> >\n> > In its current form the manager class is extremely verbose. However, I\n> > think there is some value in having a single entry point into the clients.\n> > There are better ways to do this dynamically that involve far less code.\n> >\n> >>> In the \"services\" folder.\n> >>> Why do we need two clients for JSON/XML?\n> >\n> >> Because both code paths need testing?\n> >\n> > It\'s very possible to get rid of the duplicate clients by extracting the\n> > one thing that varies (serialization/deserialization) from the clients and\n> > handle it elsewhere. This allowed us to greatly reduce the amount of\n> > duplicated client code we have in CloudCafe.\n> \n> Realistically, Tempest is close to that model today anyway, all the best\n> REST handling happens in common. It could be made cleaner, for sure, but\n> I\'d be surprised if you dropped all that much code in the process.\n> \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<1107575529.13796364.1370870312923.JavaMail.root@redhat.com>',NULL),('<1106358387.12.1387262719861.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-17 06:45:19',0,'2013-12-17 06:45:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-havana #8','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-neutron-havana/8/>\n\n------------------------------------------\n[...truncated 21331 lines...]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... FAIL\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\n\nprocess-returncode\nprocess-returncode ... FAIL\n\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-12-17 06:33:42,711 Starting new HTTP connection (1): 127.0.0.1\n2013-12-17 06:33:42,804 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 71, in test_snapshot_pattern\n    server = self._boot_image(self.config.compute.image_ref)\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 37, in _boot_image\n    return self.create_server(image=image_id, create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 352, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing b01c5cc5-6baf-4e8b-92fd-ce7d9cd9df55                       to become ACTIVE\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 248 tests in 1392.118s\n\nFAILED (failures=2, skipped=9)\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                 401.663\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  166.534\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          118.180\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]           31.429\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]                           23.216\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]             16.479\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                          15.384\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]                      12.543\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]     10.641\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]               10.529\nERROR: InvocationError: \'/bin/sh tools/pretty_tox_serial.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])((smoke)|(^tempest\\\\.scenario)) \'\n___________________________________ summary ____________________________________\nERROR:   smoke-serial: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/localrc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-876454-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-876454.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-lbaas.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-q-vpn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/neutron-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az3-876454/8/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1106596766.11.1376461407049.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-14 06:23:27',0,'2013-08-14 06:23:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #6','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/6/>\n\n------------------------------------------\n[...truncated 949 lines...]\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Test that we notice when our log file has been rotated\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_logging.py\",> line 90, in test_logrotate\n    self.assertNotEmptyFile(self.api_server.log_file)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_logging.py\",> line 80, in assertNotEmptyFile\n    self.assertTrue(os.path.exists(path))\nAssertionError: False is not true\n    \'False is not true\' = self._formatMessage(\'False is not true\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'False is not true\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 172.68 secs:\n    85.44    TestGlanceControl.test_bouncing\n    23.98    TestBinGlanceCacheManage.test_queue\n    22.51    TestBinGlance.test_results_filtering\n    21.76    TestRootApi.test_version_configurations\n    18.99    TestScrubber.test_delayed_delete\n----------------------------------------------------------------------\nRan 926 tests in 997.642s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python27-stable-folsom-6\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.QBsqWGSa6w\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/6\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise6/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1106A7B6-7E6C-40D8-AC11-E68033F486D8@huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-15 20:17:54',0,'2014-05-15 20:17:54',NULL,'[openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs\n consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer\n lounge at 3rd floor','Dear Salvatore,\n\nThank you for your comments.\n\nJoe is the best person to explain the trust relationship and his use case.\n\nWe can describe the APIs here later.\nhttps://wiki.openstack.org/wiki/Neutron/sdnapi\n\n\nThank you,\nTina\n\nOn May 15, 2014, at 11:45 AM, \"Salvatore Orlando\" <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:\n\nHi,\n\nfrankly this picture is not worth a lot to people which did not attend this meetings.\nAt least the dumb ones like me.\n\nI\'ve tried to bring myself up to speed on NBI APIs; however  It is not clear where the mnentioned trust relationship module resides, and how it interacts with the other components in the picture.\nAlso, the role of MPLS/WAN cloud is also a bit obscure at the moment.\n\nIt would be probably not such a bad idea to create a wiki page describing architecture/design and action items.\n\nHowever, I seem to understand that an Openstack based cloud is actually a energised nebula which is attracting a tie fighter whose pilot is crying for help shouting NBI APIs!\nSorry about the irony, I did not mean to be rude.\n\nRegards,\nSalvatore\n\n\nOn 15 May 2014 17:19, Tina TSOU <Tina.Tsou.Zouting at huawei.com<mailto:Tina.Tsou.Zouting at huawei.com>> wrote:\nDear all,\n\nA picture is worth 1000 words.\n\nHere is what we had in our meeting, AT&T scanario regarding trust relationship modle between cloud operator and network operator, and core APIs between OpenStack and SDN Controller for L3 VPN.\n\n<image001.jpg>\n\n\nThank you,\nTina\n\nFrom: Martinx - ????? [mailto:thiagocmartinsc at gmail.com<mailto:thiagocmartinsc at gmail.com>]\nSent: Wednesday, May 14, 2014 5:54 PM\n\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor\n\nHello!\n\nThis is very an interesting topic!\n\nI would like to talk about one idea I had, which is related to: \"1.9. API for VPN\".\n\nI think it would be awesome, for example, when dealing with IPv6-Only \"Projects (Tenants) Networks\", the VPNs should use `Opportunistic Encryption`, this way, the VPNs will be established \"by default\" without any user interaction. Then, IPSec VPN for `IPv6 <-> IPv6` subnets will be always there, safely interconnecting the subnets, everywhere, even across different \"Regions\" or across different \"Projects\" (old \"Tenants\" terminology).\n\nI already started a topic about this but, I\'m a bit busy these days... I\'ll reply there and I\'m drawing a blueprint for it...\n\nBest!\nThiago\n\nOn 14 May 2014 12:16, Tina TSOU <Tina.Tsou.Zouting at huawei.com<mailto:Tina.Tsou.Zouting at huawei.com>> wrote:\nDear all,\n\nBelow is the main conclusion from this meeting.\n\nWe will work on the following SDN NBI Core APIs at the priority per Neutron\'s interest.\n2, 7, 10, 9, 11.\n\n1.2 APIs for connection between OpenStack Neutron and controller\n\nOpenStack is widely used and deployed in cloud scenarios.OpenStack-based data center is becoming mainstream.\n\nThere should be APIs for connection between SDN controller and OpenStack Neutron.\n\n\n\n1.7 APIs for Virtual-Tenant-Network (VTN)\n\nVTN allows users and developers to design and deploy virtual networks without the need to know the physical network. This is very useful in data center.\n\nThere should be APIs for virtual tenant network.\n\n\n\n1.10 APIs for QoS\n\nQoS is usually for end user application. For example, the UC-SDN-Use-Case needs the network to guarantee its flow QoS to improve the user?s QoE.\n\nThere should be APIs for QoS.\n\n\n\n1.9 APIs for VPN\n\nVPN is also widely use in enterprise network, interconnectionbetween data centers and mobile environments.\n\nThe management and operation of VPN are necessary. There should be APIs for VPN.\n\nThe VPN may include the following type\n\nL2 VPN\n\nL3 VPN\n\n\n\n1.11 APIs for network stats/state\n\nThe network stats/state is needed by application so that the application can react with the corresponding policy.\n\nThere should be APIs for network stats/state.\n\n\nThank you,\nTina\n\nOn May 14, 2014, at 10:00 AM, \"Tina TSOU\" <Tina.Tsou.Zouting at huawei.com<mailto:Tina.Tsou.Zouting at huawei.com>> wrote:\nDear all,\n\nPlace is changed to B203 table 6 for Networking (Neutron), Design Summit Pod area.\n\n\nThank you,\nTina\n\nOn May 13, 2014, at 10:00 PM, \"Tina TSOU\" <Tina.Tsou.Zouting at huawei.com<mailto:Tina.Tsou.Zouting at huawei.com>> wrote:\nDear Stackers,\n\nWe are setting up a meeting to SDN NBI Core APIs consumed by OpenStack. Attached is the material for your reading pleasure.\n\nThe meeting is planned for:\n                Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor .\nLook forward to meeting many of you then.\n\n\nThank you,\nTina\n\n<NBI Core APIs.docx>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140515/714be1f0/attachment.html>\n\n','<A045522F-39A5-4276-916A-C769C3C19F50@huawei.com>',NULL),('<1107575529.13796364.1370870312923.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-10 09:18:32',-14400,'2013-06-10 13:18:32',NULL,'[openstack-qa] Data encapsulation within Tempest','I fail to see how is it close to that model today.\n\nWe have a lot of duplicate code in pretty much every implementation of XML vs JSON..\nwhat will happen if tomorrow we move to SOAP? do we really want to build a new client for every single component? (as it is now..)\n\nif we look at the rest_client module as it is today, let\'s take the \"identity_auth_v3\" for example, what happens when a auth_v4 comes out? v5? do we just keep adding layers?\n\nHaving a model of a \"Request\" object (or any other name/object, the implementation itself is not relevant for the argument) immediately removes all duplication in clients (which is a lot of code), and a lot more code if we consider add ons in the future. (and I do believe we should consider the future..)\n\nAlso, all response handling is hard coded, why not separate it into a class/module of it\'s own?\nCurrently, if devs decide to change the response code, there is no graceful way of handling it. everything will pretty much fail..\n\nIf we agree that things can be cleaner, why not start the cleaning process? If it\'s a matter of time, I am more than willing to volunteer.\n\nRegards,\nTal\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Monday, June 10, 2013 3:48:35 PM\nSubject: Re: [openstack-qa] Data encapsulation within Tempest\n\nOn 06/09/2013 05:54 PM, Daryl Walleck wrote:\n>>> Why do we need so many \"if\" statements for username/password/tenant/etc in the Manager class? or a >>better question is \"why is the Manager class dependent on a specific implementation of an Identity >>component\" (keystone)?\n>\n>> I don\'t really think we need a Manager class at all. It serves no purpose, IMO.\n>\n> In its current form the manager class is extremely verbose. However, I think there is some value in having a single entry point into the clients. There are better ways to do this dynamically that involve far less code.\n>\n>>> In the \"services\" folder.\n>>> Why do we need two clients for JSON/XML?\n>\n>> Because both code paths need testing?\n>\n> It\'s very possible to get rid of the duplicate clients by extracting the one thing that varies (serialization/deserialization) from the clients and handle it elsewhere. This allowed us to greatly reduce the amount of duplicated client code we have in CloudCafe.\n\nRealistically, Tempest is close to that model today anyway, all the best \nREST handling happens in common. It could be made cleaner, for sure, but \nI\'d be surprised if you dropped all that much code in the process.\n\n	-Sean\n\n-- \nSean Dague\nhttp://dague.net\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<51B5CB23.6090801@dague.net>',NULL),('<1108911865.34.1378361619585.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-05 06:13:39',0,'2013-09-05 06:13:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #15','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/15/>\n\n------------------------------------------\n[...truncated 951 lines...]\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.02\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.02\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.14\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.02\n    test_request_url_v1                                          OK    0.02\n    test_request_url_v1_0                                        OK    0.02\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Exercise `glance-control api reload`\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 239, in test_reload\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, \'Unexpected server launch status\'\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.24 secs:\n    14.01    TestGlanceControl.test_bouncing\n    13.84    TestScrubber.test_delayed_delete\n    13.58    TestGlanceControl.test_respawn\n    12.53    TestApi.test_unsupported_default_store\n    11.28    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 479.862s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python26-stable-folsom-15\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.6.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.LVyDHO0SFP\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/15/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/15\n[SCP] Copying console log.\n\n\n','<880528473.29.1378275033232.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1109960529.42.1380300335020.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-27 16:45:34',0,'2013-09-27 16:45:34',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #26','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/26/>\n\n------------------------------------------\n[...truncated 20781 lines...]\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_role_create_update_get[gate,smoke]\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_role_create_update_get[gate,smoke] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_list_user_projects[gate]\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_list_user_projects[gate] ... ok\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_user_update[gate]\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_user_update[gate] ... ok\nsetUpClass (tempest.api.network.test_load_balancer.LoadBalancerXML)\nsetUpClass (tempest.api.network.test_load_balancer.LoadBalancerXML) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_quotas.QuotasTest)\nsetUpClass (tempest.api.network.test_quotas.QuotasTest) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTest)\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTest) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML)\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML) ... skipped u\'Neutron support is required\'\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_admin_modify_quota[gate,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_admin_modify_quota[gate,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_large_object[gate,negative,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_large_object[gate,negative,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_valid_object[gate,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_valid_object[gate,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_user_modify_quota[gate,negative,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_user_modify_quota[gate,negative,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\nInitialized empty Git repository in /tmp/tempest-unitBGBWRH/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitQh9AUE/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           203.189\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   202.891\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   65.865\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]          37.595\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]        35.986\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   31.098\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]     30.640\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]         30.351\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         30.135\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                 30.044\n\n----------------------------------------------------------------------\nRan 1246 tests in 1272.645s\n\nOK (skipped=66)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-407837-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-407837.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-407837/26/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<531051546.26.1380004242374.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1110176901.949231.1409925445850.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 09:57:25',-14400,'2014-09-05 13:57:25',NULL,'[openstack-dev] [Sahara][FFE] Requesting exception for Swift trust\n authentication blueprint','hey folks,\n\nI am requesting an exception for the Swift trust authentication blueprint[1]. This blueprint addresses a security bug in Sahara and represents a significant move towards increased security for Sahara clusters. There are several reviews underway[2] with 1 or 2 more starting today or monday.\n\nThis feature is initially implemented as optional and as such will have minimal impact on current user deployments. By default it is disabled and requires no additional configuration or management from the end user.\n\nMy feeling is that there has been vigorous debate and discussion surrounding the implementation of this blueprint and there is consensus among the team that these changes are needed. The code reviews for the bulk of the work have been positive thus far and I have confidence these patches will be accepted within the next week.\n\nthanks for considering this exception,\nmike\n\n\n[1]: https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust-authentication\n[2]: https://review.openstack.org/#/q/status:open+topic:bp/edp-swift-trust-authentication,n,z\n\n\n','<1601762864.941082.1409924380349.JavaMail.zimbra@redhat.com>',NULL),('<1112310669.26664901.1406658321963.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-29 14:25:21',-14400,'2014-07-29 18:25:21',NULL,'[openstack-dev] [NFV][CI][third-party] The plan to bring up\n Snabb NFV CI for Juno-3','----- Original Message -----\n> From: \"Luke Gorrie\" <luke at snabb.co>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: \"Nikolay Nikolaev\" <n.nikolaev at virtualopensystems.com>\n> Sent: Tuesday, July 29, 2014 12:28:55 PM\n> Subject: Re: [openstack-dev] [NFV][CI][third-party] The plan to bring up Snabb NFV CI for Juno-3\n> \n> Hi Steve,\n> \n> On 29 July 2014 17:21, Steve Gordon <sgordon at redhat.com> wrote:\n> \n> > I\'ve added the [third-party] tag as well to ensure this catches the\n> > broadest segment of relevant people.\n> >\n> \n> Thanks!\n> \n> \n> > are any modifications to upstream Open vSwitch required to support Snabb?\n> >\n> \n> Good question. No, this uses a separate vswitch called Snabb Switch. Snabb\n> Switch is a small user-space program that you assign some network\n> interfaces to. It runs independent of any other networking you are doing on\n> other ports (OVS, DPDK-OVS, SR-IOV, etc).\n\nOK, that\'s what I thought - thanks for confirming.\n\n> Have you already attempted to solicit some core reviewers in Nova and\n> > Neutron\n> \n> How does one normally do that? We are getting help but I am not exactly\n> sure how people have found us beyond chat in #openstack-nfv :-).\n> \n> Two Neutron core reviewers are making the requirements there very clear to\n> us, both on the code and the CI.\n\nIdeally this is fairly organic, the NFV group certainly serves as a forum for coordinating what work is out there in this space but ultimately it is necessary to also liaise with and meet the expectations of the actual projects (e.g. Neutron and Nova in this case). This is an area where we as a group still have a lot of work to do, in my opinion.\n\nI see that there is some discussion to this end in the code submission for the new mechanism driver:\n\n    https://review.openstack.org/#/c/95711/\n\nIt appears to me the expectation/desire from Mark and Maru here is to see a lot more justification of the use cases for this driver and the direction of the current implementation so while it is positive that it got the attention of some core reviewers early there are some hard questions that will need to be answered to continue making progress with this for Juno.\n\n> One Nova core reviewer is helping us too. I would like to better understand\n> CI requirements on the Nova side (e.g. does the Neutron tempest testing\n> regime provide adequate coverage for Nova or do we need to do more?). This\n> is our first contribution to Nova so there is a risk that we overlook\n> something important.\n\nTypically third party CI is only provided/required for Nova when adding/maintaining a new hypervisor driver - at least that seems to be the case so far. I know in your earlier email you mentioned also wanting to use this third party CI to also test a number of other scenarios, particularly:\n\n> * Test with NFV-oriented features that are upstream in OpenStack.\n> * Test with NFV-oriented changes that are not yet upstream e.g. Neutron QoS\nAPI.\n\nI am not sure how this would work - perhaps I misunderstand what you are proposing? As it stands the third-party CI jobs ideally run on each change *submitted* to gerrit so features that are not yet *merged* still receive this CI testing today both from the CI managed by infra and the existing third-party CI jobs? Or are you simply highlighting that you wish to test same with snabbswitch? Just not quite understanding why these were called out as separate cases.\n\nThanks,\n\nSteve\n\n\n','<CAA2XHbf3bizU2_TcQcRbHWoASEWpqEQWnM9=sN6M9WTSANknmw@mail.gmail.com>',NULL),('<1113251883.243.1368339206537.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:13:26',0,'2013-05-12 06:13:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #223','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/223/>\n\n\n\n','<17648161.224.1368252629158.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<111336261.147.1366006601307.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-15 06:16:41',0,'2013-04-15 06:16:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python27-stable-grizzly #5','See <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/5/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal3 in workspace <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/>\nCheckout:periodic-quantum-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 2625f965:quantal3\nUsing strategy: Default\nLast Built Revision: Revision 75830a077ad326116683fcae0ab042bd3808c200 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/quantum.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/quantum.git\nCommencing build of Revision 75830a077ad326116683fcae0ab042bd3808c200 (origin/stable/grizzly)\nChecking out Revision 75830a077ad326116683fcae0ab042bd3808c200 (origin/stable/grizzly)\n[periodic-quantum-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson6338462991030797843.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack quantum\n+ version=27\n+ org=openstack\n+ project=quantum\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.hSJmlFzNHh\n+ TMPDIR=/tmp/tmp.hSJmlFzNHh\n+ trap \'rm -rf /tmp/tmp.hSJmlFzNHh\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack quantum\n+ org=openstack\n+ project=quantum\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' quantum == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.quantum.python27.stable.grizzly.5\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires\',> \'setuptools_git>=0.4\']\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/5/\', \'BUILD_TAG\': \'jenkins-periodic-quantum-python27-stable-grizzly-5\', \'SSH_CLIENT\': \'198.101.231.203 33968 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-quantum-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal3\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.hSJmlFzNHh\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-15_06-13-00\', \'BUILD_NUMBER\': \'5\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'a188c166-29de-49cb-ad18-bafeed689546\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'75830a077ad326116683fcae0ab042bd3808c200\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal3\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 33968 166.78.137.37 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking setuptools-git>=0.4\n  Real name of requirement setuptools_git is setuptools-git\n  Downloading setuptools-git-1.0b1.tar.gz\n  Running setup.py egg_info for package setuptools-git\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \nDownloading/unpacking Paste (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 1))\n  Running setup.py egg_info for package Paste\n    \n    warning: no previously-included files matching \'*\' found under directory \'docs/_build/_sources\'\nDownloading/unpacking PasteDeploy>=1.5.0 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Downloading PasteDeploy-1.5.0.tar.gz\n  Running setup.py egg_info for package PasteDeploy\n    \nDownloading/unpacking Routes>=1.12.3 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package Routes\n    \n    warning: no previously-included files matching \'.DS_Store\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgignore\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgtags\' found anywhere in distribution\nDownloading/unpacking amqplib==0.6.1 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Running setup.py egg_info for package amqplib\n    \nDownloading/unpacking anyjson>=0.2.4 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Downloading anyjson-0.3.3.tar.gz\n  Running setup.py egg_info for package anyjson\n    \nRequirement already satisfied (use --upgrade to upgrade): argparse in /usr/lib/python2.7 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 6))\nDownloading/unpacking eventlet>=0.9.17 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package greenlet\n    \nDownloading/unpacking httplib2 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package httplib2\n    \nDownloading/unpacking iso8601>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Downloading iso8601-0.1.4.tar.gz\n  Running setup.py egg_info for package iso8601\n    \nDownloading/unpacking kombu==1.0.4 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package kombu\n    \nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Running setup.py egg_info for package netaddr\n    \n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 13))\n  Running setup.py egg_info for package python-quantumclient\n    \nDownloading/unpacking pyudev (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 14))\n  Running setup.py egg_info for package pyudev\n    \nDownloading/unpacking sqlalchemy>=0.7.8,<=0.7.99 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 15))\n  Real name of requirement sqlalchemy is SQLAlchemy\n  Running setup.py egg_info for package sqlalchemy\n    \n    warning: no files found matching \'*.jpg\' under directory \'doc\'\n    no previously-included directories found matching \'doc/build/output\'\nDownloading/unpacking WebOb>=1.2 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 16))\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking python-keystoneclient>=0.2.0 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 17))\n  Running setup.py egg_info for package python-keystoneclient\n    \n    warning: no files found matching \'python-keystoneclient\'\nDownloading/unpacking alembic>=0.4.1 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 18))\n  Running setup.py egg_info for package alembic\n    \n    warning: no files found matching \'*.jpg\' under directory \'docs\'\n    warning: no files found matching \'*.sty\' under directory \'docs\'\n    warning: no files found matching \'*.dat\' under directory \'tests\'\n    no previously-included directories found matching \'docs/build/output\'\nDownloading/unpacking oslo.config>=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 19))\n  Running setup.py egg_info for package oslo.config\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires> (line 22))\n  Running setup.py egg_info for package python-novaclient\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/.tox/py27/build/python-novaclient/setuptools_git-1.0b1-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking Babel>=0.9.6 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires> (line 1))\n  Real name of requirement Babel is Babel\n  Could not find any downloads that satisfy the requirement Babel>=0.9.6 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires> (line 1))\nNo distributions at all found for Babel>=0.9.6 (from -r <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires> (line 1))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.hSJmlFzNHh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python27-stable-grizzly/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1113527679.5459556.1410421409505.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 03:43:29',-14400,'2014-09-11 07:43:29',NULL,'[openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core','\n\n> Hi,\n> \n> Nejc has been doing a great work and has been very helpful during the\n> Juno cycle and his help is very valuable.\n> \n> I\'d like to propose that we add Nejc Saje to the ceilometer-core group.\n> \n> Please, dear ceilometer-core members, reply with your votes!\n\nA hearty +1 for me, Nejc has made a great impact in Juno.\n\nCheers,\nEoghan \n\n\n','<m24mwfojaz.fsf@danjou.info>',NULL),('<1114542332.2041040.1414520524163.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 14:22:04',-14400,'2014-10-28 18:22:04',NULL,'[openstack-dev] [nova] How to connect to a serial port of\n	an	instance via websocket?','You should be able to connect like a normal WebSocket, assuming you\'re running the serial console websocketproxy (it\'s a different command from the VNC web socket proxy).  If you want, you can ping\non IRC and I can help you debug your JS code.\n\nBest Regards,\nSolly Ross\n\n(directxman12 on freenode IRC)\n\n----- Original Message -----\n> From: \"Markus Zoeller\" <mzoeller at de.ibm.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Tuesday, October 28, 2014 10:09:44 AM\n> Subject: [openstack-dev] [nova] How to connect to a serial port of an	instance via websocket?\n> \n> The API provides an endpoint for querying the serial console of an\n> instance (\'os-getSerialConsole\'). The nova-client interacts with this\n> API endpoint via the command `get-serial-console`.\n> \n>     nova get-serial-console myInstance\n>  \n> It returns a string like:\n> \n>     ws://127.0.0.1:6083/?token=e2b42240-375d-41fe-a166-367e4bbdce35\n>  \n> Q: How is one supposed to connect to such a websocket?\n> \n> [1]\n> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/consoles.py#L111\n> [2]\n> https://ask.openstack.org/en/question/50671/how-to-connect-to-a-serial-port-of-an-instance-via-websocket/\n> \n> Regards,\n> Markus Zoeller\n> IRC: markus_z\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OFE22D51C3.A70A18D7-ONC1257D7F.004D7E96-C1257D7F.004DCC3E@de.ibm.com>',NULL),('<1114581450.36.1387095991701.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-15 08:26:31',0,'2013-12-15 08:26:31',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-dsvm-stress-havana #6','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-stress-havana/6/>\n\n\n\n','<1609126248.56.1386742734535.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1115173206.356.1366958797088.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-26 06:46:37',0,'2013-04-26 06:46:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #16','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/16/>\n\n------------------------------------------\n[...truncated 4554 lines...]\n    test_get_security_group                                      OK    0.25\n    test_list_ports_security_group                               OK    0.33\n    test_list_security_group_rules                               OK    0.36\n    test_list_security_group_rules_with_pagination               OK    2.82\n    test_list_security_group_rules_with_pagination_reverse       OK    0.36\n    test_list_security_group_rules_with_sort                     OK    0.32\n    test_list_security_groups                                    OK    0.26\n    test_list_security_groups_with_pagination                    OK    0.29\n    test_list_security_groups_with_pagination_reverse            OK    0.42\n    test_list_security_groups_with_sort                          OK    0.28\n    test_update_port_remove_security_group_empty_list            OK    0.38\n    test_update_port_remove_security_group_none                  OK    0.37\n    test_update_port_with_multiple_security_groups               OK    0.38\n    test_update_port_with_security_group                         OK    0.39\nActionExtensionTest\n    test_extended_action_for_adding_extra_data                   OK    0.10\n    test_extended_action_for_deleting_extra_data                 OK    0.02\n    test_returns_404_for_non_existent_action                     OK    0.03\n    test_returns_404_for_non_existent_resource                   OK    0.02\nExtensionControllerTest\n    test_extension_can_be_accessed_by_alias                      OK    0.02\n    test_index_gets_all_registerd_extensions                     OK    0.02\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionControllerTestXML\n    test_extension_can_be_accessed_by_alias                      OK    0.03\n    test_index_gets_all_registerd_extensions                     OK    1.98\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionManagerTest\n    test_invalid_extensions_are_not_registered                   OK    0.00\nPluginAwareExtensionManagerTest\n    test_extension_loaded_for_non_core_plugin                    OK    0.00\n    test_extensions_are_loaded_for_plugin_with_expected_interfaceOK    0.00\n    test_extensions_are_not_loaded_for_plugins_unaware_of_extensionsOK    0.00\n    test_extensions_expecting_quantum_plugin_interface_are_loadedOK    0.00\n    test_extensions_not_loaded_for_plugin_without_expected_interfaceOK    0.00\n    test_extensions_without_need_for__plugin_interface_are_loadedOK    0.00\n    test_unsupported_extensions_are_not_loaded                   OK    0.00\nRequestExtensionTest\n    test_edit_previously_uneditable_field                        OK    0.02\n    test_extend_get_resource_response                            OK    0.01\n    test_get_resources                                           OK    0.02\n    test_headers_can_be_extended                                 OK    0.01\nResourceExtensionTest\n    test_exceptions_notimplemented                               OK    0.02\n    test_plugin_prefix_with_parent_resource                      OK    0.03\n    test_resource_can_be_added_as_extension                      OK    0.02\n    test_resource_ext_for_formatted_req_on_custom_collection_actionOK    0.03\n    test_resource_ext_for_nested_resource_custom_collection_actionOK    0.02\n    test_resource_ext_with_custom_member_action_gets_plugin_prefixOK    0.02\n    test_resource_extension_for_delete_custom_collection_action  OK    0.01\n    test_resource_extension_for_get_custom_collection_action     OK    0.01\n    test_resource_extension_for_post_custom_collection_action    OK    0.01\n    test_resource_extension_for_put_custom_collection_action     OK    0.01\n    test_resource_extension_with_custom_member_action            OK    0.02\n    test_resource_extension_with_custom_member_action_and_attr_mapOK    0.01\n    test_resource_gets_prefix_of_plugin                          OK    0.02\n    test_returns_404_for_non_existent_extension                  OK    0.01\nIptablesFirewallTestCase\n    test_defer_apply                                             OK    0.01\n    test_filter_defer_with_exception                             OK    0.01\n    test_filter_ipv4_egress                                      OK    0.02\n    test_filter_ipv4_egress_icmp                                 OK    0.01\n    test_filter_ipv4_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv4_egress_prefix                               OK    0.01\n    test_filter_ipv4_egress_tcp                                  OK    0.01\n    test_filter_ipv4_egress_tcp_mport                            OK    0.01\n    test_filter_ipv4_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_tcp_port                             OK    0.01\n    test_filter_ipv4_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv4_egress_udp                                  OK    0.01\n    test_filter_ipv4_egress_udp_mport                            OK    0.01\n    test_filter_ipv4_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_udp_port                             OK    0.01\n    test_filter_ipv4_egress_udp_prefix                           OK    0.01\n    test_filter_ipv4_ingress                                     OK    0.01\n    test_filter_ipv4_ingress_icmp                                OK    0.01\n    test_filter_ipv4_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv4_ingress_prefix                              OK    0.01\n    test_filter_ipv4_ingress_tcp                                 OK    0.01\n    test_filter_ipv4_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv4_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_tcp_port                            OK    0.01\n    test_filter_ipv4_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv4_ingress_udp                                 OK    0.01\n    test_filter_ipv4_ingress_udp_mport                           OK    0.01\n    test_filter_ipv4_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_udp_port                            OK    0.01\n    test_filter_ipv4_ingress_udp_prefix                          OK    0.01\n    test_filter_ipv6_egress                                      OK    0.01\n    test_filter_ipv6_egress_icmp                                 OK    0.01\n    test_filter_ipv6_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv6_egress_prefix                               OK    0.01\n    test_filter_ipv6_egress_tcp                                  OK    0.01\n    test_filter_ipv6_egress_tcp_mport                            OK    0.01\n    test_filter_ipv6_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_tcp_port                             OK    0.01\n    test_filter_ipv6_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv6_egress_udp                                  OK    0.01\n    test_filter_ipv6_egress_udp_mport                            OK    0.01\n    test_filter_ipv6_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_udp_port                             OK    0.01\n    test_filter_ipv6_egress_udp_prefix                           OK    0.01\n    test_filter_ipv6_ingress                                     OK    0.01\n    test_filter_ipv6_ingress_icmp                                OK    0.01\n    test_filter_ipv6_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv6_ingress_prefix                              OK    0.01\n    test_filter_ipv6_ingress_tcp                                 OK    0.01\n    test_filter_ipv6_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv6_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_tcp_port                            OK    0.01\n    test_filter_ipv6_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv6_ingress_udp                                 OK    0.01\n    test_filter_ipv6_ingress_udp_mport                           OK    0.01\n    test_filter_ipv6_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_udp_port                            OK    0.01\n    test_filter_ipv6_ingress_udp_prefix                          OK    0.01\n    test_prepare_port_filter_with_no_sg                          OK    0.01\n    test_remove_unknown_port                                     OK    0.01\n    test_update_delete_port_filter                               OK    0.02\nIptablesManagerStateFulTestCase\n    test_add_and_remove_chain                                    OK    0.00\n    test_add_filter_rule                                         OK    0.00\n    test_add_nat_rule                                            OK    0.00\n    test_add_rule_to_a_nonexistent_chain                         OK    0.00\n    test_binary_name                                             OK    0.01\n    test_get_chanin_name                                         OK    0.00\n    test_remove_nonexistent_chain                                OK    0.00\n    test_remove_nonexistent_rule                                 OK    0.00\nIptablesManagerStateLessTestCase\n    test_nat_not_found                                           OK    0.00\nTestBasicRouterOperations\n    testAgentAddExternalGateway                                  OK    0.02\n    testAgentAddFloatingIP                                       OK    0.02\n    testAgentAddInternalNetwork                                  OK    0.02\n    testAgentCreate                                              OK    0.01\n    testAgentRemoveExternalGateway                               OK    0.02\n    testAgentRemoveFloatingIP                                    OK    2.11\n    testAgentRemoveInternalNetwork                               OK    0.01\n    testAgentRoutingTableUpdated                                 OK    0.01\n    testAgentRoutingTableUpdatedNoNameSpace                      OK    0.01\n    testDestroyNamespace                                         OK    0.01\n    testDestroyNamespaceWithRouterId                             OK    0.01\n    testProcessRouter                                            OK    0.03\n    testRouterInfoCreate                                         OK    0.01\n    testRoutersWithAdminStateDown                                OK    0.01\n    testRoutesUpdated                                            OK    0.01\n    testRoutesUpdatedNoNamespace                                 OK    0.02\n    testSingleLoopRouterRemoval                                  OK    0.03\nTestL3AgentEventHandler\n    test_spawn_metadata_proxy                                    OK    0.02\nL3NatDBTestCase\n    test_create_external_network_admin_suceeds                   OK    0.20\n    test_create_external_network_non_admin_fails                 OK    0.15\n    test_create_floating_non_ext_network_returns_400             OK    0.28\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.14\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.13\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.14\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.44\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.55\n    test_create_port_external_network_admin_suceeds              OK    0.36\n    test_create_port_external_network_non_admin_fails            OK    2.63\n    test_floating_ip_direct_port_delete_returns_409              OK    0.72\n    test_floatingip_crd_ops                                      OK    0.69\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    0.72\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    0.85\n    test_floatingip_list_with_pagination                         OK    2.82\n    test_floatingip_list_with_pagination_reverse                 OK    0.61\n    test_floatingip_list_with_sort                               OK    0.61\n    test_floatingip_port_delete                                  OK    0.79\n    test_floatingip_update                                       OK    0.70\n    test_floatingip_with_assoc                                   OK    2.77\n    test_floatingip_with_assoc_fails                             OK    0.66\n    test_floatingips_op_agent                                    OK    0.92\n    test_get_network_succeeds_without_filter                     OK    0.25\n    test_interfaces_op_agent                                     OK    0.59\n    test_l3_agent_routers_query_floatingips                      OK    1.05\n    test_l3_agent_routers_query_gateway                          OK    2.82\n    test_l3_agent_routers_query_ignore_interfaces_with_moreThanOneIpOK    0.53\n    test_l3_agent_routers_query_interfaces                       OK    0.50\n    test_list_nets_external                                      OK    0.24\n    test_list_nets_external_pagination                           OK    0.30\n    test_network_filter_hook_admin_context                       OK    0.14\n    test_network_filter_hook_nonadmin_context                    OK    0.14\n    test_network_update_external                                 OK    0.42\n    test_network_update_external_failure                         OK    0.60\n    test_router_add_gateway                                      OK    0.54\n    test_router_add_gateway_dup_subnet1_returns_400              OK    0.39\n    test_router_add_gateway_dup_subnet2_returns_400              OK    2.40\n    test_router_add_gateway_invalid_network_returns_404          OK    0.20\n    test_router_add_gateway_net_not_external_returns_400         OK    0.28\n    test_router_add_gateway_no_subnet_returns_400                OK    0.24\n    test_router_add_gateway_tenant_ctx                           OK    0.37\n    test_router_add_interface_dup_subnet1_returns_400            OK    0.40\n    test_router_add_interface_dup_subnet2_returns_400            OK    0.44\n    test_router_add_interface_no_data_returns_400                OK    0.19\n    test_router_add_interface_overlapped_cidr_returns_400        OK    0.58\n    test_router_add_interface_port                               OK    0.35\n    test_router_add_interface_port_bad_tenant_returns_404        OK    2.23\n    test_router_add_interface_subnet                             OK    0.35\n    test_router_add_interface_subnet_with_bad_tenant_returns_404 OK    0.33\n    test_router_add_interface_subnet_with_port_from_other_tenant OK    0.48\n    test_router_create                                           OK    0.28\n    test_router_create_with_gwinfo                               OK    0.39\n    test_router_delete                                           OK    0.19\n    test_router_delete_subnet_inuse_returns_409                  OK    0.35\n    test_router_delete_with_floatingip_existed_returns_409       OK    1.12\n    test_router_delete_with_port_existed_returns_409             OK    2.55\n    test_router_gateway_op_agent                                 OK    0.37\n    test_router_list                                             OK    0.25\n    test_router_list_with_pagination                             OK    0.26\n    test_router_list_with_pagination_reverse                     OK    0.26\n    test_router_list_with_parameters                             OK    0.21\n    test_router_list_with_sort                                   OK    0.25\n    test_router_remove_interface_inuse_returns_409               OK    0.42\n    test_router_remove_interface_wrong_port_returns_404          OK    0.53\n    test_router_remove_interface_wrong_subnet_returns_409        OK    0.47\n    test_router_show                                             OK    0.24\n    test_router_update                                           OK    2.64\n    test_router_update_gateway                                   OK    0.55\n    test_router_update_gateway_to_empty_with_existed_floatingip  OK    0.69\n    test_router_update_gateway_with_existed_floatingip           OK    0.79\n    test_two_fips_one_port_invalid_return_409                    OK    0.72\nL3NatDBTestCaseXML\n    test_create_external_network_admin_suceeds                   OK    0.19\n    test_create_external_network_non_admin_fails                 OK    0.14\n    test_create_floating_non_ext_network_returns_400             OK    2.76\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.18\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.20\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.17\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.67\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.48\n    test_create_port_external_network_admin_suceeds              OK    0.33\n    test_create_port_external_network_non_admin_fails            OK    0.27\n    test_floating_ip_direct_port_delete_returns_409              OK    0.74\n    test_floatingip_crd_ops                                      OK    0.70\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    2.93\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    0.75\n    test_floatingip_list_with_pagination                         OK    0.71\n    test_floatingip_list_with_pagination_reverse                 OK    0.82\n    test_floatingip_list_with_sort                               OK    2.92\n    test_floatingip_port_delete                                  OK    0.73\n    test_floatingip_update                                       Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.iv6vZ4dmT8\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/16\n[SCP] Copying console log.\n\n\n','<1952462104.340.1366872294539.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1115274564.2.1368772644669.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-17 06:37:24',0,'2013-05-17 06:37:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #37','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 5044 lines...]\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.10\n    test_delete_pool_health_monitor                              OK    2.14\n    test_health_monitor_create                                   OK    0.05\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.05\n    test_member_list                                             OK    0.05\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.05\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.05\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.05\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    2.22\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.00\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.00\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.01\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    2.23\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.00\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.01\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.00\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    0.30\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.30\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    2.74\n    test_quotas_default_values                                   OK    0.22\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_without_admin_forbidden                     OK    0.21\n    test_update_quotas_forbidden                                 OK    0.23\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.30\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.31\n    test_list_quotas_with_admin                                  OK    0.31\n    test_list_quotas_without_admin_forbidden_returns_403         OK    2.56\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.20\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.32\n    test_quotas_limit_check_with_over_quota                      OK    0.26\n    test_quotas_loaded_bad_returns_404                           OK    0.22\n    test_quotas_loaded_right                                     OK    2.67\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_with_owner_tenant                           OK    0.24\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.36\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    2.54\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.20\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.20\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.24\n    test_quotas_get_tenant_from_request_context                  OK    2.61\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.22\n    test_show_quotas_without_admin_forbidden_returns_403         OK    2.55\n    test_update_attributes                                       OK    0.23\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.20\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.41\n    test_KillFilter_deleted_exe                                  OK    0.01\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.44\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    0.32\n    test_health_monitor_update_with_router_id                    OK    3.53\n    test_health_monitor_update_without_router_id                 OK    0.23\n    test_pool_create                                             OK    0.23\n    test_pool_delete_with_router_id                              OK    0.25\n    test_pool_delete_without_router_id                           OK    0.25\n    test_pool_update_with_router_id                              OK    0.23\n    test_pool_update_without_router_id                           OK    0.25\n    test_router_create_no_service_type_id                        OK    0.21\n    test_router_create_with_service_type_id                      OK    0.21\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    2.57\n    test_vip_create                                              OK    0.27\n    test_vip_delete_with_router_id                               OK    0.30\n    test_vip_delete_without_router_id                            OK    0.30\n    test_vip_update_with_router_id                               OK    0.27\n    test_vip_update_without_router_id                            OK    0.30\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.43\n    test_security_group_rules_for_devices_ipv4_source_group      Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.OEjertmeTY\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1:  2922 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/37\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1115292492.4247505.1361440062418.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-21 04:47:42',-18000,'2013-02-21 09:47:42',NULL,'[openstack-dev] [devstack] Problem logging into Horizon\n	as	non-admin?','Hi Paul,\n\n\"Paul Michali\" <pcm at cisco.com> wrote:\n> I\'m not sure how I got into this situation, but I have a VM based\n> setup with Devstack, where I stopped and started it a few times.\n> Currently, I see the following issue:\n> \n> - Start Devstack\n> - Login as admin and create a project\n> - Create a user and add as a MEMBER to the project.\n> - Log out\n> - Try to log in as the user.\n> \n> At this point, I get a traceback on the browser (shown at end of this\n> e-mail). The odd thing is that it says the user does not have admin\n> privileges (true), for the project page. I\'m logging in at the main\n> URL, and it is jumping to /project for some reason.\n\nI suspect you might be hitting this bug: https://bugs.launchpad.net/nova/+bug/1122267\n\nIt was fixed recently, if you refresh the master branch in /opt/stack/nova and restart the nova services, it should be resolved.\n\nRegards,\n\nJulie\n\n\n','<167B45DD-F122-44F8-8CD4-3AA7A78DAD76@cisco.com>',NULL),('<1117384860.35462685.1402775464624.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-14 15:51:04',-14400,'2014-06-14 19:51:04',NULL,'[Openstack] _member_ role after keystone installation','----- Original Message -----\n> From: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> \n> Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 03:22:51 PM:\n> \n> > > From: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> > > To: \"Steve Gordon\" <sgordon at redhat.com>\n> > > \n> > > Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 12:43:48 PM:\n> > > ...\n> > > > Yes, it\'s supposed to be created by the db creation/migration\n> > > > scripts if it\'s not there (since Grizzly if I recall correctly).\n> > > \n> > > But there is also the role spelled \"Member\".  Why both?\n> > > \n> > > Thanks,\n> > > Mike\n> > \n> > When Keystone started creating a \"_member_\" role automatically in\n> > Grizzly there was a lag period before other projects, particularly\n> > Horizon which defaulted to \"Member\" at the time, started using the\n> > new role. As a result the installation guide, and even most\n> > automated deployment tools, which previously had to create the role\n> > as part of installation still created a \"Member\" role because that\n> > was what Horizon expected and there wasn\'t any obvious indication\n> > (although there was a release note for keystone [1]) this was wrong\n> > or no longer required. The Horizon default was eventually updated to\n> > match in this commit to horizon (included in Icehouse and backported\n> > to Havana):\n> > \n> > commit 0aacc44f324c3db049f912da1f84d93c1142cb37\n> > Author: JiaHao Li <kaho_lai at hotmail.com>\n> > Date:   Thu Dec 26 15:37:14 2013 +0800\n> > \n> >     Sync OPENSTACK_KEYSTONE_DEFAULT_ROLE with keystone\n> > \n> >     For now, keystone default role is _member_, while horizon set\n> >     OPENSTACK_KEYSTONE_DEFAULT_ROLE to Member. It will really be user\n> >     friendly to modify horizon default value to _member_ to sync with\n> >     keystone\'s default setting.\n> > \n> >     Change-Id: I55d15e6cfb74e52e933c5a44efd6c27930415738\n> >     Closes-Bug: #1264228\n> > \n> > The end result is many older environments still have both roles\n> > unless action is taken to manually remove the \"Member\" one and\n> > update the Horizon default to the new value, and I should note it\n> > probably wouldn\'t even be that surprising if there are still some\n> > deployment tools creating *new* environments and using a \"Member\"\n> > role - setting horizon to match - in this fashion instead of the\n> > \"_member_\" built-in.\n> > \n> > Thanks,\n> > \n> > Steve\n> > \n> > [1] https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Upgrade_Notes_5\n> > \n> \n> The current situation for users of DevStack is that both _member_ and\n> Member are created, and through the Horizon UI users see both and are not\n> sure why there are two nor which to use.\n> \n> :-(\n> Mike\n\nThis would be an example of \"it probably wouldn\'t even be that surprising if there are still some deployment tools creating *new* environments and using a \"Member\"\" :). Looking at lib/keystone:\n\n318     # The Member role is used by Horizon and Swift so we need to keep it:\n319     MEMBER_ROLE=$(openstack role create \\\n320         Member \\\n321         | grep \" id \" | get_field 2)\n\nAs I outlined above, this means you get two roles because the Keystone SQL will always create \"_member_\". The comment mentions that Horizon and Swift require this, as I outlined above this is no longer true for Horizon - not sure about Swift.\n\n-Steve\n\n\n','<OF7FFDCC9D.ADB0E2B4-ON85257CF7.006BF5B7-85257CF7.006C4119@us.ibm.com>',NULL),('<1117577358.24695.1376069857985.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-09 10:37:38',-25200,'2013-08-09 17:37:38',NULL,'[Openstack] [Quantum] floating IP is unstable when reverse path\n filtering is off','\n?Hi all,\n\n?We are using Quantum on RHEL 6.4 with Linuxbridge-agent.\nWe observed that accessing VM through floating IP becomes unstable\nwhen reverse path filtering is off at the Quantum network node.\nWe are using OpenStack Folsom.\nHas anybody seen the same problem or any solution to make it stable?\n\n?Thanks,\n?David\n\n-- \n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n','<1263772664.24691.1376069810495.JavaMail.root@zm.isi.edu>',NULL),('<111806279.68.1386742479492.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:14:39',0,'2013-12-11 06:14:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-full-grizzly #7','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-full-grizzly/7/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827253 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-full-grizzly/ws/>\n[periodic-tempest-dsvm-full-grizzly] $ /bin/bash -xe /tmp/hudson4352865976438668509.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: Unable to find 9e06327193e2aa23b488c3c566f13acd3f03de87 under https://review.openstack.org/p/openstack-infra/devstack-gate\nCannot obtain needed object 9e06327193e2aa23b488c3c566f13acd3f03de87\nerror: Fetch failed.\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-grizzly/devstack-precise-hpcloud-az2-827253\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-grizzly/devstack-precise-hpcloud-az2-827253/7\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1118869816.64.1373522998250.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-11 06:09:58',0,'2013-07-11 06:09:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-grizzly #92','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/92/>\n\n------------------------------------------\n[...truncated 16262 lines...]\n    mock_obj._Verify()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 506, in _Verify\n    raise ExpectedMethodCallsError(self._expected_calls_queue)\nExpectedMethodCallsError: Verify: Expected methods never called:\n  0.  server_list.__call__(<class \'django.http.HttpRequest\'>) -> [<Server: server_1>, <Server: server_2>]\n\n======================================================================\nERROR: test_edit_attachments_cannot_set_mount_point (openstack_dashboard.dashboards.project.volumes.tests.VolumeViewTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 74, in instance_stub_out\n    return fn(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/dashboards/project/volumes/tests.py\",> line 394, in test_edit_attachments_cannot_set_mount_point\n    res = self.client.get(url)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 439, in get\n    response = super(Client, self).get(path, data=data, **extra)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 244, in get\n    return self.request(**r)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/core/handlers/base.py\",> line 111, in get_response\n    response = callback(request, *callback_args, **callback_kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 38, in dec\n    return view_func(request, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 53, in dec\n    if request.user.is_authenticated():\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_edit_attachments_cannot_set_mount_point (openstack_dashboard.dashboards.project.volumes.tests.VolumeViewTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 151, in tearDown\n    self.mox.VerifyAll()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 286, in VerifyAll\n    mock_obj._Verify()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 506, in _Verify\n    raise ExpectedMethodCallsError(self._expected_calls_queue)\nExpectedMethodCallsError: Verify: Expected methods never called:\n  0.  server_list.__call__(<class \'django.http.HttpRequest\'>) -> [<Server: server_1>, <Server: server_2>]\n\n======================================================================\nERROR: test_get_data (openstack_dashboard.dashboards.project.volumes.tests.VolumeViewTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 74, in instance_stub_out\n    return fn(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/dashboards/project/volumes/tests.py\",> line 471, in test_get_data\n    HTTP_X_REQUESTED_WITH=\'XMLHttpRequest\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 439, in get\n    response = super(Client, self).get(path, data=data, **extra)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 244, in get\n    return self.request(**r)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/core/handlers/base.py\",> line 111, in get_response\n    response = callback(request, *callback_args, **callback_kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 38, in dec\n    return view_func(request, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 53, in dec\n    if request.user.is_authenticated():\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_get_data (openstack_dashboard.dashboards.project.volumes.tests.VolumeViewTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 151, in tearDown\n    self.mox.VerifyAll()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 286, in VerifyAll\n    mock_obj._Verify()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 506, in _Verify\n    raise ExpectedMethodCallsError(self._expected_calls_queue)\nExpectedMethodCallsError: Verify: Expected methods never called:\n  0.  volume_get.__call__(<class \'django.http.HttpRequest\'>, \'41023e92-8008-4c8b-8059-7f2293ff3775\') -> <Volume: 41023e92-8008-4c8b-8059-7f2293ff3775>\n\n======================================================================\nERROR: test_timezone_offset_is_displayed (openstack_dashboard.dashboards.settings.user.tests.UserSettingsTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/dashboards/settings/user/tests.py\",> line 28, in test_timezone_offset_is_displayed\n    res = self.client.get(INDEX_URL)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 439, in get\n    response = super(Client, self).get(path, data=data, **extra)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/client.py\",> line 244, in get\n    return self.request(**r)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/core/handlers/base.py\",> line 111, in get_response\n    response = callback(request, *callback_args, **callback_kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 38, in dec\n    return view_func(request, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/horizon/decorators.py\",> line 53, in dec\n    if request.user.is_authenticated():\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (openstack_dashboard.test.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 283, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/openstack_dashboard/test/helpers.py\",> line 283, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.19 secs:\n    0.40    RoleAPITests.test_get_default_role\n    0.25    SwiftApiTests.test_swift_create_container\n    0.20    NetworkTests.test_network_detail_port_exception\n    0.20    NetworkTests.test_network_detail_port_exception\n    0.15    ImagesAndSnapshotsTests.test_index_error\n----------------------------------------------------------------------\nRan 425 tests in 8.389s\n\nFAILED (SKIP=3, errors=598, failures=2)\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --cover-package=openstack_dashboard --cover-inclusive --all-modules\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==jenkins.periodic.horizon.python27.stable.grizzly.92\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.aqyL48aJz1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-grizzly/92\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-grizzly/92/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-grizzly/92/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<389819886.59.1373436466263.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1118996988.15.1357693639748.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-09 01:07:19',0,'2013-01-09 01:07:19',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-postgres-vm-full #62','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/62/>\n\n\n\n','<223853718.13.1357605821942.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1119160419.26876558.1403630455244.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 13:20:55',-14400,'2014-06-24 17:20:55',NULL,'[openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup','> On 6/20/14, 6:24 AM, \"Radomir Dopieralski\" <openstack at sheep.art.pl> wrote:\n> \n> >On 20/06/14 13:56, Jaromir Coufal wrote:\n> >> On 2014/19/06 09:58, Matthias Runge wrote:\n> >>> On Wed, Jun 18, 2014 at 10:55:59AM +0200, Jaromir Coufal wrote:\n> >>>> My quick questions are:\n> >>>> * Who would be interested (and able) to get to the meeting?\n> >>>> * What topics do we want to discuss?\n> >>>>\n> >>>> https://etherpad.openstack.org/p/horizon-juno-meetup\n> >>>>\n> >>> Thanks for bringing this up!\n> >>>\n> >>> Do we really have items to discuss, where it needs a meeting in person?\n> >>>\n> >>> Matthias\n> >> \n> >> I am not sure TBH, that\'s why I added also the Topic section to figure\n> >> out if there is something what needs to be discussed. Though I don\'t see\n> >> much interest yet.\n> >\n> >Apart from the split, I also work on configuration files rework, which\n> >could benefit from discussion, but i think it\'s better done here or on\n> >the wiki/etherpad, as that leaves tangible traces. I will post a\n> >detailed e-mail in a few days. Other than that, I don\'t see a compelling\n> >reason to organize it.\n> >\n> >--\n> >Radomir Dopieralski\n> >\n> \n> I don?t think the split warrants a mid-cycle meetup. A topic that would\n> benefit from several people being in the room is client side architecture,\n> but I?m not entirely sure we?re ready to work through that yet, and the\n> dates are a little aggressive.  If we have interest in that, we could look\n> to a slightly later date.\n> \n> David\n\nThis was talked about a bit in today\'s Horizon weekly IRC meeting, and the\noutcome was that it might make sense to see if people have the interest or\nthe time to attend such a meetup.  In order to gauge interest, here\'s an\netherpad where interested parties can put down their names next to dates\nwhen they\'d be available to attend.\n\nhttps://etherpad.openstack.org/p/juno-horizon-meetup\n\nMainn\n\n\n','<CFC9BA06.16DA8%david.lyle@hp.com>',NULL),('<111930062.10271776.1375394401957.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-01 18:00:01',-14400,'2013-08-01 22:00:01',NULL,'[Openstack-docs] Common content strategy?','----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, August 1, 2013 5:27:22 PM\n> Subject: Re: [Openstack-docs] Common content strategy?\n> \n> On 02/08/13 07:26, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Tom Fifield\" <tom at openstack.org>\n> >> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >> Cc: openstack-docs at lists.openstack.org\n> >> Sent: Thursday, August 1, 2013 4:58:41 PM\n> >> Subject: Re: [Openstack-docs] Common content strategy?\n> >>\n> >> On 02/08/13 06:17, Steve Gordon wrote:\n> >>> ----- Original Message -----\n> >>>> From: \"Tom Fifield\" <tom at openstack.org>\n> >>>> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >>>> Cc: openstack-docs at lists.openstack.org\n> >>>> Sent: Thursday, August 1, 2013 4:08:35 PM\n> >>>> Subject: Re: [Openstack-docs] Common content strategy?\n> >>>>\n> >>>> On 02/08/13 06:06, Steve Gordon wrote:\n> >>>>> ----- Original Message -----\n> >>>>>> From: \"Tom Fifield\" <tom at openstack.org>\n> >>>>>> To: openstack-docs at lists.openstack.org\n> >>>>>> Sent: Thursday, August 1, 2013 3:53:54 PM\n> >>>>>> Subject: Re: [Openstack-docs] Common content strategy?\n> >>>>>>\n> >>>>>> Just quickly on the crazy linking that\'s going on right now.\n> >>>>>>\n> >>>>>> I\'m one of the worst offenders of breaking the model, but I believe\n> >>>>>> there\'s good reason ... in doing the restructure, I\'m trying to keep\n> >>>>>> current things in place, but note that they\'ll be subsumed as further\n> >>>>>> progress is made.\n> >>>>>>\n> >>>>>> If there\'s a big effort to push content into the common folder right\n> >>>>>> now, you\'ll end up with most of the compute admin manual and the\n> >>>>>> config\n> >>>>>> reference in the common folder.\n> >>>>>\n> >>>>> Given at this stage the intent is to continue to release the compute\n> >>>>> administration guide isn\'t that correct though (in that the content\n> >>>>> *is*\n> >>>>> common to both)? Keep in mind here also that large swaths of the\n> >>>>> compute\n> >>>>> admin manual already appear in common (this is in part why I brought up\n> >>>>> the taxonomy question).\n> >>>>\n> >>>> Not for the next release, unless you want to write it :)\n> >>>\n> >>> OK, it was still listed last I saw - just not as one of the two\n> >>> deliverables that must be ready:\n> >>>\n> >>> http://lists.openstack.org/pipermail/openstack-docs/2013-July/002391.html\n> >>\n> >> Yep, I disagree with this, so I\'ve replied to that thread :)\n> >>\n> >>>> Additionally, the content in config ref that is currently xi:included\n> >>>> will be struck from the compute admin guide - it will not be common to\n> >>>> both.\n> >>>\n> >>> Right, but to me that is all the more reason to do it now. As it\n> >>> currently\n> >>> stands without any of my commits on this issue being merged there are\n> >>> ~144\n> >>> relative includes in openstack-config, of those only 10 go to locations\n> >>> outside of common (which are the ones I want to move).\n> >>\n> >> So https://review.openstack.org/#/c/39731 is an example of where this\n> >> consolidation is a bad idea right now :)\n> >>\n> >> I\'m in the middle of working through re-doing which xen bit sit wher,\n> >> and would just end up un-doing the move proposed in the patch.\n> >\n> > The problem though is bits and pieces of that redo are already committed,\n> > resulting in this kind of structure:\n> >\n> > * openstack-config/ch_computehypervisors.xml\n> >    * Includes -> ../common/introduction-to-xen.xml\n> >      * Includes -> ../openstack-config/compute-configure-xen.xml\n> >        * Includes -> ../common/tables/nova-xen.xml\n> >\n> > Are you suggesting that your approach to this will be to move the 3/4 files\n> > in this chain that are in common now to openstack-config, rather than the\n> > opposite as proposed in my patch? If the plan is for these files to move\n> > to openstack-config and be dropped from the other guide(s) then I\'d\n> > suggest making a list and let\'s get it done.\n> \n> Yes\n> \n\nOK, what is the expected final resting place of these others that I have come across in my travels (cases where openstack-config includes content from other guides that is not in common):\n\nopenstack-config/ch_blockstorageconfigure.xml: \"../openstack-install/samples/cinder.conf\"\nopenstack-config/ch_computeconfigure.xml: \"../openstack-install/samples/nova.conf\"\nopenstack-config/ch_computeconfigure.xml: \"../openstack-install/samples/nova.conf\"\nopenstack-config/ch_computeconfigure.xml: \"../openstack-compute-admin/figures/SCH_5004_V00_NUAC-Network_mode_KVM_Flat_OpenStack.png\"\nopenstack-config/ch_computeconfigure.xml: \"../openstack-compute-admin/figures/SCH_5005_V00_NUAC-Network_mode_XEN_Flat_OpenStack.png\"\nopenstack-config/ch_computescheduler.xml: \"../openstack-compute-admin/figures/filteringWorkflow1.png\"\nopenstack-config/ch_computescheduler.xml: \"../openstack-compute-admin/figures/filteringWorkflow2.png\"\nopenstack-config/ch_identityconfigure.xml: \"../openstack-install/samples/keystone.conf\"\n\nAre these also cases where the content will be removed from the original guide?\n\nThanks,\n\nSteve\n\n\n','<51FAD2BA.8070809@openstack.org>',NULL),('<111eb62980294c5c8d4ea048606efc79@BRMWP-EXMB11.corp.brocade.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 13:06:51',0,'2015-01-08 13:06:51',NULL,'[openstack-dev] Mirantis Openstack 5.1 environment issues','Hi Fuel Team,\n\n         Hope you are doing good.  We are facing issues in Mirantis Openstack 5.1 environment as below;\n\n\n1)      Verify network got failed with message Expected VLAN (not received) untagged at the interface Eth1 of controller and compute nodes.\n\nIn our set-up Eth1 is connected to the public network, which we disconnect from public network while doing deployment operation as FUEL itself works as DHCP server. We want know that is this a known issue in Fuel or from our side, as we followed this prerequisite before doing verify network operation.\n\n\n2)      Eth1 interface in the Fuel UI is showing as down even after connecting back cables into the nodes.\n\nBefore doing openstack deployment  from Fuel node, we disconnected eth1 from controller and compute nodes as it is connected to public network.  Deployment was successful and then we connected back the Eth1 of all controller/compute nodes.  We are seeing an issue that eth1 displaying as down in FUEL UI, even though we connect back eth1 interface and we are able to ping to public network.\n\n\n3)       Neutron dead but pid file exists.\n\nWe are seeing this issue in the controller node after restarting the neutron server.  We stopped all neutron related services and tried to restart neutron-server , but still neutron-server is not starting.\n\n\n                               We are sharing the logs (Diagnostic Snapshots) for above issues. Please find the drop-box link below.  Thanks.\n\n\nDrop-box link:\nhttps://www.dropbox.com/s/644dxj15nge5bo1/fuel-snapshot-2015-01-06_11-09-35.tgz?dl=0\n\n\nRegards,\nPavan\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150108/da2afd4a/attachment.html>\n\n',NULL,NULL),('<1120158474.28541573.1406745491328.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 14:38:11',-14400,'2014-07-30 18:38:11',NULL,'[openstack-dev] [NFV] Meeting summary 2014-07-30','Meeting summary\n\n        https://etherpad.openstack.org/p/nfv-meeting-agenda (russellb, 14:00:32)\n\n    review actions from last week (russellb, 14:00:48)\n        ACTION: bauzas to update list with link to new dash (sgordon, 14:02:34)\n        https://review.openstack.org/#/c/95805/2 (sgordon, 14:02:54)\n        https://review.openstack.org/#/c/107797/1 (sgordon, 14:03:00)\n        http://lists.openstack.org/pipermail/openstack-dev/2014-July/040660.html (sgordon, 14:03:25)\n        http://lists.openstack.org/pipermail/openstack-dev/2014-July/040877.html (sgordon, 14:03:30)\n\n    blueprints (sgordon, 14:09:00)\n        https://wiki.openstack.org/wiki/Meetings/NFV#Active_Blueprints (sgordon, 14:09:56)\n        https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net (sgordon, 14:10:13)\n        multiple-if-1-net approved, code up for review (sgordon, 14:10:26)\n        https://review.openstack.org/#/c/98488/ (sgordon, 14:11:33)\n        https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (sgordon, 14:12:59)\n        https://review.openstack.org/#/c/97714/ (sgordon, 14:13:17)\n        https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity (sgordon, 14:15:12)\n\n    Team goals and structure (sgordon, 14:16:33)\n        Broader communication with wider development (nova, neutron, etc.) communities required to illustrate what NFV is and is not, current state and progress (sgordon, 14:26:14)\n        Feedback from nova midcycle is that more needs to be done to front load the earlier release milestones late in the previous cycle (sgordon, 14:26:50)\n        Cross-project design session proposal for Kilo summit needs to be co-ordinated and have specific goals to be accepted (sgordon, 14:30:32)\n        ACTION: Bring possible topics/goals for cross-project session to next week\'s meeting. (sgordon, 14:33:44)\n\n    meeting times (sgordon, 14:39:10)\n        http://whenisgood.net/exzzbi8 (sgordon, 14:40:00)\n        please vote on future meeting times by EoW (sgordon, 14:40:10)\n\n    open discussion (sgordon, 14:44:27)\n        ACTION: sgordon confirm future meeting times at next week\'s meeting (sgordon, 14:46:51)\n        ACTION: adrian-hoban to follow up on M/L regarding potential for pre-loading the early kilo milestones (sgordon, 14:55:24)\n        ACTION: smazziotta to report on outcome of ETSI NFV gaps discussion at next week\'s meeting (sgordon, 14:56:06)\n\nFull logs: http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-30-14.00.log.html\n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<406743510.28541071.1406745432821.JavaMail.zimbra@redhat.com>',NULL),('<1120628219.29220831.1407868006193.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 14:26:46',-14400,'2014-08-12 18:26:46',NULL,'[openstack-dev] [all] The future of the integrated release',' \n> It seems like this is exactly what the slots give us, though. The core review\n> team picks a number of slots indicating how much work they think they can\n> actually do (less than the available number of blueprints), and then\n> blueprints queue up to get a slot based on priorities and turnaround time\n> and other criteria that try to make slot allocation fair. By having the\n> slots, not only is the review priority communicated to the review team, it\n> is also communicated to anyone watching the project.\n\nOne thing I\'m not seeing shine through in this discussion of slots is\nwhether any notion of individual cores, or small subsets of the core\nteam with aligned interests, can \"champion\" blueprints that they have\na particular interest in.\n\nFor example it might address some pain-point they\'ve encountered, or\nimpact on some functional area that they themselves have worked on in\nthe past, or line up with their thinking on some architectural point.\n\nBut for whatever motivation, such small groups of cores currently have\nthe freedom to self-organize in a fairly emergent way and \"champion\"\nindividual BPs that are important to them, simply by *independently*\ngiving those BPs review attention.\n\nWhereas under the slots initiative, presumably this power would be\nsubsumed by the \"group will\", as expressed by the prioritization\napplied to the holding pattern feeding the runways?\n\nI\'m not saying this is good or bad, just pointing out a change that\nwe should have our eyes open to.\n\nCheers,\nEoghan\n\n\n','<4E2D50FE-8F56-4A09-9079-70396CF416A0@doughellmann.com>',NULL),('<1120684730.23760522.1408951372102.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 03:22:52',-14400,'2014-08-25 07:22:52',NULL,'[openstack-dev] [neutron] Runtime checks vs Sanity checks','\nIn spite of my +1 I actually agree. I had forgotten about the sanity\ncheck framework. We put it in place to avoid an excessive (and\ngrowing) amount of checks to be done in runtime.\n\nIn this case several agents need would be doing the same check.\n\nWe should do things either one way or another, but not mixed.\n\nIn this case, the check would require a privilege drop to be done:\n(probably could be done by using a root_helper= \n\"su - %(neutron_user)s %(root_helper)s\")\n\n\n\nBest regards,\nMiguel ?ngel.\n\n----- Original Message -----\n> Kevin Benton has proposed adding a runtime check for netns permission\n> problems:\n> \n> https://review.openstack.org/#/c/109736/\n> \n> There seems to be consensus on the patch that this is something that we want\n> to do at runtime, but that would seem to run counter to the precedent that\n> host-specific issues such as this one be considered a deployment-time\n> responsibility.  The addition of the sanity check  framework would seem to\n> support the latter case:\n> \n> https://github.com/openstack/neutron/blob/master/neutron/cmd/sanity_check.py\n> \n> Thoughts?\n> \n> \n> Maru\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<AFE645FE-7479-4900-883B-9B59B1377FFB@redhat.com>',NULL),('<112100518.35.1355789915722.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-18 00:18:35',0,'2012-12-18 00:18:35',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #78','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/78/>\n\n\n\n','<1168103295.8.1355702547593.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1121275921.18961856.1383594619780.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-04 14:50:19',-18000,'2013-11-04 19:50:19',NULL,'[Openstack-docs] network plug-in options in install guide','Having both ML2 and OVS documented sounds good to me.  Currently, I\'m a bit busy tracking down and fixing a bug involving communication between Nova and Cinder, but if nobody else has written such a section by the time I have finished, I can take a shot at adding a path to the Neutron install guide for ML2.  The patch that you referenced seems to have targeted the use cases section only, and not the main \"Installing Networking Services\" section.\n\nAs for the Use Case section, my suggestion would be to have each use case specify a particular path through the guide, so it would read like \"Use Case: XYZ.  The XYZ use case covers the situation when you want to have the QPW XTZ the NPO.  In an XZY setup, all QPWs have LXYs.  In order to set up this use case, you should follow the main documentation, and choose to follow the OVS path with GRE networking and no namespaces.\"  In fact, we could generalize this to broader OpenStack \"typical setup\" use cases, and have each OpenStack \"typical setup\" have a particular path through the guide with a list of documentation \"modules\" to follow to get that setup (e.g. \"Follow sections 1 (Basic Setup), 2 (Keystone), ..., 9 (Neutron, and choose the OVS plugin with GRE tunneling), and 10 (Orchestration).\"  This way, if somebody goes up to the guide without having already figured out what they want, they\'ll have a couple suggested paths to follow.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Andreas Jaeger\" <aj at suse.com>\nTo: openstack-docs at lists.openstack.org\nCc: \"Solly Ross\" <sross at redhat.com>\nSent: Monday, November 4, 2013 2:31:45 PM\nSubject: network plug-in options in install guide\n\nLooking at the guide, you see cross-references jumping to other sections.\n\nSolly said in https://bugs.launchpad.net/openstack-manuals/+bug/1244759 :\n\"The idea with the sections for the different plugins was that some of\nthe other companies/organizations with their own plugins would fill in\nparts for their own sections.\"\n\nRight now only Open vSwitch is documented. Instead of replacing Open\nvSwitch with ML2 (see https://review.openstack.org/#/c/54644/), why not\nhave both ML2 and Open vSwitch documented as two different options there?\n\nWe still would need to decide what to use in the \"Neutron deployment use\ncases\"\n(http://docs.openstack.org/trunk/install-guide/install/zypper/content/neutron-deploy-use-cases.html)\n- but that whole content is IMHO so inconsistent with the rest that it\nneeds a rewrite anyway.\n\nAndreas\n-- \n Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n\n','<5277F621.1020008@suse.com>',NULL),('<11213F12-B419-4EA9-9153-3C798F33955C@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 11:34:31',-18000,'2014-11-12 16:34:31',NULL,'[openstack-dev] oslo.vmware release 0.7.0','The Oslo team is pleased to announce the release of oslo.vmware 0.7.0.\n\nThis release includes several bug fixes (https://launchpad.net/oslo.vmware/+milestone/0.7.0) as well as many other changes:\n\n\n1661a0a Updated from global requirements\n33f6002 Imported Translations from Transifex\n8b1f97b Do not log when reraising an exception\n575fd70 Imported Translations from Transifex\n0b7ff54 Updated from global requirements\n8ed3d53 Add unit test for VC 5.1 web fault handling\n776c20d Fix to get exception detail with vCenter 5.1\n62d0ba7 Download image API to bypass vCenter\n6aa427d Updated from global requirements\n84a39fb Updated from global requirements\ne25af91 Enable the PBM WSDL to be updated\n9f6f2a3 Support building wheels (PEP-427)\n73d1160 Fixup autoindex.rst only if it exists\n42eab0c Supress error logs when exception is thrown\n2350257 Fix handling of fault details\n7591589 Fix UnboundLocalError during WebFault handling\n89d0131 Use faultstring attribute in suds.WebFault.fault\n54455f2 Imported Translations from Transifex\n95e84eb Fix the log message for progress\n264e428 Add API to get the entity inventory path\nee4d9c0 VimExceptions need to support i18n objects\ndf59368 Switch to using oslo.utils\ne55e677 Use custom transport adapter for file URLs\n1c2987b getText can be called only when doc is not None\ndef85dd Updated from global requirements\n80057e4 Add unit test for suds cache expiration\na3e493a Add a memory based shared cache\n6a72bf1 Updated from global requirements\n4bd0b4c VMware: Enable vCenter SSL certificate validation\n\n\nFor more details, please see the git log history below or http://git.openstack.org/cgit/openstack/oslo.vmware/log/\n\nPlease report issues through launchpad: https://launchpad.net/oslo.vmware\n\n----\n\n$ git log --no-merges 0.6.0..0.7.0\n\ncommit 1661a0af8ce14edbfb00fed0a30a3b9135517d93\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Wed Nov 5 08:35:10 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: I88286d9ef8ff5fc5210a9ed87bacffd60ff78a56\n\ncommit 33f60020b7b476e07edbf8fa40e755887ce66f2a\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Sun Nov 2 06:08:05 2014 +0000\n\n    Imported Translations from Transifex\n    \n    For more information about this automatic import see:\n    https://wiki.openstack.org/wiki/Translations/Infrastructure\n    \n    Change-Id: I2edec2f04103684b48e37e3d3cbf52756c7ae6a8\n\ncommit 8b1f97bc7e36b4c3bf85fb6c92b7481e6845f470\nAuthor: Arnaud Legendre <arnaudleg at gmail.com>\nDate:   Wed Oct 22 16:56:53 2014 -0700\n\n    Do not log when reraising an exception\n    \n    It should be up to the caller to use the log level error\n    when the exception is reraised. For example, if the call\n    to a VIM api fails, _poll_task is currently throwing a big\n    red block even if the caller ignores the exception.\n    \n    This patch removes the logging from _poll_task.\n    \n    Change-Id: I5bceb41c9a24dca45ff8689daee0eeafa7da839c\n\ncommit 575fd70985b5d21dbbe36efc317d9b0a0256d990\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Tue Oct 28 06:08:32 2014 +0000\n\n    Imported Translations from Transifex\n    \n    For more information about this automatic import see:\n    https://wiki.openstack.org/wiki/Translations/Infrastructure\n    \n    Change-Id: I376cde927d248be21354cee58e43bce78dec8832\n\ncommit 0b7ff54050e2e6565c9e8a3b71b41155524527d4\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Mon Oct 27 12:21:13 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: Id3da9d10632b68df8017d4f3dc69cec6ff2f1eb1\n\ncommit 8ed3d5308aae453c9f5ed3cd543e91dbf7c4dd9b\nAuthor: Vipin Balachandran <vbala at vmware.com>\nDate:   Tue Oct 14 17:30:48 2014 +0530\n\n    Add unit test for VC 5.1 web fault handling\n    \n    This patch adds unit test for web fault raised by vCenter 5.1.\n    \n    Change-Id: I6879dcb50db919386facd81d3ba5e7b133f75397\n\ncommit 776c20d96845c602ed60aea0962c6bb190fa67a5\nAuthor: Arnaud Legendre <arnaudleg at gmail.com>\nDate:   Mon Oct 13 17:34:32 2014 -0700\n\n    Fix to get exception detail with vCenter 5.1\n    \n    The current child path used \'/detail\' is not compatible with\n    vCenter 5.1.\n    \n    This patch adds a lookup to \'/Envelope/Body/Fault/detail\' to make\n    sure we get the detail of the exception.\n    \n    Change-Id: Id5ca2d87a7cba8b531a4c54111505e72c70df021\n\ncommit 62d0ba719d7dde8507f558a95a3a8844445f5655\nAuthor: Arnaud Legendre <arnaudleg at gmail.com>\nDate:   Wed Sep 17 13:56:12 2014 -0700\n\n    Download image API to bypass vCenter\n    \n    This patch introduces a new API to download images. This new API\n    provides a new signature which gives the ability to bypass vCenter\n    when downloading images.\n    \n    Change-Id: Id3cf3f03e1d0622a99573bd090b8ea6b397765e0\n\ncommit 6aa427d733b6ac215477f99ffd6727f4f8b9063a\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Mon Oct 13 18:50:38 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: Id7ac4a6fda3eb2701ab372ce63cfc4f697edced4\n\ncommit 84a39fb46b63dc07d9387518cf4e673d6ef8d46b\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Sat Oct 11 15:56:20 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: Iea56589abd2f4a764bbd22fc92fb3d2a9189d276\n\ncommit e25af91e2a5a58b8568da6c0e03c4c87cadf09b3\nAuthor: Gary Kotton <gkotton at vmware.com>\nDate:   Mon Aug 18 04:58:10 2014 -0700\n\n    Enable the PBM WSDL to be updated\n    \n    Enables the PBM WSDL to be updated after a session is created.\n    \n    An update of the WSDL will set the pbm value to None. This is lazy loaded\n    so the next access to it will result in the correct session being created.\n    \n    Change-Id: Id70a7928ca84846018ee0a62ac020ecbeac1f5d6\n\ncommit 9f6f2a333ba1fd71a11f0c26665ee627e3eefe98\nAuthor: Davanum Srinivas <dims at linux.vnet.ibm.com>\nDate:   Thu Oct 2 16:18:01 2014 -0400\n\n    Support building wheels (PEP-427)\n    \n    Universal is used to identify pure-Python module(by bdist_wheel). For\n    these, it is sufficient to build a wheel with _any_ Python ABI version\n    and publish that to PyPI (by whatever means).\n    \n    Change-Id: I2f3b3a5f75aa8dbe4c40f3b9a1d0da43a4b1a0f1\n\ncommit 73d116001bccd243fc3394c189028447ee16e514\nAuthor: Davanum Srinivas <dims at linux.vnet.ibm.com>\nDate:   Sun Sep 21 18:13:37 2014 -0400\n\n    Fixup autoindex.rst only if it exists\n    \n    Closes-Bug: #1370370\n    \n    Change-Id: I05638808b577db8e96e5b83aa8b5a9c47f8170c1\n\ncommit 42eab0c82f0ef17cd1e7dd54da2964b8eb19c660\nAuthor: Radoslav Gerganov <rgerganov at vmware.com>\nDate:   Mon Oct 6 15:40:27 2014 +0300\n\n    Supress error logs when exception is thrown\n    \n    There are many cases when exceptions from the backend are expected and\n    these exceptions must not be logged as errors. For example it is a\n    common pattern to catch DuplicateName/AlreadyExists exceptions and\n    ignore them in the cases when multiple threads are trying to perform the\n    same operation. Currently there is no way for clients to prevent logging\n    these exceptions as errors and the proper way to fix this is to just\n    raise the exception in oslo and let the client decide if it must be\n    logged as an error or not.\n    \n    Closes-Bug: #1377927\n    Change-Id: I5309cad5b0eeb380387eb3051d80c59b783561e8\n\ncommit 2350257410610b6a0ebf9b28ab9fcddc5551ca87\nAuthor: Radoslav Gerganov <rgerganov at vmware.com>\nDate:   Fri Oct 3 17:17:39 2014 +0300\n\n    Fix handling of fault details\n    \n    Fix regression caused by adding a new transport based on \'requests\'\n    in commit 4bd0b4cf. When a Fault message is returned from the backed,\n    the \'Envelope\' and \'Body\' tags are stripped and the root element becomes\n    \'Fault\'. The path to the \'detail\' string becomes \'/detail\' instead of\n    \'/Envelope/Body/Fault/detail\'. The stripping is done in:\n    \n    suds/bindings/binding.py#detect_fault()\n    \n    which was not executed when the old http transport was used.\n    \n    Change-Id: I1b99d37fdbcbf5ea05e4823e408468a06e230ccf\n\ncommit 759158933413c8d9721a47060b77e9d6e7758cf9\nAuthor: Vipin Balachandran <vbala at vmware.com>\nDate:   Wed Oct 1 14:21:29 2014 +0530\n\n    Fix UnboundLocalError during WebFault handling\n    \n    If the document attribute of WebFault is unset, the \'detail\' local\n    variable will be referenced before assignment which results in\n    UnboundLocalError. This patch fixes the problem by initializing\n    \'detail\' to None.\n    \n    Change-Id: Icf17503f46eaa389b1f31dfffc84f21f69cde3aa\n    Closes-Bug: #1376172\n\ncommit 89d01319c71a3a14edc1b29fa6aa55131242d0d3\nAuthor: Vipin Balachandran <vbala at vmware.com>\nDate:   Fri Sep 19 15:42:56 2014 +0530\n\n    Use faultstring attribute in suds.WebFault.fault\n    \n    WebFault handling fails with AttributeError if there is no element at\n    path \'/Envelope/Body/Fault/faultstring\'. This patch fixes the problem\n    by using faultstring attribute in WebFault.fault.\n    \n    Closes-Bug: #1371547\n    Change-Id: Ic61b22f833dd82f4c4e2d424f320526d1bd8eacd\n\ncommit 54455f2a0b5589af1d4e77a1987770f957991e0e\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Tue Sep 30 06:45:01 2014 +0000\n\n    Imported Translations from Transifex\n    \n    Change-Id: I1ebf869aa3f4d723fdc0fb01c8c72eaa81b4f289\n\ncommit 95e84ebc8814f1cfb5a143837f778350b17ba55a\nAuthor: Radoslav Gerganov <rgerganov at vmware.com>\nDate:   Mon Sep 29 14:15:22 2014 +0300\n\n    Fix the log message for progress\n    \n    The log message for progress throws TypeError because a mapping is\n    expected. This patch fix the format string of the message.\n    \n    Change-Id: I9b9ec1f8ef9ead4371b7d58bd12a35ec7d486d6a\n\ncommit 264e428b4f2d1a987b884742228d3e78a61cca05\nAuthor: Arnaud Legendre <alegendre at vmware.com>\nDate:   Thu Sep 18 12:30:14 2014 -0700\n\n    Add API to get the entity inventory path\n    \n    This new API provides the inventory path for a given entity reference.\n    Currently, the Nova transfer of images feature fails if the datacenter\n    is located in folders. This API has to be called prior to any HTTP\n    access to datastores.\n    \n    Change-Id: I14066601816584689fb955927496d250ed825dc2\n\ncommit ee4d9c02d3a7f404aed967c6f9212da263b84c58\nAuthor: James Carey <jecarey at us.ibm.com>\nDate:   Wed Sep 17 15:52:53 2014 +0000\n\n    VimExceptions need to support i18n objects\n    \n    When lazy is enabled the i18n translation object does not support\n    str() which causes failures like:\n      UnicodeError: Message objects do not support str() because they may\n      contain non-ascii characters. Please use unicode() or translate()\n      instead.\n    \n    Removed str() in __init__ and updated __str__ and __unicode__\n    in VimException and VimFaultsException to correctly handle this object.\n    Also updated a couple of test cases to use an i18n translation object.\n    \n    Closes-Bug: #1374210\n    Change-Id: Id55b5deb5535ba5352b449a3b78099aa912a0b54\n\ncommit df59368f76eb56fdd64ff9dac23eed805a7f07c8\nAuthor: Davanum Srinivas <dims at linux.vnet.ibm.com>\nDate:   Thu Sep 25 11:55:30 2014 -0400\n\n    Switch to using oslo.utils\n    \n    Change-Id: If97d1d95341db9fbc33f6824ff326ee3fc64d8ee\n\ncommit e55e677120d18e3204bc33570c9e4db916d27300\nAuthor: Vipin Balachandran <vbala at vmware.com>\nDate:   Thu Sep 18 19:02:53 2014 +0530\n\n    Use custom transport adapter for file URLs\n    \n    The requests library doesn\'t support local file URLs. The PBM WSDL is\n    stored locally and this affects all PBM API invocations. This patch\n    fixes the problem by registering a custom transport adapter for local\n    files.\n    \n    Closes-Bug: #1371575\n    Change-Id: Ie0635607847061c68c879e87db8f2541436f03d6\n\ncommit 1c2987bc4cb19fd53299abb8783763042348a768\nAuthor: Arnaud Legendre <arnaudleg at gmail.com>\nDate:   Mon Sep 22 12:08:54 2014 -0700\n\n    getText can be called only when doc is not None\n    \n    Add a check to make sure getText is executed only when doc is\n    not None.\n    Without this check, we can potentially get:\n    AttributeError: \'NoneType\' object has no attribute \'getText\'\n    \n    Change-Id: I8e2abd3abf015733642419cb8a3b86aec09c929f\n\ncommit def85dd151ec70031a801913f06f88b998e580a2\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Fri Sep 19 08:51:12 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: I1ae5d64f89c0207a4e83cd18d7b281620520af57\n\ncommit 80057e4034aa4b2308d795aa46c12ddad7d19d4b\nAuthor: Vipin Balachandran <vbala at vmware.com>\nDate:   Wed Sep 17 18:45:36 2014 +0530\n\n    Add unit test for suds cache expiration\n    \n    This patch adds a unit test for suds cache expiration case.\n    \n    Change-Id: Iad261107c904bb9a613decfeaf56061727b3f674\n\ncommit a3e493a96b904a1cfa342b78f89d57da98e34962\nAuthor: Davanum Srinivas <dims at linux.vnet.ibm.com>\nDate:   Fri Aug 22 10:28:35 2014 -0400\n\n    Add a memory based shared cache\n    \n    Simple dictionary based shared cache to speed up not just\n    a single set of nested wsdl/xsd(s) but also to share the\n    same cache, so when the same initial wsdl is loaded again\n    we still use the cached data from the previous wsdl load.\n    We essentially take the hit on the first wsdl load and\n    subsequent loads will be much faster. The cached items\n    expire in an hour to both clean up memory as well as\n    switch to newer wsdl/xsd(s) when the vCenter is upgraded\n    without needed a forced restart of nova compute process.\n    \n    Change-Id: Ia2265f1f8ed5fe8b05770a5572f1516893b532a0\n\ncommit 6a72bf1342d2ebf12bd79b7943747681d5877d6e\nAuthor: OpenStack Proposal Bot <openstack-infra at lists.openstack.org>\nDate:   Sat Sep 13 07:27:49 2014 +0000\n\n    Updated from global requirements\n    \n    Change-Id: Iac0539078c9e665cc17a4f316df8f945e2e55110\n\ncommit 4bd0b4cf7ab45f121aaedfdf55c77aa72bce8b38\nAuthor: Davanum Srinivas <dims at linux.vnet.ibm.com>\nDate:   Tue Sep 9 15:01:33 2014 -0400\n\n    VMware: Enable vCenter SSL certificate validation\n    \n    During https/ssl communication the server certificate of\n    a vCenter is not validated during https handshake process.\n    This patch will enable the certificate validation against root\n    certificate of the vCenter to validate the identity of that vCenter.\n    Nova, Cinder etc will need to specify the cacert parameter\n    for this to take effect.\n    \n    Ported from Id: Ic24951630698068321bb62d3098de8344a35c5d0\n    \n    Closes-Bug: #1276207\n    Co-Authored-By: Johnson koil raj <johnson.raj at hp.com>\n    Change-Id: I422e6d4df4e392334c0ce47e6f5b017a8c95f61a\n\n\n\n',NULL,NULL),('<1121531049.10110.1348853250919.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-28 10:27:30',-25200,'2012-09-28 17:27:30',NULL,'[openstack-dev] Is snapshot of LXC broken?','\n Hi,\n\n I\'m testing snapshot of LXC instance using stable/folsom branch.\nI got the error messages which I put at the end of this email.\nI think it is a bug.\n\n Thanks,\n David\n\nError message ===============\n\n2012-09-28 13:12:06 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in _process_data\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145, in dispatch\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     return f(*args, **kw)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 181, in decorated_function\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     pass\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 167, in decorated_function\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 202, in decorated_function\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     kwargs[\'instance\'][\'uuid\'], e, sys.exc_info())\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 196, in decorated_function\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 1163, in snapshot_instance\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     self.driver.snapshot(context, instance, image_id)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     return f(*args, **kw)\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/virt/libvirt/driver.py\", line 822, in snapshot\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp     disk_path = source.get(\'file\')\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp AttributeError: \'NoneType\' object has no attribute \'get\'\n2012-09-28 13:12:06 TRACE nova.openstack.common.rpc.amqp\n\n\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n','<1721361270.10092.1348853082487.JavaMail.root@zm.isi.edu>',NULL),('<1121934736.23509163.1402960730783.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 19:18:50',-14400,'2014-06-16 23:18:50',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','\n\n----- Original Message -----\n> From: \"Gregory Haynes\" <greg at greghaynes.net>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, June 16, 2014 5:49:25 PM\n> Subject: Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora\n> \n> > > Id also like to propose that if we decide against doing this then these\n> > > elements should not live in tripleo-image-elements.\n> > \n> > I\'m not so sure I agree. We have lio and tgt because lio is on RHEL but\n> > everywhere else is still using tgt IIRC.\n> \n> Looks like we do have a cinder-tgt and a cinder-lio which we dont\n> actually use anywhere\n\nIsn\'t cinder-tgt used in devtest_overcloud?\n\n, so you are correct. The mariadb-galera /\n> percona-cluster elements are much more complex and active though, and\n> seem very likely to have issues with forgetting to or incorrectly\n> porting changes between them. It might also be a moot point if we end up\n> making it a default. :)\n> \n> > \n> > However, I also am not so sure that it is actually a good idea for people\n> > to ship on MariaDB since it is not in the gate. As it diverges from MySQL\n> > (starting in earnest with 10.x), there will undoubtedly be subtle issues\n> > that arise. So I\'d say having MariaDB get tested along with Fedora will\n> > actually improve those users\' test coverage, which is a good thing.\n> > \n> \n> --\n> Gregory Haynes\n> greg at greghaynes.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1402954273-sup-4582@greghaynes0>',NULL),('<1122013466.5.1376460886012.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-14 06:14:46',0,'2013-08-14 06:14:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #3','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/3/>\n\n\n\n','<699549040.1.1376288234095.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1122064657.340.1359094379343.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-25 06:12:59',0,'2013-01-25 06:12:59',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #116','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/116/>\n\n\n\n','<2027233830.318.1359007905655.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1122569524.3473894.1373642065355.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-12 11:14:25',-14400,'2013-07-12 15:14:25',NULL,'[openstack-dev] savanna version 0.3 - added UI mockups for EDP\n	workflow','I have added some initial UI mockups for version 0.3. \nAny comments are appreciated.\n\nhttps://wiki.openstack.org/wiki/Savanna/UIMockups/JobCreation\n\nThanks,\nChad\n\n\n','<1952686957.3445580.1373639486595.JavaMail.root@redhat.com>',NULL),('<1123470909.23004374.1406837372240.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-07-31 16:09:32',-14400,'2014-07-31 20:09:32',NULL,'[Openstack-docs] Streamlined contribution workflow','\nThanks for the response Anne,\n\n> > Which is fine, I just need to level-set the expectations here,\n> > since the ceilometer team is on the hook for a TC-mandated gap\n> > coverage task[2] and also has a bunch of other stuff on its\n> > plate.\n> >\n> \n> I\'d like to continue to enable the docs team to provide the additional\n> polish and editing. Is your concern the timeline? Or that the team\'s\n> efforts appears to be less than desired?\n\nActually it was more confusion on my part, due to the comments dating\nfrom yesterday on: \n\n  https://review.openstack.org/#/c/108741/7/doc/admin-guide-cloud/ch_telemetry.xml\n\nwhich referred to revisions, which I then assumed meant a *separate*\npatch, as the revised patchset wasn\'t pushed until today (I see now\nfrom the comments trail in gerrit that this was just a simple oversight).  \n \n> If your concern is the timeline, we can certainly push through what is\n> considered \"good enough\" by the project team. However we merged 20 patches\n> yesterday so I don\'t think that\'s what you\'re talking about.\n\nI\'m somewhat concerned with timelines, since we\'re on the hook to get\nthis done by juno-3 (plus a lot of other things).\n\nHowever I\'m mostly concerned with just clarifying and streamlining\nthe workflow, so that as to minimize the friction involved in\ngetting this over the line.\n\nPotential points of friction include:\n\n * our lack of clarity of the contribution model preferred by the\n   documentation team\n\n * our unfamiliarity with the documentation tool-chain\n \n> If your concern is that the writing is being rejected somewhat, let\'s talk\n> some more about that. For the most part the core-docs team have a really\n> good sense of the voice and style we aim to achieve.\n\nWell, I\'m perfectly happy for the \"house style\" to be applied,\nso no problem with that step in the workflow, now I understand it\ninvolves polishing the original patch and re-submitting that as\nopposed to a fresh proposal.\n\nIn fact the other approach of content being re-proposed as fresh\npatches could alternatively work well ... but my point was simply\nthat if extensive rewrites are applied as a matter of course then\nthere doesn\'t seem to a pressing need for the content submitted by\nthe project team to be *already* in the unfamiliar XML mark-up.\n\n> > If the workflow is based on rough content being provided by the\n> > project team, which is then polished up by the docco team, then I\n> > think we really need to streamline this process to avoid burning\n> > time unnecessarily getting to grips with the XML-based markup and\n> > maven-based build system.\n> >\n> > For example, would it make more sense for the raw content to be\n> > submitted initially in a simple lightweight form, such as free-\n> > form text or .rst or wiki markup?\n> >\n> \n> Really, what you describe is happening already. The lightweight docs tools\n> remain in the <project> repos. The heavyweight docs tools are the ones that\n> are integrated across projects. This separation is by design with the\n> following benefits in mind:\n> - docs team knows cross-project consistency\n> - translations are enabled for these deliverables\n> - docs team manages scope and priority for cross-project docs\n> - docs team understands operators, administrators, users deliverables\n\nOK, but in this case the project team has strayed into the domain\nof the \"heavyweight docs tools\" - should we have stayed out of that\ndomain and instead crafted the content in the first instance back in\nthe project repo and have it fed into docs from there?  \n \n> > That would allow the domain expertise of the project team to be\n> > leveraged, without imposing an unnecessary burden, while at the\n> > same time getting the most RoI for the time spent by the docco\n> > team revising the formatting according to their own particular\n> > domain expertise.\n> >\n> >\n> Believe me, I\'m working on getting the ROI calculation reversed a bit by\n> introducing new tools, but for now the system is working as designed. I\'d\n> be happy to hear more tweaks.\n\nUnderstood! :)\n\nI\'m sure the RoI from this tooling is already strong on the docs\nteam, I\'m more questioning the return from the learning curve of\nthe project-team to use this mark-up and toolchain for essentially\na once-off task.\n\nCheers,\nEoghan\n\n\n','<CAD0KtVG5=zQ1VroMLh=uP8UYQZgYnizW=XGSqU+ofYM6agyDAA@mail.gmail.com>',NULL),('<1124117396.9235617.1405023242019.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 16:14:02',-14400,'2014-07-10 20:14:02',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n\n> Thanks for dusting this off. Versioning and published schemas for\n> notifications are important to the StackTach team.  It would be nice to\n> get this resolved. We\'re happy to help out.\n\nGreat!\n\n> > A great outcome would include some or all of the following:\n> >\n> >  1. more complete in-tree test coverage of notification logic on the\n> >     producer side\n> \n> Ultimately this is the core problem. A breaking change in the\n> notifications caused tests to fail in other systems. Should we be adding\n> more tests or simply add version checking at the lower levels (like the\n> first pass of RPC versioning did)?\n\nYes, that would definitely help.\n \n> >  2. versioned notification payloads to protect consumers from breaking\n> >     changes in payload format\n> Yep, like RPC the biggies are:\n> 1. removal of fields from notifications\n> 2. change in semantics of a particular field\n> 3. addition of new fields (not a biggie)\n\nTrue, true and true.\n \n> The urgency for notifications is a little different than RPC where there\n> is a method on the other end expecting a certain format. Notifications\n> consumers have to be a little more forgiving when things don\'t come in\n> as expected.\n\nYes some tolerance can be expected, but whole point would be get away\nfrom the current free-fir-all.\n \n> This isn\'t a justification for breaking changes. Just stating that we\n> have some leeway.\n\nSure.\n \n> I guess it really comes down to systems that are using notifications for\n> critical synchronization vs. purely informational.\n\nAgreed. That\'s what I was getting at with the advisory versus actionable\ndistinction.\n\n> >  3. external discoverability of which event types a service is emitting\n> These questions can be saved for later, but ...\n> \n> Is the use-case that a downstream system can learn which queue to\n> subscribe to programmatically?\n> \n> Is this a nice-to-have?\n> \n> Would / should this belong in a metadata service?\n\nPossibly. The idea was to facilitate the drive towards discoverability\nfor testing purposes.\n\n> >  4. external discoverability of which event types a service is consuming\n> \n> Isn\'t this what the topic queues are for? Consumers should only\n> subscribe to the topics they\'re interested in.\n\nYeah, that one is questionable all right.\n\nAgain it relates back to the motivating discussion with QA  around \nbranchless Tempest. The idea was to make it externally discoverable\nwhich notifications that ceilometer was currently capable of and\nconfigured to consume.\n\nBut on reflection it would be far more meaningful to surface which \nmeters ceilo is currently capable of and configured to *produce*.\n\n> > If you\'re thinking that sounds like a substantial chunk of cross-project\n> > work & co-ordination, you\'d be right :)\n> \n> Perhaps notification schemas should be broken out into a separate\n> repo(s)? That way we can test independent of the publishing system. For\n> example, our notigen event simulator [5] could use it.\n>\n> These could just be dependent libraries/plugins to oslo.messaging.\n\nThat is an interesting idea, it would allow for the schemas to be\neasily depended upon on the consumer side also for validation purposes.\n\n> >  * acquiescence from non-integrated projects that currently consume\n> >    these notifications\n> >\n> >    (we shouldn\'t, as good citizens, simply pull the rug out from under\n> >    projects such as StackTach without discussion upfront)\n> We\'ll adapt StackTach.v2 accordingly. StackTach.v3 is far less impacted\n> by notification changes since they are offloaded and processed in a\n> secondary step. Breaking changes will just stall the processing. I\n> suspect .v3 will be in place before .v2 is affected.\n> \n> Adding version handling to Stack-Distiller (our notification->event\n> translator) should be pretty easy (and useful) [6]\n\nCool, sounds like this would not be disruptive to StackTach.\n \n> > Any opinions on how desirable or necessary this is, and how the\n> > detailed mechanics might work, would be welcome.\n> \n> A published set of schemas would be very useful for StackTach, we\'d love\n> to help out in any way possible. In the near-term we have to press on\n> under the assumption notification definitions are fragile.\n\nYes, the time horizon for this would be beyond the near-time.\n \n> > Apologies BTW if this has already been discussed and rejected as\n> > unworkable. I see a stalled versioned-notifications BP[2] and some\n> > references to the CADF versioning scheme in the LP fossil-record.\n> > Also an inconclusive ML thread from 2012[3], and a related grizzly\n> > summit design session[4], but it\'s unclear to me whether these\n> > aspirations got much traction in the end.\n> \n> I\'d really like to see the CADF work adopted vs. other, hand-rolled,\n> schema solutions.\n\nYes, I need to learn more about CADF, but the general principle of\navoiding bicycle-reinvention applies.\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A528F5E0@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1124331397.63.1386741859857.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:04:19',0,'2013-12-11 06:04:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-docs-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/8/>\n\n------------------------------------------\n[...truncated 103 lines...]\nGenerating doc/source/api/cinder.api.xmlutil.rst\nGenerating doc/source/api/cinder.backup.api.rst\nGenerating doc/source/api/cinder.backup.manager.rst\nGenerating doc/source/api/cinder.backup.rpcapi.rst\nGenerating doc/source/api/cinder.backup.services.swift.rst\nGenerating doc/source/api/cinder.common.sqlalchemyutils.rst\nGenerating doc/source/api/cinder.compute.aggregate_states.rst\nGenerating doc/source/api/cinder.context.rst\nGenerating doc/source/api/cinder.db.api.rst\nGenerating doc/source/api/cinder.db.base.rst\nGenerating doc/source/api/cinder.db.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.api.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.001_cinder_init.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.002_quota_class.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.003_glance_metadata.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.004_volume_type_to_uuid.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.005_add_source_volume_column.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.006_snapshots_add_provider_location.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.007_add_volume_snapshot_fk.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.008_add_backup.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.009_add_snapshot_metadata_table.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.models.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.session.rst\nGenerating doc/source/api/cinder.exception.rst\nGenerating doc/source/api/cinder.flags.rst\nGenerating doc/source/api/cinder.image.glance.rst\nGenerating doc/source/api/cinder.image.image_utils.rst\nGenerating doc/source/api/cinder.manager.rst\nGenerating doc/source/api/cinder.openstack.common.context.rst\nGenerating doc/source/api/cinder.openstack.common.exception.rst\nGenerating doc/source/api/cinder.openstack.common.excutils.rst\nGenerating doc/source/api/cinder.openstack.common.fileutils.rst\nGenerating doc/source/api/cinder.openstack.common.gettextutils.rst\nGenerating doc/source/api/cinder.openstack.common.importutils.rst\nGenerating doc/source/api/cinder.openstack.common.jsonutils.rst\nGenerating doc/source/api/cinder.openstack.common.local.rst\nGenerating doc/source/api/cinder.openstack.common.lockutils.rst\nGenerating doc/source/api/cinder.openstack.common.log.rst\nGenerating doc/source/api/cinder.openstack.common.network_utils.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.api.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.policy.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.filters.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.wrapper.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.common.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker_redis.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.service.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.availability_zone_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.capabilities_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.extra_specs_ops.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.json_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.weight.rst\nGenerating doc/source/api/cinder.openstack.common.setup.rst\nGenerating doc/source/api/cinder.openstack.common.strutils.rst\nGenerating doc/source/api/cinder.openstack.common.timeutils.rst\nGenerating doc/source/api/cinder.openstack.common.uuidutils.rst\nGenerating doc/source/api/cinder.openstack.common.version.rst\nGenerating doc/source/api/cinder.policy.rst\nGenerating doc/source/api/cinder.quota.rst\nGenerating doc/source/api/cinder.scheduler.chance.rst\nGenerating doc/source/api/cinder.scheduler.driver.rst\nGenerating doc/source/api/cinder.scheduler.filter_scheduler.rst\nGenerating doc/source/api/cinder.scheduler.filters.capacity_filter.rst\nGenerating doc/source/api/cinder.scheduler.filters.retry_filter.rst\nGenerating doc/source/api/cinder.scheduler.host_manager.rst\nGenerating doc/source/api/cinder.scheduler.manager.rst\nGenerating doc/source/api/cinder.scheduler.rpcapi.rst\nGenerating doc/source/api/cinder.scheduler.scheduler_options.rst\nGenerating doc/source/api/cinder.scheduler.simple.rst\nGenerating doc/source/api/cinder.scheduler.weights.capacity.rst\nGenerating doc/source/api/cinder.service.rst\nGenerating doc/source/api/cinder.test.rst\nGenerating doc/source/api/cinder.tests.api.common.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_admin_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_backups.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_extended_snapshot_attributes.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_hosts.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_services.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_manage.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_host_attribute.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_image_metadata.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_tenant_attribute.rst\nGenerating doc/source/api/cinder.tests.api.extensions.foxinsocks.rst\nGenerating doc/source/api/cinder.tests.api.fakes.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_auth.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_faults.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_sizelimit.rst\nGenerating doc/source/api/cinder.tests.api.openstack.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_common.rst\nGenerating doc/source/api/cinder.tests.api.test_extensions.rst\nGenerating doc/source/api/cinder.tests.api.test_router.rst\nGenerating doc/source/api/cinder.tests.api.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_xmlutil.rst\nGenerating doc/source/api/cinder.tests.api.v1.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volume_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volumes.rst\nGenerating doc/source/api/cinder.tests.api.v2.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_volumes.rst\nGenerating doc/source/api/cinder.tests.backup.fake_service.rst\nGenerating doc/source/api/cinder.tests.backup.fake_swift_client.rst\nGenerating doc/source/api/cinder.tests.db.fakes.rst\nGenerating doc/source/api/cinder.tests.declare_flags.rst\nGenerating doc/source/api/cinder.tests.fake_driver.rst\nGenerating doc/source/api/cinder.tests.fake_flags.rst\nGenerating doc/source/api/cinder.tests.fake_utils.rst\nGenerating doc/source/api/cinder.tests.glance.stubs.rst\nGenerating doc/source/api/cinder.tests.image.fake.rst\nGenerating doc/source/api/cinder.tests.image.test_glance.rst\nGenerating doc/source/api/cinder.tests.integrated.api.client.rst\nGenerating doc/source/api/cinder.tests.integrated.integrated_helpers.rst\nGenerating doc/source/api/cinder.tests.integrated.test_extensions.rst\nGenerating doc/source/api/cinder.tests.integrated.test_login.rst\nGenerating doc/source/api/cinder.tests.integrated.test_volumes.rst\nGenerating doc/source/api/cinder.tests.integrated.test_xml.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_a.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_b.rst\nGenerating doc/source/api/cinder.tests.runtime_flags.rst\nGenerating doc/source/api/cinder.tests.scheduler.fakes.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_capacity_weigher.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_filter_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_filters.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_manager.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_rpcapi.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler_options.rst\nGenerating doc/source/api/cinder.tests.test_HpSanISCSIDriver.rst\nGenerating doc/source/api/cinder.tests.test_api.rst\nGenerating doc/source/api/cinder.tests.test_backup.rst\nGenerating doc/source/api/cinder.tests.test_backup_swift.rst\nGenerating doc/source/api/cinder.tests.test_context.rst\nGenerating doc/source/api/cinder.tests.test_coraid.rst\nGenerating doc/source/api/cinder.tests.test_drivers_compatibility.rst\nGenerating doc/source/api/cinder.tests.test_emc.rst\nGenerating doc/source/api/cinder.tests.test_exception.rst\nGenerating doc/source/api/cinder.tests.test_flags.rst\nGenerating doc/source/api/cinder.tests.test_glusterfs.rst\nGenerating doc/source/api/cinder.tests.test_hp3par.rst\nGenerating doc/source/api/cinder.tests.test_huawei.rst\nGenerating doc/source/api/cinder.tests.test_iscsi.rst\nGenerating doc/source/api/cinder.tests.test_migrations.rst\nGenerating doc/source/api/cinder.tests.test_misc.rst\nGenerating doc/source/api/cinder.tests.test_netapp.rst\nGenerating doc/source/api/cinder.tests.test_netapp_nfs.rst\nGenerating doc/source/api/cinder.tests.test_nexenta.rst\nGenerating doc/source/api/cinder.tests.test_nfs.rst\nGenerating doc/source/api/cinder.tests.test_policy.rst\nGenerating doc/source/api/cinder.tests.test_quota.rst\nGenerating doc/source/api/cinder.tests.test_rbd.rst\nGenerating doc/source/api/cinder.tests.test_scality.rst\nGenerating doc/source/api/cinder.tests.test_service.rst\nGenerating doc/source/api/cinder.tests.test_sheepdog.rst\nGenerating doc/source/api/cinder.tests.test_skip_examples.rst\nGenerating doc/source/api/cinder.tests.test_solidfire.rst\nGenerating doc/source/api/cinder.tests.test_storwize_svc.rst\nGenerating doc/source/api/cinder.tests.test_test.rst\nGenerating doc/source/api/cinder.tests.test_test_utils.rst\nGenerating doc/source/api/cinder.tests.test_utils.rst\nGenerating doc/source/api/cinder.tests.test_volume.rst\nGenerating doc/source/api/cinder.tests.test_volume_configuration.rst\nGenerating doc/source/api/cinder.tests.test_volume_glance_metadata.rst\nGenerating doc/source/api/cinder.tests.test_volume_rpcapi.rst\nGenerating doc/source/api/cinder.tests.test_volume_types.rst\nGenerating doc/source/api/cinder.tests.test_volume_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.test_volume_utils.rst\nGenerating doc/source/api/cinder.tests.test_windows.rst\nGenerating doc/source/api/cinder.tests.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.test_xenapi_sm.rst\nGenerating doc/source/api/cinder.tests.test_xiv.rst\nGenerating doc/source/api/cinder.tests.test_zadara.rst\nGenerating doc/source/api/cinder.tests.utils.rst\nGenerating doc/source/api/cinder.tests.windows.basetestcase.rst\nGenerating doc/source/api/cinder.tests.windows.db_fakes.rst\nGenerating doc/source/api/cinder.tests.windows.mockproxy.rst\nGenerating doc/source/api/cinder.tests.windows.windowsutils.rst\nGenerating doc/source/api/cinder.utils.rst\nGenerating doc/source/api/cinder.version.rst\nGenerating doc/source/api/cinder.volume.api.rst\nGenerating doc/source/api/cinder.volume.configuration.rst\nGenerating doc/source/api/cinder.volume.driver.rst\nGenerating doc/source/api/cinder.volume.drivers.coraid.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_common.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.glusterfs.rst\nGenerating doc/source/api/cinder.volume.drivers.huawei.huawei_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.lvm.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.api.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.jsonrpc.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.volume.rst\nGenerating doc/source/api/cinder.volume.drivers.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.rbd.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_common.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_fc.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp_lefthand.rst\nGenerating doc/source/api/cinder.volume.drivers.san.san.rst\nGenerating doc/source/api/cinder.volume.drivers.san.solaris.rst\nGenerating doc/source/api/cinder.volume.drivers.scality.rst\nGenerating doc/source/api/cinder.volume.drivers.sheepdog.rst\nGenerating doc/source/api/cinder.volume.drivers.solidfire.rst\nGenerating doc/source/api/cinder.volume.drivers.storwize_svc.rst\nGenerating doc/source/api/cinder.volume.drivers.windows.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.lib.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.sm.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.tools.rst\nGenerating doc/source/api/cinder.volume.drivers.xiv.rst\nGenerating doc/source/api/cinder.volume.drivers.zadara.rst\nGenerating doc/source/api/cinder.volume.iscsi.rst\nGenerating doc/source/api/cinder.volume.manager.rst\nGenerating doc/source/api/cinder.volume.rpcapi.rst\nGenerating doc/source/api/cinder.volume.utils.rst\nGenerating doc/source/api/cinder.volume.volume_types.rst\nGenerating doc/source/api/cinder.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise39\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise39/8\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1124441716.109.1364105077494.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-24 06:04:37',0,'2013-03-24 06:04:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #174','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/174/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson7200542667420794683.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.vbJU3dQTYK\n+ TMPDIR=/tmp/tmp.vbJU3dQTYK\n+ trap \'rm -rf /tmp/tmp.vbJU3dQTYK\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.12 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.37    RoleAPITests.test_get_default_role\n    0.28    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.691s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.vbJU3dQTYK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/174\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/174/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/174/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1775306685.94.1364018704315.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1124731786.240.1358662336583.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-20 06:12:16',0,'2013-01-20 06:12:16',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-folsom #111','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/111/>\n\n------------------------------------------\n[...truncated 918 lines...]\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.02\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.00\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: A test for LP bug #781410 -- glance should fail more gracefully\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/v1/test_misc.py\",> line 61, in test_api_response_when_image_deleted_from_filesystem\n    body=image_data)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1597, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1345, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1281, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 906, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.76 secs:\n    14.11    TestScrubber.test_delayed_delete\n    13.79    TestGlanceControl.test_reload\n    13.67    TestGlanceControl.test_respawn\n    13.55    TestGlanceControl.test_bouncing\n    12.63    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 919 tests in 476.265s\n\nFAILED (SKIP=103, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6rc1\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.11.0\nglance==jenkins-periodic-glance-python27-stable-folsom-111\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\njsonschema==0.8.0\nkombu==2.5.4\nlxml==3.1beta1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==1.1.0\nsimplejson==3.0.7\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.0sfG4huQ5z\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/111\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/111/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<11248837.320.1387876836439.JavaMail.yfried@yfried-mobl-rh>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-24 04:20:40',-18000,'2013-12-24 09:20:40',NULL,'[openstack-dev] [Tempest][qa] Adding tags to commit messages','\n\n----- Original Message -----\n> From: \"Masayuki Igawa\" <masayuki.igawa at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, December 24, 2013 10:42:39 AM\n> Subject: Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages\n> \n> Hi,\n> \n> On Tue, Dec 24, 2013 at 3:47 PM, Yair Fried <yfried at redhat.com>\n> wrote:\n> > Hi,\n> > Suggestion: Please consider tagging your Tempest commit messages\n> > the same way you do your mails in the mailing list\n> >\n> > Explanation: Since tempest is a single project testing multiple\n> > Openstack project we have a very diverse collection of patches as\n> > well as reviewers. Tagging our commit messages will allow us to\n> > classify patches and thus:\n> > 1. Allow reviewer to focus on patches related to their area of\n> > expertise\n> > 2. Track \"trends\" in patches - I think we all know that we lack in\n> > Neutron testing for example, but can we assess how many network\n> > related patches are for awaiting review\n> > 3. Future automation of flagging \"interesting\" patches\n> >\n> > You can usually tell all of this from reviewing the patch, but by\n> > then - you\'ve spent time on a patch you might not even be\n> > qualified to review.\n> > I suggest we tag our patches with, to start with, the components we\n> > are looking to test, and the type of test (sceanrio, api, ...) and\n> > that reviewers should -1 untagged patches.\n> >\n> > I think the tagging should be the 2nd line in the message:\n> >\n> > ======================================\n> > Example commit message\n> >\n> > [Neutron][Nova][Network][Scenario]\n> >\n> > Explanation of how this scenario tests both Neutron and Nova\n> > Network performance\n> >\n> > Chang-id XXXXXXXXXXXXXXXXXXX\n> > =======================================\n> >\n> > I would like this to start immediately but what do you guys think?\n> \n> +1\n> \n> And, how about do we the tagging about the services in the\n> subject(1st line)?\n> For example:\n>   Neutron:Example commit subject\n> \n> Because the dashboard of the gerrit shows the subject only now.\n> I think reviewers can find \"interesting\" patches easily if the\n> dashboard shows the tags.\n\nI just found out you could query search for messages like this:\nstatus:open message:[Neutron]\n\n> This is not so strong opinion because some scenario tests may have\n> several services tags.\n\nAnd you have a limited subject length that\'s already not enough (for me at least)\n\n> \n> --\n> Masayuki Igawa\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAMwH0Ni0V_0Ph1MEiZT-xLdZ3gx4vVD552tPfYUufy_CEUBgMA@mail.gmail.com>',NULL),('<112505AF-9979-4EBA-9AC6-2D087053E2F1@cern.ch>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-09 08:42:59',0,'2014-07-09 08:42:59',NULL,'[Openstack-operators] mitigating issues with kernel-level\n	connection tracking','Hi,\n\nWe recently had a case of the kernel dropping packets due to a full connection tracking table (\"kernel: nf_conntrack: table full, dropping packet.?).\n\nHow do people usually deal with this:\n\n- increase the buffer size (which is what I did for now)?\n- reduce tracking timeouts?\n- remove connection tracking altogether?\n\nThe settings we were using so far are the defaults that come with the OS.\n\nThanks!\n Arne\n\n--\nArne Wiebalck\nCERN IT\n\n\n\n',NULL,NULL),('<1125930170.21990961.1375457279641.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 11:27:59',-14400,'2013-08-02 15:27:59',NULL,'[openstack-dev] [Ceilometer] Alarming should be outside of\n Ceilometer as a separate package.','\n> On 08/01/2013 07:22 PM, Doug Hellmann wrote:\n> > \n> > \n> > \n> > On Thu, Aug 1, 2013 at 10:31 AM, Sandy Walsh <sandy.walsh at rackspace.com\n> > <mailto:sandy.walsh at rackspace.com>> wrote:\n> > \n> >     Hey y\'all,\n> > \n> >     I\'ve had a little thorn in my claw on this topic for a while and\n> >     thought\n> >     I\'d ask the larger group.\n> > \n> >     I applaud the efforts of the people working on the alarming additions\n> >     to\n> >     Ceilometer, but I\'ve got concerns that we\'re packaging things the\n> >     wrong way.\n> > \n> >     I fear we\'re making another Zenoss/Nagios with Ceilometer. It\'s trying\n> >     to do too much.\n> > \n> >     The current trend in the monitoring work (#monitoringlove) is to build\n> >     your own stack from a series of components. These components take in\n> >     inputs, process them and spit out outputs.\n> >     Collectors/Transformers/Publishers. This is the model CM is built on.\n> > \n> >     Making an all-singing-all-dancing monolithic monitoring package is the\n> >     old way of building these tools. People want to use best-of-breed\n> >     components for their monitoring stack. I\'d like to be able to use\n> >     reimann.io <http://reimann.io> for my stream manager, diamond for my\n> >     collector, logstash for\n> >     my parser, etc. Alarming should just be another consumer.\n> > \n> >     CM should do one thing well. Collect data from openstack, store and\n> >     process them, and make them available to other systems via the API or\n> >     publishers. That\'s all. It should understand these events better than\n> >     any other product out there. It should be able to produce meaningful\n> >     metrics/meters from these events.\n> > \n> >     Alarming should be yet another consumer of the data CM produces. Done\n> >     right, the If-This-Then-That nature of the alarming tool could be\n> >     re-used by the orchestration team or perhaps even scheduling.\n> >     Intertwining it with CM is making the whole thing too complex and rigid\n> >     (imho).\n> > \n> >     CM should be focused on extending our publishers and input plug-ins.\n> > \n> >     I\'d like to propose that alarming becomes its own project outside of\n> >     Ceilometer. Or, at the very least, its own package, external of the\n> >     Ceilometer code base. Perhaps it still lives under the CM moniker, but\n> >     packaging-wise, I think it should live as a separate code base.\n> > \n> > \n> > It is currently implemented as a pair of daemons (one to monitor the\n> > alarm state, another to send the notifications). Both daemons use a\n> > ceilometer client to talk to the REST API to consume the sample data or\n> > get the alarm details, as required. It looks like alarms are triggered\n> > by sending RPC cast message, and that those in turn trigger the webhook\n> > invocation. That seems pretty loosely coupled, as far as the runtime\n> > goes. Granted, it\'s still in the main ceilometer code tree, but that\n> > doesn\'t say anything about how the distros will package it.\n> > \n> > I\'ll admit I haven\'t been closely involved in the development of this\n> > feature, so maybe my quick review of the code missed something that is\n> > bringing on this sentiment?\n> \n> No, you hit the nail on the head. It\'s nothing with the implementation,\n> it\'s purely with the packaging and having it co-exist within ceilometer.\n> Since it has its own services, uses Oslo, the CM client and operates via\n> the public API, it should be able to live outside the main CM codebase.\n> My concern is that it has a different mandate than CM (or the CM mandate\n> is too broad).\n> \n> What really brought it on for me was doing code reviews for CM and\n> hitting all this alarm stuff and thinking \"this is mental context switch\n> from what CM does, it really doesn\'t belong here.\" (though I\'m happy to\n> help out with the reviews)\n> \n> -S\n\nHi Sandy,\n\nIn terms of distro packaging, the case that I\'m most familiar (Fedora & derivatives)\nalready splits out the ceilometer packaging in a fairly fine-grained manner (with\nseparate RPMs for the various services and agents). I\'d envisage a similar packaging\napproach will be followed for the alarming services, so for deployments for which\nalarming is not required, this functionality won\'t be foisted on anyone.\n\nNow we could think about splitting it out even further to aid the sort of composability\nyou desire, however this functionality is needed by Heat, so it makes sense for it to\nlive in one of the integrated projects (as opposed to a newly incubated split-off).\n\nIn terms of the context switching required for reviewing alarming patches, I don\'t\nsee that as a huge issue for two reasons:\n\n - larger projects such as nova already require immensely greater context switching\n   of it\'s team of core devs\n\n - core devs can and do concentrate their reviewing on some functional sub-domains,\n   i.e. everyone doesn\'t have to the entire spectrum of patches\n\nThat being said, the efforts of team members such as yourself who make an obvious\neffort to review a wide range of patches, is of course appreciated!\n\nCheers,\nEoghan\n \n> \n> > \n> > Doug\n> >  \n> > \n> > \n> >     Please, change my view. :)\n> > \n> >     -S\n> > \n> >     Side note: I might even argue that the statistical features of CM are\n> >     going a little too far. My only counter-argument is that statistics are\n> >     the only way to prevent us from sending large amounts of data over the\n> >     wire for post-processing. But that\'s a separate discussion.\n> > \n> > \n> >     _______________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51FB02C8.3010804@rackspace.com>',NULL),('<112636669.25677204.1393900148717.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 21:29:08',-18000,'2014-03-04 02:29:08',NULL,'[openstack-dev] [nova] Questions about guest NUMA and\n	memory	binding policies','----- Original Message -----\n> Hi, all\n> \n> I search the current blueprints and old mails in the mail list, but find\n> nothing about Guest NUMA and setting memory binding policies.\n> I just find a blueprint about vcpu topology and a blueprint about CPU\n> binding.\n> \n> https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topology\n> https://blueprints.launchpad.net/nova/+spec/numa-aware-cpu-binding\n> \n> Is there any plan for the guest NUMA and memory binding policies setting?\n> \n> Thanks,\n> Jeremy Liu\n\nHi Jeremy,\n\nAs you\'ve discovered there have been a few attempts at getting some work started in this area. Dan Berrange outlined some of the possibilities in this area in a previous mailing list post [1] though it\'s multi-faceted, there are a lot of different ways to break it down. If you dig into the details you will note that the support-libvirt-vcpu-topology blueprint in particular got a fair way along but there were some concerns noted in the code reviews and on the list [2] around the design.\n\nIt seems like this is an area that there is a decent amount of interest in and we should work on list to flesh out a design proposal, ideally this would be presented for further discussion at the Juno design summit. What are your particular needs/desires from a NUMA aware nova scheduler?\n\nThanks,\n\nSteve\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019715.html\n[2] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022940.html\n\n\n','<3353B972624C8B49AB43F74428B4701D5D0AEC72@SZXEMA512-MBX.china.huawei.com>',NULL),('<1126803990.3.1380348868804.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-28 06:14:28',0,'2013-09-28 06:14:28',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #22','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/22/>\n\n\n\n','<122492773.99.1380299166844.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<112720481.27289673.1402930580449.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 10:56:20',-14400,'2014-06-16 14:56:20',NULL,'[openstack-dev] [Horizon] [UX] Design for Alarming and	Alarm\n Management','\nApologies for the top-posting, but just wanted to call out some\npotential confusion that arose on the #os-ceilometer channel earlier\ntoday.\n\nTL;DR: the UI shouldn\'t assume a 1:1 mapping between alarms and\n       resources, since this mapping does not exist in general\n\nBackground: See ML post[1]\n\nDiscussion: See IRC log [2]\n            Ctrl+F: \"Let\'s see what the UI guys think about it\"\n\nCheers,\nEoghan\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037788.html\n[2] http://eavesdrop.openstack.org/irclogs/%23openstack-ceilometer/%23openstack-ceilometer.2014-06-16.log\n\n\n----- Original Message -----\n> Hi all,\n> \n> Thanks again for the great comments on the initial cut of wireframes. I?ve\n> updated them a fair amount based on feedback in this e-mail thread along\n> with the feedback written up here:\n> https://etherpad.openstack.org/p/alarm-management-page-design-discussion\n> \n> Here is a link to the new version:\n> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-06-05.pdf\n> \n> And a quick explanation of the updates that I made from the last version:\n> \n> 1) Removed severity.\n> \n> 2) Added Status column. I also added details around the fact that users can\n> enable/disable alerts.\n> \n> 3) Updated Alarm creation workflow to include choosing the project and user\n> (optionally for filtering the resource list), choosing resource, and\n> allowing for choose of amount of time to monitor for alarming.\n>      -Perhaps we could be even more sophisticated for how we let users filter\n>      down to find the right resources that they want to monitor for alarms?\n> \n> 4) As for notifying users?I?ve updated the ?Alarms? section to be ?Alarms\n> History?. The point here is to show any Alarms that have occurred to notify\n> the user. Other notification ideas could be to allow users to get notified\n> of alerts via e-mail (perhaps a user setting?). I?ve added a wireframe for\n> this update in User Settings. Then the Alarms Management section would just\n> be where the user creates, deletes, enables, and disables alarms. Do you\n> still think we don?t need the ?alarms? tab? Perhaps this just becomes\n> iteration 2 and is left out for now as you mention in your etherpad.\n> \n> 5) Question about combined alarms?currently I?ve designed it so that a user\n> could create multiple levels in the ?Alarm When?? section. They could\n> combine these with AND/ORs. Is this going far enough? Or do we actually need\n> to allow users to combine Alarms that might watch different resources?\n> \n> 6) I updated the Actions column to have the ?More? drop down which is\n> consistent with other tables in Horizon.\n> \n> 7) Added in a section in the ?Add Alarm? workflow for ?Actions after Alarm?.\n> I?m thinking we could have some sort of If State is X, do X type selections,\n> but I?m looking to understand more details about how the backend works for\n> this feature. Eoghan gave examples of logging and potentially scaling out\n> via Heat. Would simple drop downs support these events?\n> \n> 8) I can definitely add in a ?scheduling? feature with respect to Alarms. I\n> haven?t added it in yet, but I could see this being very useful in future\n> revisions of this feature.\n> \n> 9) Another though is that we could add in some padding for outlier data as\n> Eoghan mentioned. Perhaps a setting for ?This has happened 3 times over the\n> last minute, so now send an alarm.??\n> \n> A new round of feedback is of course welcome :)\n> \n> Best,\n> Liz\n> \n> On Jun 4, 2014, at 1:27 PM, Liz Blanchard <lsurette at redhat.com> wrote:\n> \n> > Thanks for the excellent feedback on these, guys! I?ll be working on making\n> > updates over the next week and will send a fresh link out when done.\n> > Anyone else with feedback, please feel free to fire away.\n> > \n> > Best,\n> > Liz\n> > On Jun 4, 2014, at 12:33 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> > \n> >> \n> >> Hi Liz,\n> >> \n> >> Two further thoughts occurred to me after hitting send on\n> >> my previous mail.\n> >> \n> >> First, is the concept of alarm dimensioning; see my RDO Ceilometer\n> >> getting started guide[1] for an explanation of that notion.\n> >> \n> >> \"A key associated concept is the notion of dimensioning which defines the\n> >> set of matching meters that feed into an alarm evaluation. Recall that\n> >> meters are per-resource-instance, so in the simplest case an alarm might\n> >> be defined over a particular meter applied to all resources visible to a\n> >> particular user. More useful however would the option to explicitly\n> >> select which specific resources we\'re interested in alarming on. On one\n> >> extreme we would have narrowly dimensioned alarms where this selection\n> >> would have only a single target (identified by resource ID). On the other\n> >> extreme, we\'d have widely dimensioned alarms where this selection\n> >> identifies many resources over which the statistic is aggregated, for\n> >> example all instances booted from a particular image or all instances\n> >> with matching user metadata (the latter is how Heat identifies\n> >> autoscaling groups).\"\n> >> \n> >> We\'d have to think about how that concept is captured in the\n> >> UX for alarm creation/update.\n> >> \n> >> Second, there are a couple of more advanced alarming features\n> >> that were added in Icehouse:\n> >> \n> >> 1. The ability to constrain alarms on time ranges, such that they\n> >>  would only fire say during 9-to-5 on a weekday. This would\n> >>  allow for example different autoscaling policies to be applied\n> >>  out-of-hours, when resource usage is likely to be cheaper and\n> >>  manual remediation less straight-forward.\n> >> \n> >> 2. The ability to exclude low-quality datapoints with anomolously\n> >>  low sample counts. This allows the leading edge of the trend of\n> >>  widely dimensioned alarms not to be skewed by eagerly-reporting\n> >>  outliers.\n> >> \n> >> Perhaps not in a first iteration, but at some point it may make sense\n> >> to expose these more advanced features in the UI.\n> >> \n> >> Cheers,\n> >> Eoghan\n> >> \n> >> [1] http://openstack.redhat.com/CeilometerQuickStart\n> >> \n> >> \n> >> \n> >> ----- Original Message -----\n> >>> \n> >>> Hi Liz,\n> >>> \n> >>> Looks great!\n> >>> \n> >>> Some thoughts on the wireframe doc:\n> >>> \n> >>> * The description of form:\n> >>> \n> >>>   \"If CPU Utilization exceeds 80%, send alarm.\"\n> >>> \n> >>> misses the time-window aspect of the alarm definition.\n> >>> \n> >>> Whereas the boilerplate default descriptions generated by\n> >>> ceilometer itself:\n> >>> \n> >>>   \"cpu_util > 70.0 during 3 x 600s\"\n> >>> \n> >>> captures this important info.\n> >>> \n> >>> * The metric names, e.g. \"CPU Utilization\", are not an exact\n> >>> match for the meter names used by ceilometer, e.g. \"cpu_util\".\n> >>> \n> >>> * Non-admin users can create alarms in ceilometer:\n> >>> \n> >>> \"This is where admins can come in and\n> >>>  define and edit any alarms they want\n> >>>  the environment to use.\"\n> >>> \n> >>> (though these alarms will only have visibility onto the stats\n> >>>  that would be accessible to the user on behalf of whom the\n> >>>  alarm is being evaluated)\n> >>> \n> >>> * There\'s no concept currently of alarm severity.\n> >>> \n> >>> * \"Should users be able to enable/dis-able alarms.\"\n> >>> \n> >>> Yes, the API allows for disabled (i.e. non-evaluated) alarms.\n> >>> \n> >>> * \"Should users be able to own/assign alarms?\"\n> >>> \n> >>> Only admin users can create an alarm on behalf of another\n> >>> user/tenant.\n> >>> \n> >>> * \"Should users be able to acknowledge, close alarms?\"\n> >>> \n> >>> No, we have no concept of ACKing an alarm.\n> >>> \n> >>> * \"Admins can also see a full list of all Alarms that have\n> >>>  taken place in the past.\"\n> >>> \n> >>> In ceilometer terminology, we refer to this as alarm history\n> >>> or alarm change events.\n> >>> \n> >>> * \"CPU Utilization exceeded 80%.\"\n> >>> \n> >>> Again good to capture the duration in that description of the\n> >>> event.\n> >>> \n> >>> * \"Within the Overview section, there should be a new tab that allows the\n> >>>  user to click and view all Alarms that have occurred in their\n> >>>  environment.\"\n> >>> \n> >>> Not sure really what \"environment\" means here. Non-admin tenants only\n> >>> have visibility to their own alarm, whereas admins have visibility to\n> >>> all alarms.\n> >>> \n> >>> * \"This list would keep the latest  alarms.\"\n> >>> \n> >>> Presumably this would be based on querying the alarm-history API,\n> >>> as opposed to an assumption that Horizon is consuming the actual\n> >>> alarm notifications?\n> >>> \n> >>> Cheers,\n> >>> Eoghan\n> >>> \n> >>> ----- Original Message -----\n> >>>> Hi All,\n> >>>> \n> >>>> I?ve recently put together a set of wireframes[1] around Alarm\n> >>>> Management\n> >>>> that would support the following blueprint:\n> >>>> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page\n> >>>> \n> >>>> If you have a chance it would be great to hear any feedback that folks\n> >>>> have\n> >>>> on this direction moving forward with Alarms.\n> >>>> \n> >>>> Best,\n> >>>> Liz\n> >>>> \n> >>>> [1]\n> >>>> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf\n> >>>> \n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>> \n> >>> \n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> > \n> \n>\n\n\n','<F7BBBA7B-4963-405B-B369-6E25A1E25C6B@redhat.com>',NULL),('<1127243565.14726113.1411502365081.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 15:59:25',-14400,'2014-09-23 19:59:25',NULL,'[openstack-dev] [release] client release deadline - Sept 18th','\nThe ceilometer team released python-ceilometerclient vesion 1.0.11 yesterday:\n\n  https://pypi.python.org/pypi/python-ceilometerclient/1.0.11\n\nCheers,\nEoghan\n\n> Keystone team has released 0.11.1 of python-keystoneclient. Due to some\n> delays getting things through the gate this took a few extra days.\n> \n> https://pypi.python.org/pypi/python-keystoneclient/0.11.1\n> \n> ?Morgan\n> \n> \n> ?\n> Morgan Fainberg\n> \n> \n> -----Original Message-----\n> From:?John Dickinson <me at not.mn>\n> Reply:?OpenStack Development Mailing List (not for usage questions)\n> <openstack-dev at lists.openstack.org>>\n> Date:?September 17, 2014 at 20:54:19\n> To:?OpenStack Development Mailing List (not for usage questions)\n> <openstack-dev at lists.openstack.org>>\n> Subject:? Re: [openstack-dev] [release] client release deadline - Sept 18th\n> \n> > I just release python-swiftclient 2.3.0\n> >  \n> > In addition to some smaller changes and bugfixes, the biggest changes are\n> > the support\n> > for Keystone v3 and a refactoring that allows for better testing and\n> > extensibility of\n> > the functionality exposed by the CLI.\n> >  \n> > https://pypi.python.org/pypi/python-swiftclient/2.3.0\n> >  \n> > --John\n> >  \n> >  \n> >  \n> > On Sep 17, 2014, at 8:14 AM, Matt Riedemann wrote:\n> >  \n> > >\n> > >\n> > > On 9/15/2014 12:57 PM, Matt Riedemann wrote:\n> > >>\n> > >>\n> > >> On 9/10/2014 11:08 AM, Kyle Mestery wrote:\n> > >>> On Wed, Sep 10, 2014 at 10:01 AM, Matt Riedemann\n> > >>> wrote:\n> > >>>>\n> > >>>>\n> > >>>> On 9/9/2014 4:19 PM, Sean Dague wrote:\n> > >>>>>\n> > >>>>> As we try to stabilize OpenStack Juno, many server projects need to\n> > >>>>> get\n> > >>>>> out final client releases that expose new features of their servers.\n> > >>>>> While this seems like not a big deal, each of these clients releases\n> > >>>>> ends up having possibly destabilizing impacts on the OpenStack whole\n> > >>>>> (as\n> > >>>>> the clients do double duty in cross communicating between services).\n> > >>>>>\n> > >>>>> As such in the release meeting today it was agreed clients should\n> > >>>>> have\n> > >>>>> their final release by Sept 18th. We\'ll start applying the dependency\n> > >>>>> freeze to oslo and clients shortly after that, all other requirements\n> > >>>>> should be frozen at this point unless there is a high priority bug\n> > >>>>> around them.\n> > >>>>>\n> > >>>>> -Sean\n> > >>>>>\n> > >>>>\n> > >>>> Thanks for bringing this up. We do our own packaging and need time\n> > >>>> for legal\n> > >>>> clearances and having the final client releases done in a reasonable\n> > >>>> time\n> > >>>> before rc1 is helpful. I\'ve been pinging a few projects to do a final\n> > >>>> client release relatively soon. python-neutronclient has a release\n> > >>>> this\n> > >>>> week and I think John was planning a python-cinderclient release this\n> > >>>> week\n> > >>>> also.\n> > >>>>\n> > >>> Just a slight correction: python-neutronclient will have a final\n> > >>> release once the L3 HA CLI changes land [1].\n> > >>>\n> > >>> Thanks,\n> > >>> Kyle\n> > >>>\n> > >>> [1] https://review.openstack.org/#/c/108378/\n> > >>>\n> > >>>> --\n> > >>>>\n> > >>>> Thanks,\n> > >>>>\n> > >>>> Matt Riedemann\n> > >>>>\n> > >>>>\n> > >>>>\n> > >>>> _______________________________________________\n> > >>>> OpenStack-dev mailing list\n> > >>>> OpenStack-dev at lists.openstack.org\n> > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>\n> > >>> _______________________________________________\n> > >>> OpenStack-dev mailing list\n> > >>> OpenStack-dev at lists.openstack.org\n> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>\n> > >>\n> > >> python-cinderclient 1.1.0 was released on Saturday:\n> > >>\n> > >> https://pypi.python.org/pypi/python-cinderclient/1.1.0\n> > >>\n> > >\n> > > python-novaclient 2.19.0 was released yesterday [1].\n> > >\n> > > List of changes:\n> > >\n> > > mriedem at ubuntu:~/git/python-novaclient$ git log 2.18.1..2.19.0 --oneline\n> > > --no-merges\n> > > cd56622 Stop using intersphinx\n> > > d96f13d delete python bytecode before every test run\n> > > 4bd0c38 quota delete tenant_id parameter should be required\n> > > 3d68063 Don\'t display duplicated security groups\n> > > 2a1c07e Updated from global requirements\n> > > 319b61a Fix test mistake with requests-mock\n> > > 392148c Use oslo.utils\n> > > e871bd2 Use Token fixtures from keystoneclient\n> > > aa30c13 Update requirements.txt to include keystoneclient\n> > > bcc009a Updated from global requirements\n> > > f0beb29 Updated from global requirements\n> > > cc4f3df Enhance network-list to allow --fields\n> > > fe95fe4 Adding Nova Client support for auto find host APIv2\n> > > b3da3eb Adding Nova Client support for auto find host APIv3\n> > > 3fa04e6 Add filtering by service to hosts list command\n> > > c204613 Quickstart (README) doc should refer to nova\n> > > 9758ffc Updated from global requirements\n> > > 53be1f4 Fix listing of flavor-list (V1_1) to display swap value\n> > > db6d678 Use adapter from keystoneclient\n> > > 3955440 Fix the return code of the command \"delete\"\n> > > c55383f Fix variable error for nova --service-type\n> > > caf9f79 Convert to requests-mock\n> > > 33058cb Enable several checks and do not check docs/source/conf.py\n> > > abae04a Updated from global requirements\n> > > 68f357d Enable check for E131\n> > > b6afd59 Add support for security-group-default-rules\n> > > ad9a14a Fix rxtx_factor name for creating a flavor\n> > > ff4af92 Allow selecting the network for doing the ssh with\n> > > 9ce03a9 fix host resource repr to use \'host\' attribute\n> > > 4d25867 Enable H233\n> > > 60d1283 Don\'t log sensitive auth data\n> > > d51b546 Enabled hacking checks H305 and H307\n> > > 8ec2a29 Edits on help strings\n> > > c59a0c8 Add support for new fields in network create\n> > > 67585ab Add \"version-list\" for listing REST API versions\n> > > 0ff4afc Description is mandatory parameter when creating Security Group\n> > > 6ee0b28 Filter endpoints by region whenever possible\n> > > 32d13a6 Add missing parameters for server rebuild\n> > > f10d8b6 Fixes typo in error message of do_network_create\n> > > 9f1ee12 Mention keystoneclient.Session use in docs\n> > > 58cdcab Fix booting from volume when using api v3\n> > > 52c5ad2 Sync apiclient from oslo-incubator\n> > > 2acfb9b Convert server tests to httpretty\n> > > 762bf69 Adding cornercases for set_metadata\n> > > 313a2f8 Add way to specify key-name from environ\n> > >\n> > > [1] https://pypi.python.org/pypi/python-novaclient/2.19.0\n> > >\n> > > --\n> > >\n> > > Thanks,\n> > >\n> > > Matt Riedemann\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >  \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >  \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<etPan.5421a87a.6b8b4567.4fe@nullptr.local>',NULL),('<1127294353.37584601.1403022652137.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-17 12:30:52',-14400,'2014-06-17 16:30:52',NULL,'[Openstack] _member_ role after keystone installation','----- Original Message -----\n> From: \"Adam Young\" <ayoung at redhat.com>\n> To: openstack at lists.openstack.org\n> \n> On 06/14/2014 05:59 PM, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Steve Gordon\" <sgordon at redhat.com>\n> >> To: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> >>\n> >> ----- Original Message -----\n> >>> From: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> >>> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >>>\n> >>> Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 03:22:51 PM:\n> >>>\n> >>>>> From: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> >>>>> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >>>>>\n> >>>>> Steve Gordon <sgordon at redhat.com> wrote on 06/14/2014 12:43:48 PM:\n> >>>>> ...\n> >>>>>> Yes, it\'s supposed to be created by the db creation/migration\n> >>>>>> scripts if it\'s not there (since Grizzly if I recall correctly).\n> >>>>> But there is also the role spelled \"Member\".  Why both?\n> >>>>>\n> >>>>> Thanks,\n> >>>>> Mike\n> >>>> When Keystone started creating a \"_member_\" role automatically in\n> >>>> Grizzly there was a lag period before other projects, particularly\n> >>>> Horizon which defaulted to \"Member\" at the time, started using the\n> >>>> new role. As a result the installation guide, and even most\n> >>>> automated deployment tools, which previously had to create the role\n> >>>> as part of installation still created a \"Member\" role because that\n> >>>> was what Horizon expected and there wasn\'t any obvious indication\n> >>>> (although there was a release note for keystone [1]) this was wrong\n> >>>> or no longer required. The Horizon default was eventually updated to\n> >>>> match in this commit to horizon (included in Icehouse and backported\n> >>>> to Havana):\n> >>>>\n> >>>> commit 0aacc44f324c3db049f912da1f84d93c1142cb37\n> >>>> Author: JiaHao Li <kaho_lai at hotmail.com>\n> >>>> Date:   Thu Dec 26 15:37:14 2013 +0800\n> >>>>\n> >>>>      Sync OPENSTACK_KEYSTONE_DEFAULT_ROLE with keystone\n> >>>>\n> >>>>      For now, keystone default role is _member_, while horizon set\n> >>>>      OPENSTACK_KEYSTONE_DEFAULT_ROLE to Member. It will really be user\n> >>>>      friendly to modify horizon default value to _member_ to sync with\n> >>>>      keystone\'s default setting.\n> >>>>\n> >>>>      Change-Id: I55d15e6cfb74e52e933c5a44efd6c27930415738\n> >>>>      Closes-Bug: #1264228\n> >>>>\n> >>>> The end result is many older environments still have both roles\n> >>>> unless action is taken to manually remove the \"Member\" one and\n> >>>> update the Horizon default to the new value, and I should note it\n> >>>> probably wouldn\'t even be that surprising if there are still some\n> >>>> deployment tools creating *new* environments and using a \"Member\"\n> >>>> role - setting horizon to match - in this fashion instead of the\n> >>>> \"_member_\" built-in.\n> >>>>\n> >>>> Thanks,\n> >>>>\n> >>>> Steve\n> >>>>\n> >>>> [1] https://wiki.openstack.org/wiki/ReleaseNotes/Grizzly#Upgrade_Notes_5\n> >>>>\n> >>> The current situation for users of DevStack is that both _member_ and\n> >>> Member are created, and through the Horizon UI users see both and are not\n> >>> sure why there are two nor which to use.\n> >>>\n> >>> :-(\n> >>> Mike\n> >> This would be an example of \"it probably wouldn\'t even be that surprising\n> >> if\n> >> there are still some deployment tools creating *new* environments and\n> >> using\n> >> a \"Member\"\" :). Looking at lib/keystone:\n> >>\n> >> 318     # The Member role is used by Horizon and Swift so we need to keep\n> >> it:\n> >> 319     MEMBER_ROLE=$(openstack role create \\\n> >> 320         Member \\\n> >> 321         | grep \" id \" | get_field 2)\n> >>\n> >> As I outlined above, this means you get two roles because the Keystone SQL\n> >> will always create \"_member_\". The comment mentions that Horizon and Swift\n> >> require this, as I outlined above this is no longer true for Horizon - not\n> >> sure about Swift.\n> >>\n> >> -Steve\n> > I looked into this and there doesn\'t appear to be any dependency on\n> > _member_  Vs Member in Swift itself, but rather devstack itself introduces\n> > such a dependency in the way it sets up and configures swift when it sets\n> > the value \"Member,admin\" for operator_roles. Will file a bug and hopefully\n> > a patch shortly.\n> \n> THe _member_ role can changed to Member:  there is a config value in\n> Keystone.conf for that.\n\nIf I understand correctly, that means that Member will be treated as _member_ is, and automatically added to the user/tenant association right? That would still require updates to DevStack/Tempest as they will continue to explicitly add the role to each user, getting a clash because it\'s already there (currently they don\'t get this because Keystone is automatically adding _member_ but they are using Member).\n\nThis same problem exists if you simply change DevStack to use _member_ of course so in either case, to eliminate the situation where it\'s creating two distinct member roles it appears that it\'s necessary to make some updates to at least DevStack and Tempest. I raised a bug here:\n\n    https://bugs.launchpad.net/tempest/+bug/1330132\n\nThanks,\n\nSteve\n\n\n','<539E5BFE.5030901@redhat.com>',NULL),('<1127467049.4.1387089068394.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:31:08',0,'2013-12-15 06:31:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-full-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-full-grizzly/8/>\n\n\n\n','<111806279.68.1386742479492.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1127874276.55.1387952868515.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-25 06:27:48',0,'2013-12-25 06:27:48',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-dsvm-neutron-pg-havana #11','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-pg-havana/11/>\n\n\n\n','<1314505490.51.1387607814696.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<112822971.78.1357884887457.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-11 06:14:47',0,'2013-01-11 06:14:47',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #3','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/3/>\n\n------------------------------------------\n[...truncated 14562 lines...]\n++ echo \'| id                     | 3c23877d-1230-48ce-96e5-b1c8f80b9098 |\'\n++ read data\n+ VM_UUID=3c23877d-1230-48ce-96e5-b1c8f80b9098\n+ die_if_not_set VM_UUID \'Failure launching ex-vol\'\n+ local exitcode=0\n+ set +o xtrace\n+ timeout 60 sh -c \'while ! nova show 3c23877d-1230-48ce-96e5-b1c8f80b9098 | grep status | grep -q ACTIVE; do sleep 1; done\'\n++ nova show 3c23877d-1230-48ce-96e5-b1c8f80b9098\n++ grep private\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| private network        | 10.1.0.4                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.4\n+ die_if_not_set IP \'Failure retrieving IP address\'\n+ local exitcode=0\n+ set +o xtrace\n+ ping_check private 10.1.0.4 90\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net =~ q- ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.4 90\n+ local from_net=private\n+ local ip=10.1.0.4\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.4; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.4; do sleep 1; done\'\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n64 bytes from 10.1.0.4: icmp_req=1 ttl=64 time=2.11 ms\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 2.114/2.114/2.114/0.000 ms\n++ openssl rand -hex 4\n+ VOL_NAME=myvol-223307ef\n++ get_field 2\n++ read data\n++ head -1\n++ grep myvol-223307ef\n++ cinder list\n+ [[ -n \'\' ]]\n+ cinder create --display_name myvol-223307ef --display_description \'test volume: myvol-223307ef\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                false                 |\n|      created_at     |      2013-01-11T06:13:46.919543      |\n| display_description |     test volume: myvol-223307ef      |\n|     display_name    |            myvol-223307ef            |\n|          id         | 28dd3283-0f9d-4a35-8342-99df3c470869 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ [[ 0 != 0 ]]\n++ date +%s\n+ start_time=1357884827\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-223307ef | grep available; do sleep 1; done\'\n| 28dd3283-0f9d-4a35-8342-99df3c470869 | available | myvol-223307ef |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357884829\n+ echo \'Completed cinder create in 2 seconds\'\nCompleted cinder create in 2 seconds\n++ cinder list\n++ grep myvol-223307ef\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 28dd3283-0f9d-4a35-8342-99df3c470869 | available | myvol-223307ef |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=28dd3283-0f9d-4a35-8342-99df3c470869\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for myvol-223307ef\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1357884830\n+ nova volume-attach 3c23877d-1230-48ce-96e5-b1c8f80b9098 28dd3283-0f9d-4a35-8342-99df3c470869 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| id       | 28dd3283-0f9d-4a35-8342-99df3c470869 |\n| serverId | 3c23877d-1230-48ce-96e5-b1c8f80b9098 |\n| volumeId | 28dd3283-0f9d-4a35-8342-99df3c470869 |\n+----------+--------------------------------------+\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-223307ef | grep in-use; do sleep 1; done\'\n| 28dd3283-0f9d-4a35-8342-99df3c470869 | in-use | myvol-223307ef |  1   |     None    |  false   | 3c23877d-1230-48ce-96e5-b1c8f80b9098 |\n++ date +%s\n+ end_time=1357884835\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep myvol-223307ef\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 28dd3283-0f9d-4a35-8342-99df3c470869 | in-use | myvol-223307ef |  1   |     None    |  false   | 3c23877d-1230-48ce-96e5-b1c8f80b9098 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=3c23877d-1230-48ce-96e5-b1c8f80b9098\n+ die_if_not_set VOL_ATTACH \'Failure retrieving myvol-223307ef status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 3c23877d-1230-48ce-96e5-b1c8f80b9098 != 3c23877d-1230-48ce-96e5-b1c8f80b9098 ]]\n++ date +%s\n+ start_time=1357884836\n+ nova volume-detach 3c23877d-1230-48ce-96e5-b1c8f80b9098 28dd3283-0f9d-4a35-8342-99df3c470869\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-223307ef | grep available; do sleep 1; done\'\n| 28dd3283-0f9d-4a35-8342-99df3c470869 | available | myvol-223307ef |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357884841\n+ echo \'Completed volume-detach in 5 seconds\'\nCompleted volume-detach in 5 seconds\n++ date +%s\n+ start_time=1357884841\n+ cinder delete 28dd3283-0f9d-4a35-8342-99df3c470869\n+ timeout 60 sh -c \'while cinder list | grep myvol-223307ef; do sleep 1; done\'\n| 28dd3283-0f9d-4a35-8342-99df3c470869 | deleting | myvol-223307ef |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357884845\n+ echo \'Completed cinder delete in 4 seconds\'\nCompleted cinder delete in 4 seconds\n+ nova delete 3c23877d-1230-48ce-96e5-b1c8f80b9098\n+ timeout 60 sh -c \'while nova list | grep -q 3c23877d-1230-48ce-96e5-b1c8f80b9098; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nStarting coverage data collection\nTraceback (most recent call last):\n  File \"tools/tempest_coverage.py\", line 23, in <module>\n    from tempest.common.rest_client import RestClient\nImportError: No module named tempest.common.rest_client\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/rabbitmq/rabbit at devstack-1357876897-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/rabbitmq/rabbit at devstack-1357876897.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/3/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<817723005.46.1357777679935.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1128297825.32.1381039890706.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-06 06:11:30',0,'2013-10-06 06:11:30',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-grizzly #31','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/31/>\n\n\n\n','<2092234184.16.1380610477674.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1128886312.1845425.1371460308729.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-17 05:11:48',-14400,'2013-06-17 09:11:48',NULL,'[openstack-qa] Priolity brainstorming my initial toughts','The setUpClass adding multiple new variables to the name space\nWhich does not seams harmful, and usually helpful,  because they\navoid code repetition. (The namespace can be cleaned up, or new class instance could be created)\n\nThe test_ methods supposed to work without the help of another test_ methods action,\nbut it does not prohibits the usage of setUpClasses.\n\nThey would have some usage even if they do not share resources.\n\nThe test_ method MUST not depend on each other, but they can depend on multiple\nsetUp and setUpClass called in the correct order.\n\nIf you just select an individual test, the ordering is:\nsetUpClass -- normally/usually super call first \nsetUp -- normally/usually super call first\ntest_\ntearDown -- normally/usually super call last\ntearDownClass -- normally/usually super call last\n\nA relatively simple fixture usage does not seams to be able to call,\n the first tearDownClass at the exact same order.\nEven simpler usage can have difficulties even with the setUpClass.\n\nIt can cause an issue, it may be OK.\n\nI do not feel this is the right time to add an additional layer to the model,\nThe existing one should be simplified and unified first.\ncli, scenario, api, whitebox, thirdparty, xml/json v1,v2,v3,.. handled in similar, \n less code repetitive way.\n\nSmallest possible hack is extending the caller  (even with MonkeyPatching)\nof the first setUp and tearDown caller, do do the setUpClass and tearDownClass call\nat the right time.\n\nThe issue is just only the regular users does not have the power to cause parallel issues\nin a bug free system. \nFor example the keystone tests almost all have full admin privileges.\nThe capabilities of all OpenStack admin type user are continuously improving.\n\nNot just the authentication special, the resources can have another relationship,\nat the moment none of them seams to be on issue for a proper tearDown, but once \nwe might need more complex logic, than calling several operations in reverse order.\n\nHow to handle the temporary not working test cases ?\n* Add GLOBAL or DEFAULT section to the config\n* Add a boolean option for class_based_resource sharing (selection between the old and new code path)\n* Add an attribute option which can be logical formula (python eval ??, library for formulas ?)\n  Add a skip decision into the attr decorator.\n  (If it could be move to the runner in the future would be fine, one issue with the above, \n   simple way, it takes effect just after the setUp.)  \n* Flag/attribute the test cases and test classes \n  (all attribute on the class should be implicitly \"added\" to the test_ mothod)\n* Add the basic testr config to the tempest repo\n\nNo devstack/devstack-gate changes required if we do not need to spit to multiple jobs:\n* The default configuration options should be the working ones\n* tox.ini is in the tempest repo, anyone can send testr PoC in a single review\n\nBTW:\nA simple addCleanUp does not always fully correct:\nOn the OK code path, it might try do delete something what is already deleted.\nIf the logic accepts, the already deleted resources are just deleted, \n we might not catch a bug.\nAs I remember, testr provides a tagged test responses.\nCan it make this type of issue at least visible ?\n\n\n----- Original Message -----\nFrom: \"Christopher Yeoh\" <cyeoh at au1.ibm.com>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nCc: afazekas at redhat.com, mtreinish at kortar.org\nSent: Sunday, June 16, 2013 9:15:05 AM\nSubject: Re: [openstack-qa] Priolity brainstorming my initial toughts\n\nOn Sat, 15 Jun 2013 01:07:25 -0400 (EDT)\nAttila Fazekas <afazekas at redhat.com> wrote:\n> \n> OptimisingTestSuite seams like the suite which needed to mange the\n>  resources over classes.\n> Can it be used together ?\n\nI believe OptimisingTestSuite is the long term way to go. But when\nusing OptimisingTestSuite setUpClass is no longer run. We only sort of\naccidentally get setUpClass support when using testr at the moment\nbecause of the way that test discovery works. testrepository does not\nsupport setUpClass. To use OptimisingTestSuite we will first need to\nconvert setupClass functionality to fixtures.\n\nChris\n-- \nyeohc at au1.ibm.com\n\n\n\n','<20130616164505.1b17c0ff@rockhopper>',NULL),('<112E0ACA17709D42B09A49D7C72481D82407C36F@CFWEX01.americas.cray.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2014-04-03 00:58:07',0,'2014-04-03 00:58:07',NULL,'[openstack-hpc] Atlanta Summit','Sounds like a good idea. Perhaps we could reserve one of the session rooms for an evening meetup or reserve an unconference slot.\n\nKitrick\n________________________________________\nFrom: McMillan, Scott A [scott.a.mcmillan at intel.com]\nSent: Wednesday, April 02, 2014 6:15 PM\nTo: Brian Schott\nCc: openstack-hpc at lists.openstack.org\nSubject: Re: [openstack-hpc] Atlanta Summit\n\nOn 4/2/14, 4:56 PM, \"Brian Schott\" <brian.schott at nimbisservices.com<mailto:brian.schott at nimbisservices.com>> wrote:\n> That would be a great idea.  Is it still possible to submit official ones?\n\nSince the program has been announced (http://openstacksummitmay2014atlanta.sched.org/), I assume not?\n\nBut if there is interest, we could organize a meetup around a particular booth or session?\n\nScott\n\n_______________________________________________\nOpenStack-HPC mailing list\nOpenStack-HPC at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n\n','<CF61F55E.1BF97%scott.a.mcmillan@intel.com>',NULL),('<112FBA03-439C-4C5C-829C-5A8A7F1BC667@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-07-24 16:28:33',7200,'2012-07-24 14:28:33',NULL,'[Openstack-docs] MooseFS for instances','Hi guys,\nI\'m testing right now MooseFS for the future data backend of our cloud.\n\nWhat about presenting next to GlusterFS a Moose deployment for securing the instances directory - the other advantage there would be is making NFS useless for migration - so the migration using block storage actually.\n\nHave you ever been able to test it for your cloud ?\n\nRazique\n\nNuage & Co - Razique Mahroua \nrazique.mahroua at gmail.com\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20120724/a8524e82/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20120724/a8524e82/attachment.jpg>\n\n',NULL,NULL),('<1130040139.6.1376460977523.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-14 06:16:17',0,'2013-08-14 06:16:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-grizzly #4','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/4/>\n\n------------------------------------------\n[...truncated 1166 lines...]\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_logging.TestLogging.test_logrotate\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_logging.py\",> line 95, in test_logrotate\n    response, content = httplib2.Http().request(path, \'GET\')\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 88.33 secs:\n    25.71    TestScrubber.test_scrubber_app\n    20.13    TestScrubber.test_delayed_delete\n    14.43    TestGlanceControl.test_reload\n    14.16    TestGlanceControl.test_respawn\n    13.90    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1101 tests in 556.506s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python27.stable.grizzly.4\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Xlk8djfOZp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/4/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise5/4\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1130371918.23592386.1407192891955.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-04 18:54:51',-14400,'2014-08-04 22:54:51',NULL,'[openstack-dev] [nova][libvirt][baremetal] Nova Baremetal\'s Usage\n of Components from Libvirt','Hello All,\n\nSo, I\'m working on https://review.openstack.org/#/c/111459/, and have encountered an issue.  It seems that the Nova Baremetal driver\nuses the ImageCacheManager from the Libvirt driver.  For various reasons (see the commit), the ImageCacheManager has been refactored to\nrequire a libvirt connection to function properly.  However, the Nova Baremetal driver cannot provide such a connection.  Bearing in mind that\nBaremetal is deprecated and slated to be replaced by Ironic, the question is such: what to do about the ImageCacheManager.\n\nOne option would be to make it so that the ImageCacheManager can function without a libvirt connection.  This might make sense if the Baremetal\ndriver were around to stay; there would be somewhat less duplication than a wholesale copying of the code.  However, in light of Baremetal\'s impending\nthis seems to me to be a poor choice since it would involve lots of duplicate functionality, would complicate the ImageCacheManager code, and would\nlater need to be manually removed once the Baremetal driver is removed.\n\nThe second option would be to make a copy of the old ImageCacheManager in the Baremetal directory, and have the Baremetal driver\nuse that.  This seems to me to be the better option, since it means that when the Baremetal driver is removed, the old ImageCacheManager\ncode goes with it, without someone having to manually remove it.\n\nWhat do you think?\n\nBest Regards,\nSolly Ross\n\n\n','<1898187882.23589673.1407192487531.JavaMail.zimbra@redhat.com>',NULL),('<1130544953.4.1381644650738.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-13 06:10:50',0,'2013-10-13 06:10:50',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python27-stable-grizzly #28','See <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/28/changes>\n\n\n\n','<879178606.44.1381385483158.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1130614062.78.1383546616413.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:30:16',0,'2013-11-04 06:30:16',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-tempest-devstack-vm-stable-grizzly #47','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/47/>\n\n\n\n','<1170176825.55.1383373810885.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1130722349.7168001.1390498778686.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 12:39:38',-18000,'2014-01-23 17:39:38',NULL,'[openstack-dev] [Horizon] web accessibility issues','Hi Joowoon and Douglas.\n\nThanks a lot for starting this conversation! I think this is important and\nwe\'d all be delighted to make Horizon be usable by even more people.\n\nWe were discussing the topic somewhat recently [1] in the context of dropping\nthe no-Javascript fallback mode. We couldn\'t really find one web accessibility\nstandard that is agreed upon either. In general, work to improve accessibility\nwould be very very welcome, and I believe the main thing we\'ve lacked so far\nare actionable items (AFAICT there\'s only one open bug about accessibility [3]\nat the moment?). Your lists should help with that!\n\nPeople here on the mailing list and on IRC (#openstack-horizon) would be\ndelighted to help you if you have any question while filing bugs/blueprints/\nfixing the problems you\'ve found. Make sure to let us know how we can assist.\n\nMany thanks for looking into this, and welcome!\n\nJulie\n\n[1] http://eavesdrop.openstack.org/meetings/horizon/2013/horizon.2013-11-19-22.01.log.html\n[2] https://bugs.launchpad.net/horizon/+bug/1018570\n\n\"Douglas Fish\" <drfish at us.ibm.com> wrote:\n> Hi Joowon, Stackers,\n> \n> Joowon, thanks for initiating this discussion.  Web accessibility is a\n> priority for my company as well.  I\'ve taken a quick look at Icehouse\n> horizon and share similar concerns.  later, I\'m going to go to your wiki\n> page and share my concerns and thoughts.\n> \n> I have experience with web accessibility, but I\'m still quite new to the\n> Horizon project.  Part of my long term interest in the project is to see\n> Horizon become accessible.  I look forward to being involved in\n> accessibility work.\n> \n> Below are my initial, unprocessed notes on accessibility issues I\'ve\n> informally observed.  I expect to turn these into bug reports or blueprints\n> and I get a better understanding of the project.\n> Several Tables:\n> - more button doesn\'t show focus\n> - more menu doesn\'t close when focus is elsewhere\n> - column headers don\'t have tabstops\n> - filter button traps keyboard\n> \n> Overview:\n> - calendar widget isn\'t reachable (in date range selection)\n> - calendar widget never closes once its opened via tabbing\n> \n> Modal Dialog:\n> - can tab outside of the \"modal\" dialog (observed on Domains, but I suspect\n> its a global issue)\n> - cancel button is not tabbable\n> \n> I don\'t see wai-aria tagging anywhere.  It\'s really needed on divs that are\n> used as widgets, like the more button pop-up - I assume but haven\'t\n> verified this will cause problems with screen readers.\n> \n> I _think_ horizon uses jqueryUI widgets which aren\'t accessible.  This guy\n> has forked a set of accessible jQueryUI widgets, but I\'m not sure that\n> helps us any:\n> http://hanshillen.github.io/jqtest/#goto_dialog\n> \n> It does look like bootstrap is committed to accessibility.  Maybe this will\n> be a path to getting accessible widgets?\n> \n> Doug Fish\n> IBM STG Cloud Solution Development\n> T/L 553-6879, External Phone 507-253-6879\n> \n> \n> \n> \n> From:	Joonwon Lee <joonwon7.lee at samsung.com>\n> To:	openstack-dev at lists.openstack.org,\n> Date:	01/23/2014 01:39 AM\n> Subject:	[openstack-dev]  [Horizon] web accessibility issues\n> \n> \n> \n> Dear stackers,\n> We inspected the Horizon (Havana release) for web accessibility and\n> found the following problems, as it\'s required by our domestic standards.\n> \n> 1.1.1 Non-text Contents\n> - A few non-text contents such as Network Topology (for Neutron) and\n>   Resource Usage (for Ceilometer) have no text alternatives.\n> \n> 1.3.1 Info and Relationships\n> - There is no caption element, summary attribute in tables such as\n>   instances, volumes, images, so on.\n> - There is no scope attribute in th elements.\n> \n> 1.4.3 Contrast (Minimum)\n> - text color and background color in the left menu\n> - text color and background color in the top menu\n> - link color and background color in the main content area\n> - text color and background color of the some buttons\n> \n> 2.1.1 Keyboard\n> - It\'s not easy to handle the layered message window by keyboard only.\n> - It may be difficult for a blind person to notice this layered error\n>   message.\n> \n> 2.4.1 Bypass Blocks\n> - There is no mechanism to skip repeated contents such as menu.\n>   For example, we can add a link at the top of each page that goes\n>   directly to the main content area.\n> \n> 2.4.3 Focus Order\n> - The order of navigation doesn\'t match the visual order in some cases.\n> - The focus movement is not restricted to the layered pop-up window.\n> \n> 3.1.1 Language of Page\n> - There is no lang attribute on the html element.\n> \n> 3.3.2 Labels or Instructions\n> - Is it better to use label element to associate text labels with\n>   input elements?\n> \n> The above items are in the WCAG 2.0 W3C Recommendation:\n> http://www.w3.org/TR/WCAG20/ (Web Content Accessibility Guidelines 2.0)\n> \n> I\'d like to discuss in public how to solve these issues in the Horizon\n> with the people who have the similar interests. However, I\'m not an expert\n> on this issues at all. Please correct me if I\'m wrong at any points.\n> \n> I also created the wiki page. Feel free to edit it.\n> https://wiki.openstack.org/wiki/Horizon/WebAccessibility\n> \n> Looking forward to seeing the reply from who wants to use the Horizon\n> in the public cloud service. Thanks for your consideration.\n> \n> Regards,\n> Joonwon Lee, Samsung SDS\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OFC9D210DF.56CA9530-ON85257C69.005BBB82-86257C69.005CB3B5@us.ibm.com>',NULL),('<1130846842.830880.1345050556119.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 10:09:16',-25200,'2012-08-15 17:09:16',NULL,'[openstack-dev] [Openstack] Discussion about where to put\n database for bare-metal provisioning (review 10726)','\n\n----- Original Message -----\n> Hi David,\n> \n> On Wed, 2012-08-15 at 08:28 -0700, David Kang wrote:\n> >\n> >  Hi,\n> >\n> >  This is call for discussion about the code review 10726.\n> > https://review.openstack.org/#/c/10726/\n> > Mark asked why we implemented a separata database for bare-metal\n> > provisioning.\n> > Here we describe our thought.\n> > We are open to discussion and to the changes that the community\n> > recommends.\n> > Please give us your thoughts.\n> >\n> >  NTT Docomo and USC/ISI have developed bare-metal provisioning.\n> > We created separate database to describe bare-metal nodes, which\n> > consists of 5 tables now.\n> > Our initial implementation assumes the database is not a part of\n> > nova database.\n> > In addition to the reasons described in the comments of the code\n> > review,\n> > here is another reason we decided a separate database for baremetal\n> > provisioning.\n> >\n> > Bare-metal database is mainly used by bare-metal nova-compute.\n> > Since bare-metal nova-compute manages multiple bare-metal machines,\n> > it needs to keep/update the information of bare-metal machines.\n> > If the bare-metal database is in the main nova db, accessing nova db\n> > remotely by\n> > bare-metal nova-compute is inevitable.\n> > Once Vish told us that shared db access from nova-compute is not\n> > desirable.\n> >\n> > It is possible to make the scheduler do the job of bare-metal\n> > nova-compute.\n> > However, it would need a big changes in how the scheduler and a\n> > nova-compute\n> > communicates. For example, currently, the scheduler casts an\n> > instance to a\n> > nova-compute. But for bare-metal node, the scheduler should cast an\n> > instance\n> > to a bare-metal machine through bare-metal nova-compute.\n> > Bare-metal nova-compute should boot the machine, transfer kernel,\n> > fs, etc.\n> > So, bare-metal nova-compute should know the id of bare-metal node\n> > and other information\n> > for booting (PXE ip address, ...) and more.\n> > That information should be sent to bare-metal nova-compute by the\n> > scheduler.\n> >\n> > If frequent access of bare-metal tables in nova db from bare-metal\n> > nova-compute\n> > is OK, we are OK to put the bare-metal tables into nova db.\n> >\n> >  Please let us know your opinions.\n> \n> I just posted a comment in gerrit before seeing your mail.\n> \n> The big question for me is whether the baremetal DB needs to be shared\n> between compute nodes.\n> \n> Right now, it looks like the DB is designed to be shared (e.g. the\n> service_host column in the BareMetalNode) but could we re-work things\n> so\n> that it\'s not shared?\n> \n> The big issue with a shared DB is the problems it causes for upgrades\n> which we\'ve been trying to fix with no-db-compute.\n> \n> Cheers,\n> Mark.\n\n Currently, a single bare-metal DB is shared my many bare-metal nova-compute.\nIt is OK for us to make it not shared.\nData-wise, it doesn\'t need to be shared among many nova-computes.\nOne good thing about having one shared DB is its convenience of backing up and\nimplementing fault-tolerance.\nBut, we are OK to make it not shared.\n\n Thanks,\n David\n\n\n','<1345046082.4956.360.camel@sorcha>',NULL),('<1130997259.22.1385275410182.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-24 06:43:30',0,'2013-11-24 06:43:30',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-stable-havana #3','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-stable-havana/3/changes>\n\n\n\n','<472838330.11.1385017358856.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1132113361.6503529.1353608004994.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 13:13:24',-18000,'2012-11-22 18:13:24',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n> Apparently there was some consensus in the thread around making the\n> nova.virt.driver interface and its implementations public and having\n> ceilometer consume that. I\'m not really seeing that consensus reading\n> back.\n\nMy read was that the consensus cohered in the follow-up discussion\nduring the nova IRC meeting[1].\n\n> Honestly, after looking at what parts of Nova code Ceilometer\n> currently uses, that approach looks like an awfully big\n> hammer. \n\nK, let\'s think about a less weighty hammer.\n\n> AFAICT, Ceilometer currently does some pretty simple and\n> generic querying of libvirt for CPU, disk and NIC information.\n\nYes, exactly. But we want to be able to do it in the non-libvirt\ncases too. And all without copying in a rake of nova code.\n\n> Even if we stick with this approach of having an agent that talks to\n> libvirt, is it really such a huge deal to have code in both Nova and\n> Ceilometer that does this?\n\nWell the way ceilo does it now (just picking up the whatever version\nof the nova is available) is turning out to be a real headache keeping\nup with internal mods to nova - the ceilo trunk regularly breaks\nbecause some change in nova-land has an unforeseen impact on ceilo\n(which is understandable, seeing as this code was never intended to\nexternally consumable).\n\nSo to address that instability, are you suggesting we take a big ol\'\ncopy of some version (say 2012.2) of the nova virt code, prune it down\nto the bits we need, then dump that into the ceilo repo?\n\nIs the virt code sufficiently isolated within nova to do that?\ne.g. say some bit of the nova utils or config code changes, wouldn\'t\nthat potentially have a knock-on impact?\n\nIs it OK that adding a new driver type in nova would require ceilo\nto notice and pick this up & distill out the bits needed?\n\n> Put it another way, if you made a standalone generic library for\n> doing just this piece, Nova probably wouldn\'t bother using it since\n> so little code is involved.\n\nOK, there seemed to be a willingness for nova use it expressed in\nthat IRC discussion, but yeah I take your point that it\'s a relatively\nsmall piece.\n\n> I think I\'ve the same instinct as Brian on this - it doesn\'t seem\n> unreasonable for Nova to publish CPU/disk/NIC samples at the same\n> interval as other notifications.\n\nSo IIUC the other notifications produced by nova are not really on\na fine-grained periodic basis, being either triggered by lifecycle\nevents (e.g. an instance is updated in some way) or else are very\ninfrequent (e.g. the instance audit logic runs at most hourly). \n\nBut in any case, one concern with nova-compute emitting these data\nas either notifications or else making direct calls into a ceilo-\nprovided library was that such a loaded service is likely to\nrun into timeliness issues.\n\n> What might be confusing this whole discussion is the discussion\n> around metering and instrumentation requirements. I think we should\n> keep the two concerns completely separate for now and plough ahead\n> with what we think makes sense for metering.\n\nThere\'s been a fair amount of fuzziness around the distinction\nbetween instrumentation and monitoring, but this falls into the\nlatter camp for me. Its not so much about the internal dynamics\nof nova, as the user-visible behavior (e.g. is my instance running\nhot or am I pushing loads of data through the network, as opposed\nhow long did that API call to update the instance take to service\nend-to-end or how many connections are in that pool).\n\nCheers,\nEoghan\n\n[1] http://eavesdrop.openstack.org/meetings/nova/2012/nova.2012-11-15-21.04.log.html\n#topic ceilometer/nova interaction as discussed on the ML\n\n\n','<1353603954.14377.10.camel@sorcha>',NULL),('<1132531897.51.1386223502554.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-05 06:05:02',0,'2013-12-05 06:05:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-grizzly #3','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-neutron-grizzly/3/>\n\n------------------------------------------\n[...truncated 7116 lines...]\n2013-12-05 06:04:45 + local file=/etc/cinder/cinder.conf\n2013-12-05 06:04:45 + local section=DEFAULT\n2013-12-05 06:04:45 + local option=secure_delete\n2013-12-05 06:04:45 + local line\n2013-12-05 06:04:45 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-05 06:04:45 + line=\n2013-12-05 06:04:45 + \'[\' -n \'\' \']\'\n2013-12-05 06:04:45 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-05 06:04:45 secure_delete = False\n2013-12-05 06:04:45 \' /etc/cinder/cinder.conf\n2013-12-05 06:04:45 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-12-05 06:04:45 + local file=/etc/cinder/cinder.conf\n2013-12-05 06:04:45 + local section=DEFAULT\n2013-12-05 06:04:45 + local option=volume_clear\n2013-12-05 06:04:45 + local value=none\n2013-12-05 06:04:45 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-12-05 06:04:45 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-12-05 06:04:45 + local file=/etc/cinder/cinder.conf\n2013-12-05 06:04:45 + local section=DEFAULT\n2013-12-05 06:04:45 + local option=volume_clear\n2013-12-05 06:04:45 + local line\n2013-12-05 06:04:45 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-05 06:04:45 + line=\n2013-12-05 06:04:45 + \'[\' -n \'\' \']\'\n2013-12-05 06:04:45 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-05 06:04:45 volume_clear = none\n2013-12-05 06:04:45 \' /etc/cinder/cinder.conf\n2013-12-05 06:04:45 + \'[\' False == True \']\'\n2013-12-05 06:04:45 + \'[\' default == XenAPINFS \']\'\n2013-12-05 06:04:45 + \'[\' default == sheepdog \']\'\n2013-12-05 06:04:45 + is_service_enabled quantum\n2013-12-05 06:04:45 + services=quantum\n2013-12-05 06:04:45 + for service in \'${services}\'\n2013-12-05 06:04:45 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-12-05 06:04:45 + return 0\n2013-12-05 06:04:45 + install_quantum\n2013-12-05 06:04:45 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-12-05 06:04:45 + [[ False = \\T\\r\\u\\e ]]\n2013-12-05 06:04:45 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-12-05 06:04:45 + GIT_DEST=/opt/stack/new/neutron\n2013-12-05 06:04:45 + GIT_REF=stable/grizzly\n2013-12-05 06:04:45 + echo stable/grizzly\n2013-12-05 06:04:45 + egrep -q \'^refs\'\n2013-12-05 06:04:45 + [[ ! -d /opt/stack/new/neutron ]]\n2013-12-05 06:04:45 + [[ \'\' == \\y\\e\\s ]]\n2013-12-05 06:04:45 + setup_develop /opt/stack/new/neutron\n2013-12-05 06:04:45 + [[ False = True ]]\n2013-12-05 06:04:45 + SUDO_CMD=sudo\n2013-12-05 06:04:45 + cd /opt/stack/new/neutron\n2013-12-05 06:04:45 + python setup.py egg_info\n2013-12-05 06:04:45 running egg_info\n2013-12-05 06:04:45 creating quantum.egg-info\n2013-12-05 06:04:45 writing requirements to quantum.egg-info/requires.txt\n2013-12-05 06:04:45 writing quantum.egg-info/PKG-INFO\n2013-12-05 06:04:45 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-05 06:04:45 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-05 06:04:45 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-05 06:04:45 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-05 06:04:45 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-05 06:04:45 reading manifest template \'MANIFEST.in\'\n2013-12-05 06:04:45 warning: no files found matching \'AUTHORS\'\n2013-12-05 06:04:45 warning: no files found matching \'ChangeLog\'\n2013-12-05 06:04:45 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-05 06:04:45 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-05 06:04:45 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-05 06:04:45 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-05 06:04:45 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-12-05 06:04:45 + raw_links=\n2013-12-05 06:04:45 ++ echo\n2013-12-05 06:04:45 ++ xargs\n2013-12-05 06:04:45 + depend_links=\n2013-12-05 06:04:45 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-12-05 06:04:45 ++ echo \'-r *-info/requires.txt\'\n2013-12-05 06:04:45 + require_file=\'-r *-info/requires.txt\'\n2013-12-05 06:04:45 + pip_install -r quantum.egg-info/requires.txt\n2013-12-05 06:04:45 + [[ False = \\T\\r\\u\\e ]]\n2013-12-05 06:04:45 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-12-05 06:04:45 + [[ -z deb ]]\n2013-12-05 06:04:45 + [[ False = True ]]\n2013-12-05 06:04:45 + SUDO_PIP=sudo\n2013-12-05 06:04:45 ++ get_pip_command\n2013-12-05 06:04:45 ++ is_fedora\n2013-12-05 06:04:45 ++ [[ -z Ubuntu ]]\n2013-12-05 06:04:45 ++ \'[\' Ubuntu = Fedora \']\'\n2013-12-05 06:04:46 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-12-05 06:04:46 ++ \'[\' Ubuntu = CentOS \']\'\n2013-12-05 06:04:46 ++ which pip\n2013-12-05 06:04:46 + CMD_PIP=/usr/local/bin/pip\n2013-12-05 06:04:46 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-12-05 06:04:46 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-12-05 06:04:46 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:46   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-12-05 06:04:46   Running setup.py egg_info for package python-quantumclient\n2013-12-05 06:04:46     [pbr] Processing SOURCES.txt\n2013-12-05 06:04:46     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-12-05 06:04:46     \n2013-12-05 06:04:46     [pbr] In git context, generating filelist from git\n2013-12-05 06:04:46     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:46 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-12-05 06:04:46   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.1.tar.gz\n2013-12-05 06:04:46   Running setup.py egg_info for package alembic\n2013-12-05 06:04:46     \n2013-12-05 06:04:46     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-05 06:04:46     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-05 06:04:46     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-05 06:04:46     no previously-included directories found matching \'docs/build/output\'\n2013-12-05 06:04:46 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:48 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-05 06:04:48   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-12-05 06:04:48   Running setup.py egg_info for package Mako\n2013-12-05 06:04:48     \n2013-12-05 06:04:48     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-05 06:04:48     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-05 06:04:48     warning: no files found matching \'ez_setup.py\'\n2013-12-05 06:04:48     no previously-included directories found matching \'doc/build/output\'\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-novaclient->-r quantum.egg-info/requires.txt (line 19))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-05 06:04:48 Installing collected packages: python-quantumclient, alembic, Mako\n2013-12-05 06:04:48   Running setup.py install for python-quantumclient\n2013-12-05 06:04:48     [pbr] Reusing existing SOURCES.txt\n2013-12-05 06:04:48     Installing quantum script to /usr/local/bin\n2013-12-05 06:04:48   Running setup.py install for alembic\n2013-12-05 06:04:48     \n2013-12-05 06:04:48     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-05 06:04:48     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-05 06:04:48     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-05 06:04:48     no previously-included directories found matching \'docs/build/output\'\n2013-12-05 06:04:48     Installing alembic script to /usr/local/bin\n2013-12-05 06:04:48   Running setup.py install for Mako\n2013-12-05 06:04:48     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-12-05 06:04:48     \n2013-12-05 06:04:48     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-05 06:04:48     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-05 06:04:48     warning: no files found matching \'ez_setup.py\'\n2013-12-05 06:04:48     no previously-included directories found matching \'doc/build/output\'\n2013-12-05 06:04:48     changing mode of /usr/local/bin/mako-render to 755\n2013-12-05 06:04:48 Successfully installed python-quantumclient alembic Mako\n2013-12-05 06:04:48 Cleaning up...\n2013-12-05 06:04:48 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-12-05 06:04:48 running develop\n2013-12-05 06:04:48 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-12-05 06:04:48 /usr/bin/python -E -c pass\n2013-12-05 06:04:48 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-12-05 06:04:48 running egg_info\n2013-12-05 06:04:48 writing requirements to quantum.egg-info/requires.txt\n2013-12-05 06:04:48 writing quantum.egg-info/PKG-INFO\n2013-12-05 06:04:48 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-05 06:04:48 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-05 06:04:48 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-05 06:04:48 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-05 06:04:48 reading manifest template \'MANIFEST.in\'\n2013-12-05 06:04:48 warning: no files found matching \'AUTHORS\'\n2013-12-05 06:04:48 warning: no files found matching \'ChangeLog\'\n2013-12-05 06:04:48 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-05 06:04:48 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-05 06:04:48 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-05 06:04:48 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-05 06:04:48 running build_ext\n2013-12-05 06:04:48 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-12-05 06:04:48 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-12-05 06:04:48 Installing quantum-debug script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-nec-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-ryu-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-l3-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-db-manage script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-metadata-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-server script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-12-05 06:04:48 Installing quantum-rootwrap script to /usr/local/bin\n2013-12-05 06:04:48 \n2013-12-05 06:04:48 Installed /opt/stack/new/neutron\n2013-12-05 06:04:48 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-12-05 06:04:48 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-12-05 06:04:48 ++ failed\n2013-12-05 06:04:48 ++ local r=1\n2013-12-05 06:04:48 +++ jobs -p\n2013-12-05 06:04:48 ++ kill\n2013-12-05 06:04:48 ++ set +o xtrace\n2013-12-05 06:04:48 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-12-05-060155\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-793932-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-793932.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-793932/3/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2136553434.50.1386137141006.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1132689a.00000c80.00000121@VMWARE-CE94FEA7.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-16 19:36:55',-25200,'2013-05-17 02:36:55',NULL,'[openstack-dev] VPNaaS','+ one more comment for 3. Local_cidrs\nIf there are there subnets got from \"subnet_id\" and user only wish to\nprovide VPN tunnel access to two of them from remote, we need to keep\nlocal_cidrs.\n\nThanks\nQin\n\n-----Original Message-----\nFrom: Qin Li [mailto:qili at vmware.com]\nSent: 2013?5?17? 9:55\nTo: OpenStack Development Mailing List\nSubject: RE: [openstack-dev] VPNaaS\n\nFor design on https://wiki.openstack.org/wiki/Quantum/VPNaaS , I\'d like to\nshare some of my comments.\n\n1. Table IKEPolicy\na. encryption_algorithm,  please include more information about algorithm\nsuch as cipher mode. The value could be 3des-192-cbc, aes-128-cbc,\naes-192-cbc, aes-256-cbc, aes-128-gcm-a, aes-256-gcm-a, aes-128-ccm etc.\nSo as to support more kinds of cipher modes.\nb. phase1_negotiation_mode, suggest to rename it as phrase1_mode or mode,\nphrase 1 already contains the meaning \"negotiation\".\nc. pfs, since there is no pfs_enable flag, null value of pfs means\ndisabled.  What does it mean if user does not specify it in inputs?\nd. A minor adjustment suggestion for encryption_algorithm and\nauth_algorithm, we could combine them into a phrase1 algorithm list named\nphrase1_algs including like 3des-192-cbc-sha1, aes-128-cbc-sha1 etc. So as\nto support multiple algorithm proposals in one IKE negotiation. This could\nbe considered in next release.\n\n2. Table IPSecPolicy\na. encryption_algorithm, the same as IKEPolicy b. transform_protocol,\nencapsulation_mode.  Suggest to remove them to make object and\nconfiguration simpler. We can focus on ESP and tunnel mode only for IPSec.\nThis is typical site-to-site mode for Cloud user scenario. AH and\ntransform mode are rarely used.  The alternative solution is allowed that\nuser can configure IPSecPolicy without specifying them(DB will store them\nas default value).\nc. pfs, the same as IKEPolicy\nd. A minor adjustment suggestion for encryption_algorithm and\nauth_algorithm, we can combine them into a phrase2 algorithm list named\nphrase2_algs like 3des-192-cbc-sha1, aes-128-cbc-sha1. So as to support\nmultiple algorithm proposals in one IKE negotiation. This could be\nconsidered in next release.\n\n3. local_cidrs\nIf we remove local_cidrs, where can we get local subnets parameter, from\nsubnet id?  Does \"subnet_id\" contain all the private subnets need to be\nprotected over VPN tunnel? How to support two local private subnets over\nthe same VPN tunnel(connection)?\n\nThanks\nQin\n\n-----Original Message-----\nFrom: Nachi Ueno [mailto:nachi at ntti3.com]\nSent: 2013?5?17? 7:10\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] VPNaaS\n\nHi folks\n\nWe have meeting today.\n\nOn IRC #openstack-meetings  (It looks like free)\n\nAgenda :\n\n1.Driver archtecture\nhttps://docs.google.com/presentation/d/1uoYMl2fAEHTpogAe27xtGpPcbhm7Y3tlHI\nw_G1Dy5aQ/edit\n    [Conclution] keep reviewing\n    Renamed driver name\n\n2. Agent archtecutre\nhttps://docs.google.com/presentation/d/1e85n2IE38XoYwlsqNvqhKFLox6O01SbguZ\nXq7SnSSGo/edit\n\n[Conclution]\n    At first, take Option1 (implement it as sub-class of l3-agent)\n    VPN-agent will be subclass of subclass of the l3 agent\n\n3.local_subnet vs local_cidr\n\n    remove local_cidr until BGP is implemented and keep discussion\n    keep peer_cidr\n    keep discussions on mailing list\n\n4. Next meeting is not scheudled.\nWe are continue discussion on gerrit.\n\nMunites.\nhttp://eavesdrop.openstack.org/meetings/openstack_networking__vpn_/2013/op\nenstack_networking__vpn_.2013-05-16-22.03.html\n\n2013/5/15 Nachi Ueno <nachi at ntti3.com>:\n> Hi Llya\n>\n> Wow. Sounds Great!\n> Thank you for your contribution.\n>\n> Best\n> Nachi\n>\n>\n>\n> 2013/5/15 Ilya Shakhat <ishakhat at mirantis.com>:\n>> Hi Nachi,\n>>\n>> Tatyana and me volunteer for work on UI for VPNaaS. The corresponding\n>> bp is https://blueprints.launchpad.net/horizon/+spec/vpnaas-ui. We\n>> will start filling the specification soon.\n>>\n>> Thanks,\n>> Ilya\n>>\n>>\n>> 2013/5/15 Nachi Ueno <nachi at ntti3.com>\n>>>\n>>> Hi Folks\n>>>\n>>> We had VPN meetings yesterday.\n>>>\n>>> Agenda :\n>>> 1.  local_subnet vs local_cidr  --> Keep discussion 2.  Use cidr\n>>> value or subnet_id?  --> Keep discussion 3.  Task assignment\n>>>   -  move doc to wiki (Swami) Done\n>>> https://wiki.openstack.org/wiki/Quantum/VPNaaS\n>>>   -  Register BP and get approval by Mark (Swami) Done -> H2\n>>>   -  check default value for lifetime value (Swami) Done\n>>>   -  Implement Data Model (Swami will push code to the gerrit) by 5/20\n>>>   -  CLI (python-quantum client) work (Swami will push code to the\n>>> gerrit) by 5/20\n>>>   -  Implement Driver (Nachi & PCM ) by 5/31\n>>>      - Investigate strongswan\n>>>      -  rpc (spec needed)\n>>>      - Design driver archtecutre (spec needed)\n>>>      - Write driver code\n>>>   - Instation instructions on Wiki 5/31\n>>>   -  Devstack support (nati) late June?\n>>>   -  Write openstack network api document wiki (Sachin)\n>>>   -  Horizon work (needs contributer)\n>>>   -  Tempest (needs contributer)\n>>>\n>>> Next meeting is 5/16 Thursday at 3pm (PST) . On IRC\n>>> #openstack-meetings\n>>>\n>>> Meeting ended Tue May 14 01:00:58 2013 UTC.  Information about\n>>> MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)\n>>> Minutes:\n>>>\n>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201\n>>> 3/openstack_networking_vpn.2013-05-14-00.06.html\n>>> Minutes (text):\n>>>\n>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201\n>>> 3/openstack_networking_vpn.2013-05-14-00.06.txt\n>>> Log:\n>>>\n>>> http://eavesdrop.openstack.org/meetings/openstack_networking_vpn/201\n>>> 3/openstack_networking_vpn.2013-05-14-00.06.log.htm\n>>>\n>>> Thanks!\n>>> Nachi Ueno\n>>>\n>>> 2013/5/10 Nachi Ueno <nachi at ntti3.com>:\n>>> > Hi Paul\n>>> >\n>>> > Thanks for your contributions! :)\n>>> >\n>>> > Nachi\n>>> >\n>>> > 2013/5/10 Paul Michali <pcm at cisco.com>:\n>>> >> Sure! Glad to work with you Nachi. Anything I can do to help out\n>>> >> on the project!\n>>> >>\n>>> >> I\'ll start looking at strongswan and how to configure.\n>>> >>\n>>> >>\n>>> >> Regards,\n>>> >>\n>>> >> PCM (Paul Michali)\n>>> >>\n>>> >>\n>>> >> On May 10, 2013, at 12:35 PM, Nachi Ueno wrote:\n>>> >>\n>>> >> Hi Paul\n>>> >>\n>>> >> Sounds Great.\n>>> >>\n>>> >> The first driver will be strong-swan based.\n>>> >> http://www.strongswan.org/\n>>> >>\n>>> >> How about work with me to implement strong-swan vpn driver?\n>>> >> Honestly, i\'m new to strong-swan, so I\'m very appreciate if you\n>>> >> could try strong-swan on ubuntu and share how to configure it\n>>> >> based on current API model.\n>>> >>\n>>> >> Thanks\n>>> >> Nachi\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2013/5/10 Paul Michali <pcm at cisco.com>:\n>>> >>\n>>> >> Naci, Mark, Swami, Sachin, et al,\n>>> >>\n>>> >>\n>>> >> Any suggestions on where/how I can help on this? I\'m new to OS\n>>> >> (just working\n>>> >>\n>>> >> it for a few months), so no specific expertise area, but have\n>>> >> bandwidth to\n>>> >>\n>>> >> contribute.\n>>> >>\n>>> >>\n>>> >> Also, any pointers to information that will help me get up to\n>>> >> speed on this\n>>> >>\n>>> >> would be appreciated (Mark gave me link to Amazon URL for info on\n>>> >> what they\n>>> >>\n>>> >> provide for VPNaaS). I was going to look at LBaaS code next week\n>>> >> and have\n>>> >>\n>>> >> been monitoring those discussions, as there seem to be some\n>>> >> parallels there.\n>>> >>\n>>> >> If there are companion info that you think would help, let me know.\n>>> >>\n>>> >>\n>>> >> Regards,\n>>> >>\n>>> >>\n>>> >> PCM (Paul Michali)\n>>> >>\n>>> >>\n>>> >> On May 9, 2013, at 9:12 PM, Nachi Ueno wrote:\n>>> >>\n>>> >>\n>>> >> Hi Folks\n>>> >>\n>>> >>\n>>> >> We have meeting about VPN today.\n>>> >>\n>>> >>\n>>> >> #Conclusions\n>>> >>\n>>> >> 1. We agreed ipsec api\n>>> >>\n>>> >> https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis\n>>> >>\n>>> >> 2. Swami will push api CRUD code to review (continue discussion\n>>> >> on\n>>> >> code)\n>>> >>\n>>> >>\n>>> >> https://blueprints.launchpad.net/quantum/+spec/vpnaas-python-apis\n>>> >>\n>>> >> 3. We agreed first implementation vpn architecture\n>>> >>\n>>> >> 4. Next meeting is 5/13 PST 5:00 PM on #openstack-meetings\n>>> >>\n>>> >>\n>>> >> #Questions for IPSec API\n>>> >>\n>>> >> 1 psk_key -> psk (agreed)\n>>> >>\n>>> >> 2 For ipsecpolicy table, suggest to split lifetime into two parts\n>>> >>\n>>> >> lifetime_s(per seconds) and lifetime_b(per kilobytes)   ->  updated\n>>> >>\n>>> >> table (agreed)\n>>> >>\n>>> >> 3 change back \"cidrs\" from subnet (or network)  -> check marks\'s\n>>> >> thought\n>>> >>\n>>> >> 4 For APIs, can we shorten the naming such as change  -> keep\n>>> >> current\n>>> >>\n>>> >> longer style for reability\n>>> >>\n>>> >>\n>>> >> #Project Management (Task)\n>>> >>\n>>> >> -  move doc to wiki (Swami)\n>>> >>\n>>> >> -  Register BP and get approval by Mark (Swami)\n>>> >>\n>>> >> -  check default value for lifetime value (Swami)\n>>> >>\n>>> >> -  Discuss Archtecture\n>>> >>\n>>> >> -  Implement Data Model (Swami will push code to the gerrit)\n>>> >>\n>>> >> -  Driver (Nachi?)\n>>> >>\n>>> >> -  CLI (python-quantum client) work (Swami will push code to the\n>>> >> gerrit)\n>>> >>\n>>> >> -  Write openstack network api document wiki (Sachin)\n>>> >>\n>>> >> -  Devstack support\n>>> >>\n>>> >> -  Horizon work\n>>> >>\n>>> >> -  Tempest\n>>> >>\n>>> >>\n>>> >>\n>>> >> https://docs.google.com/a/ntti3.com/presentation/d/1J7k1eI13-3pQV\n>>> >> wp5XgZDWPfzUvuSqczRdK0lEZKQOKk/edit#slide=id.p\n>>> >>\n>>> >> Nachi\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2013/5/7 Qin Li <qili at vmware.com>:\n>>> >>\n>>> >>\n>>> >> Hi Swami,\n>>> >>\n>>> >>\n>>> >>\n>>> >> Thanks for your comments. All look good to me except local_cidrs,\n>>> >>\n>>> >>\n>>> >> peer_cidrs. \"cidrs\" may be clear for value type and validation,\n>>> >> but it is\n>>> >>\n>>> >>\n>>> >> unfamiliar for the existing VPN administrators. I think we might\n>>> >> use\n>>> >>\n>>> >>\n>>> >> subnets or networks to avoid introducing a new concept for users.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Regards\n>>> >>\n>>> >>\n>>> >> QinLi\n>>> >>\n>>> >>\n>>> >>\n>>> >> -----Original Message-----\n>>> >>\n>>> >>\n>>> >> From: Vasudevan, Swaminathan (PNB Roseville)\n>>> >>\n>>> >>\n>>> >> [mailto:swaminathan.vasudevan at hp.com]\n>>> >>\n>>> >>\n>>> >> Sent: 2013?5?8? 1:25\n>>> >>\n>>> >>\n>>> >> To: OpenStack Development Mailing List\n>>> >>\n>>> >>\n>>> >> Subject: Re: [openstack-dev] VPNaaS\n>>> >>\n>>> >>\n>>> >>\n>>> >> Hi Qin Li,\n>>> >>\n>>> >>\n>>> >> See my answers inline.\n>>> >>\n>>> >>\n>>> >> Thanks.\n>>> >>\n>>> >>\n>>> >>\n>>> >> -----Original Message-----\n>>> >>\n>>> >>\n>>> >> From: Qin Li [mailto:qili at vmware.com]\n>>> >>\n>>> >>\n>>> >> Sent: Monday, May 06, 2013 8:37 PM\n>>> >>\n>>> >>\n>>> >> To: OpenStack Development Mailing List\n>>> >>\n>>> >>\n>>> >> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS\n>>> >>\n>>> >>\n>>> >>\n>>> >> I\'d like to share some of my comments on data models, tables,\n>>> >> APIs defined\n>>> >>\n>>> >>\n>>> >> in link\n>>> >>\n>>> >>\n>>> >>\n>>> >> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ\n>>> >> Q1_PYkEx5\n>>> >>\n>>> >>\n>>> >> J4aO5J5Q74R_PwgV8/edit .\n>>> >>\n>>> >>\n>>> >>\n>>> >> 1. For VPNServiceConnection table\n>>> >>\n>>> >>\n>>> >> a. suggest to remove psk(Boolean) key defined in\n>>> >> VPNServiceConnection\n>>> >>\n>>> >>\n>>> >> table. There is already key auth_mode defined in ikepolicy table.\n>>> >>\n>>> >>\n>>> >> \"auth_mode\" can be \"psk\" or \"certificate\". By default, if not\n>>> >> set, it is\n>>> >>\n>>> >>\n>>> >> psk mode for authentication. Still keeping psk_key inside\n>>> >>\n>>> >>\n>>> >> VPNServiceConnection since psk_key is different per remote peer.\n>>> >>\n>>> >>\n>>> >> Authentication mode is a part of IKE property.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - Yes we had both the auth_mode and psk_key as part of the\n>>> >> IKEPolicy\n>>> >>\n>>> >>\n>>> >> table.  We moved both the fields to the connection table since,\n>>> >> we just\n>>> >>\n>>> >>\n>>> >> wanted to re-use the IKEPolicy for different connections if only\n>>> >> the PSK\n>>> >>\n>>> >>\n>>> >> key changes or the auth_mode changes. Also in the document we\n>>> >> make\n>>> >>\n>>> >>\n>>> >> necessary changes to the table definition, but I need to make the\n>>> >> change\n>>> >>\n>>> >>\n>>> >> also in the datamodel table.\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> b. suggest to change local_cidrs and peer_cidrs to\n>>> >> local_networks(or\n>>> >>\n>>> >>\n>>> >> local_subnets) and peer_networks(per_subnets) in\n>>> >> VPNServiceConnection\n>>> >>\n>>> >>\n>>> >> table.   Cidrs is not a familiar keyword to users in IPSec\nindustry.\n>>> >> Some\n>>> >>\n>>> >>\n>>> >> IPSec VPN vendors use subnets, some use networks.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - Yes we had initially defined it as peer_subnets and\n>>> >> local_subnets,\n>>> >>\n>>> >>\n>>> >> but based on yesterday\'s discussion we moved it to \"cidrs\", since\n>>> >> it would\n>>> >>\n>>> >>\n>>> >> be clear.\n>>> >>\n>>> >>\n>>> >>\n>>> >> c. suggest to change psk_key to psk,  psk already means pre-shared\nkey.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - Accepted we will change this.\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2. For ipsecpolicy table, suggest to split lifetime into two\n>>> >> parts\n>>> >>\n>>> >>\n>>> >> lifetime_s(per seconds) and lifetime_b(per kilobytes).\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - Yes we can discuss about this in Thursday\'s meeting.\n>>> >>\n>>> >>\n>>> >>\n>>> >> 3. Can we shorten the naming of keywords? Such as change\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - We can discuss about this in Thursday\'s meeting. The\n>>> >> reason we\n>>> >>\n>>> >>\n>>> >> don\'t want to have abbreviated keys is for people to understand\n>>> >> the keys\n>>> >>\n>>> >>\n>>> >> properly.\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >>  In vpnserviceconnections table\n>>> >>\n>>> >>\n>>> >>  vpnservice_ipsecpolicy_id  to  ipsecpolicy_id\n>>> >>\n>>> >>\n>>> >>  vpnservice_ikepolicy_id    to  ikepolicy_id\n>>> >>\n>>> >>\n>>> >>  vpnservice_certificiate_id to  certificate_id\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >>  In ikepolicys table\n>>> >>\n>>> >>\n>>> >>  auth_algorithm           to auth_alg\n>>> >>\n>>> >>\n>>> >>  encryption_algorithm     to enc_alg\n>>> >>\n>>> >>\n>>> >>  phraseI_negotiation_mode to phraseI_mode\n>>> >>\n>>> >>\n>>> >>\n>>> >>  In ipsecpolicys table\n>>> >>\n>>> >>\n>>> >>  transform_protocol       to protocol\n>>> >>\n>>> >>\n>>> >>  auth_algorithm           to auth_alg\n>>> >>\n>>> >>\n>>> >>  encryption_algorithm     to enc_alg\n>>> >>\n>>> >>\n>>> >>  encapsulation_mode       to mode or encap_mode\n>>> >>\n>>> >>\n>>> >>\n>>> >> 4. There might be some updates to set proper length for each\n>>> >> value in the\n>>> >>\n>>> >>\n>>> >> tables. Such as change\n>>> >>\n>>> >>\n>>> >>  auth_algorithm VARCHAR2(255)       to auth_alg  VARCHAR2(8)   ;\nfor\n>>> >>\n>>> >>\n>>> >> example \"sha1\" etc.\n>>> >>\n>>> >>\n>>> >>  encryption_algorithm VARCHAR2(255) to enc_alg   VARCHAR2(16)   ;\nfor\n>>> >>\n>>> >>\n>>> >> example \"aes128-cbc\", \"aes256-cbc\" etc.\n>>> >>\n>>> >>\n>>> >>  name VARCHAR2(255)                 to name      VARCHAR2(64)\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - Yes we will make the necessary changes in the table.\n>>> >>\n>>> >>\n>>> >>\n>>> >> 5. What do \"dh\" and \"tls\" keywords mean in table\nvpnservicecertficates?\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami - This was mainly included in the certificate table to\n>>> >> address the\n>>> >>\n>>> >>\n>>> >> \"Openvpn\" certificate requirements. This will be dropped for now.\n>>> >> Also we\n>>> >>\n>>> >>\n>>> >> are not considering to implement the certificates for this\n>>> >> release. We\n>>> >>\n>>> >>\n>>> >> will clean up the tables.\n>>> >>\n>>> >>\n>>> >>\n>>> >> 6. For APIs, can we shorten the naming such as change\n>>> >>\n>>> >>\n>>> >>  /v1.0/vpnservicecertificates/vpnservice_certificate_id  to\n>>> >>\n>>> >>\n>>> >> /v1.0/vpncerts/certificate_id\n>>> >>\n>>> >>\n>>> >>  /v1.0/vpnserviceconnections/vpnservice_conn_id          to\n>>> >>\n>>> >>\n>>> >> /v1.0/vpnsrvconns/conn_id\n>>> >>\n>>> >>\n>>> >>\n>>> >> Swami: We can discuss in Thursday\'s meeting.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Thanks & Regards\n>>> >>\n>>> >>\n>>> >> Qin\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> -----Original Message-----\n>>> >>\n>>> >>\n>>> >> From: Nachi Ueno [mailto:nachi at ntti3.com]\n>>> >>\n>>> >>\n>>> >> Sent: 2013?5?7? 9:07\n>>> >>\n>>> >>\n>>> >> To: OpenStack Development Mailing List\n>>> >>\n>>> >>\n>>> >> Subject: Re: [openstack-dev] [Quantum] [Networking] VPNaaS\n>>> >>\n>>> >>\n>>> >>\n>>> >> Hi folks\n>>> >>\n>>> >>\n>>> >>\n>>> >> In today\'s meeting, we are almost finished to define data models.\n>>> >>\n>>> >>\n>>> >>\n>>> >> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ\n>>> >> Q1_PYkEx5\n>>> >>\n>>> >>\n>>> >> J4aO5J5Q74R_PwgV8/edit\n>>> >>\n>>> >>\n>>> >>\n>>> >> If you have any concerns, please commet it on the doc or question\n>>> >> on the\n>>> >>\n>>> >>\n>>> >> mailing list.\n>>> >>\n>>> >>\n>>> >>\n>>> >> We will have meeting at\n>>> >>\n>>> >>\n>>> >> 5/9 (Thu) 5:00 (PST)\n>>> >>\n>>> >>\n>>> >>\n>>> >> In the next meeting, we will discuss more project management\n>>> >> oriented\n>>> >>\n>>> >>\n>>> >> discussion.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Thanks\n>>> >>\n>>> >>\n>>> >> Nachi\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2013/5/6 Nachi Ueno <nachi at ntti3.com>:\n>>> >>\n>>> >>\n>>> >> Hi folks\n>>> >>\n>>> >>\n>>> >>\n>>> >> Here is note from the meeting at 2nd meeting on VPN # sorry I\n>>> >> thought\n>>> >>\n>>> >>\n>>> >> I have sent it to the mailing list, but it looks not delivery.\n>>> >>\n>>> >>\n>>> >>\n>>> >> 1) FirstStep  SSL-VPN or IPSec?  -> IPSec\n>>> >>\n>>> >>\n>>> >>\n>>> >> - all atenndes agrees with IPSec first step\n>>> >>\n>>> >>\n>>> >> - IPSec is widely used so, this is big win to the community\n>>> >>\n>>> >>\n>>> >> - IPSec can support remote user use case\n>>> >>\n>>> >>\n>>> >> - SSL-VPN (CloudPipe) can be supported by OpenVPN VM with\n>>> >> floating ips\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2) GenricService API -> Agreed\n>>> >>\n>>> >>\n>>> >>\n>>> >> -id\n>>> >>\n>>> >>\n>>> >> -name\n>>> >>\n>>> >>\n>>> >> -tenant_id\n>>> >>\n>>> >>\n>>> >> -type (VPN type)\n>>> >>\n>>> >>\n>>> >> type has namespace (should be flat)\n>>> >>\n>>> >>\n>>> >> l2 vpn -> l2.*** (l2.l2tp)\n>>> >>\n>>> >>\n>>> >> l3 vpn -> l3.** (l3.ipsec)\n>>> >>\n>>> >>\n>>> >>\n>>> >> 3) IPSec API set\n>>> >>\n>>> >>\n>>> >> Start discussion for IPSec api on the google doc\n>>> >>\n>>> >>\n>>> >> https://docs.google.com/a/ntti3.com/document/d/1Jphcvnn7PKxqFEFFZ\n>>> >> Q1_PY\n>>> >>\n>>> >>\n>>> >> kEx5J4aO5J5Q74R_PwgV8/edit\n>>> >>\n>>> >>\n>>> >>\n>>> >> 4) Next meeting time\n>>> >>\n>>> >>\n>>> >> PST Monday 5PM (Sactin at VMWare will reserve conf-call)\n>>> >>\n>>> >>\n>>> >>\n>>> >> Meeting Agenda and Note\n>>> >>\n>>> >>\n>>> >> https://docs.google.com/presentation/d/1J7k1eI13-3pQVwp5XgZDWPfzU\n>>> >> vuSqc\n>>> >>\n>>> >>\n>>> >> zRdK0lEZKQOKk/edit#slide=id.p\n>>> >>\n>>> >>\n>>> >>\n>>> >> Thanks!\n>>> >>\n>>> >>\n>>> >>\n>>> >> 2013/5/1 Sachin Thakkar <sthakkar at vmware.com>:\n>>> >>\n>>> >>\n>>> >> Thanks folks for joining today. We\'ve made some good progress on\n>>> >> the\n>>> >>\n>>> >>\n>>> >> IPsec VPN object model. Nachi has sent out the meeting notes to\n>>> >> the\n>>> >>\n>>> >>\n>>> >> alias as well.\n>>> >>\n>>> >>\n>>> >>\n>>> >> We\'ll need another follow up to continue the discussion. The\n>>> >> meeting\n>>> >>\n>>> >>\n>>> >> will be at 5pm Pacific time on Monday, May 6.\n>>> >>\n>>> >>\n>>> >>\n>>> >> The same bridge below will be used.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Thanks,\n>>> >>\n>>> >>\n>>> >> Sachin\n>>> >>\n>>> >>\n>>> >>\n>>> >> ________________________________\n>>> >>\n>>> >>\n>>> >> From: \"Sachin Thakkar\" <sthakkar at vmware.com>\n>>> >>\n>>> >>\n>>> >> To: \"OpenStack Development Mailing List\n(openstack-dev at lists.openstack.\n>>> >>\n>>> >>\n>>> >> org)\"\n>>> >>\n>>> >>\n>>> >> <openstack-dev at lists.openstack.org>\n>>> >>\n>>> >>\n>>> >> Sent: Thursday, April 25, 2013 11:43:30 PM\n>>> >>\n>>> >>\n>>> >> Subject: [openstack-dev] [Quantum] [Networking] VPNaaS\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> Trying the new Networking tag in the subject :)\n>>> >>\n>>> >>\n>>> >>\n>>> >> Anyway, we have a kickoff call for VPNaaS scheduled next\n>>> >> Wednesday @\n>>> >>\n>>> >>\n>>> >> 5pm Pacific time. We will be discussing over the phone:\n>>> >>\n>>> >>\n>>> >>\n>>> >> Participant Passcode: 697 737 3510\n>>> >>\n>>> >>\n>>> >> Call-in toll-free number (Premiere): 1-866-715-6501 (US)\n>>> >> Additional\n>>> >>\n>>> >>\n>>> >> International Numbers:\n>>> >>\n>>> >>\n>>> >> http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c2558\n>>> >> 5184\n>>> >>\n>>> >>\n>>> >> f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298\n>>> >> f8a5\n>>> >>\n>>> >>\n>>> >> 9d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151\n>>> >> c4b3\n>>> >>\n>>> >>\n>>> >> 0a31fa1b2\n>>> >>\n>>> >>\n>>> >>\n>>> >> To all interested, hope to see you there.\n>>> >>\n>>> >>\n>>> >>\n>>> >> Cheers,\n>>> >>\n>>> >>\n>>> >> Sachin\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >>\n>>> >> OpenStack-dev mailing list\n>>> >>\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >>\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >> OpenStack-dev mailing list\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>> >>\n>>> >>\n>>> >> _______________________________________________\n>>> >> OpenStack-dev mailing list\n>>> >> OpenStack-dev at lists.openstack.org\n>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> >>\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<e300efad.00000c80.0000010b@VMWARE-CE94FEA7.eng.vmware.com>',NULL),('<1132772258.20363315.1383877567046.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 21:26:07',-18000,'2013-11-08 02:26:07',NULL,'[openstack-dev] [Solum] Some initial code copying for\n db/migration','----- Original Message -----\n> >   https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420\n> >   https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43\n> \n> This API and these models are what we are trying to avoid exposing to\n> the rest of nova. By wrapping these in our NovaObject-based structures,\n> we can bundle versioned data and methods together which is what we need\n> for cross-version compatibility and parity for the parts of nova that\n> are not allowed to talk to the database directly.\n> \n> See the code in nova/objects/* for the implementations. Right now, these\n> just call into the db_api.py, but eventually we want to move the actual\n> database implementation into the objects themselves and hopefully\n> dispense with most or all of the sqlalchemy/* stuff. This also provides\n> us the ability to use other persistence backends that aren\'t supported\n> by sqlalchemy, or that don\'t behave like it does.\n> \n> If you\'re going to be at the summit, come to the \"objects\" session on\n> Thursday where we\'ll talk about this in more detail. Other projects have\n> expressed interest in moving the core framework into Oslo so that we\'re\n> all doing things in roughly the same way. It would be good to get you\n> started on \"the right way\" early on before you have the migration hassle\n> we\'re currently \"enjoying\" in Nova :)\n> \n> --Dan\n> \n\nThe summit session was excellent - next step for me is to look through what the right abstraction is going to be for objects that keeps the db details properly isolated and the API surface on /objects suitably coarse (in line with the long discussion in Nova about non-SQL backends, the consensus of which is that the domain object model needs to abstract whole interaction flows, vs granular steps).  I\'ll try to have some example code to debate after I get back from summit.\n\nEven assuming Solum has a fairly small persistence model, in the long run I believe it\'s fair to say that the ability to perform live upgrades will become critical for all operators.  One of the side effects of supporting potentially millions of applications (at the high end, and not an unreasonable estimate for hosted environments) is that any period of downtime at the API level will prevent users from making deployments, which is a direct line-of-business concern.  Designing around live upgrades - specifically, the requirement that code must be aware of two versions of a schema at the same time - implies that the domain model must be able to be aware of those versions on an object basis.  For reference, [1] and [2] contain some of the Nova discussion, and Nova in icehouse is going to be moving this way.  I\'d prefer (it\'s important to Red Hat) to design for that from the beginning and be working towards that end.\n\nDo folks have additional questions or concerns about my exploration of a versioned domain object model from day one?  Are there others who would like to embrace quick and dirty and explicitly ignore this issue until we have a Solum prototype running?  \n\n[1] https://etherpad.openstack.org/p/NovaIcehouseSummitUpgrades\n[2] https://etherpad.openstack.org/p/NovaIcehouseSummitObjects\n\n\n','<5273FC43.3030700@danplanet.com>',NULL),('<1132827071.16.1375943359028.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-08 06:29:18',0,'2013-08-08 06:29:18',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #1','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/1/>\n\n------------------------------------------\n[...truncated 20285 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=4.24 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 4.249/4.249/4.249/0.000 ms\n++ cinder list\n++ grep ex-vol-35da9b32\n++ head -1\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1375942281\n+ cinder create --display_name ex-vol-35da9b32 --display_description \'test volume: ex-vol-35da9b32\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-08T06:11:21.846478      |\n| display_description |     test volume: ex-vol-35da9b32     |\n|     display_name    |           ex-vol-35da9b32            |\n|          id         | eec80702-3bc1-4a99-b7bb-906b2bac4adf |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-35da9b32 | grep available; do sleep 1; done\'\n| eec80702-3bc1-4a99-b7bb-906b2bac4adf | available | ex-vol-35da9b32 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375942284\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-35da9b32\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| eec80702-3bc1-4a99-b7bb-906b2bac4adf | available | ex-vol-35da9b32 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=eec80702-3bc1-4a99-b7bb-906b2bac4adf\n+ die_if_not_set 164 VOL_ID \'Failure retrieving volume ID for ex-vol-35da9b32\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1375942284\n+ nova volume-attach f55de1d0-bc81-45cd-ace1-11ba2e55049b eec80702-3bc1-4a99-b7bb-906b2bac4adf /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | f55de1d0-bc81-45cd-ace1-11ba2e55049b |\n| id       | eec80702-3bc1-4a99-b7bb-906b2bac4adf |\n| volumeId | eec80702-3bc1-4a99-b7bb-906b2bac4adf |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-35da9b32 | grep in-use; do sleep 1; done\'\n| eec80702-3bc1-4a99-b7bb-906b2bac4adf | in-use | ex-vol-35da9b32 |  1   |     None    |  False   | f55de1d0-bc81-45cd-ace1-11ba2e55049b |\n++ date +%s\n+ end_time=1375942287\n+ echo \'Completed volume-attach in 3 seconds\'\nCompleted volume-attach in 3 seconds\n++ cinder list\n++ grep ex-vol-35da9b32\n++ get_field -1\n++ read data\n++ head -1\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| eec80702-3bc1-4a99-b7bb-906b2bac4adf | in-use | ex-vol-35da9b32 |  1   |     None    |  False   | f55de1d0-bc81-45cd-ace1-11ba2e55049b |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=f55de1d0-bc81-45cd-ace1-11ba2e55049b\n+ die_if_not_set 178 VOL_ATTACH \'Failure retrieving ex-vol-35da9b32 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ f55de1d0-bc81-45cd-ace1-11ba2e55049b != f55de1d0-bc81-45cd-ace1-11ba2e55049b ]]\n++ date +%s\n+ start_time=1375942288\n+ nova volume-detach f55de1d0-bc81-45cd-ace1-11ba2e55049b eec80702-3bc1-4a99-b7bb-906b2bac4adf\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-35da9b32 | grep available; do sleep 1; done\'\n| eec80702-3bc1-4a99-b7bb-906b2bac4adf | available | ex-vol-35da9b32 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375942291\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1375942291\n+ cinder delete eec80702-3bc1-4a99-b7bb-906b2bac4adf\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-35da9b32; do sleep 1; done\'\n| eec80702-3bc1-4a99-b7bb-906b2bac4adf | deleting | ex-vol-35da9b32 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375942294\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete f55de1d0-bc81-45cd-ace1-11ba2e55049b\n+ timeout 60 sh -c \'while nova list | grep -q f55de1d0-bc81-45cd-ace1-11ba2e55049b; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1529.g61c0f57.zip\nall runtests: commands[0] | python setup.py testr --slowest\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp8LFZSW\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpCs1HUK\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp4MtvDP\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpHGMgqS\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-3\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 28, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2402 tests in 995.346s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/rabbitmq/rabbit at devstack-1375940477-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/rabbitmq/rabbit at devstack-1375940477.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-2934/1/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1133246357.11487260.1349958656726.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 08:30:56',-14400,'2012-10-11 12:30:56',NULL,'[openstack-dev] [keystone] on-behalf-of proxy identities for\n applications running in-instance','\n\n> > Maybe I\'m missing something fundamental, might make sense to walk\n> > through a hypothetical case ...\n> > \n> > - Bob has two instances, webserver & DB both of type m1.medium\n> >\n> So Bob is a member of tenant \"T1\", and creates a stack (associated\n> with T1), which contains the instances\n> \n> > - Alice has a single instance, mailserver of type m1.medium\n> >\n> > - Bob and Alice are associated with different tenants\n> \n> So she is a member of tenant T2\n>  \n> > - Heat creates 3 new proxy users, webserver_user, DB_user &\n> >   mailserver_user\n> \n> So webserver_user, DB_user are in T1, mailserver_user is in T2\n\n\nOK, cool, so that\'s basically the opposite of what I understood by\n\"separate tenant\" idea mooted earlier. \n\nAs long as the generated {instance}_users are always associated with\nthe same tenant as the original instance owner then, yep, no mapping\nis necessarily required, as long as everything we need to do after\nthe fact is scoped at the tenant level (e.g. there\'s no requirement\nfor per-user chargeback for the {instance}_user\'s API calls, mapping\nback to the original user\'s identity).\n\nI\'m not sure what the \"seperate tenant\" idea was aiming to achieve\nfrom a lock-down perspective, given that the limited-karma role\nwould be associated with the user as the opposed the tenant. Anyway\nit seems that idea has fallen by the wayside ...\n\nCheers,\nEoghan\n\n\n \n> T1 will only have visibility (and hence be able to publish metric\n> data for)\n> stacks owned by T1, so webserver_user, DB_user can only publish\n> metric data\n> for Bobs stack(s)/instances, and vice-versa for T2\n>  \n> > - cfn-push-stats assumes the identity of {instance}_user when\n> >   reporting metrics from within each instance\n> > \n> > - Bob calls GetMetricStatistics with his original identity,\n> >   requesting dimension InstanceType=m1.medium\n> >\n> > - we expect only the metrics for webserver & DB to be aggregated,\n> >   but not mailserver (or?)\n> >\n> Bob can only see watch rules (and hence metric-data) for stacks owned\n> by T1,\n> so we query the DB and get results for webserver & DB (not mailserver\n> as\n> it\'s owned by T2), which I think is what is expected.\n> \n> That said, the current heat cloudwatch implementation doesn\'t support\n> query/filter by dimension, or GetMetricStatistics (yet), and we do\n> need to\n> improve our DB schema to allow this to be done efficiently.  The\n> basic\n> mapping describe above should remain the same though (maybe will get\n> more\n> complex when we decouple heat orchestration and cloudwatch..)\n> \n> Steve\n> \n\n\n','<20121011120819.GA17633@heatlt.redhat.com>',NULL),('<1133625527.31.1367647720791.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-04 06:08:40',0,'2013-05-04 06:08:40',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-grizzly #24','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/24/changes>\n\n\n\n','<1019402913.9.1367561306547.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1133791768.51.1374733606109.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-25 06:26:46',0,'2013-07-25 06:26:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python27-stable-grizzly #19','See <https://jenkins.openstack.org/job/periodic-neutron-python27-stable-grizzly/19/>\n\n\n\n','<466787426.42.1374647087918.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1134315209.16214412.1421934179329.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-22 08:42:59',-18000,'2015-01-22 13:42:59',NULL,'[Openstack-operators] Import Windows 2008 Vmware VMDK Image to\n KVM	Openstack.','----- Original Message -----\n> From: \"Pedro Sousa\" <pgsousa at gmail.com>\n> To: \"OpenStack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org>\n> \n> Hi all,\n> \n> does anybody have a working procedure/howto to convert Windows based VMDK\n> images to KVM?\n> \n> I tried to convert using qemu-img convert command but I always get a blue\n> screen when I launch the instance.\n> \n> Thanks,\n> Pedro Sousa\n\nYou might want to look into virt-v2v ( http://libguestfs.org/virt-v2v/ ). It performs some additional actions to converting the disk image such as injecting virtio drivers.\n\n-Steve\n\n\n','<CA+E02ZC++fbNUBgZkRUR8JUG_Gdkg2oNWoQ5N-2OW_ts=i6L6w@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1134480988.40.1380298758233.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-27 16:19:18',0,'2013-09-27 16:19:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #30','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/30/>\n\n------------------------------------------\n[...truncated 7307 lines...]\n2013-09-27 16:18:57 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-09-27 16:18:57 secure_delete = False\n2013-09-27 16:18:57 \' /etc/cinder/cinder.conf\n2013-09-27 16:18:57 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-09-27 16:18:57 + local file=/etc/cinder/cinder.conf\n2013-09-27 16:18:57 + local section=DEFAULT\n2013-09-27 16:18:57 + local option=volume_clear\n2013-09-27 16:18:57 + local value=none\n2013-09-27 16:18:57 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-09-27 16:18:57 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-09-27 16:18:57 + local file=/etc/cinder/cinder.conf\n2013-09-27 16:18:57 + local section=DEFAULT\n2013-09-27 16:18:57 + local option=volume_clear\n2013-09-27 16:18:57 + local line\n2013-09-27 16:18:57 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-09-27 16:18:57 + line=\n2013-09-27 16:18:57 + \'[\' -n \'\' \']\'\n2013-09-27 16:18:57 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-09-27 16:18:57 volume_clear = none\n2013-09-27 16:18:57 \' /etc/cinder/cinder.conf\n2013-09-27 16:18:57 + \'[\' False == True \']\'\n2013-09-27 16:18:57 + \'[\' default == XenAPINFS \']\'\n2013-09-27 16:18:57 + \'[\' default == sheepdog \']\'\n2013-09-27 16:18:57 + is_service_enabled quantum\n2013-09-27 16:18:57 + services=quantum\n2013-09-27 16:18:57 + for service in \'${services}\'\n2013-09-27 16:18:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-09-27 16:18:57 + return 0\n2013-09-27 16:18:57 + install_quantum\n2013-09-27 16:18:57 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-09-27 16:18:57 + [[ False = \\T\\r\\u\\e ]]\n2013-09-27 16:18:57 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-09-27 16:18:57 + GIT_DEST=/opt/stack/new/neutron\n2013-09-27 16:18:57 + GIT_REF=stable/grizzly\n2013-09-27 16:18:57 + echo stable/grizzly\n2013-09-27 16:18:57 + egrep -q \'^refs\'\n2013-09-27 16:18:57 + [[ ! -d /opt/stack/new/neutron ]]\n2013-09-27 16:18:58 + [[ \'\' == \\y\\e\\s ]]\n2013-09-27 16:18:58 + setup_develop /opt/stack/new/neutron\n2013-09-27 16:18:58 + [[ False = True ]]\n2013-09-27 16:18:58 + SUDO_CMD=sudo\n2013-09-27 16:18:58 + cd /opt/stack/new/neutron\n2013-09-27 16:18:58 + python setup.py egg_info\n2013-09-27 16:18:58 running egg_info\n2013-09-27 16:18:58 creating quantum.egg-info\n2013-09-27 16:18:58 writing requirements to quantum.egg-info/requires.txt\n2013-09-27 16:18:58 writing quantum.egg-info/PKG-INFO\n2013-09-27 16:18:58 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-09-27 16:18:58 writing top-level names to quantum.egg-info/top_level.txt\n2013-09-27 16:18:58 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-09-27 16:18:58 writing entry points to quantum.egg-info/entry_points.txt\n2013-09-27 16:18:58 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-27 16:18:58 reading manifest template \'MANIFEST.in\'\n2013-09-27 16:18:58 warning: no files found matching \'AUTHORS\'\n2013-09-27 16:18:58 warning: no files found matching \'ChangeLog\'\n2013-09-27 16:18:58 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-09-27 16:18:58 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-09-27 16:18:58 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-27 16:18:58 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-27 16:18:58 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-09-27 16:18:58 + raw_links=\n2013-09-27 16:18:58 ++ echo\n2013-09-27 16:18:58 ++ xargs\n2013-09-27 16:18:58 + depend_links=\n2013-09-27 16:18:58 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-09-27 16:18:58 ++ echo \'-r *-info/requires.txt\'\n2013-09-27 16:18:58 + require_file=\'-r *-info/requires.txt\'\n2013-09-27 16:18:58 + pip_install -r quantum.egg-info/requires.txt\n2013-09-27 16:18:58 + [[ False = \\T\\r\\u\\e ]]\n2013-09-27 16:18:58 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-09-27 16:18:58 + [[ -z deb ]]\n2013-09-27 16:18:58 + [[ False = True ]]\n2013-09-27 16:18:58 + SUDO_PIP=sudo\n2013-09-27 16:18:58 ++ get_pip_command\n2013-09-27 16:18:58 ++ is_fedora\n2013-09-27 16:18:58 ++ [[ -z Ubuntu ]]\n2013-09-27 16:18:58 ++ \'[\' Ubuntu = Fedora \']\'\n2013-09-27 16:18:58 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-09-27 16:18:58 ++ \'[\' Ubuntu = CentOS \']\'\n2013-09-27 16:18:58 ++ which pip\n2013-09-27 16:18:58 + CMD_PIP=/usr/local/bin/pip\n2013-09-27 16:18:58 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-09-27 16:18:58 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-09-27 16:18:58 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-09-27 16:18:58 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:18:58   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.3.tar.gz\n2013-09-27 16:18:58   Running setup.py egg_info for package python-quantumclient\n2013-09-27 16:18:58     [pbr] Processing SOURCES.txt\n2013-09-27 16:18:58     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-09-27 16:18:58     \n2013-09-27 16:18:58     [pbr] In git context, generating filelist from git\n2013-09-27 16:18:58     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-09-27 16:19:02 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-09-27 16:19:02   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.0.tar.gz\n2013-09-27 16:19:02   Running setup.py egg_info for package alembic\n2013-09-27 16:19:02     \n2013-09-27 16:19:02     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-09-27 16:19:02     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-09-27 16:19:02     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-09-27 16:19:02     no previously-included directories found matching \'docs/build/output\'\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.16,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Downloading/unpacking pyparsing>=1.5.6,<2.0 (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyparsing%2Fpyparsing-1.5.7.tar.gz\n2013-09-27 16:19:02   Running setup.py egg_info for package pyparsing\n2013-09-27 16:19:02     \n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-27 16:19:02 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-09-27 16:19:02   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-09-27 16:19:02   Running setup.py egg_info for package Mako\n2013-09-27 16:19:02     \n2013-09-27 16:19:02     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-09-27 16:19:02     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-09-27 16:19:02     warning: no files found matching \'ez_setup.py\'\n2013-09-27 16:19:02     no previously-included directories found matching \'doc/build/output\'\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.16,<0.6->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=0.9.6->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-27 16:19:02 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-09-27 16:19:02 Installing collected packages: python-quantumclient, alembic, pyparsing, Mako\n2013-09-27 16:19:02   Running setup.py install for python-quantumclient\n2013-09-27 16:19:02     [pbr] Reusing existing SOURCES.txt\n2013-09-27 16:19:02     Installing quantum script to /usr/local/bin\n2013-09-27 16:19:02   Running setup.py install for alembic\n2013-09-27 16:19:02     \n2013-09-27 16:19:02     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-09-27 16:19:02     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-09-27 16:19:02     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-09-27 16:19:02     no previously-included directories found matching \'docs/build/output\'\n2013-09-27 16:19:02     Installing alembic script to /usr/local/bin\n2013-09-27 16:19:02   Found existing installation: pyparsing 2.0.1\n2013-09-27 16:19:03     Uninstalling pyparsing:\n2013-09-27 16:19:03       Successfully uninstalled pyparsing\n2013-09-27 16:19:03   Running setup.py install for pyparsing\n2013-09-27 16:19:03     \n2013-09-27 16:19:03   Running setup.py install for Mako\n2013-09-27 16:19:03     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-09-27 16:19:03     \n2013-09-27 16:19:03     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-09-27 16:19:03     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-09-27 16:19:03     warning: no files found matching \'ez_setup.py\'\n2013-09-27 16:19:03     no previously-included directories found matching \'doc/build/output\'\n2013-09-27 16:19:03     changing mode of /usr/local/bin/mako-render to 755\n2013-09-27 16:19:03 Successfully installed python-quantumclient alembic pyparsing Mako\n2013-09-27 16:19:03 Cleaning up...\n2013-09-27 16:19:03 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-09-27 16:19:03 running develop\n2013-09-27 16:19:03 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-09-27 16:19:03 /usr/bin/python -E -c pass\n2013-09-27 16:19:03 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-09-27 16:19:03 running egg_info\n2013-09-27 16:19:03 writing requirements to quantum.egg-info/requires.txt\n2013-09-27 16:19:03 writing quantum.egg-info/PKG-INFO\n2013-09-27 16:19:03 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-09-27 16:19:03 writing top-level names to quantum.egg-info/top_level.txt\n2013-09-27 16:19:03 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-09-27 16:19:03 writing entry points to quantum.egg-info/entry_points.txt\n2013-09-27 16:19:03 reading manifest template \'MANIFEST.in\'\n2013-09-27 16:19:03 warning: no files found matching \'AUTHORS\'\n2013-09-27 16:19:03 warning: no files found matching \'ChangeLog\'\n2013-09-27 16:19:03 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-09-27 16:19:03 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-09-27 16:19:03 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-27 16:19:03 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-27 16:19:03 running build_ext\n2013-09-27 16:19:03 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-09-27 16:19:03 Adding quantum 2013.1.4.a13.g4601b14 to easy-install.pth file\n2013-09-27 16:19:03 Installing quantum-debug script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-nec-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-ryu-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-l3-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-db-manage script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-metadata-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-server script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-09-27 16:19:03 Installing quantum-rootwrap script to /usr/local/bin\n2013-09-27 16:19:03 \n2013-09-27 16:19:03 Installed /opt/stack/new/neutron\n2013-09-27 16:19:03 Processing dependencies for quantum==2013.1.4.a13.g4601b14\n2013-09-27 16:19:03 error: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n2013-09-27 16:19:03 ++ failed\n2013-09-27 16:19:03 ++ local r=1\n2013-09-27 16:19:03 +++ jobs -p\n2013-09-27 16:19:03 ++ kill\n2013-09-27 16:19:03 ++ set +o xtrace\n2013-09-27 16:19:03 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-27-161532\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-407835-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-407835.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-407835/30/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1167229589.34.1380175922471.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1134614479.2092079.1399414943597.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 18:22:23',-14400,'2014-05-06 22:22:23',NULL,'[openstack-dev] [nova] Consuming keystoneclient\'s Session object in\n	novaclient','All, \n\nTL;DR: novaclient should be able to use the common transport/auth layers of keystoneclient. If it does there are going to be functions like client.authenticate() that won\'t operate the same way when a session object is passed. For most users who just use the CRUD operations there will be no difference. \n\n\nI\'m hoping that at least some of the nova community has heard of the push for using keystoneclient\'s Session object across all the clients. For those unaware keystoneclient.session.Session is a common transport and authentication layer to remove the need for each python-*client having there own authentication configuration and disparate transport options.\n\nIt offers:\n - a single place for updates to transport (eg fixing TLS or other transport issues in one place)\n - a way for all clients to immediately support the full range of keystone\'s authentication including v3 auth, SAML, kerberos etc\n - a common place to handle version discovery such that we support multiple version endpoints from the same service catalog endpoint.\n\nFor information of how to interact with a session you can see: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ This mentions the code is uncommitted however has since been committed with a few small details around parameter names being changed. The theory remains the same. \n\n\nTo integrate this into novaclient means that if a session= object is passed then the standard HTTPClient code will be ignored in favour of using what was passed. This means that there are changes in the API of the client. In keystoneclient we have take the opinion that by passing a session object then you opt-in to the newer API and therefore accept that some functions are no longer available. For example client.authenticate() is no longer allowed because authentication is not the client\'s responsibility. It will have no impact on the standard novaclient CRUD operations and so be un-noticed by the vast majority of users.\n\nThe review showing these changes is here: https://review.openstack.org/#/c/85920\n\nTo enable this there are a series of test changes to mock client requests at the HTTP layer rather than in the client. This means that we can test that all client operations against the new and old client construction methods and ensure the same requests are being sent. The foundation of this to turn tests into fixtures can be found by following: https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing\n\nIMO making these tests into fixtures is a good idea anyway, however I am only pursuing it so that we can transition to using a common Session.\n\nRegarding dependencies, novaclient will need a test-requirements.txt on keystoneclient so that it can construct Session objects to test with but it should not need a requirements.txt as the session object is constructed by the user of the client (eg openstackclient, horizon etc).\n\n\nIf there are concerns with this process please respond here and/or on the review.\n\n\nThanks, \n\nJamie\n\n\n','<1651508185.2083335.1399412629719.JavaMail.zimbra@redhat.com>',NULL),('<1135410787.28.1372400106506.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-28 06:15:06',0,'2013-06-28 06:15:06',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #79','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/79/>\n\n\n\n','<1248992942.26.1372313655654.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1136341262.3440667.1386366480587.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 16:48:00',-18000,'2013-12-06 21:48:00',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','That looks really good, thanks for putting that together!\n\nI\'m going to put together a wiki page that consolidates the various Tuskar\nplanning documents - requirements, user stories, wireframes, etc - so it\'s\neasier to see the whole planning picture.\n\nMainn\n\n----- Original Message -----\n> \n> On Dec 5, 2013, at 9:31 PM, Tzu-Mainn Chen <tzumainn at redhat.com> wrote:\n> \n> > Hey all,\n> > \n> > I\'ve attempted to spin out the requirements behind Jarda\'s excellent\n> > wireframes\n> > (http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html).\n> > Hopefully this can add some perspective on both the wireframes and the\n> > needed changes to the tuskar-api.\n> \n> This list is great, thanks very much for taking the time to write this up! I\n> think a big part of the User Experience design is to take a step back and\n> understand the requirements from an end user\'s point of view?what would they\n> want to accomplish by using this UI? This might influence the design in\n> certain ways, so I\'ve taken a cut at a set of user stories for the Icehouse\n> timeframe based on these requirements that I hope will be useful during\n> discussions.\n> \n> Based on the OpenStack Personas[1], I think that Anna would be the main\n> consumer of the TripleO UI, but please let me know if you think otherwise.\n> \n> - As an infrastructure administrator, Anna needs to deploy or update a set of\n> resources that will run OpenStack (This isn\'t a very specific use case, but\n> more of the larger end goal of Anna coming into the UI.)\n> - As an infrastructure administrator, Anna expects that the management node\n> for the deployment services is already up and running and the status of this\n> node is shown in the UI.\n> - As an infrastructure administrator, Anna wants to be able to quickly see\n> the set of unallocated nodes that she could use for her deployment of\n> OpenStack. Ideally, she would not have to manually tell the system about\n> these nodes. If she needs to manually register nodes for whatever reason,\n> Anna would only want to have to define the essential data needed to register\n> these nodes.\n> - As an infrastructure administrator, Anna needs to assign a role to each of\n> the necessary nodes in her OpenStack deployment. The nodes could be either\n> controller, compute, networking, or storage resources depending on the needs\n> of this deployment.\n> - As an infrastructure administrator, Anna wants to review the distribution\n> of the nodes that she has assigned before kicking off the \"Deploy\" task.\n> - As an infrastructure administrator, Anna wants to monitor the deployment\n> process of all of the nodes that she has assigned.\n> - As an infrastructure administrator, Anna needs to be able to troubleshoot\n> any errors that may occur during the deployment of nodes process.\n> - As an infrastructure administrator, Anna wants to monitor the availability\n> and status of each node in her deployment.\n> - As an infrastructure administrator, Anna wants to be able to unallocate a\n> node from a deployment.\n> - As an infrastructure administrator, Anna wants to be able to view the\n> history of nodes that have been in a deployment.\n> - As an infrastructure administrator, Anna needs to be notified of any\n> important changes to nodes that are in the OpenStack deployment. She does\n> not want to be spammed with non-important notifications.\n> \n> Please feel free to comment, change, or add to this list.\n> \n> [1]https://docs.google.com/document/d/16rkiXWxxgzGT47_Wc6hzIPzO2-s2JWAPEKD0gP2mt7E/edit?pli=1#\n> \n> Thanks,\n> Liz\n> \n> > \n> > All comments are welcome!\n> > \n> > Thanks,\n> > Tzu-Mainn Chen\n> > \n> > --------------------------------\n> > \n> > *** Requirements are assumed to be targeted for Icehouse, unless marked\n> > otherwise:\n> >   (M) - Maybe Icehouse, dependency on other in-development features\n> >   (F) - Future requirement, after Icehouse\n> > \n> > * NODES\n> >   * Creation\n> >      * Manual registration\n> >         * hardware specs from Ironic based on mac address (M)\n> >         * IP auto populated from Neutron (F)\n> >      * Auto-discovery during undercloud install process (M)\n> >   * Monitoring\n> >       * assignment, availability, status\n> >       * capacity, historical statistics (M)\n> >   * Management node (where triple-o is installed)\n> >       * created as part of undercloud install process\n> >       * can create additional management nodes (F)\n> >    * Resource nodes\n> >        * searchable by status, name, cpu, memory, and all attributes from\n> >        ironic\n> >        * can be allocated as one of four node types\n> >            * compute\n> >            * controller\n> >            * object storage\n> >            * block storage\n> >        * Resource class - allows for further categorization of a node type\n> >            * each node type specifies a single default resource class\n> >                * allow multiple resource classes per node type (M)\n> >            * optional node profile for a resource class (M)\n> >                * acts as filter for nodes that can be allocated to that\n> >                class (M)\n> >        * nodes can be viewed by node types\n> >                * additional group by status, hardware specification\n> >        * controller node type\n> >           * each controller node will run all openstack services\n> >              * allow each node to run specified service (F)\n> >           * breakdown by workload (percentage of cpu used per node) (M)\n> >    * Unallocated nodes\n> >    * Archived nodes (F)\n> >        * Will be separate openstack service (F)\n> > \n> > * DEPLOYMENT\n> >   * multiple deployments allowed (F)\n> >     * initially just one\n> >   * deployment specifies a node distribution across node types\n> >      * node distribution can be updated after creation\n> >   * deployment configuration, used for initial creation only\n> >      * defaulted, with no option to change\n> >         * allow modification (F)\n> >   * review distribution map (F)\n> >   * notification when a deployment is ready to go or whenever something\n> >   changes\n> > \n> > * DEPLOYMENT ACTION\n> >   * Heat template generated on the fly\n> >      * hardcoded images\n> >         * allow image selection (F)\n> >      * pre-created template fragments for each node type\n> >      * node type distribution affects generated template\n> >   * nova scheduler allocates nodes\n> >      * filters based on resource class and node profile information (M)\n> >   * Deployment action can create or update\n> >   * status indicator to determine overall state of deployment\n> >      * status indicator for nodes as well\n> >      * status includes \'time left\' (F)\n> > \n> > * NETWORKS (F)\n> > * IMAGES (F)\n> > * LOGS (F)\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<D491CCDA-1003-4F4F-81FC-CECADB5FAB53@redhat.com>',NULL),('<11379465.E1ltjE6RFd@bort.suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 14:19:35',3600,'2013-11-22 13:19:35',NULL,'[openstack-dev] [horizon] Javascript development improvement','On Friday 22 November 2013 13:13:29 Matthias Runge wrote:\n> On 11/21/2013 01:55 PM, Jiri Tomasek wrote:\n> > Hi,\n> > \n> > \n> > Regarding less, I don\'t really care what compiler we use as long as it\n> > works. And if we need to provide uncompiled less for production, then\n> > let\'s use Lesscpy.\n> \n> There is at least one bug open against Ubuntu[1], asking to install\n> python-lesscpy as well, as customers \"often\" need to re-create or change\n> stylesheets.\n\nI asked chuck months ago to package it :-) \n\n> This would imply nodejs in a production environment, when going back to\n> less.\n> \n> Just naming the n word here, makes people bite, for whatever reason ;-)\n> \n> Matthias\n> \n> [1]\n> https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/1012f23e/attachment.pgp>\n\n','<528F4A69.40302@redhat.com>',NULL),('<1137973079.9.1377670729339.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-28 06:18:49',0,'2013-08-28 06:18:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python26-stable-grizzly #15','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/15/changes>\n\n\n\n','<1882844820.7.1377584221179.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1138316394.38.1375596171852.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-04 06:02:51',0,'2013-08-04 06:02:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #124','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/124/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-181617 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #212085 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stable-grizzly] $ /bin/bash -xe /tmp/hudson7417028952693695361.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stable-grizzly] $ /bin/bash -xe /tmp/hudson6912409362640589110.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_FULL=1\n+ DEVSTACK_GATE_TEMPEST_FULL=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-181617\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-181617/124\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-181617/124/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-181617/124/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1138757947.23653347.1403801854240.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 12:57:34',-14400,'2014-06-26 16:57:34',NULL,'[openstack-dev] [Neutron]One security issue about floating ip','Yes, once a connection has past the nat tables, \nand it\'s on the kernel connection tracker, it\nwill keep working even if you remove the nat rule.\n\nDoing that would require manipulating the kernel\nconnection tracking to kill that connection, \nI\'m not familiar with that part of the linux network\nstack, not sure if it\'s possible, but that would be\nthe perfect way. (kill nat connection on ext ip=float ip int_ip = internal ip)...\n\n\n\n\n----- Original Message -----\n> Hi folks,\n> \n> After we create an SSH connection to a VM via its floating ip, even though we\n> have removed the floating ip association, we can still access the VM via\n> that connection. Namely, SSH is not disconnected when the floating ip is not\n> valid. Any good solution about this security issue?\n> \n> Thanks\n> Xurong Yang\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CABxeuoK3EXVm48_+8jpZEbU0qNN4aY+OHUrZ2y2FayK=O8raCQ@mail.gmail.com>',NULL),('<1138C90D-055F-46AB-A1D7-6A6FA8CB7193@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 17:58:25',14400,'2013-09-30 13:58:25',NULL,'[openstack-dev] [savanna] 0.3 release schedule','Hi folks,\n\nhere is a schedule for Savanna 0.3 release:\n\n30-Sep-2013 // Savanna 0.3a1 (already available)\n03-Oct-2013  // Feature Freeze // Savanna 0.3aX\n10-Oct-2013	 // Code Freeze // Savanna 0.3-rc1\n14-Oct-2013	 // Savanna 0.3-rc2 (on demand)\n15-Oct-2013	 // Savanna 0.3-rc3 (on demand)\n17-Oct-2013	 // Savanna 0.3\n\nhttps://wiki.openstack.org/wiki/Savanna/0.3_Release_Schedule\n\nThanks.\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\n\n\n',NULL,NULL),('<113966381.19103270.1383601773463.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 16:49:33',-18000,'2013-11-04 21:49:33',NULL,'[openstack-dev] Improvement of Cinder API wrt\n https://bugs.launchpad.net/nova/+bug/1213953','So,\nThere\'s currently an outstanding issue with regards to a Nova shortcut command that creates a volume from an image and then boots from it in one fell swoop.  The gist of the issue is that there is currently a set timeout which can time out before the volume creation has finished (it\'s designed to time out in case there is an error), in cases where the image download or volume creation takes an extended period of time (e.g. under a Gluster backend for Cinder with certain network conditions).\n\nThe proposed solution is a modification to the Cinder API to provide more detail on what exactly is going on, so that we could programmatically tune the timeout.  My initial thought is to create a new column in the Volume table called \'status_detail\' to provide more detailed information about the current status.  For instance, for the \'downloading\' status, we could have \'status_detail\' be the completion percentage or JSON containing the total size and the current amount copied.  This way, at each interval we could check to see if the amount copied had changed, and trigger the timeout if it had not, instead of blindly assuming that the operation will complete within a given amount of time.\n\nWhat do people think?  Would there be a better way to do this?\n\nBest Regards,\nSolly Ross\n\n\n','<1124634928.19083965.1383599875202.JavaMail.root@redhat.com>',NULL),('<1139831963.37.1386482595645.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-08 06:03:15',0,'2013-12-08 06:03:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-grizzly #3','See <https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/3/>\n\n------------------------------------------\n[...truncated 649 lines...]\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 14.869s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.19.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.grizzly.3\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.7\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.12.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.8\nrequests==2.1.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\nwarlock==1.1.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.oXFS62ahu0\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-grizzly/precise22\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-grizzly/precise22/3\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1139906069.43.1386657213894.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-10 06:33:33',0,'2013-12-10 06:33:33',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-pg-havana #4','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-pg-havana/4/>\n\n------------------------------------------\n[...truncated 21391 lines...]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... FAIL\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\ntearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... FAIL\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\n\nprocess-returncode\nprocess-returncode ... FAIL\n\n======================================================================\nFAIL: tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-12-10 06:25:30,197 state: pending\n2013-12-10 06:25:34,013 State transition \"pending\" ==> \"error\" 3 second\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 175, in test_run_stop_terminate_instance_with_tags\n    self.assertInstanceStateWait(instance, \"running\")\n  File \"tempest/thirdparty/boto/test.py\", line 356, in assertInstanceStateWait\n    state = self.waitInstanceState(lfunction, wait_for)\n  File \"tempest/thirdparty/boto/test.py\", line 341, in waitInstanceState\n    self.valid_instance_state)\n  File \"tempest/thirdparty/boto/test.py\", line 332, in state_wait_gone\n    self.assertIn(state, valid_set | self.gone_set)\n  File \"/usr/local/lib/python2.7/dist-packages/testtools/testcase.py\", line 330, in assertIn\n    self.assertThat(haystack, Contains(needle))\n  File \"/usr/local/lib/python2.7/dist-packages/testtools/testcase.py\", line 414, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: u\'error\' not in set([\'paused\', \'terminated\', \'running\', \'stopped\', \'pending\', \'_GONE\', \'stopping\', \'shutting-down\'])\n\n\n======================================================================\nFAIL: tearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\ntearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/thirdparty/boto/test.py\", line 270, in tearDownClass\n    raise exceptions.TearDownException(num=fail_count)\nTearDownException: 1 cleanUp operation failed\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 249 tests in 1482.481s\n\nFAILED (failures=3, skipped=9)\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  168.260\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          115.270\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  72.896\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]           32.477\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]                           23.924\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]             19.193\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                          16.918\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]                      14.246\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]               11.860\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]                     10.452\nERROR: InvocationError: \'/bin/sh tools/pretty_tox_serial.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])((smoke)|(^tempest\\\\.scenario)) \'\n___________________________________ summary ____________________________________\nERROR:   smoke-serial: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/localrc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-819951-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-819951.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-lbaas.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-q-vpn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/neutron-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-819951/4/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1819837105.39.1386484716548.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1140486543.2271567.1384271166281.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 10:46:06',-18000,'2013-11-12 15:46:06',NULL,'[openstack-dev] Improvement of Cinder API wrt\n https://bugs.launchpad.net/nova/+bug/1213953','I\'d like to get some sort of consensus on this before I start working on it.  Now that people are back from Summit, what would you propose?\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Solly Ross\" <sross at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, November 5, 2013 10:40:48 AM\nSubject: Re: [openstack-dev] Improvement of Cinder API wrt https://bugs.launchpad.net/nova/+bug/1213953\n\nAlso, that\'s still an overly complicated process for one or two VMs.  The idea behind the Nova command was to minimize the steps in the image->volume->VM process for a single VM.\n\n----- Original Message -----\nFrom: \"Chris Friesen\" <chris.friesen at windriver.com>\nTo: openstack-dev at lists.openstack.org\nSent: Tuesday, November 5, 2013 9:23:39 AM\nSubject: Re: [openstack-dev] Improvement of Cinder API wrt	https://bugs.launchpad.net/nova/+bug/1213953\n\nWouldn\'t you still need variable timeouts?  I\'m assuming that copying \nmulti-gig cinder volumes might take a while, even if it\'s local.  (Or \nare you assuming copy-on-write?)\n\nChris\n\nOn 11/05/2013 01:43 AM, Caitlin Bestler wrote:\n> Replication of snapshots is one solution to this.\n>\n> You create a Cinder Volume once. snapshot it. Then replicate to the\n> hosts that need it (this is the piece currently missing). Then you clone\n> there.\n>\n> I will be giving an in an hour in conference session on this and other\n> uses of snapshots in the last time slot Wednesday.\n>\n> On Nov 5, 2013 5:58 AM, \"Solly Ross\" <sross at redhat.com\n> <mailto:sross at redhat.com>> wrote:\n>\n>     So,\n>     There\'s currently an outstanding issue with regards to a Nova\n>     shortcut command that creates a volume from an image and then boots\n>     from it in one fell swoop.  The gist of the issue is that there is\n>     currently a set timeout which can time out before the volume\n>     creation has finished (it\'s designed to time out in case there is an\n>     error), in cases where the image download or volume creation takes\n>     an extended period of time (e.g. under a Gluster backend for Cinder\n>     with certain network conditions).\n>\n>     The proposed solution is a modification to the Cinder API to provide\n>     more detail on what exactly is going on, so that we could\n>     programmatically tune the timeout.  My initial thought is to create\n>     a new column in the Volume table called \'status_detail\' to provide\n>     more detailed information about the current status.  For instance,\n>     for the \'downloading\' status, we could have \'status_detail\' be the\n>     completion percentage or JSON containing the total size and the\n>     current amount copied.  This way, at each interval we could check to\n>     see if the amount copied had changed, and trigger the timeout if it\n>     had not, instead of blindly assuming that the operation will\n>     complete within a given amount of time.\n>\n>     What do people think?  Would there be a better way to do this?\n>\n>     Best Regards,\n>     Solly Ross\n>\n>     _______________________________________________\n>     OpenStack-dev mailing list\n>     OpenStack-dev at lists.openstack.org\n>     <mailto:OpenStack-dev at lists.openstack.org>\n>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<660572483.19717214.1383666048757.JavaMail.root@redhat.com>',NULL),('<1141434704.153.1356307481199.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-24 00:04:41',0,'2012-12-24 00:04:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #84','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/84/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.62 secs:\n    2.53    Kc11TestCase.test_admin_requires_adminness\n    2.27    KcEssex3TestCase.test_admin_requires_adminness\n    2.24    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.07    KcEssex3TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 47.154s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.SWUOQ6d2EQ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/84\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/84/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1289493134.118.1356220919128.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1141673254.95.1384409482844.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-14 06:11:22',0,'2013-11-14 06:11:22',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #57','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/57/changes>\n\n\n\n','<1151880538.92.1384323172933.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<114196092.95505582.1389140786798.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 19:26:26',-18000,'2014-01-08 00:26:26',NULL,'[openstack-dev] [TripleO] Installing from packages\n	in	tripleo-image-elements','\n\n----- Original Message -----\n> From: \"Clint Byrum\" <clint at fewbar.com>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, January 7, 2014 3:23:24 PM\n> Subject: Re: [openstack-dev] [TripleO] Installing from packages in	tripleo-image-elements\n> \n> What would be the benefit of using packages?\n> \n> We\'ve specifically avoided packages because they complect[1] configuration\n> and system state management with software delivery. The recent friction\n> we\'ve seen with MySQL is an example where the packages are not actually\n> helping us, they\'re hurting us because they encode too much configuration\n> instead of just delivering binaries.\n> \n> Perhaps those of us who have been involved a bit longer haven\'t done\n> a good job of communicating our reasons. I for one believe in the idea\n> that image based updates eliminate a lot of the entropy that comes along\n> with a package based updating system. For that reason alone I tend to\n> look at any packages that deliver configurable software as potentially\n> dangerous (note that I think they\'re wonderful for libraries, utilities,\n> and kernels. :)\n\nTo be clear James is talking initially about using packages to build images (not update them at runtime).\n\nIn any case for much the same reason I look at what we do today with the source based pip installs an an entropy bomb:\n\n-multiple venvs in the same image\n-each venv contains its own copies of libraries\n-everything is compiled on the fly\n-due to the above ^^ image builds often fail!!!\n\nI\'d expect that anyone using real packages for OpenStack element has much less entropy on many fronts:\n\n-more control over what is installed\n-faster image build times\n-less duplication\n\nThe cost when using real packages is maintaining them. But once you have that (which we will)... you\'ve got a lot more control over things.\n\n\n> \n> [1] http://www.infoq.com/presentations/Simple-Made-Easy\n> \n> Excerpts from James Slagle\'s message of 2014-01-07 12:01:07 -0800:\n> > Hi,\n> > \n> > I\'d like to discuss some possible ways we could install the OpenStack\n> > components from packages in tripleo-image-elements.  As most folks are\n> > probably aware, there is a \"fork\" of tripleo-image-elements called\n> > tripleo-puppet-elements which does install using packages, but it does\n> > so using Puppet to do the installation and for managing the\n> > configuration of the installed components.  I\'d like to kind of set\n> > that aside for a moment and just discuss how we might support\n> > installing from packages using tripleo-image-elements directly and not\n> > using Puppet.\n> > \n> > One idea would be to add support for a new type (or likely 2 new\n> > types: rpm and dpkg) to the source-repositories element.\n> > source-repositories already knows about the git, tar, and file types,\n> > so it seems somewhat natural to have additional types for rpm and\n> > dpkg.\n> > \n> > A complication with that approach is that the existing elements assume\n> > they\'re setting up everything from source.  So, if we take a look at\n> > the nova element, and specifically install.d/74-nova, that script does\n> > stuff like install a nova service, adds a nova user, creates needed\n> > directories, etc.  All of that wouldn\'t need to be done if we were\n> > installing from rpm or dpkg, b/c presumably the package would take\n> > care of all that.\n> > \n> > We could fix that by making the install.d scripts only run if you\'re\n> > installing a component from source.  In that sense, it might make\n> > sense to add a new hook, source-install.d and only run those scripts\n> > if the type is a source type in the source-repositories configuration.\n> >  We could then have a package-install.d to handle the installation\n> > from the packages type.   The install.d hook could still exist to do\n> > things that might be common to the 2 methods.\n> > \n> > Thoughts on that approach or other ideas?\n> > \n> > I\'m currently working on a patchset I can submit to help prove it out.\n> >  But, I\'d like to start discussion on the approach now to see if there\n> > are other ideas or major opposition to that approach.\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1389125861-sup-6283@clint-HP>',NULL),('<114213532.61.1374904974730.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-27 06:02:54',0,'2013-07-27 06:02:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #299','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/299/>\n\n------------------------------------------\n[...truncated 67 lines...]\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-Wzf0fC/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-Wzf0fC/d2to1-0.2.10/egg-dist-tmp-u9tExk\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-LDizz2/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-LDizz2/setuptools-git-1.0/egg-dist-tmp-A6fBhG\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-tp3F8m/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-tp3F8m/d2to1-0.2.10/egg-dist-tmp-uzPxN3\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-AelpYt/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-AelpYt/setuptools-git-1.0/egg-dist-tmp-8LOYVo\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-6FjuP5/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-6FjuP5/d2to1-0.2.10/egg-dist-tmp-vhb1pk\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.iFiP1klKHp/easy_install-3sBjHu/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.iFiP1klKHp/easy_install-3sBjHu/setuptools-git-1.0/egg-dist-tmp-OQ_mE9\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.iFiP1klKHp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/299\n[SCP] Copying console log.\n\n\n','<205951822.54.1374818550693.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1142476949.17966767.1401020591742.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-25 05:23:11',-25200,'2014-05-25 12:23:11',NULL,'[openstack-dev] [all] Hide CI comments in Gerrit','Hi,\n\nI created a small userscript that allows you to hide CI comments in Gerrit. That way you can read only comments written by humans and hide everything else. I?ve been struggling for a long time to follow discussions on changes with many patch sets because of the CI noise. So I came up with this userscript:\n\nhttps://gist.github.com/rgerganov/35382752557cb975354a\n\nIt adds ?Toggle CI? button at the bottom of the page that hides/shows CI comments. Right now it is configured for Nova CIs, as I contribute mostly there, but you can easily make it work for other projects as well. It supports both the ?old? and ?new? screens that we have.\n\nHow to install on Chrome: open chrome://extensions and drag&drop the script there\nHow to install on Firefox: install Greasemonkey first and then open the script\n\nKnown issues:\n - you may need to reload the page to get the new button\n - I tried to add the button somewhere close to the collapse/expand links but it didn?t work for some reason\n\nHope you will find it useful. Any feedback is welcome :)\n\nThanks,\nRado\n\n\n','<137814279.17966747.1401020507835.JavaMail.root@vmware.com>',NULL),('<114367A2-AE59-4B90-947A-DD56F67900F0@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 18:50:57',0,'2014-04-30 18:50:57',NULL,'[openstack-dev] [Horizon] [UX] Summary of Horizon Usability\n Testing and plan for Summit session','Hi everyone,\nAs Liz mentioned, we did some testing and one of the big findings was that the Launch Instance form had some usability issues. I took a stab at mocking up a launch instance process that addresses some of these issues. You can read the usability findings here<https://wiki.openstack.org/wiki/Horizon-usability-test-findings>.\n\nSo, I know some of you will ask about work that is already being done around improving the launch instance form - here<https://www.youtube.com/watch?v=CO62UUQPTCM> and here<https://blueprints.launchpad.net/horizon/+spec/launch-instance-ux-enhancement>.  That work is represented here too! I took what I felt to be what was best about the current form and best about the new work, addressed the usability issues, and tried to come up with something that wasn?t too different from either of these.\n\nIf you are interested in any of the design thinking/reasoning behind the mockups, go ahead and keep reading below, otherwise, just take a look at the attachment.  Feedback is welcome!\n\nCheers,\nJacki\n\nWhy I did things the way I did:\n\n  *\nI used a multi-step form for a few reasons. 1-The Horizon people are interested in wizard patterns that could be used for launching instances and other step by step workflows. 2-The current launch instance divides the config options into tabs, but users often didn?t notice the tabs until they tried to launch the instance and got an error. The ?*? indicating required fields on each tab confused users as well. Since all but one tab contained required fields, the tabs didn?t do anything to reduce the number of clicks a user had to make in order to complete the form.\n  *   A best practice for wizards is to never reveal specific steps to the user if the number or names of those steps can change.  So, I settled on four steps. Some users might not want to visit all these steps, and this is maybe a flaw. Maybe we can think about a way to allow users to skip steps.\n  *   I decided to stack all fields vertically with labels to the left. I did this because I wanted the layout of form fields to be consistent throughout. This layout is very readable and pretty standard. It saves vertical space too.\n  *   I changed the network selection to checkboxes. Users thought the drag and drop style control was inconsistent with the rest of Horizon.\n  *   Users really liked the graphs that show their quota when they are selecting a flavor. But this didn?t really work with the new layout, so I settled on a different way of presenting the same information. It?s not as visually appealing as the graphs were, but it?s more flexible - could be used throughout Horizon to show quota information on demand and in context.\n  *   I added the ability to create key pairs. This was a big finding from the usability study.\n  *   I did not add the ability to create a network on the fly. Another big finding from the usability study was that users were frustrated by the fact that they had to have at least one network created to launch an instance. However, we know that creating networks is largely an admin task, not an end-user one. So instead, I made it impossible for a user to open up the launch instance form when there are no networks.\n  *   There are more items selected for the user by default.\n     *   Defaults have some advantages: they allow users to progress more quickly through forms. They also reduce the need for complex logic and error messages, because it becomes harder for users to leave something blank.\n     *   The disadvantage to defaults is that the user may not notice a field. Since there will be no validation message forcing their attention onto the field, they might wonder how their instance came to have the configuration that it does.\n     *   Defaults could be problematic for admins who do not want to encourage users to select a pre-defined default. It might mean that we need to allow admins to specify these default values for their environment.\n  *   The flavor selection has been expanded from a drop down to a list with details about the resources associated with each flavor, because we have some indication that users want more details about flavors when they are selecting them. In the current launch instance form, flavor information is available but it?s somewhat disconnected from the flavor selector itself.\n\n\n\n\nOn 04/24/2014 09:10 AM, Liz Blanchard wrote:\nHi All,\n\nOne of the sessions that I proposed for the Horizon track is to review the results that we got from the Usability Test that was run on Horizon in early March. I wanted to share some of the background of this test and the high level results with you all so that we can start the conversation on this list and then continue with agreeing on next steps during Summit. There will be a few follow-ups to this e-mail from myself and Jacki Bauer which will propose some potential solutions to the high priority findings, so be on the look out for those :)\n\n---Quick overview of Usability Testing...What is it? Why do it?---\nUsability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system.\n\n\n---Who was involved? What did we need to do to prepare?---\nA number of user experience engineers from a bunch of different companies got together and helped plan for a usability test that would focus on self-service end users and the ease of use of the Horizon Dashboard as it exists for the Icehouse release. This effort spun off from the Persona work that we\'ve been doing together. Some folks in the group are just getting into contributing to the design of OpenStack and doing a baseline usability test of Horizon was a great introduction to how the usability of the Horizon UI could continue to be improved based on user\'s direct feedback.\n\nWhat we needed to get done before actually jumping into the testing:\n   1) Agree on the goals of the testing.\n   2) Create a screener and send out to the OpenStack community.\n   3) Create a list of tasks that the user would complete and give feedback on during the testing.\n\n---Who we tested?---\n6 people who we considered to be \"self-service end users\" based on their screener responses.\n\n---What were the tasks that were tested?---\n\nScenario 1: Launching an instance\nIndividual Tasks:\n-Create a security key pair.\n-Create a network.\n-Boot from cirros image.\n-Confirm that instance was launched successfully.\n\nScenario 2: Understand how many vCPUs are currently in use vs. how much quota is left.\nIndividual Tasks:\n-Check out Overview Page to review current quota use/limit details.\n\nScenario 3: Take a snapshot of an Instance to save for later use.\nIndividual Tasks:\n-Either Launch an instance successfully, or identify a running instance in the instance view.\n-Choose to take a snapshot of that instance.\n-Confirm that the snapshot was successful.\n\nScenario 4: Launch an instance from a snapshot.\nIndividual Tasks:\n-Choose to either create an instance and boot from a snapshot, or identify a snapshot to create an instance from.\n-Confirm that the instance was started successfully.\n\nScenario 5: Launch an instance that boots from a specific volume.\nIndividual Tasks:\n-Create a volume.\n-Launch an instance using Volume X as a boot source.\n\n---When and how we ran the tests?---\nThese hour long tests were run over the first two weeks of March 2014. We focused on the latest bits that could be seen in the Icehouse release. The moderator (a UX researcher from HP) would ask the questions and the rest of the group would vigourously take notes :) After all of the testing was complete, we spent some time together debriefing and agreeing on the prioritized list of updates that would be best to make to the Horizon UI based on user feedback.\n\n---What were the findings?---\n\nHigh Priority\n* Improve error messages and error message catalog.\n* Fix Launch Instance workflow for end user and power user.\n* Improve informational help information about form fields.\n* Fix terminology. (e.g. launch instance, boot, shutoff, shutdown, etc.)\n* Show details for key pair and network in Launch Instance workflow.\n* Recommend a new Information Architecture.\n\nMedium Priority\n* Create UI guidelines (of best practices) for Developers to use.\n* Improve Online Help.\n* Provide clearer indication the application is working after clicking a button and the application doesn\'t respond immediately.\n* Ensure consistency of network selection. (Drag and drop of networks very inconsistent from the other pieces of the launch instance modal)\n* Create consistency of visualizations and section of action button recommendations on Instance table.\n* Suggest defaults for the forms entry fields.\n* Provide Image information details during image selection.\n\nLow Priority\n* Allow users to edit the network an instance after launching instance.\n* Resolve confusion around the split inline actions button.\n* Explain what the Instance Boot Source field in Create Instance modal.\n* Provide description/high level information about flavors for flavor selection.\n* Make sorting clearer visually.\n* Provide solution for subnet checkbox to improve usability.\n\nNice to Have\n* Provide \"Save as Draft\" option in the wizard.\n* Change security group default name to \"Default security group\".\n\nWell if you\'ve read this far, thank you for your interest in this topic!! We look forward to sharing some design proposals over the next week and continuing the discussion on tackling some of these items at Summit. Please let me know if anyone has any questions or concerns.\n\nBest,\nLiz\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/fda73d40/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Launch Instance.pdf\nType: application/pdf\nSize: 878853 bytes\nDesc: Launch Instance.pdf\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/fda73d40/attachment-0001.pdf>\n\n','<CAH+MsgF-SUL8pkE8Qort=TPmNakPRTVMHmOKCHuYPHf6GM3Y_g@mail.gmail.com>',NULL),('<1143801064.58.1383458540963.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:02:20',0,'2013-11-03 06:02:20',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-keystone-docs-stable-grizzly #38','See <https://jenkins02.openstack.org/job/periodic-keystone-docs-stable-grizzly/38/>\n\n\n\n','<921517168.40.1383372188311.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1145124110.5339443.1415929676006.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 20:47:56',-18000,'2014-11-14 01:47:56',NULL,'[openstack-dev] [oslo][kite] oslo.messaging changes for message\n	security','Hi all,\n\nTo implement kite we need the ability to sign and encrypt the message and the\nmessage data. This needs to happen at a very low level in the oslo.messaging\nstack. The existing message security review\n(https://review.openstack.org/#/c/109806/) isn\'t going to be sufficient. It\nallows us to sign/encrypt only the message data ignoring the information in the\ncontext and not allowing us to sign the message as a whole. It would also\nintercept and sign notifications which is not something that kite can do.\n\nMostly this is an issue of how the oslo.messaging library is constructed. The\nchoice of how data is serialized for transmission (including things like how\nyou arrange context and message data in the payload) is handled individually by\nthe driver layer rather than in a common higher location. All the drivers use\nthe same helper functions for this and so it isn\'t a problem in practice.\n\nEssentially I need a stateful serializing/deserializing object (I need to store\nkeys and hold things like a connection to the kite server) that either extends\nor replaces oslo.messaging._drivers.common.serialize_msg and deserialize_msg\nand their exception counterparts.\n\nThere are a couple of ways I can see to do what I need:\n\n1. Kite becomes a more integral part of oslo.messaging and the marshalling and\nverification code becomes part of the existing RPC path. This is how it was\ninitially proposed, it does not provide a good story for future or alternative\nimplementations. Oslo.messaging would either have a dependency on kiteclient,\nimplement its own ways of talking to the server, or have some hack that imports\nkiteclient if available.\n\n2. Essentially I add a global object loaded from conf to the existing common\nRPC file. Pro: The existing drivers continue to work as today, Con: global\nstate held by a library. However given the way oslo messaging works i\'m not\nreally sure how much of a problem this is. We typically load transport from a\npredefined location in the conf file and we\'re not really in a situation where\nyou might want to construct different transports with different parameters in\nthe same project.\n\n3. I create a protocol object out of the RPC code that kite can subclass and\nthe protocol can be chosen by CONF when the transport/driver is created. This\nstill touches a lot of places as the protocol object would need to be passed to\nall messages, consumers etc. It involves changing the interface of the drivers\nto accept this new object and changes in each of the drivers to work with the\nnew protocol object rather than the existing helpers.\n\n4. As the last option requires changing the driver interface anyway we try and\ncorrect the driver interfaces completely. The driver send and receive functions\nthat currently accept a context and args parameters should only accept a\ngeneric object/string consisting of already marshalled data. The code that\nhandles serializing and deserializing gets moved to a higher level and kite\nwould be pluggable there with the current RPC being default.\n\nNone of these options involve changing the public facing interfaces nor the\nmessages emitted on the wire (when kite is not used).\n\nI\'ve been playing a little with option 3 and I don\'t think it\'s worth it. There\nis a lot of code change and additional object passing that I don\'t think\nimproves the library in general.\n\nBefore I go too far down the path with option 4 I\'d like to hear the thoughts\nof people more familiar with the library.\n\nIs there a reason that the drivers currently handle marshalling rather than the\nRPC layer?\n\nI know there is ongoing talk about evolving the oslo.messaging library, I\nunfortunately didn\'t make it to the sessions at summit. Has this problem been\nraised? How would it affect those talks?\n\nIs there explicit/implicit support for out of tree drivers that would disallow\nchanging these interfaces?\n\nDoes anyone have alternative ideas on how to organize the library for message\nsecurity?\n\nThanks for the help.\n\n\nJamie\n\n\n','<1377391392.5339432.1415929662710.JavaMail.zimbra@redhat.com>',NULL),('<1145561433.21436960.1352097387053.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-05 01:36:27',-18000,'2012-11-05 06:36:27',NULL,'[Openstack-qa] Tempest Boto S3/EC2 tests','Jay,\n\nI have made many modification on the previous version.\nI would really appreciate a little feedback and review.\n\nYou can see the current version of this patch here:\nhttps://github.com/afazekas/tempest/commit/95b09c992bff9143e7808e95b2aac192ce202557\n\nI really need to know at least the base is acceptable, before creating more test cases.\n\nRegards,\nAttila\n\n\n','<1390786968.21435885.1352097071401.JavaMail.root@redhat.com>',NULL),('<1145803392.10.1368945434292.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-19 06:37:14',0,'2013-05-19 06:37:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #39','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/39/>\n\n------------------------------------------\n[...truncated 5051 lines...]\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.01\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.09\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    2.17\n    test_health_monitor_get                                      OK    0.05\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.05\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.05\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.05\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.05\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    2.24\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.00\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.00\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.01\n    test_proxy_request_network_418                               OK    2.28\n    test_proxy_request_network_500                               OK    0.00\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.00\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.01\n    test_main_dont_fork                                          OK    0.01\n    test_run                                                     OK    0.00\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.00\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    0.30\n    test_show_quotas_with_admin                                  OK    0.29\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.30\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    2.51\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_without_admin_forbidden                     OK    0.21\n    test_update_quotas_forbidden                                 OK    0.20\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.21\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.29\n    test_list_quotas_with_admin                                  OK    0.30\n    test_list_quotas_without_admin_forbidden_returns_403         OK    2.67\n    test_quotas_default_values                                   OK    0.20\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.28\n    test_quotas_limit_check                                      OK    0.31\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.21\n    test_quotas_limit_check_with_over_quota                      OK    0.22\n    test_quotas_loaded_bad_returns_404                           OK    0.23\n    test_quotas_loaded_right                                     OK    2.65\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_with_owner_tenant                           OK    0.20\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.22\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    2.87\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.20\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.20\n    test_list_quotas_with_admin                                  OK    0.20\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.31\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.32\n    test_quotas_get_tenant_from_request_context                  OK    0.26\n    test_quotas_limit_check                                      OK    2.66\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    2.56\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.20\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.40\n    test_KillFilter_deleted_exe                                  OK    0.00\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.02\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.37\n    test_health_monitor_delete_with_router_id                    OK    0.32\n    test_health_monitor_delete_without_router_id                 OK    0.29\n    test_health_monitor_update_with_router_id                    OK    3.36\n    test_health_monitor_update_without_router_id                 OK    0.23\n    test_pool_create                                             OK    0.23\n    test_pool_delete_with_router_id                              OK    0.25\n    test_pool_delete_without_router_id                           OK    0.25\n    test_pool_update_with_router_id                              OK    0.23\n    test_pool_update_without_router_id                           OK    0.24\n    test_router_create_no_service_type_id                        OK    0.21\n    test_router_create_with_service_type_id                      OK    0.21\n    test_router_delete                                           OK    0.23\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.24\n    test_vip_create                                              OK    2.68\n    test_vip_delete_with_router_id                               OK    0.30\n    test_vip_delete_without_router_id                            OK    0.30\n    test_vip_update_with_router_id                               OK    0.30\n    test_vip_update_without_router_id                            OK    0.37\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.53\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.44\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.50\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv6_ingress           OK    2.99\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.50\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.54\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.69\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.71\n    test_security_group_rules_for_devices_ipv6_egress            Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.DlMI50wQ6k\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/39\n[SCP] Copying console log.\n\n\n','<1149233907.5.1368858975715.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1146285480.4927621396465282664.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-04-02 19:01:22',0,'2014-04-02 19:01:22',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting April 3, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting April 3, 2014\nHost: Alan Clark\nDate: Thursday, April 3, 2014\nTime: 12:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 925 304 456\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t492868761bcabb4445a785368f17a3fd\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t136b6f7934dde0eb10de6c7296f4e230\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=276215942&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 925 304 456\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t3f8bfe81e7f3af41cc55b2790070c92b\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140402/99d510a5/attachment.html>\n\n',NULL,NULL),('<1146334381.263.1368426728092.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-13 06:32:08',0,'2013-05-13 06:32:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #13','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/13/>\n\n------------------------------------------\n[...truncated 12584 lines...]\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 05839952dc144682a1d920fbfc3a8524 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:60442\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:60442/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (14551) wsgi starting up on http://127.0.0.1:60442/\n\nnova.osapi_compute.wsgi.server: INFO: (14551) accepted (\'127.0.0.1\', 45951)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:50] \"GET /v2 HTTP/1.1\" 204 216 0.001003\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-150cd7b3-0dc3-48be-8a2c-b292934a6805</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (14551) accepted (\'127.0.0.1\', 45952)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b4dc10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b4dc10>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:60442/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:50 14551 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:60442/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:50] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.258209\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 27297d38c9254f6eb6381b2e4495cbd4 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:47587\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:47587/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (14551) wsgi starting up on http://127.0.0.1:47587/\n\nnova.osapi_compute.wsgi.server: INFO: (14551) accepted (\'127.0.0.1\', 51561)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:50] \"GET /v2 HTTP/1.1\" 204 216 0.001113\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-3663a617-8d0c-4cbc-bc51-fa1319ee6baf</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (14551) accepted (\'127.0.0.1\', 51562)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b27850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b27850>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:47587/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     name)\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-13 06:26:51 14551 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:47587/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/May/2013 06:26:51] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.268138\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.JAwMy6Kl71\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/13\n[SCP] Copying console log.\n\n\n','<283198924.248.1368340423673.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<11469578.616.1407731450555.JavaMail.Nick@Nick-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 12:30:51',28800,'2014-08-11 04:30:51',NULL,'[openstack-dev] [oslo.db]A proposal for DB read/write separation','> not sure if I said that :).  I know extremely little about galera.\n\nHi Mike Bayer, I\'m so sorry I mistake you from Mike Wilson in the last post. :-) Also, say sorry to Mike Wilson.\n\n> I?d totally guess that Galera would need to first have SELECTs come from a slave node, then the moment it sees any kind of DML / writing, it transparently switches the rest of the transaction over to a writer node.\n\nYou are totally right.\n\n> \n> @transaction.writer\n> def read_and_write_something(arg1, arg2, ?):\n>     # ?\n> \n> @transaction.reader\n> def only_read_something(arg1, arg2, ?):\n>     # ?\n\nThe first approach that I had in mind is the decorator-based method to separates read/write ops like what you said. To some degree, it is almost the same app-level approach to the master/slave configuration, due to transparency to developers. However, as I stated before, the current approach is merely used in OpenStack. Decorator is more friendly than use_slave_flag or something like that. If ideally transparency cannot be achieved, to say the least, decorator-based app-level switching is a great improvement, compared with the current implementation.\n\n> OK so Galera would perhaps have some way to make this happen, and that\'s great.\n\nIf any Galera expert here, please correct me. At least in my experiment, transactions work in that way.\n\n> this (the word ?integrate?, and what does that mean) is really the only thing making me nervous.\n\nMike, just feel free. What I\'d like to do is to add a django-style routing method as a plus in oslo.db, like:\n\n[database]\n# Original master/slave configuration\nmaster_connection = \nslave_connection = \n\n# Only Support Synchronous Replication\nenable_auto_routing = True\n\n[db_cluster]\nmaster_connection = \nmaster_connection = \n...\nslave_connection = \nslave_connection = \n...\n\nHOWEVER, I think it needs more investigation, so this is why I\'d like to put it in the mailing list in the early stage to raise some discussions in depth. I\'m not a Galera expert. I really appreciate any challenges here.\n\nThanks,\nLi Ma\n\n\n----- Original Message -----\nFrom: \"Mike Bayer\" <mbayer at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: ???, 2014? 8 ? 10? ?? 11:57:47\nSubject: Re: [openstack-dev] [oslo.db]A proposal for DB read/write separation\n\n\nOn Aug 10, 2014, at 11:17 AM, Li Ma <skywalker.nick at gmail.com> wrote:\n\n> \n> How about Galera multi-master cluster? As Mike Bayer said, it is virtually synchronous by default. It is still possible that outdated rows are queried that make results not stable.\n\nnot sure if I said that :).  I know extremely little about galera.\n\n\n> \n> \n> Let\'s move forward to synchronous replication, like Galera with causal-reads on. The dominant advantage is that it has consistent relational dataset support. The disadvantage are that it uses optimistic locking and its performance sucks (also said by Mike Bayer :-). For optimistic locking problem, I think it can be dealt with by retry-on-deadlock. It\'s not the topic here.\n\nI *really* don?t think I said that, because I like optimistic locking, and I?ve never used Galera ;).\n\nWhere I am ignorant here is of what exactly occurs if you write some rows within a transaction with Galera, then do some reads in that same transaction.   I?d totally guess that Galera would need to first have SELECTs come from a slave node, then the moment it sees any kind of DML / writing, it transparently switches the rest of the transaction over to a writer node.   No idea, but it has to be something like that?   \n\n\n> \n> \n> So, the transparent read/write separation is dependent on such an environment. SQLalchemy tutorial provides code sample for it [1]. Besides, Mike Bayer also provides a blog post for it [2].\n\nSo this thing with the ?django-style routers?, the way that example is, it actually would work poorly with a Session that is not in ?autocommit? mode, assuming you?re working with regular old databases that are doing some simple behind-the-scenes replication.   Because again, if you do a flush, those rows go to the master, if the transaction is still open, then reading from the slaves you won?t see the rows you just inserted.    So in reality, that example is kind of crappy, if you?re in a transaction (which we are) you?d really need to be doing session.using_bind(?master?) all over the place, and that is already way too verbose and hardcoded.   I?m wondering why I didn?t make a huge note of that in the post.  The point of that article was more to show that hey, you *can* control it at this level if you want to but you need to know what you?re doing.\n\nJust to put it out there, this is what I think good high/level master/slave separation in the app level (reiterating: *if we want it in the app level at all*) should approximately look like:\n\n@transaction.writer\ndef read_and_write_something(arg1, arg2, ?):\n    # ?\n\n@transaction.reader\ndef only_read_something(arg1, arg2, ?):\n    # ?\n\nthat way there is no awareness of master/slave anything, the underlying system can decide what ?reader? and ?writer? means.   Do in-app switching between two databases, send out some magic signals to some commercial clustering service, have the ?readers? work in ?autocommit? mode, or do nothing, whatever.  The code doesn?t decide this imperatively.    But it isn?t 100% ?transparent?, this small amount of declaration per-method is needed.\n\n\n> \n> What I did is to re-implement it in OpenStack DB API modules in my development environment, using Galera cluster(causal-reads on). It has been running perfectly for more than a week. The routing session manager works well while maintaining data consistency.\n\nOK so Galera would perhaps have some way to make this happen, and that?s great.    My understanding is that people are running Openstack already with Galera, that?s why we?re hitting issues with some of those SELECT..FOR UPDATEs that are being replaced with optimistic approaches as you mention.     But beyond that this isn?t any kind of ?change? to oslo.db or anything else.   Run Openstack with whatever database backend you want, ideally (that is my primary agenda, sorry MySQL vendors!).\n\n\n> Finally, I think if we can integrate it into oslo.db, it is a perfect plus for those who would like to deploy Galera (or other similar technology) as DB backend.\n\nthis (the word ?integrate?, and what does that mean) is really the only thing making me nervous.  If the integration here is the django blog post I have, it?s not going to work with transactions.   Either the system is magical enough that a single transaction can read/write from both sources midway and there is no ?integration? needed, or the transaction has to be declared up front as reader or writer.  Or you don?t use transactions except for writers, which is essentially the same as ?declaration up front?.\n\n> \n> [1] http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#custom-vertical-partitioning\n> [2] http://techspot.zzzeek.org/2012/01/11/django-style-database-routers-in-sqlalchemy/\n> [3] Galera replication method: http://galeracluster.com/products/technology/\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<3CD52A53-FFC5-4974-B0CF-B7777DC6255D@redhat.com>',NULL),('<1147502704.21829330.1413860982465.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-20 23:09:42',-14400,'2014-10-21 03:09:42',NULL,'[openstack-dev] [api] Request Validation - Stoplight','\n\n----- Original Message -----\n> However I don\'t think we should be mandating specific libraries, but we\n> can make recommendations (good or bad) based on actual experience. This\n> will be especially useful to new projects starting up to benefit from\n> the pain other projects have experienced.\n\n\n+1\n\ni think it\'s also important to ensure that these recommendations live in a\nplace that is easy to find. it would be really nice to have example design\nrecipes that are commonly used across projects, but i\'m not sure if that\ngets too far into dictating or mandating certain usage patterns.\n\nregards,\nmike\n\n\n','<20141021102303.40a95040@pingu>',NULL),('<1149219295.33963540.1403862881911.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-27 05:54:41',-14400,'2014-06-27 09:54:41',NULL,'[openstack-dev] [swift] eventual consistency and lost updates','\nHi Swiftsters!\n\nA basic question about swift eventual- versus strong-consistency.\nThe context is potentially using swift as a store for metric data.\n\nSay datapoints {p1, p2, ..., p_i} are stored in a swift object.\nPresumably these data are replicated across the object ring in\nan eventually consistent way.\n\nSay I want to read back this blob and update it with a further\ndatapoint {p_(i+1)}.\n\nBut eventual consistency tells me that I may end up folding my\nnew datapoint into an older version of the object:\n\n  {p1, p2, ..., p_(i-1)}\n\ninstead of the expected:\n\n  {p1, p2, ..., p_i}\n\ni.e. the classic lost update problem.\n\nSo my basic questions are:\n\n * is read-then-update an acknowledged anti-pattern for swift?\n\n * if so, what are the recommended strategies for managing non-\n   static data in swift?\n\n   - e.g. write latest to a fresh object each time, do an async\n     delete on the old\n\n   - store a checksum elsewhere and detect the stale-read case\n\n * are the object metadata (ETag, X-Timestamp specifically)\n   actually replicated in the same eventually-consistent way as\n   the object content?\n\n   (the PUT code[1] suggests data & metadata are stored together,\n    but just wanted to be sure I\'m reading that correctly)\n\nThanks,\nEoghan\n\n[1] https://github.com/openstack/swift/blob/master/swift/obj/server.py#L441-455\n\n\n','<1629652373.33950820.1403860220675.JavaMail.zimbra@redhat.com>',NULL),('<1149233907.5.1368858975715.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-18 06:36:15',0,'2013-05-18 06:36:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #38','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/38/>\n\n------------------------------------------\n[...truncated 5044 lines...]\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.01\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.09\n    test_delete_pool_health_monitor                              OK    2.17\n    test_health_monitor_create                                   OK    0.05\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.05\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.05\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.05\n    test_pool_stats                                              OK    0.05\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    2.27\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.07\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.00\n    test_get_instance_id_router_id_no_match                      OK    0.01\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    2.29\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.00\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.01\n    test_proxy_request_network_409                               OK    0.01\n    test_proxy_request_network_418                               OK    0.01\n    test_proxy_request_network_500                               OK    0.00\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.00\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.30\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.31\n    test_update_quotas_forbidden                                 OK    0.32\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    2.62\n    test_quotas_default_values                                   OK    0.21\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_without_admin_forbidden                     OK    0.22\n    test_update_quotas_forbidden                                 OK    0.25\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.30\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.32\n    test_list_quotas_with_admin                                  OK    0.31\n    test_list_quotas_without_admin_forbidden_returns_403         OK    2.64\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.21\n    test_quotas_limit_check_with_over_quota                      OK    0.22\n    test_quotas_loaded_bad_returns_404                           OK    2.62\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    0.23\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    2.65\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.22\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.22\n    test_quotas_get_tenant_from_request_context                  OK    2.58\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.21\n    test_quotas_limit_check_with_over_quota                      OK    0.22\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    2.53\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.33\n    test_KillFilter_deleted_exe                                  OK    0.01\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.02\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.43\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    3.63\n    test_health_monitor_update_with_router_id                    OK    0.23\n    test_health_monitor_update_without_router_id                 OK    0.23\n    test_pool_create                                             OK    0.23\n    test_pool_delete_with_router_id                              OK    0.25\n    test_pool_delete_without_router_id                           OK    0.25\n    test_pool_update_with_router_id                              OK    0.23\n    test_pool_update_without_router_id                           OK    0.25\n    test_router_create_no_service_type_id                        OK    0.21\n    test_router_create_with_service_type_id                      OK    0.22\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    2.57\n    test_vip_create                                              OK    0.27\n    test_vip_delete_with_router_id                               OK    0.32\n    test_vip_delete_without_router_id                            OK    0.30\n    test_vip_update_with_router_id                               OK    0.27\n    test_vip_update_without_router_id                            OK    0.30\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.44\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.49\n    test_security_group_rules_for_devices_ipv6_egress            Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.1mQb7W7ybm\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/38\n[SCP] Copying console log.\n\n\n','<1115274564.2.1368772644669.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1149258659.0.1380348627720.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-28 06:10:27',0,'2013-09-28 06:10:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-grizzly #34','See <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/34/>\n\n------------------------------------------\n[...truncated 195 lines...]\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/ec2/test_cloud.py\",> line 2275, in test_describe_security_groups_by_id\n    self.cloud.delete_security_group(self.context, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/ec2/cloud.py\",> line 737, in delete_security_group\n    group_id)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 101, in get\n    id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_false\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 231, in test_associate_port_security_enabled_false\n    req, \'1\', body)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 394, in assertRaises\n    self.assertThat(our_callable, matcher)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 406, in assertThat\n    mismatch = matcher.match(matchee)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py\",> line 99, in match\n    mismatch = self.exception_matcher.match(exc_info)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_higherorder.py\",> line 61, in match\n    mismatch = matcher.match(matchee)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 386, in match\n    reraise(*matchee)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/matchers/_exception.py\",> line 92, in match\n    result = matchee()\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 867, in __call__\n    return self._callable_object(*self._args, **self._kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate\ntags: worker-1\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 200, in test_associate\n    self.manager._addSecurityGroup(req, \'1\', body)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: nova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_true\ntags: worker-0\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/api/openstack/compute/contrib/test_quantum_security_groups.py\",> line 215, in test_associate_port_security_enabled_true\n    self.manager._addSecurityGroup(req, \'1\', body)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 448, in _addSecurityGroup\n    context, id, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/api/openstack/compute/contrib/security_groups.py\",> line 430, in _invoke\n    method(context, instance, group_name)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/compute/api.py\",> line 163, in wrapped\n    return func(self, context, target, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/network/security_group/quantum_driver.py\",> line 333, in add_to_instance\n    security_group_id = quantumv20.find_resourceid_by_name_or_id(\nAttributeError: \'module\' object has no attribute \'find_resourceid_by_name_or_id\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-0\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11328 tests in 302.923s\nFAILED (id=0, failures=13, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python27.stable.grizzly.34\nnumpy==1.7.1\noslo.config==1.2.1\nparamiko==1.11.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==2.0.1\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-quantumclient==2.2.4.2\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py27/bin/subunit-1to2\n+ .tox/py27/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_create_delete_security_group\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_by_non_existing_security_group_name\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_disassociate\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_disassociate_by_non_existing_security_group_name\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_describe_security_groups\nnova.tests.api.ec2.test_cloud.CloudTestCaseQuantumProxy.test_describe_security_groups_by_id\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_false\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate\nnova.tests.api.openstack.compute.contrib.test_quantum_security_groups.TestQuantumSecurityGroups.test_associate_port_security_enabled_true\nprocess-returncode\nprocess-returncode\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.MK9yJ8JJTs\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise31\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise31/34\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1150051755.525.1367388374776.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-01 06:06:14',0,'2013-05-01 06:06:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #21','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/21/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-05-01 06:06:10    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:06:10,579 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-01 06:06:10,580 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-01 06:06:10,581 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-01 06:06:10,581 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-01 06:06:10  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-01 06:06:10,582 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:06:10    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:06:10,583 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-01 06:06:10,583 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:06:10,584 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,584 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,587 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.587649\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.587649\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10,588 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,589 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10,589 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,590 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10,591 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.590736\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.590736\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10,592 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,592 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10,593 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:06:10,594 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,594 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,595 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10,596 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.595437\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.595437\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10,596 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,597 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10,598 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:06:10,598 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,599 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,600 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10,601 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.600400\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.600400\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10,601 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,602 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10,602 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:06:10,603 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,604 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,605 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:06:10,606 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:06:10,607 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.606230\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:06:10.606230\', resource_metadata={}) from 0 transformer\n2013-05-01 06:06:10,607 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,608 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10,609 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:06:10,609 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:06:10,610 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:06:10    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.605s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.21\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a89.g69faf22\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a454.gdccbcc8\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.kLLXbfRjP2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/21\n[SCP] Copying console log.\n\n\n','<1818782815.505.1367301924723.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1151393717.543.1367389463302.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-01 06:24:23',0,'2013-05-01 06:24:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #1','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/1/>\n\n------------------------------------------\n[...truncated 12587 lines...]\nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:40684\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:40684/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (7508) wsgi starting up on http://127.0.0.1:40684/\n\nnova.osapi_compute.wsgi.server: INFO: (7508) accepted (\'127.0.0.1\', 36298)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/May/2013 06:19:14] \"GET /v2 HTTP/1.1\" 204 216 0.001052\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-39691d16-ddee-453c-a3de-3eb616605d71</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (7508) accepted (\'127.0.0.1\', 36299)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7d63e90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7d63e90>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:40684/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-01 06:19:14 7508 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:40684/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/May/2013 06:19:14] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.241087\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 0b361e8c0657456d9174f55f127a1660 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:37492\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:37492/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (7508) wsgi starting up on http://127.0.0.1:37492/\n\nnova.osapi_compute.wsgi.server: INFO: (7508) accepted (\'127.0.0.1\', 57093)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/May/2013 06:19:15] \"GET /v2 HTTP/1.1\" 204 216 0.000935\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-5082d8b8-c63a-40c3-8750-b6b393bfe230</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (7508) accepted (\'127.0.0.1\', 57094)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9588350>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9588350>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:37492/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     name)\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-01 06:19:16 7508 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37492/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/May/2013 06:19:16] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.658088\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.e1pIHsEoaU\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/1\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1151449770.9.1386916587470.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:36:27',0,'2013-12-13 06:36:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-grizzly/5/>\n\n------------------------------------------\n[...truncated 7126 lines...]\n2013-12-13 06:35:55 + local file=/etc/cinder/cinder.conf\n2013-12-13 06:35:55 + local section=DEFAULT\n2013-12-13 06:35:55 + local option=secure_delete\n2013-12-13 06:35:55 + local line\n2013-12-13 06:35:55 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-13 06:35:55 + line=\n2013-12-13 06:35:55 + \'[\' -n \'\' \']\'\n2013-12-13 06:35:55 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-13 06:35:55 secure_delete = False\n2013-12-13 06:35:55 \' /etc/cinder/cinder.conf\n2013-12-13 06:35:55 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-12-13 06:35:55 + local file=/etc/cinder/cinder.conf\n2013-12-13 06:35:55 + local section=DEFAULT\n2013-12-13 06:35:55 + local option=volume_clear\n2013-12-13 06:35:55 + local value=none\n2013-12-13 06:35:55 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-12-13 06:35:55 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-12-13 06:35:55 + local file=/etc/cinder/cinder.conf\n2013-12-13 06:35:55 + local section=DEFAULT\n2013-12-13 06:35:55 + local option=volume_clear\n2013-12-13 06:35:55 + local line\n2013-12-13 06:35:55 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-13 06:35:55 + line=\n2013-12-13 06:35:55 + \'[\' -n \'\' \']\'\n2013-12-13 06:35:55 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-13 06:35:55 volume_clear = none\n2013-12-13 06:35:55 \' /etc/cinder/cinder.conf\n2013-12-13 06:35:55 + \'[\' False == True \']\'\n2013-12-13 06:35:55 + \'[\' default == XenAPINFS \']\'\n2013-12-13 06:35:55 + \'[\' default == sheepdog \']\'\n2013-12-13 06:35:55 + is_service_enabled quantum\n2013-12-13 06:35:55 + services=quantum\n2013-12-13 06:35:55 + for service in \'${services}\'\n2013-12-13 06:35:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-12-13 06:35:57 + return 0\n2013-12-13 06:35:57 + install_quantum\n2013-12-13 06:35:57 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-12-13 06:35:57 + [[ False = \\T\\r\\u\\e ]]\n2013-12-13 06:35:57 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-12-13 06:35:57 + GIT_DEST=/opt/stack/new/neutron\n2013-12-13 06:35:57 + GIT_REF=stable/grizzly\n2013-12-13 06:35:57 + echo stable/grizzly\n2013-12-13 06:35:57 + egrep -q \'^refs\'\n2013-12-13 06:35:57 + [[ ! -d /opt/stack/new/neutron ]]\n2013-12-13 06:35:57 + [[ \'\' == \\y\\e\\s ]]\n2013-12-13 06:35:57 + setup_develop /opt/stack/new/neutron\n2013-12-13 06:35:57 + [[ False = True ]]\n2013-12-13 06:35:57 + SUDO_CMD=sudo\n2013-12-13 06:35:57 + cd /opt/stack/new/neutron\n2013-12-13 06:35:57 + python setup.py egg_info\n2013-12-13 06:35:57 running egg_info\n2013-12-13 06:35:57 creating quantum.egg-info\n2013-12-13 06:35:57 writing requirements to quantum.egg-info/requires.txt\n2013-12-13 06:35:57 writing quantum.egg-info/PKG-INFO\n2013-12-13 06:35:57 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-13 06:35:57 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-13 06:35:57 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-13 06:35:57 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-13 06:35:57 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-13 06:35:57 reading manifest template \'MANIFEST.in\'\n2013-12-13 06:35:57 warning: no files found matching \'AUTHORS\'\n2013-12-13 06:35:57 warning: no files found matching \'ChangeLog\'\n2013-12-13 06:35:57 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-13 06:35:57 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-13 06:35:57 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-13 06:35:57 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-13 06:35:57 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-12-13 06:35:57 + raw_links=\n2013-12-13 06:35:57 ++ echo\n2013-12-13 06:35:57 ++ xargs\n2013-12-13 06:35:57 + depend_links=\n2013-12-13 06:35:57 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-12-13 06:35:57 ++ echo \'-r *-info/requires.txt\'\n2013-12-13 06:35:57 + require_file=\'-r *-info/requires.txt\'\n2013-12-13 06:35:57 + pip_install -r quantum.egg-info/requires.txt\n2013-12-13 06:35:57 + [[ False = \\T\\r\\u\\e ]]\n2013-12-13 06:35:57 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-12-13 06:35:57 + [[ -z deb ]]\n2013-12-13 06:35:57 + [[ False = True ]]\n2013-12-13 06:35:57 + SUDO_PIP=sudo\n2013-12-13 06:35:57 ++ get_pip_command\n2013-12-13 06:35:57 ++ is_fedora\n2013-12-13 06:35:57 ++ [[ -z Ubuntu ]]\n2013-12-13 06:35:57 ++ \'[\' Ubuntu = Fedora \']\'\n2013-12-13 06:35:57 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-12-13 06:35:57 ++ \'[\' Ubuntu = CentOS \']\'\n2013-12-13 06:35:57 ++ which pip\n2013-12-13 06:35:57 + CMD_PIP=/usr/local/bin/pip\n2013-12-13 06:35:57 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-12-13 06:35:57 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-12-13 06:35:57 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-12-13 06:35:58 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:58   Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-12-13 06:35:58   Running setup.py egg_info for package python-quantumclient\n2013-12-13 06:35:58     [pbr] Processing SOURCES.txt\n2013-12-13 06:35:58     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-12-13 06:35:58     \n2013-12-13 06:35:58     [pbr] In git context, generating filelist from git\n2013-12-13 06:35:58     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-13 06:35:58 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-12-13 06:35:58 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-12-13 06:35:58 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-12-13 06:35:58 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:58 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-12-13 06:35:58   Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fa%2Falembic%2Falembic-0.6.1.tar.gz\n2013-12-13 06:35:58   Running setup.py egg_info for package alembic\n2013-12-13 06:35:59     \n2013-12-13 06:35:59     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-13 06:35:59     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-13 06:35:59     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-13 06:35:59     no previously-included directories found matching \'docs/build/output\'\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:59 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-13 06:35:59   Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FM%2FMako%2FMako-0.9.0.tar.gz\n2013-12-13 06:35:59   Running setup.py egg_info for package Mako\n2013-12-13 06:35:59     \n2013-12-13 06:35:59     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-13 06:35:59     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-13 06:35:59     warning: no files found matching \'ez_setup.py\'\n2013-12-13 06:35:59     no previously-included directories found matching \'doc/build/output\'\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-novaclient->-r quantum.egg-info/requires.txt (line 19))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-13 06:35:59 Installing collected packages: python-quantumclient, alembic, Mako\n2013-12-13 06:35:59   Running setup.py install for python-quantumclient\n2013-12-13 06:35:59     [pbr] Reusing existing SOURCES.txt\n2013-12-13 06:35:59     Installing quantum script to /usr/local/bin\n2013-12-13 06:35:59   Running setup.py install for alembic\n2013-12-13 06:35:59     \n2013-12-13 06:35:59     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-13 06:35:59     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-13 06:35:59     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-13 06:35:59     no previously-included directories found matching \'docs/build/output\'\n2013-12-13 06:35:59     Installing alembic script to /usr/local/bin\n2013-12-13 06:35:59   Running setup.py install for Mako\n2013-12-13 06:35:59     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-12-13 06:35:59     \n2013-12-13 06:35:59     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-13 06:35:59     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-13 06:35:59     warning: no files found matching \'ez_setup.py\'\n2013-12-13 06:35:59     no previously-included directories found matching \'doc/build/output\'\n2013-12-13 06:35:59     changing mode of /usr/local/bin/mako-render to 755\n2013-12-13 06:35:59 Successfully installed python-quantumclient alembic Mako\n2013-12-13 06:35:59 Cleaning up...\n2013-12-13 06:35:59 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-12-13 06:35:59 running develop\n2013-12-13 06:35:59 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-12-13 06:35:59 /usr/bin/python -E -c pass\n2013-12-13 06:35:59 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-12-13 06:35:59 running egg_info\n2013-12-13 06:35:59 writing requirements to quantum.egg-info/requires.txt\n2013-12-13 06:35:59 writing quantum.egg-info/PKG-INFO\n2013-12-13 06:35:59 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-13 06:35:59 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-13 06:35:59 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-13 06:35:59 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-13 06:35:59 reading manifest template \'MANIFEST.in\'\n2013-12-13 06:35:59 warning: no files found matching \'AUTHORS\'\n2013-12-13 06:35:59 warning: no files found matching \'ChangeLog\'\n2013-12-13 06:35:59 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-13 06:35:59 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-13 06:35:59 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-13 06:35:59 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-13 06:35:59 running build_ext\n2013-12-13 06:35:59 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-12-13 06:35:59 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-12-13 06:35:59 Installing quantum-debug script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-nec-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-ryu-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-l3-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-db-manage script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-metadata-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-server script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-12-13 06:35:59 Installing quantum-rootwrap script to /usr/local/bin\n2013-12-13 06:35:59 \n2013-12-13 06:35:59 Installed /opt/stack/new/neutron\n2013-12-13 06:35:59 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-12-13 06:35:59 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-12-13 06:35:59 ++ failed\n2013-12-13 06:35:59 ++ local r=1\n2013-12-13 06:35:59 +++ jobs -p\n2013-12-13 06:35:59 ++ kill\n2013-12-13 06:35:59 ++ set +o xtrace\n2013-12-13 06:35:59 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-12-13-063320\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-848624-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-848624.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az1-848624/5/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<912779648.68.1386828331109.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1151460535.5861277.1390416361325.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 13:46:01',-18000,'2014-01-22 18:46:01',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology\n	Revival	#1	-	Roles','\n\n----- Original Message -----\n> Oh dear user... :)\n> \n> I\'ll step a little bit back. We need to agree if we want to name\n> concepts one way in the background and other way in the UI for user (did\n> we already agree on this point?). We all know pros and cons. And I will\n> still fight for users to get global infrastructure terminology  (e.g. he\n> is going to define Node Profiles instead of Flavors). Because I received\n\nJarda, sidepoint - could you explain again what the attributes of a node profile\nare?  Beyond the Flavor, does it also define an image. . . ?\n\nMainn\n\n\n> a lot of negative feedback on mixing overcloud terms into undercloud,\n> confusion about overcloud/undercloud term itself, etc. If it would be\n> easier for developers to name the concepts in the background differently\n> then it\'s fine - we just need to talk about 2 terms per concept then.\n> And I would be a bit afraid of schizophrenia...\n> \n> \n> On 2014/22/01 15:10, Tzu-Mainn Chen wrote:\n> > That\'s a fair question; I\'d argue that it *should* be resources.  When we\n> > update an overcloud deployment, it\'ll create additional resources.\n> \n> Honestly it would get super confusing for me, if somebody tells me - you\n> have 5 compute resources. (And I am talking from user\'s world, not from\n> developers one). But resource itself can be anything.\n> \n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52DFE996.2010405@redhat.com>',NULL),('<1151664728.828163.1389965670318.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 14:34:30',3600,'2014-01-17 13:34:30',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS and\n	Libra','Hi all,\n\nI\'ve been looking at Neutron default LBaaS provider using haproxy, and while it\'s working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy implementation in Neutron seems to continue to evolve (like with https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I\'m wondering why we can\'t leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example?\n\nThanks,\n\n-- \nThomas\n\n\n','<1638256261.827474.1389965263019.JavaMail.root@enovance.com>',NULL),('<1151880538.92.1384323172933.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-13 06:12:52',0,'2013-11-13 06:12:52',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #56','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/56/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x58449d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x58449d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e2cf90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e2cf90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-2030846a-7403-49ba-805a-bf3616df9033\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:12:18Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'18\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:12:18Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'18\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2013-11-15T06:12:18+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'18\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'15\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2013-11-15T06:12:18-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'18\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'15\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2013-11-16T06:12:18Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'18\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'16\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'16\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6486050>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x28c36d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 73.21 secs:\n    15.72    TestGlanceControl.test_bouncing\n    14.93    TestScrubber.test_delayed_delete\n    14.30    TestGlanceControl.test_reload\n    14.20    TestBinGlanceCacheManage.test_queue\n    14.05    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 932 tests in 618.115s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-56\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ZzpJ9jFMei\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/56\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/56/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-5/56\n[SCP] Copying console log.\n\n\n','<1709100695.85.1384063801736.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1153105059.43741863.1377697202966.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-28 06:40:02',-25200,'2013-08-28 13:40:02',NULL,'[openstack-dev] [Nova] Frustrations with review wait times','tl;dr at the end... I can ramble on a bit.\n\nI agree with Daniel.\n\nI\'m not a core reviewer, but I\'m trying to think like one. Over the last few weeks I\'ve divested myself of almost all coding tasks, instead trying to increase the size of the community that is actively contributing to my area of expertise. I have indeed gone batty! I\'ve caught myself a few times, and the frustration of feeling like I couldn\'t contribute code even if I wanted to is getting to be a bit too much.\n\nThe common refrain I\'ve heard is, \"That\'s OpenSource\" as if this is a natural state of affairs for OpenSource projects. I\'ve been either on or around OpenSource projects for nearly 20 years at this point and I really feel this doesn\'t have to be the case. Any project is doomed to have an internal structure that mirrors the organization that maintains it. That means software beyond a certain scale becomes part engineering and part state-craft.\n\nIn OpenSource projects that I have worked on recently, the way scale was handled was to break up the project into pieces small enough for teams of 1 to 5 to handle. The core framework developers worked on exposing API to the plugin developers. Each plugin developer would then focus on how their plugin could expose both additional API and leverage framework API. Feedback went from the application developers to the plugin developers and up to the core developers. This whole divide-and-conquer strategy was aided by the fact that we could lean heavily on a custom dependency management and code/binary distribution system leveraged inside the framework itself. It meant that package structure and distribution could be controlled by the community directly to suit its needs. That makes a powerful combination for building a flexible system but requires a fair amount of infrastructure in code and hardware.\n\nIt wasn\'t a perfect solution. This strategy meant that an application or deployment became the coordination of plugins mixed at run-time. While efforts were made to test common combinations, it was impossible to test all combinations. That often meant people in the field were using combinations that nobody on official teams had ever considered. Because the plugins weren\'t on the same release cycle as the core framework (and even in different code repositories and release infrastructures) a plugin could release weekly or once every few years depending on its needs and sub-community.\n\nThere is a separate dysfunction you\'ll see if you go down this path. Core API must necessarily lead plugin implementation ... which means you sometimes get nonsense API with no backing. To solve this a few plugins are deemed \"core\" plugins and march in-step with the API release cycle. Then there\'s the added burden of longer backward compatibility cycles that necessarily stretch longer and longer leaving deprecated API lying around for years as plugin developers are coaxed into leaving them behind (and subsequent plugin users are coaxed to upgrade). Some things slow down while others speed up. The core API\'s evolution slows, the plugin/driver speeds up. Is that a fair trade off? It\'s a judgement call. No right answer.\n\nIn the end you trade one kind of problem for another and one kind of coordination for another. There\'s no clean answer that just works for this kind of problem and its why we have so many different kinds of governments in the world. Because, ultimately, that\'s what human coordination becomes if you don\'t watch out and \"one size does not fit all\".\n\nBased on my experiences this last cycle, I think nova is pretty well broken down already. Each driver is practically its own little group, the scheduler is surprisingly well fenced off, as are cells. As for our sub-team I think we could have moved much faster if we had been able to approve our own driver blueprints some of which have been in review since May and others which have 30+ revisions updated every few days hoping for attention. It\'s part of why I moved to watching over people\'s work instead of doing my own and I now spend most of my time giving feedback to reviews other people are working on and seeking out expert opinions on other people\'s efforts. \n\nIt\'s not a pleasant place to be and every time I pick up something to work on I either get pulled away or someone else picks up the job and finishes before I can even get started. I imagine this is much like what it is to be a core developer and that this contest of interest is the same strain the core-reviewers feel. You end up picking your own work and neglecting others or falling on the sword so other people can do their work and doing none of your own. Frankly, I don\'t want to use this strategy next cycle because it is far too unsatisfying for me.\n\nBTW:\nAnyone interested in this on an academic level, most of these ideas I have are from vague recollections of college readings of the work of W. Edwards Deming, Coase theorem, and more humorously and directly: Conway\'s law. But, I don\'t do that for a living so I may not understand it too well. Mostly, I was interested in how to coordinate large numbers of developers.\n\ntl;dr please don\'t create a reviewer caste (it\'s not fun), break the project into pieces, give the pieces autonomy... for me, that tends to be more fun.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"Daniel P. Berrange\" <berrange at redhat.com>\n> Cc: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, August 28, 2013 6:51:22 AM\n> Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times\n> \n> On 28 August 2013 22:39, Daniel P. Berrange <berrange at redhat.com> wrote:\n> \n> > No, IIUC, Joshua was suggesting that core team members spend one cycle\n> > doing reviews only, with no coding, and then reverse for the next cycle.\n> > That is just far too coarse/crude. Core team members need to be free to\n> > balance their time between reviews and coding work on an ongoing basis,\n> > just as any other member of the community can.\n> \n> Oh! Yes, thats way too heavy.\n> \n> I do wonder about tweaking the balance more [or scaling the review\n> team :)], but only-reviews would drive anyone batty.\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<CAJ3HoZ0v9aPHyUMhcBnpjNqpaGie8YqxYvEvSYHEmCtzgu3T3A@mail.gmail.com>',NULL),('<1154020949.82944638.1381354007210.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-10-09 14:26:47',-25200,'2013-10-09 21:26:47',NULL,'[OpenStack-Infra] Third Party Testing: ServiceAccount for posting\n	reviews','Hi Admin, \n\nHere at vmware we have setup a Jenkins CI environment based on Gerrit Plugin and would like to post reviews. Could you please create a dedicated account? \n\nAccountName: \" SmokeSignal \" \nPublic key: <Attached> \n\nPlease let me know if you need any other information. \n\nThanks \nSreeram \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131009/50829e04/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: SmokeSignal.pub\nType: application/octet-stream\nSize: 393 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131009/50829e04/attachment.obj>\n\n','<1010175615.82910835.1381352253586.JavaMail.root@vmware.com>',NULL),('<1154130905.9238263.1405023709216.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 16:21:49',-14400,'2014-07-10 20:21:49',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n> > One of the issues that has been raised in the recent discussions with\n> > the QA team about branchless Tempest relates to some legacy defects\n> > in the OpenStack notification system.\n> \n> Got links to specifics? I thought the consensus was that there was a\n> contract here which we need to maintain, so I\'d be curious where that\n> broke down.\n\nWell I could go digging in the LP fossil-record for specific bugs, but\nit\'s late, so for now I\'ll simply appeal to anecdata and tribal memory\nof ceilometer being broken by notification changes on the nova side.  \n\n> Versioning and ability to newer contract versions would be good too, but\n> in the absence of such things we should maintain backwards compat.\n\nYes, I think that was the aspiration, but not always backed up by practice\nin reality.\n\nCheers,\nEoghan\n\n\n','<1405012757.27662.72.camel@sorcha>',NULL),('<1154323697.10858.1363122676091.JavaMail.nobody@jsj2tc005.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-03-12 21:11:16',0,'2013-03-12 21:11:16',NULL,'[OpenStack Foundation] Meeting invitation: OpenStack Incubator\n	Update Committee','\nHello Foundation Mailing List,\n\nAlan Clark invites you to attend this online meeting.\n\nTopic: OpenStack Incubator Update Committee\nDate: Thursday, March 14, 2013\nTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\nMeeting Number: 928 841 895\nMeeting Password: (This meeting does not require a password.)\n\n\n-------------------------------------------------------\nTo join the online meeting (Now from mobile devices!)\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/j.php?ED=220036982&UID=1539593032&RT=MiM0\n2. If requested, enter your name and email address.\n3. If a password is required, enter the meeting password: (This meeting does not require a password.)\n4. Click \"Join\".\n\nTo view in other time zones or languages, please click the link:\nhttps://openstack.webex.com/openstack/j.php?ED=220036982&UID=1539593032&ORT=MiM0\n\n-------------------------------------------------------\nTo join the audio conference only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code.\nCall-in toll number (US/Canada): 1-650-479-3207\nCall-in toll-free number (US/Canada): 1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada): 1-855-244-8681 \nCall-in toll number (US/Canada): 1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=MC&ED=220036982&tollFree=1\nToll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\n\nAccess code:928 841 895\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/mc\n2. On the left navigation bar, click \"Support\".\n\nYou can contact me at:\naclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/j.php?ED=220036982&UID=1539593032&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAApsLX-WQ0eqOYWsRqr4gKG/G/m0V7w-9VVmguAhP2ssN&RT=MiM0\n\nThe playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://openstack.webex.com/openstack/systemdiagnosis.php. \n\nSign up for a free trial of WebEx\nhttp://www.webex.com/go/mcemfreetrial\n\nhttp://www.webex.com\n\nCCP:+16504793207x928841895# \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130312/6db1d16f/attachment.html>\n\n',NULL,NULL),('<1154493820.52126407.1351788186780.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 12:43:06',-14400,'2012-11-01 16:43:06',NULL,'[openstack-dev] [ceilometer] alternative publication conduits','\nFYI relevant blueprints:\n\n  https://blueprints.launchpad.net/ceilometer/+spec/multi-publisher\n  https://blueprints.launchpad.net/ceilometer/+spec/publisher-counters-frequency\n\nCheers,\nEoghan\n\n> Hi Ceilo Folks,\n> \n> TL;DR: just wanted to get feedback on some initial ideas on how\n> we might accommodate different conduits of publication from the\n> ceilo pollsters and notification handlers.\n> \n> Currently, we\'re obviously hard-coded to always publish via the\n> message bus, so the idea is to support alternative/additional\n> publication routes, according to the following outline:\n> \n>  - a ceilo notification handler or pollster can be associated\n>    via config with a chain of zero or more Publishers\n> \n>  - each Publisher knows now to emit their representation over some\n>    conduit (AMQP notification, CW PutMetricData call, statsd UDP\n>    packet, or whatever)\n> \n>  - a ceilometer notification handler or pollster provides a\n>    Transformer corresponding to each of its Publishers, which\n>    knows how to transform domain-specific raw data into the\n>    relevant representation\n> \n>  - the batching of transformer output is up to the Publisher\n> \n>  - each Publisher has an independent frequency, so not all\n>    Publishers are called to publish every measurement\n> \n> So for example the compute.libvirt.DiskIOPollster would provide a\n> transformer to map the raw disk stats reported by libvirt into\n> DiskWriteOps, DiskWriteBytes, DiskReadOps & DiskReadBytes metric\n> datapoints for CW, also indicating that this should be published\n> very minute. This CWPublisher would handle batching these data\n> as a single PutMetricData call.\n> \n> The DiskIOPollster would also provide a second Transformer to\n> mediate between the raw stats format and the ceilo Counter\n> representation for metering.  Additionally, this second Publisher\n> could be configured with a longer period (as befits metering data\n> likely to be consumed by a billing engine).\n> \n> Now the frequency aspect is a bit awkward. For notifications,\n> the frequency of the \"exists\" style of usage audit is out of our\n> hands, depending usually on the configuration of the emitter\n> (e.g. the nova instance_usage_audit_period config). Whereas ceilo\n> config direct controls only the frequency of polling. So one idea\n> would be for a publisher\'s frequency only to impact on the periods\n> under ceilo control - i.e. we\'d accept and publish notifications\n> whenever we get them, whereas the polling cycle would be determined\n> by the greatest common divisor of all the configured publisher\n> periods for each set of related pollsters (the config would probably\n> have to be restricted so to ensure a sane GCD).\n> \n> Also, I\'m assuming that an alternative publication route would\n> generally be used when the target endpoint is not the ceilo collector\n> & metering store ... i.e. non-standard publisher would most often\n> be used in order to hive off the data to an alternative endpoint\n> or store, such as a CW metrics store, or say to be dumped as RRD\n> files to be consumed by graphite.\n> \n> Thoughts?\n> \n> Cheers,\n> Eoghan\n\n\n','<1613389202.39441675.1351258420226.JavaMail.root@redhat.com>',NULL),('<1154721220.22997722.1402315512013.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 08:05:12',-14400,'2014-06-09 12:05:12',NULL,'[openstack-dev] [openstack-tc] use of the word certified','\n\n> On 9 June 2014 09:44, Eoghan Glynn <eglynn at redhat.com> wrote:\n> \n> > Since \"certification\" seems to be quite an overloaded term\n> > already, I wonder would a more back-to-basics phrase such as\n> > \"quality assured\" better capture the Cinder project\'s use of\n> > the word?\n> >\n> > It does exactly what it says on the tin ... i.e. captures the\n> > fact that a vendor has run an agreed battery of tests against\n> > their driver and the harness has reported green-ness with a\n> > meaning that is well understood upstream (as the Tempest test\n> > cases are in the public domain).\n> \n> \n> I think \'quality-assured\' makes a far stronger statement than\n> \'certified\'.\n\nHmmm, what kind of statement is made by the title of the program\nunder which the Tempest harness falls:\n\n  https://github.com/openstack/governance/blob/master/reference/programs.yaml#L247\n\nThe purpose of Quality Assurance is to assure quality, no?\n\nSo essentially anything that passes such QA tests, has had its\nquality assured in a well-understood sense?\n\n> \'Certified\' indicated that some configuration has been\n> shown to work for for some set of feature, and some organisation is\n> attesting to the fact that is true. This is /exactly/ what the cinder\n> team is attesting to, and this program was bought in\n> _because_a_large_number_of_drivers_didn\'t_work_in_the_slightest_.\n> Since it is the cinder team who are going to get up fielding support\n> for cinder code, and the cinder team who\'s reputation is on the line\n> over the quality of cinder code, I think we are exactly the people who\n> can design a certification program, and that is exactly what we have\n> done.\n\nSure, no issue at all with the Cinder team being best placed to\njudge what works and what doesn\'t in terms of Cinder backends.\n\nJust gently suggesting that due to the terminology-overload, it\nmight be wise to choose a term with fewer connotations.\n\nCheers,\nEoghan\n\n\n','<CAOyZ2aFNHBXH_kw32pmq40xoOr2S4J3kD3=HrJuJ_1K7uf+5kw@mail.gmail.com>',NULL),('<1154775506.863305.1346102557483.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-27 14:22:37',-25200,'2012-08-27 21:22:37',NULL,'[openstack-dev] [Openstack] Discussion about where to put\n database for bare-metal provisioning (review 10726)','\n?Michael,\n\n?I think you mean \"compute_node hostname\" as \'hypervisor_hostname\' field in the \'compute_node\' table.\nWhat do you mean by \"service hostname\"?\nI don\'t see such field in the \'service\' table in the database.\nIs it in some other table?\nOr do you suggest adding \'service_hostname\' field in the \'service\' table?\n\n?Thanks,\n?David\n\n----- Original Message -----\n> openstack-bounces+mjfork=us.ibm.com at lists.launchpad.net wrote on\n> 08/27/2012 02:58:56 PM:\n> \n> > From: David Kang <dkang at isi.edu>\n> > To: Vishvananda Ishaya <vishvananda at gmail.com>,\n> > Cc: OpenStack Development Mailing List <openstack-\n> > dev at lists.openstack.org>, \"openstack at lists.launchpad.net \\\n> > (openstack at lists.launchpad.net\\)\" <openstack at lists.launchpad.net>\n> > Date: 08/27/2012 03:06 PM\n> > Subject: Re: [Openstack] [openstack-dev] Discussion about where to\n> > put database for bare-metal provisioning (review 10726)\n> > Sent by: openstack-bounces+mjfork=us.ibm.com at lists.launchpad.net\n> >\n> >\n> > Hi Vish,\n> >\n> > I think I understand your idea.\n> > One service entry with multiple bare-metal compute_node entries are\n> > registered at the start of bare-metal nova-compute.\n> > \'hypervisor_hostname\' must be different for each bare-metal machine,\n> > such as \'bare-metal-0001.xxx.com\', \'bare-metal-0002.xxx.com\', etc.)\n> > But their IP addresses must be the IP address of bare-metal nova-\n> > compute, such that an instance is casted\n> > not to bare-metal machine directly but to bare-metal nova-compute.\n> \n> I believe the change here is to cast out the message to the\n> <topic>.<service-hostname>. Existing code sends it to the compute_node\n> hostname (see line 202 of nova/scheduler/filter_scheduler.py,\n> specifically host=weighted_host.host_state.host). Changing that to\n> cast to the service hostname would send the message to the bare-metal\n> proxy node and should not have an effect on current deployments since\n> the service hostname and the host_state.host would always be equal.\n> This model will also let you keep the bare-metal compute node IP in\n> the compute node table.\n> \n> > One extension we need to do at the scheduler side is using (host,\n> > hypervisor_hostname) instead of (host) only in host_manager.py.\n> > \'HostManager.service_state\' is { <host> : { <service > : { cap k : v\n> > }}}.\n> > It needs to be changed to { <host> : { <service> : {\n> > <hypervisor_name> : { cap k : v }}}}.\n> > Most functions of HostState need to be changed to use (host,\n> > hypervisor_name) pair to identify a compute node.\n> \n> Would an alternative here be to change the top level \"host\" to be the\n> hypervisor_hostname and enforce uniqueness?\n> \n> > Are we on the same page, now?\n> >\n> > Thanks,\n> > David\n> >\n> > ----- Original Message -----\n> > > Hi David,\n> > >\n> > > I just checked out the code more extensively and I don\'t see why\n> > > you\n> > > need to create a new service entry for each compute_node entry.\n> > > The\n> > > code in host_manager to get all host states explicitly gets all\n> > > compute_node entries. I don\'t see any reason why multiple\n> > > compute_node\n> > > entries can\'t share the same service. I don\'t see any place in the\n> > > scheduler that is grabbing records by \"service\" instead of by\n> > > \"compute\n> > > node\", but if there is one that I missed, it should be fairly easy\n> > > to\n> > > change it.\n> > >\n> > > The compute_node record is created in the\n> > > compute/resource_tracker.py\n> > > as of a recent commit, so I think the path forward would be to\n> > > make\n> > > sure that one of the records is created for each bare metal node\n> > > by\n> > > the bare metal compute, perhaps by having multiple\n> > > resource_trackers.\n> > >\n> > > Vish\n> > >\n> > > On Aug 27, 2012, at 9:40 AM, David Kang <dkang at isi.edu> wrote:\n> > >\n> > > >\n> > > > Vish,\n> > > >\n> > > > I think I don\'t understand your statement fully.\n> > > > Unless we use different hostnames, (hostname,\n> > > > hypervisor_hostname)\n> > > > must be the\n> > > > same for all bare-metal nodes under a bare-metal nova-compute.\n> > > >\n> > > > Could you elaborate the following statement a little bit more?\n> > > >\n> > > >> You would just have to use a little more than hostname. Perhaps\n> > > >> (hostname, hypervisor_hostname) could be used to update the\n> > > >> entry?\n> > > >>\n> > > >\n> > > > Thanks,\n> > > > David\n> > > >\n> > > >\n> > > >\n> > > > ----- Original Message -----\n> > > >> I would investigate changing the capabilities to key off of\n> > > >> something\n> > > >> other than hostname. It looks from the table structure like\n> > > >> compute_nodes could be have a many-to-one relationship with\n> > > >> services.\n> > > >> You would just have to use a little more than hostname. Perhaps\n> > > >> (hostname, hypervisor_hostname) could be used to update the\n> > > >> entry?\n> > > >>\n> > > >> Vish\n> > > >>\n> > > >> On Aug 24, 2012, at 11:23 AM, David Kang <dkang at isi.edu> wrote:\n> > > >>\n> > > >>>\n> > > >>> Vish,\n> > > >>>\n> > > >>> I\'ve tested your code and did more testing.\n> > > >>> There are a couple of problems.\n> > > >>> 1. host name should be unique. If not, any repetitive updates\n> > > >>> of\n> > > >>> new\n> > > >>> capabilities with the same host name are simply overwritten.\n> > > >>> 2. We cannot generate arbitrary host names on the fly.\n> > > >>> The scheduler (I tested filter scheduler) gets host names from\n> > > >>> db.\n> > > >>> So, if a host name is not in the \'services\' table, it is not\n> > > >>> considered by the scheduler at all.\n> > > >>>\n> > > >>> So, to make your suggestions possible, nova-compute should\n> > > >>> register\n> > > >>> N different host names in \'services\' table,\n> > > >>> and N corresponding entries in \'compute_nodes\' table.\n> > > >>> Here is an example:\n> > > >>>\n> > > >>> mysql> select id, host, binary, topic, report_count, disabled,\n> > > >>> availability_zone from services;\n> > > >>> +----+-------------+----------------+-----------\n> > +--------------+----------+-------------------+\n> > > >>> | id | host | binary | topic | report_count | disabled |\n> > > >>> | availability_zone |\n> > > >>> +----+-------------+----------------+-----------\n> > +--------------+----------+-------------------+\n> > > >>> | 1 | bespin101 | nova-scheduler | scheduler | 17145 | 0 |\n> > > >>> | nova |\n> > > >>> | 2 | bespin101 | nova-network | network | 16819 | 0 | nova |\n> > > >>> | 3 | bespin101-0 | nova-compute | compute | 16405 | 0 | nova\n> > > >>> | |\n> > > >>> | 4 | bespin101-1 | nova-compute | compute | 1 | 0 | nova |\n> > > >>> +----+-------------+----------------+-----------\n> > +--------------+----------+-------------------+\n> > > >>>\n> > > >>> mysql> select id, service_id, hypervisor_hostname from\n> > > >>> compute_nodes;\n> > > >>> +----+------------+------------------------+\n> > > >>> | id | service_id | hypervisor_hostname |\n> > > >>> +----+------------+------------------------+\n> > > >>> | 1 | 3 | bespin101.east.isi.edu |\n> > > >>> | 2 | 4 | bespin101.east.isi.edu |\n> > > >>> +----+------------+------------------------+\n> > > >>>\n> > > >>> Then, nova db (compute_nodes table) has entries of all\n> > > >>> bare-metal\n> > > >>> nodes.\n> > > >>> What do you think of this approach.\n> > > >>> Do you have any better approach?\n> > > >>>\n> > > >>> Thanks,\n> > > >>> David\n> > > >>>\n> > > >>>\n> > > >>>\n> > > >>> ----- Original Message -----\n> > > >>>> To elaborate, something the below. I\'m not absolutely sure\n> > > >>>> you\n> > > >>>> need\n> > > >>>> to\n> > > >>>> be able to set service_name and host, but this gives you the\n> > > >>>> option\n> > > >>>> to\n> > > >>>> do so if needed.\n> > > >>>>\n> > > >>>> iff --git a/nova/manager.py b/nova/manager.py\n> > > >>>> index c6711aa..c0f4669 100644\n> > > >>>> --- a/nova/manager.py\n> > > >>>> +++ b/nova/manager.py\n> > > >>>> @@ -217,6 +217,8 @@ class SchedulerDependentManager(Manager):\n> > > >>>>\n> > > >>>> def update_service_capabilities(self, capabilities):\n> > > >>>> \"\"\"Remember these capabilities to send on next periodic\n> > > >>>> update.\"\"\"\n> > > >>>> + if not isinstance(capabilities, list):\n> > > >>>> + capabilities = [capabilities]\n> > > >>>> self.last_capabilities = capabilities\n> > > >>>>\n> > > >>>> @periodic_task\n> > > >>>> @@ -224,5 +226,8 @@ class SchedulerDependentManager(Manager):\n> > > >>>> \"\"\"Pass data back to the scheduler at a periodic interval.\"\"\"\n> > > >>>> if self.last_capabilities:\n> > > >>>> LOG.debug(_(\'Notifying Schedulers of capabilities ...\'))\n> > > >>>> - self.scheduler_rpcapi.update_service_capabilities(context,\n> > > >>>> - self.service_name, self.host, self.last_capabilities)\n> > > >>>> + for capability_item in self.last_capabilities:\n> > > >>>> + name = capability_item.get(\'service_name\',\n> > > >>>> self.service_name)\n> > > >>>> + host = capability_item.get(\'host\', self.host)\n> > > >>>> + self.scheduler_rpcapi.update_service_capabilities(context,\n> > > >>>> + name, host, capability_item)\n> > > >>>>\n> > > >>>> On Aug 21, 2012, at 1:28 PM, David Kang <dkang at isi.edu>\n> > > >>>> wrote:\n> > > >>>>\n> > > >>>>>\n> > > >>>>> Hi Vish,\n> > > >>>>>\n> > > >>>>> We are trying to change our code according to your comment.\n> > > >>>>> I want to ask a question.\n> > > >>>>>\n> > > >>>>>>>> a) modify driver.get_host_stats to be able to return a\n> > > >>>>>>>> list\n> > > >>>>>>>> of\n> > > >>>>>>>> host\n> > > >>>>>>>> stats instead of just one. Report the whole list back to\n> > > >>>>>>>> the\n> > > >>>>>>>> scheduler. We could modify the receiving end to accept a\n> > > >>>>>>>> list\n> > > >>>>>>>> as\n> > > >>>>>>>> well\n> > > >>>>>>>> or just make multiple calls to\n> > > >>>>>>>> self.update_service_capabilities(capabilities)\n> > > >>>>>\n> > > >>>>> Modifying driver.get_host_stats to return a list of host\n> > > >>>>> stats\n> > > >>>>> is\n> > > >>>>> easy.\n> > > >>>>> Calling muliple calls to\n> > > >>>>> self.update_service_capabilities(capabilities) doesn\'t seem\n> > > >>>>> to\n> > > >>>>> work,\n> > > >>>>> because \'capabilities\' is overwritten each time.\n> > > >>>>>\n> > > >>>>> Modifying the receiving end to accept a list seems to be\n> > > >>>>> easy.\n> > > >>>>> However, \'capabilities\' is assumed to be dictionary by all\n> > > >>>>> other\n> > > >>>>> scheduler routines,\n> > > >>>>> it looks like that we have to change all of them to handle\n> > > >>>>> \'capability\' as a list of dictionary.\n> > > >>>>>\n> > > >>>>> If my understanding is correct, it would affect many parts\n> > > >>>>> of\n> > > >>>>> the\n> > > >>>>> scheduler.\n> > > >>>>> Is it what you recommended?\n> > > >>>>>\n> > > >>>>> Thanks,\n> > > >>>>> David\n> > > >>>>>\n> > > >>>>>\n> > > >>>>> ----- Original Message -----\n> > > >>>>>> This was an immediate goal, the bare-metal nova-compute\n> > > >>>>>> node\n> > > >>>>>> could\n> > > >>>>>> keep an internal database, but report capabilities through\n> > > >>>>>> nova\n> > > >>>>>> in\n> > > >>>>>> the\n> > > >>>>>> common way with the changes below. Then the scheduler\n> > > >>>>>> wouldn\'t\n> > > >>>>>> need\n> > > >>>>>> access to the bare metal database at all.\n> > > >>>>>>\n> > > >>>>>> On Aug 15, 2012, at 4:23 PM, David Kang <dkang at isi.edu>\n> > > >>>>>> wrote:\n> > > >>>>>>\n> > > >>>>>>>\n> > > >>>>>>> Hi Vish,\n> > > >>>>>>>\n> > > >>>>>>> Is this discussion for long-term goal or for this Folsom\n> > > >>>>>>> release?\n> > > >>>>>>>\n> > > >>>>>>> We still believe that bare-metal database is needed\n> > > >>>>>>> because there is not an automated way how bare-metal nodes\n> > > >>>>>>> report\n> > > >>>>>>> their capabilities\n> > > >>>>>>> to their bare-metal nova-compute node.\n> > > >>>>>>>\n> > > >>>>>>> Thanks,\n> > > >>>>>>> David\n> > > >>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> I am interested in finding a solution that enables\n> > > >>>>>>>> bare-metal\n> > > >>>>>>>> and\n> > > >>>>>>>> virtualized requests to be serviced through the same\n> > > >>>>>>>> scheduler\n> > > >>>>>>>> where\n> > > >>>>>>>> the compute_nodes table has a full view of schedulable\n> > > >>>>>>>> resources.\n> > > >>>>>>>> This\n> > > >>>>>>>> would seem to simplify the end-to-end flow while opening\n> > > >>>>>>>> up\n> > > >>>>>>>> some\n> > > >>>>>>>> additional use cases (e.g. dynamic allocation of a node\n> > > >>>>>>>> from\n> > > >>>>>>>> bare-metal to hypervisor and back).\n> > > >>>>>>>>\n> > > >>>>>>>> One approach would be to have a proxy running a single\n> > > >>>>>>>> nova-compute\n> > > >>>>>>>> daemon fronting the bare-metal nodes . That nova-compute\n> > > >>>>>>>> daemon\n> > > >>>>>>>> would\n> > > >>>>>>>> report up many HostState objects (1 per bare-metal node)\n> > > >>>>>>>> to\n> > > >>>>>>>> become\n> > > >>>>>>>> entries in the compute_nodes table and accessible through\n> > > >>>>>>>> the\n> > > >>>>>>>> scheduler HostManager object.\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> The HostState object would set cpu_info, vcpus, member_mb\n> > > >>>>>>>> and\n> > > >>>>>>>> local_gb\n> > > >>>>>>>> values to be used for scheduling with the hypervisor_host\n> > > >>>>>>>> field\n> > > >>>>>>>> holding the bare-metal machine address (e.g. for IPMI\n> > > >>>>>>>> based\n> > > >>>>>>>> commands)\n> > > >>>>>>>> and hypervisor_type = NONE. The bare-metal Flavors are\n> > > >>>>>>>> created\n> > > >>>>>>>> with\n> > > >>>>>>>> an\n> > > >>>>>>>> extra_spec of hypervisor_type= NONE and the corresponding\n> > > >>>>>>>> compute_capabilities_filter would reduce the available\n> > > >>>>>>>> hosts\n> > > >>>>>>>> to\n> > > >>>>>>>> those\n> > > >>>>>>>> bare_metal nodes. The scheduler would need to understand\n> > > >>>>>>>> that\n> > > >>>>>>>> hypervisor_type = NONE means you need an exact fit (or\n> > > >>>>>>>> best-fit)\n> > > >>>>>>>> host\n> > > >>>>>>>> vs weighting them (perhaps through the multi-scheduler).\n> > > >>>>>>>> The\n> > > >>>>>>>> scheduler\n> > > >>>>>>>> would cast out the message to the\n> > > >>>>>>>> <topic>.<service-hostname>\n> > > >>>>>>>> (code\n> > > >>>>>>>> today uses the HostState hostname), with the compute\n> > > >>>>>>>> driver\n> > > >>>>>>>> having\n> > > >>>>>>>> to\n> > > >>>>>>>> understand if it must be serviced elsewhere (but does not\n> > > >>>>>>>> break\n> > > >>>>>>>> any\n> > > >>>>>>>> existing implementations since it is 1 to 1).\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> Does this solution seem workable? Anything I missed?\n> > > >>>>>>>>\n> > > >>>>>>>> The bare metal driver already is proxying for the other\n> > > >>>>>>>> nodes\n> > > >>>>>>>> so\n> > > >>>>>>>> it\n> > > >>>>>>>> sounds like we need a couple of things to make this\n> > > >>>>>>>> happen:\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> a) modify driver.get_host_stats to be able to return a\n> > > >>>>>>>> list\n> > > >>>>>>>> of\n> > > >>>>>>>> host\n> > > >>>>>>>> stats instead of just one. Report the whole list back to\n> > > >>>>>>>> the\n> > > >>>>>>>> scheduler. We could modify the receiving end to accept a\n> > > >>>>>>>> list\n> > > >>>>>>>> as\n> > > >>>>>>>> well\n> > > >>>>>>>> or just make multiple calls to\n> > > >>>>>>>> self.update_service_capabilities(capabilities)\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> b) make a few minor changes to the scheduler to make sure\n> > > >>>>>>>> filtering\n> > > >>>>>>>> still works. Note the changes here may be very helpful:\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> https://review.openstack.org/10327\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> c) we have to make sure that instances launched on those\n> > > >>>>>>>> nodes\n> > > >>>>>>>> take\n> > > >>>>>>>> up\n> > > >>>>>>>> the entire host state somehow. We could probably do this\n> > > >>>>>>>> by\n> > > >>>>>>>> making\n> > > >>>>>>>> sure that the instance_type ram, mb, gb etc. matches what\n> > > >>>>>>>> the\n> > > >>>>>>>> node\n> > > >>>>>>>> has, but we may want a new boolean field \"used\" if those\n> > > >>>>>>>> aren\'t\n> > > >>>>>>>> sufficient.\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> I This approach seems pretty good. We could potentially\n> > > >>>>>>>> get\n> > > >>>>>>>> rid\n> > > >>>>>>>> of\n> > > >>>>>>>> the\n> > > >>>>>>>> shared bare_metal_node table. I guess the only other\n> > > >>>>>>>> concern\n> > > >>>>>>>> is\n> > > >>>>>>>> how\n> > > >>>>>>>> you populate the capabilities that the bare metal nodes\n> > > >>>>>>>> are\n> > > >>>>>>>> reporting.\n> > > >>>>>>>> I guess an api extension that rpcs to a baremetal node to\n> > > >>>>>>>> add\n> > > >>>>>>>> the\n> > > >>>>>>>> node. Maybe someday this could be autogenerated by the\n> > > >>>>>>>> bare\n> > > >>>>>>>> metal\n> > > >>>>>>>> host\n> > > >>>>>>>> looking in its arp table for dhcp requests! :)\n> > > >>>>>>>>\n> > > >>>>>>>>\n> > > >>>>>>>> Vish\n> > > >>>>>>>>\n> > > >>>>>>>> _______________________________________________\n> > > >>>>>>>> OpenStack-dev mailing list\n> > > >>>>>>>> OpenStack-dev at lists.openstack.org\n> > > >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >>>>>>>\n> > > >>>>>>> _______________________________________________\n> > > >>>>>>> OpenStack-dev mailing list\n> > > >>>>>>> OpenStack-dev at lists.openstack.org\n> > > >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >>>>>>\n> > > >>>>>>\n> > > >>>>>> _______________________________________________\n> > > >>>>>> OpenStack-dev mailing list\n> > > >>>>>> OpenStack-dev at lists.openstack.org\n> > > >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >>>>>\n> > > >>>>> _______________________________________________\n> > > >>>>> OpenStack-dev mailing list\n> > > >>>>> OpenStack-dev at lists.openstack.org\n> > > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >>>>\n> > > >>>>\n> > > >>>> _______________________________________________\n> > > >>>> OpenStack-dev mailing list\n> > > >>>> OpenStack-dev at lists.openstack.org\n> > > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > Mailing list: https://launchpad.net/~openstack\n> > Post to : openstack at lists.launchpad.net\n> > Unsubscribe : https://launchpad.net/~openstack\n> > More help : https://help.launchpad.net/ListHelp\n> >\n> \n> Michael\n> \n> -------------------------------------------------\n> Michael Fork\n> Cloud Architect, Emerging Solutions\n> IBM Systems & Technology Group\n\n\n','<OFD7921F77.793A3F9D-ON85257A67.0070FCDE-85257A67.0072FBC1@us.ibm.com>',NULL),('<1155147972.27592435.1407598999829.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 11:43:19',-14400,'2014-08-09 15:43:19',NULL,'[openstack-dev] [qa][ceilometer] swapping the roles of mongodb\n and sqlalchemy for ceilometer in Tempest','\n\n> Agreed, testing options is good; and should likely be disjoint from the legal\n> questions around mongodb...\n> \n> Although if there is really only one viable & scalable option and that option\n> has legal usage questions surrounding it then it makes me wonder how much we\n> are kidding ourselves on there being anything optional about this... Not\n> something I can answer but someone likely should?.?.\n> \n> I guess it really depends on what the desired outcome of testing with mongodb\n> is, if the outcome is to satisfy a TC requirement for improved testing via\n> *any* backend then this would seem applicable. If instead it\'s around\n> testing a backend that isn\'t legally encumbered (and is also realistically\n> viable to use) then we are in a different area altogether...\n\nUsual IANAL caveats, I just want to ensure that some code that\'s used in\nthe wild to also be tested upstream :)\n\nSo as stated in response to Devananda, I\'m happy for this change to have\nmore the character of an *expansion* in overall coverage, as opposed to\nan *exchange* of one type of coverage for another.\n\nAssuming of course that the QA/infra side of the house are willing to\naccommodate that, it would seem to satisfy both requirements?\n\nNot to open another hornet\'s nest, but note that there is actually a\nthird opensource option for ceilometer storage, in the form of the\nhbase driver (Apache 2.0 being the applicable license for the backend\nin this case). In performance testing done by Ilya Tyaptin, this\nbackend shows same-ballpark performance characteristics to mongodb.\n\nCheers,\nEoghan\n \n> Just my 2cents.\n> \n> Sent from my really tiny device...\n> \n> > On Aug 9, 2014, at 10:53 AM, \"Eoghan Glynn\" <eglynn at redhat.com> wrote:\n> > \n> > \n> > \n> >> +2 from me,\n> >> \n> >> More mongodb adoption (as stated) when it\'s questionable legally doesn\'t\n> >> seem\n> >> like a good long term strategy (I know it will/does impact yahoo adopting\n> >> or\n> >> using ceilometer...). Is this another one of those tactical changes that\n> >> we\n> >> keep on making that ends up being yet another piece of technical debt that\n> >> someone will have to cleanup :-/\n> >> \n> >> If we thought a little more about this strategically maybe we would end up\n> >> in\n> >> a better place short term *and* long term??\n> > \n> > Hi Joshua,\n> > \n> > Since we currently do support mongodb as an *optional* storage driver,\n> > and some distros do recommend its usage, then surely we should test this\n> > driver fully in the upstream gate to support those users who take that\n> > option?\n> > \n> > (i.e. those users who accept MongoDB Inc\'s assurances[1] in regard to\n> > licensing of the client-side driver)\n> > \n> > Cheers,\n> > Eohgan\n> > \n> > [1] http://www.mongodb.org/about/licensing/\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<259C2821-8454-4267-B7D8-EE516832EBB5@yahoo-inc.com>',NULL),('<1155291813.1632201351701368614.JavaMail.nobody@rsj2rmd003.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-31 16:36:08',0,'2012-10-31 16:36:08',NULL,'[OpenStack Foundation] Board meeting update: OpenStack Board\n	Meeting November 2, 2012','Hello Foundation Mailing List,\n\nAlan Clark updated the following board meeting session:\n\nTopic: OpenStack Board Meeting November 2, 2012\nHost: Alan Clark\nDate: Friday, November 2, 2012\nTime: 10:00 am, Mountain Daylight Time (Denver, GMT-06:00)\n\nSession number: 928 761 237\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n-------------------------------------------------------\nTo join the meeting\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=208346702&UID=1461324282&HMAC=227314128ba9e04dccb69f5e69e6ff7daa3712c0&RT=MiM2.\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=208346702&UID=1461324282&ORT=MiM2&HMAC=227314128ba9e04dccb69f5e69e6ff7daa3712c0\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=208346702&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 928 761 237\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\nTo update this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=208346702&EF=EMA&UUID=1461324282&SHA2=ytiJwLnmCaBXVzZ1aMdCFWaU6dTfMYxO2gGirFWs34M%3D&RT=MiM2\n\nhttp://www.webex.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121031/c2c2c145/attachment.html>\n\n',NULL,NULL),('<11582C7A-E1C9-430E-99E6-635FE3CDA1A6@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 16:54:10',32400,'2013-12-06 07:54:10',NULL,'[openstack-dev] request-id in API response','\nOn Dec 6, 2013, at 1:09 AM, John Dickinson <me at not.mn> wrote:\n\n> \n> On Dec 5, 2013, at 1:36 AM, Maru Newby <marun at redhat.com> wrote:\n> \n>> \n>> On Dec 3, 2013, at 12:18 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n>> \n>>> \n>>> \n>>> \n>>> On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson <me at not.mn> wrote:\n>>> Just to add to the story, Swift uses \"X-Trans-Id\" and generates it in the outer-most \"catch_errors\" middleware.\n>>> \n>>> Swift\'s catch errors middleware is responsible for ensuring that the transaction id exists on each request, and that all errors previously uncaught, anywhere in the pipeline, are caught and logged. If there is not a common way to do this, yet, I submit it as a great template for solving this problem. It\'s simple, scalable, and well-tested (ie tests and running in prod for years).\n>>> \n>>> https://github.com/openstack/swift/blob/master/swift/common/middleware/catch_errors.py\n>>> \n>>> Leaving aside error handling and only focusing on the transaction id (or request id) generation, since OpenStack services are exposed to untrusted clients, how would you propose communicating the appropriate transaction id to a different service? I can see great benefit to having a glance transaction ID carry through to Swift requests (and so on), but how should the transaction id be communicated? It\'s not sensitive info, but I can imagine a pretty big problem when trying to track down errors if a client application decides to set eg the X-Set-Transaction-Id header on every request to the same thing.\n>>> \n>>> -1 to cross service request IDs, for the reasons John mentions above.\n>>> \n>>> \n>>> Thanks for bringing this up, and I\'d welcome a patch in Swift that would use a common library to generate the transaction id, if it were installed. I can see that there would be huge advantage to operators to trace requests through multiple systems.\n>>> \n>>> Another option would be for each system that calls an another OpenStack system to expect and log the transaction ID for the request that was given. This would be looser coupling and be more forgiving for a heterogeneous cluster. Eg when Glance makes a call to Swift, Glance cloud log the transaction id that Swift used (from the Swift response). Likewise, when Swift makes a call to Keystone, Swift could log the Keystone transaction id. This wouldn\'t result in a single transaction id across all systems, but it would provide markers so an admin could trace the request.\n>>> \n>>> There was a session on this at the summit, and although the notes are a little scarce this was the conclusion we came up with.  Every time a cross service call is made, we will log and send a notification for ceilometer to consume, with the request-ids of both request ids.  One of the benefits of this approach is that we can easily generate a tree of all the API calls that are made (and clearly show when multiple calls are made to the same service), something that just a cross service request id would have trouble with.\n>> \n>> Is wise to trust anything a client provides to ensure traceability?  If a user receives a request id back from Nova, then submits that request id in an unrelated request to Neutron, the traceability would be effectively corrupted.  If the consensus is that we don\'t want to securely deliver request ids for inter-service calls, how about requiring a service to log its request id along with the request id returned from a call to another service to achieve the a similar result?\n> \n> Yes, this is what I was proposing. I think this is the best path forward.\n\nOk, great.  And as per your suggestion, a middleware-based error handler will soon be proposed for oslo that will secondarily ensure that a request id is added to the request.  \n\n> \n> \n>> The catch is that every call point (or client instantiation?) would have to be modified to pass the request id instead of just logging at one place in each service.  Is that a cost worth paying?\n> \n> Perhaps this is my ignorance of how other projects work today, but does this not already happen? Is it possible to get a response from an API call to an OpenStack project that doesn\'t include a request id?\n\nWe\'ll have it in Neutron real-soon-now, and then I think the answer will be \'yes\'.\n\nOn reflection, it should be easy enough for a given service to ensure that calls to other services are automatically instrumented to log request id pairs.  Again, probably something for oslo.\n\n\nm.\n\n','<16A6274A-98BB-444F-BCC3-2C5682AD7F57@not.mn>',NULL),('<1159E9E8-56FC-49EF-BE54-43054F636D80@vmware.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-12-16 21:09:59',0,'2014-12-16 21:09:59',NULL,'[OpenStack-Infra] Nova Bugs tool and Reviewday','I\'m happy to help do the work if you want. \n\nSent from my iPhone\n\n> On Dec 16, 2014, at 12:19 PM, Elizabeth K. Joseph <lyz at princessleia.com> wrote:\n> \n> So we didn\'t get to it during the meeting, but had a quick chat\n> afterwards and decided:\n> \n> On Thu, Dec 11, 2014 at 2:26 PM, Elizabeth K. Joseph\n> <lyz at princessleia.com> wrote:\n>> Can we toss this code up somewhere temporarily for Nova for now, and\n>> then go from there to work on integration/replacement for reviewday?\n> \n> Yes.\n> \n>> If so, should we create a new project for this in openstack-infra or\n>> leave it on github for now until we can integrate features with\n>> reviewday?\n> \n> Leave it on github.\n> \n> Now, we do need someone to do the Puppet work to get it into infra.\n> While I\'m happy to help, I can\'t jump on this immediately to do it\n> myself right now, maybe after the holidays.\n> \n> If someone else can do this, what we\'ll need is a new module similar\n> to reviewday:\n> \n> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/reviewday\n> \n> And I imagine we\'d put it on status.openstack.org, so we\'ll need to\n> add the config too, similar to how we did reviewday:\n> \n> http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/status.pp#n214\n> \n> I\'m happy to review+test these changes.\n> \n> -- \n> Elizabeth Krumbach Joseph || Lyz || pleia2\n\n\n','<CABesOu2R4HJLsae-qRUFKsN5ZvWsLJEQqAo2=qHynCXjnLDpjQ@mail.gmail.com>',NULL),('<116001241.514091367969820477.JavaMail.nobody@rsj2rmd005.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-05-07 23:37:00',0,'2013-05-07 23:37:00',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting May 30,\n	2013','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting May 30, 2013\nHost: Alan Clark\nDate: Thursday, May 30, 2013\nTime: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\nSession number: 922 405 644\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=225010652&UID=1578378747&HMAC=79ac0abfe8d329e58230a286eb34ee9706ac955c&RT=MiM0\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=225010652&EF=MA&UUID=1578378747&SHA2=n81kEMGxYFqHa4nPyH-KgvbGmow9ZM1kxqnrsQopuHs%3D&RT=MiM0\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=225010652&UID=1578378747&ORT=MiM0&HMAC=79ac0abfe8d329e58230a286eb34ee9706ac955c\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=225010652&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 405 644\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130507/8e93e464/attachment.html>\n\n',NULL,NULL),('<1160377941.401.1367042902572.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:08:22',0,'2013-04-27 06:08:22',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-quantum-stable-grizzly #23','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-quantum-stable-grizzly/23/>\n\n------------------------------------------\n[...truncated 2190 lines...]\n2013-04-27 06:04:39 + [[ -z deb ]]\n2013-04-27 06:04:39 + \'[\' deb = deb \']\'\n2013-04-27 06:04:39 + [[ True = \\T\\r\\u\\e ]]\n2013-04-27 06:04:39 + NO_UPDATE_REPOS=True\n2013-04-27 06:04:39 + apt_get install make fakeroot dkms openvswitch-switch openvswitch-datapath-dkms linux-headers-3.2.0-32-virtual\n2013-04-27 06:04:39 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:04:39 + [[ -z install make fakeroot dkms openvswitch-switch openvswitch-datapath-dkms linux-headers-3.2.0-32-virtual ]]\n2013-04-27 06:04:39 + local sudo=sudo\n2013-04-27 06:04:39 ++ id -u\n2013-04-27 06:04:39 + [[ 1006 = \\0 ]]\n2013-04-27 06:04:39 + sudo DEBIAN_FRONTEND=noninteractive http_proxy= https_proxy= no_proxy= apt-get --option Dpkg::Options::=--force-confold --assume-yes install make fakeroot dkms openvswitch-switch openvswitch-datapath-dkms linux-headers-3.2.0-32-virtual\n2013-04-27 06:04:39 Reading package lists...\n2013-04-27 06:04:39 Building dependency tree...\n2013-04-27 06:04:39 Reading state information...\n2013-04-27 06:04:39 fakeroot is already the newest version.\n2013-04-27 06:04:39 fakeroot set to manually installed.\n2013-04-27 06:04:39 linux-headers-3.2.0-32-virtual is already the newest version.\n2013-04-27 06:04:39 make is already the newest version.\n2013-04-27 06:04:39 make set to manually installed.\n2013-04-27 06:04:39 The following extra packages will be installed:\n2013-04-27 06:04:39   openvswitch-common\n2013-04-27 06:04:39 Suggested packages:\n2013-04-27 06:04:39   ethtool\n2013-04-27 06:04:39 The following NEW packages will be installed:\n2013-04-27 06:04:39   dkms openvswitch-common openvswitch-datapath-dkms openvswitch-switch\n2013-04-27 06:04:39 0 upgraded, 4 newly installed, 0 to remove and 7 not upgraded.\n2013-04-27 06:04:39 Need to get 3,827 kB/3,900 kB of archives.\n2013-04-27 06:04:39 After this operation, 17.0 MB of additional disk space will be used.\n2013-04-27 06:04:39 Get:1 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/universe openvswitch-common amd64 1.4.0-1ubuntu1.5 [547 kB]\n2013-04-27 06:04:39 Get:2 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/universe openvswitch-datapath-dkms all 1.4.0-1ubuntu1.5 [2,007 kB]\n2013-04-27 06:04:39 Get:3 http://nova.clouds.archive.ubuntu.com/ubuntu/ precise-updates/universe openvswitch-switch amd64 1.4.0-1ubuntu1.5 [1,273 kB]\n2013-04-27 06:04:39 Fetched 3,827 kB in 0s (22.4 MB/s)\n2013-04-27 06:04:39 Selecting previously unselected package dkms.\n2013-04-27 06:04:39 (Reading database ... 102835 files and directories currently installed.)\n2013-04-27 06:04:39 Unpacking dkms (from .../dkms_2.2.0.3-1ubuntu3.1_all.deb) ...\n2013-04-27 06:04:39 Selecting previously unselected package openvswitch-common.\n2013-04-27 06:04:39 Unpacking openvswitch-common (from .../openvswitch-common_1.4.0-1ubuntu1.5_amd64.deb) ...\n2013-04-27 06:04:39 Selecting previously unselected package openvswitch-datapath-dkms.\n2013-04-27 06:04:39 Unpacking openvswitch-datapath-dkms (from .../openvswitch-datapath-dkms_1.4.0-1ubuntu1.5_all.deb) ...\n2013-04-27 06:04:39 Selecting previously unselected package openvswitch-switch.\n2013-04-27 06:04:39 Unpacking openvswitch-switch (from .../openvswitch-switch_1.4.0-1ubuntu1.5_amd64.deb) ...\n2013-04-27 06:04:39 Processing triggers for man-db ...\n2013-04-27 06:04:39 Processing triggers for ureadahead ...\n2013-04-27 06:04:39 Setting up dkms (2.2.0.3-1ubuntu3.1) ...\n2013-04-27 06:04:39 Setting up openvswitch-common (1.4.0-1ubuntu1.5) ...\n2013-04-27 06:04:39 Setting up openvswitch-datapath-dkms (1.4.0-1ubuntu1.5) ...\n2013-04-27 06:04:39 \n2013-04-27 06:04:39 Creating symlink /var/lib/dkms/openvswitch/1.4.0/source ->\n2013-04-27 06:04:39                  /usr/src/openvswitch-1.4.0\n2013-04-27 06:04:39 \n2013-04-27 06:04:40 DKMS: add completed.\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 Kernel preparation unnecessary for this kernel.  Skipping...\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 Building module:\n2013-04-27 06:04:40 cleaning build area....(bad exit status: 2)\n2013-04-27 06:04:40 ./configure --with-linux=\'/lib/modules/3.2.0-32-virtual/build\' && make -C datapath/linux..........\n2013-04-27 06:04:40 cleaning build area....(bad exit status: 2)\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 DKMS: build completed.\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 openvswitch:\n2013-04-27 06:04:40 Running module version sanity check.\n2013-04-27 06:04:40  - Original module\n2013-04-27 06:04:40    - No original module exists within this kernel\n2013-04-27 06:04:40  - Installation\n2013-04-27 06:04:40    - Installing to /lib/modules/3.2.0-32-virtual/updates/dkms/\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 brcompat.ko:\n2013-04-27 06:04:40 Running module version sanity check.\n2013-04-27 06:04:40  - Original module\n2013-04-27 06:04:40    - No original module exists within this kernel\n2013-04-27 06:04:40  - Installation\n2013-04-27 06:04:40    - Installing to /lib/modules/3.2.0-32-virtual/updates/dkms/\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 depmod....\n2013-04-27 06:04:40 \n2013-04-27 06:04:40 DKMS: install completed.\n2013-04-27 06:05:26 Setting up openvswitch-switch (1.4.0-1ubuntu1.5) ...\n2013-04-27 06:05:26  * Inserting openvswitch module\n2013-04-27 06:05:26  * /etc/openvswitch/conf.db does not exist\n2013-04-27 06:05:26  * Creating empty database /etc/openvswitch/conf.db\n2013-04-27 06:05:26  * Starting ovsdb-server\n2013-04-27 06:05:26  * Configuring Open vSwitch system IDs\n2013-04-27 06:05:26  * Starting ovs-vswitchd\n2013-04-27 06:05:26  * Enabling gre with iptables\n2013-04-27 06:05:26 + TRACK_DEPENDS=False\n2013-04-27 06:05:26 + [[ False = True ]]\n2013-04-27 06:05:26 + echo_summary \'Installing OpenStack project source\'\n2013-04-27 06:05:26 + [[ -t 3 ]]\n2013-04-27 06:05:26 + echo -e Installing OpenStack project source\n2013-04-27 06:05:26 + install_keystoneclient\n2013-04-27 06:05:26 + git_clone https://github.com/openstack/python-keystoneclient.git /opt/stack/new/python-keystoneclient master\n2013-04-27 06:05:26 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:05:26 + GIT_REMOTE=https://github.com/openstack/python-keystoneclient.git\n2013-04-27 06:05:26 + GIT_DEST=/opt/stack/new/python-keystoneclient\n2013-04-27 06:05:26 + GIT_REF=master\n2013-04-27 06:05:26 Installing OpenStack project source\n2013-04-27 06:05:26 + echo master\n2013-04-27 06:05:26 + egrep -q \'^refs\'\n2013-04-27 06:05:26 + [[ ! -d /opt/stack/new/python-keystoneclient ]]\n2013-04-27 06:05:26 + [[ \'\' == \\y\\e\\s ]]\n2013-04-27 06:05:26 + setup_develop /opt/stack/new/python-keystoneclient\n2013-04-27 06:05:26 + [[ False = True ]]\n2013-04-27 06:05:26 + SUDO_CMD=sudo\n2013-04-27 06:05:26 + cd /opt/stack/new/python-keystoneclient\n2013-04-27 06:05:26 + python setup.py egg_info\n2013-04-27 06:05:26 running egg_info\n2013-04-27 06:05:26 creating python_keystoneclient.egg-info\n2013-04-27 06:05:26 writing requirements to python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:26 writing python_keystoneclient.egg-info/PKG-INFO\n2013-04-27 06:05:26 writing top-level names to python_keystoneclient.egg-info/top_level.txt\n2013-04-27 06:05:26 writing dependency_links to python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:26 writing entry points to python_keystoneclient.egg-info/entry_points.txt\n2013-04-27 06:05:26 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:05:26 reading manifest template \'MANIFEST.in\'\n2013-04-27 06:05:26 warning: no files found matching \'AUTHORS\'\n2013-04-27 06:05:26 warning: no files found matching \'ChangeLog\'\n2013-04-27 06:05:26 warning: no files found matching \'python-keystoneclient\'\n2013-04-27 06:05:26 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:05:26 ++ awk \'/^.+/ {print \"-f \" $1}\' python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:26 + raw_links=\n2013-04-27 06:05:26 ++ echo\n2013-04-27 06:05:26 ++ xargs\n2013-04-27 06:05:26 + depend_links=\n2013-04-27 06:05:26 ++ \'[\' \'!\' -r python_keystoneclient.egg-info/requires.txt \']\'\n2013-04-27 06:05:26 ++ echo \'-r *-info/requires.txt\'\n2013-04-27 06:05:26 + require_file=\'-r *-info/requires.txt\'\n2013-04-27 06:05:26 + pip_install -r python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:26 + [[ False = \\T\\r\\u\\e ]]\n2013-04-27 06:05:26 + [[ -z -r python_keystoneclient.egg-info/requires.txt ]]\n2013-04-27 06:05:26 + [[ -z deb ]]\n2013-04-27 06:05:26 + [[ False = True ]]\n2013-04-27 06:05:26 + SUDO_PIP=sudo\n2013-04-27 06:05:26 ++ get_pip_command\n2013-04-27 06:05:26 ++ is_fedora\n2013-04-27 06:05:26 ++ [[ -z Ubuntu ]]\n2013-04-27 06:05:26 ++ \'[\' Ubuntu = Fedora \']\'\n2013-04-27 06:05:26 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-04-27 06:05:26 ++ \'[\' Ubuntu = CentOS \']\'\n2013-04-27 06:05:26 ++ which pip\n2013-04-27 06:05:26 + CMD_PIP=/usr/bin/pip\n2013-04-27 06:05:26 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-04-27 06:05:26 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install -r python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:26 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_keystoneclient.egg-info/requires.txt (line 1))\n2013-04-27 06:05:26 Downloading/unpacking prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:26   Cannot fetch index base URL http://pypi.openstack.org/openstack/\n2013-04-27 06:05:26   Could not find any downloads that satisfy the requirement prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:26 No distributions at all found for prettytable>=0.6,<0.8 (from -r python_keystoneclient.egg-info/requires.txt (line 2))\n2013-04-27 06:05:26 Storing complete log in /opt/stack/new/.pip/pip.log\n2013-04-27 06:05:26 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-04-27 06:05:26 running develop\n2013-04-27 06:05:26 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-04-27 06:05:26 /usr/bin/python -E -c pass\n2013-04-27 06:05:26 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-04-27 06:05:26 running egg_info\n2013-04-27 06:05:26 writing requirements to python_keystoneclient.egg-info/requires.txt\n2013-04-27 06:05:26 writing python_keystoneclient.egg-info/PKG-INFO\n2013-04-27 06:05:26 writing top-level names to python_keystoneclient.egg-info/top_level.txt\n2013-04-27 06:05:26 writing dependency_links to python_keystoneclient.egg-info/dependency_links.txt\n2013-04-27 06:05:26 writing entry points to python_keystoneclient.egg-info/entry_points.txt\n2013-04-27 06:05:26 reading manifest template \'MANIFEST.in\'\n2013-04-27 06:05:26 warning: no files found matching \'AUTHORS\'\n2013-04-27 06:05:26 warning: no files found matching \'ChangeLog\'\n2013-04-27 06:05:26 warning: no files found matching \'python-keystoneclient\'\n2013-04-27 06:06:11 writing manifest file \'python_keystoneclient.egg-info/SOURCES.txt\'\n2013-04-27 06:06:11 running build_ext\n2013-04-27 06:06:11 Creating /usr/local/lib/python2.7/dist-packages/python-keystoneclient.egg-link (link to .)\n2013-04-27 06:06:11 Adding python-keystoneclient 0.2.3.11.g22228f5 to easy-install.pth file\n2013-04-27 06:06:11 Installing keystone script to /usr/local/bin\n2013-04-27 06:06:11 \n2013-04-27 06:06:11 Installed /opt/stack/new/python-keystoneclient\n2013-04-27 06:06:11 Processing dependencies for python-keystoneclient==0.2.3.11.g22228f5\n2013-04-27 06:06:11 Searching for oslo.config>=1.1.0\n2013-04-27 06:06:11 Reading http://pypi.openstack.org/openstack/oslo.config/\n2013-04-27 06:06:11 Download error on http://pypi.openstack.org/openstack/oslo.config/: timed out -- Some packages may not be found!\n2013-04-27 06:06:11 Reading http://pypi.openstack.org/openstack/oslo.config/\n2013-04-27 06:06:11 Download error on http://pypi.openstack.org/openstack/oslo.config/: timed out -- Some packages may not be found!\n2013-04-27 06:06:11 Couldn\'t find index page for \'oslo.config\' (maybe misspelled?)\n2013-04-27 06:06:11 Scanning index of all packages (this may take a while)\n2013-04-27 06:06:11 Reading http://pypi.openstack.org/openstack/\n2013-04-27 06:06:11 Download error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n2013-04-27 06:06:11 No local packages or download links found for oslo.config>=1.1.0\n2013-04-27 06:06:11 error: Could not find suitable distribution for Requirement.parse(\'oslo.config>=1.1.0\')\n2013-04-27 06:06:11 ++ failed\n2013-04-27 06:06:11 ++ local r=1\n2013-04-27 06:06:11 +++ jobs -p\n2013-04-27 06:06:11 ++ kill\n2013-04-27 06:06:11 ++ set +o xtrace\n2013-04-27 06:06:11 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-04-27-060245\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1160885200.67.1375771490304.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:44:50',0,'2013-08-06 06:44:50',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-postgres-stable-grizzly #127','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/127/>\n\n\n\n','<1721359506.48.1375682568146.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1161040617.53.1386742466146.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:14:25',0,'2013-12-11 06:14:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-havana #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-havana/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827373 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-havana/ws/>\n[periodic-tempest-dsvm-neutron-havana] $ /bin/bash -xe /tmp/hudson8151843828433249977.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: RPC failed; result=7, HTTP code = 0\nfatal: The remote end hung up unexpectedly\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az2-827373\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-havana/devstack-precise-hpcloud-az2-827373/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1161115762.0.1376720308358.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-17 06:18:28',0,'2013-08-17 06:18:28',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python27-stable-grizzly #7','See <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/7/>\n\n\n\n','<2006731406.4.1376633691913.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1161159946.0.1376546967264.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-15 06:09:27',0,'2013-08-15 06:09:27',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #7','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/7/>\n\n\n\n','<729238372.6.1376374015723.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1161171262.167.1356308718964.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-24 00:25:18',0,'2012-12-24 00:25:18',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-folsom #84','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/84/>\n\n\n\n','<1193049956.133.1356221382868.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1161625358.1284325.1392111348686.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 04:35:48',-18000,'2014-02-11 09:35:48',NULL,'[openstack-dev] [Openstack-dev][All] tox 1.7.0 error while\n running	tests','\n\n----- Original Message -----\n> From: \"Swapnil Kulkarni\" <swapnilkulkarni2608 at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, February 11, 2014 11:26:29 AM\n> Subject: [openstack-dev] [Openstack-dev][All] tox 1.7.0 error while running	tests\n> \n> Hello,\n> \n> I created a new devstack environment today and installed tox 1.7.0, and\n> getting error \"tox.ConfigError: ConfigError: substitution key \'posargs\' not\n> found\".\n> \n> Details in [1].\n> \n> Anybody encountered similar error before? Any workarounds/updates needed?\n\nIt\'s a known issue, and for a workaround personally I downgraded to tox 1.6.1.\n\n> \n> [1] http://paste.openstack.org/show/64178/\n> \n> \n> Best Regards,\n> Swapnil Kulkarni\n> irc : coolsvap\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAN_H9NhQF+am0gJLTKnGhBhe39PxKeVoaDF0aXL93iuCX+sXjA@mail.gmail.com>',NULL),('<1161878055.87.1367822227604.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-06 06:37:07',0,'2013-05-06 06:37:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly-centos6 #6','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly-centos6/6/>\n\n------------------------------------------\n[...truncated 4935 lines...]\n    test_get_pid_file_name_not_existing                          OK    0.00\n    test_pid                                                     OK    0.00\n    test_pid_invalid_file                                        OK    0.00\n    test_pid_no_an_int                                           OK    0.00\nTestABCDriver\n    test_get_device_name                                         OK    0.00\n    test_l3_init                                                 OK    0.01\nTestBridgeInterfaceDriver\n    test_get_device_name                                         OK    0.00\n    test_plug_dev_exists                                         OK    0.00\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    0.01\n    test_unplug                                                  OK    0.01\n    test_unplug_no_device                                        OK    0.01\nTestMetaInterfaceDriver\n    test_get_device_plugin_tag                                   OK    2.20\n    test_get_driver_by_network_id                                OK    0.01\n    test_set_device_plugin_tag                                   OK    0.01\nTestOVSInterfaceDriver\n    test_get_device_name                                         OK    0.00\n    test_plug_alt_bridge                                         OK    0.01\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    0.01\n    test_unplug                                                  OK    0.01\nTestOVSInterfaceDriverWithVeth\n    test_get_device_name                                         OK    0.00\n    test_plug_alt_bridge                                         OK    0.01\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    0.01\n    test_plug_with_prefix                                        OK    0.01\n    test_unplug                                                  OK    0.01\nTestDeviceExists\n    test_device_does_not_exist                                   OK    0.00\n    test_device_exists                                           OK    0.00\nTestIPCommandBase\n    test_as_root                                                 OK    0.00\n    test_as_root_with_options                                    OK    0.00\n    test_run                                                     OK    0.01\n    test_run_with_options                                        OK    0.00\nTestIPDevice\n    test_eq_diff_name                                            OK    0.00\n    test_eq_diff_namespace                                       OK    0.00\n    test_eq_other_is_none                                        OK    0.00\n    test_eq_same_name                                            OK    0.00\n    test_eq_same_namespace                                       OK    0.00\n    test_str                                                     OK    0.00\nTestIPDeviceCommandBase\n    test_name_property                                           OK    0.00\nTestIpAddrCommand\n    test_add_address                                             OK    0.00\n    test_add_address_scoped                                      OK    0.00\n    test_del_address                                             OK    0.00\n    test_flush                                                   OK    0.00\n    test_list                                                    OK    0.00\n    test_list_filtered                                           OK    0.00\nTestIpLinkCommand\n    test_address_property                                        OK    0.00\n    test_alias_property                                          OK    0.00\n    test_delete                                                  OK    0.00\n    test_mtu_property                                            OK    0.00\n    test_qdisc_property                                          OK    0.00\n    test_qlen_property                                           OK    0.00\n    test_set_address                                             OK    0.00\n    test_set_alias                                               OK    0.00\n    test_set_down                                                OK    0.00\n    test_set_mtu                                                 OK    0.00\n    test_set_name                                                OK    0.00\n    test_set_netns                                               OK    0.00\n    test_set_up                                                  OK    0.00\n    test_settings_property                                       OK    0.00\n    test_state_property                                          OK    0.00\nTestIpNetnsCommand\n    test_add_namespace                                           OK    0.00\n    test_delete_namespace                                        OK    0.00\n    test_execute                                                 OK    0.00\n    test_execute_env_var_prepend                                 OK    0.00\n    test_namespace_doest_not_exist                               OK    0.00\n    test_namespace_exists                                        OK    0.00\nTestIpRouteCommand\n    test_add_gateway                                             OK    0.00\n    test_del_gateway                                             OK    0.00\n    test_get_gateway                                             OK    0.00\n    test_pullup_route                                            OK    0.00\n    test_pullup_route_first                                      OK    0.00\nTestIpWrapper\n    test_add_device_to_namespace                                 OK    0.00\n    test_add_device_to_namespace_is_none                         OK    0.00\n    test_add_tuntap                                              OK    0.00\n    test_add_veth                                                OK    0.00\n    test_ensure_namespace                                        OK    0.01\n    test_ensure_namespace_existing                               OK    0.01\n    test_garbage_collect_namespace_does_not_exist                OK    0.00\n    test_garbage_collect_namespace_existing_empty_ns             OK    0.01\n    test_garbage_collect_namespace_existing_not_empty            OK    0.01\n    test_get_device                                              OK    0.00\n    test_get_devices                                             OK    0.00\n    test_get_devices_malformed_line                              OK    0.00\n    test_get_namespaces                                          OK    0.00\n    test_namespace_is_empty                                      OK    0.00\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.10\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    2.31\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    2.46\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.07\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.01\n    test_get_instance_id_network_id_no_match                     OK    0.01\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.01\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.01\n    test_init_with_client                                        OK    0.01\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.01\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.01\n    test_init_exists_unlink_no_file                              OK    0.01\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.00\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.01\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.01\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.32\n    test_quotas_default_values                                   Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.bxKeJlR2fQ\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1: 17337 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly-centos6/6\n[SCP] Copying console log.\n\n\n','<617421112.66.1367735823255.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1162811699.59.1383459435006.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:17:15',0,'2013-11-03 06:17:15',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-tempest-devstack-vm-neutron-stable-grizzly #53','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/53/>\n\n\n\n','<994162462.47.1383373035156.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1164048471.359.1367042605211.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:03:25',0,'2013-04-27 06:03:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-docs-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal3 in workspace <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/>\nCheckout:periodic-ceilometer-docs-stable-grizzly / <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/> - hudson.remoting.Channel at 2625f965:quantal3\nUsing strategy: Default\nLast Built Revision: Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/ceilometer.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/ceilometer.git\nCommencing build of Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\nChecking out Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\n[periodic-ceilometer-docs-stable-grizzly] $ /bin/bash -xe /tmp/hudson3429277186487769428.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack ceilometer\n+ org=openstack\n+ project=ceilometer\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack ceilometer\n+ org=openstack\n+ project=ceilometer\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' ceilometer == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/pip-requires,> sphinxcontrib-httpdomain\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/test-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/pip-requires\',> \'sphinxcontrib-httpdomain\']\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-ceilometer-docs-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 33968 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-ceilometer-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal3\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'4f56c9c8-1f5c-4dc5-9921-989d39b3191f\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'75529b8bb00bbb9566eb3270ab070e89f7f94d97\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal3\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 33968 166.78.137.37 22\'}\nDownloading/unpacking http://tarballs.openstack.org/nova/nova-master.tar.gz (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package from http://tarballs.openstack.org/nova/nova-master.tar.gz\n    Download error on http://pypi.openstack.org/openstack/setuptools_git/: timed out -- Some packages may not be found!\n    Download error on http://pypi.openstack.org/openstack/setuptools-git/: timed out -- Some packages may not be found!\n    Couldn\'t find index page for \'setuptools_git\' (maybe misspelled?)\n    Download error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n    No local packages or download links found for setuptools-git>=0.4\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"/tmp/pip-5vcgUi-build/setup.py\", line 80, in <module>\n        py_modules=[])\n      File \"/usr/lib/python2.7/distutils/core.py\", line 112, in setup\n        _setup_distribution = dist = klass(attrs)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 221, in __init__\n        self.fetch_build_eggs(attrs.pop(\'setup_requires\'))\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 245, in fetch_build_eggs\n        parse_requirements(requires), installer=self.fetch_build_egg\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 586, in resolve\n        dist = best[req.key] = env.best_match(req, self, installer)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 831, in best_match\n        return self.obtain(req, installer) # try and download/install\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 843, in obtain\n        return installer(requirement)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 295, in fetch_build_egg\n        return cmd.easy_install(req)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/command/easy_install.py\",> line 592, in easy_install\n        raise DistutilsError(msg)\n    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse(\'setuptools-git>=0.4\')\n    Complete output from command python setup.py egg_info:\n    Download error on http://pypi.openstack.org/openstack/setuptools_git/: timed out -- Some packages may not be found!\n\nDownload error on http://pypi.openstack.org/openstack/setuptools-git/: timed out -- Some packages may not be found!\n\nCouldn\'t find index page for \'setuptools_git\' (maybe misspelled?)\n\nDownload error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n\nNo local packages or download links found for setuptools-git>=0.4\n\nTraceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"/tmp/pip-5vcgUi-build/setup.py\", line 80, in <module>\n\n    py_modules=[])\n\n  File \"/usr/lib/python2.7/distutils/core.py\", line 112, in setup\n\n    _setup_distribution = dist = klass(attrs)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 221, in __init__\n\n    self.fetch_build_eggs(attrs.pop(\'setup_requires\'))\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 245, in fetch_build_eggs\n\n    parse_requirements(requires), installer=self.fetch_build_egg\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 586, in resolve\n\n    dist = best[req.key] = env.best_match(req, self, installer)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 831, in best_match\n\n    return self.obtain(req, installer) # try and download/install\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py\",> line 843, in obtain\n\n    return installer(requirement)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/dist.py\",> line 295, in fetch_build_egg\n\n    return cmd.easy_install(req)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/.tox/venv/local/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/setuptools/command/easy_install.py\",> line 592, in easy_install\n\n    raise DistutilsError(msg)\n\ndistutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse(\'setuptools-git>=0.4\')\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in /tmp/pip-5vcgUi-build\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/pip-requires,> sphinxcontrib-httpdomain]\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/ws/tools/pip-requires,> sphinxcontrib-httpdomain]\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<116570045.26787709.1394723460676.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 11:11:00',-14400,'2014-03-13 15:11:00',NULL,'[openstack-dev] any recommendations for live debugging of\n openstack	services?','Well, for a non-interactive view of things, you can use the openstack.common.report functionality.  It\'s currently integrated into Nova, and I believe that the other projects are working to get it integrated as well.  To use it, you just send a SIGUSR1 to any Nova process, and a report of the current stack traces of threads and green threads, as well as the current configuration options, will be dumped.\n\nIt doesn\'t look like exactly what you want, but I figured it might be useful to you anyway.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Chris Friesen\" <chris.friesen at windriver.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, March 12, 2014 12:47:32 PM\nSubject: [openstack-dev] any recommendations for live debugging of openstack	services?\n\n\nAre there any tools that people can recommend for live debugging of \nopenstack services?\n\nI\'m looking for a mechanism where I could take a running system that \nisn\'t behaving the way I expect and somehow poke around inside the \nprogram while it keeps running.  (Sort of like tracepoints in gdb.)\n\nI\'ve seen mention of things like twisted.manhole and \neventlet.backdoor...has anyone used this sort of thing with openstack? \nAre there better options?\n\nAlso, has anyone ever seen an implementation of watchpoints for python? \n  By that I mean the ability to set a breakpoint if the value of a \nvariable changes.  I found \n\"https://sourceforge.net/blog/watchpoints-in-python/\" but it looks \npretty hacky.\n\nThanks,\nChris\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53208FA4.3030006@windriver.com>',NULL),('<1165767700.678810.1396877817800.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 09:36:57',-14400,'2014-04-07 13:36:57',NULL,'[openstack-dev] [Tuskar][TripleO] Tuskar Planning for Juno','Hi all,\n\nOne of the topics of discussion during the TripleO midcycle meetup a few weeks\nago was the direction we\'d like to take Tuskar during Juno.  Based on the ideas\npresented there, we\'ve created a tentative list of items we\'d like to address:\n\nhttps://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning \n\nPlease feel free to take a look and question, comment, or criticize!\n\n\nThanks,\nTzu-Mainn Chen\n\n\n','<1100191538.333973.1396843239424.JavaMail.zimbra@redhat.com>',NULL),('<116589737.11450848.1349952788064.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 06:53:08',-14400,'2012-10-11 10:53:08',NULL,'[openstack-dev] [keystone] on-behalf-of proxy identities for\n applications running in-instance','\n\n> Any pointers to examples of this sort of configuration via\n> policy.json would be appreciated ;)\n\nThe basic syntax is covered here:\n\n  http://docs.openstack.org/trunk/openstack-compute/install/content/keystone-concepts.html\n\nNote also this recently merged patch providing additional syntax\nto support finer-grained policy decisions:\n\n  https://review.openstack.org/#/c/14245/\n\nas discussed on the ML here:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-October/001566.html\n\nCheers,\nEoghan\n\n> >  \n> > > Ideally we need to lock down the access such that INSTANCE_USER\n> > > can\n> > > only\n> > > perform a subset of API actions on a subset of the keystone\n> > > authenticated\n> > > APIs, is there any method for doing this with the policy.json?\n> > >\n> > > If not then we can track the \"instance users\" inside heat and\n> > > reject\n> > > API\n> > > requests for non-whitelisted API actions (e.g we want ability to\n> > > send\n> > > Cloudwatch metrics, but not to query them or manipulate alarms)\n> > > \n> > > Adam - previously you mentioned putting the \"instance users\" in a\n> > > separate\n> > > tenant (managed by heat), do you still see this as a good\n> > > solution,\n> > > or do\n> > > you think there is a viable way to lock down INSTANCE_USER inside\n> > > the\n> > > same\n> > > tenant as USER?\n> > \n> > I\'m struggling with the separate tenant idea, as there doesn\'t seem\n> > to be\n> > a way of recovering the original identity (which presumably you\n> > would\n> > need when querying the metrics in you use-case, or just\n> > auditing/billing\n> > etc. in the general case).\n> \n> So I can see this being a problem generally, but within the limited\n> heat\n> use-case, we simply have to enforce one INSTACE_USER for every\n> instance, and\n> map the INSTANCE_USER to the actual instance resource internally.\n>  Non-ideal\n> though..\n> \n> The main thing seems to be having INSTANCE_USERs in a separate tenant\n> probably adds a lot of internal management complexity, for some\n> percieved\n> additional separation/security.\n> \n> Then you also have the risk of contamination between INSTANCE_USERs\n> (e.g due\n> to bugs in our internal mapping code etc), so overall I\'m reaching\n> the\n> conclusion that sticking to a single tenant will be best overall,\n> with\n> INSTANCE_USERs restricted by role/policy and possibly some whitelist\n> sanity\n> logic in the WSGI code.\n> \n> Steve\n> \n> \n\n\n','<20121011101413.GA14960@heatlt.redhat.com>',NULL),('<11667FD27DDE444B82810ED28822733D@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-29 12:54:14',-18000,'2013-01-29 17:54:14',NULL,'[openstack-dev] blueprint amqp-rpc-fast-reply-queue','>  \n> I\'m glad to hear there is a good chance that I can get this approved in a single release and with a documented config option.\n>  \n> The other contention point is how the RPC msg_id sent in the message data is used. The (somewhat) short explanation is that if the new implementation continues to use it as a unique identifier for the message and the fast option is enabled, a NEW->OLD RPC call will get executed on the server side, the response will be sent to a queue that will be immediately deleted (auto-delete), the RPC call will timeout on the caller side and no meaningful log entry will be produced.  \nThis is fairly moot if this feature is tied to the new messaging envelope, however. Sending from NEW->OLD simply won\'t work if the envelope is enabled. (Note, Russell has put some effort into making the envelope cross-version compatible, but I have some concerns about that tied to my previous email regarding the envelope format as it stands today)\n\nAssuming there is no new envelope? We\'ve discussed it already, but I\'m still unclear why the old queue cannot be, for the duration of a single release, ALSO be consumed by the caller?  \n\nThe OLD system sends the message somewhere and the NEW system knows where it is being sent to, it is just refusing to pick it up. That is, besides the impact on performance, why not ALWAYS use the new method while retaining the ability of the old pattern to continue functioning if this is a choice? Given a no-backwards-compat configuration flag, or an upgrade to H, this consumer could be disabled for a performance benefit.  Basically, support both and deprecate the old.\n\nRegards,\nEric Windisch\n\n\n\n','<CAJcv3CQyXPSVXqwNiVX-PS3bgacVKTzbtPHL8SANp82kB9bHFg@mail.gmail.com>',NULL),('<116701cdc0e3$bb918dc0$32b4a940$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-12 18:40:58',14400,'2012-11-12 14:40:58',NULL,'[openstack-dev] [quantum][LBaaS] yet another question on API','Hi Youcef,\n\n \n\nIMHO  the following API (http://wiki.openstack.org/Quantum/LBaaS/API_1.0)\noperations are redundant:\n\n1)      List all members of a specific pool\n\n\nGET\n\n/v1.0/pools/pool_id/members\n\nList all members of a specific pool.\n\n2)      List Health Monitors associated with a pool\n\n\nGET\n\n/v1.0/pools/pool_id/health_monitors\n\nList Health Monitors associated with a pool.\n\nas it can be done using filtering and column selection\n(http://docs.openstack.org/api/openstack-network/2.0/content/filtering.html)\n, like this\n\n1)      /v1.0/members/?pool_id=pool_id\n\n2)      /v1.0/pools/pool_id?fields=health_monitors\n\n \n\nWhat do you think?\n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/b35ce5f8/attachment.html>\n\n',NULL,NULL),('<1167229589.34.1380175922471.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-26 06:12:02',0,'2013-09-26 06:12:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #29','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/29/>\n\n------------------------------------------\n[...truncated 7307 lines...]\n2013-09-26 06:11:42 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-09-26 06:11:42 secure_delete = False\n2013-09-26 06:11:42 \' /etc/cinder/cinder.conf\n2013-09-26 06:11:42 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-09-26 06:11:42 + local file=/etc/cinder/cinder.conf\n2013-09-26 06:11:42 + local section=DEFAULT\n2013-09-26 06:11:42 + local option=volume_clear\n2013-09-26 06:11:42 + local value=none\n2013-09-26 06:11:42 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-09-26 06:11:42 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-09-26 06:11:42 + local file=/etc/cinder/cinder.conf\n2013-09-26 06:11:42 + local section=DEFAULT\n2013-09-26 06:11:42 + local option=volume_clear\n2013-09-26 06:11:42 + local line\n2013-09-26 06:11:42 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-09-26 06:11:42 + line=\n2013-09-26 06:11:42 + \'[\' -n \'\' \']\'\n2013-09-26 06:11:42 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-09-26 06:11:42 volume_clear = none\n2013-09-26 06:11:42 \' /etc/cinder/cinder.conf\n2013-09-26 06:11:42 + \'[\' False == True \']\'\n2013-09-26 06:11:42 + \'[\' default == XenAPINFS \']\'\n2013-09-26 06:11:42 + \'[\' default == sheepdog \']\'\n2013-09-26 06:11:42 + is_service_enabled quantum\n2013-09-26 06:11:42 + services=quantum\n2013-09-26 06:11:42 + for service in \'${services}\'\n2013-09-26 06:11:42 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-09-26 06:11:42 + return 0\n2013-09-26 06:11:42 + install_quantum\n2013-09-26 06:11:42 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-09-26 06:11:42 + [[ False = \\T\\r\\u\\e ]]\n2013-09-26 06:11:42 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-09-26 06:11:42 + GIT_DEST=/opt/stack/new/neutron\n2013-09-26 06:11:42 + GIT_REF=stable/grizzly\n2013-09-26 06:11:42 + echo stable/grizzly\n2013-09-26 06:11:42 + egrep -q \'^refs\'\n2013-09-26 06:11:42 + [[ ! -d /opt/stack/new/neutron ]]\n2013-09-26 06:11:43 + [[ \'\' == \\y\\e\\s ]]\n2013-09-26 06:11:43 + setup_develop /opt/stack/new/neutron\n2013-09-26 06:11:43 + [[ False = True ]]\n2013-09-26 06:11:43 + SUDO_CMD=sudo\n2013-09-26 06:11:43 + cd /opt/stack/new/neutron\n2013-09-26 06:11:43 + python setup.py egg_info\n2013-09-26 06:11:43 running egg_info\n2013-09-26 06:11:43 creating quantum.egg-info\n2013-09-26 06:11:43 writing requirements to quantum.egg-info/requires.txt\n2013-09-26 06:11:43 writing quantum.egg-info/PKG-INFO\n2013-09-26 06:11:43 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-09-26 06:11:43 writing top-level names to quantum.egg-info/top_level.txt\n2013-09-26 06:11:43 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-09-26 06:11:43 writing entry points to quantum.egg-info/entry_points.txt\n2013-09-26 06:11:43 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-26 06:11:43 reading manifest template \'MANIFEST.in\'\n2013-09-26 06:11:43 warning: no files found matching \'AUTHORS\'\n2013-09-26 06:11:43 warning: no files found matching \'ChangeLog\'\n2013-09-26 06:11:43 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-09-26 06:11:43 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-09-26 06:11:43 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:43 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-26 06:11:43 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-09-26 06:11:43 + raw_links=\n2013-09-26 06:11:43 ++ echo\n2013-09-26 06:11:43 ++ xargs\n2013-09-26 06:11:43 + depend_links=\n2013-09-26 06:11:43 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-09-26 06:11:43 ++ echo \'-r *-info/requires.txt\'\n2013-09-26 06:11:43 + require_file=\'-r *-info/requires.txt\'\n2013-09-26 06:11:43 + pip_install -r quantum.egg-info/requires.txt\n2013-09-26 06:11:43 + [[ False = \\T\\r\\u\\e ]]\n2013-09-26 06:11:43 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-09-26 06:11:43 + [[ -z deb ]]\n2013-09-26 06:11:43 + [[ False = True ]]\n2013-09-26 06:11:43 + SUDO_PIP=sudo\n2013-09-26 06:11:43 ++ get_pip_command\n2013-09-26 06:11:43 ++ is_fedora\n2013-09-26 06:11:43 ++ [[ -z Ubuntu ]]\n2013-09-26 06:11:43 ++ \'[\' Ubuntu = Fedora \']\'\n2013-09-26 06:11:43 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-09-26 06:11:43 ++ \'[\' Ubuntu = CentOS \']\'\n2013-09-26 06:11:43 ++ which pip\n2013-09-26 06:11:43 + CMD_PIP=/usr/local/bin/pip\n2013-09-26 06:11:43 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-09-26 06:11:43 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-09-26 06:11:43 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-09-26 06:11:43 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:43   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.3.tar.gz\n2013-09-26 06:11:43   Running setup.py egg_info for package python-quantumclient\n2013-09-26 06:11:43     [pbr] Processing SOURCES.txt\n2013-09-26 06:11:43     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-09-26 06:11:43     \n2013-09-26 06:11:43     [pbr] In git context, generating filelist from git\n2013-09-26 06:11:43     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-09-26 06:11:46 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-09-26 06:11:46   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.0.tar.gz\n2013-09-26 06:11:46   Running setup.py egg_info for package alembic\n2013-09-26 06:11:46     \n2013-09-26 06:11:46     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-09-26 06:11:46     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-09-26 06:11:46     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-09-26 06:11:46     no previously-included directories found matching \'docs/build/output\'\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.16,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46 Downloading/unpacking pyparsing>=1.5.6,<2.0 (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyparsing%2Fpyparsing-1.5.7.tar.gz\n2013-09-26 06:11:46   Running setup.py egg_info for package pyparsing\n2013-09-26 06:11:46     \n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-26 06:11:46 Requirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-26 06:11:46 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-09-26 06:11:46   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-09-26 06:11:46   Running setup.py egg_info for package Mako\n2013-09-26 06:11:46     \n2013-09-26 06:11:46     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-09-26 06:11:46     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-09-26 06:11:46     warning: no files found matching \'ez_setup.py\'\n2013-09-26 06:11:46     no previously-included directories found matching \'doc/build/output\'\n2013-09-26 06:11:47 Requirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:47 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.16,<0.6->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:47 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-09-26 06:11:47 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=0.9.6->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-09-26 06:11:47 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-09-26 06:11:47 Installing collected packages: python-quantumclient, alembic, pyparsing, Mako\n2013-09-26 06:11:47   Running setup.py install for python-quantumclient\n2013-09-26 06:11:47     [pbr] Reusing existing SOURCES.txt\n2013-09-26 06:11:47     Installing quantum script to /usr/local/bin\n2013-09-26 06:11:47   Running setup.py install for alembic\n2013-09-26 06:11:47     \n2013-09-26 06:11:47     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-09-26 06:11:47     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-09-26 06:11:47     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-09-26 06:11:47     no previously-included directories found matching \'docs/build/output\'\n2013-09-26 06:11:47     Installing alembic script to /usr/local/bin\n2013-09-26 06:11:47   Found existing installation: pyparsing 2.0.1\n2013-09-26 06:11:47     Uninstalling pyparsing:\n2013-09-26 06:11:47       Successfully uninstalled pyparsing\n2013-09-26 06:11:47   Running setup.py install for pyparsing\n2013-09-26 06:11:47     \n2013-09-26 06:11:47   Running setup.py install for Mako\n2013-09-26 06:11:47     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-09-26 06:11:47     \n2013-09-26 06:11:47     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-09-26 06:11:47     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-09-26 06:11:47     warning: no files found matching \'ez_setup.py\'\n2013-09-26 06:11:47     no previously-included directories found matching \'doc/build/output\'\n2013-09-26 06:11:47     changing mode of /usr/local/bin/mako-render to 755\n2013-09-26 06:11:47 Successfully installed python-quantumclient alembic pyparsing Mako\n2013-09-26 06:11:47 Cleaning up...\n2013-09-26 06:11:47 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-09-26 06:11:47 running develop\n2013-09-26 06:11:47 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-09-26 06:11:47 /usr/bin/python -E -c pass\n2013-09-26 06:11:47 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-09-26 06:11:47 running egg_info\n2013-09-26 06:11:47 writing requirements to quantum.egg-info/requires.txt\n2013-09-26 06:11:47 writing quantum.egg-info/PKG-INFO\n2013-09-26 06:11:47 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-09-26 06:11:47 writing top-level names to quantum.egg-info/top_level.txt\n2013-09-26 06:11:47 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-09-26 06:11:47 writing entry points to quantum.egg-info/entry_points.txt\n2013-09-26 06:11:47 reading manifest template \'MANIFEST.in\'\n2013-09-26 06:11:47 warning: no files found matching \'AUTHORS\'\n2013-09-26 06:11:47 warning: no files found matching \'ChangeLog\'\n2013-09-26 06:11:47 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-09-26 06:11:47 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-09-26 06:11:47 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:47 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-09-26 06:11:47 running build_ext\n2013-09-26 06:11:47 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-09-26 06:11:47 Adding quantum 2013.1.4.a13.g4601b14 to easy-install.pth file\n2013-09-26 06:11:47 Installing quantum-debug script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-nec-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-ryu-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-l3-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-db-manage script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-metadata-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-server script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-09-26 06:11:47 Installing quantum-rootwrap script to /usr/local/bin\n2013-09-26 06:11:47 \n2013-09-26 06:11:47 Installed /opt/stack/new/neutron\n2013-09-26 06:11:47 Processing dependencies for quantum==2013.1.4.a13.g4601b14\n2013-09-26 06:11:47 error: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n2013-09-26 06:11:47 ++ failed\n2013-09-26 06:11:47 ++ local r=1\n2013-09-26 06:11:47 +++ jobs -p\n2013-09-26 06:11:47 ++ kill\n2013-09-26 06:11:47 ++ set +o xtrace\n2013-09-26 06:11:47 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-26-060830\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-392695-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-392695.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-392695/29/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1167554010.7.1375077867008.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-29 06:04:26',0,'2013-07-29 06:04:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #301','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/301/>\n\n------------------------------------------\n[...truncated 9008 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.07 secs:\n    0.37    RoleAPITests.test_get_default_role\n    0.22    HorizonTests.test_lazy_urls\n    0.18    DataTableTests.test_summation_row\n    0.16    DataTableTests.test_table_action_attributes\n    0.14    NetworkTests.test_subnet_create_post_cidr_without_mask\n----------------------------------------------------------------------\nRan 350 tests in 7.023s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive --verbosity=1\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive --verbosity=1\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.2\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.19\npep8==1.4.6\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.1gGAEM6epN\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/301\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/301/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/301/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<35861826.1.1374991344607.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1168103295.8.1355702547593.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-17 00:02:27',0,'2012-12-17 00:02:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #77','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/77/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-rackspace-nova-29976 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/ws/>\nTriggering projects: devstack-update-inprogress\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson8861008435581138032.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone http://zuul.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson4034238706317712802.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_CINDER=1\n+ DEVSTACK_GATE_CINDER=1\n+ export ZUUL_BRANCH=stable/folsom\n+ ZUUL_BRANCH=stable/folsom\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/77\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/77/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/77/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<116a758f.20943.1473ef3556a.Coremail.ifzing@126.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 19:34:00',28800,'2014-07-16 11:34:00',NULL,'[openstack-dev] [devstack][keystone] (98)Address already in use:\n make_sock: could not bind to address [::]:5000 & 0.0.0.0:5000','Hi all, \n\n\nWhen I just set up my develope environment use devstack at CentOS 6.5, \nthat fetch devstack source via github.com and checkout stable/icehouse branch.\nand bellow[1] is the error log fragment.\nI\'m not sure if I am ok to ask my question in this mail list or not,\nbecause I search all of the web and still not resolve it.\nAnyway, I need you help. and, your help is a highly appreciated.\n\n\nThanks.\nJoe.\n\n\n2014-07-16 11:08:53.282 | + sudo sed \'/^Listen/s/^.*$/Listen 0.0.0.0:80/\' -i /etc/httpd/conf/httpd.conf\n2014-07-16 11:08:53.295 | + sudo rm -f \'/var/log/httpd/horizon_*\'\n2014-07-16 11:08:53.310 | + sudo sh -c \'sed -e \"\n2014-07-16 11:08:53.310 |         s,%USER%,stack,g;\n2014-07-16 11:08:53.310 |         s,%GROUP%,stack,g;\n2014-07-16 11:08:53.310 |         s,%HORIZON_DIR%,/opt/stack/horizon,g;\n2014-07-16 11:08:53.310 |         s,%APACHE_NAME%,httpd,g;\n2014-07-16 11:08:53.310 |         s,%DEST%,/opt/stack,g;\n2014-07-16 11:08:53.310 |         s,%HORIZON_REQUIRE%,,g;\n2014-07-16 11:08:53.310 |     \" /home/devstack/files/apache-horizon.template >/etc/httpd/conf.d/horizon.conf\'\n2014-07-16 11:08:53.321 | + start_horizon\n2014-07-16 11:08:53.321 | + restart_apache_server\n2014-07-16 11:08:53.321 | + restart_service httpd\n2014-07-16 11:08:53.321 | + is_ubuntu\n2014-07-16 11:08:53.321 | + [[ -z rpm ]]\n2014-07-16 11:08:53.322 | + \'[\' rpm = deb \']\'\n2014-07-16 11:08:53.322 | + sudo /sbin/service httpd restart\n2014-07-16 11:08:53.361 | Stopping httpd:                  [FAILED]\n2014-07-16 11:08:53.532 | Starting httpd: httpd: Could not reliably determine the server\'s fully qualified domain name, using 127.0.0.1 for ServerName\n2014-07-16 11:08:53.533 | (98)Address already in use: make_sock: could not bind to address [::]:5000\n2014-07-16 11:08:53.533 | (98)Address already in use: make_sock: could not bind to address 0.0.0.0:5000\n2014-07-16 11:08:53.533 | no listening sockets available, shutting down\n2014-07-16 11:08:53.533 | Unable to open logs\n2014-07-16 11:08:53.547 |                                  [FAILED]\n2014-07-16 11:08:53.549 | + exit_trap\n2014-07-16 11:08:53.549 | + local r=1\n2014-07-16 11:08:53.549 | ++ jobs -p\n2014-07-16 11:08:53.550 | + jobs=\n2014-07-16 11:08:53.550 | + [[ -n \'\' ]]\n2014-07-16 11:08:53.550 | + exit 1\n[stack at stack devstack]$\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140716/dcc62cff/attachment.html>\n\n',NULL,NULL),('<116B665C-0A1B-4EE8-8940-E070547C4E52@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-29 12:44:16',-25200,'2014-10-29 19:44:16',NULL,'[Openstack-operators] Ephemeral instances in RBD issue','From what I\'ve seen, yes, full support for RBD ephemeral instances is in Juno.\nJust haven\'t played with it in my lab yet.\n\nOn Oct 29, 2014, at 12:41 PM, David Moreau Simard <dmsimard at iweb.com> wrote:\n\n> Good to know..\n> \n> I\'m aware of the Havana and Icehouse branches but are these fixes upstream in Juno ?\n> \n> --\n> David Moreau Simard\n> \n> \n>> On Oct 29, 2014, at 3:34 PM, Abel Lopez <alopgeek at gmail.com> wrote:\n>> \n>> So, I figured out why this was happening.\n>> The gist of it is, the direct_snapshot doesn\'t start the domain back up. I contacted inktank and they\'re adding what I found to their fork.\n>> \n>> The long story:\n>> in nova/virt/libvirt/driver.py, the snapshot method does everything. the code doesn\'t support live snapshot for lvm or rbd, so we have to do a cold snapshot.\n>> We go into \'managedSave\' ( the instance is suspended to quiesce I/O), the snapshot is taken, then much later, we start a new domain based on the save.\n>> The last commit to jdurin\'s fork splits snapshot right after the \'try direct snapshot\' and adds a \'generic_snapshot\' method. The code for starting up the domain again is in \'generic_snapshot\' which only gets called if the exception \"ImageUnacceptable\" gets raised.\n>> as a quick hack, I just copied the \'new_dom\' lines into \'snapshot\' method and HUZZAH, it works as expected.\n>> \n>> Hopefully we\'ll see a new commit to jdurgin\'s fork for icehouse and havana soon.\n>> \n>> On Oct 26, 2014, at 6:08 AM, Simon Leinen <simon.leinen at switch.ch> wrote:\n>> \n>>> Abel Lopez writes:\n>>>> I saw this last commit to jdurgin\'s nova fork which solves the issue (\n>>>> https://github.com/jdurgin/nova/commit/ea4b5369e4bec4dd7a0ce9f68769600329cda6c6\n>>>> )\n>>>> now a snapshot happens in seconds. \n>>> \n>>>> The problem that we\'ve introduced however, is that about 15-20m after\n>>>> we do a snapshot, the VM is powered off.\n>>>> Every time.\n>>> \n>>> Ouch! Have you checked the logs (nova-compute and maybe libvirtd\'s)?\n>>> \n>>>> I can start the instance back up with `nova start`, but I am leery of\n>>>> pushing this out to prod and having to tell users to expect a shutdown\n>>>> after a snapshot.\n>>> \n>>> Understood.\n>>> \n>>>> Anyone else using this in Havana?\n>>> \n>>> Not me, but I\'m sympathetic with your worries, and want this resolved as\n>>> well.  We\'re using Icehouse with RBD, currently without the \"ephemeral\"\n>>> patches, but we would really like to (re-) activate that part of the\n>>> integration soon.\n>>> \n>>> It\'s maybe worth asking on #ceph or posting to one of the CEPH mailing\n>>> lists, too.\n>>> \n>>> Good luck,\n>>> -- \n>>> Simon.\n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141029/2b837be5/attachment.pgp>\n\n','<9EEC74DE-9552-4A7D-99B5-832E5B51DE7F@iweb.com>',NULL),('<116D75C1-C00E-4798-9592-C25B425F4F04@us.ibm.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-08 17:44:49',-21600,'2013-10-08 23:44:49',NULL,'[OpenStack Foundation] Individual Member Director Elections','exactly. this is my point. \n\n+1 to acting now while the opportunity presents itself\n\nCheers,\n\nChristopher Ferris\nIBM Distinguished Engineer, CTO Cloud Interoperability\nMember, IBM Academy of Technology\nIBM Software Group\nemail:chrisfer at us.ibm.com\nTwitter: christo4ferris\nphone: +1 508 234 2986\n\n> On Oct 8, 2013, at 5:51 PM, \"Ryan Lane\" <rlane at wikimedia.org> wrote:\n> \n>> On Tue, Oct 8, 2013 at 1:01 PM, Troy Toman <troy.toman at rackspace.com> wrote:\n>> \n>> Just to pile on. The mere appearance or possibility of corruption in the system erodes trust. The community can\'t be healthy without that fundamental trust. We have an opportunity to improve the situation and the sooner we do it the better, IMHO. I had hoped we had a change lined up that would move us in the right direction in the next election cycle. Given that is not the case, I think we should put a change up for vote sooner rather than later. We have systems that are proven to be more in line with the values of most of the community. I actually like Monty\'s suggestion of Condorcet because it also lines up with the other voting system we already have in place. Either that, STV or even one vote per candidate would move closer to the values this community has expressed.\n> \n> I\'m going to pile on this as well. Maybe right now we have no issues with board members doing the wrong thing, but that may change in the future. We have pretty clear signs of ballot stuffing right now which shows our voting system is broken. We should fix the broken voting system while we have a sensible board rather than waiting till we have a broken board, since it\'ll then be too late.\n> \n> - Ryan\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131008/51ac5c07/attachment.html>\n\n','<CAC9E6cq0HmaP3jM6g6i_Zjnvh_evnp5OvgGCxZcNNyA9CiZWFA@mail.gmail.com>',NULL),('<116F09E7-94F6-42A4-BF17-DE58044BF950@cern.ch>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 14:40:42',0,'2015-01-08 14:40:42',NULL,'[openstack-dev] [Cinder] volume / host coupling','Hmm. Not sure how widespread installations with multiple Ceph backends are where the\nCinder hosts have access to only one of the backends (which is what you assume, right?)\nBut, yes, if the volume type names are also the same (is that also needed for this to be a\nproblem?), this will be an issue ...\n\nSo, how about providing the information the scheduler does not have by introducing an\nadditional tag to identify ?equivalent? backends, similar to the way some people already\nuse the ?host? option?\n\nThanks!\n Arne\n\n\nOn 08 Jan 2015, at 15:11, Duncan Thomas <duncan.thomas at gmail.com<mailto:duncan.thomas at gmail.com>> wrote:\n\nThe problem is that the scheduler doesn\'t currently have enough info to know which backends are \'equivalent\' and which aren\'t. e.g. If you have 2 ceph clusters as cinder backends, they are indistinguishable from each other.\n\nOn 8 January 2015 at 12:14, Arne Wiebalck <Arne.Wiebalck at cern.ch<mailto:Arne.Wiebalck at cern.ch>> wrote:\nHi,\n\nThe fact that volume requests (in particular deletions) are coupled with certain Cinder hosts is not ideal from an operational perspective:\nif the node has meanwhile disappeared, e.g. retired, the deletion gets stuck and can only be unblocked by changing the database. Some\npeople apparently use the ?host? option in cinder.conf to make the hosts indistinguishable, but this creates problems in other places.\n\nFrom what I see, even for backends that would support it (such as Ceph), Cinder currently does not provide means to ensure that any of\nthe hosts capable of performing a volume operation would be assigned the request in case the original/desired one is no more available,\nright?\n\nIf that is correct, how about changing the scheduling of delete operation to use the same logic as create operations, that is pick any of the\navailable hosts, rather than the one which created a volume in the first place (for backends where that is possible, of course)?\n\nThanks!\n Arne\n\n?\nArne Wiebalck\nCERN IT\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nDuncan Thomas\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150108/c7adea6c/attachment.html>\n\n','<CAOyZ2aHk-mu4j93wYLgtpbXAq-ArZucZbpbrbvjDtFzN5eOEOw@mail.gmail.com>',NULL),('<1170042022.10964185.1351885708863.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 15:48:28',-14400,'2012-11-02 19:48:28',NULL,'[openstack-dev] OpenvSwitch testing w/ SmokeStack on Fedora 17','Just put the finishing touches on an initial SmokeStack Quantum testing configuration that uses OpenvSwitch w/ Libvirt on Fedora 17.\n\nSo now if your Quantum branch passes you should see something like this on your merge proposal:\n\nPatch Set 1: Works for me\nSmokeStack Results (patch set 1):\n        Unit Success: http://smokestack.openstack.org/?go=/jobs/43635\n        OpenvSwitch (Fedora 17) Success: http://smokestack.openstack.org/?go=/jobs/43634\n\nYou can also view results on SmokeStack and/or ReviewDay as well.\n\nCurrently I just have a single test suite called Torpedo running there verifying that things are working when Nova is configured w/ Quantum as a network backend. I hope to have more configurations and tests coming online soon too..\n\nAlso, This configuration is currently running with use_namespaces=False because I was hitting an issue where root was unable to access the ip namespace created by quantum:\n\n  https://bugzilla.redhat.com/show_bug.cgi?id=872689\n\nI\'m curious if anyone else has seen anything similar?\n\nDan\n\n\n',NULL,NULL),('<1170176825.55.1383373810885.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:30:10',0,'2013-11-02 06:30:10',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-tempest-devstack-vm-stable-grizzly #46','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/46/>\n\n\n\n',NULL,NULL),('<1170231594.20836426.1403187094644.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 10:11:34',-14400,'2014-06-19 14:11:34',NULL,'[openstack-dev] [neutron]Performance of security group','\n  Hi it\'s a very interesting topic, I was getting ready to raise\nthe same concerns about our security groups implementation, shihanzhang\nthank you for starting this topic.\n\n  Not only at low level where (with our default security group\nrules -allow all incoming from \'default\' sg- the iptable rules\nwill grow in ~X^2 for a tenant, and, the \"security_group_rules_for_devices\"\nrpc call from ovs-agent to neutron-server grows to message sizes of >100MB,\ngenerating serious scalability issues or timeouts/retries that \ntotally break neutron service.\n\n   (example trace of that RPC call with a few instances\n    http://www.fpaste.org/104401/14008522/)\n\n  I believe that we also need to review the RPC calling mechanism\nfor the OVS agent here, there are several possible approaches to breaking\ndown (or/and CIDR compressing) the information we return via this api call.\n\n\n   So we have to look at two things here:\n\n  * physical implementation on the hosts (ipsets, nftables, ... )\n  * rpc communication mechanisms.\n\n   Best regards,\nMiguel ?ngel.\n\n----- Mensaje original ----- \n\n> Do you though about nftables that will replace {ip,ip6,arp,eb}tables?\n> It also based on the rule set mechanism.\n> The issue in that proposition, it\'s only stable since the begin of the year\n> and on Linux kernel 3.13.\n> But there lot of pros I don\'t list here (leverage iptables limitation,\n> efficient update rule, rule set, standardization of netfilter commands...).\n\n> ?douard.\n\n> On Thu, Jun 19, 2014 at 8:25 AM, henry hly < henry4hly at gmail.com > wrote:\n\n> > we have done some tests, but have different result: the performance is\n> > nearly\n> > the same for empty and 5k rules in iptable, but huge gap between\n> > enable/disable iptable hook on linux bridge\n> \n\n> > On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang < ayshihanzhang at 126.com >\n> > wrote:\n> \n\n> > > Now I have not get accurate test data, but I can confirm the following\n> > > points?\n> > \n> \n> > > 1. In compute node, the iptable\'s chain of a VM is liner, iptable filter\n> > > it\n> > > one by one, if a VM in default security group and this default security\n> > > group have many members, but ipset chain is set, the time ipset filter\n> > > one\n> > > and many member is not much difference.\n> > \n> \n> > > 2. when the iptable rule is very large, the probability of failure that\n> > > iptable-save save the iptable rule is very large.\n> > \n> \n\n> > > At 2014-06-19 10:55:56, \"Kevin Benton\" < blak111 at gmail.com > wrote:\n> > \n> \n\n> > > > This sounds like a good idea to handle some of the performance issues\n> > > > until\n> > > > the ovs firewall can be implemented down the the line.\n> > > \n> > \n> \n> > > > Do you have any performance comparisons?\n> > > \n> > \n> \n> > > > On Jun 18, 2014 7:46 PM, \"shihanzhang\" < ayshihanzhang at 126.com > wrote:\n> > > \n> > \n> \n\n> > > > > Hello all,\n> > > > \n> > > \n> > \n> \n\n> > > > > Now in neutron, it use iptable implementing security group, but the\n> > > > > performance of this implementation is very poor, there is a bug:\n> > > > > https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this\n> > > > > problem.\n> > > > > In\n> > > > > his test, w ith default security groups(which has remote security\n> > > > > group),\n> > > > > beyond 250-300 VMs, there were around 6k Iptable rules on evry\n> > > > > compute\n> > > > > node,\n> > > > > although his patch can reduce the processing time, but it don\'t solve\n> > > > > this\n> > > > > problem fundamentally. I have commit a BP to solve this problem:\n> > > > > https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security\n> > > > \n> > > \n> > \n> \n> > > > > There are other people interested in this it?\n> > > > \n> > > \n> > \n> \n\n> > > > > _______________________________________________\n> > > > \n> > > \n> > \n> \n> > > > > OpenStack-dev mailing list\n> > > > \n> > > \n> > \n> \n> > > > > OpenStack-dev at lists.openstack.org\n> > > > \n> > > \n> > \n> \n> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > > \n> > > \n> > \n> \n\n> > > _______________________________________________\n> > \n> \n> > > OpenStack-dev mailing list\n> > \n> \n> > > OpenStack-dev at lists.openstack.org\n> > \n> \n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n\n> > _______________________________________________\n> \n> > OpenStack-dev mailing list\n> \n> > OpenStack-dev at lists.openstack.org\n> \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAKRF=eciO6YVdGmkZgOPZuC9C+j_a_dL9EVSuyg0NmKfDaf+jA@mail.gmail.com>',NULL),('<1170400906.46.1375596805182.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-04 06:13:25',0,'2013-08-04 06:13:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #309','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/309/>\n\n------------------------------------------\n[...truncated 950 lines...]\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.20\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: \n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, None\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 74.33 secs:\n    17.37    TestGlanceControl.test_bouncing\n    14.85    TestScrubber.test_delayed_delete\n    14.24    TestGlanceControl.test_reload\n    14.01    TestGlanceControl.test_respawn\n    13.86    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 591.919s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python26-stable-folsom-309\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npbr==0.5.20\npep8==1.1\npycparser==2.09.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.CxsHRYwB8F\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/309\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/309/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-1/309\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1171193522.16.1375250792640.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-31 06:06:32',0,'2013-07-31 06:06:32',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-docs-stable-folsom #303','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/303/changes>\n\n\n\n','<1651400964.11.1375164141559.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1171962628.133.1384931331810.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-20 07:08:51',0,'2013-11-20 07:08:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-python26-stable-havana #1','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/1/>\n\n------------------------------------------\n[...truncated 398 lines...]\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nERROR:neutron.plugins.linuxbridge.agent.linuxbridge_neutron_agent:Failed reporting state!\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py\",> line 801, in _report_state\n    self.agent_state)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/agent/rpc.py\",> line 74, in report_state\n    return self.cast(context, msg, topic=self.topic)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/proxy.py\",> line 171, in cast\n    rpc.cast(context, self._get_topic(topic), msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/__init__.py\",> line 158, in cast\n    return _get_impl().cast(CONF, context, topic, msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 166, in cast\n    check_serialize(msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 131, in check_serialize\n    json.dumps(msg)\n  File \"/usr/lib64/python2.6/json/__init__.py\", line 230, in dumps\n    return _default_encoder.encode(obj)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 367, in encode\n    chunks = list(self.iterencode(o))\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 317, in _iterencode\n    for chunk in self._iterencode_default(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 323, in _iterencode_default\n    newobj = self.default(o)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 344, in default\n    raise TypeError(repr(o) + \" is not JSON serializable\")\nTypeError: <MagicMock name=\'LinuxBridgeManager().local_ip\' id=\'261113616\'> is not JSON serializable\nERROR:neutron.plugins.linuxbridge.agent.linuxbridge_neutron_agent:Failed reporting state!\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py\",> line 801, in _report_state\n    self.agent_state)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/agent/rpc.py\",> line 74, in report_state\n    return self.cast(context, msg, topic=self.topic)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/proxy.py\",> line 171, in cast\n    rpc.cast(context, self._get_topic(topic), msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/__init__.py\",> line 158, in cast\n    return _get_impl().cast(CONF, context, topic, msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 166, in cast\n    check_serialize(msg)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/openstack/common/rpc/impl_fake.py\",> line 131, in check_serialize\n    json.dumps(msg)\n  File \"/usr/lib64/python2.6/json/__init__.py\", line 230, in dumps\n    return _default_encoder.encode(obj)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 367, in encode\n    chunks = list(self.iterencode(o))\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 309, in _iterencode\n    for chunk in self._iterencode_dict(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 275, in _iterencode_dict\n    for chunk in self._iterencode(value, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 317, in _iterencode\n    for chunk in self._iterencode_default(o, markers):\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 323, in _iterencode_default\n    newobj = self.default(o)\n  File \"/usr/lib64/python2.6/json/encoder.py\", line 344, in default\n    raise TypeError(repr(o) + \" is not JSON serializable\")\nTypeError: <MagicMock name=\'LinuxBridgeManager().local_ip\' id=\'246821776\'> is not JSON serializable\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.kxz0vvtuRO/tmpgrsXbb\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.kxz0vvtuRO/tmpcAYhgd\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.kxz0vvtuRO/tmpKbTGK4\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.kxz0vvtuRO/tmpS9eUUR\nRan 9383 tests in 2164.925s\nPASSED (id=0, skips=328)\nSlowest Tests\nTest id                                                                                                                Runtime (s)\n---------------------------------------------------------------------------------------------------------------------  -----------\nneutron.tests.unit.nicira.test_nvp_sync.NvpSyncTestCase.test_sync_chunk_larger_maxpagesize_triggers_multiple_requests  14.865\nneutron.tests.unit.nicira.test_edge_router.ServiceRouterTestCase.test_floatingip_update_different_router               12.307\nneutron.tests.unit.nicira.test_nicira_plugin.TestNiciraPortsV2.test_recycling                                          10.569\nneutron.tests.unit.ryu.test_ryu_plugin.TestRyuPortsV2.test_recycling                                                    9.782\nneutron.tests.unit.nicira.test_edge_router.NvpRouterTestCase.test_floatingip_update_different_router                    9.513\nneutron.tests.unit.nec.test_router.NecRouterOpenFlowTestCase.test_floatingip_update_different_router                    8.840\nneutron.tests.unit.test_extension_extraroute.ExtraRouteDBSepTestCase.test_floatingip_update_different_router            8.743\nneutron.tests.unit.test_l3_plugin.L3NatDBIntTestCaseXML.test_floatingip_update_different_router                         8.219\nneutron.tests.unit.ml2.test_ml2_plugin.TestMl2PortsV2.test_recycling                                                    8.211\nneutron.tests.unit.nicira.test_nicira_plugin.TestNiciraL3NatTestCase.test_floatingip_update_different_router            8.042\n___________________________________ summary ____________________________________\n  py26: commands succeeded\n  congratulations :)\n+ result=0\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==2.0.10\nalembic==0.6.0\namqp==1.3.3\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\ncliff==1.4.5\ncmd2==0.6.7\nconfigobj==4.7.2\ncoverage==3.7\ndiscover==0.4.0\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonrpclib==0.1.3\nkombu==3.0.5\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nneutron==jenkins.periodic.neutron.python26.stable.havana.1\nordereddict==1.1\noslo.config==1.2.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npyflakes==0.7.3\npyparsing==2.0.1\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-subunit==0.0.15\npytz==2013.8\npyudev==0.16.1\nrepoze.lru==0.6\nrequests==2.0.1\nsetuptools-git==1.0\nsimplejson==3.3.1\nsix==1.4.1\nstevedore==0.12\ntestrepository==0.0.18\ntesttools==0.9.33\nwaitress==0.8.7\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nBuild timed out (after 40 minutes). Marking the build as failed.\n/usr/local/jenkins/slave_scripts/run-unittests.sh: line 58: 16801 Terminated              .tox/$venv/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\n+ gzip -9 ./subunit_log.txt\n++ rm -rf /tmp/tmp.kxz0vvtuRO\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-havana/centos6-8\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-stable-havana/centos6-8/1\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1173440105.83550.1387470109382.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 17:21:49',3600,'2013-12-19 16:21:49',NULL,'[openstack-dev] [nova] VM diagnostics - V3 proposal','Ah, I think I\'ve responded too fast, sorry.\n\nmeter-list provides a list of various measurements that are being done per resource.\nsample-list provides a list of samples per every meter: ceilometer sample-list --meter cpu_util -q resource_id=vm_uuid\nThese samples can be aggregated over a period of time per every meter and resource:\nceilometer statistics -m cpu_util -q \'timestamp>START;timestamp<=END;resource_id=vm_uuid\' --period 3600\n\nVladik\n\n\n\n----- Original Message -----\n> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> To: \"Vladik Romanovsky\" <vladik.romanovsky at enovance.com>\n> Cc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>, \"John\n> Garbutt\" <john at johngarbutt.com>\n> Sent: Thursday, 19 December, 2013 10:37:27 AM\n> Subject: Re: [openstack-dev] [nova] VM diagnostics - V3 proposal\n> \n> On Thu, Dec 19, 2013 at 03:47:30PM +0100, Vladik Romanovsky wrote:\n> > I think it was:\n> > \n> > ceilometer sample-list -m cpu_util -q \'resource_id=vm_uuid\'\n> \n> Hmm, a standard devstack deployment of ceilometer doesn\'t seem to\n> record any performance stats at all - just shows me the static\n> configuration parameters :-(\n> \n>  ceilometer meter-list  -q \'resource_id=296b22c6-2a4d-4a8d-a7cd-2d73339f9c70\'\n> +---------------------+-------+----------+--------------------------------------+----------------------------------+----------------------------------+\n> | Name                | Type  | Unit     | Resource ID\n> | | User ID                          | Project ID\n> | |\n> +---------------------+-------+----------+--------------------------------------+----------------------------------+----------------------------------+\n> | disk.ephemeral.size | gauge | GB       |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> | disk.root.size      | gauge | GB       |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> | instance            | gauge | instance |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> | instance:m1.small   | gauge | instance |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> | memory              | gauge | MB       |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> | vcpus               | gauge | vcpu     |\n> | 296b22c6-2a4d-4a8d-a7cd-2d73339f9c70 | 96f9a624a325473daf4cd7875be46009 |\n> | ec26984024c1438e8e2f93dc6a8c5ad0 |\n> +---------------------+-------+----------+--------------------------------------+----------------------------------+----------------------------------+\n> \n> \n> If the admin user can\'t rely on ceilometer guaranteeing availability of\n> the performance stats at all, then I think having an API in nova to report\n> them is in fact justifiable. In fact it is probably justifiable no matter\n> what as a fallback way to check that VMs are doing in the fact of failure\n> of ceilometer / part of the cloud infrastructure.\n> \n> Daniel\n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n\n\n','<20131219153727.GI6573@redhat.com>',NULL),('<1173825287.37.1374645739501.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-24 06:02:19',0,'2013-07-24 06:02:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #296','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/296/>\n\n------------------------------------------\n[...truncated 56 lines...]\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/296/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python26-stable-folsom-296\', \'SSH_CLIENT\': \'198.101.231.203 60346 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/bin:/bin:/usr/bin\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python26-stable-folsom\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NLSPATH\': \'/usr/dt/lib/nls/msg/%L/%N.cat\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'centos6 centos6-3\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.q9NGM1rwce\', \'DEBEMAIL\': \'hudson at openstack.org\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'BUILD_ID\': \'2013-07-24_06-00-25\', \'BUILD_NUMBER\': \'296\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'a6cf6c4e-27dd-48e1-a884-f250cdf49e29\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'centos6-3\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#296\', \'XFILESEARCHPATH\': \'/usr/dt/app-defaults/%L/Dt\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 60346 166.78.7.205 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-PBxXiF/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-PBxXiF/d2to1-0.2.10/egg-dist-tmp-2ZWNDd\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-Zn_56l/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-Zn_56l/setuptools-git-1.0/egg-dist-tmp-AfjEHx\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-7EsTJK/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-7EsTJK/d2to1-0.2.10/egg-dist-tmp-VmYX6e\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-nH6smu/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-nH6smu/setuptools-git-1.0/egg-dist-tmp-8alo8M\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-TgY8GE/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-TgY8GE/d2to1-0.2.10/egg-dist-tmp-sN2KYa\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.q9NGM1rwce/easy_install-pgNrzQ/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.q9NGM1rwce/easy_install-pgNrzQ/setuptools-git-1.0/egg-dist-tmp-R0NcHU\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.q9NGM1rwce\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/296\n[SCP] Copying console log.\n\n\n','<708418888.30.1374559482189.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<117473994.4.1376287528772.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-12 06:05:28',0,'2013-08-12 06:05:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-python26-stable-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 1560 lines...]\n    test_initialize_connection                                   OK    0.03\n    test_remove_export                                           OK    0.02\nExceptionTest\n    test_exception_with_none_code_throws_500                     OK    0.01\n    test_non_cinder_exception_mapping                            OK    0.01\n    test_non_cinder_notfound_exception_mapping                   OK    0.01\n    test_quota_error_mapping                                     OK    0.01\n    test_safe_exceptions_are_described_in_faults                 OK    0.01\n    test_unsafe_exceptions_are_not_described_in_faults           OK    0.01\nTestLoaderNormalFilesystem\n    test_app_found                                               OK    0.01\n    test_app_not_found                                           OK    0.00\n    test_config_found                                            OK    0.00\nTestLoaderNothingExists\n    test_config_not_found                                        OK    0.01\nTestWSGIServer\n    test_app                                                     OK    0.03\n    test_app_using_ipv6_and_ssl                                  OK    0.04\n    test_app_using_ssl                                           OK    0.04\n    test_no_app                                                  OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nDriverTestCase\n    test_config_options                                          OK    0.00\n    test_copy_image_to_volume_non_xenserver_case                 OK    0.00\n    test_copy_image_to_volume_xenserver_case                     OK    0.00\n    test_copy_volume_to_image_non_xenserver_case                 OK    0.00\n    test_copy_volume_to_image_xenserver_case                     OK    0.00\n    test_create_export_does_not_raise_exception                  OK    0.00\n    test_create_snapshot                                         OK    0.00\n    test_create_volume                                           OK    0.00\n    test_create_volume_from_snapshot                             OK    0.00\n    test_delete_snapshot                                         OK    0.00\n    test_delete_volume                                           OK    0.00\n    test_do_setup                                                OK    0.00\n    test_get_volume_stats_reports_required_keys                  OK    0.00\n    test_get_volume_stats_reports_unknown_cap                    OK    0.00\n    test_initialize_connection                                   OK    0.00\n    test_initialize_connection_null_values                       OK    0.00\n    test_remove_export_does_not_raise_exception                  OK    0.00\n    test_reported_driver_type                                    OK    0.00\n    test_use_glance_plugin_to_copy_image_to_volume_fail          OK    0.00\n    test_use_glance_plugin_to_copy_image_to_volume_success       OK    0.00\n    test_use_glance_plugin_to_upload_volume                      OK    0.00\n    test_use_image_utils_to_pipe_bytes_to_volume                 OK    0.00\n    test_use_image_utils_to_upload_volume                        OK    0.00\nToolsTest\n    test_get_this_vm_uuid                                        OK    0.00\n    test_stripped_first_line_of                                  OK    0.00\nXIVVolumeDriverTest\n    test_create_volume                                           OK    0.01\n    test_create_volume_should_fail_if_no_pool_space_left         OK    0.01\n    test_delete_volume                                           OK    0.01\n    test_delete_volume_should_fail_for_not_existing_volume       OK    0.01\n    test_initialize_connection                                   OK    0.01\n    test_initialize_connection_should_fail_for_non_existing_volumeOK    0.01\n    test_initialized_should_set_xiv_info                         OK    0.01\n    test_setup_should_fail_if_connection_is_invalid              OK    0.01\n    test_setup_should_fail_if_credentials_are_invalid            OK    0.01\n    test_terminate_connection                                    OK    0.01\n    test_terminate_connection_should_fail_on_non_attached_volume OK    0.01\n    test_terminate_connection_should_fail_on_non_existing_volume OK    0.02\n    test_volume_exists                                           OK    0.01\nZadaraVPSADriverTestCase\n    test_bad_http_response                                       OK    0.01\n    test_create_destroy                                          OK    0.02\n    test_create_destroy_multiple                                 OK    0.03\n    test_delete_without_detach                                   OK    0.04\n    test_destroy_non_existent                                    OK    0.01\n    test_empty_apis                                              OK    0.01\n    test_no_active_ctrl                                          OK    0.01\n    test_ssl_use                                                 OK    0.01\n    test_volume_attach_detach                                    OK    0.02\n    test_volume_attach_multiple_detach                           OK    0.04\n    test_wrong_attach_params                                     OK    0.01\n    test_wrong_detach_params                                     OK    0.03\n    test_wrong_login_reply                                       OK    0.01\n\n======================================================================\nERROR: Test glance version set by arg to GlanceClientWrapper\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/tests/image/test_glance.py\",> line 576, in test_glance_version_by_arg\n    9292, version=2)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 103, in __init__\n    use_ssl, version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 117, in _create_static_client\n    self.use_ssl, self.version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 73, in _create_glance_client\n    return glanceclient.Client(str(version), endpoint, **params)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/client.py\",> line 22, in Client\n    return client_class(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/client.py\",> line 43, in __init__\n    self._get_member_model())\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/client.py\",> line 50, in _get_member_model\n    schema = self.schemas.get(\'member\')\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/schemas.py\",> line 53, in get\n    _, raw_schema = self.http_client.json_request(\'GET\', uri)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/common/http.py\",> line 250, in json_request\n    resp, body_iter = self._http_request(url, method, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/common/http.py\",> line 216, in _http_request\n    raise exc.InvalidEndpoint(message=message)\nInvalidEndpoint: Error finding address for fake_host: [Errno -2] Name or service not known\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X GET -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' http://fake_host:9292/v2/schemas/member\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Test glance version set by flag is honoured\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/tests/image/test_glance.py\",> line 564, in test_glance_version_by_flag\n    9292)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 103, in __init__\n    use_ssl, version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 117, in _create_static_client\n    self.use_ssl, self.version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/cinder/image/glance.py\",> line 73, in _create_glance_client\n    return glanceclient.Client(str(version), endpoint, **params)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/client.py\",> line 22, in Client\n    return client_class(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/client.py\",> line 43, in __init__\n    self._get_member_model())\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/client.py\",> line 50, in _get_member_model\n    schema = self.schemas.get(\'member\')\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/v2/schemas.py\",> line 53, in get\n    _, raw_schema = self.http_client.json_request(\'GET\', uri)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/common/http.py\",> line 250, in json_request\n    resp, body_iter = self._http_request(url, method, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/glanceclient/common/http.py\",> line 216, in _http_request\n    raise exc.InvalidEndpoint(message=message)\nInvalidEndpoint: Error finding address for fake_host: [Errno -2] Name or service not known\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X GET -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' http://fake_host:9292/v2/schemas/member\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 10.31 secs:\n    2.47    TestMigrations.test_postgresql_opportunistically\n    2.01    SolidFireVolumeTestCase.test_create_with_qos_type\n    2.01    SolidFireVolumeTestCase.test_create_volume_with_qos\n    2.01    SolidFireVolumeTestCase.test_create_volume\n    1.80    ScalityDriverTestCase.test_delete_snapshot\n----------------------------------------------------------------------\nRan 1323 tests in 72.142s\n\nFAILED (SKIP=52, errors=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\ncinder==jenkins.periodic.cinder.python26.stable.grizzly.5\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhp3parclient==1.0.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.12\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npython-glanceclient==0.10.0\npython-keystoneclient==0.3.1\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.10\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=178\n+ \'[\' 178 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.aOLyEn3lfx\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-cinder-python26-stable-grizzly/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-python26-stable-grizzly/centos6-10/5\n[SCP] Copying console log.\n\n\n','<207971023.0.1376201126589.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1175459034.899480.1375094593900.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 18:43:12',28800,'2013-07-29 10:43:12',NULL,'[Openstack] can not access vm via vnc(grizzly)','vnc is supported by qemu, so we needn\'t to install a vnc-server into instance.\nyou may check the vnc connection by connecting it directly on the host by a vnc client,\n1. virsh dumpxml ${instance-uuid}\n2. get the vnc port: like 5900 or 59XX\n3. get the vnc bind address: like 127.0.0.1 or 0.0.0.0(same as the vncserver_listen = 127.0.0.1 in nova.conf)\n4. make a port forwarding to the host by ssh and set the proxy in vnc client if your vncserver_listen = 127.0.0.1\n5. set the target ip address to the host of instance and the vnc port 59XX to the vnc client and connect to the instance\n\n<graphics type=\'vnc\' port=\'5900\' autoport=\'yes\' listen=\'127.0.0.1\' keymap=\'en-us\'>\n      <listen type=\'address\' address=\'127.0.0.1\'/>\n    </graphics>\n\n\nif this is ok, then may be the vncproxy type you config is wrong, there are two types :\'novnc\' and \'xvpvnc\', and in my env, the \'novnc\' is used,\nthe novnc service need be installed on the host,\nthen you can get the vnc-console by \'nova get-vnc-console ${instance-uuid} novnc\',\nhzwangpan at myhost:~$ nova get-vnc-console e4975b9f-95d0-4223-8df9-7d4f017b5de7 novnc\n+-------+-------------------------------------------------------------------------------------+\n| Type  | Url                                                                                 |\n+-------+-------------------------------------------------------------------------------------+\n| novnc | http://xxx.xxx.xxx.xxx:6080/vnc_auto.html?token=45fc8fc6-4488-4b4f-9b20-53de67d9ef8d |\n+-------+-------------------------------------------------------------------------------------+\nthe ip of Url is same as the config novncproxy_base_url = http://xxx.xxx.xxx.xxx:6080/vnc_auto.html in the nova.conf.\nthen you can try to open the url in the browser like google chrome of firefox(html5/websocket should be supported).\nthe vnc console will be open if there is no error.\n\n\n2013-07-29\n\n\n\nWangpan\n\n\n\n????Mahardhika <mahardika.gilang at andalabs.com>\n?????2013-07-29 16:07\n???Re: [Openstack] can not access vm via vnc(grizzly)\n????\"sam lee\"<lixq2000 at gmail.com>,\"openstack\"<openstack at lists.openstack.org>\n???\n\nHave you tried to used console on horizon dashboard? vnc must be installed on instance first, like tiger-vnc\nOn 7/29/2013 2:53 PM, sam lee wrote:\n\nyes.\n\n\n\n2013/7/29 Mahardhika <mahardika.gilang at andalabs.com>\n\nDoes the nova novnc start well? \n\nOn 7/29/2013 2:14 PM, sam lee wrote:\n\nHi all, \n\n\n        I am installing openstack grizzly on redhat 6.4. when I created a instances successfully and tried to access it via vnc, it had no response. the log file xvpvncproxy.log shows an error as below:\n\n\nHost: 172.16.2.91:6081\nReferer: http://172.16.2.91/dashboard/project/instances/e1f21ec1-7dfd-452b-ab3e-88ecfabc0929/\nUser-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31\n2013-07-29 10:35:18.231 3111 INFO nova.XCP VNC Proxy.wsgi.server [-] Traceback (most recent call last):\n  File \"/usr/lib/python2.6/site-packages/eventlet/wsgi.py\", line 393, in handle_one_response\n    for data in result:\nTypeError: \'NoneType\' object is not iterable\n\n\nAnyone has encountered the same question before? thanks in advance.\n\n\n \n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n-- \nRegards,\nMahardhika Gilang\n\nPT. Andalabs Technology \nGedung Gravira\nJl. Cideng Barat no. 54\nJakarta Pusat 10150\n\nHP : 0852 139 55861\nEmail : mahardika.gilang at andalabs.com \n\n\n\n\n\n-- \nRegards,\nMahardhika Gilang\n\nPT. Andalabs Technology \nGedung Gravira\nJl. Cideng Barat no. 54\nJakarta Pusat 10150\n\nHP : 0852 139 55861\nEmail : mahardika.gilang at andalabs.com \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/20505253/attachment.html>\n\n','<51F622B8.7080005@andalabs.com>',NULL),('<1176423719.139.1353286024486.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-19 00:47:04',0,'2012-11-19 00:47:04',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #11','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/11/>\n\n------------------------------------------\n[...truncated 13741 lines...]\n\n======================================================================\nERROR: 409 error when instance states are resized,None\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 164, in test_create_image_when_vm_eq_resized_task_eq_none\n    self._test_create_image_409_base(\"resized\", None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'task_state\': \'NULL\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_confirming\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 124, in test_create_image_when_vm_eq_resized_task_eq_resize_confirming\n    self._test_create_image_409_base(\"resized\", \"resize_confirming\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_finish\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 116, in test_create_image_when_vm_eq_resized_task_eq_resize_finish\n    self._test_create_image_409_base(\"resized\", \"resize_finish\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_migrated\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 112, in test_create_image_when_vm_eq_resized_task_eq_resize_migrated\n    self._test_create_image_409_base(\"resized\", \"resize_migrated\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_migrating\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 108, in test_create_image_when_vm_eq_resized_task_eq_resize_migrating\n    self._test_create_image_409_base(\"resized\", \"resize_migrating\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'task_state\': \'NULL\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_prep\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 104, in test_create_image_when_vm_eq_resized_task_eq_resize_prep\n    self._test_create_image_409_base(\"resized\", \"resize_prep\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: 409 error when instance states are resized,resize_reverting\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 120, in test_create_image_when_vm_eq_resized_task_eq_resize_reverting\n    self._test_create_image_409_base(\"resized\", \"resize_reverting\")\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'task_state\': \'NULL\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\'}\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 227, in run\n    self.tearDown()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 350, in tearDown\n    self.teardownContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 366, in teardownContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 42, in tearDownClass\n    cls.update_state(server[\'id\'], \"active\", None)\n  File \"/opt/stack/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type boolean but expression is of type integer\nLINE 1: UPDATE instances SET deleted=0, vm_state=\'active\', task_stat...\n                                     ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET deleted=%(deleted)s, vm_state=%(vm_state)s, task_state=%(task_state)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': 0, \'vm_state\': \'active\', \'uuid_1\': u\'087dd406-c9f9-4938-8f45-e12c8c6f2389\', \'task_state\': \'NULL\'}\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 500 tests in 1599.088s\n\nFAILED (SKIP=53, errors=23)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/screen-swift.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/11/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<862653023.113.1353198635655.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1176528909.13.1379572314523.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-19 06:31:54',0,'2013-09-19 06:31:54',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #22','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/22/>\n\n------------------------------------------\n[...truncated 20472 lines...]\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          198.445\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  176.100\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  66.639\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         38.163\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         37.877\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     33.393\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_manual_disk_config[gate]   31.830\ntempest.api.compute.images.test_images.ImagesTestJSON.test_create_image_from_stopped_server[gate,negative]               31.527\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]          31.402\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       31.115\n\n----------------------------------------------------------------------\nRan 1214 tests in 1353.170s\n\nOK (skipped=74)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-327888-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-327888.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-327888/22/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1773490829.10.1379485764905.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1176812494.20412691.1358336291285.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-16 06:38:11',-18000,'2013-01-16 11:38:11',NULL,'[openstack-dev] [glance] support for multi-disk OVF packages','\nFolks,\n\nI threw this question out on IRC yesterday, moving to the ML to see\nif anyone has any thoughts on it ...\n\nTL;DR: what are the supported glance approach(es) to registering\nmulti-disk OVF packages?\n\nSo say we have an OVF manifest referencing multiple disks, e.g. a\ncouple .vmdk files.\n\nDoes glance/nova even support the idea of tar\'ing up the .ovf and\n.vmdk files into a single .ova before registering with glance?\n\nOr is the only way to merge the .vmdk files, and register that alone?\n\nIf so, does the supposed glance support for the OVF container type\nreally mean anything at all?\n\nIIRC jaypipes proposed many moons ago that the ovf container format be\ndropped in favor of a new consolidated ova format - did that idea get\nany traction at all?\n\nCheers,\nEoghan\n\n\n','<2135320110.20401475.1358334142831.JavaMail.root@redhat.com>',NULL),('<1176824184.31.1378275576681.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:19:36',0,'2013-09-04 06:19:36',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-docs-stable-grizzly #20','See <https://jenkins01.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/20/changes>\n\n\n\n','<2102085668.24.1378188491118.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1177219411.531.1367388632780.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-01 06:10:32',0,'2013-05-01 06:10:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly-centos6 #1','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/1/>\n\n------------------------------------------\n[...truncated 5093 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:10:27,704 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-01 06:10:27,705 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:10:27,706 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,707 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,708 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-01 06:10:27,708 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-01 06:10:27,709 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-01 06:10:27  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-01 06:10:27,710 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:10:27    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-01 06:10:27,711 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,717 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.717036\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.717036\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27,718 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,719 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,720 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,721 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27,722 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.721702\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.721702\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27,723 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,724 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,725 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:10:27,726 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,727 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,729 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27,730 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.729020\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.729020\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27,731 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,732 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,732 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:10:27,733 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,734 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,736 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27,737 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.736165\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.736165\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27,738 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,739 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,740 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:10:27,741 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,742 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,743 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-01 06:10:27,745 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-01 06:10:27,746 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.745275\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-01T06:10:27.745275\', resource_metadata={}) from 0 transformer\n2013-05-01 06:10:27,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,748 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27,749 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-01 06:10:27,750 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-01 06:10:27,750 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-01 06:10:27    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 20.483s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.centos6.1\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a89.g69faf22\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a454.gdccbcc8\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.p07h8Qhi7H\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly-centos6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly-centos6/1\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<117753364.370982.1389595593185.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-13 01:46:33',-18000,'2014-01-13 06:46:33',NULL,'[Openstack-docs] Operations Guide - scrub or add?','\nHi Anne, \nThis is a revisit to that Ops-Guide thread before Christmas. \n\nThe Ops Guide is getting an O\'Reilly\'s edit, and an Ops-people sprint.\nI\'d found someone to add RHEL-architecture info or, if people wanted, we could work on scrubbing the Ubuntu references to make it more generic.\n\nFor the life of me, I can\'t find the decision. Was one made, or has it already happened?\n\nthanks, \nSummer\n\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n\n','<1777164087.370147.1389595407381.JavaMail.root@redhat.com>',NULL),('<1177811552.294.1354925628651.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-08 00:13:48',0,'2012-12-08 00:13:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #68','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/68/>\n\n------------------------------------------\n[...truncated 11052 lines...]\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nFailure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\n\n======================================================================\nERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n    CONFIG = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n    super(UsersTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n    super(BaseIdentityAdminTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n    super(UsersTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n    super(BaseIdentityAdminTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n    super(VolumesActionsTest, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n    super(VolumesGetTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n    super(VolumesGetTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n    super(VolumeListTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n    super(VolumeListTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 1 test in 0.018s\n\nFAILED (errors=8)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/rabbit at devstack-1354921860-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/rabbit at devstack-1354921860.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1264022130.276.1354839286747.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1179094072.138.1385016866568.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-21 06:54:26',0,'2013-11-21 06:54:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-stable-grizzly #59','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-grizzly/59/>\n\n\n\n','<1889667481.130.1384845069844.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1179142074.165.1368079524739.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-09 06:05:24',0,'2013-05-09 06:05:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #29','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/29/>\n\n------------------------------------------\n[...truncated 158 lines...]\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking anyjson>=0.2.4 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Downloading anyjson-0.3.3.tar.gz\n  Running setup.py egg_info for package anyjson\nDownloading/unpacking Flask==0.9 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package Flask\n    warning: no files found matching \'*\' under directory \'tests\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'tests\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'tests\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'examples\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'examples\'\n    no previously-included directories found matching \'docs/_build\'\n    no previously-included directories found matching \'docs/_themes/.git\'\nDownloading/unpacking pecan>=0.2.0 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package pecan\nDownloading/unpacking stevedore>=0.7 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Running setup.py egg_info for package stevedore\n    warning: no files found matching \'*.py\' under directory \'tests\'\nDownloading/unpacking python-glanceclient (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 13))\n  Running setup.py egg_info for package python-glanceclient\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0b1-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-novaclient>=2.6.10 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 14))\n  Running setup.py egg_info for package python-novaclient\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0b1-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient>=0.2.3 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 15))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no files found matching \'python-keystoneclient\'\nDownloading/unpacking python-swiftclient (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 16))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no files found matching \'swiftclient/versioninfo\'\nDownloading/unpacking lxml (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 17))\n  Running setup.py egg_info for package lxml\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'bugtrack_url\'\n      warnings.warn(msg)\n    Building lxml version 3.2.0.\n    Building without Cython.\n    Using build configuration of libxslt 1.1.26\n    Building against libxml2/libxslt in the following directory: /usr/lib\n    warning: no previously-included files found matching \'*.py\'\n    warning: no files found matching \'*.txt\' under directory \'src/lxml/tests\'\nDownloading/unpacking requests<1.0 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 18))\n  Running setup.py egg_info for package requests\n    warning: no files found matching \'tests/*.\'\nDownloading/unpacking extras (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 19))\n  Downloading extras-0.0.3.tar.gz\n  Running setup.py egg_info for package extras\nDownloading/unpacking wsme>=0.5b1 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 20))\n  Real name of requirement wsme is WSME\n  Running setup.py egg_info for package wsme\n    \n    Installed <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/wsme/d2to1-0.2.10-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*.ini\' under directory \'tests\'\nDownloading/unpacking pyyaml (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 21))\n  Real name of requirement pyyaml is PyYAML\n  Running setup.py egg_info for package pyyaml\nDownloading/unpacking oslo.config>=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 22))\n  Running setup.py egg_info for package oslo.config\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking happybase>=0.4 (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 23))\n  Running setup.py egg_info for package happybase\nDownloading/unpacking Cheetah>=2.4.4 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package Cheetah\n    warning: no files found matching \'examples\'\n    warning: no files found matching \'docs\'\n    warning: no files found matching \'bin\'\n    warning: no files found matching \'*\' under directory \'docs\'\n    warning: no files found matching \'*\' under directory \'examples\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'docs\'\nDownloading/unpacking amqplib>=0.6.1 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package amqplib\nDownloading/unpacking boto (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package boto\n    warning: no files found matching \'boto/mturk/test/*.doctest\'\n    warning: no files found matching \'boto/mturk/test/.gitignore\'\nDownloading/unpacking routes>=1.12.3 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Real name of requirement routes is Routes\n  Running setup.py egg_info for package routes\n    warning: no previously-included files matching \'.DS_Store\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgignore\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgtags\' found anywhere in distribution\nDownloading/unpacking greenlet>=0.3.1 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package greenlet\nDownloading/unpacking PasteDeploy>=1.5.0 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Downloading PasteDeploy-1.5.0.tar.gz\n  Running setup.py egg_info for package PasteDeploy\nDownloading/unpacking paste (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Real name of requirement paste is Paste\n  Running setup.py egg_info for package paste\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build/_sources\'\nDownloading/unpacking netaddr>=0.7.6 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package netaddr\n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking suds>=0.4 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package suds\nDownloading/unpacking paramiko (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package paramiko\nDownloading/unpacking pyasn1 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package pyasn1\nDownloading/unpacking httplib2 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package httplib2\nDownloading/unpacking python-cinderclient>=1.0.1 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package python-cinderclient\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0b1-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package python-quantumclient\nDownloading/unpacking websockify<0.4 (from nova==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Downloading websockify-0.3.0.tar.gz\n  Running setup.py egg_info for package websockify\nRequirement already satisfied (use --upgrade to upgrade): wsgiref in /usr/lib/python2.6 (from glance==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 12))\nDownloading/unpacking pycrypto>=2.1.0alpha1 (from glance==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 12))\n  Running setup.py egg_info for package pycrypto\nDownloading/unpacking passlib (from glance==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 12))\n  Running setup.py egg_info for package passlib\n    warning: no files found matching \'passlib/*.cfg\'\n    no previously-included directories found matching \'*.komodoproject\'\nDownloading/unpacking jsonschema (from glance==2013.1->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 12))\n  Downloading jsonschema-1.3.0.tar.gz\n  Running setup.py egg_info for package jsonschema\nDownloading/unpacking simplejson>=2.0.9 (from swift->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 15))\n  Running setup.py egg_info for package simplejson\nDownloading/unpacking xattr>=0.4 (from swift->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 15))\n  Downloading xattr-0.6.4.tar.gz\n  Running setup.py egg_info for package xattr\nDownloading/unpacking Pygments>=1.2 (from sphinx->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 19))\n  Running setup.py egg_info for package Pygments\nDownloading/unpacking Jinja2>=2.3 (from sphinx->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 19))\n  Running setup.py egg_info for package Jinja2\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'jinja2\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'jinja2\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'docs\'\nDownloading/unpacking amqp>=1.0.11,<1.1.0 (from kombu->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package amqp\nDownloading/unpacking importlib (from kombu->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Downloading importlib-1.0.2.zip\n  Running setup.py egg_info for package importlib\nDownloading/unpacking ordereddict (from kombu->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Downloading ordereddict-1.1.tar.gz\n  Running setup.py egg_info for package ordereddict\nDownloading/unpacking decorator (from sqlalchemy-migrate>=0.7.2->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Downloading decorator-3.4.0.tar.gz\n  Running setup.py egg_info for package decorator\n    warning: no previously-included files found matching \'Makefile\'\nDownloading/unpacking Tempita>=0.4 (from sqlalchemy-migrate>=0.7.2->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Downloading Tempita-0.5.1.tar.gz\n  Running setup.py egg_info for package Tempita\nRequirement already satisfied (use --upgrade to upgrade): distribute in <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg> (from sqlalchemy-migrate>=0.7.2->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\nDownloading/unpacking Werkzeug>=0.7 (from Flask==0.9->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package Werkzeug\n    warning: no files found matching \'*\' under directory \'werkzeug/debug/templates\'\n    warning: no files found matching \'*\' under directory \'tests\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'tests\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'tests\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'examples\'\n    warning: no previously-included files matching \'*.pyo\' found under directory \'examples\'\n    no previously-included directories found matching \'docs/_build\'\nDownloading/unpacking simplegeneric>=0.8 (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Downloading simplegeneric-0.8.1.zip\n  Running setup.py egg_info for package simplegeneric\nDownloading/unpacking Mako>=0.4.0 (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package Mako\n    warning: no files found matching \'*.xml\' under directory \'examples\'\n    warning: no files found matching \'*.mako\' under directory \'examples\'\n    warning: no files found matching \'ez_setup.py\'\n    no previously-included directories found matching \'doc/build/output\'\nDownloading/unpacking WebTest>=1.3.1 (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package WebTest\n    no previously-included directories found matching \'docs/_build\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    warning: no previously-included files matching \'__pycache__\' found anywhere in distribution\nDownloading/unpacking six (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Downloading six-1.3.0.tar.gz\n  Running setup.py egg_info for package six\nDownloading/unpacking logutils (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Could not find any downloads that satisfy the requirement logutils (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\nNo distributions at all found for logutils (from pecan>=0.2.0->-r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.qS2Qzb5osy\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/29\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1180099377.32.1387087547765.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:05:47',0,'2013-12-15 06:05:47',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-horizon-docs-havana #7','See <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/7/changes>\n\n\n\n','<1377805497.20.1387001141195.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1180328942.2267056.1376514884639.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-14 17:14:44',-14400,'2013-08-14 21:14:44',NULL,'[Openstack-docs] programlisting language=\"bash\" or\n language=\"INI\" for config files?','----- Original Message -----\n> From: \"David Cramer\" <david.cramer at rackspace.com>\n> To: \"Andreas Jaeger\" <aj at suse.com>\n> Cc: \"Steve Gordon\" <sgordon at redhat.com>, openstack-docs at lists.openstack.org\n> Sent: Wednesday, August 14, 2013 4:23:25 PM\n> Subject: Re: [Openstack-docs] programlisting language=\"bash\" or language=\"INI\" for config files?\n> \n> On 08/14/2013 03:00 PM, Andreas Jaeger wrote:\n> >> I\'ll wait for further responses from Andreas, or anyone else for that\n> >> matter, before doing this.\n> > \n> > \n> > Diane just suggested to add language=\"bash\" to some places - let her\n> > chime in as well.\n> > \n> > I can remove them again where I introduced them if that\'s the consensus.\n> > \n> > I agree with Steve that bash is not correct but it highlights the html\n> > nicely - so using it is a hack ;)\n> > \n> > Could we get the style sheet to be enhanced for INI and use that moving\n> > forward?\n> \n> So bash works in terms of highlighting it correctly and all you want is\n> to be able to say language=\"ini\" and otherwise have it behave the same\n> way it does now?\n> \n> If so that\'s just requires one line of xproc in the pipeline.\n> \n> David\n\nSeems like that would do the trick, yes.\n\nThanks,\n\nSteve\n\n\n','<520BE73D.7030407@rackspace.com>',NULL),('<1182148338.46.1374732156393.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-25 06:02:36',0,'2013-07-25 06:02:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-grizzly #106','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/106/>\n\n------------------------------------------\n[...truncated 60 lines...]\n  Running setup.py egg_info for package Django\nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth>=1.0.7,!=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package netaddr\n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-cinderclient>=1.0.2,<2.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-VMFrHw/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-VMFrHw/d2to1-0.2.10/egg-dist-tmp-KYMXBH\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-NuQYug/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-NuQYug/setuptools-git-1.0/egg-dist-tmp-Ja5iwW\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.12.0,<3 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-b8JYPC/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-b8JYPC/d2to1-0.2.10/egg-dist-tmp-HIYYT3\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-X0kHhy/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-X0kHhy/setuptools-git-1.0/egg-dist-tmp-7oumv7\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-R71eEA/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-R71eEA/d2to1-0.2.10/egg-dist-tmp-xTUjTA\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.M93JeKYhUA/easy_install-EmwjzE/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.M93JeKYhUA/easy_install-EmwjzE/setuptools-git-1.0/egg-dist-tmp-9IN1XJ\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.M93JeKYhUA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-grizzly/106\n[SCP] Copying console log.\n\n\n','<1628340057.36.1374645739207.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<118246164.559.1367475111417.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-02 06:11:51',0,'2013-05-02 06:11:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly-centos6 #2','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/2/>\n\n------------------------------------------\n[...truncated 5093 lines...]\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-02 06:11:45,858 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-02 06:11:45,859 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-02 06:11:45,860 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,861 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,862 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-02 06:11:45,863 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-02 06:11:45,864 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-02 06:11:45  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-02 06:11:45,865 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-02 06:11:45    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-02 06:11:45,866 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,871 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.871272\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.871272\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45,872 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,873 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,874 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,876 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45,877 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.876047\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.876047\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45,878 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,879 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,880 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-02 06:11:45,881 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,881 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,883 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45,884 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.883461\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.883461\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45,885 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,886 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,887 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-02 06:11:45,888 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,889 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,891 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45,892 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.890965\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.890965\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45,893 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,894 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,894 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-02 06:11:45,895 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,896 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,898 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-02 06:11:45,900 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-02 06:11:45,901 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.900053\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-02T06:11:45.900053\', resource_metadata={}) from 0 transformer\n2013-05-02 06:11:45,902 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,903 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45,904 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-02 06:11:45,905 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-02 06:11:45,906 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-02 06:11:45    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.898s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.2\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.centos6.2\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a95.g2781f41\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a479.g44884cf\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.5KV67AIhmh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly-centos6/2\n[SCP] Copying console log.\n\n\n','<1177219411.531.1367388632780.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1182743410.19.1375337748260.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-01 06:15:48',0,'2013-08-01 06:15:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-folsom #304','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/304/>\n\n------------------------------------------\n[...truncated 955 lines...]\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: test_v1_not_enabled (glance.tests.functional.v1.test_api.TestApi)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 457, in test_v1_not_enabled\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.67 secs:\n    14.19    TestScrubber.test_delayed_delete\n    13.79    TestGlanceControl.test_reload\n    13.57    TestGlanceControl.test_respawn\n    13.53    TestGlanceControl.test_bouncing\n    12.58    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 926 tests in 511.563s\n\nFAILED (SKIP=89, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python27-stable-folsom-304\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.20\npep8==1.1\npycparser==2.09.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.WwgMjiYNGT\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/304\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/304/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise12\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise12/304\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1183908734.12111378.1385056518014.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 12:55:18',-18000,'2013-11-21 17:55:18',NULL,'[openstack-dev] [qa] Proposals for Tempest core','+1 for both!\n\n\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Friday, November 15, 2013 2:38:27 PM\n> Subject: [openstack-dev] [qa] Proposals for Tempest core\n> \n> It\'s post summit time, so time to evaluate our current core group for\n> Tempest. There are a few community members that I\'d like to nominate for\n> Tempest core, as I\'ve found their review feedback over the last few\n> months to be invaluable. Tempest core folks, please +1 or -1 as you feel\n> appropriate:\n> \n> Masayuki Igawa\n> \n> His review history is here -\n> https://review.openstack.org/#/q/reviewer:masayuki.igawa%2540gmail.com+project:openstack/tempest,n,z\n> \n> Ken\'ichi Ohmichi\n> \n> His review history is here -\n> https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com+project:openstack/tempest,n,z\n> \n> They have both been actively engaged in the Tempest community, and have\n> been actively contributing to both Tempest and OpenStack integrated\n> projects, working hard to both enhance test coverage, and fix the issues\n> found in the projects themselves. This has been hugely beneficial to\n> OpenStack as a whole.\n> \n> At the same time, it\'s also time, I think, to remove Jay Pipes from\n> tempest-core. Jay\'s not had much time for reviews of late, and it\'s\n> important that the core review team is a working title about actively\n> reviewing code.\n> \n> With this change Tempest core would end up no longer being majority\n> north american, or even majority english as first language (that kind of\n> excites me). Adjusting to both there will be another mailing list thread\n> about changing our weekly meeting time to make it more friendly to our\n> APAC contributors.\n> \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<528623D3.6070303@dague.net>',NULL),('<1184089533.8391782.1382488908110.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-22 20:41:48',-14400,'2013-10-23 00:41:48',NULL,'[Openstack-docs] Errors In Find/Replace','Hey, it looks like someone \'%s/plugin/plug-in/g\' on the Neutron install chapter.  This breaks a couple spots in the configuration files and file paths.  Just a friendly reminder to be careful when you Replace-All :-)  I\'ll see if I can get it all fixed up by tomorrow evening.\n\nBest Regards,\nSolly Ross\n\n\n','<1838811591.8391260.1382488888873.JavaMail.root@redhat.com>',NULL),('<1185062543.21.1383026957295.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-29 06:09:17',0,'2013-10-29 06:09:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #46','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/46/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3a52fd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3a52fd0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x41dbb90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x41dbb90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-7f59666f-61cc-4b2a-8fd9-ae254c41c026\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:08:50Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'50\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'50\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:08:50Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'50\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'50\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:08:50+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'50\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'50\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:08:50-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'50\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'50\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:08:50Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'50\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'50\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5075390>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15d66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 66.83 secs:\n    13.92    TestGlanceControl.test_bouncing\n    13.77    TestScrubber.test_delayed_delete\n    13.46    TestGlanceControl.test_reload\n    13.34    TestGlanceControl.test_respawn\n    12.34    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 485.951s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-46\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.THGKDZ20x3\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/46\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/46/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/46\n[SCP] Copying console log.\n\n\n','<1448945548.11.1382854153566.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1185303780.23777843.1384491946331.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 00:05:46',-18000,'2013-11-15 05:05:46',NULL,'[openstack-dev] [Solum] Some initial code copying for\n db/migration','With no feedback on remotability so far (we can touch base at F2F next week) here\'s a representative sample of the object model with sqlalchemy implementations approach, without some of the bits that would enable remotability (primarily the ability to rehydrate an object with the correct sqlalchemy metadata). [1]\n\n  [1] https://github.com/smarterclayton/solum/commit/d9d83aac0fc98663f1daa9914edeb52faf0cc37d\n\nHighlights:\n\n  Imported nova object code, made the following changes to solum/objects/base.py:\n\n  * Used DomainObject instead of Object, also suggested were OsloObject or \n    OSObject.  I like DomainObject but I like Fowler, what can I say...\n\n  * DomainObject has the metaclass, but is a subclass of AbstractDomainObject \n    which contains all of the core mixin logic.  Allows subclasses that have\n    their own metaclasses to avoid having to do metaclass hijinks by using\n    AbstractDomainObject and objects.base.register_obj_class\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/base.py#L344\n\n  * Moved the _obj_classes registry magic out of ObjectMetaClass and into \n    its own method for easier use.  Since this is a subclass based implementation,\n    having a separate method feels more appropriate for a factory/registry\n    pattern.\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/base.py#L103\n\n  * Takes a dependency on rpc serializer, debating whether this was\n    good or bad (not everyone using objects needs rpc?)\n\n\n  solum/objects/__init__.py\n\n  * solum.objects.load() allows the framework to load a configured set of \n    implementation subclasses that can change. Nova doesn\'t have\n    subclasses of their objects yet so this seemed like the simplest possible\n    change, without introducing a new magic factory.  Called by \n    prepare_service() when API is started up, after config is parsed.\n\n  * Also provides solum.objects.registry.Application which abstracts knowing \n    about the implementation subclass in play\n\n  * solum.objects.new_schema() and transition_schema() are global helpers\n    for determining whether you should be reading newly introduce/changed \n    fields from the schema, or whether you should only be writing them.\n    I plan to have a better example in test tomorrow.\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/__init__.py\n\n\n  Application object interface (fields, docs, version) in solum/objects/application.py\n\n\n  Specific sqlalchemy implementation solum/objects/sqlalchemy/__init__.py\n\n  * As simple as I could make it - simply calls register_obj_class in its\n    load()\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/sqlalchemy/__init__.py\n\n\n  Common SQLAlchemy code in solum/objects/sqlalchemy/models.py\n\n  * SolumBase mixin abstracts all the common CRUD that would be part of the \n    base solum/objects/application.py interfaces.  Subclasses (actual model\n    objects) would override as necessary.\n\n  * Abstracts save() logic that must set new schema transition elements (copy\n    fields when transitioning)\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/sqlalchemy/models.py#L89\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/sqlalchemy/models.py\n\n  \n  Application implementation in solum/objects/sqlalchemy/application.py\n\n  * I don\'t have examples of transition schema, but you could use an if statement \n    in the class initializer:\n\n      id = Column(Integer, primary_key=True)\n      if objects.new_schema():\n          name = Column(String, nullable=True)\n\n    This would allow you to also set sqlalchemy synonym calls when renaming columns\n    for each version of the schema.  Would like to make it more testable, but if \n    you assume a restart between each old -> transitioning -> new the static\n    initialization could be associated with a schema check call in load() that blocks\n    service initialization if the incorrect mode or schema is present.\n\n    https://github.com/smarterclayton/solum/blob/d9d83aac0fc98663f1daa9914edeb52faf0cc37d/solum/objects/sqlalchemy/application.py\n\n\nThe rest of the code needs to be rebased against russell\'s import changeset, and dbsync isn\'t necessary (needs to be replaced with alembic when we hit that point).\n\n\n','<1422199463.22896686.1384370105573.JavaMail.root@redhat.com>',NULL),('<1185A76A-AA94-4E29-AFE1-AB021BC8E743@rackspace.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-19 22:23:52',0,'2012-07-19 22:23:52',NULL,'[OpenStack Foundation] [Openstack] OpenStack Foundation Initial\n	Sign Up Period','Sorry about that. We had a bug for few minutes last night but it\'s fixed now. \n\nIn every case like this we\'ve checked the sign up WAS completed. \n\nWhen you log into your account you should see the individual member agreement listed, which indicates you have completed sign up. \n\n \n\nOn Jul 19, 2012, at 5:15 PM, \"Michael Still\" <michael.still at canonical.com> wrote:\n\n> On 20/07/12 01:13, Jonathan Bryce wrote:\n> \n>> 1. Join as an Individual Member: http://www.openstack.org/join by August 15\n> \n> I tried to sign up yesterday, but got a blank page after completing the\n> form. Now when I try to fill in the form again it says my email has\n> already been registered. However, I didn\'t get a confirmation email or\n> anything like that.\n> \n> Can you confirm if I am registered or not? Is there meant to be some\n> sort of confirmation sent?\n> \n> Thanks,\n> Mikal\n> \n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n\n\n','<500884EB.60103@canonical.com>',NULL),('<1186154666.26874972.1394730830706.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 13:13:50',-14400,'2014-03-13 17:13:50',NULL,'[openstack-dev] [OpenStack-Infra] Intermittent failures cloning\n noVNC from github.com/kanaka','@Monty: having a packaging system sounds like a good idea.  Send us a pull request on github.com/kanaka/noVNC.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Monty Taylor\" <mordred at inaugust.com>\nTo: \"Sean Dague\" <sean at dague.net>, \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>, openstack at nemebean.com\nCc: openstack-infra at lists.openstack.org\nSent: Thursday, March 13, 2014 12:09:01 PM\nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka\n\nI agree.\n\nSolly - in addition to potentially \'adopting\' noVNC - or as a parallel \ntrain of thought ...\n\nAs we started working on storyboard in infra, we\'ve started using the \nbower tool for html/javascript packaging - and we have some ability to \ncache the output of that pretty easily. Would you accept patches to \nnoVNC to add bower config things and/or publication of tarballs of \nreleases via it? Since noVNC isn\'t likely to be participating in the \nintegrated gate in either case, we could potentially split the question \nof \"how do we get copies of it in a way that doesn\'t depend on OS \ndistros\" (which is why we use pip for our python depends) and \"does \nnoVNC want to have its git repo exist in OpenStack Infra systems.\n\nMonty\n\nOn 03/13/2014 07:44 AM, Sean Dague wrote:\n> I think a bigger question is why are we using a git version of something\n> outside of OpenStack.\n>\n> Where is a noNVC release we can point to and use?\n>\n> In Juno I\'d really be pro removing all the devstack references to git\n> repos not on git.openstack.org, because these kinds of failures have\n> real impact.\n>\n> Currently we have 4 repositories that fit this bill:\n>\n> SWIFT3_REPO=${SWIFT3_REPO:-http://github.com/fujita/swift3.git}\n> NOVNC_REPO=${NOVNC_REPO:-https://github.com/kanaka/noVNC.git}\n> RYU_REPO=${RYU_REPO:-https://github.com/osrg/ryu.git}\n> SPICE_REPO=${SPICE_REPO:-http://anongit.freedesktop.org/git/spice/spice-html5.git}\n>\n> I think all of these probably need to be removed from devstack. We\n> should be using release versions (preferably in distros, though allowed\n> to be in language specific package manager).\n>\n> 	-Sean\n>\n> On 03/13/2014 10:26 AM, Solly Ross wrote:\n>> @bnemec: I don\'t think that\'s been considered.  I\'m actually one of the upstream maintainers for noVNC.  The only concern that I\'d have with OpenStack adopting noVNC (there are other maintainers, as well as the author, so I\'d have to check with them as well) is that there are a few other projects that use noVNC, so we\'d need to make sure that no OpenStack-specific code gets merged into noVNC if we adopt it.  Other that that, though, adopting noVNC doesn\'t sound like a horrible idea.\n>>\n>> Best Regards,\n>> Solly Ross\n>>\n>> ----- Original Message -----\n>> From: \"Ben Nemec\" <openstack at nemebean.com>\n>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>> Cc: openstack-infra at lists.openstack.org\n>> Sent: Wednesday, March 12, 2014 3:38:19 PM\n>> Subject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning	noVNC from github.com/kanaka\n>>\n>>\n>>\n>> On 2014-03-11 20:34, Joshua Harlow wrote:\n>>\n>>\n>> https://status.github.com/messages\n>> * \'GitHub.com is operating normally, despite an ongoing DDoS attack. The mitigations we have in place are proving effective in protecting us and we\'re hopeful that we\'ve got this one resolved.\'\n>> If you were cloning from github.org and not http://git.openstack.org then you were likely seeing some of the DDoS attack in action.\n>> Unfortunately I don\'t think novnc is in git.openstack.org because it\'s not an OpenStack project. I wonder if we should investigate adopting it (if the author(s) are amenable to that) since we\'re using the git version of it. Maybe that\'s already been considered and I just don\'t know about it. :-)\n>> -Ben\n>>\n>>\n>>\n>> From: Sukhdev Kapur < sukhdevkapur at gmail.com >\n>> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >\n>> Date: Tuesday, March 11, 2014 at 4:08 PM\n>> To: \"Dane Leblanc (leblancd)\" < leblancd at cisco.com >\n>> Cc: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >, \" openstack-infra at lists.openstack.org \" < openstack-infra at lists.openstack.org >\n>> Subject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka\n>>\n>>\n>>\n>> I have noticed that even clone of devstack has failed few times within last couple of hours - it was running fairly smooth so far.\n>> -Sukhdev\n>>\n>>\n>> On Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur < sukhdevkapur at gmail.com > wrote:\n>>\n>>\n>>\n>> [adding openstack-dev list as well ]\n>> I have noticed that this has stated hitting my builds within last few hours. I have noticed exact same failures on almost 10 builds.\n>> Looks like something has happened within last few hours - perhaps the load?\n>> -Sukhdev\n>>\n>>\n>> On Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) < leblancd at cisco.com > wrote:\n>>\n>>\n>>\n>>\n>>\n>> Apologies if this is the wrong audience for this question...\n>>\n>>\n>>\n>> I\'m seeing intermittent failures running stack.sh whereby \'git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\' is returning various errors. Below are 2 examples.\n>>\n>>\n>>\n>> Is this a known issue? Are there any localrc settings which might help here?\n>>\n>>\n>>\n>> Example 1:\n>>\n>>\n>>\n>> 2014-03-11 15:00:33.779 | + is_service_enabled n-novnc\n>>\n>> 2014-03-11 15:00:33.780 | + return 0\n>>\n>> 2014-03-11 15:00:33.781 | ++ trueorfalse False\n>>\n>> 2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False\n>>\n>> 2014-03-11 15:00:33.783 | + \'[\' False = True \']\'\n>>\n>> 2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.785 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master\n>>\n>> 2014-03-11 15:00:33.786 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git\n>>\n>> 2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.789 | + GIT_REF=master\n>>\n>> 2014-03-11 15:00:33.790 | ++ trueorfalse False False\n>>\n>> 2014-03-11 15:00:33.791 | + RECLONE=False\n>>\n>> 2014-03-11 15:00:33.792 | + [[ False = \\T\\r\\u\\e ]]\n>>\n>> 2014-03-11 15:00:33.793 | + echo master\n>>\n>> 2014-03-11 15:00:33.794 | + egrep -q \'^refs\'\n>>\n>> 2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]\n>>\n>> 2014-03-11 15:00:33.796 | + [[ False = \\T\\r\\u\\e ]]\n>>\n>> 2014-03-11 15:00:33.797 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.798 | + local count=0\n>>\n>> 2014-03-11 15:00:33.799 | + local timeout=0\n>>\n>> 2014-03-11 15:00:33.801 | + [[ -n 0 ]]\n>>\n>> 2014-03-11 15:00:33.802 | + timeout=0\n>>\n>> 2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.804 | Cloning into \'/opt/stack/noVNC\'...\n>>\n>> 2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200\n>>\n>> 2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly\n>>\n>> 2014-03-11 15:03:13.697 | fatal: early EOF\n>>\n>> 2014-03-11 15:03:13.698 | fatal: index-pack failed\n>>\n>> 2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]\n>>\n>> 2014-03-11 15:03:13.700 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\'\n>>\n>> 2014-03-11 15:03:13.701 | + local exitcode=0\n>>\n>> 2014-03-11 15:03:13.702 | [Call Trace]\n>>\n>> 2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova\n>>\n>> 2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone\n>>\n>> 2014-03-11 15:03:13.706 | /var/lib/jenkins/devstack/functions-common:543:git_timed\n>>\n>> 2014-03-11 15:03:13.707 | /var/lib/jenkins/devstack/functions-common:596:die\n>>\n>> 2014-03-11 15:03:13.708 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC]\n>>\n>>\n>>\n>>\n>>\n>> Example 2:\n>>\n>>\n>> 2014-03-11 14:12:58.472 | + is_service_enabled n-novnc\n>> 2014-03-11 14:12:58.473 | + return 0\n>> 2014-03-11 14:12:58.474 | ++ trueorfalse False\n>> 2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False\n>> 2014-03-11 14:12:58.476 | + \'[\' False = True \']\'\n>> 2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC\n>> 2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master\n>> 2014-03-11 14:12:58.479 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git\n>> 2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC\n>> 2014-03-11 14:12:58.481 | + GIT_REF=master\n>> 2014-03-11 14:12:58.482 | ++ trueorfalse False False\n>> 2014-03-11 14:12:58.483 | + RECLONE=False\n>> 2014-03-11 14:12:58.484 | + [[ False = \\T\\r\\u\\e ]]\n>> 2014-03-11 14:12:58.485 | + echo master\n>> 2014-03-11 14:12:58.486 | + egrep -q \'^refs\'\n>> 2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]]\n>> 2014-03-11 14:12:58.488 | + [[ False = \\T\\r\\u\\e ]]\n>> 2014-03-11 14:12:58.489 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>> 2014-03-11 14:12:58.490 | + local count=0\n>> 2014-03-11 14:12:58.491 | + local timeout=0\n>> 2014-03-11 14:12:58.492 | + [[ -n 0 ]]\n>> 2014-03-11 14:12:58.493 | + timeout=0\n>> 2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>> 2014-03-11 14:12:58.495 | Cloning into \'/opt/stack/noVNC\'...\n>> 2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while accessing https://github.com/kanaka/noVNC.git/info/refs\n>> 2014-03-11 14:14:02.316 | fatal: HTTP request failed\n>> 2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]]\n>> 2014-03-11 14:14:02.318 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\'\n>> 2014-03-11 14:14:02.319 | + local exitcode=0\n>> 2014-03-11 14:14:02.321 | [Call Trace]\n>> 2014-03-11 14:14:02.322 | ./stack.sh:736:install_nova\n>> 2014-03-11 14:14:02.323 | /var/lib/jenkins/devstack/lib/nova:618:git_clone\n>> 2014-03-11 14:14:02.324 | /var/lib/jenkins/devstack/functions-common:543:git_timed\n>> 2014-03-11 14:14:02.326 | /var/lib/jenkins/devstack/functions-common:596:die\n>> 2014-03-11 14:14:02.327 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC]\n>>\n>>\n>>\n>>\n>> Thanks,\n>>\n>> Dane\n>>\n>>\n>> _______________________________________________\n>> OpenStack-Infra mailing list\n>> OpenStack-Infra at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5321D81D.7000907@inaugust.com>',NULL),('<1186154666.26874972.1394730830706.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-13 13:13:50',-14400,'2014-03-13 17:13:50',NULL,'[OpenStack-Infra] [openstack-dev] Intermittent failures cloning\n noVNC from github.com/kanaka','@Monty: having a packaging system sounds like a good idea.  Send us a pull request on github.com/kanaka/noVNC.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Monty Taylor\" <mordred at inaugust.com>\nTo: \"Sean Dague\" <sean at dague.net>, \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>, openstack at nemebean.com\nCc: openstack-infra at lists.openstack.org\nSent: Thursday, March 13, 2014 12:09:01 PM\nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka\n\nI agree.\n\nSolly - in addition to potentially \'adopting\' noVNC - or as a parallel \ntrain of thought ...\n\nAs we started working on storyboard in infra, we\'ve started using the \nbower tool for html/javascript packaging - and we have some ability to \ncache the output of that pretty easily. Would you accept patches to \nnoVNC to add bower config things and/or publication of tarballs of \nreleases via it? Since noVNC isn\'t likely to be participating in the \nintegrated gate in either case, we could potentially split the question \nof \"how do we get copies of it in a way that doesn\'t depend on OS \ndistros\" (which is why we use pip for our python depends) and \"does \nnoVNC want to have its git repo exist in OpenStack Infra systems.\n\nMonty\n\nOn 03/13/2014 07:44 AM, Sean Dague wrote:\n> I think a bigger question is why are we using a git version of something\n> outside of OpenStack.\n>\n> Where is a noNVC release we can point to and use?\n>\n> In Juno I\'d really be pro removing all the devstack references to git\n> repos not on git.openstack.org, because these kinds of failures have\n> real impact.\n>\n> Currently we have 4 repositories that fit this bill:\n>\n> SWIFT3_REPO=${SWIFT3_REPO:-http://github.com/fujita/swift3.git}\n> NOVNC_REPO=${NOVNC_REPO:-https://github.com/kanaka/noVNC.git}\n> RYU_REPO=${RYU_REPO:-https://github.com/osrg/ryu.git}\n> SPICE_REPO=${SPICE_REPO:-http://anongit.freedesktop.org/git/spice/spice-html5.git}\n>\n> I think all of these probably need to be removed from devstack. We\n> should be using release versions (preferably in distros, though allowed\n> to be in language specific package manager).\n>\n> 	-Sean\n>\n> On 03/13/2014 10:26 AM, Solly Ross wrote:\n>> @bnemec: I don\'t think that\'s been considered.  I\'m actually one of the upstream maintainers for noVNC.  The only concern that I\'d have with OpenStack adopting noVNC (there are other maintainers, as well as the author, so I\'d have to check with them as well) is that there are a few other projects that use noVNC, so we\'d need to make sure that no OpenStack-specific code gets merged into noVNC if we adopt it.  Other that that, though, adopting noVNC doesn\'t sound like a horrible idea.\n>>\n>> Best Regards,\n>> Solly Ross\n>>\n>> ----- Original Message -----\n>> From: \"Ben Nemec\" <openstack at nemebean.com>\n>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>> Cc: openstack-infra at lists.openstack.org\n>> Sent: Wednesday, March 12, 2014 3:38:19 PM\n>> Subject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning	noVNC from github.com/kanaka\n>>\n>>\n>>\n>> On 2014-03-11 20:34, Joshua Harlow wrote:\n>>\n>>\n>> https://status.github.com/messages\n>> * \'GitHub.com is operating normally, despite an ongoing DDoS attack. The mitigations we have in place are proving effective in protecting us and we\'re hopeful that we\'ve got this one resolved.\'\n>> If you were cloning from github.org and not http://git.openstack.org then you were likely seeing some of the DDoS attack in action.\n>> Unfortunately I don\'t think novnc is in git.openstack.org because it\'s not an OpenStack project. I wonder if we should investigate adopting it (if the author(s) are amenable to that) since we\'re using the git version of it. Maybe that\'s already been considered and I just don\'t know about it. :-)\n>> -Ben\n>>\n>>\n>>\n>> From: Sukhdev Kapur < sukhdevkapur at gmail.com >\n>> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >\n>> Date: Tuesday, March 11, 2014 at 4:08 PM\n>> To: \"Dane Leblanc (leblancd)\" < leblancd at cisco.com >\n>> Cc: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >, \" openstack-infra at lists.openstack.org \" < openstack-infra at lists.openstack.org >\n>> Subject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka\n>>\n>>\n>>\n>> I have noticed that even clone of devstack has failed few times within last couple of hours - it was running fairly smooth so far.\n>> -Sukhdev\n>>\n>>\n>> On Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur < sukhdevkapur at gmail.com > wrote:\n>>\n>>\n>>\n>> [adding openstack-dev list as well ]\n>> I have noticed that this has stated hitting my builds within last few hours. I have noticed exact same failures on almost 10 builds.\n>> Looks like something has happened within last few hours - perhaps the load?\n>> -Sukhdev\n>>\n>>\n>> On Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) < leblancd at cisco.com > wrote:\n>>\n>>\n>>\n>>\n>>\n>> Apologies if this is the wrong audience for this question...\n>>\n>>\n>>\n>> I\'m seeing intermittent failures running stack.sh whereby \'git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\' is returning various errors. Below are 2 examples.\n>>\n>>\n>>\n>> Is this a known issue? Are there any localrc settings which might help here?\n>>\n>>\n>>\n>> Example 1:\n>>\n>>\n>>\n>> 2014-03-11 15:00:33.779 | + is_service_enabled n-novnc\n>>\n>> 2014-03-11 15:00:33.780 | + return 0\n>>\n>> 2014-03-11 15:00:33.781 | ++ trueorfalse False\n>>\n>> 2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False\n>>\n>> 2014-03-11 15:00:33.783 | + \'[\' False = True \']\'\n>>\n>> 2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.785 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master\n>>\n>> 2014-03-11 15:00:33.786 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git\n>>\n>> 2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.789 | + GIT_REF=master\n>>\n>> 2014-03-11 15:00:33.790 | ++ trueorfalse False False\n>>\n>> 2014-03-11 15:00:33.791 | + RECLONE=False\n>>\n>> 2014-03-11 15:00:33.792 | + [[ False = \\T\\r\\u\\e ]]\n>>\n>> 2014-03-11 15:00:33.793 | + echo master\n>>\n>> 2014-03-11 15:00:33.794 | + egrep -q \'^refs\'\n>>\n>> 2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]\n>>\n>> 2014-03-11 15:00:33.796 | + [[ False = \\T\\r\\u\\e ]]\n>>\n>> 2014-03-11 15:00:33.797 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.798 | + local count=0\n>>\n>> 2014-03-11 15:00:33.799 | + local timeout=0\n>>\n>> 2014-03-11 15:00:33.801 | + [[ -n 0 ]]\n>>\n>> 2014-03-11 15:00:33.802 | + timeout=0\n>>\n>> 2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>>\n>> 2014-03-11 15:00:33.804 | Cloning into \'/opt/stack/noVNC\'...\n>>\n>> 2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200\n>>\n>> 2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly\n>>\n>> 2014-03-11 15:03:13.697 | fatal: early EOF\n>>\n>> 2014-03-11 15:03:13.698 | fatal: index-pack failed\n>>\n>> 2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]\n>>\n>> 2014-03-11 15:03:13.700 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\'\n>>\n>> 2014-03-11 15:03:13.701 | + local exitcode=0\n>>\n>> 2014-03-11 15:03:13.702 | [Call Trace]\n>>\n>> 2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova\n>>\n>> 2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone\n>>\n>> 2014-03-11 15:03:13.706 | /var/lib/jenkins/devstack/functions-common:543:git_timed\n>>\n>> 2014-03-11 15:03:13.707 | /var/lib/jenkins/devstack/functions-common:596:die\n>>\n>> 2014-03-11 15:03:13.708 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC]\n>>\n>>\n>>\n>>\n>>\n>> Example 2:\n>>\n>>\n>> 2014-03-11 14:12:58.472 | + is_service_enabled n-novnc\n>> 2014-03-11 14:12:58.473 | + return 0\n>> 2014-03-11 14:12:58.474 | ++ trueorfalse False\n>> 2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False\n>> 2014-03-11 14:12:58.476 | + \'[\' False = True \']\'\n>> 2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC\n>> 2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master\n>> 2014-03-11 14:12:58.479 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git\n>> 2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC\n>> 2014-03-11 14:12:58.481 | + GIT_REF=master\n>> 2014-03-11 14:12:58.482 | ++ trueorfalse False False\n>> 2014-03-11 14:12:58.483 | + RECLONE=False\n>> 2014-03-11 14:12:58.484 | + [[ False = \\T\\r\\u\\e ]]\n>> 2014-03-11 14:12:58.485 | + echo master\n>> 2014-03-11 14:12:58.486 | + egrep -q \'^refs\'\n>> 2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]]\n>> 2014-03-11 14:12:58.488 | + [[ False = \\T\\r\\u\\e ]]\n>> 2014-03-11 14:12:58.489 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>> 2014-03-11 14:12:58.490 | + local count=0\n>> 2014-03-11 14:12:58.491 | + local timeout=0\n>> 2014-03-11 14:12:58.492 | + [[ -n 0 ]]\n>> 2014-03-11 14:12:58.493 | + timeout=0\n>> 2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\n>> 2014-03-11 14:12:58.495 | Cloning into \'/opt/stack/noVNC\'...\n>> 2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while accessing https://github.com/kanaka/noVNC.git/info/refs\n>> 2014-03-11 14:14:02.316 | fatal: HTTP request failed\n>> 2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]]\n>> 2014-03-11 14:14:02.318 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\'\n>> 2014-03-11 14:14:02.319 | + local exitcode=0\n>> 2014-03-11 14:14:02.321 | [Call Trace]\n>> 2014-03-11 14:14:02.322 | ./stack.sh:736:install_nova\n>> 2014-03-11 14:14:02.323 | /var/lib/jenkins/devstack/lib/nova:618:git_clone\n>> 2014-03-11 14:14:02.324 | /var/lib/jenkins/devstack/functions-common:543:git_timed\n>> 2014-03-11 14:14:02.326 | /var/lib/jenkins/devstack/functions-common:596:die\n>> 2014-03-11 14:14:02.327 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC]\n>>\n>>\n>>\n>>\n>> Thanks,\n>>\n>> Dane\n>>\n>>\n>> _______________________________________________\n>> OpenStack-Infra mailing list\n>> OpenStack-Infra at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5321D81D.7000907@inaugust.com>',NULL),('<1186328350.74.1383632225284.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-05 06:17:05',0,'2013-11-05 06:17:05',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-nova-python26-stable-folsom #41','See <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-folsom/41/>\n\n\n\n','<1655281586.46.1383373031030.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1186775556.191.1356480266702.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-26 00:04:26',0,'2012-12-26 00:04:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #86','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/86/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/86\n[SCP] Copying console log.\n\n\n','<545032544.176.1356393871973.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1186923b031f9cb4d8158de2965635dc@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 11:34:13',-21600,'2014-02-27 17:34:13',NULL,'[openstack-dev] heads up,\n	set -o errexit on devstack - things  will fail earlier now','On 2014-02-27 09:23, Daniel P. Berrange wrote:\n> On Thu, Feb 27, 2014 at 08:38:22AM -0500, Sean Dague wrote:\n>> This patch is coming through the gate this morning -\n>> https://review.openstack.org/#/c/71996/\n>> \n>> The point being to actually make devstack stop when it hits an error,\n>> instead of only once these compound to the point where there is no\n>> moving forward and some service call fails. This should *dramatically*\n>> improve the experience of figuring out a failure in the gate, because\n>> where it fails should be the issue. (It also made us figure out some\n>> wonkiness with stdout buffering, that was making debug difficult).\n>> \n>> This works on all the content that devstack gates against. However,\n>> there are a ton of other paths in devstack, including vendor plugins,\n>> which I\'m sure aren\'t clean enough to run under -o errexit. So if all \n>> of\n>> a sudden things start failing, this may be why. Fortunately you\'ll be\n>> pointed at the exact point of the fail.\n> \n> This is awesome!\n\n+1!  Thanks Sean and everyone else who was involved with this.\n\nThis should help reduce the number of \"devstack failed, what went \nwrong?\" questions since the actual failure will be right there, as \nopposed to buried a thousand lines of output up. :-)\n\n-Ben\n\n\n','<20140227152343.GK16117@redhat.com>',NULL),('<1187155051.34.1386309766019.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-06 06:02:46',0,'2013-12-06 06:02:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-heat-python27-grizzly #2','See <https://jenkins02.openstack.org/job/periodic-heat-python27-grizzly/2/>\n\n\n\n','<587349115.31.1386137023123.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1187239750.5614348.1399650282318.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-09 11:44:42',-14400,'2014-05-09 15:44:42',NULL,'[openstack-dev] Informal meeting before SR-IOV summit\n	presentation','----- Original Message -----\n> From: \"Robert Li (baoli)\" <baoli at cisco.com>\n> Subject: Re: Informal meeting before SR-IOV summit presentation\n> \n> This is the one that Irena created:\n> https://etherpad.openstack.org/p/pci_passthrough_cross_project\n\nThanks, I missed this as it wasn\'t linked from the design summit Wiki page.\n\n-Steve\n\n> On 5/8/14, 4:33 PM, \"Steve Gordon\" <sgordon at redhat.com> wrote:\n> \n> >----- Original Message -----\n> >> > It would be nice to have an informal discussion / unconference session\n> >> > before the actual summit session on SR-IOV. During the previous IRC\n> >> > meeting, we were really close to identifying the different use cases.\n> >> > There was a dangling discussion on introducing another level of\n> >> > indirection between the vnic_types exposed via the nova boot API and\n> >>how\n> >> > it would be represented internally. It would be ideal to have these 2\n> >> > discussions converged before the summit session.\n> >> \n> >> What would be the purpose of doing that before the session? IMHO, a\n> >> large part of being able to solve this problem is getting everyone up to\n> >> speed on what this means, what the caveats are, and what we\'re trying to\n> >> solve. If we do some of that outside the scope of the larger audience, I\n> >> expect we\'ll get less interaction (or end up covering it again) in the\n> >> session.\n> >> \n> >> That said, if there\'s something I\'m missing that needs to be resolved\n> >> ahead of time, then that\'s fine, but I expect the best plan is to just\n> >> keep the discussion to the session. Afterwards, additional things can be\n> >> discussed in a one-off manner, but getting everyone on the same page is\n> >> largely the point of having a session in the first place IMHO.\n> >\n> >Right, in spite of my previous response...looking at the etherpad there\n> >is nothing there to frame the discussion at the moment:\n> >\n> >https://etherpad.openstack.org/p/juno-nova-sriov-support\n> >\n> >I think populating this should be a priority rather than organizing\n> >another session/meeting?\n> >\n> >Steve\n> \n> \n\n-- \nSteve Gordon, RHCE\nProduct Manager, Red Hat Enterprise Linux OpenStack Platform\nRed Hat Canada (Toronto, Ontario)\n\n\n','<CF9163B8.7AFF9%baoli@cisco.com>',NULL),('<1187370.344.1387878350730.JavaMail.yfried@yfried-mobl-rh>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-24 04:45:55',-18000,'2013-12-24 09:45:55',NULL,'[openstack-dev] [Tempest][qa] Adding tags to commit messages','Hi,\nAssuming this is agreed (is it?) - here\'s the dilemma:\n- Tagging the subject is problematic due to length limit and fails the pep8 gate\n- Tagging in the message looses the visibility value\n\nCan we check for the subject length without the tags, or disable this check completely?\nYair\n\n\n----- Original Message -----\nFrom: \"Yair Fried\" <yfried at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, December 24, 2013 11:20:40 AM\nSubject: Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages\n\n\n\n----- Original Message -----\n> From: \"Masayuki Igawa\" <masayuki.igawa at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, December 24, 2013 10:42:39 AM\n> Subject: Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages\n> \n> Hi,\n> \n> On Tue, Dec 24, 2013 at 3:47 PM, Yair Fried <yfried at redhat.com>\n> wrote:\n> > Hi,\n> > Suggestion: Please consider tagging your Tempest commit messages\n> > the same way you do your mails in the mailing list\n> >\n> > Explanation: Since tempest is a single project testing multiple\n> > Openstack project we have a very diverse collection of patches as\n> > well as reviewers. Tagging our commit messages will allow us to\n> > classify patches and thus:\n> > 1. Allow reviewer to focus on patches related to their area of\n> > expertise\n> > 2. Track \"trends\" in patches - I think we all know that we lack in\n> > Neutron testing for example, but can we assess how many network\n> > related patches are for awaiting review\n> > 3. Future automation of flagging \"interesting\" patches\n> >\n> > You can usually tell all of this from reviewing the patch, but by\n> > then - you\'ve spent time on a patch you might not even be\n> > qualified to review.\n> > I suggest we tag our patches with, to start with, the components we\n> > are looking to test, and the type of test (sceanrio, api, ...) and\n> > that reviewers should -1 untagged patches.\n> >\n> > I think the tagging should be the 2nd line in the message:\n> >\n> > ======================================\n> > Example commit message\n> >\n> > [Neutron][Nova][Network][Scenario]\n> >\n> > Explanation of how this scenario tests both Neutron and Nova\n> > Network performance\n> >\n> > Chang-id XXXXXXXXXXXXXXXXXXX\n> > =======================================\n> >\n> > I would like this to start immediately but what do you guys think?\n> \n> +1\n> \n> And, how about do we the tagging about the services in the\n> subject(1st line)?\n> For example:\n>   Neutron:Example commit subject\n> \n> Because the dashboard of the gerrit shows the subject only now.\n> I think reviewers can find \"interesting\" patches easily if the\n> dashboard shows the tags.\n\nI just found out you could query search for messages like this:\nstatus:open message:[Neutron]\n\n> This is not so strong opinion because some scenario tests may have\n> several services tags.\n\nAnd you have a limited subject length that\'s already not enough (for me at least)\n\n> \n> --\n> Masayuki Igawa\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<11248837.320.1387876836439.JavaMail.yfried@yfried-mobl-rh>',NULL),('<1187396934.429314.1376900901049.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-19 04:28:21',-14400,'2013-08-19 08:28:21',NULL,'[openstack-qa]  scenario vs api overlap','I wanted to start building some scenario based testing and noticed that there are some overlap of code where some scenarios re-implement code that is also present in the API.\nFor example, some of the scenarios (test_server_basic_ops.py for example) re-implement methods that were written in the corresponding REST client in the API.\nI was wondering if there is some guidelines of what is a resalable overlap of code (though I\'m not sure it really is an overlap when scenario uses the python clients and the API the REST client), for example, say I want to write a scenario for nova that tests something with the quota, I can see from the code of the API (tempest/tempest/api/compute/admin/test_quotas.py) that it has a lot of the quota related code already implemented with the REST client, so when I\'m building a scenario, how much \"freedom\" do I have to write methods that uses the python clients instead of the API methods?\n\n\nThanks,\nTal\n\n\n','<1991352369.422799.1376899662097.JavaMail.root@redhat.com>',NULL),('<1187683953.767411.1371198789567.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-14 04:33:09',-14400,'2013-06-14 08:33:09',NULL,'[openstack-qa] Priolity brainstorming my initial toughts','The discussed things are nice, but we had to race with the time.\n\n- We should avoid doing any major code change\n in order to let the testr-subunit-testtools run.\n\n- Gate time is continuously increasing and it will\n  if we do not act soon.\n\n- The huge test gaps is mainly related to keystone v3, quantum, ceilometer and heat.\n A major design change could cause major merge conflict -> slowing down the test development.\n\n- Temporary we could increase the isolation level to higher than the ideal.\n- Temporary we can loose the refstack parallel.\n- Temporary we can use even dirty tricks to have the test cases to run parallel\n- Temporary we can move the non parallel friendly tests to an another job\n\n- If we cannot do it soon, we might need to limit the number of the gating tests.\n\n\n','<77669650.759215.1371197834212.JavaMail.root@redhat.com>',NULL),('<1187688375.67.1383545345481.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:09:05',0,'2013-11-04 06:09:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #50','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/50/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4606dd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4606dd0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3f2d8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3f2d8d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-7c7d9f20-9b18-4302-8738-273d7a7b1be3\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:08:39Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'39\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'39\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:08:39Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'39\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'39\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:08:39+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'39\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'39\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:08:39-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'39\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'39\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:08:39Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'39\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'39\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57a3750>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19fb6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 66.21 secs:\n    13.73    TestScrubber.test_delayed_delete\n    13.51    TestGlanceControl.test_reload\n    13.33    TestGlanceControl.test_bouncing\n    13.30    TestGlanceControl.test_respawn\n    12.35    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 484.012s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-50\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.5kCFiq3MhX\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/50\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/50/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/50\n[SCP] Copying console log.\n\n\n','<988121099.58.1383459083969.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1188290545.950090.1382090808429.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-18 10:06:48',0,'2013-10-18 10:06:48',NULL,'[openstack-dev] [nova][scheduler] A new blueprint for\n Nova-scheduler: Policy-based Scheduler','I like what you proposed in the blueprint. I totally agree that nova-scheduler needs\nfiner granularity in its usage of filters and weighers. Our objective is thus very\nsimilar.\n\nOur approach is little different. Since flavors are choices of clients, and\naggregates are selected during host selection (which comes after filters), we choose\nto separate the policies from flavors and aggregates and put them into a Policy \nRepository (a database or a simple file). The Policy-based Scheduler then looks at\nthe Repo first to know which policy applied to which target (aggregates, tenants, etc).\nIt is an extensible architecture: It allows to customize policies and plug other \nsolutions easily. The policy may be as simple as to apply, like in your proposal, a filter \n(policy -> (filter + aggregate)), a weigher, a combination of them or a completely \nnew driver, say a new scheduling solution.\n\nCurrently we\'re working on an implementation of the blueprint which allows only admin \nto set up policies, but I also like the idea of letting client say their preferences \n(e.g. preferred availability-zone, anti-affinity, choice between silver-class or \ngold-class service). It is a question of philosophy.\n\nBest regards,\n\nToan\n\nGlobal archi:\nhttps://docs.google.com/document/d/1gr4Pb1ErXymxN9QXR4G_jVjLqNOg2ij9oA0JrLwMVRA\n\n---------- Message original --------\nSujet: Re: [openstack-dev] [nova][scheduler] A new blueprint for\nNova-scheduler: Policy-based Scheduler\nDate : Wed, 16 Oct 2013 14:38:38 +0300\nDe : Alex Glikson <GLIKSON at il.ibm.com>\nR?pondre ? : OpenStack Development Mailing List\n<openstack-dev at lists.openstack.org>\nPour : OpenStack Development Mailing List\n<openstack-dev at lists.openstack.org>\n\nThis sounds very similar to\nhttps://blueprints.launchpad.net/nova/+spec/multiple-scheduler-drivers\n\nWe worked on it in Havana, learned a lot from feedbacks during the review\ncycle, and hopefully will finalize the details at the summit and will be\nable to continue & finish the implementation in Icehouse. Would be great\nto collaborate.\n\nRegards,\nAlex\n\n\n\n\n\nFrom:   Khanh-Toan Tran <khanh-toan.tran at cloudwatt.com>\nTo:     openstack-dev at lists.openstack.org,\nDate:   16/10/2013 01:42 PM\nSubject:        [openstack-dev] [nova][scheduler] A new blueprint for\nNova-scheduler: Policy-based Scheduler\n\n\n\nDear all,\n\nI\'ve registered a new blueprint for nova-scheduler. The purpose of the\nblueprint is to propose a new scheduler that is based on policy:\n\n   https://blueprints.launchpad.net/nova/+spec/policy-based-scheduler\n\nWith current Filter_Scheduler, admin cannot change his placement policy\nwithout restarting nova-scheduler. Neither can he define local policy for\na group of resources (say, an aggregate), or a particular client. Thus we\npropose this scheduler to provide admin with the capability of\ndefining/changing his placement policy in runtime. The placement policy\ncan be global (concerning all resources), local (concerning a group of\nresources), or tenant-specific.\n\nPlease don\'t hesitate to contact us for discussion, all your comments are\nwelcomed!\n\nBest regards,\n\nKhanh-Toan TRAN\nCloudwatt\nEmail: khanh-toan.tran[at]cloudwatt.com\n892 Rue Yves Kermen\n92100 BOULOGNE-BILLANCOURT\nFRANCE\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5260F86B.3000801@cloudwatt.com>',NULL),('<1189105035.42307055.1409746420083.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 08:13:40',-14400,'2014-09-03 12:13:40',NULL,'[openstack-dev] [Ironic] (Non-)consistency of the Ironic hash\n ring implementation','\n\n> On 09/02/2014 11:33 PM, Robert Collins wrote:\n> > The implementation in ceilometer is very different to the Ironic one -\n> > are you saying the test you linked fails with Ironic, or that it fails\n> > with the ceilometer code today?\n> \n> Disclaimer: in Ironic terms, node = conductor, key = host\n> \n> The test I linked fails with Ironic hash ring code (specifically the\n> part that tests consistency). With 1000 keys being mapped to 10 nodes,\n> when you add a node:\n> - current ceilometer code remaps around 7% of the keys (< 1/#nodes)\n> - Ironic code remaps > 90% of the keys\n\nSo just to underscore what Nejc is saying here ... \n\nThe key point is the proportion of such baremetal-nodes that would\nend up being re-assigned when a new conductor is fired up.\n\nThe defining property of a consistent hash-ring is that it\nsignificantly reduces the number of re-mappings that occur when\nthe number of buckets change, when compared to a plain ol\' hash.\n\nThis desire for stickiness would often be motivated by some form\nof statefulness or initialization cost. In the ceilometer case,\nwe want to minimize unnecessary re-assignment so as to keep the\ncadence of meter collection and alarm evaluation as even as\npossible (given that each agent will be running off\nnon-synchronized periodic tasks).\n\nIn the case of the Ironic baremetal-node to conductor mapping,\nperhaps such stickiness isn\'t really of any benefit?\n\nIf so, that\'s fine, but Nejc\'s main point UUIC is that an\napproach that doesn\'t minimize the number of re-mappings isn\'t\nreally a form of *consistent* hashing.\n\nCheers,\nEoghan\n \n> The problem lies in the way you build your hash ring[1]. You initialize\n> a statically-sized array and divide its fields among nodes. When you do\n> a lookup, you check which field in the array the key hashes to and then\n> return the node that that field belongs to. This is the wrong approach\n> because when you add a new node, you will resize the array and assign\n> the fields differently, but the same key will still hash to the same\n> field and will therefore hash to a different node.\n> \n> Nodes must be hashed onto the ring as well, statically chopping up the\n> ring and dividing it among nodes isn\'t enough for consistency.\n> \n> Cheers,\n> Nejc\n> \n> >\n> > The Ironic hash_ring implementation uses a hash:\n> >      def _get_partition(self, data):\n> >          try:\n> >              return (struct.unpack_from(\'>I\',\n> >              hashlib.md5(data).digest())[0]\n> >                      >> self.partition_shift)\n> >          except TypeError:\n> >              raise exception.Invalid(\n> >                      _(\"Invalid data supplied to HashRing.get_hosts.\"))\n> >\n> >\n> > so I don\'t see the fixed size thing you\'re referring to. Could you\n> > point a little more specifically? Thanks!\n> >\n> > -Rob\n> >\n> > On 1 September 2014 19:48, Nejc Saje <nsaje at redhat.com> wrote:\n> >> Hey guys,\n> >>\n> >> in Ceilometer we\'re using consistent hash rings to do workload\n> >> partitioning[1]. We\'ve considered generalizing your hash ring\n> >> implementation\n> >> and moving it up to oslo, but unfortunately your implementation is not\n> >> actually consistent, which is our requirement.\n> >>\n> >> Since you divide your ring into a number of equal sized partitions,\n> >> instead\n> >> of hashing hosts onto the ring, when you add a new host,\n> >> an unbound amount of keys get re-mapped to different hosts (instead of the\n> >> 1/#nodes remapping guaranteed by hash ring). I\'ve confirmed this with the\n> >> test in aforementioned patch[2].\n> >>\n> >> If this is good enough for your use-case, great, otherwise we can get a\n> >> generalized hash ring implementation into oslo for use in both projects or\n> >> we can both use an external library[3].\n> >>\n> >> Cheers,\n> >> Nejc\n> >>\n> >> [1] https://review.openstack.org/#/c/113549/\n> >> [2]\n> >> https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py\n> >> [3] https://pypi.python.org/pypi/hash_ring\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<54070069.1080109@redhat.com>',NULL),('<1189111143.55.1370240542198.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-03 06:22:22',0,'2013-06-03 06:22:22',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #245','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/245/>\n\n------------------------------------------\n[...truncated 12600 lines...]\n\nnova.osapi_compute.wsgi.server: INFO: (18245) accepted (\'127.0.0.1\', 43374)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Jun/2013 06:16:58] \"GET /v2 HTTP/1.1\" 204 216 0.001039\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-403646af-eb15-4571-979c-54d00fab6547</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (18245) accepted (\'127.0.0.1\', 43375)\n\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record updated for 310f5912a8054cdd96b5935760650047 \nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x94dc9d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x94dc9d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:53582/v2/openstack/os-keypairs\nnova.compute.manager: INFO: Updating bandwidth usage cache\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-03 06:16:58 18245 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:53582/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Jun/2013 06:16:58] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.293569\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 4332a6067ecb4b4b9482879f4e10d09d \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:32950\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:32950/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (18245) wsgi starting up on http://127.0.0.1:32950/\n\nnova.osapi_compute.wsgi.server: INFO: (18245) accepted (\'127.0.0.1\', 48581)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Jun/2013 06:16:59] \"GET /v2 HTTP/1.1\" 204 216 0.001159\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-d1504db9-879b-4045-af67-a5a4a75dfe20</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (18245) accepted (\'127.0.0.1\', 48582)\n\nnova.compute.manager: INFO: Updating host status\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record updated for 4332a6067ecb4b4b9482879f4e10d09d \nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7174ed0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7174ed0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:32950/v2/openstack/os-keypairs\nnova.compute.manager: INFO: Updating bandwidth usage cache\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     name)\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-03 06:16:59 18245 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:32950/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [03/Jun/2013 06:16:59] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.311045\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.11\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.4\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.xIhNeFyCBI\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/245\n[SCP] Copying console log.\n\n\n','<1494470410.54.1370154132758.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<11891636.26589.1347382289709.JavaMail.jsuh@guest144.east.isi.edu>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2012-09-11 09:51:32',-25200,'2012-09-11 16:51:32',NULL,'[openstack-hpc] [Openstack] [HPC] Monthly telecon','All,\n\nThe documentation work is under review at https://review.openstack.org/#/c/12584/. If you have any comments, please let me know.\n\nThanks,\n\nJoseph\n\n----- Original Message -----\nFrom: \"Joseph Suh\" <jsuh at isi.edu>\nTo: \"Patrick Petit\" <patrick.michel.petit at gmail.com>\nCc: openstack-hpc at lists.openstack.org\nSent: Tuesday, September 4, 2012 1:57:50 PM\nSubject: Re: [openstack-hpc] [Openstack] [HPC] Monthly telecon\n\nPatrick,\n\nI can take the action item of documenting extra_specs extension and filtering. \n\nThanks,\n\nJoseph\n\n----- Original Message -----\nFrom: \"Patrick Petit\" <patrick.michel.petit at gmail.com>\nTo: \"John Paul Walters\" <jwalters at isi.edu>\nCc: openstack-hpc at lists.openstack.org\nSent: Tuesday, September 4, 2012 4:18:22 AM\nSubject: Re: [openstack-hpc] [Openstack] [HPC] Monthly telecon\n\n\nHi JP, \nSorry, I won\'t be able to join on the 10th. I think it\'ll be useful to take an action to make sure the HPC extensions (i.e. extra specs extensions and capabilities filtering) pushed into Folsom are properly documented in the OpenStack Admin Guide. I think it\'s not the case right now especially around how to specify off specs capabilities (nova.conf versus not nova.conf ?). For example, it\'s been said that key values for things like capabilities can be defined via host aggregates but it\'s not described how... Discussions and info around these topics are scattered and also the documentation is incomplete and lacking practical details. \nThanks \nPatrick \n\n\n_______________________________________________\nOpenStack-HPC mailing list\nOpenStack-HPC at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n\n','<9229414.719.1346781469499.JavaMail.jsuh@guest144.east.isi.edu>',NULL),('<1189617169.28611374.1403102251195.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 10:37:31',-14400,'2014-06-18 14:37:31',NULL,'[openstack-dev] An alternative approach to enforcing \"expected\n election behaviour\"','\n> James E. Blair wrote:\n> > I think our recent experience has shown that the fundamental problem is\n> > that not all of the members of our community knew what kind of behavior\n> > we expected around elections.  That\'s understandable -- we had hardly\n> > articulated it.  I think the best solution to that is therefore to\n> > articulate and communicate that.\n> > \n> > I believe Anita\'s proposal starts off by doing a very good job of\n> > exactly that, so I would like to see a final resolution based on that\n> > approach with very similar text to what she has proposed.  That\n> > statement of expected behavior should then be communicated by election\n> > officials to all participants in announcements related to all elections.\n> > Those two simple acts will, I believe, suffice to address the problem we\n> > have seen.\n> > \n> > I do agree that a heavy bureaucracy is not necessary for this.  Our\n> > community has a Code of Conduct established and administered by the\n> > Foundation.  I think we should focus on minimizing additional process\n> > and instead try to make this effort slot into the existing framework as\n> > easily as possible by expecting the election officials to forward\n> > potential violations to the Foundation\'s Executive Director (or\n> > delegate) to handle as they would any other potential CoC violation.\n>\n> Thierry Carrez wrote:\n> +1\n> \n> The community code of conduct states:\n> \n> \"\"\"Respect the election process. Members should not attempt to\n> manipulate election results. Open debate is welcome, but vote trading,\n> ballot stuffing and other forms of abuse are not acceptable.\"\"\"\n> \n> Maybe just clarifying what we mean by \"open debate\" and giving examples\n> of what we would consider \"other forms of abuse\" in the context of the\n> TC elections is actually sufficient. Then voters can judge abuse on\n> their own in their vote (reputational pressure) *and* we have an\n> established process (the alleged violation of the community code of\n> conduct) to escalate to in case we really need to (institutional pressure).\n> \n> I think the first part of Anita\'s draft captures that very well, so\n> maybe that\'s all we need. I really think that documenting and better\n> communicating expectations will actually avoid problems in the future.\n\nAbsolutely agreed with jeblair and ttx here, that communicating\nexpectations clearly is the key.\n\nHowever I think that the choice between relying on reputational\nversus institutional pressure for enforcement should be an\neither-or proposition, in order for it to be most effective.\n\nThe potential problem with reputational being the default, then\nfalling back to institutional pressure in extremis, is that folks\nmay read something into the absence of an escalation.\n\ne.g. \"the openstack officialdom doesn\'t seem to have done\n      anything about this practice, so it must be ok\"\n\nIMHO reliance on the wisdom-of-crowds for enforcement works best\nwhen the crowd explicitly knows that it\'s the last line of defense.\n\nCheers,\nEoghan\n\n\n','<53A14D05.3060305@openstack.org>',NULL),('<1190225565.44.1383372298366.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:04:58',0,'2013-11-02 06:04:58',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-cinder-docs-stable-grizzly #45','See <https://jenkins02.openstack.org/job/periodic-cinder-docs-stable-grizzly/45/>\n\n\n\n',NULL,NULL),('<1190870513.16.1352851575994.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:06:15',0,'2012-11-14 00:06:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/92/>\n\n------------------------------------------\n[...truncated 263 lines...]\n    test_get_image_details_by_name                               OK    0.05\n    test_get_image_details_by_property                           OK    0.06\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.04\n    test_get_image_details_marker_limit                          OK    0.07\n    test_get_image_details_sort_disk_format_asc                  OK    0.07\n    test_get_image_details_with_maximum_size                     OK    0.05\n    test_get_image_details_with_minimum_size                     OK    0.05\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.04\n    test_get_image_index_limit                                   OK    0.06\n    test_get_image_index_limit_None                              OK    0.06\n    test_get_image_index_marker                                  OK    0.07\n    test_get_image_index_marker_limit                            OK    0.07\n    test_get_image_members                                       OK    0.04\n    test_get_image_members_not_existing                          OK    0.04\n    test_get_image_non_existing                                  OK    0.04\n    test_get_index_sort_container_format_desc                    OK    0.06\n    test_get_index_sort_created_at_asc                           OK    0.06\n    test_get_index_sort_disk_format_asc                          OK    0.06\n    test_get_index_sort_id_desc                                  OK    0.07\n    test_get_index_sort_name_asc                                 OK    0.06\n    test_get_index_sort_size_asc                                 OK    0.06\n    test_get_index_sort_status_desc                              OK    0.07\n    test_get_index_sort_updated_at_desc                          OK    0.06\n    test_get_member_images                                       OK    0.04\n    test_replace_members                                         OK    0.04\n    test_update_image                                            OK    0.06\n    test_update_image_not_existing                               OK    0.04\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.00\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.00\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.19\n    test_version_control_existing_db                             OK    0.75\n    test_walk_versions                                           OK    0.65\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.01\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 38.03 secs:\n    11.62    TestScrubber.test_delayed_delete\n    8.74    TestBinGlance.test_results_filtering\n    6.54    TestBinGlance.test_results_pagination\n    5.97    TestBinGlance.test_results_sorting\n    5.16    TestBinGlance.test_add_list_update_list\n----------------------------------------------------------------------\nRan 338 tests in 96.600s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.5\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<1469094395.56.1352765123163.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1191711560.8170361.1404898870499.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 05:41:10',-14400,'2014-07-09 09:41:10',NULL,'[openstack-dev] [qa][all] Branchless Tempest beyond pure-API tests,\n impact on backporting policy','\nTL;DR: branchless Tempest shouldn\'t impact on backporting policy, yet\n       makes it difficult to test new features not discoverable via APIs\n\nFolks,\n\nAt the project/release status meeting yesterday[1], I raised the issue\nthat featureful backports to stable are beginning to show up[2], purely\nto facilitate branchless Tempest. We had a useful exchange of views on\nIRC but ran out of time, so this thread is intended to capture and\ncomplete the discussion.\n\nThe issues, as I see it, are:\n\n * Tempest is expected to do double-duty as both the integration testing\n   harness for upstream CI and as a tool for externally probing capabilities\n   in public clouds\n\n * Tempest has an implicit bent towards pure API tests, yet not all\n   interactions between OpenStack services that we want to test are\n   mediated by APIs\n\n * We don\'t have another integration test harness other than Tempest\n   that we could use to host tests that don\'t just make assertions\n   about the correctness/presence of versioned APIs\n\n * We want to be able to add new features to Juno, or fix bugs of\n   omission, in ways that aren\'t necessarily discoverable in the API;\n   without backporting these patches to stable if we wouldn\'t have\n   done so under the normal stable-maint policy[3]\n\n * Integrated projects are required[4] to provide Tempest coverage,\n   so the rate of addition of tests to Tempest is unlikely to slow\n   down anytime soon\n\nSo the specific type of test that I have in mind would be common\nfor Ceilometer, but also possibly for Ironic and others:\n\n 1. an end-user initiates some action via an API\n    (e.g. calls the cinder snapshot API)\n\n 2. this initiates some actions behind the scenes\n    (e.g. a volume is snapshot\'d and a notification emitted)\n\n 3. the test reasons over some expected side-effect\n    (e.g. some metering data shows up in ceilometer)\n\nThe branchless Tempest spec envisages new features will be added and\nneed to be skipped when testing stable/previous, but IIUC requires\nthat the presence of new behaviors is externally discoverable[5].\n\nOne approach mooted for allowing these kind of scenarios to be tested\nwas to split off the pure-API aspects of Tempest so that it can be used\nfor probing public-cloud-capabilities as well as upstream CI, and then\nbuild project-specific mini-Tempests to test integration with other\nprojects.\n\nPersonally, I\'m not a fan of that approach as it would require a lot\nof QA expertise in each project, lead to inefficient use of CI\nnodepool resources to run all the mini-Tempests, and probably lead to\na divergent hotchpotch of per-project approaches.\n\nAnother idea would be to keep all tests in Tempest, while also\nmicro-versioning the services such that tests can be skipped on the\nbasis of whether a particular feature-adding commit is present.\n\nWhen this micro-versioning can\'t be discovered by the test (as in the\npublic cloud capabilities probing case), those tests would be skipped\nanyway.\n\nThe final, less palatable, approach that occurs to me would be to\nrevert to branchful Tempest.\n\nAny other ideas, or preferences among the options laid out above? \n\nCheers,\nEoghan\n\n[1] http://eavesdrop.openstack.org/meetings/project/2014/project.2014-07-08-21.03.html\n[2] https://review.openstack.org/104863\n[3] https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes\n[4] https://github.com/openstack/governance/blob/master/reference/incubation-integration-requirements.rst#qa-1\n[5] https://github.com/openstack/qa-specs/blob/master/specs/implemented/branchless-tempest.rst#scenario-1-new-tests-for-new-features\n\n\n','<845865930.8137410.1404896912304.JavaMail.zimbra@redhat.com>',NULL),('<1191921867.256.1366524394124.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-21 06:06:34',0,'2013-04-21 06:06:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #11','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/11/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-21 06:06:29    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-21 06:06:29,683 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-21 06:06:29,686 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-21 06:06:29,690 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,695 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,698 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-21 06:06:29,701 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-21 06:06:29,704 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-21 06:06:29  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-21 06:06:29,708 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-21 06:06:29    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-21 06:06:29,711 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,732 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.731297\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.731297\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29,735 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,738 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,741 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,747 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.747156\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.747156\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,758 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,760 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-21 06:06:29,761 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,762 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,764 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29,765 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.764429\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.764429\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29,767 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,768 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,769 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-21 06:06:29,770 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,771 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,773 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29,774 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.773278\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.773278\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29,776 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,777 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,778 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-21 06:06:29,779 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,780 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,783 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-21 06:06:29,785 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-21 06:06:29,786 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.785035\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-21T06:06:29.785035\', resource_metadata={}) from 0 transformer\n2013-04-21 06:06:29,787 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,788 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29,790 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-21 06:06:29,791 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-21 06:06:29,792 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-21 06:06:29    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.421s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.11\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a332.g18d9a8b\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.ZtvMDhPBPa\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/11\n[SCP] Copying console log.\n\n\n','<747969834.242.1366438029893.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1192362744.2664991.1414628654841.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-29 20:24:14',-14400,'2014-10-30 00:24:14',NULL,'[Openstack-operators] qemu 1.x to 2.0','----- Original Message -----\n> From: \"Joe Topjian\" <joe at topjian.net>\n> To: \"Robert van Leeuwen\" <Robert.vanLeeuwen at spilgames.com>\n> \n> > I wonder if the qemu update issues are in the realm of the OpenStack\n> > project.\n> > Since they are provided / packaged by the distro\'s.\n> > Maybe people from Ubuntu & Redhat (which I would be interested in ;)\n> > reading this could give some suggestions...\n> >\n> \n> I\'d really appreciate someone from Ubuntu or Redhat clarifying this\n> situation.\n> \n> IMO, I don\'t think this issue is OpenStack\'s responsibility -- more on the\n> distribution side. This is why I\'m curious about the core reason why qemu\n> 1.x and 2.0 are marked as incompatible in Ubuntu\'s release notes. Is it\n> just how Ubuntu packaged/configured qemu? Or is it native to qemu itself\n> (which would then affect all distributions)?\n\nMy understanding is it\'s a combination of both issues to watch out for and fix in the qemu/libvirt projects themselves as new features are added as well as the machine types configured by the distributions, there were similar issues with migrations from RHEL 5 -> RHEL 6.\n\nAs a result work was done during the development of RHEL 7 to avoid a repeat of this and as a result migration of guests from RHEL 6 -> RHEL 7 is possible and supported out of the box [1]. RHEL 7 -> RHEL 6 migration is not however, apparently this is more problematic to handle.\n\nThanks,\n\nSteve\n\n[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-KVM_live_migration-Live_migration_and_Red_Hat_Enterprise_Linux_version_compatibility_.html\n\n\n','<CA+y7hvgNph-x6cOqCHuQ_othqrjvyFiFd6fMS9yF6zdqJcjbLw@mail.gmail.com>',NULL),('<1192788541.10196223.1375388225704.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-01 16:17:05',-14400,'2013-08-01 20:17:05',NULL,'[Openstack-docs] Common content strategy?','----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, August 1, 2013 4:08:35 PM\n> Subject: Re: [Openstack-docs] Common content strategy?\n> \n> On 02/08/13 06:06, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Tom Fifield\" <tom at openstack.org>\n> >> To: openstack-docs at lists.openstack.org\n> >> Sent: Thursday, August 1, 2013 3:53:54 PM\n> >> Subject: Re: [Openstack-docs] Common content strategy?\n> >>\n> >> Just quickly on the crazy linking that\'s going on right now.\n> >>\n> >> I\'m one of the worst offenders of breaking the model, but I believe\n> >> there\'s good reason ... in doing the restructure, I\'m trying to keep\n> >> current things in place, but note that they\'ll be subsumed as further\n> >> progress is made.\n> >>\n> >> If there\'s a big effort to push content into the common folder right\n> >> now, you\'ll end up with most of the compute admin manual and the config\n> >> reference in the common folder.\n> > \n> > Given at this stage the intent is to continue to release the compute\n> > administration guide isn\'t that correct though (in that the content *is*\n> > common to both)? Keep in mind here also that large swaths of the compute\n> > admin manual already appear in common (this is in part why I brought up\n> > the taxonomy question).\n> \n> Not for the next release, unless you want to write it :)\n\nOK, it was still listed last I saw - just not as one of the two deliverables that must be ready:\n\nhttp://lists.openstack.org/pipermail/openstack-docs/2013-July/002391.html\n\n> Additionally, the content in config ref that is currently xi:included\n> will be struck from the compute admin guide - it will not be common to both.\n\nRight, but to me that is all the more reason to do it now. As it currently stands without any of my commits on this issue being merged there are ~144 relative includes in openstack-config, of those only 10 go to locations outside of common (which are the ones I want to move).\n\nThanks,\n\nSteve\n\n\n','<51FAC043.6020206@openstack.org>',NULL),('<1193049956.133.1356221382868.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-23 00:09:42',0,'2012-12-23 00:09:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #83','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/83/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric7 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/>\nCheckout:periodic-nova-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/> - hudson.remoting.Channel at 1cca9f69:oneiric7\nUsing strategy: Default\nLast Built Revision: Revision 451003e0670b854bc833f32c67bb7ad646d3ac89 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.8.0\nERROR: Error cloning remote repo \'origin\' : Could not clone git://github.com/openstack/nova.git\nhudson.plugins.git.GitException: Could not clone git://github.com/openstack/nova.git\n	at hudson.plugins.git.GitAPI.clone(GitAPI.java:271)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1102)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n	at java.lang.Thread.run(Thread.java:679)\nCaused by: hudson.plugins.git.GitException: Command \"git clone --progress -o origin git://github.com/openstack/nova.git <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/\"> returned status code 128:\nstdout: Cloning into \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/\'...>\n\nstderr: fatal: remote error: \n  GitHub is offline for maintenance. See http://status.github.com for more info.\n\n	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:863)\n	at hudson.plugins.git.GitAPI.access$000(GitAPI.java:40)\n	at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:267)\n	at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:246)\n	at hudson.FilePath.act(FilePath.java:852)\n	at hudson.FilePath.act(FilePath.java:825)\n	at hudson.plugins.git.GitAPI.clone(GitAPI.java:246)\n	... 12 more\nTrying next repository\nERROR: Could not clone repository\nFATAL: Could not clone\nhudson.plugins.git.GitException: Could not clone\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1114)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n	at java.lang.Thread.run(Thread.java:679)\n\n\n',NULL,NULL),('<11930815.3285.1384368024010.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 10:40:26',-28800,'2013-11-13 18:40:26',NULL,'[openstack-dev] Congress: an open policy framework','We\'re just getting started with Congress and understanding how it will integrate with the OS ecosystem, but here\'s our current thinking about how Congress relates to Oslo\'s policy engine and to Keystone.  Comments and suggestions are welcome.\n\n\nCongress and Oslo\n--------------------\nThree dimensions for comparison: policy language, data sources, and policy engine.  \n\nWe\'ve always planned to make Congress compatible with existing policy languages like the one in oslo.  The plan is to build a front-end for a number of policy languages/formats, e.g. oslo-policy language, XACML, JSON, YAML, SQL, etc.  The idea being that the syntax/language you use is irrelevant as long as it can be mapped into Congress\'s native policy language.  As of now, Congress is using Datalog, which is a variant of SQL and is at least as expressive as all of the policy languages we\'ve run across in the cloud domain, including the oslo-policy language.\n\nIn terms of the data sources you can reference in the policy, Congress is designed to enable policies that reference arbitrary data sources in the cloud.  For example, we could write a Nova authorization policy that permits a new VM to be created if that VM is connected to a network owned by a tenant (info stored in Neutron) where the VM owner (info in the request) is in the same group as the network owner (info stored in Keystone/LDAP).  Oslo\'s handles some of these data sources with its terminal rules, but it\'s not involved in data integration to the same extent Congress is.\n\nIn terms of policy engines, Congress is intended to enforce policies in 2 different ways: proactively (stopping policy violations before they occur) and reactively (acting to eliminate a violation after it occurs).  Ideally we wouldn\'t need reactive enforcement, but there will always be cases where proactive enforcement is not possible (e.g. a DOS attack brings app latencies out of compliance).  The oslo-engine does proactive enforcement only--stopping API calls before they violate the policy.\n\nOne concrete integration idea would be to treat Congress as a plugin for the oslo-policy engine.  This wouldn\'t enable say Nova to write policies that take advantage of the expressiveness of Datalog, but it would give us backwards compatibility.\n\nCongress and Keystone\n----------------------\nI see Keystone as providing two pieces of functionality: authentication and group membership.  Congress has nothing to do with authentication and never will.  Groups, on the other hand, are things we end up defining when writing policies in Congress, so conceptually there\'s some overlap with Keystone.  I guess Congress could serve as a plugin/data source for Keystone and provide it with the groups defined within the policy.  This would allow a group to be defined using data sources not available to Keystone, e.g. we could define a group as all users who own a VM (info from Nova) connected to a network owned by someone (info from Neutron) in the same group (info from LDAP).  I don\'t know how useful or efficient this would be, and it\'s certainly not something we\'ve designed Congress for.\n\nThoughts?\nTim\n\n\n\n\n\n----- Original Message -----\n| From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Monday, November 11, 2013 3:10:01 PM\n| Subject: Re: [openstack-dev] Congress: an open policy framework\n| \n| \n| \n| \n| \n| \n| On Mon, Nov 11, 2013 at 4:28 AM, Flavio Percoco < flavio at redhat.com >\n| wrote:\n| \n| \n| \n| On 02/11/13 21:31 -0700, Tim Hinrichs wrote:\n| \n| \n| Hi OpenStackers,\n| \n| We\'ve been working on an open policy framework for OpenStack that\n| we\'re calling Congress. We\'ve been talking with OpenStack users and\n| several of our partners to understand the kinds of rules and\n| regulations they envision enforcing with a policy-based management\n| framework. Across the board they are interested in policies that\n| span networking, compute, storage, etc.\n| \n| The idea behind Congress is to have a single policy engine that\n| integrates any collection of external authentication and data stores\n| and allows cloud administrators to write policies over those data\n| stores in a rich, declarative language. The policy engine can either\n| enforce the policy proactively (i.e. preventing policy violations\n| before they occur) or reactively (identifying violations after they\n| occur and taking corrective action) or a combination (proactively\n| when possible and reactively when not). The policy engine can also\n| interact with the administrator, explaining the causes of\n| violations, computing potential remediation plans, and simulating\n| action executions to understand what violations those actions might\n| cause.\n| \n| While the project is still in the early stages, we have identified a\n| grammar for the policy language, implemented a policy engine, and\n| written a proof of concept integration for ActiveDirectory. We would\n| love to get participation and feedback.\n| \n| \n| Have you guys looked into oslo-incubator/policy.py ?\n| \n| What\'s wrong with the grammar used there?\n| \n| Have you guys considered starting your work from there?\n| \n| Although you\'re planning to create a policy service, it may make\n| sense\n| to be compliant with what OpenStack uses and maybe, you could\n| maintain\n| the whole policy library at some point.\n| \n| \n| \n| ++ I\'m excited to see some new effort in this space (and sad that I\n| wasn\'t aware of this ahead of the summit), but surprised by the\n| apparent lack of integration with the existing oslo.policy engine,\n| centralized policy storage in keystone (/v3/policies), etc. There\'s\n| no reason why you couldn\'t replace all that, but a comparison with\n| the existing policy infrastructure to indicate the advantages\n| provided by congress (without making me read the source!) would be\n| help this gain some traction within community.\n| \n| \n| \n| FF\n| \n| --\n| @flaper87\n| Flavio Percoco\n| \n| \n| \n| ______________________________ _________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack. org\n| http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev\n| \n| \n| \n| \n| --\n| \n| \n| -Dolph\n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n\n\n','<CAC=h7gUzddLmQpSv3u3Fzhnb5A+wYhnO8RFfFfUWCGzm+SmBAQ@mail.gmail.com>',NULL),('<1193271768.6796757.1374767241433.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-25 11:47:21',-14400,'2013-07-25 15:47:21',NULL,'[Openstack-docs] orderedlist vs procedure','----- Original Message -----\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Thursday, July 25, 2013 11:25:53 AM\n> Subject: [Openstack-docs] orderedlist vs procedure\n> \n> Hi all,\n> I\'ve noticed a general trend towards using <procedure> markup and I like\n> it, even though our original Conventions indicate to use <orderedlist>. [1]\n> \n> Would it be okay to change our Conventions to prefer <procedure> for tasks\n> as opposed to <orderedlist>?\n\nBig +1 from me.\n\n-Steve\n\n\n','<CAD0KtVGWPxVqH3XtB3-jqJQGLsPprqcrbLXVkj-jegBrSKcq-A@mail.gmail.com>',NULL),('<1193515565.127.1356221116856.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-23 00:05:16',0,'2012-12-23 00:05:16',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-folsom #83','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/83/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise10 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/>\nCheckout:periodic-swift-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/> - hudson.remoting.Channel at 48aee600:precise10\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson5202024079465512942.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.jznFwTuZ4e\n+ TMPDIR=/tmp/tmp.jznFwTuZ4e\n+ trap \'rm -rf /tmp/tmp.jznFwTuZ4e\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/83/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python27-stable-folsom-83\', \'SSH_CLIENT\': \'198.101.231.203 35643 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1355682909.807984-1981368639\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise10\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.jznFwTuZ4e\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2012-12-23_00-04-45\', \'BUILD_NUMBER\': \'83\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'3f81ecf9-9830-4700-8eb0-e73dae464a3d\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'78d79c104eef52324f0675937ae52201\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise10\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'78d79c104eef52324f0675937ae52201\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 35643 50.57.88.214 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Downloading master\n  Cannot unpack file /tmp/tmp.jznFwTuZ4e/pip-hh2cir-unpack/master (downloaded from <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient,> content-type: text/html; charset=utf-8); cannot detect archive format\nCannot determine archive format of <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.jznFwTuZ4e\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-folsom/83\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1194046700.460937.1389365424261.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-10 09:50:24',-18000,'2014-01-10 14:50:24',NULL,'[Openstack-docs] Cinder and sql_connect/connection','\n\n----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> Cc: \"Andreas Jaeger\" <aj at suse.com>, openstack-docs at lists.openstack.org\n> Sent: Friday, January 10, 2014 9:40:57 AM\n> Subject: Re: [Openstack-docs] Cinder and sql_connect/connection\n> \n> On at least Ubuntu and RHEL variants, placing \"connection\" in the\n> [database] section of cinder.conf appears to work.  However, the\n> base/sample cinder.conf on both distributions lacks the [database] section.\n>  The Ubuntu version is particularly sparse.\n> \n> For Ubuntu, a previous patch to the installation guide merely moved\n> \"sql_connection\" to the [database] section which isn\'t supported.  For RHEL\n> variants, apparently the \"openstack-config\" command breaks because it can\'t\n> find the [database] section and won\'t create it.  The Havana release of\n> Cinder still supports the legacy \"sql_connection\" in the [default] section\n> in both distributions.  We could revert the installation guides to use this\n> legacy configuration, but it would add an extra step for the upgrade\n> procedure to Icehouse.\n> \n> For Ubuntu, I suggest we use the modern configuration with \"connection\" in\n> the [database] section and tell people to create the [database] header if\n> it doesn\'t exist.  For RHEL variants, I suggest we mention editing\n> cinder.conf to add the [database] header before using the\n> \"openstack-config\" command with \"connection\" in the [database] section.  On\n> a side note, I\'m also thinking that \"openstack-config\" should support\n> creation of section headers.\n\nIt already does:\n\n-bash-4.1# touch test.conf\n-bash-4.1# openstack-config --set test.conf DEFAULT does_this_work True\n-bash-4.1# cat test.conf \n[DEFAULT]\ndoes_this_work = True\n\n-Steve\n\n\n','<CABA+jQr2bvUcgSRTMjVXOm2Ek6r6C10WN99fgXs48KN8d1nP-g@mail.gmail.com>',NULL),('<1195309990.268.1358812946666.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-22 00:02:26',0,'2013-01-22 00:02:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-folsom #113','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/113/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise4 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/>\nCheckout:periodic-swift-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/> - hudson.remoting.Channel at 73937bc8:precise4\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson1109260715416292110.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/113/\', \'BUILD_TAG\': \'jenkins-periodic-swift-docs-stable-folsom-113\', \'SSH_CLIENT\': \'198.101.231.203 58257 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1357687285.869901-1921516711\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'JOB_NAME\': \'periodic-swift-docs-stable-folsom\', \'NODE_LABELS\': \'precise precise4\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-22_00-01-35\', \'BUILD_NUMBER\': \'113\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'be0df775-b882-4aa7-af16-ea2db9de3837\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise4\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 58257 108.166.59.162 22\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-folsom/113\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1195894760.831325.1345053340738.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 10:55:40',-25200,'2012-08-15 17:55:40',NULL,'[openstack-dev] [Openstack] Discussion about where to put\n database for bare-metal provisioning (review 10726)','\n Hi Mark,\n\n One of our co-developers Arata raised the following issues of having per nova-compute db.\n\n* A different approach is needed to register/unregister nodes.\n        When I register many new nodes have different corresponging hosts, I have to exec bm_node_create/destory on host by host in current approach.\n* Because DB is distributed, full-backup may become difficult a little.\n\n His points are sound and reasonable.\nWhen we have tens of bare-metal nova-compute, the issue becomes more serious.\nHow about having a shared db on a node (that can be one of bare-metal nova-computes or \na node dedicated for this)\nand let the bare-metal compute nodes share db through the node?\n\n Thanks,\n David\n\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n----- Original Message -----\n> Hi David,\n> \n> On Wed, 2012-08-15 at 08:28 -0700, David Kang wrote:\n> >\n> >  Hi,\n> >\n> >  This is call for discussion about the code review 10726.\n> > https://review.openstack.org/#/c/10726/\n> > Mark asked why we implemented a separata database for bare-metal\n> > provisioning.\n> > Here we describe our thought.\n> > We are open to discussion and to the changes that the community\n> > recommends.\n> > Please give us your thoughts.\n> >\n> >  NTT Docomo and USC/ISI have developed bare-metal provisioning.\n> > We created separate database to describe bare-metal nodes, which\n> > consists of 5 tables now.\n> > Our initial implementation assumes the database is not a part of\n> > nova database.\n> > In addition to the reasons described in the comments of the code\n> > review,\n> > here is another reason we decided a separate database for baremetal\n> > provisioning.\n> >\n> > Bare-metal database is mainly used by bare-metal nova-compute.\n> > Since bare-metal nova-compute manages multiple bare-metal machines,\n> > it needs to keep/update the information of bare-metal machines.\n> > If the bare-metal database is in the main nova db, accessing nova db\n> > remotely by\n> > bare-metal nova-compute is inevitable.\n> > Once Vish told us that shared db access from nova-compute is not\n> > desirable.\n> >\n> > It is possible to make the scheduler do the job of bare-metal\n> > nova-compute.\n> > However, it would need a big changes in how the scheduler and a\n> > nova-compute\n> > communicates. For example, currently, the scheduler casts an\n> > instance to a\n> > nova-compute. But for bare-metal node, the scheduler should cast an\n> > instance\n> > to a bare-metal machine through bare-metal nova-compute.\n> > Bare-metal nova-compute should boot the machine, transfer kernel,\n> > fs, etc.\n> > So, bare-metal nova-compute should know the id of bare-metal node\n> > and other information\n> > for booting (PXE ip address, ...) and more.\n> > That information should be sent to bare-metal nova-compute by the\n> > scheduler.\n> >\n> > If frequent access of bare-metal tables in nova db from bare-metal\n> > nova-compute\n> > is OK, we are OK to put the bare-metal tables into nova db.\n> >\n> >  Please let us know your opinions.\n> \n> I just posted a comment in gerrit before seeing your mail.\n> \n> The big question for me is whether the baremetal DB needs to be shared\n> between compute nodes.\n> \n> Right now, it looks like the DB is designed to be shared (e.g. the\n> service_host column in the BareMetalNode) but could we re-work things\n> so\n> that it\'s not shared?\n> \n> The big issue with a shared DB is the problems it causes for upgrades\n> which we\'ve been trying to fix with no-db-compute.\n> \n> Cheers,\n> Mark.\n\n\n','<1345046082.4956.360.camel@sorcha>',NULL),('<1195e84a42bce659cf9ca9a5097b4174@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-16 20:38:28',7200,'2014-12-16 18:38:28',NULL,'[Openstack] Network speed issue',' I have changed that on both the node and the VMs and actually made \n things worse.\n\n I did that on both eth1 and br100 interfaces on the physical node.\n\n The transfer speed now is 15MB/s half of the one I had before!\n\n Have I missed something? I believe that this is not an expected \n behaviour?\n\n\n Here are the outputs for both br100 and eth1 on the node in case I have \n missed something:\n\n\n # ethtool -k br100\n Features for br100:\n rx-checksumming: off [fixed]\n tx-checksumming: on\n 	tx-checksum-ipv4: off\n 	tx-checksum-unneeded: off\n 	tx-checksum-ip-generic: on\n 	tx-checksum-ipv6: off\n 	tx-checksum-fcoe-crc: off [fixed]\n 	tx-checksum-sctp: off [fixed]\n scatter-gather: on\n 	tx-scatter-gather: on\n 	tx-scatter-gather-fraglist: on [fixed]\n tcp-segmentation-offload: off\n 	tx-tcp-segmentation: off\n 	tx-tcp-ecn-segmentation: on\n 	tx-tcp6-segmentation: on\n udp-fragmentation-offload: on [fixed]\n generic-segmentation-offload: off\n generic-receive-offload: off\n large-receive-offload: off [fixed]\n rx-vlan-offload: off [fixed]\n tx-vlan-offload: off [fixed]\n ntuple-filters: off [fixed]\n receive-hashing: off [fixed]\n highdma: on [fixed]\n rx-vlan-filter: off [fixed]\n vlan-challenged: off [fixed]\n tx-lockless: on [fixed]\n netns-local: on [fixed]\n tx-gso-robust: off [fixed]\n tx-fcoe-segmentation: off [fixed]\n tx-gre-segmentation: on [fixed]\n tx-udp_tnl-segmentation: on [fixed]\n fcoe-mtu: off [fixed]\n loopback: off [fixed]\n\n\n # ethtool -k eth1\n Features for eth1:\n rx-checksumming: on\n tx-checksumming: on\n 	tx-checksum-ipv4: off\n 	tx-checksum-unneeded: off\n 	tx-checksum-ip-generic: on\n 	tx-checksum-ipv6: off\n 	tx-checksum-fcoe-crc: off [fixed]\n 	tx-checksum-sctp: off [fixed]\n scatter-gather: on\n 	tx-scatter-gather: on\n 	tx-scatter-gather-fraglist: off [fixed]\n tcp-segmentation-offload: off\n 	tx-tcp-segmentation: off\n 	tx-tcp-ecn-segmentation: off\n 	tx-tcp6-segmentation: off\n udp-fragmentation-offload: off [fixed]\n generic-segmentation-offload: off\n generic-receive-offload: off\n large-receive-offload: off [fixed]\n rx-vlan-offload: on [fixed]\n tx-vlan-offload: on [fixed]\n ntuple-filters: off [fixed]\n receive-hashing: off [fixed]\n highdma: on [fixed]\n rx-vlan-filter: off [fixed]\n vlan-challenged: off [fixed]\n tx-lockless: off [fixed]\n netns-local: off [fixed]\n tx-gso-robust: off [fixed]\n tx-fcoe-segmentation: off [fixed]\n tx-gre-segmentation: off [fixed]\n tx-udp_tnl-segmentation: off [fixed]\n fcoe-mtu: off [fixed]\n loopback: off [fixed]\n\n\n\n\n Best,\n\n\n George\n\n\n\n\n\n> Disabling it only on the nodes should boost the speed but disabling \n> it\n> in the vms too improves greatly the speed\n> El 16/12/2014 19:13, \"Georgios Dimitrakakis\"  escribi?:\n>\n>> Ooops...It seems that I have been confused..\n>>\n>> The pasted part is indeed from the node when I was looking\n>> somewhere else....\n>>\n>> Thanks a lot for noticing that Adrian!!!!\n>>\n>> I will turn it off on the nodes and test again!\n>>\n>> Should it be off on both the nodes and the VMs?\n>>\n>> Regards,\n>>\n>> George\n>>\n>>> That shows that those 3 offload settibgs are enabled.\n>>> El 16/12/2014 19:01, \"Georgios Dimitrakakis\"? escribi?:\n>>>\n>>>> I believe that they are already disabled.\n>>>>\n>>>> Here is the ethtool output:\n>>>>\n>>>> # ethtool --show-offload eth1\n>>>> Features for eth1:\n>>>> rx-checksumming: on\n>>>> tx-checksumming: on\n>>>> ? ? ? ? tx-checksum-ipv4: off\n>>>> ? ? ? ? tx-checksum-unneeded: off\n>>>> ? ? ? ? tx-checksum-ip-generic: on\n>>>> ? ? ? ? tx-checksum-ipv6: off\n>>>> ? ? ? ? tx-checksum-fcoe-crc: off [fixed]\n>>>> ? ? ? ? tx-checksum-sctp: off [fixed]\n>>>> scatter-gather: on\n>>>> ? ? ? ? tx-scatter-gather: on\n>>>> ? ? ? ? tx-scatter-gather-fraglist: off [fixed]\n>>>> tcp-segmentation-offload: on\n>>>> ? ? ? ? tx-tcp-segmentation: on\n>>>> ? ? ? ? tx-tcp-ecn-segmentation: off\n>>>> ? ? ? ? tx-tcp6-segmentation: on\n>>>> udp-fragmentation-offload: off [fixed]\n>>>> generic-segmentation-offload: on\n>>>> generic-receive-offload: on\n>>>> large-receive-offload: off [fixed]\n>>>> rx-vlan-offload: on [fixed]\n>>>> tx-vlan-offload: on [fixed]\n>>>> ntuple-filters: off [fixed]\n>>>> receive-hashing: off [fixed]\n>>>> highdma: on [fixed]\n>>>> rx-vlan-filter: off [fixed]\n>>>> vlan-challenged: off [fixed]\n>>>> tx-lockless: off [fixed]\n>>>> netns-local: off [fixed]\n>>>> tx-gso-robust: off [fixed]\n>>>> tx-fcoe-segmentation: off [fixed]\n>>>> tx-gre-segmentation: off [fixed]\n>>>> tx-udp_tnl-segmentation: off [fixed]\n>>>> fcoe-mtu: off [fixed]\n>>>> loopback: off [fixed]\n>>>>\n>>>> Regards,\n>>>>\n>>>> George\n>>>>\n>>>>> Disable offloading on the nodes with: ethtool -K interfaceName\n>>>>> gro\n>>>>> off\n>>>>> gso off tso off\n>>>>>\n>>>>> And then try it again\n>>>>> El 16/12/2014 18:36, \"Georgios Dimitrakakis\"? escribi?:\n>>>>>\n>>>>>> Hi all!\n>>>>>>\n>>>>>> In my OpenStack installation (Icehouse and use nova legacy\n>>>>>> networking) the VMs are talking to each other over a 1Gbps\n>>>>>> network\n>>>>>> link.\n>>>>>>\n>>>>>> My issue is that although file transfers between physical\n>>>>>> (hypervisor) nodes can saturate that link transfers between\n>>>>>> VMs\n>>>>>> reach very lower speeds e.g. 30MB/s (approx. 240Mbps).\n>>>>>>\n>>>>>> My tests are performed by scping a large image file\n>>>>>> (approx.\n>>>>>> 4GB)\n>>>>>> between the nodes and between the VMs.\n>>>>>>\n>>>>>> I have updated my images to use e1000 nic driver but the\n>>>>>> results\n>>>>>> remain the same.\n>>>>>>\n>>>>>> What are any other limiting factors?\n>>>>>>\n>>>>>> Does it has to do with the disk driver I am using? Does it\n>>>>>> play\n>>>>>> significant role the filesystem of the hypervisor node?\n>>>>>>\n>>>>>> Any ideas on how to approach the saturation of the 1Gbps\n>>>>>> link?\n>>>>>>\n>>>>>> Best regards,\n>>>>>>\n>>>>>> George\n>>>>>>\n>>>>>> _______________________________________________\n>>>>>> Mailing list:\n>>>>>>\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> [1]\n>>>>>> [1] [1]\n>>>>>> Post to? ? ?: openstack at lists.openstack.org [2] [2] [2]\n>>>>>> Unsubscribe :\n>>>>>>\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> [3]\n>>>>>> [3] [3]\n>>>>>\n>>>>> Links:\n>>>>> ------\n>>>>> [1]\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>> [4]\n>>>>> [4]\n>>>>> [2] mailto:openstack at lists.openstack.org [5] [5]\n>>>>> [3]\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>> [6]\n>>>>> [6]\n>>>>> [4] mailto:giorgis at acmac.uoc.gr [7] [7]\n>>>\n>>> Links:\n>>> ------\n>>> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> [8]\n>>> [2] mailto:openstack at lists.openstack.org [9]\n>>> [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> [10]\n>>> [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> [11]\n>>> [5] mailto:openstack at lists.openstack.org [12]\n>>> [6] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> [13]\n>>> [7] mailto:giorgis at acmac.uoc.gr [14]\n>>> [8] mailto:giorgis at acmac.uoc.gr [15]\n>\n>\n> Links:\n> ------\n> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [2] mailto:openstack at lists.openstack.org\n> [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [5] mailto:openstack at lists.openstack.org\n> [6] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [7] mailto:giorgis at acmac.uoc.gr\n> [8] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [9] mailto:openstack at lists.openstack.org\n> [10] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [12] mailto:openstack at lists.openstack.org\n> [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> [14] mailto:giorgis at acmac.uoc.gr\n> [15] mailto:giorgis at acmac.uoc.gr\n> [16] mailto:giorgis at acmac.uoc.gr\n\n\n\n','<CAJw1JyWoUgVQGyVS_0SWxJUjx4h5kFbGmPY4qEEyDWWmfrU9AQ@mail.gmail.com>',NULL),('<1196785587.20.1385618668279.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-28 06:04:28',0,'2013-11-28 06:04:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #44','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/44/>\n\n------------------------------------------\n[...truncated 7127 lines...]\n2013-11-28 06:04:08 + local file=/etc/cinder/cinder.conf\n2013-11-28 06:04:08 + local section=DEFAULT\n2013-11-28 06:04:08 + local option=secure_delete\n2013-11-28 06:04:08 + local line\n2013-11-28 06:04:08 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-28 06:04:08 + line=\n2013-11-28 06:04:08 + \'[\' -n \'\' \']\'\n2013-11-28 06:04:08 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-28 06:04:08 secure_delete = False\n2013-11-28 06:04:08 \' /etc/cinder/cinder.conf\n2013-11-28 06:04:08 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-11-28 06:04:08 + local file=/etc/cinder/cinder.conf\n2013-11-28 06:04:08 + local section=DEFAULT\n2013-11-28 06:04:08 + local option=volume_clear\n2013-11-28 06:04:08 + local value=none\n2013-11-28 06:04:08 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-11-28 06:04:08 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-11-28 06:04:08 + local file=/etc/cinder/cinder.conf\n2013-11-28 06:04:08 + local section=DEFAULT\n2013-11-28 06:04:08 + local option=volume_clear\n2013-11-28 06:04:08 + local line\n2013-11-28 06:04:08 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-28 06:04:08 + line=\n2013-11-28 06:04:08 + \'[\' -n \'\' \']\'\n2013-11-28 06:04:08 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-28 06:04:08 volume_clear = none\n2013-11-28 06:04:08 \' /etc/cinder/cinder.conf\n2013-11-28 06:04:08 + \'[\' False == True \']\'\n2013-11-28 06:04:08 + \'[\' default == XenAPINFS \']\'\n2013-11-28 06:04:08 + \'[\' default == sheepdog \']\'\n2013-11-28 06:04:08 + is_service_enabled quantum\n2013-11-28 06:04:08 + services=quantum\n2013-11-28 06:04:08 + for service in \'${services}\'\n2013-11-28 06:04:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-11-28 06:04:08 + return 0\n2013-11-28 06:04:08 + install_quantum\n2013-11-28 06:04:08 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-11-28 06:04:08 + [[ False = \\T\\r\\u\\e ]]\n2013-11-28 06:04:08 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-11-28 06:04:08 + GIT_DEST=/opt/stack/new/neutron\n2013-11-28 06:04:08 + GIT_REF=stable/grizzly\n2013-11-28 06:04:08 + echo stable/grizzly\n2013-11-28 06:04:08 + egrep -q \'^refs\'\n2013-11-28 06:04:08 + [[ ! -d /opt/stack/new/neutron ]]\n2013-11-28 06:04:08 + [[ \'\' == \\y\\e\\s ]]\n2013-11-28 06:04:08 + setup_develop /opt/stack/new/neutron\n2013-11-28 06:04:08 + [[ False = True ]]\n2013-11-28 06:04:08 + SUDO_CMD=sudo\n2013-11-28 06:04:08 + cd /opt/stack/new/neutron\n2013-11-28 06:04:08 + python setup.py egg_info\n2013-11-28 06:04:08 running egg_info\n2013-11-28 06:04:08 creating quantum.egg-info\n2013-11-28 06:04:08 writing requirements to quantum.egg-info/requires.txt\n2013-11-28 06:04:08 writing quantum.egg-info/PKG-INFO\n2013-11-28 06:04:08 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-28 06:04:08 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-28 06:04:08 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-28 06:04:08 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-28 06:04:08 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-28 06:04:08 reading manifest template \'MANIFEST.in\'\n2013-11-28 06:04:08 warning: no files found matching \'AUTHORS\'\n2013-11-28 06:04:08 warning: no files found matching \'ChangeLog\'\n2013-11-28 06:04:08 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-28 06:04:10 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-28 06:04:10 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-28 06:04:10 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-28 06:04:10 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-11-28 06:04:10 + raw_links=\n2013-11-28 06:04:10 ++ echo\n2013-11-28 06:04:10 ++ xargs\n2013-11-28 06:04:10 + depend_links=\n2013-11-28 06:04:10 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-11-28 06:04:10 ++ echo \'-r *-info/requires.txt\'\n2013-11-28 06:04:10 + require_file=\'-r *-info/requires.txt\'\n2013-11-28 06:04:10 + pip_install -r quantum.egg-info/requires.txt\n2013-11-28 06:04:10 + [[ False = \\T\\r\\u\\e ]]\n2013-11-28 06:04:10 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-11-28 06:04:10 + [[ -z deb ]]\n2013-11-28 06:04:10 + [[ False = True ]]\n2013-11-28 06:04:10 + SUDO_PIP=sudo\n2013-11-28 06:04:10 ++ get_pip_command\n2013-11-28 06:04:10 ++ is_fedora\n2013-11-28 06:04:10 ++ [[ -z Ubuntu ]]\n2013-11-28 06:04:10 ++ \'[\' Ubuntu = Fedora \']\'\n2013-11-28 06:04:10 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-11-28 06:04:10 ++ \'[\' Ubuntu = CentOS \']\'\n2013-11-28 06:04:10 ++ which pip\n2013-11-28 06:04:10 + CMD_PIP=/usr/local/bin/pip\n2013-11-28 06:04:10 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-11-28 06:04:10 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-11-28 06:04:10 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:10   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-11-28 06:04:10   Running setup.py egg_info for package python-quantumclient\n2013-11-28 06:04:10     [pbr] Processing SOURCES.txt\n2013-11-28 06:04:10     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-11-28 06:04:10     \n2013-11-28 06:04:10     [pbr] In git context, generating filelist from git\n2013-11-28 06:04:10     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-11-28 06:04:10 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:10 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-11-28 06:04:11   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.1.tar.gz\n2013-11-28 06:04:11   Running setup.py egg_info for package alembic\n2013-11-28 06:04:11     \n2013-11-28 06:04:11     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-28 06:04:11     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-28 06:04:11     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-28 06:04:11     no previously-included directories found matching \'docs/build/output\'\n2013-11-28 06:04:11 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-11-28 06:04:11 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-11-28 06:04:11 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:11 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:11 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-28 06:04:12   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-11-28 06:04:12   Running setup.py egg_info for package Mako\n2013-11-28 06:04:12     \n2013-11-28 06:04:12     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-28 06:04:12     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-28 06:04:12     warning: no files found matching \'ez_setup.py\'\n2013-11-28 06:04:12     no previously-included directories found matching \'doc/build/output\'\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:12 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-28 06:04:12 Installing collected packages: python-quantumclient, alembic, Mako\n2013-11-28 06:04:12   Running setup.py install for python-quantumclient\n2013-11-28 06:04:12     [pbr] Reusing existing SOURCES.txt\n2013-11-28 06:04:12     Installing quantum script to /usr/local/bin\n2013-11-28 06:04:12   Running setup.py install for alembic\n2013-11-28 06:04:12     \n2013-11-28 06:04:12     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-28 06:04:12     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-28 06:04:12     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-28 06:04:12     no previously-included directories found matching \'docs/build/output\'\n2013-11-28 06:04:12     Installing alembic script to /usr/local/bin\n2013-11-28 06:04:12   Running setup.py install for Mako\n2013-11-28 06:04:12     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-11-28 06:04:12     \n2013-11-28 06:04:12     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-28 06:04:12     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-28 06:04:12     warning: no files found matching \'ez_setup.py\'\n2013-11-28 06:04:12     no previously-included directories found matching \'doc/build/output\'\n2013-11-28 06:04:12     changing mode of /usr/local/bin/mako-render to 755\n2013-11-28 06:04:12 Successfully installed python-quantumclient alembic Mako\n2013-11-28 06:04:12 Cleaning up...\n2013-11-28 06:04:12 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-11-28 06:04:12 running develop\n2013-11-28 06:04:12 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-11-28 06:04:12 /usr/bin/python -E -c pass\n2013-11-28 06:04:12 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-11-28 06:04:12 running egg_info\n2013-11-28 06:04:12 writing requirements to quantum.egg-info/requires.txt\n2013-11-28 06:04:12 writing quantum.egg-info/PKG-INFO\n2013-11-28 06:04:12 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-28 06:04:12 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-28 06:04:12 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-28 06:04:12 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-28 06:04:12 reading manifest template \'MANIFEST.in\'\n2013-11-28 06:04:12 warning: no files found matching \'AUTHORS\'\n2013-11-28 06:04:12 warning: no files found matching \'ChangeLog\'\n2013-11-28 06:04:12 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-28 06:04:12 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-28 06:04:12 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-28 06:04:12 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-28 06:04:12 running build_ext\n2013-11-28 06:04:12 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-11-28 06:04:12 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-11-28 06:04:12 Installing quantum-debug script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-nec-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-ryu-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-l3-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-db-manage script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-metadata-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-server script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-11-28 06:04:12 Installing quantum-rootwrap script to /usr/local/bin\n2013-11-28 06:04:12 \n2013-11-28 06:04:12 Installed /opt/stack/new/neutron\n2013-11-28 06:04:12 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-11-28 06:04:12 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-11-28 06:04:12 ++ failed\n2013-11-28 06:04:12 ++ local r=1\n2013-11-28 06:04:12 +++ jobs -p\n2013-11-28 06:04:12 ++ kill\n2013-11-28 06:04:12 ++ set +o xtrace\n2013-11-28 06:04:12 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-11-28-060133\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-758525-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-758525.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-758525/44/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2055912352.12.1385532726345.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<119784257.47114796.1410368232958.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 12:57:12',-14400,'2014-09-10 16:57:12',NULL,'[openstack-dev] On an API proxy from baremetal to ironic','As far as I understand it, though, that\'s a patch for a read-only mode.  It seems bizzare, and possibly dangerous, to proxy read commands, but not write commands.  It gives the impression that everything\'s fine until it\'s not fine (because someone tried to use an existing script to do a create command).  IMHO, it would be better to just tell people up front \"Update your scripts to use Ironic, because they won\'t work at all\" instead of leading people (through empirical evidence) to believe that their scripts will work, and then having them discover later that something broke because they tried to create a node.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, September 10, 2014 10:33:05 AM\n> Subject: Re: [openstack-dev] On an API proxy from baremetal to ironic\n> \n> On 09/09/2014 11:22 PM, Russell Bryant wrote:\n> > On 09/09/2014 05:24 PM, Michael Still wrote:\n> >> Hi.\n> >>\n> >> One of the last things blocking Ironic from graduating is deciding\n> >> whether or not we need a Nova API proxy for the old baremetal\n> >> extension to new fangled Ironic API. The TC has asked that we discuss\n> >> whether we think this functionality is actually necessary.\n> >>\n> >> It should be noted that we\'re _not_ talking about migration of\n> >> deployed instances from baremetal to Ironic. That is already\n> >> implemented. What we are talking about is if users post-migration\n> >> should be able to expect their previous baremetal Nova API extension\n> >> to continue to function, or if they should use the Ironic APIs from\n> >> that point onwards.\n> >>\n> >> Nova had previously thought this was required, but it hasn\'t made it\n> >> in time for Juno unless we do a FFE, and it has been suggested that\n> >> perhaps its not needed at all because it is an admin extension.\n> >>\n> >> To be super specific, we\'re talking about the \"baremetal nodes\" admin\n> >> extension here. This extension has the ability to:\n> >>\n> >>  - list nodes running baremetal\n> >>  - show detail of one of those nodes\n> >>  - create a new baremetal node\n> >>  - delete a baremetal node\n> >>\n> >> Only the first two of those would be supported if we implemented a proxy.\n> >>\n> >> So, discuss.\n> > \n> > I\'m in favor of proceeding with deprecation without requiring the API\n> > proxy.\n> > \n> > In the case of user facing APIs, the administrators in charge of\n> > upgrading the cloud do not have full control over all of the apps using\n> > the APIs.  In this particular case, I would expect that the cloud\n> > administrators have *complete* control over the use of these APIs.\n> > \n> > Assuming we have one overlap release (Juno) to allow the migration to\n> > occur and given proper documentation of the migration plan and release\n> > notes stating the fact that the old APIs are going away, we should be fine.\n> > \n> > In summary, +1 to moving forward without the API proxy requirement.\n> \n> The thing is, we have the patch -\n> https://review.openstack.org/#/c/120433/, so it\'s not like there is a\n> zomg run around to get the patch.\n> \n> I think we should FFE this patch as it provides a smoother transition\n> from baremetal to ironic. The patch is extremely low risk to the rest of\n> Nova, as it\'s a surface proxy feature, so lets just land it and move\n> forward.\n> \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<54106121.6000204@dague.net>',NULL);
INSERT INTO `messages` VALUES ('<1198482366.12.1359616002481.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-31 07:06:42',0,'2013-01-31 07:06:42',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #84','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/84/>\n\n------------------------------------------\n[...truncated 16250 lines...]\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/7f221dd4-d343-472b-ae5b-45d93a7c93c6\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:03:54 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-ecf197b1-c92c-41ae-b22a-4ba7d96e6474\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/bdb9dd75-7bfc-4980-aa9b-efb7777f27b7\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:03:56 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c2575a42-37ee-4d6e-9fb8-2abdda9e6812\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f8d08218-15dc-43dc-a847-d2cafcf504af\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:03:57 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-f7cd9ff4-7a1e-4fc0-b8fa-280a2ad791fa\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/a0edcf90-1054-4167-8a28-4118f1d25335\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:03:58 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-56a1cf31-b0de-4d2f-b3e7-fabc746dafcb\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/70d38a2b-d161-44ca-ac33-3aa23ba5ac8f\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:03:59 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d06ddd42-dde7-4840-9cee-b67a42a7d071\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/32f05f3c-0910-422a-b086-f89fd300b362\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:04:00 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-29456bd4-46df-4bdc-83e1-ae363cb6ef40\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/7d7c0b21-2082-43c5-8597-678ea6f4d5b3\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:04:01 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-74d20bde-c5be-4d1b-b186-a697d835a81e\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/4afb4274-d295-41e3-8e06-2749bd6f881c\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:04:02 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-49295f5f-6b7b-4002-a73d-f8354610519d\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/12a70685-a4ec-46cd-85b9-8f25c16b5610\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:04:03 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-754ed2d1-bc08-465a-9fcd-92b26c74e249\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMVQwNzowMzozNy4xNjA2NjgiLCAiZXhwaXJlcyI6ICIyMDEzLTAyLTAxVDA3OjAzOjM3WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzBmOTMyZTU0MWRkNDNjYmIzZGM1N2U4Y2VjYmY5OGMiLCAiaWQiOiAiNjM1NDRjNDZlOWE5NDY1MWE0YWFlNWI3NjY1M2UwNGMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJhNGY1M2I4ZDRjNjE0ZmJiOGEwZWVlYjJhMTU0N2I4NyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNhNmQ0ZDY4NzQxNGY5N2E5N2FlNmE3MjU1NjhmNzciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyIsICJpZCI6ICI2ZTkyZGQ3ZmQ5N2M0N2RkOGEzMGNlZTYzNWI2NWMyOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICJhZGZiMTJmMmU4YmE0ZmViODE0MGVlMTI3M2M0OWU0NiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzMwZjkzMmU1NDFkZDQzY2JiM2RjNTdlOGNlY2JmOThjIiwgImlkIjogIjkzNzBkNzQ4YWRlMTRlNjQ4MTk1OWMyYWFlYmY4ZGM5IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zMGY5MzJlNTQxZGQ0M2NiYjNkYzU3ZThjZWNiZjk4YyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogImYxMmZkM2I3MzAyZjQ4OWM4Y2ZkZTNkYWUzMDc5YzllIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMjIxN2YxZDBkZWQ4NDAzMTgwNmFlOWQ4NjJkZTRjYTQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDZhNzFlZmYzOGIyNGRiOGE5NjI0MzQ2YmRkNTdhZTUiLCAiMzIzNzMyMjFhMzA2NDAxNmJhYTUxMjY1NTBmNDU4YzgiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBk8KDMTB9sxU2853IrkH2q6HIPPtPRD6c1JvWzgx6PCqtZ+uJ2XJg7bbhTZgQym0dr-Y5r+WMn9hNXgjXNQ46zCODl+TkCZ7Pg5pcHbJbPQdWJv0kEvrBw6V2zQdurRq9eutb4ko6S1a2GFXMNgtXEvOAjkbiOp-gODBJA5-Hapg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/0409fc83-2cd6-4ea6-91b4-d36b8f977875\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 31 Jan 2013 07:04:04 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-550962c5-650d-43f6-8e31-34e980ab1685\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntempest.tests.object_storage.test_account_services.AccountTest.test_list_containers_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization ... SKIP: Until Bug 1093743 is resolved.\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_invalid_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_none_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_no_body ... SKIP: Until bug 1090320 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... SKIP: Until bug 1090320 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_create_with_empty_name ... SKIP: Until bug 1090356 is fixed\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... SKIP: Until bug 1090356 is fixed\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestJSON.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\n\n======================================================================\nERROR: tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestJSON.test_associate_ip_to_server_without_passing_floating_ip\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/floating_ips_client.py\", line 73, in associate_floating_ip_to_server\n    resp, body = self.post(url, post_body, self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n\n-------------------- >> begin captured logging << --------------------\ntempest.tests.compute: DEBUG: Entering tempest.tests.compute.setup_package\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/6534d9e6bb244020949bec9c4bcebb8c/servers/6e233ed9-6160-4a41-9a00-ff08b4819ce4/action\ntempest.common.rest_client: ERROR: Request Body: {\"addFloatingIp\": {\"address\": \"\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 31 Jan 2013 06:25:06 GMT\', \'status\': \'400\', \'content-length\': \'82\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-5ecc0b62-9c9d-415f-9b1f-01fed1cf5018\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestXML.test_associate_ip_to_server_without_passing_floating_ip\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/floating_ips_client.py\", line 83, in associate_floating_ip_to_server\n    resp, body = self.post(url, str(doc), self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n\n-------------------- >> begin captured logging << --------------------\ntempest.tests.compute: DEBUG: Entering tempest.tests.compute.setup_package\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/55c7e52cb9c7490a8c23c781be528c35/servers/0a8770e0-3891-4f51-8e66-87fffb087219/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<addFloatingIp address=\"\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 31 Jan 2013 06:26:12 GMT\', \'status\': \'400\', \'content-length\': \'144\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-0728af83-6888-476a-a2f1-5a451c7d6755\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 567 tests in 2572.014s\n\nFAILED (SKIP=75, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/rabbitmq/rabbit at devstack-1359603091-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/rabbitmq/rabbit at devstack-1359603091.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/84/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1446929572.439.1359528723135.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1199069702.58.1381645747647.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-13 06:29:07',0,'2013-10-13 06:29:07',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #34','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/34/>\n\n------------------------------------------\n[...truncated 21115 lines...]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\nInitialized empty Git repository in /tmp/tempest-unitNOPK0b/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitV_EadO/.git/\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          199.383\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  173.978\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  70.542\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     39.785\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     38.896\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        38.427\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        35.928\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         32.947\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         31.147\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        29.287\n\n----------------------------------------------------------------------\nRan 1357 tests in 1264.954s\n\nOK (skipped=65)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-575992-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-575992.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-575992/34/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<192829195.53.1381559495926.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<119A1974-380C-461E-9937-65B9763E39E6@brocade.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 05:26:09',0,'2014-12-02 05:26:09',NULL,'[openstack-dev] [Neutron] Edge-VPN and Edge-Id','I hope we all understand how edge VPN works and what interactions are introduced as part of this spec.  I see references to neutron-network mapping to the tunnel which is not at all case and the edge-VPN spec doesn?t propose it.  At a very high level, there are two main concepts:\n\n  1.  Creation of a per tenant VPN ?service? on a PE (physical router) which has a connectivity to other PEs using some tunnel (not known to tenant or tenant-facing).  An attachment circuit for this VPN service is also created which carries a ?list\" of tenant networks (the list is initially empty) .\n  2.  Tenant ?updates? the list of tenant networks in the attachment circuit which essentially allows the VPN ?service? to add or remove the network from being part of that VPN.\n\nA service plugin implements what is described in (1) and provides an API which is called by what is described in (2).  The Neutron driver only ?updates? the attachment circuit using an API (attachment circuit is also part of the service plugin? data model).   I don?t see where we are introducing large data model changes to Neutron?  How else one introduces a network service in OpenStack if it is not through a service plugin?  As we can see, tenant needs to communicate (explicit or otherwise) to add/remove its networks to/from the VPN.  There has to be a channel and the APIs to achieve this.\n\nThanks,\n?Hanif.\n\nFrom: Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Monday, December 1, 2014 at 4:35 PM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [Neutron] Edge-VPN and Edge-Id\n\nOn 1 December 2014 at 09:01, Mathieu Rohon <mathieu.rohon at gmail.com<mailto:mathieu.rohon at gmail.com>> wrote:\nThis is an alternative that would say : you want an advanced service\nfor your VM, please stretch your l2 network to this external\ncomponent, that is driven by an external controller, and make your\ntraffic goes to this component to take benefit of this advanced\nservice. This is a valid alternative of course, but distributing the\nservice directly to each compute node is much more valuable, ASA it is\ndoable.\n\nRight, so a lot rides on the interpretation of \'advanced service\' here, and also \'attachment\'.\n\nFirstly, the difference between this and the \'advanced services\' (including the L3 functionality, though it\'s not generally considered an \'advanced service\') is that advanced services that exist today attach via an addressed port.  This bridges in.  That\'s quite a signifcant difference, which is to an extent why I\'ve avoided lumping the two together and haven\'t called this an advanced service itself, although it\'s clearly similar.\n\nSecondly, \'attachment\' has historically meant a connection to that port.  But in DVRs, it can be a multipoint connection to the network - manifested on several hosts - all through the auspices of a single port.  In the edge-id proposal you\'ll note that I\'ve carefully avoided defining what an attachment is, largely because I have a natural tendency to want to see the interface at the API level before I worry about the backend, I admit.  Your point about distributed services is well taken, and I think would be addressed by one of these distributed attachment types.\n\n> So the issue I worry about here is that if we start down the path of adding\n> the MPLS datamodels to Neutron we have to add Kevin\'s switch control work.\n> And the L2VPN descriptions for GRE, L2TPv3, VxLAN, and EVPN.  And whatever\n> else comes along.  And we get back to \'that\'s a lot of big changes that\n> aren\'t interesting to 90% of Neutron users\' - difficult to get in and a lot\n> of overhead to maintain for the majority of Neutron developers who don\'t\n> want or need it.\n\nThis shouldn\'t be a lot of big changes, once interfaces between\nadvanced services and neutron core services will be cleaner.\n\nWell, incorporating a lot of models into Neutron *is*, clearly, quite a bit of change, for starters.\n\nThe edge-id concept says \'the data models live outside neutron in a separate system\' and there, yes, absolutely, this proposes a clean model for edge/Neutron separation in the way you\'re alluding to with advanced services.  I think your primary complaint is that it doesn\'t define that interface for an OVS driver based system.\n\nThe edge-vpn concept says \'the data models exists within neutron in an integrated fashion\' and, if you agree that separation is the way to go, this seems to me to be exactly the wrong approach to be using.  It\'s the way advanced services are working - for now - but that\'s because we believe it would be hard to pull them out because the interfaces between service and Neutron don\'t currently exist.  The argument for this seems to be \'we should incorporate it so that we can pull it out at the same time as advanced services\' but it feels like that\'s making more work now so that we can do even more work in the future.\n\nFor an entirely new thing that is in many respects not like a service I would prefer not to integrate it in the first place, thus skipping over that whole question of how to break it out in the future.  It\'s an open question whether the work to make it play nicely with the existing ML2 model is worth the effort or not, because I didn\'t study that.  It\'s not relevant to my needs, but if you\'re interested then we could talk about what other specs would be required.\n--\nIan.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141202/a7d1107d/attachment.html>\n\n','<CAPoubz5KLKuoKoMH=hFUEpDD7A9OLKaxcYo-RFgRgGdKDZ8_iw@mail.gmail.com>',NULL),('<11A13EB6-607C-42B7-8D54-2DBC7FFDDA54@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-13 15:58:50',-14400,'2013-05-13 19:58:50',NULL,'[openstack-dev] [Network]LBaaS IRC Meeting','The LBaaS sub-team is going to meet Thursday May 16th at 1400 UTC. We\'ll use #openstack-meeting on IRC.  During the meeting, we\'ll review the current progress for H1 and look ahead at the next steps.\n\nmark\n\n',NULL,NULL),('<11a2b24737371a835baf25183fa9a208@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-02 11:42:33',7200,'2014-03-02 09:42:33',NULL,'[Openstack] Image Network+SWAP',' Dear Antonio,\n\n thank you very much for the useful info!\n\n I will give it a shot!!!\n\n Best,\n\n G.\n\n On Sat, 1 Mar 2014 12:17:14 +0100, Antonio Messina wrote:\n> On Fri, Feb 28, 2014 at 8:36 PM, Georgios Dimitrakakis\n> <giorgis at acmac.uoc.gr> wrote:\n>> Thx for your suggestion!\n>>\n>> I am trying since yesterday to achieve this but unfortunately the \n>> installer\n>> always start in a text-based mode and cannot change the partition \n>> scheme\n>> from there :-(\n>\n> Hi Georgios,\n>\n> I don\'t know if this can be helpful for you or other people here, but\n> I usually create my centos/ubuntu images with virt-inst from \n> kickstart\n> or preseed using a script.\n>\n> Script and related kickstart is available at\n> https://github.com/gc3-uzh-ch/openstack-tools\n> they are mainly for internal use, so you may need to modify the\n> kickstart (we always provides images with the \'gc3-user\' user so we\n> need to modify the configuration of cloud-init.\n>\n> We partition our disks with one single partition. The script doesn\'t\n> yet take into account the extra swap partition though, we don\'t have\n> swap in our flavors.\n>\n> .a.\n\n-- \n\n\n','<CA+jNneBFPaHQfu8wwKXMLKO2WAPnFy-WJkurKZifiJkqAJm=WQ@mail.gmail.com>',NULL),('<11A3220C-E60C-4E6F-BC70-6E63214CFE62@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 11:12:28',-25200,'2013-04-04 18:12:28',NULL,'[openstack-dev] [Openstack-operators] Volume attach mountpoints','Horizon should IMO, I believe there is a config option to turn it on.\n\nWe left the cli option mandatory because we would have had to convert it to a --arg from a positional arg which would break existing scripts.\n\nVish\n \nOn Apr 4, 2013, at 11:06 AM, Jacob Godin <jacobgodin at gmail.com> wrote:\n\n> Just a thought, but maybe Horizon and the nova volume-attach command should default to \'auto\'? That could potentially be less confusing for end users.\n> \n> \n> On Thu, Apr 4, 2013 at 3:01 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> Yes it should, this is why the auto assign option was added in folsom:\n> \n> nova volume-attach test-instance <volume-uuid> auto\n> \n> Vish\n> \n> On Apr 4, 2013, at 10:38 AM, Abel Lopez <alopgeek at gmail.com> wrote:\n> \n> > I\'ve been dealing with lots of confusion from users, mainly because the mountpoint they specify in volume-attach really has no bearing onto what the guest OS does with the volume.\n> >\n> > Here\'s some examples:\n> > m1.tiny has no ephemeral disk, Horizon \"Suggests\" /dev/vdc as the mountpoint. The OS assigns the volume to the next available device, which is /dev/vdb\n> >\n> > a flavor with an existing (perhaps unused) ephemeral disk at /dev/vdb, and the user specifies /dev/vdb in volume-attach, OS will use the next available device, and confuse the user.\n> >\n> > Windows guests - have no /dev/ - volumes show up as disk1, disk2, etc.\n> >\n> > Having the mountpoint seems to do more to confuse the users. This is an option that really doesn\'t seem to bring anything to the table. We should really just leave device assignment to the guest OS, no?\n> >\n> > Thoughts?\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130404/4c01b968/attachment.html>\n\n','<CA+WiSK43-jNb4henfG7H1YKKkK0dC+TKjjcnT-_QgBAJJZTZRw@mail.gmail.com>',NULL),('<11A3220C-E60C-4E6F-BC70-6E63214CFE62@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-04-04 11:12:28',-25200,'2013-04-04 18:12:28',NULL,'[Openstack-operators] [openstack-dev] Volume attach mountpoints','Horizon should IMO, I believe there is a config option to turn it on.\n\nWe left the cli option mandatory because we would have had to convert it to a --arg from a positional arg which would break existing scripts.\n\nVish\n \nOn Apr 4, 2013, at 11:06 AM, Jacob Godin <jacobgodin at gmail.com> wrote:\n\n> Just a thought, but maybe Horizon and the nova volume-attach command should default to \'auto\'? That could potentially be less confusing for end users.\n> \n> \n> On Thu, Apr 4, 2013 at 3:01 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> Yes it should, this is why the auto assign option was added in folsom:\n> \n> nova volume-attach test-instance <volume-uuid> auto\n> \n> Vish\n> \n> On Apr 4, 2013, at 10:38 AM, Abel Lopez <alopgeek at gmail.com> wrote:\n> \n> > I\'ve been dealing with lots of confusion from users, mainly because the mountpoint they specify in volume-attach really has no bearing onto what the guest OS does with the volume.\n> >\n> > Here\'s some examples:\n> > m1.tiny has no ephemeral disk, Horizon \"Suggests\" /dev/vdc as the mountpoint. The OS assigns the volume to the next available device, which is /dev/vdb\n> >\n> > a flavor with an existing (perhaps unused) ephemeral disk at /dev/vdb, and the user specifies /dev/vdb in volume-attach, OS will use the next available device, and confuse the user.\n> >\n> > Windows guests - have no /dev/ - volumes show up as disk1, disk2, etc.\n> >\n> > Having the mountpoint seems to do more to confuse the users. This is an option that really doesn\'t seem to bring anything to the table. We should really just leave device assignment to the guest OS, no?\n> >\n> > Thoughts?\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130404/4c01b968/attachment.html>\n\n','<CA+WiSK43-jNb4henfG7H1YKKkK0dC+TKjjcnT-_QgBAJJZTZRw@mail.gmail.com>',NULL),('<11A603B3-0884-4CB4-AE0E-69A495636A27@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 16:13:59',0,'2014-03-18 16:13:59',NULL,'[openstack-dev] [neutron] Globally-unique VM MAC address to\n	do	vendor-backed DHCP','\nOn Mar 18, 2014, at 7:40 AM, Roman Verchikov <rverchikov at mirantis.com<mailto:rverchikov at mirantis.com>> wrote:\n\nHi stakers,\n\nWe?re trying to replace dnsmasq-supplied DHCP for tenant VMs with a vendor?s baremetal DHCP server. In order to pass DHCP request to a vendor?s server and send DHCP response back to VM we decided to add another OVS bridge (we called it br-dhcp), connected to integration bridge (br-int), which will have OVS rules connecting VM?s MAC address with br-dhcp port. In this scenario DHCP response will only find it?s way back to a VM if VM has globally-unique MAC address.\n\nMy questions are:\n\n  *   is having code which generates globally-unique MACs for VMs acceptable by the community at all?\n\nThis question tends to pop up from time to time and there are valid deployment and usage scenarios where you would want to assign the same MAC to multiple ports.\n\n\n  *   is there a better solution to the problem (we also tried using dnsmasq as a DHCP relay there)?\n\nThat answer really depends on a number of factors.\n - Are the IP allocations being handled inside or outside of Neutron?\n - Do you allow different networks to have overlapping IP ranges?\n -\n\nIf it is outside of the OpenStack deployment then your code can use flow mods with you br-dhcp. If Neutron is managing the allocations or you allow overlapping IPs, you probably want to consider implementing a driver for the DHCP server.\n\nmark\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140318/023711b4/attachment.html>\n\n','<9F71F159-743A-4F1E-B4FE-A42045D2FFDD@mirantis.com>',NULL),('<11a8c248-e7c9-48b9-a2ac-6a290f8de43f@email.android.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-15 22:32:56',3600,'2014-03-15 21:32:56',NULL,'[Openstack-docs] back-end,\n	back end or backend in OPS Guide and openstack-manuals?','On 15. M?rz 2014 21:38:58 MEZ, Anne Gentle <anne at openstack.org> wrote:\n>Sorry, hit send too soon. I am seeing \"back-end\" as a markup by\n>double-clicking the red dash and seeing the whole word corrected to\n>back-end using Adobe Reader in multiple locations.\n>\n>However, I see\n>http://chimera.labs.oreilly.com/books/1230000000969/ch04.htmlas\n>backend so I\'m sending this to our copy editor John Pierce. John, can\n>you comment?\n>\n>Thanks,\n>Anne\n>\n>\n>On Sat, Mar 15, 2014 at 3:34 PM, Anne Gentle <anne at openstack.org>\n>wrote:\n>\n>> He intends it to be changed to back-end.\n>>\n>>\n>> On Sat, Mar 15, 2014 at 1:51 PM, Andreas Jaeger <aj at suse.com> wrote:\n>>\n>>> On 03/15/2014 07:33 PM, Matt Kassawara wrote:\n>>> > I thought we were only supposed to tackle \"AU\" comments.\n>>> >\n>>>\n>>> There\'re yellow sticky notes with AU in it and there are blue edits.\n>I\'m\n>>> tackling all blue edits,\n>>>\n>>> Andreas\n>>> --\n>>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica:\n>jaegerandi\n>>>   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>>>    GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG\n>N?rnberg)\n>>>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272\n>A126\n>>>\n>>\n>>\n\nSo, it\'s backend - how shall we handle openstack-manuals and especially the glossary? \n\nI would prefer to use the same spelling everywhere and minimize divergence, \n\nAndreas \n-- \nAndreas Jaeger\naj@{suse.com,novell.com,opensuse.org} Twitter / Identica: jaegerandi\nSUSE LINUX Products GmbH , Maxfeldstr. 5, 90409 N?rnberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) \nThis email was sent from my phone\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140315/89ad64b5/attachment.html>\n\n','<CAD0KtVFzt6tgA4GOaL5rWtCMRbD3ig1WgvoG2SmqUy0owRoaTA@mail.gmail.com>',NULL),('<11B44927-C23B-45D7-A35B-68C4B783FC7F@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-05 02:54:32',0,'2013-11-05 02:54:32',NULL,'[openstack-dev] [Heat] Network topologies','On Nov 4, 2013, at 7:31 PM, Clint Byrum <clint at fewbar.com> wrote:\n> Excerpts from Kyle Mestery (kmestery)\'s message of 2013-11-05 06:35:04 +0800:\n>> On Nov 2, 2013, at 3:12 PM, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>> \n>>> Hi.\n>>> \n>>> I looked at the detailed API specification submitted by Edgar.\n>>> I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work.\n>>> On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else.\n>>> \n>>> First, the \"use cases\" section merely re-states the objective session. I think that section should somehow address the questions \"why do we need this API?\" \"How having an API for storing network topologies would be useful for us\".\n>>> \n>>> The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals?\n>>> \n>> \n>> Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1\n>> \n> \n> Hi Kyle, can you copy this to etherpad.openstack.org and link it from\n> https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads\n> \nHi Clint:\n\nI\'ve already posted an etherpad there, it\'s in fact at this link [1]. I\'ve copied some notes there, it\'s hard to translate the diagrams but what I\'ve put in there is enough to get the discussion going on Friday.\n\nThanks,\nKyle\n\n[1] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron\n\n\n> Thanks!\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1383614860-sup-8730@clint-HP>',NULL),('<11B4BD25-9235-4C5F-A282-7540D591507A@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-19 16:22:32',-14400,'2013-03-19 20:22:32',NULL,'[openstack-dev] Change in openstack/quantum[master]: Add\n	bulking support for Cisco plugin','Thanks for the review guys. Can I get some core reviewers, please?\n\n\nPCM (Paul Michali)\n\nOn Mar 19, 2013, at 3:02 PM, Edgar Magana (Code Review) wrote:\n\n> Edgar Magana has posted comments on this change.\n> \n> Change subject: Add bulking support for Cisco plugin\n> ......................................................................\n> \n> \n> Patch Set 5: Looks good to me, but someone else must approve\n> \n> --\n> To view, visit https://review.openstack.org/22470\n> To unsubscribe, visit https://review.openstack.org/settings\n> \n> Gerrit-MessageType: comment\n> Gerrit-Change-Id: I874295b32ea20c2ca393228b0893a9dd6c77baf2\n> Gerrit-PatchSet: 5\n> Gerrit-Project: openstack/quantum\n> Gerrit-Branch: master\n> Gerrit-Owner: Paul Michali <pcm at cisco.com>\n> Gerrit-Reviewer: Arvind Somya\n> Gerrit-Reviewer: Edgar Magana <emagana at plumgrid.com>\n> Gerrit-Reviewer: Henry Gessau <gessau at cisco.com>\n> Gerrit-Reviewer: Jenkins\n> Gerrit-Reviewer: Paul Michali <pcm at cisco.com>\n> Gerrit-Reviewer: SmokeStack\n> Gerrit-Reviewer: Sumit Naiksatam <sumitnaiksatam at gmail.com>\n> Gerrit-Reviewer: dan wendlandt <dan at nicira.com>\n> Gerrit-Reviewer: mark mcclain <mark.mcclain at dreamhost.com>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130319/bc9870f6/attachment.html>\n\n','<E1UI1oD-0001LT-Kx@review.openstack.org>',NULL),('<11ba3e4b.1e822.14338d4f6e2.Coremail.liusheng1175@126.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-28 18:51:57',28800,'2013-12-28 10:51:57',NULL,'[openstack-dev]  [Ceilometer] time consuming of listing resource','Hi all?\nI have reported a bug about time consuming of ?resource-list? in ceilometer CLI?\nhttps://bugs.launchpad.net/ceilometer/+bug/1264434\n\n\nIn order to Identify the causes of this phenomenon, I have pdb the codes in my invironment(configured  mysql as db driver):\nthe most import part of process of listing resource is implemented in following codes:\n\n\ncode of get_resources() in /ceilometer/storage/impl_sqlalchemy.py?\n????\n for meter, first_ts, last_ts in query.all():\n            yield api_models.Resource(\n                resource_id=meter.resource_id,\n                project_id=meter.project_id,\n                first_sample_timestamp=first_ts,\n                last_sample_timestamp=last_ts,\n                source=meter.sources[0].id,\n                user_id=meter.user_id,\n                metadata=meter.resource_metadata,?\n                meter=[\n                    api_models.ResourceMeter(\n                        counter_name=m.counter_name,\n                        counter_type=m.counter_type,\n                        counter_unit=m.counter_unit,\n                    )\n                    for m in meter.resource.meters\n                ],\n            )\nThe method  generate iterator of object of   api_models.Resource for ceilometer API to show.\n1.The operation ?query.all()? will query the DB table ?meter? with the expression generated forward,in my invironment the DB table ?meter? have more than 300000 items, so this operation may consume about 30 seconds;\n2.The operation  \"for m in meter.resource.meters\" will circulate the meters of this resource . a resource of server may have more than 100000 meter iterms in my invironment.  So the time of whole process is too long. I think the meter of Resource object can be reduced and I have tested this modification, it is OK for listing resource,and reduce the most time consumption\n\n\nI have noticed that there are many methods of db operation may time consumption. \n\n\nps: I have configured the ceilometer pulling interval from 600s to 60s in /etc/ceilometer/pipeline.yaml, but the invironment has just run 10 days!\n\n\nI\'m a beginner of ceilometer,and want to fix this bug,but I haven\'t found a suitable way\nmay be someone can help me with this?\n\n\nBest Regards\nliusheng\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131228/0cd1bf3d/attachment.html>\n\n',NULL,NULL),('<11BE13BD-BA77-4A8A-AD7B-847B746094C7@openstack.org>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-08-22 12:37:09',-18000,'2014-08-22 17:37:09',NULL,'[User-committee] User Survey','I have a few thoughts, as well.\n\nAs far as question updates:\n- In the last Board meeting, there was talk about adding an NPS-style satisfaction question to the survey that we could benchmark over time\n- One thing that has been enlightening is to see the number of NFV-related speaking submissions for the Paris Summit. The NFV community is definitely picking up, and I wonder if we should be capturing more or different information in the survey. Specifically in terms of the types of clouds, workloads and types of organizations (carriers/telcos). We could probably pull in some members of the NFV team for their input to make sure we?re not missing anything?without adding too many questions, of course :)\n- I was referencing the workloads data for a project the other day, and I think the options could use some clean up / consolidation. I can take a stab making edits, but we should probably solicit input from the WTE team or other working groups if you agree we should consider refining the responses\n\nAs far as methodology:\n- I agree with expiring data that has not been updated in 12 months, although it will still be helpful to have a historical view / trends. It may be worth sending a separate email to the administrator of those deployments as well.\n- I know that in the previous cycles it?s taken quite a few hours to analyze the data and qualitative responses, and it?s been understandably difficult for user committee volunteers to pull away from their day jobs to do it. I know Ryan Lane invested quite a few hours in the last cycle, but he won?t be involved this time around. Tom has of course been a huge help, but we also have Foundation budget available to bring in another resource with professional survey experience. I think it would be beneficial to have professional and independent help that we could put under NDA (no ties to vendor companies). I?m not thinking an analyst firm in this case, but rather an independent researcher or boutique firm that can provide some extra manpower working with the user committee. What do you all think?\n\nSeparate but related, I?m interested in commissioning a broader marketshare / industry report with an analyst firm like 451 or IDC. I think people often conflate the user survey with a comprehensive list of our users, when it?s really an opt-in chance to provide feedback to our development community and broader ecosystem. I think having a macro / statistically relevant view of OpenStack adoption across the market would complement and provide an interesting companion to the community user survey. \n\nThanks!\nLauren\n\n\nOn Jul 28, 2014, at 2:55 PM, Matt Van Winkle <mvanwink at rackspace.com> wrote:\n\n> Sorry for the delay in commenting.  Playing catch up from being out.\n> \n> From: Tim Bell <Tim.Bell at cern.ch>\n> Date: Tuesday, July 15, 2014 1:31 PM\n> To: \"User-committee at lists.openstack.org\" <User-committee at lists.openstack.org>\n> Subject: [User-committee] User Survey\n> \n>>  \n>> We have run a user survey prior to each of the OpenStack summits for the past two years.\n>>  \n>> My default proposal would be to run another one before Paris to see how the community is evolving.\n>>  \n> \n> I would agree. \n> \n>> In Hong Kong, we had not planned to present but in the end, an impromptu meetup was organised (which led amongst other things to the start of the operations meet up).\n>>  \n>> Given that we?re hoping to organise an operations ?design? style track at Paris, I would propose to include a quick highlight presentation in that session along with a more detailed document for those who wish to drill down further.\n> \n> This seems like a great fit to me.  The only concern I would have is that the user survey captures two voices ? those who interface with OpenStack APIs to deploy applications (end users) and those who deploy and mange OpenStack itself.  Would those in the first group find their way to the session?  It\'s probably more of a logistical questions ? making sure that the session time in the new \"Ops\" pieces are on a day when the main summit is underway as well.  (I\'m trying to recall the dates proposed in a meeting in ATL, and I believe there was some overlap between the time for the Ops meet ups and the main conference)\n> \n>>  \n>> The other question is expiry of clouds which have not been updated. I think that if the data on a deployment has not been updated within 12 months, it should not be considered within the statistics.\n>>  \n> \n> Seems reasonable to me\n> \n>> Given the timing of the summit at the start of November, a timing such as below would seem reasonable:\n>>  \n>> -        1st September ? Questions finalised\n>> -        15th September ? User Survey pages updated and published on openstack.org. Requests to update sent out.\n>> -        7th October ? Survey closed\n>> -        4th November ? Results published\n>>  \n>> Any thoughts ?\n>>  \n> \n> Sounds good ? how can I help?\n> \n>> Tim\n>>  \n>>  \n> \n> Thanks!\n> Matt\n> _______________________________________________\n> User-committee mailing list\n> User-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n\n\n','<CFFC139C.C7524%mvanwink@rackspace.com>',NULL),('<11C65C9B-4562-4E5A-830D-0EEDC9016C21@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-29 20:11:23',-14400,'2013-08-30 00:11:23',NULL,'[openstack-dev] [Neutron] Resource URL support for more than\n	two levels','Stay tuned.  There are folks working on a proposed set of API framework changes.  This will be something that we\'ll discuss as part of deciding the features in the Icehouse release.\n\nmark\n\nOn Aug 29, 2013, at 10:08 AM, Justin Hammond <justin.hammond at rackspace.com> wrote:\n\n> I find that kind of flexibility quite valuable for plugin developers. +1 to this. I\'d like to be involved if possible with helping you with it.\n> \n> From: balaji patnala <patnala003 at gmail.com>\n> Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>\n> Date: Thu, 29 Aug 2013 11:02:33 +0530\n> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>\n> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two levels\n> \n> Hi, \n> \n> When compared to Nova URL implementations, It is observed that the Neutron URL support cannot be used for more than TWO levels.\n> \n> Applications which want to add as PLUG-IN may be restricted with this.\n> \n> We want to add support for changes required for supporting more than TWO Levels of URL by adding the support changes required in Core Neutron Files.\n> \n> Any comments/interest in this.?\n> \n> Regards,\n> Balaji.P\n> \n> \n> \n> \n> \n> On Tue, Aug 27, 2013 at 5:04 PM, B Veera-B37207 <B37207 at freescale.com> wrote:\n> Hi,\n> \n>  \n> The current infrastructure provided in Quantum [Grizzly], while building Quantum API resource URL using the base function ?base.create_resource()? and RESOURCE_ATTRIBUTE_MAP/SUB_RESOURCE_ATTRIBUTE_MAP, supports only two level URI.\n> \n> Example:\n> \n> GET  /lb/pools/<pool_id>/members/<member_id>\n> \n>  \n> \n> Some applications may need more than two levels of URL support. Example: GET  /lb/pools/<pool_id>/members/<member_id>/xyz/<xyz_id>\n> \n>  \n> \n> If anybody is interested in this, we want to contribute for this as BP and make it upstream.\n> \n>  \n> \n> Regards,\n> \n> Veera.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130829/0b224cfd/attachment.html>\n\n','<CE44BFE5.D31A%justin.hammond@rackspace.com>',NULL),('<11C6E39D-8AF2-4783-8450-15961D3355CD@syrinx.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 06:39:26',-14400,'2013-08-12 10:39:26',NULL,'[Openstack] Baremetal Provisioning for Openstack','On Aug 12, 2013, at 6:20 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n> \n> Thanks! I know how to use google. haha thats a funny site.\n> The only reason I ask here is because I am having trouble finding a good resource or documentation from google results.\n\nYour question didn\'t specify what you had searched for previously or why what you found wasn\'t satisfactory. The first link from that Google query has a section which specifies the differences in starting a baremetal cloud with detailed instructions (http://bit.ly/142rZOY). We need to know what information is missing from that documentation which stops you from using the baremetal driver.\n\n','<1376302852.90072.YahooMailNeo@web163002.mail.bf1.yahoo.com>',NULL),('<11D5ED2E-A3E7-426F-9F87-8C2757506932@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-27 07:56:26',0,'2014-12-27 07:56:26',NULL,'[openstack-dev] [Solum] Addition to solum core','Solum cores,\n\nI propose the following addition to the solum-core group[1]:\n\n+ Ed Cranford (ed--cranford)\n\nPlease reply to this email to indicate your votes.\n\nThanks,\n\nAdrian Otto\n\n[1] https://review.openstack.org/#/admin/groups/229,members Current Members\n\n\n',NULL,NULL),('<11D5F26E-06A3-4F12-8B08-E0F486059C5A@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 11:45:05',-18000,'2014-12-02 16:45:05',NULL,'[openstack-dev] oslotest 1.3.0 released','The Oslo team is pleased to announce release 1.3.0 of oslotest.\n\nThis release is primarily to update the dependencies for the library.\n\nFor more details, please see the git log history below and\n http://launchpad.net/oslotest/+milestone/1.3.0\n\nPlease report issues through launchpad:\n http://bugs.launchpad.net/oslotest\n\n----------------------------------------\n\nChanges in openstack/oslotest  1.2.0..1.3.0\n\n2568413 Updated from global requirements\n30925bd Updated from global requirements\n47afc62 Updated from global requirements\n230f8e3 Add pbr to installation requirements\nfa1f130 Clean up the docs for oslo_debug_helper\n\n  diffstat (except docs and test files):\n\n requirements.txt        |  3 ++-\n 2 files changed, 19 insertions(+), 6 deletions(-)\n\n  Requirements updates:\n\n diff --git a/requirements.txt b/requirements.txt\n index 01d1947..125b54e 100644\n --- a/requirements.txt\n +++ b/requirements.txt\n @@ -4,0 +5 @@\n +pbr>=0.6,!=0.7,<1.0\n @@ -11 +12 @@ testscenarios>=0.4\n -testtools>=0.9.34\n +testtools>=0.9.36,!=1.2.0\n\n\n',NULL,NULL),('<11E2576A-1F00-4506-AB39-5CA4D51C4C5E@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-25 15:15:55',7200,'2013-07-25 13:15:55',NULL,'[Openstack-operators] Shared storage HA question','Good to know, that what I thought as well\nthanks for the insight.\nthanks Jabob as well, curious too see what your tests will bring up :)\n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 25 juil. 2013 ? 12:35, Sylvain Bauza <sylvain.bauza at bull.net> a ?crit :\n\n> Le 25/07/2013 11:34, Razique Mahroua a ?crit :\n>> \n>> - How come I never had such issues (to validate) with MooseFS while it\'s the mfsmount is FUSE-based?\n> \n> I\'m not saying FUSE is killing perfs :-) My point was more likely : be careful, if you mix up GlusterFS + Windows (caching system on C:) + FUSE, then you *could* have something like race condition which could affect perfs.\n> \n> I haven\'t tested out MFS, happy if this is not reproducing, then :-)\n> \n>> - Does that mean the issue is not si much about Gluster, rather all FUSE-based FS?\n>> \n> \n> Indeed. As said though, CephFS is also not perfect. If people want to choose Ceph, then it\'s better to boot from volume with Cinder-based RBD (RADOS Block Device) driver.\n> \n> -Sylvain\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130725/d19b368b/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130725/d19b368b/attachment.jpg>\n\n','<51F0FF7F.3020201@bull.net>',NULL),('<11EF0212-F8D5-4EE2-A90E-430880EFF0B2@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-24 20:47:23',7200,'2013-07-24 18:47:23',NULL,'[Openstack-operators] Shared storage HA question','Not done yet, I\'ll still do some testing on it, but I don\'t expect much given the current topology\n\n\n\nMooseFS lacks a decentralized meta-data server, but you can build an HA with an active/ passive master/metalogger, I\'ve been able to run such setup for almost 2 years now, and not any issue so far\n\nLe 24 juil. 2013 ? 20:37, Jacob Godin <jacobgodin at gmail.com> a ?crit :\n\n> Oh really, you\'ve done away with Gluster all together? The fast backbone is definitely needed, but I would think that was the case with any distributed filesystem.\n> \n> MooseFS looks promising, but apparently it has a few reliability problems.\n> \n> \n> On Wed, Jul 24, 2013 at 3:31 PM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n> :-)\n> Actually I had to remove all my instances running on it (especially the windows ones), yah unfortunately my network backbone wasn\'t fast enough to support the load induced by GFS - especially the numerous operations performed by the self-healing agents :(\n> \n> I\'m currently considering MooseFS, it has the advantage to have a pretty long list of companies using it in production\n> \n> take care\n> \n> \n> Le 24 juil. 2013 ? 16:40, Jacob Godin <jacobgodin at gmail.com> a ?crit :\n> \n>> A few things I found were key for I/O performance:\n>> Make sure your network can sustain the traffic. We are using a 10G backbone with 2 bonded interfaces per node.\n>> Use high speed drives. SATA will not cut it.\n>> Look into tuning settings. Razique, thanks for sending these along to me a little while back. A couple that I found were useful:\n>> KVM cache=writeback (a little risky, but WAY faster)\n>> Gluster write-behind-window-size (set to 4MB in our setup)\n>> Gluster cache-size (ideal values in our setup were 96MB-128MB)\n>> Hope that helps!\n>> \n>> \n>> \n>> On Wed, Jul 24, 2013 at 11:32 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>> I had much performance issues myself with Windows instances, and I/O demanding instances. Make sure it fits your env. first before deploying it in production\n>> \n>> Regards,\n>> Razique\n>> \n>> Razique Mahroua - Nuage & Co\n>> razique.mahroua at gmail.com\n>> Tel : +33 9 72 37 94 15\n>> \n>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>> \n>> Le 24 juil. 2013 ? 16:25, Jacob Godin <jacobgodin at gmail.com> a ?crit :\n>> \n>>> Hi Denis,\n>>> \n>>> I would take a look into GlusterFS with a distributed, replicated volume. We have been using it for several months now, and it has been stable. Nova will need to have the volume mounted to its instances directory (default /var/lib/nova/instances), and Cinder has direct support for Gluster as of Grizzly I believe.\n>>> \n>>> \n>>> \n>>> On Wed, Jul 24, 2013 at 11:11 AM, Denis Loshakov <dloshakov at gmail.com> wrote:\n>>> Hi all,\n>>> \n>>> I have issue with creating shared storage for Openstack. Main idea is to create 100% redundant shared storage from two servers (kind of network RAID from two servers).\n>>> I have two identical servers with many disks inside. What solution can any one provide for such schema? I need shared storage for running VMs (so live migration can work) and also for cinder-volumes.\n>>> \n>>> One solution is to install Linux on both servers and use DRBD + OCFS2, any comments on this?\n>>> Also I heard about Quadstor software and it can create network RAID and present it via iSCSI.\n>>> \n>>> Thanks.\n>>> \n>>> P.S. Glance uses swift and is setuped on another servers\n>>> \n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>> \n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n>> \n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130724/caf65cab/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 61428_254798781315632_35282649_n.jpg\nType: image/jpg\nSize: 24277 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130724/caf65cab/attachment-0001.jpg>\n\n','<CA+WiSK6V_RJ29yYRbe1LqdziVpyjpNkrxa26_chTJcr6mYnjqQ@mail.gmail.com>',NULL),('<1200097925.16.1378015619350.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-01 06:06:59',0,'2013-09-01 06:06:59',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #12','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/12/>\n\n------------------------------------------\n[...truncated 17305 lines...]\n2013-09-01 06:06:26 # This section contains the configuration options used when executing tests\n2013-09-01 06:06:26 # against the OpenStack Block Storage API service\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-01 06:06:26 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-01 06:06:26 # probably want to leave this value as \"volume\"\n2013-09-01 06:06:26 catalog_type = volume\n2013-09-01 06:06:26 # Number of seconds to wait while looping to check the status of a\n2013-09-01 06:06:26 # volume that is being made available\n2013-09-01 06:06:26 build_interval = 1\n2013-09-01 06:06:26 # Number of seconds to time out on waiting for a volume\n2013-09-01 06:06:26 # to be available or reach an expected status\n2013-09-01 06:06:26 build_timeout = 400\n2013-09-01 06:06:26 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-01 06:06:26 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-01 06:06:26 # have to be different)\n2013-09-01 06:06:26 multi_backend_enabled = false\n2013-09-01 06:06:26 backend1_name = BACKEND_1\n2013-09-01 06:06:26 backend2_name = BACKEND_2\n2013-09-01 06:06:26 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-01 06:06:26 # You should update to reflect those exported by configured backend driver.\n2013-09-01 06:06:26 storage_protocol = iSCSI\n2013-09-01 06:06:26 vendor_name = Open Source\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [object-storage]\n2013-09-01 06:06:26 # This section contains configuration options used when executing tests\n2013-09-01 06:06:26 # against the OpenStack Object Storage API.\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # You can configure the credentials in the compute section\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-01 06:06:26 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-01 06:06:26 # this value as \"object-store\"\n2013-09-01 06:06:26 catalog_type = object-store\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Number of seconds to time on waiting for a container to container\n2013-09-01 06:06:26 # synchronization complete\n2013-09-01 06:06:26 container_sync_timeout = 120\n2013-09-01 06:06:26 # Number of seconds to wait while looping to check the status of a\n2013-09-01 06:06:26 # container to container synchronization\n2013-09-01 06:06:26 container_sync_interval = 5\n2013-09-01 06:06:26 # Set to True if the Account Quota middleware is enabled\n2013-09-01 06:06:26 accounts_quotas_available = True\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Set operator role for tests that require creating a container\n2013-09-01 06:06:26 operator_role = Member\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [boto]\n2013-09-01 06:06:26 ssh_user = cirros\n2013-09-01 06:06:26 # This section contains configuration options used when executing tests\n2013-09-01 06:06:26 # with boto.\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # EC2 URL\n2013-09-01 06:06:26 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-01 06:06:26 # S3 URL\n2013-09-01 06:06:26 s3_url = http://127.0.0.1:3333\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-01 06:06:26 aws_access =\n2013-09-01 06:06:26 aws_secret =\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Image materials for S3 upload\n2013-09-01 06:06:26 # ALL content of the specified directory will be uploaded to S3\n2013-09-01 06:06:26 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-01 06:06:26 # Subdirectories not allowed!\n2013-09-01 06:06:26 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-01 06:06:26 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-01 06:06:26 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-01 06:06:26 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Instance type\n2013-09-01 06:06:26 instance_type = m1.nano\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # TCP/IP connection timeout\n2013-09-01 06:06:26 http_socket_timeout = 30\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Number of retries actions on connection or 5xx error\n2013-09-01 06:06:26 num_retries = 1\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Status change wait timout\n2013-09-01 06:06:26 build_timeout = 400\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Status change wait interval\n2013-09-01 06:06:26 build_interval = 1\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [orchestration]\n2013-09-01 06:06:26 # Status change wait interval\n2013-09-01 06:06:26 build_interval = 1\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Status change wait timout. This may vary across environments as some some\n2013-09-01 06:06:26 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-01 06:06:26 build_timeout = 300\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Instance type for tests. Needs to be big enough for a\n2013-09-01 06:06:26 # full OS plus the test workload\n2013-09-01 06:06:26 instance_type = m1.micro\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-01 06:06:26 # If not specified, tests that spawn instances will not run\n2013-09-01 06:06:26 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-01 06:06:26 # any key, which will generate a keypair for each test class\n2013-09-01 06:06:26 #keypair_name = heat_key\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [dashboard]\n2013-09-01 06:06:26 # URL where to find the dashboard home page\n2013-09-01 06:06:26 dashboard_url = http://127.0.0.1/\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # URL where to submit the login form\n2013-09-01 06:06:26 login_url = http://127.0.0.1/auth/login/\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [scenario]\n2013-09-01 06:06:26 # Directory containing image files\n2013-09-01 06:06:26 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # AMI image file name\n2013-09-01 06:06:26 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # ARI image file name\n2013-09-01 06:06:26 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # AKI image file name\n2013-09-01 06:06:26 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # ssh username for the image file\n2013-09-01 06:06:26 ssh_user = cirros\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 # specifies how many resources to request at once. Used for large operations\n2013-09-01 06:06:26 # testing.\"\n2013-09-01 06:06:26 large_ops_number = 0\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [cli]\n2013-09-01 06:06:26 # Enable cli tests\n2013-09-01 06:06:26 enabled = True\n2013-09-01 06:06:26 # directory where python client binaries are located\n2013-09-01 06:06:26 cli_dir = /usr/local/bin\n2013-09-01 06:06:26 # Number of seconds to wait on a CLI timeout\n2013-09-01 06:06:26 timeout = 15\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [service_available]\n2013-09-01 06:06:26 # Whether or not cinder is expected to be available\n2013-09-01 06:06:26 cinder = True\n2013-09-01 06:06:26 # Whether or not neutron is expected to be available\n2013-09-01 06:06:26 neutron = False\n2013-09-01 06:06:26 # Whether or not glance is expected to be available\n2013-09-01 06:06:26 glance = True\n2013-09-01 06:06:26 # Whether or not swift is expected to be available\n2013-09-01 06:06:26 swift = True\n2013-09-01 06:06:26 # Whether or not nova is expected to be available\n2013-09-01 06:06:26 nova = True\n2013-09-01 06:06:26 # Whether or not Heat is expected to be available\n2013-09-01 06:06:26 heat = True\n2013-09-01 06:06:26 # Whether or not horizon is expected to be available\n2013-09-01 06:06:26 horizon = True\n2013-09-01 06:06:26 \n2013-09-01 06:06:26 [stress]\n2013-09-01 06:06:26 # Maximum number of instances to create during test\n2013-09-01 06:06:26 max_instances = 32\n2013-09-01 06:06:26 # Time (in seconds) between log file error checks\n2013-09-01 06:06:26 log_check_interval = 60\n2013-09-01 06:06:26 # The default number of threads created while stress test\n2013-09-01 06:06:26 default_thread_number_per_action=4\n2013-09-01 06:06:26 ++ IFS=\' 	\n2013-09-01 06:06:26 \'\n2013-09-01 06:06:26 ++ set +o errexit\n2013-09-01 06:06:26 ++ init_tempest\n2013-09-01 06:06:26 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-01 06:06:26 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-01 06:06:26 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-01 06:06:26 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-01 06:06:26 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1658.gedaa084.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-197897-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-197897.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-197897/12/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1201668397.102.1384581984802.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-16 06:06:24',0,'2013-11-16 06:06:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #62','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/62/>\n\n------------------------------------------\n[...truncated 15248 lines...]\n2013-11-16 06:05:53 db_uri = mysql://root:secret at localhost/nova\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Path to a private key file for SSH access to remote hosts\n2013-11-16 06:05:53 path_to_private_key = /opt/stack/new/tempest/id_rsa\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [compute-admin]\n2013-11-16 06:05:53 # This should be the username of a user WITH administrative privileges\n2013-11-16 06:05:53 # If not defined the admin user from the identity section will be used\n2013-11-16 06:05:53 username =\n2013-11-16 06:05:53 # The above administrative user\'s password\n2013-11-16 06:05:53 password =secret\n2013-11-16 06:05:53 # The above administrative user\'s tenant name\n2013-11-16 06:05:53 tenant_name =\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [image]\n2013-11-16 06:05:53 # This section contains configuration options used when executing tests\n2013-11-16 06:05:53 # against the OpenStack Images API\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The type of endpoint for an Image API service. Unless you have a\n2013-11-16 06:05:53 # custom Keystone service catalog implementation, you probably want to leave\n2013-11-16 06:05:53 # this value as \"image\"\n2013-11-16 06:05:53 catalog_type = image\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The version of the OpenStack Images API to use\n2013-11-16 06:05:53 api_version = 1\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [network]\n2013-11-16 06:05:53 # This section contains configuration options used when executing tests\n2013-11-16 06:05:53 # against the OpenStack Network API.\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Version of the Quantum API\n2013-11-16 06:05:53 api_version = 2.0\n2013-11-16 06:05:53 # Catalog type of the Quantum Service\n2013-11-16 06:05:53 catalog_type = network\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # A large private cidr block from which to allocate smaller blocks for\n2013-11-16 06:05:53 # tenant networks.\n2013-11-16 06:05:53 tenant_network_cidr = 10.100.0.0/16\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The mask bits used to partition the tenant block.\n2013-11-16 06:05:53 tenant_network_mask_bits = 29\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # If tenant networks are reachable, connectivity checks will be\n2013-11-16 06:05:53 # performed directly against addresses on those networks.\n2013-11-16 06:05:53 tenant_networks_reachable = false\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Id of the public network that provides external connectivity.\n2013-11-16 06:05:53 public_network_id = ffaef55a-9f1d-41b5-918c-454e89f40645\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Id of a shared public router that provides external connectivity.\n2013-11-16 06:05:53 # A shared public router would commonly be used where IP namespaces\n2013-11-16 06:05:53 # were disabled.  If namespaces are enabled, it would be preferable\n2013-11-16 06:05:53 # for each tenant to have their own router.\n2013-11-16 06:05:53 public_router_id = \n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Whether or not quantum is expected to be available\n2013-11-16 06:05:53 quantum_available = True\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [volume]\n2013-11-16 06:05:53 # This section contains the configuration options used when executing tests\n2013-11-16 06:05:53 # against the OpenStack Block Storage API service\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The type of endpoint for a Cinder or Block Storage API service.\n2013-11-16 06:05:53 # Unless you have a custom Keystone service catalog implementation, you\n2013-11-16 06:05:53 # probably want to leave this value as \"volume\"\n2013-11-16 06:05:53 catalog_type = volume\n2013-11-16 06:05:53 # Number of seconds to wait while looping to check the status of a\n2013-11-16 06:05:53 # volume that is being made available\n2013-11-16 06:05:53 build_interval = 3\n2013-11-16 06:05:53 # Number of seconds to time out on waiting for a volume\n2013-11-16 06:05:53 # to be available or reach an expected status\n2013-11-16 06:05:53 build_timeout = 400\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [object-storage]\n2013-11-16 06:05:53 # This section contains configuration options used when executing tests\n2013-11-16 06:05:53 # against the OpenStack Object Storage API.\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # You can configure the credentials in the compute section\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-11-16 06:05:53 # custom Keystone service catalog implementation, you probably want to leave\n2013-11-16 06:05:53 # this value as \"object-store\"\n2013-11-16 06:05:53 catalog_type = object-store\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Number of seconds to time on waiting for a container to container\n2013-11-16 06:05:53 # synchronization complete\n2013-11-16 06:05:53 container_sync_timeout = 120\n2013-11-16 06:05:53 # Number of seconds to wait while looping to check the status of a\n2013-11-16 06:05:53 # container to container synchronization\n2013-11-16 06:05:53 container_sync_interval = 5\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 [boto]\n2013-11-16 06:05:53 ssh_user = cirros\n2013-11-16 06:05:53 # This section contains configuration options used when executing tests\n2013-11-16 06:05:53 # with boto.\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # EC2 URL\n2013-11-16 06:05:53 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-11-16 06:05:53 # S3 URL\n2013-11-16 06:05:53 s3_url = http://127.0.0.1:3333\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-11-16 06:05:53 aws_access =\n2013-11-16 06:05:53 aws_secret =\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #Image materials for S3 upload\n\n\n\nHorizon is now available at http://127.0.0.1/\nKeystone is serving at http://127.0.0.1:5000/v2.0/\nExamples on using novaclient command line is in exercise.sh\nThe default users are: admin and demo\nThe password: secret\nThis is your host ip: 10.3.74.6\nRemoving sudo privileges for devstack user\n2013-11-16 06:05:53 # ALL content of the specified directory will be uploaded to S3\n2013-11-16 06:05:53 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # The manifest.xml files, must be in the s3_materials_path directory\n2013-11-16 06:05:53 # Subdirectories not allowed!\n2013-11-16 06:05:53 # The filenames will be used as a Keys in the S3 Buckets\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-11-16 06:05:53 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #AMI Machine Image manifest. Must be in the above s3_materials_path\nRunning tempest smoke tests\n2013-11-16 06:05:53 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-11-16 06:05:53 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #Instance type\n2013-11-16 06:05:53 instance_type = m1.nano\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #TCP/IP connection timeout\n2013-11-16 06:05:53 http_socket_timeout = 30\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 #Number of retries actions on connection or 5xx error\n2013-11-16 06:05:53 num_retries = 1\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Status change wait timout\n2013-11-16 06:05:53 build_timeout = 400\n2013-11-16 06:05:53 \n2013-11-16 06:05:53 # Status change wait interval\n2013-11-16 06:05:53 build_interval = 3\n2013-11-16 06:05:53 ++ IFS=\' 	\n2013-11-16 06:05:53 \'\n2013-11-16 06:05:53 ++ set +o errexit\n2013-11-16 06:05:53 ++ init_tempest\n2013-11-16 06:05:53 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-11-16 06:05:53 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-11-16 06:05:53 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-11-16 06:05:53 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-11-16 06:05:53 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-11-16 06:05:53 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-11-16 06:05:53 ++ echo \'Prepare aki/ari/ami Images\'\n2013-11-16 06:05:53 Prepare aki/ari/ami Images\n2013-11-16 06:05:53 ++ cat\n2013-11-16 06:05:53 ++ source /opt/stack/new/devstack/accrc/demo/demo\n2013-11-16 06:05:53 +++ export EC2_ACCESS_KEY=333a9cec5c584766b0fdfa2598c78d7c\n2013-11-16 06:05:53 +++ EC2_ACCESS_KEY=333a9cec5c584766b0fdfa2598c78d7c\n2013-11-16 06:05:53 +++ export EC2_SECRET_KEY=16c9c5a4db7e4cb39613b2427491058d\n2013-11-16 06:05:53 +++ EC2_SECRET_KEY=16c9c5a4db7e4cb39613b2427491058d\n2013-11-16 06:05:53 +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-11-16 06:05:53 +++ EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-11-16 06:05:53 +++ export S3_URL=http://127.0.0.1:3333\n2013-11-16 06:05:53 +++ S3_URL=http://127.0.0.1:3333\n2013-11-16 06:05:53 +++ export OS_USERNAME=demo\n2013-11-16 06:05:53 +++ OS_USERNAME=demo\n2013-11-16 06:05:53 +++ export OS_TENANT_NAME=demo\n2013-11-16 06:05:53 +++ OS_TENANT_NAME=demo\n2013-11-16 06:05:53 +++ export OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-11-16 06:05:53 +++ OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-11-16 06:05:53 +++ export EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-11-16 06:05:53 +++ EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-11-16 06:05:53 +++ export EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-11-16 06:05:53 +++ EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-11-16 06:05:53 +++ export EC2_USER_ID=42\n2013-11-16 06:05:53 +++ EC2_USER_ID=42\n2013-11-16 06:05:53 +++ export EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-16 06:05:53 +++ EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-16 06:05:53 +++ export NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-16 06:05:53 +++ NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-16 06:05:53 +++ export OS_PASSWORD=secret\n2013-11-16 06:05:53 +++ OS_PASSWORD=secret\nERROR: unknown environment \'smoke-serial\'\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-662830-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-662830.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-q-l3.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-662830/62/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1201713026.33.1381127343926.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-07 06:29:02',0,'2013-10-07 06:29:02',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #31','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/31/>\n\n------------------------------------------\n[...truncated 19247 lines...]\n    __import__(name)\n  File \"tempest/api/compute/images/test_images_oneserver.py\", line 30, in <module>\n    class ImagesOneServerTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/images/test_images_oneserver.py\", line 69, in ImagesOneServerTestJSON\n    @attr(type=[\'negative\', \'gate\'])\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1006725 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.object_storage.test_container_sync\ntags: worker-1\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.object_storage.test_container_sync\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/object_storage/test_container_sync.py\", line 26, in <module>\n    class ContainerSyncTest(base.BaseObjectTest):\n  File \"tempest/api/object_storage/test_container_sync.py\", line 55, in ContainerSyncTest\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1093743 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.object_storage.test_object_expiry\ntags: worker-1\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.object_storage.test_object_expiry\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/object_storage/test_object_expiry.py\", line 28, in <module>\n    class ObjectExpiryTest(base.BaseObjectTest):\n  File \"tempest/api/object_storage/test_object_expiry.py\", line 46, in ObjectExpiryTest\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1069849 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.servers.test_list_server_filters\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.servers.test_list_server_filters\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/servers/test_list_server_filters.py\", line 27, in <module>\n    class ListServerFiltersTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/servers/test_list_server_filters.py\", line 208, in ListServerFiltersTestJSON\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1170718 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.servers.test_server_actions\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.servers.test_server_actions\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/servers/test_server_actions.py\", line 33, in <module>\n    class ServerActionsTestJSON(base.BaseComputeTest):\n  File \"tempest/api/compute/servers/test_server_actions.py\", line 91, in ServerActionsTestJSON\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1014647 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_instance_run\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_instance_run\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 35, in <module>\n    class InstanceRunTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 210, in InstanceRunTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1098891 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_keys\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_keys\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_keys.py\", line 30, in <module>\n    class EC2KeysTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_keys.py\", line 50, in EC2KeysTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1072318 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_ec2_network\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_ec2_network\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_ec2_network.py\", line 24, in <module>\n    class EC2NetworkTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_ec2_network.py\", line 34, in EC2NetworkTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1080406 is resolved.\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.thirdparty.boto.test_s3_buckets\ntags: worker-3\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.thirdparty.boto.test_s3_buckets\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/thirdparty/boto/test_s3_buckets.py\", line 25, in <module>\n    class S3BucketsTest(BotoTestCase):\n  File \"tempest/thirdparty/boto/test_s3_buckets.py\", line 34, in S3BucketsTest\n    @attr(type=\'smoke\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1076965 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_flavors\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_flavors\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_flavors.py\", line 27, in <module>\n    class FlavorsAdminTestJSON(base.BaseComputeAdminTest):\n  File \"tempest/api/compute/admin/test_flavors.py\", line 198, in FlavorsAdminTestJSON\n    @attr(type=\'gate\')\n  File \"tempest/test.py\", line 116, in decorator\n    raise testtools.TestCase.skipException(msg)\nSkipTest: Skipped until Bug: 1209101 is resolved.\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2497 tests in 1155.035s\nFAILED (id=0, failures=13, skips=46)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-557266-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-557266.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-557266/31/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1051345439.31.1381040926581.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<120305877.15630640.1405953934628.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 10:45:34',-14400,'2014-07-21 14:45:34',NULL,'[openstack-dev] [nova][neutron] Networks without subnets','----- Original Message -----\n> From: \"Brent Eagles\" <beagles at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> \n> Hi,\n> \n> A bug titled \"Creating quantum L2 networks (without subnets) doesn\'t\n> work as expected\" (https://bugs.launchpad.net/nova/+bug/1039665) was\n> reported quite some time ago. Beyond the discussion in the bug report,\n> there have been related bugs reported a few times.\n> \n> * https://bugs.launchpad.net/nova/+bug/1304409\n> * https://bugs.launchpad.net/nova/+bug/1252410\n> * https://bugs.launchpad.net/nova/+bug/1237711\n> * https://bugs.launchpad.net/nova/+bug/1311731\n> * https://bugs.launchpad.net/nova/+bug/1043827\n> \n> BZs on this subject seem to have a hard time surviving. The get marked\n> as incomplete or invalid, or in the related issues, the problem NOT\n> related to the feature is addressed and the bug closed. We seem to dance\n> around actually getting around to implementing this. The multiple\n> reports show there *is* interest in this functionality but at the moment\n> we are without an actual implementation.\n> \n> At the moment there are multiple related blueprints:\n\nFollowing up with post SAD status:\n\n> * https://review.openstack.org/#/c/99873/ ML2 OVS: portsecurity\n>   extension support\n\nRemains unapproved, no negative feedback on current revision.\n\n> * https://review.openstack.org/#/c/106222/ Add Port Security\n>   Implementation in ML2 Plugin\n\nHas a -2 to highlight the significant overlap with 99873 above.\n\n> * https://review.openstack.org/#/c/97715 NFV unaddressed interfaces\n\nRemains unapproved, no negative feedback on current revision. \n\nAlthough there were some discussions about these last week I am not sure we reached consensus on whether either of these (or even both of them) are the correct path forward - particularly to address the problem Brent raised w.r.t. to creation of networks without subnets - I believe this currently still works with nova-network?\n\nRegardless, I am wondering if either of the spec authors intend to propose these for a spec freeze exception?\n\nThanks,\n\nSteve\n\n\n','<20140711214140.GC15476@b3ntpin.localdomain>',NULL),('<1203103139.51392.1349984759832.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2012-10-11 12:45:59',-25200,'2012-10-11 19:45:59',NULL,'[openstack-hpc] HPC session during upcoming Design Summit','\n?Hi all,\n\n?We will have a design summit session during next week\'s OpenStack Summit in San Diego.\nIt\'ll at 11:00 am Tuesday, October 16.\nIts title is \"Scheduler for HPC with OpenStack\". \nWe have asked to change the title to \"HPC for OpenStack\".\n\n?We will cover wide range of HPC for OpenStack including\n?\n* HPC extension current state \n* Accelerator support \n* Baremetal \n* Networking \n?? ? * IB\n* HPFS (e.g. Lustre) \n* Scheduler extensions \n* Community Requests/Open Discussion \n\n?Please suggest other interesting topics and share your thoughts in the etherpad. \n(http://etherpad.openstack.org/GrizzlyHPC)\n\n?Hope to see you there.\n\n?Thanks,\n?David\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n','<2143526682.51380.1349984397523.JavaMail.root@zm.isi.edu>',NULL),('<1203239152.34.1369462916579.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-25 06:21:56',0,'2013-05-25 06:21:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #236','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/236/>\n\n------------------------------------------\n[...truncated 12586 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for f18c4015a9ca4167aa52d3f733f10c8a \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:55479\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:55479/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (4256) wsgi starting up on http://127.0.0.1:55479/\n\nnova.osapi_compute.wsgi.server: INFO: (4256) accepted (\'127.0.0.1\', 36540)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/May/2013 06:16:42] \"GET /v2 HTTP/1.1\" 204 216 0.001040\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-8333b664-198f-438a-a2b1-a0d358d04bc4</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (4256) accepted (\'127.0.0.1\', 36541)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa960590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa960590>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:55479/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-25 06:16:42 4256 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:55479/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/May/2013 06:16:42] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.250933\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 986300541afd437390e0979524935944 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:59751\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:59751/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (4256) wsgi starting up on http://127.0.0.1:59751/\n\nnova.osapi_compute.wsgi.server: INFO: (4256) accepted (\'127.0.0.1\', 41509)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/May/2013 06:16:43] \"GET /v2 HTTP/1.1\" 204 216 0.001082\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-57fa2249-8c41-483c-81ea-0b49916b10ae</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (4256) accepted (\'127.0.0.1\', 41510)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa9724d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa9724d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:59751/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     name)\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-25 06:16:43 4256 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:59751/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/May/2013 06:16:43] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.302583\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.2\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.LCFg0ARjxM\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/236\n[SCP] Copying console log.\n\n\n','<733402451.32.1369376541759.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1203424309.15.1387349334007.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-18 06:48:53',0,'2013-12-18 06:48:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-python26-havana #9','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/9/changes>\n\nChanges:\n\n[review] Fix unable to add allow all IPv4/6 security group rule\n\n[review] Fix argument mismatch failure for neutron-check-nvp-config\n\n[apevec] Bump stable/havana next version to 2013.2.2\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-11 in workspace <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/>\nCheckout:periodic-neutron-python26-havana / <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/> - hudson.remoting.Channel at 57e4122d:centos6-11\nUsing strategy: Default\nLast Built Revision: Revision c78394474be796bbf2633d0c5c8704ddffbeb487 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/neutron\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://git.openstack.org/openstack/neutron\nCommencing build of Revision 140f3cb97a2fe6a855f70dd7b54b7c28a4746551 (origin/stable/havana)\nChecking out Revision 140f3cb97a2fe6a855f70dd7b54b7c28a4746551 (origin/stable/havana)\n[periodic-neutron-python26-havana] $ /bin/bash -xe /tmp/hudson5238321656607514312.sh\n+ /usr/local/jenkins/slave_scripts/run-unittests.sh 26 openstack neutron\n+ version=26\n+ org=openstack\n+ project=neutron\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_version_org_project 26 openstack neutron /usr/local/jenkins/slave_scripts/run-unittests.sh\n+ version=26\n+ org=openstack\n+ project=neutron\n+ filename=/usr/local/jenkins/slave_scripts/run-unittests.sh\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z neutron ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.JKuzUrc1Pm\n+ TMPDIR=/tmp/tmp.JKuzUrc1Pm\n+ trap \'rm -rf /tmp/tmp.JKuzUrc1Pm\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack neutron\n++ org=openstack\n++ project=neutron\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack neutron /usr/local/jenkins/slave_scripts/run-unittests.sh\n++ org=openstack\n++ project=neutron\n++ filename=/usr/local/jenkins/slave_scripts/run-unittests.sh\n++ [[ -z openstack ]]\n++ [[ -z neutron ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/neutron /opt/requirements/projects.txt\nopenstack/neutron\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ tox -epy26\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/setup.py>\npy26 create: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/test-requirements.txt,> setuptools_git>=0.4\npy26 inst: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/dist/neutron-jenkins.periodic.neutron.python26.havana.9.zip>\npy26 runtests: commands[0] | python tools/patch_tox_venv.py\npy26 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.linuxbridge.db.l2network_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'Credential\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.network_models_v2.Credential\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.linuxbridge.db.l2network_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.linuxbridge.db.l2network_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.linuxbridge.db.l2network_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.linuxbridge.db.l2network_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'Credential\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.network_models_v2.Credential\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'Credential\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.network_models_v2.Credential\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'Credential\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.network_models_v2.Credential\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'Credential\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.network_models_v2.Credential\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NetworkBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.NetworkBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nERROR:neutron.plugins.nicira.vshield.edge_appliance_driver:VCNS: Unable to retrieve edge edge-1 status. Retry 2.\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/plugins/nicira/vshield/edge_appliance_driver.py\",> line 234, in _status_edge\n    response = self.vcns.get_edge_deploy_status(edge_id)[1]\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/mock.py\",> line 955, in __call__\n    return _mock_self._mock_call(*args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/mock.py\",> line 1018, in _mock_call\n    ret_val = effect(*args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/unit/nicira/vshield/fake_vcns.py\",> line 115, in get_edge_deploy_status\n    raise Exception(_(\"Edge %s does not exist\") % edge_id)\nException: Edge edge-1 does not exist\nBuild timed out (after 40 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.JKuzUrc1Pm\n/usr/local/jenkins/slave_scripts/run-unittests.sh: line 1:  5731 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-havana/centos6-11/9\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1206706733.6145048.1420581499164.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-06 16:58:19',-18000,'2015-01-06 21:58:19',NULL,'[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday January\n 7th @ 2200 UTC in #openstack-meeting','Hi all,\n\nJust a reminder that the OpenStack Telco Working Group [1] will be meeting @ 2200 UTC in #openstack-meeting on Wednesday January 7th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add items that you wish to discuss at the meeting.\n\nThanks,\n\nSteve\n\n[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup\n\n\n','<1694401958.6144924.1420581447702.JavaMail.zimbra@redhat.com>',NULL),('<1206706733.6145048.1420581499164.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-06 16:58:19',-18000,'2015-01-06 21:58:19',NULL,'[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday\n January 7th @ 2200 UTC in #openstack-meeting','Hi all,\n\nJust a reminder that the OpenStack Telco Working Group [1] will be meeting @ 2200 UTC in #openstack-meeting on Wednesday January 7th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add items that you wish to discuss at the meeting.\n\nThanks,\n\nSteve\n\n[1] https://wiki.openstack.org/wiki/TelcoWorkingGroup\n\n\n','<1694401958.6144924.1420581447702.JavaMail.zimbra@redhat.com>',NULL),('<1206F590-E7F9-45E6-84A0-B51FB324976D@alyseo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 13:08:39',3600,'2013-03-07 12:08:39',NULL,'[openstack-dev] Fwd: [Blueprint horizon-plugin] Summary\n	information in horizon','Yes it is in french ;) and certainly sent to the wrong recipients :)\n\nYacine kheddache / www.alyseo.com\n\nLe 7 mars 2013 ? 12:36, \"Lu, Lianhao\" <lianhao.lu at intel.com> a ?crit :\n\n> Google translate told me it\'s French: If qqun may look, this could be interesting for eNocloud...\n> \n> Jean-Baptiste Ransy wrote on 2013-03-07:\n>> oops ? :)\n>> \n>> On 03/07/2013 12:00 PM, Nicolas Barcet wrote:\n>>> Si qqun peut regarder, ca pourrait ?tre interessant pour eNocloud...\n>>> \n>>> ---------- Forwarded message ----------\n>>> From: Brooklyn <brooklyn.chen at canonical.com>\n>>> Date: Wed, Mar 6, 2013 at 11:14 AM\n>>> Subject: [Blueprint horizon-plugin] Summary information in horizon\n>>> To: nicolas at barcet.com\n>>> \n>>> \n>>> Blueprint changed by Brooklyn:\n>>> \n>>> Whiteboard changed:\n>>>   This can\'t be merged into horizon master right now. I need to push\n>>>   the code to github and make it works then merge it to horizon\n>>>   master. Do you think this will be done before Feb 19th?  Otherwise\n>>>   will have to reassign to another series No, I am afraid this can\'t\n>>>   be finished before that. Sorry for that.\n>>> :( I think this can be reassigned to H series.\n>>> +\n>>> + The code is now on github\n>>> + https://github.com/yuanotes/horizon/tree/ceilometer.\n>>> \n>>> --\n>>> Summary information in horizon\n>>> https://blueprints.launchpad.net/ceilometer/+spec/horizon-plugin\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<857BE142E5399E46B20FD45B9DB8A7BC10005F7F@SHSMSX102.ccr.corp.intel.com>',NULL),('<1207124910.25399730.1389017656686.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-06 09:14:16',-18000,'2014-01-06 14:14:16',NULL,'[Openstack-operators] Neutron Documentation','\n\n----- Original Message -----\n> From: \"Alvise Dorigo\" <alvise.dorigo at pd.infn.it>\n> To: \"Sankarshan Mukhopadhyay\" <sankarshan.mukhopadhyay at gmail.com>\n> Cc: openstack-operators at lists.openstack.org\n> Sent: Sunday, January 5, 2014 9:22:34 AM\n> Subject: Re: [Openstack-operators] Neutron Documentation\n> \n> Hi Sankarshan,\n> in the same site you suggested I found also a version ?4?:\n> \n> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/\n> \n> Do you know if that is ?good? (or still in beta) as the ?3? version ?\n> I?ve seen the version ?3? still talks about ?quantum? which was replaced by\n> neutron (just a rename as far as I know).\n> \n> thanks,\n> \n> 	A.\n\nRed Hat Enterprise Linux OpenStack Platform 3 is Grizzly based (hence the documentation for that version still correctly refers to Quantum), 4 is Havana based. Both are fully (and concurrently) supported.\n\nThanks,\n\nSteve\n\n\n','<FF905910-8558-4AD2-BC5F-BD1111813180@pd.infn.it>',NULL),('<1207289720.4651127.1395319538855.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 08:45:38',-14400,'2014-03-20 12:45:38',NULL,'[openstack-dev] [Marconi] [Ceilometer] Why is marconi a queue\n implementation vs a provisioning API?','----- Original Message -----\n> Monty Taylor wrote:\n> > On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:\n> >> The problem with AGPL is that the scope is very uncertain and the\n> >> determination of the  consequences are very fact intensive. I was the\n> >> chair of the User Committee in developing the GPLv3 and I am therefor\n> >> quite familiar with the legal issues.  The incorporation of AGPLv3\n> >> code Into OpenStack Project  is a significant decision and should not\n> >> be made without input from the Foundation. At a minimum, the\n> >> inclusion of APLv3 code means that the OpenStack Project is no longer\n> >> solely an Apache v2 licensed project because AGPLv3 code cannot be\n> >> licensed under Apache v. 2 License.  Moreover, the inclusion of such\n> >> code is inconsistent with the current CLA provisions.\n> >>\n> >> This code can be included but it is an important decision that should\n> >> be made carefully.\n> > \n> > I agree - but in this case, I think that we\'re not talking about\n> > including AGPL code in OpenStack as much as we are talking about using\n> > an Apache2 driver that would talk to a server that is AGPL ... if the\n> > deployer chooses to install the AGPL software. I don\'t think we\'re\n> > suggesting that downloading or installing openstack itself would involve\n> > downloading or installing AGPL code.\n> \n> Yes, the issue here is more... a large number of people want to stay\n> away from AGPL. Should the TC consider adding to the OpenStack\n> integrated release a component that requires AGPL software to be\n> installed alongside it ? It\'s not really a legal issue (hence me\n> stopping the legal-issues cross-posting).\n> \n> This was identified early on as a concern with Marconi and the SQLA\n> support was added to counter that concern. The question then becomes,\n> how usable this SQLA option actually is ? If it\'s sluggish, unusable in\n> production or if it doesn\'t fully support the proposed Marconi API, then\n> I think we still have that concern.\n\nThis is somewhat tangential but what\'s the recommended/default backend for Telemetry these days? I ask because in the documentation we currently still appear to concentrate on using MongoDB [1]. Are all of the backends - or at least those with \'Yes\' in all columns in the developer docs [2] - first class citizens at this point?\n\nThanks,\n\nSteve\n\n[1] http://docs.openstack.org/havana/install-guide/install/yum/content/ceilometer-install.html\n[2] http://docs.openstack.org/developer/ceilometer/install/dbreco.html\n\n\n','<532ACBFF.5010109@openstack.org>',NULL),('<1207321653.17815432.1385478175853.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 15:02:55',0,'2013-11-26 15:02:55',NULL,'[openstack-dev] Adding notifications to Horizon','Thanks for your feedback. \n\nSandy, thank you for the link. I agree that the .start/.end \nnotification pattern that you propose seems to be the most appropriate \nto monitor actions launched through the Horizon dashboard. \n\nIn the case of .start/.end notifications, the decorator should do the \njob and has the advantage of being less intrusive than the function \ncall. Specific notifications may then be sent through ad-hoc \nfunctions. \n\nLance, I agree with you that generic notification patterns should be \nmoved to Oslo-incubator. While Keystone\'s `notifications.py` module \nimplements the CrUD pattern, I believe that the .start/.end pattern \nmakes more sense in the case of Horizon. \n\nI\'ll try and propose a generic .start/.end pattern implementation to \nthe Oslo-incubator, that will be based on Keystone\'s decorator \nimplementation. \n\nRegards, \nFlorent Flament \n\n----- Original Message -----\n\nFrom: \"Lance D Bragstad\" <ldbragst at us.ibm.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Monday, November 25, 2013 6:21:55 PM \nSubject: Re: [openstack-dev] Adding notifications to Horizon \n\n\n\nSandy Walsh <sandy.walsh at rackspace.com> wrote on 11/25/2013 10:30:05 AM: \n\n> From: Sandy Walsh <sandy.walsh at rackspace.com> \n> To: <openstack-dev at lists.openstack.org>, \n> Date: 11/25/2013 10:34 AM \n> Subject: Re: [openstack-dev] Adding notifications to Horizon \n> \n> +1 on the inline method. It makes it clear when a notification should be \n> emitted and, as you say, handles the exception handling better. \n\nThis might be a good opportunity to add the decorator from Keystone\'s \nnotification module to Oslo-incubator, and recycle some of that code. \n\nhttps://github.com/openstack/keystone/blob/master/keystone/notifications.py#L26 \n\nI know some projects may require more information to be sent in the event payload: \nhttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L783 \n\nbut a general case (like Keystone) that requires only a UUID of the resource \nand the type of action being created, the current decorator does this pretty well. \nhttps://github.com/openstack/keystone/blob/master/keystone/assignment/core.py#L66 \n\nIf this is the direction of event notifications in Horizon, it would be nice to \nsettle on one implementation. \n\n> \n> Also, if it makes sense for Horizon, consider bracketing long-running \n> operations in .start/.end pairs. This will help with performance tuning \n> and early error detection. \n> \n> More info on \"well behaved notifications\" in here: \n> http://www.sandywalsh.com/2013/09/notification-usage-in-openstack-report.html \n> \n> Great to see! \n> \n> -S \n> \n> \n> On 11/25/2013 11:58 AM, Florent Flament wrote: \n> > Hi, \n> > \n> > I am interested in adding AMQP notifications to the Horizon dashboard, \n> > as described in the following blueprint: \n> > https://blueprints.launchpad.net/horizon/+spec/horizon-notifications \n> > \n> > There are currently several implementations in Openstack. While \n> > Nova and Cinder define `notify_about_*` methods that are called \n> > whenever a notification has to be sent, Keystone uses decorators, \n> > which send appropriate notifications when decorated methods are \n> > called. \n> > \n> > I fed the blueprint\'s whiteboard with an implementation proposal, \n> > based on Nova and Cinder implementation. I would be interested in \n> > having your opinion about which method would fit best, and whether \n> > these notifications make sense at all. \n> > \n> > Cheers, \n> > Florent Flament \n> > \n> > _______________________________________________ \n> > OpenStack-dev mailing list \n> > OpenStack-dev at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> > \n> \n> _______________________________________________ \n> OpenStack-dev mailing list \n> OpenStack-dev at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> \n\n\n\nBest Regards, \n\nLance Bragstad \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/9abc8ff3/attachment.html>\n\n','<OFAF3ABA53.5A68E2FA-ON86257C2E.005DDD2A-86257C2E.005F676E@us.ibm.com>',NULL),('<1209387833.33.1378361008432.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-05 06:03:28',0,'2013-09-05 06:03:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #18','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/18/>\n\n------------------------------------------\n[...truncated 634 lines...]\ntest_update_template_diff_properties_added (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.605s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.18\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-memcached==1.53\npython-novaclient==2.14.1\npython-quantumclient==2.2.3\npython-swiftclient==1.6.0\npytz==2013b\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Y3C4tJg0ZX\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise14/18\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1209743834.10219406.1400164077668.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-15 10:27:57',-14400,'2014-05-15 14:27:57',NULL,'[openstack-dev] [Neutron][NFV] NFV BoF at design summit','----- Original Message -----\n> From: \"Alan Kavanagh\" <alan.kavanagh at ericsson.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: iawells at cisco.com\n> Sent: Thursday, May 15, 2014 10:02:49 AM\n> Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit\n> \n> +1 can we reschedule to push this forward Chris please?\n> \n> Alan\n\nThere are a number of other NFV-related sessions later in the day today as well (both on the general and design tracks), perhaps the best option would be to meet during the lunch break tomorrow instead, will enough interested people still be around?\n\nThanks,\n\nSteve\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E65A191@eusaamb109.ericsson.se>',NULL),('<120ad8f3725cf9234bed1dc4f37ff6f9@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-16 20:56:39',7200,'2014-04-16 18:56:39',NULL,'[Openstack-docs] swift config-ref tables','Hello list,\n\nI\'d like to update the swift config-ref tables to include the new \nsettings/helpstrings for icehouse. An extract_swift_flags.py script \nexists in the openstack-doc-tools repo, but it doesn\'t seem to work as I \nexpected it would. From what I understand this script was used only once \nto generate the initial tables.\n\nDoes anyone (Tom?) have a good knowledge of this script and could tell \nme if it is possible to make it generate updated tables?\n\nThanks!\n\nGauvain Pocentek\n\nObjectif Libre - Infrastructure et Formations Linux\nhttp://www.objectif-libre.com\n\n\n',NULL,NULL),('<1210194021.18143403.1353313411206.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-19 00:23:31',-28800,'2012-11-19 08:23:31',NULL,'[openstack-dev] [Quantum]How to contribute LBaas driver?','That\'s likely because LBaaS as a core quantum feature is just underway for Grizzly. After the framework is in place, the plugins for each specific vendor will likely follow.\n\nSachin\n\n----- Original Message -----\nFrom: \"HuYanrui\" <huyr at arraynetworks.com.cn>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, November 19, 2012 12:14:19 AM\nSubject: Re: [openstack-dev] [Quantum]How to contribute LBaas driver?\n\nThanks for Sachin\'s kindly reply.\nJust one more question: \nI saw F5 published their driver code on github. And LBaas proposal also mentioned F5 bigip.\nBut there is no F5 driver in LBaas source on github.\nAnd I also did not found F5 name in company list of CLA at http://wiki.openstack.org/Contributors/Corporate\n----- Original Message ----- \nFrom: \"Sachin Thakkar\" <sthakkar at vmware.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, November 19, 2012 3:47 PM\nSubject: Re: [openstack-dev] [Quantum]How to contribute LBaas driver?\n\n\n> Hi Hu,\n> \n> Yes, that is the correct process. We initially were having separate LBaaS discussions during/after the summit but it has now been separated into distinct work items. If you\'re interested in helping, ping us when we discuss LBaaS during the quantum meeting\n> \n> Cheers,\n> Sachin\n> \n> ----- Original Message -----\n> From: \"HuYanrui\" <huyr at arraynetworks.com.cn>\n> To: openstack-dev at lists.openstack.org\n> Sent: Sunday, November 18, 2012 11:28:26 PM\n> Subject: [openstack-dev] [Quantum]How to contribute LBaas driver?\n> \n> \n> \n> Guys, \n> Just want to make sure how to contribue LBaas driver (commercial)? \n> Is this process same with contribute plugin in quantum like this page? - \n> http://wiki.openstack.org/QuantumDevelopment \n> \n> \n> \n> Hu Yanrui \n> \n> Array Networks Inc. \n> \n> Tel: 86 010-84446688 ext 259 \n> \n> E-mail : huyr at arraynetworks.com.cn \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<05ECD61E184949829603467D6F787C81@PC201007301138>',NULL),('<1210750042.18.1352851764989.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:09:24',0,'2012-11-14 00:09:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-essex #92','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-essex/92/>\n\n\n\n','<716662919.58.1352765312658.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1210958928.2.1381557861406.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-12 06:04:21',0,'2013-10-12 06:04:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #31','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/31/>\n\n------------------------------------------\n[...truncated 4903 lines...]\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-12T06:04:16.789927\', resource_metadata={}) from 0 transformer\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-12 06:04:16    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-12T06:04:16.791857\', resource_metadata={}) from 0 transformer\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-12 06:04:16    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-12T06:04:16.794739\', resource_metadata={}) from 0 transformer\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-12 06:04:16    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-12T06:04:16.797872\', resource_metadata={}) from 0 transformer\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-10-12 06:04:16     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-12 06:04:16    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-12T06:04:16.801633\', resource_metadata={}) from 0 transformer\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-12 06:04:16    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 41, in test_keystone_middleware_conf\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nceilometer.storage: DEBUG: looking for \'mongodb\' driver in \'ceilometer.storage\'\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'sqlite = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'postgresql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'log = ceilometer.storage.impl_log:LogStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mongodb = ceilometer.storage.impl_mongodb:MongoDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mysql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'test = ceilometer.storage.impl_test:TestDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'hbase = ceilometer.storage.impl_hbase:HBaseStorage\')\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.q2lvhFHdOW/keystone-signing-cYDeLF as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 51, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 42, in test_keystone_middleware_conf\n    self.assertEqual(api_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.q2lvhFHdOW/keystone-signing-AYK7de as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 52, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\n2013-10-12 06:04:06     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-12 06:04:06     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-12 06:04:06  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-12 06:04:06  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-12 06:04:06     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.q2lvhFHdOW/keystone-signing-O2p8wJ as cache directory for signing certificate\n2013-10-12 06:04:06     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.q2lvhFHdOW/keystone-signing-O2p8wJ as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 14.775s\n\nFAILED (SKIP=290, errors=4)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> --no-path-adjustment\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.7.1\nMako==0.9.0\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b5\nWebOb==1.2.3\nWebTest==2.0.9\nWerkzeug==0.9.4\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\nboto==2.14.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.31\ncffi==0.7.2\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.7\ndecorator==3.4.0\ndnspython==1.11.1\ndocutils==0.9.1\necdsa==0.9\neventlet==0.14.0\nextras==0.0.3\nglance==2013.1\ngreenlet==0.4.1\nhappybase==0.6\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.1\nnumpy==1.7.1\noslo.config==1.2.1\nparamiko==1.12.0\npasslib==1.6.1\npbr==0.5.21\npecan==0.4.2\nprettytable==0.7.2\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycparser==2.10\npycrypto==2.6\npymongo==2.6.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-spidermonkey==0.0.10\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplegeneric==0.8.1\nsimplejson==3.3.1\nsingledispatch==3.4.0.2\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\nswift==1.9.1\nthrift==0.9.1\nunittest2==0.5.1\nwaitress==0.8.7\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.q2lvhFHdOW\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/precise38/31\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1212884281.1278570.1366827177856.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-04-24 14:12:57',-14400,'2013-04-24 18:12:57',NULL,'[OpenStack-Infra] Talking is the first step.','\n\n----- Original Message -----\n> From: \"Monty Taylor\" <mordred at inaugust.com>\n> To: openstack-infra at lists.openstack.org\n> Sent: Wednesday, April 24, 2013 11:19:17 AM\n> Subject: Re: [OpenStack-Infra] Talking is the first step.\n> \n> \n> \n> On 04/24/2013 11:07 AM, Brian Lamar wrote:\n> > \n> > On Apr 24, 2013, at 10:50 AM, Dan Prince <dprince at redhat.com> wrote:\n> > \n> >> \n> >> ----- Original Message -----\n> >>> From: Brian Lamar <brian.lamar at rackspace.com>\n> >> \n> >>> So the question again becomes how can we get XenServer into the\n> >>> gate.\n> >> \n> >> Hi Lamar,\n> >> \n> >> I understand there is a long term goal to move towards larger scale\n> >> testing on bare metal w/ TripleO, etc. I\'m very interested in that\n> >> myself too. In the short/mid term however perhaps using SmokeStack\n> >> (which supports testing multiple/flexible configurations) would\n> >> help cover the scenario you described below via pre-gate testing?\n> > \n> > I knew I was missing something big when I had finished this email.\n> > Absolutely. Maybe our first fight really is how we can get SmokeStack\n> > (and thus XenServer testing) as part of the gate.\n> > \n> > My understanding is that the main gripe is that it needs to be easy\n> > for people to see what failed and for them to have access to the\n> > nodes to troubleshoot failures. Is this what is holding things back?\n\n\n> > I\'d love to get as many specifics as possible so we can work on\n> > getting things integrated. This is probably a question for\n> > Jim/Monty.\n> \n> There are a few issues around this:\n> \n> a) puppet/packages in the gate is a HUGE issue that we do not have a\n> solution for yet\n\nSure. This topic may warrant its own thread. But it does seem like any *more realistic* 3rd party deployments may have the same sorts of problems that we face with gating on puppet (which uses packages). Probably best to take this offline.\n\n> b) reliability engineering - running the amount of tests that we run\n> with the other system is a really big undertaking and there is a full\n> time team of people working basically just on making it work.\n> c) duplication of effort. This was the thing that made me yell at Dan\n> originally - although I think we\'re friends now. But we don\'t want two\n> things in the gate driving testing. We have zuul, and we have jenkins,\n> and we add new features to them constantly to keep up with the needs of\n> the gate. We don\'t want to add a second parallel system to a collection\n> of tools that\'s already a huge undertaking to manage, because it would\n> mean that everything we do to the zuul system would have to be\n> duplicated in the non-zuul system.\n\nThe focus of SmokeStack has really become pre-gate testing testing w/ packages and config management. Find issues before they land (outside of the scope of the gate). Because it isn\'t a gate we can be a bit more agile about the configuration we run (while still being careful) and provide good feedback to the community. If your goal is to gate things I do agree with the gist of what Monty says above in that zuul is our gate.\n\nGating issues aside I do want to clarify a couple of things lest I be seen as someone who goes around duplicating CI things on the project by just reading this thread:\n\n- SmokeStack was around before there even was a devstack gate or zuul. (The openstack Jenkins did exist... but didn\'t cut it for me initially)\n\n- It is a big undertaking, I\'ve been running a live system to test upstream since Cactus. :)\n\n- Once upon a time I even maintained a job in the OpenStack Jenkins that basically did the same thing a SmokeStack job does (w/ packages and config mgmt). After feedback from the Diablo conference there wasn\'t really a \"light at the end of the tunnel\" as far as making this job gating. For that matter upstream packages seemed to be going out of style (we stopped maintaining the upstream PPA\'s etc).\n\nSo... SmokeStack still exists and I continue to find value in running 3rd party configuration/testing with it.\n\nI\'m not trying to dig up history or dwell on any of this. But I\'m also not trying to duplicate things and I do think SmokeStack might be useful for this task in the short term being a bit more agile than our full gating solution.\n\n> \n> Now don\'t get me wrong - I think smokestack has been a very useful tool\n> for the community and I think it\'s great that Dan has provided that\n> service for the community. But if we were to \"integrate\" it in to the\n> gate, I\'d be much more interested in porting the things that it runs on\n> machines to the system that the OpenStack project already runs.\n> \n> That still doesn\'t address the issues with adding packaging and config\n> management to the gate though.\n> \n> If smokestack is useful to you to get started on this task, then by all\n> means use it! But in terms of gating, I\'d really like for us to engage\n> in the hard work of meeting all of the requirements that are out there\n> in a way that\'s integrated with the work that\'s already being done.\n\nLamar:\n\nI do think SmokeStack could be useful in the short term for this. It is probably less than a weeks worth of work to get these 4 machines upgraded to XenServer 6.1 and then you\'d have your pre-gate test results for the most part. It is your call as to whether you think this is worth the effort.\n\nMid-term: If we tease out the packages and config management pieces of what I\'m currently doing and replace it with whatever (Devstack or custom shell/venv deployment solution), and then move that job into Jenkins/Zuul I think you\'ll have your gate.\n\nLong-term: I\'d love to see a fully automated bare metal solution. TripleO, etc.\n\nDan\n\n\n','<5177F7F5.50307@inaugust.com>',NULL),('<1212970875.64.1383458636902.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:03:56',0,'2013-11-03 06:03:56',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-ceilometer-python27-stable-grizzly #47','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/47/>\n\n\n\n','<730560477.42.1383372218956.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1213620845.116.1358057727039.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-13 06:15:26',0,'2013-01-13 06:15:26',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #66','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/66/>\n\n------------------------------------------\n[...truncated 14176 lines...]\n+++ VOLUME_BACKING_FILE_SIZE=10G\n+++ PRIVATE_NETWORK_NAME=private\n+++ PUBLIC_NETWORK_NAME=nova\n++ [[ -r /opt/stack/new/devstack/.stackenv ]]\n++ source /opt/stack/new/devstack/.stackenv\n+++ BASE_SQL_CONN=postgresql://root:secret at localhost\n+++ ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net,postgresql\n+++ HOST_IP=10.4.75.157\n+++ LOGFILE=/opt/stack/new/devstacklog.txt.2013-01-13-060328\n+++ SERVICE_HOST=127.0.0.1\n+++ SERVICE_PROTOCOL=http\n+++ TLS_IP=\n++ source /opt/stack/new/devstack/lib/tls\n+++ is_service_enabled tls-proxy\n+++ services=tls-proxy\n+++ for service in \'${services}\'\n+++ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net,postgresql, =~ ,tls-proxy, ]]\n+++ [[ tls-proxy == \\n\\o\\v\\a ]]\n+++ [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n+++ [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+++ [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n+++ [[ tls-proxy == \\q\\u\\a\\n\\t\\u\\m ]]\n+++ return 1\n+++ DEVSTACK_HOSTNAME=secure.devstack.org\n+++ DEVSTACK_CERT_NAME=devstack-cert\n+++ DEVSTACK_CERT=/opt/stack/data/devstack-cert.pem\n+++ ROOT_CA_DIR=/opt/stack/data/CA/root-ca\n+++ INT_CA_DIR=/opt/stack/data/CA/int-ca\n+++ ORG_NAME=OpenStack\n+++ ORG_UNIT_NAME=DevStack\n+++ STUD_PROTO=--tls\n+++ STUD_CIPHERS=\'TLSv1+HIGH:!DES:!aNULL:!eNULL:@STRENGTH\'\n+++ OPENSSL=/usr/bin/openssl\n++ export OS_TENANT_NAME=demo\n++ OS_TENANT_NAME=demo\n++ export OS_USERNAME=demo\n++ OS_USERNAME=demo\n++ export OS_PASSWORD=secret\n++ OS_PASSWORD=secret\n++ export OS_NO_CACHE=True\n++ OS_NO_CACHE=True\n++ HOST_IP=10.4.75.157\n++ SERVICE_HOST=127.0.0.1\n++ SERVICE_PROTOCOL=http\n++ GLANCE_HOST=10.4.75.157\n++ export OS_AUTH_URL=http://127.0.0.1:5000/v2.0\n++ OS_AUTH_URL=http://127.0.0.1:5000/v2.0\n++ export OS_CACERT=/opt/stack/data/CA/int-ca/ca-chain.pem\n++ OS_CACERT=/opt/stack/data/CA/int-ca/ca-chain.pem\n++ export NOVA_VERSION=1.1\n++ NOVA_VERSION=1.1\n++ export COMPUTE_API_VERSION=1.1\n++ COMPUTE_API_VERSION=1.1\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net,postgresql, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net,postgresql =~ q- ]]\n+ return 1\n+ source /opt/stack/new/devstack/exerciserc\n++ export ACTIVE_TIMEOUT=60\n++ ACTIVE_TIMEOUT=60\n++ export ASSOCIATE_TIMEOUT=60\n++ ASSOCIATE_TIMEOUT=60\n++ export BOOT_TIMEOUT=90\n++ BOOT_TIMEOUT=90\n++ export RUNNING_TIMEOUT=150\n++ RUNNING_TIMEOUT=150\n++ export TERMINATE_TIMEOUT=60\n++ TERMINATE_TIMEOUT=60\n++ export VOLUME_TIMEOUT=30\n++ VOLUME_TIMEOUT=30\n++ export VOLUME_DELETE_TIMEOUT=60\n++ VOLUME_DELETE_TIMEOUT=60\n++ export DEFAULT_VOLUME_SIZE=1\n++ DEFAULT_VOLUME_SIZE=1\n+ is_service_enabled cinder\n+ services=cinder\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net,postgresql, =~ ,cinder, ]]\n+ return 0\n+ DEFAULT_INSTANCE_TYPE=m1.tiny\n+ DEFAULT_IMAGE_NAME=cirros-0.3.0-x86_64-uec\n+ SECGROUP=vol_secgroup\n+ nova list\n+--------------------------------------+---------------------------------------------+--------+----------+\n| ID                                   | Name                                        | Status | Networks |\n+--------------------------------------+---------------------------------------------+--------+----------+\n| e8accf8b-6ffa-4e7e-8404-f1c3465fde05 | Server e8accf8b-6ffa-4e7e-8404-f1c3465fde05 | ERROR  |          |\n| deb5778d-cc6b-4ed9-8321-a196a75c024c | ex-float                                    | BUILD  |          |\n+--------------------------------------+---------------------------------------------+--------+----------+\n+ nova image-list\n+--------------------------------------+---------------------------------+--------+--------+\n| ID                                   | Name                            | Status | Server |\n+--------------------------------------+---------------------------------+--------+--------+\n| aad9a27d-8534-4883-8eee-691b077b0b9f | cirros-0.3.0-x86_64-uec         | ACTIVE |        |\n| 5cc6d2cd-e5ee-451b-8175-5d124f13f222 | cirros-0.3.0-x86_64-uec-kernel  | ACTIVE |        |\n| 5ac5b671-f94e-435b-9b0c-792eccca9212 | cirros-0.3.0-x86_64-uec-ramdisk | ACTIVE |        |\n+--------------------------------------+---------------------------------+--------+--------+\n+ glance image-list\n+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+\n| ID                                   | Name                            | Disk Format | Container Format | Size     | Status |\n+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+\n| aad9a27d-8534-4883-8eee-691b077b0b9f | cirros-0.3.0-x86_64-uec         | ami         | ami              | 25165824 | active |\n| 5cc6d2cd-e5ee-451b-8175-5d124f13f222 | cirros-0.3.0-x86_64-uec-kernel  | aki         | aki              | 4731440  | active |\n| 5ac5b671-f94e-435b-9b0c-792eccca9212 | cirros-0.3.0-x86_64-uec-ramdisk | ari         | ari              | 2254249  | active |\n+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+\n++ glance image-list\n++ egrep \' cirros-0.3.0-x86_64-uec \'\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| aad9a27d-8534-4883-8eee-691b077b0b9f | cirros-0.3.0-x86_64-uec         | ami         | ami              | 25165824 | active |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ IMAGE=aad9a27d-8534-4883-8eee-691b077b0b9f\n+ nova secgroup-list\n+---------------+---------------------------+\n| Name          | Description               |\n+---------------+---------------------------+\n| default       | default                   |\n| euca_secgroup | euca_secgroup description |\n| test_secgroup | test_secgroup description |\n+---------------+---------------------------+\n+ nova secgroup-list\n+ grep -q vol_secgroup\n+ nova secgroup-create vol_secgroup \'vol_secgroup description\'\n+--------------+--------------------------+\n| Name         | Description              |\n+--------------+--------------------------+\n| vol_secgroup | vol_secgroup description |\n+--------------+--------------------------+\n+ timeout 60 sh -c \'while ! nova secgroup-list | grep -q vol_secgroup; do sleep 1; done\'\n+ nova secgroup-list-rules vol_secgroup\n+ grep -q icmp\n+ nova secgroup-add-rule vol_secgroup icmp -1 -1 0.0.0.0/0\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova secgroup-list-rules vol_secgroup\n+ grep -q \' tcp .* 22 \'\n+ nova secgroup-add-rule vol_secgroup tcp 22 22 0.0.0.0/0\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| tcp         | 22        | 22      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova flavor-list\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+\n| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+\n| 1  | m1.tiny   | 512       | 0    | 0         |      | 1     | 1.0         | True      | {}          |\n| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      | {}          |\n| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      | {}          |\n| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      | {}          |\n| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      | {}          |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+-------------+\n++ nova flavor-list\n++ get_field 1\n++ read data\n++ grep m1.tiny\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 1  | m1.tiny   | 512       | 0    | 0         |      | 1     | 1.0         | True      | {}          |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ INSTANCE_TYPE=1\n+ [[ -z 1 ]]\n+ NAME=ex-vol\n++ nova boot --flavor 1 --image aad9a27d-8534-4883-8eee-691b077b0b9f ex-vol --security_groups=vol_secgroup\n++ get_field 2\n++ read data\n++ grep \' id \'\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| id                     | fba6be5f-53fc-4634-818a-eee08bf88221 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ VM_UUID=fba6be5f-53fc-4634-818a-eee08bf88221\n+ die_if_not_set VM_UUID \'Failure launching ex-vol\'\n+ local exitcode=0\n+ set +o xtrace\n+ timeout 60 sh -c \'while ! nova show fba6be5f-53fc-4634-818a-eee08bf88221 | grep status | grep -q ACTIVE; do sleep 1; done\'\n+ echo \'server didn\'\\\'\'t become active!\'\nserver didn\'t become active!\n+ exit 1\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS horizon\nPASS sec_groups\nPASS swift\nFAILED euca\nFAILED floating_ips\nFAILED volumes\n=====================================================================\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/rabbitmq/rabbit at devstack-1358050287-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/rabbitmq/rabbit at devstack-1358050287.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/66/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1215117616.54.1383458559895.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:02:39',0,'2013-11-03 06:02:39',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-glance-docs-stable-folsom #50','See <https://jenkins01.openstack.org/job/periodic-glance-docs-stable-folsom/50/>\n\n\n\n','<1490384030.36.1383372180040.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1215E66F-7E94-4C66-B678-D994B3551064@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-16 13:48:50',28800,'2014-04-16 05:48:50',NULL,'[Openstack] Query on container sync','Any specific reason in this way for container-sync?\n\n\n\nFrom Hugo\'s iPhone\n\n> On 2014/4/16, at ??1:15, \"Mohammed, Allauddin\" <allauddin.mohammed at hp.com> wrote:\n> \n> Hi All,\n>     I had a question regarding container sync. Can container sync be accomplished using keystone authentication and normal PUT requests as coming from an external client, instead of using current sync-key based authentication.\n>  \n> Regards,\n> Mohammed Allauddin\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140416/a643823c/attachment.html>\n\n','<169B8F4FCC41864EAE0959D6FB7BBD972331588B@G1W3640.americas.hpqcorp.net>',NULL),('<1216049305.250.1368341186967.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:46:26',0,'2013-05-12 06:46:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-quantum-python26-stable-grizzly #32','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/32/changes>\n\n\n\n','<4904317.232.1368254739294.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1216494999.20105540.1375263173994.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-31 05:32:53',-14400,'2013-07-31 09:32:53',NULL,'[Openstack-stable-maint] 2013.1.3 Status Check','\n\n----- Original Message -----\n> Hi,\n> \n> Alan just told me about this mail on IRC?, so I\'m responding via mail.\n> \n> Yes Ceilometer will very likely want a release, but we\'re late.\n> \n> We don\'t have any milestone for 2013.1.3 on\n> https://launchpad.net/ceilometer/+milestones so we can\'t assign any bugs\n> for it if I\'m not mistaken.\n> \n> As Alan said, we only have a few patches for now waiting to be approved\n> \n>   https://review.openstack.org/#/q/status:open+project:openstack/ceilometer+branch:stable/grizzly,n,z\n> \n> Eoghan told me he would take a spin at looking our git and bug history\n> for the last weeks to see if anything needs backporting. Considering the\n> deadline I guess it\'ll be doing that RSN (Eoghan, ping me if you need\n> patches approval)\n\nYes, I started that trawl last night and will complete it this morning.\n\nNote that I\'m being pretty conservative about candidate patches for backport,\nstrictly limiting it to fixes for user-visible problems in production-ready\ncode (excluding for example optimizations to the mongodb driver, or fixes to\nthe HBase driver).\n\nCheers,\nEoghan\n\n> Cheers,\n> \n> ?\n> http://lists.openstack.org/pipermail/openstack-stable-maint/2013-July/001027.html\n>    it really should be Cc\'ed on -dev as I\'m not on stable-main, and I\'m\n>    pretty sure a lot of others are not\n> \n> --\n> Julien Danjou\n> // Free Software hacker / freelance consultant\n> // http://julien.danjou.info\n>\n\n\n','<87siyvdw6l.fsf@dex.adm.naquadah.org>',NULL),('<1217373149.14.1352851558681.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:05:58',0,'2012-11-14 00:05:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/92/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/>\nCheckout:periodic-horizon-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/> - hudson.remoting.Channel at 62f4a9a3:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson8436168922626888231.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<459317057.54.1352765093905.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1217496495.9269263.1390414519991.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 13:15:20',-18000,'2014-01-22 18:15:20',NULL,'[openstack-dev] [TripleO] our update story: can people\n	live	with it?','\n\n----- Original Message -----\n> From: \"Clint Byrum\" <clint at fewbar.com>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, January 22, 2014 12:45:45 PM\n> Subject: Re: [openstack-dev] [TripleO] our update story: can people live	with it?\n> \n> Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> > I\'ve been thinking a bit more about how TripleO updates are developing\n> > specifically with regards to compute nodes. What is commonly called the\n> > \"update story\" I think.\n> > \n> > As I understand it we expect people to actually have to reboot a compute\n> > node in the cluster in order to deploy an update. This really worries me\n> > because it seems like way overkill for such a simple operation. Lets say\n> > all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> > I need to deploy it to *all* my compute instances. Do we really expect\n> > people to actually have to reboot every single compute node in their\n> > cluster for such a thing. And then do this again and again for each\n> > update they deploy?\n> > \n> \n> Agreed, if we make everybody reboot to push out a patch to libvirt, we\n> have failed. And thus far, we are failing to do that, but with good\n> reason.\n> \n> Right at this very moment, we are leaning on \'rebuild\' in Nova, which\n> reboots the instance. But this is so that we handle the hardest thing\n> well first (rebooting to have a new kernel).\n> \n> For small updates we need to decouple things a bit more. There is a\n> notion of the image ID in Nova, versus the image ID that is actually\n> running. Right now we update it with a nova rebuild command only.\n> \n> But ideally we would give operators a tool to optimize and avoid the\n> reboot when it is appropriate. The heuristic should be as simple as\n> comparing kernels.\n\nWhen we get to implementing such a thing I might prefer it not to be auto-magic. I can see a case where I want the new image but maybe not the new kernel. Perhaps this should be addressed when building the image (by using the older kernel)... but still. I could see a case for explicitly not wanting to reboot here as well.\n\n> Once we have determined that a new image does not\n> need a reboot, we can just change the ID in Metadata, and an\n> os-refresh-config script will do something like this:\n> \n> if [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\n> then;\n>     download_new_image\n>     mount_image /tmp/new_image\n>     mount / -o remount,rw # Assuming we\'ve achieved ro root\n>     rsync --one-file-system -a /tmp/new_image/ /\n>     mount / -o remount,ro # ditto\n> fi\n> \n> No reboot required. This would run early in configure.d, so that any\n> pre-configure.d scripts will have run to quiesce services that can\'t\n> handle having their binaries removed out from under them (read:\n> non-Unix services). Then configure.d runs as usual, configures things,\n> restarts services, and we are now running the new image.\n\nCool. I like this a good bit better as it avoids the reboot. Still, this is a rather large amount of data to copy around if I\'m only changing a single file in Nova.\n\n> \n> > I understand the whole read only images thing plays into this too... but\n> > I\'m wondering if there is a middle ground where things might work\n> > better. Perhaps we have a mechanism where we can tar up individual venvs\n> > from /opt/stack/ or perhaps also this is an area where real OpenStack\n> > packages could shine. It seems like we could certainly come up with some\n> > simple mechanisms to deploy these sorts of changes with Heat such that\n> > compute host reboot can be avoided for each new deploy.\n> \n> Given the scenario above, that would be a further optimization. I don\'t\n> think it makes sense to specialize for venvs or openstack services\n> though, so just \"ensure the root filesystems match\" seems like a\n> workable, highly efficient system. Note that we\'ve talked about having\n> highly efficient ways to widely distribute the new images as well.\n\nYes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n\n1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n\n2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n\n3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n\n> \n> I would call your e-mail a documentation/roadmap bug.\n\nFair enough. Thanks for the info.\n\n> This plan may have been recorded somewhere, but for me it has just always been in my\n> head as the end goal (thanks to Robert Collins for drilling the hole\n> and pouring it in there btw ;).\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1390411585-sup-3865@fewbar.com>',NULL),('<1217550815.9187539.1382556494422.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-23 15:28:14',-14400,'2013-10-23 19:28:14',NULL,'[Openstack-docs] Tool for editing html files\n	under	openstack-manuals/www','Come, join the dark side and embrace VIM (and remap your CapsLock key to Escape, the way it was supposed to be for VIM) :-)\n\n----- Original Message -----\nFrom: \"Anne Gentle\" <annegentle at justwriteclick.com>\nTo: \"Anil Gunturu\" <anil.gunturu at riftio.com>\nCc: openstack-docs at lists.openstack.org\nSent: Tuesday, October 22, 2013 11:10:19 PM\nSubject: Re: [Openstack-docs] Tool for editing html files under	openstack-manuals/www\n\n\n\n\nOn Tue, Oct 22, 2013 at 7:33 PM, Anil Gunturu < anil.gunturu at riftio.com > wrote: \n\n\n\n\n\nJust curious what tool is used to edit the html files in openstack-manuals/www (index.html)? Or is it completely ?hand? written? \n\nThose are hand written in whatever tool you like and patched to openstack-manuals/www. \n\nAnne \n\n\n\n\n\n\n\nThanks, \n\n-Anil \n\n_______________________________________________ \nOpenstack-docs mailing list \nOpenstack-docs at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs \n\n\n\n\n-- \nAnne Gentle \nannegentle at justwriteclick.com \n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<CAD0KtVGg2vjsqB9-cy8A=ZKrku3-2Mvumh3E-b8eeZNzqO-b7Q@mail.gmail.com>',NULL),('<1217561708.5405289.1381725787569.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-14 00:43:07',-14400,'2013-10-14 04:43:07',NULL,'[Openstack-docs] Meeting times','Hi there,\nAm wondering whether we could possibly change the meeting time? \n11pm is just brutal and would be lovely to change it just a couple of hours back? Or even 1 hour back?\n\nthanks, Summer\n\n\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 06.png\nType: image/png\nSize: 50539 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20131014/45f3ef03/attachment-0001.png>\n\n','<817593974.5403879.1381725090547.JavaMail.root@redhat.com>',NULL),('<12178348-B293-418B-AD7D-AA7F92F28D3E@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-02 02:24:11',0,'2014-05-02 02:24:11',NULL,'[openstack-dev] [Neutron][LBaaS]User Stories and sruvey','     Balukoff I\'m liking your API spec so far but can you elaborate on what this loadbalancer object you refer to is. on page You declare its immutable and refer to it like an actual primitive object yet I don\'t\nsee a schema for it. I see loadbalancer_id in the vip request that reference. The top part of the doc declares a loadbalancer is is the first object created according to the definition in the glossary.\nhttps://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer where it is defined as the root Object that is first created or can be fully populated but in you API proposal it looks like the vip object is the created top level primitive with flavor attribute is apart of a VIP. Are you intending to rename what we call a loadbalancer to a VIP? Could you provide a work flow of a created loadbalancer. It looks good either way.\n\nIs it cool if we rename ca_certificate_id to client_ca or client_ca_certificate to make it clear the purpose of the CA is to snub clients. Later on if we need to do encryption to back end pool members that have x509s signed by their own CA we can then use a parameter like reencryption_ca_certificate.\n\nConsider the following cases.\n\nThe user wants SSL_ID based persistence on an HTTPS LoadBalancer where the loadbalancer does not know the key or cert but has access to the unencrypted RFC5246: 7.4.1.2 uncrypted Session ID\nto identify persistence to the back end HTTPS pool member?\n\nOn the pool side of the loadbalaancer can a loadbalancer still encrypt if no ca_certificate_id or client_certificate_id is present? How would they signal to the api that they extend to encrypt with out host name validation or even vert validation at all. Not sure why they would want to other then they don\'t feel the need to pay for certs on their backend nodes or worse yes pay for a signing cert.\n\nThe user feels secure on their network and wants SSL termination at the loadbalancer so the loadbalancer has the Cert and Key and extends to use plain old HTTP to the pool members with some headers injected. What would the protocol on the listener be \"HTTPS\" and would placing a CERT and KEY imply deception should happen.\n\nAlso I\'ve been burned in an earlier project when I started noticing some CA\'s were using ECDSA certs instead of RSA? should we take non RSA x509s into account as well? Right now it looks like the API assumes everything is RSA.\n\n\nBy placing\nOn May 1, 2014, at 5:35 PM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:\n\nGerman,\n\nThey certainly are essential-- but as far as I can tell, we haven\'t been concentrating on them, so the list there is likely very incomplete.\n\nStephen\n\n\nOn Thu, May 1, 2014 at 1:04 PM, Eichberger, German <german.eichberger at hp.com<mailto:german.eichberger at hp.com>> wrote:\nStephen,\n\nI would prefer if we can vote on them, too. They are essential and I would like to make sure they are considered first-class citizen when it comes to use cases.\n\nThanks,\nGerman\n\nFrom: Stephen Balukoff [mailto:sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>]\nSent: Thursday, May 01, 2014 12:52 PM\n\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey\n\n\nYep, I\'m all for this as well!\n\nNote: We\'re just talking about \"user\" use cases in this survey, correct?  (We\'ll leave the operator use cases for later when we have more of a story and/or model to work with on how we\'re going to approach those, yes?)\n\nThanks,\nStephen\n\nOn Thu, May 1, 2014 at 11:54 AM, Jorge Miramontes <jorge.miramontes at rackspace.com<mailto:jorge.miramontes at rackspace.com>> wrote:\nThat sounds good to me. The only thing I would caution is that we have prioritized certain requirements (like HA and SSL Termination) and I want to ensure we use the survey to compliment what we have already mutually agreed upon. Thanks for spearheading this!\n\nCheers,\n--Jorge\n\nFrom: Samuel Bercovici <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Thursday, May 1, 2014 12:39 PM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey\n\nHi Everyone!\n\nTo assist in evaluating the use cases that matter and since we now have ~45 use cases, I would like to propose to conduct a survey using something like surveymonkey.\nThe idea is to have a non-anonymous survey listing the use cases and ask you identify and vote.\nThen we will publish the results and can prioritize based on this.\n\nTo do so in a timely manner, I would like to freeze the document for editing and allow only comments by Monday May 5th 08:00AMUTC and publish the survey link to ML ASAP after that.\n\nPlease let me know if this is acceptable.\n\nRegards,\n                -Sam.\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nStephen Balukoff\nBlue Box Group, LLC\n(800)613-4305 x807<tel:%28800%29613-4305%20x807>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n--\nStephen Balukoff\nBlue Box Group, LLC\n(800)613-4305 x807\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140502/21fc13ba/attachment.html>\n\n','<CAAGw+ZpzwDbfE2BV36hUeKhbM3-_29JrrHCXYKPPF9QH+R+s=A@mail.gmail.com>',NULL),('<121788853.3846357.1373639166141.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 10:26:06',-14400,'2013-07-12 14:26:06',NULL,'[Openstack-docs] Linking to external install guides','----- Original Message ----- \n\n> From: \"Nick Chase\" <nchase at mirantis.com>\n> To: \"Atul Jha\" <Atul.Jha at csscorp.com>\n> Cc: openstack-docs at lists.openstack.org, \"Shaun McCance\" <shaunm at gnome.org>,\n> \"Steve Gordon\" <sgordon at redhat.com>\n> Sent: Friday, July 12, 2013 9:12:06 AM\n> Subject: RE: [Openstack-docs] Linking to external install guides\n\n> > > <snip>\n> > >\n> > > On the other hand, we are here to document OpenStack, not all of the\n> > > independent distros, so there\'s no shame in removing that from our\n> > > launch day scope.\n> > >\n> > > </snip>\n> > >\n> > >\n> > > Are you saying we should have only announcement about new release & no\n> > > install instruction?\n> > >\n> > > Is it?\n> >\n> >\n> > <snip>\n> >\n> > No, just the opposite. I\'m saying we should have A basic, fairly distro-\n> > neutral set of install instructions. We Can then leave the distros to do\n> > their own thing.\n> >\n> > </snip>\n> >\n> > Kindly clarify. I just hope we are not putting install from source\n> > instruction i.e distro-neutral install instruction.\n> If that\'s that\'s the only true \"distro neutral\" way, and it\'s not desirable,\n> is there another option? Are you saying Canonical is usually caught up for\n> Ubuntu? I\'m not suggesting any particular way, just that we provide enough\n> information to give people the general idea, then send them on their way. I\n> don\'t have any preferece for what that looks like.\n\nUltimately there is no way to document deployment that is *entirely* distribution neutral (well, other than perhaps using something like devstack - maybe that is a valid approach for bare bones release day install documentation, I don\'t know?) due to the need to install and configure supporting infrastructure such as the database, queuing, etc. The difference of course is the packaging of those components is far more static, predictable, and most importantly available relative to the OpenStack packaging which most likely wont exist on 0-day, though it is likely to follow shortly thereafter. \n\nMy concern with documenting installation from source is it seems like creating deployment documentation for release day and release day only. I would question whether users are likely to want to use this installation method once any form of packaging is available (and again I\'m explicitly not talking about the more advanced stuff like Foreman, Fuel, PackStack, etc. - just RPMs/DEBs/etc.) - the counter argument that is being posed here of course is \"well packaging isn\'t OpenStack anyway and at that point users should go to their distribution-specific documentation site\". \n\nThanks,\n\nSteve\n\n\n','<CA+p99GmLOzTSUNtYxPfM85U5wgjUgbgV9WO55gKuT5_UuLBLGA@mail.gmail.com>',NULL),('<1218100609.51.1373264445951.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-08 06:20:45',0,'2013-07-08 06:20:45',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-grizzly #89','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly/89/>\n\n\n\n','<550320205.46.1373177883058.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1218215486.14009812.1396341614713.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 10:40:14',7200,'2014-04-01 08:40:14',NULL,'[openstack-dev] Sprint at Pycon: Port OpenStack to Python 3','Hi,\n\nI will organize a sprint to Port OpenStack to Python 3 during 4 days at Montreal (Canada) during Pycon Montreal 2014, between April, 14 (Monday) and April, 17 (Thursday).\n\nThe goal of the sprint is to port OpenStack components and OpenStack dependencies to Python 3, send patches to port as much code as possible. If you don\'t know OpenStack, you may focus more on OpenStack dependencies (MySQL-python, python-ldap,  websockify, ...). This is also a good opportunity to try to replace eventlet with trollius (asyncio)! Wiki page of the sprint:\n\n   https://wiki.openstack.org/wiki/Python3/SprintPycon2014\n\nI\'m writing to openstack-dev to:\n\n * know if you are interested to join the sprint\n * know which OpenStack components are most interested to receive and *review* Python 3 patches during the sprint\n * know which OpenStack components are interested to replace eventlet with trollius for the Juno release, or at least have an optional support of trollius\n * more generally, get your feedback :-)\n\nI know that the sprint doesn\'t fit well with the Icehouse release (scheduled at the last day of the sprint!). I hope that patches can be reviewed during the sprint, so developers can update them if needed during the sprint. I guess that it\'s fine if patches are only merged after the sprint.\n\nVictor\n\n\n','<601014407.14009647.1396341449687.JavaMail.zimbra@enovance.com>',NULL),('<1218717466.0.1373695449113.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-13 06:04:08',0,'2013-07-13 06:04:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #285','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/285/>\n\n------------------------------------------\n[...truncated 2680 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.110.ga45c49b to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.110.ga45c49b\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.110.ga45c49b\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.6.gcc2fbf0 to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.6.gcc2fbf0\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.6.gcc2fbf0\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/rabbitmq/rabbit at devstack-1373688714-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/rabbitmq/rabbit at devstack-1373688714.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/285/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1097534679.71.1373609073783.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1219933893.45669649.1394670582818.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 17:29:42',-25200,'2014-03-13 00:29:42',NULL,'[openstack-dev] [nova] An analysis of code review in Nova','Hi Matt,\n\nI totally agree with you and actually we have been discussing this a lot internally the last few weeks.\n. As a top priority, the driver MUST integrate with oslo.vmware. This will be achieved through this chain of patches [1]. We want these patches to be merged before other things.\nI think we should stop introducing more complexity which makes the task of refactoring more and more complicated. The integration with oslo.vmware is not a refactoring but should be seen as a way to get a more \"lightweight\" version of the driver which will make the task of refactoring a bit easier.\n. Then, we want to actually refactor, we got several meetings to know what is the best strategy to adopt going forward (and avoid reproducing the same mistakes).\nThe highest priority is spawn(): we need to make it modular, remove nested methods. This refactoring work should include the integration with the image handler framework [2] and introducing the notion of image type object to avoid all these conditions on types of images inside the core logic.\n. I would like to see you cores to be \"involved\" in this design since you will be reviewing the code at some point. \"involved\" here can be interpreted as review the design, and/ or actually participate to the design discussions. I would like to get your POV on this.\n\nLet me know if this approach makes sense.\n\nThanks,\nArnaud\n\n[1] https://review.openstack.org/#/c/70175/\n[2] https://review.openstack.org/#/c/33409/\n\n\n----- Original Message -----\nFrom: \"Matt Riedemann\" <mriedem at linux.vnet.ibm.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, March 12, 2014 11:28:23 AM\nSubject: Re: [openstack-dev] [nova] An analysis of code review in Nova\n\n\n\nOn 2/25/2014 6:36 AM, Matthew Booth wrote:\n> I\'m new to Nova. After some frustration with the review process,\n> specifically in the VMware driver, I decided to try to visualise how the\n> review process is working across Nova. To that end, I\'ve created 2\n> graphs, both attached to this mail.\n>\n> Both graphs show a nova directory tree pruned at the point that a\n> directory contains less than 2% of total LOCs. Additionally, /tests and\n> /locale are pruned as they make the resulting graph much busier without\n> adding a great deal of useful information. The data for both graphs was\n> generated from the most recent 1000 changes in gerrit on Monday 24th Feb\n> 2014. This includes all pending changes, just over 500, and just under\n> 500 recently merged changes.\n>\n> pending.svg shows the percentage of LOCs which have an outstanding\n> change against them. This is one measure of how hard it is to write new\n> code in Nova.\n>\n> merged.svg shows the average length of time between the\n> ultimately-accepted version of a change being pushed and being approved.\n>\n> Note that there are inaccuracies in these graphs, but they should be\n> mostly good. Details of generation here:\n> https://urldefense.proofpoint.com/v1/url?u=https://github.com/mdbooth/heatmap&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=q%2BhYPEq%2BGxlDrGrMdbYCWuaLhZOwXwRpMQwWxkSied4%3D%0A&s=9a9e8ba562a81e0d00ca4190fbda306617637473ba5e721e4071d8d0ae20175c. This code is obviously\n> single-purpose, but is free for re-use if anyone feels so inclined.\n>\n> The first graph above (pending.svg) is the one I was most interested in,\n> and shows exactly what I expected it to. Note the size of \'vmwareapi\'.\n> If you check out Nova master, 24% of the vmwareapi driver has an\n> outstanding change against it. It is practically impossible to write new\n> code in vmwareapi without stomping on an oustanding patch. Compare that\n> to the libvirt driver at a much healthier 3%.\n>\n> The second graph (merged.svg) is an attempt to look at why that is.\n> Again comparing the VMware driver with the libvirt we can see that at 12\n> days, it takes much longer for a change to be approved in the VMware\n> driver than in the libvirt driver. I suspect that this isn\'t the whole\n> story, which is likely a combination of a much longer review time with\n> very active development.\n>\n> What\'s the impact of this? As I said above, it obviously makes it very\n> hard to come in as a new developer of the VMware driver when almost a\n> quarter of it has been rewritten, but you can\'t see it. I am very new to\n> this and others should validate my conclusions, but I also believe this\n> is having a detrimental impact to code quality. Remember that the above\n> 12 day approval is only the time for the final version to be approved.\n> If a change goes through multiple versions, each of those also has an\n> increased review period, meaning that the time from first submission to\n> final inclusion is typically very, very protracted. The VMware driver\n> has its fair share of high priority issues and functionality gaps, and\n> the developers are motived to get it in the best possible shape as\n> quickly as possible. However, it is my impression that when problems\n> stem from structural issues, the developers choose to add metaphorical\n> gaffer tape rather than fix them, because fixing both creates a\n> dependency chain which pushes the user-visible fix months into the\n> future. In this respect the review process is dysfunctional, and is\n> actively detrimental to code quality.\n>\n> Unfortunately I\'m not yet sufficiently familiar with the project to\n> offer a solution. A core reviewer who regularly looks at it is an\n> obvious fix. A less obvious fix might involve a process which allows\n> developers to work on a fork which is periodically merged, rather like\n> the kernel.\n>\n> Matt\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=q%2BhYPEq%2BGxlDrGrMdbYCWuaLhZOwXwRpMQwWxkSied4%3D%0A&s=f45e9c5395962acd9184246580e317582cb00b9428861ef7853989b96afc842f\n>\n\nWhen I originally read this I had some ideas in mind for a response \nregarding review latency with the vmware driver patches, but felt like \nanything I said, albeit what I consider honest, would sound \nbad/offensive in some way, and didn\'t want to convey that.\n\nBut this came up in IRC today:\n\nhttps://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/vmware-spawn-refactor&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=q%2BhYPEq%2BGxlDrGrMdbYCWuaLhZOwXwRpMQwWxkSied4%3D%0A&s=3f90de5965e50ab37a5f404a805eb5290e3dab4499bee8f288935619541ee6b2\n\nThat spurred some discussion around this same topic and I think \nhighlights one of the major issues, which is code quality and the design \nof the driver.\n\nFor example, the driver\'s spawn method is huge and there are a lot of \nnested methods within it.  There are a lot of vmware patches and a lot \nof blueprints, and a lot of them touch spawn.  When I\'m reviewing them, \nI\'m looking for new conditions and checking to see if those are unit \ntested (positive/error cases) and a lot of the time I find it very \ndifficult to tell if they are or not.  I think a lot of that has to do \nwith how the vmware tests are scaffolded with fakes to simulate a \nvcenter backend, but it makes it very difficult if you\'re not extremely \nfamiliar with that code to know if something is covered or not.\n\nAnd I\'ve actually asked in bp reviews before, \'you have this new/changed \ncondition, where is it tested\' and the response is more or less \'we plan \non refactoring this later and will add unit tests then\' or \'it\'s hard to \ntest this path without a lot of changes to how the tests are working\'. \nThat\'s unacceptable to me, and I generally give up on the review after that.\n\nSo to move this all forward, I think that bp above should be top \npriority for the vmware team in Juno to keep bp patches moving at the \npace they do, because the features and refactoring just keeps coming and \nat least for me it\'s very hard to burn out on looking at those reviews.\n\n-- \n\nThanks,\n\nMatt Riedemann\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttps://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=q%2BhYPEq%2BGxlDrGrMdbYCWuaLhZOwXwRpMQwWxkSied4%3D%0A&s=f45e9c5395962acd9184246580e317582cb00b9428861ef7853989b96afc842f\n\n\n','<5320A747.5060709@linux.vnet.ibm.com>',NULL),('<1220401273.27214331.1390210330785.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 09:32:10',0,'2014-01-20 09:32:10',NULL,'[openstack-dev] [nova]can someone help me? when I use cmd \"nova\n migration-list\" error.','\n\nPerhaps a bug-maintainer should to update the status, \nthe bug is not related to python-novaclient and it is not tried yet. \n\nThanks a lot, \n\ns. \n----- Original Message -----\n\nFrom: \"li zheming\" <lizheminghw at gmail.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Monday, January 20, 2014 4:52:27 AM \nSubject: Re: [openstack-dev] [nova]can someone help me? when I use cmd \"nova migration-list\" error. \n\nOk .thanks Jay \nI consider it is error in novaclient before. \nit is my misunderstand. thank you very much! \nlizheming \n\n2014/1/20 Jay Lau < jay.lau.513 at gmail.com > \n\n\n\nIt is being fixed https://review.openstack.org/#/c/61717/ \n\nThanks, \n\nJay \n\n\n2014/1/20 li zheming < lizheminghw at gmail.com > \n\n<blockquote>\n\nhi all: \nwhen I use cmd nova migration-list, it return error,like this: \nopenstack@ devstack: /home$ nova migration-list \nERROR: \'unicode\' object has no attribute \'iteritems\' \nI step the codes and find the codes have some error. \n\n\npython-novaclient/novaclient/base.py \n\nclass Manager(utils.HookableMixin): \n...... \ndef _list(self, url, response_key, obj_class=None, body=None): \nif body: \n_resp, body = self.api.client.post(url, body=body) \nelse: \n_resp, body = self.api.client.get(url) \n\nif obj_class is None: \nobj_class = self.resource_class \n\ndata = body[response_key] \n# NOTE(ja): keystone returns values as list as {\'values\': [ ... ]} \n# unlike other services which just return the list... \nif isinstance(data, dict): \ntry: \ndata = data[\'values\'] \nexcept KeyError: \npass \n\nwith self.completion_cache(\'human_id\', obj_class, mode=\"w\"): \nwith self.completion_cache(\'uuid\', obj_class, mode=\"w\"): \nreturn [obj_class(self, res, loaded=True) \nfor res in data if res] \n\nI set a breakpoint in \" data = data[\'values\']\", and find the date is \n\n{u\'objects\': []}}, it has no key named values. \n\nit except a keyError and pass. \n\nif go \" for res in data if res \", the res is unicode \"object\", this will \n\noccur error in the next fun. \n\ndo you met this issue? and someone who know why the comment say \" keystone returns values as list as {\'values\': [ ... ]}\" \n\nbut I think this is not relevant about keystone. may be I misunderstand this codes. please give me more info about this code. \n\nthank you very much! \n\n\n\n\n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n</blockquote>\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/3c34816c/attachment.html>\n\n','<CADVnxFfMHOBynoyQqStToAbhTK-rHkA_9qk3F8c1rkgKEYJKBw@mail.gmail.com>',NULL),('<12212D67-6134-433B-9F69-96C609BB8E2D@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-09 10:01:28',0,'2013-01-09 10:01:28',NULL,'[openstack-dev] [swift] [keystone] Keystone v3 API domains	in\n	Swift','So there are a couple of issues intertwined in this thread:\n\n1) Uniqueness of identifiers in Swift given the keystone Identity v3 api.  This is the issue of whether Swift uses tenant names (now called project names) at all to uniquely identify any objects - if it did, then it would need to also consider storing a domain name or id.  From the discussion, it sounds like tenant/project ID is used instead, which (from a uniqueness point of view) is fine.  A separate issue exists needs to be discussed around swift ACLs and whether username potentially becoming unique only within a domain will have an impact.\n\n2) Given that keystone identity v3 domains are likely to be usually used to represent an enterprise (or \"account holder\" in common cloud terminology) and contain the collection of projects owned by that enterprise, is it important for Swift to have that domain knowledge?  Will there be operations either within swift (or more likely layered on top of swift) that need that information?  E.g. How would someone layer a billing engine on top of swift that could collate all the swift containers that were part of one domain?  Obviously that engine could call keystone with each project_id in turn and find the domain_id.....but  that sounds pretty inefficient.\n\nHenry\n\nOn 9 Jan 2013, at 00:08, Yee, Guang wrote:\n\n> Yeah, I don?t see a need to add domain_id to Swift account either as project ID is globally unique. Since domain name/id are returned as part of token validation, you may be able to use them with Swift ACLs. I am sure Swift ACLs will need to be updated if and when we remove the globally uniqueness name requirement.\n>  \n>  \n> Guang\n>  \n>  \n> From: Dolph Mathews [mailto:dolph.mathews at gmail.com] \n> Sent: Tuesday, January 08, 2013 2:38 PM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift\n>  \n> TENANT_ID in v2 is exactly equal to PROJECT_ID in v3. ID\'s are guaranteed to be globally unique (implemented as service-defined UUID\'s) and are url-friendly.\n>  \n> Names in keystone are freeform, user-supplied unicode strings. They may not work in URL\'s without proper encoding and may collide in the future...\n>  \n> On that note, TENANT_NAME in v2 will become PROJECT_NAME in v3, however we\'re also talking about namespacing project names to the owning domain, so that two domains may have otherwise conflicting project names. Once we open up the namespace, we can\'t go back, so we\'re going about it very carefully. This may apply to user names, as well, but that\'s a subtly different conversation.\n>  \n> If we do make this change then you also need to identify the domain for a project name to be meaningful.\n>  \n> ID\'s will still uniquely identify a project regardless of domain or deployment.\n>  \n> -Dolph\n>  \n> \n> On Tue, Jan 8, 2013 at 2:11 PM, Alexandra Shulman-Peleg <SHULMANA at il.ibm.com> wrote:\n> I think that there is a problem with simply using https://SWIFT/AUTH_{PROJECT_ID} instead of the current  https://SWIFT/AUTH_{TENANT_ID} since it will loose the proper level in the hierarchy. We need something that will represent the hosted enterprises and this is the goal of domains. Project are more fine-grained and can represent departments or projects.  For example, following the description of Henry if two different enterprises with use the project name \"Test\" both with map to https://SWIFT/AUTH_Test. \n> \n> I think that we need to have both the domain id and the project id in the URL/account name. For example ashttps://SWIFT/AUTH_{DOMAIN_ID}_{PROJECT_ID} or as https://SWIFT/{DOMAIN_ID}_{PROJECT_ID}. In the second option we may try using the existing reseller prefix mechanism to simplify the implementation. Having the doman_id in the account name/URL is important to isolate the accounts that belong to different domains and remove the requirements for the global uniqueness of project names. \n> \n> Best Regards, \n> Alex. \n> \n> \n> \n> From:        Chuck Thier <cthier at gmail.com> \n> To:        OpenStack Development Mailing List <openstack-dev at lists.openstack.org>, \n> Date:        08/01/2013 09:38 PM \n> Subject:        Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in        Swift\n> \n> \n> \n> Hi Henry,\n> \n> From a swift perspective, I think we are fine there, as we do not use\n> the user name or project name anywhere.  At the moment, I\'m thinking\n> that we can do auth in a similar way as we did with v2.0 api.  An\n> \"account\" in swift is still tied to the project_id (which used to be\n> tennant_id), which is in the storage url like:\n> https://SWIFT/AUTH_{PROJECT_ID}.  Keystone middleware in swift\n> validates that the given token has permission for the given Project\n> ID.\n> \n> From this point of view domains are an abstract concept in keystone\n> only, and wouldn\'t mean anything directly in swift.\n> \n> Please let me know if any of my assumptions are incorrect.\n> \n> Thanks,\n> \n> --\n> Chuck\n> \n> On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <henryn at linux.vnet.ibm.com> wrote:\n> > Chuck,\n> >\n> > So user_id and project_id are always globally unique - so we are safe there.  The problem is when you specify user name or project name in the cases when we have to handle enterprises being represented by a domain and they insist that their name attributes (e.g. user names, project names etc.) be private to that domain (e.g. \"what do you mean I can\'t call my project \"Test\" because some other customer in another domain got there first!?!\").  See the following blueprint which introduces this ability as optional for domains: https://review.openstack.org/#/c/18805/\n> >\n> > For such domains, we cannot assume that user_name or project_name (or tenant_name as it used to be called) are globally unique.  \"Domain_name (or id) plus user_name\" as well as  \"Domain_name (or id) plus project_name\" will be unique however.\n> >\n> > Henry\n> > On 8 Jan 2013, at 19:05, Chuck Thier wrote:\n> >\n> >> Yeah, I was hoping for more clarity, as it would help to figure out\n> >> how to best map the concepts in swift.  A couple of quick questions\n> >> come to mind.  When a request is validated, is the domain required, or\n> >> is a user_id and project_id sufficient?  Is the concept of a domain\n> >> useful in the context of swift?\n> >>\n> >> --\n> >> Chuck\n> >>\n> >> On Tue, Jan 8, 2013 at 11:37 AM, heckj <heckj at mac.com> wrote:\n> >>> The best is probably https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md, but it\'s a bit light on use-cases around the concepts I\'m afraid.\n> >>>\n> >>> -joe\n> >>>\n> >>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <cthier at gmail.com> wrote:\n> >>>> Is there documentation anywhere that defines all of these, and the use\n> >>>> cases?  That would help us figure out how to map these concepts to\n> >>>> swift.\n> >>>>\n> >>>> --\n> >>>> Chuck\n> >>>>\n> >>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:\n> >>>>> I think it would be practical to expose the authenticated user\'s DOMAIN_ID\n> >>>>> and DOMAIN_NAME into the request environment for the underlying service /\n> >>>>> middleware to consume, as we do today with TENANT_ID / TENANT_NAME (soon to\n> >>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).\n> >>>>>\n> >>>>>\n> >>>>> -Dolph\n> >>>>>\n> >>>>>\n> >>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg\n> >>>>> <SHULMANA at il.ibm.com> wrote:\n> >>>>>>\n> >>>>>> Hi,\n> >>>>>>\n> >>>>>> As most of you know, Keystone v3 API will introduce the notions of\n> >>>>>> \"domains\" and \"projects\" which will replace the existing notion of tenants.\n> >>>>>> It is important to allow using the same concepts in Swift. Since different\n> >>>>>> domains may represent different companies, it is important to allow\n> >>>>>> reflecting the Keystone \"domain name\" in the Swift \"account name\", providing\n> >>>>>> an option to isolate the requests of different domains. Are there existing\n> >>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would like to start\n> >>>>>> discussing the potential solutions.\n> >>>>>>\n> >>>>>> Thank you all,\n> >>>>>> Alex.\n> >>>>>>\n> >>>>>>\n> >>>>>> ----------------------------------------------------------\n> >>>>>> Alexandra Shulman-Peleg, PhD\n> >>>>>> Storage Research, Cloud Platforms Dept.\n> >>>>>> IBM Haifa Research Lab\n> >>>>>> Tel: +972-3-7689530 | Fax: +972-3-7689545\n> >>>>>>\n> >>>>>>\n> >>>>>> _______________________________________________\n> >>>>>> OpenStack-dev mailing list\n> >>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>>\n> >>>>>\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130109/c7495adb/attachment.html>\n\n','<C73B35E94B12854596094F2CA866854950B0D249@G4W3292.americas.hpqcorp.net>',NULL),('<1221325720.137.1385015550117.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-21 06:32:30',0,'2013-11-21 06:32:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-havana #2','See <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-havana/2/>\n\n------------------------------------------\n[...truncated 2543 lines...]\n\nroutes.middleware: DEBUG: Matched POST /tokens\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>, \'path_info\': \'/tokens\'}\nroutes.middleware: DEBUG: Matched POST /tokens\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>, \'path_info\': \'/tokens\'}\nroutes.middleware: DEBUG: Matched POST /tokens\nroutes.middleware: DEBUG: Route path: \'/tokens\', defaults: {\'action\': u\'authenticate\', \'controller\': <keystone.token.controllers.Auth object at 0x12b20ed0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'authenticate\', \'controller\': <keystone.token.controllers.Auth object at 0x12b20ed0>}\nkeystone.common.wsgi: DEBUG: arg_dict: {}\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'435a4a9d7a162cfa1832cef4c4fa98c702387e05\'\" Value: \"({\'id\': \'baz\', \'enabled\': True, \'domain_id\': \'default\', \'name\': \'BAZ\', \'description\': \'description\'}, {\'ct\': 1385015153.5225241, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'435a4a9d7a162cfa1832cef4c4fa98c702387e05\'\" Value: \"({\'id\': \'baz\', \'enabled\': True, \'domain_id\': \'default\', \'name\': \'BAZ\', \'description\': \'description\'}, {\'ct\': 1385015153.5225241, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'9b28b5df37518646410debda756dd4c07f028d21\'\" Value: \"({\'id\': \'9fe2ff9ee4384b1894a90878d3e92bab\', \'name\': \'_member_\'}, {\'ct\': 1385015153.5392311, \'v\': 1})\"\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': \'06\', \'tz_hour\': None, \'month\': \'11\', \'timezone\': \'Z\', \'second\': \'53\', \'tz_minute\': None, \'year\': \'2013\', \'separator\': \'T\', \'day\': \'22\', \'minute\': \'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got \'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got \'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got \'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got \'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got \'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got \'53\' for \'second\' with default None\nkeystone.common.cache.core: DEBUG: CACHE_SET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"({\'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}, \'user_id\': u\'two\', \'bind\': None, \'expires\': datetime.datetime(2013, 11, 22, 6, 25, 53), \'token_data\': {\'access\': {\'token\': {\'issued_at\': \'2013-11-21T06:25:53.981810\', \'expires\': \'2013-11-22T06:25:53Z\', \'id\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}}, \'serviceCatalog\': [], \'user\': {\'username\': u\'TWO\', \'roles_links\': [], \'id\': u\'two\', \'roles\': [{\'name\': \'_member_\'}], \'name\': u\'TWO\'}, \'metadata\': {\'is_admin\': 0, \'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}}, \'user\': {\'tenantId\': u\'baz\', \'enabled\': True, \'id\': u\'two\', \'name\': u\'TWO\', u\'email\': u\'two at three.com\'}, \'key\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'token_version\': \'v2.0\', \'id\': \'564ba54f0564a5110bbf85dfaad523fc\', \'trust_id\': None, \'metadata\': {\'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}, {\'ct\': 1385015154.148308, \'v\': 1})\"\naccess: INFO: 127.0.0.1 - - [21/Nov/2013:06:25:54 +0000] \"POST http://localhost:46841/v2.0/tokens HTTP/1.0\" 200 1657\neventlet.wsgi.server: INFO: 127.0.0.1 - - [21/Nov/2013 06:25:54] \"POST /v2.0/tokens HTTP/1.1\" 200 1787 0.222984\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 1657\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'53\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'53\' for \'second\' with default None\nroutes.middleware: DEBUG: Matched PATCH /OS-KSCRUD/users/two\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>, \'path_info\': \'/OS-KSCRUD/users/two\'}\nroutes.middleware: DEBUG: Matched PATCH /OS-KSCRUD/users/two\nroutes.middleware: DEBUG: Route path: \'/OS-KSCRUD/users/{user_id}\', defaults: {\'action\': u\'set_user_password\', \'controller\': <keystone.contrib.user_crud.core.UserController object at 0x12647810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'set_user_password\', \'controller\': <keystone.contrib.user_crud.core.UserController object at 0x12647810>, \'user_id\': u\'two\'}\nkeystone.common.wsgi: DEBUG: arg_dict: {\'user_id\': u\'two\'}\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"({\'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}, \'user_id\': u\'two\', \'bind\': None, \'expires\': datetime.datetime(2013, 11, 22, 6, 25, 53), \'token_data\': {\'access\': {\'token\': {\'issued_at\': \'2013-11-21T06:25:53.981810\', \'expires\': \'2013-11-22T06:25:53Z\', \'id\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}}, \'serviceCatalog\': [], \'user\': {\'username\': u\'TWO\', \'roles_links\': [], \'id\': u\'two\', \'roles\': [{\'name\': \'_member_\'}], \'name\': u\'TWO\'}, \'metadata\': {\'is_admin\': 0, \'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}}, \'user\': {\'tenantId\': u\'baz\', \'enabled\': True, \'id\': u\'two\', \'name\': u\'TWO\', u\'email\': u\'two at three.com\'}, \'key\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'token_version\': \'v2.0\', \'id\': \'564ba54f0564a5110bbf85dfaad523fc\', \'trust_id\': None, \'metadata\': {\'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}, {\'ct\': 1385015154.148308, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'e45f4dc1a9bd1a59610ed5aa0db40470f719a2c3\'\" Value: \"({\'id\': \'default\', \'enabled\': True, \'description\': u\'Owns users and tenants (i.e. projects) available on Identity API v2.\', \'name\': u\'Default\'}, {\'ct\': 1385015153.5132439, \'v\': 1})\"\nkeystone.common.cache.core: DEBUG: CACHE_DELETE: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\"\nkeystone.common.cache.core: DEBUG: CACHE_DELETE: \"\'d469268500afb897a03ba9f406282f91a441a15f\'\"\nkeystone.common.cache.core: DEBUG: CACHE_DELETE: \"\'050822dbc80892d5f5f93a7057e80ad4ee797efa\'\"\nkeystone.common.cache.core: DEBUG: CACHE_DELETE: \"\'291200c84bc255409f233f759b5e029b3aadfef5\'\"\nkeystone.common.cache.core: DEBUG: CACHE_DELETE: \"\'7182d7ab14d783bee1222be030f9bfc06d29a0d3\'\"\nkeystone.common.cache.core: DEBUG: CACHE_SET: Key: \"\'8bc6f9e7d2812f0c1a52bc83902adfd4dcb16b29\'\" Value: \"({\'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}, \'user_id\': u\'two\', \'bind\': None, \'expires\': datetime.datetime(2013, 11, 22, 6, 25, 53), \'token_data\': {\'access\': {\'token\': {\'issued_at\': \'2013-11-21T06:25:53.981810\', \'expires\': \'2013-11-22T06:25:53Z\', \'id\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'tenant\': {\'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\', \'description\': \'description\'}}, \'serviceCatalog\': [], \'user\': {\'username\': u\'TWO\', \'roles_links\': [], \'id\': u\'two\', \'roles\': [{\'name\': \'_member_\'}], \'name\': u\'TWO\'}, \'metadata\': {\'is_admin\': 0, \'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}}, \'user\': {\'tenantId\': u\'baz\', \'enabled\': True, \'id\': u\'two\', \'name\': u\'TWO\', u\'email\': u\'two at three.com\'}, \'key\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'token_version\': \'v2.0\', \'id\': \'7fd0ae8f9e4d44e6a6d4a5453bc47dff\', \'trust_id\': None, \'metadata\': {\'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}, {\'ct\': 1385015154.215843, \'v\': 1})\"\nkeystone.contrib.user_crud.core: DEBUG: TOKEN_REF {\'tenant\': {\'description\': \'description\', \'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\'}, \'user_id\': u\'two\', \'bind\': None, \'expires\': datetime.datetime(2013, 11, 22, 6, 25, 53), \'token_data\': {\'access\': {\'token\': {\'issued_at\': \'2013-11-21T06:25:53.981810\', \'expires\': \'2013-11-22T06:25:53Z\', \'id\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'tenant\': {\'description\': \'description\', \'enabled\': True, \'id\': \'baz\', \'name\': \'BAZ\'}}, \'serviceCatalog\': [], \'user\': {\'username\': u\'TWO\', \'roles_links\': [], \'id\': u\'two\', \'roles\': [{\'name\': \'_member_\'}], \'name\': u\'TWO\'}, \'metadata\': {\'is_admin\': 0, \'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}}, \'user\': {u\'email\': u\'two at three.com\', \'enabled\': True, \'id\': u\'two\', \'name\': u\'TWO\', \'tenantId\': u\'baz\'}, \'key\': \'MIIDpgYJKoZIhvcNAQcCoIIDlzCCA5MCAQExCTAHBgUrDgMCGjCCAbMGCSqGSIb3DQEHAaCCAaQEggGgeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMS0yMVQwNjoyNTo1My45ODE4MTAiLCAiZXhwaXJlcyI6ICIyMDEzLTExLTIyVDA2OjI1OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmF6IiwgIm5hbWUiOiAiQkFaIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIlRXTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAidHdvIiwgInJvbGVzIjogW3sibmFtZSI6ICJfbWVtYmVyXyJ9XSwgIm5hbWUiOiAiVFdPIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAwLCAicm9sZXMiOiBbIjlmZTJmZjllZTQzODRiMTg5NGE5MDg3OGQzZTkyYmFiIl19fX0xggHKMIIBxgIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBALI-pymunzx6yHgbcYdg0HNHD-EsYP6b5SCLIhzrWMNfGj1lfaRt74RLSORtfsjUiYSenG8FmqMFpf8qf98+qsV8sExcEHRKlGEbfnvixHsbqdrn1ep41O+e-y-H+HyL9DClFFs-i+hMVAIOA4Ds6Nx7+1vkc-A1n5WPNf+A1Q+h3pzbqzMt9UDIznSCOSyzSUU-TnA-Ae0l25bVGcxa2BWO3ez-dDL+iQDdYyRDTFvWorjirRVXxjDrPl5nVFoZK7wUQDdcvEBTNEYxZ5wgjLsChYaKWH8adARxeDY4ui42VFglwYtSOp7YYaC4BApY+1gcRKr9eO9ZiqaIVyxLvus=\', \'token_version\': \'v2.0\', \'id\': \'7fd0ae8f9e4d44e6a6d4a5453bc47dff\', \'trust_id\': None, \'metadata\': {\'roles\': [u\'9fe2ff9ee4384b1894a90878d3e92bab\']}}\naccess: INFO: None - - [21/Nov/2013:06:25:54 +0000] \"PATCH http://localhost/v2.0/OS-KSCRUD/users/two HTTP/1.0\" 200 3365\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'53\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'53\' for \'second\' with default None\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'53\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'53\' for \'second\' with default None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\neventlet.wsgi.server: INFO: (29254) accepted (\'127.0.0.1\', 34778)\n\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>, \'path_info\': \'/tenants\'}\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>, \'path_info\': \'/tenants\'}\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'/tenants\', defaults: {\'action\': u\'get_projects_for_token\', \'controller\': <keystone.identity.controllers.Tenant object at 0x12b209d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'get_projects_for_token\', \'controller\': <keystone.identity.controllers.Tenant object at 0x12b209d0>}\nkeystone.common.wsgi: DEBUG: arg_dict: {}\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"<dogpile.cache.api.NoValue object at 0x2590990>\"\ndogpile.core.dogpile: DEBUG: NeedRegenerationException\ndogpile.core.dogpile: DEBUG: no value, waiting for create lock\ndogpile.core.dogpile: DEBUG: value creation lock <dogpile.cache.region._LockWrapper object at 0x12a15a50> acquired\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"<dogpile.cache.api.NoValue object at 0x2590990>\"\ndogpile.core.dogpile: DEBUG: Calling creation function\ndogpile.core.dogpile: DEBUG: Released creation lock\nkeystone.identity.controllers: WARNING: Authentication failed: Could not find token, 564ba54f0564a5110bbf85dfaad523fc.\nkeystone.common.wsgi: WARNING: Authorization failed. The request you have made requires authentication. from 127.0.0.1\naccess: INFO: 127.0.0.1 - - [21/Nov/2013:06:25:54 +0000] \"GET http://localhost:46841/v2.0/tenants HTTP/1.0\" 401 114\neventlet.wsgi.server: INFO: 127.0.0.1 - - [21/Nov/2013 06:25:54] \"GET /v2.0/tenants HTTP/1.1\" 401 253 0.015228\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/tenants HTTP/1.1\" 401 114\nkeystoneclient.httpclient: DEBUG: Request returned failure status: 401\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'53\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'53\' for \'second\' with default None\niso8601.iso8601: DEBUG: Parsed 2013-11-22T06:25:53Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'53\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'25\'} with default timezone <iso8601.iso8601.Utc object at 0x23418d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'53\' for \'second\' with default None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\neventlet.wsgi.server: INFO: (29254) accepted (\'127.0.0.1\', 34780)\n\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.contrib.user_crud.core.CrudExtension object at 0x12647290>, \'path_info\': \'/tenants\'}\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'{path_info:.*}\', defaults: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>}\nroutes.middleware: DEBUG: Match dict: {\'controller\': <keystone.common.wsgi.ComposingRouter object at 0x12b20a90>, \'path_info\': \'/tenants\'}\nroutes.middleware: DEBUG: Matched GET /tenants\nroutes.middleware: DEBUG: Route path: \'/tenants\', defaults: {\'action\': u\'get_projects_for_token\', \'controller\': <keystone.identity.controllers.Tenant object at 0x12b209d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'get_projects_for_token\', \'controller\': <keystone.identity.controllers.Tenant object at 0x12b209d0>}\nkeystone.common.wsgi: DEBUG: arg_dict: {}\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"<dogpile.cache.api.NoValue object at 0x2590990>\"\ndogpile.core.dogpile: DEBUG: NeedRegenerationException\ndogpile.core.dogpile: DEBUG: no value, waiting for create lock\ndogpile.core.dogpile: DEBUG: value creation lock <dogpile.cache.region._LockWrapper object at 0x12a15c90> acquired\nkeystone.common.cache.core: DEBUG: CACHE_GET: Key: \"\'c33c3568a1aedf532cef672d1999e11aea0a6a67\'\" Value: \"<dogpile.cache.api.NoValue object at 0x2590990>\"\ndogpile.core.dogpile: DEBUG: Calling creation function\ndogpile.core.dogpile: DEBUG: Released creation lock\nkeystone.identity.controllers: WARNING: Authentication failed: Could not find token, 564ba54f0564a5110bbf85dfaad523fc.\nkeystone.common.wsgi: WARNING: Authorization failed. The request you have made requires authentication. from 127.0.0.1\naccess: INFO: 127.0.0.1 - - [21/Nov/2013:06:25:54 +0000] \"GET http://localhost:46841/v2.0/tenants HTTP/1.0\" 401 114\neventlet.wsgi.server: INFO: 127.0.0.1 - - [21/Nov/2013 06:25:54] \"GET /v2.0/tenants HTTP/1.1\" 401 253 0.014180\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/tenants HTTP/1.1\" 401 114\nkeystoneclient.httpclient: DEBUG: Request returned failure status: 401\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 352.03 secs:\n    125.57    KcMasterTestCase.test_admin_requires_adminness\n    111.74    Kc11TestCase.test_admin_requires_adminness\n    100.24    KcEssex3TestCase.test_admin_requires_adminness\n    8.52    TestTokenRevoking.test_deleting_role_revokes_token\n    5.97    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1998 tests in 1107.727s\n\nFAILED (SKIP=157, errors=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-havana/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.10\nargparse==1.2.1\nbeautifulsoup4==4.3.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndocutils==0.10\ndogpile.cache==0.5.2\ndogpile.core==0.4.1\neventlet==0.14.0\nextras==0.0.3\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\niso8601==0.1.8\nkeyring==3.2.1\n-e git://git.openstack.org/openstack/keystone at 4221b6020e6b0b42325d8904d7b8a22577a6acc0#egg=keystone-origin/stable/havana\nlxml==3.2.4\nmccabe==0.2.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\noauth2==1.5.211\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\noslo.sphinx==1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npyflakes==0.7.3\npysqlite==2.6.3\npython-keystoneclient==0.4.1\npython-ldap==2.3.13\npython-memcached==1.53\npython-mimeparse==0.1.4\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwaitress==0.8.7\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./keystone/tests/nose_results.html\n+ \'[\' -f ./keystone/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./keystone/tests/nose_results.html\n+ passcount=113\n+ \'[\' 113 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.TohPZDLx4I\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-havana/2\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-havana/2/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-havana/centos6-12\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-havana/centos6-12/2\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1221916906.5249172.1386776598512.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 10:43:18',-18000,'2013-12-11 15:43:18',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','Thanks for writing this all out!\n\n----- Original Message -----\n> Disclaimer: I swear I\'ll stop posting this sort of thing soon, but I\'m\n> new to the project. I only mention it again because it\'s relevant in\n> that I missed any of the discussion on why proxying from tuskar API to\n> other APIs is looked down upon. Jiri and I had been talking yesterday\n> and he mentioned it to me when I started to ask these same sorts of\n> questions.\n> \n> On 12/11/2013 07:33 AM, Ji?? Str?nsk? wrote:\n> > Hi all,\n> >\n> > TL;DR: I believe that \"As an infrastructure administrator, Anna wants a\n> > CLI for managing the deployment providing the same fundamental features\n> > as UI.\" With the planned architecture changes (making tuskar-api thinner\n> > and getting rid of proxying to other services), there\'s not an obvious\n> > way to achieve that. We need to figure this out. I present a few options\n> > and look forward for feedback.\n> >\n> > Previously, we had planned Tuskar arcitecture like this:\n> >\n> > tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc.\n> \n> My biggest concern was that having each client call out to the\n> individual APIs directly put a lot of knowledge into the clients that\n> had to be replicated across clients. At the best case, that\'s simply\n> knowing where to look for data. But I suspect it\'s bigger than that and\n> there are workflows that will be implemented for tuskar needs. If the\n> tuskar API can\'t call out to other APIs, that workflow implementation\n> needs to be done at a higher layer, which means in each client.\n> \n> Something I\'m going to talk about later in this e-mail but I\'ll mention\n> here so that the diagrams sit side-by-side is the potential for a facade\n> layer that hides away the multiple APIs. Lemme see if I can do this in\n> ASCII:\n> \n> tuskar-ui -+               +-tuskar-api\n>             |               |\n>             +-client-facade-+-nova-api\n>             |               |\n> tuskar-cli-+               +-heat-api\n> \n> The facade layer runs client-side and contains the business logic that\n> calls across APIs and adds in the tuskar magic. That keeps the tuskar\n> API from calling into other APIs* but keeps all of the API call logic\n> abstracted away from the UX pieces.\n> \n> * Again, I\'m not 100% up to speed with the API discussion, so I\'m going\n> off the assumption that we want to avoid API to API calls. If that isn\'t\n> as strict of a design principle as I\'m understanding it to be, then the\n> above picture probably looks kinda silly, so keep in mind the context\n> I\'m going from.\n> \n> For completeness, my gut reaction was expecting to see something like:\n> \n> tuskar-ui -+\n>             |\n>             +-tuskar-api-+-nova-api\n>             |            |\n> tuskar-cli-+            +-heat-api\n> \n> Where a tuskar client talked to the tuskar API to do tuskar things.\n> Whatever was needed to do anything tuskar-y was hidden away behind the\n> tuskar API.\n> \n> > This meant that the \"integration logic\" of how to use heat, ironic and\n> > other services to manage an OpenStack deployment lied within\n> > *tuskar-api*. This gave us an easy way towards having a CLI - just build\n> > tuskarclient to wrap abilities of tuskar-api.\n> >\n> > Nowadays we talk about using heat and ironic (and neutron? nova?\n> > ceilometer?) apis directly from the UI, similarly as Dashboard does.\n> > But our approach cannot be exactly the same as in Dashboard\'s case.\n> > Dashboard is quite a thin wrapper on top of python-...clients, which\n> > means there\'s a natural parity between what the Dashboard and the CLIs\n> > can do.\n>\n> When you say python- clients, is there a distinction between the CLI and\n> a bindings library that invokes the server-side APIs? In other words,\n> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?\n> \n> > We\'re not wrapping the APIs directly (if wrapping them directly would be\n> > sufficient, we could just use Dashboard and not build Tuskar API at\n> > all). We\'re building a separate UI because we need *additional logic* on\n> > top of the APIs. E.g. instead of directly working with Heat templates\n> > and Heat stacks to deploy overcloud, user will get to pick how many\n> > control/compute/etc. nodes he wants to have, and we\'ll take care of Heat\n> > things behind the scenes. This makes Tuskar UI significantly thicker\n> > than Dashboard is, and the natural parity between CLI and UI vanishes.\n> > By having this logic in UI, we\'re effectively preventing its use from\n> > CLI. (If i were bold i\'d also think about integrating Tuskar with other\n> > software which would be prevented too if we keep the business logic in\n> > UI, but i\'m not absolutely positive about use cases here).\n> \n> I see your point about preventing its use from the CLI, but more\n> disconcerting IMO is that it just doesn\'t belong in the UI. That sort of\n> logic, the \"Heat things behind the scenes\", sounds like the jurisdiction\n> of the API (if I\'m reading into what that entails correctly).\n> \n> > Now this raises a question - how do we get CLI reasonably on par with\n> > abilities of the UI? (Or am i wrong that Anna the infrastructure\n> > administrator would want that?)\n> \n> To reiterate my point above, I see the idea of getting the CLI on par,\n> but I also see it as striving for a cleaner design as well.\n> \n> > Here are some options i see:\n> >\n> > 1) Make a thicker python-tuskarclient and put the business logic there.\n> > Make it consume other python-*clients. (This is an unusual approach\n> > though, i\'m not aware of any python-*client that would consume and\n> > integrate other python-*clients.)\n> \n> -1 in favor of #3 below (spoiler: I\'m -1 to that too, I suppose this is\n> a -2)\n> \n> > 2) Make a thicker tuskar-api and put the business logic there. (This is\n> > the original approach with consuming other services from tuskar-api. The\n> > feedback on this approach was mostly negative though.)\n> \n> A tentative +1. Tentative until I dig up the feedback on intra-API calls\n> and see why it was negative, in which case I may buy into those\n> arguments too.\n\nI\'d be +1 for this; I don\'t fully understand why intra-API calls are negative\neither, was there a previous thread that outlined the deficiencies?\n\nIn fact, I\'d advocate going a little bit farther than what we did in the demo\niteration.  Here\'s a specific case:\n\nFor the demo, it was decided that the UI would call the Baremetal API directly\nfor things like registering nodes and retrieving a node list.  That seemed to\nmake sense at the time.  Later, we realized that Tuskar had its own concept of\na node (used for node/rack associations).  So we had to make two separate queries\nand outer join the two, which led to some convoluted logic in the UI, and left\nme wondering - wouldn\'t a CLI need to use exactly the same logic?\n\nIt would make more sense to me to push that sort of thing into the API.\n\n\n> > 3) Keep tuskar-api and python-tuskarclient thin, make another library\n> > sitting between Tuskar UI and all python-***clients. This new project\n> > would contain the logic of using undercloud services to provide the\n> > \"tuskar experience\" it would expose python bindings for Tuskar UI and\n> > contain a CLI. (Think of it like traditional python-*client but instead\n> > of consuming a REST API, it would consume other python-*clients. I\n> > wonder if this is overengineering. We might end up with too many\n> > projects doing too few things? :) )\n> \n> This is the sort of thing I was describing with the facade image above.\n> Rather than beefing up python-tuskarclient, I\'d rather we have a\n> specific logic layer that isn\'t the CLI nor is it the bindings, but is\n> specifically for the purposes of coordination across multiple APIs.\n> \n> That said, I\'m -1 to my own facade diagram. I think that should live\n> service-side in the API.\n> \n> > 4) Keep python-tuskarclient thin, but build a separate CLI app that\n> > would provide same integration features as Tuskar UI does. (This would\n> > lead to code duplication. Depends on the actual amount of logic to\n> > duplicate if this is bearable or not.)\n> \n> I don\'t know the level of logic duplication that would happen, but the\n> design feels wrong from the start.\n> \n> > Which of the options you see as best? Did i miss some better option? Am\n> > i just being crazy and trying to solve a non-issue? Please tell me :)\n> \n> I\'m not saying you\'re not crazy. I\'m saying you\'re not alone in being\n> crazy if you are  :)\n> \n> > Please don\'t consider the time aspect of this, focus rather on what\'s\n> > the right approach, where we want to get eventually. (We might want to\n> > keep a thick Tuskar UI for Icehouse not to set the hell loose, there\n> > will be enough refactoring already.)\n> > Thanks\n> >\n> > Jirka\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52A8778D.4030804@redhat.com>',NULL),('<1221940435.41.1352678661983.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:04:21',0,'2012-11-12 00:04:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-diablo #90','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/90/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/>\nCheckout:periodic-horizon-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/> - hudson.remoting.Channel at 183b7230:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson1781894215193500089.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-diablo/90\n[SCP] Copying console log.\n\n\n','<1426885168.30.1352592283381.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1222221357.12221605.1384291674620.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 13:27:54',-28800,'2013-11-12 21:27:54',NULL,'[openstack-dev] [nova] Do we have some guidelines for mock, stub,\n mox when writing unit test?','Good point.\n\nI assume someone made a comparison similar to this:\n* http://garybernhardt.github.io/python-mock-comparison/\n\n... and evangelized a choice. I had assumed that Mock vs mox was not merely based on Python3 support but had something to do with Mock versus Mox. Does anyone have that context in their head? Would they mind sharing it?\n\n# Shawn Hartsock\n\n\n----- Original Message -----\n> From: \"Mark McLoughlin\" <markmc at redhat.com>\n> To: \"Shawn Hartsock\" <hartsocks at vmware.com>\n> Cc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, November 12, 2013 4:24:08 PM\n> Subject: Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?\n> \n> On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:\n> > Maybe we should have some 60% rule... that is: If you change more than\n> > half of a test... you should *probably* rewrite the test in Mock.\n> \n> A rule needs a reasoning attached to it :)\n> \n> Why do we want people to use mock?\n> \n> Is it really for Python3? If so, I assume that means we\'ve ruled out the\n> python3 port of mox? (Ok by me, but would be good to hear why) And, if\n> that\'s the case, then we should encourage whoever wants to port mox\n> based tests to mock.\n> \n> Or maybe it has nothing to do with Python3 at all? Maybe we just like\n> mock more? But do we like it enough to have a mixture of mock and mox\n> across the codebase?\n> \n> Mark.\n> \n> > ----- Original Message -----\n> > > From: \"John Garbutt\" <john at johngarbutt.com>\n> > > To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing\n> > > List (not for usage questions)\"\n> > > <openstack-dev at lists.openstack.org>\n> > > Sent: Tuesday, November 12, 2013 9:31:25 AM\n> > > Subject: Re: [openstack-dev] [nova] Do we have some guidelines for mock,\n> > > stub, mox when writing unit test?\n> > > \n> > > On 11 November 2013 23:18, Mark McLoughlin <markmc at redhat.com> wrote:\n> > > > On Mon, 2013-11-11 at 12:07 +0000, John Garbutt wrote:\n> > > >> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)\n> > > >> <andrea.rosa at hp.com> wrote:\n> > > >> > Hi\n> > > >> >\n> > > >> >>Generally mock is supposed to be used over mox now for python 3\n> > > >> >>support.\n> > > >> >\n> > > >> > That is my understanding too\n> > > >>\n> > > >> +1\n> > > >>\n> > > >> But I don\'t think we should waste all our time re-writing all our mox\n> > > >> and stub tests. Lets just leave this to happen organically for now as\n> > > >> we add and refactor tests. We probably need to take the hit at some\n> > > >> point, but that doesn\'t feel like we should do that right now.\n> > > >\n> > > > Hmm, I don\'t follow this stance.\n> > > >\n> > > > Adding Python3 support is a goal we all share.\n> > > >\n> > > > If we\'re saying that the use of mox stands in the way of that goal, but\n> > > > that we\'d really prefer if people didn\'t work on porting tests from mox\n> > > > to mock yet ... then are we saying we don\'t value people working on\n> > > > porting to Python3?\n> > > >\n> > > > And if we plan to use a Python3 compatible version of mox[1], then\n> > > > isn\'t\n> > > > the Python3 argument irrelevant and saying \"use mock for new tests\"\n> > > > just\n> > > > means we\'ll end up with a mixture of mox and mock?\n> > > \n> > > Good point, I forgot about the port of mox to python3.\n> > > \n> > > I liked the idea of \"prefer mock\", with a view that at some point in\n> > > the future there is only a small amount of mox related code left, that\n> > > can easily get moved to mock.\n> > > \n> > > I guess its a trade off between review capacity, risk of breaking\n> > > existing tests, and risk of never reaching that end goal.\n> > > \n> > > We already have stubs and mox, which do tend to fight each other,\n> > > adding a third does seem like a bad plan, unless there is a very good\n> > > reason, which I always had in my head as python3 support. Hmm... I do\n> > > prefer mock to mox, but not that strongly.\n> > > \n> > > John\n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> \n\n\n','<1384291448.2372.87.camel@sorcha>',NULL),('<1222380711.8.1370585569576.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-07 06:12:49',0,'2013-06-07 06:12:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #249','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/249/>\n\n------------------------------------------\n[...truncated 945 lines...]\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.04\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.02\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.02\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.02\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.02\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.21\n    test_request_url_v1                                          OK    0.02\n    test_request_url_v1_0                                        OK    0.02\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.02\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.02\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Exercise `glance-control api reload`\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 224, in test_reload\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status for: api, \n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, \'Unexpected server launch status for: api, \'\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 74.46 secs:\n    17.37    TestGlanceControl.test_bouncing\n    14.84    TestScrubber.test_delayed_delete\n    14.14    TestGlanceControl.test_reload\n    14.10    TestGlanceControl.test_respawn\n    14.01    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 588.100s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-249\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.9MGWIm0ERo\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/249\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/249/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1222632857.30.1380954838171.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-05 06:33:57',0,'2013-10-05 06:33:57',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #31','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/31/>\n\n------------------------------------------\n[...truncated 21709 lines...]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\nInitialized empty Git repository in /tmp/tempest-unitqeGDlh/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitbAYFsk/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           205.706\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   170.411\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   76.077\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                       40.259\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                     33.478\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      32.956\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]          29.907\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]      29.183\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]         28.359\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   27.867\n\n----------------------------------------------------------------------\nRan 1305 tests in 1252.277s\n\nOK (skipped=64)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-516593-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-516593.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-516593/31/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1358469263.26.1380868262621.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1223061806.2651107.1390417360085.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 20:02:40',3600,'2014-01-22 19:02:40',NULL,'[openstack-dev] [Swift] domain-level quotas','Greetings,\n\nI\'d be interested in your opinions and feedback on the following blueprint: https://blueprints.launchpad.net/swift/+spec/domain-level-quotas\n\nThe idea is to have a middleware checking a domain\'s current usage against a limit set in the configuration before allowing an upload. The domain id can be extracted from the token, then used to query keystone for a list of projects belonging to the domain. Swift would then compute the domain usage in a similar fashion as the way it is currently done for accounts, and proceed from there.\n\nDo you think it is viable ? Thoughts ?\n\nThanks,\n\nMatthieu Huin \n\nmhu at enovance.com \nhttp://www.enovance.com \neNovance SaS - 10 rue de la Victoire 75009 Paris - France \n\n\n\n','<1108817496.2650814.1390416912432.JavaMail.root@enovance.com>',NULL),('<12233488.5803547.1369389233348.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-24 05:53:53',-14400,'2013-05-24 09:53:53',NULL,'[openstack-dev] Fwd: Can\'t use Horizon trunk with\n	Grizzly	services','This was tracked and resolved in https://bugs.launchpad.net/horizon/+bug/1183230 . If you update to the latest it should work again.\n\nRegards,\n\nJulie\n\n----- Original Message -----\n> From: \"Endre Karlson\" <endre.karlson at gmail.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, 23 May, 2013 7:25:07 PM\n> Subject: Re: [openstack-dev] Fwd: Can\'t use Horizon trunk with Grizzly	services\n> \n> http://pastebin.com/wpDeVtkz\n> \n> ==> /var/log/apache2/error.log <==\n> [Thu May 23 18:21:15 2013] [error] DEBUG:openstack_auth.backend:Beginning\n> user authentication for user \"endre\".\n> [Thu May 23 18:21:16 2013] [error]\n> DEBUG:openstack_auth.backend:Authentication completed for user \"endre\".\n> [Thu May 23 18:21:16 2013] [error] INFO:openstack_auth.forms:Login\n> successful for user \"endre\".\n> \n> ==> /var/log/apache2/other_vhosts_access.log <==\n> console.x.no:443 79.160.206.91 - - [23/May/2013:18:21:14 +0000] \"POST\n> /auth/login/ HTTP/1.1\" 302 2389 \"\n> https://console.x.no/auth/login/?next=/project/\" \"Mozilla/5.0 (X11; Linux\n> x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu\n> Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22\"\n> \n> ==> /var/log/apache2/error.log <==\n> [Thu May 23 18:21:18 2013] [error]\n> [Thu May 23 18:21:18 2013] [error] REQ: curl -i\n> http://compute.x.no:8774/v2/c7bc3570f7544ba3ba7425fb572c8a87/os-simple-tenant-usage/c7bc3570f7544ba3ba7425fb572c8a87?start=2013-05-01T00:00:00&end=2013-05-23T18:21:18.354186-X\n> GET -H \"X-Auth-Project-Id: c7bc3570f7544ba3ba7425fb572c8a87\" -H\n> \"User-Agent: python-novaclient\" -H \"Accept: application/json\" -H\n> \"X-Auth-Token: 78b054c7bfd731ed489bd2fc44fbd633\"\n> [Thu May 23 18:21:18 2013] [error]\n> [Thu May 23 18:21:18 2013] [error] RESP: [200] CaseInsensitiveDict({\'date\':\n> \'Thu, 23 May 2013 18:21:18 GMT\', \'x-compute-request-id\':\n> \'req-a4eee7cf-c8a8-4124-85c5-d6c62903e0a8\', \'content-type\':\n> \'application/json\', \'content-length\': \'10917\'})\n> [Thu May 23 18:21:18 2013] [error] RESP BODY: {\"tenant_usage\":\n> {\"total_memory_mb_usage\": 344565.0019214222, \"total_vcpus_usage\":\n> 169.13004651111112, \"start\": \"2013-05-01T00:00:00.000000\", \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"stop\": \"2013-05-23T18:21:18.354186\",\n> \"server_usages\": [{\"instance_id\": \"f2476615-8bbd-4cb1-b374-cdf576ecd2e2\",\n> \"uptime\": 575, \"started_at\": \"2013-05-21T18:00:48.000000\", \"ended_at\":\n> \"2013-05-21T18:10:23.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.1597222222222222, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0, \"name\":\n> \"test\"}, {\"instance_id\": \"82efeac7-242a-4731-8b67-395706e5884c\", \"uptime\":\n> 178, \"started_at\": \"2013-05-21T18:10:43.000000\", \"ended_at\":\n> \"2013-05-21T18:13:41.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.049444444444444444, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0,\n> \"name\": \"test\"}, {\"instance_id\": \"0976b062-9dcb-4c09-885f-7e867009d57d\",\n> \"uptime\": 111, \"started_at\": \"2013-05-21T18:15:53.000000\", \"ended_at\":\n> \"2013-05-21T18:17:44.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.030833333333333334, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"9dd8dcff-3f48-4266-baf6-f581781a0099\",\n> \"uptime\": 46, \"started_at\": \"2013-05-21T18:18:04.000000\", \"ended_at\":\n> \"2013-05-21T18:18:50.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.012777777777777779, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"a2d3e301-785b-4355-aa16-a96715a8560c\",\n> \"uptime\": 2365, \"started_at\": \"2013-05-21T18:18:59.000000\", \"ended_at\":\n> \"2013-05-21T18:58:24.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.6569444444444444, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"8bf34cc2-4dc9-4e7b-8706-8a4765f270fe\",\n> \"uptime\": 298, \"started_at\": \"2013-05-21T19:02:40.000000\", \"ended_at\":\n> \"2013-05-21T19:07:38.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.08277777777777778, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0,\n> \"name\": \"test\"}, {\"instance_id\": \"60bc101d-8228-4037-9b3f-7bd4b6288e87\",\n> \"uptime\": 354, \"started_at\": \"2013-05-21T19:07:53.000000\", \"ended_at\":\n> \"2013-05-21T19:13:47.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.09833333333333333, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0,\n> \"name\": \"test\"}, {\"instance_id\": \"d27da024-bf25-40bd-82d8-ef3ee5bdddc1\",\n> \"uptime\": 2368, \"started_at\": \"2013-05-21T19:14:04.000000\", \"ended_at\":\n> \"2013-05-21T19:53:32.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.6577777777777778, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0, \"name\":\n> \"test\"}, {\"instance_id\": \"7acea51f-bd95-4c32-83ba-0be4e51af2fe\", \"uptime\":\n> 1314, \"started_at\": \"2013-05-21T19:31:38.000000\", \"ended_at\":\n> \"2013-05-21T19:53:32.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\": 0.365,\n> \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20, \"name\": \"test\"},\n> {\"instance_id\": \"28c622f1-9d2a-44fc-b49f-1937e409309e\", \"uptime\": 232,\n> \"started_at\": \"2013-05-21T19:54:01.000000\", \"ended_at\":\n> \"2013-05-21T19:57:53.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.06444444444444444, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"a03e532f-0ed1-4590-b584-e3c433c21951\",\n> \"uptime\": 1527, \"started_at\": \"2013-05-21T19:58:18.000000\", \"ended_at\":\n> \"2013-05-21T20:23:45.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.4241666666666667, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"c0c42811-3924-4dd7-b337-f1d9f8e60845\",\n> \"uptime\": 633, \"started_at\": \"2013-05-21T20:24:04.000000\", \"ended_at\":\n> \"2013-05-21T20:34:37.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.17583333333333334, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"c5d18668-c8b2-40a0-996b-434f3e1170a8\",\n> \"uptime\": 233, \"started_at\": \"2013-05-21T20:40:59.000000\", \"ended_at\":\n> \"2013-05-21T20:44:52.000000\", \"memory_mb\": 4096, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.06472222222222222, \"vcpus\": 2, \"flavor\": \"m1.medium\", \"local_gb\": 40,\n> \"name\": \"test\"}, {\"instance_id\": \"b2c79a60-3428-46fa-97c7-276fce678366\",\n> \"uptime\": 3744, \"started_at\": \"2013-05-21T20:52:54.000000\", \"ended_at\":\n> \"2013-05-21T21:55:18.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\": 1.04,\n> \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20, \"name\": \"test\"},\n> {\"instance_id\": \"b54f546c-6fba-4420-ba46-28260da82eaf\", \"uptime\": 531,\n> \"started_at\": \"2013-05-21T21:54:56.000000\", \"ended_at\":\n> \"2013-05-21T22:03:47.000000\", \"memory_mb\": 4096, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\": 0.1475,\n> \"vcpus\": 2, \"flavor\": \"m1.medium\", \"local_gb\": 40, \"name\": \"test\"},\n> {\"instance_id\": \"28a917aa-2cfe-47b2-9e14-e3cea641957b\", \"uptime\": 199,\n> \"started_at\": \"2013-05-21T22:00:28.000000\", \"ended_at\":\n> \"2013-05-21T22:03:47.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.05527777777777778, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"test\"}, {\"instance_id\": \"dafbdd03-a459-4639-b03a-30fad092b92a\",\n> \"uptime\": 2852, \"started_at\": \"2013-05-21T22:04:25.000000\", \"ended_at\":\n> \"2013-05-21T22:51:57.000000\", \"memory_mb\": 4096, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.7922222222222223, \"vcpus\": 2, \"flavor\": \"m1.medium\", \"local_gb\": 40,\n> \"name\": \"test\"}, {\"instance_id\": \"0eae6e26-755e-4953-a05d-0262c62ca247\",\n> \"uptime\": 163, \"started_at\": \"2013-05-21T22:49:14.000000\", \"ended_at\":\n> \"2013-05-21T22:51:57.000000\", \"memory_mb\": 2048, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.04527777777777778, \"vcpus\": 1, \"flavor\": \"m1.small\", \"local_gb\": 20,\n> \"name\": \"t\"}, {\"instance_id\": \"2156817b-e2a8-4666-9eab-aa71440da600\",\n> \"uptime\": 59, \"started_at\": \"2013-05-21T22:51:14.000000\", \"ended_at\":\n> \"2013-05-21T22:52:13.000000\", \"memory_mb\": 512, \"tenant_id\":\n> \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\": \"terminated\", \"hours\":\n> 0.01638888888888889, \"vcpus\": 1, \"flavor\": \"m1.tiny\", \"local_gb\": 0,\n> \"name\": \"test-2156817b-e2a8-4666-9eab-aa71440da600\"}, {\"instance_id\":\n> \"7638bfd0-4894-409a-8a07-2e748ce20ff0\", \"uptime\": 58, \"started_at\":\n> \"2013-05-21T22:51:15.000000\", \"ended_at\": \"2013-05-21T22:52:13.000000\",\n> \"memory_mb\": 512, \"tenant_id\": \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\":\n> \"terminated\", \"hours\": 0.01611111111111111, \"vcpus\": 1, \"flavor\":\n> \"m1.tiny\", \"local_gb\": 0, \"name\":\n> \"test-7638bfd0-4894-409a-8a07-2e748ce20ff0\"}, {\"instance_id\":\n> \"563e6e4b-cae4-439c-b8ab-55f46c562f35\", \"uptime\": 60, \"started_at\":\n> \"2013-05-21T22:51:13.000000\", \"ended_at\": \"2013-05-21T22:52:13.000000\",\n> \"memory_mb\": 512, \"tenant_id\": \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\":\n> \"terminated\", \"hours\": 0.016666666666666666, \"vcpus\": 1, \"flavor\":\n> \"m1.tiny\", \"local_gb\": 0, \"name\":\n> \"test-563e6e4b-cae4-439c-b8ab-55f46c562f35\"}, {\"instance_id\":\n> \"285e4d23-994a-475d-a006-10620f73d21a\", \"uptime\": 73, \"started_at\":\n> \"2013-05-21T22:51:00.000000\", \"ended_at\": \"2013-05-21T22:52:13.000000\",\n> \"memory_mb\": 512, \"tenant_id\": \"c7bc3570f7544ba3ba7425fb572c8a87\", \"state\":\n> \"terminated\", \"hours\": 0.020277777777777777, \"vcpus\": 1, \"flavor\":\n> \"m1.tiny\", \"local_gb\": 0, \"name\":\n> \"test-285e4d23-994a-475d-a006-10620f73d21a\"}, {\"instance_id\":\n> \"36b35969-eeca-43a4-824e-2ed42f57e224\", \"uptime\": 50, \"started_at\":\n> \"2013-05-21T22:51:11.000000\", \"ended_at\": \"2013-05-21T22:52:01.000000\",\n> \"memory_mb\": 512, \"tenant_id\": \"c7bc3570f7544ba3ba7425fb572c8a87\", \"sta\n> [Thu May 23 18:21:18 2013] [error]\n> \n> ==> /var/log/apache2/other_vhosts_access.log <==\n> console.x.no:443 79.160.206.91 - - [23/May/2013:18:21:17 +0000] \"GET\n> /project/ HTTP/1.1\" 302 757 \"https://console.x.no/auth/login/?next=/project/\"\n> \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko)\n> Ubuntu Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22\"\n> console.x.no:443 79.160.206.91 - - [23/May/2013:18:21:18 +0000] \"GET\n> /auth/login/?next=/project/ HTTP/1.1\" 200 4402 \"\n> https://console.x.no/auth/login/?next=/project/\" \"Mozilla/5.0 (X11; Linux\n> x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu\n> Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22\"\n> console.x.no:443 79.160.206.91 - - [23/May/2013:18:21:19 +0000] \"GET\n> /i18n/js/horizon/ HTTP/1.1\" 200 2729 \"\n> https://console.x.no/auth/login/?next=/project/\" \"Mozilla/5.0 (X11; Linux\n> x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Ubuntu\n> Chromium/25.0.1364.160 Chrome/25.0.1364.160 Safari/537.22\"\n> \n> I enabled memcache and restarted but it still fails.\n> \n> Endre\n> \n\n\n','<CAFxO1NQrzGfTRkuoZ+Ahooh04MKCa=b0qXVmVPZ6aR43fZMEEw@mail.gmail.com>',NULL),('<1224547254.6274093.1396450891606.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 11:01:31',-14400,'2014-04-02 15:01:31',NULL,'[openstack-dev] Missleading and hardly parseable default\n neutron config files','IMHO, having \"Example:\" on a separate line from the actual option is a lot easier for humans:\nyou just delete a single character or use your editor-of-choice\'s uncomment macro to activate\na line.\n\n----- Original Message -----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, April 2, 2014 9:45:05 AM\nSubject: Re: [openstack-dev] Missleading and hardly parseable default neutron config files\n\nOn 04/02/2014 06:38 AM, Salvatore Orlando wrote:\n> Hi Thomas,\n> \n> it probably won\'t be a bad idea if you can share the patches you\'re\n> applying to the default configuration files.\n> I think all distros are patching them anyway, so this might allow us to\n> provide mostly ready to use config files.\n> \n> Is there a chance you can push something to gerrit?\n\nHow about auto generate the sample config like most other projects?\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<533C1461.9040001@redhat.com>',NULL),('<1224893096.9924557.1411506460626.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 17:07:40',-14400,'2014-09-23 21:07:40',NULL,'[openstack-dev] [sahara] Juno release images','\n\n----- Original Message -----\n> If someone uses Fedora images I can add their.\n\nI can generate Fedora images, I\'ll post here when they are ready.\n\nmike\n\n\n','<CAOB5mPycCR1S53hQd8XBr+7YNsJhZSpwiPhta0JD+kYvOjaHkg@mail.gmail.com>',NULL),('<122492773.99.1380299166844.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-27 16:26:04',0,'2013-09-27 16:26:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #21','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/21/>\n\n------------------------------------------\n[...truncated 5857 lines...]\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 20694\n+ mkdir -p /opt/stack/new/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sudo iptables -S -v\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ sed s/-A/-D/g\n+ awk \'{print \"sudo iptables\",$0}\'\n+ bash\n+ grep \'\\-A\'\n+ sudo iptables -S -v -t nat\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ grep \'\\-A\'\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ bash\n+ sed s/-A/-D/g\n+ sudo iptables -S -v\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ bash\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ awk \'{print \"sudo iptables\",$0}\'\n+ grep nova\n+ sudo iptables -S -v -t nat\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ sed s/-N/-X/g\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ grep \'\\-N\'\n+ grep nova\n++ sudo virsh list --all\n++ grep instance-\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ xargs sudo iscsiadm --mode node --logout\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ sudo iscsiadm --mode node --op delete\niscsiadm: no records found!\niscsiadm: no records found!\n+ true\n+ sudo rm -rf \'/opt/stack/new/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/new/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4,<1.5 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.8.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_compressor%2Fdjango_compressor-1.3.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth<1.1.0 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /opt/stack/new/python-cinderclient (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/new/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /opt/stack/new/python-keystoneclient (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/new/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nRequirement already satisfied (use --upgrade to upgrade): pytz>=2010h in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 10))\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.6.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango-appconf%2Fdjango-appconf-0.6.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): oslo.config>=1.2.0 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing>=1.5.6,<2.0 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2012.2.5 to easy-install.pth file\n\nInstalled /opt/stack/new/horizon\nProcessing dependencies for horizon==2012.2.5\nerror: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-27-162102\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-407823-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-407823.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az2-407823/21/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<311077753.90.1380176182166.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1225046489.26.1383199909192.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-31 06:11:49',0,'2013-10-31 06:11:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #40','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/40/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5452490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5452490>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55d1e90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55d1e90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-3187efcf-4e4b-49f1-8280-b9fc2867d10b\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:11:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:11:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:11:15+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:11:15-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:11:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6515810>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27d66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 80.02 secs:\n    22.99    TestGlanceControl.test_bouncing\n    14.83    TestScrubber.test_delayed_delete\n    14.31    TestGlanceControl.test_reload\n    14.02    TestGlanceControl.test_respawn\n    13.87    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 618.725s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-40\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.0UDzmw5vog\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/40/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-6/40\n[SCP] Copying console log.\n\n\n','<1728221129.22.1383113492263.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1225418129.48.1352679246055.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:14:05',0,'2012-11-12 00:14:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-diablo #90','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/90/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/>\nCheckout:periodic-swift-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/> - hudson.remoting.Channel at 740355a4:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson3024626928271392911.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-diablo/90\n[SCP] Copying console log.\n\n\n','<218072742.36.1352592750878.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1225557000.0.1386915122540.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:12:01',0,'2013-12-13 06:12:01',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-keystone-docs-grizzly #7','See <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/7/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise36 in workspace <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/>\nCheckout:periodic-keystone-docs-grizzly / <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/> - hudson.remoting.Channel at 22fbf34b:precise36\nUsing strategy: Default\nLast Built Revision: Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/keystone\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/keystone\nCommencing build of Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\nChecking out Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\n[periodic-keystone-docs-grizzly] $ /bin/bash -xe /tmp/hudson6931051312598230114.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=keystone\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n++ org=openstack\n++ project=keystone\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=keystone\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z keystone ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/keystone /opt/requirements/projects.txt\nopenstack/keystone\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/tools/test-requires>\nvenv inst: <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/dist/keystone-jenkins.periodic.keystone.docs.grizzly.7.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/>\nGenerating doc/source/api/keystone.auth.controllers.rst\nGenerating doc/source/api/keystone.auth.core.rst\nGenerating doc/source/api/keystone.auth.plugins.password.rst\nGenerating doc/source/api/keystone.auth.plugins.token.rst\nGenerating doc/source/api/keystone.auth.routers.rst\nGenerating doc/source/api/keystone.auth.token_factory.rst\nGenerating doc/source/api/keystone.catalog.backends.kvs.rst\nGenerating doc/source/api/keystone.catalog.backends.sql.rst\nGenerating doc/source/api/keystone.catalog.backends.templated.rst\nGenerating doc/source/api/keystone.catalog.controllers.rst\nGenerating doc/source/api/keystone.catalog.core.rst\nGenerating doc/source/api/keystone.catalog.routers.rst\nGenerating doc/source/api/keystone.clean.rst\nGenerating doc/source/api/keystone.cli.rst\nGenerating doc/source/api/keystone.common.bufferedhttp.rst\nGenerating doc/source/api/keystone.common.cms.rst\nGenerating doc/source/api/keystone.common.config.rst\nGenerating doc/source/api/keystone.common.controller.rst\nGenerating doc/source/api/keystone.common.dependency.rst\nGenerating doc/source/api/keystone.common.kvs.rst\nGenerating doc/source/api/keystone.common.ldap.core.rst\nGenerating doc/source/api/keystone.common.ldap.fakeldap.rst\nGenerating doc/source/api/keystone.common.logging.rst\nGenerating doc/source/api/keystone.common.manager.rst\nGenerating doc/source/api/keystone.common.models.rst\nGenerating doc/source/api/keystone.common.openssl.rst\nGenerating doc/source/api/keystone.common.router.rst\nGenerating doc/source/api/keystone.common.serializer.rst\nGenerating doc/source/api/keystone.common.sql.core.rst\nGenerating doc/source/api/keystone.common.sql.legacy.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.manage.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.001_add_initial_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.002_token_id_hash.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.003_token_valid.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.004_undo_token_id_hash.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.005_set_utf8_character_set.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.006_add_policy_table.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.007_add_domain_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.008_create_default_domain.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.009_normalize_identity.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.010_normalize_identity_migration.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.011_endpoints_v3.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.012_populate_endpoint_type.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.013_drop_legacy_endpoints.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.014_add_group_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.015_tenant_to_project.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.016_normalize_domain_ids.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.017_membership_role.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.018_add_trust_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.019_fixup_role.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.020_migrate_metadata_table_roles.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.021_add_trust_to_token.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.022_move_legacy_endpoint_id.rst\nGenerating doc/source/api/keystone.common.sql.migration.rst\nGenerating doc/source/api/keystone.common.sql.nova.rst\nGenerating doc/source/api/keystone.common.sql.util.rst\nGenerating doc/source/api/keystone.common.systemd.rst\nGenerating doc/source/api/keystone.common.utils.rst\nGenerating doc/source/api/keystone.common.wsgi.rst\nGenerating doc/source/api/keystone.config.rst\nGenerating doc/source/api/keystone.contrib.access.core.rst\nGenerating doc/source/api/keystone.contrib.admin_crud.core.rst\nGenerating doc/source/api/keystone.contrib.ec2.backends.kvs.rst\nGenerating doc/source/api/keystone.contrib.ec2.backends.sql.rst\nGenerating doc/source/api/keystone.contrib.ec2.core.rst\nGenerating doc/source/api/keystone.contrib.s3.core.rst\nGenerating doc/source/api/keystone.contrib.stats.backends.kvs.rst\nGenerating doc/source/api/keystone.contrib.stats.core.rst\nGenerating doc/source/api/keystone.contrib.user_crud.core.rst\nGenerating doc/source/api/keystone.controllers.rst\nGenerating doc/source/api/keystone.exception.rst\nGenerating doc/source/api/keystone.identity.backends.kvs.rst\nGenerating doc/source/api/keystone.identity.backends.ldap.core.rst\nGenerating doc/source/api/keystone.identity.backends.pam.rst\nGenerating doc/source/api/keystone.identity.backends.sql.rst\nGenerating doc/source/api/keystone.identity.controllers.rst\nGenerating doc/source/api/keystone.identity.core.rst\nGenerating doc/source/api/keystone.identity.routers.rst\nGenerating doc/source/api/keystone.middleware.auth_token.rst\nGenerating doc/source/api/keystone.middleware.core.rst\nGenerating doc/source/api/keystone.middleware.ec2_token.rst\nGenerating doc/source/api/keystone.middleware.s3_token.rst\nGenerating doc/source/api/keystone.openstack.common.gettextutils.rst\nGenerating doc/source/api/keystone.openstack.common.importutils.rst\nGenerating doc/source/api/keystone.openstack.common.jsonutils.rst\nGenerating doc/source/api/keystone.openstack.common.policy.rst\nGenerating doc/source/api/keystone.openstack.common.setup.rst\nGenerating doc/source/api/keystone.openstack.common.timeutils.rst\nGenerating doc/source/api/keystone.openstack.common.version.rst\nGenerating doc/source/api/keystone.policy.backends.rules.rst\nGenerating doc/source/api/keystone.policy.backends.sql.rst\nGenerating doc/source/api/keystone.policy.controllers.rst\nGenerating doc/source/api/keystone.policy.core.rst\nGenerating doc/source/api/keystone.policy.routers.rst\nGenerating doc/source/api/keystone.routers.rst\nGenerating doc/source/api/keystone.service.rst\nGenerating doc/source/api/keystone.test.rst\nGenerating doc/source/api/keystone.token.backends.kvs.rst\nGenerating doc/source/api/keystone.token.backends.memcache.rst\nGenerating doc/source/api/keystone.token.backends.sql.rst\nGenerating doc/source/api/keystone.token.controllers.rst\nGenerating doc/source/api/keystone.token.core.rst\nGenerating doc/source/api/keystone.token.routers.rst\nGenerating doc/source/api/keystone.trust.backends.kvs.rst\nGenerating doc/source/api/keystone.trust.backends.sql.rst\nGenerating doc/source/api/keystone.trust.controllers.rst\nGenerating doc/source/api/keystone.trust.core.rst\nGenerating doc/source/api/keystone.trust.routers.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-grizzly/precise36\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-grizzly/precise36/7\n[SCP] Copying console log.\n\n\n','<873669428.64.1386828171008.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1225623484.3117823.1349344966904.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-04 06:02:46',-14400,'2012-10-04 10:02:46',NULL,'[openstack-dev] SmokeStack broken?','\n\n----- Original Message -----\n> From: \"Clark Boylan\" <clark.boylan at gmail.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Tuesday, October 2, 2012 11:18:32 PM\n> Subject: Re: [openstack-dev] SmokeStack broken?\n> \n> On 10/02/2012 03:10 PM, Dan Prince wrote:\n> > \n> > \n> > ----- Original Message -----\n> >> From: \"Sean Dague\" <sdague at linux.vnet.ibm.com>\n> >> To: OpenStack-dev at lists.openstack.org\n> >> Sent: Tuesday, October 2, 2012 12:11:42 AM\n> >> Subject: [openstack-dev] SmokeStack broken?\n> >>\n> >> SmokeStack seems to be acting up and failing on it\'s unit tests\n> >> runs,\n> >> which has left a string of -1 on all the reviews today. Anyone\n> >> have\n> >> the\n> >> ability to poke at it?\n> > \n> > Hi Sean,\n> > \n> > I\'m on travel and just now got some time to have a look at this.\n> > \n> > The failed tests were getting errors trying to create the virtual\n> > env for testing. The following error seems to be the root cause:\n> > \n> >     (Currently using distribute 0.6.24\n> >     (/tmp/smokestack_unittest/nova_source/dist/nova-2013.1/.tox/py27/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg))\n> >     Complete output from command python setup.py egg_info:\n> >     The required version of distribute (>=0.6.28) is not available,\n> > \n> > The failures started happening when we recently reverted this\n> > commit:\n> > \n> > https://github.com/openstack/nova/commit/6e9f3bb10a105411b0eb3e8f22a252af0784cb0b\n> > \n> > Note the -1 there in the Gerrit review from SmokeStack. Since the\n> > failure was ignored some reviews today got marked with -1.\n> > Appologies for that... I usually try to react to this sort of\n> > thing faster... that said the failure is valid although it is\n> > somewhat related to the tox version being used as well.\n> > \n> > Digging into it a bit... it looks like we now require a more recent\n> > distribute version to run Nova tests. This is because Python-MySQL\n> > explicitly requires 0.6.28... so I think we should now update our\n> > dependency in test-requires to this:\n> > \n> > https://review.openstack.org/13972\n> > \n> > I was also able to work around the issue by installing a newer\n> > version of tox (1.4.2) which automatically requires the more\n> > recent distribute.\n> The fix that was used on the Jenkins slaves was to install virtualenv\n> 1.8 or newer, https://review.openstack.org/#/c/13804/. Since\n> virtualenv\n> bundles distribute we had to use a version of virtualenv that\n> included\n> distribute 0.6.28. (installing newer tox may install newer virtualenv\n> as\n> well).\n\nThanks for the info Clark. I tested it a bit further and it appears that just simply updating test-requires to require distribute 0.6.28 alone doesn\'t quite seem to fix it because as you said virtualenv bundles distribute. Users would still need to update their virtualenv installation as well. When using tox (which is usually pre-installed) it would be nice if we had a good place to check for this. Any ideas on how we might make this more user friendly?\n\nDan\n\n> \n> Clark\n> > \n> > My guess is that other Nova devs might hit this same failure if\n> > they try and recreate their virtual env\'s with the new version of\n> > pip-requires.\n> > \n> > Dan\n> > \n> >> The -1 is probably shying a lot of folks off\n> >> reviewing patches which are actually fine.\n> >>\n> >> 	-Sean\n> >>\n> >> --\n> >> Sean Dague\n> >> IBM Linux Technology Center\n> >> email: sdague at linux.vnet.ibm.com\n> >> alt-email: sldague at us.ibm.com\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<506B6838.3040601@gmail.com>',NULL),('<1225678325.7.1367561301756.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-03 06:08:21',0,'2013-05-03 06:08:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly-centos6 #3','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/3/>\n\n------------------------------------------\n[...truncated 5092 lines...]\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:14,922 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:14,923 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:14,925 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,927 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14,928 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-05-03 06:08:14,930 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-05-03 06:08:14,931 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:08:14  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-05-03 06:08:14,932 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:14    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-05-03 06:08:14,933 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:14,949 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.948346\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.948346\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14,951 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,952 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14,954 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:14,957 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14,960 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.957226\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.957226\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14,961 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,963 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14,964 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:14,966 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,968 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:14,971 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14,974 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.971026\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.971026\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14,975 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,977 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14,978 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:14,980 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,982 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:14,985 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14,988 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.985255\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:14.985255\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:14,990 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,991 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14,992 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:14,994 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:14,996 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:14    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:14,999 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:14     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-05-03 06:08:15,003 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:15     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-05-03 06:08:15,006 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:15.003630\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-05-03T06:08:15.003630\', resource_metadata={}) from 0 transformer\n2013-05-03 06:08:15,008 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:15,009 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:15,011 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-05-03 06:08:15,013 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-05-03 06:08:15,014 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-05-03 06:08:15    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.198s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.2\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.centos6.3\ncliff==1.3.3\ncmd2==0.6.5.1\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a96.gcc938e2\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a491.g8bb1cc2\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==1.0.0\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.hB4vN5IcY2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly-centos6/3\n[SCP] Copying console log.\n\n\n','<118246164.559.1367475111417.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1225752882.31.1382163093453.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-19 06:11:33',0,'2013-10-19 06:11:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #34','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/34/>\n\n------------------------------------------\n[...truncated 1287 lines...]\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e48b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e48b10>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46c1710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46c1710>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-719c565b-0788-47a1-9c3a-48014a3e20a7\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2013-10-18T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'18\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'18\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2013-10-20T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'20\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'20\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2013-10-21T06:11:01+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'21\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2013-10-21T06:11:01-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'21\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2013-10-22T06:11:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4802110>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1af56d0>\niso8601.iso8601: DEBUG: Got None for \'second_fraction\' with default None\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 70.88 secs:\n    14.83    TestGlanceControl.test_bouncing\n    14.26    TestGlanceControl.test_reload\n    14.00    TestGlanceControl.test_respawn\n    13.91    TestBinGlanceCacheManage.test_queue\n    13.88    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 932 tests in 607.498s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-34\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.5\njsonschema==2.1.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.SvJIUXKcrR\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/34/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-10/34\n[SCP] Copying console log.\n\n\n','<594779491.24.1382076713275.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<122606E3-AC13-4E4A-BE42-D22725A8E0DA@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-05-21 11:03:39',-25200,'2014-05-21 18:03:39',NULL,'[Openstack-operators] Creating nova instance without backing\n	image','No, I just looked through nova.conf reference and glance-api.conf reference and there is no option for NOT using the backing image.\n\nWhen migrating a bare metal system, you should really ensure that things like logs are purged, even home directories, etc.\nBest practice to have /var mounted on a separate partition too.\nOn May 21, 2014, at 10:41 AM, Daniel Speichert <daniel at speichert.pl> wrote:\n\n> Hi,\n> \n> In our OpenStack installation (Havana, RDO), we use Ceph as storage as\n> Nova, Glance and Cinder backend.\n> \n> On compute nodes, instance\'s disks are kept on Ceph but base images are\n> copied from Glance (Ceph) to local disk. This works well with small\n> images of OS\'s.\n> \n> However, if we upload a big image (e.g. migrating bare hardware system\n> to the cloud) that is only used by one instance, the image becomes the\n> backing file stored locally on the compute node. Here, the compute node\n> hit disk space limit because we expect all the data to reside on Ceph.\n> \n> Is there any way to tell Nova to not use backing image for an instance?\n> Maybe there exists a special image property to set that tells Nova to\n> copy the whole image, which would put it entirely in Ceph without a\n> backing file?\n> \n> I hope this use case makes sense for and I\'d appreciate if you had any\n> suggestions how to resolve this issue.\n> \n> Best,\n> Daniel\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<537CE551.2000607@speichert.pl>',NULL),('<1226305169.67756.1368430686824.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-05-13 09:38:06',7200,'2013-05-13 07:38:06',NULL,'[Openstack-operators] Problem with multiple nova-consoleauth','Hi, \n\n\nWe are running : \n\n\n    * 2 memcached servers on dedicated nodes \n    * 2 nova-consoleauth with memcached_servers flag in nova.conf (don\'t forget to install python-memcache on nova-consoleauth nodes) \n    * 2 nova-html5proxy in load balancing with HAproxy in front-end. \n\nIt works fine. \n\n\nCheers ! \n\n\nEmilien \n\n\n----- Original Message -----\n\nFrom: \"Juan Jos? Pavlik Salles\" <jjpavlik at gmail.com> \nTo: \"Sam Morrison\" <sorrison at gmail.com> \nCc: openstack-operators at lists.openstack.org \nSent: Monday, May 13, 2013 2:37:56 AM \nSubject: Re: [Openstack-operators] Problem with multiple nova-consoleauth \n\nGreat, thank guys!!, Should i run one memcache server??? instead of running many of them, one in every compute node, using the configuration John Dewey says. \n\n\n2013/5/12 Sam Morrison < sorrison at gmail.com > \n\n\n\nIf you run multiple consoleauths they need to talk to the same memcached server. \n\nSam \n\n\nOn 12/05/2013, at 11:46 AM, Juan Jos? Pavlik Salles < jjpavlik at gmail.com > wrote: \n\n\n<blockquote>\n\n\n\nHi guys, on friday i was trying to reach my vms through novnc proxy and i ran into some kind of odd behaviour. One every two attempts were successfull so we started watching logs. after a couple of hours stopping and starting services we realized that this strange behaviour was due to we had two nova-consoleauth instances running, one per compute node. We stopped one of the instances a everything started to work just fine, even both novncproxies. \nI found this https://bugs.launchpad.net/nova/+bug/989337 but it\'s suppossed to be fixed in folsom, and i\'m running grizzly. \n\nShould i run just one instance of nova-consoleauth? \n_______________________________________________ \n\nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n\n\n\n\n</blockquote>\n\n\n\n\n-- \nPavlik Salles Juan Jos? \n\n_______________________________________________ \nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130513/1e4f39f6/attachment.html>\n\n','<CAKCETkefT4oxv_WQ2hcxkBGtwZKmnGQy0kAXdJdEYzf7AxaAOQ@mail.gmail.com>',NULL),('<1226375091.1651506.1404269543321.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-01 22:52:23',-14400,'2014-07-02 02:52:23',NULL,'[openstack-dev] [Horizon] Custom Gerrit Dashboard for Juno-2','Heya,\n\nI was trying to help with the Horizon Juno-2 reviews, and found the launchpad link\n(https://launchpad.net/horizon/+milestone/juno-2) a bit unhelpful in figuring out\nwhich items actually need reviews, as some of the items marked \'Needs Code Review\'\nare works in progress, or already reviewed and waiting for approval, or abandoned.\n\nSo I\'ve created a custom Gerrit dashboard for Horizon Juno-2 blueprints and bugs:\n\nhttp://goo.gl/hmhMXW (the long URL is excessively long)\n\nIt is limited to reviews that are related to Juno-2 blueprints and bugs, and\nrelies on the topic branch being set correctly.  The top section lists changes that\nonly need a +A.  The bottom section lists changes that are waiting for a +2 review,\nand includes changes with -1s for informational purposes (it excludes changes with\na -2, though).\n\nThe URL was created using Sean Dague\'s gerrit-dash-creator using a script-generated\ndashboard definition that takes in a milestone argument and scrapes the appropriate\nHorizon launchpad milestone page.  That means that the above URL won\'t update if\nand when items are added or removed from Juno-2.  However, it can be easily\nregenerated; and can be run for Juno-3 and future milestones.\n\nHope this is helpful!\n\n\nThanks,\nTzu-Mainn Chen\n\n\n','<733804476.1648200.1404268573226.JavaMail.zimbra@redhat.com>',NULL),('<1226438552.27571530.1407581289519.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 06:48:09',-14400,'2014-08-09 10:48:09',NULL,'[openstack-dev] [all] The future of the integrated release','\n\n> > We seem to be unable to address some key issues in the software we\n> > produce, and part of it is due to strategic contributors (and core\n> > reviewers) being overwhelmed just trying to stay afloat of what\'s\n> > happening. For such projects, is it time for a pause ? Is it time to\n> > define key cycle goals and defer everything else ?\n> \n> I think it\'s quite reasonable for a project to set aside some time to\n> focus on stability, whether that is a whole release cycle or just a\n> milestone. However, I think your question here is more about\n> OpenStack-wide issues, and how we enco^D^D^D^D whether we can require\n> integrated projects that are seen as having gate-affecting instability\n> to pause and address that.\n> \n> > On the integrated release side, \"more projects\" means stretching our\n> > limited strategic resources more. Is it time for the Technical Committee\n> > to more aggressively define what is \"in\" and what is \"out\" ? If we go\n> > through such a redefinition, shall we push currently-integrated projects\n> > that fail to match that definition out of the \"integrated release\" inner\n> > circle ?\n> \n> \"The integrated release\" is an overloaded term at the moment. Outside\n> of the developer community, I see it often cited as a blessing of a\n> project\'s legitimacy and production-worthiness. While I feel that a\n> non-production-ready project should not be \"in the integrated\n> release\", this has not been upheld as a litmus test for integration in\n> the past. Also, this does not imply that non-integrated projects\n> should not be used in production. I\'ve lost track of how many times\n> I\'ve heard someone say, \"Why would I deploy Ironic when it hasn\'t\n> graduated yet.\"\n> \n> Integration is foremost an artifact of our testing and development\n> processes -- an indication that a project has been following the\n> release cadence, adheres to cross-project norms, is ready for\n> cogating, and can be counted on to produce timely and stable builds at\n> release time. This can plainly be seen by looking at the criteria for\n> incubation and integration in our governance repo [1]. As written\n> today, this does not have anything to do with the technical merit or\n> production-worthiness of a project. It also does not have anything to\n> do with what \"layer\" the project sits at -- whether it is IaaS, PaaS,\n> or SaaS does not dictate whether it can be integrated.\n> \n> The TC has begun to scrutinize new projects more carefully on\n> technical grounds, particularly since some recently-integrated\n> projects have run into scaling limitations that have hampered their\n> adoption. I believe this sort of technical guidance (or curation, if\n> you will) is an essential function of the TC. We\'ve learned that\n> integration bestows legitimacy, as well as assumptions of stability,\n> performance, and scalability, upon projects which are integrated.\n> While that wasn\'t the intent, I think we need to accept that that is\n> where we stand. We will be faced with some hard decisions regarding\n> projects, both incubated and already integrated, which are clearly not\n> meeting those expectations today.\n\nHow does this relate to the recent gap analysis undertaken by the\nTC for already integrated projects, in order to measure their status\nagainst the steadily rising bar for integration?\n\nThat aforementioned process is actually still ongoing, with the TC\ndoing progress reviews against the projects\' action plans throughout\nthe Juno cycle.\n\nCheers,\nEoghan\n\n\n','<CAExZKErYdLZ7+JxKW4Nija36svEbXCxsnL5N2SGdK31Bw57m5g@mail.gmail.com>',NULL),('<1227061164.5400089.1386791633566.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 14:53:53',-18000,'2013-12-11 19:53:53',NULL,'[openstack-dev] [TripleO][Tuskar] Terminology','> >Hi,\n> >\n> >I\'m trying to clarify the terminology being used for Tuskar, which may be\n> >helpful so that we\'re sure\n> >that we\'re all talking about the same thing :)  I\'m copying responses from\n> >the requirements thread\n> >and combining them with current requirements to try and create a unified\n> >view.  Hopefully, we can come\n> >to a reasonably rapid consensus on any desired changes; once that\'s done,\n> >the requirements can be\n> >updated.\n> >\n> >* NODE a physical general purpose machine capable of running in many roles.\n> >Some nodes may have hardware layout that is particularly\n> >       useful for a given role.\n> >\n> >     * REGISTRATION - the act of creating a node in Ironic\n> >\n> >     * ROLE - a specific workload we want to map onto one or more nodes.\n> >     Examples include \'undercloud control plane\', \'overcloud control\n> >       plane\', \'overcloud storage\', \'overcloud compute\' etc.\n> >\n> >         * MANAGEMENT NODE - a node that has been mapped with an undercloud\n> >         role\n> >         * SERVICE NODE - a node that has been mapped with an overcloud role\n> >            * COMPUTE NODE - a service node that has been mapped to an\n> >            overcloud compute role\n> >            * CONTROLLER NODE - a service node that has been mapped to an\n> >            overcloud controller role\n> >            * OBJECT STORAGE NODE - a service node that has been mapped to\n> >            an overcloud object storage role\n> >            * BLOCK STORAGE NODE - a service node that has been mapped to an\n> >            overcloud block storage role\n> >\n> >         * UNDEPLOYED NODE - a node that has not been mapped with a role\n> >              * another option - UNALLOCATED NODE - a node that has not been\n> >              allocated through nova scheduler (?)\n> >                                   - (after reading lifeless\'s explanation,\n> >                                   I agree that \"allocation\" may be a\n> >                                      misleading term under TripleO, so I\n> >                                      personally vote for UNDEPLOYED)\n> >\n> >     * INSTANCE - A role deployed on a node - this is where work actually\n> >     happens.\n> >\n> >* DEPLOYMENT\n> >\n> >     * SIZE THE ROLES - the act of deciding how many nodes will need to be\n> >     assigned to each role\n> >           * another option - DISTRIBUTE NODES (?)\n> >                                 - (I think the former is more accurate, but\n> >                                 perhaps there\'s a better way to say it?)\n> >\n> >     * SCHEDULING - the process of deciding which role is deployed on which\n> >     node\n> >\n> >     * SERVICE CLASS - a further categorization within a service role for a\n> >     particular deployment.\n> >\n> >          * NODE PROFILE - a set of requirements that specify what\n> >          attributes a node must have in order to be mapped to\n> >                           a service class\n> >\n> >\n> >\n> >Does this seem accurate?  All feedback is appreciated!\n> >\n> >Mainn\n> >\n> \n> Thanks for doing this! Presumably this is going to go on a wiki where\n> we can look at it forever and ever?\n\n\nYep, if consensus is reached, I\'d replace the current tuskar glossary on the wiki with this\n(as well as update the requirements).\n\nMainn\n\n\n> --\n> Jordan O\'Mara <jomara at redhat.com>\n> Red Hat Engineering, Raleigh\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20131211194911.GF17163@redhat.com>',NULL),('<122724688.7.1380434575423.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-29 06:02:55',0,'2013-09-29 06:02:55',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #29','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/29/>\n\n\n\n','<810559356.97.1380261813239.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1228345693.10.1381732110396.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-14 06:28:30',0,'2013-10-14 06:28:30',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #36','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/36/>\n\n------------------------------------------\n[...truncated 21115 lines...]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\nInitialized empty Git repository in /tmp/tempest-unitDYj4lR/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unit3o1doc/.git/\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          195.590\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  172.902\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  71.949\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        39.385\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        35.715\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_manual_disk_config[gate]   34.635\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_confirm[gate,smoke]              32.432\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     30.176\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     28.948\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       26.360\n\n----------------------------------------------------------------------\nRan 1357 tests in 1257.855s\n\nOK (skipped=65)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-576667-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-576667.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-576667/36/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1583079047.1.1381472978133.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<12284555.6562163.1353663984215.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 04:46:24',-18000,'2012-11-23 09:46:24',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n> > > I really don\'t see much issue with ceilometer just doing\n> > > those few things directly. The only private implementation\n> > > assumption you\'d be making about the Nova libvirt driver is\n> > > that the libvirt VM name is the same as the instance name.\n> > \n> > But just to confirm I understand the suggestion, by *direct* usage\n> > do you mean simply calling the currently installed nova virt code\n> > but at a level that is unlikely to change? (say by pushing some\n> > internals of the driver implementation into the driver API)\n> \n> Nope, don\'t use any code - just have your own code for talking\n> directly to libvirt and other hypervisors.\n\nOK. Granted we could do a greenfield re-write of the nova code\nthat talks to the hypervisors, but realistically the likelihood\nis that ctrl-c/ctrl-v would provide the starting point. \n\n(So it smells a little like the \"copy and distill\" approach\nmentioned earlier, even if tightly constrained in scope)\n\nSeems to me this involves unnecessary duplication and leakage\nof nova concerns into ceilo. If a bug is discovered on the nova\nside, would we expect the nova dev doing the fix to go hunt in\nthe ceilo codebase to see if the fix needed to be ported there too?\n\nOr is the thought that this code is so small (3% or whatever)\nand thinly layered over the hypervisor, that its likely to have\nhad all the issues already smoked out?\n\n> (And for clarity - this is if ceilometer must do the polling\n> directly. I still think notifications are the way to go for now)\n\nUnderstood.\n\n> > > > There\'s been a fair amount of fuzziness around the\n> > > > distinction between instrumentation and monitoring, but\n> > > > this falls into the latter camp for me. Its not so much\n> > > > about the internal dynamics of nova, as the user-visible\n> > > > behavior (e.g. is my instance running hot or am I pushing\n> > > > loads of data through the network, as opposed how long\n> > > > did that API call to update the instance take to service\n> > > > end-to-end or how many connections are in that pool).\n> > > \n> > > Metering vs monitoring/instrumentation, not monitoring vs\n> > > instrumentation :)\n> > \n> > I kinda see the split more as metering/monitoring vs\n> > instrumentation.\n> \n> I don\'t see why.\n\nBacause:\n\n(a) Metering and user-oriented monitoring are conceptually similar,\n    in that both ask questions about the user-view of cloud resources.\n    Metering asks about who\'s using these resources and for how long,\n    monitoring asks how these resources are doing.\n\nand:\n\n(b) The data produced by metering and user-oriented monitoring\n    are often derived from the same measurements, e.g. the CPU\n    time exposed by libvirt would be reported by metering as the\n    cumulative cpu_time meter, and by monitoring as the\n    CPUUtilization metric. So there seems to be an opportunity\n    here to avoid duplicating the measurement.\n\n> Timeliness is a concern for user-oriented monitoring\n> but not for metering.\n\nNot as central a concern, but metering still requires somewhat of\na regular cadence.\n \n> Timeliness is the issue in this discussion.\n\nYes ... and I see this as an implementation challenge, as opposed\nto a reason for ceilo not to be concerned with the user-oriented\nmonitoring aspect.\n\n> So, they\'re clearly not the same thing for the purposes of this\n> discussion.\n\nI didn\'t intend to present them as the *same thing* necessarily,\nmore to suggest that they share lots of commonality (certainly\nat a conceptual level, also potentially in implementation). \n \n> > Well, actually more like metering/user-oriented-monitoring vs\n> > cloud-operator-oriented-monitoring/instrumentation.\n> > \n> > Currently ceilo is aiming to at least address both metering and\n> > user-oriented-monitoring, and possibly more in time.\n> > \n> > > If we were just designing a solution for metering, would we\n> > > go for the notifications option?\n> > \n> > Probably, but the scope of ceilo has widened a bit from pure\n> > metering.\n> \n> Right. From a far remove, that looks like a mistake at this early\n> stage.\n\nOK, well its a point we\'ve gotten to after a lot of discussion\n(at the summit and even prior to that) and the widening of scope\nwas also made clear at the TC meeting that endorsed ceilo for\nincubation.\n\nAre you advocating for (a) a strategic re-narrowing of scope, or\n(b) a tactical decision to concentrate on just metering for now?\n\n(Or something else?)\n \n> As Sandy rightly says, if we just focused on metering, then the\n> conclusion is simple - improve the notifications infrastructure. If\n> Ceilometer focused on its original mission, forward progress would be\n> easier.\n\nOK, so this feels like avoiding a technical challenge by narrowing\nthe project scope. Which would be fine if the problem was really\nnasty and intractable, but I\'m not sure that\'s the case here.\n\nCheers,\nEoghan\n\n\n','<1353652009.14377.57.camel@sorcha>',NULL),('<1228BCA3-93E9-4898-948B-F31CBA0CF573@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-06 11:31:31',3600,'2014-11-06 10:31:31',NULL,'[openstack-dev] [oslo][context] oslo.context repository review\n	request','\nOn Nov 6, 2014, at 11:13 AM, Julien Danjou <julien at danjou.info> wrote:\n\n> On Wed, Nov 05 2014, Davanum Srinivas wrote:\n> \n>> Please see notes from Doug on the etherpad on why leaving it in\n>> oslo.log or oslo.utils was not considered.\n>> https://etherpad.openstack.org/p/kilo-oslo-library-proposals\n> \n> I only get that it might be related to db at some point, but I only\n> skimmed through the linked blueprint at it\'s not clear to me how that\n> prevent this to be in oslo.utils for example. Sorry to be a pain. :)\n\nThe main reasons for splitting code into its own library are dependency management, API ownership, the logical separation of the contents of the library within the application stack and between other libraries, and review ACLs within gerrit.\n\nWe have a couple of libraries (oslo.log and oslo.messaging) that want to specify an API via the context base class, so the class can?t live in either of those places.\n\nThe utils library is actually used by some of the clients now, so we need to be conscious of adding dependencies there. I don?t think context will bring in any real dependencies for now, but it also doesn?t seem to be a general-purpose utility. We?re going to need to add some thread-local caches for setting and fetching the current context, I think, either within context or in some of the other libraries with callbacks invoked by the context constructor. So for logical separation, a different library seemed to make more sense.\n\nIt?s also possible that the applications will find other uses for a shared context base class, and so we?ll want to build a review team for it that isn?t limited to the oslo-core team, but that?s less important than the logical considerations in my mind.\n\nDoug\n\n\n> \n> -- \n> Julien Danjou\n> -- Free Software hacker\n> -- http://julien.danjou.info\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<m2a9444owy.fsf@danjou.info>',NULL),('<1229091106.440.1367129232152.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:07:12',0,'2013-04-28 06:07:12',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-folsom #209','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/209/>\n\n\n\n','<466814129.390.1367042854173.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<122afd4db4fa47e7aef62709799b5755@BL2PR08MB051.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-20 19:44:52',0,'2013-07-20 19:44:52',NULL,'[openstack-dev] [Neutron] lbaas installation guide','Thanks Anne. That link does not work. Furthermore, Do we have a LBaas for compute node (nova)?\n\nFrom: Anne Gentle [mailto:annegentle at justwriteclick.com]\nSent: Saturday, July 20, 2013 5:41 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Neutron] lbaas installation guide\n\nTry this: https://wiki.openstack.org/wiki/Neutron/LBaaS/HowToRun. I have no idea how accurate but at least it was updated in April this year.\n\nOn Fri, Jul 19, 2013 at 9:26 PM, Qing He <Qing.He at radisys.com<mailto:Qing.He at radisys.com>> wrote:\nBy the way, I\'m wondering if lbaas has a separate doc somewhere else?\n\nFrom: Anne Gentle [mailto:anne at openstack.org<mailto:anne at openstack.org>]\nSent: Friday, July 19, 2013 6:33 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [Neutron] lbaas installation guide\n\nThanks for bringing it to the attention of the list -- I\'ve logged this doc bug. https://bugs.launchpad.net/openstack-manuals/+bug/1203230 Hopefully a Neutron team member can pick it up and investigate.\n\nAnne\n\nOn Fri, Jul 19, 2013 at 7:35 PM, Qing He <Qing.He at radisys.com<mailto:Qing.He at radisys.com>> wrote:\n\nIn the network installation guide( http://docs.openstack.org/grizzly/openstack-network/admin/content/install_ubuntu.html ) there is a sentence \"quantum-lbaas-agent, etc (see below for more information about individual services agents).\" in the pluggin installation section. However, lbaas is never mentioned again after that in the doc.\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nAnne Gentle\nannegentle at justwriteclick.com<mailto:annegentle at justwriteclick.com>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130720/acf99ebf/attachment.html>\n\n','<CAD0KtVGiKpCA39yyp8d2cLK8e5VQPCbfG9QcsSYu=GPYV9GpzA@mail.gmail.com>',NULL),('<1230597797.14.1385102825228.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-22 06:47:05',0,'2013-11-22 06:47:05',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-neutron-stable-havana #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-havana/2/>\n\n\n\n','<1446014331.6.1384930592889.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1231601248.218532.1383015275677.JavaMail.zimbra@tipit.net>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-10-28 21:54:35',-18000,'2013-10-29 02:54:35',NULL,'[OpenStack-Infra] Improving the way we handle Corporate CLAs','> I\'m hesitant to suggest that any of our CLAs solves any real problem\n> (after all, I\'m not a lawyer, so I only know what I\'ve heard them\n> say). That aside, I agree the member database sounds like it would\n> be a sane place to deal with that, but until we actually see the\n> source code for that site it\'s hard to be sure.\n\nI can speak to this a little bit. OpenStack.org already has the data model in place to handle agreements and contracts amongst user groups associated with an organization. The intention is to leverage this information to shape the user experience and drive data sharing amongst the OpenStack properties.  Extending a corporate CLA to the user base is a nominal change.\n\nSetting up a specific set of users that are tied to a particular company, with a particular set of permissions, is right in line for the vision we are working towards for OpenStack.org and the coming OpenID/OAuth setup.  Some of these pieces are in place already, but we can expect most of them to be ready when we launch with OpenID.  \n\nLong term, we aim to share this data, and more with all OpenStack web properties given the appropriate permissions.  For example, an OpenStack user employed by Tycoon Corp that logs into the Beijing User Group could receive a message prompting them to notify Tycoon Corp to update their CCLA to include them as a user that\'s authorized to commit code on their behalf.  \n\nOf course, with OAuth in place, pretty much any piece of data that OpenStack and your contributors authorize to share will be available. CCLAs and CLA controversy or usefulness aside, it\'s a good opportunity for OpenStack to drive development on your web properties with real and useful user data.\n\nThanks!\n\nJimmy McArthur / tipit.net <jimmy at tipit.net> \no: 512.481.1161 \nm: 512.965.4846 \n\n----- Original Message -----\n> From: \"Jeremy Stanley\" <fungi at yuggoth.org>\n> To: \"Stefano Maffulli\" <stefano at openstack.org>\n> Cc: openstack-infra at lists.openstack.org\n> Sent: Monday, October 28, 2013 6:09:19 PM\n> Subject: Re: [OpenStack-Infra] Improving the way we handle Corporate CLAs\n> \n> On 2013-10-28 10:00:03 -0700 (-0700), Stefano Maffulli wrote:\n> [...]\n> > Probably then we should keep the notion of the CCLA in the User/Member\n> > database then? The manager of the CCLA would click-sign the agreement on\n> > our site, we keep the historic record of that signature and the manager\n> > herself declares who works for her, authorized to commit. It would still\n> > not prevent people to commit code without a CCLA but I htink it would\n> > improve the situation. What do you think?\n> \n> I\'m hesitant to suggest that any of our CLAs solves any real problem\n> (after all, I\'m not a lawyer, so I only know what I\'ve heard them\n> say). That aside, I agree the member database sounds like it would\n> be a sane place to deal with that, but until we actually see the\n> source code for that site it\'s hard to be sure.\n> --\n> Jeremy Stanley\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n\n\n','<20131028230911.GD2304@yuggoth.org>',NULL),('<1233034235.2218351.1392295833479.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 07:50:33',-18000,'2014-02-13 12:50:33',NULL,'[openstack-dev] Version Discovery Standardization','Hi all,\n\nI am one of i think a number of efforts trying to make clients be interoperable between different versions of an API.\n\nWhat i would like to talk about specifically here are the inconsistencies in the version listing of the different servers when you query the root GET \'/\' and GET \'/vX\' address for versions. This is a badly formatted sampling of the policies out there: http://paste.openstack.org/show/64770/\n\nThis is my draft of a common solution https://wiki.openstack.org/wiki/VersionDiscovery which has some changes for everyone, but I at least hope can be a guide for new services and a target for the existing\n\nThere are a number of major inconsistencies that i hope to address:\n\n1. The \'status\' of an API. \n\nKeystone uses the word \'stable\' to indicate a stable API, there are a number of services using \'CURRENT\' and i\'m not sure what \'SUPPORTED\' is supposed to mean here. In general I think \'stable\' makes the most sense and in many ways keystone has to be the leader here as it is the first contact. Any ideas how to convert existing APIs to this scheme? \n\n2. HTTP Status\n\nSome services are 200, some 300. It also doesn\'t matter how many responses there are in this status. \n\n3. Keystone uses [\'versions\'][\'values\']\n\nYep. Not sure why that is. Sorry, we should be able to have a copy under \'values\' and one in the root \'versions\' simultaneously for a while and then drop the \'values\' in some future release. \n\n4. Glance does a version entry for each minor version. \n\nSeperate entries for v2.2, v2.1, v2.0. They all point to the same place so IMO this is unnecessary. \n\n5. Differences between entry in GET \'/\' and GET \'/vX\'\n\nThere is often a log more information in GET \'/vX\' like media-type that is not present in the root. I\'m not sure if this was on purpose but i think it easier (and less lookups) to have this information consistent.\n\n6. GET \'/\' is unrestricted. GET \'/vX\' is often token restricted. \n\nKeystone allows access to /v2.0 and /v3 but most services give a HTTP Unauthorized. This is a real problem for discovery because we need to be able to evaluate the endpoints in the service catalog. I think we need to make these unauthorized.\n\nPlease have a look over the wiki page and how it addresses the above and fits into the existing schemes and reply with any comments or problems that you see. Is this going to mess with any pre-existing clients?\n\nThen is there somewhere we can do \'new project guidelines\' that we can link this from?\n\n\nJamie\n\n\nPS. This is the script I used for the sampling if you want to test yourself: http://paste.openstack.org/show/65015/ it makes assumptions on URL structures and it won\'t pass code review.\n\n\n','<428148624.1556834.1392195815166.JavaMail.zimbra@redhat.com>',NULL),('<1233329351.25571789.1392629539235.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 09:32:19',0,'2014-02-17 09:32:19',NULL,'[openstack-dev] [Nova] bp proposal: filter based on the load\n averages of the host','yes I want to use the load average because it is based on more information than the cpu utilization. May be instead of to add a new field to hypervisor status I can create a new monitor or update the exiting one.\n\n----- Original Message -----\nFrom: \"yunhong jiang\" <yunhong.jiang at linux.intel.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Saturday, February 15, 2014 12:54:52 AM\nSubject: Re: [openstack-dev] [Nova] bp proposal: filter based on the load averages of the host\n\nOn Fri, 2014-02-14 at 15:29 +0000, sahid wrote:\n> Greetings,\n> \n> I would like to add a new filter based on the load averages.\n> \n> This filter will use the command uptime and will provides an option to choice a\n> period between 1, 5, and 15 minutes and an option to choice the max load\n> average (a float between 0 and 1).\n> \n> Why:\n>   During a scheduling it could be useful to exclude a host that have a too\n> heavy load and the command uptime (available in all linux system) \n> can return a load average of the system in different periods.\n> \n> About the implementation:\n>   Currently \'all\' drivers (libvirt, xenapi, vmware) supports a method\n> get_host_uptime that returns the output of the command \'uptime\'. We have to add\n> in compute/stats.py a new method calculate_loadavg() that returns based on the\n> output of driver.get_host_uptime() from compute/ressource_tracker.py a well\n> formatted tuple of load averages for each periods. We also need to update\n> api/openstack/compute/contrib/hypervisors.py to take care of this new\n> field.\n> \n>   The implementation will be divided in several parts:\n>     * Add to host_manager the possibility to get the loads_averages\n>     * Implement the filter based on this new property\n>     * Implement the filter with a per-aggregate configuration\n> \n> The blueprint: https://blueprints.launchpad.net/nova/+spec/filter-based-uptime\n> \n> I will be happy to get any comments about this filter, perharps it is not implemented\n> yet because of something I didn\'t see or my thinking of the implementation is wrong.\n> \n> PS: I have checked metrics and cpu_resource but It does not get an averages of the\n> system load or perhaps I have not understand all.\n> \n> Thanks a lot,\n> s.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI think load average has more than CPU, you need consider like I/O\nusage, or even other metrics. Maybe you can have a look at the\nhttps://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling ?\n\nAlso IMHO the policy of \"exclude a host that have a too heavy load\" is\nnot so clean, would it be better to keep the usage as a scheduler\nweight?\n\nThanks\n--jyh\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1392422092.5487.9.camel@yjiang5-linux1>',NULL),('<1233985293.2873825.1353066243842.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 06:44:03',-18000,'2012-11-16 11:44:03',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction	going forward','\n\n> >> We don\'t *have* to use rabbit to handle the notifications. The\n> >> notification system could easily be extended to allow different\n> >> event types to use different notifiers. For example, billing\n> >> events\n> >> could go to rabbit while monitoring/lifecycle events could go to a\n> >> log file. Or, if we wanted to introduce a debugging event, that\n> >> could send to statsd (or something) directly as it strips out the\n> >> cruft from the message.\n> \n> >Yes, so in ceilometer we\'ve been making small steps towards that\n> >idea with the concept of multiple publishers and transformers.\n> >So a transformer would know how to distill what a publisher needs\n> >from the raw data (strip out the cruft & massage into the expected\n> >format) and then the publisher knows how to emit the data via\n> >some conduit (over rabbit, or a UDP packet for stats, an RRD file,\n> >a CloudWatch PutMetricData call, etc.).\n> >\n> > So I\'m thinking we\'re not a million miles from each other on that\n> > score, other than I had been assuming the publishers would live\n> > in ceilo, and it would understand their requirements in terms of\n> > cadence etc.\n> > \n> > Were you more thinking of this logic living elsewhere?\n> \n> So this should be a Ceilometer notifier, that lives in the Ceilometer\n> code base and is a nova.conf --notification_driver setting for\n> whomever deploys it. This implies there are two ways to get\n> notifications out of Nova:\n> 1. via the Rabbit Notifier with an external Worker/Consumer\n> (preferred for monitoring/usage/billing)\n> 2. via a specific Notifier (like\n> https://github.com/openstack/nova/blob/master/nova/openstack/common/notifier/log_notifier.py)\n> \n> Stuff such as converting format and varying polling rates seems to be\n> something external to nova. Since the system will only issue\n> notifications at the rate they occur. Higher sampling rates I think\n> fall into the instrumentation category and should be dealt with\n> separately.\n\nOK, I think we need to distinguish an (at least blurry) line between\ninstrumentation and monitoring.\n\nFor me monitoring is mostly about coarse-grained observables that\nallow user-oriented questions to be asked about cloud resources:\n\n - are my instances running hot?\n\n - are my volumes falling behind with queued I/O?\n\n - is my load balancer spitting out many 503s?\n\n... etc.\n\nWhereas instrumentation to me implies much more internal-facing\nand fine-grained concerns such as:\n\n - what\'s the fault-rate & latency for a particular API?\n\n - how much time is being spent accessing the DB?\n\n - how many idle connections are currently in some pool? \n\nI\'m maybe stating the obvious above, but the point is that its\nthe type of question being asked that distinguishes monitoring\nfrom instrumentation, not the sampling rate.\n\nFor certain types of monitoring, I think we do need relatively\nhigh sampling rates (e.g. once or twice a minute) that are near\nconstant (61s, 59s, 62s, ... as opposed to 45s, 75s, 52s, ...).\nIn that case, I\'m not sure we can rely on the cadence of the \nnotifications issued by a busy nova compute service. \n\n\n> >Certainly there would still be some time sensitivity, particularly\n> >for metrics feeding into near-realtime monitoring. So for metering\n> >feeding into non-realtime consumers (just as billing), we can\n> >tolerate a bit of irregularity in the cadence and some delays in\n> >the pipeline, as long as we maintain completeness. Whereas for\n> >monitoring, we need to get at that data while its still fresh and\n> >ensure its sampled at a near-constant rate. \n> \n> Sounds like instrumentation to me.\n\nSee above, could be considered instrumentation or monitoring IMO,\ndepending on the granularity of the question being asked.\n\n\n> >> Also, they are ancillary to the task at hand (providing a cloud\n> >> service) so their failure should not bring down the system. Which\n> >> is\n> >> why a queue-based approach seems the logical choice. Having nova\n> >> call out seems wrong and if it did, it belongs as a new rabbit\n> >> notifier where the person deploying that solution takes all\n> >> responsibility.\n> \n> >True that, we certainly need to be cognizant of the load imposed\n> >on a possibly degraded system potentially making things worse.\n> >Hence the leeriness about garnering the info ceilo needs from\n> >the public nova-api.\n> \n> The public api has no place for this stuff. I must have missed it,\n> but where was that being proposed? Hitting HTTP for metrics is just\n> wrong.\n\nYep, I think you\'re right about that. We kicked around some ideas\nearlier on this thread that involved hitting nova-api, but I think\nwe\'re mostly agreed that\'s not the way to go. \n\n\n> >> The existing information gathered from the hypervisors could\n> >> easily\n> >> be extended with optional sections to cover all use cases. Much\n> >> the\n> >> same way MP3 and JPG has optional data blocks. Notifications do\n> >> not\n> >> use the Nova RPC protocol and should be versioned separately from\n> >> it. The entire structure of the notification should be changed to\n> >> allow for these \"optional\" blocks ... not only for flexibility,\n> >> but\n> >> to reduce the already monstrous payload size (do we need to do 2-3\n> >> db accesses every time we send a notification?)\n> \n> >So with nova-compute losing it\'s direct database access, then 2-3 DB\n> >accesses per notification is not going to be a runner - all the\n> >information we\'re talking about extracting here will I think have to\n> >be available from the hypervisor, possibly mixed in with some cached\n> >data retrieved by ceilo from the nova-api (e.g. on every polling\n> >cycle\n> >we wouldn\'t want to go back to the nova-api to figure out the\n> >instance\n> >flavor name, if that\'s not directly exposed by nova-compute but is\n> >needed for metering purposes).\n> \n> The big requirement for it today is for network information, which is\n> already being cached in the Quantum driver. If we can separate the\n> network and the compute notifications I think we\'re ok. Likewise\n> with storage. The downside is we wouldn\'t be getting these\n> notifications as atomic updates and that can lead to race\n> conditions. But, so long as the time stamps are accurate within\n> reason (NTP), we should be ok there. If we\'re dropping events we\'ve\n> got bigger issues to deal with.\n\nYep.\n\n\n> Another possibility we\'re exploring is having a read-only mirror of\n> the production database for this sort of stuff. That could be the\n> \"best practice\" in these tight situations. But that\'s a story for\n> another time :)\n\nInteresting idea.\n\n\n> So, we need to revisit the notification format wrt versioning,\n> structure, payload size, content and overhead. Getting the data out\n> and doing something with it is easily do-able via a worker/consumer\n> or a proprietary notifier (and with no impact on nova core).\n\nOK, there may be a terminology gap here, can you explain what you\nmean by a \"proprietary notifier\" ... a non-standard notification_driver\nthat can be plugged into nova?\n\n\n> Next we need to be very clear on what is instrumentation and what is\n> monitoring/usage/billing/lifecycle.\n\nYes, see above ... I think the metering use-case is clearer, whereas\nthere\'s some blurriness on the boundary understood between monitoring\nand instrumentation.  \n \nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF038883D3F550@ORD1EXD02.RACKSPACE.CORP>',NULL),('<123566421.7674963.1354024875455.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 09:01:15',-18000,'2012-11-27 14:01:15',NULL,'[openstack-dev] [ceilometer] Multiple publisher and transformer','\n\n> IMO, from another view, if we have the pipeline idea, there is not\n> that much difference of transformer and publisher, except the\n> publisher will end the pipeline. \n\n... and know how to interface with an external conduit in a generic\nway (whereas the transformers would tend to be much more specific\nto a particular measurement).\n\n> Every components in the pipeline simply passing the data down the\n> pipeline, and the next item in the pipeline decide continue, or publish.\n\nYep, transformers should be chainable and capable of discarding\n(either by explicitly calling down the chain, or by signalling a\nstopping condition in some other way, e.g. raise an exception\nor return False or whatever makes sense as a protocol).\n\nCheers,\nEoghan\n\n\n','<DDCAE26804250545B9934A2056554AA035B5B4@SHSMSX101.ccr.corp.intel.com>',NULL),('<1235670994.24.1374041418374.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-17 06:10:18',0,'2013-07-17 06:10:18',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #9','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/9/>\n\n------------------------------------------\n[...truncated 21862 lines...]\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=1.16 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 1.165/1.165/1.165/0.000 ms\n++ cinder list\n++ grep ex-vol-43c72a5c\n++ head -1\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1374041356\n+ cinder create --display_name ex-vol-43c72a5c --display_description \'test volume: ex-vol-43c72a5c\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-07-17T06:09:17.468872      |\n| display_description |     test volume: ex-vol-43c72a5c     |\n|     display_name    |           ex-vol-43c72a5c            |\n|          id         | bcaed36a-427b-4614-b59e-9b2b21f6e423 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-43c72a5c | grep available; do sleep 1; done\'\n| bcaed36a-427b-4614-b59e-9b2b21f6e423 | available | ex-vol-43c72a5c |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1374041359\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-43c72a5c\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| bcaed36a-427b-4614-b59e-9b2b21f6e423 | available | ex-vol-43c72a5c |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=bcaed36a-427b-4614-b59e-9b2b21f6e423\n+ die_if_not_set 158 VOL_ID \'Failure retrieving volume ID for ex-vol-43c72a5c\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1374041360\n+ nova volume-attach ac082101-a58a-4128-abdb-21de8c7681cd bcaed36a-427b-4614-b59e-9b2b21f6e423 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | ac082101-a58a-4128-abdb-21de8c7681cd |\n| id       | bcaed36a-427b-4614-b59e-9b2b21f6e423 |\n| volumeId | bcaed36a-427b-4614-b59e-9b2b21f6e423 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-43c72a5c | grep in-use; do sleep 1; done\'\n| bcaed36a-427b-4614-b59e-9b2b21f6e423 | in-use | ex-vol-43c72a5c |  1   |     None    |  False   | ac082101-a58a-4128-abdb-21de8c7681cd |\n++ date +%s\n+ end_time=1374041364\n+ echo \'Completed volume-attach in 4 seconds\'\nCompleted volume-attach in 4 seconds\n++ cinder list\n++ grep ex-vol-43c72a5c\n++ get_field -1\n++ head -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ echo \'| bcaed36a-427b-4614-b59e-9b2b21f6e423 | in-use | ex-vol-43c72a5c |  1   |     None    |  False   | ac082101-a58a-4128-abdb-21de8c7681cd |\'\n++ read data\n+ VOL_ATTACH=ac082101-a58a-4128-abdb-21de8c7681cd\n+ die_if_not_set 172 VOL_ATTACH \'Failure retrieving ex-vol-43c72a5c status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ ac082101-a58a-4128-abdb-21de8c7681cd != ac082101-a58a-4128-abdb-21de8c7681cd ]]\n++ date +%s\n+ start_time=1374041365\n+ nova volume-detach ac082101-a58a-4128-abdb-21de8c7681cd bcaed36a-427b-4614-b59e-9b2b21f6e423\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-43c72a5c | grep available; do sleep 1; done\'\n| bcaed36a-427b-4614-b59e-9b2b21f6e423 | available | ex-vol-43c72a5c |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1374041368\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1374041368\n+ cinder delete bcaed36a-427b-4614-b59e-9b2b21f6e423\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-43c72a5c; do sleep 1; done\'\n| bcaed36a-427b-4614-b59e-9b2b21f6e423 | deleting | ex-vol-43c72a5c |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1374041371\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete ac082101-a58a-4128-abdb-21de8c7681cd\n+ timeout 60 sh -c \'while nova list | grep -q ac082101-a58a-4128-abdb-21de8c7681cd; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning stress tests\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1376.gab58604.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress tempest/stress/etc/stress-tox-job.json -d 3600\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tempest/stress/run_stress.py\", line 40, in <module>\n    main(parser.parse_args())\n  File \"/opt/stack/new/tempest/tempest/stress/run_stress.py\", line 31, in main\n    driver.stress_openstack(tests, ns.duration)\n  File \"tempest/stress/driver.py\", line 134, in stress_openstack\n    test_obj = get_action_object(test[\'action\'])\n  File \"tempest/stress/driver.py\", line 98, in get_action_object\n    return getattr(importlib.import_module(module_part), obj_name)\nAttributeError: \'module\' object has no attribute \'create_destroy\'\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress tempest/stress/etc/stress-tox-job.json -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/rabbitmq/rabbit at devstack-1374040290-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/rabbitmq/rabbit at devstack-1374040290.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/9/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1365121569.17.1373954833383.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<123640982.20.1352506056527.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:07:36',0,'2012-11-10 00:07:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-essex #88','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/88/>\n\n------------------------------------------\n[...truncated 471 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.00\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.36\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.05\n    test_public_versions                                        OK  0.06\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 19.427s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.25 secs:\n    2.41       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    2.35       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.06       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.36       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at f1cc3cfc42db902589785320547204388aa170a3#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 217bd202dd9a7359efb8b49799eb0626866a203f#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-essex/88\n[SCP] Copying console log.\n\n\n','<1778017025.6.1352419663120.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1237032789.283.1356912271058.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-31 00:04:30',0,'2012-12-31 00:04:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #91','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/91/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.64 secs:\n    2.56    Kc11TestCase.test_admin_requires_adminness\n    2.36    KcEssex3TestCase.test_admin_requires_adminness\n    2.13    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 49.341s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.s3hF9KN1Kf\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/91\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/91/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1063024991.265.1356825858463.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1237185725.1434520.1395154129121.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 10:48:49',-14400,'2014-03-18 14:48:49',NULL,'[openstack-dev] Updating libvirt in gate jobs','I agree with Dan -- I think it\'s important to test on newer versions as well, considering we will have people running on other versions besides Ubuntu LTS -- Fedora 20, for instance, is on 1.1.3.4.\n\nAdditionally, considering bugs get fixed and features get implemented in each version of libvirt, we need to ensure that we *can* test code that uses features present in later versions of libvirt.  0.9.8 came out over two years ago making it fairly old.  I think it\'s important to keep up-to-date on what versions we test with.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Daniel P. Berrange\" <berrange at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, March 18, 2014 10:11:54 AM\nSubject: Re: [openstack-dev] Updating libvirt in gate jobs\n\nOn Tue, Mar 18, 2014 at 07:50:15AM -0400, Davanum Srinivas wrote:\n> Hi Team,\n> \n> We have 2 choices\n> \n> 1) Upgrade to libvirt 0.9.8+ (See [1] for details)\n> 2) Enable UCA and upgrade to libvirt 1.2.2+ (see [2] for details)\n> \n> For #1, we received a patched deb from @SergeHallyn/@JamesPage and ran\n> tests on it in review https://review.openstack.org/#/c/79816/\n> For #2, @SergeHallyn/@JamesPage have updated UCA\n> (\"precise-proposed/icehouse\") repo and we ran tests on it in review\n> https://review.openstack.org/#/c/74889/\n> \n> For IceHouse, my recommendation is to request Ubuntu folks to push the\n> patched 0.9.8+ version we validated to public repos, then we can can\n> install/run gate jobs with that version. This is probably the smallest\n> risk of the 2 choices.\n\nIf we\'ve re-run the tests in that review enough times to be confident\nwe\'ve had a chance of exercising the race conditions, then using the\npatched 0.9.8 seems like a no-brainer. We know the current version in\nubuntu repos is broken for us, so the sooner we address that the better.\n\n> As soon as Juno begins, we can switch 1.2.2+ on UCA and request Ubuntu\n> folks to push the verified version where we can use it.\n\nThis basically re-raises the question of /what/ we should be testing in\nthe gate, which was discussed on this list a few weeks ago, and I\'m not\nclear that there was a definite decision in that thread\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-February/027734.html\n\nTesting the lowest vs highest is targetting two different scenarios\n\n  - Testing the lowest version demonstrates that OpenStack has not\n    broken its own code by introducing use of a new feature.\n\n  - Testing the highest version demonstrates that OpenStack has not\n    been broken by 3rd party code introducing a regression.\n\nI think it is in scope for openstack to be targetting both of these\nscenarios. For anything in-between though, it is upto the downstream\nvendors to test their precise combination of versions. Currently though\nour testing policy for non-python bits is \"whatever version ubuntu ships\",\nwhich may be neither the lowest or highest versions, just some arbitrary\nversion they wish to support. So this discussion is currently more of a\n\'what ubuntu version should we test on\' kind of decision\n\nRegards,\nDaniel\n-- \n|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n|: http://libvirt.org              -o-             http://virt-manager.org :|\n|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20140318141154.GG29054@redhat.com>',NULL),('<12387264.6395.1389054605680.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 16:29:56',-28800,'2014-01-07 00:29:56',NULL,'[openstack-dev] [neutron] [policy] Complementary or alternative\n	semantics?','\nOver the holidays I realized there\'s something about the proposed Neutron policy API that I don\'t understand.  Is the proposed API complementary to the core API, or is it intended to be an alternative?  By complementary, I mean that a user can create a bunch of networks, subnets, and ports and then constrain how those things interoperate by writing policy.  By an alternative, I mean that a user must choose either networks/subnets/ports or policy, but cannot choose both.  I had always assumed we were talking about a complementary API but wanted to double-check.\n\nThanks,\nTim\n\n\n',NULL,NULL),('<123907032.2.1380348734147.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-28 06:12:13',0,'2013-09-28 06:12:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #25','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/25/>\n\n------------------------------------------\n[...truncated 1186 lines...]\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_api.TestApi.test_ownership\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1381, in test_ownership\n    self.assertEqual(response.status, 201)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 500 != 201\n\n\n======================================================================\nFAIL: glance.tests.functional.test_cache_middleware.TestImageCacheManageXattr.test_user_not_authorized\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 277, in test_user_not_authorized\n    self.verify_no_images()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 234, in verify_no_images\n    self.assertEqual(response.status, 200)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 500 != 200\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 90.45 secs:\n    26.25    TestScrubber.test_scrubber_app\n    20.61    TestScrubber.test_delayed_delete\n    14.74    TestGlanceControl.test_reload\n    14.52    TestGlanceControl.test_respawn\n    14.33    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1101 tests in 611.985s\n\nFAILED (SKIP=38, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.25\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ZerxFpYfnv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/25/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-4/25\n[SCP] Copying console log.\n\n\n','<173295276.74.1379830328010.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<123F36E6-16E1-4ED6-8F8F-8C4FB118025E@cern.ch>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-05-04 16:06:33',0,'2014-05-04 16:06:33',NULL,'[OpenStack Foundation] [Foundation Board] Kickoff Meeting - The\n Enterprise	Readiness effort April 30th 10am\n pacificfoundation-board@lists.openstack.org','\nAre there any notes from the meeting ?\n\nAt one of the operator sessions at the summit (https://etherpad.openstack.org/p/ATL-ops-unconference-RFC), we\'re reviewing some of the gaps and I\'d like to make sure the efforts stay sync\'d up.\n\nTim\n\nOn 26 Apr 2014, at 07:58, Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>> wrote:\n\n\nUnfortunately, I am away that week but I fully support the initiative.\n\nThis is very consistent with the discussions held at the operators mini-summit and some of the attendees could provide a useful pool of additional volunteers once the structure is set up.\n\nTim\n\n-----Original Message-----\nFrom: Sean Roberts [mailto:seanrob at yahoo-inc.com<http://yahoo-inc.com>]\nSent: 25 April 2014 21:46\nTo: Joshua McKenty\nCc: foundation at lists.openstack.org<mailto:foundation at lists.openstack.org>; david.l.brown at intel.com<mailto:david.l.brown at intel.com>; Carol L Barrett; foundation-board at lists.openstack.org<mailto:foundation-board at lists.openstack.org>\nSubject: Re: [Foundation Board] Kickoff Meeting - The Enterprise Readiness effort April 30th 10am pacific\n\nI understand this meet to be a follow on to the operators summit. I like this and I want to support the effort. I understand the goals asked to be worked on:\n- enterprise IT requirements vs. today\'s OpenStack capabilities\n- market perceptions\n- define a set of recommendations to ensure OpenStack meets the technical requirements of Enterprise IT to deploy Private Clouds\n\n~sean\n\nOn Apr 25, 2014, at 11:40 AM, \"Joshua McKenty\" <joshua at pistoncloud.com<mailto:joshua at pistoncloud.com>> wrote:\n\nAdding the public mailing list.\n\nAlan/Imad, are you going to host a room in the Bay Area for folks that can congregate there? We\'re happy to host at Piston in the city, but it\'s the first day in our new office so there may not be very many chairs.\n\nFor easier reference, I\'m pasting the dial-in info below:\n\n  * Access Numbers:  US Toll Free: 888 875 9370; Australia:  (+61)1300 365 946; Japan: 0120-074-759; PRC/Shanghai: 800-6201-531; Korea: 0807-6724-90; UK: 01793 402663;\n  * Bridge #: 1\n  * Access Code: 9777448\n\n\n--\n\nJoshua McKenty\nChief Technology Officer\nPiston Cloud Computing, Inc.\n+1 (650) 242-5683\n+1 (650) 283-6846\nhttp://www.pistoncloud.com\n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\nOn Apr 23, 2014, at 8:04 AM, Alan Clark <aclark at suse.com> wrote:\n\nBoard members,\n\nAt the last board meeting we discussed and proposed to initiate an open work group  analyze enterprise IT requirements vs. today\'s OpenStack capabilities and market perceptions and define a set of recommendations to ensure OpenStack meets the technical requirements of Enterprise IT to deploy Private Clouds and has the right market awareness and perception to achieve this.\n\nWe would like to kick off this work group with an organizing phone call on April 30th to get things moving. Time: 10:00 am-11:00am pacific. Imad has volunteered to kick off the effort with support from staff Carol and David.  (Most of you met David at our Palo Alto F2F)\n\nCallin information, notes and ideas for the effort are located on an etherpad:  https://etherpad.openstack.org/p/Win-The-Enterprise\n\nThe effort is kicked off  by the Board but definitely needs collaboration from the community. The first item on the first call will discuss how best to invite people to the effort. Second item is to begin to breakdown and organize the effort.\n\nThanks,\n\nAlanClark\n\n\n\n\n_______________________________________________\nFoundation-board mailing list\nFoundation-board at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n\n\n_______________________________________________\nFoundation-board mailing list\nFoundation-board at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n\n_______________________________________________\nFoundation-board mailing list\nFoundation-board at lists.openstack.org<mailto:Foundation-board at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140504/be4cd84f/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9B64903@CERNXCHG41.cern.ch>',NULL),('<1240591547.15497919.1394442908207.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 05:15:08',-14400,'2014-03-10 09:15:08',NULL,'[openstack-dev] [ceilometer] nominating Ildikó Váncsa and Nadya Privalova to ceilometer-core','\nFolks,\n\nTime for some new blood on the ceilometer core team.\n\nI\'d like to nominate Ildik? V?ncsa and Nadya Privalova as ceilometer\ncores in recognition of their contributions([1], [2]) over the Icehouse\ncycle, and looking forward to their continued participation for Juno.\n\nBoth showed up with design summit proposals in HK, and have since\ndemonstrated staying power as project contributors, proving themselves\nas eagle-eyed reviewers.\n\nContribution highlights:\n\n * Ildik? co-authored the complex query API extension with Balazs Gibizer\n   and showed a lot of tenacity in pushing this extensive blueprint\n   through gerrit over multiple milestones.\n\n * Nadya has shown much needed love to the previously neglected HBase\n   driver bringing it much closer to feature parity with the other\n   supported DBs, and has also driven the introduction of ceilometer\n   coverage in Tempest.\n\nThis nomination doubles as my +1 for both ildikov & nprivalova.\n\nCeilometer cores, please respond with your yeas or nays on list.\n\nCheers,\nEoghan\n\n\n[1] http://bit.ly/ildikov-icehouse-reviews\n    http://bit.ly/ildikov-icehouse-commits \n\n[2] http://bit.ly/nprivalova-icehouse-reviews\n    http://bit.ly/nprivalova-icehouse-commits\n\n\n','<1599440550.15493713.1394442205448.JavaMail.zimbra@redhat.com>',NULL),('<1241080996.8596171.1415584068108.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-09 20:47:48',-18000,'2014-11-10 01:47:48',NULL,'[openstack-dev] [Neutron] Let\'s fix all neutron bugs! (NOT)','\n\n----- Original Message -----\n> Hi folks,\n> \n> I have been supervising bug list for neutron during the last release cycle,\n> trying\n> to do some \"housekeeping\", prioritizing issues and fixing some of them.\n> \n> As you might see, amount of bugs (even staying in \"New\" state) doesn\'t go\n> down.\n> Bugs appear at quite fast pace, and some of them hang for quite a long time,\n> especially if someone has assigned the bug on himself and then abandoned\n> working on it.\n> One of the other reasons for that is that we lack volunteers willing to fix\n> those bugs.\n> \n> So,\n> \n> If you\'re willing to help, have some knowledge of neutron and its codebase or\n> you have a lab where you can reproduce (and hence, confirm) the bug and\n> provide more additional debugging info, that would be great!\n> My plan is to get your contact, knowing what \"part\" of neutron project you\n> familiar with, and then assign bugs directly to you if I feel that the issue\n> matches your experience.\n> \n> I just want to make bug triaging/fixing process a bit more iterative and\n> efficient, with a help of community.\n> So please reach directly to me and let me know what you are\n> interested/experienced with.\n\nThere is one potential downside with this workflow.  When a bug is assigned to someone, it will discourage anyone else from looking at it.  You may end up with a lot of bugs assigned that are not actively being worked on.\n\nAn alternative approach would be to just subscribe developers you think may be willing and interested to take a look.  That way they\'ll get a notification email about it, but it won\'t discourage anyone else from working on it that may want to in the meantime.\n\n-- \nRussell Bryant\n\n\n','<CAJfiwOTb6oXuvZ7KFhBCvSj3DOM06fiL_wLyCDq3L5eKnVnf7w@mail.gmail.com>',NULL),('<1241695515.2514391381788762719.JavaMail.nobody@rsj2rmd001.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-14 22:12:42',0,'2013-10-14 22:12:42',NULL,'[OpenStack Foundation] Board meeting update: OpenStack Board\n Meeting October 17, 2013 - Requested Session','Hello Foundation Mailing List,\n\nAlan Clark updated the following board meeting session:\n\nTopic: OpenStack Board Meeting October 17, 2013 - Requested Session\nHost: Alan Clark\nDate: Thursday, October 17, 2013\nTime: 4:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 922 514 295\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n-------------------------------------------------------\nTo join the meeting\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&HMAC=f5f8695f8841b510747721a5bc4065416f20533c&RT=MiM0.\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&ORT=MiM0&HMAC=f5f8695f8841b510747721a5bc4065416f20533c\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=243475827&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 514 295\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\nTo update this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=243475827&EF=EMA&UUID=1713093867&SHA2=ZlP4vQhaE4dlXtCzk6Cj5KtCw9Kbet44JsLa1MX0AHA%3D&RT=MiM0\n\nhttp://www.webex.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131014/42d69372/attachment.html>\n\n',NULL,NULL),('<1241840604.28694755.1403110139926.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-18 12:48:59',-14400,'2014-06-18 16:48:59',NULL,'[OpenStack-Infra] Status of check-tempest-dsvm-f20 job','\n\n> On 06/18/2014 05:45 AM, Eoghan Glynn wrote:\n> > \n> > \n> >> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:\n> >>> If we were to use f20 more widely in the gate (not to entirely\n> >>> supplant precise, more just to split the load more evenly) then\n> >>> would the problem observed tend to naturally resolve itself?\n> >>\n> >> I would be happy to see that, having spent some time on the Fedora\n> >> bring-up :) However I guess there is a chicken-egg problem with\n> >> large-scale roll-out in that the platform isn\'t quite stable yet.\n> >> We\'ve hit some things that only really become apparent \"in the wild\";\n> >> differences between Rackspace & HP images, issues running on Xen which\n> >> we don\'t test much, the odd upstream bug requiring work-arounds [1],\n> >> etc.\n> > \n> > Fair point.\n> >  \n> >> It did seem that devstack changes was the best place to stabilze the\n> >> job.  However, as is apparent, devstack changes often need to be\n> >> pushed through quickly and that does not match well with a slightly\n> >> unstable job.\n> >>\n> >> Having it experimental in devstack isn\'t much help in stabilizing.  If\n> >> I trigger experimental builds for every devstack change it runs\n> >> several other jobs too, so really I\'ve just increased contention for\n> >> limited resources by doing that.\n> > \n> > Very true also.\n> > \n> >> I say this *has* to be running for devstack eventually to stop the\n> >> fairly frequent breakage of devstack on Fedora, which causes a lot of\n> >> people wasted time often chasing the same bugs.\n> > \n> > I agree, if we\'re committed to Fedora being a first class citizen (as\n> > per TC distro policy, IIUC) then it\'s crucial that Fedora-specific\n> > breakages are exposed quickly in the gate, as opposed to being seen\n> > by developers for the first time in the wild whenever they happen to\n> > refresh their devstack.\n> > \n> >> But in the mean time, maybe suggestions for getting the Fedora job\n> >> exposure somewhere else where it can brew and stabilize are a good\n> >> idea.\n> > \n> > Well, I would suggest the ceilometer/py27 unit test job as a first\n> > candidate for such exposure.\n> > \n> > The reason being that mongodb 2.4 is not available on precise, but\n> > is on f20. As a result, the mongodb scenario tests are effectively\n> > skipped in the ceilo/py27 units, which is clearly badness and needs\n> > to be addressed.\n> > \n> > Obviously this lack of coverage will resolve itself quickly once\n> > the Trusty switchover occurs, but it seems like we can short-circuit\n> > that process by simply switching to f20 right now.\n> > \n> > I think the marconi jobs would be another good candidate, where\n> > switching over to f20 now would add real value. The marconi tests\n> > include some coverage against mongodb proper, but this is currently\n> > disabled, as marconi requires mongodb version >= 2.2 (and precise\n> > can only offer 2.0.4).\n> > \n> >> We could make a special queue just for f20 that only triggers that\n> >> job, if others like that idea.\n> >>\n> >> Otherwise, ceilometer maybe?  I made some WIP patches [2,3] for this\n> >> already.  I think it\'s close, just deciding what tempest tests to\n> >> match for the job in [2].\n> > \n> > Thanks for that.\n> > \n> > So my feeling is that at least the following would make sense to base\n> > on f20:\n> > \n> > 1. ceilometer/py27\n> > 2. tempest variant with the ceilo DB configured as mongodb\n> > 3. marconi/py27\n> > \n> > Then a random selection of other p27 jobs could potentially be added\n> > over time to bring f20 usage up to approximately the same breath\n> > as precise.\n> > \n> > Cheers,\n> > Eoghan\n\nThanks for the rapid response Sean!\n \n> Unit test nodes are a different image yet still. So this actually\n> wouldn\'t make anything better, it would just also stall out ceilometer\n> and marconi unit tests in the same scenario.\n\nA-ha, ok, thanks for the clarification on that.\n\nMy thought was to make the zero-allocation-for-lightly-used-classes\nproblem go away by making f20 into a heavily-used node class, but\nI guess just rebasing *only* the ceilometer & marconi py27 jobs onto\nf20 would be insufficient to get f20 over the line in that regard?\n\nAnd if I understood correctly, rolling directly to a wider selection\nof py27 jobs rebased on f20 would be premature in the infra group\'s\neyes, because f20 hasn\'t yet proven itself in the gate.\n\nSo I guess I\'d like to get a feel for where the bar is set on f20\nbeing considered a valid candidate for a wider selection of gate\njobs?\n\ne.g. running as an experimental platform for X amount of time?\n\n>From a purely parochial ceilometer perspective, I\'d love to see the\npy27 job running on f20 sooner rather later, as the asymmetry between\nthe tests run in the gate and in individual developers\' environments\nis clearly badness.\n\nI believe some of the marconi folks would also be enthused about\nenabling mongodb-based testing in the short term. \n\n> I think the real issue is to come up with a fairer algorithm that\n> prevents any node class from starving, even in the extreme case. And get\n> that implemented and accepted in nodepool.\n\nThat would indeed be great. Do you think the simple randomization\nidea mooted earlier on this thread would suffice there, or am I over-\nsimplifying?\n \n> I do think devstack was the right starting point, because it fixes lots\n> of issues we\'ve had with us accidentally breaking fedora in devstack.\n> We\'ve yet to figure out how overall reliable fedora is going to be.\n\nIf there\'s anything more that the Red Hatters in the community can\ndo to expedite the process of establishing the reliability of f20,\nplease do let us know.\n\nThanks!\nEoghan\n\n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> \n\n\n','<53A168D4.6090407@dague.net>',NULL),('<1243013374.24207600.1402499513922.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 11:11:53',-14400,'2014-06-11 15:11:53',NULL,'[openstack-dev] [Nova][devstack] Unable to\n	boot	cirros-0.3.2-x86_64-uec image','Hi Deepak,\nThis mailing list is for development discussions only.  Please use the general or operators\nmailing list (http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators) to\nask questions about running OpenStack.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Deepak Shetty\" <dpkshetty at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, June 11, 2014 3:49:01 AM\n> Subject: [openstack-dev] [Nova][devstack] Unable to boot	cirros-0.3.2-x86_64-uec image\n> \n> Hi,\n> I am using the below cmd to boot cirros-0.3.2-x86_64-uec image thats present\n> in devstack\n> by default...\n> \n> \n> \n> nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --key_name mykey\n> --security_group default myvm_nano nova list -> shows the instance as\n> ACTIVE/Running\n> \n> Taking the VNC console, I see that it stuck at \"Booting from ROM .....\"\n> \n> Can someone help why the image is not booting ?\n> \n> thanx,\n> deepak\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAOXiiMkRTB4rzzm0+6fsWk6vKDjV=QEQhb6GsMOeGxvFcFELmA@mail.gmail.com>',NULL),('<1243102357.10651379.1398447872941.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-25 13:44:32',-14400,'2014-04-25 17:44:32',NULL,'[Openstack-docs] change in ceilometer.conf sample file','\nOK, let me give some context/background here.\n\nPrior to late in the Icehouse cycle (i.e. Mar 26) we had used the\ncheck_uptodate script to ensure that a statically checked-in sample\n.conf file was up-to-date with respect to the code-level descriptions\nof these config options.\n\nThis caused recurrent problems in CI, so as temporary work-around we\ndisabled this check so as to unblock the gate.\n\nHowever there was then no guarantee that reality wouldn\'t slowly\ndiverge from the static .conf sample, so early in Juno (Apr 18) we\ndecided to follow nova\'s lead and also remove the static in-tree\nsample, in favor of re-generating on the fly.\n\nIn the meantime, there has been a lot of churn in config caused mainly\nby:\n\n1. a new keystoneclient release, which seems to include lots of\n   white-space/docstr related changes to the generated config\n\n2. landing the oslo-messaging switch-over in ceilometer, which\n   deprecates all the old common RPC config options\n\nSo of the 3 attachments:\n\n> Version before it disappeared in the ceilometer project:\n> ceilometer.conf.sample-5995bf906cea07e69\n\nThis is a snapshot in time, which was correct on Apr 18 but has\nsince been superceeded.\n \n> The one I generated from ceilometer master (April 23):\n> ceilometer.conf.sample-rl-gen\n\nThis is less out-of-date, but should be re-generated from master\nas of today.\n \n> Your version that I found in openstack-manuals:\n> ceilometer.conf-manuals \n\nThis is quite stale, as it seems to predate the landing of the\noslo-messaging switchover.\n\nNote that I\'m assuming all along that the docco should be based on\nmaster, as opposed to being in lockstep with the last release (i.e.\nthe icehouse final tag).\n\nHope this helps,\nEoghan\n\n\n----- Original Message -----\n> Hi all, Roger (CCed) has identified a question about the accuracy of the\n> ceilometer.conf sample file we now have in our repo. Can anyone track down\n> the correct information for Icehouse so we can ensure it\'s in the docs\n> repo?\n> \n> Eoghan, we hadn\'t identified a Project Doc Lead for ceilometer so I\'m\n> sending to you in case you\'re not subscribed to the docs mailing list.\n> \n> Thanks,\n> Anne\n> \n> ---------- Forwarded message ----------\n> From: Roger Luethi\n> Date: Fri, Apr 25, 2014 at 9:36 AM\n> \n> On Fri, 25 Apr 2014 09:29:28 -0500, Anne Gentle wrote:\n> > Did you build from the master branch of ceilometer or stable/icehouse?\n> \n> For convenience, I\'ll attach three versions:\n> \n> Version before it disappeared in the ceilometer project:\n> ceilometer.conf.sample-5995bf906cea07e69\n> \n> The one I generated from ceilometer master (April 23):\n> ceilometer.conf.sample-rl-gen\n> \n> Your version that I found in openstack-manuals:\n> ceilometer.conf-manuals\n> \n> Roger\n> \n\n\n','<CAD0KtVFBe_7Et6EQyYO2UmcfUU8vrambQ=opVS5VswY+GXR5PQ@mail.gmail.com>',NULL),('<1243365775.255029.1391158118404.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 09:48:38',3600,'2014-01-31 08:48:38',NULL,'[openstack-dev] [Heat] About LaunchConfiguration and Autoscaling','\n> I favor the second option for the same reasons as Zane described, but also\n> don\'t think we need a LaunchConfiguration resource. How about just adding a\n> attribute to the resources such that the engine knows is not meant to be\n> handled in the usual way, and instead it is really a \"template\" (sorry for\n> the overloaded term) used in a scaling group. For example:\n> \n> group:\n> type: OS::Heat::ScalingGroup\n> properties:\n> scaled_resource: server_for_scaling\n> \n> server_for_scaling:\n> use_for_scaling: true ( the name of this attribute is clearly up for\n> discussion ;-) )\n> type: OS::Nova::Server\n> properties:\n> image: my_image\n> flavor: m1.large\n> \n> When the engine sees the \"use_for_scaling\" set to true, then it does not call\n> things like \"handle_create\". Anyway, that\'s the general idea. I\'m sure there\n> are many other ways to achieve a similar effect.\n\n\nI\'m strongly opposed to that. It reduces the readability of the template a lot for no obvious benefit. Any time you radically change behavior by putting a flag somewhere, somethings\'s wrong.\n\n-- \nThomas\n\n\n','<OF031EAD01.D61FE723-ON86257C70.005C299A-86257C70.005D4FEF@us.ibm.com>',NULL),('<1243639950.6904160.1396536018730.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 10:40:18',-14400,'2014-04-03 14:40:18',NULL,'[openstack-dev] Help in re-running openstack','I just wanted to add that if you modify code, you can commit it into a temporary commit,\nand that will be preserved.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Dolph Mathews\" <dolph.mathews at gmail.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Thursday, April 3, 2014 9:51:31 AM\nSubject: Re: [openstack-dev] Help in re-running openstack\n\n\nOn Thu, Apr 3, 2014 at 8:45 AM, Anita Kuno < anteaya at anteaya.info > wrote: \n\n\n\nOn 04/03/2014 07:02 AM, Erno Kuvaja wrote: \n> Hi Shiva, \n> \n> You can get into the screen after you have made the changes stop the \n> process you have changed (ctrl-c on the correct tab) and restart it \n> (arrow up will give you the last command ran which will be the one that \n> has started the process by devstack). \n> \n> - Erno \n> \n> On 03/04/14 11:47, shiva m wrote: \n>> Hi, \n>> \n>> I am trying to modify code in /op/stack/* and did ./unstack.sh and \n>> ./stack.sh. But after ./stack.sh it reloading to previous values. Any \n>> one please help where to modify code and re-run. Say if I modify \n>> some python file or some configurtaion file like /etc/nova/nova.conf, \n>> how do I make these changes get effected. I have ubuntu-havana \n>> devstack setup. \n>> \n>> I am new to openstack code, correct if I am wrong. \n>> \n>> Thanks, \n>> Shiva \n>> \n>> \n>> \n>> \n>> _______________________________________________ \n>> OpenStack-dev mailing list \n>> OpenStack-dev at lists.openstack.org \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> \n> \n> \n> \n> _______________________________________________ \n> OpenStack-dev mailing list \n> OpenStack-dev at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> \nRequests of this nature are considered support requests. \n\nAlthough not named, this question is specifically with regard to devstack (making this the appropriate list!). \n\n\n\nSupport requests belong on the general mailing list: \nopenstack at lists.openstack.org . \n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\nThank you, \nAnita. \n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAC=h7gWVVoCj4kMLOe39sR4KCEuEFujSnH0w8DXgra4L3NB+Lg@mail.gmail.com>',NULL),('<1245462140.9154128.1372950094821.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-04 11:01:34',-14400,'2013-07-04 15:01:34',NULL,'[openstack-dev] [horizon] python-selenium is non-free,\n Horizon shouldn\'t use it','\"Sascha Peilicke\" <speilicke at suse.com> wrote:\n> On 07/04/2013 04:06 PM, Thomas Goirand wrote:\n> > On 07/04/2013 06:10 PM, Julien Danjou wrote:\n> >> On Thu, Jul 04 2013, Julie Pichon wrote:\n> >>> Why is Selenium considered non-free? The code is Apache-licensed,\n> >>> including the Python bindings.\n> >>>\n> >>> FWIW only a few of the unit tests use Selenium (and those that do, need\n> >>> to),\n> >>> and they\'re not run by default unless you set a flag to do so.\n> >>\n> >> Yes, that seems like a mistake from the Debian packager as far as I can\n> >> tell. There\'s nothing that requires it to be in non-free.\n> >>\n> >> (Cc\'ing Sascha, the maintainer)\n> >\n> > Well, see this:\n> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677\n> >\n> > There are files not built from source. Also, when looking at the\n> > package, it seems that it isn\'t maintained as good as it deserves.\n> > #700061 was opened in 08 Feb 2013, and there\'s no answer at all from\n> > Sascha to this bug (which is RC).\n> \n> I am sorry, but I\'m an openSUSE guy. But I can tell you we had similar\n> bugs :-)\n\nI think Thomas was talking about Sascha Girrulat, the maintainer for the Debian package.\n \n> https://bugzilla.novell.com/show_bug.cgi?id=755619\n\nIt looks like \"I am not authorised to access this bug\", thanks for the link though. I understand the idea :)\n\nJulie\n\n\n','<51D58738.9010001@suse.com>',NULL),('<1245464109.2092916.1373460210879.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-10 08:43:30',-14400,'2013-07-10 12:43:30',NULL,'[Openstack-docs] Linking to external install guides','----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Tuesday, July 9, 2013 8:34:25 PM\n> Subject: Re: [Openstack-docs] Linking to external install guides\n> \n> On 10/07/13 00:48, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Lorin Hochstein\" <lorin at nimbisservices.com>\n> >> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >> Cc: \"Anne Gentle\" <annegentle at justwriteclick.com>,\n> >> openstack-docs at lists.openstack.org\n> >> Sent: Tuesday, July 9, 2013 10:38:26 AM\n> >> Subject: Re: [Openstack-docs] Linking to external install guides\n> >>\n> >> On Mon, Jul 8, 2013 at 3:36 PM, Steve Gordon <sgordon at redhat.com> wrote:\n> >>\n> >>> ----- Original Message -----\n> >>>> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> >>>> To: \"Lorin Hochstein\" <lorin at nimbisservices.com>\n> >>>> Cc: openstack-docs at lists.openstack.org\n> >>>> Sent: Monday, July 8, 2013 11:03:05 AM\n> >>>> Subject: Re: [Openstack-docs] Linking to external install guides\n> >>>>\n> >>>> So, for the last few releases, I would update\n> >>>> http://www.openstack.org/software/start/ with links to the downstream\n> >>>> deployment documentation. It was natural at the time.\n> >>>>\n> >>>> What has changed as of last week is that documentation is now an\n> >>>> official\n> >>>> \"Program\" and we\'ll need to propose the goals for the documentation and\n> >>>> make a scope for release docs. To me, this change means we should be\n> >>>> more\n> >>>> tight and targeted with our install docs as they\'ll be part of the\n> >>>> integrated release.\n> >>>\n> >>> Downstream deployment materials tend to cover arguably more streamlined\n> >>> approaches to deployment, such as Foreman, PackStack, Ansible, JuJu, etc.\n> >>> The flip side however is these deployment methods are not considered part\n> >>> of OpenStack itself and may not in fact be ready to deploy a new release\n> >>> on\n> >>> day dot. These approaches also don\'t necessarily have 1:1 equivalents\n> >>> across distributions.\n> >>>\n> >>> For these reasons my feeling is the documentation \"program\" should be\n> >>> concentrated on delivering accurate manual installation steps at release\n> >>> time in a consolidated installation guide as suggested in the restructure\n> >>> blueprint [1]. I don\'t think however this precludes also linking the\n> >>> distribution specific materials somewhere as they become available, it\n> >>> just\n> >>> wouldn\'t be a blocker to the integrated release?\n> >>>\n> >>> -Steve\n> >>>\n> >>> [1] https://wiki.openstack.org/wiki/Blueprint-restructure-documentation\n> >>>\n> >>\n> >>\n> >> At the last design summit, we talked about the doc team no longer\n> >> maintaining any install documentation at all going forward, leaving that\n> >> entirely to downstream projects. I really do think that\'s the way we\n> >> should\n> >> go. I\'m hesitant to maintain docs on a fully manual install (i.e., from\n> >> source tarballs), since we really don\'t want people to do that.\n> >\n> > Yes, I realize now I should have clarified that by \"manual\" I still meant\n> > using packages - just without aids like those listed in my previous mail.\n> > I think trying to create and maintain documentation of from source\n> > installation that would potentially be even harder than this, despite the\n> > (potential) issues with packaged builds lagging behind the source release.\n> >\n> >> It means that documentation on how to do an install won\'t exist until the\n> >> downstream projects write these up, but since we recommend installing from\n> >> downstream packages, I think that\'s unavoidable. Since we\'re seeing a lot\n> >> more support for OpenStack downstream these days, I think those projects\n> >> have more of an incentive to get their packages and docs ready ASAP after\n> >> a\n> >> release.\n> >\n> > My understanding is that at least RPM/DEB packages are likely to be\n> > available *very* shortly after the actual release for Havana.\n> \n> I\'ll take a bullish line, which may not necessarily be achievable:\n> \n> \"\"\"\n> On the day that the press release for Havana is sent out, we need -by\n> hook or by crook!- to have installation instructions for RHEL and\n> Ubuntu, and ideally SUSE and Debian too.\n> \"\"\"\n> \n> I\'m thinking: \"if you can\'t install the software, then it\'s not really a\n> release, is it?\". Release day is our time to shine :)\n\nWell, another huge gap that I think exists here is if you can\'t upgrade from the previous release it\'s not really a release. Currently I think this is a huge problem regardless of installation method because the only documentation available for upgrades appears to be some per-project notes in the release notes Wiki page. A bit tangential perhaps and not sure this is really just a documentation problem but thought I would bring it up.\n\n> So, feasibility/sanity check:\n> * This is unlikely to be provided in time by our friends at RH or\n> Canonical, leaving:\n> Option 1: Delay the press release\n> Option 2: DIY\n> \n> Personally, I think Option 1 would be terrible for the community\'s\n> \"feelings\", and tying OpenStack to particular product offerings is not\n> something we should probably be doing :)\n\nI\'ve sent a query regarding build schedules for RDO on rdo-list [1]. No doubt there is package tweaking to be done but nightlies are already being built from trunk:\n\n    http://repos.fedorapeople.org/repos/openstack/openstack-trunk/\n\nThanks,\n\nSteve\n\n[1] https://www.redhat.com/archives/rdo-list/2013-July/msg00057.html\n\n\n','<51DCAC11.4070406@openstack.org>',NULL),('<1245537268.91.1380176234536.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-26 06:17:14',0,'2013-09-26 06:17:14',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #22','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/22/>\n\n\n\n','<509750513.86.1380089727602.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1246623081.47124268.1410369412399.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 13:16:52',-14400,'2014-09-10 17:16:52',NULL,'[openstack-dev] [Horizon] Licensing issue with using JSHint in\n build','\n----- Original Message -----\n> From: \"Jeremy Stanley\" <fungi at yuggoth.org>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, September 10, 2014 1:10:18 PM\n> Subject: Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in build\n> \n> On 2014-09-10 13:00:29 -0400 (-0400), Solly Ross wrote:\n> > JSHint *isn\'t* Douglas Crockford. It was written by someone who\n> > (understandably) thought Douglas Crockford had some good ideas,\n> > but was overzealous.\n> [...]\n> \n> Overzealous enough to copy his code.\n\n?? This sentence doesn\'t make much sense.  I meant to say that\nDouglas Crockford was overzealous (which he is, IMO).\n\n> \n> > The license is as such:\n> > https://github.com/jshint/jshint/blob/master/LICENSE\n> \n> Ahem. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19\n\nFair enough.  I stand corrected.  I didn\'t catch that.\nThe general license, however, is as stated.\n\n> \n> > You are thinking of JSLint, which is written by Douglas Crockford.\n> \n> JSHint is a derivative project of JSLint. Sorry to burst your\n> bubble.\n\nTo be fair, it\'s been undergoing *major* revisions lately, making it resemble\nJSHint less and less in terms of what it checks for.  Having used it in the\npast, functionality wise it\'s very different.  While it maintains some backwards\ncompatibility, it has added in new checks, doesn\'t complain about nearly the number\nof things that JSLint complains about (for good reasons).\n\n> --\n> Jeremy Stanley\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140910171018.GR1251@yuggoth.org>',NULL),('<1246739973.2978102.1395865517321.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 16:25:17',-14400,'2014-03-26 20:25:17',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials\n	to	Keystone','\n\n> I haven\'t gotten to my email back log yet, but want to point out that I agree\n> with everything Robert just said. I also raised these concerns on the\n> original ceilometer BP, which is what gave rise to all the work in ironic\n> that Haomeng has been doing (on the linked ironic BP) to expose these\n> metrics for ceilometer to consume.\n\nThanks Devananda, so it seems like closing out the ironic work started\nin the icehouse BP[1] is the way to go, while on the ceilometer side\nwe can look into consuming these notifications.\n\nIf Haomeng needs further input from the ceilometer side, please shout.\nAnd if there are some non-trivial cross-cutting issues to discuss, perhaps\nwe could consider having another joint session at the Juno summit?\n\nCheers,\nEoghan\n\n[1] https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer\n \n> Typing quickly on a mobile,\n> Deva\n> On Mar 26, 2014 11:34 AM, \"Robert Collins\" < robertc at robertcollins.net >\n> wrote:\n> \n> \n> On 27 March 2014 06:28, Eoghan Glynn < eglynn at redhat.com > wrote:\n> > \n> > \n> >> On 3/25/2014 1:50 PM, Matt Wagner wrote:\n> >> > This would argue to me that the easiest thing for Ceilometer might be\n> >> > to query us for IPMI stats, if the credential store is pluggable.\n> >> > \"Fetch these bare metal statistics\" doesn\'t seem too off-course for\n> >> > Ironic to me. The alternative is that Ceilometer and Ironic would both\n> >> > have to be configured for the same pluggable credential store.\n> >> \n> >> There is already a blueprint with a proposed patch here for Ironic to do\n> >> the querying:\n> >> https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer .\n> > \n> > Yes, so I guess there are two fundamentally different approaches that\n> > could be taken here:\n> > \n> > 1. ironic controls the cadence of IPMI polling, emitting notifications\n> > at whatever frequency it decides, carrying whatever level of\n> > detail/formatting it deems appropriate, which are then consumed by\n> > ceilometer which massages these provided data into usable samples\n> > \n> > 2. ceilometer acquires the IPMI credentials either via ironic or\n> > directly from keystone/barbican, before calling out over IPMI at\n> > whatever cadence it wants and transforming these raw data into\n> > usable samples\n> > \n> > IIUC approach #1 is envisaged by the ironic BP[1].\n> > \n> > The advantage of approach #2 OTOH is that ceilometer is in the driving\n> > seat as far as cadence is concerned, and the model is far more\n> > consistent with how we currently acquire data from the hypervisor layer\n> > and SNMP daemons.\n> \n> The downsides of #2 are:\n> - more machines require access to IPMI on the servers (if a given\n> ceilometer is part of the deployed cloud, not part of the minimal\n> deployment infrastructure). This sets of security red flags in some\n> organisations.\n> - multiple machines (ceilometer *and* Ironic) talking to the same\n> IPMI device. IPMI has a limit on sessions, and in fact the controllers\n> are notoriously buggy - having multiple machines talking to one IPMI\n> device is a great way to exceed session limits and cause lockups.\n> \n> These seem fundamental showstoppers to me.\n> \n> -Rob\n> \n> --\n> Robert Collins < rbtcollins at hp.com >\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAExZKErNzhEEAxSURp9QDF+Rnc3CMXi7CQw20daHsNk0nu5x9Q@mail.gmail.com>',NULL),('<1246767659.3125818.1373551783603.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-11 10:09:43',-14400,'2013-07-11 14:09:43',NULL,'[Openstack-docs] Linking to external install guides','----- Original Message -----\n> From: \"Shaun McCance\" <shaunm at gnome.org>\n> To: \"Tom Fifield\" <tom at openstack.org>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, July 11, 2013 9:16:28 AM\n> Subject: Re: [Openstack-docs] Linking to external install guides\n> \n> On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:\n> > On 10/07/13 15:40, Andreas Jaeger wrote:\n> > > On 07/10/2013 02:34 AM, Tom Fifield wrote:\n> > >> I\'ll take a bullish line, which may not necessarily be achievable:\n> > >>\n> > >> \"\"\"\n> > >> On the day that the press release for Havana is sent out, we need -by\n> > >> hook or by crook!- to have installation instructions for RHEL and\n> > >> Ubuntu, and ideally SUSE and Debian too.\n> > >> \"\"\"\n> > >\n> > > What kind of instructions are you looking at? The \"Basic installation\"\n> > > ones, the current \"installation guides\" - or both?\n> > >\n> > > Andreas\n> > \n> > Thanks for the reply!!\n> > \n> > I think the answer is: \"something\" ;)\n> > \n> > My personal impression is:\n> > * the basic install guide is too basic right now\n> > * the install guides are too heavy\n> > \n> > so ideally what I would be looking for as a deployer is something that\n> > gives me a basic installation, with a bit of explanation on why the\n> > steps are being taken.\n> > \n> > \n> > However, I believe Shaun McCance is taking a very serious look at the\n> > installation guides right now and should be able to provide an\n> > authoritative answer.\n> \n> That\'s more or less my impression. I don\'t like that there\'s two guides.\n> It\'s asking readers to make an upfront decision that they\'re probably\n> not in a position to make. My preference would be a single install guide\n> that\'s structured such that you get a basic, working install within the\n> first few chapters, and can choose your own adventure after that.\n\nRight, I agree that the fact that there are two guides is a problem both for readers and for the writers attempting to keep them up to date. I think that there is some debate around what a \"basic, working install\" looks like though and in part that\'s what led to there being two guides in the first place. From my point of view a basic working install means you can run up an instance and it will have network connectivity, but that statement still leaves questions like:\n\n- Do you omit block storage (Cinder) setup because strictly speaking you don\'t need volumes to run a VM?\n- Do you omit object storage (Swift) setup because it\'s not strictly needed or do you use it as the backend for image storage (Glance)?\n\nAnother key point raised in the previous review of the basic-install guide was that while it gets the user up and running in a more streamlined fashion it can leave them in a bit of a bind when it comes to expanding [1]. So I think on top of my statement that a basic working install means \"you can run up an instance and it will have network connectivity\" there probably needs to be some consideration of ensuring the initial deployment allows for easy expansion without having to go back and rework the original endpoints etc. when it comes to the choose your own adventure part. \n\n> The current full install guide feels random, like pieces were added to\n> it over time without a lot of thought to the overall narrative. The\n> basic install guide is nice for what it is. I\'d just prefer it were\n> incorporated into a larger work.\n> \n> And I believe very strongly that your docs should be ready on release\n> day. They\'re part of your fanfare, and should be linked to from your\n> marketing materials.\n\nI am +1 on this but am concerned about expending too much effort on \"install from source\" instructions if most users are ultimately going to install from packages (even if there is a 1-2 day lag for packaging, which is the advice I am getting on rdo-list). My perhaps unrealistic suggestion is that we conditionalize such that we can have \"source\", \"debian;ubuntu\", and \"rhel;fedora;centos\" paths through a single installation guide (I provide these as examples, obviously where other distros such as SuSE differ and need an additional path they would also be more than welcome). The package-based options would be contingent on someone being willing to maintain them though - obviously I would be looking to be heavily involved from an RPM side. The \"from source\" path would be the only one that would be considered release blocking/must have though because ultimately it\'s the only one likely to be there on 0-day of the release. Thoughts?\n\nThanks,\n\nSteve\n\n[1] http://lists.openstack.org/pipermail/openstack-docs/2013-April/001510.html\n\n\n','<1373548588.23490.52.camel@recto>',NULL),('<1246876516.252.1363155280193.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-13 06:14:40',0,'2013-03-13 06:14:40',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #163','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/163/>\n\n\n\n','<911620445.230.1363068230366.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1247320a1fded8154ecd4468b9446634@li.nux.ro>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-01-14 16:43:20',0,'2013-01-14 16:43:20',NULL,'[Openstack-operators] manually deleting instances','Hi,\n\nI\'m stuck with some instances in \"Deleting\" mode for some reason. \nTerminating them from dashboard doesn\'t work.\nI also tried reseting the state with \"nova reset-state\", but all that \ngets me is:\nERROR: Policy doesn\'t allow compute_extension:admin_actions:resetState \nto be performed.\n\nWhat steps are to be performed when manually deleting instances?\n\n-- \nSent from the Delta quadrant using Borg technology!\n\nNux!\nwww.nux.ro\n\n\n',NULL,NULL),('<1247493268.46.1381471366245.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-11 06:02:46',0,'2013-10-11 06:02:46',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #32','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/32/>\n\n------------------------------------------\n[...truncated 634 lines...]\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.545s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.14.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.9\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.32\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.7\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.3Qds5gkBkm\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise13/32\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1247649343.22029629.1384375627129.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-11-13 15:47:07',-18000,'2013-11-13 20:47:07',NULL,'[Openstack-operators] New compute node, new libvirt_cpu_mode','----- Original Message -----\n> From: \"Samuel Winchenbach\" <swinchen at gmail.com>\n> To: openstack-operators at lists.openstack.org\n> Sent: Wednesday, November 13, 2013 2:57:32 PM\n> Subject: [Openstack-operators] New compute node, new libvirt_cpu_mode\n> \n> Hi All.\n> \n> I was wondering what the implications of changing libvirt_cpu_mode from the\n> default (host-passthrough) to none might be?   I setup a new compute node\n> that has a slightly newer processor model than the other nodes and live\n> migration is NOT happy about that.   I have done some reading and\n> discovered setting libvirt_cpu_mode=none should help solve the problem.\n>  What can I expect if I do this?   I am assuming a slight performance hit\n> as the VM will not have access to certain processor extensions.  Here is a\n> list of /proce/cpuinfo for two vms (one with =none and the other default).\n> \n> http://paste.openstack.org/show/52519/\n> \n> It is clear that the default mode enables more processor extensions.\n> \n> Is there any other way around this problem?\n> \n> Thanks,\n> Sam\n\nIf you can identify the Libvirt CPU model that best maps to the lowest common denominator for your cluster (that is includes the CPU flags that are common between the CPUs in your compute nodes) then you can set libvirt_cpu_mode to \"custom\" and set libvirt_cpu_model to the specific model [1]. This should be Opteron_G3 for the CPU exposed when you used \"host-passthrough\" in your output.\n\nThis will give you better performance than the QEMU baseline CPU and more importantly working live migration but obviously means some of the flags exposed by the newest CPU in the cluster aren\'t made available to guests.\n\n-Steve\n\n[1] https://wiki.openstack.org/wiki/LibvirtXMLCPUModel\n\n\n','<CAK9s_NxKSsrhodsG-ZTOd9bisHxHbX9sht1wg2GZivCTqbU8hQ@mail.gmail.com>',NULL),('<1248573902.266.1356825875279.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-30 00:04:35',0,'2012-12-30 00:04:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #90','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/90/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/90\n[SCP] Copying console log.\n\n\n','<1024712399.250.1356739495716.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1248734289.23327026.1370971288089.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 13:21:28',-14400,'2013-06-11 17:21:28',NULL,'[openstack-qa] Is tempest must be able to operate without\n identity admin privileges?','Jay,\n\nMakes sense.\n\nBut do not forget the tenants, are just a very weak isolation.\n\nThe consequences of your recommendation:\n- We will not be able parallelize the test cases in http://refstack.org/ use case.\n\nThe compromised possible solution:\n- Instead of using the provided users we will create them only once per worker process.\n- We will teardown them at the end of the execution\n\nOn single thread these kind of silly micro optimization matters.\nIf we really want to compare the performance gain of single thread solution to parallel solution,\n we should have the token optimization.\nNot just because of the performance, it leads to better model.\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: openstack-qa at lists.openstack.org\n> Sent: Tuesday, June 11, 2013 6:15:30 PM\n> Subject: Re: [openstack-qa] Is tempest must be able to operate without identity admin privileges?\n> \n> On 06/09/2013 05:49 PM, Daryl Walleck wrote:\n> > The only other time I can think of when having an isolated tenant would be\n> > a must would be when testing usage of quotas, as it\'d be impossible to\n> > keep a tenant\'s quota usage in one state with multiple concurrent tests\n> > running. Networks and Cinder would have similar concerns, as would any\n> > integration testing with Ceilometer.\n> \n> I\'m not sure I\'m getting my point across about why isolated tenants are\n> absolutely essential for parallel execution of Tempest...\n> \n> If you have test cases running within the same tenant that are testing\n> the creation, modification and destruction of resources (say, server\n> instances), and test cases that are testing the listing and showing of\n> resources, and you run them in parallel, then the tests need to take\n> into account what the other test cases are doing. This means more\n> complex code that must be injected into the listing test cases to filter\n> out unexpected results that suddenly appear in the results for things\n> like GET /servers because other test cases have added or destroyed\n> resources between the time when the listing test case originally\n> determined the number of server resources before adding the server\n> resources that its own test case uses when doing assertions.\n> \n> The reason tenant isolation was added to Tempest was to get rid of this\n> issue.\n> \n> I honestly feel like we are debating getting rid of tenant isolation for\n> silly micro-optimization reasons and completely missing the big picture\n> that isolation/containerization of the test case fixtures means they can\n> be run in parallel.\n> \n> Best,\n> -jay\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B74D22.6090705@gmail.com>',NULL),('<1248992942.26.1372313655654.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-27 06:14:15',0,'2013-06-27 06:14:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #78','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/78/>\n\n------------------------------------------\n[...truncated 1171 lines...]\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v2.test_images.TestImageDirectURLVisibility.test_v2_not_enabled\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v2/test_images.py\",> line 654, in test_v2_not_enabled\n    response = requests.get(path, headers=self._headers())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/requests/api.py\",> line 55, in get\n    return request(\'get\', url, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/requests/api.py\",> line 44, in request\n    return session.request(method=method, url=url, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/requests/sessions.py\",> line 335, in request\n    resp = self.send(prep, **send_kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/requests/sessions.py\",> line 438, in send\n    r = adapter.send(request, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/requests/adapters.py\",> line 327, in send\n    raise ConnectionError(e)\nConnectionError: HTTPConnectionPool(host=\'127.0.0.1\', port=59468): Max retries exceeded with url: /v2/images (Caused by <class \'socket.error\'>: [Errno 111] ECONNREFUSED)\n\n-------------------- >> begin captured logging << --------------------\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.51 secs:\n    26.57    TestScrubber.test_scrubber_app\n    20.90    TestScrubber.test_delayed_delete\n    15.18    TestRootApi.test_version_configurations\n    14.97    TestGlanceControl.test_reload\n    14.89    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1101 tests in 627.319s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.45\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.78\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.11\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.17\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.5\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.M02uPd0Fmg\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/78\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/78/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1355157320.23.1372227250953.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1249091998.45.1374732149098.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-25 06:02:29',0,'2013-07-25 06:02:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-grizzly #106','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/106/>\n\n------------------------------------------\n[...truncated 28 lines...]\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/106/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-grizzly-106\', \'SSH_CLIENT\': \'198.101.231.203 40578 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374091206.977481-1024910269\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise13\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-25_06-00-28\', \'BUILD_NUMBER\': \'106\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'0854d385-d251-427a-91a6-07c166a41881\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'b163c97c4cd0fac6d851d5264df823a620e8f67e\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise13\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#106\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 40578 166.78.144.35 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth>=1.0.7,!=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package netaddr\n    \n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-cinderclient>=1.0.2,<2.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-kZsfgO/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-kZsfgO/d2to1-0.2.10/egg-dist-tmp-sWhia_\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-LC8fjV/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-LC8fjV/setuptools-git-1.0/egg-dist-tmp-nn_X3L\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.12.0,<3 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-flixrI/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-flixrI/d2to1-0.2.10/egg-dist-tmp-Uf0slg\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-1EOH_Y/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-1EOH_Y/setuptools-git-1.0/egg-dist-tmp-n2RMkT\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-bUouhL/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-bUouhL/d2to1-0.2.10/egg-dist-tmp-zHxKOQ\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-gr84CK/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-gr84CK/setuptools-git-1.0/egg-dist-tmp-i5MyTi\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires> (line 12))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-grizzly/106\n[SCP] Copying console log.\n\n\n','<1020900031.35.1374645733229.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1249136722.803883.1383319217028.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 08:20:17',-25200,'2013-11-01 15:20:17',NULL,'[openstack-dev] [nova][scheduler]The database access in\n	the	scheduler filters','\n\n----- Original Message -----\n> From: \"Yunhong Jiang\" <yunhong.jiang at intel.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Thursday, October 31, 2013 6:39:29 PM\n> Subject: [openstack-dev] [nova][scheduler]The database access in the	scheduler filters\n> \n> I noticed several filters (AggregateMultiTenancyIsoaltion, ram_filter,\n> type_filter, AggregateInstanceExtraSpecsFilter) have DB access in the\n> host_passes(). Some will even access for each invocation.\n> \n> Just curios if this is considered a performance issue? With a 10k nodes, 60\n> VM per node, and 3 hours VM life cycle cloud, it will have more than 1\n> million DB access per second. Not a small number IMHO.\n> \n> Thanks\n> --jyh\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\nSorry if I\'m dumb, but please try to explain things to me. I don\'t think I follow...\n\n10k nodes, 60 VM per node... is 600k VM in the whole cloud. A 3 hour life cycle for a VM means every hour 1/3 the nodes turn over so 200k VM  are created/deleted per hour ... divide by 60 for ... 3,333.333 per minute or ... divide by 60 for ... 55.5 VM creations/deletions per second ...\n\n... did I do that math right? So where\'s the million DB accesses per second come from? Are the rules fired for every VM on every access so that 600k VM + 1 new VM means the rules fire 600k + 1 times? What? Sorry... really confused.\n\n# Shawn Hartsock\n\n\n','<DDCAE26804250545B9934A2056554AA01FBAC357@ORSMSX108.amr.corp.intel.com>',NULL),('<124971425.40.1378534311720.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-07 06:11:51',0,'2013-09-07 06:11:51',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #16','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/16/>\n\n\n\n','<1108911865.34.1378361619585.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1249834742.14636946.1391764105061.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 09:08:25',0,'2014-02-07 09:08:25',NULL,'[openstack-dev] [Nova] Bug Triage Day Proposal - Friday\n	7th	February','+1\n\n----- Original Message -----\nFrom: \"John Garbutt\" <john at johngarbutt.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Friday, February 7, 2014 9:12:42 AM\nSubject: Re: [openstack-dev] [Nova] Bug Triage Day Proposal - Friday 7th	February\n\nJust a quick reminder, its bug day!\n\nLets collaborate in #openstack-nova\n\nWe can track progress here:\nhttp://webnumbr.com/untouched-nova-bugs\nAnd later progress:\nhttp://status.openstack.org/bugday\n\nGet those bugs tagged:\nhttps://bugs.launchpad.net/nova/+bugs?field.tag=-*&field.status%3Alist=NEW\n\nTag owners, and others, lets set the priorities:\nhttps://wiki.openstack.org/wiki/Nova/BugTriage\n\nBut don\'t forget:\n* Critical if the bug prevents a key feature from working properly\n(regression) for all users (or without a simple workaround) or result\nin data loss\n* High if the bug prevents a key feature from working properly for\nsome users (or with a workaround)\n* Medium if the bug prevents a secondary feature from working properly\n* Low if the bug is mostly cosmetic\n* Wishlist if the bug is not really a bug, but rather a welcome change\nin behavior\n\nLets also watch out for stale bugs:\nhttps://bugs.launchpad.net/nova/+bugs?orderby=date_last_updated&field.status%3Alist=INPROGRESS&assignee_option=any\n\nJohn\n\n\nPS\nI am having to be an emergency taxi service first thing this morning,\nbut should be joining you this afternoon.\n\nOn 5 February 2014 01:01, Russell Bryant <rbryant at redhat.com> wrote:\n> On 02/04/2014 05:10 PM, John Garbutt wrote:\n>> Hi,\n>>\n>> Now that we getting close towards the end of Icehouse, it seems a good\n>> time to make sure we tame the un-triaged bug backlog (try say that\n>> really quickly a few times over), and look at what really needs fixing\n>> before Icehouse is released.\n>>\n>> I propose that we have a bug triage day this Friday, February 7th.\n>> That way, things should be in a more reasonable state by the Utah\n>> mid-cycle meet up, on Monday.\n>>\n>> If you have some bugs you keep meaning to raise, but haven\'t quite got\n>> around to it yet, please do that before Friday, rather than after\n>> Friday.\n>>\n>> The usual process applies for Bug Triage. Applying official nova tags, etc:\n>>     https://wiki.openstack.org/wiki/Nova/BugTriage\n>>     https://wiki.openstack.org/wiki/BugTriage\n>>\n>> To see how we are doing, take a look at:\n>>     http://webnumbr.com/untouched-nova-bugs\n>>     http://status.openstack.org/bugday\n>>\n>> Lets also not forgot about fixing bugs too, particularly ones that show up here:\n>>     http://status.openstack.org/elastic-recheck/\n>>\n>> Hopefully you can join us on #openstack-nova for some bug triage \"fun\"\n>> on Friday.\n>>\n>> If there are horrid clashes, or other issues or ideas, do speak up.\n>\n> Sounds great.  We\'re due for a bug day.  An improved bug queue as we\n> head toward the freeze would be very helpful.  Thanks!\n>\n> --\n> Russell Bryant\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CABib2_oyfG7G3+cH+28bbm1Cz8ndd2-FceaygixkrBok26dO6Q@mail.gmail.com>',NULL),('<1250132818.128.1362291179563.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-03 06:12:59',0,'2013-03-03 06:12:59',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #153','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/153/>\n\n\n\n','<1984026871.115.1362204801091.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1252153486.6568441.1412585679719.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 04:54:39',-14400,'2014-10-06 08:54:39',NULL,'[openstack-dev] What\'s a dependency (was Re: [all][tc]\n governance changes for \"big tent\"...) model','\n> >> So a bit of background here. This began from thinking about functional\n> >> dependencies, and pondering whether a map of the dependency graph of\n> >> our projects could inform our gating structure, specifically to\n> >> encourage (or dare I say, actually force) all of us (the project\n> >> teams) to become more cognizant of the API contracts we are making\n> >> with each other, and the pain it causes when we break those contracts.\n> >>\n> >> Let\'s not extend this exercise to a gigantic\n> >> everything-needs-everything-to-do-everything picture, which is where\n> >> it\'s heading now. Sure, telemetry is important for operators, and in\n> >> no way am I saying anything else when I say: for Nova to fulfill its\n> >> primary goal, telemetry is not necessary. It is optional. Desired, but\n> >> optional.\n> >\n> > I don\'t follow the optional-but-not-necessary argument here, or\n> > where you\'re applying the cut-off for the graph not turning into\n> > a gigantic picture.\n> >\n> > There were a bunch of relationships in the original graph that\n> > are not strictly necessary for nova to fulfill it\'s primary goal,\n> > but are desired and existing functional dependencies in any case.\n> >\n> \n> For nova to do anything useful at all, it very simply needs an\n> identity service (keystone), an image registry service (glance), and a\n> network service (neutron (ignoring the fact that nova-network is still\n> there because we actually want it to go away)). Without these, Nova is\n> utterly useless.\n> \n> So, from a minimalist compute-centric perspective, THAT\'S IT.\n\nSure, I get that idea of isolating the minimal set of dependencies\nfor the compute use-case.\n\nI was questioning the fact the dependency graph referenced on the\nthread earlier:\n\n  http://i.imgur.com/y8zmNIM.png\n\nselectively included *some* dependencies that lay outside this narrow\nuse-case for nova, but not others.\n\n> > So, are we trying to capture all dependencies here, or to apply\n> > some value-judgement and selectively capture just the good\n> > dependencies, for some definition of good?\n> \n> Nope. I am not making any value judgement whatsoever. I\'m describing\n> dependencies for minimally satisfying the intended purpose of a given\n> project. For example, Nova\'s primary goal is not \"emit telemetry\", it\n> is \"scalable, on demand, self service access to compute resources\" [1]\n> \n> There are a lot of other super-awesome additional capabilities for\n> which Nova depends on other services. And folks want to add more cool\n> things on top of, next to, and underneath this \"ring compute\". And\n> make new non-compute-centric groups of projects. That\'s all wonderful.\n> \n> I happen to also fall in that camp - I think Ironic is a useful\n> service, but I\'m happy for it to not be in that inner ring of\n> codependency. The nova.virt.ironic driver is optional from Nova\'s POV\n> (Nova works fine without it), and Nova is optional from Ironic\'s POV\n> (it\'s a bit awkward, but Ironic can deploy without Nova, though we\'re\n> not testing it like that today).\n> \n> On the other hand, from a minimalist telemetry-centric perspective,\n> what other projects do I need to run Ceilometer? Correct me if I\'m\n> wrong, but I think the answer is \"None\".\n\nAt the very least, ceilometer would need keystone to function.\n\n> Or rather, which ever ones I\n> want. If I\'m running Nova and not running Swift, Ceilometer works with\n> Nova. If I\'m running Swift but not Nova, Ceilometer works with Swift.\n> There\'s no functional dependency on either Nova or Swift here - it\'s\n> just consumption of an API. None of which is bad - but this informs\n> how we gate test these projects, and how we allocate certain resources\n> (like debugging gate-breaking bugs) across projects.\n\nOK, so if project A doesn\'t *need* project B to function minimally,\nbut will use if it\'s available, and it\'s likely to be so in most\nrealistic deployments, then we still need to ensure somehow that\nchanges in project B don\'t break project A.\n\ni.e. even if the dependency isn\'t a strict necessity, it may still\nvery likely be an actual reality in practice.\n\nCheers,\nEoghan\n\n\n','<CAExZKEpLXmmqVJtYE1ZyX6=E58NMfYsC_uH-4Gpw--cmK6m3UA@mail.gmail.com>',NULL),('<1252315091.2.1374127545219.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-18 06:05:45',0,'2013-07-18 06:05:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #290','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/290/>\n\n------------------------------------------\n[...truncated 9008 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.08 secs:\n    0.38    RoleAPITests.test_get_default_role\n    0.23    HorizonTests.test_lazy_urls\n    0.18    DataTableTests.test_summation_row\n    0.16    DataTableTests.test_table_action_attributes\n    0.14    NetworkTests.test_subnet_create_post_cidr_without_mask\n----------------------------------------------------------------------\nRan 350 tests in 7.362s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.U1c1mrrLxo\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/290\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/290/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/290/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<521060908.21.1374041061344.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1252405088.27572377.1407583140710.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 07:19:00',-14400,'2014-08-09 11:19:00',NULL,'[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and\n sqlalchemy for ceilometer in Tempest','\nHi Folks,\n\nDina Belova has recently landed some infra patches[1,2] to create\nan experimental mongodb-based Tempest job. This effectively just\noverrides the ceilometer storage backend config so that mongodb\nis used instead of sql-alchemy. The new job has been running\nhappily for a few days so I\'d like now to consider the path\nforwards with this.\n\nOne of our Juno goals under the TC gap analysis was to more fully\ngate against mongodb, given that this is the storage backend\nrecommended/supported by many distros. The sql-alchemy backend,\non the other hand, is more suited for proofs of concept or small\ndeployments. However up to now we\'ve been hampered from reflecting\nthat reality in the gate, due to the gate being stuck on Precise\nfor a long time, as befits LTS, and the version of mongodb needed\nby ceilometer (i.e. 2.4) effectively unavailable on that Ubuntu\nrelease (in fact it was limited to 2.0.4).\n\nSo the orientation towards gating on sql-alchemy was mostly\ndriven by legacy issues in the gate\'s usage of Precise, as\nopposed to this being considered the most logical basket in\nwhich to put all our testing eggs.\n\nHowever, we\'re now finally in the brave new world of Trusty :)\nSo I would like to make the long-delayed change over soon.\n\nThis would involve transposing the roles of sql-alchemy and\nmongodb in the gate - the mongodb variant becomes the \"blessed\"\njob run by default, whereas the sql-alchemy based job to\nrelegated to the second tier.\n\nSo my questions are:\n\n (a) would the QA side of the house be agreeable to this switch?\n\nand:\n\n (b) how long would the mongodb job need to be stable in this\n     experimental mode before we pull the trigger on swicthing?\n\nIf the answer to (a) is yes, we can get infra patches proposed\nearly next week to make the swap.\n\nCheers,\nEoghan\n\n[1] https://review.openstack.org/#/q/project:openstack-infra/config+branch:master+topic:ceilometer-mongodb-job,n,z\n[2] https://review.openstack.org/#/q/project:openstack-infra/devstack-gate+branch:master+topic:ceilometer-backend,n,z\n\n\n','<1840703325.27571765.1407581720007.JavaMail.zimbra@redhat.com>',NULL),('<1252885492.6.1385273065735.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-24 06:04:25',0,'2013-11-24 06:04:25',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python27-stable-havana #4','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/4/changes>\n\n\n\n','<1707254585.0.1385100266203.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1252914837.223.1366351618757.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-19 06:06:58',0,'2013-04-19 06:06:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #9','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/9/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-19 06:06:54    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:06:54,298 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-19 06:06:54,299 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:06:54,300 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,301 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,301 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-19 06:06:54,302 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-19 06:06:54,303 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-19 06:06:54  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-19 06:06:54,304 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:06:54    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:06:54,305 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,310 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.310191\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.310191\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54,311 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,312 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,313 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,314 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54,315 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.314772\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.314772\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54,316 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,317 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,318 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:06:54,319 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,320 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,321 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54,322 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.321553\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.321553\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54,323 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,324 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,325 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:06:54,325 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,326 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,328 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54,329 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.328403\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.328403\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54,330 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,331 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,332 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:06:54,334 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,336 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,340 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:06:54,344 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:06:54,347 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.344552\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:06:54.344552\', resource_metadata={}) from 0 transformer\n2013-04-19 06:06:54,349 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,351 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54,353 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:06:54,354 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:06:54,355 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.793s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.9\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a329.g7c2b662\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.M9QnMta5Td\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/9\n[SCP] Copying console log.\n\n\n','<154610874.205.1366265219402.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1253055624.63.1367734957926.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-05 06:22:37',0,'2013-05-05 06:22:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #5','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/5/>\n\n------------------------------------------\n[...truncated 12586 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for f7a561f8a3ce462085bdaef576db1325 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:56114\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:56114/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (18429) wsgi starting up on http://127.0.0.1:56114/\n\nnova.osapi_compute.wsgi.server: INFO: (18429) accepted (\'127.0.0.1\', 37490)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [05/May/2013 06:17:32] \"GET /v2 HTTP/1.1\" 204 216 0.001047\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-158a20f7-16c9-4d61-951c-980b8bb6e74a</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (18429) accepted (\'127.0.0.1\', 37491)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa17f210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa17f210>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:56114/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:56114/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [05/May/2013 06:17:33] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.246367\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 87ced54553344e60abefb58864797f4d \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:42560\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:42560/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (18429) wsgi starting up on http://127.0.0.1:42560/\n\nnova.osapi_compute.wsgi.server: INFO: (18429) accepted (\'127.0.0.1\', 51197)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [05/May/2013 06:17:33] \"GET /v2 HTTP/1.1\" 204 216 0.001019\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-bea94033-b16d-4594-9d66-f4b7fa8c7037</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (18429) accepted (\'127.0.0.1\', 51198)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1eff50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1eff50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:42560/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     name)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-05 06:17:33 18429 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:42560/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [05/May/2013 06:17:33] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.417565\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.yle0M5AR28\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/5\n[SCP] Copying console log.\n\n\n','<1836076943.42.1367648526778.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1253333597.55136.1387464450699.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 15:47:30',3600,'2013-12-19 14:47:30',NULL,'[openstack-dev] [nova] VM diagnostics - V3 proposal','I think it was:\n\nceilometer sample-list -m cpu_util -q \'resource_id=vm_uuid\'\n\nVladik\n\n----- Original Message -----\n> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> To: \"John Garbutt\" <john at johngarbutt.com>\n> Cc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, 19 December, 2013 9:34:02 AM\n> Subject: Re: [openstack-dev] [nova] VM diagnostics - V3 proposal\n> \n> On Thu, Dec 19, 2013 at 02:27:40PM +0000, John Garbutt wrote:\n> > On 16 December 2013 15:50, Daniel P. Berrange <berrange at redhat.com> wrote:\n> > > On Mon, Dec 16, 2013 at 03:37:39PM +0000, John Garbutt wrote:\n> > >> On 16 December 2013 15:25, Daniel P. Berrange <berrange at redhat.com>\n> > >> wrote:\n> > >> > On Mon, Dec 16, 2013 at 06:58:24AM -0800, Gary Kotton wrote:\n> > >> >> I\'d like to propose the following for the V3 API (we will not touch\n> > >> >> V2\n> > >> >> in case operators have applications that are written against this ?\n> > >> >> this\n> > >> >> may be the case for libvirt or xen. The VMware API support was added\n> > >> >> in I1):\n> > >> >>\n> > >> >>  1.  We formalize the data that is returned by the API [1]\n> > >> >\n> > >> > Before we debate what standard data should be returned we need\n> > >> > detail of exactly what info the current 3 virt drivers return.\n> > >> > IMHO it would be better if we did this all in the existing wiki\n> > >> > page associated with the blueprint, rather than etherpad, so it\n> > >> > serves as a permanent historical record for the blueprint design.\n> > >>\n> > >> +1\n> > >>\n> > >> > While we\'re doing this I think we should also consider whether\n> > >> > the \'get_diagnostics\' API is fit for purpose more generally.\n> > >> > eg currently it is restricted to administrators. Some, if\n> > >> > not all, of the data libvirt returns is relevant to the owner\n> > >> > of the VM but they can not get at it.\n> > >>\n> > >> Ceilometer covers that ground, we should ask them about this API.\n> > >\n> > > If we consider what is potentially in scope for ceilometer and\n> > > subtract that from what the libvirt get_diagnostics impl currently\n> > > returns, you pretty much end up with the empty set. This might cause\n> > > us to question if \'get_diagnostics\' should exist at all from the\n> > > POV of the libvirt driver\'s impl. Perhaps vmware/xen return data\n> > > that is out of scope for ceilometer ?\n> > \n> > Hmm, a good point.\n> \n> So perhaps I\'m just being dumb, but I deployed ceilometer and could\n> not figure out how to get it to print out the stats for a single\n> VM from its CLI ? eg, can someone show me a command line invocation\n> for ceilometer that displays CPU, memory, disk and network I/O stats\n> in one go ?\n> \n> \n> Daniel\n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<20131219143402.GE6573@redhat.com>',NULL),('<1253488217.41.1383372197103.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:03:17',0,'2013-11-02 06:03:17',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-cinder-python26-stable-grizzly #53','See <https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/53/>\n\n\n\n',NULL,NULL),('<1253907007.8.1385359315378.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-25 06:01:55',0,'2013-11-25 06:01:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #70','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/70/>\n\n------------------------------------------\n[...truncated 638 lines...]\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 13.639s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.18.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.70\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.6\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.12.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.8\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\nwarlock==1.1.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.YKxogSf1Kc\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise2/70\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1254683663.1141167.1379691517420.JavaMail.root@telecom-lille.fr>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-20 17:38:37',7200,'2013-09-20 15:38:37',NULL,'[Openstack] mapping between VNC ports and instances','Hi,\n\nOn the compute node console, with KVM/libvirt, I use \"ps | grep\" command\n\n# ps -edf | grep instance-xxxx\n\nor to list all instances\n\n# ps -edf | grep kvm | grep vnc\n\nIf you know the libvirt domainname or domainid (*) of your instance, you can also use the virsh vncdisplay command\n- locally on the compute-node console\n              # virsh -c qemu:///system vncdisplay <domain>\n- remotely\n              # virsh -c qemu://compute-node-address/system vncdisplay <domain>\n\n(*) domainname or domainid can be displayed using the \"virsh list\" command\n\nHope, this can help.\n\nJacques Landru\n\n\n\n    -----oOo-----\n Jacques Landru\n   mel:  landru~hat~telecom-lille.fr\n   tel:  +33 (0)3 2033 5556\n   fax:  +33 (0)3 2033 5598\n\n Telecom Lille\n Cite scientifique, rue G. Marconi, BP20145\n 59653 VILLENEUVE D\'ASCQ  Cedex\n  web: http://www.telecom-lille.fr\n  Tel: +33 (0)3 2033 5577 \n  Fax: +33 (0)3 2033 5599 \n    -----oOo-----\n\n\n\n----- Mail original -----\nDe: \"Nicolae Paladi\" <n.paladi at gmail.com>\n?: openstack at lists.openstack.org\nEnvoy?: Vendredi 20 Septembre 2013 13:47:38\nObjet: [Openstack] mapping between VNC ports and instances\n\nHi, is there a quick way (console or GUI) to find out \nthe mapping between VNC ports active instances? \n\nIn other words, how do I know which VNC port should be used to \nreach a particular instance? \n\nCheers, \n/Nicolae \n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<CAK0-rpYXSg7pi6aJHLR3OCChmJ578R1U5jonPbu81fgE6r2pbA@mail.gmail.com>',NULL),('<1255205416.12410990.1384301871265.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 16:17:51',-28800,'2013-11-13 00:17:51',NULL,'[openstack-dev] Custom Flavor creation through Heat','not the video I was looking for, but he kind of makes the point about planning...\nhttp://youtu.be/2E0C9zLSINE?t=42m55s\n\n# Shawn Hartsock\n\n\n----- Original Message -----\n> From: \"Shawn Hartsock\" <hartsocks at vmware.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, November 12, 2013 6:38:21 PM\n> Subject: Re: [openstack-dev] Custom Flavor creation through Heat\n> \n> \n> \n> ----- Original Message -----\n> > From: \"Yunhong Jiang\" <yunhong.jiang at intel.com>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > <openstack-dev at lists.openstack.org>\n> > Sent: Tuesday, November 12, 2013 5:39:58 PM\n> > Subject: Re: [openstack-dev] Custom Flavor creation through Heat\n> > > -----Original Message-----\n> > > From: Shawn Hartsock [mailto:hartsocks at vmware.com]\n> > > Sent: Tuesday, November 12, 2013 12:56 PM\n> > > To: OpenStack Development Mailing List (not for usage questions)\n> > > Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through\n> > > Heat\n> > > \n> > > My concern with proliferating custom flavors is that it might play havoc\n> > > with the underlying root-case for flavors.\n> > > \n> > > My understanding of flavors is that they are used to solve the resource\n> > > packing problem in elastic cloud scenarios. That way you know that 256\n> > > \"tiny\" VMs fit cleanly into your hardware layout and so do 128 \"medium\"\n> > > VMs and 64 large VMs. If you allow \"flavor of the week\" then the packing\n> > > problem re-asserts itself and scheduling becomes harder.\n> > \n> > I\'m a bit surprised that the flavor is used to resolve the packing problem.\n> > I\n> > thought it should be handled by scheduler, although it\'s a NP problem.\n> \n> I should have said \"flavors help to make the packing problem simpler for the\n> scheduler\" ... flavors do not \"solve\" the packing problem.\n> \n> > \n> > As for custom flavor, I think at least it\'s against current nova\n> > assumption.\n> > Currently nova assume flavor should only be created by admin, who knows the\n> > cloud quite well.\n> > One example is, flavor may contain extra-spec, so if an extra-spec value is\n> > specified in the flavor, while the corresponding scheduler filter is not\n> > enabled, then the extra-spec has no effect and may cause issue.\n> > \n> \n> Beyond merely extra-specs my understanding was that because you *have*\n> flavors you can make assumptions about packing that make the problem space\n> smaller... someone made a nice presentation showing how having restricted\n> flavors made scheduling easier. I can\'t find it right now. It was presented\n> at an OpenStack summit IIRC.\n> \n> \n\n\n','<762999560.12374130.1384299501701.JavaMail.root@vmware.com>',NULL),('<1255238029.51.1383458486573.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:01:26',0,'2013-11-03 06:01:26',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-keystone-docs-stable-folsom #54','See <https://jenkins01.openstack.org/job/periodic-keystone-docs-stable-folsom/54/>\n\n\n\n','<1006443029.34.1383372171247.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1255359041.25.1374041765727.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-17 06:16:05',0,'2013-07-17 06:16:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #289','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/289/>\n\n------------------------------------------\n[...truncated 947 lines...]\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.19\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.02\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: test_ownership (glance.tests.functional.v1.test_api.TestApi)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 1367, in test_ownership\n    self.assertEqual(response.status, 201)\nAssertionError: 500 != 201\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (500, 201))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.45 secs:\n    23.89    TestGlanceControl.test_bouncing\n    18.20    TestBinGlanceCacheManage.test_queue\n    17.24    TestRootApi.test_version_configurations\n    16.68    TestScrubber.test_delayed_delete\n    16.43    TestBinGlance.test_results_filtering\n----------------------------------------------------------------------\nRan 926 tests in 742.944s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python26-stable-folsom-289\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npbr==0.5.18\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Xha82CFmAp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/289\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/289/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<300817759.18.1373955421150.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1256760854.39611386.1407781437450.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-11 14:23:57',-14400,'2014-08-11 18:23:57',NULL,'[Openstack-docs] Proposal: Bug Squashing day on the 9th\n	of	September','I like the idea and the 9th is currently as good as any for me :).\n\n-Steve\n\n----- Original Message -----\n> From: \"Christian Berendt\" <berendt at b1-systems.de>\n> To: openstack-docs at lists.openstack.org\n> Sent: Friday, August 8, 2014 2:28:28 AM\n> Subject: Re: [Openstack-docs] Proposal: Bug Squashing day on the 9th of	September\n> \n> On 08/07/2014 09:18 PM, Andreas Jaeger wrote:\n> > My answer: I like to join and will be able to do so for a few hours,\n> \n> Dito.\n> \n> Christian.\n> \n> --\n> Christian Berendt\n> Cloud Computing Solution Architect\n> Mail: berendt at b1-systems.de\n> \n> B1 Systems GmbH\n> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de\n> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<53E46E0C.8000007@b1-systems.de>',NULL),('<125756499.18511485.1392051242189.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-10 16:54:02',0,'2014-02-10 16:54:02',NULL,'[openstack-dev] [Nova][Scheduler] Policy Based Scheduler and\n Solver Scheduler','> I\'m not sure what you mean by \"whatever it takes to finally create the\n> instances\", but that sounds like what I had assumed everybody meant by\n> \"orchestration\" (until I heard that there is no widespread agreement) ---\n> and I think we need to take a properly open approach to that.  I think the\n> proper API for cross-service whole-pattern scheduling should primarily\n> focus on conveying the placement problem to the thing that will make the\n> joint decision.  After the joint decision is made comes the time to create\n> the individual resources.  I think we can NOT mandate one particular agent\n> or language for that.  We will have to allow general clients to make calls\n> on Nova, Cinder, etc. to do the individual resource creations (with some\n> sort of reference to the decision that was already made).  My original\n> position was that we could use Heat for this, but I think we have gotten\n> push-back saying it is NOT OK to *require* that.  For example, note that\n> some people do not want to use Heat at all, they prefer to make individual\n> calls on Nova, Cinder, etc.  Of course, we definitely want to support,\n> among others, the people who *do* use Heat.\n\nI do not think Heat would be appropriate, either. Heat does not have the\ndetailed knowledges on the infrastructure and it uses Nova (Gantt) API to\npass the command, so if Nova (Gantt) API does not support multiple instances\nprovisioning, Heat will not get the joint decision for all VMs as a whole. Heat\nmay orchestrate the provisioning process, but eventually the instances will be\npassed to Nova-scheduler (Gantt) as separated commands, which is exactly the\nproblem Solver Scheduler wants to correct. Therefore the Instance Group API is\nneeded, wherever it is used (nova-scheduler/Gantt).\n\nI think Gantt should be the cross-service joint decision point. Heat still keeps\norchestrating processes like it always does, but the provisioning decision has\nto be made all together as one atomic step in Heat\'s whole process.\n\n> Here\'s a more detailed description of our thoughts on how such a protocol might\n> look: \n> https://wiki.openstack.org/wiki/Nova/PlacementAdvisorAndEngine \n> We\'ve concentrated on the Nova scheduler; Would be interesting to see if this\n> protocol aligns with Yathiraj\'s thoughts on a global scheduler addressing\n> compute+storage+network. \n> Feedback is most welcome. \n\nThank you for the link, I will give it a try.\n\nBest regards,\n\nToan\n\n\n----- Original Message -----\n> From: \"Mike Spreitzer\" <mspreitz at us.ibm.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, February 4, 2014 9:05:22 AM\n> Subject: Re: [openstack-dev] [Nova][Scheduler] Policy Based Scheduler and Solver Scheduler\n> \n> > From: Khanh-Toan Tran <khanh-toan.tran at cloudwatt.com>\n> ...\n> > There is an unexpected line break in the middle of the link, so I post\n> it\n> > again:\n> > \n> > \n> https://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOri\n> > IQB2Y\n> \n> The mailing list software keeps inserting that line break.  I\n> re-constructed the URL and looked at the document.  As you point out at\n> the end, the way you attempt to formulate load balancing as a linear\n> objective does not work.  I think load-balancing is a non-linear thing.\n> \n> I also doubt that simple load balancing is what cloud providers want; I\n> think cloud providers want to bunch up load, within limits, for example to\n> keep some hosts idle so that they can be powered down to save on costs or\n> left available for future exclusive use.\n> \n> \n> > From: Gil Rapaport <GILR at il.ibm.com>\n> ...\n> > As Alex Glikson hinted a couple of weekly meetings ago, our approach\n> > to this is to think of the driver\'s work as split between two entities:\n> > -- A Placement Advisor, that constructs placement problems for\n> > scheduling requests (filter-scheduler and policy-based-scheduler)\n> > -- A Placement Engine, that solves placement problems (HostManager\n> > in get_filtered_hosts() and solver-scheduler with its LP engine).\n> \n> Yes, I see the virtue in that separation.  Let me egg it on a little. What\n> Alex and KTT want is more structure in the Placement Advisor, where there\n> is a multiplicity of plugins, each bound to some fraction of the whole\n> system, and a protocol for combining the advice from the plugins.  I would\n> also like to remind you of another kind of structure: some of the\n> placement desiderata come from the cloud users, and some from the cloud\n> provider.\n> \n> \n> > From: \"Yathiraj Udupi (yudupi)\" <yudupi at cisco.com>\n> ...\n> > Like you point out, I do agree the two entities of placement\n> > advisor, and the placement engine, but I think there should be a\n> > third one ? the provisioning engine, which should be responsible for\n> > whatever it takes to finally create the instances, after the\n> > placement decision has been taken.\n> \n> I\'m not sure what you mean by \"whatever it takes to finally create the\n> instances\", but that sounds like what I had assumed everybody meant by\n> \"orchestration\" (until I heard that there is no widespread agreement) ---\n> and I think we need to take a properly open approach to that.  I think the\n> proper API for cross-service whole-pattern scheduling should primarily\n> focus on conveying the placement problem to the thing that will make the\n> joint decision.  After the joint decision is made comes the time to create\n> the individual resources.  I think we can NOT mandate one particular agent\n> or language for that.  We will have to allow general clients to make calls\n> on Nova, Cinder, etc. to do the individual resource creations (with some\n> sort of reference to the decision that was already made).  My original\n> position was that we could use Heat for this, but I think we have gotten\n> push-back saying it is NOT OK to *require* that.  For example, note that\n> some people do not want to use Heat at all, they prefer to make individual\n> calls on Nova, Cinder, etc.  Of course, we definitely want to support,\n> among others, the people who *do* use Heat.\n> \n> \n> > From: \"Yathiraj Udupi (yudupi)\" <yudupi at cisco.com>\n> ...\n> > The solver-scheduler is designed to solve for an arbitrary list of\n> > instances of different flavors. We need to have some updated apis in\n> > the scheduler to be able to pass on such requests. Instance group\n> > api is an initial effort to specify such groups.\n> \n> I\'ll remind the other readers of our draft of such a thing, at\n> \n> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA\n> \n> (you will have to re-assemble the URL if the ML software broke it for you)\n> \n> My take-aways from the Icehouse summit\'s review of that are as follows.\n> \n> (1) do NOT put orchestration under the covers (as I said above), allow\n> general clients to make the calls to create the individual resources.\n> \n> (2) The community was not convinced that this would scale as needed.\n> \n> (3) There were some remarks about \"too complicated\" but I am not clear on\n> whether the issue(s) were: (a) there was not clear/compelling motivation\n> for some of the expressiveness offered, (b) there is a simpler way to\n> accomplish the same things, (c) it\'s all good but more than we can take on\n> now, and/or (d) something else I did not get.\n> \n> \n> Regards,\n> Mike\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<OFB2275134.B4640B71-ON85257C75.00294058-85257C75.002C6FB9@us.ibm.com>',NULL),('<1257606601.37.1385877879692.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-01 06:04:39',0,'2013-12-01 06:04:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #74','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/74/>\n\n------------------------------------------\n[...truncated 7126 lines...]\n2013-12-01 06:04:22 + local file=/etc/cinder/cinder.conf\n2013-12-01 06:04:22 + local section=DEFAULT\n2013-12-01 06:04:22 + local option=secure_delete\n2013-12-01 06:04:22 + local line\n2013-12-01 06:04:22 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-01 06:04:22 + line=\n2013-12-01 06:04:22 + \'[\' -n \'\' \']\'\n2013-12-01 06:04:22 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-01 06:04:22 secure_delete = False\n2013-12-01 06:04:22 \' /etc/cinder/cinder.conf\n2013-12-01 06:04:22 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-12-01 06:04:22 + local file=/etc/cinder/cinder.conf\n2013-12-01 06:04:22 + local section=DEFAULT\n2013-12-01 06:04:22 + local option=volume_clear\n2013-12-01 06:04:22 + local value=none\n2013-12-01 06:04:22 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-12-01 06:04:22 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-12-01 06:04:22 + local file=/etc/cinder/cinder.conf\n2013-12-01 06:04:22 + local section=DEFAULT\n2013-12-01 06:04:22 + local option=volume_clear\n2013-12-01 06:04:22 + local line\n2013-12-01 06:04:22 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-12-01 06:04:22 + line=\n2013-12-01 06:04:22 + \'[\' -n \'\' \']\'\n2013-12-01 06:04:22 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-12-01 06:04:22 volume_clear = none\n2013-12-01 06:04:22 \' /etc/cinder/cinder.conf\n2013-12-01 06:04:22 + \'[\' False == True \']\'\n2013-12-01 06:04:22 + \'[\' default == XenAPINFS \']\'\n2013-12-01 06:04:22 + \'[\' default == sheepdog \']\'\n2013-12-01 06:04:22 + is_service_enabled quantum\n2013-12-01 06:04:22 + services=quantum\n2013-12-01 06:04:22 + for service in \'${services}\'\n2013-12-01 06:04:22 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-12-01 06:04:22 + return 0\n2013-12-01 06:04:22 + install_quantum\n2013-12-01 06:04:22 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-12-01 06:04:22 + [[ False = \\T\\r\\u\\e ]]\n2013-12-01 06:04:22 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-12-01 06:04:22 + GIT_DEST=/opt/stack/new/neutron\n2013-12-01 06:04:22 + GIT_REF=stable/grizzly\n2013-12-01 06:04:22 + echo stable/grizzly\n2013-12-01 06:04:22 + egrep -q \'^refs\'\n2013-12-01 06:04:22 + [[ ! -d /opt/stack/new/neutron ]]\n2013-12-01 06:04:22 + [[ \'\' == \\y\\e\\s ]]\n2013-12-01 06:04:22 + setup_develop /opt/stack/new/neutron\n2013-12-01 06:04:22 + [[ False = True ]]\n2013-12-01 06:04:22 + SUDO_CMD=sudo\n2013-12-01 06:04:22 + cd /opt/stack/new/neutron\n2013-12-01 06:04:22 + python setup.py egg_info\n2013-12-01 06:04:22 running egg_info\n2013-12-01 06:04:22 creating quantum.egg-info\n2013-12-01 06:04:22 writing requirements to quantum.egg-info/requires.txt\n2013-12-01 06:04:22 writing quantum.egg-info/PKG-INFO\n2013-12-01 06:04:22 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-01 06:04:22 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-01 06:04:22 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-01 06:04:22 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-01 06:04:22 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-01 06:04:22 reading manifest template \'MANIFEST.in\'\n2013-12-01 06:04:22 warning: no files found matching \'AUTHORS\'\n2013-12-01 06:04:22 warning: no files found matching \'ChangeLog\'\n2013-12-01 06:04:22 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-01 06:04:23 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-01 06:04:23 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-01 06:04:23 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-01 06:04:23 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-12-01 06:04:23 + raw_links=\n2013-12-01 06:04:23 ++ echo\n2013-12-01 06:04:23 ++ xargs\n2013-12-01 06:04:23 + depend_links=\n2013-12-01 06:04:23 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-12-01 06:04:23 ++ echo \'-r *-info/requires.txt\'\n2013-12-01 06:04:23 + require_file=\'-r *-info/requires.txt\'\n2013-12-01 06:04:23 + pip_install -r quantum.egg-info/requires.txt\n2013-12-01 06:04:23 + [[ False = \\T\\r\\u\\e ]]\n2013-12-01 06:04:23 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-12-01 06:04:23 + [[ -z deb ]]\n2013-12-01 06:04:23 + [[ False = True ]]\n2013-12-01 06:04:23 + SUDO_PIP=sudo\n2013-12-01 06:04:23 ++ get_pip_command\n2013-12-01 06:04:23 ++ is_fedora\n2013-12-01 06:04:23 ++ [[ -z Ubuntu ]]\n2013-12-01 06:04:23 ++ \'[\' Ubuntu = Fedora \']\'\n2013-12-01 06:04:23 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-12-01 06:04:23 ++ \'[\' Ubuntu = CentOS \']\'\n2013-12-01 06:04:23 ++ which pip\n2013-12-01 06:04:23 + CMD_PIP=/usr/local/bin/pip\n2013-12-01 06:04:23 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-12-01 06:04:23 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-12-01 06:04:23 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:23   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-12-01 06:04:23   Running setup.py egg_info for package python-quantumclient\n2013-12-01 06:04:23     [pbr] Processing SOURCES.txt\n2013-12-01 06:04:23     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-12-01 06:04:23     \n2013-12-01 06:04:23     [pbr] In git context, generating filelist from git\n2013-12-01 06:04:23     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-12-01 06:04:23 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:23 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-12-01 06:04:25   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.1.tar.gz\n2013-12-01 06:04:25   Running setup.py egg_info for package alembic\n2013-12-01 06:04:25     \n2013-12-01 06:04:25     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-01 06:04:25     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-01 06:04:25     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-01 06:04:25     no previously-included directories found matching \'docs/build/output\'\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-01 06:04:25   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-12-01 06:04:25   Running setup.py egg_info for package Mako\n2013-12-01 06:04:25     \n2013-12-01 06:04:25     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-01 06:04:25     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-01 06:04:25     warning: no files found matching \'ez_setup.py\'\n2013-12-01 06:04:25     no previously-included directories found matching \'doc/build/output\'\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-12-01 06:04:25 Installing collected packages: python-quantumclient, alembic, Mako\n2013-12-01 06:04:25   Running setup.py install for python-quantumclient\n2013-12-01 06:04:25     [pbr] Reusing existing SOURCES.txt\n2013-12-01 06:04:25     Installing quantum script to /usr/local/bin\n2013-12-01 06:04:25   Running setup.py install for alembic\n2013-12-01 06:04:25     \n2013-12-01 06:04:25     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-12-01 06:04:25     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-12-01 06:04:25     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-12-01 06:04:25     no previously-included directories found matching \'docs/build/output\'\n2013-12-01 06:04:25     Installing alembic script to /usr/local/bin\n2013-12-01 06:04:25   Running setup.py install for Mako\n2013-12-01 06:04:25     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-12-01 06:04:25     \n2013-12-01 06:04:25     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-12-01 06:04:25     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-12-01 06:04:25     warning: no files found matching \'ez_setup.py\'\n2013-12-01 06:04:25     no previously-included directories found matching \'doc/build/output\'\n2013-12-01 06:04:25     changing mode of /usr/local/bin/mako-render to 755\n2013-12-01 06:04:25 Successfully installed python-quantumclient alembic Mako\n2013-12-01 06:04:25 Cleaning up...\n2013-12-01 06:04:25 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-12-01 06:04:25 running develop\n2013-12-01 06:04:25 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-12-01 06:04:25 /usr/bin/python -E -c pass\n2013-12-01 06:04:25 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-12-01 06:04:25 running egg_info\n2013-12-01 06:04:25 writing requirements to quantum.egg-info/requires.txt\n2013-12-01 06:04:25 writing quantum.egg-info/PKG-INFO\n2013-12-01 06:04:25 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-12-01 06:04:25 writing top-level names to quantum.egg-info/top_level.txt\n2013-12-01 06:04:25 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-12-01 06:04:25 writing entry points to quantum.egg-info/entry_points.txt\n2013-12-01 06:04:25 reading manifest template \'MANIFEST.in\'\n2013-12-01 06:04:25 warning: no files found matching \'AUTHORS\'\n2013-12-01 06:04:25 warning: no files found matching \'ChangeLog\'\n2013-12-01 06:04:25 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-12-01 06:04:25 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-12-01 06:04:25 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-12-01 06:04:25 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-12-01 06:04:25 running build_ext\n2013-12-01 06:04:25 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-12-01 06:04:25 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-12-01 06:04:25 Installing quantum-debug script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-nec-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-ryu-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-l3-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-db-manage script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-metadata-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-server script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-12-01 06:04:25 Installing quantum-rootwrap script to /usr/local/bin\n2013-12-01 06:04:25 \n2013-12-01 06:04:25 Installed /opt/stack/new/neutron\n2013-12-01 06:04:25 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-12-01 06:04:25 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-12-01 06:04:25 ++ failed\n2013-12-01 06:04:25 ++ local r=1\n2013-12-01 06:04:25 +++ jobs -p\n2013-12-01 06:04:25 ++ kill\n2013-12-01 06:04:25 ++ set +o xtrace\n2013-12-01 06:04:25 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-12-01-060150\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-766179-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-766179.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-766179/74/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2124452194.36.1385791487567.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1257639623.21865010.1403505869040.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 02:44:29',-14400,'2014-06-23 06:44:29',NULL,'[openstack-dev] [Neutron] default security group rules in\n neutron','\n   I believe it\'s an important feature, because currently\nthe default security rules are hard-coded in neutron\'s code,\nand that won\'t fit all organizations (not to say that the\ndefault security rules won\'t scale well on our current\nimplementation).\n\n   Best,\nMiguel ?ngel\n  \n\n\n\n----- Mensaje original -----\n> Greetings\n> \n> We use neutron as network functionality implementation in nova, and as\n> you know, there is a feature called \'os-security-group-default-rules\'\n> in nova extension[1], a hook mechanism to add customized rules when\n> creating default security groups, which is a very useful feature to\n> the administrators or operators (at least useful to us in our\n> deployment). But I found this feature is valid only when using\n> nova-network.\n> \n> So, for the functionality parity between nova-network and neutron and\n> for our use case, I registered a blueprint[2] about default security\n> group rules in Neutron days ago and related neutron spec[3], and I\n> want it to be involved in Juno, so we can upgrade our deployment that\n> time for this feature. I\'m ready for the code implementation[3].\n> \n> But I still want to see what\'s the community\'s thought about including\n> this feature in neutron, any of your feedback and comments are\n> appreciated!\n> \n> [1]\n> https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group\n> [2]\n> https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group\n> [3] https://review.openstack.org/98966\n> [4] https://review.openstack.org/99320\n> \n> --\n> Regards!\n> -----------------------------------\n> Lingxian Kong\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CALjNAZ1i_udH+nJmyv_NG2cL8sa1FqccBO2jxPexNBDae7acWQ@mail.gmail.com>',NULL),('<1258249207.18262347.1401709312371.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-02 07:41:52',-14400,'2014-06-02 11:41:52',NULL,'[Openstack] [ceilometer] ERROR in collector : Failed to\n	record	metering data','\nYou need to run:\n\n  ceilometer-dbsync --config-file /etc/ceilometer/ceilometer.conf\n\nin order to create the required schema in the database.\n\nCheers,\nEoghan\n\n----- Original Message -----\n> \n> \n> Hi all,\n> \n> \n> \n> I am trying to use mysql as database for ceilometer. I created database as\n> follows\n> \n> CREATE DATABASE ceilometer;\n> \n> \n> \n> GRANT ALL PRIVILEGES ON ceilometer.* TO \'ceilometer\'@\'localhost\' \\\n> \n> IDENTIFIED BY \'CEILOMETER_DBPASS\';\n> \n> \n> \n> GRANT ALL PRIVILEGES ON ceilometer.* TO \'ceilometer\'@\'%\' \\\n> \n> IDENTIFIED BY \'CEILOMETER_DBPASS\';\n> \n> \n> \n> And mentioned it in ceilometer conf file.\n> \n> connection=mysql://ceilometer:CEILOMETER_DBPASS at 100.30.30.221/ceilometer?charset=utf8\n> \n> \n> \n> But ceilometer collector is failing to create metering data\n> \n> \n> \n> root at koteswar-ice-osc:~# ceilometer meter-list\n> \n> WARNING (http:172) Request returned failure status.\n> \n> HTTPInternalServerError (HTTP 500)\n> \n> \n> \n> LOG:\n> \n> 2014-06-01 22:26:41.220 32219 ERROR ceilometer.dispatcher.database\n> [req-c0453bd8-2849-4cfb-9698-3032f65e4d32 - - - - -] Failed to record\n> metering data: (ProgrammingError) (1146, \"Table \'ceilometer.source\' doesn\'t\n> exist\") \'SELECT source.id AS source_id \\nFROM source \\nWHERE source.id = %s\'\n> (\'openstack\',)\n> \n> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database Traceback\n> (most recent call last):\n> \n> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database File\n> \"/usr/lib/python2.7/dist-packages/ceilometer/dispatcher/database.py\", line\n> 67, in record_metering_data\n> \n> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database\n> self.storage_conn.record_metering_data(meter)\n> \n> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database File\n> \"/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_sqlalchemy.py\",\n> line 322, in record_metering_data\n> \n> 2014-06-01 22:26:41.220 32219 TRACE ceilometer.dispatcher.database\n> data[\'source\'])\n> \n> \n> \n> Am I missed anything here? Please give me some pointers to ?how to use mysql\n> for celometer?.\n> \n> It is working fine with mongoDB but failing with MYSQL with the above errors.\n> \n> \n> \n> Thanks in advance,\n> \n> Koteswar\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n','<9608BD1695C1AC489D33B236259C2C1F666E26@G9W0338.americas.hpqcorp.net>',NULL),('<1258323712.54.1373350477495.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-09 06:14:37',0,'2013-07-09 06:14:37',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #90','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/90/>\n\n\n\n','<76706576.49.1373264200404.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<125835530.1.1386915374375.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:16:14',0,'2013-12-13 06:16:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-docs-grizzly #10','See <https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/10/>\n\n------------------------------------------\n[...truncated 103 lines...]\nGenerating doc/source/api/cinder.api.xmlutil.rst\nGenerating doc/source/api/cinder.backup.api.rst\nGenerating doc/source/api/cinder.backup.manager.rst\nGenerating doc/source/api/cinder.backup.rpcapi.rst\nGenerating doc/source/api/cinder.backup.services.swift.rst\nGenerating doc/source/api/cinder.common.sqlalchemyutils.rst\nGenerating doc/source/api/cinder.compute.aggregate_states.rst\nGenerating doc/source/api/cinder.context.rst\nGenerating doc/source/api/cinder.db.api.rst\nGenerating doc/source/api/cinder.db.base.rst\nGenerating doc/source/api/cinder.db.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.api.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.001_cinder_init.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.002_quota_class.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.003_glance_metadata.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.004_volume_type_to_uuid.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.005_add_source_volume_column.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.006_snapshots_add_provider_location.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.007_add_volume_snapshot_fk.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.008_add_backup.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.009_add_snapshot_metadata_table.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.models.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.session.rst\nGenerating doc/source/api/cinder.exception.rst\nGenerating doc/source/api/cinder.flags.rst\nGenerating doc/source/api/cinder.image.glance.rst\nGenerating doc/source/api/cinder.image.image_utils.rst\nGenerating doc/source/api/cinder.manager.rst\nGenerating doc/source/api/cinder.openstack.common.context.rst\nGenerating doc/source/api/cinder.openstack.common.exception.rst\nGenerating doc/source/api/cinder.openstack.common.excutils.rst\nGenerating doc/source/api/cinder.openstack.common.fileutils.rst\nGenerating doc/source/api/cinder.openstack.common.gettextutils.rst\nGenerating doc/source/api/cinder.openstack.common.importutils.rst\nGenerating doc/source/api/cinder.openstack.common.jsonutils.rst\nGenerating doc/source/api/cinder.openstack.common.local.rst\nGenerating doc/source/api/cinder.openstack.common.lockutils.rst\nGenerating doc/source/api/cinder.openstack.common.log.rst\nGenerating doc/source/api/cinder.openstack.common.network_utils.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.api.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.policy.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.filters.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.wrapper.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.common.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker_redis.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.service.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.availability_zone_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.capabilities_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.extra_specs_ops.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.json_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.weight.rst\nGenerating doc/source/api/cinder.openstack.common.setup.rst\nGenerating doc/source/api/cinder.openstack.common.strutils.rst\nGenerating doc/source/api/cinder.openstack.common.timeutils.rst\nGenerating doc/source/api/cinder.openstack.common.uuidutils.rst\nGenerating doc/source/api/cinder.openstack.common.version.rst\nGenerating doc/source/api/cinder.policy.rst\nGenerating doc/source/api/cinder.quota.rst\nGenerating doc/source/api/cinder.scheduler.chance.rst\nGenerating doc/source/api/cinder.scheduler.driver.rst\nGenerating doc/source/api/cinder.scheduler.filter_scheduler.rst\nGenerating doc/source/api/cinder.scheduler.filters.capacity_filter.rst\nGenerating doc/source/api/cinder.scheduler.filters.retry_filter.rst\nGenerating doc/source/api/cinder.scheduler.host_manager.rst\nGenerating doc/source/api/cinder.scheduler.manager.rst\nGenerating doc/source/api/cinder.scheduler.rpcapi.rst\nGenerating doc/source/api/cinder.scheduler.scheduler_options.rst\nGenerating doc/source/api/cinder.scheduler.simple.rst\nGenerating doc/source/api/cinder.scheduler.weights.capacity.rst\nGenerating doc/source/api/cinder.service.rst\nGenerating doc/source/api/cinder.test.rst\nGenerating doc/source/api/cinder.tests.api.common.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_admin_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_backups.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_extended_snapshot_attributes.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_hosts.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_services.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_manage.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_host_attribute.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_image_metadata.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_tenant_attribute.rst\nGenerating doc/source/api/cinder.tests.api.extensions.foxinsocks.rst\nGenerating doc/source/api/cinder.tests.api.fakes.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_auth.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_faults.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_sizelimit.rst\nGenerating doc/source/api/cinder.tests.api.openstack.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_common.rst\nGenerating doc/source/api/cinder.tests.api.test_extensions.rst\nGenerating doc/source/api/cinder.tests.api.test_router.rst\nGenerating doc/source/api/cinder.tests.api.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_xmlutil.rst\nGenerating doc/source/api/cinder.tests.api.v1.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volume_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volumes.rst\nGenerating doc/source/api/cinder.tests.api.v2.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_volumes.rst\nGenerating doc/source/api/cinder.tests.backup.fake_service.rst\nGenerating doc/source/api/cinder.tests.backup.fake_swift_client.rst\nGenerating doc/source/api/cinder.tests.db.fakes.rst\nGenerating doc/source/api/cinder.tests.declare_flags.rst\nGenerating doc/source/api/cinder.tests.fake_driver.rst\nGenerating doc/source/api/cinder.tests.fake_flags.rst\nGenerating doc/source/api/cinder.tests.fake_utils.rst\nGenerating doc/source/api/cinder.tests.glance.stubs.rst\nGenerating doc/source/api/cinder.tests.image.fake.rst\nGenerating doc/source/api/cinder.tests.image.test_glance.rst\nGenerating doc/source/api/cinder.tests.integrated.api.client.rst\nGenerating doc/source/api/cinder.tests.integrated.integrated_helpers.rst\nGenerating doc/source/api/cinder.tests.integrated.test_extensions.rst\nGenerating doc/source/api/cinder.tests.integrated.test_login.rst\nGenerating doc/source/api/cinder.tests.integrated.test_volumes.rst\nGenerating doc/source/api/cinder.tests.integrated.test_xml.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_a.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_b.rst\nGenerating doc/source/api/cinder.tests.runtime_flags.rst\nGenerating doc/source/api/cinder.tests.scheduler.fakes.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_capacity_weigher.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_filter_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_filters.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_manager.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_rpcapi.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler_options.rst\nGenerating doc/source/api/cinder.tests.test_HpSanISCSIDriver.rst\nGenerating doc/source/api/cinder.tests.test_api.rst\nGenerating doc/source/api/cinder.tests.test_backup.rst\nGenerating doc/source/api/cinder.tests.test_backup_swift.rst\nGenerating doc/source/api/cinder.tests.test_context.rst\nGenerating doc/source/api/cinder.tests.test_coraid.rst\nGenerating doc/source/api/cinder.tests.test_drivers_compatibility.rst\nGenerating doc/source/api/cinder.tests.test_emc.rst\nGenerating doc/source/api/cinder.tests.test_exception.rst\nGenerating doc/source/api/cinder.tests.test_flags.rst\nGenerating doc/source/api/cinder.tests.test_glusterfs.rst\nGenerating doc/source/api/cinder.tests.test_hp3par.rst\nGenerating doc/source/api/cinder.tests.test_huawei.rst\nGenerating doc/source/api/cinder.tests.test_iscsi.rst\nGenerating doc/source/api/cinder.tests.test_migrations.rst\nGenerating doc/source/api/cinder.tests.test_misc.rst\nGenerating doc/source/api/cinder.tests.test_netapp.rst\nGenerating doc/source/api/cinder.tests.test_netapp_nfs.rst\nGenerating doc/source/api/cinder.tests.test_nexenta.rst\nGenerating doc/source/api/cinder.tests.test_nfs.rst\nGenerating doc/source/api/cinder.tests.test_policy.rst\nGenerating doc/source/api/cinder.tests.test_quota.rst\nGenerating doc/source/api/cinder.tests.test_rbd.rst\nGenerating doc/source/api/cinder.tests.test_scality.rst\nGenerating doc/source/api/cinder.tests.test_service.rst\nGenerating doc/source/api/cinder.tests.test_sheepdog.rst\nGenerating doc/source/api/cinder.tests.test_skip_examples.rst\nGenerating doc/source/api/cinder.tests.test_solidfire.rst\nGenerating doc/source/api/cinder.tests.test_storwize_svc.rst\nGenerating doc/source/api/cinder.tests.test_test.rst\nGenerating doc/source/api/cinder.tests.test_test_utils.rst\nGenerating doc/source/api/cinder.tests.test_utils.rst\nGenerating doc/source/api/cinder.tests.test_volume.rst\nGenerating doc/source/api/cinder.tests.test_volume_configuration.rst\nGenerating doc/source/api/cinder.tests.test_volume_glance_metadata.rst\nGenerating doc/source/api/cinder.tests.test_volume_rpcapi.rst\nGenerating doc/source/api/cinder.tests.test_volume_types.rst\nGenerating doc/source/api/cinder.tests.test_volume_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.test_volume_utils.rst\nGenerating doc/source/api/cinder.tests.test_windows.rst\nGenerating doc/source/api/cinder.tests.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.test_xenapi_sm.rst\nGenerating doc/source/api/cinder.tests.test_xiv.rst\nGenerating doc/source/api/cinder.tests.test_zadara.rst\nGenerating doc/source/api/cinder.tests.utils.rst\nGenerating doc/source/api/cinder.tests.windows.basetestcase.rst\nGenerating doc/source/api/cinder.tests.windows.db_fakes.rst\nGenerating doc/source/api/cinder.tests.windows.mockproxy.rst\nGenerating doc/source/api/cinder.tests.windows.windowsutils.rst\nGenerating doc/source/api/cinder.utils.rst\nGenerating doc/source/api/cinder.version.rst\nGenerating doc/source/api/cinder.volume.api.rst\nGenerating doc/source/api/cinder.volume.configuration.rst\nGenerating doc/source/api/cinder.volume.driver.rst\nGenerating doc/source/api/cinder.volume.drivers.coraid.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_common.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.glusterfs.rst\nGenerating doc/source/api/cinder.volume.drivers.huawei.huawei_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.lvm.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.api.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.jsonrpc.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.volume.rst\nGenerating doc/source/api/cinder.volume.drivers.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.rbd.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_common.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_fc.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp_lefthand.rst\nGenerating doc/source/api/cinder.volume.drivers.san.san.rst\nGenerating doc/source/api/cinder.volume.drivers.san.solaris.rst\nGenerating doc/source/api/cinder.volume.drivers.scality.rst\nGenerating doc/source/api/cinder.volume.drivers.sheepdog.rst\nGenerating doc/source/api/cinder.volume.drivers.solidfire.rst\nGenerating doc/source/api/cinder.volume.drivers.storwize_svc.rst\nGenerating doc/source/api/cinder.volume.drivers.windows.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.lib.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.sm.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.tools.rst\nGenerating doc/source/api/cinder.volume.drivers.xiv.rst\nGenerating doc/source/api/cinder.volume.drivers.zadara.rst\nGenerating doc/source/api/cinder.volume.iscsi.rst\nGenerating doc/source/api/cinder.volume.manager.rst\nGenerating doc/source/api/cinder.volume.rpcapi.rst\nGenerating doc/source/api/cinder.volume.utils.rst\nGenerating doc/source/api/cinder.volume.volume_types.rst\nGenerating doc/source/api/cinder.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-cinder-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise35\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise35/10\n[SCP] Copying console log.\n\n\n','<727557311.75.1386828200322.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<12588e179f8a42afb6ce06c65fa61106@BN1PR07MB022.namprd07.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-29 17:34:54',0,'2014-09-29 17:34:54',NULL,'[openstack-dev] [nova][cinder] (OperationalError) (1040,\n \'Too many connections\') None None','Yes, looks like MySQL was just configured with too low a max-connections value.\n\n-amrith\n\n| -----Original Message-----\n| From: Jay Pipes [mailto:jaypipes at gmail.com]\n| Sent: Monday, September 29, 2014 12:58 PM\n| To: openstack-dev at lists.openstack.org\n| Subject: Re: [openstack-dev] [nova][cinder] (OperationalError) (1040, \'Too\n| many connections\') None None\n| \n| On 09/29/2014 12:48 PM, Nader Lahouti wrote:\n| > Hi Jay,\n| >\n| > I login first and the recreated the problem and here is the log:\n| > http://paste.openstack.org/show/116776/\n| \n| OK. Looks like there isn\'t anything wrong with your setup. I\'m guessing\n| you have set up Keystone to run in Apache with 10 worker processes, and\n| you have the workers config option setting in nova.conf, neutron.conf and\n| all the other project configuration files set to 0, which will trigger a\n| number of worker processes equal to the number of CPU cores on your box,\n| which I\'m guessing from looking at your SHOW FULL PROCESSLIST is around\n| 24-32 cores.\n| \n| Solution: either lower the workers configuration option from 0 to\n| something like 12, or increase the max_connections setting in your my.cnf\n| to something that can handle the worker processes from all the OpenStack\n| services (I\'d recommend something like 2000).\n| \n| Best,\n| -jay\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54298FA9.7050403@gmail.com>',NULL),('<1259111509.23450205.1370977839199.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 15:10:39',-14400,'2013-06-11 19:10:39',NULL,'[openstack-qa] Data encapsulation within Tempest','\n\n\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-qa at lists.openstack.org\n> Sent: Tuesday, June 11, 2013 8:15:58 PM\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> On 06/11/2013 01:02 PM, Attila Fazekas wrote:\n> >\n> >\n> >\n> >\n> > ----- Original Message -----\n> >> From: \"Sean Dague\" <sean at dague.net>\n> >> To: openstack-qa at lists.openstack.org\n> >> Sent: Tuesday, June 11, 2013 6:13:37 PM\n> >> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> >>\n> >> On 06/11/2013 11:52 AM, Attila Fazekas wrote:\n> >>>> From: \"Matthew Treinish\" <mtreinish at kortar.org>\n> >>>> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> >>>> Sent: Monday, June 10, 2013 4:15:15 PM\n> >>>> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> >>>>\n> >>>> On Mon, Jun 10, 2013 at 09:18:32AM -0400, Tal Kammer wrote:\n> >>>>> I fail to see how is it close to that model today.\n> >>>>>\n> >>>>> We have a lot of duplicate code in pretty much every implementation of\n> >>>>> XML\n> >>>>> vs JSON..\n> >>>>\n> >>>> So are you suggesting we have a uniform client and just have a\n> >>>> serializer/deserializer option for XML or JSON. That would actually end\n> >>>> up\n> >>>> not\n> >>>> saving that much code. The issue is that XML behavior is different\n> >>>> enough\n> >>>> from\n> >>>> JSON (at least in nova) that we basically have to handle everything\n> >>>> separately.\n> >>>> So there isn\'t actually that much to combine. It would just be the\n> >>>> actually\n> >>>> request call which is only a few lines per request. (To format the url\n> >>>> and\n> >>>> then\n> >>>> to make the rest_client call) I feel that keeping them separate makes\n> >>>> more\n> >>>> sense\n> >>>> because of all the differences it would get more complicated to handle\n> >>>> everything\n> >>>> in one class. We looked at this when we initially did the XML work, but\n> >>>> it\n> >>>> ended\n> >>>> up being more confusing because of how XML is used in the projects.\n> >>>>\n> >>>\n> >>> May be the xml_to_data/xml_to_json  not smart enough.\n> >>> I suspect a smarter way can exist.\n> >>>\n> >>> Not just the serialization could be more generic.\n> >>> https://github.com/openstack/tempest/commit/d42992849f95ac9a01fc73d2d6216585b6f7d174#L1R312\n> >>> The above just a small clean up.\n> >>>\n> >>> Much more can be done.\n> >>> May be all of the nova API calls can fit into 1-2 normal sized python\n> >>> file.\n> >>\n> >> No one is arguing there aren\'t clean ups here that could be done.\n> >> However Matt and I spent a lot of time in the Nova API on the Nova side.\n> >> The XML is not just a direct mapping from JSON. Which is why the XML API\n> >> was completely broken at Folsom-3 milestone, and why the XML code grew\n> >> the way it did in Tempest, because the thing that everyone imagines it\n> >> should be, it isn\'t.\n> >>\n> >> We can do better, and incremental improvements are good. But blanket\n> >> statements assuming that you can factor it all out, without having\n> >> looked at the details, don\'t really help us more forward. :)\n> >>\n> >> So cleanup patches encouraged. Refactoring for cleanliness encouraged.\n> >> I\'ll happily review any of that.\n> >\n> > May be we need xml->json function instead of a json->xml.\n> > May be we need a common model, which automatically transferable to xml and\n> > json or to anything else.\n> >\n> > I hope Tal can find the real solution.\n> \n> They are just really different models, at least in Nova. More power to\n> anyone that can come up with a simpler separation. Just be prepared for\n> some *really* weird edge cases.\n\nI am afraid of you are correct, we will see.\n\nIf less than 20% is edge situation, only they should be leaved as it is,\n or juts minimally improving it.\nSolving the 80% of issues is still a big gain.\n\nThe edge situations are probably happened by accident, \n they should be reported and improved in the next API version.\n \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B7695E.6040502@dague.net>',NULL);
INSERT INTO `messages` VALUES ('<1260730561.406.1367043010991.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:10:10',0,'2013-04-27 06:10:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric5 in workspace <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/>\nCheckout:periodic-keystone-python26-stable-grizzly / <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/> - hudson.remoting.Channel at 6ef1dd49:oneiric5\nUsing strategy: Default\nLast Built Revision: Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/keystone.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/keystone.git\nCommencing build of Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nChecking out Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\n[periodic-keystone-python26-stable-grizzly] $ /bin/bash -xe /tmp/hudson1600683463997899206.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack keystone\n+ version=26\n+ org=openstack\n+ project=keystone\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.ua9btopWgJ\n+ TMPDIR=/tmp/tmp.ua9btopWgJ\n+ trap \'rm -rf /tmp/tmp.ua9btopWgJ\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' keystone == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.keystone.python26.stable.grizzly.17\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-keystone-python26-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 48660 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-keystone-python26-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182612.323880-1683346245\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric5\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.ua9btopWgJ\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-06-59\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'7e23e4d1-e2e8-45e0-ae60-37017276cdc8\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'5929850979b0ccf348c1b913961d581ccac9732c\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric5\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 48660 166.78.48.43 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\nNo distributions at all found for pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.ua9btopWgJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1261125364.2930732.1357583181255.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 13:26:21',-18000,'2013-01-07 18:26:21',NULL,'[openstack-dev] [ceilometer] Counter frequency bp discussion','\n> > Also, should we constrain the possible periods to avoid lots of\n> > irregularity (e.g. just allow 1s, 10s, 60s & multiples thereof),\n> > or make it completely free form?\n> \n> \n> \n> We need to specify a minimum. I\'m not sure whether we need to be more\n> strict than that, though. Did you have an example of an issue that\n> might come up if we allow arbitrary values?\n\n\nNo, it was just an idea to ensure that the GCD generally works out at\na sane value. But if its considered too constraining, there\'s no strong\nreason to go down that route.\n\nCheers,\nEoghan\n\n\n','<CADb+p3QSy7E6nM29oK9Ha5rtAc5wTi74e6O1WN_seYMSb3AU8A@mail.gmail.com>',NULL),('<1262c87a1e204f8f99d9a35e6a0c59b7@MSR-MAIL-EXCH03.ubisoft.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-25 20:11:20',0,'2014-08-25 20:11:20',NULL,'[Openstack] Heat: 2014.1.2-0 vs Keystone','Hi guys,\n\nThis is what heat-engine gets back :\nRESP BODY: {\"token\": {\"methods\": [\"token\"], \"roles\": [{\"id\": \"59bd5c58fe344eeab3bc3443b82155a0\", \"name\": \"Member\"}, {\"id\": \"9fe2ff9ee4384b1894a90878d3e92bab\", \"name\": \"_member_\"}, {\"id\": \"c119300b61bb4bfeafdf9ccc8ea3efae\", \"name\": \"Admin\"}, {\"id\": \"e80ca12406714be799fc9066d5978dbb\", \"name\": \"Owner\"}], \"expires_at\": \"2014-08-26T20:07:11.000000Z\", \"project\": {\"domain\": {\"id\": \"default\", \"name\": \"Default\"}, \"id\": \"85bcc32e66b54c8bb52f28cb58319758\", \"name\": \"monitoring\"}, \"catalog\": {}, \"extras\": {}, \"user\": {\"domain\": {\"id\": \"default\", \"name\": \"Default\"}, \"id\": \"ccba454033204a7ba96b67ddaaacf00a\", \"name\": \"monitoring\"}, \"issued_at\": \"2014-08-25T20:07:12.589937Z\"}}\n_send_request /usr/lib/python2.6/site-packages/keystoneclient/session.py:297\n\nNotice the catalog\": {} ?  I\'m not sure but... shouldn\'t contain the actual catalog?\n\nDave\n\nFrom: David Hill\nSent: 25-Aug-14 4:41 AM\nTo: \'openstack\'\nSubject: Heat: 2014.1.2-0 vs Keystone\n\nHi guys,\n\n      I\'m trying to get Heat to work ... but everytime I try to create a stack, the engine will fail at getting the catalog.\nSince everything is working fine (ceilometer,nova,cinder,glance), am I forgetting something?\n\nStackValidationFailed_Remote: Property error : WikiDatabase: ImageId The service catalog is empty.\n\n\nHere is the catalog:\ncatalog.RegionOne.identity.publicURL = http://IP:$(public_port)s/v2.0\ncatalog.RegionOne.identity.adminURL = http://IP:$(admin_port)s/v2.0\ncatalog.RegionOne.identity.internalURL = http://IP:$(public_port)s/v2.0\ncatalog.RegionOne.identity.name = Identity Service\ncatalog.RegionOne.compute.publicURL = http://IP:8774/v2/$(tenant_id)s\ncatalog.RegionOne.compute.adminURL = http://IP:8774/v2/$(tenant_id)s\ncatalog.RegionOne.compute.internalURL = http://IP:8774/v2/$(tenant_id)s\ncatalog.RegionOne.compute.name = Compute Service\ncatalog.RegionOne.volume.publicURL = http://IP:8776/v1/$(tenant_id)s\ncatalog.RegionOne.volume.adminURL = http://IP:8776/v1/$(tenant_id)s\ncatalog.RegionOne.volume.internalURL = http://IP:8776/v1/$(tenant_id)s\ncatalog.RegionOne.volume.name = Volume Service\ncatalog.RegionOne.ec2.publicURL = http://IP:8773/services/Cloud\ncatalog.RegionOne.ec2.adminURL = http://IP:8773/services/Admin\ncatalog.RegionOne.ec2.internalURL = http://IP:8773/services/Cloud\ncatalog.RegionOne.ec2.name = EC2 Service\ncatalog.RegionOne.image.publicURL = http://IP:9292/\ncatalog.RegionOne.image.adminURL = http://IP:9292/\ncatalog.RegionOne.image.internalURL = http://IP:9292/\ncatalog.RegionOne.image.name = Image Service\ncatalog.RegionOne.object_store.publicURL = http://IP:8080/v1/AUTH_$(tenant_id)s\ncatalog.RegionOne.object_store.adminURL = http://IP:8080/\ncatalog.RegionOne.object_store.internalURL = http://IP:8080/v1/AUTH_$(tenant_id)s\ncatalog.RegionOne.object_store.name = Swift Service\ncatalog.RegionOne.cloudformation.publicURL = http://IP:8000/v1\ncatalog.RegionOne.cloudformation.adminURL = http://IP:8000/v1\ncatalog.RegionOne.cloudformation.internalURL = http://IP:8000/v1\ncatalog.RegionOne.cloudformation.name = Heat CloudFormation API\ncatalog.RegionOne.heat.publicURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.heat.adminURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.heat.internalURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.heat.name = Heat API\ncatalog.RegionOne.orchestration.publicURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.orchestration.adminURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.orchestration.internalURL = http://IP:8004/v1/$(tenant_id)s\ncatalog.RegionOne.orchestration.name = Heat API\ncatalog.RegionOne.ceilometer.publicURL = http://IP:8777/\ncatalog.RegionOne.ceilometer.adminURL = http://IP:8777/\ncatalog.RegionOne.ceilometer.internalURL = http://IP:8777/\ncatalog.RegionOne.ceilometer.name = Ceilometer Metering\ncatalog.RegionOne.metering.publicURL = http://IP:8777/\ncatalog.RegionOne.metering.adminURL = http://IP:8777/\ncatalog.RegionOne.metering.internalURL = http://IP:8777/\ncatalog.RegionOne.metering.name = Ceilometer Metering\n\n\n\n/etc/heat/heat.conf\n\n\n[DEFAULT]\nverbose = True\ndebug = True\nuse_stderr = False\nlog_file = /var/log/heat/engine.log\nuse_syslog = False\nheat_stack_user_role = heat_stack_user\ninstance_connection_is_secure = 0\ninstance_connection_https_validate_certificates = 1\nbind_host = 0.0.0.0\nbind_port = 8001\nheat_metadata_server_url = http://IP:8000\nheat_waitcondition_server_url = http://IP:8000/v1/waitcondition\nheat_watch_server_url = http://IP:8003\nsql_connection = mysql://USER:PASSWORD at IP/heat\ndb_backend=heat.db.sqlalchemy.api\nrpc_backend=heat.openstack.common.rpc.impl_kombu\nauth_encryption_key=AUTH_KEY\nrabbit_host=localhost\nrabbit_port=5672\n\n[keystone_authtoken]\nadmin_tenant_name = TENANT\nadmin_user = USER\nadmin_password = PASSWORD\nauth_host = IP\nauth_port = 35357\nauth_protocol = http\nauth_uri = http://IP:5000/v2.0\nadmin_token = TOKEN\n\n[ec2authtoken]\nauth_uri http://IP:5000/v2.0\n\n[paste_deploy]\napi_paste_config=api-paste.ini\nflavor = keystone\n\n\n\napi-paste.ini\n\n[pipeline:heat-api]\npipeline = versionnegotiation authurl authtoken context apiv1app\n[pipeline:heat-api-keystone]\npipeline = versionnegotiation authurl authtoken context apiv1app\n[pipeline:heat-api-cfn]\npipeline = cfnversionnegotiation ec2authtoken authtoken context apicfnv1app\n[pipeline:heat-api-cfn-standalone]\npipeline = cfnversionnegotiation ec2authtoken context apicfnv1app\n[app:apicwapp]\npaste.app_factory = heat.common.wsgi:app_factory\nheat.app_factory = heat.api.cloudwatch:API\n[app:apicfnv1app]\npaste.app_factory = heat.common.wsgi:app_factory\nheat.app_factory = heat.api.cfn.v1:API\n[filter:cfnversionnegotiation]\npaste.filter_factory = heat.common.wsgi:filter_factory\nheat.filter_factory = heat.api.cfn:version_negotiation_filter\n[filter:ec2authtoken]\npaste.filter_factory = heat.api.aws.ec2token:EC2Token_filter_factory\n[pipeline:heat-api-cloudwatch]\npipeline = versionnegotiation ec2authtoken authtoken context apicwapp\n[pipeline:heat-api-cloudwatch-standalone]\npipeline = versionnegotiation ec2authtoken context apicwapp\n[pipeline:heat-api-cfn-keystone]\npipeline = versionnegotiation authurl authtoken context apiv1app\n[pipeline:heat-api-cloudwatch-keystone]\npipeline = versionnegotiation authurl authtoken context apiv1app\n[pipeline:heat-api-custombackend]\npipeline = versionnegotiation context custombackendauth apiv1app\n[pipeline:heat-api-caching]\npipeline = versionnegotiation authurl authtoken context cache apiv1app\n[pipeline:heat-api-keystone+caching]\npipeline = versionnegotiation authurl authtoken context cache apiv1app\n[pipeline:heat-api-cachemanagement]\npipeline = versionnegotiation authurl authtoken context cache cachemanage apiv1app\n[pipeline:heat-api-keystone+cachemanagement]\npipeline = versionnegotiation auth-context cache cachemanage apiv1app\n[app:apiv1app]\npaste.app_factory = heat.common.wsgi:app_factory\nheat.app_factory = heat.api.openstack.v1:API\n[filter:versionnegotiation]\npaste.filter_factory = heat.common.wsgi:filter_factory\nheat.filter_factory = heat.api.openstack:version_negotiation_filter\n[filter:cache]\npaste.filter_factory = heat.common.wsgi:filter_factory\nheat.filter_factory = heat.api.middleware.cache:CacheFilter\n[filter:cachemanage]\npaste.filter_factory = heat.common.wsgi:filter_factory\nheat.filter_factory = heat.api.middleware.cache_manage:CacheManageFilter\n[filter:context]\npaste.filter_factory = heat.common.context:ContextMiddleware_filter_factory\n[filter:authurl]\npaste.filter_factory = heat.common.auth_url:filter_factory\n[filter:authtoken]\npaste.filter_factory = keystoneclient.middleware.auth_token:filter_factory\n[filter:auth-context]\npaste.filter_factory = heat.common.wsgi:filter_factory\nheat.filter_factory = keystone.middleware.heat_auth_token:KeystoneContextMiddleware\n[filter:custombackendauth]\npaste.filter_factory = heat.common.custom_backend_auth:filter_factory\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140825/beae74c0/attachment.html>\n\n',NULL,NULL),('<1263373466.71.1383460611531.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:36:51',0,'2013-11-03 06:36:51',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-tempest-devstack-vm-postgres-stable-grizzly #43','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/43/>\n\n\n\n','<2101803914.56.1383373833994.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1263676792.41.1367648351802.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-04 06:19:11',0,'2013-05-04 06:19:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-grizzly-centos6 #4','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/4/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-5 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/>\nCheckout:periodic-nova-python26-stable-grizzly-centos6 / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/> - hudson.remoting.Channel at 53b5e629:centos6-5\nUsing strategy: Default\nLast Built Revision: Revision 43004ba04e77cb4776b42b4697f28364ef2db839 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 43004ba04e77cb4776b42b4697f28364ef2db839 (origin/stable/grizzly)\nChecking out Revision 43004ba04e77cb4776b42b4697f28364ef2db839 (origin/stable/grizzly)\n[periodic-nova-python26-stable-grizzly-centos6] $ /bin/bash -xe /tmp/hudson320113372828771379.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.2KwkSrMXoG\n+ TMPDIR=/tmp/tmp.2KwkSrMXoG\n+ trap \'rm -rf /tmp/tmp.2KwkSrMXoG\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\ngrep: /var/log/auth.log: No such file or directory\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.centos6.4\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.centos6.4.zip>\npy26 runtests: commands[0]\npy26 runtests: commands[1]\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.2KwkSrMXoG/tmpEwVMpv\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.2KwkSrMXoG/tmpjnznJG\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.2KwkSrMXoG/tmpyVmRwW\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.2KwkSrMXoG/tmpr9CUPZ\n======================================================================\nFAIL: nova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/nova/tests/test_db_api.py\",> line 2640, in test_archive_deleted_rows_fk_constraint\n    self.assertEqual(num, 1)\nMismatchError: 0 != 1\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 5545 tests in 429.700s\nFAILED (id=0, failures=2, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncliff==1.3.3\ncmd2==0.6.5.1\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.centos6.4\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npyOpenSSL==0.13\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.2\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-quantumclient==2.2.1\npython-subunit==0.0.11\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\ntestrepository==0.0.15\ntesttools==0.9.31\nunittest2==0.5.1\nwarlock==1.0.0\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint (subunit.RemotedTestCase)\nprocess-returncode (subunit.RemotedTestCase)\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n++ .tox/py26/bin/python .tox/py26/bin/testr list-tests\n++ sed -e 1d\n++ wc -l\n/usr/bin/python: No module named subunit\n+ foundcount=0\n++ .tox/py26/bin/python .tox/py26/bin/testr last\n++ sed -ne \'s/Ran \\([0-9]\\+\\).*tests in.*/\\1/p\'\n+ rancount=5545\n+ \'[\' 5545 -lt 0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.2KwkSrMXoG\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly-centos6/4\n[SCP] Copying console log.\n\n\n','<1677318636.17.1367562157975.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1264022130.276.1354839286747.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-07 00:14:46',0,'2012-12-07 00:14:46',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #67','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/67/>\n\n------------------------------------------\n[...truncated 11050 lines...]\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nFailure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\n\n======================================================================\nERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n    CONFIG = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n    super(UsersTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n    super(BaseIdentityAdminTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n    super(UsersTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n    super(BaseIdentityAdminTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n    super(VolumesActionsTest, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n    super(VolumesGetTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n    super(VolumesGetTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n    super(VolumeListTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n    super(VolumeListTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 1 test in 0.014s\n\nFAILED (errors=8)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/rabbitmq/rabbit at devstack-1354834255-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/rabbitmq/rabbit at devstack-1354834255.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-n-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/screen-swift.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/67/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1264806243.6227099.1383052200629.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 13:10:00',0,'2013-10-29 13:10:00',NULL,'[openstack-dev] [nova][scheduler] Instance Group Model and APIs\n - Updated document with an example request payload','Hi Yathi,\n\nThank you for yor example. I have some remarks concerning the JSON format:\n\n1) Member of a group is recursive. A member can be group or an instance. In this case there are two different declaration formats for members, as with http-server-group-1 (\"name, \"policy\", \"edge\") and Http-Server-1 (\"name\", \"request_spec\", \"type\"). Would it be better if group-typed member also have \"type\" field to better interpret the member? Like policy which has \"type\" field to declare that\'s a egde-typed policy or group-typed policy.\n\n2) The \"edge\" is not clear to me. It seems to me that \"edge\" is just a place holder for the edge policy. Does it have some particular configuration like group members (e.g. group-typed member is described by its \"member\",\"edge\" and \"policy\", while instance-typed member is described by its \"request_spec\") ?\n\n3) Members & groups have policy declaration nested in them. Why is edge-policy is declared outside of edge\'s declaration?\n\nAnyway, good work.\n\nToan\n\n----- Original Message -----\nFrom: \"John Garbutt\" <john at johngarbutt.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, October 29, 2013 12:29:19 PM\nSubject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload\n\nOn 29 October 2013 06:46, Yathiraj Udupi (yudupi) <yudupi at cisco.com> wrote:\n> The Instance Group API document is now updated with a simple example request\n> payload of a nested group, and some description of how the API\n> implementation should handle the registration of the components of a nested\n> instance group.\n> https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit\n>\n> Hope we will have a good API design session at the summit, and also continue\n> the discussion face-to-face over there.\n\nIts looking good, but I was thinking about a slightly different approach:\n\n* I would like to see instance groups be used to describe all\nscheduler hints (including, please run on cell X, or please run on\nhypervisor Y)\n\n* passing old scheduler hints to the API will just create a new\ninstance group to persist the request\n\n* ensure live-migrate/migrate never lets you violate the rules in the\nuser hints, at least don\'t allow it to happen by accident\n\n* I was expecting to see hard and soft constraints/hints, like: try\nkeep in same switch, but make sure on separate servers\n\n* Would be nice to have admin defined global options, like: \"ensure\ntenant does note have two servers on the same hypervisor\" or soft\n\n* I expected to see the existing boot server command simply have the\naddition of a reference to a group, keeping the existing methods of\nspecifying multiple instances\n\n* I aggree you can\'t change a group\'s spec once you have started some\nVMs in that group, but you could then simply launch more VMs keeping\nto the same policy\n\n* New task API (see summit session) should help with the reporting if\nthe VM actually could be started or not, and the reason why it was not\npossible\n\n* augment the server details (and group?) with more location\ninformation saying where the scheduler actually put things, obfuscated\non per tenant basis. So imagine nova, cinder, neutron exposing ordered\n(arbitrary tagged) location metadata like nova: ((\"host_id\", \"foo\"),\n(\"switch_group_id\": \"bar\"), (\"power_group\": \"bas\"))\n\n* the above should help us define the \"scope\" of a constraint relative\nto either a nova, cinder or neutron resource.\n\n* Consider a constraint that includes constraints about groups, like\nmust be separate to group X, in the scope of the switch, or something\nlike that\n\n* Need more thought on constraints between volumes, servers and\nnetworks, I don\'t think edges are the right way to state that, I think\nit would be better as a cross group constraint, where the scope of the\nconstraint is related to neutron.\n\n\nAnyways, just a few thoughts I was having. Does that fit in with what\nyou were thinking?\n\nJohn\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CABib2_qnkvwcivDeouafPA4Ytrw1_-WWD1KqbYwJ2DobiZ+yGA@mail.gmail.com>',NULL),('<1265463994.0.1377167333596.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-22 10:28:53',0,'2013-08-22 10:28:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/8/>\n\n------------------------------------------\n[...truncated 3739 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 33.57 secs:\n    8.25    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.92    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.36    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    6.17    TestTokenRevoking.test_removing_role_assignment_does_not_affect_other_users\n    5.87    TestTokenAPIs.test_revoke_token\n----------------------------------------------------------------------\nRan 1300 tests in 439.602s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==2.0\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.8\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.HLoF3K1YvK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/8/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise11/8\n[SCP] Copying console log.\n\n\n','<1846129930.11.1376979145603.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1266078059.1968521405102788575.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-07-11 18:19:48',0,'2014-07-11 18:19:48',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting\n	November 2, 2014, 9am CET','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting November 2, 2014, 9am CET\nHost: Alan Clark\nDate: Sunday, November 2, 2014\nTime: 1:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\nSession number: 922 157 992\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t94f1a23dfe6fdff44d3cf2581d7d4162\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tcf69a80c5b0fe62d49f40ec84f485564\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t4bc28c270e3d0ec2f38e26bdf0b21a76\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=295727467&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 157 992\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140711/bf4c8c5c/attachment.html>\n\n',NULL,NULL),('<1266645778.21237025.1391410376755.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-03 01:52:56',-18000,'2014-02-03 06:52:56',NULL,'[Openstack-docs] Proposal: CLI Reference manual','\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Summer Long\" <slong at redhat.com>\n> Cc: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>, \"Anne Gentle\" <anne at openstack.org>,\n> openstack-docs at lists.openstack.org, \"Steve Gordon\" <sgordon at redhat.com>\n> Sent: Monday, February 3, 2014 4:34:44 PM\n> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n> \n> On 02/03/2014 03:59 AM, Summer Long wrote:\n> > \n> > \n> > ----- Original Message -----\n> >> From: \"Andreas Jaeger\" <aj at suse.com>\n> >> To: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>, \"Anne Gentle\"\n> >> <anne at openstack.org>\n> >> Cc: openstack-docs at lists.openstack.org\n> >> Sent: Friday, January 31, 2014 1:44:04 AM\n> >> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n> >>\n> >> On 01/30/2014 04:26 PM, Diane Fleming wrote:\n> >>> Actually, I\'m fine either way ? keeping it as appendix or as separate\n> >>> book.\n> >>>\n> >>> But either way, I think we need to improve the formatting ? I\'ll open a\n> >>> bug for that.\n> > \n> > And can the \'install the clients\' section be removed? Clients should\n> > already be installed via the Installation Guide?\n> \n> Clients will be installed on machines outside of the cloud as well, so I\n> think this really belongs to the CLI reference.\nYep, ok, fair enough.\n> \n> >>\n> >> Yes, please do open a bug. I\'ll see what I can do to improve it.\n> >>\n> >>> What does everyone else think about keeping command ref as appendix, or\n> >>> moving to separate book?\n> >>\n> >> I\'m fine either way.  Having one more guide, will not really cost us\n> >> more work than having it in the appendices. And having a guide would\n> >> give us *one* location for the content instead of currently two guides\n> >> with both the same large appendix.\n> > Definitely vote for having it\n> > \n> >>\n> >> And I\'m even fine with removing the appendix and not having a book since\n> >> these are help texts users could get themselves on the command line...\n> >> Still, it\'s nice to have a common location to look it up and be aware of\n> >> these. And since there are no man pages for these, this it probably the\n> >> best way to have it,\n> > \n> > +1 on removing the CLI info from both EUG and AUG and providing links\n> > (really dislike bloat-by-duplication).\n> > \n> > But was there a reason for not just putting the CLI info into the\n> > Configuration Reference Guide?\n> > We\'re removing the HowTos from that guide, which means the whole thing\n> > really is a reference now?\n> \n> IMO they target different personas - the admin of the cloud for the\n> Configuration Reference only and the CLI reference both admin and users,\nBut if you do this, you\'re creating an admin-and-users book. Why not just make the Configuration Reference have that audience as well and keep all the automatically generated reference lists in one book? \'Configuration and CLI Reference\'\n\ncheers, Summer\n\n> \n> Andreas\n> --\n>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>    GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n> \n\n\n','<52EF3884.5050201@suse.com>',NULL),('<1267494122.6.1380350194247.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-28 06:36:34',0,'2013-09-28 06:36:34',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #22','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/22/>\n\n\n\n','<650586083.82.1380089085886.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1268503125.38633404.1361979106458.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 10:31:46',-18000,'2013-02-27 15:31:46',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','\n\nPreviously when there was some confusion over what types of\nchanges to existing APIs were acceptable without a major version\nbump, we ended up with a TC-endorsed set of guidelines to aid\nreviewers:\n\n  https://wiki.openstack.org/wiki/APIChangeGuidelines\n\nPerhaps something similar would be useful for DB migrations?\n\nHere\'s a strawman to kick it off:\n\n  https://wiki.openstack.org/wiki/DbMigrationChangeGuidelines\n\nPlease feel free to hack away on it until we get to a community\nunderstanding.\n\nThanks,\nEoghan\n\n\n----- Original Message -----\n> \n> \n> ----- Original Message -----\n> > From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n> > To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development\n> > Mailing List\" <openstack-dev at lists.openstack.org>\n> > Sent: Wednesday, February 27, 2013 9:09:00 AM\n> > Subject: Re: [openstack-dev] [keystone] re-ordering of schema\n> > migrations\n> > \n> > This was discussed in #openstack-dev, as I recall.\n> > \n> > The goal in these migrations was to support folsom <--> grizzly,\n> > not\n> > necessarily supporting intermediate milestones. I\'m not aware of\n> > anyone\n> > doing continuous deployments of keystone, if but if migrating\n> > commit\n> > to\n> > commit is the community\'s expectation, I\'m more happy to ensure\n> > that\n> > happens moving forward -- I just wasn\'t aware that was a concern\n> > here.\n> \n> We should always support upgrading between the milestones.\n> \n> Also, Existing migrations should never be re-ordered.\n> \n> One thing you could do is compact the \"released\" (as in part of the\n> previous stable release) migrations into a single (large) migration\n> in a way which doesn\'t break upgrades for previous users.\n> \n> So at Folsom keystone had 15 migrations... In order to upgrade to\n> Grizzly users would need to be at migration 15 (or greater). New\n> installations would automatically run the \'compacted\' migration\n> which initializes their schema to version 15 as well so they will be\n> upgraded in a similar fashion. New migrations added in the grizzly\n> timeframe should remain in order and untouched.\n> \n> Make sense?\n> \n> Dan\n> \n> > \n> > Thanks for the feedback, and apologies for any inconvenience!\n> > \n> > \n> > -Dolph\n> > \n> > \n> > On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin\n> > <markmc at redhat.com>\n> > wrote:\n> > \n> > > On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:\n> > > > Folks,\n> > > >\n> > > > When looking into an error encountered on a keystone db sync,\n> > > > I noticed some apparent strangeness in the way keystone schema\n> > > > migrations have been managed.\n> > > >\n> > > > Specifically the *rewriting* of schema migration history, see:\n> > > >\n> > > >   https://github.com/openstack/keystone/commit/5bc46d86\n> > > >\n> > > > In my (albeit imperfect) understanding of sqlalchemy-migrate,\n> > > > this\n> > > > reordering seems to defeat the whole purpose of step-wise\n> > > > reversible\n> > > > migration.\n> > > >\n> > > > Would it even be possible to migrate a grizzly-2 deployment to\n> > > > grizzly-3 with that re-ordering in place?\n> > > >\n> > > > Maybe I\'ve missed something here, but I\'d appreciate some\n> > > > clarity\n> > > > on what is considered community best practice in terms of\n> > > > changes\n> > > > to the migration sequence.\n> > > >\n> > > > Previously I would have assumed something like ...\n> > > >\n> > > > Invariants we maintain:\n> > > >\n> > > >  - DB schemas must always be migrate-able across milestone\n> > > >  releases\n> > >\n> > > (snip good stuff)\n> > >\n> > > It\'s more than just across milestone releases, we should support\n> > > upgrading from commit to commit. In Nova, at least, we\'re trying\n> > > hard to\n> > > avoid messing up those who are deploying continuously. I\'d expect\n> > > any\n> > > nova-core member to reject this patch immediately.\n> > >\n> > > What I really don\'t understand is how this concern wasn\'t raised\n> > > in\n> > > the\n> > > review at all:\n> > >\n> > >   https://review.openstack.org/19780\n> > >\n> > > Cheers,\n> > > Mark.\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1058247869.4881114.1361977152946.JavaMail.root@redhat.com>',NULL),('<1268733758.207.1368165984831.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-10 06:06:24',0,'2013-05-10 06:06:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-grizzly-centos6 #10','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly-centos6/10/>\n\n\n\n','<652290664.164.1368079520278.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1269113626.32768524.1410844328319.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-16 01:12:08',-14400,'2014-09-16 05:12:08',NULL,'[openstack-dev] [neutron] Ipset, merge refactor for J?','\nDuring the ipset implementatio, we designed a refactor [1] to cleanup \nthe firewall driver a bit, and move all the ipset low-level knowledge \ndown into the  IpsetManager.\n\nI\'d like to see this merged for J, and, it\'s a bit of an urgent matter \nto decide, because we keep adding small changes [2] [3] fruit of the\nearly testing which break the refactor, and will add extra work which\nneeds to be refactored too.\n\nThe advantage of merging now, vs in J, is having K & J share a more common \ncode base, which would help us during bug backports/etc in the future.\n\nShihanzhang and I, are happy to see this merge during K, as it doesn\'t \nincur in functional changes, just code blocks are moved from the iptables\nfirewall driver to IpsetManager, and the corresponding tests are moved too.\n\nThis is where I\'d like to see the driver going, in conjunction with a separate\ndriver for Iptables+Ipset, but that second part is change which \ncan\'t be done now (CI changes, documentation, etc.)\n\n\n[1] https://review.openstack.org/#/c/120806/ \n[2] https://review.openstack.org/#/c/121455/\n[3] to be done: not re-loading iptables when only ipset group members change.\n[4] to be done: better locking strategy (brian haley is looking at that)\n\n\nBest regards,\nMiguel ?ngel Ajo.\n\n\n','<1342400502.32765473.1410843423093.JavaMail.zimbra@redhat.com>',NULL),('<1269174295.808151.1418981677067.JavaMail.yahoo@jws10934.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-19 09:34:37',0,'2014-12-19 09:34:37',NULL,'[Openstack] Fedora/cirros instance failed to set root password','Hi Akash, \n\nI am able to ssh using keypair. \nOnlything I need to do set the root password. \n\n?\nRegards\nNeelu \n\n     On Friday, 19 December 2014 2:44 PM, Girija Sharan <girijasharansingh at gmail.com> wrote:\n   \n\n Hi Som,\n\nNot sure on what you are looking for. But here is a link which describe\nhow to set root password during instance boot up.\n\nhttp://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/\n\n\nOn Fri, Dec 19, 2014 at 2:19 PM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\nHi All, \n\nI am trying to set root password on Fedora-x86_64-20-20140618-sda/cirros instance it fails .DO I need to add anyother security rules, please what I am missing.?I need to install apache webserver on this instance. \n\nThanks in advance\n\n? nova root-password gggg\nNew password: \nAgain: \nERROR (HTTPNotImplemented): Unable to set password on instance (HTTP 501) (Request-ID: req-6d0eebe3-68c5-4d8d-80b7-8d4639b7c2d4)\n\nI have set all rules for security groupsPC-1:~/devstack$ nova secgroup-list-rules default\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range? | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| icmp??????? | -1??????? | -1????? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 1???????? | 65535?? | 0.0.0.0/0 |????????????? |\n| udp???????? | 1???????? | 65535?? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 22??????? | 22????? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 80??????? | 80????? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 443?????? | 443???? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 3306????? | 3306??? | 0.0.0.0/0 |????????????? |\n| tcp???????? | 53??????? | 53????? | 0.0.0.0/0 |????????????? |\n+-------------+-----------+---------+-----------+--------------+\n?\nRegards\nNeelu \n\n\n    \n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141219/66853f92/attachment.html>\n\n','<CADpE9x+UTBrUDRWTjVjEDdrO94FW0Tc3fxrOVaoRn5ktdTtRkw@mail.gmail.com>',NULL),('<1269305104.93.1380177586374.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-26 06:39:45',0,'2013-09-26 06:39:45',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #27','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/27/>\n\n------------------------------------------\n[...truncated 20733 lines...]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.api.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time[gate]\ntempest.api.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time[gate] ... skipped u\'Skipped until the Bug #1069849 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\nInitialized empty Git repository in /tmp/tempest-unitrF1wH0/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unit1oEZWW/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          228.272\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  198.866\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  78.127\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     35.597\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]    33.095\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         31.990\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       31.438\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        30.627\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     29.806\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       29.623\n\n----------------------------------------------------------------------\nRan 1232 tests in 1114.370s\n\nOK (skipped=66)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-392698-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-392698.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-392698/27/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1495525037.88.1380090585884.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1269550458.2.1371536606614.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-18 06:23:26',0,'2013-06-18 06:23:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #260','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/260/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:44952\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:44952/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (3028) wsgi starting up on http://127.0.0.1:44952/\n\nnova.osapi_compute.wsgi.server: INFO: (3028) accepted (\'127.0.0.1\', 50786)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [18/Jun/2013 06:18:02] \"GET /v2 HTTP/1.1\" 204 216 0.001134\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-9fe4d7e8-7bc4-44e9-aed1-1ec67b199e78</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (3028) accepted (\'127.0.0.1\', 50787)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9de6b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9de6b10>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:44952/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-18 06:18:02 3028 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:44952/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [18/Jun/2013 06:18:02] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.254985\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 07ecf42a48644df3ad48ba5c82d8e3ce \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:54749\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:54749/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (3028) wsgi starting up on http://127.0.0.1:54749/\n\nnova.osapi_compute.wsgi.server: INFO: (3028) accepted (\'127.0.0.1\', 54528)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [18/Jun/2013 06:18:03] \"GET /v2 HTTP/1.1\" 204 216 0.000808\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-0f7e59e3-0aea-4d58-99b8-39e8da7d9dc1</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (3028) accepted (\'127.0.0.1\', 54529)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xab619d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xab619d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:54749/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     name)\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-18 06:18:03 3028 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:54749/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [18/Jun/2013 06:18:03] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.326290\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.m2igdolbtO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/260\n[SCP] Copying console log.\n\n\n','<313698878.1.1371450246294.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<126E03B8-6710-4C71-8782-7C7D742A86A3@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-14 09:38:46',-18000,'2014-11-14 14:38:46',NULL,'[openstack-dev] [oslo][kite] oslo.messaging changes for message\n	security','\nOn Nov 13, 2014, at 8:47 PM, Jamie Lennox <jamielennox at redhat.com> wrote:\n\n> Hi all,\n> \n> To implement kite we need the ability to sign and encrypt the message and the\n> message data. This needs to happen at a very low level in the oslo.messaging\n> stack. The existing message security review\n> (https://review.openstack.org/#/c/109806/) isn\'t going to be sufficient. It\n> allows us to sign/encrypt only the message data ignoring the information in the\n> context and not allowing us to sign the message as a whole. It would also\n> intercept and sign notifications which is not something that kite can do.\n> \n> Mostly this is an issue of how the oslo.messaging library is constructed. The\n> choice of how data is serialized for transmission (including things like how\n> you arrange context and message data in the payload) is handled individually by\n> the driver layer rather than in a common higher location. All the drivers use\n> the same helper functions for this and so it isn\'t a problem in practice.\n> \n> Essentially I need a stateful serializing/deserializing object (I need to store\n> keys and hold things like a connection to the kite server) that either extends\n> or replaces oslo.messaging._drivers.common.serialize_msg and deserialize_msg\n> and their exception counterparts.\n> \n> There are a couple of ways I can see to do what I need:\n> \n> 1. Kite becomes a more integral part of oslo.messaging and the marshalling and\n> verification code becomes part of the existing RPC path. This is how it was\n> initially proposed, it does not provide a good story for future or alternative\n> implementations. Oslo.messaging would either have a dependency on kiteclient,\n> implement its own ways of talking to the server, or have some hack that imports\n> kiteclient if available.\n> \n> 2. Essentially I add a global object loaded from conf to the existing common\n> RPC file. Pro: The existing drivers continue to work as today, Con: global\n> state held by a library. However given the way oslo messaging works i\'m not\n> really sure how much of a problem this is. We typically load transport from a\n> predefined location in the conf file and we\'re not really in a situation where\n> you might want to construct different transports with different parameters in\n> the same project.\n> \n> 3. I create a protocol object out of the RPC code that kite can subclass and\n> the protocol can be chosen by CONF when the transport/driver is created. This\n> still touches a lot of places as the protocol object would need to be passed to\n> all messages, consumers etc. It involves changing the interface of the drivers\n> to accept this new object and changes in each of the drivers to work with the\n> new protocol object rather than the existing helpers.\n> \n> 4. As the last option requires changing the driver interface anyway we try and\n> correct the driver interfaces completely. The driver send and receive functions\n> that currently accept a context and args parameters should only accept a\n> generic object/string consisting of already marshalled data. The code that\n> handles serializing and deserializing gets moved to a higher level and kite\n> would be pluggable there with the current RPC being default.\n> \n> None of these options involve changing the public facing interfaces nor the\n> messages emitted on the wire (when kite is not used).\n> \n> I\'ve been playing a little with option 3 and I don\'t think it\'s worth it. There\n> is a lot of code change and additional object passing that I don\'t think\n> improves the library in general.\n> \n> Before I go too far down the path with option 4 I\'d like to hear the thoughts\n> of people more familiar with the library.\n> \n> Is there a reason that the drivers currently handle marshalling rather than the\n> RPC layer?\n\nIt may have been an artifact of the evolution of that code, but I seem to remember at some point that one of the drivers had a limitation either in the byte-values allowed or the number of bytes allowed in a message. They all seem to be doing roughly the same thing to construct the messages now, though, so I?m not sure if that?s really true.\n\n> \n> I know there is ongoing talk about evolving the oslo.messaging library, I\n> unfortunately didn\'t make it to the sessions at summit. Has this problem been\n> raised? How would it affect those talks?\n\nSecurity did come up, but I don?t see where we recorded any decisions in the etherpad: https://etherpad.openstack.org/p/kilo-oslo-oslo.messaging\n\nOur bigger concern was lack of reviewers for the library, which will make any large-scale refactoring problematic.\n\n> \n> Is there explicit/implicit support for out of tree drivers that would disallow\n> changing these interfaces?\n\nThere?s implicit support, but we haven?t formally called those APIs stable.\n\n> \n> Does anyone have alternative ideas on how to organize the library for message\n> security?\n> \n> Thanks for the help.\n> \n> \n> Jamie\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1145124110.5339443.1415929676006.JavaMail.zimbra@redhat.com>',NULL),('<1270062894.214.1368168411496.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-10 06:46:51',0,'2013-05-10 06:46:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #30','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/30/changes>\n\nChanges:\n\n[Alan Pevec] Bump stable/grizzly next version to 2013.1.2\n\n------------------------------------------\n[...truncated 5217 lines...]\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    2.57\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.20\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    0.23\n    test_update_quotas_with_admin                                OK    2.62\n    test_update_quotas_with_non_integer_returns_400              OK    0.20\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.44\n    test_KillFilter_deleted_exe                                  OK    0.00\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.44\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    0.31\n    test_health_monitor_update_with_router_id                    OK    0.29\n    test_health_monitor_update_without_router_id                 OK    0.27\n    test_pool_create                                             OK    0.26\n    test_pool_delete_with_router_id                              OK    3.51\n    test_pool_delete_without_router_id                           OK    0.25\n    test_pool_update_with_router_id                              OK    0.23\n    test_pool_update_without_router_id                           OK    0.25\n    test_router_create_no_service_type_id                        OK    0.21\n    test_router_create_with_service_type_id                      OK    0.21\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.23\n    test_vip_create                                              OK    0.27\n    test_vip_delete_with_router_id                               OK    0.31\n    test_vip_delete_without_router_id                            OK    2.67\n    test_vip_update_with_router_id                               OK    0.27\n    test_vip_update_without_router_id                            OK    0.30\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.45\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.49\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.41\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.41\n    test_security_group_rules_for_devices_ipv6_source_group      OK    2.91\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.45\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.44\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.54\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.43\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.51\nSecurityGroupAgentRpcApiTestCase\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSecurityGroupAgentRpcTestCase\n    test_prepare_and_remove_devices_filter                       OK    0.00\n    test_refresh_firewall                                        OK    0.01\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.01\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.01\nSecurityGroupServerRpcApiTestCase\n    test_security_group_rules_for_devices                        OK    0.00\nTestSecurityGroupAgentWithIptables\n    test_prepare_remove_port                                     OK    0.04\n    test_security_group_member_updated                           OK    0.09\n    test_security_group_rule_udpated                             OK    0.03\nTestSecurityGroupAgentWithOVSIptables\n    test_prepare_remove_port                                     OK    0.03\n    test_security_group_member_updated                           OK    0.10\n    test_security_group_rule_udpated                             OK    2.39\nTestSecurityGroupExtensionControl\n    test_disable_security_group_extension_iptables_driver        OK    0.00\n    test_disable_security_group_extension_noop_driver            OK    0.00\n    test_firewall_enabled_iptables_driver                        OK    0.00\n    test_firewall_enabled_noop_driver                            OK    0.00\nServiceTypeExtensionTestCase\n    test_create_service_type_adminctx_returns_200                OK    0.10\n    test_create_service_type_nonadminctx_returns_403             OK    0.03\n    test_service_type_create                                     OK    0.03\n    test_service_type_delete                                     OK    0.04\n    test_service_type_get                                        OK    0.02\n    test_service_type_list                                       OK    0.02\n    test_service_type_update                                     OK    0.03\n    test_update_service_type_adminctx_returns_200                OK    0.03\n    test_update_service_type_nonadminctx_returns_403             OK    0.03\nServiceTypeExtensionTestCaseXML\n    test_create_service_type_adminctx_returns_200                OK    0.03\n    test_create_service_type_nonadminctx_returns_403             OK    0.03\n    test_service_type_create                                     OK    0.03\n    test_service_type_delete                                     OK    0.03\n    test_service_type_get                                        OK    0.03\n    test_service_type_list                                       OK    0.03\n    test_service_type_update                                     OK    0.04\n    test_update_service_type_adminctx_returns_200                OK    0.03\n    test_update_service_type_nonadminctx_returns_403             OK    0.04\nServiceTypeManagerTestCase\n    test_create_dummy_increases_service_type_refcount            OK    0.18\n    test_create_service_type_default_returns_400                 OK    0.16\n    test_create_service_type_no_svcdef_returns_400               OK    0.16\n    test_delete_dummy_decreases_service_type_refcount            OK    0.19\n    test_delete_service_type_in_use_returns_409                  OK    0.20\n    test_get_default_service_type                                OK    0.16\n    test_get_service_type                                        OK    0.19\n    test_list_service_types                                      OK    0.20\n    test_service_type_create                                     OK    0.16\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.19\n    test_service_type_update_name                                OK    0.19\n    test_service_type_update_set_default_returns_400             OK    0.18\n    test_service_type_update_svc_defs                            OK    0.19\nServiceTypeManagerTestCaseXML\n    test_create_dummy_increases_service_type_refcount            OK    0.18\n    test_create_service_type_default_returns_400                 OK    0.16\n    test_create_service_type_no_svcdef_returns_400               OK    0.16\n    test_delete_dummy_decreases_service_type_refcount            OK    0.20\n    test_delete_service_type_in_use_returns_409                  OK    0.19\n    test_get_default_service_type                                OK    0.16\n    test_get_service_type                                        OK    2.59\n    test_list_service_types                                      OK    0.20\n    test_service_type_create                                     OK    0.16\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.18\n    test_service_type_update_name                                OK    0.19\n    test_service_type_update_set_default_returns_400             OK    0.18\n    test_service_type_update_svc_defs                            OK    0.18\nActionDispatcherTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_action_None                                    OK    0.00\n    test_dispatch_default                                        OK    0.00\nDictSerializerTest\n    test_dispatch_default                                        OK    0.00\nFaultTest\n    test_call_fault                                              OK    0.00\nJSONDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nJSONDictSerializerTest\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.01\n    test_json_with_utf8                                          OK    0.00\nMiddlewareTest\n    test_process_response                                        OK    0.00\nRequestDeserializerTest\n    test_deserialize                                             OK    0.00\n    test_get_action_args                                         OK    0.00\n    test_get_body_deserializer_unknown_content_type              OK    0.00\n    test_get_deserializer                                        OK    0.00\n    test_get_expected_content_type                               OK    0.00\nRequestHeadersDeserializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nRequestTest\n    test_content_type_accept_and_query_extension                 OK    0.00\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_accept_with_given_content_types            OK    0.00\n    test_content_type_from_accept                                OK    0.00\n    test_content_type_from_query_extension                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\n    test_content_type_with_given_content_types                   OK    0.00\nResourceTest\n    test_call_resource_class_bad_request                         OK    0.00\n    test_call_resource_class_internal_error                      OK    0.00\n    test_dispatch                                                OK    0.00\n    test_dispatch_unknown_controller_action                      OK    0.00\n    test_malformed_request_body_throws_bad_request               OK    0.00\n    test_type_error                                              OK    0.00\n    test_wrong_content_type_server_error                         OK    0.00\n    test_wrong_content_type_throws_unsupported_media_type_error  OK    0.00\nResponseHeadersSerializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nResponseSerializerTest\n    test_get_body_serializer                                     OK    0.00\n    test_get_serializer                                          OK    0.00\n    test_serialize_json_response                                 OK    0.00\n    test_serialize_response_None                                 OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_response                                  OK    0.00\nSerializerTest\n    test_deserialize_json_content_type                           OK    0.00\n    test_deserialize_raise_bad_request                           OK    0.00\n    test_deserialize_xml_content_type                            OK    0.00\n    test_deserialize_xml_content_type_with_meta                  OK    0.00\n    test_get_deserialize_handler_unknown_content_type            OK    0.00\n    test_serialize_content_type_json                             OK    0.00\n    test_serialize_content_type_xml                              OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_root_is_None                              OK    0.00\n    test_serialize_xml_root_key_is_dict                          OK    0.00\n    test_serialize_xml_root_key_is_list                          OK    0.00\nServerTest\n    test_run_server                                              OK    0.00\nTestWSGIServer\n    test_ipv6_listen_called_with_scope                           OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nTextDeserializerTest\n    test_dispatch_default                                        OK    0.00\nXMLDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_initialization                                          OK    0.00\n    test_xml_empty                                               OK    0.00\n    test_xml_with_utf8                                           OK    0.00\nXMLDictSerializerTest\n    test_None                                                    OK    0.00\n    test_call                                                    OK    0.00\n    test_empty_dic_xml                                           OK    0.00\n    test_non_root_one_item_dic_xml                               OK    0.00\n    test_non_root_two_items_dic_xml                              OK    0.00\n    test_xml                                                     OK    0.02\n    test_xml_meta_contains_node_name_dict                        OK    0.00\n    test_xml_meta_contains_node_name_list                        OK    0.00\n    test_xml_root_key_is_list                                    OK    0.00\n    test_xml_with_unicode                                        OK    0.00\n    test_xml_with_utf8                                           Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.EgIkSUJtR1\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1: 21047 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/30\n[SCP] Copying console log.\n\n\n','<955879394.182.1368081623393.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1270597535.8035290.1423075198545.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 13:39:58',-18000,'2015-02-04 18:39:58',NULL,'[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday 4th\n February 2015 @ 2200 UTC in #openstack-meeting','Hi all,\n\nJust a quick (belated) reminder that there is an OpenStack Telco Working group meeting in #openstack-meeting today @ 2200 UTC. I\'m currently updating the agenda, please review and add any items here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nThanks,\n\nSteve\n\n\n','<858154305.8034703.1423075174659.JavaMail.zimbra@redhat.com>',NULL),('<1270597535.8035290.1423075198545.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-02-04 13:39:58',-18000,'2015-02-04 18:39:58',NULL,'[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday 4th\n February 2015 @ 2200 UTC in #openstack-meeting','Hi all,\n\nJust a quick (belated) reminder that there is an OpenStack Telco Working group meeting in #openstack-meeting today @ 2200 UTC. I\'m currently updating the agenda, please review and add any items here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nThanks,\n\nSteve\n\n\n','<858154305.8034703.1423075174659.JavaMail.zimbra@redhat.com>',NULL),('<1270781067.31.1378276243306.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:30:43',0,'2013-09-04 06:30:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-grizzly #19','See <https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/19/>\n\n\n\n',NULL,NULL),('<1270956248.4901164.1345560349206.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-21 10:45:49',-14400,'2012-08-21 14:45:49',NULL,'[openstack-dev] [openstack-common] Add auth_token.py from\n keystone middleware to openstack-common','\n\n----- Original Message -----\n> From: \"Mark McLoughlin\" <markmc at redhat.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, August 20, 2012 5:02:34 PM\n> Subject: Re: [openstack-dev] [openstack-common] Add auth_token.py from keystone middleware to openstack-common\n> \n> On Sat, 2012-08-18 at 16:23 -0500, Michael Basnight wrote:\n> > Side note: I\'d prefer to not install all of keystone to get this\n> > one\n> > module, no matter where it is.\n> \n> FWIW, Fedora packages auth_token.py as python-keystone-auth-token so\n> that you don\'t need to install of keystone for just the middleware.\n\n\nActually. With some of the most recent Folsom changes auth_token.py now has some external dependencies on several other keystone modules:\n\n from keystone.openstack.common import jsonutils\n from keystone.common import cms\n from keystone.common import utils\n from keystone.openstack.common import timeutils\n\nIf we want users to be able to deploy just the single module (like was possible with Essex) I think we may want to re-work some of this so that auth_token.py is once again stand alone.\n\nDan\n\n\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1345496554.4723.84.camel@sorcha>',NULL),('<1271001683.2708956.1376577240819.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-15 10:34:00',-14400,'2013-08-15 14:34:00',NULL,'[Openstack-docs] What\'s Up Doc? Aug 14, 2013','----- Original Message -----\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: openstack-docs at lists.openstack.org, \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Cc: \"Glen Campbell\" <glen.campbell at rackspace.com>, \"Anne Gentle\" <anne.gentle at rackspace.com>\n> Sent: Wednesday, August 14, 2013 5:17:14 PM\n> Subject: [Openstack-docs] What\'s Up Doc? Aug 14, 2013\n\n> 5. Doc tools updates:\n> The Maven plugin that builds our docs is sourced at\n> https://github.com/rackerlabs/clouddocs-maven-plugin and just released\n> version 1.9.0.\n> \n> Our pom.xml files still point to 1.8.0 but we could start testing 1.9.0\n> which adds supports for olinks. By using olinks instead of our current\n> linking with xrefs would prevent Oxygen from showing non-valid file\n> warnings in individual chapter files and adds an easier interface for\n> finding cross-reference links. David Cramer can demo at the Boot Camp, and\n> then we\'ll need to make decisions about how much cross-referencing we want.\n> With fewer books going to a \"released\" docs site, we may want to limit the\n> use of cross-references altogether, but let\'s discuss in person. Our\n> current linking conventions are here:\n> https://wiki.openstack.org/wiki/Documentation/Conventions#Linking.\n\nI am going to be very active/interested in where we take this both because I\'m not overly familiar with the use of olinks and because Publican doesn\'t currently support them (shenanigans ahead!) at this time. Does anyone have some good examples from other projects? The page in The DocBook Guide gives me the impression some of the key attributes are used in fairly implementation specific/defined ways [1].\n\nThanks,\n\nSteve\n\n[1] http://docbook.org/tdg5/en/html/olink.html\n\n\n','<CAD0KtVGDdz-yS24d36W6Sr6QcE5anOS5wBjjCh3DETOVTiS=zw@mail.gmail.com>',NULL),('<1271397673.55.1373436293855.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-10 06:04:53',0,'2013-07-10 06:04:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #282','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/282/>\n\n------------------------------------------\n[...truncated 2680 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.110.ga45c49b to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.110.ga45c49b\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.110.ga45c49b\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0 to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/rabbitmq/rabbit at devstack-1373435488-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/rabbitmq/rabbit at devstack-1373435488.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/282/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<549142449.52.1373349889172.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1271467603.23.1379926819176.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-23 09:00:18',0,'2013-09-23 09:00:18',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #27','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/27/>\n\n------------------------------------------\n[...truncated 17939 lines...]\n2013-09-23 06:07:20 # catalog, the first found one is used.\n2013-09-23 06:07:20 #region = RegionOne\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # A large private cidr block from which to allocate smaller blocks for\n2013-09-23 06:07:20 # tenant networks.\n2013-09-23 06:07:20 tenant_network_cidr = 10.100.0.0/16\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # The mask bits used to partition the tenant block.\n2013-09-23 06:07:20 tenant_network_mask_bits = 28\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # If tenant networks are reachable, connectivity checks will be\n2013-09-23 06:07:20 # performed directly against addresses on those networks.\n2013-09-23 06:07:20 tenant_networks_reachable = false\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Id of the public network that provides external connectivity.\n2013-09-23 06:07:20 public_network_id = \n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Id of a shared public router that provides external connectivity.\n2013-09-23 06:07:20 # A shared public router would commonly be used where IP namespaces\n2013-09-23 06:07:20 # were disabled.  If namespaces are enabled, it would be preferable\n2013-09-23 06:07:20 # for each tenant to have their own router.\n2013-09-23 06:07:20 public_router_id = \n2013-09-23 06:07:20 \n2013-09-23 06:07:20 \n2013-09-23 06:07:20 [volume]\n2013-09-23 06:07:20 volume_backup_enabled = True\n2013-09-23 06:07:20 # This section contains the configuration options used when executing tests\n2013-09-23 06:07:20 # against the OpenStack Block Storage API service\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-23 06:07:20 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-23 06:07:20 # probably want to leave this value as \"volume\"\n2013-09-23 06:07:20 catalog_type = volume\n2013-09-23 06:07:20 # The name of a region for volume. If empty or commented-out, the value of\n2013-09-23 06:07:20 # identity.region is used instead. If no such region is found in the service\n2013-09-23 06:07:20 # catalog, the first found one is used.\n2013-09-23 06:07:20 #region = RegionOne\n2013-09-23 06:07:20 # The disk format to use when copying a volume to image\n2013-09-23 06:07:20 disk_format = raw\n2013-09-23 06:07:20 # Number of seconds to wait while looping to check the status of a\n2013-09-23 06:07:20 # volume that is being made available\n2013-09-23 06:07:20 build_interval = 1\n2013-09-23 06:07:20 # Number of seconds to time out on waiting for a volume\n2013-09-23 06:07:20 # to be available or reach an expected status\n2013-09-23 06:07:20 build_timeout = 400\n2013-09-23 06:07:20 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-23 06:07:20 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-23 06:07:20 # have to be different)\n2013-09-23 06:07:20 multi_backend_enabled = false\n2013-09-23 06:07:20 backend1_name = BACKEND_1\n2013-09-23 06:07:20 backend2_name = BACKEND_2\n2013-09-23 06:07:20 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-23 06:07:20 # You should update to reflect those exported by configured backend driver.\n2013-09-23 06:07:20 storage_protocol = iSCSI\n2013-09-23 06:07:20 vendor_name = Open Source\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 [object-storage]\n2013-09-23 06:07:20 # This section contains configuration options used when executing tests\n2013-09-23 06:07:20 # against the OpenStack Object Storage API.\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # You can configure the credentials in the compute section\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-23 06:07:20 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-23 06:07:20 # this value as \"object-store\"\n2013-09-23 06:07:20 catalog_type = object-store\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # The name of a region for object storage. If empty or commented-out, the\n2013-09-23 06:07:20 # value of identity.region is used instead. If no such region is found in\n2013-09-23 06:07:20 # the service catalog, the first found one is used.\n2013-09-23 06:07:20 #region = RegionOne\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Number of seconds to time on waiting for a container to container\n2013-09-23 06:07:20 # synchronization complete\n2013-09-23 06:07:20 container_sync_timeout = 120\n2013-09-23 06:07:20 # Number of seconds to wait while looping to check the status of a\n2013-09-23 06:07:20 # container to container synchronization\n2013-09-23 06:07:20 container_sync_interval = 5\n2013-09-23 06:07:20 # Set to True if the Account Quota middleware is enabled\n2013-09-23 06:07:20 accounts_quotas_available = True\n2013-09-23 06:07:20 # Set to True if the Container Quota middleware is enabled\n2013-09-23 06:07:20 container_quotas_available = True\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Set operator role for tests that require creating a container\n2013-09-23 06:07:20 operator_role = Member\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 [boto]\n2013-09-23 06:07:20 ssh_user = cirros\n2013-09-23 06:07:20 # This section contains configuration options used when executing tests\n2013-09-23 06:07:20 # with boto.\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # EC2 URL\n2013-09-23 06:07:20 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-23 06:07:20 # S3 URL\n2013-09-23 06:07:20 s3_url = http://127.0.0.1:3333\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-23 06:07:20 aws_access =\n2013-09-23 06:07:20 aws_secret =\n2013-09-23 06:07:20 \n2013-09-23 06:07:20 # Image materials for S3 upload\n2013-09-23 06:07:20 # ALL content of the specified directory will be uploaded to S3\n2013-09-23 06:07:20 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-23 06:07:21 # Subdirectories not allowed!\n2013-09-23 06:07:21 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-23 06:07:21 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-23 06:07:21 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-23 06:07:21 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Instance type\n2013-09-23 06:07:21 instance_type = m1.nano\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # TCP/IP connection timeout\n2013-09-23 06:07:21 http_socket_timeout = 30\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Number of retries actions on connection or 5xx error\n2013-09-23 06:07:21 num_retries = 1\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Status change wait timout\n2013-09-23 06:07:21 build_timeout = 400\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Status change wait interval\n2013-09-23 06:07:21 build_interval = 1\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [orchestration]\n2013-09-23 06:07:21 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-09-23 06:07:21 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-23 06:07:21 # this value as \"orchestration\"\n2013-09-23 06:07:21 catalog_type = orchestration\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # The name of a region for orchestration. If empty or commented-out, the value\n2013-09-23 06:07:21 # of identity.region is used instead. If no such region is found in the service\n2013-09-23 06:07:21 # catalog, the first found one is used.\n2013-09-23 06:07:21 #region = RegionOne\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Status change wait interval\nstress create: /opt/stack/new/tempest/.tox/stress\n2013-09-23 06:07:21 build_interval = 1\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Status change wait timout. This may vary across environments as some some\n2013-09-23 06:07:21 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-23 06:07:21 build_timeout = 300\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Instance type for tests. Needs to be big enough for a\n2013-09-23 06:07:21 # full OS plus the test workload\n2013-09-23 06:07:21 instance_type = m1.micro\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-23 06:07:21 # If not specified, tests that spawn instances will not run\n2013-09-23 06:07:21 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-23 06:07:21 # any key, which will generate a keypair for each test class\n2013-09-23 06:07:21 #keypair_name = heat_key\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [dashboard]\n2013-09-23 06:07:21 # URL where to find the dashboard home page\n2013-09-23 06:07:21 dashboard_url = http://127.0.0.1/\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # URL where to submit the login form\n2013-09-23 06:07:21 login_url = http://127.0.0.1/auth/login/\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [scenario]\n2013-09-23 06:07:21 # Directory containing image files\n2013-09-23 06:07:21 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # AMI image file name\n2013-09-23 06:07:21 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # ARI image file name\n2013-09-23 06:07:21 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # AKI image file name\n2013-09-23 06:07:21 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # ssh username for the image file\n2013-09-23 06:07:21 ssh_user = cirros\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 # specifies how many resources to request at once. Used for large operations\n2013-09-23 06:07:21 # testing.\"\n2013-09-23 06:07:21 large_ops_number = 0\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [cli]\n2013-09-23 06:07:21 # Enable cli tests\n2013-09-23 06:07:21 enabled = True\n2013-09-23 06:07:21 # directory where python client binaries are located\n2013-09-23 06:07:21 cli_dir = /usr/local/bin\n2013-09-23 06:07:21 # Number of seconds to wait on a CLI timeout\n2013-09-23 06:07:21 timeout = 15\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [service_available]\n2013-09-23 06:07:21 # Whether or not cinder is expected to be available\n2013-09-23 06:07:21 cinder = True\n2013-09-23 06:07:21 # Whether or not neutron is expected to be available\n2013-09-23 06:07:21 neutron = False\n2013-09-23 06:07:21 # Whether or not glance is expected to be available\n2013-09-23 06:07:21 glance = True\n2013-09-23 06:07:21 # Whether or not swift is expected to be available\n2013-09-23 06:07:21 swift = True\n2013-09-23 06:07:21 # Whether or not nova is expected to be available\n2013-09-23 06:07:21 nova = True\n2013-09-23 06:07:21 # Whether or not Heat is expected to be available\n2013-09-23 06:07:21 heat = True\n2013-09-23 06:07:21 # Whether or not horizon is expected to be available\n2013-09-23 06:07:21 horizon = True\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [stress]\n2013-09-23 06:07:21 # Maximum number of instances to create during test\n2013-09-23 06:07:21 max_instances = 32\n2013-09-23 06:07:21 # Time (in seconds) between log file error checks\n2013-09-23 06:07:21 log_check_interval = 60\n2013-09-23 06:07:21 # The default number of threads created while stress test\n2013-09-23 06:07:21 default_thread_number_per_action=4\n2013-09-23 06:07:21 \n2013-09-23 06:07:21 [debug]\n2013-09-23 06:07:21 # Enable diagnostic commands\n2013-09-23 06:07:21 enable = True\n2013-09-23 06:07:21 ++ IFS=\' 	\n2013-09-23 06:07:21 \'\n2013-09-23 06:07:21 ++ set +o errexit\n2013-09-23 06:07:21 ++ init_tempest\n2013-09-23 06:07:21 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-23 06:07:21 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-23 06:07:21 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-23 06:07:21 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-23 06:07:21 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1826.gfcbca58.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-373883\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-373883/27\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-373883/27/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-373883/27/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az1-373883/27/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<34182846.19.1379754017541.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1271500514.15948916.1416769269534.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-23 14:01:09',-18000,'2014-11-23 19:01:09',NULL,'[OpenStack-docs] [networking] DVR and VLANs?','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> To: \"Nick Chase\" <nchase at mirantis.com>\n> \n> Based on what I read while putting a patch together, it wasn\'t going to for\n> Juno. This bug is in progress for tracking.\n> \n> https://bugs.launchpad.net/neutron/+bug/1374995\n\nRight, there are also currently issues with using DVR+IPV6:\n\nhttps://bugs.launchpad.net/neutron/+bug/1376325\n\n> > On Nov 22, 2014, at 5:32 AM, Nick Chase <nchase at mirantis.com> wrote:\n> > \n> > Someone asked me about this today and I didn\'t know the answer: does DVR\n> > work with VLANs?\n> > \n> > ---- Nick\n> > _______________________________________________\n> > OpenStack-docs mailing list\n> > OpenStack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> _______________________________________________\n> OpenStack-docs mailing list\n> OpenStack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<4A57D7BE-06AF-42B8-9EC4-D3D2C38CB43D@justwriteclick.com>',NULL),('<1271584604e6438a8171f3424699f059@BY2PR07MB044.namprd07.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-07-04 19:11:37',0,'2014-07-04 19:11:37',NULL,'[Openstack-docs] Which docbookxi.rng file to use with XML Copy\n	Editor','I am using XML Copy Editor. When I open a file that the openstack.ent statement:\n\n\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE chapter [\n<!ENTITY % openstack SYSTEM \"../common/entities/openstack.ent\">\n%openstack;\n]>\n\nI now get a validation error.\n\nI believe I need a new docbookxi.rng file to validate against. Andreas suggested that I ask the list which one to use for XML Copy Editor.\n\nAny ideas?\n\nThanks,\n\nLaurel\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140704/96d24c56/attachment.html>\n\n',NULL,NULL),('<1272061042.35.1372659294691.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-01 06:14:54',0,'2013-07-01 06:14:54',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #82','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/82/>\n\n\n\n','<236862865.32.1372572903649.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1272362839.300.1366697846946.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-23 06:17:26',0,'2013-04-23 06:17:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #204','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/204/>\n\n------------------------------------------\n[...truncated 946 lines...]\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.02\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.19\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: We test the following:\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance.py\",> line 628, in test_add_location_with_checksum\n    exitcode, out, err = execute(cmd)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 255, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command bin/glance --port=53620 add is_public=True disk_format=raw container_format=ovf name=MyImage location=http://localhost:0 checksum=1 did not succeed. Returned an exit code of 1.\n\nSTDOUT: Failed to connect to the Glance API server 0.0.0.0:53620. Is the server running?\n\n\nSTDERR: WARNING! This tool is deprecated in favor of python-glanceclient (see http://github.com/openstack/python-glanceclient).\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 90.31 secs:\n    20.80    TestBinGlanceCacheManage.test_queue\n    18.56    TestBinGlance.test_results_filtering\n    17.14    TestRootApi.test_version_configurations\n    17.01    TestGlanceControl.test_bouncing\n    16.80    TestScrubber.test_delayed_delete\n----------------------------------------------------------------------\nRan 926 tests in 766.252s\n\nFAILED (SKIP=106, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-204\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.1.2\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.UIku43vcTY\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/204\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/204/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1272510562.5377720.1386789322036.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 14:15:22',-18000,'2013-12-11 19:15:22',NULL,'[openstack-dev] [TripleO][Tuskar] Terminology','Hi,\n\nI\'m trying to clarify the terminology being used for Tuskar, which may be helpful so that we\'re sure\nthat we\'re all talking about the same thing :)  I\'m copying responses from the requirements thread\nand combining them with current requirements to try and create a unified view.  Hopefully, we can come\nto a reasonably rapid consensus on any desired changes; once that\'s done, the requirements can be\nupdated.\n\n* NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly\n       useful for a given role.\n\n     * REGISTRATION - the act of creating a node in Ironic\n\n     * ROLE - a specific workload we want to map onto one or more nodes. Examples include \'undercloud control plane\', \'overcloud control\n       plane\', \'overcloud storage\', \'overcloud compute\' etc.\n\n         * MANAGEMENT NODE - a node that has been mapped with an undercloud role\n         * SERVICE NODE - a node that has been mapped with an overcloud role\n            * COMPUTE NODE - a service node that has been mapped to an overcloud compute role\n            * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role\n            * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role\n            * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role\n\n         * UNDEPLOYED NODE - a node that has not been mapped with a role\n              * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?)\n                                   - (after reading lifeless\'s explanation, I agree that \"allocation\" may be a\n                                      misleading term under TripleO, so I personally vote for UNDEPLOYED)\n\n     * INSTANCE - A role deployed on a node - this is where work actually happens.\n\n* DEPLOYMENT\n\n     * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role\n           * another option - DISTRIBUTE NODES (?)\n                                 - (I think the former is more accurate, but perhaps there\'s a better way to say it?)\n\n     * SCHEDULING - the process of deciding which role is deployed on which node\n\n     * SERVICE CLASS - a further categorization within a service role for a particular deployment.\n\n          * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to\n                           a service class\n\n\n\nDoes this seem accurate?  All feedback is appreciated!\n\nMainn\n\n\n','<1514935125.5273607.1386779764196.JavaMail.root@redhat.com>',NULL),('<1273272612.897142.1347293464572.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2012-09-10 09:11:04',-25200,'2012-09-10 16:11:04',NULL,'[openstack-hpc] [Openstack] [HPC] Reminder\n	monthly	telecon	Sep.	10','\n Webex,\n\n https://usc-isi.webex.com/mw0306ld/mywebex/default.do?siteurl=usc-isi\n\n password: dodcs\n\n David \n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n----- Original Message -----\n> While setting up webex, please call\n> 1-866-528-2256; code: 3289628\n> \n> for the audio conference.\n> \n> Thanks,\n> David\n> \n> \n> ----------------------\n> Dr. Dong-In \"David\" Kang\n> Computer Scientist\n> USC/ISI\n> \n> ----- Original Message -----\n> > Hello,\n> >\n> > We will use different webex host today because of some technical\n> > problem.\n> > Sorry for that.\n> >\n> > David\n> >\n> > ----------------------\n> > Dr. Dong-In \"David\" Kang\n> > Computer Scientist\n> > USC/ISI\n> >\n> > ----- Original Message -----\n> > > I am guessing your intent is to determine the maximum available\n> > > bandwidth and lowest latency (commonly implemented as least hops)\n> > > path\n> > > between hosts. In other platforms there is the notion of Cell,\n> > > Zone,\n> > > Row, Rack etc where the host that you are running your workload\n> > > has\n> > > the topology encoded in the host meta information itself.\n> > >\n> > >\n> > > In instances where this is not encoded within some sort of meta of\n> > > the\n> > > host either shortest path first or constrained shortest path first\n> > > can\n> > > be run to determine the network, topology and either distributed\n> > > to\n> > > the nodes. The challenge here is that it is really hard to take\n> > > into\n> > > account available bandwidth between nodes vs hops.\n> > >\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > Regards,\n> > >\n> > > Colin\n> > >\n> > > If you would like to schedule a time to speak with me, please\n> > > click\n> > > here to see my calendar and pick a time that works for your\n> > > schedule.\n> > > The system will automatically send us both an outlook meeting\n> > > invite.\n> > > Colin McNamara\n> > > (858)208-8105\n> > > CCIE #18233,VCP\n> > > http://www.colinmcnamara.com\n> > > http://www.linkedin.com/in/colinmcnamara\n> > >\n> > > \"The difficult we do immediately, the impossible just takes a\n> > > little\n> > > longer\"\n> > >\n> > >\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > On Sep 7, 2012, at 9:54 AM, Joseph Suh < jsuh at isi.edu > wrote:\n> > >\n> > >\n> > > All,\n> > >\n> > > I have a blue print on proximity scheduler at\n> > > http://wiki.openstack.org/ProximityScheduler , and would like to\n> > > get\n> > > feedback on it.\n> > >\n> > > Thanks,\n> > >\n> > > Joseph\n> > >\n> > > ----- Original Message -----\n> > > From: \"John Paul Walters\" < jwalters at isi.edu >\n> > > To: openstack at lists.launchpad.net\n> > > Cc: openstack-hpc at lists.openstack.org\n> > > Sent: Friday, September 7, 2012 12:12:20 PM\n> > > Subject: [openstack-hpc] [HPC] Reminder monthly telecon Sep. 10\n> > >\n> > >\n> > > Hi,\n> > >\n> > >\n> > > This is a reminder that we\'ll hold our next monthly HPC telecon\n> > > this\n> > > coming Monday, Sep. 10 and 12:00 noon Eastern Time. We\'ll use\n> > > webex\n> > > (details below). The agenda is somewhat open. Our default will be\n> > > to\n> > > start the conversation about HPC features that folks are\n> > > interested\n> > > in\n> > > adding to the Grizzly release. If anyone has any other specific\n> > > agenda\n> > > items, they\'re welcome to propose them.\n> > >\n> > >\n> > > I\'m unable to attend, so my colleague David Kang will be hosting\n> > > this\n> > > meeting. We look forward to talking to you!\n> > >\n> > >\n> > > best,\n> > > JP\n> > >\n> > >\n> > > John Paul Walters invites you to attend this online meeting.\n> > >\n> > > Topic: HPC Monthly Telecon\n> > > Date: Monday, September 10, 2012\n> > > Time: 12:00 pm, Eastern Daylight Time (New York, GMT-04:00)\n> > > Meeting Number: 927 246 497\n> > > Meeting Password: hpcmonthly\n> > >\n> > >\n> > > -------------------------------------------------------\n> > > To join the online meeting (Now from mobile devices!)\n> > > -------------------------------------------------------\n> > > 1. Go to\n> > > https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&RT=MiMxMQ%3D%3D\n> > > 2. If requested, enter your name and email address.\n> > > 3. If a password is required, enter the meeting password:\n> > > hpcmonthly\n> > > 4. Click \"Join\".\n> > >\n> > > To view in other time zones or languages, please click the link:\n> > > https://openstack.webex.com/openstack/j.php?ED=203524102&UID=1431607857&PW=NYzljOTEwYThj&ORT=MiMxMQ%3D%3D\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-HPC mailing list\n> > > OpenStack-HPC at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n> > >\n> > > _______________________________________________\n> > > Mailing list: https://launchpad.net/~openstack\n> > > Post to : openstack at lists.launchpad.net\n> > > Unsubscribe : https://launchpad.net/~openstack\n> > > More help : https://help.launchpad.net/ListHelp\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-HPC mailing list\n> > > OpenStack-HPC at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n> >\n> > _______________________________________________\n> > OpenStack-HPC mailing list\n> > OpenStack-HPC at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n> \n> _______________________________________________\n> OpenStack-HPC mailing list\n> OpenStack-HPC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n\n','<1869435819.897132.1347293240555.JavaMail.root@zm.isi.edu>',NULL),('<1273294089.7966193.1405611671750.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 11:41:11',-14400,'2014-07-17 15:41:11',NULL,'[openstack-dev] [devstack][keystone] (98)Address already in\n use: make_sock: could not bind to address [::]:5000 & 0.0.0.0:5000','Hi,\n\nYou can handle this one of two ways.\n\n1)\nsemanage port -m -t <the new label you choose> -p tcp 5000\n\nWhich will relabel port 5000 as whatever you choose.\n\n2)\nOr you could allow <the label you choose> to bind to commplex_main_port_t\n\nallow <your label> commplex_main_port_t:tcp_socket name_bind;\n\nThis will allow <your label> to connect to any port labeled commplex_main_port_t. \n\nSincerely,\nRyan\n\n----- Original Message -----\nFrom: \"Ray Chen\" <chenrano2002 at gmail.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Thursday, July 17, 2014 10:57:41 AM\nSubject: Re: [openstack-dev] [devstack][keystone] (98)Address already in use: make_sock: could not bind to address [::]:5000 & 0.0.0.0:5000\n\ntry to disable the selinux module. I can setup devstack env on my fedora machine with selinux disabled \n\non my fedora machine, selinux is disable, and port 5000 look likes are still used by selinux, \n[ray at fedora devstack]$ sudo semanage port -l|grep 5000 \ncluster_port_t tcp 5149, 40040, 50006-50008 \ncluster_port_t udp 5149, 50006-50008 \ncommplex_main_port_t tcp 5000 \ncommplex_main_port_t udp 5000 \n\n[ray at fedora devstack]$ netstat -anp | grep 5000 \n\ntcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 6171/python \n[ray at fedora devstack]$ ps -ef | grep python \nray 6171 5695 0 21:34 pts/3 00:00:07 python /opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --debug \n\n\n\n\nOn Thu, Jul 17, 2014 at 10:23 PM, Rich Megginson < rmeggins at redhat.com > wrote: \n\n\n\nOn 07/16/2014 10:40 PM, Joe Jiang wrote: \n\n\n\nHi all, \nThanks for your responds. \n\nI try to running # sudo semanage port -l|grep 5000 in my envrionment and get same infomation. \n>> ... \n>> commplex_main_port_t tcp 5000 \n>> commplex_main_port_t udp 5000 \nthen, I wanna remove this port(5000) from SELinux policy rules list use this command(semanage port -d -p tcp -t commplex_port_t 5000), \nthe console echo is \"/usr/sbin/semanage: Port tcp/5000 is defined in policy, cannot be deleted\" , and \'udp/5000\' is same reply. \nSome sounds[1] say, this port is declared in the corenetwork source policy which is compiled in the base module. \nSo, Have to recompile selinux module? \n\nI think that\'s the only way to do it if you want to relabel port 5000. \n\n\n\n\n\n\n\n\nThanks. \nJoe. \n\n[1] \nhttp://www.redhat.com/archives/fedora-selinux-list/2009-September/msg00056.html \n\n\n\n\n>> Another problem with port 5000 in Fedora, and probably more recent\n>> versions of RHEL, is the selinux policy:\n>>  \n>> # sudo semanage port -l|grep 5000\n>> ...\n>> commplex_main_port_t tcp 5000\n>> commplex_main_port_t udp 5000\n>>  \n>> There is some service called \"commplex\" that has already \"claimed\" port\n>> 5000 for its use, at least as far as selinux goes. \n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADDg3B++-GuWpZ1XO4OThzHgF9MhdecJWv66o9os9fTu_CzhUg@mail.gmail.com>',NULL),('<1273960505.5271225.1400593396525.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 09:43:16',-14400,'2014-05-20 13:43:16',NULL,'[openstack-dev] [sahara] bug triage day after summit','I think in our eagerness to triage bugs we might have missed that May 26 is a holiday in the U.S.\n\nI know some of us have the day off work and while that doesn\'t necessarily stop the effort, it might throw a wrench in people\'s holiday weekend plans. I\'m wondering if we should re-evaluate and make the following day(May 27) triage day instead?\n\nregards,\nmike\n\n----- Original Message -----\n> Hey sahara folks,\n> \n> let\'s make a Bug Triage Day after the summit.\n> \n> I\'m proposing the May, 26 for it.\n> \n> Any thoughts/objections?\n> \n> Thanks.\n> \n> --\n> Sincerely yours,\n> Sergey Lukjanov\n> Sahara Technical Lead\n> (OpenStack Data Processing)\n> Mirantis Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CA+GZd7-G3DmddcDA7=MfpfOsygabwzkxCMc9kCXMtLoY0=t0Bg@mail.gmail.com>',NULL),('<1274011424.1964426.1396979615717.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 13:53:35',-14400,'2014-04-08 17:53:35',NULL,'[openstack-dev] [nova][cinder] create server from a volume\n snapshot, 180 reties is sufficient?','I think some of the objections to such patches were based on the fact that this is really\njust a shortcut for two separate operations: create a volume from a Glance image, and then boot\noff of that image.  Instead of monkey-patching it, we should either figure out a way to dynamically\nconfigure the timeout based on image size, network conditions, etc, or we should just remove the shortcut\nentirely, and just have people do the two steps separately (the current workaround for large disk images).\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Ben Swartzlander\" <Ben.Swartzlander at netapp.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, April 8, 2014 12:08:52 PM\nSubject: Re: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient?\n\n\n\nOptions may be bad, but hardcoded values chosen arbitrarily are worse. Unless someone can justify why the value needs to be 180 and not 179 or 181 then it should be configurable. That?s my opinion at any rate. \n\n\n\n-Ben \n\n\n\n\n\nFrom: Lingxian Kong [mailto:anlin.kong at gmail.com] \nSent: Tuesday, April 08, 2014 11:59 AM \nTo: OpenStack Development Mailing List \nSubject: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient? \n\n\n\n\nhi there: \n\n\n\n\n\nAccording to the patch https://review.openstack.org/#/c/80619/ , Nova \n\n\nwill wait for volume creation for 180s, the config option is rejected by \n\n\nRussell and Nikola. But the reason I raise it up is, we found the server \n\n\ncreation failed due to timeout in our deployment, with LVM as Cinder \n\n\nbackend. \n\n\n\n\n\nSo, I wander is 180s really suitable here? Are there some guidences \n\n\nabout when should we add an option? But at least, we should not avoid an \n\n\noption, just because of the existing overwhelming number of them, right? \n\n\n\n\n\nThoughts? \n\n\n\n\n\n\n\n\n\n\n\n-- \n\n\n--------------------------------------- \n\n\nLingxian Kong \n\n\nHuawei Technologies Co.,LTD. \n\n\nIT Product Line CloudOS PDU \n\n\nChina, Xi\'an \n\n\nMobile: +86-18602962792 \n\n\nEmail: konglingxian at huawei.com ; anlin.kong at gmail.com \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53E7920A93307949AC19339A21136DC937A03AA0@SACEXCMBX01-PRD.hq.netapp.com>',NULL),('<127443520.6768742.1386981065832.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 19:31:05',-18000,'2013-12-14 00:31:05',NULL,'[openstack-dev] [TripleO][Tuskar] Terminology','Thanks for the reply!  Let me try and address one particular section for now,\nsince it seems to be the part causing the most confusion:\n\n> >      * SERVICE CLASS - a further categorization within a service role for a\n> >      particular deployment.\n> > \n> >           * NODE PROFILE - a set of requirements that specify what\n> >           attributes a node must have in order to be mapped to\n> >                            a service class\n> \n> I think I still need some more information about the above two. They\n> sound vaguely like Cobbler\'s system profiles... :)\n\nI admit that this concept was a bit fuzzy for me as well, but after a few IRC\nchats, I think I have a better handle on this.  Let me begin with my understanding of what\nhappens in Heat, using Heat terminology:\n\nA Heat stack template defines RESOURCES.  When a STACK is deployed using that template,\nthe resource information in the template is used to instantiate an INSTANCE of that\nresource on a NODE.  Heat can pass a FLAVOR (flavors?) to nova-scheduler in order to\nfilter for appropriate nodes.\n\nSo: based on that explanation, here\'s what Tuskar has been calling the above:\n\nHEAT TERM == TUSKAR TERM\n------------------------\nNODE == NODE\nSTACK == DEPLOYMENT\nINSTANCE == INSTANCE\nRESOURCE == SERVICE CLASS (at the very least, it\'s a one-to-one correspondence)\nFLAVOR == NODE PROFILE\n???    == ROLE\n\nThe ??? is because ROLE is entirely a Tuskar concept, based on what TripleO views\nas the fundamental kinds of building blocks for an overcloud: Compute, Controller,\nObject Storage, Block Storage.  A ROLE essentially categorizes RESOURCES/SERVICE CLASSES;\nfor example, the Control ROLE might contain a control-db resource, control-secure resource,\ncontrol-api resource, etc.\n\nHeat cares only about the RESOURCE and not the ROLE; if the roles were named Foo1, Foo2, Foo3,\nand Barney, Heat would not care.  Also, if the UI miscategorized, say, the control-db resource\nunder the Block Storage category - Heat would again not care, and the deploy action would work.\n\n>From that perspective, I think the above terminology should either *be* the Heat term, or be\na word that closely corresponds to the intended purpose.  For example, I think DEPLOYMENT reasonably\ndescribes a STACK, but I don\'t think SERVICE CLASS works for RESOURCE.  I also think ROLE should be\nRESOURCE CATEGORY, since that seems to me to be the most straightforward description of its purpose.\n\nPeople with more experience in Heat, please correct any of my misunderstandings!\n\n\nMainn\n\n> \n> Best,\n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1386976903.2137.37.camel@uberbox.gateway.2wire.net>',NULL),('<1274935987.29.1352592245411.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-11 00:04:05',0,'2012-11-11 00:04:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #89','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/89/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.01\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.01\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.36\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.06\n    test_public_versions                                        OK  0.06\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 20.286s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.18 secs:\n    2.34       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    2.31       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    1.08       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.08       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.36       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at f617b09874046a0f56f6342638cc8444ed719022#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 217bd202dd9a7359efb8b49799eb0626866a203f#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/89\n[SCP] Copying console log.\n\n\n','<1375856201.17.1352505891861.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1274C9FD-ECB8-4E9D-803F-9C93C0D77B39@pravka.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-17 22:24:29',-28800,'2013-11-18 06:24:29',NULL,'[Openstack] where do we use NodeJS in openstack?','NodeJS was actually dropped for Horizon in Havana in favor of lesscpy:\n\nhttps://review.openstack.org/#/c/37473/\n\n-Aaron\n\n> On Nov 17, 2013, at 9:38 PM, Purandhar Sairam Mannidi <sairam.mp at freescale.com> wrote:\n> \n> Hi,\n>  \n> When we?re trying to install Openstack components like horizon in one of our boards we found that it requires NodeJS package.\n> We?re trying to understand where this NodeJS package is used. Any inputs would be helpful.\n>  \n> Thanks,\n> Sairam\n>  \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131117/14045a64/attachment.html>\n\n','<F175ADA1EA02D84E88F89EFA83943B1C08EE08AD@039-SN1MPN1-001.039d.mgd.msft.net>',NULL),('<1275241524.32916946.1408363555012.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 08:05:55',-14400,'2014-08-18 12:05:55',NULL,'[openstack-dev] [nova][cinder][qa] Volume attachment not visible on\n	the guest','Hi All,\n\nI have a `little` trouble with the volume attachment stability.\n\nThe test_stamp_pattern test is skipped since long, you\ncan see what would happen if it would be enabled [1] now.\n\nThere is a workaround kind way for enabling that test [2].\n\nI suspected the acpi hot plug event is not detected by the kernel \nat some phases of the boot, for example after the first pci scan,\n but before the pci hot plug initialized.\n\nIs the above blind spot really exists ?\n\nIf yes, is something what needs to be handled by init system or\n kernel needs to ensure all device is discovered before calling init ?\n\nLong time ago I had trouble with reproducing the above issue,\nbut now I was able to see a PCI rescan can solve the issue.\n\'echo \"1\" > /sys/bus/pci/rescan\' (ssh to guest)\n\nRecently we found `another type` of volume attachment issue,\nwhen booting from volume. [3]\n\nHere I would expect the PCI device is ready before,\nthe VM actually started, but according to the \nconsole log, the disk device is missing.\n\nWhen I am booting from an iscsi volume, is the virtual device show up\nguaranteed by nova/cinder/libvirt/qemu/whatever\n to be present at the first pci scan ?\n\nIs there anything what can delay the device/disk appearance ?\n\nBest Regards,\nAttila\n\n[1] https://review.openstack.org/#/c/52740/\n[2] https://review.openstack.org/#/c/62886/\n[3] https://bugs.launchpad.net/nova/+bug/1357677\n\n\n','<456642625.32903516.1408362226208.JavaMail.zimbra@redhat.com>',NULL),('<127605220.7494542.1362680446757.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 13:20:46',-18000,'2013-03-07 18:20:46',NULL,'[openstack-dev] [Nova] Proposal to add Devananda van der Veen\n to	nova-core','+1\n\n----- Original Message -----\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, March 6, 2013 2:31:15 PM\n> Subject: [openstack-dev] [Nova] Proposal to add Devananda van der Veen to	nova-core\n> \n> Greetings,\n> \n> I would like to propose adding Devananda van der Veen (devananda) to\n> the\n> nova-core team.\n> \n>     https://review.openstack.org/#/dashboard/2889\n> \n> Devananda has been very helpful in a number of areas, including nova\n> reviews.  I was very impressed by the database expertise he\n> demonstrated\n> during the last design summit.  He carried that into the Grizzly\n> cycle\n> by leading the Nova DB team, which accomplished a number of database\n> usage improvements in Grizzly.  He has also been spending a lot of\n> time\n> improving the new baremetal driver.\n> \n> Please respond with comments, +1s, or objections within one week.\n> \n> Thanks,\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51379983.1040805@redhat.com>',NULL),('<1276277002.118.1384497214355.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-15 06:33:34',0,'2013-11-15 06:33:34',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #48','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/48/>\n\n------------------------------------------\n[...truncated 21370 lines...]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_reserve_unreserve_volume[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_reserve_unreserve_volume[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  218.921\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_get_console_output[gate]                     218.100\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          111.032\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  61.885\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             46.710\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                40.455\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                          37.942\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_create_backup[gate]                            37.643\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     32.709\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_manual_disk_config[gate]   31.886\n\n----------------------------------------------------------------------\nRan 1503 tests in 1379.800s\n\nOK (skipped=78)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-659593-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-659593.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-659593/48/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<572624135.114.1384324310754.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1276815382.1496022.1399294312362.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 08:51:52',-14400,'2014-05-05 12:51:52',NULL,'[openstack-dev] [infra] elements vs. openstack-infra puppet for	CI\n \"infra\" nodes','I originally sent this to TripleO but perhaps [infra] would have been a better choice.\n\nThe short version is I\'d like to run a lightweight (unofficial) mirror for Fedora in infra:\n\n https://review.openstack.org/#/c/90875/\n\nAnd then in the TripleO CI racks we can run local Squid caches using something like this:\n\n https://review.openstack.org/#/c/91161/\n\nWe have to do something because we see quite a bit of job failures related to unstable mirrors. If using local Squid caches doesn\'t work out then perhaps we will have to run local mirrors in each TripleO CI rack but I would like to avoid that if possible as it is more resource heavy. Especially because we\'ll need to do the same things in each rack for Fedora and Ubuntu (both of which run in each TripleO CI test rack).\n\nDan\n\n----- Forwarded Message -----\nFrom: \"Dan Prince\" <dprince at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, April 29, 2014 4:10:30 PM\nSubject: [openstack-dev] [TripleO] elements vs. openstack-infra puppet for	CI \"infra\" nodes\n\nA bit of background TripleO CI background:\n\n At this point we\'ve got two public CI overcloud which we can use to run TripleO check jobs for CI. Things are evolving nicely and we\'ve recently been putting some effort into making things run faster by adding local distro and Pypi mirrors. Etc. This is good in that it should help us improve both the stability of test results and runtimes.\n\n----\n\nThis brings up the question of how we are going to manage our TripleO overcloud CI resources for things like: distro mirrors, caches, test environment brokers, etc\n\n1) Do we use and or create openstack-infra/config modules for everything we need and manage it via the normal OpenStack infrastructure way using Puppet etc.?\n\n2) Or, do we take the TripleO oriented approach and use image elements and Heat templates to manage things?\n\nWhich of these two options do we prefer given that we eventually want TripleO to be gating? And who is responsible for maintaining them (TripleO CD Admins or OpenStack Infra)?\n\n----\n\nIf it helps to narrow the focus of this thread I do want to stress I\'m only really talking about the public CI (overcloud) resources. What happens underneath this layer is already managed via TripleO tooling itself.\n\nRegardless of what we use I\'d like to be able to maintain feature parity with regards to setting up these CI cloud resources across providers (HP and Red Hat at this point). As is I fear we\'ve got a growing list of CI infrastructure that isn\'t easily reproducible across the racks.\n\nDan\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<2146331717.21284617.1398802230040.JavaMail.zimbra@redhat.com>',NULL),('<1277868241.11922.1396670084685.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-04 23:54:44',-14400,'2014-04-05 03:54:44',NULL,'[Openstack-docs] How to deal with DocImpact patches','\n----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: \"Summer Long\" <slong at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Tuesday, April 1, 2014 6:18:04 PM\n> Subject: Re: [Openstack-docs] How to deal with DocImpact patches\n> \n> On 01/04/14 07:56, Summer Long wrote:\n> > Was hoping someone would chime in with the further problem of not noting\n> > doc bugs or review for docs in the dev space.\n> > *  Could the automatic process for a DocImpact dev bug note somewhere that\n> > the doc bug has been created?\n> \n> Yes, it could post a message on the git review. This just needs a bit of\n> coding. Effectively, get jeepyb, and look at welcome_message.py - this\n> has the necessary code for posting messages on reviews. Grab that and\n> put it in notify_impact.py. Just needs someone who knows python to do\n> the work :)\n> \n> > *  For patches without \'DocImpact\', could we note somewhere that the dev\n> > bug has been reviewed for doc impact?\n> \n> I\'m a little confused by this. Can you elaborate?\n>\nFor blueprints or patches that don\'t have a doc impact. If \'no doc impact\' has been assessed\nby docs, would be good to put something on the blueprint\'s whiteboard so that it\'s not done over and over again.\n\nJust for those cases where you see a blueprint, no dev has raised a \'DocImpact\', and \nyou think \'really?\', so check it to make sure that something wasn\'t missed...\n\n\n\n','<533A763C.7080506@openstack.org>',NULL),('<1278160574.178.1368080169498.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-09 06:16:09',0,'2013-05-09 06:16:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly-centos6 #9','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/9/>\n\n------------------------------------------\n[...truncated 3914 lines...]\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 482, in test_user_get_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:55535/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 526, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:39641/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 489, in test_user_list_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:58178/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 823, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:41178/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 842, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:36403/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 496, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:41828/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 512, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:46227/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 34.98 secs:\n    7.40    TestTokenRevoking.test_group_membership_changes_revokes_token\n    7.29    KcEssex3TestCase.test_admin_requires_adminness\n    7.00    Kc11TestCase.test_admin_requires_adminness\n    6.88    KcMasterTestCase.test_admin_requires_adminness\n    6.41    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1271 tests in 462.415s\n\nFAILED (SKIP=84, errors=126)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.centos6.9\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=68\n+ \'[\' 68 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KpYw69rUEk\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/9\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/9/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<571233804.146.1367993696663.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1278892924.1372547.1391680322842.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-06 10:52:02',3600,'2014-02-06 09:52:02',NULL,'[openstack-dev] Asynchrounous programming: replace eventlet\n with asyncio','Hi,\n\nJoshua Harlow:\n> Any mysql DB drivers (I think the majority of openstack deployments use\n> mysql?).\n\nI don\'t know. Here are some asynchronous clients for MySQL:\n\nhttps://github.com/PyMySQL/PyMySQL/\nhttps://launchpad.net/myconnpy\nhttps://github.com/hybridlogic/txMySQL\nhttp://chartio.com/blog/2011/06/making-mysql-queries-asynchronous-in-tornado\nhttp://www.arpalert.org/mysac.html\nhttp://code.google.com/p/perl-mysql-async/\n\nIMO to have an efficient driver for asyncio, it should give access to the socket / file descriptor, so asyncio can watch it can execute a callback when some data can be read on the socket. A pure Python connector should fit such requirements. Or the API should use a callback when the result is available.\n\n> How about sqlalchemy (what would possibly need to change there for it to\n> work)?\n\nI found some projects using SQLAchemy asynchronously, but only with PostgreSQL.\n\n> The pain that I see is that to connect all these libraries into\n> asyncio they have to invert how they work (sqlalchemy would have to become\n> asyncio compatible (?), which probably means a big rewrite).\n\nThere is no problem to call slow blocking functions in asyncio.\n\nBut if you want to have efficient code, it\'s better to run the blocking code asynchronously. For example, use loop.run_in_executor() with a thread pool.\n\n> This is where\n> it would be great to have a \'eventlet\' like-thing built ontop of asyncio\n> (letting existing libraries work without rewrites). Eventually I guess\n> in-time (if tulip succeeds) then this \'eventlet\' like-thing could be\n> removed.\n\nIt\'s a little bit weird to design an abstraction on top of asyncio, since asyncio has be designed an an abstraction of existing event loops. But I wrote an asyncio executor for Oslo Messaging which has already such abstraction.\n\nVictor\n\n\n','<CF183ECA.5583C%harlowja@yahoo-inc.com>',NULL),('<127913276.45923827.1408460292923.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 10:58:12',-14400,'2014-08-19 14:58:12',NULL,'[openstack-dev] [NFV] New meeting time for this week - Thursday\n 1600 UTC in #openstack-meeting','Hi all,\n\nIn response to the recent survey and resulting discussion about the meeting time I would like to trial the alternative time discussed. In the short term this means alternating between:\n\n- Wednesdays at 1400 UTC in #openstack-meeting-alt (Current time)\n- Thursdays at 1600 UTC in #openstack-meeting (New time)\n\nThis week\'s meeting will be on Thursday at 1600 URC in #openstack-meeting. I have also updated the Wiki to list the schedule for the next couple of meetings:\n\n    https://wiki.openstack.org/wiki/Teams/NFV#Agenda_for_next_meeting\n\nMy suggestion is that we try this alternating pattern for a short period and then re-visit this discussion. If you have items you wish to discuss at this week\'s meeting please add them to:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nThanks,\n\nSteve\n\n\n','<2052081362.45919351.1408460166522.JavaMail.zimbra@redhat.com>',NULL),('<127956804.22287110.1370889480716.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 14:38:00',-14400,'2013-06-10 18:38:00',NULL,'[openstack-dev] Discussion of Nova Bug 1189543 (Setting drive\n error policy in Nova)','I think the idea is that a VM\'s OS might just blindly go on writing, or even stop the write and not write some important piece of data.  The idea behind pausing the VM would be that someone could hypothetically fix the error (allocate more space for the disk, etc) and resume the VM, thus not losing the data that was to be written.\n\n----- Original Message -----\nFrom: \"Robert Collins\" <robertc at robertcollins.net>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, June 10, 2013 2:17:05 PM\nSubject: Re: [openstack-dev] Discussion of Nova Bug 1189543 (Setting drive error policy in Nova)\n\nOn 11 June 2013 04:45, Solly Ross <sross at redhat.com> wrote:\n> (https://bugs.launchpad.net/nova/+bug/1189543)\n>\n> It was proposed at RedHat (https://bugzilla.redhat.com/show_bug.cgi?id=865336) that we should explicitly set Libvirt to stop VMs on drive read/write errors, and then detect that and somehow set a piece of state in nova.\n\nIt\'s not obvious to me why you\'d stop the VM : that will cause\nauto-scaling systems to detect it as down, detach the volume and spin\nit up elsewhere, but if the fault is in the volume, the new instance\nwill just pause and on it goes.\n\nI/O errors are a known part of the machine model: what is the data\nloss that that bug talks about if the VM isn\'t paused?\n\n-Rob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Cloud Services\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJ3HoZ0sfV_G6aEynTstNM17-AU4K+nZ3Vwv++CMdkNYJULG4A@mail.gmail.com>',NULL),('<1280024451.19.1380694189241.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-02 06:09:49',0,'2013-10-02 06:09:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #29','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/29/>\n\n------------------------------------------\n[...truncated 949 lines...]\n    test_add_host_variations                                     OK    0.02\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.00\n    test_merge_conflicting_but_identical_properties              OK    0.00\n    test_merge_conflicting_properties                            OK    0.00\n    test_merge_properties                                        OK    0.00\n    test_raw_json_schema                                         OK    0.00\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.00\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.00\n    test_generate_uuid_unique                                    OK    0.00\n    test_is_uuid_like_fails                                      OK    0.00\n    test_is_uuid_like_success                                    OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: We test that the \'--respawn\' option doesn\'t cause bouncing\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 187, in test_bouncing\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \'Unexpected server launch status\' = self._formatMessage(\'Unexpected server launch status\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'Unexpected server launch status\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 62.21 secs:\n    13.38    TestScrubber.test_delayed_delete\n    13.26    TestGlanceControl.test_reload\n    13.07    TestGlanceControl.test_respawn\n    12.18    TestApi.test_unsupported_default_store\n    10.31    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 926 tests in 425.099s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-29\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.7.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Z6j1FwJFaq\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/29/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise36/29\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1280499000.23.1385359534861.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-25 06:05:34',0,'2013-11-25 06:05:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #71','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/71/>\n\n------------------------------------------\n[...truncated 7124 lines...]\n2013-11-25 06:05:15 + ini_has_option /etc/cinder/cinder.conf DEFAULT secure_delete\n2013-11-25 06:05:15 + local file=/etc/cinder/cinder.conf\n2013-11-25 06:05:15 + local section=DEFAULT\n2013-11-25 06:05:15 + local option=secure_delete\n2013-11-25 06:05:15 + local line\n2013-11-25 06:05:15 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-25 06:05:15 + line=\n2013-11-25 06:05:15 + \'[\' -n \'\' \']\'\n2013-11-25 06:05:15 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-25 06:05:15 secure_delete = False\n2013-11-25 06:05:15 \' /etc/cinder/cinder.conf\n2013-11-25 06:05:15 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-11-25 06:05:15 + local file=/etc/cinder/cinder.conf\n2013-11-25 06:05:15 + local section=DEFAULT\n2013-11-25 06:05:15 + local option=volume_clear\n2013-11-25 06:05:15 + local value=none\n2013-11-25 06:05:15 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-11-25 06:05:15 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-11-25 06:05:15 + local file=/etc/cinder/cinder.conf\n2013-11-25 06:05:15 + local section=DEFAULT\n2013-11-25 06:05:15 + local option=volume_clear\n2013-11-25 06:05:15 + local line\n2013-11-25 06:05:15 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-25 06:05:15 + line=\n2013-11-25 06:05:15 + \'[\' -n \'\' \']\'\n2013-11-25 06:05:15 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-25 06:05:15 volume_clear = none\n2013-11-25 06:05:15 \' /etc/cinder/cinder.conf\n2013-11-25 06:05:15 + \'[\' False == True \']\'\n2013-11-25 06:05:15 + \'[\' default == XenAPINFS \']\'\n2013-11-25 06:05:15 + \'[\' default == sheepdog \']\'\n2013-11-25 06:05:15 + is_service_enabled quantum\n2013-11-25 06:05:15 + services=quantum\n2013-11-25 06:05:15 + for service in \'${services}\'\n2013-11-25 06:05:15 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-11-25 06:05:15 + return 0\n2013-11-25 06:05:15 + install_quantum\n2013-11-25 06:05:15 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-11-25 06:05:15 + [[ False = \\T\\r\\u\\e ]]\n2013-11-25 06:05:15 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-11-25 06:05:15 + GIT_DEST=/opt/stack/new/neutron\n2013-11-25 06:05:15 + GIT_REF=stable/grizzly\n2013-11-25 06:05:15 + echo stable/grizzly\n2013-11-25 06:05:15 + egrep -q \'^refs\'\n2013-11-25 06:05:15 + [[ ! -d /opt/stack/new/neutron ]]\n2013-11-25 06:05:15 + [[ \'\' == \\y\\e\\s ]]\n2013-11-25 06:05:15 + setup_develop /opt/stack/new/neutron\n2013-11-25 06:05:15 + [[ False = True ]]\n2013-11-25 06:05:15 + SUDO_CMD=sudo\n2013-11-25 06:05:15 + cd /opt/stack/new/neutron\n2013-11-25 06:05:15 + python setup.py egg_info\n2013-11-25 06:05:15 running egg_info\n2013-11-25 06:05:15 creating quantum.egg-info\n2013-11-25 06:05:15 writing requirements to quantum.egg-info/requires.txt\n2013-11-25 06:05:15 writing quantum.egg-info/PKG-INFO\n2013-11-25 06:05:15 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-25 06:05:15 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-25 06:05:15 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-25 06:05:15 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-25 06:05:15 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-25 06:05:15 reading manifest template \'MANIFEST.in\'\n2013-11-25 06:05:15 warning: no files found matching \'AUTHORS\'\n2013-11-25 06:05:15 warning: no files found matching \'ChangeLog\'\n2013-11-25 06:05:15 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-25 06:05:16 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-25 06:05:16 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-25 06:05:16 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-25 06:05:16 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-11-25 06:05:16 + raw_links=\n2013-11-25 06:05:16 ++ echo\n2013-11-25 06:05:16 ++ xargs\n2013-11-25 06:05:16 + depend_links=\n2013-11-25 06:05:16 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-11-25 06:05:16 ++ echo \'-r *-info/requires.txt\'\n2013-11-25 06:05:16 + require_file=\'-r *-info/requires.txt\'\n2013-11-25 06:05:16 + pip_install -r quantum.egg-info/requires.txt\n2013-11-25 06:05:16 + [[ False = \\T\\r\\u\\e ]]\n2013-11-25 06:05:16 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-11-25 06:05:16 + [[ -z deb ]]\n2013-11-25 06:05:16 + [[ False = True ]]\n2013-11-25 06:05:16 + SUDO_PIP=sudo\n2013-11-25 06:05:16 ++ get_pip_command\n2013-11-25 06:05:16 ++ is_fedora\n2013-11-25 06:05:16 ++ [[ -z Ubuntu ]]\n2013-11-25 06:05:16 ++ \'[\' Ubuntu = Fedora \']\'\n2013-11-25 06:05:16 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-11-25 06:05:16 ++ \'[\' Ubuntu = CentOS \']\'\n2013-11-25 06:05:16 ++ which pip\n2013-11-25 06:05:16 + CMD_PIP=/usr/local/bin/pip\n2013-11-25 06:05:16 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-11-25 06:05:16 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-11-25 06:05:16 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:16   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-11-25 06:05:16   Running setup.py egg_info for package python-quantumclient\n2013-11-25 06:05:16     [pbr] Processing SOURCES.txt\n2013-11-25 06:05:16     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-11-25 06:05:16     \n2013-11-25 06:05:16     [pbr] In git context, generating filelist from git\n2013-11-25 06:05:16     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-11-25 06:05:16 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:16 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-11-25 06:05:18   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.0.tar.gz\n2013-11-25 06:05:18   Running setup.py egg_info for package alembic\n2013-11-25 06:05:18     \n2013-11-25 06:05:18     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-25 06:05:18     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-25 06:05:18     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-25 06:05:18     no previously-included directories found matching \'docs/build/output\'\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-25 06:05:18   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-11-25 06:05:18   Running setup.py egg_info for package Mako\n2013-11-25 06:05:18     \n2013-11-25 06:05:18     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-25 06:05:18     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-25 06:05:18     warning: no files found matching \'ez_setup.py\'\n2013-11-25 06:05:18     no previously-included directories found matching \'doc/build/output\'\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:18 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-25 06:05:19 Installing collected packages: python-quantumclient, alembic, Mako\n2013-11-25 06:05:19   Running setup.py install for python-quantumclient\n2013-11-25 06:05:19     [pbr] Reusing existing SOURCES.txt\n2013-11-25 06:05:19     Installing quantum script to /usr/local/bin\n2013-11-25 06:05:19   Running setup.py install for alembic\n2013-11-25 06:05:19     \n2013-11-25 06:05:19     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-25 06:05:19     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-25 06:05:19     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-25 06:05:19     no previously-included directories found matching \'docs/build/output\'\n2013-11-25 06:05:19     Installing alembic script to /usr/local/bin\n2013-11-25 06:05:19   Running setup.py install for Mako\n2013-11-25 06:05:19     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-11-25 06:05:19     \n2013-11-25 06:05:19     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-25 06:05:19     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-25 06:05:19     warning: no files found matching \'ez_setup.py\'\n2013-11-25 06:05:19     no previously-included directories found matching \'doc/build/output\'\n2013-11-25 06:05:19     changing mode of /usr/local/bin/mako-render to 755\n2013-11-25 06:05:19 Successfully installed python-quantumclient alembic Mako\n2013-11-25 06:05:19 Cleaning up...\n2013-11-25 06:05:19 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-11-25 06:05:19 running develop\n2013-11-25 06:05:19 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-11-25 06:05:19 /usr/bin/python -E -c pass\n2013-11-25 06:05:19 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-11-25 06:05:19 running egg_info\n2013-11-25 06:05:19 writing requirements to quantum.egg-info/requires.txt\n2013-11-25 06:05:19 writing quantum.egg-info/PKG-INFO\n2013-11-25 06:05:19 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-25 06:05:19 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-25 06:05:19 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-25 06:05:19 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-25 06:05:19 reading manifest template \'MANIFEST.in\'\n2013-11-25 06:05:19 warning: no files found matching \'AUTHORS\'\n2013-11-25 06:05:19 warning: no files found matching \'ChangeLog\'\n2013-11-25 06:05:19 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-25 06:05:19 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-25 06:05:19 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-25 06:05:19 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-25 06:05:19 running build_ext\n2013-11-25 06:05:19 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-11-25 06:05:19 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-11-25 06:05:19 Installing quantum-debug script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-nec-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-ryu-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-l3-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-db-manage script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-metadata-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-server script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-11-25 06:05:19 Installing quantum-rootwrap script to /usr/local/bin\n2013-11-25 06:05:19 \n2013-11-25 06:05:19 Installed /opt/stack/new/neutron\n2013-11-25 06:05:19 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-11-25 06:05:19 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-11-25 06:05:19 ++ failed\n2013-11-25 06:05:19 ++ local r=1\n2013-11-25 06:05:19 +++ jobs -p\n2013-11-25 06:05:19 ++ kill\n2013-11-25 06:05:19 ++ set +o xtrace\n2013-11-25 06:05:19 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-11-25-060148\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-730820-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-730820.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-730820/71/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<924717316.21.1385273088929.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1280978078.30.1387087494959.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:04:54',0,'2013-12-15 06:04:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-ceilometer-docs-grizzly #9','See <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/9/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise4 in workspace <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/>\nCheckout:periodic-ceilometer-docs-grizzly / <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/> - hudson.remoting.Channel at 73035b47:precise4\nUsing strategy: Default\nLast Built Revision: Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/ceilometer\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/ceilometer\nCommencing build of Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\nChecking out Revision a3a187ec18ab15b493311d4e83bafe3e75e22fd4 (origin/stable/grizzly)\n[periodic-ceilometer-docs-grizzly] $ /bin/bash -xe /tmp/hudson7479099209213415710.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack ceilometer\n+ org=openstack\n+ project=ceilometer\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack ceilometer /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=ceilometer\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack ceilometer\n++ org=openstack\n++ project=ceilometer\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack ceilometer /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=ceilometer\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z ceilometer ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/ceilometer /opt/requirements/projects.txt\nopenstack/ceilometer\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/tools/test-requires,> -r<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/tools/pip-requires,> sphinxcontrib-httpdomain\nvenv inst: <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/dist/ceilometer-jenkins.periodic.ceilometer.docs.grizzly.9.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/>\nGenerating doc/source/api/ceilometer.agent.rst\nGenerating doc/source/api/ceilometer.api.acl.rst\nGenerating doc/source/api/ceilometer.api.app.rst\nGenerating doc/source/api/ceilometer.api.config.rst\nGenerating doc/source/api/ceilometer.api.controllers.root.rst\nGenerating doc/source/api/ceilometer.api.controllers.v2.rst\nGenerating doc/source/api/ceilometer.api.hooks.rst\nGenerating doc/source/api/ceilometer.api.middleware.rst\nGenerating doc/source/api/ceilometer.api.v1.acl.rst\nGenerating doc/source/api/ceilometer.api.v1.app.rst\nGenerating doc/source/api/ceilometer.api.v1.blueprint.rst\nGenerating doc/source/api/ceilometer.central.manager.rst\nGenerating doc/source/api/ceilometer.central.plugin.rst\nGenerating doc/source/api/ceilometer.collector.meter.rst\nGenerating doc/source/api/ceilometer.collector.service.rst\nGenerating doc/source/api/ceilometer.compute.instance.rst\nGenerating doc/source/api/ceilometer.compute.manager.rst\nGenerating doc/source/api/ceilometer.compute.notifications.rst\nGenerating doc/source/api/ceilometer.compute.nova_notifier.folsom.rst\nGenerating doc/source/api/ceilometer.compute.nova_notifier.grizzly.rst\nGenerating doc/source/api/ceilometer.compute.plugin.rst\nGenerating doc/source/api/ceilometer.compute.pollsters.rst\nGenerating doc/source/api/ceilometer.compute.virt.inspector.rst\nGenerating doc/source/api/ceilometer.compute.virt.libvirt.inspector.rst\nGenerating doc/source/api/ceilometer.counter.rst\nGenerating doc/source/api/ceilometer.energy.kwapi.rst\nGenerating doc/source/api/ceilometer.extension_manager.rst\nGenerating doc/source/api/ceilometer.image.glance.rst\nGenerating doc/source/api/ceilometer.image.notifications.rst\nGenerating doc/source/api/ceilometer.network.floatingip.rst\nGenerating doc/source/api/ceilometer.network.notifications.rst\nGenerating doc/source/api/ceilometer.nova_client.rst\nGenerating doc/source/api/ceilometer.objectstore.swift.rst\nGenerating doc/source/api/ceilometer.objectstore.swift_middleware.rst\nGenerating doc/source/api/ceilometer.openstack.common.context.rst\nGenerating doc/source/api/ceilometer.openstack.common.eventlet_backdoor.rst\nGenerating doc/source/api/ceilometer.openstack.common.excutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.gettextutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.importutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.jsonutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.local.rst\nGenerating doc/source/api/ceilometer.openstack.common.log.rst\nGenerating doc/source/api/ceilometer.openstack.common.loopingcall.rst\nGenerating doc/source/api/ceilometer.openstack.common.network_utils.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.api.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.list_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/ceilometer.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/ceilometer.openstack.common.policy.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.common.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.matchmaker_redis.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/ceilometer.openstack.common.rpc.service.rst\nGenerating doc/source/api/ceilometer.openstack.common.service.rst\nGenerating doc/source/api/ceilometer.openstack.common.setup.rst\nGenerating doc/source/api/ceilometer.openstack.common.threadgroup.rst\nGenerating doc/source/api/ceilometer.openstack.common.timeutils.rst\nGenerating doc/source/api/ceilometer.openstack.common.version.rst\nGenerating doc/source/api/ceilometer.pipeline.rst\nGenerating doc/source/api/ceilometer.plugin.rst\nGenerating doc/source/api/ceilometer.policy.rst\nGenerating doc/source/api/ceilometer.publisher.meter_publish.rst\nGenerating doc/source/api/ceilometer.service.rst\nGenerating doc/source/api/ceilometer.storage.base.rst\nGenerating doc/source/api/ceilometer.storage.impl_hbase.rst\nGenerating doc/source/api/ceilometer.storage.impl_log.rst\nGenerating doc/source/api/ceilometer.storage.impl_mongodb.rst\nGenerating doc/source/api/ceilometer.storage.impl_sqlalchemy.rst\nGenerating doc/source/api/ceilometer.storage.impl_test.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.001_add_meter_table.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.002_remove_duration.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.003_set_utf8_charset.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.004_add_counter_unit.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.005_remove_resource_timestamp.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migrate_repo.versions.006_counter_volume_is_float.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.migration.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.models.rst\nGenerating doc/source/api/ceilometer.storage.sqlalchemy.session.rst\nGenerating doc/source/api/ceilometer.tests.api.rst\nGenerating doc/source/api/ceilometer.tests.base.rst\nGenerating doc/source/api/ceilometer.tests.db.rst\nGenerating doc/source/api/ceilometer.tests.skip.rst\nGenerating doc/source/api/ceilometer.transformer.accumulator.rst\nGenerating doc/source/api/ceilometer.utils.rst\nGenerating doc/source/api/ceilometer.volume.notifications.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-docs-grizzly/precise4/9\n[SCP] Copying console log.\n\n\n','<108062365.4.1386915351348.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<12810B7F-B106-43AD-B0F1-9973776D7F55@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-17 15:06:41',39600,'2013-10-17 04:06:41',NULL,'[Openstack] six dependencies for nova and keystone client','It looks like there is an issue with six with havana nova (milestone-proposed).\n\nNova has: \nsix<1.4.0\npython-keystoneclient>=0.3.2\n\nLatest keystoneclient (0.4.1) has:\n\nsix>=1.4.1\n\nDoes nova need to require an older version of keystoneclient? Downgrading to 0.3.2 will fix it.\n\nCheers,\nSam\n\n\n\n\n',NULL,NULL),('<1282095512.22995368.1384384442414.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 18:14:02',-18000,'2013-11-13 23:14:02',NULL,'[openstack-dev] [Solum] Create a source repo for the API\n specification?','----- Original Message -----\n> \n> \n> \n> On Sat, Nov 2, 2013 at 4:55 PM, Christopher Armstrong <\n> chris.armstrong at rackspace.com > wrote:\n> \n> \n> \n> On Sat, Nov 2, 2013 at 4:39 PM, Jay Pipes < jaypipes at gmail.com > wrote:\n> \n> \n> Hi all,\n> \n> One of the most important aspects in the early stages of Solum development\n> will be the consensus building and stabilization of the Solum API\n> specification. A solid API spec aid in the speeding up the pace of\n> innovation in the Solum contributor community.\n> \n> One of the aspects of the Keystone development process that I think is a big\n> benefit is the separate source repository that stores the OpenStack Identity\n> API specifications:\n> \n> https://github.com/openstack/ identity-api\n> \n> When new versions of the API specification are debated or new extensions are\n> proposed, patches are made to the specification markdown documents and\n> reviewed in the exact same manner that regular code is on the\n> https://review.openstack.org Gerrit site. Contributors are free to annotate\n> the proposed changes to the API specification in the same way that they\n> would make inline code comments on a regular code review. Here\'s an example\n> for a proposed change that I recently made:\n> \n> https://review.openstack.org/# /c/54215/10\n> \n> I\'d like to propose that Solum do the same: have a separate source repository\n> for the API specification.\n> \n> Thoughts?\n> -jay\n> \n> \n> I like this idea. I\'d also propose that the format of the specification be\n> something machine-readable, such as API-Blueprint (a simple subset of\n> markdown, apiblueprint.org , also what apiary uses, if you\'ve ever seen\n> that) or RAML (a more structured YAML-based syntax, raml.org ).\n> API-Blueprint is closer to what the keystone document uses.\n> \n> Making the documentation machine-readable means that it\'s much easier to\n> verify that, in practice, the implementation of an API matches its\n> specification and documentation, which is a problem that plagues many\n> OpenStack projects right now.\n> \n> \n> Hi all,\n> I wouldn\'t expect you to know this unless you read minds, but we had a Summit\n> session last week and a long email thread with all the PTLs prior to the\n> Summit, and we decided to move all API specs into the repositories of the\n> project itself, and stop maintaining separate \"spec\" repos.\n> \n> The Etherpad is here:\n> \n> https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads\n> \n> We are working on a document to describe how to document your API both for\n> future end-users and for current devs wanting to write to the specified\n> needs of the API. Stay tuned to all the bat channels for that.\n> \n> Happy to discuss further, but after 2 years, it\'s time to make some changes,\n> and we worked hard to build consensus for the 10+ APIs we have in OpenStack.\n> \n> Thanks,\n> Anne\n> \n\nWhile waiting for that to manifest, pandoc can do a reasonably good mediawiki -> markdown conversion.  Here\'s an example of the current API doc transliterated: https://gist.github.com/smarterclayton/7458182.\n\nWe can either check in a md format (for easy GitHub viewing) version into solum/ and iterate on that via code review, or hold off and iterate on the wiki page as it stands today.\n\n\n','<CAD0KtVEG-PivDJG4H-C3NqwgZqvG7fz8yestut_fmNUt0EC8mw@mail.gmail.com>',NULL),('<1282910710.2652966.1399486211779.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 14:10:11',-14400,'2014-05-07 18:10:11',NULL,'[openstack-dev] [Nova] [Heat] Custom Nova Flavor creation\n through Heat (pt.2)','(response inline)\n\n----- Original Message -----\n> From: \"Zane Bitter\" <zbitter at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Tuesday, May 6, 2014 9:09:09 PM\n> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)\n> \n> On 05/05/14 13:40, Solly Ross wrote:\n> > One thing that I was discussing with @jaypipes and @dansmith over\n> > on IRC was the possibility of breaking flavors down into separate\n> > components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.\n> > This way, you still get the control of the size of your building blocks\n> > (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid\n> > exponential flavor explosion by separating out the axes.\n> \n> Dimitry and I have discussed this on IRC already (no-one changed their\n> mind about anything as a result), but I just wanted to note here that I\n> think even this idea is crazy.\n> \n> VMs are not allocated out of a vast global pool of resources. They\'re\n> allocated on actual machines that have physical hardware costing real\n> money in fixed ratios.\n> \n> Here\'s a (very contrived) example. Say your standard compute node can\n> support 16 VCPUs and 64GB of RAM. You can sell a bunch of flavours:\n> maybe 1 VCPU + 4GB, 2 VCPU + 8GB, 4 VCPU + 16GB... &c. But if (as an\n> extreme example) you sell a server with 1 VCPU and 64GB of RAM you have\n> a big problem: 15 VCPUs that nobody has paid for and you can\'t sell.\n> (Disks add a new dimension of wrongness to the problem.)\n\nSo the simple solution is to not allow a VM that uses all of the RAM\non a given host (just don\'t have a RAM flavor that size), and then schedule\nthe VM on a host that has minimal RAM usage but high CPU usage.  This is\nespecially true for disk, where you may have situations where you don\'t\ncare if an otherwise large VM uses no disk (disks on network stores, etc).\n\n> The insight of flavours, which is fundamental to the whole concept of\n> IaaS, is that users must pay the *opportunity cost* of their resource\n> usage. If you allow users to opt, at their own convenience, to pay only\n> the actual cost of the resources they use regardless of the opportunity\n> cost to you, then your incentives are no longer aligned with your\n> customers. You\'ll initially be very popular with the kind of customers\n> who are taking advantage of you, but you\'ll have to hike prices across\n> the board to make up the cost leading to a sort of dead-sea effect. A\n> Gresham\'s Law of the cloud, if you will, where bad customers drive out\n> good customers.\n> \n> Simply put, a cloud allowing users to define their own flavours *loses*\n> to one with predefined flavours 10 times out of 10.\n\nNote that this proposal wouldn\'t prevent flavors from being used -- you\ncould still have \"flavor bundles\" (or something of the sort) that would\nact the way current flavors do.\n\n> In the above example, you just tell the customer: bad luck, you want\n> 64GB of RAM, you buy 16 VCPUs whether you want them or not. It can\'t\n> actually hurt to get _more_ than you wanted, even though you\'d rather\n> not pay for it (provided, of course, that everyone else *is* paying for\n> it, and cross-subsidising you... which they won\'t).\n\nAgain, what if you also have a user who needs lots of CPUs, but a relatively\nsmall amount of RAM or disk?\n\n> Now, it\'s not the OpenStack project\'s job to prevent operators from\n> going bankrupt. But I think at the point where we are adding significant\n> complexity to the project just to enable people to confirm the\n> effectiveness of a very obviously infallible strategy for losing large\n> amounts of money, it\'s time to draw a line.\n> \n> \n> By the way, the whole theory behind this idea seems to be that this:\n> \n>    nova server-create --cpu-flavor=4 --ram-flavour=16G --disk-flavor=200G\n> \n> minimises the cognitive load on the user, whereas this:\n> \n>    nova server-create --flavor=4-64G-200G\n\nBut, flavors aren\'t (and shouldn\'t be) named \"16G\".  Realistically, it would\nlook more like\n\n   nova create --cpu-flavor=large --ram-flavor=medium --disk-flavor=small\n\nfor many clouds.  Additionally, keep in mind that not everyone uses the command\nline.  Developers often forget that many users will want to use horizon, and\nselecting 4-64G-200G (or even large-medium-large) from a long list can be very\nannoying (suppose we have 6 RAM flavors and 6 disk flavors -- that\'s 36 flavors\nthat start with \"4-\").\n\n> \n> will cause the user\'s brain to explode from its combinatorial\n> complexity. I find this theory absurd.\n> \n> In other words, if you really want to lose some money, it\'s perfectly\n> feasible with the existing flavour implementation. The operator is only\n> ever 3 for-loops away from setting up every combination of flavours\n> possible from combining the CPU, RAM and disk options, and can even\n> apply whatever constraints they desire.\n> \n> \n> All that said, Heat will expose any API that Nova implements. Choose wisely.\n> \n> cheers,\n> Zane.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<536987B5.2040004@redhat.com>',NULL),('<1283157929.70.1383545675614.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:14:35',0,'2013-11-04 06:14:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #41','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/41/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/registry/client.py\",> line 89, in do_request\n    action, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x553d290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x553d290>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4fe2dd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4fe2dd0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-4f58ddbf-6d00-40ce-b80a-3a8c807c2457\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:14:03Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'03\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:14:03Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'03\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:14:03+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'03\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:14:03-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'03\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:14:03Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'03\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e8bc90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2010d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 79.41 secs:\n    16.85    TestGlanceControl.test_bouncing\n    16.31    TestScrubber.test_delayed_delete\n    15.64    TestRootApi.test_version_configurations\n    15.41    TestBinGlanceCacheManage.test_queue\n    15.21    TestBinGlance.test_results_filtering\n----------------------------------------------------------------------\nRan 932 tests in 700.999s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-41\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.2bDXHbstxW\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/41/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise9/41\n[SCP] Copying console log.\n\n\n','<1380738508.57.1383459072939.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1283264922.45.1383372880136.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:14:40',0,'2013-11-02 06:14:40',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-keystone-python26-stable-grizzly #57','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/57/>\n\n\n\n',NULL,NULL),('<128353567.7547328.1374863792915.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-26 14:36:32',-14400,'2013-07-26 18:36:32',NULL,'[Openstack-docs] Intro and example installations','----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Friday, July 26, 2013 1:26:01 PM\n> Subject: Re: [Openstack-docs] Intro and example installations\n> \n> On 19/07/13 13:22, Anne Gentle wrote:\n> >     2) Isn\'t nova-network slated to be deprecated in Havana (\n> >     https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network )?\n> > \n> > \n> > Yes but neutron is not yet an acceptable replacement, nor do we know if\n> > it will be in Havana. So my guess is that the work to deprecate\n> > nova-network will be delayed again. I don\'t know this for certain,\n> > though, so the safest thing for docs to do is to have the\n> > easiest/simplest still use nova-networks. Happy to\n> > hear dissension around this point but with lack of HA in L3 plus major\n> > complexity of SDN I just don\'t think it\'s right to use neutron for the\n> > simplest install.\n> \n> Nova-network was slated to be deprecated in Havana, but this has change\n> and will now happen in Ice House, with potential removal in J release.\n> Therefore, I personally still consider it a very valid option for an\n> architecture :)\n\nMy suggestion is not that nova-network isn\'t a valid option but my main concerns/feelings are that:\n\n1) We have the opportunity here to steer new deployers past what is still looking like a fairly involved migration path when nova-network actually is removed (regardless of timing).\n\n2) Software Defined Networking is by its nature a conceptually different way of thinking about networking in the data center. As such while the implementation of it in OpenStack (neutron) will likely get somewhat friendlier (and various issues like HA of the L3 agent will be addressed*) as it is bedded down I don\'t think that central element of conceptual complexity that will eventually need to explained is necessarily going away.\n\n3) Somewhat related to (1) bolting neutron on as a choose your own adventure component is possibly going to be more difficult than installing it in the first place ;).\n\nJust my 2c.\n\nThanks,\n\nSteve\n\n* https://blueprints.launchpad.net/neutron/+spec/quantum-multihost\n\n\n','<51F2B129.1030608@openstack.org>',NULL),('<1283591334.130.1356221149247.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-23 00:05:49',0,'2012-12-23 00:05:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #83','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/83/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/83\n[SCP] Copying console log.\n\n\n','<1289202050.107.1356134712962.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1283643701.35.1369463777151.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-25 06:36:17',0,'2013-05-25 06:36:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #45','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/45/changes>\n\nChanges:\n\n[Gary Kotton] Enable quantum-netns-cleanup to receive force as cli parameter\n\n------------------------------------------\n[...truncated 5004 lines...]\n    test_device_exists                                           OK    0.00\nTestIPCommandBase\n    test_as_root                                                 OK    0.00\n    test_as_root_with_options                                    OK    0.00\n    test_run                                                     OK    0.00\n    test_run_with_options                                        OK    0.00\nTestIPDevice\n    test_eq_diff_name                                            OK    0.00\n    test_eq_diff_namespace                                       OK    0.00\n    test_eq_other_is_none                                        OK    0.00\n    test_eq_same_name                                            OK    0.00\n    test_eq_same_namespace                                       OK    0.00\n    test_str                                                     OK    0.00\nTestIPDeviceCommandBase\n    test_name_property                                           OK    0.00\nTestIpAddrCommand\n    test_add_address                                             OK    0.00\n    test_add_address_scoped                                      OK    0.00\n    test_del_address                                             OK    0.00\n    test_flush                                                   OK    0.00\n    test_list                                                    OK    0.00\n    test_list_filtered                                           OK    0.00\nTestIpLinkCommand\n    test_address_property                                        OK    0.00\n    test_alias_property                                          OK    0.00\n    test_delete                                                  OK    0.00\n    test_mtu_property                                            OK    0.00\n    test_qdisc_property                                          OK    0.00\n    test_qlen_property                                           OK    0.00\n    test_set_address                                             OK    0.00\n    test_set_alias                                               OK    0.00\n    test_set_down                                                OK    0.00\n    test_set_mtu                                                 OK    0.00\n    test_set_name                                                OK    0.00\n    test_set_netns                                               OK    0.00\n    test_set_up                                                  OK    0.01\n    test_settings_property                                       OK    0.00\n    test_state_property                                          OK    0.00\nTestIpNetnsCommand\n    test_add_namespace                                           OK    0.00\n    test_delete_namespace                                        OK    0.00\n    test_execute                                                 OK    0.00\n    test_execute_env_var_prepend                                 OK    0.00\n    test_namespace_doest_not_exist                               OK    0.00\n    test_namespace_exists                                        OK    0.00\nTestIpRouteCommand\n    test_add_gateway                                             OK    0.00\n    test_del_gateway                                             OK    0.00\n    test_get_gateway                                             OK    0.00\n    test_pullup_route                                            OK    0.00\n    test_pullup_route_first                                      OK    0.00\nTestIpWrapper\n    test_add_device_to_namespace                                 OK    0.00\n    test_add_device_to_namespace_is_none                         OK    0.00\n    test_add_tuntap                                              OK    0.00\n    test_add_veth                                                OK    0.00\n    test_add_veth_with_namespaces                                OK    0.00\n    test_ensure_namespace                                        OK    0.01\n    test_ensure_namespace_existing                               OK    0.01\n    test_garbage_collect_namespace_does_not_exist                OK    0.00\n    test_garbage_collect_namespace_existing_empty_ns             OK    0.01\n    test_garbage_collect_namespace_existing_not_empty            OK    0.00\n    test_get_device                                              OK    0.00\n    test_get_devices                                             OK    0.00\n    test_get_devices_malformed_line                              OK    0.00\n    test_get_namespaces                                          OK    0.00\n    test_namespace_is_empty                                      OK    0.00\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    2.21\n    test_delete_pool_health_monitor                              OK    0.05\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.07\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.07\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    2.30\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.01\n    test_get_instance_id_network_id_no_match                     OK    0.01\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.01\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.01\n    test_init_with_client                                        OK    0.01\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.01\n    test_init_exists                                             OK    0.01\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.01\n    test_main                                                    OK    2.29\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.00\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.00\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.04\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.32\n    test_quotas_default_values                                   OK    0.30\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.31\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    2.56\n    test_quotas_default_values                                   OK    0.21\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_without_admin_forbidden                     OK    0.22\n    test_update_quotas_forbidden                                 OK    0.30\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.31\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.31\n    test_list_quotas_with_admin                                  OK    2.68\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.22\n    test_quotas_limit_check                                      OK    0.23\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.22\n    test_quotas_limit_check_with_over_quota                      OK    0.25\n    test_quotas_loaded_bad_returns_404                           OK    2.75\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.23\n    test_show_quotas_with_owner_tenant                           OK    0.22\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.22\n    test_update_attributes                                       OK    0.24\n    test_update_quotas_with_admin                                OK    0.23\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    2.62\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.20\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.20\n    test_delete_quotas_without_admin_forbidden_returns_403       Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.cB7iBV2Ll3\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/45\n[SCP] Copying console log.\n\n\n','<1776855808.33.1369377375549.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1284497480.25149614.1352732434705.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-12 10:00:34',-18000,'2012-11-12 15:00:34',NULL,'[openstack-qa] Tempest Boto S3/EC2 tests','Hi Jay,\n\nCan you add some environment variables for configuration creation in order to get working the https://review.openstack.org/#/c/14689/ ?\nBased on the bash debug output I see in the jenkins logs I created small script. Probably the parts of the attached scripts can be merged or at least can help.\n\nThe expected output when it has the s3-materailas:\nEC2 run, stop and terminate instance ... ok\nEC2 run, terminate immediately ... ok\nEC2 create KeyPair ... ok\nEC2 delete KeyPair ... SKIP: Skipped until the Bug #1072318 is resolved\nEC2 duplicate KeyPair ... SKIP: Skipped until the Bug #1072762 is resolved\nEC2 get KeyPair ... ok\nEC2 Create, get, delete Volume ... SKIP: Skipped until the Bug #1074901 is resolved\nS3 Create, get and delete bucket ... SKIP: Skipped until the Bug #1076965 is resolved\nRegister and deregister aki image ... SKIP: Skipped until the Bug #1074904 is resolved\nRegister and deregister ami image ... ok\nRegister and deregister ari image ... SKIP: Skipped until the Bug #1074908 and #1074904 is resolved\nS3 Create, get and delete object ... SKIP: Skipped until the Bug #1076534 is resolved\n\n\nBest Regards,\nAttila \n\n----- Original Message -----\nFrom: \"Attila Fazekas\" <afazekas at redhat.com>\nTo: \"Jay Pipes\" <jaypipes at gmail.com>\nCc: \"Yaniv Kaul\" <ykaul at redhat.com>, \"daryl walleck\" <daryl.walleck at rackspace.com>, \"Jaroslav Henner\" <jhenner at redhat.com>, openstack-qa at lists.openstack.org\nSent: Wednesday, November 7, 2012 7:06:47 PM\nSubject: Re: [openstack-qa] Tempest Boto S3/EC2 tests\n\nOK. Some projects push back patches when they are too large.\nI will submit the full patch to the refers Gerrint link.\n\n----- Original Message -----\nFrom: \"Jay Pipes\" <jaypipes at gmail.com>\nTo: \"Attila Fazekas\" <afazekas at redhat.com>\nCc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\" <ykaul at redhat.com>, \"daryl walleck\" <daryl.walleck at rackspace.com>, openstack-qa at lists.openstack.org\nSent: Wednesday, November 7, 2012 6:19:37 PM\nSubject: Re: Tempest Boto S3/EC2 tests\n\nYou won\'t be sending anything... you just need to git review and your\nchanges should be pushed to Gerrit.\n\nBest,\n-jay\n\nOn 11/07/2012 12:08 PM, Attila Fazekas wrote:\n> Hi Jay,\n> \n> My patch is more than 1000 line changes, now.\n> Can I send it in one commit ? \n> \n> Regards,\n> Attila\n> \n> ----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: \"Attila Fazekas\" <afazekas at redhat.com>\n> Cc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\" <ykaul at redhat.com>, \"daryl walleck\" <daryl.walleck at rackspace.com>, openstack-qa at lists.openstack.org\n> Sent: Wednesday, November 7, 2012 4:18:21 PM\n> Subject: Re: Tempest Boto S3/EC2 tests\n> \n> On 11/07/2012 07:50 AM, Attila Fazekas wrote:\n>> Hi Jay,\n>>\n>> Is is ok if just send the full patch once?\n>> Am I need to split it first ?\n> \n> I\'m sorry Attila, I don\'t understand your question... are you asking\n> about how to push updates to your code to Gerrit?\n> \n> -jay\n> \n>> ----- Original Message -----\n>> From: \"Jay Pipes\" <jaypipes at gmail.com>\n>> To: \"Attila Fazekas\" <afazekas at redhat.com>\n>> Cc: \"Jaroslav Henner\" <jhenner at redhat.com>, \"Yaniv Kaul\" <ykaul at redhat.com>, \"daryl walleck\" <daryl.walleck at rackspace.com>, openstack-qa at lists.openstack.org\n>> Sent: Tuesday, November 6, 2012 3:48:07 PM\n>> Subject: Re: Tempest Boto S3/EC2 tests\n>>\n>> Hi again Attila,\n>>\n>> So, I\'m still having major issues running Tempest due to\n>> https://bugs.launchpad.net/tempest/+bug/1072841 which is being held up\n>> because of https://bugs.launchpad.net/glance/+bug/1074132. That latter\n>> bug is actually preventing me from even getting devstack to complete :(\n>>\n>> I will work with Brian Waldon to try and get this resolved today. Thanks\n>> for your patience.\n>>\n>> Could you please mark your review\n>> (https://review.openstack.org/#/c/14689/) back to Open status -- just\n>> click the Unabandon button.\n>>\n>> Thanks!\n>> -jay\n>>\n>> On 11/05/2012 01:36 AM, Attila Fazekas wrote:\n>>> Jay,\n>>>\n>>> I have made many modification on the previous version.\n>>> I would really appreciate a little feedback and review.\n>>>\n>>> You can see the current version of this patch here:\n>>> https://github.com/afazekas/tempest/commit/95b09c992bff9143e7808e95b2aac192ce202557\n>>>\n>>> I really need to know at least the base is acceptable, before creating more test cases.\n>>>\n>>> Regards,\n>>> Attila\n>>>\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: configure_boto.sh\nType: application/x-shellscript\nSize: 2247 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20121112/6b93a32d/attachment.bin>\n\n','<635381358.23111843.1352311607586.JavaMail.root@redhat.com>',NULL),('<1285964787.301.1356999104766.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-01 00:11:44',0,'2013-01-01 00:11:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #92','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/92/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 10.36 secs:\n    3.10    Kc11TestCase.test_admin_requires_adminness\n    2.40    KcEssex3TestCase.test_admin_requires_adminness\n    2.28    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 73.721s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==3.0.0\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.jwh1sraur1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/92\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/92/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1684659234.286.1356912491703.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1286108470.69.1365575403591.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-10 06:30:03',0,'2013-04-10 06:30:03',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #191','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/191/>\n\n------------------------------------------\n[...truncated 13820 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\nRuntimeError: maximum recursion depth exceeded\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: S3 Objectstore listening on 127.0.0.1:3333\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 34.98 secs:\n    11.74    ComputeTestCase.test_state_revert\n    7.07    CloudTestCase.test_instance_initiated_shutdown_behavior\n    6.47    ServersTest.test_create_multiple_servers\n    5.09    StorwizeSVCDriverTestCase.test_storwize_svc_flashcopy\n    4.60    ServersTest.test_create_and_rebuild_server\n----------------------------------------------------------------------\nRan 3726 tests in 939.747s\n\nFAILED (SKIP=7, errors=11)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==1.0.4\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosehtmloutput==0.0.4\nnova==2012.2.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nova/tests/nose_results.html\n+ \'[\' -f ./nova/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nova/tests/nose_results.html\n+ passcount=457\n+ \'[\' 457 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.YpU2tBHLkM\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/191\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-nova-python26-stable-folsom/191/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<546279859.53.1365489283584.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1286206424.32.1380175895060.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-26 06:11:34',0,'2013-09-26 06:11:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #25','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/25/>\n\n------------------------------------------\n[...truncated 7155 lines...]\n2013-09-26 06:11:12 warning: no files found matching \'ChangeLog\'\n2013-09-26 06:11:12 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:12 writing manifest file \'nova.egg-info/SOURCES.txt\'\n2013-09-26 06:11:12 ++ awk \'/^.+/ {print \"-f \" $1}\' nova.egg-info/dependency_links.txt\n2013-09-26 06:11:12 + raw_links=\n2013-09-26 06:11:12 ++ echo\n2013-09-26 06:11:12 ++ xargs\n2013-09-26 06:11:12 + depend_links=\n2013-09-26 06:11:12 ++ \'[\' \'!\' -r nova.egg-info/requires.txt \']\'\n2013-09-26 06:11:12 ++ echo \'-r *-info/requires.txt\'\n2013-09-26 06:11:12 + require_file=\'-r *-info/requires.txt\'\n2013-09-26 06:11:12 + pip_install -r nova.egg-info/requires.txt\n2013-09-26 06:11:12 + [[ False = \\T\\r\\u\\e ]]\n2013-09-26 06:11:14 + [[ -z -r nova.egg-info/requires.txt ]]\n2013-09-26 06:11:14 + [[ -z deb ]]\n2013-09-26 06:11:14 + [[ False = True ]]\n2013-09-26 06:11:14 + SUDO_PIP=sudo\n2013-09-26 06:11:14 ++ get_pip_command\n2013-09-26 06:11:14 ++ is_fedora\n2013-09-26 06:11:14 ++ [[ -z Ubuntu ]]\n2013-09-26 06:11:14 ++ \'[\' Ubuntu = Fedora \']\'\n2013-09-26 06:11:14 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-09-26 06:11:14 ++ \'[\' Ubuntu = CentOS \']\'\n2013-09-26 06:11:14 ++ which pip\n2013-09-26 06:11:14 + CMD_PIP=/usr/local/bin/pip\n2013-09-26 06:11:14 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-09-26 06:11:14 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r nova.egg-info/requires.txt\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): SQLAlchemy>=0.7.8,<0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 1))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): Cheetah>=2.4.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 2))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 3))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 4))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): boto in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 5))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 6))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 7))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): lxml>=2.3 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 8))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 9))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): WebOb==1.2.3 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 10))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 11))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 12))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): paste in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 13))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy-migrate>=0.7.2 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 14))\n2013-09-26 06:11:14 Downloading/unpacking netaddr>=0.7.6 (from -r nova.egg-info/requires.txt (line 15))\n2013-09-26 06:11:14   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fnetaddr%2Fnetaddr-0.7.10.zip\n2013-09-26 06:11:14   Running setup.py egg_info for package netaddr\n2013-09-26 06:11:14     \n2013-09-26 06:11:14     warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n2013-09-26 06:11:14     warning: no previously-included files matching \'*.git*\' found anywhere in distribution\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): suds>=0.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 16))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): paramiko in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 17))\n2013-09-26 06:11:14 Downloading/unpacking pyasn1 (from -r nova.egg-info/requires.txt (line 18))\n2013-09-26 06:11:14   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyasn1%2Fpyasn1-0.1.7.tar.gz\n2013-09-26 06:11:14   Running setup.py egg_info for package pyasn1\n2013-09-26 06:11:14     \n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 19))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 20))\n2013-09-26 06:11:14 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 21))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 22))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): python-cinderclient>=1.0.1 in /opt/stack/new/python-cinderclient (from -r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:17   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.3.tar.gz\n2013-09-26 06:11:17   Running setup.py egg_info for package python-quantumclient\n2013-09-26 06:11:17     [pbr] Processing SOURCES.txt\n2013-09-26 06:11:17     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-09-26 06:11:17     \n2013-09-26 06:11:17     [pbr] In git context, generating filelist from git\n2013-09-26 06:11:17     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): python-glanceclient>=0.5.0,<2 in /opt/stack/new/python-glanceclient (from -r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r nova.egg-info/requires.txt (line 26))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): stevedore>=0.7 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 27))\n2013-09-26 06:11:17 Downloading/unpacking websockify<0.4 (from -r nova.egg-info/requires.txt (line 28))\n2013-09-26 06:11:17   Downloading websockify-0.3.0.tar.gz\n2013-09-26 06:11:17   In the tar file /tmp/pip-8bmohW-unpack/websockify-0.3.0.tar.gz the member websockify-0.3.0/websockify.py is invalid: \"linkname \'websockify-0.3.0/run\' not found\"\n2013-09-26 06:11:17   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fwebsockify%2Fwebsockify-0.3.0.tar.gz\n2013-09-26 06:11:17   Running setup.py egg_info for package websockify\n2013-09-26 06:11:17     \n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 29))\n2013-09-26 06:11:17 Downloading/unpacking Markdown>=2.0.1 (from Cheetah>=2.4.4->-r nova.egg-info/requires.txt (line 2))\n2013-09-26 06:11:17   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMarkdown%2FMarkdown-2.3.1.tar.gz\n2013-09-26 06:11:17   Running setup.py egg_info for package Markdown\n2013-09-26 06:11:17     \n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): decorator in /usr/lib/python2.7/dist-packages (from sqlalchemy-migrate>=0.7.2->-r nova.egg-info/requires.txt (line 14))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): Tempita>=0.4 in /usr/lib/python2.7/dist-packages (from sqlalchemy-migrate>=0.7.2->-r nova.egg-info/requires.txt (line 14))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=0.9.6->-r nova.egg-info/requires.txt (line 19))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:17 Requirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:19 Downloading/unpacking pyparsing>=1.5.6,<2.0 (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:19   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyparsing%2Fpyparsing-1.5.7.tar.gz\n2013-09-26 06:11:19   Running setup.py egg_info for package pyparsing\n2013-09-26 06:11:19     \n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): numpy in /usr/lib/python2.7/dist-packages (from websockify<0.4->-r nova.egg-info/requires.txt (line 28))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:19 Requirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-26 06:11:19 Installing collected packages: netaddr, pyasn1, python-quantumclient, websockify, Markdown, pyparsing\n2013-09-26 06:11:19   Found existing installation: netaddr 0.7.5\n2013-09-26 06:11:19     Uninstalling netaddr:\n2013-09-26 06:11:19       Successfully uninstalled netaddr\n2013-09-26 06:11:19   Running setup.py install for netaddr\n2013-09-26 06:11:19     changing mode of build/scripts-2.7/netaddr from 644 to 755\n2013-09-26 06:11:19     \n2013-09-26 06:11:19     warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n2013-09-26 06:11:19     warning: no previously-included files matching \'*.git*\' found anywhere in distribution\n2013-09-26 06:11:19     changing mode of /usr/local/bin/netaddr to 755\n2013-09-26 06:11:19   Running setup.py install for pyasn1\n2013-09-26 06:11:19     \n2013-09-26 06:11:19   Running setup.py install for python-quantumclient\n2013-09-26 06:11:19     [pbr] Reusing existing SOURCES.txt\n2013-09-26 06:11:19     Installing quantum script to /usr/local/bin\n2013-09-26 06:11:19   Running setup.py install for websockify\n2013-09-26 06:11:19     \n2013-09-26 06:11:19     Installing websockify script to /usr/local/bin\n2013-09-26 06:11:19   Running setup.py install for Markdown\n2013-09-26 06:11:19     changing mode of build/scripts-2.7/markdown_py from 644 to 755\n2013-09-26 06:11:19     Converting docs/release-2.2.1.txt -> build/docs/release-2.2.1.html\n2013-09-26 06:11:19     Converting docs/install.txt -> build/docs/install.html\n2013-09-26 06:11:19     Converting docs/change_log.txt -> build/docs/change_log.html\n2013-09-26 06:11:19     Converting docs/release-2.0.txt -> build/docs/release-2.0.html\n2013-09-26 06:11:19     Converting docs/release-2.1.0.txt -> build/docs/release-2.1.0.html\n2013-09-26 06:11:19     Converting docs/release-2.0.2.txt -> build/docs/release-2.0.2.html\n2013-09-26 06:11:19     Converting docs/cli.txt -> build/docs/cli.html\n2013-09-26 06:11:19     Converting docs/authors.txt -> build/docs/authors.html\n2013-09-26 06:11:19     Converting docs/siteindex.txt -> build/docs/siteindex.html\n2013-09-26 06:11:19     Converting docs/release-2.1.1.txt -> build/docs/release-2.1.1.html\n2013-09-26 06:11:19     Converting docs/release-2.0.1.txt -> build/docs/release-2.0.1.html\n2013-09-26 06:11:19     Converting docs/reference.txt -> build/docs/reference.html\n2013-09-26 06:11:20     Converting docs/release-2.2.0.txt -> build/docs/release-2.2.0.html\n2013-09-26 06:11:20     Converting docs/release-2.3.txt -> build/docs/release-2.3.html\n2013-09-26 06:11:20     Converting docs/test_suite.txt -> build/docs/test_suite.html\n2013-09-26 06:11:20     Converting docs/index.txt -> build/docs/index.html\n2013-09-26 06:11:20     Converting docs/extensions/extra.txt -> build/docs/extensions/extra.html\n2013-09-26 06:11:20     Converting docs/extensions/definition_lists.txt -> build/docs/extensions/definition_lists.html\n2013-09-26 06:11:20     Converting docs/extensions/tables.txt -> build/docs/extensions/tables.html\n2013-09-26 06:11:20     Converting docs/extensions/fenced_code_blocks.txt -> build/docs/extensions/fenced_code_blocks.html\n2013-09-26 06:11:20     Converting docs/extensions/smart_strong.txt -> build/docs/extensions/smart_strong.html\n2013-09-26 06:11:20     Converting docs/extensions/toc.txt -> build/docs/extensions/toc.html\n2013-09-26 06:11:20     Converting docs/extensions/footnotes.txt -> build/docs/extensions/footnotes.html\n2013-09-26 06:11:20     Converting docs/extensions/api.txt -> build/docs/extensions/api.html\n2013-09-26 06:11:20     Converting docs/extensions/abbreviations.txt -> build/docs/extensions/abbreviations.html\n2013-09-26 06:11:20     Converting docs/extensions/header_id.txt -> build/docs/extensions/header_id.html\n2013-09-26 06:11:20     Converting docs/extensions/wikilinks.txt -> build/docs/extensions/wikilinks.html\n2013-09-26 06:11:20     Converting docs/extensions/code_hilite.txt -> build/docs/extensions/code_hilite.html\n2013-09-26 06:11:20     Converting docs/extensions/sane_lists.txt -> build/docs/extensions/sane_lists.html\n2013-09-26 06:11:20     Converting docs/extensions/attr_list.txt -> build/docs/extensions/attr_list.html\n2013-09-26 06:11:20     Converting docs/extensions/nl2br.txt -> build/docs/extensions/nl2br.html\n2013-09-26 06:11:20     Converting docs/extensions/index.txt -> build/docs/extensions/index.html\n2013-09-26 06:11:20     Converting docs/extensions/admonition.txt -> build/docs/extensions/admonition.html\n2013-09-26 06:11:20     Converting docs/extensions/meta_data.txt -> build/docs/extensions/meta_data.html\n2013-09-26 06:11:20     \n2013-09-26 06:11:20     changing mode of /usr/local/bin/markdown_py to 755\n2013-09-26 06:11:20   Found existing installation: pyparsing 2.0.1\n2013-09-26 06:11:20     Uninstalling pyparsing:\n2013-09-26 06:11:20       Successfully uninstalled pyparsing\n2013-09-26 06:11:20   Running setup.py install for pyparsing\n2013-09-26 06:11:20     \n2013-09-26 06:11:20 Successfully installed netaddr pyasn1 python-quantumclient websockify Markdown pyparsing\n2013-09-26 06:11:20 Cleaning up...\n2013-09-26 06:11:20 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-09-26 06:11:20 running develop\n2013-09-26 06:11:20 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-09-26 06:11:20 /usr/bin/python -E -c pass\n2013-09-26 06:11:20 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-09-26 06:11:20 running egg_info\n2013-09-26 06:11:20 writing requirements to nova.egg-info/requires.txt\n2013-09-26 06:11:20 writing nova.egg-info/PKG-INFO\n2013-09-26 06:11:20 writing top-level names to nova.egg-info/top_level.txt\n2013-09-26 06:11:20 writing dependency_links to nova.egg-info/dependency_links.txt\n2013-09-26 06:11:20 reading manifest template \'MANIFEST.in\'\n2013-09-26 06:11:20 warning: no files found matching \'AUTHORS\'\n2013-09-26 06:11:20 warning: no files found matching \'ChangeLog\'\n2013-09-26 06:11:20 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-26 06:11:20 writing manifest file \'nova.egg-info/SOURCES.txt\'\n2013-09-26 06:11:20 running build_ext\n2013-09-26 06:11:20 Creating /usr/local/lib/python2.7/dist-packages/nova.egg-link (link to .)\n2013-09-26 06:11:20 Adding nova 2013.1.4.a27.gfaabb91 to easy-install.pth file\n2013-09-26 06:11:20 Installing nova-all script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-api script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-api-ec2 script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-api-metadata script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-api-os-compute script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-baremetal-deploy-helper script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-baremetal-manage script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-rpc-zmq-receiver script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-cells script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-cert script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-clear-rabbit-queues script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-compute script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-conductor script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-console script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-consoleauth script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-dhcpbridge script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-manage script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-network script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-novncproxy script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-objectstore script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-rootwrap script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-scheduler script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-spicehtml5proxy script to /usr/local/bin\n2013-09-26 06:11:20 Installing nova-xvpvncproxy script to /usr/local/bin\n2013-09-26 06:11:20 \n2013-09-26 06:11:20 Installed /opt/stack/new/nova\n2013-09-26 06:11:20 Processing dependencies for nova==2013.1.4.a27.gfaabb91\n2013-09-26 06:11:20 error: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n2013-09-26 06:11:20 ++ failed\n2013-09-26 06:11:20 ++ local r=1\n2013-09-26 06:11:20 +++ jobs -p\n2013-09-26 06:11:20 ++ kill\n2013-09-26 06:11:20 ++ set +o xtrace\n2013-09-26 06:11:20 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-26-060838\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/localrc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-392688-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-392688.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-392688/25/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1768649681.27.1380089073483.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1286302151.32.1374559635044.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-23 06:07:14',0,'2013-07-23 06:07:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #295','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/295/>\n\n------------------------------------------\n[...truncated 2596 lines...]\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.128.g58d436e to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.128.g58d436e\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.128.g58d436e\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.10.g8ffaa0a to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.10.g8ffaa0a\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.10.g8ffaa0a\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/rabbitmq/rabbit at devstack-1374556837-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/rabbitmq/rabbit at devstack-1374556837.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/295/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<338390192.28.1374473216505.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1286369680.5.1385189101223.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-23 06:45:00',0,'2013-11-23 06:45:00',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #52','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/52/>\n\n------------------------------------------\n[...truncated 21712 lines...]\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.api.network.test_extensions.ExtensionsTestJSON)\nsetUpClass (tempest.api.network.test_extensions.ExtensionsTestJSON) ... skipped u\'Neutron support is required\'\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_large_object[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_large_object[gate,smoke] ... ok\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_too_many_objects[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_too_many_objects[gate,smoke] ... ok\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_valid_object[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_valid_object[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_container_staticweb.StaticWebTest.test_web_index\ntempest.api.object_storage.test_container_staticweb.StaticWebTest.test_web_index ... ok\ntempest.api.object_storage.test_container_staticweb.StaticWebTest.test_web_listing\ntempest.api.object_storage.test_container_staticweb.StaticWebTest.test_web_listing ... ok\ntempest.api.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time[gate]\ntempest.api.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time[gate] ... skipped u\'Skipped until Bug: 1069849 is resolved.\'\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_begin_detaching[gate]\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_begin_detaching[gate] ... ok\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_reset_status[gate]\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_reset_status[gate] ... ok\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_roll_detaching[gate]\ntempest.api.volume.admin.test_volumes_actions.VolumesActionsTest.test_volume_roll_detaching[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_reserve_unreserve_volume[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_reserve_unreserve_volume[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          103.529\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   54.749\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  52.107\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             42.779\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         37.753\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                34.594\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     33.292\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     33.269\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    32.099\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       31.637\n\n----------------------------------------------------------------------\nRan 1520 tests in 1284.657s\n\nOK (skipped=84)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-726637-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-726637.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-726637/52/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<340186763.127.1384756606413.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1286C4B0-A66B-4B97-A68E-5AB3EFF342DE@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 19:18:45',-18000,'2013-12-10 00:18:45',NULL,'[openstack-dev] [neutron] Questions on logging setup for\n	development','Thanks! That worked!!!!\n\n\n\nPCM (Paul Michali)\n\nMAIL          pcm at cisco.com\nIRC            pcm_  (irc.freenode.net)\nTW            @pmichali\nGPG key    4525ECC253E31A83\nFingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\nOn Dec 9, 2013, at 5:27 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n\n> \n> On Dec 6, 2013, at 2:09 PM, Paul Michali <pcm at cisco.com> wrote:\n> \n>> Hi,\n>> \n>> For Neutron, I\'m creating a module (one of several eventually) as part of a new blueprint I\'m working on, and the associated unit test module. I\'m in really early development, and just running this UT module as a standalone script (rather than through tox). It allows me to do TDD pretty quickly on the code I\'m developing (that\'s the approach I\'m taking right now - fingers crossed :).\n>> \n>> In the module, I did an import of the logging package and when I run UTs I can see messaging that would occur, if desired.\n>> \n>> I have the following hack to turn off/on the logging for debug level:\n>> \n>> if False:  # Debugging\n>>     logging.basicConfig(format=\'%(asctime)-15s [%(levelname)s] %(message)s\',\n>>                         level=logging.DEBUG)\n>> \n>> I made the log calls the same as what would be in other Neutron code, so that I don\'t have to change the code later, as I start to fold it into the Neutron code. However, I\'d like to import the neutron.openstack.common.log package in my code, so that the code will be identical to what is needed once I start running this code as part of a process, but I had some questions?\n>> \n>> When using neutron.openstack.common.log, how do I toggle the debug level logging on, if I run this standalone, as I\'m doing now?\n>> Is there a way to do it, without adding in the above conditional logic to the production code? Maybe put something in the UT module?\n> \n> I believe you can just make sure to set_override on the CONF option to True and then call logging.setup(\'neutron\')\n> \n> Here is an example with the nova code\n> \n> >>> from nova.openstack.common import log as logging\n> >>> LOG = logging.getLogger(__name__)\n> >>> LOG.debug(\'foo\')\n> >>> logging.CONF.set_override(\'debug\', True)\n> >>> logging.setup(\'nova\')\n> >>> LOG.debug(\'foo\')\n> 2013-12-09 14:25:21.220 72011 DEBUG __main__ [-] foo <module> <input>:2\n> \n> Vish\n> \n> \n>> \n>> I can always continue as is, and then switch things over later (changing the import line and pulling the if clause), once I have things mostly done, and want to run as part of Neutron, but it would be nice if I can find a way to do that up front to avoid changes later.\n>> \n>> Thoughts? Suggestions?\n>> \n>> Thanks!\n>> \n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL          pcm at cisco.com\n>> IRC            pcm_  (irc.freenode.net)\n>> TW            @pmichali\n>> GPG key    4525ECC253E31A83\n>> Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/7f476399/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 841 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/7f476399/attachment.pgp>\n\n','<CFE97272-2C33-4517-AD2E-021465AA86F1@gmail.com>',NULL),('<1287190384.16255570.1372866690361.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 08:51:30',-25200,'2013-07-03 15:51:30',NULL,'[openstack-dev]  [vmware] VMwareAPI sub-team status update','Greetings Stackers!\n\nI covered open reviews on Friday. It is a short week for us here in the US so I\'ll just be sending the one email this week just ahead of our VMwareAPI team meeting.\n\nBlueprints targeted for Havana-2:\n* https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage - started but depends on\n** https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy - which I have up for review\n* https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service - good progress \n\nIf you are working on a BP for H2 deadline try to get it up and finished for Monday morning. Review cycles are long and if you don\'t have it up for review by then the chances are your blueprint will slip into Havana-3.\n\nThanks to the core-reviewers for all their attention! We\'ve had several patches merge and I feel that our developers are starting to learn what\'s expected from them. I have a feeling that future reviews will be smoother thanks to your attentions.\n\nMerged (Victory!):\n* https://review.openstack.org/#/c/30036/\n* https://review.openstack.org/#/c/30289/\n\nNeeds one more +2 / Approve button:\n* https://review.openstack.org/#/c/27885/\n* https://review.openstack.org/#/c/29453/ \n\nReady for core-reviewer:\n[none at this stage right now]\n\nNeeds VMware API expert review:\n* https://review.openstack.org/#/c/30282/\n* https://review.openstack.org/#/c/30628/ <- pretty close to ready for core\n* https://review.openstack.org/#/c/30822/ <- almost ready for core\n* https://review.openstack.org/#/c/33100/\n* https://review.openstack.org/#/c/33238/ <- BP\n* https://review.openstack.org/#/c/33504/ <- VC not available fix\n* https://review.openstack.org/#/c/34033/ <- new feature, how should VMwareAPI support?\n\nNeeds help/discussion (has topical -1 issues):\n* https://review.openstack.org/#/c/33782/ <- general nova discussion affects all hypervisors\n* https://review.openstack.org/#/c/33088/ <- IIRC author is considering dropping this?\n* https://review.openstack.org/#/c/34189/ <- has -1 for nit-pick reasons\n\nWork in progress:\n* https://review.openstack.org/#/c/35502/ <- I can\'t click the \"Work in progress button\" I\'m not sure how else to signal that I\'m still working... help?\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n\n# Shawn Hartsock - VMware\'s Nova Compute driver maintainer guy\n\n\n','<57455745.12523152.1372446159769.JavaMail.root@vmware.com>',NULL),('<1287488259.10217571.1375392375279.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-01 17:26:15',-14400,'2013-08-01 21:26:15',NULL,'[Openstack-docs] Common content strategy?','----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, August 1, 2013 4:58:41 PM\n> Subject: Re: [Openstack-docs] Common content strategy?\n> \n> On 02/08/13 06:17, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Tom Fifield\" <tom at openstack.org>\n> >> To: \"Steve Gordon\" <sgordon at redhat.com>\n> >> Cc: openstack-docs at lists.openstack.org\n> >> Sent: Thursday, August 1, 2013 4:08:35 PM\n> >> Subject: Re: [Openstack-docs] Common content strategy?\n> >>\n> >> On 02/08/13 06:06, Steve Gordon wrote:\n> >>> ----- Original Message -----\n> >>>> From: \"Tom Fifield\" <tom at openstack.org>\n> >>>> To: openstack-docs at lists.openstack.org\n> >>>> Sent: Thursday, August 1, 2013 3:53:54 PM\n> >>>> Subject: Re: [Openstack-docs] Common content strategy?\n> >>>>\n> >>>> Just quickly on the crazy linking that\'s going on right now.\n> >>>>\n> >>>> I\'m one of the worst offenders of breaking the model, but I believe\n> >>>> there\'s good reason ... in doing the restructure, I\'m trying to keep\n> >>>> current things in place, but note that they\'ll be subsumed as further\n> >>>> progress is made.\n> >>>>\n> >>>> If there\'s a big effort to push content into the common folder right\n> >>>> now, you\'ll end up with most of the compute admin manual and the config\n> >>>> reference in the common folder.\n> >>>\n> >>> Given at this stage the intent is to continue to release the compute\n> >>> administration guide isn\'t that correct though (in that the content *is*\n> >>> common to both)? Keep in mind here also that large swaths of the compute\n> >>> admin manual already appear in common (this is in part why I brought up\n> >>> the taxonomy question).\n> >>\n> >> Not for the next release, unless you want to write it :)\n> > \n> > OK, it was still listed last I saw - just not as one of the two\n> > deliverables that must be ready:\n> > \n> > http://lists.openstack.org/pipermail/openstack-docs/2013-July/002391.html\n> \n> Yep, I disagree with this, so I\'ve replied to that thread :)\n> \n> >> Additionally, the content in config ref that is currently xi:included\n> >> will be struck from the compute admin guide - it will not be common to\n> >> both.\n> > \n> > Right, but to me that is all the more reason to do it now. As it currently\n> > stands without any of my commits on this issue being merged there are ~144\n> > relative includes in openstack-config, of those only 10 go to locations\n> > outside of common (which are the ones I want to move).\n> \n> So https://review.openstack.org/#/c/39731 is an example of where this\n> consolidation is a bad idea right now :)\n> \n> I\'m in the middle of working through re-doing which xen bit sit wher,\n> and would just end up un-doing the move proposed in the patch.\n\nThe problem though is bits and pieces of that redo are already committed, resulting in this kind of structure:\n\n* openstack-config/ch_computehypervisors.xml\n  * Includes -> ../common/introduction-to-xen.xml\n    * Includes -> ../openstack-config/compute-configure-xen.xml\n      * Includes -> ../common/tables/nova-xen.xml\n\nAre you suggesting that your approach to this will be to move the 3/4 files in this chain that are in common now to openstack-config, rather than the opposite as proposed in my patch? If the plan is for these files to move to openstack-config and be dropped from the other guide(s) then I\'d suggest making a list and let\'s get it done.\n\nThanks,\n\nSteve\n\n\n','<51FACC01.7000603@openstack.org>',NULL),('<1287605746.7410807.1353968507751.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 17:21:47',-18000,'2012-11-26 22:21:47',NULL,'[openstack-dev] [ceilometer] Multiple publisher and transformer','\n\n> > > Would we expect users to configure that pipeline?\n> \n> > Rarely, it should be more of a side-effect of deployment (e.g.\n> > rolling out a CW service would require corresponding updates to\n> > the ceilo compute agent config).\n> \n> That seems a little brittle. We probably want a set of files, instead\n> of a monolithic config, to make it easier to add and remove pieces\n> using tools like chef and puppet.\n\n\nYep.\n\nIn fact, if we stick to the common cfg format, then we get the ability\nto pull in config fragments from a conf.d-style directory for free.\n\n(I added this a while back in[1] specifically to support the puppet\nuse-case).\n\nCheers,\nEoghan\n\n[1] https://github.com/openstack/oslo-incubator/commit/fd8c2e7c\n\n\n','<CADb+p3R2t8Dm=bWjgbgWBDKc8=EY8WzEnEnNkhfEfcgr9d=gOQ@mail.gmail.com>',NULL),('<1287855348.16.1377065845027.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-21 06:17:24',0,'2013-08-21 06:17:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-grizzly #6','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/6/>\n\n------------------------------------------\n[...truncated 1166 lines...]\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_infinite_child_death\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 267, in test_infinite_child_death\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib64/python2.6/unittest.py\", line 324, in failUnless\n    if not expr: raise self.failureException, msg\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 93.35 secs:\n    26.94    TestScrubber.test_scrubber_app\n    21.10    TestScrubber.test_delayed_delete\n    15.33    TestRootApi.test_version_configurations\n    15.12    TestGlanceControl.test_reload\n    14.87    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 651.534s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.6\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.13\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.5UrwAjARhK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-3/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<128806795.294.1366697224972.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-23 06:07:04',0,'2013-04-23 06:07:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #13','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/13/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-23 06:06:59    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-23 06:06:59,370 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-23 06:06:59,371 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-23 06:06:59,371 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,372 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,373 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-23 06:06:59,374 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-23 06:06:59,375 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-23 06:06:59  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-23 06:06:59,376 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-23 06:06:59    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-23 06:06:59,377 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,382 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.382401\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.382401\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59,383 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,384 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,385 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,387 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59,388 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.386917\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.386917\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59,389 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,389 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,390 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-23 06:06:59,391 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,392 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,394 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59,395 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.394078\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.394078\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59,396 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,397 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,398 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-23 06:06:59,399 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,399 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,401 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59,402 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.401393\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.401393\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59,403 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,404 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,405 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-23 06:06:59,406 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,406 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,408 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-23 06:06:59,410 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-23 06:06:59,411 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.409975\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-23T06:06:59.409975\', resource_metadata={}) from 0 transformer\n2013-04-23 06:06:59,412 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,413 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59,413 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-23 06:06:59,414 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-23 06:06:59,415 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-23 06:06:59    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.706s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.13\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a65.gb56491f\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a355.gbfc3a3c\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.zZgb58iT9q\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/13\n[SCP] Copying console log.\n\n\n','<1573948199.277.1366610832008.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1288114510.103.1384064118291.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-10 06:15:18',0,'2013-11-10 06:15:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #43','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/43/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x591a810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x591a810>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5440290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5440290>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-41daf398-8e08-4461-8641-43a1662f2004\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x359e8c0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x359e8c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x359e8c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x359e8c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:14:32Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'32\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'32\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:14:32Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'32\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'32\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:14:32+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'32\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'32\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:14:32-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'32\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'32\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:14:32Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'32\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'32\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x655a110>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x21422d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 96.35 secs:\n    26.98    TestScrubber.test_scrubber_app\n    21.63    TestScrubber.test_delayed_delete\n    16.46    TestRootApi.test_version_configurations\n    15.99    TestBinGlanceCacheManage.test_queue\n    15.29    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1109 tests in 722.342s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.16.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.43\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.QcMQBllh8Z\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/43/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise30/43\n[SCP] Copying console log.\n\n\n','<1622271862.100.1383977592892.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1288199568.10929761.1410378777669.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-10 15:52:57',-14400,'2014-09-10 19:52:57',NULL,'[Openstack-docs] Installation guide updates for Juno','----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: openstack-docs at lists.openstack.org\n> \n> Ubuntu recently began offering pre-release Juno packages [1] and I\n> successfully built a three-node \"core services\" environment using them.\n> Let\'s discuss the potential changes...\n> \n> 1) So far, updating the OpenStack services chapters of the installation\n> guide mostly involves some configuration file changes, removing old\n> workarounds, and probably adding new workarounds. Should we use a bug or a\n> blueprint for these issues? In either case, I recommend uploading separate\n> patches for each service.\n> \n> 2) Neutron supports distributed virtual routers (DVR) and I\'m sure people\n> want instructions for deploying them. However, DVR introduces more\n> complexity to already difficult networking concepts and requires\n> architectural changes to fully configure and demonstrate. At least for\n> Juno, I recommend keeping the legacy architecture and adding instructions\n> for deploying DVR to the networking or admin guides.\n> \n> 3) Open vSwitch adds another level of complexity to already difficult\n> networking concepts, particularly with troubleshooting. Linux Bridge\n> provides a reliable alternative that reduces complexity, but DVR doesn\'t\n> support it. Should we add instructions for deploying Linux Bridge as an\n> alternative to Open vSwitch?\n> \n> 4) The neutron external network (ext-net) \"magically\" works although we\n> don\'t explicitly configure support for flat networks. For sanity, we should\n> probably adjust the configuration to support one flat network and adjust\n> the initial network instructions to use it as a flat provider network.\n> \n> 5) I\'m seeing more deployments moving from novnc to spice consoles. Should\n> we configure spice instead of novnc?\n>\n> 6) I\'m seeing more deployments moving from MySQL to MariaDB. Ubuntu 14.04\n> offers MariaDB 5.5 which more or less clones MySQL 5.5 including the\n> configuration files. I suspect RHEL 7, Fedora, and other RPM distributions\n> also offer MariaDB packages. Should we change all distributions to MariaDB?\n> \n> [1] https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/juno-staging\n\nRDO and RHELOSP actually already moved to mariadb 5.5 in the Icehouse-based releases.\n\n-Steve\n\n\n','<CABA+jQq0SuWaVLBp0ZGgxk8EPB2FH8v7+8ygMv6yqtwQSfSKfQ@mail.gmail.com>',NULL),('<1288738911.3683521381964470890.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-16 23:01:10',0,'2013-10-16 23:01:10',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n Meeting October 17, 2013 - Requested Session','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting October 17, 2013 - Requested Session\nHost: Alan Clark\nDate: Thursday, October 17, 2013\nTime: 4:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 922 514 295\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&HMAC=f5f8695f8841b510747721a5bc4065416f20533c&RT=MiM0\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&HMAC=f5f8695f8841b510747721a5bc4065416f20533c&ORT=MiM0\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=243475827&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 514 295\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=243475827&EF=MA&UUID=1713093867&RT=MiM0&SHA2=ZlP4vQhaE4dlXtCzk6Cj5KtCw9Kbet44JsLa1MX0AHA=\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131016/d98f4aa1/attachment.html>\n\n',NULL,NULL),('<1288818596.762559.1381767405841.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 12:16:45',-14400,'2013-10-14 16:16:45',NULL,'[openstack-dev] Ceilometer','\nDoes your pipeline configuration file exist?\n\n(This defaults to /etc/ceilometer/pipeline.yaml, if not\noverridden via the pipeline_cfg_file config option.)\n\n----- Original Message -----\n> Hi all,\n> \n> I tried to install openstack via devstack, while including ceilometer.\n> The install of openstack is ok. The dashborad is accessible, and everything\n> seem to be fine.\n> However, I am not able to launch ceilometer services. For instance\n> ceilometer-collector returns the following error, that seems related to\n> python coding errors. Would you please help me to fix this bug.\n> \n> Thanks,\n> Afef\n> \n> -------------------------------------------------------------------------------------------------\n> root at onodedomU:/etc/ceilometer# ceilometer-collector\n> 2013-10-14 13:53:12.638 32022 INFO ceilometer.openstack.common.rpc.common [-]\n> Connected to AMQP server on localhost:5672\n> /usr/local/lib/python2.7/dist-packages/amqp/channel.py:599:\n> DeprecationWarning: auto_delete exchanges has been deprecated\n> \'auto_delete exchanges has been deprecated\'))\n> Traceback (most recent call last):\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/hubs/poll.py\", line 99,\n> in wait\n> writers.get(fileno, noop).cb(fileno)\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py\", line\n> 194, in main\n> result = function(*args, **kwargs)\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/service.py\", line\n> 448, in run_service\n> service.start()\n> File \"/opt/stack/ceilometer/ceilometer/collector/service.py\", line 138, in\n> start\n> super(CollectorService, self).start()\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/rpc/service.py\", line\n> 66, in start\n> self.manager.initialize_service_hook(self)\n> File \"/opt/stack/ceilometer/ceilometer/collector/service.py\", line 147, in\n> initialize_service_hook\n> \'ceilometer.transformer\',\n> File \"/opt/stack/ceilometer/ceilometer/pipeline.py\", line 356, in\n> setup_pipeline\n> with open(cfg_file) as fap:\n> TypeError: coercing to Unicode: need string or buffer, NoneType found\n> Removing descriptor: 4\n> 2013-10-14 13:53:12.662 32022 ERROR ceilometer.openstack.common.threadgroup\n> [-] coercing to Unicode: need string or buffer, NoneType found\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> Traceback (most recent call last):\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/threadgroup.py\",\n> line 117, in wait\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> x.wait()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/threadgroup.py\",\n> line 49, in wait\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> return self.thread.wait()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py\", line\n> 168, in wait\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> return self._exit_event.wait()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/event.py\", line 116,\n> in wait\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> return hubs.get_hub().switch()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py\", line\n> 187, in switch\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> return self.greenlet.switch()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py\", line\n> 194, in main\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> result = function(*args, **kwargs)\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/service.py\", line\n> 448, in run_service\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> service.start()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/collector/service.py\", line 138, in\n> start\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> super(CollectorService, self).start()\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/openstack/common/rpc/service.py\",\n> line 66, in start\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> self.manager.initialize_service_hook(self)\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/collector/service.py\", line 147, in\n> initialize_service_hook\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> \'ceilometer.transformer\',\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> File \"/opt/stack/ceilometer/ceilometer/pipeline.py\", line 356, in\n> setup_pipeline\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> with open(cfg_file) as fap:\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> TypeError: coercing to Unicode: need string or buffer, NoneType found\n> 2013-10-14 13:53:12.662 32022 TRACE ceilometer.openstack.common.threadgroup\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAEufa6A68gW1dr9g1TDjievmRjVSEuFHKWkf3ovoWq2hyiJX9g@mail.gmail.com>',NULL),('<128899EB-4E2D-4E52-90BC-075CC5A8F789@unitedstack.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-26 14:49:48',28800,'2013-07-26 06:49:48',NULL,'[openstack-dev] [nova] generate_sample.sh','\n\n2013-7-26?1:58 pm?Gary Kotton <gkotton at vmware.com> Wrote?\n\n> Hi,\n> Over the last few days I have been battling with this script (I am only human). Recently there was a nice change that removed the number of entries which helps with the merges. One thing that I have encountered over the last 2 days is that the pep8 passes with my environment and fails with the gaiting. Would it be possible that Jenkins updates the nova.sample.conf in a similar fashion to the way that is done with the translations?\n+1, I encountered the same problem and I think the task running gererate_sample.sh should be given to Jenkins\n\n> Thanks\n> Gary\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nBest regards,\nHaomai Wang, UnitedStack Inc.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130726/1892bb72/attachment.html>\n\n','<D9AD1F0A0B678548BB8FF40C740D1772025940A8E0@exch-mbx-122.vmware.com>',NULL),('<1289202050.107.1356134712962.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-22 00:05:12',0,'2012-12-22 00:05:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #82','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/82/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/82\n[SCP] Copying console log.\n\n\n','<278834913.83.1356048323315.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1289493134.118.1356220919128.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-23 00:01:59',0,'2012-12-23 00:01:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #83','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/83/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise16 in workspace <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/>\nCheckout:periodic-keystone-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/> - hudson.remoting.Channel at 31f32e51:precise16\nUsing strategy: Default\nLast Built Revision: Revision ec9c84c497ad7ca802e3bfc52842018b259a3ad9 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/keystone.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/keystone.git\nERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway.\nhudson.plugins.git.GitException: Command \"git fetch -t git://github.com/openstack/keystone.git +refs/heads/*:refs/remotes/origin/*\" returned status code 128:\nstdout: \nstderr: fatal: unable to connect to github.com:\ngithub.com[0: 207.97.227.239]: errno=Connection timed out\n\n\n	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:863)\n	at hudson.plugins.git.GitAPI.launchCommand(GitAPI.java:824)\n	at hudson.plugins.git.GitAPI.fetch(GitAPI.java:198)\n	at hudson.plugins.git.GitAPI.fetch(GitAPI.java:1071)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1122)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n	at java.lang.Thread.run(Thread.java:679)\nERROR: Could not fetch from any repository\nFATAL: Could not fetch from any repository\nhudson.plugins.git.GitException: Could not fetch from any repository\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1134)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n	at java.lang.Thread.run(Thread.java:679)\n\n\n','<1405464732.110.1356134807488.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<12895458-D787-43BE-8F25-C64FCFBEF349@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-03 01:21:58',-28800,'2013-02-03 09:21:58',NULL,'[openstack-dev] Nova + testr?','Will check it out, I am just trying to make sure those devs running tests locally don\'t get \'second classed\' in the name of parallel ci and such. \n\nThx!\n\nSent from my really tiny device...\n\nOn Feb 2, 2013, at 6:18 PM, \"Monty Taylor\" <mordred at inaugust.com> wrote:\n\n> \n> \n> On 02/03/2013 12:16 PM, Robert Collins wrote:\n>> On 3 February 2013 13:28, Monty Taylor <mordred at inaugust.com> wrote:\n>>> \n>>> \n>>> On 02/03/2013 04:36 AM, Joshua Harlow wrote:\n>>>> Haha, even in parallel u could just have X progress bars ya?\n>>> \n>>> Totally. Except I think I\'ve figured out how to get you the actual\n>>> magical thing you actually want ... (non-integrated POC working on my\n>>> laptop - now I just have to get it called from the right place)\n>>> \n>>>> Thanks for the babble, I was looking through testr docs/code and wasn\'t able to figure out to much. Your \'dump\' helps.\n>> \n>> Isn\'t \'testr run --subunit | subunit2pyunit what you want?\n> \n> It\'s a step better. I believe folks will be extra happier when we can\n> return the formatted and colored output, which is what I was poking at.\n> But I\'ve submitted a patch here:\n> \n> https://review.openstack.org/21063\n> \n> In case this is good enough for the case Josh is concerned about short term.\n> \n> Monty\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<510DC1C6.6040300@inaugust.com>',NULL),('<1289659060.906306.1391536539969.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 18:55:39',3600,'2014-02-04 17:55:39',NULL,'[openstack-dev] Asynchrounous programming: replace\n	eventlet	with asyncio','Hi,\n\n> Thanks for taking this on, Victor.\n> \n> Do you have a small eventlet program example that you can show the\n> transformation to asyncio?\n\nExample getting the body of an HTML page and display it to the terminal. The HTTP query is invalid, the Host header is missing, but supporting HTTP/1.0 and the connected mode would make the example more complex.\n\nEventlet version:\n---\nimport eventlet\nfrom eventlet.green import socket\n\ndef getbody(url, limit=1024):\n    c = socket.socket()\n    ip = socket.gethostbyname(url)\n    c.connect((ip, 80))\n    c.sendall(\'HEAD /\\r\\n\\r\\n\')\n    body = c.recv(limit)\n    return body\n\nbody = getbody(\'www.python.org\')\nprint(body)\n---\n\nTrollius version:\n---\nimport asyncio\nimport logging; logging.basicConfig()\nfrom asyncio import Return\nimport socket\n\n@asyncio.coroutine\ndef getbody(url):\n    reader, writer = yield asyncio.open_connection(url, 80)\n    writer.write(\'HEAD /\\r\\n\\r\\n\')\n    # yield writer.drain()\n    body = yield reader.read()\n    raise Return(body)\n\nloop = asyncio.get_event_loop()\nbody = loop.run_until_complete(getbody(\'www.python.org\'))\nprint(body)\nloop.close()\n---\n\nRemarks:\n\n - no special \"sendall\" method: writer.write() always write all data, and it\'s the same name for any kind of transport (socket, SSL socket, pipe, etc.)\n - open_connection() accepts directly an hostname. It resolves the hostname asynchronously (call socket.gethostbyname in a pool of threads)\n - it\'s possible to call reader.read() with no limit: in this case, read() stops when the server closes the connection. Using eventlet, you have to buffer manually. There is also a convinient readline() buffer which reads until it gets a newline character (\"\\n\")\n - run_until_complete() is only used in short examples, usually run_forever() is preferred, something will call loop.stop() to stop the loop\n\nYou can uncomment \"writer.drain()\" to wait until all data are sent to the server. Otherwise, it will be done in background asynchronously.\n\nSee asyncio documentation for more examples:\nhttp://docs.python.org/dev/library/asyncio.html\n\nVictor\n\n\n','<CAPzLFkWe0R-09EYOYeJcrrNWScADGSh7WGqrjAN=rmhkHO2RCw@mail.gmail.com>',NULL),('<128A129B-79BE-41C5-81B4-36BD1363EE2D@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 13:39:32',32400,'2013-12-11 04:39:32',NULL,'[openstack-dev] [Neutron] DHCP Agent Reliability','\nOn Dec 11, 2013, at 8:39 AM, Isaku Yamahata <isaku.yamahata at gmail.com> wrote:\n\n> On Wed, Dec 11, 2013 at 01:23:36AM +0900,\n> Maru Newby <marun at redhat.com> wrote:\n> \n>> \n>> On Dec 10, 2013, at 6:36 PM, Isaku Yamahata <isaku.yamahata at gmail.com> wrote:\n>> \n>>> On Mon, Dec 09, 2013 at 08:43:59AM +1300,\n>>> Robert Collins <robertc at robertcollins.net> wrote:\n>>> \n>>>>>> listening: when an agent connects after an outage, it first starts\n>>>>>> listening, then does a poll for updates it missed.\n>>>>> \n>>>>> Are you suggesting that processing of notifications and full state synchronization are able to cooperate safely?  Or hoping that it will be so in the future?\n>>>> \n>>>> I\'m saying that you can avoid race conditions by a combination of\n>>>> \'subscribe to changes\' + \'give me the full state\'.\n>>> \n>>> Like this?\n>>> https://review.openstack.org/#/c/61057/\n>>> This patch is just to confirm the idea.\n>> \n>> I\'m afraid the proposed patch is no more reliable than the current approach of using file-based locking.   I am working on an alternate patch that puts the rpc event loop in the dhcp agent so that better coordination between full synchronization and notification handling is possible.  This approach has already been taken with the L3 agent and work on the L2 agent is in process.  \n> \n> You objected against agent polling in the discussion.\n> But you\'re now proposing polling now. Did you change your mind?\n\nUh, no.  I\'m proposing better coordination between notification processing and full state synchronization beyond simple exclusionary primitives  (utils.synchronize etc).  I apologize if my language was unclear.  \n\n\nm.\n\n','<20131210233953.GA26201@private.email.ne.jp>',NULL),('<1290076849.45.1378620747345.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-08 06:12:27',0,'2013-09-08 06:12:27',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #20','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/20/>\n\n\n\n','<1301036426.42.1378534333809.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1290414993.177.1364537033879.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-29 06:03:53',0,'2013-03-29 06:03:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #179','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/179/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson865184357321776776.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.uvVbkIEcA0\n+ TMPDIR=/tmp/tmp.uvVbkIEcA0\n+ trap \'rm -rf /tmp/tmp.uvVbkIEcA0\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.11 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.37    RoleAPITests.test_get_default_role\n    0.28    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.688s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==1.1.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.12.0\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.uvVbkIEcA0\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/179\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/179/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/179/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<461136114.163.1364450646452.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1290430765.7667410.1396066136114.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-29 00:08:56',-14400,'2014-03-29 04:08:56',NULL,'[openstack-dev] [Openstack-docs] [cinder] recover Sheepdog\n	documentation','\n\n----- Original Message -----\n> On 28/03/14 14:00, Takazawa Shiori wrote:\n> > Hello\n> >\n> >\n> > I would like to add document abount Sheepdogfor Commodity Storage Back-end\n> > Technologies.  Will this work for users?\n> >\n> >\n> > http://docs.openstack.org/trunk/openstack-ops/content/storage_decision.html\n> >\n> >\n> > In previous documentation Sheepdog was included. But in current version,\n> > dropped out.\n> >\n> > Do you know the reason?\n> >\n> > http://dream.daynight.jp/openstack/openstack-ops/content/storage_decision.html\n> >\n> > (Sorry only found japanese version)\n> >\n> >\n> > Sheepdog is distributed storage system and can be used from Cinder, Glance\n> > and Swift.\n> >\n> > It is introduced Openstack Summit in 2013 at Honk Kong.\n> >\n> > http://sheepdog.github.io/sheepdog/_static/sheepdog-openstack.pdf\n> >\n> \n> Hmm, I don\'t see sheepdog on\n> https://wiki.openstack.org/wiki/CinderSupportMatrix\n> \n> I wonder why that is?\n> \n> Regards,\n> \n> \n> Tom\n\nNot sure, it appears to be in tree?\n\nSteve\n\n\n','<53353A0C.5090009@openstack.org>',NULL),('<1290430765.7667410.1396066136114.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-29 00:08:56',-14400,'2014-03-29 04:08:56',NULL,'[Openstack-docs] [cinder] recover Sheepdog documentation','\n\n----- Original Message -----\n> On 28/03/14 14:00, Takazawa Shiori wrote:\n> > Hello\n> >\n> >\n> > I would like to add document abount Sheepdogfor Commodity Storage Back-end\n> > Technologies.  Will this work for users?\n> >\n> >\n> > http://docs.openstack.org/trunk/openstack-ops/content/storage_decision.html\n> >\n> >\n> > In previous documentation Sheepdog was included. But in current version,\n> > dropped out.\n> >\n> > Do you know the reason?\n> >\n> > http://dream.daynight.jp/openstack/openstack-ops/content/storage_decision.html\n> >\n> > (Sorry only found japanese version)\n> >\n> >\n> > Sheepdog is distributed storage system and can be used from Cinder, Glance\n> > and Swift.\n> >\n> > It is introduced Openstack Summit in 2013 at Honk Kong.\n> >\n> > http://sheepdog.github.io/sheepdog/_static/sheepdog-openstack.pdf\n> >\n> \n> Hmm, I don\'t see sheepdog on\n> https://wiki.openstack.org/wiki/CinderSupportMatrix\n> \n> I wonder why that is?\n> \n> Regards,\n> \n> \n> Tom\n\nNot sure, it appears to be in tree?\n\nSteve\n\n\n','<53353A0C.5090009@openstack.org>',NULL),('<1291173495.23500034.1370979047261.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 15:30:47',-14400,'2013-06-11 19:30:47',NULL,'[openstack-qa] Tempest CPU usuage','Tempest\'s CPU usage is not real concern even with multiple processes.\nThe processor mostly consumed by the other processes.\n\nThe thing still doable on python level, is event based I/O (select,epoll,libevent, ..) \n on single thread with multiple connections,\n it can mitigate the number of context switches.\n\n- This is not doable in a regular unit test framework\n- Not necessarily all library provides good support for this.\n- Tempest normal usage is far from the level, when it really makes sense.\n- We lose more CPU power because of other things\n\n\n\n','<756402581.23463464.1370978470805.JavaMail.root@redhat.com>',NULL),('<1291531B-E100-46EB-8D5F-F61E19E590A2@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-10-22 09:28:05',-14400,'2014-10-22 13:28:05',NULL,'[openstack-tc] Topics for the Board/TC joint meeting in Paris','On Oct 22, 2014, at 5:09 AM, Thierry Carrez <thierry at openstack.org> wrote:\n\n> Hey members of the TC,\n> \n> As you know we\'ll have a joint Board/TC meeting in the afternoon of\n> Sunday, November 2 in Paris. Is there any specific topic you\'d like to\n> see discussed there ?\n\nDoes it make sense to ask for a short update on the DefCore situation? My impression is that the committee is adopting a multi-mark approach with some sort of tiering, but I haven?t had time to catch up on that. I see that on the Board meeting agenda too, though, and I?m not sure we want everyone on the board to have to sit through it twice.\n\nAre there any updates on the CLA issue to talk about?\n\nDoug\n\n\n\n','<5447743D.7000003@openstack.org>',NULL),('<1291779766.10538163.1421269761582.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 16:09:21',-18000,'2015-01-14 21:09:21',NULL,'[openstack-dev] [Telco] [NFV]\n [neutron][advancedservices][group-based-policy] Service function chaining','----- Original Message -----\n> From: \"Zhipeng Huang\" <zhipengh512 at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> \n> Hi Yuriy,\n> \n> FYI there is a project proposal on opnfv wiki on this issue:\n> https://wiki.opnfv.org/requirements_projects/openstack_based_vnf_forwarding_graph\n\nHi Zhipeng,\n\nThe OPNFV project page you linked mentions that it is dependent on current development work for Policy Based Specification of Service Chaining [1] and Service Instance Registration & Integration [2] \"targeted at the OpenStack Kilo release\". I\'m assuming this is in the context of the group-based-policy project - is anyone from the OPNFV side interacting with the project directly with a view to working on this?\n\nThanks,\n\nSteve\n\n[1] https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining\n[2] https://blueprints.launchpad.net/group-based-policy/+spec/service-registration-and-integration\n\n> On Wed, Jan 7, 2015 at 12:22 AM, <Yuriy.Babenko at telekom.de> wrote:\n> \n> > Hi all,\n> >\n> > as discussed per last IRC meeting we prepared first thoughts on the\n> > requirements on Service Function Chaining (SFC) and relevant use-case.\n> >\n> > We have an etherpad for initial draft ideas. Later on we should move it to\n> > wiki.\n> >\n> > All comments are very welcome.\n> >\n> > https://etherpad.openstack.org/p/kKIqu2ipN6\n> >\n> > Best,\n> > Yuriy\n> > Deutsche Telekom\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> \n> --\n> Zhipeng (Howard) Huang\n> \n> Standard Engineer\n> IT Standard & Patent/IT Prooduct Line\n> Huawei Technologies Co,. Ltd\n> Email: huangzhipeng at huawei.com\n> Office: Huawei Industrial Base, Longgang, Shenzhen\n> \n> (Previous)\n> Research Assistant\n> Mobile Ad-Hoc Network Lab, Calit2\n> University of California, Irvine\n> Email: zhipengh at uci.edu\n> Office: Calit2 Building Room 2402\n> \n> OpenStack, OpenDaylight, OpenCompute affcienado\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<CAHZqm+V0OeERhMVJ6554VGY5k6ymGxi1MQS94pX1iypedOgOXQ@mail.gmail.com>',NULL),('<1292270246.22065811.1385418308652.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 17:25:08',-18000,'2013-11-25 22:25:08',NULL,'[openstack-dev] [Keystone][Marconi][Oslo] Discoverable home\n document for APIs (Was: Re: [Nova][Glance] Support of v1 and v2 glance APIs\n in Nova)','To most of your questions i don\'t know the answer as the format was in place before i started with the project. I know that it is similar (though not exactly the same) as nova\'s but not where they are documented (as they are version independent)\n\nI can tell you it looks like: \n\n{\n  \"versions\": {\n    \"values\": [\n      {\n        \"status\": \"stable\",\n        \"updated\": \"2013-03-06T00:00:00Z\",\n        \"media-types\": [\n          {\n            \"base\": \"application\\/json\",\n            \"type\": \"application\\/vnd.openstack.identity-v3+json\"\n          },\n          {\n            \"base\": \"application\\/xml\",\n            \"type\": \"application\\/vnd.openstack.identity-v3+xml\"\n          }\n        ],\n        \"id\": \"v3.0\",\n        \"links\": [\n          {\n            \"href\": \"http:\\/\\/localhost:5000\\/v3\\/\",\n            \"rel\": \"self\"\n          }\n        ]\n      },\n      {\n        \"status\": \"stable\",\n        \"updated\": \"2013-03-06T00:00:00Z\",\n        \"media-types\": [\n          {\n            \"base\": \"application\\/json\",\n            \"type\": \"application\\/vnd.openstack.identity-v2.0+json\"\n          },\n          {\n            \"base\": \"application\\/xml\",\n            \"type\": \"application\\/vnd.openstack.identity-v2.0+xml\"\n          }\n        ],\n        \"id\": \"v2.0\",\n        \"links\": [\n          {\n            \"href\": \"http:\\/\\/localhost:5000\\/v2.0\\/\",\n            \"rel\": \"self\"\n          },\n          {\n            \"href\": \"http:\\/\\/docs.openstack.org\\/api\\/openstack-identity-service\\/2.0\\/content\\/\",\n            \"type\": \"text\\/html\",\n            \"rel\": \"describedby\"\n          },\n          {\n            \"href\": \"http:\\/\\/docs.openstack.org\\/api\\/openstack-identity-service\\/2.0\\/identity-dev-guide-2.0.pdf\",\n            \"type\": \"application\\/pdf\",\n            \"rel\": \"describedby\"\n          }\n        ]\n      }\n    ]\n  }\n}\n\n----- Original Message -----\n> From: \"Flavio Percoco\" <flavio at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, 25 November, 2013 6:41:42 PM\n> Subject: [openstack-dev] [Keystone][Marconi][Oslo] Discoverable home document for APIs (Was: Re: [Nova][Glance]\n> Support of v1 and v2 glance APIs in Nova)\n> \n> On 25/11/13 09:28 +1000, Jamie Lennox wrote:\n> >So the way we have this in keystone at least is that querying GET / will\n> >return all available API versions and querying /v2.0 for example is a\n> >similar result with just the v2 endpoint. So you can hard pin a version\n> >by using the versioned URL.\n> >\n> >I spoke to somebody the other day about the discovery process in\n> >services. The long term goal should be that the service catalog contains\n> >unversioned endpoints and that all clients should do discovery. For\n> >keystone the review has been underway for a while now:\n> >https://review.openstack.org/#/c/38414/ the basics of this should be\n> >able to be moved into OSLO for other projects if required.\n> \n> Did you guys create your own \'home document\' language? or did you base\n> it on some existing format? Is it documented somewhere? IIRC, there\'s\n> a thread where part of this was discussed, it was related to horizon.\n> \n> I\'m curious to know what you guys did and if you knew about\n> JSON-Home[0] when you started working on this.\n> \n> We used json-home for Marconi v1 and we\'d want the client to work in a\n> \'follow your nose\' way. Since, I\'d prefer OpenStack modules to use the\n> same language for this, I\'m curious to know why - if so - you\n> created your own spec, what are the benefits and if it\'s documented\n> somewhere.\n> \n> Cheers,\n> FF\n> \n> [0] http://tools.ietf.org/html/draft-nottingham-json-home-02\n> \n> --\n> @flaper87\n> Flavio Percoco\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20131125084142.GB21312@redhat.com>',NULL),('<1292271667.13254820.1384960145465.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 15:09:05',0,'2013-11-20 15:09:05',NULL,'[openstack-dev] [horizon] Enhance UX of Launch Instance Form','Thanks for all the feedback on the \"Enhance UX of launch instance form\" subject and its prototype.\n\nTry the latest version of the prototype:\nhttp://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance\n\nThis update was made after several discussion on those different channels:\n\n- openstack ux google group\n- launchpad horizon (and now launchpad openstack ux)\n- mailing list and IRC\n- the new ask bots for openstack UX\n\nWe tried to write back most of discussions on ask bot, and are now focusing on this tool.\n\nBelow a \"digest\" of those discussions, with links to ask bot (on each subject, there are links to related blueprints, google doc drafts, etc)\n\n= General topics =\n\n- Modals and supporting different screen sizes [2]\n  Current modal doesn\'t work well on the top 8 screen resolutions [2]\n  => Responsive and full screen modal added on the prototype [1]\n\n- Wizard mode for some modals [3]\n  => try the wizard [1]\n\n= Specific to \"launch instance\" =\n\n- Improve \"boot source\" options [4]\n  * first choose to boot from ephemeral or persistent disk\n  * if no ephemeral flavor are available, hide the selector\n  * group by \"public\", \"project\", \"shared with me\"\n  * warning message added for \"delete on terminate\" option (when boot from persistent)\n\n- Scaling the flavor list [5]\n  * sort the columns of the table. In particular: by name.\n  * group of flavor list (for example: \"performance\", \"standard\"...)?\n\n- Scaling the image list [5]\n  * a scrollbar on the image list\n  * limit the number of list items and add a \"x more instance snapshots - See more\" line\n  * a search / filter feature would be great, like discussed at the \"scaling horizon\" design session\n\n- Step 1 / Step 2 workflow: when the user click on \"select\" from one boot source item it goes directly to the step 2.\n  If it goes back from step 2 to step 1:\n  * the text \"Please select a boot source\" would be replaced with a \"Next\" button\n  * the button \"select\" on the selected boot source item would be replaced with a check-mark (or equivalent).\n  * the user would still have the possibility to select another boot source\n\n- flavor depending on image requirements and quotas available: \n   * this a very good point, lot of things to discuss about\n   => should open a separate thread on this\n \n- Network: still a work in progress\n  * if a single choice: then make it default choice\n\n- Several wording updates (\"cancel\", \"ephemeral boot source\", ...)\n\n[1] http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance\n[2] http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/\n[3] http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow\n[4] http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/\n[5] http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/\n\nBest,\n\nC?dric\n\n> Oct 11 17:11:26 UTC 2013, Jesse Pretorius <jesse.pretorius at gmail.com>  wrote:\n>\n> +1\n> \n> A few comments:\n> \n> 1. Bear in mind that sometimes a user may not have access to any Ephemeral\n> flavors, so the tabbing should ideally be adaptive. An alternative would\n> not to bother with the tabs and just show a flavor list. In our deployment\n> we have no flavors with ephemeral disk space larger than 0.\n> 2. Whenever there\'s a selection, but only one choice, make it a default\n> choice. It\'s tedious to choose the only selection only because you have to.\n> It\'s common for our users to have one network/subnet defined, but the\n> current UI requires them to switch tabs and select the network which is\n> rather tedious.\n> 3. The selection of the flavor is divorced from the quota available and\n> from the image requirements. Ideally those two items should somehow be\n> incorporated. A user needs to know up-front that the server will build> \n> based on both their quota and the image minimum requirements.\n> 4. We\'d like to see options for sorting on items like flavors. Currently\n> the sort is by \'id\' and we\'d like to see an option to sort by name\n> alphabetically.\n> \n> \n> \n> On 11 October 2013 18:53, C?dric Soulas <cedric.soulas at cloudwatt.com> wrote:\n> \n> > Hi,\n> >\n> > I just started a draft with suggestions to enhance the UX of the \"Launch\n> > Instance\" form:\n> >\n> > https://docs.google.com/document/d/1hUdmyxpVxbYwgGtPbzDsBUXsv0_rtKbfgCHYxOgFjlo\n> >\n> > Try the live prototype:\n> > http://cedricss.github.io/openstack-dashboard-ux-blueprints/launch-instance\n> >\n> > Best,\n> >\n> > C?dric\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1439960956.145219.1381935810026.JavaMail.root@cloudwatt.com>',NULL),('<1293087949.21.1374386757797.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-21 06:05:57',0,'2013-07-21 06:05:57',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-ceilometer-docs-stable-grizzly #102','See <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/102/>\n\n\n\n',NULL,NULL),('<1294300487.9740491.1415724965102.JavaMail.zimbra@zmail14.collab.prod.int.phx2.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-11 11:56:05',-18000,'2014-11-11 16:56:05',NULL,'[openstack-dev] [neutron] Neutron mid-cycle announcement','+1 would be great to at least have a hangout going\n\n\n\n_sent from my mobile device, sorry for spacing/spelling/top-posting/.*_\n\n\n-----Original Message-----\nFrom: Kyle Mestery [mestery at mestery.com]\nReceived: Tuesday, 11 Nov 2014, 16:14\nTo: OpenStack Development Mailing List (not for usage questions) [openstack-dev at lists.openstack.org]\nSubject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement\n\nOn Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton <gkotton at vmware.com> wrote:\n> Hi,\n> For those unable to attend will there be an option of remote access?\n> Thanks\n> Gary\n>\nWe\'ll do our best to make this happen. I\'ll see if we can get a Google\nHangout going in the room, and make sure people are on IRC.\n\nThanks!\nKyle\n\n> On 11/11/14, 3:04 PM, \"Kyle Mestery\" <mestery at mestery.com> wrote:\n>\n>>Hi folks:\n>>\n>>Apologies for the delay in announcing the Neutron mid-cycle, but I was\n>>confirming the details up until last night. I\'ve captured the details\n>>on an etherpad here [1]. The dates are December 8-10\n>>(Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,\n>>USA.\n>>\n>>We\'re still collecting information on hotels which should be on the\n>>etherpad later today.\n>>\n>>Thanks, looking forward to seeing everyone I missed in Paris!\n>>Kyle\n>>\n>>[1] https://etherpad.openstack.org/p/neutron-kilo-midcycle\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141111/7a69833f/attachment.html>\n\n','<CAL3VkVyXRn7cvp0YKDNN=-APfFeuXrs-0B_eYgW3ka_Zir6PFg@mail.gmail.com>',NULL),('<1294492496.22.1380694539374.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-02 06:15:38',0,'2013-10-02 06:15:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #27','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 1173 lines...]\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_cache_middleware.TestImageCacheXattr.test_cache_middleware_transparent_v1\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 65, in test_cache_middleware_transparent_v1\n    body=image_data)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 100.91 secs:\n    27.84    TestScrubber.test_scrubber_app\n    22.30    TestScrubber.test_delayed_delete\n    18.08    TestBinGlanceCacheManage.test_queue\n    17.06    TestRootApi.test_version_configurations\n    15.64    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1101 tests in 751.806s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.27\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.7.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.9DeiSGgHEV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/27/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-2/27\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1294823910.2781463.1373558770878.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 12:06:10',-14400,'2013-07-11 16:06:10',NULL,'[openstack-dev] AMQP Version upgrade plans?','\n\n----- Original Message -----\n> On 07/08/2013 10:51 AM, Ted Ross wrote:\n> > If someone from the Qpid community were to work on integrating the new\n> > AMQP 1.0 technology into OpenStack, where would be the right place to\n> > start?  Would it be to add a new transport to oslo.messaging?\n> \n> I think so, yes.  oslo.messaging is new, but it will deprecate the\n> existing \'rpc\' library in oslo-incubator.  All projects will need to\n> move to oslo.messaging, so for something new I would focus efforts there.\n\nI think that one of the important points that Ted brought up is that AMQP 1.0 doesn\'t have the concepts of broker artifacts like exchanges etc.\n\nA recent change I proposed to the existing impl_qpid.py which focuses more on addressing and not exchanges is a very important first step to solve several issues: a recent qpidd leak issue, transitioning to AMQP 1.0 (addressing), and possible HA solutions.\n\nThis is an area I\'d really like to continue to help out in. I\'m back from some vacation and would like to get stuck in soon.\n\nWilliam\n  \n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51DADF8E.5030709@redhat.com>',NULL),('<1294908914.25.1371017549902.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-12 06:12:29',0,'2013-06-12 06:12:29',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #254','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/254/>\n\n\n\n','<1687494964.20.1370931177231.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1294B2FFA1D540489E37142D9B372BAB36CB40C8@SZXEMA510-MBS.china.huawei.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-27 01:59:44',0,'2014-11-27 01:59:44',NULL,'[openstack-dev] 答复:  [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force','My name is also on the etherpad, I\'d like to take part in these works. \n-----????-----\n???: marios [mailto:marios at redhat.com] \n????: 2014?11?19? 18:10\n???: openstack-dev at lists.openstack.org\n??: Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force\n\nOn 19/11/14 11:34, Rossella Sblendido wrote:\n> My name is also on the etherpad, I\'d like to work on improving RPC and \n> ovslib. I am willing to take care of the BP, if somebody else is \n> interested we can do it together.\n\nsure I can help - (let\'s sync up on irc to split out the sections and get an etherpad going which we can then just paste into a spec - we can just use the l3 one as a template?)\n\nthanks, marios\n\n> \n> cheers,\n> \n> Rossella\n> \n> \n> On 11/19/2014 12:01 AM, Kevin Benton wrote:\n>> My name is already on the etherpad in the RPC section, but I\'ll \n>> reiterate here that I\'m very interested in optimizing a lot of the \n>> expensive ongoing communication between the L2 agent and the server \n>> on the message bus.\n>>\n>> On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin <carl at ecbaldwin.net \n>> <mailto:carl at ecbaldwin.net>> wrote:\n>>\n>>     At the recent summit, we held a session about debt repayment in the\n>>     Neutron agents [1].  Some work was identified for the L2 agent.  We\n>>     had a discussion in the Neutron meeting today about bootstrapping that\n>>     work.\n>>\n>>     The first order of business will be to generate a blueprint\n>>     specification for the work similar, in purpose, to the one that is\n>>     under discussion for the L3 agent [3].  I personally am at or over\n>>     capacity for BP writing this cycle.  We need a volunteer to take this\n>>     on coordinating with others who have been identified on the etherpad\n>>     for L2 agent work (you know who you are) and other volunteers who have\n>>     yet to be identified.\n>>\n>>     This \"task force\" will use the weekly Neutron meeting, the ML, and IRC\n>>     to coordinate efforts.  But first, we need to bootstrap the task\n>>     force.  If you plan to participate, please reply to this email and\n>>     describe how you will contribute, especially if you are willing to be\n>>     the lead author of a BP.  I will reconcile this with the etherpad to\n>>     see where gaps have been left.\n>>\n>>     I am planning to contribute as a core reviewer of blueprints and code\n>>     submissions only.\n>>\n>>     Carl\n>>\n>>     [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt\n>>     [2]\n>>     http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html\n>>     [3] https://review.openstack.org/#/c/131535/\n>>\n>>     _______________________________________________\n>>     OpenStack-dev mailing list\n>>     OpenStack-dev at lists.openstack.org\n>>     <mailto:OpenStack-dev at lists.openstack.org>\n>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>>\n>> --\n>> Kevin Benton\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<546C6C5E.403@redhat.com>',NULL),('<1295552120.66175949@192.168.4.58>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-01-20 14:35:20',-18000,'2011-01-20 19:35:20',NULL,'[Openstack-operators] Informations about OpenStack','On the nodes you mostly just need the nova-compute package and the same config file as on the primary controller.\n\nWhat specifically do you want to know about the architecture?\n\n-----Original Message-----\nFrom: \"CLABAUT, Emmanuel\" <e.st.clabaut at sqltechnologies.com>\nSent: Thursday, January 20, 2011 4:49am\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Informations about OpenStack\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\nHello,\n\nI\'am trying to set up OpenStack with one Cloud Controller and two Nodes.\nBut unfortunately, I don\'t really understand how to install OpenStack on the\nNodes. One the cloud controller I used the five minutes script.\nDoes anyone have some informations about how to set up the nodes ? And some\ninformation about the architecture of OpenStack ?\n\nThanks for your Help.\n\nEmmanuel Clabaut\n\n\n\n','<AANLkTin9H9jnVLCN8mOnMG7oWzDKhAN21R_75r_-n7hP@mail.gmail.com>',NULL),('<1295825312.6464701375718481161.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-08-05 16:01:21',0,'2013-08-05 16:01:21',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting August 6, 2013','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting August 6, 2013\nHost: Alan Clark\nDate: Tuesday, August 6, 2013\nTime: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 496 198 592\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=21410163&UID=63072083&HMAC=9636896c068c6af7546174443ed028b9081930bb&RT=MiM0\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=21410163&UID=63072083&HMAC=9636896c068c6af7546174443ed028b9081930bb&ORT=MiM0\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=21410163&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 496 198 592\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=21410163&EF=MA&UUID=63072083&RT=MiM0&SHA2=J6S7-TlNml-Mx7UwGnfD-63GD8RZc1rsnL9CK0mKi2s=\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130805/845554fa/attachment.html>\n\n',NULL,NULL),('<129589601.1629659.1419346725212.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-23 09:58:45',-18000,'2014-12-23 14:58:45',NULL,'[openstack-dev] [nova][libvirt]How to customize cpu features in\n nova','----- Original Message -----\n> From: \"CloudBeyond\" <cloudbeyond at gmail.com>\n> To: openstack-dev at lists.openstack.org\n> \n> Dear Developers,\n> \n> Sorry for interrupting if i sent to wrong email group, but i got a problem on\n> running Solaris 10 on icehouse openstack.\n>  I found it is need to disable CPU feature x2apic so that solaris 10 NIC\n> could work in KVM as following code in libvirt.xml\n> \n>   <cpu mode=\"custom\" match=\"exact\">\n>     <model>SandyBridge</model>\n>     <vendor>Intel</vendor>\n>     <feature policy=\'disable\' name=\'x2apic\'/>\n>   </cpu>\n> \n> if without line\n>   <feature policy=\'disable\' name=\'x2apic\'/>\n> the NIC in Solaris could not work well.\n> \n> And I try to migrate the KVM libvirt xml to Nova. I found only two options\n> to control the result.\n> \n> First I used default setting cpu_mdoe = None in nova.conf , the Solaris 10\n> would keep rebooting before enter desktop env.\n> \n> And then I set cpu_mode = custom, cpu_model = SandyBridge. Solaris 10 could\n> start up but NIC not work.\n> \n> I also set cpu_mode = host-model, cpu_model = None. Solaris 10 could work\n> but NIC not.\n> \n> I read the code located\n> in /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py. Is that\n> possible to do some hacking to customize the cpu feature?\n\nIt\'s possible though as you note requires modification of the driver, if you want to try and do this in a way that is compatible with other efforts to handle guest OS specific customizations you might want to review this proposal:\n\n    https://review.openstack.org/#/c/133945/4\n\n-Steve\n\n\n','<CADhZ1JfDpz=r0tra5hT+CGJTeFCoiaWj99BH79AMZqBHmURyEw@mail.gmail.com>',NULL),('<1295938584.26300631.1401906863982.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 14:34:23',-14400,'2014-06-04 18:34:23',NULL,'[openstack-dev] [nova] Proposal: Move CPU and memory allocation\n ratio out of scheduler','----- Original Message -----\n> From: \"ChangBo Guo\" <glongwave at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, June 3, 2014 10:40:19 PM\n> Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler\n> \n> Jay, thanks for raising this up .\n> +1 for this .\n>  A related question about the CPU and RAM allocation ratio, shall we apply\n> them when get hypervisor information with command \"nova hypervisor-show\n> ${hypervisor-name}\"\n> The output  shows like\n> | memory_mb                 |\n> 15824\n> |\n> | memory_mb_used            |\n> 1024\n> |\n> | running_vms               |\n> 1\n> |\n> | service_host              |\n> node-6\n> |\n> | service_id                |\n> 39\n> |\n> | vcpus                     |\n> 4\n> |\n> | vcpus_used                | 1\n> \n> vcpus is showing the number of physical CPU, I think that\'s not correct.\n> Any thoughts ?\n\nYes, this is a frequent source of confusion particularly as this ultimately ends up being reflected in the dashboard as vCPUS used/vCPUs available even though the available figure is based on pCPUs, not vCPUs (so no factoring in of overcommit). See also:\n\n    https://bugs.launchpad.net/nova/+bug/1202965\n\nThanks,\n\nSteve\n\n\n','<CANWmB0Wknh+PXnETdrRSviJg6A-N-jcAA3W7v9bZCFd+QAmsew@mail.gmail.com>',NULL),('<1296045690.4023.45.camel@ecsr7106.ecs.wmin.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-01-26 12:41:30',0,'2011-01-26 12:41:30',NULL,'[Openstack-operators] Which distro?','Hi all,\nI am about to construct a cloud infrastructure as part of an upcoming\nUniversity research project, funded by the Engineering and Physical\nSciences Research Council (EPSRC) here in the UK. I have the choice\nbetween Openstack Nova and Eucalyptus, and it is the former I\'m keen to\nuse.\n\nI would like some advice before I begin. I have found some docs\ndescribing installations of Nova using Ubuntu. Is this the prefered\nLinux distro? \n\nCheers\n\nChris\n\n\n-- \nThe University of Westminster is a charity and a company limited by\nguarantee.  Registration number: 977818 England.  Registered Office:\n309 Regent Street, London W1B 2UW, UK.\n\n',NULL,NULL),('<1296172584.245.1368339402727.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:16:42',0,'2013-05-12 06:16:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly-centos6 #12','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/12/>\n\n------------------------------------------\n[...truncated 1167 lines...]\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_reload\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/functional/test_bin_glance_control.py\",> line 223, in test_reload\n    self.get_versions()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/functional/test_bin_glance_control.py\",> line 39, in get_versions\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 90.78 secs:\n    26.41    TestScrubber.test_scrubber_app\n    20.85    TestScrubber.test_delayed_delete\n    14.94    TestRootApi.test_version_configurations\n    14.59    TestGlanceControl.test_respawn\n    14.00    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 1102 tests in 609.631s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.centos6.12\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.31\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.vyftjmj4Tf\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/12\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/12/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1296304200.228.1366351923537.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-19 06:12:03',0,'2013-04-19 06:12:03',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #200','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/200/>\n\n\n\n','<168265265.210.1366265511761.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1296654299.31.1352592302310.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-11 00:05:02',0,'2012-11-11 00:05:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-diablo #89','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/89/>\n\n------------------------------------------\n[...truncated 265 lines...]\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.05\n    test_get_image_details_marker_limit                          OK    0.08\n    test_get_image_details_sort_disk_format_asc                  OK    0.07\n    test_get_image_details_with_maximum_size                     OK    0.06\n    test_get_image_details_with_minimum_size                     OK    0.07\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.05\n    test_get_image_index_limit                                   OK    0.08\n    test_get_image_index_limit_None                              OK    0.07\n    test_get_image_index_marker                                  OK    0.08\n    test_get_image_index_marker_limit                            OK    0.08\n    test_get_image_members                                       OK    0.04\n    test_get_image_members_not_existing                          OK    0.05\n    test_get_image_non_existing                                  OK    0.05\n    test_get_index_sort_container_format_desc                    OK    0.07\n    test_get_index_sort_created_at_asc                           OK    0.20\n    test_get_index_sort_disk_format_asc                          OK    0.07\n    test_get_index_sort_id_desc                                  OK    0.07\n    test_get_index_sort_name_asc                                 OK    0.07\n    test_get_index_sort_size_asc                                 OK    0.07\n    test_get_index_sort_status_desc                              OK    0.07\n    test_get_index_sort_updated_at_desc                          OK    0.07\n    test_get_member_images                                       OK    0.05\n    test_replace_members                                         OK    0.04\n    test_update_image                                            OK    0.07\n    test_update_image_not_existing                               OK    0.05\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.01\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.01\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.21\n    test_version_control_existing_db                             OK    0.78\n    test_walk_versions                                           OK    0.81\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.00\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 39.63 secs:\n    11.62    TestScrubber.test_delayed_delete\n    9.05    TestBinGlance.test_results_filtering\n    7.14    TestBinGlance.test_results_pagination\n    6.36    TestBinGlance.test_results_sorting\n    5.45    TestBinGlance.test_add_list_update_list\n----------------------------------------------------------------------\nRan 338 tests in 102.107s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nimportlib==1.0.2\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\nordereddict==1.1\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.4\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-diablo/89\n[SCP] Copying console log.\n\n\n','<2088140081.18.1352505944348.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1296756017.63.1375769695458.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:14:55',0,'2013-08-06 06:14:55',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #312','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/312/>\n\n\n\n','<2013815517.49.1375682569439.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1296844271.18011.66.camel@ecsr7106.ecs.wmin.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-04 18:31:11',0,'2011-02-04 18:31:11',NULL,'[Openstack-operators] Networking nova.conf','Hi all,\nI have a question about the nova.conf settings. I basically have the\nCloud controller (and all storage components etc) on a single server\nwith two interfaces eth0 and eth1. The first, eth0 is assigned a public\nIP, whilst eth1 is a private IP network for my cloud. There is no\nrouting between the two.\n\nI\'m confused as to what to set the -rabbit_host, -s3_host\n-sql_connection -cc_host and -ec2_url IPs to. Should I set all of these\nto the external or internal interface IPs? At some point I need to have\nec2api connectivity arriving at the public IP, so I\'m guessing -ec2_url\nis more straight forward. But the rest?\n\nCheers\n\nChris\n\n\n-- \nThe University of Westminster is a charity and a company limited by\nguarantee.  Registration number: 977818 England.  Registered Office:\n309 Regent Street, London W1B 2UW, UK.\n\n',NULL,NULL),('<129728857.4516610.1421093163811.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-12 21:06:03',3600,'2015-01-12 20:06:03',NULL,'[openstack-dev] [nova] request spec freeze exception for virtio-net\n multiqueue','Hello,\n\nI\'d like to request an exception for virtio-net multiqueue feature. [1]\nThis is an important feature that aims to increase the total network throughput\nin guests and not too hard to implement.\n\nThanks,\nVladik\n\n[1] https://review.openstack.org/#/c/128825\n\n\n','<1363772922.4516536.1421092983061.JavaMail.zimbra@enovance.com>',NULL),('<1297383626.1.1377173525422.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-22 12:12:05',0,'2013-08-22 12:12:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #10','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/10/>\n\n------------------------------------------\n[...truncated 3739 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 385.56 secs:\n    162.31    Kc11TestCase.test_admin_requires_adminness\n    124.76    KcMasterTestCase.test_admin_requires_adminness\n    83.73    KcEssex3TestCase.test_admin_requires_adminness\n    7.60    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    7.15    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1300 tests in 863.078s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==2.0\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.10\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.xVMezo0x73\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/10/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-11/10\n[SCP] Copying console log.\n\n\n','<1860071105.17.1377065950311.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<129742596.24297259.1391618549860.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:42:29',-18000,'2014-02-05 16:42:29',NULL,'[openstack-dev] [Manila] Modularity of generic driver (network\n	mediated)','Hi,\n\nThe first prototype of the multi-tenant capable GlusterFS driver would piggyback on the generic driver, which implements the network plumbing model [1]. We\'d have NFS-Ganesha server running on the service VM. The Ganesha server would mediate access to the GlusterFS backend (or any other Ganesha compatible clustered file system backends such as CephFS, GPFS, among others), while the tenant network isolation would be done by the service VM networking [2][3]. To implement this idea, we\'d have to reuse much of the generic driver code especially that related to the service VM networking.\n\nSo we were wondering whether the current generic driver can be made more modular? The service VM could not just be used to expose a formatted cinder volume, but instead be used as an instrument to convert the existing single tenant drivers (with slight modification) - LVM, GlusterFS - to a multi-tenant ready driver. Do you see any issues with this thought - generic driver, a modular multi-tenant driver that implements the network plumbing model? And is this idea feasible?\n\n\n[1] https://wiki.openstack.org/wiki/Manila_Networking\n[2] https://docs.google.com/document/d/1WBjOq0GiejCcM1XKo7EmRBkOdfe4f5IU_Hw1ImPmDRU/edit\n[3] https://docs.google.com/a/mirantis.com/drawings/d/1Fw9RPUxUCh42VNk0smQiyCW2HGOGwxeWtdVHBB5J1Rw/edit\n\nThanks,\n\nRam\n\n\n','<1820370886.24277102.1391617571679.JavaMail.root@redhat.com>',NULL),('<1297536531.44552218.1377781502891.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 06:05:02',-25200,'2013-08-29 13:05:02',NULL,'[Openstack] Instances running on VMware ESXi are unable\n	to	configure IP','I don\'t know if this helps, but I\'m assuming you aren\'t running DHCP? If you\'re stuck without that, there\'s an IP pool feature in ESX that you might be able to use to mimic DHCP. I can\'t help you on the quantum configuration. Hope this is more help than confusing.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Rajshree Thorat\" <rajshree.thorat at gslab.com>\n> To: \"openstack Users\" <openstack at lists.openstack.org>, openstack at ask.openstack.org\n> Cc: \"virtualization-initiative\" <virtualization-initiative at gslab.com>\n> Sent: Thursday, August 29, 2013 8:38:26 AM\n> Subject: [Openstack] Instances running on VMware ESXi are unable to	configure IP\n> \n> Hi All,\n> \n> I have configured Openstack Grizzly to use ESXi 5.1 as hypervisor.\n> Creating/deleting instances from Openstack\n> works as expected, instances are created in ESXi ( Verified via vSphere\n> Client) and started ok.  The trouble is that\n> VMs are unable to configure internal IP.  Does quantum have a way to\n> reach vmware api to configure network.\n> Does quantum plugin for vmware/esx exist?\n> \n> What could be possible solution for this? Any help would be really\n> appreciated.\n> \n> Thanks in advance.\n> \n> Regards,\n> Rajshree\n> \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<521F40C2.90707@gslab.com>',NULL),('<1297582875.28.1378275566312.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:19:26',0,'2013-09-04 06:19:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-folsom #20','See <https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-folsom/20/>\n\n\n\n',NULL,NULL),('<1298136512.10608283.1400678460999.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 09:21:01',-14400,'2014-05-21 13:21:01',NULL,'[openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval\n - Can we kill it?','Dear Nova aficionados,\n\nPlease make sure I understand this correctly:\nEach nova compute instance selects a single VM out of all of the VMs\nthat it hosts, and every <heal_instance_info_cache_interval> seconds\nqueries Neutron for all of its networking information, then updates\nNova\'s DB.\n\nIf the information above is correct, then I fail to see how that\nis in anyway useful. For example, for a compute node hosting 20 VMs,\nit would take 20 minutes to update the last one. Seems unacceptable\nto me.\n\nConsidering Icehouse\'s Neutron to Nova notifications, my question\nis if we can change the default to 0 (Disable the feature), deprecate\nit, then delete it in the K cycle. Is there a good reason not to do this?\n\n\nAssaf Muller, Cloud Networking Engineer \nRed Hat \n\n\n','<1399755380.10567390.1400676433118.JavaMail.zimbra@redhat.com>',NULL),('<1298297064.478.1367130943811.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:35:43',0,'2013-04-28 06:35:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #24','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/24/>\n\n\n\n','<683258320.394.1367042870841.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1298445286.83.1383977556506.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-09 06:12:36',0,'2013-11-09 06:12:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #54','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/54/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47230d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47230d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47b3210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47b3210>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-4402f65f-2ac0-49bc-a2c8-19d77281b561\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:12:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:12:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:12:02+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:12:02-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:12:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5875890>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1b006d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 73.53 secs:\n    17.15    TestGlanceControl.test_bouncing\n    14.79    TestScrubber.test_delayed_delete\n    14.15    TestGlanceControl.test_reload\n    13.92    TestGlanceControl.test_respawn\n    13.52    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 598.998s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-54\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.hDJP8OZe3E\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/54\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/54/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-7/54\n[SCP] Copying console log.\n\n\n','<143861007.79.1383890965337.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1298650287.17087310.1375207988998.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-30 11:13:09',-25200,'2013-07-30 18:13:09',NULL,'[openstack-dev] [vmware] VMwareAPI sub-team status update 2013-07-30','I got this weeks report out a bit late this week because I spent the time I usually use for the task writing a Python script to help me manage this report. Sorry for the formatting it\'s a Work in Progress.\n\nYou should take notice that some abandoned patches are there because they had a single -1 vote and were neglected by the patch submitter for long enough. There is some good work that is could get lost if we don\'t circle back around on it. Havana-3 is looming on us, so let\'s try and salvage some of that work that was really close but not quite there yet.\n\nPersonally, I\'m dealing with a set of test failures that arose from another set of merges (yay! merges! I love it!) that only fail once my patch is over-laid on top of the new changes. So I\'m busy reworking that. I\'ve marked my own change \"work in progress\" while I\'m resolving that issue.\n\nI\'m now pulling how many votes are on a change, you\'ll notice some are quite popular and have as many as +10 votes from the vmwareapi subteam members and the community but are being down voted for some reason. If you\'re going to act on the down vote, perhaps you should put your patch in \"Work in Progress\" as well while you deal with the feed back? It makes it easier to understand whether you are ignoring the feedback (because you feel it is wrong) or if you are working on the feedback actively.\n\nSo, here\'s our fancy new stats:\n\n2013-07-30, Open: 8, Draft: 1, In Progress: 1, Merged: 2, Ready for core: 1\n\n\nNeeds one more core review/approval:\n* NEW, https://review.openstack.org/#/c/30822/ ,\n \'Fix VMwareVCDriver to support multi-datastore\'\n  https://bugs.launchpad.net/nova/+bug/1104994 \n  core votes,1, non-core votes,5, down votes, 0\n\nNeeds VMware API expert review:\n* NEW, https://review.openstack.org/#/c/33504/\n \'VMware: nova-compute crashes if VC not available\'\n https://bugs.launchpad.net/nova/+bug/1192016\n core votes,0, non-core votes,3, down votes, 0\n\n* NEW, https://review.openstack.org/#/c/30282/\n \'Multiple Clusters using single compute service\'\n https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service\n core votes,0, non-core votes,2, down votes, 0\n\n* NEW, https://review.openstack.org/#/c/37389/ \n \'VMware: Ensure Neutron networking works with VMware drivers\'\n  https://bugs.launchpad.net/nova/+bug/1202042\n  core votes,0, non-core votes,4, down votes, 0\n\nNeeds discussion/work (has -1):\n* NEW, https://review.openstack.org/#/c/30628/\n \'Fix VCDriver to pick the datastore that has capacity\'\n  https://bugs.launchpad.net/nova/+bug/1171930\n  core votes,0, non-core votes,5, down votes, -1\n\n* NEW, https://review.openstack.org/#/c/33100/ \n \'Fixes host stats for VMWareVCDriver\'\n  https://bugs.launchpad.net/nova/+bug/1190515 \n  core votes,1, non-core votes,10, down votes, -1\n\n* NEW, https://review.openstack.org/#/c/34685/ \n \'Fix VMware Hyper reports wrong type of hypervisor version.\'\n  https://bugs.launchpad.net/nova/+bug/1195139 \n  core votes,0, non-core votes,2, down votes, -3\n\nRecently Merged:\n* MERGED, https://review.openstack.org/#/c/36411/ \n  \'Use RetrievePropertiesEx instead of RetrieveProperties\'\n  https://bugs.launchpad.net/nova/+bug/1183654 \n  core votes,3, non-core votes,5, down votes, 0\n\n* MERGED, https://review.openstack.org/#/c/37539/ \n  \'Create vmware section\' \n  https://blueprints.launchpad.net/nova/+spec/vmware-configuration-section\n  core votes,3, non-core votes,3, down votes, 0\n\nWork in progress:\n* https://review.openstack.org/#/c/37819/ \n \'VMware image clone strategy settings and overrides\'\n  https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy\n  core votes,0, non-core votes,2, down votes, -1\n\nAbandoned work being tracked:\n* https://review.openstack.org/#/c/34189/ \n \'Added check for datastore state before selection\'\n  https://bugs.launchpad.net/nova/+bug/1194078\n  core votes,0, non-core votes,8, down votes, -1\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n\nHappy stacking!\n\n\n# Shawn Hartsock\n\n\n','<1937365898.17006682.1375205229248.JavaMail.root@vmware.com>',NULL),('<1299463601.226.1368252714453.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:11:54',0,'2013-05-11 06:11:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-quantum-stable-grizzly #37','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 20963 lines...]\n++ field=\'$3\'\n++ echo \'| private network             | 10.1.0.4                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.4\n+ die_if_not_set 133 IP \'Failure retrieving IP address\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ ping_check private 10.1.0.4 90\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n+ return 0\n+ _ping_check_quantum private 10.1.0.4 90\n+ local from_net=private\n+ local ip=10.1.0.4\n+ local timeout_sec=90\n+ local expected=True\n+ local check_command=\n++ _get_probe_cmd_prefix private\n++ local from_net=private\n+++ _get_net_id private\n+++ quantum --os-tenant-name admin --os-username admin --os-password secret net-list\n+++ awk \'{print $2}\'\n+++ grep private\n++ net_id=bb976e93-7d31-4a66-bc13-d409aa6f07b9\n+++ quantum-debug --os-tenant-name admin --os-username admin --os-password secret probe-list -c id -c network_id\n+++ head -n 1\n+++ awk \'{print $2}\'\n+++ grep bb976e93-7d31-4a66-bc13-d409aa6f07b9\n++ probe_id=c5d2b22c-5159-4827-b090-540bd965ecd1\n++ echo \'sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qprobe-c5d2b22c-5159-4827-b090-540bd965ecd1\'\n+ probe_cmd=\'sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qprobe-c5d2b22c-5159-4827-b090-540bd965ecd1\'\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qprobe-c5d2b22c-5159-4827-b090-540bd965ecd1 ping -w 1 -c 1 10.1.0.4; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! sudo /usr/local/bin/quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qprobe-c5d2b22c-5159-4827-b090-540bd965ecd1 ping -w 1 -c 1 10.1.0.4; do sleep 1; done\'\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.2 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.2 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n64 bytes from 10.1.0.4: icmp_req=1 ttl=64 time=121 ms\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 121.917/121.917/121.917/0.000 ms\n+ return\n++ cinder list\n++ head -1\n++ get_field 2\n++ read data\n++ grep ex-vol-fba9e95d\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1368252662\n+ cinder create --display_name ex-vol-fba9e95d --display_description \'test volume: ex-vol-fba9e95d\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                false                 |\n|      created_at     |      2013-05-11T06:11:03.430337      |\n| display_description |     test volume: ex-vol-fba9e95d     |\n|     display_name    |           ex-vol-fba9e95d            |\n|          id         | 3f459599-f5e1-4307-a808-5f5efb02da0e |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-fba9e95d | grep available; do sleep 1; done\'\n| 3f459599-f5e1-4307-a808-5f5efb02da0e | available | ex-vol-fba9e95d |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1368252665\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-fba9e95d\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 3f459599-f5e1-4307-a808-5f5efb02da0e | available | ex-vol-fba9e95d |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=3f459599-f5e1-4307-a808-5f5efb02da0e\n+ die_if_not_set 158 VOL_ID \'Failure retrieving volume ID for ex-vol-fba9e95d\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1368252666\n+ nova volume-attach 36ec376c-db6c-483b-a05b-2c5fbb09466c 3f459599-f5e1-4307-a808-5f5efb02da0e /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 36ec376c-db6c-483b-a05b-2c5fbb09466c |\n| id       | 3f459599-f5e1-4307-a808-5f5efb02da0e |\n| volumeId | 3f459599-f5e1-4307-a808-5f5efb02da0e |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-fba9e95d | grep in-use; do sleep 1; done\'\n| 3f459599-f5e1-4307-a808-5f5efb02da0e | in-use | ex-vol-fba9e95d |  1   |     None    |  false   | 36ec376c-db6c-483b-a05b-2c5fbb09466c |\n++ date +%s\n+ end_time=1368252671\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-fba9e95d\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 3f459599-f5e1-4307-a808-5f5efb02da0e | in-use | ex-vol-fba9e95d |  1   |     None    |  false   | 36ec376c-db6c-483b-a05b-2c5fbb09466c |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=36ec376c-db6c-483b-a05b-2c5fbb09466c\n+ die_if_not_set 172 VOL_ATTACH \'Failure retrieving ex-vol-fba9e95d status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 36ec376c-db6c-483b-a05b-2c5fbb09466c != 36ec376c-db6c-483b-a05b-2c5fbb09466c ]]\n++ date +%s\n+ start_time=1368252671\n+ nova volume-detach 36ec376c-db6c-483b-a05b-2c5fbb09466c 3f459599-f5e1-4307-a808-5f5efb02da0e\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-fba9e95d | grep available; do sleep 1; done\'\n| 3f459599-f5e1-4307-a808-5f5efb02da0e | available | ex-vol-fba9e95d |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1368252676\n+ echo \'Completed volume-detach in 5 seconds\'\nCompleted volume-detach in 5 seconds\n++ date +%s\n+ start_time=1368252676\n+ cinder delete 3f459599-f5e1-4307-a808-5f5efb02da0e\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-fba9e95d; do sleep 1; done\'\n| 3f459599-f5e1-4307-a808-5f5efb02da0e | deleting | ex-vol-fba9e95d |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1368252679\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 36ec376c-db6c-483b-a05b-2c5fbb09466c\n+ timeout 60 sh -c \'while nova list | grep -q 36ec376c-db6c-483b-a05b-2c5fbb09466c; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS quantum-adv-test\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nERROR: unknown environment \'smoke\'\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/rabbitmq/rabbit at devstack-1368243109-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/rabbitmq/rabbit at devstack-1368243109.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-q-l3.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-quantum-stable-grizzly/37/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1299903455.9145556.1372948409277.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-04 10:33:29',-14400,'2013-07-04 14:33:29',NULL,'[openstack-dev] [horizon] python-selenium is non-free,\n Horizon shouldn\'t use it','\"Matthias Runge\" <mrunge at redhat.com> wrote:\n> On 04/07/13 15:55, Daniel P. Berrange wrote:\n> > \n> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677\n> > \n> >   \"the package ships some files which are not yet built from source.\"\n> > \n> > Whether this is still accurate or not, is another matter, since that\n> > bz is 2 years old...\n> I remember that I filed a bug, because selenium shipped a binary web\n> driver adapter for firefox.\n> \n> E.g there are prebuilt files checked into seleniums svn:\n> http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/prebuilt/\n> which are/were required to build the whole thing.\n> \n> That was the point where I stopped packaging it for Fedora.\n\nThanks for the link Daniel, and Matthias for the extra information. I assume this is the same issue openSUSE has with the package (my google-fu is failing me for finding a bug).\n\nCheers,\n\nJulie\n\n\n','<51D5854C.9040203@redhat.com>',NULL),('<129bbbe9414364862dd0222c5b814719@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-16 19:23:38',7200,'2014-12-16 17:23:38',NULL,'[Openstack] Network speed issue','\n Hi all!\n\n In my OpenStack installation (Icehouse and use nova legacy networking) \n the VMs are talking to each other over a 1Gbps network link.\n\n My issue is that although file transfers between physical (hypervisor) \n nodes can saturate that link transfers between VMs reach very lower \n speeds e.g. 30MB/s (approx. 240Mbps).\n\n My tests are performed by scp\'ing a large image file (approx. 4GB) \n between the nodes and between the VMs.\n\n I have updated my images to use e1000 nic driver but the results remain \n the same.\n\n What are any other limiting factors?\n\n Does it has to do with the disk driver I am using? Does it play \n significant role the filesystem of the hypervisor node?\n\n Any ideas on how to approach the saturation of the 1Gbps link?\n\n\n Best regards,\n\n\n George\n\n\n',NULL,NULL),('<12A22F71-FA9E-4525-BECC-478926EF2DD6@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 11:50:57',-28800,'2013-01-23 19:50:57',NULL,'[openstack-dev] Booting Nova VMs with custom swap/ephemeral\n	devices ?','\nOn Jan 23, 2013, at 7:03 AM, Daniel P. Berrange <berrange at redhat.com> wrote:\n\n> On Wed, Jan 23, 2013 at 03:38:00PM +0100, Nikola ?ipanov wrote:\n>> On 23/01/13 13:14, Daniel P. Berrange wrote:\n>> \n>> Hey Daniel,\n>> \n>> So currently root_device_name is populated form the image properties see\n>> nova.compute.api.API._validate_and_provision_instance mostly this line:\n>> \n>> root_device_name = block_device.properties_root_device_name(\n>>                image.get(\'properties\', {}))\n>> \n>> and then nova.compute.manager._setup_block_device_mapping just gets it\n>> from the instance. So - it can be set on the image but not passed from\n>> the command line to boot.\n>> \n>> swap and ephemeral are taken in a similar way, but for details see\n>> nova.compute.api.API._populate_instance_for_bdm and\n>> _update_image_block_device_mapping methods.\n>> \n>> Please do correct me if I\'m wrong.\n>> \n>> I am working on enabling ephemerals and swap from the command line as\n>> well as part of\n>> https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling targeted\n>> for grizzly-3.\n> \n> Hmm, this seems to imply it is not currently possible to use the\n> features with nova CLI ?  If so, then I wonder why/how did this\n> functionality come to exist & be used in the first place ? Perhaps\n> there\'s a way to use it from the EC2 compatible CLI ?\n\nyes you can do it using euca-run-instances for example. It looks like we just left\nout some of the never-used params from the nova version.\n\n\nVish\n\n\n\n','<20130123150314.GU15923@redhat.com>',NULL),('<12ABB824-82C6-469A-9F15-4FC79D94E6D7@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 14:59:50',-18000,'2013-03-04 19:59:50',NULL,'[openstack-dev] Quantum PTL Candidacy','Hi-\n\nI\'m writing to announce my candidacy for the Quantum PTL.  The Quantum team has done a great job during the Grizzly cycle and I\'m excited about what\'s ahead for the Havana cycle.  My work at DreamHost provides me a unique perspective of deploying Quantum at scale using both IPv4 and IPv6.  Working for a deployer also reinforces my desire for a vibrant, multi-vendor ecosystem within Quantum. \n\nQualifications\n-------------------\n\nI am a Quantum core developer with 13 years of commercial Python development experience.  During my career, I have developed and deployed network applications based on the same underlying libraries as Quantum.  I started contributing to Quantum during the Essex development cycle.  In Folsom, I was promoted to core and was the primary developer of the DHCP implementation and Quantum\'s network namespace library. \n\nGrizzly Accomplishments\n----------------------------------\n\nIn the Grizzly cycle,  I worked both as a developer and a core team member.\n\nGrizzly Development:\n- Added Metadata Service Support to Quantum. (Quantum High Priority)\n- Developed database migration framework for Quantum to support all plugins. (Quantum Essential Priority)\n- Developed the LBaaS Agent Reference Implementation. (Quantum High Priority)\n- Added support for preserving NIC ordering when booting an instance attached to Quantum. (Nova High Priority Bug)\n\nGrizzly Core Team:\n- Second most active reviewer on the Quantum team.\n- Leader of the L3/IPAM/DHCP and Database sub teams.\n- Led triaging and sub-team assignment of bugs.\n- Assisted members of the community to further their understanding of Quantum and improve Python development best practices.\n- Interfaced with vendors new to Quantum and helped in the integration of their plugins.\n	(core reviewer on 4 of the new vendor plugins included with Grizzly)\n- Worked to promote Quantum by presenting at regional OpenStack Meetups in both Atlanta and Los Angeles.\n\n\nHavana\n-----------\n\nDuring the Havana development cycle, I\'d like to see the team focus on:\n\n- Continuing to grow the community of contributors and code reviewers.\n- Improving documentation for both deployers and developers.\n- Improving database resource modeling and extension management.\n- Collaborating with the Nova team to make Quantum the default network implementation.\n- Leveraging the service insertion framework to add new services (i.e. VPN).\n- Modularization of L2 and L3.\n- L3 improvements (ACLs, better IPv6, pluggable IPAM).\n- Integrating plugins from vendors new to the community including LBaaS plugins/drivers.\n- Further work to ease deploying at scale.\n- More efficient Quantum system testing and gating.\n- Supporting the Horizon team for better Quantum integration.\n\n\nI\'d love the chance to be the PTL and work with the Quantum team to fill in gaps in this list during the summit in Portland.\n\nThanks,\n\nmark\n\n',NULL,NULL),('<12B40C9E-EDCA-4A43-90F6-AC16112FED3A@adesso-mobile.de>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-09 13:51:54',0,'2013-08-09 13:51:54',NULL,'[Openstack] OpenStack without Floating IPs in Multi Host Setup','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130809/5fe1a618/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: banner_signatur_dmexco2013_625x77.jpg\nType: image/jpeg\nSize: 59351 bytes\nDesc: banner_signatur_dmexco2013_625x77.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130809/5fe1a618/attachment.jpg>\n\n','<CAO5CbpCc540DAshPBWS+8a8iz4Ta9UmTQE=7Vxy=bHC_hjgdpA@mail.gmail.com>',NULL),('<12b6bbfa12184bc9814cd7354bdc6db3@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 10:18:35',0,'2014-07-17 10:18:35',NULL,'[openstack-dev] [Neutron][CI] DB migration error','Hi Kevin-\n\nThe fix given in the bug report is not working for my CI. I think I need to wait for the real fix in the main stream.\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n\nFrom: Kevin Benton [mailto:blak111 at gmail.com]\nSent: Wednesday, July 16, 2014 10:01 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron][CI] DB migration error\n\n\nThis bug is also affecting Ryu and the Big Switch CI.\nThere is a patch to bump the version requirement for alembic linked in the bug report that should fix it. It we can\'t get that merged we may have to revert the healing patch.\n\nhttps://bugs.launchpad.net/bugs/1342507\nOn Jul 16, 2014 9:27 AM, \"trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>\" <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>> wrote:\nHi-\n\nWith the neutron Update to my CI, I get the following error while configuring Neutron in devstack.\n\n2014-07-16 16:12:06.349 | INFO  [alembic.autogenerate.compare] Detected server default on column \'poolmonitorassociations.status\'\n2014-07-16 16:12:06.411 | INFO  [neutron.db.migration.alembic_migrations.heal_script] Detected added foreign key for column \'id\' on table u\'ml2_brocadeports\'\n2014-07-16 16:12:14.853 | Traceback (most recent call last):\n2014-07-16 16:12:14.853 |   File \"/usr/local/bin/neutron-db-manage\", line 10, in <module>\n2014-07-16 16:12:14.853 |     sys.exit(main())\n2014-07-16 16:12:14.854 |   File \"/opt/stack/new/neutron/neutron/db/migration/cli.py\", line 171, in main\n2014-07-16 16:12:14.854 |     CONF.command.func(config, CONF.command.name<http://CONF.command.name>)\n2014-07-16 16:12:14.854 |   File \"/opt/stack/new/neutron/neutron/db/migration/cli.py\", line 85, in do_upgrade_downgrade\n2014-07-16 16:12:14.854 |     do_alembic_command(config, cmd, revision, sql=CONF.command.sql)\n2014-07-16 16:12:14.854 |   File \"/opt/stack/new/neutron/neutron/db/migration/cli.py\", line 63, in do_alembic_command\n2014-07-16 16:12:14.854 |     getattr(alembic_command, cmd)(config, *args, **kwargs)\n2014-07-16 16:12:14.854 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/command.py\", line 124, in upgrade\n2014-07-16 16:12:14.854 |     script.run_env()\n2014-07-16 16:12:14.854 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/script.py\", line 199, in run_env\n2014-07-16 16:12:14.854 |     util.load_python_file(self.dir, \'env.py\')\n2014-07-16 16:12:14.854 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/util.py\", line 205, in load_python_file\n2014-07-16 16:12:14.854 |     module = load_module_py(module_id, path)\n2014-07-16 16:12:14.854 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/compat.py\", line 58, in load_module_py\n2014-07-16 16:12:14.854 |     mod = imp.load_source(module_id, path, fp)\n2014-07-16 16:12:14.854 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py\", line 106, in <module>\n2014-07-16 16:12:14.854 |     run_migrations_online()\n2014-07-16 16:12:14.855 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py\", line 90, in run_migrations_online\n2014-07-16 16:12:14.855 |     options=build_options())\n2014-07-16 16:12:14.855 |   File \"<string>\", line 7, in run_migrations\n2014-07-16 16:12:14.855 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/environment.py\", line 681, in run_migrations\n2014-07-16 16:12:14.855 |     self.get_context().run_migrations(**kw)\n2014-07-16 16:12:14.855 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/migration.py\", line 225, in run_migrations\n2014-07-16 16:12:14.855 |     change(**kw)\n2014-07-16 16:12:14.856 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/versions/1d6ee1ae5da5_db_healing.py\", line 32, in upgrade\n2014-07-16 16:12:14.856 |     heal_script.heal()\n2014-07-16 16:12:14.856 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py\", line 78, in heal\n2014-07-16 16:12:14.856 |     execute_alembic_command(el)\n2014-07-16 16:12:14.856 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py\", line 93, in execute_alembic_command\n2014-07-16 16:12:14.856 |     parse_modify_command(command)\n2014-07-16 16:12:14.856 |   File \"/opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py\", line 126, in parse_modify_command\n2014-07-16 16:12:14.856 |     op.alter_column(table, column, **kwargs)\n2014-07-16 16:12:14.856 |   File \"<string>\", line 7, in alter_column\n2014-07-16 16:12:14.856 |   File \"<string>\", line 1, in <lambda>\n2014-07-16 16:12:14.856 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/util.py\", line 322, in go\n2014-07-16 16:12:14.857 |     return fn(*arg, **kw)\n2014-07-16 16:12:14.857 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/operations.py\", line 300, in alter_column\n2014-07-16 16:12:14.857 |     existing_autoincrement=existing_autoincrement\n2014-07-16 16:12:14.857 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py\", line 42, in alter_column\n2014-07-16 16:12:14.857 |     else existing_autoincrement\n2014-07-16 16:12:14.857 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py\", line 76, in _exec\n2014-07-16 16:12:14.857 |     conn.execute(construct, *multiparams, **params)\n2014-07-16 16:12:14.857 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 727, in execute\n2014-07-16 16:12:14.857 |     return meth(self, multiparams, params)\n2014-07-16 16:12:14.858 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py\", line 67, in _execute_on_connection\n2014-07-16 16:12:14.858 |     return connection._execute_ddl(self, multiparams, params)\n2014-07-16 16:12:14.858 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 775, in _execute_ddl\n2014-07-16 16:12:14.858 |     compiled = ddl.compile(dialect=dialect)\n2014-07-16 16:12:14.858 |   File \"<string>\", line 1, in <lambda>\n2014-07-16 16:12:14.858 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/elements.py\", line 493, in compile\n2014-07-16 16:12:14.859 |     return self._compiler(dialect, bind=bind, **kw)\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py\", line 25, in _compiler\n2014-07-16 16:12:14.859 |     return dialect.ddl_compiler(dialect, self, **kw)\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/compiler.py\", line 196, in __init__\n2014-07-16 16:12:14.859 |     self.string = self.process(self.statement, **compile_kwargs)\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/compiler.py\", line 219, in process\n2014-07-16 16:12:14.859 |     return obj._compiler_dispatch(self, **kwargs)\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/ext/compiler.py\", line 410, in <lambda>\n2014-07-16 16:12:14.859 |     lambda *arg, **kw: existing(*arg, **kw))\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/ext/compiler.py\", line 448, in __call__\n2014-07-16 16:12:14.859 |     return fn(element, compiler, **kw)\n2014-07-16 16:12:14.859 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py\", line 98, in _mysql_alter_column\n2014-07-16 16:12:14.860 |     autoincrement=element.autoincrement\n2014-07-16 16:12:14.860 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py\", line 118, in _mysql_colspec\n2014-07-16 16:12:14.860 |     spec += \" DEFAULT %s\" % _render_value(compiler, server_default)\n2014-07-16 16:12:14.860 |   File \"/usr/local/lib/python2.7/dist-packages/alembic/ddl/mysql.py\", line 106, in _render_value\n2014-07-16 16:12:14.860 |     return compiler.sql_compiler.process(expr)\n2014-07-16 16:12:14.860 |   File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/sql/compiler.py\", line 219, in process\n2014-07-16 16:12:14.860 |     return obj._compiler_dispatch(self, **kwargs)\n2014-07-16 16:12:14.860 | AttributeError: \'DefaultClause\' object has no attribute \'_compiler_dispatch\'\n\nKindly help how to resolve this issue.\n\nThanks in advance.\n\n\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> | extn: 4048\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/7de04ae3/attachment.html>\n\n','<CAO_F6JNQfbTHMUXBh7ZgxzN+PcGpcAj2yuay7PSyvTNcS8c1NA@mail.gmail.com>',NULL),('<12bd5be3829bb9c2ca3f405d95744aad@home.nemebean.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 13:30:16',-18000,'2013-06-17 18:30:16',NULL,'[openstack-dev] Nova list with all-tenants flag','Is there ever a situation where you would use tenant_id and not want \nall_tenants=1?  If there is then I can maybe see leaving it, but if \ntenant_id implies all_tenants=1 then IMHO it\'s rather poor to force the \nuser to remember to set it.\n\nTo be honest, as someone fairly new to OpenStack I found it very \nunintuitive that a request made as an admin user doesn\'t behave as \nthough it came from an admin unless an extra option is set.  By way of \nanalogy, I feel like this would be similar to if vim required you to do \n\"# vim --as-root some-file\" to edit a file as root.  I already \nauthenticated as root (or admin), why are you forcing me to reiterate \nthat I am?  If I don\'t want admin privileges I won\'t use an admin user.\n\n/my 2 cents\n\n-Ben\n\nOn 2013-06-17 12:12, Chris Behrens wrote:\n> The original intent behind \'all_tenants=1\' was whether or not to\n> include all instances for all tenants in the filtering process.\n> Basically it means \"Should I operate as admin or not?\". I still view\n> it this way, and would prefer it still mean this (although it might be\n> more clear with a different name).\n> \n> This means that if you\'re an admin? you\'re not treated as one UNTIL\n> you specify all_tenants=1. So technically I think specifying a\n> \'tenant_id\' filter should raise or do whatever it does for a normal\n> user. I don\'t think specifying a \'tenant_id\' filter should mean that\n> we automatically turn \'all_tenants\' on.\n> \n> I don\'t see the bug deal in needing to remember to use all_tenants=1\n> so that all instances will be filtered, not just the instances belong\n> to the admin user.\n> \n> My opinion,\n> \n> - Chris\n> \n> On Jun 16, 2013, at 11:09 PM, Aarti Mahesh Kriplani\n> <aarti.kriplani at RACKSPACE.COM> wrote:\n> \n>> Hello all,\n>> \n>> There have been a few contrasting views on this bug\n>> [1]<https://bugs.launchpad.net/nova/+bug/1185290 [1]>.\n>> I would really like some views on how we want to use the\n>> all-tenenats flag going ahead.\n>> Comments/Suggestions?\n>> \n>> Thanks,\n>> Aarti _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> Links:\n> ------\n> [1] https://bugs.launchpad.net/nova/+bug/1185290\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<379E28E1-733F-4833-9B3C-F38C9C9505FB@codestud.com>',NULL),('<12c33656fa472863640ef40451b1d0db@acmac.uoc.gr>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-20 14:41:01',7200,'2014-01-20 12:41:01',NULL,'[Openstack] Απάντ.:  [Quantum] Can\'t Ping Private/Public IP of CentOS Cloud Image 6.4 Instance in Grizlly',' Could you ellaborate a little bit more on this...\n\n What do you mean by saying that you have installed and created the \n image?\n Did you install it inside OpenStack? How did you create the image?\n\n Best,\n\n G.\n\n On Mon, 20 Jan 2014 11:02:15 +0800, jeffty wrote:\n> Hi Girogis,\n>\n> No available CentOS 6.5 cloud image found. I just downloaded the iso \n> and\n> installed and created the image. You can install cloud-init to create\n> your own cloud image.\n>\n>\n> On 1/20/2014 7:21 AM, giorgis at acmac.uoc.gr wrote:\n>> Could you tell us where did you find the CentOS 6.5 that worked?\n>>\n>> Best,\n>>\n>> G.\n>>\n>>\n>> ----- Reply message -----\n>> ???: \"jeffty\" <wantwatering at gmail.com>\n>> ????: \"???\" <stone_an at 163.com>\n>> ????.: <openstack at lists.openstack.org>\n>> ????: [Openstack] [Quantum] Can\'t Ping Private/Public IP of CentOS \n>> Cloud\n>> Image 6.4 Instance in Grizlly\n>> ??/???: ???, ??? 18, 2014 13:14\n>>\n>>\n>> Hi ???,\n>>\n>> Although this image is still not allowed to be ssh, I installed \n>> another\n>> CentOS 6.5 without cloud-init, get the public key from meta service \n>> and\n>> write to the authorized-keys, disabled the firewall rules and \n>> SELinux.\n>>\n>> Now I can SSH such instances.\n>>\n>> Thanks.\n>>\n>> On 1/10/2014 3:32 PM, ??? wrote:\n>>> Hey, Jeffty\n>>>\n>>> SSH-key login works for me.\n>>>\n>>> I\'m running Havana, and my OS is CentOS 6.4.\n>>>\n>>> Is the compute log complaining about error mounting the instance \n>>> disk or\n>>> error injecting key data?\n>>>\n>>> Best wishes!\n>>>\n>>> azq\n>>>\n>>>\n>>> ? 2014-01-10 12:20:03?jeffty <wantwatering at gmail.com> ???\n>>>>Thanks ???, that works!\n>>>>\n>>>>I can ssh it but only with the provided username and password.\n>>>>\n>>>>When ssh it shows \'Server refused our key\'.\n>>>>\n>>>>Which means we can\'t use the keypair for login?\n>>>>\n>>>>Thanks.\n>>>>\n>>>>On 1/10/2014 10:26 AM, ??? wrote:\n>>>>> i also tried that image, and couldn\'t ping it either ...\n>>>>>\n>>>>> edit the image and shutdown the firewall completely,\n>>>>> or try the centos 6.4 image from CatN lab, that one works.\n>>>>>\n>>>>> http://catn.com/labs/project/centos-images/\n>>>>>\n>>>>> good luck, have fun!\n>>>>>\n>>>>> azq\n>>>>>\n>>>>>\n>>>>> At 2014-01-10 00:39:12,jeffty <wantwatering at gmail.com> wrote:\n>>>>>>Hi,\n>>>>>>\n>>>>>>I\'m running Grizzly in two nodes. One controller and one compute \n>>>>>> node.\n>>>>>>\n>>>>>>I tested Cirros and Ubuntu instance. I can ping them with \n>>>>>> assigned\n>>>>>>public IP and SSH them. But for the CentOS cloud image downloaded \n>>>>>> from\n>>>>>>http://wiki.centos.org/Cloud/OpenNebula I failed.\n>>>>>>\n>>>>>>After assign public IP to CentOS instance it can\'t be \n>>>>>> reached(ping or\n>>>>>>ssh) by neither of private or public IP.\n>>>>>>\n>>>>>>After ssh in the Ubuntu/Cirros instance and try to ping the \n>>>>>> CentOS\n>>>>>>instance it still failed. But Ubuntu and Cirros instance \n>>>>>> succeeded to\n>>>>>>ping each other after ssh. And all these instances use the same \n>>>>>> security\n>>>>>>group.\n>>>>>>\n>>>>>>I found below know issue in OpenNubula:\n>>>>>>http://wiki.centos.org/Cloud/OpenNebula\n>>>>>>--------------------------------------------------------------------\n>>>>>>Known Issues\n>>>>>>\n>>>>>>Images are built with firewall turned on, with only ssh allowed \n>>>>>> to\n>>>>>>connected in. On a Cloud instance where the access is controlled \n>>>>>> via\n>>>>>>security and network policy, this might not be an ideal state.\n>>>>>>--------------------------------------------------------------------\n>>>>>>\n>>>>>>But now it\'s not only for ssh but also for ping. Is CentOS cloud \n>>>>>> image\n>>>>>>configured by reject all network access in its firewall rule? If \n>>>>>> so\n>>>>>>since it has no default root password how can we log in them?\n>>>>>>\n>>>>>>Thanks.\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to     : openstack at lists.openstack.org\n>>>>>>Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>\n>>>\n>>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-- \n\n\n','<52DC91B7.7090107@gmail.com>',NULL),('<12C3409B-6BB0-47F6-9A89-4D5A8137052E@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 22:36:22',-21600,'2014-10-16 04:36:22',NULL,'[openstack-dev] [Nova] Automatic evacuate','I\'ve been thinking a lot about these use cases too. As was previously suggested, I think a session in Paris in this topic would be immensely beneficial. Is there somewhere we can officially log a room or some such for further discussion?\n\n- Joe\n\n> On Oct 15, 2014, at 9:04 PM, Russell Bryant <rbryant at redhat.com> wrote:\n> \n>> On 10/15/2014 05:07 PM, Florian Haas wrote:\n>> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant <rbryant at redhat.com> wrote:\n>>>> Am I making sense?\n>>> \n>>> Yep, the downside is just that you need to provide a new set of flavors\n>>> for \"ha\" vs \"non-ha\".  A benefit though is that it\'s a way to support it\n>>> today without *any* changes to OpenStack.\n>> \n>> Users are already very used to defining new flavors. Nova itself\n>> wouldn\'t even need to define those; if the vendor\'s deployment tools\n>> defined them it would be just fine.\n> \n> Yes, I know Nova wouldn\'t need to define it.  I was saying I didn\'t like\n> that it was required at all.\n> \n>>> This seems like the kind of thing we should also figure out how to offer\n>>> on a per-guest basis without needing a new set of flavors.  That\'s why I\n>>> also listed the server tagging functionality as another possible solution.\n>> \n>> This still doesn\'t do away with the requirement to reliably detect\n>> node failure, and to fence misbehaving nodes. Detecting that a node\n>> has failed, and fencing it if unsure, is a prerequisite for any\n>> recovery action. So you need Corosync/Pacemaker anyway.\n> \n> Obviously, yes.  My post covered all of that directly ... the tagging\n> bit was just additional input into the recovery operation.\n> \n>> Note also that when using an approach where you have physically\n>> clustered nodes, but you are also running non-HA VMs on those, then\n>> the user must understand that the following applies:\n>> \n>> (1) If your guest is marked HA, then it will automatically recover on\n>> node failure, but\n>> (2) if your guest is *not* marked HA, then it will go down with the\n>> node not only if it fails, but also if it is fenced.\n>> \n>> So a non-HA guest on an HA node group actually has a slightly\n>> *greater* chance of going down than a non-HA guest on a non-HA host.\n>> (And let\'s not get into \"don\'t use fencing then\"; we all know why\n>> that\'s a bad idea.)\n>> \n>> Which is why I think it makes sense to just distinguish between\n>> HA-capable and non-HA-capable hosts, and have the user decide whether\n>> they want HA or non-HA guests simply by assigning them to the\n>> appropriate host aggregates.\n> \n> Very good point.  I hadn\'t considered that.\n> \n> -- \n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<543F35AC.4040901@redhat.com>',NULL),('<12C4262B-FC1E-4B88-8F6A-0C68CB50EB46@me.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 06:43:53',-28800,'2014-03-06 14:43:53',NULL,'[Openstack] swift recon query','The \'-a\' argument to swift-recon is for looking at the async-pendings, \nwhich will only be available if you\'ve set up the \n/usr/bin/swift-recon-cron job on the object server nodes.\n\nTry running with the \'-d\' or \'-l\' arguments to see some actual \nstatistics.\n\n-- \nSteve Mayer\nsmayer69 at me.com\n\nOn 6 Mar 2014, at 2:31, Drudy, Gerry wrote:\n\n> Add the verbose option to swift-recon:\n>\n> swift-recon -av\n>\n> It will list all the object servers in the ring.  Each server listed \n> should have the object-server process running.\n>\n> Gerry.\n>\n> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n> Sent: 06 March 2014 10:25\n> To: Drudy, Gerry; openstack at lists.openstack.org\n> Subject: Re: [Openstack] swift recon query\n>\n> hi Gerry,\n>\n> I run following commands:\n> root at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/async\n> curl: (7) couldn\'t connect to host\n> root at swift-VirtualBox:~# swift-recon -a\n> ===============================================================================\n> --> Starting reconnaissance on 4 hosts\n> ===============================================================================\n> [2014-03-06 15:51:14] Checking async pendings\n> [async_pending] - No hosts returned valid data.\n> ===============================================================================\n> I can\'t understand where is the problem\n>\n> Please help.\n>\n> Thanks\n> Pragya jain\n>\n> On Thursday, 6 March 2014 2:38 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> \n> wrote:\n> Try\n>\n> curl  -i http://127.0.0.1:6000/recon/async\n>\n> assuming 6000 is the port the object-server binds to.\n>\n> Gerry,\n>\n> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n> Sent: 06 March 2014 06:58\n> To: openstack at lists.openstack.org\n> Subject: Re: [Openstack] swift recon query\n>\n> please somebody answer my questions related to swift recon.\n>\n> Thanks\n>\n> Pragya Jain\n>\n> On Wednesday, 5 March 2014 2:31 PM, pragya jain \n> <prag_2648 at yahoo.co.in> wrote:\n> hello all,\n>\n> I have some basic questions about swift recon. please query them.\n>\n> Q1: what should be the curl command for recon?\n>\n> I use the following commands:\n> 1.  root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>\n> HTTP/1.1 401 Unauthorized\n> Content-Length: 131\n> Content-Type: text/html; charset=UTF-8\n> Www-Authenticate: Swift realm=\"async\"\n> X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n> Date: Wed, 05 Mar 2014 08:43:17 GMT\n>\n> <html><h1>Unauthorized</h1><p>This server could not verify that you \n> are authorized to access the document you requested.</p></html>\n>\n> 2.  root at swift-VirtualBox:~# curl -i \n> http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>\n> HTTP/1.1 401 Unauthorized\n> Content-Length: 131\n> Content-Type: text/html; charset=UTF-8\n> Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n> X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n> Date: Wed, 05 Mar 2014 08:45:24 GMT\n>\n> <html><h1>Unauthorized</h1><p>This server could not verify that you \n> are authorized to access the document you requested.</p></html>\n>\n> Q2. Does \'swift-recon\' command not provide the status about\n>                     (i)      /proc/meminfo,\n>                     (ii)     currently mounted file systems\n>                     (iii)    list of devices\n>    if \'swift-recon\' provides these informations, then what should be \n> the command?\n>\n> Q3. It stands for what?\n>          low\n>          high\n>          avg\n>          total\n>          failed\n>          no_result\n>          reported\n>\n> Pragya Jain\n>\n>\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<923E0D692F901442ACBA7199520F3D4625302106@G4W3226.americas.hpqcorp.net>',NULL),('<12C94131-5613-49AC-A307-DA9356615142@enovance.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-06 03:01:02',3600,'2013-12-06 02:01:02',NULL,'[Openstack] Regarding Openstack upgrade for havana onwards','On 06 Dec 2013, at 01:35, Sumit Gaur <sumitkgaur at gmail.com> wrote:\n\n> Hi ,\n> I am a openstack user and I had faced a lot of problems in upgrading\n> my environment to newer versions of openstack releases. I need to know\n> if Openstack dev team is working on *smooth upgrade* process of\n> further release ? I know there are process doc available but process\n> itself is very difficult.\n> \n> Can we start looking into this direction as it is a major pain point\n> and show stopper for openstack users so far. *Please let me know any\n> pointers in this directions*.\n> \n> Thanks\n> sumit\n> Cloud administrator\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\nThe only automated upgrade I know of is Grenade[1]. You should check it out.\n\nThe upgrade process is going to be difficult no matter what, but you?ll find the\npeople thinking seriously about this problem in the Grenade project.\n\nHope this helps.\n\n---\nJoe H. Rahme\nIRC: rahmu\n\n\n [1]: https://wiki.openstack.org/wiki/Grenade\n\n\n','<CAH_rboqm3ZvdLqyr7yW0KGtB_trx-S0hRW2=XTG4os4-0btrVA@mail.gmail.com>',NULL),('<12CF5EEC0206B3nihongi.nobuyoshi@lab.ntt.co.jp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 21:03:15',32400,'2014-04-23 12:03:15',NULL,'[openstack-dev] [Ceilometer] having trouble with tox','Hi,\n\nI\'m having trouble with tox to run unit tests of Ceilometer.\n\nI run devstack on Ubuntu13.10 which is running as a Guest OS in \nVirtualBox.\nCeilometer commit id is e5b7606eaa94033256eb1aca5f6a6eed4f9e54a0.\nThe VM is connecting to the Internet via proxy server.\n\nI\'m using tox 1.6.1 instead of 1.7.1 to avoid bug [1].\nI didn\'t make any changes in tox.ini from default settings.\n\nI was following the instruction [2].\nWhen I typed the following command;\n$ tox -e py27,pep8\nI didn\'t get any response for more than 2 hours.\n\nThen I found the following message in /opt/stack/ceilometer/.tox/py27/\nlog/py27-1.log. Actually, the message was stopping halfway.\n-----\n:\nDownloading/unpacking jsonschema>=2.0.0,<3.0.0 (from -r /opt/stack/\nceilometer/requirements.txt (line 10))\n  Storing download in cache at ./.tox/_download/https%3A%2F%2Fpypi.\npython.org%2Fpackages%2Fsource%2Fj%2Fjsonschema%2Fjsonschema-2.3.0.tar.\ngz\n  Running s\n-----\n\nAfter that, I terminated tox with Ctrl+C and found the whole message as \nfollows.\n-----\n:\nDownloading/unpacking oslo.config>=1.2.0 (from -r /opt/stack/ceilometer/\nrequirements.txt (line 15))\n  Storing download in cache at ./.tox/_download/https%3A%2F%2Fpypi.\npython.org%2Fpackages%2Fsource%2Fo%2Foslo.config%2Foslo.config-1.3.0.tar.\ngz\n  Running setup.py egg_info for package oslo.config\nCleaning up...\nOperation cancelled by user\nStoring complete log in /home/openstack/.pip/pip.log\n-----\n\nAny advice or information would be greatly appreciated.\n\n[1]:https://bugs.launchpad.net/openstack-ci/+bug/1274135\n[2]:http://docs.openstack.org/developer/ceilometer/contributing/source.html#running-the-tests\n\nBest regards,\nNihongi\n\n\n--\nNobuyoshi Nihongi\nNTT Software Innovation Center\nPhone: +81 422 59 4880\nE-mail: nihongi.nobuyoshi at lab.ntt.co.jp\n\n\n',NULL,NULL),('<12D53C41B45C0B45B009937DA1D8229801E8625901@AUSX7MCPC103.AMER.DELL.COM>','http://lists.openstack.org/pipermail/community',NULL,'2013-01-15 08:15:27',-21600,'2013-01-15 14:15:27',NULL,'[openstack-community] Calling all user group and meetup\n organizers','Hi Sean,\n  Thanks for taking the initiative to organize this.\n\nI\'d like to toss another agenda item if I may.\nI started, and currently help organize the Boston meetup, and we\'ve been blessed with lots of local resources, both in terms of facilities and openstack enthusiasts.\nFeedback I\'ve gotten from multiple folks is that it would be useful to make available technical experts on up and coming projects (ceilometer, heat, new quantum services , cinder etc). While in the past I coordinated with project PTL\'s to locate local experts, it might be more efficient (and less troubling to PTL\'s) to have a community effort around this. If local presence is less than possible, then various collaboration tools could work.\nAfter that long promo, the agenda item would be - how do UG\'s help with incubating projects, and what kind of support the Openstack community at large supports that?\n\nRegards,\na.\n\n\n\n\nFrom: Sean Roberts [mailto:seanrob at yahoo-inc.com]\nSent: Monday, January 14, 2013 6:26 PM\nTo: OpenStack community; openstack\nCc: Hirschfeld, Rob; Pemmaraju, Kamesh; Abes, Andi; trevor.lowing at gmail.com; stephon.striplin at dreamhost.com; carlp at hq.newdream.net; brent.scotten at rackspace.com; kmestery at cisco.com; lloydostack at gmail.com; freedomhui at gmail.com; duyujie.dyj at gmail.com; santiagoc120 at outlook.com; sc360 at kent.ac.uk; mohamed at egyptcloudforum.com; Ilkka.Turunen at jamk.fi; berendt at b1-systems.de; BruceLok at cyberport.hk; marton.kiss at xemeti.com; deepakgarg.iitg at gmail.com; frans at meruvian.org; tim.horgan at cit.ie; fenris at ubuntu.com; mypapit at gmail.com; muharem at lbox.cc; hang.tran at dtt.vn\nSubject: Re: [openstack-community] Calling all user group and meetup organizers\n\nAgenda for tomorrow\'s user group / meetup planning meeting\n\n *\n *   Review of user group and meetup template\n *   Meetups fit into the larger plan of user committee and summit to summit development how?\n *   Where would be the location for social materials like videos, meetup logs, and other meeting related items?\n *   Where do operators go to figure out how to run OpenStack in production?\n *   Can the Foundation start working with some Universities for meeting space, sponsorship, and student participation? Is the Foundation interested in Phd thesis sponsorship?\n *   If possible I like to get some supporters for a groups.openstack.org site, including content writers and some developer resources from the community. We have a lot of knowledge about running / starting an user group, and need to write it down, publish on the site and share it with newcomers.  I think this is answered by the user group template information that will be published to http://wiki.openstack.org/OpenStackUserGroups.\n *   Should there be an OpenStack user group and/or meetup approval process? How do we clean up user groups and meetups that are abandoned?\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/14/13 2:07 PM, \"Sean Roberts\" <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\nReminder for the global user group planning meetup, tomorrow, Tuesday, 15 Jan 2012 11:00am to 1:00pm PST  http://www.meetup.com/openstack/events/93593062/\nJoin us!\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n\nOn 1/9/13 1:05 PM, \"Tim Horgan\" <tim.horgan at cit.ie<mailto:tim.horgan at cit.ie>> wrote:\n\nHi S?an,\n\nI run the OpenStack Ireland meetup group, just wondering if your meeting is targeting only groups in the East Coast of the USA?\n\nKind Regards,\nTim\n\nOn 9 Jan 2013, at 00:54, Sean Roberts <seanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>> wrote:\n\n\nWe are going to have a planning meeting on Tuesday, 15 Jan 2012 11:00am to 1:00pm PST. RSVP via  http://www.meetup.com/openstack/events/93593062/  Connect remotely via webex https://yahoomeetings.webex.com/yahoomeetings/j.php?ED=160663792&UID=492396097&RT=MiM0\nIf this time doesn\'t work for you, get ahold of me directly via skype:seanroberts66, email, mobile, irc:sarob, twitter:sarob, or carrier pigeon.\n\nStefano and Thierry will be joining us. I want to get input from people that run user groups and meetups.\n\nSee you then!\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com<mailto:seanrob at yahoo-inc.com>\nDirect (408) 349-5234  Mobile (925) 980-4729\n\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300  Fax (408) 349-3301\n\n[http://forgood.zenfs.com/logos/yahoo.png]\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org<mailto:Community at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\nRegards,\nTim\n\n\n---------------------------------------------------------------------------------------------\nTIM HORGAN\nHead of Cloud Computing Centre of Excellence\nExtended Campus Office\nCork Institute of Technology, Cork, Ireland\nphone: +353 214335120<callto:+353%2021%204335120> | mobile: +353 87 9439333<callto:+353%2087%209439333>\ntwitter: @timhorgan<https://twitter.com/#%21/timhorgan> | skype: timothy.horgan<https://twitter.com/#%21/timhorgan>\nlinkedin: http://ie.linkedin.com/in/timhorgan | web: http://cloud.cit.ie<http://cloud.cit.ie/>\n---------------------------------------------------------------------------------------------\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130115/ac9119bd/attachment-0001.html>\n\n','<CD19D324.8FEDB%seanrob@yahoo-inc.com>',NULL),('<12D9D608-94F8-4B1D-9E2A-A99786D78F05@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 11:02:33',-18000,'2014-11-19 16:02:33',NULL,'[openstack-dev] WSME 0.6.2 released','Version 0.6.2 was incorrectly configured to build universal wheels, leading to installation errors under Python 3 because of a dependency on ipaddr that only works on Python 2 (there is a version of the module already in the standard library for Python 3).\n\nTo fix this, fungi removed the bad wheel from PyPI and our mirror. I just tagged version 0.6.3 with the wheel build settings changed so that the wheels are only built for Python 2. This release was just uploaded to PyPI and should hit the mirror fairly soon.\n\nSorry for the issues,\nDoug\n\nOn Nov 18, 2014, at 10:01 AM, Doug Hellmann <doug at doughellmann.com> wrote:\n\n> The WSME development team has released version 0.6.2, which includes several bug fixes.\n> \n> $ git log --oneline --no-merges 0.6.1..0.6.2\n> 2bb9362 Fix passing Dict/Array based UserType as params\n> ea9f71d Document next version changes\n> 4e68f96 Allow non-auto-registered complex type\n> 292c556 Make the flask adapter working with flask.ext.restful\n> c833702 Avoid Sphinx 1.3x in the tests\n> 6cb0180 Doc: status= -> status_code=\n> 4441ca7 Minor documentation edits\n> 2c29787 Fix tox configuration.\n> 26a6acd Add support for manually specifying supported content types in @wsmeexpose.\n> 7cee58b Fix broken sphinx tests.\n> baa816c fix errors/warnings in tests\n> 2e1863d Use APIPATH_MAXLEN from the right module\n> \n> Please report issues through launchpad https://launchpad.net/wsme or the #wsme channel on IRC.\n> \n> Doug\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<F4857618-015F-4CCC-84FF-3CC8E3F57E38@doughellmann.com>',NULL),('<12DC8A53-BC84-4F18-8493-FE2C70C24A7F@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-12 20:09:58',-14400,'2013-07-13 00:09:58',NULL,'[openstack-dev] [OSLO] Comments/Questions on Messaging Wiki','\n\nSent from my iPhone\n\nOn Jul 12, 2013, at 5:27 PM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n\n> \n> \n> \n> On Fri, Jul 12, 2013 at 5:40 PM, William Henry <whenry at redhat.com> wrote:\n>> Hi all,\n>> \n>> I\'ve been reading through the Messaging Wiki and have some comments. Not criticisms, just comments and questions.\n>>  I have found this to be a very useful document. Thanks.\n>> \n>> 1. \"There are multiple backend transport drivers which implement the API semantics using different messaging systems - e.g. RabbitMQ, Qpid, ZeroMQ. While both sides of a connection must use the same transport driver configured in the same way, the API avoids exposing details of transports so that code written using one transport should work with any other transport.\"\n>> \n>> The good news for AMQP 1.0 users is that technically \"boths sides of the connection\" do not have to use same transport driver. In pre-AMQP 1.0 days this was the case. But today interoperability between AMQP 1.0 implementations has been demonstrated.\n> \n> In this case I think we mean the Transport driver from within Oslo. So you could not connect a ZMQ Transport on one end to an AMQP Transport on the other. It will be an implementation detail of the AMQP Transport class to decide whether it supports more than one version of AMQP, or if the different versions are implemented as different Transports.\n>  \n>> \n>> 2. I notice under the RPC concepts section that you mention Exchanges as a container in which topics are scoped. Is this exchange a pre AMQP 1.0 artifact or just a general term for oslo.messaging that is loosely based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you assuming that messaging implementations have something called an exchange? Or do you mean that messaging implementations can scope a topic and in oslo we call that scoping an exchange?\n> \n> The latter.\n\nAck. Good. Fits very well into AMQP 1.0 then ;-)\n\n>  \n>> \n>> 3. Some messaging nomenclature: The way the wiki describes RPC \"Invoke Method on One of Multiple Servers\" is more like a queue than a topic. In messaging a queue is something that multiple consumers can attach to and one of them gets and services a message/request.  A topic is where 1+ consumers are \"connected\" and each receives a the message and each can service it as it sees fit.  In pre-AMQP 1.0 terms what this seems to describe is a direct exchange. And a direct excahnge can have multiple consumers listening to a queue on that exchange.  (Remember that fanout is just a generalization of topic in that all consumers get all fanout messages - there are no sub-topics etc.)\n>> \n>> In AMQP 1.0 the addressing doesn\'t care or know about exchanges but it can support this queue type behavior on an address or topic type behavior on an address. \n>> \n>> I know this isn\'t about AMQP specifically but therefore this is even more important. Topics are pub/sub with multiple consumer/services responding to a single message. Queues are next consumer up gets the next message. \n>> \n>> \n>> (BTW I\'ve seen this kind of confusion also in early versions of MCollective in Puppet.)\n>> \n>> It might be better to change some of the references to \"topic\" to \"address\". This would solve the problem. i.e. a use case where one of many servers listening on an address services a message/request. And later all of servers listening on an address service a message/request. Addressing also solves the one-to-one as the address is specific to the server (and the others don\'t have to receive and reject the message).\n> \n> Too many of these terms are overloaded. :-)\n\nYep. But topic pup/sub is certainly different to a queue. ;-)\n\n> \n> I\'m not sure of the details of how \"topic\" and \"address\" are different in AMQP 1.0. The word \"address\" implies to me that the message sender knows where the message receiver is in some concrete sense. We don\'t want those semantics in a lot of our use cases. If the \"address\" is abstract, then it sounds like it works much as a topic does. Maybe you can expand on the differences?\n\n\nNope the address is essentially a namespace. The send knows not where it ends up. Hence in some applications it doesn\'t even know of its a topic or a queue an it could go to one or many depending.\n\nWilliam\n\n> \n> Thanks,\n> Doug\n> \n>  \n>> \n>> Please feel free to respond and critique my comments/suggestions.\n>> \n>> Best,\n>> William\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130712/082faf69/attachment.html>\n\n','<CADb+p3S6gUEHBOkTGxt0FBUuaR8F3kwoX5RyR+kkE9YLNepzeg@mail.gmail.com>',NULL),('<12E00A50-0E8D-4700-8CC4-802A209D04AC@mcclain.xyz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 12:17:57',-14400,'2014-08-28 16:17:57',NULL,'[openstack-dev] [infra] [neutron] [tc] Neutron Incubator\n	workflow','\nOn Aug 28, 2014, at 10:45 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On 08/27/2014 04:28 PM, Kevin Benton wrote:\n>> What are you talking about? The only reply was from me clarifying that\n>> one of the purposes of the incubator was for components of neutron that\n>> are experimental but are intended to be merged.\n> \n> Right. The special unicorns.\n> \n> > In that case it might\n>> not make sense to have a life cycle of their own in another repo\n>> indefinitely.\n> \n> The main reasons these \"experimental components\" don\'t make sense to live in their own repo indefinitely are:\n> \n> a) Neutron\'s design doesn\'t make it easy or straightforward to build/layer other things on top of it, or:\n> \n\nCorrect and this something I want the team to address in Kilo.  Many of the L7 services would be easier to build if we invest some time early in the cycle to establishing a well defined interface for a few items.  I?m sure the LBaaS team has good feedback to share with everyone.\n\n> b) The experimental piece of code intends to replace whole-hog a large chunk of Neutron\'s existing codebase, or:\n> \n> c) The experimental piece of code relies so heavily on inconsistent, unversioned internal interface and plugin calls that it cannot be designed externally due to the fragility of those interfaces\n\nI?m glad Jim reminded us of the pain of merging histories and the availability of feature branches.  I think for items where we?re replacing large chunks of code feature branches make lots of sense.\n\n> \n> Fixing a) is the solution to these problems. An incubator area where \"experimental components\" can live will just continue to mask the true problem domain, which is that Neutron\'s design is cumbersome to build on top of, and its cross-component interfaces need to be versioned, made consistent, and cleaned up to use versioned data structures instead of passing random nested dicts of randomly-prefixed string key/values.\n> \n> Frankly, we\'re going through a similar problem in Nova right now. There is a group of folks who believe that separating the nova-scheduler code into the Gantt project will magically make placement decision code and solver components *easier* to work on (because the pace of coding can be increased if there wasn\'t that pesky nova-core review process). But this is not correct, IMO. Separating out the scheduler into its own project before internal interfaces and data structures are cleaned up and versioned will just lead to greater technical debt and an increase in frustration on the part of Nova developers and scheduler developers alike.\n\nRight hopefully the incubator will allow us to develop components that should be independent from the start without incurring too much debt.\n\n> \n> -jay\n> \n>> On Wed, Aug 27, 2014 at 11:52 AM, Jay Pipes <jaypipes at gmail.com\n>> <mailto:jaypipes at gmail.com>> wrote:\n>> \n>>    On 08/26/2014 07:09 PM, James E. Blair wrote:\n>> \n>>        Hi,\n>> \n>>        After reading\n>>        https://wiki.openstack.org/__wiki/Network/Incubator\n>>        <https://wiki.openstack.org/wiki/Network/Incubator> I have\n>>        some thoughts about the proposed workflow.\n>> \n>>        We have quite a bit of experience and some good tools around\n>>        splitting\n>>        code out of projects and into new projects.  But we don\'t\n>>        generally do a\n>>        lot of importing code into projects.  We\'ve done this once, to my\n>>        recollection, in a way that preserved history, and that was with the\n>>        switch to keystone-lite.\n>> \n>>        It wasn\'t easy; it\'s major git surgery and would require significant\n>>        infra-team involvement any time we wanted to do it.\n>> \n>>        However, reading the proposal, it occurred to me that it\'s\n>>        pretty clear\n>>        that we expect these tools to be able to operate outside of the\n>>        Neutron\n>>        project itself, to even be releasable on their own.  Why not\n>>        just stick\n>>        with that?  In other words, the goal of this process should be\n>>        to create\n>>        separate projects with their own development lifecycle that will\n>>        continue indefinitely, rather than expecting the code itself to\n>>        merge\n>>        into the neutron repo.\n>> \n>>        This has advantages in simplifying workflow and making it more\n>>        consistent.  Plus it builds on known integration mechanisms like\n>>        APIs\n>>        and python project versions.\n>> \n>>        But more importantly, it helps scale the neutron project itself.  I\n>>        think that a focused neutron core upon which projects like these can\n>>        build on in a reliable fashion would be ideal.\n>> \n>> \n>>    Despite replies to you saying that certain branches of Neutron\n>>    development work are special unicorns, I wanted to say I *fully*\n>>    support your above statement.\n>> \n>>    Best,\n>>    -jay\n>> \n>> \n>> \n>>    _________________________________________________\n>>    OpenStack-dev mailing list\n>>    OpenStack-dev at lists.openstack.__org\n>>    <mailto:OpenStack-dev at lists.openstack.org>\n>>    http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n>> \n>> \n>> \n>> \n>> --\n>> Kevin Benton\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<53FF4086.4020703@gmail.com>',NULL),('<12E35BF1-353B-47E6-B9B9-A0A2F01AA54D@alterway.fr>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-18 16:04:54',7200,'2013-09-18 14:04:54',NULL,'[Openstack] [Cinder] Attach the volume in Local Disk failed.\n	The log in nova/compute.log said \"libvirtError: unsupported\n	configuration: disk bus \'ide\' cannot be hotplugged\"','Hi,\n\n> The openstack was running on one server in my experiment. The VolumeGroup named ?cinder-volumes? was comprised by a local disk partition whose name was ?/dev/sda2?.\n>  \n> A volume was created in the dashboard, and I tried to attach it to a running instance. However, the operation was failed.\n>  \n> The exception in nova/compute.log said that the disk bus ide could not be hotplugged.\n>  \n> As known to all, the ide bus cannot be hotplugged to a running instance.\n>  \n> It seems that the current version used the bus type ?ide? as the default one.\n>  \n> In this case, all the volumes created in the ?cinder-volumes? cannot be hotplugged into the running vm. You can never attach a volume to a suspend instance in the dashboard. There is no choice to this in the portal.\n>  \n> How can I choose the type ?virtio? when the volume has been attached?\n>  \n> [root at localhost nova]# nova --version\n> 2.13.0\n> [root at localhost nova]# uname -a\n> Linux localhost 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux\n> [root at localhost nova]#\n\nI had the same issue on my storage node when iet and tgt process was running at the same time.\n\nFor example in my cinder.conf :\n\niscsi_helper = etadm\n\nSo i stopped tgt service (service tgt stop) and restart iscsitarget and cinder services .\n\nAfter that everything was ok, perhaps you should try this method.\n\nI hope it will help you.\n\n-- \nYannick Foeillet\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130918/e4e643d5/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4837 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130918/e4e643d5/attachment.bin>\n\n','<F3FF02E5B1A52F44A89CA6A3523CE5577181D6B7@szxema507-mbx.china.huawei.com>',NULL),('<12F48C6A-523D-4827-978A-29BD03A4CD21@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:44:14',-14400,'2014-09-04 14:44:14',NULL,'[openstack-dev] WARNING: upcoming dependency change to oslotest','Next week the Oslo team will be releasing a new version of oslotest that replaces its use of the ?mox? library with ?mox3\". This will allow us to prepare a packaged version of oslotest that works on both python 2 and 3, which is necessary for porting some of the other Oslo libraries as well as applications which are trying to use Oslo and support python 3.\n\nmox3 has the same API as mox, so if your test suite uses oslotest.moxstubout you shouldn?t notice any difference.\n\nIf you are using oslotest but also import mox directly in some of your test modules and do not have an explicit dependency on mox, your tests will break. There are two ways to fix them: change them to use the moxstubout module to get a mox instance or add mox to your test-requirements.txt list. The first solution, using moxstubout from oslotest, is preferred because it means your test suite is one step closer to being python 3 ready. However, updating test-requirements.txt may be a less invasive change and so it might be more expedient to use that approach for now.\n\nDoug\n\n\n\n',NULL,NULL),('<1300487886.79.1357885250693.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-11 06:20:50',0,'2013-01-11 06:20:50',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #71','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/71/>\n\n------------------------------------------\n[...truncated 14678 lines...]\n++ grep myvol-aad14aa6\n++ cinder list\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ echo \'| 456bcb04-f813-4fd9-955d-45673b829d84 | available | myvol-aad14aa6 |  1   |     None    |  false   |             |\'\n++ read data\n+ VOL_ID=456bcb04-f813-4fd9-955d-45673b829d84\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for myvol-aad14aa6\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1357884819\n+ nova volume-attach f439ddfd-32a7-47ea-9b46-6e7d661f6da9 456bcb04-f813-4fd9-955d-45673b829d84 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| id       | 456bcb04-f813-4fd9-955d-45673b829d84 |\n| serverId | f439ddfd-32a7-47ea-9b46-6e7d661f6da9 |\n| volumeId | 456bcb04-f813-4fd9-955d-45673b829d84 |\n+----------+--------------------------------------+\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-aad14aa6 | grep in-use; do sleep 1; done\'\n| 456bcb04-f813-4fd9-955d-45673b829d84 | in-use | myvol-aad14aa6 |  1   |     None    |  false   | f439ddfd-32a7-47ea-9b46-6e7d661f6da9 |\n++ date +%s\n+ end_time=1357884824\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ get_field -1\n++ read data\n++ head -1\n++ grep myvol-aad14aa6\n++ cinder list\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ echo \'| 456bcb04-f813-4fd9-955d-45673b829d84 | in-use | myvol-aad14aa6 |  1   |     None    |  false   | f439ddfd-32a7-47ea-9b46-6e7d661f6da9 |\'\n++ read data\n+ VOL_ATTACH=f439ddfd-32a7-47ea-9b46-6e7d661f6da9\n+ die_if_not_set VOL_ATTACH \'Failure retrieving myvol-aad14aa6 status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ f439ddfd-32a7-47ea-9b46-6e7d661f6da9 != f439ddfd-32a7-47ea-9b46-6e7d661f6da9 ]]\n++ date +%s\n+ start_time=1357884825\n+ nova volume-detach f439ddfd-32a7-47ea-9b46-6e7d661f6da9 456bcb04-f813-4fd9-955d-45673b829d84\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-aad14aa6 | grep available; do sleep 1; done\'\n| 456bcb04-f813-4fd9-955d-45673b829d84 | available | myvol-aad14aa6 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357884829\n+ echo \'Completed volume-detach in 4 seconds\'\nCompleted volume-detach in 4 seconds\n++ date +%s\n+ start_time=1357884829\n+ cinder delete 456bcb04-f813-4fd9-955d-45673b829d84\n+ timeout 60 sh -c \'while cinder list | grep myvol-aad14aa6; do sleep 1; done\'\n| 456bcb04-f813-4fd9-955d-45673b829d84 | deleting | myvol-aad14aa6 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357884832\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete f439ddfd-32a7-47ea-9b46-6e7d661f6da9\n+ timeout 60 sh -c \'while nova list | grep -q f439ddfd-32a7-47ea-9b46-6e7d661f6da9; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nSKIP: EC2 InstanceRunTest: requires ami/aki/ari manifest\n-------------------- >> begin captured logging << --------------------\ntempest.config: INFO: Using tempest config file /opt/stack/new/tempest/etc/tempest.conf\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6676\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/users/b29a1b2e7c414f139b923f3376daf35f/credentials/OS-EC2 HTTP/1.1\" 200 777\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6676\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/users/b29a1b2e7c414f139b923f3376daf35f/credentials/OS-EC2 HTTP/1.1\" 200 777\n--------------------- >> end captured logging << ---------------------\ntest_create_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... ok\ntest_delete_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... SKIP: Skipped until the Bug #1072318 is resolved\ntest_duplicate_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... SKIP: Skipped until the Bug #1072762 is resolved\ntest_get_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... ok\ntest_disassociate_not_associated_floating_ip (tempest.tests.boto.test_ec2_network.EC2NetworkTest) ... SKIP: Skipped until the Bug #1080406 is resolved\ntest_create_authorize_security_group (tempest.tests.boto.test_ec2_security_groups.EC2SecurityGroupTest) ... ok\ntest_create_get_delete (tempest.tests.boto.test_ec2_volumes.EC2VolumesTest) ... ok\ntest_create_volme_from_snapshot (tempest.tests.boto.test_ec2_volumes.EC2VolumesTest) ... ok\ntest_create_and_get_delete_bucket (tempest.tests.boto.test_s3_buckets.S3BucketsTest) ... SKIP: Skipped until the Bug #1076965 is resolved\nSKIP: EC2 S3ImagesTest: requires ami/aki/ari manifest\ntest_create_get_delete_object (tempest.tests.boto.test_s3_objects.S3BucketsTest) ... SKIP: Skipped until the Bug #1076534 is resolved\ntest_get_default_quotas (tempest.tests.compute.admin.test_quotas.QuotasTest) ... ok\ntest_get_flavor (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_list_flavors (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_list_flavors_with_detail (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_get_flavor (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\ntest_list_flavors (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\ntest_list_flavors_with_detail (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\ntest_get_image (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_list_images (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_list_images_with_detail (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\nERROR\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_change_server_password (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Change password not available.\ntest_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... ok\ntest_reboot_server_soft (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Until bug 1014647 is dealt with.\ntest_rebuild_server (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... ok\ntest_resize_server_confirm (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Resize not available.\ntest_change_server_password (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Change password not available.\ntest_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... ok\ntest_reboot_server_soft (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Until bug 1014647 is dealt with.\ntest_rebuild_server (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... ok\ntest_resize_server_confirm (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Resize not available.\ntest_list_server_addresses (tempest.tests.compute.servers.test_server_addresses.ServerAddressesTest) ... ok\ntest_list_server_addresses_by_network (tempest.tests.compute.servers.test_server_addresses.ServerAddressesTest) ... ok\ntest_volume_create_get_delete (tempest.tests.compute.volumes.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.compute.volumes.test_volumes_get.VolumesGetTestXML) ... ok\ntest_get_default_quotas (tempest.tests.compute.test_quotas.QuotasTest) ... ok\ntest_create_user (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_delete_user (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_get_users (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_user_authentication (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_create_user (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_delete_user (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_get_users (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_user_authentication (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.compute.servers.test_create_server.ServersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_create_server.py\", line 167, in setUpClass\n    ServersTest.setUpClass(cls)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_create_server.py\", line 59, in setUpClass\n    cls.client.wait_for_server_status(cls.server_initial[\'id\'], \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 739ecb8a-804b-466e-83e5-a984a89a4cf8 failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 80 tests in 372.876s\n\nFAILED (SKIP=15, errors=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/rabbitmq/rabbit at devstack-1357869707-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/rabbitmq/rabbit at devstack-1357869707.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/71/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1639541984.47.1357778923160.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1300607682.8600897.1400597148608.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 10:45:48',-14400,'2014-05-20 14:45:48',NULL,'[openstack-dev] [sahara] bug triage day after summit','+1 for May 27.\n\n----- Original Message -----\nFrom: \"Andrew Lazarev\" <alazarev at mirantis.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, May 20, 2014 10:20:58 AM\nSubject: Re: [openstack-dev] [sahara] bug triage day after summit\n\nI think May 26 was a random \'day after summit\'. I\'m Ok with May 27 too. \n\nAndrew. \n\n\nOn Tue, May 20, 2014 at 10:16 AM, Sergey Lukjanov < slukjanov at mirantis.com > wrote: \n\n\nI\'m ok with moving it to May 27. \n\nOn Tuesday, May 20, 2014, Michael McCune < mimccune at redhat.com > wrote: \n\n\nI think in our eagerness to triage bugs we might have missed that May 26 is a holiday in the U.S. \n\nI know some of us have the day off work and while that doesn\'t necessarily stop the effort, it might throw a wrench in people\'s holiday weekend plans. I\'m wondering if we should re-evaluate and make the following day(May 27) triage day instead? \n\nregards, \nmike \n\n----- Original Message ----- \n> Hey sahara folks, \n> \n> let\'s make a Bug Triage Day after the summit. \n> \n> I\'m proposing the May, 26 for it. \n> \n> Any thoughts/objections? \n> \n> Thanks. \n> \n> -- \n> Sincerely yours, \n> Sergey Lukjanov \n> Sahara Technical Lead \n> (OpenStack Data Processing) \n> Mirantis Inc. \n> \n> _______________________________________________ \n> OpenStack-dev mailing list \n> OpenStack-dev at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n-- \nSincerely yours, \nSergey Lukjanov \nSahara Technical Lead \n(OpenStack Data Processing) \nMirantis Inc. \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CANzyysihDe0KOFGfQg9TL7PbKwMcw4dp=zyOwR_Qjp-asAnafQ@mail.gmail.com>',NULL),('<1301036426.42.1378534333809.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-07 06:12:13',0,'2013-09-07 06:12:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #19','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 1165 lines...]\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_reload\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 244, in test_reload\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 86.49 secs:\n    25.70    TestScrubber.test_scrubber_app\n    20.15    TestScrubber.test_delayed_delete\n    14.16    TestGlanceControl.test_respawn\n    13.40    TestGlanceControl.test_bouncing\n    13.07    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1101 tests in 549.000s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.19\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.wxIOU8tdQa\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/19/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise7/19\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1302132849.23.1352506374535.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:12:54',0,'2012-11-10 00:12:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-diablo #88','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/88/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/>\nCheckout:periodic-swift-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson6215215803677869133.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-diablo/88\n[SCP] Copying console log.\n\n\n','<1722190511.11.1352419949343.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<130284511.20.1352851998894.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:13:18',0,'2012-11-14 00:13:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/92/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/>\nCheckout:periodic-swift-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/> - hudson.remoting.Channel at 276b998f:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson7769899125411557534.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<172230038.60.1352765530968.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1303464291.251.1368341218241.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:46:58',0,'2013-05-12 06:46:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly-centos6 #12','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly-centos6/12/changes>\n\nChanges:\n\n[Gary Kotton] Do not attempt to kill already-dead dnsmasq\n\n[Gary Kotton] OSLO updates for stable\n\n[Gary Kotton] Treat unbound port\n\n[Gary Kotton] Duplicate line in Brocade plugin\n\n[Gary Kotton] Create veth peer in namespace.\n\n[Gary Kotton] in dhcp_agent, always use quantum.conf root_helper\n\n[Gary Kotton] Add kill-metadata rootwrap filter to support RHEL.\n\n------------------------------------------\n[...truncated 5102 lines...]\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    2.30\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.01\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.00\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.01\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.32\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.31\n    test_update_quotas_forbidden                                 OK    2.57\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.20\n    test_quotas_default_values                                   OK    0.21\n    test_show_quotas_with_admin                                  OK    0.28\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.31\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.31\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    2.61\n    test_list_quotas_with_admin                                  OK    0.20\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.23\n    test_quotas_limit_check_with_over_quota                      OK    2.74\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.20\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    0.23\n    test_update_quotas_with_admin                                OK    0.26\n    test_update_quotas_with_non_integer_returns_400              OK    2.70\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.22\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.22\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.22\n    test_quotas_default_values                                   OK    0.23\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    2.65\n    test_quotas_get_tenant_from_request_context                  OK    0.20\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_with_owner_tenant                           OK    2.57\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.22\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.45\n    test_KillFilter_deleted_exe                                  OK    0.01\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.02\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    3.86\n    test_health_monitor_delete_with_router_id                    OK    0.28\n    test_health_monitor_delete_without_router_id                 OK    0.25\n    test_health_monitor_update_with_router_id                    OK    0.24\n    test_health_monitor_update_without_router_id                 OK    0.24\n    test_pool_create                                             OK    0.24\n    test_pool_delete_with_router_id                              OK    0.27\n    test_pool_delete_without_router_id                           OK    0.26\n    test_pool_update_with_router_id                              OK    0.23\n    test_pool_update_without_router_id                           OK    0.25\n    test_router_create_no_service_type_id                        OK    0.21\n    test_router_create_with_service_type_id                      OK    0.22\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    2.54\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.23\n    test_vip_create                                              OK    0.26\n    test_vip_delete_with_router_id                               OK    0.29\n    test_vip_delete_without_router_id                            OK    0.29\n    test_vip_update_with_router_id                               OK    0.27\n    test_vip_update_without_router_id                            OK    0.30\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.45\n    test_security_group_rules_for_devices_ipv4_source_group      OK    3.05\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.44\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.50\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.43\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.52\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv6_ingress           OK    2.85\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.53\nSecurityGroupAgentRpcApiTestCase\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSecurityGroupAgentRpcTestCase\n    test_prepare_and_remove_devices_filter                       OK    0.01\n    test_refresh_firewall                                        OK    0.01\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.01\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.01\nSecurityGroupServerRpcApiTestCase\n    test_security_group_rules_for_devices                        OK    0.00\nTestSecurityGroupAgentWithIptables\n    test_prepare_remove_port                                     OK    0.05\n    test_security_group_member_updated                           OK    0.10\n    test_security_group_rule_udpated                             OK    0.04\nTestSecurityGroupAgentWithOVSIptables\n    test_prepare_remove_port                                     OK    0.03\n    test_security_group_member_updated                           OK    0.10\n    test_security_group_rule_udpated                             OK    0.04\nTestSecurityGroupExtensionControl\n    test_disable_security_group_extension_iptables_driver        OK    0.00\n    test_disable_security_group_extension_noop_driver            OK    0.00\n    test_firewall_enabled_iptables_driver                        OK    0.00\n    test_firewall_enabled_noop_driver                            OK    0.00\nServiceTypeExtensionTestCase\n    test_create_service_type_adminctx_returns_200                OK    0.10\n    test_create_service_type_nonadminctx_returns_403             OK    0.03\n    test_service_type_create                                     OK    0.03\n    test_service_type_delete                                     OK    0.03\n    test_service_type_get                                        OK    0.02\n    test_service_type_list                                       OK    0.02\n    test_service_type_update                                     OK    0.03\n    test_update_service_type_adminctx_returns_200                OK    0.03\n    test_update_service_type_nonadminctx_returns_403             OK    0.03\nServiceTypeExtensionTestCaseXML\n    test_create_service_type_adminctx_returns_200                OK    0.03\n    test_create_service_type_nonadminctx_returns_403             OK    0.03\n    test_service_type_create                                     OK    0.03\n    test_service_type_delete                                     OK    0.03\n    test_service_type_get                                        OK    0.02\n    test_service_type_list                                       OK    0.02\n    test_service_type_update                                     OK    0.03\n    test_update_service_type_adminctx_returns_200                OK    0.03\n    test_update_service_type_nonadminctx_returns_403             OK    0.03\nServiceTypeManagerTestCase\n    test_create_dummy_increases_service_type_refcount            OK    0.17\n    test_create_service_type_default_returns_400                 OK    0.16\n    test_create_service_type_no_svcdef_returns_400               OK    0.16\n    test_delete_dummy_decreases_service_type_refcount            OK    0.19\n    test_delete_service_type_in_use_returns_409                  Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.W6eAhmtu43\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1:  5076 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly-centos6/12\n[SCP] Copying console log.\n\n\n','<1725524428.233.1368254825186.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1303970730.3402119.1386361562712.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 15:26:02',-18000,'2013-12-06 20:26:02',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','Thanks for the comments!  Responses inline:\n\n> Disclaimer: I\'m very new to the project, so apologies if some of my\n> questions have been already answered or flat out don\'t make sense.\n> \n> As I proofread, some of my comments may drift a bit past basic\n> requirements, so feel free to tell me to take certain questions out of\n> this thread into specific discussion threads if I\'m getting too detailed.\n> \n> > --------------------------------\n> >\n> > *** Requirements are assumed to be targeted for Icehouse, unless marked\n> > otherwise:\n> >     (M) - Maybe Icehouse, dependency on other in-development features\n> >     (F) - Future requirement, after Icehouse\n> >\n> > * NODES\n> >     * Creation\n> >        * Manual registration\n> >           * hardware specs from Ironic based on mac address (M)\n> >           * IP auto populated from Neutron (F)\n> >        * Auto-discovery during undercloud install process (M)\n> >     * Monitoring\n> >         * assignment, availability, status\n> >         * capacity, historical statistics (M)\n> >     * Management node (where triple-o is installed)\n> >         * created as part of undercloud install process\n> >         * can create additional management nodes (F)\n> >      * Resource nodes\n> >          * searchable by status, name, cpu, memory, and all attributes from\n> >          ironic\n> >          * can be allocated as one of four node types\n> \n> It\'s pretty clear by the current verbiage but I\'m going to ask anyway:\n> \"one and only one\"?\n\nYep, that\'s right!\n\n> >              * compute\n> >              * controller\n> >              * object storage\n> >              * block storage\n> >          * Resource class - allows for further categorization of a node\n> >          type\n> >              * each node type specifies a single default resource class\n> >                  * allow multiple resource classes per node type (M)\n> \n> My gut reaction is that we want to bite this off sooner rather than\n> later. This will have data model and API implications that, even if we\n> don\'t commit to it for Icehouse, should still be in our minds during it,\n> so it might make sense to make it a first class thing to just nail down now.\n\nThat is entirely correct, which is one reason it\'s on the list of requirements.  The\nforthcoming API design will have to account for it.  Not recreating the entire data\nmodel between releases is a key goal :)\n\n\n> >              * optional node profile for a resource class (M)\n> >                  * acts as filter for nodes that can be allocated to that\n> >                  class (M)\n> \n> To my understanding, once this is in Icehouse, we\'ll have to support\n> upgrades. If this filtering is pushed off, could we get into a situation\n> where an allocation created in Icehouse would no longer be valid in\n> Icehouse+1 once these filters are in place? If so, we might want to make\n> it more of a priority to get them in place earlier and not eat the\n> headache of addressing these sorts of integrity issues later.\n\nThat\'s true.  The problem is that to my understanding, the filters we\'d\nneed in nova-scheduler are not yet fully in place.\n\nI also think that this is an issue that we\'ll need to address no matter what.\nEven once filters exist, if a user applies a filter *after* nodes are allocated,\nwe\'ll need to do something clever if the already-allocated nodes don\'t meet the\nfilter criteria.\n\n> >          * nodes can be viewed by node types\n> >                  * additional group by status, hardware specification\n> >          * controller node type\n> >             * each controller node will run all openstack services\n> >                * allow each node to run specified service (F)\n> >             * breakdown by workload (percentage of cpu used per node) (M)\n> >      * Unallocated nodes\n> \n> Is there more still being flushed out here? Things like:\n>   * Listing unallocated nodes\n>   * Unallocating a previously allocated node (does this make it a\n> vanilla resource or does it retain the resource type? is this the only\n> way to change a node\'s resource type?)\n>   * Unregistering nodes from Tuskar\'s inventory (I put this under\n> unallocated under the assumption that the workflow will be an explicit\n> unallocate before unregister; I\'m not sure if this is the same as\n> \"archive\" below).\n\nAh, you\'re entirely right.  I\'ll add these to the list.\n\n> >      * Archived nodes (F)\n> \n> Can you elaborate a bit more on what this is?\n\nTo be honest, I\'m a bit fuzzy about this myself; Jarda mentioned that there was\nan OpenStack service in the process of being planned that would handle this\nrequirement.  Jarda, can you detail a bit?\n\nThanks again for the comments!\n\n\nMainn\n\n\n','<52A2224D.6030907@redhat.com>',NULL),('<1303D9AB-0AA9-4110-92C4-2A057410A0D7@siliconloons.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 08:11:15',-21600,'2013-12-19 14:11:15',NULL,'[openstack-dev] [neutron] [ml2] Canceling next two weekly meetings','Since the next two Neutron ML2 meetings fall on Dec. 25\nand Jan. 1, we\'ll cancel both and reconvene on Jan. 8.\n\nThanks!\nKyle\n\n\n',NULL,NULL),('<1304299105.13151412.1401306782998.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 15:53:03',-14400,'2014-05-28 19:53:03',NULL,'[openstack-dev] [Horizon][Tuskar-UI] Location for\n	common	dashboard code?','Hi Doug,\n\nThanks for the response!  I agree with you in the cases where we are extending\nthings like panels; if you\'re extending those, you\'re extending the dashboard\nitself.  However, things such as workflows feel like they could reasonably live\nindependently of the dashboard for re-use elsewhere.\n\nIncidentally, I know that within openstack_dashboard there are cases where, say,\nthe admin dashboard extends instances tables from the project dashboard.  That\nfeels a bit odd to me; wouldn\'t it be cleaner to have both dashboards extend\nsome common instances table that lives independently of either dashboard?\n\nThanks,\nTzu-Mainn Chen\n\n----- Original Message -----\n> Hey Tzu-Mainn,\n> \n> I\'ve actually discouraged people from doing this sort of thing when\n> customizing Horizon.  IMO it\'s risky to extend those panels because they\n> really aren\'t intended as extension points.  We intend Horizon to be\n> extensible by adding additional panels or dashboards.  I know you are\n> closely involved in Horizon development, so you are better able to manage\n> that better than most customizers.\n> \n> Still, I wonder if we can better address this for Tuskar-UI as well as\n> other situations by defining extensibility points in the dashboard panels\n> and workflows themselves.  Like well defined ways to add/show a column of\n> data, add/hide row actions, add/skip a workflow step, override text\n> elements, etc.  Is it viable to create a few well defined extension points\n> and meet your need to modify existing dashboard panels?\n> \n> In any case, it seems to me that if you are overriding the dashboard\n> panels, it\'s reasonable that tuskar-ui should be dependent on the\n> dashboard.\n> \n> Doug Fish\n> \n> \n> \n> \n> \n> From:	Tzu-Mainn Chen <tzumainn at redhat.com>\n> To:	\"OpenStack Development Mailing List (not for usage questions)\"\n>             <openstack-dev at lists.openstack.org>,\n> Date:	05/28/2014 11:40 AM\n> Subject:	[openstack-dev] [Horizon][Tuskar-UI] Location for common\n>             dashboard	code?\n> \n> \n> \n> Heya,\n> \n> Tuskar-UI is currently extending classes directly from openstack-dashboard.\n> For example, right now\n> our UI for Flavors extends classes in both\n> openstack_dashboard.dashboards.admin.flavors.tables and\n> openstack_dashboard.dashboards.admin.flavors.workflows.  In the future,\n> this sort of pattern will\n> increase; we anticipate doing similar things with Heat code in\n> openstack-dashboard.\n> \n> However, since tuskar-ui is intended to be a separate dashboard that has\n> the potential to live\n> away from openstack-dashboard, it does feel odd to directly extend\n> openstack-dashboard dashboard\n> components.  Is there a separate place where such code might live?\n> Something similar in concept\n> to\n> https://github.com/openstack/horizon/tree/master/openstack_dashboard/usage\n> ?\n> \n> \n> Thanks,\n> Tzu-Mainn Chen\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OF14009F33.95546D74-ON85257CE6.00697E21-86257CE6.006B1F33@us.ibm.com>',NULL),('<1304736774.1961776.1396979345616.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 13:49:05',-14400,'2014-04-08 17:49:05',NULL,'[openstack-dev] [keystone] event notifications issue','Hi Nader,\nI ran into some issues the other day with Keystone notifications.\nMake sure that you have (in both Keystone and the receiving project) the following\nconfiguration options set:\n\n- rpc_backend (should be \"rabbit\", \"qpid\", etc)\n- appropriate rpc backend config options (e.g. for rabbit, rabbit_hosts and rabbit_password)\n- notification_driver = messaging\n\nHopefully this is helpful, as some of these options are not set by default in devstack.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Nader Lahouti\" <nader.lahouti at gmail.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, April 8, 2014 12:50:50 PM\nSubject: Re: [openstack-dev] [keystone] event notifications issue\n\nResending the question: \n\nCan someone please point me to a document/code in order to get keystone notification with the latest keystone code. \n\nAppreciate your help. \n\n\nOn Sun, Apr 6, 2014 at 4:13 PM, Nader Lahouti < nader.lahouti at gmail.com > wrote: \n\n\n\nHi All, \n\nI was able to get keystone notification when creating/deleting a tenant by setting these parameters in keystone.conf: \n\n(NOTE: the brach that I was using: \ngit branch -v \n* (no branch) 0d83e7e Bump stable/havana next version to 2013.2.2) \n) \nnotification_topics = Key_Notify \nrpc_backend = keystone.openstack.common.rpc.impl_kombu \ncontrol_exchange = Key_openstack \nnotification_driver = keystone.openstack.common.notifier.rpc_notifier \n\nNow I changed the branch to: \ngit branch -v \n* master e45ff9e Merge \"Updated from global requirements\" \n\nAnd cannot get any notification. It seems the notifications.py changed. \n\nWhat I need to do, in order to get event notification with the current code and make it work? \n\nThanks, \nNader. \n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAF5T5jvsWzORvAsUwk3QFNjQZBra1HVcJVyLwHnhr1JkKDaNaA@mail.gmail.com>',NULL),('<1305384399.19448.14.camel@manzanillo>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-05-14 16:46:39',7200,'2011-05-14 14:46:39',NULL,'[Openstack-operators] VHPC\'11 submission deadline extension','Due to several requests, the deadline for full paper submission has been\nextended to the 20th of June.\n\nBest regards,\n\nMichael Alexander and Gianluigi Zanetti\n\n--\n\n=================================================================\n\nCALL FOR PAPERS\n\n6th Workshop on\n\nVirtualization in High-Performance Cloud Computing\n\nVHPC\'11\n\nas part of Euro-Par 2011, Bordeaux, France\n\n=================================================================\n\nDate: August 30, 2011\n\nEuro-Par 2011: http://europar2011.bordeaux.inria.fr/\n\nWorkshop URL: http://vhpc.org\n\nSUBMISSION DEADLINE:\n\nFull Paper: June 20, 2011 (extended)\n\n\nScope:\n\nVirtualization has become a common abstraction layer in modern data\ncenters, enabling resource owners to manage complex infrastructure\nindependently of their applications. Conjointly virtualization is\nbecoming a driving technology for a manifold of industry grade IT\nservices. The cloud concept includes the notion of a separation\nbetween resource owners and users, adding services such as hosted\napplication frameworks and queuing. Utilizing the same infrastructure,\nclouds carry significant potential for use in high-performance\nscientific computing. The ability of clouds to provide for\nrequests and releases of vast computing resource dynamically and\nclose to the marginal cost of providing the services is unprecedented\nin the history of scientific and commercial computing.\n\nDistributed computing concepts that leverage federated resource access\nare popular within the grid community, but have not seen previously\ndesired deployed levels so far. Also, many of the scientific\ndatacenters have not adopted virtualization or cloud concepts yet.\n\nThis workshop aims to bring together industrial providers with the\nscientific community in order to foster discussion, collaboration and\nmutual exchange of knowledge and experience.\n\nThe workshop will be one day in length, composed of 20 min paper\npresentations, each followed by 10 min discussion sections.\nPresentations may be accompanied by interactive demonstrations. It\nconcludes with a 30 min panel discussion by presenters.\n\nTOPICS\n\nTopics include, but are not limited to, the following subjects:\n\n- Virtualization in cloud, cluster and grid environments\n- VM-based cloud performance modeling\n- Workload characterizations for VM-based environments\n- Software as a Service (SaaS)\n- Cloud reliability, fault-tolerance, and security\n- Cloud, cluster and grid filesystems\n- QoS and and service levels\n- Cross-layer VM optimizations\n- Virtualized I/O and storage\n- Virtualization and HPC architectures including NUMA\n- System and process/bytecode VM convergence\n- Paravirtualized driver development\n- Research and education use cases\n- VM cloud, cluster distribution algorithms\n- MPI on virtual machines and clouds\n- Cloud frameworks and API sets\n- Checkpointing of large compute jobs\n- Cloud load balancing\n- Accelerator virtualization\n- Instrumentation interfaces and languages\n- Hardware support for virtualization\n- High-performance network virtualization\n- Auto-tuning of VMM and VM parameters \n- High-speed interconnects\n- Hypervisor extensions and tools for cluster and grid computing\n- VMMs/Hypervisors\n- Cloud use cases including optimizations\n- Performance modeling\n- Fault tolerant VM environments\n- VMM performance tuning on various load types\n- Cloud provisioning\n- Virtual machine monitor platforms\n- Pass-through VM device access\n- Management, deployment of VM-based environments\n\nPAPER SUBMISSION\n\nPapers submitted to the workshop will be reviewed by at least two\nmembers of the program committee and external reviewers. Submissions\nshould include abstract, key words, the e-mail address of the\ncorresponding author, and must not exceed 10 pages, including tables\nand figures at a main font size no smaller than 11 point. Submission\nof a paper should be regarded as a commitment that, should the paper\nbe accepted, at least one of the authors will register and attend the\nconference to present the work.\n\nAccepted papers will be published in the Springer LNCS series - the\nformat must be according to the Springer LNCS Style. Initial\nsubmissions are in PDF, accepted papers will be requested to provided\nsource files.\n\nFormat Guidelines: http://www.springer.de/comp/lncs/authors.html\nSubmission Link: http://edas.info/newPaper.php?c=10155\n\nIMPORTANT DATES\n\nJune 20 2011 - Full paper submission (extended)\nJuly 15 2011 - Acceptance notification\nAugust 3 2011 - Camera-ready version due\nAugust 30 2011 - September 2 - conference\n\n\nCHAIR\n\nMichael Alexander (chair), IBM, Austria\nGianluigi Zanetti (co-chair), CRS4, Italy\n\n\nPROGRAM COMMITTEE\n\nPaolo Anedda, CRS4, Italy\nVolker Buege, University of Karlsruhe, Germany\nGiovanni Busonera, CRS4, Italy\nRoberto Canonico, University of Napoli, Italy\nTommaso Cucinotta, Scuola Superiore Sant\'Anna, Italy\nWilliam Gardner, University of Guelph, Canada\nWerner Fischer, Thomas-Krenn AG, Germany\nWolfgang Gentzsch, Max Planck Gesellschaft, Germany\nMarcus Hardt, Forschungszentrum Karlsruhe, Germany\nSverre Jarp, CERN, Switzerland\nShantenu Sjha, Louisiana State University, USA\nXuxian Jiang, NC State, USA\nKenji Kaneda, Google, USA\nSimone Leo, CRS4, Italy\nIgnancio Llorente, Universidad Complutense de Madrid, Spain,\nNaoya Maruyama, Tokyo Institute of Technology, Japan\nJean-Marc Menaud, Ecole des Mines de Nantes, France\nAnastassios Nanos, National Technical University of Athens, Greece\nJose Renato Santos, HP Labs, USA\nDeepak Singh, Amazon Webservices, USA \nBoria Sotomayor, University of Chicago, USA\nYoshio Turner, HP Labs, USA\nKurt Tutschku, University of Vienna, Austria\nLizhe Wang, Indiana University, USA\nChao-Tung Yang, Tunghai University, China\n\n\nDURATION: Workshop Duration is one day.\n\nGENERAL INFORMATION\n\nThe workshop will be held as part of Euro-Par 2011,\norganized by INRIA, CNRS and the University of Bordeaux I, II, France.\nEuro-Par 2011: http://europar2011.bordeaux.inria.fr/ \n\n\n',NULL,NULL),('<1305539108.126.1365919542028.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-14 06:05:42',0,'2013-04-14 06:05:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #4','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/4/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-14 06:05:37    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:05:37,548 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-14 06:05:37,548 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:05:37,549 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,549 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,550 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-14 06:05:37,551 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-14 06:05:37,551 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-14 06:05:37  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-14 06:05:37,552 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:05:37    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:05:37,553 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,556 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.555853\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.555853\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37,556 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,557 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,557 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,558 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37,559 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.558783\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.558783\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37,560 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,560 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,561 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:05:37,562 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,562 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,563 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37,564 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.563677\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.563677\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37,565 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,565 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,566 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:05:37,567 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,567 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,568 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37,569 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.568422\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.568422\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37,569 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,570 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,570 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:05:37,571 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,572 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,573 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:05:37,574 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:05:37,574 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.574157\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:05:37.574157\', resource_metadata={}) from 0 transformer\n2013-04-14 06:05:37,575 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,576 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37,576 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:05:37,577 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:05:37,578 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 16.979s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.4\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a45.g4bf4390\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a308.g497b423\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.XXivv6Rf98\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/4\n[SCP] Copying console log.\n\n\n','<99941929.112.1365833214275.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1306107738.4974833.1396029747425.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 14:02:27',-14400,'2014-03-28 18:02:27',NULL,'[openstack-dev] [keystone] [horizon] [nova]','Currently, when you delete a tenant that has 1 or more running instances, the tenant will be deleted\nwithout warning and the running instance(s) will be left in place. Should there be a warning\nand should the admin be allowed to do this?  Or should it be left be?\n\nThanks,\n-Ryan Hallisey\n\n\n\n','<1570657909.4973122.1396029397718.JavaMail.zimbra@redhat.com>',NULL);
INSERT INTO `messages` VALUES ('<1306395356.65.1373523342372.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-11 06:15:42',0,'2013-07-11 06:15:42',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #184','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/184/>\n\n------------------------------------------\n[...truncated 21314 lines...]\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova secgroup-list-rules vol_secgroup\n+ grep -q \' tcp .* 22 \'\n+ nova secgroup-add-rule vol_secgroup tcp 22 22 0.0.0.0/0\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| tcp         | 22        | 22      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova secgroup-list-rules vol_secgroup\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n| tcp         | 22        | 22      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova flavor-list\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |\n| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      |\n| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      |\n| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |\n| 42 | m1.nano   | 64        | 0    | 0         |      | 1     | 1.0         | True      |\n| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |\n| 84 | m1.micro  | 128       | 0    | 0         |      | 1     | 1.0         | True      |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n++ nova flavor-list\n++ grep m1.tiny\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ INSTANCE_TYPE=1\n+ [[ -z 1 ]]\n+ nova delete ex-vol-inst\nERROR: Unable to delete any of the specified servers.\nNo server with a name or ID of \'ex-vol-inst\' exists.\n+ true\n+ timeout 90 sh -c \'while nova show ex-vol-inst; do sleep 1; done\'\nERROR: No server with a name or ID of \'ex-vol-inst\' exists.\n++ nova boot --flavor 1 --image a2dd07dc-6c96-4c6e-8575-9f11a6adfc21 --security_groups=vol_secgroup ex-vol-inst\n++ grep \' id \'\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| id                                   | a6b80a08-dd58-43b3-b572-b19f43d94563 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ VM_UUID=a6b80a08-dd58-43b3-b572-b19f43d94563\n+ die_if_not_set 124 VM_UUID \'Failure launching ex-vol-inst\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ timeout 90 sh -c \'while ! nova show a6b80a08-dd58-43b3-b572-b19f43d94563 | grep status | grep -q ACTIVE; do sleep 1; done\'\n++ nova show a6b80a08-dd58-43b3-b572-b19f43d94563\n++ grep private\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| private network                      | 10.1.0.3                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.3\n+ die_if_not_set 133 IP \'Failure retrieving IP address\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ ping_check private 10.1.0.3 90\n+ is_service_enabled neutron\n+ services=neutron\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,neutron, ]]\n+ [[ neutron == \\n\\o\\v\\a ]]\n+ [[ neutron == \\c\\i\\n\\d\\e\\r ]]\n+ [[ neutron == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ neutron == \\g\\l\\a\\n\\c\\e ]]\n+ [[ neutron == \\n\\e\\u\\t\\r\\o\\n ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net =~ q- ]]\n+ [[ neutron == \\s\\w\\i\\f\\t ]]\n+ [[ neutron == s-* ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.3 90\n+ local from_net=private\n+ local ip=10.1.0.3\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.3; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.3; do sleep 1; done\'\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n64 bytes from 10.1.0.3: icmp_req=1 ttl=64 time=3.49 ms\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 3.490/3.490/3.490/0.000 ms\n++ cinder list\n++ grep ex-vol-53fe9821\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1373523223\n+ cinder create --display_name ex-vol-53fe9821 --display_description \'test volume: ex-vol-53fe9821\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-07-11T06:13:44.322114      |\n| display_description |     test volume: ex-vol-53fe9821     |\n|     display_name    |           ex-vol-53fe9821            |\n|          id         | e070eddb-056f-4ca7-bfc7-874b44c3a2a2 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-53fe9821 | grep available; do sleep 1; done\'\n+ die 151 \'Volume ex-vol-53fe9821 not created\'\n+ local exitcode=0\n+ set +o xtrace\n[ERROR] /opt/stack/new/devstack/exercises/volumes.sh:151 Volume ex-vol-53fe9821 not created\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nFAILED euca\nFAILED volumes\n=====================================================================\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/rabbitmq/rabbit at devstack-1373522491-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/rabbitmq/rabbit at devstack-1373522491.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/184/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1306862271.39.1381299207457.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-09 06:13:27',0,'2013-10-09 06:13:27',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #39','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/39/>\n\n\n\n','<1547906396.28.1380953445876.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1306880854.14638803.1384447781028.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 08:49:41',-28800,'2013-11-14 16:49:41',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update\n 2013-11-14','\nGreetings Stackers!\n\nI hope you had a great time at the Summit! I\'m expecting the VMwareAPI sub-team\'s priorities to shift around a bit as we digest the outcomes from the sessions. So, with that in mind, I\'ll stick to just updating on what reviews are in flight and where they are as far as our crack team of trusted reviewers is concerned. We\'ll worry about priority order more as we close on the milestones.\n\nBTW: I\'ve noticed a trend of folks starting to put \"VMware:\" in the titles of their reviews that are related to the drivers or need VMware subject matter expert\'s examination, that\'s a nice touch and will make searching easier for people. I encourage it. \n\nBBTW: Note that the meeting times are UTC and UTC does not have day light savings time so if you are in a country that observes such things your meeting times may have changed. I\'m open to a new meeting time and format if people want to discuss it. \n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n* If anything is missing, email me and I\'ll check it.\n* We hang out in #openstack-vmware if you need to chat & it\'s not worth spamming the whole list\n\nHappy stacking!\n--------------------------------------------------------------------------------\n\nOrdered by fitness for review:\n\n== needs one more +2/approval ==\n* https://review.openstack.org/47743\n	title: \'VMWare: bug fix for Vim exception handling\'\n	votes: +2:1, +1:6, -1:0, -2:0. +52 days in progress, revision: 10 is 24 days old \n* https://review.openstack.org/53109\n	title: \'VMware: enable driver to work with postgres database\'\n	votes: +2:1, +1:8, -1:0, -2:0. +22 days in progress, revision: 2 is 22 days old \n* https://review.openstack.org/49305\n	title: \'VMware: fix snapshot failure when host in maintenance mode\'\n	votes: +2:1, +1:7, -1:0, -2:0. +42 days in progress, revision: 15 is 12 days old \n\n== ready for core ==\n* https://review.openstack.org/54361\n	title: \'VMware: fix datastore selection when token is returned\'\n	votes: +2:0, +1:6, -1:0, -2:0. +15 days in progress, revision: 5 is 14 days old \n\n== needs review ==\n* https://review.openstack.org/55038\n	title: \'VMware: bug fix for VM rescue when config drive is config...\'\n	votes: +2:0, +1:4, -1:0, -2:0. +11 days in progress, revision: 2 is 10 days old \n* https://review.openstack.org/55934\n	title: \'Always upload a snapshot as a preallocated disk\'\n	votes: +2:0, +1:2, -1:0, -2:0. +2 days in progress, revision: 2 is 1 days old \n* https://review.openstack.org/52645\n	title: \'VMware: Detach volume should not delete vmdk\'\n	votes: +2:0, +1:4, -1:0, -2:0. +26 days in progress, revision: 14 is 1 days old \n* https://review.openstack.org/55509\n	title: \'VMware: fix VM resize bug\'\n	votes: +2:0, +1:3, -1:0, -2:0. +6 days in progress, revision: 1 is 6 days old \n* https://review.openstack.org/53648\n	title: \'VMware: fix image snapshot with attached volume\'\n	votes: +2:0, +1:3, -1:0, -2:0. +20 days in progress, revision: 1 is 20 days old \n* https://review.openstack.org/55505\n	title: \'VMware: Handle cases when there are no hosts in cluster\'\n	votes: +2:0, +1:1, -1:0, -2:0. +6 days in progress, revision: 1 is 6 days old \n* https://review.openstack.org/55070\n	title: \'VMware: fix rescue with disks are not hot-addable\'\n	votes: +2:0, +1:4, -1:0, -2:0. +10 days in progress, revision: 1 is 10 days old \n* https://review.openstack.org/52630\n	title: \'VMware: fix bug when more than one datacenter exists\'\n	votes: +2:0, +1:3, -1:0, -2:0. +26 days in progress, revision: 10 is 8 days old \n* https://review.openstack.org/52630\n	title: \'VMware: fix bug when more than one datacenter exists\'\n	votes: +2:0, +1:3, -1:0, -2:0. +26 days in progress, revision: 10 is 8 days old \n* https://review.openstack.org/54808\n	title: \'VMware: fix bug for exceptions thrown in _wait_for_task\'\n	votes: +2:0, +1:1, -1:0, -2:0. +13 days in progress, revision: 2 is 11 days old \n* https://review.openstack.org/52557\n	title: \'VMware Driver update correct disk usage stat\'\n	votes: +2:0, +1:0, -1:0, -2:0. +27 days in progress, revision: 1 is 27 days old \n* https://review.openstack.org/43270\n	title: \'vmware driver selection of vm_folder_ref.\'\n	votes: +2:0, +1:1, -1:0, -2:0. +83 days in progress, revision: 1 is 83 days old \n\n== needs revision ==\n* https://review.openstack.org/56278\n	title: \'VMware: bug in rebooting powered off instance\'\n	votes: +2:0, +1:1, -1:1, -2:0. +0 days in progress, revision: 1 is 0 days old \n* https://review.openstack.org/48544\n	title: \'VMWare - Fix when a image upload is interrupted it\'s not ...\'\n	votes: +2:0, +1:2, -1:2, -2:0. +48 days in progress, revision: 15 is 8 days old \n* https://review.openstack.org/52478\n	title: \'VMware: Refactor vim_util to reuse existing util method\'\n	votes: +2:0, +1:2, -1:1, -2:0. +27 days in progress, revision: 2 is 1 days old \n* https://review.openstack.org/49692\n	title: \'VMware: iscsi target discovery fails while attaching volumes\'\n	votes: +2:0, +1:2, -1:1, -2:0. +40 days in progress, revision: 9 is 1 days old \n* https://review.openstack.org/53976\n	title: \'VMware: Fix VSAN datastores cannot be used\'\n	votes: +2:0, +1:0, -1:1, -2:0. +19 days in progress, revision: 5 is 14 days old \n* https://review.openstack.org/53990\n	title: \'VMware ESX: Boot from volume must not relocate vol\'\n	votes: +2:0, +1:5, -1:1, -2:0. +18 days in progress, revision: 3 is 18 days old \n\n# Shawn Hartsock\n\n\n','<1431030050.14538876.1384446107702.JavaMail.root@vmware.com>',NULL),('<1307139606.25.1380003343582.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-24 06:15:43',0,'2013-09-24 06:15:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #26','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/26/>\n\n\n\n','<2100391012.21.1379916935686.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1307196406.92839.1351271237177.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-26 10:07:17',-25200,'2012-10-26 17:07:17',NULL,'[openstack-dev] new mailing list for bare-metal provisioning','\n Hello all,\n\n An openstack mailing list is created for the discussion of bare-metal provisioning.\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-baremetal\n\n Please join it if you are interested in participating the dicussion/collaboration\nof bare-metal provisioning.\n\n Thanks,\n David\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n\n','<1904146415.92742.1351269589128.JavaMail.root@zm.isi.edu>',NULL),('<1307258680.35948146.1408634073584.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 11:14:33',-14400,'2014-08-21 15:14:33',NULL,'[openstack-dev] [nova][libvirt] Non-readonly connection to\n libvirt in unit tests','(reply inline)\n\n----- Original Message -----\n> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, August 21, 2014 11:05:18 AM\n> Subject: Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests\n> \n> On Thu, Aug 21, 2014 at 10:52:42AM -0400, Solly Ross wrote:\n> > FYI, the context of this is that I would like to be able to test some\n> > of the libvirt storage pool code against a live file system, as we\n> > currently test the storage pool code.  To do this, we need at least to\n> > be able to get a proper connection to a session daemon.  IMHO, since\n> > these calls aren\'t \"expensive\", so to speak, it should be fine to have\n> > them run against a real libvirt.\n> \n> No it really isn\'t OK to run against the real libvirt host system when\n> in the unit tests. Unit tests must *not* rely on external system state\n> in this way because it will lead to greater instability and unreliability\n> of our unit tests. If you want to test stuff against the real libvirt\n> storage pools then that becomes a functional / integration test suite\n> which is pretty much what tempest is targetting.\n\nThat\'s all well and good, but we *currently* manipulates the actual file\nsystem manually in tests.  Should we then say that we should never manipulate\nthe actual file system either?  In that case, there are some tests which\nneed to be refactored.\n\n>  \n> > > So If we require libvirt-python for tests and that requires\n> > > libvirt-bin, what\'s stopping us from just removing fakelibvirt since\n> > > it\'s kind of useless now anyway, right?\n> > \n> > The thing about fakelibvirt is that it allows us to operate against\n> > against a libvirt API without actually doing libvirt-y things like\n> > launching VMs.  Now, libvirt does have a \"test:///default\" URI that\n> > IIRC has similar functionality, so we could start to phase out fake\n> > libvirt in favor of that.  However, there are probably still some\n> > spots where we\'ll want to use fakelibvirt.\n> \n> I\'m actually increasingly of the opinion that we should not in fact\n> be trying to use the real libvirt library in the unit tests at all\n> as it is not really adding any value. We typically nmock out all the\n> actual API calls we exercise so despite \"using\" libvirt-python we\n> are not in fact exercising its code or even validating that we\'re\n> passing the correct numbers of parameters to API calls. Pretty much\n> all we really relying on is the existance of the various global\n> constants that are defined, and that has been nothing but trouble\n> because the constants may or may not be defined depending on the\n> version.\n\nIsn\'t that what \'test:///default\' is supposed to be?  A version of libvirt\nwith libvirt not actually touching the rest of the system?\n\n> \n> The downside of fakelibvirt is that it is a half-assed implementation\n> of libvirt that we evolve in an adhoc fashion. I\'m exploring the idea\n> of using pythons introspection abilities to query the libvirt-python\n> API and automatically generate a better \'fakelibvirt\' that we can\n> guarantee to match the signatures of the real libvirt library. If we\n> had something like that which we had more confidence in, then we could\n> make the unit tests use that unconditionally. This would make our unit\n> tests more reliable since we would not be suspectible to different API\n> coverage in different libvirt module versions which have tripped us up\n> so many times\n> \n> Regards,\n> Daniel\n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140821150518.GG6671@redhat.com>',NULL),('<1308153210.2888798.1390470402818.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 10:46:42',3600,'2014-01-23 09:46:42',NULL,'[openstack-dev] [Swift] domain-level quotas','Hello Christian,\n\n----- Original Message -----\n> From: \"Christian Schwede\" <christian.schwede at enovance.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>, \"Matthieu\n> Huin\" <matthieu.huin at enovance.com>\n> Sent: Wednesday, January 22, 2014 10:47:24 PM\n> Subject: Re: [openstack-dev] [Swift] domain-level quotas\n> \n> Hi Matthieu,\n> \n> Am 22.01.14 20:02, schrieb Matthieu Huin:\n> > The idea is to have a middleware checking a domain\'s current usage\n> > against a limit set in the configuration before allowing an upload.\n> > The domain id can be extracted from the token, then used to query\n> > keystone for a list of projects belonging to the domain. Swift would\n> > then compute the domain usage in a similar fashion as the way it is\n> > currently done for accounts, and proceed from there.\n> \n> the problem might be to compute the current usage of all accounts within\n> a domain. It won\'t be a problem if you have only a few accounts in a\n> domain, but with tens, hundreds or even thousands accounts in a domain\n> there will be a performance impact because you need to iterate over all\n> accounts (doing a HEAD on every account) and sum up the total usage.\n\nOne might object that this is already a concern when applying quotas to potentially huge accounts with lots of containers, although I agree that domains add an order of magnitude to this problem.\n\n> I think some performance tests would be helpful (doing a HEAD on all\n> accounts repeatedly with some PUTs in-between) to see if the performance\n> impact is an issue at all (since there will be a lot of caching involved).\n> \n> Christian\n> \n\nYes, this is a sound plan. Thanks for the feedback !\n\nMatthieu\n\n\n','<52E03C6C.80006@enovance.com>',NULL),('<1308279226.1014010.1384963276076.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 17:01:16',3600,'2013-11-20 16:01:16',NULL,'[openstack-dev]  [horizon] Javascript development improvement','Hi all, I know it is pretty annoying but I have to resurrect this subject.\n\nWith the integration of Angularjs into Horizon we will encounter a lot of issues with javascript. I ask you to reconsider to bring back Nodejs as a development platform. I am not talking about production, we are all agree that Node is not ready for production, and we do not want it as a backend. But the facts are that we need a lot of its features, which will increase the tests and the development. Currently, we do not have any javascript code quality: jslint is a great tool and can be used easily into node. Angularjs also provides end-to-end testing based on nodejs again, testing is important especially if we start to put more logic into JS. Selenium is used just to run qUnit tests, we can bring back these tests into node and have a clean unified testing platform. Tests will be easier to perform. \n\nFinally, (do not punch me in the face) lessc which is used for bootstrap is completely integrated into it. I am afraid that modern javascript development can not be perform without this tool.\n\nRegards\n\nMaxime Vidori\n\n\n\n','<1635204.vPSZkMFmxb@bort.suse.de>',NULL),('<1308710589.18391947.1416944377502.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 14:39:37',-18000,'2014-11-25 19:39:37',NULL,'[openstack-dev] [NFV][Telco] Meeting Reminder - Wednesday @ 2200 UTC','Hi all,\n\nJust a reminder - there is a Telco working group meeting at 2200 UTC on Wednesday in #openstack-meeting. If you have items you wish to add to the agenda please add them to the etherpad:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nNote that I fully expect attendance will take a hit as it\'s the day before the US Thanksgiving holiday but think it\'s worth trying to continue moving forward with those who are still available.\n\nThanks,\n\nSteve\n\n\n','<1738198029.18357550.1416941809931.JavaMail.zimbra@redhat.com>',NULL),('<1308710589.18391947.1416944377502.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-25 14:39:37',-18000,'2014-11-25 19:39:37',NULL,'[Openstack-operators] [NFV][Telco] Meeting Reminder - Wednesday @\n	2200 UTC','Hi all,\n\nJust a reminder - there is a Telco working group meeting at 2200 UTC on Wednesday in #openstack-meeting. If you have items you wish to add to the agenda please add them to the etherpad:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nNote that I fully expect attendance will take a hit as it\'s the day before the US Thanksgiving holiday but think it\'s worth trying to continue moving forward with those who are still available.\n\nThanks,\n\nSteve\n\n\n','<1738198029.18357550.1416941809931.JavaMail.zimbra@redhat.com>',NULL),('<1308917220.21464900.1384194394488.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 13:26:34',-18000,'2013-11-11 18:26:34',NULL,'[openstack-dev] [Solum] Some initial code copying\n	for	db/migration','\n\n----- Original Message -----\n> > 1) Using objects as an abstraction for versioned data:\n> >    This seems like a good direction overall, especially from the\n> >    point-of-view\n> >    of backwards compatibility of consumers of the object. However, after\n> >    looking through some\n> >    of the objects defined in nova/objects/, I am not sure if I understand\n> >    how\n> >    this works. Specifically, it is not clear to me how might the consumer\n> >    of the\n> >    object be able to query different versions of it at runtime.\n> \n> The object registry is handled by the metaclass in objects/base.py. It\n> automatically collects objects that inherit from NovaObject, and allows\n> multiple versions of the same object to exist. We don\'t have anything\n> that needs to specifically ask the registry directly for \"foo object\n> version X\", so there\'s no interface for doing that right now. We do,\n> however, have incoming objects over RPC that need to be re-hydrated,\n> with an \"is this compatible\" version check. We also have the ability to\n> downlevel an object using the obj_make_compatible() method. We are\n> planning to always roll the conductor code first, which means it can\n> take the newest version of an object from the schema (in whatever state\n> it\'s in) and backlevel it to the version being asked for by a remote RPC\n> client.\n\nFor places where we may not have an RPC isolation layer, it\'s similar - the code knows what version of the schema to ask for, and the object abstraction hides the details of converting between older to newer.\n\nWe probably need to map out the scenarios where multiversion is enabled for live upgrade - that\'s the most critical place where you need to ask for specific versions.  The Google F1 live schema change paper has a good summary of the core issues [1] (and a great diagram on page 9) with live schema migration that apply to generic SQL dbs as well.  There are five distinct phases:\n\n  1) new code is available that can read the old schema and the new schema, but continues to read the old schema\n  2) additive elements of the new schema are enabled\n  3) new code begins copying/deleting data as its read / updated, and a background process is converting the rest of the data\n  4) new code starts reading/querying the new fields\n  5) old schema data is dropped once all code is reading the new schema\n\nThe new code has to know whether it should read the new or old schema - it can\'t read the new schema (query by new column names, by updated data, etc) until all of the reads are complete and in place in #4.  That could be a config value, something in memory triggered by an admin, etc.\n\n> \n> > 2) Using objects as an abstraction to support different kinds of backends\n> >    (SQL and non-SQL backends):\n> >    - Again, a good direction overall. From implementation point-of-view\n> >    though\n> >    this may become tricky, in the sense that the object layer would need to\n> >    be\n> >    designed with just the right amount of logic so as to be able to work\n> >    with either\n> >    a SQL or a non-SQL backend. It will be good to see some examples of how\n> >    this might\n> >    be done if there are any existing examples somewhere.\n> \n> We don\'t have any examples of using a non-SQL backend for general\n> persistence in Nova, which means we don\'t have an example of using\n> objects to hide it. If what NovaObject currently provides is not\n> sufficient to hide the intricacies of a non-SQL persistence layer, I\n> think it\'s probably best to build that on top of what we\'ve got in the\n> object model.\n\nThe abstraction will probably always leak something, but in general it comes down to isolating a full transaction behind a coarse method.  Was going to try to demonstrate that as I went.\n\n[1] http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/41376.pdf\n\n\n','<527D7649.5090304@danplanet.com>',NULL),('<1308939009.16391212.1421944019860.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2015-01-22 11:26:59',-18000,'2015-01-22 16:26:59',NULL,'[OpenStack-docs] [networking] Meeting summary 1/16/15','----- Original Message -----\n> From: \"Nick Chase\" <nchase at mirantis.com>\n> To: \"Anita Kuno\" <anteaya at anteaya.info>, \"Matt Kassawara\" <mkassawara at gmail.com>\n> \n> Absolutely, Anita!  We meet in a Google Hangout on Friday mornings at\n> 9am Pacific.  Let me know if you\'d like an invite.\n> \n> thanks!\n> \n> ----  Nick\n\nFWIW even for meetings that aren\'t using IRC as the conduit I think it\'s worth listing them on the Meetings wiki so that they are discoverable (I had a similar challenge tracking down where Win The Enterprise meetings were occurring until they were recently published to a wiki page).\n\n-Steve\n \n> On 1/22/2015 10:48 AM, Anita Kuno wrote:\n> > On 01/21/2015 09:54 AM, Matt Kassawara wrote:\n> >> They\'re not official documentation team meetings... probably because most\n> >> of the people who attend aren\'t part of the documentation team. For the\n> >> most part, Nick Chase (nchase at mirantis.com) schedules the networking guide\n> >> meetings.\n> >>\n> > Great, thank Matt.\n> >\n> > Where do you meet, Nick? I\'m trying to learn if I can join you.\n> >\n> > Thanks,\n> > Anita.\n> >\n> >> On Wed, Jan 21, 2015 at 9:39 AM, Anita Kuno <anteaya at anteaya.info> wrote:\n> >>\n> >>> On 01/21/2015 12:27 AM, Nick Chase wrote:\n> >>>> Status reports from the meeting (thanks to Matt for keeping track):\n> >>>>\n> >>>> Matt\n> >>>> ---\n> >>>> - working on basic/classic/legacy openvswitch scenario\n> >>>> - mostly finished diagrams, working on text next. hopefully merge\n> >>>> content in the next few days.\n> >>>> - content here:\n> >>>>\n> >>> https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-ovs/scenario-legacy-ovs.md\n> >>>>\n> >>>> Phil\n> >>>> ---\n> >>>> - working on l3 ha scenario\n> >>>> - content here:\n> >>>> https://github.com/phil-hopkins-a/openstack-networking-guide\n> >>>> - running into issues with lb/vxlan/l2pop, need to resolve for proper\n> >>>> documentation\n> >>>>\n> >>>> Sean\n> >>>> ---\n> >>>> - working on provider networking scenario diagrams\n> >>>> - content here:\n> >>>>\n> >>> https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-providernet/scenario-providernet.md\n> >>>>\n> >>>> Edgar\n> >>>> ---\n> >>>> - working on nova-network to neutron conversion process\n> >>>> - will review the legacy neutron openvswitch scenario content\n> >>>>\n> >>>> Swami\n> >>>> ---\n> >>>> - working on neutron legacy to dvr conversion process\n> >>>>\n> >>>> Since the meeting:\n> >>>>\n> >>>> Matt has completed the first pass of the Neutron legacy with OVS\n> >>>> scenario and has made it available for review\n> >>>> (\n> >>> https://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-ovs/scenario-legacy-ovs.md\n> >>> ).\n> >>>> He has also incorporated changes to the DVR content.\n> >>>>\n> >>>> Next meeting January 23 at noon EST.\n> >>>>\n> >>>> Thanks, all!\n> >>>>\n> >>>> -----  Nick\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-docs mailing list\n> >>>> OpenStack-docs at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >>> Hello all:\n> >>>\n> >>> Where do you conduct your meetings? I am trying to figure out if I can\n> >>> attend.\n> >>>\n> >>> So far I have been unable to find your meeting information on\n> >>> https://wiki.openstack.org/wiki/Meetings\n> >>>\n> >>> Thank you,\n> >>> Anita Kuno.\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-docs mailing list\n> >>> OpenStack-docs at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >>>\n> >\n> \n> \n> _______________________________________________\n> OpenStack-docs mailing list\n> OpenStack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<54C12212.4070508@mirantis.com>',NULL),('<1309175910.17154804.1393433725677.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 11:55:25',-18000,'2014-02-26 16:55:25',NULL,'[openstack-dev] New Websockify Release','Greetings!\n\nWe (the websockify/noVNC team) have released a new version of websockify (0.6.0).  It contains several fixes and features relating to OpenStack (a couple of bugs were fixed, and native support for the `logging` module was added).  Unfortunately, to integrate it into OpenStack, a patch is needed to the websocketproxy code in Nova (https://gist.github.com/DirectXMan12/9233369) due to a refactoring of the websockify API.  My concern is that the various distos most likely have not had time to update the package in their package repositories.  What is the appropriate timescale for updating Nova to work with the new version?\n\nBest Regards,\nSolly Ross\n\n\n','<1698156354.17149968.1393433393085.JavaMail.zimbra@redhat.com>',NULL),('<1309192640.38944.YahooMailNeo@web36306.mail.mud.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-06-27 09:37:20',-25200,'2011-06-27 16:37:20',NULL,'[Openstack-operators] Problem using Curl with Swift.','In step 4, try:\n\ncurl -k -i -H \"X-Auth-Token: $XT\" -X PUT $XU/test-container\n\n\n\n________________________________\nFrom: e.testingcloud <e.testingcloud at tid.es>\nTo: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org>\nSent: Monday, June 27, 2011 2:46 AM\nSubject: [Openstack-operators] Problem using Curl with Swift.\n\nHi.\n\nI\'m doing test with Swift and Curl and I have the next problem.\n\n1. I create the user.\n\nswauth-add-user -A http://192.168.8.106:8080/auth/ -K beto -a openstack tester2 testerpass2\n\n2. I get the X-Storage-Url and X-Auth-Token\n\ncurl -k -v -H \'X-Storage-User: openstack:tester2\' -H \'X-Storage-Pass: testerpass2\' http://192.168.8.106:8080/auth/v1.0 \n* About to connect() to 192.168.8.106 port 8080 (#0)\n*?  Trying 192.168.8.106... connected\n* Connected to 192.168.8.106 (192.168.8.106) port 8080 (#0)\n> GET /auth/v1.0 HTTP/1.1\n> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n> Host: 192.168.8.106:8080\n> Accept: */*\n> X-Storage-User: openstack:tester2\n> X-Storage-Pass: testerpass2\n>\n< HTTP/1.1 200 OK\n< X-Storage-Url: https://127.0.0.1:8080/v1/AUTH_41bd9ba4-60bc-4b45-bc00-298bac9ba239 \n< X-Storage-Token: AUTH_tkaf8d1d9b65174e77a57e9493775aaa14\n< X-Auth-Token: AUTH_tkaf8d1d9b65174e77a57e9493775aaa14\n< Content-Length: 113\n< Date: Mon, 27 Jun 2011 09:26:12 GMT\n<\n* Connection #0 to host 192.168.8.106 left intact\n* Closing connection #0\n{\"storage\": {\"default\": \"local\", \"local\": \"https://127.0.0.1:8080/v1/AUTH_41bd9ba4-60bc-4b45-bc00-298bac9ba239\"}}\n\n3. environtment\n\nexport XU=\"https://127.0.0.1:8080/v1/AUTH_41bd9ba4-60bc-4b45-bc00-298bac9ba239\"\nexport XT=\"AUTH_tkaf8d1d9b65174e77a57e9493775aaa14\"\n\n4. Create a container.\n\ncurl -k -i -H \"$XT\" -X PUT $XU/test-container\nHTTP/1.1 401 Unauthorized\nContent-Length: 358\nContent-Type: text/html; charset=UTF-8\nDate: Mon, 27 Jun 2011 09:42:40 GMT\n\n<html>\n<head>\n? <title>401 Unauthorized</title>\n</head>\n<body>\n? <h1>401 Unauthorized</h1>\n? This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.<br /><br />\n\n\n\n</body>\n</html>\n\n\nAlways I get the same error. I\'m not authorized, but the X-Auth-Token and X-Storage-Url are correct.\nSomebody can help me please?\n\nThanks in advance.\n\nEste mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.\nThis message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.\nhttp://www.tid.es/ES/PAGINAS/disclaimer.aspx \n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110627/177764c6/attachment.html>\n\n','<8EE61BA0CAEDBD4E9DA928D1206463D2A184D0EED4@EXCLU2K7.hi.inet>',NULL),('<1309342726.711866.1409839497576.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:04:57',-14400,'2014-09-04 14:04:57',NULL,'[openstack-dev] [all] Design Summit reloaded','\n\n> Hi everyone,\n> \n> I\'ve been thinking about what changes we can bring to the Design Summit\n> format to make it more productive. I\'ve heard the feedback from the\n> mid-cycle meetups and would like to apply some of those ideas for Paris,\n> within the constraints we have (already booked space and time). Here is\n> something we could do:\n> \n> Day 1. Cross-project sessions / incubated projects / other projects\n> \n> I think that worked well last time. 3 parallel rooms where we can\n> address top cross-project questions, discuss the results of the various\n> experiments we conducted during juno. Don\'t hesitate to schedule 2 slots\n> for discussions, so that we have time to come to the bottom of those\n> issues. Incubated projects (and maybe \"other\" projects, if space allows)\n> occupy the remaining space on day 1, and could occupy \"pods\" on the\n> other days.\n> \n> Day 2 and Day 3. Scheduled sessions for various programs\n> \n> That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> available. So, rather than trying to cover all the scope, the idea would\n> be to focus those sessions on specific issues which really require\n> face-to-face discussion (which can\'t be solved on the ML or using spec\n> discussion) *or* require a lot of user feedback. That way, appearing in\n> the general schedule is very helpful. This will require us to be a lot\n> stricter on what we accept there and what we don\'t -- we won\'t have\n> space for courtesy sessions anymore, and traditional/unnecessary\n> sessions (like my traditional \"release schedule\" one) should just move\n> to the mailing-list.\n> \n> Day 4. Contributors meetups\n> \n> On the last day, we could try to split the space so that we can conduct\n> parallel midcycle-meetup-like contributors gatherings, with no time\n> boundaries and an open agenda. Large projects could get a full day,\n> smaller projects would get half a day (but could continue the discussion\n> in a local bar). Ideally that meetup would end with some alignment on\n> release goals, but the idea is to make the best of that time together to\n> solve the issues you have. Friday would finish with the design summit\n> feedback session, for those who are still around.\n> \n> \n> I think this proposal makes the best use of our setup: discuss clear\n> cross-project issues, address key specific topics which need\n> face-to-face time and broader attendance, then try to replicate the\n> success of midcycle meetup-like open unscheduled time to discuss\n> whatever is hot at this point.\n> \n> There are still details to work out (is it possible split the space,\n> should we use the usual design summit CFP website to organize the\n> \"scheduled\" time...), but I would first like to have your feedback on\n> this format. Also if you have alternative proposals that would make a\n> better use of our 4 days, let me know.\n\nApologies for jumping on this thread late.\n\nI\'m all for the idea of accommodating a more fluid form of project-\nspecific discussion, with the schedule emerging in a dynamic way. \n\nBut one aspect of the proposed summit redesign that isn\'t fully clear\nto me is the cross-over between the new \"Contributors meetups\" and the\n\"Project pods\" that we tried out for the first time in Atlanta.\n\nThat seemed, to me at least, to be a very useful experiment. In fact:\n\n \"parallel midcycle-meetup-like contributors gatherings, with no time\n  boundaries and an open agenda\"\n\nsounds like quite a good description of how some projects used their\npods in ATL.\n\nThe advantage of the pods approach in my mind, included:\n\n * no requirement for reducing the number of design sessions slots,\n   as the pod time ran in parallel with the design session tracks\n   of other projects\n\n * depending on where in the week the project track occurred, the\n   pod time could include a chunk of scene-setting/preparation \n   discussion *in advance of* the more structured design sessions\n\n * on a related theme, the pods did not rely on the \"graveyard shift\"\n   at the backend of the summit when folks tend to hit their Friday\n   afternoon \"brain-full\" state\n\nAm I missing some compelling advantage of moving all these emergent\nproject-specific meetups to the Friday?\n\nCheers,\nEoghan\n\n\n','<53FDD46B.5090206@openstack.org>',NULL),('<1309494357.27.1352592058909.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-11 00:00:58',0,'2012-11-11 00:00:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-diablo #89','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/89/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/>\nCheckout:periodic-horizon-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson1545277108242723915.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-diablo/89\n[SCP] Copying console log.\n\n\n','<1438567161.14.1352505665734.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1309983215.14.1382855289067.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-27 06:28:08',0,'2013-10-27 06:28:08',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #41','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/41/>\n\n------------------------------------------\n[...truncated 18278 lines...]\n2013-10-27 06:07:51 catalog_type = object-store\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # The name of a region for object storage. If empty or commented-out, the\n2013-10-27 06:07:51 # value of identity.region is used instead. If no such region is found in\n2013-10-27 06:07:51 # the service catalog, the first found one is used.\n2013-10-27 06:07:51 #region = RegionOne\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Number of seconds to time on waiting for a container to container\n2013-10-27 06:07:51 # synchronization complete\n2013-10-27 06:07:51 container_sync_timeout = 120\n2013-10-27 06:07:51 # Number of seconds to wait while looping to check the status of a\n2013-10-27 06:07:51 # container to container synchronization\n2013-10-27 06:07:51 container_sync_interval = 5\n2013-10-27 06:07:51 # Set to True if the Account Quota middleware is enabled\n2013-10-27 06:07:51 accounts_quotas_available = True\n2013-10-27 06:07:51 # Set to True if the Container Quota middleware is enabled\n2013-10-27 06:07:51 container_quotas_available = True\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Set operator role for tests that require creating a container\n2013-10-27 06:07:51 operator_role = Member\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 [boto]\n2013-10-27 06:07:51 ssh_user = cirros\n2013-10-27 06:07:51 # This section contains configuration options used when executing tests\n2013-10-27 06:07:51 # with boto.\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # EC2 URL\n2013-10-27 06:07:51 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-10-27 06:07:51 # S3 URL\n2013-10-27 06:07:51 s3_url = http://127.0.0.1:3333\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-10-27 06:07:51 aws_access =\n2013-10-27 06:07:51 aws_secret =\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Image materials for S3 upload\n2013-10-27 06:07:51 # ALL content of the specified directory will be uploaded to S3\n2013-10-27 06:07:51 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # The manifest.xml files, must be in the s3_materials_path directory\n2013-10-27 06:07:51 # Subdirectories not allowed!\n2013-10-27 06:07:51 # The filenames will be used as a Keys in the S3 Buckets\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-10-27 06:07:51 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-10-27 06:07:51 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-10-27 06:07:51 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Instance type\n2013-10-27 06:07:51 instance_type = m1.nano\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # TCP/IP connection timeout\n2013-10-27 06:07:51 http_socket_timeout = 30\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Number of retries actions on connection or 5xx error\n2013-10-27 06:07:51 num_retries = 1\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Status change wait timout\n2013-10-27 06:07:51 build_timeout = 400\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # Status change wait interval\n2013-10-27 06:07:51 build_interval = 1\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 [orchestration]\n2013-10-27 06:07:51 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-10-27 06:07:51 # custom Keystone service catalog implementation, you probably want to leave\n2013-10-27 06:07:51 # this value as \"orchestration\"\n2013-10-27 06:07:51 catalog_type = orchestration\n2013-10-27 06:07:51 \n2013-10-27 06:07:51 # The name of a region for orchestration. If empty or commented-out, the value\n2013-10-27 06:07:52 # of identity.region is used instead. If no such region is found in the service\n2013-10-27 06:07:52 # catalog, the first found one is used.\n2013-10-27 06:07:52 #region = RegionOne\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # Status change wait interval\n2013-10-27 06:07:52 build_interval = 1\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # Status change wait timout. This may vary across environments as some some\n2013-10-27 06:07:52 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-10-27 06:07:52 build_timeout = 300\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # Instance type for tests. Needs to be big enough for a\n2013-10-27 06:07:52 # full OS plus the test workload\n2013-10-27 06:07:52 instance_type = m1.micro\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # Name of heat-cfntools enabled image to use when launching test instances\n2013-10-27 06:07:52 # If not specified, tests that spawn instances will not run\n2013-10-27 06:07:52 #image_ref = ubuntu-vm-heat-cfntools\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # Name of existing keypair to launch servers with. The default is not to specify\n2013-10-27 06:07:52 # any key, which will generate a keypair for each test class\n2013-10-27 06:07:52 #keypair_name = heat_key\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 [dashboard]\n2013-10-27 06:07:52 # URL where to find the dashboard home page\n2013-10-27 06:07:52 dashboard_url = http://127.0.0.1/\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # URL where to submit the login form\n2013-10-27 06:07:52 login_url = http://127.0.0.1/auth/login/\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 [scenario]\n2013-10-27 06:07:52 # Directory containing image files\n2013-10-27 06:07:52 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # AMI image file name\n2013-10-27 06:07:52 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # ARI image file name\n2013-10-27 06:07:52 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # AKI image file name\n2013-10-27 06:07:52 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # ssh username for the image file\n2013-10-27 06:07:52 ssh_user = cirros\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 # specifies how many resources to request at once. Used for large operations\n2013-10-27 06:07:52 # testing.\"\n2013-10-27 06:07:52 large_ops_number = 0\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 [cli]\n2013-10-27 06:07:52 # Enable cli tests\n2013-10-27 06:07:52 enabled = True\n2013-10-27 06:07:52 # directory where python client binaries are located\n2013-10-27 06:07:52 cli_dir = /usr/local/bin\n2013-10-27 06:07:52 # Number of seconds to wait on a CLI timeout\n2013-10-27 06:07:52 timeout = 15\n2013-10-27 06:07:52 \n2013-10-27 06:07:52 [service_available]\n2013-10-27 06:07:52 # Whether or not cinder is expected to be available\n2013-10-27 06:07:52 cinder = True\nall develop-inst: /opt/stack/new/tempest\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpIbcuPl\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp7OWB6a\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpRhDFz8\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpjJWZYU\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_hosts_negative\ntags: worker-1\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_hosts_negative\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_hosts_negative.py\", line 23, in <module>\n    class HostsAdminNegativeTestJSON(base.BaseComputeAdminTest):\nAttributeError: \'module\' object has no attribute \'BaseComputeAdminTest\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2861 tests in 1147.644s\nFAILED (id=0, failures=2, skips=76)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-610872-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-610872.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-610872/41/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1764418249.5.1382596265373.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<130B1A70-2872-40C2-9BCB-F52E9DCD0D1C@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 10:49:24',-28800,'2014-01-21 18:49:24',NULL,'[openstack-dev] [Neutron][3rd Party Testing] Jenkins setup','For vmware minesweeper ,we filter tests following way:\n\n1. testr list-tests > alltests\n2. exclude-tests (file with test names we want to filter)\n3. alltests - excludetests = tests_to_be_run\n4. testr run ?load-list=tests_to_be_run\n\nhope that helps\n\n\nOn Jan 21, 2014, at 9:56 AM, Lucas Eznarriaga <lucas at midokura.com> wrote:\n\n> Hi, \n> \n> \n> For step 3/5, is the right procedure. Or is there a way to use a cmd to run all the tests and use a different mechanism to specify a filter for the tests to be run.\n> \n> \n> I don\'t know if Tempest allows you to filter for the tests to be run.\n> I\'m following these steps to configure Jenkins but I still have issues with the Post build actions task to run the commands to scp the test logs in a server to make them available and write its url into the gerrit plugin environment variable to be returned to OS/neutron review.\n> Any hint from someone who has this part already solved?\n> \n> Thanks,\n> Lucas\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=aFCd3VHHntevS%2F4zRg5X3Q67rMfoK4zaQbQ8vktBEac%3D%0A&m=Dd7OAFj8u6FeRIbifSygXPu1BSZlQaiwjO3mnAuaO68%3D%0A&s=ce622e15ad3098f3ba627963122be95f45f269f31550afaf34b176ac35e73870\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140121/17a1d608/attachment.html>\n\n','<CAGAc197_DparYcmubzf3-5Oe+JKvVWyo2gGKPnCjSZ7Q9YDWug@mail.gmail.com>',NULL),('<130dc5f1d1c041998788d6f0e0a3b289@DBXPR05MB0589.eurprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-04 14:53:06',0,'2014-11-04 14:53:06',NULL,'[openstack-dev] PCI/SR-IOV meet-up at the summit','Hi,\nWe thought it would be a good idea to have some chat regarding further SR-IOV enchantment that we want to achieve during Kilo.\nIf you are interested to discuss it, please join us Wednesday 5, at 13:15 at the developers lounge.\nThe list of topics raised till now can be found here:\nhttps://etherpad.openstack.org/p/kilo_sriov_pci_passthrough\n\nSee you there,\nIrena\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141104/f0ce50c6/attachment.html>\n\n',NULL,NULL),('<1310195395.1060327.1386062600244.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 10:23:20',3600,'2013-12-03 09:23:20',NULL,'[openstack-dev] [Neutron] L3 agent external networks','Hi,\n\nI was reviewing this patch (https://review.openstack.org/#/c/52884/) from Oleg and I thought that is a bit tricky to deploy an l3 agent with automation tools like Puppet since you have to specify the uuid of a network that doesn\'t already exist. It may be better to bind a l3 agent to an network by a CIDR instead of a uuid since when we deploy we know in advance which network address will be on which l3 agent.\n\nI wanted also remove the L3 agent limit regarding to the number of external networks, I submitted a patch as WIP (https://review.openstack.org/#/c/59359/) for that purpose and I wanted to have the community opinion about that :)\n\nPlease let me know what you think.\n\nBest regards,\n\nSylvain\n\n\n\n','<1284488649.1059398.1386062133391.JavaMail.root@enovance.com>',NULL),('<1310375496.13576156.1414002265356.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-22 14:24:25',-14400,'2014-10-22 18:24:25',NULL,'[openstack-dev] [Manila] command execution refactor plan','Hi,\n\nI have these concerns regarding command execution in Manila.\nI was to propose these to be discussed at the Design Summit.\nIt might be too late for that. Then we can discuss it here --\nor at the summit, just informally.\n\nThanks for Valeriy for his ideas about some of the topics below.  \n\nDriver ancestry\n---------------\n\nSee ExecuteMixin [1]:\n- method _try_execute is not used anywhere\n- method set_execute only used in __init__ and it could be inlined\n- __init__ just inlines ShareDriver.__init__ and sets up self._execute\n- ExecuteMixin itself is used only in conjunction with ShareDriver\n  (to derive specific driver classes from them)\n\n[1] http://git.openstack.org/cgit/openstack/manila/tree/manila/share/driver.py?id=f67311a#n49\n\nPlan: eliminate ExecuteMixin\n- Drop _try_execute. If it\'s needed in future, it can be resurrected as a\n  utility function (ie. toplevel function in utils.py).\n- Drop set_execute, instead set set self._execute directly.\n- ShareDriver.__init__ should take over execute management from ExecuteMixin, ie.\n  set self._execute from kwargs[\'execute\'] if available, else fall back to\n  utils.execute.\n- Drop the ExecuteMixin class.\n\nImpact: a driver class definition that currently takes this from:\n\n  SomeDriver(driver.ExecuteMixin, driver.ShareDriver)\n\nwill be identical to the\n\n  SomeDriver(driver.ShareDriver)\n\ndefinition after the change.\n\nSSH execution\n-------------\n\n## Signature\n\nTerminology:\n-  by \'executor\' we mean a function that\'s used for command execution\n   in some way (locally, remotely, etc.)\n-  the standard (or default, cf. previous section) executor is\n   utils.execute; we will refer to its signature [2] as the \'standard\n   executor signature\'\n-  \'standard signature executor\': an executor the signature of which is\n   the standard executor signature\n\n[2] in the sense of http://en.wikipedia.org/wiki/Type_signature\n\nThe demand for transparent remote execution naturally arises for\ndrivers which do command line basedd management of a resource or service\nthat can be available both locally and remotely.\n\nThat is, an instance of such a resource manager class ideally would get a\nstandard signature executor at initialization and it would perform executions\nvia this executor with no knowledge whether it acts locally or remotely.\nProviding the executor, appropriately set up for either local or remote execution,\nis up to the instantiator.\n\nHowever, currently local command execution is typically done by utils.execute\n(or a wrapper that changes some defaults), and remote execution is\ntypically done with processutils.ssh_execute (or some wrapper of it).\nAnd these two functions differ in signature, because ssh_execute takes\nalso an ssh connection object as parameter.\n\nThus such manager classes either resign of execution transparency and come in\nlocal and remote variants, or they implement some wrapper around\nprocessutils.ssh_execute that ensures standard executor signature.\n\nMy proposal is:\n- implement and standardize an ssh executor with standard signature\n- it would be built atop of processutils.ssh_execute\n- it would apply some basic strategy for managing the ssh connection\n  internally\n- let all drivers use this executor instead of direct processutils.ssh_execute\n  invocations (unless there is a manifest demand for custom management of\n  the ssh connection)\n\nHere is a prototype of that idea:\n\nhttps://review.openstack.org/gitweb?p=openstack/manila.git;a=blob;f=manila/share/drivers/ganesha/utils.py;h=463da36;hb=7443672#l70\n\nIt\'s a class that\'s instantiated with the same parameters as an ssh connection,\nand the corresponding ssh connection is created upon instantiation. Moreover,\nit\'s a callable class [3], with standard executor signature, whereby a call of an\ninstance of it performs remote execution using the ssh connection with which the\ninstance had been initialized.\n\n[3] ie. instances of it are callable, ie. the __call__ instance method is\ndefined, cf. https://docs.python.org/2/reference/datamodel.html#object.__call__\n\n## Escaping\n\nThe other major difference between local and remote (SSH based) execution that\nformer is argument array based, latter is command string based (which is passed\nto shell at the remote end). This is not a problem, as the argument array can\nbe transformed in a safe and faithful manner to a shell command string by shell\nescaping the arguments and then joining them with space. This algorithm is\nindeed obligatory to get at a correct result. So the standard ssh executor\nwill also include it properly. Therefore standardizing ssh execution will\nimprove safety by eliminating the need to do ad hoc conversions between argument\narrays and command strings.\n\n## run_as_root\n\nprocessutils.ssh_exec does not handle the run_as_root parameter. That\'s however\na low hanging fruit -- given its presence, just sudo(8) (or custom root wrapper)\nshould be prepended to the command string. (It is actually a realistic concern,\nas remote nodes might be set up to allow remote log in with unprivileged user\nand to curate administrative tasks via sudo.)\n\nshell vs run_as_root\n--------------------\n\nI found a bug in utils.execute, inherited from upstream (oslo.concurrency). See\nthe bug item for details:\n\nhttps://bugs.launchpad.net/oslo.concurrency/+bug/1382873\n\nalso my propsed fix (to be resubmitted for oslo.concurrency):\n\nhttps://review.openstack.org/129447\n\nCsaba\n\n\n','<713434344.11105707.1413728965386.JavaMail.zimbra@redhat.com>',NULL),('<1310466486.22196004.1391468524184.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-03 18:02:04',-18000,'2014-02-03 23:02:04',NULL,'[Openstack-docs] Proposal: CLI Reference manual','Trying to be creative here with another solution, but nothing is arriving. Do believe it\'s a good step to get rid of the EUG/AUG duplication, and you can\'t pick one over the other since the audience is so integral. \n\nAm really just kicking against the separate book for a reference list where, again, a listing by component is contained. Wouldn\'t it be nice to have one place where all component bits could be found.....OpenStack Component Reference? \n\n/me bowing to the many. \nSummer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: \"Diane Fleming\" <diane.fleming at rackspace.com>\n> Cc: \"Summer Long\" <slong at redhat.com>, \"Andreas Jaeger\" <aj at suse.com>,\n> openstack-docs at lists.openstack.org, \"Steve Gordon\" <sgordon at redhat.com>\n> Sent: Tuesday, February 4, 2014 12:14:02 AM\n> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n\n> On Mon, Feb 3, 2014 at 8:09 AM, Diane Fleming < diane.fleming at rackspace.com >\n> wrote:\n\n> > I don\'t think CLI reference should be part of config reference. Two\n> > different\n> > audiences and CLI commands are used by a broad audience who would probably\n> > never think to look in that book for CLI info (even if the title changes).\n> > My two cents!\n> \n\n> Agreed -- I think the keyword of that title is Configuration so people\n> wouldn\'t think to look there. Let\'s not expose our autodoc victory to our\n> readers by combining the two just because they\'re both automated. :)\n\n> Summer, I think the heart of your concern lies with the admin/end-user split?\n> Is there another way to address that?\n\n> Anne\n\n> > Sent from my iPhone\n> \n\n> > > On Feb 3, 2014, at 12:53 AM, \"Summer Long\" < slong at redhat.com > wrote:\n> \n> > >\n> \n> > >\n> \n> > >\n> \n> > > --\n> \n> > > Summer Long\n> \n> > > OpenStack Documentation Lead\n> \n> > > Engineering Content Services\n> \n> > >\n> \n> > > Red Hat Asia Pacific\n> \n> > > Brisbane, Austral ia\n> \n> > > slong at redhat.com | irc: slong\n> \n> > >\n> \n> > > ----- Original Message -----\n> \n> > >> From: \"Andreas Jaeger\" < aj at suse.com >\n> \n> > >> To: \"Summer Long\" < slong at redhat.com >\n> \n> > >> Cc: \"Diane Fleming\" < diane.fleming at RACKSPACE.COM >, \"Anne Gentle\" <\n> > >> anne at openstack.org >,\n> \n> > >> openstack-docs at lists.openstack.org , \"Steve Gordon\" < sgordon at redhat.com\n> > >> >\n> \n> > >> Sent: Monday, February 3, 2014 4:34:44 PM\n> \n> > >> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n> \n> > >>\n> \n> > >>> On 02/03/2014 03:59 AM, Summer Long wrote:\n> \n> > >>>\n> \n> > >>>\n> \n> > >>> ----- Original Message -----\n> \n> > >>>> From: \"Andreas Jaeger\" < aj at suse.com >\n> \n> > >>>> To: \"Diane Fleming\" < diane.fleming at RACKSPACE.COM >, \"Anne Gentle\"\n> \n> > >>>> < anne at openstack.org >\n> \n> > >>>> Cc: openstack-docs at lists.openstack.org\n> \n> > >>>> Sent: Friday, January 31, 2014 1:44:04 AM\n> \n> > >>>> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n> \n> > >>>>\n> \n> > >>>>> On 01/30/2014 04:26 PM, Diane Fleming wrote:\n> \n> > >>>>> Actually, I\'m fine either way ? keeping it as appendix or as separate\n> \n> > >>>>> book.\n> \n> > >>>>>\n> \n> > >>>>> But either way, I think we need to improve the formatting ? I\'ll open\n> > >>>>> a\n> \n> > >>>>> bug for that.\n> \n> > >>>\n> \n> > >>> And can the \'install the clients\' section be removed? Clients should\n> \n> > >>> already be installed via the Installation Guide?\n> \n> > >>\n> \n> > >> Clients will be installed on machines outside of the cloud as well, so I\n> \n> > >> think this really belongs to the CLI reference.\n> \n> > > Yep, ok, fair enough.\n> \n> > >>\n> \n> > >>>>\n> \n> > >>>> Yes, please do open a bug. I\'ll see what I can do to improve it.\n> \n> > >>>>\n> \n> > >>>>> What does everyone else think about keeping command ref as appendix,\n> > >>>>> or\n> \n> > >>>>> moving to separate book?\n> \n> > >>>>\n> \n> > >>>> I\'m fine either way. Having one more guide, will not really cost us\n> \n> > >>>> more work than having it in the appendices. And having a guide would\n> \n> > >>>> give us *one* location for the content instead of currently two guides\n> \n> > >>>> with both the same large appendix.\n> \n> > >>> Definitely vote for having it\n> \n> > >>>\n> \n> > >>>>\n> \n> > >>>> And I\'m even fine with removing the appendix and not having a book\n> > >>>> since\n> \n> > >>>> these are help texts users could get themselves on the command line...\n> \n> > >>>> Still, it\'s nice to have a common location to look it up and be aware\n> > >>>> of\n> \n> > >>>> these. And since there are no man pages for these, this it probably\n> > >>>> the\n> \n> > >>>> best way to have it,\n> \n> > >>>\n> \n> > >>> +1 on removing the CLI info from both EUG and AUG and providing links\n> \n> > >>> (really dislike bloat-by-duplication).\n> \n> > >>>\n> \n> > >>> But was there a reason for not just putting the CLI info into the\n> \n> > >>> Configuration Reference Guide?\n> \n> > >>> We\'re removing the HowTos from that guide, which means the whole thing\n> \n> > >>> really is a reference now?\n> \n> > >>\n> \n> > >> IMO they target different personas - the admin of the cloud for the\n> \n> > >> Configuration Reference only and the CLI reference both admin and users,\n> \n> > > But if you do this, you\'re creating an admin-and-users book. Why not just\n> > > make the Configuration Reference have that audience as well and keep all\n> > > the automatically generated reference lists in one book? \'Configuration\n> > > and CLI Reference\'\n> \n> > >\n> \n> > > cheers, Summer\n> \n> > >\n> \n> > >>\n> \n> > >> Andreas\n> \n> > >> --\n> \n> > >> Andreas Jaeger aj@{ suse.com , opensuse.org } Twitter/Identica:\n> > >> jaegerandi\n> \n> > >> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n> \n> > >> GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n> \n> > >> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126\n> \n> > >>\n> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140203/8ac678fb/attachment-0001.html>\n\n','<CAD0KtVGgB9Tm5svtTg6xBO6Fo5wbwfCVkouQZ8pgQbo25-MWcg@mail.gmail.com>',NULL),('<1310792454.18273793.1406309547455.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 13:32:27',-14400,'2014-07-25 17:32:27',NULL,'[openstack-dev] [QA] Proposed Changes to Tempest Core','+1\n\n\n----- Original Message -----\n> From: \"Matthew Treinish\" <mtreinish at kortar.org>\n> To: openstack-dev at lists.openstack.org\n> Sent: Tuesday, July 22, 2014 12:34:28 AM\n> Subject: [openstack-dev] [QA] Proposed Changes to Tempest Core\n> \n> \n> Hi Everyone,\n> \n> I would like to propose 2 changes to the Tempest core team:\n> \n> First, I\'d like to nominate Andrea Fritolli to the Tempest core team. Over\n> the\n> past cycle Andrea has been steadily become more actively engaged in the\n> Tempest\n> community. Besides his code contributions around refactoring Tempest\'s\n> authentication and credentials code, he has been providing reviews that have\n> been of consistently high quality that show insight into both the project\n> internals and it\'s future direction. In addition he has been active in the\n> qa-specs repo both providing reviews and spec proposals, which has been very\n> helpful as we\'ve been adjusting to using the new process. Keeping in mind\n> that\n> becoming a member of the core team is about earning the trust from the\n> members\n> of the current core team through communication and quality reviews, not\n> simply a\n> matter of review numbers, I feel that Andrea will make an excellent addition\n> to\n> the team.\n> \n> As per the usual, if the current Tempest core team members would please vote\n> +1\n> or -1(veto) to the nomination when you get a chance. We\'ll keep the polls\n> open\n> for 5 days or until everyone has voted.\n> \n> References:\n> \n> https://review.openstack.org/#/q/reviewer:%22Andrea+Frittoli+%22,n,z\n> \n> http://stackalytics.com/?user_id=andrea-frittoli&metric=marks&module=qa-group\n> \n> \n> The second change that I\'m proposing today is to remove Giulio Fidente from\n> the\n> core team. He asked to be removed from the core team a few weeks back because\n> he\n> is no longer able to dedicate the required time to Tempest reviews. So if\n> there\n> are no objections to this I will remove him from the core team in a few days.\n> Sorry to see you leave the team Giulio...\n> \n> \n> Thanks,\n> \n> Matt Treinish\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140721223428.GA9318@Sazabi.treinish>',NULL),('<1311070638.12541255.1343845130082.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-01 14:18:50',-14400,'2012-08-01 18:18:50',NULL,'[openstack-dev] [keystone] Accessing current Context from\n inside an	Identity driver ?','Can you provide a sense of the features you are looking to implement this way?\n\nThe Roles can always be requeried,  although I will admit that it is sub optimal.\n\nPersonally, I am not a fan of passing around the Context object the way that we do.  I would much prefer an inversion of control, where each component registers its dependencies, and the context plays the middleman in handing them out. \n\nhttp://wiki.python.org/moin/DependencyInjectionPattern\n\nThere are some thoughts on the link:\n\nhttp://code.activestate.com/recipes/413268/\n\n\nFor our purposes, we need to only concern ourselves with Request and GLobally scoped objects,  though there is always the possibility of a session sneaking in there in the future (perhaps for paging functionality in LDAP deployments)\n\n\n\n\n\n----- Original Message -----\nFrom: \"Stef Telford\" <stelford at internap.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, August 1, 2012 1:19:48 PM\nSubject: [openstack-dev] [keystone] Accessing current Context from inside an	Identity driver ?\n\n\nHey Everyone, \nRecently, I have been digging in and around keystone, and there is a need for the current context to be made available to the identity driver rather than merely the manager. This is mostly so the identity driver can have the current roles for authee/user. I noticed in keystone/common/manager.py (where it ties everything together) that there is a note which says; \n\n\n\ndef __getattr__(self, name): \n\"\"\"Forward calls to the underlying driver.\"\"\" \n# NOTE(termie): context is the first argument, we\'re going to strip \n# that for now, in the future we\'ll probably do some \n# logging and whatnot in this class \n\n\nMy question is, what\'s the \"approved\" solution to passing over the context ? I could always stuff the context into the **kw or append it to the args but, seems rather .. sub-optimal. Is there any design hints/tips ? I don\'t fancy maintaining a set of patches against the main branch jst for our codebase, and would rather do something to benefit everyone. I think this may come up again in the future ;) \n\n\nRegards \nS. \n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAGP-STPFyaSMq418G3BW1-i_QoX0rQJn1ACDVp1QOAnkVhKkvQ@mail.gmail.com>',NULL),('<131148736.79.1353110883660.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-17 00:08:03',0,'2012-11-17 00:08:03',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-cinder #40','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder/40/>\n\n------------------------------------------\n[...truncated 4825 lines...]\n++ line=\'signing_dir = /tmp/keystone-signing-nova\'\n++ echo /tmp/keystone-signing-nova\n+ [[ -z /tmp/keystone-signing-nova ]]\n+ sed -i -e \'/^\\[filter:authtoken\\]/,/^\\[.*\\]/ s|^\\(signing_dir[ \\t]*=[ \\t]*\\).*$|\\1/var/cache/nova|\' /etc/nova/api-paste.ini\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,n-cpu, ]]\n+ return 0\n+ sudo sysctl -w net.ipv4.ip_forward=1\nnet.ipv4.ip_forward = 1\n+ sudo modprobe nbd\n+ [[ kvm == \\k\\v\\m ]]\n+ sudo modprobe kvm\nFATAL: Module kvm not found.\n+ true\n+ \'[\' \'!\' -e /dev/kvm \']\'\n+ echo \'WARNING: Switching to QEMU\'\nWARNING: Switching to QEMU\n+ LIBVIRT_TYPE=qemu\n+ which selinuxenabled\n+ [[ qemu == \\l\\x\\c ]]\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 20223\n+ mkdir -p /opt/stack/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ bash\n+ sudo iptables -S -v\n+ awk \'{print \"sudo iptables\",$0}\'\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ grep nova\n+ sudo iptables -S -v -t nat\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ sudo iptables -S -v\n+ bash\n+ awk \'{print \"sudo iptables\",$0}\'\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ sudo iptables -S -v -t nat\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n++ grep instance-\n++ sudo virsh list --all\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ xargs sudo iscsiadm --mode node --logout\n+ cut -d \' \' -f2\n+ grep volume-\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ cut -d \' \' -f2\n+ grep volume-\n+ sudo iscsiadm --mode node --op delete\niscsiadm: no records found!\niscsiadm: no records found!\n+ true\n+ sudo rm -rf \'/opt/stack/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ xargs\n++ echo\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ [[ \'\' != \\F\\a\\l\\s\\e ]]\n+ PIP_MIRROR_OPT=--use-mirrors\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.2.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_compressor%2Fdjango_compressor-1.2.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \nDownloading/unpacking django-openstack-auth>=1.0.3 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.4.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.4.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nDownloading/unpacking pytz (from -r horizon.egg-info/requires.txt (line 10))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpytz%2Fpytz-2012h.tar.bz2\n  Running setup.py egg_info for package pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.5.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango-appconf%2Fdjango-appconf-0.5.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): prettytable in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-novaclient->-r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.2.1 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema==0.2 in /usr/local/lib/python2.7/dist-packages (from warlock<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2 in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, pytz, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth pytz django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2013.1 to easy-install.pth file\n\nInstalled /opt/stack/horizon\nProcessing dependencies for horizon==2013.1\nerror: Installed distribution python-keystoneclient 0.2.0 conflicts with requirement python-keystoneclient>=0.1.2,<0.2\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/devstacklog.txt.2012-11-17-000452\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/40/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1312247069.1387232.1414584853064.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-10-29 08:14:13',-14400,'2014-10-29 12:14:13',NULL,'[Openstack-stable-maint] Neutron backports for security group\n performance','+1, With cured I mean sitting on master to make sure they don\'t introduce any new issue.\nI like Claudiu\'s definition of the problem, it\'s actually very descriptive.\n\nClaudiu, I believe all plugins gerrit/CI on stable/juno may be enough to validate the backports,\nam I right?. Otherwise the process could go too complicated (manual backport D/S for every CI, and\nspecific testing... that actually may happen before the next D/S release based on juno).\n\n----- Original Message -----\n> Hello,\n> \n> The security groups really needs a performance boost, since it becomes\n> troublesome in large deployments.\n> \n> Let\'s say we have an OpenStack deployment of 10,000 vms. Each time we modify\n> a security group rule, the L2 agents will be notified that the security\n> group has changed. Some of them (I don\'t know if all of them) will do a full\n> refresh. This would mean 10,000 refreshes each time a security group\n> changes.\n> \n> Now, the question is, how often will the security groups change? Well, as far\n> as I know, a security group rule is created whenever a new port is created\n> and is bound to a network (for example., nova boot --nic net-id=...). Also,\n> when a vm is deleted, the security group rule will be removed as well. I\n> also assume that the L2 agent will refresh the security group rules in case\n> of migration and resize.\n> \n> Also, there are some agents (Hyper-V L2 agent) that will refresh all the\n> ports it manages when they start.\n> Also, a vm can have multiple security groups, so when an agent will do a\n> refresh, it will refresh for each security group.\n> Also, a vm can have multiple nics, which can mean more ports and more rules.\n> \n> There might be other common scenarios I didn\'t mention, but my point is that\n> any performance boost, even a small one, for security groups will have a big\n> impact.\n> \n> I am in favor of this, but still, I think we will have to make sure it\n> introduce new issues for some L2 agents, since they are the main consumers\n> of the security groups. The commits will have to be validated by all the\n> CIs.\n> \n> Best regards,\n> Claudiu Belu\n> ________________________________________\n> From: Ihar Hrachyshka [ihrachys at redhat.com]\n> Sent: Wednesday, October 29, 2014 12:59 PM\n> To: Miguel Angel Ajo Pelayo\n> Cc: openstack-stable-maint\n> Subject: Re: [Openstack-stable-maint] Neutron backports for security group\n> performance\n> \n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> On 29/10/14 11:39, Miguel Angel Ajo Pelayo wrote:\n> > In the case of backporting, I\'d, at least, let some time to get\n> > those changes cured, and make sure they are not introducing any new\n> > failure mode.\n> \n> Cured? What do you mean? Giving them some time to sit in master before\n> proceeding with backports?\n> \n> /Ihar\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> \n> iQEcBAEBCgAGBQJUUMiBAAoJEC5aWaUY1u57FVQH+QH8gSgkvr1r8Tj9+EBONf+O\n> n5ht7BIkd0P4bMLTWEZ/s3CX8z5EqhuBr6DcOyhQEq+Sf+AOQgkcy360DSPlRyGu\n> FzwHt3v2DARCC6sZ6xSryZiyZcrYjucUP70ZOSSLhDR25wdKsNF/RTWBanryFLQD\n> X7rABJdgSQN2e0uF7gshApMwzzC6ypRt6TimXHO1CBiK+MvUfEJN2NuS8TGx4+F3\n> 8O+W7cwdn9RxNoqMP30qZGcUzfJTqnRse05JSmj9xgWOI1QUVA3Ql3LXfh+SDBe1\n> NyxKGk1DmvoWNhVw6F8T1gfghXt/yg5xCbbqCindZawwcFNjgxniFQDpVe8OOoM=\n> =QwWs\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> \n\n\n','<FBEE3301F14DA946B921457EF854C37702ECC5B0@CBSEX1.cloudbase.local>',NULL),('<1312880988.29966609.1376359891225.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-12 19:11:31',-25200,'2013-08-13 02:11:31',NULL,'[openstack-dev] [vmware] VMwareAPI sub-team status update 2013-08-12','\nGreetings stackers!\n\nHere\'s the Monday report for the VMware API subteam! We\'ve got 4 ready for a core-reviewer to take a look at! Meanwhile, there\'s a healthy pile of patches (8 in all) that need rework. I\'ve got 5 patches that need reviews done by someone who knows VMware API\'s and 3 that are in need of some work. The August 22nd deadline is coming up, if you have a Havana feature to post and propose we need to get it up here. If you\'ve got something that needs a VMware person\'s attention, make sure to add me so I can track it or pass it on to the right people.  (For example: Thanks to Dan Smith for letting me grab this patch: https://review.openstack.org/#/c/40682/ and have our CI team look at it.)\n\nOn that note: \n \nMerged: 2, Ready for core: 4\n \n\nNeeds one more core review/approval:\n* NEW, https://review.openstack.org/#/c/37389/ ,\'VMware: Ensure Neutron networking works with VMware drivers\'\n    https://bugs.launchpad.net/nova/+bug/1202042\n    core votes,1, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/40105/ ,\'VMware: use VM uuid for volume attach and detach\'\n    https://bugs.launchpad.net/nova/+bug/1208173\n    core votes,1, non-core votes,2, down votes, 0\n\nReady for core reviewer:\n* NEW, https://review.openstack.org/#/c/33100/ ,\'Fixes host stats for VMWareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1190515\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/40298/ ,\'Fix snapshot in VMWwareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1184807\n    core votes,0, non-core votes,4, down votes, 0\n\nNeeds VMware API expert review:\n* NEW, https://review.openstack.org/#/c/37659/ ,\'Enhance VMware Hyper instance disk usage\'\n    https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage\n    core votes,0, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/40245/ ,\'Nova support for vmware cinder driver\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,1, down votes, 0\n* NEW, https://review.openstack.org/#/c/30282/ ,\'Multiple Clusters using single compute service\'\n    https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service\n    core votes,0, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/40029/ ,\'VMware: Config Drive Support\'\n    https://bugs.launchpad.net/nova/+bug/1206584\n    core votes,0, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/37819/ ,\'VMware image clone strategy settings and overrides\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy\n    core votes,0, non-core votes,0, down votes, 0\n\nNeeds discussion/work (has -1):\n* NEW, https://review.openstack.org/#/c/34903/ ,\'Deploy vCenter templates\'\n    https://blueprints.launchpad.net/nova/+spec/deploy-vcenter-templates-from-vmware-nova-driver\n    core votes,0, non-core votes,2, down votes, -1\n* NEW, https://review.openstack.org/#/c/30628/ ,\'Fix VCDriver to pick the datastore that has capacity\'\n    https://bugs.launchpad.net/nova/+bug/1171930\n    core votes,0, non-core votes,6, down votes, -1\n* NEW, https://review.openstack.org/#/c/33504/ ,\'VMware: nova-compute crashes if VC not available\'\n    https://bugs.launchpad.net/nova/+bug/1192016\n    core votes,0, non-core votes,1, down votes, -1\n\nKeep reviewing and keep up the good work.\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n\n# Shawn Hartsock\n\n\n','<1479992332.29954349.1376357568481.JavaMail.root@vmware.com>',NULL),('<1312995300.60.1374904903740.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-27 06:01:43',0,'2013-07-27 06:01:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #299','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/299/>\n\n------------------------------------------\n[...truncated 23 lines...]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/299/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-299\', \'SSH_CLIENT\': \'198.101.231.203 54431 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374861645.915036-183846463\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise2\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-27_06-00-26\', \'BUILD_NUMBER\': \'299\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'dd2d0100-01d8-437d-aa8a-f72470a6ae99\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise2\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#299\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 54431 64.49.246.124 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-G6T1gl/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-G6T1gl/d2to1-0.2.10/egg-dist-tmp-FjgV2O\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-Vx_aiD/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Vx_aiD/setuptools-git-1.0/egg-dist-tmp-D6IU5k\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-JuXTAu/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-JuXTAu/d2to1-0.2.10/egg-dist-tmp-4mnqZL\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-c8zRMI/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-c8zRMI/setuptools-git-1.0/egg-dist-tmp-_7CxMn\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-TWsqG3/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-TWsqG3/d2to1-0.2.10/egg-dist-tmp-vZ0Yni\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-hAw7HV/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-hAw7HV/setuptools-git-1.0/egg-dist-tmp-LaOlJ7\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/299\n[SCP] Copying console log.\n\n\n','<274266369.52.1374818545238.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1313356598.35829954.1386922170924.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-13 03:09:30',-18000,'2013-12-13 08:09:30',NULL,'[Openstack] [Ceilometer] VM instance CPU/disk/network\n utilization data','\nHi Mark,\n\nA common issue is a mismatch between the hostname used by nova\nto associate instances with hosts, and the hostname used by the\nceilometer compute agent to constrain the query it uses to discover\nthe instances running on the local host.\n\nTypically a mismatch might result from the hostname defaulting to\na FQDN in the nova case, and perhaps explicitly configured as an\nplain hostname in the ceilometer case.\n\nIn fact the default hostname used by *both* service is by design\nthe same, socket.gethostname(), so if it\'s not explicitly configured\nfor both services, it will naturally match.\n\nSo check your /etc/ceilometer/ceilometer.conf for an explicit setting\nof the host option in the [DEFAULT] section. You can just comment\nthat out to fall back onto the default value for the variable\n\nCheers,\nEoghan\n\n----- Original Message -----\n> I see the nova-compute service enabled and running in the Horizon\n> dashboard and I followed the instructions here\n> (http://docs.openstack.org/havana/install-guide/install/yum/content/ceilome\n> ter-install-nova.html) to install the Telemetry/Ceilometer compute agent\n> on the same node but I still don\'t see any of the CPU/disk/network\n> utilization data in the  meter or resource lists (retrieved using CLI and\n> API queries -\n> http://docs.openstack.org/developer/ceilometer/webapi/v2.html#api-and-cli-q\n> uery-examples).\n> \n> Any ideas? Keep in mind, I am new to this and still trying to understand\n> how everything works together so please let me know if I\'m looking in the\n> wrong places or not setting this up correctly.\n> \n> Thanks,\n> Mark\n> \n> \n> On 12/11/13 12:50 AM, \"Julien Danjou\" <julien at danjou.info> wrote:\n> \n> >On Wed, Dec 11 2013, Mark Vlcek (mavlcek) wrote:\n> >\n> >> How do I get CPU/disk/network utilization data? Do I need to update my\n> >> ceilometer.conf file or is something else not setup/running correctly?\n> >\n> >You need to run the ceilometer compute agent on each of your compute\n> >node.\n> >\n> >--\n> >Julien Danjou\n> >/* Free Software hacker * independent consultant\n> >   http://julien.danjou.info */\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CECF374F.96F2%mavlcek@cisco.com>',NULL),('<1314134336.22917488.1402303445428.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 04:44:05',-14400,'2014-06-09 08:44:05',NULL,'[openstack-dev] [openstack-tc]  use of the word certified','\n\n----- Original Message -----\n> \n> \n> \n> On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin < markmc at redhat.com > wrote:\n> \n> \n> \n> On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n> > The issue I have with the word certify is that it requires someone or a\n> > group of someones to attest to something. The thing attested to is only\n> > as credible as the someone or the group of someones doing the attesting.\n> > We have no process, nor do I feel we want to have a process for\n> > evaluating the reliability of the somones or groups of someones doing\n> > the attesting.\n> > \n> > I think that having testing in place in line with other programs testing\n> > of patches (third party ci) in cinder should be sufficient to address\n> > the underlying concern, namely reliability of opensource hooks to\n> > proprietary code and/or hardware. I would like the use of the word\n> > \"certificate\" and all its roots to no longer be used in OpenStack\n> > programs with regard to testing. This won\'t happen until we get some\n> > discussion and agreement on this, which I would like to have.\n> \n> Thanks for bringing this up Anita. I agree that \"certified driver\" or\n> similar would suggest something other than I think we mean.\n> ?Can you expand on the above comment? In other words a bit more about what\n> \"you\" mean. I think from the perspective of a number of people that\n> participate in Cinder the intent is in fact to say. Maybe it would help\n> clear some things up for folks that don\'t see why this has become a\n> debatable issue.\n> \n> By running CI tests successfully that it is in fact a ?way of certifying that\n> our device and driver is in fact \'certified\' to function appropriately and\n> provide the same level of API and behavioral compatability as the default\n> components as demonstrated by running CI tests on each submitted patch.\n> \n> Personally I believe part of the contesting of the phrases and terms is\n> partly due to the fact that a number of organizations have their own\n> \"certification\" programs and tests. I think that\'s great, and they in fact\n> provide some form of \"certification\" that a device works in their\n> environment and to their expectations.\n> \n> Doing this from a general OpenStack integration perspective doesn\'t seem all\n> that different to me. For the record, my initial response to this was that I\n> didn\'t have too much preference on what it was called (verification,\n> certification etc etc), however there seems to be a large number of people\n> (not product vendors for what it\'s worth) that feel differently.\n\nSince \"certification\" seems to be quite an overloaded term\nalready, I wonder would a more back-to-basics phrase such as\n\"quality assured\" better capture the Cinder project\'s use of\nthe word?\n\nIt does exactly what it says on the tin ... i.e. captures the\nfact that a vendor has run an agreed battery of tests against\ntheir driver and the harness has reported green-ness with a\nmeaning that is well understood upstream (as the Tempest test\ncases are in the public domain). \n\nCheers,\nEoghan\n\n\n','<CA+qL3LVJPubcDt=AyBPQPc3kV5OYdDdx=-QrO63to0VW2ALprA@mail.gmail.com>',NULL),('<1314134336.22917488.1402303445428.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-09 04:44:05',-14400,'2014-06-09 08:44:05',NULL,'[openstack-tc] [openstack-dev]   use of the word certified','\n\n----- Original Message -----\n> \n> \n> \n> On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin < markmc at redhat.com > wrote:\n> \n> \n> \n> On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n> > The issue I have with the word certify is that it requires someone or a\n> > group of someones to attest to something. The thing attested to is only\n> > as credible as the someone or the group of someones doing the attesting.\n> > We have no process, nor do I feel we want to have a process for\n> > evaluating the reliability of the somones or groups of someones doing\n> > the attesting.\n> > \n> > I think that having testing in place in line with other programs testing\n> > of patches (third party ci) in cinder should be sufficient to address\n> > the underlying concern, namely reliability of opensource hooks to\n> > proprietary code and/or hardware. I would like the use of the word\n> > \"certificate\" and all its roots to no longer be used in OpenStack\n> > programs with regard to testing. This won\'t happen until we get some\n> > discussion and agreement on this, which I would like to have.\n> \n> Thanks for bringing this up Anita. I agree that \"certified driver\" or\n> similar would suggest something other than I think we mean.\n> ?Can you expand on the above comment? In other words a bit more about what\n> \"you\" mean. I think from the perspective of a number of people that\n> participate in Cinder the intent is in fact to say. Maybe it would help\n> clear some things up for folks that don\'t see why this has become a\n> debatable issue.\n> \n> By running CI tests successfully that it is in fact a ?way of certifying that\n> our device and driver is in fact \'certified\' to function appropriately and\n> provide the same level of API and behavioral compatability as the default\n> components as demonstrated by running CI tests on each submitted patch.\n> \n> Personally I believe part of the contesting of the phrases and terms is\n> partly due to the fact that a number of organizations have their own\n> \"certification\" programs and tests. I think that\'s great, and they in fact\n> provide some form of \"certification\" that a device works in their\n> environment and to their expectations.\n> \n> Doing this from a general OpenStack integration perspective doesn\'t seem all\n> that different to me. For the record, my initial response to this was that I\n> didn\'t have too much preference on what it was called (verification,\n> certification etc etc), however there seems to be a large number of people\n> (not product vendors for what it\'s worth) that feel differently.\n\nSince \"certification\" seems to be quite an overloaded term\nalready, I wonder would a more back-to-basics phrase such as\n\"quality assured\" better capture the Cinder project\'s use of\nthe word?\n\nIt does exactly what it says on the tin ... i.e. captures the\nfact that a vendor has run an agreed battery of tests against\ntheir driver and the harness has reported green-ness with a\nmeaning that is well understood upstream (as the Tempest test\ncases are in the public domain). \n\nCheers,\nEoghan\n\n\n','<CA+qL3LVJPubcDt=AyBPQPc3kV5OYdDdx=-QrO63to0VW2ALprA@mail.gmail.com>',NULL),('<1314505490.51.1387607814696.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-21 06:36:54',0,'2013-12-21 06:36:54',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-dsvm-neutron-pg-havana #10','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-pg-havana/10/>\n\n------------------------------------------\n[...truncated 21466 lines...]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... FAIL\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\n\nprocess-returncode\nprocess-returncode ... FAIL\n\n======================================================================\nFAIL: tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-12-21 06:23:04,210 Starting new HTTP connection (1): 127.0.0.1\n2013-12-21 06:23:04,320 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_basic_ops.py\", line 107, in test_server_basicops\n    self.boot_instance()\n  File \"tempest/scenario/test_server_basic_ops.py\", line 59, in boot_instance\n    instance = self.create_server(create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 352, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing ec100a9b-0a69-4b49-89b5-8321388084ba                       to become ACTIVE\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 248 tests in 1540.095s\n\nFAILED (failures=2, skipped=9)\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                         402.592\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  171.025\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          126.045\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  82.118\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]           35.909\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]                           24.316\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]             20.336\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]                      15.082\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]               13.984\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]     10.761\nERROR: InvocationError: \'/bin/sh tools/pretty_tox_serial.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])((smoke)|(^tempest\\\\.scenario)) \'\n___________________________________ summary ____________________________________\nERROR:   smoke-serial: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/localrc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-909892-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-909892.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-lbaas.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-q-vpn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/neutron-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-909892/10/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<131453602.5.1376979305490.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-20 06:15:05',0,'2013-08-20 06:15:05',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #7','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/7/>\n\n\n\n','<1956606828.2.1376720051896.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1314737979.126.1384754516721.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-18 06:01:56',0,'2013-11-18 06:01:56',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #65','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/65/>\n\n\n\n','<1974101057.123.1384668191258.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1315329719.38456748.1377114225557.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-21 12:43:45',-25200,'2013-08-21 19:43:45',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update\n 2013-08-21','\nNeed something to review? (It\'s all the rage. All the cool kids are doing it!)\n\nHere\'s a mid-week break down of what\'s fit for review from the VMwareAPI subteam! See something you like? Let us know. See something you don\'t? Tell us (how else will we learn?)\n\n\nNeeds one more core review/approval:\n* NEW, https://review.openstack.org/#/c/39046/ ,\'VMware: fix rescue/unrescue instance\'\n    https://bugs.launchpad.net/nova/+bug/1199955\n    core votes,1, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/33504/ ,\'VMware: nova-compute crashes if VC not available\'\n    https://bugs.launchpad.net/nova/+bug/1192016\n    core votes,1, non-core votes,6, down votes, 0\n\nReady for core reviewer:\n* NEW, https://review.openstack.org/#/c/39720/ ,\'VMware: Added check for datastore state before selection\'\n    https://bugs.launchpad.net/nova/+bug/1194078\n    core votes,0, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/37819/ ,\'VMware image clone strategy settings and overrides\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/33100/ ,\'Fixes host stats for VMWareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1190515\n    core votes,0, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/30628/ ,\'Fix VCDriver to pick the datastore that has capacity\'\n    https://bugs.launchpad.net/nova/+bug/1171930\n    core votes,0, non-core votes,7, down votes, 0\n* NEW, https://review.openstack.org/#/c/40029/ ,\'VMware: Config Drive Support\'\n    https://bugs.launchpad.net/nova/+bug/1206584\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/40298/ ,\'Fix snapshot in VMWwareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1184807\n    core votes,0, non-core votes,6, down votes, 0\n\nJust needs reviews:\n* NEW, https://review.openstack.org/#/c/40105/ ,\'VMware: use VM uuid for volume attach and detach\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/41387/ ,\'VMware: Nova boot from cinder volume\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,2, down votes, 0\n* NEW, https://review.openstack.org/#/c/40245/ ,\'Nova support for vmware cinder driver\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,1, down votes, 0\n\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n* If anything is missing, add \'hartsocks\' as a reviewer to the patch so I can examine it.\n* We hang out in #openstack-vmware if you need to chat.\n\nHappy stacking!\n\n# Shawn Hartsock\n\n\n','<1156464773.38451255.1377113888249.JavaMail.root@vmware.com>',NULL),('<1316213089.67166.YahooMailNeo@web161708.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-09-16 15:44:49',-25200,'2011-09-16 22:44:49',NULL,'[Openstack-operators] Swift v1.4.3 Multiple Server Installation on\n	EC2 - Help','\n\nI am following the steps in?http://swift.openstack.org/howto_installmultinode.html?to try out Swift on 6 EC2 nodes (1 proxy, 5 storage). I\'m using EC2 since I don\'t have 6 physical servers to spare.\n\nIn the \"General OS configuration and partitioning for each node\" section:?Step 6 is not clear\n\n\nStep 6 says:\n\n===\nPublish the local network IP address for use by scripts found later in this documentation:\nexport STORAGE_LOCAL_NET_IP=10.1.2.3\nexport PROXY_LOCAL_NET_IP=10.1.2.4\n===\n\nI assume I should be substituting the IP addresses with my IP addresses??\n\nThe PROXY_LOCAL_NET_IP I am guessing should be the local IP address of my Proxy server.\n\nHow about STORAGE_LOCAL_NET_IP? Is that the IP address of the first Storage server out of the 5 that I set up or any Storage server picked at random?\n\nThanks in advance.\n\nAmar\n--\nAmar Kapadia\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110916/29442844/attachment.html>\n\n',NULL,NULL),('<1316369347.2725467.1390726696554.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-26 08:58:16',0,'2014-01-26 08:58:16',NULL,'[openstack-dev] [nova] hugepage support','I have started an implementation in review: https://review.openstack.org/#/c/69148/ \n\n----- Original Message -----\n\nFrom: \"sahid\" <sahid.ferdjaoui at cloudwatt.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Saturday, January 25, 2014 5:56:10 PM \nSubject: Re: [openstack-dev] [nova] hugepage support \n\n\n\nHi Anil, \n\nI have checked on the code and it looks it is not possible to enable this feature for the guest. We are running kvm through libvirt and it support this option: http://libvirt.org/formatdomain.html \n\nIt could be an interesting feature. may be by an option readed from the image properties. There is something similar here: https://review.openstack.org/#/c/65028/ . \n\nWhat do you think? \n\ns. \n\n\n----- Original Message -----\n\nFrom: \"Anil Gunturu\" <anil.gunturu at riftio.com> \nTo: openstack-dev at lists.openstack.org \nSent: Saturday, January 25, 2014 4:31:51 PM \nSubject: [openstack-dev] [nova] hugepage support \n\n\n\nReposting with correct category in the subject. \n\n\n\n\nFrom: Anil Gunturu [mailto:anil.gunturu at riftio.com] \nSent: Thursday, January 23, 2014 12:18 AM \nTo: openstack-dev at lists.openstack.org \nSubject: [openstack-dev] hugepage support \n\n\n\n\nHi, \n\nIs it possible to enable the hugepages in the guest OS for the VMs launched in OpenStack (with KVM hypervisor)? Specifically is it possible to pass the ?-mem-path? option when invoking QEMU? \n\nThanks, \n\nAnil \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140126/d98c1e58/attachment.html>\n\n','<611764189.2091123.1390668970555.JavaMail.root@cloudwatt.com>',NULL),('<1316694860.4382865.1386628705810.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 17:38:25',-18000,'2013-12-09 22:38:25',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','Thanks for the explanation!\n\nI\'m going to claim that the thread revolves around two main areas of disagreement.  Then I\'m going\nto propose a way through:\n\na) Manual Node Assignment\n\nI think that everyone is agreed that automated node assignment through nova-scheduler is by\nfar the most ideal case; there\'s no disagreement there.\n\nThe disagreement comes from whether we need manual node assignment or not.  I would argue that we\nneed to step back and take a look at the real use case: heterogeneous nodes.  If there are literally\nno characteristics that differentiate nodes A and B, then why do we care which gets used for what?  Why\ndo we need to manually assign one?\n\nIf we can agree on that, then I think it would be sufficient to say that we want a mechanism to allow\nUI users to deal with heterogeneous nodes, and that mechanism must use nova-scheduler.  In my mind,\nthat\'s what resource classes and node profiles are intended for.\n\nOne possible objection might be: nova scheduler doesn\'t have the appropriate filter that we need to\nseparate out two nodes.  In that case, I would say that needs to be taken up with nova developers.\n\n\nb) Terminology\n\nIt feels a bit like some of the disagreement come from people using different words for the same thing.\nFor example, the wireframes already details a UI where Robert\'s roles come first, but I think that message\nwas confused because I mentioned \"node types\" in the requirements.\n\nSo could we come to some agreement on what the most exact terminology would be?  I\'ve listed some examples below,\nbut I\'m sure there are more.\n\nnode type | role\nmanagement node | ?\nresource node | ?\nunallocated | available | undeployed\ncreate a node distribution | size the deployment\nresource classes | ?\nnode profiles | ?\n\nMainn\n\n----- Original Message -----\n> On 10 December 2013 09:55, Tzu-Mainn Chen <tzumainn at redhat.com> wrote:\n> >> >        * created as part of undercloud install process\n> \n> >> By that note I meant, that Nodes are not resources, Resource instances\n> >> run on Nodes. Nodes are the generic pool of hardware we can deploy\n> >> things onto.\n> >\n> > I don\'t think \"resource nodes\" is intended to imply that nodes are\n> > resources; rather, it\'s supposed to\n> > indicate that it\'s a node where a resource instance runs.  It\'s supposed to\n> > separate it from \"management node\"\n> > and \"unallocated node\".\n> \n> So the question is are we looking at /nodes/ that have a /current\n> role/, or are we looking at /roles/ that have some /current nodes/.\n> \n> My contention is that the role is the interesting thing, and the nodes\n> is the incidental thing. That is, as a sysadmin, my hierarchy of\n> concerns is something like:\n>  A: are all services running\n>  B: are any of them in a degraded state where I need to take prompt\n> action to prevent a service outage [might mean many things: - software\n> update/disk space criticals/a machine failed and we need to scale the\n> cluster back up/too much load]\n>  C: are there any planned changes I need to make [new software deploy,\n> feature request from user, replacing a faulty machine]\n>  D: are there long term issues sneaking up on me [capacity planning,\n> machine obsolescence]\n> \n> If we take /nodes/ as the interesting thing, and what they are doing\n> right now as the incidental thing, it\'s much harder to map that onto\n> the sysadmin concerns. If we start with /roles/ then can answer:\n>  A: by showing the list of roles and the summary stats (how many\n> machines, service status aggregate), role level alerts (e.g. nova-api\n> is not responding)\n>  B: by showing the list of roles and more detailed stats (overall\n> load, response times of services, tickets against services\n>      and a list of in trouble instances in each role - instances with\n> alerts against them - low disk, overload, failed service,\n> early-detection alerts from hardware\n>  C: probably out of our remit for now in the general case, but we need\n> to enable some things here like replacing faulty machines\n>  D: by looking at trend graphs for roles (not machines), but also by\n> looking at the hardware in aggregate - breakdown by age of machines,\n> summary data for tickets filed against instances that were deployed to\n> a particular machine\n> \n> C: and D: are (F) category work, but for all but the very last thing,\n> it seems clear how to approach this from a roles perspective.\n> \n> I\'ve tried to approach this using /nodes/ as the starting point, and\n> after two terrible drafts I\'ve deleted the section. I\'d love it if\n> someone could show me how it would work:)\n> \n> >> >     * Unallocated nodes\n> >> >\n> >> > This implies an \'allocation\' step, that we don\'t have - how about\n> >> > \'Idle nodes\' or something.\n> >> >\n> >> > It can be auto-allocation. I don\'t see problem with \'unallocated\' term.\n> >>\n> >> Ok, it\'s not a biggy. I do think it will frame things poorly and lead\n> >> to an expectation about how TripleO works that doesn\'t match how it\n> >> does, but we can change it later if I\'m right, and if I\'m wrong, well\n> >> it won\'t be the first time :).\n> >>\n> >\n> > I\'m interested in what the distinction you\'re making here is.  I\'d rather\n> > get things\n> > defined correctly the first time, and it\'s very possible that I\'m missing a\n> > fundamental\n> > definition here.\n> \n> So we have:\n>  - node - a physical general purpose machine capable of running in\n> many roles. Some nodes may have hardware layout that is particularly\n> useful for a given role.\n>  - role - a specific workload we want to map onto one or more nodes.\n> Examples include \'undercloud control plane\', \'overcloud control\n> plane\', \'overcloud storage\', \'overcloud compute\' etc.\n>  - instance - A role deployed on a node - this is where work actually\n>  happens.\n>  - scheduling - the process of deciding which role is deployed on which node.\n> \n> The way TripleO works is that we defined a Heat template that lays out\n> policy: 5 instances of \'overcloud control plane please\', \'20\n> hypervisors\' etc. Heat passes that to Nova, which pulls the image for\n> the role out of Glance, picks a node, and deploys the image to the\n> node.\n> \n> Note in particular the order: Heat -> Nova -> Scheduler -> Node chosen.\n> \n> The user action is not \'allocate a Node to \'overcloud control plane\',\n> it is \'size the control plane through heat\'.\n> \n> So when we talk about \'unallocated Nodes\', the implication is that\n> users \'allocate Nodes\', but they don\'t: they size roles, and after\n> doing all that there may be some Nodes that are - yes - unallocated,\n> or have nothing scheduled to them. So... I\'m not debating that we\n> should have a list of free hardware - we totally should - I\'m debating\n> how we frame it. \'Available Nodes\' or \'Undeployed machines\' or\n> whatever. I just want to get away from talking about something\n> ([manual] allocation) that we don\'t offer.\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ1VV9YPnG+=n9E7UGb5WgGXEWWSUM5HP3xuTADkBqszaw@mail.gmail.com>',NULL),('<1317678295.35506.YahooMailNeo@web161717.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-03 14:44:55',-25200,'2011-10-03 21:44:55',NULL,'[Openstack-operators] Swift Install \"Check that you can HEAD the\n	account\" step fails','Hi,\n\nI am using the instructions on this page:?http://swift.openstack.org/howto_installmultinode.html. I assume this works for Diablo release of Swift as well.\n\nI am on STEP 2 \"Check that you can HEAD the account\" of the \"Create Swift admin account and test\" step i.e.:?\n\ncurl-k -v -H \'X-Auth-Token: <token-from-x-auth-token-above>\' <url-from-x-storage-url-above>\n\nI did this and replaced the token & URL as per below. However the command failed.?\n\n\nAny ideas how I can fix this?\n\nThanks, in advance.\n\nRegards,\n\nAmar\n===\n\ncurl -k -v -H \'X-Auth-Token: AUTH_tk9dac19fd2c87484bb7c9e779b0478968\'?https://$PROXY_LOCAL_NET_IP:8080/v1/AUTH_system/\n\n\n* About to connect() to 10.10.10.61 port 8080 (#0)\n*? Trying 10.10.10.61... connected\n* Connected to 10.10.10.61 (10.10.10.61) port 8080 (#0)\n* successfully set certificate verify locations:\n*? CAfile: none\n? CApath: /etc/ssl/certs\n* SSLv3, TLS handshake, Client hello (1):\n* SSLv3, TLS handshake, Server hello (2):\n* SSLv3, TLS handshake, CERT (11):\n* SSLv3, TLS handshake, Server finished (14):\n* SSLv3, TLS handshake, Client key exchange (16):\n* SSLv3, TLS change cipher, Client hello (1):\n* SSLv3, TLS handshake, Finished (20):\n* SSLv3, TLS change cipher, Client hello (1):\n* SSLv3, TLS handshake, Finished (20):\n* SSL connection using AES256-SHA\n* Server certificate:\n*? ? ? subject: C=US; ST=CA; L=San Francisco; O=UL; emailAddress=xxx at yyy.com\n*? ? ? start date:?2011-10-02 09:03:42 GMT\n*? ? ? expire date:?2011-11-01 09:03:42 GMT\n* SSL: unable to obtain common name from peer certificate\n> GET /v1/AUTH_system/ HTTP/1.1\n> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n> Host: 10.10.10.61:8080\n> Accept: */*\n> X-Auth-Token: AUTH_tk9dac19fd2c87484bb7c9e779b0478968\n>\n< HTTP/1.1 401 Unauthorized\n< Content-Length: 358\n< Content-Type: text/html; charset=UTF-8\n< Date:?Mon, 03 Oct 2011 21:13:58 GMT\n<\n<html>\n<head>\n<title>401 Unauthorized</title>\n</head>\n<body>\n<h1>401 Unauthorized</h1>\n? This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.<br /><br />\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111003/07f15d4d/attachment.html>\n\n',NULL,NULL),('<1317756550.6967081416945677162.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-11-25 20:01:17',0,'2014-11-25 20:01:17',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting December 2, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting December 2, 2014\nHost: Alan Clark\nDate: Tuesday, December 2, 2014\nTime: 12:00 pm, Pacific Standard Time (San Francisco, GMT-08:00)\n\nSession number: 496 704 260\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t914ded96f1b5c0325aa188b32a2eddea\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tcffe751b648c6d4d4bed514161c1646a\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=302703958&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 496 704 260\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb7c348bd0161189a702cfd2a42f72b9d\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20141125/85c73f90/attachment.html>\n\n',NULL,NULL),('<1318185350.24665.YahooMailNeo@web161701.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-09 11:35:50',-25200,'2011-10-09 18:35:50',NULL,'[Openstack-operators] (no subject)','I\'ve finished installing Swift on 6 EC2 nodes, but I\'m struggling on this seemingly simple step:\n\nhttp://docs.openstack.org/diablo/openstack-object-storage/admin/content/part-i-setting-up-secure-access.html\n\n\nSome quick questions:\n\n1. I\'m probably missing something obvious but where do I get the \"swift\" tool from?\n2. Also, do these below iptables look OK?\n3. Finally, do I have to restart some service to have the new iptables read??\n\nThanks,\n\nAmar\n\n\nChain INPUT (policy ACCEPT 454 packets, 36014 bytes)\n?pkts bytes target ? ? prot opt in ? ? out ? ? source ? ? ? ? ? ? ? destination\n45287 4651K ACCEPT ? ? all ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?ctstate RELATED,ESTABLISHED\n? ? 0 ? ? 0 ACCEPT ? ? all ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?state RELATED,ESTABLISHED\n?3505 ?210K ACCEPT ? ? tcp ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?tcp dpt:ssh\n? ?12 ? 720 ACCEPT ? ? tcp ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?tcp dpt:https\n? ? 0 ? ? 0 LOG ? ? ? ?all ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: \'\n? ? 7 ? 408 ACCEPT ? ? tcp ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?tcp dpt:www\n? ? 0 ? ? 0 ACCEPT ? ? tcp ?-- ?any ? ?any ? ? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ?tcp dpt:https\n\nChain FORWARD (policy ACCEPT 0 packets, 0 bytes)\n?pkts bytes target ? ? prot opt in ? ? out ? ? source ? ? ? ? ? ? ? destination\n\nChain OUTPUT (policy ACCEPT 48502 packets, 8622K bytes)\n?pkts bytes target ? ? prot opt in ? ? out ? ? source ? ? ? ? ? ? ? destination\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111009/5628c5e1/attachment.html>\n\n',NULL,NULL),('<1318426290.365231732@apps.rackspace.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2011-10-12 09:31:30',-14400,'2011-10-12 13:31:30',NULL,'[OpenStack Foundation] Hello...','I think this is a good list of questions Jay.  I expect it will take some time to figure them all out.  Agree with Thierry we need to separate them.\n\nI think it would be good to give a few more days for people to join the list before diving in too deep.  I\'ll put up a blog post today to help spread the word about the list.\n\nAs far as what to tackle first, I think it would make sense to start at a high level, recapping the discussion at the conference (video of it should be available next week to post) and address some of the initial questions about Mission & Scope before getting into structure, funding, and all that fun stuff :)\n\nScott Sanchez was kind enough to play court stenographer for last week\'s session.  If anyone wants to clean it up, feel free:   http://etherpad.openstack.org/BsUGmhl7QA\n\n\n\n\n-----Original Message-----\nFrom: \"Jay Pipes\" <jaypipes at gmail.com>\nSent: Wednesday, October 12, 2011 8:52am\nTo: \"Jan Drake\" <jan_drake at hotmail.com>\nCc: \"foundation at lists.openstack.org\" <foundation at lists.openstack.org>\nSubject: Re: [OpenStack Foundation] Hello...\n\nHi Jan!\n\nI\'d like to see some discussion regarding what initial functions will\nmove to a foundation first? Legal and trademark policy stuff,\ncopyright and patent management sound like good beginning efforts.\n\nHow are participating organizations going to join the foundation, and\nwhat dollar amounts grant the donor organization what rights? Is it a\ngood idea to look at separating the (currently singular) Project\nPolicy Board into at least two boards, one focused on technical\nmatters and another focused on legal, copyright, and trademark issues?\n\nWhat, if any, technical roles should be placed into the foundation?\nRelease management? Community management? Infrastructure development\nlike Jenkins and source control, list management, etc?\n\nShould openstack.org and the maintenance of that site be moved under\ncontrol of foundation employees?\n\nShould the foundation even have employees, or should foundation roles\nsimply be employees of donor organizations, with their salaries\ncomposing some part of foundation membership dues?\n\nAll questions that I\'ve personally been wondering about and questions\nI heard voiced last week by numerous individuals.\n\nCheers,\n-jay\n\nOn Tue, Oct 11, 2011 at 11:07 PM, Jan Drake <jan_drake at hotmail.com> wrote:\n> ...glad to see this formed. ?First salvos anyone. ?;)\n>\n>\n>\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n','<CAAE6tVbD9Btu6X7E2g00NReifuECu2SQKvXmQPP-Ju-OHAr3rQ@mail.gmail.com>',NULL),('<1318529462.2570.90.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2011-10-13 19:11:01',3600,'2011-10-13 18:11:01',NULL,'[OpenStack Foundation] Board of directors: scope and\n composition (a.k.a. the Money board)','Hi Thierry,\n\nOn Wed, 2011-10-12 at 15:23 +0200, Thierry Carrez wrote:\n> From Jay\'s original email:\n> > How are participating organizations going to join the foundation, and\n> > what dollar amounts grant the donor organization what rights? Is it a\n> > good idea to look at separating the (currently singular) Project\n> > Policy Board into at least two boards, one focused on technical\n> > matters and another focused on legal, copyright, and trademark issues?\n> \n> As I said during the Town Hall session at the Conference, I think there\n> needs to be a Board of directors (where membership is linked to your\n> company commitment to OpenStack, including monetary) that is separate\n> from the Technical board (which should become a pure elected code\n> committer meritocracy).\n> \n> This board of directors should handle how the Foundation money is spent\n> (including setting compensation for Foundation employees, if any),\n> should encourage participation and focus on legal issues. Should they\n> also handle (or participate to) the OpenStack scope definition ?\n> \n> The board of directors could have Strategic members (that show a\n> multi-year monetary commitment, together with some measurable level of\n> strategic involvement in the project, to be defined) with one seat each.\n> It should also have Sustaining members: a number of seats for\n> representatives of the wider ecosystem of companies showing interest in\n> OpenStack. For example, if you have 5 strategic members and 80 ordinary\n> companies, you could have a total of 9 seats, with all ordinary\n> companies holding an election to decide who should represent them on\n> their 4 board seats.\n\nRestricting the board to company representatives jars a little with me,\nI must admit.\n\nI like how GNOME have it structured[1]:\n\n  - The board is composed of individuals elected by the members of the \n    foundation, where each director tries to represent the foundation \n    membership rather than their employer. Directors do their best to \n    leave their affiliation aside when wearing their director hat. Even \n    still, no single company can have employees which make up more than\n    40% of the board.\n\n  - There is an advisory board composed of representatives of companies \n    who sponsor the foundation with either $10k or $20k a year, \n    depending on company size. Members of this board are explicitly \n    there to represent their employer and provide a perspective that \n    may be lacking on the board of directors.\n\nI think this recognizes the contribution of cash to the foundation with\na very real voice in the governance of the foundation.\n\nBut it also recognizes that cash isn\'t the most important thing the\nfoundation needs. To be truly sustainable, it first and foremost needs\nthe commitment of the individual foundation members (whether sponsored\nor not) to do the work which the foundation is there to enable.\n\n- i.e. the \"doers\" in community drive the direction of the foundation -\nand not just the technical direction - but they do so with the input and\nguidance of sponsoring companies.\n\nThe board is so critical to the foundation that we need the directors of\nour foundation to make a serious commitment to that role. They also need\nto represent the community, not their employers. While both of those\nrequirements aren\'t incompatible with appointments based on affiliation,\nI think we\'d do a lot better with an election open to all foundation\nmembers.\n\nCheers,\nMark.\n\n[1] - http://foundation.gnome.org/about/\n\n\n','<4E9594EE.1030704@openstack.org>',NULL),('<1318625106.30457.5929.camel@sledge.emsl.pnl.gov>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-14 13:45:06',-25200,'2011-10-14 20:45:06',NULL,'[Openstack-operators] Nova/libvirt','Quick question. How strongly does Nova assume it manages everything in\nlibvirt? I\'m curious if I wanted to fire up a few virtual machines\nmanually using libvirt on a nova managed host if it would confuse Nova.\nI\'m ok with Nova not knowing about them. I\'m wondering if Nova will\nassume it has more resources then are available and flip out.\n\nThanks,\nKevin\n\n\n',NULL,NULL),('<1318812387.41.1375596179901.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-04 06:02:59',0,'2013-08-04 06:02:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #309','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/309/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-181613 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #212084 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stable-folsom] $ /bin/bash -xe /tmp/hudson1770896557479483453.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stable-folsom] $ /bin/bash -xe /tmp/hudson2398947504127359725.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az3-181613\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az3-181613/309\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az3-181613/309/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az3-181613/309/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1318825695.66506863.1379979402834.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 16:36:42',-25200,'2013-09-23 23:36:42',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update\n 2013-09-23','Greetings Stackers!\n\nWe\'ve had a lot of merges lately in the vmwareapi folders so if you have a review pending there, take a moment to \"git fetch --all\" and rebase your patch! Thanks for all the attention we\'ve been getting lately, and thanks tot he contributors for staying on top of their respective contributions. Here\'s a breakdown of the changes I\'m tracking. First ordered by \"priority\" based on health of the driver, then ordered by the number of +1 votes.\n\nWe have 6 reviews that look like they\'re in good shape for a core-reviewer to take a look.\n\n--------------------------------------------------------------------------------\n\nOrdered by bug priority:\n High/Critical https://bugs.launchpad.net/bugs/1223709 \n    https://review.openstack.org/46027 votes:(+2:2,+1:5,-1:0,-2:1), status: needs revision\n\n High/Critical https://bugs.launchpad.net/bugs/1226211 \n    https://review.openstack.org/46789 votes:(+2:1,+1:7,-1:0,-2:0), status: needs one more +2/approval\n\n High/Critical https://bugs.launchpad.net/bugs/1217541 \n    https://review.openstack.org/43621 votes:(+2:1,+1:2,-1:1,-2:0), status: needs revision\n\n High/High https://bugs.launchpad.net/bugs/1226052 \n    https://review.openstack.org/46730 votes:(+2:0,+1:2,-1:0,-2:0), status: needs review\n\n High/High https://bugs.launchpad.net/bugs/1171226 \n    https://review.openstack.org/43994 votes:(+2:0,+1:4,-1:0,-2:0), status: ready for core\n\n Medium/High https://bugs.launchpad.net/bugs/1207064 \n    https://review.openstack.org/47503 votes:(+2:1,+1:3,-1:1,-2:0), status: needs revision\n\n Medium/Medium https://bugs.launchpad.net/bugs/1199954 \n    https://review.openstack.org/46231 votes:(+2:1,+1:3,-1:1,-2:0), status: needs revision\n\n High https://bugs.launchpad.net/bugs/1214850 \n    https://review.openstack.org/43270 votes:(+2:0,+1:1,-1:0,-2:0), status: needs review\n\n High https://bugs.launchpad.net/bugs/1226826 \n    https://review.openstack.org/47030 votes:(+2:0,+1:5,-1:0,-2:0), status: ready for core\n\n High https://bugs.launchpad.net/bugs/1225002 \n    https://review.openstack.org/41977 votes:(+2:0,+1:5,-1:0,-2:0), status: ready for core\n\n High https://bugs.launchpad.net/bugs/1227825 \n    https://review.openstack.org/47289 votes:(+2:0,+1:2,-1:0,-2:0), status: needs review\n\n High https://bugs.launchpad.net/bugs/1194018 \n    https://review.openstack.org/43641 votes:(+2:1,+1:6,-1:0,-2:0), status: needs one more +2/approval\n\n<snip> trimming anything Medium or below off..\n\n--------------------------------------------------------------------------------\nOrdered by fitness for review:\n\n== needs one more +2/approval ==\n* https://review.openstack.org/43268\n	title: \'VMware: enable VNC access without user having to enter pa...\'\n	votes: +2:1, +1:3, -1:0, -2:0. +32 days in progress, revision: 13 is 1 days old \n* https://review.openstack.org/43641\n	title: \'VMware: Fix ensure_vlan_bridge to work properly with exis...\'\n	votes: +2:1, +1:6, -1:0, -2:0. +29 days in progress, revision: 14 is 6 days old \n* https://review.openstack.org/46789\n	title: \'VMware: fix bug for incorrect cluster access\'\n	votes: +2:1, +1:7, -1:0, -2:0. +7 days in progress, revision: 1 is 7 days old \n* https://review.openstack.org/46896\n	title: \'Add linked clone related unit tests for VMware Hyper\'\n	votes: +2:1, +1:5, -1:0, -2:0. +6 days in progress, revision: 1 is 6 days old \n\n== ready for core ==\n* https://review.openstack.org/43994\n	title: \'VMwareVCDriver Fix sparse disk copy error on spawn\'\n	votes: +2:0, +1:4, -1:0, -2:0. +26 days in progress, revision: 20 is 0 days old \n* https://review.openstack.org/47030\n	title: \'VMware: Fix volume detach failure\'\n	votes: +2:0, +1:5, -1:0, -2:0. +6 days in progress, revision: 2 is 5 days old \n* https://review.openstack.org/41977\n	title: \'VMware: Network fallback in case specified one not found\'\n	votes: +2:0, +1:5, -1:0, -2:0. +40 days in progress, revision: 5 is 8 days old \n\n== needs review ==\n* https://review.openstack.org/43665\n	title: \'VMware: Check for the propSet attribute\'s existence befor...\'\n	votes: +2:0, +1:2, -1:0, -2:0. +28 days in progress, revision: 6 is 2 days old \n* https://review.openstack.org/47289\n	title: \'fixes datastore selection bug 1227825\'\n	votes: +2:0, +1:2, -1:0, -2:0. +5 days in progress, revision: 8 is 0 days old \n* https://review.openstack.org/46730\n	title: \'VMware: Fix bug for root disk size\'\n	votes: +2:0, +1:2, -1:0, -2:0. +7 days in progress, revision: 10 is 1 days old \n* https://review.openstack.org/46400\n	title: \'VMware: booting multiple instances fails if image is not ...\'\n	votes: +2:0, +1:2, -1:0, -2:0. +11 days in progress, revision: 7 is 3 days old \n\n== needs revision ==\n* https://review.openstack.org/46824\n	title: \'VMware: Fix SwitchNotFound error when network exists\'\n	votes: +2:1, +1:2, -1:1, -2:0. +7 days in progress, revision: 2 is 0 days old \n* https://review.openstack.org/46231\n	title: \'VMware: fix VM resize bug\'\n	votes: +2:1, +1:3, -1:1, -2:0. +11 days in progress, revision: 7 is 2 days old \n* https://review.openstack.org/46027\n	title: \'VMware: fix bug with booting from volume\'\n	votes: +2:2, +1:5, -1:0, -2:1. +12 days in progress, revision: 3 is 0 days old \n* https://review.openstack.org/47503\n	title: \'VMWare: Disabling linked clone doesn\'t cache images\'\n	votes: +2:1, +1:3, -1:1, -2:0. +4 days in progress, revision: 4 is 4 days old \n* https://review.openstack.org/43621\n	title: \'VMware: Handle case when there are no hosts in cluster\'\n	votes: +2:1, +1:2, -1:1, -2:0. +29 days in progress, revision: 6 is 2 days old \n* https://review.openstack.org/43621\n	title: \'VMware: Handle case when there are no hosts in cluster\'\n	votes: +2:1, +1:2, -1:1, -2:0. +29 days in progress, revision: 6 is 2 days old \n* https://review.openstack.org/47618\n	title: \'plug_vif raise NotImplementedError instead of pass\'\n	votes: +2:0, +1:0, -1:1, -2:0. +3 days in progress, revision: 12 is 1 days old \n* https://review.openstack.org/46895\n	title: \'Fix problem specifying VMware network name in flat networ...\'\n	votes: +2:0, +1:2, -1:1, -2:0. +6 days in progress, revision: 3 is 6 days old \n* https://review.openstack.org/45203\n	title: \'Use RetrievePropertiesEx instead of RetrieveProperties\'\n	votes: +2:0, +1:1, -1:1, -2:0. +18 days in progress, revision: 2 is 18 days old \n\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n* If anything is missing, ping me so I can examine it\n* We hang out in #openstack-vmware if you need to chat.\n\nHappy stacking!\n\n# Shawn Hartsock\n\n\n','<1304746115.66443882.1379975741945.JavaMail.root@vmware.com>',NULL),('<1318848212.2048.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-17 11:43:30',3600,'2011-10-17 10:43:30',NULL,'[Openstack-operators] Problem running Openstack on fedora 16\n (nova segfault)','Hi Sergey,\n\nOn Fri, 2011-10-14 at 21:57 +0300, Sergey Kulanov wrote:\n\n>    Installing : \n> openstack-swift-object-1.4.0-2.fc16.noarch                                                                           \n> 1/5\n> Non-fatal POSTIN scriptlet failure in rpm package \n> openstack-swift-object-1.4.0-2.fc16.noarch\n> error reading information on service swift-object: No such file or directory\n> warning: %post(openstack-swift-object-1.4.0-2.fc16.noarch) scriptlet \n> failed, exit status 1\n\nIt looks like this problem was reported sometime ago and a patch is\nwaiting to be applied:\n\n  https://bugzilla.redhat.com/685155\n\nSilas, David - can one of you take care of this or should I?\n\nCheers,\nMark.\n\n\n','<4E988631.10905@kulanov.org.ua>',NULL),('<1318849375.2048.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-17 12:02:54',3600,'2011-10-17 11:02:54',NULL,'[Openstack-operators] Problem running Openstack on fedora 16\n (nova segfault)','On Fri, 2011-10-14 at 21:57 +0300, Sergey Kulanov wrote:\n\n> ---------------------------NOVA START -----------------------\n> service openstack-nova-api start\n> \n> /var/log/messages\n> Oct 14 21:30:55 server1 kernel: [ 1186.188224] nova-api[1560]: segfault \n> at 4 ip 0025a950 sp bfef9108 error 4 in libc-2.14.90.so[115000+1a7000]\n> Oct 14 21:30:55 server1 systemd[1]: openstack-nova-api.service: main \n> process exited, code=killed, status=11\n> Oct 14 21:30:55 server1 systemd[1]: Unit openstack-nova-api.service \n> entered failed state.\n\nSo, there are some known problems with 2.14.90-11\n\n  https://admin.fedoraproject.org/updates/FEDORA-2011-14175\n\nCould you try:\n\n  $> yum downgrade glibc?\n\nHopefully that will get you 2.14.90-10\n\nThanks,\nMark.\n\n\n','<4E988631.10905@kulanov.org.ua>',NULL),('<1319120115.16385.113.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2011-10-20 15:15:13',3600,'2011-10-20 14:15:13',NULL,'[OpenStack Foundation] Board of directors: scope and\n composition (a.k.a. the Money board)','On Thu, 2011-10-20 at 15:01 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Wed, 2011-10-12 at 15:23 +0200, Thierry Carrez wrote:\n> >> From Jay\'s original email:\n> >>> How are participating organizations going to join the foundation, and\n> >>> what dollar amounts grant the donor organization what rights? Is it a\n> >>> good idea to look at separating the (currently singular) Project\n> >>> Policy Board into at least two boards, one focused on technical\n> >>> matters and another focused on legal, copyright, and trademark issues?\n> >>\n> >> As I said during the Town Hall session at the Conference, I think there\n> >> needs to be a Board of directors (where membership is linked to your\n> >> company commitment to OpenStack, including monetary) that is separate\n> >> from the Technical board (which should become a pure elected code\n> >> committer meritocracy).\n> >>\n> >> This board of directors should handle how the Foundation money is spent\n> >> (including setting compensation for Foundation employees, if any),\n> >> should encourage participation and focus on legal issues. Should they\n> >> also handle (or participate to) the OpenStack scope definition ?\n> >>\n> >> The board of directors could have Strategic members (that show a\n> >> multi-year monetary commitment, together with some measurable level of\n> >> strategic involvement in the project, to be defined) with one seat each.\n> >> It should also have Sustaining members: a number of seats for\n> >> representatives of the wider ecosystem of companies showing interest in\n> >> OpenStack. For example, if you have 5 strategic members and 80 ordinary\n> >> companies, you could have a total of 9 seats, with all ordinary\n> >> companies holding an election to decide who should represent them on\n> >> their 4 board seats.\n> > \n> > Restricting the board to company representatives jars a little with me,\n> > I must admit.\n> > \n> > I like how GNOME have it structured[1]:\n> > \n> >   - The board is composed of individuals elected by the members of the \n> >     foundation, where each director tries to represent the foundation \n> >     membership rather than their employer. Directors do their best to \n> >     leave their affiliation aside when wearing their director hat. Even \n> >     still, no single company can have employees which make up more than\n> >     40% of the board.\n> > \n> >   - There is an advisory board composed of representatives of companies \n> >     who sponsor the foundation with either $10k or $20k a year, \n> >     depending on company size. Members of this board are explicitly \n> >     there to represent their employer and provide a perspective that \n> >     may be lacking on the board of directors.\n> > \n> > I think this recognizes the contribution of cash to the foundation with\n> > a very real voice in the governance of the foundation.\n> > \n> > But it also recognizes that cash isn\'t the most important thing the\n> > foundation needs. To be truly sustainable, it first and foremost needs\n> > the commitment of the individual foundation members (whether sponsored\n> > or not) to do the work which the foundation is there to enable.\n> > \n> > - i.e. the \"doers\" in community drive the direction of the foundation -\n> > and not just the technical direction - but they do so with the input and\n> > guidance of sponsoring companies.\n> > \n> > The board is so critical to the foundation that we need the directors of\n> > our foundation to make a serious commitment to that role. They also need\n> > to represent the community, not their employers. While both of those\n> > requirements aren\'t incompatible with appointments based on affiliation,\n> > I think we\'d do a lot better with an election open to all foundation\n> > members.\n> \n> I guess it depends on the respective attributions of the different\n> boards. You are advocating for three boards:\n> \n> - Directors board (elected by the general community)\n> - Advisory (or \"Money\") board (paid for by contributing companies)\n> - Technical board (elected by code contributors)\n> \n> One issue with this setup is the need to define \"general community\".\n> What gives you a right to vote on that election ? Some level of\n> involvement ? The other two corpus (corpi ?) are well defined -- code\n> contributors and companies contributing money. What makes a general\n> community member, with the ability to pick the best directors ? Should\n> we setup, first and foremost, a membership board that decides if a given\n> individual contribution is enough to make him a \"community member\" ?\n\nAgain, using GNOME as the example ... any member of the foundation can\nvote. The membership rules are here:\n\n  http://foundation.gnome.org/membership/\n\n  Who is eligible for membership in the GNOME Foundation?\n\n  Per the GNOME Foundation\'s charter, any contributor to GNOME is\n  eligible for membership. Although it is difficult to specify a precise\n  definition, a contributor generally must have contributed to a\n  non-trivial improvement of the GNOME Project. Contributions may be\n  code, documentation, translations, maintenance of project-wide\n  resources, or other non-trivial activities which benefit the GNOME\n  Project. [...]\n\nThere\'s a membership committee made up of volunteers who apply the\nguidelines:\n\n  http://live.gnome.org/MembershipCommittee\n\nEverything they do is open to scrutiny on their mailing list.\n\n> The second issue is the respective authority of each board. For example,\n> who defines what should be accepted as a core project ?\n\nUltimately, under the foundation\'s charter, it should probably be the\nboard but they would delegate the responsibility to the PPB.\n\nIn GNOME, the release team makes the equivalent decision by attempting\nto judge the consensus reached on the public discussion of the project\'s\nproposal.\n\n> Is it a proposal of the technical board that can be vetoed by the\n> directors board ?\n\nTechnically, I guess. But I\'d hope it would be unusual. You want the\nboard of directors to have ultimate oversight I think.\n\n> Vetoed by the directors board and the advisory board ?\n\nNope, the advisory board wouldn\'t have veto powers.\n\n> What are the actual rights of the advisory board, the way you propose\n> to set it up ?\n\nThe advisory board is the place where companies who have contributed\nmoney to the foundation have the right to make recommendations to the\nboard of directors. I\'d also expect the board of directors to ask the\nadvisory board for input on some decisions they need to make.\n\nIt\'s the one place in the foundation where there are people explicitly\nthere to represent the views of their company. Everywhere else members\nare expected to be avoid being \"a mouthpiece for whatever company\nhappens to be signing their paychecks right now\" as the ASF puts it[1].\n\nI think this is key - if the board of directors run the foundation and\ncompanies can buy a seat on that board purely by sponsoring the\nfoundation, then it means you have decision making directors who are\nonly accountable to the company they work for. You also over-emphasise\nthe value of cash contributions to the foundation when, ultimately, the\nfoundation should be able to survive (if needs be) with a minimal cash\nbudget but cannot survive without the non-cash contributions that the\nfoundation is there to facilitate.\n\nThe GNOME charter puts it nicely:\n\n  http://foundation.gnome.org/about/charter/\n\n  \"members of the board of directors shall act on behalf of all GNOME\n   contributors in the best interest of the GNOME project. Although\n   board members may be affiliated with companies that have an interest\n   in the success of GNOME, they will not be considered representatives\n   of companies with which they are affiliated. The GNOME Foundation\n   Board of Advisors provides a forum for corporate representation.\"\n\n> What would the directors board do that couldn\'t fall on the shoulders of\n> either the money board or technical board ?\n\n\"The board is the primary decision-making body of the [..] foundation.\nIt is responsible for ratifying all decisions the [..] foundation\nmakes.\"\n\ni.e. it has ultimate responsibility for everything but, in practice,\ndelegates a lot of stuff.\n\nThis is a nice example of the kind of things the GNOME board takes\ndirect responsibility for:\n\n  http://live.gnome.org/FoundationBoard/Minutes/20111004\n\n    - conference planning and budgeting\n    - fundraising\n    - spending, contracts, etc.\n    - preparing an annual report, including accounts\n    - affiliations with other organizations\n    - working with the advisory board\n    - trademark control\n    - working with the likes of Google Summer of Code\n\nThe board also will mediate disputes if needed.\n\nTo summarize my main points:\n\n  - I think the board needs to have ultimate responsibility for the \n    foundation, and I don\'t think the term \"money board\" reflects that\n\n  - Membership of the foundation should be open to anyone who makes \n    technical or non-technical contributions to the foundation and/or \n    its projects\n\n  - I don\'t think corporate representation is appropriate on the board \n    of directors, but I do think corporate sponsors need an official \n    way to make representations to the foundation - i.e. an advisory \n    board\n\nCheers,\nMark.\n\n[1] - http://www.apache.org/foundation/how-it-works.html#management\n\n  Individuals compose the ASF\n\n  All of the ASF including the board, the other officers, the\n  committers, and the members, are participating as individuals. That is\n  one strength of the ASF, affiliations do not cloud the personal\n  contributions.\n\n  Unless they specifically state otherwise, whatever they post on any\n  mailing list is done as themselves. It is the individual\n  point-of-view, wearing their personal hat and not as a mouthpiece for\n  whatever company happens to be signing their paychecks right now, and\n  not even as a director of the ASF.\n\n\n','<4EA01BB2.7020800@openstack.org>',NULL),('<1319330763.144.1366006147344.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-15 06:09:07',0,'2013-04-15 06:09:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #5','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-15 06:09:02    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:09:02,284 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-15 06:09:02,285 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-15 06:09:02,286 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-15 06:09:02,286 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-15 06:09:02  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-15 06:09:02,287 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:09:02    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-15 06:09:02,288 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-15 06:09:02,288 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:09:02,289 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,289 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,292 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.292282\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.292282\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02,293 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,293 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02,294 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,295 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02,296 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.295346\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.295346\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02,297 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,297 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02,298 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:09:02,298 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,299 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,300 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02,300 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.300145\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.300145\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02,301 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,302 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02,302 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:09:02,303 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,303 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,304 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02,305 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.304741\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.304741\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02,306 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,307 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02,307 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:09:02,308 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,308 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,309 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-15 06:09:02,310 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-15 06:09:02,311 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.310641\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-15T06:09:02.310641\', resource_metadata={}) from 0 transformer\n2013-04-15 06:09:02,312 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,312 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02,313 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-15 06:09:02,313 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-15 06:09:02,314 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-15 06:09:02    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.434s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.5\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a46.ga0e15fa\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a310.g0fc0588\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.08Tyl98SZJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/5\n[SCP] Copying console log.\n\n\n','<1305539108.126.1365919542028.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1319474900.49121276.1386586007487.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-09 05:46:47',-18000,'2013-12-09 10:46:47',NULL,'[Openstack-stable-maint] Freeze Exception request (Horizon)','Hi,\n\nI\'d like to request a freeze exception for the following Horizon review:\n\nhttps://review.openstack.org/#/c/55425/\n\nIt\'s a self-contained change that was merged on master several weeks ago,\nhowever due to the ordering in which stable patches were merged it required\na rebase.\n\nWithout it the Resource Usage graph, which displays information based on the\nCeilometer data, only works with Nova but not with any other resources type.\n\nThanks,\n\nJulie\n\n\n','<1407634607.49113257.1386585601485.JavaMail.root@redhat.com>',NULL),('<1319535612.12527197.1400468484843.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-18 23:01:24',-14400,'2014-05-19 03:01:24',NULL,'[openstack-dev] [Neutron][NFV] NFV BoF at design summit','----- Original Message -----\n> From: \"Sumit Naiksatam\" <sumitnaiksatam at gmail.com>\n> \n> Thanks for initiating this conversation. Unfortunately I was not able\n> to participate during the summit on account of overlapping sessions.\n> As has been identified in the wiki and etherpad, there seem to be\n> obvious/potential touch points with the advanced services\' discussion\n> we are having in Neutron [1]. Our sub team, and I, will track and\n> participate in this NFV discussion. Needless to say, we are definitely\n> very keen to understand and accommodate the NFV requirements.\n> \n> Thanks,\n> ~Sumit.\n> [1] https://wiki.openstack.org/wiki/Neutron/AdvancedServices\n\nYes, there are definitely touch points across a number of different existing projects and sub teams. The consensus seemed to be that while a lot of people in the community have been working in independent groups on advancing the support for NFV use cases in OpenStack we haven\'t necessarily been coordinating our efforts effectively. Hopefully having a cross-project sub team will allow us to do this.\n\nIn the BoF sessions we started adding relevant *existing* blueprints on the wiki page, we probably need to come up with a more robust way to track these from launchpad :). Further proposals will no doubt need to be built out from use cases as we discuss them further:\n\n    https://wiki.openstack.org/wiki/Meetings/NFV\n\nFeel free to add any blueprints from the Advanced Services efforts that were missed!\n\nThanks,\n\nSteve\n\n\n','<CAMWrLvhEpJLKoVrEAa+ovTcGCZH7=7+X+-tHjjM_TBNA5mSkmg@mail.gmail.com>',NULL),('<1319789283.105.1365748416044.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-12 06:33:36',0,'2013-04-12 06:33:36',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-folsom #193','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/193/changes>\n\n\n\n','<46327229.87.1365662027388.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<131B4265-D5FB-4D3F-A9C4-63EC9CB3CCF5@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 22:15:09',0,'2014-03-28 22:15:09',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','Hi,\n\nI have a VM that I start up outside of OpenStack (as a short term solution, until we get it working inside a Nova VM), using KVM. It has scrips associated with the three interfaces that are created, to hook this VM into Neutron. One I/F is on br-ex (connected to the ?public\" network for DevStack), another to br-int (connected to a management network that is created), and a third is connected to br-int (connected to the ?private? network for DevStack). It?s understood these are hacks to get things going and can be brittle.  With DevStack, I have a vanilla localrc, so using ML2, without any ML2 settings specified.\n\nNow, the first two scripts use internal Neutron client calls to create the port, and then plug the VIF. The third, uses Neutron to create the port, and then Nova to plug the VIF. I don?t know why - I inherited the scripts.\n\nOn one system, where Nova is based on commit b3e2e05 (10 days ago), this all works just peachy. Interfaces are hooked in and I can ping to my hearts content. On another system, that I just reimaged today, using the latest and greatest OpenStack projects, the third script fails.\n\nI talked to Nova folks, and the vic is now an object, instead of a plain dict, and therefore calls on the object fail (as the script just provides a dict). I started trying to convert the vif to an object, but in discussing with a co-worker, we thought that we could too use Neutron calls for all of the setup of this third interface.\n\nWell, I tried, and the port is created, but unlike the other system, the port is DOWN, and I cannot ping to or from it (the other ports still work fine, with this newer OpenStack repo). One difference is that the port is showing  {\"port_filter\": true, \"ovs_hybrid_plug\": true} for binding:vif_details, in the neutron port-show output. On the older system this is empty (so must be new changes in Neutron?)\n\n\nHere is the Neutron based code (trimmed) to do the create and plugging:\n\nimport neutron.agent.linux.interface as vif_driver\nfrom neutronclient.neutron import client as qclient\n\nqc = qclient.Client(\'2.0\', auth_url=KEYSTONE_URL, username=user, tenant_name=tenant, password=pw)\n\nprefix, net_name = interface.split(\'__\')\nport_name = net_name + \'_p\'\ntry:\n    nw_id = qc.list_networks(name=net_name)[\'networks\'][0][\'id\']\nexcept qcexp.NeutronClientException as e:\n    ?\n\np_spec = {\'port\': {\'admin_state_up\': True,\n                   \'name\': port_name,\n                   \'network_id\': nw_id,\n                   \'mac_address\': mac_addr,\n                   \'binding:host_id\': hostname,\n                   \'device_id\': vm_uuid,\n                   \'device_owner\': \'compute:None\'}}\n\ntry:\n    port = qc.create_port(p_spec)\nexcept qcexp.NeutronClientException as e:\n    ...\n\nport_id = port[\'port\'][\'id\']\nbr_name = \'br-int\'\n\nconf = cfg.CONF\nconfig.register_root_helper(conf)\nconf.register_opts(vif_driver.OPTS)\n\ndriver = vif_driver.OVSInterfaceDriver(cfg.CONF)\ndriver.plug(nw_id, port_id, interface, mac_addr, br_name)\n\nFinally, here are the questions (hope you stuck with the long message)?\n\nAny idea why the neutron version is not working? I know there were a bunch of recent changes.\nIs there a way for me to turn off the ova_hybrid_plug and port_filter flags? Should I?\nShould I go back to using Nova and build a VIF object?\nIf so, any reason why the Neutron version would not work?\nIs there a way to do a similar thing, but via using Northbound APIs (so it isn?t as brittle)?\n\nThanks in advance!\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pcm_ (irc.freenode.com<http://irc.freenode.com>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140328/40288d39/attachment.html>\n\n',NULL,NULL),('<1320146039.1896.18.camel@warchild>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-01 12:13:56',3600,'2011-11-01 11:13:56',NULL,'[Openstack-operators] [Swift][Keystone] Ressource not found','Heyho Guys,\n\ni\'ve a problem with swift and keystone.\nI added a new user in keystone with role and all this stuff. This works\nand i can login in my dashboard.\nIf i try now to get the containers from swift, then I get this error\nbelow. \n\nNov  1 10:14:27 test1-os swift Keystone middleware called\nNov  1 10:14:27 test1-os swift token:\nc9022cd4-xxxxx-xxxxxx-xxxxx-d58397f54080\nNov  1 10:14:27 test1-os swift Asking keystone to validate token\nNov  1 10:14:27 test1-os swift headers: {\'Content-type\':\n\'application/json\', \'Accept\': \'text/json\', \'X-Auth-Token\':\n\'1111111111111111\'}\nNov  1 10:14:27 test1-os swift url: ParseResult(scheme=\'http\',\nnetloc=\'localhost:5001\', path=\'/v2.0/\', params=\'\', query=\'\',\nfragment=\'\')\nNov  1 10:14:27 test1-os swift request authenticated: {\'roles\': [u\'3\',\nu\'3\'], \'user\': u\'test\', \'tenant\': u\'3\'}\nNov  1 10:14:27 test1-os swift calling app: <function start_response at\n0x7f4344377398> // {\'SCRIPT_NAME\': \'\', \'REQUEST_METHOD\': \'GET\',\n\'PATH_INFO\': \'/v1/AUTH_3/\', \'SERVER_PROTOCOL\': \'HTTP/1.0\',\n\'QUERY_STRING\': \'format=json\', \'swift.authorize\': <bound method\nAuthProtocol.authorize of <keystone.middleware.swift_auth.AuthProtocol\nobject at 0x18881d0>>, \'CONTENT_LENGTH\': \'0\', \'HTTP_X_AUTH_TOKEN\':\n\'c9022cd4-xxxxx-xxxxxx-xxxxx-d58397f54080\', \'HTTP_USER_AGENT\':\n\'python-cloudfiles/1.7.9.1\', \'eventlet.posthooks\': [], \'SERVER_NAME\':\n\'192.168.0.2\', \'REMOTE_ADDR\': \'192.168.0.2\', \'eventlet.input\':\n<eventlet.wsgi.Input object at 0x1bd1cd0>, \'wsgi.url_scheme\': \'http\',\n\'keystone.identity\': {\'roles\': [u\'3\', u\'3\'], \'user\': u\'test\', \'tenant\':\nu\'3\'}, \'SERVER_PORT\': \'8080\', \'wsgi.input\': <eventlet.wsgi.Input object\nat 0x1bd1cd0>, \'HTTP_HOST\': \'192.168.0.2:8080\', \'swift.cache\':\n<swift.common.memcached.MemcacheRing object at 0x1bd1210>,\n\'wsgi.multithread\': True, \'wsgi.version\': (1, 0), \'GATEWAY_INTERFACE\':\n\'CGI/1.1\', \'wsgi.run_once\': False, \'wsgi.errors\':\n<swift.common.utils.LoggerFileObject object at 0x186c0d0>,\n\'wsgi.multiprocess\': False, \'CONTENT_TYPE\': None, \'swift.clean_acl\':\n<function clean_acl at 0x18822a8>, \'HTTP_ACCEPT_ENCODING\': \'identity\'}\nNov  1 10:14:27 test1-os swift keystone middleware authorization begin\n(txn: txc4288a66373348d0805b72d6b0b3b976) (client_ip: 192.168.0.2)\nNov  1 10:14:27 test1-os swift AUTHORIZED OKAY (txn:\ntxc4288a66373348d0805b72d6b0b3b976) (client_ip: 192.168.0.2)\nNov  1 10:14:27 test1-os account-server 192.168.0.2 - -\n[01/Nov/2011:09:14:27 +0000] \"GET /sda6/244982/AUTH_3\" 404 -\n\"txc4288a66373348d0805b72d6b0b3b976\" \"-\" \"python-cloudfiles/1.7.9.1\"\n0.0003 \"\"\nNov  1 10:14:27 test1-os swift return from app: [\'404 Not Found\\n\\nThe\nresource could not be found.\\n\\n   \'] (txn:\ntxc4288a66373348d0805b72d6b0b3b976) (client_ip: 192.168.0.2)\nNov  1 10:14:27 test1-os swift 192.168.0.2 192.168.0.2\n01/Nov/2011/09/14/27 GET /v1/AUTH_3/%3Fformat%3Djson HTTP/1.0 404 -\npython-cloudfiles/1.7.9.1 c9022cd4-xxxxx-xxxxxx-xxxxx-d58397f54080 - - -\ntxc4288a66373348d0805b72d6b0b3b976 - 0.0061\n\n\n\nThe mountpoint in /srv/node/sda6 exists with the correct rights. But\nthis folder doesn\'t exists.\n\nSo i try with the curl or Swift commands directly on the server to login\nand get this informations.\n\nThe result:\n\n> GET /auth/v1.0 HTTP/1.1\n> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7\nOpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n> Host: 192.168.0.2:8080\n> Accept: */*\n> X-Auth-Tokenr: c9022cd4-xxxxx-xxxxxx-xxxxx-d58397f54080\n> \n< HTTP/1.1 401 Unauthorized\n< Content-Length: 358\n< Content-Type: text/html; charset=UTF-8\n< Date: Tue, 01 Nov 2011 10:33:34 GMT\n< \n<html>\n <head>\n  <title>401 Unauthorized</title>\n </head>\n <body>\n  <h1>401 Unauthorized</h1>\n  This server could not verify that you are authorized to access the\ndocument you requested. Either you supplied the wrong credentials (e.g.,\nbad password), or your browser does not understand how to supply the\ncredentials required.<br /><br />\n\n </body>\n* Connection #0 to host 192.168.0.2 left intact\n* Closing connection #0\n\nIn the Log:\nNov  1 12:05:45 test1-os swift keystone middleware authorization begin\n(txn: tx0df22eb538f040da87f6b8fbfca505df) (client_ip: 192.168.0.2)\nNov  1 12:05:45 test1-os swift tenant mismatch: u\'3\' (txn:\ntx0df22eb538f040da87f6b8fbfca505df) (client_ip: 192.168.0.2)\nNov  1 12:05:45 test1-os swift return from app: [\'<html>\\n <head>\\n\n<title>401 Unauthorized</title>\\n </head>\\n <body>\\n  <h1>401\nUnauthorized</h1>\\n  This server could not verify that you are\nauthorized to access the document you requested. Either you supplied the\nwrong credentials (e.g., bad password), or your browser does not\nunderstand how to supply the credentials required.<br /><br />\\n\\n\\n\\n\n</body>\\n</html>\'] (txn: tx0df22eb538f040da87f6b8fbfca505df) (client_ip:\n192.168.0.2)\n\n\n\n\n\nMy config (only the important options):\nSwift-Proxy-Server(swift)\n\n[pipeline:main]\npipeline = healthcheck cache keystone proxy-server\n\n[filter:keystone]\nuse = egg:keystone#swiftauth\nkeystone_admin_token = 1111111111111111\nkeystone_url = http://localhost:5001/v2.0/\n\n\nIn the Keystone config i changed only bind-address and keystone runs on\nall NIC\'s.\n\n\nI hope for any idea :)\n\nGreetings\nHeiko\n\n\n\n\n-- \nHeiko Kr?mer \nCIO / Administrator\n\nAvarteq GmbH\nGeb?ude A1.2 - Universit?t des Saarlandes - 66123 Saarbr?cken - Germany\n\nPh/Fax: +49-700-RAILSHOSTER\nPh/Fax: +49-700-72 45 74 67\n\nWeb: www.avarteq.de\n\nGesch?ftsf?hrer: Alexander Fai?t, Dipl.-Inf.(FH) Julian Fischer\nHandelsregister: AG Saarbr?cken HRB 17413, Ust-IdNr.: DE262633168\nSitz: Saarbr?cken\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111101/99405e9c/attachment.html>\n\n',NULL,NULL),('<1320382289.40884.YahooMailNeo@web161703.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-03 21:51:29',-25200,'2011-11-04 04:51:29',NULL,'[Openstack-operators] Can\'t get s3curl to work','Also posted on Launchpad. Sorry for posting to two places.\n==\nHi All,\n\nI installed the s3 API on my swift cluster.\nI can successfully connect to it via Cyberduck and Python boto library. But not with s3curl. I can\'t figure out what I\'m doing wrong. Help appreciated.\nError below:\n====\nakapadia at ubuntu:~/s3-curl$ ./s3curl.pl --id personal --head -- -k -v -s?https://ec2-184-73-4-50.compute-1.amazonaws.com\n* About to connect() to ec2-184-73-4-50.compute-1.amazonaws.com port 443 (#0)\n* Trying 10.113.35.108... connected\n* Connected to ec2-184-73-4-50.compute-1.amazonaws.com (10.113.35.108) port 443 (#0)\n* successfully set certificate verify locations:\n* CAfile: none\n??CApath: /etc/ssl/certs\n* SSLv3, TLS handshake, Client hello (1):\n* SSLv3, TLS handshake, Server hello (2):\n* SSLv3, TLS handshake, CERT (11):\n* SSLv3, TLS handshake, Server finished (14):\n* SSLv3, TLS handshake, Client key exchange (16):\n* SSLv3, TLS change cipher, Client hello (1):\n* SSLv3, TLS handshake, Finished (20):\n* SSLv3, TLS change cipher, Client hello (1):\n* SSLv3, TLS handshake, Finished (20):\n* SSL connection using AES256-SHA\n* Server certificate:\n* subject: C=US; ST=CA; L=San Jose; O=OpenStack Consulting; OU=Swift; CN=ec2-184-73-4-50.compute-1.amazonaws.com; emailAddress=bitnami at ec2-184-73-4-50.compute-1.amazonaws.com\n* start date: 2011-11-04 04:26:58 GMT\n* expire date: 2011-12-04 04:26:58 GMT\n* common name: ec2-184-73-4-50.compute-1.amazonaws.com (matched)\n* issuer: C=US; ST=CA; L=San Jose; O=OpenStack Consulting; OU=Swift; CN=ec2-184-73-4-50.compute-1.amazonaws.com; emailAddress=bitnami at ec2-184-73-4-50.compute-1.amazonaws.com\n* SSL certificate verify result: self signed certificate (18), continuing anyway.\n> HEAD / HTTP/1.1\n> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n> Host: ec2-184-73-4-50.compute-1.amazonaws.com\n> Accept: */*\n> Date: Fri, 04 Nov 2011 04:40:41 +0000\n> Authorization: AWS test:tester:shoi7Ubs/hYe2VGucf5YesElDMI=\n>\n< HTTP/1.1 400 Bad Request\nHTTP/1.1 400 Bad Request\n< Content-Type: text/xml; charset=UTF-8\nContent-Type: text/xml; charset=UTF-8\n< Content-Length: 142\nContent-Length: 142\n< Date: Fri, 04 Nov 2011 04:40:42 GMT\nDate: Fri, 04 Nov 2011 04:40:42 GMT\n<\n* Connection #0 to host ec2-184-73-4-50.compute-1.amazonaws.com left intact\n* Closing connection #0\n* SSLv3, TLS alert, Client hello (1):\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111103/575f71d8/attachment.html>\n\n',NULL,NULL),('<1320539624.37.1375510813498.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-03 06:20:13',0,'2013-08-03 06:20:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #116','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/116/>\n\n------------------------------------------\n[...truncated 1224 lines...]\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_misc.TestMiscellaneous.test_exception_not_eaten_from_registry_to_api\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_misc.py\",> line 113, in test_exception_not_eaten_from_registry_to_api\n    self.assertEqual(\'{\"images\": []}\', out.strip())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: !=:\nreference = \'{\"images\": []}\'\nactual    = \'\'\'\\\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/wsgi.py\",> line 384, in handle_one_response\n    result = self.application(self.environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 362, in __call__\n    response = req.get_response(self.application)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1296, in send\n    application, catch_exc_info=False)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1260, in call_application\n    app_iter = application(self.environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 362, in __call__\n    response = req.get_response(self.application)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1296, in send\n    application, catch_exc_info=False)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1260, in call_application\n    app_iter = application(self.environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/paste/urlmap.py\",> line 203, in __call__\n    return app(environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 144, in __call__\n    return resp(environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/routes/middleware.py\",> line 131, in __call__\n    response = self.app(environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 144, in __call__\n    return resp(environ, start_response)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 569, in __call__\n    request, **action_args)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 586, in dispatch\n    return method(*args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/api/v1/images.py\",> line 171, in index\n    images = registry.get_images_list(req.context, **params)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/__init__.py\",> line 150, in get_images_list\n    return c.get_images(**kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/client.py\",> line 80, in get_images\n    res = self.do_request(\"GET\", \"/images\", params=params)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/client.py\",> line 90, in do_request\n    **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 377, in do_request\n    headers=headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 541, in _do_request\n    raise exception.ClientConnectionError(e)\nClientConnectionError: [Errno 111] ECONNREFUSED\'\'\'\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.96 secs:\n    26.76    TestScrubber.test_scrubber_app\n    20.84    TestScrubber.test_delayed_delete\n    14.93    TestRootApi.test_version_configurations\n    14.87    TestGlanceControl.test_reload\n    14.56    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 626.011s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.9\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.116\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.20\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.09.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.A604ImOwo8\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/116\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/116/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-5/116\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1320591D-BDE5-4445-9D46-2790AAC41093@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-08 13:06:07',0,'2014-04-08 13:06:07',NULL,'[Openstack-docs] Fwd: RC change with doc impact','Heads up.\n\nWe haven\'t addressed ipv6 in detail other than a mention in the ops guide that I know of. Still, please assess in your reviews.\n\nThanks,\nAnne\n\nAnne Gentle\nContent Stacker\nanne at openstack.org<mailto:anne at openstack.org>\n\n\nBegin forwarded message:\n\nFrom: Mark McClain <mmcclain at yahoo-inc.com<mailto:mmcclain at yahoo-inc.com>>\nDate: April 8, 2014 at 7:40:17 AM CDT\nTo: Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>>\nSubject: RC change with doc impact\n\nAnne-\n\nThis RC change might have a documentation impact since we?re hiding attributes for a half implemented feature:\n\nhttps://bugs.launchpad.net/neutron/+bug/1304093\n\nmark\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140408/6b70d338/attachment.html>\n\n',NULL,NULL),('<1320654800.3241.61.camel@Odin>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-07 09:33:20',3600,'2011-11-07 08:33:20',NULL,'[Openstack-operators] Error getting virtual servers up and\n running','Hi Alex,\n\n\ndo you have running your glance service ?\nHave you configured the correct ports/IP ?\n\n\nGreetings,\nHeiko\n\n\n\n\nAm Montag, den 07.11.2011, 09:50 +1100 schrieb Alex Chen:\n> Hi all,\n> \n>  \n> \n> I am having an error while trying to get a virtual machine to run the\n> virtual server.\n> \n>  \n> \n> I installed Nova with manual installation following the official\n> OpenStack Compute User Manual.\n> \n>  \n> \n> Then I went through Chapter 10 OpenStack Compute Tutorials. I set up\n> the Cloud Infrastructure, created a new project and user  and\n> configured user credentials.\n> \n>  \n> \n> Then I followed Part II to get a virtual machine to run the virtual\n> server. An image was successfully downloaded\n> ?ubuntu1010-UEC-localuser-image.tar.gz?. When I tried to publish the\n> image to the virtual machine it threw the following error:\n> \n> [ERRNO 111 ] Connection refused.\n> \n>  \n> \n> This stopped me continue the subsequent steps.\n> \n>  \n> \n> When I entered euca-describe-instances. It threw out the same error.\n> \n>  \n> \n> I have been trying a lot of googling around but no luck. I am a\n> beginner to OpenStack. Could anyone please give me some tips about\n> what might be wrong?\n> \n>  \n> \n> Thanks!\n> \n>  \n> \n> Cheers, Alex\n> \n> \n> \n> \n> \n> ______________________________________________________________________\n> This message is intended only for the use of the intended recipient(s)\n> If you are not an intended recipient, you are hereby notified that any\n> use, dissemination, disclosure or copying of this communication is\n> strictly prohibited. If you have received this communication in error\n> please destroy all copies of this message and its attachments and\n> notify the sender immediately\n> \n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n-- \nHeiko Kr?mer \n\nCIO / Administrator\n\nAvarteq GmbH\nGeb?ude A1.2 - Universit?t des Saarlandes - 66123 Saarbr?cken - Germany\n\nPh/Fax: +49-700-RAILSHOSTER\nPh/Fax: +49-700-72 45 74 67\n\nWeb: www.avarteq.de\n\nGesch?ftsf?hrer: Alexander Fai?t, Dipl.-Inf.(FH) Julian Fischer\nHandelsregister: AG Saarbr?cken HRB 17413, Ust-IdNr.: DE262633168\nSitz: Saarbr?cken\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111107/c8f7e965/attachment.html>\n\n','<658AAD349100834E94B8C486393AB5FCD818AE31C8@sac002.lmal.com.au>',NULL),('<1320880183.71553.YahooMailNeo@web161702.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-09 15:09:43',-28800,'2011-11-09 23:09:43',NULL,'[Openstack-operators] Problem send HTTP GET request.','I just went through this exercise. See if my blog on this topic helps:?http://bit.ly/uku6VN\n\nGood luck,\n\n\nRegards,\n\nAmar\n==\n\nFrom: Salman Zubair Toor <salman.toor at it.uu.se>\n\nTo: Marcelo Martins <btorch-os at zeroaccess.org>\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Problem send HTTP GET request.\nMessage-ID: <43121C3F-AEFB-40C7-B63C-AB7BD13E12DF at it.uu.se>\nContent-Type: text/plain; charset=\"windows-1252\"; Format=\"flowed\";\n??? DelSp=\"yes\"\n\nHi Marcelo,\n\nThanks for the reply.\n\nWith curl I manage to access the file.\n\n# curl -v -k -H \'X-Storage-User: system:root\' -H \'X-Storage-Pass:? \ntestpass\' https://swift.uppmax.se:443/auth/v1.0\n\n# curl -v -k -H \"GET HTTP/1.1\" -H \'X-Auth-Token:? \nAUTH_tk63e5a2291f9b44a1ab5afb9674c05779\' https://swift.uppmax.se/v1/AUTH_286270d2-3d18-46f5-a5dc-7c6c88da1e7d/rootContainer/eventdata.root\n\nfollowing is the correct header\n\n\n> GET /v1/AUTH_286270d2-3d18-46f5-a5dc-7c6c88da1e7d/rootContainer/ \neventdata.root HTTP/1.1\n> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7? \nOpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15\n> Host: swift.uppmax.se\n> Accept: */*\n> X-Auth-Token: AUTH_tk63e5a2291f9b44a1ab5afb9674c05779\n\n\nActually my original task is a bit different. I am working on a? \nproject where we already have S3 plugin available and I want to access? \nSWIFT using S3 plugin,\nThats why I want to use Authentication rather than X-Auth-Token.\n\nWith this solution I can continue but is there anything else you want? \nme to try ?\n\nRegards..\nSalman.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111109/1f859a96/attachment.html>\n\n','<mailman.1.1320879165.6840.openstack-operators@lists.openstack.org>',NULL),('<1321127753.15.1369031967817.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-20 06:39:27',0,'2013-05-20 06:39:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #40','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/40/changes>\n\nChanges:\n\n[Aaron Rosen] Allow admin to delete default security groups\n\n------------------------------------------\n[...truncated 5061 lines...]\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.09\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.07\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.05\n    test_pool_update                                             OK    2.20\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    2.36\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.08\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.01\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.01\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.01\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.00\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.01\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.00\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.00\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.33\n    test_show_quotas_with_admin                                  OK    2.59\n    test_show_quotas_without_admin_forbidden                     OK    0.22\n    test_update_quotas_forbidden                                 OK    0.32\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.32\n    test_quotas_default_values                                   OK    0.31\n    test_show_quotas_with_admin                                  OK    0.31\n    test_show_quotas_without_admin_forbidden                     OK    0.32\n    test_update_quotas_forbidden                                 OK    0.31\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    2.72\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.23\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.24\n    test_quotas_get_tenant_from_request_context                  OK    0.23\n    test_quotas_limit_check                                      OK    0.24\n    test_quotas_limit_check_with_invalid_quota_value             OK    2.61\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    2.64\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.22\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.22\n    test_list_quotas_without_admin_forbidden_returns_403         OK    2.66\n    test_quotas_default_values                                   OK    0.22\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.22\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.22\n    test_quotas_limit_check_with_over_quota                      OK    0.23\n    test_quotas_loaded_bad_returns_404                           OK    0.23\n    test_quotas_loaded_right                                     OK    2.61\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.22\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.22\n    test_update_quotas_without_admin_forbidden_returns_403       OK    2.62\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.33\n    test_KillFilter_deleted_exe                                  OK    0.00\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.44\n    test_health_monitor_delete_with_router_id                    OK    0.37\n    test_health_monitor_delete_without_router_id                 OK    0.32\n    test_health_monitor_update_with_router_id                    OK    0.30\n    test_health_monitor_update_without_router_id                 OK    0.29\n    test_pool_create                                             OK    0.27\n    test_pool_delete_with_router_id                              OK    0.29\n    test_pool_delete_without_router_id                           OK    0.30\n    test_pool_update_with_router_id                              OK    0.27\n    test_pool_update_without_router_id                           OK    0.29\n    test_router_create_no_service_type_id                        OK    3.42\n    test_router_create_with_service_type_id                      OK    0.22\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.23\n    test_vip_create                                              OK    0.27\n    test_vip_delete_with_router_id                               OK    0.30\n    test_vip_delete_without_router_id                            OK    0.31\n    test_vip_update_with_router_id                               OK    0.28\n    test_vip_update_without_router_id                            OK    0.30\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.45\n    test_security_group_rules_for_devices_ipv4_ingress           OK    2.90\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.52\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.43\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.52\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.45\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.46\n    test_security_group_rules_for_devices_ipv4_source_group      Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.HMEzyCqqqH\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/40\n[SCP] Copying console log.\n\n\n','<1145803392.10.1368945434292.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<132117311.45.1373177745008.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-07 06:15:44',0,'2013-07-07 06:15:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #279','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/279/>\n\n------------------------------------------\n[...truncated 13216 lines...]\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nsmoke create: /opt/stack/new/tempest/.tox/smoke\nsmoke inst: /opt/stack/new/tempest/.tox/dist/tempest-0.1.zip\nsmoke runtests: commands[0] | nosetests --logging-format %(asctime)-15s %(message)s --with-xunit -sv --attr=type=smoke --xunit-file=nosetests-smoke.xml tempest\nWARNING:test command found but not installed in testenv\n  cmd: /usr/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/smoke\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... ERROR\nCREATE, GET, DELETE Volume ... ERROR\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nVolume is attached and detached successfully from an instance ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\n\n======================================================================\nERROR: CREATE, GET, DELETE Volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/test_volumes_get.py\", line 68, in test_volume_create_get_delete\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 257, in wait_for_resource_deletion\n    if self.is_resource_deleted(id):\n  File \"/opt/stack/new/tempest/tempest/services/nova/json/volumes_extensions_client.py\", line 97, in is_resource_deleted\n    self.get_volume(id)\n  File \"/opt/stack/new/tempest/tempest/services/nova/json/volumes_extensions_client.py\", line 48, in get_volume\n    resp, body = self.get(url)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 166, in get\n    return self.request(\'GET\', url, headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 244, in request\n    raise exceptions.ComputeFault(message)\nComputeFault: Got compute fault\nDetails: Got compute fault\nDetails: The server has either erred or is incapable of performing the requested operation.\n-------------------- >> begin captured logging << --------------------\n2013-07-07 06:13:49,380 Request URL: http://127.0.0.1:8774/v2/fc9c26c6e23f4222abd1015f6f537e28/os-volumes/80c400ce-8e64-401e-9bc6-c2916760ffb4\n2013-07-07 06:13:49,380 Request Body: None\n2013-07-07 06:13:49,380 Response Headers: {\'date\': \'Sun, 07 Jul 2013 06:13:49 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-8c7e5add-2669-45b9-9d65-7af6323637f3\'}\n2013-07-07 06:13:49,380 Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: CREATE, GET, DELETE Volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/test_volumes_get.py\", line 68, in test_volume_create_get_delete\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 257, in wait_for_resource_deletion\n    if self.is_resource_deleted(id):\n  File \"/opt/stack/new/tempest/tempest/services/nova/xml/volumes_extensions_client.py\", line 143, in is_resource_deleted\n    self.get_volume(id)\n  File \"/opt/stack/new/tempest/tempest/services/nova/xml/volumes_extensions_client.py\", line 86, in get_volume\n    resp, body = self.get(url, self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 166, in get\n    return self.request(\'GET\', url, headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 244, in request\n    raise exceptions.ComputeFault(message)\nUnboundLocalError: local variable \'message\' referenced before assignment\n-------------------- >> begin captured logging << --------------------\n2013-07-07 06:13:59,493 Request URL: http://127.0.0.1:8774/v2/f1da8dbe80924a1c81e5197f7143b543/os-volumes/dd9aec28-2578-465d-95a5-404691d81efc\n2013-07-07 06:13:59,494 Request Body: None\n2013-07-07 06:13:59,494 Response Headers: {\'date\': \'Sun, 07 Jul 2013 06:13:59 GMT\', \'status\': \'500\', \'content-length\': \'192\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-325da797-c607-4df3-8a6e-8b81ee0e14d7\'}\n2013-07-07 06:13:59,494 Response Body: {\'message\': \'The server has either erred or is incapable of performing the requested operation.\', \'code\': \'500\'}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 46 tests in 208.610s\n\nFAILED (SKIP=8, errors=2)\nERROR: InvocationError: \'/usr/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit -sv --attr=type=smoke --xunit-file=nosetests-smoke.xml tempest\'\n___________________________________ summary ____________________________________\nERROR:   smoke: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/rabbitmq/rabbit at devstack-1373170939-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/rabbitmq/rabbit at devstack-1373170939.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/screen-swift.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/279/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<274311972.42.1373091216598.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1321334472.43394200.1377646035108.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 16:27:15',-25200,'2013-08-27 23:27:15',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update\n 2013-08-27','Greetings stackers!\n\nWe are deep in the freeze ... so here\'s what people are working on in the VMwareAPI sub-team and here\'s the reviews in order from most ready on top to least ready on the bottom. Some of these are *very* ready with 8 +1 reviews... others need some attention and revision. Let\'s try and get no more than a day between when a review has a negative vote and a revision. The merge freeze for blueprints is September 5th, so please keep the pressure on.\n\nNeeds one more core review/approval:\n* NEW, https://review.openstack.org/#/c/40105/ ,\'VMware: use VM uuid for volume attach and detach\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,1, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/42619/ ,\'fix broken WSDL logic\'\n    https://bugs.launchpad.net/nova/+bug/1171215\n    core votes,1, non-core votes,1, down votes, 0\n\nReady for core reviewer:\n* NEW, https://review.openstack.org/#/c/40245/ ,\'Nova support for vmware cinder driver\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,3, down votes, 0\n* NEW, https://review.openstack.org/#/c/37819/ ,\'VMware image clone strategy settings and overrides\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/30282/ ,\'Multiple Clusters using single compute service\'\n    https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service\n    core votes,0, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/33100/ ,\'Fixes host stats for VMWareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1190515\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/30628/ ,\'Fix VCDriver to pick the datastore that has capacity\'\n    https://bugs.launchpad.net/nova/+bug/1171930\n    core votes,0, non-core votes,8, down votes, 0\n* NEW, https://review.openstack.org/#/c/40029/ ,\'VMware: Config Drive Support\'\n    https://bugs.launchpad.net/nova/+bug/1206584\n    core votes,0, non-core votes,5, down votes, 0\n* NEW, https://review.openstack.org/#/c/40298/ ,\'Fix snapshot in VMwareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1184807\n    core votes,0, non-core votes,6, down votes, 0\n\nNeeds VMware API expert review:\n* NEW, https://review.openstack.org/#/c/43268/ ,\'VMware: enable VNC access without user having to enter password\'\n    https://bugs.launchpad.net/nova/+bug/1215352\n    core votes,0, non-core votes,4, down votes, 0\n* NEW, https://review.openstack.org/#/c/36882/ ,\'Fix VMware fakes\'\n    https://bugs.launchpad.net/nova/+bug/1200482\n    core votes,0, non-core votes,3, down votes, 0\n* NEW, https://review.openstack.org/#/c/41387/ ,\'VMware: Nova boot from cinder volume\'\n    https://blueprints.launchpad.net/nova/+spec/vmware-nova-cinder-support\n    core votes,0, non-core votes,3, down votes, 0\n* NEW, https://review.openstack.org/#/c/35633/ ,\'Enhance the vCenter driver to support FC volume attach\'\n    https://blueprints.launchpad.net/nova/+spec/fc-support-for-vcenter-driver\n    core votes,0, non-core votes,1, down votes, 0\n* NEW, https://review.openstack.org/#/c/41657/ ,\'Fix VMwareVCDriver to support multi-datastore\'\n    https://bugs.launchpad.net/nova/+bug/1104994\n    core votes,0, non-core votes,3, down votes, 0\n* NEW, https://review.openstack.org/#/c/43721/ ,\'VMware: handle exceptions from RetrievePropertiesEx correctly\'\n    https://bugs.launchpad.net/nova/+bug/1216961\n    core votes,0, non-core votes,3, down votes, 0\n* NEW, https://review.openstack.org/#/c/43621/ ,\'VMware: Handle case when there are no hosts in cluster\'\n    https://bugs.launchpad.net/nova/+bug/1197041\n    core votes,0, non-core votes,2, down votes, 0\n\nNeeds discussion/work (has -1):\n* NEW, https://review.openstack.org/#/c/37659/ ,\'Enhance VMware instance disk usage\'\n    https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage\n    core votes,0, non-core votes,1, down votes, -1\n* NEW, https://review.openstack.org/#/c/42024/ ,\'VMWare: Disabling linked clone doesn\'t cache images\'\n    https://bugs.launchpad.net/nova/+bug/1207064\n    core votes,0, non-core votes,1, down votes, -3\n* NEW, https://review.openstack.org/#/c/43582/ ,\'Fixes host stats for VMWareVCDriver\'\n    https://bugs.launchpad.net/nova/+bug/1190515\n    core votes,0, non-core votes,0, down votes, -1\n* NEW, https://review.openstack.org/#/c/34903/ ,\'Deploy vCenter templates\'\n    https://blueprints.launchpad.net/nova/+spec/deploy-vcenter-templates-from-vmware-nova-driver\n    core votes,0, non-core votes,2, down votes, -2\n* NEW, https://review.openstack.org/#/c/33504/ ,\'VMware: nova-compute crashes if VC not available\'\n    https://bugs.launchpad.net/nova/+bug/1192016\n    core votes,0, non-core votes,2, down votes, -1\n* NEW, https://review.openstack.org/#/c/43665/ ,\'VMware: Validate the returned object data prior to accessing\'\n    https://bugs.launchpad.net/nova/+bug/1215958\n    core votes,0, non-core votes,1, down votes, -1\n* NEW, https://review.openstack.org/#/c/43641/ ,\'VMware: Fix ensure_vlan_bridge to work properly with existing DVS\'\n    https://bugs.launchpad.net/nova/+bug/1194018\n    core votes,0, non-core votes,1, down votes, -2\n \n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n* If anything is missing, add \'hartsocks\' as a reviewer to the patch so I can examine it.\n* We hang out in #openstack-vmware if you need to chat.\n\nHappy stacking!\n\n# Shawn Hartsock\n\n\n','<986753153.43387955.1377645628480.JavaMail.root@vmware.com>',NULL),('<1321595897.17380969.1412579357312.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-06 03:09:17',-14400,'2014-10-06 07:09:17',NULL,'[Openstack-operators] Request for feedback on DHCP IP usage','Hi operators, \n\nI wanted to ask for feedback on a design issue regarding DHCP agent and IP per\nagent. \n\nSo a short introduction first - I want to propose a spec to have a distributed\nDHCP agent that can run directly on the compute node, and service only the VMs\nrunning locally on it. \nThis will help balance out the DHCP agent accross the cloud and each node will\nonly get the information it requires (no more MB size messages which get the\nqueue stuck). \nIt will also limit the scope of failure of the DHCP agent and/or service to\nthat compute node alone. \n\nNow, regarding the IP consumption there are two possible alternatives: \n1. Use single IP per serviced subnet for all the servers. (similar to DVR) \n2. Use IP per server per subnet per host where VMs are serviced. \n\nSo in a theoretical cloud with 100 running VMs for 10 subnets and 10 compute\nnodes, per subnet the 1st approach will take only 1 IP while the second will\ntake a minimum of 1 IP and a maximum of 10 (limited by amount of compute nodes).\n\nNow, I know the 1st solution seems very appealing but thinking of it further\nreveals very serious limitations: \n* No HA for DHCP agents is possible (more prone to certain race conditions). \n* DHCP IP can\'t be reached from outside the cloud. \n* You will just see a single port per subnet in Neutron, without granularity of\nthe host binding (but perhaps it\'s not that bad). \n* This solution will be tied initially only to OVS mechanism driver, each other\ndriver or 3rd party plugin will have to support it individually in some way. \n\nSo basically my question is - which solution would you prefer as a cloud op? \n\nIs it that bad to consume more than 1 IP, given that we\'re talking about private\nisolated networks? \n\nRegards,\nMike\n\n\n','<1170980928.17366248.1412578475143.JavaMail.zimbra@redhat.com>',NULL),('<1321746560.80.1363932283363.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-22 06:04:43',0,'2013-03-22 06:04:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #172','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/172/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson6661562613939940353.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.HNsJ0yJxhq\n+ TMPDIR=/tmp/tmp.HNsJ0yJxhq\n+ trap \'rm -rf /tmp/tmp.HNsJ0yJxhq\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.13 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.37    RoleAPITests.test_get_default_role\n    0.30    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.790s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.HNsJ0yJxhq\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/172\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/172/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/172/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1392056336.64.1363845882434.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1321913563.329281.1414186986867.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-24 21:43:06',0,'2014-10-24 21:43:06',NULL,'[Openstack] [openstack-dev] [Heat] Stack stuck in\n DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE','I\'ve got some additional info for y\'all on this. ?The problem is in heat.engine.parser.Stack.delete with this statement:\nuser_creds = db_api.user_creds_get(self.user_creds_id)\nIn my case, that call is throwing an exception that\'s not getting caught or logged. ?The exact exception is:\nERROR Incorrect paddingTraceback (most recent call last):? File \"/usr/lib/python2.6/site-packages/heat/engine/parser.py\", line 670, in delete? ? user_creds = db_api.user_creds_get(self.user_creds_id)? File \"/usr/lib/python2.6/site-packages/heat/db/api.py\", line 170, in user_creds_get? ? return IMPL.user_creds_get(context_id)? File \"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py\", line 468, in user_creds_get? ? result[\'password\'] = _decrypt(result[\'password\'], db_result.decrypt_method)? File \"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py\", line 174, in _decrypt? ? value = decryptor(enc_value)? File \"/usr/lib/python2.6/site-packages/heat/common/crypt.py\", line 48, in oslo_decrypt_v1? ? auth_info, b64decode=True)? File \"/usr/lib/python2.6/site-packages/heat/openstack/common/crypto/utils.py\", line 158, in decrypt? ? msg = base64.b64decode(msg)? File \"/usr/lib64/python2.6/base64.py\", line 76, in b64decode? ? raise TypeError(msg)TypeError: Incorrect padding\nDoes this ring any bells? I checked the user_creds table and it looks okay as far as I can tell. Do I have a mismatch between how the value is encoded vs how it\'s being decoded?\nKen      From: Zane Bitter <zbitter at redhat.com>\n To: Ken Thomas <krt at yahoo-inc.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n Sent: Wednesday, October 22, 2014 6:10 AM\n Subject: Re: [openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE\n   \nMoving this to the openstack@ list...\n\nOn 21/10/14 18:56, Ken Thomas wrote:\n> Greetings all,\n> I\'m using Heat from Icehouse and I\'m hitting a problem that I\'m hoping y\'all can shed some light on.\n> I have no problems doing stack-create. I can watch the MySQL commands go by and see it happily update the stack table so that it eventually shows up as CREATE_COMPLETE. When I delete the stack, everything seems to be working fine.? I see the MySQL update that sets the stack to DELETE IN PROGRESS as well as the updates that sets my single resource to DELETE_COMPLETE... but I never see the final update to the stack table to set it to DELETE COMPLETE.\n\nI don\'t think you\'re the first person to report this, but afaik we\'ve \nnever been able to track it down. There are a bunch of things that Heat \ndoes after deleting the resources, like cleaning up trusts in Keystone, \nand perhaps one of those is failing. However, *in theory* there\'s no way \nfor the stack to be left in the \"DELETE_IN_PROGRESS\" state without an \nexception being raised that would leave a prominent entry in the logs.\n\n> One very odd thing that I found in the MySQL logs (snippet below), is a query that includes that stack name but with an extra \'*\' character append to it. My stack is named \'xyzzy8\' but notice the \'xzyzzy8*\' in the constraint. That\'s not going to return anything and I\'m wondering if that is what\'s preventing the final stack DELETE_COMPLTE update from happening?\n\nThe stack name that ends with \'*\' is the \"backup stack\", which is used \nto hold out-of-date resources during a stack update. When the stack is \ndeleted, Heat will check for the existence of the backup stack and make \nsure any resources left behind in there (from a failed update) are \ndeleted too. If it doesn\'t exist, that shouldn\'t be a problem.\n\n> There are no errors in the any of the heat logs.\n>\n> Any guidance would be greatly appreciated!\n\nAll I can suggest is to (a) make sure you have the very latest version \nof Icehouse and (b) make sure your logging is turned up to 11, then try \nagain.\n\nSince you seem very proficient at debugging, if that doesn\'t work you \ncould also try adding extra logging into the method \nheat.engine.parser.Stack.delete to try to figure out how far it is getting.\n\nFeel free to raise a bug in Launchpad and attach any logs that might \nhelp us figure out what is happening.\n\ncheers,\nZane.\n\n\n\n>\n> Ken\n> SELECT stack.status_reason AS stack_status_reason, stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action AS stack_action, stack.status AS stack_status, stack.id AS stack_id, stack.name AS stack_name, stack.raw_template_id AS stack_raw_template_id, stack.username AS stack_username, stack.tenant AS stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback AS stack_disable_rollback, stack.stack_user_project_id AS stack_stack_user_project_id, stack.updated_at AS stack_updated_atFROM stackWHERE stack.deleted_at IS NULL AND (stack.tenant = \'c6c488223aae4e97bf56dda8cef36b3b\' OR stack.stack_user_project_id = \'c6c488223aae4e97bf56dda8cef36b3b\') AND stack.name = \'xyzzy8*\' AND stack.owner_id = \'9a3e56d7-0c10-4c1c-8c54-0e5580cee121\'\n\n\n\n  \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141024/5f2c96fb/attachment.html>\n\n','<5447ACB4.4080001@redhat.com>',NULL),('<1322173901.8.1368944085271.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-19 06:14:45',0,'2013-05-19 06:14:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #39','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/39/>\n\n------------------------------------------\n[...truncated 1157 lines...]\n    test_validate_with_additional_properties_allowed             OK    0.00\nTestStoreImage\n    test_image_delayed_delete                                    OK    0.00\n    test_image_delete                                            OK    0.00\n    test_image_get_data                                          OK    0.00\n    test_image_set_data                                          OK    0.00\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 192, in test_bouncing\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.39 secs:\n    26.38    TestScrubber.test_scrubber_app\n    20.83    TestScrubber.test_delayed_delete\n    14.88    TestGlanceControl.test_reload\n    14.74    TestRootApi.test_version_configurations\n    14.57    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1102 tests in 612.720s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.39\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.31\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.sSHuYoYE0O\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/39\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/39/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1322220835.0.1379139084201.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-14 06:11:24',0,'2013-09-14 06:11:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-grizzly #19','See <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 31 lines...]\n+ TMPDIR=/tmp/tmp.iITtntc6uk\n+ trap \'rm -rf /tmp/tmp.iITtntc6uk\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' nova == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.19\n+ tox -epy26\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires>\npy26 inst: <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.19.zip>\npy26 runtests: commands[0] | python tools/patch_tox_venv.py\npy26 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.iITtntc6uk/tmpGX_If5\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.iITtntc6uk/tmpEIYNwj\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.iITtntc6uk/tmpxrv7pj\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.iITtntc6uk/tmpmO4jSQ\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\ntags: worker-2\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group dutaid\n0.63905s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\nCreate Security Group twrp\n0.53530s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress dutaid\n0.135309s None GET /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64]  text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 582, in test_authorize_revoke_security_group_foreign_group\n    group.authorize(src_group=other_group)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group uqcsciq\n0.83409s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress uqcsciq\n0.93311s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 419, in test_authorize_revoke_security_group_cidr\n    group.authorize(\'tcp\', 80, 81, \'0.0.0.0/0\')\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group eaeptqds\n0.80065s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress eaeptqds\n0.92480s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.11.1.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 521, in test_authorize_revoke_security_group_cidr_v6\n    group.authorize(\'tcp\', 80, 81, \'::/0\')\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11310 tests in 414.147s\nFAILED (id=0, failures=5, skips=13)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.19\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.11\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nunittest2==0.5.1\nwarlock==1.0.1\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py26/bin/subunit-1to2\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.iITtntc6uk\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly/centos6-11/19\n[SCP] Copying console log.\n\n\n','<768528064.61.1379052824606.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1322627021.10764393.1349871263615.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 08:14:23',-14400,'2012-10-10 12:14:23',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','\nHi Joonwon Lee,\n\n> Unfortunately, we could not attend the Design Summit. We also need\n> some time\n> before opening our source codes, mostly for our internal process. We\n> will try to shorten this time.\n\nIt\'s unfortunate you guys won\'t be at the summit, as it would have\nbeen great to discuss in that forum.\n\nBut that said, the quicker you can push the code through your internal\nprocess, the better.\n\n\n> Now we\'re preparing the overview of our project and other\n> documentation.\n> If you have any questions, feel free to ask them at any time.\n\nA few immediate questions that spring to mind:\n\n1. Are you re-using any of the ceilometer[1] infrastructure for\n   your metrics collection pipeline?\n\n2. What technology is the metrics store based on, at a high level?\n   (e.g. RDBMS accessed via sqlalchemy, noSQL store such as MongoDB,\n    etc.)\n\n3. How are you performing datapoint aggregation? (e.g. eagerly on\n   metric ingestion, versus lazily on get)\n\nCheers,\nEoghan\n\n[1] http://ceilometer.readthedocs.org/en/latest/architecture.html\n\n\n> Here are answers of June Yi for Steven Hardy\'s questions below.\n> > - Is the metric collection secure/authenticated?\n> > - Are metrics collected from the hypervisors or in-instance?\n> > - Can service monitoring (in instance) metrics be collected?\n> > - Is the API authenticated (ie via keystone ec2 credentials?)\n> \n> All metrics are collected using the API. The API is authenticated via\n> auth\n> module came from Nova.Authenticate WSGI middleware which supports AWS\n> signature v2. It works well with LdapDriver. But we did not tested if\n> it is\n> working with keystone yet.\n> \n> Default metrics (i.e. CPUUtilization, disk IO, network IO) are\n> collected\n> from hypervisors. Custom metrics can be collected from in-instance or\n> any other source.\n> \n> Regards,\n> --\n> Joonwon Lee, principal software engineer, Samsung SDS\n> \n> \n> ------- Original Message -------\n> Sender : Eoghan Glynn<eglynn at redhat.com>\n> Date : 2012-10-10 18:59 (GMT+09:00)\n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> \n> \n> > > > I\'m working for Synaps project that provides AWS CloudWatch\n> > > > compatible API at Samsung SDS.\n> > > > Currently, we have plan to open the project to the community.\n> > > > \n> > > > Here I introduce Synaps project:\n> > > > http://wiki.openstack.org/Synaps\n> > > \n> > > Details are a bit scarce but at first glance there seem to be an\n> > > overlap\n> > > with the CloudWatch work in the Heat project ?\n> > \n> > There certainly seems to be from the description, but pretty hard\n> > to\n> > evaluate until we see some code ;)\n> \n> Yes, I would second that.\n> \n> Once the code is out the open, the community will be much better\n> placed\n> to judge which approach will make sense to concentrate efforts on.\n> \n> June Yi - are you planning on attending the design summit?\n> \n> Cheers,\n> Eoghan\n> \n> \n> > > Any chance the two groups could meet at the Design Summit next\n> > > week\n> > > and\n> > > make sure we don\'t duplicate effort here ?\n> > > \n> > > Angus Saskeld has a session on CloudWatch in the Incubation room:\n> > > http://openstacksummitfall2012.sched.org/event/60b0bcf1253efcb3dd72dff531d59d26\n> > \n> > Angus Salkeld and Steve Dake will be at the Summit and could\n> > discuss,\n> > also\n> > possible overlap with metric collection in ceilometer (has been\n> > discussed\n> > previously).\n> > \n> > I have several questions which will be make/break for the heat\n> > usage\n> > of\n> > Cloudwatch:\n> > \n> > - Is the metric collection secure/authenticated?\n> > - Are metrics collected from the hypervisors or in-instance?\n> > - Can service monitoring (in instance) metrics be collected?\n> > - Is the API authenticated (ie via keystone ec2 credentials?)\n> > \n> > Many more questions, need to see code and evaluate if we could use\n> > this for\n> > heat or if we continue with our own implementation.\n> > \n> > --\n> > Steve Hardy\n> > Red Hat Engineering, Cloud\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5944471.422151349868713283.JavaMail.weblogic@epv6ml08>',NULL),('<1322677113.2193.4.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-30 10:18:33',-28800,'2011-11-30 18:18:33',NULL,'[Openstack-operators] Improving the experience for new OpenStack\n	users','Hello folks\n\nthere is an important discussion happening on the mailing list and I\nwould like all users to be included in it.\n\nI think we should have a better system for users to find answers to\ntheir questions. The number of users is increasing and newcomers have\ntoo many contact points where to ask questions.\n\nI have the feeling we have room for improvements and your opinion is\nvery much appreciated. The discussion started with this message\nhttps://lists.launchpad.net/openstack/msg05715.html\n\nLeaving aside naming the tools, what would be the most important\nfeatures we should have? Here is my personal list, in no particular\norder:\n\n* good search engine\n* ability to promote question and best answer to FAQ\n* good looking and nice to use\n* custom domain (like ask.openstack.org)\n* layout customizable, to give it the \"openstack.org look\"\n* use Launchpad login\n* possibility to turn question into bug report (nice to have)\n\nLorin Hochstein added\n- Users should be able to \"follow\" a question, (e.g., email\nnotifications per question and/or RSS feed per question).\n- An effective way of filtering out spam (I see lots of spammy content\nin the RSS feed for forums.openstack.org).\n\nThierry added:\n* Tagging\n* Use of a reputation system to encourage participation and get a better\nhandle on authoritative answers\n\nMichael Pittaro added:\n* a method or process for flagging topics which should migrate into\ndocumentation and/or the wiki\n\nanything else you would like to see as a user of OpenStack that has\nquestions? Please focus on features and requirements, we\'ll shop around\nfor tools at later stage. I will collect all feedback at the end of this\nweek and start the selection of software based on it.\n\nThanks,\nstef\n\n--\nOpenStack Community Manager\n\n\n',NULL,NULL),('<1322679018.84129.YahooMailNeo@web161704.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-30 10:50:18',-28800,'2011-11-30 18:50:18',NULL,'[Openstack-operators] swift-recon problem','I am trying out swift-recon but running into problems. Help appreciated :-)!!\n\n?- The standard object server install as per instructions on?http://docs.openstack.org/diablo/openstack-object-storage/admin/content/installing-and-configuring-storage-nodes.html?does not install swift-recon.\n\nSo I did the following:\n\n1. Downloaded swift code from - http://openstack.org/projects/storage/latest-release/\n\n2. sudo cp ~/swift-1.4.3/swift/common/middleware/recon.py /usr/share/pyshared/swift/common/middleware\n3. sudo ln -s /usr/share/pyshared/swift/common/middleware/recon.py?/usr/lib/pymodules/python2.6/swift/common/middleware\n4. Compiled recon.py to generate recon.pyc\n5.?sudo cp swift-recon* /usr/bin\n6.?sudo mkdir /var/cache/swift\n7.?sudo chown swift:swift swift\n8. Followed swift-recon instructions from?http://swift.openstack.org/admin_guide.html\n9. My object-server.conf looks like this:\n===\n[DEFAULT]\nbind_ip = x.x.x.x\nworkers = 2\n\n[pipeline:main]\npipeline = recon object-server\n\n[filter:recon]\nuse = egg:swift#recon\nrecon_cache_path = /var/cache/swift\n\n[app:object-server]\nuse = egg:swift#object\n\n[object-replicator]\n\n[object-updater]\n\n[object-auditor]\n===\n10. I restarted the object server\n11. When I try the curl command I get the following error:\n\n/etc/swift$ curl -i http://localhost:6030/recon/async\ncurl: (7) couldn\'t connect to host\n\n12. Ditto with the cli (the other hosts don\'t have swift-recon so that\'s OK, but the first one does, IP addresses masked):\n\n/etc/swift$ sudo swift-recon -d\n\n===============================================================================\n[2011-11-30 18:47:24] Checking disk usage on 5 hosts...\n-> http://10.x.x.x:6000/recon/diskusage: <urlopen error [Errno 111] ECONNREFUSED>\n-> http://10.x.x.x:6000/recon/diskusage: HTTP Error 400: Bad Request\n-> http://10.x.x.x:6000/recon/diskusage: HTTP Error 400: Bad Request\n-> http://10.x.x.x:6000/recon/diskusage: HTTP Error 400: Bad Request\n-> http://10.x.x.x:6000/recon/diskusage: HTTP Error 400: Bad Request\n-> http://10.x.x.x:6000/recon/diskusage: Error. No drive info available.\nError: No hosts available or returned valid information.\n===============================================================================\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111130/5384b2e4/attachment.html>\n\n',NULL,NULL),('<1322843595.9624.1389426575926.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-11 02:49:35',-18000,'2014-01-11 07:49:35',NULL,'[openstack-dev] [Horizon][Tuskar] Tuskar-UI navigation','Hey all,\n\nI have a question regarding the development of the tuskar-ui navigation.\n\nSo, to give some background: we are currently working off the wireframes that Jaromir Coufal has developed:\n\nhttp://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-03_tripleo-ui_02-resources.pdf\n\nIn these wireframes, you can see a left-hand navigation for Resources (which we have since renamed Nodes).  This\nleft-hand navigation includes sub-navigation for Resources: Overview, Resource Nodes, Unallocated, etc.\n\nIt seems like the \"Horizon way\" to implement this would be to create a \'nodes/\' directory within our dashboard.\nWe would create a tabs.py with a Tab for Overview, Resource Nodes, Unallocated, etc, and views.py would contain\na single TabbedTableView populated by our tabs.\n\nHowever, this prevents us from using left-handed navigation.  As a result, our nodes/ directory currently appears\nas such: https://github.com/openstack/tuskar-ui/tree/master/tuskar_ui/infrastructure/nodes\n\n\'overview\', \'resource\', and \'free\' are subdirectories within nodes, and they each define their own panel.py,\nenabling them to appear in the left-handed navigation.\n\nThis leads to the following questions:\n\n* Would our current workaround be acceptable?  Or should we follow Horizon precedent more closely?\n* I understand that a more flexible navigation system is currently under development\n  (https://blueprints.launchpad.net/horizon/+spec/navigation-enhancement) - would it be preferred that\n  we follow Horizon precedent until that navigation system is ready, rather than use our own workarounds?\n\nThanks in advance for any opinions!\n\n\nTzu-Mainn Chen\n\n\n','<1055817470.6670.1389425351893.JavaMail.root@redhat.com>',NULL),('<1322872605.27616.38.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-12-02 16:36:45',-28800,'2011-12-03 00:36:45',NULL,'[Openstack-operators] Improving the experience for new\n OpenStack users','On Wed, 2011-11-30 at 10:18 -0800, Stefano Maffulli wrote:\n> I will collect all feedback at the end of this\n> week and start the selection of software based on it. \n\nHere is the list of requirements we gathered:\n\n* good search engine\n* ability to promote question and best answer to FAQ\n* good looking and nice to use\n* custom domain (like ask.openstack.org)\n* layout customizable, to give it the \"openstack.org look\"\n* use Launchpad login\n* Tagging\n* Use of a reputation system to encourage participation and get a better\nhandle on authoritative answers\n * a method or process for flagging topics which should migrate  into\ndocumentation and/or the wiki. In details: (1) a way of flagging a\nquestion or discussion as a doc bug, a potential enhancement, or even a\nproduct bug. 2) A way of closing the loop, and updating the question to\nindicate the issue is resolved/fixed, and no longer relevant.\n* a way to assign a question to a particular version (or milestone) in\norder to better mark questions (and answers) as obsolete\n\nI would add an extra requirement: that the tool itself must be \'free as\nin freedom\' software.\n\nI\'m assuming we want all of these requirements satisfied. We should\nstart talking about tools now. \n\nWhat tool do you know that allows us to satisfy these requirements? Help\nme build a list of tools to evaluate. I\'m especially interested in\nseeing whether we can improve upon the tools we already have.\n\nthanks\nstef\n\n\n\n','<1322677113.2193.4.camel@mattone-E6420>',NULL),('<132340814.37865849.1403298955839.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 17:15:55',-14400,'2014-06-20 21:15:55',NULL,'[openstack-dev] [TripleO] CI status update for this week','\n\n----- Original Message -----\n> \n> \n> \n> On Jun 20, 2014 1:52 PM, \"Charles Crouch\" < ccrouch at redhat.com > wrote:\n> > \n> > \n> > \n> > ----- Original Message -----\n> > > Not a great week for TripleO CI. We had 3 different failures related to:\n> > > \n> > > Nova [1]: we were using a deprecated config option\n> > > Heat [2]: missing heat data obtained from the Heat CFN API\n> > > Neutron [3]: a broken GRE overlay network setup\n> > \n> > The last two are bugs, but is there anything tripleo can do about avoiding\n> > the first one in the future?:\n> > e.g. reviewing a list of deprecated options and seeing when they will be\n> > removed.\n> ++\n> > \n> > do the integrated projects have a protocol for when an option is deprecated\n> > and at what point it can be removed?\n> > e.g. if I make something deprecated in icehouse I can remove it in juno,\n> > but if I\n> > make something deprecated at the start of juno I can\'t remove it at the end\n> > of juno?\n> \n> That is exactly what we do, deprecate for one release. This was the removal\n> of deprecated icehouse options patch.\n\nOk great, and just to be clear I didn\'t mean to imply Nova did anything wrong here.\nI\'m looking for what tripleo can do to make sure it keeps up.\n\nIs there any easy way to see what options have been deprecated in a release for\nthe integrated projects?\nI guess a list would only need to be pulled together once at the end of each release.\n\n\n> > \n> > > \n> > > The TripleO check jobs look to be running stable again today so if your\n> > > patch had failures from earlier this week then recheck away (perhaps\n> > > referencing one of these bugs if appropriate). The queue is fairly empty\n> > > right now...\n> > > \n> > > Thanks for all the help in tracking these down and getting things fixed.\n> > > \n> > > [1] https://bugs.launchpad.net/tripleo/+bug/1292105\n> > \n> > I think [1] was meant to be\n> > https://bugs.launchpad.net/tripleo/+bug/1330735\n> > \n> > > [2] https://bugs.launchpad.net/heat/+bug/1331720\n> > > [3] https://bugs.launchpad.net/tripleo/+bug/1292105\n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHXdxOdgWrhtoNGXcjApArARC62kP5_Mr-yNgFGAVSwY4+2dvQ@mail.gmail.com>',NULL),('<1323457836.40.1385964833872.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-02 06:13:53',0,'2013-12-02 06:13:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #68','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/68/>\n\n------------------------------------------\n[...truncated 1190 lines...]\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_ssl.TestSSL.test_get_head_simple_post\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_ssl.py\",> line 135, in test_get_head_simple_post\n    response, content = https.request(path, \'GET\')\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1044, in connect\n    raise SSLHandshakeError(e)\nSSLHandshakeError: [Errno 1] _ssl.c:492: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.19 secs:\n    26.46    TestScrubber.test_scrubber_app\n    20.68    TestScrubber.test_delayed_delete\n    14.85    TestGlanceControl.test_reload\n    14.69    TestRootApi.test_version_configurations\n    14.52    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 637.742s\n\nFAILED (SKIP=42, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.19.0\ncffi==0.8.1\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.68\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.3.0\nkombu==3.0.6\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\ntesttools==0.9.34\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.wTexIuEU49\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/68/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-1/68\n[SCP] Copying console log.\n\n\n','<799964513.38.1385878189691.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1323704824.18.1387608158155.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-21 06:42:38',0,'2013-12-21 06:42:38',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-havana #11','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/11/>\n\n\n\n','<1413562665.16.1387435482506.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<13252825.10059544.1389183844600.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 07:24:04',-18000,'2014-01-08 12:24:04',NULL,'[openstack-dev] [neutron] Implement NAPT in neutron\n (https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api)','Hi Dong, \n\nCan you please clarify this blueprint? Currently in Neutron, If an instance has a floating IP, then that will be used for both inbound and outbound traffic. If an instance does not have a floating IP, it can make connections out using the gateway IP (SNAT using PAT/NAT Overload). Does the idea in this blueprint is to implement PAT on both directions using only the gateway IP? Also, did you see this one [1]? \n\nThanks, \nNir \n\n[1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/82c10820/attachment.html>\n\n','<521915878.10052908.1389183266057.JavaMail.root@redhat.com>',NULL),('<1325794582.637110616@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-05 15:16:22',-18000,'2012-01-05 20:16:22',NULL,'[OpenStack Foundation] OpenStack Foundation','As Jim mentioned, I\'m going to focus on establishing the foundation this year and am really excited to be able to dedicate the time and attention it deserves, alongside Jonathan, Stef, and many others.  I\'ve found myself spread a bit too thin the past few months, as I\'m sure we all have in the crazy whirlwind of the OpenStack universe. \n\nTo kick things off I\'ve created a Foundation page on the wiki and published a \"Foundation Mission\" draft for comment as well a a rough timeline for the next couple of months:  http://wiki.openstack.org/Governance/Foundation\n\nThe first thing you\'ll notice is that I tried to keep it simple and stay out of the questions of HOW the foundation will achieve the mission, because I think it\'s good to start with an idea of the purpose before debating the many ways in which a foundation could be structured to achieve it (as several people pointed out on the list).  So much of the HOW is too be discussed, debated, and ultimately determined, but if you look at the timeline you\'ll see that in about a month our goal is t have a draft structure to review with everyone.  I\'m hopeful that we can rally around the Mission between now and then and get it finalized.\n\nJonathan and I will host a webinar in the next week or so as an additional method of gathering feedback.  We are also thinking an in person meeting in February in Santa Clara might be helpful, and can add other forums.  And of course we\'ll have lots of time dedicated during the Conference in April, details of which are coming together so stay tuned for an update on that from Lauren & Stef very soon.\n\n@sparkycollier\nCell:  512-791-0356\n\n\n\n-----Original Message-----\nFrom: \"Jim Curry\" <jim.curry at rackspace.com>\nSent: Thursday, January 5, 2012 1:42pm\nTo: \"openstack at lists.launchpad.net\" <openstack at lists.launchpad.net>, \"foundation at lists.openstack.org\" <foundation at lists.openstack.org>\nSubject: [OpenStack Foundation] OpenStack Foundation\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\nTeam,\n\nFirst, an apology.  It has been 3 months since we announced our intention to move OpenStack into a foundation in 2012.  Since that time, we have done a poor job of updating you on the status of our efforts and involving you in the process.  Jan,  Cole, Ryan and others are all more than justified in asking for better communication.  We are going to improve our efforts starting today and will continue to actively communicate with you throughout the formation of the foundation.  Responsibility and accountability for this effort at Rackspace rests with me, so I offer my apologies and promise that this will be improved.\n\nSo now for the update.  In reality, there has been a ton of work occurring to build a proposal that can serve as the basis for a constructive community conversation.  I firmly believe that the best way to have a conversation with a group as diverse and large as the OpenStack community is to start with a very defined proposal that everyone can react to ? positively or negatively.  This proposal is not meant to be anything other than a framework to manage the discussion.  No decisions are being made without the involvement of the broad community.  Trying to handle the large number of complex issues over a mailing list without a base framework would be impossible to manage.  It is also unfair to community members who don\'t live on the mailing lists day to day, but do want to review the plans and provide comments.  We are basing this initial proposal on a lot of input received from the community and beyond ? developers, users, companies, other open source projects and foundations, lawyers, specific country experts, etc.  As you might imagine, the diversity of opinion received is large (we are not a shy group!) and pulling that together into a starting point in and of itself is a challenge.   But we are about done with it and will be posting the initial proposal in the next few days.  Looking back on our initial setup of OpenStack, I wish we had had more time to have solicited broader input and completed additional diligence as there are likely decisions that would have been made differently.  In the hopefully long life of the OpenStack foundation, I believe a 3 month investment in setting up the right framework for a discussion is a justified investment.\n\nRackspace has a number of resources dedicated to this effort:\n\n1.  Jonathan Bryce has been 100% focused on this effort since the announcement, and has been actively soliciting feedback from the constituencies I mentioned above.\n2.  Mark Collier has given up his other responsibilities to focus on getting the foundation setup with Jonathan.\n3.  Alice King is leading the legal efforts and actively working with other legal counsel in the community\n\nWe also have numerous other team members devoting a substantial portion of their time to the foundation including our community manager, Stefano Maffulli, and other members of my team.  Not to mention those of you who have generously helped along the way!\n\nI sincerely appreciate the goodwill the community demonstrates towards Rackspace.  We are not perfect, and we absolutely make mistakes along the way.  Its easiest to assume the worst ? that Rackspace has ill intentions or is incompetent in the management of this process.  But the vast majority of you are supportive even if we don\'t always deserve your support.  Many outside this community are eagerly seeking signs of division.  Lets please not give it to them.  I am asking for your trust that we are good to our word, and that we will transition this project from Rackspace to you as soon as possible.  Rackspace wants the foundation to happen as much as any member of this community does.  We committed to you that it will happen in 2012, and it will ? hopefully sooner rather than later.  But much work remains to be done, and we need your active feedback, support, and patience during this process.\n\nI look forward to working with you on this effort in the coming months.\n\nJim Curry\n@jimcurry\n\n\n\n','<CB2B4B47.348CE%jim.curry@rackspace.com>',NULL),('<1325801945.2043.181.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-05 22:19:03',0,'2012-01-05 22:19:03',NULL,'[OpenStack Foundation] OpenStack Foundation','Hi Mark,\n\nOn Thu, 2012-01-05 at 15:16 -0500, mark at openstack.org wrote:\n> As Jim mentioned, I\'m going to focus on establishing the foundation\n> this year and am really excited to be able to dedicate the time and\n> attention it deserves, alongside Jonathan, Stef, and many others.\n> I\'ve found myself spread a bit too thin the past few months, as I\'m\n> sure we all have in the crazy whirlwind of the OpenStack universe. \n> \n> To kick things off I\'ve created a Foundation page on the wiki and\n> published a \"Foundation Mission\" draft for comment\n\nNicely done on the Foundation Mission. It covers a lot of ground\nconcisely. Great start. Really.\n\nAt first glance, one thing that seems missing is \"OpenStack is a\nself-governing meritocracy\". Compare with the GNOME Charter, \"How the\nASF works\" and the Document Foundation Manifesto.\n\nThere\'s lots of ways we could reflect this principle of meritocracy -\ne.g. to highlight that the foundation is not an entity separated from\nits members, but rather its members are the foundation. Members are\nempowered beyond the points you list; they are empowered to\nfundamentally shift the direction of the foundation itself. Influence in\nthe foundation is based solely on what one is doing to drive the project\nforward. etc.\n\nAnother thing I wouldn\'t be too keen on is the overly negative \"defend\nthe trademark\" references. I\'d go for \"determining the appropriate use\nof the trademark\". The trademark is an asset of the foundation that\nneeds to be fairly shared amongst the foundation membership, not some\nprecious jewel to be locked in a basement and jealously guarded.\n\nBut, again ... great start.\n\nIn some ways the mission statement is fundamental to the foundation, but\nin other ways it won\'t nearly have as much impact on the success of the\nfoundation as its structure, governance and culture. For that reason,\nI\'d tend to say \"the mission statement looks fine, let\'s get on to the\nmeaty stuff\".\n\nRAX have a lot to be commended for and will be worthy of high praise\nindeed if this is done right. The feedback below is purely my little bit\nto help make that happen.\n\n>  as well a a rough timeline for the next couple of months:\n> http://wiki.openstack.org/Governance/Foundation\n> \n> The first thing you\'ll notice is that I tried to keep it simple and\n> stay out of the questions of HOW the foundation will achieve the\n> mission, because I think it\'s good to start with an idea of the\n> purpose before debating the many ways in which a foundation could be\n> structured to achieve it (as several people pointed out on the list).\n> So much of the HOW is too be discussed, debated, and ultimately\n> determined, but if you look at the timeline you\'ll see that in about a\n> month our goal is t have a draft structure to review with everyone.\n> I\'m hopeful that we can rally around the Mission between now and then\n> and get it finalized.\n\nHaving to wait another month before any discussion of the structure is\nvery disappointing.\n\nIt sounds like there are \"numerous other\" RAX employees who have the\nprivilege of some insight into the ongoing drafting. That may have been\nintended to convey RAX\'s commitment to establishing the foundation, but\nit comes across to me like there\'s a party going on that the rest of us\naren\'t invited to.\n\nI assume some basic principles for the structure of the foundation have\nbeen settled on in the months since the announcement. I really don\'t see\nwhy those principles can\'t be shared and debated on in advance of the\nfull blown verbiage.\n\n> Jonathan and I will host a webinar in the next week or so as an\n> additional method of gathering feedback.  We are also thinking an in\n> person meeting in February in Santa Clara might be helpful, and can\n> add other forums.\n\nIMHO, the mailing list is the one forum available to us which enables a\ntruly open debate.\n\nI think the emphasis should be on encouraging that debate here on the\nmailing list for all to see, archived for posterity.\n\nThe previous thread here that I contributed to felt a little like\nThierry and I chatting alone in a giant cavern.\n\nThat concerns me for two reasons - (1) the silence of all those\nexcellent RAX OpenStack developers suggests that those folks are either\nafraid to publicly speak their mind on these matters, or they are\nambivalent about them and (2) there are obviously many other discussions\nhappening away from the transparency of this mailing list.\n\n> And of course we\'ll have lots of time dedicated during the Conference\n> in April, details of which are coming together so stay tuned for an\n> update on that from Lauren & Stef very soon.\n\nI look forward to the foundation planning these events openly and\ntransparently :-)\n\nCheers,\nMark.\n\n\n','<1325794582.637110616@emailsrvr.com>',NULL),('<1325845563.2043.210.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-06 10:26:01',0,'2012-01-06 10:26:01',NULL,'[OpenStack Foundation] OpenStack Foundation','Hi Todd,\n\nOn Thu, 2012-01-05 at 18:29 -0500, Todd Willey wrote:\n> On Thu, Jan 5, 2012 at 5:19 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> >\n> > The previous thread here that I contributed to felt a little like\n> > Thierry and I chatting alone in a giant cavern.\n> >\n> > That concerns me for two reasons - (1) the silence of all those\n> > excellent RAX OpenStack developers suggests that those folks are either\n> > afraid to publicly speak their mind on these matters, or they are\n> > ambivalent about them and (2) there are obviously many other discussions\n> > happening away from the transparency of this mailing list.\n> \n> Speaking for myself: I\'m more interested in driving the code base\n> forward than the foundation.\n> \n> The foundation bits are in the hands of trustworthy people that are\n> very approachable.  Knowing I can ask about it at any time, and that\n> it is moving forward without having to constantly bird-dog it makes me\n> happy and able to be productive in other ways.\n\nSo, generally speaking, RAX hackers are regularly talking (in-person, on\nprivate mail, irc, phone?) to the folks working on establishing the\nfoundation and are reassured by what they are hearing back?\n\nI\'m reassured that you\'re reassured (genuinely), but I\'d be more\nreassured if such questions and assurances were happening on this list\nwhere I too could be directly reassured by the assurances given ... if\nyou follow me :-)\n\n> I don\'t think there is going to be any publicly holding back from\n> developers once there are more substantial bits that we have opinions\n> on, and we\'ll register them on the list the same way as everyone else.\n>  Looking at the foundation archives, I\'m not sure how you construed\n> silence on behalf of RAX developers more than anyone else in the first\n> place.  It is very low volume so you have a poor sample to begin with,\n> and a lot of what is there is in fact from Rackspace employees.\n\nOk, cool. I\'m really looking forward to hearing the thoughts of more\ndevelopers on this stuff.\n\nThanks for the perspective Todd.\n\nCheers,\nMark.\n\n\n','<CAARb+tO5QgvxZ0LUxHN7Qn6Qa3N6xD3s4X6XiENd-13o4iCDAQ@mail.gmail.com>',NULL),('<1325845587.2043.211.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-06 10:26:25',0,'2012-01-06 10:26:25',NULL,'[OpenStack Foundation] [Openstack]  OpenStack Foundation','Hi Soren,\n\nOn Fri, 2012-01-06 at 10:44 +0100, Soren Hansen wrote:\n> 2012/1/5 Jim Curry <jim.curry at rackspace.com>:\n\n> > We are basing this initial proposal on a lot of input received from the\n> > community and beyond ? developers, users, companies, other open source\n> > projects and foundations, lawyers, specific country experts, etc.\n> \n> How has this worked? Have these people (who?) been asked a specific set\n> of questions? Can we see them so that we can consider the same\n> questions?  Can we see the feedback itself?\n> \n> If you expect the foundation after it\'s been established to take it into\n> consideration at all, it needs to be disclosed, otherwise the first\n> revision of the bylaws/constitution might go against this feedback\n> entirely, and then it\'s been a waste of time.\n\nWow, that is an awesome point.\n\nIf there is no open, transparent, detailed historical record of the\nrationale for the foundation structure, then the foundation may choose\nto make future structural changes without the benefit of the original\nrationale.\n\nUs hackers are well used to this with code and have all sorts of\ntechniques - e.g. code clarity, code comments, commit messages, detailed\nbug reports, unit tests, mail/irc archives, etc. - to build up a body of\ninformation that is invaluable to future hackers trying to understand\nsubtle decisions made by past hackers.\n\nCheers,\nMark.\n\n\n','<CAPFUtkbMATLfEkppvkUwKjukuO_yZCY_v0dSK35RQevYGRU_Rg@mail.gmail.com>',NULL),('<1325968479.20315985.1373401730253.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 13:28:50',-25200,'2013-07-09 20:28:50',NULL,'[openstack-dev]  [vmware] VMwareAPI sub-team status update','Greetings Stackers!\n\nWe\'re recovering from a long weekend here in the US. Sorry for this getting out late. Here\'s the weekly run-down of the state of affairs for the VMwareAPI portions of nova. We should try and push as many things up to the \"ready for core review\" status as we can by Friday. I decide that something is \"ready for core review\" if I see several +1\'s from people I trust to have reviewed the patch properly.\n\nI\'ll be carving out extra time for myself to conduct code reviews the next couple weeks so I can help people get their code in good enough shape that the core-reviewers will be likely to give their +2 without hesitation. If you have a review you want me to track, give input on, or just include in this list then add me as a reviewer http://i.imgur.com/XLINkt3.png using my username \"hartsocks\" (not my email) and clicking \"Add Reviewer\".\n\nBlueprints targeted for Havana-2:\n* https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage - started but depends on\n** https://blueprints.launchpad.net/nova/+spec/vmware-image-clone-strategy - revising after review\n* https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service - good progress \n\nNeeds one more +2 / Approve button:\n* https://review.openstack.org/#/c/27885/ - Support FlatDHCP network for VMware Hyper.\n\nReady for core-reviewer:\n* https://review.openstack.org/#/c/30628/ - Fix VCDriver to pick the datastore that has capacity\n* https://review.openstack.org/#/c/30822/ - Fix VMwareVCDriver to support multi-datastore\n\nNeeds VMware API expert review (no human reviews):\n* https://review.openstack.org/#/c/30282/ - BP: Multiple Clusters using single compute service **\n* https://review.openstack.org/#/c/32695/ - Inherit base image properties on instance creation\n* https://review.openstack.org/#/c/33238/ - Ehance VMware Hyper instance disk usage.\n* https://review.openstack.org/#/c/33504/ - nova-compute crashes if VC not available.\n* https://review.openstack.org/#/c/33962/ - Add missing tests for db.api.instance_* methods (NO REVIEWS!)\n* https://review.openstack.org/#/c/33100/ - Fixes host stats for VMWareVCDriver *critical*\n\nNeeds help/discussion (has a -1):\n* https://review.openstack.org/#/c/34033/ -  API for shelving\n* https://review.openstack.org/#/c/34189/ - Added check for datastore state before selection ( has a nit-pick comment to clear )\n\nWork/re-work in progress:\n* https://review.openstack.org/#/c/33100/ - Fixes host stats for VMWareVCDriver\n* https://review.openstack.org/#/c/35502/ - VMware image clone strategy settings and defaults. ( several significant reworks to do)\n\nMeeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n\nHappy stacking!\n\n# Shawn Hartsock - VMware\'s Nova Compute driver maintainer guy\n\n\n','<1287190384.16255570.1372866690361.JavaMail.root@vmware.com>',NULL),('<1326129018.5928786@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-09 12:10:18',-18000,'2012-01-09 17:10:18',NULL,'[OpenStack Foundation] OpenStack Foundation','I think that shared resources are a key part of the foundation\'s role, and love the idea of having reference platforms for testing (quality, scale, compatibility are all testing areas I would imagine would benefit).  I\'ll work on weaving that in and also keep it in mind as we pull resource estimates together.  \n\nThanks Soren\n\nMark\n\n-----Original Message-----\nFrom: \"Soren Hansen\" <soren at linux2go.dk>\nSent: Monday, January 9, 2012 5:37am\nTo: mark at openstack.org\nCc: \"Jim Curry\" <jim.curry at rackspace.com>, \"foundation at lists.openstack.org\" <foundation at lists.openstack.org>, \"openstack at lists.launchpad.net\" <openstack at lists.launchpad.net>\nSubject: Re: [OpenStack Foundation] OpenStack Foundation\n\n2012/1/5  <mark at openstack.org>:\n> To kick things off I\'ve created a Foundation page on the wiki and published a \"Foundation Mission\" draft for comment as well a a rough timeline for the next couple of months: ?http://wiki.openstack.org/Governance/Foundation\n\nI\'ve always imagined the foundation would be responsible for ensuring\nthat developers will have access to a set of reference platforms for\ntesting as well as ensuring that we have relatively continuous access\nto means for conducting large-scale testing.\n\nCan you weave that in there somehow?\n\n-- \nSoren Hansen ? ? ? ?| http://linux2go.dk/\nUbuntu Developer ? ?| http://www.ubuntu.com/\nOpenStack Developer | http://www.openstack.org/\n\n\n\n','<CAPFUtkYDKAfKRKytZEL8o22WWTZQhD8TyX1FKrMW8gh9BKvV-g@mail.gmail.com>',NULL),('<1326132812.27.1380953374333.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-05 06:09:34',0,'2013-10-05 06:09:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #35','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/35/>\n\n------------------------------------------\n[...truncated 12951 lines...]\n2013-10-05 06:08:57 + [[ swift3 == \\n\\o\\v\\a ]]\n2013-10-05 06:08:57 + [[ swift3 == \\c\\i\\n\\d\\e\\r ]]\n2013-10-05 06:08:57 + [[ swift3 == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-05 06:08:57 + [[ swift3 == \\g\\l\\a\\n\\c\\e ]]\n2013-10-05 06:08:57 + [[ swift3 == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-05 06:08:57 + [[ swift3 == \\s\\w\\i\\f\\t ]]\n2013-10-05 06:08:57 + [[ swift3 == s-* ]]\n2013-10-05 06:08:57 + return 1\n2013-10-05 06:08:57 + is_service_enabled zeromq\n2013-10-05 06:08:57 + services=zeromq\n2013-10-05 06:08:57 + for service in \'${services}\'\n2013-10-05 06:08:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,zeromq, ]]\n2013-10-05 06:08:57 + [[ zeromq == \\n\\o\\v\\a ]]\n2013-10-05 06:08:57 + [[ zeromq == \\c\\i\\n\\d\\e\\r ]]\n2013-10-05 06:08:57 + [[ zeromq == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-05 06:08:57 + [[ zeromq == \\g\\l\\a\\n\\c\\e ]]\n2013-10-05 06:08:57 + [[ zeromq == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-05 06:08:57 + [[ zeromq == \\s\\w\\i\\f\\t ]]\n2013-10-05 06:08:57 + [[ zeromq == s-* ]]\n2013-10-05 06:08:57 + return 1\n2013-10-05 06:08:57 + is_service_enabled n-api\n2013-10-05 06:08:57 + services=n-api\n2013-10-05 06:08:57 + for service in \'${services}\'\n2013-10-05 06:08:59 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,n-api, ]]\n+ exec\n2013-10-05 06:08:59 + return 0\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-10-05 06:08:59 + echo_summary \'Starting Nova API\'\n2013-10-05 06:08:59 + [[ -t 3 ]]\n2013-10-05 06:08:59 + echo -e Starting Nova API\n2013-10-05 06:08:59 + start_nova_api\n2013-10-05 06:08:59 + local service_port=8774\n2013-10-05 06:08:59 + is_service_enabled tls-proxy\n2013-10-05 06:08:59 + services=tls-proxy\n2013-10-05 06:08:59 + for service in \'${services}\'\n2013-10-05 06:08:59 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,tls-proxy, ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-10-05 06:08:59 + [[ tls-proxy == s-* ]]\n2013-10-05 06:08:59 + return 1\n2013-10-05 06:08:59 + screen_it n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + SCREEN_NAME=stack\n2013-10-05 06:08:59 + SERVICE_DIR=/opt/stack/new/status\n2013-10-05 06:08:59 Starting Nova API\n2013-10-05 06:08:59 ++ trueorfalse True False\n2013-10-05 06:08:59 ++ local default=True\n2013-10-05 06:08:59 ++ local testval=False\n2013-10-05 06:08:59 ++ [[ -z False ]]\n2013-10-05 06:08:59 ++ [[ 0 no false False FALSE =~ False ]]\n2013-10-05 06:08:59 ++ echo False\n2013-10-05 06:08:59 ++ return\n2013-10-05 06:08:59 + USE_SCREEN=False\n2013-10-05 06:08:59 + is_service_enabled n-api\n2013-10-05 06:08:59 + services=n-api\n2013-10-05 06:08:59 + for service in \'${services}\'\n2013-10-05 06:08:59 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,n-api, ]]\n2013-10-05 06:08:59 + return 0\n2013-10-05 06:08:59 + screen_rc n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + SCREEN_NAME=stack\n2013-10-05 06:08:59 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-05 06:08:59 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-05 06:08:59 + grep n-api /opt/stack/new/devstack/stack-screenrc\n2013-10-05 06:08:59 ++ echo -ne \'\\015\'\n2013-10-05 06:08:59 + NL=$\'\\r\'\n2013-10-05 06:08:59 + echo \'screen -t n-api bash\'\n2013-10-05 06:08:59 + echo \'stuff \"cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\n\"\'\n2013-10-05 06:08:59 + [[ False = \\T\\r\\u\\e ]]\n2013-10-05 06:08:59 + run_process n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + local service=n-api\n2013-10-05 06:08:59 + local \'command=cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + echo 20621\n2013-10-05 06:08:59 + _run_process n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + echo \'Waiting for nova-api to start...\'\n2013-10-05 06:08:59 Waiting for nova-api to start...\n2013-10-05 06:08:59 + wait_for_service 60 http://127.0.0.1:8774\n2013-10-05 06:08:59 + local timeout=60\n2013-10-05 06:08:59 + local url=http://127.0.0.1:8774\n2013-10-05 06:08:59 + timeout 60 sh -c \'while ! http_proxy= https_proxy= curl -s http://127.0.0.1:8774 >/dev/null; do sleep 1; done\'\n2013-10-05 06:08:59 + local service=n-api\n2013-10-05 06:08:59 + local \'command=cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-05 06:08:59 + exec\n2013-10-05 06:08:59 + exec\n2013-10-05 06:08:59 + is_service_enabled tls-proxy\n2013-10-05 06:08:59 + services=tls-proxy\n2013-10-05 06:08:59 + for service in \'${services}\'\n2013-10-05 06:08:59 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,tls-proxy, ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-05 06:08:59 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-10-05 06:08:59 + [[ tls-proxy == s-* ]]\n2013-10-05 06:08:59 + return 1\n2013-10-05 06:08:59 + is_service_enabled q-svc\n2013-10-05 06:08:59 + services=q-svc\n2013-10-05 06:08:59 + for service in \'${services}\'\n2013-10-05 06:08:59 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,q-svc, ]]\n2013-10-05 06:08:59 + return 0\n2013-10-05 06:08:59 + echo_summary \'Starting Quantum\'\n2013-10-05 06:08:59 + [[ -t 3 ]]\n2013-10-05 06:08:59 + echo -e Starting Quantum\n2013-10-05 06:08:59 + start_quantum_service_and_check\n2013-10-05 06:08:59 + local cfg_file\n2013-10-05 06:08:59 + local \'CFG_FILE_OPTIONS=--config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:08:59 + screen_it q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:08:59 + SCREEN_NAME=stack\n2013-10-05 06:08:59 + SERVICE_DIR=/opt/stack/new/status\n2013-10-05 06:08:59 Starting Quantum\n2013-10-05 06:08:59 ++ trueorfalse True False\n2013-10-05 06:08:59 ++ local default=True\n2013-10-05 06:08:59 ++ local testval=False\n2013-10-05 06:08:59 ++ [[ -z False ]]\n2013-10-05 06:09:02 ++ [[ 0 no false False FALSE =~ False ]]\n2013-10-05 06:09:02 ++ echo False\n2013-10-05 06:09:02 ++ return\n2013-10-05 06:09:02 + USE_SCREEN=False\n2013-10-05 06:09:02 + is_service_enabled q-svc\n2013-10-05 06:09:02 + services=q-svc\n2013-10-05 06:09:02 + for service in \'${services}\'\n2013-10-05 06:09:02 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,q-svc, ]]\n2013-10-05 06:09:02 + return 0\n2013-10-05 06:09:02 + screen_rc q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:09:02 + SCREEN_NAME=stack\n2013-10-05 06:09:02 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-05 06:09:02 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-05 06:09:02 + grep q-svc /opt/stack/new/devstack/stack-screenrc\n2013-10-05 06:09:02 ++ echo -ne \'\\015\'\n2013-10-05 06:09:02 + NL=$\'\\r\'\n2013-10-05 06:09:03 + echo \'screen -t q-svc bash\'\n2013-10-05 06:09:03 + echo \'stuff \"cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\n\"\'\n2013-10-05 06:09:03 + [[ False = \\T\\r\\u\\e ]]\n2013-10-05 06:09:03 + run_process q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:09:03 + local service=q-svc\n2013-10-05 06:09:03 + local \'command=cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:09:03 + echo 20795\n2013-10-05 06:09:03 + echo \'Waiting for Quantum to start...\'\n2013-10-05 06:09:03 Waiting for Quantum to start...\n2013-10-05 06:09:03 + _run_process q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:09:03 + timeout 60 sh -c \'while ! http_proxy= wget -q -O- http://10.6.68.217:9696; do sleep 1; done\'\n2013-10-05 06:09:03 + local service=q-svc\n2013-10-05 06:09:03 + local \'command=cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-05 06:09:03 + exec\n2013-10-05 06:09:03 + exec\n2013-10-05 06:09:03 {\"versions\": [{\"status\": \"CURRENT\", \"id\": \"v2.0\", \"links\": [{\"href\": \"http://10.6.68.217:9696/v2.0\", \"rel\": \"self\"}]}]}+ create_quantum_initial_network\n2013-10-05 06:09:03 ++ keystone tenant-list\n2013-10-05 06:09:03 ++ grep \' demo \'\n2013-10-05 06:09:03 ++ get_field 1\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 ++ \'[\' 1 -lt 0 \']\'\n2013-10-05 06:09:03 ++ field=\'$2\'\n2013-10-05 06:09:03 ++ echo \'| 38631e5b8ea645cea0aa3f7a470224af |        demo        |   True  |\'\n2013-10-05 06:09:03 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 + TENANT_ID=38631e5b8ea645cea0aa3f7a470224af\n2013-10-05 06:09:03 + is_baremetal\n2013-10-05 06:09:03 + [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta =~ baremetal ]]\n2013-10-05 06:09:03 + return 1\n2013-10-05 06:09:03 ++ quantum net-create --tenant_id 38631e5b8ea645cea0aa3f7a470224af private\n2013-10-05 06:09:03 ++ grep \' id \'\n2013-10-05 06:09:03 ++ get_field 2\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 ++ \'[\' 2 -lt 0 \']\'\n2013-10-05 06:09:03 ++ field=\'$3\'\n2013-10-05 06:09:03 ++ echo \'| id                        | 911c5c00-4f63-48ab-b257-e884e7b517b3 |\'\n2013-10-05 06:09:03 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 + NET_ID=911c5c00-4f63-48ab-b257-e884e7b517b3\n2013-10-05 06:09:03 ++ quantum subnet-create --tenant_id 38631e5b8ea645cea0aa3f7a470224af --ip_version 4 --gateway 10.1.0.1 911c5c00-4f63-48ab-b257-e884e7b517b3 10.1.0.0/24\n2013-10-05 06:09:03 ++ grep \' id \'\n2013-10-05 06:09:03 ++ get_field 2\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 ++ \'[\' 2 -lt 0 \']\'\n2013-10-05 06:09:03 ++ field=\'$3\'\n2013-10-05 06:09:03 ++ echo \'| id               | 19c5661e-38e7-401d-87dd-55feb8dc9abc       |\'\n2013-10-05 06:09:03 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 + SUBNET_ID=19c5661e-38e7-401d-87dd-55feb8dc9abc\n2013-10-05 06:09:03 + [[ True == \\T\\r\\u\\e ]]\n2013-10-05 06:09:03 + [[ True == \\T\\r\\u\\e ]]\n2013-10-05 06:09:03 ++ quantum router-create --tenant_id 38631e5b8ea645cea0aa3f7a470224af router1\n2013-10-05 06:09:03 ++ grep \' id \'\n2013-10-05 06:09:03 ++ get_field 2\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 ++ \'[\' 2 -lt 0 \']\'\n2013-10-05 06:09:03 ++ field=\'$3\'\n2013-10-05 06:09:03 ++ echo \'| id                    | bbd8baed-3f43-4212-a980-e7a0624c0ed4 |\'\n2013-10-05 06:09:03 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-05 06:09:03 ++ read data\n2013-10-05 06:09:03 + ROUTER_ID=bbd8baed-3f43-4212-a980-e7a0624c0ed4\n2013-10-05 06:09:03 + quantum router-interface-add bbd8baed-3f43-4212-a980-e7a0624c0ed4 19c5661e-38e7-401d-87dd-55feb8dc9abc\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-516592-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-516592.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-516592/35/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<968982870.21.1380866798091.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1326471097.2214.111.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-13 16:11:35',0,'2012-01-13 16:11:35',NULL,'[OpenStack Foundation] Presenting OpenStack Foundation mission\n and roadmap [webinar]','Hey,\n\nOn Tue, 2012-01-10 at 11:00 -0800, Stefano Maffulli wrote:\n> Hello all\n> \n> Jonathan Bryce and Mark Collier will host two webinars to illustrate the\n> draft mission for the future OpenStack Foundation. The draft was\n> published on http://wiki.openstack.org/Governance/Foundation/ and it?s\n> the fist building block of the organisation that was announced in\n> Boston. They will be available to answer questions about the roadmap and\n> deadlines proposed for the project.  We believe a live conversation will\n> complement the online discussion on the foundation mailing list.\n\nThanks for hosting this! It was certainly helpful to hear you guys speak\nabout the foundation work.\n\nI know you\'re hoping to post a recording, transcripts, slides etc. but\nin the meantime I thought I\'d dump my own notes in an etherpad:\n\n  http://etherpad.openstack.org/foundation-webinar-2012-01-13\n\nI\'m not sure the webinar works well as a forum for debate, but that\ndoesn\'t take away from the usefulness of hearing from the folks doing\nthe work on this.\n\nI did mean to throw a couple of things out there to start some debate,\nbut the webinar was wrapping up before I felt there was an appropriate\ntime ... so I\'ll just start a couple of mini-threads on the list.\n\nCheers,\nMark.\n\n\n','<4F0C8ADD.8010102@openstack.org>',NULL),('<1326473726.2214.146.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-13 16:55:25',0,'2012-01-13 16:55:25',NULL,'[OpenStack Foundation] Self-governing meritocracy','Hey,\n\nOne of the things I raised on the previous thread was whether we could\nenshrine the principle of \"OpenStack is a self-governing meritocracy\" on\nthe mission statement.\n\nMaybe the lack of replies on that means that everyone agrees and this is\npart of the consensus Jonathan mentioned. It be good to hear that\nthough :)\n\nRelated to this, I\'ve quoted some the bits from the Apache and GNOME\nFoundations\' blurbs that I really like.\n\nThere are a couple of pieces of language in the discussion about the\nFoundation that I think are very different in tone from the bits I\nquoted and I\'m not sure that\'s intentional, so I thought I\'d mention it.\n\n  - \"business friendly\" - this *is* important and OpenStack *has* done \n    well on this front so far. Each time it was mentioned in the \n    webinar it as accompanied by well articulated reasons why this is \n    important and how to ensure the goal is met.\n\n    However, I\'d be cautious about putting it front and centre too much \n    in the language of the foundation mission as I think it \n    de-emphasises the importance of individuals (affiliated or not) \n    contributing (in the broadest sense) to OpenStack as opposed to\n    the companies contributing.\n\n    Even though many of the individuals contributing are employees of \n    companies investing in OpenStack (as is the case for GNOME and \n    Apache), I think the emphasis in the governance and mission of the \n    foundation should be on individuals.\n\n  - \"the foundation co-ordinates resources\" - the point being made here\n    is important too. This legal entity isn\'t going to employ or \n    closely manage a phalanx of developers etc. to do the work of the\n    project. Nor will it own a bunch of hardware etc. Those \"resources\" \n    will continue to be contributed by companies or individuals \n    investing in the project.\n\n    However, this really makes it sound like the foundation is separate \n    from the individuals (the \"resources\"). The blurbs below talk more \n    about the individuals making up the foundation. We are the \n    foundation. So, the foundation is doing more than co-ordinating. \n    Through its membership, the foundation *is* in fact doing the work\n    of the project.\n\nCheers,\nMark.\n\n  http://foundation.gnome.org/about/charter/\n\n  \"the foundation will provide a forum that is elected by the GNOME \n  community, that is accountable to that community, and that will\n  conduct its affairs in the open.\"\n\n  \"The foundation should not be exclusionary or elitist. Every GNOME \n  contributor, however small his or her contribution, must have the\n  opportunity to participate in determining the direction and actions of\n  the project. \"\n\n  \"This principle has real, concrete meaning for the foundation: All \n  discussions must be publicly viewable, any person must have the\n  opportunity to contribute to the decision-making process, and every\n  GNOME contributor must have the direct ability to influence the\n  decisions which are made. The foundation must be democratic and\n  friendly to those responsible for making GNOME what it is. \"\n\n  \"Participation in the foundation is intended only for those \n  individuals who are making contributions to the GNOME project and the\n  software which makes up GNOME. A corporation, organization or\n  individual should not be granted a place in the foundation unless its\n  presence is justified by the merits of its contribution. Money cannot\n  buy influence in the GNOME project: show us the code (or\n  documentation, or translations, or leadership, or webmastering...). \"\n\n  http://apache.org/foundation/how-it-works.html\n\n  \"When the group felt that the person had \"earned\" the merit to be \n  part of the development community, they granted direct access to the\n  code repository, thus increasing the group and increasing the ability\n  of the group to develop the program, and to maintain and develop it\n  more effectively.\n\n  We call this basic principle \"meritocracy\": literally, government by \n  merit.\n\n  [..] newcomers were seen as volunteers that wanted to help, rather \n  than people that wanted to steal a position.\"\n\n  \"We firmly believe in hats. Your role at the ASF is one assigned to \n  you personally, and is bestowed on you by your peers. It is not tied\n  to your job or current employer or company.\"\n\n  \"Individuals compose the ASF\n\n  All of the ASF including the board, the other officers, the\n  committers, and the members, are participating as individuals. That is\n  one strength of the ASF, affiliations do not cloud the personal\n  contributions.\n\n  Unless they specifically state otherwise, whatever they post on any\n  mailing list is done as themselves. It is the individual\n  point-of-view, wearing their personal hat and not as a mouthpiece for\n  whatever company happens to be signing their paychecks right now, and\n  not even as a director of the ASF.\n\n  All of those ASF people implicitly have multiple hats, especially the\n  Board, the other officers, and the PMC chairs. They sometimes need to\n  talk about a matter of policy, so to avoid appearing to be expressing\n  a personal opinion, they will state that they are talking in their\n  special capacity. However, most of the time this is not necessary,\n  personal opinions work well.\n\n  Some people declare their hats by using a special footer to their\n  email, others enclose their statements in special quotation marks,\n  others use their apache.org email address when otherwise they would\n  use their personal one. This latter method is not reliable, as many\n  people use their apache.org address all of the time.\"\n\n\n\n',NULL,NULL),('<1326473752.2214.147.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-01-13 16:55:51',0,'2012-01-13 16:55:51',NULL,'[OpenStack Foundation] Linux Foundation as an inspiration','Hey,\n\nThis article was re-tweeted by the OpenStack twitter account:\n\n  http://www.itworld.com/cloud-computing/241213/openstack-steps-towards-its-foundation-future\n\n(I\'m guessing that it must be somewhat accurate if it was re-tweeted :-)\n\n  \"Interestingly, Collier said the mission statement of the OpenStack\n  Foundation was influenced by the mission statement of another such\n  organization.\n\n  The Linux Foundation\'s mission was a inspiration for the theme of the\n  mission statement,\" Collier said. Some elements of the Linux\n  Foundation\'s mission statement fit well for the OpenStack Foundation,\n  he said.\"\n\nI\'d see the Linux Foundation as a radically different organization from\nwhat I\'d like to see for the OpenStack foundation e.g.\n\n  - the Linux project is completely independent from the Linux \n    Foundation, the latter is just there to support and promote the \n    former\n\n    the project has a benevolent dictator who decides a release \n    schedule, where the code repositories live, what the policies of \n    the project are etc.\n\n    OpenStack clearly doesn\'t (yet) have such a dictator (benevolent or \n    otherwise) so I had assumed the foundation board would assume\n    ultimate responsibility for the project, but delegate a lot of it to\n    a PPB or technical steering committee or the PTLs\n\n  - individual Linux contributors aren\'t members of the foundation. \n    Membership is split into gold/silver/bronze classes depending on \n    how much you pay\n\nSo, could someone highlight which elements of the Linux foundation wiki\nare a good fit for OpenStack?\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1327258296.4975151.1361990603353.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 13:43:23',-18000,'2013-02-27 18:43:23',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','\n\n----- Original Message -----\n> From: \"Doug Hellmann\" <doug.hellmann at dreamhost.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, February 27, 2013 12:21:14 PM\n> Subject: Re: [openstack-dev] [keystone] re-ordering of schema migrations\n> \n> On Wed, Feb 27, 2013 at 9:59 AM, Dan Prince <dprince at redhat.com>\n> wrote:\n> \n> >\n> >\n> > ----- Original Message -----\n> > > From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n> > > To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development\n> > Mailing List\" <openstack-dev at lists.openstack.org>\n> > > Sent: Wednesday, February 27, 2013 9:09:00 AM\n> > > Subject: Re: [openstack-dev] [keystone] re-ordering of schema\n> > > migrations\n> > >\n> > > This was discussed in #openstack-dev, as I recall.\n> > >\n> > > The goal in these migrations was to support folsom <--> grizzly,\n> > > not\n> > > necessarily supporting intermediate milestones. I\'m not aware of\n> > > anyone\n> > > doing continuous deployments of keystone, if but if migrating\n> > > commit\n> > > to\n> > > commit is the community\'s expectation, I\'m more happy to ensure\n> > > that\n> > > happens moving forward -- I just wasn\'t aware that was a concern\n> > > here.\n> >\n> > We should always support upgrading between the milestones.\n> >\n> > Also, Existing migrations should never be re-ordered.\n> >\n> > One thing you could do is compact the \"released\" (as in part of the\n> > previous stable release) migrations into a single (large) migration\n> > in a\n> > way which doesn\'t break upgrades for previous users.\n> >\n> > So at Folsom keystone had 15 migrations... In order to upgrade to\n> > Grizzly\n> > users would need to be at migration 15 (or greater). New\n> > installations\n> > would automatically run the \'compacted\' migration which initializes\n> > their\n> > schema to version 15 as well so they will be upgraded in a similar\n> > fashion.\n> > New migrations added in the grizzly timeframe should remain in\n> > order and\n> > untouched.\n> >\n> > Make sense?\n> >\n> \n> Yeah. Let\'s not do that, though. Let\'s just add new migrations as\n> necessary. That way each migration is tested, and after it is known\n> to work\n> it is not changed to something different that has to be re-tested.\n\n\nI don\'t think Keystone has reached this point either. At some point though the number or migrations becomes unwieldy and compacting things may make more sense though.\n\n\n> \n> Doug\n> \n> \n> >\n> > Dan\n> >\n> > >\n> > > Thanks for the feedback, and apologies for any inconvenience!\n> > >\n> > >\n> > > -Dolph\n> > >\n> > >\n> > > On Wed, Feb 27, 2013 at 7:43 AM, Mark McLoughlin\n> > > <markmc at redhat.com>\n> > > wrote:\n> > >\n> > > > On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:\n> > > > > Folks,\n> > > > >\n> > > > > When looking into an error encountered on a keystone db sync,\n> > > > > I noticed some apparent strangeness in the way keystone\n> > > > > schema\n> > > > > migrations have been managed.\n> > > > >\n> > > > > Specifically the *rewriting* of schema migration history,\n> > > > > see:\n> > > > >\n> > > > >   https://github.com/openstack/keystone/commit/5bc46d86\n> > > > >\n> > > > > In my (albeit imperfect) understanding of sqlalchemy-migrate,\n> > > > > this\n> > > > > reordering seems to defeat the whole purpose of step-wise\n> > > > > reversible\n> > > > > migration.\n> > > > >\n> > > > > Would it even be possible to migrate a grizzly-2 deployment\n> > > > > to\n> > > > > grizzly-3 with that re-ordering in place?\n> > > > >\n> > > > > Maybe I\'ve missed something here, but I\'d appreciate some\n> > > > > clarity\n> > > > > on what is considered community best practice in terms of\n> > > > > changes\n> > > > > to the migration sequence.\n> > > > >\n> > > > > Previously I would have assumed something like ...\n> > > > >\n> > > > > Invariants we maintain:\n> > > > >\n> > > > >  - DB schemas must always be migrate-able across milestone\n> > > > >  releases\n> > > >\n> > > > (snip good stuff)\n> > > >\n> > > > It\'s more than just across milestone releases, we should\n> > > > support\n> > > > upgrading from commit to commit. In Nova, at least, we\'re\n> > > > trying\n> > > > hard to\n> > > > avoid messing up those who are deploying continuously. I\'d\n> > > > expect\n> > > > any\n> > > > nova-core member to reject this patch immediately.\n> > > >\n> > > > What I really don\'t understand is how this concern wasn\'t\n> > > > raised in\n> > > > the\n> > > > review at all:\n> > > >\n> > > >   https://review.openstack.org/19780\n> > > >\n> > > > Cheers,\n> > > > Mark.\n> > > >\n> > > >\n> > > > _______________________________________________\n> > > > OpenStack-dev mailing list\n> > > > OpenStack-dev at lists.openstack.org\n> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CADb+p3ScR5bh0tUvZ3B7jF7s91zw-huz3GisCiJVzs4cRW7ELw@mail.gmail.com>',NULL),('<1327895482.23.1387003523616.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-14 06:45:23',0,'2013-12-14 06:45:23',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-full-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-full-grizzly/5/>\n\n\n\n','<757995640.12.1386918192854.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1327934569.2009473.1422389082191.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 15:04:42',-18000,'2015-01-27 20:04:42',NULL,'[openstack-dev] [Telco][NFV] Meeting reminder - Wednesday 28th @\n 1400 UTC in #openstack-meeting-alt','Hi all,\n\nJust a friendly reminder that this week\'s OpenStack Telco Working Group meeting is tomorrow, Wednesday the 28th, at 1400 UTC in #openstack-meeting-alt. Please add any items you wish to discuss to the agenda at:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nMarc Koderer has kindly stepped up to run the meeting in my absence.\n\nThanks,\n\nSteve\n\n\n','<1926480619.2005394.1422388673903.JavaMail.zimbra@redhat.com>',NULL),('<1327934569.2009473.1422389082191.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-27 15:04:42',-18000,'2015-01-27 20:04:42',NULL,'[Openstack-operators] [Telco][NFV] Meeting reminder - Wednesday\n 28th @ 1400 UTC in #openstack-meeting-alt','Hi all,\n\nJust a friendly reminder that this week\'s OpenStack Telco Working Group meeting is tomorrow, Wednesday the 28th, at 1400 UTC in #openstack-meeting-alt. Please add any items you wish to discuss to the agenda at:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nMarc Koderer has kindly stepped up to run the meeting in my absence.\n\nThanks,\n\nSteve\n\n\n','<1926480619.2005394.1422388673903.JavaMail.zimbra@redhat.com>',NULL),('<1328377205.555723817@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-04 12:40:05',-18000,'2012-02-04 17:40:05',NULL,'[OpenStack Foundation] Foundation Mission Update','Hi everyone,\n\nA few weeks ago we published a draft mission statement for discussion and feedback. We had good responses on the foundation mailing list, during the webinars and in direct discussions with a number of people, including from many of the companies that have demonstrated strong support for OpenStack and others that are getting serious about committing. The number of meeting requests has been a bit overwhelming, but we are making as much time as possible to hear from everyone. This process has taken us past the original timeline, but I think it\'s worth it to build up as much support for OpenStack as possible. \n\nIn general, there was a lot of consensus on the basic mission of the foundation, although there does seem to be a desire to revise the overall OpenStack mission. There was also some input that influences the structure more than the mission, and we\'ll be incorporating that into the next document that presents a high-level draft structure. Here\'s a summary of the major themes we saw on the mission:\n\n* The foundation should work to protect the values of the OpenStack community, such as technical meritocracy\n* Even though this is a very business-friendly project and community, make clear that we value the individuals who are contributing\n* Some specific changes like mentioning testing resources and changing \"compatibility\" to \"interoperability\"\n\nThese changes were all incorporated and are included in the wiki: http://wiki.openstack.org/Governance/Foundation/Mission and you\'ll note that we removed the word \"Draft\", believing we are getting really close on this one and want to turn our attention to the big job of defining the structure. We can certainly continue to tweak the Mission, though.\n\nOne common theme was the desire to go back and adjust the original OpenStack Mission from July 2010.  We hadn\'t considered that a part of the exercise of defining the \"Foundation Mission\", but clearly it\'s on people\'s minds so I suggest we tackle that too as a separate work stream (Note that I removed it from the \"Foundation Mission\" page to keep it separate).  While many said that we should change it, there was not as much consensus about what the changes should be. Some people think it should explicitly be limited to infrastructure services, while others think it should be a broader vision that can be valid and stand the test of time. One approach may be to create a broad-based visionary mission that describes the general purpose of OpenStack and also include a short charter that sets out the specific focus of the community currently which can be reviewed and changed periodically.\n\nNext up, we\'ll post a draft document that summarizes a proposed structure and look to get feedback on that. We\'ll also be holding a meetup Wednesday 2/15 at 4:30 near Cloud Connect. We\'ll publish the full details, including location, shortly on the meetup.  We will update the timeline on the wiki this week as well.  \n\nMark\n@sparkycollier\ncell:  512-791-0356\n\n\n',NULL,NULL),('<1328507922.2515451.1377183703038.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-22 11:01:43',-14400,'2013-08-22 15:01:43',NULL,'[Openstack-stable-maint] Stable grizzly failures','Hi, sorry for delay I\'m looking into it now.\n\nAfter quick try with master pythonkeystone-client I was unable to reproduce it (but just again older than latest stable/grizzly instance).\n\nI\'m going to take that https://bugs.launchpad.net/tempest/+bug/1213912.\n\n----- Original Message -----\n> From: \"Gary Kotton\" <gkotton at vmware.com>\n> To: \"Alan Pevec\" <apevec at gmail.com>, \"Dolph Mathews\" <dolph.mathews at gmail.com>\n> Cc: openstack-stable-maint at lists.openstack.org, \"Pavel Sedl?k\" <psedlak at redhat.com>\n> Sent: Wednesday, August 21, 2013 7:25:55 PM\n> Subject: RE: [Openstack-stable-maint] Stable grizzly failures\n> \n> Thanks.\n> Sorry but I have not found the cycles today to look into any of this\n> \n> > -----Original Message-----\n> > From: Alan Pevec [mailto:apevec at gmail.com]\n> > Sent: Wednesday, August 21, 2013 8:25 PM\n> > To: Dolph Mathews\n> > Cc: openstack-stable-maint at lists.openstack.org; Pavel Sedl?k\n> > Subject: Re: [Openstack-stable-maint] Stable grizzly failures\n> > \n> > 2013/8/21 Dolph Mathews <dolph.mathews at gmail.com>:\n> > > On Wed, Aug 21, 2013 at 7:30 AM, Alan Pevec <apevec at gmail.com> wrote:\n> > >> Adding Pavel who wrote cli.output_parser according to git log.\n> > >> Tempest is using keystoneclient master, but I don\'t see any changes\n> > >> in cli output.\n> > >> Pavel, you can check Tempest logs from the last failure[1] but afaict\n> > >> the complete output from subprocess.check_output is not logged, so\n> > >> I\'m not sure what happened and confused clii parser.\n> > > The latest version of keystoneclient looks like it would still pass\n> > > this test. Here\'s my attempt to reproduce manually:\n> > >   http://pasteraw.com/812w2wwnyhz6nf9b7o0kyzimpepfdo0\n> > > As Alan suggested, knowing what tempest is actually seeing from this\n> > > command is critical to debugging it.\n> > \n> > BTW this was already filed as\n> > https://bugs.launchpad.net/tempest/+bug/1213912\n> > \n> > Cheers,\n> > Alan\n> > \n> > _______________________________________________\n> > Openstack-stable-maint mailing list\n> > Openstack-stable-maint at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> \n\n-- \nPavel Sedl?k <psedlak at redhat.com>\n OpenStack Quality Engineer\n Red Hat Czech / BRQ\n irc: psedlak\n phone: +420532294659 | (82) 62659\n\n\n\n','<D9AD1F0A0B678548BB8FF40C740D17720259940E9C@exch-mbx-122.vmware.com>',NULL),('<1328718774.838418527@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-08 11:32:54',-18000,'2012-02-08 16:32:54',NULL,'[OpenStack Foundation] Foundation Mission Update','\n\nOn Wednesday, February 8, 2012 6:15am, \"Thierry Carrez\" <thierry at openstack.org> said:\n\n> mark at openstack.org wrote:\n>> These changes were all incorporated and are included in the wiki:\n>> http://wiki.openstack.org/Governance/Foundation/Mission and you\'ll note that we\n>> removed the word \"Draft\", believing we are getting really close on this one and\n>> want to turn our attention to the big job of defining the structure. We can\n>> certainly continue to tweak the Mission, though.\n> \n> I think it covers the key areas, and we can safely move to discussing\n> the structure best suited to achieve those goals.\n> \n> Just noticed a typo:\n> \"Responsibilties\" -> \"Responsibilities\"\n> \n>> One common theme was the desire to go back and adjust the original OpenStack\n>> Mission from July 2010.  We hadn\'t considered that a part of the exercise of\n>> defining the \"Foundation Mission\", but clearly it\'s on people\'s minds so I\n>> suggest we tackle that too as a separate work stream (Note that I removed it from\n>> the \"Foundation Mission\" page to keep it separate).  While many said that we\n>> should change it, there was not as much consensus about what the changes should\n>> be. Some people think it should explicitly be limited to infrastructure services,\n>> while others think it should be a broader vision that can be valid and stand the\n>> test of time. One approach may be to create a broad-based visionary mission that\n>> describes the general purpose of OpenStack and also include a short charter that\n>> sets out the specific focus of the community currently which can be reviewed and\n>> changed periodically.\n\n\n> \n> I agree that the re-definition of the \"OpenStack Mission\" (which could\n> also be named \"OpenStack Core software scope\") might have trouble to\n> reach wide consensus, and therefore it might be preferable to wait for\n> the Foundation structure to be set up (including the new technical\n> board) so that we have a formal way to select between competing proposed\n> objectives.\n> \n> Regards,\n\nI would also prefer to wait on tackling a change to the OpenStack Mission, unless there is a really strong interest to work on it now, given the important work of defining the structure we need to focus on at the moment.\n\n\n\n> \n> --\n> Thierry Carrez (ttx)\n> Release Manager, OpenStack\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n','<4F325957.4070802@openstack.org>',NULL),('<1328728308.8069.13.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-08 19:11:47',0,'2012-02-08 19:11:47',NULL,'[OpenStack Foundation] Strawman Foundation Structure','Hey,\n\nSome discussions at FOSDEM prompted me to write up in detail my ideas\nfor the ideal foundation structure:\n\n  http://wiki.openstack.org/StrawmanFoundationStructure\n\nI\'ve just had a productive conversation with Mark and Jonathan about\nthis and I\'m glad to see they welcome the input. I was going to\nsummarize the main differences of opinion we discussed, but I guess that\nmight be an unwelcome pre-emptive disclosure of their ideas.\n\nAnyway, just another perspective to add to the mix.\n\nCheers,\nMark.\n\n\n',NULL,NULL),('<1329048069.7032497.1395680168653.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-24 12:56:08',-14400,'2014-03-24 16:56:08',NULL,'[openstack-dev] [TripleO] test environment requirements','\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Sunday, March 23, 2014 11:18:19 PM\n> Subject: Re: [openstack-dev] [TripleO] test environment requirements\n> \n> On 24 March 2014 14:06, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Robert Collins\'s message of 2014-03-13 02:51:30 -0700:\n> >> So we already have pretty high requirements - its basically a 16G\n> >> workstation as minimum.\n> >>\n> >> Specifically to test the full story:\n> >>  - a seed VM\n> >>  - an undercloud VM (bm deploy infra)\n> >>  - 1 overcloud control VM\n> >>  - 2 overcloud hypervisor VMs\n> >> ====\n> >>    5 VMs with 2+G RAM each.\n> >>\n> >> To test the overcloud alone against the seed we save 1 VM, to skip the\n> >> overcloud we save 3.\n> >>\n> >> However, as HA matures we\'re about to add 4 more VMs: we need a HA\n> >> control plane for both the under and overclouds:\n> >>  - a seed VM\n> >>  - 3 undercloud VMs (HA bm deploy infra)\n> >>  - 3 overcloud control VMs (HA)\n> >>  - 2 overcloud hypervisor VMs\n> >> ====\n> >>    9 VMs with 2+G RAM each == 18GB\n> >>\n> >\n> > If we switch end-user-vm tests to cirros, and use a flavor that is really\n> > really tiny, like 128M RAM, then I think we can downsize the development\n> > environment hypervisors from 2G to 1G. That at least drops us to 16G. If\n> > we can also turn off the seed as soon as the undercloud boots, that\'s\n> > another 2G saved. Finally if we can turn off 1 of the undercloud VMs\n> > and run degraded, that is another 2G saved.\n> \n> We can\'t turn off the seed unless we change the network topology; we\n> need to make sure if we do that that we don\'t invalidate the test\n> structure.\n\nThis should make changing the network topology in the test env\'s easier:\n\n  https://review.openstack.org/#/c/82327/\n\nIf we use something else (besides the seed VM) as the gateway for the baremetal network I think it should work fine right?\n\n> \n> > Small potatoes I know, but it wouldn\'t be complicated to do any of these\n> > and it would also help test real scenarios we want to test (seed going\n> > away, undercloud node going away).\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> I like this.\n> \n> I also like much of the spread of ideas that came up - lets capture\n> them to an etherpad and link that from a blueprint for future selves\n> finding it.\n> \n> In particular I\'d like to make being able to use OpenStack a J series\n> goal, though it doesn\'t help with local dev overheads.\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ2Ng5phcZAnbgp2tcYSP+VSdQNJ5E9zDZpgMtgkDpYAqw@mail.gmail.com>',NULL),('<1329113862.679.28.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-13 06:17:42',0,'2012-02-13 06:17:42',NULL,'[OpenStack Foundation] Foundation Structure Draft','Hi Jonathan,\n\nOn Fri, 2012-02-10 at 15:45 -0600, Jonathan Bryce wrote:\n> Hello Everyone,\n> \n> Now that we\'ve settled on a good baseline of what the mission of the\n> Foundation will be, it\'s time to set down the details of how it will\n> be organized to accomplish that mission.[..]\n> \n> http://wiki.openstack.org/Governance/Foundation/Structure\n\nThanks for posting this. It\'s just awesome to have a detailed draft to\nmull over. There\'s an awful lot to be commended here, not least the very\nobvious intent on Rackspace\'s part to do what it said it was going to\ndo. I see nothing in this but deep concern for OpenStack\'s future\nsuccess.\n\nSo, Kudos to everyone involved!\n\nDefining which companies have made a \"strategic commitment\" to OpenStack\nis really tough. Is it based on the funding provided? The number of\nemployees dedicated? The impact of those employees? How do we take into\naccount the size of the company? How do we value contributions to the\necosystem or the marketing of the project? How do we do all that while\nkeeping the numbers down to 6-8 without appearing to undervalue the\ncontributions of some?\n\nMaking that kind of a value judgement seems more suited to a fair and\nopen vote of the foundation membership, rather than a set of\nhard-and-fast rules. Perhaps we could have an election each year where\nthe foundation membership ranks the contributions of the various company\nmembers to the foundation and, from that, 8 companies are awarded\n\"strategic\" status?\n\nOr to go a step further, we could have all 12 seats on the board be\ndirectly elected but some candidates could explicitly be nominated by\ntheir employer as their official representative. The membership would\nvote for the candidate on the basis of that companies contributions.\nThat way the foundation membership implicitly ranks the contributions of\ncompanies alongside individual member candidates.\n\nAlso, not all highly committed companies will make it into the elite\n\"strategic\" category and gain a board seat. I think that we need to give\na strong voice to those companies and a sponsors advisory board would\nprovide such a forum.\n\nCheers,\nMark.\n\n\n','<FB88B9C9-97EF-45B8-AC68-F9CB1C69499F@openstack.org>',NULL),('<1329175736.14629.43.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-13 15:28:56',-28800,'2012-02-13 23:28:56',NULL,'[Openstack-operators] OpenStack Governance Elections Spring 2012','The time is once again upon us for our OpenStack Governance Elections.\nThe OpenStack community is called to elect the Project Technical Leads\nand two seats of the Project Policy Board. The election committee is\nmade of Stefano Maffulli, Lloyd Dewolf and Dave Nielsen.\n\n\n      * February 16 ? 26 11:59 PST: Nominations open. \n      * February 28 ? March 3 11:59 PST: Online voting open. \n      * March 3 11:59 PST: Voting closed.\n\n\nFinal results will be posted immediately upon election close. \n\nWhat seats are up for election\n\n      * NOVA Project Team Lead (1 Position) \n      * SWIFT Project Team Lead (1 Position) \n      * GLANCE Project Team Lead (1 Position) \n      * HORIZON Project Team Lead (1 Position) \n      * KEYSTONE Project Team Lead (1 Position) \n      * Project Policy Board (2 Open Positions)\n\n\n\nHow to nominate yourself or others as Project Technical Lead\nOnly OpenStack community members who have code in the respective\nOpenStack subproject are eligible to be elected as that subproject?s\nProject Team Lead. Please nominate someone from the developer community\nor yourself at http://etherpad.openstack.org/Spring2012-Nominees under\nthe Nominees heading.  Please provide the name and email address of the\nnominee. The election committee will then confirm with the nominee that\nthey are willing to run for the position.The list of Approved Candidates\nwill be announced with a new blog post on openstack.org/blog when online\nvoting opens (Feb 28). \n\nHow to nominate yourself or others as member of the Project Policy Board\n\nAny registered member of the OpenStack Launchpad group is eligible to\nrun or be nominated for a position on the Project Policy Board. If you\nwant to vote and/or run for a seat you need to register on Launchpad and\nadd yourself to the public OpenStack group on\nhttps://launchpad.net/~openstack. Please nominate someone from the\ncommunity or yourself at\nhttp://etherpad.openstack.org/Spring2012-Nominees under the Nominees\nheading. Please give the name and email address of the nominee. The\nelection committee will then confirm with the nominee that they are\nwilling to run for the position. The list of Approved Candidates will be\nannounced with a new blog post on openstack.org/blog right before the\nelection starts.How to register to vote for PTL\nOnly OpenStack community members who have code in the respective\nOpenStack subproject are eligible to vote for that subproject?s Project\nTeam Lead.  The authoritative list of eligible voters and nominees is\nthe Authors file in each repository. For example, the list of Nova\nauthors is https://github.com/openstack/nova/blob/master/Authors.\nMake sure your name and correct email address is there or you won?t be\nable to vote.\n\n\n\nHow to register to vote for Project Policy Board\n\nAny registered member of the OpenStack Launchpad group is eligible to\nvote for the Project Policy Board. If you want to vote you need to\nregister to Launchpad and add yourself to the public OpenStack group on\nhttps://launchpad.net/~openstack before registering as a voter using the\nform at http://ppbelectionsregistration.openstack.org/. Company\naffiliation is only collected as an interesting statistic; it has no\neffect on the outcome of the election.\n\n\n\nVoting process\n\nLike previous OpenStack Governance Elections, we will use the Condorcet\nInternet Voting Service from Cornell University,\nhttp://www.cs.cornell.edu/andru/civs.html. This tool uses the Condorcet\nmethod of voting which invokes ranking the nominees instead of just\nselecting one choice. More information on this methodology is at\nhttp://www.cs.cornell.edu/w8/~andru/civs/rp.html.\n\nAll registered voters will receive an email with a unique link allowing\nthem to privately vote.\n\nPlease note that the voting system is run using private polls with\nrestricted access to ensure voter authenticity; however all results will\nbe made public once the election ends. Voter anonymity is guaranteed.\nThe result?s ranking will be evaluated using Schulze (also known as\nBeatpath or CSSD) completion rule.\n\nThanks for participating in this essential process. Please remind your\nfriends and colleagues to get involved, register and vote!\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120213/79e5d80a/attachment.html>\n\n',NULL,NULL),('<13291B6F-67B6-4E89-B263-7F6AF2E6D8D3@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 11:43:14',-14400,'2014-09-03 15:43:14',NULL,'[openstack-dev] Treating notifications as a contract','\nOn Sep 3, 2014, at 9:50 AM, Sandy Walsh <sandy.walsh at RACKSPACE.COM> wrote:\n\n> Is there anything slated for the Paris summit around this?\n> \n> I just spent nearly a week parsing Nova notifications and the pain of no schema has overtaken me. \n> \n> We\'re chatting with IBM about CADF and getting down to specifics on their applicability to notifications. Once I get StackTach.v3 into production I\'m keen to get started on revisiting the notification format and olso.messaging support for notifications. \n> \n> Perhaps a hangout for those keenly interested in doing something about this?\n\nJulien did start some work on it a while back, but it was shelved for other more pressing things at the time.\n\nhttps://blueprints.launchpad.net/oslo.messaging/+spec/notification-structured\nhttps://wiki.openstack.org/wiki/Oslo/blueprints/notification-structured\n\nIt would be good to start building up a set of requirements in anticipation of a cross-project or Oslo session at the summit.\n\nDoug\n\n> \n> Thoughts?\n> -S\n> \n> ________________________________________\n> From: Eoghan Glynn [eglynn at redhat.com]\n> Sent: Monday, July 14, 2014 8:53 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [all] Treating notifications as a contract\n> \n>>> So what we need to figure out is how exactly this common structure can be\n>>> accommodated without reverting back to what Sandy called the \"wild west\"\n>>> in another post.\n>> \n>> I got the impression that \"wild west\" is what we\'ve already got\n>> (within the payload)?\n> \n> Yeah, exactly, that was my interpretation too.\n> \n> So basically just to ensure that the lightweight-schema/common-structure\n> notion doesn\'t land us back not too far beyond square one (if there are\n> too many degrees-of-freedom in that declaration of \"a list of dicts with\n> certain required fields\" that you had envisaged in an earlier post).\n> \n>>> For example you could write up a brief wiki walking through how an\n>>> existing widely-consumed notification might look under your vision,\n>>> say compute.instance.start.end. Then post a link back here as an RFC.\n>>> \n>>> Or, possibly better, maybe submit up a strawman spec proposal to one\n>>> of the relevant *-specs repos and invite folks to review in the usual\n>>> way?\n>> \n>> Would oslo-specs (as in messaging) be the right place for that?\n> \n> That\'s a good question.\n> \n> Another approach would be to hone in on the producer-side that\'s\n> currently the heaviest user of notifications, i.e. nova, and propose\n> the strawman to nova-specs given that (a) that\'s where much of the\n> change will be needed, and (b) many of the notification patterns\n> originated in nova and then were subsequently aped by other projects\n> as they were spun up.\n> \n>> My thinking is the right thing to do is bounce around some questions\n>> here (or perhaps in a new thread if this one has gone far enough off\n>> track to have dropped people) and catch up on some loose ends.\n> \n> Absolutely!\n> \n>> For example: It appears that CADF was designed for this sort of thing and\n>> was considered at some point in the past. It would be useful to know\n>> more of that story if there are any pointers.\n>> \n>> My initial reaction is that CADF has the stank of enterprisey all over\n>> it rather than \"less is more\" and \"worse is better\" but that\'s a\n>> completely uninformed and thus unfair opinion.\n> \n> TBH I don\'t know enough about CADF, but I know a man who does ;)\n> \n> (gordc, I\'m looking at you!)\n> \n>> Another question (from elsewhere in the thread) is if it is worth, in\n>> the Ironic notifications, to try and cook up something generic or to\n>> just carry on with what\'s being used.\n> \n> Well, my gut instinct is that the content of the Ironic notifications\n> is perhaps on the outlier end of the spectrum compared to the more\n> traditional notifications we see emitted by nova, cinder etc. So it\n> may make better sense to concentrate initially on how contractizing\n> these more established notifications might play out.\n> \n>>> This feels like something that we should be thinking about with an eye\n>>> to the K* cycle - would you agree?\n>> \n>> Yup.\n>> \n>> Thanks for helping to tease this all out and provide some direction on\n>> where to go next.\n> \n> Well thank *you* for picking up the baton on this and running with it :)\n> \n> Cheers,\n> Eoghan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A52CBA77@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1329450621.47.1383372504078.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:08:24',0,'2013-11-02 06:08:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #50','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/50/>\n\n------------------------------------------\n[...truncated 1310 lines...]\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:08:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:08:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:08:02+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:08:02-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:08:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6dbb090>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2f48d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 64.93 secs:\n    13.34    TestScrubber.test_delayed_delete\n    13.26    TestGlanceControl.test_reload\n    13.11    TestGlanceControl.test_respawn\n    13.08    TestGlanceControl.test_bouncing\n    12.14    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 437.511s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-50\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Epe1zsKimg\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/50\nERROR: Failed to upload files\n2: No such file\n	at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2833)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2185)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2202)\n	at com.jcraft.jsch.ChannelSftp.stat(ChannelSftp.java:2159)\n	at be.certipost.hudson.plugin.SCPSite.mkdirs(SCPSite.java:314)\n	at be.certipost.hudson.plugin.SCPSite.upload(SCPSite.java:243)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:248)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)\n	at hudson.model.Run.execute(Run.java:1618)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:247)\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise36/50\nERROR: Failed to upload files\n2: No such file\n	at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2833)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2185)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2202)\n	at com.jcraft.jsch.ChannelSftp.stat(ChannelSftp.java:2159)\n	at be.certipost.hudson.plugin.SCPSite.mkdirs(SCPSite.java:314)\n	at be.certipost.hudson.plugin.SCPSite.createOutStream(SCPSite.java:208)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:204)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)\n	at hudson.model.Run.execute(Run.java:1618)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:247)\n\n\n','<722710469.29.1383286296821.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1329768133.15728.116.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-20 20:02:13',0,'2012-02-20 20:02:13',NULL,'[OpenStack Foundation] Technical committee','Indeed, nice work Thierry.\n\nThe one thing I\'d say is that it would benefit from elaborating on the\nresponsibilities of the TC. Perhaps we all feel we have a rough idea\nwhat falls under the TC, but it\'d be nice to see those enumerated.\n\nAs a simple example - release management is listed as part of the\n\"project management\" role of the foundation. Does the foundation board\ndelegate to the TC decisions around the release schedule, go/no go on\nrelease candidates, etc.?\n\nMark.\n\nOn Mon, 2012-02-20 at 12:10 -0500, Jay Pipes wrote:\n> This is a well-written proposal, and I can\'t find anything that I would \n> disagree with.\n> \n> +1\n> \n> -jay\n> \n> On 02/20/2012 11:46 AM, Thierry Carrez wrote:\n> > Hi everyone,\n> >\n> > The current structure document is quite open on the Technical committee\n> > organization. Here are my proposals to keep it efficient... Please comment.\n> >\n> >\n> > = Technical committee =\n> >\n> > == Mission ==\n> >\n> > The Technical Committee (TC) is tasked with providing the technical\n> > leadership for the OpenStack project. It enforces OpenStack core\n> > projects ideals (Openness, Transparency, Commonality, Integration,\n> > Respect of release deadlines, Facilitation of downstream distribution\n> > [0]), decides on issues affecting multiple projects, and generally forms\n> > an ultimate appeals board for technical decisions.\n> >\n> > == Members ==\n> >\n> > The TC is composed of 9 elected members. You can cumulate other roles\n> > (Project technical lead, Foundation board member...) with a TC seat.\n> > Note that Project technical leads do not get appointed seats to the TC:\n> > they should run for election[1].\n> >\n> > == Meeting ==\n> >\n> > TC meetings happen publicly, weekly on IRC. The TC maintains an open\n> > agenda on the wiki. A TC meeting is called if anything is posted to that\n> > wiki at least one day before the meeting time. For a meeting to be\n> > actually held, at least two thirds of the members need to be present (6\n> > people). Non-members, in particular unelected PTLs or release manager,\n> > are more than welcome to participate to the meeting and voice their\n> > opinion, though they can\'t ultimately vote.\n> >\n> > == Motions ==\n> >\n> > Before being put to a vote, motions presented before the TC should be\n> > discussed publicly on the mailing-list[2] for a minimum of 5 days to\n> > give a chance to the wider community to express their opinion. Members\n> > can vote positively, negatively, or abstain. Decisions need more\n> > positive votes than negative votes, and a minimum of 3 positive votes.\n> >\n> > == Election ==\n> >\n> > The TC is renewed every 6 months using staggered elections: 5 seats are\n> > renewed every 6 months. People ranking 1st to 4th get elected for a\n> > one-year term. The 5th person gets elected for a 6-month term. People\n> > ranking after 6th are retained as potential substitute members (see\n> > \"Revocation\").\n> >\n> > == Voters ==\n> >\n> > Technical members of the Foundation, as determined by the Technical\n> > membership committee[3], are able to participate in this election.\n> >\n> > == Revocation ==\n> >\n> > TC members are expected to be available and participate to weekly\n> > meetings. If a particular TC member misses 3 of the last 5 called\n> > meetings, he should automatically be revoked. He would be replaced by\n> > the top substitute (person ranking 6th and after in previous election).\n> > Even when replacing someone elected for 1 year, the substitute inherits\n> > from the shortest term; the highest ranking elected person inherits from\n> > the potential longer term[4].\n> >\n> > == Initial election ==\n> >\n> > To initially populate the TC, all 9 seats are up for election. People\n> > ranking 1st to 4th get elected for one year. People ranking 5th to 9th\n> > get elected for 6 months[5].\n> >\n> >\n> > [0] From http://wiki.openstack.org/ProjectTypes\n> >\n> > [1] The idea is that we want to de-correlate the number of PTLs (and the\n> > relative importance of their projects) from the TC composition, to\n> > reduce committee bloat and be more fair. Influential PTLs from large\n> > projects should get elected anyway.\n> >\n> > [2] Could be the openstack ML or a specific TC ML. The idea is to avoid\n> > surprising the community with a decision, and avoid the usual kabbale\n> > critics.\n> >\n> > [3] More on this later.\n> >\n> > [4] Example: Fx got elected in Fall 2012, while Sx got elected in Spring\n> > 2013. Current board as F1, F2, F3, F4, S5 elected until Fall 2013, and\n> > S1, S2, S3, S4 elected until Spring 2014. S2 is a slacker is is revoked.\n> > S6 is called as a substitute. He should not get a longer term than S5\n> > though. So S5 inherits from the 1-year-long term and S6 from the\n> > 6-month-long term. Resulting board is: F1, F2, F3, F4, S6 elected until\n> > Fall 2013, and S1, S3, S4, S5 elected until Spring 2014.\n> >\n> > [5] We may want to re-align elections with release cycles. Example: If\n> > TC is created in July 2012, we may want to align elections with the next\n> > design summits, so the first term only be 2 months or 8 months.\n> >\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n','<4F427E94.1010207@gmail.com>',NULL),('<1329769075.15728.130.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-20 20:17:55',0,'2012-02-20 20:17:55',NULL,'[OpenStack Foundation] Technical committee Technical committee','Hi Jesse,\n\nOn Mon, 2012-02-20 at 11:32 -0800, Jesse Andrews wrote:\n> Hi,\n> \n> Perhaps it would be useful to share the the problems / issues you are\n> trying to improve.  My reading is that TC = PBB 2.0\n> \n>  * without appointed seats (PTLs or RAX appointed)\n>  * attendance requirements\n\nSame reading here, but also:\n\n * emphasis on wider discussion before TC level voting\n\n> I\'m particularly worried about the idea that PTLs aren\'t automatic.\n> What does it mean to allow decisions to made by the TC that a project\n> technical lead aren\'t inherently part of?\n\nGood question - e.g. if the TC votes that all projects should adopt the\nAwesomeDb library as a replacement for sqlalchemy and the PTL (and\nperhaps $project-core) disagrees, what then?\n\nI think the answer to that is that the TC is not so much responsible for\nmaking a final call where there is two fundamentally opposing views, but\nrather it is responsible for building a rough consensus. TC voting\nshould perhaps be about whether the TC think a rough consensus has been\nreached on a given topic.\n\nA PTL vehemently opposed to a given proposal is a signal that more work\nis needed. If the PTL is on the TC and a majority of the TC members vote\nagainst the PTL, that doesn\'t mean a consensus has been reached.\n\nA PTL has a strong veto power irrespective of his ability to vote on the\nTC. Also, $project-core members have somewhat of a veto power with the\nability to -2 a review.\n\nIMHO, this is all very healthy. We don\'t want the TC to be a group of\nindividuals making far reaching decisions without building a rough\nconsensus between the main players.\n\nCheers,\nMark.\n\n\n','<CAF=5gWvyW3knWeq7wJXho6Z-sQm9LYukT9Bp7hEJXpbMDE8C_g@mail.gmail.com>',NULL),('<1329770400.15728.143.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-02-20 20:40:00',0,'2012-02-20 20:40:00',NULL,'[OpenStack Foundation] Technical committee','On Mon, 2012-02-20 at 17:46 +0100, Thierry Carrez wrote:\n> == Revocation ==\n> \n> TC members are expected to be available and participate to weekly\n> meetings. If a particular TC member misses 3 of the last 5 called\n> meetings, he should automatically be revoked. \n\nYou\'ll probably have very little sympathy for this given that you manage\nto chair the OpenStack team meeting at 10pm your time every week,\nbut ... :)\n\nTimezones are a killer here; if folks absolutely have to attend the\nmeetings, we\'d need to rotate the time of the meetings to line up with\ndifferent TZs.\n\nCheers,\nMark.\n\n\n','<4F4278CD.9030406@openstack.org>',NULL),('<1329877082.0.1368771227928.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-17 06:13:47',0,'2013-05-17 06:13:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #228','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/228/>\n\n------------------------------------------\n[...truncated 941 lines...]\n    test_policy_file_default_not_found                           OK    0.01\n    test_policy_file_specified_but_not_found                     OK    0.01\nTestStore\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.19\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: \n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, None\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 73.34 secs:\n    17.17    TestGlanceControl.test_bouncing\n    14.65    TestScrubber.test_delayed_delete\n    14.13    TestGlanceControl.test_reload\n    13.94    TestGlanceControl.test_respawn\n    13.45    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 571.947s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-228\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.DOMRiZTeAH\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/228\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/228/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1329960384.2500.193.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-22 17:26:24',-28800,'2012-02-23 01:26:24',NULL,'[Openstack-operators] OpenStack Conference Call For Speakers','Hello folks,\n\nWe?ve postponed the deadline for OpenStack Conference call for speakers.\nWe\'d like your help to build out an informative and compelling agenda,\nincluding user stories, technical advancements, best practices and\nvisions on the future of OpenStack.\n\nThe new deadline is February 29, 2012. If you\'re interested in a\nspeaking opportunity please go fill the form on \nhttp://www.openstack.org/conference/san-francisco-2012/speakers\n\nThanks,\nStef\n\n\n',NULL,NULL),('<132DC00E-2F06-4111-8302-38545C5D924B@juniper.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 05:38:27',0,'2013-08-14 05:38:27',NULL,'[openstack-dev] Blueprint for Amazon VPC API support','Hi All,\n\nA blueprint has been registered to add Amazon VPC API support.\nCurrently Amazon EC2 API support already exists in Openstack.\nPlease review the blueprint and the attached specification. The\nspecification covers all the VPC APIs and describes how it maps\nto the Openstack constructs.\n\nBlueprint\nhttps://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n\nSpecification\nhttps://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n\nThe changes are orthogonal to Amazon EC2 APIs but follow the\nsame model as the EC2 API source code. In addition new unit\ntests have been added to cover all the VPC tests.\n\nPlease review the blueprint - all comments are welcome.\n\nThank you,\nRudra\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130814/229ac5ec/attachment.html>\n\n',NULL,NULL),('<1330130059.2232.142.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-24 16:34:19',-28800,'2012-02-25 00:34:19',NULL,'[Openstack-operators] OpenStack Community Newsletter –February 24, 2012','OpenStack Community Newsletter ?February 24, 2012\n\nHIGHLIGHTS\n\n\n      * OpenStack Governance Elections Spring 2012: Action Item For All\n        Candidates\n        http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012-action-item-for-all-candidates/ \n              * Nominations close on Monday \n      * Announcing StackTach: a little debugging tool to watch the flow\n        of an operation through the various parts of OpenStack\n        https://lists.launchpad.net/openstack/msg07765.html \n      * Quantum promoted to core project: it will be part of Folsom\n        release, in Autumn 2012 \n      * A brief update on the invites to the Design Summit\n        https://lists.launchpad.net/openstack/msg07765.html \n      * A proposal for the OpenStack Foundation Technical Committee\n        http://lists.openstack.org/pipermail/foundation/2012-February/000146.html \n      * New graph: now tracking contributions to Tempest (see below)\n\n\nEVENTS\n\n\n      * OpenStack 1st Global Hack-In Day Mar 01, 2012 ? Around the world\n        http://wiki.openstack.org/OpenStackUsersGroup/EssexGlobalHackIn \n      * TryStack.org ? a Sandbox for OpenStack! Mar 06, 2012 ? San\n        Francisco, CA http://www.meetup.com/openstack/events/52464312/ \n      * OpenStack Essex Doc Day Mar 06, 2012 ? San Francisco, CA\n        http://www.meetup.com/openstack/events/52466462/ \n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n\n\nOTHER NEWS\n\n\n      * Open development, releases and quality (Thierry Carrez)\n        http://fnords.wordpress.com/2012/02/21/open-dev-releases-quality/ \n      * Revisiting OpenStack Architecture: Essex Edition (Ken Pepple)\n        http://ken.pepple.info/openstack/2012/02/21/revisit-openstack-architecture-diablo/ \n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges \n              * Keystone Use Cases\n                http://wiki.openstack.org/KeystoneUseCases \n              * OpenStack Dashboard design concepts\n                http://wiki.openstack.org/Design \n              * Get started with Quantum fixing these easy bugs\n                http://wiki.openstack.org/QuantumStarterBugs \n      * Project meeting\n        summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-02-21-21.04.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Feb 13 00:00:00 UTC 2012 to Mon Feb 20 00:00:00 UTC 2012)\n        \nChanges to Tempest project week 07 2012\n\nChanges to Tempest project week 07 2012 \nChanges to Horizon project week 07 2012\n\nChanges to Horizon project week 07 2012 \nChanges to Swift project week 07 2012\n\nChanges to Swift project week 07 2012 \n\n\n\n\n\nChanges to Manuals project week 07 2012\n\nChanges to Manuals project week 07 2012 \nChanges to Keystone project week 07 2012\n\nChanges to Keystone project week 07 2012 \nChanges to Quantum project week 07 2012\n\nChanges to Quantum project week 07 2012 \n\n\n\n\n\nChanges to Glance project week 07 2012\n\nChanges to Glance project week 07 2012 \nChanges to Nova project week 07 2012\n\nChanges to Nova project week 07 2012 \n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120224/2574e907/attachment.html>\n\n',NULL,NULL),('<1330228366.8.1380436190368.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-29 06:29:50',0,'2013-09-29 06:29:50',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #27','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/27/>\n\n------------------------------------------\n[...truncated 20785 lines...]\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_grant_list_revoke_role_to_user_on_project[gate,smoke]\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_grant_list_revoke_role_to_user_on_project[gate,smoke] ... ok\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_role_create_update_get[gate,smoke]\ntempest.api.identity.admin.v3.test_roles.RolesV3TestJSON.test_role_create_update_get[gate,smoke] ... ok\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_list_user_projects[gate]\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_list_user_projects[gate] ... ok\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_user_update[gate]\ntempest.api.identity.admin.v3.test_users.UsersV3TestXML.test_user_update[gate] ... ok\nsetUpClass (tempest.api.network.test_load_balancer.LoadBalancerXML)\nsetUpClass (tempest.api.network.test_load_balancer.LoadBalancerXML) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_quotas.QuotasTest)\nsetUpClass (tempest.api.network.test_quotas.QuotasTest) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTest)\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTest) ... skipped u\'Neutron support is required\'\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML)\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML) ... skipped u\'Neutron support is required\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_admin_modify_quota[gate,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_admin_modify_quota[gate,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_large_object[gate,negative,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_large_object[gate,negative,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_valid_object[gate,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_upload_valid_object[gate,smoke] ... ok\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_user_modify_quota[gate,negative,smoke]\ntempest.api.object_storage.test_account_quotas.AccountQuotasTest.test_user_modify_quota[gate,negative,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\nInitialized empty Git repository in /tmp/tempest-unitGIFQv4/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitfAaafh/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  226.653\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          197.102\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  70.894\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         34.235\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        33.480\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    31.777\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       30.973\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       30.834\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        30.536\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         30.352\n\n----------------------------------------------------------------------\nRan 1249 tests in 1274.757s\n\nOK (skipped=66)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-416176-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-416176.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-416176/27/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1109960529.42.1380300335020.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1330730865.26151.1.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-02 15:27:45',-28800,'2012-03-02 23:27:45',NULL,'[Openstack-operators] OpenStack Community Newsletter –March 2, 2012','OpenStack Community Newsletter ?March 2, 2012\n\nHIGHLIGHTS\n\n\n      * OpenStack Governance Elections Spring 2012: remember to vote if\n        you have received the ballot. Results will be announced tomorrow\n        with a blog post. At 2:00pm PST this is the voter?s turnout:\n              * PPB: 104 of 208\n              * Keystone PTL: 46 of 75\n              * Horizon PTL: 27 of 42\n              * Glance PTL: 36 of 56\n              * Nova PTL: 105 of 188\n      * Rackspace announced the beta version of Cloud Servers powered by\n        OpenStack\n        http://www.rackspace.com/blog/rackspace-cloud-servers-powered-by-openstack-beta/\n      * Lots of new jobs posted on http://openstack.org/community/jobs/\n      * The road to Essex release (a.k.a. what is RC1?)\n        https://lists.launchpad.net/openstack/msg08223.html\n      *  Essex-4 milestone available for Keystone, Glance, Nova and\n        Horizon https://lists.launchpad.net/openstack/msg08173.html\n              * and Quantum\n                https://lists.launchpad.net/openstack/msg08197.html\n\n\nEVENTS\n\n\n      * TryStack.org ? a Sandbox for OpenStack! Mar 06, 2012 ? San\n        Francisco, CA http://www.meetup.com/openstack/events/52464312/\n      * OpenStack Essex Doc Day Mar 06, 2012 ? San Francisco, CA\n        http://www.meetup.com/openstack/events/52466462/\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n\n\nOTHER NEWS\n\n\n      * New OpenStack group in Atlanta\n        https://lists.launchpad.net/openstack/msg08090.html\n              * Do you know other groups around the world? Add it to\n                http://wiki.openstack.org/OpenStackUsersGroup and join\n                https://launchpad.net/~openstack-community\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n              * XenServer Development\n                http://wiki.openstack.org/XenServerDevelopment\n              * Hypervisor Support Matrix\n                http://wiki.openstack.org/HypervisorSupportMatrix\n              * How to contribute to OpenStack\n                http://wiki.openstack.org/HowToContribute\n              * OpenStack at PyCon 2012\n                http://wiki.openstack.org/Sprints/PyCon2012\n      * Project meeting summary\n        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-02-28-21.02.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Feb 20 00:00:00 UTC 2012 to Mon Feb 27 00:00:00 UTC 2012)\n\n\n\n\nChanges to Tempest project - week 08 2012\n        Changes to Tempest project ? week 08 2012 \nChanges to Horizon project - week 08 2012\n        Changes to Horizon project ? week 08 2012 \nChanges to Swift project - week 08 2012\n        Changes to Swift project ? week 08 2012 \n\n\n\n\nChanges to Manuals project - week 08 2012\n        Changes to Manuals project ? week 08 2012 \nChanges to Keystone project - week 08 2012\n        Changes to Keystone project ? week 08 2012 \nChanges to Quantum project - week 08 2012\n        Changes to Quantum project ? week 08 2012 \n\n\n\n\nChanges to Glance project - week 08 2012\n        Changes to Glance project ? week 08 2012 \nChanges to Nova project - week 08 2012\n        Changes to Nova project ? week 08 2012 \n\n\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120302/348b7752/attachment.html>\n\n',NULL,NULL),('<13308753.673.1365404774567.JavaMail.sthakkar@sthakkar-mbair.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 00:06:16',-25200,'2013-04-08 07:06:16',NULL,'[openstack-dev]  [Quantum] Summit Sessions - VPNaaS','The following is a new meeting request:\n\nSubject: [openstack-dev] [Quantum] Summit Sessions - VPNaaS \nOrganizer: \"Sachin Thakkar\" <sthakkar at vmware.com> \n\nLocation: Bridge \nTime: Wednesday, April 10, 2013, 1:00:00 PM - 2:00:00 PM GMT -08:00 US/Canada Pacific\n \nInvitees: openstack-dev at lists.openstack.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\n\nScheduling a follow up call on VPNaaS from the April 5th discussion.\n\nDetails at https://etherpad.openstack.org/HavanaVPNaaS\n\nDial info below\n\nParticipant Passcode: 4973535622\n\nCall-in toll-free number (Premiere): 1-866-715-6501  (US) \nCall-in number (Premiere): 1-719-325-2777  (US) \nLo-call  :- China  : +400 120 0675\nLocal :- UK, London : +44 (0) 20 3059 6057\n\nAdditional Numbers: http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c25585184f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298f8a59d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151c4b30a31fa1b2\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130408/57b3030f/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: meeting.ics\nType: text/calendar\nSize: 3526 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130408/57b3030f/attachment.ics>\n\n',NULL,NULL),('<1331090451.078312949@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-06 22:20:51',-18000,'2012-03-07 03:20:51',NULL,'[OpenStack Foundation] Update to proposal on Foundation structure','Thanks to everyone who has contributed to the discussion on the Foundation structure over the past few weeks. As I see it, the feedback has fallen into two main buckets--structure of the Board and make up of the Technical Committee--along with a few other tactical, but important details that are probably better worked out in the next phase.\n\nOn the Board structure the most consist feedback we heard was to make it easier for a more diverse set of organizations to be involved in the Board. To make it more accessible, we have created a new membership class: Associate Members. Associate Members would pay significantly lower fees, adjusted for company size, and as a class elect one person to the Board for each Strategic seat. Individual Members would also elect one person to the Board for each Strategic seat. The new Board structure would therefore be 1/3 elected by Individual Members, 1/3 elected by Associate Members, and 1/3 appointed by Strategic Members. The wiki was updated to reflect this: http://wiki.openstack.org/Governance/Foundation/Structure \n\nWhile there are other Board options that have been floated around (all individuals, no individuals and everything in between), this type of mixed structure still seems to have the broadest support.\n\nThere are also open questions about the mechanics of the Technical Committee, such as the role of PTLs on it, what qualifiers (if any) are placed on those who wish to vote in the elections, etc., so the Structure draft just makes note of that fact for now. I think we should keep that discussion going in the existing threads on the topic and Thierry\'s draft in the wiki. We can just incorporate that document into the Structure as it gets closer to being done.\n\nThe next phase will kick off the Drafting Committee mentioned in a previous email. We\'ll be publishing a commitment letter this week and asking companies that intend to become members to sign to that effect. We would like to set an aggressive deadline (late March) for signatures by interested companies so that we can keep the process moving. After the deadline, the Drafting Committee will be formed with each potential Strategic Member assigning an attorney to assist Alice King in the drafting process. The committee will  produce drafts of the legal documents to be published in the open for review and comment. These documents will be a good place to get into those finer details, such as the question of how a Board member could be removed or what happens in the case of an acquisition or merger between corporate members.\n\nWe\'ll hold webinars on Thurdsday & Friday this week (March 8 & 9) to gather additional feedback.\n\nThanks again for caring so much about the future of OpenStack! \n\nMark\n@sparkycollier\ncell: 512-791-0356\n\n\n',NULL,NULL),('<1331149883.29.1371104800119.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-13 06:26:40',0,'2013-06-13 06:26:40',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #255','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/255/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:41209\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:41209/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (15943) wsgi starting up on http://127.0.0.1:41209/\n\nnova.osapi_compute.wsgi.server: INFO: (15943) accepted (\'127.0.0.1\', 57303)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/Jun/2013 06:21:18] \"GET /v2 HTTP/1.1\" 204 216 0.000812\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-7327a326-5c7f-4b7d-ae72-468fb6ba436c</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (15943) accepted (\'127.0.0.1\', 57304)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7bb0710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7bb0710>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:41209/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-13 06:21:18 15943 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:41209/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/Jun/2013 06:21:18] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.256858\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 5ee1f2caba444c32a4772dddaa3871c5 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:53931\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:53931/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (15943) wsgi starting up on http://127.0.0.1:53931/\n\nnova.osapi_compute.wsgi.server: INFO: (15943) accepted (\'127.0.0.1\', 34267)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/Jun/2013 06:21:19] \"GET /v2 HTTP/1.1\" 204 216 0.001051\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-e59d1e90-c13e-4b58-9b31-dff7c95b908b</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (15943) accepted (\'127.0.0.1\', 34268)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8435550>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8435550>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:53931/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     name)\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-13 06:21:19 15943 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:53931/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [13/Jun/2013 06:21:19] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.284947\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.16\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.NG0z92iJtk\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/255\n[SCP] Copying console log.\n\n\n','<1670985218.27.1371018260650.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1331263911.109226591@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-08 22:31:51',-18000,'2012-03-09 03:31:51',NULL,'[OpenStack Foundation] Update to proposal on Foundation\n	structure','Hey y\'all, we\'ve decided to hold the webinars next week on Tuesday at 4pm central and Wednesday at 9am central to catch people in different parts of the world as we did last time.  We\'re hoping to get a lot of participation to hear feedback from folks about the latest draft we shared this week on the Foundation Structure, and discuss next steps.\n\nWe\'re going to be trying a new online meeting tool this time called meetingburner, since not everyone was thrilled with the readytalk system we used last time.  I really have no idea how well meetingburner will work, but let\'s give it a try and find out. A few things to note:\n\n1)  Unlike Readytalk, you do NOT need to dial into a bridge via phone to hear the call. In fact, with the free account we\'re testing the bridge will only accomodate 15 callers so please do NOT dial into the bridge number unless you absolutely have to.  Instead, when the webinar starts look for a little button on the left side of your browser to listen to the old fashioned way: over the internet. Let\'s try that.\n\n2)  There is a chat box where everyone can chat amongst ourselves - another missing feature from readytalk. The only flaw is that the box is really tiny, so we\'ll see how well it works.\n\n\nRegistration Links:\n\nTuesday March 13th at 4pm Central:  http://markcollier.enterthemeeting.com/m/EE23MEC8\n\nWednesday March 14th at 9am Central:  http://markcollier.enterthemeeting.com/m/3DP2HPKO\n\n\nMark Collier\n@sparkycollier\ncell:  512-791-0356\n\n\n\nOn Tuesday, March 6, 2012 10:20pm, \"Mark Collier\" <mark at openstack.org> said:\n\n> Thanks to everyone who has contributed to the discussion on the Foundation\n> structure over the past few weeks. As I see it, the feedback has fallen into two\n> main buckets--structure of the Board and make up of the Technical Committee--along\n> with a few other tactical, but important details that are probably better worked\n> out in the next phase.\n> \n> On the Board structure the most consist feedback we heard was to make it easier\n> for a more diverse set of organizations to be involved in the Board. To make it\n> more accessible, we have created a new membership class: Associate Members.\n> Associate Members would pay significantly lower fees, adjusted for company size,\n> and as a class elect one person to the Board for each Strategic seat. Individual\n> Members would also elect one person to the Board for each Strategic seat. The new\n> Board structure would therefore be 1/3 elected by Individual Members, 1/3 elected\n> by Associate Members, and 1/3 appointed by Strategic Members. The wiki was updated\n> to reflect this: http://wiki.openstack.org/Governance/Foundation/Structure\n> \n> While there are other Board options that have been floated around (all\n> individuals, no individuals and everything in between), this type of mixed\n> structure still seems to have the broadest support.\n> \n> There are also open questions about the mechanics of the Technical Committee, such\n> as the role of PTLs on it, what qualifiers (if any) are placed on those who wish\n> to vote in the elections, etc., so the Structure draft just makes note of that\n> fact for now. I think we should keep that discussion going in the existing threads\n> on the topic and Thierry\'s draft in the wiki. We can just incorporate that\n> document into the Structure as it gets closer to being done.\n> \n> The next phase will kick off the Drafting Committee mentioned in a previous email.\n> We\'ll be publishing a commitment letter this week and asking companies that intend\n> to become members to sign to that effect. We would like to set an aggressive\n> deadline (late March) for signatures by interested companies so that we can keep\n> the process moving. After the deadline, the Drafting Committee will be formed with\n> each potential Strategic Member assigning an attorney to assist Alice King in the\n> drafting process. The committee will  produce drafts of the legal documents to be\n> published in the open for review and comment. These documents will be a good place\n> to get into those finer details, such as the question of how a Board member could\n> be removed or what happens in the case of an acquisition or merger between\n> corporate members.\n> \n> We\'ll hold webinars on Thurdsday & Friday this week (March 8 & 9) to gather\n> additional feedback.\n> \n> Thanks again for caring so much about the future of OpenStack!\n> \n> Mark\n> @sparkycollier\n> cell: 512-791-0356\n> \n\n\n\n','<1331090451.078312949@emailsrvr.com>',NULL),('<1331333118.2631.67.camel@mattone-E6420>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-09 14:45:18',-28800,'2012-03-09 22:45:18',NULL,'[OpenStack Foundation] is \'strategic\' the right name? (was Re:\n Foundation Structure: An Alternative)','On Fri, 2012-03-09 at 16:27 -0600, Mark Collier wrote:\n> Associate Member category, [...]\n> Strategic Member [...]\n\nI wonder if calling \'Strategic\' members that basically only have more\nmoney but the same responsibilities and rights of other members is\nreally the best thing to do. It made sense when we had only two kinds\n(corporate and individuals) and corporate members where called to put\nmoney down to create the foundation. That was a strategic role.\n\nNow we have two corporate citizens, startup and small companies with\nlarge established corporations, both equally strategic to the success of\nthe initiative. And we have individuals, too.\n\nWould it make sense to spend some time and think about a different name\nfor the levels of corporate participation to the foundation?\n\n/stef\n\n\n\n\n','<CB7FDD75.19508%mark@openstack.org>',NULL),('<1331338220.2631.73.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-09 16:10:20',-28800,'2012-03-10 00:10:20',NULL,'[Openstack-operators] OpenStack Community Newsletter –March 9, 2012','OpenStack Community Newsletter ?March 9, 2012\n\nHIGHLIGHTS\n\n\n      * OpenStack community elected new PTLs and two members of PPB\n        http://www.openstack.org/blog/2012/03/openstack-governance-elections-spring-2012-results/\n      * OpenStack effort to join Google Summer of Code\n        https://lists.launchpad.net/openstack/msg08459.html\n      * Swift 1.4.7 released\n        https://lists.launchpad.net/openstack/msg08445.html\n      * Results of OpenStack Documentation Day\n        https://lists.launchpad.net/openstack/msg08403.html\n      * Help needed to enable remote participation at Folsom Design\n        Summit https://lists.launchpad.net/openstack/msg08360.html\n\n\nEVENTS\n\n\n      * Webinar: OpenStack Foundation update Mar 13, 2012 ? Webinar\n        http://markcollier.enterthemeeting.com/m/EE23MEC8\n      * Webinar: OpenStack Foundation update Mar 14, 2012 ? Webinar\n        http://markcollier.enterthemeeting.com/m/3DP2HPKO\n      * Australian OpenStack Users Group MeetUp Mar 26, 2012 ? Sidney,\n        Australia http://aosug.openstack.org.au/events/49679462/\n      * Lights, Camera, Stackers! Mar 29, 2012 ? Los Angeles, CA\n        http://www.meetup.com/OpenStack-LA/events/54125632/\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n\n\nOTHER NEWS\n\n\n      * Preparing my first patch for OpenStack (by Doug Hellmann)\n        http://blog.doughellmann.com/2012/03/preparing-my-first-patch-for-openstack.html\n      * Image registering in nova2ools (by GridDynamics)\n        http://openstackgd.wordpress.com/2012/03/07/image-registering-in-nova2ools/\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n              * Governance/Foundation/Structure\n                http://wiki.openstack.org/Governance/Foundation/Structure\n              * Governance/Foundation/Funding\n                http://wiki.openstack.org/Governance/Foundation/Funding\n              * Governance/Elections Spring2012/Post Mortem\n                http://wiki.openstack.org/Governance/ElectionsSpring2012/PostMortem\n              * GSoC2012/Ideas http://wiki.openstack.org/GSoC2012/Ideas \n              * XenServer http://wiki.openstack.org/XenServer\n      * Project meeting\n        summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-03-06-21.06.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Feb 27 00:00:00 UTC 2012 to Mon March 5 00:00:00 UTC 2012)\n        \nChanges to Glance project ? week 09 2012\n        Changes to Glance project ? week 09 2012 \nChanges to Horizon project ? week 09 2012\n        Changes to Horizon project ? week 09 2012 \nChanges to Keystone project ? week 09 2012\n        Changes to Keystone project ? week 09 2012 \n\n\n\n\nChanges to Manuals project ? week 09 2012\n        Changes to Manuals project ? week 09 2012 \nChanges to Nova project ? week 09 2012\n        Changes to Nova project ? week 09 2012 \nChanges to Quantum project ? week 09 2012\n        Changes to Quantum project ? week 09 2012 \n\n\n\n\nChanges to Swift project ? week 09 2012\n        Changes to Swift project ? week 09 2012 \nChanges to Tempest project ? week 09 2012\n        Changes to Tempest project ? week 09 2012 \n\n\n\n\n\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120309/be56bf8d/attachment.html>\n\n',NULL,NULL),('<1331370A-C2DC-4FFA-85F1-772989D3B872@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 19:59:07',0,'2012-11-21 19:59:07',NULL,'[openstack-dev] A set of Keystone blueprints relating to domains','Hi\n\nI have been working, with others, on a set of blueprints (some already discussed on this list) that enhance the definition and use of domains to make Openstack more successful and acceptable to enterprise customers (both when being hosted by a openstack-based cloud provider as well as for private clouds).  I would welcome comments/suggestions:\n\nOptional private name spaces for domains.  The initial draft of this proposal has been discussed here before, but I have now added details of the proposed changes : https://blueprints.launchpad.net/keystone/+spec/domain-name-spaces\n\nToken scoping to a domain.  More easily enabling the operation of domain-wide admin roles: https://blueprints.launchpad.net/keystone/+spec/domain-scoping\n\nDomain role assignment.  Providing more flexibility in terms of what the current functionality means to assign a role to a user-domain pair: https://blueprints.launchpad.net/keystone/+spec/domain-role-assignment\n\nHenry\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/e5f23e03/attachment.html>\n\n',NULL,NULL),('<1331476716.2065.26.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-11 14:38:36',0,'2012-03-11 14:38:36',NULL,'[OpenStack Foundation] Foundation Structure: An Alternative','On Fri, 2012-03-09 at 14:50 -0800, Boris Renski Jr. wrote:\n\n> In my view the price tag for the sponsorship and the ultimate means\n> for raising the money is not what drives OpenStack?s vendor\n> independence principles. What matters the most is the degree of\n> decoupling between the front-end, marketing  and the technical\n> governance. Much of the OpenStack current momentum is due to this\n> fairly unique way of doing open source where on one end you have an\n> open, meritocracy-based technology community and, on the other ?\n> structured commercial interest that evangelizes it. As long as the two\n> sides remain sufficiently decoupled (as they have been so far) ? no\n> OpenStack principles will be compromised.  \n> \n> I think that the community needs to do away with this geek, open\n> source mentality of ?all corporations are evil?\n\nFWIW, I don\'t think I\'ve noticed the \"all corporations are evil\"\nmentality during any of the foundation discussions to date.\n\nThen again, I haven\'t noticed the \"petulant moralism of the meritocracy\"\nin OpenStack either.\n\nSo, perhaps those attributing such unreasonable behaviour to folks could\ncall out specific examples in future as they occur?\n\n>  and harness the value in strong commercial forces evangelizing and\n> battling for the interest of the independent technology community.\n> This is what got OpenStack to where it is now. So far the line between\n> technology and marketing been well maintained. The bottom line is that\n> a) technical committee must be elected and driven by meritocracy; b)\n> foundation board should have virtually no influence (which is the case\n> in the current structure) on the technical committee. Everything else\n> is noise. \n\nRackspace and others have done an awesome job of evangelising and\npromoting OpenStack to date. I\'m sure no-one wants that marketing\nsuccess to falter.\n\nHowever, you\'re overstating the current and proposed independence\nbetween the project\'s technical community and the entity evangelising\nthe project (i.e. Rackspace currently, the Foundation in future).\n\nLooking at:\n\n  http://wiki.openstack.org/Governance/Foundation/Structure\n\nthe Foundation is responsible for \"project management\", community\nmanagement (including the technical community, I assume), release\nmanagement, \"encouraging and rewarding contribution\" and, importantly,\nthe governance structure of the project itself. Any power the technical\ncommunity has over the project is devolved to it by the Foundation.\n\nIn the proposed structure, the Foundation is ultimately in complete\ncontrol of the project just as Rackspace is now. It is not analogous to\nthe separation between Linux project governance (i.e. Linus) and its\nevangelism (i.e. the Linux Foundation).\n\nIf the primary motivation for the current proposal\'s emphasis - decision\nmaking by corporate appointees, very large corporate cash contributions\nand a multi-million dollar annual budget - is purely on the evangelism\nand marketing side, perhaps the notion of having two separate\norganizations is worth considering.\n\nHowever, to make that work, the organization responsible for the project\nwould have to own the OpenStack mark (so that e.g. it has full control\nover decisions about what can be announced as an official OpenStack\nproject release), but perhaps delegate the responsibility for\nadministering that mark to the marketing organization.\n\nCheers,\nMark.\n\n\n','<011b01ccfe47$182da740$4888f5c0$@renski.com>',NULL),('<1331571573.2589777.1390024821233.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 01:00:21',-18000,'2014-01-18 06:00:21',NULL,'[openstack-dev] a \"common\" client library','I can\'t see any reason that all of these situations can\'t be met. \n\nWe can finally take the openstack pypi namespace, move keystoneclient -> openstack.keystone and similar for the other projects. Have them all based upon openstack.base and probably an openstack.transport for transport.\n\nFor the all-in-one users we can then just have openstack.client which depends on all of the openstack.x projects. This would satisfy the requirement of keeping projects seperate, but having the one entry point for newer users. Similar to the OSC project (which could acutally rely on the new all-in-one).\n\nThis would also satisfy a lot of the clients who have i know are looking to move to a version 2 and break compatability with some of the crap from the early days.\n\nI think what is most important here is deciding what we want from our clients and discussing a common base that we are happy to support - not just renaming the existing ones.\n\n(I don\'t buy the problem with large amounts of dependencies, if you have a meta-package you just have one line in requirements and pip will figure the rest out.)\n\nJamie\n\n----- Original Message -----\n> From: \"Jonathan LaCour\" <jonathan-lists at cleverdevil.org>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Saturday, 18 January, 2014 4:00:58 AM\n> Subject: Re: [openstack-dev] a \"common\" client library\n> \n> On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < donald at stufft.io > wrote:\n> \n> \n> \n> \n> On Jan 16, 2014, at 4:06 PM, Jesse Noller < jesse.noller at RACKSPACE.COM >\n> wrote:\n> \n> \n> \n> \n> \n> On Jan 16, 2014, at 2:22 PM, Renat Akhmerov < rakhmerov at mirantis.com > wrote:\n> \n> \n> \n> \n> Since it?s pretty easy to get lost among all the opinions I?d like to\n> clarify/ask a couple of things:\n> \n> \n> \n>     * Keeping all the clients physically separate/combining them in to a\n>     single library. Two things here:\n>         * In case of combining them, what exact project are we considering?\n>         If this list is limited to core projects like nova and keystone what\n>         policy could we have for other projects to join this list?\n>         (Incubation, graduation, something else?)\n>         * In terms of granularity and easiness of development I?m for keeping\n>         them separate but have them use the same boilerplate code, basically\n>         we need a OpenStack Rest Client Framework which is flexible enough\n>         to address all the needs in an abstract domain agnostic manner. I\n>         would assume that combining them would be an additional\n>         organizational burden that every stakeholder would have to deal\n>         with.\n> \n> Keeping them separate is awesome for *us* but really, really, really sucks\n> for users trying to use the system.\n> \n> I agree. Keeping them separate trades user usability for developer usability,\n> I think user usability is a better thing to strive for.\n> 100% agree with this. In order for OpenStack to be its most successful, I\n> believe firmly that a focus on end-users and deployers needs to take the\n> forefront. That means making OpenStack clouds as easy to consume/leverage as\n> possible for users and tool builders, and simplifying/streamlining as much\n> as possible.\n> \n> I think that a single, common client project, based upon package namespaces,\n> with a unified, cohesive feel is a big step in this direction.\n> \n> --\n> Jonathan LaCour\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAO4Q=i+bOeahbAgM65qR2+X4whHUoLD2u+oiN54yTPi8SRHPfA@mail.gmail.com>',NULL),('<1331753631.30910.104.camel@mattone-E6420>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-14 12:33:51',-25200,'2012-03-14 19:33:51',NULL,'[OpenStack Foundation] [Openstack] Foundation Structure: An\n Alternative','On Wed, 2012-03-14 at 15:15 -0400, Jim Jagielski wrote:\n> Foundations should exist to service the code and the\n> committer/developer.\n\nI think you\'re forgetting to put users in the pictures, both existing\nones and the ones that should/could become users. Code and developers\ndeveloping in vacuum don\'t go anywhere. Some would argue that putting\nusers immediately in the picture was one of the reasons of OpenStack\nsuccess.\n\n> Yeah, I admit I\'m biased. But I\'d hate to see OpenStack make a\n> mistake. One of the best things it did was to get out from underneath\n> the shackles of RackSpace, \n\nWhat do you see that Rackspace does that qualifies as \'shackles\'? Lets\nbe specific here because if something needs to be fixing it\'s better to\nidentify it now and propose solutions.\n\nThanks\n/stef\n\n\n','<CAJWaTXS1tZZw8rjeBxijjMviVUF3ktaN5D=Yk8HbrxVhzxx6UQ@mail.gmail.com>',NULL),('<1331908292.20169.22.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-16 10:31:32',-14400,'2012-03-16 14:31:32',NULL,'[OpenStack Foundation] [Openstack] Foundation Structure: An\n Alternative','Hi Jim,\n\nOn Fri, 2012-03-16 at 09:10 -0400, Jim Jagielski wrote:\n\n> Just an overriding desire, it seems, to favor big-name players, with\n> deep pockets, over a real community; the desire to start *big*, and\n> get bigger; the desire to see how much money can be pulled in, and not\n> so much where that money goes or how it ultimately helps the\n> *community* instead of the *foundation*.\n> \n> OpenStack will turn into a business consortium made up of large,\n> well-financed companies, who will determine the course and direction\n> of the so-called \"open source projects\" and unless you\'re able to pay\n> up, smaller players will simply have to take what they are given. And\n> the only personal incentive developers will have to work on the code\n> will be their bonuses and payments.\n> \n> Open source communities are built around passion for the code, not\n> passion for the foundation (or its income).\n\nI admit to sharing your uneasiness about the emphasis of the foundation\non the corporate players, fund-raising and the lack of emphasis on\nmembers of the community as individuals with a shared passion for the\nproject.\n\nHowever, there\'s a bunch of detail that greatly mitigates those\nconcerns:\n\n  - The OpenStack Foundation is more akin to the Linux Foundation than\n    e.g. the Apache Foundation. It\'s about bringing the corporate\n    players together and raising funds to \"promote and protect\" the\n    project.\n\n  - Continuing the Linux Foundation analogy, there is a strong desire \n    for the project itself to have almost as much independence from the \n    Foundation as the Linux project has from the Linux Foundation. This \n    is what the \"empower\" part of the Foundation\'s mission is about.\n\n    I say *almost* because, unlike Linux, the Foundation holds the \n    trademark and the Foundation Board has some ability to control the \n    project by e.g. defining the scope of the project to limit the \n    Technical Board\'s ability to approve new projects. Unlike Linux, \n    the project governance is ultimately subordinate to the Foundation\n    Board.\n\n  - As Thierry says, the Technical Board should be fully elected and \n    all members of that board will be expected to represent the project \n    rather than their employer.\n\nMy strawman foundation structure[1] was all about making the corporate\nrepresentation subordinate to the meritocratic project governance. I\nthink the concern with taking that approach is that it will limit the\namount of cash that can be raised to help the project and continue its\nmarketing/evangelism success to date.\n\nIf we go with the approach of keeping project and the corporate\nconsortium separated, I\'d love to see us go the whole hog and build the\nkind of separation that Linux has. One way of doing that would be to\ncreate two organizations - the OpenStack Consortium and the OpenStack\nFoundation. The latter would govern the project using a meritocratic\nstructure and hold the trademark. The former would bring the corporate\nplayers together, advise the project on strategy, evangelise the\nproject, provide resources to the project and protect the trademark.\nThere would be a symbiotic relationship between the two organizations.\n\nYet another alternative would be to create the OpenStack Consortium,\nmove the project to an existing Foundation and build that same symbiotic\nrelationship between the two organizations.\n\nCheers,\nMark.\n\n[1] - http://wiki.openstack.org/StrawmanFoundationStructur\n\n\n','<CAJWaTXRq5StBZp8C_HBsE2EYm7yUH_4cnYBfeFtjqzZ0a8SZ8Q@mail.gmail.com>',NULL),('<1331936213.9795.19.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-16 15:16:53',-25200,'2012-03-16 22:16:53',NULL,'[Openstack-operators] OpenStack Community Newsletter –March 16, 2012','OpenStack Community Newsletter ?March 16, 2012\n\nHIGHLIGHTS\n\n\n      * Submit session proposals for OpenStack Folsom Design Summit\n        https://lists.launchpad.net/openstack/msg08674.html\n      * Shout out to all folks who participated to sprints for OpenStack\n        this year at PyCon\n        http://oubiwann.blogspot.com/2012/03/openstack-at-pycon-2012-sprints.html\n      * The real way to start hacking on OpenStack\n        http://www.linuxjedi.co.uk/2012/03/real-way-to-start-hacking-on-openstack.html\n      * OpenStack API?s and WSGI, Mike Pittaro?s presentation at South\n        Bay OpenStack Meetup March 8th\n        http://www.slideshare.net/lhrc_mikeyp/openstack-apis-and-wsgi\n      * The road to OpenStack Essex release candidates\n        http://fnords.wordpress.com/2012/03/16/road-to-essex-rc/\n      * Hardware needed to enable remote participation at Folsom Design\n        Summit https://lists.launchpad.net/openstack/msg08360.html\n\n\nEVENTS\n\n\n      * Australian OpenStack Users Group MeetUp Mar 26, 2012 ? Sidney,\n        Australia http://aosug.openstack.org.au/events/49679462/\n      * Lights, Camera, Stackers! Mar 29, 2012 ? Los Angeles, CA\n        http://www.meetup.com/OpenStack-LA/events/54125632/\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n      * OpenStack Israel 2012 May 30, 2012 ? Tel Aviv-Yafo, Israel\n        http://www.meetup.com/IGTCloud/events/53864922/\n\n\nOTHER NEWS\n\n\n      * Changes to the handling of local storage for the libvirt driver\n        http://openstackgd.wordpress.com/2012/03/15/changes-to-the-handling-of-local-storage-for-the-libvirt-driver/\n      * Add Support for Local Volumes in OpenStack\n        http://openstackgd.wordpress.com/2012/03/15/add-support-for-local-volumes-in-openstack/\n      * Changes coming to Gerryt style on review.openstack.org\n        http://www.linuxjedi.co.uk/2012/03/changes-coming-to-gerrits-style.html\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n              * Governance/Foundation/Structure\n                http://wiki.openstack.org/Governance/Foundation/Structure\n              * Governance/Foundation/Funding\n                http://wiki.openstack.org/Governance/Foundation/Funding\n              * Nova Volume meetings\n                http://wiki.openstack.org/NovaVolumeMeetings\n      * Project meeting\n        summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-03-06-21.06.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Feb 27 00:00:00 UTC 2012 to Mon March 5 00:00:00 UTC 2012)\n\n\n\n\nChanges to Glance project ? week 10 2012\n        Changes to Glance project ? week 10 2012 \nChanges to Horizon project ? week 10 2012\n        Changes to Horizon project ? week 10 2012 \nChanges to Keystone project ? week 10 2012\n        Changes to Keystone project ? week 10 2012 \n\n\n\n\nChanges to Manuals project ? week 10 2012\n        Changes to Manuals project ? week 10 2012 \nChanges to Nova project ? week 10 2012\n        Changes to Nova project ? week 10 2012 \nChanges to Quantum project ? week 10 2012\n        Changes to Quantum project ? week 10 2012 \n\n\n\n\nChanges to Swift project ? week 10 2012\n        Changes to Swift project ? week 10 2012 \nChanges to Tempest project ? week 10 2012\n        Changes to Tempest project ? week 10 2012 \n\n\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120316/7a3c88da/attachment.html>\n\n',NULL,NULL),('<1332195788.9236338.1405023368814.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 16:16:08',-14400,'2014-07-10 20:16:08',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n\n> It\'s not clear to me in this discussion what it is that is being\n> versioned, contracted or standardized.\n\nWell the statement in the original mail was pretty explicit:\n\n \"versioned notification payloads to protect consumers from breaking\n  changes in payload format\"\n\nSo it\'s the standardization of notification payload formats that\'s\nbeing proposed.\n \n> Is it each of the many different notifications that various services\n> produce now?\n\nIts the event types emitted and the version of each payload.\n\n> Is it the general concept of a notification which can be considered\n> a \"sample\" that something like Ceilometer or StackTack might like to\n> consume?\n\nWell, the notifications emitted are intended to be general-purpose\nin nature.\n\nCeilometer, StackTack OTOH put those notifications to a specific\n(and slightly different) purpose.\n\nHaving the services emit exactly the sample format that ceilometer\ndesired would save ceilometer itself doing the transformation, but\nwould make the notifications less useful to other consumers. \n\n> If it not the latter, why isn\'t it the latter?\n\nFor the reason state above.\n\n> Here\'s some semi-random\n> noodling:\n> \n> Wouldn\'t the metering process be a lot easier if there was a\n> standardized package for a \"sample\" and anyone with the proper\n> credentials could drop a sample on the bus with the right exchange with\n> the right topic and anything (e.g. Ceilometer, StackTack, the\n> NewShinyMeteringShiz) that wants to consider itself a metering store can\n> consume it and hey presto.\n\nProblem is, the requirements of Ceilometer, StackTack, and indeed\nNewShinyMeteringShiz, are probably gonna be different.\n \n> If people are going to have to write a bunch of new tests and\n> related code to get notifications healthier why not make\n> notifications for metrics _healthy_ and available to any system\n> without needing to write a bunch of code on both sides of the bus.\n\nThe intent was loose-coupling between the notifier and the notified.\n\nThese notifications pre-exist ceilometer, where never intended for\nceilometer\'s exclusive use, and are in current use by frameworks\nother than ceilometer, each with differing requirements. \n\n> Currently Ceilometer is required to know far too much about the\n> notifications it receives and that knowledge is being represented is\n> code. That is a BadThing?. I\'m sure there are plenty of reasons for\n> why it has turned out that way, but if there is an opportunity for\n> change...?\n\nNot really, I don\'t think, TBH.\n\nCheers,\nEoghan\n\n\n','<alpine.OSX.2.11.1407101548510.28364@seed>',NULL),('<1332428407.8210.YahooMailNeo@web31806.mail.mud.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-22 08:00:07',-25200,'2012-03-22 15:00:07',NULL,'[Openstack-operators] Looking for speakers on Private Clouds','I organize the speakers for the Bay Area Large-Scale Production Engineering\nmeetup (http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/ ;\ntake a look at the \"PAST\" tab to see the kinds of events we\'ve had).\n\nFor our April event, on Thursday April 19th\n(http://www.meetup.com/SF-Bay-Area-Large-Scale-Production-Engineering/events/48901162/), I\'m putting together an evening of talks about private clouds,\nand am looking for speakers. ?I usually try to arrange two to four 20-25\nminute talks around a single topic or theme -- this time it would be private\nclouds. ?If you have experience building and/or using a private cloud using OpenStack (or anything else), we\'d\nlike to hear about it. ?I\'ve put some suggested topics there on\nthe meetup event page (please take a look), but I\'m open to anything in this\narea.\n\nIf you\'re going to be in the Bay Area on that date, and could give a talk,\nplease contact me through that meetup, or at c w e s t i n (at y a h o o dot com).\n\nThanks!\nChris Westin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120322/400071bd/attachment.html>\n\n',NULL,NULL),('<1332540224.28301.13.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-23 15:03:44',-25200,'2012-03-23 22:03:44',NULL,'[Openstack-operators] OpenStack Community Newsletter –March 23, 2012','OpenStack Community Newsletter ?March 23, 2012\n\nA great community story:\n\n\n        Over the course of just a week I?ve gone from despair and\n        frustration to almost wanting to shout from the rooftops the\n        achievements that have been made in OpenStack and my own\n        deployments and testing\n\n\nRead the rest of it on\nhttps://lists.launchpad.net/openstack/msg08950.html\n\nHIGHLIGHTS\n\n\n      * Submit session proposals for OpenStack Folsom Design Summit\n        https://lists.launchpad.net/openstack/msg08674.html\n      * OpenStack Essex release candidates are ready: go test them while\n        supplies last\n      * Shout out to Andrew Hutchings for the new Jenkins and Gerrit\n        styles\n        http://www.linuxjedi.co.uk/2012/03/new-gerrit-and-jenkins-styles-are-live.html\n\n\nEVENTS\n\n\n      * Australian OpenStack Users Group MeetUp Mar 26, 2012 ? Sidney,\n        Australia http://aosug.openstack.org.au/events/49679462/\n      * Lights, Camera, Stackers! Mar 29, 2012 ? Los Angeles, CA\n        http://www.meetup.com/OpenStack-LA/events/54125632/\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n      * OpenStack Israel 2012 May 30, 2012 ? Tel Aviv-Yafo, Israel\n        http://www.meetup.com/IGTCloud/events/53864922/\n      * Open Cloud and Public Administration Jun 19, 2012 ? Bern,\n        Switzerland Call for papers/sponsors\n        http://www.ch-open.ch/index.php?id=1034\n\n\nOTHER NEWS\n\n\n     1. New user groups in Canberra\n        http://www.meetup.com/Canberra-OpenStack-Users-Group/ and India\n        http://www.meetup.com/Indian-OpenStack-User-Group\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n              * How To Update Corporate CLA\n                http://wiki.openstack.org/HowToUpdateCorporateCLA\n              * Governance/Foundation/Funding\n                http://wiki.openstack.org/Governance/Foundation/Funding\n              * Nova Orchestration Spec For Folsom\n                http://wiki.openstack.org/NovaOrchestrationSpecForFolsom\n              * XenServer http://wiki.openstack.org/XenServer\n              * QuantumPackages\n                http://wiki.openstack.org/QuantumPackages\n      * Project meeting summary\n        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-03-20-21.02.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Mar 5 00:00:00 UTC 2012 to Mon March 12 00:00:00 UTC 2012)\n\n\n\n\nChanges to Glance project ? week 11 2012\n        Changes to Glance project ? week 11 2012 \nChanges to Horizon project ? week 11 2012\n        Changes to Horizon project ? week 11 2012 \nChanges to Keystone project ? week 11 2012\n        Changes to Keystone project ? week 11 2012 \n\n\n\n\nChanges to Manuals project ? week 11 2012\n        Changes to Manuals project ? week 11 2012 \nChanges to Nova project ? week 11 2012\n        Changes to Nova project ? week 11 2012 \nChanges to Quantum project ? week 11 2012\n        Changes to Quantum project ? week 11 2012 \n\n\n\n\nChanges to Swift project ? week 11 2012\n        Changes to Swift project ? week 11 2012 \nChanges to Tempest project ? week 11 2012\n        Changes to Tempest project ? week 11 2012 \n\n\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120323/06ae9304/attachment.html>\n\n',NULL,NULL),('<1332613658.8164316.1382079878899.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-18 03:04:38',-14400,'2013-10-18 07:04:38',NULL,'[Openstack-docs] What\'s Up Doc? Oct 17th 2013','Hi Anne,\nFirst off, congratulations on the Havana release with yourself as program technical lead! You were tireless and patient, you herded the cats, and it all somehow worked. For myself, as a newcomer to upstream contribution, the entire process was fascinating and educational.\n\nAnd now, a question for the OpenStack Docs site.\nIs there anyway to re-index the search, so that it gives out Havana results instead of Grizzly doc results?\n\nthanks,\nSummer\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\nFrom: \"Anne Gentle\" <anne at openstack.org>\nTo: openstack-docs at lists.openstack.org, \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nCc: \"Glen Campbell\" <glen.campbell at rackspace.com>\nSent: Friday, October 18, 2013 6:13:45 AM\nSubject: [Openstack-docs] What\'s Up Doc? Oct 17th 2013\n\nSpecial release day edition of What\'s Up Doc -- I want to take a minute to recognize this milestone and give a huge thanks to everyone who made it possible to release docs today. A sincere thank you, pat on the back, and special recognition to the top 10: \nAndreas Jaeger, Diane Fleming, (me), Tom Fifield, Christian Berendt, Sean Roberts, Stephen Gordon, Summer Long, Lorin Hochstein, and Nermina Miller. Way to rock the docs! \n\nThe openstack-manuals repo now has a stable/havana branch which publishes the Install Guides and Configuration Reference to docs.openstack.org/havana/ . All other guides publish from the master branch to a direct link. \n\nSo, I\'ll walk through a scenario. Let\'s say you have a fix to the install guide that you know is incorrect in the Havana link for the install guide: \n\n\n    1. First, fix the error in the master branch as normal. \n    2. Then, once that patch is reviewed and merged, follow the steps in https://wiki.openstack.org/wiki/Documentation/HowTo#How_to_a_cherry-pick_a_change_to_a_stable_branch to pick a copy of that patch create a special patch just for the stable/havana branch. \n    3. Once that patch is merged, your changes will show up on the docs.openstack.org/havana/ version of the install guide. \nHint: It\'s best to keep those changes small to make the reviewing/merging when backporting easier. \n\nFor the time prior to the summit, let\'s focus on doc bugs -- triaging, fixing, tagging, all are good tasks for the next 2 weeks. Let\'s also keep an eye on http://ask.openstack.org and the Disqus comments for feedback and input. I also want to work on search-ability/find-ability with a sitemap.xml, fine-tuned .htaccess, and any other tips and tricks after the release and reorg would be welcomed. We\'re also exploring redesign ideas for the docs pages. After the Summit and listening to feedback on Havana, let\'s write up some top priorities for docs for the next release. \n\nThanks all, \nAnne \n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<CAD0KtVEYfy3H+7O-ad9C5=DzS4V+ozp2EP9c1dOESaOdph6LOg@mail.gmail.com>',NULL),('<1333139799.2520.50.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-30 13:36:39',-25200,'2012-03-30 20:36:39',NULL,'[Openstack-operators] OpenStack Community Newsletter –March 30, 2012','OpenStack Community Newsletter ?March 30, 2012\n\nHIGHLIGHTS\n\n\n      * Submit session proposals for OpenStack Folsom Design Summit\n        https://lists.launchpad.net/openstack/msg08674.html\n      * OpenStack Spring 2012 Conference Schedule\n        http://www.openstack.org/blog/2012/03/openstack-spring-2012-conference-schedule/\n\n\nEVENTS\n\n\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n      * OpenStack Israel 2012 May 30, 2012 ? Tel Aviv-Yafo, Israel\n        http://www.meetup.com/IGTCloud/events/53864922/\n      * Open Cloud and Public Administration Jun 19, 2012 ? Bern,\n        Switzerland Call for papers/sponsors\n        http://www.ch-open.ch/index.php?id=1034\n\n\nOTHER NEWS\n\n\n      * Getting started with OpenStack on Fedora 17\n        https://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17\n      * Installing OpenStack Essex-4 on Ubuntu 12-04\n        http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin\n      * Testing Essex RC1 with Devstack and Tempest\n        http://www.joinfu.com/2012/03/testing-essex-rc1-with-devstack-and-tempest/\n      * Installing OpenStack on Citrix XenServer using DevStack\n        https://www.youtube.com/watch?feature=player_embedded&v=x_-MWihUqF4\n      * Screencast / Video of an Install of OpenStack Essex on Ubuntu\n        12.04 under VirtualBox\n        https://uksysadmin.wordpress.com/2012/03/28/screencast-video-of-an-install-of-openstack-essex-on-ubuntu-12-04-under-virtualbox/\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n      * Project meeting summary\n        http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-03-27-21.01.html\n\n\nCOMMUNITY STATISTICS\n\n\n      *  Activity on the main branch of OpenStack repositories, lines of\n        code added and removed per developer during week 7 of 2012 (from\n        Mon Mar 19 00:00:00 UTC 2012 to Mon March 26 00:00:00 UTC 2012)\n        \nChanges to Glance project ? week 12 2012\n        Changes to Glance project ? week 12 2012 \nChanges to Horizon project ? week 12 2012\n        Changes to Horizon project ? week 12 2012 \nChanges to Keystone project ? week 12 2012\n        Changes to Keystone project ? week 12 2012 \n\n\n\n\nChanges to Manuals project ? week 12 2012\n        Changes to Manuals project ? week 12 2012 \nChanges to Nova project ? week 12 2012\n        Changes to Nova project ? week 12 2012 \nChanges to Quantum project ? week 12 2012\n        Changes to Quantum project ? week 12 2012 \n\n\n\n\nChanges to Swift project ? week 12 2012\n        Changes to Swift project ? week 12 2012 \nChanges to Tempest project ? week 12 2012\n        Changes to Tempest project ? week 12 2012 \n\n\n\n\n\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120330/bd4192af/attachment.html>\n\n',NULL,NULL),('<1333395861.2.1386915202451.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:13:21',0,'2013-12-13 06:13:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-docs-grizzly #7','See <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/7/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise10 in workspace <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/>\nCheckout:periodic-glance-docs-grizzly / <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/> - hudson.remoting.Channel at 432184ba:precise10\nUsing strategy: Default\nLast Built Revision: Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/glance\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/glance\nCommencing build of Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\nChecking out Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\n[periodic-glance-docs-grizzly] $ /bin/bash -xe /tmp/hudson6970953501230852148.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack glance\n+ org=openstack\n+ project=glance\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack glance /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=glance\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack glance\n++ org=openstack\n++ project=glance\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack glance /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=glance\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z glance ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/glance /opt/requirements/projects.txt\nopenstack/glance\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/tools/test-requires>\nvenv inst: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/dist/glance-jenkins.periodic.glance.docs.grizzly.7.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/>\nGenerating doc/source/api/glance.api.authorization.rst\nGenerating doc/source/api/glance.api.cached_images.rst\nGenerating doc/source/api/glance.api.common.rst\nGenerating doc/source/api/glance.api.middleware.cache.rst\nGenerating doc/source/api/glance.api.middleware.cache_manage.rst\nGenerating doc/source/api/glance.api.middleware.context.rst\nGenerating doc/source/api/glance.api.middleware.version_negotiation.rst\nGenerating doc/source/api/glance.api.policy.rst\nGenerating doc/source/api/glance.api.v1.controller.rst\nGenerating doc/source/api/glance.api.v1.filters.rst\nGenerating doc/source/api/glance.api.v1.images.rst\nGenerating doc/source/api/glance.api.v1.members.rst\nGenerating doc/source/api/glance.api.v1.router.rst\nGenerating doc/source/api/glance.api.v2.image_data.rst\nGenerating doc/source/api/glance.api.v2.image_members.rst\nGenerating doc/source/api/glance.api.v2.image_tags.rst\nGenerating doc/source/api/glance.api.v2.images.rst\nGenerating doc/source/api/glance.api.v2.router.rst\nGenerating doc/source/api/glance.api.v2.schemas.rst\nGenerating doc/source/api/glance.api.versions.rst\nGenerating doc/source/api/glance.common.auth.rst\nGenerating doc/source/api/glance.common.client.rst\nGenerating doc/source/api/glance.common.config.rst\nGenerating doc/source/api/glance.common.crypt.rst\nGenerating doc/source/api/glance.common.exception.rst\nGenerating doc/source/api/glance.common.utils.rst\nGenerating doc/source/api/glance.common.wsgi.rst\nGenerating doc/source/api/glance.context.rst\nGenerating doc/source/api/glance.db.migration.rst\nGenerating doc/source/api/glance.db.simple.api.rst\nGenerating doc/source/api/glance.db.sqlalchemy.api.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.schema.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.001_add_images_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.002_add_image_properties_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.003_add_disk_format.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.004_add_checksum.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.005_size_big_integer.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.006_key_to_name.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.007_add_owner.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.008_add_image_members_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.009_add_mindisk_and_minram.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.010_default_update_at.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.011_make_mindisk_and_minram_notnull.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.012_id_to_uuid.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.013_add_protected.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.014_add_image_tags_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.015_quote_swift_credentials.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.016_add_status_image_member.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.017_quote_encrypted_swift_credentials.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.018_add_image_locations_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.019_migrate_image_locations.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.020_drop_images_table_location.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.021_set_engine_mysql_innodb.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.022_image_member_index.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migration.rst\nGenerating doc/source/api/glance.db.sqlalchemy.models.rst\nGenerating doc/source/api/glance.domain.proxy.rst\nGenerating doc/source/api/glance.gateway.rst\nGenerating doc/source/api/glance.image_cache.base.rst\nGenerating doc/source/api/glance.image_cache.cleaner.rst\nGenerating doc/source/api/glance.image_cache.client.rst\nGenerating doc/source/api/glance.image_cache.drivers.base.rst\nGenerating doc/source/api/glance.image_cache.drivers.sqlite.rst\nGenerating doc/source/api/glance.image_cache.drivers.xattr.rst\nGenerating doc/source/api/glance.image_cache.prefetcher.rst\nGenerating doc/source/api/glance.image_cache.pruner.rst\nGenerating doc/source/api/glance.notifier.notify_kombu.rst\nGenerating doc/source/api/glance.notifier.notify_log.rst\nGenerating doc/source/api/glance.notifier.notify_noop.rst\nGenerating doc/source/api/glance.notifier.notify_qpid.rst\nGenerating doc/source/api/glance.notifier.strategy.rst\nGenerating doc/source/api/glance.openstack.common.gettextutils.rst\nGenerating doc/source/api/glance.openstack.common.importutils.rst\nGenerating doc/source/api/glance.openstack.common.jsonutils.rst\nGenerating doc/source/api/glance.openstack.common.local.rst\nGenerating doc/source/api/glance.openstack.common.log.rst\nGenerating doc/source/api/glance.openstack.common.notifier.api.rst\nGenerating doc/source/api/glance.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/glance.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/glance.openstack.common.policy.rst\nGenerating doc/source/api/glance.openstack.common.setup.rst\nGenerating doc/source/api/glance.openstack.common.strutils.rst\nGenerating doc/source/api/glance.openstack.common.timeutils.rst\nGenerating doc/source/api/glance.openstack.common.uuidutils.rst\nGenerating doc/source/api/glance.openstack.common.version.rst\nGenerating doc/source/api/glance.registry.api.v1.images.rst\nGenerating doc/source/api/glance.registry.api.v1.members.rst\nGenerating doc/source/api/glance.registry.client.rst\nGenerating doc/source/api/glance.schema.rst\nGenerating doc/source/api/glance.store.base.rst\nGenerating doc/source/api/glance.store.filesystem.rst\nGenerating doc/source/api/glance.store.http.rst\nGenerating doc/source/api/glance.store.location.rst\nGenerating doc/source/api/glance.store.rbd.rst\nGenerating doc/source/api/glance.store.s3.rst\nGenerating doc/source/api/glance.store.scrubber.rst\nGenerating doc/source/api/glance.store.swift.rst\nGenerating doc/source/api/glance.tests.functional.db.base.rst\nGenerating doc/source/api/glance.tests.functional.db.test_simple.rst\nGenerating doc/source/api/glance.tests.functional.db.test_sqlalchemy.rst\nGenerating doc/source/api/glance.tests.functional.store.test_filesystem.rst\nGenerating doc/source/api/glance.tests.functional.store.test_http.rst\nGenerating doc/source/api/glance.tests.functional.store.test_s3.rst\nGenerating doc/source/api/glance.tests.functional.store.test_swift.rst\nGenerating doc/source/api/glance.tests.functional.store_utils.rst\nGenerating doc/source/api/glance.tests.functional.test_api.rst\nGenerating doc/source/api/glance.tests.functional.test_bin_glance_cache_manage.rst\nGenerating doc/source/api/glance.tests.functional.test_bin_glance_control.rst\nGenerating doc/source/api/glance.tests.functional.test_cache_middleware.rst\nGenerating doc/source/api/glance.tests.functional.test_client_exceptions.rst\nGenerating doc/source/api/glance.tests.functional.test_client_redirects.rst\nGenerating doc/source/api/glance.tests.functional.test_glance_manage.rst\nGenerating doc/source/api/glance.tests.functional.test_logging.rst\nGenerating doc/source/api/glance.tests.functional.test_scrubber.rst\nGenerating doc/source/api/glance.tests.functional.test_sqlite.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_api.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_copy_to_file.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_misc.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_multiprocessing.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_rbd.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_ssl.rst\nGenerating doc/source/api/glance.tests.functional.v2.test_images.rst\nGenerating doc/source/api/glance.tests.functional.v2.test_schemas.rst\nGenerating doc/source/api/glance.tests.stubs.rst\nGenerating doc/source/api/glance.tests.unit.api.test_common.rst\nGenerating doc/source/api/glance.tests.unit.base.rst\nGenerating doc/source/api/glance.tests.unit.common.test_client.rst\nGenerating doc/source/api/glance.tests.unit.common.test_exception.rst\nGenerating doc/source/api/glance.tests.unit.test_auth.rst\nGenerating doc/source/api/glance.tests.unit.test_cache_middleware.rst\nGenerating doc/source/api/glance.tests.unit.test_clients.rst\nGenerating doc/source/api/glance.tests.unit.test_config.rst\nGenerating doc/source/api/glance.tests.unit.test_context.rst\nGenerating doc/source/api/glance.tests.unit.test_context_middleware.rst\nGenerating doc/source/api/glance.tests.unit.test_db.rst\nGenerating doc/source/api/glance.tests.unit.test_domain.rst\nGenerating doc/source/api/glance.tests.unit.test_domain_proxy.rst\nGenerating doc/source/api/glance.tests.unit.test_filesystem_store.rst\nGenerating doc/source/api/glance.tests.unit.test_glance_replicator.rst\nGenerating doc/source/api/glance.tests.unit.test_http_store.rst\nGenerating doc/source/api/glance.tests.unit.test_image_cache.rst\nGenerating doc/source/api/glance.tests.unit.test_migrations.rst\nGenerating doc/source/api/glance.tests.unit.test_misc.rst\nGenerating doc/source/api/glance.tests.unit.test_notifier.rst\nGenerating doc/source/api/glance.tests.unit.test_policy.rst\nGenerating doc/source/api/glance.tests.unit.test_s3_store.rst\nGenerating doc/source/api/glance.tests.unit.test_schema.rst\nGenerating doc/source/api/glance.tests.unit.test_store_image.rst\nGenerating doc/source/api/glance.tests.unit.test_store_location.rst\nGenerating doc/source/api/glance.tests.unit.test_swift_store.rst\nGenerating doc/source/api/glance.tests.unit.test_utils.rst\nGenerating doc/source/api/glance.tests.unit.test_versions.rst\nGenerating doc/source/api/glance.tests.unit.test_wsgi.rst\nGenerating doc/source/api/glance.tests.unit.utils.rst\nGenerating doc/source/api/glance.tests.unit.v1.test_api.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_data_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_members_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_tags_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_images_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_schemas_resource.rst\nGenerating doc/source/api/glance.tests.utils.rst\nGenerating doc/source/api/glance.version.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-docs-grizzly/precise10\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-docs-grizzly/precise10/7\n[SCP] Copying console log.\n\n\n','<154416313.65.1386828184283.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1333419361.19747.111.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-02 19:16:01',-25200,'2012-04-03 02:16:01',NULL,'[Openstack-operators] ANN: new and better archives for OpenStack\n	mailing lists','Did you have the feeling that traffic on the dev mailing list since\nDiablo release? Well... it did!\n\nNew tool to search and retrieve messages to this and operators@ list\nwith some graphs on top:\n\nhttp://openstack.markmail.org/\n\nthanks Markmail and awesome Jason Hunter for the support.\nstef	\n\n\n',NULL,NULL),('<1333738799.2381.19.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-06 11:59:59',-25200,'2012-04-06 18:59:59',NULL,'[Openstack-operators] OpenStack Community Newsletter – April 6, 2012','OpenStack Community Newsletter ? April 6, 2012\n\nHIGHLIGHTS\n\n\n      * OpenStack Essex is ready http://www.openstack.org/Essex/\n              * Press release\n                http://www.openstack.org/projects/essex/press-release/\n              * Release notes\n                http://wiki.openstack.org/ReleaseNotes/Essex\n              * Essex Hall Of Fame\n                http://www.openstack.org/blog/2012/04/openstack-essex-hall-of-fame/\n      * The Secret History of OpenStack, the Free Cloud Software That?s\n        Changing Everything\n        http://www.wired.com/wiredenterprise/2012/04/openstack\n      * OpenStack Community Pulls It Out Of The\n        Bag http://www.openstack.org/blog/2012/04/openstack-community-pulls-it-out-of-the-bag/\n      * Ask not what OpenStack can do for you?\n        http://fnords.wordpress.com/2012/04/04/ask-not-what-openstack-can-do-for-you/\n      * There is still time to submit session proposals for OpenStack\n        Folsom Design Summit\n        https://lists.launchpad.net/openstack/msg08674.html\n      * OpenStack Spring 2012 Conference Schedule\n        http://www.openstack.org/blog/2012/03/openstack-spring-2012-conference-schedule/\n\n\nEVENTS\n\n\n      * Introduction to OpenStack and Inaugural Meetup Apr 11, 2012 ?\n        Edmonton, Alberta, Canada\n        http://www.meetup.com/Canadian-OpenStack-Users-Group/events/57906402/\n      * OpenStack Austin Meetup Apr 12, 2012 ? Austin, TX\n        http://www.meetup.com/OpenStack-Austin/events/56488672/\n      * OpenStack Spring 2012 Design Summit Apr 16 ? 18 and Conference\n        Apr 19-20 ? San Francisco, California\n        http://openstack.org/conference/\n      * OpenStack Israel 2012 May 30, 2012 ? Tel Aviv-Yafo, Israel\n        http://www.meetup.com/IGTCloud/events/53864922/\n      * Open Cloud and Public Administration Jun 19, 2012 ? Bern,\n        Switzerland Call for papers/sponsors\n        http://www.ch-open.ch/index.php?id=1034\n\n\nREPORTS FROM PAST EVENTS\n\n\n      * OpenStack Sydney Australia Meetup March 26\n        http://www.openstack.org/blog/2012/03/openstack-sydney-australia-meetup-march-26/\n      * Recap: OpenStack LA Meetup Mar\n        29 http://www.openstack.org/blog/2012/04/recap-openstack-la-meetup-mar-29/\n\n\nOTHER NEWS\n\n\n      * Passing the Devstack Gate http://amo-probos.org/post/12\n      * Ushering in the OpenStack Essex\n        Release http://www.joinfu.com/2012/04/ushering-in-the-openstack-essex-release\n      * Reflecting on Essex http://www.stillhq.com/openstack/000005.html\n      * OpenStackManager 1.4 released by Wikimedia Foundation\n        http://ryandlane.com/blog/2012/04/06/openstackmanager-1-4-released/\n      * Swift State of the Project Spring 2012\n        http://programmerthoughts.com/openstack/swift-state-of-the-project-spring-2012\n      * OpenStack Wiki Recent Changes ?\n        http://wiki.openstack.org/RecentChanges\n      * Project meeting\n        summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-04-03-21.02.html\n\n\nCOMMUNITY STATISTICS\n\nTo celebrate Essex release we publish the statistics assembled by Mark\nMcLoughlin using gitdm, looking into the top 20 contributors across\nNova, Glance, Swift, Keystone, Horizon and Quantum (even if Quantum will\nbe officially part of OpenStack Folsom, not Essex):\n\n\n        Processed 3481 csets from 217 developers\n        100 employers found\n        A total of 421695 lines added, 256904 removed (delta 164791)\n        Developers with the most changesets\n        termie                     238 (6.8%)\n        Gabriel Hurley             207 (5.9%)\n        Brian Waldon               195 (5.6%)\n        Johannes Erdfelt           146 (4.2%)\n        Vishvananda Ishaya         116 (3.3%)\n        Dolph Mathews               98 (2.8%)\n        Dan Prince                  84 (2.4%)\n        Ziad Sawalha                80 (2.3%)\n        Jason K?lker               77 (2.2%)\n        Mark McLoughlin             73 (2.1%)\n        Jake Dahn                   73 (2.1%)\n        Rick Harris                 71 (2.0%)\n        Alex Meade                  70 (2.0%)\n        Trey Morris                 62 (1.8%)\n        Joe Heck                    58 (1.7%)\n        Chris Behrens               52 (1.5%)\n        Russell Bryant              50 (1.4%)\n        Eoghan Glynn                50 (1.4%)\n        Joe Gordon                  47 (1.4%)\n        Jesse Andrews               46 (1.3%)\n        Covers 54.380925% of changesets\n\n\nw00t! Congrats and thanks to those for all their hard work on Essex!\n\nThis weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120406/31f76545/attachment.html>\n\n',NULL,NULL),('<1333802576.3261987.1395337843193.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 13:50:43',-14400,'2014-03-20 17:50:43',NULL,'[openstack-dev] [Nova] Updates to Juno blueprint review process','IMHO, I feel like many of the things in the \"Implementation\" section should just be in the\nlaunchpad BP, and not in the git-tracked spec.  While I think that the idea of having\nthe BP in Gerrit is a great idea, I feel like the details of the \"Implementation\" section\n(assignee, etc) will lead to \"trivial\" changes that will be a burden on the people who need\nto approve changes and will distract from \"substantial\" changes (changes to the design parts\nof the blueprint, etc).\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Thursday, March 20, 2014 11:49:37 AM\nSubject: [openstack-dev] [Nova] Updates to Juno blueprint review process\n\nWe recently discussed the idea of using gerrit to review blueprint\nspecifications [1].  There was a lot of support for the idea so we have\nproceeded with putting this together before the start of the Juno\ndevelopment cycle.\n\nWe now have a new project set up, openstack/nova-specs.  You submit\nchanges to it just like any other project in gerrit.  Find the README\nand a template for specifications here:\n\n  http://git.openstack.org/cgit/openstack/nova-specs/tree/README.rst\n\n  http://git.openstack.org/cgit/openstack/nova-specs/tree/template.rst\n\nThe blueprint process wiki page has also been updated to reflect that we\nwill be using this for Nova:\n\n  https://wiki.openstack.org/wiki/Blueprints#Nova\n\nNote that *all* Juno blueprints, including ones that were previously\napproved, must go through this new process.  This will help ensure that\nblueprints previously approved still make sense, as well as ensure that\nall Juno specs follow a more complete and consistent format.\n\nBefore the flood of spec reviews start, we would really like to get\nfeedback on the content of the spec template.  It includes things like\n\"deployer impact\" which could use more input.  Feel free to provide\nfeedback on list, or just suggest updates via proposed changes in gerrit.\n\nI suspect this process to evolve a bit throughout Juno, but I\'m very\nexcited about the positive impact it is likely to have on our overall\nresult.\n\nThanks!\n\n[1]\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<532B0E11.2040006@redhat.com>',NULL),('<1333898189.28263.YahooMailNeo@web122302.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/fits',NULL,'2012-04-08 08:16:29',-25200,'2012-04-08 15:16:29',NULL,'[Fits]  It\'s time to answer this question...','What does it mean to be OpenStack?\n\n\nKristen Eisenberg\nBillige Fl?ge\nMarketing GmbH\nEmanuelstr. 3,\n10317 Berlin\nDeutschland\nTelefon: +49 (33)\n5310967\nEmail:\nutebachmeier at\ngmail.com\nSite:\nhttp://flug.airego.de\n- Billige Fl?ge vergleichen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/fits/attachments/20120408/c2909301/attachment.html>\n\n',NULL,NULL),('<1334181138.26500.148.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-11 14:52:18',-25200,'2012-04-11 21:52:18',NULL,'[Openstack-operators] [Openstack] Health & Monitoring Blueprints','On Wed, 2012-04-11 at 14:03 -0700, Matt Joyce wrote:\n> Problem of course is many operators aren\'t on the design summit\n> contributor list ( ala don\'t have codes to get into it ) and if it\'s\n> later it\'s 500 USD to attend. \n\nThere will be over 400 people at the summit, not all of them are\ndevelopers. I expect lots of operators/users have a representation\nthere. Will there be enough to justify having this discussion there? I\ndon\'t know but we can try.\n\nOn Wed, 2012-04-11 at 17:16 -0400, Duncan McGreggor wrote:\n> That\'s a really good point. In the post-conference conversations that\n> deal with attendance policy, this should be kept in mind.\n\nWe probably should set a date for a post-mortem discussion, after the\nconference. I\'m quite sure I\'ll take a few days off after April 20,\nmaybe have a couple of live feedback sessions in the first week of May\nwould work?\n\n> In lieu of not being able to attend in person, keep in mind the\n> live-casting that will be done, \n\n\nWe\'re not yet sure to be able to offer this. Wait for an official\ncommunication.\n\n> in combination with IRC channels. \n\nThis we can do: use IRC but there will be only one projector in the\nrooms, not two like at UDS. Each track leader can decide how to use it\n(for IRC or something else).\n\nSince you are already familiar with UDS setup, would you mind setting up\nthe IRC channels for each of the rooms at the summit? This is the layout\nof the rooms and their expected usage:\n\n        Ballroom: Intro Plenary, Breakout tables, Lightning Talks\n        \n        Seacliff A+B: Design summit sessions (fishbowl setup)*\n        Seacliff C: Design summit sessions (fishbowl setup)*\n        Seacliff D: Design summit sessions (fishbowl setup)*\n        Marina: Design summit sessions (fishbowl setup)*\n        Bayview B: Design summit sessions (fishbowl setup)*\n        \n        Golden Gate: Unconference room (theater setup)*\n        Bayview A: Developer\'s lounge\n\nThe association between rooms+track will be published soon, once the\nrevisions on summit.openstack.org are completed.\n\nCheers,\nstef\n\n\n','<CAP_sDUHrkmbVx4K7GzpW3cOB6ObyVG7Hwh10WpsmzdJ4BOfWxQ@mail.gmail.com>',NULL),('<1334238381.60448588@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-04-12 09:46:21',-14400,'2012-04-12 13:46:21',NULL,'[OpenStack Foundation] OpenStack Foundation Update','All -- later this morning we\'re publishing the names of the companies that signed the framework acknowledgement letter, and I wanted to share that info with you here first.  The blog post I\'ll be putting up shortly is included below. \n\nThe post will have lots of links (not included below) for folks who want to go back and read up on all of the history, as well as links to blog posts many of you are also posting this morning.\n\nBlog Post:\n\nWe?ve come a long way since announcing in October in Boston that we planned to create an OpenStack Foundation in 2012. We set out to solicit as much feedback as possible (and on the second day, there was a town hall) and to participate in as many open forums as possible (mailing lists, webinars, meetups, and in person meetings).\n\nAt the start of the process, Jonathan Bryce and I spent the first couple of months learning as much as we could about successful open source foundations, like the ASF, Eclipse, and the Linux Foundation, reading foundation meeting minutes into the wee hours of the morning. We also talked to a lot of lawyers to get advice on legal structures, and received feedback from many of the folks in the community. We entered 2012 with a heck of a lot more knowledge and a good sense of what proposals to put forward (borrowing heavily from these amazing trailblazers before us!) that would best fit the ?OpenStack Way.?\n\nSince then we?ve had active mailing list discussions, held several webinars, meetups, and published a ton of stuff on the wiki, culminating in a Mission, Structure, and Funding Model that stay true to our values as a community, including:\n\n    An open development process that is driven by technical meritocracy\n\n    Making significant investments in community building and driving awareness and adoption\n\n    Encouraging the development of a healthy and profitable ecosystem of companies powered by OpenStack\n\nLast month, as that framework started coming into focus, we published a ?Framework Acknowledgement Letter? and asked companies to sign it if they agreed with the approach and were intent on joining as Gold or Platinum members once formed. Today are are very excited to announce that nineteen companies have signed the letter:\n\n    Platinum: AT&T, Canonical, HP, IBM, Nebula, Rackspace, Red Hat, SUSE\n    Gold: Cisco, ClearPath, Cloudscaling, Dell, DreamHost, ITRI, Mirantis, Morphlabs, NetApp, Piston Cloud Computing, Yahoo!\n\nWhat?s Next?\nWe are now forming a Drafting Committee, to take the framework and turn it into legal documents, with the help of legal resources from the above companies. The Drafting Committee process and timeline is outlined on the wiki, and they will be publishing drafts for community review & input, with a goal of getting to a final draft in Q3. The committee will not be making decisions in a vacuum, they will be putting the framework into long form legalese for all of us to review and comment.\n\nI don?t think it?s a stretch to suggest that cloud computing will one day power our global economy, and that means there is a lot at stake. Seeing the caliber of companies putting serious resources into making OpenStack successful, who all believe deeply in the open development model, I am more optimistic than ever it will be an open future, powered by OpenStack.\n\nMark\n@sparkycollier\n\n\n\n',NULL,NULL),('<1334250696.4455.5.camel@mattone-E6420>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-04-12 10:11:36',-25200,'2012-04-12 17:11:36',NULL,'[Openstack-operators] Remote participation from Design Summit (and\n conference) was (Re: [Openstack] Health & Monitoring Blueprints)','On Wed, 2012-04-11 at 23:13 -0400, Duncan McGreggor wrote:\n> The following channels have been created on Freenode and are\n> registered.\n> \n> #osds-ballroom\n> #osds-seacliff-a-b\n> #osds-seacliff-c\n> #osds-seacliff-d\n> #osds-marina\n> #osds-bayview-a\n> #osds-bayview-b\n> #osds-golden-gate\n> \n> Each channel is also getting logged, viewable via HTTP here:\n>   http://irclogs.osds.cogitat.io/\n> \nAwesome, thank you Duncan. \n\nWe have also (thanks to Cisco) https://openstack.webex.com/ that we can\nuse to stream audio from the rooms. Before we sing our happy song,\nthough, we need to jump a few hoops:\n\n- test that Webex actually runs on the Ubuntu machines contributed by\nZareason\n- configure the 8 machines\n- prepare all the Webex events/meetings\n- update the Summit sessions adding the link to the Webex meetings\n- install the machines at the conference venue (on Sunday afternoon)\n- hope things work well on Monday\n\nI need volunteers to make all these things happen. Sunday afternoon hand\nwork especially. Contact me in private, please, if you have experience\nwith Webex, have an Ubuntu 11.04 machine for testing purposes and will\nbe in San Francisco on Sunday afternoon to help setup the rooms.\n\nthanks,\nstef\n\n\n','<CAG_87O=_DA4cVYHWHzC3gUPYcH5_HCm7PQWfZCmTzQqqODV7KA@mail.gmail.com>',NULL),('<1334273435.654016.1402583576581.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 16:32:56',7200,'2014-06-12 14:32:56',NULL,'[openstack-dev] Import errors in tests are not reported in python\n	2.7','Hi all,\n\nI don\'t know if it\'s a know issue or not, but I noticed on one of my patch (https://review.openstack.org/#/c/99648/) that the 2.7 gate was passing whereas the 2.6 is failing because of import errors. It seems to be a problem related to the difference in the discover module, so presumably an issue in testtools. The problem appears locally when using tox, so it\'s fairly annoying not to be able to trust the test result.\n\nThanks,\n\n-- \nThomas\n\n\n','<1712417366.651720.1402583074642.JavaMail.zimbra@enovance.com>',NULL),('<1334836762.38.1378361932206.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-05 06:18:52',0,'2013-09-05 06:18:52',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #19','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 1169 lines...]\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.22\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_api.TestApi.test_ordered_images\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1030, in test_ordered_images\n    self.assertEqual(response.status, 200)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 500 != 200\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 102.33 secs:\n    28.64    TestScrubber.test_scrubber_app\n    22.13    TestScrubber.test_delayed_delete\n    18.43    TestRootApi.test_version_configurations\n    17.00    TestBinGlanceCacheManage.test_queue\n    16.11    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1101 tests in 777.676s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.19\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KrWTw0HjxD\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/19/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-2/19\n[SCP] Copying console log.\n\n\n','<1863787882.26.1378275042072.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1335136480.78.1360217794997.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-07 06:16:34',0,'2013-02-07 06:16:34',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #129','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/129/>\n\n\n\n','<1047784310.68.1360135886109.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1335295555.23301479.1370969644527.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 12:54:04',-14400,'2013-06-11 16:54:04',NULL,'[openstack-qa] Use Mock OpenStack instead of real one\n	on	the	tempest gate','No, I do not want.\n\nI just wanted to point out, possible consequence if we are following some ideas consistently.\n\n----- Original Message -----\nFrom: \"Daryl Walleck\" <daryl.walleck at RACKSPACE.COM>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Tuesday, June 11, 2013 6:47:50 PM\nSubject: Re: [openstack-qa] Use Mock OpenStack instead of real one on	the	tempest gate\n\nTempest is a functional/system level test suite, which is meant to run end to end. If you wanted to run against mocks, why not just improve the existing unit/mocked integration tests per project? It\'s not that you can\'t mock these APIs (we\'ve been experimenting with HTTPretty for testing of CloudCafe itself this way with some success), but it goes against the charter of what Tempest itself should be doing.\n\nDaryl\n________________________________________\nFrom: Attila Fazekas [afazekas at redhat.com]\nSent: Tuesday, June 11, 2013 11:40 AM\nTo: All Things QA.\nSubject: [openstack-qa] Use Mock OpenStack instead of real one on the   tempest gate\n\nThe usual unit test rules consequences in real life environment is\nhttp://en.wikipedia.org/wiki/Isolated_system.\n\nThe easiest way to avoid this, Is not having real environment on the tempest-devstack gate,\njust using mock objects.\n\nBenefits of this:\n - We do not have non-deterministic test responses\n - Tests will be able to run in parallel easily\n - ;)\n\n\nUsing computer emulator/simulator:\n - The starting parameters should be the same all time (CMOS data..)\n - The simulated HW interrupts will always happen at the \"same time\". (Preventing all true random functionality)\n - The host system load will not have effect to the system\n - The simplest model is ~10 times slower than a real VM,\n   the more precise models can be 10^20 times slower or more.\n   The simplest model is not enough for low level system code testing in many cases.\n\n\nThe Vertically scaled test cases are the most riskiest way of extending tempest performance,\non devstack-tempest gate.\n\n - The admins can observer and manipulate more than just basic user.\n - The race conditions issues will be triggered more frequently.\n - Smarter withebox test May not be able to operate properly\n - Figuring out what was the real issue, will be more difficult.\n\nhorizontal scalability does not have the above issues.\n\nThe additional consequences of multiprocessing:\n - We (will) have test cases which are not able run in parallel by nature.\n - We need to create dedicated gate jobs or periodic jobs for them.\n  (It is an another test case selection topic)\n\n\nBTW: The stress tests should get a periodic job, as soon as the nova is logging properly.\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C6951B64A@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1335827554.586230016@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-04-30 19:12:34',-14400,'2012-04-30 23:12:34',NULL,'[OpenStack Foundation] OpenStack Foundation Bylaws first draft\n	published','Today the first draft of the Bylaws for the OpenStack Foundation were published on the wiki here: http://wiki.openstack.org/Governance/Foundation/Bylaws, per the process detailed on the wiki: http://wiki.openstack.org/Governance/Foundation/DraftingCommitteeProcess\n\nThe goal with the first draft was to take a critical step towards putting the structure (http://wiki.openstack.org/Governance/Foundation/Structure) and mission (http://wiki.openstack.org/Governance/Foundation/Mission) defined previously into long form legal documents, which we will use to establish the foundation this year.  There are still some gaps to fill in, but I think we are off to a strong start.  \n\nSome of the legal language maybe be a bit difficult to parse for those of us who aren\'t lawyers, so when it doubt please ask questions.  One piece of advice:  read the whole thing before responding.  There are places where you may have a question that is answered later on in the document.  For example, when you read that the initial elections for Gold director is in January 2013 and wonder why (article II, section 5), you\'ll find out later (spoiler!) that there is actually an \"interim election\" to get us through the end of 2012 (article VII, section 2). \n\nSome of the mechanics of the initial boot strap phase are the hardest to articulate, and I want to personally thank Alice King for doing the hard work of getting this first draft written to give us a strong starting point. \n\nIf these are details you care deeply about, please review the draft and get involved!\n\nMark Collier\n@sparkycollier\ncell:  512-791-0356\n\n\n',NULL,NULL),('<1335877366.29.1374473704470.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-22 06:15:04',0,'2013-07-22 06:15:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #103','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/103/>\n\n\n\n','<985586303.23.1374387312787.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1336255144.29356119.1385721802435.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-29 05:43:22',-18000,'2013-11-29 10:43:22',NULL,'[Openstack] Ceilometer network and disk Mb/s measurements','\nHi Nick,\n\nI\'m planning to add rate-per-second meters deriving from the\ncumulative disk and network meters:\n\n  https://blueprints.launchpad.net/ceilometer/+spec/rates-derived-from-cumulative\n\nHowever, the intent is to average these over the polling period,\nwhich typically would be in the range 60s to 600s, and not to\nincur the cost of sub-second hypervisor polling. \n\nCheers,\nEoghan\n\n----- Original Message -----\n> Hi,\n> \n> Well, that is the problem exactly - I need to get info every second to track\n> traffic bursts, i.e. depth of precision should be on seconds level. So, in\n> my case I`ll have to either poll it every second - or approximate it by\n> computing an average?\n> \n> Thanks a lot for your answers!\n> \n> NM\n> --\n> Nick Maslov\n> Sent with Airmail\n> \n> \n> \n> On November 29, 2013 at 11:47:50 AM, Julien Danjou ( julien at danjou.info )\n> wrote:\n> \n> \n> On Fri, Nov 29 2013, Nick Maslov wrote:\n> \n> Hi Nick,\n> \n> > How do you think, is it a right way to meter such data with ceilometer? I\n> > mean, such statistics should be transferred to collector each second, and\n> > in\n> > case of >1000 VM`s can easily bring down database. How do you think?\n> \n> You don\'t _have to_ poll every seconds, you can poll every minute and\n> compute an average. That really depends on what precision you need.\n> \n> You can do the same things with the existing samples provided by\n> Ceilometer.\n> \n> --\n> Julien Danjou\n> /* Free Software hacker * independent consultant\n> http://julien.danjou.info */\n> \n> - signature.asc, 851 bytes\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n','<etPan.529867f7.ded7263.100d@mbp>',NULL),('<133645499.19505.1392604622821.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 10:37:01',28800,'2014-02-17 02:37:01',NULL,'[openstack-dev] [nova] Should we limit the disk IO\n	bandwidth	in	copy_image while creating new instance?','Hi sahid, \nI have tested `scp -l xxx src dst` (local scp copy) and believe that the `-l` option is invalid in this situation,\nit seems that `-l` only valid in remote copy.\n\n\n2014-02-17\n\n\n\nWangpan\n\n\n\n????sahid <sahid.ferdjaoui at cloudwatt.com>\n?????2014-02-14 17:58\n???Re: [openstack-dev] [nova] Should we limit the disk IO bandwidth in copy_image while creating new instance?\n????\"OpenStack Development Mailing List (not for usage questions)\"<openstack-dev at lists.openstack.org>\n???\n\nIt could be a good idea but as Sylvain said how to configure this? Then, what about using scp instead of rsync for a local copy? \n\n----- Original Message ----- \nFrom: \"Wangpan\" <hzwangpan at corp.netease.com> \nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org> \nSent: Friday, February 14, 2014 4:52:20 AM \nSubject: [openstack-dev] [nova] Should we limit the disk IO bandwidth in    copy_image while creating new instance? \n\nCurrently nova doesn\'t limit the disk IO bandwidth in copy_image() method while creating a new instance, so the other instances on this host may be affected by this high disk IO consuming operation, and some time-sensitive business(e.g RDS instance with heartbeat) may be switched between master and slave. \n\nSo can we use the `rsync --bwlimit=${bandwidth} src dst` command instead of `cp src dst` while copy_image in create_image() of libvirt driver, the remote image copy operation also can be limited by `rsync --bwlimit=${bandwidth}` or `scp -l=${bandwidth}`, this parameter ${bandwidth} can be a new configuration in nova.conf which allow cloud admin to config it, it\'s default value is 0 which means no limitation, then the instances on this host will be not affected while a new instance with not cached image is creating. \n\nthe example codes: \nnova/virt/libvit/utils.py: \ndiff --git a/nova/virt/libvirt/utils.py b/nova/virt/libvirt/utils.py \nindex e926d3d..5d7c935 100644 \n--- a/nova/virt/libvirt/utils.py \n+++ b/nova/virt/libvirt/utils.py \n@@ -473,7 +473,10 @@ def copy_image(src, dest, host=None): \n         # sparse files.  I.E. holes will not be written to DEST, \n         # rather recreated efficiently.  In addition, since \n         # coreutils 8.11, holes can be read efficiently too. \n-        execute(\'cp\', src, dest) \n+        if CONF.mbps_in_copy_image > 0: \n+            execute(\'rsync\', \'--bwlimit=%s\' % CONF.mbps_in_copy_image * 1024, src, dest) \n+        else: \n+            execute(\'cp\', src, dest) \n     else: \n         dest = \"%s:%s\" % (host, dest) \n         # Try rsync first as that can compress and create sparse dest files. \n@@ -484,11 +487,22 @@ def copy_image(src, dest, host=None): \n             # Do a relatively light weight test first, so that we \n             # can fall back to scp, without having run out of space \n             # on the destination for example. \n-            execute(\'rsync\', \'--sparse\', \'--compress\', \'--dry-run\', src, dest) \n+            if CONF.mbps_in_copy_image > 0: \n+                execute(\'rsync\', \'--sparse\', \'--compress\', \'--dry-run\', \n+                        \'--bwlimit=%s\' % CONF.mbps_in_copy_image * 1024, src, dest) \n+            else: \n+                execute(\'rsync\', \'--sparse\', \'--compress\', \'--dry-run\', src, dest) \n         except processutils.ProcessExecutionError: \n-            execute(\'scp\', src, dest) \n+            if CONF.mbps_in_copy_image > 0: \n+                execute(\'scp\', \'-l\', \'%s\' % CONF.mbps_in_copy_image * 1024 * 8, src, dest) \n+            else: \n+                execute(\'scp\', src, dest) \n         else: \n-            execute(\'rsync\', \'--sparse\', \'--compress\', src, dest) \n+            if CONF.mbps_in_copy_image > 0: \n+                execute(\'rsync\', \'--sparse\', \'--compress\', \n+                        \'--bwlimit=%s\' % CONF.mbps_in_copy_image * 1024, src, dest) \n+            else: \n+                execute(\'rsync\', \'--sparse\', \'--compress\', src, dest) \n\n\n2014-02-14 \n\n\n\nWangpan \n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140217/f98de449/attachment.html>\n\n','<565923354.22386979.1392371926021.JavaMail.root@cloudwatt.com>',NULL),('<1336886591.24.1372227794872.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-26 06:23:14',0,'2013-06-26 06:23:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #268','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/268/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:36303\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:36303/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (10497) wsgi starting up on http://127.0.0.1:36303/\n\nnova.osapi_compute.wsgi.server: INFO: (10497) accepted (\'127.0.0.1\', 36681)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/Jun/2013 06:17:58] \"GET /v2 HTTP/1.1\" 204 216 0.001009\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-f8eb41c4-772d-43d9-b051-1c31ed022349</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (10497) accepted (\'127.0.0.1\', 36682)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa52b650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa52b650>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:36303/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-26 06:17:59 10497 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:36303/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/Jun/2013 06:17:59] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.689279\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 8ee2a4d68cea4baa8f5faa574c66a463 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:34854\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:34854/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (10497) wsgi starting up on http://127.0.0.1:34854/\n\nnova.osapi_compute.wsgi.server: INFO: (10497) accepted (\'127.0.0.1\', 34216)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/Jun/2013 06:17:59] \"GET /v2 HTTP/1.1\" 204 216 0.001006\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-5c93c727-965e-4dda-8302-82335f26453e</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (10497) accepted (\'127.0.0.1\', 34217)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7e4d110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7e4d110>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:34854/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     name)\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-26 06:18:00 10497 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:34854/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [26/Jun/2013 06:18:00] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.336602\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.45\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.xjMKgcFfLB\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/268\n[SCP] Copying console log.\n\n\n','<1554273847.21.1372141390054.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1337615030.2565.60.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-05-21 16:43:50',3600,'2012-05-21 15:43:50',NULL,'[OpenStack Foundation] OpenStack Foundation Bylaws first draft\n published','On Mon, 2012-04-30 at 19:12 -0400, Mark Collier wrote:\n> Today the first draft of the Bylaws for the OpenStack Foundation were\n> published on the wiki here:\n> http://wiki.openstack.org/Governance/Foundation/Bylaws\n\nReally nice to see these published!\n\nI like Thierry\'s comments, but I\'d also add that it would be good to see\nthe complexity of the bylaws reduced as much as possible. IMHO, they\nshould only encode those things we feel as fundamental to the working of\nthe Foundation and everything else should be changeable by a vote of the\nFoundation board. I\'d hate to see us having to call a full vote of of\nthe Foundation membership to make relatively trivial changes.\n\nIn that vein, I\'d really like to see this simplified:\n\n  Article VIII, Section 1. Apache License and CLA. The Project shall not\n  accept contributions of software code unless such contribution is made\n  on the terms of the Apache 2.0 license, and the contributor has\n  executed the applicable Contributor License Agreement attached as\n  Appendix 4. The Board may adopt additional contributor license\n  agreements as may be appropriate to secure a license on the same terms\n  as stated in the Contributor License Agreements attached on Appendix 4\n  from entities other than those covered by those Contributor License\n  Agreements, or by contributors in non -United States jurisdictions.\n\nTo something like:\n\n  Article VIII, Section 1. Apache License. The Project shall only accept\n  contributions of software code where such contribution is made under \n  the terms of the Apache License 2.0. The Board may adopt whatever \n  contribution process it deems necessary to ensure the correct \n  licensing of contributions.\n\ni.e. please let\'s not make it so difficult to move from the CLA process\nto something like the kernel\'s Signed-off-by process as discussed\npreviously:\n\n  https://lists.launchpad.net/openstack/msg06639.html\n\n  > This is the one area that some form of \"contributor agreement\" makes\n  > sense to me - requiring the contributor to explicitly make their\n  > licensing intent clear.\n  > \n  > Simply adding Signed-off-by: to a commit message would be my\n  > preferred way of doing it, but do you think that helps clarify the\n  > intent or even whether such clarification is useful?\n\n  I like the Linux kernel approach (Signed-off-by requirement with a\n  brief but explicit explanation of what that actually means [the\n  \"Developer Certificate of Origin\"] in the patch-submission\n  documentation in the kernel source tree[1]). I\'m known for voicing\n  skepticism about contributor agreements but I\'ve recommended use of\n  \"signed-off-by\" to a number of projects.\n\n\nI do think a change like this needs debate and proper consideration, but\nI trust the board will be perfectly capable of doing this with the help\nof the Legal Committee.\n\nTo me, it\'s a perfect example of what we should omit from the bylaws.\nYes, by all means require the Apache License, but why require a CLA?\nEspecially since changing the clause invokes this:\n\n  (i) A motion to amend Article VIII (Intellectual Property Policy)\n  shall be adopted only if approved by each of the following: (A) a\n  two-thirds (2/3)vote of the Platinum Membership, (B) a two-thirds\n  (2/3) vote of the Gold Membership, and (C) a majority vote of the\n  Individual Membership in which at least twenty five percent (25%) of\n  the Individual Membership participates.\n\nCheers,\nMark.\n\n\n','<1335827554.586230016@emailsrvr.com>',NULL),('<1337770910.13677.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-23 04:01:50',-25200,'2012-05-23 11:01:50',NULL,'[Openstack-operators] About OpenStack','Hi all,\n\nOpenStack is completely new to me.? Would its function be only limited to sharing files, such as DropBox, UbuntuOne etc?? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120523/92632eb7/attachment.html>\n\n',NULL,NULL),('<1337772292.16541.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-23 04:24:52',-25200,'2012-05-23 11:24:52',NULL,'[Openstack-operators] About OpenStack','hi Vivek,\n\nThanks for your link.\n\nIf I\'m NOT wrong, OpenStack is service-type cloud.? Do I need 2 physical PCs to test OpenStack?\n\nI have 2 Virtual PCs, one running VirtualBox and another KVM.? Before I have tested Ubuntu Enterprise Cloud on VirtualBox without success because it needs 2 physical PCs.? Can I test OpenStack on VMs of KVM?\n\nTIA\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, May 23, 2012 7:08 PM\n>Subject: Re: [Openstack-operators] About OpenStack\n> \n>\n>Hi Satimis,\n>\n>Please find below the link it is very old and need to update but give you some overview.\n>\n>http://vivekraghuwanshi.wordpress.com/openstack-and-its-component/\n>\n>\n>On Wed, May 23, 2012 at 4:31 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi all,\n>>\n>>\n>>OpenStack is completely new to me.? Would its function be only limited to sharing files, such as DropBox, UbuntuOne etc?? TIA\n>>\n>>\n>>B.R.\n>>Stephen L\n>>_______________________________________________\n>>Openstack-operators mailing list\n>>Openstack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>-- \n>ViVek Raghuwanshi\n>Mobile -+91-09595950504\n>? ? ? ? ? ? \n>Skype - vivek_raghuwanshi\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120523/76907bb6/attachment.html>\n\n','<CAP68xYnaFAPqw=QVvN66RU1Ze7PcFMycHWpCVtLohDYL9+7Faw@mail.gmail.com>',NULL),('<1337774292.62078.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-23 04:58:12',-25200,'2012-05-23 11:58:12',NULL,'[Openstack-operators] About OpenStack','H Vivek,\n\nThanks for your further advice.\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, May 23, 2012 7:44 PM\n>Subject: Re: [Openstack-operators] About OpenStack\n> \n>\n>\n>\n>\n>On Wed, May 23, 2012 at 4:54 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>hi Vivek,\n>>\n>>\n>>Thanks for your link.\n>>\n>>\n>>If I\'m NOT wrong, OpenStack is service-type cloud.? Do I need 2 physical PCs to test OpenStack?\n>>\n>\n>Openstack is a IaaS Type cloud\n>You can test openstack on vm and use pre build instances to test it.\n>\n>\n>>I have 2 Virtual PCs, one running VirtualBox and another KVM.? Before I have tested Ubuntu Enterprise Cloud on VirtualBox without success because it needs 2 physical PCs.? Can I test OpenStack on VMs of KVM?\n>>\n>>TIA\n>>\n>>B.R.\n>>Stephen L\n>>\n>>\n>>\n>>>________________________________\n>>> From: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Wednesday, May 23, 2012 7:08 PM\n>>>Subject: Re: [Openstack-operators] About OpenStack\n>>> \n>>>\n>>>\n>>>Hi Satimis,\n>>>\n>>>Please find below the link it is very old and need to update but give you some overview.\n>>>\n>>>http://vivekraghuwanshi.wordpress.com/openstack-and-its-component/\n>>>\n>>>\n>>>On Wed, May 23, 2012 at 4:31 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>>>\n>>>Hi all,\n>>>>\n>>>>\n>>>>OpenStack is completely new to me.? Would its function be only limited to sharing files, such as DropBox, UbuntuOne etc?? TIA\n>>>>\n>>>>\n>>>>B.R.\n>>>>Stephen L\n>>>>_______________________________________________\n>>>>Openstack-operators mailing list\n>>>>Openstack-operators at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>\n>>>>\n>>>\n>>>\n>>>-- \n>>>ViVek Raghuwanshi\n>>>Mobile -+91-09595950504\n>>>? ? ? ? ? ? \n>>>Skype - vivek_raghuwanshi\n>>>\n>>>\n>>>\n>>>\n>>>\n>\n>\n>-- \n>ViVek Raghuwanshi\n>Mobile -+91-09595950504\n>? ? ? ? ? ? \n>Skype - vivek_raghuwanshi\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120523/46c9c040/attachment.html>\n\n','<CAP68xYkcrE-ejgmW-nZjMkqO+bC3+OcMGzdeB0ZTpm7PMz7ziw@mail.gmail.com>',NULL),('<1337774651.2606.YahooMailNeo@web125105.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-23 05:04:11',-25200,'2012-05-23 12:04:11',NULL,'[Openstack-operators] About OpenStack','Hi Frederik,\n\nThanks for your advice.\n\nThen OpenStack doesn\'t need LXC to run ?? For KVM, the hypervisor is build into the Linux kernel.? But VirtualBox is NOT.\n\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Frederik Van Hecke <frederik at cluttr.be>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>; \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, May 23, 2012 7:32 PM\n>Subject: Re: [Openstack-operators] About OpenStack\n> \n>\n>Hi Stephen,\n>\n>\n>You could play around with OpenStack in VirtualBox or KVM if you like.\n>You could have a look at the devstack.org scripts, which would get you going in no time.\n>(more specifically this one:?http://devstack.org/guides/single-vm.html seems appropriate)\n>\n>\n>If you want to do a full deployment yourself, have a look here:\n>http://docs.openstack.org/trunk/openstack-compute/install/content/\n>\n>\n>If you\'d want to do a Swift deployment, you could have a look here:\n>http://swift.openstack.org/howto_installmultinode.html\n>\n>(you can use VirtualBox / KVM machines to play with swift)\n>\n>\n>\n>\n>\n>Kind regards,\n>Frederik Van Hecke\n>\n>\n>T:??+32487733713\n>E:??frederik at cluttr.be\n>W:?www.cluttr.be\n>\n>\n>\n>\n>\n>\n>This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s)named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation.\n>\n>\n>\n>On Wed, May 23, 2012 at 1:24 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>hi Vivek,\n>>\n>>\n>>Thanks for your link.\n>>\n>>\n>>If I\'m NOT wrong, OpenStack is service-type cloud.? Do I need 2 physical PCs to test OpenStack?\n>>\n>>I have 2 Virtual PCs, one running VirtualBox and another KVM.? Before I have tested Ubuntu Enterprise Cloud on VirtualBox without success because it needs 2 physical PCs.? Can I test OpenStack on VMs of KVM?\n>>\n>>TIA\n>>\n>>B.R.\n>>Stephen L\n>>\n>>\n>>\n>>>________________________________\n>>> From: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Wednesday, May 23, 2012 7:08 PM\n>>>Subject: Re: [Openstack-operators] About OpenStack\n>>> \n>>>\n>>>\n>>>Hi Satimis,\n>>>\n>>>Please find below the link it is very old and need to update but give you some overview.\n>>>\n>>>http://vivekraghuwanshi.wordpress.com/openstack-and-its-component/\n>>>\n>>>\n>>>On Wed, May 23, 2012 at 4:31 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>>>\n>>>Hi all,\n>>>>\n>>>>\n>>>>OpenStack is completely new to me.? Would its function be only limited to sharing files, such as DropBox, UbuntuOne etc?? TIA\n>>>>\n>>>>\n>>>>B.R.\n>>>>Stephen L\n>>>>_______________________________________________\n>>>>Openstack-operators mailing list\n>>>>Openstack-operators at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>\n>>>>\n>>>\n>>>\n>>>-- \n>>>ViVek Raghuwanshi\n>>>Mobile -+91-09595950504\n>>>? ? ? ? ? ? \n>>>Skype - vivek_raghuwanshi\n>>>\n>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Openstack-operators mailing list\n>>Openstack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120523/b05651a3/attachment.html>\n\n','<CADpnJWQ4QO1OOW1tdPuENRb+iwZ2geavviibEt1=RnUgLP5tFQ@mail.gmail.com>',NULL),('<1337791558.47240.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-23 09:45:58',-25200,'2012-05-23 16:45:58',NULL,'[Openstack-operators] About OpenStack','Hi Kevin,\n\nLot of thanks for your demo.? It eases my work.\n\nI have 2 Virtual PCs, both for testing.? One of them is running VirtualBox and another KVM+qemu.\n\nI\'ll clean some space on VirtualBox for the testing.? It is now only about 150G space available.? I can increase the space to 200G.? Would it be sufficient?.? The KVM+qemu box is almost full.\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Kevin Jackson <kevin at linuxservices.co.uk>\n>To: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, May 23, 2012 8:07 PM\n>Subject: Re: [Openstack-operators] About OpenStack\n> \n>\n>Hi Stephen,When you get to the configuration of Nova (Compute) there is an option to specify the hypervisor.\n>Running OpenStack under VirtualBox is not a problem. ?You just end up with using software emulated virtualization using qemu.\n>\n>\n>Shameless plug but see?http://uksysadmin.wordpress.com/2012/03/28/screencast-video-of-an-install-of-openstack-essex-on-ubuntu-12-04-under-virtualbox/ for what sounds like what you want to achieve.\n>\n>\n>Cheers,\n>\n>\n>Kev\n>\n>\n>On 23 May 2012 13:04, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi Frederik,\n>>\n>>\n>>Thanks for your advice.\n>>\n>>\n>>Then OpenStack doesn\'t need LXC to run ?? For KVM, the hypervisor is build into the Linux kernel.? But VirtualBox is NOT.\n>>\n>>\n>>\n>>B.R.\n>>Stephen L\n>>\n>>\n>>\n>>>________________________________\n>>> \n>\n>-- \n>Kevin Jackson\n>@itarchitectkev\n>\n>_______________________________________________\n>Openstack-operators mailing list\n>Openstack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120523/feb499ec/attachment-0001.html>\n\n','<CACbLkcmsL1pwC=q4ANVcN25i5h8TXZ3m17YFMntWQx1T2YUpJQ@mail.gmail.com>',NULL),('<1337848061.18033.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-24 01:27:41',-25200,'2012-05-24 08:27:41',NULL,'[Openstack-operators] About NIC','Hi all,\n\nHost - Debian 6.0\nGuest - Ubuntu 12.04\nVirtualizer - KVM+qemu\nRAM 4G\nCPU AMD Phenom II X2\n\nI\'ll follow;\nhttps://help.ubuntu.com/12.04/serverguide/ubuntucloud.html\n\nto install OpenStack on the guest.? However I have only one NIC, eth0.? Would it be a problem?\n\nIf YES, please advise how to solve the problem.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120524/f16192ab/attachment.html>\n\n',NULL,NULL),('<1337861760.169.1366092425688.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-16 06:07:05',0,'2013-04-16 06:07:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #6','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/6/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-16 06:07:01    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-16 06:07:01,424 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-16 06:07:01,425 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-16 06:07:01,426 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,427 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,428 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-16 06:07:01,429 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-16 06:07:01,430 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-16 06:07:01  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-16 06:07:01,430 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-16 06:07:01    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-16 06:07:01,432 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,438 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.438083\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.438083\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01,439 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,440 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,441 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,443 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01,444 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.443148\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.443148\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01,445 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,446 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,447 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-16 06:07:01,448 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,449 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,451 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01,452 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.450807\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.450807\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01,453 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,454 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,455 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-16 06:07:01,456 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,457 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,459 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01,460 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.459083\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.459083\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01,461 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,462 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,463 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-16 06:07:01,464 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,465 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,466 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-16 06:07:01,468 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-16 06:07:01,469 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.468128\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-16T06:07:01.468128\', resource_metadata={}) from 0 transformer\n2013-04-16 06:07:01,470 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,471 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01,472 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-16 06:07:01,472 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-16 06:07:01,473 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-16 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.614s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.6\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a47.g4793577\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a314.g36b1038\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Xgdsv7302W\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/6\n[SCP] Copying console log.\n\n\n','<108650400.142.1366006033881.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1337d664.17bd5.14572fa87d3.Coremail.magazine.lihuiba@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-18 11:56:32',28800,'2014-04-18 03:56:32',NULL,'[openstack-dev] [Nova][blueprint] Accelerate the booting\n process of a number of vms via VMThunder','> - _some_ libvirt drivers already have image caching. I am unsure if\n>all of them do, I\'d have to check.\n \'$instances_path/_base\' is used to cache images downloaded fromglance, in file-level. While VMThunder employs find-grained block-level cacheing, for volumes served by cinder.\n\n> - we already have blueprints for better support of glance multiple\n>image locations, it might be better to extend that work than to do\n>something completely separate.\nIs there a cinder multiple volume locations? We are considering to\nsupport something like that.\n\n> - the xen driver already does bittorrent image delivery IIRC, you\n>could take a look at how that do that.\nWe are trying to do bittorrent image delivery for libvirt, too.\n\n> - pre-caching images has been proposed for libvirt for a long time,\n>but never implemented. I think that\'s definitely something of interest\n>to deployers.\n\nWhat is pre-caching? Deploying images to compute nodes before they \nare used?\n\n\n\nHuiba Li\nNational Key Laboratory for Parallel and Distributed\nProcessing, College of Computer Science, National University of Defense\nTechnology, Changsha, Hunan Province, P.R. China\n410073\n\n\n\n\n\nAt 2014-04-18 05:19:23,\"Michael Still\" <mikal at stillhq.com> wrote:\n>If you\'d like to have a go at implementing this in nova\'s Juno\n>release, then you need to create a new-style blueprint in the\n>nova-specs repository. You can find more details about that process at\n>https://wiki.openstack.org/wiki/Blueprints#Nova\n>\n>Some initial thoughts though, some of which have already been brought up:\n>\n> - _some_ libvirt drivers already have image caching. I am unsure if\n>all of them do, I\'d have to check.\n>\n> - we already have blueprints for better support of glance multiple\n>image locations, it might be better to extend that work than to do\n>something completely separate.\n>\n> - the xen driver already does bittorrent image delivery IIRC, you\n>could take a look at how that do that.\n>\n> - pre-caching images has been proposed for libvirt for a long time,\n>but never implemented. I think that\'s definitely something of interest\n>to deployers.\n>\n>Cheers,\n>Michael\n>\n>On Wed, Apr 16, 2014 at 11:14 PM, yongquan Fu <quanyongf at gmail.com> wrote:\n>>\n>> Dear all,\n>>\n>>\n>>\n>>  We would like to present an extension to the vm-booting functionality of\n>> Nova when a number of homogeneous vms need to be launched at the same time.\n>>\n>>\n>>\n>> The motivation for our work is to increase the speed of provisioning vms for\n>> large-scale scientific computing and big data processing. In that case, we\n>> often need to boot tens and hundreds virtual machine instances at the same\n>> time.\n>>\n>>\n>>     Currently, under the Openstack, we found that creating a large number of\n>> virtual machine instances is very time-consuming. The reason is the booting\n>> procedure is a centralized operation that involve performance bottlenecks.\n>> Before a virtual machine can be actually started, OpenStack either copy the\n>> image file (swift) or attach the image volume (cinder) from storage server\n>> to compute node via network. Booting a single VM need to read a large amount\n>> of image data from the image storage server. So creating a large number of\n>> virtual machine instances would cause a significant workload on the servers.\n>> The servers become quite busy even unavailable during the deployment phase.\n>> It would consume a very long time before the whole virtual machine cluster\n>> useable.\n>>\n>>\n>>\n>>   Our extension is based on our work on vmThunder, a novel mechanism\n>> accelerating the deployment of large number virtual machine instances. It is\n>> written in Python, can be integrated with OpenStack easily. VMThunder\n>> addresses the problem described above by following improvements: on-demand\n>> transferring (network attached storage), compute node caching, P2P\n>> transferring and prefetching. VMThunder is a scalable and cost-effective\n>> accelerator for bulk provisioning of virtual machines.\n>>\n>>\n>>\n>>   We hope to receive your feedbacks. Any comments are extremely welcome.\n>> Thanks in advance.\n>>\n>>\n>>\n>> PS:\n>>\n>>\n>>\n>> VMThunder enhanced nova blueprint:\n>> https://blueprints.launchpad.net/nova/+spec/thunderboost\n>>\n>>  VMThunder standalone project: https://launchpad.net/vmthunder;\n>>\n>>  VMThunder prototype: https://github.com/lihuiba/VMThunder\n>>\n>>  VMThunder etherpad: https://etherpad.openstack.org/p/vmThunder\n>>\n>>  VMThunder portal: http://www.vmthunder.org/\n>>\n>> VMThunder paper: http://www.computer.org/csdl/trans/td/preprint/06719385.pdf\n>>\n>>\n>>\n>>   Regards\n>>\n>>\n>>\n>>   vmThunder development group\n>>\n>>   PDL\n>>\n>>   National University of Defense Technology\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>\n>-- \n>Rackspace Australia\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/ae98bdfb/attachment.html>\n\n','<CAEd1pt6nxcSS5DGRo6wohWd3E0cDhGBxGu1gfzt37JVOwBU4Yw@mail.gmail.com>',NULL),('<1338031074.64431.YahooMailNeo@web125104.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-26 04:17:54',-25200,'2012-05-26 11:17:54',NULL,'[Openstack-operators] My 1st test on OpenStack','Hi all,\n\nI\'m prepared testing OpenStack on following PC:\n\nHost??? Debian 6.0 32bit\nHD 600G\nRAM??? 4G\nVirtualizer??? KVM\n6 guests (created)??? OS Ubuntu 12.04 server 32bit, each allotted with 30G storage space\n\n\nI read;\nInstructions for a Multiple Server Swift Installation (Ubuntu)\nhttp://swift.openstack.org/howto_installmultinode.html\n\nand have following questions;\n\n1)\nWhether run all commands under \"General OS configuration and partitioning for each node\" on all nodes (6 guests)?\n\n2)\nWhether run all commands under \"Configure the Proxy node\" on the Proxy node (1st guest)?\n\n3)\nWhether run all commands under \"Configure the Storage nodes\" on all storage nodes (the remaining 5 guests)?\n\n4)\nRe: \"Adding a Proxy Server\"\nI don\'t have proxy server running on this box.? I use ISP\'s DNS instead.? Whether I need adding a Proxy Server?\nIf \"YES\" then I\'ll create another Ubuntu guest for this purpose.\n\nPls advise.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120526/04291b3c/attachment-0001.html>\n\n',NULL,NULL),('<1338043674.17216.YahooMailNeo@web125102.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-26 07:47:54',-25200,'2012-05-26 14:47:54',NULL,'[Openstack-operators] My 1st test on OpenStack','Hi judd,\n\nThanks for your advice.\n\nYour\'re correct.? This is a test, my 1st test on OpenStack, in order to learn.? This is my only spare PC available.? Eventhough for testing I\'m on way to build another desktop PC with 32G RAM running AMD 8 cores CPU.\n\n\n> \"Swift AIO\" (All In One) \nWhether you meant following document:\nSAIO - Swift All In One\nhttp://swift.openstack.org/development_saio.html\n?\n\nI still don\'t have a clear picture whether I need only ONE VM(guest) for the test.? OR I need 6 VMs?? I can create 6 new VMs without problem.\n\nFurthermore whether I need installing any package on the host which is my most concern.? I still have other VMs running, testing other projects.? I don\'t expect touching the host avoiding making mistake detrimental to other projects.\n\nPlease help.\n\nB.R.\nStephen L\n\n\n\n\n\n\n>________________________________\n> From: Judd Maltin <judd at newgoliath.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Saturday, May 26, 2012 10:06 PM\n>Subject: Re: [Openstack-operators] My 1st test on OpenStack\n> \n>\n>Hi Stephan,\n>You are very low on RAM.? This really should just be a test.\n>You don\'t need the virtual machines.? You can test Swift by putting its components on different ports (which they already are) and setting up separate object storage paths on your filesystem.? Look for \"Swift AIO\" (All In One) docs.\n>-judd\n>\n>On May 26, 2012 7:17 AM, \"Stephen Liu\" <satimis at yahoo.com> wrote:\n>>\n>> Hi all,\n>>\n>> I\'m prepared testing OpenStack on following PC:\n>>\n>> Host??? Debian 6.0 32bit\n>> HD 600G\n>> RAM??? 4G\n>> Virtualizer??? KVM\n>> 6 guests (created)??? OS Ubuntu 12.04 server 32bit, each allotted with 30G storage space\n>>\n>>\n>> I read;\n>> Instructions for a Multiple Server Swift Installation (Ubuntu)\n>> http://swift.openstack.org/howto_installmultinode.html\n>>\n>> and have following questions;\n>>\n>> 1)\n>> Whether run all commands under \"General OS configuration and partitioning for each node\" on all nodes (6 guests)?\n>>\n>> 2)\n>> Whether run all commands under \"Configure the Proxy node\" on the Proxy node (1st guest)?\n>>\n>> 3)\n>> Whether run all commands under \"Configure the Storage nodes\" on all storage nodes (the remaining 5 guests)?\n>>\n>> 4)\n>> Re: \"Adding a Proxy Server\"\n>> I don\'t have proxy server running on this box.? I use ISP\'s DNS instead.? Whether I need adding a Proxy Server?\n>> If \"YES\" then I\'ll create another Ubuntu guest for this purpose.\n>>\n>> Pls advise.? TIA\n>>\n>> B.R.\n>> Stephen L\n>>\n>> _______________________________________________\n>> Openstack-operators mailing list\n>> Openstack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120526/165358ce/attachment.html>\n\n','<CAG+ZfSC0HQRfxoLgFVhKVSsLd1_3=am4HBi5SBxGg9-_GH7Kmg@mail.gmail.com>',NULL),('<1338111708.53.1383458536923.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:02:16',0,'2013-11-03 06:02:16',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-keystone-python27-stable-folsom #48','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-folsom/48/>\n\n\n\n','<436289016.38.1383372214339.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1338305520.24739.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-29 08:32:00',-25200,'2012-05-29 15:32:00',NULL,'[Openstack-operators] About NIC','Hi all,\n\nI\'m prepared to start my 1st experiment on OpenStack according to following document;\n\nExpreimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n\nHowever it needs 3 NICs, eth0, eth1 and eth2.? But I have only ONE NIC, eth0.\n\nWhat can I do, please help.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120529/8e4859b2/attachment.html>\n\n',NULL,NULL),('<1338305828.93743.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-29 08:37:08',-25200,'2012-05-29 15:37:08',NULL,'[Openstack-operators] About NIC (resend)','Hi all,\n\nI\'m prepared to start my 1st experiment on OpenStack according to following document;\n\nExpreimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n\nHowever it needs 3 NICs, eth0, eth1 and eth2.? But I have only ONE NIC, eth0.\n\nWhat can I do, please help.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120529/ddcd8654/attachment.html>\n\n',NULL,NULL),('<1338393265.16468591.1421953793164.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 14:09:53',-18000,'2015-01-22 19:09:53',NULL,'[openstack-dev] [Telco][NFV] Meeting summary and logs - 2015-01-21','Hi all,\n\nPlease find minutes and logs from this week\'s OpenStack Telco Working Group meeting at the locations linked below:\n\n* Minutes (HTML): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.html\n* Log (HTML): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.html\n* Minutes (TXT): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.txt\n* Log (TXT): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.txt\n\nIn particular please take some time to review and comment on these use case outlines in the coming week (comments directly in the etherpads are fine):\n\n* https://etherpad.openstack.org/p/telcowg-usecase-Virtual_IMS_Core\n* https://etherpad.openstack.org/p/telcowg-usecase-VPN_Instantiation\n\nFinally, I am attending the product working group midcycle next Monday/Tuesday and on checking my return flight have realized I will not quite be back on the ground before the telco working group meeting on Wednesday the 28th. As such I need a lucky volunteer (!) to facilitate the meeting.\n\nThanks,\n\nSteve\n\n\n','<875108264.16466150.1421953427175.JavaMail.zimbra@redhat.com>',NULL),('<1338393265.16468591.1421953793164.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-22 14:09:53',-18000,'2015-01-22 19:09:53',NULL,'[Openstack-operators] [Telco][NFV] Meeting summary and logs -\n	2015-01-21','Hi all,\n\nPlease find minutes and logs from this week\'s OpenStack Telco Working Group meeting at the locations linked below:\n\n* Minutes (HTML): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.html\n* Log (HTML): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.html\n* Minutes (TXT): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.txt\n* Log (TXT): http://eavesdrop.openstack.org/meetings/telcowg/2015/telcowg.2015-01-21-22.00.log.txt\n\nIn particular please take some time to review and comment on these use case outlines in the coming week (comments directly in the etherpads are fine):\n\n* https://etherpad.openstack.org/p/telcowg-usecase-Virtual_IMS_Core\n* https://etherpad.openstack.org/p/telcowg-usecase-VPN_Instantiation\n\nFinally, I am attending the product working group midcycle next Monday/Tuesday and on checking my return flight have realized I will not quite be back on the ground before the telco working group meeting on Wednesday the 28th. As such I need a lucky volunteer (!) to facilitate the meeting.\n\nThanks,\n\nSteve\n\n\n','<875108264.16466150.1421953427175.JavaMail.zimbra@redhat.com>',NULL),('<1338452052.5.1375855343831.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-07 06:02:23',0,'2013-08-07 06:02:23',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #2','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/2/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-1192 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #1167 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-coverage] $ /bin/bash -xe /tmp/hudson5999805108887462053.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-coverage] $ /bin/bash -xe /tmp/hudson1543014279925639656.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_COVERAGE=1\n+ DEVSTACK_GATE_TEMPEST_COVERAGE=1\n+ export ZUUL_BRANCH=master\n+ ZUUL_BRANCH=master\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-1192\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-1192/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-1192/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-1192/2/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<446664141.1.1375768929185.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1338481381.16015.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-05-31 09:23:01',-25200,'2012-05-31 16:23:01',NULL,'[Openstack-operators] About NIC (resend)','Hi Everett,\n\nThanks for your advice.\n\nMy problem is \"I have only 1 NIC\", i.e. eth0.? Then what can I do with the other 2 settings eth1 and eth2?? OR just leave them there?\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Everett Toews <everett.toews at cybera.ca>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, May 30, 2012 2:16 AM\n>Subject: Re: [Openstack-operators] About NIC (resend)\n> \n>\n>Under Step 1 it reads.\n>\n>\n>Configure?VirtualBox\'s Host-Only Networks\n>start VirtualBox [on ubuntu prior to Unity it\'s in?Applications ? Accessories]\n>open?File ? Preferences ? Network?tab\n>Add?host-only netwok for?vboxnet0?? this will be the?Public?interface\n>set IP to 172.16.0.254, mask 255.255.0.0, dhcp disbaled\n>Add?host-only netwok for?vboxnet1?? this will be the?Private?(VLAN) interface\n>set IP to 11.0.0.1, mask 255.0.0.0, dhcp disbaled\n>\n>\n>Under Step 2 it reads.\n>\n>\n>Network?tab: see figure above?\n>Adapter 1: attached to NAT ? eth0 will connect here;?\n>Adapter 2: attached to Host-Only Adapter, vboxnet0 - eth1 will connect here ;\n>Adapter 3: attached to Host-Only Adapter, vboxnet1 - eth2?will connect here;\n>\n>\n>This will setup all the NICs you need in VirtualBox.\n>\n>\n>Everett\n>\n>On Tue, May 29, 2012 at 9:37 AM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi all,\n>>\n>>\n>>I\'m prepared to start my 1st experiment on OpenStack according to following document;\n>>\n>>Expreimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\n>>http://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n>>\n>>However it needs 3 NICs, eth0, eth1 and eth2.? But I have only ONE NIC, eth0.\n>>\n>>What can I do, please help.? TIA\n>>\n>>B.R.\n>>Stephen L\n>>_______________________________________________\n>>Openstack-operators mailing list\n>>Openstack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120531/ff749b5a/attachment.html>\n\n','<CAH6jzwsFZnP8Z0Hzxg_pzTA440C4oapQAU-_BPd6Dh=JnT97Fw@mail.gmail.com>',NULL),('<1338498541.564.1367475688425.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-02 06:21:28',0,'2013-05-02 06:21:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-grizzly-centos6 #2','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/2/changes>\n\nChanges:\n\n[Russell Bryant] Fix missing kernel output via VNC/Spice on boot\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-8 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/>\nCheckout:periodic-nova-python26-stable-grizzly-centos6 / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/> - hudson.remoting.Channel at 52d7384a:centos6-8\nUsing strategy: Default\nLast Built Revision: Revision c18519501af57e91deb35792c53e542116ccba64 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision a58d97502fdbab4e4416b779a6219bbe687250d6 (origin/stable/grizzly)\nChecking out Revision a58d97502fdbab4e4416b779a6219bbe687250d6 (origin/stable/grizzly)\n[periodic-nova-python26-stable-grizzly-centos6] $ /bin/bash -xe /tmp/hudson9017781084763109426.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.7qs3Ng4Wn6\n+ TMPDIR=/tmp/tmp.7qs3Ng4Wn6\n+ trap \'rm -rf /tmp/tmp.7qs3Ng4Wn6\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\ngrep: /var/log/auth.log: No such file or directory\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.centos6.2\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.centos6.2.zip>\npy26 runtests: commands[0]\npy26 runtests: commands[1]\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.7qs3Ng4Wn6/tmpExVYbZ\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.7qs3Ng4Wn6/tmp8p8YGP\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.7qs3Ng4Wn6/tmp1mPFvM\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.7qs3Ng4Wn6/tmpODTnN9\n======================================================================\nFAIL: nova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/nova/tests/test_db_api.py\",> line 2597, in test_archive_deleted_rows_fk_constraint\n    self.assertEqual(num, 1)\nMismatchError: 0 != 1\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 5539 tests in 406.250s\nFAILED (id=0, failures=2, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.centos6.2\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npyflakes==0.7.2\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-quantumclient==2.2.1\npython-subunit==0.0.11\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\ntestrepository==0.0.15\ntesttools==0.9.31\nunittest2==0.5.1\nwarlock==1.0.0\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint (subunit.RemotedTestCase)\nprocess-returncode (subunit.RemotedTestCase)\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n++ .tox/py26/bin/python .tox/py26/bin/testr list-tests\n++ sed -e 1d\n++ wc -l\n/usr/bin/python: No module named subunit\n+ foundcount=0\n++ .tox/py26/bin/python .tox/py26/bin/testr last\n++ sed -ne \'s/Ran \\([0-9]\\+\\).*tests in.*/\\1/p\'\n+ rancount=5539\n+ \'[\' 5539 -lt 0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.7qs3Ng4Wn6\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly-centos6/2\n[SCP] Copying console log.\n\n\n','<1636323055.542.1367389367230.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1338739251.92502.YahooMailNeo@web125104.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-03 09:00:51',-25200,'2012-06-03 16:00:51',NULL,'[Openstack-operators] Unable to browse openstack demo','Hi all,\n\nI followed following doc to install openstack;\n\nExpreimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n\nInstallation went through without much difficulty.? However after finish I couldn\'t connect openstack demo on host\'s browser running 172.16.0.1, \"server not found\".\n\neth0 10.0.2.15\neth1 172.16.0.1\n\nOn host terminal I can ping 172.16.0.1 but unable to ping 10.0.2.15\n\n# glance details\nFailed to show details.? Got error:\nYou are not authenticated\nDetails: 401 Unauthroized\n\nThis server could not verify that your are authrised to access the document you requested.? Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.\n\nPlease help.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120603/360a0c56/attachment.html>\n\n',NULL,NULL),('<1338862758.28202.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-04 19:19:18',-25200,'2012-06-05 02:19:18',NULL,'[Openstack-operators] About NIC (resend)','Hi Everett,\n\nThanks for your advice.\n\nNow I got it clear.? eth0, eth1, eth2 etc. are virtual NIC, NOT physical, releting to vboxnet0, vboxnet1 etc.\n\nThe tutorial;\nExperimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n\nis mostly working.? On browser I can connect the \"demo\" running http://176.16.0.1.? Still there are some minor problems, e.g.\n\n# glance details\nFailed to show details. Got error:\nYou are not authenticated.\nDetails: 401 Unauthorized\n\nThis server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.\n\nI\'m still hunting around for solution.? Can you help?? TIA\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Everett Toews <everett.toews at cybera.ca>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, June 5, 2012 4:17 AM\n>Subject: Re: [Openstack-operators] About NIC (resend)\n> \n>\n>I take it you mean you only have 1 NIC on your physical machine. That\'s okay, the NICs you\'re creating in VirtualBox according to the instructions are virtual so you can create as many as you need. You can just leave them there once you\'ve created them.\n>\n>\n>Everett\n>\n>\n>On Thu, May 31, 2012 at 10:23 AM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi Everett,\n>>\n>>\n>>Thanks for your advice.\n>>\n>>\n>>My problem is \"I have only 1 NIC\", i.e. eth0.? Then what can I do with the other 2 settings eth1 and eth2?? OR just leave them there?\n>>\n>>\n>>B.R.\n>>Stephen L\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Everett Toews <everett.toews at cybera.ca>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Wednesday, May 30, 2012 2:16 AM\n>>>Subject: Re: [Openstack-operators] About NIC (resend)\n>>> \n>>>\n>>>\n>>>Under Step 1 it reads.\n>>>\n>>>\n>>>Configure?VirtualBox\'s Host-Only Networks\n>>>start VirtualBox [on ubuntu prior to Unity it\'s in?Applications ? Accessories]\n>>>open?File ? Preferences ? Network?tab\n>>>Add?host-only netwok for?vboxnet0?? this will be the?Public?interface\n>>>set IP to 172.16.0.254, mask 255.255.0.0, dhcp disbaled\n>>>Add?host-only netwok for?vboxnet1?? this will be the?Private?(VLAN) interface\n>>>set IP to 11.0.0.1, mask 255.0.0.0, dhcp disbaled\n>>>\n>>>\n>>>Under Step 2 it reads.\n>>>\n>>>\n>>>Network?tab: see figure above?\n>>>Adapter 1: attached to NAT ? eth0 will connect here;?\n>>>Adapter 2: attached to Host-Only Adapter, vboxnet0 - eth1 will connect here ;\n>>>Adapter 3: attached to Host-Only Adapter, vboxnet1 - eth2?will connect here;\n>>>\n>>>\n>>>This will setup all the NICs you need in VirtualBox.\n>>>\n>>>\n>>>Everett\n>>>\n>>>On Tue, May 29, 2012 at 9:37 AM, Stephen Liu <satimis at yahoo.com> wrote:\n>>>\n>>>Hi all,\n>>>>\n>>>>\n>>>>I\'m prepared to start my 1st experiment on OpenStack according to following document;\n>>>>\n>>>>Expreimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\n>>>>http://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n>>>>\n>>>>However it needs 3 NICs, eth0, eth1 and eth2.? But I have only ONE NIC, eth0.\n>>>>\n>>>>What can I do, please help.? TIA\n>>>>\n>>>>B.R.\n>>>>Stephen L\n>>>>_______________________________________________\n>>>>Openstack-operators mailing list\n>>>>Openstack-operators at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120604/bfa5029c/attachment-0001.html>\n\n','<CAH6jzws5+m=ByVohM1JV=9F1Pj_vjiymJJ-bTWU-R3vAj53n=A@mail.gmail.com>',NULL),('<1338942847.94993.YahooMailNeo@web125105.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-05 17:34:07',-25200,'2012-06-06 00:34:07',NULL,'[Openstack-operators] About NIC (resend)','Hi jay,\n\n$ env | grep OS_\n\nno output\n\n-SL\n\n\n\n\n----- Original Message -----\n> From: Jay Pipes <jaypipes at gmail.com>\n> To: openstack-operators at lists.openstack.org\n> Cc: \n> Sent: Wednesday, June 6, 2012 1:39 AM\n> Subject: Re: [Openstack-operators] About NIC (resend)\n> \n> On 06/04/2012 10:19 PM, Stephen Liu wrote:\n>>  # glance details\n>>  Failed to show details. Got error:\n>>  You are not authenticated.\n>>  Details: 401 Unauthorized\n> \n> This is due to your OpenStack credentials not being authorized to connect to \n> Glance (or not being set at all! :))\n> \n> If you do:\n> \n> $ env | grep OS_\n> \n> What does it show?\n> \n> For me (after source\'ing my devstack/openrc file), I get:\n> \n> jpipes at uberbox:~/repos/devstack$ env | grep OS_\n> OS_PASSWORD=pass\n> OS_AUTH_URL=http://192.168.1.76:5000/v2.0\n> OS_USERNAME=demo\n> OS_TENANT_NAME=demo\n> \n> Best,\n> -jay\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n','<4FCE444D.8050400@gmail.com>',NULL),('<1338997107.90365.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-06 08:38:27',-25200,'2012-06-06 15:38:27',NULL,'[Openstack-operators] Problem running euca-authorize command','Hi all,\n\nOn running;\n$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0\nEC2_ACCESS_KEY environment variable must be set.\n\nopenstack at ub1204dk00:~$ euca-authorize default -P tcp -p 80 -s 0.0.0.0/0\nEC2_ACCESS_KEY environment variable must be set.\n\nWhat does it mean?? How to fix it.\n\nI couldn\'t find novarc.\n\nB.R.\nSL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120606/c191d112/attachment.html>\n\n',NULL,NULL),('<1338999233.27943.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-06 09:13:53',-25200,'2012-06-06 16:13:53',NULL,'[Openstack-operators] Problem running euca-authorize command','Hi Lorin,\n\n\nThanks for your advice.\n\n# keystone ec2-credentials-list\nExpecting authentication method via \n? either a service token, --token or env[SERVICE_TOKEN], \n? or credentials, --os_username or env[OS_USERNAME].\n\nI can\'t find euca2-admin-x509.zip.? Please help.? TIA\n\nB.R.\nSL\n\n\n\n\n>________________________________\n> From: Lorin Hochstein <lorin at nimbisservices.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Wednesday, June 6, 2012 11:59 PM\n>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n> \n>\n>Stephen:\n>\n>\n>The eucatools (e.g., euca-authorize) require that you set the EC2_ACCESS_KEY and EC2_SECRET_KEY environment variables. If you have created a tenant with keystone, you should be able to do:\n>\n>\n>keystone ec2-credentials-list\n>\n>\n>And it will tell you what the access key and secret key are.\n>\n>Take care,\n>\n>\n>Lorin\n>--\n>Lorin Hochstein\n>Lead Architect - Cloud Services\n>Nimbis Services, Inc.\n>www.nimbisservices.com\n>\n>\n>\n>\n>\n>\n>On Jun 6, 2012, at 11:38 AM, Stephen Liu wrote:\n>\n>Hi all,\n>>\n>>On running;\n>>$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0\n>>EC2_ACCESS_KEY environment variable must be set.\n>>\n>>openstack at ub1204dk00:~$ euca-authorize default -P tcp -p 80 -s 0.0.0.0/0\n>>EC2_ACCESS_KEY environment variable must be set.\n>>\n>>What does it mean?? How to fix it.\n>>\n>>I couldn\'t find novarc.\n>>\n>>B.R.\n>>SL_______________________________________________\n>>Openstack-operators mailing list\n>>Openstack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120606/f8a5f51e/attachment-0001.html>\n\n','<FF53D0C4-CD2A-45DC-84FA-B36F2E2ED915@nimbisservices.com>',NULL),('<1339000128.66580.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-06 09:28:48',-25200,'2012-06-06 16:28:48',NULL,'[Openstack-operators] Problem running euca-authorize command','H Lorin,\n\nI\'m running Essex version of OpenStack Swift on Ubuntu 12.04.? \n\nI followed;\n\nExperimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox#comment-1851\n\nto install/config it.\n\nB.R.\nSL\n\n\n\n\n\n>________________________________\n> From: Lorin Hochstein <lorin at nimbisservices.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Thursday, June 7, 2012 12:19 AM\n>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n> \n>\n>Stephen:\n>\n>\n>Which version of OpenStack are you running? Have you created users and tenants with keystone yet? ?You shouldn\'t need euca2-admin-x509.zip to do euca-authorize.\n>\n>\n>\n>Take care,\n>\n>\n>Lorin\n>--\n>Lorin Hochstein\n>Lead Architect - Cloud Services\n>Nimbis Services, Inc.\n>www.nimbisservices.com\n>\n>\n>\n>\n>\n>\n>On Jun 6, 2012, at 12:13 PM, Stephen Liu wrote:\n>\n>Hi Lorin,\n>>\n>>\n>>\n>>Thanks for your advice.\n>>\n>>\n>># keystone ec2-credentials-list\n>>Expecting authentication method via \n>>? either a service token, --token or env[SERVICE_TOKEN], \n>>? or credentials, --os_username or env[OS_USERNAME].\n>>\n>>I can\'t find euca2-admin-x509.zip.? Please help.? TIA\n>>\n>>\n>>B.R.\n>>SL\n>>\n>>\n>>\n>>>________________________________\n>>> From: Lorin Hochstein <lorin at nimbisservices.com>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Wednesday, June 6, 2012 11:59 PM\n>>>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n>>> \n>>>\n>>>Stephen:\n>>>\n>>>\n>>>The eucatools (e.g., euca-authorize) require that you set the EC2_ACCESS_KEY and EC2_SECRET_KEY environment variables. If you have created a tenant with keystone, you should be able to do:\n>>>\n>>>\n>>>keystone ec2-credentials-list\n>>>\n>>>\n>>>And it will tell you what the access key and secret key are.\n>>>\n>>>Take care,\n>>>\n>>>\n>>>Lorin\n>>>--\n>>>Lorin Hochstein\n>>>Lead Architect - Cloud Services\n>>>Nimbis Services, Inc.\n>>>www.nimbisservices.com\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Jun 6, 2012, at 11:38 AM, Stephen Liu wrote:\n>>>\n>>>Hi all,\n>>>>\n>>>>On running;\n>>>>$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0\n>>>>EC2_ACCESS_KEY environment variable must be set.\n>>>>\n>>>>openstack at ub1204dk00:~$ euca-authorize default -P tcp -p 80 -s 0.0.0.0/0\n>>>>EC2_ACCESS_KEY environment variable must be set.\n>>>>\n>>>>What does it mean?? How to fix it.\n>>>>\n>>>>I couldn\'t find novarc.\n>>>>\n>>>>B.R.\n>>>>SL_______________________________________________\n>>>>Openstack-operators mailing list\n>>>>Openstack-operators at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120606/1a0f56f0/attachment-0001.html>\n\n','<556C74E5-C831-4465-A05F-211808702269@nimbisservices.com>',NULL),('<1339001081.39674.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-06-06 09:44:41',-25200,'2012-06-06 16:44:41',NULL,'[Openstack-operators] Problem running euca-authorize command','Hi Lorin,\n\n# find / -name demorc\n/root/OpenStackInstaller/demorc\n\ndemorc is there.? \n\nAccording to the tutorial;\n....\nSetting up user environment\n\nCopy over the demorc file created in this directory to your client\nSource in the demorc file: . demorc\n\nI don\'t understand what does it mean?? Where shall I copy the original \"demorc\" to?\n\nB.R.\nSL\n\n\n\n\n>________________________________\n> From: Lorin Hochstein <lorin at nimbisservices.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Thursday, June 7, 2012 12:34 AM\n>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n> \n>\n>Stephen:\n>\n>\n>I haven\'t followed those particular instructions, but it sounds like you should have a \"demorc\" file after doing \"upload_ubuntu.sh\". Do you have that file??\n>\n>\n>If so, try doing: \"source demorc\" and then try the euca-authorize command.\n>\n>\n>You also might want to try the starter guide as an alternative:?http://docs.openstack.org/essex/openstack-compute/starter/content/\n>\n>\n>Take care,\n>\n>\n>Lorin\n>--\n>Lorin Hochstein\n>Lead Architect - Cloud Services\n>Nimbis Services, Inc.\n>www.nimbisservices.com\n>\n>\n>\n>\n>\n>\n>On Jun 6, 2012, at 12:28 PM, Stephen Liu wrote:\n>\n>H Lorin,\n>>\n>>\n>>I\'m running Essex version of OpenStack Swift on Ubuntu 12.04.? \n>>\n>>I followed;\n>>\n>>Experimenting with OpenStack Essex on Ubuntu 12.04 LTS under VirtualBox\n>>http://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox#comment-1851\n>>\n>>to install/config it.\n>>\n>>B.R.\n>>SL\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Lorin Hochstein <lorin at nimbisservices.com>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Thursday, June 7, 2012 12:19 AM\n>>>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n>>> \n>>>\n>>>Stephen:\n>>>\n>>>\n>>>Which version of OpenStack are you running? Have you created users and tenants with keystone yet? ?You shouldn\'t need euca2-admin-x509.zip to do euca-authorize.\n>>>\n>>>\n>>>\n>>>Take care,\n>>>\n>>>\n>>>Lorin\n>>>--\n>>>Lorin Hochstein\n>>>Lead Architect - Cloud Services\n>>>Nimbis Services, Inc.\n>>>www.nimbisservices.com\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Jun 6, 2012, at 12:13 PM, Stephen Liu wrote:\n>>>\n>>>Hi Lorin,\n>>>>\n>>>>\n>>>>\n>>>>Thanks for your advice.\n>>>>\n>>>>\n>>>># keystone ec2-credentials-list\n>>>>Expecting authentication method via \n>>>>? either a service token, --token or env[SERVICE_TOKEN], \n>>>>? or credentials, --os_username or env[OS_USERNAME].\n>>>>\n>>>>I can\'t find\n euca2-admin-x509.zip.? Please help.? TIA\n>>>>\n>>>>\n>>>>B.R.\n>>>>SL\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Lorin Hochstein <lorin at nimbisservices.com>\n>>>>>To: Stephen Liu <satimis at yahoo.com> \n>>>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>>>Sent: Wednesday, June 6, 2012 11:59 PM\n>>>>>Subject: Re: [Openstack-operators] Problem running euca-authorize command\n>>>>> \n>>>>>\n>>>>>Stephen:\n>>>>>\n>>>>>\n>>>>>The eucatools (e.g., euca-authorize) require that you set the EC2_ACCESS_KEY and EC2_SECRET_KEY environment variables. If you have created a tenant with keystone, you should be able to do:\n>>>>>\n>>>>>\n>>>>>keystone ec2-credentials-list\n>>>>>\n>>>>>\n>>>>>And it will tell you what the access key and secret key are.\n>>>>>\n>>>>>Take care,\n>>>>>\n>>>>>\n>>>>>Lorin\n>>>>>--\n>>>>>Lorin Hochstein\n>>>>>Lead Architect - Cloud Services\n>>>>>Nimbis Services, Inc.\n>>>>>www.nimbisservices.com\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Jun 6, 2012, at 11:38 AM, Stephen Liu wrote:\n>>>>>\n>>>>>Hi all,\n>>>>>>\n>>>>>>On running;\n>>>>>>$ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0\n>>>>>>EC2_ACCESS_KEY environment variable must be set.\n>>>>>>\n>>>>>>openstack at ub1204dk00:~$ euca-authorize default -P tcp -p 80 -s 0.0.0.0/0\n>>>>>>EC2_ACCESS_KEY environment variable must be set.\n>>>>>>\n>>>>>>What does it mean?? How to fix it.\n>>>>>>\n>>>>>>I couldn\'t find novarc.\n>>>>>>\n>>>>>>B.R.\n>>>>>>SL_______________________________________________\n>>>>>>Openstack-operators mailing list\n>>>>>>Openstack-operators at lists.openstack.org\n>>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120606/98df807e/attachment-0001.html>\n\n','<CB16B987-BC00-494E-AAA3-AF423BAF821E@nimbisservices.com>',NULL),('<1339456465.35916309.1408632762042.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 10:52:42',-14400,'2014-08-21 14:52:42',NULL,'[openstack-dev] [nova][libvirt] Non-readonly connection to\n libvirt in unit tests','FYI, the context of this is that I would like to be able to test some of the libvirt storage pool code against a live file system, as we currently test the storage pool code.  To do this, we need at least to be able to get a proper connection to a session daemon.  IMHO, since these calls aren\'t \"expensive\", so to speak, it should be fine to have them run against a real libvirt.\n\n> So If we require libvirt-python for tests and that requires\n> libvirt-bin, what\'s stopping us from just removing fakelibvirt since\n> it\'s kind of useless now anyway, right?\n\nThe thing about fakelibvirt is that it allows us to operate against against a libvirt API without actually doing libvirt-y things like launching VMs.  Now, libvirt does have a \"test:///default\" URI that IIRC has similar functionality, so we could start to phase out fakelibvirt in favor of that.  However, there are probably still some spots where we\'ll want to use fakelibvirt.\n\nBest Regards,\nSolly\n\n----- Original Message -----\n> From: \"Matt Riedemann\" <mriedem at linux.vnet.ibm.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, August 20, 2014 8:37:39 PM\n> Subject: Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests\n> \n> \n> \n> On 8/11/2014 4:42 AM, Daniel P. Berrange wrote:\n> > On Mon, Aug 04, 2014 at 06:46:13PM -0400, Solly Ross wrote:\n> >> Hi,\n> >> I was wondering if there was a way to get a non-readonly connection\n> >> to libvirt when running the unit tests\n> >> on the CI.  If I call `LibvirtDriver._connect(LibvirtDriver.uri())`,\n> >> it works fine locally, but the upstream\n> >> CI barfs with \"libvirtError: internal error Unable to locate libvirtd\n> >> daemon in /usr/sbin (to override, set $LIBVIRTD_PATH to the name of the\n> >> libvirtd binary)\".\n> >> If I try to connect by calling libvirt.open(None), it also barfs, saying\n> >> I don\'t have permission to connect.  I could just set it to always use\n> >> fakelibvirt,\n> >> but it would be nice to be able to run some of the tests against a real\n> >> target.  The tests in question are part of\n> >> https://review.openstack.org/#/c/111459/,\n> >> and involve manipulating directory-based libvirt storage pools.\n> >\n> > Nothing in the unit tests should rely on being able to connect to the\n> > libvirt daemon, as the unit tests should still be able to pass when the\n> > daemon is not running at all. We should be either using fakelibvirt or\n> > mocking any libvirt APIs that need to be tested\n> >\n> > Regards,\n> > Daniel\n> >\n> \n> Also, doesn\'t this kind of break with the test requirement on\n> libvirt-python now?  Before I was on trusty and trying to install that\n> it was failing because I didn\'t have a new enough version of libvirt-bin\n> installed.  So if we require libvirt-python for tests and that requires\n> libvirt-bin, what\'s stopping us from just removing fakelibvirt since\n> it\'s kind of useless now anyway, right?\n> \n> --\n> \n> Thanks,\n> \n> Matt Riedemann\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<53F53F53.7040604@linux.vnet.ibm.com>',NULL),('<1339913146.22.1387779014947.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-23 06:10:14',0,'2013-12-23 06:10:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-havana #6','See <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/6/>\n\n------------------------------------------\n[...truncated 2629 lines...]\nregistry_server: INFO: 2013-12-23 06:04:55.302 9960 DEBUG glance.common.config [-] sqlalchemy_debug               = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.302 9960 DEBUG glance.common.config [-] syslog_log_facility            = LOG_USER log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.303 9960 DEBUG glance.common.config [-] tcp_keepidle                   = 600 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.303 9960 DEBUG glance.common.config [-] use_stderr                     = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.303 9960 DEBUG glance.common.config [-] use_syslog                     = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.304 9960 DEBUG glance.common.config [-] use_tpool                      = False log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.304 9960 DEBUG glance.common.config [-] user_storage_quota             = 0 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.304 9960 DEBUG glance.common.config [-] verbose                        = True log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.305 9960 DEBUG glance.common.config [-] workers                        = 0 log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1941\nregistry_server: INFO: 2013-12-23 06:04:55.305 9960 DEBUG glance.common.config [-] paste_deploy.config_file       = None log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1949\nregistry_server: INFO: 2013-12-23 06:04:55.305 9960 DEBUG glance.common.config [-] paste_deploy.flavor            = fakeauth log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1949\nregistry_server: INFO: 2013-12-23 06:04:55.305 9960 DEBUG glance.common.config [-] ******************************************************************************** log_opt_values <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/oslo/config/cfg.py>:1951\nscrubber_daemon: INFO: 2013-12-23 06:04:54.265 9953 DEBUG glance.store [-] Attempting to import store glance.store.filesystem.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.266 9953 DEBUG glance.store [-] Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.267 9953 DEBUG glance.store.base [-] Late loading location class glance.store.filesystem.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.267 9953 DEBUG glance.store.location [-] Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.267 9953 DEBUG glance.store.location [-] Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.268 9953 DEBUG glance.store [-] Attempting to import store glance.store.http.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.268 9953 DEBUG glance.store [-] Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.269 9953 DEBUG glance.store.base [-] Late loading location class glance.store.http.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.269 9953 DEBUG glance.store.location [-] Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.269 9953 DEBUG glance.store.location [-] Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.269 9953 DEBUG glance.store [-] Attempting to import store glance.store.rbd.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.274 9953 DEBUG glance.store [-] Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.274 9953 DEBUG glance.store.base [-] Late loading location class glance.store.rbd.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.275 9953 DEBUG glance.store.location [-] Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.275 9953 DEBUG glance.store [-] Attempting to import store glance.store.s3.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.276 9953 DEBUG glance.store.s3 [-] Could not find s3_store_host in configuration options. _option_get glance/store/s3.py:256\nscrubber_daemon: INFO: 2013-12-23 06:04:54.277 9953 WARNING glance.store.base [-] Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:54.277 9953 DEBUG glance.store [-] Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.277 9953 DEBUG glance.store.base [-] Late loading location class glance.store.s3.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.277 9953 DEBUG glance.store.location [-] Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.278 9953 DEBUG glance.store.location [-] Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.278 9953 DEBUG glance.store.location [-] Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.278 9953 DEBUG glance.store [-] Attempting to import store glance.store.swift.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.286 9953 ERROR glance.store.swift [-] Could not find swift_store_auth_address in configuration options.\nscrubber_daemon: INFO: 2013-12-23 06:04:54.287 9953 WARNING glance.store.base [-] Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:54.287 9953 DEBUG glance.store [-] Registering store <function Store at 0x2cdfde8> with schemes (\'swift+https\', \'swift\', \'swift+http\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.287 9953 DEBUG glance.store.base [-] Late loading location class glance.store.swift.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.288 9953 DEBUG glance.store.location [-] Registering scheme swift+https with {\'store_class\': <function Store at 0x2cdfde8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.288 9953 DEBUG glance.store.location [-] Registering scheme swift+http with {\'store_class\': <function Store at 0x2cdfde8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.288 9953 DEBUG glance.store.location [-] Registering scheme swift with {\'store_class\': <function Store at 0x2cdfde8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.288 9953 DEBUG glance.store [-] Attempting to import store glance.store.sheepdog.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.292 9953 DEBUG glance.openstack.common.processutils [-] Running cmd (subprocess): collie execute glance/openstack/common/processutils.py:142\nscrubber_daemon: INFO: 2013-12-23 06:04:54.317 9953 DEBUG glance.openstack.common.processutils [-] Result was 127 execute glance/openstack/common/processutils.py:167\nscrubber_daemon: INFO: 2013-12-23 06:04:54.318 9953 ERROR glance.store.sheepdog [-] Error in store configuration: Unexpected error while running command.\nscrubber_daemon: INFO: Command: collie\nscrubber_daemon: INFO: Exit code: 127\nscrubber_daemon: INFO: Stdout: \'\'\nscrubber_daemon: INFO: Stderr: \'/bin/sh: collie: command not found\\n\'\nscrubber_daemon: INFO: 2013-12-23 06:04:54.319 9953 WARNING glance.store.base [-] Failed to configure store correctly: Store sheepdog could not be configured correctly. Reason: Error in store configuration: Unexpected error while running command.\nscrubber_daemon: INFO: Command: collie\nscrubber_daemon: INFO: Exit code: 127\nscrubber_daemon: INFO: Stdout: \'\'\nscrubber_daemon: INFO: Stderr: \'/bin/sh: collie: command not found\\n\' Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:54.319 9953 DEBUG glance.store [-] Registering store <class \'glance.store.sheepdog.Store\'> with schemes (\'sheepdog\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.319 9953 DEBUG glance.store.base [-] Late loading location class glance.store.sheepdog.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.320 9953 DEBUG glance.store.location [-] Registering scheme sheepdog with {\'store_class\': <class \'glance.store.sheepdog.Store\'>, \'location_class\': <class \'glance.store.sheepdog.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.320 9953 DEBUG glance.store [-] Attempting to import store glance.store.cinder.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:54.386 9953 WARNING glance.store.base [-] Failed to configure store correctly: Store cinder could not be configured correctly. Reason: Cinder storage requires a context. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:54.387 9953 DEBUG glance.store [-] Registering store <class \'glance.store.cinder.Store\'> with schemes (\'cinder\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:54.387 9953 DEBUG glance.store.base [-] Late loading location class glance.store.cinder.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:54.388 9953 DEBUG glance.store.location [-] Registering scheme cinder with {\'store_class\': <class \'glance.store.cinder.Store\'>, \'location_class\': <class \'glance.store.cinder.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:54.389 9953 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:54.390 9953 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:54.391 9953 INFO glance.store.scrubber [-] Initializing scrubber with configuration: {\'cleanup_time\': 86400, \'registry_host\': \'127.0.0.1\', \'cleanup\': False, \'scrubber_datadir\': \'/tmp/tmp.2WyH8mq3UC/tmp7PvBPX/scrubber\', \'registry_port\': 34933}\nscrubber_daemon: INFO: 2013-12-23 06:04:54.392 9953 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:54.393 9953 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:54.394 9953 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:54.394 9953 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:54.395 9953 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:54.396 9953 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:56.656 9972 DEBUG glance.store [-] Attempting to import store glance.store.filesystem.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.658 9972 DEBUG glance.store [-] Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.658 9972 DEBUG glance.store.base [-] Late loading location class glance.store.filesystem.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.658 9972 DEBUG glance.store.location [-] Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.659 9972 DEBUG glance.store.location [-] Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.659 9972 DEBUG glance.store [-] Attempting to import store glance.store.http.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.660 9972 DEBUG glance.store [-] Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.660 9972 DEBUG glance.store.base [-] Late loading location class glance.store.http.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.660 9972 DEBUG glance.store.location [-] Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.660 9972 DEBUG glance.store.location [-] Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.661 9972 DEBUG glance.store [-] Attempting to import store glance.store.rbd.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.665 9972 DEBUG glance.store [-] Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.666 9972 DEBUG glance.store.base [-] Late loading location class glance.store.rbd.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.666 9972 DEBUG glance.store.location [-] Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.666 9972 DEBUG glance.store [-] Attempting to import store glance.store.s3.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.667 9972 DEBUG glance.store.s3 [-] Could not find s3_store_host in configuration options. _option_get glance/store/s3.py:256\nscrubber_daemon: INFO: 2013-12-23 06:04:56.668 9972 WARNING glance.store.base [-] Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:56.668 9972 DEBUG glance.store [-] Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.668 9972 DEBUG glance.store.base [-] Late loading location class glance.store.s3.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.669 9972 DEBUG glance.store.location [-] Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.669 9972 DEBUG glance.store.location [-] Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.669 9972 DEBUG glance.store.location [-] Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.669 9972 DEBUG glance.store [-] Attempting to import store glance.store.swift.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.678 9972 ERROR glance.store.swift [-] Could not find swift_store_auth_address in configuration options.\nscrubber_daemon: INFO: 2013-12-23 06:04:56.678 9972 WARNING glance.store.base [-] Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:56.678 9972 DEBUG glance.store [-] Registering store <function Store at 0x21b9de8> with schemes (\'swift+https\', \'swift\', \'swift+http\') create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.679 9972 DEBUG glance.store.base [-] Late loading location class glance.store.swift.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.679 9972 DEBUG glance.store.location [-] Registering scheme swift+https with {\'store_class\': <function Store at 0x21b9de8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.679 9972 DEBUG glance.store.location [-] Registering scheme swift+http with {\'store_class\': <function Store at 0x21b9de8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.680 9972 DEBUG glance.store.location [-] Registering scheme swift with {\'store_class\': <function Store at 0x21b9de8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.680 9972 DEBUG glance.store [-] Attempting to import store glance.store.sheepdog.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.683 9972 DEBUG glance.openstack.common.processutils [-] Running cmd (subprocess): collie execute glance/openstack/common/processutils.py:142\nscrubber_daemon: INFO: 2013-12-23 06:04:56.708 9972 DEBUG glance.openstack.common.processutils [-] Result was 127 execute glance/openstack/common/processutils.py:167\nscrubber_daemon: INFO: 2013-12-23 06:04:56.709 9972 ERROR glance.store.sheepdog [-] Error in store configuration: Unexpected error while running command.\nscrubber_daemon: INFO: Command: collie\nscrubber_daemon: INFO: Exit code: 127\nscrubber_daemon: INFO: Stdout: \'\'\nscrubber_daemon: INFO: Stderr: \'/bin/sh: collie: command not found\\n\'\nscrubber_daemon: INFO: 2013-12-23 06:04:56.710 9972 WARNING glance.store.base [-] Failed to configure store correctly: Store sheepdog could not be configured correctly. Reason: Error in store configuration: Unexpected error while running command.\nscrubber_daemon: INFO: Command: collie\nscrubber_daemon: INFO: Exit code: 127\nscrubber_daemon: INFO: Stdout: \'\'\nscrubber_daemon: INFO: Stderr: \'/bin/sh: collie: command not found\\n\' Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:56.710 9972 DEBUG glance.store [-] Registering store <class \'glance.store.sheepdog.Store\'> with schemes (\'sheepdog\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.710 9972 DEBUG glance.store.base [-] Late loading location class glance.store.sheepdog.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.710 9972 DEBUG glance.store.location [-] Registering scheme sheepdog with {\'store_class\': <class \'glance.store.sheepdog.Store\'>, \'location_class\': <class \'glance.store.sheepdog.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.711 9972 DEBUG glance.store [-] Attempting to import store glance.store.cinder.Store _get_store_class glance/store/__init__.py:146\nscrubber_daemon: INFO: 2013-12-23 06:04:56.777 9972 WARNING glance.store.base [-] Failed to configure store correctly: Store cinder could not be configured correctly. Reason: Cinder storage requires a context. Disabling add method.\nscrubber_daemon: INFO: 2013-12-23 06:04:56.778 9972 DEBUG glance.store [-] Registering store <class \'glance.store.cinder.Store\'> with schemes (\'cinder\',) create_stores glance/store/__init__.py:176\nscrubber_daemon: INFO: 2013-12-23 06:04:56.783 9972 DEBUG glance.store.base [-] Late loading location class glance.store.cinder.StoreLocation get_store_location_class glance/store/base.py:82\nscrubber_daemon: INFO: 2013-12-23 06:04:56.784 9972 DEBUG glance.store.location [-] Registering scheme cinder with {\'store_class\': <class \'glance.store.cinder.Store\'>, \'location_class\': <class \'glance.store.cinder.StoreLocation\'>} register_scheme_map glance/store/location.py:86\nscrubber_daemon: INFO: 2013-12-23 06:04:56.785 9972 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:56.786 9972 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:56.787 9972 INFO glance.store.scrubber [-] Initializing scrubber with configuration: {\'cleanup_time\': 86400, \'registry_host\': \'127.0.0.1\', \'cleanup\': False, \'scrubber_datadir\': \'/tmp/tmp.2WyH8mq3UC/tmp7PvBPX/scrubber\', \'registry_port\': 34933}\nscrubber_daemon: INFO: 2013-12-23 06:04:56.789 9972 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:56.789 9972 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:56.790 9972 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:56.790 9972 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\nscrubber_daemon: INFO: 2013-12-23 06:04:56.791 9972 DEBUG glance.api.policy [-] Loading policy from /tmp/tmp.2WyH8mq3UC/tmp7PvBPX/etc/policy.json _read_policy_file glance/api/policy.py:96\nscrubber_daemon: INFO: 2013-12-23 06:04:56.792 9972 DEBUG glance.api.policy [-] Loaded policy rules: {u\'context_is_admin\': \'role:admin\', u\'default\': \'@\'} load_rules glance/api/policy.py:75\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 85.52 secs:\n    23.28    TestScrubber.test_scrubber_delete_handles_exception\n    23.23    TestScrubber.test_scrubber_app\n    17.38    TestScrubber.test_delayed_delete\n    13.35    TestBinGlanceCacheManage.test_queue\n    8.29    TestMigrations.test_walk_versions\n----------------------------------------------------------------------\nRan 1762 tests in 494.217s\n\nFAILED (SKIP=28, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-havana/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.2\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.21.0\ncffi==0.8.1\ncolorama==0.2.7\ncoverage==3.7.1\ndecorator==3.4.0\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\nglance==jenkins.periodic.glance.python26.havana.6\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.8\nlxml==3.2.4\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.2.0\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\noslo.sphinx==1.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npsutil==0.7.1\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npycparser==2.10\npycrypto==2.6.1\npyflakes==0.7.3\npysendfile==2.0.0\npython-cinderclient==1.0.7\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nqpid-python==0.20\nrepoze.lru==0.6\nrequests==2.1.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\ntesttools==0.9.34\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=180\n+ \'[\' 180 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.2WyH8mq3UC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-havana/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-havana/centos6-11/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<13409273.DKD3yI32kR@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 23:59:34',3600,'2014-02-07 22:59:34',NULL,'[openstack-dev] Asynchrounous programming: replace eventlet\n	with asyncio','Le mardi 4 f?vrier 2014, 12:53:24 Kevin Conway a ?crit :\n> One of the great benefits of using a green thread abstraction, like\n> eventlet or gevent, is that it lets you write normal Python code and slap\n> your concurrency management over the top. It even lets us program in\n> familiar models by pretending like we are using threads.\n\nUsing Tulip/Trollius, thanks to yield-from/yield, the code a function is \nsequential. So it\'s very close to eventlet programming if you ignore \nyield/yield from in the code.\n\nBasically, just replace \"data = obj.read(10)\" with \"data = yield \nobj.read(10)\".\n\n> Switching our async IO management from eventlet to asyncio would not be a\n> trivial task. Tell me when I\'m wrong, but it would require that we\n> completely change our programming model from typical, function-call based\n> programming to use generator-iterators for everything.\n\nNo, that\'s wrong. The only functions that will need to be made asynchronous \nare all functions which are performance critical. Examples: HTTP query to a \nserver or request to a database. All other code will be left unchanged.\n\nI don\'t see why external libraries should be modified. Only the few libraries \nsending HTTP queries and requests to the database should handle asyncio. Dummy \nexample: the iso8601 module used to parse time doesn\'t need to be aware of \nasyncio.\n\n***\n\nI don\'t know OpenStack well enough to say how much code should be modified, but \nI guess that only few functions need to be modified to be asynchronous.\n\nDummy example:\n---\ndef task():\n    print(\"hello\")\n    time.sleep(1)\n    print(\"world\")\n---\n\nWith eventlet and monkey-patching, this task is suspended and other tasks can \nbe executed before \"world\" is displayed.\n\nWith eventlet without monkey-patching orwith asyncio: this function will block \nfor 1 second.\n\nTo make this function asynchronous and allow other tasks to run during the \nsleep, you have to write:\n---\n@asyncio.coroutine\ndef task():\n    print(\"hello\")\n    yield from asyncio.sleep(1)\n    print(\"world\")\n---\n\nBut you will also have to modify how the function is called.\n\nVictor\n\n\n','<CF168A2B.27133%kevinjacobconway@gmail.com>',NULL),('<1341677287.6178145.1368187057139.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-10 07:57:37',-14400,'2013-05-10 11:57:37',NULL,'[openstack-dev] revert keystone eventlet changes?','Hi all,\n\nWe made a change to keystone eventlet last night that seems to have ground SmokeStack to a halt:\n\nhttps://review.openstack.org/#/c/28785/\nhttps://bugs.launchpad.net/keystone/+bug/1178646\n\nCould we get a speedy revert on that patch until we get this figured out?\n\nThanks,\n\nDan\n\n\n','<1812801783.6177946.1368186995383.JavaMail.root@redhat.com>',NULL),('<1341775716.4.1384929659082.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-20 06:40:58',0,'2013-11-20 06:40:58',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/2/>\n\n------------------------------------------\n[...truncated 22543 lines...]\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-11-20 06:38:20,810 Request: POST http://127.0.0.1:5000/v2.0/tokens\n2013-11-20 06:38:20,912 Response Status: 200\n2013-11-20 06:38:20,913 Request: POST http://127.0.0.1:8774/v2/68cacc6e27f54b67a5f42cf6a6288998/servers\n2013-11-20 06:38:22,330 Response Status: 202\n2013-11-20 06:38:22,330 Nova request id: req-db4bc42d-325f-46e4-82c2-ac49700b6426\n2013-11-20 06:38:22,330 Request: GET http://127.0.0.1:8774/v2/68cacc6e27f54b67a5f42cf6a6288998/servers/05f98d5f-7b05-4e56-b314-b31defca9f0a\n2013-11-20 06:38:22,876 Response Status: 200\n2013-11-20 06:38:22,876 Nova request id: req-22a48823-1644-4173-9717-f9e5d3d22874\n2013-11-20 06:38:23,878 Request: GET http://127.0.0.1:8774/v2/68cacc6e27f54b67a5f42cf6a6288998/servers/05f98d5f-7b05-4e56-b314-b31defca9f0a\n2013-11-20 06:38:23,977 Response Status: 200\n2013-11-20 06:38:23,978 Nova request id: req-0a91268c-aca4-4cec-8210-2ab032e06012\n2013-11-20 06:38:23,980 Request: DELETE http://127.0.0.1:8774/v2/68cacc6e27f54b67a5f42cf6a6288998/servers/05f98d5f-7b05-4e56-b314-b31defca9f0a\n2013-11-20 06:38:24,565 Response Status: 204\n2013-11-20 06:38:24,565 Nova request id: req-17a273ac-1628-4437-a84b-99ad99ef9dff\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/api/volume/test_volumes_negative.py\", line 140, in test_attach_volumes_with_nonexistent_volume_id\n    self.servers_client.wait_for_server_status(server[\'id\'], \'ACTIVE\')\n  File \"tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 05f98d5f-7b05-4e56-b314-b31defca9f0a failed to build and is in ERROR status\n\n\n======================================================================\nFAIL: setUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\nsetUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/thirdparty/boto/test_ec2_instance_run.py\", line 46, in setUpClass\n    cls.zone = cls.ec2_client.get_good_zone()\n  File \"tempest/services/botoclients.py\", line 191, in get_good_zone\n    raise IndexError(\"Don\'t have a good zone\")\nIndexError: Don\'t have a good zone\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: setUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest)\nsetUpClass (tempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/thirdparty/boto/test_ec2_volumes.py\", line 38, in setUpClass\n    cls.zone = cls.client.get_good_zone()\n  File \"tempest/services/botoclients.py\", line 191, in get_good_zone\n    raise IndexError(\"Don\'t have a good zone\")\nIndexError: Don\'t have a good zone\n\n\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-11-20 06:38:41,609 Starting new HTTP connection (1): 127.0.0.1\n2013-11-20 06:38:41,805 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 71, in test_snapshot_pattern\n    server = self._boot_image(self.config.compute.image_ref)\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 37, in _boot_image\n    return self.create_server(image=image_id, create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 349, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 256, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 340, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-1767269968> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-11-20 06:39:12,834 Starting new HTTP connection (1): 127.0.0.1\n2013-11-20 06:39:12,936 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 51, in test_resize_server_confirm\n    instance = self.create_server()\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 349, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 256, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 340, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-529511723> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  pythonlogging:\'\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 69, in test_server_sequence_suspend_resume\n    instance = self.create_server()\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 349, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 256, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 340, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-1291378257> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 941 tests in 462.672s\n\nFAILED (failures=97, skipped=42)\nERROR: InvocationError: \'/bin/sh tools/pretty_tox.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])(^tempest\\\\.(api|scenario|thirdparty|cli))\'\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-692295-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-692295.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-692295/2/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1502973536.1.1384845074123.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1342126264.49252168.1359463177499.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-29 07:39:37',-18000,'2013-01-29 12:39:37',NULL,'[openstack-dev] [Ceilometer] Proposing Yunhong Jiang and\n Lianhao Lu	as core dev','\nSorry, I\'m late to the party :)\n\nA hearty +1 to both!\n\nCheers,\nEoghan\n\n----- Original Message -----\n> Hello,\n> \n> As discussed yesterday during the meeting, it seems that Yunhong\n> Jiang\n> and Lianhao Lu have done some great work in the Ceilometer project\n> and\n> deserve to become core dev of our team.\n> \n> Please confirm or infirm this withing the next 5 days.\n> \n> --\n> Nicolas Barcet <nicolas at barcet.com>\n> a.k.a. nijaba, nick\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAEcpoL9++6T18Q4EfPOo1RwmreP-S2EZ8EsP1i0iqANaUpEyWQ@mail.gmail.com>',NULL),('<1342130821.30639812.1407959001063.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 15:43:21',-14400,'2014-08-13 19:43:21',NULL,'[openstack-dev] [all] The future of the integrated release','\n\n> >> Divert all cross project efforts from the following projects so we can\n> >> focus\n> >> our cross project resources. Once we are in a bitter place we can expand\n> >> our\n> >> cross project resources to cover these again. This doesn\'t mean removing\n> >> anything.\n> >> * Sahara\n> >> * Trove\n> >> * Tripleo\n> > \n> > You write as if cross-project efforts are both of fixed size and\n> > amenable to centralized command & control.\n> > \n> > Neither of which is actually the case, IMO.\n> > \n> > Additional cross-project resources can be ponied up by the large\n> > contributor companies, and existing cross-project resources are not\n> > necessarily divertable on command.\n> \n> What ?cross-project efforts? are we talking about? The liaison program in\n> Oslo has been a qualified success so far. Would it make sense to extend that\n> to other programs and say that each project needs at least one designated\n> QA, Infra, Doc, etc. contact?\n\nWell my working assumption was that we were talking about people with\nthe appropriate domain knowledge who are focused primarily on standing\nup the QA infrastructure.\n\n(as opposed to designated points-of-contact within the individual\nproject teams who would be the first port of call for the QA/infra/doc\nfolks if they needed a project-specific perspective on some live issue)\n \nThat said however, I agree that it would be useful for the QA/infra/doc\nteams to know who in each project is most domain-knowledgeable when they\nneed to reach out about a project-specific issue.\n\nCheers,\nEoghan\n\n\n','<6349EEEB-531E-45E3-B408-4D2F9C8B9F71@doughellmann.com>',NULL),('<1342225379.1745575.1399396562821.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 13:16:02',-14400,'2014-05-06 17:16:02',NULL,'[openstack-dev] [Nova] [Heat] Custom Nova Flavor creation\n through Heat (pt.2)','For your first question, I\'ll probably create a BP sometime today.\n\nFor your second question, allowing tenants to create flavors\nprevents one of the main parts of the flavor idea from working --\nhaving flavors that nicely fit together to prevent \"wasted\" host\nresources.  For instance suppose the normal system flavors used\nmemory in powers of 2GB (2, 4, 8, 16, 32).  Now suppose someone\ncame in, created a private flavor that used 3GB of RAM.  We now\nhave 1GB of RAM that can never be used, unless someone decides\nto come along and create a 1GB flavor (actually, since RAM has\neven more granularity than that, you could have someone specify\nthat they wanted 1.34GB of RAM, for instance, and then you have\nall sorts of weird stuff going on).\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Dimitri Mazmanov\" <dimitri.mazmanov at ericsson.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Monday, May 5, 2014 3:40:08 PM\nSubject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)\n\nThis is good! Is there a blueprint describing this idea? Or any plans\ndescribing it in a blueprint?\nWould happily share the work.\n\nShould we mix it with flavors in horizon though? I?m thinking of having a\nseparate ?Resources? page,\nwherein the user can ?define? resources. I?m not a UX expert though.\n\nBut let me come back to the project-scoped flavor creation issues.\nWhy do you think it?s such a bad idea to let tenants create flavors for\ntheir project specific needs?\n\nI?ll refer again to the Steve Hardy?s proposal:\n- Normal user : Can create a private flavor in a tenant where they\n  have the Member role (invisible to any other users)\n- Tenant Admin user : Can create public flavors in the tenants where they\n  have the admin role (visible to all users in the tenant)\n- Domain admin user : Can create public flavors in the domains where they\n  have the admin role (visible to all users in all tenants in that domain)\n\n\n> If you actually have 64 flavors, though, and it\'s overwhelming\n> your users, ...\n\nThe users won?t see all 64 flavor, only those they have defined and public.\n\n-\n\nDimitri\n\nOn 05/05/14 20:18, \"Chris Friesen\" <chris.friesen at windriver.com> wrote:\n\n>On 05/05/2014 11:40 AM, Solly Ross wrote:\n>> One thing that I was discussing with @jaypipes and @dansmith over\n>> on IRC was the possibility of breaking flavors down into separate\n>> components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.\n>> This way, you still get the control of the size of your building blocks\n>> (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid\n>> exponential flavor explosion by separating out the axes.\n>\n>I like this idea because it allows for greater flexibility, but I think\n>we\'d need to think carefully about how to expose it via horizon--maybe\n>separate tabs within the overall \"flavors\" page?\n>\n>As a simplifying view you could keep the existing flavors which group\n>all of them, while still allowing instances to specify each one\n>separately if desired.\n>\n>Chris\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CF8DB16C.D3B5%dimitri.mazmanov@ericsson.com>',NULL),('<1342501080.27469.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-17 05:58:00',3600,'2012-07-17 04:58:00',NULL,'[openstack-dev] recent merge broke quantum','On Mon, 2012-07-16 at 21:21 -0700, Dan Wendlandt wrote:\n> Hi Bob,\n> \n> Looks like the new openstack-common changes can\'t handle a line that has an\n> empty value like:\n> \n> api_extensions_path =\n> \n> You should be able to work around it just by changing the line to:\n> \n> api_extensions_path = \"\"\n> \n> I\'m CC\'ing the openstack-dev list, as this likely affects others.\n> \n> This was actually noticed during the review for merge into quantum by\n> yusuke: ttps://\n> review.openstack.org/#/c/9166/9/quantum/openstack/common/iniparser.py .\n\nThanks for raising this Dan and Bob. I\'ve filed a bug and a fix:\n\n  https://bugs.launchpad.net/openstack-common/+bug/1025522\n\nCheers,\nMark.\n\n\n\n','<CA+0XJm_KA7b6BcHihuSY65OfU8+jSBRG9hh7ytpBUofmawLNLA@mail.gmail.com>',NULL),('<1342530953.27469.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-17 14:15:53',3600,'2012-07-17 13:15:53',NULL,'[openstack-dev] Some Cinder patches to re-sync with Nova','Hi John,\n\nOverall, I think you\'ve done an absolute shit job of ... wait a\nsecond ... I\'m not that guy :-P\n\n(Sorry, couldn\'t resist)\n\nSince cinder forked from nova, it has obviously gotten out of sync in a\nbunch of places. I\'ve pushed some patches to re-sync some pieces again\nand also delete some unused code.\n\nSince it\'s pretty hard to figure out from gerrit what order the patches\ncome in, I thought I\'d do a map :)\n\nFirstly, patches to sync cfg related changes:\n\n  https://review.openstack.org/9863 Sync to newer openstack.common.cfg\n  https://review.openstack.org/9864 Pass \'cinder\' project into ConfigOpts\n  https://review.openstack.org/9865 Misused and not used config options\n  https://review.openstack.org/9866 Remove old flagfile support\n  https://review.openstack.org/9867 Sync with latest version of openstack.common.cfg\n  https://review.openstack.org/9868 Use cfg\'s new behavior of reset() clearing overrides\n  https://review.openstack.org/9869 Use cfg\'s new global CONF object\n  https://review.openstack.org/9870 Sync cfg and iniparser from openstack-common.\n\nAnd a patch to delete cfg related code which I don\'t think is relevant\nto cinder:\n\n  https://review.openstack.org/9871 Remove \'cinder-manage config convert\'\n\nNow a patch to remove @synchronized, since it\'s unused in cinder. Later\nRPC related patches conflict with this which is why it\'s here:\n\n  https://review.openstack.org/9888 Remove unused synchronization decorator\n\nAnd a big bunch of patches to adopt the rpc module from openstack-common:\n\n  https://review.openstack.org/9890 Make use of openstack.common.jsonutils.\n  https://review.openstack.org/9899 Stop using cinder.exception from cinder.rpc.\n  https://review.openstack.org/9900 Make kombu support optional for running unit tests.\n  https://review.openstack.org/9901 Add base support for rpc API versioning.\n  https://review.openstack.org/9902 Add version to scheduler rpc API.\n  https://review.openstack.org/9903 Localize rpc options to rpc code.\n  https://review.openstack.org/9904 Remove cinder.context dependency from cinder.rpc\n  https://review.openstack.org/9905 Remove cinder.log usage from cinder.rpc.\n  https://review.openstack.org/9906 Move queue_get_for() from db to rpc.\n  https://review.openstack.org/9907 Use openstack.common.cfg.CONF.\n  https://review.openstack.org/9908 Add missing ack to impl_qpid.\n  https://review.openstack.org/9909 Use save_and_reraise_exception() from common.\n  https://review.openstack.org/9910 Add missing gettextutils from openstack-common.\n  https://review.openstack.org/9911 Use rpc from openstack-common.\n\nNow a series of 4 patches to remove unused code. They come together\nbecause they conflict in various ways:\n\nhttps://review.openstack.org/9880 Remove unused raise_http_conflict_for_instance_invalid_state()\nhttps://review.openstack.org/9881 Remove unused metadata serialization\nhttps://review.openstack.org/9882 Remove unused get_{id,version}_from_href()\nhttps://review.openstack.org/9883 Remove unused check_snapshots_enabled\n\nAnd, finally, 5 non-conflicting patches to remove unused code. These do\nnot depend on each other:\n\n  https://review.openstack.org/9884 Remove unused enabled_apis flag\n  https://review.openstack.org/9885 Remove unused fake memcache client\n  https://review.openstack.org/9886 Remove some unused helper scripts\n  https://review.openstack.org/9887 Remove unused OverLimitFault\n  https://review.openstack.org/9889 Remove unused wrap_errors decorator\n\nYou can kiss my ass,^H^H^H^H^H^H^H^H\nRegards,\nMark.\n\n\n\n',NULL,NULL),('<1342543074.27469.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-17 17:37:54',3600,'2012-07-17 16:37:54',NULL,'[openstack-dev] Some Cinder patches to re-sync with Nova','Hi Chmouel,\n\nOn Tue, 2012-07-17 at 15:02 +0100, Chmouel Boudjnah wrote:\n> Hello Mark,\n> \n> On Tue, Jul 17, 2012 at 2:15 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > Since cinder forked from nova, it has obviously gotten out of sync in a\n> > bunch of places. I\'ve pushed some patches to re-sync some pieces again\n> > and also delete some unused code.\n> \n> I was working on getting cinder working with openstack.common.log\n> (just to get the pretty colored log messages in devstack) and i\'m not\n> sure if you already been working on this or would conflict with your\n> patches, it\'s avail as a Draft here:\n> \n> https://review.openstack.org/9913\n\nAwesome! No, I hadn\'t started looking at this yet. I\'ve left some review\ncomments, but it looks great.\n\nThanks,\nMark.\n\n\n\n','<CAPeWyqxJ0Mb5XAmj7oxbn1GOVTkN+PH1BN7Q+Z2PZUUZH9VsRg@mail.gmail.com>',NULL),('<1342555756.16035.257.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-17 15:09:16',-18000,'2012-07-17 20:09:16',NULL,'[openstack-dev] scheduler testing tool?','On Tue, 2012-07-17 at 15:41 -0400, Sean Dague wrote:\n> At the Folsom Summit someone (and I am totally blanking on who, sorry), \n> did a really great lightning talk on a scheduler tester that would run \n> through a simulated scheduling process and pack a set of simulated \n> hosts, ensuring that scheduling didn\'t over commit, or happen in an \n> unexpected way.\n\nI believe that was Sandy Walsh.\n\n> Is that code available as something that could be integrated into nova \n> unit tests? It would be a nice basis for being able to confirm scheduler \n> behavior, especially for some of the reported scheduler bugs like this \n> one - https://bugs.launchpad.net/nova/+bug/1023827\n\nActually, I believe it was approved and merged into the unit tests?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5005BFF4.6050909@linux.vnet.ibm.com>',NULL),('<1342597100.19642.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-18 08:38:20',3600,'2012-07-18 07:38:20',NULL,'[openstack-dev] Context class of openstack common project','Hi,\n\nOn Wed, 2012-07-18 at 07:24 +0800, Yong Sheng Gong wrote:\n> Hi,\n> We ( quantum) are using notifier and rpc code of openstack common\n> project, but found these common codes need a common Context class.\n> I think the common Context class is from glance project, which is\n> using user, and tenant instead of user_id and tenant_id in nova.\n> Quantum\'s Context class is from nova originally.\n\nI see that while the common notifiers code uses this class - and Nova\nuses the common notifiers code - Nova itself doesn\'t use the class. So,\nI\'m not sure how this is supposed to work.\n> \n> I think for all others to use the Common code, we have to redesign the\n> common Context so that it is easy to be a base class.\n\nI haven\'t looked too closely, but I suspect you\'re correct. The Context\nclass is one of the parts of openstack-common which I think needs more\nwork for it to be generally useful across projects.\n\n> 1.  Don\'t have fields, such as user, and tenant. Instead we can have\n> methods.\n> 2.  Don\'t use module methods since it is no way to be redefined.\n> Consider factory or define it in configuration.\n\nMy one concern is that we may make this class so generic that it\nactually contains very little and isn\'t very useful to have in\nopenstack-common at all.\n\nCheers,\nMark.\n\n\n\n','<OF7A525369.31B4643C-ON48257A3E.00809D28-48257A3E.00809D30@cn.ibm.com>',NULL),('<1342704037.18575.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-19 14:20:37',3600,'2012-07-19 13:20:37',NULL,'[openstack-dev] Modelling the creation of multiple networks in\n	Nova\'s REST API','Hi,\n\nI was just reviewing the code for this:\n\n  https://blueprints.launchpad.net/nova/+spec/os-api-network-create\n\nYou POST to /networks:\n\n  {\"network\": {\"vlan_start\": 234, \"cidr\": \"10.70.105.0/24\", \"label\": \"net234\"}}\n\nand get back e.g.\n\n  {\"networks\": [{..., \"id\": 66085e78-8f6-4a26-b16c-4b1f55901fbd\", ..., \"label\": \"net234\", ..., \"vlan\": 234, ..., \"cidr\": \"10.70.105.0/24\", ...}]}\n\nNotice the plural \"networks\" in the response. A single POST may create\nmultiple networks (where e.g. FLAGS.num_networks > 1), but it\'s not\nclear to me what the use case for this is.\n\nThe issue with this is that (at least IMHO) POST requests should only\ncreate a single resource - e.g. we want to be able to return a 201\nCreated response with a Location header and it would seem bizarre to\ninclude multiple location headers.\n\nSo:\n\n  - What\'s this batch network create thing for?\n\n  - Is it important for it to be available in the API?\n\n  - If it is important to make available in the API, any thoughts on \n    modelling it?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1342925022.35418.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-21 19:43:42',-25200,'2012-07-22 02:43:42',NULL,'[Openstack-operators] How many NIC do I need for installing Essex','Hi all,\n\nI\'m following;\nExpreimenting with OpenStack Essex on Ubuntu 12.04 LTS under \nhttp://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n\nbuilding OpenStack, Essex.\n\nBut I can\'t resolve how many NICs I need to install Essex?? To my understanding on the diagram - Quick Overview of The Installation\n\neth0 = NIC-0\neth1 = NIC-1\neth2 = NIC-2\n\nthen it needs 3 NICs.\n\nOn the other hand;\nvboxnet0 and vboxnet1 are virtual NIC\n\nthen it needs 2 NICs, one for NAT. \n\nBut I have only ONE NIC on the box.? Is there any solution?? Please help.? TIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120721/7a819d86/attachment.html>\n\n',NULL,NULL),('<1342937202.13605.YahooMailNeo@web125102.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-21 23:06:42',-25200,'2012-07-22 06:06:42',NULL,'[Openstack-operators] How many NIC do I need for installing\n	Essex','Hi Paul,\n\nThanks for your advice.\n\nCan I replace;\n172.16.0.254 with 192.168.0.100\n\nand\n\n11.0.0.1 with 192.168.0.101\n?\n\nBecause 172.16.0.254 and 11.0.0.1 are not in the range of IP address of the router\n\nB.R.\nStephen L\n\n\n\n\n>________________________________\n> From: Paul Guth <gunther at cloudscaling.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Sunday, July 22, 2012 1:40 PM\n>Subject: Re: [Openstack-operators] How many NIC do I need for installing Essex\n> \n>\n>Hi Stephen,\n>\n>\n>That installation requires only one physical NIC. All the NICs shown in the diagram are virtual - created by virtualbox.\n>\n>\n>Paul\n>\n>\n>On Sat, Jul 21, 2012 at 7:43 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi all,\n>>\n>>I\'m following;\n>>Expreimenting with OpenStack Essex on Ubuntu 12.04 LTS under \n>>http://www.tikalk.com/alm/blog/expreimenting-openstack-essex-ubuntu-1204-lts-under-virtualbox\n>>\n>>building OpenStack, Essex.\n>>\n>>But I can\'t resolve how many NICs I need to install Essex?? To my understanding on the diagram - Quick Overview of The Installation\n>>\n>>eth0 = NIC-0\n>>eth1 = NIC-1\n>>eth2 = NIC-2\n>>\n>>then it needs 3 NICs.\n>>\n>>On the other hand;\n>>vboxnet0 and vboxnet1 are virtual NIC\n>>\n>>then it needs 2 NICs, one for NAT. \n>>\n>>But I have only ONE NIC on the box.? Is there any solution?? Please help.? TIA\n>>\n>>B.R.\n>>Stephen L\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n>-- \n>Paul Guth\n>Cloudscaling Technical Operations\n>skype: pguth66\n>phone: +1 408 647 5128\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120721/d4155139/attachment.html>\n\n','<CAOt0G2Bwgtj4pgiyDKMJD5vDdGKJJiVZT9mnmAq=PCuXcM50ug@mail.gmail.com>',NULL),('<1343034941.7219.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-23 10:15:41',3600,'2012-07-23 09:15:41',NULL,'[openstack-dev] [API] Standardizing status codes in the native\n API','On Sat, 2012-07-21 at 06:15 -0400, Eoghan Glynn wrote:\n> \n> > >> Do you reckon this change warrants a full major version bump?\n> > >\n> > > Generally speaking non-backwards-compatible changes do require a\n> > > version\n> > > bump, yes. I know it seems like a trivial change, but it would\n> > > break all\n> > > clients expecting a 200 where a 201/202 would now be returned.\n> > \n> > Agreed, I expect a number of clients are checking for 200, and not a\n> > generic 2xx status code. So, while I am all in favor of this change,\n> > I think it requires a version bump.\n> \n> Thanks Jay & Sean for the responses,\n> \n> Normally I\'d agree with you that we need to very reticent about breaking\n> backward compatibility, however in this case I suspect we may be talking\n> about bug compatibility.\n\nI agree. I\'m fully behind us being very careful about maintaining API\ncompatibility, but that does not imply that we should prevent ourselves\nfrom fixing bugs until a v3 API.\n\nSo, some things I\'d consider when reviewing the change:\n\n  - do we document anywhere what our response codes should be for \n    resource creation? (guess: no)\n\n  - if not, is 201 with a Location header the right thing? (guess: yes)\n\n  - do we know of any clients that this change would break? (guess: no)\n\nAlso, the \"we must maintain compat\" is inconsistent with other similar\nchanges like this one merged on Friday:\n\n  https://review.openstack.org/#/c/9993/\n\nCheers,\nMark.\n\n\n\n','<240364428.14663.1342865746515.JavaMail.root@redhat.com>',NULL),('<1343104114.12411.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-23 21:28:34',-25200,'2012-07-24 04:28:34',NULL,'[Openstack-operators] Examples/demonstration on running OpenStack\n	in Data-Centre','Hi all,\n\nI have been hunting for examples/demonstration applying OpenStack in Data-Centre where there are hundreds of server running with different application without much result.? Could any folk on the list shed me some light?? TIA\n\nDuring searching I found;\n\nQuantum\nhttp://wiki.openstack.org/Quantum\n\nIt is a side project of OpenStack.? It aims for Data-Center application.\n\nB.R.\nSL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120723/9b3ebfd2/attachment.html>\n\n',NULL,NULL),('<1343134572.57605.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-24 05:56:12',-25200,'2012-07-24 12:56:12',NULL,'[Openstack-operators] Examples/demonstration on running\n	OpenStack in Data-Centre','Hi Steven,\n\nThanks for your advice.\n\nNot many discovery found.? Maybe it is ONLY at start?\n\nI found;\n\n1)\nNectar\nhttp://support.rc.nectar.org.au/research_cloud/openstack.html\n\n2)\nNASA drops their participation to OpenStack for Amazon Cloud\n\n3)\nCitrix, CloudStack, OpenStack, and the war for open-source clouds\nhttp://blogs.gartner.com/lydia_leong/2012/04/03/citrix-cloudstack-openstack-and-the-war-for-open-source-clouds/\n\nB.R.\nSL\n\n\n\n\n>________________________________\n> From: Steven Manos <smanos at unimelb.edu.au>\n>To: Stephen Liu <satimis at yahoo.com>; \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, July 24, 2012 12:56 PM\n>Subject: RE: [Openstack-operators] Examples/demonstration on running OpenStack in Data-Centre\n> \n>\n> \n>Stephen\n>?\n>Googling for ?openstack research cloud? might yield some useful results.\n>?\n>Steven.\n>?\n>?\n>From:Stephen Liu [mailto:satimis at yahoo.com] \n>Sent: Tuesday, 24 July 2012 2:29 PM\n>To: openstack-operators at lists.openstack.org\n>Subject: [Openstack-operators] Examples/demonstration on running OpenStack in Data-Centre\n>?\n>Hi all,\n>\n>I have been hunting for examples/demonstration applying OpenStack in Data-Centre where there are hundreds of server running with different application without much result.? Could any folk on the list shed me some light?? TIA\n>\n>During searching I found;\n>\n>Quantum\n>http://wiki.openstack.org/Quantum\n>\n>It is a side project of OpenStack.? It aims for Data-Center application.\n>\n>B.R.\n>SL\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120724/d1de028d/attachment.html>\n\n','<DBD68B58F23E8349AE6D12AD0AB5D1A9A8BD4DF3@000S-EX-MBX-QS2.unimelb.edu.au>',NULL),('<1343136826.2465.121.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-24 14:33:46',3600,'2012-07-24 13:33:46',NULL,'[openstack-dev] [Quantum] Agents and configuration files','Hey,\n\nChatting to Gary on IRC, I was saying what makes most sense to me is to\ngive users/distributors the choice of configuring everything in\nquantum.conf i.e.\n\n  /etc/quantum/quantum.conf:\n    [DEFAULT]\n    plugin = linuxbridge\n\n    [linuxbridge]\n    foo = bar\n\n    [ovs]\n    foobar = blaa\n\nor keeping plugin configuration in separate files:\n\n  /etc/quantum/quantum.conf:\n    [DEFAULT]\n    plugin = linuxbridge\n\n  /etc/quantum/plugins.d/linuxbridge.conf:\n    [linuxbridge]\n    foo = bar\n\n  /etc/quantum/plugins.d/ovs.conf:\n    [ovs]\n    foobar = blaa\n\nBasically, quantum would default to:\n\n  --config-file=/etc/quantum.conf --config-file=/etc/quantum/quantum.conf --config-dir=/etc/quantum/plugins.d\n\nand all configuration options would be registered with the global CONF\nobject - so e.g. a value set in a .conf file in plugins.d take\nprecedence over anything set in quantum.conf.\n\nThis also has the advantage of being very easily supported by cfg :)\n\nCheers,\nMark.\n\n\n\n','<500E9D09.60009@redhat.com>',NULL),('<1343184733.51495.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-24 19:52:13',-25200,'2012-07-25 02:52:13',NULL,'[Openstack-operators] Examples/demonstration on running\n	OpenStack in Data-Centre','Hi Diego,\n\nI have OpenStack installed and running on a VM of VirtualBox for testing.? However I have no idea how to use it.? On the VirtualBox there are servers running on other VMs as well, also for testing.\n\nActually this is NOT a new technolgy similar to server adminstration the later of which has been existing for sometimes.? There are software for such adminstration.? But I\'m interested finding a new approach making use of OpenStack to do such a job.\n\nThanks for the link which is a Spanish website.\nMi espa?ol no es bueno.\n\nI have browsed it a while.\n\nMuchas gracias\n\nAtentamente\nSL\n\n\n\n\n>________________________________\n> From: Diego Parrilla Santamar?a <diego.parrilla.santamaria at gmail.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, July 24, 2012 10:29 PM\n>Subject: Re: [Openstack-operators] Examples/demonstration on running OpenStack in Data-Centre\n> \n>\n>It\'s not clear for me if you are looking for an architectural blueprint or a success case. There are a lot of architectural blueprints to scale Openstack, but honestly finally we had to build our own Reference Architecture :-(?\n>\n>\n>If you are looking for a success case, may be one of our customers could fit your needs. He has an on-demand Virtual Private Cloud subscription service with a good bunch of servers:\n>\n>\n>http://www.hostalia.com/cloud-dedicado/\n>\n>\n>Hostalia is brand of ACENS, a Hosting Provider of the Telef?nica Group. Basically the customer choose in a wizard the number of compute nodes, storage size and public IPs and in 30\' you have your own private cloud ready to go. His customers are running a very heterogenous set of application and services.\n>\n>\n>We are working with some providers worldwide to deliver similar services based on Openstack.?\n>\n>\n>Regards\n>Diego\n>?--?\n>Diego Parrilla\n>CEO\n>www.stackops.com?|??diego.parrilla at stackops.com?|?+34 649 94 43 29 |?skype:diegoparrilla\n>\n>\n>\n>\n>\n>\n>On Tue, Jul 24, 2012 at 6:28 AM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi all,\n>>\n>>I have been hunting for examples/demonstration applying OpenStack in Data-Centre where there are hundreds of server running with different application without much result.? Could any folk on the list shed me some light?? TIA\n>>\n>>During searching I found;\n>>\n>>Quantum\n>>http://wiki.openstack.org/Quantum\n>>\n>>It is a side project of OpenStack.? It aims for Data-Center application.\n>>\n>>B.R.\n>>SL\n>>\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120724/62fc4168/attachment-0001.html>\n\n','<CAASO9xaU==uRCK5uOfYYOVzWuO1ffMDMc+90smoKu=evTo2MCg@mail.gmail.com>',NULL),('<1343194784.65427.YahooMailNeo@web125102.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-24 22:39:44',-25200,'2012-07-25 05:39:44',NULL,'[Openstack-operators] Examples/demonstration on running\n	OpenStack in Data-Centre','Hi Warren,\n\nThanks for your advice.\n\n- snip _\n\n\n> Design the site to be resilient, and use Openstack and Chef/Puppet/CFengine/etc \n\n> to configure them.\n\n\nI hope following document is the right direction for me to start?\n\nUsing Puppet to configure OpenStack Instances\nhttp://start.nwt.fhstp.ac.at/blog/?p=236\n\nIf I\'m wrong pls advice.? TIA\n\n\n\n- snip -\n> When you start talking about multiple cloud environments across multiple\n> data centers, things become more interesting.\n\nAre following threads being relevant?\n\n\nMulti-Datacenter and Remote IT Monitoring\nhttp://www.uptimesoftware.com/multi-datacenter.php\n\nDuraCloud Wiki\nhttps://wiki.duraspace.org/display/DURACLOUD/DuraCloud\n\nIf NOT, please advise.? TIA\n\n\n\n> There are a lot of things that you can do to demo a cloud environment.? \n\n> You don\'t necessarily have to look at just Openstack to get ideas.? \n\n> You can get ideas from EC2 as well.\n\n\nNoted.? Thanks\n\nB.R.\nSL\n\n\n\n>On Tue, Jul 24, 2012 at 10:52 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>\n>Hi Diego,\n>>\n>>I have OpenStack installed and running on a VM of VirtualBox for testing.? However I have no idea how to use it.? On the VirtualBox there are servers running on other VMs as well, also for testing.\n>>\n>>Actually this is NOT a new technolgy similar to server adminstration the later of which has been existing for sometimes.? There are software for such adminstration.? But I\'m interested finding a new approach making use of OpenStack to do such a job.\n>>\n>>Thanks for the link which is a Spanish website.\n>>Mi espa?ol no es bueno.\n>>\n>>I have browsed it a while.\n>>\n>>Muchas gracias\n>>\n>>Atentamente\n>>SL\n>>\n>>\n>>\n>>>________________________________\n>>> From: Diego Parrilla Santamar?a <diego.parrilla.santamaria at gmail.com>\n>>>To: Stephen Liu <satimis at yahoo.com> \n>>>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>>>Sent: Tuesday, July 24, 2012 10:29 PM\n>>>Subject: Re: [Openstack-operators] Examples/demonstration on running OpenStack in Data-Centre\n>>> \n>>>\n>>>\n>>>It\'s not clear for me if you are looking for an architectural blueprint or a success case. There are a lot of architectural blueprints to scale Openstack, but honestly finally we had to build our own Reference Architecture :-(?\n>>>\n>>>\n>>>If you are looking for a success case, may be one of our customers could fit your needs. He has an on-demand Virtual Private Cloud subscription service with a good bunch of servers:\n>>>\n>>>\n>>>http://www.hostalia.com/cloud-dedicado/\n>>>\n>>>\n>>>Hostalia is brand of ACENS, a Hosting Provider of the Telef?nica Group. Basically the customer choose in a wizard the number of compute nodes, storage size and public IPs and in 30\' you have your own private cloud ready to go. His customers are running a very heterogenous set of application and services.\n>>>\n>>>\n>>>We are working with some providers worldwide to deliver similar services based on Openstack.?\n>>>\n>>>\n>>>Regards\n>>>Diego\n>>>?--?\n>>>Diego Parrilla\n>>>CEO\n>>>www.stackops.com?|??diego.parrilla at stackops.com?|?+34 649 94 43 29 |?skype:diegoparrilla\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Tue, Jul 24, 2012 at 6:28 AM, Stephen Liu <satimis at yahoo.com> wrote:\n>>>\n>>>Hi all,\n>>>>\n>>>>I have been hunting for examples/demonstration applying OpenStack in Data-Centre where there are hundreds of server running with different application without much result.? Could any folk on the list shed me some light?? TIA\n>>>>\n>>>>During searching I found;\n>>>>\n>>>>Quantum\n>>>>http://wiki.openstack.org/Quantum\n>>>>\n>>>>It is a side project of OpenStack.? It aims for Data-Center application.\n>>>>\n>>>>B.R.\n>>>>SL\n>>>>\n>>>>_______________________________________________\n>>>>OpenStack-operators mailing list\n>>>>OpenStack-operators at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n\n\n','<CAARB8+utdiehFVHsLJAXnT=KdiDc_xMLnjbZp2xJLQW=VgNweA@mail.gmail.com>',NULL),('<1343234344.2465.213.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-25 17:39:04',3600,'2012-07-25 16:39:04',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing status\n codes in the native API]','Hey,\n\nTrying to get away from this specific issue for a minute ... some\npoints:\n\n   - We fix bugs all the time that may affect clients which rely on the \n     specific buggy behaviour. Not just pure API changes like this one, \n     but subtle behavioural changes.\n\n   - API compatibility is very important. As a general rule, we don\'t\n     want to break clients.\n\n   - If we take things to extremes and wait until the next major \n     version to fix *any* issue which *may* have an impact on clients, \n     I don\'t think anyone will thank us.\n\n   - So, there\'s a client impact threshold under which we accept the \n     bugfixes without a major version bump.\n\n   - What that threshold is will partly depend on when the next major \n     version will be - e.g. if v3 will be in 5 years time, it wouldn\'t \n     be sane for us to wait that long to fix issues which have minimal \n     client impact.\n\n   - We certainly do want to get to a point where we can make a \n     commitment to not make changes even this minor, but I don\'t think \n     the project is there yet.\n\n   - Our API documentation doesn\'t cover every aspect of the API which \n     clients may come to rely on. We also don\'t really document what \n     clients should avoid relying on (e.g. URL structure, specific \n     response codes etc.) so we can\'t always rely on the documentation\n     to tell us whether an API fix is acceptable.\n\n   - I hate to think of us rejecting API fixes with \"this needs to wait \n     until v3\" and then, when v3 comes around, we don\'t actually get \n     around to fixing those issues. We need some way of channelling \n     people\'s desire to fix the API, even if that\'s just helping to \n     document what needs fixing in v3.\n\nSo, thinking about this specific issue:\n\n   - \"201 Created\" is clearly the right behaviour and is what we do \n     elsewhere in the API. Unfortunately, we don\'t document this so we \n     can\'t just say \"see, we\'re just making it compliant with the spec\".\n\n   - Some clients may be relying on \"200 OK\" and they may be affected\n     by this change. However, more sensible clients would just accept\n     any 2xx code as success. In terms of impact that I expect API\n     clients may see between Essex and Folsom, my guess is this is\n     pretty minor.\n\n   - I don\'t know of any plans for v3. I also don\'t know that we have\n     any way to channel this effort into preparing for v3.\n\nNo-one reading this should interpret it as a lack of understanding of\nthe importance of API compatibility. There is a spectrum of API compat\nstrictness. Where we fall on the spectrum at this point of the project\'s\nlife isn\'t a trivial question. We don\'t want to be at either of the\nextreme ends of the spectrum (e.g. the rules Sun used to apply to\nSolaris changes vs Ruby libraries which change API every day of the\nweek), so please don\'t try and make out this is a black-and-white thing.\n\nCheers,\nMark.\n\n\n\n','<500D9CE0.7010103@gmail.com>',NULL),('<1343248869.2465.235.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-25 21:41:09',3600,'2012-07-25 20:41:09',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','On Wed, 2012-07-25 at 13:49 -0400, Sean Dague wrote:\n> On 07/25/2012 12:39 PM, Mark McLoughlin wrote:\n> >     - Our API documentation doesn\'t cover every aspect of the API which\n> >       clients may come to rely on. We also don\'t really document what\n> >       clients should avoid relying on (e.g. URL structure, specific\n> >       response codes etc.) so we can\'t always rely on the documentation\n> >       to tell us whether an API fix is acceptable.\n> \n> I\'m actually trying to sort out how and where we are documenting these \n> details today in a user facing way, and what we consider canonical on \n> return codes? This seems a bit fragmented today, as I was trying to \n> figure out what we specified in the v2 API fully here.\n\nI don\'t know of any complete existing documentation of these.\n\nIf we could gather together some thoughts on what they should be, this\ncould form the beginning of discussing and documenting what changes\nshould be made in v3.\n\nIt would actually be a really worthwhile discussion to have - e.g. I\nthink we misuse/abuse/overuse \"202 Accepted\" and that \"201 Created\" is\nusually more appropriate.\n\n> >     - I hate to think of us rejecting API fixes with \"this needs to wait\n> >       until v3\" and then, when v3 comes around, we don\'t actually get\n> >       around to fixing those issues. We need some way of channelling\n> >       people\'s desire to fix the API, even if that\'s just helping to\n> >       document what needs fixing in v3.\n> \n> Agreed. Is there some kind of artifact in launchpad that we can track to?\n\nNot that I know of. How could we do this? A v3-api blueprint with most\nof the details in a wiki page? And also a v3-api tag for bugs which\nwe\'re deferring until v3?\n\n> > So, thinking about this specific issue:\n> >\n> >     - \"201 Created\" is clearly the right behaviour and is what we do\n> >       elsewhere in the API. Unfortunately, we don\'t document this so we\n> >       can\'t just say \"see, we\'re just making it compliant with the spec\".\n> >\n> >     - Some clients may be relying on \"200 OK\" and they may be affected\n> >       by this change. However, more sensible clients would just accept\n> >       any 2xx code as success. In terms of impact that I expect API\n> >       clients may see between Essex and Folsom, my guess is this is\n> >       pretty minor.\n> >\n> >     - I don\'t know of any plans for v3. I also don\'t know that we have\n> >       any way to channel this effort into preparing for v3.\n> >\n> > No-one reading this should interpret it as a lack of understanding of\n> > the importance of API compatibility. There is a spectrum of API compat\n> > strictness. Where we fall on the spectrum at this point of the project\'s\n> > life isn\'t a trivial question. We don\'t want to be at either of the\n> > extreme ends of the spectrum (e.g. the rules Sun used to apply to\n> > Solaris changes vs Ruby libraries which change API every day of the\n> > week), so please don\'t try and make out this is a black-and-white thing.\n> \n> I agree that it\'s not black and white, but the fact that this required a \n> change in tempest should be an indication that == 200 is a common \n> pattern for folks, ourselves included. So there are some real pragmatics \n> about changing what a success code is.\n\nOk, I can buy that response codes are just about above our current\n\"client impact threshold\". Especially if we have some sort of realistic\nplan for cleaning these up in the medium term.\n\nIn v3, though, it would be worth considering explicitly calling out that\nindividual response codes as something that clients should not\nexplicitly rely on - i.e. \"accept 2xx as success\".\n\nCheers,\nMark.\n\n\n\n','<5010319D.7080000@linux.vnet.ibm.com>',NULL),('<1343253797.2465.244.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-25 23:03:17',3600,'2012-07-25 22:03:17',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','Hey,\n\nContext for others - Jay asked for feedback on some API change\nguidelines which he and David have been working on. See here:\n\n  http://etherpad.openstack.org/Hn8rKP7XgB\n\nSo ... kudos for kicking this off. I think it\'ll help a lot to get this\nstuff written down - e.g. consistency in reviews and to give confidence\nto users that we do care about API compat.\n\nWhat you have looks like a good start, but I think it\'s going to take an\nsustained effort to polish this off into something really useful for\nreviewers in particular.\n\nThe guidelines themselves will probably only get us so far. What will\nprobably be more effective is expanding on examples of where we\nconsidered and approved/rejected an incompatible change. If we got into\nthe habit of discussing such proposed changes on the list and then\ndocumenting the conclusion as examples in the guidelines, I think we\'d\nbe in great shape pretty quickly.\n\nI\'ve taken a stab at reworking most of the doc, but I don\'t think I\'ve\nchanged it all that much. I think we\'re pretty well aligned. The main\nthing I tried to was make it read like helpful advice for reviewers and\ndevelopers rather than a stringent set of \"THOU SHALT NOT\"\ncommandments :-)\n\nHope that helps,\nMark.\n\n\n\n','<1343234344.2465.213.camel@sorcha>',NULL),('<13432590.923211349957788217.JavaMail.weblogic@epml01>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 12:16:28',0,'2012-10-11 12:16:28',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','Eoghan, \n\n> Are all aggregations (sum, min, max, average, sample count)\n> for the 60s metrics stored across all dimensions (i.e. instance ID,\n> instance type, image ID etc. for AWS/EC2 metrics)?\n> \n> Or are some or all aggregation-over-dimensions only calculated lazily\n> if and when a corresponding call to GetMetricStatistics occurs?\n\nSynaps does not aggregate datapoints across dimensions. However, \nagents can push metrics per dimensions. \n\n> How do you handle metric backfill? Say for example at time t0 a\n> delayed datapoint is received for t0-600s and you\'re evaluating\n> a monitor with say 3x5min evaluation periods. Is the in-memory\n> representation updated or somehow marked as stale so as to force\n> a re-read from Cassandra?\n\nIf a datapoint that could not hit in-memory window of storm is pushed,\nSynaps re-reads and updates from Cassandra without evaluation.\n\nThank you,\nJune Yi\n\n\n\n\n\n\n\n------- Original Message -------\nSender : Eoghan Glynn<eglynn at redhat.com> \nDate   : 2012-10-11 17:52 (GMT+09:00)\nTitle  : Re: [openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API\n\n\n\nThanks for the quick response June Yi,\n\n> Synaps basically stores metric data aggregated with 1 minute\n> resolution in hybrid way, in-memory of storm workers and Cassandra\n> database. And it rolls those aggregated datapoints up again when\n> another resolutions of statistics are requested.\n\nAre all aggregations (sum, min, max, average, sample count)\nfor the 60s metrics stored across all dimensions (i.e. instance ID,\ninstance type, image ID etc. for AWS/EC2 metrics)?\n\nOr are some or all aggregation-over-dimensions only calculated lazily\nif and when a corresponding call to GetMetricStatistics occurs?\n \n> Storm holds time-series datapoints within flexible sliding window per\n> metric based on its longest period of alarm so that it can evaluate\n> alarms without any reading operation from Cassandra database.\n\nHow do you handle metric backfill? Say for example at time t0 a\ndelayed datapoint is received for t0-600s and you\'re evaluating\na monitor with say 3x5min evaluation periods. Is the in-memory\nrepresentation updated or somehow marked as stale so as to force\na re-read from Cassandra?\n\nCheers,\nEoghan\n\n\n> Synaps was designed with inspiration by following posts:\n> [1]\n> https://www.cloudkick.com/blog/2010/mar/02/4_months_with_cassandra/\n> [2]\n> http://pyvideo.org/video/675/storm-the-hadoop-of-realtime-stream-processing\n> \n> Hi Endre,\n> \n> > But how does Synaps then difffer from Ceilometer? It looks to be\n> > duplicated\n> > efforts here?\n> > \n> \n> I think I don\'t understand Ceilometer enough but as I know its main\n> purpose is to be a billing system based on hourly collected data\n> while Synaps is focusing to be a monitoring service which deals with\n> more amount of data more frequently.\n> \n> Thank you,\n> June Yi\n> \n> ------- Original Message -------\n> Sender : Endre Karlson<endre.karlson at gmail.com>\n> Date : 2012-10-11 06:04 (GMT+09:00)\n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> But how does Synaps then difffer from Ceilometer? It looks to be\n> duplicated efforts here?\n> \n> \n> Endre.\n> \n> \n> 2012/10/10 Joonwon Lee <joonwon7.lee at samsung.com>\n> \n> Hi, Eoghan,\n> 1. No, we don\'t have any relation with ceilometer.\n> 2. Cassandra and Storm (as explained in\n> http://wiki.openstack.org/Synaps)\n> 3. As far as I understand, aggregation is performed lazily on the\n> request.\n>  (Metrics are collected every minute and aggregated according to the\n>  request.)\n> \n> Deok-June Yi can explain with more details tomorrow, if you want.\n> Thanks,\n> Joonwon Lee\n> \n> \n> ------- Original Message -------\n> Sender : Eoghan Glynn<eglynn at redhat.com>\n> \n> Date : Oct 10, 2012 21:14 (GMT+09:00)\n> \n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> \n> \n> Hi Joonwon Lee,\n> \n> > Unfortunately, we could not attend the Design Summit. We also need\n> > some time\n> > before opening our source codes, mostly for our internal process.\n> > We\n> > will try to shorten this time.\n> \n> It\'s unfortunate you guys won\'t be at the summit, as it would have\n> been great to discuss in that forum.\n> \n> But that said, the quicker you can push the code through your\n> internal\n> process, the better.\n> \n> \n> > Now we\'re preparing the overview of our project and other\n> > documentation.\n> > If you have any questions, feel free to ask them at any time.\n> \n> A few immediate questions that spring to mind:\n> \n> 1. Are you re-using any of the ceilometer[1] infrastructure for\n>    your metrics collection pipeline?\n> \n> 2. What technology is the metrics store based on, at a high level?\n>    (e.g. RDBMS accessed via sqlalchemy, noSQL store such as MongoDB,\n>     etc.)\n> \n> 3. How are you performing datapoint aggregation? (e.g. eagerly on\n>    metric ingestion, versus lazily on get)\n> \n> Cheers,\n> Eoghan\n> \n> [1] http://ceilometer.readthedocs.org/en/latest/architecture.html\n> \n> \n> > Here are answers of June Yi for Steven Hardy\'s questions below.\n> > > - Is the metric collection secure/authenticated?\n> > > - Are metrics collected from the hypervisors or in-instance?\n> > > - Can service monitoring (in instance) metrics be collected?\n> > > - Is the API authenticated (ie via keystone ec2 credentials?)\n> >\n> > All metrics are collected using the API. The API is authenticated\n> > via\n> > auth\n> > module came from Nova.Authenticate WSGI middleware which supports\n> > AWS\n> > signature v2. It works well with LdapDriver. But we did not tested\n> > if\n> > it is\n> > working with keystone yet.\n> >\n> > Default metrics (i.e. CPUUtilization, disk IO, network IO) are\n> > collected\n> > from hypervisors. Custom metrics can be collected from in-instance\n> > or\n> > any other source.\n> >\n> > Regards,\n> > --\n> > Joonwon Lee, principal software engineer, Samsung SDS\n> >\n> >\n> > ------- Original Message -------\n> > Sender : Eoghan Glynn\n> \n> > Date : 2012-10-10 18:59 (GMT+09:00)\n> > Title : Re: [openstack-dev] Introducing Synaps project that\n> > provides\n> > AWS CloudWatch compatible API\n> >\n> >\n> >\n> > > > > I\'m working for Synaps project that provides AWS CloudWatch\n> > > > > compatible API at Samsung SDS.\n> > > > > Currently, we have plan to open the project to the community.\n> > > > >\n> > > > > Here I introduce Synaps project:\n> > > > > http://wiki.openstack.org/Synaps\n> > > >\n> > > > Details are a bit scarce but at first glance there seem to be\n> > > > an\n> > > > overlap\n> > > > with the CloudWatch work in the Heat project ?\n> > >\n> > > There certainly seems to be from the description, but pretty hard\n> > > to\n> > > evaluate until we see some code ;)\n> >\n> > Yes, I would second that.\n> >\n> > Once the code is out the open, the community will be much better\n> > placed\n> > to judge which approach will make sense to concentrate efforts on.\n> >\n> > June Yi - are you planning on attending the design summit?\n> >\n> > Cheers,\n> > Eoghan\n> >\n> >\n> > > > Any chance the two groups could meet at the Design Summit next\n> > > > week\n> > > > and\n> > > > make sure we don\'t duplicate effort here ?\n> > > >\n> > > > Angus Saskeld has a session on CloudWatch in the Incubation\n> > > > room:\n> > > > http://openstacksummitfall2012.sched.org/event/60b0bcf1253efcb3dd72dff531d59d26\n> > >\n> > > Angus Salkeld and Steve Dake will be at the Summit and could\n> > > discuss,\n> > > also\n> > > possible overlap with metric collection in ceilometer (has been\n> > > discussed\n> > > previously).\n> > >\n> > > I have several questions which will be make/break for the heat\n> > > usage\n> > > of\n> > > Cloudwatch:\n> > >\n> > > - Is the metric collection secure/authenticated?\n> > > - Are metrics collected from the hypervisors or in-instance?\n> > > - Can service monitoring (in instance) metrics be collected?\n> > > - Is the API authenticated (ie via keystone ec2 credentials?)\n> > >\n> > > Many more questions, need to see code and evaluate if we could\n> > > use\n> > > this for\n> > > heat or if we continue with our own implementation.\n> > >\n> > > --\n> > > Steve Hardy\n> > > Red Hat Engineering, Cloud\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n',NULL,NULL),('<1343296020.2465.246.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-26 10:47:00',3600,'2012-07-26 09:47:00',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','On Thu, 2012-07-26 at 04:43 -0400, Eoghan Glynn wrote:\n> > Context for others - Jay asked for feedback on some API change\n> > guidelines which he and David have been working on. See here:\n> > \n> >   http://etherpad.openstack.org/Hn8rKP7XgB\n> > \n> > So ... kudos for kicking this off. I think it\'ll help a lot to get this\n> > stuff written down - e.g. consistency in reviews and to give confidence\n> > to users that we do care about API compat.\n> \n> Agreed, the current version on etherpad is a *great* start, and will be\n> an excellent resource if we continue to codify the group wisdom as it \n> evolves.\n> \n> Just one suggestion, can we put the guidelines under version control,\n> in the style of the HACKING.rst?\n> \n> So, I\'ve just added a small clarification to the etherpad, and there\'s\n> nothing to stop anyone else adding their particular slant, without it\n> necessarily reflecting the group consensus.\n> \n> Whereas putting the thing in git at least ensures some oversight on\n> changes. Obviously the guideline should apply across all projects, but\n> I think it would be OK to just stick the file into the nova repo\n> (with the understanding that there\'s broader applicability).\n\nI think the next step is to put it on the wiki.\n\nI\'m not worried about people editing it - especially if they\'re adding\nexamples. Any major change in the guidelines that wasn\'t first discussed\ncould be easily reverted.\n\nCheers,\nMark.\n\n\n\n','<1665665799.3303153.1343292232492.JavaMail.root@redhat.com>',NULL),('<1343298104.2465.249.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-26 11:21:44',3600,'2012-07-26 10:21:44',NULL,'[openstack-dev] [nova] proposal: nova IRC meeting','On Wed, 2012-07-25 at 10:07 -0400, Sean Dague wrote:\n> I think it would be really good to get a weekly nova IRC meeting spun \n> up, run by the nova PTL, much like some of the newer openstack projects \n> have.\n> \n> It would be a place for people working on blueprints and bugs to check \n> in (letting others no where they could use help), and give the PTL a \n> chance to bring up his/her hottest issues they would like worked. It \n> might also be a good place to get nova core people aware of reviews that \n> are languishing (I think the current model of \"harass core reviewers \n> until they break down and take time to look at your patch\" isn\'t really \n> scalable. :) )  And it would give new folks a chance to learn the \n> culture of the team, and get them integrated.\n\nYeah, I think it would be a good idea. I\'d like to more discussion\nbetween nova-core folks on blueprints, reviews and bugs.\n\nCheers,\nMark.\n\n\n\n','<500FFDB4.8050201@linux.vnet.ibm.com>',NULL),('<1343304280.48860.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-26 05:04:40',-25200,'2012-07-26 12:04:40',NULL,'[Openstack-operators] nova [-] --bridge_interface is require','Hi all,\n\nTo create a network using Quantum Manager, run: \nhttp://docs.openstack.org/trunk/openstack-network/admin/content/Net-Create-dle455.html\n\n$ nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24\nCommand failed, please check log for more info\n2012-07-26 19:59:43 CRITICAL nova [-] --bridge_interface is required to create a network.\n\nWhat does it mean in the error msg?? How to fix it?? TIA\n\nB.R.\nSL\n\n\n\n',NULL,NULL),('<1343314118.28967.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-07-26 07:48:38',-25200,'2012-07-26 14:48:38',NULL,'[Openstack-operators] nova [-] --bridge_interface is require','Hi\nTks for your advice.\n\n$ sudo apt-get install openvswitch-switch\n\n$ sudo ovs-vsctl add-br br-int\nno complaint\n\n$ network_manager=nova.network.quantum.manager.QuantumManager\nno complaint\n\n$ nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24\nCommand failed, please check log for more info\n2012-07-26 22:35:23 CRITICAL nova [-] --bridge_interface is required to create a network.\n\n\nStill the same.\n\nI installed python-quantumclient-2012.2~f1.tar.gz and quantum-2012.2~f2.tar.gz from source.\n\nB.R.\nSL\n\n\n\n----- Original Message -----\n> From: Nirbhay Tomar <nirbhaysinghtomar at gmail.com>\n> To: Stephen Liu <satimis at yahoo.com>\n> Cc: \n> Sent: Thursday, July 26, 2012 9:12 PM\n> Subject: Re: [Openstack-operators] nova [-] --bridge_interface is require\n> \n> Hi,\n> \n> You have to create a bridge interface which you have mentioned in\n> configuration by default it is br-int in ovs by following command:\n> \n> ovs-vsctl add-br br-int\n> \n> after doing this start the quantum agent.\n> \n> this might solve your problem.\n> \n> // nirbhay\n> \n> On Thu, Jul 26, 2012 at 5:34 PM, Stephen Liu <satimis at yahoo.com> wrote:\n>>  Hi all,\n>> \n>>  To create a network using Quantum Manager, run:\n>> \n> http://docs.openstack.org/trunk/openstack-network/admin/content/Net-Create-dle455.html\n>> \n>>  $ nova-manage network create --label=public --fixed_range_v4=8.8.8.0/24\n>>  Command failed, please check log for more info\n>>  2012-07-26 19:59:43 CRITICAL nova [-] --bridge_interface is required to \n> create a network.\n>> \n>>  What does it mean in the error msg?? How to fix it?? TIA\n>> \n>>  B.R.\n>>  SL\n>> \n>> \n>>  _______________________________________________\n>>  OpenStack-operators mailing list\n>>  OpenStack-operators at lists.openstack.org\n>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<CAGypPdcK78civU6SExrvUkHz3CEGcGbrFNLMkFGygoXot0MCMA@mail.gmail.com>',NULL),('<1343320556.2465.271.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-26 17:35:56',3600,'2012-07-26 16:35:56',NULL,'[OpenStack Foundation] Individual Nominations for Foundation\n Board of Directors','Hi Rick,\n\nOn Thu, 2012-07-26 at 10:37 -0500, Rick Clark wrote:\n> Who is the election official, running this election.  Nomination should\n> be an open process, similar to the core dev process.  It is currently\n> closed and subject to manipulation.\n> \n> I would also suggest that if you are a candidate, you must not be\n> managing the process.\n\nAll reasonable points, especially for future elections.\n\nHowever, I think Jonathan deserves a break on this - trying to quickly\nbootstrap something means you can\'t get everything perfect. I\'d prefer\nto see rapid progress rather than a perfect process for the bootstrap\nelection.\n\nAssuming we can all trust that everyone is acting in good faith ...\n\nCheers,\nMark.\n\n\n\n','<5011644C.8050902@openstack.org>',NULL),('<1343368571.2465.305.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-27 06:56:11',3600,'2012-07-27 05:56:11',NULL,'[openstack-dev] [common] moving manager.py and service.py into\n common','Hi Angus,\n\nOn Fri, 2012-07-27 at 14:19 +1000, Angus Salkeld wrote:\n> Hi\n> \n> If no one else is busy doing $Subject then I\'ll get busy\n> with it. Both Heat and ceilometer use these (in heat we\n> copied it and ceilometer import it directly).\n> \n> I tried starting ceilometer on Fedora and a receint change\n> to one of them made this impossible. So I thought it\'s a good\n> time to move them.\n\nYep, and they\'re copied into Cinder too. Sounds like a good candidate as\npart of the fight on our lame copying-and-pasting :)\n\nI\'d start by thinking about the use cases that are generally\napplication.\n\ne.g. looking at manager.py, I see:\n\n  1) loading the DB driver and providing db access via \"self.db\"\n\n  2) plugin loading\n\n  3) RPC dispatcher\n\n  4) Somewhere to register periodic, recurring jobs\n\n  5) The init_host() hook\n\n  6) Misc bits like \'self.host\'\n\nThe one to be wary of is the DB stuff, since that requires code which\nisn\'t already in common.\n\nservice.py looks a lot more daunting in terms of making it more general\n- e.g. report_state() is very nova specific.\n\nThe way I\'d love to see these things done would be for a very basic\nversion of this stuff added to common first and then, over time, we pull\nin support for more use cases. Just copying the whole thing piecemeal\ndoesn\'t give us that same opportunity to sit back and think how to make\nit more generally useful so that the likes of glance or keystone can use\nit too.\n\nCheers,\nMark.\n\n\n\n','<20120727041945.GA30265@redhat.com>',NULL),('<1343384384.16086.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-27 11:19:44',3600,'2012-07-27 10:19:44',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','Hey,\n\nOn Thu, 2012-07-26 at 16:51 -0400, David Kranz wrote:\n> In order to let interested people subscribe to and more easily follow \n> changes to this document I have moved it to\n> \n> http://wiki.openstack.org/Governance/Proposed/Policy%20for%20Changes%20to%20OpenStack%20APIs\n\nI don\'t think we could describe these guidelines as \"policy\" at this\npoint - they\'re in their infancy and what we really want to do is\nencourage people to help expand these guidelines into something that is\nreally useful for developers and reviewers.\n\nIMHO, the PPB could help at this point by:\n\n  1) Reinforce for everyone that the project is committed to API\n     stability. I don\'t see any evidence of disagreement about that, but\n     I guess stating it formally as a policy would remove any doubt.\n\n  2) Encourage the use and continued development of the guidelines \n     we\'ve come up with so far\n\nSo, how about splitting it up? Propose this statement addressing (1) and\n(2) as a policy:\n\n  http://wiki.openstack.org/Governance/Proposed/APIStability\n\nand develop the actual guidelines here:\n\n  http://wiki.openstack.org/APIChangeGuidelines\n\nCheers,\nMark.\n\n\n\n','<5011ADBD.8010705@qrclab.com>',NULL),('<1343393685.16086.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-27 13:54:45',3600,'2012-07-27 12:54:45',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','On Fri, 2012-07-27 at 08:49 -0400, David Kranz wrote:\n> Mark, I am perfectly OK with that. Please don\'t read too much into the \n> location. I just wanted to move from the randomly-named etherpad to a \n> more stable place and discovered there was a similarly-themed proposal \n> from a while back in that wiki location. I used the template there \n> because it was easy but this  is still just a working document. The PPB \n> doesn\'t need to be involved with the details of the guidelines.\n> \n> With regard to your point (1), I think the major disagreement about \n> whether OpenStack has a commitment to API stability comes from outside. \n> An official statement from the PPB would help. As you said, we need to \n> flesh out the guidelines to help us actually implement that commitment. \n> I would also add:\n> \n> (3) Reinforce for every one that API stability is a priority for \n> OpenStack as a whole, not individual projects.\n\nOk, great. I\'ve added it to the PPB page ... hopefully that\'s the right\nway to get it onto their agenda :)\n\nhttp://wiki.openstack.org/Governance/PPB\n\nCheers,\nMark.\n\n\n\n','<50128E5B.30200@qrclab.com>',NULL),('<1343558635.2478.34.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-29 11:43:55',3600,'2012-07-29 10:43:55',NULL,'[OpenStack Foundation] [Openstack] Individual Member Elections','Hi Atul,\n\nOn Sun, 2012-07-29 at 07:21 +0000, Atul Jha wrote:\n\n> We\'ve learned that someone may have violated the basic principles that\n> hold this community together by trying to affect the nominations for\n> the Individual Member elections. This is not what our community stands\n> for, and we do not want to let the actions of one or a few tarnish the\n> reputation of the thousands of individuals who are working to make\n> OpenStack a great place to develop open source software. We are so\n> determined to uphold our values that every member--individual or\n> corporate--agrees to a code of conduct that prohibits abusive behavior\n> and attempts to manipulate our elections.\n\nWell said, we cannot allow the entire community to be tainted by the\nbehaviour of an individual.\n\n> Our bylaws and election process have been defined and overseen by very\n> experienced, independent legal counsel, Mark Radcliffe.\n\nMy understanding from:\n\n  http://www.gossamer-threads.com/lists/openstack/foundation/14647\n\nis that Mark was \"retained to provide additional independent legal\nadvice\" to the drafting committee.\n\n>  We are completely committed to ensuring this process is open, fair\n> and legitimate in accordance with our bylaws and Delaware corporate\n> law. To ensure that the process is open, fair and legitimate, we are\n> looking for individuals who would like to volunteer to be inspectors\n> through the duration of the election to certify the outcome along with\n> our counsel. No more than two affiliated members (working for the same\n> company) can be inspectors, and any candidates who wish to run for\n> election are also ineligible to be inspectors. As stated in the\n> bylaws, \"Each inspector, before entering upon the discharge of his\n> duties, shall take and sign an oath to faithfully execute the duties\n> of inspector with strict impartiality and according to the best of his\n> ability.\" This will require a firm time commitment from any\n> volunteers, as they will need to be available at a\n>   number of points through the process to fulfill their duties in a\n> timely manner. If you are interested in being an inspector, let me\n> know.\n> \n> Any complaints or concerns about the election process are taken\n> extremely seriously. Each complaint will be reviewed by our\n> independent counsel and addressed or brought before the full Board at\n> its first meeting as appropriate. To facilitate reporting we have\n> created an email address that is received only by the Foundation\'s\n> independent counsel for review: electionmonitor at openstack.org\n> \n> We are also working on process improvements for nominations and\n> elections--more details on that coming soon. In the meantime, please\n> speak up or contact me or Mark Radcliffe directly if you have any\n> concerns. We have all come a very long way in establishing the\n> OpenStack Foundation--our Foundation--and are right on the threshold\n> of having it up and running. Now is the time for us all to pull\n> together and to make sure we continue to build the kind of inclusive,\n> supportive community that has come so far in the last 2 years.\n\nI don\'t mean to give offence, but I must admit the above strikes me as\nrather bizarre.\n\nThe role \"inspector\" you refer to above seems to be about an individual\nwho may be appointed to make a written report of a meeting and any\nvoting that happens there, including by proxy.\n\nYou are laying out a mechanism for handling complaints about the\nelection process which involves Mark Radcliffe being the sole recipient\nof those complaints. I know neither what your current role in the\nFoundation is nor how Mark was appointed to this position.\n\nFurther, the mechanism above does not address the issue at hand - how\nshould the Foundation handle a complaint about a member of our\ncommunity[1]?\n\nPersonally, I assume good good faith and there\'s some reasonable\nexplanation for how this all came about, but we need to be careful here\n- having people (apparently arbitrarily) assume roles in the Foundation\nand establish new processes doesn\'t help matters IMHO.\n\n...\n\nSeeing the brouhaha on twitter last night, I had hoped the target of the\nallegation would be named and we could sort this out in the open.\nHowever, a name doesn\'t appear forthcoming and the text of the complaint\nitself has been deleted.\n\nGiven the code of conduct that members are subject:\n\n  http://wiki.openstack.org/Governance/Foundation/CommunityCodeOfConduct\n\nand the bit about \"OpenStack members ... are ultimately accountable to\nthe OpenStack Board of Directors\", I think the way forward is for the\ncomplaint to be made formally to the board so that they can investigate\nthe matter and report on their actions to address it.\n\nThe bylaws name Jonathan Bryce, Mark Collier and Alice King as the\n\"Initial Board\". The complaint should be made to them.\n\nIf the complainant isn\'t satisfied with that and can\'t make the\ncomplaint public, then we may need another process. That would need some\nopen discussion to figure out and IMHO may just be that the complaint is\ntaken to a meeting of the corporate members who have been working to\nestablish the Foundation.\n\nRegards,\nMark.\n\n[1] - the target of the complaint was not named, so I\'m assuming for now\nwe\'re not talking about a \"director, officer and employee of the\nFoundation\" who would be subject to:\n\n  http://wiki.openstack.org/Governance/Foundation/CodeOfConduct\n\n\n\n','<0790F7C009AF7C40B43D459485FC7CA71F050BD0@INCHEAM-MBX02.ad.csscorp.com>',NULL),('<1343559505.2478.41.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-07-29 11:58:25',3600,'2012-07-29 10:58:25',NULL,'[OpenStack Foundation] [Openstack] Individual Member Elections','On Sun, 2012-07-29 at 11:43 +0100, Mark McLoughlin wrote:\n> Hi Atul,\n> \n> On Sun, 2012-07-29 at 07:21 +0000, Atul Jha wrote:\n>   \n> > We are also working on process improvements for nominations and\n> > elections--more details on that coming soon. In the meantime, please\n> > speak up or contact me or Mark Radcliffe directly if you have any\n> > concerns. We have all come a very long way in establishing the\n> > OpenStack Foundation--our Foundation--and are right on the threshold\n> > of having it up and running. Now is the time for us all to pull\n> > together and to make sure we continue to build the kind of inclusive,\n> > supportive community that has come so far in the last 2 years.\n> \n[..]\n> You are laying out a mechanism for handling complaints about the\n> election process which involves Mark Radcliffe being the sole recipient\n> of those complaints. I know neither what your current role in the\n> Foundation is nor how Mark was appointed to this position.\n\nWow. See how important it is to properly quote emails? :-(\n\nMy apologies to all. I see now that Jonathan sent the original email.\nThat makes a whole lot more sense.\n\nI hope this gets resolved quickly.\n\nRegards,\nMark.\n\n\n\n','<1343558635.2478.34.camel@sorcha>',NULL),('<1343640709.8748.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-30 10:31:49',3600,'2012-07-30 09:31:49',NULL,'[openstack-dev] Hiding complexity of paste config files from\n operators','Hi Lorin,\n\nOn Sun, 2012-07-29 at 21:28 -0400, Lorin Hochstein wrote:\n> Assuming that the *-paste.ini files always need to be there, is there\n> some way we could avoid requiring admins to edit these files, and\n> instead make it more like editing the .conf files?\n\nI\'d like us to get to a point where it\'s highly unusual for admins to\nneed to modify the PasteDeploy files.\n\nFor example, in glance the most commonly used pipelines are pre-defined\nin the PasteDeploy file and the admin chooses one of those in\nglance-api.conf by setting e.g.\n\n  [paste_deploy]\n  flavor = keystone\n\nThis should probably be documented in glance-api.conf itself.\n\nNova has something similar where the auth_strategy option in nova.conf\nchooses one of:\n\n  [composite:openstack_compute_api_v2]\n  use = call:nova.api.auth:pipeline_factory\n  noauth = ...\n  keystone = ...\n  keystone_nolimit = ...\n\nI think the last remaining common use case for modifying the PasteDeploy\nfiles is to configure keystone\'s authtoken middleware. At the last\ndesign summit we briefly discussed allowing this to be configured via\ncfg options using the global ConfigOpts object - i.e. this would allow\nthe configuration for the middleware to come from nova.conf:\n\n  in keystone/middleware/auth_token.py:\n\n    from openstack.common import cfg\n\n    CONF = cfg.CONF\n\n    opts = [\n        cfg.StrOpt(\'auth_host\', default=\'127.0.0.1\'),\n        cfg.IntOpt(\'auth_port\', default=35357),\n        cfg.StrOpt(\'auth_protocol\', default=\'http\'),\n        cfg.StrOpt(\'auth_uri\', default=None),  # default=\'$auth_protocol://$auth_host:$auth_port\'\n        cfg.BoolOpt(\'delay_auth_decision\', default=False),\n        cfg.StrOpt(\'admin_token\'),\n        cfg.StrOpt(\'admin_user\'),\n        cfg.StrOpt(\'admin_password\'),\n        cfg.StrOpt(\'admin_tenant_name\', default=\'admin\'),\n        cfg.ListOpt(\'memcache_servers\'),\n        cfg.IntOpt(\'token_cache_time\', default=300),\n    ]\n    CONF.register_opts(opts, group=\'keystone_authtoken\')\n    ...\n    class AuthProtocol(object):\n        ...\n        def _conf_get(self, name):\n            if name in self.conf:\n                return self.conf[name]\n            else:\n                return CONF.keystone_authtoken[name]\n\n  in nova.conf:\n\n      [keystone_authtoken]\n      auth_host = 127.0.0.1\n      auth_port = 35357\n      auth_protocol = http\n      admin_tenant_name = admin\n      admin_user = admin\n      admin_password = badpassword\n\nCheers,\nMark.\n\n\n\n','<0952654E-ACE5-4AF9-8EED-C17AC336D31E@nimbisservices.com>',NULL),('<1343640994.8748.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-30 10:36:34',3600,'2012-07-30 09:36:34',NULL,'[openstack-dev] Hiding complexity of paste config files from\n operators','On Mon, 2012-07-30 at 11:12 +0200, Thierry Carrez wrote:\n> Lorin Hochstein wrote:\n> > I wanted to discuss the usability of the paste config files from an\n> > operator\'s point of view. The paste config files are opaque to\n> > administrators who are trying to stand an OpenStack cloud for the first\n> > time, since they expose a lot of implementation details about the\n> > middleware. I can follow the instructions in the Install and Deploy\n> > guide, but I have no idea what the options I don\'t edit are, and if the\n> > documentation has deviated from the implementation, I\'m pretty much stuck.\n> > [...]\n> \n> This was mentioned in the \"Making configuration easier\" session on the\n> DevOps track at the last design summit. You can find the notes at:\n> \n> http://etherpad.openstack.org/FolsomMakingConfigurationEasier\n> \n> In particular, it was identified that paste configs were evil, failing\n> to properly separate service/code configuration from end-user configuration.\n> \n> > Assuming that the *-paste.ini files always need to be there, is\n> > there some way we could avoid requiring admins to edit these files,\n> > and instead make it more like editing the .conf files? For example,\n> > could the paste.ini files be generated from the corresponding .conf\n> > file as needed?\n> \n> I would not assume that *-paste.ini files always need to be there...\n> Paste is a pain point if we are to support Python 3 one day, so it\'s\n> also on the black list of the (still inexistant) OpenStack Python3\n> advocacy group.\n> \n> So I\'d rather investigate a solution that solves our two problems,\n> rather than adding a layer on top of the current broken solution... That\n> said I\'m not really a specialist of Paste alternatives.\n\nLooks like termie took a stab at it:\n\n  https://github.com/termie/shred\n\nCheers,\nMark.\n\n\n\n','<50164FE6.2020208@openstack.org>',NULL),('<1343759890.3218.50.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-31 13:38:10',-18000,'2012-07-31 18:38:10',NULL,'[openstack-dev] [nova] Team meeting details','On Tue, 2012-07-31 at 11:21 -0700, Vishvananda Ishaya wrote:\n> I\'ve been thinking about a simple way to solve this issue, and I\'ve\n> come up with a spec[2] that i think is workable. I\'d like to get some\n> decisions on the following at the meeting:\n> \n> a) is this approach acceptable?\n>  * does it need to be modified slightly?\n>  * is renaming the badly named extensions ok?\n>  * is there a more general approach that extensions could use?\n> b) is there an alternative to this that is easier/better?\n>  * alternative: bump minor version of the api?\n> c) who wants to help on produce the required code in the next week?\n> d) who wants to help update the documentation?\n> e) who wants to investigate xml?\n\nI unfortunately won\'t be able to make it to the meeting, however, I\nwanted to contribute a few comments on this.  The primary comment I have\nis that it should be possible, with a few tweaks, to extend the XML\ntemplates stuff such that it can decode from XML, as well as encode to\nXML; this would make it possible to create an extensible XML decoder for\nsomething like servers.  This would likely go a long way to addressing\nthe problem you\'ve brought up.\n\nThe second comment I have would be far more oriented to OS-APIv3: Let\'s\nplan on just removing the XML support altogether.  My argument for this\nis simple: if you examine the extensions that have been contributed, you\nwill discover that several of the more recently contributed ones don\'t\nhave XML templates, which means that the developers that have\ncontributed them probably aren\'t concerned with supporting XML, and that\nthe reviewers who approved them aren\'t either; under those conditions,\nour XML support is going to suffer bitrot over time, and I feel we\nshould try to nip the problem in the bud for v3.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<16FAB602-8813-4364-8703-A652A1442571@gmail.com>',NULL),('<1343832152.3218.56.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-01 09:42:32',-18000,'2012-08-01 14:42:32',NULL,'[openstack-dev] [nova] Team meeting details','On Wed, 2012-08-01 at 01:33 -0400, Jay Pipes wrote:\n> Yeah. A few things pop to mind:\n> \n> 1) I think extensions should have a version all their own. Right now,\n> there is no versioning of an extension\'s REST API and therefore there is\n> no safeguard in place to prevent backwards-incompatible API changes in\n> an extension.\n\nThey do.  Extensions have an \"updated\" class attribute which contains a\ndate and time in ISO-8601 format.  That is, admittedly, clunky, and I\npersonally would prefer a number or dotted-number version format.\n\n> 2) Get rid of the os: prefix. It\'s silly and confusing. It can be\n> misinterpreted to mean \"operating system\" and if it means \"OpenStack\",\n> then its redundant -- what descriptive value does it denote?\n\nWell, it\'s meant to differentiate extensions that are possible future\nfirst-class elements of the API from vendor-specific elements.  Would\nyou prefer \"osapi\"?\n\n> 3) Get rid of the concept of \"admin extensions\". An extension is an\n> extension. Whether or not it is an administrative action is entirely up\n> to the deployer and what they set in the policy.json files.\n\nActually, the situation is already exactly as you describe here: an\n\"admin extension\" is merely an extension with policy configured to allow\naccess to admins.  We seem to be using the term \"admin extension\" merely\nto convey to users that a particular extension is intended for\nadministrators.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5018BFAC.4010703@gmail.com>',NULL),('<1343832817.3218.61.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-01 09:53:37',-18000,'2012-08-01 14:53:37',NULL,'[openstack-dev] Allow defining a different auth strategy for\n different service providers.','On Wed, 2012-08-01 at 12:11 +0200, Chmouel Boudjnah wrote:\n> assuming you have this in a file in your PYTHON_PATH named :\n> \n> openstack_client_auth_rackspace2_0.py\n> \n> and connect with :\n> \n> from novaclient.v1_1 import client\n> cnx = client.Client(\"user\", \"password\", \"notneeded\",\n> \n> \"https://lon.identity.api.rackspacecloud.com/v2.0\",\n>                     auth_strategy=\"rackspace2_0\")\n\nYou should also take a look at the entry points provided by\npkg_resources.  We could define an \"openstack.auth\" entry point, and\nyour example could then be done by having the following in setup.py:\n\n        from setuptools import setup\n        setup(\n            ?\n            entry_points={\n                \'openstack.auth\': [\n                    \'rackspace2_0 = rackspace.auth:authenticate\',\n                    ],\n                },\n            ?\n            )\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAPeWyqyf6Cz43Wh9obfX2bB4JTnxuVajiOrUtJs9=D64+nieKg@mail.gmail.com>',NULL),('<1343856686.8748.138.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 22:31:26',3600,'2012-08-01 21:31:26',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 12:37 -0700, Benjamin Black wrote:\n> why are employees of platinum and gold member companies allows to run\n> at all given that the point of the individual seats is to expand\n> representation to include those unable to pay to play? \n\nDirectors elected by the Individual Members should serve to represent\nthe Individual Members on the board. Directors appointed by Platinum or\nGold Members are explicitly there to represent the interests of their\ncompanies.\n\nIt\'s not all that different from contributing successfully to an\nopen-source project. You learn to switch between two hats - your\n\"company hat\" and your \"project hat\" - and focus on the interests of\nyour company or the project as appropriate.\n\nPersonally, I will only be voting for candidates who I think understand\nthe distinction and will wear their \"project hat\" at all times on the\nboard.\n\nCheers,\nMark.\n\n\n\n','<CA+Vbu7x8BO+tenL7qR6fBJOG86KdUmafVYBjn8wc1anS1V8v_g@mail.gmail.com>',NULL),('<1343856984.8748.141.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 22:36:24',3600,'2012-08-01 21:36:24',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 14:26 -0700, Benjamin Black wrote:\n> One of the growing pains of moving from a tightly-controlled project\n> run by a company to an open and inclusive one run by a foundation is\n> accepting that there are no longer any individual entitlements,\n> regardless of contribution.\n\nSay what? In order for the project to be open and inclusive, employed\ncontributors must at all times represent their employer rather than\nthemselves? I must be misunderstanding your point?\n\nMark.\n\n\n\n','<CA+Vbu7zs-y=ANMDMRgU7QMQ4np+_74AsLa1aCiWFECLW5EU6AQ@mail.gmail.com>',NULL),('<1343859318.8748.162.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 23:15:18',3600,'2012-08-01 22:15:18',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 14:52 -0700, Benjamin Black wrote:\n> On Wed, Aug 1, 2012 at 2:36 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > On Wed, 2012-08-01 at 14:26 -0700, Benjamin Black wrote:\n> >> One of the growing pains of moving from a tightly-controlled project\n> >> run by a company to an open and inclusive one run by a foundation is\n> >> accepting that there are no longer any individual entitlements,\n> >> regardless of contribution.\n> >\n> > Say what? In order for the project to be open and inclusive, employed\n> > contributors must at all times represent their employer rather than\n> > themselves? I must be misunderstanding your point?\n> >\n> \n> You are.  As part of being open and inclusive, major contributors to\n> the project must be prepared to not get the organizational leadership\n> positions they want or feel they deserve.\n\nThat\'s an odd statement. OpenStack prides itself on being a meritocracy\nwhere leadership positions are awarded based on how much the individual\ndeserves it based on their contributions.\n\n> The elections for the\n> individual board seats is not a referendum on the contributions or\n> value to the project of the nominees and should not be turned into\n> one.  Similarly, being appointed to the board does not also make\n> someone a committer (and glad we all should be of that).\n\nThe election is a referendum on the candidate\'s value as a director on\nthe board of the foundation. That is clearly separate from any\ncandidate\'s value as a contributor of code the project.\n\nI would expect those who contribute most to technical leadership of the\nproject to be awarded seats on the Technical Committee. And, similarly,\nthose who contribute most to the mission of the foundation to be awarded\nwith seats on the board.\n\nMark.\n\n\n\n','<CA+Vbu7xGyG4yG1kFTxGkQqCKSqyx1YXQKp88sYO+cygNW8ymcw@mail.gmail.com>',NULL),('<1343860728.67914047@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 18:38:48',-14400,'2012-08-01 22:38:48',NULL,'[OpenStack Foundation] Nomination Process Updates','Correction:  The by laws call for the use of the Cumulative Method for this election:  http://en.wikipedia.org/wiki/Cumulative_voting\n\nIANAL but my understanding is that this was a good solution that also works under Delaware law.\n\n\n\nOn Wednesday, August 1, 2012 6:29pm, \"Stefano Maffulli\" <stefano at openstack.org> said:\n\n> On 08/01/2012 03:17 PM, Matt Joyce wrote:\n>> You are assuming a binary set.\n>>\n>> In the event that :\n>>\n>> 25% vote for A\n>> 17% vote for B\n>> 35% vote for C\n>> 23% vote for D\n>>\n>> If 35% the majority vote is 95% one block of individual, the loudest\n>> minority wins.  This is a problem.\n> \n> We\'ll be using the Condorcet voting system, as we do for PTL and PPB\n> elections in the past. There is no 25% vote for A or B. There is a\n> matrix of preferences... Wikipedia explains it:\n> \n> https://en.wikipedia.org/wiki/Condorcet_method\n> \n> A Condorcet method is any election method that elects the candidate that\n> would win by majority rule in all pairings against the other candidates,\n> whenever one of the candidates has that property.\n> \n> hth\n> /stef\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<5019ADE2.5080909@openstack.org>',NULL),('<1343862284.945631026@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 19:04:44',-14400,'2012-08-01 23:04:44',NULL,'[OpenStack Foundation] Nomination Process Updates','I agree with you 100% Monty.\n\n\nOn Wednesday, August 1, 2012 6:58pm, \"Monty Taylor\" <mordred at inaugust.com> said:\n\n> \n> \n> On 08/01/2012 05:47 PM, Eric Windisch wrote:\n>>>\n>>> That\'s, you know campaigning. It doesn\'t involve collusion to elect\n>>> a board of 8 other people. For them to send an email:\n>>\n>> Yes, I agree. I may not have been clear enough. My point was that\n>> collusion isn\'t even necessary for HP or Rackspace to benefit from\n>> their power of vote.\n>>\n> \n> Fair point. I suppose I don\'t accept the assumption that Rackspace or HP\n> _have_ a power of vote. They only have employees, all of whom are free\n> to individually chose whoever they want to.\n> \n> Now, that we may have blocks of fake people (even if they are real) so\n> that non-involved employees can be used to attempt to swing an election\n> in a particular manner is a theoretically troublesome issues.\n> \n> However, it turns out that we\'re just talking about vote tampering, and\n> in a system where we have election monitors to validate the vote, that\'s\n> not that hard to deal with - especially in a voting system such as what\n> we\'re looking for.\n> \n> Turns out, in any given population, one would expect an amount of\n> variance in the vote. If 350 from HP all ranked their top 8 candidates\n> exactly the same, I think a little bit of data mining would show that to\n> be the case. In our case, we happen to have some very smart (and very\n> pedantic) people working as election monitors. So I\'m betting that they\n> will enjoy looking for such things.\n> \n> It\'s also possible that I believe in strong free will more than other\n> people ...\n> \n> Monty\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<5019B4B3.3040002@inaugust.com>',NULL),('<1343862746.8748.199.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 00:12:26',3600,'2012-08-01 23:12:26',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 15:28 -0700, Benjamin Black wrote:\n> On Wed, Aug 1, 2012 at 3:15 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > On Wed, 2012-08-01 at 14:52 -0700, Benjamin Black wrote:\n> >> On Wed, Aug 1, 2012 at 2:36 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> >> > On Wed, 2012-08-01 at 14:26 -0700, Benjamin Black wrote:\n> >> >> One of the growing pains of moving from a tightly-controlled project\n> >> >> run by a company to an open and inclusive one run by a foundation is\n> >> >> accepting that there are no longer any individual entitlements,\n> >> >> regardless of contribution.\n> >> >\n> >> > Say what? In order for the project to be open and inclusive, employed\n> >> > contributors must at all times represent their employer rather than\n> >> > themselves? I must be misunderstanding your point?\n> >> >\n> >>\n> >> You are.  As part of being open and inclusive, major contributors to\n> >> the project must be prepared to not get the organizational leadership\n> >> positions they want or feel they deserve.\n> >\n> > That\'s an odd statement. OpenStack prides itself on being a meritocracy\n> > where leadership positions are awarded based on how much the individual\n> > deserves it based on their contributions.\n> >\n> \n> We\'re voting for the board, it\'s not a meritocracy, no matter how much\n> we might like it to be.\n\nI would hope that people will vote for directors based on the\ncontribution they think a candidate will make to the mission of the\nfoundation.\n\nWhy would anyone vote someone to the board who they don\'t think would\nmake a valuable contribution to the foundation?\n\nSo, absolutely these 8 seats should be awarded by the foundation\nindividual membership based on merit.\n\n> >> The elections for the\n> >> individual board seats is not a referendum on the contributions or\n> >> value to the project of the nominees and should not be turned into\n> >> one.  Similarly, being appointed to the board does not also make\n> >> someone a committer (and glad we all should be of that).\n> >\n> > The election is a referendum on the candidate\'s value as a director on\n> > the board of the foundation. That is clearly separate from any\n> > candidate\'s value as a contributor of code the project.\n> >\n> > I would expect those who contribute most to technical leadership of the\n> > project to be awarded seats on the Technical Committee. And, similarly,\n> > those who contribute most to the mission of the foundation to be awarded\n> > with seats on the board.\n> >\n> \n> Board seats are not awarded.\n\nThese 8 seats are awarded by Individual Members through their voting in\nthe election.\n\n> They are purchased by companies or won by individuals.  My commitment\n> is to maximizing inclusion of the community who are otherwise excluded\n> due to the cost of the paid seats.  2/3 of the board is there to\n> represent the member companies. That seems quite sufficient, to me.\n\nCompletely agree. The Individual Member directors should represent the\ninterests of the project and all the Individual Members, not their\ncompany.\n\nMark.\n\n\n\n','<CA+Vbu7wMqzuEoeGSOrC_ii5U+UroW_fBGqyv_QwhQQB3LWNHPQ@mail.gmail.com>',NULL),('<1343862862.8748.200.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 00:14:22',3600,'2012-08-01 23:14:22',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 16:02 -0700, Benjamin Black wrote:\n> The question there is not whether _you_, or any other specific person,\n> can be trusted to act independently of their employer.  The question\n> is whether permitting member company employees to hold individual\n> seats _in general_ will serve the community and the project over the\n> long-term.  In this I take a pretty liberal view of the democratic\n> process: I am much more trusting of the electorate and much less\n> trusting of the candidates. \n\nTrust the electorate to figure out which of the candidates can act\nindependently of their employer, then.\n\nMark.\n\n\n\n','<CA+Vbu7zVDcqNrpVw9VPddh0sEMhaWiAC0RCi73656hipCuDQ6w@mail.gmail.com>',NULL),('<1343873787.57182665@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 22:16:27',-14400,'2012-08-02 02:16:27',NULL,'[OpenStack Foundation] Nomination Process Updates','> Their purpose is exactly to give a voice to members of the community who\n> would otherwise be excluded because of the cost of the corporate\n> seats.\n\nI think this is a fundamental misunderstanding.  \n\nThe definition of \"individual members\" (and their associated seats on the board), has been on the wiki since early this year and it is clearly described there, as well as in the by laws, as being inclusive of people who are paid to work on it (such as by member companies). \n\nThe wiki:\n\n\"Individual Members\n\n\"Individual Members\" who participate on their own or as part of their paid employment. It is free to join as an Individual Member and Individual Members have the right to run for, and vote for, a number of leadership positions. Characteristics of Individual Members:\n\nContribute to OpenStack in a variety of ways such as code, documentation, translations, bug reports, testing, project infrastructure, advocacy, marketing, community management, legal guidance\n\nExpected to be constructive & courteous, adhering to a community code of conduct\n\nWear the OpenStack hat and always act with integrity\n\nElect representatives to Board, Technical Committee and PTL positions (if they are also project contributors)\"\n\n\nand in the by laws it\'s even more explicit:\n\n\"2.2 Individual Members.  \n\n(a) Individual Members must be natural persons. Individual Members may be any natural person who has an interest in the purpose of the Foundation and may be employed by Platinum Members or Gold Members. \"\n\nWith respect to the risk of one company dominating the board, that was raised during the process, and the conclusion reached was to add a 2 seat limit per affiliation out of the 24 total seats.  \n\nI can appreciate the fact that someone coming into the discussion now may look at past decisions and disagree (especially without all of the context), but this approach has been discussed and iterated openly for several months and is reflected in the published by laws. If there is sufficient demand to amend the by laws, there is a process for that (in the by laws, naturally!).\n\nPersonally I feel very good about the list of nominees we have today, and know many of them well enough to know they will do a great job on the Board of Directors, regardless of their affiliation with member companies.  \n\nMark\n@sparkycollier\n512-791-0356\n\n\n\n\nOn Wednesday, August 1, 2012 8:55pm, \"Benjamin Black\" <b at b3k.us> said:\n\n> On Wed, Aug 1, 2012 at 5:42 PM, Monty Taylor <mordred at inaugust.com> wrote:\n>>\n>>\n>> On 08/01/2012 07:03 PM, George Reese wrote:\n>>>\n>>> On Aug 1, 2012, at 6:45 PM, Monty Taylor <mordred at inaugust.com\n>>> <mailto:mordred at inaugust.com>> wrote:\n>>>\n>>>>\n>>>> Nope. Still don\'t stipulate this point. If a vote came up to the board\n>>>> that would cost HP a billion dollars but that made sense for OpenStack\n>>>> and is something I would vote for it I worked elsewhere,  I would still\n>>>> vote for it without blinking an eye.\n>>>>\n>>>> I will stipulate that in general, it is possible that employers do exert\n>>>> influence over employees, and that policy might need to take that in to\n>>>> account. I will not stipulate that employers always influence employees.\n>>>\n>>> I did not say they always influence employees.\n>>>\n>>> I said they can (and sometimes will) influence employees. Shouldn\'t we\n>>> have a few board positions that are free of that possibility of influence?\n>>\n>> You know - I\'d support the existence of a number of seats that are for\n>> that purpose - as long as it isn\'t ALL of the at-large seats.\n>>\n> \n> They are not at-large seats, they are individual member seats.  Their\n> purpose is exactly to give a voice to members of the community who\n> would otherwise be excluded because of the cost of the corporate\n> seats.  I want those seats used for their intended purpose.  While\n> eliminating the possibility of undue influence by a corporate member\n> is clearly out of the question, taking reasonable steps to reduce\n> opportunities for it and increase opportunities for wider community\n> participation is worthwhile.  Excluding corporate member employees\n> from the individual member seats is such a reasonable step.\n> \n> \n> b\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<CA+Vbu7wKkFgOX-PxxMQdJ6TovT3Ju=me0t_yaJWeTR4s1L_pFA@mail.gmail.com>',NULL),('<1343874591.67267901@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 22:29:51',-14400,'2012-08-02 02:29:51',NULL,'[OpenStack Foundation] Nomination Process Updates','This was actually addressed in the original message by Jonathan Bryce that started this thread:\n\n\"We have had three community members volunteer to help define and administer the election in response to the request for inspectors. If at any point you have questions concerning the nomination or election process, you can contact the inspectors at electioninspectors at openstack.org.\"\n\nIn other words, those folks are working to define it now.  \n\nI was just quoting from the by laws (as I\'m known to do) about the requirement to use cumulative voting to clear up any confusion.\n\nMark\n\n\n\nOn Wednesday, August 1, 2012 6:44pm, \"Andrew Clay Shafer\" <acs at parvuscaptus.com> said:\n\n> Mark,\n> \n> Can you please explain the specific mechanics that will be used for the\n> voting?\n> \n> And preferably post them somewhere prominent.\n> \n> Thanks,\n> Andrew\n> \n> On Wed, Aug 1, 2012 at 6:38 PM, Mark Collier <mark at openstack.org> wrote:\n> \n>> Correction:  The by laws call for the use of the Cumulative Method for\n>> this election:  http://en.wikipedia.org/wiki/Cumulative_voting\n>>\n>> IANAL but my understanding is that this was a good solution that also\n>> works under Delaware law.\n>>\n>>\n>>\n>>\n> \n\n\n\n\n','<CALC1uEM53uPfbUYF8Qhz4=gLw7Dvs6Gxr9y1kbZyyy9UGhy9XA@mail.gmail.com>',NULL),('<1343887526.8748.201.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 07:05:26',3600,'2012-08-02 06:05:26',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 16:21 -0700, Benjamin Black wrote:\n> I would support a proposal to eliminate all paid\n> seats, as well, though I doubt that would be very popular. \n\nThe time for supporting that has passed and, no, it wasn\'t very\npopular :)\n\nhttp://wiki.openstack.org/StrawmanFoundationStructure\n\nMark.\n\n\n\n','<CA+Vbu7w5_1qrWu2Za2jU06dU96R15nRLsURCCRO5hydV+9KhEQ@mail.gmail.com>',NULL),('<1343888383.8748.205.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 07:19:43',3600,'2012-08-02 06:19:43',NULL,'[OpenStack Foundation] Nomination Process Updates','On Wed, 2012-08-01 at 17:55 -0700, Benjamin Black wrote:\n> They are not at-large seats, they are individual member seats.  Their\n> purpose is exactly to give a voice to members of the community who\n> would otherwise be excluded because of the cost of the corporate\n> seats.  I want those seats used for their intended purpose. \n\nTheir purpose is to give a voice to individuals.\n\nEven individuals who are employed by a company which isn\'t a platinum or\ngold member should serve to represent the interest of project and the\nIndividual Members. It is not a way for companies to get a seat without\npaying membership fees.\n\nMark.\n\n\n\n','<CA+Vbu7wKkFgOX-PxxMQdJ6TovT3Ju=me0t_yaJWeTR4s1L_pFA@mail.gmail.com>',NULL),('<1343911565.8748.233.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-02 13:46:05',3600,'2012-08-02 12:46:05',NULL,'[OpenStack Foundation] Nomination Process Updates','Just a random thought on the criteria for being an individual member ...\n\nOn Wed, 2012-08-01 at 22:16 -0400, Mark Collier wrote:\n\n> \n> The definition of \"individual members\"\n[...]\n> \n> The wiki:\n> \n[...]\n> Characteristics of Individual Members:\n> \n> Contribute to OpenStack in a variety of ways such as code,\n> documentation, translations, bug reports, testing, project\n> infrastructure, advocacy, marketing, community management, legal\n> guidance\n[...]\n> and in the by laws [...]\n> \n> \"2.2 Individual Members.  \n> \n> (a) Individual Members must be natural persons. Individual Members may\n> be any natural person who has an interest in the purpose of the\n> Foundation\n[...]\n\nThe wiki clearly says that individual members should have contributed to\nOpenStack in some form. I like that, and I have no problem with the\ndefinition of \"contributed\" being extremely inclusive.\n\nHowever, the bylaws watered that down to \"has an interest\" and AFAIK\nwe\'re taking \"applied for membership\" as enough to demonstrate an\ninterest.\n\nGiven the 700+ RAX and HP members, was this too inclusive? Would all of\nthose meet the criteria in the wiki? If not, how can we correct the\nprocess now or in the future?\n\nI like Lauren\'s idea of making people fill in a \"why you\'re interested\nin OpenStack\" blurb and publishing it. I also like the approach of\nhaving an open membership committee[1] with clear guidelines.\n\nCheers,\nMark.\n\n[1] - e.g. https://live.gnome.org/MembershipCommittee/\n\n\n\n','<1343873787.57182665@emailsrvr.com>',NULL),('<1343971367.8748.250.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-03 06:22:47',3600,'2012-08-03 05:22:47',NULL,'[OpenStack Foundation] Nomination Process Updates','On Thu, 2012-08-02 at 20:37 -0400, Doug Davis wrote:\n> And exactly who is going to be the judge of what\'s \'good enough\'?\n\nThe idea is to have a public registry of foundation members which\nincludes each members\' answers. People are much less likely to give\ninadequate answers if they will be public.\n\nThe alternative is a membership committee like\nhttps://live.gnome.org/MembershipCommittee/\n\nMark.\n\n\n\n','<OFCED68C71.ED813088-ON85257A4F.00030FF0-85257A4F.00036C88@us.ibm.com>',NULL),('<1344005845.3218.78.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-03 09:57:25',-18000,'2012-08-03 14:57:25',NULL,'[openstack-dev] [Netstack] Request for comments on a pep8\n	problem','On Fri, 2012-08-03 at 17:48 +0300, Gary Kotton wrote:\n> Will you also be fixing the pep8 issues in the common code?\n\nWhen the pep8 running in openstack-common reports the issue, yes, it\nwill make sense to fix it.  Since I have already synchronized nova and\nglance, I\'m highly reluctant to make the necessary change.  I\'ll also\npoint out that the particular condition that pep8 is reporting here is\nall over the place in nova and probably also in glance?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<501BE4B1.70507@redhat.com>',NULL),('<1344007479.15619.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-03 16:24:39',3600,'2012-08-03 15:24:39',NULL,'[openstack-dev] openstack-common library release [was Re:\n [Netstack] Request for comments on a pep8 problem]','On Fri, 2012-08-03 at 10:16 -0500, Monty Taylor wrote:\n> On 08/03/2012 09:57 AM, Kevin L. Mitchell wrote:\n> > On Fri, 2012-08-03 at 17:48 +0300, Gary Kotton wrote:\n> >> Will you also be fixing the pep8 issues in the common code?\n> > \n> > When the pep8 running in openstack-common reports the issue, yes, it\n> > will make sense to fix it.  Since I have already synchronized nova and\n> > glance, I\'m highly reluctant to make the necessary change.  I\'ll also\n> > point out that the particular condition that pep8 is reporting here is\n> > all over the place in nova and probably also in glance?\n> \n> If we keep openstack-common testing against latest pep8 (even when it\'s\n> a pita) it should allow us to drop that code into any of the projects\n> without worrying about which version they\'ve caught up to.\n\nYeah, I\'m fine with us using latest pep8.\n\n> Also - I hear that one of these days we\'re going to make a library out\n> of openstack common ... how\'s that coming Mark?\n\nThere are two parts - figuring out which APIs are ready for the\nbackwards compat commitment and sorting out the pure mechanics of doing\nthe library release.\n\nI was mostly blocked on the first part and this week took a look at the\nRPC API to see if it\'s ready:\n\n  https://blueprints.launchpad.net/openstack-common/+spec/rpc-api-review\n\nThe summary from a first review is that it\'s not too far away, but does\nneed more work. Just doing a thorough review is pretty time consuming,\nthough, nevermind fixing the issues themselves.\n\nTalking it over with Russell, we thought it might make sense to tackle\nthe second part of the problem first - if e.g. we\'re happy with the\nstate of cfg, we could do an initial library release with just that and\nbe happy we have the mechanics sorted out. Then we can iterate through\nreviews of the other APIs and add them to future releases.\n\nCheers,\nMark.\n\n\n\n','<501BEB62.7060006@inaugust.com>',NULL),('<1344107190.97087287.1389293776665.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 13:56:16',-18000,'2014-01-09 18:56:16',NULL,'[openstack-dev] os-*-config in tripleo repositories','\n\n----- Original Message -----\n> From: \"Derek Higgins\" <derekh at redhat.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, January 9, 2014 8:13:53 AM\n> Subject: [openstack-dev] os-*-config in tripleo repositories\n> \n> It looks like we have some duplication and inconsistencies on the 3\n> os-*-config elements in the tripleo repositories\n> \n> os-apply-config (duplication) :\n>    We have two elements that install this\n>      diskimage-builder/elements/config-applier/\n>      tripleo-image-elements/elements/os-apply-config/\n> \n>    As far as I can tell the version in diskimage-builder isn\'t used by\n> tripleo and the upstart file is broke\n> ./dmesg:[   13.336184] init: Failed to spawn config-applier main\n> process: unable to execute: No such file or directory\n> \n>    To avoid confusion I propose we remove\n> diskimage-builder/elements/config-applier/ (or deprecated if we have a\n> suitable process) but would like to call it out here first to see if\n> anybody is using it or thinks its a bad idea?\n> \n> inconsistencies\n>   os-collect-config, os-refresh-config : these are both installed from\n> git into the global site-packages\n>   os-apply-config : installed from a released tarball into its own venv\n> \n>   To be consistent with the other elements all 3 I think should be\n> installed from git into its own venv, thoughts?\n\nThese all sound good to me and I\'ve got no issues with cleaning these up.\n\nI\'m not the biggest fan of having multiple venv\'s for each component though. Especially now that we have a global requirements.txt file where we can target a common baseline. Multiple venvs causes lots of duplicated libraries and increased image build time. Is anyone planning on making consolidated venv\'s an option? Or perhaps even just using a consolidated venv as the default where possible.\n\n> \n> If no objections I\'ll go ahead an do this next week,\n> \n> thanks,\n> Derek.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52CEA091.7000307@redhat.com>',NULL),('<1344322252.3319.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 07:50:52',3600,'2012-08-07 06:50:52',NULL,'[openstack-dev] openstack-common library release [was Re:\n [Netstack] Request for comments on a pep8 problem]','On Fri, 2012-08-03 at 13:45 -0400, Doug Hellmann wrote:\n\n> I was thinking a single namespace package \"openstack\" with\n> single-level nested packages such as openstack.config,\n> openstack.messaging (to include rpc and notifications),\n> openstack.server (service and manager-related stuff, maybe also the\n> wsgi stuff). The \"common\" feels a little redundant.\n\nI wasn\'t convinced the first time you suggested it, but I\'m warming to\nthe idea :)\n\nWhen an API like cfg, rpc or server is ready to come out of incubation\nwe just move it from openstack.common to openstack.config or whatever.\nWe\'d also move it into a separate git repo.\n\n> OTOH, it would be even better if we came up with names that didn\'t\n> include \"openstack\" in the distro or package name. That would help\n> avoid the Zope-branding issue that keeps other projects from adopting\n> a lot of the useful components that came out of the Zope project just\n> because they are apparently tied to Zope. Of course, naming is one of\n> the hard problems in compsci. :-)\n\nI suspect a lot or stuff will be only used by OpenStack project, but\nit\'s a fair point that there\'s no reason to necessarily exclude the\npossibility.\n\nNaming ... How about Oslo? Short, begins with \"OS\" and \"lo\" has a vague\nconnotations of \"base\" or \"foundation\".\n\n  pip install oslo\n\n  from oslo.config import cfg\n  from oslo.messaging import rpc\n\nCheers,\nMark.\n\n\n\n','<CADb+p3RzFtYrcMxogYpk4n_kgxjmrf8OBhd0-cmNUf+HZOtkVA@mail.gmail.com>',NULL),('<1344323161.3319.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 08:06:01',3600,'2012-08-07 07:06:01',NULL,'[openstack-dev] [common] moving manager.py and service.py into\n common','On Fri, 2012-07-27 at 11:22 -0400, Jay Pipes wrote:\n\n> I\'d also love to see standardization around the binding of services to\n> sockets. In Nova-land, each service has its own nova.conf value -- for\n> example, there is a host/port pair for each of nova-os-api,\n> nova-ec2-api, nova-metadata-api, etc: (see [1])\n> \n> osapi_compute_listen=0.0.0.0\n> osapi_compute_listen_port=8774\n> ec2_listen=0.0.0.0\n> ec2_listen_port=8773\n> metadata_listen=0.0.0.0\n> metadata_listen_port=8775\n> \n> There are also nova.conf options that duplicate the above (not sure if\n> these even are used any more...):\n> \n> ec2_host=$my_ip\n> ec2_port=8773\n> metadata_host=$my_ip\n> metadata_port=8775\n> \n> as well as this pair for the nova-objectstore service:\n> \n> s3_host=$my_ip\n> s3_port=3333\n> \n> In every other core project -- Glance, Swift, Keystone, Cinder and\n> Quantum -- only the following options are used:\n> \n> bind_host=0.0.0.0\n> bind_port=XXXX\n\nNot quite :)\n\nCinder follows Nova\'s lead because it copied and pasted Nova\'s code.\n\nQuantum has followed Glance\'s lead because it copied and pasted Glance\'s\ncode.\n\nKeystone has bind_host and public_port/admin_port.\n\nSwift is quite similar to Glance, yes - bind_ip and bind_port.\n\n> and each service has its own paste deploy INI file and configuration\n> file containing the bind_host/bind_port options for the particular service.\n>\n> I would love it if Nova could standardize on using bind_host/bind_port\n> for all of its services that listen on TCP sockets as well. That way, we\n> can put the get_socket() call that originated in Swift and exists in\n> Glance as well, into a openstack.common.wsgi module.\n\nI don\'t think it\'s unreasonable for a single process to expose multiple\nAPIs bound to different ports. That, at least, means that you need to\nsupport configuring multiple ports in the one file.\n\nWe could use sections for this e.g.\n\n  [DEFAULT]\n  bind_host = 127.0.0.1\n\n  [osapi_compute]\n  bind_port = 8774\n\n  [osapi_compute]\n  bind_port = 8776\n\n  [ec2]\n  bind_port = 8773\n\n  [metadata]\n  bind_port = 8775\n\ni.e. we\'d try bind_host/bind_port in a section corresponding to the\nservice name and fall back to bind_host/bind_port in DEFAULT if not set.\n\nCheers,\nMark.\n\n\n\n','<5012B225.4000506@gmail.com>',NULL),('<1344323288.3319.23.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 08:08:08',3600,'2012-08-07 07:08:08',NULL,'[openstack-dev] openstack-common library release [was Re:\n [Netstack] Request for comments on a pep8 problem]','On Fri, 2012-08-03 at 13:40 -0400, Jay Pipes wrote:\n> I\'d prefer smaller, reusable libs as well. Unfortunately, the decision\n> to use global CONF objects has essentially made the config module an\n> interdependency between all the other common code, so at a minimum, the\n> config module would need to be a dep in the other libs.\n\nYes, most openstack-common modules depend on cfg.\n\nBut this isn\'t because of the global config object. The dependency is\nthere because we want to allow modules to define configuration options.\n\nCheers,\nMark.\n\n\n\n','<501C0D01.8010700@gmail.com>',NULL),('<1344337662.3319.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 12:07:42',3600,'2012-08-07 11:07:42',NULL,'[openstack-dev] openstack-common library release [was Re:\n [Netstack] Request for comments on a pep8 problem]','On Tue, 2012-08-07 at 06:55 -0400, Doug Hellmann wrote:\n> \n> On Aug 7, 2012, at 3:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > On Fri, 2012-08-03 at 13:40 -0400, Jay Pipes wrote:\n> >> I\'d prefer smaller, reusable libs as well. Unfortunately, the decision\n> >> to use global CONF objects has essentially made the config module an\n> >> interdependency between all the other common code, so at a minimum, the\n> >> config module would need to be a dep in the other libs.\n> > \n> > Yes, most openstack-common modules depend on cfg.\n> > \n> > But this isn\'t because of the global config object. The dependency is\n> > there because we want to allow modules to define configuration options.\n> \n> Unfortunately it means the modules are going to be harder to reuse\n> outside of OpenStack because instead of providing a class-based API\n> that takes individual arguments that can come from another\n> application\'s config, or even a single config object as argument, the\n> global object needs to be initialized correctly.\n\nYes, agree. But I don\'t see \"enable reuse outside of OpenStack\" as much\nof a priority here.\n\nOur focus should be on OpenStack\'s copy-and-paste technical debt rather\nthan general re-usability. Allowing modules to add config parameters is\na pragmatic approach to get us moving forward but, if we design the APIs\nwell, we should be able to extend them later so that the config options\ncan be overridden by API users.\n\nCheers,\nMark.\n\n\n\n','<04B3E422-FBAC-4130-BD9A-C0CABFB046DF@dreamhost.com>',NULL),('<1344342084.14.1374300301734.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-20 06:05:01',0,'2013-07-20 06:05:01',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #292','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/292/>\n\n------------------------------------------\n[...truncated 9008 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.09 secs:\n    0.37    RoleAPITests.test_get_default_role\n    0.23    HorizonTests.test_lazy_urls\n    0.18    DataTableTests.test_summation_row\n    0.16    DataTableTests.test_table_action_attributes\n    0.15    NetworkTests.test_subnet_create_post_gw_inconsistent\n----------------------------------------------------------------------\nRan 350 tests in 7.333s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.6\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Zbx3aPOLzQ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/292\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/292/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/292/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<417075250.8.1374213976822.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1344346974.3319.60.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-07 14:42:54',3600,'2012-08-07 13:42:54',NULL,'[openstack-dev] stable-maint team updates','Hey,\n\nWhile I was away yesterday, there was some confusion on IRC about the\nstable-maint team so I thought I\'d recap a few things here.\n\nThe team is responsible for approving changes to the currently\nmaintained stable branch of projects which were core in that release -\ni.e. currently stable/essex of keystone, glance, nova, horizon. Swift\nfollows a different release model.\n\nWhen reviewing changes, stable-maint folks concentrate on (a) how\nserious the bug is, (b) how risky the fix is and (c) whether the fix is\nalready on master. The goal is for the stable branch to have a steady\nflow of safe fixes for high-impact bugs.\n\nThe current team members are me, Dave Walker, Chuck Short and the PTLs\n(Vish, Brian Waldon, Joe Heck and Devin Carlen).\n\nWhile I was at it, I took a look at who else was doing reviews of stable\nbranch patches[1] and I\'m going to go ahead and add Ionut Artarisi, Alan\nPevec, P?draig Brady, Ghe Rivero and Eoghan Glynn. Many thanks to them\nfor joining!\n\nI\'ve updated the wiki page to be more clear about how folks can get\ninvolved if they would like to join the team:\n\n  http://wiki.openstack.org/StableBranch#Joining_the_Team\n\n  We\'re really keen to add more folks to the stable-maint team to help \n  out with reviews.\n\n  All you really need is some time and the ability to apply the \"safe\n  source of high impact fixes\" and \"must be fixed on master first\"\n  policies. It mostly comes down to having a good sense of the risk vs\n  benefit of applying a backport to the branch.\n\n  If you\'d like to join the team, you can start by simply [+-]1ing\n  stable branch reviews. It\'s best if you can add some brief thoughts to\n  your review on why you think the fix is suitable for stable so that we\n  know how you\'re applying the policy.\n\n  After doing reviews over a few weeks, email the team and ask to be\n  added. \n\nCheers,\nMark.\n\n[1] - if you\'re interested, here\'s how the new team members have been\nhelping out:\n\nhttps://review.openstack.org/#/q/branch:stable/essex+AND+%28reviewer:mapleoin+OR+owner:mapleoin%29,n,z\nhttps://review.openstack.org/#/q/branch:stable/essex+AND+%28reviewer:apevec+OR+owner:apevec%29,n,z\nhttps://review.openstack.org/#/q/branch:stable/essex+AND+%28reviewer:p-draigbrady+OR+owner:p-draigbrady%29,n,z\nhttps://review.openstack.org/#/q/branch:stable/essex+AND+%28reviewer:ghe.rivero+OR+owner:ghe.rivero%29,n,z\nhttps://review.openstack.org/#/q/branch:stable/essex+AND+%28reviewer:eglynn+OR+owner:eglynn%29,n,z\n\n\n\n',NULL,NULL),('<1344542703.4956.46.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-09 21:05:03',3600,'2012-08-09 20:05:03',NULL,'[openstack-dev] [Openstack] Making the RPC backend a required\n configuration parameter','On Wed, 2012-08-08 at 16:35 -0400, Eric Windisch wrote:\n> I believe that the RPC backend should no longer have any default.\n> \n> \n> \n> Historically, it seems that the Kombu driver is default only because\n> it existed before all others and before there was an abstraction. With\n> multiple implementations now available, it may be time for a change.\n> \n> Why?\n> * A default skews the attitudes and subsequent architectures toward a\n> specific implementation\n\nThat is true. That, presumably, is why we didn\'t have a default for\nconnection_type and don\'t have one now for compute_driver.\n\nWe also default to sqlite when clearly we expect real deployments to\nchose MySQL or Postgres.\n\n> * A default skews the practical testing scenarios, ensuring maturity\n> of one driver over others.\n\nThe default is more likely to be tested, yet.\n\n> * The kombu driver does not work \"out of the box\", so it is no more\n> reasonable as a default than impl_fake.\n\nThe fake driver does not \"work\" out of the box either, except maybe in\nthe case of nova-all.\n\nI\'d actually prefer no default rather than fake.\n\n> * The RPC code is now in openstack-common, so addressing this later\n> will only create additional technical debt.\n\nIt will be harder to change after we release this code as the\noslo-messaging library, yes.\n\n> My proposal is that for Folsom, we introduce a \"future_required\" flag\n> on the configuration option, \"rpc_backend\". This will trigger a\n> WARNING message if the rpc_backend configuration value is not set.  In\n> Grizzly, we would make the rpc_backend variable mandatory in the\n> configuration.\n\nRussell makes a very valid point about backwards compat. Configuration\nfiles where the user hasn\'t specified rpc_backend will no longer work.\nThat\'s something we want to avoid doing without good reason.\n\nI\'m a fan of sane defaults. Rabbit isn\'t a sane default for anyone who\nhas rabbitmq-server running, Qpid is a sane default for anyone with\nqpidd running and I guess ZeroMQ is sane for anyone with zeromq\ninstalled. Can we just do the right thing if rpc_backend isn\'t set?\n\nSimilarly, I\'d love to try and have a sane default for compute driver -\ne.g. detect if there\'s a local libvirtd running or whatever.\n\nAlso, in the cases of compute driver, database and messaging we have\nmultiple implementations that we consider equally well supported. Dan\nPrince has helped make sure all of those options are tested using\nSmokestack, but we still have a greater emphasis on particular\nimplementations because of what devstack-gate uses.\n\n</waffle>\n\nOn the whole, I think I\'m persuaded. Having no default is better than\ndefaulting to rabbit. The compute driver default and the fact we default\nto sqlite sets a precedent that makes sense to follow here. A\ndeprecation period helps with the backwards compat concerns.\n\nWe should handle the deprecation issue by making nova warn if\nrpc_backend isn\'t set. It probably makes sense to just make it required\nright away for e.g. Cinder, Quantum and Glance though.\n\nCheers,\nMark.\n\n\n\n','<606206A0BADB4E13BABB52D7E06E7804@cloudscaling.com>',NULL),('<1344576501.4956.77.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-10 06:28:21',3600,'2012-08-10 05:28:21',NULL,'[openstack-dev] [nova] Call for Help -- OpenStack API XML\n Support','On Thu, 2012-08-09 at 18:20 -0500, George Reese wrote:\n> It goes to the complete clown show that Nebula team is running with\n> respect to OpenStack development.\n\nTone it down on this list or we\'ll have to start actively enforcing our\ncode of conduct[1]. Do you want to be the first person censured under\nit? We could name the \"be respectful\" clause after you if you like?\n\nThese kind of attacks are completely out of line on a mailing list where\npeople are trying to work together and get stuff done.\n\nMark.\n\n[1] - http://wiki.openstack.org/Governance/Foundation/CommunityCodeOfConduct\n\n\n\n','<D427F867-AD0B-4194-9868-763802FA2590@imaginary.com>',NULL),('<1344592744.4956.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2012-08-10 10:59:04',3600,'2012-08-10 09:59:04',NULL,'[Openstack-announce] [ANNOUNCE] OpenStack Nova,\n	Glance and Keystone 2012.1.2 released','Hey,\n\nIn the time since the Essex release, we have been busy selectively\nback-porting bugfixes to the stable/essex branch according to our \"safe\nsource of high-impact fixes\" criteria documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nWe made a first round of those fixes available in the 2012.1.1 release 6\nweeks ago and now we\'re happy to announce a 2012.1.2 release!\n\nThese releases are bugfix updates to Essex and are intended to be\nrelatively risk free with no intentional regressions or API changes.\n\nThe list of bugs fixed can be seen here:\n\n  https://launchpad.net/nova/+milestone/2012.1.2\n  https://launchpad.net/glance/+milestone/2012.1.2\n  https://launchpad.net/keystone/+milestone/2012.1.2\n\nPlease read (and add to!) the release notes at:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.1.2\n\nEnjoy!\n\nMark.\n\n\n\n\n',NULL,NULL),('<1344608700.3218.110.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-10 09:25:00',-18000,'2012-08-10 14:25:00',NULL,'[openstack-dev] [Openstack] Making the RPC backend a required\n configuration parameter','On Thu, 2012-08-09 at 15:55 -0400, Eric Windisch wrote:\n> They would only break in Grizzly, following a one-release depreciation\n> schedule. During Folsom, if they run Folsom, they\'ll only get\n> warnings.  When it becomes required, if they haven\'t yet updated their\n> configuration, and if they don\'t see it clearly stated in\n> release-notes, they\'ll discover the change quickly within their\n> testing.\n\n<pet-peeve>The word is \"deprecation,\" not \"depreciation\"; we are saying\nan interface is going away (\"deprecation\"), not that its financial value\nis decreasing (\"depreciation\")?</pet-peeve>\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<192B8E162CE44667AD7BC518BEBFCF1E@cloudscaling.com>',NULL),('<1344610649.3218.116.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-10 09:57:29',-18000,'2012-08-10 14:57:29',NULL,'[openstack-dev] [Openstack] [nova] Call for Help -- OpenStack\n API XML Support','On Fri, 2012-08-10 at 13:47 +0100, Daniel P. Berrange wrote:\n> I don\'t know this area of Nova code at all, but I must say I\'m\n> surprised that it actually needs explicit extra work to accept\n> or output XML, instead of JSON. It should be possible to auto\n> generate an XML document from a JSON document, and vica-verca.\n> At which point you\'d not need to have 2 sets of tests for JSON\n> vs XML, all you need test is the XML<->JSON conversions.\n\nUnfortunately, it\'s not at all that simple.  The XML spec and JSON spec\nare not precisely identical matches in all respects, so a mindless\ntranslation is insufficient to generate XML compliant with our spec.  It\nis possible to build a translator to XML?see for example the XML\nTemplates code I contributed?but I certainly wouldn\'t call it simple.\nThis is one of the reasons I favor dropping XML from the next spec\n(v3?).\n\n> If we can get to a position where we auto-generate XML from JSON for Nova,\n> we could do the same for other projects too\n\nWhile this would represent an ideal situation, I\'m not 100% convinced\nyet that this can actually be done.  Also, don\'t forget that we have to\ndeal with the deserialization side as well; our current deserialization\nmethod is hand-coded XML tree walkers that convert string values to\ntheir expected representation.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<20120810124744.GD26807@redhat.com>',NULL),('<1344611807.3218.125.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-10 10:16:47',-18000,'2012-08-10 15:16:47',NULL,'[openstack-dev] [nova] Call for Help -- OpenStack API XML\n Support','On Fri, 2012-08-10 at 08:01 -0500, Christopher B Ferris wrote:\n> The next sentence in HACKING.rst goes a step further and requires that\n> bug fixes for features that lack unit tests add them. Given that the \n> XML API code has been around for a while, it begs the question: why is\n> the coverage so poor? Collectively, we need to fix both the symptom\n> and the underlying cause. \n\nIt\'s important to note that the unit test coverage is not poor; for\nalmost everything for which there\'s an XML template, there is also unit\ntests covering that template serialization.  (The weasel word is only\nbecause I haven\'t done a thorough review to verify my assertion for 100%\nof cases.)  For that matter, when I contributed the XML template code, I\nwent through all existing extensions and created templates, even for\nthose that did not have XML support at the time, and when I do reviews\nfor new extensions, I try to ensure that there is a template for those\nextensions.\n\nThe problem comes from the fact that there are several extensions that\nhave been added which I personally did not review, and for which there\nexists no XML template.  The unit tests are perfectly adequate to test\nthose new extensions, but there is obviously no new serializer, and thus\nno serializer unit tests.  It isn\'t that our test coverage is poor, it\nis that our code is actually deficient, and we reviewers are directly to\nblame for not enforcing that all API extensions must have working and\ntested XML handling.\n\nNote also that the unit tests are orthogonal to the tests being\ndiscussed in this thread, which are _integration_ tests; those test\nsuites are apparently, to date, not testing the XML side of the API.\nRemember also that these test suites are *outside* the nova code base,\nand would also have to be updated to cover any newly-added extension;\nI\'m not currently aware of any process in place which ensures that they\nget updated in that situation.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<OFEA355E76.3C6C33DA-ON86257A56.004780E5-86257A56.004780EB@us.ibm.com>',NULL),('<1344675251.32604.YahooMailNeo@web125103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-11 01:54:11',-25200,'2012-08-11 08:54:11',NULL,'[Openstack-operators] About the directory of keystone admin','Hi all,\n\nI\'m following;\n\nRed Hat Essex Preview\nLab Guide??? \nRed Hat Summit - 2012 Edition\nhttp://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/\n\nto set up OpenStack, Essex, on Fedora 17\n\nI\'m stuck here:\nNow that an admin user has been created, that account can be used to administer keystone. To make it easy to set the admin user\'s credentials in the proper environment variables, create a keystonerc_admin file with the following contents ....\nhttp://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/ch02s02.html\n\nWhere shall I create the file keystonerc_admin?? Where is the admin\'s directory?\n\nPlease help.? TIA\n\nB.R.\nSL\n\n\n\n',NULL,NULL),('<1344855565.47714.YahooMailNeo@web125104.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-13 03:59:25',-25200,'2012-08-13 10:59:25',NULL,'[Openstack-operators] About the directory of keystone admin','Hi Jay,\n\nThanks for your advice.\n\nI have stopped there and rebooted the PC.? Please advise where can I find admin\'s directory?? OR I have to start from the begining again?? Thank\n\n\nB.R.\nSL\n\n\n\n----- Original Message -----\n> From: Jay Pipes <jaypipes at gmail.com>\n> To: openstack-operators at lists.openstack.org\n> Cc: \n> Sent: Monday, August 13, 2012 6:02 AM\n> Subject: Re: [Openstack-operators] About the directory of keystone admin\n> \n> On 08/11/2012 04:54 AM, Stephen Liu wrote:\n>>  Hi all,\n>> \n>>  I\'m following;\n>> \n>>  Red Hat Essex Preview\n>>  Lab Guide? ? \n>>  Red Hat Summit - 2012 Edition\n>>  http://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/\n>> \n>>  to set up OpenStack, Essex, on Fedora 17\n>> \n>>  I\'m stuck here:\n>>  Now that an admin user has been created, that account can be used to \n> administer keystone. To make it easy to set the admin user\'s credentials in \n> the proper environment variables, create a keystonerc_admin file with the \n> following contents ....\n>>  http://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/ch02s02.html\n>> \n>>  Where shall I create the file keystonerc_admin?? Where is the admin\'s \n> directory?\n> \n> Create it in the admin user\'s home directory. You should have a UNIX\n> user that corresponds to the same admin user you created for Keystone.\n> Create the rc file in that user\'s home directory and optionally have the\n> user\'s .profile or .bash_profile file source the rc file.\n> \n> Best,\n> -jay\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<502827E1.4090907@gmail.com>',NULL),('<1344858260.4956.159.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-13 12:44:20',3600,'2012-08-13 11:44:20',NULL,'[openstack-dev] Considerations when adding Nova config options','Hi,\n\nI just noticed we\'ve added a new \'defer_iptables_apply\' configuration\noption to Nova:\n\n  https://bugs.launchpad.net/nova/+bug/1034401\n\nThe default value is False but AFAICT there is no reason why users would\n*not* want to change this to True.\n\nAlso, the docs for the option does nothing to help users decide whether\nthey should change the option:\n\n +    cfg.BoolOpt(\'defer_iptables_apply\',\n +                default=False,\n +                help=\'Whether to batch up the application of IPTables rules\'\n +                     \' during a host restart and apply all at the end of the\'\n +                     \' init phase\'),\n\nI can only see one justification for this being an option - perhaps\nwe\'re unsure about the reliability of this \"defer\" mode and plan to\nswitch to defer mode by default in future and remove the option. If so,\nit would be nice if the docs said something like:\n\n  Set to True to evaluate this new experimental behaviour which is \n  likely to become the default behaviour in a future version.\n\n\nAnother similarish example is where we\'re considering adding an\n\'ignore_attach_device\' option:\n\n  https://bugs.launchpad.net/nova/+bug/1004328\n\nAgain, the default is False but AFAICT there\'s no reason users of the\nlibvirt driver would *not* want to change this to True.\n\nAnd again, the docs give no guidance to users about when they might want\nto change it to True.\n\n\nWe now have roughly 500 configuration options in Nova. That\'s absolutely\ninsane. Especially if some of them are set by default to some known\nbroken value and we don\'t have docs to tell users to change them.\n\nI\'d like us to start rationalizing configuration options - removing\nsome, marking others as \"experimental\", adding more helpful guidance to\nthe docs, etc. - but I\'d really like if we could make a better effort to\nnot make the problem worse in the meantime :-)\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1344866010.6513.31.camel@gashuffer.lobefin.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-13 13:53:34',0,'2012-08-13 13:53:34',NULL,'[Openstack-operators] [Openstack] [Nova] How common is\n	user_data for instances?','Hi,\n\nI think user_data is probably reasonably common - most people who use,\neg, cloud-init will use it (we do).\n\nAs the 64k limit is a MySQL limitation, and not a nova limitation, why\nnot just say, \"if you want more storage, use postgres\" (or similar)?  I\nhave no issue with making the size guarded in the application, with a\nconfigurable limit, but the particular problem that started this off is\nan implementation issue rather than a code issue.\n\nStoring the user_data in some place like the database is fairly\nimportant for making things like launch configs for autoscale groups\nwork.  I\'d like to not make that harder to implement.\n\nCheers,\n\nOn Mon, 2012-08-13 at 09:12 -0400, Dan Prince wrote:\n> \n> ----- Original Message -----\n> > From: \"Michael Still\" <michael.still at canonical.com>\n> > To: openstack at lists.launchpad.net, openstack-operators at lists.openstack.org\n> > Sent: Saturday, August 11, 2012 5:12:22 AM\n> > Subject: [Openstack] [Nova] How common is user_data for instances?\n> > \n> > Greetings.\n> > \n> > I\'m seeking information about how common user_data is for instances\n> > in\n> > nova. Specifically for large deployments (rackspace and HP, here\'s\n> > looking at you). What sort of costs would be associated with changing\n> > the data type of the user_data column in the nova database?\n> > \n> > Bug 1035055 [1] requests that we allow user_data of more than 65,535\n> > bytes per instance. Note that this size is a base64 encoded version\n> > of\n> > the data, so that\'s only a bit under 50k of data. This is because the\n> > data is a sqlalchemy Text column.\n> > \n> > We could convert to a LongText column, which allows 2^32 worth of\n> > data,\n> > but I want to understand the cost to operators of that change some\n> > more.\n> > Is user_data really common? Do you think people would start uploading\n> > much bigger user_data? Do you care?\n> \n> Nova has configurable quotas on most things so if we do increase the size of the DB column we should probably guard it in a configurable manner with quotas as well.\n> \n> My preference would actually be that we go the other way though and not have to store user_data in the database at all. That unfortunately may not be possible since some images obtain user_data via the metadata service which needs a way to look it up. Other methods of injecting metadata via disk injection, agents and/or config drive however might not need it to be store in the database right?\n> \n> As a simpler solution:\n> \n> Would setting a reasonable limit (hopefully smaller) and returning a HTTP 400 bad request if incoming requests exceed that limit be good enough to resolve this ticket? That way we don\'t have to increase the DB column at all and end users would be notified up front that user_data is too large (not silently truncated). They way I see it user_data is really for bootstrapping instances... we probably don\'t need it to be large enough to write an entire application, etc.\n> \n> \n> > \n> > Mikal\n> > \n> > 1: https://bugs.launchpad.net/nova/+bug/1035055\n> > \n> > _______________________________________________\n> > Mailing list: https://launchpad.net/~openstack\n> > Post to     : openstack at lists.launchpad.net\n> > Unsubscribe : https://launchpad.net/~openstack\n> > More help   : https://help.launchpad.net/ListHelp\n> > \n> \n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n\n-- \nStephen Gran\nSenior Systems Integrator - guardian.co.uk\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit guardian.co.uk - newspaper of the year\n\nwww.guardian.co.uk    www.observer.co.uk     www.guardiannews.com \n\nOn your mobile, visit m.guardian.co.uk or download the Guardian\niPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad \n \nSave up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. \nVisit guardian.co.uk/subscribe \n\n---------------------------------------------------------------------\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n\nGuardian News & Media Limited\n\nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n\nRegistered in England Number 908396\n\n\n\n','<1348940401.2660297.1344863520261.JavaMail.root@redhat.com>',NULL),('<1344872144.2849.1.camel@null.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-13 10:35:44',-18000,'2012-08-13 15:35:44',NULL,'[openstack-dev] [Openstack] Does glance-scrubber.conf require\n	sql_connection?','On Mon, 2012-08-13 at 11:33 -0400, Jay Pipes wrote:\n> On 08/12/2012 10:12 PM, Lorin Hochstein wrote:\n> > Doc question:\n> > \n> > Does glance-scrubber require sql_connection?  The Install and Deploy\n> > Guide specifies the sql_connection parameter\n> > <http://docs.openstack.org/essex/openstack-compute/install/apt/content/glance-scrubber-conf-file.html>,\n> > but it wasn\'t clear to me that the scrubber actually makes any queries\n> > against the database. \n> \n> It used to make direct queries against the registry database, but now it\n> makes queries via the registry\'s REST API. So this option can safely be\n> removed now.\n> \n> Jason, do you concur?\n\nI think so, but to be honest I haven\'t looked at it in a while; I\nglanced over the code quickly and didn\'t see any reason not to ;).\n\nHappy Hacking!\n\n7-11\n\n\n\n\n\n','<50291E3B.4070804@gmail.com>',NULL),('<1344873600.217.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-13 09:00:00',-25200,'2012-08-13 16:00:00',NULL,'[Openstack-operators] About the directory of keystone admin','\n\nHi Jay,\n\n> I\'m not understanding you, sorry, Stephen. What user are you logging\n> into the host machine (not the VM) with?\n\nLogin??? satimis\n\nBut I don\'t know whether I need to start from the beginning again.? As the PC has been restarted several time?? \n\nI finished up to;\n\n2.2. Creating Users\nhttp://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/ch02s02.html\n\n$ keystone user-role-add --user 94d659c3c9534095aba5f8475c87091a \\\n? --role 78035c5d3cd94e62812d6d37551ecd6a \\\n? --tenant_id 6f8e3e36c4194b86b9a9b55d4b722af3\n\nThanks\n\nB.R.\nSL\n\n\n>>  ----- Original Message -----\n>>>  From: Jay Pipes <jaypipes at gmail.com>\n>>>  To: openstack-operators at lists.openstack.org\n>>>  Cc: \n>>>  Sent: Monday, August 13, 2012 6:02 AM\n>>>  Subject: Re: [Openstack-operators] About the directory of keystone \n> admin\n>>> \n>>>  On 08/11/2012 04:54 AM, Stephen Liu wrote:\n>>>> ? Hi all,\n>>>> \n>>>> ? I\'m following;\n>>>> \n>>>> ? Red Hat Essex Preview\n>>>> ? Lab Guide? ? \n>>>> ? Red Hat Summit - 2012 Edition\n>>>> ? http://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/\n>>>> \n>>>> ? to set up OpenStack, Essex, on Fedora 17\n>>>> \n>>>> ? I\'m stuck here:\n>>>> ? Now that an admin user has been created, that account can be used \n> to \n>>>  administer keystone. To make it easy to set the admin user\'s \n> credentials in \n>>>  the proper environment variables, create a keystonerc_admin file with \n> the \n>>>  following contents ....\n>>>> ? \n> http://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/ch02s02.html\n>>>> \n>>>> ? Where shall I create the file keystonerc_admin?? Where is the \n> admin\'s \n>>>  directory?\n>>> \n>>>  Create it in the admin user\'s home directory. You should have a \n> UNIX\n>>>  user that corresponds to the same admin user you created for Keystone.\n>>>  Create the rc file in that user\'s home directory and optionally \n> have the\n>>>  user\'s .profile or .bash_profile file source the rc file.\n>>> \n>>>  Best,\n>>>  -jay\n>>> \n>>>  _______________________________________________\n>>>  OpenStack-operators mailing list\n>>>  OpenStack-operators at lists.openstack.org\n>>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>> \n> \n\n\n','<502913DF.9000000@gmail.com>',NULL),('<1344935308.4956.229.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-14 10:08:28',3600,'2012-08-14 09:08:28',NULL,'[openstack-dev] Considerations when adding Nova config options','On Tue, 2012-08-14 at 09:59 +0200, Thierry Carrez wrote:\n> Maybe we could add some category/priority/experimentalness declaration\n> where the option is defined, so that tools could pick it up and use it\n> to generate prettier documentation ?\n\nOne idea I\'ve been toying with is allowing options to be marked as\n\"experimental\" and adding a \"--disable-experimental\" command line\noption. Then we could run with --disable-experimental by default (from\ne.g. init scripts, devstack etc.) so that users have to explicitly\nre-enable the experimental options in nova.conf if they want to use\nthem.\n\nCheers,\nMark.\n\n\n\n','<502A054D.9010008@openstack.org>',NULL),('<1344939490.25212.YahooMailNeo@web125104.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-14 03:18:10',-25200,'2012-08-14 10:18:10',NULL,'[Openstack-operators] About the directory of keystone admin','\n\n\n\n----- Original Message -----\n> From: Jay Pipes <jaypipes at gmail.com>\n> To: Stephen Liu <satimis at yahoo.com>\n> Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org>\n> Sent: Tuesday, August 14, 2012 1:26 AM\n> Subject: Re: [Openstack-operators] About the directory of keystone admin\n> \n\n- snip -\n\n> Yeah, I\'m not talking about the Keystone user or the OpenStack users\n> that spin up VMs. I\'m talking about the UNIX user that has SSH abilities\n> to the host machine that provides the environment for the guest VMs to\n> spawn.\n\nI got it.? Thanks\n\nsatimis\n\n\n\n','<502938C4.4000208@gmail.com>',NULL),('<1345001757.84244.YahooMailNeo@web125102.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-14 20:35:57',-25200,'2012-08-15 03:35:57',NULL,'[Openstack-operators] bash:\n	/srv/rhsummit/images/rhel62_x86_64.qcow2: No such file or directory','Hi all,\n\nFedora 17\n\n\nI\'m following\nhttp://fedorapeople.org/~russellb/openstack-lab-rhsummit-2012/ch03.html\n\nand stuck here:\n\nChapter 3. Glance (Images)\n$ glance add name=\"RHEL 6.2\" is_public=true disk_format=qcow2 \\\n> container_format=bare < /srv/rhsummit/images/rhel62_x86_64.qcow2\nbash: /srv/rhsummit/images/rhel62_x86_64.qcow2: No such file or directory\n\n$ yum list python\nLoaded plugins: langpacks, presto, refresh-packagekit\nadobe-linux-x86_64/primary?????????????????????????????? | 1.2 kB???? 00:00???? \nadobe-linux-x86_64????????????????????????????????????????????????????????? 2/2\nInstalled Packages\npython.x86_64????????????????????? 2.7.3-7.2.fc17?????????????????????? @updates\nAvailable Packages\npython.i686??????????????????????? 2.7.3-7.2.fc17?????????????????????? updates \n\n\n$ ls -al /srv\ntotal 8\ndrwxr-xr-x.? 2 root root 4096 Feb? 3? 2012 .\ndr-xr-xr-x. 18 root root 4096 Aug 15 10:33 ..\n\n\nPlease help.? TIA\n\nB.R.\nSL\n\n\n',NULL,NULL),('<1345018957.4956.284.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 09:22:37',3600,'2012-08-15 08:22:37',NULL,'[openstack-dev] Modelling the creation of multiple networks in\n Nova\'s REST API','On Thu, 2012-07-19 at 14:20 +0100, Mark McLoughlin wrote:\n> Hi,\n> \n> I was just reviewing the code for this:\n> \n>   https://blueprints.launchpad.net/nova/+spec/os-api-network-create\n> \n> You POST to /networks:\n> \n>   {\"network\": {\"vlan_start\": 234, \"cidr\": \"10.70.105.0/24\", \"label\": \"net234\"}}\n> \n> and get back e.g.\n> \n>   {\"networks\": [{..., \"id\": 66085e78-8f6-4a26-b16c-4b1f55901fbd\", ..., \"label\": \"net234\", ..., \"vlan\": 234, ..., \"cidr\": \"10.70.105.0/24\", ...}]}\n> \n> Notice the plural \"networks\" in the response. A single POST may create\n> multiple networks (where e.g. FLAGS.num_networks > 1), but it\'s not\n> clear to me what the use case for this is.\n> \n> The issue with this is that (at least IMHO) POST requests should only\n> create a single resource - e.g. we want to be able to return a 201\n> Created response with a Location header and it would seem bizarre to\n> include multiple location headers.\n\nFor anyone interested, this debate is still rumbling on here:\n\n  https://review.openstack.org/#/c/9847/\n\nI\'ve tried to be pretty clear about my objection to the proposed\nmodelling:\n\n  REST stands for Representational State Transfer\n\n  When you POST to /networks, you are sending a representation of the\n  network resource you want to create\n\n  The sensible thing for a client to expect is that a network resource\n  will be created and for a 201 Created response to include a\n  representation the resource and a Location header with a URI for the\n  resource\n\n  What doesn\'t seem at all sensible is for the server to return a\n  collection of resources, based on \"num_networks\" and \"network_size\"\n  properties in the network representation and also based on the server\n  configuration\n\nOther opinions are most welcome, though.\n\nCheers,\nMark.\n\n\n\n','<1342704037.18575.14.camel@sorcha>',NULL),('<1345021090.4956.291.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 09:58:10',3600,'2012-08-15 08:58:10',NULL,'[openstack-dev] Modelling the creation of multiple networks in\n Nova\'s REST API','On Wed, 2012-08-15 at 12:55 +0400, Oleg Gelbukh wrote:\n> Hello,\n> \n> \n> It seems to me that this call just mimics the behavior of nova-manage\n> utility which allows to create multiple networks for single\n> project/tenant with single CLI command.\n\nYes, but that doesn\'t mean it\'s a sane REST API.\n\nCheers,\nMark.\n\n> --\n> Best regards,\n> Oleg\n> \n> On Wed, Aug 15, 2012 at 12:22 PM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Thu, 2012-07-19 at 14:20 +0100, Mark McLoughlin wrote:\n>         > Hi,\n>         >\n>         > I was just reviewing the code for this:\n>         >\n>         >\n>         https://blueprints.launchpad.net/nova/+spec/os-api-network-create\n>         >\n>         > You POST to /networks:\n>         >\n>         >   {\"network\": {\"vlan_start\": 234, \"cidr\": \"10.70.105.0/24\",\n>         \"label\": \"net234\"}}\n>         >\n>         > and get back e.g.\n>         >\n>         >   {\"networks\": [{..., \"id\":\n>         66085e78-8f6-4a26-b16c-4b1f55901fbd\", ..., \"label\":\n>         \"net234\", ..., \"vlan\": 234, ..., \"cidr\":\n>         \"10.70.105.0/24\", ...}]}\n>         >\n>         > Notice the plural \"networks\" in the response. A single POST\n>         may create\n>         > multiple networks (where e.g. FLAGS.num_networks > 1), but\n>         it\'s not\n>         > clear to me what the use case for this is.\n>         >\n>         > The issue with this is that (at least IMHO) POST requests\n>         should only\n>         > create a single resource - e.g. we want to be able to return\n>         a 201\n>         > Created response with a Location header and it would seem\n>         bizarre to\n>         > include multiple location headers.\n>         \n>         \n>         For anyone interested, this debate is still rumbling on here:\n>         \n>           https://review.openstack.org/#/c/9847/\n>         \n>         I\'ve tried to be pretty clear about my objection to the\n>         proposed\n>         modelling:\n>         \n>           REST stands for Representational State Transfer\n>         \n>           When you POST to /networks, you are sending a representation\n>         of the\n>           network resource you want to create\n>         \n>           The sensible thing for a client to expect is that a network\n>         resource\n>           will be created and for a 201 Created response to include a\n>           representation the resource and a Location header with a URI\n>         for the\n>           resource\n>         \n>           What doesn\'t seem at all sensible is for the server to\n>         return a\n>           collection of resources, based on \"num_networks\" and\n>         \"network_size\"\n>           properties in the network representation and also based on\n>         the server\n>           configuration\n>         \n>         Other opinions are most welcome, though.\n>         \n>         Cheers,\n>         Mark.\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n\n\n\n\n','<CAFkLEwrExdO+jNZBEpnmysujaM28oOFPysojH+wc57dZWW5Lsg@mail.gmail.com>',NULL),('<1345032796.4956.333.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 13:13:16',3600,'2012-08-15 12:13:16',NULL,'[openstack-dev] Porting healthcheck from Swift - feedback?','On Wed, 2012-08-15 at 12:52 +0100, Paul Bourke wrote:\n> Hi all,\n> \n> Swift contains some middleware called \"healthcheck\", with which you may or may\n> not be familiar.  It sits at the front of the pipeline and responds to GETs\n> with 200 under normal circumstances.\n> \n> I have submitted the following blueprint and patchset that ports this\n> functionality to openstack-common for inclusion across multiple Openstack\n> components:\n> \n> https://blueprints.launchpad.net/openstack-common/+spec/port-swift-healthcheck\n> https://review.openstack.org/#/c/11074/\n> \n> There has been some uncertainty as to whether this healthcheck is more valuable\n> than a simple GET/HEAD on the top level service endpoint.  While this could be\n> used, but it may be more consistent to have something which can be checked in\n> the same was across services.\n\nMy own take on this is that consistently supporting HEAD on all our\ntoplevel endpoints is much more obvious to API users than a /healthcheck\nresource.\n\nCheers,\nMark.\n\n\n\n','<20120815115210.GH3243@bourke-z400>',NULL),('<1345046082.4956.360.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-15 16:54:42',3600,'2012-08-15 15:54:42',NULL,'[openstack-dev] [Openstack] Discussion about where to put\n database for bare-metal provisioning (review 10726)','Hi David,\n\nOn Wed, 2012-08-15 at 08:28 -0700, David Kang wrote:\n> \n>  Hi,\n> \n>  This is call for discussion about the code review 10726.\n> https://review.openstack.org/#/c/10726/\n> Mark asked why we implemented a separata database for bare-metal provisioning.\n> Here we describe our thought. \n> We are open to discussion and to the changes that the community recommends.\n> Please give us your thoughts.\n> \n>  NTT Docomo and USC/ISI have developed bare-metal provisioning.\n> We created separate database to describe bare-metal nodes, which consists of 5 tables now.\n> Our initial implementation assumes the database is not a part of nova database.\n> In addition to the reasons described in the comments of the code review,\n> here is another reason we decided a separate database for baremetal provisioning.\n> \n> Bare-metal database is mainly used by bare-metal nova-compute.\n> Since bare-metal nova-compute manages multiple bare-metal machines, \n> it needs to keep/update the information of bare-metal machines.\n> If the bare-metal database is in the main nova db, accessing nova db remotely by\n> bare-metal nova-compute is inevitable.\n> Once Vish told us that shared db access from nova-compute is not desirable.\n> \n> It is possible to make the scheduler do the job of bare-metal nova-compute.\n> However, it would need a big changes in how the scheduler and a nova-compute\n> communicates. For example, currently, the scheduler casts an instance to a\n> nova-compute. But for bare-metal node, the scheduler should cast an instance \n> to a bare-metal machine through bare-metal nova-compute.\n> Bare-metal nova-compute should boot the machine, transfer kernel, fs, etc.\n> So, bare-metal nova-compute should know the id of bare-metal node and other information \n> for booting (PXE ip address, ...) and more.\n> That information should be sent to bare-metal nova-compute by the scheduler.\n> \n> If frequent access of bare-metal tables in nova db from bare-metal nova-compute\n> is OK, we are OK to put the bare-metal tables into nova db.\n> \n>  Please let us know your opinions.\n\nI just posted a comment in gerrit before seeing your mail.\n\nThe big question for me is whether the baremetal DB needs to be shared\nbetween compute nodes.\n\nRight now, it looks like the DB is designed to be shared (e.g. the\nservice_host column in the BareMetalNode) but could we re-work things so\nthat it\'s not shared?\n\nThe big issue with a shared DB is the problems it causes for upgrades\nwhich we\'ve been trying to fix with no-db-compute.\n\nCheers,\nMark.\n\n\n\n','<679740826.830072.1345044514992.JavaMail.root@zm.isi.edu>',NULL);
INSERT INTO `messages` VALUES ('<1345124944.11.1377325491085.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-24 06:24:51',0,'2013-08-24 06:24:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #10','See <https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/10/>\n\n------------------------------------------\n[...truncated 3740 lines...]\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 39.86 secs:\n    9.83    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    8.16    TestTokenRevoking.test_group_membership_changes_revokes_token\n    7.69    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    7.50    TestTokenRevoking.test_removing_role_assignment_does_not_affect_other_users\n    6.68    TestTokenAPIs.test_revoke_token\n----------------------------------------------------------------------\nRan 1300 tests in 564.082s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==2.0\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.10\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.071SV8eANQ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/10/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise30\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise30/10\n[SCP] Copying console log.\n\n\n','<1984526827.5.1377238403507.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1345143737.4956.383.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-16 20:02:17',3600,'2012-08-16 19:02:17',NULL,'[openstack-dev] [Openstack-dev] Copyright headers in source\n files','On Thu, 2012-08-16 at 13:29 -0400, Monty Taylor wrote:\n> \n> On 08/16/2012 01:12 PM, John Griffith wrote:\n> > Hey Everyone,\n> > \n> > A while back there was some discussion taking place in the PPB\n> > meetings regarding copyright headers.  There was some concern as I\n> > recall from lawyers regarding the addition of assigning Copyright to\n> > Openstack LLC etc. (don\'t ask me, I\'m not a lawyer).\n> \n> Yeah. Our CLA does not actually require copyright assignment... however\n> many people shove Openstack LLC in the header, rather than themselves or\n> the company they work for. The right policy for when and how to do that\n> is something that various people who are actually lawyers should\n> probably do some education for people on.\n>\n> > I was wondering if there was ever a solid decision on how we wanted to\n> > proceed with header files?  Are we just including the Apache header,\n> > both or some other form?  Did I misinterpret the topic that was being\n> > discussed?\n> \n> I do not know what decisions may or may not have been made regarding\n> OpenStack LLC usage in copyright headers. However, files all need the\n> Apache header, and they need at least one copyright line (the line\n> asserts who owns the copyright and the header indicates under what\n> license terms they are granting the content to others) Because we do not\n> do copyright assignment, you can expect to see, as the project goes on,\n> a proliferation of different copyright lines, and there will likely be\n> many files with multiple copyright lines. However, if you are in doubt\n> as to what copyright line you should or should not add to files you are\n> hacking on, you should double-check with someone who has more legal\n> clout than I.\n\nMy assumption is that OpenStack LLC indicates the code was written by a\nRackspace developer and Rackspace has blanket assigned its copyright to\nOpenStack LLC (which is owned by Rackspace).\n\nCheers,\nMark.\n\n\n\n','<502D2DDD.7090709@inaugust.com>',NULL),('<1345144114.4956.389.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-16 20:08:34',3600,'2012-08-16 19:08:34',NULL,'[openstack-dev] [Openstack-dev] Copyright headers in source\n files','On Thu, 2012-08-16 at 12:34 -0600, John Griffith wrote:\n> On Thu, Aug 16, 2012 at 11:37 AM, Russell Bryant <rbryant at redhat.com> wrote:\n> > On 08/16/2012 01:12 PM, John Griffith wrote:\n> >> Hey Everyone,\n> >>\n> >> A while back there was some discussion taking place in the PPB\n> >> meetings regarding copyright headers.  There was some concern as I\n> >> recall from lawyers regarding the addition of assigning Copyright to\n> >> Openstack LLC etc. (don\'t ask me, I\'m not a lawyer).\n> >>\n> >> I was wondering if there was ever a solid decision on how we wanted to\n> >> proceed with header files?  Are we just including the Apache header,\n> >> both or some other form?  Did I misinterpret the topic that was being\n> >> discussed?\n> >\n> > First of all, IANAL.  :-)\n> >\n> > I think many cases of people leaving the following at the top of a new\n> > file is due to just copying it from another file:\n> >\n> >     # Copyright (c) 2011 OpenStack, LLC.\n> >\n> > IMO, whenever someone creates a new file, or makes substantial /\n> > non-trivial changes or additions to a file, your name (or the name of\n> > your employer, if they own the copyright to your work) should be placed\n> > at or added to the top of the file.  I usually forget when I\'m changing\n> > existing files, but am going to try to be better about remembering.\n\nSame here.\n\n> Cool... good info thanks Monty and Russell.\n> \n> So I have a specific example now that I can use :)\n> \n> A contributor noticed that a number of files in the source tree have\n> *NO* header whatsoever.  So, they did a global search and add of the\n> copyright Openstack and Apache license on all files that didn\'t have\n> it.  Granted most of these are empty __init__ files, and the general\n> answer from most is probably *who cares*.  Seems like this is the\n> right way to go, but wanted to make sure.\n\nI\'d be wary of retrospectively adding copyright headers to files. Who\'s\nto say the header you add accurately reflects the ownership of any\ncopyrightable material? And surely no copyright header is better than an\ninaccurate one?\n\nEmpty files without a copyright header doesn\'t seem like an issue to me.\n\n> Sorry if this seems like a silly question to be asking, but I think we\n> should have some sort of consistent guidance/rule here.\n\nFeel free to create a new proposal here:\n\n  http://wiki.openstack.org/Governance/Proposed/\n\nand the PPB can rubber stamp it.\n\nI think the guidance would simply be:\n\n  - always include an Apache License 2.0 notice\n\n  - if you\'re copying an existing file, retain the existing copyright \n    headers\n\n  - if you substantially modify a file, add your own copyright header\n\n  - if you\'re unsure what copyright header is appropriate in your case, \n    seek your own legal advice. It may name you personally or your \n    employer, depending on the circumstances.\n\nCheers,\nMark.\n\n\n\n','<CA+qL3LVzUSsjtBnk-52fxAw2UyM7f8svzXEs=AEcyW=1-DC4xg@mail.gmail.com>',NULL),('<1345203737.2630.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-17 12:42:17',3600,'2012-08-17 11:42:17',NULL,'[openstack-dev] question about the scheduler filters','On Thu, 2012-08-16 at 20:22 -0600, Jim Fehlig wrote:\n> While merging the recent ComputeFilter additions with the ArchFilter, I\n> spent too much time agonizing over the name ArchFilter, which I was now\n> making filter on more than just architecture.  ComputeCapabilitiesFilter\n> seems like better name, but this is already taken.\n> \n> Looking at ComputeCapabilitiesFilter again, I realize it is filtering on\n> some of the same properties as the combined ArchFilter [1], but from a\n> different source.  IIUC, ComputeCapabilitiesFilter filters on properties\n> that originate from the instance type/flavor.  The combined ArchFilter\n> filters on properties that originate from the image.  It seems this\n> could be a source of confusion for users, but at the same time seems\n> necessary, particularly for properties such as architecture, preferred\n> hypervisor and virtual machine mode, which I tend to think are\n> properties of an image more so than a flavor.  E.g. I could select my\n> \"Xen arm\" flavor, but unless I also selected a \"Xen arm\" image, I could\n> have an instance that doesn\'t boot.\n> \n> Do folks have any issues with filters using both image and flavor\n> properties?  Being relatively new here, this may very well be intended\n> :).  If so, I\'d like to change the name of ArchFilter to better reflect\n> its new additions.  What do you think of ImagePropertiesFilter?  It\n> filters hosts based on compute properties defined on the image.  Or\n> ImageComputePropertiesFilter, to accommodate a future class of\n> filterable image properties?\n\nOk, stepping back for a minute. Before your patch, we had:\n\nComputeFilter\n  simply matches enabled compute hosts\n\nArchFilter\n  match the architecture from the image properties against the compute \n  node\'s permitted_instance_types\n\n  it\'s using instance_properties[\'architecture\'] which is taken from the\n  image\'s architecture property in _create_instance() - see how\n  base_options is populated\n\n  permitted_instance_types is just the list of guest archs\n\nComputeCapabilitiesFilter\n  matches properties defined in an instance type\'s extra specs against \n  compute capabilities\n\nAggregateInstanceExtraSpecsFilter\n  matches properties defined in an instance type\'s extra specs against\n  admin-defined properties on a host aggregate\n\nAnd then you added:\n\n  match the arch, hypervisor type and vm type from the image properties \n  against those supported by the compute node\n\nIt looks to me like what you\'ve added is a complete superset of\nArchFilter - i.e. if you just specify the architecture property on the\nimage, the behaviour should be identical.\n\nSo, IMHO, it should be fine to move your new matching into\nImagePropertiesFilter and just delete ArchFilter.\n\nCheers,\nMark.\n\n\n\n','<502DAACC.1020206@suse.com>',NULL),('<134529360.73.1383631846826.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-05 06:10:46',0,'2013-11-05 06:10:46',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #49','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/49/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5533910>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47e7190>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x47e7190>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-c85a9bc3-fe24-4f62-a888-adbc53f000ba\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x302d9b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x302d9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x302d9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x302d9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:10:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:10:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:10:15+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:10:15-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:10:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6259590>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1cebb10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 85.20 secs:\n    24.92    TestScrubber.test_scrubber_app\n    19.45    TestScrubber.test_delayed_delete\n    13.94    TestGlanceControl.test_reload\n    13.74    TestGlanceControl.test_respawn\n    13.15    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 518.668s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.49\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.gHtEeX71Dd\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/49/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-13/49\n[SCP] Copying console log.\n\n\n','<970917961.68.1383545558021.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1345493015.4723.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-20 21:03:35',3600,'2012-08-20 20:03:35',NULL,'[openstack-dev] openstack-common now branched for folsom','Hi all,\n\nAll projects using openstack-common incubation APIs should regularly\nre-sync their copies:\n\n  http://wiki.openstack.org/CommonLibrary#Incubation\n\nNow that Folsom is in feature freeze, we wanted projects to be able to\nsync from openstack-common without pulling in new feature work.\n\nTo that end, we\'ve created a stable/folsom branch. Everything committed\nto master which isn\'t a feature will be cherry-picked onto\nstable/folsom. All projects now in feature freeze for Folsom should sync\nfrom this branch.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1345493970.4723.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-20 21:19:30',3600,'2012-08-20 20:19:30',NULL,'[openstack-dev] Bitrot Jenkins jobs','Hi James,\n\nOn Mon, 2012-08-20 at 13:12 -0700, James E. Blair wrote:\n> Hi,\n> \n> I\'ve set up some jobs in Jenkins to run the gate tests daily on the\n> stable branches of the core projects:\n> \n>   https://jenkins.openstack.org/view/Bitrot/\n> \n> We recently had a delay merging a change to the stable/diablo branch of\n> nova because some un-pinned pip dependencies had changed, as had our\n> testing interface.  These jobs are designed to help us avoid similar\n> problems in the future.\n\nExcellent! Thanks much.\n\n> With Essex, we introduced the standardized Project Testing Interface\n> <URL:http://wiki.openstack.org/ProjectTestingInterface> which means that\n> the way tests are invoked should not (greatly) change over time, and\n> indeed, all of the stable/essex branches on that page are currently\n> green.\n> \n> There are a few stable/diablo jobs that are failing due to missing\n> tox.ini files in those projects.  The CI team will work to fix those so\n> we\'ll be ready if changes need to be merged.  The glance unit tests,\n> however, are failing due to a change in swift, which is the sort of\n> error we hope to catch with these jobs.\n> \n> Since we expect these jobs to be successful all the time, I think it\n> makes sense to have them automatically notify a team when they fail.\n> The stable branch maintainers seems like a good fit -- does that sound\n> reasonable, and are there other groups or individuals who would like to\n> be notified?  We could set up a mailing list on the new list server and\n> let people sign up.\n\nThe stable-maint team is looking after stable/essex and the diablo-maint\nteam is looking after stable/diablo. See:\n\n  http://wiki.openstack.org/StableBranch\n\nSo, I think notifying the team for the appropriate branch makes most\nsense.\n\nCheers,\nMark.\n\n\n\n\n\n','<87txvx5nm1.fsf@meyer.lemoncheese.net>',NULL),('<1345496384.4723.83.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-20 21:59:44',3600,'2012-08-20 20:59:44',NULL,'[openstack-dev] [openstack-common] Add auth_token.py from\n keystone middleware to openstack-common','On Sat, 2012-08-18 at 13:04 -0700, Joseph Heck wrote:\n> Hi Yaguang,\n> \n> I agree that it looks like a close fit for pushing into\n> openstack-common, but I don\'t have a solid sense of what the boundary\n> is between stuff that\'s somewhat common and stuff that\'s project\n> specific. auth_token is in one of those grey areas - it\'s used by\n> glance, quantum, nova (and keystone), but not swift - swift extended\n> that basic setup to include some additional context and such detail\n> specific to swift. That auth-token-middleware-for-swift code is now in\n> the swift repository\n> (https://github.com/openstack/swift/blob/master/swift/common/middleware/keystoneauth.py)\n> \n> The other part of this is how we do updates - right now a change to\n> Keystone (such as adding PKI support for signed tokens) means updating\n> in a single location (keystone), where if we moved it to OpenStack\n> common, we\'d need to update it in more than one location. If it were\n> really locked down and not changing, then I think maybe it would make\n> sense to shift in there, but right now (especially with advancements\n> in PKI/signed tokens) and looking forward to the V3 API set, I don\'t\n> know that it makes as much sense. My intuition is telling me that it\'s\n> not sufficiently unchanging and \"common\" enough to move into common,\n> although getting it there is actually something of a goal.\n> \n> Mark - how and where have you been drawing the line on what and when\n> to shift code into OpenStack common?\n\nNot sure how I missed this thread, sorry :(\n\nAs I said, anything which would otherwise be copied and pasted between\nprojects makes sense in openstack-common.\n\nWe used to copy auth_token between the projects, but we don\'t do that\nanymore so ... that sounds like there\'s no need to move it to\nopenstack-common.\n\nHowever, is keystone providing (and committed to continuing to provide)\na stable auth_token API to the projects that require it?\n\nCould a situation arise where we make a change to auth_token which\nbreaks older versions of the projects which require it? If so, then it\'s\nnot a good idea for projects to depend on the version supplied by\nkeystone. Think about the situation where you may want newer keystone\ninstalled on a system, but e.g. older Nova.\n\nSo, there are a few options:\n\n  1) auth_token is a stable API, continue to have keystone provide it\n\n  2) auth_token is a stable API, release it as a library in the \n     openstack-common family e.g. oslo-auth-token\n\n  3) auth_token is an unstable API, add it to openstack-common\'s \n     incubation area and have projects sync a copy of it from there\n\nCheers,\nMark.\n\n\n\n','<09D42CCF-E896-40CC-B326-75730CC6A479@mac.com>',NULL),('<1345496554.4723.84.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-20 22:02:34',3600,'2012-08-20 21:02:34',NULL,'[openstack-dev] [openstack-common] Add auth_token.py from\n keystone middleware to openstack-common','On Sat, 2012-08-18 at 16:23 -0500, Michael Basnight wrote:\n> Side note: I\'d prefer to not install all of keystone to get this one\n> module, no matter where it is.\n\nFWIW, Fedora packages auth_token.py as python-keystone-auth-token so\nthat you don\'t need to install of keystone for just the middleware.\n\nCheers,\nMark.\n\n\n\n','<749E303C-5D18-47F7-B86C-2897FE69B814@gmail.com>',NULL),('<1345565940.17839.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-21 17:19:00',3600,'2012-08-21 16:19:00',NULL,'[openstack-dev] [nova] FFE for entrypoints driver loading','Hey,\n\nOn Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:\n> Hey all!\n> \n> I\'d like to request a FFE for the following:\n> \n> https://review.openstack.org/#/c/11027/\n> \n> The patch adds the ability to register and load virt drivers via\n> entrypoints. There are a couple of virt drivers that I\'ve been involved\n> with or that I\'m becoming involved with, such as the openvz driver and\n> the bare-metal work, that aren\'t going to land this cycle. But there\'s\n> no real reason why it needs to be quite so wonky to have a virt driver\n> out of tree. (patch was driven by trying to figure out ways to have CI\n> test these things _before_ we had them landed or ever proposed)\n> \n> The way the patch works is that it registers an entrypoint for virt\n> drivers and also registers the current in-tree virt drivers with that\n> entrypoint. Because we have people using the direct class-loading\n> interface that is currently there, the driver loader falls back to\n> class-path loading as currently works.\n> \n> So while it adds a potential code loading path, it does not alter the\n> behavior of the current system - and I think it should be safe enough to\n> land, which should give us an easier mechanism moving forward in this\n> next cycle for testing and vetting new work in the virt driver layer.\n\nI guess one of the most important things with an FFE is the benefit to\nusers. You say in the commit:\n\n  With this, things like \"pip install nova-virt-hyper-v\" could be\n  expected to work.\n\nWith the patch, will that actually work in Folsom, or is it just laying\nthe groundwork for it to work in Grizzly?\n\nCheers,\nMark.\n\n\n\n','<5033AD2B.3040204@inaugust.com>',NULL),('<1345566380.3218.160.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-21 11:26:20',-18000,'2012-08-21 16:26:20',NULL,'[openstack-dev] [nova] FFE for entrypoints driver loading','On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:\n> I\'d like to request a FFE for the following:\n> \n> https://review.openstack.org/#/c/11027/\n> \n> The patch adds the ability to register and load virt drivers via\n> entrypoints. There are a couple of virt drivers that I\'ve been involved\n> with or that I\'m becoming involved with, such as the openvz driver and\n> the bare-metal work, that aren\'t going to land this cycle. But there\'s\n> no real reason why it needs to be quite so wonky to have a virt driver\n> out of tree. (patch was driven by trying to figure out ways to have CI\n> test these things _before_ we had them landed or ever proposed)\n\nI like the basic idea.  If we\'re sure this can be finished up before\nfinal release, I think it\'s something we should let in?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5033AD2B.3040204@inaugust.com>',NULL),('<1345651136.17839.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-22 16:58:56',3600,'2012-08-22 15:58:56',NULL,'[openstack-dev] [nova] FFE for entrypoints driver loading','On Wed, 2012-08-22 at 17:20 +0200, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > On 08/21/2012 10:19 AM, Mark McLoughlin wrote:\n> >> Hey,\n> >>\n> >> On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:\n> >>> Hey all!\n> >>>\n> >>> I\'d like to request a FFE for the following:\n> >>>\n> >>> https://review.openstack.org/#/c/11027/\n> \n> So I looked a bit more deeply into this, and I\'m not really convinced.\n> \n> First, this comes out of nowhere with no blueprints / discussion, with\n> first patch proposed even after Folsom-3 was pushed. This looks like the\n> textbook example of what you should not do, diverting resources from\n> bugfixing to do FFE assessment and reviews with no prior warning. The\n> process is there for everyone, so I\'d feel bad if we granted an\n> exception to this while we refused exceptions for things that were\n> proposed with proper blueprint tracking and before FF but which were\n> just held back by slow reviews.\n\nThis is my take too. I started looking at this stuff in some detail this\nmorning and mulling it over but, after a while, I was like \"wait, I\nwanted to be doing bug triage today!\".\n\nOne of the issues with FFEs is they become a distraction from what we\nwant everyone to be focused on at this point - bugs and release quality.\n\nCheers,\nMark/\n\n\n\n','<5034F8C9.8000103@openstack.org>',NULL),('<1345653247.2607.2.camel@null.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-22 11:34:07',-18000,'2012-08-22 16:34:07',NULL,'[openstack-dev] [nova] FFE for entrypoints driver loading','On Wed, 2012-08-22 at 17:20 +0200, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > On 08/21/2012 10:19 AM, Mark McLoughlin wrote:\n> >> Hey,\n> >>\n> >> On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:\n> >>> Hey all!\n> >>>\n> >>> I\'d like to request a FFE for the following:\n> >>>\n> >>> https://review.openstack.org/#/c/11027/\n> \n> So I looked a bit more deeply into this, and I\'m not really convinced.\n> \n> First, this comes out of nowhere with no blueprints / discussion, with\n> first patch proposed even after Folsom-3 was pushed.\n\nUsing entry_points was discussed at the Folsom summit. I agree with the\nrest of the sentiment though, better to wait for grizzly.\n\nHappy Hacking!\n\n7-11\n\n\n\n','<5034F8C9.8000103@openstack.org>',NULL),('<1345672493.17839.35.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-22 22:54:53',3600,'2012-08-22 21:54:53',NULL,'[openstack-dev] [nova] FFE for entrypoints driver loading','Hi Duncan,\n\nOn Wed, 2012-08-22 at 13:29 -0700, Duncan McGreggor wrote:\n> On Wed, Aug 22, 2012 at 1:04 PM, Thierry Carrez <thierry at openstack.org> wrote:\n> > Jason K?lker wrote:\n> >> On Wed, 2012-08-22 at 17:20 +0200, Thierry Carrez wrote:\n> >>> Monty Taylor wrote:\n> >>>> On 08/21/2012 10:19 AM, Mark McLoughlin wrote:\n> >>>>> Hey,\n> >>>>>\n> >>>>> On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:\n> >>>>>> Hey all!\n> >>>>>>\n> >>>>>> I\'d like to request a FFE for the following:\n> >>>>>>\n> >>>>>> https://review.openstack.org/#/c/11027/\n> >>>\n> >>> So I looked a bit more deeply into this, and I\'m not really convinced.\n> >>>\n> >>> First, this comes out of nowhere with no blueprints / discussion, with\n> >>> first patch proposed even after Folsom-3 was pushed.\n> >>\n> >> Using entry_points was discussed at the Folsom summit. I agree with the\n> >> rest of the sentiment though, better to wait for grizzly.\n> >\n> > Yeah, I also realized after posting that one of the patches was actually\n> > posted before FF :) I guess the decision boils down to *why* this needs\n> > to be in Folsom rather than in early Grizzly, and I wish changes had\n> > been submitted a few weeks earlier so that we didn\'t have to lose time\n> > over that review/discussion/decision :)\n> \n> At DeamHost, we\'re developing against Folsom and will be releasing a\n> Folsom-based product. If this change makes it in for Folsom, this will\n> save us considerable work via an improved development process. Within\n> the larger context of the community at large we may be only one team\n> of devs, but I\'d imagine that with a team as senior as ours, there\n> will be other Python hackers out there who will appreciate the\n> methodology represented by this change and the benefits of having it\n> in place for Folsom-based projects.\n\nCould you elaborate on what this new methodology is and how it will save\nyou considerable work? Honestly totally non-obvious to me, I\'m afraid.\n\nThanks,\nMark.\n\n\n\n','<CAG_87OkPBe+dD5MsBf-tgy38tyJQzZFF5S7S9A_-5L3Qec0eig@mail.gmail.com>',NULL),('<1346068023.1713.23.camel@warchild>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-27 13:47:03',7200,'2012-08-27 11:47:03',NULL,'[Openstack-operators] Using bridge instead of routing by floating\n	ips','Heyho dear community,\n\nI\'ll try to find a solution how i can use a layer 3 load balancer\n(keepalived) with Openstack instances. \nThis load balancer is shared to all projects and Keepalived will\ndistribute all incoming connections (http, https, port xy) to the\nregistered instances. It\'s only possible if the floating ip\'s are not\nrouted by iptables and each instance have a second NIC with a unique\nMac.\n\nI\'ve found quantum instead of the default network manager but Quantum\nhave no multi_host option ?! In addition Quantum will use vLan tagging\nand that\'s not possible for our setup. Or i\'m wrong with vlan tagging?\n\nConfiguration:\nI\'m using \"FlatDHCPManager\" to manage my network. It\'s installed on each\ncompute node with \"multi_host\" flag. So the fixed_ips are using bridging\nbut the floating will be routed with IPtables.\nLoad balancer (keepalived) it\'s installed an configured on extra hosts.\nI\'ve a very distributed cloud stack that means i\'m using extra hosts for\napi and keystone, storage and image, many shared services (DB cluster,\nglusterfs cluster, mail cluster and so on)and compute/network nodes. \n\n\nIf you have questions or need more detailled informations to answer,\nplease ask :)\n\n\nGreetings\nHeiko Kr?mer\n\nIRC: foexle\n\n\n\n-- \nB. Sc. Informatik\nHeiko Kr?mer\nCIO/Administrator\n\nTwitter: @railshoster\nAvarteq GmbH\nZweigstelle: \nPrinzessinnenstr. 20, 10969 Berlin\n\n----\nGesch?ftsf?hrer: Alexander Fai?t, Dipl.-Inf.(FH) Julian Fischer\nHandelsregister: AG Saarbr?cken HRB 17413, Ust-IdNr.: DE262633168\nSitz: \nScience Park 2\n66123 Saarbr?cken\n\nTel: +49 (0)681 / 309 64 190\nFax: +49 (0)681 / 309 64 191\n\nVisit:\nhttp://www.enterprise-rails.de/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120827/43a8fd28/attachment.html>\n\n',NULL,NULL),('<1346068979.2602.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-27 13:02:59',3600,'2012-08-27 12:02:59',NULL,'[openstack-dev] [nova] FFE: entrypoints loading for schedulers','On Mon, 2012-08-27 at 07:27 -0400, Jay Pipes wrote:\n> Sorry, did we get a decision on this one? Was a FFE granted or is this\n> waiting to Grizzly?\n\nIt\'s deferred until Grizzly:\n\nhttp://eavesdrop.openstack.org/meetings/nova/2012/nova.2012-08-23-21.00.html\n\nMost of the discussion happened on the \"FFE for entrypoints driver\nloading\" thread:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-August/thread.html#750\n\nCheers,\nMark.\n\n\n\n','<503B59A0.1000901@gmail.com>',NULL),('<1346070462.2602.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-27 13:27:42',3600,'2012-08-27 12:27:42',NULL,'[openstack-dev] Discussion about response value in\n project-specific-flavor API','On Sat, 2012-08-25 at 11:53 +0800, unicell wrote:\nHi Folks,\n> \n> In the review comments of my project-specific-flavor blueprint patch,\n> https://review.openstack.org/#/c/11270/\n> Kevin raised a question about response value for public flavor access list.\n> And I\'d like to posted here for discussion.\n...\n> # Retrieve public flavor access information\n> stack at precise64:~$ nova flavor-access-list --flavor 1\n> +-----------+-------------+\n> | Flavor_ID | Tenant_ID   |\n> +-----------+-------------+\n> | 1         | ALL TENANTS |\n> +-----------+-------------+\n> \n> Question\n> --\n> For the default public flavor types, is this \"ALL TENANTS\" an acceptable\n> solution?  It was intended to provide a human readable message for public\n> flaovrs. And, to differentiate from a non-public flavor with no project\n> access configured.\n\nYou\'re trying to model:\n\n  1) A public flavor\n\n  2) A private flavor associated with one or more tenants\n\n  3) A private flavor not associated with any tenants\n\n(2) and (3) can be modelled with a \"list of tenants\" property, but the\nquestion is how to model (1) using only a list of tenants\n\nI agree that \"ALL TENANTS\" isn\'t acceptable. The obvious solution I see\nis either to expose the \"is_public\" property or return a 404 if the\nclient queries os-flavor-access on a non-private flavor.\n\nCheers,\nMark.\n\n\n\n','<CAM_HZbCcCqOj7yOe-rtQDX9ihBa4TPzYGWjcYM4fwExgBfdQ4w@mail.gmail.com>',NULL),('<1346074234.36344629.1409058677212.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 09:11:17',-14400,'2014-08-26 13:11:17',NULL,'[openstack-dev] [Trove] Proposal to add Amrith Kumar to\n trove-core','Strong +1 from me!\n\n\n> -----Original Message-----\n> From: Nikhil Manchanda [mailto:nikhil at manchanda.me]\n> Sent: August-26-14 3:48 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: [openstack-dev] [Trove] Proposal to add Amrith Kumar to trove-core\n> \n> Hello folks:\n> \n> I\'m proposing to add Amrith Kumar (amrith on IRC) to trove-core.\n> \n> Amrith has been working with Trove for a while now. He has been a\n> consistently active reviewer, and has provided insightful comments on\n> numerous reviews. He has submitted quality code for multiple bug-fixes in\n> Trove, and most recently drove the audit and clean-up of log messages across\n> all Trove components.\n> \n> https://review.openstack.org/#/q/reviewer:\"amrith\",n,z\n> https://review.openstack.org/#/q/owner:\"amrith\",n,z\n> \n> Please respond with +1/-1, or any further comments.\n> \n> Thanks,\n> Nikhil\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<e57cce580b8b4ad0958569362d23e35a@BN1PR07MB037.namprd07.prod.outlook.com>',NULL),('<1346101728.31666.38.camel@null.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-27 16:08:48',-18000,'2012-08-27 21:08:48',NULL,'[openstack-dev] Which mailing list?','What up peeps?\n\nI\'m fine, how are you?\n\nI\'ve noticed that both this list and the old launchpad lists are being\nused. Which is the correct list? After the announcement in July, I\nthought that all discussion was to move to this list and those lists\ndisabled. Is that not the case? Just trying to figure out the least\nnumber of lists that I need to be subscribed to.\n\nHappy Hacking!\n\n7-11\n\n\n\n',NULL,NULL),('<1346106055.31666.44.camel@null.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-27 17:20:55',-18000,'2012-08-27 22:20:55',NULL,'[openstack-dev] Which mailing list?','On Mon, 2012-08-27 at 15:01 -0700, Stefano Maffulli wrote:\n> On Mon 27 Aug 2012 02:08:48 PM PDT, Jason K?lker wrote:\n> > I\'ve noticed that both this list and the old launchpad lists are being\n> > used. Which is the correct list?\n> \n> Right, we are in the middle of a renovation :)\n> \n> The situation *at the moment* is summarized on \n> http://wiki.openstack.org/MailingLists\n> \n> To try to answer your question, the mailing list  for the developers of \n> OpenStack to discuss development issues and roadmap is \n> openstack-dev at lists.openstack.org (this list). It is focused on the \n> next release of OpenStack: you should post on this list if you are a \n> contributor to OpenStack or are very familiar with OpenStack \n> development and want to discuss very precise topics, contribution ideas \n> and similar. Do not ask support requests on this list.\n> \n> The old Launchpad list should be closed so we don\'t rely on Launchpad \n> for mailing list anymore. Last time we talked about this I don\'t think \n> we reached consensus on how to move things around and where to land \n> this General mailing list. A few people suggested to use the exisiting \n> openstack-operators mailing list as General list, therefore not \n> creating anything new.\n> \n> Moving a group of over 4000 people from one list on Launchpad to \n> another on our mailman is scary. Unfortunately we can\'t export the list \n> of email addresses subscribed to Launchpad and invite them to another \n> list (LP doesn\'t allow that).  The first question is: where would \n> people go for general openstack usage questions (is \'operators\' the \n> best fit?) Then, what do we do with Launchpad mailing list archives? If \n> we find an agreement we can aim at closing the old LP-hosted mailing \n> list around the summit, where we will be able to announce the new list \n> destination to many people.\n\nI think someone needs to be policing the launchpad list then proactively\ntelling people not to discuss development there and to take it to the\ncorrect list. Its getting very hard to follow the threads with all the\ncross posting and random forwarding to \"loop-in\" the other list.\n\nHappy Hacking!\n\n7-11\n\n\n\n','<503BEE1F.5070901@openstack.org>',NULL),('<13462319.GKc1PN7E8i@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 18:14:22',39600,'2014-10-07 07:14:22',NULL,'[openstack-dev] [kolla] kolla, keystone, and endpoints (oh my!)','On Mon, 6 Oct 2014 10:33:21 AM Lars Kellogg-Stedman wrote:\n> Hello all,\n> \n> I wanted to expand on a discussion we had in #tripleo on Friday\n> regarding Kubernetes and the Keystone service catalog.\n> \n> ## The problem\n> \n> The essential problem is that Kubernetes and Keystone both provide\n> service discovery mechanisms, and they are not aware of each other.\n> \n> Kubernetes provides information about available services through\n> Docker environment variables, whereas Keystone maintains a list of API\n> endpoints in a database.\n\nWhat you haven\'t stated here is whether the catalog endpoints should be \nreachable outside the kubernetes minions or not.\n\nPerhaps we could even use this mysterious(*) keystone publicURL/internalURL \ndivision to publish different external and kubernetes-only versions, since we \ncan presumably always do more efficient communication pod<->pod.\n\n\n(*) Is the publicURL/internalURL/adminURL split documented anywhere?  Does \nanything other than keystone-manage use anything other than publicURL?\n\n> When you configure the keystone endpoints, it is tempting to simply\n> use the service environment variables provided by Kubernetes, but this\n> is problematic: the variables point at the host-local kube-proxy\n> instance.  This is a problem right now because if that host were to\n> go down, that endpoint would no longer be available.  That will be a\n> problem in the near future because the proxy address will soon be\n> pod-local, and thus inaccessible from other pods (even on the same\n> host).\n> \n> One could instrument container start scripts to replace endpoints in\n> keystone when the container boots, but if a service has cached\n> information from the catalog it may not update in a timely fashion.\n> \n> ## The (?) solution\n> \n> I spent some time this weekend experimenting with setting up a\n> pod-local proxy that takes all the service information provided by\n> Kubernetes and generates an haproxy configuration (and starts haproxy\n> with that configuration):\n\nThis sounds good.\n\nSome alternatives off the top of my head, just to feed the discussion:\n\n1.  Fixed hostname\n\nAdd something like this to the start.sh wrapper script:\n echo $SERVICE_HOST proxy >> /etc/hosts\nand then use http://proxy:$port/... etc as the endpoint in keystone catalog.\n\n2. Fixed IP addresses\n\nCreate a regular OpenStack loadbalancer and configure this (possibly publicly \navailable) IP in keystone catalog.\n\nI _think_ this could even be a loadbalancer controlled by the neutron we just \nset up, assuming the the loadbalancer HA works without help and the nova<-\n>neutron \"bootstrap\" layer was setup using regular k8s service env vars and \nnot the loadbalancer IPs.\n\nVariant a)\n\nCreate an \"external proxy\" kubernetes job that adds itself to a regular \nOpenStack loadbalancer and forwards traffic to the local kubernetes proxy (and \nthence to the real backend).  We can just walk the standard kubernetes \nenvironment variables to find configured k8s services.\n\nVariant b)\n\nHave an out-of-band job that periodically finds the current location of \nsuitable endpoints using a \"list pods\" with label matching and then \n(re)configures a loadbalancer with the hostports of whatever it finds.\nAvoids the \"double proxy\" inherent in (a) (and (c) aiui), at the cost of more \nfrequent loadbalancer config churn.\n\nVariant c)\n\nTeach kubernetes how to configure OpenStack loadbalancers directly by adding a \nkubernetes/pkg/cloudprovider/openstack.  Then we add \n\"CreateExternalLoadBalancer: true\" to the appropriate service definitions and \nkubernetes basically does variant (a) itself.\n\n\nFwiw, I think we should do (2.c) anyway, just to keep up with the other \nproviders that already exist in kubernetes.  I haven\'t written any go in a \nyear or so, but I might even do this myself.\n\n\nIn case it needs to be said, I think we should watch discussions like \nhttps://github.com/GoogleCloudPlatform/kubernetes/issues/1161 and try to \nfollow the \"standard\" kubernetes approaches as they emerge.\n\n - Gus\n\n> - https://github.com/larsks/kolla/tree/larsks/hautoproxy/docker/hautoproxy\n> \n> This greatly simplifies the configuration of openstack service\n> containers: in all cases, the \"remote address\" of another service will\n> be at http://127.0.0.1/, so you can simply configure that address into\n> the keystone catalog.\n> \n> It requires minimal configuration: you simply add the \"hautproxy\"\n> container to your pod.\n> \n> This seems to do the right thing in all situations: if a pod is\n> rescheduled on another host, the haproxy configuration will pick up\n> the appropriate service environment variables for that host, and\n> services inside the pod will contain to use 127.0.0.1 as the \"remote\"\n> address.\n> \n> If you use the .json files from\n> https://github.com/larsks/kolla/tree/larsks/hautoproxy, you can see\n> this in action.  Specifically, if you start the services for mariadb,\n> keystone, and glance, and then start the corresponding ponds, you will\n> end up with functional keystone and glance services.\n> \n> Here\'s a short script that will do just that:\n> \n>     #!/bin/sh\n> \n>     for x in glance/glance-registry-service.json \\\n>         glance/glance-api-service.json \\\n>         keystone/keystone-public-service.json \\\n>         keystone/keystone-admin-service.json \\\n>         mariadb/mariadb-service.json; do\n>       kubecfg -c $x create services\n>     done\n> \n>     for x in mariadb/mariadb.json \\\n>         keystone/keystone.json \\\n>         glance/glance.json; do\n>       kubecfg -c $x create pods\n>     done\n> \n> With this configuration running, you can kill the keystone pod and allow\n> Kubernetes to reschedule it and glance will continue to operate correctly.\n> \n> You cannot kill either the glance or mariadb pods because we do not\n> yet have a solution for persistent storage.\n> \n> I will be cleaning up these changes and submitting them for review...but\n> probably not today due to an all-day meeting.\n\n-- \n - Gus\n\n\n','<20141006143321.GA7311@redhat.com>',NULL),('<1346239012.2524.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-29 12:16:52',3600,'2012-08-29 11:16:52',NULL,'[openstack-dev] [Quantum] Administrator Guide - quantum.conf','On Wed, 2012-08-29 at 13:53 +0300, Gary Kotton wrote:\n> Hi,\n> Part of the Admin guide will be to list all of the configuration \n> options. I have started by compiling a list of the items that can be \n> configured in quantum.conf. Please take a look and let me know if you \n> think that something is missing or requires additional documentation or \n> better formatting...\n> Please look at - \n> https://docs.google.com/document/d/1EDLXQbuVWJ4MgTOC93WbyoDPWG4nnSD75PvSsxuuGuo/edit\n\nOne small issue - change the hyphen to underscore in the logging config\noptions. The hyphen is only correct when passing the option on the\ncommand line.\n\nAlso, nova has a script (nova/tools/config) for generating a sample\nconfig file with all this information and from there we copy it into the\ndocs. I think the script could do with a lot of work, but it might be\nuseful to quantum too.\n\nCheers,\nMark.\n\n\n\n','<503DF4B2.8010208@redhat.com>',NULL),('<1346247286.2524.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-29 14:34:46',3600,'2012-08-29 13:34:46',NULL,'[openstack-dev] [Quantum] Administrator Guide - quantum.conf','Hi Anne,\n\nOn Wed, 2012-08-29 at 08:25 -0500, Anne Gentle wrote:\n>  \n>         \n>         \n>         One small issue - change the hyphen to underscore in the\n>         logging config\n>         options. The hyphen is only correct when passing the option on\n>         the\n>         command line.\n>         \n> \n> This is so strange to have to document that I want to believe we can\n> fix it with code. Can anyone describe why hyphens are needed at the\n> command line and underscores in the config file? How can we make it\n> consistent both places? \n\nThe difference between the command line and config file isn\'t a docs\nissue really, IMHO. Only a tiny number of config options are available\non the command line, the two things need to be documented separately\nanyway.\n\nThe docs for the config file options should just have underscores, as I\ndid for nova:\n\n  https://github.com/openstack/nova/commit/63cc191c2d\n\nCheers,\nMark.\n\n\n\n\n','<CAD0KtVFvQi1Guq4-O-+=QL-JD5=VcgZ4pTTX=i4ic4pdQXy3Wg@mail.gmail.com>',NULL),('<1346334769.7106.1.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-30 14:52:49',3600,'2012-08-30 13:52:49',NULL,'[OpenStack Foundation] Board Meeting Tuesday','Hi Jonathan,\n\nOn Sun, 2012-08-26 at 10:36 -0500, Jonathan Bryce wrote:\n> The first full Board meeting of the OpenStack Foundation is scheduled\n> for Tuesday August 28th at 11:00am PDT/1800 UTC. The current draft\n> agenda is on the wiki:\n> http://wiki.openstack.org/Governance/Foundation/Aug2012BoardAgenda\n> \n> The agenda contains information that you can use to listen to the\n> Board meeting online or through a conference dial-in. It also contains\n> the Gold Member applications of several new companies.\n\nAre the minutes of the board meeting going to be posted soon?\n\nThanks,\nMark.\n\n\n\n','<8FAA973A-B3B1-465F-91D7-8C9901F828AE@openstack.org>',NULL),('<134640599.264.1368426886300.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-13 06:34:46',0,'2013-05-13 06:34:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #39','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/39/>\n\n\n\n','<1001628727.252.1368341550421.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1346642417.18.1377939616097.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-31 09:00:15',0,'2013-08-31 09:00:15',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #15','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/15/>\n\n------------------------------------------\n[...truncated 17253 lines...]\n2013-08-31 06:06:24 # If not defined the admin user from the identity section will be used\n2013-08-31 06:06:24 username =\n2013-08-31 06:06:24 # The above administrative user\'s password\n2013-08-31 06:06:24 password =secret\n2013-08-31 06:06:24 # The above administrative user\'s tenant name\n2013-08-31 06:06:24 tenant_name =\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [image]\n2013-08-31 06:06:24 # This section contains configuration options used when executing tests\n2013-08-31 06:06:24 # against the OpenStack Images API\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The type of endpoint for an Image API service. Unless you have a\n2013-08-31 06:06:24 # custom Keystone service catalog implementation, you probably want to leave\n2013-08-31 06:06:24 # this value as \"image\"\n2013-08-31 06:06:24 catalog_type = image\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The version of the OpenStack Images API to use\n2013-08-31 06:06:24 api_version = 1\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # HTTP image to use for glance http image testing\n2013-08-31 06:06:24 http_image = http://127.0.0.1/\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [network]\n2013-08-31 06:06:24 # This section contains configuration options used when executing tests\n2013-08-31 06:06:24 # against the OpenStack Network API.\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Version of the Neutron API\n2013-08-31 06:06:24 api_version = 2.0\n2013-08-31 06:06:24 # Catalog type of the Neutron Service\n2013-08-31 06:06:24 catalog_type = network\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # A large private cidr block from which to allocate smaller blocks for\n2013-08-31 06:06:24 # tenant networks.\n2013-08-31 06:06:24 tenant_network_cidr = 10.100.0.0/16\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The mask bits used to partition the tenant block.\n2013-08-31 06:06:24 tenant_network_mask_bits = 28\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # If tenant networks are reachable, connectivity checks will be\n2013-08-31 06:06:24 # performed directly against addresses on those networks.\n2013-08-31 06:06:24 tenant_networks_reachable = false\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Id of the public network that provides external connectivity.\n2013-08-31 06:06:24 public_network_id = \n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Id of a shared public router that provides external connectivity.\n2013-08-31 06:06:24 # A shared public router would commonly be used where IP namespaces\n2013-08-31 06:06:24 # were disabled.  If namespaces are enabled, it would be preferable\n2013-08-31 06:06:24 # for each tenant to have their own router.\n2013-08-31 06:06:24 public_router_id = \n2013-08-31 06:06:24 \n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [volume]\n2013-08-31 06:06:24 # This section contains the configuration options used when executing tests\n2013-08-31 06:06:24 # against the OpenStack Block Storage API service\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The type of endpoint for a Cinder or Block Storage API service.\n2013-08-31 06:06:24 # Unless you have a custom Keystone service catalog implementation, you\n2013-08-31 06:06:24 # probably want to leave this value as \"volume\"\n2013-08-31 06:06:24 catalog_type = volume\n2013-08-31 06:06:24 # Number of seconds to wait while looping to check the status of a\n2013-08-31 06:06:24 # volume that is being made available\n2013-08-31 06:06:24 build_interval = 1\n2013-08-31 06:06:24 # Number of seconds to time out on waiting for a volume\n2013-08-31 06:06:24 # to be available or reach an expected status\n2013-08-31 06:06:24 build_timeout = 400\n2013-08-31 06:06:24 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-08-31 06:06:24 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-08-31 06:06:24 # have to be different)\n2013-08-31 06:06:24 multi_backend_enabled = false\n2013-08-31 06:06:24 backend1_name = BACKEND_1\n2013-08-31 06:06:24 backend2_name = BACKEND_2\n2013-08-31 06:06:24 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-08-31 06:06:24 # You should update to reflect those exported by configured backend driver.\n2013-08-31 06:06:24 storage_protocol = iSCSI\n2013-08-31 06:06:24 vendor_name = Open Source\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [object-storage]\n2013-08-31 06:06:24 # This section contains configuration options used when executing tests\n2013-08-31 06:06:24 # against the OpenStack Object Storage API.\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # You can configure the credentials in the compute section\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-08-31 06:06:24 # custom Keystone service catalog implementation, you probably want to leave\n2013-08-31 06:06:24 # this value as \"object-store\"\n2013-08-31 06:06:24 catalog_type = object-store\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Number of seconds to time on waiting for a container to container\n2013-08-31 06:06:24 # synchronization complete\n2013-08-31 06:06:24 container_sync_timeout = 120\n2013-08-31 06:06:24 # Number of seconds to wait while looping to check the status of a\n2013-08-31 06:06:24 # container to container synchronization\n2013-08-31 06:06:24 container_sync_interval = 5\n2013-08-31 06:06:24 # Set to True if the Account Quota middleware is enabled\n2013-08-31 06:06:24 accounts_quotas_available = True\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Set operator role for tests that require creating a container\n2013-08-31 06:06:24 operator_role = Member\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [boto]\n2013-08-31 06:06:24 ssh_user = cirros\n2013-08-31 06:06:24 # This section contains configuration options used when executing tests\n2013-08-31 06:06:24 # with boto.\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # EC2 URL\n2013-08-31 06:06:24 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-08-31 06:06:24 # S3 URL\n2013-08-31 06:06:24 s3_url = http://127.0.0.1:3333\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-08-31 06:06:24 aws_access =\n2013-08-31 06:06:24 aws_secret =\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Image materials for S3 upload\n2013-08-31 06:06:24 # ALL content of the specified directory will be uploaded to S3\n2013-08-31 06:06:24 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # The manifest.xml files, must be in the s3_materials_path directory\n2013-08-31 06:06:24 # Subdirectories not allowed!\n2013-08-31 06:06:24 # The filenames will be used as a Keys in the S3 Buckets\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-08-31 06:06:24 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-08-31 06:06:24 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-08-31 06:06:24 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Instance type\n2013-08-31 06:06:24 instance_type = m1.nano\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # TCP/IP connection timeout\n2013-08-31 06:06:24 http_socket_timeout = 30\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Number of retries actions on connection or 5xx error\n2013-08-31 06:06:24 num_retries = 1\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Status change wait timout\n2013-08-31 06:06:24 build_timeout = 400\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Status change wait interval\n2013-08-31 06:06:24 build_interval = 1\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [orchestration]\n2013-08-31 06:06:24 # Status change wait interval\n2013-08-31 06:06:24 build_interval = 1\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Status change wait timout. This may vary across environments as some some\n2013-08-31 06:06:24 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-08-31 06:06:24 build_timeout = 300\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Instance type for tests. Needs to be big enough for a\n2013-08-31 06:06:24 # full OS plus the test workload\n2013-08-31 06:06:24 instance_type = m1.micro\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Name of heat-cfntools enabled image to use when launching test instances\n2013-08-31 06:06:24 # If not specified, tests that spawn instances will not run\n2013-08-31 06:06:24 #image_ref = ubuntu-vm-heat-cfntools\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # Name of existing keypair to launch servers with. The default is not to specify\n2013-08-31 06:06:24 # any key, which will generate a keypair for each test class\n2013-08-31 06:06:24 #keypair_name = heat_key\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [dashboard]\n2013-08-31 06:06:24 # URL where to find the dashboard home page\n2013-08-31 06:06:24 dashboard_url = http://127.0.0.1/\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # URL where to submit the login form\n2013-08-31 06:06:24 login_url = http://127.0.0.1/auth/login/\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [scenario]\n2013-08-31 06:06:24 # Directory containing image files\n2013-08-31 06:06:24 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # AMI image file name\n2013-08-31 06:06:24 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # ARI image file name\n2013-08-31 06:06:24 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # AKI image file name\n2013-08-31 06:06:24 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # ssh username for the image file\n2013-08-31 06:06:24 ssh_user = cirros\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 # specifies how many resources to request at once. Used for large operations\n2013-08-31 06:06:24 # testing.\"\n2013-08-31 06:06:24 large_ops_number = 0\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [cli]\n2013-08-31 06:06:24 # Enable cli tests\n2013-08-31 06:06:24 enabled = True\n2013-08-31 06:06:24 # directory where python client binaries are located\n2013-08-31 06:06:24 cli_dir = /usr/local/bin\n2013-08-31 06:06:24 # Number of seconds to wait on a CLI timeout\n2013-08-31 06:06:24 timeout = 15\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [service_available]\n2013-08-31 06:06:24 # Whether or not cinder is expected to be available\n2013-08-31 06:06:24 cinder = True\n2013-08-31 06:06:24 # Whether or not neutron is expected to be available\n2013-08-31 06:06:24 neutron = False\n2013-08-31 06:06:24 # Whether or not glance is expected to be available\n2013-08-31 06:06:24 glance = True\n2013-08-31 06:06:24 # Whether or not swift is expected to be available\n2013-08-31 06:06:24 swift = True\n2013-08-31 06:06:24 # Whether or not nova is expected to be available\n2013-08-31 06:06:24 nova = True\n2013-08-31 06:06:24 # Whether or not Heat is expected to be available\n2013-08-31 06:06:24 heat = True\n2013-08-31 06:06:24 # Whether or not horizon is expected to be available\n2013-08-31 06:06:24 horizon = True\n2013-08-31 06:06:24 \n2013-08-31 06:06:24 [stress]\n2013-08-31 06:06:24 # Maximum number of instances to create during test\n2013-08-31 06:06:24 max_instances = 32\n2013-08-31 06:06:24 # Time (in seconds) between log file error checks\n2013-08-31 06:06:24 log_check_interval = 60\n2013-08-31 06:06:24 # The default number of threads created while stress test\n2013-08-31 06:06:24 default_thread_number_per_action=4\n2013-08-31 06:06:24 ++ IFS=\' 	\n2013-08-31 06:06:24 \'\n2013-08-31 06:06:24 ++ set +o errexit\n2013-08-31 06:06:24 ++ init_tempest\n2013-08-31 06:06:24 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-08-31 06:06:24 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-31 06:06:24 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-08-31 06:06:24 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-08-31 06:06:24 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1658.gedaa084.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-197113\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-197113/15\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-197113/15/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-197113/15/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-197113/15/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1716551899.12.1377853216135.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1346742847.2400.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-04 08:14:07',3600,'2012-09-04 07:14:07',NULL,'[openstack-dev] [openstack-common] Which version?','Hi Gary,\n\nOn Tue, 2012-09-04 at 08:55 +0300, Gary Kotton wrote:\n> Hi,\n> For Quantum F-3 RC1 we would like to pull the latest updates and fixes \n> from openstack-common. Should this be done form the master or stable/folsom?\n\n>From stable/folsom:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-August/000735.html\n\nCheers,\nMark.\n\n\n\n','<504597C2.6050508@redhat.com>',NULL),('<1346828422.2273.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 08:00:22',3600,'2012-09-05 07:00:22',NULL,'[openstack-dev] [Keystone] Questions about git heirarchy','On Tue, 2012-09-04 at 16:01 -0700, Matt Joyce wrote:\n\n> How do people know which git ref to pull to get all of the latest fixes?\n> \n> How do people know which corresponding git refs in other projects they\n> should pull to ensure they have the latest compatible and tested ( ???? )\n> refs?\n\nSounds like you want the stable/essex branch?\n\nCheers,\nMark.\n\n\n\n','<CAGYSk8fXyfgZVUEQzruLL2p9Jia43yEHTZW8c-6ci=+ebR9xGQ@mail.gmail.com>',NULL),('<1346875840.11675463.1398685350080.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 07:42:30',-14400,'2014-04-28 11:42:30',NULL,'[openstack-dev] [Ceilometer] Approximate alarming','\n\n----- Original Message -----\n> Hey everyone!\n> \n> I?d like to get your gut reaction on an idea for the future of alarming.\n> Should I or should I not put it up for debate at the design summit?\n\nHi Nejc,\n\nYes this is certainly worthy of discussion at the design summit.\n\nBecause the algorithms being discussed are quite technical, it\nwould be good to prepare an etherpad in advance with a gentle\nintroduction to the ideas involved, e.g. some worked examples etc.\n\nThis would make for a more profitable discussion at summit, where\nyou don\'t have to burn too much time explaining the intricacies of\nthe streaming approaches.\n\nCheers,\nEoghan\n\n\n> ---TL;DR\n> Online algorithms for computing stream statistics over sliding windows would\n> allow us to provide sample statistics within an error bound (e.g. \"The\n> average cpu utilization in the last hour was 85% +/- 1%?), while\n> significantly reducing the load and memory requirements of the computation.\n> ?\n> \n> Alarm evaluation currently recalculates the aggregate values each time the\n> alarm is evaluated, which is problematic because of the load it puts on the\n> system. There have been multiple ideas on how to solve this problem, from\n> precalculating aggregate values\n> (https://wiki.openstack.org/wiki/Ceilometer/Alerting#Precalculation_of_aggregate_values)\n> to re-architecting the alarms into the sample pipeline\n> (https://wiki.openstack.org/wiki/Ceilometer/AlarmImprovements). While\n> Sandy\'s suggestions make sense from the performance viewpoint, the problem\n> of scalability remains. Samples in the pipeline need to be kept in-memory\n> for the whole evaluation window, which requires O(N) memory for a window of\n> size N.\n> \n> We could tackle this problem by using cutting edge research in streaming\n> algorithms, namely the papers by Datar et al. [1], and Arasu et al. [2].\n> They provide algorithms for computing stream statistics over sliding\n> windows, such as *count, avg, min, max* and even *percentile*, **online**\n> and with polylogarithmic space requirements. The tradeoff is of course\n> precision, but the algorithms are bounded on the relative error - which\n> could be specified by the user.\n> \n> If we can tell the user \"The average cpu utilization in the last hour was 85%\n> +/- 1%\", would that not be enough for most use cases, while severely\n> reducing the load on the system? We could still support *error_rate=0*,\n> which would simply use O(N) space and provide a precise answer for the cases\n> where such an answer is needed.\n> \n> These algorithms were developed with telcos and computer network monitoring\n> in mind, \"in which information about current network performance?latency,\n> bandwidth, etc.?is generated online and is used to monitor and adjust\n> network performance dynamically\"[1]. IIUC the main user of alarms is Heat\n> autoscaling, which is exactly the kind of problem suitable to \'soft\'\n> calculations, with a certain tolerance for error.\n> \n> [1] Datar, Mayur, et al. \"Maintaining stream statistics over sliding\n> windows.\" *SIAM Journal on Computing* 31.6 (2002): 1794-1813. PDF @\n> http://ilpubs.stanford.edu:8090/504/1/2001-34.pdf\n> \n> [2] Arasu, Arvind, and Gurmeet Singh Manku. \"Approximate counts and quantiles\n> over sliding windows.\" *Proceedings of the twenty-third ACM\n> SIGMOD-SIGACT-SIGART symposium on Principles of database systems.* ACM,\n> 2004. PDF @ http://ilpubs.stanford.edu:8090/624/1/2003-72.pdf\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<B3425ACF-3DA0-4827-9147-632CB1B1F74A@xlab.si>',NULL),('<1346875973.2273.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 21:12:53',3600,'2012-09-05 20:12:53',NULL,'[openstack-dev] [Quantum][Common] Private rpc methods /\n	declare_topic_consumer','On Wed, 2012-09-05 at 15:17 -0400, Russell Bryant wrote:\n> On 09/05/2012 02:42 PM, Eric Windisch wrote:\n> > After a bit of a distraction, I\'ve returned to working on some Quantum compatibility testing, analysis, etc. in regard to ZeroMQ.\n> > \n> > Currently, Quantum\'s NotificationDispatcher class uses connection.declare_topic_consumer which is not part of the standardized RPC abstraction. As such, it has not been implemented in the ZeroMQ driver.\n> > \n> > The obvious choices are to make this a required part of the abstraction, implementing it in impl_fake and impl_zmq, or changing the behavior of Quantum.  Also, relatedly, this isn\'t the first time this has happened in a project, we should really look at prefixing these private functions with _.\n> \n> To clarify what *is* a part of the public interface:\n> \n> in rpc/__init__.py, create_connection(), the docs say:\n> \n>     :returns: An instance of openstack.common.rpc.common.Connection\n> \n> so, rpc/common.py has a Connection class which declares the public\n> interface.\n> \n> Adding prefixes to methods not used outside the class is fine with me.\n\nYep, at a glance, it looks like declare_topic_consumer() is an\nimplementation detail of create_consumer() and Quantum should be using\ncreate_consumer(). Good catch.\n\nI\'ve been tracking API improvements we need for the RPC API here:\n\n  https://blueprints.launchpad.net/openstack-common/+spec/rpc-api-review\n\nSo, I\'ve gone ahead and filed this:\n\n  https://bugs.launchpad.net/openstack-common/+bug/1046524\n\nCheers,\nMark.\n\n\n\n','<5047A52C.1030608@redhat.com>',NULL),('<1346877202.2273.67.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 21:33:22',3600,'2012-09-05 20:33:22',NULL,'[openstack-dev] [Common] generic rpc notifications','On Wed, 2012-09-05 at 16:23 -0400, Eric Windisch wrote:\n> Currently, there only exists a rabbit_notifier module. It kind-of\n> works with the other drivers, but at least in the case of the ZeroMQ\n> driver, there is an assumption made that the rabbit notifier doesn\'t\n> really work with.\n> \n> Specifically, separating the topic and the priority with a period. In\n> the ZeroMQ driver, we assume that the period is a separator between a\n> topic and a host.  I know this doesn\'t precisely match the general\n> AMQP patterns, but it does match the pattern of how topics are\n> otherwise constructed in OpenStack.\n> \n> My solution has been to dynamically modify this topic inside the\n> notify() function within the driver. It isn\'t very clean and it leaves\n> much to be desired in terms of queue consumers, as any consumers would\n> not know of the rewriting being done transparently within the driver.\n> \n> Instead, I suggest that we either extend queue_get_for to support\n> topic construction or we make a new method of a similar nature for\n> notification construction.  Also, perhaps obviously, the notification\n> driver should be renamed (it seems prudent to leave the old filename\n> around for a release cycle or two).\n\nSounds sensible. Could you file bugs for both those ideas?\n\nThanks,\nMark.\n\n\n\n','<1E7CEDBFA5DB49D4814473D755C5D1AC@cloudscaling.com>',NULL),('<1346877654.3218.213.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 15:40:54',-18000,'2012-09-05 20:40:54',NULL,'[openstack-dev] Nova extension oddness?','On Wed, 2012-09-05 at 12:51 -0700, Joshua Harlow wrote:\n> In looking at how \'launch-index\' works in the OS nova api (its used\n> when you spin up more than 1 instance in 1 api call) I was seeing that\n> extensions almost seem to be used as configuration \'flags\', is that\n> the purpose? I always thought of an extension as something you could\n> hook-in that would override default behavior (which some of the\n> extensions seem to be doing), not something that was tied to the main\n> program  so tightly.\n\nThe extensions shipped with nova are technically incubating features\nthat are not part of the strict API spec.  The idea is that many of\nthese would become first-class citizens in the next API spec.\n\n\n>         min_count = 1\n>         max_count = 1\n>         if self.ext_mgr.is_loaded(\'os-multiple-create\'):\n>             ret_resv_id = server_dict.get(\'return_reservation_id\', False)\n>             min_count = server_dict.get(\'min_count\', 1)\n>             max_count = server_dict.get(\'max_count\', min_count)\n\nThe problem here is that we currently only have a way of extending nova\nin terms of the manager classes and changes to the API; for the\nextension you\'re referencing here, it has to be coupled with changes to\nthe underlying code.  The is_loaded() test you\'re seeing here is\nprobably a change that Vish recently contributed to try to make these\nextensions actually optional.\n\n> This is in nova/api/openstack/computer/servers.py (~L700). Is that how\n> we want to proceed with extension, or does there need to be\n> refactoring to make the right \'hook-in\' points be used; say have the\n> create server \'top\' level code go through various \'states\', where each\n> \'state\' can be adjusted by an extension (more data added, different\n> configuration?), with no checking of extensions being loaded in the\n> top level code. There seems to be multiple cases of extensions being\n> used as boolean flags there and I wonder if that?s the right approach?\n\nI think there\'s still a lot of work to do to make nova properly\nextensible.  Some of it will be solved by promoting at least some of the\nextensions to be first-class citizens (osapi v3?), but there\'s a lot\nmore that\'s difficult or perhaps impossible to accommodate.  Take for\ninstance the hypervisors extension\'s support for calling uptime on the\nhypervisor host; that required adding: a call to the RPC API so we could\nsend a message to the appropriate compute node; the call in the compute\nnode manager to make an appropriate call to the virt driver; and the\nimplementation of the final call in the virt driver (for xenapi, this\nsupport involved adding behavior to one of the xenapi plugins).  The\nonly piece of this that really could be made into a plugin of any form\nwas the osapi extension itself.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CC6CFA47.1F3AC%harlowja@yahoo-inc.com>',NULL),('<1346880220.3218.219.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 16:23:40',-18000,'2012-09-05 21:23:40',NULL,'[openstack-dev] Nova extension oddness?','On Wed, 2012-09-05 at 14:07 -0700, Joshua Harlow wrote:\n> It seems like its almost like a extension here is a bundle of code that\n> extends multiple parts no? \n\nThat would be a good way of doing it.  However, it\'s not the way that\'s\ncurrently implemented in nova.  Right now, the only thing that can be\nextended by loading a plugin?in the context we\'re discussing?is the\nosapi itself.\n\n> So when someone loads the extension you are\n> talking about they also have to load the extended compute manager... \n\nThe problem with that approach is that it is not properly extensible.\nConsider someone who wants to use two independent extensions which do\ntwo different things, but both require changes to the compute manager;\nif we simply extend the compute manager class, only one of the\nextensions can be used at a time.\n\n> Then when this extension that needs these extra calls is used, it has to\n> basically be a bundle of code that hooks in to the X various points\n> (instead of just 1 point at the extension webservice). Perhaps improving\n> upon the extension mechanism is in order (or making it more widely\n> distributed?), it seems like plugins are themselves extensions, so maybe a\n> unified way of doing this would be applicable? \n\nAt present, there is no way of extending the various managers except by\nsubclassing, which is not scalable.  Hooks would probably be a very good\nfirst pass at improving extensibility.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CC6D0B9E.1F3C2%harlowja@yahoo-inc.com>',NULL),('<1347027101.3679.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-07 15:11:41',3600,'2012-09-07 14:11:41',NULL,'[openstack-dev] Syncing volumes changes from cinder into nova','Hey,\n\nAs discussed in Nova\'s meeting yesterday, I\'ve taken a look at what\nchanges still need to be synced from cinder into nova\n\nTedious stuff to pick through the commit logs and diffs, but here\'s what\nI came up with:\n\n  http://etherpad.openstack.org/cinder-to-nova-sync\n\nI\'ve gone ahead and handled some of the low hanging fruit, but wanted\nsomeone more familiar with the changes to do the others. What remains:\n\n * c191d0d Add admin actions extension\n\n * 5475deb Add \'detaching\' to volume status\n   * Nova patch was abandonded: https://review.openstack.org/11625\n\n edc1110 add ability to clone images\n   * https://blueprints.launchpad.net/nova/+spec/efficient-volumes-from-images\n   * related to create-volumes-from-image bp\n   * nova bp seems to be incorrectly marked as completed\n\n 2f53607 Adds new volume API extensions\n   * https://blueprints.launchpad.net/cinder/+spec/create-volume-from-image\n   * https://blueprints.launchpad.net/nova/+spec/create-volumes-from-images\n   * nova bp seems to be incorrectly marked as completed\n   * Makes sense to sync, but there\'ll be some tricky conflicts\n   * Squash \"ffe5036 Fix bug where image size is incorrectly rejected\"\n     into this\n   * Squash \"8c30edf Removed unnecessary call to ensure_export\" into\n     this\n\n 5b605b6 Include volume_metadata with object on vol create\n   * Syncing this was abandonded and should be restored\n   * https://review.openstack.org/10461\n   * https://bugs.launchpad.net/nova/+bug/1029762\n\nHTH,\nMark.\n\n\n\n',NULL,NULL),('<1347087827.39468606.1351261158452.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-26 10:19:18',-14400,'2012-10-26 14:19:18',NULL,'[openstack-dev] [ceilometer] alternative publication conduits','\n\n> > The DiskIOPollster would also provide a second Transformer to\n> > mediate between the raw stats format and the ceilo Counter\n> > representation for metering.  Additionally, this second Publisher\n> > could be configured with a longer period (as befits metering data\n> > likely to be consumed by a billing engine).\n> \n> I don\'t think it\'s up to the Pollster to provide Transformers. If we go\n> on that road, I\'m afraid it complicates a lot the Pollster writing.\n\nThat was just poorly expressed in my initial mail. The intent was\nmore like:\n\n \"the DiskIOPollster could also be associated with a second Transformer\n  via configuration ...\"\n \n> Why wouldn\'t each publisher be in charge to convert the Counters yielded\n> by the Pollsters using whatever their own Transformer(s)?\n\nYes, I think we may be ad idem on that point.\n\nThe idea was to split the publisher and transformer concerns, as\nthere are likely to be far fewer of the former than the latter.\n\nFor example, we might have a single CloudWatchPublisher that\nknows how to call PutMetricData with any metric datum, and also\nmultiple CloudWatchTransformers who each know how to construct a\nparticular set of metrics from some domain-specific raw data\n(e.g. the disk stats returned by libvirt).\n\nCheers,\nEoghan\n\n \n> > Now the frequency aspect is a bit awkward. For notifications,\n> > the frequency of the \"exists\" style of usage audit is out of our\n> > hands, depending usually on the configuration of the emitter\n> > (e.g. the nova instance_usage_audit_period config). Whereas ceilo\n> > config direct controls only the frequency of polling. So one idea\n> > would be for a publisher\'s frequency only to impact on the periods\n> > under ceilo control - i.e. we\'d accept and publish notifications\n> > whenever we get them, whereas the polling cycle would be determined\n> > by the greatest common divisor of all the configured publisher\n> > periods for each set of related pollsters (the config would\n> > probably\n> > have to be restricted so to ensure a sane GCD).\n> \n> That makes sense. Basically, your polling frequence should be\n> automatically computed to be the min() of the frequency requested by\n> all\n> enabled Publishers.\n> \n> For notifications, the code rounting Counter to Publishers may/should\n> filter out the Counters if they are likely to be emitted wrt with\n> what a\n> Publisher asked for.\n> \n> --\n> Julien Danjou\n> # Free Software hacker & freelance\n> # http://julien.danjou.info\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<87lietwczy.fsf@dex.adm.naquadah.org>',NULL),('<1347260644.21533.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-10 08:04:04',3600,'2012-09-10 07:04:04',NULL,'[openstack-dev] When to use openstack-common','Hi Gabriel,\n\nOn Fri, 2012-09-07 at 19:09 +0000, Gabriel Hurley wrote:\n> In response to https://review.openstack.org/#/c/12413/ I\'m faced with\n> the following question: should openstack common modules be included in\n> cases where they\'re not providing any benefit other than\n> standardization?\n> \n> In particular, there are 3 points around that review:\n> \n>   1. The jsonutils code is designed to solve problems Horizon doesn\'t\n> have.\n\nHow come it was imported in the first place?\n\n>   2. The timeutils code duplicates functionality already built into\n> Django (which Horizon is built on) and is only included because\n> jsonutils now requires it.\n>   3. The timeutils code is now adding external dependencies (iso8601\n> python module) which *again* is duplicating built-in function in\n> Django.\n\nIMHO, this all sounds like perfectly good rationale to not use\njsonutils.\n\nIf you really wanted to use jsonutils but wanted to avoid timeutils, I\'m\nsure we could figure something out, but it sounds like that\'s not the\ncase.\n\nCheers,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F23629249199@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1347281388.21533.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-10 13:49:48',3600,'2012-09-10 12:49:48',NULL,'[openstack-dev] [metering] flask or openstack style wsgi.py','Hey,\n\nOn Mon, 2012-09-10 at 21:58 +1000, Angus Salkeld wrote:\n> On 10/09/12 07:23 -0400, Doug Hellmann wrote:\n> >\n> >\n> >On Sep 10, 2012, at 5:23 AM, Julien Danjou <julien at danjou.info> wrote:\n> >\n> >> On Mon, Sep 10 2012, Angus Salkeld wrote:\n> >>\n> >>> How do you guys feel about me changing flask to a more openstack style\n> >>> wsgi implementation? So the suggestion is not flask sucks, but it is not\n> >>> used anywhere else. We should really use it everywhere or nowhere. I think\n> >>> the consistency across the openstack projects is really nice for people\n> >>> that work across projects.\n> >>\n> >> Sure, one of our principles is to blend with others OS projects, so\n> >> obviously Flask choice can seem weird.\n> >>\n> >> But actually, IIRC, I\'ve discussed this with Doug, and we decided to go\n> >> with Flask because it seemed that WSGI was a dead-end, and that other\n> >> projects would be moving away from it. So what\'s the roadmap for other\n> >> projects about this?\n> >\n> >Not WSGI, paste.deploy. At the last summit we discussed dropping paste because it does not have python 3 support. No timetable was set.\n> >\n> >I pushed the use of flask in ceilometer because when I looked at the WSGI libraries in nova they were not available in common and I didn\'t feel I had time to figure out which bits needed to be extracted to copy them into our project. I also found them to be more complex than I wanted to deal with, since I didn\'t find any tutorials for using them.\n> \n> Yea, I was going to start on this blueprint soon:\n> https://blueprints.launchpad.net/openstack-common/+spec/wsgi-common\n> but if this is the case (moving away from wsgi.py) then this probably needs to be\n> scrapped.\n> \n> Is there a wiki page/blueprint somewhere that explains this decision?\n\nSummary of ceilometer\'s decision to use Flask seems to be:\n\n  - some people are advocating for dropping paste.deploy\n\n  - the WSGI code in Nova is complex and not in openstack-common\n\n  - let\'s use Flask instead\n\nI haven\'t noticed anyone actually making progress towards dropping\npaste.deploy beyond this:\n\n  https://github.com/termie/shred/blob/master/paste/deploy.py\n\nAs for WSGI support in openstack-common, I basically considered the\ncurrent code in openstack-common to be dead since no other projects use\nit even though most projects have very similar code. Angus has done some\nwork bring it back to life, so hopefully we\'ll see a project or two\nswitched over to using it soon.\n\nI don\'t have any strong opinion on this approach vs Flask except that\nthe wsgi-common approach looks more like something which we can have\nmost projects adopt sooner.\n\nCheers,\nMark.\n\n\n\n','<20120910115832.GA1472@redhat.com>',NULL),('<1347312622.21533.78.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-10 22:30:22',3600,'2012-09-10 21:30:22',NULL,'[openstack-dev] Nova\'s service infrastructure in openstack-common','Hi Angus,\n\nLooking at the service infrastructure stuff proposed for\nopenstack-common again:\n\n  https://blueprints.launchpad.net/openstack-common/+spec/service-infrastructure\n\nI always get a bit lost with all the classes and abstractions we have\ngoing on this space, so I spent some time thinking about how it might be\nimproved.\n\nNone of this is necessarily stuff that needs fixing before your patches\ncan be merged, but I felt we needed to have a better picture of where\nwe\'re going.\n\nSo ... my attempt at simplifying the abstractions:\n\n - A Launcher class with the following methods:\n\n     launch_service(service)\n     stop()\n     wait()\n\n   A launcher can be responsible for multiple services.\n\n   There are two subclasses of this. The first - ServiceLauncher - \n   handles a TERM/INT signal by stopping the services. The second -\n   ProcessLauncher - will start a number of child processes, each child\n   process running the service.\n\n - A Service class with the following methods:\n\n     start()\n     stop()\n     wait()\n\n   A service is associated with a Server object.\n\n   A service also has a thread group whose members are stopped when the\n   service is stopped.\n\n - A Server base class with the following methods:\n\n     init(service)\n\n   Server sub-classes PeriodicTasks, so it supports the @periodic_task\n   decorator on its methods. The init() method of Server will spawn a\n   timer thread from the service\'s thread group to run the periodic\n   tasks from.\n\n   There are two further sub-classes of Server which themselves are also\n   base classes - rpc.Server and wsgi.Server. Sub-classes of rpc.Server\n   and wsgi.Server will typically hook into the init() method and add\n   methods which are decorated with @periodic_task.\n\n - The rpc.Server base class creates an RPC dispatcher which exposes all\n   of the server\'s public methods over RPC via a given topic. All RPC\n   calls will be handled in a thread spawned from the service\'s thread\n   group.\n\n - The wsgi.Server base class exposes a WSGI over application a given \n   port and spawns threads from the service\'s thread group to handle\n   requests.\n\nThe differences between this and what we currently have is:\n\n - We no longer have these fairly similar \"manager\" and \"server\"\n   concepts that are completely different but mostly about WSGI vs RPC.\n\n - The functionality of the init_host() hook and periodic tasks are \n   available to both WSGI and RPC servers.\n\n - The Service class doesn\'t know anything about WSGI vs RPC servers, \n   all that knowledge is moved into the Server base classes.\n\n - init_host() is renamed to init(), since the \"host\" bit is fairly\n   meaningless.\n\n - All green threads are spawned from the service\'s thread group.\n\nBut, actually, I\'m now starting to struggle with justifying the\nServer/Service split ... why do we need both?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1347314564.21533.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-10 23:02:44',3600,'2012-09-10 22:02:44',NULL,'[openstack-dev] Syncing volumes changes from cinder into nova','Hi John,\n\nOn Fri, 2012-09-07 at 15:11 +0100, Mark McLoughlin wrote:\n> Hey,\n> \n> As discussed in Nova\'s meeting yesterday, I\'ve taken a look at what\n> changes still need to be synced from cinder into nova\n> \n> Tedious stuff to pick through the commit logs and diffs, but here\'s what\n> I came up with:\n> \n>   http://etherpad.openstack.org/cinder-to-nova-sync\n> \n> I\'ve gone ahead and handled some of the low hanging fruit, but wanted\n> someone more familiar with the changes to do the others. What remains:\n> \n>  * c191d0d Add admin actions extension\n> \n>  * 5475deb Add \'detaching\' to volume status\n>    * Nova patch was abandonded: https://review.openstack.org/11625\n> \n>  edc1110 add ability to clone images\n>    * https://blueprints.launchpad.net/nova/+spec/efficient-volumes-from-images\n>    * related to create-volumes-from-image bp\n>    * nova bp seems to be incorrectly marked as completed\n> \n>  2f53607 Adds new volume API extensions\n>    * https://blueprints.launchpad.net/cinder/+spec/create-volume-from-image\n>    * https://blueprints.launchpad.net/nova/+spec/create-volumes-from-images\n>    * nova bp seems to be incorrectly marked as completed\n>    * Makes sense to sync, but there\'ll be some tricky conflicts\n>    * Squash \"ffe5036 Fix bug where image size is incorrectly rejected\"\n>      into this\n>    * Squash \"8c30edf Removed unnecessary call to ensure_export\" into\n>      this\n> \n>  5b605b6 Include volume_metadata with object on vol create\n>    * Syncing this was abandonded and should be restored\n>    * https://review.openstack.org/10461\n>    * https://bugs.launchpad.net/nova/+bug/1029762\n\nAny plans for these remaining items?\n\nCheers,\nMark.\n\n\n\n','<1347027101.3679.41.camel@sorcha>',NULL),('<1347342840.21533.103.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-11 06:54:00',3600,'2012-09-11 05:54:00',NULL,'[openstack-dev] WSGI \'status\' page?','On Mon, 2012-09-10 at 15:08 -0700, John Dickinson wrote:\n> Swift comes with a healthcheck middleware used as the first entry on\n> the pipeline. It can be used for the purpose you describe. The\n> middleware implements the \"/healthcheck\" endpoint and returns a 200\n> status code with \"OK\" in the body.\n\nThis was proposed to openstack-common recently, but we figured that\nsupporting HEAD on the top-level entry point of services would be more\nobvious and have the same semantics.\n\nhttps://blueprints.launchpad.net/openstack-common/+spec/port-swift-healthcheck\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-August/000614.html\n\nCheers,\nMark.\n\n\n\n','<B4B82E58-B6EF-4FFD-9E62-45B55F0A7CB4@not.mn>',NULL),('<1347360147.21533.116.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-11 11:42:27',3600,'2012-09-11 10:42:27',NULL,'[openstack-dev] [CI] Gerrit Trivial Rebase Detection (LP bug\n 881184)','Hey,\n\nOn Thu, 2012-09-06 at 19:01 +0000, Jeremy Stanley wrote:\n> The CI Team will be merging a long-requested[1]_ feature to Gerrit\n> on review.openstack.org at 16:00 UTC this coming Monday, 2012-09-10.\n> \n> Automatic Detection of Trivially-Rebased Commits\n> ================================================\n> \n> Any committed patchset with no substantive changes (where the git\n> patch-id[2]_ and commit message remain the same) will have code\n> review flags automatically[3]_ reapplied from its predecessor\n> patchset on that Change-Id. Patchsets where the commit message\n> differs but the patch-id still remains the same will *not* have code\n> reviews reapplied, but will have a comment automatically added from\n> the Trivial Rebase user noting that the code itself is unchanged.\n> \n> It\'s hoped that these changes will improve workflow for code\n> reviews, allowing reviewers to avoid re-reading identical patchsets\n> looking for nonexistent alterations. The script itself is provided\n> in upstream Gerrit\'s contrib[4]_ directory and has been put through\n> its paces with our OpenStack-specific modifications[5]_ on a couple\n> of non-production Gerrit servers already (including review-dev.o.o\n> where it is currently installed and active[6]_), so the CI Team\n> doesn\'t anticipate any disruption. Follow up to the list with any\n> questions and I\'ll be happy to answer!\n\nNice work on this!\n\nI\'ve just noticed a case where this went a little wrong:\n\n  https://review.openstack.org/12692\n\nPatch set 2 isn\'t actually a trivial rebase - it makes a whitespace\nchange, but the whitespace change is actually important. And, now that I\nthink about it, I\'m not sure it\'s a great idea to always ignore\nwhitespace changes in trivial rebase detection.\n\nAs Vish said - now that git-review doesn\'t auto-rebase, we should see\nfar less trivial rebases happening. Maybe we should re-think whether we\nneed this?\n\nCheers,\nMark.\n\n\n> References...\n> \n> .. [1] https://bugs.launchpad.net/openstack-ci/+bug/881184\n> \n> .. [2] http://www.kernel.org/pub/software/scm/git/docs/git-patch-id.html\n> \n> .. [3] Automatically but not instantly--there is a delay of a few\n>    seconds before the review flags reappear in the WebUI.\n> \n> .. [4] https://gerrit.googlesource.com/gerrit/+/master/contrib\n> \n> .. [5] https://review.openstack.org/12373\n> \n> .. [6] https://review-dev.openstack.org/488\n> \n\n\n\n\n','<20120906190102.GG6169@yuggoth.org>',NULL),('<1347375367.21533.124.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-11 15:56:07',3600,'2012-09-11 14:56:07',NULL,'[openstack-dev] [CI] Gerrit Trivial Rebase Detection (LP bug\n 881184)','On Tue, 2012-09-11 at 14:43 +0000, Jeremy Stanley wrote:\n> On 2012-09-11 12:15:37 +0000 (+0000), Jeremy Stanley wrote:\n> > It appears that git-patch-id is fairly inflexible in this regard,\n> > taking no options to alter its whitespace-ignoring behaviors. It\'s\n> > doing something akin to diff\'s -w whereas the behavior we\'d want is\n> > more likely along the lines of -BEb instead... or maybe even none at\n> > all, since this also has implications for work which could in fact\n> > be whitespace-only (PEP 8 conformance fixes, for example).\n> [...]\n> \n> Based on a quick IRC discussion on -infra it sounds like the next\n> step would be to implement a new CLI option in git-patch-id, causing\n> it to consider all whitespace changes substantive (and then see if\n> we can get this feature merged upstream in Git as well).\n\nSounds difficult.\n\nAny thoughts on the point about rebase-detection not being so important\nnow that git-review no longer rebases gratuitously?\n\nCheers,\nMark.\n\n\n\n','<20120911144336.GX6169@yuggoth.org>',NULL),('<1347388955.21533.138.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-11 19:42:35',3600,'2012-09-11 18:42:35',NULL,'[openstack-dev] Moving auth_token middleware dependencies to\n openstack common','On Tue, 2012-09-11 at 12:20 -0400, Adam Young wrote:\n> I think that we can get away with the current set up for auth_token \n> middleware  (shipping it inside Keystone but deploying it as a stand \n> alone file) if we move its dependencies to openstack common.  Those \n> dependencies are:\n\nThinking about this some more ...\n\nThe auth_token middleware is a client for part of keystone\'s API.\n\nIt could be part of keystoneclient, or another library.\n\nIf it moves to openstack-commmon, it would eventually end up being\npublished as e.g. oslo-auth after going through an API stabilization\nperiod (aka \"incubation\")\n\nDo we gain anything from going this route? Could we not just publish a\nkeystone-authclient library containing the middleware?\n\nCheers,\nMark.\n\n\n\n','<504F64D1.1060905@redhat.com>',NULL),('<1347520901.439547.1422263214651.JavaMail.yahoo@mail.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-26 09:06:54',0,'2015-01-26 09:06:54',NULL,'[Openstack]  [openstack][neutron] ipv6 DHCP state full issue','\n\nwhat version of dnsmasq are you using? You will need 2.67\nor better for the client to be identified by mac address\n\nhttps://bugs.launchpad.net/neutron/+bug/1408297\n\nD.\n\n> Message: 5> Date: Fri, 23 Jan 2015 22:53:23 +0000> From: \"Ajay Kalambur (akalambu)\" <akalambu at cisco.com>\n\n> To: \"openstack at lists.openstack.org\" \n> <openstack at lists.openstack.org>\n> Subject: [Openstack] [openstack][neutron] ipv6 DHCP state full issue\n> Message-ID: <D0E80F61.14D15%akalambu at cisco.com>\n> Content-Type: text/plain; charset=\"us-ascii\"\n> \n> Hi\n> I am using Openstack Juno release to test some basic ipv6. I created a\n> ipv6 tenant network and subnet with ip6_ra_mode and ipv6_address_mode set\n> to\n> DHCPv6 stateful. The instance cannot get the DHCP ip address.\n> \n> Reason seems to be that the DHCP advertise message in response to the DHCP\n> solicit message from the client says no address available\n> 14:14:07.861197 IP6 (hlim 1, next-header UDP (17) payload length: 64)\n> fe80::f816:3eff:fee2:25ef.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp\n> sum ok] dhcp6 solicit (xid=172906 (client-ID hwaddr/time type 1 time\n> 454713283 5254005cbf62) (option-request DNS-server DNS-search-list\n> Client-FQDN SNTP-servers) (elapsed-time 295) (IA_NA IAID:1055008239\n> T1:3600 T2:5400))\n> 14:14:07.862505 IP6 (class 0xc0, hlim 64, next-header UDP (17) payload\n> length: 92) fe80::f816:3eff:fe58:88c7.dhcpv6-server >\n> fe80::f816:3eff:fee2:25ef.dhcpv6-client: [udp sum ok] dhcp6 advertise\n> (xid=172906 (client-ID hwaddr/time type 1 time 454713283 5254005cbf62)\n> (server-ID hwaddr/time type 1 time 475357091 fa163e5888c7) (IA_NA\n> IAID:1055008239 T1:4294967295 T2:4294967295) (status-code no addresses))\n> \n> \n> \n> \n> Dnsmasq is launched fine and the hosts file on dhcp seems to be fine\n> fa:16:3e:e2:25:ef,host-2001-50--6.openstacklocal,[2001:50::6]\n> \n> But somehow the DHCP advertise message shows no addresses\n> \n> Ajay\n\n\n','<mailman.27.1422100802.18098.openstack@lists.openstack.org>',NULL),('<1347522849.87210.YahooMailClassic@web112908.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-13 00:54:09',-25200,'2012-09-13 07:54:09',NULL,'[openstack-dev] Asking about Open Stack Development','\n\nDear? All\nI am ulysse?studying?in china and i am contacting you because we have a school project about open stack and i did some research on this mater and found your Community (In this Project we need to develop a open Stack Platform ),i was wondering if you can guide me in this because i am new in?Open Stack,but i have some?knowledge?about PYTHON language.\nThanks for your understanding and help\nRegards!!!\nUlysse\n Rugwiro\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120913/aaede062/attachment.html>\n\n',NULL,NULL),('<1347523226.93336.YahooMailClassic@web112906.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-13 01:00:26',-25200,'2012-09-13 08:00:26',NULL,'[openstack-dev] Asking about Open Stack Development','\n\n\nDear? All\nI\n am ulysse?studying?in china and i am contacting you because we have a \nschool project about open stack and i did some research on this mater \nand found your Community (In this Project we need to develop a open \nStack Platform ),i was wondering if you can guide me in this because i \nam new in?Open Stack,but i have some?knowledge?about PYTHON language.\nThanks\n for your understanding and help\nRegards!!!\nUlysse\n Rugwiro\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120913/1340ee28/attachment-0001.html>\n\n',NULL,NULL),('<1347919009.235631.1415334328127.JavaMail.yahoo@jws10041.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-07 04:25:28',0,'2014-11-07 04:25:28',NULL,'[Openstack] [Cinder] Cinder State Machine - Kilo Design Summit\n Talk - November 5','I have updated?https://etherpad.openstack.org/p/cinder-enforcement-of-states? - Cinder Enforcement of States?with the write-up (in an easily understandable way) for Dynamic state diagram generation depending on the way the flow has been layed out in the code.\nInterested people have a look.\nThanks,Vilobh\n\n \n\n     From: Vilobh Meshram <vilobhmm at yahoo-inc.com>\n To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nCc: Vilobh Meshram <vilobhmm at yahoo-inc.com> \n Sent: Tuesday, November 4, 2014 2:55 PM\n Subject: [Cinder] Cinder State Machine - Kilo Design Summit Talk - November 5\n   \nFollowing Etherpad links will be used for the talk :-\nhttps://etherpad.openstack.org/p/cinder-state-machine-and-rolling-upgrades? - Cinder State Machine and Rolling upgrades\n\nhttps://etherpad.openstack.org/p/cinder-enforcement-of-states? - Cinder Enforcement of States\n\nThanks,Vilobh\n\n\n   \n\n  \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141107/eafe7855/attachment.html>\n\n','<381052305.240408.1415334148603.JavaMail.yahoo@jws100121.mail.ne1.yahoo.com>',NULL),('<1347919009.235631.1415334328127.JavaMail.yahoo@jws10041.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-07 04:25:28',0,'2014-11-07 04:25:28',NULL,'[openstack-dev] [Cinder] Cinder State Machine - Kilo Design\n Summit Talk - November 5','I have updated?https://etherpad.openstack.org/p/cinder-enforcement-of-states? - Cinder Enforcement of States?with the write-up (in an easily understandable way) for Dynamic state diagram generation depending on the way the flow has been layed out in the code.\nInterested people have a look.\nThanks,Vilobh\n\n \n\n     From: Vilobh Meshram <vilobhmm at yahoo-inc.com>\n To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nCc: Vilobh Meshram <vilobhmm at yahoo-inc.com> \n Sent: Tuesday, November 4, 2014 2:55 PM\n Subject: [Cinder] Cinder State Machine - Kilo Design Summit Talk - November 5\n   \nFollowing Etherpad links will be used for the talk :-\nhttps://etherpad.openstack.org/p/cinder-state-machine-and-rolling-upgrades? - Cinder State Machine and Rolling upgrades\n\nhttps://etherpad.openstack.org/p/cinder-enforcement-of-states? - Cinder Enforcement of States\n\nThanks,Vilobh\n\n\n   \n\n  \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141107/eafe7855/attachment.html>\n\n','<381052305.240408.1415334148603.JavaMail.yahoo@jws100121.mail.ne1.yahoo.com>',NULL),('<1348026238.60775.YahooMailClassic@web112905.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-18 20:43:58',-25200,'2012-09-19 03:43:58',NULL,'[openstack-dev] Open Stack Development','Dear All\n\nCould anybody guide me through the open Stack development ? I am new in this area and i am very interested!!\n\nYour advise will be much appreciated\n\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120918/36323f08/attachment.html>\n\n',NULL,NULL),('<1348050996.3521.1.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-09-19 11:36:36',3600,'2012-09-19 10:36:36',NULL,'[OpenStack Foundation] OpenStack Foundation Board Meeting','On Wed, 2012-09-19 at 09:10 +0200, Dave Neary wrote:\n> Hi Joshua et al,\n> \n> On 09/18/2012 10:22 PM, Joshua McKenty wrote:\n> > As far as the agenda for the special meeting, this is actually beyond\n> > the ED position, but addresses staffing the short-term requirements of\n> > the foundation - which involves discussing individuals who currently\n> > have other jobs. The broader staffing plan and budget will be reviewed\n> > and discussed, first by the finance committee, and then by the board as\n> > a whole, in October.\n> \n> Are there plans to advertise the positions you\'re filling short term, or \n> have you already agreed among board members, sponsoring organisations & \n> ED how you plan to fill those positions? I\'d like to see us set a good \n> precedent here.\n\nAs pointed out by @mikal on twitter:\n\nhttp://www.openstack.org/community/jobs/openstack-infrastructure-engineer/\nhttp://www.openstack.org/community/jobs/openstack-user-community-manager\nhttp://www.openstack.org/community/jobs/director-of-business-development\n\nJust posted, apparently\n\nCheers,\nMark.\n\n\n\n','<50596FE0.7040608@redhat.com>',NULL),('<1348160963.686522600@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-20 13:09:23',-14400,'2012-09-20 17:09:23',NULL,'[openstack-dev] DB Migration Testing','\nI couldn\'t agree more with this.\n \n-Alex\n \n-----Original Message-----\nFrom: \"Brian Waldon\" <bcwaldon at gmail.com>\nSent: Tuesday, September 18, 2012 9:57pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] DB Migration Testing\n\n\n\nIt has become painfully obvious over the past few weeks that we aren\'t testing our database migrations nearly well enough. Dean Troyer and myself have found several show-stopping bugs [1] [2] [3] [4] [5] [6] by simply applying the migrations to a running Essex system. I\'d like to propose two things to prevent this from cropping up in the future:\n1) Migrations must come with a test that exercises the database modifications with pre-loaded fixture test data. For examples of these tests see [7] and [8].\n2) Run migration tests on a functional mysql backend in Jenkins.\nI am concerned that there are hidden bugs in the existing migrations; to address this I\'d like to propose a third action:\n3) Revisit existing migrations and add the appropriate testing where necessary\nIf anybody has any additional suggestions, please throw them out there! If this all sounds sane, I\'ll start pushing to make it happen.\nWaldon\n\n\n[1] [https://bugs.launchpad.net/nova/+bug/1047633] https://bugs.launchpad.net/nova/+bug/1047633\n[2] [https://bugs.launchpad.net/nova/+bug/1047665] https://bugs.launchpad.net/nova/+bug/1047665\n[3] [https://bugs.launchpad.net/nova/+bug/1052220] https://bugs.launchpad.net/nova/+bug/1052220\n[4] [https://bugs.launchpad.net/nova/+bug/1052244] https://bugs.launchpad.net/nova/+bug/1052244\n[5] [https://bugs.launchpad.net/nova/+bug/1052252] https://bugs.launchpad.net/nova/+bug/1052252\n[6] [https://bugs.launchpad.net/glance/+bug/1043041] https://bugs.launchpad.net/glance/+bug/1043041\n[7] [https://github.com/openstack/nova/blob/0ffff7c490d54f9b932df4b2dcd62158242dae2a/nova/tests/test_migrations.py#L307] https://github.com/openstack/nova/blob/0ffff7c490d54f9b932df4b2dcd62158242dae2a/nova/tests/test_migrations.py#L307\n[8] [https://github.com/openstack/nova/blob/0ffff7c490d54f9b932df4b2dcd62158242dae2a/nova/tests/test_migrations.py#L327] https://github.com/openstack/nova/blob/0ffff7c490d54f9b932df4b2dcd62158242dae2a/nova/tests/test_migrations.py#L327\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120920/ab4d8b35/attachment-0001.html>\n\n','<61378955-3242-45BA-B597-75194E18E4B4@gmail.com>',NULL),('<1348462455.4534.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-24 05:54:15',3600,'2012-09-24 04:54:15',NULL,'[openstack-dev] Keystone auth_token middleware','On Fri, 2012-09-21 at 19:24 -0500, Dolph Mathews wrote:\n> Agree-- this topic has come up several times, and I think it\'s just a\n> matter of deciding between keystoneclient or openstack-common.\n\nRight, we had a thread on this only 2 weeks ago :)\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-September/001184.html\n\n> Although I wouldn\'t immediately think to look for middleware in a client\n> library,\n\nI don\'t see why it would be so non-obvious for it to live in a client\nlibrary - the code is used by multiple services so a library makes\nsense, it acts as a client to keystone\'s API and a shared middleware\nneeds to have a stable API like any other API in a client library.\n\n> my vote goes to keystoneclient; auth_token should utilize\n> keystoneclient\'s python API anyway.\n\nYep, I too think keystoneclient makes most sense.\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gWX7krmAS5v7mhe7JKuvKaokTNv8hc-JbpA-TqfPxR+HA@mail.gmail.com>',NULL),('<1348498856.3243.48.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-24 10:00:56',-18000,'2012-09-24 15:00:56',NULL,'[openstack-dev] Writing extensions to Nova API','On Fri, 2012-09-21 at 08:46 +0530, Trinath Somanchi wrote:\n> I understand that the extension extend the behavior of an existing\n> expert class. \n> \n> But I have a doubt, How the extension based definitions/methods are\n> mapped to the URI ?\n\nYou might want to take a look at nova/api/openstack/compute/contrib for\nexisting extensions, to get an idea of how extensions are structured.\nIn short, there are two major types of extensions: ControllerExtension,\nwhich extends existing \"expert\" controllers, and ResourceExtension,\nwhich adds a brand new URI endpoint.\n\nFor the ControllerExtension, you specify the short name of the resource\nyou\'re extending; for instance, to extend the behavior\nof /v2/<tenant-id>/servers/detail, you would use \'servers\'.  You\'ll have\nto dig through the code a bit to verify the short names of the\ncontrollers.  As an example of this, check out admin_actions.py.\n\nFor the ResourceExtension, you specify the endpoint name and an optional\nparent.  The underlying Routes package sets up the mapping between\nURI/HTTP method and the controller method name, and it is possible to\nadd methods using the member_actions and collection_actions arguments.\nAs an example of this, check out quotas.py.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAH8Hgmb_pNFoBNgQyFUgFGDWRAo3mfMwcHeHQCkeoR24Vd5dpA@mail.gmail.com>',NULL),('<1348499213.3243.50.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-24 10:06:53',-18000,'2012-09-24 15:06:53',NULL,'[openstack-dev] Troubleshooting the nova api extension','On Mon, 2012-09-24 at 15:09 +0530, Trinath Somanchi wrote:\n> Here, The URI, /server/metadetail? is not being mapped to the method\n> \"metadetail()\" method present in the   extension. \n> \n> Also, its that, the WSGI is mapping, the URI to \"show\" method rather\n> than the \"metadetail\" method.  \'wsgiorg.routing_args\':\n> (<routes.util.URLGenerator object at 0x36f64d0>, {\'action\': u\'show\',\n> \'controller\': <nova.api.openstack.wsgi.Resource object at 0x4644750>,\n> \'project_id\': u\'e216fcb54dc944a8ab16e4e325299643\', \'id\':\n> u\'metadetail\'}) \n> \n> Please guide me on how to fix the issue such that the URL with\n> \"/server/metadetail\" is mapped to the \"metadetail\" method in the new\n> extension. \n\nUnfortunately, this isn\'t going to be possible using a\nControllerExtension, because of the way nova sets up its routes?there\'s\nno way to merge the controller actions from the ControllerExtension with\nthe creation of the server resource.  Try a ResourceExtension with the\nservers resource as the parent; that may work better for you.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAH8Hgmbq74n4tDR16awWK6o1eV1R5NLRJYC52R-rCh2r2nfMYg@mail.gmail.com>',NULL),('<1348605931.2264.50.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 21:45:31',3600,'2012-09-25 20:45:31',NULL,'[openstack-dev] Quantum + ZeroMQ (with a sprinkling of Nova) in\n	Folsom','On Tue, 2012-09-25 at 13:28 -0400, Eric Windisch wrote:\n> Russell, perhaps. The issue is that if the message format changes, it\n> would be lower cost to do it now. Also, I\'m moving this to the public\n> list, because I agree that it is a good time to do it. \n> \n> IF there is an RC3 for Nova, I\'d like for consideration to get the\n> message-format change in, because it reduces complexity for Grizzly\n> (having to understand two formats), and because it will make the\n> Quantum code supportable. This binary needs to move outside of Nova to\n> avoid this unnecessary interdependency.\n> \n> It might be resolvable by adding a version to the message format, but\n> it doesn\'t solve the problem today - which, arguably, doesn\'t have to\n> be solved. We can just release with the zeromq stuff broken in Quantum\n> for Folsom, without any ability to backport, and I\'m prepared for that\n> to happen. I\'ve just rallied for a best-effort to get it in, because\n> it would be a nice to have, after finding out at F3 that it wouldn\'t\n> work.\n> \n> As it is, the patch that is already in Quantum should be enough to get\n> us going for Folsom if we can also get the patch into Nova. The two\n> patches pending review can be backported, if necessary. \n\nIt took me a while to make any sense of this\n\nThis change which was merged into openstack-common a few days ago:\n\n  https://review.openstack.org/11408\n\nis what changed the message format?\n\nI must admit I didn\'t realize there was a backwards compatibility issue\nwith that patch.\n\nSo, the message format used by zmq in Nova is incompatible with what\'s\nused in Quantum.\n\nAt this point I\'d be inclined to document the zmq driver as unstable and\nwarn users that it\'s only included in Folsom as a \"preview\". Making\nincompatible changes days before the release should tell us that we\'re\nnot ready to commit to maintaining compatibility with this driver yet.\n\nIf we don\'t document it as unstable, we have two choices before the\nfinal Folsom release - either merge the new format into Nova or revert\nit from Quantum.\n\nCheers,\nMark.\n\n\n\n','<90EC6177FC214FAE962A981C8F66B09A@cloudscaling.com>',NULL),('<1348606702.2264.53.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 21:58:22',3600,'2012-09-25 20:58:22',NULL,'[openstack-dev] Quantum + ZeroMQ (with a sprinkling of Nova) in\n	Folsom','On Tue, 2012-09-25 at 16:53 -0400, Eric Windisch wrote:\n> Note that before this patch, it wasn\'t at all compatible with Quantum. \n> \n> Even leaving Nova as it is, it could simply be \"unsupported\" in Quantum.\n> \n> For Grizzly, we can either opt to revert this change to the message format, or\n> support versioning.\n\nOk, how about just removing impl_zmq.py from Quantum?\n\nThat way, we\'re only allowing zmq to be used in Nova and commit to\nchanging the message format in compatible ways\n\nHow about zmq in Ceilometer and Cinder? Are they compatible with the\ncurrent Nova message format?\n\nCheers,\nMark.\n\n\n\n','<4F8D7B62F24C4EFAA5D6BD061ED05B3C@cloudscaling.com>',NULL),('<1348671119.3204.6.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-26 09:51:59',-18000,'2012-09-26 14:51:59',NULL,'[openstack-dev] Writing Openstack Nova API extensions','On Wed, 2012-09-26 at 10:37 +0530, Trinath Somanchi wrote:\n> But I execute the URL as\n> \"GET http://10.232.90.82:8774/v2/e216fcb54dc944a8ab16e4e325299643/servers/metadetail?key=Created+By&value=TestApp.py\"\n\nAs you have declared the ResourceExtension, the URL that maps to the\nmetadetail method would be, I believe, more like this:\n\n        http://10.232.90.82:8774/v2/<tenant>/servers/server_actions/metadetail\n\nYou might try that and see if that gets you any closer to your goal.\n\nWhat I would suggest trying for the ResourceExtension declaration would\nbe something more like ResourceExtension(\'metadetail\',\nServerMetaDetailController(), parent=dict(?)) and implementing the\nindex() method to report your metadetail call.\n\n(Also, it\'s probably a bad idea to use \"server_actions.py\" to contain\nyour extension code, since that duplicates the name of an existing\nextension.  Probably not a problem for PoC code as you\'re trying to\nfigure out how extensions work, but when you get ready for production,\nmake sure your names make sense and are distinct?)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAH8HgmZQ6y0X_KwegOEdOh9dwB1Bbk6U5snOvOgNZR8yBsPDKA@mail.gmail.com>',NULL),('<1348675594.3204.27.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-26 11:06:34',-18000,'2012-09-26 16:06:34',NULL,'[openstack-dev] Writing Openstack Nova API extensions','On Wed, 2012-09-26 at 21:00 +0530, Trinath Somanchi wrote:\n> 1. What are Controller and Resource extensions? How do they differ?\n\nOK, so term definition time.  Nova uses the Routes[1] software to map\nURI/HTTP method to a function to call.  Routes happens to provide a\nshort-cut interface for setting up the routes for REST-style calls\n(which is what Nova uses); the call is resource()[2].\n\nNow, in Nova\'s world, a \"Resource\" is one of these top-level things; it\nhas operations like index() (\"GET <resource>\"), show() (\"GET\n<resource>/<id>\"), update() (\"PUT <resource>/<id>\"), delete() (\"DELETE\n<resource>/<id>\"), etc.  (See the Routes documentation for the full\nlist.)  A ResourceExtension is an extension that allows creation of one\nof these resources, and the \"parent\" stuff allows you to link that\nresource to be under another resource, i.e., \"GET <parent>/<resource>\"\nmaps to index(), \"GET <parent>/<resource>/<id>\" maps to show(), etc.\n\nA ControllerExtension, on the other hand, allows you to extend an\nexisting resource?usually one of the basic Nova resources\n(i.e., /servers).  With this kind of extension, you can add an\n\"action\" (not your current use case, but see below), or you can wrap an\nexisting (and only an existing!) method of that resource.  This\nlimitation is why I suggested you should try using a ResourceExtension\nfor your use case?there\'s no way to add a new method to an existing\nresource without modifying the code that creates that existing resource.\n\n> 2. How do client requests differ for these type of extensions? Can you\n> give some examples on this.\n\nClient requests don\'t differ at all for these types of extensions; it\'s\nthe semantics of what they mean.\n\nI should note that I can see a way to use a ControllerExtension to\nretrieve metadetails, but you wouldn\'t be doing GET /servers/metadetail;\nyou would be doing POST /servers/action, and the body that you POSTed\nwould convey the request for metadetails.  (You could also use this body\nto convey the query parameters.)  This is called an \"action\", and if you\nwant to see examples of how this works, check out the admin_actions.py\nextension you\'ve already looked at?it defines a whole bunch of actions.\n\nThe Nova API system is rather complicated, and the best documentation\nfor how to modify and extend it is still the code, unfortunately.  I\nhope that I\'ve helped you understand it a bit more clearly, but keep in\nmind that much of what I\'ve stated here is from memory, so it might be\nworth reading the code for yourself to make sure I got it right :)\n\n--\n\n[1] http://routes.readthedocs.org/en/latest/index.html\n[2] http://routes.readthedocs.org/en/latest/restful.html\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAH8HgmbHsKv6ufnRj+TfgePvh6FOBq2_J1Fkt1TALnEnYomA8Q@mail.gmail.com>',NULL),('<134869631.2912406.1384347517512.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 12:58:37',0,'2013-11-13 12:58:37',NULL,'[openstack-dev] [nova][scheduler] Instance Group Model and APIs\n - Updated document with an example request payload','\n\nHi all, \n\nHaving no info from the HK summit on this topic, I would like to re-open it in the mailing list. \n\nMy concerns with the API is that it does not refer to a particular (scheduling) component. In my \nunderstanding, it comes along with the SolverScheduler proposal. However, we does not know whether \nthis component is located either. The first implementation suggests that it would located within Nova, \nbut, as the discussion goes on, I believe that it will have interractions with Cinder & Neutron \nalso. Thus its position and its (possible) relation with Heat and other *-scheduler is unclear. \n\nThe reason I want to point out this is that normally we would design a global architecture, then \ndepending on the funcitonality of a component and its interactions with other components that we \nwould define its API. This API, however, does not refer to any particular component. In my \nunderstanding, it is designed so that users could define their request as a whole, as opposed to \ncurrent openstack where users have to make requests for nova, cinder and neutron independently. \n\nWith that purpose in mind, I wonder if the component that would receive this request should be Heat? \n\'Cause users will not send two requests for the same application. In this case we should extend Heat \nAPI to accept this kind of request, not to define a completely new one. If, however, that the \ncomponent that this API is not user-facing (i.e. designed for some meta-scheduler which receives request \nthat are generated from another component, such as Heat), then the API should be designed in the way \nthat reflex this aspect. \n\nAnyway, I would like that before we go further, please give a global architecture that would benefit \nfrom such a functionality and which component that would receive and make use of this request. \n\nToan \n\n----- Original Message -----\n\nFrom: \"Mike Spreitzer\" <mspreitz at us.ibm.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Wednesday, October 30, 2013 6:34:51 PM \nSubject: Re: [openstack-dev] [nova][scheduler] Instance Group Model and APIs - Updated document with an example request payload \n\nAlex Glikson <GLIKSON at il.ibm.com> wrote on 10/30/2013 02:26:08 AM: \n\n> Mike Spreitzer <mspreitz at us.ibm.com> wrote on 30/10/2013 06:11:04 AM: \n> > Date: 30/10/2013 06:12 AM \n> > \n> > Alex also wrote: \n> > ``I wonder whether it is possible to find an approach that takes \n> > into account cross-resource placement considerations (VM-to-VM \n> > communicating over the application network, or VM-to-volume \n> > communicating over storage network), but does not require delivering \n> > all the intimate details of the entire environment to a single place \n> > -- which probably can not be either of Nova/Cinder/Neutron/etc.. but \n> > can we still use the individual schedulers in each of them with \n> > partial view of the environment to drive a placement decision which \n> > is consistently better than random?\'\' \n> > \n> > I think you could create a cross-scheduler protocol that would \n> > accomplish joint placement decision making --- but would not want \n> > to. It would involve a lot of communication, and the subject matter \n> > of that communication would be most of what you need in a \n> > centralized placement solver anyway. You do not need \"all the \n> > intimate details\", just the bits that are essential to making the \n> > placement decision. \n> \n> Amount of communication depends on the protocol, and what exactly \n> needs to be shared.. Maybe there is a range of options here that we \n> can potentially explore, between what exists today (Heat talking to \n> each of the components, retrieving local information about \n> availability zones, flavors and volume types, existing resources, \n> etc, and communicates back with scheduler hints), and having a \n> centralized DB that keeps the entire data model. \n> Also, maybe different points on the continuum between \'share few\' \n> and \'share a lot\' would be a good match for different kinds of \n> environments and different kinds of workload mix (for example, as \n> you pointed out, in an environment with flat network and centralized \n> storage, the sharing can be rather minimal). \n\nI\'m not going to claim the direction you\'re heading is impossible, I am not good at impossibility proofs. But I do wonder about the why of it. This came up in the context of the issues around the fact that orchestration is downstream from joint decision making. Even if that joint decision making is done in a distributed way, orchestration will still be downstream from it. \n\nThanks, \nMike \n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/1d08ca84/attachment.html>\n\n','<OF65249B1B.0D7F602A-ON85257C14.006030B6-85257C14.00609163@us.ibm.com>',NULL),('<1348740674.2281.43.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-27 11:11:14',3600,'2012-09-27 10:11:14',NULL,'[openstack-dev] [CI] Gerrit Trivial Rebase Detection (LP bug\n 881184)','On Tue, 2012-09-11 at 10:22 -0500, Monty Taylor wrote:\n> \n> On 09/11/2012 09:56 AM, Mark McLoughlin wrote:\n> > On Tue, 2012-09-11 at 14:43 +0000, Jeremy Stanley wrote:\n> >> On 2012-09-11 12:15:37 +0000 (+0000), Jeremy Stanley wrote:\n> >>> It appears that git-patch-id is fairly inflexible in this regard,\n> >>> taking no options to alter its whitespace-ignoring behaviors. It\'s\n> >>> doing something akin to diff\'s -w whereas the behavior we\'d want is\n> >>> more likely along the lines of -BEb instead... or maybe even none at\n> >>> all, since this also has implications for work which could in fact\n> >>> be whitespace-only (PEP 8 conformance fixes, for example).\n> >> [...]\n> >>\n> >> Based on a quick IRC discussion on -infra it sounds like the next\n> >> step would be to implement a new CLI option in git-patch-id, causing\n> >> it to consider all whitespace changes substantive (and then see if\n> >> we can get this feature merged upstream in Git as well).\n> > \n> > Sounds difficult.\n> > \n> > Any thoughts on the point about rebase-detection not being so important\n> > now that git-review no longer rebases gratuitously?\n> \n> I think the two are orthogonal - I don\'t think the auto-rebase was the\n> cause of all of our rebases. If we can get this to not ignore\n> whitespace, I think it\'ll still be quite helpful in the cases where it\n> matches.\n\nFor the record, rebase detection is proving useful where there are\nmultiple patches in a series and you need to fix one of the earlier\npatches\n\ni.e. you rebase, fix an earlier patch, re-upload and any +1/+2s you\nreceived on later patches aren\'t lost\n\nIs there a bug to track the whitespace ignoring issue?\n\nCheers,\nMark.\n\n\n\n','<504F5746.1000902@inaugust.com>',NULL),('<1348756679.3204.31.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-27 09:37:59',-18000,'2012-09-27 14:37:59',NULL,'[openstack-dev] Writing Openstack Nova API extensions','On Thu, 2012-09-27 at 10:28 +0530, Trinath Somanchi wrote:\n> [1] What are Member action and Collection actions? I see them in the\n> Source code, of the ResourceExtension. Can you shower some light on\n> these terms, their usage and significance.\n\nThe \"member_actions\" and \"collection_actions\" keyword arguments map to\nthe \"member\" and \"action\" keyword arguments to Routes\' resource()\nmethod.  See:\n\n        http://routes.readthedocs.org/en/latest/restful.html#resource-options\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAH8HgmansRmPn=E67tmikh1Efp2hP4t-7hucWrN2Hctcao8Faw@mail.gmail.com>',NULL),('<1348908332.95552.YahooMailClassic@web112913.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-29 01:45:32',-25200,'2012-09-29 08:45:32',NULL,'[openstack-dev] Swift Application','Dear all\n\nI want your help on something,i want to write an application that could help me store some file \non a cloud storage and also help me give away the right access to the file (Full access,read only,or modify).\n\nAny Idea on how i could accomplish this?\n\nRegards!!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120929/6c8c6934/attachment-0001.html>\n\n',NULL,NULL),('<1348940401.2660297.1344863520261.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-13 13:12:05',0,'2012-08-13 13:12:05',NULL,'[Openstack-operators] [Openstack] [Nova] How common is\n	user_data for instances?','\n\n----- Original Message -----\n> From: \"Michael Still\" <michael.still at canonical.com>\n> To: openstack at lists.launchpad.net, openstack-operators at lists.openstack.org\n> Sent: Saturday, August 11, 2012 5:12:22 AM\n> Subject: [Openstack] [Nova] How common is user_data for instances?\n> \n> Greetings.\n> \n> I\'m seeking information about how common user_data is for instances\n> in\n> nova. Specifically for large deployments (rackspace and HP, here\'s\n> looking at you). What sort of costs would be associated with changing\n> the data type of the user_data column in the nova database?\n> \n> Bug 1035055 [1] requests that we allow user_data of more than 65,535\n> bytes per instance. Note that this size is a base64 encoded version\n> of\n> the data, so that\'s only a bit under 50k of data. This is because the\n> data is a sqlalchemy Text column.\n> \n> We could convert to a LongText column, which allows 2^32 worth of\n> data,\n> but I want to understand the cost to operators of that change some\n> more.\n> Is user_data really common? Do you think people would start uploading\n> much bigger user_data? Do you care?\n\nNova has configurable quotas on most things so if we do increase the size of the DB column we should probably guard it in a configurable manner with quotas as well.\n\nMy preference would actually be that we go the other way though and not have to store user_data in the database at all. That unfortunately may not be possible since some images obtain user_data via the metadata service which needs a way to look it up. Other methods of injecting metadata via disk injection, agents and/or config drive however might not need it to be store in the database right?\n\nAs a simpler solution:\n\nWould setting a reasonable limit (hopefully smaller) and returning a HTTP 400 bad request if incoming requests exceed that limit be good enough to resolve this ticket? That way we don\'t have to increase the DB column at all and end users would be notified up front that user_data is too large (not silently truncated). They way I see it user_data is really for bootstrapping instances... we probably don\'t need it to be large enough to write an entire application, etc.\n\n\n> \n> Mikal\n> \n> 1: https://bugs.launchpad.net/nova/+bug/1035055\n> \n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n> \n\n\n','<502621F6.9040600@canonical.com>',NULL),('<1349106813.2210.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-01 16:53:33',3600,'2012-10-01 15:53:33',NULL,'[openstack-tc] Designation of TC Chair','On Mon, 2012-10-01 at 11:24 +0200, Thierry Carrez wrote:\n\n> I have been filling the TC Chair duties during all the TC setup phase,\n> and would be happy to continue to do so. I happen to know the TC rules\n> well, since I wrote them. If someone else is interested by the role (or\n> more people), please say so and we can have a quick vote to decide this.\n\nFWIW, I think it makes perfect sense for you to be TC Chair.\n\nCheers,\nMark.\n\n\n\n','<50696148.7040101@openstack.org>',NULL),('<1349193864.28748.3.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-02 17:04:24',3600,'2012-10-02 16:04:24',NULL,'[OpenStack Foundation] Individual Member Election Statistics','On Tue, 2012-10-02 at 08:37 -0700, James E. Blair wrote:\n> Before the election, the issue of influence of corporate entities in\n> the individual member election was raised.  As a result, the election\n> inspectors agreed it would be beneficial to analyze the election\n> results to help quantify the role employers played in the election.\n\nJames and co - that\'s an excellent piece of work, really fascinating.\nWell done.\n\nThis kind of transparency is really great to see - I\'m sure we\'ll all\njudge these stats differently and draw different conclusions on what\nthis means for the future, but at least we\'re making those judgements\nbased on real data.\n\nThanks again,\nMark.\n\n\n\n','<87y5jo3mwc.fsf@meyer.lemoncheese.net>',NULL),('<1349279378.23148334@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-03 11:49:38',-14400,'2012-10-03 15:49:38',NULL,'[OpenStack Foundation] Individual Member Election Statistics','I will take the action to talk with our attorney to understand the feasibility of using condorcet in the future.\n\nMark\n\n\nOn Wednesday, October 3, 2012 11:18am, \"Monty Taylor\" <mordred at inaugust.com> said:\n\n> \n> \n> On 10/03/2012 02:39 AM, Thierry Carrez wrote:\n>>> We need to discuss how to\n>>> raise the bar of membership entry just enough to improve that.\n>>\n>> Alternatively (or additionally), we could switch to Condorcet, which is\n>> an election method that specifically does not fill the proportionality\n>> criteria. 30% of voters won\'t give you anything, especially if the other\n>> 70% don\'t like you that much.\n>>\n>> It would favor consensus candidates, which in this case (individual\n>> member election) could be a good idea.\n>>\n>> AFAIK there is a lawyer question about accepted election methods for\n>> corporate boards under Delaware law, but I think that\'s an option that\n>> we should definitely explore.\n> \n> I support any and all efforts for us to use Condorcet instead of cumulative.\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<506C5748.3000704@inaugust.com>',NULL),('<1349447755.2415.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-05 15:35:55',3600,'2012-10-05 14:35:55',NULL,'[openstack-tc] In-person Technical Committee meeting in San\n Diego','On Fri, 2012-10-05 at 11:06 +0200, Thierry Carrez wrote:\n> Hi everyone,\n> \n> We should have our first Technical Committee meeting in-person in San\n> Diego. Let me know if you have any time constraint.\n> \n> Ideally it would happen one of the days at 6pm after the end of the\n> regular sessions, in some quiet area of some bar. I\'d propose Tuesday or\n> Wednesday at 6pm, so that we have the formal approval of the Board of\n> Directors regarding the designation of the TC Chair. It should only take\n> an hour. Alternatively we could do it over lunchtime one of the days.\n> Preferences ?\n\nI think it\'d be excellent to get us together like this. Count me in for\nsure. Wednesday evening sounds good.\n\n> The agenda lives at:\n> http://wiki.openstack.org/Governance/TechnicalCommittee\n> \n> If you have more stuff to add to this first meeting, please send an\n> email to this list and I\'ll add it to the agenda. If it\'s a formal\n> decision you\'re requesting, please follow the guidelines at the bottom\n> of that wiki page.\n\nI wonder should we defer these agenda items to our more normal IRC\nmeetings. The openness and archiving of the IRC meetings is really\nimportant IMHO and I wouldn\'t be happy for us to vote on an incubation\nproposal offline.\n\nI guess I\'d hope for a meeting like this to be more of a brainstorming\nsession than an actual decision-making meeting.\n\nFor an agenda, how about each PTL describes briefly the challenges their\nproject is currently facing and the directly-elected members do the same\nfrom a more cross-project perspective. As we go along, we build up a\nlist of discussion topics before finally picking the most important\ntopics and go into those in greater detail?\n\nCheers,\nMark.\n\n\n\n','<506EA319.30306@openstack.org>',NULL),('<1349678943.19587.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-08 07:49:03',3600,'2012-10-08 06:49:03',NULL,'[openstack-dev] Bare-metal node scheduling','Hi,\n\nI\'m reviewing the first of the \"general bare-metal provisioning\"\npatches:\n\n  https://review.openstack.org/13920\n\nand I\'m really very concerned at how invasive this is to the core\ncompute scheduling infrastructure.\n\nBasically, we\'re adding infrastructure so that a virt driver in a single\ncompute service can cause the resources of multiple \"nodes\" to be\nadvertised to the scheduler.\n\nMaking already confusing core infrastructure much more confusing for the\nsake of a single virt driver seems like a bad idea.\n\nWhat we\'re doing is allowing the scheduler to choose a compute node\nbased on the details of the individual bare-metal nodes available via\nthe compute node. However, the compute node is still responsible for\nchoosing which bare-metal node to provision.\n\nHow about we take a more simple approach?\n\n - Assume that each compute node has a homogeneous set of bare-metal \n   nodes\n\n - Have the bare-metal virt driver advertise the resources of a single\n   bare-metal node as the resources of the compute node\n\n - Allow the number of un-provisioned bare-metal nodes to be advertised\n   to the scheduler\n\n - Add a scheduler filter which will ignore compute nodes with no \n   un-provisioned bare-metal nodes\n\n - Perhaps add a scheduler filter which will ignore compute nodes whose \n   resources are not an exact match for the instance type\n\n - Add a weighting function based on the number of un-provisioned \n   bare-metal nodes that will allow choosing between a fill-first and \n   spread-first strategy\n\nSince the only extra information we need to get to the scheduler is the\nnumber of un-provisioned bare-metal nodes, I think this would be much\nmore simple.\n\nAs for terminology, rather than the scheduler considering \"nodes\" I\nthink \"slots\" would be less confusing.\n\nYou could imagine extending this scheme to other virt drivers to give\nproviders the option of a much more simple and predictable scheduling\nstrategy. You could configure a compute node to have e.g. 10 medium size\n\"slots\" and the scheduler would only ever schedule 10 medium size\ninstances to that node. This could potentially be a way for providers to\nsimplify their capacity planning.\n\nFor reference, bare-metal node scheduling was discussed previously on\nthis thread:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-August/000627.html\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1349704229.19587.106.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-08 14:50:29',3600,'2012-10-08 13:50:29',NULL,'[openstack-dev] Bare-metal node scheduling','On Mon, 2012-10-08 at 14:21 +0100, John Garbutt wrote:\n> Interesting ideas.\n> \n> > What we\'re doing is allowing the scheduler to choose a compute node\n> > based on the details of the individual bare-metal nodes available via the\n> > compute node. However, the compute node is still responsible for choosing\n> > which bare-metal node to provision.\n> \n> While I don\'t like this approach, it could be used for Hypervisor pools.\n> We did wonder about this for XenServer pools. However, it just seemed too messy.\n> For example, when you want to live migrate between two members of the pool using nova.\n\nYeah, I\'m not loving the idea of the nova scheduler knowing much if\nanything about the details of the resource available to a\nvirt-driver-layer scheduler.\n\nAnother example would be if there was a virt driver for oVirt, I\'d much\nrather if nova knew nothing about individual oVirt hosts but rather if\nthe admin configured a bunch of compute slots representing the resources\nwhich nova is allowed to consume from an oVirt cluster.\n\n> > As for terminology, rather than the scheduler considering \"nodes\" I think\n> > \"slots\" would be less confusing.\n> > \n> > You could imagine extending this scheme to other virt drivers to give\n> > providers the option of a much more simple and predictable scheduling\n> > strategy. You could configure a compute node to have e.g. 10 medium size\n> > \"slots\" and the scheduler would only ever schedule 10 medium size\n> > instances to that node. This could potentially be a way for providers to\n> > simplify their capacity planning.\n> \n> This sounds like a good idea.\n\nCool.\n\n> I have wondered about an alternative scheduler where each nova-compute\n> node is configured with a supported set of flavours, and it reports to\n> the scheduler how many of each flavour it still has the capacity to\n> run (i.e. full-ish hypervisor reports: 4 tiny instances or 1 small\n> instance, 0 large instances etc, but baremetal: 0 tiny, 3 small, 10\n> large, etc). That seems to unify the two cases.\n\nYeah, that\'s the way I\'m thinking.\n\nThe issue with making this about configuring a compute node with a set\nof flavours is that we\'re working towards having the compute node not\naccess the DB at all.\n\nThis means the \"compute slots\" configuration would need to live in the\nDB. I guess that\'s pretty nice in way because we can have a proper admin\nAPI for it.\n\n> For the above, I was thinking about GPU pass-through. You probably\n> don\'t want to fill up a GPU pass-through enabled hypervisors with\n> standard instances, unless there is no other option. So you could use\n> the above information to write such a server. Once you have used the\n> GPUs, you might want to fill up the server with tiny instances to\n> maybe save on power.\n\nYou could use slots for this, but the simple version wouldn\'t have the\nflexibility around allowing GPU slots to be used for standard instances\nif there was no room elsewhere.\n\nCheers,\nMark.\n\n\n\n','<FFDB98DC9661D3418B9EB0FF5202E46BE7D5E27320@LONPMAILBOX01.citrite.net>',NULL),('<1349712218.77725.YahooMailClassic@web112914.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-08 09:03:38',-25200,'2012-10-08 16:03:38',NULL,'[openstack-dev] Swift App','Hello everyone !!\n?\nI would like your advice on swift application development.\n?\n\" How a client can talk directly to a swift cluster without a web service invorved?\"\n?\nThis question have been in my mind for long and i dont seem to have figured out how to make such application in python. any ideas??\n?\nRegards!!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121008/8c302619/attachment.html>\n\n',NULL,NULL),('<1349759198.19587.151.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-09 06:06:38',3600,'2012-10-09 05:06:38',NULL,'[openstack-dev] [Quantum] folsom-backport-potential','On Tue, 2012-10-09 at 12:15 +0900, Yoshihiro Kaneko wrote:\n> Hi Quantum team,\n> \n> Can I add folsom-backport-potential tag to my bug report, or does core developer\n> determine whether the bugfix should be merged into folsom branch?\n\nAdding folsom-backport-potential to bugs you think are suitable for\nbackporting is very useful to the stable-maint team - it doesn\'t\nguarantee the fix will be backported, but it does get the issue on our\nradar.\n\nCheers,\nMark.\n\n\n\n','<CAH1o70JTzjh42CLOHBNrHo0HnwuY+1vGYd=+KChupiXrVQ+qUw@mail.gmail.com>',NULL),('<1349876702.19587.198.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 14:45:02',3600,'2012-10-10 13:45:02',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n	policy decisions','Hey,\n\nJust yanking this discussion out of gerrit so it doesn\'t get lost in a\nclosed review: https://review.openstack.org/14245\n\nOn Wed, 2012-10-10 at 01:55 +0000, Vish Ishaya (Code Review) wrote:\n\n> I like the rewrites of the policy code, but I\'m not so sure about this\n> addition. Giving too much freedom in the control of policy rules leads\n> to inconsistently defined rules. If some policy checks can return\n> \"roles\" to allow for different behaviors then we have some policy\n> controls being defined in the policy engine, and some in the how the\n> results of the call are used. I can see this leading to a big mess in\n> the future.\n>\n> I think the policy implementation is clearer when every complex policy\n> decision is \"denormalized\" into one action and one target with a\n> simple true-false response. If you want some roles to be able to (for\n> example) modify a specific field, then there should be an action for\n> modifying that particular field. Otherwise I think the policy will\n> become overly complex and hard to follow.\n\nThat seems like a good point. I admit that I didn\'t pay enough attention\nto how this would actually be used.\n\nIn the docs, Kevin says:\n\n  Consider a function that not only wants to check whether a user is\n  allowed to modify an object, but wants to see which set of fields the\n  user is allowed to modify.  For this, we can use the new \"case\"\n  expression::\n\n      case {\n        \"fulladmin\" = role:admin;\n        \"projectadmin\" = project_id:%(project_id)s and role:projectadmin\n      }\n\nIf we take a specific example of admin_actions:pause, this would allow\nthe rule to not just say \"the action is allowed\" but also \"the action is\nallowed because the user is a full admin\" or \"the user is a project\nadmin\".\n\nThe question then would be, what does nova do with that info? And if\nnova might make a decision that something is allowed for \"fulladmin\" but\nnot \"projectadmin\", then why aren\'t they not two separate rules in the\npolicy? By hard-coding the \"full vs project admin\" decision in Nova, it\nmeans it\'s not configurable in the policy.\n\nKevin - maybe you could elaborate more on the specific use case?\n\nCheers,\nMark.\n\n\n\n','<E1TLlVu-000237-4D@review.openstack.org>',NULL),('<1349881571.3204.66.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 10:06:11',-18000,'2012-10-10 15:06:11',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n policy decisions','On Wed, 2012-10-10 at 14:45 +0100, Mark McLoughlin wrote:\n> > I think the policy implementation is clearer when every complex policy\n> > decision is \"denormalized\" into one action and one target with a\n> > simple true-false response. If you want some roles to be able to (for\n> > example) modify a specific field, then there should be an action for\n> > modifying that particular field. Otherwise I think the policy will\n> > become overly complex and hard to follow.\n> \n> That seems like a good point. I admit that I didn\'t pay enough attention\n> to how this would actually be used.\n> \n> In the docs, Kevin says:\n> \n>   Consider a function that not only wants to check whether a user is\n>   allowed to modify an object, but wants to see which set of fields the\n>   user is allowed to modify.  For this, we can use the new \"case\"\n>   expression::\n> \n>       case {\n>         \"fulladmin\" = role:admin;\n>         \"projectadmin\" = project_id:%(project_id)s and role:projectadmin\n>       }\n> \n> If we take a specific example of admin_actions:pause, this would allow\n> the rule to not just say \"the action is allowed\" but also \"the action is\n> allowed because the user is a full admin\" or \"the user is a project\n> admin\".\n> \n> The question then would be, what does nova do with that info? And if\n> nova might make a decision that something is allowed for \"fulladmin\" but\n> not \"projectadmin\", then why aren\'t they not two separate rules in the\n> policy? By hard-coding the \"full vs project admin\" decision in Nova, it\n> means it\'s not configurable in the policy.\n> \n> Kevin - maybe you could elaborate more on the specific use case?\n\nThe specific case I had in mind was a hypothetical case where an API\nupdate method allows all fields to be updated for admin users but only\nsome fields to be updated for project admins.  For instance, maybe a\nfull admin can change which project the object belongs to as well as\nsome limit, while a project admin should only be able to alter the\nlimit.  I believe this was one element of the (now reverted) user quotas\npatch, which ended up having quota keys\n\"compute_extension:quotas:update_admin\" and\n\"compute_extension:quotas:update_project_admin\".\n\nIn my opinion, there is some merit to the desire to keep policies\nsimple, i.e., true-false decision making; but I fear we could end up\nwith an explosion of policy rules like those the user quotas patch\nadded, which I believe will make the policy files harder to understand\nas we enhance nova.   I (obviously :) feel that having the \"case\"\nenhancement strikes a good balance between the two extremes here.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<1349876702.19587.198.camel@sorcha>',NULL),('<1349884765.19587.215.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 16:59:25',3600,'2012-10-10 15:59:25',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n	policy decisions','Hey Kevin,\n\nOn Wed, 2012-10-10 at 10:06 -0500, Kevin L. Mitchell wrote:\n> On Wed, 2012-10-10 at 14:45 +0100, Mark McLoughlin wrote:\n> > > I think the policy implementation is clearer when every complex policy\n> > > decision is \"denormalized\" into one action and one target with a\n> > > simple true-false response. If you want some roles to be able to (for\n> > > example) modify a specific field, then there should be an action for\n> > > modifying that particular field. Otherwise I think the policy will\n> > > become overly complex and hard to follow.\n> > \n> > That seems like a good point. I admit that I didn\'t pay enough attention\n> > to how this would actually be used.\n> > \n> > In the docs, Kevin says:\n> > \n> >   Consider a function that not only wants to check whether a user is\n> >   allowed to modify an object, but wants to see which set of fields the\n> >   user is allowed to modify.  For this, we can use the new \"case\"\n> >   expression::\n> > \n> >       case {\n> >         \"fulladmin\" = role:admin;\n> >         \"projectadmin\" = project_id:%(project_id)s and role:projectadmin\n> >       }\n> > \n> > If we take a specific example of admin_actions:pause, this would allow\n> > the rule to not just say \"the action is allowed\" but also \"the action is\n> > allowed because the user is a full admin\" or \"the user is a project\n> > admin\".\n> > \n> > The question then would be, what does nova do with that info? And if\n> > nova might make a decision that something is allowed for \"fulladmin\" but\n> > not \"projectadmin\", then why aren\'t they not two separate rules in the\n> > policy? By hard-coding the \"full vs project admin\" decision in Nova, it\n> > means it\'s not configurable in the policy.\n> > \n> > Kevin - maybe you could elaborate more on the specific use case?\n> \n> The specific case I had in mind was a hypothetical case where an API\n> update method allows all fields to be updated for admin users but only\n> some fields to be updated for project admins.  For instance, maybe a\n> full admin can change which project the object belongs to as well as\n> some limit, while a project admin should only be able to alter the\n> limit.  I believe this was one element of the (now reverted) user quotas\n> patch, which ended up having quota keys\n> \"compute_extension:quotas:update_admin\" and\n> \"compute_extension:quotas:update_project_admin\".\n\nSo, we\'re talking about this:\n\n https://github.com/openstack/nova/commit/391f345d\n\n      \"admin_or_owner\":  [[\"role:admin\"], [\"project_id:%(project_id)s\"]],\n +    \"admin_or_projectadmin\": [[\"role:projectadmin\"], [\"role:admin\"]],\n \n -    \"compute_extension:quotas:update\": [[\"rule:admin_api\"]],\n +    \"compute_extension:quotas:update_for_project\": [[\"rule:admin_api\"]],\n +    \"compute_extension:quotas:update_for_user\": [[\"rule:admin_or_projectadmin\"]],\n\nAnd then:\n\n +        if \'user_id\' in params:\n +            # Project admins are able to modify per-user quotas.\n +            authorize_action(context, \'update_for_user\')\n ...\n +        else:\n +            # Only admins are able to modify per-project quotas.\n +            authorize_action(context, \'update_for_project\')\n\n(There\'s an obvious issue in the above that we\'re making the\n\"projectadmin\" role apply to all projects, not just ones the\nprojectadmin is a member of)\n\nYour idea would be to make it more like:\n\n +        if \'user_id\' in params:\n +            # Project admins are able to modify per-user quotas.\n +            authorize_action(context, \'update\', require=\'projectadmin\')\n ...\n +        else:\n +            # Only admins are able to modify per-project quotas.\n +            authorize_action(context, \'update\', require=\'fulladmin\')\n\nWhich is just as configurable in the policy, but won\'t result in an\nexplosion of rules where we want to make similar distinctions. It is\nconfusing, though, since you\'d need to document it in the policy with\ne.g\n\n +    # Valid rule results are False, \'fulladmin\' or \'projectadmin\'\n +    \"compute_extension:quotas:update\": [[\"rule:admin_or_projectadmin\"]],\n\nBut I think the specific example we\'re talking about here is pretty\ndumb. Having a \'projectadmin\' role which applies to all projects you\'re\na member doesn\'t seem very useful. We really need users to have\nper-project roles, and that concept would need to be added in keystone.\n\n> In my opinion, there is some merit to the desire to keep policies\n> simple, i.e., true-false decision making; but I fear we could end up\n> with an explosion of policy rules like those the user quotas patch\n> added, which I believe will make the policy files harder to understand\n> as we enhance nova.   I (obviously :) feel that having the \"case\"\n> enhancement strikes a good balance between the two extremes here.\n\nI\'m leaning towards dropping this feature for now until we have a really\ncompelling use case for it. Now that I understand the context a bit\nbetter, I think I\'d be against adding this \"global projectadmin role\"\nidea at all.\n\nThe danger with leaving it in even if there\'s no good use case for it is\nthat folks might find bad/confusing use cases for it :)\n\nCheers,\nMark.\n\n\n\n','<1349881571.3204.66.camel@einstein>',NULL),('<1349885659.3204.74.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 11:14:19',-18000,'2012-10-10 16:14:19',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n policy decisions','On Wed, 2012-10-10 at 16:59 +0100, Mark McLoughlin wrote:\n> So, we\'re talking about this:\n[snip]\n\nYes, that\'s what I\'m referring to?\n\n> Your idea would be to make it more like:\n> \n>  +        if \'user_id\' in params:\n>  +            # Project admins are able to modify per-user quotas.\n>  +            authorize_action(context, \'update\', require=\'projectadmin\')\n>  ...\n>  +        else:\n>  +            # Only admins are able to modify per-project quotas.\n>  +            authorize_action(context, \'update\', require=\'fulladmin\')\n> \n> Which is just as configurable in the policy, but won\'t result in an\n> explosion of rules where we want to make similar distinctions. \n\nWhat I had in mind was a reorganization more like:\n\n    authorization = authorize_action(context, \'update\')\n    if authorization == \'fulladmin\':\n        ?\n    elif authorization == \'projectadmin\':\n        ?\n\nOr something similar.\n\n> It is\n> confusing, though, since you\'d need to document it in the policy with\n> e.g\n\nI have just been thinking about having a means of pre-declaring policies\nwith documentation strings, similar to what we currently do with\nconfiguration settings; you wouldn\'t need to pre-declare, but it\'d be\none way to provide documentation for policies.  (Frankly, I think we\nneed to document *all* of our current policy rules?)\n\n> I\'m leaning towards dropping this feature for now until we have a really\n> compelling use case for it. Now that I understand the context a bit\n> better, I think I\'d be against adding this \"global projectadmin role\"\n> idea at all.\n\nTo be clear, I never envisioned a \"global projectadmin role\" either; I\ndid think roles were already per-project.  I was merely using that as an\nexample of where this could be useful.\n\n> The danger with leaving it in even if there\'s no good use case for it is\n> that folks might find bad/confusing use cases for it :)\n\nHeh.  Indeed, I suppose that is a danger.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<1349884765.19587.215.camel@sorcha>',NULL),('<1349893816.3204.87.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 13:30:16',-18000,'2012-10-10 18:30:16',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n policy decisions','On Wed, 2012-10-10 at 10:11 -0700, heckj wrote:\n> I\'m very opposed to changing policy files from declarative policy to\n> interpreted mechanisms. There in is the road to madness and horrific\n> complexity. I get the desire for wanting to make a seemingly simple\n> modification to all \"if/else\", but it\'s a slippery slope from there\n> into a full-bore interpreted world and internal variables, and the\n> last thing we need to do is move into the world of inventing a new\n> language (even a DSL) for authorization policies.\n\nApart from the \"case\" mechanism, the interpreted string is dead simple,\nand was largely designed to be easy for admins to configure; it is\npurely an expression syntax (i.e., \"role:admin or project_id:%(project_id)s\"\ninstead of the somewhat more opaque [[\"role:admin\", \"project_id:%(project_id)s\"]]\nlist-of-lists syntax).  It supports the operators \"and\", \"or\", and\n\"not\", and for exactly the reasons you raise, I never intended for it to\nbe much more complicated than that.  I certainly don\'t want to see\nvariables of any sort (can\'t figure out how *that* would work anyway!).\n\nFor reference, the policy file remains a JSON file containing a\ndictionary mapping rule names to policies; this just makes it easier for\nadmins to properly understand and manipulate the rules.  Without this\nunderstanding, who knows what someone could accidentally configure their\npolicies to do?\n\n>  It should be quite possible and not-too-terrible to create a policy\n> that uses simple boolean logic to express this need and keep it\n> entirely declarative, especially with the rules mechanism that\'s\n> already in place.\n\nAs mentioned, this uses the boolean operators and, or, and not; the\nmechanism under discussion right now is the \"case\" syntax I included,\nwhich allows a \"True\" return to be split into finer shades.  (And your\nother arguments have plenty of bearing on that question, which I\'m also\ntaking seriously, FTR.)\n\n> I would, however, very much like to see a suggestion of roles and\n> associated policies that do what Kevin needs as a suggestion for\n> deployment. Kevin - how far down the road are you with roles and\n> definitions for those roles of what you\'re doing? I\'d love to get the\n> layout to document it and include it, along with the current highly\n> simplified global-role and come up with some structures that we can\n> make available for suggesting how to configure openstack roles and\n> policy files that would be useful for a wide variety of use cases.\n\nHonestly, I\'m not certain I understand what you\'re asking here.  I came\nup with the \"case\" mechanism due to a half-remembering of how the user\nquotas patch worked, and I figured that could be addressed effectively\nthat way; I also figured someone might find that functionality useful.\nI didn\'t have specific roles or associated policies in mind.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<A7729AC5-EB86-44B2-A6CF-50220E946261@mac.com>',NULL),('<1349894802.3204.101.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 13:46:42',-18000,'2012-10-10 18:46:42',NULL,'[openstack-dev] [openstack-common]Add support for finer-grained\n policy decisions','On Wed, 2012-10-10 at 11:24 -0700, Vishvananda Ishaya wrote:\n> I agree that this particular feature needs a compelling use case. Its too bad\n> because the feature itself is cool I think it will just lead to bad decisions\n> in the fulture.\n\nMaybe someone else on this list has a compelling use case?  Anyone?\n\n> To totally hijack the thread: I think the best thing we could do with policy\n> is to start looking at it from an operator perspective. The plethora of options\n> in the current policy.json is confusing at best.\n\nNo kidding; that was one of the factors in my mind when I set out to\ncreate the policy interpreter.\n\n> What we really need is some effort given to coming up with policy.json best\n> practices:\n> \n> a) making sure the policies are named in a consistent manner\n\nI think we already largely have this, in nova at least.  That doesn\'t\nmean that it\'s the *best* naming scheme, and my earlier suggestion of\npre-declaring policies with help text would probably also factor in\nhere.\n\n> b) grouping the policies in a way that makes them easy to edit for operators.\n> In other words, I think in most cases there are only a few policies that will be\n> touched, so make configuring those easy\n\nIt had occurred to me to consider whether policies could be specified\nvia a ConfigParser-style file instead of a JSON file, which would allow\nfor easy policy grouping.  With the new policy specification format,\nthat style of configuration becomes quite possible.  However, we\'d have\nto carefully consider how to support older installations using the JSON\nspecification.\n\n> c) standard definitions of which things should be policy controlled and ensuring\n> that all of those are in place.\n> d) documentation on configuring policies\n\nPredeclaration of policy rules with help text could really help here,\nbut we probably also need a doc.  (Anne, does one already exist?)\n\n> b) Centrally controlled policy (i.e. store it in keystone vs a bunch\n> of separate files\n\nThat makes a lot of sense?perhaps a one-time download from keystone on\nserver start?  (It would be really good to try to at least cache results\nof this from Keystone, so we don\'t introduce a bottleneck?)\n\n> c) Delegation of rights (i.e. Giving another user a subset of rights. This is\n> already being discussed in another thread.)\n\nThe obvious way of doing this, to my mind, would be to include some form\nof special token in the request, stating to allow override of some\nspecific rule or set of rules.\n\n> d) Programmable policy (we may get enough with rights delegation or user based\n> quotas, but the basic use case we\'d like to support is that a project owner could limit\n> the actions of other project users. i.e. user a can launch new instances but user b\n> cannot.)\n\nThat sounds good, but I worry that our policy code could become too\ncomplex.  Still, maybe we\'ll figure out a way to do it that won\'t cause\ntoo much complexity :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<DA6E8191-3385-4B6B-99F5-68E3964AAB87@gmail.com>',NULL),('<1349895599.19587.218.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-10 19:59:59',3600,'2012-10-10 18:59:59',NULL,'[OpenStack Foundation] Congrats Lauren Sell,\n OpenStack Foundation hire!','On Tue, 2012-10-09 at 18:45 -0500, Jonathan Bryce wrote:\n> We\'re very excited Lauren will continue working on OpenStack as the\n> OpenStack Foundation Director of Marketing.\n\nExcellent news! And more excellent news from Stefano\'s blog:\n\n  http://maffulli.net/2012/10/05/new-job-same-job-at-openstack-foundation-new-laptop/\n\nthat Stefano, Thierry and Mark have also moved to the Foundation.\n\nCongrats to all involved!\n\nThere\'s definitely a lot of interest in appointments like these. Could\nwe have appointments announced by the Foundation as a matter of course\nin future?\n\nCheers,\nMark.\n\n\n\n','<C9EE0BC3-5DD3-45B2-A410-87A75599501B@openstack.org>',NULL),('<1349904591.19587.254.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 22:29:51',3600,'2012-10-10 21:29:51',NULL,'[openstack-dev] Bare-metal node scheduling','On Wed, 2012-10-10 at 08:14 -0700, Monty Taylor wrote:\n> \n> On 10/08/2012 01:53 PM, David Kang wrote:\n> > \n> >  Mark,\n> > \n> >  I think Mark\'s suggestion has many advantages.\n> > However, I\'m not sure how realistic the assumption is in real-world \"Assume that each compute node has a homogeneous set of bare-metal nodes\".\n> > I want to ask other people\'s opinion on that, especially industry people like Calxeda, NTT, ...\n> > Please let us know your experiences and opinions.\n> \n> Indeed. I, in fact, do not want to have to run my data center in this\n> way. We\'ve been discussing that it is entirely possible with the current\n> codebase to run with only one compute node (looking at openstack bare\n> metal as a management framework beneath an openstack install - so the\n> spin up/tear down is pretty infrequent)\n> \n> Requiring a compute node to have a homogenous set of servers would make\n> this much less appealing. So for whatever my vote counts here, I vote\n> very very very strongly against requiring that assumption.\n\nIt\'s a suggestion for how we can make progress merging the rest of the\nbare-metal support work quickly without overly complicating the\nscheduler/compute code for the non-bare-metal case.\n\nThe idea is be that compute would only be able to support a single slot\ntype now (i.e. manages heterogeneous nodes) but we\'d soon add support\nfor multiple slot types.\n\n> >  If we have to change the code according to the review, this would be another fundamental design changes.\n> > Let me tell you how our design has evolved.\n> > \n> > Our initial design did not change upstream scheduler part except adding BaremetalHostManager.\n> > BaremetalHostManager (instead of HostManager) takes care of special communication with bare-metal nova-compute.\n> > In this case, bare-metal nova-compute reports the largest available resources to BaremetalHostManager.\n> > But Vish and other people did not like it and suggested the multiple entries of capabilities for bare-metal nova-compute.\n> > (We\'ve exchanged many emails in this mailing list to conclude the 2nd design.)\n> > \n> > 2nd design: This is the design that is being reviewed.\n> > Now bare-metal nova-compute reports multiple entries of capabilities of bare-metal machines.\n> > We knew that this design change causes (non-trivial) changes in upstream scheduler.\n> > After the 2nd design is summarized in that email chain at August 28, our team has worked based on that.\n> > But, now the multiple entries of capabilities seem to disrupt the main nova too much. Sigh~\n> \n> It seems to me that we\'ve got work done in response to vish and other\'s\n> comments and design input from earlier. It seems a little bit\n> problematic to come back out of the context of the earlier design\n> discussion and suggest a wholly-new design idea again at this point.\n\nIt\'s certainly not ideal, but sometimes an idea doesn\'t seem like such a\ngreat idea when you see the code.\n\nIt may be that the patch implementing the idea could be improved so that\nit starts looking like an OK idea again, but I wanted to explore another\nidea which would potentially be much less invasive before proceeding. If\nwe figure out the idea won\'t work, we can go back to the current\nproposed code again.\n\nI understand everyone\'s a little jumpy because this folks have been keen\nto see this merged for a while now, but that doesn\'t mean we should at\nsome point give up and merge whatever we have at that point.\n\nCheers,\nMark.\n\n\n\n','<507590E8.7030604@inaugust.com>',NULL),('<1349907137.19587.264.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 23:12:17',3600,'2012-10-10 22:12:17',NULL,'[openstack-dev] Bare-metal node scheduling','On Wed, 2012-10-10 at 14:47 -0700, Monty Taylor wrote:\n> > The idea is be that compute would only be able to support a single slot\n> > type now (i.e. manages heterogeneous nodes) but we\'d soon add support\n> > for multiple slot types.\n> \n> I hear that. In my world though, the functionality would be taking a\n> step back while waiting for a feature that doesn\'t exist that once it\n> does would be finally back to parity with the current feature set. \n\nI think I\'m missing some context here. You\'re using the new baremetal\ndriver now?\n\nHow many bare-metal node types are there in your deployment? i.e. if we\ndid the homogeneous thing, how many compute services would you need to\nrun?\n\nCheers,\nMark.\n\n\n\n','<5075ED0F.6020303@inaugust.com>',NULL),('<1349952787.19587.322.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 11:53:07',3600,'2012-10-11 10:53:07',NULL,'[OpenStack Foundation] Use of the word \"certified\" and\n protecting brand OpenStack','Hi Tristan,\n\nThanks for raising this openly. That\'s very healthy IMHO\n\nOn Thu, 2012-10-11 at 08:42 +1100, Tristan Goode wrote:\n> Dear Foundation Members,\n>  \n> I believe a key role of the Foundation is to protect the brand that is\n> OpenStack.\n>  \n> After raising the issue with Rackspace and Jonathan Bryce several days\n> ago, yesterday I sought my fellow Foundation Board members opinion on\n> Rackspace\'s use of the word \"certified\" in media releases 6 days ago,\n...\n\nIt took me a little bit of digging to find out what exactly you were\nreferring to, so for others reference it was the RAX \"Launch Your Career\nInto The Clouds\" email sent out to summit attendees which said:\n\n  \"learn how you can accelerate your career by becoming one of the first\n   Certified OpenStack technicians. OpenStack public training classes\n   are now posted at www.rackspacetraining.com.\"\n\nThe \"Certified OpenStack Technician\" brand should definitely be\nsomething that the Foundation should seek to control. IMHO, it would\nonly be appropriate for training course run by the Foundation itself or\na Foundation contractor.\n\nHowever, the response you got:\n\n> From: Jim Curry [mailto:jim.curry at rackspace.com] \n.. \n> Tristan,\n>  \n> The email was an unfortunate mistake by our marketing team.  It does\n> not represent the official branding or positioning of our offer.  We\n> aren\'t perfect, and for any confusion that created I apologize.\n>  \n> To be clear, our offer is a \"Rackspace Certified\" training program for\n> OpenStack, not \"OpenStack certified\" for OpenStack.  We are putting\n> our brand behind the training, not representing the brand of the\n> project itself. \n\nseems pretty \"fair dinkum\" to me :)\n\nThe term \"Rackspace Certified Technician for OpenStack\" makes it quite\nclear that it\'s not a certification endorsed by the Foundation. The\nFoundation should encourage such programs as part of growing the\necosystem.\n\nWhile a training course offered directly by the Foundation sounds like a\ngood idea, I struggle to see how it would be useful without focusing on\na specific OpenStack distribution and, if it did that, it would mean the\nFoundation being seen as endorsing a specific distribution.\n\nCheers,\nMark.\n\n\n\n','<02db3751-69ec-4883-a766-09ba4d740bce@aptira.com>',NULL),('<1349953690.19587.332.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 12:08:10',3600,'2012-10-11 11:08:10',NULL,'[OpenStack Foundation] Board Meeting - October 15th','On Thu, 2012-10-11 at 08:41 +0200, Vincent Untz wrote:\n>  + possible changes to election rules; the election statistics published\n>    last week triggered some discussion about what some people see as a\n>    flaw in how things are currently set up:\n>    http://lists.openstack.org/pipermail/foundation/2012-October/001114.html\n> \n>    There were several ideas raised before the elections in August to at\n>    least mitigate this flaw, but we couldn\'t implement them because it\n>    was too late. I really want to get this improved for the next\n>    elections, and I think it\'s safe to assume I\'m not the only one :-) \n\nGood point. To make the discussion easier for the board, here\'s an\nattempt to summarize the positions taken on the thread:\n\n  1) The \"2 seats per company\" limit did its job and limited the \n     damage.\n\n  2) We should use a different voting method like Condorcet because it \n     allows voters to express which candidates they like least which \n     partially offsets the effect of a large block of voters.\n\n  3) Increase the barrier to entry for Foundation members by e.g. \n     requiring them to make a public statement of their interest in \n     Openstack or having a membership committee which openly vets\n     applications\n\n  4) Reduce the number of directors allowed to be affiliated with a\n     single company from two to one\n\n  5) Introduce a membership subscription charge\n\nMy own preference is (3) and (2) sounds plausible except that I haven\'t\ntaken the time to fully understand how Condorcet.\n\nCheers,\nMark.\n\n\n\n','<20121011064113.GE16368@vuntz.net>',NULL),('<1349958943.19587.345.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 13:35:43',3600,'2012-10-11 12:35:43',NULL,'[OpenStack Foundation] Board Meeting - October 15th','On Thu, 2012-10-11 at 07:24 -0500, Christopher B Ferris wrote:\n> Personally, I don\'t think that either (2) or (3) effectively address\n> the concerns. I\'d be opposed to a membership committee making such\n> decisions. \n\nTo be clear, the \"membership committee\" idea is just one way of raising\nthe barrier to membership. I\'m raising it as an idea because I\'ve seen\nit work in GNOME. It can be done very inclusively, openly and\ntransparently. I probably shouldn\'t have included it in the summary as\nit just confuses the issue. My bad.\n\nI think there\'s actually more agreement behind around the idea of\nmembers making a public statement of their interest in OpenStack. There\nwould be no vetting of this statement, but the fact that it is published\nwould give pause to any potential members who have no real involvement\nin OpenStack.\n\n> I\'d like to see OpenStack Foundation adopt a policy it should have\n> adopted at the outset. Limit Board representation to a single\n> individual from an affiliated entity, period.\n\nThat\'s certainly one view. My view is that the foundation board would\nbenefit from the input of affiliated directors who are explicitly\nrepresenting the individual members rather than their employer.\n\nIn an perfect world, I\'d like to see no limit to affiliated individual\ndirectors and trust the individual members to choose directors they can\ntrust to act on their behalf. The limit is there to prevent the\nappearance of a company dominating the board, not because affiliated\ndirectors can\'t be trusted to represent the individual members rather\nthan their employer.\n\nCheers,\nMark.\n\n\n\n','<OF647DA2B7.C524D648-ON86257A94.004422B5-86257A94.004422BF@us.ibm.com>',NULL),('<1349959269.19587.348.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 13:41:09',3600,'2012-10-11 12:41:09',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','Hi,\n\nOn Wed, 2012-10-10 at 11:31 +0000, ??? wrote:\n\n> Unfortunately, we could not attend the Design Summit. We also need some time \n> before opening our source codes, mostly for our internal process. We will try\n> to shorten this time.\n\nCan you estimate how long this will take?\n\nI think it\'s pretty clear from the thread that the introduction of\nSynaps could change the direction folks are taking in this area, but\nwithout being able to see the code it\'s quite a frustrating disruption\nfor those involved.\n\nCheers,\nMark.\n\n\n\n','<5944471.422151349868713283.JavaMail.weblogic@epv6ml08>',NULL),('<1349961091.19587.357.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 14:11:31',3600,'2012-10-11 13:11:31',NULL,'[OpenStack Foundation] Board Meeting - October 15th','On Thu, 2012-10-11 at 07:57 -0500, Christopher B Ferris wrote:\n> Mark,\n> \n> I\'d be interested in more background on how GNOME handles membership.\n\nTonnes of info here:\n\n  https://live.gnome.org/MembershipCommittee\n\nAll parts of the process are open and archived here:\n\n  https://mail.gnome.org/archives/membership-committee/\n\n> Is there objective criteria that are applied?\n\nhttps://live.gnome.org/MembershipCommittee/MembershipGuidelines\n\n  \"Examples of non-trivial contributions include hacking, bugfixing,\n   extensive testing, design, documentation, translation,\n   administration or maintenance of project-wide resources, giving\n   GNOME talks at conferences and community coordination such as\n   bugzilla or release management.  Any activity, such as advocacy or\n   submitting bug reports, must substantially exceed the level of\n   contribution expected of an ordinary user or fan of the project to\n   qualify an individual for membership in the Foundation.\"\n\nI like this criteria, but obviously a membership committee could have an\neven more inclusive criteria.\n\n> If a request is declined, is there an appeals process?\n\nThe committee will reconsider a rejection if you give more info. I\'m not\nsure if you can escalate beyond that.\n\n> Must the objective criteria be cited in the declined request?\n\nhttps://live.gnome.org/MembershipCommittee/FormLetters#Application_denied\n> \n> As for a statement being sufficient, I can appreciate that some\n> believe it sufficient. I am merely stating that I don\'t believe that\n> it is. Unless they are vetted, company X could send out an email with\n> suggested statements and the barrier is thus circumvented. \n\nImagine if any of the large voting blocks in the recent election had\ntaken such a strategy. It would have been obvious to everyone (the\nstatements would be public) and there would be uproar. Social pressure.\n\n> Bottom line, we do not live in a perfect world. The individual members\n> can be equally represented by individuals who are unaffiliated with\n> existing Board members, and there is ample opportunity on the various\n> mailing lists to have one\'s voice heard; just as we are doing here.\n\nWe have elections because we think that some candidates will represent\nthe individual members better than other candidates. IMHO there are a\nnumber of affiliated candidates who would I would prefer to see\nrepresenting us over some of the unaffiliated candidates.\n\nCheers,\nMark.\n\n\n\n','<OF15B400C7.B13D13D8-ON86257A94.00472498-86257A94.0047249C@us.ibm.com>',NULL),('<1349968578.3204.105.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 10:16:18',-18000,'2012-10-11 15:16:18',NULL,'[openstack-dev] Unit tests error not reflecting in Jenkins\n report (for Nova)','On Thu, 2012-10-11 at 14:05 +0000, Gurjar, Unmesh wrote:\n> I happened to check the unit test results for Nova for a few reviews\n> today, and it seems that there is a failure in running unit tests.\n> However, it is not appearing in the Jenkins summary on the review.\n\nHrm.  It appears that the test runner found no tests at all, looking at\nthe console log; since it found no tests, it ran none, and none failed,\ncausing it to claim success.\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<C2F1FD20FE83284AA0E9E36639ECDAEBED1A4A@MAIL703.KDS.KEANE.COM>',NULL),('<1349995537.24046260@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-11 18:45:37',-14400,'2012-10-11 22:45:37',NULL,'[OpenStack Foundation] [Foundation Board] Use of the word\n	\"certified\" and protecting brand OpenStack','Thanks Alan.\n\nI was also thinking it would be a good time to point out the various places where you can learn more about the current policies and marketing programs.\n\nThis page has many helpful links:  http://www.openstack.org/brand\n\nThe brand page outlines 5 specific marketing programs for commercial products, which are sometimes referred to as the \"restricted use logo\" programs, also pasted below.  Although the programs have logos associated with them, they also govern the ways in which companies can use the wordmark (\"OpenStack\") as they market their products, including the rules around the naming of their product or service.  Please note that these are summaries, not legal documents, so they are meant to convey the meaning of each program in laymans terms, but are not a substitute for a full review of the relevant legal agreements.  This is one of the challenges of discussing a complex legal topic over a mailing list, but I think it\'s still useful for us non-lawyers to start with the summaries:\n\nFrom the website:\n--\nFor Commercial Products:\n\n\"Powered By OpenStack\"\nIf you have a service offering that uses formally released OpenStack Compute (Nova) code in your application or product, you may be eligible for the \"Powered by OpenStack\" marketing program, which includes a specific commercial-use logo and wordmark treatment for your product name. See the logo guidelines at the the above link, and contact logo at openstack.org for more details.  A signed contract is required.\n\n\"Storage Powered By OpenStack\"\nIf you have a service offering that uses formally released OpenStack Object Storage (Swift) code in your application or product, you may be eligible for the \"Storage Powered by OpenStack\" marketing program, which includes a specific commercial-use logo and wordmark treatment for your product name. See the logo guidelines at the above link, and contact logo at openstack.org for more details.  A signed contract is required.\n\n\"Built For OpenStack\"\nIf you are creating hardware, applications or services that integrate with or support OpenStack technology, but do not actually incorporate OpenStack technology, you may be eligible for the \"Built for OpenStack\" marketing program, which includes a specific commercial-use logo and wordmark treatment for your product name. See the logo guidelines at the above link, and contact logo at openstack.org for more details.  A signed contract is required.\n\n\"OpenStack Distribution\"\nThis program is designed for Software Distributions based on OpenStack, which include, at a minimum, the Compute (Nova) and Object Storage (Swift) software from one of the two most recent versions at time of commercial launch, expose the OpenStack API, and are distributed as installable software (e.g. USB, download, etc).  Companies who are part of the program may use the OpenStack Distribution logo and may also use the OpenStack wordmark in their product name, such as \"ACME OpenStack\".  To determine if you qualify for the program, contact logo at openstack.org.  A signed contract is required.\n\n\"OpenStack Cloud\"\nThis program is for public Infrastructure-as-a-Service (IaaS) clouds which utilize the OpenStack software (including, at a minimum, the Compute (Nova) and Object Storage (Swift) software), expose the OpenStack API, are running one of the two most recent versions.  Companies who are part of the program may use the OpenStack Cloud logo and may also use the OpenStack wordmark in their service name, such as \"ACME OpenStack Cloud\".  To determine if you qualify for the program, contact logo at openstack.org.  A signed contract is required.\n\n--\n\nThe \"Built for OpenStack\" program is in some ways the broadest, as it is for products and services that work with OpenStack, as opposed to products or services that actually run or distribute the OpenStack code.  For example, professional services, including training,  fall under the \"Built for OpenStack\" marketing program.  Using \"ACME\" as an example company name, \"ACME Training for OpenStack\" is something you could see in the marketplace under this program.\n\nThe last two, \"OpenStack Distribution\" and \"OpenStack Cloud\" are relatively new.  They are the first programs that allow a company to use \"OpenStack\" in the product name without a modifer such as \"Powered by\" or \"for\", and thus have the most stringent requirements, including the requirement to include Nova & Swift from one of the two most recent releases, and to expose the OpenStack APIs.\n\nNote that for all programs, a signed contract is required, which means that this \"ACME\" company would need to contact the Foundation (logo at openstack.org) and discuss their programs before such an agreement were executed.\n\nSo, that\'s the status right now. It sounds like several of you have ideas about how to evolve these programs, or have ideas for new programs, which is great, but obviously we need to carefully consider the impact of any changes to the market, users and companies who are currently using the restricted logos. Whether or not the Foundation will have a training/certification program, and how that will take shape, is a separate but important topic.\n\n--\nPersonal Opinion:\n\nI think we could better address the growing ecosystem of companies who are offering professional services for OpenStack, including Training and Certification.  As always, we need to balance the duty to protect the brand with the opportunity to leverage the combined reach of such a thriving ecosystem.  But I think it\'s clear that the current \"Built for OpenStack\" is not a perfect fit for service businesses. The name itself doesn\'t exactly say \"professional services.\"\n\nMany ideas have already been shared on the mailing list specific to Certification, and I think it will be a good topic for Monday\'s board meeting, in the context of Training and perhaps professional services as a whole.\n\nTrademark issues are not simple, and thus won\'t be solved overnight, but in the grand scheme of things I am very happy that there is so much demand for OpenStack knowledge, and that we have the strongest open cloud ecoystem on the planet looking to meet it.  As a newly formed Foundation with the responsibiltiy to protect, empower, and promote OpenStack, I\'m confident that if we make this a priority we can ensure any new program ultimately strikes the right balance. \n\nMark Collier\n\n\n\nOn Thursday, October 11, 2012 6:15pm, \"Alan Clark\" <aclark at suse.com> said:\n\n> \n> \n>>>> On 10/11/2012 at 04:03 PM, Tristan Goode <tristan at aptira.com> wrote:\n>> Jim,\n>>\n>>> > > From: Jim Curry [mailto:jim.curry at rackspace.com]\n>>> > ..\n>>> > > Tristan,\n>>> > >\n>>> > > The email was an unfortunate mistake by our marketing team.  It does\n>>> > > not represent the official branding or positioning of our offer.  We\n>>> > > aren\'t perfect, and for any confusion that created I apologize.\n>>> > >\n>>\n>> The limited viewing audience of the Foundation mailing list and the Board\n>> mailing list doesn\'t let the actual recipients of the mail out know that this\n>> was a mistake. Could I please request that all the original recipients of the\n>> email be advised.\n>>\n>> Cheers\n>> Tristan\n> \n> \n> While there are many details that have come up during this current email thread, I\n> feel that it is important to remind everyone that the OpenStack Foundation has a\n> trademark policy[1]  and procedure[1].  The policy sets out the rules for proper\n> use of the OpenStack marks in word and logo form. The procedure is in place to\n> govern and enforce the rules for those marks. The objective of the policy is to\n> ensure that the OpenStack marks remain reliable indicators of source and quality\n> and that they are protected from inappropriate and unauthorized use.   The policy\n> goes through great detail to demonstrate what is and isn\'t authorized and/or\n> proper use of the marks.\n> \n> The policy also spells out what a person should do if a person has questions or\n> wishes to report misuse of the OpenStack marks. \"If you wish to obtain our\n> permission for any uses above or for any other use which is not specifically\n> addressed in this Trademark Policy or you became aware of unauthorized use of the\n> OpenStack Marks, please contact us by email at logo at openstack.org...\"[1]\n> \n> Please use this as the mechanism to report uses of the marks which you feel are in\n> question. Through this mechanism the proper people will be informed up front and\n> will then be able to judiciously investigate the questioned use and subsequent\n> actions.  Using such mechanisms ensure the proper enforcement of our marks while\n> allowing the community to productively focus on and/or evolve the standing\n> trademark policy and procedures while avoiding community strife and ill will\n> through an onslaught of opinions towards any one person(s) or companies.\n> \n> regards,\n> \n> AlanClark\n> \n> [1] http://www.openstack.org/brand/openstack-trademark-policy/\n> \n> \n> \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<5076F0B9020000CC0002F016@novprvoes0310.provo.novell.com>',NULL),('<1350028045.19587.396.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-12 08:47:25',3600,'2012-10-12 07:47:25',NULL,'[OpenStack Foundation] [Foundation Board] Use of the word\n \"certified\" and protecting brand OpenStack','On Thu, 2012-10-11 at 16:15 -0600, Alan Clark wrote:\n> Using such mechanisms ensure the proper enforcement of our marks while\n> allowing the community to productively focus on and/or evolve the\n> standing trademark policy and procedures while avoiding community\n> strife and ill will through an onslaught of opinions towards any one\n> person(s) or companies.\n\nThat there is a mechanism in place does not mean that some we should\ndiscourage open debate amongst Foundation members about how we like to\nsee our brand used and promoted.\n\nI don\'t see this thread as \"community strife and ill will\" or \"an\nonslaught of opinions\". I think most of the opinions offered were\nactually totally reasonable and measured.\n\nSure, the initial tone Tristan used may have been a little over the top\nand there wasn\'t enough assumption of good intent, but let\'s put that\ndown to folks being passionate about OpenStack.\n\nPut it another way - individual directors are elected to serve the\nindividual members. This mailing list is a great way (and maybe the only\nway) for individual directors to get input from the members they\nrepresent.\n\nCheers,\nMark.\n\n\n\n','<5076F0B9020000CC0002F016@novprvoes0310.provo.novell.com>',NULL),('<1350029838.30113.YahooMailNeo@web15703.mail.cnb.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-10-12 16:17:18',28800,'2012-10-12 08:17:18',NULL,'[Openstack-operators] 回复：  Issue creating networks with high availability networking option','Hi,\n?\nThis is normal. It is recommended to use floating IP(public interface) to communicate inter-network.\nYou can see that from route table.\n\nRegards,\nwillfu\n\n\n________________________________\n???? Miguel Angel Diaz Corchero <miguelangel.diaz at ciemat.es>\n???? openstack-operators at lists.openstack.org \n????? 2012?10?11?, ???, ?? 10:32\n??: [Openstack-operators] Issue creating networks with high availability networking option\n\n\nHi\n\nI have configured OpenStack in VLAN mode with HA networking option and I have worked with this for a month. The infrastructure is composed by 1 controller-compute and N compute nodes. \n\nToday when I created a new network I noticed that vlanXXX and brXXX are not created in the controller node until a VM is running on this. Is this normal? \n\nif this is normal, how I can access from controller to the VLAN without waiting for any VM in the controller?\n\nRegards\nMiguel.\n\n-- \nMiguel Angel D?az Corchero\nResearcher / System Administrator at CETA-Ciemat\nc/ Sola n? 1; 10200 TRUJILLO, SPAIN\nTel: +34 927 65 93 17 Fax: +34 927 32 32 37 ---------------------------- Confidencialidad: Este mensaje y sus ficheros adjuntos se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente respondiendo al mensaje y proceda a su destrucci?n. Disclaimer: This message and its attached files is intended exclusively for its recipients and may contain confidential information. If you received this e-mail in error you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited and may be unlawful. In this case, please notify us by a reply and delete this email and its contents immediately.\n ---------------------------- \n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121012/b11b8356/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 26213 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121012/b11b8356/attachment-0001.png>\n\n','<2547_1349965968_5076D890_2547_11408_1_5076D88F.5020606@ciemat.es>',NULL),('<1350030506.19587.404.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2012-10-12 09:28:26',3600,'2012-10-12 08:28:26',NULL,'[Openstack-announce] [ANNOUNCE] OpenStack Nova,\n	Keystone and Horizon 2012.1.3 released','Hey,\n\nIn the time since the Essex release, we have been busy selectively\nback-porting bugfixes to the stable/essex branch according to our \"safe\nsource of high-impact fixes\" criteria documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nWe\'re happy to announce the 2012.1.3 release, the latest in the series\nof releases to make available the bugfixes from stable/essex.\n\nThese releases are bugfix updates to Essex and are intended to be\nrelatively risk free with no intentional regressions or API changes.\n\nThe list of bugs fixed can be seen here:\n\n  https://launchpad.net/nova/+milestone/2012.1.3\n  https://launchpad.net/keystone/+milestone/2012.1.3\n  https://launchpad.net/horizon/+milestone/2012.1.3\n\nPlease read (and add to!) the release notes at:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.1.3\n\nThis release is the last planned release of Essex Nova, Keystone and\nHorizon. There may be a further release of Essex Glance to resolve a\nserious issue with Diablo to Essex migrations.\n\nEnjoy!\n\nMark.\n\n\n\n',NULL,NULL),('<1350042834.19587.409.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-12 12:53:54',3600,'2012-10-12 11:53:54',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','On Fri, 2012-10-12 at 11:23 +0000, Joonwon Lee wrote:\n> Hi, Mark.\n> I expect that we need a few weeks for opening Synaps. (maybe early Nov.)\n> However, as I completely agree with Mark, I tried my best to find a way. \n\nThank you for your efforts\n\n> We\'re going to send directly the source codes of Synaps to you tomorrow:\n>     Mark McLoughlin, Eoghan Glynn, Steve Hardy (Heat developers, Red Hat)\n> I hope it will help you deciding the direction next week at the Summit.\n> You may see them and ask any questions, but don\'t make them public yet.\n> (Are there other people who want to see our codes first and work with us?)\n\nActually, I don\'t think this is such a good idea. If you shared the code\noutside Samsung, the license you\'re sharing it under would not be clear\nat this point and if the code doesn\'t eventually licensed under the\nApache License it potentially could cause legal trouble.\n\nThanks,\nMark.\n\n\n\n','<18465120.31911350040995117.JavaMail.weblogic@epml28>',NULL),('<1350237858.701851.1381778341475.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-10-14 12:19:01',-25200,'2013-10-14 19:19:01',NULL,'[OpenStack-Infra] Third Party Testing: ServiceAccount for\n posting reviews','Yes, I just saw that message :) For now jenkins is running in a private env but logs will be published to public server and link will be posted in the review. \nAlso, I just made a changes to gerrit trigger plugin to send messages only for build success.\n\n----- Original Message -----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nTo: \"Jeremy Stanley\" <fungi at yuggoth.org>\nCc: \"Sreeram Yerrapragada\" <syerrapragada at vmware.com>, openstack-infra at lists.openstack.org\nSent: Monday, October 14, 2013 12:07:00 PM\nSubject: Re: [OpenStack-Infra] Third Party Testing: ServiceAccount for posting reviews\n\nOn 10/12/2013 03:37 PM, Jeremy Stanley wrote:\n> On 2013-10-11 13:17:54 -0700 (-0700), Sreeram Yerrapragada wrote: \n> [...]\n>> Account Name: VMware Mine Sweeper Pub key: <Attached>\n> [...]\n> \n> I\'ve created the requested account. Its SSH username is \n> vmwareminesweeper while the full name and public key are as you \n> requested in your last E-mail. Try it out and let me know if you \n> encounter any issues.\n\nI just saw a post from this account on here:\n\n?? https://review.openstack.org/#/c/51404/\n\nIt\'s great to see the progress on this! ?One question, though. ?The\ncomment includes a private address. ?Is this going to get updated so\nthat all of the status and results are public?\n\n?? ?Build Started http://10.132.98.47/job/VCDriverTempestTests/154/\n\nThanks,\n\n-- \nRussell Bryant\n\n\n','<525C40D4.7050402@redhat.com>',NULL),('<1350395443.28.1380089111963.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-25 06:05:11',0,'2013-09-25 06:05:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #30','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/30/>\n\n------------------------------------------\n[...truncated 7411 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 1625, in __call__\n    else sys.argv[1:])\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 2124, in _parse_cli_opts\n    opt._add_to_cli(self._oparser, group)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 1018, in _add_to_cli\n    self.handler(subparsers)\n  File \"./bin/glance-control\", line 274, in add_command_parsers\n    parser = subparsers.add_parser(server, parents=[cmd_parser])\n  File \"/usr/lib/python2.7/argparse.py\", line 1064, in add_parser\n    parser = self._parser_class(**kwargs)\nTypeError: __init__() got an unexpected keyword argument \'parents\'\n\n\nCONTEXT: ==Core config==\n[DEFAULT]\nverbose = True\ndebug = True\nbind_host = 127.0.0.1\nbind_port = 45598\nlog_file = /tmp/tmp.1T9HUDHiMd/tmpHwC1qr/registry.log\ndb_auto_create = False\nsql_connection = sqlite://///tmp/tmp.1T9HUDHiMd/tmpHwC1qr/tests.sqlite\nsql_idle_timeout = 3600\napi_limit_max = 1000\nlimit_param_default = 25\nowner_is_tenant = True\nworkers = 0\n[paste_deploy]\nflavor = \n\n==Paste config==\n[pipeline:glance-registry]\npipeline = unauthenticated-context registryapp\n\n[pipeline:glance-registry-fakeauth]\npipeline = fakeauth context registryapp\n\n[app:registryapp]\npaste.app_factory = glance.registry.api.v1:API.factory\n\n[filter:context]\npaste.filter_factory = glance.api.middleware.context:ContextMiddleware.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory =\n glance.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:fakeauth]\npaste.filter_factory = glance.tests.utils:FakeAuthMiddleware.factory\n\n\n======================================================================\nERROR: glance.tests.functional.test_sqlite.TestSqlite.test_big_int_mapping\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 105, in _runner\n    func(*args, **kw)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_sqlite.py\",> line 33, in test_big_int_mapping\n    self.start_servers(**self.__dict__.copy())\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 645, in start_servers\n    **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 612, in start_with_retry\n    **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 143, in start\n    context=overridden)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 198, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command ./bin/glance-control --pid-file=/tmp/tmp.1T9HUDHiMd/tmpzov_st/registry.pid --capture-output registry start /tmp/tmp.1T9HUDHiMd/tmpzov_st/etc/registry.conf did not succeed. Returned an exit code of 1.\n\nSTDOUT: \n\nSTDERR: Traceback (most recent call last):\n  File \"./bin/glance-control\", line 312, in <module>\n    config.parse_args(usage=USAGE)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/common/config.py\",> line 98, in parse_args\n    default_config_files=default_config_files)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 1625, in __call__\n    else sys.argv[1:])\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 2124, in _parse_cli_opts\n    opt._add_to_cli(self._oparser, group)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/oslo/config/cfg.py\",> line 1018, in _add_to_cli\n    self.handler(subparsers)\n  File \"./bin/glance-control\", line 274, in add_command_parsers\n    parser = subparsers.add_parser(server, parents=[cmd_parser])\n  File \"/usr/lib/python2.7/argparse.py\", line 1064, in add_parser\n    parser = self._parser_class(**kwargs)\nTypeError: __init__() got an unexpected keyword argument \'parents\'\n\n\nCONTEXT: ==Core config==\n[DEFAULT]\nverbose = True\ndebug = True\nbind_host = 127.0.0.1\nbind_port = 48216\nlog_file = /tmp/tmp.1T9HUDHiMd/tmpzov_st/registry.log\ndb_auto_create = False\nsql_connection = sqlite://///tmp/tmp.1T9HUDHiMd/tmpzov_st/tests.sqlite\nsql_idle_timeout = 3600\napi_limit_max = 1000\nlimit_param_default = 25\nowner_is_tenant = True\nworkers = 0\n[paste_deploy]\nflavor = \n\n==Paste config==\n[pipeline:glance-registry]\npipeline = unauthenticated-context registryapp\n\n[pipeline:glance-registry-fakeauth]\npipeline = fakeauth context registryapp\n\n[app:registryapp]\npaste.app_factory = glance.registry.api.v1:API.factory\n\n[filter:context]\npaste.filter_factory = glance.api.middleware.context:ContextMiddleware.factory\n\n[filter:unauthenticated-context]\npaste.filter_factory =\n glance.api.middleware.context:UnauthenticatedContextMiddleware.factory\n\n[filter:fakeauth]\npaste.filter_factory = glance.tests.utils:FakeAuthMiddleware.factory\n\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_api.TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1246, in test_unsupported_default_store\n    **self.__dict__.copy())\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/__init__.py\",> line 585, in start_server\n    self.assertTrue(re.search(\"Starting glance-[a-z]+ with\", out))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: None is not true\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 32.06 secs:\n    11.18    TestGlanceControl.test_reload\n    11.18    TestGlanceControl.test_respawn\n    4.70    TestMigrations.test_postgresql_opportunistically\n    2.58    TestMigrations.test_mysql_opportunistically\n    2.41    TestMigrations.test_walk_versions\n----------------------------------------------------------------------\nRan 1101 tests in 152.154s\n\nFAILED (SKIP=38, errors=81, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.6\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.30\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.0\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=107\n+ \'[\' 107 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.1T9HUDHiMd\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/30/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise37/30\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1350437861.73785.YahooMailClassic@web112910.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-16 18:37:41',-25200,'2012-10-17 01:37:41',NULL,'[openstack-dev] Swift App','Dear John Dickinson\n?\n\nI would like to ask a favor from you,i followed the instruction you gave me on how to apload quickly file on swift but i couldnt run and test you code .could you guide me step by step on how i should do it?? i am using windows 7 OS and PyDev\n?\n\nThanks a lot!!\n\n--- On Mon, 10/8/12, John Dickinson <me at not.mn> wrote:\n\n\nFrom: John Dickinson <me at not.mn>\nSubject: Re: [openstack-dev] Swift App\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nDate: Monday, October 8, 2012, 6:20 PM\n\n\n\"Advice on swift application development\" could cover a lot of ground and fill a lot of pages of text. However, here are some getting started places.\n\nFirst, check out the swift API docs at http://docs.openstack.org. Swift\'s API is HTTP, so any client or library that speaks HTTP can talk to swift. I\'ve published some examples of using Python\'s httplib to talk to swift at http://programmerthoughts.com/programming/quickly-uploading-to-cloud-files-part-2/.\n\nIf you are looking for language bindings, check out either https://github.com/openstack/python-swiftclient (the official Python language bindings) or https://github.com/rackspace/python-cloudfiles). There are bindings for other languages as well.\n\nAs a general guide for building a client app, first, know your data. Try to use concurrency when talking to swift (instead of sending each request serially). Also, for large data sets, shard your data across many containers. Try to target 1-10 million objects in each container (although this is affected by your hardware deployment choices). Swift is designed for high throughput using many concurrent connections, so take advantage of that.\n\n--John\n\n\n\n\n\nOn Oct 8, 2012, at 9:03 AM, Rugwiro Ulysse <rugwiro05 at yahoo.com> wrote:\n\n> Hello everyone !!\n>? \n> I would like your advice on swift application development.\n>? \n> \" How a client can talk directly to a swift cluster without a web service invorved?\"\n>? \n> This question have been in my mind for long and i dont seem to have figured out how to make such application in python. any ideas??\n>? \n> Regards!!\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-----Inline Attachment Follows-----\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121016/b883936c/attachment.html>\n\n','<B0585257-3431-4D57-9EC9-FB6754254722@not.mn>',NULL),('<1350541560.23048.28.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-17 23:26:00',-25200,'2012-10-18 06:26:00',NULL,'[OpenStack Foundation] Board Meeting - October 15th','On Wed, 2012-10-17 at 18:06 -0700, Jonathan Bryce wrote:\n> Hi everyone,\n> \n> Since it takes us a few weeks to turn around the official minutes, I\n> wanted to share a short summary from the Board meeting Monday.\n\nThanks! These notes are probably even more useful than the formal\nminutes themselves, even aside from the turnaround time :)\n\nCheers,\nMark.\n\n\n\n','<E6F67F95-78B6-4A97-9BA8-E67D9576A806@openstack.org>',NULL),('<1350718359.19855987.1393476040722.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-26 23:40:40',-18000,'2014-02-27 04:40:40',NULL,'[Openstack-docs] roundup of topics from (missed) meeting','----- Original Message -----\n> I missed the meeting this morning, being out of town made me forget! Plus I\n> have been having trouble getting on IRC.\n> \n> Enough excuses, please accept my apologies for not running the Doc Team\n> meeting this morning. I don\'t have much to report other than what I sent\n> out Monday in What\'s Up Doc? Here are a few other topics.\n> \n> I do want to circle back on the install guide changes, because someone\n> asked me if the intent was to get rid of all conditional markup. Not at all\n> -- just want to ship sample neutron.conf files rather than conditionalizing\n> all the openstack-config commands. What do you all think?\n\nI think we can and should ship sample config files *as appendices* regardless, ideally they should be automatically pulled from the project repositories themselves where they are available.\n\nThanks,\n\nSteve\n\n\n','<CAD0KtVFHxqz9LLrzUBQwp1H5seKXKQ2SyVtCHdLv2n--P=c64g@mail.gmail.com>',NULL),('<1350DA40-4CF0-490D-B507-B215843C2C85@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-29 12:34:36',-25200,'2014-10-29 19:34:36',NULL,'[Openstack-operators] Ephemeral instances in RBD issue','So, I figured out why this was happening.\nThe gist of it is, the direct_snapshot doesn\'t start the domain back up. I contacted inktank and they\'re adding what I found to their fork.\n\nThe long story:\nin nova/virt/libvirt/driver.py, the snapshot method does everything. the code doesn\'t support live snapshot for lvm or rbd, so we have to do a cold snapshot.\nWe go into \'managedSave\' ( the instance is suspended to quiesce I/O), the snapshot is taken, then much later, we start a new domain based on the save.\nThe last commit to jdurin\'s fork splits snapshot right after the \'try direct snapshot\' and adds a \'generic_snapshot\' method. The code for starting up the domain again is in \'generic_snapshot\' which only gets called if the exception \"ImageUnacceptable\" gets raised.\nas a quick hack, I just copied the \'new_dom\' lines into \'snapshot\' method and HUZZAH, it works as expected.\n\nHopefully we\'ll see a new commit to jdurgin\'s fork for icehouse and havana soon.\n\nOn Oct 26, 2014, at 6:08 AM, Simon Leinen <simon.leinen at switch.ch> wrote:\n\n> Abel Lopez writes:\n>> I saw this last commit to jdurgin\'s nova fork which solves the issue (\n>> https://github.com/jdurgin/nova/commit/ea4b5369e4bec4dd7a0ce9f68769600329cda6c6\n>> )\n>> now a snapshot happens in seconds. \n> \n>> The problem that we\'ve introduced however, is that about 15-20m after\n>> we do a snapshot, the VM is powered off.\n>> Every time.\n> \n> Ouch! Have you checked the logs (nova-compute and maybe libvirtd\'s)?\n> \n>> I can start the instance back up with `nova start`, but I am leery of\n>> pushing this out to prod and having to tell users to expect a shutdown\n>> after a snapshot.\n> \n> Understood.\n> \n>> Anyone else using this in Havana?\n> \n> Not me, but I\'m sympathetic with your worries, and want this resolved as\n> well.  We\'re using Icehouse with RBD, currently without the \"ephemeral\"\n> patches, but we would really like to (re-) activate that part of the\n> integration soon.\n> \n> It\'s maybe worth asking on #ceph or posting to one of the CEPH mailing\n> lists, too.\n> \n> Good luck,\n> -- \n> Simon.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141029/d55caf5f/attachment.pgp>\n\n','<aa38ab3rme.fsf@macsl.switch.ch>',NULL),('<1351166466.346.1359158511240.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-26 00:01:51',0,'2013-01-26 00:01:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-folsom #117','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/117/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise6 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/>\nCheckout:periodic-swift-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/> - hudson.remoting.Channel at 577a2815:precise6\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson7065431049889626475.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.8og6fnYLD2\n+ TMPDIR=/tmp/tmp.8og6fnYLD2\n+ trap \'rm -rf /tmp/tmp.8og6fnYLD2\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/117/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python27-stable-folsom-117\', \'SSH_CLIENT\': \'198.101.231.203 50520 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1357687285.854054-1874355803\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.8og6fnYLD2\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-26_00-01-22\', \'BUILD_NUMBER\': \'117\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'c139337a-4da6-4936-adce-286d6feb70b2\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50520 108.166.59.174 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.8og6fnYLD2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-folsom/117\n[SCP] Copying console log.\n\n\n','<383268077.328.1359072142804.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1351182080.30781.2.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-25 11:21:20',-18000,'2012-10-25 16:21:20',NULL,'[openstack-dev] Nova: add mock as a test dependency','On Thu, 2012-10-25 at 13:19 +0100, Mate Lakat wrote:\n> What do you guys think about adding mock==1.0.0 to the nova test\n> dependencies? I think it is already added to quantum.\n\nI believe it\'s also used in openstack-common.\n\nPersonally, I really like mock; I\'ve been using it on some of my\npersonal projects, and I would welcome its use in nova, etc.  I did -1\nthe review, however, because I think we should not add dependencies\nuntil we\'re actually using those dependencies somewhere?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<20121025121941.GA495@matel-HP-Elite-7300-Series-MT>',NULL),('<1351196763.3820.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-25 21:26:03',3600,'2012-10-25 20:26:03',NULL,'[openstack-dev] [openstack-tc] Motion to validate Heat\'s\n application as incubated project','On Wed, 2012-10-24 at 09:07 +1100, Angus Salkeld wrote:\n> Dear Member of the OpenStack Technical Committee,\n> \n> Following up on Heat\'s application to the former PPB to be\n> incubated that was done in July [1], we would like you to consider a\n> motion to validate this application at your next meeting.\n> \n> The project\'s application can be found at [2].\n> \n> We would be happy to answer any question you may have about our\n> application and hope that you will give a favorable answer to our request.\n> \n> [1] http://www.mail-archive.com/openstack at lists.launchpad.net/msg14506.html\n> [2] http://wiki.openstack.org/Heat\n\nI know some members of the TC would like to discuss the \"widening of\nOpenStack\'s scope\"[1] that including Heat implies. IMHO it would be good\nto give that subject a thoughtful airing on the mailing list rather than\nrush a discussion at the next meeting.\n\nBriefly, my feeling on the \"scope\" question is that at its core Heat\nprovides some very straightforward and easy to understand orchestration\nfeatures which are a really nice addition to OpenStack.\n\nBy orchestration, I mean it gives you the ability to say \"run my\nWordpress app\" and have the following happen:\n\n  1) The DB server instance is launched, perhaps with user-supplied \n     parameters like the DB admin password passed to the instance via\n     user-data\n  2) During its startup it reports its IP address back to Heat\n  3) Heat sees that the DB has started and launches the Wordpress \n     server with the DB IP address passed via user-data\n  4) The Wordpress app configures itself to use the DB and then reports \n     its own IP address back to Heat\n  5) Heat uses the IP address to build a URL for the Wordpress server \n     and returns the URL to the user\n\nAll of the instructions to Heat about how to orchestrate the launching\nof an app are supplied as part of the \"run my Wordpress app\" request in\nthe form of a \"template\" file. If you know AWS CloudFormations, then you\nknow how this works. Heat borrows heavily from it.\n\nThis is a really sweet feature and serves as a great integration point\nfor all OpenStack APIs. I\'d love to see this be accepted into the family\nof OpenStack projects.\n\nIn considering the incubation proposal, I\'d like to see us consider e.g.\n\n  * Is the project a sound technical idea?\n  * Does the architecture make sense?\n  * Is the service useful to OpenStack operators or users?\n  * Are the APIs a good addition to OpenStack APIs?\n  * Is the project following OpenStack development processes?\n  * Does the project look like it has a healthy future?\n\nThere\'s a whole other discussion about \"what is core?\", \"what is\nOpenStack??\", \"what services/APIs are required for a cloud to use the\nOpenStack name?\", etc.\n\nThat\'s a discussion that the TC and Foundation Board need to have (both\nseparately and together) but I\'d hate to see the TC undermine the\nprogress of a thriving project like Heat because we haven\'t got our act\ntogether on those questions.\n\nThe first question  should be whether we hope to welcome Heat into the\nfamily of OpenStack projects after an incubation period.\n\nThe second, later question should be how we classify Heat\'s role in that\nfamily once it has been incubated.\n\nCheers,\nMark.\n\n\n\n','<20121023220719.GA13413@redhat.com>',NULL),('<1351196763.3820.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-25 21:26:03',3600,'2012-10-25 20:26:03',NULL,'[openstack-tc] Motion to validate Heat\'s application as\n incubated project','On Wed, 2012-10-24 at 09:07 +1100, Angus Salkeld wrote:\n> Dear Member of the OpenStack Technical Committee,\n> \n> Following up on Heat\'s application to the former PPB to be\n> incubated that was done in July [1], we would like you to consider a\n> motion to validate this application at your next meeting.\n> \n> The project\'s application can be found at [2].\n> \n> We would be happy to answer any question you may have about our\n> application and hope that you will give a favorable answer to our request.\n> \n> [1] http://www.mail-archive.com/openstack at lists.launchpad.net/msg14506.html\n> [2] http://wiki.openstack.org/Heat\n\nI know some members of the TC would like to discuss the \"widening of\nOpenStack\'s scope\"[1] that including Heat implies. IMHO it would be good\nto give that subject a thoughtful airing on the mailing list rather than\nrush a discussion at the next meeting.\n\nBriefly, my feeling on the \"scope\" question is that at its core Heat\nprovides some very straightforward and easy to understand orchestration\nfeatures which are a really nice addition to OpenStack.\n\nBy orchestration, I mean it gives you the ability to say \"run my\nWordpress app\" and have the following happen:\n\n  1) The DB server instance is launched, perhaps with user-supplied \n     parameters like the DB admin password passed to the instance via\n     user-data\n  2) During its startup it reports its IP address back to Heat\n  3) Heat sees that the DB has started and launches the Wordpress \n     server with the DB IP address passed via user-data\n  4) The Wordpress app configures itself to use the DB and then reports \n     its own IP address back to Heat\n  5) Heat uses the IP address to build a URL for the Wordpress server \n     and returns the URL to the user\n\nAll of the instructions to Heat about how to orchestrate the launching\nof an app are supplied as part of the \"run my Wordpress app\" request in\nthe form of a \"template\" file. If you know AWS CloudFormations, then you\nknow how this works. Heat borrows heavily from it.\n\nThis is a really sweet feature and serves as a great integration point\nfor all OpenStack APIs. I\'d love to see this be accepted into the family\nof OpenStack projects.\n\nIn considering the incubation proposal, I\'d like to see us consider e.g.\n\n  * Is the project a sound technical idea?\n  * Does the architecture make sense?\n  * Is the service useful to OpenStack operators or users?\n  * Are the APIs a good addition to OpenStack APIs?\n  * Is the project following OpenStack development processes?\n  * Does the project look like it has a healthy future?\n\nThere\'s a whole other discussion about \"what is core?\", \"what is\nOpenStack??\", \"what services/APIs are required for a cloud to use the\nOpenStack name?\", etc.\n\nThat\'s a discussion that the TC and Foundation Board need to have (both\nseparately and together) but I\'d hate to see the TC undermine the\nprogress of a thriving project like Heat because we haven\'t got our act\ntogether on those questions.\n\nThe first question  should be whether we hope to welcome Heat into the\nfamily of OpenStack projects after an incubation period.\n\nThe second, later question should be how we classify Heat\'s role in that\nfamily once it has been incubated.\n\nCheers,\nMark.\n\n\n\n','<20121023220719.GA13413@redhat.com>',NULL),('<1351197409.3820.40.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-25 21:36:49',3600,'2012-10-25 20:36:49',NULL,'[openstack-dev] [openstack-tc] Motion to validate Heat\'s\n application as incubated project','On Thu, 2012-10-25 at 21:26 +0100, Mark McLoughlin wrote:\n> Briefly, my feeling on the \"scope\" question is that at its core Heat\n> provides some very straightforward and easy to understand orchestration\n> features which are a really nice addition to OpenStack.\n\nHmm, I guess I should add a couple of disclaimers ...\n\nAs you can see from our email addresses, a bunch of Heat developers work\nfor Red Hat and are, like me, on the OpenStack team. However, I\'ve\npersonally very little involvement in Heat\'s development or planning.\n\nThe tiny involvement I can claim is suggesting the basic idea for the\nproject over beers late one night in Brno, CZ. We\'d come across AWS\nCloudFormations when working on http://aeolusproject.org orchestration\nand it seemed obvious that something similar would be a great OpenStack\nproject.\n\nSo, discount my opinion as biased if you like. But, honestly, I think my\nopinion would be the same if I had zero involvement with Heat.\n\nCheers,\nMark.\n\n\n\n','<1351196763.3820.31.camel@sorcha>',NULL),('<1351197409.3820.40.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-25 21:36:49',3600,'2012-10-25 20:36:49',NULL,'[openstack-tc] Motion to validate Heat\'s application as\n incubated project','On Thu, 2012-10-25 at 21:26 +0100, Mark McLoughlin wrote:\n> Briefly, my feeling on the \"scope\" question is that at its core Heat\n> provides some very straightforward and easy to understand orchestration\n> features which are a really nice addition to OpenStack.\n\nHmm, I guess I should add a couple of disclaimers ...\n\nAs you can see from our email addresses, a bunch of Heat developers work\nfor Red Hat and are, like me, on the OpenStack team. However, I\'ve\npersonally very little involvement in Heat\'s development or planning.\n\nThe tiny involvement I can claim is suggesting the basic idea for the\nproject over beers late one night in Brno, CZ. We\'d come across AWS\nCloudFormations when working on http://aeolusproject.org orchestration\nand it seemed obvious that something similar would be a great OpenStack\nproject.\n\nSo, discount my opinion as biased if you like. But, honestly, I think my\nopinion would be the same if I had zero involvement with Heat.\n\nCheers,\nMark.\n\n\n\n','<1351196763.3820.31.camel@sorcha>',NULL),('<1351241366.3820.87.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-10-26 09:49:26',3600,'2012-10-26 08:49:26',NULL,'[OpenStack Foundation] Proposals for individual board election','On Fri, 2012-10-26 at 09:24 +0800, Hui Cheng wrote:\n> Hi all:\n> \n> ** **\n> \n> Until now we already have tons of discussions regarding the individual\n> board member election, and we have some meaningful proposals from the\n> following discussions:****\n> \n> http://www.gossamer-threads.com/lists/openstack/foundation/19569****\n> \n> http://www.gossamer-threads.com/lists/openstack/foundation/19675****\n> \n> ** **\n> \n> From my understanding, most proposals are focusing on how to increase\n> the barrier for becoming individual members and limit one single\n> company\'s undue board control.****\n> \n> ** **\n> \n> In the initial board election, everyone can be nominated by everyone, it is\n> really easy for someone to get at least 10 nominators, thus to be\n> a candidate, and then voting began. Thus any incapable person can be\n> elected in such kind of process.****\n\nThanks for posting your thoughts on this. None of your ideas or crazy\nbut, like Ryan, I\'d be wary of requiring people to publish a video.\n\nHowever, I think you\'ve focused on the wrong thing. The main issue is\nnot that we had too many incapable candidates, nor that those elected\nare incapable, but that we had large numbers of people affiliated with a\nsmall number of companies voting for employees of their company.\n\nThe issue isn\'t so much the correlation between affiliation and voting\npattern either IMHO, but just the sheer number of people doing so.\n\nPersonally, I just wonder why 600+ people from an individual company\nshould have voting rights in the election. In the cases of e.g. the Red\nHat and Cisco OpenStack teams, it was only those actively involved with\nthe project who joined the Foundation and voted.\n\nCheers,\nMark.\n\n\n\n','<CAAtGtGSRYNPy+byaZvjMq7+ViH0MEJiLHcKy0eAmVe0w7eqTog@mail.gmail.com>',NULL),('<1351257732.3820.110.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-26 14:22:12',3600,'2012-10-26 13:22:12',NULL,'[openstack-dev] [openstack-tc] Motion to validate Heat\'s\n application as incubated project','On Fri, 2012-10-26 at 14:30 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > All of the instructions to Heat about how to orchestrate the launching\n> > of an app are supplied as part of the \"run my Wordpress app\" request in\n> > the form of a \"template\" file. If you know AWS CloudFormations, then you\n> > know how this works. Heat borrows heavily from it.\n> \n> The main issue I see with us entering this space is that there are many\n> competing solutions out there. I\'m not entirely convinced there is that\n> much value in OpenStack picking one and somehow making the others\n> second-class...\n\nCare to list the many competing solutions that you\'re concerned about\nmaking second-class?\n\n> In particular, the argument could be made that ...\n\nUnclear whether you\'re relaying perceived potential arguments or your\nown view?\n\n> the priority should be in providing the basic services that IaaS is\n> about (together with the supporting services that are necessary to run\n> those), while leaving the client/management/orchestration/deployment\n> space to an ecosystem of competing solutions.\n\nPrioritize basic services, agree. We don\'t want to dilute our focus by\ngrowing our scope at an unsustainable rate.\n\nAllow a ecosystem of competing solutions to form around those, agree. In\nmany cases that is the right choice.\n\nHowever, I do see the project growing (slowly, cautiously) in scope over\ntime and that should be welcomed. What is considered \"basic IaaS\" will\nchange. What users considered advanced features when EC2 was first\nlaunched are now considered trivial and features like CloudWatch and\nAuto-Scaling are \"basic\".\n\nI see Heat as being in the vein - with the increasingly sophisticated\nfeatures clouds are providing and how people are using those features, a\norchestration API is becoming pretty essential.\n\nLook at some of the templates listed here:\n\n  http://aws.amazon.com/cloudformation/aws-cloudformation-templates/\n\nand then think about how OpenStack is evolving. Even now, a single\nmulti-instance launch request may involve talking multiple times to\nGlance, Nova, Cinder and Quantum and we shouldn\'t be recommending a\nsituation where users need to script this client-side or use a third\nparty service.\n\nAlso, I think both Heat will be improved by being in OpenStack (e.g.\nimproved in-guest signalling back to Heat) and the rest of OpenStack\nwill be improved by Heat\'s inclusion (e.g. helping to drive our\nunderstanding of monitoring and auto-scaling use cases).\n\n> > In considering the incubation proposal, I\'d like to see us consider e.g.\n> > \n> >   * Is the project a sound technical idea?\n> >   * Does the architecture make sense?\n> >   * Is the service useful to OpenStack operators or users?\n> >   * Are the APIs a good addition to OpenStack APIs?\n> >   * Is the project following OpenStack development processes?\n> >   * Does the project look like it has a healthy future?\n> \n> Incubation is about diverting some common resources (QA, CI, Release\n> management) to support the incubating project. So we also need to\n> address whether the project ultimately looks like a welcome addition to\n> the OpenStack set of projects or if it should just live \"in the\n> ecosystem\"... because incubating a project has a cost.\n\nI agree. I hope I\'m helping to make the case for it being a welcome\naddition :)\n\nCheers,\nMark.\n\n\n\n','<508A8265.7070502@openstack.org>',NULL),('<1351257732.3820.110.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-10-26 14:22:12',3600,'2012-10-26 13:22:12',NULL,'[openstack-tc] Motion to validate Heat\'s application as\n incubated project','On Fri, 2012-10-26 at 14:30 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > All of the instructions to Heat about how to orchestrate the launching\n> > of an app are supplied as part of the \"run my Wordpress app\" request in\n> > the form of a \"template\" file. If you know AWS CloudFormations, then you\n> > know how this works. Heat borrows heavily from it.\n> \n> The main issue I see with us entering this space is that there are many\n> competing solutions out there. I\'m not entirely convinced there is that\n> much value in OpenStack picking one and somehow making the others\n> second-class...\n\nCare to list the many competing solutions that you\'re concerned about\nmaking second-class?\n\n> In particular, the argument could be made that ...\n\nUnclear whether you\'re relaying perceived potential arguments or your\nown view?\n\n> the priority should be in providing the basic services that IaaS is\n> about (together with the supporting services that are necessary to run\n> those), while leaving the client/management/orchestration/deployment\n> space to an ecosystem of competing solutions.\n\nPrioritize basic services, agree. We don\'t want to dilute our focus by\ngrowing our scope at an unsustainable rate.\n\nAllow a ecosystem of competing solutions to form around those, agree. In\nmany cases that is the right choice.\n\nHowever, I do see the project growing (slowly, cautiously) in scope over\ntime and that should be welcomed. What is considered \"basic IaaS\" will\nchange. What users considered advanced features when EC2 was first\nlaunched are now considered trivial and features like CloudWatch and\nAuto-Scaling are \"basic\".\n\nI see Heat as being in the vein - with the increasingly sophisticated\nfeatures clouds are providing and how people are using those features, a\norchestration API is becoming pretty essential.\n\nLook at some of the templates listed here:\n\n  http://aws.amazon.com/cloudformation/aws-cloudformation-templates/\n\nand then think about how OpenStack is evolving. Even now, a single\nmulti-instance launch request may involve talking multiple times to\nGlance, Nova, Cinder and Quantum and we shouldn\'t be recommending a\nsituation where users need to script this client-side or use a third\nparty service.\n\nAlso, I think both Heat will be improved by being in OpenStack (e.g.\nimproved in-guest signalling back to Heat) and the rest of OpenStack\nwill be improved by Heat\'s inclusion (e.g. helping to drive our\nunderstanding of monitoring and auto-scaling use cases).\n\n> > In considering the incubation proposal, I\'d like to see us consider e.g.\n> > \n> >   * Is the project a sound technical idea?\n> >   * Does the architecture make sense?\n> >   * Is the service useful to OpenStack operators or users?\n> >   * Are the APIs a good addition to OpenStack APIs?\n> >   * Is the project following OpenStack development processes?\n> >   * Does the project look like it has a healthy future?\n> \n> Incubation is about diverting some common resources (QA, CI, Release\n> management) to support the incubating project. So we also need to\n> address whether the project ultimately looks like a welcome addition to\n> the OpenStack set of projects or if it should just live \"in the\n> ecosystem\"... because incubating a project has a cost.\n\nI agree. I hope I\'m helping to make the case for it being a welcome\naddition :)\n\nCheers,\nMark.\n\n\n\n','<508A8265.7070502@openstack.org>',NULL),('<1351327988.18.1379749522734.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-21 07:45:22',0,'2013-09-21 07:45:22',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #23','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/23/>\n\n------------------------------------------\n[...truncated 43019 lines...]\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Server 4a564de9-86cf-485d-9b8f-9a1e1f3d29ef failed to reach ACTIVE status within the required time (400 s). Current status: BUILD.\n\n\n======================================================================\nFAIL: tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-21 07:16:38,281 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:16:38,391 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_minimum_basic.py\", line 153, in test_minimum_basic_scenario\n    self.nova_boot()\n  File \"tempest/scenario/test_minimum_basic.py\", line 92, in nova_boot\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 341, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing 20c2aa49-99a0-461d-9ec4-b799db7c0132                       to become ACTIVE\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-21 07:23:24,449 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:23:24,550 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 51, in test_resize_server_confirm\n    instance = self.create_server(self.compute_client)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 341, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing 450d154d-f849-4349-b532-21f0397528f6                       to become ACTIVE\n\n\n======================================================================\nFAIL: tearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\ntearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/thirdparty/boto/test.py\", line 270, in tearDownClass\n    raise exceptions.TearDownException(num=fail_count)\nTearDownException: 2 cleanUp operation failed\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-21 07:23:58,318 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:23:58,427 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:23:59,147 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:23:59,250 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:24:00,855 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:24:01,934 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:24:03,010 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:24:04,085 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 129, in test_volume_boot_pattern\n    keypair)\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 53, in _boot_instance_from_volume\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 341, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing 764e5df6-582d-4d70-a9c1-7cc4fe02d75c                       to become ACTIVE\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  pythonlogging:\'\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 69, in test_server_sequence_suspend_resume\n    instance = self.create_server(self.compute_client)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 341, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing 40cae585-f458-43b7-8ae2-80d61d0e0515                       to become ACTIVE\n\n\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-21 07:36:50,695 Starting new HTTP connection (1): 127.0.0.1\n2013-09-21 07:36:50,799 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 72, in test_snapshot_pattern\n    server = self._boot_image(self.config.compute.image_ref)\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 38, in _boot_image\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 341, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing 07aa1844-2873-4613-9c9e-22dda5a3fc50                       to become ACTIVE\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 1150 tests in 5789.188s\n\nFAILED (failures=45, skipped=64)\nERROR: InvocationError: \'/bin/sh tools/pretty_tox.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])(^tempest\\\\.(api|scenario|thirdparty|cli|tests))\'\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-355066-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-355066.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-355066/23/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1176528909.13.1379572314523.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1351537953.30731114@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-29 15:12:33',-14400,'2012-10-29 19:12:33',NULL,'[openstack-dev] Automate backup images','\nHey ?douard,\n \nEddie Sheffield and I are putting together a similar blueprint with some implementation ideas we have been discussing with our team. We have some thoughts around specific issues that may arise and scalability concerns. Some other members of our team are looking into a simpler, best-effort implementation based on using a more generic cron service that would be less equipped to handle error cases.\n \nWe\'ll be sending out a proposal blueprint shortly.\n \n-Alex\n \n-----Original Message-----\nFrom: \"?douard Thuleau\" <thuleau at gmail.com>\nSent: Monday, October 29, 2012 8:07am\nTo: josh.kearney at rackspace.com\nCc: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] Automate backup images\n\n\n\nHi Josh,\nI aim to automate backup images of instance.\nI saw that you implemented a backup solution to the OpenStack Compute API which uses the snapshot mechanism of OpenStack Nova. It adds backup command with parameters \'backup_type\' and \'rotation\'. This command permits to define two type of backup (daily and weekly) and the number of backup to keep around.\nThe problem is this mechanism isn\'t periodically executed by OpenStack. The user must execute himself the backup command to update the backuped images.\nI created, few weeks ago, a blueprint to define a simple way to automate this mechanism: [https://blueprints.launchpad.net/nova/+spec/backup-schedule] https://blueprints.launchpad.net/nova/+spec/backup-schedule\nCould you send me some comments/feedback on this blueprint ?\nRegards,\n?douard.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121029/ff96a07c/attachment.html>\n\n','<CAKRF=ed3KKNpKf1Ng5Bf_7z=KoPZWVX1_Hk1npGBC0_2ndePcg@mail.gmail.com>',NULL),('<1351611443.30781.21.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-30 10:37:23',-18000,'2012-10-30 15:37:23',NULL,'[openstack-dev] Configuration Options, APIs, Class Paths, Oh my!','On Mon, 2012-10-29 at 21:21 -0400, Russell Bryant wrote:\n> This patch introduces a new configuration option, servicegroup_driver.\n> The default value for this option is\n> \'nova.servicegroup.db_driver.DbDriver\'.  I have a couple of objections\n> with using a class path as the value.\n> \n> 1) It breaks as soon as the code moves.\n[snip]\n> 2) It implies that this is a stable, supported API.\n\nAs a point of information, there is currently a series of patches by\nMonty to move nova over to using entrypoints.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<508F2BAD.4030205@redhat.com>',NULL),('<1351612562.30781.26.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-30 10:56:02',-18000,'2012-10-30 15:56:02',NULL,'[openstack-dev] [OSSG] SSL Review (Clark, Robert Graham)','On Tue, 2012-10-30 at 15:43 +0000, Clark, Robert Graham wrote:\n> In this context yes, when I (or my esteemed colleague Stuart) mention\n> CNAME we actually mean the x509 Common Name otherwise referred to as\n> CN.\n> \n> You make a good point around subjectAlternativeNames, whenever a\n> certificate is presented we should check against the CN and the SANs,\n> if\n> the certificate has SANs.\n\nMy recent reading suggests that, if present, SubjectAltNames should be\npreferred over CommonName [1].  Something to think about?\n\n[1] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CCB5A32B.E6EC%robert.clark@hp.com>',NULL),('<13516228-E44A-4D82-A44F-D02493620093@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-29 08:53:43',0,'2014-07-29 08:53:43',NULL,'[openstack-dev] [Nova][Spec freeze exception] Controlled\n shutdown of GuestOS','Glad to see that the Bp is hypervisor independent.\n\nWe\'ll provide the Hyper-V implementation, based on this TODO comment:\n\nhttps://review.openstack.org/#/c/99916/3/nova/virt/hyperv/driver.py\n\nThanks,\n\nAlessandro\n\n\n> On 25.07.2014, at 03:08, \"Michael Still\" <mikal at stillhq.com> wrote:\n> \n> Yep, I think this one has well and truly crossed the line. Exception granted.\n> \n> Michael\n> \n> On Fri, Jul 25, 2014 at 2:30 AM, Andrew Laski\n> <andrew.laski at rackspace.com> wrote:\n>> \n>> ________________________________________\n>> From: Day, Phil [philip.day at hp.com]\n>> Sent: Thursday, July 24, 2014 9:20 AM\n>> To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange\n>> Subject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled shutdown of GuestOS\n>> \n>> According to: https://etherpad.openstack.org/p/nova-juno-spec-priorities   alaski has also singed up for this if I drop the point of contention - which I\'ev done\n>> \n>> \n>> Yes, I will sponsor this one as well.  This is more a bug fix than a feature IMO and would be really nice to get into Juno.\n>> \n>> \n>> \n>>> -----Original Message-----\n>>> From: Michael Still [mailto:mikal at stillhq.com]\n>>> Sent: 24 July 2014 00:50\n>>> To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage\n>>> questions)\n>>> Subject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled\n>>> shutdown of GuestOS\n>>> \n>>> Another core sponsor would be nice on this one. Any takers?\n>>> \n>>> Michael\n>>> \n>>> On Thu, Jul 24, 2014 at 4:14 AM, Daniel P. Berrange <berrange at redhat.com>\n>>> wrote:\n>>>> On Wed, Jul 23, 2014 at 06:08:52PM +0000, Day, Phil wrote:\n>>>>> Hi Folks,\n>>>>> \n>>>>> I\'d like to propose the following as an exception to the spec freeze, on the\n>>> basis that it addresses a potential data corruption issues in the Guest.\n>>>>> \n>>>>> https://review.openstack.org/#/c/89650\n>>>>> \n>>>>> We were pretty close to getting acceptance on this before, apart from a\n>>> debate over whether one additional config value could be allowed to be set\n>>> via image metadata - so I\'ve given in for now on wanting that feature from a\n>>> deployer perspective, and said that we\'ll hard code it as requested.\n>>>>> \n>>>>> Initial parts of the implementation are here:\n>>>>> https://review.openstack.org/#/c/68942/\n>>>>> https://review.openstack.org/#/c/99916/\n>>>> \n>>>> Per my comments already, I think this is important for Juno and will\n>>>> sponsor it.\n>>>> \n>>>> Regards,\n>>>> Daniel\n>>>> --\n>>>> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/\n>>> :|\n>>>> |: http://libvirt.org              -o-             http://virt-manager.org :|\n>>>> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n>>>> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> \n>>> --\n>>> Rackspace Australia\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> -- \n> Rackspace Australia\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAEd1pt7Tg-8wU01+_T0=sRqLdbrqhGFr-TsPHPrVP=UrFcddsA@mail.gmail.com>',NULL),('<1351638546.30781.29.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-30 18:09:06',-18000,'2012-10-30 23:09:06',NULL,'[openstack-dev] [nova] entrypoint slowness','On Tue, 2012-10-30 at 18:44 -0400, Sean Dague wrote:\n> While I get that in production, the class loading will disappear in the \n> noise, that huge hit on the unit tests seems really problematic from a \n> developer point of view. And a big problem from a CI perspective. Anyone \n> have ideas on why this is such a huge hit, or thoughts on how to \n> mitigate it?\n\nStub it out.  Honestly, we don\'t need to test stevedore itself except in\na small handful of tests?just to ensure that we\'re using the interface\ncorrectly?, so stubbing out the calls to it would be the best thing.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50905850.7070800@linux.vnet.ibm.com>',NULL),('<1351660768.53499353.1411414176885.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 15:29:36',-14400,'2014-09-22 19:29:36',NULL,'[openstack-dev] [requirements] [nova] requirements\n	freeze	exception for websockify','FYI, we roughly do semantic versioning right-shifted by one -- for a release 0.X.Y, incrementing X is supposed to be backwards-incompatible, while incrementing Y is supposed to be backwards-compatible [1].\n\nThus, you can safely say anything less than 0.7 should work fine for Nova.\n\nBest Regards,\nSolly\n\n[1] https://github.com/kanaka/websockify/issues/122\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-dev at lists.openstack.org\n> Sent: Monday, September 22, 2014 3:22:54 PM\n> Subject: Re: [openstack-dev] [requirements] [nova] requirements freeze	exception for websockify\n> \n> On 09/22/2014 02:58 PM, Solly Ross wrote:\n> > The reason it was bounded was because we (the websockify upstream\n> > mantainers) made a backwards-incompatible change (for good reasons -- it\n> > brought websockify more inline with the Python standard library\n> > interfaces).\n> > However, OpenStack had subclassed the WebSocketProxy code, and so the\n> > change would have broken OpenStack.\n> > \n> > I did a commit a while ago that made it possible to use Nova with both the\n> > newest version and the older versions, but we never bumped the max version\n> > for OpenStack, even though we could.\n> \n> Actually, the max version is bumped. We\'re testing with 0.6.0 in the\n> gate because of it.\n> \n> 	-Sean\n> \n> > \n> > Best Regards,\n> > Solly\n> > \n> > ----- Original Message -----\n> >> From: \"Doug Hellmann\" <doug at doughellmann.com>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >> <openstack-dev at lists.openstack.org>\n> >> Sent: Friday, September 19, 2014 1:54:08 PM\n> >> Subject: Re: [openstack-dev] [requirements] [nova] requirements freeze\n> >> 	exception for websockify\n> >>\n> >> On Sep 19, 2014, at 11:22 AM, Sean Dague <sean at dague.net> wrote:\n> >>\n> >>> I\'d like to request a requirements freeze exception for websockify -\n> >>> https://review.openstack.org/#/c/122702/\n> >>>\n> >>> The rationale for this is that websockify version bump fixes a Nova bug\n> >>> about zombie processes - https://bugs.launchpad.net/nova/+bug/1048703.\n> >>> It also sets g-r to the value we\'ve been testing against for the entire\n> >>> last cycle.\n> >>>\n> >>> I don\'t believe it has any impacts on other projects, so should be a\n> >>> very safe change.\n> >>\n> >> Gantt, Ironic, and Nova all use websockify.\n> >>\n> >> I?m +1 on updating the minimum based on the fact that our current version\n> >> spec is causing us to test with this version anyway.\n> >>\n> >> However, the proposed change also removes the upper bound. Do we know why\n> >> that was bounded before? Have we had issues with API changes in that\n> >> project? Is it safe to remove the cap?\n> >>\n> >> Doug\n> >>\n> >>>\n> >>> 	-Sean\n> >>>\n> >>> --\n> >>> Sean Dague\n> >>> http://dague.net\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5420770E.2090607@dague.net>',NULL),('<1351700742.30781.31.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-31 11:25:42',-18000,'2012-10-31 16:25:42',NULL,'[openstack-dev] [nova] entrypoint slowness','On Wed, 2012-10-31 at 12:04 -0400, Sean Dague wrote:\n> So I guess the question back to the experts is, is there a path here \n> that makes this not add so much time to the test runs?\n\nYes, there is.  Stub out stevedore in the test suite.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50914C16.9050709@linux.vnet.ibm.com>',NULL),('<1351717263.699222750@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-31 17:01:03',-14400,'2012-10-31 21:01:03',NULL,'[openstack-dev] [nova] Automate backup images','\nHey ?douard,\n \nMy team has put together some ideas on scheduled backups as well.\n \nA generic cron service, here:\nhttp://wiki.openstack.org/scheduled-task-service\n \nand a more robust snapshot scheduling service, here:\nhttp://wiki.openstack.org/scheduled-images-service\n \nWe want to know what everyone else needs out of this feature, these are just some solutions we have thought about.\n \nWe need something more robust than simple periodic tasks since our cloud will be under heavy load. One example is in both proposals we have the snapshot time being determined by the system and not the user, this is important in a heavy load system since we do not want to handle a heavy load in bursts. However, allowing a user to specify time could always be an option of the deployer.\n \n-Alex\n \n \n-----Original Message-----\nFrom: \"?douard Thuleau\" <edouard.thuleau at gmail.com>\nSent: Wednesday, October 31, 2012 7:00am\nTo: josh at jk0.org\nCc: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [nova] Automate backup images\n\n\nHi Josh,\n\nI aim to automate backup images of instance.\n\nI saw that you implemented a backup solution to the OpenStack Compute API which uses the snapshot mechanism of OpenStack Nova. It adds backup command with parameters \'backup_type\' and \'rotation\'. This command permits to define two type of backup (daily and weekly) and the number of backup to keep around.\nThe problem is this mechanism isn\'t periodically executed by OpenStack. The user must execute himself the backup command to update the backuped images.\n\nI created, few weeks ago, a blueprint to define a simple way to automate this mechanism: [https://blueprints.launchpad.net/nova/+spec/backup-schedule] https://blueprints.launchpad.net/nova/+spec/backup-schedule\nCould you send me some comments/feedback on this blueprint ?\nRegards,\n?douard.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/23859d16/attachment.html>\n\n','<CAKRF=ecAaVkaUsh_f0OiPHF=V_gd=8DH-_RUtASDJb7yf-pu_w@mail.gmail.com>',NULL),('<1351750975.3820.164.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 06:22:55',0,'2012-11-01 06:22:55',NULL,'[openstack-dev] [Quantum] import lockutil and fileutil from the\n openstack-common to the quantum','Hi Nachi,\n\nOn Wed, 2012-10-31 at 16:48 -0700, Nachi Ueno wrote:\n> Hi Quantum folks\n> \n> I would like to import lockutil and fileutil from the openstack-common\n> to the quantum\n> # They are needed to implement iptables implementation for securitygroup.\n> \n> I updated openstack-common.conf and used python update.py with\n> stable/folsom version of openstack-common.\n> \n> This operation also updates setup.py and another files.\n> And new setup.py looks didn\'t work with CI.\n> https://review.openstack.org/#/c/15156/\n> \n> How should I work with this?\n> \n> Option 1)  copy lockutil and fileutil manually then commit\n> Option 2)  work with CI team to let new setup.py and CI works\n\nOption 3)  only \'git add\' the lockutil and fileutil changes\nOption 4)  ask update.py explicitly to copy lockutil/fileutil:\n\n  $> python update.py --modules lockutil,fileutil --base quantum ../quantum\n\nCheers,\nMark.\n\n\n\n','<CABJepwg2smjrf1p2XbUOtkkOfjDG+0rsVuS0kN7Qq=jGZPhk1Q@mail.gmail.com>',NULL),('<1351754890.3820.172.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 07:28:10',0,'2012-11-01 07:28:10',NULL,'[openstack-dev] [Stable Release] Pip Requires','On Wed, 2012-10-31 at 12:57 +0000, P?draig Brady wrote:\n> On 10/31/2012 12:08 PM, Gary Kotton wrote:\n> > Hi,\n> > Whilst back porting patches to the Quantum stable folsom branch I have encountered a very frustrating problem which I think that should be discussed. All of the stable quantum patches approved in the last few hours are failing unit tests. This seems to be due to one of the imported packages being problematic (the hunch at the moment is that this could be sqlalchemy). At the moment this is under investigation. I am wondering if when we create a stable branch, we should specifically set the pip-requires package numbers.\n> > Any thoughts?\n> > Thanks\n> > Gary\n> \n> This was discussed at the design summit, with notes kept here:\n> https://etherpad.openstack.org/process-dependency-management\n> \n> One of the action items from there is:\n> \n> * freeze \'sane\' version (max major version?) range at release time\n> \n> So by recording the max version in the pip-requires,\n> it would mean that newer versions wouldn\'t be pulled\n> in, in the future, that might break stuff.\n> Also distros etc. should not be impacted since packages\n> manage dependencies independently.\n\nYep, I think we should go this route.\n\nBasically, on master we should be testing the latest versions of\nlibraries as they are released because the next release needs to work on\ndistros with the very latest libraries.\n\nOn the stable branch, I think we mostly just want to keep the gate\nworking and not be randomly impacted by new libraries.\n\nThe question is how to do this. The Jenkins gate job runs \'pip freeze\'\nso we have a source of this info:\n\n  http://logs.openstack.org/13829/1/gate/gate-quantum-python27/1696/console.html.gz\n\nand since that\'s the commit which started the stable/folsom branch, it\nshould be the list we want.\n\nSo we can take that \'pip freeze\' output and use it to update the\npip-requires. I\'ve re-purposed a script Monty wrote for this:\n\n  https://gist.github.com/3992317\n\nand the result looks like this:\n\n  https://review.openstack.org/15186\n\nThoughts?\n\nCheers,\nMark.\n\n\n\n','<5091202D.7070705@draigBrady.com>',NULL),('<1351773698.3820.180.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 12:41:38',0,'2012-11-01 12:41:38',NULL,'[openstack-dev] [Stable Release] Pip Requires','On Thu, 2012-11-01 at 12:56 +0100, Monty Taylor wrote:\n> \n> On 11/01/2012 08:28 AM, Mark McLoughlin wrote:\n> > On Wed, 2012-10-31 at 12:57 +0000, P?draig Brady wrote:\n> >> On 10/31/2012 12:08 PM, Gary Kotton wrote:\n> >>> Hi,\n> >>> Whilst back porting patches to the Quantum stable folsom branch I have encountered a very frustrating problem which I think that should be discussed. All of the stable quantum patches approved in the last few hours are failing unit tests. This seems to be due to one of the imported packages being problematic (the hunch at the moment is that this could be sqlalchemy). At the moment this is under investigation. I am wondering if when we create a stable branch, we should specifically set the pip-requires package numbers.\n> >>> Any thoughts?\n> >>> Thanks\n> >>> Gary\n> >>\n> >> This was discussed at the design summit, with notes kept here:\n> >> https://etherpad.openstack.org/process-dependency-management\n> >>\n> >> One of the action items from there is:\n> >>\n> >> * freeze \'sane\' version (max major version?) range at release time\n> >>\n> >> So by recording the max version in the pip-requires,\n> >> it would mean that newer versions wouldn\'t be pulled\n> >> in, in the future, that might break stuff.\n> >> Also distros etc. should not be impacted since packages\n> >> manage dependencies independently.\n> > \n> > Yep, I think we should go this route.\n> > \n> > Basically, on master we should be testing the latest versions of\n> > libraries as they are released because the next release needs to work on\n> > distros with the very latest libraries.\n> > \n> > On the stable branch, I think we mostly just want to keep the gate\n> > working and not be randomly impacted by new libraries.\n> > \n> > The question is how to do this. The Jenkins gate job runs \'pip freeze\'\n> > so we have a source of this info:\n> > \n> >   http://logs.openstack.org/13829/1/gate/gate-quantum-python27/1696/console.html.gz\n> > \n> > and since that\'s the commit which started the stable/folsom branch, it\n> > should be the list we want.\n> > \n> > So we can take that \'pip freeze\' output and use it to update the\n> > pip-requires. I\'ve re-purposed a script Monty wrote for this:\n> > \n> >   https://gist.github.com/3992317\n> > \n> > and the result looks like this:\n> > \n> >   https://review.openstack.org/15186\n> > \n> > Thoughts?\n> \n> I think the general approach is great - but I think that doing an\n> absolute == has the potential to break current releases on older distro\n> versions. Instead, if we add a ,<=current_version to the end of the\n> version string, then we protect ourselves from new unexpected pypi\n> releases without asserting a new lower-bound on acceptable older library\n> releases which may or may not be a valid assertion.\n\ntl;dr of below is that we had agreed on a solution for this at summit\nand then forgot about it until now. We\'ll drop the version pinning idea\nand have the Jenkings nightly-stable jobs send email notifications to\nthe stable-maint team\n\n---\n\nMonty and I just discussed this on IRC and the discussion turned pretty\nheated when he reminded me that the versions in pip-requires are also\nincluded in setup.py :)\n\nBasically, Monty\'s concern about using == is that you\'d be prevented\nfrom doing \'python setup.py install\' with older versions of the\nrequirements installed. I\'m similarly concerned about not being able to\ndo that with *newer* versions of the requirements installed.\n\nWhere we got to in the end is that the issue of keeping the stable gate\nrunning on a stable set of library versions is the issue everyone wants\nto see resolved now and we\'ve pretty good consensus on that. The issue\nof what goes into install_requires in setup.py requires much more\ndiscussion.\n\nSo, I was going to propose a patch that would add frozen-pip-requires\nwith the specific versions pinned there and make tox use that for\ntesting purposes.\n\nAfter some more discussion we realized we do actually want to catch\ncases where a new library version comes along and breaks things. Having\nthe gate running on a frozen set of versions would mean we don\'t catch\nthis.\n\nAnd after all of this, we remembered that Jenkins actually runs the gate\ntests nightly on stable/folsom and we had agreed that email\nnotifications about failures of those should go to the stable-maint\nteam. That way we should quickly catch such issues and update\npip-requires as appropriate.\n\nCheers,\nMark.\n\n\n\n','<5092636A.1090500@inaugust.com>',NULL),('<1351781094.3820.190.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 14:44:54',0,'2012-11-01 14:44:54',NULL,'[Openstack-stable-maint] Proposing garyk for stable-maint team','Hey,\n\nI figure I\'d abuse our new mailing list even though we set it up for\nJenkins notifications :)\n\nGary has been doing a tonne of work identifying fixes to backport to\nQuantum\'s stable/folsom:\n\n  https://review.openstack.org/#/q/branch:stable/folsom+owner:garyk,n,z\n\nI think he\'s showing good judgement about what constitutes a suitable\nfix for the stable branch. Any objections to adding him to stable-maint?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351782134.3820.194.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 15:02:14',0,'2012-11-01 15:02:14',NULL,'[Openstack-stable-maint] stable-maint','Hi John,\n\nNow that Cinder is core, the openstack-stable-maint team is responsible\nfor the stable/folsom branch.\n\nThat team\'s job is really to evaluate the risk/benefit of a given\nbackported patch and understand the \"safe source of fixes for\nhigh-impact, user-visible issues\" policy documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nDuring Essex, I added all the PTLs to the team since they have to make\nsimilar tradeoffs when backporting to the milestone-proposed branch.\nThat has worked well, so I figure it makes sense to continue it.\n\nSo, basically - keep an eye out for changes proposed to stable/folsom\nand then:\n\n * evaluate risk of a patch\n * consider how severe the issue is for users\n * check that it\'s already fixed on master\n\nPlease add a little comment indicating whether a change meets those\ncriteria when adding your +/-2\n\nAlso, stable/folsom reviews need 2 +2s from stable-maint members unless\nthe person proposing the backport is also a stable-maint member.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351782651.3820.196.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 15:10:51',0,'2012-11-01 15:10:51',NULL,'[Openstack-stable-maint] stable-maint','Hi Gabriel,\n\nThe openstack-stable-maint team is responsible for the stable/folsom\nbranch.\n\nThat team\'s job is really to evaluate the risk/benefit of a given\nbackported patch and understand the \"safe source of fixes for\nhigh-impact, user-visible issues\" policy documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nDuring Essex, I added all the PTLs to the team since they have to make\nsimilar tradeoffs when backporting to the milestone-proposed branch.\nSince you\'ve taken over from Devin as Horizon PTL, I figure it makes\nsense to add you in place of Devin.\n\nSo, basically - keep an eye out for changes proposed to stable/folsom\nand then:\n\n * evaluate risk of a patch\n * consider how severe the issue is for users\n * check that it\'s already fixed on master\n\nPlease add a little comment indicating whether a change meets those\ncriteria when adding your +/-2\n\nAlso, stable/folsom reviews need 2 +2s from stable-maint members unless\nthe person proposing the backport is also a stable-maint member.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351785144.3820.199.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 15:52:24',0,'2012-11-01 15:52:24',NULL,'[Openstack-stable-maint] Proposing garyk for stable-maint team','On Thu, 2012-11-01 at 15:32 +0000, Daviey Walker wrote:\n> On 1 November 2012 14:44, Mark McLoughlin <markmc at redhat.com> wrote:\n> >\n> > Hey,\n> >\n> > I figure I\'d abuse our new mailing list even though we set it up for\n> > Jenkins notifications :)\n> >\n> > Gary has been doing a tonne of work identifying fixes to backport to\n> > Quantum\'s stable/folsom:\n> >\n> >   https://review.openstack.org/#/q/branch:stable/folsom+owner:garyk,n,z\n> >\n> > I think he\'s showing good judgement about what constitutes a suitable\n> > fix for the stable branch. Any objections to adding him to stable-maint?\n> >\n> > Cheers,\n> > Mark.\n> >\n> >\n> \n> Hi,\n> \n> Some great contributions for stable/folsom quantum.  Does Gary have\n> interest in other openstack components?\n\nProbably not so much, but nor do the PTLs on the stable-maint.\n\n> Does Gary understand the relevant processes,\n\nYes\n\n> and perhaps project specific nuances?\n\nCertainly for Quantum and I\'d don\'t expect him to approve stuff on other\nprojects which he isn\'t comfortable with\n\nGary has basically been doing the stable-maint work that many of the\nPTLs of other projects do, that\'s my thinking here.\n\nCheers,\nMark.\n\n\n\n','<CACyjiAjqtM83T6ozi6P-sJM3VvsPmrzHOqC02QHMLrdzonrNVg@mail.gmail.com>',NULL),('<1351786326.3820.205.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-01 16:12:06',0,'2012-11-01 16:12:06',NULL,'[openstack-dev] Proposed RPC API change on nova stable/folsom','Hey,\n\nFor the first time (that I\'m aware of) we have a request to include a\nbackport on the stable branch which includes a change to the RPC API:\n\n  https://review.openstack.org/14754\n\nThis is troublesome for a couple of reasons:\n\n  1) People upgrading to a version which includes this change would \n     need to be aware that they should update their compute services\n     before updating their API services\n\n  2) While in this case we\'re backporting the first RPC API change \n     since Folsom (i.e. version 2.2 was in Folsom, this is version 2.3)\n     if we were backporting a later API version we would have to give \n     up on retaining Folsom compatibility in Grizzly\n\nIn this particular case, I\'m somewhat hopeful we might be able to figure\nout a fix which doesn\'t involve the API change but that remains to be\nseen.\n\nAny ideas?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351786326.3820.205.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 16:12:06',0,'2012-11-01 16:12:06',NULL,'[Openstack-stable-maint] Proposed RPC API change on nova\n	stable/folsom','Hey,\n\nFor the first time (that I\'m aware of) we have a request to include a\nbackport on the stable branch which includes a change to the RPC API:\n\n  https://review.openstack.org/14754\n\nThis is troublesome for a couple of reasons:\n\n  1) People upgrading to a version which includes this change would \n     need to be aware that they should update their compute services\n     before updating their API services\n\n  2) While in this case we\'re backporting the first RPC API change \n     since Folsom (i.e. version 2.2 was in Folsom, this is version 2.3)\n     if we were backporting a later API version we would have to give \n     up on retaining Folsom compatibility in Grizzly\n\nIn this particular case, I\'m somewhat hopeful we might be able to figure\nout a fix which doesn\'t involve the API change but that remains to be\nseen.\n\nAny ideas?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351837244.3820.208.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 06:20:44',0,'2012-11-02 06:20:44',NULL,'[openstack-dev] Proposed RPC API change on nova stable/folsom','On Thu, 2012-11-01 at 16:34 -0400, Russell Bryant wrote:\n> On 11/01/2012 12:12 PM, Mark McLoughlin wrote:\n> > Hey,\n> > \n> > For the first time (that I\'m aware of) we have a request to include a\n> > backport on the stable branch which includes a change to the RPC API:\n> > \n> >   https://review.openstack.org/14754\n> > \n> > This is troublesome for a couple of reasons:\n> > \n> >   1) People upgrading to a version which includes this change would \n> >      need to be aware that they should update their compute services\n> >      before updating their API services\n> > \n> >   2) While in this case we\'re backporting the first RPC API change \n> >      since Folsom (i.e. version 2.2 was in Folsom, this is version 2.3)\n> >      if we were backporting a later API version we would have to give \n> >      up on retaining Folsom compatibility in Grizzly\n> > \n> > In this particular case, I\'m somewhat hopeful we might be able to figure\n> > out a fix which doesn\'t involve the API change but that remains to be\n> > seen.\n> > \n> > Any ideas?\n> \n> It looks like Vish took care of it.  The new version maintains rpc API\n> backwards compat.\n> \n> https://review.openstack.org/#/c/14754/2/nova/compute/manager.py\n\nAny RPC API changes (even backwards compatible) are a problem on the\nstable branch - users need to know to upgrade in a certain order and we\nalso have the issue with linear versioning issue on two branches\n\nCheers,\nMark.\n\n\n\n','<5092DCDF.3000004@redhat.com>',NULL),('<1351837244.3820.208.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-02 06:20:44',0,'2012-11-02 06:20:44',NULL,'[Openstack-stable-maint] [openstack-dev] Proposed RPC API\n	change on nova stable/folsom','On Thu, 2012-11-01 at 16:34 -0400, Russell Bryant wrote:\n> On 11/01/2012 12:12 PM, Mark McLoughlin wrote:\n> > Hey,\n> > \n> > For the first time (that I\'m aware of) we have a request to include a\n> > backport on the stable branch which includes a change to the RPC API:\n> > \n> >   https://review.openstack.org/14754\n> > \n> > This is troublesome for a couple of reasons:\n> > \n> >   1) People upgrading to a version which includes this change would \n> >      need to be aware that they should update their compute services\n> >      before updating their API services\n> > \n> >   2) While in this case we\'re backporting the first RPC API change \n> >      since Folsom (i.e. version 2.2 was in Folsom, this is version 2.3)\n> >      if we were backporting a later API version we would have to give \n> >      up on retaining Folsom compatibility in Grizzly\n> > \n> > In this particular case, I\'m somewhat hopeful we might be able to figure\n> > out a fix which doesn\'t involve the API change but that remains to be\n> > seen.\n> > \n> > Any ideas?\n> \n> It looks like Vish took care of it.  The new version maintains rpc API\n> backwards compat.\n> \n> https://review.openstack.org/#/c/14754/2/nova/compute/manager.py\n\nAny RPC API changes (even backwards compatible) are a problem on the\nstable branch - users need to know to upgrade in a certain order and we\nalso have the issue with linear versioning issue on two branches\n\nCheers,\nMark.\n\n\n\n','<5092DCDF.3000004@redhat.com>',NULL),('<1351875412.3820.257.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 16:56:52',0,'2012-11-02 16:56:52',NULL,'[openstack-dev] Policy on \"3rd party\" APIs and Nova','Hey\n\nAlmost exactly 6 months ago, the PPB had a discussion about 3rd party\nAPIs after a mailing list discussion on the topic:\n\n  http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html\n  https://lists.launchpad.net/openstack-poc/msg00448.html\n\nThe conclusion reached in the meeting was:\n\n  \"an OpenStack project will support an official API in it\'s core \n   implementation (the OpenStack API). other APIs will be implemented\n   external to core. the core project will expose stable, complete,\n   performant interfaces so that 3rd party APIs can be implemented in a\n   complete and performant manner.\"\n\nLet me first qualify that with some of the discussion that lead up to\nthe policy being voted on:\n\n  <vishy> jbryce: I\'m not sure that we can mandate that they must live outside\n  <vishy> jbryce: unless we are just talking ultimate goal here.\n  <vishy> jbryce: I agree with the principle that they should be there\n  <vishy> jbryce: I just don\'t know if we are technically at the point where they can\n  <jbryce> vishy: let\'s work on defining the end state of this as the goal/convention to aim for\n\ni.e. I think it\'s fair to say the \"policy\" was intended to be a\nforward-looking \"where we want to get to\" statement.\n\nAlso, the statement might seem to imply that 3rd party APIs should be\nimplemented as proxies to the OpenStack REST APIs, but actually the\nstatement wasn\'t directing an implementation choice. The other option\ndiscussed was a project exposing a \"stable, complete, performant\" python\ninterface for implementing 3rd party APIs either as a plugins or\ncompletely separate services talking to the DB and message bus.\n\n\nNow, what about Nova?\n\nNova has an implementation of the EC2 API (a \"3rd party API\") and,\nindeed, has had this since the project began ... even before the\nRackspace CloudServers API became the OpenStack API.\n\nIt seems to me that the EC2 API is a fairly popular feature, generally\nworks reasonably well and is tested by unit tests, the devstack gate\n(using devstack\'s euca exercise) and smokestack (using nova smoketests).\n\nIt\'s true there isn\'t any particular person or group of people\nconsistently working to improve the EC2 API (can that also be said of\nthe OpenStack API?) but in Folsom nova/api/ec2 did have 59 commits (4%\nof total) by 27 developers (14% of total) and the diffstat was:\n\n   6 files changed, 585 insertions(+), 688 deletions(-)\n\nPart of that work involved re-factoring some code that was common\nbetween the EC2 and OpenStack APIs.\n\nAnyway, my take is the EC2 API is a nice feature, we should be proud of\nit and we\'re successfully maintaining it without a terrible amount of\npain.\n\n\nIn theory, the PPB\'s policy decision should have prompted some move by\nNova developers to figure out what \"stable, complete, performant\"\ninterface to expose and move the EC2 API to that. Six months have passed\nwith zero progress, partly because of a lack of interest but mostly\nbecause Nova developers have a lot of other higher priority things on\ntheir plate.\n\n\nThe question reared its head again at the Grizzly summit when Joe Gordon\nlead this session:\n\n  https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2\n\nThe (or at least part of the) motivation for the session was Joe and his\nteam\'s work on a Google Compute Engine API implementation:\n\n  https://github.com/cloudscaling/nova-gce\n\nThis is implemented quite similarly to the EC2 API so the question\nbecomes \"if new 3rd party APIs can\'t be added to Nova, how do we expose\nthe appropriate APIs for those new APIs\". It was pretty clear during the\nsession that we don\'t have an answer to that.\n\n\nSo, to the point - what Nova developers wish to discuss here and at a TC\nmeeting is how we can make progress.\n\nAssuming we don\'t have the \"stable, complete, performant\" interface\nneeded for 3rd party APIs, what do we do if the GCE API is proposed for\ninclusion in Nova?\n\n\nMy opinion - the GCE work looks awesome, it\'s an exciting new feature\nand it\'s the kind of awesome new feature by awesome developers that we\nshould be facilitating.\n\nWe have a long term goal of facilitating work like this happening\noutside of Nova, but no real sign of that goal coming about in the\nmedium term.\n\nWe shouldn\'t let our idealistic long term plans get in the way of\npragmatic, exciting progress happening now.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351875412.3820.257.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-02 16:56:52',0,'2012-11-02 16:56:52',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','Hey\n\nAlmost exactly 6 months ago, the PPB had a discussion about 3rd party\nAPIs after a mailing list discussion on the topic:\n\n  http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html\n  https://lists.launchpad.net/openstack-poc/msg00448.html\n\nThe conclusion reached in the meeting was:\n\n  \"an OpenStack project will support an official API in it\'s core \n   implementation (the OpenStack API). other APIs will be implemented\n   external to core. the core project will expose stable, complete,\n   performant interfaces so that 3rd party APIs can be implemented in a\n   complete and performant manner.\"\n\nLet me first qualify that with some of the discussion that lead up to\nthe policy being voted on:\n\n  <vishy> jbryce: I\'m not sure that we can mandate that they must live outside\n  <vishy> jbryce: unless we are just talking ultimate goal here.\n  <vishy> jbryce: I agree with the principle that they should be there\n  <vishy> jbryce: I just don\'t know if we are technically at the point where they can\n  <jbryce> vishy: let\'s work on defining the end state of this as the goal/convention to aim for\n\ni.e. I think it\'s fair to say the \"policy\" was intended to be a\nforward-looking \"where we want to get to\" statement.\n\nAlso, the statement might seem to imply that 3rd party APIs should be\nimplemented as proxies to the OpenStack REST APIs, but actually the\nstatement wasn\'t directing an implementation choice. The other option\ndiscussed was a project exposing a \"stable, complete, performant\" python\ninterface for implementing 3rd party APIs either as a plugins or\ncompletely separate services talking to the DB and message bus.\n\n\nNow, what about Nova?\n\nNova has an implementation of the EC2 API (a \"3rd party API\") and,\nindeed, has had this since the project began ... even before the\nRackspace CloudServers API became the OpenStack API.\n\nIt seems to me that the EC2 API is a fairly popular feature, generally\nworks reasonably well and is tested by unit tests, the devstack gate\n(using devstack\'s euca exercise) and smokestack (using nova smoketests).\n\nIt\'s true there isn\'t any particular person or group of people\nconsistently working to improve the EC2 API (can that also be said of\nthe OpenStack API?) but in Folsom nova/api/ec2 did have 59 commits (4%\nof total) by 27 developers (14% of total) and the diffstat was:\n\n   6 files changed, 585 insertions(+), 688 deletions(-)\n\nPart of that work involved re-factoring some code that was common\nbetween the EC2 and OpenStack APIs.\n\nAnyway, my take is the EC2 API is a nice feature, we should be proud of\nit and we\'re successfully maintaining it without a terrible amount of\npain.\n\n\nIn theory, the PPB\'s policy decision should have prompted some move by\nNova developers to figure out what \"stable, complete, performant\"\ninterface to expose and move the EC2 API to that. Six months have passed\nwith zero progress, partly because of a lack of interest but mostly\nbecause Nova developers have a lot of other higher priority things on\ntheir plate.\n\n\nThe question reared its head again at the Grizzly summit when Joe Gordon\nlead this session:\n\n  https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2\n\nThe (or at least part of the) motivation for the session was Joe and his\nteam\'s work on a Google Compute Engine API implementation:\n\n  https://github.com/cloudscaling/nova-gce\n\nThis is implemented quite similarly to the EC2 API so the question\nbecomes \"if new 3rd party APIs can\'t be added to Nova, how do we expose\nthe appropriate APIs for those new APIs\". It was pretty clear during the\nsession that we don\'t have an answer to that.\n\n\nSo, to the point - what Nova developers wish to discuss here and at a TC\nmeeting is how we can make progress.\n\nAssuming we don\'t have the \"stable, complete, performant\" interface\nneeded for 3rd party APIs, what do we do if the GCE API is proposed for\ninclusion in Nova?\n\n\nMy opinion - the GCE work looks awesome, it\'s an exciting new feature\nand it\'s the kind of awesome new feature by awesome developers that we\nshould be facilitating.\n\nWe have a long term goal of facilitating work like this happening\noutside of Nova, but no real sign of that goal coming about in the\nmedium term.\n\nWe shouldn\'t let our idealistic long term plans get in the way of\npragmatic, exciting progress happening now.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1351879559.3820.268.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-02 18:05:59',0,'2012-11-02 18:05:59',NULL,'[openstack-tc] TC meeting tomorrow Tue Oct 23, 20:00 UTC','On Mon, 2012-10-22 at 09:44 -0700, Monty Taylor wrote:\n> I\'d also like a quick check in with folks on underlying distro support\n> policy and about python 2.6 policy:\n\nAny reason that openstack-dev wasn\'t included on this thread?\n\nWas about to reply, but think the discussion should be open to a wider\naudience\n\nCheers,\nMark.\n\n\n\n','<508577D8.90302@inaugust.com>',NULL),('<1351890821.3820.274.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-02 21:13:41',0,'2012-11-02 21:13:41',NULL,'[openstack-tc] TC meeting tomorrow Tue Oct 23, 20:00 UTC','On Fri, 2012-11-02 at 21:59 +0100, Thierry Carrez wrote:\n> Thierry Carrez wrote:\n> > 3rd-party API discussion... (btw we still need a thread started on\n> > openstack-dev for that).\n> \n> And now I see it was just started :)\n> \n> Would be good if we could somehow keep the discussion only on\n> openstack-dev rather than cross-posted to a moderated list.\n\nStefano made the same point and I didn\'t understand what the problem was\nfirst ... the issue is having to approve messages from folks who aren\'t\non -tc\n\nI cross-posted because TC folks really need to follow these discussions\nand I fear without the cross-posting things will just get lost in -dev\n\nCheers,\nMark.\n\n\n\n\n','<50943431.20407@openstack.org>',NULL),('<1352146326.3820.296.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-05 20:12:06',0,'2012-11-05 20:12:06',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Mon, 2012-11-05 at 14:33 -0500, Jay Pipes wrote:\n> On 11/02/2012 12:56 PM, Mark McLoughlin wrote:\n> > My opinion - the GCE work looks awesome, it\'s an exciting new feature\n> > and it\'s the kind of awesome new feature by awesome developers that we\n> > should be facilitating.\n> > \n> > We have a long term goal of facilitating work like this happening\n> > outside of Nova, but no real sign of that goal coming about in the\n> > medium term.\n> > \n> > We shouldn\'t let our idealistic long term plans get in the way of\n> > pragmatic, exciting progress happening now.\n> \n> Yeah, I mostly agree with what you\'re saying above and in the rest of\n> the post. That said, however, the rub is that while the GCE work looks\n> awesome, this whole topic came up, IIRC, because of the OCCI-compatible\n> work that had been proposed. I personally didn\'t care for the OCCI work\n> and didn\'t want it in Nova core.\n\nWhat was the issue with the OCCI work? I don\'t recall ever seeing a\npatch\n\n> While I personally wouldn\'t mind seeing the GCE work in core, because I\n> think the work is better, it sets a precedent vs. the current\n> \"exception\" of the EC2 API being in core.\n> \n> Once there is precedent, we either need to let everything in, or we need\n> to be picky about the winners and losers. The intent 6 months ago was to\n> NOT pick winners and losers intentionally, and make a statement that we\n> intended to only have the native REST API in core long-term.\n> \n> If that decision is to be reversed, are nova-core folks willing to pick\n> the winners and losers or if not, are they willing to let all comers\n> into the code base?\n\nWe pick winners and losers all the time - what features make sense, what\npatches suck, etc.\n\nCheers,\nMark.\n\n\n\n','<509814A7.1040801@gmail.com>',NULL),('<1352147700.3820.313.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-05 20:35:00',0,'2012-11-05 20:35:00',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Mon, 2012-11-05 at 12:17 -0800, John Dickinson wrote:\n> On Nov 5, 2012, at 12:12 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > On Mon, 2012-11-05 at 14:33 -0500, Jay Pipes wrote:\n> >> On 11/02/2012 12:56 PM, Mark McLoughlin wrote:\n> >>> My opinion - the GCE work looks awesome, it\'s an exciting new feature\n> >>> and it\'s the kind of awesome new feature by awesome developers that we\n> >>> should be facilitating.\n> >>> \n> >>> We have a long term goal of facilitating work like this happening\n> >>> outside of Nova, but no real sign of that goal coming about in the\n> >>> medium term.\n> >>> \n> >>> We shouldn\'t let our idealistic long term plans get in the way of\n> >>> pragmatic, exciting progress happening now.\n> >> \n> >> Yeah, I mostly agree with what you\'re saying above and in the rest of\n> >> the post. That said, however, the rub is that while the GCE work looks\n> >> awesome, this whole topic came up, IIRC, because of the OCCI-compatible\n> >> work that had been proposed. I personally didn\'t care for the OCCI work\n> >> and didn\'t want it in Nova core.\n> > \n> > What was the issue with the OCCI work? I don\'t recall ever seeing a\n> > patch\n> \n> The main issue (along with the CDMI patch in Swift) was one of support\n> and maintenance. The CDMI patch (would have) added a significant\n> amount of code, significant complexity, and the core devs and other\n> contributors weren\'t familiar enough with the spec or uses to be\n> willing to accept responsibility of maintaining it or even properly\n> reviewing it.\n\nIn the case of GCE, we\'d be welcoming a group of developers to the Nova\ndeveloper community and that group would be responsible for a\nsignificant amount of its maintenance. We shouldn\'t welcome any \"toss it\nover the wall\" style feature patches.\n\nFrankly, I\'m more concerned about the support and maintenance burden of\nsomething like the bare-metal driver currently under review for Nova.\n\nIn terms of support and maintenance, I don\'t see an API being all that\ndifferent from any other new proposed feature.\n\nMark.\n\n\n\n','<AC97173F-66E5-483D-84DB-958D9986BDD9@not.mn>',NULL),('<1352147851.3820.316.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-05 20:37:31',0,'2012-11-05 20:37:31',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Mon, 2012-11-05 at 14:15 -0600, Anne Gentle wrote:\n> It\'s not just whether nova-core is willing to test/vote/review/pick\n> but swift-core and all the other *-core, right?\n> \n> Just clarifying the scope...\n\nI don\'t follow the clarification ...\n\nAccepting a new API into Nova doesn\'t affect swift-core.\n\nIndeed, in the case of OCCI/CDMI, I don\'t see what would be wrong with\nNova accepting OCCI (because we don\'t have a stable, complete,\nperformant interface for 34d party APIs) and Swift not accepting CDMI\n(because it apparently does have such an interface).\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVETOJ+vLK1GcesrigHaz9kwgJ9OaPz9UUhTodvVRV=mCg@mail.gmail.com>',NULL),('<1352148083.3820.320.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-05 20:41:23',0,'2012-11-05 20:41:23',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Mon, 2012-11-05 at 12:29 -0800, John Dickinson wrote:\n> I agree completely. The decision in my mind is around an official,\n> non-diluted OpenStack API that we as the community control and direct.\n\nCare to elaborate on this \"non-diluted/control\" issue? It\'s additional\nto the \"support and maintenance\" issue?\n\n>  And I would like us to keep the decision we made to move 3rd party\n> APIs out of core.\n\nThe decision taken by the PPB aspired to having a \"stable, complete,\nperformant interface\" for 3rd party APIs. Nova doesn\'t have this and\nno-one is showing interest in making this happen. Meanwhile we\'re\nblocking potentially very interesting developments in the OpenStack\necosystem.\n\nMark.\n\n\n\n','<4AF2F73C-7690-4BE1-9859-B8BB79DF1963@not.mn>',NULL),('<1352149269.3820.329.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-05 21:01:09',0,'2012-11-05 21:01:09',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Mon, 2012-11-05 at 14:43 -0600, Anne Gentle wrote:\n> Regarding the scope clarification - my question is, is the TC making\n> policy that all -core projects must follow?\n\nNo, we\'re just asking the TC to recognize that Nova isn\'t ready to meet\nthe requirements necessary to follow the PPB\'s previous aspirational\ndirection and allow us to accept further 3rd party APIs.\n\n> If so, then we will need detailed definitions of what it means to\n> accept an API - code patches and reviews seem to be assumed but what\n> about test platforms? Minimum documentation?\n\nDoes this differ from other features? Do we have detailed definitions of\nwhat nova-core must require before it can accept a new virt driver?\n\n> > In terms of support and maintenance, I don\'t see an API being all that\n> > different from any other new proposed feature.\n> \n> Specifically, I don\'t think this is true - testing, releasing, and\n> documenting are all part of this support and maintenance. I don\'t\n> think we\'ll get the doc and test support we\'d need based on what I\'ve\n> observed so far with the Swift 3rd-party APIs - configuring how-tos\n> for S3 for example weren\'t put into the documentation. I also realize\n> that certain features are not being documented fully (the bare metal\n> stuff has me concerned as well).\n\nAgain, not seeing the support and maintenance difference between\nfeatures generally and APIs specifically.\n\n> What I think inclusion of more APIs, what it does is put more burden\n> on prioritizing - what do we document first? second? third? And so on.\n\nThe kind of APIs being proposed have an interesting property that other\nnew features don\'t have - they generally will have existing developer\ndocumentation.\n\ne.g. we don\'t really have much in the way of documentation for Nova\'s\nEC2 implementation AFAIK, but I assume developers lean heavily on EC2\'s\nown great documentation.\n\n> My questions relate to: beyond just the patch acceptance, what are we\n> signing (all projects) up for? It\'s not a matter of blocking but\n> wondering how to resource honestly so we can sign up for this in good\n> faith (pragmatically not visionarily). Just made that last word up.\n\nCertainly happy to discuss that generally in the context of accepting\nany large new feature into any project but it seems like something we\'ve\nlargely left up to the individual PTLs to decide up until now.\n\nAgain, I have some concerns about what we\'re signing up to with the\nbare-metal driver but, in the end, it currently falls on Vish to make\nthat call.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVH9c0nCWmP_UKFU19cDGzaB1iYtoy-hAo=3No9XUGZ4ow@mail.gmail.com>',NULL),('<1352205537.2264.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 12:38:57',0,'2012-11-06 12:38:57',NULL,'[openstack-dev] [Common] Rename rabbit_notifier to rpc_notifier.','On Tue, 2012-11-06 at 09:47 +0200, Gary Kotton wrote:\n> Hi,\n> The change is cool and understood. My concern here is that if someone \n> has deployed Folsom, when they upgrade to Grizzly then the code will be \n> broken. In the original configuration the the entry was:\n> notification_driver =quantum.openstack.common.notifier.rabbit_notifier\n> This has now been changed to:\n> notification_driver =quantum.openstack.common.notifier.rpc_notifier\n> Is this something that needs to be taken care of internally by Quantum \n> or something across OpenStack?\n\nYeah, it would be nice if we had support for the Folsom configuration\n\nIf we used entry points for loading these drivers, we could set up an\nalias like in this proposed patch:\n\n  https://review.openstack.org/15030\n\nCheers,\nMark.\n\n\n\n','<5098C091.4010802@redhat.com>',NULL),('<1352205924.2264.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 12:45:24',0,'2012-11-06 12:45:24',NULL,'[openstack-dev] [Common] Rename rabbit_notifier to rpc_notifier.','On Tue, 2012-11-06 at 12:38 +0000, Mark McLoughlin wrote:\n> On Tue, 2012-11-06 at 09:47 +0200, Gary Kotton wrote:\n> > Hi,\n> > The change is cool and understood. My concern here is that if someone \n> > has deployed Folsom, when they upgrade to Grizzly then the code will be \n> > broken. In the original configuration the the entry was:\n> > notification_driver =quantum.openstack.common.notifier.rabbit_notifier\n> > This has now been changed to:\n> > notification_driver =quantum.openstack.common.notifier.rpc_notifier\n> > Is this something that needs to be taken care of internally by Quantum \n> > or something across OpenStack?\n> \n> Yeah, it would be nice if we had support for the Folsom configuration\n> \n> If we used entry points for loading these drivers, we could set up an\n> alias like in this proposed patch:\n> \n>   https://review.openstack.org/15030\n\nI filed a bug:\n\n  https://bugs.launchpad.net/oslo/+bug/1075536\n\nMark.\n\n\n\n','<1352205537.2264.5.camel@sorcha>',NULL),('<1352208768.2264.15.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-06 13:32:48',0,'2012-11-06 13:32:48',NULL,'[OpenStack Foundation] OpenStack Foundation Event Planner','On Fri, 2012-11-02 at 18:06 -0500, Lauren Sell wrote:\n> Hello,\n> \n> I want to introduce Kathy Cacciatore, who is coming on board to\n> coordinate OpenStack activities at industry, member and global events.\n\nWelcome Kathy!\n\n...\n> As a quick update on marketing jobs at the Foundation, Kathy is\n> assuming the Event Planner position (which has now been removed from\n> the job board), but we are still actively recruiting for the Marketing\n> Manager and Marketing Coordinator positions. Please see the updated\n> job descriptions and send potential candidates here to apply --\n> http://www.openstack.org/community/jobs/?foundation=1\n\nThanks for the update Lauren\n\nCheers,\nMark.\n\n\n\n','<3F48DB16-B9F6-4764-AACE-A5422D112033@openstack.org>',NULL),('<1352210441.443712698@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-06 08:00:41',-21600,'2012-11-06 14:00:41',NULL,'[OpenStack Foundation] Invitation to training session:\n	OpenStack Board Meeting November 2, 2012','\nI believe I have followed up with everyone that volunteered to participate in the training working group, however if I have missed someone, please send me a reminder and I\'ll be sure to include you:  mark at openstack.org\n \n \n \nOn Friday, November 2, 2012 4:04pm, \"Jonathan Bryce\" <jonathan at openstack.org> said:\n\n\n\n> As Alan announced, the OpenStack Foundation Board held a Board meeting today from\n> 9:00am PDT to 11:00am PDT. The planned agenda was drafted on the wiki:\n> http://wiki.openstack.org/Governance/Foundation/02Nov2012BoardMeeting\n> \n> This meeting served as a follow on to the October 15th meeting to address several\n> important items we were not able to cover then. The Board discussed the 2013\n> budget, the 2013 election schedule and possible updates to the election process.\n> The Board also discussed ways to work jointly with the Technical Committee,\n> including around providing more detail on the incubation process and what \"core\"\n> OpenStack means. Finally, there was a brief discussion around training and\n> certification, and the Board approved the minutes from the previous meeting.\n> \n> Decisions that were made:\n> - Approved the 2013 budget\n> - Finalized the schedule for the 2013 Individual Director and Gold Director\n> Selector elections (included below)\n> - Discussed options for updates to the election process. Tim Bell, Hui Cheng and\n> Tristan Goode are pulling together some recommendations that they will be sharing\n> with the mailing list for feedback before the election period opens with\n> nominations on November 26.\n> - Mark Collier will establish a working group to help define the Foundation\'s\n> program with regard to training and certification. Anyone interested in being\n> involved should contact Mark (mark at openstack.org).\n> - Approved the October 15th Board meeting minutes\n> (http://wiki.openstack.org/Governance/Foundation/15Oct2012BoardMinutes)\n> \n> The schedule for the 2013 Board elections is as follows:\n> - November 26: Individual Member nominations open, election section of\n> openstack.org goes live with details on process and candidates\n> - December 7: Individual Member nominations close\n> - December 14: Deadline for Individual Member Nominees to complete application\n> - January 3: Gold Director Selector Election\n> - January 14: Individual Member Elections open\n> - January 18: Individual Member Elections close\n> \n> Thanks to those who took the time to join and listen in. Feel free to let us know\n> if you have any questions,\n> \n> Jonathan\n> \n> \n> On Oct 31, 2012, at 9:43 AM, Alan Clark <aclark at suse.com> wrote:\n> \n> > Note that the November 2nd meeting time is at 9:am Pacific not 9pm Mountain. \n> Sorry for the mistake am still learning to control the WebEx training center tool.\n> >\n> > Agenda for board meetings are at:\n> http://wiki.openstack.org/Governance/Foundation\n> >\n> >\n> >>>> On 10/30/2012 at 08:59 PM, <messenger at webex.com> wrote:\n> >> Greetings,\n> >> The OpenStack Board invites you to participate as an attendee in the\n> >> following online board meeting.  We will be using the WebEx Training\n> Session\n> >> tool to facilitate the meeting and audio conferencing. Please join the\n> WebEx\n> >> session then follow the instructions to either join a telephone\n> conference\n> >> service or to join via VOIP.\n> >>\n> >> Topic: OpenStack Board Meeting November 2, 2012\n> >> Host: Alan Clark\n> >> Date: Friday, November 2, 2012\n> >> Time: 9:00 pm, Mountain Daylight Time (Denver, GMT-06:00)\n> >\n> > Time: 9:00am Pacific, 4pm UTC\n> >\n> >\n> >> Session number: 928 761 237\n> >> Session password: This session does not require a password.\n> >>\n> >> -------------------------------------------------------\n> >> To join the board meeting\n> >> -------------------------------------------------------\n> >> 1. Go to\n> >>\n> https://openstack.webex.com/openstack/k2/j.php?ED=208346702&UID=1461324282&HMA\n> >> C=227314128ba9e04dccb69f5e69e6ff7daa3712c0&RT=MiM2\n> >> 2. Enter your name and email address.\n> >> 3. Enter the session password: This session does not require a password.\n> >> 4. Click \"Join Now\".\n> >> 5. Follow the instructions that appear on your screen.\n> >>\n> >> To view in other time zones or languages, please click the link\n> >>\n> https://openstack.webex.com/openstack/k2/j.php?ED=208346702&UID=1461324282&ORT\n> >> =MiM2&HMAC=227314128ba9e04dccb69f5e69e6ff7daa3712c0\n> >>\n> >>\n> >> -------------------------------------------------------\n> >> To join the session by phone only\n> >> -------------------------------------------------------\n> >> To receive a call back, provide your phone number when you join the\n> training\n> >> session, or call the number below and enter the access code.\n> >> Call-in toll number (US/Canada):1-650-479-3207\n> >> Call-in toll-free number (US/Canada):1-855-244-8681\n> >>\n> >> Having trouble dialing in? Try these backup numbers:\n> >> Call-in toll-free number (US/Canada):1-855-244-8681\n> >> Call-in toll number (US/Canada):1-650-479-3207\n> >> Global call-in numbers:\n> >>\n> https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=20834\n> >> 6702&tollFree=1\n> >> Show toll-free dialing restrictions:\n> >> http://www.webex.com/pdf/tollfree_restrictions.pdf\n> >> Access code: 928 761 237\n> >>\n> >> -------------------------------------------------------\n> >> For assistance\n> >> -------------------------------------------------------\n> >> You can contact Alan Clark at:\n> >> aclark at suse.com\n> >>\n> >>\n> >> To add this session to your calendar program (for example Microsoft\n> >> Outlook), click this link:\n> >>\n> https://openstack.webex.com/openstack/k2/j.php?AT=down&ED=208346702&EF=MA&UUID=\n> >> 1461324282&SHA2=ytiJwLnmCaBXVzZ1aMdCFWaU6dTfMYxO2gGirFWs34M%3D&RT=MiM2\n> >>\n> >>\n> >>\n> >>\n> >> http://www.webex.com\n> >>\n> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio\n> >> and any documents and other materials exchanged or viewed during the\n> session\n> >> to be recorded. By joining this session, you automatically consent to\n> such\n> >> recordings. If you do not consent to the recording, discuss your concerns\n> >> with the meeting host prior to the start of the recording or do not join\n> the\n> >> session. Please note that any such recordings may be subject to discovery\n> in\n> >> the event of litigation.\n> >\n> >\n> > _______________________________________________\n> > Foundation mailing list\n> > Foundation at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121106/f7b940a0/attachment.html>\n\n','<FDFB61DC-BBF6-456D-8EF6-B5C45B2B2A9D@openstack.org>',NULL),('<1352217930.2264.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-06 16:05:30',0,'2012-11-06 16:05:30',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','On Tue, 2012-11-06 at 14:40 +0100, Thierry Carrez wrote:\n> Anne Gentle wrote:\n> > Regarding the scope clarification - my question is, is the TC making\n> > policy that all -core projects must follow?\n> \n> We currently have a PPB-old edict that prevents projects from accepting\n> new 3rd-party APIs. Vish proposes to dissolve that edict and let all\n> projects pick 3rd-party APIs if they think they make sense for their\n> project, can be maintained etc.. So in a way, we would be removing\n> established restrictions rather than making a choice.\n\nIt may be a pedantic distinction, but what I\'m proposing (and AFAICT\nVish agrees) is just that we recognize what the PPB previously voted on\nwas aspirational rather than an edict.\n\ni.e. the project still aspires to exposing \"stable, complete, performant\ninterfaces so that 3rd party APIs can be implemented in a complete and\nperformant manner\" and that \"other APIs will be implemented external to\ncore\" but that it will take time to get there.\n\nI actually think that\'s all pretty self-evident.\n\n> The reality is a bit more complex though. As Jay mentioned, the edict\n> had for example the side benefit of making it easy to refuse 3rd-party\n> APIs (no need to pick losers and winners). The edict was also about\n> ensuring the OpenStack API was the first-class API, by encouraging\n> projects to come up with a clean internal compute API for 3rd-party APIs\n> to connect to.\n> \n> While I\'m all for letting more freedom to each project on that specific\n> matter, I would really preferred if we arrived one day to that clean\n> internal API... and I feel like removing the incentive to do it is not a\n> step in the right direction.\n\nRight, one can think of a \"no more 3rd party APIs\" edict as a way of\nforcing individual projects into creating the \"stable, complete,\nperformant\" interfaces necessary.\n\nWhat we\'re seeing in Nova is that it is not proving to be a positive\nincentive for anything. It is merely frustrating people\'s (most\nexcellent, IMHO) efforts to build support for APIs like GCE, CIMI or\nOCCI.\n\nCheers,\nMark.\n\n\n\n','<50991336.6000808@openstack.org>',NULL),('<1352218157.2264.27.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 16:09:17',0,'2012-11-06 16:09:17',NULL,'[openstack-dev] [Common] Rename rabbit_notifier to rpc_notifier.','On Tue, 2012-11-06 at 08:23 -0500, Russell Bryant wrote:\n> On 11/06/2012 07:38 AM, Mark McLoughlin wrote:\n> > On Tue, 2012-11-06 at 09:47 +0200, Gary Kotton wrote:\n> >> Hi,\n> >> The change is cool and understood. My concern here is that if someone \n> >> has deployed Folsom, when they upgrade to Grizzly then the code will be \n> >> broken. In the original configuration the the entry was:\n> >> notification_driver =quantum.openstack.common.notifier.rabbit_notifier\n> >> This has now been changed to:\n> >> notification_driver =quantum.openstack.common.notifier.rpc_notifier\n> >> Is this something that needs to be taken care of internally by Quantum \n> >> or something across OpenStack?\n> > \n> > Yeah, it would be nice if we had support for the Folsom configuration\n> > \n> > If we used entry points for loading these drivers, we could set up an\n> > alias like in this proposed patch:\n> > \n> >   https://review.openstack.org/15030\n> \n> What am I missing here?  The patch that went in still supports\n> specifying rabbit_notifier.  There is a rabbit_notifier module that just\n> acts as a pass-through to the rpc_notifier.\n> \n> https://review.openstack.org/#/c/15441/\n\nAh, it\'s me missing something. That\'s fine, my bad :)\n\nThanks,\nMark.\n\n\n\n\n','<50990F52.3010506@redhat.com>',NULL),('<1352234314.062818300@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 15:38:34',-18000,'2012-11-06 20:38:34',NULL,'[openstack-dev] PyCharm License for OpenStack','Hey devs!\n\nThe people over at JetBrains have been nice enough to grant us a new PyCharm license. I\'m sure the majority of us have settled into our current dev environment, but if you\'d like to try it out, please let me know! Their terms require that the license not be distributed through our mailing list, but if you email me I can get it to you.\n\n--Andrew\n\n\n\n',NULL,NULL),('<1352236405.2264.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-06 21:13:25',0,'2012-11-06 21:13:25',NULL,'[openstack-dev] [openstack-tc] Policy on \"3rd party\" APIs and\n	Nova','Hey\n\nI was asked to clarify exactly what motion is being proposed so that the\nTC can vote on it for next weeks meeting.\n\nWhat we\'re proposing is:\n\n  The previous aspirational statement that the PPB made in May 2012 \n  about 3rd party APIs being implemented external to core stands. \n  However, where a given project does yet have expose a \"stable, \n  complete, performant interface\" for 3rd party APIs to build on, that \n  project may choose to accept proposed new APIs in the interim if it\n  sees fit.\n\nBit of a mouthful, but I think it captures our position.\n\nCheers,\nMark.\n\nOn Fri, 2012-11-02 at 16:56 +0000, Mark McLoughlin wrote:\n> Hey\n> \n> Almost exactly 6 months ago, the PPB had a discussion about 3rd party\n> APIs after a mailing list discussion on the topic:\n> \n>   http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html\n>   https://lists.launchpad.net/openstack-poc/msg00448.html\n> \n> The conclusion reached in the meeting was:\n> \n>   \"an OpenStack project will support an official API in it\'s core \n>    implementation (the OpenStack API). other APIs will be implemented\n>    external to core. the core project will expose stable, complete,\n>    performant interfaces so that 3rd party APIs can be implemented in a\n>    complete and performant manner.\"\n> \n> Let me first qualify that with some of the discussion that lead up to\n> the policy being voted on:\n> \n>   <vishy> jbryce: I\'m not sure that we can mandate that they must live outside\n>   <vishy> jbryce: unless we are just talking ultimate goal here.\n>   <vishy> jbryce: I agree with the principle that they should be there\n>   <vishy> jbryce: I just don\'t know if we are technically at the point where they can\n>   <jbryce> vishy: let\'s work on defining the end state of this as the goal/convention to aim for\n> \n> i.e. I think it\'s fair to say the \"policy\" was intended to be a\n> forward-looking \"where we want to get to\" statement.\n> \n> Also, the statement might seem to imply that 3rd party APIs should be\n> implemented as proxies to the OpenStack REST APIs, but actually the\n> statement wasn\'t directing an implementation choice. The other option\n> discussed was a project exposing a \"stable, complete, performant\" python\n> interface for implementing 3rd party APIs either as a plugins or\n> completely separate services talking to the DB and message bus.\n> \n> \n> Now, what about Nova?\n> \n> Nova has an implementation of the EC2 API (a \"3rd party API\") and,\n> indeed, has had this since the project began ... even before the\n> Rackspace CloudServers API became the OpenStack API.\n> \n> It seems to me that the EC2 API is a fairly popular feature, generally\n> works reasonably well and is tested by unit tests, the devstack gate\n> (using devstack\'s euca exercise) and smokestack (using nova smoketests).\n> \n> It\'s true there isn\'t any particular person or group of people\n> consistently working to improve the EC2 API (can that also be said of\n> the OpenStack API?) but in Folsom nova/api/ec2 did have 59 commits (4%\n> of total) by 27 developers (14% of total) and the diffstat was:\n> \n>    6 files changed, 585 insertions(+), 688 deletions(-)\n> \n> Part of that work involved re-factoring some code that was common\n> between the EC2 and OpenStack APIs.\n> \n> Anyway, my take is the EC2 API is a nice feature, we should be proud of\n> it and we\'re successfully maintaining it without a terrible amount of\n> pain.\n> \n> \n> In theory, the PPB\'s policy decision should have prompted some move by\n> Nova developers to figure out what \"stable, complete, performant\"\n> interface to expose and move the EC2 API to that. Six months have passed\n> with zero progress, partly because of a lack of interest but mostly\n> because Nova developers have a lot of other higher priority things on\n> their plate.\n> \n> \n> The question reared its head again at the Grizzly summit when Joe Gordon\n> lead this session:\n> \n>   https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2\n> \n> The (or at least part of the) motivation for the session was Joe and his\n> team\'s work on a Google Compute Engine API implementation:\n> \n>   https://github.com/cloudscaling/nova-gce\n> \n> This is implemented quite similarly to the EC2 API so the question\n> becomes \"if new 3rd party APIs can\'t be added to Nova, how do we expose\n> the appropriate APIs for those new APIs\". It was pretty clear during the\n> session that we don\'t have an answer to that.\n> \n> \n> So, to the point - what Nova developers wish to discuss here and at a TC\n> meeting is how we can make progress.\n> \n> Assuming we don\'t have the \"stable, complete, performant\" interface\n> needed for 3rd party APIs, what do we do if the GCE API is proposed for\n> inclusion in Nova?\n> \n> \n> My opinion - the GCE work looks awesome, it\'s an exciting new feature\n> and it\'s the kind of awesome new feature by awesome developers that we\n> should be facilitating.\n> \n> We have a long term goal of facilitating work like this happening\n> outside of Nova, but no real sign of that goal coming about in the\n> medium term.\n> \n> We shouldn\'t let our idealistic long term plans get in the way of\n> pragmatic, exciting progress happening now.\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n\n','<1351875412.3820.257.camel@sorcha>',NULL),('<1352236405.2264.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2012-11-06 21:13:25',0,'2012-11-06 21:13:25',NULL,'[openstack-tc] Policy on \"3rd party\" APIs and Nova','Hey\n\nI was asked to clarify exactly what motion is being proposed so that the\nTC can vote on it for next weeks meeting.\n\nWhat we\'re proposing is:\n\n  The previous aspirational statement that the PPB made in May 2012 \n  about 3rd party APIs being implemented external to core stands. \n  However, where a given project does yet have expose a \"stable, \n  complete, performant interface\" for 3rd party APIs to build on, that \n  project may choose to accept proposed new APIs in the interim if it\n  sees fit.\n\nBit of a mouthful, but I think it captures our position.\n\nCheers,\nMark.\n\nOn Fri, 2012-11-02 at 16:56 +0000, Mark McLoughlin wrote:\n> Hey\n> \n> Almost exactly 6 months ago, the PPB had a discussion about 3rd party\n> APIs after a mailing list discussion on the topic:\n> \n>   http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html\n>   https://lists.launchpad.net/openstack-poc/msg00448.html\n> \n> The conclusion reached in the meeting was:\n> \n>   \"an OpenStack project will support an official API in it\'s core \n>    implementation (the OpenStack API). other APIs will be implemented\n>    external to core. the core project will expose stable, complete,\n>    performant interfaces so that 3rd party APIs can be implemented in a\n>    complete and performant manner.\"\n> \n> Let me first qualify that with some of the discussion that lead up to\n> the policy being voted on:\n> \n>   <vishy> jbryce: I\'m not sure that we can mandate that they must live outside\n>   <vishy> jbryce: unless we are just talking ultimate goal here.\n>   <vishy> jbryce: I agree with the principle that they should be there\n>   <vishy> jbryce: I just don\'t know if we are technically at the point where they can\n>   <jbryce> vishy: let\'s work on defining the end state of this as the goal/convention to aim for\n> \n> i.e. I think it\'s fair to say the \"policy\" was intended to be a\n> forward-looking \"where we want to get to\" statement.\n> \n> Also, the statement might seem to imply that 3rd party APIs should be\n> implemented as proxies to the OpenStack REST APIs, but actually the\n> statement wasn\'t directing an implementation choice. The other option\n> discussed was a project exposing a \"stable, complete, performant\" python\n> interface for implementing 3rd party APIs either as a plugins or\n> completely separate services talking to the DB and message bus.\n> \n> \n> Now, what about Nova?\n> \n> Nova has an implementation of the EC2 API (a \"3rd party API\") and,\n> indeed, has had this since the project began ... even before the\n> Rackspace CloudServers API became the OpenStack API.\n> \n> It seems to me that the EC2 API is a fairly popular feature, generally\n> works reasonably well and is tested by unit tests, the devstack gate\n> (using devstack\'s euca exercise) and smokestack (using nova smoketests).\n> \n> It\'s true there isn\'t any particular person or group of people\n> consistently working to improve the EC2 API (can that also be said of\n> the OpenStack API?) but in Folsom nova/api/ec2 did have 59 commits (4%\n> of total) by 27 developers (14% of total) and the diffstat was:\n> \n>    6 files changed, 585 insertions(+), 688 deletions(-)\n> \n> Part of that work involved re-factoring some code that was common\n> between the EC2 and OpenStack APIs.\n> \n> Anyway, my take is the EC2 API is a nice feature, we should be proud of\n> it and we\'re successfully maintaining it without a terrible amount of\n> pain.\n> \n> \n> In theory, the PPB\'s policy decision should have prompted some move by\n> Nova developers to figure out what \"stable, complete, performant\"\n> interface to expose and move the EC2 API to that. Six months have passed\n> with zero progress, partly because of a lack of interest but mostly\n> because Nova developers have a lot of other higher priority things on\n> their plate.\n> \n> \n> The question reared its head again at the Grizzly summit when Joe Gordon\n> lead this session:\n> \n>   https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2\n> \n> The (or at least part of the) motivation for the session was Joe and his\n> team\'s work on a Google Compute Engine API implementation:\n> \n>   https://github.com/cloudscaling/nova-gce\n> \n> This is implemented quite similarly to the EC2 API so the question\n> becomes \"if new 3rd party APIs can\'t be added to Nova, how do we expose\n> the appropriate APIs for those new APIs\". It was pretty clear during the\n> session that we don\'t have an answer to that.\n> \n> \n> So, to the point - what Nova developers wish to discuss here and at a TC\n> meeting is how we can make progress.\n> \n> Assuming we don\'t have the \"stable, complete, performant\" interface\n> needed for 3rd party APIs, what do we do if the GCE API is proposed for\n> inclusion in Nova?\n> \n> \n> My opinion - the GCE work looks awesome, it\'s an exciting new feature\n> and it\'s the kind of awesome new feature by awesome developers that we\n> should be facilitating.\n> \n> We have a long term goal of facilitating work like this happening\n> outside of Nova, but no real sign of that goal coming about in the\n> medium term.\n> \n> We shouldn\'t let our idealistic long term plans get in the way of\n> pragmatic, exciting progress happening now.\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n\n','<1351875412.3820.257.camel@sorcha>',NULL),('<1352305998.2959.28.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-07 10:33:18',-21600,'2012-11-07 16:33:18',NULL,'[openstack-dev] Less of coding standard for i18n of LOG messages','On Wed, 2012-11-07 at 23:43 +0800, Ying Chun Guo wrote:\n> First of all, there is an agreement within community that user-facing\n> string should be translated. As to LOG messages, there are arguments\n> but no consensus yet. One argument says the LOG messages are useful\n> for operators/administrators especially in the case of abnormal\n> behavior and is certainly accessible to users and therefore just like\n> all user-facing text, thus LOG messages should be translated. The\n> opposing argument could say that LOG is primarily useful for\n> developers, developers can read English LOG, and LOG in different\n> languages will block the communication between developers and users,\n> thus LOG should not be translated.\n\nIt\'s also worth pointing out that another argument for log messages\nremaining in English is that it will be easier to search the web for\nthose log messages, whereas if they\'re translated, discussion about them\nmay end up being fractured.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<OF62A67D28.C8415B5F-ON48257AAF.004E5D19-48257AAF.00565BBC@cn.ibm.com>',NULL),('<1352310993.2959.32.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-07 11:56:33',-21600,'2012-11-07 17:56:33',NULL,'[openstack-dev] Less of coding standard for i18n of LOG messages','On Wed, 2012-11-07 at 12:26 -0500, Eric Windisch wrote:\n> In fact, now that I think abut it, is there a reason we use _() from\n> callers instead of just having the log formatter wrap this for us? \n\nTechnical reasons.  The ones I can think of off the top of my head:\n\n     1. The tools which extract strings to be translated expect those\n        strings to be wrapped in _().\n     2. The LOG.<level>() methods are often passed pre-formatted\n        strings, i.e.:\n\n                LOG.error(_(\"message here with %s\") % variable)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<F75ABDC57E71448AB39063F568584ACA@cloudscaling.com>',NULL),('<1352375823.2264.97.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-08 11:57:03',0,'2012-11-08 11:57:03',NULL,'[openstack-dev] The future of Incubation and Core','Hey\n\nI think too much of this discussion has been about the fairly arbitrary\nnames we have for different classes of projects. The term \"Core\" isn\'t\nactually all that useful to us in the discussion, or more generally,\nbecause everyone has their own idea of what the term means.\n\nThere are two important things being discussed here - our vision for the\ncoordinated OpenStack releases and the rules around the use of the\nOpenStack trademark.\n\nThey are different things - a project being included in the coordinated\nrelease does not mean it has to be deployed in order for a provider to\nuse the trademark.\n\nFor the sake of focusing the discussion, we should ignore the trademark\nquestion for now and focus on our vision for the coordinated release.\n\nI see our coordinated release as being a cloud provider\'s toolbox of\ngreat projects that are designed to work well together built by a\ncommunity with a unified mission.\n\nTo be included in the coordinated release, a project needs to meet set\nof criteria which we should clearly define[1].\n\nIf a project looks promising, it is accepted into Incubation for a full\nrelease cycle so that is fully prepared to be included in the next\ncoordinated release. Projects must go through at least one release cycle\nas an Incubated Project, but multiple cycles may be required if it turns\nout it needs more time to be fully ready for inclusion.\n\nCheers,\nMark.\n\n[1] - Example of what our criteria for inclusion in the coordinated\nrelease might look like:\n\n  - Development process - follows the standard OpenStack development \n    process; everything from git, gerrit, launchpad, team meetings, \n    wiki, blueprints, milestone releases, etc.\n\n  - Community - has a solid community of folks contributing to the \n    project, a community that looks like it has longevity\n\n  - Openness - the project\'s community not only follows our development \n    process, but is truly committed to open development and welcoming \n    new leaders into its community\n\n  - Fit - the software needs to \"fit\" with the rest of OpenStack. I \n    don\'t think we should be overly prescriptive about this (e.g. \n    \"projects absolutely must be written in Python\") but deviations \n    from Openstack norms (like use of Python) would need to be \n    justified and considered carefully.\n\n  - Integration - as well as being a good fit for OpenStack, new \n    project\'s should also integrate well with existing projects where \n    that makes sense.\n\n  - Scope - new projects, almost by definition, will expand the scope \n    of the OpenStack release but we should be growing the scope in \n    careful, measured ways. Maybe someday OpenStack might have a e.g. \n    CDN project, but we should only consider including such a thing \n    where it is a sensible, incremental expansion of OpenStack\'s scope. \n    In the case of the CDN example, that might be where OpenStack \n    already does PaaS really well and a CDN to support applications \n    deployed on our PaaS solution is an obvious need for providers \n    already using our PaaS solutions. Clearly, that\'s a long, long way \n    off if it ever happens at all.\n\n\n\n','<509A8F09.8000004@openstack.org>',NULL),('<1352376433.2264.105.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-08 12:07:13',0,'2012-11-08 12:07:13',NULL,'[openstack-dev] The future of Incubation and Core','On Thu, 2012-11-08 at 10:42 +0100, Thierry Carrez wrote:\n> OK, let\'s try to summarize the different views so far:\n> \n> 1. core+supported (russellb)\n> Let Core be anything you want (required set, necessary set...), but have\n> a Supported category for everything that is a positive addition to\n> OpenStack.\n> \n> 2. Product core (gabrielhurley)\n> Do not have an intermediary category which could carry more duties than\n> rights, but have an inclusive definition of Core that would include\n> necessary/recommended projects.\n> \n> 3. Required core (mtaylor)\n> Same as \"product core\", + make all the core stuff a required use if you\n> are to call yourself an \"OpenStack cloud\"\n> \n> 4. IaaS core (notmyname)\n> Do not have an intermediary category, and have Core only include pure\n> IaaS projects.\n\nAs I said, I think we\'re discussing two things - \"vision for our\ncoordinated release\" and \"requirements for use of the trademark\" - it\'d\nbe interesting to figure out what the four views are saying about those\ntwo issues.\n\nI\'m not sure I fully understand peoples\' views enough to summarize that,\nbut ...\n\nOn the vision for the coordinated release:\n\n 1. core+supported (russellb)\n Very inclusive criteria for inclusion.\n \n 2. Product core (gabrielhurley)\n 3. Required core (mtaylor)\n More exclusive criteria for inclusion.\n\n 4. IaaS core (notmyname)\n Very exclusive criteria for inclusion.\n\nCheers,\nMark.\n\n\n\n','<509B7EA0.1060608@openstack.org>',NULL),('<1352378126.2264.129.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-08 12:35:26',0,'2012-11-08 12:35:26',NULL,'[openstack-dev] The future of Incubation and Core','On Wed, 2012-11-07 at 19:47 +0000, Gabriel Hurley wrote:\n> We need to step back for a minute and question the supposition that a\n> \"non-core but blessed by OpenStack\" category is benefical. I don\'t\n> believe it is.\n\nMy understanding of the \"non-core but blessed by OpenStack\" idea is \"not\nrequired for the use of the trademark, but part of the coordinated\nrelease\" where the criteria for inclusion is the coordinated release is\nquite broad.\n\n> There are serious implications to creating a space which is not core\n> but is blessed by the foundation/TC. It sends mixed messages to the\n> community and has a significant impact on the ecosystem. All the\n> concerns the TC has about crushing ecosystem competition when debating\n> incubation apply just as much to creating a second \"non-core\" space.\n>\n> There should be Core, and then there should be a thriving community\n> which is supported equally by the foundation. Nothing in between. We\n> can\'t play favorites there.\n\nI agree that the effect on our ecosystem should be considered when\ndeciding on the inclusion of a project in the coordinated release.\n\nHowever, where a project fills a gaping hole in our coordinated release,\nwhere the project is a great \"fit\" for OpenStack and where the project\nis quite clearly already a part of the OpenStack project rather than the\necosystem, then leaving it in the ecosystem just to encourage\ncompetition seems very artificial.\n\nHas including Horizon in the coordinated release crushed competition (or\neven potential for competition) in the ecosystem? It probably has to an\nextent, but it has been hugely beneficial for OpenStack and we are still\nseeing some competition to Horizon in the ecosystem.\n\n> I also think we\'re placing too much weight on the value of CI\n> infrastructure and release management. Projects have been doing that\n> for themselves forever and there\'s lots of free (or nearly free)\n> services for Open Source projects readily available.\n\nIt\'s not so much about the value these resources bring to the individual\nproject, but that an individual project must use those resources to be\nconsidered part of the OpenStack project.\n\nSo, Incubation providing access to those resources is a way of allowing\nthe individual project join the broader OpenStack project in preparation\nfor inclusion in the coordinated release.\n\n> Ultimately making another category is just a way to dodge the hard\n> issue of what is truly core. Whether core is Iaas or a viable cloud at\n> all levels of the stack... that\'s the real debate here.\n> \n> I agree (even at peril to my own project\'s status) that Horizon\n> (currently core), Ceilometer (currently incubated) and Heat (incubated\n> largely by a plurality of abstentions) fall above the realm of IaaS.\n> However I think that Core would be excruciatingly lacking without the\n> inclusion of higher-layer projects for two main reasons:\n> \n> \n> 1.       Higher-layer projects are the only check on the unity of the\n> \"core\" projects. Projects that span the APIs of Nova, Glance, Swift\n> and Quantum are the ones that discover the pain points. They\'re the\n> ones that can work towards OpenStack feeling cohesive. Without those\n> OpenStack is just a trademark and a bunch of arbitrary code.\n> \n> \n> \n> 2.       Higher-layer projects (particularly Horizon) improve the\n> discoverability, usability and visibility of OpenStack. At this point\n> most new users considering OpenStack experience Horizon first. When\n> people want to demo OpenStack\'s functionalities, they use Horizon.\n> That\'s quite telling. Humans are inherently visual creatures and the\n> majority of the future users of \"cloud\" are not the type who want\n> arcane CLIs. Folks from Amazon, Rackspace and any other cloud provider\n> will tell you that services experience a huge increase in usage when\n> they integrate into the dashboard. Losing that from Core benefits\n> nobody.\n\nThese are great arguments for including more projects in the coordinated\nrelease, I agree.\n\n> As a final argument, let me flip things the other way and suppose that\n> Horizon was designated a \"supported\" project. If that entails the\n> arduous Gerrit review process and having to clear major decisions with\n> the broader community rather than just letting my team keep building\n> great things... that\'s enough of a disincentive that I\'d rather not be\n> \"supported\". I\'ll go build something autonomously, promote it\n> aggressively, make it dead-simple to install, and if it\'s cool people\n> will use it. People will use it in spite of a core component if it\'s\n> better in every metric.\n\nIf the \'H\' release included Nova, Swift, Glance, Keystone, Quantum,\nCinder, Horizon, Heat and Ceilometer but only say Nova, Swift and\nKeystone were referenced in the trademark rules, that\'s ok by you right?\n\nAgain, I don\'t the \"Core\" term is helping anything here.\n\nIf we define the coordinated release as containing those projects which\nwe\'re only willing to label \"Core\" we end up with a much too exclusive\ncriteria for inclusion.\n\nIf we say the coordinated release contains both \"Core\" and \"Extra\"\nclasses of projects, we arbitrarily make some projects feel second\nclass.\n\nProjects are either in the coordinated release or not, and we should\nhave fairly broad criteria for inclusion that would welcome projects\nlike Horizon, Heat and Ceilometer.\n\n> Long story short, I don\'t see value in creating another category; I\n> think we need to fundamentally define Core, let things be in or out,\n> and then devote the foundation\'s resources to supporting the *entire*\n> ecosystem, not just a handful of projects.\n\nI think I mostly agree except:\n\n  1) \"Core\" is proving to be a divisive term, we should instead \n     define our vision for the coordinated release.\n\n  2) I think I\'d draw the line between \"what makes sense in the \n     release\" and \"what should live in the ecosystem\" slightly\n     differently.\n\nCheers,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F2362930E24A@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1352386097.58934.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-11-08 06:48:17',-28800,'2012-11-08 14:48:17',NULL,'[Openstack-operators] About NIC','Hi all,\n\nI\'m following;\nInstalling OpenStack Essex (2012.1) on Ubuntu 12.04 (\"Precise Pangolin\")\nhttp://www.hastexo.com/resources/docs/installing-openstack-essex-20121-ubuntu-1204-precise-pangolin\n\nto install OpenStack on Ubuntu 12.04 desktop 64bit.\n\nAccording to \"Step 1: Prepare your System\"\nhttp://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin/step-1-prepare-your-system\n\nit needs 2 NICs for the test.? Please advise;\n\n1) \n\nCan I have one NIC to continue the test? ? If NO then I\'ll install an additional NIC on this PC.\n\n2)\nI suppose\n\nauto eth1\niface eth1 inet static\naddress 192.168.22.1\n.....\n....\n\nis to connect Internet?? The setting on my router is \"192.168.0.0 up\".? Can I set the address according to the settings on my router?\n\n3)\nI suppose eth0 is for internal connection.? Should I set the entries exactly identical to the instruction?\n\nTIA\n\nB.R.\nStephen L\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121108/07acac79/attachment.html>\n\n',NULL,NULL),('<1352394343.2689.YahooMailNeo@web125101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-11-08 09:05:43',-28800,'2012-11-08 17:05:43',NULL,'[Openstack-operators] About NIC','Hi,\n\nThanks for your advice. \n\nI see.? eth0 and eth1 are virtual NIC.\n\nPerformed following steps;\n\n# ifconfig\neth0????? Link encap:Ethernet? HWaddr 00:26:18:44:b6:1a? \n????????? inet addr:192.168.0.10? Bcast:192.168.0.255? Mask:255.255.255.0\n????????? inet6 addr: fe80::226:18ff:fe44:b61a/64 Scope:Link\n????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n????????? RX packets:2437 errors:0 dropped:0 overruns:0 frame:0\n????????? TX packets:2216 errors:0 dropped:0 overruns:0 carrier:1\n????????? collisions:0 txqueuelen:1000 \n????????? RX bytes:2427087 (2.4 MB)? TX bytes:344276 (344.2 KB)\n????????? Interrupt:42 \n\nlo??????? Link encap:Local Loopback? \n????????? inet addr:127.0.0.1? Mask:255.0.0.0\n????????? inet6 addr: ::1/128 Scope:Host\n????????? UP LOOPBACK RUNNING? MTU:16436? Metric:1\n????????? RX packets:368 errors:0 dropped:0 overruns:0 frame:0\n????????? TX packets:368 errors:0 dropped:0 overruns:0 carrier:0\n????????? collisions:0 txqueuelen:0 \n????????? RX bytes:61669 (61.6 KB)? TX bytes:61669 (61.6 KB)\n\n# apt-get install bridge-utils\n\n# gedit /etc/network/interfaces\nauto lo\niface lo inet loopback\n\nauto eth0 \n??? iface eth0 inet static\n??? address 192.168.0.11\n??? network 192.168.0.0\n??? netmask 255.255.255.0\n??? broadcast 192.168.0.255\n??? gateway 192.168.0.1\n\nauto eth1\n??? iface eth1 inet static\n??? address 192.168.22.1\n??? network 192.168.22.0\n??? netmask 255.255.255.0\n??? broadcast 192.168.22.255\n\n# /etc/init.d/networking restart\n?* Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces\n?* Reconfiguring network interfaces...?????????????????????????????????????????? * Disconnecting iSCSI targets\n?? ...done.\n?* Stopping iSCSI initiator service\n?? ...done.\n?* Starting iSCSI initiator service iscsid\n?? ...done.\n?* Setting up iSCSI targets\n?? ...done.\nssh stop/waiting\nssh start/running, process 3301\nCannot find device \"eth1\"\nFailed to bring up eth1.\n???????????????????????????????????????????????????????????????????????? [ OK ]\n\n# ifconfig\neth0????? Link encap:Ethernet? HWaddr 00:26:18:44:b6:1a? \n????????? inet addr:192.168.0.11? Bcast:192.168.0.255? Mask:255.255.255.0\n????????? inet6 addr: fe80::226:18ff:fe44:b61a/64 Scope:Link\n????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n????????? RX packets:2839 errors:0 dropped:0 overruns:0 frame:0\n????????? TX packets:2693 errors:0 dropped:0 overruns:0 carrier:2\n????????? collisions:0 txqueuelen:1000 \n????????? RX bytes:2532982 (2.5 MB)? TX bytes:401990 (401.9 KB)\n????????? Interrupt:42 \n\nlo??????? Link encap:Local Loopback? \n????????? inet addr:127.0.0.1? Mask:255.0.0.0\n????????? inet6 addr: ::1/128 Scope:Host\n????????? UP LOOPBACK RUNNING? MTU:16436? Metric:1\n????????? RX packets:552 errors:0 dropped:0 overruns:0 frame:0\n????????? TX packets:552 errors:0 dropped:0 overruns:0 carrier:0\n????????? collisions:0 txqueuelen:0 \n????????? RX bytes:91141 (91.1 KB)? TX bytes:91141 (91.1 KB)\n\n\n\n# cat /etc/udev/rules.d/70-persistent-net.rules \n.......\n.......\n# PCI device 0x1969:/sys/devices/pci0000:00/0000:00:06.0/0000:02:00.0 (ATL1E)\nSUBSYSTEM==\"net\", ACTION==\"add\", DRIVERS==\"?*\", ATTR{address}==\"00:26:18:44:b6:1a\", ATTR{dev_id}==\"0x0\", ATTR{type}==\"1\", KERNEL==\"eth*\", NAME=\"eth0\"\n\nSorry I forgot how to edit this file.? I did it many times in the past.\n\nPlease advise.? TIA\n\nB.R.\nStephen L\n\n\n\n\n\n\n>________________________________\n> From: Razique Mahroua <razique.mahroua at gmail.com>\n>To: Stephen Liu <satimis at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Friday, November 9, 2012 12:07 AM\n>Subject: Re: [Openstack-operators] About NIC\n> \n>\n>Hey there, please find my answers above?\n>Nuage & Co - Razique Mahroua?razique.mahroua at gmail.com\n> \n>\n>Le 8 nov. 2012 ? 15:48, Stephen Liu <satimis at yahoo.com> a ?crit :\n>\n>Hi all,\n>>\n>>\n>>I\'m following;\n>>Installing OpenStack Essex (2012.1) on Ubuntu 12.04 (\"Precise Pangolin\")\n>>http://www.hastexo.com/resources/docs/installing-openstack-essex-20121-ubuntu-1204-precise-pangolin\n>>\n>>\n>>to install OpenStack on Ubuntu 12.04 desktop 64bit.\n>>\n>>\n>>According to \"Step 1: Prepare your System\"\n>>http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin/step-1-prepare-your-system\n>>\n>>\n>>it needs 2 NICs for the test.? Please advise;\n>>\n>>\n>>1) \n>>\n>>Can I have one NIC to continue the test? ? If NO then I\'ll install an additional NIC on this PC.Yes you can only have one NIC, make sure to update all the settings accordingly.\n>You can also create an alias (eth0:0) or a new ip on the interface (ip addr add XXXX/Y dev eth0)\n>\n>\n>\n>>\n>>2)\n>>I suppose\n>>\n>>\n>>auto eth1\n>>iface eth1 inet static\n>>address 192.168.22.1\n>>.....\n>>....\n>>\n>>\n>>is to connect Internet?? The setting on my router is \"192.168.0.0 up\".? Can I set the address according to the settings on my router?It depends on what you are trying yo achieve, but if you have an extra interface, it won\'t need to access to the internet, eth0 would be good for that\n>\n>\n>>\n>>3)\n>>I suppose eth0 is for internal connection.? Should I set the entries exactly identical to the instruction?Nope, totally up to you. I usually have three interfaces : eth0 for internet acces, eth1 for internal network and eth3 for rescue/admin access\n>\n>\n>\n>>\n>>TIAsure :)\n>\n>\n>\n>>\n>>B.R.\n>>Stephen L\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121108/97aaabc9/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121108/97aaabc9/attachment.jpg>\n\n','<E3601006-5EF6-4F77-8EFB-5A0CB2CF33C7@gmail.com>',NULL),('<1352509746.24346.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-10 02:09:06',3600,'2012-11-10 01:09:06',NULL,'[openstack-dev] [Nova] Reviews and core members','On Fri, 2012-11-09 at 16:16 -0800, Vishvananda Ishaya wrote:\n> Hey Everyone,\n> \n> It\'s that time again. We are falling behind with over 100 reviews in the nova queue[1]. It would be great if more people were involved in the review process. Here are the stats from the last thirty days for core members:\n> \n> Kevin Mitchell \"klmitch\": 207\n> Michael Still \"mikalstill\": 197\n> Vish Ishaya \"vishvananda\": 175\n> Russell Bryant \"russellb\": 160\n> Mark McLoughlin \"markmc\": 113\n> Josh Kearney \"jk0\": 90\n> Johannes Erdfelt \"johannes.erdfelt\": 84\n> Chris Behrens \"cbehrens\": 64\n> P?draig Brady \"p-draigbrady\": 55\n> Matt Dietz \"cerberus\": 36\n> Yon Mao\"yunmao\": 58\n> Dan Prince \"dan-prince\": 22\n> Rick Harris \"rconradharris\": 12\n> Christopher MacGown \"0x44\": 6\n> Brian Waldon \"bcwaldon\": 5\n> Trey Morris \"tr3buchet\": 5\n> Sandy Walsh \"sandy-walsh\": 1\n> Devin Carlen \"devcamcar\": 0\n> Mark Washenberger \"markwash\": 0\n> \n> Thanks to everyone who has been active! Based on these numbers I think it is fairly clear that there are some people who have moved on to other things. I\'d like to propose we cut the following people from core:\n> \n> Christopher MacGown, Brian Waldon, Trey Morris, Sandy Walsh, Devin Carlen, Mark Washenberger.\n> \n> As before, please keep in mind that this isn\'t intended to question the amazing work that all of these people have done for nova.  Nova-core is a review team, so we have to make sure the people on it actually have time to do reviews. If anyone jumps back in and starts reviewing we can fast-track them back in.\n> \n> I\'d also like to propose that we add the following active reviewers to the core team:\n> \n> Dan Smith \"danms\": 84\n> Has been doing a lot of work with russelb on no-db-compute\n> \n> Sean Dague \"sdague-b\": 82\n> Has been leading a lot of the api related work and api-sample testing\n> \n> Joe Gordon \"joe-gordon0\": 48\n> Has been doing lots of general cleanup and feature work around host aggregates\n> \n> Nova Core members: Please +1 each person you think should join nova core.\n\nAll sounds good to me, +1 to everything here.\n\nCheers,\nMark.\n\n\n\n','<1B98D951-E3FC-44B9-8779-E1474B7DBEEB@gmail.com>',NULL),('<1352517831.34059204.1386663630991.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-10 03:20:30',-18000,'2013-12-10 08:20:30',NULL,'[Openstack] [Ceilometer] Ceilometer not fetching Nova Compute\n Notifications compute.instance.create.start/end','\nHi Sravani,\n\nHere are the compute notification event types that ceilometer is actually\ninterested in (modulo wildcard expansion):\n\n * \'compute.instance.*\'\n\n * \'compute.instance.delete.samples\'\n\n * \'scheduler.run_instance.scheduled\'\n\nSee respectively:\n\n * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L73\n\n * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L161\n\n * https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/notifications.py#L54\n\nSo, clearly ceilometer is only interested in a subset of these notifications,\nhence that\'s all that it processes.\n\nCheers,\nEoghan\n\n\n----- Original Message -----\n> Hi All,\n> \n> I\'m trying to catch Nova Compute Notifications in Ceilometer\n> \n> I have Openstack installed on Ubuntu 13.04 using devstack.\n> \n> While launching an instance, Nova Compute is sending the required\n> notifications to notifications.info queue.\n> \n> \n> The same could be seen in the Nova Compute logs:\n> \n> 2013-12-03 12:19:07.617 DEBUG nova.openstack.common.rpc.amqp\n> [req-32a523c5-ebeb-4885-88e9-986918ab7f86 demo demo]\n> Sending compute.instance.create.start on notifications.info from\n> (pid=5418) notify\n> /opt/stack/nova/nova/openstack/common/rpc/amqp.py:621\n> ..\n> ....\n> \n> 2013-12-03 12:19:11.313 DEBUG nova.openstack.common.rpc.amqp\n> [req-32a523c5-ebeb-4885-88e9-986918ab7f86 demo demo]\n> Sending compute.instance.create.end on notifications.info from\n> (pid=5418) notify\n> /opt/stack/nova/nova/openstack/common/rpc/amqp.py:621\n> \n> \n> But the ceilometer is unable to fetch these notifications from\n> notifications.info. Instead it is fetching only\n> compute.instance.update notification.\n> \n> The same could be seen in the ceilometer-agent-notification:\n> \n> 2013-12-03 12:19:06.999 14017 DEBUG ceilometer.notification [-]\n> notification u\'compute.instance.update\' process_notification\n> /opt/stack/ceilometer/ceilometer/notification.py:124\n> 2013-12-03 12:19:07.000 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline degree.temperature.current\n> 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline meter_pipeline\n> 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline cpu_pipeline\n> 2013-12-03 12:19:07.001 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline instance_pipeline\n> 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline degree.temperature.current\n> 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline meter_pipeline\n> 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline cpu_pipeline\n> 2013-12-03 12:19:07.002 14017 AUDIT ceilometer.pipeline [-] Flush\n> pipeline instance_pipeline\n> \n> I am facing the same issue with the below mentioned Compute notifications\n> too:\n> compute.instance.delete.start/.end\n> compute.instance.shutdown.start/.end\n> compute.instance.power_off.start/.end\n> \n> \n> Please find my Configuration setup in the below mentioned files:\n> \n> [nova.conf]\n> \n> firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver\n> compute_driver = libvirt.LibvirtDriver\n> libvirt_cpu_mode = none\n> libvirt_type = qemu\n> rabbit_password = root\n> rabbit_host = <IP>\n> rpc_backend = nova.openstack.common.rpc.impl_kombu\n> notification_driver = nova.openstack.common.notifier.rpc_notifier\n> notification_driver = ceilometer.compute.nova_notifier\n> notify_on_state_change = vm_and_task_state\n> notification_topics = notifications\n> topics = notifications\n> control_exchange = openstack\n> notify_api_faults = true\n> \n> \n> [ceilometer.conf]\n> \n> verbose = True\n> debug = True\n> notification_topics = notifications\n> rabbit_password = root\n> rabbit_host = <IP>\n> rpc_backend = ceilometer.openstack.common.rpc.impl_kombu\n> nova_control_exchange = nova\n> default_notification_level=INFO\n> notification_driver = nova.openstack.common.notifier.rpc_notifier\n> \n> So, what changes can be done for Ceilometer to fetch the all the\n> notifications which the Nova Compute sends on the notifications.info ?\n> \n> Kindly let me know if any more information is required.\n> \n> Thank You.\n> \n> Regards,\n> Sravani M\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAOdv3z-sBuh20cqy+bOM7wZg=wjOQb1jNC4QOw6uPVY2jd_VXA@mail.gmail.com>',NULL),('<1352673435.24346.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-11 22:37:15',0,'2012-11-11 22:37:15',NULL,'[openstack-dev] [CI] Gerrit downtime 2012-11-11','On Sun, 2012-11-11 at 21:16 +0000, Jeremy Stanley wrote:\n> This was completed successfully earlier today and we\'ve seen no\n> related issues since. If you notice a problem you think may be\n> associated with this work, please don\'t hesitate to let us know in\n> #openstack-ci or as a follow-up to the list.\n> \n> Be mindful that the following projects were renamed:\n> \n>  * from openstack/openstack-core to openstack/oslo\n\nHmm, the plan was to rename openstack-common.git to oslo-incubator.git\n\nMark.\n\n\n\n','<20121111211633.GX22041@yuggoth.org>',NULL),('<1352704618.24346.23.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-12 07:16:58',0,'2012-11-12 07:16:58',NULL,'[openstack-dev] [CI] Gerrit downtime 2012-11-11','On Mon, 2012-11-12 at 00:01 +0000, Jeremy Stanley wrote:\n> On 2012-11-11 23:22:49 +0000 (+0000), Jeremy Stanley wrote:\n> > Clark and I have resolved to go ahead and fix this now, as Mark\'s\n> > message does definitely match what was discussed in the Project\n> > meeting.\n> [...]\n> \n> This is complete (pending approval of a trivial .gitreview update\n> awaiting the oslo-incubator core devs[1]). Someone with rights on\n> openstack/openstack-common in Launchpad will probably also want to\n> rename the project there.\n\nThanks Clark and Jeremy. The launchpad project is already set up:\n\n   https://launchpad.net/oslo\n\nCheers,\nMark.\n\n\n\n','<20121112000151.GB22041@yuggoth.org>',NULL),('<1352723458.8968.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 12:30:58',0,'2012-11-12 12:30:58',NULL,'[Openstack-stable-maint] Diablo/Essex bitrot job notifications','Hi James,\n\nJust re-thinking an element of this bitrot job notifications thing ...\n\nThe openstack-stable-maint list is being spammed with notifications of\nDiablo/Essex failures:\n\n  http://lists.openstack.org/pipermail/openstack-stable-maint/2012-November/date.html\n  https://jenkins.openstack.org/view/Bitrot/\n\nBut the stable-maint team is only responsible for the stable/folsom\nbranch. There are separate essex-maint and diablo-maint teams.\n\nThe Diablo/Essex failures should be addressed, but I\'d prefer to not\nhave those notifications hit the stable-maint list - I fear we\'re just\ntraining the team to ignore the notifications and we\'ll miss any Folsom\nfailures when they crop up.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1352732895.8968.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-12 15:08:15',0,'2012-11-12 15:08:15',NULL,'[openstack-dev] Oslo Grizzly Plans','Hi\n\nI\'ve been a bit tardy gathering together our plans for Oslo in Grizzly,\napologies.\n\nThe first thing we\'re doing is renaming the project from\nopenstack-common to Oslo. The Oslo project[1], core[2] and driver[3]\nteams, blueprints[4] and bugs[5] have all been sorted out.\n\nThe openstack-common git repository has been renamed to oslo-incubator.\nThe idea is that this repository is a stepping stone for new APIs before\nbeing properly released in an Oslo library package.\n\nWhich brings us to the next part of Oslo\'s Grizzly plan ... releasing\nour first library package. We hope to release oslo-config as part of the\ngrizzly-1 milestone. Two things remain before we\'re ready to do that -\nfirstly, the work going on to re-write cfg to use argparse[7] and,\nsecondly, agreeing on what versioning scheme[8] Oslo releases will\nfollow.\n\nThe other set of APIs which could potentially be promoted out of\noslo-incubator during Grizzly is the RPC and messaging APIs. However,\nthere was some discussion at the Design Summit about making these APIs\nmore generic messaging APIs and there is a set of outstanding cleanup\ntasks associated with the rpc-api-review[9] blueprint. We also have\ndecided we need to version the RPC message format[10]. Finally, there is\nongoing discussion around whether Kombu as a default RPC driver makes\nsense[11].\n\nKevin Mitchell has done great work implementing a new language for\npolicy specifications[12]. This work is already merged. Kevin also has\nsome ideas to help with documenting policies[13].\n\nNext on the list is adding basic service infrastructure[14] into Oslo.\nAngus Salkeld has done some great work kicking this off and our focus\nshould be on having the various projects attempt to adopt the APIs we\nhave added to oslo-incubator since the Folsom release. Angus has also\nbeen working on making Oslo\'s WSGI code more closely match Nova\'s\ncurrent implementation[15] with a view to having a number of projects\nadopt these APIs.\n\nThierry plans to move rootwrap into Oslo[16] in time for grizzly-2.\nSince Nova, Cinder and Quantum are all using rootwrap, this would be a\nbig step forward.\n\nThere are a number of other blueprints that haven\'t yet owners or a\nclear plan for Grizzly, but we may yet seem them come together in good\ntime for the release!\n\nThanks,\nMark.\n\n[1] - https://launchpad.net/oslo\n[2] - https://launchpad.net/~oslo-core\n[3] - https://launchpad.net/~oslo-drivers\n[4] - https://blueprints.launchpad.net/oslo\n[5] - https://bugs.launchpad.net/oslo\n[6] - https://github.com/markmc/oslo-config\n[7] - https://blueprints.launchpad.net/oslo/+spec/cfg-argparse\n[8] - https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning\n[9] - https://blueprints.launchpad.net/oslo/+spec/rpc-api-review\n[10] - https://blueprints.launchpad.net/oslo/+spec/version-rpc-messages\n[11] - https://blueprints.launchpad.net/oslo/+spec/no-kombu-default\n[12] - https://blueprints.launchpad.net/oslo/+spec/new-policy-language\n[13] - https://blueprints.launchpad.net/oslo/+spec/self-documenting-policies\n[14] - https://blueprints.launchpad.net/oslo/+spec/service-infrastructure\n[15] - https://blueprints.launchpad.net/oslo/+spec/wsgi-common\n[16] - https://blueprints.launchpad.net/oslo/+spec/common-rootwrap\n\n\n\n',NULL,NULL),('<1352733042.8968.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-12 15:10:42',0,'2012-11-12 15:10:42',NULL,'[openstack-dev] New oslo-core team member','Hey\n\nI\'m delighted to say that Michael Still has volunteered to join the\noslo-core team and the rest of the team are delighted to have him on\nboard.\n\nThanks Michael!\n\nMark.\n\n\n\n',NULL,NULL),('<1352804553.21623.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 06:02:33',-18000,'2012-11-13 11:02:33',NULL,'[openstack-dev] oslo-incubator [was Re: [CI] Gerrit downtime\n 2012-11-11]','On Mon, 2012-11-12 at 09:13 -0800, heckj wrote:\n> Jeremy\'s already made the GIT move to change oslo over to\n> oslo-incubator, but I\'d like to seriously reconsider that move.\n> Presumably we\'ll need to move it again when you want to stop calling\n> it incubator\n\nAs Vish said, this repo will continue to be named oslo-incubator into\nthe long term.\n\nThe idea is that if some code is being copied and pasted between\nprojects right now, the first step is to move the code into\noslo-incubator and get all projects onto the same version of the code\nvia the \"managed copy and paste\" update.py mechanism.\n\nOnce in oslo-incubator, we work on getting the code to have a stable,\nsupportable API so that we can release it as a normal library package\nwith a commitment to backwards compatibility around it.\n\nWhen the API is ready for a library release, we either create a new\nlibrary that installs into the \'oslo\' namespace package or add it to an\nexisting library. Either way, it moves out of oslo-incubator at that\npoint and switch to using it as a normal library API.\n\nThe point of calling the repo oslo-incubator is to reinforce the idea\nthat code isn\'t intended to live their forever. It\'s a stepping stone\ntowards a proper library release.\n\nI think this will all become more obvious to everyone after we do our\nfirst library release. We\'re starting with oslo-config once some last\nminute things are wrapped up:\n\n  https://github.com/markmc/oslo-config\n\nCheers,\nMark.\n\n\n\n','<CD15F4EF-3BAA-4EF9-A1F9-2312F0E4D0FD@mac.com>',NULL),('<1352836599.21623.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 14:56:39',-18000,'2012-11-13 19:56:39',NULL,'[openstack-dev] oslo-incubator','Hey\n\nOn Tue, 2012-11-13 at 07:02 -0800, James E. Blair wrote:\n> Mark McLoughlin <markmc at redhat.com> writes:\n> \n> > When the API is ready for a library release, we either create a new\n> > library that installs into the \'oslo\' namespace package or add it to an\n> > existing library. Either way, it moves out of oslo-incubator at that\n> > point and switch to using it as a normal library API.\n> >\n> > The point of calling the repo oslo-incubator is to reinforce the idea\n> > that code isn\'t intended to live their forever. It\'s a stepping stone\n> > towards a proper library release.\n> >\n> > I think this will all become more obvious to everyone after we do our\n> > first library release. We\'re starting with oslo-config once some last\n> > minute things are wrapped up:\n> >\n> >   https://github.com/markmc/oslo-config\n> \n> Thanks for the clarification.  Your last link suggests some questions\n> about the details of the process of splitting off a stable library from\n> incubation.\n> \n> Are you planning on continuing to host the development of libraries in\n> the project infrastructure, with the tree in /markmc just a platform for\n> doing an initial import into Gerrit?\n\nRight, that was literally a first experiment - it should move to\nopenstack infrastructure when it\'s ready\n\n> The tree to which you linked contains only one commit with no\n> development history of the files in it.  I think it would be better to\n> clone the repo and rewrite the history to remove irrelevant files\n> leaving the history of the final files intact.\n\nThat\'s a good point, will do.\n\n> We\'ve done this a few\n> times when we broke out projects (such as jenkins-job-builder and\n> gerritlib) from the openstack-ci-puppet project.\n> \n> Additionally, the openstack-common project still exists in Launchpad.  I\n> noticed you moved all the bugs to olso, however, new ones have been\n> reported since then.\n\nThanks, I\'ve moved them now.\n\n> I think to avoid confusion, we should delete the\n> openstack-common project, or at least disable all its features and\n> change the description to point people at oslo.\n\nI\'m up for that - do you have any specifics on what launchpad allows on\nthis front (apart from just updating the description)?\n\n> And finally, once this is all hashed out, it might be a good idea to\n> have a wiki page describing the Oslo intent and process.\n\nYeah, I\'ll move this:\n\n  http://wiki.openstack.org/CommonLibrary\n\nto /Oslo and update it to reflect the latest thinking. It\'s not too out\nof date, though.\n\nCheers,\nMark.\n\n\n\n','<87obj1tujm.fsf@meyer.lemoncheese.net>',NULL),('<1352847119.2959.185.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 16:51:58',-21600,'2012-11-13 22:51:58',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','On Tue, 2012-11-13 at 21:50 +0000, Joe Heck wrote:\n> Guang brought up the same need (and I think his team at HP is alrealdy\n> doing it) - so I wanted to get some feedback on the contracts that you\n> (Kevin & Guang) are after to support making auth_token something\n> that\'s stable enough to be subclassed (and to nail down those\n> interfaces so we don\'t accidentally break them in the future). What\n> hooks or methods do your needs for subclasses have today?\n\nWhat I particularly care about is certain extension data that may be\nincluded in the token verification response.  What I\'m after with my\nreview (https://review.openstack.org/#/c/16002) is to make that data\navailable to another piece of middleware following auth_token in the\nWSGI stack; this other piece of middleware would translate that\nextension data into particular headers (as well as make some more calls\nto our in-house version of Keystone to pick up some other important\ndata).  I chose this route because it allows me to avoid having to\neither write my own auth_token middleware or having to maintain a set of\npatches to auth_token in-house.  I admit that directly subclassing the\nmiddleware did not occur to me, but it\'s not clear that the current\ndesign of the middleware lends itself to that.\n\n> Guang mentioned how keystone handles EC2 token validation today -\n> perhaps breaking auth_token middleware into two separate filters,\n> token_validator and context_builder.\n\nI think such a breakdown would provide an alternate solution to my\nproblem; however, we need to think carefully about it.  One of my other\nimportant concerns is some header sanitizing, for instance; I have\nseveral headers that I would add that need to be stripped out of the\nincoming request, not to mention some other headers that simply need to\nbe removed.  In one case, the best way to describe the headers that need\nto be stripped is with a wildcard, i.e., all headers that start with a\nparticular string.\n\nAs I say, the above breakdown would work fine; however, I thought I\'d\nalso suggest another approach: some way to incorporate plugins into the\nsequence.  That is, you could have some optional configuration option to\nsubstitute out the token validation, and some other one?perhaps an\niter_entry_points()-based loop?that would perform the context building.\n(I don\'t necessarily think that this is a good approach, I\'m just laying\nit out there for other people to brainstorm with.)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<0545CD046FA0FC4198AC808CA43D32812AC7766C@BLUPRD0511MB438.namprd05.prod.outlook.com>',NULL),('<1352891073.21623.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 06:04:33',-18000,'2012-11-14 11:04:33',NULL,'[openstack-dev] The future of Incubation and Core - a motion','On Wed, 2012-11-07 at 17:40 +0100, Thierry Carrez wrote:\n\n> We need to discuss all this in the next two weeks before delegates of\n> the TC will join a committee with Board of Directors delegates to come\n> to a final decision on this. So let the public discussion begin.\n\nI think this was a really excellent discussion, kudos to all.\n\nThe TC should have an agreed direction when we talk to the Board and\nwhen a decision is reached with the Board, that should come back and be\nvoted on by the TC.\n\ni.e. the TC should vote on a direction now and then vote on the detailed\ndecision later.\n\nHere\'s a first attempt at a \"direction motion\" for the TC to vote on:\n\n  The concepts of \"what is core\" and \"what is in OpenStack\" have been \n  conflated until now. The TC cares far more about the process for new\n  projects to be included in the coordinated release than it cares about\n  which projects are required to be used by providers in order to access\n  the trademark.\n\n  We would like to take an inclusive but measured approach to accepting\n  new OpenStack projects. We should evaluate any given proposed project\n  on whether it embraces our values and processes, is useful to\n  OpenStack users, well integrated with other projects and represents a\n  sensible broadening of the scope of OpenStack.\n\n  We see Incubation as a trial period where promising projects have the \n  opportunity to demonstrate their suitability for inclusion in our \n  coordinated releases.\n\n  We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n  bylaws as being solely related to trademark guidelines. We would be \n  happy to see the term \"Core\" fall into disuse and for the Foundation \n  to simply maintain a list of projects required for trademark usage.\n\nPlease feel free to suggest changes to this motion or, indeed, propose a\nmotion describing a different approach.\n\nCheers,\nMark.\n\n\n\n','<509A8F09.8000004@openstack.org>',NULL),('<1352903859.21623.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 09:37:39',-18000,'2012-11-14 14:37:39',NULL,'[openstack-dev] The future of Incubation and Core - a motion','On Wed, 2012-11-14 at 13:19 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > Here\'s a first attempt at a \"direction motion\" for the TC to vote on:\n> > \n> >   The concepts of \"what is core\" and \"what is in OpenStack\" have been \n> >   conflated until now. The TC cares far more about the process for new\n> >   projects to be included in the coordinated release than it cares about\n> >   which projects are required to be used by providers in order to access\n> >   the trademark.\n> \n> That\'s the main point for me. By separating the two issues (\"what is\n> developed within openstack\" and \"what is core openstack\"), we clearly\n> separate what is BoD responsibility and what is TC responsibility, which\n> is a great way to avoid conflict between the two governance bodies\n> (which is what we are being asked to proactively resolve here).\n\nYep.\n\n> >   We would like to take an inclusive but measured approach to accepting\n> >   new OpenStack projects. We should evaluate any given proposed project\n> >   on whether it embraces our values and processes, is useful to\n> >   OpenStack users, well integrated with other projects and represents a\n> >   sensible broadening of the scope of OpenStack.\n> \n> Note that this still doesn\'t give crystal-clear guidelines on how to\n> judge what is promising/complementary/useful. Even if we don\'t have to\n> care about trademark anymore, we might still need to come up with more\n> defined guidelines for acceptation than personal gut feeling...\n\nAbsolutely - the TC needs to make those criteria very clear. A starting\npoint might be what I wrote up in the footnote of this mail:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002470.html\n\nHowever, I think those criteria are the responsibility of the TC. We\njust need to explain to the Board the rough idea we have for these\ncriteria. Details can come later.\n\n> >   We see Incubation as a trial period where promising projects have the \n> >   opportunity to demonstrate their suitability for inclusion in our \n> >   coordinated releases.\n> \n> A consequence of that is we would judge if the project scope is\n> promising/complementary/useful for OpenStack at the moment the project\n> applies for incubation. And we would promote it out of incubation if it\n> matured enough to be included in the full next release cycle. I\n> personally think that\'s OK (removes the risk of following the whole\n> incubation process for nothing).\n\nYep.\n\n> >   We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n> >   bylaws as being solely related to trademark guidelines. We would be \n> >   happy to see the term \"Core\" fall into disuse and for the Foundation \n> >   to simply maintain a list of projects required for trademark usage.\n> \n> I\'m not sure we should recommend that the \"Core\" term falls into disuse.\n> If the BoD wants to keep using \"Core\" as meaning \"part of the\n> coordinated release AND required for trademark use\" (which is what the\n> bylaws say, emphasis is mine), then I\'m perfectly OK with it.\n\nYeah, me too. Mostly.\n\nHowever, changing the commonly understood definition of a term can be\nharder than just dropping the term and adopting a new term with the new\ndefinition.\n\n> What I think we actually want is to redefine \"OpenStack projects\" as\n> being \"Services + Library + Gating + Supporting\" (instead of Core +\n> Library + Gating + Supporting), with \"OpenStack Services\" being the\n> projects sharing the same release cycle. Have incubation be the trial\n> period to prove you can become an official OpenStack Service. Then let\n> the BoD pick which of those \"OpenStack projects\" they want to consider\n> \"core\" for trademark use.\n\nDo we really need to have these classifications in the bylaws?\n\nThe set of \"OpenStack projects\" is whatever the TC chooses to include.\nWe may classify those projects, but a new project doesn\'t have to fit\ninto an existing class to be accepted.\n\ni.e. if a new project comes along that doesn\'t nicely fit into the\n\"Services\" class, I don\'t think we necessarily need to revisit all this\nagain with the Board.\n\nHow does this update sound?\n\n  The concepts of \"what is core\" and \"what is in OpenStack\" have been \n  conflated until now. The TC cares far more about the process for new\n  projects to be included in the coordinated release than it cares about\n  which projects are required to be used by providers in order to access\n  the trademark.\n\n  We would like to take an inclusive but measured approach to accepting\n  new OpenStack projects. We should evaluate any given proposed project\n  on a well defined set of criteria like whether it embraces our values\n  and processes, is useful to OpenStack users, well integrated with\n  other projects and represents a sensible broadening of the scope of\n  OpenStack.\n\n  We see Incubation as a trial period where promising projects have the \n  opportunity to demonstrate their suitability for inclusion in our \n  coordinated releases.\n\n  We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n  bylaws as being solely related to trademark guidelines. The Foundation\n  should simply maintain a list of projects required for trademark \n  usage. We would be happy for that list to be called \"Core Projects\" \n  or for a new name to be chosen to describe that list.\n\nCheers,\nMark.\n\n\n\n','<50A38C60.6030909@openstack.org>',NULL),('<1352906848.26393.YahooMailNeo@web125104.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-11-14 07:27:28',-28800,'2012-11-14 15:27:28',NULL,'[Openstack-operators] about creating LVM volume group called\n	nova-volumes','Hi all,\n\n\nUbuntu 12.04 desktop\n\nHow to create LVM volume group called nova-volumes\n\nWhether just to run;\n\n$ sudo addgroup nova-volumes\n?\n\nwithout user?\n\n\n\n',NULL,NULL),('<1352910545.58855.YahooMailNeo@web125106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-11-14 08:29:05',-28800,'2012-11-14 16:29:05',NULL,'[Openstack-operators] about creating LVM volume group called\n	nova-volumes','Hi,\n\n\nThanks for your advice.\n\nThis is a dualboot system, Ubuntu/Fedora.? I installed Ubuntu first and then Fedora, both on LVM, IIRC.\n\n# fdisk -l\nDisk /dev/sda: 160.0 GB, 160041885696 bytes\n255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors\nUnits = sectors of 1 * 512 = 512 bytes\nSector size (logical/physical): 512 bytes / 512 bytes\nI/O size (minimum/optimal): 512 bytes / 512 bytes\nDisk identifier: 0x0002f734\n\n?? Device Boot????? Start???????? End????? Blocks?? Id? System\n/dev/sda1?? *??????? 2048????? 194559?????? 96256?? 83? Linux\n/dev/sda2????????? 196606?? 156444671??? 78124033??? 5? Extended\n/dev/sda3?????? 156444672?? 157468671????? 512000?? 83? Linux\n/dev/sda4?????? 157468672?? 312580095??? 77555712?? 8e? Linux LVM\n/dev/sda5????????? 196608?? 117381119??? 58592256?? 83? Linux\n/dev/sda6?????? 117383168?? 136912895???? 9764864?? 83? Linux\n/dev/sda7?????? 136914944?? 156444671???? 9764864?? 82? Linux swap / Solaris\n\n# lsblk\nNAME?? MAJ:MIN RM?? SIZE RO TYPE MOUNTPOINT\nsda????? 8:0??? 0 149.1G? 0 disk \n??sda1?? 8:1??? 0??? 94M? 0 part /boot\n??sda2?? 8:2??? 0???? 1K? 0 part \n??sda3?? 8:3??? 0?? 500M? 0 part \n??sda4?? 8:4??? 0??? 74G? 0 part \n??sda5?? 8:5??? 0? 55.9G? 0 part /\n??sda6?? 8:6??? 0?? 9.3G? 0 part /home\n??sda7?? 8:7??? 0?? 9.3G? 0 part [SWAP]\n\nIs there connection between them and the LVM volume group nova-volumes ?\n\nB.R.\nStephen L\n\n\n\n\n----- Original Message -----\n> From: Christian Berendt <berendt at b1-systems.de>\n> To: openstack-operators at lists.openstack.org\n> Cc: \n> Sent: Thursday, November 15, 2012 12:01 AM\n> Subject: Re: [Openstack-operators] about creating LVM volume group called nova-volumes\n> \n> On 11/14/2012 04:27 PM, Stephen Liu wrote:\n>>  How to create LVM volume group called nova-volumes\n>> \n>>  Whether just to run;\n>> \n>>  $ sudo addgroup nova-volumes\n> \n> First you have to create a physical volume, for example pvcreate /dev/xvdb1. Now \n> you can assign this physical volume to a new volume group by using vgcreate \n> nova-volumes /dev/xvdb1.\n> \n> If you haven\'t installed lvcreate, vgcreate, .. do it with apt-get install \n> lvm2.\n> \n> You can find more details here: \n> http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)\n> \n> Christian.\n> \n> -- Christian Berendt\n> Solution Architect\n> Tel: +49 171 5542175\n> Mail: berendt at b1-systems.de\n> \n> B1 Systems GmbH\n> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de\n> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<50A3C058.3030200@b1-systems.de>',NULL),('<1352912816.2959.209.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 11:06:56',-21600,'2012-11-14 17:06:56',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','On Wed, 2012-11-14 at 16:46 +0000, Yee, Guang wrote:\n> Sure, we can have a generic header_sanitizer filter sitting in front\n> of token_validator so the pipeline would look something like this\n\nAre you talking about in the WSGI pipeline?  That wasn\'t exactly what I\nwas envisioning, and it wouldn\'t completely solve my problem.  If you\'re\njust talking about the \"pipeline\" that is the sequence of calls in\n__call__(), OTOH, that\'s fine; we just need to figure out the proper\ninterface.\n\n> header_sanitizer: removes the given set of headers from the request.\n> Headers to be removed are configured in the filter section.\n> token_validator: does token caching (including cache encryption) if\n> necessary; validates the token using a set of configurable protocols\n> (i.e. http, https, pki, etc); and sets the raw token in the\n> environment.\n\nWell, again, this sounds like using the pipeline; and if you\'re setting\nthe raw token in the environment, well, that\'s essentially what my patch\ndoes?\n\n> context_builder: builds the default Keystone context from the raw\n> token by setting the X_USER_ID, X_TENANT_ID headers, etc.\n> <3rd party context builder>: additional header/environment\n> manipulation\n\n>From your description, these would end up being other pieces of\nmiddleware, and this essentially matches the approach I was attempting\nwith my patch.\n\n> We should have a \"contrib\" folder in python-keystoneclient to stash\n> the 3rd party middlerware filters. When a 3rd party middleware filter\n> becomes mainstream, we\'ll promote it to core/default in the next\n> release.\n\nHrm.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<C73B35E94B12854596094F2CA866854950ADE0F9@G4W3292.americas.hpqcorp.net>',NULL),('<1352918834.2959.215.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 12:47:14',-21600,'2012-11-14 18:47:14',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','On Wed, 2012-11-14 at 17:33 +0000, Yee, Guang wrote:\n> Yes WSGI pipeline. How else are you intend to use auth_token middleware?\n> \n> Looking at the changes\n> \n> https://review.openstack.org/#/c/16002/1/keystoneclient/middleware/auth_token.py\n> \n> You are basically setting the extensions data in the headers right?\n> You should be able to sanitize the X_<USER|TENANT|TOKEN>_EXTENSION\n> headers in header_sanitizer and set them in your own extension context\n> builder. What am I missing?\n\nI have gotten somewhat confused.  16002 is my review and was the\napproach I was shooting for, but heckj pushed back on that and brought\nit to the list to see if there were suggestions on other possible\nimplementations; I had thought his suggested implementation was to\nsubclass the auth_token middleware and try to solve my problem that way.\n\nIf we like 16002, I\'m quite happy with that approach; I can do\neverything I need to do by just implementing one more piece of\nmiddleware.  If that\'s not a desirable approach, I can suggest that we\nstuff the entire token validation response into the wsgi environment\n(not a header), which would also meet my needs.  If we want to use a\nsubclassing approach, we need some further modification to the existing\nauth_token middleware to make that work, but that basically amounts to\nsome refactoring, and I should again be able to make that work.  I just\nneed to know which approach we are going to end up taking in the end :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<C73B35E94B12854596094F2CA866854950ADE249@G4W3292.americas.hpqcorp.net>',NULL),('<1352976599.16124.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-15 05:49:59',-18000,'2012-11-15 10:49:59',NULL,'[Openstack-stable-maint] Proposing garyk for stable-maint team','Hmm, I somehow forgot to pull the trigger on this ... I\'ve added Gary to\nthe team now.\n\nWelcome Gary and thanks for all your efforts!\n\nCheers,\nMark.\n\nOn Thu, 2012-11-01 at 09:26 -0700, Dan Wendlandt wrote:\n> Yes, Gary is taking the lead as the maintainer of the stable branch in\n> Quantum, so having him be part of the team is very valuable.\n> \n> \n> Dan\n> \n> \n> On Thu, Nov 1, 2012 at 9:03 AM, Eoghan Glynn <eglynn at redhat.com>\n> wrote:\n>         \n>         \n>         ----- Original Message -----\n>         > Hey,\n>         >\n>         > I figure I\'d abuse our new mailing list even though we set\n>         it up for\n>         > Jenkins notifications :)\n>         >\n>         > Gary has been doing a tonne of work identifying fixes to\n>         backport to\n>         > Quantum\'s stable/folsom:\n>         >\n>         >   https://review.openstack.org/#/q/branch:stable/folsom\n>         +owner:garyk,n,z\n>         >\n>         > I think he\'s showing good judgement about what constitutes a\n>         suitable\n>         > fix for the stable branch. Any objections to adding him to\n>         > stable-maint?\n>         \n>         \n>         +1 ... IMO the more domain-expertise available to\n>         stable-maint, the better.\n>         \n>         Cheers,\n>         Eoghan\n>         \n>         _______________________________________________\n>         Openstack-stable-maint mailing list\n>         Openstack-stable-maint at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n>         \n> \n> \n> \n> \n> -- \n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> Dan Wendlandt \n> Nicira, Inc: www.nicira.com\n> twitter: danwendlandt\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> \n> \n> \n\n\n\n\n','<CA+0XJm-riydLAs15-GbDcPEJFUvDhXwanFH1u+hUYxEUZ1tbCQ@mail.gmail.com>',NULL),('<1352998771.2959.222.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 10:59:31',-21600,'2012-11-15 16:59:31',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','On Thu, 2012-11-15 at 09:56 -0500, Adam Young wrote:\n> OK, if I understand correctly, there are two distinct issues getting \n> mixed here.\n> \n> 1.  Handling tokens in HTTP environments.\n> 2.  Extending the data that is carried in the Auth token signed document.\n> \n> My gut feeling is that additional Headers is a mistake.  The payload of \n> the signed messages should be extracted only once, expanded, and added \n> to the WSGI context.  Anything that needs to consume the data downstream \n> should read it as Python objects, not as strings out of headers.  I \n> never really understood the rationale for additional custom headers from \n> validate.\n\nThe reason I chose the headers route, rather than the wsgi environment\nroute, was because of an original design goal of the auth_token\nmiddleware.  In retrospect, it\'s not necessary for my change to have\nbeen done the way I did, and placing the extracted token validation into\nthe wsgi environment makes sense.  However, in answer to your statement,\nabout custom headers, maybe it\'d be worth mentioning the design goal, as\nI understand it, of how auth_token was designed.\n\nIn short, the auth_token middleware was designed so that it could be run\nfrom a proxy, rather than directly in the WSGI pipeline.  The idea was\nto allow for a case where you have a reverse proxy, which performs the\nauthentication check, then forwards the HTTP request (with the added\nauthentication headers) on to the actual service running on another host\nentirely.  In addition, using the headers allows for alternate\nauthentication implementations; as long as they set the same headers,\nyou can use any authentication backend you want.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50A5028C.4070003@redhat.com>',NULL),('<1353001321.2959.235.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 11:42:01',-21600,'2012-11-15 17:42:01',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','On Thu, 2012-11-15 at 12:19 -0500, Adam Young wrote:\n> I think it complicates things.  I\'d rather use the auth token headers we \n> have, or focus on heading back toward standard headers.\n\nThe application I\'m working on is an internal application, and I really\nneed the extension data from the verification response.  I really don\'t\ncare how I get it?these extension headers I propose in 16002 will work\nfine, as would putting the verification response into the WSGI\nenvironment or even rearchitecting auth_token.py to be easier to\nsubclass.  I just need the data, and 16002 seemed like the least-cost\nmeans of getting it at the time.\n\n> However, you do bring up an interesting use case: offloading the token \n> validation does make sense in some setups, and I am not sure how we \n> would want to tie in with the WSGI spec in those cases.  My suspicion is \n> that there is a better way than customer headers.  If, for example, \n> someone had already done the LDAP lookup for groups (AuthZ) in a \n> Kerberos (AuthN) implementation,  that information gets filtered at the \n> Proxy. I don\'t know of a standard way of passing that information on the \n> the WSGI App.  Have you done the research to show that there is not good \n> way to do this?\n\nHave I done any research on what headers people are using for\ntransferring authentication results?  No; so far as I know, there is no\nspec for that.  Further, we\'re talking about a protected path (between a\nproxy and the final backend implementation), so it\'s not 100% clear to\nme that we need a standard as developed by someone else; I think our use\nof x-user-id, x-user-name, x-tenant-id, x-tenant-name, etc. is perfectly\nacceptable for this, and valid as a spec.  (In fact, I know of no other\nsystem that even has the concept of a tenant/user division, though that\nmakes absolutely perfect sense in our use case.)  The only real question\nis, what about people that need to include other, internally-derived\ndata through that protected path?  How can they get access to extended\ninformation included in the verification response?  How they inject it\ninto the protected path should be up to them, but they need to get to\nthat data, and that\'s where the conversation came from?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50A5243F.9000401@redhat.com>',NULL),('<1353015059.2959.240.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 15:30:59',-21600,'2012-11-15 21:30:59',NULL,'[openstack-dev] [KEYSTONE] subclassing auth_token middleware','OK, I have uploaded a different review\n(https://review.openstack.org/#/c/16230/) which uses an alternate\napproach: it places the verification response into the WSGI environment,\nin the \"keystone.token_info\" variable.  This is substantially simpler\nthan my original approach and allows me to get to the information I\nneed?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<0545CD046FA0FC4198AC808CA43D32812AC7766C@BLUPRD0511MB438.namprd05.prod.outlook.com>',NULL),('<1353088621.16124.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 17:57:01',0,'2012-11-16 17:57:01',NULL,'[openstack-dev] The future of Incubation and Core - a motion','Hi Anne,\nOn Fri, 2012-11-16 at 08:17 -0600, Anne Gentle wrote:\n> Okay, thanks Mark for giving us some good food for thought. I would\n> like to propose a different set of 3rd and 4th paragraphs in the\n> \"direction motion\" for us to consider. The first two paragraphs are\n> great.\n> \n> ---\n> \n> We see Incubation as a category for projects who would like to have a\n> trial period to share resources and integrate with other OpenStack\n> projects. While we as a technical committee need time to evaluate\n> projects for inclusion in the OpenStack shared resource set (for\n> example, release management, integrated testing and releases,\n> continuous integration, documentation, Summit discussion time, and so\n> on),\n\nI think this is what we all understand Incubation to be about and it\'s\nnot really up for debate with the Board.\n\n>  there should be an end-result for an Incubation period to result\n> in a final destination that is not related to all the current\n> privileges given to Core projects.\n\nI think this is the bit where you\'re really trying to make a different\nproposal, but I don\'t fully understand it.\n\nMy motion basically says that the end-resource of Incubation is \"part of\nthe OpenStack releases\" or \"not part of the OpenStack releases\".\n\nWhat other end-result do you see?\n\n> We see trademark privileges as unrelated of the day-to-day work needed\n> to create and maintain related, integrated OpenStack projects. Because\n> trademark is irrelevant to the other privileges given to a Core\n> project, having the term \"Core OpenStack Project\" in section 4.1.b of\n> the bylaws related to trademark is unnecessary.\n\nI don\'t think we\'re really differing, but the point I\'m trying to\nemphasize with:\n\n  We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n  bylaws as being solely related to trademark guidelines. The Foundation\n  should simply maintain a list of projects required for trademark \n  usage. We would be happy for that list to be called \"Core Projects\" \n  or for a new name to be chosen to describe that list.\n\nis that \"yes, you the Foundation Board need a list of projects required\nfor trademark usage\" but that we (the TC) don\'t need to be a part of\nmaintaining that list nor do we care what the list is called.\n\nI guess what I\'m saying is that if we\'re to vote on two different\nmotions, it needs to be really clear where the motions differ beyond\njust wording.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVEgUZf87tFka4gVWMyTFTekXTKn5T2r_xvXgjkC2K7w8Q@mail.gmail.com>',NULL),('<1353163496.16124.50.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-17 14:44:56',0,'2012-11-17 14:44:56',NULL,'[Openstack-stable-maint] test_killed_worker_recover failure [was\n Re: Build failed in Jenkins: periodic-nova-python26-stable-folsom #46]','Just highlighting the traceback for future reference\n\nMight be a non-deterministic test, in which case we\'ll see the nightly\nfail occasionally\n\nCheers,\nMark.\n\nOn Fri, 2012-11-16 at 00:50 +0000, OpenStack Jenkins wrote:\n\n> ======================================================================\n> FAIL: test_killed_worker_recover (nova.tests.integrated.test_multiprocess_api.MultiprocessWSGITest)\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_multiprocess_api.py\",> line 113, in test_killed_worker_recover\n>     start_workers = self._spawn()\n>   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_multiprocess_api.py\",> line 85, in _spawn\n>     self.assertEqual(len(workers), self.workers)\n> AssertionError: 1 != 2\n> >>  raise self.failureException, \\\n>           (None or \'%r != %r\' % (1, 2))\n\n\n\n\n','<29007330.64.1353027058054.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1353163687.16124.52.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-17 14:48:07',0,'2012-11-17 14:48:07',NULL,'[Openstack-stable-maint] test_interrupt_avoids_respawn_storm\n failure [was Re: Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #46]','Another failure at the same time as the Nova failure - something\nhappening in Jenkins at the time to cause this?\n\nCheers,\nMark.\n\nOn Fri, 2012-11-16 at 00:37 +0000, OpenStack Jenkins wrote:\n\n> ======================================================================\n> ERROR: Ensure an interrupt signal does not cause a respawn storm.\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 61, in test_interrupt_avoids_respawn_storm\n>     execute(cmd, raise_error=True)\n>   File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 255, in execute\n>     raise RuntimeError(msg)\n> RuntimeError: Command kill -INT 10263 10262 did not succeed. Returned an exit code of 1.\n> \n> STDOUT: \n> \n> STDERR: kill: 1: No such process\n\n\n\n\n','<802408847.62.1353026271947.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1353163884.16124.54.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-17 14:51:24',0,'2012-11-17 14:51:24',NULL,'[Openstack-stable-maint] keystoneclient version issues [was Re:\n Build failed in Jenkins: periodic-tempest-devstack-vm-cinder #40]','On Sat, 2012-11-17 at 00:08 +0000, OpenStack Jenkins wrote:\n\n> Processing dependencies for horizon==2013.1\n> error: Installed distribution python-keystoneclient 0.2.0 conflicts with requirement python-keystoneclient>=0.1.2,<0.2\n\nAny ideas what changed here to cause this?\n\nCheers,\nMark.\n\n\n\n','<131148736.79.1353110883660.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1353169613.16124.91.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-17 16:26:53',0,'2012-11-17 16:26:53',NULL,'[OpenStack Foundation] Board discussing how to improve the\n Individual Director election process, community input wanted','On Tue, 2012-11-13 at 06:17 -0700, Alan Clark wrote:\n> Informal conversations after the Summit led the Board, as a first\n> step, to establish a sub-committee composed of primarily Individual\n> Members.\n\nAFAICT, this sub-committee was composed of Tristan Goode, Tim Bell, Rob\nHirschfeld, Hui Cheng, Toby Ford and Troy Toman.\n\nConcerns have been expressed about the election process since August and\nour response has been to:\n\n  * have the board appoint a sub-committee consisting of directors who\n    were elected using the current election process\n\n  * not make the existence of that sub-committee publicly known\n\n  * not invite any of those community members who worked to make\n    constructive suggestions about the issue on this list in the past\n\n  * publish the proposals mere days before they were to be adopted\n\nI\'m personally not into conspiracy theories and always assume good\nfaith, but is it not obvious to everyone how bad this looks?\n\nIt would have been quite straightforward to look over these archives:\n\n  http://lists.openstack.org/pipermail/foundation/2012-October/thread.html\n\nthen ask those making constructive contributions whether they want to\nparticipate in the sub-committee, publish the etherpad from the very\nstart and encourage the sub-committee to involve the mailing list in the\ndiscussion at all stages.\n\n> An etherpad detailing all of the potential options explored and\n> discussed is at\n> https://etherpad.openstack.org/Board-2012-VotingProposals. \n\nRegardless of the above, thanks and kudos to those who worked on this.\nIt looks like you worked hard to include all proposals made on the\nmailing list and weight them carefully.\n\n> Firstly, for the August 2012 election, four questions were produced\n> from mailing list input and put to each election candidate, some of\n> whom responded and some did not. It is the Board\'s recommendation that\n> we develop this into a compulsory procedure where a nominated\n> candidate is required to make a clear statement of the candidate\'s\n> contribution to OpenStack.\n\nVery positive but IMHO is, at first glance, orthogonal to the concerns\nabout voter behaviour.\n\nIn the previous election, only Yujie Du and Rob Hirschfeld were elected\nwithout answering those questions (although Rob did blog about his\ncandidacy).\n\nPerhaps the concern we\'re trying to address is that if a candidate is\nelected without making it clear what they\'re standing for, it becomes\nhard for everyone to understand post-election why they were elected?\n\n> Secondly, the Board would like to more clearly inform the electorate\n> on the reasons for individual members of the Board and explain their\n> role, the importance of diversity on the Board, be that international,\n> cultural, technological, gender or otherwise, the role of the\n> Individual members for who and or what they represent, and provide\n> guidance for members to use these criteria to assess their voting\n> choice.\n>\n> Thirdly, the Board asks that all organisations act honourably, be\n> respectful and demonstrate responsibility and guide their staff to\n> vote according to the best interests of the Community, and not their\n> organisation. OpenStack\'s life blood is the Community.\n\nGreat. Let\'s make sure to have an open discussion about both sets of\nguidelines in advance of the election.\n\n...\n> Fourthly, the Board is exploring options not requiring by-law changes\n> and that fall within the current cumulative voting structure which\n> will help to create a balanced representation of candidates from\n> affiliated organisations, independents and minorities.\n\nThis is confusing. The board is exploring options other than those\nproposed by the sub-committee?\n\nCheers,\nMark.\n\n\n\n','<50A1E602020000CC0003323F@novprvoes0310.provo.novell.com>',NULL),('<1353170883.16124.105.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-17 16:48:03',0,'2012-11-17 16:48:03',NULL,'[openstack-dev] The future of Incubation and Core - a motion','On Fri, 2012-11-16 at 14:14 -0600, Anne Gentle wrote:\n> Hi Mark,\n> Good points, I\'ll try to further delineate where I see differences.\n> \n> On Fri, Nov 16, 2012 at 11:57 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > Hi Anne,\n> > On Fri, 2012-11-16 at 08:17 -0600, Anne Gentle wrote:\n> >>  there should be an end-result for an Incubation period to result\n> >> in a final destination that is not related to all the current\n> >> privileges given to Core projects.\n> >\n> > I think this is the bit where you\'re really trying to make a different\n> > proposal, but I don\'t fully understand it.\n> >\n> > My motion basically says that the end-resource of Incubation is \"part of\n> > the OpenStack releases\" or \"not part of the OpenStack releases\".\n> >\n> > What other end-result do you see?\n> \n> There will be projects that are released together that we all talk\n> about every week at the project meeting and at twice-annual in-person\n> events. These are called \"nuclear\" -- and \"core\" projects are also\n> welcomed to be part of the OpenStack release umbrella but will not get\n> all the associated privileges that three \"nuclear\" goals have -\n> compute, network, storage. Perhaps I am trying to define IaaS with\n> simpler terms since I don\'t have all the verbiage for defining\n> infrastructure.\n> \n> The process would be -- those projects not specifically \"nuclear\" will\n> have a different set of requirements to be called \"core.\" Those\n> projects in \"incubation\" will be promoted to \"core\" if they meet the\n> requirements to be called \"core\" and \"core\" drops the trademark\n> connotation but does get other privileges, yet to be defined in the\n> details.\n\nOk, we can put aside the \"trademark projects list\" thing for a moment\nsince you\'re also in favour of leaving that completely up to the Board,\nassuming the list is a subset of list of projects accepted into the\nOpenStack release by the TC.\n\nI think what you\'re proposing then is to:\n\n  1) Create a new category called \"nuclear\"\n\n  2) Move nova, swift, glance, cinder and quantum (keystone too?) into\n     this category\n\n  3) Everything else - e.g. horizon, ceilometer, heat - would be in the \n     \"core\" category\n\n  4) The end-result of a positive incubation is being accepted into core\n\n  5) We somehow treat nuclear and core projects differently during \n     development\n\nThe bit I\'m unclear about is (5) - exactly what are we talking about?\nPerhaps the release management, vulnerability management or stable\nbranch teams would ignore these projects?\n\nOr, perhaps it\'s closer to your own heart? That the docs team wouldn\'t\nfeel they were being forced into committing to fully documenting those\nprojects?\n\nI don\'t like the idea of second-class projects, but I\'m sympathetic to\nthe docs issue. I\'d like to think the number of docs contributors would\ngrow as new projects are added (i.e. people from those projects would\ncontribute to the docs). Perhaps full docs coverage would be a\nrequirement to graduate from Incubation?\n\nIf we dug into the details of (5) a bit more, it definitely would be a\nfine motion for the TC to vote on.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVFikS7W2TwMouR_nvkbJbEduYJyJNKP-cLX9t4UOjDhWA@mail.gmail.com>',NULL),('<1353171876.16124.114.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-17 17:04:36',0,'2012-11-17 17:04:36',NULL,'[openstack-dev] The future of Incubation and Core','On Fri, 2012-11-16 at 11:06 -0800, John Dickinson wrote:\n> Where I seemingly disagree with others is that the scope of OpenStack\n> projects should be limited to IaaS projects (as defined in my other\n> email and quoted above) and the necessary pieces for managing and\n> delivering those projects (eg docs, CI, etc).\n\nThanks John, I think that does clarify how your preferred direction\ndiffers from the motion I wrote up.\n\nPersonally, I look forward to OpenStack growing in scope, in a measured\nway, release after release.\n\nIMHO, an inclusive approach will ensure the project remains vibrant and\ncontinues to attract contributors. We\'re seeing groups of developers who\nwant to be join our community, fill gaps they see in what OpenStack\nprovides and participate in all aspects of the project. I understand and\nsupport the goal of a strong \"ecosystem\", but it\'s not the \"ecosystem\"\nthat these groups of developers want to be a part of, it\'s the project\nitself. I think we should welcome them.\n\nCheers,\nMark.\n\n\n\n','<6130C2F1-4750-4D7D-8580-D77D617C0169@not.mn>',NULL),('<1353256926.13528.9.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-18 16:42:06',0,'2012-11-18 16:42:06',NULL,'[OpenStack Foundation] Board discussing how to improve the\n Individual Director election process, community input wanted','Hi Tim,\n\nOn Sun, 2012-11-18 at 14:47 +0000, Tim Bell wrote:\n> Mark,\n> \n> The proposals for actions to be taken for the 2013 individual elections were\n> prepared by Tristan, Hui and myself.  We are individual board members but do\n> not have any affiliation with companies who have platinum or gold member\n> seats (which is where the concern has been expressed).\n\nThat\'s fair.\n\n> This is as Johnathan communicated on November 2nd\n> (http://lists.openstack.org/pipermail/foundation/2012-November/001237.html)\n> - \"Discussed options for updates to the election process. Tim Bell, Hui\n> Cheng and Tristan Goode are pulling together some recommendations that they\n> will be sharing with the mailing list for feedback before the election\n> period opens with nominations on November 26.\"\n\nAh, apologies. I missed the significance of this.\n\n> Given that the board meeting to propose the sub-committee was only agreed on\n> Nov 2nd, we were pleased to get the letter published on the 13th for the\n> board meeting on the 16th.  The time zone differences between Europe and\n> Australia didn\'t make it easy to do it faster.\n\nIt\'s a reasonable turnaround from Nov 2nd, yes.\n\n> Rob, Toby and Troy were also involved in the brainstorming prior to that to\n> cover possibilities for both (as shown in the etherpad  at\n> https://etherpad.openstack.org/Board-2012-VotingProposals). Many of these\n> proposals were  extracted from ideas on the mailing list. The 4\n> possibilities proposed for the 2013 elections were those where the bylaws\n> permitted us to change within the timescales available. The other options\n> can be debated during 2013 and proposals can then be prepared to be voted on\n> according to the bylaws.\n\nI\'m disappointed by the fact that bylaws changes were ruled out, but I\nget it. I also think you guys did a good job of capturing the ideas that\nwere discussed on the mailing list. The result isn\'t the issue, it\'s the\nprocess.\n\nIn retrospect what I really find odd is the way we have a bunch of\nengaged, constructive and interested people actively discussing ideas on\nthe mailing list. Then a completely different group goes off and\ndiscusses ideas privately and, a month later, comes back with a\nconclusion giving the original group mere days to give feedback.\n\nI guess from the perspective of members of the board, you\'ve seen the\nissue taken seriously and actively worked to a conclusion. From the\nperspective of not being on the board, I see little engagement from the\nboard in the original discussion, silence and then a big reveal. It\'s\nnot the kind of open, collaborative process I\'d hope for.\n\nThen again, no-one else seems to be taking issue with the process so\nit\'d be fair to count me as one of the \"No matter what we do, there will\nbe people who object\" crowd :)\n\nCheers,\nMark.\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5A84D87A2@CERNXCHG01.cern.ch>',NULL),('<1353259190.13528.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-18 17:19:50',0,'2012-11-18 17:19:50',NULL,'[openstack-dev] The future of Incubation and Core - a motion','On Sun, 2012-11-18 at 00:20 -0600, Anne Gentle wrote:\n> All this said, I think paragraph three is the only area where a\n> revised motion helps me come to consensus. I want a welcoming,\n> worthwhile incubation process, that\'s important to me. What\'s also\n> important is that we are ready to define the responsibilities to exit\n> incubation. This sentence just isn\'t enough... \"demonstrate\" and\n> \"suitability\" and \"inclusion\" and \"coordinated\" aren\'t enough...\n> \n> \"We see Incubation as a trial period where promising projects have the\n>   opportunity to demonstrate their suitability for inclusion in our\n>   coordinated releases.\" \n\nCare to propose a stronger wording? I suspect there\'s general consensus\nthat Incubation should be no cakewalk and that the bar should actually\nbe quite high for projects to exit Incubation.\n\nBack to the docs example again, it may be a case that there needs to be\nhigh bar for the docs required to exit Incubation (be it API, config,\ndeployer, user, etc. docs) and that we\'re not so much saying that the\ndevelopers on the project must write those docs but rather that if the\nproject isn\'t interesting enough to attract a certain level of docs\ncontributions, then it\'s just not interesting enough, period.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVHxx6JOmW5N63EBjDhEiQC+5gNS4FAprGYsrg+ap30HMQ@mail.gmail.com>',NULL),('<1353314818.316.1355011945527.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-09 00:12:25',0,'2012-12-09 00:12:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #69','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/69/>\n\n------------------------------------------\n[...truncated 11853 lines...]\nPASS euca\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nFailure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\n\n======================================================================\nERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n    CONFIG = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n    super(UsersTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n    super(BaseIdentityAdminTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n    super(UsersTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n    super(BaseIdentityAdminTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n    super(VolumesActionsTest, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n    super(VolumesGetTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n    super(VolumesGetTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n    super(VolumeListTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n    super(VolumeListTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 1 test in 0.036s\n\nFAILED (errors=8)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/rabbitmq/rabbit at devstack-1354972252-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/rabbitmq/rabbit at devstack-1354972252.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/69/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<755835509.289.1354925373488.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1353369805.582526863@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-19 18:03:25',-21600,'2012-11-20 00:03:25',NULL,'[OpenStack Foundation] Member Profile pages November 26','\nTL;DR: UPDATE YOUR PROFILE AT OPENSTACK.ORG/PROFILE BY 11/26\n \nOn Monday, November 26, we will be publishing public profiles for all members, which will include a subset of the information members provided when joining:\n- Name- Affiliation(s)- Statement of Interest- IRC Handle- Twitter Handle- Projects involved with- Join Date- Your Nominations- Photo (coming soon, optional).\n \nThe list of members is already public on the site, so this just expands on that with some additional information.  I think this will be a good way to get to know each other better as a community.  Here is a sample profile: https://www.openstack.org/community/members/sample-profile/\n \nI\'ll be sending an email to all members shortly with more information. Please make sure your profile is up to date, including your email address so that you can receive member updates. Login now: openstack.org/profile \n \nPer the election timeline Jonathan posted, nominations will also start on Monday November 26th.  Once the nomination process is underway and candidates have received 10 nominations and filled out the application, their responses will also appear on their public profile.\n \nWe are also working on an overall election page to go live 11/26 which will live here: http://www.openstack.org/election/2013-board-election/ and provide clear instructions for voters to ensure a smooth election. If anyone would like to help with the content for that page, let me know. I plan to start with the basic info from 2012 page (http://www.openstack.org/election/2012-board-election/), update and expand to ensure we are as clear and informative as possible.  \n \nAs a reminder, here is the overall timeline:\n \n\nElection Timeline:\n- November 26: Individual Member nominations open, election details live on openstack.org \n- December 7: Individual Member nominations close\n- December 14: Deadline for Individual Member Nominees to complete application\n- January 3: Gold Member Director Selector Election (1 day)\n- January 14: Individual Member Elections open\n- January 18: Individual Member Elections close\n \nMark\n \n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121119/a79c0201/attachment.html>\n\n',NULL,NULL),('<1353414274.2213.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 12:24:34',0,'2012-11-20 12:24:34',NULL,'[openstack-dev] The future of Incubation and Core - a motion','On Mon, 2012-11-19 at 09:03 -0600, Anne Gentle wrote:\n> On Sun, Nov 18, 2012 at 11:19 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > On Sun, 2012-11-18 at 00:20 -0600, Anne Gentle wrote:\n> >> All this said, I think paragraph three is the only area where a\n> >> revised motion helps me come to consensus. I want a welcoming,\n> >> worthwhile incubation process, that\'s important to me. What\'s also\n> >> important is that we are ready to define the responsibilities to exit\n> >> incubation. This sentence just isn\'t enough... \"demonstrate\" and\n> >> \"suitability\" and \"inclusion\" and \"coordinated\" aren\'t enough...\n> >>\n> >> \"We see Incubation as a trial period where promising projects have the\n> >>   opportunity to demonstrate their suitability for inclusion in our\n> >>   coordinated releases.\"\n> >\n> > Care to propose a stronger wording? I suspect there\'s general consensus\n> > that Incubation should be no cakewalk and that the bar should actually\n> > be quite high for projects to exit Incubation.\n> \n> Sure:\n> \n> \"We see Incubation as a trial period where projects interested in\n> joining the OpenStack community have the opportunity to demonstrate\n> their willingness to meet OpenStack standards for coordinated releases\n> and project management. The Incubation period is time-based and\n> intends to provide a extended evaluation effort while providing the\n> project shared resources both for consumption and contribution. While\n> evaluation criteria for incubation exit are still needed, the ideal\n> incubation process affords time for both the project itself and the\n> community. Ideally projects exiting incubation give a proven,\n> measurable ability to enable OpenStack infrastructure and services, to\n> increase adoption for OpenStack and possibly across multiple OpenStack\n> clouds, and prove it has potential for wide usefulness.\"\n> \n> A couple of reasons for the extended wording:\n> \n> -acknowledges the need to define the process further\n> -enables several more definitions of exit/promotion/next life\n\nThat sounds good to me and is how I understand the current incubation\nprocess.\n\nI don\'t think the discussion with the board is so much about\nsignificantly changing the requirements for a project to exit\nincubation, but more what about what types of projects we should accept\ninto incubation and what happens a project once with it exits.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVGxXaowoHqpm5pr_MLkQkBv9P+XZER0DMO5UK11ZB0Eqw@mail.gmail.com>',NULL),('<1353415519.2213.17.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 12:45:19',0,'2012-11-20 12:45:19',NULL,'[openstack-dev] Mandating projects support plugins [was Re: The\n future of Incubation and Core - a motion]','On Mon, 2012-11-19 at 13:18 -0800, Boris Renski Jr. wrote:\n> Since we are talking about OpenStack core and respective roles of TC and\n> board in helping define this, I have a matter up for discussion that\'s been\n> bothering me for some time. \n\nI honestly think we\'ve enough on our plate right now with the current\ndiscussion without getting into this. We\'re working hard on this thread\nto build some form of consensus around one specific issue. Introducing a\nmuch broader topic into the discussion really doesn\'t help.\n\n> Today we have two types of projects that are core. Those where the bigger\n> emphasis is on the API and APIs are loosely coupled with the implementation\n> or even third party functionality or plug-ins (Nova, Quantum, Cinder) and\n> those that are really opinioned implementations of certain functionality -\n> Swift (probably the most pronounced member of the second category), Horizon\n> etc. \n>\n> For instance, similar to Quantum, Swift could have been designed as an API\n> centric service with implementations as plug-ins; but it is not. And largely\n> due to the history of how OpenStack evolved, Swift now became the monopoly\n> implementation on object store, indefinitely enjoying core project status.\n> It is not unlikely that Swift could become less active and its opinionated\n> architecture - less relevant to the newer paradigms of storage. More\n> importantly, because something like Swift is core, nobody in the community\n> would even consider developing a different, competing implementation.... \n> \n> I am not trying to pick on Swift in particular (so John, don\'t get mad) but\n> am using it to illustrate a scenario. \n\nIt sounds like you want Swift to have a plugin architecture with the\ncurrent backend implementation being just one of several plugins?\n\nIt seems like a vaguely reasonable idea and, indeed, the GlusterFS team\nhave done work around building a GlusterFS plugin for Swift. Whether\nthat idea is adopted is solely a question for the Swift team and whether\nit makes sense for the projects\' goals.\n\nHowever, I wouldn\'t support the Board or the TC attempting to somehow\nmandate this kind of stuff to projects by wrapping it up in some sort of\n\"The OpenStack Project is API focused and welcomes multiple\nimplementations of those APIs\" verbiage. From my perspective, the\nproject cares far more about its implementation than its APIs.\n\nBut, again, I think this has the potential to be a massive distraction\nfrom the topic at hand.\n\nCheers,\nMark.\n\n\n\n','<03bb01cdc69b$5d6c46a0$1844d3e0$@renski.com>',NULL),('<1353421032.74122251@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-20 08:17:12',-21600,'2012-11-20 14:17:12',NULL,'[OpenStack Foundation] Member Profile pages November 26','\nThat was phrased in a someone vague manner to leave open to interpretation... and purposely avoided the use of the term \"contributor\" so as to avoid that age old debate :)\n \nIMHO anyone who is deploying OpenStack is \"involved with\" any piece they are deploying/running.\n \nFor the future, we could definitely add a lot of additional fields to help each member express their support for, and involvement with, openstack in a more detailed way. Perhaps a \"I\'m a user\" badge with details on your deployment... and on the developer front, Monty & team are working to better tie together the member database and the launchpad IDs used for the dev process, so we could automate display of recent code contributions.  We could do a lot of cool things!  Monday\'s profile is a very basic starting point.  Let\'s work on improving it together.\n \n \n \n \nOn Tuesday, November 20, 2012 1:31am, \"Tim Bell\" <Tim.Bell at cern.ch> said:\n\n\n\n\n \nMark,\n \nFor the ?Project involved with? , what should someone fill out if they are doing a production deployment as a user ?\n \nTim\n \n\n\n\nFrom: Mark Collier [mailto:mark at openstack.org] \nSent: 20 November 2012 01:03\nTo: foundation at lists.openstack.org\nSubject: [OpenStack Foundation] Member Profile pages November 26\n \nTL;DR: UPDATE YOUR PROFILE AT OPENSTACK.ORG/PROFILE BY 11/26\n \nOn Monday, November 26, we will be publishing public profiles for all members, which will include a subset of the information members provided when joining: \n\n- Name\n- Affiliation(s)\n- Statement of Interest\n- IRC Handle\n- Twitter Handle\n- Projects involved with\n- Join Date\n- Your Nominations\n- Photo (coming soon, optional). \n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20121120/79036f29/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5A84E8AE9@CERNXCHG01.cern.ch>',NULL),('<1353421525.2213.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-20 14:25:25',0,'2012-11-20 14:25:25',NULL,'[Openstack-stable-maint] 2012.2.1','Hey\n\nThe date we discussed for the 2012.2.1 release is upon us:\n\n  https://etherpad.openstack.org/process-stable-branch\n\ni.e. November 22nd\n\nPlease take some time today to do some stable/folsom reviews and we can\ndiscuss the current status at tonight\'s project meeting.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1353423430.2213.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-20 14:57:10',0,'2012-11-20 14:57:10',NULL,'[Openstack-stable-maint] 2012.2.1','On Tue, 2012-11-20 at 14:25 +0000, Mark McLoughlin wrote:\n> Hey\n> \n> The date we discussed for the 2012.2.1 release is upon us:\n> \n>   https://etherpad.openstack.org/process-stable-branch\n> \n> i.e. November 22nd\n> \n> Please take some time today to do some stable/folsom reviews and we can\n> discuss the current status at tonight\'s project meeting.\n\nThere are a few Nova backports with failing unit tests:\n\nhttps://review.openstack.org/16430 [R=-1 V=-1 A=0]  Eliminates simultaneous schedule race.  (zulcss) \nhttps://review.openstack.org/16433 [R=-1 V=-1 A=0]  XenAPI should only snapshot root disk  (zulcss) \nhttps://review.openstack.org/16434 [R=-1 V=-1 A=0]  make QuantumV2 support requested nic ordering  (zulcss) \n\nI think Gary\'s going to look at the latter one. If others could look at\nthe first two, that\'d be great.\n\nThanks,\nMark.\n\n\n\n\n','<1353421525.2213.19.camel@sorcha>',NULL),('<1353498385.2213.63.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-21 11:46:25',0,'2012-11-21 11:46:25',NULL,'[Openstack-stable-maint] [Fwd: [openstack-dev] [Nova] nova\n stable/folsom with quantum does not work]','Hey\n\nJust in case people wonder what\'s up here - it looks like this might be\na 2012.2.1 release blocker and Gary is looking into it\n\nOh, and during last night\'s project meeting we decided to do 2012.2.1 on\nthe 29th (next week) rather than the originally planned 22nd (tomorrow)\n\nhttp://eavesdrop.openstack.org/meetings/project/2012/project.2012-11-20-21.03.html\n\nCheers,\nMark.\n\n-------- Forwarded Message --------\n> From: Akihiro MOTOKI <motoki at da.jp.nec.com>\n> Reply-to: OpenStack Development Mailing List\n> <openstack-dev at lists.openstack.org>\n> To: openstack-dev at lists.openstack.org\n> Subject: [openstack-dev] [Nova] nova stable/folsom with quantum does\n> not work\n> Date: Wed, 21 Nov 2012 19:17:18 +0900\n> \n> Hi,\n> \n> Nova stable/folsom and milestone-proposed with Quantum does not work now.\n> I tested with milestone-proposed 9dfb4b420f9d15d348f9fa9a2a0cb1a57f4e5771.\n> \n> I think it is a critical issue for G-1 and please check it.\n> \n> The cause of the problem is a backport of \"Proxy floating IP calls to quantum\".\n> This patch requires the other fix https://review.openstack.org/#/c/13912/\n> I file a bug about it as https://bugs.launchpad.net/nova/+bug/1081434\n> and please see it for details.\n> \n> Thanks,\n> -- \n> Akihiro MOTOKI <motoki at da.jp.nec.com>\n> Cloud System Research Laboratories, NEC Corporation\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n',NULL,NULL),('<1353514091.59240.YahooMailClassic@web122504.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 08:08:11',-28800,'2012-11-21 16:08:11',NULL,'[openstack-dev] [quantum] [LBaaS] Health monitors REST resource','\nHello everyone \n?\ni spend some time trying to develop a server dashboard and thank for all you help,but now i got to a second step where i need to write a platform like this:\n?\nWhen the user log in he can see all the VM I have on my Cloud instance, and submit the information where the server will respond with a VM IP address if the VM is available but when it?s not available the server will respond with a message.\n?\nAnyone have an Idea how i can do this?? thanks!!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/834b9629/attachment.html>\n\n','<2ad401cdc7fc$f111e420$d335ac60$@mirantis.com>',NULL),('<1353522840.5521935@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-21 12:34:00',-21600,'2012-11-21 18:34:00',NULL,'[OpenStack Foundation] Member Profile pages November 26','As I mentioned below, I\'m finalizing the copy for the main election page now, which will go live on Monday 11/26 at this url:  https://www.openstack.org/election/2013-board-election/\n\nTim Bell has volunteered to help review the content and make sure it hits the mark for accuracy and completeness.  If anyone else would like to give it a read through, let me know.\n\nMark\n\n\nOn Monday, November 19, 2012 6:03pm, \"Mark Collier\" <mark at openstack.org> said:\n\n> \n> TL;DR: UPDATE YOUR PROFILE AT OPENSTACK.ORG/PROFILE BY 11/26\n> \n> On Monday, November 26, we will be publishing public profiles for all members,\n> which will include a subset of the information members provided when joining:\n> - Name- Affiliation(s)- Statement of Interest- IRC Handle- Twitter Handle-\n> Projects involved with- Join Date- Your Nominations- Photo (coming soon,\n> optional).\n> \n> The list of members is already public on the site, so this just expands on that\n> with some additional information.  I think this will be a good way to get to know\n> each other better as a community.  Here is a sample profile:\n> https://www.openstack.org/community/members/sample-profile/\n> \n> I\'ll be sending an email to all members shortly with more information. Please make\n> sure your profile is up to date, including your email address so that you can\n> receive member updates. Login now: openstack.org/profile\n> \n> Per the election timeline Jonathan posted, nominations will also start on Monday\n> November 26th.  Once the nomination process is underway and candidates have\n> received 10 nominations and filled out the application, their responses will also\n> appear on their public profile.\n> \n> We are also working on an overall election page to go live 11/26 which will live\n> here: http://www.openstack.org/election/2013-board-election/ and provide clear\n> instructions for voters to ensure a smooth election. If anyone would like to help\n> with the content for that page, let me know. I plan to start with the basic info\n> from 2012 page (http://www.openstack.org/election/2012-board-election/), update\n> and expand to ensure we are as clear and informative as possible.\n> \n> As a reminder, here is the overall timeline:\n> \n> \n> Election Timeline:\n> - November 26: Individual Member nominations open, election details live on\n> openstack.org\n> - December 7: Individual Member nominations close\n> - December 14: Deadline for Individual Member Nominees to complete application\n> - January 3: Gold Member Director Selector Election (1 day)\n> - January 14: Individual Member Elections open\n> - January 18: Individual Member Elections close\n> \n> Mark\n> \n> \n\n\n\n\n','<1353369805.582526863@emailsrvr.com>',NULL),('<1353546512.86717.YahooMailClassic@web122503.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 17:08:32',-28800,'2012-11-22 01:08:32',NULL,'[openstack-dev] Cloud instance managment!','\n\n\n\n\nHello everyone \n?\n\ni spend some time trying to develop a server dashboard and thank for all you help,but now i got to a second step where i need to write a platform like this:\n?\n\nWhen the user log in he can see all the VM I have on my Cloud instance, and submit the information where the server will respond with a VM IP address if the VM is available but when it?s not available the server will respond with a message.\n?\n\nAnyone have an Idea how i can do this?? thanks!!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/781955dd/attachment.html>\n\n','<2ad401cdc7fc$f111e420$d335ac60$@mirantis.com>',NULL),('<1353603954.14377.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 17:05:54',0,'2012-11-22 17:05:54',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','Sorry, I didn\'t manage to keep up with this thread as it happened and\nI\'m struggling to get a good handle on it now\n\nApparently there was some consensus in the thread around making the\nnova.virt.driver interface and its implementations public and having\nceilometer consume that. I\'m not really seeing that consensus reading\nback.\n\nHonestly, after looking at what parts of Nova code Ceilometer currently\nuses, that approach looks like an awfully big hammer. AFAICT, Ceilometer\ncurrently does some pretty simple and generic querying of libvirt for\nCPU, disk and NIC information.\n\nEven if we stick with this approach of having an agent that talks to\nlibvirt, is it really such a huge deal to have code in both Nova and\nCeilometer that does this?\n\nPut it another way, if you made a standalone generic library for doing\njust this piece, Nova probably wouldn\'t bother using it since so little\ncode is involved.\n\nOn Wed, 2012-11-14 at 16:55 -0500, Eoghan Glynn wrote:\n> \n> ----- Original Message -----\n> > I\'m partial to #3 on the basis that it would encourage us to expose\n> > more useful information to the world. I don\'t think that would mean\n> > Ceiliometer is leaking into Nova, we\'re just exposing data that\n> > consumers are asking for.\n> > \n> > I might be missing something silly, but why does Nova need to know\n> > where Ceiliometer\'s message bus is? Why can\'t Ceiliometer just\n> > listen on the queue wherever Nova, Glance, Cinder, etc are already\n> > producing notifications?\n> \n> Sure, but that\'s not so much the issue I had in mind.\n> \n> Its more that nova would have to start becoming concerned with the\n> semantics of stats that ceilometer currently interprets. For example,\n> nova might need to know how to derive say CPU utilization from the\n> cumulative CPU time samples reported by the hypervisor driver.\n> \n> So, its not knowledge of the ceilo queues leaking into nova that I\'d\n> be concerned about, more leakage of ceilo logic.\n\nI think I\'ve the same instinct as Brian on this - it doesn\'t seem\nunreasonable for Nova to publish CPU/disk/NIC samples at the same\ninterval as other notifications.\n\nWhat might be confusing this whole discussion is the discussion around\nmetering and instrumentation requirements. I think we should keep the\ntwo concerns completely separate for now and plough ahead with what we\nthink makes sense for metering.\n\nCheers,\nMark.\n\n\n\n','<575115739.2220204.1352930157999.JavaMail.root@redhat.com>',NULL),('<1353604253.14377.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 17:10:53',0,'2012-11-22 17:10:53',NULL,'[openstack-dev] [nova] versioning scheme for consumable\n libraries','On Thu, 2012-11-22 at 11:34 +0100, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > On 11/21/2012 09:13 AM, Doug Hellmann wrote:\n> > \n> >>     My understanding of option 5 is that the library would be use by\n> >>     ceilometer to access Nova, not the other way around ?\n> >>\n> >> I thought that option represented moving the virtualization code out of\n> >> nova into a library that was used by both components for talking to the\n> >> hypervisor. That introduces a new dependency, but neither component is\n> >> communicating with the other so there is still no dependency between\n> >> nova and ceilometer (in fact, removing our current dependency on nova is\n> >> part of the motivation for these changes).\n> > \n> > I\'m a fan of this. It uses existing software engineering concepts\n> > (libraries) that are well understood with well understood machinery. Of\n> > course, the proof is in the pudding (what does the patch actually look\n> > like) - but I think this has the best chance of being something that\n> > doesn\'t turn crazy.\n> \n> This just looks a lot like an Oslo (common code) library. Is there any\n> reason why we couldn\'t just use Oslo for this ? The code is common\n> between Nova and Ceilometer, and should become a separate library\n> (oslo-virt ?) used by both. That way we reuse a well-known model and\n> there is no reason to create a special case, and I\'m completely fine\n> with it.\n> \n> The versioning scheme discussion then becomes the same as the oslo\n> libraries versioning scheme discussion, and I suggest we continue there:\n> \n> http://lists.openstack.org/pipermail/openstack-dev/2012-November/002709.html\n> \n> Additional questions on the oslo route: is it OK to move to oslo, today,\n> code that is currently only used in one core project (Nova), to care for\n> the need of an incubated project (Ceilometer) ? Could we be using\n> oslo-incubator copy/update mechanism in the first stage of this ? I\n> guess we need markmc\'s view on this.\n\nI went back over the thread and replied:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/003222.html\n\nAFAICT Ceilometer is looking to re-use approximately 3% of Nova\'s\nlibvirt driver. There\'s no way the Nova project should incur the\ncomplexity (separate team, releases, cross-project changes, stable APIs,\netc.) of managing *all* of the virt driver code as a separate project\njust for the sake of the re-use of that 3%.\n\nWhat might make sense is a little \"talk to the hypervisor and get\nCPU/disk/NIC usage data\" library which both Ceilometer and the nova virt\ndrivers would use. That could be an Oslo library but I really doubt that\nwould be worth it.\n\nFinally, I think it\'s worth investigating in more depth whether Nova can\npublish notifications with the data required for Ceilometer to meter\nthis stuff.\n\nCheers,\nMark.\n\n\n\n','<50ADFFAD.7010203@openstack.org>',NULL),('<1353606295.14377.24.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 17:44:55',0,'2012-11-22 17:44:55',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Tue, 2012-11-13 at 15:19 +0100, Thierry Carrez wrote:\n> From https://blueprints.launchpad.net/oslo/+spec/oslo-release-versioning\n> \n> > Before we can release Oslo\'s first library package, we must agree on a versioning scheme.\n> > \n> > The core services projects follow one versioning scheme and the client libraries follow another scheme, but this is our first time releasing a library which supports the core services.\n> \n> A bit of explanation there.\n\n(snip good summary, agree we can\'t assume same solution as client\nlibraries works here)\n\n> > Should Oslo library packages be part of the co-ordinated release schedule along with the core services? Or should they follow their own (ad-hoc?) release schedule?\n> \n> Adding another question: should all oslo libraries share the same\n> versioning ? i.e. should oslo.config version be updated when oslo.rpc\n> needs to be released ?\n\nNo, it\'s not required, but I think there\'s some value in a checkpoint\nrelease of all the libraries in the same family using the same version.\nIt would just make it easier for folks to understand which versions\nbelong together, given they will be dependent on each other.\n\n> > Which versions get released to PyPi? Should we have a stable branch of these libraries with stable releases?\n> \n> That\'s the crux of the issue. We have two valid models:\n> \n> 1- Integrated with common release, using common versioning, not using\n> PyPI, supporting stable/* branches and stable point releases\n> \n> 2- Ad-hoc versioning, ignoring the common cycle, using PyPI (which makes\n> stable point releases look weird)\n> \n> I\'m not sure there is a middle solution. I guess we /could/ support\n> stable branches and stable point releases in solution (2), despite\n> PyPI\'s lack of good support for it... but then I\'d prefer if those\n> stable branches were disconnected from the common release cycle (i.e.\n> the stable series would be \"1.x\" and not \"folsom\") so that we don\'t tie\n> a lot of different weird version numbers to a given series.\n\nWell, to add two more questions:\n\n  * When do we commit to compatibility around a new API in Oslo? When \n    it gets committed, when it gets released or when we release an \n    officially \"API frozen\" version?\n\n  * How do other OpenStack projects consume Oslo libraries during \n    development? e.g. can you put a git URL into pip-requires, or must \n    you have a pypi release version there?\n\nYou could say e.g. new APIs are committed to when they\'re released to\npypi and OpenStack projects can only consume new APIs once they\'ve been\nreleased to pypi.\n\nBut that could result us doing library releases too often, integration\nwith other projects being too slow or us only realizing we\'ve made\ndrastic API design mistakes after committing to the new API.\n\nHmm.\n\nMark.\n\n\n\n','<50A2570A.80509@openstack.org>',NULL),('<1353612817.14377.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 19:33:37',0,'2012-11-22 19:33:37',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','On Thu, 2012-11-22 at 13:13 -0500, Eoghan Glynn wrote:\n> > Apparently there was some consensus in the thread around making the\n> > nova.virt.driver interface and its implementations public and having\n> > ceilometer consume that. I\'m not really seeing that consensus reading\n> > back.\n> \n> My read was that the consensus cohered in the follow-up discussion\n> during the nova IRC meeting[1].\n\nAh, ok - we really should get into the habit of posting summaries of\ndiscussion like that to the relevant thread. I\'m as guilty of not doing\nthat as anyone.\n\n> > Honestly, after looking at what parts of Nova code Ceilometer\n> > currently uses, that approach looks like an awfully big\n> > hammer. \n> \n> K, let\'s think about a less weighty hammer.\n> \n> > AFAICT, Ceilometer currently does some pretty simple and\n> > generic querying of libvirt for CPU, disk and NIC information.\n> \n> Yes, exactly. But we want to be able to do it in the non-libvirt\n> cases too. And all without copying in a rake of nova code.\n\nUnderstood.\n\n> > Even if we stick with this approach of having an agent that talks to\n> > libvirt, is it really such a huge deal to have code in both Nova and\n> > Ceilometer that does this?\n> \n> Well the way ceilo does it now (just picking up the whatever version\n> of the nova is available) is turning out to be a real headache keeping\n> up with internal mods to nova - the ceilo trunk regularly breaks\n> because some change in nova-land has an unforeseen impact on ceilo\n> (which is understandable, seeing as this code was never intended to\n> externally consumable).\n\nUnderstood.\n\n> So to address that instability, are you suggesting we take a big ol\'\n> copy of some version (say 2012.2) of the nova virt code, prune it down\n> to the bits we need, then dump that into the ceilo repo?\n> \n> Is the virt code sufficiently isolated within nova to do that?\n> e.g. say some bit of the nova utils or config code changes, wouldn\'t\n> that potentially have a knock-on impact?\n> \n> Is it OK that adding a new driver type in nova would require ceilo\n> to notice and pick this up & distill out the bits needed?\n\nNo, that\'s not what I\'m suggesting.\n\nTake the DiskIOPollster stuff as an example:\n\n  conn = driver.load_compute_driver()\n  disks = conn.get_disks(instance_name)\n  for disk in disks:\n      stats = conn.block_stats(instance_name, disk)\n\nThe Nove code ceilometer is re-using is the code to connect to libvirt,\ncode to call conn.lookupByName() and domain.XMLDesc() to query libvirt\nfor the XML describing a VM, code to use xpath to extract the disk\ndescriptions from the XML and then code to call domain.blockStats() to\nget stats about the disk.\n\nI really don\'t see much issue with ceilometer just doing those few\nthings directly. The only private implementation assumption you\'d be\nmaking about the Nova libvirt driver is that the libvirt VM name is the\nsame as the instance name.\n\nYou\'d be right to be concerned that you\'d need to implement that same\ncode for other hypervisors, but here\'s the thing - the get_disks() and\nblock_stats() methods in the libvirt virt driver aren\'t part of the virt\ndriver abstraction. Other drivers neither implement them, nor do we have\ncommon data structures for the values they\'d return. In other words, the\nabstraction layer with multiple implementations doesn\'t yet exist.\n\n> > Put it another way, if you made a standalone generic library for\n> > doing just this piece, Nova probably wouldn\'t bother using it since\n> > so little code is involved.\n> \n> OK, there seemed to be a willingness for nova use it expressed in\n> that IRC discussion, but yeah I take your point that it\'s a relatively\n> small piece.\n\nYou know what\'s weird? The get_disks() and block_stats() methods appear\nunused in Nova.\n\n> > I think I\'ve the same instinct as Brian on this - it doesn\'t seem\n> > unreasonable for Nova to publish CPU/disk/NIC samples at the same\n> > interval as other notifications.\n> \n> So IIUC the other notifications produced by nova are not really on\n> a fine-grained periodic basis, being either triggered by lifecycle\n> events (e.g. an instance is updated in some way) or else are very\n> infrequent (e.g. the instance audit logic runs at most hourly). \n> \n> But in any case, one concern with nova-compute emitting these data\n> as either notifications or else making direct calls into a ceilo-\n> provided library was that such a loaded service is likely to\n> run into timeliness issues.\n\nIf the data is purely for metering, the timeliness issue isn\'t a concern\nright?\n\n> > What might be confusing this whole discussion is the discussion\n> > around metering and instrumentation requirements. I think we should\n> > keep the two concerns completely separate for now and plough ahead\n> > with what we think makes sense for metering.\n> \n> There\'s been a fair amount of fuzziness around the distinction\n> between instrumentation and monitoring, but this falls into the\n> latter camp for me. Its not so much about the internal dynamics\n> of nova, as the user-visible behavior (e.g. is my instance running\n> hot or am I pushing loads of data through the network, as opposed\n> how long did that API call to update the instance take to service\n> end-to-end or how many connections are in that pool).\n\nMetering vs monitoring/instrumentation, not monitoring vs\ninstrumentation :)\n\nIf we were just designing a solution for metering, would we go for the\nnotifications option?\n\nCheers,\nMark.\n\n\n\n','<1132113361.6503529.1353608004994.JavaMail.root@redhat.com>',NULL),('<1353652009.14377.57.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 06:26:49',0,'2012-11-23 06:26:49',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','On Thu, 2012-11-22 at 16:32 -0500, Eoghan Glynn wrote:\n\n> > I really don\'t see much issue with ceilometer just doing those few\n> > things directly. The only private implementation assumption you\'d be\n> > making about the Nova libvirt driver is that the libvirt VM name is\n> > the same as the instance name.\n> \n> Well I was thinking we\'d also need ComputeDriver.list_instances()\n> at least (previously we pulled the instances for the compute node\n> directly from the nova DB, now we query the nova-api, but neither\n> solution is really optimal).\n> \n> But just to confirm I understand the suggestion, by *direct* usage\n> do you mean simply calling the currently installed nova virt code\n> but at a level that is unlikely to change? (say by pushing some\n> internals of the driver implementation into the driver API)\n\nNope, don\'t use any code - just have your own code for talking directly\nto libvirt and other hypervisors.\n\n(And for clarity - this is if ceilometer must do the polling directly. I\nstill think notifications are the way to go for now)\n\n> > > There\'s been a fair amount of fuzziness around the distinction\n> > > between instrumentation and monitoring, but this falls into the\n> > > latter camp for me. Its not so much about the internal dynamics\n> > > of nova, as the user-visible behavior (e.g. is my instance running\n> > > hot or am I pushing loads of data through the network, as opposed\n> > > how long did that API call to update the instance take to service\n> > > end-to-end or how many connections are in that pool).\n> > \n> > Metering vs monitoring/instrumentation, not monitoring vs\n> > instrumentation :)\n> \n> I kinda see the split more as metering/monitoring vs instrumentation.\n\nI don\'t see why. Timeliness is a concern for user-oriented monitoring\nbut not for metering.\n\nTimeliness is the issue in this discussion.\n\nSo, they\'re clearly not the same thing for the purposes of this\ndiscussion.\n\n> Well, actually more like metering/user-oriented-monitoring vs \n> cloud-operator-oriented-monitoring/instrumentation.\n> \n> Currently ceilo is aiming to at least address both metering and \n> user-oriented-monitoring, and possibly more in time.\n> \n> > If we were just designing a solution for metering, would we go for\n> > the notifications option?\n> \n> Probably, but the scope of ceilo has widened a bit from pure\n> metering.\n\nRight. From a far remove, that looks like a mistake at this early stage.\n\nAs Sandy rightly says, if we just focused on metering, then the\nconclusion is simple - improve the notifications infrastructure. If\nCeilometer focused on its original mission, forward progress would be\neasier.\n\nCheers,\nMark.\n\n\n\n','<1042654059.6514135.1353619946738.JavaMail.root@redhat.com>',NULL),('<1353655778.14377.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 07:29:38',0,'2012-11-23 07:29:38',NULL,'[openstack-dev] New python dependency - extras-0.0.1','Hey,\n\nA new Oslo dependency is proposed here:\n\n  https://review.openstack.org/16789\n\nThe library is called \'extras\' and released its first version nearly a\nmonth ago:\n\n  http://pypi.python.org/pypi/extras/0.0.1\n  https://github.com/testing-cabal/extras\n\nI don\'t forsee any objections apart from perhaps \'is a separate library\nfor just try_import() really worth it?\'\n\nI\'m inclined to approve it, just want to give folks a chance to express\nan opinion.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1353965018.2927.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-26 21:23:38',0,'2012-11-26 21:23:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-folsom #56','Hey,\n\nI\'m keeping track of all these failures here:\n\n  https://etherpad.openstack.org/folsom-bitrot-jobs\n\nApart from the keystoneclient version thing which seemed to get fixed\nup, they all seem to just be intermittent failures which go away the\nnext time the job is run.\n\nJust trying to gather together the known failures so we can spot a real\nfailure when it happens.\n\nCheers,\nMark.\n\n\n\n\n\n','<1104484954.83.1353888719542.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1353967297.2927.60.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 22:01:37',0,'2012-11-26 22:01:37',NULL,'[openstack-dev] Making pbr an Oslo package','Hey Monty\n\nFor other people\'s reference, this is about taking pbr (\"Python Build\nReasonableness\") and releasing it as an Oslo library package:\n\n  https://github.com/openstack-dev/pbr\n  https://bugs.launchpad.net/openstack-ci/+bug/1082821\n\nMy understanding is pbr is based on the openstack.common.setup module in\noslo-incubator but has evolved a good bit since then.\n\nThe reason we\'re thinking it makes sense under Oslo is that it does\nencode a bunch of OpenStack specific ideas which aren\'t something we see\nother projects adopting wholesale.\n\nThere\'s a bunch to discuss here:\n\n  - You say in the bug that it needs work. It hasn\'t seen any activity\n    in the last couple of months. Is that likely to change soon?\n\n  - How close do you think we are to being able to make a commitment to \n    its API stability? Remember the rule we\'re aiming for in Oslo \n    packages is that APIs need to be deprecated for two releases before \n    they can be removed[1]\n\n  - Are any projects using it yet? Catch 22 here, I guess, but I\'m \n    never too confident about any API until it has been used for a \n    while.\n\n  - If we still have a bunch of work to do here, isn\'t pbr effectively \n    in Incubation? Would it make sense to move it back into \n    oslo-incubator for a while? At least that would reduce the \n    confusion around the current stuff being stale.\n\n  - Bikeshedding, oslo-version doesn\'t make sense to me - thinking \n    something like oslo-build or oslo-setuptools or something?\n\nCheers,\nMark.\n\n[1] - https://etherpad.openstack.org/grizzly-oslo\n\n\n\n',NULL,NULL),('<1353969205.2927.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 22:33:25',0,'2012-11-26 22:33:25',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Thu, 2012-11-22 at 23:21 -0800, Monty Taylor wrote:\n> \n> On 11/22/2012 09:44 AM, Mark McLoughlin wrote:\n> > Well, to add two more questions:\n> >\n> >    * When do we commit to compatibility around a new API in Oslo? When\n> >      it gets committed, when it gets released or when we release an\n> >      officially \"API frozen\" version?\n> \n> I vote for when it gets released.\n> \n> >    * How do other OpenStack projects consume Oslo libraries during\n> >      development? e.g. can you put a git URL into pip-requires, or must\n> >      you have a pypi release version there?\n> >\n> > You could say e.g. new APIs are committed to when they\'re released to\n> > pypi and OpenStack projects can only consume new APIs once they\'ve been\n> > released to pypi.\n> \n> Yes please. We have done cross-project git-url consumption before. It\'s \n> a nightmare (largely because although the python toolchain tempts us \n> into thinking this will work, it doesn\'t actually fully work.\n> \n> > But that could result us doing library releases too often, integration\n> > with other projects being too slow or us only realizing we\'ve made\n> > drastic API design mistakes after committing to the new API.\n> \n> Honestly, I think you have a slightly easier time of it than the client \n> lib folks in terms of API commitment - since you know who your consumers \n> are, and you can actually check around to see if anyone is using an old \n> API. It\'s not too terrible - how about we try it that way for a bit and \n> see if there are actual logistical problems?\n\nLeaving aside mechanics for a second, the more I think about this the\nmore I\'m coming to a pretty firm view ...\n\nI want the 6 month release cycle model for Oslo. I want the project to\ngo through a bunch of hacking for the first part of that cycle and lock\nthings down towards the end of the release. I want Oslo to have a stable\nbranch where people can get fixes without the risk of new features. I\nwant milestone release checkpoints to focus the mind and not have one\nlong period of hacking before a release. I want Oslo\'s cycle to be in\nsync with the projects which are using Oslo\'s APIs. I want people to\nintuitively understand what Oslo\'s cycle is rather than it having a\nbunch of special rules. And I want Thierry\'s help coordinating all\nthis :-)\n\nBasically, my instinct is to do everything just like any of the other\ncore projects except in those cases where Oslo really is a special case.\n\nThe main difference is other core projects are consuming APIs provided\nby Oslo.\n\nI think it makes sense to say other projects can only consume new Oslo\nAPIs if they\'ve actually been released.\n\nI wouldn\'t like to see Oslo development releases go on pypi. To me, that\nwould give those releases an inaccurate appearance of stability. I would\nlike to see stable branch releases going to pypi.\n\nDuring development, I think we should have some wiggle room to fix up\nbad API design errors even after we\'ve done a development release with\nthose errors. If we can notice the error, add a better API, deprecate\nthe broken API, update all the core projects and remove the broken API\nbefore final release, I think that\'s workable.\n\nCan we figure out the mechanics to make this all possible? e.g. can we\npush tarball releases somewhere during development other than PyPi and\njust reference those tarball URLs directly in pip-requires? At release\ntime, we\'d push Oslo releases to PyPi and update the core projects to\nuse those as their dependencies rather than URLs.\n\nCheers,\nMark.\n\n\n\n','<50AF23ED.1050008@inaugust.com>',NULL),('<1353969604.2927.83.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 22:40:04',0,'2012-11-26 22:40:04',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:\n> There seem to be two options there: just push everything on the same\n> PyPI module, or have multiple PyPI modules for each series. I\'d say\n> the latter looks worse.\n\nI don\'t really buy that unstable development releases of Oslo have to go\nto PyPI in order for core projects to be able to consume them.\n\npip supports http:// URLs of tarballs. Why not use that during\ndevelopment?\n\n> For the former, I suspect you can specify \">=1.2.1 <2\" as far as\n> dependencies are concerned.\n\nI really, really hate version caps like that :)\n\nSay we add a new API to oslo-config, release version 1.2.1 and nova\nwants to express that it requires that API. Why on earth would we say\nthat this version of nova is incompatible with version 2.x of\noslo-config?\n\nIn another context, Monty\'s case for this kind of version capping is\nthat you can\'t depend on Python library maintainers to have any\ndiscipline around API stability - but that\'s exactly the discipline\nwe\'re aiming for with Oslo!\n\nCheers,\nMark.\n\n\n\n','<50AF5606.1090201@openstack.org>',NULL),('<1353970888.9027.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 23:01:28',0,'2012-11-26 23:01:28',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','On Mon, 2012-11-26 at 10:39 -0500, Doug Hellmann wrote:\n> \n> \n> On Fri, Nov 23, 2012 at 1:26 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Thu, 2012-11-22 at 16:32 -0500, Eoghan Glynn wrote:\n\n>         > > If we were just designing a solution for metering, would\n>         we go for\n>         > > the notifications option?\n>         >\n>         > Probably, but the scope of ceilo has widened a bit from pure\n>         > metering.\n>         \n>         \n>         Right. From a far remove, that looks like a mistake at this\n>         early stage.\n>         \n>         As Sandy rightly says, if we just focused on metering, then\n>         the\n>         conclusion is simple - improve the notifications\n>         infrastructure. If\n>         Ceilometer focused on its original mission, forward progress\n>         would be\n>         easier.\n> \n> \n> We\'ve had conflicting messages on that point. When we applied for\n> incubation I understood the TC mandate for the project to be \"measure\n> everything,\" and that has led to consideration of features like\n> monitoring and collecting data more frequently and in different ways\n> than would be necessary for just billing-related purposes. However,\n> when changes related to those features are proposed we\'ve had some\n> push-back because of scope creep. Are you suggesting we should drop\n> the monitoring work?\n\nUggh, I don\'t want to be talking about \"TC mandates\" here :)\n\nA project gets accepted into Incubation partly based on the fact that\nthe TC has a reasonable level of trust in the judgement of the project\nleaders. I\'d hate to see the TC get into mandating the detailed\ntechnical direction of an incubating project.\n\nThe way I\'d personally like to see Ceilometer approach incubation is to\nfocus completely on metering, \"knock the ball out of the park\" and be a\nkick-ass metering solution when Grizzly is released.\n\nI worry that if the scope expands, you might get to Grizzly release time\nand still have a bunch of loose ends. I mention it in this Nova\nintegration thread because it looks like a good example. IMHO, if\nCeilometer was focused (for now) purely on metering then this thread\nwould have been shorter and the solution might already be in place.\n\nSo, it\'s not about TC mandates. It\'s about TC folks giving their best\nadvice on the trade-offs you guys are facing. It\'s for you to make the\ndecision on those trade-offs.\n\n(In fact, I only expressed an opinion here because the idea came up of\nmoving Nova\'s virt drivers out as an Oslo library)\n\nThat\'s not to say monitoring isn\'t important, or that there isn\'t a\nwhole lot of benefit to monitoring an metering folks working together,\nor that no-one should be working on monitoring right now, or that Nova\ndoesn\'t need to support monitoring requirements, or ... just let\'s not\nallow monitoring slow down progress on metering.\n\nCheers,\nMark.\n\n\n\n','<CADb+p3RN4gQRRp=2aphMy_UrhTpZUDdEyG_7-gBt++PRFQoJjg@mail.gmail.com>',NULL),('<1353972487.9027.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 23:28:07',0,'2012-11-26 23:28:07',NULL,'[openstack-dev] Python and OS version support','Hey,\n\nOn Mon, 2012-11-26 at 08:40 -0800, Monty Taylor wrote:\n> Hey all!\n> \n> I started a discussion during a TC meeting a little while ago that needs \n> more general input and feedback. The question at hand is \"what versions \n> of python and what versions of what distros do we care about as a project?\"\n\nThanks for doing this.\n\n> First of all, this isn\'t a discussion about what CI will test or what \n> we\'ll use for gating.  It\'s more of a conversation about what language \n> and OS assumptions developers can make when they are writing code, so \n> that design and review choices can be made.\n> \n> To put it more bluntly, if someone files a bug or a code review comment \n> that says:\n> \n> \"Blah doesn\'t work in python X\"\n> \n> When can we respond \"not a bug/won\'t fix\" with a clear conscience?\n> \n> When we first started the project, we said out loud that development was \n> always focused on the current release of Ubuntu and that\'s it. We picked \n> that because doing _development_ targeting a bazillion distro options at \n> the same time gets hairy quickly, and I think the clarity served has us \n> well. But I\'m pretty sure things have changed since then - latest Ubuntu \n> does not come with python 2.6, for instance, but we still seem to care \n> about it.\n\nYeah, I think it\'s pretty obvious that things have moved on a little\nsince then.\n\n> With that background, I\'d like to start things off by proposing the \n> following:\n> \n> a) We continue to focus development efforts of master on the latest \n> release of Ubuntu with python libraries coming from PyPI.\n\nI\'d say \"latest release of Fedora\" too - e.g. devstack not working on\nthe latest Fedora release would be understood as a bug by everyone IMHO.\n\nI wouldn\'t discount us saying \"latest release of Debian or SuSE\" too.\nI\'m not just clear whether that\'s already the reality (i.e. we work on\ntwo recent distros, other recent distros \"just work\" and no-one says\nanything\") or whether it really is just Ubuntu or Fedora we are\nconsistently in good shape on.\n\n> b) We don\'t introduce things into master that would be unworkable on \n> either latest Ubuntu LTS or latest RHEL.\n\nNever say never. Honestly, if someone showed up with fairly well\nadvanced support for Python 3.x and that meant we absolutely had to drop\nPython 2.6 support, I\'d be the first to say we should do it.\n\nIf that happened, Red Hat (and others) would have to just suck it up and\nmaintain patches for 2.6 support. I\'d think we (as a project) would\nprovide whatever assistance is reasonable, though.\n\nBut ... that\'s theoretical at this point. I don\'t see any evidence of\nimminent, complete and solid 3.x support.\n\n> Logistically, because of our development focus on pypi modules in \n> virtualenvs, this doesn\'t affect much for developers outside of base \n> python versions and a few things that can\'t go in a virtualenv like \n> libvirt or the kernel. Since RedHat and Canonical have both committed to \n> maintaining special backport repos for those things for users of RHEL \n> and Ubuntu LTS, I don\'t think in practice it\'s going to have much of a \n> noticeable impact.\n> \n> Except where it comes to base python versions.\n> \n> If we take the above to be correct, it has the following effect:\n> \n> - We need to care about python 2.6 compatibility until such a time as \n> there is a RHEL that has 2.7 in it.\n\nYes, but even then I don\'t see why we\'d actively work to drop 2.6\nsupport if no-one was working on 3.x support. The emphasis should be on\ndoing new, positive stuff rather than dropping support for stuff.\n\n> - 2.7 should be our current dev focus, so if possible we should code to \n> 2.7 libs and then use backport packages like unittest2 to make 2.6 happy.\n\nYep.\n\n> - We can\'t REALLY start thinking about Python3 in earnest until a RHEL \n> release comes out with python 2.7, because 2.7/3.3 are needed for \n> source-code compatible code\n\nHonestly, if there was a determined group of people ready to make 3.x\nsupport happen, I think a tonne of progress could be made (e.g. in side\nbranches) while the project itself continues to support 2.6.\n\nAn obvious example is eventlet - if there\'s no sign of eventlet being\nsupported on Python 3, then the first job for a group of determined\nPython 3 hackers is to move us off eventlet. That doesn\'t (necessarily)\nimmediately require us to drop 2.6 support.\n\n> Net result - pretty much exactly what we\'re doing today, it just gets it \n> down on paper a little better.\n> \n> Thoughts? Disagreements?\n\nAgree pretty much :)\n\nCheers,\nMark.\n\n\n\n','<50B39B6F.7000304@inaugust.com>',NULL),('<1353973563.4350.2.camel@eharney.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-26 18:46:03',-18000,'2012-11-26 23:46:03',NULL,'[openstack-dev] [Cinder] LIO support in Cinder','Hi everyone,\n\nI\'ve posted a blueprint for supporting the LIO (linux-iscsi.org) target\nin Cinder.  This leverages targetd to interface with LIO, and will be\nimplemented as an alternative target within the iSCSI driver.\n\nA detailed spec has not been posted yet, but I would like to welcome\nhigh-level feedback on this as a feature and start discussion around it.\n\nhttps://blueprints.launchpad.net/cinder/+spec/lio-support-via-targetd\n\nThank you,\nEric\n\n\n\n\n',NULL,NULL),('<1353978332.951111926@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-26 19:05:32',-21600,'2012-11-27 01:05:32',NULL,'[OpenStack Foundation] Member Profile pages November 26','This page is now live, which means you can begin nominating members for the upcoming January Board election.  We\'ve worked to improve the nomination system so that it\'s more automated (for example, if you receive a nomination you will get an email).  If you run into any bugs, please let me know.\n\nhttps://www.openstack.org/election/2013-board-election/\n\nInstructions and useful links can be found there.\n\nThanks to Tim Bell, Lloyd Dewolf, and Vincent Untz for volunteering to help with the page content.\n\nProfiles for all members are also live.  You can log on to your profile at openstack.org/profile to update it, and you will find useful Election related links there as well.\n\n\n\nOn Wednesday, November 21, 2012 12:34pm, \"Mark Collier\" <mark at openstack.org> said:\n\n> As I mentioned below, I\'m finalizing the copy for the main election page now,\n> which will go live on Monday 11/26 at this url: \n> https://www.openstack.org/election/2013-board-election/\n> \n> Tim Bell has volunteered to help review the content and make sure it hits the mark\n> for accuracy and completeness.  If anyone else would like to give it a read\n> through, let me know.\n> \n> Mark\n> \n> \n> On Monday, November 19, 2012 6:03pm, \"Mark Collier\" <mark at openstack.org> said:\n> \n>>\n>> TL;DR: UPDATE YOUR PROFILE AT OPENSTACK.ORG/PROFILE BY 11/26\n>>\n>> On Monday, November 26, we will be publishing public profiles for all members,\n>> which will include a subset of the information members provided when joining:\n>> - Name- Affiliation(s)- Statement of Interest- IRC Handle- Twitter Handle-\n>> Projects involved with- Join Date- Your Nominations- Photo (coming soon,\n>> optional).\n>>\n>> The list of members is already public on the site, so this just expands on that\n>> with some additional information.  I think this will be a good way to get to know\n>> each other better as a community.  Here is a sample profile:\n>> https://www.openstack.org/community/members/sample-profile/\n>>\n>> I\'ll be sending an email to all members shortly with more information. Please\n>> make\n>> sure your profile is up to date, including your email address so that you can\n>> receive member updates. Login now: openstack.org/profile\n>>\n>> Per the election timeline Jonathan posted, nominations will also start on Monday\n>> November 26th.  Once the nomination process is underway and candidates have\n>> received 10 nominations and filled out the application, their responses will also\n>> appear on their public profile.\n>>\n>> We are also working on an overall election page to go live 11/26 which will live\n>> here: http://www.openstack.org/election/2013-board-election/ and provide clear\n>> instructions for voters to ensure a smooth election. If anyone would like to help\n>> with the content for that page, let me know. I plan to start with the basic info\n>> from 2012 page (http://www.openstack.org/election/2012-board-election/), update\n>> and expand to ensure we are as clear and informative as possible.\n>>\n>> As a reminder, here is the overall timeline:\n>>\n>>\n>> Election Timeline:\n>> - November 26: Individual Member nominations open, election details live on\n>> openstack.org\n>> - December 7: Individual Member nominations close\n>> - December 14: Deadline for Individual Member Nominees to complete application\n>> - January 3: Gold Member Director Selector Election (1 day)\n>> - January 14: Individual Member Elections open\n>> - January 18: Individual Member Elections close\n>>\n>> Mark\n>>\n>>\n> \n> \n\n\n\n\n','<1353522840.5521935@emailsrvr.com>',NULL),('<1354017081.9027.54.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 11:51:21',0,'2012-11-27 11:51:21',NULL,'[openstack-dev] Python and OS version support','On Tue, 2012-11-27 at 10:52 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > Never say never. Honestly, if someone showed up with fairly well\n> > advanced support for Python 3.x and that meant we absolutely had to drop\n> > Python 2.6 support, I\'d be the first to say we should do it.\n> > \n> > If that happened, Red Hat (and others) would have to just suck it up and\n> > maintain patches for 2.6 support. I\'d think we (as a project) would\n> > provide whatever assistance is reasonable, though.\n> \n> I\'d really prefer if we could have a clear house rule, rather than a set\n> of ad-hoc decisions that nobody can anticipate. That doesn\'t mean we\n> can\'t have exceptions to the rule in really odd corner cases (say, if\n> RHEL decides the next version will actually be in 2025). But, in absence\n> of exceptions, everyone should know what the default rule is.\n\nThe clear house rule is \"we support latest RHEL\" but we can anticipate\nan exception to that.\n\nWe don\'t want to discourage people from working on Python 3 support now\nnor do we want to give the impression that we\'ll ditch 2.6 support the\nday RHEL7 comes out. Neither makes any sense.\n\nThe reality isn\'t hard to explain:\n\n  The project has two apparently conflicting goals - supporting \n  RHEL6-era distros (i.e. Python 2.6) and adopting Python 3 support\n  ASAP. In the absence of a group of developers making determined \n  efforts to bring us closer to Python 3 support and being hampered by\n  the requirement to support Python 2.6, we will continue to support\n  Python 2.6.\n\nCheers,\nMark.\n\n\n\n','<50B48D49.3060307@openstack.org>',NULL),('<1354025855.9027.63.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 14:17:35',0,'2012-11-27 14:17:35',NULL,'[openstack-dev] Python and OS version support','On Tue, 2012-11-27 at 12:52 +0000, Daniel P. Berrange wrote:\n> On Mon, Nov 26, 2012 at 11:28:07PM +0000, Mark McLoughlin wrote:\n> > \n> > > b) We don\'t introduce things into master that would be unworkable on \n> > > either latest Ubuntu LTS or latest RHEL.\n> > \n> > Never say never. Honestly, if someone showed up with fairly well\n> > advanced support for Python 3.x and that meant we absolutely had to drop\n> > Python 2.6 support, I\'d be the first to say we should do it.\n> \n> I\'m of the opposite opinion really. There may be nice things in Python\n> 3.x, but when it actually comes down to it, the choice of 2.x vs 3.x\n> has little-to-no bearing on what features OpenStack supports, what\n> its user experience is, and what its deployment model is. What does make\n> a negative experiance as a person deploying / using OpenStack, is finding\n> out that your platform is too old and being forced to upgrade, or more\n> likely switch to an alternative cloud technology which does support your\n> current platform. IMHO, supporting Python 3.x adds little, and if it means\n> dropping 2.6 support, it could be considered actively harmful overall.\n> \n> Meanwhile there are plenty of things we could be doing to improve the\n> quality / scalability / ease of deployment for OpenStack that are\n> relevant to both 2.x and 3.x and would have much more significant\n> benefit for end users / deployers / vendors. eg switch to use a real\n> OS threading system so we can actually utilization large SMP hosts\n> effectively\n\nMostly agree with all that, but the way I see the Python 3 issue is that\nPython 2 is eventually going to go away and we\'re going to need multiple\nrelease cycles of determined effort to be prepared for that.\n\nIf there was a group showing that they are prepared to put in that\ndetermined effort, I\'d prefer to support them rather than block that\nprogress.\n\nIf and when that time comes, though, I\'d expect another group to be\nprepared to put in a determined effort to maintain 2.6 support (somehow)\nalongside the 3.x support. Those two groups would have to just muddle\nthrough somehow, perhaps not sharing the same branch.\n\nMy point is pretty simple - no-one should feel that there are rules or\nmandates that prevents them getting starting on 3.x support.\n\nCheers,\nMark.\n\n\n\n','<20121127125215.GI24370@redhat.com>',NULL),('<1354029350.757824928@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-11-27 09:15:50',-21600,'2012-11-27 15:15:50',NULL,'[OpenStack Foundation] Nominations NOW OPEN, Dec 7th Deadline','All of the election details are here:\nhttps://www.openstack.org/election/2013-board-election/\n\nKey points:  December 7th is the deadline for a candidate to receive 10 nominations from members.  All candidates must also complete an application to be eligible.\n\nIf you are interested in running, don\'t delay!  Get your 10 nominations and your application completed as soon as possible.  You can complete the application immediately, by visiting openstack.org/profile and clicking the \"Election\" tab.  \n\nYou can also visit openstack.org/profile and click the \"public profile\" to see how your public profile looks.  This is the URL you can then share with members to tell them what you\'re all about!  Once you complete the application, that additional detail will also appear as \"Q&A\" on your profile.  Every profile has a \"nominate\" button on it, so share your public profile URL if you want to ask for nominations.\n\nDon\'t delay!  \n\nMark\n\n\n\n\n\n',NULL,NULL),('<1354034750.9027.74.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 16:45:50',0,'2012-11-27 16:45:50',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Tue, 2012-11-27 at 08:21 -0800, Monty Taylor wrote:\n> I think it\'s important to think about what it means to have  6-month\n> lead time between landing a feature in oslo and it being able to be\n> used in any of the projects. So I agree that other projects should\n> only consume new oslo apis if they\'ve been released, and I agree about\n> not publishing dev versions to PyPI - I would counsel against setting\n> them on the hard-and-fast rule of the 6-month core project release\n> cycle. \n> (obviously, you can always NOT release something if it\'s not ready) \n\nWait, wait - you misunderstood me.\n\nOslo libraries would have a 6 month development cycle. At the end of the\n6 months, Oslo libraries would be released as part of the co-ordinated\nOpenStack release and also pushed to PyPI. Similarly, releases from the\nstable branch of Oslo libraries would be released along with other core\nproject stable releases.\n\nDuring the 6 months of development, we\'d do regular snapshot releases of\nthe libraries and the development branches of core OpenStack projects\nwould be able to consume those releases. A snapshot release would just\nbe our way of communicating with other core projects that new APIs are\nready for consumption.\n\nOpenStack milestone releases would include the latest snapshot releases\nof Oslo libraries. Within a milestone, we have the opportunity to fixup\nAPI design issues with incompatible changes between snapshots.\n\nThe logistics question is about how to make snapshot releases available\nand allow core projects consume them.\n\nDuring development, would there be any issue with just using tarball\nURLs in pip-requires? e.g.\n\n  https://launchpad.net/oslo-config/grizzly/grizzly-2.4/+download/oslo-config-2012.2~g2.4.tar.gz\n\nLeading up to final release time, we\'d publish the Oslo library releases\nearly to PyPI and update pip-requires to use:\n\n  oslo-config>=2012.2\n\nThe thing is, we don\'t want to publish dev versions of Oslo to PyPI but\nwe *do* want the dev branches of other core projects to be able to use\ndev versions of Oslo.\n\nCheers,\nMark.\n\n\n\n','<50B4E89D.6010006@inaugust.com>',NULL),('<1354042304.4350.10.camel@eharney.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 13:51:44',-18000,'2012-11-27 18:51:44',NULL,'[openstack-dev] [Cinder] LIO support in Cinder','On Tue, 2012-11-27 at 12:41 -0500, Russell Bryant wrote:\n> On 11/27/2012 11:38 AM, Christoph Hellwig wrote:\n> > On Tue, Nov 27, 2012 at 08:12:59AM -0800, Vishvananda Ishaya wrote:\n> >> for this. It seems like the fastest path to using LIO would be to simply\n> >> extend the tgt code to be able to use targetcli[1] in addition to tgtadmin\n> >> and ietadmin. That seems like literally a few days of work.\n> >>\n> >> Integrating targetd sounds more complicated and I think it would be better\n> >> done with its own driver. If you are managing volumes remotely I don\'t think you\n> >> are going to get much benefit out of sharing the existing target code.\n> >>\n> >> Would you consider a dual approach? A quick-and-dirty version using targetcli\n> >> to get lio support in, followed by a more general driver using targetd?\n> > \n\nI hadn\'t considered the dual approach idea before -- do we think it\nwould be beneficial?  I\'m not convinced it would be much quicker, since\nwe likely have to do some amount of work to fix targetcli.  (See below.)\n\n> > I think the \"simple\" driver using targetcli would fit the current cinder\n> > model fairly well.  It would essentially just plug another class into\n> > the abstraction between TgtAdm and IetAdm provided by\n> > get_target_admin().\n> \n> IIRC, targetcli doesn\'t provide any usable way to detect errors (return\n> codes or pareseable output).  If I\'m wrong, or if we can help improve\n> that, that sounds ok to me.\n> \n\nYes, this was the main issue I saw with using targetcli.  It seems to be\ndesigned mostly for interactive use.\n\n> > The way I understand targetd (and Andy may have to correct me) it\n> > actually managed the backend storage using e.g. LVM as well.\n> \n> Agreed that it seems to make more sense for targetd to be its own Cinder\n> driver.\n> \n\nThis is ok with me.\n\n\n\n','<50B4FB57.5010604@redhat.com>',NULL),('<1354043087.4350.21.camel@eharney.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 14:04:47',-18000,'2012-11-27 19:04:47',NULL,'[openstack-dev] [Cinder] LIO support in Cinder','On Mon, 2012-11-26 at 20:22 -0500, Russell Bryant wrote:\n> On 11/26/2012 06:46 PM, Eric Harney wrote:\n> > Hi everyone,\n> > \n> > I\'ve posted a blueprint for supporting the LIO (linux-iscsi.org) target\n> > in Cinder.  This leverages targetd to interface with LIO, and will be\n> > implemented as an alternative target within the iSCSI driver.\n> > \n> > A detailed spec has not been posted yet, but I would like to welcome\n> > high-level feedback on this as a feature and start discussion around it.\n> > \n> > https://blueprints.launchpad.net/cinder/+spec/lio-support-via-targetd\n> \n> Thanks, Eric!\n> \n> I have one implementation question.  You mention that this will be\n> implemented as an alternative target within the iSCSI driver.  Why not\n> make it its own driver?\n> \n> IIRC, the iSCSI driver is built around exposing local storage.  A\n> targetd driver would be managing remote storage resources, so it seems\n> to be a different model.\n> \n> Thoughts?\n> \n\nThinking about this a bit more, it does probably make sense for it to be\nits own driver, which would be consistent with many of the other drivers\nfor remote storage resources.\n\nI\'m not too clear on where the line is here (between iSCSI vs. other\ndriver), but your reasoning sounds right to me.\n\n\n\n\n','<50B415D0.20402@redhat.com>',NULL),('<1354060676.9027.91.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-27 23:57:56',0,'2012-11-27 23:57:56',NULL,'[Openstack-stable-maint] 2012.2.1 status - locking it down','Hey,\n\nWe\'re still hoping to releasing 2012.2.1 on Thursday but we need to lock\nthings down now to allow last minute regression testing.\n\nSo, please don\'t approve any more fixes for the branch until after the\nrelease. If there\'s something you think warrants an exception, leave a\n+2 with a comment explaining you\'re thinking and I\'ll make the call as\nrelease manager.\n\nWe\'ve had a huge amount of activity in the last week, so I\'m a little\nnervous that we might have broken something. The current \"bugs fixed\"\ntallies are:\n\n   79 nova\n   33 quantum\n   11 glance\n    7 keystone\n    3 cinder\n    1 horizon\n  134 total\n\nThings to note:\n\n  * It looks like there might be a regression on stable/folsom with \n    ceph/rbd:\n\n      https://bugs.launchpad.net/nova/+bug/1083818\n\n    Adam Gandelman and Josh Durgin are chasing it.\n\n  * There\'s a very serious known issue with the image cache cleanup \n    code when you\'re using shared storage:\n\n      https://bugs.launchpad.net/nova/+bug/1078594\n\n    The fix is invasive and risky, but there\'s a known workaround (i.e. \n    disable the image cache manager) which Vish has documented in the \n    release notes.\n\n    We may just disable the image cache manager by default for the \n    release.\n\n  * The Quantum linuxbridge plugin fix which allows us to move away from\n    using libvirt\'s type=\"ethernet\" has been merged, but it isn\'t \n    really useful without the corresponding change to the Nova VIF \n    driver.\n\n       https://review.openstack.org/16223\n\n    Given the limited number of users affected, maybe we can consider\n    merging the Nova change before the release too.\n\n    One detail here is that if we merge the Nova VIF change, we would \n    need to warn users to update Quantum before Nova. \n\n  * Please add stuff to the release notes as it occurs to you:\n\n      http://wiki.openstack.org/ReleaseNotes/2012.2.1\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1354107478.2230.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 12:57:58',0,'2012-11-28 12:57:58',NULL,'[Openstack-stable-maint] 2012.2.1 status - locking it down','On Tue, 2012-11-27 at 23:57 +0000, Mark McLoughlin wrote:\n\n>   * There\'s a very serious known issue with the image cache cleanup \n>     code when you\'re using shared storage:\n> \n>       https://bugs.launchpad.net/nova/+bug/1078594\n> \n>     The fix is invasive and risky, but there\'s a known workaround (i.e. \n>     disable the image cache manager) which Vish has documented in the \n>     release notes.\n> \n>     We may just disable the image cache manager by default for the \n>     release.\n\nIs it sufficient to just set remove_unused_base_images to False by\ndefault?\n\nCheers,\nMark.\n\n\n\n','<1354060676.9027.91.camel@sorcha>',NULL),('<1354123029.2230.18.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 17:17:09',0,'2012-11-28 17:17:09',NULL,'[Openstack-stable-maint] Patch\n https://review.openstack.org/#/c/17036/','Hey,\n\nOn Wed, 2012-11-28 at 12:21 +0200, Gary Kotton wrote:\n> Hi,\n> There is valid concern about the upgrade procedure with this patch. \n> There is a way that we are able to do this without creating an major \n> problems:\n> 1. Leave the class QuantumLinuxBridgeVIFDriver unchanged\n> 2. Add in a new class QuantumLinuxBridgeVIFDriverEnhanced (or if someone \n> has a better name). This class will contain the changes. If someone \n> wants to benefit fro the changes then she/he will need to update their \n> configuration file to:\n>      \n> libvirt_vif_driver=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriverEnhanced\n> This can be documented and it may treat all of the concerns. Naturally a \n> patch upstream will need to be added so that this wil be forward compatible.\n\nYeah, I think this would work well - linuxbridge users are no longer\nrequired to update Quantum before Nova, they just need to update Quantum\nbefore using the new VIF driver.\n\nSo, yep - go for it IMHO. It\'ll have to wait until after 2012.2.1 though\nand will have to happen on master too.\n\nCheers,\nMark.\n\n\n\n','<50B5E5B9.3020204@redhat.com>',NULL),('<1354123787.2230.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 17:29:47',0,'2012-11-28 17:29:47',NULL,'[Openstack-stable-maint] 2012.2.1 status - locking it down','On Tue, 2012-11-27 at 23:57 +0000, Mark McLoughlin wrote:\n\n>   * It looks like there might be a regression on stable/folsom with \n>     ceph/rbd:\n> \n>       https://bugs.launchpad.net/nova/+bug/1083818\n> \n>     Adam Gandelman and Josh Durgin are chasing it.\n\nAdam did an awesome job of bisecting and fixing this issue:\n\n  https://bugs.launchpad.net/cinder/+bug/1083818\n\nIt appears that it needs to be backported to cinder stable/folsom too\n\nCheers,\nMark.\n\n\n\n','<1354060676.9027.91.camel@sorcha>',NULL),('<1354123885.2230.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 17:31:25',0,'2012-11-28 17:31:25',NULL,'[Openstack-stable-maint] Patch\n https://review.openstack.org/#/c/17036/','On Wed, 2012-11-28 at 17:22 +0000, Daniel P. Berrange wrote:\n> On Wed, Nov 28, 2012 at 05:17:09PM +0000, Mark McLoughlin wrote:\n> > Hey,\n> > \n> > On Wed, 2012-11-28 at 12:21 +0200, Gary Kotton wrote:\n> > > Hi,\n> > > There is valid concern about the upgrade procedure with this patch. \n> > > There is a way that we are able to do this without creating an major \n> > > problems:\n> > > 1. Leave the class QuantumLinuxBridgeVIFDriver unchanged\n> > > 2. Add in a new class QuantumLinuxBridgeVIFDriverEnhanced (or if someone \n> > > has a better name). This class will contain the changes. If someone \n> > > wants to benefit fro the changes then she/he will need to update their \n> > > configuration file to:\n> > >      \n> > > libvirt_vif_driver=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriverEnhanced\n> > > This can be documented and it may treat all of the concerns. Naturally a \n> > > patch upstream will need to be added so that this wil be forward compatible.\n> > \n> > Yeah, I think this would work well - linuxbridge users are no longer\n> > required to update Quantum before Nova, they just need to update Quantum\n> > before using the new VIF driver.\n> > \n> > So, yep - go for it IMHO. It\'ll have to wait until after 2012.2.1 though\n> > and will have to happen on master too.\n> \n> I don\'t much like that we\'d be supporting this duplicate class\n> in Grizzly too. IMHO it is right that users of the existing\n> code on Folsom, automatically get the new code when switching\n> to Grizzly with no re-configuration.\n\nFair, but the new class name that we add to the Folsom branch needs to\ncontinue to work when people update to Grizzly.\n\ni.e. two classes that do the same thing on Grizzly, but do different\nthings on Folsom\n\nCheers,\nMark.\n\n\n\n','<20121128172206.GD29387@redhat.com>',NULL),('<1354124809.2230.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 17:46:49',0,'2012-11-28 17:46:49',NULL,'[Openstack-stable-maint] 2012.2.1 status - locking it down','On Wed, 2012-11-28 at 12:57 +0000, Mark McLoughlin wrote:\n> On Tue, 2012-11-27 at 23:57 +0000, Mark McLoughlin wrote:\n> \n> >   * There\'s a very serious known issue with the image cache cleanup \n> >     code when you\'re using shared storage:\n> > \n> >       https://bugs.launchpad.net/nova/+bug/1078594\n> > \n> >     The fix is invasive and risky, but there\'s a known workaround (i.e. \n> >     disable the image cache manager) which Vish has documented in the \n> >     release notes.\n> > \n> >     We may just disable the image cache manager by default for the \n> >     release.\n> \n> Is it sufficient to just set remove_unused_base_images to False by\n> default?\n\n>From IRC:\n\n<vishy> yeah although I think setting the interval=0 might be better\n<vishy> since it will be going crazy md5summing on shared storage and still running all the logic otherwise\n<vishy> so it may not delete images but I suspect the performance will still be horrible\n\nCheers,\nMark.\n\n\n\n','<1354107478.2230.1.camel@sorcha>',NULL),('<1354125161.2230.23.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-28 17:52:41',0,'2012-11-28 17:52:41',NULL,'[Openstack-stable-maint] 2012.2.1 status - locking it down','On Wed, 2012-11-28 at 17:46 +0000, Mark McLoughlin wrote:\n> On Wed, 2012-11-28 at 12:57 +0000, Mark McLoughlin wrote:\n> > On Tue, 2012-11-27 at 23:57 +0000, Mark McLoughlin wrote:\n> > \n> > >   * There\'s a very serious known issue with the image cache cleanup \n> > >     code when you\'re using shared storage:\n> > > \n> > >       https://bugs.launchpad.net/nova/+bug/1078594\n> > > \n> > >     The fix is invasive and risky, but there\'s a known workaround (i.e. \n> > >     disable the image cache manager) which Vish has documented in the \n> > >     release notes.\n> > > \n> > >     We may just disable the image cache manager by default for the \n> > >     release.\n> > \n> > Is it sufficient to just set remove_unused_base_images to False by\n> > default?\n> \n> From IRC:\n> \n> <vishy> yeah although I think setting the interval=0 might be better\n> <vishy> since it will be going crazy md5summing on shared storage and still running all the logic otherwise\n> <vishy> so it may not delete images but I suspect the performance will still be horrible\n\nReview posted:\n\n  https://review.openstack.org/17064\n\nCheers,\nMark.\n\n\n\n','<1354124809.2230.22.camel@sorcha>',NULL),('<1354231012.2230.185.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2012-11-29 23:16:52',0,'2012-11-29 23:16:52',NULL,'[openstack-announce] [ANNOUNCE] OpenStack Nova, Glance, Keystone,\n Cinder, Quantum and Horizon 2012.2.1 released','Hey,\n\nIn the time since the Folsom release, we have been busy selectively\nback-porting bugfixes to the stable/folsom branch according to our \"safe\nsource of high-impact fixes\" criteria documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nWe\'re happy to announce the 2012.2.1 release, the first in the series of\nreleases to make available the bugfixes from stable/folsom.\n\nThese releases are bugfix updates to Folsom and are intended to be\nrelatively risk free with no intentional regressions or API changes.\n\nA total of 139 bugs have been fixed in this release, which is a higher\nthan the usual volume of fixes in a stable release.\n\nThe list of bugs fixed can be seen here:\n\n  https://launchpad.net/nova/folsom/2012.2.1\n  https://launchpad.net/glance/folsom/2012.2.1\n  https://launchpad.net/keystone/folsom/2012.2.1\n  https://launchpad.net/cinder/folsom/2012.2.1\n  https://launchpad.net/quantum/folsom/2012.2.1\n  https://launchpad.net/horizon/folsom/2012.2.1\n\nPlease read (and add to!) the release notes at:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.2.1\n\nEnjoy!\n\nMark.\n\n\n\n',NULL,NULL),('<1354283126.2230.213.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-30 13:45:26',0,'2012-11-30 13:45:26',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Mon, 2012-11-26 at 22:40 +0000, Mark McLoughlin wrote:\n> On Fri, 2012-11-23 at 11:55 +0100, Thierry Carrez wrote:\n> > There seem to be two options there: just push everything on the same\n> > PyPI module, or have multiple PyPI modules for each series. I\'d say\n> > the latter looks worse.\n> \n> I don\'t really buy that unstable development releases of Oslo have to go\n> to PyPI in order for core projects to be able to consume them.\n> \n> pip supports http:// URLs of tarballs. Why not use that during\n> development?\n\nI\'m kinda waiting for opinions on this :-)\n\nCheers,\nMark.\n\n\n\n','<1353969604.2927.83.camel@sorcha>',NULL),('<1354384531.11.1353543145813.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-22 00:12:25',0,'2012-11-22 00:12:25',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #52','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/52/>\n\n\n\n','<76655569.165.1353456768394.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1354533793.9900.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-03 11:23:13',0,'2012-12-03 11:23:13',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Fri, 2012-11-30 at 13:55 -0800, Monty Taylor wrote:\n> Hey Matt!\n> \n> On 11/30/2012 01:24 PM, Matt Joyce wrote:\n\n> > 2.  Second Concern - .git derives our versioning\n> > \n> > First, thank god for the versioninfo file.  Without it, cinderclient\n> > would be unbuildable in certain situations.\n> \n> Totally. It\'s pretty important.\n> \n> > It boils down to this logic:\n> > \n> > from cinderclient/openstack/common/setup.py  ( which btw is common\n> > SOLELY to cinderclient every other client does this logic in a different\n> > yet standard fashion ).\n> \n> I did not realize cinderclient had diveged. We should fix that. (patch\n> coming)\n> \n> > def get_post_version(projectname):\n> >     \"\"\"Return a version which is equal to the tag that\'s on the current\n> >     revision if there is one, or tag plus number of additional revisions\n> >     if the current revision has no tag.\"\"\"\n> > \n> >     if os.path.isdir(\'.git\'):\n> >         version = _get_git_post_version()\n> >         write_versioninfo(projectname, version)\n> >         return version\n> >     return open(os.path.join(projectname, \'versioninfo\'),\n> > \'r\').read().strip()\n> > \n> > This basically says either grab the version from .git, or the\n> > versioninfo file.  Except that generating the versioninfo file requires\n> > .git.\n> \n> \n> Well, there is a bug in the logic there. Currently it tries to keep the\n> versioninfo file up to date at all costs, so if it finds that it has a\n> git repo, it will recreate the versioninfo file.\n> \n> Except that makes evil for git-buildpackage. Sorry, I just didn\'t catch it.\n> \n> The fix for that is to always trust the versioninfo file if it exists.\n> Since it gets created on tarball creation as part of our release\n> process, it should never not be there - and to only fall back to git if\n> the versioninfo file does not exist.\n> \n> I can come up with no valid situation where a person will have a copy of\n> the code with neither an upstream git repo OR a tarball generated\n> versioninfo file. (although please check me if I\'m wrong there)\n\nI saw the review[1] before this thread.\n\nAFAICT the logic you\'re proposing is:\n\n  if versioninfo exists:\n      version = read_versioninfo()\n  else:\n      version = do_some_git_magic()\n      write_versioninfo(version)\n  return version\n\nSo, if you clone a project, do something with setup.py, versioninfo gets\ncreated at that time and never gets re-created again?\n\nCheers,\nMark.\n\n[1] - https://review.openstack.org/17249\n\n\n\n','<50B92B5F.6080002@inaugust.com>',NULL),('<1354534363.9900.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-03 11:32:43',0,'2012-12-03 11:32:43',NULL,'[openstack-dev] [oslo] Oslo library versioning','On Mon, 2012-12-03 at 11:09 +0100, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > Actually, if we have some snapshot releases which look like this:\n> > 2012.2~G2~5 (for instance)\n> > \n> > That get turned in to python versions that look like this:\n> > 2012.2-alpha2.5  (for instance)\n> \n> Yes, that was one of the options I considered, translating into\n> something that PyPI actually supports. I tried to avoid that because it\n> makes us use two different-looking version numbers to represent the same\n> thing (2013.1~G2 = 2013.2-alpha2), but since for oslo libraries we\'ll\n> have to push intermediary versions between milestones anyway... it\'s no\n> longer a 1:1 match. So I guess it\'s not such a big deal.\n\nI don\'t think we can use PyPI for development/apha/milestone releases\nwhile PyPI has no way for us to ensure that \"pip install oslo-config\"\nwon\'t install a development snapshot.\n\ni.e. PyPI has only one stream and IMHO it only makes sense for that to\nbe our stable stream, not our development stream.\n\n> > Then I don\'t understand why we couldn\'t upload snapshots and real\n> > releases to pypi - and then have nova do:\n> > oslo-foo>=2012.2,<=2013.1\n> > In its pip-requires.\n> \n> That\'s what I proposed higher in the thread, but Mark replied:\n> \n> > I really, really hate version caps like that :)\n> \n> So I suspect there is no consensus yet about that...\n\nRight :)\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/003349.html\n\nA <=2013.1 cap is simply inaccurate and misleading.\n\nSay we ended up with this in the Grizzly release:\n\n  glance: oslo-config>=2013.1,<2013.2\n  nova: oslo-config>=2013.1,<2013.2\n\nand then the H release comes out:\n\n  glance: oslo-config>=2013.2,<2014.1\n  nova: oslo-config>=2013.2,<2014.1\n\nYou now cannot update Glance to the H release on a single system without\nbreaking the requirement conditions of the installed Nova Grizzly\npackage.\n\nAnd a big reason for wanting stable APIs in Oslo library packages is to\nallow those types of situations.\n\nCheers,\nMark.\n\n\n\n','<50BC7A47.2050203@openstack.org>',NULL),('<1354633493.21527.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-04 15:04:53',0,'2012-12-04 15:04:53',NULL,'[openstack-dev] Blueprint proposal: Drop setuptools_git for\n including data/config files','On Tue, 2012-12-04 at 15:43 +0100, Thierry Carrez wrote:\n> Ionu? Ar??ri?i wrote:\n> > On 12/04/2012 02:06 PM, Thierry Carrez wrote:\n> >> In summary, I would hate it if we went back to the previous situation.\n> >> I\'m not personally attached to setuptools_git, but any proposed\n> >> replacement solution should keep its simplicity.\n> > \n> > Maybe a solution could be to add a Jenkins hook for re-generating the\n> > MANIFEST.in file after each commit? Just like we currently have for\n> > updating the contributors email list?\n> \n> I suppose that could work, although I\'d wait on Monty\'s opinion before\n> moving on that :)\n> \n> Note that it\'s not just MANIFEST.in that needs updating, but also the\n> \"scripts\" entry in setup.py. Most developers just forgot to update it\n> when they added a new executable under bin/... and it needs updating\n> unless you rely on setuptools_git to handle that for you.\n> \n> Makes regenerating as a commit hook a bit more tricky (mix autogenerated\n> with authored content in a single file).\n\n(Excuse the hand-waving)\n\nIf setuptools_git generates a bunch of info from git when creating a\ntarball, you\'d think it would include that info in the tarball itself.\n\ni.e. if setuptools_git replaces the need for MANIFEST.in to be kept up\nto date, you\'d expect that a generated MANIFEST.in would be included in\nthe generated tarball.\n\nCheers,\nMark.\n\n\n\n','<50BE0C26.9010004@openstack.org>',NULL),('<1354637546.21527.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-04 16:12:26',0,'2012-12-04 16:12:26',NULL,'[openstack-dev] Making pbr an Oslo package','On Thu, 2012-11-29 at 10:36 -0800, Monty Taylor wrote:\n> \n> On 11/26/2012 02:01 PM, Mark McLoughlin wrote:\n\n> >    - If we still have a bunch of work to do here, isn\'t pbr effectively\n> >      in Incubation? Would it make sense to move it back into\n> >      oslo-incubator for a while? At least that would reduce the\n> >      confusion around the current stuff being stale.\n> \n> We could just ignore the pbr repo and consider the task \"extract \n> openstack.common.{version|setup} to oslo-build.\" OR, I could take the \n> refactoring in pbr and move that back in to oslo-incubator first, then \n> do the extraction. Or I could just rename pbr, give up on the setuptools \n> bootstrap issue and start migrating projects to it. I\'m game for any of \n> them...\n\nSorry for the slow response.\n\nThe second option would be my preference if you really are up for any of\nthe options - i.e. take the ideas from PBR, evolve the code in\noslo-incubator and then split it out as oslo-build.\n\nI\'ve updated the blueprint:\n\nhttps://blueprints.launchpad.net/oslo/+spec/oslo-build\n\nCheers,\nMark.\n\n\n\n','<50B7AB4A.9020700@inaugust.com>',NULL),('<1354656320.29592.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-04 21:25:20',0,'2012-12-04 21:25:20',NULL,'[Openstack-stable-maint] Nova regression in 2012.2.1','Hey\n\nFYI for anyone who hasn\'t seen it already:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.2.1\n\n  The default of the rpc_control_exchange option for Nova in this \n  release is \'openstack\' rather than \'nova\' - you need to explicitly set\n  it to \'nova\'. See https://bugs.launchpad.net/nova/+bug/1083944\n\nIn the project meeting just now Thierry and I discussed doing another\nquick point release with just this fix and any pending security issue\nthere might be. A snap 2012.2.2 this week might be possible.\n\nDepending on how soon we decide to do it, I may block other Nova fixes\nfrom stable/folsom in the meantime.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<135467424.78.1353110879512.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-17 00:07:59',0,'2012-11-17 00:07:59',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #9','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/9/>\n\n------------------------------------------\n[...truncated 4851 lines...]\n++ line=\'signing_dir = /tmp/keystone-signing-nova\'\n++ echo /tmp/keystone-signing-nova\n+ [[ -z /tmp/keystone-signing-nova ]]\n+ sed -i -e \'/^\\[filter:authtoken\\]/,/^\\[.*\\]/ s|^\\(signing_dir[ \\t]*=[ \\t]*\\).*$|\\1/var/cache/nova|\' /etc/nova/api-paste.ini\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net,postgresql, =~ ,n-cpu, ]]\n+ return 0\n+ sudo sysctl -w net.ipv4.ip_forward=1\nnet.ipv4.ip_forward = 1\n+ sudo modprobe nbd\n+ [[ kvm == \\k\\v\\m ]]\n+ sudo modprobe kvm\nFATAL: Module kvm not found.\n+ true\n+ \'[\' \'!\' -e /dev/kvm \']\'\n+ echo \'WARNING: Switching to QEMU\'\nWARNING: Switching to QEMU\n+ LIBVIRT_TYPE=qemu\n+ which selinuxenabled\n+ [[ qemu == \\l\\x\\c ]]\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net,postgresql, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net,postgresql =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 24503\n+ mkdir -p /opt/stack/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net,postgresql, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sudo iptables -S -v\n+ bash\n+ awk \'{print \"sudo iptables\",$0}\'\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ sudo iptables -S -v -t nat\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep \'\\-N\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ awk \'{print \"sudo iptables\",$0}\'\n+ bash\n+ sed s/-N/-X/g\n+ sudo iptables -S -v\n+ sudo iptables -S -v -t nat\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n++ grep instance-\n++ sudo virsh list --all\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ cut -d \' \' -f2\n+ grep volume-\n+ xargs sudo iscsiadm --mode node --logout\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ sudo iscsiadm --mode node --op delete\n+ grep volume-\n+ cut -d \' \' -f2\niscsiadm: no records found!\niscsiadm: no records found!\n+ true\n+ sudo rm -rf \'/opt/stack/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net,postgresql, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ xargs\n++ echo\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ [[ \'\' != \\F\\a\\l\\s\\e ]]\n+ PIP_MIRROR_OPT=--use-mirrors\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.2.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_compressor%2Fdjango_compressor-1.2.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \nDownloading/unpacking django-openstack-auth>=1.0.3 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.4.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.4.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nDownloading/unpacking pytz (from -r horizon.egg-info/requires.txt (line 10))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpytz%2Fpytz-2012h.tar.bz2\n  Running setup.py egg_info for package pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.5.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango-appconf%2Fdjango-appconf-0.5.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): prettytable in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-novaclient->-r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.2.1 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema==0.2 in /usr/local/lib/python2.7/dist-packages (from warlock<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2 in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, pytz, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth pytz django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2013.1 to easy-install.pth file\n\nInstalled /opt/stack/horizon\nProcessing dependencies for horizon==2013.1\nerror: Installed distribution python-keystoneclient 0.2.0 conflicts with requirement python-keystoneclient>=0.1.2,<0.2\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/devstacklog.txt.2012-11-17-000457\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/9/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<236115290.51.1353024547769.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1354719208.6557.28.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-05 14:53:28',0,'2012-12-05 14:53:28',NULL,'[openstack-dev] [keystone] Standardizing the approach to\n pip-requires dependencies','On Tue, 2012-12-04 at 21:41 -0800, Clark Boylan wrote:\n> There was a summit session on using a common dependency list and I think\n> the consensus there was to remove the upper bounds on dependencies where\n> possible (eg not sqlalchemy where version 0.8 breaks the current projects).\n\nYep, here\'s the notes from the session:\n\nhttp://etherpad.openstack.org/process-dependency-management\n\nUpper bounds shouldn\'t be used except where we know a library has (or\nmaybe - based on history - is extremely likely to) released a newer\nversion with an API change that breaks us. Our client libraries\ncertainly should be doing that.\n\n> Then, when stable branches for releases are cut, the dependencies for those\n> projects would have upper bounds added for the currently available versions\n> (the versions of dependencies that the gate will be testing against at that\n> time). That way changes in upstream don\'t break the stable branches. Might\n> be worth running this by markmc and/or mordred to make sure I am\n> remembering correctly.\n\nThere was some confusion about this - I wanted to pin the gating\ninfrastructure to specific versions, but didn\'t want to prevent\nusers/distros from using stable releases with newer versions of\nlibraries.\n\nAll summarized here:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html\n\n> Also, the above decisions were made assuming there would be a common\n> dependency list across openstack projects. Perhaps we should put more\n> resources behind that effort to reduce the occurrence of these odd\n> dependency problems.\n\nYes ... Monty and I have been driving a lot of the discussions around\nthis, but that doesn\'t mean others can\'t dive in and actually start\nfixing it :-)\n\nIMHO, the first thing is to go through all the pip-requires of our\nprojects and resolve places where there are conflicting requirements.\n\nCheers,\nMark.\n\n\n\n','<CAAcH74hUBMtp-OFmR46Nwx4D5QerFKnVDquDgE6FL33Oso0AaA@mail.gmail.com>',NULL),('<1354728419.2851.34.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-05 11:26:59',-21600,'2012-12-05 17:26:59',NULL,'[openstack-dev] [Keystone] unit test coverage','On Tue, 2012-12-04 at 22:10 -0500, Adam Young wrote:\n> keystone.identity.core           62%     No Big deal:  all the un \n> implemented functions. \n\nAs a point of information, you can add \"# Pragma: nocover\" to lines to\nmake them be skipped.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50BEBB13.20904@redhat.com>',NULL),('<1354736907.2851.37.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-05 13:48:27',-21600,'2012-12-05 19:48:27',NULL,'[openstack-dev] [Keystone] unit test coverage','On Wed, 2012-12-05 at 14:01 -0500, Adam Young wrote:\n> On 12/05/2012 12:26 PM, Kevin L. Mitchell wrote:\n> > On Tue, 2012-12-04 at 22:10 -0500, Adam Young wrote:\n> >> keystone.identity.core           62%     No Big deal:  all the un\n> >> implemented functions.\n> > As a point of information, you can add \"# Pragma: nocover\" to lines to\n> > make them be skipped.\n> Can you do that for an entire file?  We have certain files that are just \n> interface specifications, and we really don\'t expect the exceptions for \n> unimplemented to ever be thrown, at least not in a unit test.\n\nSupposedly you can use a configuration file to fine-tune file selection\nfor coverage purposes, but I haven\'t had any success with that (in\nconjunction with tox, at least).  I haven\'t tried it with adding the\nconfiguration file to the MANIFEST.in, though, so that could potentially\nhave an effect.  (To see what I\'m talking about, see .coveragerc in the\ntop-level of nova.)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<50BF9A21.508@redhat.com>',NULL),('<1354795133.26420.27.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-06 11:58:53',0,'2012-12-06 11:58:53',NULL,'[openstack-dev] HTTP response code for not implemented features','Hey,\n\nKevin raised a good point here:\n\n  https://review.openstack.org/17565\n\nCurrently attempting to set a host\'s status to disabled will fail with\n400 Bad Request (without any explanatory error message) if you\'re using\nthe libvirt driver.\n\nTo be clear, this is a PUT request containing a representation of the\ndesired status for the host and we don\'t support changing its status.\n\nI proposed changing this to return a 501 Not Implemented with an\nexplanatory message, but it\'s not clear that\'s correct either.\n\nThings to consider:\n\n  - 4xx codes are for client errors - is this a client error? There is \n    no way for a client to know that a cloud supports this without \n    trying it, so it\'s obviously something we expect clients to do.\n\n  - 400 explicitly states that clients should not retry the request \n    without modifications. That does apply here.\n\n  - 405 Method Not Allowed is only appropriate where a request method \n    isn\'t allowed. We do support PUT requests on host resources, just \n    not this particular request.\n\n  - 5xx codes \"indicate cases in which the server is aware that it has\n    erred or is incapable of performing the request\". The latter part \n    seems appropriate here.\n\n  - The 501 docs say:\n\n       The server does not support the functionality required to \n       fulfill the request. This is the appropriate response when the\n       server does not recognize the request method and is not capable\n       of supporting it for any resource. \n\n    The first sentence makes it seem like 501 is a good fit here. I \n    take the second sentence to be an example of one of cases where 501 \n    is appropriate, rather than the only case.\n\n\nI think I\'m still leaning towards 501. Any thoughts?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1354798011.26420.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-06 12:46:51',0,'2012-12-06 12:46:51',NULL,'[openstack-dev] HTTP response code for not implemented features','On Thu, 2012-12-06 at 05:32 -0700, Christopher B Ferris wrote:\n> Mark,\n> \n> \n> The term \"request method\" in the HTTP spec refers exclusively to the\n> tokens described in sect 5.1.1 Method (GET, PUT, POST, etc). Hence,\n> 405 and 501 are inappropriate, because they refer to situations where\n> the request method is not implemented, etc.\n\nI understand that line of thinking, but as I said:\n\n  \"I take the second sentence to be an example of one of cases where 501\n   is appropriate, rather than the only case\"\n\ni.e. the first sentence:\n\n  \"The server does not support the functionality required to fulfill the\n   request\"\n\ndoesn\'t mention request methods.\n\nCheers,\nMark.\n\n\n> I should think that 400 is appropriate,accompanied with a suitable\n> explanation (error message).\n> \n> Cheers,\n> \n> Christopher Ferris\n> IBM Distinguished Engineer, CTO Industry and Cloud Standards\n> Member, IBM Academy of Technology\n> IBM Software Group, Standards Strategy\n> email: chrisfer at us.ibm.com\n> Twitter: christo4ferris\n> phone: +1 508 234 2986\n> \n> On Dec 6, 2012, at 7:06 AM, \"Mark McLoughlin\" <markmc at redhat.com>\n> wrote:\n> \n> \n> > Hey,\n> > \n> > Kevin raised a good point here:\n> > \n> >   https://review.openstack.org/17565\n> > \n> > Currently attempting to set a host\'s status to disabled will fail with\n> > 400 Bad Request (without any explanatory error message) if you\'re using\n> > the libvirt driver.\n> > \n> > To be clear, this is a PUT request containing a representation of the\n> > desired status for the host and we don\'t support changing its status.\n> > \n> > I proposed changing this to return a 501 Not Implemented with an\n> > explanatory message, but it\'s not clear that\'s correct either.\n> > \n> > Things to consider:\n> > \n> >   - 4xx codes are for client errors - is this a client error? There is\n> >     no way for a client to know that a cloud supports this without\n> >     trying it, so it\'s obviously something we expect clients to do.\n> > \n> >   - 400 explicitly states that clients should not retry the request\n> >     without modifications. That does apply here.\n> > \n> >   - 405 Method Not Allowed is only appropriate where a request method\n> >     isn\'t allowed. We do support PUT requests on host resources, just\n> >     not this particular request.\n> > \n> >   - 5xx codes \"indicate cases in which the server is aware that it has\n> >     erred or is incapable of performing the request\". The latter part\n> >     seems appropriate here.\n> > \n> >   - The 501 docs say:\n> > \n> >        The server does not support the functionality required to\n> >        fulfill the request. This is the appropriate response when the\n> >        server does not recognize the request method and is not capable\n> >        of supporting it for any resource.\n> > \n> >     The first sentence makes it seem like 501 is a good fit here. I\n> >     take the second sentence to be an example of one of cases where 501\n> >     is appropriate, rather than the only case.\n> > \n> > \n> > I think I\'m still leaning towards 501. Any thoughts?\n> > \n> > Cheers,\n> > Mark.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n\n\n\n\n','<3FF7C9BC-51F3-491C-8E91-4C0E90BB3685@us.ibm.com>',NULL),('<1355149770.2187.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-10 14:29:30',0,'2012-12-10 14:29:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #68','Hi James\n\nAny idea what\'s going on here?\n\nCheers,\nMark.\n\nOn Sat, 2012-12-08 at 00:13 +0000, OpenStack Jenkins wrote:\n> See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/68/>\n> \n> ------------------------------------------\n> [...truncated 11052 lines...]\n> PASS aggregates\n> PASS bundle\n> PASS client-args\n> PASS euca\n> PASS floating_ips\n> PASS sec_groups\n> PASS swift\n> PASS volumes\n> =====================================================================\n> Running tempest smoke tests\n> nose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\n> Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\n> ERROR\n> ERROR\n> ERROR\n> ERROR\n> ERROR\n> ERROR\n> ERROR\n> \n> ======================================================================\n> ERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n>     addr.filename, addr.module)\n>   File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n>     return self.importFromDir(dir_path, fqname)\n>   File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n>     mod = load_module(part_fqname, fh, filename, desc)\n>   File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n>     CONFIG = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n>     super(UsersTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n>     super(BaseIdentityAdminTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n>     os = openstack.IdentityManager(interface=cls._interface)\n>   File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n>     conf = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n>     super(UsersTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n>     super(BaseIdentityAdminTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n>     os = openstack.IdentityManager(interface=cls._interface)\n>   File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n>     conf = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n>     super(VolumesActionsTest, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n>     cls.config = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n>     super(VolumesGetTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n>     super(BaseVolumeTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n>     cls.config = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n>     super(VolumesGetTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n>     super(BaseVolumeTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n>     cls.config = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n>     super(VolumeListTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n>     super(BaseVolumeTestJSON, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n>     cls.config = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ======================================================================\n> ERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n>     self.setUp()\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n>     self.setupContext(ancestor)\n>   File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n>     try_run(context, names)\n>   File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n>     return func()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n>     super(VolumeListTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n>     super(BaseVolumeTestXML, cls).setUpClass()\n>   File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n>     cls.config = config.TempestConfig()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n>     instances[cls] = cls()\n>   File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n>     raise RuntimeError(msg)\n> RuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n> \n> ----------------------------------------------------------------------\n> XML: nosetests-smoke.xml\n> ----------------------------------------------------------------------\n> Ran 1 test in 0.018s\n> \n> FAILED (errors=8)\n> Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\n> Build step \'Execute shell\' marked build as failure\n> [SCP] Connecting to static.openstack.org\n> [SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68\n> [SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-cleanup-host.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-setup-host.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstack-gate-setup-workspace-new.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/devstacklog.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/kern_log.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/localrc.txt\'\n> [SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/rabbit at devstack-1354921860-sasl.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/rabbit at devstack-1354921860.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/rabbitmq/startup_log.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-g-api.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-g-reg.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-horizon.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-key.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-api.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-cpu.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-crt.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-net.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-obj.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-sch.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-n-vol.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/screen-swift.txt\'\n> [SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/README.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/jenkins-sudo-grep.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.d/nova-rootwrap.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/sudoers.txt\'\n> [SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/68/logs/syslog.txt\'\n> [SCP] Connecting to static.openstack.org\n> [SCP] Copying console log.\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n\n\n','<1177811552.294.1354925628651.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1355157320.23.1372227250953.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-26 06:14:10',0,'2013-06-26 06:14:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #77','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/77/>\n\n------------------------------------------\n[...truncated 1168 lines...]\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_ssl.TestSSL.test_delete_not_existing\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_ssl.py\",> line 1250, in test_delete_not_existing\n    response, content = https.request(path, \'GET\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1060, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.94 secs:\n    26.62    TestScrubber.test_scrubber_app\n    21.04    TestScrubber.test_delayed_delete\n    15.51    TestRootApi.test_version_configurations\n    15.06    TestGlanceControl.test_reload\n    14.71    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 1101 tests in 642.018s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.45\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.77\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.11\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.17\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.5\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.tWtYCrq2J3\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/77\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/77/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1355157380.5912.13.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-10 10:36:20',-21600,'2012-12-10 16:36:20',NULL,'[openstack-dev] Why no test DB ?','On Mon, 2012-12-10 at 09:59 +1000, Matthew Sherborne wrote:\n> Why don\'t we create and destroy a test sqlite in memory database for\n> the tests instead of stubbing out the DB calls ?\n\nStubbing out the DB calls makes perfect sense for the unit tests, which\nhonestly should be (but isn\'t) the bulk of our test suite.  Using an\nin-memory database is exactly what should be happening for the function\ntests, and Monty\'s comment indicates that it is?\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CADf4zRKfmG6wcXmJ=9HbXTAig5MrZ=Gu4DjO99qP2GycHAsgnQ@mail.gmail.com>',NULL),('<1355225732.2187.44.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-11 11:35:32',0,'2012-12-11 11:35:32',NULL,'[openstack-dev] extracting nbd support to an oslo module?','On Tue, 2012-12-11 at 12:22 +0100, Thierry Carrez wrote:\n> Robert Collins wrote:\n> > I\'d like to be able to nbd from Python for part of diskimage-builder,\n\nContext wasn\'t obvious to me, but I found:\n\n  https://github.com/stackforge/diskimage-builder\n\n> > and the needed code for that is neatly in nova; but installing nova on\n> > sysadmin workstations just to get at that code is a little... ugly.\n> > \n> > Would there be any objections to moving the nbd code to an oslo\n> > module, and if not, whats the process for that? [possibly more than\n> > the nbd code - basically enough to get qcow2 images mounted :)].\n> \n> I\'ll let markmc reply on that, but oslo tends to be oriented towards\n> reusing common code between openstack core projects, not to extract\n> generally reusable pieces of code out of core projects for potential\n> reuse elsewhere... I feel like it\'s a slippery slope that could make us\n> lose our focus.\n\nYep, that\'s basically what I would have said too. I could be persuaded\notherwise, I guess, but I wouldn\'t see this particular API as being high\non the priority list for Oslo.\n\nAlso, I\'d recommend just using libguestfs for poking around in qcow2\nfiles from Python.\n\nCheers,\nMark.\n\n\n\n','<50C7178A.8030402@openstack.org>',NULL),('<1355226793.2187.53.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-11 11:53:13',0,'2012-12-11 11:53:13',NULL,'[openstack-dev] extracting nbd support to an oslo module?','On Tue, 2012-12-11 at 11:36 +0000, Daniel P. Berrange wrote:\n> On Tue, Dec 11, 2012 at 12:22:50PM +0100, Thierry Carrez wrote:\n> > Robert Collins wrote:\n> > > I\'d like to be able to nbd from Python for part of diskimage-builder,\n> > > and the needed code for that is neatly in nova; but installing nova on\n> > > sysadmin workstations just to get at that code is a little... ugly.\n> > > \n> > > Would there be any objections to moving the nbd code to an oslo\n> > > module, and if not, whats the process for that? [possibly more than\n> > > the nbd code - basically enough to get qcow2 images mounted :)].\n> > \n> > I\'ll let markmc reply on that, but oslo tends to be oriented towards\n> > reusing common code between openstack core projects, not to extract\n> > generally reusable pieces of code out of core projects for potential\n> > reuse elsewhere... I feel like it\'s a slippery slope that could make us\n> > lose our focus.\n> \n> It also implies that you\'d need to make promises about API stability\n> in Oslo. As long as Oslo is only intended for use by core projects,\n> can we make API changes in Olso & update all core projects to match.\n> Once you have users outside of the project, then we get locked into\n> supporting those APIs unchanged.\n\nTo be clear, Oslo\'s API stability commitment is that an API may be\ndeprecated in release N, maintained in N+1 and removed in N+2. This is\nso we don\'t force all projects to be updated together.\n\nBut yes, if Oslo had a lot more users than just OpenStack projects we\nwould have to make an even greater commitment to API stability.\n\nCheers,\nMark.\n\n\n\n','<20121211113602.GF25176@redhat.com>',NULL),('<1355326518.2220.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-12 15:35:18',0,'2012-12-12 15:35:18',NULL,'[openstack-dev] [CI] lockutils failures','On Wed, 2012-12-12 at 10:16 -0500, Eric Windisch wrote:\n> CI-team,\n> \n> Lockutils is failing its tests (oslo-incubator). The tests succeed\n> locally, so I suspect this is a problem with the filesystem on the\n> jenkins nodes. Thoughts?\n\n\nHere was the last attempt to fix it:\n\n  https://review.openstack.org/14556\n\nCheers,\nMark.\n\n\n\n','<FFD67D5D416C4C27BAE1101DD7A5CFE2@cloudscaling.com>',NULL),('<1355347477.964817014@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-12-12 15:24:37',-21600,'2012-12-12 21:24:37',NULL,'[OpenStack Foundation] Welcome Claire & Jim','I wanted to let everyone know that we have two new Stackers joining the OpenStack Foundation staff.  Claire Massey is joining us as Marketing Coordinator, and Jim Blair has joined us as an Infrastructure Engineer. Welcome Claire & Jim!\n\nWe still have openings for another Infrastructure Engineer, Community Manager, Marketing Manager, and Director of Business Development:  http://www.openstack.org/community/jobs/?foundation=1\n\nMark\n\n\n\n\n',NULL,NULL),('<1355435129.2220.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2012-12-13 21:45:29',0,'2012-12-13 21:45:29',NULL,'[openstack-announce] [ANNOUNCE] OpenStack Nova 2012.2.2 released','Hey,\n\nIn the time since the Folsom release, we have been busy selectively\nback-porting bugfixes to the stable/folsom branch according to our \"safe\nsource of high-impact fixes\" criteria documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nWe\'re now announcing the 2012.2.2 release of Nova, a snap release\ncontaining a security fix and a fix for a serious regression in\n2012.2.1.\n\nThis release is a bugfix update to Folsom and is intended to be\nrelatively risk free with no intentional regressions or API changes.\n\nThe list of bugs fixed can be seen here:\n\n  https://launchpad.net/nova/folsom/2012.2.2\n\nPlease read (and add to!) the release notes at:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.2.2\n\nEnjoy!\n\nMark.\n\n\n\n',NULL,NULL),('<1355583673.9724739.1412618081109.JavaMail.zimbra@zimbra.xlab.si>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-06 19:54:41',7200,'2014-10-06 17:54:41',NULL,'[Openstack-operators] Problem creating resizable CentOS\n	6.5	image','Try this:\n\nhttps://github.com/flegmatik/linux-rootfs-resize\n\n- Robert\n\n----- Original Message -----\nFrom: \"Antonio Messina\" <antonio.s.messina at gmail.com>\nTo: \"Robert van Leeuwen\" <Robert.vanLeeuwen at spilgames.com>\nCc: openstack-operators at lists.openstack.org\nSent: Friday, October 3, 2014 2:50:44 PM\nSubject: Re: [Openstack-operators] Problem creating resizable CentOS 6.5	image\n\nI use this snippet in my %post section. I don\'t find it particularly\nelegant, but it works just fine:\n\n    # Set up to grow root in initramfs\n    cat << EOF > 05-grow-root.sh\n    #!/bin/sh\n\n    /bin/echo\n    /bin/echo Resizing root filesystem\n\n    /bin/echo \"d\n    n\n    p\n    1\n\n\n    w\n    \" | /sbin/fdisk -c -u /dev/vda\n    /sbin/e2fsck -f /dev/vda1\n    /sbin/resize2fs /dev/vda1\n    EOF\n\n    chmod +x 05-grow-root.sh\n\n    dracut --force --include 05-grow-root.sh /mount --install \'echo\nfdisk e2fsck resize2fs\' /boot/\"initramfs-grow_root-$(ls /boot/|grep\ninitramfs|sed s/initramfs-//g)\" $(ls /boot/|grep vmlinuz|sed\ns/vmlinuz-//g)\n    rm -f 05-grow-root.sh\n\n    tail -4 /boot/grub/grub.conf | sed\ns/initramfs/initramfs-grow_root/g| sed s/CentOS/ResizePartition/g |\nsed s/crashkernel=auto/crashkernel=0 at 0/g >> /boot/grub/grub.conf\n\nIt only works if the root filesystem is `/dev/vd1` (which is a very\ncommon setup anyway) but can be adapted.\n\nI only tested it with CentOS 5 and 6. The full script is available at\nhttps://github.com/gc3-uzh-ch/openstack-tools/\n\n.a.\n\n\n-- \nantonio.s.messina at gmail.com\nantonio.messina at uzh.ch                     +41 (0)44 635 42 22\nS3IT: Service and Support for Science IT   http://www.s3it.uzh.ch/\nUniversity of Zurich\nWinterthurerstrasse 190\nCH-8057 Zurich Switzerland\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<CA+jNneB9==8Bnbwm052ae=Pz-QSaRCqh8PX5=o95r4+knZju1A@mail.gmail.com>',NULL),('<1355785562.509115775@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2012-12-17 17:06:02',-21600,'2012-12-17 23:06:02',NULL,'[openstack-community] Requesting volunteers to staff the OpenStack\n	booth at the Open Compute Project Summit','\n\nHi everyone, I am the relatively new OpenStack Foundation industry events planner.  I\'ll post this kind of request for community support for events from time to time.\n \nThe Open Compute Project has provided OpenStack with a very nice 10\' x 10\' booth at the OCP Summit January 16-17 2013, at the Santa Clara Convention Center in California.  The Foundation staff cannot attend, unfortunately. We\'re looking for volunteers to staff the booth.  The Expo Hall is open both days from 8am - 6pm with peak times over breaks and lunch.  Volunteers will have full conference access to attend keynotes, sessions, and evening cocktail party in addition to speaking with potential developers and users in the booth. \n \nWe will provide everything needed (except travel expenses) including videos for the large monitor, collateral, OpenStack logo\'d backdrop and more.  Please reply to me directly at [mailto:kathyc at openstack.org] kathyc at openstack.org, by end of day Wednesday, December 19 if interested.  Thank you!-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20121217/3821f3d1/attachment.html>\n\n',NULL,NULL),('<1355786957.8134.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-17 23:29:17',0,'2012-12-17 23:29:17',NULL,'[openstack-dev] oslo library version summary','On Sun, 2012-12-16 at 00:02 -0800, Monty Taylor wrote:\n> Hey all,\n> \n> ttx, markmc and I synced up on the versioning of oslo libraries, and\n> have settled on a system which is a superset of what we do with client\n> libraries - which means we can just implement an additional feature in\n> the current code and it\'ll handle both sets of things. We\'ll sync up\n> later on to discuss applicability of this to the server projects as well.\n> \n> Essentially, it breaks down like this:\n> \n> A tag to the repo will trigger tarball generation.\n> \n> If the tag contains alpha\\d*, beta\\d* or rc\\d*, the tarball will only be\n> uploaded to tarballs.openstack.org. This will allow those pre-releases\n> to be used in the other projects.\n> \n> Otherwise, the tarball will be uploaded to tarballs.o.o AND PyPI. This\n> should allow us to use released versions of oslo libraries in pip-requires.\n> \n> Turns out it\'s easy to implement:\n> \n> https://review.openstack.org/#/c/18171/\n> \n> As soon as that lands, we should be able to handle the oslo requirements.\n\nThanks for that.\n\nI\'ve pushed another test repo here:\n\n  https://github.com/markmc/oslo-config\n\nIt now includes all the history of cfg changes as James suggested.\n\nMore importantly, I\'ve included the setuptools magic from oslo-incubator\nso that it will be versioned correctly when we push a tag. I\'ve added\nthat code under the magic/ directory so that it won\'t actually get\ninstalled with oslo.config. Could you check that what I\'ve done is\nreasonable? It seems to work ...\n\nCheers,\nMark.\n\n\n\n','<50CD8008.2070109@inaugust.com>',NULL),('<1355831428.8134.65.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-18 11:50:28',0,'2012-12-18 11:50:28',NULL,'[openstack-dev] [Openstack] Blueprint proposal: Drop\n setuptools_git for including data/config files','On Mon, 2012-12-17 at 23:47 +0800, Thomas Goirand wrote:\n> On 12/04/2012 09:06 PM, Thierry Carrez wrote:\n> > A bit of history here:\n> > \n> > We used to rely on MANIFEST.in to list all files, but people routinely\n> > forgot to add new files to it. Apparently \"every Python developer\"\n> > doesn\'t know (or care) about this. The end result was that we\n> > discovered very late (sometimes after the release itself) that we\n> > built incomplete tarballs. As a quick search[1] shows, I have\n> > personally filed 27 bugs so far on the subject, so it\'s not a corner case.\n> > \n> > [1] http://bit.ly/TDim7U\n> > \n> > Relying on setuptools_git instead allows to avoid that issue\n> > altogether. The projects that adopted it became a non-issue. The\n> > projects that didn\'t adopt it yet are still a problem. I was about to\n> > push setuptools_git support to projects that don\'t use it yet.\n> > \n> > In summary, I would hate it if we went back to the previous situation.\n> > I\'m not personally attached to setuptools_git, but any proposed\n> > replacement solution should keep its simplicity.\n> \n> With my Debian Developer in charge of Openstack, I have to tell that\n> this was a real problem for us, in Debian, as well.\n> \n> On Debian, we don\'t use released tarballs like they do on Ubuntu. We use\n> git-buildpackage, and do our packaging exclusively with Git (no bzr at\n> all here...). All of our packaging work is stored on alioth.debian.org,\n> on the pkg-openstack git repository. We don\'t even store the master\n> branch, it is picked-up doing:\n> \n> ./debian/rules get-vcs-source\n> \n> which on top of that, creates a .orig.tar.xz out of the upstream source\n> code. (yes! Because xz is so much nicer than gzip...)\n> \n> The problem isn\'t to use setuptools_git for building, you\'re fine to do\n> that, the problem is having the Git repositories not holding the correct\n> MANIFEST.in file, and fooling the people doing packaging using Git. This\n> means that absolutely all of our packages have to embed a patch in\n> debian/patches to \"fix\" the \"wrong\" MANIFEST.in.\n> \n> We\'ve spent quite some time on that. Or rather, should I say: it\'s a\n> real time waster.\n> \n> While I do agree that the MANIFEST.in should be generated automatically,\n> I don\'t think it should be stored in a \"wrong\" way on github.\n> \n> The magic solution could be to have some automatic tools to take care of\n> it. Like, for example, jenkins, or maybe a git hook? I\'m not sure, how,\n> but I\'m quite convince it should be workable.\n> \n> Also, we\'ve been having troubles with clean targets accessing the\n> network at build time, because they see a \".git\" folder. That\'s wrong\n> too, when I do \"git-buildpackage\", I do have a .git folder, though I\n> don\'t want to have any network access, even less a \"git fetch origin\" or\n> something like this. This can be mitigated by doing:\n> \n> echo \"cleaner = true\" >>debian/gbp.conf\n> \n> I\'ve done that, but that\'s quite annoying to have to disable the clean\n> before the build (note: it\'s only not cleaning my git repo, but it\'s\n> really calling clean later on at build time in ../build-area).\n\nI have to say - I\'m quite sympathetic about this issue and would like to\nsee it solved, but I haven\'t yet seen a clear explanation of the build\nprocess you\'re using and where setuptools_git is causing an issue. There\nare a lot of gaps in my understanding of the problem that I\'m having to\nuse guesswork to fill in.\n\nLet\'s see if I can explain my current understanding and where the gaps\nare.\n\n  1) You don\'t build packages from the tarballs produced by upstream. I \n     don\'t understand why you don\'t use tarballs, but I\'m willing to \n     assume it\'s not something you can (or want to) change.\n\n  2) Instead you use git-buildpackage which I know nothing about.\n\n  3) You work from git repositories forked from upstream e.g.\n\n       http://anonscm.debian.org/gitweb/?p=openstack/python-novaclient.git;a=shortlog;h=refs/heads/debian/experimental\n\n     which AFAICT just add a debian/ directory to the source tree\n\n  4) \'get-vcs-source\' somehow generates a tarball from this tree. I\'m \n     guessing it does \'git archive\' rather than \'python setup.py sdist\' \n     but I\'m not sure. Some more digging turns up:\n\n       http://anonscm.debian.org/gitweb/?p=openstack/openstack-pkg-tools.git;a=blob_plain;f=pkgos.make;hb=HEAD\n\n     and it seems that yes, you\'re using \'git archive\'\n\n  5) I\'m guessing there are two issues with these \'git archive\' \n     generated tarballs - (a) there\'s no versioninfo file so setuptools \n     doesn\'t know have a version number and (b) there\'s no .git \n     directory so setuptools doesn\'t have an accurate way of building a \n     manifest\n\n     I\'m not completely clear what setuptools commands are failing \n     because of issue (b)\n\n  6) However, you seem to be saying that issue (b) isn\'t an issue but \n     rather inaccurate MANIFEST.in files are the problem. How exactly \n     are they causing a problem. If we delete those files from upstream \n     git, does that work for you?\n\n  7) You\'re also describing some issue where \'clean targets\' (I don\'t \n      know what they are? Similar to \'make clean\'?) are causing \n      commands like \'git fetch origin\' to be run? What exactly is going \n      on here? Is this because the versioninfo file gets deleted by the \n      cleanup and our setup.py logic attempts to recreate it? If we had \n      a way of disabling network access during the build (e.g. \n      OS_SETUP_NONET=1) would that solve the problem?\n\nHonestly, I\'ve just spent a good amount of time trying to figure out\nyour problems and I think I\'m even more confused.\n\nIf you want upstream to change its build process to reduce your\npackaging pain, then you really need to take the time to very clearly\nexplain what you need in a way that doesn\'t require upstream folks to\nknow anything about your packaging process.\n\nFor example, you could say ....\n\n  I effectively need to be able to do:\n\n    $> git clone git://.../python-novaclient.git\n    $> cd python-novaclient\n    $> git archive .... > ../python-novaclient-2.10.0.tar.gz\n    $> tar -xvzf python-nova-client-2.10.0\n    $> cd python-nova-client-2.10.0\n    $> python setup.py install\n\n  But I right now that fails because of foo, bar and blaa.\n\n  Instead I\'m doing:\n\n    ....\n\n  But that sucks because ....\n\nCheers,\nMark.\n\n\n\n','<50CF3E75.8010700@goirand.fr>',NULL),('<1355849652.8134.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-18 16:54:12',0,'2012-12-18 16:54:12',NULL,'[openstack-dev] [Openstack] Blueprint proposal: Drop\n setuptools_git for including data/config files','On Wed, 2012-12-19 at 00:22 +0800, Thomas Goirand wrote:\n> On 12/18/2012 07:50 PM, Mark McLoughlin wrote:\n\n> >   5) I\'m guessing there are two issues with these \'git archive\'\n> >      generated tarballs - (a) there\'s no versioninfo file so\n> >      setuptools doesn\'t know have a version number and (b) there\'s\n> >      no .git directory so setuptools doesn\'t have an accurate way of\n> >      building a manifest\n> >\n> >      I\'m not completely clear what setuptools commands are failing\n> >      because of issue (b)\n> \n> All the above is exactly right!\n> \n> One of the reasons we are happy to use git archive is that this produces\n> a Debian orig.tar.xz (notice the xz, and not just gz) from *any* commit,\n> if we want to. Let me explain how it works.\n> \n> Let\'s say I want to make a snapshot release of Ceilometer for the commit\n> hash 23ff2f9bbfc14e435c4c04ddddfba473cf2a829b (this is an actual real\n> life example, in fact...). Then, to do that, I just do:\n> \n> git checkout master\n> git log # find out what\'s the name of the tag...\n> git tag 2013.1_g0.4+23ff2f9bbf 23ff2f9bbfc14e435c4c04ddddfba473cf2a829b\n> git checkout debian/experimental\n> git merge -X theirs 23ff2f9bbfc14e435c4c04ddddfba473cf2a829b\n> \n> Then I edit my debian/changelog so it matches the tag:\n> \n> <example debian/changelog>\n> ceilometer (2013.1~g0.4+23ff2f9bbf-1) experimental; urgency=low\n> \n>   * Initial release (Closes: #693406).\n> \n>  -- Thomas Goirand <zigo at debian.org>  Wed, 14 Nov 2012 14:41:52 +0000\n> <end of example debian/changelog>\n> \n> (the important bit is of course the version number above)\n> \n> Then I generate the orig.tar.xz:\n> \n> ./debian/rules get-vcs-source\n> cp ../ceilometer_2013.1~g0.4+23ff2f9bbf.orig.tar.xz ../build-area\n> \n> Then I just build:\n> git-buildpackage\n> \n> Another reason why git is convenient, is that we can cherry pick -x\n> stuff from upstream, do branching, etc. Well, do I really have to\n> convince people of this list that git is convenient? :) Probably not.\n\nThe main thing I don\'t understand is why generate the tarball with \'git\narchive\' and not \'python setup.py sdist\' ?\n\nWith a setuptools generated tarball, we\'d at least have the versioninfo\nfile generated and also the potential to generate a correct manifest\nfrom git.\n\n> >   6) However, you seem to be saying that issue (b) isn\'t an issue but\n> >      rather inaccurate MANIFEST.in files are the problem. How exactly\n> >      are they causing a problem. If we delete those files from\n> >      upstream git, does that work for you?\n> \n> Well, it be better if the MANIFEST.in could be stored correctly in\n> upstream Git repositories, so we wouldn\'t have to deal with them.\n> Currently, we embed a patch in debian/patches to fix them.\n\nHow exactly is an incorrect MANIFEST.in is more trouble for you than no\nMANIFEST.in? Does it break setuptools in some way?\n\n> >   7) You\'re also describing some issue where \'clean targets\' (I don\'t\n> >       know what they are? Similar to \'make clean\'?) are causing\n> >       commands like \'git fetch origin\' to be run? What exactly is\n> >       going on here? Is this because the versioninfo file gets\n> >       deleted by the cleanup and our setup.py logic attempts to\n> >       recreate it? If we had a way of disabling network access during\n> >       the build (e.g. OS_SETUP_NONET=1) would that solve the problem?\n> \n> Let me give an example from Ceilometer. Without \"cleaner = true\",\n> git-buildpackage attemps to run \"./debian/rules clean\", which calls\n> setup.py clean -a. The shell output is then:\n> \n> zigo at GPLHost:dom0.node4407>_\n> ~/openstack-auto-builder/sources/ceilometer/ceilometer$ git-buildpackage\n> dh clean  --with python2\n>    dh_testdir\n>    debian/rules override_dh_auto_clean\n> make[1]: Entering directory\n> `/home/zigo/openstack-auto-builder/sources/ceilometer/ceilometer\'\n> dh_auto_clean\n> Could not create directory \'/root/.ssh\'.\n> The authenticity of host \'git.debian.org (217.196.43.140)\' can\'t be\n> established.\n> RSA key fingerprint is 8c:c0:b8:9f:0a:79:ee:1c:77:c4:b8:a1:70:55:b7:31.\n> Are you sure you want to continue connecting (yes/no)?\n\nWhat setuptools command is being called here? \'setup.py clean\' ?\n\nIs this setuptools command being called from within the tarball or the\ngit checkout?\n\nIf a versioninfo file exists, do you still see this issue?\n\nWould \'git clean -f -x -d\' do what you want without hitting setuptools?\n\n> because in ceilometer/openstack/common/setup.py, there\'s a \"git fetch\n> origin\". Openstack common (or Oslo...) makes the wrong assumption that\n> \"origin\" is the repository on github, which isn\'t true in my case (for\n> us, origin is alioth.debian.org). Worse: it\'s trying to do this as root,\n> because of the use of the debian tool \"fakeroot\" to build.\n\nI agree that you should be able to avoid hitting the network during\nbuilds.\n\n...\n\n> I have discussed this problem already, and Julien Danjou made an attempt\n> at fixing it (but I\'m not sure if his patch has been approved already or\n> not in gerrit).\n> \n> Of course, I can add \"cleaner = true\" so that no \"setup.py clean -a\" is\n> called before the build, but I think this is both suboptimal and\n> potentially dangerous.\n\nOk, so it is \'setup.py clean\' you\'re doing. My other questions above\nstill stand.\n\n> > Honestly, I\'ve just spent a good amount of time trying to figure out\n> > your problems\n> \n> Thanks a lot!\n> \n> > If you want upstream to change its build process to reduce your\n> > packaging pain, then you really need to take the time to very clearly\n> > explain what you need in a way that doesn\'t require upstream folks to\n> > know anything about your packaging process.\n> \n> I\'m trying ... :)\n> I hope that with this mail, it\'s going to be more clear. Let me know if\n> it\'s not.\n> \n> What would be great, for us in Debian, would be if every (PGP signed,\n> please... ;) ) tag upstream would also include the generation of a\n> correct MANIFEST.in and versioninfo files.\n\nI think it\'s pretty clear - upstream is determined to come up with a\nsolution that avoids MANIFEST.in and versioninfo being checked into git.\nYou need to focus on helping us figure out how to achieve that while\nenabling your desired build process.\n\nCheers,\nMark.\n\n\n\n','<50D0985B.5040407@goirand.fr>',NULL),('<1355865259.8134.102.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-18 21:14:19',0,'2012-12-18 21:14:19',NULL,'[openstack-dev] Motion to clarify Python Support policy','On Tue, 2012-12-18 at 12:52 -0800, Monty Taylor wrote:\n> OpenStack will target its development efforts to latest Ubuntu/Fedora,\n> but will endeavor to not introduce any changes that would make it\n> impossibly or unnaturally difficult to run on the latest Ubuntu LTS or\n> latest RHEL. \n\nVery nicely put.\n\nCheers,\nMark.\n\n\n\n','<50D0D784.2080205@inaugust.com>',NULL),('<1356005191.5452.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-20 12:06:31',0,'2012-12-20 12:06:31',NULL,'[openstack-dev] [Quantum] Quantum Scheduler','On Tue, 2012-12-18 at 18:25 +0400, Eugene Nikanorov wrote:\n> Hi Yong Sheng,\n> \n> I see you\'ve started working on\n> https://blueprints.launchpad.net/quantum/+spec/quantum-scheduler\n\nCould you check to see if it makes sense to build on the efforts to move\nthe Nova/Cinder scheduler into Oslo?\n\n  https://blueprints.launchpad.net/oslo/+spec/common-filters\n\nI haven\'t looked enough to know whether it is relevant but, if you find\nyourself copying Nova scheduler code, please help to get that code into\nOslo :-)\n\nCheers,\nMark.\n\n\n\n','<CAJfiwOS0EvhEG4dTqmUBSaBowaCTwmEUjJCtcwFzBv+oKEMj0Q@mail.gmail.com>',NULL),('<1356854431.125.1356221107454.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-23 00:05:07',0,'2012-12-23 00:05:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-folsom #83','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/83/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise1 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/>\nCheckout:periodic-swift-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/> - hudson.remoting.Channel at 2b8e1cc5:precise1\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson4059453655895990545.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/83/\', \'BUILD_TAG\': \'jenkins-periodic-swift-docs-stable-folsom-83\', \'SSH_CLIENT\': \'198.101.231.203 38365 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1355682909.773134-2063765931\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'JOB_NAME\': \'periodic-swift-docs-stable-folsom\', \'NODE_LABELS\': \'precise precise1\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2012-12-23_00-04-26\', \'BUILD_NUMBER\': \'83\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'274a1f91-b342-436e-93e9-47e4ca02aee3\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'78d79c104eef52324f0675937ae52201\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise1\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'78d79c104eef52324f0675937ae52201\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 38365 108.166.59.148 22\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Downloading master\n  Cannot unpack file /tmp/pip-0LwGVS-unpack/master (downloaded from <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient,> content-type: text/html; charset=utf-8); cannot detect archive format\nCannot determine archive format of <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-folsom/83\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1356E446-5639-487A-97F4-02788E8C94ED@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 10:39:29',-28800,'2013-12-06 18:39:29',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','\nOn Dec 6, 2013, at 10:07 AM, Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote:\n\n> Hi,\n> \n> I am really inspired by this thread. Frankly saying, Glance for Murano was a kind of sacred entity, as it is a service with a long history in OpenStack.  We even did not think in the direction of changing Glance. Spending a night with these ideas, I am kind of having a dream about unified catalog where the full range of different entities are presented. Just imagine that we have everything as  first class citizens of catalog treated equally: single VM (image), Heat template (fixed number of VMs\\ autoscaling groups), Murano Application (generated Heat templates), Solum assemblies\n> \n> Projects like Solum will highly benefit from this catalog as it can use all varieties of VM configurations talking with one service.\n> This catalog will be able not just list all possible deployable entities but can be also a registry for already deployed configurations. This is perfectly aligned with the goal for catalog to be a kind of market place which provides billing information too.\n> \n> OpenStack users also will benefit from this as they will have the unified approach for manage deployments and deployable entities.\n> \n> I doubt that it could be done by a single team. But if all teams join this effort we can do this. From my perspective, this could be a part of Glance program and it is not necessary to add a new program for that. As it was mentioned earlier in this thread an idea of market place for images in Glance was here for some time. I think we can extend it to the idea of creating a marketplace for a deployable entity regardless of the way of deployment. As Glance is a core project which means it always exist in OpenStack deployment it makes sense to as a central catalog for everything.\n\n+1 \n\nVish\n\n> \n> Thanks\n> Georgy\n> \n> \n> On Fri, Dec 6, 2013 at 8:57 AM, Mark Washenberger <mark.washenberger at markwash.net> wrote:\n> \n> \n> \n> On Thu, Dec 5, 2013 at 9:32 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> On 12/05/2013 04:25 PM, Clint Byrum wrote:\n> Excerpts from Andrew Plunk\'s message of 2013-12-05 12:42:49 -0800:\n> Excerpts from Randall Burt\'s message of 2013-12-05 09:05:44 -0800:\n> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com>\n>   wrote:\n> \n> Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> Why not just use glance?\n> \n> \n> I\'ve asked that question a few times, and I think I can collate the\n> responses I\'ve received below. I think enhancing glance to do these\n> things is on the table:\n> \n> 1. Glance is for big blobs of data not tiny templates.\n> 2. Versioning of a single resource is desired.\n> 3. Tagging/classifying/listing/sorting\n> 4. Glance is designed to expose the uploaded blobs to nova, not users\n> \n> My responses:\n> \n> 1: Irrelevant. Smaller things will fit in it just fine.\n> \n> Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance.\n> \n> \n> Optimizations can be improved for various use cases. The design, however,\n> has no assumptions that I know about that would invalidate storing blobs\n> of yaml/json vs. blobs of kernel/qcow2/raw image.\n> \n> I think we are getting out into the weeds a little bit here. It is important to think about these apis in terms of what they actually do, before the decision of combining them or not can be made.\n> \n> I think of HeatR as a template storage service, it provides extra data and operations on templates. HeatR should not care about how those templates are stored.\n> Glance is an image storage service, it provides extra data and operations on images (not blobs), and it happens to use swift as a backend.\n> \n> If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field \"minRam\" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it\'s own service, or becomes part of Heat.\n> \n> \n> I spoke at length via G+ with Randall and Tim about this earlier today.\n> I think I understand the impetus for all of this a little better now.\n> \n> Basically what I\'m suggesting is that Glance is only narrow in scope\n> because that was the only object that OpenStack needed a catalog for\n> before now.\n> \n> However, the overlap between a catalog of images and a catalog of\n> templates is quite comprehensive. The individual fields that matter to\n> images are different than the ones that matter to templates, but that\n> is a really minor detail isn\'t it?\n> \n> I would suggest that Glance be slightly expanded in scope to be an\n> object catalog. Each object type can have its own set of fields that\n> matter to it.\n> \n> This doesn\'t have to be a minor change to glance to still have many\n> advantages over writing something from scratch and asking people to\n> deploy another service that is 99% the same as Glance.\n> \n> My suggestion for long-term architecture would be to use Murano for catalog/metadata information (for images/templates/whatever) and move the block-streaming drivers into Cinder, and get rid of the Glance project entirely. Murano would then become the catalog/registry of objects in the OpenStack world, Cinder would be the thing that manages and streams blocks of data or block devices, and Glance could go away. Imagine it... OpenStack actually *reducing* the number of projects instead of expanding! :)\n> \n> I think it is good to mention the idea of shrinking the overall OpenStack code base. The fact that the best code offers a lot of features without a hugely expanded codebase often seems forgotten--perhaps because it is somewhat incompatible with our low-barrier-to-entry model of development.\n> \n> However, as a mild defense of Glance\'s place in the OpenStack ecosystem, I\'m not sure yet that a general catalog/metadata service would be a proper replacement. There are two key distinctions between Glance and a catalog/metadata service. One is that Glance *owns* the reference to the underlying data--meaning Glance can control the consistency of its references. I.e. you should not be able to delete the image data out from underneath Glance while the Image entry exists, in order to avoid a terrible user experience. Two is that Glance understands and coordinates the meaning and relationships of Image metadata. Without these distinctions, I\'m not sure we need any OpenStack project at all--we should probably just publish an LDAP schema for Images/Templates/what-have-you and use OpenLDAP.\n> \n> To clarify, I think these functions are critical to Glance\'s role as a gatekeeper and helper, especially in public clouds--but having this role in your deployment is probably something that should ultimately become optional. Perhaps Glance should not be in the required path for all deployments.\n>  \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Georgy Okrokvertskhov\n> Technical Program Manager,\n> Cloud and Infrastructure Services,\n> Mirantis\n> http://www.mirantis.com\n> Tel. +1 650 963 9828\n> Mob. +1 650 996 3284\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/c14ed903/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/c14ed903/attachment.pgp>\n\n','<CAG_6_on-4pBmu3-SxC3JzDukbm=GreBgeEMRA4LUqKzM++avig@mail.gmail.com>',NULL),('<1357196233.2553.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 06:57:13',0,'2013-01-03 06:57:13',NULL,'[openstack-dev] Command line verbose and debug flag behavior','On Wed, 2013-01-02 at 21:39 -0500, Davanum Srinivas wrote:\n> Hi Team,\n> \n> We have a bug 989268 [1] with a review 18110 in progress [2] which\n> proposes the following change.\n> \n> Current Behavior - when debug or verbose flag is set then log level is\n> DEBUG. default log level is INFO when neither flag is set\n> New Behavior - when debug flag is set then log level is DEBUG, when\n> verbose flag is set then log level is INFO. default log level is\n> WARNING when neither flag is set\n> \n> Is this acceptable? Please chime in here on the mailing list or on the\n> review itself.\n\nI think the new behaviour makes far more sense, so the only concern is\nbackwards compatibility.\n\nThe implication is that folks with the verbose flag set will no longer\nget debugging and folks with neither flag set will no longer get info\nmessages.\n\nThat\'s definitely something that could catch people out, but perhaps\nit\'s not too big a deal if we add it to the release notes.\n\nCheers,\nMark.\n\n\n\n','<CANw6fcGabFVZ2ydm_0ntiFvsCdt9VO0RMYs8z2mmhjyL1=3=FA@mail.gmail.com>',NULL),('<1357215752.2553.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 12:22:32',0,'2013-01-03 12:22:32',NULL,'[openstack-dev] Implications of switching to entry points for\n scheduler filtering/weighing','Hey,\n\nThere are some patches proposed for oslo-incubator which adds Nova\'s\nfilter and weighing infrastructure so that it can be re-used by Cinder:\n\n  https://blueprints.launchpad.net/oslo/+spec/common-filters\n\nOne part of this is that we would move to loading filters and weighers\nfrom entry points. I want to make sure Nova folks are aware of the\nimplications of this before merging it into Oslo.\n\nMy thinking is we should aim to have zero impact on users who just use\nthe standard filters/weighers but users who add custom code (should)\nhave the expectation that their code will occasionally stop working as\nthings upstream and that both code and configuration will need to be\nupdated.\n\nI\'d appreciate people\'s thoughts on the summary below.\n\nCheers,\nMark.\n\n1) Users who don\'t add custom filters or weighers:\n\n   o If a user has set the scheduler_default_filters config option to\n     enable or disable some filters, this should keep working without\n     the user having to update their config files. The current patch\n     renames ComputeCapabilitiesFilter to CapabilitiesFilter which\n     breaks this rule, but should be able to fix that the former is\n     retained for compatibility.\n\n   o The behaviour of the filters should not change at all. For example,\n     they operate on the same set of filter_properties provided to\n     run_instance() so you should be able to update the scheduler before\n     updating the API server.\n\n   o It is proposed that we remove the scheduler_available_filters \n     config option and use the default \"all_filters\" behaviour. I can\'t\n     imagine that this class of users would have changed this option.\n\n   o It is also proposed that we remove the scheduler_weight_classes \n     config option. It\'s somewhat plausible that users may have used \n     this to disable the RAM weigher, so maybe we need a config option \n     which lists the subset of available weighing functions which should\n     be used.\n\n2) Users who have added their own custom filters or weighers.\n\n   o There were previously two ways of adding new code - drop a file \n     into the right directory Nova\'s codebase or install it elsewhere \n     and update the available_filters or weight_classes options. Neither\n     of these methods will work anymore. Instead, you need to register\n     your filter as an entry point.\n\n   o The code needs to be updated to use the new Oslo filter/weigher \n     base classes.\n\n\n\n',NULL,NULL),('<1357215839.2553.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 12:23:59',0,'2013-01-03 12:23:59',NULL,'[openstack-dev] Implications of switching to entry points for\n scheduler filtering/weighing','On Thu, 2013-01-03 at 12:22 +0000, Mark McLoughlin wrote:\n> Hey,\n> \n> There are some patches proposed for oslo-incubator which adds Nova\'s\n> filter and weighing infrastructure so that it can be re-used by Cinder:\n> \n>   https://blueprints.launchpad.net/oslo/+spec/common-filters\n> \n> One part of this is that we would move to loading filters and weighers\n> from entry points. I want to make sure Nova folks are aware of the\n> implications of this before merging it into Oslo.\n\nBah, I forgot to include the link to the WIP patch for Nova:\n\n  https://review.openstack.org/18718\n\nAnd if anyone is thinking \"didn\'t Monty have a patch to do this?\",\nyou\'re thinking of a patch to switch to using entry points for the\nscheduler driver and host manager:\n\n  https://review.openstack.org/11557\n\nCheers,\nMark.\n\n\n\n','<1357215752.2553.32.camel@sorcha>',NULL),('<1357230515.2553.57.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 16:28:35',0,'2013-01-03 16:28:35',NULL,'[openstack-dev] Implications of switching to entry points for\n scheduler filtering/weighing','On Thu, 2013-01-03 at 10:51 -0400, Sandy Walsh wrote:\n> \n> On 01/03/2013 10:27 AM, Monty Taylor wrote:\n> > On 01/03/2013 04:23 AM, Mark McLoughlin wrote:\n> >> On Thu, 2013-01-03 at 12:22 +0000, Mark McLoughlin wrote:\n> >>> Hey,\n> >>>\n> >>> There are some patches proposed for oslo-incubator which adds Nova\'s\n> >>> filter and weighing infrastructure so that it can be re-used by Cinder:\n> >>>\n> >>>   https://blueprints.launchpad.net/oslo/+spec/common-filters\n> >>>\n> >>> One part of this is that we would move to loading filters and weighers\n> >>> from entry points. I want to make sure Nova folks are aware of the\n> >>> implications of this before merging it into Oslo.\n> >>\n> >> Bah, I forgot to include the link to the WIP patch for Nova:\n> >>\n> >>   https://review.openstack.org/18718\n> >>\n> >> And if anyone is thinking \"didn\'t Monty have a patch to do this?\",\n> >> you\'re thinking of a patch to switch to using entry points for the\n> >> scheduler driver and host manager:\n> >>\n> >>   https://review.openstack.org/11557\n> > \n> > I, for one, welcome our new filters and weighers overlords.\n> \n> Yep, having the shared filters/weighers sounds cool.\n> \n> Is there a security concern about using the entry-point mechanism for\n> allowing untrusted code access to the rich scheduler data (host &\n> request info)?\n> \n> For example, someone installs a sneaky python package on a scheduler\n> node that has an entry-point that the scheduler uses. We wouldn\'t want\n> that to suddenly being included in the filter chain.\n> \n> The old filter driver mechanism, while clunky, was at least explicit. Or\n> am I missing something here?\n\nSure, it\'s very important that unprivileged users can\'t make the\nscheduler (or any other service) load untrusted code.\n\nHowever, in a sanely configured system, only root or the user which the\nscheduler is running as can register an entry point. You basically need\nto be able to install a python egg in the scheduler\'s python path.\n\nCheers,\nMark.\n\n\n\n','<50E59B05.5020901@rackspace.com>',NULL),('<1357232616.9.1370671513224.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-08 06:05:13',0,'2013-06-08 06:05:13',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-docs-stable-grizzly #59','See <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/59/>\n\n\n\n','<886444631.2.1370585086886.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1357233470.2553.75.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 17:17:50',0,'2013-01-03 17:17:50',NULL,'[openstack-dev] [keystone] [Openstack-stable-maint] Build\n failed in Jenkins: periodic-keystone-python27-stable-folsom #84','On Mon, 2012-12-24 at 09:47 -0800, James E. Blair wrote:\n\n> I looked into this, and I believe the problem is that in this file:\n> \n> https://github.com/openstack/keystone/blob/stable/folsom/tests/test_keystoneclient.py\n> \n> It checks out python-keystoneclient git repos from gerrit into the\n> keystone workspace and attempts tests with different branches.  The\n> problem is that different versions of python-keystoneclient will have\n> different dependencies, and since they are not being installed properly\n> with setuptools, those dependencies will not be in the environment.  In\n> this case, \'requests\', which is a current dependency of keystoneclient,\n> is not available.\n> \n> In general, I don\'t think _inside_ the test cases is a good place to be\n> installing software.  This might be more appropriate as a set of jenkins\n> jobs and tox configs that install the needed dependencies before running\n> tests.\n\nWell now, that\'s pretty interesting ... it\'s actually fairly amusing\nthis hasn\'t reared its head before :)\n\nHonestly, the checking out of different versions of keystoneclient,\nreloading the module and testing against the keystone server is a pretty\ninsane thing to do in unit tests ... but I have to applaud the effort at\ngood test coverage. I\'m guessing a big part of the rationale here was to\nmake sure that the pre-keystonelight client worked with newer keystone.\n\nWhy insane? Well, for one thing, as a packager I would expect to be able\nto run the unit tests during my package build process without any\nnetwork access being involved. I\'d also find it pretty odd that the\nkeystone tests are testing keystoneclient, nevermind that they\'re\ntesting different versions of keystoneclient.\n\nI guess there are a bunch of different ways to approach this:\n\n  - As James suggests, keep the tests in keystone but only use the \n    currently installed version of keystoneclient. Add different tox \n    configs for the different versions of keystoneclient we want to \n    test and set up jenkins jobs for each. This would mean the tests \n    would need to be able to detect which version of keystoneclient is \n    installed because not all tests are applicable to each version. It \n    would also be nice if the jobs to test older versions just ran the \n    keystoneclient tests, not all the rest of the unit tests.\n\n  - Think of these as API compatibility tests, record the API requests \n    produced by older versions of keystoneclient, check them into git \n    and have the tests check that these older API requests still work \n    correctly.\n\n  - Think of these as integration tests for keystoneclient, move them \n    out of keystone and have different jenkins jobs for each version of \n    keystoneclient we want to test.\n\nNone of these are quick fixes, but IMHO we need an alternative to the\ncurrent approach.\n\nTo fix the stable/folsom issues, how about we say that the stable/folsom\ntests only need to test the 0.2.0 version of keystoneclient, not master?\n\nThat\'s as simple as this change:\n\n  @@ -789,7 +789,7 @@ class KeystoneClientTests(object):\n \n   class KcMasterTestCase(CompatTestCase, KeystoneClientTests):\n       def get_checkout(self):\n  -        return KEYSTONECLIENT_REPO, \'master\'\n  +        return KEYSTONECLIENT_REPO, \'0.2.0\'\n \n       def test_tenant_add_and_remove_user(self):\n           client = self.get_client(admin=True)\n\nCheers,\nMark.\n\n\n\n','<87ehifl4v6.fsf_-_@meyer.lemoncheese.net>',NULL),('<1357233985.78235748@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-01-03 11:26:25',-21600,'2013-01-03 17:26:25',NULL,'[OpenStack Foundation] Thinking about the mission of the user\n	committeee','One idea I discussed with Thierry was to kick off each \"topic\" within the Design Summit every day with a roundtable to share user pain points or other areas that users might see as priorities going forward.  \n\nIMHO this would be a positive step, and is something we could implement in April.\n\n\n\nOn Friday, December 28, 2012 11:11am, \"Narayan Desai\" <narayan.desai at gmail.com> said:\n\n> I originally sent this mail to Tim Bell, on the subject of a document\n> that he (and the other members of the user committee) are preparing.\n> \n> Tim suggested widening the discussion to this mailing list, so I\'ve\n> forwarded the message here. I\'m particularly interested in others\'\n> opinions about the mission of the user committee, and aspects of the\n> openstack community culture that this mission reflects.\n>  -nld\n> \n> =====================\n> \n> Hi Tim.\n> \n> Thanks for the update on the user committee.\n> \n> When Lauren (Sell) originally mentioned the user committee to me, I\n> was most excited about the addition of user advocacy into the\n> openstack community. From early on in the project (at least back to\n> Bexar when I started paying attention), openstack has primarily been a\n> developer-focused community. While this culture has been excellent for\n> encouraging contribution of code,  I think that this is a tendency\n> that needs to be moderated in order for openstack to grow to its full\n> potential.\n> \n> I have a few comments; these aren\'t so much comments about the\n> document that you\'re circulating; rather, they speak specifically to\n> the mission of the user committee, which is only discussed briefly at\n> the end.\n> \n> This mission of the user committee should (IMO) flow from a few basic questions:\n>  - How do users engage in the community?\n>  - How do we incentivize these participants to help fill the current\n> gaps that exist in the community?\n>  - How do we best integrate the perspectives of users into the design\n> process of openstack code?\n>  - How can the user committee facilitate a more productive engagement\n> between these two parts of the openstack community?\n> \n> To the first point, there is often a tone of \"patches welcome\" in the\n> community, that is somewhat unwelcoming to users that can\'t or won\'t\n> develop code. This suggests that engagement solely on the development\n> terms is probably not a sustainable solution for the heterogenous\n> community that is developing around openstack. I think that it is\n> important to give these folks (ones that build systems, not so much\n> software) a role that they can identify with as a contributor to the\n> project.\n> \n> I think that there are a large range of gaps between the coding and\n> deployments today. Openstack supports a wide enough range of functions\n> (and IMO it is necessary, not incidental complexity) that it is\n> difficult to boil down to simple configurations. I think this poses a\n> serious difficulty for both documentation and testing. These issues\n> have been discussed at length, but make me wonder if a different\n> structure would address these gaps as well as the social split as\n> well.\n> \n> As I\'ve written this, I\'m realizing that the one thing that doesn\'t\n> sit well with me about the current structure you\'re proposing for the\n> user committee seems to institutionalize the current split between\n> developers and users, where I think that the committee should be\n> trying to figure out ways to blur the divisions between the groups.\n> \n> I\'d suggest adding in an explicit mission for the group at the top of\n> the document, in addition to the mandate. I think that might set the\n> tone for the rest of the document in a productive way. Considering my\n> lack of standing on the committee, I think that it might be\n> presumptive for me to suggest its mission, but I think that the four\n> questions above capture many of the things that I think are important.\n> \n> I\'m happy to help in any way you\'d like. let me know if you\'d like\n> additional comments, or participation in the documents in some\n> fashion.\n> \n> Happy holidays.\n>  -nld\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<CABweQmJhz7AzZWDkUqgPG4j97qmxpddbfOj-wBipzp9gO7F91Q@mail.gmail.com>',NULL),('<1357234480.2553.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-03 17:34:40',0,'2013-01-03 17:34:40',NULL,'[openstack-dev] [keystone] [Openstack-stable-maint] Build\n failed in Jenkins: periodic-keystone-python27-stable-folsom #84','On Thu, 2013-01-03 at 17:17 +0000, Mark McLoughlin wrote:\n> On Mon, 2012-12-24 at 09:47 -0800, James E. Blair wrote:\n> \n> > I looked into this, and I believe the problem is that in this file:\n> > \n> > https://github.com/openstack/keystone/blob/stable/folsom/tests/test_keystoneclient.py\n> > \n> > It checks out python-keystoneclient git repos from gerrit into the\n> > keystone workspace and attempts tests with different branches.  The\n> > problem is that different versions of python-keystoneclient will have\n> > different dependencies, and since they are not being installed properly\n> > with setuptools, those dependencies will not be in the environment.  In\n> > this case, \'requests\', which is a current dependency of keystoneclient,\n> > is not available.\n> > \n> > In general, I don\'t think _inside_ the test cases is a good place to be\n> > installing software.  This might be more appropriate as a set of jenkins\n> > jobs and tox configs that install the needed dependencies before running\n> > tests.\n> \n...\n> To fix the stable/folsom issues, how about we say that the stable/folsom\n> tests only need to test the 0.2.0 version of keystoneclient, not master?\n> \n> That\'s as simple as this change:\n> \n>   @@ -789,7 +789,7 @@ class KeystoneClientTests(object):\n>  \n>    class KcMasterTestCase(CompatTestCase, KeystoneClientTests):\n>        def get_checkout(self):\n>   -        return KEYSTONECLIENT_REPO, \'master\'\n>   +        return KEYSTONECLIENT_REPO, \'0.2.0\'\n>  \n>        def test_tenant_add_and_remove_user(self):\n>            client = self.get_client(admin=True)\n\nProposed here: https://review.openstack.org/18898\n\nCheers,\nMark.\n\n\n\n','<1357233470.2553.75.camel@sorcha>',NULL),('<1357235679.2553.79.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-03 17:54:39',0,'2013-01-03 17:54:39',NULL,'[Openstack-stable-maint] Swift bitrot jobs [was Re: Build failed in\n Jenkins: periodic-swift-python26-stable-folsom #86]','Hey James\n\nCould you take openstack-stable-maint off the notification list for\nswift bitrot jobs?\n\nThe stable-maint team doesn\'t have any involvement with swift (yet?) ...\nI didn\'t even know it had a stable/folsom branch\n\nCheers,\nMark.\n\nOn Wed, 2012-12-26 at 00:13 +0000, OpenStack Jenkins wrote:\n> See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/86/>\n...\n> ======================================================================\n> FAIL: test_hash_suffix_multi_file_two (test.unit.obj.test_replicator.TestObjectReplicator)\n> ----------------------------------------------------------------------\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/test/unit/obj/test_replicator.py\",> line 328, in test_hash_suffix_multi_file_two\n>     self.assertEquals(len(os.listdir(whole_hsh_path)), 2)\n> AssertionError: 1 != 2\n> >>  raise self.failureException, \\\n>           (None or \'%r != %r\' % (1, 2))\n>   \n\n\n\n','<1707825463.199.1356480794110.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1357235996.2553.80.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-03 17:59:56',0,'2013-01-03 17:59:56',NULL,'[Openstack-stable-maint] Horizon docs stable/folsom bitrot job\n failures [was Re: Build failed in Jenkins:\n periodic-horizon-docs-stable-folsom #94]','Hi Gabriel,\n\nDo you have any idea why this stable/folsom bitrot job has been failing\nsince December 17?\n\nThanks,\nMark.\n\nOn Thu, 2013-01-03 at 00:04 +0000, OpenStack Jenkins wrote:\n> See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/94/>\n> \n> ------------------------------------------\n> [...truncated 2287 lines...]\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n>     app_list = resolver.app_dict[ns]\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n>     self._populate()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n>     for pattern in reversed(self.url_patterns):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n>     patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n>     self._urlconf_module = import_module(self.urlconf_name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n>     __import__(name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n>     url(r\'\', include(horizon.urls)))\n> AttributeError: \'module\' object has no attribute \'urls\'\n> reading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n>     from horizon.dashboards.syspanel import dashboard\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n>     class SystemPanels(horizon.PanelGroup):\n> AttributeError: \'module\' object has no attribute \'PanelGroup\'\n> reading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n>     INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n>     app_list = resolver.app_dict[ns]\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n>     self._populate()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n>     for pattern in reversed(self.url_patterns):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n>     patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n>     self._urlconf_module = import_module(self.urlconf_name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n>     __import__(name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n>     url(r\'\', include(horizon.urls)))\n> AttributeError: \'module\' object has no attribute \'urls\'\n> reading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n>     from horizon.dashboards.syspanel import dashboard\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n>     class SystemPanels(horizon.PanelGroup):\n> AttributeError: \'module\' object has no attribute \'PanelGroup\'\n> reading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n>     from horizon.dashboards.syspanel import dashboard\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n>     class SystemPanels(horizon.PanelGroup):\n> AttributeError: \'module\' object has no attribute \'PanelGroup\'\n> reading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n>     INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n>     app_list = resolver.app_dict[ns]\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n>     self._populate()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n>     for pattern in reversed(self.url_patterns):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n>     patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n>     self._urlconf_module = import_module(self.urlconf_name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n>     __import__(name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n>     url(r\'\', include(horizon.urls)))\n> AttributeError: \'module\' object has no attribute \'urls\'\n> reading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n>     from horizon.dashboards.syspanel import dashboard\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n>     class SystemPanels(horizon.PanelGroup):\n> AttributeError: \'module\' object has no attribute \'PanelGroup\'\n> reading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n>     USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n>     app_list = resolver.app_dict[ns]\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n>     self._populate()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n>     for pattern in reversed(self.url_patterns):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n>     patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n>     self._urlconf_module = import_module(self.urlconf_name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n>     __import__(name)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n>     url(r\'\', include(horizon.urls)))\n> AttributeError: \'module\' object has no attribute \'urls\'\n> reading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n>     from horizon.dashboards.syspanel import dashboard\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n>     class SystemPanels(horizon.PanelGroup):\n> AttributeError: \'module\' object has no attribute \'PanelGroup\'\n> reading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\n> Traceback (most recent call last):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n>     __import__(self.modname)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n>     url(r\'\', include(horizon.urls)))\n> AttributeError: \'module\' object has no attribute \'urls\'\n> \n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n> <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n> looking for now-outdated files... none found\n> pickling environment... done\n> checking consistency... done\n> writing... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.excepti!\n on!\n>  s sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecod!\n e/!\n>  horizon/horizon.conf.dash_template sourcecode/horizon/horizon.!\n>  conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboard!\n s.!\n>  syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboa!\n rd!\n>  s.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavo!\n>  rs.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls so!\n ur!\n>  cecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspane!\n l.!\n>  instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instance!\n>  s.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon!\n /h!\n>  orizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/h!\n or!\n>  izon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboard!\n>  s.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots !\n so!\n>  urcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.das!\n hb!\n>  oards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizo!\n>  n.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.port!\n s !\n>  sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/hor!\n iz!\n>  on.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboar!\n>  ds.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.da!\n sh!\n>  boards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/hori!\n zo!\n>  n/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcec!\n>  ode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.!\n ap!\n>  i.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode!\n /h!\n>  orizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filter!\n>  s sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n>   File \"setup.py\", line 105, in <module>\n>     \'Topic :: Internet :: WWW/HTTP\']\n>   File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n>     dist.run_commands()\n>   File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n>     self.run_command(cmd)\n>   File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n>     cmd_obj.run()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n>     BuildDoc.run(self)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n>     app.build(force_all=self.all_files)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n>     self.builder.build_all()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n>     self.build(None, summary=\'all source files\', method=\'all\')\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n>     self.write(docnames, list(updated_docnames), method)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n>     docwriter.write(largetree, destination)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n>     self.translate()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n>     self.document.walkabout(visitor)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n>     if child.walkabout(visitor):\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n>     visitor.dispatch_departure(self)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n>     return method(node)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n>     self.depart_admonition(node)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n>     self.depart_block_quote(node)\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n>     self.dedent()\n>   File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n>     self._indent.pop()\n> IndexError: pop from empty list\n> ERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n> ___________________________________ summary ____________________________________\n> ERROR:   venv: commands failed\n> Build step \'Execute shell\' marked build as failure\n> [SCP] Connecting to static.openstack.org\n> [SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/94\n> [SCP] Copying console log.\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n\n\n','<1420571982.334.1357171495154.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1357296789.2368.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-04 10:53:09',0,'2013-01-04 10:53:09',NULL,'[openstack-dev] [keystone] [Openstack-stable-maint] Build\n failed in Jenkins: periodic-keystone-python27-stable-folsom #84','On Fri, 2013-01-04 at 11:12 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> >> To fix the stable/folsom issues, how about we say that the stable/folsom\n> >> tests only need to test the 0.2.0 version of keystoneclient, not master?\n> >>\n> >> That\'s as simple as this change:\n> >>\n> >>   @@ -789,7 +789,7 @@ class KeystoneClientTests(object):\n> >>  \n> >>    class KcMasterTestCase(CompatTestCase, KeystoneClientTests):\n> >>        def get_checkout(self):\n> >>   -        return KEYSTONECLIENT_REPO, \'master\'\n> >>   +        return KEYSTONECLIENT_REPO, \'0.2.0\'\n> >>  \n> >>        def test_tenant_add_and_remove_user(self):\n> >>            client = self.get_client(admin=True)\n> > \n> > Proposed here: https://review.openstack.org/18898\n> \n> Mixed feelings: we are supposed to always use the latest client --\n> that\'s why there is no stable/folsom branch of the client.\n\nRight, but there\'s something very wrong with using keystone\nstable/folsom unit tests to catch regressions in keystoneclient master.\n\nTesting keystone stable/folsom with keystoneclient 0.2.0 is fine because\nit will catch regressions in keystone itself.\n\nFor catching regressions in keystoneclient master, the keystoneclient\ntesting which happens on keystone master is sufficient.\n\n> The real issue here is the test itself. I\'m fine with this as a\n> temporary workaround to unblock keystone stable/folsom, as long as it\'s\n> clear that this test needs to be rewritten (or moved to tempest).\n\nYes, it\'s a stopgap measure.\n\nCheers,\nMark.\n\n\n\n','<50E6AB22.703@openstack.org>',NULL),('<1357304690.9046926.1416937758405.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 12:49:18',-18000,'2014-11-25 17:49:18',NULL,'[openstack-dev] Where should Schema files live?','\n\n> I think Doug\'s suggestion of keeping the schema files in-tree and pushing\n> them to a well-known tarball maker in a build step is best so far.\n> \n> It\'s still a little clunky, but not as clunky as having to sync two repos.\n\nYes, I tend to agree.\n\nSo just to confirm that my understanding lines up:\n\n* the tarball would be used by the consumer-side for unit tests and\n  limited functional tests (where the emitter service is not running)\n\n* the tarball would be also be used by the consumer-side in DSVM-based\n  CI and in a full production deployments (where the emitter service is\n  running)\n\n* the tarballs will be versioned, with old versions remaining accessible\n  (as per the current practice with released source on tarballs.openstack.org)\n\n* the consumer side will know which version of each schema it expects to\n  support, and will download the appropriate tarball at runtime\n\n* the emitter side will signal the schema version that\'s it actually using,\n  via say a well-known field in the notification body\n\n* the consumer will reject notification payloads with a mismatched major\n  version to what it\'s expecting to support\n \n> >[snip]\n> >> >> d. Should we make separate distro packages? Install to a well known\n> >> >> location all the time? This would work for local dev and integration\n> >> >> testing and we could fall back on B and C for production distribution.\n> >> >> Of\n> >> >> course, this will likely require people to add a new distro repo. Is\n> >> >> that\n> >> >> a concern?\n> >>\n> >> >Quick clarification ... when you say \"distro packages\", do you mean\n> >> >Linux-distro-specific package formats such as .rpm or .deb?\n> >>\n> >> Yep.\n> \n> >So that would indeed work, but just to sound a small note of caution\n> >that keeping an oft-changing package (assumption #5) up-to-date for\n> >fedora20/21 & epel6/7, or precise/trusty, would involve some work.\n> \n> >I don\'t know much about the Debian/Ubuntu packaging pipeline, in\n> >particular how it could be automated.\n> \n> >But in my small experience of Fedora/EL packaging, the process is\n> >somewhat resistant to many fine-grained updates.\n> \n> Ah, good to know. So, if we go with the tarball approach, we should be able\n> to avoid this. And it allows the service to easily service up the schema\n> using their existing REST API.\n\nI\'m not clear on how servicing up the schema via an existing API would\navoid the co-ordination issue identified in the original option (b)?\n\nWould that API just be a very simple proxying in front of the well-known\nsource of these tarballs? \n\nFor production deployments, is it likely that some shops will not want\nto require access to an external site such as tarballs.openstack.org?\n\nSo in that case, would we require that they mirror, or just assume that\ndownstream packagers will bundle the appropriate schema versions with\nthe packages for the emitter and consumer services?\n\nCheers,\nEoghan\n\n> Should we proceed under the assumption we\'ll push to a tarball in a\n> post-build step? It could change if we find it\'s too messy.\n> \n> -S\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A5352E0B@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1357319833.2368.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-04 17:17:13',0,'2013-01-04 17:17:13',NULL,'[openstack-dev] oslo library version summary','On Mon, 2012-12-17 at 23:29 +0000, Mark McLoughlin wrote:\n> On Sun, 2012-12-16 at 00:02 -0800, Monty Taylor wrote:\n> > Hey all,\n> > \n> > ttx, markmc and I synced up on the versioning of oslo libraries, and\n> > have settled on a system which is a superset of what we do with client\n> > libraries - which means we can just implement an additional feature in\n> > the current code and it\'ll handle both sets of things. We\'ll sync up\n> > later on to discuss applicability of this to the server projects as well.\n> > \n> > Essentially, it breaks down like this:\n> > \n> > A tag to the repo will trigger tarball generation.\n> > \n> > If the tag contains alpha\\d*, beta\\d* or rc\\d*, the tarball will only be\n> > uploaded to tarballs.openstack.org. This will allow those pre-releases\n> > to be used in the other projects.\n> > \n> > Otherwise, the tarball will be uploaded to tarballs.o.o AND PyPI. This\n> > should allow us to use released versions of oslo libraries in pip-requires.\n> > \n> > Turns out it\'s easy to implement:\n> > \n> > https://review.openstack.org/#/c/18171/\n> > \n> > As soon as that lands, we should be able to handle the oslo requirements.\n> \n> Thanks for that.\n> \n> I\'ve pushed another test repo here:\n> \n>   https://github.com/markmc/oslo-config\n> \n> It now includes all the history of cfg changes as James suggested.\n> \n> More importantly, I\'ve included the setuptools magic from oslo-incubator\n> so that it will be versioned correctly when we push a tag. I\'ve added\n> that code under the magic/ directory so that it won\'t actually get\n> installed with oslo.config. Could you check that what I\'ve done is\n> reasonable? It seems to work ...\n\nAny thoughts on this?\n\nI think I\'ve pretty much done what needs to be done for the first\noslo-config, but there\'s a bunch of follow on openstack-ci work?\n\n  - import the openstack-config repo into gerrit\n  - CI jobs\n  - make sure release tagging works\n  - ...\n\nCheers,\nMark.\n\n\n\n','<1355786957.8134.2.camel@sorcha>',NULL),('<13573_1402909888_539EB4C0_13573_20_2_d3a83135-067c-406e-ae4d-546d8f1adec7@PEXCVZYH01.corporate.adroot.infra.ftgroup>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 09:11:25',0,'2014-06-16 09:11:25',NULL,'[openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal','Hi all,\n\nWe\'ve just released our implementation of BGP VPN extensions (called \n\'BaGPipe\'), under a opensource license :\nhttps://github.com/Orange-OpenSource/bagpipe-bgp\n\nIt reuses some code from ExaBGP, but with a dedicated engine for VPN \ninstance creation through a rest API, and a modular architecture to \ndrive a dataplane (e.g. OpenVSwtich).  It is based on an internal \ndevelopment we did to address IaaS/IP VPN interconnection issues; \nalthough still young the project was the basis for a few working lab \nprototypes.  There is more info in the README.\n\nI filled-in a column for BaGPipe on the wiki page ( \nhttps://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison ), to give \nan idea where it stands, and let people think how that could address \nneeds in Openstack.  I also added a line to specify support for \nRoute-Target-constrained distribution of VPN routes (RFC4684), because \nit is a real need beyond VPNv4/v6 routes for some VPN interconnection \nuse deployments.\n\nBest,\n\n-Thomas\n\n\nNachi Ueno :\n> Hi folks\n>\n> ExaBGP won\'t suit for BGPVPN implementation because it isn\'t support vpnv4.\n> Ryu is supporting it, however they have no internal api to binding\n> neutron network & route target.\n> so I think contrail is a only solution for  BGPVPN implementation now.\n>\n>\n>\n> 2014-05-30 2:22 GMT-07:00 Mathieu Rohon <mathieu.rohon at gmail.com>:\n>> Hi,\n>>\n>> I was about mentionning ExaBGP too! can we also consider using those\n>> BGP speakers for BGPVPN implementation [1].\n>> This would be consistent to have the same BGP speaker used for every\n>> BGP needs inside Neutron.\n>>\n>> [1]https://review.openstack.org/#/c/93329/\n>>\n>>\n>> On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa <devvesa at gmail.com> wrote:\n>>> Hello Takashi,\n>>>\n>>> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing\n>>> blueprint[2], I\'ve added a new column for this speaker in the wiki page. I\n>>> plan to fill it soon.\n>>>\n>>> ExaBgp was our first choice because we thought that run something in library\n>>> mode would be much more easy to deal with (especially the exceptions and\n>>> corner cases) and the code would be much cleaner. But seems that Ryu BGP\n>>> also can fit in this requirement. And having the help from a Ryu developer\n>>> like you turns it into a promising candidate!\n>>>\n>>> I\'ll start working now in a proof of concept to run the agent with these\n>>> implementations and see if we need more requirements to compare between the\n>>> speakers.\n>>>\n>>> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison\n>>> [2]: https://review.openstack.org/#/c/90833/\n>>>\n>>> Regards,\n>>>\n>>>\n>>> On 29 May 2014 18:42, YAMAMOTO Takashi <yamamoto at valinux.co.jp> wrote:\n>>>> as per discussions on l3 subteem meeting today, i started\n>>>> a bgp speakers comparison wiki page for this bp.\n>>>>\n>>>> https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison\n>>>>\n>>>> Artem, can you add other requirements as columns?\n>>>>\n>>>> as one of ryu developers, i\'m naturally biased to ryu bgp.\n>>>> i appreciate if someone provides more info for other bgp speakers.\n>>>>\n>>>> YAMAMOTO Takashi\n>>>>\n>>>>> Good afternoon Neutron developers!\n>>>>>\n>>>>> There has been a discussion about dynamic routing in Neutron for the\n>>>>> past few weeks in the L3 subteam weekly meetings. I\'ve submitted a review\n>>>>> request of the blueprint documenting the proposal of this feature:\n>>>>> https://review.openstack.org/#/c/90833/. If you have any feedback or\n>>>>> suggestions for improvement, I would love to hear your comments and include\n>>>>> your thoughts in the document.\n>>>>>\n>>>>> Thank you.\n>>>>>\n>>>>> Sincerely,\n>>>>> Artem Dmytrenko\n>>>>\n\n_________________________________________________________________________________________________________________________\n\nCe message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc\npas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler\na l\'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d\'alteration,\nOrange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.\n\nThis message and its attachments may contain confidential or privileged information that may be protected by law;\nthey should not be distributed, used or copied without authorisation.\nIf you have received this email in error, please notify the sender and delete this message and its attachments.\nAs emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.\nThank you.\n\n\n','<CABJepwg3DJT8ST0tS0Mi5P98ovgbjVB_n3DSvGniMYHEpqUkCw@mail.gmail.com>',NULL),('<1357541216.2329.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 06:46:56',0,'2013-01-07 06:46:56',NULL,'[openstack-dev] [Openstack][Nova] Slow Nova API Calls from\n periodic-tempest-devstack-vm-check-hourly','On Fri, 2013-01-04 at 11:58 -0800, Joe Gordon wrote:\n> Conclusion\n> =========\n> \n> Nova REST calls take way long, even in small scale devstack/tempest\n> testing.  We should spend resources on fixing this for Grizzly.  I would\n> like to start a dialog on how we can fix this and see if anyone wants to\n> volunteer help.  Below are a few possible ideas of things that will help us\n> make the REST calls faster.\n> \n> * Continuously track REST API times of devstack/tempest jobs, to identify\n> slow API calls and watch for trends.  (logstash + statsd?)\n> * Identify the underlying cause of the slow performance.  It looks like\n> nova.db.api may be partially responsible, but not the only issue?  What\n> else is a bottleneck?\n> * Enable millisecond level time logging\n> https://review.openstack.org/#/c/18933/\n> * Add an option in devstack to enable python profiling?  Whats best way to\n> do this?\n> * Make more REST API related code asynchronous (via RPC)\n\nSummary is we\'re randomly seeing a multi-second delay in nova-api\nbetween the time a HTTP request is received and we send an AMQP message?\n\nSuspecting the DB calls is a good first guess. The ability to log slow\nDB calls would be nice. Perhaps MySQL has something we can use here,\nassuming we log some sort of client ID on the nova-api side that we can\nuse to correlate with the MySQL logs.\n\nExternal processes we run is also another place to look. Again, logging\nthose processes that take longer than a certain threshold to run might\nbe good.\n\nI\'d also investigate whether it\'s some other greenthread blocking the\nAPI request thread from running. What would be really nice would be some\nway of logging when a particular greenthread ran for a long time while\nother greenthreads are pending.\n\nIt would also be good to see some system level stats and see if it\'s\njust that the system is generally CPU or I/O bound while these slow\ncalls are happening. Maybe logging CPU, memory, disk and network usage\nalong with the top few processes every tenth of a second.\n\nCheers,\nMark.\n\n\n\n','<CAKe5d-SjnRRdYPycgpzFhnjvCW2uvw7psxrf7ShegbAG_P31GQ@mail.gmail.com>',NULL),('<1357543624.2329.24.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 07:27:04',0,'2013-01-07 07:27:04',NULL,'[openstack-dev] _() consensus??','On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:\n> Hi all,\n> \n> I understand that i18n is an important feature to customers and that having\n> gettextutils wrapped on all log messages will benefit\n> in packing custom .pot files to ship with a product.\n\nIf we want to i18n log messages, I think they should be in a separate\ntranslation domain from the messages we return to users of the REST API.\n\nThe problem with having them both in the same translation domain is that\ntranslators have no way of prioritizing the REST API messages nor do\nadministrators have any way of disabling the translation of log messages\nwithout the translation of the REST API messages.\n\nSomething like this:\n\n  import gettext\n\n  gettext.install(\'nova\', unicode=True)\n  t = gettext.translation(\'nova-logmsgs\', fallback=True)\n\n  import __builtin__\n  __builtin__.__dict__[\'L_\'] = t.ugettext\n\n  print _(\'This is a user-visible message\')\n  print L_(\'This is a log message\')\n\nThe next step is to handle the setuptools integration so that it can\ngenerate multiple template files and install multiple catalogs. Here\'s a\nquick experiment I did for extract_messages:\n\nFirst in setup.py, add the extract_log_messages command:\n\n  cmdclass = common_setup.get_cmdclass()\n\n  from babel.messages import frontend as babel\n\n  cmdclass[\'extract_log_messages\'] = babel.extract_messages\n\nand, secondly, in setup.cfg configure its default parameters:\n\n  [extract_log_messages]\n  no_default_keywords = True\n  keywords = L_\n  mapping_file = babel.cfg\n  output_file = nova/locale/nova-logmsgs.pot\n\nIt looks like it might just be possible to do this.\n\nI\'ve filed this oslo blueprint, since we\'d probably add some helper code\nto oslo to make this possible:\n\n  https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n\nCheers,\nMark.\n\n\n\n','<CAFf0h6dpw+5nZK+UGaLAxd9Uca+Gsf-Tnm9yBdde7q=F=05GTQ@mail.gmail.com>',NULL),('<1357545423.2329.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 07:57:03',0,'2013-01-07 07:57:03',NULL,'[openstack-dev] _() consensus??','On Mon, 2013-01-07 at 07:48 +0000, Monty Taylor wrote:\n> \n> On 01/07/2013 07:27 AM, Mark McLoughlin wrote:\n> > On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:\n> >> Hi all,\n> >>\n> >> I understand that i18n is an important feature to customers and that having\n> >> gettextutils wrapped on all log messages will benefit\n> >> in packing custom .pot files to ship with a product.\n> > \n> > If we want to i18n log messages, I think they should be in a separate\n> > translation domain from the messages we return to users of the REST API.\n> > \n> > The problem with having them both in the same translation domain is that\n> > translators have no way of prioritizing the REST API messages nor do\n> > administrators have any way of disabling the translation of log messages\n> > without the translation of the REST API messages.\n> > \n> > Something like this:\n> > \n> >   import gettext\n> > \n> >   gettext.install(\'nova\', unicode=True)\n> >   t = gettext.translation(\'nova-logmsgs\', fallback=True)\n> > \n> >   import __builtin__\n> >   __builtin__.__dict__[\'L_\'] = t.ugettext\n> > \n> >   print _(\'This is a user-visible message\')\n> >   print L_(\'This is a log message\')\n> > \n> > The next step is to handle the setuptools integration so that it can\n> > generate multiple template files and install multiple catalogs. Here\'s a\n> > quick experiment I did for extract_messages:\n> > \n> > First in setup.py, add the extract_log_messages command:\n> > \n> >   cmdclass = common_setup.get_cmdclass()\n> > \n> >   from babel.messages import frontend as babel\n> > \n> >   cmdclass[\'extract_log_messages\'] = babel.extract_messages\n> > \n> > and, secondly, in setup.cfg configure its default parameters:\n> > \n> >   [extract_log_messages]\n> >   no_default_keywords = True\n> >   keywords = L_\n> >   mapping_file = babel.cfg\n> >   output_file = nova/locale/nova-logmsgs.pot\n> > \n> > It looks like it might just be possible to do this.\n> > \n> > I\'ve filed this oslo blueprint, since we\'d probably add some helper code\n> > to oslo to make this possible:\n> > \n> >   https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> \n> GREAT!\n> \n> However, before we start doing multiple-domain craziness, we should\n> probably finish the task of consuming the messages we currently have.\n\nI don\'t follow? What aren\'t we doing? Bug #?\n\nCheers,\nMark.\n\n\n\n','<50EA7DE2.4040308@inaugust.com>',NULL),('<1357546584.2329.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 08:16:24',0,'2013-01-07 08:16:24',NULL,'[openstack-dev] _() consensus??','On Mon, 2013-01-07 at 15:58 +0800, Xu He Jie wrote:\n> On 2013?01?07? 15:27, Mark McLoughlin wrote:\n> > On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:\n> >> Hi all,\n> >>\n> >> I understand that i18n is an important feature to customers and that having\n> >> gettextutils wrapped on all log messages will benefit\n> >> in packing custom .pot files to ship with a product.\n> > If we want to i18n log messages, I think they should be in a separate\n> > translation domain from the messages we return to users of the REST API.\n> >\n> > The problem with having them both in the same translation domain is that\n> > translators have no way of prioritizing the REST API messages nor do\n> > administrators have any way of disabling the translation of log messages\n> > without the translation of the REST API messages.\n> >\n> > Something like this:\n> >\n> >    import gettext\n> >\n> >    gettext.install(\'nova\', unicode=True)\n> >    t = gettext.translation(\'nova-logmsgs\', fallback=True)\n> >\n> >    import __builtin__\n> >    __builtin__.__dict__[\'L_\'] = t.ugettext\n> >\n> >    print _(\'This is a user-visible message\')\n> User-visible message\'s translation domain should be decided by user\'s \n> locale.\n> If we wrapped message with \'_()\', those message will be translated as\n> server side locale.\n> \n> So we should remove all \'_()\' from exception message and we should find \n> a way for\n> get user locale from user\'s request and translated it.\n\nThat\'s a very good point. Care to file a bug on that?\n\nIt still makes sense to have REST API messages and log messages be in\nseparate translation domains, though.\n\nCheers,\nMark.\n\n\n\n','<50EA800A.3070109@linux.vnet.ibm.com>',NULL),('<1357547692.2329.37.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 08:34:52',0,'2013-01-07 08:34:52',NULL,'[openstack-dev] _() consensus??','On Mon, 2013-01-07 at 08:19 +0000, Monty Taylor wrote:\n> \n> On 01/07/2013 07:57 AM, Mark McLoughlin wrote:\n> > On Mon, 2013-01-07 at 07:48 +0000, Monty Taylor wrote:\n> >>\n> >> On 01/07/2013 07:27 AM, Mark McLoughlin wrote:\n> >>> On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:\n> >>>> Hi all,\n> >>>>\n> >>>> I understand that i18n is an important feature to customers and that having\n> >>>> gettextutils wrapped on all log messages will benefit\n> >>>> in packing custom .pot files to ship with a product.\n> >>>\n> >>> If we want to i18n log messages, I think they should be in a separate\n> >>> translation domain from the messages we return to users of the REST API.\n> >>>\n> >>> The problem with having them both in the same translation domain is that\n> >>> translators have no way of prioritizing the REST API messages nor do\n> >>> administrators have any way of disabling the translation of log messages\n> >>> without the translation of the REST API messages.\n> >>>\n> >>> Something like this:\n> >>>\n> >>>   import gettext\n> >>>\n> >>>   gettext.install(\'nova\', unicode=True)\n> >>>   t = gettext.translation(\'nova-logmsgs\', fallback=True)\n> >>>\n> >>>   import __builtin__\n> >>>   __builtin__.__dict__[\'L_\'] = t.ugettext\n> >>>\n> >>>   print _(\'This is a user-visible message\')\n> >>>   print L_(\'This is a log message\')\n> >>>\n> >>> The next step is to handle the setuptools integration so that it can\n> >>> generate multiple template files and install multiple catalogs. Here\'s a\n> >>> quick experiment I did for extract_messages:\n> >>>\n> >>> First in setup.py, add the extract_log_messages command:\n> >>>\n> >>>   cmdclass = common_setup.get_cmdclass()\n> >>>\n> >>>   from babel.messages import frontend as babel\n> >>>\n> >>>   cmdclass[\'extract_log_messages\'] = babel.extract_messages\n> >>>\n> >>> and, secondly, in setup.cfg configure its default parameters:\n> >>>\n> >>>   [extract_log_messages]\n> >>>   no_default_keywords = True\n> >>>   keywords = L_\n> >>>   mapping_file = babel.cfg\n> >>>   output_file = nova/locale/nova-logmsgs.pot\n> >>>\n> >>> It looks like it might just be possible to do this.\n> >>>\n> >>> I\'ve filed this oslo blueprint, since we\'d probably add some helper code\n> >>> to oslo to make this possible:\n> >>>\n> >>>   https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> >>\n> >> GREAT!\n> >>\n> >> However, before we start doing multiple-domain craziness, we should\n> >> probably finish the task of consuming the messages we currently have.\n> > \n> > I don\'t follow? What aren\'t we doing? Bug #?\n> \n> https://bugs.launchpad.net/openstack-ci/+bug/995287\n> \n> We happily collect the strings, translate them and install them - but to\n> the best of my knowledge we are still missing the code to actually\n> consume the translations. I\'d be thrilled to be wrong here...\n\nThe gettext.install(\'nova\') calls hook _() up as a call to ugettext().\n\nThe issue Clark alludes to is \"what is message catalogs aren\'t installed\nin a standard location?\" may be accurate, but AFAICT we\'re doing what\'s\nneeded to consume translations installed in standard locations.\n\nCheers,\nMark.\n\n\n\n','<50EA8521.90707@inaugust.com>',NULL),('<1357557757.2329.49.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 11:22:37',0,'2013-01-07 11:22:37',NULL,'[openstack-dev] _() consensus??','On Mon, 2013-01-07 at 10:09 +0000, Monty Taylor wrote:\n> \n> On 01/07/2013 08:34 AM, Mark McLoughlin wrote:\n> > On Mon, 2013-01-07 at 08:19 +0000, Monty Taylor wrote:\n> >>\n> >> On 01/07/2013 07:57 AM, Mark McLoughlin wrote:\n> >>> On Mon, 2013-01-07 at 07:48 +0000, Monty Taylor wrote:\n> >>>>\n> >>>> On 01/07/2013 07:27 AM, Mark McLoughlin wrote:\n> >>>>> On Sat, 2013-01-05 at 16:43 +0800, Zhongyue Luo wrote:\n> >>>>>> Hi all,\n> >>>>>>\n> >>>>>> I understand that i18n is an important feature to customers and that having\n> >>>>>> gettextutils wrapped on all log messages will benefit\n> >>>>>> in packing custom .pot files to ship with a product.\n> >>>>>\n> >>>>> If we want to i18n log messages, I think they should be in a separate\n> >>>>> translation domain from the messages we return to users of the REST API.\n> >>>>>\n> >>>>> The problem with having them both in the same translation domain is that\n> >>>>> translators have no way of prioritizing the REST API messages nor do\n> >>>>> administrators have any way of disabling the translation of log messages\n> >>>>> without the translation of the REST API messages.\n> >>>>>\n> >>>>> Something like this:\n> >>>>>\n> >>>>>   import gettext\n> >>>>>\n> >>>>>   gettext.install(\'nova\', unicode=True)\n> >>>>>   t = gettext.translation(\'nova-logmsgs\', fallback=True)\n> >>>>>\n> >>>>>   import __builtin__\n> >>>>>   __builtin__.__dict__[\'L_\'] = t.ugettext\n> >>>>>\n> >>>>>   print _(\'This is a user-visible message\')\n> >>>>>   print L_(\'This is a log message\')\n> >>>>>\n> >>>>> The next step is to handle the setuptools integration so that it can\n> >>>>> generate multiple template files and install multiple catalogs. Here\'s a\n> >>>>> quick experiment I did for extract_messages:\n> >>>>>\n> >>>>> First in setup.py, add the extract_log_messages command:\n> >>>>>\n> >>>>>   cmdclass = common_setup.get_cmdclass()\n> >>>>>\n> >>>>>   from babel.messages import frontend as babel\n> >>>>>\n> >>>>>   cmdclass[\'extract_log_messages\'] = babel.extract_messages\n> >>>>>\n> >>>>> and, secondly, in setup.cfg configure its default parameters:\n> >>>>>\n> >>>>>   [extract_log_messages]\n> >>>>>   no_default_keywords = True\n> >>>>>   keywords = L_\n> >>>>>   mapping_file = babel.cfg\n> >>>>>   output_file = nova/locale/nova-logmsgs.pot\n> >>>>>\n> >>>>> It looks like it might just be possible to do this.\n> >>>>>\n> >>>>> I\'ve filed this oslo blueprint, since we\'d probably add some helper code\n> >>>>> to oslo to make this possible:\n> >>>>>\n> >>>>>   https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> >>>>\n> >>>> GREAT!\n> >>>>\n> >>>> However, before we start doing multiple-domain craziness, we should\n> >>>> probably finish the task of consuming the messages we currently have.\n> >>>\n> >>> I don\'t follow? What aren\'t we doing? Bug #?\n> >>\n> >> https://bugs.launchpad.net/openstack-ci/+bug/995287\n> >>\n> >> We happily collect the strings, translate them and install them - but to\n> >> the best of my knowledge we are still missing the code to actually\n> >> consume the translations. I\'d be thrilled to be wrong here...\n> > \n> > The gettext.install(\'nova\') calls hook _() up as a call to ugettext().\n> > \n> > The issue Clark alludes to is \"what is message catalogs aren\'t installed\n> > in a standard location?\" may be accurate, but AFAICT we\'re doing what\'s\n> > needed to consume translations installed in standard locations.\n> \n> So... yes. If they are installed in standard locations, we should be\n> fairly good. However, there is some additional work we can do to consume\n> them even where they are installed via pip install.\n\nDo we have translations for any of our pip-installable projects yet?\n\n> <rant>\n> Python doesn\'t know how to install message catalogs, or man pages, or\n> anything else. Grumble.\n> </rant>\n> \n> The workaround we\'re using for message catalogs is taken from the Sphinx\n> source. That workaround is to keep them inside of the tree and include\n> them as data files in the install.\n\nAh, I see. We install them (well, the uncompiled .po message catalogs)\nin the python sitelib but gettext looks in /usr/share/locale for the\ncompiled message catalog.\n\nYes, you\'re right - we have work to do here :)\n\n> That way, there\'s not much code (can\n> be stolen from sphinx in not much time) involved in looking for the\n> files from inside of the data files location. Clearly we don\'t want to\n> that BREAK installations (like Debian packaging) that would actually\n> grab the files and put them in properly.\n> \n> Why bother then? Because we can\'t test that we are consuming the\n> messages without it. If we\'re ok with that - then cool! I will stop\n> caring and close that bug. But, if we _do_ want to put in testing\n> verification that we are shipping catalogs that we can consume, then we\n> need for them to work from a purely python toolchain.\n> \n> Sigh.\n> \n> Why can\'t we all just get along@!?!?!\"?!?!\n\nOh Monty, I thought we already did!\n\n:-P\n\nCheers,\nMark.\n\n\n\n','<50EA9EDE.7050207@inaugust.com>',NULL),('<1357578628.2329.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 17:10:28',0,'2013-01-07 17:10:28',NULL,'[openstack-dev] upgrading WebOb across all projects','On Thu, 2013-01-03 at 11:32 -0500, Doug Hellmann wrote:\n> The ceilometer team is using Pecan [1] for our next-generation API\n> framework. Pecan depends on a newer WebOb than is used by the other\n> OpenStack components, so I spent this morning reviewing the differences in\n> WebOb between 1.0.8 and 1.2.3 (the latest stable release) [2] and what\n> impact those changes might have on nova, cinder, keystone, and oslo (the 4\n> projects where I found WebOb being used -- please let me know if I missed\n> one).\n> \n> Most of the changes appear to be bug fixes and changes that either have a\n> backwards-compatible alias, are deprecations that were reversed later, or\n> should not have an impact on us because we were not using the changed area\n> of the code directly. The only thing I found to be questionable is the\n> change to Request.path_info and Request.script_name. Those properties are\n> now unicode objects instead of str objects, as WebOb is trying to provide\n> better Python 3 support. I found a few uses of those variables in\n> comparisons and concatenation with str objects, but the casting should work\n> automatically as long as the path can be encoded in the default encoding,\n> which should be the case as the paths to our API use only ASCII characters.\n> All of the unit tests pass when I run them locally.\n> \n> I have submitted patches against the 4 projects to update the version\n> number in tools/pip-requires, without any other code changes:\n> \n> Oslo: https://review.openstack.org/#/c/18885/\n> Nova: https://review.openstack.org/#/c/18886/\n> Keystone: https://review.openstack.org/#/c/18887/\n> Cinder: https://review.openstack.org/#/c/18888/\n\nThe issue Sean raised in the Nova review is:\n\n  ubuntu quantal, debian unstable, and fedora latest all seem to\n  have webob 1.1.1\n\nIs there anyway we can make \'>= 1.1.1\' the requirement and keep all\nprojects happy?\n\nDistro packagers - anyone know the reason why webob isn\'t getting\nupdated in distros?\n\nCheers,\nMark.\n\n\n\n','<CADb+p3Sv9WAR8iqbHJGEqaCH281ajG_jhfGhnx5R4LRKaeRPgA@mail.gmail.com>',NULL),('<1357660777.2322.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-08 15:59:37',0,'2013-01-08 15:59:37',NULL,'[openstack-dev] [oslo-incubator] pyzmq in test-requires','On Tue, 2013-01-08 at 10:52 -0500, Eric Windisch wrote:\n> For some time, the ZeroMQ tests have been disabled due to a race\n> condition that would cause occassional failures and would upset\n> Jenkins.\n> \n> \n> That race condition is now fixed and I\'m seeking to have the tests run\n> again.  When I last worked on this, Monty had been working on\n> full-vs-partial dependencies testing such that diffciult dependencies\n> such as ZeroMQ, Qpid, and MySQL that require shared C libraries could\n> be tested separately from the pure-python code that could be easily\n> managed via \'pip\'.  However, that work seems to have been reverted.\n> \n> \n> As such, the only present solution would be, as has happened with\n> MySQL, to put pyzmq directly into test-requires. This would make the\n> pyzmq library and, by extension, the C libzmq library, a requirement\n> for running tests locally (as well as on Jenkins)\n> \n> \n> I would presume that in doing this, we\'d open the door to introducing\n> a Qpid dependency as well.\n> \n> \n> The following review contains a patch introducing pyzmq to\n> test-requires:\n>   https://review.openstack.org/#/c/19202/\n\nAIUI, dependencies listed in test-requires need to be pip-installable.\n\nI don\'t know of any current progress on changing that?\n\nCheers,\nMark.\n\n\n\n','<9D2C393F004E4674A3C51E657237ABFE@cloudscaling.com>',NULL),('<1357661228.2322.36.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-08 16:07:08',0,'2013-01-08 16:07:08',NULL,'[openstack-dev] [oslo-incubator] pyzmq in test-requires','On Tue, 2013-01-08 at 11:02 -0500, Eric Windisch wrote:\n> > \n> > \n> > AIUI, dependencies listed in test-requires need to be\n> > pip-installable.\n> > \n> > \n> > I don\'t know of any current progress on changing that?\n> The pyzmq dependency listed is pip-installable, but it is a Cython\n> module dependening on the libzmq shared library.\n> \n> \n> This is similar to MySQL-Python, which depends on a C library and is\n> currently in pip-requires.\n\nOK, that makes sense.\n\nSo it\'s just a question of:\n\n  if a pip-installable module requires a C library, it can be added as a\n  test-requires dependency IFF we know the C library will be installed \n  on the Jenkins slaves\n\n?\n\nCheers,\nMark.\n\n\n\n\n','<FAA4A699F6C846808B154F87F23934D4@cloudscaling.com>',NULL),('<13579752-5FA0-482B-80A6-CFE6E3491FFC@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 12:41:26',-14400,'2014-07-14 16:41:26',NULL,'[openstack-dev] [all] switch from mysqldb to another eventlet\n	aware mysql client -- status of postgresql drivers?','\nOn Jul 14, 2014, at 12:29 PM, Chris Friesen <chris.friesen at windriver.com> wrote:\n\n> On 07/09/2014 05:17 AM, Ihar Hrachyshka wrote:\n>> -----BEGIN PGP SIGNED MESSAGE-----\n>> Hash: SHA512\n>> \n>> Hi all,\n>> \n>> Multiple projects are suffering from db lock timeouts due to deadlocks\n>> deep in mysqldb library that we use to interact with mysql servers. In\n>> essence, the problem is due to missing eventlet support in mysqldb\n>> module, meaning when a db lock is encountered, the library does not\n>> yield to the next green thread, allowing other threads to eventually\n>> unlock the grabbed lock, and instead it just blocks the main thread,\n>> that eventually raises timeout exception (OperationalError).\n>> \n>> The failed operation is not retried, leaving failing request not\n>> served. In Nova, there is a special retry mechanism for deadlocks,\n>> though I think it\'s more a hack than a proper fix.\n> \n> This may be a bit of a tangent to the original discussion, but does anyone know where we stand with postgres and eventlets?  Is pyscopg2 susceptible to the same problems as mysqldb?\n\nif psycopg2 is in use, the set_wait_callback() extension must be enabled.\n\nsee http://initd.org/psycopg/docs/extensions.html#psycopg2.extensions.set_wait_callback and https://bitbucket.org/zzzeek/green_sqla/src/2732bb7ea9d06b9d4a61e8cd587a95148ce2599b/green_sqla/psyco_gevent.py?at=default for an example use taken from psycopg2 developers.\n\n\n\n\n','<53C40557.3050301@windriver.com>',NULL),('<1357996055.610339.1387322269587.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 00:17:49',3600,'2013-12-17 23:17:49',NULL,'[Openstack] [openstack][ceilometer] MongoDB replica set\n connection	string','----- Original Message -----\n> From: \"Prashanth Hari\" <hvprash at gmail.com>\n> To: openstack at lists.openstack.org\n> Sent: Tuesday, December 17, 2013 8:35:03 PM\n> Subject: [Openstack] [openstack][ceilometer] MongoDB replica set connection	string\n> \n> I assume ceilometer currently supports MongoDB replica sets.\n> Can someone provide inputs on how to enable replica set definitions in\n> configs ?\n> \n\nHi, see MongoDB Connection-strign reference [1]\n\n[1] http://docs.mongodb.org/manual/reference/connection-string/\n\nCheers.\n-- \nFran?ois Charlier                       Software Engineer\n// eNovance SAS                  http://www.enovance.com/\n// ? francois.charlier at enovance.com  ? +33 1 49 70 99 81\n\n\n\n','<CADW3kYOGm+iLRPX3YtQQL0wgUdTx3n2t8_fh45tKuQxoLGQtkQ@mail.gmail.com>',NULL),('<1358163551.8737.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-14 11:39:11',0,'2013-01-14 11:39:11',NULL,'[openstack-dev] A new nova service? nova-periodic?','On Mon, 2013-01-14 at 11:24 +0000, Daniel P. Berrange wrote:\n> On Mon, Jan 14, 2013 at 09:55:12PM +1100, Michael Still wrote:\n> > On Mon, Jan 14, 2013 at 9:44 PM, Daniel P. Berrange <berrange at redhat.com> wrote:\n> > \n> > [snip]\n> > \n> > > For example in the libvirt driver we use a threadpool for running the\n> > > native API calls to avoid blocking eventlet. This doc\n> > >\n> > >   doc/source/devref/threading.rst\n> > >\n> > > indicates that DB calls used to do the same thing, but apparently don\'t\n> > > anymore. That said, this may be solved with most of the DB calls being\n> > > removed due to nodb-compute blueprint. There could be other areas that\n> > > would benefit from a threadpool though\n> > \n> > So the current big use case for this is in the libvirt driver. The\n> > image cache manager needs to do a lot of file IO, and it locks up the\n> > main thread while it does that. If your images are really large, then\n> > it locks the world up for a really long time. Now, the initial\n> > proposal for that was to put a heap of yields into the code that did\n> > the IO, but we didn\'t like that, so this code started out as a way of\n> > exploring how to solve the problem without yielding. It should be\n> > noted this all came about at the request of Yahoo! who had performance\n> > problems because of this IO load. In fact, I\'m pretty sure that the\n> > image cache manager is the only \"external capable\" periodic task at\n> > the moment, but I am sure there could be more.\n> \n> Looking at the code that is run for the image cache manager, I can\'t\n> help thinking this would easily be handled by a native thread without\n> introducing any concurrency/locking problems wrt the rest of the Nova\n> libvirt driver. So IMHO this doesn\'t really justify a new standalone\n> service.\n\nOr perhaps even simpler than native threads, have the periodic task\nspawn off a new process for the long-running operation and reap it on\nthe next task iteration.\n\nCheers,\nMark.\n\n\n\n','<20130114112427.GG9663@redhat.com>',NULL),('<1358184435.8737.38.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-14 17:27:15',0,'2013-01-14 17:27:15',NULL,'[openstack-dev] Moving forward with openstack/requirements','On Sat, 2013-01-12 at 19:30 -0800, Monty Taylor wrote:\n> Hey all!\n> \n> Once again, we\'ve kind of stalled out on our two-summit old project of\n> common requirements across the projects. The initial repo is up at\n> http://github.com/openstack/requirements but I think not much happens\n> with it because working on it doesn\'t really get you anything right now.\n\nJust to remind ourselves, here\'s what we discussed at the last summit:\n\nhttps://etherpad.openstack.org/process-dependency-management\n\nThanks for prodding this again - I was starting to get really grumpy\nwith myself for not doing anything to help it along :)\n\n> So I\'ve got an idea for steps to move forward.\n> \n> Step 0: Re-sync the contents of the files with the new state of reality\n\nTake a look at:\n\n  https://github.com/markmc/requirements/\n\nIs that what you\'re thinking?\n\n> Step 1: Drive updates to the OpenStack PyPI mirror from the requirements\n> repo\n> Step 2: Configure the Jenkins slaves to only talk to the PyPI mirror for pip\n> Step 3: Add a step to the pypi mirror creation that pulls packages fresh\n> from requirements into a new proposed state of the PyPI mirror, then\n> tests all of the projects against that mirror and only promotes new\n> packages into if those tests pass.\n> \n> That\'s it. Done.\n> \n> If we do through step 2, it means that before someone can add a new\n> requirement to a project, it would have to go into\n> openstack/requirements. If we do step 3, it\'ll trap for things like the\n> sqlalchemy 0.8 upgrade issue. It also, as an approach, doesn\'t enforce\n> that projects have to upgrade at any point, because previous versions of\n> things will still be in our mirror (we don\'t purge it)\n\nI think there\'s 3 things we want to catch:\n\n  1) When whole new libraries are added as a dependency\n\n  2) When the minimum version of a dependency is increased\n\n  3) When a project wants to specify a version range that is \n     incompatible with another project\'s version range\n\nI think what you\'re talking about will catch (1) and (3) but not (2).\n\nTo catch (2), I guess we\'d need a separate pypi mirror with all the\nminimum versions of dependencies and a set of jobs to run tests with\nthat mirror?\n\n> Also - while you\'re all thinking about it - I\'ve been considering\n> getting the code we have in oslo-incubator setup that makes setup.py\n> understand pip-requires and test-requires automatically upstreamed\n> (seems like a thing we\'re not the only ones who would want it) The catch\n> - those aren\'t the filenames most people use for those files. SO - what\n> if we (and by we, I mean I, and by I, I mean a shell script that submits\n> a bajillion reviews) renamed tools/pip-requires to requirements.txt and\n> tools/test-requires to test-requirements.txt? I\'ve already updated our\n> mirror creation code to recognize both files. If people are cool with\n> that, I can then work on trying to get a patch into distribute that\n> would allow for that - which would mean less copied code for us.\n\nSounds good to me.\n\nAt the summit, I said I\'d take a stab at resolving the differences\nbetween the requires of the core projects so that the effective\nrequirements of the project as a whole were consistent. I\'ve dumped some\nnotes about what I think needs fixing here:\n\n  https://github.com/markmc/requirements/blob/master/issues.txt\n\nCheers,\nMark.\n\n\n\n','<50F22A3C.4010509@inaugust.com>',NULL),('<1358251471.2376.18.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 12:04:31',0,'2013-01-15 12:04:31',NULL,'[openstack-dev] RFC: Synchronizing hypervisor <-> nova state\n with event notifications','On Tue, 2013-01-15 at 10:52 +0000, Daniel P. Berrange wrote:\n> This email is in relation to the following bug\n> \n>   https://bugs.launchpad.net/nova/+bug/1099761\n> \n> If a guest administrator shuts down their VM from inside the guest\n> OS using \'shutdown -h now\' (or equivalent), it will take Nova upto\n> 10 minutes to notice that the VM has stopped running\n> \n> The Nova<->hypervisor state synchronization is done in a periodic\n> task (nova.compute.manager._sync_power_states) which only runs\n> every 10 minutes. It used to be every 60 seconds until this bug\n> was addressed:\n> \n>   https://bugs.launchpad.net/nova/+bug/928910\n> \n> I put most of the blame for that bug\'s perforance issues in the use\n> of the wrong libvirt APIs, but none the less I don\'t really want to\n> put the periodic task frequency back down to 60 seconds.\n> \n> IMHO the key problem here is the design, not the implementation. In\n> particular the use of polling by the manager to detect the state\n> changes is inherantly inefficient. Libvirt provides an async event\n> notification mechanism allowing applications to have a callback\n> triggered whenever a guest changes lifecycle state. Other hypervisor\n> APIs like ESX have similar notification mechanisms. Making use of\n> this would allow state changes to be detected pretty much immediately.\n> \n> The question is how to structure the processing of events. I don\'t\n> think that the hypervisor drivers should be directly processing events.\n> Instead I believe they need to pass along the event notifications to\n> the manager.py class. So my current thought is to introduce a new API\n> to nova.virt.api\n> \n>   register_event_notifier(self, callback)\n> \n> and have nova.compute.manager provide a callback impl to receive the\n> events. Before I start coding on this, I want some kind of confirmation\n> that this is an acceptable direction to go in, since there is no current\n> callback based interactions between nova.compute.manager & nova.virt.api\n\nThat all sounds good to me, but can you go into more details about how\nthe event dispatching would work?\n\nWe don\'t have a mainloop to integrate this with, so presumably you\'re\ntalking about spawning a greenthread which would poll for events (using\nvirEventRunDefaultImpl()?) and then invoke the callbacks? Does this\ngreenthread need its own libvirt connection?\n\nDoes this new thread introduce any new concurrency issues? I guess not\nsince processing each RPC message and running periodic timers all happen\nin different threads, so this wouldn\'t be much different.\n\nCheers,\nMark.\n\n\n\n','<20130115105239.GE14801@redhat.com>',NULL),('<1358255249.2376.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 13:07:29',0,'2013-01-15 13:07:29',NULL,'[openstack-dev] A new nova service? nova-periodic?','On Tue, 2013-01-15 at 07:59 +1100, Michael Still wrote:\n>  - we change the periodic task running code to fork() a process every\n> time it needs to run an \"external\" periodic task, it then wait()s for\n> those processes later in its loop: means you can have as many slow\n> periodic tasks as you want without them blocking each other, makes the\n> periodic task running more complex and therefore more likely to have\n> bugs, easy to deploy, transparent to users. \n\nWorks for me. I\'d be a little wary of issues we might see in the forked\nprocess around duplicated file descriptors and the like, so another\noption could be to implement nice scripts for each task which we\'d\nexec().\n\nThis has the nice advantage of allow the admin to run the periodic task\nscript directly for whatever reason. Maybe a single nova-compute-task\nscript?\n\nCheers,\nMark.\n\n\n\n','<CAEd1pt4b_xL1=pT3DWe7e1DvLpT1AQDV43i_yM_ew+i+rNQuSA@mail.gmail.com>',NULL),('<1358257553.2376.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 13:45:53',0,'2013-01-15 13:45:53',NULL,'[openstack-dev] RFC: Synchronizing hypervisor <-> nova state\n with event notifications','On Tue, 2013-01-15 at 13:24 +0000, Daniel P. Berrange wrote:\n> On Tue, Jan 15, 2013 at 12:04:31PM +0000, Mark McLoughlin wrote:\n> > On Tue, 2013-01-15 at 10:52 +0000, Daniel P. Berrange wrote:\n> > > The question is how to structure the processing of events. I don\'t\n> > > think that the hypervisor drivers should be directly processing events.\n> > > Instead I believe they need to pass along the event notifications to\n> > > the manager.py class. So my current thought is to introduce a new API\n> > > to nova.virt.api\n> > > \n> > >   register_event_notifier(self, callback)\n> > > \n> > > and have nova.compute.manager provide a callback impl to receive the\n> > > events. Before I start coding on this, I want some kind of confirmation\n> > > that this is an acceptable direction to go in, since there is no current\n> > > callback based interactions between nova.compute.manager & nova.virt.api\n> > \n> > That all sounds good to me, but can you go into more details about how\n> > the event dispatching would work?\n> > \n> > We don\'t have a mainloop to integrate this with, so presumably you\'re\n> > talking about spawning a greenthread which would poll for events (using\n> > virEventRunDefaultImpl()?) and then invoke the callbacks? Does this\n> > greenthread need its own libvirt connection?\n> > \n> > Does this new thread introduce any new concurrency issues? I guess not\n> > since processing each RPC message and running periodic timers all happen\n> > in different threads, so this wouldn\'t be much different.\n> \n> Yes, thanks to eventlet awfulness, we\'d need to have a greenthread running\n> the libvirt event loop.  The event notification callbacks from libvirt\n> would thus obviously execute in the greenthread. What I\'m not sure about\n> is how to switch control back to the main eventlet thread before we call\n> out into the manager.py\'s callback.\n>\n> I imagine a queue of events in the nova.virt.libvirt.driver object which\n> is fed back the libvirt greenthread callbacks. Something in the main\n> eventlet thread would then have to process the queue to dispatch to the\n> manager. With a regular mainloop the way you\'d do this is to schedule a\n> timer to fire after zero seconds. I\'m not familiar enough with eventlet\n> yet to know how you\'d do this.\n\nThere isn\'t really a \"main eventlet thread\" - the main greenthread is\njust sitting there waiting for the other greenthreads to finish.\n\nThe greenthread for consuming RPC messages spawns off a greenthread for\neach message and this is the normal entry point into manager.py.\n\nThat\'s why I\'m thinking just invoking the callback directly from your\ngreenthread would work.\n\n(I\'m explicitly saying greenthread over and over because it\'s so easy to\nforget these aren\'t native threads :)\n\nCheers,\nMark.\n\n\n\n','<20130115132451.GA26531@redhat.com>',NULL),('<1358266199.2376.67.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 16:09:59',0,'2013-01-15 16:09:59',NULL,'[openstack-dev] Technical Committee membership evolution','On Tue, 2013-01-15 at 16:52 +0100, Thierry Carrez wrote:\n...\n> We are considering adding more projects in the integrated release in the\n> future, but adding more PTLs with guaranteed TC seats doesn\'t really\n> scale, quickly leading to committee bloat (personally I think 13 is the\n> maximum workable number).\n...\n> 3/ Limit the TC to 13 members, and have them all directly-elected (the\n> most significant PTLs will get elected anyway)\n\nThis would be my preference - because it\'s simple.\n\n13 seats gives ample opportunity for diverse parts of the development\ncommunity to be represented.\n\nIt also means that the committee can\'t assume all parts of the project\nare represented at its meetings and must reach out for broader input.\n\nIMHO, the TC is a group of people charged with building a rough\nconsensus on cross-project topics. I\'d much rather see the 13 seats open\nto those who are actively interested in this cross-project consensus\nbuilding.\n\nNo TC could consider itself as having reached a consensus if PTLs are\nobjecting strongly to a proposal. Indeed, I think PTL come pretty close\nto having a veto when it comes to proposals which affect their projects.\nIMHO, that effective veto makes the \"1 vote in 13\" from a PTL\'s seat on\nthe TC look like a pretty minor thing.\n\n> 4/ Limit the TC to 13 members, have them all directly-elected, *and*\n> guarantee that a minimum of 8 PTLs end up in the committee\n...\n\nThis is the next best option but is a layer of bureaucracy and\nover-engineering I think we could live without.\n\nCheers,\nMark.\n\n\n\n','<50F57B50.5080306@openstack.org>',NULL),('<1358266282.2376.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 16:11:22',0,'2013-01-15 16:11:22',NULL,'[openstack-dev] Technical Committee membership evolution','On Tue, 2013-01-15 at 16:09 +0000, Mark McLoughlin wrote:\n> On Tue, 2013-01-15 at 16:52 +0100, Thierry Carrez wrote:\n> ...\n> > We are considering adding more projects in the integrated release in the\n> > future, but adding more PTLs with guaranteed TC seats doesn\'t really\n> > scale, quickly leading to committee bloat (personally I think 13 is the\n> > maximum workable number).\n> ...\n> > 3/ Limit the TC to 13 members, and have them all directly-elected (the\n> > most significant PTLs will get elected anyway)\n> \n> This would be my preference - because it\'s simple.\n\nOh, I forgot to say - I\'d prefer to try something simple and evolve to\nsomething more complex if we find problems with the simple approach.\n\nClearly, it is possible for us to evolve this since that\'s what we\'re\ndoing right now :)\n\nCheers,\nMark.\n\n\n\n','<1358266199.2376.67.camel@sorcha>',NULL),('<1358266735.2376.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 16:18:55',0,'2013-01-15 16:18:55',NULL,'[openstack-dev] RFC: Synchronizing hypervisor <-> nova state\n with event notifications','On Tue, 2013-01-15 at 13:58 +0000, Daniel P. Berrange wrote:\n> On Tue, Jan 15, 2013 at 01:45:53PM +0000, Mark McLoughlin wrote:\n> > On Tue, 2013-01-15 at 13:24 +0000, Daniel P. Berrange wrote:\n> > > On Tue, Jan 15, 2013 at 12:04:31PM +0000, Mark McLoughlin wrote:\n> > > > On Tue, 2013-01-15 at 10:52 +0000, Daniel P. Berrange wrote:\n> > > > > The question is how to structure the processing of events. I don\'t\n> > > > > think that the hypervisor drivers should be directly processing events.\n> > > > > Instead I believe they need to pass along the event notifications to\n> > > > > the manager.py class. So my current thought is to introduce a new API\n> > > > > to nova.virt.api\n> > > > > \n> > > > >   register_event_notifier(self, callback)\n> > > > > \n> > > > > and have nova.compute.manager provide a callback impl to receive the\n> > > > > events. Before I start coding on this, I want some kind of confirmation\n> > > > > that this is an acceptable direction to go in, since there is no current\n> > > > > callback based interactions between nova.compute.manager & nova.virt.api\n> > > > \n> > > > That all sounds good to me, but can you go into more details about how\n> > > > the event dispatching would work?\n> > > > \n> > > > We don\'t have a mainloop to integrate this with, so presumably you\'re\n> > > > talking about spawning a greenthread which would poll for events (using\n> > > > virEventRunDefaultImpl()?) and then invoke the callbacks? Does this\n> > > > greenthread need its own libvirt connection?\n> > > > \n> > > > Does this new thread introduce any new concurrency issues? I guess not\n> > > > since processing each RPC message and running periodic timers all happen\n> > > > in different threads, so this wouldn\'t be much different.\n> > > \n> > > Yes, thanks to eventlet awfulness, we\'d need to have a greenthread running\n> > > the libvirt event loop.  The event notification callbacks from libvirt\n> > > would thus obviously execute in the greenthread. What I\'m not sure about\n> > > is how to switch control back to the main eventlet thread before we call\n> > > out into the manager.py\'s callback.\n> > >\n> > > I imagine a queue of events in the nova.virt.libvirt.driver object which\n> > > is fed back the libvirt greenthread callbacks. Something in the main\n> > > eventlet thread would then have to process the queue to dispatch to the\n> > > manager. With a regular mainloop the way you\'d do this is to schedule a\n> > > timer to fire after zero seconds. I\'m not familiar enough with eventlet\n> > > yet to know how you\'d do this.\n> > \n> > There isn\'t really a \"main eventlet thread\" - the main greenthread is\n> > just sitting there waiting for the other greenthreads to finish.\n> > \n> > The greenthread for consuming RPC messages spawns off a greenthread for\n> > each message and this is the normal entry point into manager.py.\n> > \n> > That\'s why I\'m thinking just invoking the callback directly from your\n> > greenthread would work.\n> > \n> > (I\'m explicitly saying greenthread over and over because it\'s so easy to\n> > forget these aren\'t native threads :)\n> \n> Of course when I wrote \'greenthread\' in my description above, I of course\n> mean native thread. You can\'t invoke libvirt API calls directly from\n> greenthreads because native code blocks the whole interpretor unless you\n> use native threads.\n>\n> So the libvirt callback will be running in a native thread and needs to\n> pass control back to a greenthread for processing. I guess I can have a\n> dedicated greenthread that processes a queue of events from the native\n> thread.\n\nHmm, not sure I buy that.\n\nIf this was a single-threaded app with a mainloop, I think I\'d be happy\nto add libvirt\'s \"check for events\" timer to the main thread. Do you\nreally see the timer blocking for that long?\n\nWith eventlet and greenthreads, a greenthread which runs this timer is\nessentially the same thing.\n\nCheers,\nMark.\n\n\n\n','<20130115135830.GB26531@redhat.com>',NULL),('<1358272306.113.1384322577135.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-13 06:02:57',0,'2013-11-13 06:02:57',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #61','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/61/>\n\n\n\n','<1605580678.110.1384236131593.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1358363862.4146614@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-16 14:17:42',-18000,'2013-01-16 19:17:42',NULL,'[openstack-dev] Upgrade Glance python client to use Glance API v2 ?','Hey Ying,\n\nYou can get the Glance Pyhton Client to use Glance v2 API using:\nglance --os-image-api-version 2\n\nBut right now only limited functionality from Glance v2 API is accessible from Glance python client  (\'explain\', \'image-download\', \'image-list\', \'image-show\', \'help\').\n\nAlso, there is a blue print in progress for glance client to be able to talk to v2 glance api - https://blueprints.launchpad.net/python-glanceclient/+spec/glance-client-v2\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"Ying Chun Guo\" <guoyingc at cn.ibm.com>\nSent: Wednesday, January 16, 2013 12:47pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Upgrade Glance python client to use Glance API v2 ?\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nHi,\n\nI found the image APIs could not support non-ascii characters when using\nGlance python client. This is because Glance python client is still using\nthe API v1 and Glance v1 API doesn\'t support non-ascii characters.\n\nI want to understand if there is any plans to upgrade Glance python client\nto use v2 API. Thanks.\n\nRegards\nYing Chun Guo (Daisy)\n\n\n\n','<OF260A4837.3060BA09-ON48257AF5.00000BF3-48257AF5.0061C060@cn.ibm.com>',NULL),('<1358378711.30539.YahooMailNeo@web162202.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-01-16 15:25:11',-28800,'2013-01-16 23:25:11',NULL,'[Openstack-operators] customising network (flatdhcpmanager)\n	start_address and dns','\n\nAnton, Nux!,?\n\nWhile I am using a different networking model I had a few issue with a few directives from Folsom nova-network create as well. ?I was tooling around looking for a?relevant?issue or bug report.\n\nI found that the --dns1 and --dns2 directives really did nothing and I ended up hacking them into the network table. ?The result did not product the dnsmasq (dhcp) lease attribute assignment I excepted for a new VM. ?\n\nLikewise with --dhcp_start, it was was populated in the network table correctly and seemingly used by dnsmasq correctly\n\n? --dhcp-range=set:\'Network101\',10.101.0.11,static,120s?\n\nhowever, the static leases assignment still began with .3.\n\n\nI detailed some of my usage and syntax for?nova-network create.\nhttps://answers.launchpad.net/nova/+question/219375\n\n\n-t\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130116/fdb537d3/attachment.html>\n\n',NULL,NULL),('<1358469263.26.1380868262621.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-04 06:31:02',0,'2013-10-04 06:31:02',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #30','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/30/>\n\n------------------------------------------\n[...truncated 21133 lines...]\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\nInitialized empty Git repository in /tmp/tempest-unit8rLxpX/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unit_0YxAt/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until the Bug #1076965 is resolved\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          218.511\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  174.855\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  79.582\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     38.389\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      37.355\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]    30.841\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         30.354\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         30.215\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    29.346\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        29.101\n\n----------------------------------------------------------------------\nRan 1305 tests in 1312.981s\n\nOK (skipped=64)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-447342-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-447342.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-447342/30/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1036432164.18.1380781764346.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1358492910.2359.79.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-18 07:08:30',0,'2013-01-18 07:08:30',NULL,'[openstack-dev] RFC: Synchronizing hypervisor <-> nova state\n with event notifications','On Tue, 2013-01-15 at 16:41 +0000, Daniel P. Berrange wrote:\n> On Tue, Jan 15, 2013 at 04:18:55PM +0000, Mark McLoughlin wrote:\n> > On Tue, 2013-01-15 at 13:58 +0000, Daniel P. Berrange wrote:\n> > > On Tue, Jan 15, 2013 at 01:45:53PM +0000, Mark McLoughlin wrote:\n> > > > On Tue, 2013-01-15 at 13:24 +0000, Daniel P. Berrange wrote:\n> > > > > On Tue, Jan 15, 2013 at 12:04:31PM +0000, Mark McLoughlin wrote:\n> > > > > > On Tue, 2013-01-15 at 10:52 +0000, Daniel P. Berrange wrote:\n> > > > > > > The question is how to structure the processing of events. I don\'t\n> > > > > > > think that the hypervisor drivers should be directly processing events.\n> > > > > > > Instead I believe they need to pass along the event notifications to\n> > > > > > > the manager.py class. So my current thought is to introduce a new API\n> > > > > > > to nova.virt.api\n> > > > > > > \n> > > > > > >   register_event_notifier(self, callback)\n> > > > > > > \n> > > > > > > and have nova.compute.manager provide a callback impl to receive the\n> > > > > > > events. Before I start coding on this, I want some kind of confirmation\n> > > > > > > that this is an acceptable direction to go in, since there is no current\n> > > > > > > callback based interactions between nova.compute.manager & nova.virt.api\n> > > > > > \n> > > > > > That all sounds good to me, but can you go into more details about how\n> > > > > > the event dispatching would work?\n> > > > > > \n> > > > > > We don\'t have a mainloop to integrate this with, so presumably you\'re\n> > > > > > talking about spawning a greenthread which would poll for events (using\n> > > > > > virEventRunDefaultImpl()?) and then invoke the callbacks? Does this\n> > > > > > greenthread need its own libvirt connection?\n> > > > > > \n> > > > > > Does this new thread introduce any new concurrency issues? I guess not\n> > > > > > since processing each RPC message and running periodic timers all happen\n> > > > > > in different threads, so this wouldn\'t be much different.\n> > > > > \n> > > > > Yes, thanks to eventlet awfulness, we\'d need to have a greenthread running\n> > > > > the libvirt event loop.  The event notification callbacks from libvirt\n> > > > > would thus obviously execute in the greenthread. What I\'m not sure about\n> > > > > is how to switch control back to the main eventlet thread before we call\n> > > > > out into the manager.py\'s callback.\n> > > > >\n> > > > > I imagine a queue of events in the nova.virt.libvirt.driver object which\n> > > > > is fed back the libvirt greenthread callbacks. Something in the main\n> > > > > eventlet thread would then have to process the queue to dispatch to the\n> > > > > manager. With a regular mainloop the way you\'d do this is to schedule a\n> > > > > timer to fire after zero seconds. I\'m not familiar enough with eventlet\n> > > > > yet to know how you\'d do this.\n> > > > \n> > > > There isn\'t really a \"main eventlet thread\" - the main greenthread is\n> > > > just sitting there waiting for the other greenthreads to finish.\n> > > > \n> > > > The greenthread for consuming RPC messages spawns off a greenthread for\n> > > > each message and this is the normal entry point into manager.py.\n> > > > \n> > > > That\'s why I\'m thinking just invoking the callback directly from your\n> > > > greenthread would work.\n> > > > \n> > > > (I\'m explicitly saying greenthread over and over because it\'s so easy to\n> > > > forget these aren\'t native threads :)\n> > > \n> > > Of course when I wrote \'greenthread\' in my description above, I of course\n> > > mean native thread. You can\'t invoke libvirt API calls directly from\n> > > greenthreads because native code blocks the whole interpretor unless you\n> > > use native threads.\n> > >\n> > > So the libvirt callback will be running in a native thread and needs to\n> > > pass control back to a greenthread for processing. I guess I can have a\n> > > dedicated greenthread that processes a queue of events from the native\n> > > thread.\n> > \n> > Hmm, not sure I buy that.\n> > \n> > If this was a single-threaded app with a mainloop, I think I\'d be happy\n> > to add libvirt\'s \"check for events\" timer to the main thread. Do you\n> > really see the timer blocking for that long?\n> \n> To receive events from libvirt you need to provide an event loop impl\n> to libvirt, in the form of running this code:\n> \n>   libvirt.virEventRegisterDefaultImpl()\n>   while True:\n>      libvirt.virEventRunDefaultImpl()\n> \n> to allow libvirt to process incoming events from libvirtd. While those\n> API calls above are invoked from a greenthread, since we use a native\n> threadpool for all libvirt APIs, this means they\'re going to actually\n> switch to a native to run the C code. This implies that the callback\n> from libvirt is going to be invoked in the context of a native thread.\n> We thus need to get out of native thread context & into a greenthread\n> context before we can pass the event back up to the nova.compute.manager\n> class\' callback.\n\nFWIW, that makes sense to me - I\'d missed the fact that we use a native\nthreadpool for libvirt API calls.\n\nCheers,\nMark.\n\n\n\n','<20130115164110.GC9079@redhat.com>',NULL),('<1358518218.2359.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-18 14:10:18',0,'2013-01-18 14:10:18',NULL,'[openstack-dev] Nova\'s use of task_state for reboot serialization','Hey\n\nHere\'s a scenario I came across yesterday in a real Folsom deployment:\n\n  https://bugs.launchpad.net/nova/+bug/982108\n\n  - compute node locked up for over 12 due to what looks like a kernel \n    bug\n\n  - during that time, someone came along and tried to reboot their \n    instance with horizon which does a hard reboot\n\n  - the reboot message was cast to the compute node but never picked up \n    so the instance was in task_state=REBOOTING_HARD\n\n  - once the compute node had come back to life, the user tried \n    rebooting again  but wasn\'t allowed. The instance needed admin \n    intervention to get unstuck.\n\nAt first, I thought this was just an oversight that REBOOTING_HARD\nwasn\'t one of the allowed states for rebooting.\n\nHowever, I came across a discussion here:\n\n  https://review.openstack.org/5090\n\nwhich shows that we\'re using task_state to prevent multiple reboots of\nthe same type happening at once. I\'m assuming that\'s because the reboots\nwould interfere with me, e.g. attempting to create the same VM twice.\n\nThat has me wondering why we just don\'t take a lock on the instance in\nthe compute manager during a reboot?\n\nIsn\'t it the case that we should only be using task_state as a kind of\n\"it doesn\'t make sense to do foo while bar is happening\" type policies?\nAs opposed to task serialization?\n\nAlso, if a task is kicked off with a cast we never know if it the\nmessage was ever actually received and don\'t know to revert the\ntask_state in the case? If we want asynchrony in these cases, shouldn\'t\nbe call() but have the compute node spawn off a greenthread to carry out\nthe action? That way the message is acknowledged and we know that\ntask_state reversion should happen if it fails from that point on.\n\nIn summary, the patch I\'d cook up for this would change the reboot\ncast() to call() and have nova-compute spawn off a greenthread which\ntakes the instance lock for the duration of the reboot and reverts\ntask_state on failure.\n\nAm I missing something?\n\nIs this a fundamental change from our previous thinking and we should\naudit for similar problems, or is this just an individual oddity?\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1358520113.2359.117.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-18 14:41:53',0,'2013-01-18 14:41:53',NULL,'[openstack-dev] Heads up: bumping the required version of greenlet\n	to 0.3.2','Hi\n\nSee here: https://review.openstack.org/20026\n\nWe currently require greenlet>=0.3.1 and 0.3.1 is almost 3 years old. \n\nIt\'s the version in Fedora 18 and Ubuntu Precise.\n\n0.3.2 has a fix for a nasty issue found with Oslo\'s thread group.\n\nUbuntu Quantal has 0.3.3. The latest version is 0.4.0.\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1358531010.25534679@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-01-18 11:43:30',-21600,'2013-01-18 17:43:30',NULL,'[OpenStack Foundation] 2013 Individual Director election','Thierry & Stefano will be in Brussels for FOSDEM, and have a lot of cool stuff lined up:\n\nhttp://www.openstack.org/blog/2013/01/openstack-at-fosdem13/\n\n\n\nOn Friday, January 18, 2013 11:34am, \"Dave Neary\" <dneary at redhat.com> said:\n\n> Congratulations to all the newly elected (and re-elected) board members!\n> \n> Just an FYI: the board meeting has times, but no location or timezone\n> information at the moment.\n> \n> Thanks for a well run election! See you in Brussels, perhaps?\n> \n> Regards,\n> Dave.\n> \n> \n> On 01/18/2013 06:28 PM, Jonathan Bryce wrote:\n>> Hello everyone,\n>>\n>> The 2013 election of Individual Directors has closed. Preliminary results are\n>> available at the following link:\n>>\n>> https://www.bigpulse.com/pollresults?code=2888d7aPUFe5Euveb5kiYNGT\n>>\n>> These are the raw voting results and are now being reviewed by our election\n>> inspectors. The elected and appointed directors will be seated at 9:00am PDT on\n>> January 31st\n>> (http://wiki.openstack.org/Governance/Foundation/31Jan2013BoardMeeting).\n>>\n>> Also, the Bylaws amendment was overwhelmingly approved by the Individual\n>> Members.\n>>\n>> Thank you to everyone who participated in this year\'s Individual Director\n>> election.\n>>\n>> Jonathan\n>> 210-317-2438\n>>\n>>\n>> Preliminary Individual Directors\n>> -------------------------------------------\n>> Tim Bell\n>> Hui Cheng\n>> Tristan Goode\n>> Rob Hirschfeld\n>> Mark McLoughlin\n>> Lauren Sell\n>> Monty Taylor\n>> Troy Toman\n>>\n>> Platinum Directors\n>> -----------------------------------------\n>> Alan Clark\n>> Jim Curry\n>> Eileen Evans\n>> Toby Ford\n>> Kyle MacDonald\n>> Jon Mittelhauser\n>> Todd Moore\n>> Brian Stevens\n>>\n>> Gold Directors\n>> ------------------------------------------\n>> Simon Anderson\n>> Nick Barcet\n>> Randy Bias\n>> John Igoe\n>> Joshua McKenty\n>> Boris Renski\n>> Sean Roberts\n>> Lew Tucker\n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>\n> \n> --\n> Dave Neary - Community Action and Impact\n> Open Source and Standards, Red Hat - http://community.redhat.com\n> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n\n\n\n\n','<50F987A8.3030807@redhat.com>',NULL),('<1358587470.4065.36.camel@varinia.lobefin.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-19 09:24:30',0,'2013-01-19 09:24:30',NULL,'[openstack-dev] Potential change to provide a configurable list\n of nwfilters','Hi,\n\nOn Thu, 2013-01-17 at 16:46 +0000, Bak, Ed (HPCS Fort Collins) wrote:\n> Hi,\n> \n>  \n> \n> We have a need to add additional network filters to the nova-base\n> filter list.  For one additional case, we would also like to add an\n> additional filter to specific instances.  I would like to propose a\n> change to nova/virt/libvirt/firewall.py.  I?m thinking that these\n> custom network filter definitions could be defined in individual files\n> and the use of the filters could be controlled through nova.conf.  As\n> a proof a concept,  I added some code to\n> NWFilterFirewall:setup_basic_filtering which reads the list of custom\n> filters as defined in nova.conf and sets up the filters depending on\n> the filter definition.  Each filter definition requires 3 functions:  \n\nI\'ve run into a similar situation in the past, but only for one instance\nor image.  I\'d prefer if this could somehow be implemented as a property\nof the image/instance/something, rather than as a global setting in a\nconfig file.  It looks like your apply_filter returning False does\nsomething like this?  I\'m probably pre-coffee, but it wasn\'t clear to\nme.\n\nCheers,\n-- \nStephen Gran\nSenior Systems Integrator - guardian.co.uk\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit guardian.co.uk - website of the year\n \nwww.guardian.co.uk    www.observer.co.uk     www.guardiannews.com \n \nOn your mobile, visit m.guardian.co.uk or download the Guardian\niPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad \n \nSave up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. \nVisit guardian.co.uk/subscribe\n \n---------------------------------------------------------------------\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n\n\n','<F7520559978BFD47A3B64F85745A13B9145B2186@G5W2714.americas.hpqcorp.net>',NULL),('<1358769446.6965766.1372103203134.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 12:46:43',-25200,'2013-06-24 19:46:43',NULL,'[openstack-dev]  [vmware] VMwareAPI sub-team status update','Greetings Stackers!\n\nThis is the Monday update. Looks like we had a few rebases that failed. The developers involved are working on them as you read this and will be posting new versions as soon as they can. This kind of thing happens when a patch takes too long to review and the code base shifts around the patch enough to cause merge conflicts. Let\'s try and be vigilant, porting forward our patches as the code shifts... and getting through reviews faster in general.\n\nFirst up, posted reviews and their statuses...\n\nReady for core review:\n* https://review.openstack.org/#/c/30822/\n* https://review.openstack.org/#/c/33482/\n* https://review.openstack.org/#/c/27885/\n\nAccepted since Friday:\n* https://review.openstack.org/#/c/29396/\n\nNeeds VMwareAPI expert\'s attention:\nIf you know VMware\'s API\'s please take some time with these so we can pass them on to the core-reviewers.\n* https://review.openstack.org/#/c/29453/\n* https://review.openstack.org/#/c/30282/\n* https://review.openstack.org/#/c/30289/\n* https://review.openstack.org/#/c/32695/\n* https://review.openstack.org/#/c/33100/\n\nWork In Progress (not ready for general review):\n* https://review.openstack.org/#/c/30036/ <- (failed rebase)\n* https://review.openstack.org/#/c/30628/ <- needs traversal spec work & API expert participation\n* https://review.openstack.org/#/c/33088/ <- needs more discussion\n* https://review.openstack.org/#/c/33504/ <- needs more discussion\n\nCritical/High priority bugs open now:\n* https://bugs.launchpad.net/nova/+bug/1184807\n* https://bugs.launchpad.net/nova/+bug/1192192\n* https://bugs.launchpad.net/nova/+bug/1180471\n* https://bugs.launchpad.net/nova/+bug/1180897\n* https://bugs.launchpad.net/nova/+bug/1190515\n\nBugs needing confirmation / triage work:\n* https://bugs.launchpad.net/nova/+bug/1193980\n* https://bugs.launchpad.net/nova/+bug/1194018\n* https://bugs.launchpad.net/nova/+bug/1194076\n\nWeekly Meeting info:\n* https://wiki.openstack.org/wiki/Meetings/VMwareAPI\n\n# Shawn Hartsock - VMware\'s Nova Compute driver maintainer guy\n\n\n','<622443024.5390033.1371832995689.JavaMail.root@vmware.com>',NULL),('<1358794985.465312985@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-01-21 13:03:05',-21600,'2013-01-21 19:03:05',NULL,'[OpenStack Foundation] 2013 Board of Directors','Thanks Lisa & Vincent for your work on this!\n\nMark\n\n\nOn Monday, January 21, 2013 12:58pm, \"Lisa Miller\" <lisa at lsmillerlaw.com> said:\n\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> Dear Foundation Members,\n> \n> The election inspectors have reviewed the individual director election results and\n> are pleased to confirm the list of Preliminary Individual Directors and formally\n> announce the final slate of Individual Directors:\n> \n> Tim Bell\n> Hui Cheng\n> Tristan Goode\n> Rob Hirschfeld\n> Mark McLoughlin\n> Lauren Sell\n> Monty Taylor\n> Troy Toman\n> \n> The full slate of the 2013 OpenStack Foundation Board of Directors is as follows:\n> \n> Simon Anderson\n> Nick Barcet\n> Tim Bell\n> Randy Bias\n> Alan Clark\n> Jim Curry\n> Hui Cheng\n> Eileen Evans\n> Toby Ford\n> Tristan Goode\n> Rob Hirschfeld\n> John Igoe\n> Kyle MacDonald\n> Joshua McKenty\n> Mark McLoughlin\n> Jon Mittelhauser\n> Todd Moore\n> Boris Renski\n> Sean Roberts\n> Lauren Sell\n> Brian Stevens\n> Monty Taylor\n> Troy Toman\n> Lew Tucker\n> \n> Congratulations to all the new and returning directors!  The board of directors\n> will hold its first meeting via telephone conference on January 31, 2013.  Thank\n> you to everyone who participated in the election process.  We are looking forward\n> to an exciting year for the Foundation!  If you have any questions about this\n> year\'s elections please feel free to contact us at\n> electioninspectors at openstack.org<mailto:electioninspectors at openstack.org>.\n> \n> Best regards,\n> \n> Vincent Untz and Lisa Miller\n> 2013 OpenStack Foundation Election Inspectors\n> \n> Lisa S. Miller\n> ________________________________\n> Law Office of Lisa S. Miller, PLLC\n> Phone: (210) 296-6991 Fax: (210) 828-5330\n> 6338 N. New Braunfels, #191, San Antonio, Texas 78209\n> ________________________________\n> \n> The information contained in this e-mail message may be privileged, confidential\n> and protected from disclosure, and no waiver of any attorney-client, work product\n> or other privilege is intended. If you are not the intended recipient, any\n> dissemination, distribution or copying is strictly prohibited. If you think that\n> you have received this e-mail message in error, please e-mail the sender and\n> delete all copies.\n> \n\n\n\n\n','<CD22EA37.7B16%lisa@lsmillerlaw.com>',NULL),('<1358804095.2311.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-21 21:34:55',0,'2013-01-21 21:34:55',NULL,'[openstack-dev] [CI] Recheck/reverify syntax changing','On Wed, 2013-01-16 at 10:54 -0800, James E. Blair wrote:\n> Every time a recheck/reverify comment is left with a bug number\n> attached, this page:\n> \n>   http://status.openstack.org/rechecks/\n> \n> will update.  It includes information such as when the bug was first and\n> most recently seen, how many times it has prompted someone to recheck a\n> change, what projects it has affected, and what changes in Gerrit it has\n> affected. \n\nYou know what? This is just awesome.\n\nThank you,\nMark.\n\n\n\n','<87d2x5dklv.fsf@meyer.lemoncheese.net>',NULL),('<1358847305.2453.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-22 09:35:05',0,'2013-01-22 09:35:05',NULL,'[openstack-dev] How to get back the helpful verbose unit test\n display in Nova','On Mon, 2013-01-21 at 18:54 -0500, Monty Taylor wrote:\n> a) run_tests.sh is missing the \"slowest X tests\" output. Sorry, we\n> missed that, I think because we all use tox directly. Clark is working\n> on adding that back real quick \n\nHmm, just to be sure there isn\'t a misunderstanding - I think what Dan\nwas asking for (and what I\'ve felt is missing too) is simply some\nindication that stuff is happening.\n\nFor it to just sit there outputting nothing for a long time is pretty\ndisconcerting.\n\nMaybe we\'re just missing some obvious feature?\n\nCheers,\nMark.\n\n\n\n','<50FDD521.2090309@inaugust.com>',NULL),('<1358868763.2453.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-22 15:32:43',0,'2013-01-22 15:32:43',NULL,'[Openstack-stable-maint] 2012.2.3 status','Hey\n\n2012.2.3 is scheduled for January 31st. I\'m planning on calling whatever\nwe have on January 25th a RC and getting aggressive about punting\nanything risky until the next release.\n\nA summary of the status of each project is below.\n\nQuantum and Nova have obviously had the most activity, but also have a\nbunch of bugs tagged as potential for backporting. Vish has done a\nparticularly great job of tagging bugs which look like they might be\ngood for backporting.\n\nSo, if folks have some time this week, the best thing to do for each\nproject is to look for serious issues which haven\'t been tagged with\nfolsom-backport-candidate or consider proposing backported patches for\nany tagged bugs.\n\nThanks,\nMark.\n\nNova:\n  - 11 bugs fixed\n  - 5 InProgress\n  - 1 review open, needs another +2\n  - 29 tagged with folsom-backport-potential\n\nGlance:\n  - 3 bugs fixed\n  - nothing in the backport or review queue\n\nKeystone:\n  - 4 bugs fixed\n  - nothing in the backport or review queue\n\nQuantum:\n  - 16 bugs fixed\n  - 8 others marked with folsom-backport-potential\n  - nothing in the review queue\n\nCinder:\n  - 1 bug fixed\n  - 1 bug InProgress\n\nHorizon:\n  - 6 bugs fixed\n  - 2 marked with folsom-backport-potential\n\n\n\n\n',NULL,NULL),('<1358897366.242132244@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-22 18:29:26',-18000,'2013-01-22 23:29:26',NULL,'[openstack-dev] swift client for Xen on dom0','Hi,\n\nWe have a review patch in Nova https://review.openstack.org/#/c/17803/, which is making us contemplate on the best possible way to communicate with swift from the dom0. The two  options mentioned below have pros and cons:-\n\n1. either emulate swift client\n2. or install python-swiftclient on dom0\n\nOn trying out both on them, we have realized some pain points involved in deployment and maintenance process. Also, as John has correctly pointed out in the review, we need to keep in mind about having the same code in 2 different places, especially for security fixes.\n\nYour opinions and comments would be greatly appreciated and we wish to discuss about this in the XenAPI IRC meeting on Wednesday Jan 23rd as well.\n\nthanks,\n-Nikhil\n\n\n\n',NULL,NULL),('<1358952525.2468.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-01-23 14:48:45',0,'2013-01-23 14:48:45',NULL,'[openstack-tc] H naming poll','On Wed, 2013-01-23 at 15:22 +0100, Thierry Carrez wrote:\n> Hi,\n> \n> The H naming public poll is setup[1] and ready to open tomorrow\n\nCool :)\n\n> (Launchpad asks for a delay of one day between creation of poll and\n> opening of poll, don\'t ask), with the following preselected options\n> (thanks to our internal CIVS poll):\n> \n> * Hood\n> * Havana\n> * Harbor\n> * Hatfield\n\nEveryone from outside the US should lobby aggressively against Harbor\nsince the correct spelling is \'Harbour\' :)\n\nCheers,\nMark.\n\n\n\n','<50FFF21C.2030204@openstack.org>',NULL),('<1358954676.315317912@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 10:24:36',-18000,'2013-01-23 15:24:36',NULL,'[openstack-dev] swift client for Xen on dom0','\nHey Chmouel,\n \nThanks for your comments! Please find some answers to your concerns below.\n\nActually, there already is an emulated swift-client in the patch (https://review.openstack.org/#/c/17803/10/plugins/xenserver/xenapi/etc/xapi.d/plugins/swift_client.py). Though, we would like to keep it trimmed to meet just about the current requirements. \n\nInitially, we preferred having python-swiftclient on dom0 and found that there are following roadblocks:\n\n\nhaving to deploy updated swift client on dom0\nit adds another package on dom0 (making the Ops guys nervous)\nauth v2 for swift needs keystone client which would have to be added there as well\nwe need to meet the dependencies if they change in the future\nkeeping up with swift client instead of the dedicated code for nova-swift communication\nagreed that cut paste code is more susceptible to security fixes\nhowever, this way the entire service would be vulnerable if there is some change in swift-client and nova-swift communication is not updated accordingly\nWe would like to be there at the Swift meeting today (Wed 23rd), if you think it would be essential.\n \nthanks,\n-Nikhil\n\n-----Original Message-----\nFrom: \"Chmouel Boudjnah\" <chmouel at chmouel.com>\nSent: Wednesday, January 23, 2013 7:00am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] swift client for Xen on dom0\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi Nikhil,\n\nI would definitively go for options 2 having to redo a swiftclient would\nnot be very useful. What are the pain point about option 2?\n\nWe have as well a Swift meeting tonight (Wed/23) if you want to come talk\nwith the swift core about it.\n\nRegards,\nChmouel.\n\n\nOn Wed, Jan 23, 2013 at 12:29 AM, Nikhil Komawar <\nnikhil.komawar at rackspace.com> wrote:\n\n> Hi,\n>\n> We have a review patch in Nova https://review.openstack.org/#/c/17803/,\n> which is making us contemplate on the best possible way to communicate with\n> swift from the dom0. The two  options mentioned below have pros and cons:-\n>\n> 1. either emulate swift client\n> 2. or install python-swiftclient on dom0\n>\n> On trying out both on them, we have realized some pain points involved in\n> deployment and maintenance process. Also, as John has correctly pointed out\n> in the review, we need to keep in mind about having the same code in 2\n> different places, especially for security fixes.\n>\n> Your opinions and comments would be greatly appreciated and we wish to\n> discuss about this in the XenAPI IRC meeting on Wednesday Jan 23rd as well.\n>\n> thanks,\n> -Nikhil\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/28e77c7c/attachment.html>\n\n','<CAPeWyqyHKhU4as_84_uy_VX+ZJ4XnawTqXyV2R6R97YFq01noA@mail.gmail.com>',NULL),('<1358957234.2468.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 16:07:14',0,'2013-01-23 16:07:14',NULL,'[openstack-dev] Packaging pain tales','On Wed, 2013-01-23 at 16:22 +0100, Sascha Peilicke wrote:\n> A while ago, we were even able\n> to use daily git checkouts for package building but for reasons\n> described in [1][2], we had to move away from git checkouts. \n\nCan you look at this again and describe why you can\'t go back to using\ngit checkouts?\n\nThanks,\nMark.\n\n\n\n','<51000044.20902@suse.de>',NULL),('<1358977336.63331777.1379623165377.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-19 13:39:25',-25200,'2013-09-19 20:39:25',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews update\n 2013-09-19','Greetings stackers!\n\nA quick mid-week update on the patches we\'re tracking for Havana-rc1. There was a bug in my vote counting code that I use to query votes. Some of the older patches were getting their votes counted wrong. Tracking the \"age\" of a submitted patchset (number of days since a patchset was posted) and the revision number helps spot these problems. I try to validate these reports by hand, but I do miss things on occasion. Let me know if I need to add or edit something.\n\nOrdered by priority:\n* High/Critical https://bugs.launchpad.net/bugs/1223709 https://review.openstack.org/46027 readiness:ready for core\n* High/Critical https://bugs.launchpad.net/bugs/1216510 https://review.openstack.org/43616 readiness:needs one more +2/approval\n* High/Critical https://bugs.launchpad.net/bugs/1226211 https://review.openstack.org/46789 readiness:ready for core\n* High/Critical https://bugs.launchpad.net/bugs/1217541 https://review.openstack.org/43621 readiness:needs review\n* High/High https://bugs.launchpad.net/bugs/1187853 https://review.openstack.org/45349 readiness:ready for core\n* Medium/High https://bugs.launchpad.net/bugs/1190515 https://review.openstack.org/33100 readiness:ready for core\n* High https://bugs.launchpad.net/bugs/1184807 https://review.openstack.org/40298 readiness:ready for core\n* High https://bugs.launchpad.net/bugs/1214850 https://review.openstack.org/43270 readiness:needs review\n* High https://bugs.launchpad.net/bugs/1226052 https://review.openstack.org/46730 readiness:needs review\n* High https://bugs.launchpad.net/bugs/1226826 https://review.openstack.org/47030 readiness:needs review\n* High https://bugs.launchpad.net/bugs/1225002 https://review.openstack.org/41977 readiness:ready for core\n* High https://bugs.launchpad.net/bugs/1194018 https://review.openstack.org/43641 readiness:ready for core\n* High https://bugs.launchpad.net/bugs/1171226 https://review.openstack.org/43994 readiness:ready for core\n* Medium https://bugs.launchpad.net/bugs/1183654 https://review.openstack.org/45203 readiness:needs revision\n* Medium https://bugs.launchpad.net/bugs/1223074 https://review.openstack.org/45864 readiness:needs review\n* Medium https://bugs.launchpad.net/bugs/1199954 https://review.openstack.org/46231 readiness:needs review\n* Medium https://bugs.launchpad.net/bugs/1222349 https://review.openstack.org/45570 readiness:needs one more +2/approval\n* Medium https://bugs.launchpad.net/bugs/1216961 https://review.openstack.org/43721 readiness:needs one more +2/approval\n* Medium https://bugs.launchpad.net/bugs/1215352 https://review.openstack.org/43268 readiness:needs one more +2/approval\n* Medium https://bugs.launchpad.net/bugs/1197041 https://review.openstack.org/43621 readiness:needs review\n* Medium https://bugs.launchpad.net/bugs/1222948 https://review.openstack.org/46400 readiness:needs revision\n* Medium https://bugs.launchpad.net/bugs/1226238 https://review.openstack.org/46824 readiness:needs review\n* Medium https://bugs.launchpad.net/bugs/1224479 https://review.openstack.org/46277 readiness:ready for core\n* Medium https://bugs.launchpad.net/bugs/1207064 https://review.openstack.org/42024 readiness:needs revision\n* Medium https://bugs.launchpad.net/bugs/1180044 https://review.openstack.org/43270 readiness:needs review\n* Medium https://bugs.launchpad.net/bugs/1226425 https://review.openstack.org/46895 readiness:needs revision\n* Low https://bugs.launchpad.net/bugs/1215958 https://review.openstack.org/43665 readiness:needs review\n* Low https://bugs.launchpad.net/bugs/1226450 https://review.openstack.org/46896 readiness:ready for core\n\n--------------------------------------------------------------------------------\nOrdered by fitness for review:\n\n== needs one more +2/approval ==\n* Medium https://bugs.launchpad.net/bugs/1222349 review: https://review.openstack.org/45570\n	title: \'VMware: datastore_regex is not honoured\'\n	votes: +2:1, +1:5, -1:0, -2:0  age: 11 days revision: 4\n* Medium https://bugs.launchpad.net/bugs/1216961 review: https://review.openstack.org/43721\n	title: \'VMware: exceptions for RetrievePropertiesEx incorrectly handled\'\n	votes: +2:1, +1:5, -1:0, -2:0  age: 1 days revision: 2\n* Medium https://bugs.launchpad.net/bugs/1215352 review: https://review.openstack.org/43268\n	title: \'VMware: unable to access VNC console if password is not configured\'\n	votes: +2:1, +1:3, -1:0, -2:0  age: 1 days revision: 12\n* High/Critical https://bugs.launchpad.net/bugs/1216510 review: https://review.openstack.org/43616\n	title: \'VMware: exception when accessing invalid nodename\'\n	votes: +2:1, +1:5, -1:0, -2:0  age: 3 days revision: 8\n\n== ready for core ==\n* High/Critical https://bugs.launchpad.net/bugs/1223709 review: https://review.openstack.org/46027\n	title: \'VMware: boot from volume exception\'\n	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 3\n* High https://bugs.launchpad.net/bugs/1184807 review: https://review.openstack.org/40298\n	title: \'Snapshot failure with VMwareVCDriver\'\n	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 18\n* High https://bugs.launchpad.net/bugs/1225002 review: https://review.openstack.org/41977\n	title: \'VMware: no VM connectivity when opaque network does not match bridge id\'\n	votes: +2:0, +1:5, -1:0, -2:0  age: 4 days revision: 5\n* Low https://bugs.launchpad.net/bugs/1226450 review: https://review.openstack.org/46896\n	title: \'no image cache tests for VMware Hyper\'\n	votes: +2:0, +1:4, -1:0, -2:0  age: 2 days revision: 1\n* Medium https://bugs.launchpad.net/bugs/1224479 review: https://review.openstack.org/46277\n	title: \'[vmware] InvalidURL nonnumeric port in read_write_ util with ipv6 host\'\n	votes: +2:0, +1:4, -1:0, -2:0  age: 7 days revision: 5\n* Medium/High https://bugs.launchpad.net/bugs/1190515 review: https://review.openstack.org/33100\n	title: \'Incorrect host stats reported by VMWare VCDriver\'\n	votes: +2:0, +1:7, -1:0, -2:0  age: 1 days revision: 19\n* High https://bugs.launchpad.net/bugs/1194018 review: https://review.openstack.org/43641\n	title: \'Can\'t use vmware distributed virtual switch with nova\'\n	votes: +2:0, +1:5, -1:0, -2:0  age: 25 days revision: 14\n* High/Critical https://bugs.launchpad.net/bugs/1226211 review: https://review.openstack.org/46789\n	title: \'VMware: some API\'s return only data on the first cluster and not the correct cluster\'\n	votes: +2:0, +1:7, -1:0, -2:0  age: 3 days revision: 1\n* High https://bugs.launchpad.net/bugs/1171226 review: https://review.openstack.org/43994\n	title: \'VMwareVCDriver: Sparse disk copy error on spawn\'\n	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 18\n* High/High https://bugs.launchpad.net/bugs/1187853 review: https://review.openstack.org/45349\n	title: \'VMWAREAPI: Problem with starting Windows instances on ESXi 5.1\'\n	votes: +2:0, +1:6, -1:0, -2:0  age: 14 days revision: 9\n\n== needs review ==\n* Medium https://bugs.launchpad.net/bugs/1223074 review: https://review.openstack.org/45864\n	title: \'vsphere: Instance with volume attachment stuck with DELETING status\'\n	votes: +2:0, +1:4, -1:0, -2:0  age: 1 days revision: 4\n* Medium https://bugs.launchpad.net/bugs/1199954 review: https://review.openstack.org/46231\n	title: \'VCDriver: Failed to resize instance\'\n	votes: +2:0, +1:3, -1:0, -2:0  age: 2 days revision: 6\n* Low https://bugs.launchpad.net/bugs/1215958 review: https://review.openstack.org/43665\n	title: \'vim_util get_dynamic_property propSet need not be set - makes vmware driver hard to diagnose\'\n	votes: +2:0, +1:3, -1:0, -2:0  age: 11 days revision: 5\n* High https://bugs.launchpad.net/bugs/1214850 review: https://review.openstack.org/43270\n	title: \'vmware driver selection of vm_folder_ref does not account for datastore\'\n	votes: +2:0, +1:1, -1:0, -2:0  age: 28 days revision: 1\n* Medium https://bugs.launchpad.net/bugs/1197041 review: https://review.openstack.org/43621\n	title: \'nova compute crashes if you do not have any hosts in your cluster\'\n	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 5\n* High https://bugs.launchpad.net/bugs/1226052 review: https://review.openstack.org/46730\n	title: \'VMware: VM creation ignores the size of the flavor root disk\'\n	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 7\n* Medium https://bugs.launchpad.net/bugs/1226238 review: https://review.openstack.org/46824\n	title: \'VMware Driver reports SwitchNotFound when network already exists\'\n	votes: +2:0, +1:3, -1:0, -2:0  age: 3 days revision: 1\n* High https://bugs.launchpad.net/bugs/1226826 review: https://review.openstack.org/47030\n	title: \'VMwareVCDriver: detaching volume  fails with TypeError\'\n	votes: +2:0, +1:4, -1:0, -2:0  age: 1 days revision: 2\n* Medium https://bugs.launchpad.net/bugs/1180044 review: https://review.openstack.org/43270\n	title: \'nova failures when vCenter has multiple datacenters\'\n	votes: +2:0, +1:1, -1:0, -2:0  age: 28 days revision: 1\n* High/Critical https://bugs.launchpad.net/bugs/1217541 review: https://review.openstack.org/43621\n	title: \'vmwareapi drivers - most summary fields need not be set\'\n	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 5\n\n== needs revision ==\n* Medium https://bugs.launchpad.net/bugs/1183654 review: https://review.openstack.org/45203\n	title: \'vmware code is using deprecated API that may not handle inventories over 100 items properly\'\n	votes: +2:0, +1:1, -1:1, -2:0  age: 14 days revision: 2\n* Medium https://bugs.launchpad.net/bugs/1222948 review: https://review.openstack.org/46400\n	title: \'VMware: booting multiple instances fails if image is not in cache\'\n	votes: +2:0, +1:1, -1:2, -2:0  age: 7 days revision: 6\n* Medium https://bugs.launchpad.net/bugs/1207064 review: https://review.openstack.org/42024\n	title: \'VMWare : Disabling linked clone does not cache images on the datastore\'\n	votes: +2:0, +1:1, -1:3, -2:0  age: 1 days revision: 11\n* Medium https://bugs.launchpad.net/bugs/1226425 review: https://review.openstack.org/46895\n	title: \'Problem specifying VMware network name in FlatNetworking\'\n	votes: +2:0, +1:2, -1:1, -2:0  age: 2 days revision: 3\n\n# Shawn Hartsock\n\n\n','<246654613.63313760.1379622356017.JavaMail.root@vmware.com>',NULL),('<1358977562.3006.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 21:46:02',0,'2013-01-23 21:46:02',NULL,'[openstack-dev] Packaging pain tales','On Wed, 2013-01-23 at 17:28 +0100, Ionu? Ar??ri?i wrote:\n> On 01/23/2013 05:07 PM, Mark McLoughlin wrote:\n> > On Wed, 2013-01-23 at 16:22 +0100, Sascha Peilicke wrote:\n> >> A while ago, we were even able\n> >> to use daily git checkouts for package building but for reasons\n> >> described in [1][2], we had to move away from git checkouts.\n> > Can you look at this again and describe why you can\'t go back to using\n> > git checkouts?\n> >\n> >\n> We\'ve discussed that before in the mailing list thread that Sascha \n> mentioned in his email. We can\'t use git checkouts because it would mean \n> distributing the whole .git repository in our srpms in order to run the \n> python setup.py sdist command with setuptools_git.\n\nThere are basically two options now if you want to build  package from a\ngiven git commit and include information about the commit in the package\nversion:\n\n  - build a tarball using \'python setup.py sdist\' and build your RPM \n    using that - the commit id is included in the tarball name, \n    toplevel directory name and PKG-INFO file\n\n  - if you take a git checkout and remove it\'s .git dir, you need to \n    record the git commit id, construct a version number with it and \n    pass it via the OSLO_PACKAGE_VERSION env variable\n\nCheers,\nMark.\n\n\n\n','<51000FB8.6030806@suse.cz>',NULL),('<1359024352.2347.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-24 10:45:52',0,'2013-01-24 10:45:52',NULL,'[openstack-dev] Motion on Technical Committee membership for\n Spring 2013 session','On Thu, 2013-01-24 at 11:28 +0100, Thierry Carrez wrote:\n> Hi,\n> \n> Following the discussion at [1], option (3) appears to have supporters,\n> no strong opposition or amendments proposed. No alternate option was\n> fully detailed, and we need to come to a decision ASAP in order to set\n> the agenda for the upcoming Spring 2013 elections.\n> \n> I therefore propose the following special motion for voting at the next\n> Technical Committee meeting. The business summary is that all TC members\n> would be directly-elected\n\nI think this is a really positive step forward.\n\n> , and all elections (PTLs and TC) would happen\n> at the same time, with 10 members being elected at the Spring 2013\n> election. If you have comments, please reply to openstack-dev for public\n> discussion.\n> \n> \"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n> 1. Amend the \"TC Members\" section of the Technical Committee Charter[2]\n> like this:\n> \n> =TC Members=\n> The TC is composed of *13 directly-elected members*. It is partially\n> renewed using elections every 6 months. All TC members must be OpenStack\n> Foundation individual members. You can cumulate any other role,\n> including Foundation Director, with a TC seat.\n> \n> 2. Amend the \"Election for PTL seats\" section like this:\n> \n> =Election for PTL seats=\n> PTL seats are completely renewed every 6 months. A separate election is\n> run for each core project and each library project that has its own PTL.\n> These elections are collectively held *4* weeks prior to each design\n> summit, with nominations due *5* weeks prior to the summit and elections\n> held open for no less than five business days.\n\nContinuing to refer to PTL \"seats\" is a bit strange - how about\ns/seats/positions/ ?\n\ni.e. the PTL role is a position within the project, not a seat on the TC\n\n> 3.Amend the \"Election for extra TC seats\" section like this:\n> \n> =Election for *TC seats*=\n> The *13 TC seats* are partially renewed every 6 months using staggered\n> elections: *7* seats are renewed every Fall, and *6* seats are renewed\n> every Spring. For this election we\'ll use a multiple-winner election\n> system (see below). The election is held *4* weeks prior to each design\n> summit, with nominations due *5* weeks prior to the summit and elections\n> held open for no less than five business days.\n> \n> 4. For the Spring 2013 elections, we\'ll exceptionally elect 10 members.\n> The first 6 will be granted a one-year term, while the next 4 will be\n> granted a 6-month term.\n> \"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\"\n> \n> Note that according to our Charter[2] special motions need the\n> affirmative vote of at least *two-thirds* of the total number of TC\n> members (that means: more \"YES\" than \"NO\" votes, and at least 9 \"YES\").\n> If the special motion doesn\'t pass, the status quo is preserved, which\n> means if new core/integrated projects get added, their PTLs will\n> automatically get TC seats and increase the committee size above 13.\n\nThis is an important point - we have projects graduating from incubation\nsoon and we\'re trying to both avoid the TC size growing and avoid a\nproject failing to graduate because the TC didn\'t want to add another\nPTL to the TC.\n\nCheers,\nMark.\n\n\n\n','<51010CD4.30703@openstack.org>',NULL),('<1359065328.201419330@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-24 17:08:48',-18000,'2013-01-24 22:08:48',NULL,'[openstack-dev] swift client for Xen on dom0','\nHi John,\n \nIts great to hear that you got this working. Yum was not working for us after having installed python26, however will give it a try this way. This definitely completes the action item of the meeting.\n \nHowever, we are looking for a more friendly solution to the automated deployment process, to the very least trying to avoid a flaky yum (which you mentioned to have observed in this process). Until we all find a cleaner way out, we\'r going to work on submitting a minimal necessary patch for review which does not hurt the OpenStack code and community in general.\n \nThanks for your help and time!\n-Nikhil\n\n-----Original Message-----\nFrom: \"John Garbutt\" <John.Garbutt at citrix.com>\nSent: Thursday, January 24, 2013 11:58am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nCc: \"Nikhil Komawar\" <nikhil.komawar at rackspace.com>\nSubject: RE: [openstack-dev] swift client for Xen on dom0\n\n\n\n\nHi Nikhil,\n \nI have just had a quick look at installing python-swiftclient and python-keystoneclient into XenServer/XCP?s Dom0.\n \nIt seems to have installed OK by following these steps: [http://wiki.openstack.org/XenServer/PostInstall#Install_Python_2.6_in_Dom0] http://wiki.openstack.org/XenServer/PostInstall#Install_Python_2.6_in_Dom0\n \nIn the XenAPI meeting you said there were some issues with yum after installing python 2.6. I managed to reproduce issues doing ?yum upgrade?. It was getting very confused with package differences between the EPEL and Citrix repositories (gdisk in particular). I managed to ?fix? this by removing the EPEL repo once I installed python2.6 and easy-install-2.6\n \nDoes that sound OK?\nWere there any other issues blocking you going for (2)?\n \nJohn \n \n\n\n\nFrom: Chmouel Boudjnah [mailto:chmouel at chmouel.com] \nSent: 23 January 2013 12:00\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] swift client for Xen on dom0\n \n\n\n\nHi Nikhil,\nI would definitively go for options 2 having to redo a swiftclient would not be very useful. What are the pain point about option 2?\n\nWe have as well a Swift meeting tonight (Wed/23) if you want to come talk with the swift core about it.\n\n \nRegards,\nChmouel.\n\n \n\nOn Wed, Jan 23, 2013 at 12:29 AM, Nikhil Komawar <[mailto:nikhil.komawar at rackspace.com] nikhil.komawar at rackspace.com> wrote:\nHi,\n\nWe have a review patch in Nova [https://review.openstack.org/#/c/17803/] https://review.openstack.org/#/c/17803/, which is making us contemplate on the best possible way to communicate with swift from the dom0. The two  options mentioned below have pros and cons:-\n\n1. either emulate swift client\n2. or install python-swiftclient on dom0\n\nOn trying out both on them, we have realized some pain points involved in deployment and maintenance process. Also, as John has correctly pointed out in the review, we need to keep in mind about having the same code in 2 different places, especially for security fixes.\n\nYour opinions and comments would be greatly appreciated and we wish to discuss about this in the XenAPI IRC meeting on Wednesday Jan 23rd as well.\n\nthanks,\n-Nikhil\n\n\n_______________________________________________\nOpenStack-dev mailing list\n[mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n[http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130124/39099b73/attachment.html>\n\n','<FFDB98DC9661D3418B9EB0FF5202E46B0111BAB36CF4@LONPMAILBOX01.citrite.net>',NULL),('<1359119582.2392.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-25 13:13:02',0,'2013-01-25 13:13:02',NULL,'[openstack-dev] Call for testing: 2012.2.3 candidate tarballs','Hey,\n\nWe are scheduled to publish Nova, Glance, Keystone, Quantum, Cinder and\nHorizon 2012.2.3 releases next Thursday (Jan 31).\n\nThe list of issues fixed so far can be seen here:\n\n  https://launchpad.net/nova/+milestone/2012.2.3\n  https://launchpad.net/glance/+milestone/2012.2.3\n  https://launchpad.net/keystone/+milestone/2012.2.3\n  https://launchpad.net/quantum/+milestone/2012.2.3\n  https://launchpad.net/cinder/+milestone/2012.2.3\n  https://launchpad.net/horizon/+milestone/2012.2.3\n\nThat\'s over 40 bugs.\n\nWe\'d appreciate anyone who could give the candidate 2012.2.3 tarballs a\nwhirl:\n\n  http://tarballs.openstack.org/nova/nova-stable-folsom.tar.gz\n  http://tarballs.openstack.org/glance/glance-stable-folsom.tar.gz\n  http://tarballs.openstack.org/keystone/keystone-stable-folsom.tar.gz\n  http://tarballs.openstack.org/quantum/quantum-stable-folsom.tar.gz\n  http://tarballs.openstack.org/cinder/cinder-stable-folsom.tar.gz\n  http://tarballs.openstack.org/horizon/horizon-stable-folsom.tar.gz\n\nThanks!\nMark.\n\n\n\n',NULL,NULL),('<1359121517.2392.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-25 13:45:17',0,'2013-01-25 13:45:17',NULL,'[openstack-dev] Need for a String Freeze for\n documenters/translators','On Fri, 2013-01-25 at 14:28 +0100, Thierry Carrez wrote:\n> Hi everyone,\n> \n> At the last design summit we discussed the need for introducing a String\n> Freeze in our development cycle. It was decided to propose it in time on\n> the ML, so here it goes.\n> \n> A String Freeze is a deadline for submitting changes that affect\n> translatable strings (log messages) or documentation (think config\n> option names, user-visible changes).\n> \n> Under String Freeze, changing those requires an exception process (tbd)\n> that involves properly warning documenters and translators about it, and\n> making sure the change is worth the extra hassle imposed on them.\n> \n> Is it a good idea ? Is it solving a real problem ? Should it happen at\n> the same time a FeatureFreeze (February 19), or slightly afterwards\n> (like March 5, one month before final release) ?\n\nI agree with it in principal. I think complete translations are\nimportant and the only way to achieve that at release time is to stop\nchanging them soon enough to give translators a reasonable chance to do\ntheir thing.\n\nBut I\'m not convinced we\'re yet a point where our translations are\nuseful. The fact that we include all log messages implies to me that\nwe\'re unlikely to be getting remotely close to 100% translation for any\nlanguage (except maybe en_GB). Also, locking down all log messages is a\npretty invasive freeze.\n\nMaybe things are more reasonable in Horizon? e.g. do we have some\nlanguages at close to 100% there? Is it just user-visible strings marked\nfor translation there?\n\nAlso it would be great if we could have a jenkins job which would\ngenerate the .pot file and check if there have been changes rather than\nrelying on reviewers to catch the change.\n\nFinally, if there\'s a string freeze then there also needs to be a\nprocess for approving freeze breaks. Sometimes you can\'t fix a serious\nbug without changing a string and that has to be allowed.\n\nCheers,\nMark.\n\n\n\n','<51028898.1070509@openstack.org>',NULL),('<1359136809.2392.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-25 18:00:09',0,'2013-01-25 18:00:09',NULL,'[openstack-dev] oslo library version summary','On Sun, 2012-12-16 at 00:02 -0800, Monty Taylor wrote:\n> Hey all,\n> \n> ttx, markmc and I synced up on the versioning of oslo libraries, and\n> have settled on a system which is a superset of what we do with client\n> libraries - which means we can just implement an additional feature in\n> the current code and it\'ll handle both sets of things. We\'ll sync up\n> later on to discuss applicability of this to the server projects as well.\n> \n> Essentially, it breaks down like this:\n> \n> A tag to the repo will trigger tarball generation.\n> \n> If the tag contains alpha\\d*, beta\\d* or rc\\d*, the tarball will only be\n> uploaded to tarballs.openstack.org. This will allow those pre-releases\n> to be used in the other projects.\n> \n> Otherwise, the tarball will be uploaded to tarballs.o.o AND PyPI. This\n> should allow us to use released versions of oslo libraries in pip-requires.\n> \n> Turns out it\'s easy to implement:\n> \n> https://review.openstack.org/#/c/18171/\n> \n> As soon as that lands, we should be able to handle the oslo requirements.\n\nLatest oslo-config repo is here:\n\n  http://github.com/markmc/openstack-config\n\nand proposed for import here:\n\n  https://review.openstack.org/20117\n\nGiven the recent versioning changes, a tarball built from this repo\ncurrently has 2012.3.a84.gc490e35 as its version.\n\nI guess I shouldn\'t do alpha releases since that needlessly conflicts\nwith the alpha versioning scheme we use for git snapshots?\n\nSo, if/when I want to release the first beta, I do:\n\n  $> git tag -s 2012.3b1\n\nbuilding that gives:\n\n  $> python setup.py sdist\n  $> ls dist/\n  oslo-config-2012.3b1.tar.gz\n\nand pushing the tag would cause the tarball to be uploaded:\n\n  $> git push gerrit tag 2012.3b1\n\nand sometime in the future, Thierry or I would do:\n\n  $> git push gerrit tag 2012.3\n\nand that would get uploaded to PyPI.\n\nRight?\n\nThanks,\nMark.\n\n\n\n','<50CD8008.2070109@inaugust.com>',NULL),('<1359143053-sup-4436@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-25 12:08:06',-28800,'2013-01-25 20:08:06',NULL,'[openstack-dev] [heat] Future of the cfn-tools','Zane, thanks for writing this up, comments below..\n\nExcerpts from Zane Bitter\'s message of 2013-01-24 07:28:25 -0800:\n> There\'s been quite a bit of discussion recently about Heat\'s cfn-tools, \n> which currently comprise a minimalist reimplementation by the Heat \n> developers of Amazon\'s aws-cfn-bootstrap tools.\n> \n> It was also brought up on IRC last night that there has been a formal \n> request from Amazon (not yet acted upon) for Ubuntu to include \n> aws-cfn-bootstrap in the distribution.[1]\n> \n> At the same time, Fedora\'s Cloud SIG is discussing ways to make Fedora \n> Cloud images \"more awesome\".[2] Although no specifics have been \n> mentioned, packaging the aws-cfn-bootstrap tools would seem like an \n> obvious possible improvement. The Cloud SIG also has plans for Fedora 19 \n> to introduce builds that target clouds other than EC2, including \n> OpenStack.[3]\n> \n> Steve Hardy has done a lot of work on Heat to make the data that gets \n> passed to the instance as similar as possible to what gets passed by \n> CloudFormation (e.g. a reference to a WaitConditionHandle now resolves \n> to a pre-signed URL that can be used for signalling). Still, Heat is not \n> able to use the aws-cfn-bootstrap tools directly because they are \n> hard-coded with the CloudFormation endpoints. (There may be other issues \n> too, and more investigation is required.)\n> \n> However: The aws-cfn-bootstrap tools are open source, under the Apache 2 \n> license. I see little point in continuing to reimplement features \n> piecemeal as we become aware of the need for them.[4] I propose that we \n> instead take the following steps:\n> \n> * Fork the aws-cfn-bootstrap tools with the goal of creating a \n> cloud-agnostic upstream community (unaffiliated with OpenStack) around them.\n> * Modify the tools to read endpoints from a configuration file (perhaps \n> defaulting to the CloudFormation endpoints).\n> * Make any further modifications to Heat (and/or cfn-bootstrap) required \n> to implement full interoperability.\n> * Package this configurable version of aws-cfn-bootstrap for \n> Debian/Ubuntu/Fedora.\n> * Work with Ubuntu and the Fedora Cloud SIG to get this configurable \n> version included in cloud server builds.\n> \n\nThis is where \"Open Source\" can be a trap. One has to wonder what will lag\nmore, the tools or the understanding of the tools and how they\'ve changed?\n\nThere\'s a simple equation here. The right answer is whichever of the following\ntwo options is lower:\n\n* The cost of merging tools from an upstream source whose level of\ncooperation is \"unknown\".\n\n* the cost of implementing bits that users most desire plus the cost\nof not having those features.\n\nThese are hard to measure, maybe impossible. But at least the cost of\nimplementing is knowable and under complete control of the Heat project.\n\n> This would not only save us a lot of work, and likely prevent a lot of \n> bugs, but it would also offer a huge advantage to users: a single \n> prebuilt cloud image available from the distro of their choice could run \n> on both AWS and OpenStack without modification.\n> \n> There is one known issue that anybody wanting to package \n> aws-cfn-bootstrap in a distro would have to circumvent: the current \n> tools are installed (appropriately) in /opt/aws/bin. Amazon, through \n> their example templates, have encouraged people to use the \n> fully-qualified path (e.g. /opt/aws/bin/cfn-init) when calling them, \n> instead of just adding /opt/aws/bin to $PATH. The latter would have made \n> the transition to including the tools in the distro (where packaging in \n> /opt is *not* appropriate) transparent, but the former most certainly \n> does not. I have several ideas for working around this, none of them good ;)\n> \n\nThe main issue seems to be that existing CloudFormation templates will\nembed a single, predictable string in them, /opt/aws/bin.\n\nChanging images is hard, but morphing templates is easy, as we control\naccess to them whenever they enter Heat.\n\nwhat about this:\n\nheat stack-create --aws-compat my-stack-name my-cfn-template.json\n\nThis would simply look for known issues where Heat\'s implementation\ndiffers from AWS\'s, and fix them. So, it can remove /opt/aws/bin/, and\nensure that the Heat tools are in the path. The \"How\" of doing this isn\'t\nimportant... what Heat users seem to desire is using the same template\non AWS and Heat.\n\nAbsent this feature..\n\nsed -i -e \'s,/opt/aws/bin/,,\' my-cfn-template.json\n\nNot nearly as cool, but probably effective for 99% of cases if the tools\nare put into the system path.\n\nI\'d rather see the AWS compatibility be a little hacky than see Heat\nrepeat the mistakes of CloudFormation just for the sake of compatibility.\nAs Heat grows things that CloudFormation doesn\'t have, these tools will\nremain extremely useful.\n\n\n','<51015319.1050203@redhat.com>',NULL),('<1359219745.4038.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-26 17:02:25',0,'2013-01-26 17:02:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-swift-docs-stable-folsom #116','Hi James,\n\nAs best I can tell, the swift bitrot jobs shouldn\'t be running anymore\nsince:\n\n  https://review.openstack.org/18901\n\nConfused ...\n\nCheers,\nMark.\n\nOn Fri, 2013-01-25 at 00:02 +0000, OpenStack Jenkins wrote:\n> See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/116/>\n\n\n\n\n','<1522213825.326.1359072139324.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1359221329.4038.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-26 17:28:49',0,'2013-01-26 17:28:49',NULL,'[openstack-dev] Motion on Technical Committee membership for\n Spring 2013 session','On Thu, 2013-01-24 at 17:44 +0100, Thierry Carrez wrote:\n\n> The PTL is much more influential than a TC member. The PTL has ultimate\n> (and *unshared*) say on what happens over his project. He takes precise\n> day-to-day technical decisions, and can do all by himself.\n> \n> Comparing that to just one vote on a committee of 13 members that\n> address cross-project issues and express their opinion on a handful of\n> issues every 6 months... I\'m pretty sure it\'s clear what position ends\n> up being more influential.\n\nThis is a pretty crucial point, I think.\n\nI find it really, really sad that people could think that any project\'s\ninterests would be ignored if their PTL doesn\'t have a vote on the TC.\n\nWe place far too much emphasis on voting in the Technical Committee. The\nTC should instead be about building cross-project consensus. Close-run\nvotes on any matter is not a healthy basis to proceed with anything. The\nfact that TC members have the option of voting against something without\nblocking it means that members can avoid the responsibility of engaging\nwith the rest of the TC to find a consensus position that works for\nthem.\n\nSwitching to an all-elected committee would give us the opportunity to\nshow that the consensus building model can work. Because an all-elected\nTC that doesn\'t work to build consensus which involves all PTLs just\nwill not work.\n\nKeeping the status quo and adding more PTLs will mean more PTLs fearful\nof their project being ignored by an all-elected TC - i.e. I\'m skeptical\nwe\'ll ever be brave enough to give all-elected a shot if we decide not\nto now.\n\nCheers,\nMark.\n\n\n\n','<510164DF.6020309@openstack.org>',NULL),('<1359340453.383.1367042791711.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:06:31',0,'2013-04-27 06:06:31',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal7 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 4ee93f2b:quantal7\nUsing strategy: Default\nLast Built Revision: Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nChecking out Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson3150269241818438531.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.j2UiUmhzuC\n+ TMPDIR=/tmp/tmp.j2UiUmhzuC\n+ trap \'rm -rf /tmp/tmp.j2UiUmhzuC\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\n2012.2.5\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python27-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 58090 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal7\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.j2UiUmhzuC\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-03-28\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'f5b2ca7b-01fb-4694-9f34-22675f1f18a8\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal7\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 58090 166.78.136.24 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 2))\nNo distributions at all found for Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.j2UiUmhzuC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1359366860.17541.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-28 09:54:20',0,'2013-01-28 09:54:20',NULL,'[openstack-dev] oslo library version summary','On Mon, 2013-01-28 at 10:42 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > Latest oslo-config repo is here:\n> >   http://github.com/markmc/openstack-config\n> > \n> > and proposed for import here:\n> >   https://review.openstack.org/20117\n> > \n> > Given the recent versioning changes, a tarball built from this repo\n> > currently has 2012.3.a84.gc490e35 as its version.\n> \n> Hmmm... shouldn\'t that be 2013.1 ? There is no such thing as 2012.3.\n\nYep sorry, typo :)\n\nCheers,\nMark.\n\n\n\n','<510647F7.2060300@openstack.org>',NULL),('<1359440857.2298.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 06:27:37',0,'2013-01-29 06:27:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-swift-docs-stable-folsom #116','On Mon, 2013-01-28 at 17:10 -0800, James E. Blair wrote:\n> Mark McLoughlin <markmc at redhat.com> writes:\n> \n> > Hi James,\n> >\n> > As best I can tell, the swift bitrot jobs shouldn\'t be running anymore\n> > since:\n> >\n> >   https://review.openstack.org/18901\n> >\n> > Confused ...\n> \n> Sorry about that.  We haven\'t set up jenkins-job-builder to actually\n> delete jobs yet.  Since all our jobs are in JJB now, we should be safe\n> to start doing that.\n\n> I manually deleted those jobs, so we should be good now.\n\nAh, that makes sense - thanks James!\n\nMark.\n\n\n\n','<87libcyetr.fsf@shiprock.lan>',NULL),('<1359457347.2298.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 11:02:27',0,'2013-01-29 11:02:27',NULL,'[Openstack-stable-maint] Merges to stable/folsom','Hi Dave,\n\nOn Tue, 2013-01-29 at 10:31 +0000, Daviey Walker wrote:\n> Hi Mark,\n> \n> Hope you are well.\n> \n> You\'ve probably noticed that I accepted a few merges to stable/folsom.\n>  I spotted on a comment for one that stable/folsom was in freeze until\n> this Thursday.  I didn\'t realise this, which is why you will have seen\n> a few land today.\n> \n> I apologise for this, and whilst i\'m confident they were safe and the\n> regression potential is low; I am willing to help solve any issues\n> this causes (Including backing them out).\n\nThanks for the heads-up. Partly my bad, I should have been keeping a\ncloser watch out.\n\nThe process isn\'t perfect, but I\'m reluctant to get into the\ncomplication of doing the equivalent of milestone-proposed for stable\nreleases. We\'ll probably end up doing that eventually, though.\n\nThe three changes merged since we froze were:\n\n    https://review.openstack.org/19264\n      nova: Fix to include error message in instance faults\n\n    https://review.openstack.org/20644\n      quantum: LinuxBridge: update status according to admin_state_up\n\n    https://review.openstack.org/20544\n      quantum: Ensure that correct root helper is used\n\nAnyone with concerns, please shout.\n\nThanks,\nMark.\n\n\n\n','<CACyjiAjZFBp62V=xjUjEpKBDzm8RQoS_CgcXXKueuf7m-dckTg@mail.gmail.com>',NULL),('<1359459506.2298.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 11:38:26',0,'2013-01-29 11:38:26',NULL,'[Openstack-stable-maint] Merges to stable/folsom','On Tue, 2013-01-29 at 13:26 +0200, Gary Kotton wrote:\n> On 01/29/2013 01:02 PM, Mark McLoughlin wrote:\n> > Hi Dave,\n> >\n> > On Tue, 2013-01-29 at 10:31 +0000, Daviey Walker wrote:\n> >> Hi Mark,\n> >>\n> >> Hope you are well.\n> >>\n> >> You\'ve probably noticed that I accepted a few merges to stable/folsom.\n> >>   I spotted on a comment for one that stable/folsom was in freeze until\n> >> this Thursday.  I didn\'t realise this, which is why you will have seen\n> >> a few land today.\n> >>\n> >> I apologise for this, and whilst i\'m confident they were safe and the\n> >> regression potential is low; I am willing to help solve any issues\n> >> this causes (Including backing them out).\n> > Thanks for the heads-up. Partly my bad, I should have been keeping a\n> > closer watch out.\n> \n> My understanding is that the release date is the 31st. I do not recall \n> any update about the stable branch being in a frozen state. At last \n> nights Quantums meeting I mentioned that I was planning to backport some \n> patches and there were no objections.\n\nOn Jan 22:\n\n  http://lists.openstack.org/pipermail/openstack-stable-maint/2013-January/000282.html\n\n  2012.2.3 is scheduled for January 31st. I\'m planning on calling\n  whatever we have on January 25th a RC and getting aggressive about\n  punting anything risky until the next release.\n\nand:\n\n  http://eavesdrop.openstack.org/meetings/project/2013/project.2013-01-22-21.02.html\n\n  2012.2.3 scheduled for Jan 31, RC Jan 24\n\nI -2ed some Nova changes on Friday:\n\n  https://review.openstack.org/20485\n  https://review.openstack.org/20337\n\n> > The process isn\'t perfect, but I\'m reluctant to get into the\n> > complication of doing the equivalent of milestone-proposed for stable\n> > releases. We\'ll probably end up doing that eventually, though.\n> \n> I do not think that we need to be extreme about it, but a sync a few \n> days before to understand that we are all on the same page would suffice.\n\nThat\'s what we did for 2012.2.1:\n\n  http://lists.openstack.org/pipermail/openstack-stable-maint/2012-November/000131.html\n\nand ended up with a regression in Nova:\n\n  http://lists.openstack.org/pipermail/openstack-stable-maint/2012-December/000150.html\n\nA week really is a fairly minimal amount of time to lock things down\nbefore a release.\n\n> > The three changes merged since we froze were:\n> >\n> >      https://review.openstack.org/19264\n> >        nova: Fix to include error message in instance faults\n> >\n> >      https://review.openstack.org/20644\n> >        quantum: LinuxBridge: update status according to admin_state_up\n> \n> This is not a MUST have for this release. It is very nice to have an \n> improves the usability. What is the risk - very low. It would be nice to \n> have https://review.openstack.org/#/c/20677/ in conjunction with this \n> one. Please note that the patch https://review.openstack.org/#/c/20676/ \n> depends on the aforementioned patch.\n\nPlease add your justifications to the review - i.e. how user-visible the\nissue, how low risk the fix is, how well tested it is etc.\n\nThanks,\nMark.\n\n\n\n','<5107B1FD.90601@redhat.com>',NULL),('<1359472476.2298.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-29 15:14:36',0,'2013-01-29 15:14:36',NULL,'[openstack-dev] blueprint amqp-rpc-fast-reply-queue','Hi\n\nOn Tue, 2013-01-29 at 00:23 -0600, Ray Pekowski wrote:\n> This is in regards to the comments in the code review for this blueprint:\n> https://review.openstack.org/#/c/19721/\n> \n> This blueprint is blocked primarily due to backward compatibility issues.\n> Russell Bryant posted in a different thread that RPC features are typically\n> added in two releases.  The first to enable the receiving of message having\n> the new feature.  The second to enable the sending of messages having the\n> new feature.\n\nI admit I haven\'t been following this conversation closely enough, but\nthat seems like a slight misunderstanding.\n\nSee https://review.openstack.org/17554\n\nRussell did originally add a config option to allow enabling the new\nformat, but I said:\n\n  Why would a user choose to enable the new format now? Isn\'t there\n  basically no benefit until we start using the new format to do\n  something interesting in H?\n\n> My biggest concern is I don\'t want to wait two releases.  I propose that we\n> add an unsupported option \"unsupported_amqp_rpc_single_reply_queue\" which\n> enables this performance improvement feature.  This option would not be\n> documented.  It would be removed from the next release when the feature\n> becomes always enabled.\n\nIn this case, there is a (performance) benefit to using the new feature\nso it probably does make sense to have an off-by-default feature which\nwe\'d enable by default for the H release.\n\nThe config option should be documented though :)\n\nCheers,\nMark.\n\n\n\n','<CAJcv3CR1UxwvXN2Q9FNJDGud=psspA+4ve5+ih_xJuTFeiBk=w@mail.gmail.com>',NULL),('<1359472671.2298.57.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 15:17:51',0,'2013-01-29 15:17:51',NULL,'[Openstack-stable-maint] Merges to stable/folsom','Hey\n\nFYI, two security issues have just been publicly disclosed and the fixes\nwill be in 2012.2.3:\n\n  https://review.openstack.org/20696\n  https://review.openstack.org/20699\n\nCheers,\nMark.\n\n\n\n\n','<1359457347.2298.32.camel@sorcha>',NULL),('<1359498378.2298.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-01-29 22:26:18',0,'2013-01-29 22:26:18',NULL,'[openstack-tc] Incubation process','Hey\n\nThe \"Incubation Update\" committee meetings are still going on, but\nThierry and I made the point at the last meeting that the TC will soon\nneed to be able to proceed with evaluating Ceilometer and Heat for\ngraduation from Incubation.\n\nWe came up with a summary of how we think the TC should proceed based on\nthe committee discussions so far. I think it closely matches what the TC\nagreed previously its position[1] on the issue.\n\nI\'m giving the Foundation Board a run through of this on Thursday (as\nthe TC rep) to give them an opportunity to raise any red flags. Assuming\nall is well there, I expect we\'ll need to quickly go about updating the\nTC\'s policies on Incubation.\n\nTo be clear - all of this is still subject to a final TC vote.\n\nThe full summary is here:\n\n  https://etherpad.openstack.org/IncubationAndCoreInterimSummary\n\nbut the tl;dr is:\n\n  * Graduating from Incubation means a project is \"Integrated\", meaning \n    it will be part of the next coordinated release\n\n  * Which projects are accepted into - and graduate from - Incubation \n    is the TC\'s decision\n\n  * The \"Core\" designation is closely tied to the trademark programme\n    managed by the Foundation Board\n\n  * There should be no expectation that projects which graduate from \n    Incubation will eventually be designated \"Core\". Projects will work \n    with the Foundation Board - either before, during or after \n    Incubation - to understand whether they are likely to be suitable to\n    be \"Core\" in future\n\nThierry did an excellent job of drawing this:\n\n  https://docs.google.com/drawings/d/1oLo1ETnRpNSgDj_m7p6o6tF7HHA2a-3XeKa-QLMBcRc/edit\n\nDoes this all make sense to everyone?\n\nCheers,\nMark.\n\n[1] - I double-checked exactly what we agreed since it has been a while :)\n\nThe position we voted for was:\n\n  http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-20-20.01.html\n\n  Separate the trademark question from the \"developed under OpenStack\n  umbrella\" question, have incubation be the process by which you become\n  supported, potentially with multiple categories as far as associated\n  resources are concerned\n\nWe called this the \"annemark\" motion which was a summary of this:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002771.html\n\n  The concepts of \"what is core\" and \"what is in OpenStack\" have been \n  conflated until now. The TC cares far more about the process for new\n  projects to be included in the coordinated release than it cares about\n  which projects are required to be used by providers in order to access\n  the trademark.\n\n  We would like to take an inclusive but measured approach to accepting\n  new OpenStack projects. We should evaluate any given proposed project\n  on a well defined set of criteria like whether it embraces our values\n  and processes, is useful to OpenStack users, well integrated with\n  other projects and represents a sensible broadening of the scope of\n  OpenStack.\n\n  We see Incubation as a trial period where promising projects have the \n  opportunity to demonstrate their suitability for inclusion in our \n  coordinated releases.\n\n  We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n  bylaws as being solely related to trademark guidelines. The Foundation\n  should simply maintain a list of projects required for trademark \n  usage. We would be happy for that list to be called \"Core Projects\" \n  or for a new name to be chosen to describe that list.\n\nwith the addition of Anne\'s suggestion that some projects which are \"in\nOpenStack\" (what we\'re now calling \"Integrated\") might potentially\nreceive different levels of resource commitment in terms of e.g.\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002904.html\n\n  - track time at the Summit every six months\n  - release management time at the weekly Project meeting\n  - testing gated via DevStack and/or tempest\n  - CI guidance\n  - documentation guidance\n\n\n\n',NULL,NULL),('<1359663473.5699.11.camel@varinia.lobefin.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-31 20:17:53',0,'2013-01-31 20:17:53',NULL,'[openstack-dev] blueprint ec2-tags-api','Hello,\n\nAt work we use the EC2 tags API quite heavily for all sorts of things,\nso I\'ve been tasked with getting it implemented for openstack.\n\nAs some background, the EC2 API offers 3 API calls: CreateTags,\nDeleteTags and DescribeTags, as well as a way to filter a search for a\nresource by tags (by passing {\"filter\": [{\"tag:key\": \"value\"}]} or\n{\"filter\": [{\"tag-key\": \"value\"}]} as parameters to an API call like\nDescribeInstances or DescribeSecurityGroups.\n\nThe API references are here:\nhttp://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-CreateTags.html\nhttp://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DeleteTags.html\nhttp://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeTags.html\nhttp://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html\n(and other Describe* resource searches)\n\nThe part of this that seems awkward to overlay onto openstack\'s database\nschema is that tags can be applied to multiple resource types - eg, when\na stack is cloudformed, all the instances, load balancers, security\ngroups, etc are tagged with the cloudformation name.\n\nI can see two ways of implementing this: \n\n1) Reuse the existing instance-metadata table and start creating\nsecurity-group metadata tables and so on.  This approach has the\ndownside that resources that are served by cinder or quantum will be\nawkward - we\'d have to add equivalent API calls to them and call their\nAPI.\n\n2) Create a new tags table containing references to the resource type\nand ID.  This has the advantage that we won\'t need to make lots of API\ncalls to return all the resources with a given tag, but also feels\npossibly over-denormalized (is that a word?).\n\nI have a proof of concept implementation that takes the second approach,\nbut only provides an EC2 API without the equivalent nova API, and only\nprovides the filtering for DescribeInstances.  It can of course be\nextended - this was mostly me getting familiar with the code base.\n\nPlease let me know what you think.  As we use this at work, I\'ll be\nquite happy to provide the implementation, once it\'s agreed how this\nshould look.\n\nCheers,\n-- \nStephen Gran\nSenior Systems Integrator - guardian.co.uk\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit guardian.co.uk - website of the year\n \nwww.guardian.co.uk    www.observer.co.uk     www.guardiannews.com \n \nOn your mobile, visit m.guardian.co.uk or download the Guardian\niPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad \n \nSave up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. \nVisit guardian.co.uk/subscribe\n \n---------------------------------------------------------------------\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n\n\n',NULL,NULL),('<1359665762.15197.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-31 20:56:02',0,'2013-01-31 20:56:02',NULL,'[openstack-dev] \"if X not in Y\" vs. \"if not X in Y\" consensus?','On Thu, 2013-01-31 at 12:32 -0800, Maru Newby wrote:\n> Hi all,\n> \n> I\'m the reviewer that prompted Zhongyue Luo to ask this question on\n> the mailing list, and would like to chime in.\n> \n> As has been noted on this thread, not only are the two forms logically\n> equivalent, but they also produce the same byte code.  The only reason\n> to mandate one over the other would be \'readability\'.  I would\n> suggest, though, that the minimal increase in so-called readability\n> does not justify requiring reviewers to enforce this style rule.\n> \n> That is not to say that I think code consistency is without value -\n> quite the opposite.  I subscribe to Ableson/Sussman\'s view that\n> \"Programs must be written for people to read, and only incidentally\n> for machines to execute.\" I do think, however, that the effort\n> required to enforce a given rule should be weighed carefully against\n> the value that its enforcement brings.  I\'m not of the opinion that\n> manual effort is justified in this particular case.  If the community\n> consensus is that this rule needs to be enforced, I suggest that it be\n> done through automatic detection (ala pep8), or even automatic\n> correction (ala the kinds of code reformatting tools that are\n> pervasive in c/c++ land).\n\nHow about this as a conclusion?\n\nWe generally prefer \"X not in Y\", but few think it\'s a big deal.\n\nReviewers don\'t need to enforce this, but they shouldn\'t be recommending\n\"not X in Y\" either.\n\nIf anyone feels like taking on the janitorial task of removing uses of\n\"not X in Y\" from code occasionally, that\'s totally cool.\n\nIf someone wants to write a hacking.py check for this, that\'s totally\ncool too.\n\nCheers,\nMark.\n\n\n\n','<7507DC4E-FE67-4613-9944-91E319BFF16E@internap.com>',NULL),('<1359667257.15197.21.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-01-31 21:20:57',0,'2013-01-31 21:20:57',NULL,'[OpenStack Foundation] Opening up the board mailing list','Hi,\n\nThere\'s a standing desire by some (many?) board members for the\nfoundation-board mailing list to be made public so that anyone can\nfollow their discussions.\n\nPersonally, I\'d also like a way for folks who aren\'t on the board to\neasily be able to participate in any board discussions. However, there\nneeds to be some way for board members to easily separate the discussion\nbetween board members from the discussion with the wider foundation\nmembership.\n\nI think of this is an \"inner circle\"[1] mailing list setup:\n\n - Two mailing lists - \"inner circle\" and \"everyone else\", lets call \n   them the IC and EE lists\n\n - Discussions on IC are mirrored to EE\n\n - IC member starts thread on IC, the thread is also started on EE\n\n - IC member replies to thread on IC, the reply also goes to EE\n\n - EE member starts thread on EE, only goes there\n\n - EE member replies to thread on EE, whether it was started on IC and\n   EE, then the reply only goes to EE\n\n - IC member replies to thread on EE, the reply also goes only to EE\n\nI\'ve come across cases where this would be useful several times - has\nanyone seen a mailman configuration that resembles this?\n\nCheers,\nMark.\n\n[1] - I\'m using that term in a slightly mocking tone btw :)\n\n\n\n',NULL,NULL),('<1359674377.15197.23.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-01-31 23:19:37',0,'2013-01-31 23:19:37',NULL,'[OpenStack Foundation] Some ramblings','Hey\n\nIn an attempt to give individual members more of an insight into board\nmeetings, here\'s my rambling summary of today\'s meeting:\n\n  http://blogs.gnome.org/markmc/2013/01/31/first-board-meeting/\n\nMeh, my blog is still on gnome.org - who else thinks we need a wordpress\ninstance on openstack.org? :-)\n\nHTH,\nMark.\n\n\n\n',NULL,NULL),('<1359674884.15197.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-31 23:28:04',0,'2013-01-31 23:28:04',NULL,'[openstack-dev] [Fwd: Incubation process]','Hey\n\nYou might remember the big \"The future of Incubation and Core\"\ndiscussion we had back in November.\n\nSince then, reps from the TC and Foundation Board have been meeting to\nclarify (amongst other things) what it means for the TC to approve a\nproject\'s graduation from Incubation.\n\nObviously, this is important with Heat and Ceilometer\'s potential\ngraduation around the corner. We\'ve made enough progress that we can\nkeeping moving forward with the incubation process for these projects.\n\nFull details below. Questions, comments, concerns, etc. all welcome.\n\nCheers,\nMark.\n\n-------- Forwarded Message --------\n> From: Mark McLoughlin <markmc at redhat.com>\n> Reply-to: Mark McLoughlin <markmc at redhat.com>\n> To: openstack-tc at lists.openstack.org\n> Subject: Incubation process\n> Date: Tue, 29 Jan 2013 22:26:18 +0000\n> \n> Hey\n> \n> The \"Incubation Update\" committee meetings are still going on, but\n> Thierry and I made the point at the last meeting that the TC will soon\n> need to be able to proceed with evaluating Ceilometer and Heat for\n> graduation from Incubation.\n> \n> We came up with a summary of how we think the TC should proceed based on\n> the committee discussions so far. I think it closely matches what the TC\n> agreed previously its position[1] on the issue.\n> \n> I\'m giving the Foundation Board a run through of this on Thursday (as\n> the TC rep) to give them an opportunity to raise any red flags. Assuming\n> all is well there, I expect we\'ll need to quickly go about updating the\n> TC\'s policies on Incubation.\n> \n> To be clear - all of this is still subject to a final TC vote.\n> \n> The full summary is here:\n> \n>   https://etherpad.openstack.org/IncubationAndCoreInterimSummary\n> \n> but the tl;dr is:\n> \n>   * Graduating from Incubation means a project is \"Integrated\", meaning \n>     it will be part of the next coordinated release\n> \n>   * Which projects are accepted into - and graduate from - Incubation \n>     is the TC\'s decision\n> \n>   * The \"Core\" designation is closely tied to the trademark programme\n>     managed by the Foundation Board\n> \n>   * There should be no expectation that projects which graduate from \n>     Incubation will eventually be designated \"Core\". Projects will work \n>     with the Foundation Board - either before, during or after \n>     Incubation - to understand whether they are likely to be suitable to\n>     be \"Core\" in future\n> \n> Thierry did an excellent job of drawing this:\n> \n>   https://docs.google.com/drawings/d/1oLo1ETnRpNSgDj_m7p6o6tF7HHA2a-3XeKa-QLMBcRc/edit\n> \n> Does this all make sense to everyone?\n> \n> Cheers,\n> Mark.\n> \n> [1] - I double-checked exactly what we agreed since it has been a while :)\n> \n> The position we voted for was:\n> \n>   http://eavesdrop.openstack.org/meetings/tc/2012/tc.2012-11-20-20.01.html\n> \n>   Separate the trademark question from the \"developed under OpenStack\n>   umbrella\" question, have incubation be the process by which you become\n>   supported, potentially with multiple categories as far as associated\n>   resources are concerned\n> \n> We called this the \"annemark\" motion which was a summary of this:\n> \n>   http://lists.openstack.org/pipermail/openstack-dev/2012-November/002771.html\n> \n>   The concepts of \"what is core\" and \"what is in OpenStack\" have been \n>   conflated until now. The TC cares far more about the process for new\n>   projects to be included in the coordinated release than it cares about\n>   which projects are required to be used by providers in order to access\n>   the trademark.\n> \n>   We would like to take an inclusive but measured approach to accepting\n>   new OpenStack projects. We should evaluate any given proposed project\n>   on a well defined set of criteria like whether it embraces our values\n>   and processes, is useful to OpenStack users, well integrated with\n>   other projects and represents a sensible broadening of the scope of\n>   OpenStack.\n> \n>   We see Incubation as a trial period where promising projects have the \n>   opportunity to demonstrate their suitability for inclusion in our \n>   coordinated releases.\n> \n>   We see the term \"Core OpenStack Project\" in section 4.1.b of the  \n>   bylaws as being solely related to trademark guidelines. The Foundation\n>   should simply maintain a list of projects required for trademark \n>   usage. We would be happy for that list to be called \"Core Projects\" \n>   or for a new name to be chosen to describe that list.\n> \n> with the addition of Anne\'s suggestion that some projects which are \"in\n> OpenStack\" (what we\'re now calling \"Integrated\") might potentially\n> receive different levels of resource commitment in terms of e.g.\n> \n>   http://lists.openstack.org/pipermail/openstack-dev/2012-November/002904.html\n> \n>   - track time at the Summit every six months\n>   - release management time at the weekly Project meeting\n>   - testing gated via DevStack and/or tempest\n>   - CI guidance\n>   - documentation guidance\n\n\n\n\n',NULL,NULL),('<1359678152.15197.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2013-02-01 00:22:32',0,'2013-02-01 00:22:32',NULL,'[openstack-announce] [ANNOUNCE] OpenStack 2012.2.3 released','Hey,\n\nIn the time since the Folsom release, we have been busy selectively\nback-porting bugfixes to the stable/folsom branch according to our \"safe\nsource of high-impact fixes\" criteria documented here:\n\n  http://wiki.openstack.org/StableBranch\n\nWe\'re happy to announce the 2012.2.3 release, the latest in the series\nof releases to make available the bugfixes from stable/folsom.\n\nThese releases are bugfix updates to Folsom and are intended to be\nrelatively risk free with no intentional regressions or API changes.\n\nA total of 51 bugs have been fixed in this release. The list of bugs\nfixed can be seen here:\n\n  https://launchpad.net/nova/folsom/2012.2.3\n  https://launchpad.net/glance/folsom/2012.2.3\n  https://launchpad.net/keystone/folsom/2012.2.3\n  https://launchpad.net/cinder/folsom/2012.2.3\n  https://launchpad.net/quantum/folsom/2012.2.3\n  https://launchpad.net/horizon/folsom/2012.2.3\n\nPlease read (and add to!) the release notes at:\n\n  http://wiki.openstack.org/ReleaseNotes/2012.2.3\n\nEnjoy!\n\nMark.\n\n\n\n',NULL,NULL),('<1359717501.2348.20.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-01 11:18:21',0,'2013-02-01 11:18:21',NULL,'[OpenStack Foundation] Individual Member Election Statistics\n (January 2013)','On Fri, 2013-02-01 at 09:06 +0100, Vincent Untz wrote:\n...\n> All credits for this should still go to James, as we used the same\n> script, and his explanations for each table are used below.\n\nExcellent work again, kudos guys.\n\n...\n> The following table lists the sources of votes for the top 8 candidates\n> classified by the employer of the voter. Four categories are listed;\n> the first, \"%Employer\", is the percentage of voters for that candidate\n> with the same employer as the candidate. The second, \"%Major\", is the\n> percentage of voters from a \"major\" employer, which is to say an\n> employer that was specified by at least 5 voters overall (there are\n> about 20 \"major\" employers in the data set by this calculation). The\n> third, \"%Minor\", is the percentage from a \"minor\" employer, i.e., one\n> specified by less than 5 individuals. The last, \"%None\", is the\n> percentage who listed no affiliation.\n> \n>               Source of Votes for Top 8 Candidates\n> +-----------------+----------------------+-----------+--------+--------+-------+\n> |       Name      |       Employer       | %Employer | %Major | %Minor | %None |\n> +-----------------+----------------------+-----------+--------+--------+-------+\n> | Monty Taylor    | HP                   |    57 %   |  22 %  |  14 %  |   7 % |\n> | Rob Hirschfeld  | Dell                 |    59 %   |  23 %  |  13 %  |   5 % |\n> | Troy Toman      | Rackspace            |    68 %   |  18 %  |  10 %  |   4 % |\n> | Hui Cheng       | SINA                 |           |        |  29 %  |  31 % |\n> | Tim Bell        | CERN                 |           |        |  23 %  |  10 % |\n> | Lauren Sell     | OpenStack Foundation |           |        |  19 %  |   8 % |\n> | Mark McLoughlin | Red Hat              |           |        |  24 %  |   9 % |\n> | Tristan Goode   | Aptira               |           |        |  30 %  |  12 % |\n> +-----------------+----------------------+-----------+--------+--------+-------+\n>       [Some values have been omitted to preserve anonymity.]\n\nWhat I\'d focus on here is %Employer\n\nLast time around it was:\n\n| Rob Hirschfeld | Dell      |    86 % \n| Monty Taylor   | HP        |    75 % \n| Joseph George  | Dell      |    88 % \n| Troy Toman     | Rackspace |    76 %\n\nThe smaller numbers this time around means the candidates\' votes were\nfrom a more diverse set of voters.\n\nThat\'s definitely a solid improvement, but it still looks to me like the\nbig blocks of affiliated voters have an overly large influence over the\nresult. If the affiliated blocks who voted for the top 3 candidates were\na more average size, I\'m guessing they still would rank highly (which is\ngreat) but it would be a much more closely run thing.\n\n> The following table shows how voters who identified as affiliates of\n> \"major\" employers (see above) voted. Only the \"major\" employers with at\n> least 50 affiliated voters and at least 10% of their affiliates voting\n> for at least one candidate employed by the subject employer are listed\n> to preserve anonymity.\n> \n> The first column after the name of the organization indicates the number\n> of voters claiming affiliation with that organization. Three percentages\n> are then listed: the first, \"%Only Affiliated\" is the percentage of\n> those voters who voted only for candidates employed by their affiliate\n> organization. The second, \"%Including Affiliated\", is the percentage who\n> voted for at least one candidate employed by their affiliate\n> organization. The third, \"%Non Affiliated\" is the percentage who did not\n> vote for any employee of their affiliate organization.\n> \n>                      How Affiliates Voted\n> +-----------+------------+------------+------------+------------+\n> |           |   Number   |   %Only    | %Including |    %Non    |\n> |    Name   | Affiliated | Affiliated | Affiliated | Affiliated |\n> +-----------+------------+------------+------------+------------+\n> | Dell      |    242     |    52 %    |    90 %    |    10 %    |\n> | HP        |    273     |    40 %    |    87 %    |    13 %    |\n> | Rackspace |    261     |    32 %    |    90 %    |    10 %    |\n> +-----------+------------+------------+------------+------------+\n\nCompared to this last year:\n\n| Dell      |    470     |    81 %    |    97 %    |     3 %    |\n| HP        |    304     |    55 %    |    91 %    |     9 %    |\n| Rackspace |    244     |    25 %    |    85 %    |    15 %    |\n\nit again looks like a good improvement - i.e. more diversity in voting\nand smaller blocks of voters - but the numbers of voters affiliated with\nthese companies still seem surprisingly high, at least to me.\n\nCheers,\nMark.\n\n\n\n','<20130201080655.GS1775@vuntz.net>',NULL),('<1359733539.9071.13.camel@gashuffer.lobefin.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-01 15:45:39',0,'2013-02-01 15:45:39',NULL,'[openstack-dev] blueprint ec2-tags-api','Hi,\n\nOn Thu, 2013-01-31 at 14:30 -0800, Vishvananda Ishaya wrote:\n> On Jan 31, 2013, at 12:17 PM, Stephen Gran <stephen.gran at guardian.co.uk> wrote:\n> > \n> > 2) Create a new tags table containing references to the resource type\n> > and ID.  This has the advantage that we won\'t need to make lots of API\n> > calls to return all the resources with a given tag, but also feels\n> > possibly over-denormalized (is that a word?).\n> \n> This would be the fastest way to implement the feature, but I suspect we will end up\n> with some pretty nasty querys to do filters by tags in this model.\n\nThe proof of concept patch for doing it this way is at\nhttps://review.openstack.org/#/c/20412/ .   The queries aren\'t amazing,\nbut they\'re not that awful either.  It currently hardcodes \'instance\',\nbut that\'s just a lookup table to fix.\n\nThis doesn\'t mean I disagree about the right way to do it - if you think\ntags will serve a purpose in glance/quantum/etc beyond EC2 API\ncompatibility, then that\'s the right way to do it.  I\'m just saying that\nif it\'s not useful in it\'s own right, getting a cheap and cheerful EC2\nAPI compatibility fix a different way doesn\'t introduce huge amounts of\nawfulness.\n\nCheers,\n-- \nStephen Gran\nSenior Systems Integrator - guardian.co.uk\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit guardian.co.uk - website of the year\n \nwww.guardian.co.uk    www.observer.co.uk     www.guardiannews.com \n \nOn your mobile, visit m.guardian.co.uk or download the Guardian\niPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad \n \nSave up to 37% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. \nVisit guardian.co.uk/subscribe\n \n---------------------------------------------------------------------\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n\n\n','<EA69ABF6-2B8D-41B7-B875-62442A923FA2@gmail.com>',NULL),('<1359800920.3672.16.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-02 10:28:40',0,'2013-02-02 10:28:40',NULL,'[OpenStack Foundation] Opening up the board mailing list','On Fri, 2013-02-01 at 09:20 +0100, Thierry Carrez wrote:\n> Dave Neary wrote:\n> > On 01/31/2013 10:20 PM, Mark McLoughlin wrote:\n> >> There\'s a standing desire by some (many?) board members for the\n> >> foundation-board mailing list to be made public so that anyone can\n> >> follow their discussions.\n> >>\n> >> Personally, I\'d also like a way for folks who aren\'t on the board to\n> >> easily be able to participate in any board discussions. However, there\n> >> needs to be some way for board members to easily separate the discussion\n> >> between board members from the discussion with the wider foundation\n> >> membership.\n> >>\n> >> I think of this is an \"inner circle\"[1] mailing list setup:\n> >>\n> >>   - Two mailing lists - \"inner circle\" and \"everyone else\", lets call\n> >>     them the IC and EE lists\n> > \n> > I\'ve been thinking of foundation as EE, in which case the board list is\n> > IC - and opening the archives of board discussions/allowing read-only\n> > subscriptions would give the transparency to the operation of the board.\n> > Since board members are all members of the foundation list already\n> > (correct?) the foundation list would be the avenue for members to engage\n> > with the board. Problem solved, without the need for Yet Another Mailing\n> > List or a complicated workflow.\n> > \n> > Am I missing something?\n> \n> That\'s been my suggestion too. The workflow that Mark suggests is likely\n> to result in thread duplication, missing elements in some threads vs.\n> the other, and overall confusion, especially with a population that\'s\n> not necessarily following strict ML etiquette.\n> \n> Using two lists (with one of them being the \"open discussion\" list for\n> the topics formally introduced on the first one) is a classic setup that\n> is simpler and more foolproof imho.\n\nI see this model panning out one of two ways:\n\n  1) The majority of the discussion happens on the open list and we \n     are very successful at getting non-directors involved in healthy \n     open discussions. This means massive email threads which I expect \n     many of the directors to find overwhelming and not follow or \n     participate in the discussion. That could mean little in the way of\n     collaborative discussion amongst directors, or those discussions \n     happening privately somewhere.\n\n  2) The majority of the discussion happens amongst directors on the \n     readonly list with maybe summaries sent to the open list. \n     Non-directors are annoyed because they can only follow the\n     discussion by looking at the archives and it\'s difficult to take \n     part of the discussion amongst the directors and discuss the topic \n     amongst the wider audience.\n\nBasically, I think a big part of the value committee like this is the\nmembers actively and directly engaging with each to understand their\npoints of view. In an ideal world, the committee members would also\nlisten to the points of view of non-members. But if we end up with a\nsituation that the volume of discussion is so large that it\'s hard to\neven just have a discussion amongst committee members, then you\'ll get a\nleast some of the members giving up completely on the discussion.\n\nI think this is even true of the TC - if we had discussions on the TC\nlist, I think TC members would be more engaged. Instead, we have it on\nthe -dev list and have more participation, but less participation from\nthe committee members. I think the problem will be worse with the board,\nwhere many of the directors just aren\'t used to massive mailing list\ndiscussions.\n\nWhat I\'m trying to figure out is a model where directors engage fully\nwith each other in open discussions, but we also have a very active open\ndiscussions amongst non-directors which directors can dip in and out of.\n\nCheers,\nMark.\n\n\n\n','<510B7AD9.7060303@openstack.org>',NULL),('<1359801203.3672.20.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-02 10:33:23',0,'2013-02-02 10:33:23',NULL,'[OpenStack Foundation] Opening up the board mailing list','On Fri, 2013-02-01 at 01:00 +0100, Dave Neary wrote:\n> > I\'ve come across cases where this would be useful several times - has\n> > anyone seen a mailman configuration that resembles this?\n> \n> It is possible in Mailman to restrict posting to a list to a subset of \n> the members - you set the \"Moderation\" flag and set behaviour for all \n> moderated users to \"Discard\" or \"Reject\" (reject lets the poster know \n> the mail was rejected, which might be better) in \"Privacy \n> options->Sender filters\" - then you unset the mod bit for all board \n> members in \"Membership management\".\n> \n>   That would allow you to have non-board-members subscribe to the board \n> list, get all the email, but not be able to post. If members really want \n> to raise issues related to the board member post, then it can be done on \n> foundation, but you\'d need to manually change the header (which might be \n> an effective social control to bike shedding board conversations, rather \n> than trying to figure out how to have reply-to set to a different list \n> for a subset of the membership). \n\nI have no idea whether it is possible, but if it is then it would work\npretty well except the \"non-directors need to change the Reply: header\nwhen replying\" part. That\'s not terrible, and we can actively encourage\npeople to do it.\n\nCheers,\nMark.\n\n\n\n','<510B05BA.7020206@redhat.com>',NULL),('<1359941484.16.1382940527181.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-28 06:08:47',0,'2013-10-28 06:08:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #38','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/38/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/registry/client.py\",> line 89, in do_request\n    action, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55f70d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55f70d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4bddc90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4bddc90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-d146f824-bbb6-4064-9a1f-dc99245f6dba\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:08:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:08:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:08:27+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'27\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:08:27-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'27\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:08:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5cc66d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x203ad50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 64.41 secs:\n    13.49    TestGlanceControl.test_bouncing\n    13.05    TestScrubber.test_delayed_delete\n    13.02    TestGlanceControl.test_reload\n    12.82    TestGlanceControl.test_respawn\n    12.03    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 404.265s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-38\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.5Hw3emhkjr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/38/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise35/38\n[SCP] Copying console log.\n\n\n','<1590772962.2.1382594979042.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1359982891.2432.14.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-04 13:01:31',0,'2013-02-04 13:01:31',NULL,'[OpenStack Foundation] Opening up the board mailing list','On Sat, 2013-02-02 at 17:12 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > What I\'m trying to figure out is a model where directors engage fully\n> > with each other in open discussions, but we also have a very active open\n> > discussions amongst non-directors which directors can dip in and out of.\n> \n> I see where you\'re going... My main gripe with it is that I don\'t see\n> how the duplicate-thread-to-EE and reply-to-both-lists rules can be\n> enforced in the ML setup, so it will rely on people applying it.\n> \n> If we can\'t get developers to use subject prefixes, I somehow doubt we\n> can get directors to follow thread replication rules between two\n> mailing-lists. And the discussion can quickly get messy if a subset of\n> people don\'t follow the rules.\n\nRight, I\'m not proposing a solution. I\'m proposing some requirements for\nan ideal solution and looking for ideas. You think it can\'t be done, I\nget that :)\n\n> The alternative setup doesn\'t depend so much on people following a copy\n> rule, so my impression is that it would be more successful in the end ?\n\nYou mean Dave\'s idea? It\'s certainly fairly close to the requirements I\nlaid out, but I don\'t think Dave is certain mailman can even do that\nmuch.\n\nCheers,\nMark.\n\n\n\n','<510D3ADD.8050203@openstack.org>',NULL),('<135BC36F-C8A5-49EA-B7B7-FEC238019C07@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 13:15:30',-18000,'2014-12-01 18:15:30',NULL,'[openstack-dev] [oslo] change to Oslo release process to\n	support stable branch requirement caps','\nOn Dec 1, 2014, at 9:57 AM, Thierry Carrez <thierry at openstack.org> wrote:\n\n> Doug Hellmann wrote:\n>> On Dec 1, 2014, at 9:31 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n>> \n>>> Are we going to have stable releases for those branches?\n>> \n>> We will possibly have point or patch releases based on those branches, as fixes end up needing to be backported. We have already done this in a few cases, which is why some libraries had stable branches already.\n> \n> We won\'t do stable coordinated point releases though, since those\n> libraries are on their own semver versioning scheme.\n\nYes, good point. We would release as needed, from the stable branches, bumping the least significant value in the version number.\n\nDoug\n\n> \n> Cheers,\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<547C81C5.4030701@openstack.org>',NULL),('<135D33FC-73CB-442D-9AEE-FF6D93AE0632@juniper.net>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-12-11 01:52:30',0,'2013-12-11 01:52:30',NULL,'[OpenStack-Infra] Requesting account for Opencontrail third party\n	testing','New SSH account:\ncontrail\n\nHuman readable name:\nOpenContrail\n\nSSH pub\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDk+ZmN6aHbLbV7vw79J1q09p42ba/u1kxWRmECKUBG/5m41VM1Xg+kvhq/qbz8yI1n6Z+LHCrDzFt5EWHj4ng33nCf6riVFBRvNxiAAsX3QXHqd1KhMGUm9Q15xCfQYzKfgW+Op2eW6l/UBPZrybjO1RCcZzTuumMdOfK6M1r2ISzj9vxSYQvxSNfmXDAUysOS+TAuXLS093RhKfC6WueH0pQ+2mwdw2Qyqyy9iCveTwCBQesrPUOOYdVvjRNXzN0nIZlLY7zeadU7o5twNDyBKyiCfEJ5NpAunGStf94Vdo+a/+WRl2fXyAFrPBlHvQG6ghcvpuUEsgMDMM5wx/kL root at Ubuntu-1204-precise-64-minimal\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131211/bba40df3/attachment.html>\n\n',NULL,NULL),('<1360010093.407321890@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-04 15:34:53',-18000,'2013-02-04 20:34:53',NULL,'[openstack-dev] \"if X not in Y\" vs. \"if not X in Y\" consensus?','\n+1\n \n-----Original Message-----\nFrom: \"Mark McLoughlin\" <markmc at redhat.com>\nSent: Thursday, January 31, 2013 3:56pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] \"if X not in Y\" vs. \"if not X in Y\" consensus?\n\n\n\nOn Thu, 2013-01-31 at 12:32 -0800, Maru Newby wrote:\n> Hi all,\n> \n> I\'m the reviewer that prompted Zhongyue Luo to ask this question on\n> the mailing list, and would like to chime in.\n> \n> As has been noted on this thread, not only are the two forms logically\n> equivalent, but they also produce the same byte code.  The only reason\n> to mandate one over the other would be \'readability\'.  I would\n> suggest, though, that the minimal increase in so-called readability\n> does not justify requiring reviewers to enforce this style rule.\n> \n> That is not to say that I think code consistency is without value -\n> quite the opposite.  I subscribe to Ableson/Sussman\'s view that\n> \"Programs must be written for people to read, and only incidentally\n> for machines to execute.\" I do think, however, that the effort\n> required to enforce a given rule should be weighed carefully against\n> the value that its enforcement brings.  I\'m not of the opinion that\n> manual effort is justified in this particular case.  If the community\n> consensus is that this rule needs to be enforced, I suggest that it be\n> done through automatic detection (ala pep8), or even automatic\n> correction (ala the kinds of code reformatting tools that are\n> pervasive in c/c++ land).\n\nHow about this as a conclusion?\n\nWe generally prefer \"X not in Y\", but few think it\'s a big deal.\n\nReviewers don\'t need to enforce this, but they shouldn\'t be recommending\n\"not X in Y\" either.\n\nIf anyone feels like taking on the janitorial task of removing uses of\n\"not X in Y\" from code occasionally, that\'s totally cool.\n\nIf someone wants to write a hacking.py check for this, that\'s totally\ncool too.\n\nCheers,\nMark.\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130204/9f110391/attachment.html>\n\n','<1359665762.15197.5.camel@sorcha>',NULL),('<1360017823.03922353@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-04 17:43:43',-18000,'2013-02-04 22:43:43',NULL,'[openstack-dev] Glance to refer images on a image library\n	rather than upload','\nHi VK,\n\nCurrently, the answer is sort of. There is work going into bypassing glance when downloading from an image store so that it goes straight from the image store to the compute node. There was a recent patch (https://review.openstack.org/#/c/19408/) for making this work when nova has access to the same filesystem as glance and glance is using the filesystem as the image store. \n\nOther than this I do not believe there is a way to avoid the extra download to glance.\n\nSpecifying the location just makes it so that an image can be added to glance without uploading data to glance. Then whenever an image is requested to be downloaded from glance, glance will first download the image data from the specified location and then pass it on.\n\nDoes this answer your question?\n\n-Alex Meade\n \n-----Original Message-----\nFrom: \"VK Kumar\" <vkkumar.live at gmail.com>\nSent: Thursday, January 31, 2013 6:34am\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] Glance to refer images on a image library rather than upload\n\n\n\nHi All,\nIs there a way to add an image from an existing image library (file share) into glance so that the image is not copied to the glance server?\nWhen ever nova boot is used, the image is then directly copied from the image server to the compute node.\nI am not sure if using the location option as http/s3/switf url still copies the image or references it.\nglance add location=http+s3://AWSACCOUNTID:<email address hidden>/BUCKET/OBJECTNAME name=\"My S3 Image\" disk_format=ami container_format=ami is_public=True\n\n\nThanks,\nVK Kumar.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130204/b1469b0d/attachment.html>\n\n','<CAF81-aT6WP0vh5LnLGiuca1skgnpXHJV+HwaDWn96iyaa3mfgw@mail.gmail.com>',NULL),('<1360028072.2432.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-05 01:34:32',0,'2013-02-05 01:34:32',NULL,'[openstack-dev] oslo library version summary','On Sat, 2013-01-26 at 08:52 +1100, Monty Taylor wrote:\n> \n> On 01/26/2013 05:00 AM, Mark McLoughlin wrote:\n> > On Sun, 2012-12-16 at 00:02 -0800, Monty Taylor wrote:\n> >> Hey all,\n> >>\n> >> ttx, markmc and I synced up on the versioning of oslo libraries, and\n> >> have settled on a system which is a superset of what we do with client\n> >> libraries - which means we can just implement an additional feature in\n> >> the current code and it\'ll handle both sets of things. We\'ll sync up\n> >> later on to discuss applicability of this to the server projects as well.\n> >>\n> >> Essentially, it breaks down like this:\n> >>\n> >> A tag to the repo will trigger tarball generation.\n> >>\n> >> If the tag contains alpha\\d*, beta\\d* or rc\\d*, the tarball will only be\n> >> uploaded to tarballs.openstack.org. This will allow those pre-releases\n> >> to be used in the other projects.\n> >>\n> >> Otherwise, the tarball will be uploaded to tarballs.o.o AND PyPI. This\n> >> should allow us to use released versions of oslo libraries in pip-requires.\n> >>\n> >> Turns out it\'s easy to implement:\n> >>\n> >> https://review.openstack.org/#/c/18171/\n> >>\n> >> As soon as that lands, we should be able to handle the oslo requirements.\n> > \n> > Latest oslo-config repo is here:\n> > \n> >   http://github.com/markmc/openstack-config\n> > \n> > and proposed for import here:\n> > \n> >   https://review.openstack.org/20117\n> > \n> > Given the recent versioning changes, a tarball built from this repo\n> > currently has 2012.3.a84.gc490e35 as its version.\n> > \n> > I guess I shouldn\'t do alpha releases since that needlessly conflicts\n> > with the alpha versioning scheme we use for git snapshots?\n> > \n> > So, if/when I want to release the first beta, I do:\n> > \n> >   $> git tag -s 2012.3b1\n> > \n> > building that gives:\n> > \n> >   $> python setup.py sdist\n> >   $> ls dist/\n> >   oslo-config-2012.3b1.tar.gz\n> > \n> > and pushing the tag would cause the tarball to be uploaded:\n> > \n> >   $> git push gerrit tag 2012.3b1\n> > \n> > and sometime in the future, Thierry or I would do:\n> > \n> >   $> git push gerrit tag 2012.3\n> > \n> > and that would get uploaded to PyPI.\n> \n> Yup!\n\n... and if I want to depend on a beta oslo-config tarball from\ntarballs.openstack.org in e.g. Nova, I stick the tarball URL in\npip-requires? Once it gets published to pypi, I\'ll go back around and\nuse a proper versioned require?\n\nCheers,\nMark.\n\n\n\n','<5102FE96.8050305@inaugust.com>',NULL),('<1360060862.2432.62.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-02-05 10:41:02',0,'2013-02-05 10:41:02',NULL,'[openstack-tc] TC meeting tomorrow Tue Feb 5, 20:00 UTC','On Tue, 2013-02-05 at 08:32 +1100, Monty Taylor wrote:\n> \n> On 02/05/2013 03:13 AM, Thierry Carrez wrote:\n> > Hello members of the TC,\n> > \n> > Tomorrow at 20:00 UTC we\'ll hold a TC meeting with the following agenda:\n> > \n> > * Update on the \"Future of Incubation / core\" joint committee\n> >   * Officialize incubation process update [1]\n> \n> Can you clarify what \"officialize\" means? The joint committee has not\n> actually made a final recommendation (although I agree that the writeup\n> matches the discussion of that so far)\n\nOk, it appears this whole thing is way too confusing.\n\nYou\'re right - the joint committee has yet to make a final report of its\nfindings to the TC and Foundation Board. That\'s because there\'s still a\nlot of ongoing discussion around the trademark programme side of things\n- i.e. \"the meaning of Core\".\n\nPerhaps we should have had the committee formally do a report on the\nincubation process side of things, but instead we took the approach that\nthe committees\' discussions have already validated and elaborated the\napproach the TC wished to take to carrying out its existing mandate.\n\nI understood that the committee members were happy with that approach\nand there were no objections from the board last week. But there seems\nto be a bunch of confusion around it.\n\nWhat we\'re talking about here is the TC updating a process which it is\nresponsible for. Beyond weeks of working through the details in a joint\ncommittee and sharing our plans with the board, what more officialness\ndo people need before being comfortable with us moving forward?\n\nI guess we could take a slightly more formal run at this - have the\ncommittee approve an \"Incubation Process\" report this week and set up a\njoint meeting between the TC and Board during next week\'s Board\nmeeting[1] to jointly approve it? Meh ...\n\nCheers,\nMark.\n\n[1] - what I don\'t like about that setup is the board members would be\nattending the meeting in person while the TC members would be dialling\nin.\n\n\n\n','<511028FD.5050805@inaugust.com>',NULL),('<1360083945.2466153@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-05 12:05:45',-18000,'2013-02-05 17:05:45',NULL,'[openstack-dev] Glance to refer images on a image library\n	rather than upload','\nHi VK,\n \nBesides the option laid out by Alex and Izy, currently you could take advantage of the bittorrent and image_cache functionality provided by nova. In this case you would need to download an image from glance once and then it could be pulled in from the image_cache for subsequent requests. Similar but not so much helpful for smaller deployments would be the bittorrent stuff.\n \nthanks,\n-Nikhil\n \n-----Original Message-----\nFrom: \"VK Kumar\" <vkkumar.live at gmail.com>\nSent: Tuesday, February 5, 2013 12:44am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] Glance to refer images on a image library rather than upload\n\n\n\nThanks Alex and Izy.\nYour replies confirm that my first part of the assumption that when location is provide the image in not uploaded into glance.\nWill check the patch links if the following is also eliminated by the patches.\n\"Then whenever an image is requested to be downloaded from glance, glance will first download the image data from the specified location and then pass it on.\"\nWhat I was thinking was that when nova boot is done for an image with location on a http server, glance will not get the image, instead it will pass on the information such as image meta-data and http location to compute so that compute can get the image. This makes sense in cases where the compute nodes have direct access to the http server repository location (SAN) and transfer would be faster.\n@Izy patch seems to address this, let me check.\nThanks again!\nVK Kumar\n\n\n\nOn Tue, Feb 5, 2013 at 7:53 AM, [mailto:lzy.dev at gmail.com] lzy.dev at gmail.com <[mailto:lzy.dev at gmail.com] lzy.dev at gmail.com> wrote:\n@VK\n If you give \"location\" option when you create glance image, glance\n will just register it  and set status to \"active\" but not upload.\n\n @Alex Meade\n I\'m developing an iSCSI store driver for Glance, it also be used to\n avoid downloading/uploading operation for nova-compute and user. It\n can support multiple path accessing:\n\n[https://review.openstack.org/#/c/20593/] https://review.openstack.org/#/c/20593/\n\n\n\n On Tue, Feb 5, 2013 at 6:43 AM, Alex Meade <[mailto:alex.meade at rackspace.com] alex.meade at rackspace.com> wrote:\n > Hi VK,\n >\n > Currently, the answer is sort of. There is work going into bypassing glance\n > when downloading from an image store so that it goes straight from the image\n > store to the compute node. There was a recent patch\n > ([https://review.openstack.org/#/c/19408/] https://review.openstack.org/#/c/19408/) for making this work when nova has\n > access to the same filesystem as glance and glance is using the filesystem\n > as the image store.\n >\n > Other than this I do not believe there is a way to avoid the extra download\n > to glance.\n >\n > Specifying the location just makes it so that an image can be added to\n > glance without uploading data to glance. Then whenever an image is requested\n > to be downloaded from glance, glance will first download the image data from\n > the specified location and then pass it on.\n >\n > Does this answer your question?\n >\n > -Alex Meade\n >\n >\n >\n > -----Original Message-----\n > From: \"VK Kumar\" <[mailto:vkkumar.live at gmail.com] vkkumar.live at gmail.com>\n > Sent: Thursday, January 31, 2013 6:34am\n > To: [mailto:openstack-dev at lists.openstack.org] openstack-dev at lists.openstack.org\n > Subject: [openstack-dev] Glance to refer images on a image library rather\n > than upload\n >\n > Hi All,\n > Is there a way to add an image from an existing image library (file share)\n > into glance so that the image is not copied to the glance server?\n > When ever nova boot is used, the image is then directly copied from the\n > image server to the compute node.\n > I am not sure if using the location option as http/s3/switf url still copies\n > the image or references it.\n > glance add location=http+s3://AWSACCOUNTID:<email address\n > hidden>/BUCKET/OBJECTNAME name=\"My S3 Image\" disk_format=ami\n > container_format=ami is_public=True\n >\n > Thanks,\n > VK Kumar.\n >> _______________________________________________\n > OpenStack-dev mailing list\n > [mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n > [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n >\n\n _______________________________________________\n OpenStack-dev mailing list\n[mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n[http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130205/81788be1/attachment.html>\n\n','<CAF81-aSfRvXgw8xGaDfG9Fz+4TybtHBpMJ7caJiax2QF1JkWGw@mail.gmail.com>',NULL),('<1360165612.2432.110.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 10:46:52',-18000,'2013-02-06 15:46:52',NULL,'[openstack-dev] RFC: Classnames in config parameters harmful to\n	users / upgrades','On Wed, 2013-02-06 at 15:22 +0000, Daniel P. Berrange wrote:\n> The only way we can do this is if we do *NOT* require the use of\n> classnames in config parameters. Instead we should treat all these\n> config parameters as being more like enumerations, and map those to\n> classnames internally\n> \n> eg for the compute_driver instead of having the user set\n> \n>   compute_driver=nova.virt.libvirt.LibvirtDriver\n> \n> they would do\n> \n>   compute_driver=libvirt \n\nI think there\'s already good consensus on this and the idea is to use\nentry points and stevedore to achieve it.\n\nSee:\n\n  https://blueprints.launchpad.net/nova/+spec/entrypoints-plugins\n  https://review.openstack.org/11027\n  https://review.openstack.org/15030\n\nThe end result is exactly that\n\n  compute_driver=libvirt\n\nwill work, along with backwards compat for the original name.\n\nIt just needs to be resurrected and finished off.\n\nCheers,\nMark.\n\n\n\n','<20130206152220.GR17014@redhat.com>',NULL),('<1360166729.2432.116.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 11:05:29',-18000,'2013-02-06 16:05:29',NULL,'[openstack-dev] Copyright guidance','On Tue, 2013-02-05 at 16:12 -0600, Anne Gentle wrote:\n> After patching with some updates around the new year [1] [2] [3], and\n> learning we needed more clarity around copyright statements in source code\n> files, I got guidance from Lisa Miller, one of the Foundation\'s corporate\n> attorneys.\n> \n> I\'ve created a new wiki page with this guidance at:\n> http://wiki.openstack.org/Documentation/Copyright\n> \n> Basically, when a new year rolls around, we don\'t need to update all\n> copyrights. When you update or add a doc file, it\'s fine to add the year.\n> Generally leave copyright statements in place, and add your own if you feel\n> so led. All references to \"OpenStack LLC\" can be changed to \"OpenStack\n> Foundation\" because the copyright was transferred when the new entity was\n> created.\n> \n> I think the wiki page answers other questions you may have but feel free to\n> ask questions as you update files. We don\'t need an overarching guidance\n> from the TC about the contents of the headers, individual PTLs can decide,\n> but please do adhere to the guidelines for updates.\n\nThanks Anne, this all makes sense to me.\n\nThere\'s a tiny potential source of confusion here, though. The way the\n\"OpenStack LLC notice\" section is worded, I think someone reading\nquickly might think they should *add* a OpenStack Foundation copyright\nnotice to all files.\n\nThat\'s not the case - the only copyright the Foundation will have over\ncontent will be (a) work that was done by Rackspace employees and the\ncopyright assigned to its subsidiary, OpenStack LLC and (b) work done by\nOpenStack Foundation employees.\n\nCheers,\nMark.\n\n\n\n','<CAD0KtVHZqi4oTbff7aAhYOmB_rM8Rer4FcJDFQwwg0ba-CKXJw@mail.gmail.com>',NULL),('<1360167521.2432.119.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 11:18:41',-18000,'2013-02-06 16:18:41',NULL,'[openstack-dev] RFC: Classnames in config parameters harmful to\n	users / upgrades','On Wed, 2013-02-06 at 16:10 +0000, Daniel P. Berrange wrote:\n> On Wed, Feb 06, 2013 at 10:46:52AM -0500, Mark McLoughlin wrote:\n> > On Wed, 2013-02-06 at 15:22 +0000, Daniel P. Berrange wrote:\n> > > The only way we can do this is if we do *NOT* require the use of\n> > > classnames in config parameters. Instead we should treat all these\n> > > config parameters as being more like enumerations, and map those to\n> > > classnames internally\n> > > \n> > > eg for the compute_driver instead of having the user set\n> > > \n> > >   compute_driver=nova.virt.libvirt.LibvirtDriver\n> > > \n> > > they would do\n> > > \n> > >   compute_driver=libvirt \n> > \n> > I think there\'s already good consensus on this and the idea is to use\n> > entry points and stevedore to achieve it.\n> > \n> > See:\n> > \n> >   https://blueprints.launchpad.net/nova/+spec/entrypoints-plugins\n> >   https://review.openstack.org/11027\n> >   https://review.openstack.org/15030\n> \n> Heh, I\'ve even seen that blueprint before, but it was hard to understand\n> just what it was on about. A etherpad transcript of a conversation that\n> you weren\'t present for, doesn\'t make a nice design doc for blueprint :-(\n> \n> > The end result is exactly that\n> > \n> >   compute_driver=libvirt\n> > \n> > will work, along with backwards compat for the original name.\n> > \n> > It just needs to be resurrected and finished off.\n> \n> Indeed, it looks like that is definitely something to have as a\n> priority item. Even if those patches were resurrected it looks\n> like quite alot more work is needed, give that they only tackle\n> 3 out of 44+ config parameters!\n> \n> Do we have any official position on config file upgrade support\n> at this time ?  It would be helpful to reviewers if they could\n> clearly identify whether a proposed config change is acceptable\n> or not from an upgrade POV, since currently people are holding\n> different changes to different standards before approval\n\n\"Official position\", heh.\n\nI\'d say that we should not be changing configuration options in\nincompatible ways without a deprecation period (of a release cycle)\nunless we\'re talking about a really obscure config option that is highly\nunlikely to have been used by real users.\n\nGot examples of where we didn\'t follow that general rule?\n\nCheers,\nMark.\n\n\n\n','<20130206161028.GX17014@redhat.com>',NULL),('<1360168058.18709.46.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 10:27:38',-21600,'2013-02-06 16:27:38',NULL,'[openstack-dev] Hardcoding of requests in client','On Wed, 2013-02-06 at 10:49 -0500, Chuck Short wrote:\n> I would like to propose a transition to allow at least requests 1.1 \n> since that is the latest version according to pypi and most linux \n> distros will be migrating to that sooner or later.\n> \n> Thoughts comments, flaming arrows?\n\nMy only comment is that, as I understand it, requests 0.9 and requests\n1.0 are incompatible interfaces, meaning that this transition will\nlikely entail more than just updating the pip-requires.  That said, I\'m\nall for allowing the use of the latest version of our dependencies\nwherever possible, as it does simplify supporting client usage on the\nlatest systems?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51127B87.2000708@canonical.com>',NULL),('<1360173086.74626.YahooMailNeo@web163804.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 09:51:26',-28800,'2013-02-06 17:51:26',NULL,'[openstack-dev] Code Submitted for Volume Encryption','We have submitted code to encrypt volumes.? The code is currently under review.? We are hoping to get accepted into the Grizzly release and would appreciate any feedback or tips to help us do that.? This is our first time trying to submit code.\n\nThe blue print for this can be found at https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes.? The specification can be found at http://wiki.openstack.org/VolumeEncryption.\n\nThe specification contains instructions on how to demonstrate volume encryption.? This way you can try it out if you like.\n\nWe do have a dependency between our nova commits and our horizon commits.? We do not know how to list this dependency on the review.? Does anyone know if there is a way to do this?\n\n-Nate\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/a8e26f12/attachment.html>\n\n',NULL,NULL),('<1360176692.097116235@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 13:51:32',-18000,'2013-02-06 18:51:32',NULL,'[openstack-dev] RFC: Classnames in config parameters harmful to\n	users / upgrades','\nThis is a very good point.\n \n+1 to accepting an enum or classname, unless there is an even better solution.\n \nHow do we currently handle the mapping of extensions that are turned on or off?\n \n-Alex\n \n-----Original Message-----\nFrom: \"Anne Gentle\" <anne at openstack.org>\nSent: Wednesday, February 6, 2013 1:26pm\nTo: \"Daniel P. Berrange\" <berrange at redhat.com>, \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] RFC: Classnames in config parameters harmful to users / upgrades\n\n\n\n\n\n\n\n\nOn Wed, Feb 6, 2013 at 9:22 AM, Daniel P. Berrange <[mailto:berrange at redhat.com] berrange at redhat.com> wrote:\nNova (and most other OpenStack components) have an ever increasing\n number of configuration parameters which accept classnames.\n Obviously, we\'re doing this to make it possible to plug in custom\n implementations of various interfaces, which is great.\n\n There are two downsides to this\n\n - The user has to know about obscure, often undocumented, python\n module names.\n\n\nThanks for shining a light on this particular difficulty. While we now have a sample nova.conf with descriptions, any use of and changes to class names in both nova and quantum have caused headaches for users. And doc bugs too.\n- Any time we rename a class, or refactor code possibly deleting\n or merging classes, we break the end config file upon upgrade.\n\n The first point is a mere usability matter, but the second point\n is a serious deployment issue IMHO, which can only get worse as\n usage of OpenStack increases & people expect more stability and\n consistency across upgrades.\n\n Historically code changes have been pretty fast & loose config\n parameters, arbitrarily changing them at any time for any reason.\n AFAIK there are no formal rules defined about changing config\n paramaters, but in some of the recent changes I\'ve submitted\n which involved config changes, reviewers wanted backwards compat\n to be maintained. The result that when renaming, or obsoleting\n existing classses we\'re having to keep around stubs for the old\n classes to avoid breaking user config files. This is not a good\n approach for long term maintainability of the codebase.\n\n IMHO the core issue here is that by using classnames in config\n parameters we are exposing what we (developers) generally consider\n to be internal/private implementation details to the end user. End\n user expectations wrt upgrades are thus restricting what we can do\n with our internal implementations.\n\n I don\'t think it is acceptable to have a situation where configuration\n file parameters restrict what we can do in terms of re-arranging /\n refactoring our codebase. Provided we maintain the same featureset\n compatibility, we should be free todo any code refactoring we desire.\n\n The only way we can do this is if we do *NOT* require the use of\n classnames in config parameters. Instead we should treat all these\n config parameters as being more like enumerations, and map those to\n classnames internally\n\nI would completely support this and wish I had dev resources to put behind the effort. Is there a group who wants to work on this? \n\n\n44 isn\'t bad out of over 600 I might add.\nLet me help any way I can.\n\nAnne\n\n eg for the compute_driver instead of having the user set\n\n compute_driver=nova.virt.libvirt.LibvirtDriver\n\n they would do\n\n compute_driver=libvirt\n\n and internally nova would resolve this to the classname. Obviously the\n key issue is how we deal with the mapping of enum values to classnames.\n If we just had a table of mappings in the codebase, then it ceases to\n be possible for people to drop in custom out-of-tree implementations\n from 3rd parties.\n\n One option to this would be to allow the config parameters to take a\n enum value, or a classname. We would declare the enum values as\n \"stable, guaranteed upgrade compatibility\", and the use of classnames\n as \"liable to break on upgrade\". The intent would be that all our\n documentation / tools like devstack, etc would use the short enum\n names by default. The only people who would ever use classnames for the\n config parameters, would be those who need to plug in a 3rd party impl\n that is not part of the main openstack codebase.\n\n A different option would be to only ever allow for enum values in the\n config parameter, but define a way for 3rd parties to register their\n new impls. For example, you could have them do something like\n\n # cd /usr/share/openstack/nova/configmap/compute_driver\n # echo \"nova.virt.libvirt.LibvirtDriver\" > libvirt\n\n as a way to register that the \'compute_driver\' parameter gets a new\n valid option of \'libvirt\' mapping to the classname\n \"nova.virt.libvirt.LibvirtDriver\"\n\n Regards,\n Daniel\n\n [1] In fact Nova currently has at least 44 classname based options\n\n $ grep \'nova\\.\' etc/nova/nova.conf.sample  | grep -v \"# \" | sort | sed -e \'s/#//\'\n allowed_rpc_exception_modules=nova.openstack.common.exception,nova.exception,cinder.exception,exceptions\n cert_manager=nova.cert.manager.CertManager\n compute_api_class=nova.compute.api.API\n compute_manager=nova.compute.manager.ComputeManager\n compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n compute_stats_class=nova.compute.stats.Stats\n consoleauth_manager=nova.consoleauth.manager.ConsoleAuthManager\n console_driver=nova.console.xvp.XVPConsoleProxy\n console_manager=nova.console.manager.ConsoleProxyManager\n db_driver=nova.db\n default_scheduler_driver=nova.scheduler.chance.ChanceScheduler\n driver=nova.cells.rpc_driver.CellsRPCDriver\n driver=nova.virt.baremetal.pxe.PXE\n floating_ip_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver\n instance_dns_manager=nova.network.noop_dns_driver.NoopDNSDriver\n l3_lib=nova.network.l3.LinuxNetL3\n libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtBridgeDriver\n libvirt_volume_drivers=iscsi=nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver,local=nova.virt.libvirt.volume.LibvirtVolumeDriver,fake=nova.virt.libvirt.volume.LibvirtFakeVolumeDriver,rbd=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,sheepdog=nova.virt.libvirt.volume.LibvirtNetVolumeDriver,nfs=nova.virt.libvirt.volume_nfs.NfsVolumeDriver\n linuxnet_interface_driver=nova.network.linux_net.LinuxBridgeInterfaceDriver\n manager=nova.cells.manager.CellsManager\n manager=nova.conductor.manager.ConductorManager\n metadata_manager=nova.api.manager.MetadataManager\n monkey_patch_modules=nova.api.ec2.cloud:nova.notifier.api.notify_decorator,nova.compute.api:nova.notifier.api.notify_decorator\n network_api_class=nova.network.api.API\n network_driver=nova.network.linux_net\n network_manager=nova.network.manager.VlanManager\n osapi_compute_extension=nova.api.openstack.compute.contrib.standard_extensions\n power_manager=nova.virt.baremetal.ipmi.IPMI\n quota_driver=nova.quota.DbQuotaDriver\n rpc_backend=nova.openstack.common.rpc.impl_kombu\n rpc_zmq_matchmaker=nova.openstack.common.rpc.matchmaker.MatchMakerLocalhost\n scheduler_available_filters=nova.scheduler.filters.all_filters\n scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n scheduler_host_manager=nova.scheduler.host_manager.HostManager\n scheduler_manager=nova.scheduler.manager.SchedulerManager\n scheduler=nova.cells.scheduler.CellsScheduler\n scheduler_weight_classes=nova.scheduler.weights.all_weighers\n security_group_api=nova.compute.api.SecurityGroupAPI\n security_group_handler=nova.network.sg.NullSecurityGroupHandler\n sqlite_db=nova.sqlite\n vif_driver=nova.virt.baremetal.vif_driver.BareMetalVIFDriver\n volume_api_class=nova.volume.cinder.API\n volume_driver=nova.virt.baremetal.volume_driver.LibvirtVolumeDriver\n xenapi_vif_driver=nova.virt.xenapi.vif.XenAPIBridgeDriver\n\n --\n |: [http://berrange.com] http://berrange.com -o-    [http://www.flickr.com/photos/dberrange/] http://www.flickr.com/photos/dberrange/ :|\n |: [http://libvirt.org] http://libvirt.org -o-             [http://virt-manager.org] http://virt-manager.org :|\n |: [http://autobuild.org] http://autobuild.org -o-         [http://search.cpan.org/~danberr/] http://search.cpan.org/~danberr/ :|\n |: [http://entangle-photo.org] http://entangle-photo.org -o-       [http://live.gnome.org/gtk-vnc] http://live.gnome.org/gtk-vnc :|\n\n _______________________________________________\n OpenStack-dev mailing list\n[mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n[http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/6b9cb056/attachment.html>\n\n','<CAD0KtVHirw=ucUffkdzKqrZavf5ncXemA=ERyAewRkdCWmxW0A@mail.gmail.com>',NULL),('<1360184527.587520252@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 16:02:07',-18000,'2013-02-06 21:02:07',NULL,'[openstack-dev] [Quantum] Question on unit tests','\nHey Sal,\n \nI\'m not a Quantum dev but I may have some ideas. I\'m sure most everyone knows that a lot of the projects have moved to using testr as the test runner in order to execute tests in parallel. Since that seems like something you guys are not moving to right away then maybe there is a quicker solution.\n \nHave you seen \'eatmydata\' (http://www.makelinux.net/man/1/E/eatmydata) I use it when running tests and it cuts the time in half. Just \'apt-get install eatmydata\' if you\'re on ubuntu.\n \n-Alex\n \n-----Original Message-----\nFrom: \"Salvatore Orlando\" <sorlando at nicira.com>\nSent: Wednesday, February 6, 2013 3:21pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Quantum] Question on unit tests\n\n\n\nHi,\n\nAs some of you have noticed, the number of unit tests arose to above\n3,000 with recent merges.\nThe XML support is adding most of them, by doing something similar to\nwhat the API tests for Quantum v1 did (execute the whole test cases\nwith both format).\nWhile I understand and support this approach, there are two things to be noted:\n- Unit test execution times have more than doubled\n- With Quantum v2 we adopted a slightly different approach, by\nseparating API and DB tests. The formers tests (that we have for the\ncore API as well as many extensions) are the ones aimed at validating\ncorrect serialization/deserialization. If we keep following this\napproach, we might be able to save a lot of format-specific unit tests\nfor DB logic. From my perspective I don\'t think we will be losing any\ncoverage - but I might be missing something fundamental.\n\nI recall Aaron and BobK in recent posts were suggesting to move to\nparallel testing; this one of the first things we should address in\nHavana. In the meanwhile, let me know if you think we can do something\nto reduce the amount of resources used by unit tests.\n\nI am also noticing that the memory leaks which were reduced a lot\nduring G-1 are hitting again, on low memory workers (2Gb); probably no\nnew leak has been introduced, it\'s just that the effect of the few\nones which were left it\'s now being felt more.\n\nSalvatore\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130206/ced2d1f5/attachment.html>\n\n','<CAGR=i3jcBZXJtgQ_dXEM6HGatvDAOsGDtat-P72=dF4_MLRwcw@mail.gmail.com>',NULL),('<136024341.7424799.1393308407993.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 01:06:47',-18000,'2014-02-25 06:06:47',NULL,'[openstack-dev] [neutron] Significance of subnet_id for LBaaS Pool','Hi All,\n\n\'subnet_id\' attribute of LBaaS Pool resource has been documented as \"The network that pool members belong to\"\n\nHowever, with \'HAProxy\' driver, it allows to add members belonging to different subnets/networks to a lbaas Pool.  \n\nIt also allows to create VIP from a separate subnet than the pool. I could see there is a validation in horizon that restricts vip to the subnet of the pool. \n\nMy understanding is that a Pool with a specific subnet, would allow members from the same  subnet and the VIP would be also of the same subnet.\n\nCan someone please help clarify the design consideration?\n\n\n\n[stack at devstack-rabi devstack]$ neutron lb-pool-create --name http-pool --lb-method ROUND_ROBIN --protocol HTTP --subnet-id 547f99da-7dd5\n[stack at devstack-rabi devstack]$ neutron lb-pool-list\n+--------------------------------------+-----------+----------+-------------+----------+----------------+--------+\n| id                                   | name      | provider | lb_method   | protocol | admin_state_up | status |\n+--------------------------------------+-----------+----------+-------------+----------+----------------+--------+\n| 8235339a-4158-468b-9377-5ece0826e7a6 | http-pool | haproxy  | ROUND_ROBIN | HTTP     | True           | ACTIVE |\n+--------------------------------------+-----------+----------+-------------+----------+----------------+--------+\n\n[stack at devstack-rabi devstack]$ neutron lb-member-create --address 10.0.0.2 --protocol-port 80 http-pool\nCreated a new member:\n+--------------------+--------------------------------------+\n| Field              | Value                                |\n+--------------------+--------------------------------------+\n| address            | 10.0.0.2                             |\n| admin_state_up     | True                                 |\n| id                 | e9515a09-1a95-4875-b45f-3b2bab559eb8 |\n| pool_id            | 8235339a-4158-468b-9377-5ece0826e7a6 |\n| protocol_port      | 80                                   |\n| status             | PENDING_CREATE                       |\n| status_description |                                      |\n| tenant_id          | c46ae2b06ee54d06828c346f77fb5628     |\n| weight             | 1                                    |\n+--------------------+--------------------------------------+\n[stack at devstack-rabi devstack]$ neutron lb-member-create --address 10.10.0.2 --protocol-port 80 http-pool\nCreated a new member:\n+--------------------+--------------------------------------+\n| Field              | Value                                |\n+--------------------+--------------------------------------+\n| address            | 10.10.0.2                            |\n| admin_state_up     | True                                 |\n| id                 | 4f4ecd2d-b734-4a98-95ac-06d9d09ddb62 |\n| pool_id            | 8235339a-4158-468b-9377-5ece0826e7a6 |\n| protocol_port      | 80                                   |\n| status             | PENDING_CREATE                       |\n| status_description |                                      |\n| tenant_id          | c46ae2b06ee54d06828c346f77fb5628     |\n| weight             | 1                                    |\n+--------------------+--------------------------------------+\n[stack at devstack-rabi devstack]$ neutron lb-member-list --sort-key address --sort-dir asc\n+--------------------------------------+-----------+---------------+--------+----------------+--------+\n| id                                   | address   | protocol_port | weight | admin_state_up | status |\n+--------------------------------------+-----------+---------------+--------+----------------+--------+\n| 4f4ecd2d-b734-4a98-95ac-06d9d09ddb62 | 10.10.0.2 |            80 |      1 | True           | ACTIVE |\n| e9515a09-1a95-4875-b45f-3b2bab559eb8 | 10.0.0.2  |            80 |      1 | True           | ACTIVE |\n+--------------------------------------+-----------+---------------+--------+----------------+--------+\n\n\n[stack at devstack-rabi devstack]$ neutron lb-vip-create --name http-vip --protocol-port 80 --protocol HTTP --subnet-id b1557101-c8f1-415a-846d-6d165a8e8fc2 8235339a-4158-468b-9377-5ece0826e7a6\n\nCreated a new vip:\n+---------------------+--------------------------------------+\n| Field               | Value                                |\n+---------------------+--------------------------------------+\n| address             | 10.10.0.4                            |\n| admin_state_up      | True                                 |\n| connection_limit    | -1                                   |\n| description         |                                      |\n| id                  | 409e72e6-5a3c-4a7b-be0b-6a8784193dfc |\n| name                | http-vip                             |\n| pool_id             | 8235339a-4158-468b-9377-5ece0826e7a6 |\n| port_id             | 9dfc3a6f-4641-4f1d-835b-bda3aea9c6ce |\n| protocol            | HTTP                                 |\n| protocol_port       | 80                                   |\n| session_persistence |                                      |\n| status              | PENDING_CREATE                       |\n| status_description  |                                      |\n| subnet_id           | b1557101-c8f1-415a-846d-6d165a8e8fc2 |\n| tenant_id           | c46ae2b06ee54d06828c346f77fb5628     |\n+---------------------+--------------------------------------+\n[stack at devstack-rabi devstack]$ neutron lb-vip-list\n+--------------------------------------+----------+-----------+----------+----------------+--------+\n| id                                   | name     | address   | protocol | admin_state_up | status |\n+--------------------------------------+----------+-----------+----------+----------------+--------+\n| 409e72e6-5a3c-4a7b-be0b-6a8784193dfc | http-vip | 10.10.0.4 | HTTP     | True           | ACTIVE |\n+--------------------------------------+----------+-----------+----------+----------------+--------+\n   \n\n\nRegards,\nRabi Mishra \n\n\n\n','<386662758.7410972.1393304292204.JavaMail.zimbra@redhat.com>',NULL),('<1360255717.6408.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-07 11:48:37',-18000,'2013-02-07 16:48:37',NULL,'[openstack-dev] Copyright guidance','On Wed, 2013-02-06 at 17:22 -0600, Monty Taylor wrote:\n> \n> On 02/06/2013 10:40 AM, Sandy Walsh wrote:\n> > \n> > \n> >> On Tue, 2013-02-05 at 16:12 -0600, Anne Gentle wrote:\n> >>> After patching with some updates around the new year [1] [2] [3], and\n> >>> learning we needed more clarity around copyright statements in source code\n> >>> files, I got guidance from Lisa Miller, one of the Foundation\'s corporate\n> >>> attorneys.\n> >>>\n> >>> I\'ve created a new wiki page with this guidance at:\n> >>> http://wiki.openstack.org/Documentation/Copyright\n> >>>\n> >>> Basically, when a new year rolls around, we don\'t need to update all\n> >>> copyrights. When you update or add a doc file, it\'s fine to add the year.\n> >>> Generally leave copyright statements in place, and add your own if you feel\n> >>> so led. \n> > \n> > Timely, we were just having this conversation internally.\n> > \n> > How do I define what a \"substantial\" change is in source code when\n> > deciding whether to update the year or not?\n> \n> Fun question. Luckily - it\'s a judgement call. AIUI (IANAL) the question\n> is the same as if the code contributed itself is copyrightable in its\n> own right. It might be related to code size - but I _think_ the easier\n> way to think about it is whether or not there is an actual thought in there.\n\nYeah, that\'s pretty much my understanding.\n\n> PS. I can easily make a script which replaces all OpenStack LLC\n> references with OpenStack Foundation references ... should I?\n\nI think it makes sense - it makes it clear that this is about the owner\nof the copyright of existing work changing rather than the OpenStack\nFoundation owning the copyright to new work.\n\nCheers,\nMark.\n\n\n\n','<5112E5A8.7040807@inaugust.com>',NULL),('<1360269151.6408.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-07 15:32:31',-18000,'2013-02-07 20:32:31',NULL,'[openstack-dev] Use of local()','On Thu, 2013-02-07 at 12:15 -0800, Joe Gordon wrote:\n> i18n support prevents us from doing something like:\n> \n> \n> _(\"The server with id %()s has no key %s\" % (s_id, m_key))\n> \n> Because translations my reverse the sentence structures.  So the two\n> options are:\n> \n> \n> _(\"The server with id %(s_id)s has no key %(m_key)s\" % locals())\n> \n> and\n> \n> \n> msg = _(\"The server with id %(s_id)s has no key %(m_key)s\")\n> LOG.error(msg % {\"s_id\": \"1234\", \"m_key\": \"imageId\"})\n> \n> \n> https://github.com/openstack/nova/blob/master/HACKING.rst#internationalization-i18n-strings\n\nI really disklike the use of locals().\n\nA nicer option is:\n\n  _(\"The server with id %(s_id)s has no key %(m_key)s\") % dict(s_id=\"1234\", m_key=\"imageId\")\n\nCheers,\nMark.\n\n> On Thu, Feb 7, 2013 at 11:49 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > I actually prefer the use of locals()... I find it cleaner that\n> > specifying huge dictionaries to supply for string interpolation.\n> >\n> > -jay\n> >\n> > On 02/07/2013 02:33 PM, Andrew Laski wrote:\n> > > On 02/07/13 at 10:23am, Nachi Ueno wrote:\n> > >> Hi folks\n> > >>\n> > >> I wanna ask the opinion of use of local()\n> > >> This function is mainly used for logging because of no need to specify\n> > >> actual parameters.\n> > >>\n> > >> However, the variable ,which code checker says it is not used, is used\n> > >> by local() sometimes.\n> > >> so I prefer not to use local() .\n> > >> I also believe to specify used parameter improves readability of the\n> > code.\n> > >\n> > > I agree.  I prefer the explicitness of passing variables to string\n> > > interpolation, and my style checker also picks up the variables which it\n> > > thinks are not used.\n> > >\n> > > I would support a check in hacking.py for this in Nova but personally\n> > > don\'t think reviewers should spend time worrying about it.  Which means\n> > > that I think it\'s an uphill battle for projects without something like\n> > > hacking.py.\n> > >\n> > >\n> > >>\n> > >> I appreciate if I could get the opinion on the community.\n> > >>\n> > >> Thanks\n> > >> Nachi\n...\n\n\n\n','<CAKe5d-SKuKmLGLq658C=OXZvFJBn2JPDBzumgHoBxCDriZ9iXg@mail.gmail.com>',NULL),('<1360439999.28707.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-09 14:59:59',-18000,'2013-02-09 19:59:59',NULL,'[openstack-dev] unit tests','Hi John,\n\nOn Sat, 2013-02-09 at 12:15 -0700, John Griffith wrote:\n> We seem to be going down a path of requiring more and more infrastructure\n> and reliance from modules inside of the respective projects code base, and\n> lately (the most annoying thing to me) is actually requiring the\n> installation of the project and it\'s services in order for our unit tests\n> to run.\n\nGot an example?\n\nCheers,\nMark.\n\n\n\n','<CA+qL3LWrzGD=t5xhnJ=PrxmsO+Qr5RSoVMUau0EXQj2Ue4zMLw@mail.gmail.com>',NULL),('<1360441046.28707.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-09 15:17:26',-18000,'2013-02-09 20:17:26',NULL,'[openstack-dev] Please do use PGP and PGP signed tags!','Hi Thomas,\n\nOn Sun, 2013-02-10 at 01:41 +0800, Thomas Goirand wrote:\n> As you may know, I am the person doing the packaging of Openstack in\n> Debian. So uploading stuff in Debian is my responsibility. I\'ve been\n> trying to shout to everyone that they should be using PGP signed tags on\n> Github, but the message doesn\'t seem to be received well enough, even\n> though core repositories are signed (I could check that ttx signature is\n> in all core projects, so we\'re safe here). But that\'s not truth for many\n> smaller python modules.\n\nCare to share specific examples?\n\nThanks,\nMark.\n\n\n\n','<51168A62.6030203@debian.org>',NULL),('<1360446019.28707.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-09 16:40:19',-18000,'2013-02-09 21:40:19',NULL,'[openstack-dev] Please do use PGP and PGP signed tags!','On Sun, 2013-02-10 at 08:21 +1100, Michael Still wrote:\n> On Sun, Feb 10, 2013 at 4:41 AM, Thomas Goirand <zigo at debian.org> wrote:\n> > Hi everyone!\n> >\n> > As you may know, I am the person doing the packaging of Openstack in\n> > Debian. So uploading stuff in Debian is my responsibility. I\'ve been\n> > trying to shout to everyone that they should be using PGP signed tags on\n> > Github, but the message doesn\'t seem to be received well enough, even\n> > though core repositories are signed (I could check that ttx signature is\n> > in all core projects, so we\'re safe here). But that\'s not truth for many\n> > smaller python modules.\n> \n> I had a play with this, but I haven\'t had a lot of luck. It turns out\n> to sign a commit you can just do:\n> \n>   git commit -a --gpg-sign\n> \n> But the signature doesn\'t appear in git log output unless you use the\n> --show-signature flag. I _think_ that means it wont end up getting\n> sent to gerrit, so me signing locally isn\'t the most useful thing\n> ever.\n> \n> Am I misunderstanding something?\n\nThe question is about signing tags. As part of releasing modules, we do\ne.g.:\n\n  $> git tag -s 2012.2.3\n  $> git push gerrit tag 2012.2.3\n\nIt sounds like we\'ve failed to include \'-s\' when tagging some projects\nin the past.\n\nCheers,\nMark.\n\n\n\n','<CAEd1pt5KWUQgX-KjYLhFCbdL=f_bD61mp3Wp4VyuSj9xXp=_Ng@mail.gmail.com>',NULL),('<1360469226.28707.22.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-09 23:07:06',-18000,'2013-02-10 04:07:06',NULL,'[OpenStack Foundation] Individual Member Election Statistics\n (January 2013)','On Sat, 2013-02-09 at 19:30 +0000, Tim Bell wrote:\n> \n> I strongly object to the assertion that employment history should be\n> considered in the way you propose. Having worked with Lauren closely in the\n> past year, I am surprised at the implication behind your statement.\n\nTo be fair to Lloyd, I read his comment as \"some people might label\nLauren as a Rackspace stooge but looking at the Rackspace voting stats\nwould show how diverse her support is\".\n\ni.e. I actually read it as a positive comment and agree with the\nsentiment.\n\nIt\'s important to counter any FUD about Rackspace influence over the\nFoundation but I wouldn\'t like to see a single individual subjected to\nmore scrutiny than other candidates.\n\n> I worked for IBM for 15 years and found this an excellent experience, I\'ve\n> moved on to other activities, have good relationships with former colleagues\n> and fond memories but I was elected to represent the individuals of the\n> foundation. \n> \n> I am sure that all other individual directors feel the same.\n\nI feel very strongly that I\'m representing the Individual Members rather\nthan my employer, if that\'s what you mean.\n\nCheers,\nMark.\n\n> From: Lloyd Dewolf [mailto:lloydostack at gmail.com] \n> Sent: 08 February 2013 20:37\n> To: Mark McLoughlin\n> Cc: Vincent Untz; foundation at lists.openstack.org\n> Subject: Re: [OpenStack Foundation] Individual Member Election Statistics\n> (January 2013)\n> \n>  \n> \n> \n> \n> I\'m surprised Lauren Sell\'s results were not also run against Rackspace --\n> I\'m hopeful that would show the diversity of her base.\n> \n> \n> I\'m thankful that Mark Collier agreed to drop out of the race right before\n> voting began as two Foundation executives on the board in \"Individual\" spots\n> would have been a huge distraction to the success of the Foundation in 2013.\n> \n> \n> \n> --\n> \n> @lloyddewolf\n> http://www.pistoncloud.com/ \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5A86779AD@CERNXCHG01.cern.ch>',NULL),('<1360469571.28707.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-09 23:12:51',-18000,'2013-02-10 04:12:51',NULL,'[openstack-dev] Bumping eventlet to 0.12.0+','On Sat, 2013-02-09 at 22:56 -0500, Eric Windisch wrote:\n> As such, contributions are NOT under the Apache license, but are\n> licensed under the CLA to the OpenStack Foundation and then relicensed\n> by the foundation under the Apache license.\n\nThe CLAs\' terms is very similar to the terms of the Apache License 2.0.\nI basically think of the CLA as \"I submit my contribution to OpenStack\nunder the terms of the Apache License 2.0\". But IANAL\n\n>   As such, I\'m not entitled to actually submit MIT licensed code into\n> the project (which very well may be a good thing).\n\nThat is probably true, but I\'m not 100% sure.\n\nIMHO, the question on 0.12.0 is to distro maintainers - how disruptive\nis the requirement for 0.12.0 in Grizzly?\n\nIf it is disruptive, we can punt on it until Havana and recommend to\nfolks they use 0.12.0 if they want to use the zmq driver.\n\nCheers,\nMark.\n\n\n\n','<1F76F38B86CE42208828BE1185EA5EA7@cloudscaling.com>',NULL),('<1360523933.801621638@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-10 14:18:53',-18000,'2013-02-10 19:18:53',NULL,'[openstack-dev] unit tests','\n\nUnit tests I\'ve seen in a number of OpenStack projects have been significantly less than perfect and I think we all know this (I hope).\n \nWe need to make a change ASAP because it is only going to get harder. I don\'t think just saying it\'s too hard and continuing to do as we currently do is going to do us any good in the long run. We must create a good system of enforcement when it comes to writing good unittests and having functional test coverage.\n \nI\'m not sure what the most effective course of action here is but I do know that we need to get all of the reviewers on the same page and enforcing some guidelines. In the past we have had resources like  [http://wiki.openstack.org/SmallTestingGuide] http://wiki.openstack.org/SmallTestingGuide. Perhaps we need to expand on the definition of good testing habits in OpenStack, come up with a way to promote awareness, enforce guidelines, and fix old and bloated tests.\n \nAnyone have any thoughts on some actions we can take? I\'d love to talk about this at the summit but hopefully we can make some improvements in the mean time?\n \n-Alex\n \n-----Original Message-----\nFrom: \"John Griffith\" <john.griffith at solidfire.com>\nSent: Sunday, February 10, 2013 12:37pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] unit tests\n\n\n\n\n\nOn Sun, Feb 10, 2013 at 3:03 AM, Huang Zhiteng <[mailto:winston.d at gmail.com] winston.d at gmail.com> wrote:\nJohn, Monty, Mark,\n\n I think one example is unit tests involving test case against entry\n points which requires installation.  I guess that\'s John\'s most\n annoying thing.\n\n For this special case, I think switching from run_tests.sh to tox (or\n even ditching run_tests.sh) is the right solution.  I\'m working on a\n patch for Cinder to make this change\n ([https://review.openstack.org/#/c/21597/] https://review.openstack.org/#/c/21597/).   It\'s not ready yet as I\n met some difficulty with coverage tests, but as a starter, you can try\n functionality other than coverage tests.\n\n\n\n On Sun, Feb 10, 2013 at 5:23 AM, Monty Taylor <[mailto:mordred at inaugust.com] mordred at inaugust.com> wrote:\n >\n >\n > On 02/09/2013 01:59 PM, Mark McLoughlin wrote:\n >> Hi John,\n >>\n >> On Sat, 2013-02-09 at 12:15 -0700, John Griffith wrote:\n >>> We seem to be going down a path of requiring more and more infrastructure\n >>> and reliance from modules inside of the respective projects code base, and\n >>> lately (the most annoying thing to me) is actually requiring the\n >>> installation of the project and it\'s services in order for our unit tests\n >>> to run.\n >>\n >> Got an example?\n >\n > Yes. I\'d also like an example.\n >\n > FWIW - I agree with the sentiment that our unittests should be simple to\n > run and that cross-project testing should be the purview of integration\n > tests.\n >\n > Monty\n >\n > _______________________________________________\n > OpenStack-dev mailing list\n > [mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n > [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\n Regards\n Huang Zhiteng\n\n\n\n _______________________________________________\n OpenStack-dev mailing list\n[mailto:OpenStack-dev at lists.openstack.org] OpenStack-dev at lists.openstack.org\n[http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nSorry for dropping the email then going MIA.\n\nThere are multiple things I wanted to get some thought around, I\'ll start with what I believe are the easier ones first:\n\n1. I don\'t believe that we should require the installation of Cinder to run the Cinder unit tests\n This to me clearly crosses the line in to functional or integration territory, and moving it in to\n a venv (tox, or otherwise) doesn\'t address my issue with it.  Sorry Winston but right now 21597 does \n exactly what I don\'t want.\n\n Today for Cinder I have the test-requires packages and other required items all installed on my laptop and other machines.  \n I can clone the Cinder repo and run all of the tests using \'run_tests.sh -N\' in less than a minute.  Lately unit tests are coming\n online that depend on the egg info being installed as Winston touched on.\n\n2. I haven\'t figured out what Tox versus Nose buys me in Cinder.\n I understand in Nova and others there may be advantages due to parallelism and some other enhancements, but in my\n case my test cycle time has actually increased by having to install the tox venv when I do a fresh clone, and in the case\n of Nova, I *think* my tests are running a bit faster but really I don\'t feel that I actually know what\'s being run and the results.\n\nThese first two items are the main things I\'m looking for feed-back from folks on, the rest of this email is more around test philosophy, and I don\'t think I\'m interested in trying to come to an agreement or change on things here.  I\'d just like to raise some awareness, if anybody is interested in pursuing some of this, maybe we can all get together and chat at the summit.  If people think it\'s ridiculous that\'s fine too.\n\n\nIn my mind you have unit tests, functional tests and integration tests.  Unit tests to me aren\'t designed to find bugs, or test for regressions.  They\'re specifically to test a unit of code that I\'ve written, and the tests should only depend on that unit of code that I\'m intending to test.  \n\nSo for example if I write a Cinder driver called \'super_cool_driver\', I have a single file of unit tests that tests super_cool_driver methods and NOTHING else.  It has no dependencies on any other files/modules in the Cinder project.  It\'s only purpose is to make sure that super_cool_driver\'s behaviours are in fact what I intended and expect.  It also ensures that somebody later doesn\'t change those behaviours inadvertently.\n\nTesting the interaction with other Cinder modules should be done through functional tests.  This is where devstack exercises would come in to play.  Currently I don\'t think we put enough emphasis here, when somebody submits a bug fix for something we often say \"You need a unit test to catch this sort of thing in the future\", maybe that\'s true in some cases but I\'d argue that we should be saying \"You need a test in devstack or tempest to catch this in the future\".  One of the main reasons unit tests aren\'t very helpful here IMO is that in most cases a bug results from a refactor or enhancement in the code.  Most of the time when folks make these enhancements they also modify the unit test to behave the way they \"expect\" it to and think it should.  The result is they just create a unit test that verifies the incorrect behaviour.\n\nAnother point that came up; we have \"fake\" volume objects and such spread out and created in multiple places throughout the Cinder unit tests.  Some folks use the fake class that\'s set up, and most create a fake in their setup, or on the fly in the test case they\'re writing.  This creates a bit of a problem if the volume object ever changes (you have to find every fake that\'s created and modify it, then modify any test that uses it etc etc).  It would be great if at some point in the future we had good fakes for things like volume objects, instance objects etc (sort of along the lines of what Robert mentioned, but I\'m not sure I\'m thinking of the same scope as he mentioned).\n\nAn example of this was recently Sean Dague asked me about test objects for Cinder (Volumes, Snapshots, Types etc), I was kinda surprised but we didn\'t have an existing set of updated fakes to represent these things.  Seems like it would be smart to have these things (both objects and DB entries) to use throughout the unit tests to provide consistency and make tests a bit more realistic, rather than just rolling your own fake object to fit the test your writing it for.\n\nThanks,\nJohn\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130210/426edb10/attachment.html>\n\n','<CA+qL3LWCvMkESC-EtSGK_q7wnLKdXsVBidZCk8hoxqAnHxZ3FQ@mail.gmail.com>',NULL),('<1360534641.28707.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-10 17:17:21',-18000,'2013-02-10 22:17:21',NULL,'[openstack-dev] How to make a change in openstack/common','On Mon, 2013-02-11 at 08:51 +1100, Michael Still wrote:\n> On Mon, Feb 11, 2013 at 8:43 AM, Day, Phil <philip.day at hp.com> wrote:\n> \n> > However this is my first time venturing into changing openstack/common ? so\n> > I?d appreciate some pointers on how to start.   I?m assuming that I start by\n> > pushing the change for review against\n> > https://github.com/openstack/oslo-incubator ? but it?s not clear to me what\n> > I then need to do before I can get that change into Nova so I can add the\n> > extra parameter to the call from conductor/manager.\n> \n> Yep, this is a two step process. First off send off a change against\n> openstack/oslo-incubator (the new name for common) with your change.\n> It then goes through the standard code review process. Then you need\n> to sync the change into nova and send a code review for that as well.\n> \n> The sync process is to use update.py from the oslo-incubator\n> repository, although you probably only want to sync the module you\n> changed.\n\nThis should all be covered by:\n\n  http://wiki.openstack.org/Oslo\n\nfeel free to improve if not.\n\nCheers,\nMark.\n\n\n\n','<CAEd1pt5VY3gkNeQsLiqDqvTMOuH9gzFbuSrsMQEHdT1cE3jLww@mail.gmail.com>',NULL),('<1360600059.18709.67.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-11 10:27:39',-21600,'2013-02-11 16:27:39',NULL,'[openstack-dev] unit tests','On Sat, 2013-02-09 at 14:59 -0500, Mark McLoughlin wrote:\n> On Sat, 2013-02-09 at 12:15 -0700, John Griffith wrote:\n> > We seem to be going down a path of requiring more and more infrastructure\n> > and reliance from modules inside of the respective projects code base, and\n> > lately (the most annoying thing to me) is actually requiring the\n> > installation of the project and it\'s services in order for our unit tests\n> > to run.\n> \n> Got an example?\n\nOne obvious example is this: at least half of the \"unit\" tests for the\nAPI extensions set up the entire WSGI stack for every single test, then\ntear it down at the end.  The other half at least use a more reasonable\nprocess of just calling the function being tested.\n\nThat said, I think the test suite should include functional tests, which\ndo things like setting up the WSGI stack and making sure everything\nworks together.  However, these functional tests don\'t need to be\nanywhere near as extensive as the unit tests.  My own preference for\ntesting some of my projects is to split the tests directory in two; the\n\"unit\" directory has all unit tests, which do exactly what John has\ndescribed, and the \"function\" directory has a handful of functional\ntests, as I describe here.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<1360439999.28707.0.camel@sorcha>',NULL);
INSERT INTO `messages` VALUES ('<1360605847.2400.23.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-11 10:04:07',-28800,'2013-02-11 18:04:07',NULL,'[openstack-dev] unit tests','On Sun, 2013-02-10 at 16:17 -0700, John Griffith wrote:\n> there have been patches submitted however that intentionally require\n> cinder to be installed, I\'ve let one go through and added a skip if\n> cinder not installed, and other\'s I\'ve pushed back and said\n> \'thanks but no thanks\".\n\nGot links? I\'m actually really curious to look at these examples to see\nhow the issue comes about\n\nCheers,\nMark.\n\n\n\n','<CA+qL3LXpg5s=yP1MFS4A4n4B+55md0NJN2WkXvNViVXW-M=N_w@mail.gmail.com>',NULL),('<1360774094.30235917@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-13 11:48:14',-18000,'2013-02-13 16:48:14',NULL,'[openstack-dev] [Nova] Unit tests','\nYou can do:\n./tools/with_venv.sh pip install -r tools/pip-requires\n./tools/with_venv.sh pip install -r tools/test-requires\n \nTo get any dependencies you might be missing, however, this will leave behind previous dependencies that are no longer required.\n \n-Alex\n \n-----Original Message-----\nFrom: \"Jean-Marc Saffroy\" <jean.marc.saffroy at scality.com>\nSent: Wednesday, February 13, 2013 10:40am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nCc: \"Sean Dague\" <sdague at linux.vnet.ibm.com>\nSubject: Re: [openstack-dev] [Nova] Unit tests\n\n\n\nOn 02/12/2013 04:09 PM, Sean Dague wrote:\n> Your venv is probably very old. Unfortunately the venv tools don\'t look\n> for freshness, just the existence of the venv.\n>\n> rm -rf .venv and rerun, and you\'ll be fine.\n\nI had to do exactly this last week, and it took over 40 minutes to \ndownload and rebuild the venv stuff.\n\nIs there a way to do it faster?\n\n\nJean-Marc\n\n>\n>      -Sean\n>\n> On 02/12/2013 08:38 AM, Gary Kotton wrote:\n>> Hi,\n>> Today I updated the code. When I try and run unit tests I get the\n>> following:\n>>\n>> garyk at linus:~/nova$ ./run_tests.sh\n>> Running `tools/with_venv.sh python setup.py testr --slowest\n>> --testr-args=\'--subunit  \'`\n>> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]\n>>     or: setup.py --help [cmd1 cmd2 ...]\n>>     or: setup.py --help-commands\n>>     or: setup.py cmd --help\n>>\n>> error: invalid command \'testr\'\n>>\n>> ----------------------------------------------------------------------\n>> Ran 0 tests in 0.193s\n>>\n>> OK\n>> cp: cannot stat `.testrepository/-1\': No such file or directory\n>>\n>> Any ideas?\n>> Thanks\n>> Gary\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130213/f12a0a04/attachment.html>\n\n','<511BB3F2.9020307@scality.com>',NULL),('<1360777588.61953.YahooMailNeo@web163801.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-13 09:46:28',-28800,'2013-02-13 17:46:28',NULL,'[openstack-dev] Volume Encryption','Our intent was not to limit which encryption algorithms to use or to propose a minimum standard.? We needed to pick a default implementation to use for the Grizzly release.? We did not have enough time to make the algorithm configurable, so we needed to pick a default for the release.\n\nIn the future we would like to support many different algorithms and key sizes.? We are imagining the user inputting which algorithm and key size they would like to use via the dashboard.? The administrators of the cloud would be responsible for configuring the dashboard and other components to report which encryption algorithms are available.? This will depend upon their cloud, and the encryption algorithm and key sizes will likely be dictated by the features supported by the compute nodes.\n\n-Nate\n\n> As I understand it you are proposing setting a minimal standard for? \n> storage encryption in OpenStack.\n> \n> I am not necessarily opposed to that, but I would rather focus on \n> ensuring that OpenStack\'s handling\n> of keys was of sufficiently high quality before limiting what OS \n> encryption capabilities will be allowed.\n> \n> Historically, there has been a tradeoff between affordability and? \n> quality of encryption. About a decade\n> ago you may recall there was an effort to define \"Better Than Nothing\" \n> security in the IETF, based on the\n> premise that \'inferior\' encryption that people would use was better than \n> \'superior\' encryption that would\n> be turned off. \n> \n> That has not been as hot of an issue recently, mostly because processing \n> makes \"expensive\" encryption\n> affordable almost faster than a debate can be resolved.\n> \n> That is why I think this is a debate better left to implementers and OS \n> communities. By the time we\n> can select what \"minimal\" encryption needs to be it could well be a moot \n> discussion.\n> \n> The security of encryption is dependent on the speed of an attacking \n> machine, only communities that \n> are prepared to stay on top of the latest encryption technologies should \n> be offering advise to end\n> consumers on these matters.\n> \n> I\'d recommend that OpenStack just use the technology that is available, \n> and specifically avoid endorsing\n> any of the options.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130213/a966654a/attachment.html>\n\n',NULL,NULL),('<1360783714.5229.6.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-13 13:28:33',-21600,'2013-02-13 19:28:33',NULL,'[openstack-dev] AVersion version selection application','I have just completed writing a composite application for version\nselection.  This could replace Nova\'s URLMap application, and could be\nused by other projects to allow API version selection.  I have dubbed\nthis piece of code, \"AVersion,\" and it is available on PyPi.  Here are\nthe links:\n\n      * http://pypi.python.org/pypi/aversion\n      * https://github.com/klmitch/aversion\n\nI\'ve written an extensive README describing what AVersion does and how\nit does it, but here\'s a quick summary:\n\nAVersion is a composite application, similar to the Paste urlmap. It is\nconfigured with several different applications--each of which represents\na different version of the desired end application. It can also be\nconfigured with a special application which handles unversioned API\nrequests, e.g., by returning a list of the available versions. AVersion\nthen selects the appropriate application to pass a given request to,\nbased on the URI prefix, or a version parameter on the content type or\ntypes specified in the \"Content-Type\" or \"Accept\" headers. In addition,\nAVersion can determine the best content type for the reply, based on the\nURI suffix (e.g., \".json\" could map to content type \"application/json\")\nor the \"Accept\" header.\n\nI wrote AVersion to be compatible with the existing Nova version\nselection algorithm; it uses the same ordering and techniques, and\nshould be usable as a drop-in replacement, with the appropriate\nconfiguration.  The configuration is admittedly rather complex, and is\nfully documented in the README, available at:\n\n        http://pypi.python.org/pypi/aversion\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1360790658.72331456@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-02-13 15:24:18',-21600,'2013-02-13 21:24:18',NULL,'[openstack-community] Scouting for volunteers to help staff\n	OpenStack booths at upcoming events','\n\nGood day to all.  The OpenStack Foundation is sponsoring these technical events in California, for which we would very much appreciate community support to help staff our booths. \n \n---------------------------------------------------------------------------------------------------\n[https://www.socallinuxexpo.org/scale11x] SCALE 11x - Los Angeles, LAX Hilton, Feb 23-24 (Saturday and Sunday).  We have a couple of volunteers but if you are attending and can help us out for a few hours, please let me know.  We\'ll also be promoting the LA User Group; co-organizer Stephon Striplin from DreamHost will be there.  As will I :-)\n \nBooth hours are Saturday, February 23 10am-6pm, and Sunday February 24 10am-4pm.  \n \nSCALE 11x is open to everyone - register today!  You\'ll not want to miss Chris MacGown, Founder and Chief Scientist from Piston Cloud, talk about The Tao of OpenStack on Saturday 3-4pm.  Then, join us along with Opscode and Rackspace, for an OpenStack in-booth beer party from 4-6pm!\n----------------------------------------------------------------------------------------------------\n \n[https://us.pycon.org/2013/] PyCon 2013 - Santa Clara Convention Center, March 14-16.  Our objective for this event is to help Python developers get involved, both from a recruiting perspective for OpenStack jobs and as potential users.  We are in search of volunteers to help staff our booth along with Community Manager Stefano Maffulli.  Meet Jim Blair, OpenStack Infrastructure Engineer, while there, too.  This event is sold out - a limited number of volunteers will be guaranteed free entrance!\n \nBooth hours are\n- Thursday, March 14, 6-8pm during opening reception\n- Friday, March 15, 10am-5pm\n- Saturday, March 16, 10am-5pm\n \nWe\'ll also have a table at the Job Fair on March 17, so be sure to post all of your open positions on openstack.org/jobs before the event.\n \n-----------------------------------------------------------------------------------------------------\nPlease contact me at [mailto:kathyc at openstack.org] kathyc at openstack.org if you\'d like to help out.  Thank you very much. \n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130213/f065f333/attachment.html>\n\n',NULL,NULL),('<1360859015.12943.YahooMailNeo@web163804.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-14 08:23:35',-28800,'2013-02-14 16:23:35',NULL,'[openstack-dev] Volume Encryption','Malini, I was happy to learn about a key manager discussion at the summit.? Do you know what track this would be under?? I can\'t decide if this should be in Keystone or maybe a whole new service.? I like the idea of a whole new service myself because I think it helps to have the separation and prevent bloating of functionality for components.? On the other hand, I probably don\'t want a dozen services.\n\nI like the idea of the key-id.? I think we may end up using that idea.? This will help us to support snapshot operations.\n\nOne item we have yet to tackle is cloning.? I think there are a few options for this.\n\n1) Don\'t support clone operations for encrypted volumes.? This is easy to implement and prevents key reuse, but it limits functionality.\n\n2) Support clone with same key.? This should be easy to implement as well.? We could use the metadata key-id and set it to the same value for the clone.? The drawback to this is that the key has multiple uses, and it could be used to decrypt many different volumes.? I don\'t like the idea of that.? If the key is compromised then what do you do?\n3) Support clone with different key.? You could do this by decrypting the bytes from the original volume and encrypting them with a new key.? If we are going to support cloning then I think I like this approach the best.? The drawback on this is time.\n\nThere are similar issues for snapshots, but I am not as opposed to option 2 for snapshots.? Any thoughts on this?\n\n-Nate\n\n\n\n________________________________\n From: \"Bhandaru, Malini K\" <malini.k.bhandaru at intel.com>\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Wednesday, February 13, 2013 4:32 PM\nSubject: RE: [openstack-dev] Volume Encryption\n \n\n \nOleg, just the thought I had earlier in the day!\nSuggested a session for key manager? at http://summit.openstack.org/.\nTo your list of blueprints, I added another one I found.\n?\nNate, if your volume meta data included a key-id, it could pull the key-string from the key-manager? (as yet a fuzzy) entity.\n?\nThe keystone token could also capture preferences for encryption algorithm (for Cinder/Glance/Swift) and these default to\nstrong versions like Caitlin suggests.\n?\nRegards,\nMalini\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130214/e0cdbb36/attachment.html>\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E5208121E@FMSMSX105.amr.corp.intel.com>',NULL),('<1360923430.2052090.1389722970405.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-14 13:09:30',-18000,'2014-01-14 18:09:30',NULL,'[Openstack-docs] Copyright statements in docs source files','----- Original Message -----\n> From: \"Nicholas Chase\" <nchase at mirantis.com>\n> To: openstack-docs at lists.openstack.org\n> Sent: Tuesday, January 14, 2014 12:57:15 PM\n> Subject: Re: [Openstack-docs] Copyright statements in docs source files\n> \n> The docs are supposed to be licensed either as Creative Commons or\n> Apache files (depending on what they are and who you ask :)).  they\n> should not have copyright notices in them.\n\nSure, but per my response to Rich that\'s contrary to the currently stated guidelines, which permit people to add copyright attributions referring to either themselves or their employer.\n\n> The exact licensing situation is being worked out at the board level.\n> If people are copying and pasting copyrighted information and putting in\n> a notice to avoid the idea that they\'re plagiarising, that\'s wrong.  If\n> they\'re putting them in to try and keep ownership of the content, that\'s\n> also wrong.\n\nDo you have any actual evidence of that happening? My read of Rich\'s email is that employees of the organizations he listed have contributed to the documentation and inserted the copyright attributions (as they are permitted to under the current guidelines) and I\'d expect the git history bears this out.\n\n> Anybody here been doing this?  If so, can you explain, so we can clear\n> it up?\n\nSee above.\n\n-Steve\n\n\n','<52D57A7B.6040308@mirantis.com>',NULL),('<1360926463.2400.117.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-15 11:07:43',0,'2013-02-15 11:07:43',NULL,'[openstack-dev] Moving nova.conf compute driver options from\n [DEFAULT] to [DRIVER_NAME]','On Fri, 2013-02-15 at 12:22 +0200, Alessandro Pilotti wrote:\n> Hi guys,\n> \n> As discussed with russelb and during the OpenStack Hyper-V meetings, it\'d be a great to move compute driver specific onfigurations from nova.conf\'s [DEFAULT] group to a driver specific group (e.g. [LIBVIRT], [HYPERV], etc).\n> \n> We already added new options in Grizzly to the [HYPERV] group and for consistency, before closing Grizzly, we\'d like to move the existing Hyper-V ones added in Folsom there as well.\n> \n> This approach could be IMO applied to all the drivers (in the Havana timeframe at this point, I guess).\n> The obvious issue is that breaking backwards compatibility is not an option.\n> \n> openstack.common.cfg.Opt() offers a \"deprecated_name\" argument, but AFAIK this applies only for options belonging to the same group:\n> https://github.com/openstack/nova/blob/master/nova/openstack/common/cfg.py#L518\n> \n> What about adding a \"deprecated_group\" as well or a \"<group>.<option>\" syntax for \"deprecated_name\"? This way we could handle the transition smoothly.\n\nCoincidentally, I have a WIP oslo-config branch for this:\n\n  https://github.com/markmc/oslo-config/commits/deprecated-group\n\nIt\'s getting pretty tight for Grizzly, but I hope to push this up for\nreview today.\n\n> Getting back to the specific Hyper-V case, if deprecated options are not possible at this stage, we\'d prefer to rename them anyway now. The Hyper-V support is far more complete in this release then it was in Folsom. Moving or deprecating the options in Havana will create way more confusion than doing it now.\n> \n> Here are the Hyper-V config options that need to be moved to the [HYPERV] group:\n> https://github.com/openstack/nova/blob/master/nova/virt/hyperv/vmops.py#L43\n> https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeops.py#L35\n> \n> Any additional ideas?\n\nUsually, we avoid breaking existing configurations. But, in the case of\nhyper-v, I\'d be fine with you guys saying \"we did\'t have many users in\nFolsom, so backwards compat isn\'t a big concern\".\n\nCheers,\nMark.\n\n\n\n','<C5E78CFC-CCB6-45E6-A861-1C0A5DD82935@pilotti.it>',NULL),('<1360930833.2400.134.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-15 12:20:33',0,'2013-02-15 12:20:33',NULL,'[openstack-dev] Moving nova.conf compute driver options from\n [DEFAULT] to [DRIVER_NAME]','On Fri, 2013-02-15 at 20:00 +0800, Thomas Goirand wrote:\n> On 02/15/2013 07:07 PM, Mark McLoughlin wrote:\n> > Usually, we avoid breaking existing configurations. But, in the case of\n> > hyper-v, I\'d be fine with you guys saying \"we did\'t have many users in\n> > Folsom, so backwards compat isn\'t a big concern\".\n> \n> I would agree too, on this case only ... :)\n> \n> Please don\'t propose to move *other* directives around on new sections.\n> It\'s too late for that already.\n\nAlready proposed and there was consensus that it was a good idea:\n\nhttps://etherpad.openstack.org/grizzly-nova-config-options\n\nWe\'ll retain backwards compatibility support for at least a release,\nthough.\n\nCheers,\nMark.\n\n\n\n','<511E2353.5050907@debian.org>',NULL),('<1360948157.2400.154.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-15 17:09:17',0,'2013-02-15 17:09:17',NULL,'[OpenStack Foundation] Board Meeting - February 12th','On Thu, 2013-02-14 at 20:59 -0600, Jonathan Bryce wrote:\n> The Board of Directors had another full meeting this past Tuesday in\n> San Francisco. Most directors were able to be present in person. We\n> met from 10:00am to 6:00pm, covering almost every item on the planned\n> agenda:\n> http://wiki.openstack.org/Governance/Foundation/12Feb2013BoardMeeting\n\nHere\'s my more rambling summary:\n\n  http://blogs.gnome.org/markmc/2013/02/15/february-12th-openstack-foundation-board-meeting/\n\nI expect most people prefer the more concise summary, but hopefully\nthere are at least a few people out there who appreciate the detailed\nversion :)\n\nCheers,\nMark.\n\n\n\n','<2D481937-5CC8-40C6-A73B-EA1315E0E82C@openstack.org>',NULL),('<1361093940.2400.188.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-17 09:39:00',0,'2013-02-17 09:39:00',NULL,'[openstack-dev] Using oslo-config library in grizzly-3','Hey\n\nI\'ve put up a bunch of reviews to make nova, glance, keystone, quantum\nand cinder use oslo-config-2013.1b3:\n\n  https://review.openstack.org/#/q/I4815aeb8a9341a31a250e920157f15ee15cfc5bc,n,z\n\nLooks like I\'ve still got some issues to work through with those.\n\nAlan Pevec has put up a review for keystoneclient:\n\n  https://review.openstack.org/22126\n\nI\'m hoping to get all this sorted out and included in grizzly-3. I\'m\nalso hoping to submit ceilometer and heat patches to do the same.\n\nThis is mostly a heads-up for packagers who\'ll need to package up\noslo-config. The tarball is here:\n\n  http://tarballs.openstack.org/oslo-config/oslo-config-2013.1b3.tar.gz\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1361204950.5229.13.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-18 10:29:09',-21600,'2013-02-18 16:29:09',NULL,'[openstack-dev] AVersion version selection application','On Sat, 2013-02-16 at 02:22 +0000, Mellquist, Peter wrote:\n> Have you considered using regular expressions for URI matching?\n\nNo, I was attempting to match the logic nova currently uses, which is\nderived from paste\'s URLMap class (which admittedly has more options\nthan I\'ve accounted for, such as the ability to restrict destination\nhost).  I\'m not against adding regular expression support in the future,\nbut I think we should encourage using simple prefixes where possible?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<F7DACD2842D0844DACB472968051D2E221FA1253@G4W3293.americas.hpqcorp.net>',NULL),('<1361305961.2449.84.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-19 20:32:41',0,'2013-02-19 20:32:41',NULL,'[openstack-dev] [quantum] ImportError oslo.config when\n run_tests.sh -f','Hey\n\nOn Tue, 2013-02-19 at 13:32 -0600, Jason K?lker wrote:\n> On Tue, Feb 19, 2013 at 12:50 PM, Paul Michali <pcm at cisco.com> wrote:\n> > Thanks!\n> >\n> > I\'m assuming one the commit that Jason Kolker is doing this will be part of the master branch?  I\'m doing the pip install right now.\n> \n> Yep it will be in the next release tarball, another temporary option\n> instead of pip would be to change the requires file to use the master\n> tarball:  http://tarballs.openstack.org/oslo-config/oslo-config-master.tar.gz#egg=oslo-config\n\nJust tagged another version with your patch:\n\nhttp://tarballs.openstack.org/oslo-config/oslo-config-2013.1b4.tar.gz\n\nCheers,\nMark.\n\n\n\n','<CAB=yZ1PN-5ukwy8jES4CAWs_B90QfvPQZGvPiVEruJwxyx1RvA@mail.gmail.com>',NULL),('<1361351674.184.1356396140603.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-12-25 00:42:20',0,'2012-12-25 00:42:20',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #47','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/47/>\n\n------------------------------------------\n[...truncated 15137 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 25 Dec 2012 00:39:22 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-1edc4d7c-b21e-43f3-af2d-11e59c9ad99f\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yNVQwMDozOToxMi40OTIwMTYiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI2VDAwOjM5OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImE1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAiaWQiOiAiNDBhM2VjYzM2MzkyNDljMTg2YjJmMzAyNDZiMTJjZjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJkYTMyY2ZlODhjNmI0OTFhYjI5NTg1NWQ1OTFmNWFhOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ3NTRmYmRiNjg4NDIzMDg3Zjk3N2M2ZThhMjVjYWUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJpZCI6ICIyMzI1NWFkMmE0MTc0OGYxYjYxMTI5OTBiMzJjNzk2ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0MTllMWRkN2U3OWE0ZjNlOTAxNGJhNzM2NTljNGMzOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2IiwgImlkIjogImExMmFjYzllODY1MDQzNjU5ZDYzMmE0YThhZjYxYWVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjlkOTZkYWQxN2JmYjRkYjQ4MTFlMWY2ZGVlY2QzNWI0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZWQ1ZjZmMGY3ZTk2NDQ4Y2JiNWE0YTY2NWE1NWYzMTEiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiODE0YzM4NmNkYTMwNGVlNDkyMTI4N2UwYWFkNGI0NjMiLCAiNGE5Mzg4NDlmMzdiNDhiYzhhNzM0YmI1NTIwYjVmY2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAbZGLDKt2oeCeRsK6TQgohKHqQSg+QRjBTCchKuwhQkVLQD4svqAo3jy90euUpex9eGWp7YzxdnE0YUVPVfxJA0oqUgN70Cf25EOrCgbaE0GK3uRYHt68bYap+SuqCeuEpURsBT7mtAenXQ6Q2O3BVnx6gfRQN-0hYN9X6Nl0i1w==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/b80ab9fc-a068-49bf-89c5-4bf9cbb1f4ba\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 25 Dec 2012 00:39:23 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-d1d5b577-474c-4db6-a7f0-d777a3218b78\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yNVQwMDozOToxMi40OTIwMTYiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI2VDAwOjM5OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImE1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAiaWQiOiAiNDBhM2VjYzM2MzkyNDljMTg2YjJmMzAyNDZiMTJjZjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJkYTMyY2ZlODhjNmI0OTFhYjI5NTg1NWQ1OTFmNWFhOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ3NTRmYmRiNjg4NDIzMDg3Zjk3N2M2ZThhMjVjYWUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJpZCI6ICIyMzI1NWFkMmE0MTc0OGYxYjYxMTI5OTBiMzJjNzk2ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0MTllMWRkN2U3OWE0ZjNlOTAxNGJhNzM2NTljNGMzOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2IiwgImlkIjogImExMmFjYzllODY1MDQzNjU5ZDYzMmE0YThhZjYxYWVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjlkOTZkYWQxN2JmYjRkYjQ4MTFlMWY2ZGVlY2QzNWI0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZWQ1ZjZmMGY3ZTk2NDQ4Y2JiNWE0YTY2NWE1NWYzMTEiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiODE0YzM4NmNkYTMwNGVlNDkyMTI4N2UwYWFkNGI0NjMiLCAiNGE5Mzg4NDlmMzdiNDhiYzhhNzM0YmI1NTIwYjVmY2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAbZGLDKt2oeCeRsK6TQgohKHqQSg+QRjBTCchKuwhQkVLQD4svqAo3jy90euUpex9eGWp7YzxdnE0YUVPVfxJA0oqUgN70Cf25EOrCgbaE0GK3uRYHt68bYap+SuqCeuEpURsBT7mtAenXQ6Q2O3BVnx6gfRQN-0hYN9X6Nl0i1w==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/cc8472ac-17bb-4231-9648-626daf043eed\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 25 Dec 2012 00:39:23 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-0c71064c-ba7b-4d52-9df5-cad59d3a5ddb\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yNVQwMDozOToxMi40OTIwMTYiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI2VDAwOjM5OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImE1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAiaWQiOiAiNDBhM2VjYzM2MzkyNDljMTg2YjJmMzAyNDZiMTJjZjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJkYTMyY2ZlODhjNmI0OTFhYjI5NTg1NWQ1OTFmNWFhOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ3NTRmYmRiNjg4NDIzMDg3Zjk3N2M2ZThhMjVjYWUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJpZCI6ICIyMzI1NWFkMmE0MTc0OGYxYjYxMTI5OTBiMzJjNzk2ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0MTllMWRkN2U3OWE0ZjNlOTAxNGJhNzM2NTljNGMzOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2IiwgImlkIjogImExMmFjYzllODY1MDQzNjU5ZDYzMmE0YThhZjYxYWVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjlkOTZkYWQxN2JmYjRkYjQ4MTFlMWY2ZGVlY2QzNWI0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZWQ1ZjZmMGY3ZTk2NDQ4Y2JiNWE0YTY2NWE1NWYzMTEiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiODE0YzM4NmNkYTMwNGVlNDkyMTI4N2UwYWFkNGI0NjMiLCAiNGE5Mzg4NDlmMzdiNDhiYzhhNzM0YmI1NTIwYjVmY2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAbZGLDKt2oeCeRsK6TQgohKHqQSg+QRjBTCchKuwhQkVLQD4svqAo3jy90euUpex9eGWp7YzxdnE0YUVPVfxJA0oqUgN70Cf25EOrCgbaE0GK3uRYHt68bYap+SuqCeuEpURsBT7mtAenXQ6Q2O3BVnx6gfRQN-0hYN9X6Nl0i1w==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/3b0304f5-bdf0-4a15-8cac-abd912d17919\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 25 Dec 2012 00:39:23 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-b5b74787-6abc-42ab-a1c4-ae152a58e49b\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yNVQwMDozOToxMi40OTIwMTYiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI2VDAwOjM5OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImE1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvYTU0ZjIxNzk3MmQ5NDNiNzhmNGYyNTg5OTQ3NDU1NTYiLCAiaWQiOiAiNDBhM2VjYzM2MzkyNDljMTg2YjJmMzAyNDZiMTJjZjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJkYTMyY2ZlODhjNmI0OTFhYjI5NTg1NWQ1OTFmNWFhOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMWQ3NTRmYmRiNjg4NDIzMDg3Zjk3N2M2ZThhMjVjYWUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiIsICJpZCI6ICIyMzI1NWFkMmE0MTc0OGYxYjYxMTI5OTBiMzJjNzk2ZiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0MTllMWRkN2U3OWE0ZjNlOTAxNGJhNzM2NTljNGMzOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2E1NGYyMTc5NzJkOTQzYjc4ZjRmMjU4OTk0NzQ1NTU2IiwgImlkIjogImExMmFjYzllODY1MDQzNjU5ZDYzMmE0YThhZjYxYWVlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9hNTRmMjE3OTcyZDk0M2I3OGY0ZjI1ODk5NDc0NTU1NiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjlkOTZkYWQxN2JmYjRkYjQ4MTFlMWY2ZGVlY2QzNWI0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZWQ1ZjZmMGY3ZTk2NDQ4Y2JiNWE0YTY2NWE1NWYzMTEiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiODE0YzM4NmNkYTMwNGVlNDkyMTI4N2UwYWFkNGI0NjMiLCAiNGE5Mzg4NDlmMzdiNDhiYzhhNzM0YmI1NTIwYjVmY2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAbZGLDKt2oeCeRsK6TQgohKHqQSg+QRjBTCchKuwhQkVLQD4svqAo3jy90euUpex9eGWp7YzxdnE0YUVPVfxJA0oqUgN70Cf25EOrCgbaE0GK3uRYHt68bYap+SuqCeuEpURsBT7mtAenXQ6Q2O3BVnx6gfRQN-0hYN9X6Nl0i1w==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/19e39d64-edbb-4bf7-a33b-84146c68625d\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 25 Dec 2012 00:39:24 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-e29ffb6b-6f0a-4de4-95e9-f314d199e986\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\nAdd metadata to account ... ok\nDelete metadata from account ... ok\nList all account metadata ... ok\nList of all containers should not be empty ... ok\nUpdate/Retrieve/Delete Container Metadata ... ok\nCreate a container, test responses ... ok\nCreate and Delete a container, test responses ... ok\nAdd metadata to object ... ok\nGET object after expiry time ... SKIP: Until bug 1069849 is resolved.\nMake container public-readable, and access the object ... ok\nCopy storage object ... ok\nCopy storage object across containers ... ok\nCopy storage object ... ok\nChange the content type of an existing object ... ok\nCreate storage object, test response ... ok\nCreate and delete a storage object, test responses ... ok\nRetrieve object\'s data(in response body) ... ok\nAdd metadata to storage object, test if metadata is retrievable ... ok\nVersioned container responses tests ... ok\nCreate/get/delete volume with volume_type and extra spec. ... ok\nCreate/Delete volume type. ... ok\nCreate/get volume type. ... ok\nList Volume types. ... ok\nCreate/Delete volume type extra spec. ... FAIL\nCreate/get volume type extra spec ... FAIL\nList Volume types extra specs. ... FAIL\nUpdate volume type extra specs ... FAIL\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nFAIL: Create/Delete volume type extra spec.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 91, in test_volume_type_extra_spec_create_delete\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/93876a1ec36d41a380034cf0d398b4fa/types/eaffb66d-badb-4a94-9065-821b8fe30b67/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec2\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 25 Dec 2012 00:39:40 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-e767a133-9e30-49be-930d-d196a8eed426\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Create/get volume type extra spec\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 109, in test_volume_type_extra_spec_create_get\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/93876a1ec36d41a380034cf0d398b4fa/types/eaffb66d-badb-4a94-9065-821b8fe30b67/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec1\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 25 Dec 2012 00:39:40 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-24bdde24-6516-41ac-bace-bf9ea55ab7bd\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: List Volume types extra specs.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 59, in test_volume_type_extra_specs_list\n    self.fail(\"Could not list volume types extra specs\")\nAssertionError: Could not list volume types extra specs\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not list volume types extra specs\')\n    \n\n======================================================================\nFAIL: Update volume type extra specs\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 75, in test_volume_type_extra_specs_update\n    self.fail(\"Couldnt update volume type extra spec\")\nAssertionError: Couldnt update volume type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Couldnt update volume type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/93876a1ec36d41a380034cf0d398b4fa/types/eaffb66d-badb-4a94-9065-821b8fe30b67/extra_specs/spec1\ntempest.common.rest_client: ERROR: Request Body: {\"spec1\": \"val2\"}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 25 Dec 2012 00:39:40 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-5efbfeb9-0761-465e-8e61-100768f25071\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 587 tests in 1480.507s\n\nFAILED (SKIP=73, failures=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/rabbitmq/rabbit at devstack-1356095445-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/rabbitmq/rabbit at devstack-1356095445.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/47/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<963166377.168.1356310091693.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1361367124.2449.92.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-20 13:32:04',0,'2013-02-20 13:32:04',NULL,'[openstack-dev] Oslo-config update in Nova','On Wed, 2013-02-20 at 13:02 +0000, Pitucha, Stanislaw Izaak wrote:\n> And I just found that this file comes from oslo-incubator and has been\n> already fixed in a similar way...\n> Ignore this, please and thanks Mark for fixing it earlier :)\n\nI\'ve just pushed the fix for Nova:\n\n  https://review.openstack.org/22422\n\nCheers,\nMark.\n\n\n\n','<F2CEBDD2D596EC45A4D5479F72C865C5ADF547@G1W3787.americas.hpqcorp.net>',NULL),('<1361367400.2449.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-20 13:36:40',0,'2013-02-20 13:36:40',NULL,'[openstack-dev] [oslo] Option conflict when mixing projects','On Wed, 2013-02-20 at 14:14 +0100, Julien Danjou wrote:\n> Hi,\n> \n> Context: Ceilometer provides a special notifier driver for Nova,\n> publishing the last counters before an instance get destroyed.\n> \n> That means this code is run from `nova-compute\' and uses some Ceilometer\n> code. The problem is that when importing Ceilometer modules from this\n> notifier, it ends up importing `ceilometer.openstack.common.rpc\', which\n> tries to register the `rpc_backend\' option inside\n> `oslo.config.cfg.CONF\', object which already has this option defined by\n> nova.openstack.common.rpc. So `DuplicateOptError\' is raised, and\n> badaboum.\n\nIf the code is running inside nova-compute, it should be using nova\'s\nCONF object - previously nova.openstack.common.cfg.CONF but since last\nnight, oslo.config.cfg.CONF\n\nCheers,\nMark.\n\n\n\n','<87ehgbdt54.fsf@dex.adm.naquadah.org>',NULL),('<1361367787.2449.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-20 13:43:07',0,'2013-02-20 13:43:07',NULL,'[openstack-dev] [oslo] Option conflict when mixing projects','On Wed, 2013-02-20 at 14:39 +0100, Julien Danjou wrote:\n> On Wed, Feb 20 2013, Mark McLoughlin wrote:\n> \n> > If the code is running inside nova-compute, it should be using nova\'s\n> > CONF object - previously nova.openstack.common.cfg.CONF but since last\n> > night, oslo.config.cfg.CONF\n> \n> I don\'t think you understood the issue, but I might also not have been\n> totally clear.\n> \n> Here\'s the real problem we\'re facing:\n> \n> % python\n> Python 2.7.3 (default, Jan  2 2013, 13:56:14) \n> [GCC 4.7.2] on linux2\n> Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n> >>> import nova.openstack.common.rpc\n> >>> import ceilometer.openstack.common.rpc\n\nOk, so the issue is that the ceilometer code also needs to be using\nnova.openstack.common.rpc if it is running inside nova-compute\n\nCheers,\nMark.\n\n\n\n','<87a9qzdrzr.fsf@dex.adm.naquadah.org>',NULL),('<1361368360.2449.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-20 13:52:40',0,'2013-02-20 13:52:40',NULL,'[openstack-dev] [oslo] Option conflict when mixing projects','On Wed, 2013-02-20 at 14:46 +0100, Julien Danjou wrote:\n> On Wed, Feb 20 2013, Mark McLoughlin wrote:\n> \n> > Ok, so the issue is that the ceilometer code also needs to be using\n> > nova.openstack.common.rpc if it is running inside nova-compute\n> \n> And how do we deal with cases like the RPC for Nova and for Ceilometer\n> using different backends, or on differents hosts?\n> \n> Actually, the first problem is that both project are using different\n> control_exchange, and both are trying to set this option to different\n> values.\n\nI don\'t know exactly what you\'re trying to achieve here, but if you need\ndifferent RPC configuration for ceilometer code in nova-compute then you\nneed a separate configuration file and a separate ConfigOpts object\n\nBasically, there should be a way to pass an object other than\noslo.confg.cfg.CONF to the RPC calls.\n\nCheers,\nMark.\n\n\n\n','<87621ndrnz.fsf@dex.adm.naquadah.org>',NULL),('<1361384335.187222680@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-02-20 12:18:55',-21600,'2013-02-20 18:18:55',NULL,'[openstack-community] Requesting European volunteers to help staff\n	the OpenStack booth at World Hosting Days, 19-21 March in Rust,\n	Germany','\n\n\nMarianna Raffaele in the UK is helping coordinate OpenStack\'s presence at World Hosting Days 2013.  Please support her on this request for booth staff volunteers.  Thank you to StackOps and eNovance for their commitments to date! \n----------------------------------------------------------------------------------------------\nThe OpenStack Foundation is the proud Gold Sponsor of World Hosting Days 2013 (WHD.global) in Germany, one of the largest worldwide hosting events with over 4,200 attendees from the international hosting industry.\n \n \nAt this event, OpenStack will raise awareness of the value of OpenStack cloud software for hosting and SaaS providers, including the pace of innovation, terrific community, ecosystem of tools and applications, and economies of scale. We will focus our participation on our users which are achieving these benefits.  We\'re pleased to announce Kurt Garloff of Deutsche Telekom AG will speak about their use of OpenStack in a general session on 21 March.\n \n \nWe\'re looking for a few volunteers from our member and sponsor companies to help staff the OpenStack booth. Here are the details, for your consideration. Thank you.\n \n \nEvent Logistics:\n\nDates: 19-21 March, 9am-6pm\n\nLocation: Europa Park, Rust, Germany (near Frankfurt)\n\nAgenda: See attached\n\nType of volunteers: People who can converse about the value and benefits of OpenStack, and have experienced these directly or indirectly with their hosting clients.\n\nAvailability at the booth: There are 3 hour time slots available all three days; volunteer for one or more at your convenience.\n\nRegistration: You will be provided with a code to register for the event free of charge and to book accommodation (if needed) in one of the recommended hotels at a discounted rate.\n \nWe would love to hear from you and have your OpenStack skilled people on board to represent us during this event!\n \n \nShould you have any questions, please do not hesitate to contact me.\n \n \nI look forward to hearing from you.\n \n \nKind regards,\nMarianna Raffaele\nEvents Assistant\nOpenStack Foundation\n \n[mailto:m.raffaele05 at gmail.com] m.raffaele05 at gmail.com\nTel. [http://tel:%2B44%207940%20889129] +44 7940 889129\n[http://www.worldhostingdays.com/eng/index.php] http://www.worldhostingdays.com/eng/index.php\n ----------------------------------------------------------------------------------------------\nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130220/d163d321/attachment.html>\n\n',NULL,NULL),('<1361431627.22851465.1402299492504.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 03:38:12',-14400,'2014-06-09 07:38:12',NULL,'[openstack-dev] use of the word certified','\n\n> So there are certain words that mean certain things, most don\'t, some do.\n> \n> If words that mean certain things are used then some folks start using\n> the word and have expectations around the word and the OpenStack\n> Technical Committee and other OpenStack programs find themselves on the\n> hook for behaviours that they didn\'t agree to.\n> \n> Currently the word under discussion is \"certified\" and its derivatives:\n> certification, certifying, and others with root word \"certificate\".\n> \n> This came to my attention at the summit with a cinder summit session\n> with the one of the cerficiate words in the title. I had thought my\n> point had been made but it appears that there needs to be more\n> discussion on this. So let\'s discuss.\n> \n> Let\'s start with the definition of certify:\n> cer?ti?fy\n> verb (used with object), cer?ti?fied, cer?ti?fy?ing.\n> 1. to attest as certain; give reliable information of; confirm: He\n> certified the truth of his claim.\n> 2. to testify to or vouch for in writing: The medical examiner will\n> certify his findings to the court.\n> 3. to guarantee; endorse reliably: to certify a document with an\n> official seal.\n> 4. to guarantee (a check) by writing on its face that the account\n> against which it is drawn has sufficient funds to pay it.\n> 5. to award a certificate to (a person) attesting to the completion of a\n> course of study or the passing of a qualifying examination.\n> Source: http://dictionary.reference.com/browse/certify\n> \n> The issue I have with the word certify is that it requires someone or a\n> group of someones to attest to something. The thing attested to is only\n> as credible as the someone or the group of someones doing the attesting.\n> We have no process, nor do I feel we want to have a process for\n> evaluating the reliability of the somones or groups of someones doing\n> the attesting.\n> \n> I think that having testing in place in line with other programs testing\n> of patches (third party ci) in cinder should be sufficient to address\n> the underlying concern, namely reliability of opensource hooks to\n> proprietary code and/or hardware. I would like the use of the word\n> \"certificate\" and all its roots to no longer be used in OpenStack\n> programs with regard to testing. This won\'t happen until we get some\n> discussion and agreement on this, which I would like to have.\n> \n> Thank you for your participation,\n> Anita.\n\nHi Anita,\n\nJust a note on cross-posting to both the os-dev and os-tc lists.\n\nAnyone not on the TC who will hits reply-all is likely to see their\npost be rejected by the TC list moderator, but go through to the\nmore open dev list.\n\nAs a result, the thread diverges (as we saw with the recent election\nstats/turnout thread).\n\nAlso, moderation rejects are an unpleasant user experience.\n\nSo if a post is intended to reach out for input from the wider dev\ncommunity, it\'s better to post *only* to the -dev list, or vice versa\nif you want to interact with a narrower audience.\n\nThanks,\nEoghan\n\n\n','<5391FA6A.1000400@anteaya.info>',NULL),('<1361431627.22851465.1402299492504.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-09 03:38:12',-14400,'2014-06-09 07:38:12',NULL,'[openstack-tc] [openstack-dev] use of the word certified','\n\n> So there are certain words that mean certain things, most don\'t, some do.\n> \n> If words that mean certain things are used then some folks start using\n> the word and have expectations around the word and the OpenStack\n> Technical Committee and other OpenStack programs find themselves on the\n> hook for behaviours that they didn\'t agree to.\n> \n> Currently the word under discussion is \"certified\" and its derivatives:\n> certification, certifying, and others with root word \"certificate\".\n> \n> This came to my attention at the summit with a cinder summit session\n> with the one of the cerficiate words in the title. I had thought my\n> point had been made but it appears that there needs to be more\n> discussion on this. So let\'s discuss.\n> \n> Let\'s start with the definition of certify:\n> cer?ti?fy\n> verb (used with object), cer?ti?fied, cer?ti?fy?ing.\n> 1. to attest as certain; give reliable information of; confirm: He\n> certified the truth of his claim.\n> 2. to testify to or vouch for in writing: The medical examiner will\n> certify his findings to the court.\n> 3. to guarantee; endorse reliably: to certify a document with an\n> official seal.\n> 4. to guarantee (a check) by writing on its face that the account\n> against which it is drawn has sufficient funds to pay it.\n> 5. to award a certificate to (a person) attesting to the completion of a\n> course of study or the passing of a qualifying examination.\n> Source: http://dictionary.reference.com/browse/certify\n> \n> The issue I have with the word certify is that it requires someone or a\n> group of someones to attest to something. The thing attested to is only\n> as credible as the someone or the group of someones doing the attesting.\n> We have no process, nor do I feel we want to have a process for\n> evaluating the reliability of the somones or groups of someones doing\n> the attesting.\n> \n> I think that having testing in place in line with other programs testing\n> of patches (third party ci) in cinder should be sufficient to address\n> the underlying concern, namely reliability of opensource hooks to\n> proprietary code and/or hardware. I would like the use of the word\n> \"certificate\" and all its roots to no longer be used in OpenStack\n> programs with regard to testing. This won\'t happen until we get some\n> discussion and agreement on this, which I would like to have.\n> \n> Thank you for your participation,\n> Anita.\n\nHi Anita,\n\nJust a note on cross-posting to both the os-dev and os-tc lists.\n\nAnyone not on the TC who will hits reply-all is likely to see their\npost be rejected by the TC list moderator, but go through to the\nmore open dev list.\n\nAs a result, the thread diverges (as we saw with the recent election\nstats/turnout thread).\n\nAlso, moderation rejects are an unpleasant user experience.\n\nSo if a post is intended to reach out for input from the wider dev\ncommunity, it\'s better to post *only* to the -dev list, or vice versa\nif you want to interact with a narrower audience.\n\nThanks,\nEoghan\n\n\n','<5391FA6A.1000400@anteaya.info>',NULL),('<1361458994.2392.38.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-21 15:03:14',0,'2013-02-21 15:03:14',NULL,'[openstack-dev] [oslo] Option conflict when mixing projects','On Wed, 2013-02-20 at 15:07 +0100, Julien Danjou wrote:\n> On Wed, Feb 20 2013, Mark McLoughlin wrote:\n> \n> > I don\'t know exactly what you\'re trying to achieve here, but if you need\n> > different RPC configuration for ceilometer code in nova-compute then you\n> > need a separate configuration file and a separate ConfigOpts object\n> >\n> > Basically, there should be a way to pass an object other than\n> > oslo.confg.cfg.CONF to the RPC calls.\n> \n> Ok, but the underlying problem is that we don\'t control what\n> openstack.common.rpc does, and it registers its options at import time.\n> \n> So how can we, Ceilometer, fix this case:\n> \n> >>> import nova.openstack.common.rpc\n> >>> import ceilometer.openstack.common.rpc\n> \n> on our own?\n> \n> (Hint: the answer \"don\'t do that\" isn\'t valid :-))\n\nOk, I took a poke at this and hacked up a patch that\'s probably broken\nin a million different ways.\n\nThe tl;dr is that we can add an rpc.get_impl() function quite easily but\nceilometer will require quite a bit of conf to ensure no code run by\nnova_notifer uses cfg.CONF:\n\n  https://github.com/markmc/ceilometer/commits/non-global-conf\n\n    Allow nova_notifier use non-global config\n      \n    The nova_notifer code runs in the context of nova, so if we use cfg.CONF\n    then we are reading options from nova.conf. Instead, we want to read\n    config options from ceilometer.conf.\n    \n    To achieve that, all of ceilometers code which is used by nova_notifier\n    needs to accept a ConfigOpts object created by nova_notifier. The code\n    needs to both register and read config options from this object.\n    \n    When we get down to meter_publish, the calls to the oslo RPC code also\n    need to be passed this ConfigOpts object. To facilitate this, we add\n    a new rpc.get_impl() function which needs to be proposed to\n    oslo-incubator.\n\nI\'ve also filed this bug:\n\n  https://bugs.launchpad.net/oslo/+bug/1131233\n\nCheers,\nMark.\n\n\n\n','<87y5ejcc3p.fsf@dex.adm.naquadah.org>',NULL),('<1361462689.5229.40.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-21 10:04:49',-21600,'2013-02-21 16:04:49',NULL,'[openstack-dev] [quantum] unittest updates','On Thu, 2013-02-21 at 09:42 +0000, Rosa, Andrea (HP Cloud Services)\nwrote:\n> Maybe I am wrong but addCleanup is new in python 2.7 using it could  break the compatibility with python 2.6.\n> Is that correct?\n\nThe point of unittest2 is to backport Python 2.7 unittest features to\nPython 2.6.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5F389C517756284F80239F55BCA5DDDD67EFC085@G4W3295.americas.hpqcorp.net>',NULL),('<1361575682.37857094.1403296726864.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 16:38:46',-14400,'2014-06-20 20:38:46',NULL,'[openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle\n	Meetup	-	Attendance Confirmation','\n\n----- Original Message -----\n> Any more takers for the tripleo mid-cycle meetup in Raleigh? If so, please\n> sign up on the etherpad below.\n> \n> The hotel group room rate will be finalized on Monday Jul 23rd (US time),\n\nOf course that was meant to be Jun 23rd :-), i.e. this coming Monday.\n\n> after that time you will be on your own for finding accommodation.\n> \n> Thanks\n> Charles\n> \n> ----- Original Message -----\n> > Hi all,\n> > \n> > I would like to remind you to sign up for mid-cycle meetup which is\n> > happening July 21-25 in Raleigh:\n> > \n> > * https://etherpad.openstack.org/p/juno-midcycle-meetup\n> > \n> > We need number of participants as soon as possible so that we can ask\n> > for group discount at the hotel. Also if we don\'t get rooms in one of\n> > these two hotels (see etherpad) the experience of accommodation is\n> > rapidly decreasing. Therefor I would like to ask everybody, if you can\n> > confirm your attendance as soon as possible.\n> > \n> > If you have any related question just let me know, I will be happy to help.\n> > \n> > Looking forward to seeing you all in Raleigh\n> > -- Jarda\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1647485198.37853953.1403296007239.JavaMail.zimbra@redhat.com>',NULL),('<1361640136.27021.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-23 17:22:16',0,'2013-02-23 17:22:16',NULL,'[openstack-dev] Filesystem as a Service API in Cinder [was\n Management of NAS (NFS/CIFS shares) in OpenStack]','Hi,\n\nOn Wed, 2012-11-21 at 15:52 +0000, Swartzlander, Ben wrote:\n> NetApp is interested in providing a common way to provision and attach\n> NFS and CIFS shares to VMs in an OpenStack environment. We presented our\n> ideas at the OpenStack summit last month and we have submitted a patch\n> to Cinder that demonstrates one way to implement these features. We\n> believe that extensions to the Cinder API are the most logical and least\n> disruptive way to bring these features to OpenStack, but discussions at\n> the conference show there are differences of opinion on this topic.\n> \n> I would like to invite anyone who is interested in NFS and CIFS in\n> OpenStack, or Cinder or NAS in general to take a look at our etherpad\n> and our code submission and provide feedback and suggestions.\n> \n> Etherpad: https://etherpad.openstack.org/cinder-nas-extensions\n> Gerrit Submission: https://review.openstack.org/#/c/16054/\n> \n> Our proposed patch does include substantial changes and we want to do\n> our best to ensure that we do it right the first time, so please reply\n> to me and/or this thread if you\'re interested and have good ideas,\n> opinions, or suggestions. We also welcome any code review comments on\n> the gerrit submission.\n\nI must admit this discussion completely escaped my attention. There\nwasn\'t much feedback on the original thread, so I\'m re-titling to make\nit more obvious what\'s being proposed here.\n\nThe blueprint is:\n\n  https://blueprints.launchpad.net/cinder/+spec/cinder-protocol-enhancements\n\nand latest review:\n\n  https://review.openstack.org/21290\n\nand wiki pages:\n\n  https://wiki.openstack.org/wiki/CinderProtocolEnhancements\n  https://wiki.openstack.org/wiki/CinderProtocolEnhancementsAPI\n\nwith the usage looking like:\n\n  $> cinder share-create cifs 10\n  $> cinder share-list\n  $> cinder share-allow ip 10.0.1.*\n  $> cinder share-delete d596078a-7bfb-4977-b10d-2cf5528e708d\n\nThe share-show command would give e.g.\n\n  export_location = //172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971\n\nand you\'d use this from within your instance to mount the share.\n\nFirstly, I think this is awesome - it\'s a really interesting new feature\nand I\'d love OpenStack to support it.\n\nHowever ... looking at the concept, the API and the implementation it\nreally seems to me that there\'s no reason to include this in Cinder.\n\nThe concept of filesystem storage is as distinct from block storage as\nobject storage is from block storage. The blueprint says:\n\n   We propose and intend to act to evolve Cinder as the canonical\n   storage provisioning control plane in OpenStack independent of\n   storage protocol type (whether block or file)\n\nbut I don\'t get it ... why does conceptually make sense? Why block and\nfile? Why not object too?\n\nThe API has been added to the OpenStack Volumes API as extensions, but\nit really should be a completely new Shares API.\n\nThe implementation of the shares support is completely separate from\nCinder\'s volumes support.\n\nThe only benefit to adding this to Cinder AFAICS is that we avoid having\nanother copy of Nova\'s API infrastructure and scheduling code. Honestly,\nif that was something we felt outweighed other concerns ... then we\nshouldn\'t have split Cinder out from Nova in the first place. The way I\nsee it, another copy of this code will encourage people to double down\non sharing the code via Oslo.\n\nCheers,\nMark.\n\n\n\n','<53E7920A93307949AC19339A21136DC903F99C4A@SACEXCMBX01-PRD.hq.netapp.com>',NULL),('<1361823051.2303.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-25 20:10:51',0,'2013-02-25 20:10:51',NULL,'[openstack-dev] nova dependencies, oslo-config and pypi','On Mon, 2013-02-25 at 10:25 -0800, Johannes Erdfelt wrote:\n> I noticed that oslo-config isn\'t in pypi yet.\n> \n> This is causing some problems when nova is installed in some ways.\n> \n> For instance, if you use \'pip install\n> http://tarballs.openstack.org/nova/nova-2013.1.g3.tar.gz\' or if nova is\n> installed indirectly because of a dependency (such as for nova_limits).\n> \n> It appears the reason is because of limitations in setuptools and the\n> different ways dependencies can get installed.\n> \n> The nova tox config will install dependencies by calling pip directly.\n> This can handle the URL style install of oslo-config just fine. However,\n> when using pip install with a nova tarball, or when indirectly installed\n> by dependencies, setuptools is used.\n> \n> nova (using nova.openstack.common.setup) will generate a list of\n> dependencies based on the tools/pip-requires file for the setuptools\n> install_requires parameter. In doing so, it will convert the URL for\n> oslo-config into just a package name.\n> \n> Unfortunately oslo-config doesn\'t exist in pypi, causing the install to\n> fail with an error similar to this:\n> \n> Downloading/unpacking oslo-config (from nova==2013.1.g3)\n>   Could not find any downloads that satisfy the requirement oslo-config\n> (from nova==2013.1.g3)\n> No distributions at all found for oslo-config (from nova==2013.1.g3)\n\nWhen you\'re installing this way, why isn\'t dependency_links being\nrespected?\n\n> It looks like the best way of fixing this is to get oslo-config into\n> pypi. Is there a reason it isn\'t already?\n> \n> Should we restrict URLs in pip-requires to avoid similar problems in the\n> future?\n\nIt\'s very much intentional that oslo-config isn\'t on pypi yet.\n\nDuring the development cycle between releases, we\'ll be adding APIs to\noslo libraries and making the various other projects consume those.\nDuring the development cycle, we may find ourselves introducing\nregressions or needing to change new APIs.\n\nI don\'t want pypi users to be subjected to any of that stability - oslo\nlibraries will have a release not long before the server projects are\nreleased and that will be what will be pushed to pypi. They\'ll also have\nreleases from their stable branches as an avenue to push bugfix only\nupdates to pypi.\n\nCheers,\nMark.\n\n\n\n','<20130225182513.GJ25371@sventech.com>',NULL),('<1361863936.2303.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-26 07:32:16',0,'2013-02-26 07:32:16',NULL,'[openstack-dev] nova dependencies, oslo-config and pypi','On Mon, 2013-02-25 at 17:26 -0800, Johannes Erdfelt wrote:\n> On Mon, Feb 25, 2013, Johannes Erdfelt <johannes at erdfelt.com> wrote:\n> > 1) Add the version to the egg fragment for oslo-config in\n> >    tools/pip-requires\n> \n> Oh yeah, oslo-config needs to be \"escaped\" like the docs say. So:\n> \n> #egg=oslo_config-2013.1b4\n\nBeautiful. Thanks Johannes. If it fixes it, I\'m fine with us doing that.\n\nCheers,\nMark.\n\n\n\n','<20130226012603.GL25371@sventech.com>',NULL),('<1361865319.10594321.1391106596495.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 13:29:56',-18000,'2014-01-30 18:29:56',NULL,'[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous\n hardware support','Wouldn\'t lying about the hardware specs when registering nodes be problematic for upgrades? Users would have \nto re-register their nodes. \n\nOne reason why a custom filter feels attractive is that it provides us with a clear upgrade path: \n\nIcehouse \n* nodes are registered with correct attributes \n* create a custom scheduler filter that allows any node to match \n* users are informed that for this release, Tuskar will not differentiate between heterogeneous hardware \n\nJ-Release \n* implement the proper use of flavors within Tuskar, allowing Tuskar to work with heterogeneous hardware \n* work with nova regarding scheduler filters (if needed) \n* remove the custom scheduler filter \n\nMainn \n\n----- Original Message -----\n\n> As far as nova-scheduler and Ironic go, I believe this is a solved problem.\n> Steps are:\n> - enroll hardware with proper specs (CPU, RAM, disk, etc)\n> - create flavors based on hardware specs\n> - scheduler filter matches requests exactly\n\n> There are, I suspect, three areas where this would fall short today:\n> - exposing to the user when certain flavors shouldn\'t be picked, because\n> there is no more hardware available which could match it\n> - ensuring that hardware is enrolled with the proper specs //\n> trouble-shooting when it is not\n> - a UI that does these well\n\n> If I understand your proposal correctly, you\'re suggesting that we introduce\n> non-deterministic behavior. If the scheduler filter falls back to >$flavor\n> when $flavor is not available, even if the search is in ascending order and\n> upper-bounded by some percentage, the user is still likely to get something\n> other than what they requested. From a utilization and inventory-management\n> standpoint, this would be a headache, and from a user standpoint, it would\n> be awkward. Also, your proposal is only addressing the case where hardware\n> variance is small; it doesn\'t include a solution for deployments with\n> substantially different hardware.\n\n> I don\'t think introducing a non-deterministic hack when the underlying\n> services already work, just to provide a temporary UI solution, is\n> appropriate. But that\'s just my opinion.\n\n> Here\'s an alternate proposal to support same-arch but different cpu/ram/disk\n> hardware environments:\n> - keep the scheduler filter doing an exact match\n> - have the UI only allow the user to define one flavor, and have that be the\n> lowest common denominator of available hardware\n> - assign that flavor\'s properties to all nodes -- basically lie about the\n> hardware specs when enrolling them\n> - inform the user that, if they have heterogeneous hardware, they will get\n> randomly chosen nodes from their pool, and that scheduling on heterogeneous\n> hardware will be added in a future UI release\n\n> This will allow folks who are using TripleO at the commandline to take\n> advantage of their heterogeneous hardware, instead of crippling\n> already-existing functionality, while also allowing users who have slightly\n> (or wildly) different hardware specs to still use the UI.\n\n> Regards,\n> Devananda\n\n> On Thu, Jan 30, 2014 at 7:14 AM, Tomas Sedovic < tsedovic at redhat.com > wrote:\n\n> > On 30/01/14 15:53, Matt Wagner wrote:\n> \n\n> > > On 1/30/14, 5:26 AM, Tomas Sedovic wrote:\n> > \n> \n\n> > > > Hi all,\n> > > \n> > \n> \n\n> > > > I\'ve seen some confusion regarding the homogenous hardware support as\n> > > \n> > \n> \n> > > > the first step for the tripleo UI. I think it\'s time to make sure we\'re\n> > > \n> > \n> \n> > > > all on the same page.\n> > > \n> > \n> \n\n> > > > Here\'s what I think is not controversial:\n> > > \n> > \n> \n\n> > > > 1. Build the UI and everything underneath to work with homogenous\n> > > \n> > \n> \n> > > > hardware in the Icehouse timeframe\n> > > \n> > \n> \n> > > > 2. Figure out how to support heterogenous hardware and do that (may or\n> > > \n> > \n> \n> > > > may not happen within Icehouse)\n> > > \n> > \n> \n\n> > > > The first option implies having a single nova flavour that will match\n> > > \n> > \n> \n> > > > all the boxes we want to work with. It may or may not be surfaced in\n> > > > the\n> > > \n> > \n> \n> > > > UI (I think that depends on our undercloud installation story).\n> > > \n> > \n> \n\n> > > > Now, someone (I don\'t honestly know who or when) proposed a slight step\n> > > \n> > \n> \n> > > > up from point #1 that would allow people to try the UI even if their\n> > > \n> > \n> \n> > > > hardware varies slightly:\n> > > \n> > \n> \n\n> > > > 1.1 Treat similar hardware configuration as equal\n> > > \n> > \n> \n\n> > > > The way I understand it is this: we use a scheduler filter that\n> > > > wouldn\'t\n> > > \n> > \n> \n> > > > do a strict match on the hardware in Ironic. E.g. if our baremetal\n> > > \n> > \n> \n> > > > flavour said 16GB ram and 1TB disk, it would also match a node with\n> > > > 24GB\n> > > \n> > \n> \n> > > > ram or 1.5TB disk.\n> > > \n> > \n> \n\n> > > > The UI would still assume homogenous hardware and treat it as such.\n> > > > It\'s\n> > > \n> > \n> \n> > > > just that we would allow for small differences.\n> > > \n> > \n> \n\n> > > > This *isn\'t* proposing we match ARM to x64 or offer a box with 24GB RAM\n> > > \n> > \n> \n> > > > when the flavour says 32. We would treat the flavour as a lowest common\n> > > \n> > \n> \n> > > > denominator.\n> > > \n> > \n> \n\n> > > Does Nova already handle this? Or is it built on exact matches?\n> > \n> \n\n> > It\'s doing an exact match as far as I know. This would likely involve\n> > writing\n> > a custom filter for nova scheduler and updating nova.conf accordingly.\n> \n\n> > > I guess my question is -- what is the benefit of doing this? Is it just\n> > \n> \n> > > so people can play around with it? Or is there a lasting benefit\n> > \n> \n> > > long-term? I can see one -- match to the closest, but be willing to give\n> > \n> \n> > > me more than I asked for if that\'s all that\'s available. Is there any\n> > \n> \n> > > downside to this being permanent behavior?\n> > \n> \n\n> > Absolutely not a long term thing. This is just to let people play around\n> > with\n> > the MVP until we have the proper support for heterogenous hardware in.\n> \n\n> > It\'s just an idea that would increase the usefulness of the first version\n> > and\n> > should be trivial to implement and take out.\n> \n\n> > If neither is the case or if we will in fact manage to have a proper\n> > heterogenous hardware support early (in Icehouse), it doesn\'t make any\n> > sense\n> > to do this.\n> \n\n> > > I think the lowest-common-denominator match will be familiar to\n> > \n> \n> > > sysadmins, too. Want to do RAID striping across a 500GB and a 750GB\n> > \n> \n> > > disk? You\'ll get a striped 500GB volume.\n> > \n> \n\n> > > ______________________________ _________________\n> > \n> \n> > > OpenStack-dev mailing list\n> > \n> \n> > > OpenStack-dev at lists.openstack. org\n> > \n> \n> > > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev\n> > \n> \n\n> > ______________________________ _________________\n> \n> > OpenStack-dev mailing list\n> \n> > OpenStack-dev at lists.openstack. org\n> \n> > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev\n> \n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/a8b1655a/attachment.html>\n\n','<CAExZKEpgx3Me6aL1hPtRsSi__wSEKCnUcJOETGLEzB0K_PrBEA@mail.gmail.com>',NULL),('<1361884605.2303.65.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-26 13:16:45',0,'2013-02-26 13:16:45',NULL,'[openstack-dev] Reminder: Project & release status meeting - 21:00\n UTC','On the agenda of the Project & release status meeting for today:\n\nWith grizzly-3 out and ttx in absentia, Thierry has asked me to cover\nthe following for each project:\n\n  1. Check progress on features that got exceptions\n  2. Check RC1 buglists\n  3. Consider new exceptions, if any\n\nI expect it\'ll be relatively short!\n\nFeel free to add extra topics to the agenda:\n[1] http://wiki.openstack.org/Meetings/ProjectMeeting\n\nAll Project Technical Leads should be present (if you can\'t make it,\nplease name a substitute on [1]). Everyone else is very welcome to attend.\n\nThe meeting will be held at 21:00 UTC on the #openstack-meeting channel\non Freenode IRC. You can look up how this time translates locally at:\n[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130219T21\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1361900451.719218832@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-26 12:40:51',-18000,'2013-02-26 17:40:51',NULL,'[openstack-dev] nova dependencies, oslo-config and pypi','\nGlance is showing similar behavior too on glance-api restart\n \n[https://bugs.launchpad.net/glance/+bug/1133416] https://bugs.launchpad.net/glance/+bug/1133416\n \n-----Original Message-----\nFrom: \"Monty Taylor\" <mordred at inaugust.com>\nSent: Monday, February 25, 2013 10:49pm\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] nova dependencies, oslo-config and pypi\n\n\n\nThanks Johannes!\n\nAlso - jeez. lifeless and I are going to try to corner some folks about\nthis at pycon...\n\nOn 02/25/2013 08:26 PM, Johannes Erdfelt wrote:\n> On Mon, Feb 25, 2013, Johannes Erdfelt <johannes at erdfelt.com> wrote:\n>> 1) Add the version to the egg fragment for oslo-config in\n>>    tools/pip-requires\n> \n> Oh yeah, oslo-config needs to be \"escaped\" like the docs say. So:\n> \n> #egg=oslo_config-2013.1b4\n> \n> JE\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130226/c2cdebf0/attachment.html>\n\n','<512C30D5.2010805@inaugust.com>',NULL),('<1361961588.2365.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 10:39:48',0,'2013-02-27 10:39:48',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing 2.0\n breaking jenkins jobs]','On Wed, 2013-02-27 at 18:40 +1100, Kieran Spear wrote:\n> It must be a day for breaking releases. pyparsing 2.0 was just uploaded to\n> pypi and is not compatible with python 2.x.\n> Quantumclient is pulling it in.\n> \n> See:\n> \n> https://review.openstack.org/#/c/22295/\n> http://logs.openstack.org/22295/2/gate/gate-horizon-python26/1655/console.html\n> \n> quantumclient has been fixed to pin pyparsing [1], but the commit hasn\'t\n> made it into a pypi release yet.\n> Do we need a 2.1.1 release of quantumclient?\n\nYou know, pinning should only ever be a short-term solution. At some\npoint, distributions are going to have the newer version of any given\npackage and we need to be able to work with that.\n\nReally, any time we pin to a specific dependency version we should also\nfile a bug to track the work needed to unpin it again.\n\nThanks,\nMark.\n\n\n\n','<CAP4hQKOh5EpdK-oNknPmuiTuYKdWqRVrg_ug6+m_Y3-qSRoyhg@mail.gmail.com>',NULL),('<1361972629.2365.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 13:43:49',0,'2013-02-27 13:43:49',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','On Wed, 2013-02-27 at 08:09 -0500, Eoghan Glynn wrote:\n> Folks,\n> \n> When looking into an error encountered on a keystone db sync,\n> I noticed some apparent strangeness in the way keystone schema\n> migrations have been managed.\n> \n> Specifically the *rewriting* of schema migration history, see:\n> \n>   https://github.com/openstack/keystone/commit/5bc46d86\n> \n> In my (albeit imperfect) understanding of sqlalchemy-migrate, this\n> reordering seems to defeat the whole purpose of step-wise reversible\n> migration.\n> \n> Would it even be possible to migrate a grizzly-2 deployment to\n> grizzly-3 with that re-ordering in place? \n> \n> Maybe I\'ve missed something here, but I\'d appreciate some clarity\n> on what is considered community best practice in terms of changes\n> to the migration sequence.\n> \n> Previously I would have assumed something like ...\n> \n> Invariants we maintain:\n> \n>  - DB schemas must always be migrate-able across milestone releases\n\n(snip good stuff)\n\nIt\'s more than just across milestone releases, we should support\nupgrading from commit to commit. In Nova, at least, we\'re trying hard to\navoid messing up those who are deploying continuously. I\'d expect any\nnova-core member to reject this patch immediately.\n\nWhat I really don\'t understand is how this concern wasn\'t raised in the\nreview at all:\n\n  https://review.openstack.org/19780\n\nCheers,\nMark.\n\n\n\n','<1827645920.37903856.1361970554466.JavaMail.root@redhat.com>',NULL),('<1361976017.2365.70.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 14:40:17',0,'2013-02-27 14:40:17',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','On Wed, 2013-02-27 at 08:09 -0600, Dolph Mathews wrote:\n> This was discussed in #openstack-dev, as I recall.\n\nI see this:\n\n  http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2013-01-16.log\n  2013-01-16T16:41:09  <dolphm> henrynash: i assume my change needs to\n  come in the migration sequence ahead of yours, correct?\n\nand no discussion about impact on people\'s ability to upgrade.\n\nBut even if it was fully discussed on irc ... frankly, that\'s not\nenough. This is a big deal and needs broader input than whoever happened\nto be listening on #openstack-dev at the time.\n\nAlso, a summary of what was discussed on #openstack-dev in the review\nwould have been good.\n\n> The goal in these migrations was to support folsom <--> grizzly, not\n> necessarily supporting intermediate milestones. I\'m not aware of\n> anyone doing continuous deployments of keystone, if but if migrating\n> commit to commit is the community\'s expectation, I\'m more happy to\n> ensure that happens moving forward -- I just wasn\'t aware that was a\n> concern here.\n\nCommit to commit is one thing, but this even breaks grizzly-2 to\ngrizzly-3.\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gWfia0sJJip=pMu_iyFSFn_qvA55CdZCwGBj_wTUCyydA@mail.gmail.com>',NULL),('<1361980245.2365.78.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-27 15:50:45',0,'2013-02-27 15:50:45',NULL,'[openstack-dev] [keystone] re-ordering of schema migrations','On Wed, 2013-02-27 at 14:40 +0000, Mark McLoughlin wrote:\n> On Wed, 2013-02-27 at 08:09 -0600, Dolph Mathews wrote:\n> > This was discussed in #openstack-dev, as I recall.\n> \n> I see this:\n> \n>   http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2013-01-16.log\n>   2013-01-16T16:41:09  <dolphm> henrynash: i assume my change needs to\n>   come in the migration sequence ahead of yours, correct?\n> \n> and no discussion about impact on people\'s ability to upgrade.\n\nOk, apparently it was discussed on a different review:\n\n  https://review.openstack.org/21951\n\n  ayoung: You cannot add the constraint in an old upgrade. Once an\n  upgrade is in the tree, any changes to the schema have to happen in a\n  new upgrade.\n\n  dolphm: on the block, I\'m not aware of anyone doing continuous\n  deployment of keystone (are you?), so I\'m comfortable revising our\n  recent migration history (between named releases).\n\nI guess I\'m surprised to think that individual projects would think\nthey\'d have their own policy on this sort of stuff rather than it being\na cross-project policy, but it\'s reassuring to see that the problem was\nat least considered and discussed.\n\nCheers,\nMark.\n\n\n\n','<1361976017.2365.70.camel@sorcha>',NULL),('<1362033834.2370.12.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 06:43:54',0,'2013-02-28 06:43:54',NULL,'[openstack-dev] nova dependencies, oslo-config and pypi','On Mon, 2013-02-25 at 17:26 -0800, Johannes Erdfelt wrote:\n> On Mon, Feb 25, 2013, Johannes Erdfelt <johannes at erdfelt.com> wrote:\n> > 1) Add the version to the egg fragment for oslo-config in\n> >    tools/pip-requires\n> \n> Oh yeah, oslo-config needs to be \"escaped\" like the docs say. So:\n> \n> #egg=oslo_config-2013.1b4\n\nTrying this out, this ends up in nova.egg-info/requires.txt as:\n\n  oslo_config-2013.1b4\n\nwhich doesn\'t make much sense to me?\n\nCheers,\nMark.\n\n\n\n','<20130226012603.GL25371@sventech.com>',NULL),('<1362033844.2370.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 06:44:04',0,'2013-02-28 06:44:04',NULL,'[openstack-dev] oslo-config and debian packaging','On Thu, 2013-02-28 at 00:02 -0500, Eric Windisch wrote:\n> It turns out that oslo-config and Debian packaging create at least a\n> little bit of a mess, as I\'ve discovered when attempting to do so. \n> \n> Packages depending on oslo-config will depend on \'oslo.config\' in\n> their setup.py. Debian packaging will, at least by default, map this\n> to \'python-oslo.config\'.  However, the sdist tarball and the directory\n> said tarball creates are, well, \"oslo-config\", not \"oslo.config\". This\n> means that the packages we create for \'oslo-config\' will be called\n> \'python-oslo-config\'.  To clarify and reiterate, this means packages\n> will depend on \'python-oslo.config\', but the package will actually be\n> called \'python-oslo-config\'.\n\nHmm, it\'s your first statement I don\'t get - why will packages depend on\noslo.config in their setup.py?\n\nIn nova, I\'m seeing this in nova.egg-info/requires.txt:\n\n  oslo-config\n\nCheers,\nMark.\n\n\n\n','<A07B849863064C45A59E88FDF450FA1E@cloudscaling.com>',NULL),('<1362035212.2370.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 07:06:52',0,'2013-02-28 07:06:52',NULL,'[openstack-dev] pyparsing 2.0 postmortem','On Wed, 2013-02-27 at 16:29 -0500, Sean Dague wrote:\n> On 02/27/2013 03:51 PM, Russell Bryant wrote:\n> > So I\'m not sure that the problems Sean has described here should be\n> > considered a disaster.  They seem to be just one of the things our\n> > testing should be catching for us.\n> \n> I\'m not sure I\'d call them disaster, but they at least are a calamity.\n> \n> > It\'s not just about getting updates for free.  It\'s about finding out\n> > when our software is no longer compatible with an upstream dependency.\n> > It means we found out as soon as we could that there is work to do to\n> > update project X to be compatible with new version of dependency Y.  We\n> > have to find this out somehow sometime.\n> \n> Here\'s the thing though, because all our software requires all the rest \n> of our software to go through the gate, the current process isn\'t \n> getting that answer. The pain threshold of a broken merge queue is too \n> high, and the ability to explore removing dependency limitations is too \n> hard.\n> \n> I\'ll use the example from yesterday:\n> \n> django 1.5 comes out. Horizon as setup by devstack doesn\'t do something \n> right by it. The gate stops merging any code. Nova, glance, tempest \n> development is now blocked.\n\nI accept the problem statement - these changes upstream of us shouldn\'t\nbreak the gate.\n\nWe\'ve talked about using the PyPi mirroring infrastructure to solve\nthis ... we wouldn\'t allow new versions to be synced into the mirror if\nit causes the tests to break.\n\nSo, upstream chances would break the PyPI mirror sync and we\'d fix that\nby pinning and filing a bug to sort out the compat issue. Same end\nresult (i.e. good data, issue found early) but the gate doesn\'t get\nbroken.\n\n> So the answer is pin it as fast as you can because right now horizon is \n> preventing all other projects from doing anything. There really isn\'t \n> time to figure out the right fix, because you\'ve got 400 contributors \n> sitting on their hands, unable to get anything through CI.\n> \n> so we pin, move on. it didn\'t solve the issue, and the issue got thrown \n> on the back burner because there are bigger fish to fry. Most of the \n> pins in pip-requires showed up because of\n> similar issues.\n\nThe issue hasn\'t been fixed, but it has been identified. We now know\nthat Horizon needs fixing to work with Django 1.5. This is really\nimportant data.\n\n> > Pinning seems like a fine short term fix for this, but only along with a\n> > bug for fixing compatibility with this new version of the dependency.\n> >\n> > I think I could buy pinning everything in stable branches since we\n> > wouldn\'t be doing work in stable branches to chase new versions of\n> > dependencies, but not in master.\n> \n> I think that for sure we need to pin in stable branches, otherwise it\'s \n> pretty bad bit rot.\n\nWe discussed this at length before:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html\n\nand couldn\'t come to a conclusion about what should into setup.py as our\nrequires. Pinning is nasty because it artificially limits what versions\nof dependencies you can install with.\n\nCheers,\nMark.\n\n\n\n','<512E7AD2.30805@linux.vnet.ibm.com>',NULL),('<1362049783.2370.28.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 11:09:43',0,'2013-02-28 11:09:43',NULL,'[openstack-dev] oslo-config and debian packaging','On Thu, 2013-02-28 at 16:00 +0800, Thomas Goirand wrote:\n> It is annoying to put that in all and every package for Openstack, so it\n> would be nicer to avoid it and have \"oslo-config\" as python module name,\n> rather than oslo.config, but it is workable still. \n\nYou\'re suggesting:\n\n  -package = \'oslo-config\'\n  +package = \'oslo.config\'\n\nin oslo-config\'s setup.py? I\'m totally open to persuaded on that. Anyone\nwant to list the reasons why the latter makes more sense than the\nformer?\n\nThis is the kind of stuff I want to get sorted out before we push to\npypi.\n\nCheers,\nMark.\n\n\n\n','<512F0EA7.30408@debian.org>',NULL),('<1362052788.2370.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 11:59:48',0,'2013-02-28 11:59:48',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Wed, 2013-02-27 at 14:43 -0500, Doug Hellmann wrote:\n> On Wed, Feb 27, 2013 at 1:44 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> > On 02/27/2013 01:38 PM, Sean Dague wrote:\n\n> > > Various respected python community members, it would be really awesome\n> > > to solve this as a root issue, get pypi to not allow uploads that don\'t\n> > > specify, and have it be part of the installer. Would be good for\n> > > everyone, not just OpenStack.\n> >\n> > Python is talking about serveral major upgrades to PyPI - I\'ll toss this\n> > one in the mix.\n> >\n> \n> +1 Participating in the packaging summit at PyCon in a few weeks should go\n> a long way.\n\nI\'ve just sent a slightly desperate plea to psf-members. See attached.\n\n(Yes, I\'ve also purchased a brand new asbestos suit)\n\nCheers,\nMark.\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Mark McLoughlin <markmc at redhat.com>\nSubject: Library instability on PyPI and impact on OpenStack\nDate: Thu, 28 Feb 2013 11:56:36 +0000\nSize: 3890\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130228/93b67255/attachment.mht>\n\n','<CADb+p3RVFP8e0pGTBBptYBfD=EKb7Hdih+zp3k5R6bmgBHD0oQ@mail.gmail.com>',NULL),('<1362057383.2370.64.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 13:16:23',0,'2013-02-28 13:16:23',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Thu, 2013-02-28 at 22:29 +1030, Christopher Yeoh wrote:\n> On Wed, 27 Feb 2013 10:36:52 -0500\n> Sean Dague <sdague at linux.vnet.ibm.com> wrote:\n> > If no one wants the gate to work before noon EST any more we can\n> > leave things unpinned. With pycon in 2 weeks I\'m sure these are not\n> > the only 2 breaks we\'re going to see on this.\n> > \n> > I agree we need some way of figuring out that it\'s safe to move\n> > forward, but the current model means we can loose 1/2 day of merging\n> > because of something we don\'t control at all.\n> \n> How about this:\n> \n> - What if by default we pin *everything*. \n> - Have a CI machine running a job in the background that uses the\n>   latest version of everything except where we explicitly pin to a\n>   specific version because of a known issue.\n> - Have that job notify us when the gating tests pass with a later version\n>   of a package succeeds\n>   - maybe this can be automatically passed on to the normal gating\n>     machines and automatically upgrade the pinned version specified.\n> - Have the job loudly and repeatedly tell us when the system is broken\n>   with a newer package (have it spam openstack-dev mailing list and IRC)\n>   so people will know and be motivated to fix it.\n> \n> That way we find out about compatibility problems ASAP but we have a\n> controlled way of managing the changes necessary into projects and not\n> end up with the gate stalled for hours at random times.\n\nIt\'s not just about the gate, it\'s also about the software we ship. The\nideal is that all our dependencies listed in setup.py are >= because\nthat allows our software to be installed in more environments.\n\nCheers,\nMark.\n\n\n\n','<20130228222954.04850cda@rockhopper>',NULL),('<1362064265.2370.93.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 15:11:05',0,'2013-02-28 15:11:05',NULL,'[openstack-dev] nova dependencies, oslo-config and pypi','On Thu, 2013-02-28 at 06:30 -0800, Johannes Erdfelt wrote:\n> On Thu, Feb 28, 2013, Mark McLoughlin <markmc at redhat.com> wrote:\n> > On Mon, 2013-02-25 at 17:26 -0800, Johannes Erdfelt wrote:\n> > > On Mon, Feb 25, 2013, Johannes Erdfelt <johannes at erdfelt.com> wrote:\n> > > > 1) Add the version to the egg fragment for oslo-config in\n> > > >    tools/pip-requires\n> > > \n> > > Oh yeah, oslo-config needs to be \"escaped\" like the docs say. So:\n> > > \n> > > #egg=oslo_config-2013.1b4\n> > \n> > Trying this out, this ends up in nova.egg-info/requires.txt as:\n> > \n> >   oslo_config-2013.1b4\n> > \n> > which doesn\'t make much sense to me?\n> \n> See the second bullet point in my original post, you only did the first\n> bullet point :)\n\nAh, apologies.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-February/005975.html\n\n> 2) Fix the regular expression in parse_requirements (in\n>   nova/openstack/common/setup.py) to exclude the version from the\n>   match\n\nAlso to unescape from oslo_config to oslo-config?\n\nThanks,\nMark.\n\n\n\n','<20130228143015.GV25371@sventech.com>',NULL),('<1362066224.2370.98.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 15:43:44',0,'2013-02-28 15:43:44',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Thu, 2013-02-28 at 11:59 +0000, Mark McLoughlin wrote:\n> On Wed, 2013-02-27 at 14:43 -0500, Doug Hellmann wrote:\n> > On Wed, Feb 27, 2013 at 1:44 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> > > On 02/27/2013 01:38 PM, Sean Dague wrote:\n> \n> > > > Various respected python community members, it would be really awesome\n> > > > to solve this as a root issue, get pypi to not allow uploads that don\'t\n> > > > specify, and have it be part of the installer. Would be good for\n> > > > everyone, not just OpenStack.\n> > >\n> > > Python is talking about serveral major upgrades to PyPI - I\'ll toss this\n> > > one in the mix.\n> > >\n> > \n> > +1 Participating in the packaging summit at PyCon in a few weeks should go\n> > a long way.\n> \n> I\'ve just sent a slightly desperate plea to psf-members. See attached.\n\nRedirected here:\n\n  http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html\n\nNick Coghlan points out PEP426 which is relevant:\n\n  http://www.python.org/dev/peps/pep-0426/\n\nCheers,\nMark.\n\n\n\n','<1362052788.2370.61.camel@sorcha>',NULL),('<1362085396.269.1366526864402.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-21 06:47:44',0,'2013-04-21 06:47:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #11','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/11/>\n\n------------------------------------------\n[...truncated 5015 lines...]\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.09\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    2.33\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.08\n    test_pool_delete                                             OK    0.10\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.08\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.07\n    test_delete_pool_health_monitor                              OK    0.08\n    test_health_monitor_create                                   OK    0.07\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.07\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.07\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    2.42\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.07\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.09\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.08\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.09\n    test_vip_update                                              OK    0.08\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.01\n    test_get_instance_id_network_id_no_match                     OK    0.01\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.01\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.01\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.01\n    test_main                                                    OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.01\n    test_proxy_request_network_418                               OK    0.01\n    test_proxy_request_network_500                               OK    0.00\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.02\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.01\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.02\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.08\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.02\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    2.45\n    testQuantumContextCreate                                     OK    0.01\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.37\n    test_quotas_default_values                                   OK    0.42\n    test_show_quotas_with_admin                                  OK    0.31\n    test_show_quotas_without_admin_forbidden                     OK    0.37\n    test_update_quotas_forbidden                                 OK    0.32\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.32\n    test_show_quotas_with_admin                                  OK    2.56\n    test_show_quotas_without_admin_forbidden                     OK    0.19\n    test_update_quotas_forbidden                                 OK    0.19\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.26\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.30\n    test_list_quotas_with_admin                                  OK    0.26\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.29\n    test_quotas_default_values                                   OK    0.31\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    2.67\n    test_quotas_get_tenant_from_request_context                  OK    0.19\n    test_quotas_limit_check                                      OK    0.20\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.27\n    test_quotas_limit_check_with_over_quota                      OK    0.24\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.35\n    test_show_quotas_with_owner_tenant                           OK    2.61\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.18\n    test_update_attributes                                       OK    0.20\n    test_update_quotas_with_admin                                OK    0.20\n    test_update_quotas_with_non_integer_returns_400              OK    0.19\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.20\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.20\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    2.96\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.27\n    test_list_quotas_with_admin                                  OK    0.34\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.35\n    test_quotas_default_values                                   OK    0.23\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.19\n    test_quotas_get_tenant_from_request_context                  OK    0.19\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    2.58\n    test_quotas_limit_check_with_over_quota                      OK    0.20\n    test_quotas_loaded_bad_returns_404                           OK    0.19\n    test_quotas_loaded_right                                     OK    0.19\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_with_owner_tenant                           OK    0.19\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.19\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    2.61\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.19\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.19\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.60\n    test_KillFilter_deleted_exe                                  OK    0.01\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.02\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.43\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    0.28\n    test_health_monitor_update_with_router_id                    OK    0.24\n    test_health_monitor_update_without_router_id                 OK    0.25\n    test_pool_create                                             OK    0.24\n    test_pool_delete_with_router_id                              OK    3.76\n    test_pool_delete_without_router_id                           OK    0.23\n    test_pool_update_with_router_id                              OK    0.21\n    test_pool_update_without_router_id                           OK    0.23\n    test_router_create_no_service_type_id                        OK    0.20\n    test_router_create_with_service_type_id                      OK    0.20\n    test_router_delete                                           OK    0.22\n    test_router_get                                              OK    0.20\n    test_router_update_with_service_type_id                      OK    0.20\n    test_router_update_without_service_type_id                   OK    0.22\n    test_vip_create                                              OK    0.26\n    test_vip_delete_with_router_id                               OK    0.31\n    test_vip_delete_without_router_id                            OK    2.91\n    test_vip_update_with_router_id                               OK    0.25\n    test_vip_update_without_router_id                            OK    0.29\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.41\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.41\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.48\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.42\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.39\n    test_security_group_rules_for_devices_ipv6_source_group      Build timed out (after 30 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n++ rm -rf /tmp/tmp.oMiOdGvDSp\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1: 28041 Terminated              tox -e$venv\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/11\n[SCP] Copying console log.\n\n\n','<258616463.251.1366440321554.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1362095052.08712290@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 18:44:12',-18000,'2013-02-28 23:44:12',NULL,'[openstack-dev] [nova] Implementing extensions links in nova.','\nHi,\n \nMy recent experience with writing an extension for nova made me wonder why the links are not implemented for the extensions in general. The resource defaults the links value to an empty list and returns the same for all implemented extensions.\n \nAfter brainstorming with certain individuals, the feedback was that such implementation could make certain code shaky. Although the implementation seems straightforward at the first sight, just wanted to get some thoughts and inputs especially if someone is directly affected by this.\n \nCreated a blueprint: [https://blueprints.launchpad.net/nova/+spec/nova-extensions-links] https://blueprints.launchpad.net/nova/+spec/nova-extensions-links\n \nthanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130228/11e40cdc/attachment.html>\n\n',NULL,NULL),('<1362119051.51288.YahooMailRC@web181703.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-28 22:24:11',-28800,'2013-03-01 06:24:11',NULL,'[openstack-dev] VMs can\'t access outside world..','Hi,\n I posted this on the General Discussions but didn\'t get any answer. I also \nfound someone post similar issue back on Dec but didn\'t get an answer neither \n So I hope someone from the Dev side can help.\n\nI installed Folsom on CentOS6.3.  It has 2 NIC ( the server has 4 but I only use \ntwo and disable the other two ).  I used Quantum + LinuxBridge.  VM provisioning \nis fine and it got an ip address.  I assigned floatingIP and create security ( \nallow icmp and ssh ).  I can SSH to the VM from outside through the floatingIP. \n However, when I am inside the VM, I can\'t access anything outside of the VM or \nmy openstack infrastructure.  Here is the information I can provide\n\n\n\nOS - CentOS6.3 ( single node - everything are running there , eg cinder, nova, \ncompute, glance.... )\nOpenstack Folsom\nQuantum - LinuxBridge\nSingle node with two NIC ( em1 and em 3.  They are on different VLAN on the \nphysical switch ).\n\n\n\n/etc/sysctl.conf\nnet.ipv4.ip_forward = 1\nnet.ipv4.conf.default.rp_filter = 0\nnet.ipv4.conf.default.accept_source_route = 0\nkernel.sysrq = 0\nkernel.core_uses_pid = 1\nnet.ipv4.tcp_syncookies = 1\nnet.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1\nnet.bridge.bridge-nf-call-arptables = 1\nkernel.msgmnb = 65536\nkernel.msgmax = 65536\nkernel.shmmax = 68719476736\nkernel.shmall = 4294967296\n\n\n\n\n\n/etc/sysconfig/modules/openstack-quantum-linuxbridge.modules\n#!/bin/sh\nmodprobe -b bridge >/dev/null 2>&1\nexit 0\n\n\n\n\n/etc/sysconfig/network-scripts/ifcfg-em1\nDEVICE=\"em1\"\nBOOTPROTO=\"static\"\nDNS1=\"10.99.99.1\"\nGATEWAY=\"10.38.0.254\"\nIPADDR=\"10.38.15.251\"\nIPV6INIT=\"no\"\nMTU=\"1500\"\nNETMASK=\"255.255.0.0\"\nNM_CONTROLLED=\"yes\"\nONBOOT=\"yes\"\nTYPE=\"Ethernet\"\n\n\n\n\n/etc/sysconfig/network-scripts/ifcfg-em3\nDEVICE=\"em3\"\nBOOTPROTO=\"none\"\nNM_CONTROLLED=\"yes\"\nONBOOT=\"yes\"\nTYPE=\"Ethernet\"\n\n\n\n\n/etc/nova/nova.conf\n[DEFAULT]\nlogdir = /var/log/nova\nstate_path = /var/lib/nova\nlock_path = /var/lib/nova/tmp\nvolumes_dir = /etc/nova/volumes\ndhcpbridge = /usr/bin/nova-dhcpbridge\ndhcpbridge_flagfile = /etc/nova/nova.conf\nforce_dhcp_release = True\ninjected_network_template = /usr/share/nova/interfaces.template\nlibvirt_nonblocking = True\nlibvirt_inject_partition = -1\nnetwork_manager = nova.network.manager.FlatDHCPManager\niscsi_helper = tgtadm\nsql_connection = mysql://nova:nova at localhost/nova\ncompute_driver = libvirt.LibvirtDriver\nfirewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver\nrpc_backend = nova.openstack.common.rpc.impl_qpid\nrootwrap_config = /etc/nova/rootwrap.conf\nflat_interface = em3\npublic_interface = em1\nauth_strategy = keystone\nqpid_hostname =opst01\nglance_api_servers = optst01:9292\nglance_host = opst01\nvolume_api_class = nova.volume.cinder.API\nenabled_apis = ec2,osapi_compute,metadata\nnetwork_api_class = nova.network.quantumv2.api.API\nquantum_admin_username = quantum\nquantum_admin_password = quantum\n#quantum_admin_auth_url = http://localhost:5000/v2.0/\nquantum_admin_auth_url = http://localhost:35357/v2.0/\nquantum_auth_strategy = keystone\nquantum_admin_tenant_name = service\nquantum_url = http://opst01:9696/\nlibvirt_vif_driver = nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriver\n[keystone_authtoken]\nadmin_token = 111111111111111\n\n\n\n\n\n/etc/quantum/l3_agent.ini\n[DEFAULT]\ndebug = True\ninterface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver\nadmin_token = 111111111111111\nroot_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf\nexternal_network_bridge = \nuse_namespaces = False\nrouter_id = 1a8fd530-56d2-4192-b3fe-1f77651cbf41\n\n\n\n\n\n/etc/quantum/plugin.ini\n[VLANS]\ntenant_network_type = vlan\nnetwork_vlan_ranges = physnet1,physnet2:100:199\n[DATABASE]\nsql_connection = mysql://quantum:quantum at optst01/quantum_linux_bridge\nreconnect_interval = 2\n[LINUX_BRIDGE]\nphysical_interface = em1,em3\nphysical_interface_mappings = physnet1:em1,physnet2:em3\n[AGENT]\npolling_interval = 2\nroot_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf\n\n\n\n\n\n[root at opst01 quantum]# route -n\nKernel IP routing table\nDestination     Gateway         Genmask         Flags Metric Ref    Use Iface\n192.168.151.0   0.0.0.0         255.255.255.0   U     0      0        0 \nns-b21309cd-11\n192.168.151.0   0.0.0.0         255.255.255.0   U     0      0        0 \nqr-ec728fdd-44\n10.38.17.0      0.0.0.0         255.255.255.0   U     0      0        0 \nqg-28179e3d-dc\n10.38.0.0       0.0.0.0         255.255.0.0     U     0      0        0 \nbrq6b600334-9f\n169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 em3\n0.0.0.0         10.38.0.254     0.0.0.0         UG    100    0        0 \nbrq6b600334-9f\n\n\n\n\n\n[root at optst01 quantum]# service iptables status\nTable: nat\nChain PREROUTING (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-compute-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0           \n2    quantum-l3-agent-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0       \n    \n3    nova-api-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain POSTROUTING (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-compute-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0         \n  \n2    quantum-l3-agent-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0       \n    \n3    quantum-postrouting-bottom  all  --  0.0.0.0/0            0.0.0.0/0         \n  \n4    nova-api-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0           \n5    nova-postrouting-bottom  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain OUTPUT (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-compute-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n2    quantum-l3-agent-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n3    nova-api-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain nova-api-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-POSTROUTING (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-PREROUTING (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-float-snat (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-snat (1 references)\nnum  target     prot opt source               destination         \n1    nova-api-float-snat  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain nova-compute-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-POSTROUTING (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-PREROUTING (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-float-snat (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-snat (1 references)\nnum  target     prot opt source               destination         \n1    nova-compute-float-snat  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain nova-postrouting-bottom (1 references)\nnum  target     prot opt source               destination         \n1    nova-compute-snat  all  --  0.0.0.0/0            0.0.0.0/0           \n2    nova-api-snat  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain quantum-l3-agent-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-POSTROUTING (1 references)\nnum  target     prot opt source               destination         \n1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           ! ctstate \nDNAT \n\nChain quantum-l3-agent-PREROUTING (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-float-snat (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-snat (1 references)\nnum  target     prot opt source               destination         \n1    quantum-l3-agent-float-snat  all  --  0.0.0.0/0            0.0.0.0/0       \n    \n2    SNAT       all  --  192.168.151.0/24     0.0.0.0/0           to:10.38.17.1 \n\nChain quantum-postrouting-bottom (1 references)\nnum  target     prot opt source               destination         \n1    quantum-l3-agent-snat  all  --  0.0.0.0/0            0.0.0.0/0           \n\nTable: filter\nChain INPUT (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-compute-INPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n2    quantum-l3-agent-INPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n3    nova-api-INPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain FORWARD (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-filter-top  all  --  0.0.0.0/0            0.0.0.0/0           \n2    nova-compute-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0           \n3    quantum-filter-top  all  --  0.0.0.0/0            0.0.0.0/0           \n4    quantum-l3-agent-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0         \n  \n5    nova-api-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain OUTPUT (policy ACCEPT)\nnum  target     prot opt source               destination         \n1    nova-filter-top  all  --  0.0.0.0/0            0.0.0.0/0           \n2    nova-compute-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n3    quantum-filter-top  all  --  0.0.0.0/0            0.0.0.0/0           \n4    quantum-l3-agent-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n5    nova-api-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain nova-api-FORWARD (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-INPUT (1 references)\nnum  target     prot opt source               destination         \n1    ACCEPT     tcp  --  0.0.0.0/0            10.38.15.251        tcp dpt:8775 \n\nChain nova-api-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-api-local (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-FORWARD (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-INPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-inst-20 (1 references)\nnum  target     prot opt source               destination         \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID \n2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state \nRELATED,ESTABLISHED \n3    nova-compute-provider  all  --  0.0.0.0/0            0.0.0.0/0           \n4    ACCEPT     udp  --  192.168.151.2        0.0.0.0/0           udp spt:67 \ndpt:68 \n5    ACCEPT     all  --  192.168.151.0/24     0.0.0.0/0           \n6    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           \n7    ACCEPT     icmp --  192.168.151.3        0.0.0.0/0           \n8    ACCEPT     icmp --  192.168.151.4        0.0.0.0/0           \n9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 \n10   nova-compute-sg-fallback  all  --  0.0.0.0/0            0.0.0.0/0         \n  \n\nChain nova-compute-inst-21 (1 references)\nnum  target     prot opt source               destination         \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID \n2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state \nRELATED,ESTABLISHED \n3    nova-compute-provider  all  --  0.0.0.0/0            0.0.0.0/0           \n4    ACCEPT     udp  --  192.168.151.2        0.0.0.0/0           udp spt:67 \ndpt:68 \n5    ACCEPT     all  --  192.168.151.0/24     0.0.0.0/0           \n6    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           \n7    ACCEPT     icmp --  192.168.151.3        0.0.0.0/0           \n8    ACCEPT     icmp --  192.168.151.4        0.0.0.0/0           \n9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 \n10   nova-compute-sg-fallback  all  --  0.0.0.0/0            0.0.0.0/0         \n  \n\nChain nova-compute-local (1 references)\nnum  target     prot opt source               destination         \n1    nova-compute-inst-20  all  --  0.0.0.0/0            192.168.151.3       \n2    nova-compute-inst-21  all  --  0.0.0.0/0            192.168.151.4       \n\nChain nova-compute-provider (2 references)\nnum  target     prot opt source               destination         \n\nChain nova-compute-sg-fallback (2 references)\nnum  target     prot opt source               destination         \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain nova-filter-top (2 references)\nnum  target     prot opt source               destination         \n1    nova-compute-local  all  --  0.0.0.0/0            0.0.0.0/0           \n2    nova-api-local  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain quantum-filter-top (2 references)\nnum  target     prot opt source               destination         \n1    quantum-l3-agent-local  all  --  0.0.0.0/0            0.0.0.0/0           \n\nChain quantum-l3-agent-FORWARD (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-INPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-OUTPUT (1 references)\nnum  target     prot opt source               destination         \n\nChain quantum-l3-agent-local (1 references)\nnum  target     prot opt source               destination         \n\n\n\n',NULL,NULL),('<1362132590.2455.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-01 10:09:50',0,'2013-03-01 10:09:50',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Fri, 2013-03-01 at 20:27 +1030, Christopher Yeoh wrote:\n> On Thu, 28 Feb 2013 13:16:23 +0000\n> Mark McLoughlin <markmc at redhat.com> wrote:\n> > > That way we find out about compatibility problems ASAP but we have a\n> > > controlled way of managing the changes necessary into projects and\n> > > not end up with the gate stalled for hours at random times.\n> > \n> > It\'s not just about the gate, it\'s also about the software we ship.\n> > The ideal is that all our dependencies listed in setup.py are >=\n> > because that allows our software to be installed in more environments.\n> > \n> \n> That\'s true, though there\'s no reason we can\'t in general ship with >=\n> dependencies, but have the gate test with specific versions required,\n> where that version is the latest we know that works (determined through\n> some automated testing to warn us of problems ahead).\n\nI\'d like us to be testing with two dependency stacks - both the minimum\nrequired versions and the latest available versions - but that\'s a ways\naway yet.\n\nThe instability in the gate is best fixed by only updating the pypi\nmirror when the update doesn\'t break the gate. If a pypi mirror update\nfails, that means something is broken upstream of us and we either need\nto get the upstream fixed or pin to a specific version.\n\nAdvantage is we know when something has broken and we can investigate it\nwithout the \"OMG, the gate is hosed!\" pressure.\n\nCheers,\nMark.\n\n\n\n','<20130301202710.5a450967@rockhopper>',NULL),('<1362141336.2455.12.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-01 12:35:36',0,'2013-03-01 12:35:36',NULL,'[openstack-dev] oslo-config and debian packaging','On Thu, 2013-02-28 at 13:02 +0000, Daviey Walker wrote:\n> On 28 February 2013 08:00, Thomas Goirand <zigo at debian.org> wrote:\n> > On 02/28/2013 01:02 PM, Eric Windisch wrote:\n> >> It turns out that oslo-config and Debian packaging create at least\n> >> a little bit of a mess, as I\'ve discovered when attempting to do so.\n> >>\n> >> Packages depending on oslo-config will depend on \'oslo.config\' in\n> >> their setup.py. Debian packaging will, at least by default, map\n> >> this to \'python-oslo.config\'.\n> >\n> > This could be overwritten. When it comes to Debian packages, I have put\n> > manually python-oslo-config as (build-)dependency. With g3, I haven\'t\n> > seen any problem.\n> >\n> > Are you here talking about *Ubuntu* packages, and not *Debian*?\n> >\n> >> However, the sdist tarball and the\n> >> directory said tarball creates are, well, \"oslo-config\", not\n> >> \"oslo.config\".\n> >\n> > Debian doesn\'t use tarballs, but git tags for the packaging.\n> >\n> >> This means that the packages we create for\n> >> \'oslo-config\' will be called \'python-oslo-config\'.\n> >\n> > Yeah, that\'s the Debian policy for python... I don\'t see why having\n> > python- in front is a problem. dh_python2 doesn\'t really care.\n> <SNIP>\n> \n> In Ubuntu, we also currently have it overridden in debian/pydist-overrides.\n> \n> However, we discussed this last week with fellow Ubuntu developers, as\n> the Ubuntu package was called python-oslo-config.  We are planning to\n> re-name it to python-oslo.config on the next upload to reflect the\n> convention that has been formed.\n> \n> Prior art is things such as, \"python-zope.interfaces\"\n\nWell, depends on what you mean \"prior art\"\n\nIt\'s prior art for a python project with a namespace package using the\n$namespace.$submodule naming format i.e. in setup.py\n\n  name=\"zope.interface\"\n\nIt makes complete sense for debian/ubuntu packaging to call their\npackages python-zope.interface\n\nHowever, in this case, oslo has gone for the $namespace-$submodule\nnaming format i.e.\n\n  name=\"oslo-config\"\n\nSo, in this case, debian/ubuntu should stick with python-oslo-config.\nThere presumably isn\'t prior art for debian/ubuntu to use a different\nname from the upstream package.\n\nNow ... what I am open to is an argument that $namespace.$submodule is a\nconvention generally recommended for all python projects with a\nnamespace package. Is anyone arguing that, though?\n\nThanks,\nMark.\n\n\n\n','<CACyjiAh7pTs1RZoPPJ6HxjZHbFPHGnHdhXeDfW9tN9Dih-vfag@mail.gmail.com>',NULL),('<1362142610.2455.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-01 12:56:50',0,'2013-03-01 12:56:50',NULL,'[openstack-dev] oslo-config and debian packaging','On Fri, 2013-03-01 at 12:35 +0000, Mark McLoughlin wrote:\n> On Thu, 2013-02-28 at 13:02 +0000, Daviey Walker wrote:\n> > On 28 February 2013 08:00, Thomas Goirand <zigo at debian.org> wrote:\n> > > On 02/28/2013 01:02 PM, Eric Windisch wrote:\n> > >> It turns out that oslo-config and Debian packaging create at least\n> > >> a little bit of a mess, as I\'ve discovered when attempting to do so.\n> > >>\n> > >> Packages depending on oslo-config will depend on \'oslo.config\' in\n> > >> their setup.py. Debian packaging will, at least by default, map\n> > >> this to \'python-oslo.config\'.\n> > >\n> > > This could be overwritten. When it comes to Debian packages, I have put\n> > > manually python-oslo-config as (build-)dependency. With g3, I haven\'t\n> > > seen any problem.\n> > >\n> > > Are you here talking about *Ubuntu* packages, and not *Debian*?\n> > >\n> > >> However, the sdist tarball and the\n> > >> directory said tarball creates are, well, \"oslo-config\", not\n> > >> \"oslo.config\".\n> > >\n> > > Debian doesn\'t use tarballs, but git tags for the packaging.\n> > >\n> > >> This means that the packages we create for\n> > >> \'oslo-config\' will be called \'python-oslo-config\'.\n> > >\n> > > Yeah, that\'s the Debian policy for python... I don\'t see why having\n> > > python- in front is a problem. dh_python2 doesn\'t really care.\n> > <SNIP>\n> > \n> > In Ubuntu, we also currently have it overridden in debian/pydist-overrides.\n> > \n> > However, we discussed this last week with fellow Ubuntu developers, as\n> > the Ubuntu package was called python-oslo-config.  We are planning to\n> > re-name it to python-oslo.config on the next upload to reflect the\n> > convention that has been formed.\n> > \n> > Prior art is things such as, \"python-zope.interfaces\"\n> \n> Well, depends on what you mean \"prior art\"\n> \n> It\'s prior art for a python project with a namespace package using the\n> $namespace.$submodule naming format i.e. in setup.py\n> \n>   name=\"zope.interface\"\n> \n> It makes complete sense for debian/ubuntu packaging to call their\n> packages python-zope.interface\n> \n> However, in this case, oslo has gone for the $namespace-$submodule\n> naming format i.e.\n> \n>   name=\"oslo-config\"\n> \n> So, in this case, debian/ubuntu should stick with python-oslo-config.\n> There presumably isn\'t prior art for debian/ubuntu to use a different\n> name from the upstream package.\n> \n> Now ... what I am open to is an argument that $namespace.$submodule is a\n> convention generally recommended for all python projects with a\n> namespace package. Is anyone arguing that, though?\n\nAn example of another project not using that format is PasteDeploy - it\ninstalls into the \'paste\' namespace package and yet isn\'t called\n\'paste.deploy\'\n\nIf it was straightforward, I\'d write a script to look at all the\nnamespace packages on pypi and compare.\n\nCheers,\nMark.\n\n\n\n','<1362141336.2455.12.camel@sorcha>',NULL),('<1362214090.17431.4.camel@varinia.lobefin.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-02 08:48:10',0,'2013-03-02 08:48:10',NULL,'[openstack-dev] FFE request for EC2 tags API','Hi,\n\nI sent a mail a month ago about adding a tags API to the EC2 API, and\nthe consensus at the time was to do it by using the native API rather\nthan creating a bespoke EC2 solution.  Unfortunately, work pulled me in\nother directions for a bit, but I\'ve got it on review now:\nhttps://review.openstack.org/#/c/23256/\nhttps://review.openstack.org/#/c/23258/\n\nI realize these are arriving late, but we find this ability incredibly\nuseful.  They are minimally intrusive, so hopefully you\'ll find them\nacceptable.\n\nCheers,\n-- \nStephen Gran\nSenior Systems Integrator - guardian.co.uk\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit guardian.co.uk - website of the year\n \nwww.guardian.co.uk    www.observer.co.uk     www.guardiannews.com \n \nOn your mobile, visit m.guardian.co.uk or download the Guardian\niPhone app www.guardian.co.uk/iphone and iPad edition www.guardian.co.uk/iPad \n \nSave up to 32% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. \nVisit guardian.co.uk/subscribe\n \n---------------------------------------------------------------------\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n\n\n',NULL,NULL),('<1362231153.2332.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-02 13:32:33',0,'2013-03-02 13:32:33',NULL,'[openstack-dev] [Keystone][Oslo] Caching tokens in auth token\n middleware','On Fri, 2013-03-01 at 18:32 -0500, Russell Bryant wrote:\n> >> 3) Move memorycache into oslo and sync it to nova and keystoneclient:\n> >>\n> >> https://review.openstack.org/23306\n> >> https://review.openstack.org/23308\n> >> https://review.openstack.org/23309\n> >>\n> >> I think 3) is the right long term move, but I\'m not sure if this appropriate considering how close we are to the grizzly release, so if we want to do 2) immediately and postpone 3) until H, that is fine with me.\n> > \n> > Well, I think 3) is the right thing to do in any case, and can be done\n> > in oslo regardless of Nova\'s RC status.\n> > \n> > Not sure that 2) is really all that useful. If you are in any serious\n> > production environment, you\'re going to be using memcached anyway.\n> \n> +1 that 3 is ideal.  I think this should have been done with a FFE for\n> Oslo.  It got merged in Oslo already anyway, though ... \n\nThe Oslo commit merged quickly while I wasn\'t looking, but I when I saw\nit post-merge I figured it\'s fine without an FFE.\n\nIt\'s just moving code from nova.common to nova.openstack.common\nessentially. No major regression risk, no impact on users, no massive\ndistraction of reviewers.\n\nAdding it to keystoneclient also doesn\'t need an FFE since we don\'t do\nfeature freezes for clients.\n\nCheers,\nMark.\n\n\n\n','<51313A8B.5080304@redhat.com>',NULL),('<1362256350.S.2806.23719.H.TmNvbW11bml0eS1yZXF1ZXN0QGxpc3RzLm9wZW5zdABXZWxjb21lIHRvIHRoZSAiQ29tbXVuaXR5IiBtYWk_.RU.rfs266,\n rfs266, 895, 361.f4-235-162.1362258933.3450@webmail.rediffmail.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-03-02 21:15:33',0,'2013-03-02 21:15:33',NULL,'[openstack-community] virtualwrapper error while installation devstack','Hi All,\n\n\n\n       I am installing devstack using git script.\n\n       but at the end of installation I am hitting to virtualwrapper permission denied error.\n\n       If I give all the permission to .virtualenv & runs installation, again It is giving me\n\n       error.\n\n       If anybody knows the solution of this, please help me on this problem.\n\n       It will be great help for me.\n\n\n\nRegards,\n\nDigambar\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130302/6e90ae6b/attachment.html>\n\n',NULL,NULL),('<1362327784.5909.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-03 16:23:04',0,'2013-03-03 16:23:04',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Thu, 2013-02-28 at 15:43 +0000, Mark McLoughlin wrote:\n> On Thu, 2013-02-28 at 11:59 +0000, Mark McLoughlin wrote:\n> > On Wed, 2013-02-27 at 14:43 -0500, Doug Hellmann wrote:\n> > > On Wed, Feb 27, 2013 at 1:44 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> > > > On 02/27/2013 01:38 PM, Sean Dague wrote:\n> > \n> > > > > Various respected python community members, it would be really awesome\n> > > > > to solve this as a root issue, get pypi to not allow uploads that don\'t\n> > > > > specify, and have it be part of the installer. Would be good for\n> > > > > everyone, not just OpenStack.\n> > > >\n> > > > Python is talking about serveral major upgrades to PyPI - I\'ll toss this\n> > > > one in the mix.\n> > > >\n> > > \n> > > +1 Participating in the packaging summit at PyCon in a few weeks should go\n> > > a long way.\n> > \n> > I\'ve just sent a slightly desperate plea to psf-members. See attached.\n> \n> Redirected here:\n> \n>   http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html\n> \n> Nick Coghlan points out PEP426 which is relevant:\n> \n>   http://www.python.org/dev/peps/pep-0426/\n\nAnother follow-up on distutils-sig attached.\n\nThe conclusion I\'m coming to from the discussion is that by and large\nPython library maintainers try to avoid incompatible changes and they\nhave commitments to stability built into their versioning schemes. We\nneed to understand each library\'s versioning scheme and do e.g.\n\n  sqlalchemy>=0.7.8,<0.8\n\nbecause we know that a minor version number change in sqlalchemy is used\nto warn people of an incompatible change whereas other libraries we can\ndo:\n\n  foo>=1.2.3,<2\n\nbecause we know they\'re using the semantic versioning and will only make\nincompatible API changes in version 2 whereas still others we can do:\n\n  bar>=2.2\n\nbecause we know they will introduce a new \'bar2\' library if they need to\nmake incompatible changes.\n\nNot fun, but way better than pinning to specific versions IMHO.\n\nCheers,\nMark.\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Mark McLoughlin <markmc at redhat.com>\nSubject: Re: Library instability on PyPI and impact on OpenStack\nDate: Sun, 03 Mar 2013 15:54:33 +0000\nSize: 9184\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130303/895e0bf6/attachment.mht>\n\n','<1362066224.2370.98.camel@sorcha>',NULL),('<1362395621.5909.45.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 11:13:41',0,'2013-03-04 11:13:41',NULL,'[openstack-dev] [Heat] Upwards compatibility in templates','On Mon, 2013-03-04 at 10:56 +0100, Zane Bitter wrote:\n> [Taking this to openstack-dev, because I think it\'s an important discussion]\n> \n> There\'s a debate going on in https://review.openstack.org/23157 \n> regarding to what extent we should try to handle upwards compatibility \n> of templates in Heat. The issue in question is how to handle Resource \n> properties that are not defined. At present, this is almost always due \n> to a typo on the part of the template creator, and it would be highly \n> desirable to return an error (as AWS does). On the other hand, this may \n> not always be the case if we add properties to resources in future.\n> \n> As I wrote in a review comment, let us say that cloud provider G rolls \n> out a Grizzly-based OpenStack cloud, and then later cloud provider H \n> rolls out a Havana-based cloud, where we\'ve added a bunch of properties \n> to resources. Templates written for cloud provider H that use these \n> properties will now fail to launch on cloud provider G if we strictly \n> enforce properties. This is a problem that AWS does not have. The \n> question is, do we care?\n\nSo long as we support the other way around - i.e. the template written\nagainst G works on H - then it\'s exactly what I\'d expect.\n\nIt\'s similar to what I\'d expect with e.g. Python APIs - if I want my app\nto work with version 1.1 and version 1.2, then I write my app against\n1.1 and assume that 1.2 is backwards compatible with 1.1.\n\nCheers,\nMark.\n\n\n\n','<51346FB9.6040408@redhat.com>',NULL),('<1362402216.5909.81.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 13:03:36',0,'2013-03-04 13:03:36',NULL,'[openstack-dev] Ceilometer PTL candidacy','Hi Nick,\n\nOn Mon, 2013-03-04 at 13:17 +0100, Nicolas Barcet wrote:\n> As I do not think it is a good practice, nor completely practical to\n> be both a PTL and a board member, I will not seek a third mandate as\n> Ceilometer\'s project lead. \n\nWow, I find that a really sad statement.\n\nIf you mean there\'s a conflict of interest between representing the Gold\nMembers on the Board and representing Ceilometers\' contributors on the\nTechnical Committee, then I don\'t see it - we all wear multiple hats and\nneed to figure out a way to juggle them in an upfront and honest way.\nThe conflict of interest argument taken to an extreme would mean that\ne.g. no affiliated developers should be allowed on the TC.\n\nIf you mean there\'s only so much anybody can achieve with their time and\nthat a PTL should dedicate all their available time to that task, then I\nalso don\'t see it - we all have multiple responsibilities and no PTL\ndedicates all of their time to the role.\n\nIf you mean that, in your case, there\'s only time to dedicate to one of\nthe roles, then I can understand that - but what makes me sad is that\nanyone would see the role of Board member as taking priority over the\nrole of PTL of an Integrated project. I take the opposite view - the\ndifference a PTL can make to OpenStack is far greater than the\ndifference a member of the 24 person Board can make.\n\nI think you\'ve done a great job of leading Ceilometer to date and\ntestament to that is the project has a bunch of strong technical leaders\n(e.g. Doug, Eoghan, Julien and Angus) any of which would be awesome as\nPTL. You guys have built a great team.\n\nI would just hate this \"Board members shouldn\'t be PTLs and vice-versa\"\nattitude to take hold in the project. I\'d like to see the technical\nleadership of the project take a far more active role in the Foundation,\nnot less.\n\nThanks,\nMark.\n\n\n\n','<CAEcpoL8QQB9X69-6NPMN+OsSvr9=QPaTMZrdLRK4M8xY+o5_EQ@mail.gmail.com>',NULL),('<1362402964.5909.90.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 13:16:04',0,'2013-03-04 13:16:04',NULL,'[openstack-dev] Oslo PTL candidacy','Hi,\n\nI\'d like to put my name forward as a candidate for Oslo PTL.\n\nI\'ve only been PTL for 6 months, so hopefully what I wrote last time\nshould still apply. Let see!\n\n  https://lists.launchpad.net/openstack/msg16443.html\n  (edited to s/openstack-common/Oslo/ and s/PPB/TC/)\n\n  ---\n  I helped start the project with Jason K?lker in January and wrote the\n  plan we\'ve been following:\n\n    http://wiki.openstack.org/Oslo\n\n  Since then, I\'ve been doing reviews, triaging bugs and organizing the\n  blueprints for the project. At the Folsom Design Summit, I lead\n  several sessions on Oslo related topics.\n\n  I also wrote the cfg API and worked to ensure its use across\n  OpenStack.\n\n  Recently, the TC decided that Oslo should officially have a PTL and I \n  was appointed to the position in the interim.\n\n  As elected PTL, I would increase my focus on moving the project \n  forward. My goals for the Grizzly cycle would be:\n\n  - Finalize the renaming of the project to Oslo\n  - Rename the openstack-common repo to oslo-incubator\n  - Promote the cfg and rpc APIs out of incubation\n  - Agree on a versioning scheme for oslo-* releases\n  - Release the first versions of the oslo-config and oslo-messaging \n    packages\n  - Help with merging services infrastructure, WSGI and DB APIs into \n    the incubator\n  - Help OpenStack projects adopt existing incubating APIs\n  - Clear out some of the unused/stale APIs out of the incubator\n\n  Like all other PTLs, I would also do my best to encourage new \n  contributors, guide the development of new features, review patches,\n  triage bugs and serve as a contact point for the project.\n  ---\n\nMost of the above has been accomplished, so for Havana I think the\nprimary goals of the project should be:\n\n  - Promote the rpc APIs out of incubation as the oslo-messaging library\n  - Ensure the recently added service infrastructure APIs are adopted \n    by Nova\n  - Ensure the recently added scheduler filter APIs are adopted by Nova\n  - Make some progress on a WSGI API all projects can use\n\nThanks!\nMark\n\n\n\n',NULL,NULL),('<1362404713.5909.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 13:45:13',0,'2013-03-04 13:45:13',NULL,'[openstack-dev] Pinning deps at RC1 (was: pyparsing 2.0\n postmortem)','On Mon, 2013-03-04 at 14:14 +0100, Thierry Carrez wrote:\n> Sean Dague wrote:\n> > I think that for sure we need to pin in stable branches, otherwise it\'s\n> > pretty bad bit rot.\n> \n> About that: when we discussed this at the last Summit, the plan was to\n> pin all dependencies as part of the plan to produce RC1. Something like\n> running a script that would propose a change automatically translating\n> the current state into pinning, and apply that to milestone-proposed\n> just after it\'s cut, just before we tag RC1.\n\nRight. I went ahead and wrote that script and then we realized this is\nactually a really bad idea:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html\n\ni.e. the reasons we didn\'t do it on stable/folsom apply equally to\ngrizzly.\n\nThe issue is that pinning to a specific version in setup.py\ninstall_requires severely limits what our releases can be installed on.\n\nWhat we want is a solution that limits the version range to the minimum\nrequired version and some unknown, future version which is likely to\nhave incompatible changes. The discussion on distutils-sig is mostly\nabout figuring out how to do that. It\'s hard, but I think we\'re making\nprogress.\n\nCheers,\nMark.\n\n\n\n','<51349E4D.2030401@openstack.org>',NULL),('<1362429243.5909.168.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-04 20:34:03',0,'2013-03-04 20:34:03',NULL,'[openstack-dev] Adding write capability in oslo-config','Hi Thomas,\n\nOn Tue, 2013-03-05 at 01:29 +0800, Thomas Goirand wrote:\n> Hi,\n> \n> As much as I can see, the only thing which oslo-config does is *reading*\n> the config files for an openstack project.\n\nA nitpick perhaps, but oslo-config\'s niche is reading config values from\nthe combination of the command line and config files. If you want simply\nwant to use a config files, it doesn\'t have a huge amount to offer.\n\n> It doesn\'t seems that it is possible to use the same API to actually\n> write values.\n> \n> As I do the Debian packaging, I would be happy to use oslo-config to be\n> able to read / write values in the different configuration files of\n> Openstack. I need to do that, for example to read, then set the\n> sql_connection DSN string in each package, as Openstack is integrated\n> with dbconfig-common in Debian.\n> \n> The problem is that oslo-config doesn\'t currently provides a command\n> line tool. Though it would be really trivial to do:\n> oslo-config-get /etc/keystone/keystone.conf \\\n> 	DEFAULT admin_token\n> \n> so that I could use that from my debian/*.config scripts.\n> \n> But then I would also need in a debian/*.postinst script:\n> oslo-config-set /etc/keystone/keystone.conf \\\n> 	DEFAULT admin_token <password>\n> \n> which isn\'t currently implemented at all in oslo-config. oslo-config\n> currently can only *read* .ini files, it can\'t actually *write*\n> directives in them.\n> \n> While I currently need the above in my Debian packaging, I am quite sure\n> that it would be helpful for anyone willing to write automation tools to\n> deploy Openstack, so I am convinced it would be helpful for others to\n> add write functions in oslo-config.\n> \n> Would anyone who worked on oslo-config have some time to write this?\n\nDefinitely planned, but it didn\'t get done in time for Grizzly:\n\n  https://blueprints.launchpad.net/oslo/+spec/oslo-config-cli\n\nIn Fedora, we use this:\n\n  https://github.com/fedora-openstack/openstack-utils/blob/master/utils/openstack-config\n\nbut that doesn\'t handle multi-str options.\n\n> Also, reading the code, it seems that the parser doesn\'t even implement\n> sections, which surprised me. Is this something planned? Or is it\n> specified that there will never be any 2 of the same directive in\n> different sections of a given configuration file?\n\nWe definitely support sections (aka \'groups\'), see e.g.\n\n  https://github.com/openstack/oslo-config/blob/59b6720/tests/test_cfg.py#L1043\n\nCheers,\nMark.\n\n\n\n','<5134DA0E.8030902@debian.org>',NULL),('<1362492135.5909.332.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 14:02:15',0,'2013-03-05 14:02:15',NULL,'[openstack-dev] RFC: last minute changes to Oslo library versioning\n	and naming','Hey,\n\nThe thread on naming of namespace packages[1] and the discussion about\nPEP426 on distutils-sig[2] have lead me to these conclusion:\n\n  - Naming the package oslo.config is a better choice than oslo-config. \n    I don\'t think there\'s necessarily a standard for naming these \n    things but it seems more likely that period-separated will become\n    more common than hyphen-separated (i.e. zope.interface vs\n    oslo-config)\n\n  - The date based 2013.1 version is likely to be disallowed by PEP426\n    when it is ratified and we\'ll end up making the date based version\n    a \"private version\" but 0.2013.1 would be the version on PyPI. Uggh.\n\n  - I\'m coming around to the idea of using semantic versioning (i.e. \n    x.y.z) and increasing the major number when removing any deprecated \n    APIs. That certainly is the trend expressed in PEP426 and on \n    distutils-sig. I\'d be far more reluctant to actually remove \n    deprecated APIs, though, so this would change our policy from \n    \"remove APIs after a year of deprecation\" to \"very rarely making \n    any incompatible changes to our APIs\"\n\n  - With semantic versioning, I figure we\'d increase the micro number \n    when we do release from the stable branch and increase the minor \n    number with every coordinated OpenStack release.\n\nIn practical terms, I\'m proposing doing:\n\n -package = \'oslo-config\'\n -version = \'2013.1\'\n +package = \'oslo.config\'\n +version = \'1.1.0\'\n\nin oslo-config\'s setup.py\n\nI know this is painful for packagers. In Fedora, I\'ll have to set an\n\"epoch\" which packagers always hate doing. In Debian, it\'ll probably\nmean the package name changing to python-oslo.config.\n\nHowever, this is why we didn\'t publish directly to PyPI - we wanted the\nopportunity to catch issues like this. So, I\'m thinking we should just\ngo for it ASAP.\n\nThoughts?\n\nThanks,\nMark.\n\n[1] - http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6078\n[2] - http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054\n\n\n\n\n',NULL,NULL),('<1362499701.5909.344.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 16:08:21',0,'2013-03-05 16:08:21',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n versioning and naming','On Tue, 2013-03-05 at 10:29 -0500, Doug Hellmann wrote:\n> \n> \n> On Tue, Mar 5, 2013 at 9:02 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         Hey,\n>         \n>         The thread on naming of namespace packages[1] and the discussion about\n>         PEP426 on distutils-sig[2] have lead me to these conclusion:\n>         \n>           - Naming the package oslo.config is a better choice than oslo-config.\n>             I don\'t think there\'s necessarily a standard for naming these\n>             things but it seems more likely that period-separated will become\n>             more common than hyphen-separated (i.e. zope.interface vs\n>             oslo-config)\n>         \n>           - The date based 2013.1 version is likely to be disallowed by PEP426\n>             when it is ratified and we\'ll end up making the date based version\n>             a \"private version\" but 0.2013.1 would be the version on PyPI. Uggh. \n>         \n>           - I\'m coming around to the idea of using semantic versioning (i.e.\n>             x.y.z) and increasing the major number when removing any deprecated\n>             APIs. That certainly is the trend expressed in PEP426 and on\n>             distutils-sig. I\'d be far more reluctant to actually remove\n>             deprecated APIs, though, so this would change our policy from\n>             \"remove APIs after a year of deprecation\" to \"very rarely making\n>             any incompatible changes to our APIs\"\n> \n> \n> +1 to semantic versioning\n> \n> \n> -0 to not cleaning up deprecated APIs\n\nThanks\n\n>           - With semantic versioning, I figure we\'d increase the micro number\n>             when we do release from the stable branch and increase the minor\n>             number with every coordinated OpenStack release.\n> \n> \n> And the major number?\n\nIf/when we ever remove deprecated APIs.\n\n>         In practical terms, I\'m proposing doing:\n>         \n>          -package = \'oslo-config\'\n>          -version = \'2013.1\'\n>          +package = \'oslo.config\'\n>          +version = \'1.1.0\'\n> \n> \n> Why not 1.0.0?\n\nA weak, silly 2013.1.0-2012 approach :)\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3RQMhpYamKVagdRQqfmgK+tRvZQv4vhPqCTeGCsJo1eaQ@mail.gmail.com>',NULL),('<1362500808.5909.345.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 16:26:48',0,'2013-03-05 16:26:48',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n versioning and naming','On Tue, 2013-03-05 at 09:23 -0500, Davanum Srinivas wrote:\n> Mark,\n> \n> Are we going to use  X.Y (Major.Minor) or X.Y.Z (Major.Minor.Patch)?\n> Assuming the latter, When would we bump up Z?\n\nCovered in the first mail:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-March/006283.html\n\n  - With semantic versioning, I figure we\'d increase the micro number \n    when we do release from the stable branch and increase the minor \n    number with every coordinated OpenStack release.\n\nCheers,\nMark.\n\n\n\n','<CANw6fcEuDK8CuWoTbeMWGkooC4RnYSgaSDCytK3M4XUrpKNW=A@mail.gmail.com>',NULL),('<1362503968.3189.8.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 11:19:28',-21600,'2013-03-05 17:19:28',NULL,'[openstack-dev] Problems with jenkins','On Tue, 2013-03-05 at 18:55 +0200, Gary Kotton wrote:\n> Can anyone help here: \n> http://logs.openstack.org/23570/2/check/gate-quantum-pep8/5424/console.html\n> Locally the pep8 tests pass.\n\nLooks like a transient error copying the logs from a pep8 run; just\n\"recheck\" or \"reverify\" as appropriate?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5136239B.909@redhat.com>',NULL),('<1362515374.5909.357.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 20:29:34',0,'2013-03-05 20:29:34',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n versioning and naming','On Wed, 2013-03-06 at 02:05 +0800, Thomas Goirand wrote:\n> On 03/05/2013 10:02 PM, Mark McLoughlin wrote:\n> > In practical terms, I\'m proposing doing:\n> > \n> >  -package = \'oslo-config\'\n> >  -version = \'2013.1\'\n> >  +package = \'oslo.config\'\n> >  +version = \'1.1.0\'\n> > \n> > in oslo-config\'s setup.py\n> \n> I\'m sorry, I will have to be the bad guy complaining and ranting here. I\n> hate to do so, but I have to explain what the consequences can be, since\n> it doesn\'t seem to be understood or known.\n\nI can\'t really advise you on what to do about Debian packages or not\nconflicting with what Ubuntu are doing - you\'re best placed to figure\nthat out.\n\nA few things strike me as odd, though:\n\n  - If changes like this are such a huge hassle for Debian packagers, \n    then Debian probably shouldn\'t be packaging pre-release OpenStack\n\n  - There\'s not much you can do about coordinating with Ubuntu, if they \n    go ahead with their own approach anyway\n\n  - This is an awful lot of verbiage about something that is a little \n    painful to me as a packager and other packagers have also replied\n    \"uggh, but ok ... not a huge deal\"\n\nAgain, my case for biting the bullet and going with this:\n\n  - Only a pre-release development snapshot has been made available so \n    far\n\n  - We\'re changing the versioning scheme, which is disruptive anyway\n\n  - We\'re all agreed that oslo.config naming makes more sense than \n    oslo-config\n\n  - Debian can choose to stick with the python-oslo-config name if \n    renaming to python-oslo.config is so much hassle\n\nThanks,\nMark.\n\n\n\n','<513633DE.3080401@debian.org>',NULL),('<1362519351.5909.359.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 21:35:51',0,'2013-03-05 21:35:51',NULL,'[openstack-dev] Configuration files group/section case\n consistency between projects','On Tue, 2013-03-05 at 20:16 +0200, Alessandro Pilotti wrote:\n> Hi guys,\n> \n> We recently moved the nova.conf Hyper-V options to a dedicated group\n> and we ended up having different casings for the options group in Nova\n> and Quantum, as section casing conventions differs between the\n> projects. E.g.:\n> \n> nova.conf:\n> [hyperv]\n> \n> quantum.conf:\n> [HYPERV] \n> \n> This inconsistency can lead to a lot of issues from a user\n> perspective, as it\'s quite difficult to troubleshoot this type of\n> configuration file errors. IMHO a common convention should be decided\n> and applied consistently across all OpenStack projects. Since the\n> [DEFAULT] group is uppercase, I\'d go with this casing, but anything\n> else is fine as long as it is consistent.  \n> \n> In a recent chat on the #openstack-nova channel, markmc proposed to do\n> case insensitive group names matching, which IMO would be a perfect\n> solution.\n> This is also supported by the fact that historically sections (groups)\n> names are case insensitive in the INI format used by OpenStack:\n> http://en.wikipedia.org/wiki/INI_file#Case_insensitivity  \n\nI\'ve registered this Havana blueprint:\n\nhttps://blueprints.launchpad.net/oslo/+spec/cfg-lowercase-groups\n\nCheers,\nMark.\n\n\n\n','<090E0206-CEEE-4273-B1C1-8C9E5F92B0AB@pilotti.it>',NULL),('<1362521152.5909.362.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 22:05:52',0,'2013-03-05 22:05:52',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n versioning and naming','On Tue, 2013-03-05 at 14:02 +0000, Mark McLoughlin wrote:\n> Hey,\n> \n> The thread on naming of namespace packages[1] and the discussion about\n> PEP426 on distutils-sig[2] have lead me to these conclusion:\n> \n>   - Naming the package oslo.config is a better choice than oslo-config. \n>     I don\'t think there\'s necessarily a standard for naming these \n>     things but it seems more likely that period-separated will become\n>     more common than hyphen-separated (i.e. zope.interface vs\n>     oslo-config)\n> \n>   - The date based 2013.1 version is likely to be disallowed by PEP426\n>     when it is ratified and we\'ll end up making the date based version\n>     a \"private version\" but 0.2013.1 would be the version on PyPI. Uggh.\n> \n>   - I\'m coming around to the idea of using semantic versioning (i.e. \n>     x.y.z) and increasing the major number when removing any deprecated \n>     APIs. That certainly is the trend expressed in PEP426 and on \n>     distutils-sig. I\'d be far more reluctant to actually remove \n>     deprecated APIs, though, so this would change our policy from \n>     \"remove APIs after a year of deprecation\" to \"very rarely making \n>     any incompatible changes to our APIs\"\n> \n>   - With semantic versioning, I figure we\'d increase the micro number \n>     when we do release from the stable branch and increase the minor \n>     number with every coordinated OpenStack release.\n> \n> In practical terms, I\'m proposing doing:\n> \n>  -package = \'oslo-config\'\n>  -version = \'2013.1\'\n>  +package = \'oslo.config\'\n>  +version = \'1.1.0\'\n> \n> in oslo-config\'s setup.py\n> \n> I know this is painful for packagers. In Fedora, I\'ll have to set an\n> \"epoch\" which packagers always hate doing. In Debian, it\'ll probably\n> mean the package name changing to python-oslo.config.\n> \n> However, this is why we didn\'t publish directly to PyPI - we wanted the\n> opportunity to catch issues like this. So, I\'m thinking we should just\n> go for it ASAP.\n\nThanks for everyone\'s input. I\'ve pushed these changes for review:\n\n  https://review.openstack.org/23621\n  https://review.openstack.org/23622\n\nI think it\'s clear we should make the versioning change. The name change\nI\'m less certain about, but my instinct tells me we should take the\nopportunity to get it right now.\n\nThanks,\nMark.\n\n\n\n','<1362492135.5909.332.camel@sorcha>',NULL),('<1362524847.5909.382.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 23:07:27',0,'2013-03-05 23:07:27',NULL,'[openstack-dev] Dependency version pinning [was Re: Pyparsing\n 2.0 breaking jenkins jobs]','On Sun, 2013-03-03 at 16:23 +0000, Mark McLoughlin wrote:\n> On Thu, 2013-02-28 at 15:43 +0000, Mark McLoughlin wrote:\n> > On Thu, 2013-02-28 at 11:59 +0000, Mark McLoughlin wrote:\n> > > On Wed, 2013-02-27 at 14:43 -0500, Doug Hellmann wrote:\n> > > > On Wed, Feb 27, 2013 at 1:44 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> > > > > On 02/27/2013 01:38 PM, Sean Dague wrote:\n> > > \n> > > > > > Various respected python community members, it would be really awesome\n> > > > > > to solve this as a root issue, get pypi to not allow uploads that don\'t\n> > > > > > specify, and have it be part of the installer. Would be good for\n> > > > > > everyone, not just OpenStack.\n> > > > >\n> > > > > Python is talking about serveral major upgrades to PyPI - I\'ll toss this\n> > > > > one in the mix.\n> > > > >\n> > > > \n> > > > +1 Participating in the packaging summit at PyCon in a few weeks should go\n> > > > a long way.\n> > > \n> > > I\'ve just sent a slightly desperate plea to psf-members. See attached.\n> > \n> > Redirected here:\n> > \n> >   http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html\n> > \n> > Nick Coghlan points out PEP426 which is relevant:\n> > \n> >   http://www.python.org/dev/peps/pep-0426/\n> \n> Another follow-up on distutils-sig attached.\n> \n> The conclusion I\'m coming to from the discussion is that by and large\n> Python library maintainers try to avoid incompatible changes and they\n> have commitments to stability built into their versioning schemes. We\n> need to understand each library\'s versioning scheme and do e.g.\n> \n>   sqlalchemy>=0.7.8,<0.8\n> \n> because we know that a minor version number change in sqlalchemy is used\n> to warn people of an incompatible change whereas other libraries we can\n> do:\n> \n>   foo>=1.2.3,<2\n> \n> because we know they\'re using the semantic versioning and will only make\n> incompatible API changes in version 2 whereas still others we can do:\n> \n>   bar>=2.2\n> \n> because we know they will introduce a new \'bar2\' library if they need to\n> make incompatible changes.\n> \n> Not fun, but way better than pinning to specific versions IMHO.\n\nTo follow up some more ... the distutils-sig thread is really quite\nenlightening IMHO:\n\n  http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054\n\nI\'ve some notes below, but the tl;dr is that unless we \"cap\" our\nrequirement ranges we\'re going to be hit by incompatible updates. Each\nproject has a different policy on how their version number and we\'ll\nactually need to talk to each project we use about their policy.\n\nWhat we want is e.g.\n\n  sqlalchemy>=0.7.8,<0.8\n\nbut only after talking to sqlalchemy to confirm that they will bump the\nminor number iff they are making incompatible changes.\n\nWhat we need is a combination of (a) the openstack/requirements repo,\n(b) capping our requirements as described above and (c) a PyPI mirror\nthat is only refreshed if the refresh doesn\'t break the gate\n\nCheers,\nMark.\n\nNotes on PEP426:\n\n  - A trend towards semantic versioning. Any project that we know is \n    using this versioning scheme, we should cap our requirement range \n    to avoid incompatible updates e.g.\n\n        foo>=1.2.3,<2.0\n\n  - A new operator (sometimes known as the \'spermy\' operator in Ruby) \n    is being introduced. In PEP426, it\'s expressed as:\n\n      Requires-Dist: foo (1.2)\n\n    but in pip-requires, it\'s likely to be:\n\n      foo~>1.2\n\n    any version in the 1.x series greater than 1.2 satisfies this. If \n    you wanted 1.2.3 or later but also to avoid 2.x, you\'d do:\n\n      foo~>1.2,>=1.2.3\n\n  - Not all projects will use semantic versioning, but it is expected \n    that all projects have some policy on how their version number will \n    reflect incompatible updates. There is currently no metadata that \n    projects can use to publish this information, so we actually need \n    to talk to each upstream individually.\n\n  - There is currently no sane support for installing multiple \n    incompatible versions of the same library except \"use venv\". This \n    isn\'t a problem for OpenStack per-se, but it is a problem for \n    distributors. Nick Coghlan had some ideas for how this could be \n    improved in future:\n\n      http://mail.python.org/pipermail/distutils-sig/2013-March/020082.html\n\n  - There will be support for a library saying which version of Python \n    it requires. Presumably that would prevent us auto-updating to a \n    library which doesn\'t support 2.6/2.7. However, dropping 2.6/2.7\n    support should surely be seen as an incompatible change and the \n    project\'s version number increased so ... it\'s probably covered \n    anyway.\n\n  - All the way through this I\'ve seen mentions of work needed in PyPI \n    and that\'s completely separate from PEP426 etc. We need to get up \n    to speed there and follow what\'s happening on catalog-sig.\n\n  - I\'d never heard of buildout before and still haven\'t looked in \n    detail. Maybe it\'s relevant to OpenStack, maybe not.\n\n\n\n','<1362327784.5909.31.camel@sorcha>',NULL),('<1362526432.5909.397.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 23:33:52',0,'2013-03-05 23:33:52',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n versioning and naming','On Tue, 2013-03-05 at 22:05 +0000, Mark McLoughlin wrote:\n> On Tue, 2013-03-05 at 14:02 +0000, Mark McLoughlin wrote:\n> > Hey,\n> > \n> > The thread on naming of namespace packages[1] and the discussion about\n> > PEP426 on distutils-sig[2] have lead me to these conclusion:\n> > \n> >   - Naming the package oslo.config is a better choice than oslo-config. \n> >     I don\'t think there\'s necessarily a standard for naming these \n> >     things but it seems more likely that period-separated will become\n> >     more common than hyphen-separated (i.e. zope.interface vs\n> >     oslo-config)\n> > \n> >   - The date based 2013.1 version is likely to be disallowed by PEP426\n> >     when it is ratified and we\'ll end up making the date based version\n> >     a \"private version\" but 0.2013.1 would be the version on PyPI. Uggh.\n> > \n> >   - I\'m coming around to the idea of using semantic versioning (i.e. \n> >     x.y.z) and increasing the major number when removing any deprecated \n> >     APIs. That certainly is the trend expressed in PEP426 and on \n> >     distutils-sig. I\'d be far more reluctant to actually remove \n> >     deprecated APIs, though, so this would change our policy from \n> >     \"remove APIs after a year of deprecation\" to \"very rarely making \n> >     any incompatible changes to our APIs\"\n> > \n> >   - With semantic versioning, I figure we\'d increase the micro number \n> >     when we do release from the stable branch and increase the minor \n> >     number with every coordinated OpenStack release.\n> > \n> > In practical terms, I\'m proposing doing:\n> > \n> >  -package = \'oslo-config\'\n> >  -version = \'2013.1\'\n> >  +package = \'oslo.config\'\n> >  +version = \'1.1.0\'\n> > \n> > in oslo-config\'s setup.py\n> > \n> > I know this is painful for packagers. In Fedora, I\'ll have to set an\n> > \"epoch\" which packagers always hate doing. In Debian, it\'ll probably\n> > mean the package name changing to python-oslo.config.\n> > \n> > However, this is why we didn\'t publish directly to PyPI - we wanted the\n> > opportunity to catch issues like this. So, I\'m thinking we should just\n> > go for it ASAP.\n> \n> Thanks for everyone\'s input. I\'ve pushed these changes for review:\n> \n>   https://review.openstack.org/23621\n>   https://review.openstack.org/23622\n> \n> I think it\'s clear we should make the versioning change. The name change\n> I\'m less certain about, but my instinct tells me we should take the\n> opportunity to get it right now.\n\nThese have landed now:\n\n  http://tarballs.openstack.org/oslo-config/oslo.config-1.1.0b1.tar.gz\n\nCheers,\nMark.\n\n\n\n','<1362521152.5909.362.camel@sorcha>',NULL),('<1362600300.17356.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 20:05:00',0,'2013-03-06 20:05:00',NULL,'[openstack-dev] [Nova] Proposal to add Devananda van der Veen\n to nova-core','On Wed, 2013-03-06 at 14:31 -0500, Russell Bryant wrote:\n> Greetings,\n> \n> I would like to propose adding Devananda van der Veen (devananda) to the\n> nova-core team.\n> \n>     https://review.openstack.org/#/dashboard/2889\n> \n> Devananda has been very helpful in a number of areas, including nova\n> reviews.  I was very impressed by the database expertise he demonstrated\n> during the last design summit.  He carried that into the Grizzly cycle\n> by leading the Nova DB team, which accomplished a number of database\n> usage improvements in Grizzly.  He has also been spending a lot of time\n> improving the new baremetal driver.\n> \n> Please respond with comments, +1s, or objections within one week.\n\nDevananda does thorough reviews and is clearly \"Mr. Baremetal\" lately\n\n+1\n\nCheers,\nMark.\n\n\n\n','<51379983.1040805@redhat.com>',NULL),('<1362600315.17356.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 20:05:15',0,'2013-03-06 20:05:15',NULL,'[openstack-dev] [Nova] Proposal to add Daniel Berrange to\n nova-core','On Wed, 2013-03-06 at 14:31 -0500, Russell Bryant wrote:\n> Greetings,\n> \n> I would like to propose adding Daniel Berrange (danpb) to the nova-core\n> team.\n> \n>     https://review.openstack.org/#/dashboard/1779\n> \n> Daniel has brought his libvirt and general virtualization expertise to\n> Nova and has been making a big impact.  He has been doing a lot of\n> helpful reviews.  He also made multiple substantial contributions to\n> Grizzly, including:\n> \n>     https://blueprints.launchpad.net/nova/+spec/virt-disk-api-refactoring\n>     https://blueprints.launchpad.net/nova/+spec/libvirt-custom-hardware\n>     https://blueprints.launchpad.net/nova/+spec/libvirt-spice\n>     https://blueprints.launchpad.net/nova/+spec/libvirt-vif-driver\n> \n> Please respond with comments, +1s, or objections within one week.\n\nNo brainer IMHO, +1\n\nCheers,\nMark.\n\n\n\n','<5137998F.8080809@redhat.com>',NULL),('<1362602315.3189.9.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 14:38:34',-21600,'2013-03-06 20:38:34',NULL,'[openstack-dev] [Nova] Proposal to add Andrew Laski to nova-core','On Wed, 2013-03-06 at 14:31 -0500, Russell Bryant wrote:\n> Andrew has been quite active lately helping out with reviews and\n> contributing to Nova.  He also implemented the instance-actions\n> blueprint for Grizzly.\n\n+1\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51379977.9090806@redhat.com>',NULL),('<1362602723.3189.15.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-06 14:45:22',-21600,'2013-03-06 20:45:22',NULL,'[openstack-dev] [Nova] nova-core cleanup','On Wed, 2013-03-06 at 15:14 -0500, Russell Bryant wrote:\n> On 03/06/2013 02:59 PM, Josh Kearney wrote:\n> > Do these stats include python-novaclient reviews?\n> \n> No, good point.  novaclient stats included below.\n\nAnd I\'ll again appeal to current nova cores to *please* periodically\nreview novaclient patches.  One of the reasons I have such a high count\nis because I pretty much assume that no one else is going to, and I end\nup reviewing every patch.  Also, quite often, after I review a patch, it\njust sits there in the queue for days until jk0 pops up or the patch\nauthor convinces some other core to take a look.\n\n> > It might be better to use 60 days in this case because of the feature\n> > freeze.\n> \n> What does the feature freeze change?\n\nWell, for myself, I tend to avoid reviewing patches right now unless I\nknow they\'re targeted for rc1 due to feature freeze; this will\nundoubtedly reduce the review count.  I\'m +1 for using a 60 day window\nright now, at least until trunk re-opens.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<5137A388.2050102@redhat.com>',NULL),('<1362650695.2383.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 10:04:55',0,'2013-03-07 10:04:55',NULL,'[openstack-dev] [Nova] PTL Candidacy','On Thu, 2013-03-07 at 10:45 +0100, Thierry Carrez wrote:\n> Vishvananda Ishaya wrote:\n> > I\'d like to announce formally that I won\'t be running for nova PTL this cycle. PTL duties for a large project like Nova take an inordinate amount of time and I think it is good to spread the load around.\n> > \n> > Over the last release cycle Russell Bryant has been extremely helpful, taking on a lot of the blueprint and meeting work. Other members have also contributed in important ways, by doing massive amounts of reviews (Sean Dague, Michael Still, Kevin Mitchell) or taking on specific areas of functionality (Devananda Van Der Veen, Daniel Berrange, Chris Behrens).\n> > \n> > I don\'t think it is possible for one person to fly solo; it really requires a team of people working together. I will therefore continue to help the new PTL by taking on whatever duties I can. I plan on continuing to contribute code, bug fixes, and reviews.\n> \n> Yes, I think Nova needs to be run by a small group (1-4) of very active\n> lieutenants (nova-drivers group ?), potentially split along functional\n> lines, with the PTL having the duties to keep a global view, updated\n> roadmaps and do release meeting reports. To compensate for that, the PTL\n> gets the right to make final calls when one needs to be taken (+ a free\n> TC seat).\n\nA model that could work is that drivers become a very small group of\nleaders (e.g. 4 members) that make final calls based on rough consensus\namongst them.\n\nOpenStack basically requires that all projects have a PTL (and not just\nfor the TC seat) but maybe an individual project could prove the concept\nof \"joint, consensus based leadersip\" can work and rotate the figurehead\nPTL title amongst the drivers every 6 months.\n\nWith these PTL elections, you can say it\'s better when each PTL position\nis contested because it shows that the project has multiple viable\nleaders. However, I hate the idea that folks who are effectively jointly\nleading a project are forced to compete for the PTL title and that this\ncompetition would in any way damage their relationship and ability to\njointly lead. I also hate the idea that the loser of that competition\nthen steps back and takes less of a leadership role.\n\nCheers,\nMark.\n\n\n\n','<513861C0.601@openstack.org>',NULL),('<1362683744.4760439.1421186048664.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-13 22:54:08',3600,'2015-01-13 21:54:08',NULL,'[openstack-dev] [oslo] Test failures due to oslo_concurrency?','See also the following changes:\n\noslo.concurrency: Don\'t decode stdout/stderr on Python 2\nhttps://review.openstack.org/#/c/146984/\n(my change)\n\noslo.concurrency: Allow callers to disable encoding for execute()\nhttps://review.openstack.org/#/c/146932/\n(Doug Hellmann)\n\nnova: Do not decode binary data from crypt commands\nhttps://review.openstack.org/#/c/146937/\n(Doug Hellmann)\n\nnova: use -out for openssl encrypted blobs\nhttps://review.openstack.org/#/c/146929/\n(Sean Dague)\n\nVictor\n\n----- Mail original -----\n> De: \"Kevin L. Mitchell\" <kevin.mitchell at rackspace.com>\n> ?: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Envoy?: Mardi 13 Janvier 2015 22:20:35\n> Objet: [openstack-dev] [oslo] Test failures due to oslo_concurrency?\n> \n> Noticed that https://review.openstack.org/#/c/145626/ failed tests.\n> That\'s kind of curious, as all it does is alter HACKING.rst.\n> Investigation of the test failures[1] showed some UTF-8 decoding errors\n> that appeared to be coming from oslo_concurrency/processutils.py.  Any\n> ideas?\n> \n> [1]\n> http://logs.openstack.org/26/145626/2/check/gate-nova-python27/b350bbc/console.html\n> --\n> Kevin L. Mitchell <kevin.mitchell at rackspace.com>\n> Rackspace\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1421184035.3132.9.camel@einstein.kev>',NULL),('<1362747067.2314.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-08 12:51:07',0,'2013-03-08 12:51:07',NULL,'[openstack-dev] [Nova] PTL Candidacy','On Thu, 2013-03-07 at 20:59 -0500, Russell Bryant wrote:\n> Nova is quite busy.  Vish, obviously you know how much work this takes.\n>  I think Michael and I have both been around enough to see how much work\n> it is, which is why both of us called out project structure and\n> delegation as things we would want to work on if elected as the PTL.\n> \n> I give a +1 to formalizing an expanded leadership model that addresses\n> the growth in the project so that we don\'t burn out a single leader, but\n> -0 to getting rid of a single PTL that is ultimately responsible for the\n> project.  I\'ll keep thinking about it, though. \n\n(FWIW, I do buy the argument that things are improving organically and\nthat a more radical change might be overkill ... but figure it\'s worth\ntalking through this a bit more)\n\nNova is indeed quite busy. For me personally, the answer to \"well, what\nwould it take for me to be Nova PTL?\" is basically \"drop everything else\nand just do that\".\n\nI\'m sure both you and Michael feel the same way when submitting your\ncandidacies, but you both also hope the team will take more of the\nburden from the PTL.\n\nThat\'s all great, but I struggle to see it ending (any time, at least)\nin a situation where the PTL doesn\'t have an order of magnitude work and\nresponsibility than anyone else on the team.\n\nThe idea of \"3 or 4 drivers with a rotating figurehead PTL\" is that none\nof the drivers would feel more responsibility than the others and they\'d\nbe forced to share the work much more evenly. Hopefully with a number\nthat small, it would never be a case of \"one of the others will do it\".\n\nThat might result in 3 or 4 people feeling they have to drop everything\nand focus on the Nova leadership ... but if that\'s what it takes ...\n\nThere\'s the slightly ugly human nature side of this too - much as no-one\nwants the PTL position to be a \"prize\" for the most committed leader, it\nis an elevated status and if the 2 or 3 other Nova leaders feel they are\nmassively \"under-rewarded\" compared to the PTL, then I think it\'s\nnatural for them to feel less responsibility for the workload ... except\nwhere they want to be in the running for the \"prize\" in the next\nelection.\n\nCheers,\nMark.\n\n\n\n','<51394603.6030809@redhat.com>',NULL),('<1362761654-sup-9023@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-08 08:57:39',-28800,'2013-03-08 16:57:39',NULL,'[openstack-dev] [heat] Proposal to add Clint Byrum to heat-core','Excerpts from Steven Dake\'s message of 2013-03-08 08:28:14 -0800:\n> On 03/06/2013 02:20 PM, Steven Dake wrote:\n> > I would like to propose adding Clint Byrum (clint-fewbar) to heat-core.\n> >\n> > Please respond with (+1/0/-1).\n> >\n> \n> Clint has my +1 vote.\n> \n> All heat-core members have +1\'ed.  Welcome to heat-core Clint!\n\nThanks everyone, you honor me with your +1\'s.\n\nIt has been a real pleasure to work with all of you thus far. I can\'t\nwait to see all the great stuff we\'re going to produce this cycle.\n\n--\nClint Byrum\nHP Cloud Services\n\n\n','<513A119E.9000907@redhat.com>',NULL),('<1362773735.75752.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-08 12:15:35',-28800,'2013-03-08 20:15:35',NULL,'[openstack-dev] key manager proposal','Malini,\n\nSorry for the long reply, but I have a lot of thoughts on this. I like the \nproposal overall, but I have some concerns and suggestions. \n\n*** Master Key and Access for Compute Hosts *** \n\nMy biggest concerns are with regards to the master key and preventing access to \nthe compute hosts. In our proposal, encrypt-cinder-volumes, the compute host is \nencrypting the cinder volume data after it leaves the VM and before it is sent \nto the cinder host. Clearly we would like for compute hosts to have access to \nthe Key Manager to allow them to encrypt the data. \n\nMy other concern is with the master key idea. The compute hosts will be \nresponsible for encrypting and decrypting the data for cinder volumes. If the \nkeys for doing this are encrypted by a master key then the master key must be \nshared by all compute hosts that will use the cinder volume. That would require \ncopying the master key to multiple platforms and that makes me nervous. This is \nmy biggest concern with master keys encrypting other keys. It forces the master \nkey to be shared with all entities that will use the key. \n\nI propose changing the interface to operate on generic Key objects. Then we can \nhave classes of Key objects for different types of keys. One Key class may be a \nSymmetricKey class for storing AES keys and the like. Another Key class may be \nan EncryptedSymmetricKey class that stores a symmetric key that is encrypted by \na master key. This way the interface can support the use cases for master keys \nand plain old symmetric keys. It would also support split keys. I can send a \nUML diagram or two with my thoughts if you like. Let me know. \n\n*** Authroization Token *** \n\nI like that your API takes in an authorization token. Do you have more details \non what that would be? Our prototype right now takes in the context of the \ncaller (i.e. the user). I would like to extend that to have the interface take \nin a security context that not only provides an authorization token from the \nuser, but it may include other information as well. I am thinking about \ninformation specific to the platform. For instance, I may want to have the \ncompute host provide a signed TPM quote, so the Key Manager can verify that the \ncaller is from a particular platform. I would be interested in brainstorming \nmore ideas on this.  I\'m also not sure what the Keystone group is working on in \nthis area. I also think it would be cool to integrate TNC into this, but I\'m \nnot sure how to do that.\n\n*** Miscellaneous Thoughts *** \n\nI would like to see the Key Manager as its own service. I think many different \nservices have a need for a Key Manager and making it its own service would be \nuseful. \n\nTPM could be used to encrypt all keys on Key Manager platform. Then you could\nlock the keys down unless the platform is in a specific state.\n\nI don\'t think we should limit key scope. I imagine there will be many different\nuse cases for keys, and the key scope will be different for each one. It may\nalso be different per deployment.\n\nThis topic is of interest to the OpenStack Security Group (OSSG). You may want\nto join the meetings on Thursdays.\n\nLink to encrypt-cinder-volumes blueprint:\nhttps://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes\n\n-Nate\n\n> When you get a chance we checkout https://wiki.openstack.org/wiki/KeyManager > \n> I hope I have captured ideas and addressed concerns we have discussed on this mailing list.\n\n\n',NULL,NULL),('<1363021356.86351.YahooMailNeo@web163801.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-11 10:02:36',-25200,'2013-03-11 17:02:36',NULL,'[openstack-dev] key manager proposal','I attached a diagram for KeyManager and the Key class hierarchy that I am \nenvisioning. I think we are pretty similar on this.\n\n> Volume = NateV\n>\n> Compute-node-host-A??? Compute-node-host-B Compute-node-host-C\n>\n> Your VM should be technically able to run on the above A, B, or C and attach\n> volume NateV.\n>\n> If master encryption key lives only on compute-node-host-A, then you can\n> decrypt the volume only on A.\n>\n> Alternately if VM runs on compute-node-host-B, need to retrieve the master\n> from compute-node-host-A or elsewhere.\n>\n> After retrieving master, then retrieve the volume specific key NateV-k.\n\nI think what is missing for me is how compute-node-host-B knows where to find \nthe master key and how does the master key get transferred from A to B.? Could\nyou please explain this to me?\n\nFor instance compute-node-host-B receives request to mount encrypted volume. It\ncan retrieve the key from the Key Manager, but at that point it would not know \nhow to unwrap the encrypted key.? How would it know to retrieve the key from \ncompute-node-host-A? What service must be running on compute-node-host-A to\nallow compute-node-host-B to retrieve the key? \n\nI think we can support the master key concept, but I\'m wondering if that should\ncome in a later phase. I think we could have a KeyManager that accepts generic\nKey objects (i.e. plain old key objects and encrypted key objects) and support\nboth use cases. At first we could have simple keys that are not encrypted with \nmaster key, and then in a later phase implement master key concept. Thoughts?\n\n-Nate\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ops-kmip.png\nType: image/png\nSize: 16499 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130311/341d9a90/attachment.png>\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E52096C67@FMSMSX105.amr.corp.intel.com>',NULL),('<1363078314.7926.296.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-12 08:51:54',0,'2013-03-12 08:51:54',NULL,'[openstack-dev] OSLO Release Dates','On Tue, 2013-03-12 at 09:20 +0200, Gary Kotton wrote:\n> Hi,\n> Is there any chance to get a planned release date for OSLO RC-1.\n\nThat was my plan, but the date crept up on my. Will try and get it done\ntoday.\n\n> This \n> would enable the project using OSLO to pull in the latest changes and \n> ensure that we all have a synced snapshot of the OSLO release.\n\nAll projects are using 1.1.0b1 and there have been no changes since.\n\n(Aside: Oslo is not an acronym)\n\nCheers,\nMark.\n\n\n\n','<513ED73B.4010901@redhat.com>',NULL),('<1363081195.7926.301.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-12 09:39:55',0,'2013-03-12 09:39:55',NULL,'[openstack-dev] OSLO Release Dates','On Tue, 2013-03-12 at 10:12 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Tue, 2013-03-12 at 09:20 +0200, Gary Kotton wrote:\n> >> Hi,\n> >> Is there any chance to get a planned release date for OSLO RC-1.\n> > \n> > That was my plan, but the date crept up on my. Will try and get it done\n> > today.\n> > \n> >> This \n> >> would enable the project using OSLO to pull in the latest changes and \n> >> ensure that we all have a synced snapshot of the OSLO release.\n> > \n> > All projects are using 1.1.0b1 and there have been no changes since.\n> \n> I think Gary\'s question is linked to the incubator, not oslo-version...\n> When are we declaring Oslo grizzly \"done\" so that all projects can have\n> a synced snapshot of the latest incubator state ?\n\nProjects should sync regularly. There\'s no reason to wait for anything\nto be considered \"done\".\n\n> Since we don\'t really \"release\" anything from the incubator, it\'s more a\n> question of when we are moving to only-critical-bugs mode. We could cut\n> a stable/grizzly branch at that point (and let master continue to\n> havana). Then we only update.py from stable/grizzly and make sure that\n> if we change anything in stable/grizzly we sync that to all relevant\n> projects.\n\nWell, oslo-incubator is in feature freeze like other modules.\n\nI don\'t see the need to be ultra proactive in syncing to all projects\nevery time there\'s a change in oslo-incubator. In only-critical-bugs\nmode, we should only be syncing to a given project when we know the sync\nfixes a critical bug. Otherwise the sync is just needless risk.\n\nCheers,\nMark.\n\n\n\n','<513EF180.3060304@openstack.org>',NULL),('<1363086898.7926.302.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-12 11:14:58',0,'2013-03-12 11:14:58',NULL,'[openstack-dev] OSLO Release Dates','On Tue, 2013-03-12 at 11:14 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Tue, 2013-03-12 at 10:12 +0100, Thierry Carrez wrote:\n> >> Since we don\'t really \"release\" anything from the incubator, it\'s more a\n> >> question of when we are moving to only-critical-bugs mode. We could cut\n> >> a stable/grizzly branch at that point (and let master continue to\n> >> havana). Then we only update.py from stable/grizzly and make sure that\n> >> if we change anything in stable/grizzly we sync that to all relevant\n> >> projects.\n> > \n> > Well, oslo-incubator is in feature freeze like other modules.\n> > \n> > I don\'t see the need to be ultra proactive in syncing to all projects\n> > every time there\'s a change in oslo-incubator. In only-critical-bugs\n> > mode, we should only be syncing to a given project when we know the sync\n> > fixes a critical bug. Otherwise the sync is just needless risk.\n> \n> I think we are in agreement here. I\'d like to see oslo-incubator move\n> from \"all bugfixes accepted\" mode to \"only release-critical bugs\n> accepted\" and open the master branch for havana development, in the same\n> way that integrated projects do when they reach RC1.\n> \n> That can be done by creating a milestone-proposed branch like for every\n> other project, or directly a stable/grizzly branch. Given that there is\n> no real candidate to publish, maybe going straight to stable/grizzly\n> when the RC1 buglist is down to 0 makes the most sense...\n\nGoing direct to stable/grizzly is fine by me. AFAIR, that\'s what we did\nlast time.\n\nWill take a run through the buglist today to make sure we\'re not missing\nanything scarey.\n\nThanks,\nMark.\n\n\n\n','<513F0021.2050902@openstack.org>',NULL),('<1363087798.44113248@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-03-12 06:29:58',-18000,'2013-03-12 11:29:58',NULL,'[openstack-community] Going to PyCon?  Advertise your OpenStack job openings in our booth and at our Job Fair table','\nOpenStack will be in booth #248 at PyCon in the Santa Clara Convention Center Thursday-Saturday, then at the Job Fair on Sunday.  We\'ll have a magnetic whiteboard there for job postings from OpenStack companies.  Please visit by our booth during setup on Thursday (1-6pm) or during the show and fill out index cards with your jobs.  Cards and markers will be there for your use.  Stefano Maffulli, Community Manager, and a wonderful group of community volunteers will encourage visitors to take pictures of the jobs for later followup.  We\'ll be seeding the board with jobs from openstack.org/jobs.  Let\'s expand the OpenStack community and fill your available positions this weekend!  Thank you for your support.\n\n -- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130312/b9bf1f79/attachment.html>\n\n',NULL,NULL),('<1363095448.7926.305.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-12 13:37:28',0,'2013-03-12 13:37:28',NULL,'[openstack-dev] OSLO Release Dates','On Tue, 2013-03-12 at 09:27 -0400, Sean Dague wrote:\n> On 03/12/2013 04:51 AM, Mark McLoughlin wrote:\n> > On Tue, 2013-03-12 at 09:20 +0200, Gary Kotton wrote:\n> >> Hi,\n> >> Is there any chance to get a planned release date for OSLO RC-1.\n> >\n> > That was my plan, but the date crept up on my. Will try and get it done\n> > today.\n> >\n> >> This\n> >> would enable the project using OSLO to pull in the latest changes and\n> >> ensure that we all have a synced snapshot of the OSLO release.\n> >\n> > All projects are using 1.1.0b1 and there have been no changes since.\n> >\n> > (Aside: Oslo is not an acronym)\n> \n> The sooner the better here. I noticed that tempest run_tests.sh is \n> broken on a fresh environment because of install_venv\'s inability to \n> correctly install by url. Will be nice to finally have this up in pypi.\n\nWe need to fix whatever the issue is here (maybe this what Johannes\nfound before wrt to including the version number in the URL?)\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-February/005975.html\n\nNew oslo-config APIs in Havana won\'t be available on PyPI until Havana\nis frozen, so we\'ll soon be going back to this \"use a development\nsnapshot tarball\" model on master.\n\nCheers,\nMark.\n\n\n\n','<513F2D2B.3000408@linux.vnet.ibm.com>',NULL),('<1363157264.7926.313.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-13 06:47:44',0,'2013-03-13 06:47:44',NULL,'[openstack-dev] Change in openstack/quantum[master]: Switch to\n final 1.1.0 oslo.config release','On Tue, 2013-03-12 at 22:44 -0700, Dan Wendlandt wrote:\n> Adding in Gary, Salvatore, and Thierry, who may be able to magically\n> solve this while we\'re (hopefully) sleeping.   Also adding Monty +\n> James, as they seem to also magically solve issues like this :) \n\nWe\'re all on openstack-dev :)\n\n> Thierry, at this point, we\'re still planning on pulling the\n> milestone-proposed branch tonight.  Mark will just cherry pick changes\n> tomorrow before we declare an RC-1.\n\nThe issue appears to be with the way tempest is getting installed\ncauses:\n\n 2013-03-13 05:52:53.481 | 2013-03-13 05:52:52   Found existing installation: oslo.config 1.1.0\n 2013-03-13 05:52:53.485 | 2013-03-13 05:52:52     Uninstalling oslo.config:\n\nand then we get the 1.1.0b1 version installed again\n\nCheers,\nMark.\n\n> On Tue, Mar 12, 2013 at 10:23 PM, Mark McClain\n> <mark.mcclain at dreamhost.com> wrote:\n>         I don\'t think this will ever pass because the beta tarball is\n>         being installed after Quantum installs the version from pip.\n>          Ideas how to break this deadlock?\n>         \n>         mark\n>         \n>         On Mar 13, 2013, at 12:44 AM, Jenkins (Code Review)\n>         <review at openstack.org> wrote:\n>         \n>         > Jenkins has posted comments on this change.\n>         >\n>         > Change subject: Switch to final 1.1.0 oslo.config release\n>         > ......................................................................\n>         >\n>         >\n>         > Patch Set 1: Fails\n>         >\n>         > Build failed.  For information on how to proceed, see\n>         https://wiki.openstack.org/wiki/GerritJenkinsGithub#Test_Failures\n>         >\n>         > -\n>         http://logs.openstack.org/24204/1/gate/gate-quantum-docs/4990 : SUCCESS\n>         > -\n>         http://logs.openstack.org/24204/1/gate/gate-quantum-pep8/5713 : SUCCESS\n>         > -\n>         http://logs.openstack.org/24204/1/gate/gate-quantum-python26/5363 : SUCCESS\n>         > -\n>         http://logs.openstack.org/24204/1/gate/gate-quantum-python27/5377 : SUCCESS\n>         > -\n>         http://logs.openstack.org/24204/1/gate/gate-tempest-devstack-vm-quantum/13827 : FAILURE\n>         >\n>         > --\n>         > To view, visit https://review.openstack.org/24204\n>         > To unsubscribe, visit https://review.openstack.org/settings\n>         >\n>         > Gerrit-MessageType: comment\n>         > Gerrit-Change-Id: I655f831718ae5f4e25e941ee206fe195214a9a91\n>         > Gerrit-PatchSet: 1\n>         > Gerrit-Project: openstack/quantum\n>         > Gerrit-Branch: master\n>         > Gerrit-Owner: Mark McLoughlin <markmc at redhat.com>\n>         > Gerrit-Reviewer: Jenkins\n>         > Gerrit-Reviewer: Mark McLoughlin <markmc at redhat.com>\n>         > Gerrit-Reviewer: dan wendlandt <dan at nicira.com>\n>         > Gerrit-Reviewer: mark mcclain <mark.mcclain at dreamhost.com>\n>         \n>         \n> \n> \n> \n> \n> -- \n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> Dan Wendlandt \n> Nicira, Inc: www.nicira.com\n> twitter: danwendlandt\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> \n\n\n\n\n','<CA+0XJm8CR1irHYSWw9iU0ffvyy6pxCw2PxwNSax01UhhGvj4Jw@mail.gmail.com>',NULL),('<1363158396.7926.318.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-13 07:06:36',0,'2013-03-13 07:06:36',NULL,'[openstack-dev] Change in openstack/quantum[master]: Switch to\n final 1.1.0 oslo.config release','On Tue, 2013-03-12 at 23:50 -0700, Monty Taylor wrote:\n> \n> On 03/12/2013 11:47 PM, Mark McLoughlin wrote:\n> > On Tue, 2013-03-12 at 22:44 -0700, Dan Wendlandt wrote:\n> >> Adding in Gary, Salvatore, and Thierry, who may be able to magically\n> >> solve this while we\'re (hopefully) sleeping.   Also adding Monty +\n> >> James, as they seem to also magically solve issues like this :) \n> > \n> > We\'re all on openstack-dev :)\n> > \n> >> Thierry, at this point, we\'re still planning on pulling the\n> >> milestone-proposed branch tonight.  Mark will just cherry pick changes\n> >> tomorrow before we declare an RC-1.\n> > \n> > The issue appears to be with the way tempest is getting installed\n> > causes:\n> > \n> >  2013-03-13 05:52:53.481 | 2013-03-13 05:52:52   Found existing installation: oslo.config 1.1.0\n> >  2013-03-13 05:52:53.485 | 2013-03-13 05:52:52     Uninstalling oslo.config:\n> > \n> > and then we get the 1.1.0b1 version installed again\n> \n> It\'s the de-facto version sharing issue that devstack provides us. It\'s\n> a little late, I\'m not sure I\'ve got a great answer...\n\nI think this should fix it:\n\n  https://review.openstack.org/24291\n\nFor some reason this:\n\n  pip install -r tools/pip-requires\n\nwill uninstall oslo.config in order to install the exact tarball\nspecified but this:\n\n  pip_install -r glance.egg-info/requires.txt -f http://tarballs.openstack.org/oslo-config/oslo.config-1.1.0b1.tar.gz#egg=oslo.config\n\nwhich is what setup_develop() does, works fine.\n\nInteresting that we pass dependency link URLs to pip install using the\n--find-links option.\n\nCheers,\nMark.\n\n\n\n','<51402198.8000004@inaugust.com>',NULL),('<1363529968.12595.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-17 14:19:28',0,'2013-03-17 14:19:28',NULL,'[openstack-dev] oslo-config.git renamed to oslo.config.git [was Re:\n [CI] Gerrit Downtime Saturday, March 16 (UTC)]','On Thu, 2013-03-14 at 11:48 -0700, James E. Blair wrote:\n> Hi,\n> \n> Gerrit will be unavailable for about 5 minutes starting at 04:00\n> Saturday, March 16 UTC (which is 21:00 PDT on Friday March 15):\n> \n>   http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130316T04\n> \n> We will be renaming the oslo-config repository to oslo.config.  Upon\n> completion, you should update your Git remotes with:\n> \n>   git remote set-url origin https://github.com/openstack/oslo.config.git\n\nHere\'s what I did to handle the rename:\n\n  $> mv oslo-config oslo.config\n  $> sed -i \'s/oslo-config\\.git/oslo.config\\.git/\' oslo.config/.git/config\n\nCheers,\nMark.\n\n\n\n','<87wqt924xq.fsf@meyer.lemoncheese.net>',NULL),('<1363538851.1934627.1414560583170.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-29 01:29:43',-14400,'2014-10-29 05:29:43',NULL,'[OpenStack-docs] Can we push stable/juno out a day or two?','Hi Anne,\n\nI\'m available tomorrow before I have to travel for the summit. I\'m happy to help Matt out with the testing. But I also want to ensure the Fedora example patch that I\'m working on for the Image guide is submitted before I travel. And of course I can work on it after the Summit.\n\nThanks,\nDeepti\n\n-- \nDeepti Navale \nContent Author, Red Hat OpenStack \nCustomer Content Services \nRed Hat Asia Pacific \nSydney, Australia \ndnavale at redhat.com \n\n----- Original Message -----\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: \"Matt Kassawara\" <mkassawara at gmail.com>, \"Deepti Navale\" <dnavale at redhat.com>\n> Cc: \"Steve Gordon\" <sgordon at redhat.com>, openstack-docs at lists.openstack.org\n> Sent: Wednesday, October 29, 2014 1:22:38 PM\n> Subject: Re: [OpenStack-docs] Can we push stable/juno out a day or two?\n> \n> Deepti, are you available to work on testing, patching, and reviewing the\n> OpenStack Install Guide for RHEL/Fedora/Centos? We already publish it to\n> /juno but are hoping to cut a stable branch either this week or after the\n> Summit (say, 11/8).\n> \n> Matt, sounds like earlier access to the staged packages will be best for\n> the future. You sound burned out, so it might be better to shift gears and\n> take your time next week. Up to you.\n> \n> Thanks Steve for the prompt responses and explanations.\n> \n> Thanks,\n> Anne\n> \n> On Tue, Oct 28, 2014 at 8:43 PM, Matt Kassawara <mkassawara at gmail.com>\n> wrote:\n> \n> > I checked the RDO repository almost every day since release and didn\'t see\n> > release packages until the e-mail announcement. Maybe they weren\'t publicly\n> > visible? Anyway, given at least four installation permutations with RDO\n> > packages, I would appreciate any help testing the installation guide as\n> > soon as packages become available for a particular release. With any luck,\n> > we can reduce the delay between official release and a stable installation\n> > guide.\n> >\n> > On Tue, Oct 28, 2014 at 8:26 PM, Steve Gordon <sgordon at redhat.com> wrote:\n> >\n> >> ----- Original Message -----\n> >> > From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> >> > To: \"Steve Gordon\" <sgordon at redhat.com>\n> >> >\n> >> > Several of the core service packages skipped RC1 and went from\n> >> milestone 3\n> >> > to RC2. I generally avoid mixing packages with a difference of more than\n> >> > one milestone/RC version... especially milestones given significant\n> >> changes\n> >> > to the services.\n> >>\n> >> I understand that practice when it comes to the milestone builds, but I\n> >> don\'t think it really makes sense when it comes to the RCs. Either way, we\n> >> had packaged builds of the final release available on the 22nd/23rd. This\n> >> probably went under the radar as we held off on the formal announcement,\n> >> but nobody asked me about it so I didn\'t realize that the formal email was\n> >> a blocker for docs.\n> >>\n> >> > P.S. - Does anyone from RH work on the installation guide these days?\n> >>\n> >> Deepti is available to work on upstream guides, I think when she had\n> >> discussed priorities with Anne the main ones that came up were identity\n> >> federation and some other keystone issues that she has been trying to work\n> >> on. If you need assistance feel free to ask her for help.\n> >>\n> >> Thanks,\n> >>\n> >> Steve\n> >>\n> >> > On Tue, Oct 28, 2014 at 7:28 PM, Steve Gordon <sgordon at redhat.com>\n> >> wrote:\n> >> >\n> >> > > ----- Original Message -----\n> >> > > > From: \"Steve Gordon\" <sgordon at redhat.com>\n> >> > > > To: \"Matt Kassawara\" <mkassawara at gmail.com>\n> >> > > >\n> >> > > > ----- Original Message -----\n> >> > > > > From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> >> > > > > To: \"Steve Gordon\" <sgordon at redhat.com>\n> >> > > > >\n> >> > > > > While OpenStack RC code often sufficiently tests services,\n> >> packaging\n> >> > > > > concerns such as dependencies and default configuration options\n> >> tend\n> >> > > to lag\n> >> > > > > by one or more milestone/RC cycles. The RDO repository only\n> >> contained\n> >> > > > > milestone 3 packages until just prior to the official release of\n> >> Juno\n> >> > > when\n> >> > > > > RC2 packages appeared in it.\n> >> > > >\n> >> > > > RC2 tarballs themselves only became available just prior to the\n> >> official\n> >> > > > release (e.g. Oct 9th for Cinder, Oct 10th for Neutron) and were\n> >> put into\n> >> > > > the repo on the 13th. The gap between RC1 tarballs being available\n> >> and\n> >> > > being\n> >> > > > put in the repo was similar.\n> >> > > >\n> >> > > > > Testing packages (even just the core services), writing patches,\n> >> > > reviewing\n> >> > > > > patches, and general time allocation\n> >> > > > > issues can delay a functional installation guide by a week or more\n> >> > > beyond\n> >> > > > > the package release date. Furthermore, the RDO packages require\n> >> > > testing on\n> >> > > > > RHEL/CentOS and Fedora plus the neutron and nova-network\n> >> variations. I\n> >> > > > > would like to provide users with a mostly functional installation\n> >> > > guide on\n> >> > > > > the official release date which would require availability of at\n> >> least\n> >> > > RC\n> >> > > > > packages at least one week prior to the official release date.\n> >> > > > > release packages becoming available yesterday afternoon and the\n> >> plan\n> >> > > to cut\n> >> > > > > juno/stable for openstack-manuals tomorrow gives us about one day\n> >> to\n> >> > > > > install the packages on two distributions each with two variants,\n> >> > > determine\n> >> > > > > the issues, write patches, test them, and run them through the\n> >> review\n> >> > > > > process before all changes involve backports.\n> >> > > >\n> >> > > > As a result of user feedback from previous test days we stage and\n> >> test\n> >> > > the\n> >> > > > RDO packages to ensure basic sanity before putting them into the\n> >> repo,\n> >> > > this\n> >> > > > takes time but ensures that we have at least some level of\n> >> confidence in\n> >> > > the\n> >> > > > packages being deployed and avoids user frustration caused by basic\n> >> > > issues\n> >> > > > that can be easily prevented. If you wish to access the staged\n> >> packages\n> >> > > in\n> >> > > > future while they are still undergoing testing, just ask (they are\n> >> > > public,\n> >> > > > just not in the main repo).\n> >> > >\n> >> > > Going back through the repo [1] we pushed builds based on the final\n> >> > > release into the repo on the 22nd/23rd and held off formally\n> >> announcing\n> >> > > while we fixed a few more bugs over the weekend.\n> >> > >\n> >> > > Thanks,\n> >> > >\n> >> > > Steve\n> >> > >\n> >> > > [1]\n> >> > >\n> >> https://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/?C=M;O=A\n> >> > > > > On Tue, Oct 28, 2014 at 4:23 PM, Steve Gordon <sgordon at redhat.com\n> >> >\n> >> > > wrote:\n> >> > > > >\n> >> > > > > > ----- Original Message -----\n> >> > > > > > > From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> >> > > > > > > To: \"Anne Gentle\" <anne at openstack.org>\n> >> > > > > > >\n> >> > > > > > > If other reasons (outside of the installation guide) exist to\n> >> move\n> >> > > it\n> >> > > > > > > on\n> >> > > > > > > the 29th rather than wait until after the summit, I can\n> >> deal... but\n> >> > > > > > > backporting patches for RHEL/CentOS/Fedora will take more\n> >> time and\n> >> > > > > > effort.\n> >> > > > > > > Not our fault RDO can\'t push release packages out in a\n> >> reasonable\n> >> > > > > > > amount\n> >> > > > > > of\n> >> > > > > > > time.\n> >> > > > > >\n> >> > > > > > Can you elaborate on what\'s reasonable so we can endeavour to\n> >> > > accommodate\n> >> > > > > > in future? Our aim this time around was for +2 weeks on upstream\n> >> > > release\n> >> > > > > > to\n> >> > > > > > allow some level of smoke testing to occur, despite that M-3\n> >> and RC\n> >> > > > > > packages that could have been used were available leading up to\n> >> this.\n> >> > > > > >\n> >> > > > > > We\'ve been communicating this to users @\n> >> > > > > > https://www.redhat.com/archives/rdo-list/\n> >> > > > > >\n> >> > > > > > Thanks,\n> >> > > > > >\n> >> > > > > > Steve\n> >> > > > > >\n> >> > > > > > > On Mon, Oct 27, 2014 at 9:45 PM, Anne Gentle <\n> >> anne at openstack.org>\n> >> > > > > > > wrote:\n> >> > > > > > >\n> >> > > > > > > >\n> >> > > > > > > > On Mon, Oct 27, 2014 at 9:34 PM, Matt Kassawara\n> >> > > > > > > > <mkassawara at gmail.com>\n> >> > > > > > > > wrote:\n> >> > > > > > > >\n> >> > > > > > > >> The RDO Juno release packages for RHEL/CentOS/Fedora only\n> >> became\n> >> > > > > > > >> available today [1] which leaves very little time for\n> >> testing\n> >> > > and\n> >> > > > > > patching\n> >> > > > > > > >> the installation guide prior to cutting juno/stable for\n> >> > > > > > openstack-manuals\n> >> > > > > > > >> on the 29th. Can we push it out a day or two?\n> >> > > > > > > >>\n> >> > > > > > > >\n> >> > > > > > > > I think if we don\'t do the 29th it\'ll be after Nov 7th due\n> >> to\n> >> > > > > > > > Andreas\'s\n> >> > > > > > > > and my travel schedules, is that an okay solution?\n> >> > > > > > > >\n> >> > > > > > > >\n> >> > > > > > > >>\n> >> > > > > > > >> [1]\n> >> > > > > > > >>\n> >> > > > > >\n> >> > >\n> >> https://openstack.redhat.com/forum/discussion/992/rdo-juno-packages-available\n> >> > > > > > > >>\n> >> > > > > > > >> _______________________________________________\n> >> > > > > > > >> OpenStack-docs mailing list\n> >> > > > > > > >> OpenStack-docs at lists.openstack.org\n> >> > > > > > > >>\n> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >> > > > > > > >>\n> >> > > > > > > >>\n> >> > > > > > > >\n> >> > > > > > >\n> >> > > > > > > _______________________________________________\n> >> > > > > > > OpenStack-docs mailing list\n> >> > > > > > > OpenStack-docs at lists.openstack.org\n> >> > > > > > >\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >> > > > > > >\n> >> > > > > >\n> >> > > > > > --\n> >> > > > > > Steve Gordon, RHCE\n> >> > > > > > Sr. Technical Product Manager,\n> >> > > > > > Red Hat Enterprise Linux OpenStack Platform\n> >> > > > > >\n> >> > > > >\n> >> > > >\n> >> > > > _______________________________________________\n> >> > > > OpenStack-docs mailing list\n> >> > > > OpenStack-docs at lists.openstack.org\n> >> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >> > > >\n> >> > >\n> >> > > --\n> >> > > Steve Gordon, RHCE\n> >> > > Sr. Technical Product Manager,\n> >> > > Red Hat Enterprise Linux OpenStack Platform\n> >> > >\n> >> >\n> >>\n> >> --\n> >> Steve Gordon, RHCE\n> >> Sr. Technical Product Manager,\n> >> Red Hat Enterprise Linux OpenStack Platform\n> >>\n> >\n> >\n> > _______________________________________________\n> > OpenStack-docs mailing list\n> > OpenStack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >\n> >\n> \n\n\n','<CAD0KtVEPKsGONR5GvPhEDRuwZNNfUn8onuK_coVUS4GQoBLB0Q@mail.gmail.com>',NULL),('<1363595194.12595.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-18 08:26:34',0,'2013-03-18 08:26:34',NULL,'[openstack-dev] oslo.packaging progress - and comments?','Hi Monty,\n\nOn Sun, 2013-03-10 at 21:58 -0400, Monty Taylor wrote:\n> Hey guys!\n> \n> I\'ve been trying to figure out how to get openstack.common.setup out of\n> openstack.common and in to a consumable library.\n\nNice!\n\n> It\'s a non-trivial problem, because of the bootstrapping in setup.py.\n\nCould you explain what the bootstrapping project is?\n\n> Anyway - thanks to the d2to1 project, I\'ve got it working. (yay!)\n> \n> Here:\n> https://review.openstack.org/#/c/24033/\n> \n> is a work-in-progress patch showing what it\'s shaping up to look like\n> for a project to consume this.\n\nI\'ve also tried it out for oslo.config:\n\nhttps://github.com/markmc/oslo.config/commit/7e54a17\n\n> The repo itself is up on github:\n> \n> https://github.com/emonty/oslo-packaging\n\nI\'ve used filter-branch to clean up the history a bit:\n\nhttps://github.com/markmc/oslo.packaging\n\n> It still needs testing in tree, and it needs to be run through its paces\n> and everything - but I wanted to get some stuff in front of people\'s\n> eye-holes.\n> \n> oslo.packaging above includes everything that\'s currently in\n> openstack/common/setup, plus the speed-boost I just proposed.\n\nWhich speed-boost?\n\nSee below for a list of minor things I noticed looking over all this.\n\n...\n\nI like this new declarative metadata style in setup.cfg. The idea makes\na tonne of sense over supporting arbitrary code in setup.py that\ngenerates metadata.\n\nHowever, I\'d much rather know that this is the way the entire python\nworld is going and eventually the standard setuptools stuff everyone is\nusing will support this.\n\nSo, I go digging ... there\'s d2to1[1] which supports distutils2[2]-like\nsetup.cfg files, but distutils2 got merged as \'packaging\' during cpython\n3.3 development but then got removed[3], distlib[4] has now entered the\nscene and the metadata section in setup.cfg seems to be proposed by\npep390[5].\n\nWhat took me so long to reply was trying to figure out all that, yet I\'m\nstill not sure I fully understand the state of things.\n\nWhat I\'m wary of is us adopting some new fangled thing before the PEP on\nit is even finalized. Heck, we\'re still on python 2.7 and this thingk\nmight not be officially blessed until 3.4.\n\nIf we release oslo.packaging with support for this setup.cfg metadata,\nI\'ll want us to continue supporting the same format into the future. Any\nchange to the metadata supported by oslo.packaging would be a backwards\nincompatible change.\n\nAlso, if we\'re going for this setup.cfg metadata, the only public API\nexposed by oslo.packaging should probably just be setup_hook() rather\nthan all the functions in oslo.packaging.setup.\n\nAll of this leads me to wonder ... why should we make the leap to this\ndeclarative metadata now? Why can\'t we do oslo.packaging without d2to1\nand allow the distlib/pep390 saga settle down before we make the switch?\n\nCheers,\nMark.\n\n* need https://github.com/iguananaut/d2to1/commit/0395d77 for dependency_links and tests_require\n* set version to 1.1.0\n* move tests under tests/ so they don\'t get installed\n* need to include oslo.packaging in packages list\n* can we avoid setuptools_git\n* need to review which symbols are public so we can leave scope for future changes\n* log.set_verbosity() on module import looks dodgy\n* add license tag to setup.cfg\n* doesn\'t seem to write namespace_packages.txt\n\n[1] - https://github.com/iguananaut/d2to1\n[2] - http://pythonhosted.org/Distutils2/\n[3] - http://mail.python.org/pipermail/python-dev/2012-June/120430.html\n[4] - https://readthedocs.org/projects/distlib/\n[5] - http://www.python.org/dev/peps/pep-0390/\n\n\n\n','<513D3A5D.2090905@inaugust.com>',NULL),('<1363644750.78541.YahooMailNeo@web120406.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-03-18 15:12:30',-25200,'2013-03-18 22:12:30',NULL,'[Openstack-operators] Scalable Glance Nodes','Hi,\n\nHow can I have multiple glance nodes in a way that, when I \ncreate an image from the controler, it would be coppied to all of the \nglance nodes?\nNow, when I define multiple glance endpoints in the controler (keystone), the images would only go to the first glance node.\n\nI also want to avoid putting the name of all glance nodes in the nova nodes.\n\nThank you,\nAd\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130318/e4ef5d78/attachment.html>\n\n',NULL,NULL),('<1363704679.12595.113.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-19 14:51:19',0,'2013-03-19 14:51:19',NULL,'[openstack-dev] rtslib dependency for cinder is AGPL - thoughts?','On Mon, 2013-03-18 at 16:30 -0400, Sean Dague wrote:\n> Recently just doing a license analysis of the dependencies for the \n> various projects and one popped up that seemed worth discussing.\n> \n> rtslib is currently listed as a dependency for cinder. The package \n> itself is AGPL, which has some rather strong requirements for a cloud \n> provider using it \n> (https://github.com/agrover/rtslib-fb/blob/master/COPYING).\n> \n> It\'s currently used only in bin/cinder-rtstool, so it\'s largely isolated \n> in it\'s use. However given that the spirit of the OpenStack project was \n> Apache 2 style licensing, it\'s a bit odd to have an AGPL dependency that \n> really means cinder-rtstool is AGPL (even though it says Apache2 in the \n> header).\n> \n...\n> My inclination is that tooling which requires AGPL libraries probably \n> shouldn\'t be in the main OpenStack tree. Maybe externally available as \n> some sort of contrib. However, licensing always opens up new cans of \n> worms. So I\'d like to hear other opinions here.\n\nJust to be clear on something here - our policy is to not allow the use\nof any GPL libraries. And we don\'t know of any cases where we currently\nuse GPL libraries.\n\ni.e. this is an issue with GPL libraries, generally. The fact that it\'s\nspecifically AGPL makes it a more \"interesting\" case, but that\'s more or\nless secondary.\n\nHave I got that right?\n\nCheers,\nMark.\n\n\n\n','<51477948.9090804@linux.vnet.ibm.com>',NULL),('<1363714319.12595.123.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-19 17:31:59',0,'2013-03-19 17:31:59',NULL,'[openstack-dev] rtslib dependency for cinder is AGPL - thoughts?','On Tue, 2013-03-19 at 13:27 -0400, Sean Dague wrote:\n> On 03/19/2013 10:51 AM, Mark McLoughlin wrote:\n> > On Mon, 2013-03-18 at 16:30 -0400, Sean Dague wrote:\n> >> Recently just doing a license analysis of the dependencies for the\n> >> various projects and one popped up that seemed worth discussing.\n> >>\n> >> rtslib is currently listed as a dependency for cinder. The package\n> >> itself is AGPL, which has some rather strong requirements for a cloud\n> >> provider using it\n> >> (https://github.com/agrover/rtslib-fb/blob/master/COPYING).\n> >>\n> >> It\'s currently used only in bin/cinder-rtstool, so it\'s largely isolated\n> >> in it\'s use. However given that the spirit of the OpenStack project was\n> >> Apache 2 style licensing, it\'s a bit odd to have an AGPL dependency that\n> >> really means cinder-rtstool is AGPL (even though it says Apache2 in the\n> >> header).\n> >>\n> > ...\n> >> My inclination is that tooling which requires AGPL libraries probably\n> >> shouldn\'t be in the main OpenStack tree. Maybe externally available as\n> >> some sort of contrib. However, licensing always opens up new cans of\n> >> worms. So I\'d like to hear other opinions here.\n> >\n> > Just to be clear on something here - our policy is to not allow the use\n> > of any GPL libraries. And we don\'t know of any cases where we currently\n> > use GPL libraries.\n> \n> I wasn\'t sure if that was formal policy or not, but if it is, I\'m happy \n> with that. If that\'s the case though, it got missed in at least one \n> instance here by rtslib coming in as a cinder dependency.\n\nTo be clear, I\'m really not sure whether this is our policy either. I\nguess I always assumed it was, but that\'s based on nothing substantive.\n\nCheers,\nMark.\n\n\n\n','<5148A002.5030300@linux.vnet.ibm.com>',NULL),('<1363734266.12595.129.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-19 23:04:26',0,'2013-03-19 23:04:26',NULL,'[openstack-dev] Behavior of command line flags and\n configuration file','On Tue, 2013-03-19 at 18:43 -0400, Davanum Srinivas wrote:\n> Team,\n> \n> Current State: say there\'s a flag in nova.conf (debug=True), then\n> --debug and --nodebug on the command line has no effect by design.\n> Config file entry basically wins every time.\n> \n> There are 2 bugs, one against glance and one against nova-manage where\n> people were surprised at this behavior.\n> https://bugs.launchpad.net/oslo/+bug/1155347\n> https://bugs.launchpad.net/glance/+bug/1156877\n> \n> Does anyone remember how things used to work in Folsom? (I won\'t ask\n> how you would prefer it to work :)\n\nAdded some findings to https://review.openstack.org/24851\n\nSummary is there is a difference between how cfg and gflags works in\nthis case, but we\'ve been using cfg since Essex ... so it really seems\nlike something else has changed here.\n\n(e.g. do I remember \'nova-manage --debug\' previously used to send its\ndebug output to /var/lib/nova-manage.log ?)\n\nCheers,\nMark.\n\n\n\n','<CANw6fcHPebS1S7DxaqbQKpHX9jp+To_4f2cKvM88qoR1cL43iw@mail.gmail.com>',NULL),('<1363764693.12595.143.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-20 07:31:33',0,'2013-03-20 07:31:33',NULL,'[Openstack-stable-maint] Preparing for 2012.2.4','Hey\n\nI\'ve been struggling to stay on top of stable/folsom stuff lately so\nAlan is going to help out with the next release with a view taking\nresponsibility for future releases.\n\n2012.2.4 is due for release on 2013-04-11, so we\'d like a release\ncandidate on 2013-04-04. That gives us two weeks to prepare. This will\nlikely be the last release in the 2012.2.x series.\n\nThere are notes on the release process here:\n\n  https://wiki.openstack.org/wiki/StableBranchRelease\n\nThe first thing I do is make sure all of the currently fixed bugs are\nadded to the folsom series and targeted to the next release. There are\n47 bugs currently fixed, and I\'ve listed them all here:\n\n  https://gist.github.com/markmc/5202793\n\nI also make sure the assignee and priority fields are correct so the\nfinal release page is nice and pretty e.g.\n\n  https://launchpad.net/nova/folsom/2012.2.3\n\nFinally, I go through the folsom-backport-potential and in-stable-folsom\ntags and remove them from bugs which don\'t need them anymore.\n\nIt\'s actually not too bad to do all this by hand, but maybe it\'s a good\nopportunity to improve our scripts:\n\n  https://github.com/markmc/openstack-lp-scripts\n  https://github.com/ttx/openstack-releasing\n\nIn order to add bugs to the folsom, you need to be a member of the\nopenstack-release team so I\'ll ask ttx to do that.\n\nBeyond bugs, we also need to get a handle on outstanding reviews.\nCurrently, there are 37 open reviews.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1363766872.24041.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-20 08:07:52',0,'2013-03-20 08:07:52',NULL,'[Openstack-stable-maint] stable-maint team for stable/grizzly','Hey\n\nThe openstack-stable-maint team will be responsible for the\nstable/grizzly branches of nova, keystone, glance, cinder, quantum,\nhorizon, oslo-incubator and oslo.config.\n\nThat team\'s job is really to evaluate the risk/benefit of a given\nbackported patch and understand the \"safe source of fixes for\nhigh-impact, user-visible issues\" policy documented here:\n\n  http://wiki.openstack.org/StableBranch\n\ni.e. we keep an eye out for changes proposed to stable/grizzly\nand then:\n\n * evaluate risk of a patch\n * consider how severe the issue is for users\n * check that it\'s already fixed on master\n\nPreferably we add a little comment indicating whether a change meets\nthose criteria when adding our +/-2. Also, stable/grizzly reviews need 2\n+2s from stable-maint members unless the person proposing the backport\nis also a stable-maint member.\n\nThe question is ... who should be on the team?\n\nPreviously, we\'ve included the PTLs and a number of others who are\ninterested in helping out and understand the inclusion criteria.\n\n  https://launchpad.net/~openstack-stable-maint/+members#active\n\nThe outgoing PTLs are bcwaldon, danwent, heckj and vishy. If any of you\nguys want to remain on the team, just let me know.\n\nDaviey, zul, eglynn, garyk, ghe.rivero, mapleoin and pixelbeat - if any\nof you want to bow out, just let me know.\n\nThe incoming PTLs are russellb, dolphm, markwash and mark.mcclain. I\'ll\nassume all of you want to be added.\n\nMatthias Runge from the Horizon team has also expressed an interest in\nhelping, so I\'ll add him.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1363772375.24041.54.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-20 09:39:35',0,'2013-03-20 09:39:35',NULL,'[openstack-dev] Policy on using GPL libraries [was Re: rtslib\n dependency for cinder is AGPL - thoughts?]','Hey\n\ncc-ing VanL and rfontana in the hope they can bring some new perspective\nto this. For reference, the full thread is here:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-March/thread.html#6705\n\nOn Tue, 2013-03-19 at 11:04 -0700, Eric Windisch wrote:\n> On Tue, 2013-03-19 at 13:50 -0400, Sean Dague wrote:\n>> On 03/19/2013 01:31 PM, Mark McLoughlin wrote:\n>>> On Tue, 2013-03-19 at 13:27 -0400, Sean Dague wrote:\n>>>> On 03/19/2013 10:51 AM, Mark McLoughlin wrote:\n>>>>> On Mon, 2013-03-18 at 16:30 -0400, Sean Dague wrote:\n>>>>>> Recently just doing a license analysis of the dependencies for the\n>>>>>> various projects and one popped up that seemed worth discussing.\n>>>>>>\n>>>>>> rtslib is currently listed as a dependency for cinder. The package\n>>>>>> itself is AGPL, which has some rather strong requirements for a cloud\n>>>>>> provider using it\n>>>>>> (https://github.com/agrover/rtslib-fb/blob/master/COPYING).\n>>>>>>\n>>>>>> It\'s currently used only in bin/cinder-rtstool, so it\'s largely isolated\n>>>>>> in it\'s use. However given that the spirit of the OpenStack project was\n>>>>>> Apache 2 style licensing, it\'s a bit odd to have an AGPL dependency that\n>>>>>> really means cinder-rtstool is AGPL (even though it says Apache2 in the\n>>>>>> header).\n>>>>>>\n>>>>> ...\n>>>>>> My inclination is that tooling which requires AGPL libraries probably\n>>>>>> shouldn\'t be in the main OpenStack tree. Maybe externally available as\n>>>>>> some sort of contrib. However, licensing always opens up new cans of\n>>>>>> worms. So I\'d like to hear other opinions here.\n>>>>>\n>>>>> Just to be clear on something here - our policy is to not allow the use\n>>>>> of any GPL libraries. And we don\'t know of any cases where we currently\n>>>>> use GPL libraries.\n>>>>\n>>>> I wasn\'t sure if that was formal policy or not, but if it is, I\'m happy\n>>>> with that. If that\'s the case though, it got missed in at least one\n>>>> instance here by rtslib coming in as a cinder dependency.\n>>>\n>>> To be clear, I\'m really not sure whether this is our policy either. I\n>>> guess I always assumed it was, but that\'s based on nothing substantive.\n> >  \n> > This would be a good thing for the TC to formalize, because it sounds \n> > right for the project culture, and would be good to make it something \n> > that\'s formal and we all review for.\n> > \n> Here is the Apache foundation\'s own interpretation on this issue in\n> regard to their license and project policies:\n> http://www.apache.org/licenses/GPL-compatibility.html\n> \n> TL;DR - don\'t link to GPL code.\n\nIMHO your TL;DR oversimplifies and misrepresents the issue.\n\nThe main[1] issue is that the ASF has this policy:\n\n  all Apache software must be distributed under the Apache License\n\nSince (some claim that) linking an ALv2 project with a GPL library means\nthe resulting combination must be distributed according to the terms of\nthe GPL, an ASF project linking to GPL code would result in an ASF\npolicy violation.\n\nThe question this thread raises is whether we have the same or similar\npolicy. Using the Apache License does not *automatically* mean we adopt\nthe ASF\'s licensing policy.\n\nThere is also the question of whether including an optional,\nnot-used-by-default program which imports a GPL licensed Python module\nin an OpenStack project really does mean that the project must be\ndistributed under the terms of the GPL - i.e. (1) would cinder-rtstool\nbe considered a derivative work of rtslib and (2) would you be required\nto distribute just cinder-rtstool or all of Cinder or all OpenStack\nprojects under the terms of the GPL?\n\nOn (1) a quick google turns up e.g. this interesting take from VanL:\n\n  http://jacobian.org/writing/gpl-questions/\n\n   1. foo.py is a Python library released under the GPLv3. bar.py is a\n   library distributed commercially. If bar contains import foo, must\n   bar.py be released under the GPL?\n\n   Maybe. This has not been resolved by the court, and the answer you\n   get depends on who you ask. The FSF and SFLC will say absolutely yes.\n   Mark Lemley and Larry Rosen would probably say no.\n\n   The relevant legal question is whether the interpreted file bar.py is\n   a derivative work of the contents of foo.py. [...]\n\n   The best advice is to act in accordance with the GPL as a social\n   contract, as that will keep you out of the most trouble. [...]\n\n\nI assumed our policy was to avoid using GPL libraries in OpenStack\nbecause we want all of OpenStack to be distributable under the ALv2. In\nthat sense, our stance wouldn\'t be all that different from the stance\ntaken by the ASF. However, it is really important to be very clear why\nwe\'re taking this stance.\n\nHonestly, I\'d love someone to argue for  a different stance because\notherwise it feels like we\'re adopting this policy without proper\nconsideration.\n\nThanks,\nMark.\n\n[1] - there\'s also the ASF\'s claim of an incompatibility between the\nGPLv2 and the patent provisions in ALv2. Let\'s leave that aside since\nwe\'re talking about an AGPLv3 licensed project.\n\n\n\n','<1E09F6E4B54F46A0BC9684DF716D2D3E@cloudscaling.com>',NULL),('<1363795466.24041.80.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-20 16:04:26',0,'2013-03-20 16:04:26',NULL,'[Openstack-stable-maint] stable-maint team for stable/grizzly','On Wed, 2013-03-20 at 11:33 -0400, Eoghan Glynn wrote:\n> \n> > Hey\n> > \n> > The openstack-stable-maint team will be responsible for the\n> > stable/grizzly branches of nova, keystone, glance, cinder, quantum,\n> > horizon, oslo-incubator and oslo.config.\n> > \n> > That team\'s job is really to evaluate the risk/benefit of a given\n> > backported patch and understand the \"safe source of fixes for\n> > high-impact, user-visible issues\" policy documented here:\n> > \n> >   http://wiki.openstack.org/StableBranch\n> > \n> > i.e. we keep an eye out for changes proposed to stable/grizzly\n> > and then:\n> > \n> >  * evaluate risk of a patch\n> >  * consider how severe the issue is for users\n> >  * check that it\'s already fixed on master\n> > \n> > Preferably we add a little comment indicating whether a change meets\n> > those criteria when adding our +/-2. Also, stable/grizzly reviews\n> > need 2\n> > +2s from stable-maint members unless the person proposing the\n> > backport\n> > is also a stable-maint member.\n> > \n> > The question is ... who should be on the team?\n> > \n> > Previously, we\'ve included the PTLs and a number of others who are\n> > interested in helping out and understand the inclusion criteria.\n> > \n> >   https://launchpad.net/~openstack-stable-maint/+members#active\n> > \n> > The outgoing PTLs are bcwaldon, danwent, heckj and vishy. If any of\n> > you\n> > guys want to remain on the team, just let me know.\n> > \n> > Daviey, zul, eglynn, garyk, ghe.rivero, mapleoin and pixelbeat - if\n> > any\n> > of you want to bow out, just let me know.\n> \n> Count me in please as a continuing member.\n\nCool.\n\n> > The incoming PTLs are russellb, dolphm, markwash and mark.mcclain.\n> > I\'ll\n> > assume all of you want to be added.\n> \n> Just wondering if the two newly-minted Integrated projects will be\n> included in the stable-maint process?\n> \n> If so, then IMO we should also invite Steve Dake & Julien Danjou\n> on board as the respective incoming PTLs for Heat & Ceilo.\n\nNo, since they were Integrated in Grizzly. We\'ve typically left it up to\nprojects to manage this for themselves until they are Integrated.\n\nIt would be good to talk both projects through the inclusion policy and\nencourage them to maintain a stable/grizzly branch themselves using a\nsimilar policy.\n\nCheers,\nMark.\n\n\n\n','<674136440.48664792.1363793635192.JavaMail.root@redhat.com>',NULL),('<1363805138-sup-7103@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-20 11:51:34',-25200,'2013-03-20 18:51:34',NULL,'[openstack-dev] pep8 pinning in requirements','Excerpts from Thomas Goirand\'s message of 2013-03-20 09:46:38 -0700:\n> On 03/20/2013 07:53 PM, Sean Dague wrote:\n> > I noticed yesterday with the cinder review that pep8 was listed as >=\n> > 1.3, and not pinned. I think this is a really bad idea.\n> \n> I do think it always should be this way, and not only with pep8, but\n> with as much python tools as possible, including all the test suite.\n> \n> > After a large amount of pep8 churn at the end of Folsom, we agreed to\n> > pin pep8 for Grizzly, and it was good. It prevented huge numbers of\n> > churn patches because a new pep8 minor release came out and now we\n> > needed an extra space somewhere to pass the scanner.\n> \n> Well, from a distribution standpoint, imposing such a restrictive\n> build-dependency is just crazy. In Debian, there\'s either pep8 1.2 (in\n> Wheezy which is frozen) or 1.4.4 (in SID). It\'s like that, and it wont\n> change soon, unless there is a new upstream release. There will never be\n> a 1.3.3. This kind of situation is likely to happen in other\n> distributions than Debian.\n\nWhich is why we have tox to run things like pep8 in a virtualenv that\nisolates the tools from the distribution code. I understand that the\nfact that developers would like to take responsibility for their own\ntools infuriates distributors, but I don\'t think it is warranted.\n\nThis particular issue feels like it is worthy of a special case and that\ndistributors should not worry about pep8/hacking.py/etc.\n\n> \n> > I realize that we\'re trying to uncap as many deps as possible, but I\n> > think doing that for pep8 isn\'t the right call, because of the amount of\n> > code churn it causes.\n> \n> Then pep8 is either a bad software, or it isn\'t updated to Openstack.\n> IMO, it should always be backward compatible, and be able to validate\n> the same old code it did validate few versions ago.\n> \n\nIndeed, a backward compatibility mode would be beneficial for a number\nof reasons. Right now, that backward compatibility mode is pinning.\n\n> > I think at the beginning of every release cycle we should bump pep8 to\n> > the latest release version\n> \n> PLEASE DON\'T !!!\n> \n> Openstack already made my Debian package maintainer life miserable,\n> because there was only version 1.2 in SID. I don\'t want to have to spend\n> my life convincing the maintainer of pep8 to upload a new release.\n> \n\nFor pep8, not other things, why should Debian, Ubuntu, Fedora, or\nMary-Joe-Cloud-Distributor care? Downstream is too late to run pep8.\n\n\n','<5149E7EE.6000306@debian.org>',NULL),('<1363805509-sup-7350@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-20 11:57:22',-25200,'2013-03-20 18:57:22',NULL,'[openstack-dev] pep8 pinning in requirements','Excerpts from Chuck Short\'s message of 2013-03-20 10:38:30 -0700:\n> On 13-03-20 01:27 PM, Sean Dague wrote:\n> > On 03/20/2013 12:46 PM, Thomas Goirand wrote:\n> >> On 03/20/2013 07:53 PM, Sean Dague wrote:\n> >>> I noticed yesterday with the cinder review that pep8 was listed as >=\n> >>> 1.3, and not pinned. I think this is a really bad idea.\n> >>\n> >> I do think it always should be this way, and not only with pep8, but\n> >> with as much python tools as possible, including all the test suite.\n> >>\n> >>> After a large amount of pep8 churn at the end of Folsom, we agreed to\n> >>> pin pep8 for Grizzly, and it was good. It prevented huge numbers of\n> >>> churn patches because a new pep8 minor release came out and now we\n> >>> needed an extra space somewhere to pass the scanner.\n> >>\n> >> Well, from a distribution standpoint, imposing such a restrictive\n> >> build-dependency is just crazy. In Debian, there\'s either pep8 1.2 (in\n> >> Wheezy which is frozen) or 1.4.4 (in SID). It\'s like that, and it wont\n> >> change soon, unless there is a new upstream release. There will never be\n> >> a 1.3.3. This kind of situation is likely to happen in other\n> >> distributions than Debian.\n> >>\n> >>> I realize that we\'re trying to uncap as many deps as possible, but I\n> >>> think doing that for pep8 isn\'t the right call, because of the \n> >>> amount of\n> >>> code churn it causes.\n> >>\n> >> Then pep8 is either a bad software, or it isn\'t updated to Openstack.\n> >> IMO, it should always be backward compatible, and be able to validate\n> >> the same old code it did validate few versions ago.\n> >>\n> >>> I think at the beginning of every release cycle we should bump pep8 to\n> >>> the latest release version\n> >>\n> >> PLEASE DON\'T !!!\n> >>\n> >> Openstack already made my Debian package maintainer life miserable,\n> >> because there was only version 1.2 in SID. I don\'t want to have to spend\n> >> my life convincing the maintainer of pep8 to upload a new release.\n> >>\n> >> Now, imagine if all upstream authors were thinking like Openstack. The\n> >> only way to be able to use pep8 would be to have as many version of pep8\n> >> in Debian as there is upstream project using it.\n> >\n> > So, I\'m confused....\n> >\n> > As a packager you are re-running the development internal style \n> > checkers on released code? and if so, why?\n> >\n> > I can understand rerunning unit tests to make sure that you didn\'t \n> > break function in patching openstack, but I actually don\'t understand \n> > at all why you\'d run style enforcement on code during packaging.\n> >\n> >     -Sean\n> >\n> Hi\n> \n> In Ubuntu at least it is required by our main inclusion  to run \n> available tests of the testsuites that is available to particular a \n> given project during the project build.\n> \n\nhttps://wiki.ubuntu.com/UbuntuMainInclusionRequirements\n\n\"If the package ships a test suite, and there is no obvious reason why\nit cannot work during build (e. g. it needs root privileges or network\naccess), it should be run during package build, and a failing test suite\nshould fail the build.\"\n\nIt is not required. The intent is to ensure quality, not to blindly run\neverything upstream does.\n\n\n','<5149F416.9000607@canonical.com>',NULL),('<1363882286.2329.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-21 16:11:26',0,'2013-03-21 16:11:26',NULL,'[openstack-dev] Policy on using GPL libraries [was Re: rtslib\n dependency for cinder is AGPL - thoughts?]','Hi Richard,\n\nOn Wed, 2013-03-20 at 10:45 -0400, Richard Fontana wrote:\n> On Wed, Mar 20, 2013 at 09:39:35AM +0000, Mark McLoughlin wrote:\n>  \n> > The main[1] issue is that the ASF has this policy:\n> > \n> >   all Apache software must be distributed under the Apache License\n> \n> Which BTW the ASF does not actually follow, except possibly by\n> tortured definition of \"Apache software\". \n> \n> > Since (some claim that) linking an ALv2 project with a GPL library means\n> > the resulting combination must be distributed according to the terms of\n> > the GPL, an ASF project linking to GPL code would result in an ASF\n> > policy violation.\n> > \n> > The question this thread raises is whether we have the same or similar\n> > policy. Using the Apache License does not *automatically* mean we adopt\n> > the ASF\'s licensing policy.\n> \n> I do not believe that is absolute ASF policy. I believe it may be more\n> like a default policy as to which exceptions have been made from time\n> to time.\n\nOk, very interesting - I\'d be very curious to hear examples of\nexceptions :)\n\n> > There is also the question of whether including an optional,\n> > not-used-by-default program which imports a GPL licensed Python module\n> > in an OpenStack project really does mean that the project must be\n> > distributed under the terms of the GPL - i.e. (1) would cinder-rtstool\n> > be considered a derivative work of rtslib and (2) would you be required\n> > to distribute just cinder-rtstool or all of Cinder or all OpenStack\n> > projects under the terms of the GPL?\n> > \n> > On (1) a quick google turns up e.g. this interesting take from VanL:\n> > \n> >   http://jacobian.org/writing/gpl-questions/\n> > \n> >    1. foo.py is a Python library released under the GPLv3. bar.py is a\n> >    library distributed commercially. If bar contains import foo, must\n> >    bar.py be released under the GPL?\n> > \n> >    Maybe. This has not been resolved by the court, and the answer you\n> >    get depends on who you ask. The FSF and SFLC will say absolutely yes.\n> \n> I hate to disagree with VanL on anything, but:\n> \n> I do not agree that the FSF (a former client of mine) would adopt an\n> absolute interpretation there.\n> \n> As for SFLC, I will just note that it is (AFAIK) currently counsel to\n> both FSF and ASF. If anything SFLC as an entity is less likely to\n> adopt an absolute interpretation of a GPL issue than the FSF, one of\n> its clients (particularly if the ASF is another of its clients). I say\n> that in part as a former lawyer for SFLC familiar with its work in\n> general.\n> \n> >    Mark Lemley and Larry Rosen would probably say no.\n> \n> I\'m not sure what Lemley would say, but I agree that Larry Rosen would\n> probably say no. \n> \n> However, since we\'re talking about lawyers and clients I must also\n> point out the interesting fact that the AGPL licensor in the specific\n> case that led to this thread, Rising Tide Systems, is represented by\n> Larry Rosen as to at least some open source software licensing\n> matters.\n\nWhat I\'m taking away from all this is that if an OpenStack project\nincludes code (even optional code) which uses a GPL/AGPL Python library,\nthen it\'s at least possible that someone with some credibility (maybe\neven a copyright holder of that module) might claim that this means that\nOpenStack project needs to be distributed under the terms of the\nGPL/AGPL.\n\n> >    The relevant legal question is whether the interpreted file bar.py is\n> >    a derivative work of the contents of foo.py. [...]\n> > \n> >    The best advice is to act in accordance with the GPL as a social\n> >    contract, as that will keep you out of the most trouble. [...]\n> > \n> > \n> > I assumed our policy was to avoid using GPL libraries in OpenStack\n> > because we want all of OpenStack to be distributable under the ALv2. In\n> > that sense, our stance wouldn\'t be all that different from the stance\n> > taken by the ASF.\n> \n> That is unclear, as noted above. \n> \n> Quite unlike the ASF, the OpenStack Foundation has baked an Apache\n> License 2.0 policy into its bylaws:\n> \n> \"The Foundation shall distribute the software in the OpenStack Project\n> under the Apache License 2.0.\"\n> \n> As to what the \"OpenStack Project\" is for purposes of such a\n> statement, that is also addressed in the bylaws:\n> \n>   The management of the technical matters relating to the OpenStack\n>   Project shall be managed by the Technical Committee. The management\n>   of the technical matters for the OpenStack Project is designed to be\n>   a technical meritocracy. The ?OpenStack Project? shall consist of a\n>   ?Core OpenStack Project,? library projects, gating projects and\n>   supporting projects. . The Core OpenStack Project means the software\n>   modules which are part of an integrated release and for which an\n>   OpenStack trademark may be used. The other modules which are part of\n>   the OpenStack Project, but not the Core OpenStack Project may not be\n>   identified using the OpenStack trademark except when distributed\n>   with the Core OpenStack Project. The role of the Board of Directors\n>   in the management of the OpenStack Project and the Core OpenStack\n>   Project are set forth in Section 4.13. On formation of the\n>   Foundation, the Core OpenStack Project is the Block Storage,\n>   Compute, Dashboard, Identity Service, Image Service, Networking, and\n>   Object Storage modules. The Secretary shall maintain a list of the\n>   modules in the Core OpenStack Project which shall be posted on the\n>   Foundation?s website.\n\nThanks for that, I hadn\'t consider that the bylaws reads on this. Its\nseems pretty clear cut to me - the Foundation\'s bylaws appears to\nprevent any OpenStack project from doing anything that would require the\nproject to be distributed under the GPL or AGPL.\n\ni.e. to consider linking to GPL/AGPL libraries we would need a bylaws\nchange\n\nI\'m willing to believe there\'s some nuance here that makes it not so\nclear cut, but honestly I\'d need some hand-holding through an\nexplanation :-)\n\n> > However, it is really important to be very clear why\n> > we\'re taking this stance.\n> > \n> > Honestly, I\'d love someone to argue for  a different stance because\n> > otherwise it feels like we\'re adopting this policy without proper\n> > consideration.\n> \n> I would just suggest that the OpenStack project should not be adopting\n> policies based on what it thinks ASF policy is. \n\nAbsolutely. Agree. That was more-or-less my point. We need to define our\nown policy clearly and we need to define it for reasons that make sense\nspecifically for OpenStack.\n\nCheers,\nMark.\n\n\n\n','<20130320144526.GB27912@redhat.com>',NULL),('<1363882516.2329.74.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-21 16:15:16',0,'2013-03-21 16:15:16',NULL,'[openstack-dev] Policy on using GPL libraries [was Re: rtslib\n dependency for cinder is AGPL - thoughts?]','On Wed, 2013-03-20 at 09:19 -0400, Richard Fontana wrote:\n> Mark wrote\n> > there\'s also the ASF\'s claim of an incompatibility between the\n> > GPLv2 and the patent provisions in ALv2. Let\'s leave that aside since\n> > we\'re talking about an AGPLv3 licensed project.\n> \n> Just a comment on this very peripheral item, which I feel compelled\n> to make for the benefit of future generations etc.: That is not the\n> view of the ASF -- indeed the ASF raised serious doubts about the\n> rational basis for this interpretation. Rather it was the view of the\n> FSF in ~2004 when it considered the question of compatibility of the\n> new Apache License 2.0 with GPLv2.\n\nYes, apologies. I have a tendency to make tiny typos (in this case \'A\'\nvs \'F\') that completely reverses my intended meaning :-)\n\nThe ASF doc makes it quite clear that it\'s the FSF\'s view on the matter,\nnot the ASF\'s view.\n\nThanks,\nMark.\n\n\n\n','<20130320131943.GB27711@redhat.com>',NULL),('<1363949048.2326.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-22 10:44:08',0,'2013-03-22 10:44:08',NULL,'[openstack-dev] [Keystone] trusts API extension naming,\n company prefix?','On Fri, 2013-03-22 at 06:23 -0400, Russell Bryant wrote:\n> Greetings,\n> \n> I see that the following patch went in last night to make trusts an\n> extension.\n> \n> https://review.openstack.org/#/q/I32b32fc5df8d8483ae8e99067f0655c13c6f520b,n,z\n> \n> Why is the name of the extension prefixed with \"RH-\"?  I take it that it\n> stands for \"Red Hat\".  What\'s the reasoning for the name?  It strikes me\n> as quite odd.\n> \n> It\'s not a Red Hat specific feature.  If it is seen that way then it\n> seems like it should just be removed until a solution is in place that\n> is seen as generally useful.\n\nThis makes no sense to me either and neither the commit message nor the\nreview gives any real insight into the rationale.\n\nCheers,\nMark.\n\n\n\n\n','<514C3119.7010505@redhat.com>',NULL),('<1363954313.2326.37.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-22 12:11:53',0,'2013-03-22 12:11:53',NULL,'[Openstack-stable-maint] Lockutils','On Thu, 2013-03-21 at 12:19 +0200, Gary Kotton wrote:\n> Hi,\n> I think that the following bug fix needs to be backported to Nova - \n> https://bugs.launchpad.net/oslo/+bug/1158179.\n> Any objections?\n\nNice find Gary, it turns out to be quite an adventure.\n\nThere\'s some work we should do here beyond the fairly safe fix you\'ve\nproposed, but your fix is good for backporting.\n\nThe code in Nova stable/folsom isn\'t actually the Oslo code exactly, but\nyour fix should apply equally well there too.\n\nI haven\'t checked what other projects have this code yet.\n\nAlso, if this fix doesn\'t get into Grizzly final for some projects,\nwe\'ll need it backported to stable/grizzly too.\n\nCheers,\nMark.\n\n\n\n','<514ADEAB.6060706@redhat.com>',NULL),('<1363957845.2326.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-22 13:10:45',0,'2013-03-22 13:10:45',NULL,'[openstack-dev] [Keystone] trusts API extension naming,\n company prefix?','On Fri, 2013-03-22 at 13:57 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Fri, 2013-03-22 at 06:23 -0400, Russell Bryant wrote:\n> >> Why is the name of the extension prefixed with \"RH-\"?  I take it that it\n> >> stands for \"Red Hat\".  What\'s the reasoning for the name?  It strikes me\n> >> as quite odd.\n> >>\n> >> It\'s not a Red Hat specific feature.  If it is seen that way then it\n> >> seems like it should just be removed until a solution is in place that\n> >> is seen as generally useful.\n> > \n> > This makes no sense to me either and neither the commit message nor the\n> > review gives any real insight into the rationale.\n> \n> I suspect it\'s historical, linked to the way extensions were named in\n> the past... and not an assignment or a judgment on quality.\n> \n> IMO extensions that are grown in-tree shouldn\'t have to use a company\n> prefix, since we all vouch for them... but I\'m lacking a bit of history\n> and reference doc about extension naming to actually tell how much room\n> we have for maneuver here.\n\nRight ... it\'s an API produced by OpenStack, if it needs a namespace to\nlive in it should be an OpenStack namespace not a Red Hat namespace.\n\nCheers,\nMark.\n\n\n\n','<514C5557.1090005@openstack.org>',NULL),('<1364224358.31513.3.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-25 10:12:38',-18000,'2013-03-25 15:12:38',NULL,'[openstack-dev] [Openstack] Project quotas on multi-region','On Mon, 2013-03-25 at 10:05 +0000, Day, Phil wrote:\n> Currently quotas are maintained within each nova system so there is\n> not a global view/management/enforcement of quotas. I would love to\n> see a discussion of centralizing things from nova like key pairs, AZs,\n> and quotas in keystone.\n\nI must have missed this thread the first time it came around; I\'ll point\nout Boson[1].  Unfortunately, I\'ve not had any time to work on Boson,\nand probably will not be able to work on it myself at any point in the\nnear future; if anyone is interested in helping out on this project,\nplease check out the git repository[2] and propose code?\n\n[1] https://wiki.openstack.org/wiki/Boson\n[2] https://github.com/klmitch/boson\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F0027928E1@G2W2525.americas.hpqcorp.net>',NULL),('<1364248167.4701.64.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-25 21:49:27',0,'2013-03-25 21:49:27',NULL,'[openstack-dev] Policy on using GPL libraries [was Re: rtslib\n dependency for cinder is AGPL - thoughts?]','Hi Richard,\n\nOn Thu, 2013-03-21 at 21:39 -0400, Richard Fontana wrote:\n> On Thu, Mar 21, 2013 at 04:11:26PM +0000, Mark McLoughlin wrote:\n> \n> > What I\'m taking away from all this is that if an OpenStack project\n> > includes code (even optional code) which uses a GPL/AGPL Python library,\n> > then it\'s at least possible that someone with some credibility (maybe\n> > even a copyright holder of that module) might claim that this means that\n> > OpenStack project needs to be distributed under the terms of the\n> > GPL/AGPL.\n> \n> Is it *likely* though?  In five years of experience dealing with\n> Python packages in Fedora and RHEL and other code contributed to by\n> Red Hat developers I have never encountered a single GPL (or AGPL)\n> licensor who made such a claim, nor have I encountered a single\n> downstream customer or partner that raised this as a concern. That has\n> to mean something.\n\nIt does indeed. Good info, thanks.\n\n> > Its\n> > seems pretty clear cut to me - the Foundation\'s bylaws appears to\n> > prevent any OpenStack project from doing anything that would require the\n> > project to be distributed under the GPL or AGPL.\n> \n> That is true; for an easy example, if an OpenStack project developer\n> somehow did not sign the CLA, put a GPL notice (and no other license\n> notice) on a source file, and committed that source file to an\n> OpenStack project, that result would unquestionably conflict with the\n> policy stated in the bylaws (clearly at least *some* code in the\n> project would be distributed under the GPL).\n> \n> However, \n> \n> > i.e. to consider linking to GPL/AGPL libraries we would need a bylaws\n> > change\n> \n> To me this doesn\'t necessarily follow. It embodies a particular legal\n> conclusion.\n\nThis is the point that I wish you could just categorically say \"it\'s the\nwrong conclusion\" :-)\n\n> Maybe it\'s nonetheless the best approach for OpenStack to\n> adopt (e.g. for ease of administration).\n> \n> I would think something less severe could be appropriate. I can\n> imagine many situations that ought not present even a hypothetical\n> problem, drawn from real experiences I\'ve had dealing with other\n> projects. Easy case: Suppose the GPL library in question is developed\n> solely by one copyright holder who does not wish to use a license\n> other than GPL but who states very explicitly that it sees no\n> licensing implications for the OpenStack code using said library, no\n> conflict with the bylaws policy. And suppose the GPL library falls\n> outside the scope of the definition of \"the OpenStack Project\".\n> \n> IOW you could have a case-by-case approach, or a default rule with\n> some opportunity to argue that an exception should be made in a\n> particular circumstance (without requiring bylaws amendment).\n\nThat makes a tonne of sense to me.\n\n> Maybe the ASF *is* a good model to follow here, in that, AIUI, it does\n> not have absolute rules around things of this sort (requiring bylaws\n> amendment to override). It appears to me (as an outside observer) to\n> have an evolving legal policy -- admittedly one that remains strongly\n> biased against having GPL code in proximity -- based on real cases\n> faced by ASF project developers in real life.\n\nThe thing about OpenStack is that I honestly don\'t see any developers on\nthe project being interested in taking the difficult decisions about\nexceptions to the default rule of \"no GPL libraries\".\n\n(I\'d love someone to say I\'m wrong about that)\n\nHowever, I could imagine us developers delegating that responsibility to\na committee of experts in this area.\n\nPersonally, I had hoped (and, I guess, still hope) that the Foundation\'s\nLegal Affairs committee could take on this responsibility without being\noverly conservative. But we do need the policy documented and a process\nwhereby developers can escalate a particular licensing issue to the\ncommittee and get a decision turned around quickly.\n\nThanks,\nMark.\n\n\n\n','<20130322013958.GB11512@redhat.com>',NULL),('<1364248471.4701.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-25 21:54:31',0,'2013-03-25 21:54:31',NULL,'[openstack-dev] Policy on using GPL libraries [was Re: rtslib\n dependency for cinder is AGPL - thoughts?]','On Fri, 2013-03-22 at 17:44 -0400, Richard Fontana wrote:\n> Just *one* more comment on this, as I wish to say something more\n> explicitly than I did before (partly because I\'m now more confident\n> about something I assert here).\n> \n> > > > There is also the question of whether including an optional,\n> > > > not-used-by-default program which imports a GPL licensed Python module\n> > > > in an OpenStack project really does mean that the project must be\n> > > > distributed under the terms of the GPL - i.e. (1) would cinder-rtstool\n> > > > be considered a derivative work of rtslib and (2) would you be required\n> > > > to distribute just cinder-rtstool or all of Cinder or all OpenStack\n> > > > projects under the terms of the GPL?\n> > > > \n> > > > On (1) a quick google turns up e.g. this interesting take from VanL:\n> > > > \n> > > >   http://jacobian.org/writing/gpl-questions/\n> > > > \n> > > >    1. foo.py is a Python library released under the GPLv3. bar.py is a\n> > > >    library distributed commercially. If bar contains import foo, must\n> > > >    bar.py be released under the GPL?\n> > > > \n> > > >    Maybe. This has not been resolved by the court, and the answer you\n> > > >    get depends on who you ask.\n> \n> I am reasonably confident that all mainstream Linux distributions have\n> been operating for years under the consistent assumption that the\n> answer to this general question is \"no\".\n\nOh, you do tease :)\n\n> My wish is that any policy adopted by OpenStack on this issue be\n> developed and worded in such a way that it will not have problematic\n> or disruptive consequences for such Linux distributions. \n> \n> Red Hat (my employer) is, of course, only one of a number of companies\n> substantially involved in developing and distributing such Linux\n> distributions that are also substantially involved in OpenStack.\n\nI wouldn\'t interpret any of the discussion in this thread as anyone in\nOpenStack having a particularly strong view on this issue[1]. I think\nwe\'re crying out for someone to make a firm, reasoned argument for what\nour policy should be.\n\nThanks,\nMark.\n\n[1] - when I say \"this issue\", I mean whether OpenStack projects can\never use GPLed libraries ... not the specific issue of rtslib\n\n\n\n','<20130322214419.GA16798@redhat.com>',NULL),('<1364280734.56371.YahooMailClassic@web122501.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-25 23:52:14',-25200,'2013-03-26 06:52:14',NULL,'[openstack-dev] Need guidance','\n\n\nDear all\n?\nI need to write open Stack Metadata service in order to retrive Virtual machine information and maybe be able to create or edit an instance information.\n?\nAny Idea on how i can accomplish this??\n?\n?\nThank you !!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130325/0485f653/attachment.html>\n\n','<CA+_JKzq-=6eo600quG+7uAcwGnANWAEquEhDEYg_D8A8DSNP4g@mail.gmail.com>',NULL),('<1364315875.4849.3.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-03-26 16:37:55',0,'2013-03-26 16:37:55',NULL,'[OpenStack Foundation] Opening up the board mailing list','On Sat, 2013-02-02 at 10:33 +0000, Mark McLoughlin wrote:\n> On Fri, 2013-02-01 at 01:00 +0100, Dave Neary wrote:\n> > > I\'ve come across cases where this would be useful several times - has\n> > > anyone seen a mailman configuration that resembles this?\n> > \n> > It is possible in Mailman to restrict posting to a list to a subset of \n> > the members - you set the \"Moderation\" flag and set behaviour for all \n> > moderated users to \"Discard\" or \"Reject\" (reject lets the poster know \n> > the mail was rejected, which might be better) in \"Privacy \n> > options->Sender filters\" - then you unset the mod bit for all board \n> > members in \"Membership management\".\n> > \n> >   That would allow you to have non-board-members subscribe to the board \n> > list, get all the email, but not be able to post. If members really want \n> > to raise issues related to the board member post, then it can be done on \n> > foundation, but you\'d need to manually change the header (which might be \n> > an effective social control to bike shedding board conversations, rather \n> > than trying to figure out how to have reply-to set to a different list \n> > for a subset of the membership). \n> \n> I have no idea whether it is possible, but if it is then it would work\n> pretty well except the \"non-directors need to change the Reply: header\n> when replying\" part. That\'s not terrible, and we can actively encourage\n> people to do it.\n\nI\'ve filed a bug on this:\n\n  https://bugs.launchpad.net/openstack-ci/+bug/1160466\n\nThe main issue is dealing with the existing archives. I\'d like to create\na new, hidden mailing list (which only board members can access) to hold\nthose archives for now. Perhaps later we can remove confidential\ninformation from the archives and re-instate the leftovers under\nfoundation-board.\n\nCheers,\nMark.\n\n\n\n','<1359801203.3672.20.camel@sorcha>',NULL),('<1364334922.23961.YahooMailNeo@web163802.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-26 14:55:22',-25200,'2013-03-26 21:55:22',NULL,'[openstack-dev] encrypted volume snapshot question','I do not think decryption and re-encryption will be necessary. I will do my\nbest to describe why via email.\n\nThe image file is used to setup a loop device, which looks like a normal block\ndevice. The loop device size is limited to the size of the file backing the\nloop device. It maps its idea of sectors to locations in the file backing the\ndevice. Hence sector 0 will be bytes (0, 511) in the file backing the device.\nWhere those bytes are on the physical disk are unknown.\n\nNormal block device functions are used to read and write data from a loop \ndevice.? Hence in Linux this will be a request call. This will tell the block\ndevice where to write the data. For example a call could be made to write data \nto the first sector. The first sector is relative to the loop device and not\nthe physical device.? Therefore data written to the first sector of the loop \ndevice will be to the first 512 bytes of the file backing the loop device.\n\nNow when dm-crypt is used I believe it is setup as another block device that \nsits above the block device to be encrypted. It will simply encrypt the data \nbefore it is sends the request call down to the lower level driver. Consider\nthe example write above again. Now the dm-crypt block device will receive a\nrequest to write to the first sector. It will encrypt the data using the sector\nnumber as the IV, and then call the lower block device using the same \nparameters (i.e. send this data to the first sector). The bytes will then be\nwritten to the first sector of the loop device, which is the first 512 bytes of\nthe file backing the device, and who knows where on the physical device.\n\nSince the physical sector is not used in the encryption then I do not see why\nthe disk would need to be decrypted and then re-encrypted. You could test this \nby creating a file backed loop device, putting dm-crypt on top, writing data to\nit, unmounting it all, copying the file, putting dm-crypt on top, and reading\nthe data from it.\n\nI must point out that I am no Linux kernel guru. I only have a very limited\nexperience. Let me know if this makes sense or not. \n\n-Nate\n\n> Greetings Nate, Caitlin!\n> \n> With volume snapshots, if a second physical copy is to be made, and an\n> algorithm such as\n> AES-XTS is used, how can one escape \"decryption followed by re-encryption\" give \n> than AES-XTS\n> uses the sector address to generate the tweaks for encrypting each sector.\n> \n> Regards\n> Malini\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130326/39bbd190/attachment.html>\n\n',NULL,NULL),('<1364343515.90247352@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-26 20:18:35',-14400,'2013-03-27 00:18:35',NULL,'[openstack-dev] [Glance] Proposal to add Flavio Percoco Premoli\n	to Glance Core','\n+1\nI agree with Mark.\n \n-----Original Message-----\nFrom: \"Mark Washenberger\" <mark.washenberger at markwash.net>\nSent: Tuesday, March 26, 2013 3:03pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Glance] Proposal to add Flavio Percoco Premoli to Glance Core\n\n\n\nHi folks,\n\nI\'d like to propose adding Flavio Percoco Premoli (flaper87) to the\nglance-core team.\n\nhttps://review.openstack.org/#/dashboard/6159\n\nFlavio has been contributing heavily to glance reviews and bugfixes,\nand working on several important new features.\n\nPlease respond with comments, +1s, or objections within one week.\n\nThanks!\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130326/9c6f5652/attachment.html>\n\n','<CAJyP2C-uwcRFFeh4S=Mz3K5vVLvWxG3Zk2hgHQ2w4xT4f65LLA@mail.gmail.com>',NULL),('<1364399265.26726.YahooMailNeo@web163802.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-27 08:47:45',-25200,'2013-03-27 15:47:45',NULL,'[openstack-dev] encrypted volume snapshot question','I think a light weight clone operation like option (2) is possible. I could be\nwrong, but I feel confident that it should be ok.\n\nHowever, I feel like option (2) does introduce some security risks. This is why\nI like option (3).? If we do a clone with the same key then the original and\nclone will use the same key going forward.? The content of the disks will \nchange over time, but the key used to provide the encryption will be the same.\n\nMy concern is that if we use option (2) then there will be many clones using\nthe same key. Consider a user that creates a new encrypted volume. The user \nthen clones the volume and makes it available for other members to use. Each \nmember that uses a cloned volume will have an encrypted drive, but they will \nall be using the same key. \n\nIf an attacker can find the key then they can read the data for all of the\nvolumes. It also makes administration much slower and more difficult in the\ninstance of a key compromise because now all of the drives must be rekeyed\ninstead of just one. \n\n> My concern is with option (2) above, given Nate?s description of a logical\n> block device, so the sector numbers would be 0, 1, 2 in the copy and original.\n> Say one uses an encryption scheme that builds in a tweak using the sector\n> address, and for argument?s sake we have a single physical device and on that \n> we save the original and a snapshot of the same. Would the physical disk have a\n> string of bits that looks identical (because the sector numbers and hence tweak\n> are the same, and the encryption key is the same). Meta data could look \n> different by making a copy of the key and saving it against a new key-id.\n> \n> The above is ideal for de-duplication efforts.\n> But would it introduce a security vulnerability?\n\n-Nate\n\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E5209F54B@FMSMSX105.amr.corp.intel.com>',NULL),('<1364413541.62183.YahooMailNeo@web163806.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-27 12:45:41',-25200,'2013-03-27 19:45:41',NULL,'[openstack-dev] encrypted volume snapshot question','I agree.? I like the user specifying the option as well.\n\n-Nate\n\n\n\n\n----- Original Message -----\nFrom: \"Bhandaru, Malini K\" <malini.k.bhandaru at intel.com>\nTo: Caitlin Bestler <Caitlin.Bestler at nexenta.com>; Nate Reller <rellerreller at yahoo.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org>\nCc: \nSent: Wednesday, March 27, 2013 2:11 PM\nSubject: RE: [openstack-dev] encrypted volume snapshot question\n\nAdding an argument to clone/snapshot that specifies re-key (true/false)? meets security (when true, no key sharing, no bit pattern on physical device that is common) and de-duplication (when false, bit pattern common, key same, quick) needs.\nRegards and thank you!\nMalini\n\n\n-----Original Message-----\nFrom: Caitlin Bestler [mailto:Caitlin.Bestler at nexenta.com] \nSent: Wednesday, March 27, 2013 9:19 AM\nTo: Nate Reller; Bhandaru, Malini K; OpenStack Development Mailing List\nSubject: RE: [openstack-dev] encrypted volume snapshot question\n\nIf I understand your concern with option 2, it is that cloning will be used as a form of mass distribution, and that therefore hundreds of volumes will all require access to the same key.\n\nThat can be easily addressed by simply forcing re-encryption on at least some cloning operations, especially when cloning on a peer-to-peer basis between users.\n\nA far more common pattern would be for an IT department or a Service Provider to create volumes/objects would be cloned by all users in the company (a clone of the Windows C: drive, or of a specific application). For those deployments, Efficiency of the cloning operation, and the ability to share a master reference image on a virtualization host as a form of Deduplication would far outweigh the security concerns.\n\nBut if we include an option to clone with new encryption keys the users will be more than capable of determining when this step is justified.\n\n\n-----Original Message-----\nFrom: Nate Reller [mailto:rellerreller at yahoo.com]\nSent: Wednesday, March 27, 2013 8:48 AM\nTo: Bhandaru, Malini K; OpenStack Development Mailing List; Caitlin Bestler\nSubject: Re: [openstack-dev] encrypted volume snapshot question\n\nI think a light weight clone operation like option (2) is possible. I could be wrong, but I feel confident that it should be ok.\n\nHowever, I feel like option (2) does introduce some security risks. This is why I like option (3).? If we do a clone with the same key then the original and clone will use the same key going forward.? The content of the disks will change over time, but the key used to provide the encryption will be the same.\n\nMy concern is that if we use option (2) then there will be many clones using the same key. Consider a user that creates a new encrypted volume. The user then clones the volume and makes it available for other members to use. Each member that uses a cloned volume will have an encrypted drive, but they will all be using the same key. \n\nIf an attacker can find the key then they can read the data for all of the volumes. It also makes administration much slower and more difficult in the instance of a key compromise because now all of the drives must be rekeyed instead of just one. \n\n> My concern is with option (2) above, given Nate?s description of a \n> logical block device, so the sector numbers would be 0, 1, 2 in the copy and original.\n> Say one uses an encryption scheme that builds in a tweak using the \n> sector address, and for argument?s sake we have a single physical \n> device and on that we save the original and a snapshot of the same.\n> Would the physical disk have a string of bits that looks identical \n> (because the sector numbers and hence tweak are the same, and the \n> encryption key is the same). Meta data could look different by making a copy of the key and saving it against a new key-id.\n> \n> The above is ideal for de-duplication efforts.\n> But would it introduce a security vulnerability?\n\n-Nate\n\n\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E520A095D@FMSMSX105.amr.corp.intel.com>',NULL),('<1364472792.9329.102.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-28 12:13:12',0,'2013-03-28 12:13:12',NULL,'[openstack-dev] [horizon] [*client] WAS\n [Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #178','Hi Alan,\n\nOn Thu, 2013-03-28 at 12:56 +0100, Alan Pevec wrote:\n> Hi all,\n> \n> horizon stable/folsom started failing after keystoneclient 0.2.3 last good was\n>  https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/168/\n> with keystoneclient 0.2.2.\n> \n> All OpenStack clients are supposed to be backward compatible, so I\'m\n> not sure if the solution here is to lock all client version on\n> stable/* or is Horizon using keystoneclient internals which aren\'t\n> part of stable API?\n\nThanks for finding this. The client libraries definitely aren\'t supposed\nto be breaking their APIs.\n\nMaybe we can get the backwards incompatible API change reverted and a\nnew release made?\n\nThanks,\nMark.\n\n> 2013/3/28 OpenStack Jenkins <jenkins at openstack.org>:\n> > See https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/178/\n> \n> ...snip...\n> \n> 2013-03-28 06:04:01.567 | FAIL: test_get_default_role\n> (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n> 2013-03-28 06:04:01.567 |\n> ----------------------------------------------------------------------\n> 2013-03-28 06:04:01.567 | Traceback (most recent call last):\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/tests/api_tests/keystone_tests.py\",\n> line 76, in test_get_default_role\n> 2013-03-28 06:04:01.568 |     keystoneclient = self.stub_keystoneclient()\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/test.py\",\n> line 329, in stub_keystoneclient\n> 2013-03-28 06:04:01.568 |     self.keystoneclient =\n> self.mox.CreateMock(keystone_client.Client)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 258, in CreateMock\n> 2013-03-28 06:04:01.568 |     new_mock = MockObject(class_to_mock, attrs=attrs)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 556, in __init__\n> 2013-03-28 06:04:01.568 |     attr = getattr(class_to_mock, method)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 608, in __getattr__\n> 2013-03-28 06:04:01.568 |     raise UnknownMethodCallError(name)\n> 2013-03-28 06:04:01.568 | UnknownMethodCallError: Method called is not\n> a member of the object: Method called is not a member of the object:\n> auth_token\n> 2013-03-28 06:04:01.568 | >>  raise UnknownMethodCallError(\'auth_token\')\n> \n> ...snip...\n> \n> 2013-03-28 06:04:03.188 | python-keystoneclient==0.2.3\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAGi==UU5GHqnGCCejP2RXya6rLxtC4Ls5PN3di91Oh4D_gC34A@mail.gmail.com>',NULL),('<1364472792.9329.102.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-28 12:13:12',0,'2013-03-28 12:13:12',NULL,'[Openstack-stable-maint] [openstack-dev] [horizon] [*client]\n WAS Build failed in Jenkins: periodic-horizon-python27-stable-folsom #178','Hi Alan,\n\nOn Thu, 2013-03-28 at 12:56 +0100, Alan Pevec wrote:\n> Hi all,\n> \n> horizon stable/folsom started failing after keystoneclient 0.2.3 last good was\n>  https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/168/\n> with keystoneclient 0.2.2.\n> \n> All OpenStack clients are supposed to be backward compatible, so I\'m\n> not sure if the solution here is to lock all client version on\n> stable/* or is Horizon using keystoneclient internals which aren\'t\n> part of stable API?\n\nThanks for finding this. The client libraries definitely aren\'t supposed\nto be breaking their APIs.\n\nMaybe we can get the backwards incompatible API change reverted and a\nnew release made?\n\nThanks,\nMark.\n\n> 2013/3/28 OpenStack Jenkins <jenkins at openstack.org>:\n> > See https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/178/\n> \n> ...snip...\n> \n> 2013-03-28 06:04:01.567 | FAIL: test_get_default_role\n> (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n> 2013-03-28 06:04:01.567 |\n> ----------------------------------------------------------------------\n> 2013-03-28 06:04:01.567 | Traceback (most recent call last):\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/tests/api_tests/keystone_tests.py\",\n> line 76, in test_get_default_role\n> 2013-03-28 06:04:01.568 |     keystoneclient = self.stub_keystoneclient()\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/test.py\",\n> line 329, in stub_keystoneclient\n> 2013-03-28 06:04:01.568 |     self.keystoneclient =\n> self.mox.CreateMock(keystone_client.Client)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 258, in CreateMock\n> 2013-03-28 06:04:01.568 |     new_mock = MockObject(class_to_mock, attrs=attrs)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 556, in __init__\n> 2013-03-28 06:04:01.568 |     attr = getattr(class_to_mock, method)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 608, in __getattr__\n> 2013-03-28 06:04:01.568 |     raise UnknownMethodCallError(name)\n> 2013-03-28 06:04:01.568 | UnknownMethodCallError: Method called is not\n> a member of the object: Method called is not a member of the object:\n> auth_token\n> 2013-03-28 06:04:01.568 | >>  raise UnknownMethodCallError(\'auth_token\')\n> \n> ...snip...\n> \n> 2013-03-28 06:04:03.188 | python-keystoneclient==0.2.3\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAGi==UU5GHqnGCCejP2RXya6rLxtC4Ls5PN3di91Oh4D_gC34A@mail.gmail.com>',NULL),('<1364563767.83026.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-29 06:29:27',-25200,'2013-03-29 13:29:27',NULL,'[openstack-dev] (no subject)','I have looked for one for a while but have had no luck.? I do not think there is one.\n\n> Malini, I saw your design summit about KMIP.\n> Do you know a good opensource implementation of KMIP server ?\n> The main issue will be for the validation process...\n\n-Nate\n\n\n',NULL,NULL),('<1364574194142.a98b043f@Nodemailer>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-03-29 09:23:15',-25200,'2013-03-29 16:23:15',NULL,'[Openstack-docs] newly integrated projects need your guidance!','Oops, I replied initially but forgot to reply all so it only went to Doug. My response was very similar in spirit.?\n\n\nLorin\n?\nSent from Mailbox for iPhone\n\nOn Fri, Mar 29, 2013 at 12:18 PM, Tom Fifield <fifieldt at unimelb.edu.au>\nwrote:\n\n> Hi,\n> I didn\'t see a reply from anyone else so here goes:\n> Let\'s have a joint session. Please propose it - it\'s a great idea!\n> You may also be interested in another session the docs team will propose\n> - on restructuring the docs.\n> Looking forward to working together :)\n> Regards,\n> Tom\n> On 08/03/13 00:48, Doug Hellmann wrote:\n>> Hi, Folks,\n>> \n>> I hope this is the right venue for asking this question. If not, please\n>> redirect me.\n>> \n>> The Ceilometer and Heat projects have recently become integrated\n>> projects under the OpenStack umbrella. Both teams have a combined goal\n>> of starting to work more closely with the documentation team, now that\n>> we\'re official. To that end, I would like to propose a joint session for\n>> the ODS where we can receive some direction from you all about how to\n>> make that go as smoothly as possible.\n>> \n>> So, is this a good idea? Should I propose that session, or should it be\n>> someone on the doc team?\n>> \n>> Thanks,\n>> Doug\n>> \n>> \n>> \n>> _______________________________________________\n>> Openstack-docs mailing list\n>> Openstack-docs at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130329/d64f349d/attachment.html>\n\n','<5155BE62.4020909@unimelb.edu.au>',NULL),('<1364581184.77984.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-29 11:19:44',-25200,'2013-03-29 18:19:44',NULL,'[openstack-dev] Supporting KMIP in Key Manager','I have looked for one for a while but have had no luck.? I do not think there is one.\n\n> Malini, I saw your design summit about KMIP.\n> Do you know a good opensource implementation of KMIP server ?\n> The main issue will be for the validation process...\n\n-Nate\n\n\n',NULL,NULL),('<1364590921813.3d9487e4@Nodemailer>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-03-29 14:02:02',-25200,'2013-03-29 21:02:02',NULL,'[Openstack-docs] Newbie Questions','Joe:\n\n\nI wrote a docbook schema validation script that might give you more helpful error messages than Maven. It\'s included in the repo. To run it, do from the openstack-manuals root:\n\n\ntools/validate.py\n\n\nIt\'s been failing for a while so it may pick up issues unrelated to your specific changes.?\n\n\nLorin?\n?\nSent from Mailbox for iPhone\n\nOn Fri, Mar 29, 2013 at 3:58 PM, Joe Topjian <joe.topjian at cybera.ca>\nwrote:\n\n> Hello,\n> I\'m working on Bug 1117767 (GlusterFS and Cinder) and have a few questions:\n> 1. Is it OK to have changes to multiple books in one commit? For this bug,\n> I edited the Compute, Block, and Ops books.\n> 2. I\'m getting an error when trying to generate the Compute Admin book.\n> This happens on my modified repo and a clean repo:\n> [INFO]\n> ------------------------------------------------------------------------\n> [INFO] BUILD FAILURE\n> [INFO]\n> ------------------------------------------------------------------------\n> [INFO] Total time: 1:03.474s\n> [INFO] Finished at: Fri Mar 29 13:50:36 MDT 2013\n> [INFO] Final Memory: 100M/346M\n> [INFO]\n> ------------------------------------------------------------------------\n> [ERROR] Failed to execute goal\n> com.rackspace.cloud.api:clouddocs-maven-plugin:1.7.2:generate-webhelp\n> (generate-webhelp) on project openstack-guide: Failed to transform\n> bk-compute-adminguide.xml. Processing terminated by xsl:message at line 222\n> -> [Help 1]\n> [ERROR]\n> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e\n> switch.\n> [ERROR] Re-run Maven using the -X switch to enable full debug logging.\n> [ERROR]\n> [ERROR] For more information about the errors and possible solutions,\n> please read the following articles:\n> [ERROR] [Help 1]\n> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException\n> The link says that the error is plugin-specific which is beyond me at the\n> moment. Any ideas?\n> Thanks,\n> Joe\n> -- \n> Joe Topjian\n> Systems Administrator\n> Cybera Inc.\n> www.cybera.ca\n> Cybera is a not-for-profit organization that works to spur and support\n> innovation, for the economic benefit of Alberta, through the use\n> of cyberinfrastructure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130329/9c8fb82c/attachment.html>\n\n','<CAD07=DdO7+U4Jna0+GtfRcPQy30vqpoXXJ1RbcP-0xgS82zk+A@mail.gmail.com>',NULL),('<1364827813.2563.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-01 15:50:13',3600,'2013-04-01 14:50:13',NULL,'[openstack-tc] TC Meeting tomorrow Tue Apr 2, 20:00 UTC','On Mon, 2013-04-01 at 14:17 +0200, Thierry Carrez wrote:\n> Welcome to new and returning members of the Technical Committee !\n> \n> Tomorrow at 20:00 UTC we\'ll hold an introductory TC meeting on\n> #openstack-meeting with the following agenda:\n> \n> * Best date for a TC members dinner during the Summit\n\nI we do at 6/6.30, I\'ve no real preference for a day\n\n> * Discussion: Policy on use of GPL libraries [1]\n> \n> [1]\n> http://lists.openstack.org/pipermail/openstack-dev/2013-March/006772.html\n\nSorry, I\'m unlikely to be able to make it - I\'m travelling and have a\nmeeting I can\'t miss at that time\n\nSo, can we punt the GPL libraries issue for another week? AFAIK Richard\nFontana is working with the Legal Affairs committee, but I think some\nviews from TC folks would help them\n\nCheers,\nMark.\n\n\n\n','<51597AC9.6040000@openstack.org>',NULL),('<1364902820.15085.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-02 07:40:20',-14400,'2013-04-02 11:40:20',NULL,'[openstack-tc] TC Meeting tomorrow Tue Apr 2, 20:00 UTC','On Tue, 2013-04-02 at 13:38 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > Sorry, I\'m unlikely to be able to make it - I\'m travelling and have a\n> > meeting I can\'t miss at that time\n> > \n> > So, can we punt the GPL libraries issue for another week? AFAIK Richard\n> > Fontana is working with the Legal Affairs committee, but I think some\n> > views from TC folks would help them\n> \n> Since you are the one who added this point to the agenda, I see no point\n> in discussing it while you\'re away :)\n> \n> So for this week we\'ll just have a quick discussion on the ideal date\n> for a TC dinner. If you can\'t make it to the meeting today, please post\n> your availability to this list.\n\nI already did! :)\n\n  http://lists.openstack.org/pipermail/openstack-tc/2013-April/000135.html\n\n  \"I we do at 6/6.30, I\'ve no real preference for a day\"\n\ni.e. any evening is fine for me, but I\'d prefer we do it early in the evening\n\nCheers,\nMark.\n\n\n\n','<515AC32E.1020806@openstack.org>',NULL),('<1364907083.13777832.1370866858985.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 08:20:58',-14400,'2013-06-10 12:20:58',NULL,'[openstack-dev] [Horizon] 3ds.js','Hi Matt,\n\n\"Matt Joyce\" <matt.joyce at cloudscaling.com> wrote:\n> They are not rendering in devstack atm.\n\nYou might want to check that your version of django_compressor is >= 1.3.\n\nRegards,\n\nJulie\n\n> Also I\'ve been told bar graphs are a poor design for rendering data in a\n> format easy for humans to interpret.  I\'ll see if I can find who is putting\n> that together and sync up with them.\n> \n> -Matt\n\n\n','<CAGYSk8duHynBgwmBzD61iCbqpja=OiGmZ+bHxiSLmU+1ne05iA@mail.gmail.com>',NULL),('<1364936488.15085.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-02 17:01:28',-14400,'2013-04-02 21:01:28',NULL,'[Openstack-stable-maint] Preparing for 2012.2.4','On Wed, 2013-03-20 at 07:31 +0000, Mark McLoughlin wrote:\n> Hey\n> \n> I\'ve been struggling to stay on top of stable/folsom stuff lately so\n> Alan is going to help out with the next release with a view taking\n> responsibility for future releases.\n> \n> 2012.2.4 is due for release on 2013-04-11, so we\'d like a release\n> candidate on 2013-04-04. That gives us two weeks to prepare. This will\n> likely be the last release in the 2012.2.x series.\n\nSo, we\'re still hoping to do the RC this week but there\'s a lot of\nreviews outstanding. Please do jump in and help clear the queue:\n\nhttps://review.openstack.org/#/q/status:open+branch:stable/folsom,n,z\n\nThanks,\nMark.\n\n\n\n','<1363764693.12595.143.camel@sorcha>',NULL),('<1364939246.173922833@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-02 16:47:26',-18000,'2013-04-02 21:47:26',NULL,'[openstack-community] OpenStack in the.org pavilion at the MySQL\n	Users Conference and Expo - let\'s make it work!','\n\nThanks to Mark Atwood for fielding the offer for an OpenStack presence at the MySQL conference in the Santa Clara Convention Center.  I spoke to the .org pavilion organizer today.  The offer is no charge and includes a 6\' table, chairs, sign and 1 electrical outlet (no Internet).  We can do this with enough volunteers.  I\'ll support it by drawing up a booth volunteer schedule and shipping the following:\n \n- tablecloth\n- hanging banner\n- 6\' popup quickscreen summarizing the software\n- collateral\n- stickers to giveaway\n- pens to giveaway\n- videos and ppt presentations in a Dropbox for advance download to laptops (no monitor rental; and no Internet for onsite download)\n \nMark has offered to setup and Colin McNamara has volunteered for Wednesday, I assume for the daytime hours.   We need a bunch of volunteers to make this work.  The expo hours are\n \nMonday, 4/22, 1:00-4:15 setup (Mark Atwood)\nMonday, 4/22 4:30-6:30 opening reception\nTuesday, 4/23 10:20-5:20\nWednesday 4/24: 10:20-4:50 (Colin McNamara) and 6-9pm reception\nThursday, 4/25: 10:45-1:20\nThursday, 4/25 1:20-3:45 teardown, packing, return shipping. \n \nIf possible to commit by Thursday, we can get in the conference guide.  Thanks everyone for making it happen!-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130402/e53a5747/attachment.html>\n\n',NULL,NULL),('<1364940067.15085.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-02 18:01:07',-14400,'2013-04-02 22:01:07',NULL,'[Openstack-stable-maint] Preparing for 2012.2.4','On Tue, 2013-04-02 at 23:57 +0200, Alan Pevec wrote:\n> 2013/4/2 Mark McLoughlin <markmc at redhat.com>:\n> > So, we\'re still hoping to do the RC this week but there\'s a lot of\n> > reviews outstanding. Please do jump in and help clear the queue:\n> >\n> > https://review.openstack.org/#/q/status:open+branch:stable/folsom,n,z\n> \n> For last-minute fun, looks like gate is blocked on getting at least\n> updated glanceclient and quantumclient on pypi:\n> \n> http://logs.openstack.org/23996/4/gate/gate-tempest-devstack-vm-smoke/403/console.html\n> \n> error: Installed distribution prettytable 0.7.1 conflicts with\n> requirement prettytable>=0.6,<0.7\n> \n> Fixed in\n>  https://github.com/openstack/python-glanceclient/commit/31960f0a8584802852d97ec8ce27b5516b32d63b\n>  https://github.com/openstack/python-quantumclient/commit/714ade07ac4d1ac0cdf545f5b0823e88af0c03ae\n> \n> I\'ve asked on #openstack-dev owners to push new releases to pypi which\n> should unblock this.\n\nLovely ... cc-ed new and old PTLs, hopefully we can get them released\nquickly.\n\nCheers,\nMark.\n\n\n\n','<CAGi==UXBE0__i7e=TQVRaSnGvqwqwRZLA52taNNPhLDfb6kf_g@mail.gmail.com>',NULL),('<1365007772.190322811@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-04-03 11:49:32',-18000,'2013-04-03 16:49:32',NULL,'[openstack-community] Several 2013 Conference Call for Papers (speaking opportunities) Deadlines Approaching','\nIf you\'d like to be considered for a speaking session about OpenStack at key 2013 industry and regional events, several Call for Papers (CFP) deadlines are approaching.  Here is a list in deadline order with links for submissions. We appreciate your participation, especially with new success stories and topics!\n \nHere is a list in CFP deadline order with links for submissions.\nPyCon Australia speaker [http://2013.pycon-au.org/programme/call_for_proposals] deadline is this Friday, April 5th! Get your submissions in quickly if you?re interested in speaking. The event is July 5-7th, with a Python on OpenStack mini-conference organized by Aptira on July 5th. The CFP for the mini-conf closes on April 15th - submit your topic at [http://aptira.wufoo.com/forms/pyconau2013-openstack-miniconf-call-for-presenters/] http://aptira.wufoo.com/forms/pyconau2013-openstack-miniconf-call-for-presenters/ \n\nThe Call for Papers for [http://www.cloudcomputingexpo.com/general/papers2013east.htm] Cloud Expo East deadline is also this Friday, April 5! Event is June 10-13th in New York City.\n\n[http://www.openstack-israel.org/] OpenStack Israel 2013. Join Jonathan Bryce on the agenda on May 27th. Call for Speakers open until April 15th.\n\nSponsor speaking opportunities are still available for [http://www.gluecon.com/2013/] GlueCon, held May 22-23rd in Broomfield, CO. Get your sponsor requests in asap if interested.\n\n[http://utrconf.com/nominate-to-present/] Under the Radar submissions accepted on a rolling basis, but we recommend getting them in soon to be considered. \n\nThe call for papers is open until April 26th for [http://poweringthecloud.com/call4papers_2013.php] Powering the Cloud, a SNW Europe, Virtualization World and Datacenter Technologies co-located conference in Germany. held October 29-30th.\n\n[http://www.cloudconnectevent.com/chicago/call-for-submissions/] Cloud Connect Chicago open for submissions through April 29th. Event dates are October 21-24th. \n\n[http://velocityconf.com/velocityny2013/public/cfp/261] O?Reilly Velocity is open for submissions until April 29th. Conference taking place in New York City, October 14-16th.\n\n[https://www.usenix.org/conference/lisa13/call-for-participation] Usenix LISA 2013 Call for Participation is open until April 30th. Event is November 3-8th in Washington, D.C. \n\n[https://ep2013.europython.eu/call-for-proposals] EuroPython 2013. The event is July 1-7th in Florence, Italy; please submit your sessions and development sprints soon! \n\n[http://events.linuxfoundation.org/events/linuxcon] LinuxCon North America and co-hosted event, [http://events.linuxfoundation.org/events/cloudopen/cfp] CloudOpen North America, accepting submissions until June 17th. Events held together on September 16-18th in New Orleans, LA. \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130403/e613c096/attachment.html>\n\n',NULL,NULL),('<1365027035.2940.30.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-03 17:10:35',-18000,'2013-04-03 22:10:35',NULL,'[openstack-dev] Request for feedback - Nova image building proof of\n	concept','We\'ve put together a simple proof of concept of driving native operating\nsystem installers using Nova:\n\nhttps://github.com/redhat-openstack/image-building-poc\n\nThe python CLI tool in this repo, when combined with the example install\nscripts, can build both glance-backed and cinder-backed JEOS images for\nthe following operating systems entirely inside of Nova:\n\nFedora 17, 18\nUbuntu 10.04, 12.04, 12.10\nRHEL 5.9, 6.4\n\nThese builds can be done using network install sources and, in some\nlimited cases, DVD/ISO install sources.  Full details can be found in\nthe README.md file on github.\n\nSome background discussion about this approach from earlier this year\ncan be found here:\n\nhttps://wiki.openstack.org/wiki/NovaImageBuilding\n\nThe code is a bit rough around the edges but we believe the approach has\npromise and can form the basis for a proper image building service\nnative to OpenStack.\n\nI\'d be grateful if anyone who\'s interested in the problem of image\nbuilding could have a look at this, give it a try and share\nthoughts/feedback.\n\nIt\'s been developed against the packstack Folsom release but has had\nsome limited testing against devstack Grizzly installs.  Building glance\nbacked images may well be possible in earlier releases.\n\nSome specific additional things I\'d like to work on are:\n\n* Expanding the collection of example kickstart/preseed files\n* Adding the ability to pull kickstart/preseed files from libosinfo\n* Adding support for installers beyond Ubuntu and Anaconda - I have\ntaken an early look at Yast but have yet to wrap my brain around the\nbootstrap process.\n\n-Ian\n\n\n\n',NULL,NULL),('<1365082842.2354.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 14:40:42',3600,'2013-04-04 13:40:42',NULL,'[openstack-dev] Request for feedback - Nova image building\n proof of concept','Hi Robert,\n\nOn Thu, 2013-04-04 at 12:27 +1300, Robert Collins wrote:\n> On 4 April 2013 11:10, Ian McLeod <imcleod at redhat.com> wrote:\n> > We\'ve put together a simple proof of concept of driving native operating\n> > system installers using Nova:\n> >\n> > https://github.com/redhat-openstack/image-building-poc\n> >\n> > The python CLI tool in this repo, when combined with the example install\n> > scripts, can build both glance-backed and cinder-backed JEOS images for\n> > the following operating systems entirely inside of Nova:\n> >\n> > Fedora 17, 18\n> > Ubuntu 10.04, 12.04, 12.10\n> > RHEL 5.9, 6.4\n> >\n> > These builds can be done using network install sources and, in some\n> > limited cases, DVD/ISO install sources.  Full details can be found in\n> > the README.md file on github.\n> >\n> > Some background discussion about this approach from earlier this year\n> > can be found here:\n> >\n> > https://wiki.openstack.org/wiki/NovaImageBuilding\n> >\n> > The code is a bit rough around the edges but we believe the approach has\n> > promise and can form the basis for a proper image building service\n> > native to OpenStack.\n> \n> It\'s cool you\'ve done this - I think such a general solution is\n> necessary, particularly for folk running systems like Windows.\n> \n> > I\'d be grateful if anyone who\'s interested in the problem of image\n> > building could have a look at this, give it a try and share\n> > thoughts/feedback.\n> \n> We\'ve been working on a much lighter weight solution - using as you\n> note chroots - because we need something that can build images *fast*.\n> TripleO wants to deploy Openstack as part of the CI pipeline, so even\n> short (multiple second) delays add up rapidly as you starting\n> generating images inline in the landing process.\n> https://github.com/stackforge/diskimage-builder/ is the project we put\n> together.\n> \n> The focus we have is building images which can be used to deploy\n> openstack, so we have a hard requirement to not depend on openstack\n> itself - but having an API that can drive building of images (by\n> spinning up a machine on the back end) would be useful, to make custom\n> images easier for folk on limited hardware etc.\n> \n> Perhaps we can collaborate on having a common API for creating images,\n> with multiple backends - one oz for super generality, and one\n> diskimage-builder for fast creation?\n\nAn API with multiple backends is certainly very openstack-esque :-)\n\nI had seen diskimage-builder and a Nova based image building service as\nboth being separately excellent for their specific use cases:\n\n  - diskimage-builder - the user building the image is an OpenStack \n    admin so is \"close\" to the image store\n\n  - Nova based image building - a facility exposed to remote user of the\n    OpenStack clouds and allows them to build images in the cloud rather\n    than building locally and uploading. Also, it means that the user\n    gets build for compute, network and storage used during the image\n    build itself.\n\nNow, as you say, you could take any image building tool like\ndiskimage-builder and have a service which launches a Nova VM with an\nimage containing the image builder tool, passes through details of what\nyou want built, the user\'s glance/cinder credentials ... and it would\nbehave pretty similarly. I\'m guessing an API abstraction that works for\nboth modes is doable too.\n\nI\'m a little dubious that the speed vs generality tradeoff is worth the\neffort of having multiple drivers (e.g. does the API allow a user to\nchoose which driver to use, or does the admin configure it) but perhaps\nit would be a nice way of bringing different image building ideas\ntogether in the one project.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ0Qs=O3URS1=umpj+2_TjWti+d6P=A+3RZg3jOZTYoKRA@mail.gmail.com>',NULL),('<1365087921.2354.55.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 16:05:21',3600,'2013-04-04 15:05:21',NULL,'[openstack-dev] Updating pip-requires in the stable branch','Hi Julie,\n\nOn Wed, 2013-03-27 at 09:51 -0400, Julie Pichon wrote:\n> Hi all,\n> \n> I\'m currently looking into bug 1157950 [0] for Horizon, which is about\n> adding support for the new fixed_ips quota. The fix depends on a\n> recent version of the Nova client (2.12.0) and I\'m wondering about the\n> impact of having to update pip-requires when backporting it to Folsom.\n> Would increasing the nova client required version cause trouble for\n> the distributions packaging openstack? Without stable branches for the\n> clients I\'m not sure what other solution there is. Any thought/best\n> practice?\n\nWithout thinking about it in too much detail, I think I\'d err on the\nside of not requiring newer clients on the stable branch.\n\nIn theory, the client APIs aren\'t supposed to change but the risk of\nregressions in newer versions is probably enough for some users or\ndistros to want to stick with an older version.\n\ni.e. requiring newer clients generally might make the stable branch less\nof a \"safe source of bugfixes\" if the client updates are themselves\n\"safe\"\n\nThat said, if the bug was serious enough ... the risk of a newer client\nmight be worth it.\n\nIs there any way Horizon could use the newer version if its available,\nbut still work with the older version?\n\nCheers,\nMark.\n\n\n\n','<1482626853.7101268.1364392311972.JavaMail.root@redhat.com>',NULL),('<1365087976.2937.21.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 10:06:16',-18000,'2013-04-04 15:06:16',NULL,'[openstack-dev] Request for feedback - Nova image building\n proof of concept','On Thu, 2013-04-04 at 15:19 +0100, Daniel P. Berrange wrote:\n> On Wed, Apr 03, 2013 at 05:10:35PM -0500, Ian McLeod wrote:\n> > We\'ve put together a simple proof of concept of driving native operating\n> > system installers using Nova:\n> > \n> > https://github.com/redhat-openstack/image-building-poc\n> > \n> > The python CLI tool in this repo, when combined with the example install\n> > scripts, can build both glance-backed and cinder-backed JEOS images for\n> > the following operating systems entirely inside of Nova:\n> > \n> > Fedora 17, 18\n> > Ubuntu 10.04, 12.04, 12.10\n> > RHEL 5.9, 6.4\n> > \n> > These builds can be done using network install sources and, in some\n> > limited cases, DVD/ISO install sources.  Full details can be found in\n> > the README.md file on github.\n> > \n> > Some background discussion about this approach from earlier this year\n> > can be found here:\n> > \n> > https://wiki.openstack.org/wiki/NovaImageBuilding\n> > \n> > The code is a bit rough around the edges but we believe the approach has\n> > promise and can form the basis for a proper image building service\n> > native to OpenStack.\n> > \n> > I\'d be grateful if anyone who\'s interested in the problem of image\n> > building could have a look at this, give it a try and share\n> > thoughts/feedback.\n> > \n> > It\'s been developed against the packstack Folsom release but has had\n> > some limited testing against devstack Grizzly installs.  Building glance\n> > backed images may well be possible in earlier releases.\n> > \n> > Some specific additional things I\'d like to work on are:\n> > \n> > * Expanding the collection of example kickstart/preseed files\n> > * Adding the ability to pull kickstart/preseed files from libosinfo\n> > * Adding support for installers beyond Ubuntu and Anaconda - I have\n> > taken an early look at Yast but have yet to wrap my brain around the\n> > bootstrap process.\n> \n> IMHO the tool should not contain any kickstart files at all, nor\n> explicit support for different installers. The main goal of libosinfo\n> is to enable the creation of applications like this, without needing\n> to have any OS specific code what-so-ever. All the OS specific info\n> ought to be isolated in the libosinfo database, so that all code is\n> purely metadata driven. In other words once the basic tool is created\n> to use libosinfo, there should be now coding work required to support\n> any other OS distros. Simply dropping in a suitable data file to the\n> libosinfo data is all that should be requried for ongoing support.\n\n> It may be that you find cases where libosinfo isn\'t providing enough\n> metadata to avoid OS-specific python code, but that should be fairly\n> rare, since the GNOME Boxes app developers have already done alot of\n> work to ensure libosinfo is covering all bases.\n\nSourcing default install scripts (when they ar available) from libosinfo\nis one of the next items on our TODO list.  As you\'ve suggested, I\nexpect this will involve us wrapping libosinfo for now and applying some\nOS-specific bits to the output as needed.  This will likely result in\nsome feature requests and/or patches flowing back to libosinfo.\n\nSome things it currently appears to be lacking to achieve the goal of\nzero OS specific code:\n\n* Install scripts for OSes other than Fedora/RHEL and Windows:\n\nhttp://git.fedorahosted.org/cgit/libosinfo.git/tree/data/install-scripts\n\n\n* Substitutions within install scripts to control where the install\nmedia is sourced from.  For example, with Anaconda:\n\nhttp://fedoraproject.org/wiki/Anaconda/Kickstart#install\n\n\n* Some way of expressing how to generate a boot environment that\ninitiates the unattended install.  This has some overlap with the\ninstall media sourcing issue abovc.  Basically, representing the details\nfound here in some more abstract way:\n\nhttps://github.com/redhat-openstack/image-building-poc/blob/master/image_utils.py#L398\n\nI\'ll try to have a look at how the Gnome Box project is using it.\n\n> \n> Regards,\n> Daniel\n\n-- \nIan McLeod - Red Hat\noffice: 312.660.3539\nmobile: 312.899.6736\nrh internal: (81) 33539\n\n\n\n','<20130404141920.GE19785@redhat.com>',NULL),('<1365089078.2354.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 16:24:38',3600,'2013-04-04 15:24:38',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','Hey!\n\nOn Thu, 2013-04-04 at 11:01 -0400, Monty Taylor wrote:\n> I know everyone loves looking at numbers around this time. I\'m sure\n> there will be several new reports on which people or companies did the\n> most. I wanted to poke at a slightly different thing - which is overall\n> combined community effort.\n> \n> 	                Essex	Folsom	Grizzly\n> Patches Uploaded	11036	17986	29308\n> Changes Created	        5137	5990	12721\n> Changes Landed	        4235	4978	10561\n> Avg patches per Change	2.6	3.6	2.7\n> Landing Percentage	82%	83%	83%\n> \n> Clearly our velocity continues to increase, which is great. Something\n> happened during folsom to cause us to need to on-average iterate more to\n> get a change landed, but then we corrected the ship during grizzly. I\'m\n> more fascinated by the fact that our percentage of changes created to\n> changes landed is holding extremely steady.\n> \n> Great work at managing the firehose everybody!\n\nIndeed, those are amazing stats! Nice one Monty.\n\nI sent out gitdm based \"Who wrote Essex/Folsom\" stats in previous\nreleases:\n\n  https://lists.launchpad.net/openstack/msg09650.html\n  https://lists.launchpad.net/openstack/msg17006.html\n\nand I\'ve done them again for Grizzly:\n\n  https://github.com/markmc/openstack-gitdm/blob/results/grizzly/git-stats.txt\n\nFrankly, though, I\'m losing faith in this \"number of commits\" statistic\nbeing all that useful. Most of my commits were probably trivial cfg\ncleanups in Nova.\n\nAlso, bitergia\'s stats are getting more and more comprehensive:\n\n  http://blog.bitergia.com/2013/04/04/companies-contributing-to-openstack-grizzly-analysis/\n\nSo ... consider openstack-gitdm orphaned and open to a new\nmaintainer :-)\n\nCheers,\nMark.\n\n\n\n','<515D95D1.1020206@inaugust.com>',NULL),('<1365098571.20961.112.camel@ttssb.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-04-04 20:02:51',7200,'2013-04-04 18:02:51',NULL,'[openstack-qa] [Tempest] Blueprint: add-scenario-tests','If the test subject behave like working OpenStack deployment it is a\n\"working OpenStack\" installation, this is the concept behind\ntempest/tempest. (Black Box) \nThe installation method is correct when the result is a \"working\nOpenStack\".\n\nThe tests cases are focusing on functionality and API testing,\nthese should behave in same way regardless to the installation\nmethod and configuration.\n\nSome OpenStack configuration does not able to do certain operation, for\nexample cinder with nfs is not able to create snapshots,\nbut it does not makes the model invalid.  Usually just small parts\neffected because of a not supported functionality.\n\ntempest/tempest does not looks behind the scenes.\nIf as an \"end-user\" we see the deployment is working as expected, the\ntest subject considered good.\n\nTwo deployment\'s internal behavior can be very different, even if they\njust differs in one configuration variable ...\n\nBut, we can use the same tempest/tempest to test them.\n\nThe gate test just using  single virtual machines for testing the system\nwith 3 \"little\" different configuration.\n\n\nIt would be good to see those interesting scenarios, which can not fit\nto the tempest/tempest model and causing significant coverage lost.\n\nI would like to see 3-4 scenario specification with detailed\ninstallation/configuration steps. In order to see where can it reach\nadditional code paths.\n\n\nIn a multi-node environment we have greater chance to see certain bug\ntypes and we will have little more behavior to test, like volume types and\nscheduling.\n\nI agree, for hunting those issue mainly we need better \"stress\"\nframework, probably with some temporary fault injection method in\naddition.\n\nI agree we need something which test things which are outside from the\ngating tempest scope.\n\n\n\nThis scenario member/role things may included policy.json settings. \n\nBTW: What is the reason behind these settings are in a configuration\nfile and not in a database ?\n\nThe policy rules interpreted by a module which is in the oslo and used\nby multiple projects.\nThis module functionality tested by unit tests. \nUnit test are good for testing it\'s decision making capabilities, we do\nnot really need an integration test tool for these IMHO.\n\nEvery requested action should pass a policy testing before execution!\nBTW: Can I say if an action needs two policy check, it is a bug ?  \n\nBTW: Not just the policy checks are able to refuse an operation.\n\nEvery policy check should decide is the operation authorized or not.\nWe have relatively good coverage for the authorized code path, but the\nnot authorized code path, is not tested intensively.\n\nNow, we have 3 type of user\'s which attempting an operation: \n- admin\n- non-admin user\n- non-admin user from a different tenant\n\nNow, we do not have enough negative test case even for the possible\nsituations from these 3 groups.\n\n\nThe main issue with the policy, it can changes the expected behavior in\ntempest viewpoint.\n\nThe policy.json has the ability to define very strange behaviors, so we\nwould need strange test framework for following all of the\npossibilities.\nDo we want to test all possibilities on tempest/tempest level ?\n \nTempest expect the test user (demo), has the ability (rights) to pass\nthe test cases.\n\nIf we start creating test users which has all necessary roles for a test\ncase, we do not test anything new, because the policy module itself\ntested by unit tests and in the higher level we just see the very same\ndecision..\n\nWe are testing a new code path only if the operation rejected by the\npolicy module.   \n  \nWe should change the policy settings on the gate by extending a model\nwith a \'nobody\' users.\n\nNobody is user for testing the situation when the user is in the same\ntenant, but does not have permission for any operation.\n  \nWe should have \"somebody\" users who are not admin users, but have\npermission for doing the things which was allowed by default policy.json\nsettings.\n\nIn this case we will have 4 type:\n- admin\n- \"somebody\"\n- \"nobody\" (rejection caused by policy)\n- \"somebody\" user from a different tenant\n\nCreating a tempest/devstack migration path seams possible.\n\nWe should add some role related config parameter to tempest.conf for the run time user creation as\njaypipes mentioned since long.\n\nWe should add some role to the demo users in devstack...\nWe need to change all default policy.json on the gate...\n\nIs this \"model\" good enough for judging the policy things ?\n\nDo we have any other \"strange\" thing to test ?\n\nBest Regards,\nAttila\n\n\n\n\n\n','<5152F68C.7020804@qrclab.com>',NULL),('<1365103409.2937.71.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 14:23:29',-18000,'2013-04-04 19:23:29',NULL,'[openstack-dev] Request for feedback - Nova image building\n proof of concept','On Thu, 2013-04-04 at 10:58 -0700, Vishvananda Ishaya wrote:\n> A whole bunch of work has already been done around image building from install media in a project called veewee:\n> \n> https://github.com/jedi4ever/veewee\n\nAnd additional work to do this exists in Oz:\n\nhttps://github.com/clalancette/oz\n\nWhich is used in the Image Factory project:\n\nhttp://github.com/aeolusproject/imagefactory\n\nHowever none of these tools use Nova to manage the install containers.\nThat is the primary point of the demonstration code I\'ve posted.  I\'m\nunaware of any other tool that does this.\n\nBoth Oz and VeeWee could, in theory, be enhanced to support OpenStack\ninstances as another virt provider in which to perform installs using\nthe approach we\'re demonstrating here.\n\n> It also might be worth looking at whether veewee could be mixed with the vagrant openstack provider:\n> \n> https://github.com/cloudbau/vagrant-openstack\n\nAs far as I can tell Vagrant has a hard requirement for working base\nimages as input.  It does not attempt to build base images from scratch,\nthey must be provided.  In that sense it seems similar to\nbaseimage-builder.\n\nTools like VeeWee and Oz (and potentially a builder based on our\ndemonstration) can provide this base input.\n\n> to allow the image building to be done remotely on an openstack cloud.\n> \n> Vish\n> \n> On Apr 3, 2013, at 3:10 PM, Ian McLeod <imcleod at redhat.com> wrote:\n> \n> > We\'ve put together a simple proof of concept of driving native operating\n> > system installers using Nova:\n> > \n> > https://github.com/redhat-openstack/image-building-poc\n> > \n> > The python CLI tool in this repo, when combined with the example install\n> > scripts, can build both glance-backed and cinder-backed JEOS images for\n> > the following operating systems entirely inside of Nova:\n> > \n> > Fedora 17, 18\n> > Ubuntu 10.04, 12.04, 12.10\n> > RHEL 5.9, 6.4\n> > \n> > These builds can be done using network install sources and, in some\n> > limited cases, DVD/ISO install sources.  Full details can be found in\n> > the README.md file on github.\n> > \n> > Some background discussion about this approach from earlier this year\n> > can be found here:\n> > \n> > https://wiki.openstack.org/wiki/NovaImageBuilding\n> > \n> > The code is a bit rough around the edges but we believe the approach has\n> > promise and can form the basis for a proper image building service\n> > native to OpenStack.\n> > \n> > I\'d be grateful if anyone who\'s interested in the problem of image\n> > building could have a look at this, give it a try and share\n> > thoughts/feedback.\n> > \n> > It\'s been developed against the packstack Folsom release but has had\n> > some limited testing against devstack Grizzly installs.  Building glance\n> > backed images may well be possible in earlier releases.\n> > \n> > Some specific additional things I\'d like to work on are:\n> > \n> > * Expanding the collection of example kickstart/preseed files\n> > * Adding the ability to pull kickstart/preseed files from libosinfo\n> > * Adding support for installers beyond Ubuntu and Anaconda - I have\n> > taken an early look at Yast but have yet to wrap my brain around the\n> > bootstrap process.\n> > \n> > -Ian\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nIan McLeod - Red Hat\noffice: 312.660.3539\nmobile: 312.899.6736\nrh internal: (81) 33539\n\n\n\n','<34596810-D733-4C4B-A8E0-1FE2AB80D839@gmail.com>',NULL),('<1365107858.2937.92.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-04 15:37:37',-18000,'2013-04-04 20:37:37',NULL,'[openstack-dev] Request for feedback - Nova image building\n proof of concept','On Fri, 2013-04-05 at 07:36 +1300, Robert Collins wrote:\n> On 5 April 2013 03:13, Daniel P. Berrange <berrange at redhat.com> wrote:\n> > On Thu, Apr 04, 2013 at 12:27:29PM +1300, Robert Collins wrote:\n> >>\n> >> Perhaps we can collaborate on having a common API for creating images,\n> >> with multiple backends - one oz for super generality, and one\n> >> diskimage-builder for fast creation?\n> >\n> > There is much more than just speed to consider here - there are a great\n> > many downsides to the chroot based approach IMHO, to the extent that I\n> > don\'t think it is worthwhile going down that route.\n> >\n> > First of all a chroot based approach is not taking advantage of the\n> > OS distro\'s installer, so you have to writen a load of custom install\n> \n> s/taking advantage of/having to deal with/.\n> \n> We don\'t run installers in the chroot based approach. We *start* with\n> cloud images published by the distro vendor (or we separate that to a\n> separate concern). This removes a huge source of latency, and ensures\n> that any cloud specific features the vendor includes in their cloud\n> installs are already present.\n\nI think I understand.  Like Vagrant, you take a known working minimal\nimage as your input and then build from there.  Correct?\n\nWe take install media and install scripts as input and generate a\nminimal image (or, potentially, some other image flavors).  Doing this,\nand doing it entirely within Nova containers, is the point of the demo\ncode I pointed to.\n\nI\'d be interested to know if you can use a base build generated by our\ndemo code as your input.  For example, the Ubuntu 12.04 image generated\nby running this on a checked out copy of the code:\n\n./create_image.py --username admin --tenant admin --password password \\\n  --auth-url http://10.10.10.10:5000/v2.0 \\\n  --glance-url http://10.10.10.10:9292/ \\\n  --root-password myrootpw \\\n  install_scripts/ubuntu-12.04-jeos.preseed\n\n(And, I suppose, likewise with an Ubuntu image generated by Oz.)\n\n> > code for each OS to be sppported. The many existing/previous chroot\n> > based installers show this OS specific code is very fragile and will\n> > frequently break when a new release comes out & is alot of work to\n> > maintain.\n> \n> Exactly why we don\'t run the installer.\n> \n> > You\'re limited by the types of OS that can bootstrapped via chroot,\n> > to mostly just Linux distros. No Windows, BSD, Solaris etc. Even with\n> > Linux OS, you can run into compatibility issues if the kernel running\n> > the chroot is not the same as the kernel that the OS usually uses.\n> > For example, at certain times glibc in Fedora is set to require a new\n> > minimum kernel version. So if your OpenStack is say RHEL-6 you may\n> > find it impossible to do a chroot install of, say, Fedora 22.\n> \n> Huh? If you run it in a VM, that VM kernel can be any version. So you\n> can run the build in a Fedora-21 image, to get a Fedora-22 image. And\n> if Fedora-22 can\'t run in anything but its own, you could use an Oz\n> based image as your host image.\n\nI believe Dan\'s point here is that bootstraping an image _from scratch_\nusing chroots is fragile, sometimes complicated and often impossible.  I\nstrongly agree.  Even the hypothetical example you\'ve given of building\nF22 in an F21 environment isn\'t always guaranteed to work without some\narm twisting.  \n\n> \n> > Unless you boot up a guest in which run the chroot install, you are\n> > exposing yourself to serious security risks. If you are booting up a\n> > guest to run the chroot install, then you might as well just run the\n> > real OS installer in a guest and forget about chroot installs.\n> \n> Totally agree, when running third party code.\n> \n> > Installation time is going to be dominated by the time to install the\n> > packages actual packages, regardless of what technique is used to do\n> > the installation. Running the native guest installer requires booting\n> > a VM which has a little overhead, but as mentioned above and chroot\n> > tool should be run inside a throw-away guest too, otherwise you have\n> > unacceptable security risks to your infrastructure. So I don\'t really\n> > think there is going to be much of a compelling speed advantage to\n> > chroot based installs - a few % difference at best.\n> \n> One of our reference images - ubuntu mysql - builds in under 5\n> minutes. Last time I installed Fedora it took considerably longer than\n> that (and the 5 minutes is dominated by qemu-img -c compression to\n> make the image as small as possible for internet download.\n> http://jenkins.tripleo.org:8080/job/autobuilt-images/elements=ubuntu%20mysql/lastBuild/\n> - I\'d be delighted to know that you have an equally fast but much more\n> general solution.\n\nIf you are starting the clock at the point you launch an already\ncompleted image, and comparing this with the time it takes for a\nfrom-scratch Fedora install, I\'d submit that you are comparing apples to\noranges :-).\n\nBut seriously, when running our Nova demo code using a CDROM in Cinder\nas the install source, I\'ve seen an F18 JEOS install finish in the 4-5\nminute range.\n\n> > Finally there are already many chroot based installers for OS that\n> > exist. Given that the amount of custom code required for each OS\n> > to be supported, I\'m not convinced it is a good use of time to be\n> > re-inventing this in OpenStack. For the few places which really do\n> > want todo chroot based installs, just use an existing tool.\n> \n> Right, which is why - and let me really stress this -\n> *diskimage-builder is NOT an installer*. Getting an OS to install\n> isn\'t an interesting part of the problem space we\'re tackling, which\n> is building golden images for Heat.\n\nUnderstood.  We, on the other hand, are interested in precisely the\nproblem of getting an OS to install, with the further restriction of\ndoing that install using the resources already available within an\nOpenStack deployment.\n\nI think, as you point out, these goals are complimentary.\n\n> \n> -Rob\n> \n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Cloud Services\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nIan McLeod - Red Hat\noffice: 312.660.3539\nmobile: 312.899.6736\nrh internal: (81) 33539\n\n\n\n','<CAJ3HoZ0rHeVdzCVwAtsQqe=wq9LWQHgsHgV=4ggYcP3MhgT8dQ@mail.gmail.com>',NULL),('<1365121569.17.1373954833383.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-16 06:07:13',0,'2013-07-16 06:07:13',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #8','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/8/>\n\n------------------------------------------\n[...truncated 10505 lines...]\n2013-07-16 06:05:55 + return 1\n2013-07-16 06:05:55 + is_service_enabled mysql postgresql\n2013-07-16 06:05:55 + services=\'mysql postgresql\'\n2013-07-16 06:05:55 + for service in \'${services}\'\n2013-07-16 06:05:55 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,mysql, ]]\n2013-07-16 06:05:55 + return 0\n2013-07-16 06:05:55 + configure_database\n2013-07-16 06:05:55 + configure_database_mysql\n2013-07-16 06:05:55 + echo_summary \'Configuring and starting MySQL\'\n2013-07-16 06:05:55 + [[ -t 3 ]]\n2013-07-16 06:05:55 + echo -e Configuring and starting MySQL\n2013-07-16 06:05:55 + is_ubuntu\n2013-07-16 06:05:55 + [[ -z deb ]]\n2013-07-16 06:05:55 + \'[\' deb = deb \']\'\n2013-07-16 06:05:55 + MY_CONF=/etc/mysql/my.cnf\n2013-07-16 06:05:55 + MYSQL=mysql\n2013-07-16 06:05:55 + is_fedora\n2013-07-16 06:05:55 + [[ -z Ubuntu ]]\n2013-07-16 06:05:55 + \'[\' Ubuntu = Fedora \']\'\n2013-07-16 06:05:55 + \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-07-16 06:05:55 + \'[\' Ubuntu = CentOS \']\'\n2013-07-16 06:05:55 + is_suse\n2013-07-16 06:05:55 Configuring and starting MySQL\n2013-07-16 06:05:55 + [[ -z Ubuntu ]]\n2013-07-16 06:05:55 + \'[\' Ubuntu = openSUSE \']\'\n2013-07-16 06:05:55 + \'[\' Ubuntu = \'SUSE LINUX\' \']\'\n2013-07-16 06:05:55 + is_ubuntu\n2013-07-16 06:05:55 + [[ -z deb ]]\n2013-07-16 06:05:55 + \'[\' deb = deb \']\'\n2013-07-16 06:05:55 + sudo mysql -uroot -psecret -h127.0.0.1 -e \'GRANT ALL PRIVILEGES ON *.* TO \'\\\'\'root\'\\\'\'@\'\\\'\'%\'\\\'\' identified by \'\\\'\'secret\'\\\'\';\'\n2013-07-16 06:05:55 + sudo sed -i \'/^bind-address/s/127.0.0.1/0.0.0.0/g\' /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo grep -q default-storage-engine /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i -e \'/^\\[mysqld\\]/ a default-storage-engine = InnoDB\' /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i /log.slow.queries/d /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i -e \'/^\\[mysqld\\]/ a log-slow-queries = /var/log/mysql/mysql-slow.log\' /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i /long.query.time/d /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i -e \'/^\\[mysqld\\]/ a long-query-time = 0\' /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i /log.queries.not.using.indexes/d /etc/mysql/my.cnf\n2013-07-16 06:05:55 + sudo sed -i -e \'/^\\[mysqld\\]/ a log-queries-not-using-indexes\' /etc/mysql/my.cnf\n2013-07-16 06:05:55 + restart_service mysql\n2013-07-16 06:05:55 + is_ubuntu\n2013-07-16 06:05:55 + [[ -z deb ]]\n2013-07-16 06:05:55 + \'[\' deb = deb \']\'\n2013-07-16 06:05:55 + sudo /usr/sbin/service mysql restart\n2013-07-16 06:05:55 mysql stop/waiting\n2013-07-16 06:05:55 mysql start/running, process 10398\n2013-07-16 06:05:55 ++ trueorfalse True False\n2013-07-16 06:05:55 ++ local default=True\n2013-07-16 06:05:55 ++ local testval=False\n2013-07-16 06:05:55 ++ [[ -z False ]]\n2013-07-16 06:05:55 ++ [[ 0 no false False FALSE =~ False ]]\n2013-07-16 06:05:55 ++ echo False\n2013-07-16 06:05:55 ++ return\n2013-07-16 06:05:55 + USE_SCREEN=False\n2013-07-16 06:05:55 + [[ False == \\T\\r\\u\\e ]]\n2013-07-16 06:05:55 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-07-16 06:05:57 + [[ -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-07-16 06:05:57 + init_service_check\n+ exec\n2013-07-16 06:05:57 + SCREEN_NAME=stack\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-07-16 06:05:57 + SERVICE_DIR=/opt/stack/new/status\n2013-07-16 06:05:57 + [[ ! -d /opt/stack/new/status/stack ]]\n2013-07-16 06:05:57 + mkdir -p /opt/stack/new/status/stack\n2013-07-16 06:05:57 + rm -f \'/opt/stack/new/status/stack/*.failure\'\n2013-07-16 06:05:57 + is_service_enabled sysstat\n2013-07-16 06:05:57 + services=sysstat\n2013-07-16 06:05:57 + for service in \'${services}\'\n2013-07-16 06:05:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,sysstat, ]]\n2013-07-16 06:05:57 + return 0\n2013-07-16 06:05:57 + [[ -n /opt/stack/new/screen-logs ]]\n2013-07-16 06:05:57 + screen_it sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + SCREEN_NAME=stack\n2013-07-16 06:05:57 + SERVICE_DIR=/opt/stack/new/status\n2013-07-16 06:05:57 ++ trueorfalse True False\n2013-07-16 06:05:57 ++ local default=True\n2013-07-16 06:05:57 ++ local testval=False\n2013-07-16 06:05:57 ++ [[ -z False ]]\n2013-07-16 06:05:57 ++ [[ 0 no false False FALSE =~ False ]]\n2013-07-16 06:05:57 ++ echo False\n2013-07-16 06:05:57 ++ return\n2013-07-16 06:05:57 + USE_SCREEN=False\n2013-07-16 06:05:57 + is_service_enabled sysstat\n2013-07-16 06:05:57 + services=sysstat\n2013-07-16 06:05:57 + for service in \'${services}\'\n2013-07-16 06:05:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,sysstat, ]]\n2013-07-16 06:05:57 + return 0\n2013-07-16 06:05:57 + screen_rc sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + SCREEN_NAME=stack\n2013-07-16 06:05:57 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-07-16 06:05:57 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-07-16 06:05:57 + echo \'sessionname stack\'\n2013-07-16 06:05:57 + echo \'hardstatus alwayslastline \'\\\'\'\'\\\'\'\'\n2013-07-16 06:05:57 + echo \'setenv PROMPT_COMMAND /bin/true\'\n2013-07-16 06:05:57 + echo \'screen -t shell bash\'\n2013-07-16 06:05:57 + grep sysstat /opt/stack/new/devstack/stack-screenrc\n2013-07-16 06:05:57 ++ echo -ne \'\\015\'\n2013-07-16 06:05:57 + NL=$\'\\r\'\n2013-07-16 06:05:57 + echo \'screen -t sysstat bash\'\n2013-07-16 06:05:57 + echo \'stuff \"sar -o /opt/stack/new/screen-logs/sysstat.dat 1\n\"\'\n2013-07-16 06:05:57 + [[ False = \\T\\r\\u\\e ]]\n2013-07-16 06:05:57 + run_process sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + local service=sysstat\n2013-07-16 06:05:57 + local \'command=sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + echo 11032\n2013-07-16 06:05:57 + _run_process sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + local service=sysstat\n2013-07-16 06:05:57 + local \'command=sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-07-16 06:05:57 + exec\n2013-07-16 06:05:57 + exec\n2013-07-16 06:05:57 + is_service_enabled key\n2013-07-16 06:05:57 + services=key\n2013-07-16 06:05:57 + for service in \'${services}\'\n2013-07-16 06:05:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,key, ]]\n2013-07-16 06:05:57 + return 0\n2013-07-16 06:05:57 + echo_summary \'Starting Keystone\'\n2013-07-16 06:05:57 + [[ -t 3 ]]\n2013-07-16 06:05:57 + echo -e Starting Keystone\n2013-07-16 06:05:57 Starting Keystone\n2013-07-16 06:05:57 + init_keystone\n2013-07-16 06:05:57 + recreate_database keystone utf8\n2013-07-16 06:05:57 + local db=keystone\n2013-07-16 06:05:57 + local charset=utf8\n2013-07-16 06:05:57 + recreate_database_mysql keystone utf8\n2013-07-16 06:05:57 + local db=keystone\n2013-07-16 06:05:57 + local charset=utf8\n2013-07-16 06:05:57 + mysql -uroot -psecret -hlocalhost -e \'DROP DATABASE IF EXISTS keystone;\'\n2013-07-16 06:05:57 + mysql -uroot -psecret -hlocalhost -e \'CREATE DATABASE keystone CHARACTER SET utf8;\'\n2013-07-16 06:05:57 + /opt/stack/new/keystone/bin/keystone-manage db_sync\n2013-07-16 06:05:57 + [[ PKI == \\P\\K\\I ]]\n2013-07-16 06:05:57 + rm -rf /etc/keystone/ssl\n2013-07-16 06:05:57 + /opt/stack/new/keystone/bin/keystone-manage pki_setup\n2013-07-16 06:05:57 Generating RSA private key, 2048 bit long modulus\n2013-07-16 06:05:57 .....................................................+++\n2013-07-16 06:05:57 .......................+++\n2013-07-16 06:05:57 e is 65537 (0x10001)\n2013-07-16 06:05:57 Generating RSA private key, 2048 bit long modulus\n2013-07-16 06:05:57 ..................+++\n2013-07-16 06:05:57 ......+++\n2013-07-16 06:05:57 e is 65537 (0x10001)\n2013-07-16 06:05:57 Using configuration from /etc/keystone/ssl/certs/openssl.conf\n2013-07-16 06:05:57 Check that the request matches the signature\n2013-07-16 06:05:57 Signature ok\n2013-07-16 06:05:57 The Subject\'s Distinguished Name is as follows\n2013-07-16 06:05:57 countryName           :PRINTABLE:\'US\'\n2013-07-16 06:05:57 stateOrProvinceName   :PRINTABLE:\'Unset\'\n2013-07-16 06:05:57 localityName          :PRINTABLE:\'Unset\'\n2013-07-16 06:05:57 organizationName      :PRINTABLE:\'Unset\'\n2013-07-16 06:05:57 commonName            :PRINTABLE:\'www.example.com\'\n2013-07-16 06:05:57 Certificate is to be certified until Jul 14 06:05:57 2023 GMT (3650 days)\n2013-07-16 06:05:57 \n2013-07-16 06:05:57 Write out database with 1 new entries\n2013-07-16 06:05:57 Data Base Updated\n2013-07-16 06:05:57 + sudo mkdir -p /var/cache/keystone\n2013-07-16 06:05:57 + sudo chown stack /var/cache/keystone\n2013-07-16 06:05:57 + rm -f \'/var/cache/keystone/*\'\n2013-07-16 06:06:57 + start_keystone\n2013-07-16 06:06:57 + local service_port=5000\n2013-07-16 06:06:57 + is_service_enabled tls-proxy\n2013-07-16 06:06:57 + services=tls-proxy\n2013-07-16 06:06:57 + for service in \'${services}\'\n2013-07-16 06:06:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,tls-proxy, ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\n\\e\\u\\t\\r\\o\\n ]]\n2013-07-16 06:06:57 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-07-16 06:06:57 + [[ tls-proxy == s-* ]]\n2013-07-16 06:06:57 + return 1\n2013-07-16 06:06:57 + screen_it key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + SCREEN_NAME=stack\n2013-07-16 06:06:57 + SERVICE_DIR=/opt/stack/new/status\n2013-07-16 06:06:57 ++ trueorfalse True False\n2013-07-16 06:06:57 ++ local default=True\n2013-07-16 06:06:57 ++ local testval=False\n2013-07-16 06:06:57 ++ [[ -z False ]]\n2013-07-16 06:06:57 ++ [[ 0 no false False FALSE =~ False ]]\n2013-07-16 06:06:57 ++ echo False\n2013-07-16 06:06:57 ++ return\n2013-07-16 06:06:57 + USE_SCREEN=False\n2013-07-16 06:06:57 + is_service_enabled key\n2013-07-16 06:06:57 + services=key\n2013-07-16 06:06:57 + for service in \'${services}\'\n2013-07-16 06:06:57 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,key, ]]\n2013-07-16 06:06:57 + return 0\n2013-07-16 06:06:57 + screen_rc key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + SCREEN_NAME=stack\n2013-07-16 06:06:57 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-07-16 06:06:57 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-07-16 06:06:57 + grep key /opt/stack/new/devstack/stack-screenrc\n2013-07-16 06:06:57 ++ echo -ne \'\\015\'\n2013-07-16 06:06:57 + NL=$\'\\r\'\n2013-07-16 06:06:57 + echo \'screen -t key bash\'\n2013-07-16 06:06:57 + echo \'stuff \"cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\n\"\'\n2013-07-16 06:06:57 + [[ False = \\T\\r\\u\\e ]]\n2013-07-16 06:06:57 + run_process key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + local service=key\n2013-07-16 06:06:57 + local \'command=cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + echo 11334\n2013-07-16 06:06:57 + _run_process key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + echo \'Waiting for keystone to start...\'\n2013-07-16 06:06:57 Waiting for keystone to start...\n2013-07-16 06:06:57 + timeout 60 sh -c \'while ! http_proxy= curl -s http://127.0.0.1:5000/v2.0/ >/dev/null; do sleep 1; done\'\n2013-07-16 06:06:57 + local service=key\n2013-07-16 06:06:57 + local \'command=cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-07-16 06:06:57 + exec\n2013-07-16 06:06:57 + exec\n2013-07-16 06:06:57 + die 311 \'keystone did not start\'\n2013-07-16 06:06:57 + local exitcode=0\n2013-07-16 06:06:57 + set +o xtrace\n2013-07-16 06:06:57 [ERROR] ./stack.sh:311 keystone did not start\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/rabbitmq/rabbit at devstack-1373939478-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/rabbitmq/rabbit at devstack-1373939478.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/8/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1365162194.2354.137.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-05 12:43:14',3600,'2013-04-05 11:43:14',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Fri, 2013-04-05 at 11:03 +0200, Thierry Carrez wrote:\n> Michael Still wrote:\n> > On Fri, Apr 5, 2013 at 2:47 AM, Stefano Maffulli <stefano at openstack.org> wrote:\n> >> On 04/04/2013 08:24 AM, Mark McLoughlin wrote:\n> > \n> > [snip]\n> > \n> >>> Frankly, though, I\'m losing faith in this \"number of commits\" statistic\n> >>> being all that useful. Most of my commits were probably trivial cfg\n> >>> cleanups in Nova.\n> >>\n> >> Not one single number has meanings by itself but only acquires a meaning\n> >> inside a story. If you look at count of commits together with the number of\n> >> bugs closed over time, so you can see trends, for example, you may have an\n> >> idea of how much effort goes into stabilization vs new features. Looking at\n> >> commits and lines of code added/removed can also help understand where the\n> >> development effort is going. Or at least the numbers will seem to tell\n> >> something and force you to want to dive deeper.\n> > \n> > Yes. I am increasingly worried about employers managing to these\n> > numbers as well. I feel that the numbers that get discussed in the\n> > community are the ones employees are likely to optimise for.\n> > \n> > I\'d like to see a more general discussion about what contributions we\n> > value as a community, and how we encourage those contributions.\n> \n> Yeah, I\'m having the same concern, and the official \"activity board\" is\n> only making it more pressing:\n> \n> On one hand, it\'s extremely difficult to get those stats right. Tracking\n> where everyone works is painful (the Bitergia report, for example, still\n> counts me under \"Rackspace\"). The metrics themselves can be a bit\n> unfair: we already mentioned the issue with \"number of commits\"... but\n> others fail as well (like \"bug activity\": stable branch management will\n> result in opening a lot of bugs for process tracking, which will be an\n> order of magnitude bigger than the number of bugs opened due to QA\n> research).\n> \n> On the other hand, more and more people/companies want to be able to\n> brag about their OpenStack contribution, or want to not appear too bad\n> on those lists. That leads to the incentive to game the system, once\n> some stats are made \"official\".\n> \n> Until now, the stats posted were mostly one-shot and ad-hoc, to serve as\n> a reputational pressure encouraging people to contribute more,\n> especially in strategic areas. But if they become official and stable\n> metrics, they will be gamed, defeating their original purpose.\n> \n> Bruce Schneier puts it in better words than I do in \"Liars and Outliers\":\n> \n> \"When you start measuring something and then judge people based on that\n> measurement, you encourage people to game the measurement instead of\n> doing whatever it is you wanted in the first place.\"\n\nAgree with everything you say. I don\'t think I\'ve seen obvious examples\nof people trying to game the stats but, with the emphasis we\'re putting\non these stats, it\'s only natural that people will start gaming them.\n\nCheers,\nMark.\n\n\n\n','<515E9360.9000109@openstack.org>',NULL),('<1365168119.2354.157.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-05 14:21:59',3600,'2013-04-05 13:21:59',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Fri, 2013-04-05 at 09:04 -0400, Sean Dague wrote:\n> On 04/05/2013 07:43 AM, Mark McLoughlin wrote:\n> > On Fri, 2013-04-05 at 11:03 +0200, Thierry Carrez wrote:\n> <snip>\n> >> Bruce Schneier puts it in better words than I do in \"Liars and Outliers\":\n> >>\n> >> \"When you start measuring something and then judge people based on that\n> >> measurement, you encourage people to game the measurement instead of\n> >> doing whatever it is you wanted in the first place.\"\n> >\n> > Agree with everything you say. I don\'t think I\'ve seen obvious examples\n> > of people trying to game the stats but, with the emphasis we\'re putting\n> > on these stats, it\'s only natural that people will start gaming them.\n> \n> I think we\'ve been reasonably lucky so far, so if there are any folks \n> gaming it, they are drowned out by the vast amount of legitimate work \n> being done.\n> \n> In an era of readily available data, it\'s kind of hard to prevent people \n> from making graphs out of it. And with a project that gets so much \n> press, it\'s hard to keep people from making ridiculous press releases.\n> \n> Mark, I\'m more comfortable when someone like yourself is maintaining the \n> code base that everyone seems to be using to generate stats, because I \n> know he\'s not going to game this output. If you are stepping away from \n> the repo, it might be worth putting it into openstack-dev and gerrit, so \n> at least people can push reviews to deal with org changes.\n\nI\'m fine with that, it\'s really that I don\'t have enough interest to\ndeal with pull requests like this:\n\nhttps://github.com/markmc/openstack-gitdm/pull/12\n\nBut then again, the Foundation membership database is probably a more\nreliable source of affiliation information at this point that my\ntrolling LinkedIn :)\n\n> I don\'t know that putting the cat back in the bag is going to happen no \n> matter what we do.\n\nWe were keeping it somewhat under control by only publish stats at\nrelease time. I\'m really quite concerned about publishing ongoing stats.\nMaybe people will just get bored of them eventually, though.\n\nCheers,\nMark.\n\n\n\n','<515ECBEF.20209@dague.net>',NULL),('<1365168994.2354.162.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-05 14:36:34',3600,'2013-04-05 13:36:34',NULL,'[Openstack-stable-maint] Preparing for 2012.2.4','On Fri, 2013-04-05 at 14:13 +0200, Alan Pevec wrote:\n> Hi,\n> \n> looks like we\'re good to go except for Cinder:\n> https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:stable/folsom,n,z\n> \n> Mark, what about cutting 2012.2.4 RC now but leaving Cinder under\n> soft-freeze, i.e. get those last-minute backports reviewed properly?\n\nSounds good to me\n\n> Some of them I had a look at seem to be squashed from multiple master\n> comments which should be backported separately IMHO, keeping\n> Change-Ids as per stable guidelines\n> https://wiki.openstack.org/wiki/StableBranch\n\nI\'m working through them, but yeah - they\'re outstanding examples of\ngood backports :)\n\nCheers,\nMark.\n\n\n\n','<CAGi==UUoRdND8ASpBdMa3MYLqyXUxR=6m3Jpu4R1Ap9CdUENgw@mail.gmail.com>',NULL),('<1365175593.2354.174.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-05 16:26:33',3600,'2013-04-05 15:26:33',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Fri, 2013-04-05 at 09:24 -0600, John Griffith wrote:\n> \n> \n> On Thu, Apr 4, 2013 at 9:24 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         Hey!\n>         \n>         On Thu, 2013-04-04 at 11:01 -0400, Monty Taylor wrote:\n>         > I know everyone loves looking at numbers around this time.\n>         I\'m sure\n>         > there will be several new reports on which people or\n>         companies did the\n>         > most. I wanted to poke at a slightly different thing - which\n>         is overall\n>         > combined community effort.\n>         >\n>         >                       Essex   Folsom  Grizzly\n>         > Patches Uploaded      11036   17986   29308\n>         > Changes Created               5137    5990    12721\n>         > Changes Landed                4235    4978    10561\n>         > Avg patches per Change        2.6     3.6     2.7\n>         > Landing Percentage    82%     83%     83%\n>         >\n>         > Clearly our velocity continues to increase, which is great.\n>         Something\n>         > happened during folsom to cause us to need to on-average\n>         iterate more to\n>         > get a change landed, but then we corrected the ship during\n>         grizzly. I\'m\n>         > more fascinated by the fact that our percentage of changes\n>         created to\n>         > changes landed is holding extremely steady.\n>         >\n>         > Great work at managing the firehose everybody!\n>         \n>         \n>         Indeed, those are amazing stats! Nice one Monty.\n>         \n>         I sent out gitdm based \"Who wrote Essex/Folsom\" stats in\n>         previous\n>         releases:\n>         \n>           https://lists.launchpad.net/openstack/msg09650.html\n>           https://lists.launchpad.net/openstack/msg17006.html\n>         \n>         and I\'ve done them again for Grizzly:\n>         \n>         \n>         https://github.com/markmc/openstack-gitdm/blob/results/grizzly/git-stats.txt\n>         \n>         Frankly, though, I\'m losing faith in this \"number of commits\"\n>         statistic\n>         being all that useful. Most of my commits were probably\n>         trivial cfg\n>         cleanups in Nova.\n>         \n>         Also, bitergia\'s stats are getting more and more\n>         comprehensive:\n>         \n>         \n>         http://blog.bitergia.com/2013/04/04/companies-contributing-to-openstack-grizzly-analysis/\n>         \n>         So ... consider openstack-gitdm orphaned and open to a new\n>         maintainer :-)\n>         \n>         Cheers,\n>         Mark.\n>         \n>         \n> FWIW there seems to be a bug in your algorithm, keying off of only a\n> single Author name.  A number of us have aliases, modifying your query\n> to use email seems to yield different results.  \n\nThere\'s an openstack-config/aliases file for this\n\nCheers,\nMark.\n\n\n\n\n','<CA+qL3LXziC+1V_znRLBWzSwzgGRSQus5ABc1kdBTb_ineZfvqA@mail.gmail.com>',NULL),('<1365178396-sup-9543@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-05 09:29:38',-25200,'2013-04-05 16:29:38',NULL,'[openstack-dev] Rackspace Plans Contributions to HEAT','Excerpts from Alan Kavanagh\'s message of 2013-04-05 04:56:07 -0700:\n> I want the \"flexibility\" to choose how I do auto-scaling without having to say it must be done through HEAT. I want the flexibility to have auto-scaling as a service done on top of Openstack not through HEAT API Calling Openstack API\'s. If you can explain the technical merit and benefit of such a case we can take it from their, as right now all I see is adding another layer on top of another layer etc.......and the benefit to me as an openstack consumer and user is ?\n\nHeat is just an engine for orchestration. If you take \"Heat\" out of\nwhat you said (it really isn\'t an acronym and should not be in all caps)\nand replace it with \"an orchestration service\", your sentence is a lot\neasier to understand. However, clarity of what you mean also makes it\nless clear *why* you want this.\n\n\"I want the \'flexibility\' to choose how I do auto-scaling without having\nto say it must be done through an orchestration service. I want the\nflexibility to have auto-scaling as a service done on top of Openstack\nnot through an orchestration service API calling OpenStack API\'s.\"\n\nAn orchestration service seems a quite appropriate place to be doing\nauto-scaling. Unlike every other component of OpenStack, an orchestration\nservice is meant to manage all of the OpenStack APIs and keep the\ncomponents informed of each other. Quantum\'s LBaaS will only know\nabout load balancers. Its coupling to Nova is at the bare minimum, just\nenough to get the load balancer to talk to the right servers. However,\nan orchestration service also knows about volumes. So when you auto-scale\nand need a new volume.. are you going to teach Quantum how to define a\nvolume and attach it to the instances?\n\nNo, I understand you\'re suggesting auto-scaling should be\nseparate. However, if you have a stand-alone auto-scaler that is not\nHeat, now you have two things which are designed to understand how load\nbalancers, instances, and volumes connect.\n\n> \n> If we are not progressing then I suggest we take this at the Summit, I am more than happy to discuss this in finer details.\n> \n\nSide Note:\nIt might help if you start quoting messages rather than top posting. Just\nan idea. Putting a response next to the thing you are responding to\ntends to help the reader know your intended context. I understand that\nsome email clients don\'t allow this, but it is really the only way to\nkeep mailing list conversations from turning into context-free shouting\nmatches. Anyway, just a suggestion.\n\n--\nClint Byrum\nHP Cloud Services\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E09401E@eusaamb109.ericsson.se>',NULL),('<1365199529.15724.391.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-06 00:05:29',7200,'2013-04-05 22:05:29',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin... [maybe\n now off-topic]','What an interesting thread. Let me just make a couple of comments.\n\n[Sorry for the long post: just skip if not interested in project\nanalytics]\n\n- Yes, any measure about company activity and contribution can be\ncheated. But sets of measures are more difficult to cheat (or at least,\nat some point cheating a good enough set of metrics may require too much\neffort to pay the trouble). That\'s why we\'re trying to provide more\nmetrics in the analysis. Probably commits is the most \"classical\" one,\nbut others are also relevant.\n\n- In any case, we\'re not trying to imply that such company is behind\nsuch other just because they are having 20 more or less commits. The\nidea is that if a company is high in most or all the metrics, it is very\nlikely that they are important contributors. If company A is like one\nthird of company B in most or all metrics, it is likely that company A\nis contributing significantly less than company B. So that in the end,\nwe can enrich discussions with data.\n\n- Company participation is just one of the many kinds of quantitative\nanalysis that can be done. To be honest, until seeing the level of\ninterest they raise, I never thought they were too important. But now I\nguess I understand the reason: having some numbers, even if only\napproximate, is much better than having no numbers at all. It is clear\nthat a company may try to cheat the analytics, but if there are no\nnumbers it is even easier: everything becomes a matter of opinion [but\nof course, this is just my very personal impression].\n\n- We\'ve done this company analysis on our own, because we felt it was\ninteresting, and we had the tools and the data. Of course we had the\nsupport of some members of the OpenStack community, including the people\nthat do the git-dm analysis, because we used in part their affiliation\ndata (thanks!). One of the nice things (in my opinion) of free / open\nsource software developed in the open is this transparency, or maybe\naccountability, where anyone can come, look at the data, and extract\ntheir conclusions. In addition, our tools are free software, our\nmethodology is public (if you need any detail just ask), the datasets\nare public (thanks to OpenStack, which makes everything available). Any\ncritic is welcome: it will only help to improve the results for the next\ntime.\n\n- We\'re working with the OpenStack Foundation in other kinds of\nanalysis. We will be talking about them at Portland. Those have more to\ndo with how the project is performing as a whole, which metrics could be\nidentified that could help to track performance, bottlenecks, areas that\nneed work, or general evolution of the project. I hope that maybe those\nanalytics are more appealing to those of you who don\'t find the company\nanalysis helpful for the project.\n\nIn any case, as said, we will be in Portland, and will be more than\nhappy to discuss all these issues with any of you who may be interested,\neither in the session for this, or at any other time. If there is\ninterest and logistics allow for it, we could even have some kind of BoF\non \"measuring OpenStack\".\n\n[BTW, probably it is obvious from the above, but I\'m one of the guys\nbehind Bitergia\'s report]\n\nSaludos,\n\n	Jesus.\n\nOn Fri, 2013-04-05 at 14:12 -0700, Matt Joyce wrote:\n> Made a quick attempt to guess gender of devs to see a gender bias in\n> development.\n> \n> https://github.com/openfly/openstack-rnd/tree/master/openstack-gender\n> \n> Came up with  \n> \n> females : 25\n> males : 262\n> unknowncount : 240\n> \n> the gender import came from \n> \n> https://github.com/Bemmu/gender-from-name\n> \n> which uses US Census Data ( obviously going to have a bias there\n> probably why I have 240 unknowns...  )\n> If someone knows of a better dataset to test against I\'d love to hear\n> it.\n> \n> Alternativelly.... git push your name and gender to the gender.py   =D\n> \n> -Matt\n> \n> On Fri, Apr 5, 2013 at 12:18 PM, Daniel Izquierdo\n> <dizquierdo at bitergia.com> wrote:\n>         Hi Eric,\n>         \n>         \n>         On 04/05/2013 08:31 PM, Eric Windisch wrote:\n>                 \n>                 \n>                 On Friday, April 5, 2013 at 14:17 PM, Stefano Maffulli\n>                 wrote:\n>                 \n>                         Let me pull in the authors of the study, as\n>                         they may be able to shed\n>                         some light on the inconsistencies you found.\n>                         \n>                         Eric, Joshua: can you please send Daniel and\n>                         Jesus more details so they\n>                         can look into them?\n>                 \n>                 I made a note on the blog. The response to others\n>                 indicates that their results are based on two\n>                 different methodologies (git-dm and their own dataset\n>                 analysis), this would likely be the source of\n>                 differences in numbers.  I haven\'t noticed variations\n>                 anywhere except author counts, but I haven\'t looked\n>                 very hard, either.\n>         \n>         \n>         The methodology we have used to match developers and\n>         affiliations is based on information partially obtained from\n>         the OpenStack gitdm project, but also compared to our own\n>         dataset (that we already had from previous releases). Sorry if\n>         I didn\'t explain myself consistently in the blog.\n>         \n>         The bug here is related to how we\'re calculating data for the\n>         spreadsheets and company by company. The result is that the\n>         company by company analysis had a bug, and we were counting\n>         some more developers than expected and commits (we were\n>         counting for instance as two different people a developer who\n>         used at some point two different email addresses).\n>         \n>         So, the data at the tables (bottom part in the main page) is\n>         the correct one. The data for the source code management\n>         system in the left part of each of the companies is\n>         overestimated.\n>         \n>         In addition, the number of commits in Rackspace will be a bit\n>         higher for the next round. Another developer told us that he\n>         moved from one company to Rackspace at some point, so you will\n>         see how that number will increased a bit.\n>         \n>         \n>                 \n>                 I guess it could also be differences or errors in\n>                 employee->company mappings? Perhaps instead, one\n>                 methodology includes those that report bugs, while the\n>                 other only accounts for git? I\'m not sure.\n>         \n>         \n>         Regarding to this point, the data about bug tracking system\n>         and mailing lists is only based on activity from developers.\n>         This means that people that have not committed a change to the\n>         source code are not counted as part of the activity of\n>         companies in Launchpad and Mailing Lists. In any case and as\n>         an example, we\'re covering around a 60% of the activity in the\n>         mailing lists because people that at some point submitted\n>         changes to the Git are that active.\n>         \n>         Our purpose with this is to show only activity from developers\n>         and their affiliations through the three data sources (git,\n>         tickets and mailing lists). This is also an option. From our\n>         point of view this analysis was pretty interesting, but\n>         perhaps for others this is not good enough.\n>         \n>         \n>                 \n>                 Other things like dividing commits/authors seems to\n>                 just be the wrong methodology where a median would be\n>                 more appropriate and harder to game.\n>                 \n>         \n>         \n>         This is a good point. As you mention it is probably more fair\n>         to have such metric. At some point we would like to show some\n>         boxplots and other metrics to better understand the\n>         distribution of the datasets, but we had to choose some. In\n>         any case, we will take into account this for the next reports\n>         for sure. Thanks!\n>         \n>         Probably a good approach would be to have a common view with\n>         all of the people interested in this type of analysis. In this\n>         way we could reach an agreement about how to visualize data,\n>         necessary and interesting metrics, common methodology to\n>         measure stuff and projects involved. This analysis is just a\n>         possibility, but there are some more for sure.\n>         \n>         In any case, please, let us know any other concerns you may\n>         have and any feedback of the community is more than\n>         appreciated.\n>         \n>         Thanks a lot for all your comments.\n>         \n>         \n>         Regards,\n>         Daniel Izquierdo.\n>         \n>                 Regards,\n>                 Eric Windisch\n>                 \n>         \n>         \n> \n> \n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<CAGYSk8e4d9upi91rdjbw80WAq=XLsXFk2r8QvM7q6=jYLgUD9A@mail.gmail.com>',NULL),('<1365263938524.14a83a4c@Nodemailer>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-04-06 08:58:59',-25200,'2013-04-06 15:58:59',NULL,'[Openstack-operators] CentOS Image','Out of curiosity, why did you decide to create AMI/ARI/AKI format images instead of qcow2? Curious because I thought that was a legacy thing that nobody did anymore.?\n?\nSent from Mailbox for iPhone\n\nOn Fri, Apr 5, 2013 at 11:32 AM, Jacob Godin <jacobgodin at gmail.com> wrote:\n\n> Hi all,\n> I have created a CentOS image using the AMI + AKI + ARI method (same as I\n> used to create my Ubuntu images). I am able to successfully upload and\n> launch the image at first. When trying to launch the third+ instances, they\n> simply get stuck in a bootloop after the \'Booting from ROM...\'.\n> Even if I delete the original two images, I am unable to boot. The only way\n> to get a CentOS image to successfully boot is to re-upload the image.\n> Any ideas? I\'m using Folsom w/ Ceph RBD storage for images, and CephFS for\n> instances.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130406/fa0802cc/attachment.html>\n\n','<CA+WiSK4acRowTaTRJx-GbGt8U=uFdru5CnDT5ojkMmXvsGCXdw@mail.gmail.com>',NULL),('<1365338948.432.1367129186713.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:06:26',0,'2013-04-28 06:06:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-docs-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/18/>\n\n\n\n','<1787561443.357.1367042603813.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1365384247.12181165.1379003306398.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-12 12:28:26',-14400,'2013-09-12 16:28:26',NULL,'[Openstack-docs] Need to retrieve old files? No worries','----- Original Message -----\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Wednesday, September 11, 2013 11:23:25 PM\n> Subject: [Openstack-docs] Need to retrieve old files? No worries\n> \n> I just like to say no worries so I sound Aussie. :)\n> \n> I\'m working on ensuring that some Identity configuration info is correctly\n> placed, so I wanted a copy of the repository before the rename. Here\'s how\n> you do that in case you ever need to get an \"archived\" copy of the repo.\n> \n> 1. Switch into a temporary directory.\n> 2. Clone the openstack-manuals repository.\n> $ git clone http://github.com/openstack/openstack-manuals.git\n> Cloning into \'openstack-manuals\'...\n> remote: Counting objects: 30034, done.\n> remote: Compressing objects: 100% (9438/9438), done.\n> remote: Total 30034 (delta 17276), reused 26918 (delta 14505)\n> Receiving objects: 100% (30034/30034), 55.18 MiB | 990 KiB/s, done.\n> Resolving deltas: 100% (17276/17276), done.\n> 3. Go to review.openstack.org and look for the patch that occured just\n> before the rename patch. (It\'s https://review.openstack.org/#/c/45491/).\n\nIs it possible to add a tag to that specific commit (my git-fu doesn\'t really expand to tagging so genuinely asking)?\n\nThanks,\n\nSteve\n\n\n','<CAD0KtVHcdVjPNE-dzjdVheueiFgXr2LnQwZxwW8tbRVXo2NoiQ@mail.gmail.com>',NULL),('<1365400949.2524.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-08 07:02:29',3600,'2013-04-08 06:02:29',NULL,'[Openstack-stable-maint] Proposed stable/grizzly release dates','On Mon, 2013-04-08 at 01:06 +0200, Alan Pevec wrote:\n> 2013/4/6 Daviey Walker <dave.walker at canonical.com>:\n> > It\'s looking like there is a steady stream of post release fixes coming\n> > through for Grizzly now.  Therefore, I think we should consider a sooner\n> \n> How soon you had in mind? Would it work to insert 2013.1.1 on May 9th\n> and then release every 2 months: .2 Jun 6 .3 Aug 8 .4 Oct 10 ?\n\nA .1 relatively soon after the release sounds like a good idea, assuming\nsomeone (e.g. Alan :) has the time to pull it together.\n\n> > release for the first one.  But then, I still maintain that point releases\n> > isn\'t something that I think is useful.\n> \n> That sounds like there was a prior discussion which I missed, so I\'m\n> not sure if I understand right, but taking this to the extreme, we\n> wouldn\'t need major releases either and just deploy from trunk.\n\nYeah, for me, releases from the stable branch are like errata for the\nmain releases ... I hate to think of the project having e.g.\n2012.2.tar.gz sitting on its site with major known issues and telling\npeople \"oh, ignore the tarball releases and just use the stable branch\".\n\n> Was it the idea to maintain stable branch only as a repository of\n> useful backports?\n> IMHO best part of releases is a deadline, which usually motivates\n> people to get work done.\n\nThere\'s going to be a design summit session on stable branch\nprocesses ... that\'s a good time for us to revisit what we\'re doing and\ndiscuss in detail.\n\nCheers,\nMark.\n\n\n\n','<CAGi==UUX81b3YWDO0thKnRsFN4FJFetDrQ+hPWinU6qOvOh1AQ@mail.gmail.com>',NULL),('<1365439902.3281.4.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 11:51:42',-18000,'2013-04-08 16:51:42',NULL,'[openstack-dev] Strict validation and Compatibility (Re: [Nova]\n Blueprint: nova-api-validation-fw)','On Sun, 2013-04-07 at 15:24 +0900, Ken\'ichi Ohmichi wrote:\n> IMO it is a good opportunity to adjust api validation, so I feel\n> strict\n> validation is better. But this is not a strong opinion due to\n> compatibility.\n> \n> \n> Any comments are welcome.\n\nI believe strongly in the motto, \"Be conservative in what you send, but\nbe liberal in what you accept.\"  That seems to be the most effective way\nof constructing interoperable protocols, so?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAA393vg=bxPXBdB1YCUo1FsHEYkAdYf==s4-dP-HDVWcETttWw@mail.gmail.com>',NULL),('<1365440455.3281.7.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 12:00:55',-18000,'2013-04-08 17:00:55',NULL,'[openstack-dev] Failing CI tests on python-novaclient','There seems to be a brokenness in the jobs that run the unit tests on\npython-novaclient.  At least one patch which does nothing more than\nmodify a docstring is failing on all unittests, and several reviews all\nshow similar errors, along with a lack of testr_results.html?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1365453911.3281.9.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 15:45:11',-18000,'2013-04-08 20:45:11',NULL,'[openstack-dev] Failing CI tests on python-novaclient','On Tue, 2013-04-09 at 08:36 +1200, Robert Collins wrote:\n> Indeed, and sorry about that. The cause was a new release of subunit,\n> which added the new version 2 wire protocol. I had tested the whole\n> ecosystem for compatibility forward and backwards, and the specific\n> case of \'new subunit old testrepository\' was known to break *unless* a\n> subunit-2to1 filter was put in the pipeline; when I discussed that\n> with the -infra folk they didn\'t think we\'d have any issues, because\n> the new testrepository would be brought down with everything else due\n> to the PyPI mirror : sadly that global install mentioned in the review\n> wasn\'t pulling from the PyPI mirror, and so it sucked down a new\n> subunit on it\'s own.\n\nThat explains it.  However, I have to say that the problem still\npersists?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAJ3HoZ2G4Xbb60Qk1vmvn8RjRYhwoYgsH=WrbonX9OB704noaw@mail.gmail.com>',NULL),('<1365457397.3281.12.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 16:43:17',-18000,'2013-04-08 21:43:17',NULL,'[openstack-dev] Failing CI tests on python-novaclient','On Mon, 2013-04-08 at 13:51 -0700, Clark Boylan wrote:\n> Assuming the failures for\n> http://logs.openstack.org/26310/2/check/gate-python-novaclient-python27/1404/\n> are the same failures you are seeing I don\'t think this is related to\n> the testrepository and python-subunit changes. That looks like a real\n> test failure to me and the html report is being generated. \n\nA closer look reveals a mixture of things going on.  There is a test\nfailure indeed, that somehow made its way into trunk; I\'ve uploaded\nhttps://review.openstack.org/#/c/26405/ to address that.  However, as to\nthe html report being generated, look instead at\nhttp://logs.openstack.org/26310/2/check/gate-python-novaclient-python26/1185/ where the html report is not present; there\'s still something going on.\n\n> Also,\n> looking at the output from pip freeze we seem to still be using the\n> old version of python-subunit and testrepository (our pypi mirror has\n> not pulled in the new goodness yet).\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAAcH74gcfcJiw_Rq6dXYvB-sMg=fsKoDGtwNt89YysJ1CU01DA@mail.gmail.com>',NULL),('<1365460823.3281.16.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 17:40:23',-18000,'2013-04-08 22:40:23',NULL,'[openstack-dev] Nova core review request: Urgent novaclient bug-fix\n patch needing approval','So, today bug 1166464[1] was discovered in novaclient, which is\npreventing *all* test runs from completing successfully, including test\nruns on a patch which only changes a docstring.  I have a patch up to\ncorrect the issue:\n\n        https://review.openstack.org/#/c/26405/\n\nPlease review and approve ASAP so we can get the novaclient tests\npassing again?\n\n[1] https://bugs.launchpad.net/python-novaclient/+bug/1166464\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1365470522-sup-8642@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-08 18:22:16',-25200,'2013-04-09 01:22:16',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','Excerpts from Robert Collins\'s message of 2013-04-08 12:43:11 -0700:\n> On 6 April 2013 01:37, Chuck Thier <cthier at gmail.com> wrote:\n> > I\'be seen very obvious examples of stats like this being gamed.  As an\n> > example, overly trivial patches that add no value, shortly followed by\n> > company press releases with how many developers are contributing to the\n> > project.  I would also be careful with what stats we as a community put\n> > emphasis on.  For example, I cringe every time someone lauds the number of\n> > lines of code, as it is such a poor metric.\n> \n> Perhaps we can laud lines of code deleted?\n> \n\n+1\n\nor.. should that be -1?\n\n\n','<CAJ3HoZ27tq6V_e6Ux+=tjdoRYh3taQ7bJU8JHGztBy4-Sph2Cw@mail.gmail.com>',NULL),('<1365499691.2524.80.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-09 10:28:11',3600,'2013-04-09 09:28:11',NULL,'[openstack-tc] TC Meeting tomorrow Tue Apr 9, 20:00 UTC','Hey\n\nOn Mon, 2013-04-08 at 20:38 +0200, Thierry Carrez wrote:\n> Hi everyone,\n> \n> Tomorrow at 20:00 UTC we\'ll have a TC meeting on #openstack-meeting with\n> the following agenda:\n> \n> * Discussion: Policy on use of GPL libraries [1]\n> \n> [1]\n> http://lists.openstack.org/pipermail/openstack-dev/2013-March/006772.html\n\nRichard and VanL are (unofficial) members of the Legal Affairs Committee\nand have been discussing some ideas for a general licensing policy and\nprocess for the project. I invited them to join us for the meeting.\n\nCheers,\nMark.\n\n\n\n','<51630E95.8030405@openstack.org>',NULL),('<1365520309.3281.17.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-09 10:11:49',-18000,'2013-04-09 15:11:49',NULL,'[openstack-dev] Strict validation and Compatibility (Re: [Nova]\n Blueprint: nova-api-validation-fw)','On Tue, 2013-04-09 at 17:55 +0900, Ken\'ichi Ohmichi wrote:\n> Good motto, thanks.\n\nYou\'re welcome ;)\n\n> I will apply the motto to the framework, and let\'s talk together about\n> it at the summit. \n\nI\'m afraid I\'m not able to attend the summit this time around, sorry?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<20130409175519.50852d63.oomichi@mxs.nes.nec.co.jp>',NULL),('<1365574901-sup-6591@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-09 23:24:33',-25200,'2013-04-10 06:24:33',NULL,'[openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???','As we near the next OpenStack Summit, it has become clear that the way\nforward for Heat users is.. well, not very clear.\n\nHeat currently only supports one way to define applications. That is the\nhybrid Heat-specific plus CloudFormation-compatible templating language.\n\nWe also have a proposal to add TOSCA support to Heat:\n\nhttps://blueprints.launchpad.net/heat/+spec/tosca-support\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-April/007252.html\n\nAdrian from RackSpace has stated that they are working on an \"Open API &\nDSL\" and a \"Declarative Model\":\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-April/007126.html\n\nI\'ve also heard OASIS/CAMP thrown around as something that might be\nimplemented in Heat.\n\nI count no less than 4 possible ways for users to express application\ndeployments. Succinctly:\n\n* CloudFormation-ish\n* Open DSL w/ Declarative model(undefined yet)\n* TOSCA\n* CAMP\n\nhttp://xkcd.com/927/\n\nI am concerned about the fragmentation that users may be presented\nwith if we do not take a step back and talk about the ramifications\nof supporting all of them. Its great to be as broad and accepting as\npossible when it makes sense, but not at the expense of user confusion\nand/or incompatibility.\n\nSo, I am calling on those interested in the various formats to at least\nraise your hands and let us, the heat users and developers, know what\nyou expect from Heat as a project, and what makes any of these standards\nworth implementing. I think this is worth having a break-out session at\nthe summit next week to discuss, and would also encourage everyone to\nstart (or continue) the discussion right here on the mailing list.\n\n\nClint Byrum\nHP Cloud Services\n\n\n',NULL,NULL),('<1365584372.2299.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-10 09:59:32',3600,'2013-04-10 08:59:32',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Tue, 2013-04-09 at 18:42 -0700, Vishvananda Ishaya wrote:\n> On Apr 9, 2013, at 3:02 PM, Daniel Izquierdo <dizquierdo at bitergia.com> wrote:\n> \n> > Hi Vish,\n> > \n> > On 04/09/2013 05:47 PM, Vishvananda Ishaya wrote:\n> >> Any insight into how the number of closed tickets were generated? I just checked my stats for grizzly and noticed that I fixed 38 bugs in nova alone[1]. Counting all projects (it is a little harder to find results for the python-*clients since we don\'t have coordinated releases) it is somewhere around 45, yet our company only has 34 listed for the entire release. There is clearly some error in the tickect closing statistics.\n> > \n> > We already had a small discussion with other OpenStack members about how to measure activity. What we\'re measuring when talking about tickets are those whose final stage is \"Fix Committed\".\n> > \n> > At the beginning, we considered other stages as \"final\" ones such as \"Fix Released\" or \"Won\'t Fix\", however Thierry appeared to have an incredible high number of \"closed\" tickets for that definition. So, what you can see (as specified in [1]) is the number of closed bugs with the condition of being in the \"Fix Committed\" stage (only that).\n> \n> The act of \"closing\" as in changing the state of the bug is relatively meaningless. Jenkins sets fix committed is most cases and the release manager or jenkins sets fix released. It makes a lot more sense to use the assignee of the bug. That is the person that did the actual work.\n\nAgree, and that\'s what my stats show:\n\nhttps://github.com/markmc/openstack-gitdm/blob/results/grizzly/lp-stats.txt\n\nHowever, the large number of fixes by \"Unknown hacker\" show that e.g.\nthe assignee field wasn\'t always set or I didn\'t have a mapping of the\nassignee\'s LP account to an email address.\n\nCheers,\nMark.\n\n\n\n','<B353F09E-711C-4B8E-A613-0EE6521315CE@gmail.com>',NULL),('<1365674225.2628.36.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-11 10:57:05',3600,'2013-04-11 09:57:05',NULL,'[openstack-dev] guidance re: cfg module usage -- failure to\n recognize options in nova.conf','Hi,\n\nOn Wed, 2013-04-10 at 16:49 -0700, Eric Hankins wrote:\n> All,\n> \n> Apologies for what is hopefully a simple issue...been staring at it for far\n> too long and I\'m not sure what I\'m missing.\n> \n> I\'ve been fixing up the nova-dns module I found on github to manage inserts\n> of new instance DNS info into PowerDNS.\n> \n> It configures its kombu BrokerConnection with the following params block:\n> \n>         self.params = dict(hostname=FLAGS.rabbit_host,\n>                           port=FLAGS.rabbit_port,\n>                           userid=FLAGS.rabbit_userid,\n>                           password=FLAGS.rabbit_password,\n>                           virtual_host=FLAGS.rabbit_virtual_host)\n> \n> When I go to fire it up, it\'s claiming that rabbit_host isn\'t defined:\n> \n> Traceback (most recent call last):\n>   File \"/usr/bin/nova-dns\", line 55, in <module>\n>     service.serve(dns.Service(), amqp.Service())\n>   File \"/usr/lib/pymodules/python2.7/nova_dns/amqp.py\", line 50, in __init__\n>     self.params = dict(hostname=FLAGS.rabbit_host,\n>   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/cfg.py\",\n> line 1039, in __getattr__\n>     return self._get(name)\n>   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/cfg.py\",\n> line 1361, in _get\n>     value = self._substitute(self._do_get(name, group))\n>   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/cfg.py\",\n> line 1377, in _do_get\n>     info = self._get_opt_info(name, group)\n>   File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/cfg.py\",\n> line 1470, in _get_opt_info\n>     raise NoSuchOptError(opt_name, group)\n> nova.openstack.common.cfg.NoSuchOptError: no such option: rabbit_host\n> \n> However, it clearly is, under my [DEFAULT] block in nova.conf:\n> \n> # grep rabbit_host /etc/nova/nova.conf\n> rabbit_host=localhost\n\nThere needs to be a register_opt() call somewhere which registers the\n\'rabbit_host\' option\n\ne.g. in impl_kombu:\n\n    cfg.StrOpt(\'rabbit_host\',\n               default=\'localhost\',\n               help=\'The RabbitMQ broker address where a single node is used\'),\n\n\ncfg.CONF.register_opts(kombu_opts)\n\nMaybe you just need to import the rpc module? Hmm, you actually probably\nneed to call e.g. rpc.create_connection() so that impl_kombu gets\nimported\n\nCheers,\nMark.\n\n\n\n','<CAOyyTDt9k1eor2Gr19zWJKid4Hik6ERPdG=v=67edYuYhErC6g@mail.gmail.com>',NULL),('<1365680198.33513286@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-11 07:36:38',-14400,'2013-04-11 11:36:38',NULL,'[openstack-dev] [Openstack][Glance] difference api version\n	between v1 and v2','Gareth,\n\nThere are a number of improvisations in v2 of Glance API. To name a few the registry layer is no longer been used in v2 of Glance API(so one less layer your request has to go through), image sharing has been designed to prevent spamming in v2, there are additional features like protected properties and multiple locations been worked on. I am sure there are several more.\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"Gareth\" <academicgareth at gmail.com>\nSent: Thursday, April 11, 2013 12:51am\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Openstack][Glance] difference api version between v1 and v2\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi, Glance devs\n\nAny design purpose between v1 and v2 API?\n\nI know the url changed a little, but functionality seems same.\n\nSo is there any further improvement in v2 API?\n\nThanks\n-- \nGareth\n\n*Cloud Computing, Openstack, Fitness, Basketball\n*\n*OpenStack contributor*\n*My promise: if you find any spelling or grammar mistakes in my email from\nMar 1 2013, notify me *\n*and I\'ll donate $1 or ?1 to an open organization you specify.*\n\n\n\n\n','<CAAhuP_9LuTPnKsx=96WrA2dtp9aaQ3pLiLuNTERu4F17DyaUDg@mail.gmail.com>',NULL),('<1365696797-sup-368@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-11 09:49:53',-25200,'2013-04-11 16:49:53',NULL,'[openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???','Excerpts from Zane Bitter\'s message of 2013-04-11 04:38:07 -0700:\n> On 11/04/13 02:18, Tripp, Travis S wrote:\n> >\n> > Zane Bitter wrote:\n> >> FWIW it appears to me that CAMP is targeted at the PaaS level,\n> >> and while I\'m supportive of that effort it doesn\'t seem to me to\n> >> be in scope for Heat, which I see as limited to the IaaS layer.\n> >> I\'m willing to be re-educated though ;)\n> >\n> > Perhaps Heat was intended to be at the IaaS level today (?), but there are already platform and application examples in the test templates today (e.g. wordpress). I know from experience that infrastructure has complexity and that things become even more complex when we start considering how applications use the infrastructure.\n> \n> The reason for the choice of the Wordpress application in the examples \n> is that you can try it and see a very concrete demonstration that it \n> works. And for some people (not large enterprise IT departments, one \n> suspects) deploying applications that way will be enough. For most large \n> applications, I would imagine something like the Puppet slave template \n> would be more representative, but it doesn\'t make for a great demo ;)\n\nRight, Heat\'s examples are showing whole deliverable templates that\ndeploy a thing. That is useful for showing all of the things Heat can do,\nbut it violates the principle of separation of concerns.\n\n> >\n> >  From my perspective, there are a few fundamental categories of management to consider in the orchestration of applications and infrastructure.\n> >\n> > + Physical Resource Management  (Machine, Network, Storage, Load Balancing, etc.)\n> > + Configuration Management (Setup users, install software, configure software, deploy code)\n> > + Performance Management (Availability, Scalability, Placement)\n> > + Security Management (Data, Connectivity, Placement)\n> >\n> > To accomplish all of the above, we have a point of view that cloud orchestration at the enterprise-level cannot be solved with a single engine or tool and that different enterprises will want to leverage their existing investments in their tools. This is why Chef may be used for configuration management (and even infrastructure resource management), but it doesn\'t make sense to use Chef for monitoring or making policy decisions about when and where to instantiate resources.\n> \n> +1 totally agree.\n\nHow your app uses the data heat provides to it should remain as a\nperipheral concern of Heat. Chef, heat-cfntools, or whatever, can all\nbe brought in to accomplish things inside an instance. There\'s a nice\nsnippet in the heat-cfntools README that explains this:\n\n\"\"\"\nThere are several bootstrap methods for cloudformations:\n1. Create image with application ready to go\n2. Use cloud-init to run a startup script passed as userdata to the nova\n   server create\n3. Use the CloudFormation instance helper scripts\n\n   This package contains files required for choice #3.\n\"\"\"\n\nBecause there are many ways to do this, heat-cfntools remains a separate\ncode tree and an optional thing.\n\n> >\n> > If I were to categorize Heat *today* from an external perspective, I might call it an API orchestrator expressed in a mixed declarative / imperative template script language which provides a way to create, update, and delete multiple resources in a coordinated fashion by calling their APIs through resource plugins (including core resources).  The engine doesn\'t care about what the resource is, it doesn\'t care about why it is being called, all it knows is that it has been asked to orchestrate a physical resource stack based on an input template.\n> \n> That seems basically accurate, although I\'m not sure I would describe it \n> as mixed declarative/imperative. I assume you\'re referring there to the \n> UserData section of a Nova instance (which is basically just a script)?\n> \n> Essentially Heat is designed as a declarative interface to the OpenStack \n> APIs. Deploying an interdependent collection of resources - and \n> especially making changes to that collection - by hand or with a custom \n> script can be complex and error-prone, and every user has to do it every \n> time they want to make a change. There\'s a big advantage in having a \n> description of the old state and the state you want to get to and \n> letting an orchestration engine figure how to get there. Even better if \n> you can keep that description in version control and easily do diffs to \n> see what changed and when.\n> \n\nThis is a side tangent, but you actually need to also store the parameters\nand diff those too, or you run the risk of making unintended changes. I\'ve\nbeen working out in my head how to write some CLI helpers for automating\nthings so that developers can encode \"this is what I expect to change\nwhen we update the stack\" and automation systems can stop the presses\nif there are unintended changes.\n\n> What we have _not_ tried to do is anything that is not part of the \n> OpenStack API, except for some temporary resource types for things that \n> should be in OpenStack but weren\'t at the time - e.g. LBaaS, DBaaS). So \n> the UserData is passed straight through because it\'s passed straight \n> through in the Nova API as well. It\'s worth noting that the UserData is \n> extremely constrained in size - in general the point is not to put all \n> of your application in there, it\'s to put just enough bootstrap to tell \n> the instance to e.g. grab a Chef recipe and go from there, so that you \n> don\'t have to build it into a custom image.\n> \n\nRight, if you build an image with heat-cfntools installed that runs\ncfn-init and cfn-hup, you don\'t need UserData at all and can just pass\nin declarative Metadata to get things done.\n\nWe\'re taking that a step further with os-config-applier in the tripleo\nproject by just passing in declarative values which the image knows how\nto interpert into config file changes. This way the template only encodes\norchestration, and not config file or software management of any kind.\n\nhttps://github.com/openstack-ops/templates/blob/master/mysql.yaml\n\nNote the hint to OpenStack::ImageBuilder::Elements, which is just a hint\nthat this template wants an image built with the mysql-migration element.\nThis is an alternative way to use Heat without cfn-init, and without\nhaving to specify file paths or service names or anything in the template,\nthose things all remain in the image as part of the software.\n\n> >\n> > If I am correct in my categorization of Heat (open for comments!), what this implies is that Heat provides a tightly scoped service for physical resource API orchestration. It doesn\'t attempt to intermingle knowledge of the resources with the engine, which would distract from its core capability. I like that in theory, it can treat an infrastructure resource (VM) the same as a configuration resource (Chef cookbook) - a set of inputs that will be passed to a plugin at the appropriate time based upon dependency graphing and let the plugin handle it. It doesn\'t even care if a resource plugin recursively invokes other Heat resources. It is this intended ignorance of what it is doing that makes it work as an API orchestrator.\n> \n> I would agree with that assessment.\n> >\n> > All of which leads me back to the core questions surfacing that I am very interested in:\n> >   + Does Heat support alternate ways to express the resource orchestration?\n> >   + Does Heat play a greater role in orchestration other than as pre-scripted resource orchestration?\n> >\n> > And the implied questions are:\n> > + Should Heat support a logical way to model stack layers independently and without physical resource binding?\n> > + Does this start breaking down into sub services like Nova did (some of which have now been separated)?\n> >\n> > I believe that as software projects go from small to large, that the modeling and scripting needs change and often become more complex.  Some people will care about cloud portability and some won\'t. People in different roles will desire fine grained control and others will not. In other words, there is a need for both logical / declarative modeling as well as physical / imperative modeling and they are complementary. I also believe that there can be course grained declarative modeling as well as fine grained declarative modeling.\n> >\n> > So, ultimately, the question for Heat is how much, how far, and how soon is it going to go in all of these areas?\n> \n> These are good questions. I don\'t really have direct answers, but here \n> is my 2c:\n> \n> I agree that long-term we need to have a better story on configuring \n> what runs inside Nova instances. But I\'m also wary of scope creep. \n> During the incubation discussions around Heat, there were a lot of folks \n> expressing concern about blessing one particular orchestration engine as \n> an official OpenStack project and, while I disagree with that view when \n> it comes to orchestrating OpenStack APIs, I think it\'s a very good point \n> when it comes to dealing with non-OpenStack tools.\n> \n\nAs I stated above, this line needs to be clear. Things inside the\ninstances are not at all \"Heat\". We should provide minimalistic tools,\nbut if those tools get too deep, we will actually make it harder to\nadopt Heat.\n\n> There are multiple, Open Source PaaS solutions that can run on top of \n> OpenStack (e.g. OpenShift Origin, CloudFoundry). I think where OpenStack \n> in general, and Heat in particular, can add the most value is to be the \n> best IaaS base on which to layer the PaaS. (BTW the hosted version of \n> OpenShift currently uses CloudFormation templates.)\n> \n\nI think there is far too much attention given to \"is this PaaS or IaaS\".\n\nApplications need a platform that gives them access to the infrastructure.\nWe can see that in the industry where pure PaaS solutions are not nearly\nas popular as those that give you the ability to get out to the OS when\nyou need to.\n\nHeat should orchestrate OpenStack APIs in its core. If TOSCA apps can\'t\nget their jobs done with just the OpenStack APIs, then the pieces they\nneed should be on the same level as the heat-cfntools.\n\n> That\'s obviously not the only use case though. I would be in favour of \n> supporting some ways to generate the UserData for an instance in some \n> simpler manner than a shell script. One idea that has been kicked around \n> is Juju integration, and I think that would be a really interesting one \n\nZane you kind of just blew my mind a little. Being intimiately familiar\nwith how Juju works, I\'m not sure this makes any sense at all.\n\nAny attempt to make juju charms work on heat is basically reimplementing\nthe entire juju charm CLI API (relation-{get,set,list}, unit-get,\nconfig-get) to work using Heat\'s API tools. Juju doesn\'t just install\nthings. It sets up juju\'s own agents to do what Heat already does (spin\nup instances, communicate changes between them).\n\n> to look at. Another would be some sort of (pluggable) layer to add \n> native ways of configuring the likes of Puppet and Chef. (Those two \n> ideas are not mutually exclusive, either.)\n> \n\nPuppet and Chef can do this without changing anything in Heat. Just teach\nthem how to read the Metadata. IIRC, chef already has an ohai plugin to\ndo just that. Then just have something like:\n\n    Metadata:\n      Puppet:\n        master-host: xxxxxx\n        roles: [x, y, z]\n\n\n','<5166A09F.6030300@redhat.com>',NULL),('<1365699026-sup-8280@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-11 09:55:39',-25200,'2013-04-11 16:55:39',NULL,'[openstack-dev] [Heat] TOSCA, CAMP, CloudFormation, ???','Excerpts from Doug Davis\'s message of 2013-04-10 05:27:54 -0700:\n> \n> +1\n> \n> I believe that the core of Heat should, for the most part, remain pretty\n> agnostic\n> to the format of the deployment descriptions.\n> \n> There will be a bit of pain for users of Heat for a while until the dust\n> settles and\n> the community gravitates towards the preferred format.  But I\'d prefer to\n> let the users\n> and the community decide the winner instead of just us doing it right now.\n> \n\nRight, I am most concerned with deciding on our principles, not on\ntrying to crown a king.  If a user shows up with an entirely new way to\ndrive Heat, but it does not compromise Heat, I think we should be quite\nenthusiastic about accepting it into Heat.\n\nThere is a side concern, which is that Heat\'s documentation will need to\nfocus on one standard for the sake of user education and for gathering\nsteam around the format we think will benefit the broadest base of users.\nThis isn\'t to the exclusion of others, but without that kind of focus,\nusers will get frustrated.\n\nMaybe TOSCA is a great way to bring large scale applications and\nenterprise users into Heat, but that may be too heavy and narrow focus\nfor Heat to push as \"the way to learn Heat\".\n\n\nClint Byrum\nHP Cloud Services\n\n\n','<OFDC9331C5.0E767EAB-ON85257B49.0042D918-85257B49.004478FA@us.ibm.com>',NULL),('<136587404.16834722.1385375345663.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-25 10:29:05',0,'2013-11-25 10:29:05',NULL,'[Openstack] Introducing Warm, a tool to setup environment from Yaml','Hello all,\n\nIt\'s my first message on the ML so maybe I have to introduce myself. My name is \nSahid Ferdjaoui, I\'m working at Cloudwatt and I\'m really happy to be part of \nthis great community.\n\nI wanted share with you a tool to setup environments from templates. It exposes \nAPIs on Yaml and I hope it could be useful for some of us.\n\n      The sources code is on GitHub: https://github.com/sahid/warm\n\nThe code is not completely mature and you can find inconsistencies, feel free to \ngive me any feedbacks.\n\nAs examples I have pushed templates; One to setup a multi-nodes OpenStack using \ndevstack, could be useful for developers and an other to setup a WordPress with \ndedicated webserver, database and proxy.\n\n     The template on GitHub: https://github.com/sahid/warm-templates\n    \nFirst of all we need to install Warm. We can do that with the command pip. \n(It needs some deps so don\'t forget to check the README before to launch the \ninstall. https://github.com/sahid/warm/blob/master/README)\n$> sudo pip install warm\n\nYou can check if Warm is correctly installed \n$> warm -v\n0.1.25\n\nWe will try to setup a WordPress:\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n$> git clone https://github.com/sahid/warm-templates\n$> cd warm-templates/wordpress\n\nWarm can read OS_* env, if not defined it checks in the template to get credentials.\nPlease read config.yaml.sample for more information:\n  https://github.com/sahid/warm/blob/master/templates/config.yaml.sample\n\nIs good to read stack.yaml and userdata/* to maybe update these files for \nyour OpenStack. It\'s in Yaml and Bash/CloudInit so really easy to understand.\n\nNow we can deploy our environment...\n$> warm stack.yaml\n\n    Note: Warm doesn\'t recreate resources already exists and mixes names/ids.\n\nWe can use \'nova console-log\' to verify if all run well.\n$> nova console-log {proxy, mysql, web}\n\nIf all sounds good we have to add a public ip, yes Warm is not able yet\nto configure floating ip.\n$> nova add-floating-ip proxy <addr>\n\nNow just go to the <addr> to play with WordPress.\n\n\nPlease feel free to send me any comments, bugs or requests. I will be happy to work \non these. \n\nPS: Warm is not really documented but the code is simple, if you want to find \nwhat is currently supported just go to components/__init__.py, \'whitelist\' is a \ngood variable to look at to find supported options for a component.\n\nThanks for your time,\ns.\n\n\n','<1179476907.14235862.1385052843761.JavaMail.root@cloudwatt.com>',NULL),('<1365922126.9250.357.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-13 23:48:46',-25200,'2013-04-14 06:48:46',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Tue, 2013-04-09 at 18:42 -0700, Vishvananda Ishaya wrote:\n> On Apr 9, 2013, at 3:02 PM, Daniel Izquierdo <dizquierdo at bitergia.com> wrote:\n> \n> > Hi Vish,\n> > \n> > On 04/09/2013 05:47 PM, Vishvananda Ishaya wrote:\n> >> Any insight into how the number of closed tickets were generated? I\n> just checked my stats for grizzly and noticed that I fixed 38 bugs in\n> nova alone[1]. Counting all projects (it is a little harder to find\n> results for the python-*clients since we don\'t have coordinated\n> releases) it is somewhere around 45, yet our company only has 34\n> listed for the entire release. There is clearly some error in the\n> tickect closing statistics.\n> > \n> > We already had a small discussion with other OpenStack members about\n> how to measure activity. What we\'re measuring when talking about\n> tickets are those whose final stage is \"Fix Committed\".\n> > \n> > At the beginning, we considered other stages as \"final\" ones such as\n> \"Fix Released\" or \"Won\'t Fix\", however Thierry appeared to have an\n> incredible high number of \"closed\" tickets for that definition. So,\n> what you can see (as specified in [1]) is the number of closed bugs\n> with the condition of being in the \"Fix Committed\" stage (only that).\n> \n> The act of \"closing\" as in changing the state of the bug is relatively\n> meaningless. Jenkins sets fix committed is most cases and the release\n> manager or jenkins sets fix released. It makes a lot more sense to use\n> the assignee of the bug. That is the person that did the actual work.\n\nThanks a lot for this insight. We\'ve been playing a bit with our\ndatabase, and these are the results [long message].\n\nWe have focused on tickets reaching the state of \"Fixed Committed\", as\nMark McLoughlin and Michael Still sugeested.\n\nFirst of all, there is the issue of which tickets to consider. We have\nconsidered tickets being closed during the Grizzly release cycle, and\nfor all OpenStack trackers (complete list of what we\'re considering as\n\"all trackers\" is in http://bugs.launchpad.net/openstack. As you will\nsee, numbers below are different from those commented by Mark, I wonder\nif this is because either the list of trackers or the date condition is\ndifferent for his study.\n\nAnyway, we\'ve found 2,806 tickets transitioning to \"Fix committed\" at\nleast once during the periodm with a total of 3,784 transitions of that\nkind.\n\nOf those, we have tracked the asignee at the time of the transitioning,\nfinding 387 different identities, which according to our records\ncorrespond to 329 different persons. Of those, we have identified\ncompanies for 228, which amount for 2,084\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<B353F09E-711C-4B8E-A613-0EE6521315CE@gmail.com>',NULL),('<1365925048.9250.394.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-14 00:37:28',-25200,'2013-04-14 07:37:28',NULL,'[openstack-dev] Grizzly\'s out - let the numbers begin...','On Sat, 2013-04-13 at 23:48 -0700, Jesus M. Gonzalez-Barahona wrote:\n> On Tue, 2013-04-09 at 18:42 -0700, Vishvananda Ishaya wrote:\n> > On Apr 9, 2013, at 3:02 PM, Daniel Izquierdo <dizquierdo at bitergia.com> wrote:\n> > \n> > > Hi Vish,\n> > > \n> > > On 04/09/2013 05:47 PM, Vishvananda Ishaya wrote:\n> > >> Any insight into how the number of closed tickets were generated? I\n> > just checked my stats for grizzly and noticed that I fixed 38 bugs in\n> > nova alone[1]. Counting all projects (it is a little harder to find\n> > results for the python-*clients since we don\'t have coordinated\n> > releases) it is somewhere around 45, yet our company only has 34\n> > listed for the entire release. There is clearly some error in the\n> > tickect closing statistics.\n> > > \n> > > We already had a small discussion with other OpenStack members about\n> > how to measure activity. What we\'re measuring when talking about\n> > tickets are those whose final stage is \"Fix Committed\".\n> > > \n> > > At the beginning, we considered other stages as \"final\" ones such as\n> > \"Fix Released\" or \"Won\'t Fix\", however Thierry appeared to have an\n> > incredible high number of \"closed\" tickets for that definition. So,\n> > what you can see (as specified in [1]) is the number of closed bugs\n> > with the condition of being in the \"Fix Committed\" stage (only that).\n> > \n> > The act of \"closing\" as in changing the state of the bug is relatively\n> > meaningless. Jenkins sets fix committed is most cases and the release\n> > manager or jenkins sets fix released. It makes a lot more sense to use\n> > the assignee of the bug. That is the person that did the actual work.\n> \n> Thanks a lot for this insight. We\'ve been playing a bit with our\n> database, and these are the results [long message].\n> \n> We have focused on tickets reaching the state of \"Fixed Committed\", as\n> Mark McLoughlin and Michael Still sugeested.\n> \n> First of all, there is the issue of which tickets to consider. We have\n> considered tickets being closed during the Grizzly release cycle, and\n> for all OpenStack trackers (complete list of what we\'re considering as\n> \"all trackers\" is in http://bugs.launchpad.net/openstack. As you will\n> see, numbers below are different from those commented by Mark, I wonder\n> if this is because either the list of trackers or the date condition is\n> different for his study.\n> \n> Anyway, we\'ve found 2,806 tickets transitioning to \"Fix committed\" at\n> least once during the periodm with a total of 3,784 transitions of that\n> kind.\n> \n> Of those, we have tracked the asignee at the time of the transitioning,\n> finding 387 different identities, which according to our records\n> correspond to 329 different persons. Of those, we have identified\n> companies for 228, which amount for 2,084\n\n[Oooops. I was preparing the message when I noticed we had more recent\ndata. But the message went away anway still unfinished, sorry about\nthat. Numbers below (and a question for those of you interested in all\nthis)]\n\n1. Number of (unique) tickets changed to Fix Committed during the \nrelease: 2802\n\n- 1.a 2090 of them have been done by people associated to a company,\naccording to our records (remember, we can have more than a transition\nper ticket)\n\n- 1.b The person who \"closes\" the issue and the assignee is different in\nmost cases: 2683 (as you said in your previous messages)\n\n\n2. How many assignee-when-fixed-commit do we have?\n\n- assignees 388, where unique assignees (once identities are merged into\npersons): 330\n\n\n3. How many unique assignee-when-fixed-commit are associated to a\ncompany?\n\n- 229 ( 229 out of 330 unique_assignees)\n\n\n4. Number of transitions to fix-committed: 3776\n\n4.A. Number of transitions to fix-committed where the assignee is \nassociated to a company: 2806 (2806 out of 3776)\n\n4.B. By company\n\nname;total\n\"Red Hat\";758\nRackspace;261\nIBM;239\nNebula;214\nHP;192\nVMware;139\nCanonical;131\nIntel;131\nMicrosoft;84\neNovance;72\nNTT;64\nDreamHost;54\nSolidFire;49\n\n4.C. By people - company\n\nname,user_id,name,total\n\"Gary Kotton\",garyk,\"Red Hat\",160\n\"Mark McLoughlin\",markmc,\"Red Hat\",144\n\"Vish Ishaya\",vishvananda,Nebula,128\n\"Zhongyue Luo\",zyluo,Intel,90\n\"Alessandro Pilotti\",alexpilotti,Microsoft,84\n\"Aaron Rosen\",arosen,VMware,83\n\"Dan Prince\",dan-prince,\"Red Hat\",73\n\"Chuck Short\",zulcss,Canonical,68\n\"Steven Hardy\",shardy,\"Red Hat\",62\n\"Russell Bryant\",russellb,\"Red Hat\",58\n\"Dolph Mathews\",dolph,Rackspace,56\n\"Julien Danjou\",jdanjou,eNovance,50\n\nFor those of you interested, I can share the SQL queries we\'re using,\nand the last version of the database (which we have still not uploaded\nto the website).\n\nIn addition, we\'re tracking time-to-close for tickets, and there the\ndifference between committed and released matters, because times are\ndifferent. When do you think a ticket should be considered as closed? At\n\"Fix committed\" or at \"Fix released\" time?\n\nRight now, the condition for considering a ticket as closed is:\n\nnew_value = \'Fix Released\' or new_value = \'Invalid\' or new_value =\n\'Expired\' or new_value = \'Won\\\'t Fix\'\n\nDo you find this ok? Any other state?\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<1365922126.9250.357.camel@parato.mi.casa>',NULL),('<1365950151.2628.106.camel@sorcha>','http://lists.openstack.org/pipermail/transparency',NULL,'2013-04-14 07:35:51',-25200,'2013-04-14 14:35:51',NULL,'[Transparency] Last minute updates','Hey\n\nJust adding a reference to:\n\n  https://bugs.launchpad.net/openstack-ci/+bug/1160466\n\nfor opening up the board mailing list\n\nCheers,\nMark.\n\nOn Sat, 2013-04-13 at 13:53 -0700, Joshua McKenty wrote:\n> Folks, I\'m pulling together a status update for tomorrow\'s BoD. If anything\n> got done (thanks especially to Eileen and Lauren for pulling together notes\n> on policy), can you update the etherpad doc at\n> https://etherpad.openstack.org/TransparencyWG-Feb21-Agenda? Or just send me\n> a quick email.\n> \n> Again, thanks!\n> \n> Joshua\n> \n> \n> On Thu, Feb 21, 2013 at 6:39 PM, Tristan Goode <tristan at aptira.com> wrote:\n> \n> > No worries, thanks!****\n> >\n> > ** **\n> >\n> > *From:* Joshua McKenty [mailto:joshua at pistoncloud.com]\n> > *Sent:* Friday, 22 February 2013 1:35 PM\n> > *To:* Tristan Goode\n> > *Cc:* transparency at lists.openstack.org\n> > *Subject:* Re: [Transparency] Apologies..****\n> >\n> > ** **\n> >\n> > We assigned a few things to you - well, I volunteered you in your absence.\n> > The notes are fairly well captured in\n> > https://etherpad.openstack.org/TransparencyWG-Feb21-Agenda - your main\n> > task is to work with Rob Hirschfeld and myself to identify options for\n> > ombudsman or external review organizations.****\n> >\n> > ** **\n> >\n> > ** **\n> >\n> > ** **\n> >\n> > On Thu, Feb 21, 2013 at 6:32 PM, Tristan Goode <tristan at aptira.com> wrote:\n> > ****\n> >\n> > ..for missing this folks. I have been known to miss the occasional 4am\n> > meeting! :)****\n> >\n> >  ****\n> >\n> > I?m pretty sure my views are known though, I?m looking forward to hearing\n> > how it went.****\n> >\n> >  ****\n> >\n> > Cheers****\n> >\n> > Tristan****\n> >\n> >  ****\n> >\n> >\n> > _______________________________________________\n> > Transparency mailing list\n> > Transparency at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/transparency****\n> >\n> >\n> >\n> > ****\n> >\n> > ** **\n> >\n> > --\n> > --\n> > Joshua McKenty, CEO\n> > Piston Cloud Computing, Inc.\n> > w: (650) 24-CLOUD\n> > m: (650) 283-6846\n> > http://www.pistoncloud.com\n> >\n> > \"Oh, Westley, we\'ll never survive!\"\n> > \"Nonsense. You\'re only saying that because no one ever has.\" ****\n> >\n> > _______________________________________________\n> > Transparency mailing list\n> > Transparency at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/transparency\n> >\n> >\n> \n> \n> _______________________________________________\n> Transparency mailing list\n> Transparency at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/transparency\n\n\n\n\n','<CALOyBR04wnK-N1gwKQQYK=jiD32pVGan9m1cX2CP_SsLp8zchw@mail.gmail.com>',NULL),('<1366047648330.b9edb2ce@Nodemailer>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-04-15 10:40:50',-25200,'2013-04-15 17:40:50',NULL,'[openstack-hpc] [Openstack] [HPC] Anyone interested in an\n HPC-themed unconference?','I\'d love to join in. We\'re looking at OpenStack as a way to build a shared RC infrastructure at Harvard at a level below the scheduler, and would love to hear what others are\n\nOn Mon, Apr 15, 2013 at 10:32 AM, John Paul Walters <jwalters at isi.edu>\nwrote:\n\n> Hi,\n> We missed the deadline for an HPC related design summit session, but there\'s still time to sign up for an unconference if anyone\'s interested.  Anyone interested?  I\'d propose one of the Wednesday slots.\n> best,\n> JP\n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20130415/8e32d29b/attachment.html>\n\n','<089349C0-F956-450C-910B-DB71B9FE2FDE@isi.edu>',NULL),('<1366178876.1669.YahooMailRC@web181703.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-16 23:07:56',-25200,'2013-04-17 06:07:56',NULL,'[openstack-dev] VMs can\'t access outside world..','A few people has email me said they have the same issue and if I have this \nresolve.  Unfortunately, the issue still exists and I gave up and move on to \ncloudstack.  everything looks great with openstack but if the VM guest can\'t \naccess outside world, I can\'t really move forward.\n\nI saw some people has installed OpenStack on CentOS but they didn\'t seem to have \nissue.  I am hoping people can share about their installation and configuation.\n\nBarrow\n\n\n\n----- Original Message ----\nFrom: Barrow Kwan <barrowkwan at yahoo.com>\nTo: openstack-dev at lists.openstack.org\nSent: Thu, February 28, 2013 10:26:19 PM\nSubject: [openstack-dev] VMs can\'t access outside world..\n\nHi,\nI posted this on the General Discussions but didn\'t get any answer. I also \nfound someone post similar issue back on Dec but didn\'t get an answer neither \nSo I hope someone from the Dev side can help.\n\nI installed Folsom on CentOS6.3.  It has 2 NIC ( the server has 4 but I only use \n\ntwo and disable the other two ).  I used Quantum + LinuxBridge.  VM provisioning \n\nis fine and it got an ip address.  I assigned floatingIP and create security ( \nallow icmp and ssh ).  I can SSH to the VM from outside through the floatingIP. \nHowever, when I am inside the VM, I can\'t access anything outside of the VM or \nmy openstack infrastructure.  Here is the information I can provide\n\n\n\nOS - CentOS6.3 ( single node - everything are running there , eg cinder, nova, \ncompute, glance.... )\nOpenstack Folsom\nQuantum - LinuxBridge\nSingle node with two NIC ( em1 and em 3.  They are on different VLAN on the \nphysical switch ).\n\n\n\n/etc/sysctl.conf\nnet.ipv4.ip_forward = 1\nnet.ipv4.conf.default.rp_filter = 0\nnet.ipv4.conf.default.accept_source_route = 0\nkernel.sysrq = 0\nkernel.core_uses_pid = 1\nnet.ipv4.tcp_syncookies = 1\nnet.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1\nnet.bridge.bridge-nf-call-arptables = 1\nkernel.msgmnb = 65536\nkernel.msgmax = 65536\nkernel.shmmax = 68719476736\nkernel.shmall = 4294967296\n\n\n\n\n\n/etc/sysconfig/modules/openstack-quantum-linuxbridge.modules\n#!/bin/sh\nmodprobe -b bridge >/dev/null 2>&1\nexit 0\n\n\n\n\n/etc/sysconfig/network-scripts/ifcfg-em1\nDEVICE=\"em1\"\nBOOTPROTO=\"static\"\nDNS1=\"10.99.99.1\"\nGATEWAY=\"10.38.0.254\"\nIPADDR=\"10.38.15.251\"\nIPV6INIT=\"no\"\nMTU=\"1500\"\nNETMASK=\"255.255.0.0\"\nNM_CONTROLLED=\"yes\"\nONBOOT=\"yes\"\nTYPE=\"Ethernet\"\n\n\n\n\n/etc/sysconfig/network-scripts/ifcfg-em3\nDEVICE=\"em3\"\nBOOTPROTO=\"none\"\nNM_CONTROLLED=\"yes\"\nONBOOT=\"yes\"\nTYPE=\"Ethernet\"\n\n\n\n\n/etc/nova/nova.conf\n[DEFAULT]\nlogdir = /var/log/nova\nstate_path = /var/lib/nova\nlock_path = /var/lib/nova/tmp\nvolumes_dir = /etc/nova/volumes\ndhcpbridge = /usr/bin/nova-dhcpbridge\ndhcpbridge_flagfile = /etc/nova/nova.conf\nforce_dhcp_release = True\ninjected_network_template = /usr/share/nova/interfaces.template\nlibvirt_nonblocking = True\nlibvirt_inject_partition = -1\nnetwork_manager = nova.network.manager.FlatDHCPManager\niscsi_helper = tgtadm\nsql_connection = mysql://nova:nova at localhost/nova\ncompute_driver = libvirt.LibvirtDriver\nfirewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver\nrpc_backend = nova.openstack.common.rpc.impl_qpid\nrootwrap_config = /etc/nova/rootwrap.conf\nflat_interface = em3\npublic_interface = em1\nauth_strategy = keystone\nqpid_hostname =opst01\nglance_api_servers = optst01:9292\nglance_host = opst01\nvolume_api_class = nova.volume.cinder.API\nenabled_apis = ec2,osapi_compute,metadata\nnetwork_api_class = nova.network.quantumv2.api.API\nquantum_admin_username = quantum\nquantum_admin_password = quantum\n#quantum_admin_auth_url = http://localhost:5000/v2.0/\nquantum_admin_auth_url = http://localhost:35357/v2.0/\nquantum_auth_strategy = keystone\nquantum_admin_tenant_name = service\nquantum_url = http://opst01:9696/\nlibvirt_vif_driver = nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriver\n[keystone_authtoken]\nadmin_token = 111111111111111\n\n\n\n\n\n/etc/quantum/l3_agent.ini\n[DEFAULT]\ndebug = True\ninterface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver\nadmin_token = 111111111111111\nroot_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf\nexternal_network_bridge = \nuse_namespaces = False\nrouter_id = 1a8fd530-56d2-4192-b3fe-1f77651cbf41\n\n\n\n\n\n/etc/quantum/plugin.ini\n[VLANS]\ntenant_network_type = vlan\nnetwork_vlan_ranges = physnet1,physnet2:100:199\n[DATABASE]\nsql_connection = mysql://quantum:quantum at optst01/quantum_linux_bridge\nreconnect_interval = 2\n[LINUX_BRIDGE]\nphysical_interface = em1,em3\nphysical_interface_mappings = physnet1:em1,physnet2:em3\n[AGENT]\npolling_interval = 2\nroot_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf\n\n\n\n\n\n[root at opst01 quantum]# route -n\nKernel IP routing table\nDestination     Gateway         Genmask         Flags Metric Ref    Use Iface\n192.168.151.0   0.0.0.0         255.255.255.0   U     0      0        0 \nns-b21309cd-11\n192.168.151.0   0.0.0.0         255.255.255.0   U     0      0        0 \nqr-ec728fdd-44\n10.38.17.0      0.0.0.0         255.255.255.0   U     0      0        0 \nqg-28179e3d-dc\n10.38.0.0       0.0.0.0         255.255.0.0     U     0      0        0 \nbrq6b600334-9f\n169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 em3\n0.0.0.0         10.38.0.254     0.0.0.0         UG    100    0        0 \nbrq6b600334-9f\n\n\n\n\n\n[root at optst01 quantum]# service iptables status\nTable: nat\nChain PREROUTING (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-compute-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0          \n2    quantum-l3-agent-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0      \n    \n3    nova-api-PREROUTING  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain POSTROUTING (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-compute-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0        \n  \n2    quantum-l3-agent-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0      \n    \n3    quantum-postrouting-bottom  all  --  0.0.0.0/0            0.0.0.0/0        \n  \n4    nova-api-POSTROUTING  all  --  0.0.0.0/0            0.0.0.0/0          \n5    nova-postrouting-bottom  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain OUTPUT (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-compute-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n2    quantum-l3-agent-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n3    nova-api-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain nova-api-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-POSTROUTING (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-PREROUTING (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-float-snat (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-snat (1 references)\nnum  target     prot opt source               destination        \n1    nova-api-float-snat  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain nova-compute-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-POSTROUTING (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-PREROUTING (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-float-snat (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-snat (1 references)\nnum  target     prot opt source               destination        \n1    nova-compute-float-snat  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain nova-postrouting-bottom (1 references)\nnum  target     prot opt source               destination        \n1    nova-compute-snat  all  --  0.0.0.0/0            0.0.0.0/0          \n2    nova-api-snat  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain quantum-l3-agent-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-POSTROUTING (1 references)\nnum  target     prot opt source               destination        \n1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           ! ctstate \nDNAT \n\nChain quantum-l3-agent-PREROUTING (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-float-snat (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-snat (1 references)\nnum  target     prot opt source               destination        \n1    quantum-l3-agent-float-snat  all  --  0.0.0.0/0            0.0.0.0/0      \n    \n2    SNAT       all  --  192.168.151.0/24     0.0.0.0/0           to:10.38.17.1 \n\nChain quantum-postrouting-bottom (1 references)\nnum  target     prot opt source               destination        \n1    quantum-l3-agent-snat  all  --  0.0.0.0/0            0.0.0.0/0          \n\nTable: filter\nChain INPUT (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-compute-INPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n2    quantum-l3-agent-INPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n3    nova-api-INPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain FORWARD (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-filter-top  all  --  0.0.0.0/0            0.0.0.0/0          \n2    nova-compute-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0          \n3    quantum-filter-top  all  --  0.0.0.0/0            0.0.0.0/0          \n4    quantum-l3-agent-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0        \n  \n5    nova-api-FORWARD  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain OUTPUT (policy ACCEPT)\nnum  target     prot opt source               destination        \n1    nova-filter-top  all  --  0.0.0.0/0            0.0.0.0/0          \n2    nova-compute-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n3    quantum-filter-top  all  --  0.0.0.0/0            0.0.0.0/0          \n4    quantum-l3-agent-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n5    nova-api-OUTPUT  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain nova-api-FORWARD (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-INPUT (1 references)\nnum  target     prot opt source               destination        \n1    ACCEPT     tcp  --  0.0.0.0/0            10.38.15.251        tcp dpt:8775 \n\nChain nova-api-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-api-local (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-FORWARD (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-INPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-inst-20 (1 references)\nnum  target     prot opt source               destination        \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID \n2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state \nRELATED,ESTABLISHED \n3    nova-compute-provider  all  --  0.0.0.0/0            0.0.0.0/0          \n4    ACCEPT     udp  --  192.168.151.2        0.0.0.0/0           udp spt:67 \ndpt:68 \n5    ACCEPT     all  --  192.168.151.0/24     0.0.0.0/0          \n6    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          \n7    ACCEPT     icmp --  192.168.151.3        0.0.0.0/0          \n8    ACCEPT     icmp --  192.168.151.4        0.0.0.0/0          \n9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 \n10   nova-compute-sg-fallback  all  --  0.0.0.0/0            0.0.0.0/0        \n  \n\nChain nova-compute-inst-21 (1 references)\nnum  target     prot opt source               destination        \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID \n2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state \nRELATED,ESTABLISHED \n3    nova-compute-provider  all  --  0.0.0.0/0            0.0.0.0/0          \n4    ACCEPT     udp  --  192.168.151.2        0.0.0.0/0           udp spt:67 \ndpt:68 \n5    ACCEPT     all  --  192.168.151.0/24     0.0.0.0/0          \n6    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          \n7    ACCEPT     icmp --  192.168.151.3        0.0.0.0/0          \n8    ACCEPT     icmp --  192.168.151.4        0.0.0.0/0          \n9    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 \n10   nova-compute-sg-fallback  all  --  0.0.0.0/0            0.0.0.0/0        \n  \n\nChain nova-compute-local (1 references)\nnum  target     prot opt source               destination        \n1    nova-compute-inst-20  all  --  0.0.0.0/0            192.168.151.3      \n2    nova-compute-inst-21  all  --  0.0.0.0/0            192.168.151.4      \n\nChain nova-compute-provider (2 references)\nnum  target     prot opt source               destination        \n\nChain nova-compute-sg-fallback (2 references)\nnum  target     prot opt source               destination        \n1    DROP       all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain nova-filter-top (2 references)\nnum  target     prot opt source               destination        \n1    nova-compute-local  all  --  0.0.0.0/0            0.0.0.0/0          \n2    nova-api-local  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain quantum-filter-top (2 references)\nnum  target     prot opt source               destination        \n1    quantum-l3-agent-local  all  --  0.0.0.0/0            0.0.0.0/0          \n\nChain quantum-l3-agent-FORWARD (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-INPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-OUTPUT (1 references)\nnum  target     prot opt source               destination        \n\nChain quantum-l3-agent-local (1 references)\nnum  target     prot opt source               destination        \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1362119051.51288.YahooMailRC@web181703.mail.ne1.yahoo.com>',NULL),('<1366583248.389.1367042853537.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:07:33',0,'2013-04-27 06:07:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal10 in workspace <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/>\nCheckout:periodic-keystone-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 4e087ce1:quantal10\nUsing strategy: Default\nLast Built Revision: Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/keystone.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/keystone.git\nCommencing build of Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nChecking out Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\n[periodic-keystone-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson327752422654016390.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack keystone\n+ version=27\n+ org=openstack\n+ project=keystone\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.mGkoOrHGVt\n+ TMPDIR=/tmp/tmp.mGkoOrHGVt\n+ trap \'rm -rf /tmp/tmp.mGkoOrHGVt\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' keystone == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.keystone.python27.stable.grizzly.17\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-keystone-python27-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 56171 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-keystone-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal10\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.mGkoOrHGVt\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-04-31\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'6f5c6e36-a71f-491b-88e2-f438ac9517e8\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'5929850979b0ccf348c1b913961d581ccac9732c\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal10\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 56171 166.78.63.171 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\nNo distributions at all found for pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.mGkoOrHGVt\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1366631344.60274.YahooMailClassic@web122503.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-22 04:49:04',-25200,'2013-04-22 11:49:04',NULL,'[openstack-dev] Instance Managment','\nHello Everyone!\n?\nI am working on Nova API and i would like to find out :\n?\n1.how can i manage instances? any Idea would be much appriciated!\n2.if i would like to make a web based platform instance managment what direction would i go? (Please point me in the right direction)\n?\nThanks!!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130422/43cfd5bb/attachment.html>\n\n','<CACyjiAi2X=qBRVPRHpbVek0V4Z2KRnZqC=etXkyoS4t1iwLjaw@mail.gmail.com>',NULL),('<1366645787.5350.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-22 16:49:47',3600,'2013-04-22 15:49:47',NULL,'[openstack-tc] Reddwarf application for incubation','On Mon, 2013-04-22 at 14:16 +0200, Thierry Carrez wrote:\n> Michael Basnight wrote:\n> > The following wiki page has the Reddwarf database as a service\n> > application for incubation. Thank you for your consideration!\n> > \n> > https://wiki.openstack.org/wiki/ReddwarfAppliesForIncubation\n> \n> Hi!\n> \n> I\'d like to give more time for the Technical Committee members to\n> recover from the Summit and look into this, so we should consider this\n> application at the meeting next week (April 30).\n> \n> In the mean time, could you repost your application for incubation link\n> to the openstack-dev ML ASAP, so that it can openly be discussed there ?\n\nWould the first meeting be an \"intro to Reddwarf\" discussion and we\nactually make a decision on the application the following week?\n\nI, for one, would like to make a little more effort to look at the code\nthis time around :)\n\nPoking at the code after some initial discussion with the developers\nseems like it would be helpful\n\nCheers,\nMark.\n\n\n\n','<51752A31.20701@openstack.org>',NULL),('<1366647118.5350.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-22 17:11:58',3600,'2013-04-22 16:11:58',NULL,'[openstack-dev] [keystone] [oslo.config] [nova] [tox/testr]\n DuplicateOptError from oslo.config on middleware','Hi Chmoel,\n\nOn Mon, 2013-04-22 at 17:35 +0200, Chmouel Boudjnah wrote:\n> Hi,\n> \n> In review :\n> \n> https://review.openstack.org/#/c/23986/\n> \n> I am trying to bring some update to the ec2 token middleware shipped\n> with keystone to bring  caching, tests use the oslo.config module\n> instead of\n> nova.flags (which is obsolete in grizzly).\n> \n> When running the tests I am getting the infamous error :\n> \n> 2013-04-18 21:20:55.442 | DuplicateOptError: duplicate option: log-format\n> \n> http://logs.openstack.org/23986/3/check/gate-keystone-python26-rhel6/219/console.html.gz\n> \n> While reading other bug reports on it I understand why this has been\n> done, to not get a duplication of config flags, but in my case I just\n> have a middleware designed for nova run in keystone and somehow\n> oslo.config parse nova and keystone during the tests config flags when\n> run by tox.\n> \n> And that\'s the strange thing when I run the indivual test class the\n> problem does not show up but only when I run the full test suite :\n> \n> http://pastie.org/private/x1wdqcrvrzmlk1h6jkazqg\n> \n> so I am guessing there is some mix up going on somewhere while runing\n> the full test suite.\n> \n> \n> The solution/workarounds I can see are :\n> \n> 1) Move ec2_token to nova source tree.\n> 2) do a try: catch(DuplicateError): pass  when parsing the flags.\n> 3) Don\'t use nova for wsgi but the one from keystone.\n> 4) fix tox.\n> \n> I don\'t like 3 because it would assume we need to install keystone\n> package to use ec2token middleware which should be used only with nova\n> so then i\'m in favor of 1) because 2) is just plain ugly and I have\n> spent too much time trying to figure out how to do 4) that I am just\n> avoiding it (infra peps if you have any ideas?).\n\nI admit I\'m replying here without digging into the details, but the\nthing that jumps out at me is:\n\n  keystone/middleware/ec2_token.py:\n\n    from nova import wsgi\n\n  tools/test-requires:\n\n    # ec2token test use nova.wsgi\n    http://tarballs.openstack.org/nova/nova-master.tar.gz#egg=nova\n\nWe really, really should not have code in keystone which depends on code\nin nova. Nova is not library code, its interface is not stable.\n\nWhy can\'t the ec2 token middleware live in Nova?\n\nAs for the DuplicateOpt error, there are a couple of ways I can see to\navoid it:\n\n  1) Fix it so that importing the ec2 middleware doesn\'t import all of \n     keystone\'s config options via the import in keystone.middleware\n\nor\n\n  2) Make keystone use the common logging infrastructure from Oslo\n\nCheers,\nMark.\n\n\n\n','<CAPeWyqxqHUgKaRYWUuudLryr6v_cJrmqtRgJ1sFVA9yjjHeCVA@mail.gmail.com>',NULL),('<1366652874.3281.55.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-22 12:47:54',-18000,'2013-04-22 17:47:54',NULL,'[openstack-dev] [Nova] Future of nova-api operations that act\n on all servers on a host','On Mon, 2013-04-22 at 13:33 -0400, Russell Bryant wrote:\n> Of the things that already exist, python-novaclient makes the most\n> sense.  I\'m concerned with the significant scope increase, though.  This\n> takes novaclient from a fairly straight forward API wrapper library and\n> cmd line tool to something that orchestrates nova operational\n> activities.  Maybe that\'s ok, though.  I\'d like to see some more in\n> depth exploration of how this might be structured so that it\'s only\n> exposed to admins and kept somewhat separate from the traditional stuff\n> in novaclient that is just wrapping the API.\n\nMaybe the solution then is not to implement these sorts of\nadministrative tools in novaclient; just implement the base calls, then\nwrite a new administrative tool that uses the novaclient API and\nperforms the calls; you could call it \"nova-admin\".\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51757483.6010103@redhat.com>',NULL),('<1366660677.7543.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-22 20:57:57',3600,'2013-04-22 19:57:57',NULL,'[openstack-dev] core contributor vs reviewer (was: [keystone]\n Proposal to add Andy Smith to keystone core)','On Mon, 2013-04-22 at 11:04 -0700, Dolph Mathews wrote:\n> Ultimately, \"core contributor\" to me simply means that this person\'s\n> downvotes on code reviews are consistently well thought out and meaningful,\n> such that an upvote by the same person shows a lot of confidence in the\n> patch.\n\nThat\'s a nice way of expressing what makes a good reviewer\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gX5iRpHsokddN=LpXRM79PH5iWqrZuR9DSdV-R5OfCmHw@mail.gmail.com>',NULL),('<1366720993.14480.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 13:43:13',3600,'2013-04-23 12:43:13',NULL,'[openstack-dev] [OSLO] DB Support','On Tue, 2013-04-23 at 10:54 +0300, Gary Kotton wrote:\n\n> 3. In the current Quantum versions all of the database configuration \n> information is under a section [DATABASE]. The common code moves this to \n> [DEFAULT]. If possible it would be great if we could preserve the \n> current configuration file settings. This will enable us to have \n> smoother version upgrades. If this is not possible then we will need a \n> migration script to update configuration files. Does anyone have \n> thoughts on this? I would like to make changes to the common code to \n> ensure that we can use the DATABASE section.\n\nOk, the bug outlines one option:\n\n  https://bugs.launchpad.net/oslo/+bug/1171837\n\nwe move the db options to the \'database\' group and make the group names\ncase insensitive as per:\n\n  https://blueprints.launchpad.net/oslo/+spec/cfg-lowercase-groups\n\nAnother option is to have get_session() in oslo take an sql_connection\nparameter which would override CONF.sql_connection. Quantum would have\nsomething like this:\n\n  sql_opts = [\n      cfg.StrOpt(\'sql_connection\', default=None),\n  ]\n\n  CONF.register_opts(sql_opts, group=\'DEFAULT\')\n\n  def get_session():\n      if CONF.sql_connection:\n          log.warn(\"deprecated!\")\n      return db_session.get_session(CONF.sql_connection)\n\nIf the sets DATABASE.sql_connection they get a deprecation warning but\nit still works. If they don\'t set DATABASE.sql_connection, the common DB\ncode just falls back to DEFAULT.sql_connection.\n\nCheers,\nMark.\n\n\n\n','<51763E2B.2010704@redhat.com>',NULL),('<1366727905.08683398@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 10:38:25',-14400,'2013-04-23 14:38:25',NULL,'[openstack-dev] [Glance] Image Interchange Session Summary','\nImage Interchange Session Summary\n\nWe (as in OpenStack) want to allow users to build in various clouds, but in order to do this we need to provide image conversion tools (or organize existing tools to make it easier on users). \n\nhttps://etherpad.openstack.org/havana-image-interchange\n\nConsensus:\n* Cloud-init to become standard for initializing instances\n\n* We never want to crack open the bits of an image to perform introspection for inserting/\"installing\" software or hypervisor performance tools.\n - Customers may not want us peering into their images\n - it would be greatly complex and vary based on distro\n - Instead things like xentools and virtio could be installed with cloud-init or config management\n\n* Tools already exist for image conversion\n - qemu-img\n - libguestfs\n - virt-v2v\n - guestconv\n\nFurther discussion:\n* Common image format that must be supported by an openstack installation (qcow seemed a leading option)\n\n* Where should conversion happen?\n Options continued to surface:\n - Before image upload by some other tool\n - Let the hypervisor worry about it\n - Provide hooks for image conversion on upload and download\n\nNext steps:\n* Discuss next steps at the next Glance meeting (All are welcome)\n - Thursday, April 25th 20:00 UTC\n - https://wiki.openstack.org/wiki/Meetings/Glance\n\n-Alex\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130423/914877ee/attachment.html>\n\n',NULL,NULL),('<1366728081.14480.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 15:41:21',3600,'2013-04-23 14:41:21',NULL,'[openstack-dev] Standardizing on a WSGI framework [was Re: Pecan vs\n Falcon?]','On Tue, 2013-04-23 at 10:11 -0400, Jay Pipes wrote:\n> This project (Falcon) is only about 4 months old. While it looks to be\n> good solid code, it would be great if OpenStack projects could settle on\n> a WSGI framework and everyone work towards the same end goal. By my\n> count, to date OpenStack projects have used Bottle, Flask, Pecan, WSME,\n> and custom-built frameworks.\n> \n> Why don\'t we get this into Oslo and at least make an attempt at driving\n> the car in the same direction? If the performance benefits of Falcon are\n> as advertised, I would think the OpenStack dev community would be eager\n> to create a simple Oslo wrapper around the Falcon library and start to\n> standardize on a single framework for WSGI handling.\n\nI wholeheartedly agree with the premise - \"this is a frickin mess and it\nwould be awesome to see it get fixed\"\n\nWe\'ve probably discussed it at every design summit to date e.g.\n\n  https://etherpad.openstack.org/havana-common-wsgi\n  https://etherpad.openstack.org/grizzly-common-wsgi-frameworks\n\nHowever, the solution isn\'t for someone to add a Falcon based API to\nOslo and leave it rot there. The hard part is moving projects to a\ncommon framework.\n\nDoug\'s proposal is to use Pecan/WSME for new APIs based on his\nexperience using it in Ceilometer - it would be a step forward if we\ncould have consensus on at least this much.\n\nHowever, the existing WSGI code in our projects isn\'t going away any\ntime soon and continues to evolve. I think there\'d be huge value in\nsomeone incrementally consolidating those WSGI implementations, bit by\nbit.\n\nThe issue here isn\'t a lack of WSGI frameworks to choose from, or a lack\nof understanding that this is a huge issue, or a lack of frustrated\npeople who think it should be easy to fix ... :-)\n\nThe issue here is a lack of anyone willing to grab the bull by the horns\nand start taking baby steps to improve the situation.\n\nCheers,\nMark.\n\n\n\n','<517696AE.3080401@gmail.com>',NULL),('<1366735563.3281.62.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 11:46:03',-18000,'2013-04-23 16:46:03',NULL,'[openstack-dev] [Nova] Future of nova-api operations that act\n on all servers on a host','On Mon, 2013-04-22 at 14:31 -0500, John Garbutt wrote:\n> I am not sure I like diverging from python-novaclient, I was thinking\n> more of a external repo that is full of these style commands:\n> https://github.com/openstack/python-novaclient/tree/master/novaclient/v1_1/contrib\n\nWho said anything about diverging from python-novaclient?  To me,\n\"diverging\" implies having two independent but complete implementations\nof something, and those two implementations start evolving in different\ndirections.  My proposal is simply set up a new CLI tool that leverages\nthe python-novaclient API to implement these complex administrative\noperations.  (And you could, if you wanted to, make those into CLI\nextensions to the existing python-novaclient, instead of a separate\ntool, but I think it becomes cleaner and clearer to use a new\n\"nova-admin\" command for that?)\n\n> So if you are an admin / ops / support, you install an extra set of\n> things, an a whole bunch of extra params light up. Those commands\n> should then just call into novaclient to make any API calls (hmm,\n> maybe thats a dependency loop).\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CABib2_rV4GjChiBYQBW_eWCzWd0qrg6tXckma-_Hdb1ABAefAA@mail.gmail.com>',NULL),('<1366735719.3281.65.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 11:48:39',-18000,'2013-04-23 16:48:39',NULL,'[openstack-dev] Pecan vs Falcon?','Since this thread has become a discussion of WSGI frameworks, I might as\nwell throw my Appathy framework into the fray:\n\n        https://github.com/klmitch/appathy\n\nIt\'s based on the Nova WSGI stack concepts, but considerably cleaned up?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<60A3427EF882A54BA0A1971AE6EF038886805ACE@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1366752864.21508.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-23 22:34:24',3600,'2013-04-23 21:34:24',NULL,'[openstack-dev] legal-discuss mailing list [was Re: NOTICE files]','Hey Dims,\n\nOn Tue, 2013-04-23 at 16:39 -0400, Davanum Srinivas wrote:\n> Hi all,\n> \n> Let me start with IANAL :)\n> \n> At the ASF, the root directory of each project has a NOTICE file (same\n> directory as the LICENSE) file. This file is for collecting copyright,\n> attribution etc. and per the Apache License 2.0 (Section 4.d) [1]\n> requires those who create derivative works using our code to carry\n> those along as well. Please see the following examples.\n> \n> https://svn.apache.org/viewvc/httpd/httpd/trunk/NOTICE?view=log\n> https://svn.apache.org/viewvc/axis/axis2/java/core/trunk/NOTICE.txt?view=log\n> https://svn.apache.org/viewvc/geronimo/server/trunk/NOTICE?view=log\n> \n> Do we have a mechanism that serves the same purpose? Should we adopt\n> this practice?\n\nInteresting question! Can we shelve the question for a short time? :)\n\nGiven some recent discussions amongst the TC, during the Foundation\nboard meeting last week I brought up the issue of the technical\ncommunity needing more support from subject matter experts on legal\nmatters such as this.\n\nThe examples I gave were:\n\n * Changing of OpenStack LLC copyright notices\n\n * Licensing compliance\n   * e.g. copying and pasting BSD code\n   * e.g. GPL licensed shell script\n\n * Licensing policy for dependencies\n   * e.g. ALv2, MIT, BSD, LGPL assumed fine\n   * What about e.g. GPL, AGPL?\n   * Policy vs review process\n\nWhen it comes to actual formal legal advice, we do have the option of\nasking the Foundation to have its council review a matter and this may\noccasionally be necessary. However, in many cases such as this, what we\nreally want is for knowledgeable people to share their experiences from\nother projects, explain their understanding of the rationale for various\napproaches, share what they perceive to be issues with what we\'re doing,\netc. Even if we did have legal council give us formal advice, we need a\nway to discuss that amongst ourselves and with interested subject matter\nexperts.\n\nAnyway, the blindingly obvious suggestion from Richard Fontana is that\nwe create a legal-discuss mailing list like many other projects have\ndone. The advantage to such a list is that subject matter experts could\nactually follow that list, but they\'d never be able to cope with the\nvolume on openstack-dev.\n\nThe only concern anyone has raised to date was from the Foundation\'s\nlegal council that messages on the list could be construed as legal\nadvice, but we can put appropriate disclaimers about the place the allay\nthat fear. Everyone else I talked to (including e.g. Alice King, who\nco-ordinates the Legal Affairs Committee) thinks it\'s a fine idea.\n\nThis question would be a perfect first topic for discussion on the new\nlist :)\n\nCheers,\nMark.\n\n\n\n','<CANw6fcHa4U9TfdBA754hLRS_uiTu19ZpcVoDXqHbNnFbB3+Ybw@mail.gmail.com>',NULL),('<1366808443.7239.159.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 09:00:43',-14400,'2013-04-24 13:00:43',NULL,'[openstack-dev] [keystone] Suggested LDAP DIT for domains','On Tue, 2013-04-23 at 15:26 -0700, Ryan Lane wrote:\n> <https://docs.google.com/file/d/0B96SIvDkZEUJU1JoZE8xTWh4UFk/edit?usp=sharing>\n> \n> \n> In the above, everything exists under ou=domains. In the case an\n> operator wants to use only one single (default) domain, they\'d set\n> their configuration to use the root, rather than ou=domains, and would\n> move everything up a level. Otherwise, a default domain exists as a\n> normal domain in the tree.\n> \n> \n> In this DIT configuration, domains have roles and projects, projects\n> have roles. Projects and roles have members. I believe there was\n> discussion of implying membership in the project by membership of the\n> roles. I\'m not a huge fan of that, but I can modify this design if\n> that\'s the preferred approach.\n> \n> \n> There\'s some major benefits of designing the DIT in this way:\n> \n> \n> 1. It\'s possible to scope searches by depth and base to limit searches\n> to domains and project and to find roles for domains and projects.\n> 2. The DIT can be extended by LDAP administrators for other uses. I\n> can give you a ton of examples, as I\'m doing this currently for\n> per-project sudoers, service and group users, etc..\n> 3. Users, groups, and projects have no requirements for being globally\n> unique. They are only unique per domain.\n> 4. For operators using the current implementation who don\'t want\n> multiple domains, this is backwards compatible.\n> 5. For operators wanting to using multiple domains, they simply need\n> to move their tree a level deeper. Of course this isn\'t a simple\n> change, but it should be a matter of configuration for their\n> applications, rather than development effort.\n> 6. Domains are a matter of hierarchy, and this uses LDAP\'s natural\n> hierarchy.\n> \n\nIt would be nice if this hierarchy were optional, for example you may\nhave attributes with substitution rules that tell where the base for a\ndomain is\n\nPseudo ini-style config:\n[domain]\nbase = ou=%D,ou=domains\n\nwhere %D is substituted with the domain name.\n\n\nThis would allow people to flexibly define their DITs.\n\nAnother option could be to spawn a separate driver per domain with a\ntemplate based configuration system (based again on substitutions), or a\nper domain explicit configuration.\nThis way you could use either one or multiple LDAP servers at the same\ntime as each domain could have a completely different configuration.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CAC9E6cpX74dPPPaTchSkDaYXQMgsvtWrQ4gQgGZwcSXPHPg--A@mail.gmail.com>',NULL),('<1366837639.4412.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 22:07:19',3600,'2013-04-24 21:07:19',NULL,'[openstack-dev] New mailing list : legal-discuss','Hey\n\nThanks to Stefano, we now have a new mailing list ... just what you\nalways wanted :)\n\n  http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss\n\n  The legal-discuss at lists.openstack.org mailing list is a forum for\n  questions (even FAQs) that have a legal aspect to them. These\n  questions may concern (for example) licensing, third party packages,\n  contributor agreement questions and trademark issues. This list will\n  build into an ad-hoc knowledge base about those thorny legal issues\n  that most commonly affect the OpenStack project.\n\n  In other words, this list has similar intent to\n  legal-discuss at apache.org, legal at lists.fedoraproject.org,\n  debian-legal at lists.debian.org, legal-list at gnome.org, etc.\n\n  Opinions expressed on this this list do not constitute legal advice\n  from the OpenStack Foundation, unless explicitly stated.\n\n  Please keep speculation to a minimum and avoid making authoritative\n  statements without genuine knowledge of the subject.\n\n  Volunteers willing to codify discussions into a FAQ will be welcomed.\n\n  --\n\nCredit goes to Richard Fontana for the idea. Please join us!\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1366837692.4412.32.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-24 22:08:12',3600,'2013-04-24 21:08:12',NULL,'[openstack-tc] [Fwd: New mailing list : legal-discuss]','Hey\n\nI\'m thinking it makes sense to just mass-subscribe all TC members to\nthis. Any objection?\n\nCheers,\nMark.\n\n-------- Forwarded Message --------\n> From: Mark McLoughlin <markmc at redhat.com>\n> Reply-to: Mark McLoughlin <markmc at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Subject: New mailing list : legal-discuss\n> Date: Wed, 24 Apr 2013 22:07:19 +0100\n> \n> Hey\n> \n> Thanks to Stefano, we now have a new mailing list ... just what you\n> always wanted :)\n> \n>   http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss\n> \n>   The legal-discuss at lists.openstack.org mailing list is a forum for\n>   questions (even FAQs) that have a legal aspect to them. These\n>   questions may concern (for example) licensing, third party packages,\n>   contributor agreement questions and trademark issues. This list will\n>   build into an ad-hoc knowledge base about those thorny legal issues\n>   that most commonly affect the OpenStack project.\n> \n>   In other words, this list has similar intent to\n>   legal-discuss at apache.org, legal at lists.fedoraproject.org,\n>   debian-legal at lists.debian.org, legal-list at gnome.org, etc.\n> \n>   Opinions expressed on this this list do not constitute legal advice\n>   from the OpenStack Foundation, unless explicitly stated.\n> \n>   Please keep speculation to a minimum and avoid making authoritative\n>   statements without genuine knowledge of the subject.\n> \n>   Volunteers willing to codify discussions into a FAQ will be welcomed.\n> \n>   --\n> \n> Credit goes to Richard Fontana for the idea. Please join us!\n> \n> Thanks,\n> Mark.\n\n\n\n\n',NULL,NULL),('<1366838167.74606.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 14:16:07',-25200,'2013-04-24 21:16:07',NULL,'[openstack-dev] Key Manager blueprint updated','Are there differences in the API between the two efforts?? When do you think\nyou will have an API available for comment?? I saw the intel API on the\nblueprint specification, but I am not sure if that is going to change or not. \n\n> The Intel Key Manager effort (developed on the Openstack mailing list with \n> blueprints) and the Rackspace effort announced last week \n> back? are getting to know each other and collaborate. Early stages.\n\nThe volume encryption team is obviously very interested in the key manager.\nPlease keep us informed of the effort. We would like to know the APIs as soon \nas possible, so we can begin coding to an interface. That will make it easy for\nus to transition to a real key manager in future.\n\n> Also need a close partner for using the keys from the Key Manager, the volume\n> encryption folks. Or a simpler first use, saving the Nova public certificates\n> that are injected into VMs to support ssh. ?\n\nAny timeline on when this would happen?\n\n> The only published blueprint is mine, and as good a placeholder for your \n> comments/feedback as any other, or this mailing list.\n> A first successful Intel/Rackspace co-operation would be a revised blueprint,\n> and sub-blueprints (representing feature coding chunks)\n> and publishing a git repository for code and community contributions.\n\n-Nate\n\n\n',NULL,NULL),('<1366839056.215328255@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 17:30:56',-14400,'2013-04-24 21:30:56',NULL,'[openstack-dev] [Glance] Getting Glance Ready for Public Clouds\n	Session Summary','\nTopic & short description\nTopic: Getting Glance Ready for Public Clouds\nDescription:\nCurrently Glance is exposed to users through Nova; this is becoming a problem because new Glance features require a Nova extension.  It would be better to have Glance as a first-class member of the OpenStack ecosystem.  But in order for this to happen, we (as in OpenStack cloud providers) would need at least:\n\nmore robust user roles to allow per-user:\n\nrate limits\n\nquotas\n\nRBAC (per-tenant)\n\nprotected image properties\n\nimage-related restrictions\n\ne.g., there may be contractual reasons why you wouldn\'t want to allow download of specific images based not on the user, but on the image itself; might be the case for other actions)\n\nother API changes from increased load\n\nThere are currently blueprints for rate limits, but an alternative approach would be to think that rate limiting should be done in front of Glance by Repose or a similar system that understands Keystone. \n\nLink to etherpad discussion\n\n[https://etherpad.openstack.org/havana-getting-glance-ready-for-public-clouds] https://etherpad.openstack.org/havana-getting-glance-ready-for-public-clouds\n\nSummary of summit consensus (if any) about how to proceed\n\n1. rate limits: should be done by something in front of glance\n 2. quotas: no consensus\n\nrequires further research. \n\nThere are 2 related blueprints:\n\n[https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas\n\n[https://blueprints.launchpad.net/nova/+spec/ledger-quota-subsystem] https://blueprints.launchpad.net/nova/+spec/ledger-quota-subsystem : proposed as a Nova subsystem, would be better in Oslo?\n\nThe BPs were proposed by Artem Andreev ([https://launchpad.net/~just-wow] https://launchpad.net/~just-wow ), not sure if he\'s still interested in working on this3. protected image properties\n\nhas an approved blueprint [https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection] https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection\n\ndetails are under discussion: [https://etherpad.openstack.org/public-glance-protected-props] https://etherpad.openstack.org/public-glance-protected-props\n\nvolunteers to work on this: smclaren, isethi, & mikal4. upload and download workflow\n\nWorkflow discussion in summit etherpad and blueprint\nBlueprint: [https://blueprints.launchpad.net/glance/+spec/upload-download-workflow] https://blueprints.launchpad.net/glance/+spec/upload-download-workflow\n\nList of blueprints and assignees (if any)\n\n[https://blueprints.launchpad.net/glance/+spec/uplopad-download-workflow] https://blueprints.launchpad.net/glance/+spec/upload-download-workflow\n\nstatus: New\n\nassignee: none\n\n[https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection] https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection\n\nstatus: Approved for Havana-M1\n\nassignee: Mark W\n\n[https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas\n\nstatus: Drafting\n\nassignee: none\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/f0cc3149/attachment.html>\n\n',NULL,NULL),('<1366842333.4412.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 23:25:33',3600,'2013-04-24 22:25:33',NULL,'[openstack-dev] [oslo][keystone] Trying to get\n openstack.common.wsgi in keystoneclient','Hi,\n\nOn Wed, 2013-04-24 at 17:07 +0200, Chmouel Boudjnah wrote:\n> Hello,\n> \n> I am trying to move the s3_token and ec2_token middleware to\n> python-keystoneclient I thought it would be a good idea to make them\n> using openstack.common.wsgi instead of {swift,keystone,nova}.wsgi\n\nHow much of openstack.common.wsgi do these middlewares actually use?\nWould it be reasonable to factor out the middleware-supporting code into\na standalone module?\n\nCheers,\nMark.\n\n\n\n','<CAPeWyqzy2Vgth+RR2QrUA6qGStYNN3wdXY=RuARybyoSz7vKcQ@mail.gmail.com>',NULL),('<1366849811.109611723@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-24 20:30:11',-14400,'2013-04-25 00:30:11',NULL,'[openstack-dev] [Glance] Image Cloning to other regions Session\n	Summary','\n\nTopic and short description :-\n\nTopic: Image Cloning to Other Regions\nDescription:\nMany Cloud providers have clouds in segregated \"regions\".  AWS just announced the ability for customers to copy images to other regions -- we want to implement the same capability in OpenStack.  One difference would be that we\'d like to have the same UUID in every region (because the \"bits\" of the image would be the same).\n\nIt would make sense for this to be a Swift-to-Swift transfer, so we\'d need to cooperate with Swift on this. (Swift doesn\'t currently have anything like this for individual files; it\'s currently a full-container transfer.)  The reason we\'re proposing it as a Glance topic is:\n\nit would make sense for Glance to be the endpoint for this service (once Glance is ready for exposure in public clouds)\n\nwe want this to be a user operation, not an admin operation\n\nit would make sense that people will want some kind of metadata sync (determining exactly what this would be is part of the focus of this session)\n\nGlance may need some enhancements with respect to API calls and notifications to support this\n\n\nLink to etherpad discussion\n\n[https://etherpad.openstack.org/havana-image-cloning-to-other-regions] https://etherpad.openstack.org/havana-image-cloning-to-other-regions\n \nSummary of summit consensus (if any) about how to proceed\n\nThe Rackspace proposal to have the same UUID in each region was rejected.  Instead, the checksum image property will be indexed so that users can search for an image by specifying the checksum.\n[https://blueprints.launchpad.net/glance/+spec/index-using-checksum-image-property] https://blueprints.launchpad.net/glance/+spec/index-using-checksum-image-property\nguess the URL will be \"/images?checksum=<value>\" (hopefully returning a list containing at most one element)\nThe call will use a \"pull\" model, i.e., will be made in the target region\ndiscussion\nmakes it easy to return an image URL that can be polled, but what to do when it turns out the UUID doesn\'t exist or the user doesn\'t have permission to copy?  Can put the image into an error state, but this isn\'t helpful telling the user what the problem is\nwhat will the call look like?  (The regions a user has access to should be in the user\'s service catalog)\nrequires more discussion on [https://etherpad.openstack.org/clone-image-across-regions] https://etherpad.openstack.org/clone-image-across-regions\n[https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions] https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions\nAll appropriate image properties/metadata will be propagated to the target glance from the source glance.\nno ongoing synchronization\nrequires more discussion on [https://etherpad.openstack.org/clone-image-across-regions] https://etherpad.openstack.org/clone-image-across-regions\n[https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions] https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions\nThe image data should travel directly from source backend store to target backend store.\nSwift-to-swift for first implementation? (Exception \"operation not supported\" for other stores?)\ndiscussion\nSince it\'s an async operation, have to figure out how error states will be propagated back to the caller\nrequires more discussion on [https://etherpad.openstack.org/copying-image-data-across-regions] https://etherpad.openstack.org/copying-image-data-across-regions\n[https://blueprints.launchpad.net/glance/+spec/copying-image-data-across-regions] https://blueprints.launchpad.net/glance/+spec/copying-image-data-across-regions\n\n \nList of blueprints and assignees (if any)\n\n[https://blueprints.launchpad.net/glance/+spec/image-cloning-to-other-regions] https://blueprints.launchpad.net/glance/+spec/image-cloning-to-other-regions\n\nstatus: discussion\n\nassignee: none\n\n[https://blueprints.launchpad.net/glance/+spec/index-using-checksum-image-property] https://blueprints.launchpad.net/glance/+spec/index-using-checksum-image-property\n\nstatus: discussion\n\nassignee: none\n\n[https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions] https://blueprints.launchpad.net/glance/+spec/clone-image-across-regions\n\nstatus: discussion\n\nassignee: none\n\n[https://blueprints.launchpad.net/glance/+spec/copying-image-data-across-regions] https://blueprints.launchpad.net/glance/+spec/copying-image-data-across-regions\n\nstatus: discussion\n\nassignee: none\n \nthanks,\n-Nikhil Komawar\n(nikhil on #openstack-glance)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130424/250e3f73/attachment.html>\n\n',NULL,NULL),('<1366893429.7239.214.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 08:37:09',-14400,'2013-04-25 12:37:09',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','Hello list,\nat the Summit we had a very interesting and productive discussion about\nMessage Signing/Encryption for RPC Messages sent via the Message Queue.\n\nI would like to present a proposal that uses symmetric keys and a\ncentral key server to address the problem:\n\nhttps://wiki.openstack.org/wiki/MessageSecurity\n\nI would really like to get feedback on the proposal, especially if there\nare corner cases I have not considered.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n',NULL,NULL),('<1366897137.16156.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-25 14:38:57',3600,'2013-04-25 13:38:57',NULL,'[openstack-tc] Reddwarf application for incubation','Hi John,\n\nOn Wed, 2013-04-24 at 21:55 -0700, John Dickinson wrote:\n> AFAIK, we have yet to receive any direction from the OpenStack BoD on\n> the question of the scope of OpenStack. As such, especially with\n> somethink like Red Dwarf which appears to be completely built on top\n> of existing OpenStack projects, should we wait to consider the\n> application?\n> \n> Perhaps having somewhat of a backup in incubation considerations will\n> put some pressure on the BoD to more quickly answer the \"what is\n> OpenStack\" question.\n\nIf you look at e.g. the TC motion[1] or the Incubation Update\ncommittee\'s report[2], we describe the TC as considering whether a\nproject \"represents a sensible broadening of the scope of OpenStack\",\n\"the appropriateness of its scope\", \"complementary in scope\" etc.\n\nWhether a new project\'s scope is appropriate for an Integrated project\nin OpenStack is a TC decision. We can certainly ask the BoD and others\nfor input on this or any other topic, but it\'s on us to consider and\ndecide on this for each Incubation application.\n\nCheers,\nMark.\n\n[1] - http://lists.openstack.org/pipermail/openstack-dev/2012-November/002766.html\n[2] - https://wiki.openstack.org/wiki/Governance/Foundation/IncubationUpdate2013\n\n\n\n','<378B6D8A-9C55-4390-A252-06B4CA4D3AEF@not.mn>',NULL),('<1366897895.7239.247.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 09:51:35',-14400,'2013-04-25 13:51:35',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:\n> Simo,\n> \n> Nice! feedback after a quick browse and compare with xml-dsig\n> \n> 1. Can we please allow additional algorithms? (see DigestMethod in\n> [1]). HMAC-SHA-256 can definitely be the default\n\nWell as a principle I like keeping security code *simple* and well\ndefined, at least for an initial implementation. We might add additional\nmetadata in the future to specify different algorithms, but I would see\nthat as an additional feature to allow in the future.\n\n> 2. Do we need some terminator between MetaData and Message during -\n> \"Signature = HMAC(SignKey, (Version || MetaData || Message))\"?\n\nNo.\n\n> 3. Assuming that _SIGNATURE_KEY maps to DigestValue in [1] right?\n\nNo, XML signatures are a mess, we are not doing anything like that, we\njust use version as a string, and message and metadata are also srings\n(JSON dumps). So _SIGNATURE_KEY is literally a MAC on a blob of data\ncomposed of 3 concatenated strings.\n\n> 4. I am assuming the counter is to prevent replay attacks. can we\n> please use a nonce instead?\n\nYes replay attacks.\nWhat is the advantage of a nonce ?\n\nThe counter can be used to make sure older messages are simply discarded\nw/o the need to keep track of them. The 2 advantages are:\na) no need to save all the messages (or at least the nonces) seen during\nthe validity interval of the keys, you just need to store a counter.\nb) allows to have some protection against replay attacks also when\nmultiple targets are allowed to use the same key. For example sending\nmessage signed with the \'common\' scheduler.* key. With nonces the only\nway to do any replay attack detection would be to have a shared cache\nbetween all schedulers. With a counter at least you can automatically\ndiscard any \'old\' value if any specific scheduler have already seen a\nnewer counter even if no shared database exists.\n\nI do not actually like either the counter or the nonce approach, and we\ntechnically do not require either. We could just use the timestamp, so I\nmay end up proposing we drop the counter completely.\n\n> 5. Can we please use ISO 8601 timestamps instead of unixtime?\n\nAt the moment I am experimenting with python time.time() values that\nhave sub-second resolution. ISO8601 timestamp do not really make sense\nhere, This timestamp is not for human consumption, and having to parse\nit back and forth is unnecessary. Also ISO 8601 does not have sub-second\nresolution, while we may want to use it so that we can also drop the\ncounter as the chance of 2 message being sent to the same target to end\nup with the same timestamp are low, and we can make it 0 by simply\nkeeping around the old timestamp and increasing it by 1 if the new one\nmatches exactly.\n\n> I\'ll take a deeper look at the encryption later when i get a chance.\n\nThanks for the feedback so far, you raised excellent points!\n\nSimo.\n\n> thanks,\n> dims\n> \n> [1] http://www.w3.org/TR/xmldsig-core/\n> \n> On Thu, Apr 25, 2013 at 8:37 AM, Simo Sorce <simo at redhat.com> wrote:\n> > Hello list,\n> > at the Summit we had a very interesting and productive discussion about\n> > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> >\n> > I would like to present a proposal that uses symmetric keys and a\n> > central key server to address the problem:\n> >\n> > https://wiki.openstack.org/wiki/MessageSecurity\n> >\n> > I would really like to get feedback on the proposal, especially if there\n> > are corner cases I have not considered.\n> >\n> > Simo.\n> >\n> > --\n> > Simo Sorce * Red Hat, Inc * New York\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CANw6fcHN9n6-mqVGMcitb+ebs8ntaLRLDYWgrY0uAXfyvG=JnQ@mail.gmail.com>',NULL),('<1366899987.7239.251.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 10:26:27',-14400,'2013-04-25 14:26:27',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 10:12 -0400, Davanum Srinivas wrote:\n> Please see below:\n\n> Dropping the counter/nonce for the first cut sounds good to me.\n\nOk then I will just drop it, I am writing some code to play with and the\ncounter is just annoying and requires more state to be kept. I\'ll change\nthe page and get rid of it.\n\n> >> 5. Can we please use ISO 8601 timestamps instead of unixtime?\n> >\n> > At the moment I am experimenting with python time.time() values that\n> > have sub-second resolution. ISO8601 timestamp do not really make sense\n> > here, This timestamp is not for human consumption, and having to parse\n> > it back and forth is unnecessary. Also ISO 8601 does not have sub-second\n> > resolution, while we may want to use it so that we can also drop the\n> > counter as the chance of 2 message being sent to the same target to end\n> > up with the same timestamp are low, and we can make it 0 by simply\n> > keeping around the old timestamp and increasing it by 1 if the new one\n> > matches exactly.\n> \n> ISO8601 here is not for human consumption. In my environment, we make\n> sure all components are synced using NTPD and we like adding code to\n> reject messages outside of a time window.\n\nAnd you really should use NTP, but what has that to do with how you\nrepresent time in the metadata?\n\ntime.time() gives you the numbers of seconds since the epoch in UTC, int\nhis case with subseconds as well. If you can help me find better\nlanguage to define the format I\'ll be happy to. But I think number of\nseconds since the epoch is fine, we do not need a structured date format\nhere. \n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CANw6fcFYQC_txMrNAu4egS+regHcBTz84EKppvuCi09aPOtpFA@mail.gmail.com>',NULL),('<1366900031.16156.25.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 15:27:11',3600,'2013-04-25 14:27:11',NULL,'[openstack-dev] [oslo] IRC meeting info','Hi Annie,\n\nOn Wed, 2013-04-24 at 18:23 -0700, Annie Cheng wrote:\n> Hi Oslo team,\n> \n> Is there a weekly IRC meeting for Oslo?\n> \n> I can\'t find it on https://wiki.openstack.org/wiki/Meetings\n\nI tend to be a little sceptical about regularly meetings in general, so\nthat\'s part of the reason why we haven\'t done one to date :)\n\nHowever, I\'m totally up for having a meeting whenever someone has\nsomething they want to talk about. To that end, I\'ve created:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n\nWe just need to agree on a time slot to keep open for the meeting. Sigh,\nthis is never fun. Here\'s a doodle to see what time suits for people:\n\n  http://www.doodle.com/vbs7ux7m4pa3c6c5\n\nCheers,\nMark.\n\n\n\n','<CAG766XeDmENVzWrTBvJNv8y9=gt1w6dpfo9m=N5x3-K8CGS6qA@mail.gmail.com>',NULL),('<1366901460.7239.256.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 10:51:00',-14400,'2013-04-25 14:51:00',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 15:38 +0100, David Chadwick wrote:\n> \n> On 25/04/2013 14:51, Simo Sorce wrote:\n> > On Thu, 2013-04-25 at 09:20 -0400, Davanum Srinivas wrote:\n> >> Simo,\n> >>\n> >> Nice! feedback after a quick browse and compare with xml-dsig\n> >>\n> >> 1. Can we please allow additional algorithms? (see DigestMethod in\n> >> [1]). HMAC-SHA-256 can definitely be the default\n> >\n> > Well as a principle I like keeping security code *simple* and well\n> > defined, at least for an initial implementation. We might add additional\n> > metadata in the future to specify different algorithms, but I would see\n> > that as an additional feature to allow in the future.\n> \n> I think you should differentiate between the code that implements \n> different algorithms, and the mechanism that is used to choose between \n> algorithms.\n\nThe problem is that crypto is hard, and considering all the implications\nof how algorithms interact is something few can master.\nso I tend to subscribe to the cabal :) that wants to dictate a very\nstrict set and not give much choice to the implementer when it comes to\nhow crypto is handled.\n\nSo my question really is: why do you want choice in this matter ?\n\n>  The initial implementation should not be hard coded with any \n> specific algorithm, but should have the mechanism for choosing between \n> algorithms built into it from the start,\n\nI object in principle to this :)\n\n>  even if the initial \n> implementation only supports one algorithm. It then becomes relatively \n> straight forward to plug in new algorithms.\n\nYes, which is not necessarily a good thing. I am not saying we will not\nend up doing this, but I want to hear a good reason for allowing\nnon-experts (ie the users or the packagers) choice in this matter.\n\nThe more options you add the more avenues of attack you add ...\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51793FD5.8040102@kent.ac.uk>',NULL),('<1366901790.7239.261.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 10:56:30',-14400,'2013-04-25 14:56:30',NULL,'[openstack-dev] [keystone] Suggested LDAP DIT for domains','On Thu, 2013-04-25 at 10:45 -0400, Adam Young wrote:\n> OK,  so Ryan has convinced me that multiple LDAP servers under the same \n> Keystone is an incantation for self induced insanity.\n> \n> Based on conversations with the other devs, we are going to enforce that \n> there is only one LDAP server per keystone, and limit the number of \n> domains it can support to one.\n> \n> There can be only one.\n\nI would like to hear what is the argument that convinced you here ?\n\nThe reason you have multiple domains is that you have the need for\nmultiple user-sets, that seem to lend naturally to cover the case where\nan organization have multiple set of users in different LDAP servers, so\nthat you may want to use one LDAP server for one domain and another for\nanother domain.\n\nWhere does this argument breaks ?\n\n> The APIs for Domains will still be implemented, but creating or \n> modifying a domain will be return an Not implemented return code. There \n> will be a single domain object that will be immutable, although we may \n> allow initializing it from config file values.\n\nOh, so no support for multiple domains at all ? Odd, seem this will make\nyour LDAP backend a second class citizen and a non viable choice in some\ndeployment. Not complaining just acknowledging.\n\n> Why are we \"yanking\" a feature like this? Quite simply, because the vast \n> majority of LDAP deployments out there will not use it, and will not \n> support the approach we have started.  We would rather focus on solving \n> the real needs of the LDAP users.  Most people cannot write to their \n> LDAP servers, and those that can often don\'t have the power to change \n> the schema.  Thus far, the LDAP work has kept this design in mind, but \n> Domains forced us to marry up two inconstant views of the world.\n> \n> Multiple domains will still be supported in the SQL backend.\n> \n> Organizations that require multiple LDAP servers were not served by the \n> existing implementation.  Those will require a different solution. Each \n> will get their own Keystone server, and we will use the approach \n> sketched out in other blueprints to ensure that they can co-exist in a \n> single Open Stack deployment.\n\nI guess the read-only LDAP case can still be used for multiple domains\nif keystone specific data is kept in a Kystone database ?\n\nIf that\'s the case I think your choice will make sense.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51794196.8040104@redhat.com>',NULL),('<1366905093.10084.4.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 11:51:33',-14400,'2013-04-25 15:51:33',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 16:38 +0100, David Chadwick wrote:\n> You answered your own question when you said\n> \n> \"The problem is that crypto is hard, and considering all the \n> implications of how algorithms interact is something few can master.\"\n> \n> So if you hard code in a single (set of) algoriths, and then a \n> vulnerability is found in it (which happens all the time), then you are \n> screwed because you have no alternatives to switch to.\n> \n> Some applications still have MD5 hard coded in, which is why many root \n> CAs with MD5 are still configured into most browsers. And that provided \n> the attack hole for APTs sending out \"microsoft\" updates with spoofed \n> MD5 certs.\n\nThe thing is, unless you are asking for negotiating algorithms on the\nfly, what is the difference from changing a configuration option and\npatching a single python source file ?\n\nSure we can set the HMAC and encryption scheme in a config file, but due\nto the networked nature of queues, it means you still have to manually\nchange this configuration on all hosts and restart the cloud.\nI see no difference between doing that and patching all components and\nrestarting the cloud. Is there ?\n\nI will look into making this configurable now anyway :)\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51794E13.9070703@kent.ac.uk>',NULL),('<1366905429.10084.6.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 11:57:09',-14400,'2013-04-25 15:57:09',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 10:39 -0500, Dolph Mathews wrote:\n> As for utilizing a key manager, we had a couple sessions about that at\n> the summit, including:\n> \n> \n> \n> http://openstacksummitapril2013.sched.org/event/886118ad75e16dae1da91d9ca9866ca7#.UXlOASuDQ1I\n\nI was at that presentation.\nThat said holding keys for volume encryption and handling symmetric keys\nfor signing of messages are two quite different tasks and realms.\nThey can end up in the same service though, I have no preference.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CAC=h7gWTDjiXU249TjaUcn9b4D7Z9dXGoMdFb1nHMrta-NKR-A@mail.gmail.com>',NULL),('<1366905733.10084.10.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 12:02:13',-14400,'2013-04-25 16:02:13',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 15:41 +0000, Bhandaru, Malini K wrote:\n> My take on encryption choice:\n> 1) Not giving choice when it exists is bad. We especially do not want our solution to be disregarded because of its restrictiveness.\n> 2) The novice user/deployer/enterprise can be agnostic of the crypto choices, the defaults being set to NIST best practices.\n> 3) Billing -- encrypted/un-encrypted rates will differ, and a 1024 bit key encryption would be more expensive than a 256 bit key.\n>      A small deployer may want to give their public web pages un-encrypted but their high value customer/pay-roll data strongly encrypted and with different strengths may be. Sometimes in retail, the winner of a contract may differ in price point by just a cent. This choice affords both user and cloud provider different monitization rates. I am thinking for object/volume encryption here, not openstack endpoint to endpoint communication.\n> There we can keep things fixed, best practice.\n\nYour points apply well to the Key Manager case where encryption keys for\ndisk volumes are handled. For internal message queue security however\npoint 3 is simply not applicable.\n\nAnd I will address point 1, 2 by making the algorithm a configuration\noption in the implementation, however I will keep the language in the\ncurrent document, just read the \"we choose X and Y algorithm\" to simply\nmean \"as default\".\n\nWhat I am not going to do and will strongly object to is to add means to\nnegotiate algorithms. If you want to go down that rabbit hole we should\njust stop trying to do our own and instead use an existing\nimplementation like Kerberos and simply build APIs on top of it so it\ncan be exposed via HTTP instead of the traditional stream oriented\nGSSAPI.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E53C4E51A@ORSMSX154.amr.corp.intel.com>',NULL),('<1366906990.10084.13.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 12:23:10',-14400,'2013-04-25 16:23:10',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 17:04 +0100, David Chadwick wrote:\n> you dont need to negotiate algorithms on the fly. If the crypto arrives \n> with a clear indication of what algorithms it has used (as in S/MIME, \n> X.509 certs etc.) then the receiving code can automatically determine \n> which algorithms to use to decrypt the message. Of course, negotiation \n> of algorithms for point to point connections e.g. as in TLS/SSL, allows \n> an optimal set to be chosen from the outset\n\nWell, you are assuming that the keys given out by the Key server do not\nneed to change if you change the algorithm, and that is not necessarily\ntrue. So you slowly but steadily end up with needing a negotiation\nscheme with the key server at least and ... it is a slippery slope.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51795422.2090607@kent.ac.uk>',NULL),('<1366907220.10084.17.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 12:27:00',-14400,'2013-04-25 16:27:00',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 17:19 +0100, David Chadwick wrote:\n> What happens in a very fast system if two sub-processes create a message \n> at the same time and therefore contain the same timestamp?\n\nWell, right now we use eventlet so no concurrency is really allowed.\nIf we move to a truly concurrent system (something I actually hope we\ndo) then we\'ll have to serialize how we get the timestamp. We\'ll\nbasically need a single source of time that will just increment by one\nhundredth of a second or so if a second request comes in within the same\nhundredth of a second. Basically keep a high watermark in shared memory\nand use atomic updates to never get a dup.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51795798.1060108@kent.ac.uk>',NULL),('<1366911742.72075192@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 13:42:22',-14400,'2013-04-25 17:42:22',NULL,'[openstack-dev] Should deleted glance images be visible still','\nIt\'s by design.\n \nYou can see deleted images when doing a show or a list with a filter such as the \"changes-since\" filter. If you do a list with no filters then deleted images should not appear. I can\'t remember all of the logic behind this though, just that there was good reason. Obviously, it had something to do with the need to lookup an image after it was deleted.\n \nThanks for asking though, perhaps we need to make the reasoning more obvious (or get rid of soft deletes) :)\n \n-Alex\n \n-----Original Message-----\nFrom: \"Matthew Sherborne\" <msherborne at gmail.com>\nSent: Thursday, April 25, 2013 6:28am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Should deleted glance images be visible still\n\n\n\n\n\n\n\n\n\nIs it by design that glance shows deleted images ? or is it a bug ? or am I experiencing some kind of caching  ?\n\n\nI\'m testing through the nova client:\n\nAs an end user in nova:\n\n\n1. Create a vm2. nova image-create myvm myimage3. nova image-delete my-uuid4. nova image-show my-uuid\n+----------------------+--------------------------------------+\n | Property             | Value                                |\n+----------------------+--------------------------------------+\n| status               | DELETED                              |\n| updated              | 2013-04-25T10:24:02Z                 |\n | name                 | temp                 s                |\n| created              | 2013-04-25T10:19:09Z                 |\n| minDisk              | 20                                   |\n| progress             | 0                                    |\n | minRam               | 512                                  |\n| OS-EXT-IMG-SIZE:size | 893173760                            |\n| id                   | 1b399542-a4fb-49a0-8130-69969f1175b8 |\n+----------------------+--------------------------------------+\nMany ThanksMatthew Sherborne\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130425/e3da71d8/attachment.html>\n\n','<CADf4zRJrQ8v6m++r169-z+wLaHS62BMt1kDzFgsO9ucc7PQyoA@mail.gmail.com>',NULL),('<1366912723.10084.39.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 13:58:43',-14400,'2013-04-25 17:58:43',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 12:52 -0400, Eric Windisch wrote:\n> I\'ve read through this and had a discussion with Simo on IRC for clarity, before posting.\n> \n> It isn\'t a terrible proposal. My biggest concerns are the following, as pertains to signing-only:\n> \n> 1) Keyserver lookups on both sides, not just one-sided, on signing.\n> 2) Practical requirement for the matchmaker for signing, even for AMQP.\n> \n> On the encryption side, PKI has the same requirements, but using\n> slower algorithms. If we accept that the typical use-case will be\n> message signing, then we may prefer to optimize for that, not for\n> encryption.\n\nSigning is also very slow with public key crypto as it is the same\noperation only using the other key (private vs public).\n\n> Perhaps we could figure out a middle-ground here with a single\n> sender-side lookup and a token from the keyserver? That might be a\n> slippery slope.\n\n> The practical requirement for the matchmaker is a HUGE one. This means\n> that not only does a keyserver lookup have to be performed when\n> sending each message, but also a matchmaker lookup. The matchmaker\n> would perform local routing decisions, rather than making those\n> decisions on a broker. These routing decisions must be made locally\n> such that the peers on both sides of the connection are known in\n> advance, for keying purposes.\n\nI have looked into this claim after our conversation and I am not so\nsure we really need it. At least not always.\n\nFor communication to services that are duplicated just for scalability,\nlike the scheduler, using a shared short term key that they can all\nrequest from the key server is probably fine. The schedulers are all\nallowed to send messages to the compute nodes anyway, so if any get\ncompromised it is already game over.\nSo we could easily have a target of scheduler.* and no matchmaker would\nbe required.\n\nThe only \"service\" we do not want to allow to share keys is the compute\nnode, but fanning out to compute nodes is already a bad idea, so\nlimiting that target, or simply not signing those kind of broadcast\nmessages until a better approach is found is probably ok.\n\nOne minor issue is handling replay attacks, but the same issue exists\nunaltered in a public key crypto approach.\n\n[..]\n\n> Hell, I\'m the ZeroMQ driver maintainer - I don\'t mind if everyone\n> wants to switch to ZeroMQ, or switch to the messaging model it\n> advocates. I\'d be happy for it. However, I\'m not the one suggesting we\n> do this - but the community should realize that Simo is effectively,\n> whether he knows it or not, pushing for either the adoption of ZeroMQ\n> or the rewrite of our RabbitMQ/Qpid drivers.\n\nI think this is a gross misrepresentation, sorry.\n\n>  It might not be obvious now, but that is the path this particular\n> road leads to. It isn\'t a bad road, but we shouldn\'t be surprised when\n> we get to the end.\n\n> The proposal to use PKI for signing, despite what might otherwise be\n> complexities and difficulties around that proposal, would not\n> significantly change our messaging model. This kind of gets thrown out\n> as soon as we introduce encryption, however, where we fall back into\n> the matchmaker trap such that we can determine the remote peer\'s\n> identity for encryption purposes.\n\nExcept my proposal allows encryption to multiple parties, they just have\nto share a short term key, while a public key infrastructure simply\ncannot do that, because you\'d have to share a long term key.\n\nSo pick your poison :)\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<BB8E43DB228D4E25A7120CE72D73F0A7@cloudscaling.com>',NULL),('<1366914045.10084.60.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 14:20:45',-14400,'2013-04-25 18:20:45',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 13:27 -0400, Eric Windisch wrote:\n> > \n> > I don\'t think he was advocating a matchmaker requirement. In fact, we\n> > spoke about this specifically. The idea is what in cases when we\'re\n> > sending a specific service+host, the key used reflects that. In the\n> > case where we\'re sending to any one of a specific service, the key is\n> > service-wide. Is that acceptable? Maybe. We have to look at when each\n> > case is used.\n> \n> \n> I don\'t think it is acceptable. Shared private keys aren\'t private.\n\nThey are shared, not private indeed, you just need to decide if the\nbounding set of actors that have access to a shared key is acceptable.\nI think it is for short term keys.\n\nAfter all if you want to do encryption at any point you\'ll have exactly\nthe same problem with a public key infrastructure, only worse as you\nhave to share a long term key then!\n\n> Also, you eliminate the ability to prevent replay attacks if the peer\n> is not known in advance.\n\nHow do you prevent replay attacks with public key crypto ?\n\n>  Despite what I said earlier, this does mean that for PKI, if strict\n> replay attack prevention is enforced, one will need to use the\n> matchmaker for signing.\n\nIf you have to use the matchmaker you are back to square zero and both\nsolutions are again on equal foot on this detail.\n\n>  However, at least then, that is a soft-requirement, something a\n> deployer can choose: risk of replay versus performance.\n\nNo, there is no versus here. You can choose to ignore replay attacks\nwith both solutions, the threat posed by a replay attack does not depend\non the scheme used. Either you care for it or not.\n\n> Having individual keying allows for things like tying your keyserver\n> into remote attestation. Hosts that cannot attest can be removed from\n> the pool automatically.\n\nI am not sure I understand what you mean here, care to elaborate ?\n\n> You want one compromised scheduler to remove them all?\n\nNo, how would the scheme I proposed imply that ?\n\n>  If using some plugin to Quantum that required a fanout to all\n> compute, should one compromised compute machine disable them all?\n> \nCompute nodes obviously should not be allowed to share keys.\nBut the thing is that you shouldn\'t probably do fanout to all compute\nnodes in the first place.\n\nOne way to address broadcast type issues in quantum then, is perhaps to\nestablish that compute nodes should not trust information sent out that\nway, and consider any broadcast messaging as a \'please call home as soon\nas you can and grab a new value for X\'. Broadcast messages would be\nunsigned. Then each compute node can decide if they are interested in\nthe information and if they are, they actually go and contact the\nservice to get the information directly.\n\nIncidentally this scheme may also give some protection from a single\ncompromised service, as its broadcasts will not be implicitly trusted.\n\nIf you have many instances of the service then only a subset of nodes\nwill end up contacting the compromised one as the nodes will evenly\nspread their requests among the various copies of the service and reduce\nthe success of a broadcast attack.\n> \n> > In nova, the case that we\'re *most* concerned about is anything\n> > involving compute nodes. In the case of compute, we\'re almost always\n> > talking directly to a specific compute node. There\'s one case where we\n> > broadcast to all computes, but I think we can probably re-engineer that\n> > case.\n> \n> What about Quantum? Cinder? Ceilometer?\n\nWhat you want signing for is mostly to avoid an anonymous attacker from\nsending fake messages around posing as one of the legit services.\nSigning is not a way to protect nodes from services that have legit\nkeys.\nI see each of these services as a single trust entity, the fact there\nare multiple instances is necessary to scale better but that\'s just\nincidental. If any of the copy of the services is compromised this copy\ncan attack all other endpoints that \'believe\' them. The fact they might\nshare a short term key makes absolutely no difference as a compute node\nwill trust scheduler.compromised or quantum.compromised as much as they\ntrust any other. \n\n> Quantum seems to require agents on all compute nodes. Several plugins\n> perform fanout calls to those agents. Yes, seriously. That might not\n> be a good design, but they do it.\n\n\n> > A service-wide example would be scheduler. We\'re not nearly as\n> > concerned about the scheduler, so a key for scheduler.* is probably\n> > acceptable.\n> > \n> \n> I disagree. \n\nCan you please substantiate a threat model ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<71BA30EDA2224814981E3B8BAA1768A5@cloudscaling.com>',NULL),('<1366914498.10084.67.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 14:28:18',-14400,'2013-04-25 18:28:18',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 13:48 -0400, Eric Windisch wrote:\n> > I don\'t think it is acceptable. Shared private keys aren\'t private.\n> Sometimes I should read what I write before I send it. I realize this\n> is probably not the right response. First, none of the keys in this\n> architecture are private anyway. I used the wrong terminology here.\n> \n> If each host has a shared AES key with the server, and their key is\n> paired to their service-group, it is irrelevant if the service-group\'s\n> key is shared.  You could even reject requests for unattested origin\n> hosts, regardless of their service-group, based on their individual\n> AES key.\n\nPrecisely :)\n\n> The important factors we have are:\n> \n> 1) Verify the sender\'s message signature\n> 2) Prevent replay attacks\n> \n> We can do #1 with a shared key-per-service, because we know the\n> origin, even if we don\'t know the destination. It does seem to imply\n> that any scheduler, if compromised, could replay messages to other\n> schedulers until key cache timeouts occurred, even if revocation\n> occurred. Unless, of course, a centralized replay-prevention-service\n> to maintain state was deployed...\n\nA compromised scheduler can simply go ahead and send commands to nodes,\nan attacker has no reason to play with replays in this case unless there\nis a specific reason for which a node would reject messages from a\nspecific scheduler but not another.\n\nThis is the reason why I think sharing keys between a single service\ngroup is just fine.\n\n> We can\'t do #2 without maintaining state somewhere. It is easiest and\n> most scalable to maintain state in each endpoint, than centrally for\n> each service group. The matchmaker is what lets us send messages to\n> independent endpoints such that message history can be maintained. A\n> nounce in the message makes them unique. The signature itself is what\n> you cache and lookup against for replays.\n\nYou don\'t even need a nounce, timestamp + source name is already a\nunique combination, assuming the source does not reuse timestamps (same\ncheck you need in place to avoid reusing nonunces)\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1AB0ABE4FEAF40A18400720B847E4B6F@cloudscaling.com>',NULL),('<1366916992.10084.77.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 15:09:52',-14400,'2013-04-25 19:09:52',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 14:42 -0400, Eric Windisch wrote:\n> We do have true concurrency. It might not be used everywhere, but we\n> have it.  \n> \n> You could run multiple copies of nova-scheduler on the same host. They\n> could both generate the same timestamp + source, assuming that source\n> was \'service_name + hostname\'.  The only workaround for that would be\n> to make the source include the PID as well? until/unless we get\n> in-process concurrency, at least. Does the remote system really need\n> to know the PID? That could be a security thread. Perhaps we should\n> hash it? wait, this is getting complicated...\n> \n> Why block everything synchronously on a single source of time or\n> counter when we can simply use a nonce?\n\nThe main reason was to avoid having to store many records on the\nreceiving side. Using a monotonic timestamp you just need to keep around\nthe last received one and if a message with an equal or older timstamp\ncomes around you simply discard it.\n\nIs it possible to receive 2 valid messages from the same source in the\nwrong order through the massage queue ?\n\nIf that is possible I guess using a nonce will be necessary, but I dread\nhaving to keep a dictionary of received packets, search through it every\nsingle time you receive a message, scrub it regularly to prune old\nentries and so on.\n\nI have witnessed how the replay database was cause of various\nperformance issues in the past in libkrb5 and would like to avoid\ncomplex replay detection schemes if possible.\n\nKeep in mind this database would have to be on shared if you really run\nmultiple processes with the same name on the same host as they all have\nto share the replay database, so you need to use shared memory or IPC\nand some sort and locking ... which tends to slow done processing and it\nis usually a blocking operation.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<5752A85C7BC84D4A99025BCD53FF0249@cloudscaling.com>',NULL),('<1366917582.10084.82.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 15:19:42',-14400,'2013-04-25 19:19:42',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 19:55 +0100, David Chadwick wrote:\n> Conventional wisdom is that you should not roll your own security but \n> use tried and trusted mechanisms. So what is wrong with using Kerberos?\n\nNothing wrong, but not something we can get running in the Havana time\nframe I am afraid. I would love to see if people would be amenable to\nusing Kerberos and I can make a proposal on how to integrate it for the\nfuture, but it would require a few things we are missing, including good\nbindings.\nAlso would introduce some C code in the project as we would definitely\nwant to use some DAl modules in the KDC to be able to create our own\ndelegation rules. I\'ve done all this for the FreeIPA project, and it is\nall doable and quite neat, but it will take time and I am not sure\neverybody is comfortable with the dependency.\n\nSo I decided to try with a much simpler scheme first that would require\na lot less time to prototype and test. If it is successful we can keep\nit as a basic system and start discussing whether we want to go all 99\nyards toward something like full fledged kerberos.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51797C3B.20509@kent.ac.uk>',NULL),('<1366920907.10084.132.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 16:15:07',-14400,'2013-04-25 20:15:07',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 19:39 +0000, Joshua Harlow wrote:\n> Except there is concurrency, eventlet just makes it \'appear\' that there\n> isn\'t.\n> \n> Right now any blocking operation will cause a context-switch, think of\n> that as the trigger to cause said context-switch.\n> \n> In regular process schedulers there is just a different trigger that the\n> operating system uses.\n> \n> So to me we already have concurrency (not for simple int operations of\n> course), its just sorta ghetto :-P\n\nWell correct me if I am wrong, but eventlet is a single process, system\nw/o threads, so things may intermix but python calls do not race due to\nthe GIL.\n\nI may be wrong on that, but it was my understanding.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CD9ED3DC.3B075%harlowja@yahoo-inc.com>',NULL),('<1366923103.10084.143.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 16:51:43',-14400,'2013-04-25 20:51:43',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 15:16 -0400, Eric Windisch wrote:\n> One use-case I see this proposal failing to address is with cross-cell\n> and cross-project messaging. \n\nAt the moment it is not directly addressed, but I haven\'t seen\naddressing handling certificate trust and revocation checking in the\npublic key scheme which has the same challenges.\n\n> The cross-cell messaging is a legitimate concern and probably where\n> some of this security is most desperately needed. Your present design\n> seems to require a single, global service to drive communication and\n> authority for all cells.\n\nIf I have to argue on the spot I can tell that cross-cell keys can be\neasily handled through intra key server communication when the 2 peers\nare in different cells.\n\nIf you look at how keys are generated only one peer key is used to do\nderivation, so if the key is not on a specific server all you need is a\ncall to the trusted peer-key server to obtain the necessary keys and\nhand them back to the client.\n\nThis is made up on the spot and will need more consideration but I do\nnot see it as an obstacle, and certainly not incompatible with the\ncurrent scheme, just an additional extension.\n\n> Secondly, cross-project messaging is a concern for the Ceilometer\n> team. This is presently contentious amongst the RPC users and\n> maintainers, and a matter of active discussion.  However, should that\n> we seek to support this, it should be considered. Presently, all\n> projects communicate via AMQP through a single control_exchange.\n> ZeroMQ messaging happen over a unique TCP port per project. The\n> messaging is clearly delineated, split between the projects.\n> \n> In our proposed PKI model, this isn\'t a huge deal, because we can have\n> a keyserver per project, per cell, or per project per cell. There will\n> be devils in the details of implementing it,\n\nAt least as hard as with the shared-secret solution.\n\nYou have the same problem of trust between clients and the key server\nand inter-domain/project/cell/server trust between different key\nservers. \n\n>  surely, but it isn\'t against the architectural design. If\n> communicating to another project or cell, we can make the code reach\n> into the right keyserver.\n\nSame with a shared key solution, why do you think you can\'t there ?\n\n>   However, your proposal requires a tight coupling of peers / services\n> that introduces complexity around scale that is not presently\n> addressed. \n\nI do not see a difference in the complexity, care to share some details\nabout why you think it is more complex ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<6C3B1DA687DE4F0F94B64D5C69DB66EF@cloudscaling.com>',NULL),('<1366923700.10084.151.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 17:01:40',-14400,'2013-04-25 21:01:40',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 15:27 -0400, Eric Windisch wrote:\n> > \n> > The main reason was to avoid having to store many records on the\n> > receiving side. Using a monotonic timestamp you just need to keep around\n> > the last received one and if a message with an equal or older timstamp\n> > comes around you simply discard it.\n> > \n> > Is it possible to receive 2 valid messages from the same source in the\n> > wrong order through the massage queue ?\n> \n> \n> Message are not guaranteed to be in order. First, this is not expected\n> of the RPC abstraction, and secondly, it isn\'t true of the\n> implementations we have. I can\'t speak for Rabbit/Qpid, but I know\n> that ZeroMQ will certainly deliver messages out of order as they\'re\n> sent over separate TCP connections. I suspect the same is probably\n> true of Rabbit/Qpid, at least if you happen to have multiple processes\n> per host (i.e. two processes of \'nova-scheduler\'). \n\nOk, then I will think again about it.\n\n> > If that is possible I guess using a nonce will be necessary, but I dread\n> > having to keep a dictionary of received packets, search through it every\n> > single time you receive a message, scrub it regularly to prune old\n> > entries and so on.\n> \n> Dictionary key lookups are fast. Memory is a bigger concern. You only need to keep signatures, not message contents. There are data structures and patterns that are appropriate for this task that won\'t require active scrubbing.\n> > Keep in mind this database would have to be on shared if you really run\n> > multiple processes with the same name on the same host as they all have\n> > to share the replay database, so you need to use shared memory or IPC\n> > and some sort and locking ... which tends to slow done processing and it\n> > is usually a blocking operation.\n> \n> \n> At least that will be per-host and not per-service. \n\nThe thing is, in order to use a nonce you need to do interprocess\nlocking and keep a table of all the numbers previously used (or use a\ncounter). Unless by nonce, you really mean a \'random\' number.\n\n1. A nonce cannot ever repeat. To guarantee this you have to have a\nsingle source for this number (back to monotonic timestamp and\nserialization, just different output).\n\n2. A random number can repeat but it is very unlikely that will happen\nif you have a good random generator that has uniform distribution. \n\nI think you mean 2, because the chance we get out of the hat 2 identical\nnumbers chosen at random within the same hundredth of a second on the\nsame machine if the numbers are big enough, say 2^64, are very, very\nlow, so we might decide to ignore that it may happen.\n\nHowever, how bad is it is it *does* happen ?\n\n\nIf we really need a *nonce* then we should use a counter that is updated\natomically cross-process.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<F838B75015CA40E0BBEB31B77BF0C855@cloudscaling.com>',NULL),('<1366924826.10084.162.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 17:20:26',-14400,'2013-04-25 21:20:26',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 17:01 -0400, Simo Sorce wrote:\n> On Thu, 2013-04-25 at 15:27 -0400, Eric Windisch wrote: \n> > Message are not guaranteed to be in order. First, this is not expected\n> > of the RPC abstraction, and secondly, it isn\'t true of the\n> > implementations we have. I can\'t speak for Rabbit/Qpid, but I know\n> > that ZeroMQ will certainly deliver messages out of order as they\'re\n> > sent over separate TCP connections. I suspect the same is probably\n> > true of Rabbit/Qpid, at least if you happen to have multiple processes\n> > per host (i.e. two processes of \'nova-scheduler\'). \n> \n> Ok, then I will think again about it.\n\nI thought more about it :-)\n\n> > > If that is possible I guess using a nonce will be necessary, but I dread\n> > > having to keep a dictionary of received packets, search through it every\n> > > single time you receive a message, scrub it regularly to prune old\n> > > entries and so on.\n> > \n> > Dictionary key lookups are fast. Memory is a bigger concern. You only need to keep signatures, not message contents. There are data structures and patterns that are appropriate for this task that won\'t require active scrubbing.\n> > > Keep in mind this database would have to be on shared if you really run\n> > > multiple processes with the same name on the same host as they all have\n> > > to share the replay database, so you need to use shared memory or IPC\n> > > and some sort and locking ... which tends to slow done processing and it\n> > > is usually a blocking operation.\n> > \n> > \n> > At least that will be per-host and not per-service. \n> \n> The thing is, in order to use a nonce you need to do interprocess\n> locking and keep a table of all the numbers previously used (or use a\n> counter). Unless by nonce, you really mean a \'random\' number.\n> \n> 1. A nonce cannot ever repeat. To guarantee this you have to have a\n> single source for this number (back to monotonic timestamp and\n> serialization, just different output).\n> \n> 2. A random number can repeat but it is very unlikely that will happen\n> if you have a good random generator that has uniform distribution. \n> \n> I think you mean 2, because the chance we get out of the hat 2 identical\n> numbers chosen at random within the same hundredth of a second on the\n> same machine if the numbers are big enough, say 2^64, are very, very\n> low, so we might decide to ignore that it may happen.\n> \n> However, how bad is it is it *does* happen ?\n> \n> \n> If we really need a *nonce* then we should use a counter that is updated\n> atomically cross-process.\n\nOk we can actually use a per process counter so that we do not have to\nsynchronize between processes or threads, we just need a big enough\nnumber, say a 64bit unsigned integer and then slice the number space\nequally between each process or thread.\n\nAll we need to do is register a slice each time a new process/thread\nstarts so that the synchronization happens only once at process startup.\n\nBy dividing a 64 bit integer in slices of 32 bits we can have 4 billion\nprocesses running at the same time and each of them can send 400 billion\nmessages per second without generating a conflict (if the timestamp has\nhundredth of second resolution like time.time() has.\n\nI guess this is sufficient, if we can have machines so fast to sign 4\nbillion messages per 1/100s .. well I\'ll be really glad to have this\nproblem :-)\n\nSo I\'ll re-add the nonce and specify it is a 64bit number, the mechanics\nof how multiple processes handle it and the fact it actually should be a\ncounter at implementation are implementation details.\nI will simply specify the nonce must be unique within the same timestamp\ninterval.\n\nSimo.\n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1366923700.10084.151.camel@willson.li.ssimo.org>',NULL),('<1366927028.10084.169.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-25 17:57:08',-14400,'2013-04-25 21:57:08',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Thu, 2013-04-25 at 17:26 -0400, Eric Windisch wrote:\n> >  \n> > 2. A random number can repeat but it is very unlikely that will happen\n> > if you have a good random generator that has uniform distribution.  \n> >  \n> > I think you mean 2, because the chance we get out of the hat 2 identical\n> > numbers chosen at random within the same hundredth of a second on the\n> > same machine if the numbers are big enough, say 2^64, are very, very\n> > low, so we might decide to ignore that it may happen.\n> >  \n> > However, how bad is it is it *does* happen ?\n> I mean the latter and I believe this is sufficient. I believe worst\n> case is that a message is rejected by the endpoint as a potential\n> replay. In theory, we should be pretty resistant to lost messages,\n> especially at the very low rate of occurrence we\'d expect it.\n\nWell actually thinking about it the chance are infinitesimally smaller\nthan I previously thought because if we are going to use the signature\nto check for replays not only the timestamp and nonce must match, but\nthe message being sent must be a repeat and exactly identical to othe\nprevious.\n\nHonestly unless there are condition where it is legit to resend the\nexact same message multiple times we should probably just forget about\nthe nonce, which is why I didn\'t care for it in the first place.\nHowever base don my last formulation we have a good way to avoid\ninterprocess locking too.\n\nSo given a few people requested it, and to account for the weirdest\npossible use of messages where a service decides to send 2 identical\nmessages in rapid succession I will leave the nonce in.\n\n> I gag any time we mention interprocess locking, global counters, or\n> state. I recognize might need to compromise here, especially in regard\n> to multiple services on a remote machine receiving the same message,\n> although I\'d be careful about how we implement that.  The\n> implementation details will be vastly different for AMQP, versus\n> ZeroMQ.\n\nI am not sure this difference will matter from the signing point of\nview.\n\n> For instance, the ZeroMQ driver could do first-pass replay detection\n> in the ZmqProxy, which is a machine-global process. We\'d still want to\n> verify signatures in the consuming services, but as all messages pass\n> through the ZmqProxy, it can outright reject duplicates. (This won\'t\n> stop someone from killing the ZmqProxy and doing a MITM to allow\n> replays - not but outright injection - but if that happens, the server\n> is likely compromised already?)\n\nAre you going to check the signature in ZmqProxy ?\n\n> The AMQP drivers won\'t be able to filter their replays centrally on\n> the host unless it added a per-host consumer and local distribution\n> pattern like we use in ZeroMQ. Without that, we\'d need a local\n> datastore with all the locking issues that brings with it.\n\nI am not sure I am following you here ...\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<BCDF715C93D147FCA36E9E38FE359796@cloudscaling.com>',NULL),('<1366954084.905218716@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 01:28:04',-14400,'2013-04-26 05:28:04',NULL,'[openstack-dev] Should deleted glance images be visible still','\nI think it was to look up image details based of which a given server is running.( And in case the image has been deleted now, still being able to look it up)\n \nI am not sure if we still need that now, with the ability to preserve image info on server.\n \n-----Original Message-----\nFrom: \"Alex Meade\" <alex.meade at rackspace.com>\nSent: Thursday, April 25, 2013 1:42pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] Should deleted glance images be visible still\n\n\n\nIt\'s by design.\n \nYou can see deleted images when doing a show or a list with a filter such as the \"changes-since\" filter. If you do a list with no filters then deleted images should not appear. I can\'t remember all of the logic behind this though, just that there was good reason. Obviously, it had something to do with the need to lookup an image after it was deleted.\n \nThanks for asking though, perhaps we need to make the reasoning more obvious (or get rid of soft deletes) :)\n \n-Alex\n \n-----Original Message-----\nFrom: \"Matthew Sherborne\" <msherborne at gmail.com>\nSent: Thursday, April 25, 2013 6:28am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Should deleted glance images be visible still\n\n\n\n\n\n\n\n\n\nIs it by design that glance shows deleted images ? or is it a bug ? or am I experiencing some kind of caching  ?\n\n\nI\'m testing through the nova client:\n\nAs an end user in nova:\n\n\n1. Create a vm2. nova image-create myvm myimage3. nova image-delete my-uuid4. nova image-show my-uuid\n+----------------------+--------------------------------------+\n | Property             | Value                                |\n+----------------------+--------------------------------------+\n| status               | DELETED                              |\n| updated              | 2013-04-25T10:24:02Z                 |\n | name                 | temp                 s                |\n| created              | 2013-04-25T10:19:09Z                 |\n| minDisk              | 20                                   |\n| progress             | 0                                    |\n | minRam               | 512                                  |\n| OS-EXT-IMG-SIZE:size | 893173760                            |\n| id                   | 1b399542-a4fb-49a0-8130-69969f1175b8 |\n+----------------------+--------------------------------------+\nMany ThanksMatthew Sherborne\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/3df33dd6/attachment.html>\n\n','<1366911742.72075192@apps.rackspace.com>',NULL),('<1366970532.16156.75.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-26 11:02:12',3600,'2013-04-26 10:02:12',NULL,'[openstack-tc] Reddwarf application for incubation','On Thu, 2013-04-25 at 17:31 -0400, Monty Taylor wrote:\n> For me, I think that RedDwarf is a good fit for us, and I see it as an\n> essential part of a cloud offering. I\'m not sure about where it falls in\n> the IaaS/PaaS split, and I have to be honest I don\'t care, because I\n> don\'t think that a user of a cloud ever says \"today I want to use some\n> IaaS!\" \n\nThat\'s where I\'m at too, I think.\n\nTo the point that such services should be based on Heat and that there\nshould be a framework for building similar services - that\'s my instinct\ntoo and if there\'s general agreement on that point, I\'d be wary of\nRedDwarf entering Incubation without progress being made in that\ndirection.\n\nI mean, who knows - if someone came along with a new project to\nimplement such a generic framework, I think we\'d want to incubate *that*\nproject and encourage RedDwarf to port to it. I don\'t see why we should\ndecide now that RedDwarf will be the basis that generic framework.\n\nCheers,\nMark.\n\n\n\n','<5179A0C7.80109@inaugust.com>',NULL),('<1366972142.16156.83.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 11:29:02',3600,'2013-04-26 10:29:02',NULL,'[openstack-dev] [openstack-tc] Splitting the Baremetal driver\n	out of Nova','Hey\n\nOn Thu, 2013-04-25 at 11:57 -0700, Devananda van der Veen wrote:\n> In the Nova \"Baremetal Next Steps\" design session last Thursday, I proposed\n> that we split the baremetal driver out into its own top-level project -\n> this was met with support from everyone in the room. We then discussed the\n> project\'s plans and how such a split should be done. I have written up that\n> proposal in more detail here, and would like to bring this before the TC.\n> \n> https://wiki.openstack.org/wiki/BaremetalSplitRationale\n\nI\'m all for the code being in a separate project - I think this thing\ncould have users outside of Nova.\n\nI did work up an idea for how it could be done during Folsom\ndevelopment, but I actually was thinking of it just being a library:\n\n  https://gist.github.com/markmc/5466295\n\nNot much detail there, but BareMetalConnection/BareMetalNode would be in\nthe library and BareMetalDriver would be the Nova part. I hadn\'t figured\non this being a service with its own REST API, but perhaps that does\nmake sense.\n\nHowever, that does make me wonder whether we\'d see desire to plug\nalternative baremetal provisioning technologies into that API, in the\nsame way we see a desire for alternative backends to the Swift API.\n\nFinally, making this a service (with a yet undefined API) rather than a\nlibrary makes me think the new project should go through an incubation\nperiod, rather than bypassing incubation the way Cinder did.\n\nCheers,\nMark.\n\n\n\n','<CAExZKEo5bdwP6jJRCWQ-cuFu2WEfy6EKNjrrkpqTvufHtOh3cw@mail.gmail.com>',NULL),('<1366972142.16156.83.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-04-26 11:29:02',3600,'2013-04-26 10:29:02',NULL,'[openstack-tc] Splitting the Baremetal driver out of Nova','Hey\n\nOn Thu, 2013-04-25 at 11:57 -0700, Devananda van der Veen wrote:\n> In the Nova \"Baremetal Next Steps\" design session last Thursday, I proposed\n> that we split the baremetal driver out into its own top-level project -\n> this was met with support from everyone in the room. We then discussed the\n> project\'s plans and how such a split should be done. I have written up that\n> proposal in more detail here, and would like to bring this before the TC.\n> \n> https://wiki.openstack.org/wiki/BaremetalSplitRationale\n\nI\'m all for the code being in a separate project - I think this thing\ncould have users outside of Nova.\n\nI did work up an idea for how it could be done during Folsom\ndevelopment, but I actually was thinking of it just being a library:\n\n  https://gist.github.com/markmc/5466295\n\nNot much detail there, but BareMetalConnection/BareMetalNode would be in\nthe library and BareMetalDriver would be the Nova part. I hadn\'t figured\non this being a service with its own REST API, but perhaps that does\nmake sense.\n\nHowever, that does make me wonder whether we\'d see desire to plug\nalternative baremetal provisioning technologies into that API, in the\nsame way we see a desire for alternative backends to the Swift API.\n\nFinally, making this a service (with a yet undefined API) rather than a\nlibrary makes me think the new project should go through an incubation\nperiod, rather than bypassing incubation the way Cinder did.\n\nCheers,\nMark.\n\n\n\n','<CAExZKEo5bdwP6jJRCWQ-cuFu2WEfy6EKNjrrkpqTvufHtOh3cw@mail.gmail.com>',NULL),('<1366993490.10084.375.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 12:24:50',-14400,'2013-04-26 16:24:50',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','TL;DR: improving the crypto exchanges to address the issues raised :-)\n\nRead below.\n\nOn Thu, 2013-04-25 at 16:51 -0400, Simo Sorce wrote:\n> On Thu, 2013-04-25 at 15:16 -0400, Eric Windisch wrote:\n> > One use-case I see this proposal failing to address is with cross-cell\n> > and cross-project messaging. \n> \n> At the moment it is not directly addressed, but I haven\'t seen\n> addressing handling certificate trust and revocation checking in the\n> public key scheme which has the same challenges.\n> \n> > The cross-cell messaging is a legitimate concern and probably where\n> > some of this security is most desperately needed. Your present design\n> > seems to require a single, global service to drive communication and\n> > authority for all cells.\n> \n> If I have to argue on the spot I can tell that cross-cell keys can be\n> easily handled through intra key server communication when the 2 peers\n> are in different cells.\n> \n> If you look at how keys are generated only one peer key is used to do\n> derivation, so if the key is not on a specific server all you need is a\n> call to the trusted peer-key server to obtain the necessary keys and\n> hand them back to the client.\n> \n> This is made up on the spot and will need more consideration but I do\n> not see it as an obstacle, and certainly not incompatible with the\n> current scheme, just an additional extension.\n> \n> > Secondly, cross-project messaging is a concern for the Ceilometer\n> > team. This is presently contentious amongst the RPC users and\n> > maintainers, and a matter of active discussion.  However, should that\n> > we seek to support this, it should be considered. Presently, all\n> > projects communicate via AMQP through a single control_exchange.\n> > ZeroMQ messaging happen over a unique TCP port per project. The\n> > messaging is clearly delineated, split between the projects.\n> > \n> > In our proposed PKI model, this isn\'t a huge deal, because we can have\n> > a keyserver per project, per cell, or per project per cell. There will\n> > be devils in the details of implementing it,\n> \n> At least as hard as with the shared-secret solution.\n> \n> You have the same problem of trust between clients and the key server\n> and inter-domain/project/cell/server trust between different key\n> servers. \n> \n> >  surely, but it isn\'t against the architectural design. If\n> > communicating to another project or cell, we can make the code reach\n> > into the right keyserver.\n> \n> Same with a shared key solution, why do you think you can\'t there ?\n> \n> >   However, your proposal requires a tight coupling of peers / services\n> > that introduces complexity around scale that is not presently\n> > addressed. \n> \n> I do not see a difference in the complexity, care to share some details\n> about why you think it is more complex ?\n\nOk I have been thinking about the issues raised here for the best part\nof the last 12 hours :-)\nAs well as the following one:\n\nOn Thu, 2013-04-25 at 12:52 -0400, Eric Windisch wrote:\n> I\'ve read through this and had a discussion with Simo on IRC for\n> clarity, before posting.\n> \n> It isn\'t a terrible proposal. My biggest concerns are the following,\n> as pertains to signing-only:\n> \n> 1) Keyserver lookups on both sides, not just one-sided, on signing.\n> 2) Practical requirement for the matchmaker for signing, even for\n> AMQP.\n> \n> On the encryption side, PKI has the same requirements, but using\n> slower algorithms. If we accept that the typical use-case will be\n> message signing, then we may prefer to optimize for that, not for\n> encryption. Perhaps we could figure out a middle-ground here with a\n> single sender-side lookup and a token from the keyserver? That might\n> be a slippery slope.\n\n\nAnd I have a few ideas to improve the scheme I proposed.\nI will ignore point 2 above here because I think we can used group keys,\nhowever we can improve on the design and have short lived ones.\n\n\nThis is a quite long description, and I may have made errors (either in\ntranscribing the mechanism or even in the logic!) so if something\ndoesn\'t check out feel absolutely free to point it out, it\'s rather\ncomplex stuff so any question is a good question!\n\n\n\nSo let\'s proceed in order.\n\n1) Double lookups on both sides.\nThis is solvable by simply following a bit more the Needham-Schroeder\nmodel. I initially tried to keep things a simple as possible, but it is\nevident the cost is concerning so let\'s explore a slightly more complex\nmodel that have very desirable properties.\n\nLet\'s look at the communication pattern for sending a message, assuming\nnone of the actors have talked to each other in a while.\n\nS is the key server.\nEx() means Encrypt with key of X\nA wants to send a message to B and sign it\n\nCurrent proposal:\n\n1. A -> S [Please give me SEK for A -> B]\n2. S -> A [Here your SEK]\n3. A -> B [signed message]\n4. B -> S [Please give me SEK for A -> B]\n5. S -> B [Here your SEK]\nnow B validates the message.\n\nWe can cut down steps 4 and 5 by simply sending back in 2 a copy of the\nSEK encrypted with B\'s key so that the pattern becomes:\n\n1. A -> S [Please give me SEK for A -> B]\n2. S -> A [Here your SEK and btw here is Eb(SEK)]\n3. A -> B [signed message, sends along Eb(SEK)]\nnow B takes Eb(SEK), unencrypts it and uses SEK to validate the message\n\nThis cuts down the 2 lookups per pair problem. The communication between\nA and S or between A and B is not more complex, the total number of\nencryption/decryption in the system does not change.\n\nThere are also 3 neat advantages using this amended protocol:\n1. Multiple Key Servers do not need anymore to have a coherent\nRandom.Key shared among them. This makes scaling key servers a little\nbit easier (big win!).\n\n2. It allows us to use a random salt that differs for every single SEK\nrequest (win!) as we do not need to be able to regenerate the same SEK\nin the server anymore (no second query from the receiver). [Even better\nsee 4) below.]\n\n3. It allows us to avoid a potential attack on the receiver side I\nthought about this night (win!) With the current scheme an attacker can\nrun a DoS by which it sends many messages to a receiver pretending each\nmessage comes from a different source. This will cause the client to ask\nfor SEKs from the Key server at a rapid rate consuming key server\nresources needlessly. This is especially problematic because you cannot\nstop receivers from asking as that\'s a totally legitimate operation.\nUsing the new scheme this does not happen anymore as the receiver does\nnot need to ask for anything, and if a compromised host contacts\ndirectly the key server it can be rate limited or filtered and squashed\nas its requests are not legitimate anymore.\n\n\n4. An additional property of this scheme is that because of (2) we do\nnot actually need to use A\'s key and HKDF to derive the SEK, we can\nactually decide to use completely random keys generated on the spot as\nthe SEK pair if we wish. Because we do not need to ever be able to\nregenerate a SEK again. So we gain the fact we have now simplified the\nSEK generation by removing the need to perform Key Derivation.\nWe can still do Key Derivation if we see an advantage to it, but we do\nnot need to.\n\nAlso note that Eb(SEK) is actually more than just encrypting the SEK\ninto a key, the reason is that the receiver must actually be able to\ncheck the SEK used is actually the one for A -> B and not one stolen by\nX and used to send messages X -> B\n\nSo Eb(SEK) includes both A and B names and the expiration time and the\nreceiver will check that they all check out.\nWe have 2 ways to do this:\n1. simple direct comparison of strings taken from message metadata.\n\n2. Use just HKDF expansion (w/o extraction) and generate a Random Key\n(Rkey) on the key server side and send the Rkey encrypted, leaving the\nclient to perform the expansion (which requires the correct names and\nexpiration time to yield the right SEK back).\nThe new way to compute the SEK now becomes:\n\nSEK = HKDF-Expand(Rkey, Svc.A+\'\\x00\'+Svc.B+\'\\x00\'Exp.Time, Le+Ls)\n\n\nI have a slight preference for 2 as it makes impossible to \'forget\' to\nmake this check on the receiver. It also decouples completely using any\nof the shared keys to derive the SEK because is uses totally random keys\nat this point.\nSo we basically reduce computation on the key server side as we just\nneed to get a random value and do not need to perform the HKDF\nextraction.\n\nAlso note that we do not want to send Rkey to the sender but a fully\nformed SEK, this way if the sender is compromised it cannot try to\nimpersonate other services. If we gave the RKey to the sender it would\nbe able to generate a SEK for any source/expiration combination (the\ntarget is fixed and determined by Eb()), so the receiver would have to\ngo back to actually explicitly check the source and expiration time\nprovided do actually match the ones in the message metadata as just\ncomputing the SEK would not be a check in itself anymore.\n\n\n2) Group messages.\nOne of the issues here is how to send messages to a group like\nscheduler.*, by using EB(SEK) the receiver is none the wiser if key B is\na group key, unless the receiver happens to have access to this key.\nhowever there are 2 big issues with group keys:\n1. distribution\n2. re-keying in case one actor in the group is compromised\n\nWe can solve both of these problems with a short lived key.\nBasically each service in a group can be allowed to request the shared\ngroup key from the Key server.\nThe exchange is very similar to the one used to request a SEK.\nWhen a client asks for a Group key, the server performs a few steps:\n1. Verifies the requesting party is actually part of the group it is\nasking a key for. The simplest way to validate this is by verifying the\nservice part of the name of the requester matches the group name and the\ngroup is white listed and allowed to exist.\n2. Checks if a recent valid key is available otherwise generates a new\nkeys and stores it (timestamped with a short expiration time, say a few\nhours)\n3. Sends the key back encrypted with the requester long term key.\nEa(group.key + expiration)\n\nThe receiver caches the group key until the expiration time so that the\nreceiver performs at most one lookup within the expiration time and we\ndo not fall back into a 2 lookups per message scheme.\n\nThis solves distribution and re-keying.\nIf any host is compromised the admin will kill the specific host key and\ncan kill the group key or count on the fact it will expire very shortly.\n\nThe group key is ever only used for *receiving* messages, A request to\nthe key server for a SEK where the source is a group SHOULD be denied.\n\nSo a compromised group key can only fake messages that can be sent to\nthe group but cannot be used to fake messages sent from any other group\nmember to third parties.\n\n\n3) Finally let\'s come to services from different trust zones talking to\neach other. Assuming we have S1 as the key server for A and S2 the key\nserver for B and A wants to send messages to B\n\nThe solution for this is a trust relationship between S1 and S2 (shared\nkey between them). And ACLs that says S1 is allowed to ask any SEK for\ntargets in S2 (and vice versa unless the trust is unidirectional).\n\n\nSo to send a message from A-> B our communication now becomes only\nslightly more complex, but requires no knowledge of this \'trust\' from\neither A or B which is a win as we can seamlessly add this later.\n\n1. A -> S1 [Please give me SEK for A -> B]\n2.1. S1 -> S2 [Please give me SEK for A -> B] (*)\n2.2. S2 -> S1 [Here your SEK and btw here is  Eb(SEK)]\n2.3. S1 -> A [Here your SEK and btw here is Eb(SEK)]\n3. A -> B [signed message, sends along Eb(SEK)]\nnow B takes Eb(SEK), unencrypts it and uses SEK to validate the message\n\nSo the communication now is a little bit slower cross-trust zone but\nworks just fine and transparently to the sender and the receiver.\n\n\n\n(*) Note that S2 does not have A\'s Key for derivation but that is ok see\nsubpoint 4 of the first point in this email, where I say SEK can be\ntotally random. Note also how neither S1 gets to know any secret in zone\nS1nor S2 any secret in zone S2, the only secret really is the shared key\nbetween them that represents the trust.\n\n\nI am going to work over the weekend to change the document to use this\nscheme.\n\nAs always Feedback is *very* welcome.\n\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1366923103.10084.143.camel@willson.li.ssimo.org>',NULL),('<1367006347.10084.411.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 15:59:07',-14400,'2013-04-26 19:59:07',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 11:23 -0700, JIANGANG Zhang wrote:\n> (The previous reply used the wrong subject line - my appologies)\n> \n> \n> Hi Simo,\n> \n> Nice writeup. A couple of comments I have just in case:\n\nHi,\nthank you for your comments!\n\n\n> 1) Regardless public key or shared key based solution, there\'s always\n> a need to store the secret key. The difference is with public key\n> based, only the owner has the private key.\n\nYup.\n> \n> 2) You mentioned that PKI is slow and complex, which is true\n> comparatively but should be ok in this use case. For example, I can do\n> 1034 sign/s and 22829 verify/s on my shabby macbook pro of 2010 and\n> the CPU usage does not seem to be an issue. Compared to the 2 lookups\n> per message in your proposal as you mentioned, it\'s much much more\n> efficient.\n\nAnd how many HMACs can you do ?\n\n> \n> 3) It looks like your key server is like Kerberos.  There\'s probably\n> no point to reinvent the wheel. It should easily adapt to this 1:1 use\n> case as you proposal supported.\n\nI already replied about this, there is however a difference, where it\ncomes to trusts between different realms and most importantly group\nrecipients. They are all solvable so I always keep an option open to\njust move everything over to use Kerberos for most of what is done here.\nThe changes would be minimal so far and would be able to drop in place\neasily. I am just trying to do a simpler implementation now so we can\nhave something decent in Havana that works.\n> \n> 4) Arguably, your proposal supports confidentiality, authorization\n> control (via the shared secret)  and integrity and anti-replay (via\n> timestamp), but it falls short on non-repudiation due to the nature of\n> shared secret. \n\nTrue, but I do not think we need non-repudiation at this stage.\n> \n> 5) The 2 lookups to Key Server per message is way too much with regard\n> to efficiency.\n\nKeep in mind that the 2 lookups are not *per-message* but per-peer-pair.\nIe if you send many messages between A and B in a short timeframe you do\nonly 2 lookups in total, not 2 lookups per message.\n\nAlso read the email I sent today, the number of lookups is down to 1\nnow, just like in the public key case.\n> \n> 6) As mentioned, failure to support 1:m, m:n messaging imposes too\n> much restriction to the overall system.\n\nIndeed this has been mostly addressed though.\n> \n> That said, the following is what I would suggest, which supports 1:1,\n> 1:m and m:n messaging with confidentiality, integrity, authorization,\n> non-repudiation and anti-reply:\n> \n> \n> a) In keystone, for each user add an entry for its public key - only\n> the user itself knows its own private key.\n> \n> \n> b) To support 1:m and m:n, each \"group/role\" of users is provisioned\n> with its group public key - all users of this \"group/role\" is\n> provisioned with the \"group/role\" private key. \n\nHow do you provision these keys ? How do you revoke and replace them ?\n\nIn my recent design I have a very simple method that avoids very\nexpensive provisioning. (still setting up the share key need to be done,\nbut that\'s inevitable)\n> \n> c) All public keys (via x.509 or bare key) are cacheable. Cautious\n> senders and recipients should check regularly but it\'s an overkill to\n> check once per message.\n> \nIndeed, nobody is suggesting to check once per message.\n\n> d) On sending the message, the sender does the following:\n> \n> \n>         d.a) looks up (if not cached or to be cautious - assuming\n>         there\'s no revocation in place) for the recipient\'s or\n>         recipients\' public key. \n>         \n>         \n>         d.b) generate a encryption key (EK) and a signing key (SK)\n>         (not necessary if public key signing is used) and decide its\n>         lifetime (expiration and) \n>         \n>         \n>         d.c) generate a random # of at least 128 bit long,\n>         start/current time (e.g. via gettimeofday), EK and SK\n>         signature, expiration and and sender-id, concatenate and sign\n>         them using its private key\n>         \n>         \n>         d.d) Encrypt the message (together necessary meta data, e.g.\n>         recipient list and lifetime left, sequence counter) using EK,\n>         as BodyE and sign the encrypted BodyE using the sign key as\n>         SIGN.\n>         \n>         \n>         d.e) For each recipient, use its public key to encrypt EK, the\n>         encryption algo,  signing key SK (if needed), signing algo,\n>          and EK/SK expiration), then prepend it with the recipient\'s\n>         public key identifier - e.g. uid.\n>         \n>         \n>         d.f) Send the the outcome of d.c), BodyE and SIGN from d.d)\n>         and d.e) over the all recipients.\n>         \n>         \n>         Note: d.b), d.c) and d.e) are only done once for the duration\n>         of the EK/SK lifetime, so the # of public key calculations\n>         (RSA/EC etc) are minimized. The algos are there for\n>         extensibility and the recipient can reject if it\'s weak.\n\nYes this is very similar to what I described in the document and the\nrecent amendment to the list except you use a public key scheme to\nprotect EK and SK.\nHowever there is a problem here, you assume that either the sender knows\nthe identity of all recipients one by one or use of a shared private key\nfor groups of services.\n\nIf you send to multiple recipients, you need one lookup for each\nrecipient, which becomes very expansive rapidly. and the message size\nalso increases quite rapidly as you have to encrypt the same body\nmultiple times, plus you need to use something like a dict so the\nrecipient can find the correct key, which further increases message\nsize.\n\nIf you send to a shared identity you still have a shared private key\nsystem but your shared key for a group is long term and not short term.\nAlso you need a way to communicate this key to all peers, how do you do\nthat ?\n\n> e) On receiving the message, the recipient doe the following:\n> \n> \n>         e.a) looks up )if not cached or to be cautious - assuming\n>         there\'s no revocation in place)  for the sender\'s public key.\n>         \n>         \n>         e.b) verify sender signature and time window etc if not\n>         previously verified for this \"session\" (a while ago - time\n>         window == expiration).\n>         \n>         \n>         e.c) decrypt the block prepared by d.e), gets the EK, SK,\n>         expiration and verify the expiration. \n>         \n>         \n>         e.d) Using SK to verify signature\n>         \n>         \n>         e.e) Decrypt the message using EK, check against replay via\n>         verifying the expiration and counter/sequence etc.\n>         \n>         \n> If more detailes are needed, please let me know. Note that there may\n> be loose ends given the limited time I have spent on this. \n\nWell I see 2 problems with this scheme.\n\n1. Now you are doing 2 lookups because you have to look up keys on both\nsender and receiver. While my revised scheme needs only one :-)\n\n2. Because you do not have a key server in the mix you also do not have\naccess control there, which means the receiver will have to additionally\nperform access control to decide whether the sending party is allowed to\nsend messages at all, and this is an additional policy lookup from some\ncentral server. It can be cached, but you still need to regularly\nrefresh it in case policies change.\n\nIn my design if the A -> B message is not permitted the sender doesn\'t\neven get a key so no resources are spent at all either on the sender or\non the receiver. So it seem to me my proposal is more efficient on\nvarious levels.\n\nSimo.\n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<SNT142-W55B8BEA921916C16FF15E0B8B70@phx.gbl>',NULL),('<1367006727.10084.417.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 16:05:27',-14400,'2013-04-26 20:05:27',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 13:14 -0400, Eric Windisch wrote:\n> \n> On Friday, April 26, 2013 at 12:24 PM, Simo Sorce wrote:\n> \n> > 1. A -> S [Please give me SEK for A -> B]\n> > 2. S -> A [Here your SEK and btw here is Eb(SEK)]\n> > 3. A -> B [signed message, sends along Eb(SEK)]\n> > now B takes Eb(SEK), unencrypts it and uses SEK to validate the message\n> \n> I was thinking along these same lines.\n> \n> However, the messages from S must be signed and Eb(SEK) must also be\n> signed (using PKI). A question here becomes to do Sign-Encrypt,\n> Encrypt-Sign, or Sign-Encrypt-Sign. This is one of those areas where\n> attempting to roll your own cryptographically secure protocol bites\n> designers/implementors.\n\nPlease see 5.1, all messages are always authenticated.\nPlus see 5.3.3 the SEK is returned encrypted, and the revised spec will\ndo the same of course, I omitted it because it seemed clear from the\ncontext.\n\nThe complete reply will be:\n\nHMAC(metadata, Ea(SEK, Eb(SEK)))\n\nThis is again a simplification of course, I am going to write up the\ndetails of the amended proposal now, so re-read the spec in the weekend\nand it will contain all the details as proposed in the amendment\nhopefully.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<E866B45AE9934CDC84E488C817C261DC@cloudscaling.com>',NULL),('<1367008217.10084.421.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 16:30:17',-14400,'2013-04-26 20:30:17',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 16:09 -0400, Eric Windisch wrote:\n> > \n> > Also read the email I sent today, the number of lookups is down to 1\n> > now, just like in the public key case.\n> > > \n> > \n> \n> Except in the public-key case, the lookup is done on the receiving end\n> for verifications, not on the sender-side. \n> \n> The receiving end tends to scale-out more than the sending end and can\n> more comfortably handle these lookups.\n> \n> The 5 schedulers sending to 1000 compute or volume services shouldn\'t\n> bear the burden of performing lookups if those lookups can be\n> performed on the receiving end. 1000 hosts can more comfortably make\n> queries than 5 hosts can.\n\nExcept for encryption you have to do those lookups on the sender side\ntoo, so you are back to square zero.\n\nAlso doing lookup on the receiver you forgo the possibility of doing\naccess control even before allowing to send any message, requiring\naccess control on the receiving end (potentially a second lookup for the\npolicy).\n\nAlso doing lookups on the receiver end you open up to an attack where a\nmalicious users sends thousands of messages *seemingly* coming from\ndifferent sources causing the receiver to try thousands of requests\nagainst the server to verify a public key that does not exist.\n\nSorry, no silver bullet for you.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<9DB53CDE6A13413BB915D6CD9FD4D238@cloudscaling.com>',NULL),('<1367008947.10084.430.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 16:42:27',-14400,'2013-04-26 20:42:27',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 16:23 -0400, Eric Windisch wrote:\n> > \n> > HMAC(metadata, Ea(SEK, Eb(SEK)))\n> > \n> \n> The problem is that Eb(SEK) isn\'t signed. You sign Ea(), but you can\'t\n> send that to B, because B can\'t decrypt it. Thus, you\'re only sending\n> Eb(SEK).\n> \n> When B receives Eb(SEK), it cannot validate it.  You would need to\n> receive from the keyserver:\n\n> Sa(metadata, Ea(SEK, Sb(Eb(SEK))))\n> \n> Then, you can send to B:  Sb(Eb(SEK)))\n\nSigning Eb(SEK) is unnecessary, as I wrote Eb(SEK) is a *simplification*\nit really is: Eb(RKey, NameA, NameB, Exp.Time)\n\nWhat this means is that The sender cannot replace it with an arbitrary\ntoken, it also cannot be stolen and used by a different service because\non the receiving side the SEK will be created using NameA and NameB and\ntherefore bound to A -> B it also cannot be reused at a later time\nbecause the expiration timestamp is sent as well so older tokens are\ninvalidated.\n\nAnd the very fact Eb() can be decrypted by B is proof this token came\nfrom the Key Sever, because the Key server is the only one that knows\nthe shared key, so signing it does not add anything that I can see.\n\nWhat is the attack that A can perform on B here that A cannot already\ndo ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<01CA1FD9677640E586E174A42623CDA6@cloudscaling.com>',NULL),('<1367011270.10084.440.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 17:21:10',-14400,'2013-04-26 21:21:10',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 16:52 -0400, Eric Windisch wrote:\n> > \n> > Except for encryption you have to do those lookups on the sender\n> side\n> > too, so you are back to square zero.\n> \n> Overall, the encryption situation is not too different in the PKI vs\n> shared-key case.\n> \n> We shouldn\'t disregard improvements in signing performance just\n> because they don\'t apply when encryption is used.  Most I\'ve spoken to\n> consider encryption a nice-to-have than a need-to-have. Signing seems\n> to be the common case.\n\nHow comes that you get to wave away any deficiency in the public-key\nmodel but I have to defend any minor nitpick in my detailed\nproposal ? :-)\n\n> > Also doing lookup on the receiver you forgo the possibility of doing\n> > access control even before allowing to send any message, requiring\n> > access control on the receiving end (potentially a second lookup for\n> the\n> > policy).\n> \n> Potentially as part of the keying, but yes, this is a challenge. \n\nDo you have a solution to propose that we can evaluate ?\n\n> > Also doing lookups on the receiver end you open up to an attack\n> where a\n> > malicious users sends thousands of messages *seemingly* coming from\n> > different sources causing the receiver to try thousands of requests\n> > against the server to verify a public key that does not exist.\n> > \n> \n> You can DoS a message consumer, period. Hell, if you get this far, you\n> can probably DoS the keyservers without too much difficulty.\n\nI think you have not caught the point.\n\nThe problem is not in the DoS per se. The problem is that Actor X can\ncause any other party to hit the key server and the key server have no\nway, on its own, to identify the bogus party, because the bogus party is\nconcealed behind a legitimate service that is simply trying to find out\nwho it is talking to.\n\nIf you try to DoS the Key Server directly that is easy to foil, just use\nrate limiting or even firewall off the offender. But you can\'t do that\nwhen the DoS comes masked through a legitimate party.\n\n>  With your suggestion, we\'ll need a specialized application running on\n> each keyserver.\n\nYeah it is called \'a firewall\', I think that is available as a stock\ncomponent on all the systems we use.\n\n>  That will limit how much you\'ll reasonably scale the keyservers\n> introducing a greater chance of a DoS.\n\nCan you please explain this one ? It makes no sense to me, sorry.\n\n> Overall, DoS of a message receiver by making it query the keyserver\n> too frequently is probably not a concern at all, all things\n> considered.\n\nIn fact that wasn\'t the concern ...\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<5FA82E320186401C96207BCA09EF8ED1@cloudscaling.com>',NULL),('<136702843.4084497.1367326632253.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-04-30 08:57:12',-14400,'2013-04-30 12:57:12',NULL,'[Openstack-docs] What\'s Up Doc? April 25 2013','----- Original Message ----- \n\n> From: \"Lorin Hochstein\" <lorin at nimbisservices.com>\n> To: \"Anne Gentle\" <anne at openstack.org>\n> Cc: \"Glen Campbell\" <glen.campbell at rackspace.com>,\n> openstack-docs at lists.openstack.org\n> Sent: Monday, April 29, 2013 9:31:15 PM\n> Subject: Re: [Openstack-docs] What\'s Up Doc? April 25 2013\n\n> Hi Anne:\n\n> > 5. Doc tools updates:\n> \n\n> > I love hearing that RedHat is testing their tools with our source. A year\n> > or\n> > so ago I learned about Publican at the Open Help Conference and wondered if\n> > we should just re-tool. Would love to hear discussions around that -- we\n> > need the maven plugin for the api.openstack.org/api-ref.html site, but\n> > there\n> > are certainly cases where it would be cool to completely share content and\n> > tooling.\n> \n\n> Could you say a little more about the benefits of using Publican over our\n> existing tooling? In particular, I can imagine how sharing tooling with\n> others would be a benefit (especially if, say, RedHat was using it for their\n> own OpenStack-related docs), but how would it help us share content with\n> others?\n\nWhile we do use Publican for our OpenStack documentation [1] I haven\'t been advocating for a switch in tooling used to build openstack-manuals, nor would I consider myself in any position to do so. At the moment I have been independently working on ensuring that it\'s possible to perform the transformations to build content from openstack-manuals with Publican in an easily repeatable fashion. This has been relatively successful and I am currently tidying up the scripting so that I can put it up on Github and do a full write-up of what was involved.\n\nIt\'s been a valuable experience for me not only in terms of ensuring that we can contribute to and single source from the openstack-manuals project over the coming cycle but also in that I\'ve been able to raise several RFEs/bugs against Publican to make such conversions easier for anyone attempting them in the future. There are definitely places where the two toolchains handle things differently (not necessarily better or worse on either side of the fence) and I think they\'ll become clearer in my write-up and form some useful discussion points particularly when looked over by those of you who have more experience with clouddocs-maven than I do :).\n\nThanks,\n\nSteve\n\n[1] https://access.redhat.com/site/documentation/Red_Hat_OpenStack/\n\n\n','<CADzpNMWS1q1yyhB=9euW+c6ebJSjMFW0k+z5NpJmb+g5LQLdTA@mail.gmail.com>',NULL),('<1367028843.10084.469.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-26 22:14:03',-14400,'2013-04-27 02:14:03',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Fri, 2013-04-26 at 20:11 -0400, Eric Windisch wrote:\n> I meant the keyserver software itself. Your keyserver needs to be a\n> custom built to purpose service. To scale that keyserver, you\'ll need\n> to run more of them. Maybe you can deploy some HTTP proxies for\n> caching. This is additional infrastructure for organizations to\n> support and organizations will only add as much as they can afford to.\n\nI am currently planning to bake this stuff into keystone, but it could\nbe a separate service.\nIn any case I am being careful in the design about making sure it is\neasy to deploy duplicate copies to allow scaling.\n\n> A PKI-based solution could potentially allow a pluggable keysever\n> component that might be scaled in a variety of ways that may leverage\n> existing infrastructure.  DNS, Swift, etc?\n> \n> However, to play devil\'s advocate against myself, if the PKI solution\n> doesn\'t *also* use a custom built-to-purpose service as a keyserver,\n> it complicates the revocation story.\n\nYou cannot handle revocation at all, nor you can check the certificates\nare legit to start with. I don\'t think there is any chance to run a PKI\nbased system without a Central Authority, or some sort of central\nrepository.\n\n> At least, perhaps, with PKI we do open the possibility of a pluggable\n> keyserver mechanism and changing the keyserver solution -- whereas the\n> shared-key solution will need to be much more baked-in and\n> tightly-coupled?\n\nNot sure what this means honestly.\n\nSimo.\n> \n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<4F205276F5FB4F249015DA0FD7061B16@cloudscaling.com>',NULL),('<1367230357.9418.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 11:12:37',3600,'2013-04-29 10:12:37',NULL,'[openstack-dev] Oslo messaging API design','Hey\n\nI\'ve been working on gathering requirements and design ideas for a\nre-design of Oslo\'s RPC and notifications API. The goals are:\n\n  1) A simple and easy to understand RPC abstraction which enables \n     all of the intra project communication patterns we need for\n     OpenStack\n\n  2) It should be possible to implement the RPC abstraction using a \n     variety of messaging transports, not just AMQP or AMQP-like\n\n  3) It should be a stable API with plenty of room for backwards \n     compatible evolution in the future so that we can release it as a \n     standalone library\n\nHere\'s what I have so far:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging\n\nThere\'s plenty to discuss - please try and spawn off separate threads\n(i.e. change the subject) for specific topics rather than addressing the\nentire topic at once.\n\nThanks!\nMark.\n\n\n\n',NULL,NULL),('<1367231071.9418.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 11:24:31',3600,'2013-04-29 10:24:31',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n	port numbers','On Wed, 2013-04-24 at 09:47 -0400, Eric Windisch wrote:\n> Discussing in regard to changing the ZeroMQ ipc directory,\n> and \"allow to cast to other any control exchange\"\n> https://review.openstack.org/27351\n> https://review.openstack.org/27346\n> \n> \n> Basically, the fact that one can deploy each project on a different\n> port number with ZeroMQ is as close an equivalent (and best practice)\n> as one may get to AMQP\'s control_exchange.\n> \n> \n> Even if we add artificial support for control_exchange to the ZeroMQ\n> driver (which is possible), this won\'t do Ceilometer any good if\n> people deploy ZeroMQ on different ports for different projects. Then,\n> you\'ll need to add a port= kwarg to cast/call/notify, in addition to\n> the control_exchange.  In fact, it seems likely that people will want\n> to deploy ZeroMQ on different ports for different projects, and we\n> might want to do this by default, so it *will* be a problem.\n> \n> \n> Perhaps the best solution here is to bake in a numeric representation\n> for each control_exchange? We\'d need to manage these for each\n> core/incubated project to prevent overlap. We already do this for the\n> control_exchange, although as a string there is little cost to doing\n> so. A bit more effort would be needed for tracking port assignments.\n\nThe way I\'m thinking of an exchange is simply that it\'s a namespace\nunder which topics live:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Concepts\n\nThe use case is simply that you should be able to run, say, two\ninstances of heat on the same messaging transport and not have their\ntopics conflict.\n\nI guess you could just prefix topics in the zmq driver with the exchange\nname.\n\nCheers,\nMark.\n\n\n\n\n','<CALnZm-YRzxksULkObm9Wj4r+c_SiO23gG4s1DJebme_2HyqO6g@mail.gmail.com>',NULL),('<1367231768.9418.27.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 11:36:08',3600,'2013-04-29 10:36:08',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Fri, 2013-04-26 at 07:19 -0400, Doug Hellmann wrote:\n> On Friday, April 26, 2013, Julien Danjou wrote:\n> \n> > On Fri, Apr 26 2013, Doug Hellmann wrote:\n> >\n> > > After thinking about this a little more I realized that this doesn\'t\n> > solve\n> > > the problem of allowing one service to talk to another on a separate\n> > > \"exchange.\" If that\'s still something we want to do, we need another\n> > > argument passed to the ConnectionFactory to represent that exchange\n> > > explicitly (I know we need another name, but until we come up with one\n> > I\'ll\n> > > stick with \"exchange\"). The default can come from the config, but callers\n> > > like ceilometer need a way to specify an alternative value.\n> > >\n> > > Do we care if the exchange for a service is not on the same host? Do we\n> > > need to allow users to provide different host/port settings for every\n> > > exchange?\n> >\n> > Yes, that\'s why I thought we would include the control exchange as part\n> > of a connection URL. That would be an abstraction detail for AMQP, where\n> > url would be something like amqp://localhost:3456/mycontrolexchange.\n> \n> \n> I definitely like the idea of using a URL instead of the multiple params we\n> have now, but we will need a way to migrate or otherwise support old\n> configs.\n\nI think we can support the current config format as the more convenient\nway of configuring the default transport that a service uses, but also\nsupport URLs for configuring alternate transports e.g.\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API\n\n> The real challenge, in my mind, is how to know which URL to use for a given\n> connection. If we have several, what values are part of the lookup key?\n\nWell, if this is ceilometer wanting to listen for nova notifications,\nthen you just have a config option in ceilometer like\n\n  nova_notifications_url = kombu://broker//nova/notifications\n\nCheers,\nMark.\n\n\n\n','<CADb+p3TEYDB1DE2JSUS_PssyXd+oTyMwfGUEnkvGKHe9=K6Oug@mail.gmail.com>',NULL),('<1367232427.9418.37.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 11:47:07',3600,'2013-04-29 10:47:07',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Wed, 2013-04-24 at 10:42 -0400, Russell Bryant wrote:\n> On 04/24/2013 10:35 AM, Julien Danjou wrote:\n> > On Wed, Apr 24 2013, Russell Bryant wrote:\n> > \n> >> On 04/24/2013 10:10 AM, Eric Windisch wrote:\n> >>> Sending aside sending, Ceilometer is already doing consumption \n> >>> cross-project, receiving notifications from multiple\n> >>> control_exchanges (at least where amqp is concerned).\n> >> \n> >> Yes, I\'m aware that it\'s consuming notifications from multiple\n> >> projects. The patch in question is about enabling *sending* cross\n> >> project. That\'s what I\'m curious about.\n> > \n> > The use case here is to send metrics to the Ceilometer collector \n> > directly from other projects using openstack.common.rpc. To do\n> > that, you have to send a message? on another control exchange.\n> > \n> > As Eric points out, this is typically the same use case we already\n> > have, just put in the opposite way: not having the Ceilometer\n> > collector joining a bunch of other control exchange (that it may\n> > not know about in advance), but having each project send its meters\n> > to the right place directly (Ceilometer\'s control exchange).\n> \n> That seems like a step backwards to me.  Right now we have a nice\n> generic notification mechanism that can be consumed by ceilometer or\n> something else.  This would be a move toward coupling all projects\n> with ceilometer specifically.  Is there something problematic with\n> consuming notifications as they are today?\n\nYeah, this is an interesting subject. I\'m seeing a few different points:\n\n * RPCs should be for intra project communication\n\n * Notifications should be used for where you want to make event \n   notifications available for third parties\n\n * Just because the RPC notification driver needs to be able to do \n   something, doesn\'t mean we also allow other users of the RPC API to \n   do the same\n\n * A ceilometer notifications driver is part of the ceilometer project,\n   so it sending RPCs back to ceilometer-collector is fine\n\n * There are probably reasonable use cases (like a ceilometer \n   notifications plugin used by nova, but also cells) for a service to\n   connect to another broker and/or use a different exchange. Even \n   without those use cases, though, I think it would be lame for the \n   API to only allow such things to be specified through global \n   configuration ... global configuration should be a convenience \n   default only.\n\nHowever, I\'d really like to understand this ceilometer use case better.\nSee:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Ceilometer_Metering_Messages\n\nCeilometer is sending record_metering_data casts on the \'metering\'\ntopic. The ceilometer-collector service consumes these, but it uses\ncreate_worker() so that it doesn\'t use the default queue to receive\nthem. It\'s like we\'re supporting the existence of third party consumers\nof these messages which would be peers with ceilometer-collector. Maybe\nceilometer-collector consuming them is intended to be optional?\n\nI\'m mostly curious why \'record_metering_data\' isn\'t a notification if we\nwant to support third party consumers of it.\n\nCheers,\nMark.\n\n\n\n','<5177EF72.9080108@redhat.com>',NULL),('<1367233201.9418.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 12:00:01',3600,'2013-04-29 11:00:01',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n\n> We\'ve gone around a few times with ideas for having better driver-parity in\n> the rpc library, so maybe the best thing to do is start by making sure we\n> have all of the requirements lined up. Here\'s a list of some that I came up\n> with based on existing features and my understanding of the shortcomings\n> (numbered for reference, but in no particular order):\n\nThanks for doing this. We definitely need to be stepping back and\nthinking about this at a high level. I\'ve attempted to step a little\nfurther back in my writeup:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging\n\n> 1. Application code using RPC connections must not be required to know to\n> pass different arguments to establish the connection (i.e., the app\n> shouldn\'t have to care if it is using Rabbit or ZMQ).\n\nYes.\n\n> 2. An application must be able to direct a message to a specific peer\n> (i.e., call() with a host specified).\n\ns/direct a message to/invoke a method on/\n\nBut, yes.\n\n> 3. An application must be able to direct a message to a pool of peers\n> (i.e., cast()).\n\n... and for it to be delivered to one of those peers, yes.\n\n> 4. An application must be able to direct a message to a specific peer (or\n> unknown? or both?) using a different rpc endpoint than the originating\n> app\'s default (i.e., calling into cells).\n\nI\'ve tried to separate the notion of a transport from the target. The\nproperties of the target is what\'s known to the application code, the\nproperties of the transport are target specific and come from\nconfiguration.\n\nSo, I\'d say \"an application must be able to invoke a method on a\nspecific target using a supplied transport configuration\".\n\n> 5. An application must be able to listen for messages without interfering\n> with others receiving those same messages (i.e., join_consumer_pool()).\n\nFor notifications, yes - and we should have an API for consuming\nnotifications.\n\nBut for RPC (i.e. create_worker()), I don\'t really see it. See here:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Ceilometer_Metering_Messages\n\nShould ceilometer be using notifications instead of record_metering_data()\n\n> 6. An application must be able to listen for messages sent by any peer, and\n> any service (i.e., specifying a different \"exchange\", though we want to\n> extend this to include a different broker as well).\n\nFor notifications, yes.\n\nFor RPC, this sounds like a \"tap\" - i.e. listen in on RPC exchanges\nbetween peers.\n\n> 7. Any configuration changes must maintain backwards compatibility (i.e.,\n> if we move to URLs instead of N different variables, we still have to\n> support the old format somehow for some time).\n\nYes.\n\nThanks,\nMark.\n\n\n\n','<CADb+p3QYF4d+8-T8NYx_MisBDRUT79FFoSU5r7cmTXceS=yfkA@mail.gmail.com>',NULL),('<1367242581.9418.49.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 14:36:21',3600,'2013-04-29 13:36:21',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 09:19 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 6:36 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Fri, 2013-04-26 at 07:19 -0400, Doug Hellmann wrote:\n>         > On Friday, April 26, 2013, Julien Danjou wrote:\n>         >\n>         > > On Fri, Apr 26 2013, Doug Hellmann wrote:\n>         > >\n>         > > > After thinking about this a little more I realized that this doesn\'t\n>         > > solve\n>         > > > the problem of allowing one service to talk to another on a separate\n>         > > > \"exchange.\" If that\'s still something we want to do, we need another\n>         > > > argument passed to the ConnectionFactory to represent that exchange\n>         > > > explicitly (I know we need another name, but until we come up with one\n>         > > I\'ll\n>         > > > stick with \"exchange\"). The default can come from the config, but callers\n>         > > > like ceilometer need a way to specify an alternative value.\n>         > > >\n>         > > > Do we care if the exchange for a service is not on the same host? Do we\n>         > > > need to allow users to provide different host/port settings for every\n>         > > > exchange?\n>         > >\n>         > > Yes, that\'s why I thought we would include the control exchange as part\n>         > > of a connection URL. That would be an abstraction detail for AMQP, where\n>         > > url would be something like amqp://localhost:3456/mycontrolexchange.\n>         >\n>         >\n>         > I definitely like the idea of using a URL instead of the multiple params we\n>         > have now, but we will need a way to migrate or otherwise support old\n>         > configs.\n>         \n>         \n>         I think we can support the current config format as the more convenient\n>         way of configuring the default transport that a service uses, but also\n>         support URLs for configuring alternate transports e.g.\n>         \n>           https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_Driver_API\n>         \n>         > The real challenge, in my mind, is how to know which URL to use for a given\n>         > connection. If we have several, what values are part of the lookup key?\n>         \n>         \n>         Well, if this is ceilometer wanting to listen for nova notifications,\n>         then you just have a config option in ceilometer like\n>         \n>           nova_notifications_url = kombu://broker//nova/notifications\n> \n> \n> That\'s basically what we have for ceilometer now, although we only specify the exchange.\n> \n> \n> I\'m not sure that works so well for cells, though. Does a parent cell\n> have a configuration setting for each of its children? How does it\n> address the children (do cells have names or unique ids or\n> something?)?\n\nYeah, AFAIK. The cell name to transport configuration goes into the\ndatabase.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3QirhhzYp6uDqhK=9uqL45c_4X23GmhnL4BdZzU+0ZtPg@mail.gmail.com>',NULL),('<1367244361.9418.53.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 15:06:01',3600,'2013-04-29 14:06:01',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 09:28 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 6:47 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n>         \n>          * There are probably reasonable use cases (like a ceilometer\n>            notifications plugin used by nova, but also cells) for a service to\n>            connect to another broker and/or use a different exchange. Even\n>            without those use cases, though, I think it would be lame for the\n>            API to only allow such things to be specified through global\n>            configuration ... global configuration should be a convenience\n>            default only.\n> \n> \n> Agreed. I would prefer it if we could establish an API that didn\'t use\n> the global configuration object at all.\n\nI guess I\'m thinking that this is the only place it\'s used:\n\n    def get_transport_driver(url=None, conf=None):\n        conf = conf or cfg.CONF\n\ni.e. the entry point into the library is to construct a transport\ndriver. If that has optional support for using the global object, I\ndon\'t think it\'s a big deal.\n\nWhen I said \"global configuration\", though, I actually more meant that\nit would be lame if transport configuration could only come from a cfg\nobject - e.g. if ceilometer had to construct a cfg object with the\nconfiguration required to connect to glance notifications.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3Q+Wo3Of==5Bt3cuEVyP97P0rR6fzw06AkubG8zLR+GDQ@mail.gmail.com>',NULL),('<1367245411.9418.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 15:23:31',3600,'2013-04-29 14:23:31',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 09:39 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n>         \n>         > We\'ve gone around a few times with ideas for having better driver-parity in\n>         > the rpc library, so maybe the best thing to do is start by making sure we\n>         > have all of the requirements lined up. Here\'s a list of some that I came up\n>         > with based on existing features and my understanding of the shortcomings\n>         > (numbered for reference, but in no particular order):\n>         \n>         \n>         Thanks for doing this. We definitely need to be stepping back and\n>         thinking about this at a high level. I\'ve attempted to step a little\n>         further back in my writeup:\n>         \n>           https://wiki.openstack.org/wiki/Oslo/Messaging\n>         \n>         > 1. Application code using RPC connections must not be required to know to\n>         > pass different arguments to establish the connection (i.e., the app\n>         > shouldn\'t have to care if it is using Rabbit or ZMQ).\n>         \n>         \n>         Yes.\n>         \n>         > 2. An application must be able to direct a message to a specific peer\n>         > (i.e., call() with a host specified).\n>         \n>         \n>         s/direct a message to/invoke a method on/\n> \n> \n> RPC and notification aren\'t the only usage patterns for messaging. If\n> we\'re going to design a general purpose library, we should not limit\n> ourselves to RPC semantics. RPC can be built on top of messaging, but\n> it has been painful to try to make it work the other way around.\n\nI don\'t think the goal is to design a general purpose library, it\'s to\nclean up the APIs we already have to support our current usage patterns.\nThe library can grow new APIs to support new usage patterns over time.\n\nI really don\'t want to design generic APIs in a vacuum when we have the\nmuch more pressing concern of our current usage patterns. I also don\'t\nwant to unnecessarily restrict what messaging systems could be used to\nsupport our current patterns.\n\n>         But, yes.\n>         \n>         > 3. An application must be able to direct a message to a pool of peers\n>         > (i.e., cast()).\n>         \n>         \n>         ... and for it to be delivered to one of those peers, yes.\n>         \n>         > 4. An application must be able to direct a message to a specific peer (or\n>         > unknown? or both?) using a different rpc endpoint than the originating\n>         > app\'s default (i.e., calling into cells).\n>         \n>         \n>         I\'ve tried to separate the notion of a transport from the target. The\n>         properties of the target is what\'s known to the application code, the\n>         properties of the transport are target specific and come from\n>         configuration.\n>         \n>         So, I\'d say \"an application must be able to invoke a method on a\n>         specific target using a supplied transport configuration\".\n> \n> \n> Something has to know how to map the target to the configuration. What\n> does that, and how much does that code know about the transport?\n\nOk, on the client side:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API\n\nfor the simple case, you\'d have something like:\n\n  rpc_driver = rpc.get_transport_driver()\n\n  base_rpcapi = BaseAPIClient(rpc_driver)\n\n  base_rpcapi.ping(context, \'foo\')\n\nfor the more complex case, you\'d have:\n\n  class MeteringAPIClient(rpc.RPCClient):\n\n      target = rpc.Target(exchange=\'ceilometer\',\n                          topic=\'metering\',\n                          version=\'1.0\')\n\n      def __init__(self, driver):\n          # FIXME: need some way to override with exchange from URL\n  ---\n          \n  rpc_driver = rpc.get_transport_driver(url=\'kombu://broker//ceilometer\')\n\n  metering_rpcapi = MeteringAPIClient(rpc_driver)\n  metering_rpc_api.record_metering_data(...)\n\nThe annoying bit here is the application code should know what the\ndefault exchange is, but there is a use case for it to be overridden by\nconfiguration.\n\n>         > 5. An application must be able to listen for messages without interfering\n>         > with others receiving those same messages (i.e., join_consumer_pool()).\n>         \n>         \n>         For notifications, yes - and we should have an API for consuming\n>         notifications.\n>         \n>         But for RPC (i.e. create_worker()), I don\'t really see it. See here:\n>         \n>           https://wiki.openstack.org/wiki/Oslo/Messaging#Ceilometer_Metering_Messages\n>         \n>         Should ceilometer be using notifications instead of record_metering_data()\n> \n> \n> Probably.\n\nHmm, ok :)\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3QjOVZa0=tZ8RDOgCG4_WgHuQim9=tVukzZzc26pt2AZQ@mail.gmail.com>',NULL),('<1367245591.9418.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 15:26:31',3600,'2013-04-29 14:26:31',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n	port numbers','On Mon, 2013-04-29 at 09:43 -0400, Eric Windisch wrote:\n> > My I\'m thinking of an exchange is simply that it\'s a namespace\n> > under which topics live:\n> > \n> > \n> The discussion we were having was that we should NOT expose the\n> control_exchange in the API unless we also expose the queue connection\n> mechanism. The reason is that the control_exchange is presently a\n> point of clean sharding between projects.\n\nYes, I\'m proposing the concept of \"exchange\" purely as a namespace for\nprojects to keep their topics separated ... and allow multiple instances\nof the project share the same space by allowing the exchange name to be\nuser configurable.\n\n> Each unique value of control_exchange can be safely sharded to a\n> separate broker or, in the case of ZeroMQ, to a separate rpc_zmq_port.\n> This latter point is important because it feeds back into the ipc_dir\n> discussion we had; Projects can have their own IPC directory if they\n> run on their own rpc_zmq_port.  Of course, sharding for RabbitMQ/Qpid\n> might also be useful...\n\nI don\'t think what I\'m saying changes that. You can absolutely put each\nexchange on a separate broker.\n\nCheers,\nMark.\n\n\n\n','<67F495BB7BD34756970A45859A357D09@cloudscaling.com>',NULL),('<1367245776.9418.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 15:29:36',3600,'2013-04-29 14:29:36',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 09:45 -0400, Eric Windisch wrote:\n> > \n> > It was, originally, but create_worker() uses the RPC dispatcher so we had to change. Now that we have join_consumer_pool() in the public API, we could change back. \n> > \n> \n> \n> Is create_worker not used in Ceilometer anymore? This was added for\n> Ceilometer\'s benefit. If it isn\'t used, we might want to deprecate it.\n\nIt is used to listen on the \'metering\' topic ... but I\'m not entirely\nsure why.\n\n        # Set ourselves up as a separate worker for the metering data,                                                                                                                                             \n        # since the default for service is to use create_consumer().                                                                                                                                               \n        self.conn.create_worker(\n            cfg.CONF.metering_topic,\n            rpc_dispatcher.RpcDispatcher([self]),\n            \'ceilometer.collector.\' + cfg.CONF.metering_topic,\n        )\n\nThe best guess I can come up for this is that we want to use a\nnon-default worker pool so that third party listeners can use the\ndefault worker pool.\n\nCheers,\nMark.\n\n\n\n','<F30FAEBEBE3F4F5EBAFD991CA08451CC@cloudscaling.com>',NULL),('<1367249137.9418.91.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 16:25:37',3600,'2013-04-29 15:25:37',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 10:43 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n>         \n>         > We\'ve gone around a few times with ideas for having better driver-parity in\n>         > the rpc library, so maybe the best thing to do is start by making sure we\n>         > have all of the requirements lined up. Here\'s a list of some that I came up\n>         > with based on existing features and my understanding of the shortcomings\n>         > (numbered for reference, but in no particular order):\n>         \n>         \n>         Thanks for doing this. We definitely need to be stepping back and\n>         thinking about this at a high level. I\'ve attempted to step a little\n>         further back in my writeup:\n>         \n>           https://wiki.openstack.org/wiki/Oslo/Messaging\n> \n> \n> A few comments/questions on that:\n\nAll good questions, thanks Doug.\n\n> In the client, it seems like the rpc.Target() should be passed to the\n> RPCClient constructor, rather than specified as a class attribute.\n\nI was seeing the class attribute as being the defaults for method\ninvocations ... to make those defaults be per instance, you could do\nsomething like:\n\n  class BaseAPIClient(rpc.RPCClient):\n\n      def __init__(self, driver,\n                   topic=\'blaa\', version=\'1.0\', namespace=\'baseapi\'):\n          self.target = rpc.Target(topic=topic,\n                                   version=version,\n                                   namespace=namespace)\n\n... but maybe the point here is that we never expect this class to be\nused with a different topic, version or namespace.\n\n>  The target parameters should include the host (or \"peer\" to use\n> Eric\'s terminology), shouldn\'t it?\n\nYes, absolutely:\n\n      def get_backdoor_port(self, context, host):\n          self.call(self.target(version=\'1.1\', host=host),\n                    \'get_backdoor_port\', context)\n\nThe host would be added to the default target parameters at method\ninvocation time.\n\nNote, though, this is about a client specifying one of a pool of\nlistening servers ... it\'s certainly not a peer of a client, and we\'re\nnot talking about peers at the transport level either.\n\n> On the server side, I like separating the dispatcher from the server,\n> but I wonder if the server needs to know about the dispatcher at all?\n> Why not just give the server a single callable, which might be a\n> Dispatcher instance? It isn\'t clear why the dispatcher has start() and\n> stop() methods, either, but maybe that has something to do with this\n> design.\n\nYeah, exactly.\n\nIn BlockingDispatcher, start() would read messages and dispatch them to\nthe API objects we have listening on this topic and stop() would cause\nthat dispatch loop to exit.\n\nIn EventletDispatch, start() would spawn off a greenthread to do the\ndispatching and stop() would cancel the thread.\n\nThat said, this part of the proposal doesn\'t feel very solid yet.\n\n> In web frameworks the decorator for exposing a method is usually named\n> something like \"expose\" so how about rpc.expose instead of rpc.method?\n\nSounds good, updated.\n\n> Is fake_rabbit used for testing? If so, that transport should be its\n> own driver.\n\n>From a quick grep, it looks like it just enables the in-memory RabbitMQ\ntransport. Maybe it should just be a parameter to the kombu transport\ndriver.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3RTJH4jJNmvSC65xJpMsoavNHbNkir0W_wKhFYznsv-vw@mail.gmail.com>',NULL),('<1367250311.9418.102.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 16:45:11',3600,'2013-04-29 15:45:11',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 10:55 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 10:23 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 09:39 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n>         >\n>         >         > We\'ve gone around a few times with ideas for having better driver-parity in\n>         >         > the rpc library, so maybe the best thing to do is start by making sure we\n>         >         > have all of the requirements lined up. Here\'s a list of some that I came up\n>         >         > with based on existing features and my understanding of the shortcomings\n>         >         > (numbered for reference, but in no particular order):\n>         >\n>         >\n>         >         Thanks for doing this. We definitely need to be stepping back and\n>         >         thinking about this at a high level. I\'ve attempted to step a little\n>         >         further back in my writeup:\n>         >\n>         >           https://wiki.openstack.org/wiki/Oslo/Messaging\n>         >\n>         >         > 1. Application code using RPC connections must not be required to know to\n>         >         > pass different arguments to establish the connection (i.e., the app\n>         >         > shouldn\'t have to care if it is using Rabbit or ZMQ).\n>         >\n>         >\n>         >         Yes.\n>         >\n>         >         > 2. An application must be able to direct a message to a specific peer\n>         >         > (i.e., call() with a host specified).\n>         >\n>         >\n>         >         s/direct a message to/invoke a method on/\n>         >\n>         >\n>         > RPC and notification aren\'t the only usage patterns for messaging. If\n>         > we\'re going to design a general purpose library, we should not limit\n>         > ourselves to RPC semantics. RPC can be built on top of messaging, but\n>         > it has been painful to try to make it work the other way around.\n>         \n>         \n>         I don\'t think the goal is to design a general purpose library, it\'s to\n>         clean up the APIs we already have to support our current usage patterns.\n>         The library can grow new APIs to support new usage patterns over time.\n>         \n>         I really don\'t want to design generic APIs in a vacuum when we have the\n>         much more pressing concern of our current usage patterns. I also don\'t\n>         want to unnecessarily restrict what messaging systems could be used to\n>         support our current patterns.\n> \n> \n> You\'ve already, mostly, separated the transport stuff from the RPC\n> semantics. I think that\'s all I was asking for, but I want the way we\n> describe it to not say \"invoke a method on\" but just stick with\n> message delivery. The dispatcher for method invocation is one\n> server-side detail.\n\nI think about it more in terms of the payload - I don\'t want users of\nthe API ever to see this as \"sending a message with \'method\' and \'args\'\nparameters\'\" ... it should be \"invoke a method with the given name and\nargs\".\n\nIf we want to support messaging with alternative or free-form payloads,\nthen we can do that later - right now, we don\'t have a use case for it.\n\n>         >         But, yes.\n>         >\n>         >         > 3. An application must be able to direct a message to a pool of peers\n>         >         > (i.e., cast()).\n>         >\n>         >\n>         >         ... and for it to be delivered to one of those peers, yes.\n>         >\n>         >         > 4. An application must be able to direct a message to a specific peer (or\n>         >         > unknown? or both?) using a different rpc endpoint than the originating\n>         >         > app\'s default (i.e., calling into cells).\n>         >\n>         >\n>         >         I\'ve tried to separate the notion of a transport from the target. The\n>         >         properties of the target is what\'s known to the application code, the\n>         >         properties of the transport are target specific and come from\n>         >         configuration.\n>         >\n>         >         So, I\'d say \"an application must be able to invoke a method on a\n>         >         specific target using a supplied transport configuration\".\n>         >\n>         >\n>         > Something has to know how to map the target to the configuration. What\n>         > does that, and how much does that code know about the transport?\n>         \n>         \n>         Ok, on the client side:\n>         \n>           https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API\n>         \n>         for the simple case, you\'d have something like:\n>         \n>           rpc_driver = rpc.get_transport_driver()\n>         \n>           base_rpcapi = BaseAPIClient(rpc_driver)\n>         \n>           base_rpcapi.ping(context, \'foo\')\n>         \n>         for the more complex case, you\'d have:\n>         \n>           class MeteringAPIClient(rpc.RPCClient):\n>         \n>               target = rpc.Target(exchange=\'ceilometer\',\n>                                   topic=\'metering\',\n>                                   version=\'1.0\')\n>         \n>               def __init__(self, driver):\n>                   # FIXME: need some way to override with exchange from URL\n> \n> \n> Ceilometer knows which exchanges to listen on based on its plugins and\n> configuration (we know to look for the glance notification config\n> option when the glance-related plugins are activated, for example).\n\nRight, and this is relevant to the notifications consumption API.\n\n> Cells will know because they will have some configuration setting(s)\n> per cell they want to talk to in the database.\n\nYes, and this is why I want to support it in the transport URL.\n\n> Are those the only cases we have now? Are they the only cases we\n> anticipate?\n\nWell, we also have the control_exchange config varibale. So we need to\ndefault to control_exchange, but allow the transport driver URL to\noverride it?\n\nThe MeteringAPIClient example I had in mind above was the code for a\nNova notifications plugin - the code runs in Nova, so control_exchange\nwill be \'nova\' but we know the default should be \'ceilometer\' even if it\ngets overridden by the transport URL.\n\n>           ---\n>         \n>           rpc_driver = rpc.get_transport_driver(url=\'kombu://broker//ceilometer\')\n>         \n>           metering_rpcapi = MeteringAPIClient(rpc_driver)\n>           metering_rpc_api.record_metering_data(...)\n>         \n>         The annoying bit here is the application code should know what the\n>         default exchange is, but there is a use case for it to be overridden by\n>         configuration.\n> \n> \n> If the application gets the URL to pass to get_transport_driver() from\n> a config file or the database, does it even need to know there is such\n> a thing as an \"exchange\" any more?\n\nIt needs to know what the default is - i.e. Nova needs to set it to\n\'nova\' process-wide and Ceilometer\'s notification plugin needs it to be\n\'ceilometer\'\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3Sj699=eQkVxAg-OoN-MttPP3th5hnfSGSyM2=zLUD1JA@mail.gmail.com>',NULL),('<1367250596.9418.105.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 16:49:56',3600,'2013-04-29 15:49:56',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 11:00 -0400, Doug Hellmann wrote:\n>On Mon, Apr 29, 2013 at 10:26 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > I don\'t think what I\'m saying changes that. You can absolutely put each\n> > exchange on a separate broker.\n> >\n> \n> It is difficult to do that using the current configuration schema, because\n> there are so many different options that have to be replicated for each\n> broker. So you end up with foo_exchange, foo_host, foo_port, etc. for every\n> service that you want to connect to. For ceilometer we just said that all\n> of the exchanges have to be on the same broker. For cells, I think they\n> reproduce the settings in the database. \n\nBut if we allow all of these options to be specified in a URL,\nceilometer can just have:\n\n  glance_transport = kombu://me:secret at foobar:3232//glance/notifications\n\nrather than just:\n\n  glance_control_exchange = \'glance\'\n\nand can easily support exchanges being on different brokers. Right?\n\nCheers,\nMark.\n\n\n\n','<CADb+p3T1hYkr2C38akRKteLMB460izYqkPRicYw4qB=vKE8KEw@mail.gmail.com>',NULL),('<1367250744.9418.107.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 16:52:24',3600,'2013-04-29 15:52:24',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 11:04 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 10:29 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 09:45 -0400, Eric Windisch wrote:\n>         > >\n>         > > It was, originally, but create_worker() uses the RPC dispatcher so we had to change. Now that we have join_consumer_pool() in the public API, we could change back.\n>         > >\n>         >\n>         >\n>         > Is create_worker not used in Ceilometer anymore? This was added for\n>         > Ceilometer\'s benefit. If it isn\'t used, we might want to deprecate it.\n>         \n>         \n>         It is used to listen on the \'metering\' topic ... but I\'m not entirely\n>         sure why.\n>         \n>                 # Set ourselves up as a separate worker for the metering data,\n>                 # since the default for service is to use create_consumer().\n>                 self.conn.create_worker(\n>                     cfg.CONF.metering_topic,\n>                     rpc_dispatcher.RpcDispatcher([self]),\n>                     \'ceilometer.collector.\' + cfg.CONF.metering_topic,\n>                 )\n>         \n>         The best guess I can come up for this is that we want to use a\n>         non-default worker pool so that third party listeners can use the\n>         default worker pool.\n> \n> \n> If I had written join_consumer_pool() before create_worker() I would\n> never have needed create_worker(). I\'d like to wait for the new rpc\n> API to come out before changing ceilometer, but I think we can assume\n> create_worker() could go away.\n\nI still don\'t understand what was wrong with create_consumer() for this\nuse case, though. Why not just use the default worker pool?\n\nIs it to support 3rd party listeners? If so, they could just add another\npool without us the default pool interfering with them.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3ShFLGWKLkaQq=sWqdMkODY4mN=jGth+kKGUx-O9sU+3A@mail.gmail.com>',NULL),('<1367251490.9418.117.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:04:50',3600,'2013-04-29 16:04:50',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 11:44 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 11:25 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 10:43 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n>         >\n>         >         > We\'ve gone around a few times with ideas for having better driver-parity in\n>         >         > the rpc library, so maybe the best thing to do is start by making sure we\n>         >         > have all of the requirements lined up. Here\'s a list of some that I came up\n>         >         > with based on existing features and my understanding of the shortcomings\n>         >         > (numbered for reference, but in no particular order):\n>         >\n>         >\n>         >         Thanks for doing this. We definitely need to be stepping back and\n>         >         thinking about this at a high level. I\'ve attempted to step a little\n>         >         further back in my writeup:\n>         >\n>         >           https://wiki.openstack.org/wiki/Oslo/Messaging\n>         >\n>         >\n>         > A few comments/questions on that:\n>         \n>         \n>         All good questions, thanks Doug.\n>         \n>         > In the client, it seems like the rpc.Target() should be passed to the\n>         > RPCClient constructor, rather than specified as a class attribute.\n>         \n>         \n>         I was seeing the class attribute as being the defaults for method\n>         invocations ... to make those defaults be per instance, you could do\n>         something like:\n>         \n>           class BaseAPIClient(rpc.RPCClient):\n>         \n>               def __init__(self, driver,\n>                            topic=\'blaa\', version=\'1.0\', namespace=\'baseapi\'):\n>                   self.target = rpc.Target(topic=topic,\n>                                            version=version,\n>                                            namespace=namespace)\n>         \n>         ... but maybe the point here is that we never expect this class to be\n>         used with a different topic, version or namespace.\n> \n> \n> Right, I see all of those settings as part of defining where the\n> messages sent by the client should be going. I like the idea of\n> encapsulating them in a Topic which is either passed to the base class\n> or a required property (if BaseAPIClient is an abstract base class,\n> for example).\n\nSo, this Target term is supposed to be exactly \"where the messages\nshould be going\" ... i.e. (exchange, topic, host, fanout, namespace,\nversion) are the routing attributes that the client application is aware\nof ... not just the topic.\n\n>         >  The target parameters should include the host (or \"peer\" to\n>         use\n>         > Eric\'s terminology), shouldn\'t it?\n>         \n>         \n>         Yes, absolutely:\n>         \n>               def get_backdoor_port(self, context, host):\n>                   self.call(self.target(version=\'1.1\', host=host),\n>                             \'get_backdoor_port\', context)\n>         \n>         The host would be added to the default target parameters at\n>         method\n>         invocation time.\n> \n> \n> Ah, no, that\'s not what I meant. I meant that the host should be\n> specified when the client is constructed. Maybe that makes it too\n> inconvenient to use given our existing patterns?\n\nYeah, we (well, I\'m thinking of Nova) typically have one instance of\nthis client proxy class which will invoke methods by default on e.g.\n\n  (exchange=\'nova\', topic=\'compute\', namespace=\'baseapi\', version=\'1.1\')\n\nbut individual methods can take a host parameter and invoke the method\non that host specifically.\n\nI guess you could have choose to have a client object per destination\nhost so long as the client constructor accepted a host parameter.\n\n>         Note, though, this is about a client specifying one of a pool\n>         of\n>         listening servers ... it\'s certainly not a peer of a client,\n>         and we\'re\n>         not talking about peers at the transport level either.\n> \n> \n> Yeah, we still need to figure out what to call that. \"Server\" is\n> heavily overloaded, so Eric suggested \"peer\" as the name of the remote\n> thing we\'re talking to.\n\nOh, a peer at transport level, you mean? I\'m not sure it makes sense to\ntalk about it generically ... I mean, the only thing that\'s really\nimportant to describe at the transport level with AMQP transport drivers\nis the broker.\n\n>         > On the server side, I like separating the dispatcher from\n>         the server,\n>         > but I wonder if the server needs to know about the\n>         dispatcher at all?\n>         > Why not just give the server a single callable, which might\n>         be a\n>         > Dispatcher instance? It isn\'t clear why the dispatcher has\n>         start() and\n>         > stop() methods, either, but maybe that has something to do\n>         with this\n>         > design.\n>         \n>         \n>         Yeah, exactly.\n>         \n>         In BlockingDispatcher, start() would read messages and\n>         dispatch them to\n>         the API objects we have listening on this topic and stop()\n>         would cause\n>         that dispatch loop to exit.\n>         \n>         In EventletDispatch, start() would spawn off a greenthread to\n>         do the\n>         dispatching and stop() would cancel the thread.\n>         \n>         That said, this part of the proposal doesn\'t feel very solid\n>         yet.\n> \n> \n> \n> Listening in a loop feels like a responsibility of the Service, not\n> the dispatcher. The Dispatcher is both routing messages and\n> (potentially) starting tasks now. Would it be cleaner to add another\n> class that knows how to start and stop tasks, and let the dispatcher\n> just use that? It would avoid permutations like EventletRPCDispatcher\n> and EventletNotificationDispatcher. We would just have an\n> RPCDispatcher that knows how to look up a method from a message and a\n> NotificationDispatcher that looks up a method from a notification\n> event type. They would both use an EventletTaskManager,\n> BlockingTaskManager, or even implementations based on threads or\n> multiprocessing.\n\nSounds reasonable to me ... want to replace my proposal with that in the\nwiki?\n\n> I don\'t see anything in the current dispatcher that looks like it is\n> starting an eventlet task, though. Is that happening somewhere else,\n> or do the individual methods deal with it themselves?\n\nIt\'s the consume_in_thread() method on the connection.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3RwM6=OAev6RgPJ8=DfCa+RDFZtxexxqL7LsTAViB1QYg@mail.gmail.com>',NULL),('<1367252215.9418.127.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:16:55',3600,'2013-04-29 16:16:55',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 11:52 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 11:45 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 10:55 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Mon, Apr 29, 2013 at 10:23 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Mon, 2013-04-29 at 09:39 -0400, Doug Hellmann wrote:\n\n>         >         >         > 4. An application must be able to direct a message to a specific peer (or\n>         >         >         > unknown? or both?) using a different rpc endpoint than the originating\n>         >         >         > app\'s default (i.e., calling into cells).\n>         >         >\n>         >         >\n>         >         >         I\'ve tried to separate the notion of a transport from the target. The\n>         >         >         properties of the target is what\'s known to the application code, the\n>         >         >         properties of the transport are target specific and come from\n>         >         >         configuration.\n>         >         >\n>         >         >         So, I\'d say \"an application must be able to invoke a method on a\n>         >         >         specific target using a supplied transport configuration\".\n>         >         >\n>         >         >\n>         >         > Something has to know how to map the target to the configuration. What\n>         >         > does that, and how much does that code know about the transport?\n>         >\n>         >\n>         >         Ok, on the client side:\n>         >\n>         >           https://wiki.openstack.org/wiki/Oslo/Messaging#Client_Side_API\n>         >\n>         >         for the simple case, you\'d have something like:\n>         >\n>         >           rpc_driver = rpc.get_transport_driver()\n>         >\n>         >           base_rpcapi = BaseAPIClient(rpc_driver)\n>         >\n>         >           base_rpcapi.ping(context, \'foo\')\n>         >\n>         >         for the more complex case, you\'d have:\n>         >\n>         >           class MeteringAPIClient(rpc.RPCClient):\n>         >\n>         >               target = rpc.Target(exchange=\'ceilometer\',\n>         >                                   topic=\'metering\',\n>         >                                   version=\'1.0\')\n>         >\n>         >               def __init__(self, driver):\n>         >                   # FIXME: need some way to override with exchange from URL\n>         >\n>         >\n>         > Ceilometer knows which exchanges to listen on based on its plugins and\n>         > configuration (we know to look for the glance notification config\n>         > option when the glance-related plugins are activated, for example).\n>         \n>         \n>         Right, and this is relevant to the notifications consumption API.\n>         \n>         > Cells will know because they will have some configuration setting(s)\n>         > per cell they want to talk to in the database.\n>         \n>         \n>         Yes, and this is why I want to support it in the transport URL.\n> \n> \n> Right. What I\'d like to do is move entirely to URLs, with a\n> backwards-compatibility layer for getting the default URL from the\n> config settings if there is no URL value set. So if the user sets\n> rpc_broker_url, we use that by default. If they don\'t, we combine the\n> values of the existing driver options to make a URL and then use that.\n\nYeah, but I\'m not sure I\'d ever remove this layer - it is very\nconvenient to tell people they just need to set qpid_hostname in\nnova.conf for the most straightforward scenariou.\n\nI can imagine us having e.g.\n\n  [rpc]\n  # Full transport URL, the default for qpid is below but you shouldn\'t need to change this\n  #transport_url=qpid+$qpid_protocol://$qpid_username:$qpid_password@$qpid_hostname:$qpid_port//$control_exchange?nodelay=$qpid_tcp_nodelay\n\n  control_exchange=nova\n\n  [qpid]\n  hostname=localhost\n  port=5672\n  username=\n  password=\n\nWhere this gets tricky is the clustered broker setup - right now, you\njust need to set qpid_hosts to a list of hostnames. To make it work with\nthis setup, we\'d need cfg to have a crazy interpolation scheme where\ne.g.\n\n  foo=foo:$bar\n  bar=blaa,foobar\n\nthen referencing foo returns [foo:blaa, foo:foobar]\n\n>         > Are those the only cases we have now? Are they the only cases we\n>         > anticipate?\n>         \n>         \n>         Well, we also have the control_exchange config varibale. So we need to\n>         default to control_exchange, but allow the transport driver URL to\n>         override it?\n>         \n>         The MeteringAPIClient example I had in mind above was the code for a\n>         Nova notifications plugin - the code runs in Nova, so control_exchange\n>         will be \'nova\' but we know the default should be \'ceilometer\' even if it\n>         gets overridden by the transport URL.\n> \n> \n> I thought the ceilometer notifier would instantiate its own RPCClient,\n> using its own configuration option to set the transport stuff up. The\n> plugin won\'t even look at nova\'s \"global\" settings for RPC.\n\nYes. But it\'s nice to know that \'ceilometer\' is the default exchange, so\nwe can use that if the user doesn\'t specify it in the URL they supply\nfor connecting to ceilometer. We know that \'ceilometer\' is a reasonable\ndefault.\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3SmNHDAjL-_UMGYypjfg1KV=edGXL8AujpW034QNBtRMQ@mail.gmail.com>',NULL),('<1367252327.9418.128.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:18:47',3600,'2013-04-29 16:18:47',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 12:00 -0400, Eric Windisch wrote:\n> > > \n> > > But if we allow all of these options to be specified in a URL,\n> > > ceilometer can just have:\n> > > \n> > > glance_transport = kombu://me:secret at foobar:3232//glance/notifications\n> > > \n> > > rather than just:\n> > > \n> > > glance_control_exchange = \'glance\'\n> > > \n> > > and can easily support exchanges being on different brokers. Right?\n> > \n> > Yes, please! :-)\n> > \n> \n> +1 \n> \n> As long as this won\'t lead to someone hard-coding the scheme.\n> \n> I think the host portion would actually be the *listening* address /\n> interface for ZeroMQ, which might be odd?\n\nI guess the semantics of the URL are transport specific, so they can be\nas odd as you like. Alternatively, just make it a query parameter.\n\nCheers,\nMark.\n\n\n\n','<1CAC6196C27B43CB9D16E5D97F1856CF@cloudscaling.com>',NULL),('<1367252381.9418.129.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:19:41',3600,'2013-04-29 16:19:41',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 12:04 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 11:52 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 11:04 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Mon, Apr 29, 2013 at 10:29 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Mon, 2013-04-29 at 09:45 -0400, Eric Windisch wrote:\n>         >         > >\n>         >         > > It was, originally, but create_worker() uses the RPC dispatcher so we had to change. Now that we have join_consumer_pool() in the public API, we could change back.\n>         >         > >\n>         >         >\n>         >         >\n>         >         > Is create_worker not used in Ceilometer anymore? This was added for\n>         >         > Ceilometer\'s benefit. If it isn\'t used, we might want to deprecate it.\n>         >\n>         >\n>         >         It is used to listen on the \'metering\' topic ... but I\'m not entirely\n>         >         sure why.\n>         >\n>         >                 # Set ourselves up as a separate worker for the metering data,\n>         >                 # since the default for service is to use create_consumer().\n>         >                 self.conn.create_worker(\n>         >                     cfg.CONF.metering_topic,\n>         >                     rpc_dispatcher.RpcDispatcher([self]),\n>         >                     \'ceilometer.collector.\' + cfg.CONF.metering_topic,\n>         >                 )\n>         >\n>         >         The best guess I can come up for this is that we want to use a\n>         >         non-default worker pool so that third party listeners can use the\n>         >         default worker pool.\n>         >\n>         >\n>         > If I had written join_consumer_pool() before create_worker() I would\n>         > never have needed create_worker(). I\'d like to wait for the new rpc\n>         > API to come out before changing ceilometer, but I think we can assume\n>         > create_worker() could go away.\n>         \n>         \n>         I still don\'t understand what was wrong with create_consumer() for this\n>         use case, though. Why not just use the default worker pool? \n>         \n>         Is it to support 3rd party listeners? If so, they could just add another\n>         pool without us the default pool interfering with them.\n> \n> \n> I frankly don\'t remember. It\'s possible that I thought we might want\n> some other RPC mechanism where we *wouldn\'t* want the third party\n> listeners getting involved, so I was saving the \'ceilometer\' worker\n> pool name for something that just never materialized. It\'s also\n> possible that I just thought cast() was point-to-point and we would\n> have to know the identity of the recipient in the sender, so I didn\'t\n> think create_consumer() would work at all.\n> \n> \n> Suffice to say, I am reasonably certain that notifications and\n> join_consumer_pool() will take care of ceilometer\'s current use cases,\n> so we could move to the equivalent of that in the new RPC API and get\n> rid of create_worker().\n\nGreat!\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3QK00GwZa1S1MntMs+T1tJHEFxwHs-N=3gXD8O6y_5EvA@mail.gmail.com>',NULL),('<1367252876.9418.134.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:27:56',3600,'2013-04-29 16:27:56',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 12:12 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, Apr 29, 2013 at 12:04 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 11:44 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Mon, Apr 29, 2013 at 11:25 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Mon, 2013-04-29 at 10:43 -0400, Doug Hellmann wrote:\n>         >         >\n>         >         >\n>         >         >\n>         >         > On Mon, Apr 29, 2013 at 7:00 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         >         On Fri, 2013-04-26 at 15:18 -0400, Doug Hellmann wrote:\n\n\n>         >         Note, though, this is about a client specifying one of a pool\n>         >         of\n>         >         listening servers ... it\'s certainly not a peer of a client,\n>         >         and we\'re\n>         >         not talking about peers at the transport level either.\n>         >\n>         >\n>         > Yeah, we still need to figure out what to call that. \"Server\" is\n>         > heavily overloaded, so Eric suggested \"peer\" as the name of the remote\n>         > thing we\'re talking to.\n>         \n>         \n>         Oh, a peer at transport level, you mean? I\'m not sure it makes sense to\n>         talk about it generically ... I mean, the only thing that\'s really\n>         important to describe at the transport level with AMQP transport drivers\n>         is the broker.\n> \n> \n> On the side sending the message we need to know the host where the\n> broker is and the host where the server we really want to talk to is\n> (the OpenStack service that is going to receive the call and respond\n> to it). Instead of calling both of those \"host\" Eric suggested that we\n> call the latter \"peer\". I don\'t care what we call it, but \"host\" isn\'t\n> sufficiently descriptive, IMO.\n\nOk, fair point. This is the Target::host property currently. I\'d just\nrename that to Target::server. That reinforces that that Target property\ndoesn\'t have any relevance on the server side of the API.\n\n>         \n>         > I don\'t see anything in the current dispatcher that looks like it is\n>         > starting an eventlet task, though. Is that happening somewhere else,\n>         > or do the individual methods deal with it themselves?\n>         \n>         \n>         It\'s the consume_in_thread() method on the connection.\n> \n> \n> It looks like that is dealing with the reads. How do you envision\n> moving that up the stack, and out of the driver?\n\nYou need a generic way of saying \"spawn a thread to read requests and\ndispatch them as invocations on one of these objects\" or \"block this\nthread to read requests and dispatch them as invocations on one of these\nobjects\".\n\nCheers,\nMark.\n\n\n\n\n','<CADb+p3Rtmkb0SUBa6ZtiTMG-1FT-Y83cwbJjERKszYw=9Ku1Mw@mail.gmail.com>',NULL),('<1367256856-sup-1367@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 10:50:22',-25200,'2013-04-29 17:50:22',NULL,'[openstack-dev] [Heat] A concrete proposal for Heat Providers','Excerpts from Zane Bitter\'s message of 2013-04-26 10:41:25 -0700:\n> On 26/04/13 09:39, Thomas Spatzier wrote:\n> > So if I use multiple nested stacks with each one\n> > deploying a couple of VMs, will I end up with the sum of VMs that all the\n> > stacks create? Or will it be possible to, for example, please Tomcat\n> > defined in one Stack on the same VM as MySQL defined in another Stack? I\n> > think it should be possible to have means for defining collocation or\n> > anti-collocation kinds of constraints.\n> \n> Heat as it exists now manages resources that map more or less directly \n> to objects you can manipulate with the OpenStack APIs. Nova Servers, \n> Swift Buckets, Quantum Networks, &c. The software that runs on an \n> instance is not modelled in the template; it\'s just data that is passed \n> to Nova when a server is created.\n> \n> I\'m struggling to understand why you would want Tomcat from one stack \n> co-located with MySQL from another stack (which implies a completely \n> different application)... isn\'t the popularity of virtualisation \n> entirely due to people _not_ wanting to have to do that? Can you \n> elaborate on the use case a little more here?\n> \n\nIf we have a flavor that fits every use case, then yes, combining work\nloads into VMs is somewhat counter-productive.\n\nHowever, consider the baremetal use case, where we may have a rack of 40\nidentical servers, all powerful enough to handle the most demanding of\nour applications, but also far too powerful to handle one of them. I am\nactually running into this right now while trying to write CFN templates\nfor OpenStack on OpenStack.\n\nThe Heat API services, for instance, are very lightweight. But keystone\ncan be very taxing on memory and CPU. I\'d like to be able to group all\nof the light weight services together inside one \"server\". At the same\ntime, I may want to be able to split them out.\n\nThis applies to the virt use case as well. As has already been stated,\nthere are optimization reasons to run two apps on the same VM. There\nis also a cost issue. A smaller testing cloud may not be able to give\ndevelopers all of the VMs that production requires, and so people will\nwant to co-locate things together.\n\nSo I think the message here is that there are two concepts that should be\nexpressable separately:\n\n* I have app X, which needs informational bits a,b, and c, from other\nparts of my stack.\n\n* I want to run app X on a compute resource with properties y and z.\n\nSo, it would be useful if the DSL is able to express things things\nseparately.\n\nAs another data point, the juju project still struggles with this concept,\nand it has been a real sticking point for a lot of users to not be able\nto assemble their apps separate from their resources.\n\n\n','<517ABC45.6040703@redhat.com>',NULL),('<1367257296.9418.138.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 18:41:36',3600,'2013-04-29 17:41:36',NULL,'[openstack-dev] [OSLO][RPC] AMQP / ZeroMQ control_exchange vs\n port numbers','On Mon, 2013-04-29 at 12:34 -0400, Doug Hellmann wrote:\n> > Where this gets tricky is the clustered broker setup - right now, you\n> > just need to set qpid_hosts to a list of hostnames. To make it work with\n> > this setup, we\'d need cfg to have a crazy interpolation scheme where\n> > e.g.\n> >\n> >   foo=foo:$bar\n> >   bar=blaa,foobar\n> \n> \n> > then referencing foo returns [foo:blaa, foo:foobar]\n> >\n> \n> Is clustering by telling the client about multiple hosts \"standard\" or is\n> that just something qpid does?\n\nKombu/RabbitMQ does it too.\n\nCheers,\nMark.\n\n\n\n','<CADb+p3R2-h2rpXcmjL-bVtuB=Bxt3ce-LZSC6UUQFY+15HmqBA@mail.gmail.com>',NULL),('<1367270668.98062100@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-29 17:24:28',-14400,'2013-04-29 21:24:28',NULL,'[openstack-dev] Qonos and Convection - merge projects?','\nJust want to let you know that QonoS is still being actively developed by our team at Rackspace.\nIt\'s a service that is the basis for our proposed Nova Scheduled Images extension, which is nearing completion.\nOther than the code (https://github.com/rackspace-titan/qonos), here\'s some basic docs on QonoS:\n https://wiki.openstack.org/wiki/Scheduled-images-service\nand the Nova extension that uses it:\n https://wiki.openstack.org/wiki/Nova-scheduled-images-extension\n\nThe main goal of Qonos is to act as a distributed and scalable Cron service that can provide basic job error recovery. We are definitely interested in how Qonos can play a role in other parts of OpenStack.\n\nIt seems that the duties of Qonos and Convection only overlap in one area, job execution. atm Qonos has it\'s own way of executing a task but it seems like in the future it could make sense for Qonos to utilize a system like Convection to perform the work. Currently, Qonos performs this work ad hoc and we would like to move away from that model and a system like Convection makes a lot of sense there.\n\nAs we near completion of the scheduled images blueprint, Qonos should fall further into the sight of the OpenStack community.\n\n-Alex\n \n-----Original Message-----\nFrom: \"Endre Karlson\" <endre.karlson at gmail.com>\nSent: Friday, April 26, 2013 2:23am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Qonos and Convection - merge projects?\n\n\n\nHi, I saw that there is a new Task system proposed:\n[https://wiki.openstack.org/wiki/Convection] https://wiki.openstack.org/wiki/Convection\nWoud it be possible to have this effort joined with the Qonos project from the RAX Titan team?\n[https://github.com/rackspace-titan/qonos] https://github.com/rackspace-titan/qonos\nEndre.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130429/41ea8de4/attachment.html>\n\n','<CAFxO1NQ9mDndSpjWnZUs5DqX4=v3yoCegUSyHjo2Knj0sk08jA@mail.gmail.com>',NULL),('<1367311469.611314600@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 04:44:29',-14400,'2013-04-30 08:44:29',NULL,'[openstack-dev] [Glance] Proposal to add John Bresnahan to\n	Glance Core','\n+1 . John for core!\n \n-----Original Message-----\nFrom: \"Mark Washenberger\" <mark.washenberger at markwash.net>\nSent: Tuesday, April 30, 2013 1:42am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Glance] Proposal to add John Bresnahan to Glance Core\n\n\n\nHi folks,\nI am proposing we add John Bresnahan (jbresnah) to the glance-core team.\n[https://review.openstack.org/#/dashboard/6493] https://review.openstack.org/#/dashboard/6493\nSince recently joining the OpenStack scene, John has made significant contributions to Glance, including valuable feedback on reviews and key fixes to improve the stability and performance of our test suite.\nPlease respond with comments, +1s, or objections within one week.\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/7cc32b36/attachment.html>\n\n','<CAJyP2C-k2-Wg6m5eEt+9iLnzP9kVqXFhieZVQxCrmQK9O3mSsA@mail.gmail.com>',NULL),('<1367319049.9418.181.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 11:50:49',3600,'2013-04-30 10:50:49',NULL,'[openstack-dev] Continuous deployment - significant process\n change','On Tue, 2013-04-30 at 09:04 +1200, Robert Collins wrote:\n>  * Land features disabled by default. Such disabled features are\n> experimental and we don\'t need to be so careful - we can in fact\n> remove them entirely if they turn out to be bad idea - when they\n> become supported (individual teams can define this we think) they\n> can\'t be broken again though: they are now part of the product. \n\nI\'d agree with the negative reactions to this as a blanket statement,\nbut I\'m fine with it as one of a menu of options reviewers have when\nthey a large change is proposed and they want to have it land in a way\nthat has an acceptable level of risk for existing deployments.\n\nYou list another option - breaking the change down into smaller pieces.\nAnother is to give it more soak time out of tree (effectively your \"no\ncramming\", I guess). Another is to require additional tests. Another is\nto have the feature not impact existing functionality at all (like\nglance v2 API, cells, GCE API, the baremetal driver).\n\nI think nova-core has a reasonably good handle on this, but codifying\nthis menu of options would help people submitting patches and reviewers\non other projects.\n\nFor me, the negative reaction is about giving a license to merge crappy\nunfinished code as long it\'s disabled by default. In reality, the\n\"disabled by default\" approach is only a good idea if the feature is\npretty testable and if you\'re likely to get people to actually to go the\nbother of enabling it and testing it. What we don\'t want is a feature\nwhich is half-implemented, broken, nobody cares about it, those who do\ntry it write it off for all time so always want an option to disable it\nand it never quite gets solid enough to enable by default.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ3g5xQs8ZXMDJL7w6++qMATzGKBnOd+sQCO0U8YWRTzuw@mail.gmail.com>',NULL),('<1367319809.9418.189.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 12:03:29',3600,'2013-04-30 11:03:29',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','Hi Simo,\n\nOn Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> Hello list,\n> at the Summit we had a very interesting and productive discussion about\n> Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> \n> I would like to present a proposal that uses symmetric keys and a\n> central key server to address the problem:\n> \n> https://wiki.openstack.org/wiki/MessageSecurity\n> \n> I would really like to get feedback on the proposal, especially if there\n> are corner cases I have not considered.\n\nI admit I haven\'t spent much time considering all aspects of this, but\nfrom a high level I like the idea and your diligence.\n\nI\'m working on a proposal for a redesign of the messaging API:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging\n\nI don\'t think this will affect your design in any way, and I don\'t think\nyour proposal changes the API design ... so that\'s all goodness.\n\nOne thing I\'ve just realized we haven\'t taken into account is\nnotifications. There\'s probably a lot of value (to ceilometer at least,\nI\'d imagine) in using public-key encryption to sign those messages since\nthey are being broadcast to the world and there\'s no concept of the\nsender knowing who the message is being sent to.\n\nMaybe solving the notification signing issue is orthogonal to RPC\nsigning and encryption, but had you any thoughts on it?\n\nCheers,\nMark.\n\n\n\n','<1366893429.7239.214.camel@willson.li.ssimo.org>',NULL),('<1367324879.10084.514.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 08:27:59',-14400,'2013-04-30 12:27:59',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> Hi Simo,\n> \n> On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > Hello list,\n> > at the Summit we had a very interesting and productive discussion about\n> > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > \n> > I would like to present a proposal that uses symmetric keys and a\n> > central key server to address the problem:\n> > \n> > https://wiki.openstack.org/wiki/MessageSecurity\n> > \n> > I would really like to get feedback on the proposal, especially if there\n> > are corner cases I have not considered.\n> \n> I admit I haven\'t spent much time considering all aspects of this, but\n> from a high level I like the idea and your diligence.\n> \n> I\'m working on a proposal for a redesign of the messaging API:\n> \n>   https://wiki.openstack.org/wiki/Oslo/Messaging\n> \n> I don\'t think this will affect your design in any way, and I don\'t think\n> your proposal changes the API design ... so that\'s all goodness.\n> \n> One thing I\'ve just realized we haven\'t taken into account is\n> notifications. There\'s probably a lot of value (to ceilometer at least,\n> I\'d imagine) in using public-key encryption to sign those messages since\n> they are being broadcast to the world and there\'s no concept of the\n> sender knowing who the message is being sent to.\n> \n> Maybe solving the notification signing issue is orthogonal to RPC\n> signing and encryption, but had you any thoughts on it?\n\nI was under the impression that broadcasting to the world is a bad idea.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1367319809.9418.189.camel@sorcha>',NULL),('<1367325274.9418.197.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 13:34:34',3600,'2013-04-30 12:34:34',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > Hi Simo,\n> > \n> > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > Hello list,\n> > > at the Summit we had a very interesting and productive discussion about\n> > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > \n> > > I would like to present a proposal that uses symmetric keys and a\n> > > central key server to address the problem:\n> > > \n> > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > \n> > > I would really like to get feedback on the proposal, especially if there\n> > > are corner cases I have not considered.\n> > \n> > I admit I haven\'t spent much time considering all aspects of this, but\n> > from a high level I like the idea and your diligence.\n> > \n> > I\'m working on a proposal for a redesign of the messaging API:\n> > \n> >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > \n> > I don\'t think this will affect your design in any way, and I don\'t think\n> > your proposal changes the API design ... so that\'s all goodness.\n> > \n> > One thing I\'ve just realized we haven\'t taken into account is\n> > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > I\'d imagine) in using public-key encryption to sign those messages since\n> > they are being broadcast to the world and there\'s no concept of the\n> > sender knowing who the message is being sent to.\n> > \n> > Maybe solving the notification signing issue is orthogonal to RPC\n> > signing and encryption, but had you any thoughts on it?\n> \n> I was under the impression that broadcasting to the world is a bad idea.\n\nOk, \"broadcasting on a message bus that requires credentials to access\".\n\nAn example would be a cloud operators fault analysis tool listening on\nthe bus for error events, applying some logic and alerting the right\npeople.\n\nCheers,\nMark.\n\n\n\n','<1367324879.10084.514.camel@willson.li.ssimo.org>',NULL),('<1367325366.10084.516.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 08:36:06',-14400,'2013-04-30 12:36:06',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:\n> On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > > Hi Simo,\n> > > \n> > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > > Hello list,\n> > > > at the Summit we had a very interesting and productive discussion about\n> > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > > \n> > > > I would like to present a proposal that uses symmetric keys and a\n> > > > central key server to address the problem:\n> > > > \n> > > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > > \n> > > > I would really like to get feedback on the proposal, especially if there\n> > > > are corner cases I have not considered.\n> > > \n> > > I admit I haven\'t spent much time considering all aspects of this, but\n> > > from a high level I like the idea and your diligence.\n> > > \n> > > I\'m working on a proposal for a redesign of the messaging API:\n> > > \n> > >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > > \n> > > I don\'t think this will affect your design in any way, and I don\'t think\n> > > your proposal changes the API design ... so that\'s all goodness.\n> > > \n> > > One thing I\'ve just realized we haven\'t taken into account is\n> > > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > > I\'d imagine) in using public-key encryption to sign those messages since\n> > > they are being broadcast to the world and there\'s no concept of the\n> > > sender knowing who the message is being sent to.\n> > > \n> > > Maybe solving the notification signing issue is orthogonal to RPC\n> > > signing and encryption, but had you any thoughts on it?\n> > \n> > I was under the impression that broadcasting to the world is a bad idea.\n> \n> Ok, \"broadcasting on a message bus that requires credentials to access\".\n> \n> An example would be a cloud operators fault analysis tool listening on\n> the bus for error events, applying some logic and alerting the right\n> people.\n\nI think just for detection you could simply ignore signing and rely on\nthe message queue ?\nDo you need to protect from spoofing for this task ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1367325274.9418.197.camel@sorcha>',NULL),('<1367325952.9418.200.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 13:45:52',3600,'2013-04-30 12:45:52',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 08:36 -0400, Simo Sorce wrote:\n> On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:\n> > On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> > > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > > > Hi Simo,\n> > > > \n> > > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > > > Hello list,\n> > > > > at the Summit we had a very interesting and productive discussion about\n> > > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > > > \n> > > > > I would like to present a proposal that uses symmetric keys and a\n> > > > > central key server to address the problem:\n> > > > > \n> > > > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > > > \n> > > > > I would really like to get feedback on the proposal, especially if there\n> > > > > are corner cases I have not considered.\n> > > > \n> > > > I admit I haven\'t spent much time considering all aspects of this, but\n> > > > from a high level I like the idea and your diligence.\n> > > > \n> > > > I\'m working on a proposal for a redesign of the messaging API:\n> > > > \n> > > >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > > > \n> > > > I don\'t think this will affect your design in any way, and I don\'t think\n> > > > your proposal changes the API design ... so that\'s all goodness.\n> > > > \n> > > > One thing I\'ve just realized we haven\'t taken into account is\n> > > > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > > > I\'d imagine) in using public-key encryption to sign those messages since\n> > > > they are being broadcast to the world and there\'s no concept of the\n> > > > sender knowing who the message is being sent to.\n> > > > \n> > > > Maybe solving the notification signing issue is orthogonal to RPC\n> > > > signing and encryption, but had you any thoughts on it?\n> > > \n> > > I was under the impression that broadcasting to the world is a bad idea.\n> > \n> > Ok, \"broadcasting on a message bus that requires credentials to access\".\n> > \n> > An example would be a cloud operators fault analysis tool listening on\n> > the bus for error events, applying some logic and alerting the right\n> > people.\n> \n> I think just for detection you could simply ignore signing and rely on\n> the message queue ?\n> Do you need to protect from spoofing for this task ?\n\nCeilometer is the other example, and the ability to spoof notifications\ngives you the ability to cause someone to be incorrectly billed ... so,\nyeah, I think it would be valuable to be able to trust that\nnotifications can\'t be spoofed even if the message queue is compromised.\n\nCheers,\nMark.\n\n\n\n','<1367325366.10084.516.camel@willson.li.ssimo.org>',NULL),('<1367326173.10084.518.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 08:49:33',-14400,'2013-04-30 12:49:33',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 13:45 +0100, Mark McLoughlin wrote:\n> On Tue, 2013-04-30 at 08:36 -0400, Simo Sorce wrote:\n> > On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:\n> > > On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> > > > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > > > > Hi Simo,\n> > > > > \n> > > > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > > > > Hello list,\n> > > > > > at the Summit we had a very interesting and productive discussion about\n> > > > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > > > > \n> > > > > > I would like to present a proposal that uses symmetric keys and a\n> > > > > > central key server to address the problem:\n> > > > > > \n> > > > > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > > > > \n> > > > > > I would really like to get feedback on the proposal, especially if there\n> > > > > > are corner cases I have not considered.\n> > > > > \n> > > > > I admit I haven\'t spent much time considering all aspects of this, but\n> > > > > from a high level I like the idea and your diligence.\n> > > > > \n> > > > > I\'m working on a proposal for a redesign of the messaging API:\n> > > > > \n> > > > >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > > > > \n> > > > > I don\'t think this will affect your design in any way, and I don\'t think\n> > > > > your proposal changes the API design ... so that\'s all goodness.\n> > > > > \n> > > > > One thing I\'ve just realized we haven\'t taken into account is\n> > > > > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > > > > I\'d imagine) in using public-key encryption to sign those messages since\n> > > > > they are being broadcast to the world and there\'s no concept of the\n> > > > > sender knowing who the message is being sent to.\n> > > > > \n> > > > > Maybe solving the notification signing issue is orthogonal to RPC\n> > > > > signing and encryption, but had you any thoughts on it?\n> > > > \n> > > > I was under the impression that broadcasting to the world is a bad idea.\n> > > \n> > > Ok, \"broadcasting on a message bus that requires credentials to access\".\n> > > \n> > > An example would be a cloud operators fault analysis tool listening on\n> > > the bus for error events, applying some logic and alerting the right\n> > > people.\n> > \n> > I think just for detection you could simply ignore signing and rely on\n> > the message queue ?\n> > Do you need to protect from spoofing for this task ?\n> \n> Ceilometer is the other example, and the ability to spoof notifications\n> gives you the ability to cause someone to be incorrectly billed ... so,\n> yeah, I think it would be valuable to be able to trust that\n> notifications can\'t be spoofed even if the message queue is compromised.\n\nHow will ceilometer deal with encryption ?\n\nWouldn;t it be better to send messages explicitly to ceilometer (would\nallow to send encrypted too) for billing rather than relying on signed\nonly (but not encrypted) messages and broadcast ?\n\nFor some things you may want to bill you will also want to encrypt the\nmessage.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1367325952.9418.200.camel@sorcha>',NULL),('<1367326502.9418.203.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 13:55:02',3600,'2013-04-30 12:55:02',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 08:49 -0400, Simo Sorce wrote:\n> On Tue, 2013-04-30 at 13:45 +0100, Mark McLoughlin wrote:\n> > On Tue, 2013-04-30 at 08:36 -0400, Simo Sorce wrote:\n> > > On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:\n> > > > On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> > > > > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > > > > > Hi Simo,\n> > > > > > \n> > > > > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > > > > > Hello list,\n> > > > > > > at the Summit we had a very interesting and productive discussion about\n> > > > > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > > > > > \n> > > > > > > I would like to present a proposal that uses symmetric keys and a\n> > > > > > > central key server to address the problem:\n> > > > > > > \n> > > > > > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > > > > > \n> > > > > > > I would really like to get feedback on the proposal, especially if there\n> > > > > > > are corner cases I have not considered.\n> > > > > > \n> > > > > > I admit I haven\'t spent much time considering all aspects of this, but\n> > > > > > from a high level I like the idea and your diligence.\n> > > > > > \n> > > > > > I\'m working on a proposal for a redesign of the messaging API:\n> > > > > > \n> > > > > >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > > > > > \n> > > > > > I don\'t think this will affect your design in any way, and I don\'t think\n> > > > > > your proposal changes the API design ... so that\'s all goodness.\n> > > > > > \n> > > > > > One thing I\'ve just realized we haven\'t taken into account is\n> > > > > > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > > > > > I\'d imagine) in using public-key encryption to sign those messages since\n> > > > > > they are being broadcast to the world and there\'s no concept of the\n> > > > > > sender knowing who the message is being sent to.\n> > > > > > \n> > > > > > Maybe solving the notification signing issue is orthogonal to RPC\n> > > > > > signing and encryption, but had you any thoughts on it?\n> > > > > \n> > > > > I was under the impression that broadcasting to the world is a bad idea.\n> > > > \n> > > > Ok, \"broadcasting on a message bus that requires credentials to access\".\n> > > > \n> > > > An example would be a cloud operators fault analysis tool listening on\n> > > > the bus for error events, applying some logic and alerting the right\n> > > > people.\n> > > \n> > > I think just for detection you could simply ignore signing and rely on\n> > > the message queue ?\n> > > Do you need to protect from spoofing for this task ?\n> > \n> > Ceilometer is the other example, and the ability to spoof notifications\n> > gives you the ability to cause someone to be incorrectly billed ... so,\n> > yeah, I think it would be valuable to be able to trust that\n> > notifications can\'t be spoofed even if the message queue is compromised.\n> \n> How will ceilometer deal with encryption ?\n>\n> Wouldn;t it be better to send messages explicitly to ceilometer (would\n> allow to send encrypted too) for billing rather than relying on signed\n> only (but not encrypted) messages and broadcast ?\n> \n> For some things you may want to bill you will also want to encrypt the\n> message.\n\nI don\'t see a case where encryption would be a big benefit, but maybe\nCeilometer folks would have an example.\n\nOne of the benefits I see in the notification system is that the sender\nof notifications don\'t need to be aware of who\'s consuming them.\n\nCheers,\nMark.\n\n\n\n','<1367326173.10084.518.camel@willson.li.ssimo.org>',NULL),('<1367328641.10084.521.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 09:30:41',-14400,'2013-04-30 13:30:41',NULL,'[openstack-dev] [nova][keystone] Message Queue Security','On Tue, 2013-04-30 at 13:55 +0100, Mark McLoughlin wrote:\n> On Tue, 2013-04-30 at 08:49 -0400, Simo Sorce wrote:\n> > On Tue, 2013-04-30 at 13:45 +0100, Mark McLoughlin wrote:\n> > > On Tue, 2013-04-30 at 08:36 -0400, Simo Sorce wrote:\n> > > > On Tue, 2013-04-30 at 13:34 +0100, Mark McLoughlin wrote:\n> > > > > On Tue, 2013-04-30 at 08:27 -0400, Simo Sorce wrote:\n> > > > > > On Tue, 2013-04-30 at 12:03 +0100, Mark McLoughlin wrote:\n> > > > > > > Hi Simo,\n> > > > > > > \n> > > > > > > On Thu, 2013-04-25 at 08:37 -0400, Simo Sorce wrote:\n> > > > > > > > Hello list,\n> > > > > > > > at the Summit we had a very interesting and productive discussion about\n> > > > > > > > Message Signing/Encryption for RPC Messages sent via the Message Queue.\n> > > > > > > > \n> > > > > > > > I would like to present a proposal that uses symmetric keys and a\n> > > > > > > > central key server to address the problem:\n> > > > > > > > \n> > > > > > > > https://wiki.openstack.org/wiki/MessageSecurity\n> > > > > > > > \n> > > > > > > > I would really like to get feedback on the proposal, especially if there\n> > > > > > > > are corner cases I have not considered.\n> > > > > > > \n> > > > > > > I admit I haven\'t spent much time considering all aspects of this, but\n> > > > > > > from a high level I like the idea and your diligence.\n> > > > > > > \n> > > > > > > I\'m working on a proposal for a redesign of the messaging API:\n> > > > > > > \n> > > > > > >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> > > > > > > \n> > > > > > > I don\'t think this will affect your design in any way, and I don\'t think\n> > > > > > > your proposal changes the API design ... so that\'s all goodness.\n> > > > > > > \n> > > > > > > One thing I\'ve just realized we haven\'t taken into account is\n> > > > > > > notifications. There\'s probably a lot of value (to ceilometer at least,\n> > > > > > > I\'d imagine) in using public-key encryption to sign those messages since\n> > > > > > > they are being broadcast to the world and there\'s no concept of the\n> > > > > > > sender knowing who the message is being sent to.\n> > > > > > > \n> > > > > > > Maybe solving the notification signing issue is orthogonal to RPC\n> > > > > > > signing and encryption, but had you any thoughts on it?\n> > > > > > \n> > > > > > I was under the impression that broadcasting to the world is a bad idea.\n> > > > > \n> > > > > Ok, \"broadcasting on a message bus that requires credentials to access\".\n> > > > > \n> > > > > An example would be a cloud operators fault analysis tool listening on\n> > > > > the bus for error events, applying some logic and alerting the right\n> > > > > people.\n> > > > \n> > > > I think just for detection you could simply ignore signing and rely on\n> > > > the message queue ?\n> > > > Do you need to protect from spoofing for this task ?\n> > > \n> > > Ceilometer is the other example, and the ability to spoof notifications\n> > > gives you the ability to cause someone to be incorrectly billed ... so,\n> > > yeah, I think it would be valuable to be able to trust that\n> > > notifications can\'t be spoofed even if the message queue is compromised.\n> > \n> > How will ceilometer deal with encryption ?\n> >\n> > Wouldn;t it be better to send messages explicitly to ceilometer (would\n> > allow to send encrypted too) for billing rather than relying on signed\n> > only (but not encrypted) messages and broadcast ?\n> > \n> > For some things you may want to bill you will also want to encrypt the\n> > message.\n> \n> I don\'t see a case where encryption would be a big benefit, but maybe\n> Ceilometer folks would have an example.\n> \n> One of the benefits I see in the notification system is that the sender\n> of notifications don\'t need to be aware of who\'s consuming them.\n\nOk, notifications were not in scope for my document, so I will ignore\nthis problem for now.\n\nOnce we have something in place and can play with it it will be easier\nto make changes and see what works, worst case we introduce public key\nfor signing of notifications on top or instead of the current proposal.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1367326502.9418.203.camel@sorcha>',NULL),('<1367340773.260632433@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 12:52:53',-14400,'2013-04-30 16:52:53',NULL,'[openstack-dev] [Glance] Proposal to add John Bresnahan to\n	Glance Core','\n+1, definitely... The best core proposals are for people who you can\'t believe aren\'t already core\n \n-----Original Message-----\nFrom: \"Mark Washenberger\" <mark.washenberger at markwash.net>\nSent: Tuesday, April 30, 2013 1:42am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Glance] Proposal to add John Bresnahan to Glance Core\n\n\n\nHi folks,\nI am proposing we add John Bresnahan (jbresnah) to the glance-core team.\n[https://review.openstack.org/#/dashboard/6493] https://review.openstack.org/#/dashboard/6493\nSince recently joining the OpenStack scene, John has made significant contributions to Glance, including valuable feedback on reviews and key fixes to improve the stability and performance of our test suite.\nPlease respond with comments, +1s, or objections within one week.\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/1f6b3a36/attachment.html>\n\n','<CAJyP2C-k2-Wg6m5eEt+9iLnzP9kVqXFhieZVQxCrmQK9O3mSsA@mail.gmail.com>',NULL),('<1367355975.9418.224.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 22:06:15',3600,'2013-04-30 21:06:15',NULL,'[openstack-dev] [oslo] IRC meeting info','On Thu, 2013-04-25 at 15:27 +0100, Mark McLoughlin wrote:\n> Hi Annie,\n> \n> On Wed, 2013-04-24 at 18:23 -0700, Annie Cheng wrote:\n> > Hi Oslo team,\n> > \n> > Is there a weekly IRC meeting for Oslo?\n> > \n> > I can\'t find it on https://wiki.openstack.org/wiki/Meetings\n> \n> I tend to be a little sceptical about regularly meetings in general, so\n> that\'s part of the reason why we haven\'t done one to date :)\n> \n> However, I\'m totally up for having a meeting whenever someone has\n> something they want to talk about. To that end, I\'ve created:\n> \n>   https://wiki.openstack.org/wiki/Meetings/Oslo\n> \n> We just need to agree on a time slot to keep open for the meeting. Sigh,\n> this is never fun. Here\'s a doodle to see what time suits for people:\n> \n>   http://www.doodle.com/vbs7ux7m4pa3c6c5\n\nOk, let\'s go with Friday at 1400 UTC\n\nThanks!\nMark.\n\n\n\n','<1366900031.16156.25.camel@sorcha>',NULL),('<1367355996.22063.124.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 23:06:36',7200,'2013-04-30 21:06:36',NULL,'[openstack-dev] [metrics] Continuous deployment - significant\n process change','On Mon, 2013-04-29 at 17:50 -0400, Russell Bryant wrote:\n> On 04/29/2013 05:04 PM, Robert Collins wrote:\n> > We had a process track session about bringing in upstream continuous\n> > deployment for openstack.\n> > https://etherpad.openstack.org/HavanaContinuousDeployment\n> > \n> > I suspect that while the session was good with both deployer and\n> > distributor attendees, we need to do more to make it happen, as it\n> > impinges on review / testing / backwards compat requirements for every\n> > project.\n> > \n> > Note that CD doesn\'t require no-downtime deployments, CD is about\n> > being able to adopt *any arbitrary revision of trunk* at *any point in\n> > time*. The engineering required to do deployments without disruption\n> > is beneficial to both CD and per-release deployments.\n> > \n> > Here are the key takeaways we came up with:\n> >  * No more big landings [except the purely mechanical]. Set a hard\n> > limit - maybe 500 lines of diff. Big landings are more risky per line\n> > of diff than small ones due to reviewer cognitive overhead - reviewers\n> > get non-linearly less effective the larger the review.\n> > \n> \n> I don\'t think we can set a # of lines that always makes sense.  However,\n> I feel like in Nova we already do a nice job of pushing back hard on\n> large patches in favor of breaking them up into a reasonable patch series.\n> \n> https://wiki.openstack.org/wiki/GitCommitMessages\n> \n> So, at least for Nova, this is business as usual.\n[...]\n\nSome numbers, just in case they are useful:\n\nOpenStack (all projects):\nTotal number of commits: 29,943\nCommits with > 250 lines added+removed: 3,239 (10.81%)\nCommits with > 500 lines added+removed: 1,766 (5.89%)\nCommits with > 1000 lines added+removed: 945 (3.15%)\n\nOpenstack (all projects, since 2013-01-01):\nTotal number of commits: 3,850\nCommits with > 500 lines added+removed: 265 (6,88%)\n\nNova:\nTotal number of commits: 12,683\nCommits with > 500 lines added+removed: 535 (4.21%)\n\nNova (since 2013-01-01):\n\nTotal number of commits: 1052\nCommits with > 500 lines added+removed: 58 (5.51%)\n\n[All of this, up to 2013-03-25, excluding commits whith 0 lines added\nand removed, which usually are merge commits]\n\nSo, it seems Nova is below the numbers for the whole project, although\nthe fraction of large patches seems to be increasing in both cases.\n\nMore detailed numbers, such as evolution over time for each project\ncould be produced.\n\nSaludos,\n\n	Jesus.\n\nPS: All of these data can be calculated on the database produced by\nCVSAnalY, which you can get as the dumpfile\nopenstack_git_2013_04_04.mysql.7z from\nhttp://bitergia.com/public/reports/openstack/2013_04_grizzly/data/db/\n\n[Well, I used an slightly older version, that\'s why it gets only up to\nApril 25th]\n\nUpdated database dumps soon to be available at\nhttp://activity.openstack.org/dash/\n\nQueries used:\n\nselect max(date) from scmlog;\n\n# All OpenStack projects\nselect count(commit_id) from commits_lines where added+removed > 0;\nselect count(commit_id) from commits_lines where added+removed > 250;\nselect count(commit_id) from commits_lines where added+removed > 500;\nselect count(commit_id) from commits_lines where added+removed > 1000;\n\n# All OpenStack projects since 2013-01-01\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 500  and scmlog.id=commit_id and\n  scmlog.date>=\"2013-01-01\";\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 0  and scmlog.id=commit_id and\n  scmlog.date>=\"2013-01-01\";\n\n# Nova\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 500 and scmlog.id=commit_id and\n  scmlog.repository_id=13;\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 0 and scmlog.id=commit_id and\n  scmlog.repository_id=13;\n\n# Nova since 2013-01-01\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 0  and scmlog.id=commit_id and\n  scmlog.repository_id=13 and scmlog.date>=\"2013-01-01\";\nselect count(commit_id) from commits_lines,scmlog\nwhere added+removed > 500  and scmlog.id=commit_id and\n  scmlog.repository_id=13 and scmlog.date>=\"2013-01-01\";\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<517EEB2D.8080001@redhat.com>',NULL),('<1367356048.9418.225.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 22:07:28',3600,'2013-04-30 21:07:28',NULL,'[openstack-dev] [oslo] IRC meeting info','On Tue, 2013-04-30 at 22:06 +0100, Mark McLoughlin wrote:\n> On Thu, 2013-04-25 at 15:27 +0100, Mark McLoughlin wrote:\n> > Hi Annie,\n> > \n> > On Wed, 2013-04-24 at 18:23 -0700, Annie Cheng wrote:\n> > > Hi Oslo team,\n> > > \n> > > Is there a weekly IRC meeting for Oslo?\n> > > \n> > > I can\'t find it on https://wiki.openstack.org/wiki/Meetings\n> > \n> > I tend to be a little sceptical about regularly meetings in general, so\n> > that\'s part of the reason why we haven\'t done one to date :)\n> > \n> > However, I\'m totally up for having a meeting whenever someone has\n> > something they want to talk about. To that end, I\'ve created:\n> > \n> >   https://wiki.openstack.org/wiki/Meetings/Oslo\n> > \n> > We just need to agree on a time slot to keep open for the meeting. Sigh,\n> > this is never fun. Here\'s a doodle to see what time suits for people:\n> > \n> >   http://www.doodle.com/vbs7ux7m4pa3c6c5\n> \n> Ok, let\'s go with Friday at 1400 UTC\n\nAnd let\'s start this Friday with a discussion about what we\'re doing\nwith messaging in Havana - both the new API and the trusted messaging\nwork\n\nCheers,\nMark.\n\n\n\n','<1367355975.9418.224.camel@sorcha>',NULL),('<1367397718.10903171.1398361606492.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 13:46:46',-14400,'2014-04-24 17:46:46',NULL,'[openstack-dev] [Nova][blueprint] Accelerate the booting\n process of a number of vms via VMThunder','Something to be aware of when planing an image transfer library is that individual drivers\nmight have optimized support for image transfer in certain cases (especially when dealing\nwith transferring between different formats, like raw to qcow2, etc).  This builds on what\nChristopher was saying -- there\'s actually a reason why we have code for each driver.  While\nhaving a common image copying library would be nice, I think a better way to do it would be to\nhave some sort of library composed of building blocks, such that each driver could make use of\ncommon functionality while still tailoring the operation to the quirks of the particular drivers.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Christopher Lefelhocz\" <christopher.lefelhoc at RACKSPACE.COM>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Thursday, April 24, 2014 11:17:41 AM\nSubject: Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder\n\nApologies for coming to this discussion late...\n\nOn 4/22/14 6:21 PM, \"Jay Pipes\" <jaypipes at gmail.com> wrote:\n\n>\n>Right, a good solution would allow for some flexibility via multiple\n>transfer drivers.\n\n+1. In particular I don\'t think this discussion should degenerate into\nzero-copy vs. pre caching.  I see both as possible solutions depending on\ndeployer/environment needs.\n\n>\n>> Jay Pipes has suggested we figure out a blueprint for a separate\n>> library dedicated to the data(byte) transfer, which may be put in oslo\n>> and used by any projects in need (Hoping Jay can come in:-)). Huiba,\n>> Zhiyan, everyone else, do you think we come up with a blueprint about\n>> the data transfer in oslo can work?\n>\n>Yes, so I believe the most appropriate solution is to create a library\n>-- in oslo or a standalone library like taskflow -- that would offer a\n>simple byte streaming library that could be used by nova.image to expose\n>a neat and clean task-based API.\n>\n>Right now, there is a bunch of random image transfer code spread\n>throughout nova.image and in each of the virt drivers there seems to be\n>different re-implementations of similar functionality. I propose we\n>clean all that up and have nova.image expose an API so that a virt\n>driver could do something like this:\n>\n>from nova.image import api as image_api\n>\n>...\n>\n>task = image_api.copy(from_path_or_uri, to_path_or_uri)\n># do some other work\n>copy_task_result = task.wait()\n>\n>Within nova.image.api.copy(), we would use the aforementioned transfer\n>library to move the image bits from the source to the destination using\n>the most appropriate method.\n\nIf I understand correctly, we\'ll create some common library around this.\nIt would be good to understand the details a bit better.  I\'ve thought a\nbit about this issue.  The one area that I get stuck at is providing a\ncommon set of downloads which work across drivers effectively.  Part of\nthe reason there are a bunch or random image transfers is historical, but\nalso because performance was already a problem.  Examples include:\ntransferring to compute first then copying to dom0 causing performance\nissues, needs in some drivers to download image completely to validate\nprior to putting in place, etc.\n\nIt may be easy to say we\'ll push most of this to the dom0, but I know for\nXen our python stack is somewhat limited so that may be an issue.\n\nBy the way we\'ve been working on proposing a simpler image pre caching\nsystem/strategy.  It focuses specifically on the image caching portion of\nthis discussion.  For those interested, see the nova-spec\nhttps://review.openstack.org/#/c/85792.  We\'d like to leverage whatever\noptimized image download strategy is available.\n\nChristopher \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CF7E8FCC.161FC%christopher.lefelhoc@rackspace.com>',NULL),('<1367420555.2976.12.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-01 11:02:35',-14400,'2013-05-01 15:02:35',NULL,'[openstack-dev] [nova][moniker] DNSaaS but DNS Updates not first\n	class interface ?','I have been looking at the DNS as a Service proposal stuff that was\nrecently brought up on the list and on IRC.\n\nAnd I am very surprised to see people here want to actually own the DNS\nserver backend (writing to databases directly and stuff) instead of\nsimply using DNS Updates and letting the deployer choose the DNS server\ninfrastructure it likes best.\n\nWhy DNS Updates are not the primary interaction method with a DNS Server\nin moniker (or nova-dns) ?\n\nThey are standard and quite simple to use, and any DNS Server worth this\nname support them with multiple authentication methods (TSIG or GSS-TSIG\nbeing the most prominent).\n\nSo I am baffled to see people going the direction of creating much more\ncomplex deigns to interact directly with databases and stuff when that\nis basically a solved problem in today infrastructures and trying to\n*own* the DNS Server is going to cause more problems than it solves when\ntrying to integrate in an existing network.\n\nPlease comment.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n',NULL,NULL),('<1367421978.3586.19.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-01 10:26:17',-18000,'2013-05-01 15:26:17',NULL,'[openstack-dev] A (probably) interesting authZ question','On Tue, 2013-04-30 at 23:57 +0100, Salvatore Orlando wrote:\n> and we would like to say that the policy for setting enable_snat must\n> be rule:admin_only.\n> there are several options, among which:\n> \n> \n> 1) this way of doing authZ does not make sense at all. authZ should be\n> enforced on resources not single attributes\n> 2) If the particular attribute comes from some specific extension,\n> instead of policing access one should be allowed to turn\n> administratively on/off the extension itself\n> 3) We should have a rule check for sub-attributes (like FieldCheck in\n> quantum/policy.py).\n> 4) The enable_snat attribute should be moved to the first-level\n> resource, and authZ checked as with any other attribute\n\nWhen I rewrote policies into a language, one of the features I included\nwas a \"case\" syntax; the idea was that, instead of just giving you a\n\"authorized\" vs. \"unauthorized\" decision, the policy enforcer could give\nyou finer-grained data, e.g., \"admin\", \"user\", \"unauthorized\".  That\npart of the patch did not make it in, however, because there was no\nextant use case for it at the time.\n\nNow that we have a use case, is this a feature that should be\nresurrected?  Any opinions on what it should look like?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAGR=i3j+w2XKwcxA0Zx=rY8sc_UE1iUma3+g7uqxLLUkMU_yXw@mail.gmail.com>',NULL),('<1367424105.9418.268.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-01 17:01:45',3600,'2013-05-01 16:01:45',NULL,'[openstack-dev] jsonschema based API validation in Nova','Hey\n\nI haven\'t reviewed them closely yet, but I wanted to bring some\nattention to these reviews:\n\n  https://review.openstack.org/25358\n  https://review.openstack.org/25884\n  https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw\n\nIt\'s a pretty significant new approach, so I\'d really like to see more\nnova-core folks chiming in.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1367428853.2976.20.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-01 13:20:53',-14400,'2013-05-01 17:20:53',NULL,'[openstack-dev] [nova][moniker] DNSaaS but DNS Updates not\n first	class interface ?','On Wed, 2013-05-01 at 16:35 +0000, Mac Innes, Kiall wrote:\n> Hi Simo,\n> \n> On 01/05/13 16:07, Simo Sorce wrote:\n> > I have been looking at the DNS as a Service proposal stuff that was\n> > recently brought up on the list and on IRC.\n> > \n> > And I am very surprised to see people here want to actually own the DNS\n> > server backend (writing to databases directly and stuff) instead of\n> > simply using DNS Updates and letting the deployer choose the DNS server\n> > infrastructure it likes best.\n> \n> RFC2136 DNS Updates don\'t offer the ability to do things like add/remove\n> zones and is not always available. Many providers, like Akamai, UltraDNS\n> etc simply don\'t offer support for RFC2136.\n> \n> We don\'t require that the deployer maintains their own DNS servers. HP\n> Cloud DNS, for example, takes advantage of Akamai\'s DNS offering.\n> \n> > \n> > Why DNS Updates are not the primary interaction method with a DNS Server\n> > in moniker (or nova-dns) ?\n> \n> IMO, The primary method of interaction implemented should be usable for\n> all primary interactions. Creation and deletion of zones are primary\n> interactions.\n> \n> Down the line, we expect to support features like allowing customers to\n> slave zones from moniker managed DNS servers, requiring the provisioning\n> of ACLs and TSIG keys, again, this is not supported by RFC2136.\n> \n> > \n> > They are standard and quite simple to use, and any DNS Server worth this\n> > name support them with multiple authentication methods (TSIG or GSS-TSIG\n> > being the most prominent).\n> > \n> > So I am baffled to see people going the direction of creating much more\n> > complex deigns to interact directly with databases and stuff when that\n> > is basically a solved problem in today infrastructures and trying to\n> > *own* the DNS Server is going to cause more problems than it solves when\n> > trying to integrate in an existing network.\n> \n> We DO expect to own the DNS infrastructure to which customer domains\n> will be provisioned. Mixing customers zones and operator zones is just\n> not something we specifically support (That said, there is nothing\n> currently preventing that, today)\n> \n> Moniker does *much* more than the DNS functionality currently built into\n> Nova does, if we were simply creating A records for instances, RFC2136\n> would have been a better choice.\n> \n> > \n> > Please comment.\n> > \n> > Simo.\n> > \n> \n> And.. Anyway! Moniker is completely modular, a RFC2136 backend could\n> easily be written, assuming you have a secondary method of handling\n> configuration that the RFC does not support.\n\n\nThanks for the explanation that makes a lot more sense, maybe it would\nbe nice to have it in distilled form here in the overview section:\nhttps://wiki.openstack.org/wiki/Moniker\n\nCurrently that page does not give enough information about the\nrequirements and the objectives of the project.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<2CA92712C6DFEB4D8C2818165644367105E2C5E7@G9W0341.americas.hpqcorp.net>',NULL),('<1367473027.2345.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-02 06:37:07',3600,'2013-05-02 05:37:07',NULL,'[openstack-dev] [openstack-tc] Splitting the Baremetal driver\n out of Nova','Hi Devananda,\n\nOn Wed, 2013-05-01 at 09:10 -0700, Devananda van der Veen wrote:\n> To clarify this request, since there seems to be some ambiguity as to\n> whether I suggested a scope reduction to Nova or a new incubated project, I\n> am, in fact, suggesting both at the same time, and would like the TC to\n> consider these requests in parallel. Specifically, I would like to see the\n> baremetal code be split out of Nova and into a new project, code name\n> Ironic, which would start incubation immediately, and thereafter follow the\n> normal incubation process until the TC determines that graduation is (or\n> isn\'t) appropriate.\n>\n> A salient point here is that, at the moment, there is no separate codebase\n> for ironic. The majority of functionality lives in these places within the\n> nova tree:\n> \n>   bin/nova-baremetal-deploy-helper\n>   bin/nova-baremetal-manage\n>   nova/api/openstack/compute/contrib/baremetal_nodes.py\n>   nova/virt/baremetal/*\n>   nova/tests/baremetal/*\n> \n> I am starting the work of splitting the code now(), and waiting for the\n> TC\'s determination of incubate-or-not to see whether the code gets hosted\n> on the stackforge or openstack org. Once the split tree is working to some\n> degree, I\'ll reply to this thread with a link to github, so folks can start\n> to look at it.\n\nSo, is the idea that we\'d very soon switch the Nova baremetal driver\nover to using the new project?\n\nI think a parallel was being drawn with nova-volumes/Cinder, which\nsuggested to me that the current baremetal driver would remain for a\ntransition period while the new project settles in?\n\nPersonally, I can see the difficulty with making it happen that way and\nI\'d be pretty confident you could make this a success in Havana without\na transition period.\n\nHowever, maybe you could get the new project going first and host the\nre-worked baremetal driver on a github fork for a few weeks before\nproposing it gets merged into Nova?\n\nCheers,\nMark.\n\n\n\n','<CAExZKEpw2sV5e7zxkk+VcQUGGpQp6SRKiKsTeErhGR0cBSuYQQ@mail.gmail.com>',NULL),('<1367473027.2345.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-02 06:37:07',3600,'2013-05-02 05:37:07',NULL,'[openstack-tc] [openstack-dev] Splitting the Baremetal driver\n out of Nova','Hi Devananda,\n\nOn Wed, 2013-05-01 at 09:10 -0700, Devananda van der Veen wrote:\n> To clarify this request, since there seems to be some ambiguity as to\n> whether I suggested a scope reduction to Nova or a new incubated project, I\n> am, in fact, suggesting both at the same time, and would like the TC to\n> consider these requests in parallel. Specifically, I would like to see the\n> baremetal code be split out of Nova and into a new project, code name\n> Ironic, which would start incubation immediately, and thereafter follow the\n> normal incubation process until the TC determines that graduation is (or\n> isn\'t) appropriate.\n>\n> A salient point here is that, at the moment, there is no separate codebase\n> for ironic. The majority of functionality lives in these places within the\n> nova tree:\n> \n>   bin/nova-baremetal-deploy-helper\n>   bin/nova-baremetal-manage\n>   nova/api/openstack/compute/contrib/baremetal_nodes.py\n>   nova/virt/baremetal/*\n>   nova/tests/baremetal/*\n> \n> I am starting the work of splitting the code now(), and waiting for the\n> TC\'s determination of incubate-or-not to see whether the code gets hosted\n> on the stackforge or openstack org. Once the split tree is working to some\n> degree, I\'ll reply to this thread with a link to github, so folks can start\n> to look at it.\n\nSo, is the idea that we\'d very soon switch the Nova baremetal driver\nover to using the new project?\n\nI think a parallel was being drawn with nova-volumes/Cinder, which\nsuggested to me that the current baremetal driver would remain for a\ntransition period while the new project settles in?\n\nPersonally, I can see the difficulty with making it happen that way and\nI\'d be pretty confident you could make this a success in Havana without\na transition period.\n\nHowever, maybe you could get the new project going first and host the\nre-worked baremetal driver on a github fork for a few weeks before\nproposing it gets merged into Nova?\n\nCheers,\nMark.\n\n\n\n','<CAExZKEpw2sV5e7zxkk+VcQUGGpQp6SRKiKsTeErhGR0cBSuYQQ@mail.gmail.com>',NULL),('<1367473992.2345.18.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-02 06:53:12',3600,'2013-05-02 05:53:12',NULL,'[openstack-tc] Copyrights and License Headers in source files','Hi Mark,\n\nOn Wed, 2013-05-01 at 14:57 -0700, Mark Washenberger wrote:\n> Hi folks,\n> \n> I was looking into the ASL-2.0, and chanced across the fact that in Apache\n> projects, they require that source files only have the License Header, and\n> may not have any copyright notices [1]. It occurred to me that we waste a\n> fair amount of time on copyrights in license headers, and it would be nice\n> not to have to do that anymore.\n\nLike Monty said, I\'d like to hear more about why these are seen as a\ntime sink.\n\n> I also noticed a previous conversation [2] on this subject. I have not\n> found any policy that actually requires us to include copyrights with each\n> source file license header.\n> \n> Feel free to suggest that this is more trouble than it is worth, but I\'d\n> like to propose that we discourage new contributions from including\n> copyright attribution, and provide a process to work with the various\n> parties we have to remove the copyrights from existing files.\n\nI don\'t have a massively strong opinion on this and I\'d never really\nconsidered the possibility of not having copyright headers, but my first\nthought is that I like that we have them. I like that \"ownership\" of the\nwork is distributed and it\'s nice to be able to see how that ownership\nis distributed through the code base.\n\nIn any case, I think it\'s too late for us to effectively make a change\nin like this successfully and not worth the hassle.\n\nCheers,\nMark.\n\n\n\n','<CAJyP2C_cMmhPQHKsbohN8=1JZc8tbJYN4-Ao=q7a0-vmukDLyA@mail.gmail.com>',NULL),('<1367480086.2345.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-02 08:34:46',3600,'2013-05-02 07:34:46',NULL,'[openstack-dev] [openstack-tc] Proposal for API version\n	discovery','Hi Garbiel\n\nOn Thu, 2013-05-02 at 00:46 +0000, Gabriel Hurley wrote:\n> Based on input from several of the PTLs (and others), I\'d like to\n> propose the following outline for how version discovery should be\n> handled across heterogeneous clouds:\n> \n> https://etherpad.openstack.org/api-version-discovery-proposal\n> \n> Further discussion is absolutely welcome, and I would like to propose\n> it as a topic for review by the Technical Committee at the next\n> meeting since it involves a significant cross-project standardization\n> effort.\n\nThis definitely looks like a nice step forward and would be great to\nhave it done cross-project.\n\nThis is a bit of a side-track but ... I\'ve been around this project a\nwhile now, but I admit to still being pretty confused about our approach\nto API versioning. Are extensions really our only way of adding new\ncapabilities to an API version in a backwards compatible way?\n\nAnd are extensions really our only way of allowing an API capability to\nbe optional?\n\nI\'d like to see us introducing new API versions a lot less regularly,\nbut still being able to add new capabilities (and optional capabilities)\nin a backwards compatible and client-queryable way.\n\nSome options for doing that:\n\n  * We allow minor versions with new features; clients know what \n    features are supported in minor versions and expose capabilities to \n    users based on the queried versions\n\n  * We add a \'GET /capabilities\' which returns a document describing \n    which features this endpoints support - a feature could be optional \n    because it was added in a new version or because not all \n    deployments would be configured with it enabled. This would allow \n    clients to be able to query for features, rather than having a \n    hard-coded understanding of which minor versions support which\n    features.\n\n  * We adopt a more HATEOAS model where a client basically never \n    constructs a URL - everything can be reached via links in the \n    hypertext we return. If an endpoint doesn\'t support a given \n    feature, it just never includes a link to that feature in the \n    hypertext.\n\nAn example of the first approach:\n\n  https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Capabilities-Example\n\n  <capabilities>\n      <version minor=\"0\" major=\"3\">\n          <current>true</current>\n          <features>\n              <transparent_hugepages/>\n          </features>\n          <cpus>\n              <cpu id=\"Intel Conroe Family\">\n                  <level>3</level>\n              </cpu>\n   ....\n\n   (ignore the version number there, it\'s not what you think it is)\n\nand the second approach:\n\n  https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Common_Features-Resources-Actions\n\n  <resource>\n      ...\n      <actions>\n          <link rel=\"start\" href=\"/api/collection/resource_id/start\"/>\n          <link rel=\"stop\" href=\"/api/collection/resource_id/stop\"/>\n        ...\n      </actions>\n      ...\n  </resource>\n\nDeltacloud\'s native API also has some of this:\n\n  http://deltacloud.apache.org/api-entry-point.html\n\n  <link href=\'http://localhost:3001/api/images\' rel=\'images\'>\n    <feature name=\'owner_id\'/>\n  </link>\n\n\nHTH,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F2365B330DCE@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1367480086.2345.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-02 08:34:46',3600,'2013-05-02 07:34:46',NULL,'[openstack-tc] Proposal for API version discovery','Hi Garbiel\n\nOn Thu, 2013-05-02 at 00:46 +0000, Gabriel Hurley wrote:\n> Based on input from several of the PTLs (and others), I\'d like to\n> propose the following outline for how version discovery should be\n> handled across heterogeneous clouds:\n> \n> https://etherpad.openstack.org/api-version-discovery-proposal\n> \n> Further discussion is absolutely welcome, and I would like to propose\n> it as a topic for review by the Technical Committee at the next\n> meeting since it involves a significant cross-project standardization\n> effort.\n\nThis definitely looks like a nice step forward and would be great to\nhave it done cross-project.\n\nThis is a bit of a side-track but ... I\'ve been around this project a\nwhile now, but I admit to still being pretty confused about our approach\nto API versioning. Are extensions really our only way of adding new\ncapabilities to an API version in a backwards compatible way?\n\nAnd are extensions really our only way of allowing an API capability to\nbe optional?\n\nI\'d like to see us introducing new API versions a lot less regularly,\nbut still being able to add new capabilities (and optional capabilities)\nin a backwards compatible and client-queryable way.\n\nSome options for doing that:\n\n  * We allow minor versions with new features; clients know what \n    features are supported in minor versions and expose capabilities to \n    users based on the queried versions\n\n  * We add a \'GET /capabilities\' which returns a document describing \n    which features this endpoints support - a feature could be optional \n    because it was added in a new version or because not all \n    deployments would be configured with it enabled. This would allow \n    clients to be able to query for features, rather than having a \n    hard-coded understanding of which minor versions support which\n    features.\n\n  * We adopt a more HATEOAS model where a client basically never \n    constructs a URL - everything can be reached via links in the \n    hypertext we return. If an endpoint doesn\'t support a given \n    feature, it just never includes a link to that feature in the \n    hypertext.\n\nAn example of the first approach:\n\n  https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Capabilities-Example\n\n  <capabilities>\n      <version minor=\"0\" major=\"3\">\n          <current>true</current>\n          <features>\n              <transparent_hugepages/>\n          </features>\n          <cpus>\n              <cpu id=\"Intel Conroe Family\">\n                  <level>3</level>\n              </cpu>\n   ....\n\n   (ignore the version number there, it\'s not what you think it is)\n\nand the second approach:\n\n  https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.0/html-single/REST_API_Guide/index.html#sect-REST_API_Guide-Common_Features-Resources-Actions\n\n  <resource>\n      ...\n      <actions>\n          <link rel=\"start\" href=\"/api/collection/resource_id/start\"/>\n          <link rel=\"stop\" href=\"/api/collection/resource_id/stop\"/>\n        ...\n      </actions>\n      ...\n  </resource>\n\nDeltacloud\'s native API also has some of this:\n\n  http://deltacloud.apache.org/api-entry-point.html\n\n  <link href=\'http://localhost:3001/api/images\' rel=\'images\'>\n    <feature name=\'owner_id\'/>\n  </link>\n\n\nHTH,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F2365B330DCE@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1367485888.2345.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-02 10:11:28',3600,'2013-05-02 09:11:28',NULL,'[openstack-dev] Who owns the centos gate for oslo?','Hey Michael,\n\nOn Thu, 2013-05-02 at 17:36 +1000, Michael Still wrote:\n> Who owns the centos gate for oslo? Its failing on one of my changes,\n> and it looks to me like a centos bug...\n> \n> http://logs.openstack.org/28014/1/check/gate-oslo-incubator-python26-centos6/15/console.html\n> \n> One of the failures looks like this:\n> \n> 2013-05-02 07:28:03.563 |\n> ======================================================================\n> 2013-05-02 07:28:03.563 | ERROR:\n> tests.unit.test_processutils.ProcessExecutionErrorTest.test_check_exit_code_boolean\n> 2013-05-02 07:28:03.563 |\n> ----------------------------------------------------------------------\n> 2013-05-02 07:28:03.563 | _StringException: Empty attachments:\n> 2013-05-02 07:28:03.563 |   pythonlogging:\'openstack.common\'\n> 2013-05-02 07:28:03.563 |\n> 2013-05-02 07:28:03.563 | Traceback (most recent call last):\n> 2013-05-02 07:28:03.563 |   File\n> \"/home/jenkins/workspace/gate-oslo-incubator-python26-centos6/tests/unit/test_processutils.py\",\n> line 140, in test_check_exit_code_boolean\n> 2013-05-02 07:28:03.563 |     processutils.execute(\'/usr/bin/env\',\n> \'false\', check_exit_code=False)\n> 2013-05-02 07:28:03.563 |   File\n> \"/home/jenkins/workspace/gate-oslo-incubator-python26-centos6/openstack/common/processutils.py\",\n> line 149, in execute\n> 2013-05-02 07:28:03.563 |     result = obj.communicate()\n> 2013-05-02 07:28:03.563 |   File \"/usr/lib64/python2.6/subprocess.py\",\n> line 729, in communicate\n> 2013-05-02 07:28:03.563 |     stdout, stderr = self._communicate(input, endtime)\n> 2013-05-02 07:28:03.563 |   File \"/usr/lib64/python2.6/subprocess.py\",\n> line 1330, in _communicate\n> 2013-05-02 07:28:03.564 |     self.wait(timeout=self._remaining_time(endtime))\n> 2013-05-02 07:28:03.564 | TypeError: wait() got an unexpected keyword\n> argument \'timeout\'\n> \n> Note that argument is coming from python2.6, not my code. According to\n> http://blog.dynamichosting.biz/2013/01/10/issues-with-nova-services-and-timeout-from-python-eventlet-w-centos-and-rhel/\n> it might be an eventlet versioning issue?\n\nThe eventlet on PyPI basically doesn\'t work on RHEL6 right now because\nwe (Red Hat) screwed up by not taking monkey patching into account when\nbackporting an API from python 3. Nova has a hack to workaround this and\nI\'ve just proposed that we add this to oslo-incubator. The commit\nmessage has all the gory details:\n\n  https://review.openstack.org/28020\n\nCheers,\nMark.\n\n\n\n','<CAEd1pt5vW5NUwNa9-GUP4ese+0b1rJgy8k2FuK_d8Hi4wxe+Yw@mail.gmail.com>',NULL),('<1367495112.2345.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-02 12:45:12',3600,'2013-05-02 11:45:12',NULL,'[openstack-tc] Copyrights and License Headers in source files','On Thu, 2013-05-02 at 07:30 -0400, Sean Dague wrote:\n> On 05/01/2013 06:12 PM, Monty Taylor wrote:\n> > On 05/01/2013 06:05 PM, John Griffith wrote:\n> >> On Wed, May 1, 2013 at 3:57 PM, Mark Washenberger\n> >> <mark.washenberger at markwash.net <mailto:mark.washenberger at markwash.net>>\n> >> wrote:\n> >>\n> >>      Hi folks,\n> >>\n> >>      I was looking into the ASL-2.0, and chanced across the fact that in\n> >>      Apache projects, they require that source files only have the\n> >>      License Header, and may not have any copyright notices [1]. It\n> >>      occurred to me that we waste a fair amount of time on copyrights in\n> >>      license headers, and it would be nice not to have to do that anymore.\n> >\n> > I would like to hear more about the time waste there - where are we\n> > spending time? Can we do something to make that better?\n> >\n> >> I think that only applies to code submitted directly to ASF, but\n> >> regardless you wouldn\'t get any objections from me regarding your\n> >> proposal.  Some of the legal teams in companies involved in OpenStack\n> >> however may feel differently.\n> >\n> > And some of the developers. I would not like that.\n> >\n> > I would really like to see more folks learn about appropriate addition\n> > of copyright attribution when they work on a file, because I think it\'s\n> > quite important. Don\'t think that removing attribution from each file\n> > would prevent people from needing to do it - if we moved to a NOTICE\n> > file system, they\'d need to put the notice there.\n> \n> +1\n> \n> This is really an education issue. Lots of first time Open Source folks \n> on the project that don\'t understand that copyright + license grant in \n> each file is actually quite important to ensure things are actually Open \n> Source in all jurisdictions.\n> \n> It would be good if there was a single wiki page that I could respond to \n> people that -1 adding Copyright statements to explain that it is normal. \n> I\'ve had to explain that too many times\n\nLet\'s get this on:\n\n  https://wiki.openstack.org/wiki/LegalIssuesFAQ\n\nCheers,\nMark.\n\n\n\n','<51824E59.3040509@dague.net>',NULL),('<1367576198.2401.0.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 11:16:38',3600,'2013-05-03 10:16:38',NULL,'[openstack-dev] Reminder: Oslo project meeting','Hi\n\nWe\'re having our first IRC meeting today where the main topic on the\nagenda is the messaging working in Havana:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n\nSee on #openstack-meeting at 1400 UTC\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1367586627.8724.YahooMailNeo@web163802.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 06:10:27',-25200,'2013-05-03 13:10:27',NULL,'[openstack-dev] [barbican] CloudKeep API','How are the tenant IDs populated in the database?\n\nWhat are the possible content_types for a secret GET request?? I\'m a little\nconfused as to what to expect for that value.? The AES key in the example has a\npublic key word.? Why public?? Public and private I can kind of understand for\nasymmetric keys, but I don\'t know what would be there for a symmetric key.? Any? \nparticular reason you have MIME type for post and content_type for get?? I\nguess my expectation is that if I create an object with the properties name,\nexpiration, and MIME type that I would be able to retrieve that same object and\nit would have the same properties of name, expiration, and MIME type.\n\nIs application/aes-256-cbc an actual MIME type?? I wonder if MIME type is the\nbest descriptor for an attribute.? I don\'t even think that MIME type will be\nreturned to the user in the HTTP request since it will be application/json in\nmost circumstances.? Perhaps algorithm or format might be better.? MIME types\nseem specific to protocols.\n\nShould the key expiration be a part of the secret object or the policy\nassociated with the secret object?? I was thinking this would be in a policy\nobject, but it\'s not a big deal to me either way.? Can this be null if no\nexpiration?\n\n-Nate\n\n\n',NULL,NULL),('<1367593953.3586.30.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 10:12:33',-18000,'2013-05-03 15:12:33',NULL,'[openstack-dev] Policy\'s persistence layer','On Fri, 2013-05-03 at 09:54 +0200, Flavio Percoco wrote:\n> 1) The change would be backward compatible.\n> 2) It would still support file based RBAC.\n> 3) Policy\'s form wont change. It would still be based on dictionaries\n> and it\'d be up to storage to de-normalize rules.\n> 4) Policies could be imported from a file.\n> 5) Policies could be updated using a manage command or by modifying a\n> single policy file that is kept updated.\n> \n> Before digging more into this, I would like to have some feedback from\n> you and see if there are some issues not being considered in the above.\n\nI\'ll just add to this a blueprint I submitted but haven\'t had a chance\nto work on:\n\n        https://blueprints.launchpad.net/oslo/+spec/self-documenting-policies\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<20130503075401.GC26603@redhat.com>',NULL),('<1367594059.3586.32.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 10:14:19',-18000,'2013-05-03 15:14:19',NULL,'[openstack-dev] Policy\'s persistence layer','On Fri, 2013-05-03 at 09:20 -0500, Dolph Mathews wrote:\n> This API was implemented in keystone in grizzly for centralized policy\n> storage:\n> \n> \n>   https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-policy-post-policies\n\nDoes this support the language-based policies now implemented in\noslo-incubator and used by nova, quantum, and glance?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAC=h7gWpcQ7zQsqY4XnbyDgCM=wBaMJcfxPeNrut3qfBQ5E5-Q@mail.gmail.com>',NULL),('<1367594271.2401.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 16:17:51',3600,'2013-05-03 15:17:51',NULL,'[openstack-dev] Reminder: Oslo project meeting','On Fri, 2013-05-03 at 11:16 +0100, Mark McLoughlin wrote:\n> Hi\n> \n> We\'re having our first IRC meeting today where the main topic on the\n> agenda is the messaging working in Havana:\n> \n>   https://wiki.openstack.org/wiki/Meetings/Oslo\n> \n> See on #openstack-meeting at 1400 UTC\n\nWell, that was fun :)\n\n  http://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-05-03-14.01.html\n\nCheers,\nMark.\n\n\n\n','<1367576198.2401.0.camel@sorcha>',NULL),('<1367598050.2976.177.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 12:20:50',-14400,'2013-05-03 16:20:50',NULL,'[openstack-dev] [Barbican] Use of Dogtag for Production Backend','On Fri, 2013-05-03 at 14:09 +0000, Jarret Raim wrote:\n> On 5/3/13 8:44 AM, \"Clark, Robert Graham\" <robert.clark at hp.com> wrote:\n> \n> >From a personal point of view I\'ve always found Dogtag to be a pain to\n> >install on any non Redhat system. EJBCA offers some cross over and is\n> >significantly easier to deploy. That said, I think the overall approach\n> >makes a lot of sense. I\'ll be watching with interest.\n> \n> Thanks for the feedback. I\'ll add EJBCA to our list to investigate. I\'ve\n> also gotten some feedback from our ops folks that they aren\'t particularly\n> happy about having to run 389, but we\'ll see if there is any fire under\n> all the smoke :)\n> \n> >Seeing as RH has thrown so much effort into OpenStack already, I guess\n> >Dogtag makes a lot of sense. Looking forward to seeing where this goes.\n> >Once the blueprint is done I\'d be prepared to throw some effort into\n> >documenting how to deploy a reference implementation on a debian-type\n> >system.\n> \n> That\'s awesome, thanks. We\'ll have to get everything working on at least\n> Cent, RHEL, Debian and Ubuntu so if there are install difficulties, that\'s\n> something we can work with the RedHat guys about. They\'ve been super\n> helpful so far.\n\nOn the Red Hat side we are working on making sure DogTag 10 will be\ninstallable on Debian/Ubuntu soon, currently they miss some packages for\nRestEasy which is used to implement the RESTful API.\n\nSimo.\n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CDA92E6F.63839%jarret.raim@rackspace.com>',NULL),('<1367600573.99610.YahooMailNeo@web163805.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 10:02:53',-25200,'2013-05-03 17:02:53',NULL,'[openstack-dev] [barbican] CloudKeep API','> >How are the tenant IDs populated in the database?\n> \n> Our current plan is to silently create the tenant_id once the user\'s first\n> call has validated against keystone. E.g. If you have our endpoint in\n> keystone, we\'ll create the tenant. The tenant_id is going to just be a \n> varchar with the data from keystone since, IIRC, the OpenStack provider\n> can use any values for tenant_ids so we can\'t rely on any particular\n> format.\n\nI was wondering how you were going to do that. The tenant ID is going to\ninitially be used to validate who can use a key? For volume encryption I will \nneed to make sure I can use the same tenant ID for both. Ideally I would use\nthe user\'s tenant ID, but this could be a problem if I cannot get access to it\nfor both the creation and retrieval of the key. \n\nThanks for clearing up the content-types questions. That makes sense to me. Do\nyou know if it will be a list or a map? \n\n-Nate\n\n\n','<CDA923BE.637DD%jarret.raim@rackspace.com>',NULL),('<1367600910.71862.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 10:08:30',-25200,'2013-05-03 17:08:30',NULL,'[openstack-dev] [Barbican] Use of Dogtag for Production Backend','> The second would utilize the Dogtag system\n> (http://pki.fedoraproject.org/wiki/PKI_Main_Page). Maintained by RedHat,\n> Dogtag is a Java web-app that offers many advantages including being\n> Common Criteria and FIPS certified, existing integrations with Hardware\n> Security Modules (HSMs) and a secure crypto storage platform all with a\n> ReSTish API. The current plan is that production implementations of\n> Barbican would use Dogtag as their backend, optionally paired with an HSM\n> for extra security. No one would interface directly with Dogtag, it would\n> be the tool that Barbican uses to store the keys.\n\n+1 \nThe FIPS certification and integration with HSMs sounds great.\n\n-Nate\n\n\n',NULL,NULL),('<1367605241.2976.184.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-03 14:20:41',-14400,'2013-05-03 18:20:41',NULL,'[openstack-dev] [barbican] Tech approach blueprint updated','On Fri, 2013-05-03 at 17:50 +0000, Jarret Raim wrote:\n\n> The people using our APIs will be devs. I tend to fall on the side of\n> allowing the app the power and expecting the user to make the correct\n> choices. Having a key expire and orphan data is a valid use case as well.\n> My thought on the expires feature is that once expired, the key is not\n> served at all, encryption of decryption. The key is dead. It may be a flag\n> on whether we allow recovery of expired keys or just delete them as soon\n> as they expire.\n\nWhat about backups ?\n\n> We might be able to mitigate this by allowing a per-secret setting on\n> whether we should store a history of key changes. Trades off security for\n> some safety. \n\nWhat is the security issue ?\n\n> >[\n> >7) Based on the input I got at the key manager design session, there was\n> >a request for the key manager to create symmetric keys.\n> >    A simple 256/512/1024 bit key should not take long to generate (but\n> >PKI pairs with a certificate would be a different story).\n> >    Would be nice to support a \"create\" key.\n> >    https:// ../get/{tenant_id}/secrets/new  or basically one with no uuid\n> >    Default expiration time, format ..\n> >    Or more parameters in the get url\n> >]\n> >\n> >A POST to secrets with the \'plain-text\' omitted could do a similar thing\n> >(i.e. have Barbican create the secret). However, this behavior would be\n> >inconsistent with other secret types (such as SSL certs), that have\n> >long-running asynchronous work flows to generate them.  The orders ->\n> >create-secret flow, though a bit clunky for quick-gen secrets, would at\n> >least be consistent. Yet another thing to query the community about.\n> \n> Barbican will be capable of creating a wide variety of keying material.\n> The order abstraction allows us to treat all create requests the same,\n> whether or not they require a longer processing workflow. I think it is\n> also cleaner to not clutter the secret schema with a bunch of provisioning\n> information, hence the concept of storing all provisioning information in\n> an Order schema, that is linked to the secret.\n> \n> So the current plan is that all key creations would hit the /orders\n> resource to submit an order. They would then poll the order resource until\n> the status is COMPLETE. At that point, the orders resource will have a uri\n> to a valid secret resource that can be retrieved.\n> \n> If people don\'t like this idea - speak up now :)\n\nWhat about supporting messaging and have notifications sent out via\nqueue as an alternative to polling ?\n\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CDA95FFA.638F1%jarret.raim@rackspace.com>',NULL),('<1367844149.87.1383718389726.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-06 06:13:09',0,'2013-11-06 06:13:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #52','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/52/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5acba10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5acba10>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x441d890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x441d890>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-264a0d30-849a-4a85-8569-9af8a869377f\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:12:37Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'37\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'37\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:12:37Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'37\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'37\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:12:37+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'37\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'37\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:12:37-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'37\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'37\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:12:37Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'37\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'37\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x640c710>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x25a6d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 84.47 secs:\n    21.44    TestGlanceControl.test_bouncing\n    16.76    TestBinGlanceCacheManage.test_queue\n    15.85    TestScrubber.test_delayed_delete\n    15.62    TestRootApi.test_version_configurations\n    14.81    TestBinGlance.test_results_filtering\n----------------------------------------------------------------------\nRan 932 tests in 700.615s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-52\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.jGK2dU8QF1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/52\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/52/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise28/52\n[SCP] Copying console log.\n\n\n','<974417259.80.1383631986828.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1367904091.3566.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 06:21:31',3600,'2013-05-07 05:21:31',NULL,'[openstack-dev] A proposal for RPC-friendly objects','Hi Dan,\n\nOn Mon, 2013-05-06 at 13:36 -0700, Dan Smith wrote:\n> We\'ve been working on some proof-of-concept code to do this, and I\'ve\n> written up a wiki page describing what we\'re trying to do:\n> \n>   https://wiki.openstack.org/wiki/ObjectProposal\n> \n> We\'d appreciate some feedback on the approach, as well as discussion\n> about whether something like this belongs in Oslo so that it can be\n> used by other projects.\n\nNice work!\n\nWrt Oslo, the serialization hook needs to go in from the start,\nobviously, but I\'d recommend developing the base object class in Nova in\na way (e.g. by abstracting away nova-isms) that it can easily be moved\nto Oslo later at the moment when another project wants to use it.\nStarting it in oslo-incubator when no other projects are using it would\njust be unnecessary overhead for you.\n\nCheers,\nMark.\n\n\n\n','<20130506133653.010cb680@caffeine.danplanet.com>',NULL),('<1367924878.3566.11.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 12:07:58',3600,'2013-05-07 11:07:58',NULL,'[openstack-dev] Where should utility services be started?','On Mon, 2013-05-06 at 22:38 +0000, Adrian Otto wrote:\n> In reference to the Oslo Wiki[1] , in the Incubation section,\n> principle number 2:\n> \n> \"The API is already in use by a number of OpenStack projects\"\n> \n> And in the Incubation section:\n> \n> \"The process of developing a new Oslo API begins by taking code which\n> is common to some OpenStack projects and moving it into the\n> oslo-incubator repository.\"\n> \n> Where should cross-project code be incubated in the phase *before* it\n> is implemented by multiple projects? The Heat and Nova teams are\n> working together on StructuredStateManagement[2] and want to start\n> something new, but are struggling to determine where to put it. This\n> is probably evolve into an Oslo library, but it\'s not obvious where it\n> should live in the mean time. Should it be a splinter off of Heat? In\n> Nova? Neither option seems quite right.\n\nIdeally, when a new API is proposed to Oslo, I\'d like to see it already\nsuccessfully in use by one project and that there is an immediate plan\n(preferably a WIP patch) for a second project to use it.\n\nIf there were WIP patches for two projects using the new API, that\'d be\ncool tool.\n\nSo, it really depends - do you want to tackle this first in the context\nof Heat and then adapt it for Nova? Or the other way around? Or tackle\nboth at once?\n\nPragmatically speaking, I\'d recommend you first make sure you understand\nNova\'s requirements, then start coding it in Heat but keep its\nimplementation generic and once it has gotten merged into Heat look to\nhaving Nova adopt it.\n\nBaby steps is what gets stuff done in OpenStack. The concern I\'d have\nwith tackling both projects at once is that you might put a tonne of\nwork into it and neither project adopts it.\n\nCheers,\nMark.\n\n\n\n','<2587F12E-A92C-4253-B1D3-43F08F2F9ACB@rackspace.com>',NULL),('<1367939402.31111.YahooMailNeo@web163804.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 08:10:02',-25200,'2013-05-07 15:10:02',NULL,'[openstack-dev] [barbican] Tech approach blueprint updated','> My thought here is that the expiration date is a hard datetime. It is not\n> required to be set, but if it is, they key should essentially\n> self-destruct once the time has passed. I think it should be up to the\n> provider what \'self-destructed\' means. It could be totally deleted and\n> unrecoverable, marked as deleted and recoverable via an alternate process\n> or only existing on backups and recoverable via a manual process.\n> Something like that.\n\n\n+1\n\nI think when the key expires that it should no longer be available.\n\n-Nate\n\n\n\n',NULL,NULL),('<1367941827.5477.YahooMailNeo@web163801.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 08:50:27',-25200,'2013-05-07 15:50:27',NULL,'[openstack-dev] [barbican] CloudKeep API - Updates','> We propose changing from \'orders\' to \'requests\'...so to request that Barbican\n> create a new secret (or start a process to generate a secret) clients would\n> issue a \'request\'. This seems more natural, and a bit less overused than \n> \'orders\'. \n\nI think request sounds more overused than orders. I was not that thrilled with \norders, but I do like it more than request. What about something like \nsecretfactory, secretgenerator, or something else along those lines? I\'m not\ntoo picky either way with whatever you pick.\n\n> The next step would be to provide the actual plain-text to encrypt/store in\n> Barbican, via a follow up PUT call to the new secret, with the Accept header\n> set to the mime-type above (say application/pem). This data would then be\n> encrypted and stored by Barbican. To address Malini\'s concern about wrecking\n> systems already using a key to encrypt their data, we may only allow one such \n> PUT request to happen per secret.\n\nI would like to see the put operation be one step. Making it two operations \nseems a bit forced and introduces more overhead, IMHO. Now the key manager server\nmust wait for another web request for the actual key. What about time outs, or\nif the second operation never happens. You are then in a weird state.\n\nI would specify the type, and include the bytes for it. Then you can do it all\nin one step. For instance, specify application/aes-256-cbc as mime type and \nthen include the bytes for the key. The server then stores the bytes, and it \ncan assume the bytes are in the format specified. Or do a check to make sure \nthey are formatted correctly to make it more secure.\n\n-Nate\n\n\n',NULL,NULL),('<1367944180.3566.45.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 17:29:40',3600,'2013-05-07 16:29:40',NULL,'[openstack-dev] [Oslo] Give CLI the priority over config files','On Fri, 2013-05-03 at 10:25 -0400, Monty Taylor wrote:\n> \n> On 05/03/2013 10:16 AM, Flavio Percoco wrote:\n> > Hi,\n> > \n> > NOTE: Recently, something similar to $topic was discussed[0] in this list.\n> > \n> > I was looking into a glance-manage \"bug\"[1] and found out that oslo.config\n> > gives priority to parameters configured in config files over the ones\n> > passed in the CLI (I missed the part that says: \"Option values in\n> > config files override those on the command line\"). Although I understand\n> > it was designed like that, I think this\n> > behaviour is wrong.\n> > \n> > Besides the fact that this is causing some confusion to CLI tools\n> > users (see glance-manage bug), it makes it impossible to define\n> > configuration parameters that are meant to be overridden by CLI\n> > arguments.\n> > \n> > That being said, I would like to propose to invert that behaviour and\n> > let CLI arguments override configuration parameters. Reasoning behind\n> > this is that it is already possible to define config parameters that\n> > are hidden from the CLI, which means that parameters that shouldn\'t be\n> > overridden by the CLI should not be exposed there.\n> \n> I agree. I believe the natural order of things is:\n> \n> - Default value in source code\n> - Overridden by value in config file\n> - Overridden by value in environment variable\n> - Overridden by value given as command line option\n> \n> Basically due to the relative permanence of each.\n\nI think you hit the nail on the head with \"the relative permanence of\neach\".\n\nWith a service started by the likes of systemd, the command line\narguments are the most permanent - you\'re much more likely to change the\nconfig file than the command line arguments used by the service.\n\nFor example, Fedora\'s systemd config for nova-api is:\n\n  /usr/bin/nova-api --config-file /etc/nova/nova.conf --logfile /var/log/nova/api.log\n\nand you\'d expect setting logfile in the config file to change the\nlocation of the log file.\n\nThe behaviour of gflags in this case was determined by where on the\ncommand line the config file was specified - we don\'t have a way to do\nthat in cfg, but maybe we could figure it out.\n\nThe \"permanence order\" seems reversed in the case  of tools like\nnova-manage. So, maybe the solution is to have a flag which specifies\nthe order and CLIs like nova-manage would set that flag, but the\nbehaviour of services would stay the same.\n\nCheers,\nMark.\n\n\n\n','<5183C8EC.90303@inaugust.com>',NULL),('<1367946680.290931316@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-07 12:11:20',-18000,'2013-05-07 17:11:20',NULL,'[openstack-community] Interest in participating in LinuxCon/CloudOpen Europe in October?','\n\n\n\nHi all,  [http://events.linuxfoundation.org/events/linuxcon-europe] LinuxCon & [http://events.linuxfoundation.org/events/cloudopen-europe] Cloud Open Europe (co-located conferences), are coming to Edinburgh, UK on October 21-23.  We are considering sponsoring Cloud Open if there is interest and willingness from the European community to help staff a booth. If you are able to participate as a booth volunteer or in any other way, please let me know.\n \nAlso, please submit speaking proposals for OpenStack talks by July 21 at [http://events.linuxfoundation.org/events/cloudopen-europe/cfp] http://events.linuxfoundation.org/events/cloudopen-europe/cfp\n \nThank you!\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130507/a61b715a/attachment.html>\n\n',NULL,NULL),('<1367947274.20220.43.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 13:21:14',-14400,'2013-05-07 17:21:14',NULL,'[openstack-dev] Gitweb integration for Gerrit reviews ?','I often want to see a patchset in review in its entirety without having\nto dump to a shell, fetch, format patch and then fire vim to see th full\npatch.\n\nIs there any plan on integrating gerrit with webgit or similar so the\npatch can be seen via browser directly ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n',NULL,NULL),('<1367948495.20220.45.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 13:41:35',-14400,'2013-05-07 17:41:35',NULL,'[openstack-dev] Gitweb integration for Gerrit reviews ?','On Tue, 2013-05-07 at 17:35 +0000, Mac Innes, Kiall wrote:\n> On 07/05/13 18:31, Simo Sorce wrote:\n> \n> I often want to see a patchset in review in its entirety without having\n> to dump to a shell, fetch, format patch and then fire vim to see th full\n> patch.\n> \n> Is there any plan on integrating gerrit with webgit or similar so the\n> patch can be seen via browser directly ?\n> \n> Simo.\n> \n> \n> \n> Like this? :)\n> \n> https://review.openstack.org/gitweb?p=openstack%2Foslo-incubator.git;a=commitdiff;h=3a3970fa96d01cd88e68c968f08e5713ee3a7a66\n> \n> Next to each patchset, you\'ll see a \"(gitweb)\" link..\n\nPardon my blindness, I serached before visually and could never find it.\nAfter your mail I did an actual search on the page for gitweb and\nfinally saw it.\n\nThanks a lot, this is a life saver and will make me hate gerrit a little\nbit less :)\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<2CA92712C6DFEB4D8C2818165644367105E344FF@G9W0341.americas.hpqcorp.net>',NULL),('<1367958075.3566.55.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 21:21:15',3600,'2013-05-07 20:21:15',NULL,'[openstack-dev] A proposal for RPC-friendly objects','On Tue, 2013-05-07 at 10:01 -0700, Dan Smith wrote:\n> > Wrt Oslo, the serialization hook needs to go in from the start,\n> > obviously, but I\'d recommend developing the base object class in Nova\n> > in a way (e.g. by abstracting away nova-isms) that it can easily be\n> > moved to Oslo later at the moment when another project wants to use\n> > it. Starting it in oslo-incubator when no other projects are using it\n> > would just be unnecessary overhead for you.\n> \n> Cool, that sounds good to me.\n> \n> Right now, we embed special fields in the serialized version of the\n> object, such as \"nova_object.name\" (like the VERSION_KEY stuff does\n> with \"oslo.version\"). Should we go ahead and use \"oslo\" in such things\n> as we\'re cooking this up in nova so that the move to oslo is easy?\n\nIt depends whether you want it to be \'nova\' or \'oslo\' when this ends up\nin a proper library - the former makes sense where you want each project\nto have its own namespace (e.g. control_exchange to namespace topics)\nand the former makes sense where you want interop between projects (e.g.\nthe keys of the RPC message envelope)\n\nCheers,\nMark.\n\n\n\n','<20130507100133.1860236d@caffeine.danplanet.com>',NULL),('<1367958681.20220.47.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 16:31:21',-14400,'2013-05-07 20:31:21',NULL,'[openstack-dev] [keystone][nova] New blueprint related to message\n	security','New blueprint:\nhttps://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n\nThis is the server part needed to implement Message Security for Havana.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n',NULL,NULL),('<1367990516.3566.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-08 06:21:56',3600,'2013-05-08 05:21:56',NULL,'[openstack-dev] A proposal for RPC-friendly objects','On Tue, 2013-05-07 at 16:01 -0700, Dan Smith wrote:\n> > \'args\': {\n> >     \'arg1\': {\n> >         \'oslo.object_name\': \'nova.MyObject\',\n>\n> That looks good to me.\n\nYep.\n\n\n> > jsonutils.dumps() will automatically call jsonutils.to_primitive() on\n> > anything that is not a primitive type.  We could add a check in there\n> > to see if the object has a to_primitive() method and if so, call that.\n> \n> Hmm, I\'ll have to look at this a bit. I had it hacked into RpcProxy,\n> since we have easy access to the args, each of which we can check for\n> object-ness and serialize as needed. I liked this because of the\n> symmetry of putting the deserialization in RpcDispatcher. Just to be\n> clear, you\'re suggesting keeping jsonutils.to_primitive() and making it\n> stop recursing at an object with to_primitive() and call that instead?\n>  \n> > On the deserialize side, there\'s no hook really.  You could subclass\n> > RpcDispatcher, override the dispatch() method and do it there, and\n> > then let the base dispatch() do its thing after you do\n> > deserialization magic.\n> \n> Yeah, that was the plan. Would it be better to add \"serialize_args()\"\n> and \"deserialize_args()\" to Proxy and Dispatcher so that it\'s all in\n> one place and very clear?\n\nIf you look at my WIP re-design of the RPC API:\n\nhttps://github.com/markmc/oslo-incubator/commit/1f2f7fab\n\nyou\'ll see that Proxy and Dispatcher basically become rpc.Client and\nrpc.Server - users of those APIs only deal in Python method calls which\nthe rpc layer serialize to and from dicts which it passes down to the\nmessaging layer.\n\nI guess you\'re wondering whether to have the messaging layer just deal\nwith dicts of primitives and require the rpc layer to serialize objects\nto primitives, or do it all at the messaging layer.\n\nI like the simplicity of messaging dealing with dicts of primitives. We\ncan re-use support the same object serialization method at the\nnotifications layer too. Can see the argument for just doing it all at\nthe messaging layer, though.\n\nCheers,\nMark.\n\n\n\n','<20130507160134.3bc3c71d@caffeine.danplanet.com>',NULL),('<1367991558.3566.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-08 06:39:18',3600,'2013-05-08 05:39:18',NULL,'[openstack-dev] [openstack-tc] Proposal for API version\n discovery','On Tue, 2013-05-07 at 15:44 -0700, Vishvananda Ishaya wrote:\n> Basically our goal is to provide a way for clients to determine what actions\n> are available on a server. Essentially this means a few things:\n> \n> A) what resources are available\n> B) what actions can be performed on those resources\n> C) what (url) parameters are available?\n> D) what is the structure of the request/response?\n> \n> HATEOS seems to provide the cleanest solution for A)\n\nKind of a random side-bar, but I\'ve always felt that HATEOAS is actually\nclaiming to be the solution to all of this ... but I\'ve never seen a\ncomplete implementation of my understanding of the idea.\n\nThe term is \"hypermedia as the engine of application state\" meaning\n(IMHO) that the interface to making the application change state is the\nhypertext itself ... and if the interface for a specific action isn\'t in\nthe hypertext, the client knows it\'s not available.\n\nFor e.g. (c), I keep thinking of a HTML form - you know what parameters\ncan be POSTed to the URL in a form because the form describes those\nparameters pretty richly. Wouldn\'t it make sense for a REST API to have\nsomething similar? You allow the parameters to be discoverable by their\npresence in the \"form\".\n\nCheers,\nMark.\n\n\n\n','<7656BCCB-A406-47DD-8D69-A81FD19474C3@gmail.com>',NULL),('<1367991558.3566.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-08 06:39:18',3600,'2013-05-08 05:39:18',NULL,'[openstack-tc] [openstack-dev] Proposal for API version\n discovery','On Tue, 2013-05-07 at 15:44 -0700, Vishvananda Ishaya wrote:\n> Basically our goal is to provide a way for clients to determine what actions\n> are available on a server. Essentially this means a few things:\n> \n> A) what resources are available\n> B) what actions can be performed on those resources\n> C) what (url) parameters are available?\n> D) what is the structure of the request/response?\n> \n> HATEOS seems to provide the cleanest solution for A)\n\nKind of a random side-bar, but I\'ve always felt that HATEOAS is actually\nclaiming to be the solution to all of this ... but I\'ve never seen a\ncomplete implementation of my understanding of the idea.\n\nThe term is \"hypermedia as the engine of application state\" meaning\n(IMHO) that the interface to making the application change state is the\nhypertext itself ... and if the interface for a specific action isn\'t in\nthe hypertext, the client knows it\'s not available.\n\nFor e.g. (c), I keep thinking of a HTML form - you know what parameters\ncan be POSTed to the URL in a form because the form describes those\nparameters pretty richly. Wouldn\'t it make sense for a REST API to have\nsomething similar? You allow the parameters to be discoverable by their\npresence in the \"form\".\n\nCheers,\nMark.\n\n\n\n','<7656BCCB-A406-47DD-8D69-A81FD19474C3@gmail.com>',NULL),('<1368022303.382626484@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-08 10:11:43',-14400,'2013-05-08 14:11:43',NULL,'[openstack-dev] [Oslo] Give CLI the priority over config files','\n+1 to the \"permanence order\" change\n \nI think it\'s important we keep something like this as simple as possible. So I\'m against taking CLI argument order into account or having a flag that changes how it works. The more rules we put into this behavior the more confusing it will be for deployers and users. As for backward compat, I do believe it to be a version thing because some sort of middle ground doesn\'t make sense here.\n \n-Alex\n \n-----Original Message-----\nFrom: \"Flavio Percoco\" <flavio at redhat.com>\nSent: Tuesday, May 7, 2013 4:44pm\nTo: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Oslo] Give CLI the priority over config files\n\n\n\nOn 07/05/13 17:29 +0100, Mark McLoughlin wrote:\n>On Fri, 2013-05-03 at 10:25 -0400, Monty Taylor wrote:\n>> I agree. I believe the natural order of things is:\n>>\n>> - Default value in source code\n>> - Overridden by value in config file\n>> - Overridden by value in environment variable\n>> - Overridden by value given as command line option\n>>\n>> Basically due to the relative permanence of each.\n>\n>The \"permanence order\" seems reversed in the case  of tools like\n>nova-manage. So, maybe the solution is to have a flag which specifies\n>the order and CLIs like nova-manage would set that flag, but the\n>behaviour of services would stay the same.\n\nWhile I see the issues here, I still think this change should happen.\nA way to keep backward compatibility would be to pinned (don\'t kill\nme) stable branches and let his change land.\n\nI thought a bit more about the flag and I don\'t think having it is a\ngood idea. TBH, I\'d be ok with it if the default behavior is giving\npriority to the CLI and the flag just reverses that but, I\'d\ndefinitely prefer not having it. There should be just one way to\nmanage configs and CLI arguments, IMHO.\n\nCheers,\nFF\n\n-- \n{ name: \"Flavio Percoco\",\n gpg: \"87112EC1\", \n internal: \"8261386\",\n phone: \"+390687502386\",\n irc: [\"fpercoco\", \"flaper87\"]}\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130508/f5d82cd9/attachment.html>\n\n','<20130507204412.GK30965@redhat.com>',NULL),('<1368026141.3566.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-08 16:15:41',3600,'2013-05-08 15:15:41',NULL,'[openstack-dev] Where should utility services be started?','On Wed, 2013-05-08 at 14:59 +0000, Adrian Otto wrote:\n> Mark,\n> \n> On May 7, 2013, at 4:12 AM, \"Mark McLoughlin\" <markmc at redhat.com> wrote:\n> \n> > On Mon, 2013-05-06 at 22:38 +0000, Adrian Otto wrote:\n> >> In reference to the Oslo Wiki[1] , in the Incubation section,\n> >> principle number 2:\n> >> \n> >> \"The API is already in use by a number of OpenStack projects\"\n> >> \n> >> And in the Incubation section:\n> >> \n> >> \"The process of developing a new Oslo API begins by taking code which\n> >> is common to some OpenStack projects and moving it into the\n> >> oslo-incubator repository.\"\n> >> \n> >> Where should cross-project code be incubated in the phase *before* it\n> >> is implemented by multiple projects? The Heat and Nova teams are\n> >> working together on StructuredStateManagement[2] and want to start\n> >> something new, but are struggling to determine where to put it. This\n> >> is probably evolve into an Oslo library, but it\'s not obvious where it\n> >> should live in the mean time. Should it be a splinter off of Heat? In\n> >> Nova? Neither option seems quite right.\n> > \n> > Ideally, when a new API is proposed to Oslo, I\'d like to see it already\n> > successfully in use by one project and that there is an immediate plan\n> > (preferably a WIP patch) for a second project to use it.\n> > \n> > If there were WIP patches for two projects using the new API, that\'d be\n> > cool tool.\n> > \n> > So, it really depends - do you want to tackle this first in the context\n> > of Heat and then adapt it for Nova? Or the other way around? Or tackle\n> > both at once?\n> > \n> > Pragmatically speaking, I\'d recommend you first make sure you understand\n> > Nova\'s requirements, then start coding it in Heat but keep its\n> > implementation generic and once it has gotten merged into Heat look to\n> > having Nova adopt it.\n> > \n> > Baby steps is what gets stuff done in OpenStack. The concern I\'d have\n> > with tackling both projects at once is that you might put a tonne of\n> > work into it and neither project adopts it.\n> \n> We have contributors from four companies in both Nova and Heat\n> projects working together on this one with a spirit of collaboration\n> that I have never before experienced. It would be extremely inspiring\n> if we could find a way to make this work. The amount of red tape is\n> getting to the point where it is now hindering innovation. There are\n> plenty of smart developers on this effort who simply can\'t see a clear\n> path to proceed.\n> \n> Can we expect either Heat or Nova to accept patches that require code\n> from a StackForge project? If not, then we have a rather serious\n> paradox here.\n\nThis is all rather abstract. If there was a patch, github branch, chunk\nof code in one of the projects, whatever ... that people from multiple\nprojects were eager to consume, I could help with the specifics.\n\nCheers,\nMark.\n\n\n\n','<F2C756AF-89CC-4473-BBA2-8B4FF68C49D0@rackspace.com>',NULL),('<1368032933.20220.72.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-08 13:08:53',-14400,'2013-05-08 17:08:53',NULL,'[openstack-dev] [keystone][nova] New blueprint related to\n message security','On Wed, 2013-05-08 at 15:55 +0000, Jarret Raim wrote:\n> On 5/7/13 3:31 PM, \"Simo Sorce\" <simo at redhat.com> wrote:\n> \n> \n> >New blueprint:\n> >https://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n> >\n> >This is the server part needed to implement Message Security for Havana.\n> \n> I agree that Keystone should own the assignment of keys to accounts for\n> use in authentication and the /kds endpoint seems fine to me, but I would\n> suggest that instead of keystone returning the keying material directly,\n> it just return a URI to the barbican API.\n\n> When we talked about key management at the design summit, it seemed like\n> Keystone didn\'t want to take on a lot of the secure storage (common\n> criteria, fips) stuff or the logging & auditing requirements for a key\n> management solution. If Keystone uses Barbican as its backend store for\n> keys (while still owning the lifecycle of those keys and the mapping of\n> those to services) that seems to make the most sense?\n> \n> \n> \n> Thoughts?\n\nWe already have too many moving parts in this project, and bouncing one\nrequest to another server just adds latency (keys are sourced at the\ntime you need to send a message) and I do not see what is the benefit of\nsplitting storage this way.\nCurrently the only thing I store is a key, and the KDS does key\nderivation and returns a ticket containing a session key. It\'s all it\ndoes.\nAs a second step it will also start doing some simple ACL to handle\ntemporary group keys. But those keys are created on the spot and need no\nlong term storage.\n\nI rather keep the hole thing simple and in one place.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CDAFC351.640BE%jarret.raim@rackspace.com>',NULL),('<1368077609.2331.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 06:33:29',3600,'2013-05-09 05:33:29',NULL,'[openstack-dev] [openstack-tc] Proposal for API\n	version	discovery','On Wed, 2013-05-08 at 18:59 +0000, Gabriel Hurley wrote:\n> > -----Original Message-----\n> > From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]\n> > Sent: Tuesday, May 07, 2013 3:44 PM\n> \n> > It is relatively easy to include the info at servers/<uuid> however:\n> > {\n> >  \"features\": [\"OS-EXT-SRV-ATTR\", \"os-start-stop\"],\n> >  \"server\": {\n> >    \"OS-EXT-SRV-ATTR:host\": \"1169a68456af48238da47b1d5957a714\",\n> >    \"OS-EXT-SRV-ATTR:hypervisor_hostname\": \"fake-mini\",\n> >    \"OS-EXT-SRV-ATTR:instance_name\": \"instance-00000001\",\n> >    \"links\": [\n> >      {\"rel\": \"self\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980\"},\n> >      {\"rel\": \"start\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980/start\"\n> >       \"feature\": \"os-start-stop\"},\n> >      {\"rel\": \"stop\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980/stop\"\n> >       \"feature\": \"os-start-stop\"}.\n> >    ]\n> >   }\n> > }\n> \n> Tht perfectly illustrates my biggest concern with doing this on a\n> per-resource basis.\n\nPer-resource does allow you to expose whether a user has permission to\nperform an action, though.\n\n>  The list of \"links\" gets unconscionably enormous. If I do a \"list\"\n> call and retrieve 100 instances each with 100 links because you have\n> 20 extensions the whole thing becomes a mess. I think it\'s much more\n> sane (though less explicit) to understand what\'s provided by the\n> service and extrapolate that to the individual resources therein.\n\nYeah, lots of links can be messy. How about URI templates?\n\nMaybe we have them as a /capabilities/templates resource:\n\n  {\"templates\": [\n     {\"rel\": \"server_start_action\",\n      \"href\": \"http://example.org/v3/servers/{server_uuid}\"\n     }\n  ]}\n\nthen just do:\n\n  \"links\": [\n    {\"rel\": \"start\", \"template\": \"server_start_action\"}\n  ]\n\nJust a thought ...\n\nCheers,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F2365B34A8C1@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1368077609.2331.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-05-09 06:33:29',3600,'2013-05-09 05:33:29',NULL,'[openstack-tc] [openstack-dev] Proposal for API\n	version	discovery','On Wed, 2013-05-08 at 18:59 +0000, Gabriel Hurley wrote:\n> > -----Original Message-----\n> > From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]\n> > Sent: Tuesday, May 07, 2013 3:44 PM\n> \n> > It is relatively easy to include the info at servers/<uuid> however:\n> > {\n> >  \"features\": [\"OS-EXT-SRV-ATTR\", \"os-start-stop\"],\n> >  \"server\": {\n> >    \"OS-EXT-SRV-ATTR:host\": \"1169a68456af48238da47b1d5957a714\",\n> >    \"OS-EXT-SRV-ATTR:hypervisor_hostname\": \"fake-mini\",\n> >    \"OS-EXT-SRV-ATTR:instance_name\": \"instance-00000001\",\n> >    \"links\": [\n> >      {\"rel\": \"self\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980\"},\n> >      {\"rel\": \"start\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980/start\"\n> >       \"feature\": \"os-start-stop\"},\n> >      {\"rel\": \"stop\",\n> >       \"href\":\"http://example.org/v3/servers/009e9aca-b765-11e2-855a-\n> > 008cfa10b980/stop\"\n> >       \"feature\": \"os-start-stop\"}.\n> >    ]\n> >   }\n> > }\n> \n> Tht perfectly illustrates my biggest concern with doing this on a\n> per-resource basis.\n\nPer-resource does allow you to expose whether a user has permission to\nperform an action, though.\n\n>  The list of \"links\" gets unconscionably enormous. If I do a \"list\"\n> call and retrieve 100 instances each with 100 links because you have\n> 20 extensions the whole thing becomes a mess. I think it\'s much more\n> sane (though less explicit) to understand what\'s provided by the\n> service and extrapolate that to the individual resources therein.\n\nYeah, lots of links can be messy. How about URI templates?\n\nMaybe we have them as a /capabilities/templates resource:\n\n  {\"templates\": [\n     {\"rel\": \"server_start_action\",\n      \"href\": \"http://example.org/v3/servers/{server_uuid}\"\n     }\n  ]}\n\nthen just do:\n\n  \"links\": [\n    {\"rel\": \"start\", \"template\": \"server_start_action\"}\n  ]\n\nJust a thought ...\n\nCheers,\nMark.\n\n\n\n','<BD35DBE010D5B64589500D43F775F2365B34A8C1@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1368093090.2331.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 10:51:30',3600,'2013-05-09 09:51:30',NULL,'[openstack-dev] [OpenStack][Cinder-Core]Nomination for Cinder\n core members','On Wed, 2013-05-08 at 16:00 -0400, Russell Bryant wrote:\n> On 05/08/2013 02:13 PM, Sheng Bo Hou wrote:\n> > Hi Cinder contributors,\n> > \n> > I would like to be a bit immodest to nominate Vincent Hou, myself as a\n> > core contributor for OpenStack Block Storage(Cinder) project.\n> > \n> > Last October, I began my work in cinder by testing and looking for bugs.\n> > Then, by implementing the blueprint and fixing bugs. After that, I\n> > started reviewing the patches. I took some screenshots from the\n> > Launchpad website, indicating my contribution and how active I am in\n> > cinder community. You can find my name in the list of the ranking.\n> > \n> > Please take a look at the snapshots below. They are why I think I can be\n> > qualified core member. I sincerely hope OpenStack Cinder community can\n> > take me into consideration for a new core member. Thank you very much.\n> > \n> > PS:\n> > 1. Here are some of the snapshots for the patches I reviewed:\n> \n> Screenshots are kind of a bizarre way to do this ... I think links to\n> relevant pages would have sufficed.  :-)\n> \n> This message prompted me to take a look at who is doing Cinder reviews.\n>  I\'m not on cinder-core, so I don\'t really get a vote, but I\'ll provide\n> some commentary anyway.  :-)\n> \n> Review numbers aren\'t the only metric, but they are something.  When I\n> look at these things, I\'m looking for some indication of how involved\n> people are, as well as whether people are putting effort into providing\n> good constructive feedback with -1/-2, or if they are just rubber\n> stamping things (primarily just +1/+2).\n> \n> Dolph Mathews summarized core member criteria *really* well in another\n> thread when he said:\n> \n> > Ultimately, \"core contributor\" to me simply means that this person\'s downvotes on code reviews are consistently well thought out and meaningful, such that an upvote by the same person shows a lot of confidence in the patch.\n> \n> I think that is a *great* way to summarize the criteria that should be used.\n> \n> The numbers for the last 90 days are here (please correct me if the\n> cinder-core members are marked incorrectly)\n\nThis is really useful data. I think it\'s interesting to compare across\nprojects, so I\'ve posted the same same 90 days stats for nova here:\n\n  https://gist.github.com/markmc/5546607\n\nSome comments below.\n\n> The line for the self-nomination here is:\n> \n> |     houshengbo    |       54 (0|2|52|0) (96.3%)       |\n> \n> \n> ** -- cinder-core team member\n> +-------------------+-----------------------------------+\n> |      Reviewer     | Reviews (-2|-1|+1|+2) (+/- ratio) |\n> +-------------------+-----------------------------------+\n> |  john-griffith ** |     307 (13|27|1|266) (87.0%)     |\n\nLooks like John has a massive reviewer burden. He\'s doing far more\nreviews than anyone else.\n\n> |   avishay-il **   |      109 (1|28|46|34) (73.4%)     |\n> |  zhiteng-huang ** |       80 (3|14|5|58) (78.8%)      |\n> |      rushiagr     |       75 (0|11|64|0) (85.3%)      |\n> |     thingee **    |       71 (0|19|8|44) (73.2%)      |\n> |  duncan-thomas ** |       66 (0|15|3|48) (77.3%)      |\n> |     houshengbo    |       54 (0|2|52|0) (96.3%)       |\n> |   kurt-f-martin   |       46 (0|10|36|0) (78.3%)      |\n> |      eharney      |       38 (0|7|31|0) (81.6%)       |\n> |   oliver-leahy-l  |       26 (0|6|20|0) (76.9%)       |\n\nJust looking at the top 10 reviewers, the +/- ratio is consistently\nabove 70% and averaging at ~80%.\n\nLooking at the top 15 nova reviews, the +/- ratio is consistently above\n60% and averages at ~75%.\n\nSo ... not a massive amount of difference between projects. I had looked\nat the review stats for the last 14 days of nova and the +/- ratio for\nsome were more like 40% so the cinder stats looked high to me at first.\n\nCheers,\nMark.\n\n\n\n','<518AAEF6.5000706@redhat.com>',NULL),('<1368101834.20220.82.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-09 08:17:14',-14400,'2013-05-09 12:17:14',NULL,'[openstack-dev] [keystone][nova] New blueprint related to\n message security','On Wed, 2013-05-08 at 20:38 +0000, Jarret Raim wrote:\n> On 5/8/13 12:08 PM, \"Simo Sorce\" <simo at redhat.com> wrote:\n> \n> >On Wed, 2013-05-08 at 15:55 +0000, Jarret Raim wrote:\n> >> On 5/7/13 3:31 PM, \"Simo Sorce\" <simo at redhat.com> wrote:\n> >> \n> >> \n> >> >New blueprint:\n> >> >https://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n> >> >\n> >> >This is the server part needed to implement Message Security for\n> >>Havana.\n> >> \n> >> I agree that Keystone should own the assignment of keys to accounts for\n> >> use in authentication and the /kds endpoint seems fine to me, but I\n> >>would\n> >> suggest that instead of keystone returning the keying material directly,\n> >> it just return a URI to the barbican API.\n> >\n> >> When we talked about key management at the design summit, it seemed like\n> >> Keystone didn\'t want to take on a lot of the secure storage (common\n> >> criteria, fips) stuff or the logging & auditing requirements for a key\n> >> management solution. If Keystone uses Barbican as its backend store for\n> >> keys (while still owning the lifecycle of those keys and the mapping of\n> >> those to services) that seems to make the most sense?\n> >> \n> >> \n> >> \n> >> Thoughts?\n> >\n> >We already have too many moving parts in this project, and bouncing one\n> >request to another server just adds latency (keys are sourced at the\n> >time you need to send a message) and I do not see what is the benefit of\n> >splitting storage this way.\n> \n> I think the value is in all the work that Keystone is not planning on\n> doing. For example:\n> \n> * Secure storage including key encryption keys and access control\n> * Auditing & logging of key storage, accesses, etc.\n> * Common Criteria & FIPS certifications (capable anyway - up to the\n> provider)\n> * Use of HSMs and other encryption products for secure storage and\n> generation\n> * Mitigation for entropy exhaustion\n> \n> There are more, but the goal of Barbican is to implement all the things we\n> need for secure key management so that all the other systems don\'t have\n> too. Keystone is, of course, welcome to do so, I\'m just saying that we\'ll\n> be solving those problems so there might not be a need to do it twice.\n> \n> As to the two request issue, I would assume any implementation would cache\n> the keys for message security for some period of time or at least the uri\n> to the key in barbican so it would only need to make the double request\n> infrequently. If worse comes to worse, we could have keystone make a\n> request to barbican to get the key and return it to the user to obviate\n> the need for the second request. I don\'t believe that\'s as clean and it\n> does make the transaction less secure (loss of auditing, more systems with\n> access to the key, etc), but it would be doable.\n> \n> >Currently the only thing I store is a key, and the KDS does key\n> >derivation and returns a ticket containing a session key. It\'s all it\n> >does.\n> >As a second step it will also start doing some simple ACL to handle\n> >temporary group keys. But those keys are created on the spot and need no\n> >long term storage.\n> \n> Barbican is designed to rely on consumers to associate keys to their\n> objects. E.g. We don\'t store what Cinder volume a key belongs to, Cinder\n> stores the barbican URI in the volume metadata. I agree that Keystone owns\n> the linking and the key itself, just suggesting the storage (and possibly\n> the creation) logic doesn\'t need to be duplicated.\n> \n> \n> >I rather keep the hole thing simple and in one place.\n> \n> I think that\'s what I\'m suggesting, I\'m just suggesting that the best\n> place for key storage and generation is in the system that is designed to\n> perform those operations rather than a system designed to manage\n> identities. \n> \n> Depending on what you need and when, Keystone might be the best option in\n> the short-term. I\'m just saying we are going to have to solve these issues\n> in Barbican and you might be able to take advantage of that work. I\'d be\n> happy to talk about exactly what you need if you are interested and we can\n> aim at delivering those features.\n\nI think we should definitely look at the similarities in the long term,\nbut I say it is a post-Havana perspective. Once we understand better the\nlimits and requirements and we know what is the performance profile of\nthe key distribution server and barbican for this type of operations.\n\nThe other reason not to rush towards barbican is that there is still a\nchance operational issues will push the solution to morph from shared\nkey to public-key type or even a mix of the two. So it is better to keep\nthe whole thing in one place until we discovered all the issues and\ntweak the scheme to our needs. Coordinating more projects is a burden\nthat would make the whole problem much harder to crack at this stage.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CDB01DA0.642AE%jarret.raim@rackspace.com>',NULL),('<1368142610.190711475@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-09 18:36:50',-18000,'2013-05-09 23:36:50',NULL,'[openstack-community] Booth staff assistance at HostingCon in\n	Austin, June 18-19','\n\nHi all, I\'m back once again asking for your support, especially from those of you with sizable Austin locations (Dell, HP, Rackspace, IBM - not to point y\'all out :-). \n \nOpenStack has a 10x10 booth at [http://www.hostingcon.com/] HostingCon 2013, which is June 17-19 at the Austin Convention Center.  We\'re also the official event t-shirt sponsor.  And board member Rob Hirschfeld from Dell is speaking on our behalf on the Pitfalls of Building Clouds panel on June 19 at 11am.\n \nI\'ll be on-site the whole time to set up, teardown and support our community members.  The Expo hours are\n \nTuesday, June 18 12noon - 6:30pm\nWednesday, June 19 12noon-4pm\n \nPlease let me know if you or your colleagues can speak to potential OpenStack service providers for a 3-4 hour shift on one or more of these two days.  As always, thank you very much. \n -- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130509/479804c7/attachment.html>\n\n',NULL,NULL),('<1368223162-sup-280@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-10 16:17:59',-25200,'2013-05-10 23:17:59',NULL,'[openstack-dev] [nova][ironic] making file injection optional /\n	removing it','Excerpts from Scott Moser\'s message of 2013-05-10 12:50:24 -0700:\n> On Wed, 8 May 2013, Michael Still wrote:\n> \n> > I would not say that file injection is a requirement at the moment for\n> > a nova hypervisor driver. In fact, there\'s been discussion for a\n> > couple of releases about turning it off for everyone. I\'d like to see\n> > it deprecated in Havana for removal in Incarceration [1] if at all\n> > possible. Some more discussion of if that\'s possible would be nice.\n> >\n> > However, I do think you need to support configdrive if you\'re not\n> > doing file injection. I say this because some deployments cannot use\n> > metadata server (for example, network policy may not allow instances\n> > to talk to infrastructure nodes). So, I think having that would be\n> > good.\n> \n> I spoke with Robert at the summit, and have thought about \"config-drive\"\n> and bare-metal provisioning a bit since.\n> \n> I really prefer openstack to generally offer a \"platform\" for images to\n> target.  Ie, the image is made so that it works well with openstack (it\n> reads data from config-drive or ec2-metadata) rather than openstack\n> making images work (file injection).\n> \n\n+1 image content never being introspected by OpenStack. They are bytes\nto be fed to a computer... be it kvm, xen, or a baremetal node.\n\n> In that direction, for bare-metal, what I thought makes most sense is the\n> following:\n>  * images from openstack\'s perspective are just a bunch of blocks (in raw\n>    format or qcow2 format) as opposed to a tarball of a root filesystem.\n>  * installation of that image, pretty much looks like this:\n>    convert-image-to-stdout input.img | dd if=- of=/dev/sda\n>  * The image, then is in charge of handling the partition table or\n>    otherwise making the OS boot.  Ie, your image is likely to be\n>    partitioned and have grub installed in the master boot record or GPT\n>    partitioned with EFI. The key thing here is that ironic pretty much\n>    doesn\'t care.\n>  * The \"communication\" mechanism from an image to ironic is via a\n>    partition that is identified. For example we might choose to require\n>    that there be a partition with a vfat filesystem.  In GPT, I think we\n>    can actually identify it better by expecting for there to be a label\n>    \'config-v2\'.  In DOS partition it would be \'Id\' of \'99\' (or something).\n> \n>  * After \'dd\' of the image, ironic would then re-read the partition\n>    tables, and search for this partition.\n>    If it finds it, it can insert data like the data that goes into\n>    config-drive-v2 (or some other format)\n>  * The OS, when it boots reads this new \"datasource\" and operates the same\n>    way it does with ec2 metadata or openstack configdrive.\n> \n> The benefits of this path are:\n>  a.) openstack has a \'contract\' of sorts with images, rather than mucking\n>      around inside them.\n>  b.) The OS can handle bootloading itself (as opposed to having openstack\n>      have to poke around inside looking for something name \'kernel\' or\n>      \'initrmafs\' or other such silly things. And also figure out what\n>      kernel cmdline parameters it should hve.\n>  c.) This can work for windows or bsd or whatever. The images are made for\n>      openstack.\n>\n\nIf I understand it right, the problem that file injection and config\ndrive are trying to solve is that the \"ec2 metadata\" service is not\nconsidered safe enough for some environments because:\n\na) MITM attacks from other tenants are in theory possible if they can\nspoof all of the right things.\nb) This requires that instances be able to reach some Nova API node that\nthen has access to the rest of the nova infrastructure.\n\nProblem \"b\" is pretty simple to solve in Nova by having a more clear\nhand-off between the sensitive bits of nova and the metadata service.\n\nMaking the partition solution above more useful than HTTP metadata\nservices for baremetal would also mean having a secure way to send\nthe image to the node to boot, or problem \"a\" will not be solved. With\nmetadata, we have a separation of concerns here by accepting that PXE\nand tftp are not secure and will need to be locked down, but the metadata\ncould be secure by simply using HTTPS.\n\nI\'m not sure why this would be superior to just implementing HTTPS\nmetadata services. Images can have PKI built in for authentication\nof the metadata host. This allows full control of the trust model by\nimage authors.\n\nTo me, HTTPS metadata is as simple as partitions and filesystems, and\nmore flexible.\n\n\n','<alpine.DEB.2.02.1305101533210.9342@brickies>',NULL),('<1368292062.4582.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-11 18:07:42',3600,'2013-05-11 17:07:42',NULL,'[openstack-dev] Oslo messaging API design','On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> I\'ve been working on gathering requirements and design ideas for a\n> re-design of Oslo\'s RPC and notifications API. The goals are:\n> \n>   1) A simple and easy to understand RPC abstraction which enables \n>      all of the intra project communication patterns we need for\n>      OpenStack\n> \n>   2) It should be possible to implement the RPC abstraction using a \n>      variety of messaging transports, not just AMQP or AMQP-like\n> \n>   3) It should be a stable API with plenty of room for backwards \n>      compatible evolution in the future so that we can release it as a \n>      standalone library\n> \n> Here\'s what I have so far:\n> \n>   https://wiki.openstack.org/wiki/Oslo/Messaging\n\nJust a quick status update. We\'re using this etherpad to coordinate:\n\n  https://etherpad.openstack.org/HavanaOsloMessaging\n\nand this branch:\n\n  https://github.com/markmc/oslo-incubator/commits/messaging\n\nAt this point, we\'ve got a pretty solid API design, a working fake\ndriver and some simple test code.\n\nCheers,\nMark.\n\n\n\n','<1367230357.9418.19.camel@sorcha>',NULL),('<1368369038.11927140.1386209097596.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-04 21:04:57',-18000,'2013-12-05 02:04:57',NULL,'[Openstack-docs] Setting WIP by core-reviewers?','----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: openstack-docs at lists.openstack.org\n> Sent: Wednesday, December 4, 2013 3:05:12 PM\n> Subject: [Openstack-docs] Setting WIP by core-reviewers?\n> \n> During the review of creating openstack-doc-tools, I was asked whether\n> we want to have the ability to allow core-reviewers to set\n> Workinprogress on a patch. Currently only the owner can do that, this\n> ability give the core-reviewers this right as well.\n> \n> I can easily create a patch, just like to know whether you agree with me\n> moving ahead.\n> \n> If I send a patch, should I do it for all documentation projects\n> including the API ones as well?\n\nCan\'t see any downside to this, and some possible upside, so +1.\n\n\n','<529F8AF8.5000108@suse.com>',NULL),('<1368370373.480222615@emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-12 09:52:53',-18000,'2013-05-12 14:52:53',NULL,'[openstack-community] [OpenStack Marketing] New code name for\n	networks','\nAnd the foundation will try to vet and filter the list before the vote to reduce the likelihood of a repeat of the Quantum situation.  You can use me as the point of contact for that and I\'ll work with our trademark legal team.\n \n \n \nOn Sunday, May 12, 2013 8:14am, \"Mark McLoughlin\" <markmc at redhat.com> said:\n\n\n\n> On Sat, 2013-05-11 at 19:50 +0000, Jason Smith wrote:\n> > Hello,\n> > I understand why we had to give up Quantum code name but rather than\n> > just refer to it as networking let\'s come up with a new code name!\n> \n> Yes, this was discussed at the summit:\n> \n>   https://etherpad.openstack.org/ProjectsReNaming\n> \n> The conclusion was that a number of choices for a new name would be put\n> forward and that Quantum\'s contributors would vote for one of those\n> choices.\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> Marketing mailing list\n> Marketing at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/marketing\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130512/1a3cc093/attachment.html>\n\n','<1368364480.4153.1.camel@sorcha>',NULL),('<1368452003.10105.24.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-13 14:33:23',3600,'2013-05-13 13:33:23',NULL,'[openstack-dev] OS proliferation on PyPI','On Mon, 2013-05-13 at 15:08 +0200, Sascha Peilicke wrote:\n> Hi,\n> \n> while I appreciate the rationale behind the \"hacking\" package [0], could \n> we please rename this to openstack.hacking or alternatively transform it \n> into a more generic flake8.hacking? So far, we often just polluted the \n> PyPI namespace with randomly named packages that are very much \n> OS-specific. If such packages aren\'t meant to be consumed outside the OS \n> context or make little sense without, they probably shouldn\'t look like \n> they could.\n> \n> FWIW, It seems to be a somewhat similar issue to whats currently \n> discussed in th \"New code name for networks\" thread on the generic ML.\n> \n> Footnotes:\n>   [0] https://pypi.python.org/pypi/hacking\n\nhacking is intended not to be totally OpenStack specific, that\'s why it\nwasn\'t called e.g. oslo.hacking\n\nAll OpenStack pypi packages are tagged with the same environment so they\nshow up here:\n\n  https://pypi.python.org/pypi?:action=browse&c=583\n\nCheers,\nMark.\n\n\n\n','<5190E5BD.10001@suse.com>',NULL),('<1368457330.2389.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-13 16:02:10',3600,'2013-05-13 15:02:10',NULL,'[openstack-dev] Oslo messaging API design','Hey Doug,\n\nOn Mon, 2013-05-13 at 10:43 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Sat, May 11, 2013 at 1:07 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:\n>         > Hey\n>         >\n>         > I\'ve been working on gathering requirements and design ideas for a\n>         > re-design of Oslo\'s RPC and notifications API. The goals are:\n>         >\n>         >   1) A simple and easy to understand RPC abstraction which enables\n>         >      all of the intra project communication patterns we need for\n>         >      OpenStack\n>         >\n>         >   2) It should be possible to implement the RPC abstraction using a\n>         >      variety of messaging transports, not just AMQP or AMQP-like\n>         >\n>         >   3) It should be a stable API with plenty of room for backwards\n>         >      compatible evolution in the future so that we can release it as a\n>         >      standalone library\n>         >\n>         > Here\'s what I have so far:\n>         >\n>         >   https://wiki.openstack.org/wiki/Oslo/Messaging\n>         \n>         \n>         Just a quick status update. We\'re using this etherpad to coordinate:\n>         \n>           https://etherpad.openstack.org/HavanaOsloMessaging\n>         \n>         and this branch:\n>         \n>           https://github.com/markmc/oslo-incubator/commits/messaging\n>         \n>         At this point, we\'ve got a pretty solid API design, a working fake\n>         driver and some simple test code.\n> \n> \n> Have you given any thought to how the MessageHandlingServer can listen\n> on more than one target? That\'s an important use case for ceilometer,\n> which I didn\'t address in my earlier changes.\n> \n> \n> Do we need to support different transports (and drivers), or just\n> multiple targets?\n\nI guess I was thinking you\'d just create multiple servers, but you\nprobably really want a single executor and dispatcher pair with multiple\nlisteners.\n\nWould something like this work?\n\n    def start(self):\n        if self._executor is not None:\n            return\n        self._executor = self._executor_cls(self.conf, self.dispatcher)\n        self.listen(self.transport, self.target)\n	self._executor.start()\n\n    def listen(self, transport, target):\n        self._executor.add_listener(transport._listen(target))\n\nCheers,\nMark.\n\n\n\n','<CADb+p3TSBwmAAFCDe519+hw0YOCRaiKXiOQLM6pt6M-XZ7piDw@mail.gmail.com>',NULL),('<1368643292.26799.147.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 20:41:32',7200,'2013-05-15 18:41:32',NULL,'[openstack-dev] [Metrics] Notes on Dash of Development Activity','Hi all,\n\nThe OpenStack Development Dashboard (Dash of Development Activity) [1]\nis starting to be updated daily. For some days, you\'ll have to clean\nyour browser cache before you can access the new JSON files (and the new\ncharts), but this will be fixed shortly.\n\n[1] http://activity.openstack.org/dash/\n\nFor those of you interested in reproducing the dash in your own\nmachines, you can just clone the corresponding GitHub repository [2].\nThis repository, which is in fact the source for the Dash, will also be\nupdated daily. Once cloned, just serve it via HTTP and point your\nbrowser to it.\n\n[2] https://github.com/Bitergia/openstack-dashboard\n\nThis repository is basically a collection of HTML, JS and CSS files\nwhich provide the functionality of the Dash, and a set of JSON files\nwhich come from running the extraction tools daily. It is maintained\nmainly for easy of reversion in case of trouble, and for easily\nobtaining snapshots of the past. Of course you can version HTML, JS and\nCSS on your own, and still benefit from the new JSON files updated every\nday.\n\nFor those interested in reproducing from source, a couple of notes:\n\n- HTML, JS and CSS come from the openstack branch of vizGrimoireJS,\nwhich you can also get from GitHub [3]. You\'re welcome to upload pull\nrequests there to fix bugs and/or add new functionality.\n\n[3] https://github.com/VizGrimoire/VizGrimoireJS/tree/openstack\n\n- JSON files come from running vizGrimoreR [4] on the database produced\nby the MetricsGrimoire tools [5]. The exact procedure for getting the\nJSON files out of the OpenStack repositories will be detailed here in\nthe following days. For now, let the magic work, and get your JSON files\nupdated daily from [2], above.\n\n[4] https://github.com/VizGrimoire/VizGrimoireR\n\n[5] http://metricsgrimoire.github.io/\n\nPlease, file any bug report or wishlist which could be particular to\nOpenStack in the community Launchpad tracker, and/or discuss it here.\n\n[6] https://bugs.launchpad.net/openstack-community\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n',NULL,NULL),('<1368716731.15568019@emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-16 10:05:31',-18000,'2013-05-16 15:05:31',NULL,'[openstack-community] OpenStack in Africa (specifically Nairobi)','\nThat\'s very exciting news!  I\'d love to be involved.\n \n \n \nOn Thursday, May 16, 2013 2:43am, \"Adam Nelson\" <adam at varud.com> said:\n\n\n\nHello,\nWe\'re building a public OpenStack implementation in Nairobi and over time, the rest of the continent.  Is anybody on the list interested in talking about OpenStack in the African context or in starting a virtual meetup about it?  I\'d like to get more feedback about it and meet more people who are interested in the logistics of launching a cloud platform here.  I\'m also excited to get people not on the continent in the group if they have an interest.\nBased on feedback, I\'ll try to set up some sort of Hangout or something along those lines.  Just shoot me a line.\nCheers,\nAdam\n-------\nOpenStack in Africa: [http://kili.io] http://kili.io\n\n\n\nThoughts: [https://twitter.com/varud] https://twitter.com/varud\nAbout Me: [https://www.linkedin.com/in/adamcnelson] https://www.linkedin.com/in/adamcnelson\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130516/c832cc00/attachment-0001.html>\n\n','<CAGTm15=uKxnDMm846bk+dNUH=nr6LaY+_-jb9t-X=khf4Ohumg@mail.gmail.com>',NULL),('<1368728639.1004482@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-16 13:23:59',-18000,'2013-05-16 18:23:59',NULL,'[openstack-community] Interest in participating in LinuxCon/CloudOpen Europe in October?','\n\nThank, Dave.  I\'ll put you on the list for some hours.  eNovance and Rightscale have alo volunteered so we have secured a small sponsorship.  I\'ll probably travel over there to coordinate things.  Everyone else here will be heads down getting ready for the Hong Kong Summit.  Thanks again.  I\'ll be in touch.\n On Thursday, May 16, 2013 2:50am, \"Dave Neary\" <dneary at redhat.com> said:\n\n\n\n> Hi Kathy,\n> \n> Have you had success identifying volunteers? I would be happy to give a\n> few hours to man a booth in Edinburgh, but could not commit to\n> co-ordinating the booth.\n> \n> Thanks,\n> Dave.\n> \n> On 05/07/2013 07:11 PM, Kathy Cacciatore wrote:\n> > Hi all, LinuxCon\n> > <http://events.linuxfoundation.org/events/linuxcon-europe> & Cloud\n> Open\n> > <http://events.linuxfoundation.org/events/cloudopen-europe> Europe\n> > (co-located conferences), are coming to Edinburgh, UK on October 21-23.\n> > We are considering sponsoring Cloud Open if there is interest and\n> > willingness from the European community to help staff a booth. If you\n> > are able to participate as a booth volunteer or in any other way, please\n> > let me know.\n> >\n> >\n> >\n> > Also, please submit speaking proposals for OpenStack talks by July 21 at\n> > http://events.linuxfoundation.org/events/cloudopen-europe/cfp\n> >\n> >\n> >\n> > Thank you!\n> >\n> >\n> >\n> > --\n> > Regards,\n> >\n> > Kathy Cacciatore\n> > OpenStack Industry Event Planner\n> > 1-512-970-2807 (mobile)\n> > Part time: Monday - Thursday, 9am - 2pm US CT\n> > kathyc at openstack.org\n> >\n> >\n> > _______________________________________________\n> > Community mailing list\n> > Community at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> >\n> \n> --\n> Dave Neary - Community Action and Impact\n> Open Source and Standards, Red Hat - http://community.redhat.com\n> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13\n>\n\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130516/99323534/attachment.html>\n\n','<51948FBA.6010403@redhat.com>',NULL),('<1368800857.8098.13.camel@localhost>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-17 16:27:37',7200,'2013-05-17 14:27:37',NULL,'[openstack-qa] Documentation of tempest','On Fri, 2013-05-17 at 07:52 -0400, Sean Dague wrote:\n> I like your idea of adding metadata to test cases that we could generate \n> this later.\n> \n> One of the reasons I was writing all the \"Tempest Guide to .... \" files \n> as README.rst was I\'m planning on creating a docs job once we are done \n> that will rebuild qa.openstack.org to be a collection of those READMEs. \n> Going from rst -> html should be pretty easy, and will mean that changes \n> in the code will be the website.\n> \n> I think something equivalent like this could really be useful as well \n> and part of that publishing stream.\n> \n> Now it just needs a champion to dive in and make it happen! :)\n> \n\nI really like idea about this overview table, and I would like to do it.\nBut to get real data to do it, it would require all those tags/attrs in\nplace.\n\nSo for start I would like to start maybe from existing state:\n* create tool which generates table:\n  * for each tempest/tests subfolder\n  * mark columns for each where we have gate/smoke/positive/negative\nlabels\n* show how colors would like there and also the links to the source etc\n* in the meantime add those service-object/action labels\n  * probably in external github repo, just as example how it could look\nlike and see how many of those tags it would really require\n  * switch the table generation to those real tags\n* later this would have to be automated somehow (=>update repo on commit\nto tempest or to the descriptions if they would be kept separately)\n  * can we use service hook on github repo for this?\n\nAlso I\'m not sure about the possibility of maintaining those \'manually\'\nassigned states(colors).\n* it could be maintained somewhere in db etc, so it would require access\nauth etc etc\n* better would be to keep rst somewhere with service-object/action +\nstate + description ... that could be merged together with tags from\ntempest code and put together in that table\nMy main issue with this is, that it would require manual upkeep and that\nthose manually assigned states could divert from real state in tempest\ncode (like test cases rewritten/removed/whatever).\nBut whatever, this looks like thing that can be done as future\nimprovement.\n\n\n> 	-Sean\n> \n> On 05/17/2013 07:01 AM, Attila Fazekas wrote:\n> > I like the ACC model, but it looks like too high level overview for starting,\n> >   but it can be a good continuation.\n> >\n> > A simple model for mainly API testing can be good for now.\n> >\n> > Initial considerations:\n> > * We have services or components and and sub-part of this at API level.\n> >    (3D matrix mapped to 2D)\n> > * We have operations to test\n> > * We have things to verify\n> > * I would like to know is something missing or not covered properly\n> >\n> > I have constructed a matrix, than I simplified it.\n> >\n> > Something like below as a colored HTML table seams OK.\n> >\n> > ------------------------------------------------------------------------\n> > | component    | CRUD | list | associations | quota | security |  misc |\n> > ------------------------------------------------------------------------\n> > | nova-server  |      |      |              |       |          |       |\n> > ------------------------------------------------------------------------\n> > | swift-object |      |      |              |       |          |       |\n> > ------------------------------------------------------------------------\n> > | keystone-user|      |      |              |       |          |       |\n> > ------------------------------------------------------------------------\n> > | misc         |      |      |              |       |          |       |\n> > ------------------------------------------------------------------------\n> >\n> > CRUD: create, read, update, get\n> > list: list, list detailed, filtering, pagination\n> > misc: action , bulk-action\n> > security: tenant-isolates, admin-denied\n> > association: member, attach, assign\n> >\n> >\n> > * In every intersection we should have multiple links to the source\n> >    (github, automatically generated link).\n> > * One test case can be in multiple intersection\n> > * every line and row should have a short description\n> > * every intersection should have a short description\n> > * based on the description anyone can color the intersections\n> >    1. Black: Does not makes sense in this context\n> >    2. Red: completely missing\n> >    3. yellow: partially completed\n> >    4. light green: good progress\n> >    5. green: OK\n> >    6. white: unknown\n> >\n> > We could have tables for different API versions or CLI ..\n> >\n> > In theory if we add enough meta-data (attribute) on test cases to be map able\n> >   into this kind of table. The only paper work will be:\n> >\n> > * create short description about what we need to verify\n> >   (likely the columns will tell it alone)\n> > * Color the table\n> >\n> >\n> > Possible addition:\n> > * Links to additional resources like blueprints, bugs..\n> \n\n\n-- \nPavel Sedl?k <psedlak at redhat.com>\nRed Hat\n\n\n\n','<51961A13.5000906@dague.net>',NULL),('<1368803044.3586.93.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-17 10:04:04',-18000,'2013-05-17 15:04:04',NULL,'[openstack-dev] Copyright headers in source files','On Fri, 2013-05-17 at 01:00 -0700, Mark Washenberger wrote:\n> So, what do you think? Is this a bad idea? If so, why do you hate me?\n> Did copyright headers once save your kitty from a burning building?\n> Are you worried about consistency? If so, please explain why you\n> believe consistency is useful in this specific case to avoid a choice\n> Emerson quote.\n\nSo, I have one question: does this advice apply only to the copyright\nheader (\"Copyright 2013 OpenStack Foundation\") or does it apply to both\nthe copyright header AND the license header?  (To my mind, these are\nlogically two separate things?)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAJyP2C_DpTzsYbX0FshohOOaf_9LpXP_gc_tw-J+KDDU+QH__Q@mail.gmail.com>',NULL),('<1368803588.3586.97.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-17 10:13:08',-18000,'2013-05-17 15:13:08',NULL,'[openstack-dev] Tempest test merging','So, I\'ve just seen a patch[1] that had all its +2s expire; the reason it\nhadn\'t been approved is because it required a change to tempest[2], and\nalthough the tempest change also had +2s, it hadn\'t been approved\neither.  This makes it obvious that we need to come up with a better\nprocess for managing patches which require associated patches in other\nprojects, particularly when those other projects are gated.\n\nAny suggestions on how this process could be improved?\n\n[1] https://review.openstack.org/#/c/25887/\n[2] https://review.openstack.org/#/c/27043/\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1368804202-sup-1110@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-17 08:48:38',-25200,'2013-05-17 15:48:38',NULL,'[openstack-dev] Copyright headers in source files','Excerpts from Russell Bryant\'s message of 2013-05-17 07:23:08 -0700:\n> On 05/17/2013 10:07 AM, Brian Lamar wrote:\n> > I\'m genuinely curious why your first preference is for complete copyright headers after it\'s been determined they\'re not needed to preserve copyright. Can you expound on that? Perhaps I\'m misinterpreting markwash\'s statements.\n> \n> Because it gives some people warm fuzzies, and there\'s some value in\n> that.  The chance for recognition in public helps drive open source\n> contributions.  It also seems to be the norm.  It\'s done all over the\n> place, so I\'m just used to it.\n> \n> Admittedly that view seems outdated, though.  Since git maintains\n> history of commit authors, the headers seem to have more value for a\n> project using a a system like svn with only a few committers and no\n> tracking of who wrote the code other than what you write in the commit\n> message and leave in copyright headers.\n> \n\nGit does not follow the code through to tarballs and onto peoples\'\nsystems.  Also git does not express copyright assignment. Much of the code\nI write is work for hire for HP Cloud and thus they own the copyrights. To\nlook at git and determine that, one would have to know the dates of my\nemployment. This creates an ambiguity that a copyright notice does not.\n\nI understand that they get out of date. HP could sell the copyrights\nto another company, and even though my code says \"Copyright Hewlett\nPackard Development Corporation\" now it belongs to \"Fictional Future\nCorporation\". However, this still provides a bread crumb for anyone\nauditing the code to follow to HP, who can then make it clear they do\nnot own the rights and that they have transferred to FFC.\n\n> Anyway, I\'m not trying to argue for keeping them.  If everyone wants to\n> kill them, that is completely ok with me.\n> \n\nI think its fine to have them, or to not. I don\'t think it is a world\nending thing to have inaccurate and inconsistent copyright headers. We\nwill likely not have them anymore, but now we will just have inaccurate\nand inconsistent AUTHORS files and git logs.\n\nI do think they are useful in a tiny fraction of cases where the origin of\nmodified code is in dispute, especially when that code has been separated\nfrom its git/AUTHORS/LICENSE. However, if the cost of maintaining and/or\nreviewing them is deemed high, then it is probably worth it to just drop\nthem and make some kind of statement about this risk.\n\n\n','<51963D4C.1060601@redhat.com>',NULL),('<1368807168.3389175.1416251581675.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-17 14:13:01',-18000,'2014-11-17 19:13:01',NULL,'[Openstack] Ceilometer Api error in Juno','\n> Hello Eoghan,\n> \n> I have installed mongodb using below command as per the document.\n\nWhich document exactly?\n\n> 1. apt-get install mongodb-server   ( this case mongodb will not be installed)\n> \n> 2. apt-get install mongodb   :  if I use this , mongodb-server will automatically installed as a dependencies.  \n\nI suspect install this mongodb meta-package caused mongodb-clients to\ninstalled.\n\nWhereas the actual client-side dependency that ceilometer has is on\npython-pymongo, as opposed mongodb-clients.\n\nThis can be clearly seen from:\n\n  http://packages.ubuntu.com/trusty/python-ceilometer  \n\n[...]\n \n> If I won\'t delete sqlite db, all ceilometer data will be stored in sqlitedb. If I am wrong correct me , because I can see the size of the file increasing  .\n\nDeleting is not the key here, rather stopping ceilometer using\nsql-a to store data is what you need:\n\n 1. Ensure the connection_url in the ceilometer.conf is using a \n    mongodb URL[1]\n\n 2. Ensure the python-pymongo package is installed\n\n 3. Restart the services that use the metering store (ceilometer-api,\n    collector and notification-agent)\n\nCheers,\nEoghan\n\n[1] http://docs.openstack.org/developer/ceilometer/install/manual.html#mongodb\n \n> root at Control:/var/lib/ceilometer# du -sh *\n> 312K    ceilometer.sqlite\n> root at Control:/var/lib/ceilometer#\n> \n> \n> Thanks for your assistance.\n> \n> Regards,\n> Malleshi CN\n> \n> \n> -----Original Message-----\n> From: Eoghan Glynn [mailto:eglynn at redhat.com] \n> Sent: Monday, November 17, 2014 7:17 PM\n> To: Channappa Negalur, M.\n> Cc: openstack at lists.openstack.org\n> Subject: RE: [Openstack] Ceilometer Api error in Juno\n> \n> \n> You don\'t need to delete the sqlite DB, just configure the ceilometer.conf to use a mongodb connection URL.\n> \n> However it seems like you don\'t have all the mongodb client-side dependencies all installed.\n> \n> BTW how did you install mongodb?\n> \n> Looking at the Trusty packaging for python-ceilometer:\n> \n>   http://packages.ubuntu.com/trusty-updates/python/python-ceilometer\n> \n> I see that it depends on python-pymongo:\n> \n>   http://packages.ubuntu.com/trusty/python-pymongo\n> \n> which in turn depends on python-bson as expected:\n> \n>   http://packages.ubuntu.com/trusty/python-bson\n> \n> Can you check if those packages are installed?\n> \n>   $ sudo dpkg -s python-pymongo\n> \n> Cheers,\n> Eoghan\n> \n> ----- m channappa negalur <m.channappa.negalur at accenture.com> wrote:\n> > Hello Eoghan,\n> > \n> > Thanks for your reply. I have installed Juno on Ubuntu 14.04 .\n> > \n> > 1.How did you install ceilometer, using packages or direct from git?.\n> > Ans: I have installed it from Juno repsiotory.\n> > \n> > \n> > I want to configure ceilometer to use mongodb as a backend. Is it require to delete ceilometer.sqlite db  under /var/lib/ceilometer and also I need to remove it from the configuration /etc/ceilometer/ceilometer.conf.. ?\n> > \n> > If your answer is yes, then it will start throwing error as I mentioned below and ceilometer-api will stop running and 8777 port will stop listening to ceilometer-api.\n> > \n> > Please let me know how I can proceed further.\n> > \n> > \n> > This is the error I have received again.\n> > \n> > ==> ceilometer-collector.log <==\n> > 2014-11-17 13:05:26.808 937 ERROR stevedore.extension [-] Could not \n> > load \'database\': No module named bson.code\n> > 2014-11-17 13:05:26.809 937 ERROR stevedore.extension [-] No module \n> > named bson.code\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension Traceback (most recent call last):\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 162, in _load_plugins\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     verify_requirements,\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/named.py\", line 123, in _load_one_plugin\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     verify_requirements,\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 180, in _load_one_plugin\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     obj = plugin(*invoke_args, **invoke_kwds)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/ceilometer/dispatcher/database.py\", line 41, in __init__\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     self.storage_conn = storage.get_connection_from_config(conf)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 82, in get_connection_from_config\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     return get_connection(url, namespace)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 93, in get_connection\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     mgr = driver.DriverManager(namespace, engine_name)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 45, in __init__\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     verify_requirements=verify_requirements,\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/named.py\", line 55, in __init__\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     verify_requirements)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 170, in _load_plugins\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     self._on_load_failure_callback(self, ep, err)\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 50, in _default_on_load_failure\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension     raise err\n> > 2014-11-17 13:05:26.809 937 TRACE stevedore.extension ImportError: No \n> > module named bson.code\n> > \n> > \n> > Regards,\n> > Malleshi CN\n> > \n> > -----Original Message-----\n> > From: Eoghan Glynn [mailto:eglynn at redhat.com]\n> > Sent: Monday, November 17, 2014 5:31 PM\n> > To: Channappa Negalur, M.\n> > Cc: openstack at lists.openstack.org\n> > Subject: Re: [Openstack] Ceilometer Api error in Juno\n> > \n> > \n> > Hi,\n> > \n> > How did you install ceilometer, using packages or direct from git?\n> > \n> > If using packages, what OS are you working on? (Fedora, Ubuntu, CentOS \n> > etc.)\n> > \n> > Note that the bson.code module is provided by the python-bson package on Fedora, which is a dependency of python-pymongo, which is in turn required by the ceilometer packages.\n> > \n> > I suspect there is a similar dependency structure on Ubuntu.\n> > \n> > These dependencies are generally handled by the underlying package manager, i.e. the yum utility in the case of Fedora or CentOS.\n> > \n> > Cheers,\n> > Eoghan\n> > \n> > ----- m channappa negalur <m.channappa.negalur at accenture.com> wrote:\n> > > Hello Geeks,\n> > > \n> > > I have installed three node openstack Juno. I was configuring ceilometer using mongodb as back end.\n> > > \n> > > I found my ceilometer-api is not starting and throwing some module error.\n> > > \n> > > root at Control:/var/log/ceilometer# tail -50 ceilometer-api.log\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 170, in _load_plugins\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer     self._on_load_failure_callback(self, ep, err)\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 50, in _default_on_load_failure\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer     raise err\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer ImportError: No \n> > > module named bson.code\n> > > 2014-11-15 12:02:02.124 23900 TRACE ceilometer\n> > > 2014-11-16 22:22:30.649 17570 CRITICAL ceilometer [-] ImportError: \n> > > No module named bson.code\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer Traceback (most recent call last):\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/bin/ceilometer-api\", line 10, in <module>\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     sys.exit(main())\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/cmd/api.py\", line 23, in main\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     srv = app.build_server()\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 157, in build_server\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     app = load_app()\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 153, in load_app\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return deploy.loadapp(\"config:\" + cfg_file)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 247, in loadapp\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return loadobj(APP, uri, name=name, **kw)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 272, in loadobj\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return context.create()\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 710, in create\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return self.object_type.invoke(self)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 203, in invoke\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     app = context.app_context.create()\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 710, in create\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return self.object_type.invoke(self)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 146, in invoke\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return fix_call(context.object, context.global_conf, **context.local_conf)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/util.py\", line 55, in fix_call\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     val = callable(*args, **kw)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 181, in app_factory\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return VersionSelectorApplication()\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 104, in __init__\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     self.v2 = setup_app(pecan_config=pc)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 68, in setup_app\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     storage.get_connection_from_config(cfg.CONF, \'metering\'),\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 82, in get_connection_from_config\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return get_connection(url, namespace)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 93, in get_connection\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     mgr = driver.DriverManager(namespace, engine_name)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 45, in __init__\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     verify_requirements=verify_requirements,\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/named.py\", line 55, in __init__\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     verify_requirements)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 170, in _load_plugins\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     self._on_load_failure_callback(self, ep, err)\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 50, in _default_on_load_failure\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer     raise err\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer ImportError: No \n> > > module named bson.code\n> > > 2014-11-16 22:22:30.649 17570 TRACE ceilometer\n> > > \n> > > \n> > > Looking for some help..\n> > > \n> > > Regards,\n> > > Malleshi CN\n> > > \n> > > ________________________________\n> > > \n> > > This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n> > > ____________________________________________________________________\n> > > __\n> > > ________________\n> > > \n> > > www.accenture.com\n\n\n','<22778e9c9f2547d49af489e1e237bc9a@BY2PR42MB181.048d.mgd.msft.net>',NULL),('<1369042232.18206.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-20 11:30:32',7200,'2013-05-20 09:30:32',NULL,'[openstack-qa] gate/smoke tags','On Mon, 2013-05-20 at 11:00 +0200, Giulio Fidente wrote:\n> On 05/18/2013 02:24 PM, Christopher Yeoh wrote:\n> > Hi,\n> >\n> > I\'ve noticed with the recent changesets add gate/smoke tags that some\n> > tests have the gate tag, some have the smoke tag, and some have both.\n> > I\'m wondering if there are really cases where we intend on having a\n> > test in smoke but not gate?\n> >\n> > ie. Should we consider gate to be a superset of smoke and so not have\n> > to mark a test as gate if it is already tagged smoke?\n> \n> I noticed the discussion went further and changes have been made to \n> remove the smoke tag where also the gate was applied\n> \n> I\'m totally okay with that but I need some help understand the meaning \n> of \'smoke\'\n> \n> When should we set such a tag?\n\nNot sure if I missed additional change, but it does actually the\nopposite:\n- \'smoke\' is subset of \'gate\'\n  - so where the \'smoke\' is, it implies also the \'gate\'\n  - https://review.openstack.org/#/c/29688/\n- if it would in reverse as you point to:\n  - it would become \'addition\' set to \'gate\', not subset\n\n-- \nPavel Sedl?k <psedlak at redhat.com>\nRed Hat\n\n\n\n','<5199E62B.2070706@redhat.com>',NULL),('<1369054696.3894.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-20 13:58:16',3600,'2013-05-20 12:58:16',NULL,'[openstack-dev] Copyright headers in source files','On Fri, 2013-05-17 at 19:45 +0200, Zane Bitter wrote:\n> On 17/05/13 17:48, Clint Byrum wrote:\n> > Excerpts from Russell Bryant\'s message of 2013-05-17 07:23:08 -0700:\n> >> >On 05/17/2013 10:07 AM, Brian Lamar wrote:\n> >>> > >I\'m genuinely curious why your first preference is for complete copyright headers after it\'s been determined they\'re not needed to preserve copyright. Can you expound on that? Perhaps I\'m misinterpreting markwash\'s statements.\n> >> >\n> >> >Because it gives some people warm fuzzies, and there\'s some value in\n> >> >that.  The chance for recognition in public helps drive open source\n> >> >contributions.  It also seems to be the norm.  It\'s done all over the\n> >> >place, so I\'m just used to it.\n> >> >\n> >> >Admittedly that view seems outdated, though.  Since git maintains\n> >> >history of commit authors, the headers seem to have more value for a\n> >> >project using a a system like svn with only a few committers and no\n> >> >tracking of who wrote the code other than what you write in the commit\n> >> >message and leave in copyright headers.\n> >> >\n> > Git does not follow the code through to tarballs and onto peoples\'\n> > systems.  Also git does not express copyright assignment. Much of the code\n> > I write is work for hire for HP Cloud and thus they own the copyrights. To\n> > look at git and determine that, one would have to know the dates of my\n> > employment. This creates an ambiguity that a copyright notice does not.\n> >\n> > I understand that they get out of date. HP could sell the copyrights\n> > to another company, and even though my code says \"Copyright Hewlett\n> > Packard Development Corporation\" now it belongs to \"Fictional Future\n> > Corporation\". However, this still provides a bread crumb for anyone\n> > auditing the code to follow to HP, who can then make it clear they do\n> > not own the rights and that they have transferred to FFC.\n> \n> A NOTICE file _would_ follow the code through to tarballs &c. though, \n> and the Apache 2 license already requires it to be included when \n> distributing:\n> \n>     (d) If the Work includes a \"NOTICE\" text file as part of its\n>         distribution, then any Derivative Works that You distribute must\n>         include a readable copy of the attribution notices contained\n>         within such NOTICE file, excluding those notices that do not\n>         pertain to any part of the Derivative Works, in at least one\n>         of the following places: within a NOTICE text file distributed\n>         as part of the Derivative Works; ... [it goes on]\n> \n> It seems to me that including a NOTICE file with any copyright \n> statements that contributors wish to add, plus a statement that the \n> OpenStack project is the source of the package, would deliver 90% of the \n> value while eliminating 99.9% of the absurdity of trying to maintain \n> copyright headers in every single file.\n\nIMHO, a NOTICE file isn\'t so much about tracking copyright ownership as\nit is about us ensuring credit is given.\n\nThink about how you\'d comply with the above clause in the context of an\nOpenStack-based hardware appliance. Would it mean e.g. printed copy of\nthe NOTICE file?\n\nWe discussed this a bit here:\n\n  http://lists.openstack.org/pipermail/legal-discuss/2013-April/000014.html\n\nBut I wouldn\'t like to see us adopt NOTICE files *just* as a way to\ntrack copyright ownership ... because it actually has wider\nimplications.\n\nCheers,\nMark.\n\n\n\n','<51966CD3.5070109@redhat.com>',NULL),('<1369065341-sup-663@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-20 08:59:45',-25200,'2013-05-20 15:59:45',NULL,'[openstack-dev] Fw: [OpenStack] [Glance] Reuse the image id\n	when recreate an image in Glance which had been deleted','Excerpts from Flavio Percoco\'s message of 2013-05-20 00:25:28 -0700:\n> On 17/05/13 11:33 -0700, Mark Washenberger wrote:\n> >   I wonder if the best solution here is to change the uniqueness\n> >   constraint in our tables (as has been mentioned in several other\n> >   OpenStack-related database discussions) so that deleted images do not\n> >   conflict with active images with the same uuid. As I recall, the best\n> >   practice suggestion was to key the uniqueness constraint off the pair\n> >   <uuid, deleted>. In this scheme, deleted is no longer a simple boolean,\n> >   but rather either 0 (not deleted) or equal to the auto-increment row id\n> >   (deleted).\n> >   Does that make sense?\n> \n> That should work.\n> \n> I must admit, I\'m a bit worried about keeping deleted images in the\n> database, I see how that can be usefull (I guess) but I also think it\n> just makes the database bigger and the table slower - thinking about\n> really big environments and the fact that we\'re working on making\n> glance public. \n> \n\nThis is why we have indexes. If there is a table scan, there is a\nhuge failure waiting to happen no matter how small the table is (see:\nthundering herd). Well optimized access to tables shouldn\'t be any slower\nif they have millions of small rows or just a few.\n\n\n','<20130520072528.GD7782@redhat.com>',NULL),('<1369066346.21613.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-20 17:12:26',3600,'2013-05-20 16:12:26',NULL,'[openstack-dev] [OSLO] DB Support','On Sun, 2013-05-19 at 07:51 +0300, Gary Kotton wrote:\n> On 05/18/2013 06:57 PM, Davanum Srinivas wrote:\n> > Gary,\n> >\n> > We are at a stalemate between your -1 and Dolph Mathews\'s -1 on what\n> > the naming of the group in session.py [1]\n> \n> I\'d say that we are between a rock and a hard place :)\n> \n> Below is a partial mapping on how the projects have the section and key \n> names for the SQL database:\n> \n> Nova: Section - DEFAULT; Key - sql_connection\n> Cinder: Section - DEFAULT; Key - sql_connection\n> Glance: Section - DEFAULT; Key - sql_connection\n> Quantum: Section - DATABASE; key - sql_connection\n> Keystone: Section - SQL; key - connection\n> \n> My concern is the upgrade process and being backward compatible to the \n> existing configuration. The code that you have done works great for \n> Nova, Cinder and Glance. Problem is that it does not work for Quantum \n> and Keystone.\n> \n> Is there anyway of ensuring that the Quantum and Keystone configurations \n> are also supported. I am not sure that the common configuration module \n> supports more than one deprecated section and key name. If so great.\n> \n> I am really impartial to the section name. I prefer database but can be \n> easily swayed as it is not something that is written in stone. But What \n> I really do think is important is that we do not break things when going \n> from Grizzly to Havana.\n\nI think \'database\' is a fine section name - remember, the section names\nare there to help users rather than a name-spacing tool to keep\nindependent pieces of code (like an alternative DB driver) from\nclashing.\n\nIf we say that \'database\' is the right thing, we can merge this patch\ninto oslo-incubator and have Quantum switch over to the common DB code.\n\nSupporting legacy keystone configs with sql.connection using something\nlike dims cfg patch makes sense too, but we can do that at a later point\nsince it seems like Quantum is the project most eager to adopt the\ncommon code now.\n\nCheers,\nMark.\n\n\n\n','<51985A58.4020601@redhat.com>',NULL),('<1369124273.21613.81.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-21 09:17:53',3600,'2013-05-21 08:17:53',NULL,'[openstack-dev] [Oslo][Messaging] Do we really need\n transport_url parameter?','On Mon, 2013-05-20 at 18:48 +0200, Flavio Percoco wrote:\n> Hi,\n> \n> The new API has an optional parameter called transport_url[0], which is\n> used to specify the connection parameters for the chosen transport.\n> This url is being passed to the driver instance, which has to parse\n> it and, eventually, merge it with its own connection parameters -\n> depending on the implementation. [1]\n> \n> My question is: Do we really need it?\n\nYes, for ceilometer and cells\n\nFor cells, we need to to create a transport which connects us to the\nparent cell.\n\nFor ceilometer, we need to create transports which allows us to listen\nto the notifications from the various projects.\n\n> I agree it is useful for some implementations but, it can also make it\n> a bit more difficult for other implementations. For example, in qpid\'s\n> case, it could either use a single host or have a list of hosts for\n> HA. If transport_url is specified it will be necessary to either give\n> priority to it or append its netloc to the qpid_hosts list. However,\n> this behavior, most likely won\'t be the same for other\n> implementations.\n\nSee\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_URLs\n\n  \"Since some transports will support a clustered scenario where the\n   transport must be confgured with multiple distinct (but equivalent)\n   configurations, so we will support configuring a transport with a \n   set of URLs.\"\n\nand\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-April/008200.html\n\n  Where this gets tricky is the clustered broker setup - right now, you\n  just need to set qpid_hosts to a list of hostnames. To make it work with\n  this setup, we\'d need cfg to have a crazy interpolation scheme where\n  e.g.\n\n    foo=foo:$bar\n    bar=blaa,foobar\n\n  then referencing foo returns [foo:blaa, foo:foobar]\n\n> I\'m proposing to use rpc_backend and leave the connection parameters\n> definition to the implementation.\n\nDoesn\'t work for cells and ceilometer - the requirement is pretty basic,\nI think. A process needs to be able to connect to arbitrary transports,\nnot just e.g. multiple exchanges on the same broker.\n\n> Also, from my experience with kombu managing connection URLs at a\n> higher level can be painful for both the lib and backends\n> implementation.\n\nMore details?\n\nCheers,\nMark.\n\n\n\n','<20130520164804.GA2095@redhat.com>',NULL),('<1369151633.3586.111.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-21 10:53:53',-18000,'2013-05-21 15:53:53',NULL,'[openstack-dev] [CI] Problems with nova Python 2.6 tests?','There seems to be a system problem with the Python 2.6 tests on nova;\nI\'ve seen several failures with the exact same symptoms: only a console\nlog gets uploaded, and the only thing of note in the console log appears\nto be a version mismatch on a dependency?and it seems that the mismatch\narises from the system-installed packages.\n\nThe problem seems to arise for every patch in the series starting at:\n\n    https://review.openstack.org/#/c/29329/\n\nThat patch does not touch any dependencies.  Any insights?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1369156210.855715284@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-21 12:10:10',-18000,'2013-05-21 17:10:10',NULL,'[openstack-community] OpenStack booth at Cloud Expo East 2013 in\n	NYC June 10-13','\n\nHi all,  SUSE has generously donated a booth (#340) and marketing support to the OpenStack Foundation at [http://www.cloudcomputingexpo.com/] Cloud Expo East 2013 in NYC\'s Javits Convention Center June 10-13.  This event attracts senior technologists including CIOs, CTOs, directors of infrastructure, VPs of technology, IT directors and managers, network and storage managers, network engineers, enterprise architects, and communications and networking specialists.  This year, Cloud Expo combines Cloud and Big Data, both on the Expo floor and in the sessions. \n \nAs usual, we\'re looking for several booth volunteers.  I will be there for setup/teardown and the entire show.  Please reply if you can help out during these hours, and whether or not you require a pass:\n\n Monday, June 10, 6:30-8pm (reception)\n\nTuesday, June 11, 10am-12:30pm, 3-5:30pm\n\nWednesday, June 12, 10am-12:30pm, 3-5:30pm\n\nThursday, June 13, 10am-12:30pm, 2:30-5pm\nMany OpenStack companies are sponsors of this event.  We would like to offer the following marketing visibility to OpenStack members,corporate sponsors and supporters, as based on [http://www.openstack.org/foundation/companies/] http://www.openstack.org/foundation/companies/.  Please reply to [mailto:kathyc at openstack.org] kathyc at openstack.org with your interest in these activities by the dates provided.  We\'re on a short runway for this event; late requests may not be accommodated.\nPassport-style stamp card with participating logos and booth numbers of OpenStack companies.  Cards with the most number of stamps will be entered into a drawing for 2 Samsung tablets.  Drawing will take place at 4pm June 13 in the OpenStack booth (last day of Expo; open till 5pm).  No charge to participate - just send your logo, booth number, and company name as you want it listed by Tuesday, May 28.\n\"OpenStack to the Core\" tabletop banner designed expressly for OpenStack companies to proudly display your affiliation with OpenStack in your booth.  These will be distributed during setup hours on June 10 and picked up at the end of the show on June 13.  Please reply interested, with the on-site person\'s name who will be responsible for the banner by June 12.  Limit of 25 available.\nWe *may* have the ability to feature a few demos or 10 minute presentations at our booth throughout the event.  There is no theater; it would be people gathered around a large monitor in the booth. Presentations and demos must represent OpenStack (only) and be informative.  This is not firm yet but please let me know if you are interested by May 28. \nPlatinum and Gold members\' logos will be featured on a 6\' banner in the OpenStack booth, fyi.\nThank you!\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130521/37724516/attachment.html>\n\n',NULL,NULL),('<1369171816.874919301@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-21 17:30:16',-14400,'2013-05-21 21:30:16',NULL,'[openstack-dev] [OpenStack] [Glance] Reuse the image id when\n	recreate an image in Glance which had been deleted','Hey,\n\nWould it help to store image info on the server in terms of image metadata instead of looking for a deleted image? Also this would help in terms of knowing the exact image details at the time of boot.\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"Belmiro Moreira\" <moreira.belmiro.email.lists at gmail.com>\nSent: Tuesday, May 21, 2013 4:57pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [OpenStack] [Glance] Reuse the image id when recreate an image in Glance which had been deleted\n\nHi,\nI\'m not against to move them to another table? but removing them completely is different.\nI would like to know the owner of the image (even if already deleted), how long the image \nwas available,  ?\nAll of this is valuable data even for deleted images. Especially if a security incident happens and I need to collect data for my security team.\n\ncheers,\nBelmiro\n\n\nOn May 21, 2013, at 10:19 PM, Flavio Percoco <flavio at redhat.com> wrote:\n\n> On 21/05/13 22:08 +0200, Belmiro Moreira wrote:\n>> Hi,\n>> in fact I believe having this information in glance DB is really useful.\n>> In a big environment there are always instances running using images\n>> that were already deleted from glance.\n>> Having the info that the image existed and it was deleted is important.\n>> \n> \n> So happy you brought this up because this isn\'t clear. Could you\n> please elaborate a bit more the use case and how having\n> flagged-deleted images is useful?\n> \n> What would be the impact of removing them or moving them to a separate\n> table?\n> \n> Cheers,\n> FF\n> \n> -- \n> { name: \"Flavio Percoco\",\n>  gpg: \"87112EC1\",   internal: \"8261386\",\n>  phone: \"+390687502386\",\n>  irc: [\"fpercoco\", \"flaper87\"]}\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<D0DBD1B3-4DFF-4D0A-A6FF-9235EDC94597@gmail.com>',NULL),('<1369171973.765411624@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-21 17:32:53',-14400,'2013-05-21 21:32:53',NULL,'[openstack-dev] [OpenStack] [Glance] Reuse the image id when\n	recreate an image in Glance which had been deleted','Also would other alternatives like notifications be able to provide you sufficient information? Trying to think if there are alternative solutions to problems than having to store the deleted image information. But if there are usecases which definitely require them, I am open to hearing about them.\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"Belmiro Moreira\" <moreira.belmiro.email.lists at gmail.com>\nSent: Tuesday, May 21, 2013 4:57pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [OpenStack] [Glance] Reuse the image id when recreate an image in Glance which had been deleted\n\nHi,\nI\'m not against to move them to another table? but removing them completely is different.\nI would like to know the owner of the image (even if already deleted), how long the image \nwas available,  ?\nAll of this is valuable data even for deleted images. Especially if a security incident happens and I need to collect data for my security team.\n\ncheers,\nBelmiro\n\n\nOn May 21, 2013, at 10:19 PM, Flavio Percoco <flavio at redhat.com> wrote:\n\n> On 21/05/13 22:08 +0200, Belmiro Moreira wrote:\n>> Hi,\n>> in fact I believe having this information in glance DB is really useful.\n>> In a big environment there are always instances running using images\n>> that were already deleted from glance.\n>> Having the info that the image existed and it was deleted is important.\n>> \n> \n> So happy you brought this up because this isn\'t clear. Could you\n> please elaborate a bit more the use case and how having\n> flagged-deleted images is useful?\n> \n> What would be the impact of removing them or moving them to a separate\n> table?\n> \n> Cheers,\n> FF\n> \n> -- \n> { name: \"Flavio Percoco\",\n>  gpg: \"87112EC1\",   internal: \"8261386\",\n>  phone: \"+390687502386\",\n>  irc: [\"fpercoco\", \"flaper87\"]}\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<D0DBD1B3-4DFF-4D0A-A6FF-9235EDC94597@gmail.com>',NULL),('<1369268242.2353.67.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-23 10:17:22',36000,'2013-05-23 00:17:22',NULL,'[openstack-community] Online Presentation of Tripleo 0:00UTC\n May 23, 2013','Hopefully someone will record this and put a video online later as i am\ninterested in watching. So far it seems though that: \n* \'linux\' is an unsupported OS for using the browser\n* latest version of skype implies the stuff that isn\'t in the linux\nversion \n* microsoft lync - unlikely\n* google chat is failing via empathy for an unknown reason. \n* I don\'t have an ipad \n* am not willing to phone in internationally. \n\nHope it goes well but bluejeans may not be a great hosting service for a\ncommunity that is largely linux based. \n\nLet us know a link.\n\nThanks\n\nOn Tue, 2013-05-21 at 21:06 -0400, Anita Kuno wrote:\n> Please join us for an online presentation of Tripleo - OpenStack on\n> OpenStack\n> given by Robert Collins\n> on May 23, 2012 at 0:00 UTC:\n> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130522T20&p1=1194\n> hosted by the Canadian OpenStack User Group: http://canstack.ca/\n> \n> This presentation will take place virtually using bluejeans.com.\n> You can connect to the meeting from the canstack webpage:\n> http://canstack.ca/\n> Here is the link to the meeting: https://bluejeans.com/119008447\n> Bluejeans allows you to connect to the meeting several different ways\n> including: browser, skype and telephone.\n> \n> You can watch Robert Collins\' Tripleo presentation from the OpenStack\n> Summit in Portland:\n> http://www.openstack.org/summit/portland-2013/session-videos/presentation/openstack-on-openstack-overview\n> \n> We are looking forward to Robert\'s presentation on Tripleo. He\n> probably will reiterate of some of the basic concepts from the summit,\n> as well as sharing any new Tripleo developments with us. After the\n> presentation we hope to have some time for questions. We are\n> anticipating ~ 30 minutes of presentation and about 20 - 30 minutes of\n> questions but given the nature of the venue we will probably be fairly\n> lenient with time frames.\n> \n> Since bluejeans.com doesn\'t have a chat feature please join us on\n> irc.freenode.net #canstack for chat during the presentation.\n> \n> Since this meeting is virtual, you are welcome regardless of where you\n> happen to be located. You don\'t have to be Canadian or in Canada to\n> attend.\n> However the app only allows for 15 connections, so 14 plus Robert. If\n> you can buddy up or attend with a friend, that would help us out.\n> \n> Any questions? You are welcome to email me or find me on #canstack, my\n> nick is anteaya.\n> You can also email the canstack organizer, Curtis Collicutt at\n> curtis.collicutt at cybera.ca, Curtis\' nick is serverascode.\n> \n> Thanks,\n> -- \n> Anita Kuno\n> Open Cloud Developer, Teacher, DevOps\n> \n> eNovance\n> \n> EMAIL: anita.kuno at enovance.com ? SKYPE: anita_kuno\n> LOCATION: Montreal, Quebec, Canada\n> WEB: www.enovance.com ? TWITTER: @enovance \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\n\n','<519C1A26.9000201@enovance.com>',NULL),('<1369272207.2353.70.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-23 11:23:27',36000,'2013-05-23 01:23:27',NULL,'[openstack-community] Online Presentation of Tripleo 0:00UTC\n May 23, 2013','Hi all, \n\nto clarify i did eventually get in with skype, i\'m not sure why it\nfailed the first time i tried. I\'m on fedora and skype is not always\nright so let\'s put it down to that. \n\nThanks for hosting this, it was very interesting. \n\nJamie\n\nOn Thu, 2013-05-23 at 11:03 +1000, Tom Fifield wrote:\n> Hi Jamie,\n> \n> On 23/05/13 10:17, Jamie Lennox wrote:\n> > Hopefully someone will record this and put a video online later as i am\n> > interested in watching. So far it seems though that:\n> > * \'linux\' is an unsupported OS for using the browser\n> > * latest version of skype implies the stuff that isn\'t in the linux\n> > version\n> \n> I can confirm that Skype 4.1.0.20 under Ubuntu 12.04 64 bit works well \n> with Blue Jeans. Last time I called in, everyone could see and hear \n> everyone (including shared screens), and they could see and hear me.\n> \n> \n> Regards,\n> \n> Tom\n> \n> \n> \n> >\n> > Thanks\n> >\n> > On Tue, 2013-05-21 at 21:06 -0400, Anita Kuno wrote:\n> >> Please join us for an online presentation of Tripleo - OpenStack on\n> >> OpenStack\n> >> given by Robert Collins\n> >> on May 23, 2012 at 0:00 UTC:\n> >> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20130522T20&p1=1194\n> >> hosted by the Canadian OpenStack User Group: http://canstack.ca/\n> >>\n> >> This presentation will take place virtually using bluejeans.com.\n> >> You can connect to the meeting from the canstack webpage:\n> >> http://canstack.ca/\n> >> Here is the link to the meeting: https://bluejeans.com/119008447\n> >> Bluejeans allows you to connect to the meeting several different ways\n> >> including: browser, skype and telephone.\n> >>\n> >> You can watch Robert Collins\' Tripleo presentation from the OpenStack\n> >> Summit in Portland:\n> >> http://www.openstack.org/summit/portland-2013/session-videos/presentation/openstack-on-openstack-overview\n> >>\n> >> We are looking forward to Robert\'s presentation on Tripleo. He\n> >> probably will reiterate of some of the basic concepts from the summit,\n> >> as well as sharing any new Tripleo developments with us. After the\n> >> presentation we hope to have some time for questions. We are\n> >> anticipating ~ 30 minutes of presentation and about 20 - 30 minutes of\n> >> questions but given the nature of the venue we will probably be fairly\n> >> lenient with time frames.\n> >>\n> >> Since bluejeans.com doesn\'t have a chat feature please join us on\n> >> irc.freenode.net #canstack for chat during the presentation.\n> >>\n> >> Since this meeting is virtual, you are welcome regardless of where you\n> >> happen to be located. You don\'t have to be Canadian or in Canada to\n> >> attend.\n> >> However the app only allows for 15 connections, so 14 plus Robert. If\n> >> you can buddy up or attend with a friend, that would help us out.\n> >>\n> >> Any questions? You are welcome to email me or find me on #canstack, my\n> >> nick is anteaya.\n> >> You can also email the canstack organizer, Curtis Collicutt at\n> >> curtis.collicutt at cybera.ca, Curtis\' nick is serverascode.\n> >>\n> >> Thanks,\n> >> --\n> >> Anita Kuno\n> >> Open Cloud Developer, Teacher, DevOps\n> >>\n> >> eNovance\n> >>\n> >> EMAIL: anita.kuno at enovance.com ? SKYPE: anita_kuno\n> >> LOCATION: Montreal, Quebec, Canada\n> >> WEB: www.enovance.com ? TWITTER: @enovance\n> >> _______________________________________________\n> >> Community mailing list\n> >> Community at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > Community mailing list\n> > Community at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> >\n> \n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\n\n','<519D6AE8.1000904@unimelb.edu.au>',NULL),('<1369308507.29845.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-23 12:28:27',3600,'2013-05-23 11:28:27',NULL,'[openstack-dev] Recent oslo.config/Quantum changes [was Re: For\n those using Quantum with devstack]','Hey\n\nLet me try and summarize a few things about this:\n\n  - a change went into oslo.config master (what will be 1.2.0) to\n    normalize config file section names to lowercase\n\n    the compat concerns are pretty subtle here:\n\n      1) the only way this change would have (intentionally) caused \n         breakage is where a project was doing something like this:\n\n           [foo]\n           bar = blaa\n\n           [FOO]\n           bar = boo\n\n         and expected to see CONF.foo == blaa and CONF.FOO.bar == boo. \n         That\'s incredibly unlikely, but if it turns out that a project \n         was doing that, we will have to revert the change. That\'s why \n         we don\'t publish dev release to pypi - we want to give \n         ourselves a chance to find these issues on the dev branch \n         before breaking stable pypi-based deployments. Again, I \n         sincerely doubt this case is going to be a problem.\n\n      2) there was some confusion in Quantum and some interpreted this \n         change as meaning that they would need to replace e.g. CONF.OVS\n         to CONF.ovs in the codebase in order to upgrade to latest \n         oslo.config.\n\n         If that was true, this would have been a massively \n         incompatible change and would completely hose Grizzly \n         deployments if you upgraded oslo.config. All the noise I make \n         about API compatibility is about avoiding that exact situation.\n         We do not (intentionally) make those kind of incompatible\n         changes in oslo.config.\n\n         In order to change the case of the references in the code \n         base, you have to explicitly opt-in by doing:\n\n           -CONF.register_opts(opts, group=\'OVS\')\n           +CONF.register_opts(opts, group=\'ovs\')\n\n         and you can do that group-by-group.\n\n         Summary: Quantum could have upgraded to latest oslo.config \n         with *zero* code changes.\n\n      3) we did actually make an incompatible change to a part of the \n         oslo.config API that we thought no-one was using. As soon as \n         it became apparent that one of the Quantum drivers was using \n         it, we jumped on the issue and restored the previous API \n         semantics:\n\n           https://review.openstack.org/30250\n\n  - These changes to Quantum:\n\n      b8b2c4e Reference OVS OptGoup names in lowercase\n      2f13345 Reference DEFAULT_SERVICETYPE OptGoup names in lowercase\n      362bd7f Reference QUOTA OptGoup names in lowercase\n\n    require latest oslo.config. They should not have been merged before \n    we changed pip-requires to use the latest oslo.config:\n\n      https://review.openstack.org/30094\n\n    I don\'t fully understand yet how these changes got through the gate\n    before the newer version of oslo.config was even available.\n\n  - I\'ve tagged oslo.config-1.2.0a1 yesterday and I\'ll tag 1.2.0a2 \n    later today hopefully. The 1.2.0 release won\'t be pushed to pypi\n    until Havana is almost ready to be released. This is to give us a\n    chance to catch issues like the MultiConfigParser breakage above.\n\n    In the meantime, all Havana development and testing should be using \n    the oslo.config 1.2.0 branch (i.e. master) - currently the only way \n    we have of doing that is to update each project\'s pip-requires file \n    to point to the oslo.config tarball on tarballs.openstack.org\n\nHope that helps,\nMark.\n\n\n\n','<CC6516285E165D48ACB2CF4D9266006C2154D0AC@xmb-aln-x05.cisco.com>',NULL),('<1369309515.29845.40.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-23 12:45:15',3600,'2013-05-23 11:45:15',NULL,'[openstack-dev] Recent oslo.config/Quantum changes [was Re: For\n those using Quantum with devstack]','On Thu, 2013-05-23 at 12:28 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> Let me try and summarize a few things about this:\n\nSince this is definitely TL and I expect there\'ll be plenty who don\'t\nTR, let me TL;DR :)\n\n  1) the breakage people saw in Quantum was due to the fact the Quantum \n     merged changes requiring latest oslo.config and it wasn\'t\n     available. This should never have gotten through the gate, but it\n     did.\n\n  2) we don\'t intentionally make incompatible changes in oslo.config. \n     We did accidentally make one and it broke a fairly obscure part of \n     Quantum. We\'ve reverted that incompatible change. Again, though,\n     this was not the cause of the Quantum breakage people noticed.\n\n  3) we need to figure out a better way for all the development \n     branches of our integrated projects to use the development version\n     of oslo.config.\n\nCheers,\nMark.\n\n>   - a change went into oslo.config master (what will be 1.2.0) to\n>     normalize config file section names to lowercase\n> \n>     the compat concerns are pretty subtle here:\n> \n>       1) the only way this change would have (intentionally) caused \n>          breakage is where a project was doing something like this:\n> \n>            [foo]\n>            bar = blaa\n> \n>            [FOO]\n>            bar = boo\n> \n>          and expected to see CONF.foo == blaa and CONF.FOO.bar == boo. \n>          That\'s incredibly unlikely, but if it turns out that a project \n>          was doing that, we will have to revert the change. That\'s why \n>          we don\'t publish dev release to pypi - we want to give \n>          ourselves a chance to find these issues on the dev branch \n>          before breaking stable pypi-based deployments. Again, I \n>          sincerely doubt this case is going to be a problem.\n> \n>       2) there was some confusion in Quantum and some interpreted this \n>          change as meaning that they would need to replace e.g. CONF.OVS\n>          to CONF.ovs in the codebase in order to upgrade to latest \n>          oslo.config.\n> \n>          If that was true, this would have been a massively \n>          incompatible change and would completely hose Grizzly \n>          deployments if you upgraded oslo.config. All the noise I make \n>          about API compatibility is about avoiding that exact situation.\n>          We do not (intentionally) make those kind of incompatible\n>          changes in oslo.config.\n> \n>          In order to change the case of the references in the code \n>          base, you have to explicitly opt-in by doing:\n> \n>            -CONF.register_opts(opts, group=\'OVS\')\n>            +CONF.register_opts(opts, group=\'ovs\')\n> \n>          and you can do that group-by-group.\n> \n>          Summary: Quantum could have upgraded to latest oslo.config \n>          with *zero* code changes.\n> \n>       3) we did actually make an incompatible change to a part of the \n>          oslo.config API that we thought no-one was using. As soon as \n>          it became apparent that one of the Quantum drivers was using \n>          it, we jumped on the issue and restored the previous API \n>          semantics:\n> \n>            https://review.openstack.org/30250\n> \n>   - These changes to Quantum:\n> \n>       b8b2c4e Reference OVS OptGoup names in lowercase\n>       2f13345 Reference DEFAULT_SERVICETYPE OptGoup names in lowercase\n>       362bd7f Reference QUOTA OptGoup names in lowercase\n> \n>     require latest oslo.config. They should not have been merged before \n>     we changed pip-requires to use the latest oslo.config:\n> \n>       https://review.openstack.org/30094\n> \n>     I don\'t fully understand yet how these changes got through the gate\n>     before the newer version of oslo.config was even available.\n> \n>   - I\'ve tagged oslo.config-1.2.0a1 yesterday and I\'ll tag 1.2.0a2 \n>     later today hopefully. The 1.2.0 release won\'t be pushed to pypi\n>     until Havana is almost ready to be released. This is to give us a\n>     chance to catch issues like the MultiConfigParser breakage above.\n> \n>     In the meantime, all Havana development and testing should be using \n>     the oslo.config 1.2.0 branch (i.e. master) - currently the only way \n>     we have of doing that is to update each project\'s pip-requires file \n>     to point to the oslo.config tarball on tarballs.openstack.org\n> \n> Hope that helps,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1369308507.29845.34.camel@sorcha>',NULL),('<1369395591.14638.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-24 12:39:51',3600,'2013-05-24 11:39:51',NULL,'[openstack-dev] headsup - backwards incompatible change -\n python-novaclient is incompatible with [some] existing nova environments','On Fri, 2013-05-24 at 23:29 +1200, Robert Collins wrote:\n> I just thought I\'d call attention to this -\n> https://bugs.launchpad.net/python-novaclient/+bug/1173353\n> \n> Since https://review.openstack.org/#/c/26365/ landed,\n> python-novaclient will trigger a 400 error from nova-api when setting\n> quotas, because it supplies an option existing nova doesn\'t support.\n> \n> There are no novas running anything in trunk that *can* support it,\n> because the nova side of the code hasn\'t landed.\n> \n> I think this is another case where we should back it out, and land it\n> again with some thought for backwards compat.\n\nAgree - we shouldn\'t be afraid to do an immediate revert of mistakes\nlike this and revisit when the heat is out of the situation.\n\nI made a mistake with backwards compat this week in oslo.config - it\'s\neasily done and no-one should take offence at a quick revert for an\nissue like this.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ0-1fVXbeNnZOYeS-391DNSHi72ijGJJmzSCbBZ8Drppw@mail.gmail.com>',NULL),('<1369487015.2325.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-25 14:03:35',3600,'2013-05-25 13:03:35',NULL,'[openstack-dev] Recent oslo.config/Quantum changes [was Re: For\n those using Quantum with devstack]','On Fri, 2013-05-24 at 23:00 +0100, Salvatore Orlando wrote:\n> Hi Mark,\n> \n> \n> Your comments where not really TL, but I thank your very much for the\n> TL;DR follow up!\n> And btw, thank you very much for [1]!\n\n:)\n\n> oslo.config 1.2.0 does normalize all option group names to lowercase,\n> but still supports as \'deprecated\' the ones with all capital letters.\n> Is the above statement correct?\n> I\'m asking because during a review I expressed a similar concern and\n> was told that oslo.config 1.1.0 did this ([2]), and I want to be sure\n> my understanding is correct.\n\nYeah, this statement:\n\n  \"Thus conf files are backwards compatible but option group references\n   in the code must now use lowercase before we update oslo.config\"\n\nwas a misunderstanding.\n\nThere are two aspects to this case normalization thing:\n\n  1) After the update to 1.2.0, users can now use upper case or lower \n     case section names in their config files (they can also have a \n     mixture of upper and lower case) and everything will work fine\n\n  2) Before and after the update to 1.2.0, the case of the group names \n     in the code is determined by the case of the group name passed to \n     register_opt() - i.e. both of these are valid:\n\n       CONF.register_opt(StrOpt(\'foo\'), group=\'bar\')\n       print CONF.bar.foo\n\n       CONF.register_opt(StrOpt(\'foo\'), group=\'BAR\')\n       print CONF.BAR.foo\n\n     but these would not be valid:\n\n       CONF.register_opt(StrOpt(\'foo\'), group=\'bar\')\n       print CONF.BAR.foo\n\n       CONF.register_opt(StrOpt(\'foo\'), group=\'BAR\')\n       print CONF.bar.foo\n\n     Basically, the recent changes to oslo.config shouldn\'t *require*\n     any code changes to Quantum. However, since we want to recommend \n     users use lower case sections, it makes sense to gradually change\n     Quantum code to also use lower case group names.\n\nCheers,\nMark.\n\n\n\n\n','<CAGR=i3gG=sS08Dfh9rxa_y8+6g7DO3QUXo=_hm7K-+cw37aSUg@mail.gmail.com>',NULL),('<1369493369.2325.15.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-05-25 15:49:29',3600,'2013-05-25 14:49:29',NULL,'[OpenStack Foundation] April 14th board meeting','Hey,\n\nUsually Jonathan posts a summary of our board meetings very quickly\nafter the meeting and I try to follow up with a longer blog post. This\ntime around I guess the craziness of the summit week got in the way of\nthat and time seems have moved along quickly since then :)\n\nApologies for the delay, but I hope this is still useful:\n\n  http://blogs.gnome.org/markmc/2013/05/25/april-14th-openstack-foundation-board-meeting/\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1369571418.2325.32.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-05-26 13:30:18',3600,'2013-05-26 12:30:18',NULL,'[OpenStack Foundation] April 14th board meeting','On Sat, 2013-05-25 at 18:20 -0700, Joshua McKenty wrote:\n> A beautiful summary, and appreciated - however; as much as I hate to\n> be \"that guy\", I believe the purpose of the board approval for\n> Jonathan\'s \"unofficial recap\" was to have a single, semi-official\n> record of the meeting prior to any blogging free-for-all. I believe\n> board policy is still to forego any commentary on the meeting until\n> either Jonathan\'s notes, or the official board minutes, are published.\n\nJonathan did ask me to go ahead with mine since we were long overdue\nhowever, in retrospect, he also asked me to explicitly note that in my\nsummary and I didn\'t quite do that. Sorry for that.\n\n> As a more serious note - we should refrain from ANY description of\n> what was discussed during executive session - whether it was restated\n> afterwards or not.\n\nThis is what you\'re taking issue with?\n\n  As part of the voting process, some directors chose to publicly \n  restate their concerns with the applications that had been discussed\n  during the executive session.\n\nIt would have been better to leave it ambiguous as to whether these\nconcerns were stated in the executive session or whether they were\nraised for the first time after the executive session?\n\nThe way I saw it, the whole point of those statements after the\nexecutive session was to *restate* concerns publicly for the record ...\nnot to have a whole new conversation.\n\nCheers,\nMark.\n\n\n\n','<CALOyBR12poRseyVDbsnKW3ppJnuPvfM+qNKSZbZvM84zoyhUjg@mail.gmail.com>',NULL),('<1369652F6B984CDCB2EA41A8B60A3290@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-16 17:22:09',-14400,'2012-07-16 21:22:09',NULL,'[openstack-dev] no-db-compute blueprint status?','\n\n\nOn Monday, July 16, 2012 at 16:59 PM, Sean Dague wrote:\n\n> Is there any update on work towards the no-db-compute blueprint? Even if \n> there isn\'t work done on it yet, has there been thinking on basic \n> strategy to get there?\n> \n> I\'d really like to see this one land for folsom, so would be happy to \n> apply some effort here.\n> \n\n\nI believe drafter Russell Bryant has made some progress on this, but I\'ll wait for his response.\n\nI\'ve personally introduced a related patch, which is still in (perpetual) draft status as a PoC, to access the database over RPC. This would remove the direct access from compute nodes to the database, although they could still write to the database.  If we can complete the trusted-rpc-messaging blueprint, this could become a secure solution. I don\'t expect that trusted messaging + granular access control will arrive any sooner than Grizzly, however. With luck, it might appear as a patch for Folsom. Needless to say, that might not be the fastest path to a no-db-compute feature, but it would be a \"free\" consequence of changes we\'re making to otherwise secure the system.\n\nI\'ll happily provide access to the draft patch for those in Gerrit, to those that are interested.\n\n-- \nEric Windisch\n\n\n\n\n\n','<500480A1.8000107@linux.vnet.ibm.com>',NULL),('<1369729296.2325.220.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 09:21:36',3600,'2013-05-28 08:21:36',NULL,'[openstack-dev] [Horizon] Realtime push-based communication PoC','Hey Tomas,\n\nOn Tue, 2013-05-28 at 09:29 +0200, Tomas Sedovic wrote:\n> On 05/24/2013 08:36 PM, Doug Hellmann wrote:\n> >\n> >\n> >\n> > On Fri, May 24, 2013 at 12:39 PM, Tomas Sedovic <tsedovic at redhat.com\n> > <mailto:tsedovic at redhat.com>> wrote:\n...\n> >     I wonder if we could leverage Ceilometer here since it already\n> >     listens in on the message bus. Could it be configured to send\n> >     interesting information to Horizon (as opposed to being polled for it)?\n> >\n> >\n> > This really feels like a different use case that what ceilometer is made\n> > for. Gabriel and I talked at the grizzly summit about the code we have\n> > in ceilometer for listening to notifications, and we agreed to try to\n> > put that in oslo somewhere to make it easier to create a similar\n> > listening service in horizon that redirects the notifications to the\n> > browser(s). I haven\'t had a chance to do that. If you want to tackle it,\n> > I can help figure out which bits are interesting/useful.\n> \n> Thanks, I thought that might be the case but I didn\'t know enough to be \n> sure.\n> \n> Putting the bits to oslo sounds like a neat idea.\n\nThe notifications listening API is basically the last API design task\nfor the oslo messaging API:\n\n\n\n>  I\'m certainly willing \n> to look into it, but I\'d like to get some feedback on this first.\n> \n> >\n> > Doug\n> >\n> >\n> >\n> >     I\'m not sure whether it makes sense to push the code or not, but I\n> >     tried to make sure I didn\'t break the standard set up.\n> >\n> >     Please let me know what you think.\n> >\n> >     Thanks,\n> >     Tomas Sedovic\n> >\n> >\n> >     [1]:\n> >     https://blueprints.launchpad.__net/horizon/+spec/realtime-__communication\n> >     <https://blueprints.launchpad.net/horizon/+spec/realtime-communication>\n> >     [2]: https://etherpad.openstack.__org/havana-horizon-realtime\n> >     <https://etherpad.openstack.org/havana-horizon-realtime>\n> >     [3]: https://github.com/abourget/__gevent-socketio\n> >     <https://github.com/abourget/gevent-socketio>\n> >\n> >     _________________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.__org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<51A45CD6.401@redhat.com>',NULL),('<1369729348.2325.222.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 09:22:28',3600,'2013-05-28 08:22:28',NULL,'[openstack-dev] [Horizon] Realtime push-based communication PoC','Hey Tomas,\n\nOn Tue, 2013-05-28 at 09:29 +0200, Tomas Sedovic wrote:\n> On 05/24/2013 08:36 PM, Doug Hellmann wrote:\n> >\n> >\n> >\n> > On Fri, May 24, 2013 at 12:39 PM, Tomas Sedovic <tsedovic at redhat.com\n> > <mailto:tsedovic at redhat.com>> wrote:\n...\n> >     I wonder if we could leverage Ceilometer here since it already\n> >     listens in on the message bus. Could it be configured to send\n> >     interesting information to Horizon (as opposed to being polled for it)?\n> >\n> >\n> > This really feels like a different use case that what ceilometer is made\n> > for. Gabriel and I talked at the grizzly summit about the code we have\n> > in ceilometer for listening to notifications, and we agreed to try to\n> > put that in oslo somewhere to make it easier to create a similar\n> > listening service in horizon that redirects the notifications to the\n> > browser(s). I haven\'t had a chance to do that. If you want to tackle it,\n> > I can help figure out which bits are interesting/useful.\n> \n> Thanks, I thought that might be the case but I didn\'t know enough to be \n> sure.\n> \n> Putting the bits to oslo sounds like a neat idea.\n\nThe notifications listening API is basically the last API design task\nfor the oslo messaging API:\n\nhttps://wiki.openstack.org/wiki/Oslo/Messaging#Handling_Notifications\n\n> I\'m certainly willing \n> to look into it, but I\'d like to get some feedback on this first.\n\nI guess the question comes down to whether Horizon itself should be\nlistening on the message bus or whether we have some other agent consume\nnotifications and send them to Horizon via socket.io?\n\nCheers,\nMark.\n\n\n\n','<51A45CD6.401@redhat.com>',NULL),('<1369751678.16851.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 15:34:38',3600,'2013-05-28 14:34:38',NULL,'[openstack-dev] For those using Quantum with devstack','On Fri, 2013-05-24 at 14:56 +0900, Yoshihiro Kaneko wrote:\n> Hi,\n> \n> Change I78260871(Require oslo.config 1.2.0a2) was merged, but the problem\n> was not solved at least in my environment.\n> oslo.config 1.2.0a2 does not seem to be installed.\n...\n> 2013-05-24 04:47:00 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY=\n> HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install --use-mirrors -r\n> quantum.egg-info/requires.txt -f\n> http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config\n> <snip>\n> 2013-05-24 04:47:00 Requirement already satisfied (use --upgrade to\n> upgrade): os\n> lo.config in /usr/local/lib/python2.7/dist-packages (from -r\n> quantum.egg-info/re\n> quires.txt (line 20))\n\nTwo things:\n\n  1) the requires.txt generated by pbr just has \'oslo.config\' listed as \n     the requirement, so pip thinks that requirement is already \n     satisfied\n\n  2) we\'re passing the tarball URL via \'-f\' which means that pip looks \n     there for packages to satisfy the requirements, rather then always \n     installing the tarball. That makes sense, the URL may be to a \n     version which is older than the currently installed version.\n\nThis brings us back to this:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-February/005975.html\n\nSomething like this in pbr might do the trick:\n\n  -            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*)$\', r\'\\1\',\n  -                                line))\n  +            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*?)-(.*)$\',\n  +                                       r\'\\1>=\\2\', line))\n\nWe\'d make the URL be:\n\n  http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2\n\nand that would give us:\n\n  oslo.config>=1.2.0a2\n\nin requires.txt\n\nHowever, we\'d need to figure out some way to make this pbr change\nwithout screwing up existing users of the library.\n\nFor havana-1 (i.e. today), I guess we have three options:\n\n  1) Get the change above into PBR and released to PyPi, then update \n     the tarball URL in quantum as above\n\n  2) Revert the changes to Quantum which require latest oslo.config\n\n  3) Release oslo.config 1.2.0a2 to PyPi, exposing Grizzly users to the \n     development branch of oslo.config\n\nAt this point, I\'m thinking we need to do (2) and get (1) figured out\nASAP after havana-1. I\'ll look at getting the reverts proposed.\n\nOn a related note, though, I see Monty has added pbr to devstack:\n\n  https://review.openstack.org/28590\n\nIMHO, it makes just as much sense to include oslo.config in devstack. We\nshould always be testing trunk with the trunk version of oslo.config.\n\nCheers,\nMark.\n\n\n\n','<CAH1o70Lj0BYz7bxcJZ5Hfgnn76JpfOxYJ691bSrWThZAOx5JLw@mail.gmail.com>',NULL),('<1369764652.3586.138.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 13:10:52',-18000,'2013-05-28 18:10:52',NULL,'[openstack-dev] [nova] policy names for API extensions','On Fri, 2013-05-24 at 13:59 +0930, Christopher Yeoh wrote:\n> What I\'d like to do for only the V3 API is to change the convention so\n> the name used for an extension\'s policy to be the same as the alias\n> definition. This would make things more difficult for a\n> Grizzly->Havana upgrade, but long term I think its worth it.\n\nOne comment I have is that we have a few V2 extensions that have\nmultiple authorizors; generally, they have one interface accessible to\nthe general user and one that should be restricted to administrative\naccess.  I think they generally use \':\' to append a differentiator, but\nI wanted to point this out, since any policy naming scheme needs to take\nthis use into account?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CANCY3effmKwUTE7XnZ4=mteK7MJekP+8GSfJnmR+SOE6-wCD7w@mail.gmail.com>',NULL),('<1369767855.16851.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 20:04:15',3600,'2013-05-28 19:04:15',NULL,'[openstack-dev] For those using Quantum with devstack','On Tue, 2013-05-28 at 15:34 +0100, Mark McLoughlin wrote:\n> On Fri, 2013-05-24 at 14:56 +0900, Yoshihiro Kaneko wrote:\n> > Hi,\n> > \n> > Change I78260871(Require oslo.config 1.2.0a2) was merged, but the problem\n> > was not solved at least in my environment.\n> > oslo.config 1.2.0a2 does not seem to be installed.\n> ...\n> > 2013-05-24 04:47:00 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY=\n> > HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install --use-mirrors -r\n> > quantum.egg-info/requires.txt -f\n> > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config\n> > <snip>\n> > 2013-05-24 04:47:00 Requirement already satisfied (use --upgrade to\n> > upgrade): os\n> > lo.config in /usr/local/lib/python2.7/dist-packages (from -r\n> > quantum.egg-info/re\n> > quires.txt (line 20))\n> \n> Two things:\n> \n>   1) the requires.txt generated by pbr just has \'oslo.config\' listed as \n>      the requirement, so pip thinks that requirement is already \n>      satisfied\n> \n>   2) we\'re passing the tarball URL via \'-f\' which means that pip looks \n>      there for packages to satisfy the requirements, rather then always \n>      installing the tarball. That makes sense, the URL may be to a \n>      version which is older than the currently installed version.\n> \n> This brings us back to this:\n> \n>   http://lists.openstack.org/pipermail/openstack-dev/2013-February/005975.html\n> \n> Something like this in pbr might do the trick:\n> \n>   -            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*)$\', r\'\\1\',\n>   -                                line))\n>   +            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*?)-(.*)$\',\n>   +                                       r\'\\1>=\\2\', line))\n> \n> We\'d make the URL be:\n> \n>   http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2\n> \n> and that would give us:\n> \n>   oslo.config>=1.2.0a2\n> \n> in requires.txt\n> \n> However, we\'d need to figure out some way to make this pbr change\n> without screwing up existing users of the library.\n> \n> For havana-1 (i.e. today), I guess we have three options:\n> \n>   1) Get the change above into PBR and released to PyPi, then update \n>      the tarball URL in quantum as above\n> \n>   2) Revert the changes to Quantum which require latest oslo.config\n> \n>   3) Release oslo.config 1.2.0a2 to PyPi, exposing Grizzly users to the \n>      development branch of oslo.config\n> \n> At this point, I\'m thinking we need to do (2) and get (1) figured out\n> ASAP after havana-1. I\'ll look at getting the reverts proposed.\n> \n> On a related note, though, I see Monty has added pbr to devstack:\n> \n>   https://review.openstack.org/28590\n> \n> IMHO, it makes just as much sense to include oslo.config in devstack. We\n> should always be testing trunk with the trunk version of oslo.config.\n\nHmm, I meant to cc Thierry and Monty\n\nCheers,\nMark.\n\n\n\n','<1369751678.16851.26.camel@sorcha>',NULL),('<1369776094.3586.139.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 16:21:34',-18000,'2013-05-28 21:21:34',NULL,'[openstack-dev] [Metrics] Keeping up with review requests','On Tue, 2013-05-28 at 17:03 -0400, Russell Bryant wrote:\n> $ for project in *.json ; do ./openreviews.py -p ${project} && echo ; done\n> Projects: [u\'cinder\']\n> Total Open Reviews: 40\n> Waiting on Submitter: 21\n> Waiting on Reviewer: 19\n>  --> Average wait time: 2 days, 22 hours, 43 minutes\n\nHow about the python-*client projects?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51A51B88.3050802@redhat.com>',NULL),('<1369776315.16851.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-28 22:25:15',3600,'2013-05-28 21:25:15',NULL,'[openstack-dev] For those using Quantum with devstack','Hi,\n\nOn Tue, 2013-05-28 at 18:07 +0100, Mate Lakat wrote:\n> Hi,\n> \n> What do you think about these:\n> \n> devstack:\n> https://review.openstack.org/30723\n\nI\'m not sure this is correct - we\'d be interpreting depedency_links.txt\ndifferently from how other tools would interpret, I think\n\n> quantum:\n> https://review.openstack.org/30745\n\nVery close, but the issue is that it creates a broken dependency_links\nfile - i.e. we can have egg_info=oslo.config-1.2.0a2 but not\negg_info=oslo.config==1.2.0a2\n\n> At the moment the quantum patch failed on gate, because all the rootwrap\n> commands are complaining:\n> \n> UserWarning: Module oslo was already imported from None, but\n> /usr/local/lib/python2.7/dist-packages/oslo.config-1.2.0a2-py2.7.egg is\n> being added to sys.path\n> \n> It seems, oslo.config conflicts with oslo? I am a bit lost.\n\nI\'m not sure what that\'s about ... maybe collateral damage from\neasy_install installing oslo.config instead of pip?\n\nI\'ve gone ahead and proposed an interim revert of this stuff so we can\ncut havana-1:\n\n  https://review.openstack.org/30794\n\nThanks,\nMark.\n\n> Mate\n> \n> \n> On Tue, May 28, 2013 at 03:34:38PM +0100, Mark McLoughlin wrote:\n> > On Fri, 2013-05-24 at 14:56 +0900, Yoshihiro Kaneko wrote:\n> > > Hi,\n> > > \n> > > Change I78260871(Require oslo.config 1.2.0a2) was merged, but the problem\n> > > was not solved at least in my environment.\n> > > oslo.config 1.2.0a2 does not seem to be installed.\n> > ...\n> > > 2013-05-24 04:47:00 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY=\n> > > HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install --use-mirrors -r\n> > > quantum.egg-info/requires.txt -f\n> > > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config\n> > > <snip>\n> > > 2013-05-24 04:47:00 Requirement already satisfied (use --upgrade to\n> > > upgrade): os\n> > > lo.config in /usr/local/lib/python2.7/dist-packages (from -r\n> > > quantum.egg-info/re\n> > > quires.txt (line 20))\n> > \n> > Two things:\n> > \n> >   1) the requires.txt generated by pbr just has \'oslo.config\' listed as \n> >      the requirement, so pip thinks that requirement is already \n> >      satisfied\n> > \n> >   2) we\'re passing the tarball URL via \'-f\' which means that pip looks \n> >      there for packages to satisfy the requirements, rather then always \n> >      installing the tarball. That makes sense, the URL may be to a \n> >      version which is older than the currently installed version.\n> > \n> > This brings us back to this:\n> > \n> >   http://lists.openstack.org/pipermail/openstack-dev/2013-February/005975.html\n> > \n> > Something like this in pbr might do the trick:\n> > \n> >   -            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*)$\', r\'\\1\',\n> >   -                                line))\n> >   +            requirements.append(re.sub(r\'\\s*https?:.*#egg=(.*?)-(.*)$\',\n> >   +                                       r\'\\1>=\\2\', line))\n> > \n> > We\'d make the URL be:\n> > \n> >   http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2\n> > \n> > and that would give us:\n> > \n> >   oslo.config>=1.2.0a2\n> > \n> > in requires.txt\n> > \n> > However, we\'d need to figure out some way to make this pbr change\n> > without screwing up existing users of the library.\n> > \n> > For havana-1 (i.e. today), I guess we have three options:\n> > \n> >   1) Get the change above into PBR and released to PyPi, then update \n> >      the tarball URL in quantum as above\n> > \n> >   2) Revert the changes to Quantum which require latest oslo.config\n> > \n> >   3) Release oslo.config 1.2.0a2 to PyPi, exposing Grizzly users to the \n> >      development branch of oslo.config\n> > \n> > At this point, I\'m thinking we need to do (2) and get (1) figured out\n> > ASAP after havana-1. I\'ll look at getting the reverts proposed.\n> > \n> > On a related note, though, I see Monty has added pbr to devstack:\n> > \n> >   https://review.openstack.org/28590\n> > \n> > IMHO, it makes just as much sense to include oslo.config in devstack. We\n> > should always be testing trunk with the trunk version of oslo.config.\n> > \n> > Cheers,\n> > Mark.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<20130528170735.GD15025@matel-HP-Elite-7300-Series-MT>',NULL),('<1369841286.3586.144.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-29 10:28:06',-18000,'2013-05-29 15:28:06',NULL,'[openstack-dev] Desired goal for review turnaround time','On Wed, 2013-05-29 at 10:39 -0400, Russell Bryant wrote:\n> We now have some numbers we can look at for how long people are waiting\n> for code reviews.  What kind of turnaround time should we be aiming for?\n> \n> 5 days?\n\nThat seems like a good starting point to me.  It would also be\ninteresting to collect information on reviewer behavior.  For instance,\nI will have a lot of reviews on one day roughly every two weeks, then\ncontinue re-reviewing those changes until they go in, and occasionally\npick up other reviews throughout the period between spurts.  I suspect\nother reviewers have very different behavior?\n\n> The current data is below for reference.  Note that the numbers are a\n> good bit different than what I posted yesterday.  The numbers yesterday\n> included stable branch commits.  The script no longer includes those by\n> default (thanks to cyeoh for pointing this out).\n\nHow about the python-*client projects?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51A61308.8020202@redhat.com>',NULL),('<1369850792.3586.147.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-29 13:06:32',-18000,'2013-05-29 18:06:32',NULL,'[openstack-dev] Desired goal for review turnaround time','On Wed, 2013-05-29 at 12:21 -0400, Russell Bryant wrote:\n> > How about the python-*client projects?\n> \n> As noted before [1], they are included.  Are you asking for\n> repo-specific stats as opposed to project-wide stats?\n> \n> [1] http://lists.openstack.org/pipermail/openstack-dev/2013-May/009616.html\n\nOops, missed that, never mind :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51A62B0E.4040809@redhat.com>',NULL),('<1369858797.83997136@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-29 15:19:57',-18000,'2013-05-29 20:19:57',NULL,'[openstack-community] May 30 is the Call for Papers deadline for\n	Cloud Connect in Shanghai','\n\nPlease submit your OpenStack topics for this inaugural event in Shanghai by tomorrow, at [http://www.cloudconnectevent.cn/submission_en.php] http://www.cloudconnectevent.cn/submission_en.php.  The event is September 15-17.  Topics can be 60 minute sessions or panels, or half- or full-day workshops.  OpenStack will help to promote them.  Thank you!  \n -- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130529/cebfd7fc/attachment.html>\n\n',NULL,NULL),('<1369893054.11918.28.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 06:50:54',3600,'2013-05-30 05:50:54',NULL,'[openstack-dev] [oslo] deprecating openstack.common.wsgi','On Thu, 2013-05-30 at 14:34 +1200, Robert Collins wrote:\n> On 30 May 2013 12:07, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n> \n> > To officially indicate the module as deprecated, Mark suggested moving it to\n> > openstack/common/deprecated/wsgi.py. I have done that in changeset\n> \n> Thats going to break imports of it.\n\nAPIs in oslo-incubator break all the time. That\'s mostly the point of\nthe incubator.\n\n> Why not just delete it ? If noone uses it, there seems to be no value\n> in keeping it in-tree, and VCS history can recover it anytime.\n\nReddwarf is using it, as are some stackforge projects AFAIK. The idea\nwith this move is to put it into a \"no new features\" and \"don\'t use it\nfor new projects\" mode.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ23xEONW5yCc8bMmY1Gxjy9SvWpuHMYhD4KH_oZ4E3h7g@mail.gmail.com>',NULL),('<1369893980.11918.39.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 07:06:20',3600,'2013-05-30 06:06:20',NULL,'[openstack-dev] incubating diskimage-builder?','On Thu, 2013-05-30 at 13:17 +1200, Robert Collins wrote:\n> On 27 May 2013 21:57, Thierry Carrez <thierry at openstack.org> wrote:\n> > Robert Collins wrote:\n> >> Diskimage-builder isn\'t a whole lot of code, but thats deliberate ;).\n> >> It is however something I suspect will end up in the inner loop of a\n> >> bunch of projects as people get familiar with it\'s utility. Maybe it\n> >> should be an oslo component  [though its 95% shell], or maybe it\n> >> should be \'part of\' glance in the same way python-glanceclient is\n> >> \'part of\' glance.\n> >\n> > I think it makes sense as an Oslo component, exactly for the same\n> > reasons rootwrap is an Oslo component. Both are small, 95% shell, and\n> > end up in the inner loop of a bunch of OpenStack projects...\n> >\n> > Oslo already has a concept of \"specialist maintainer\" so you can keep\n> > driving it.\n> \n> Hi Mark; I think Thierry\'s suggestion of Oslo components makes sense.\n> Could you have a look at\n> https://github.com/stackforge/diskimage-builder and weigh in on what\n> you think the best route forward for this is?\n\nI can accept that Oslo\'s scope is a *little* nebulous, but some of the\nthings which I think defines Oslo\'s scope is:\n\n  - addressing cross-project technical debt\n  - python code which would historically have been across official\n    OpenStack projects\n  - building a set of python libraries focused on the needs of official \n    OpenStack projects\n  - oslo-core, as a group of python generalists with an interest in \n    clean APIs, are good reviewers for the code\n\nHonestly, even at a stretch, I don\'t think Oslo is the right umbrella to\nhave d-i-b under.\n\nThis process of trying to find somewhere to shoehorn d-i-b feels wrong\nto me. If it belongs in OpenStack now, it coming in as a new standalone\nthing shouldn\'t be a problem. Applying for incubation would make TC\nmembers give you properly considered feedback.\n\nWhere we get ourselves tied up into knots is trying to figure out which\ncategory it with fit into here:\n\n  https://wiki.openstack.org/wiki/Projects\n\nand whether it would be in a category that would have a PTL that\nautomatically gets a TC seat.\n\nAnd, well ... I\'m not a big fan of such rigid categorization because I\ndon\'t think it really helps much and it does constrain us in cases such\nas this ... and I\'m not a big fan of PTLs automatically having TC seats,\nbecause it bears too much on the consideration of new projects.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ1r9-L4e8GQAPu6aeVWgnVSYJ9yiu95KXVgonxQi2MNGw@mail.gmail.com>',NULL),('<1369906929.11918.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 10:42:09',3600,'2013-05-30 09:42:09',NULL,'[openstack-dev] incubating diskimage-builder?','On Thu, 2013-05-30 at 10:55 +0200, Thierry Carrez wrote:\n> \n> > This process of trying to find somewhere to shoehorn d-i-b feels wrong\n> > to me. If it belongs in OpenStack now, it coming in as a new standalone\n> > thing shouldn\'t be a problem. Applying for incubation would make TC\n> > members give you properly considered feedback.\n> \n> I think we could first have an open discussion at the next TC meeting\n> (Tuesday) to see where we think this best belongs. No need to formally\n> apply for incubation if we decide it belongs outside OpenStack\n> integrated release.\n\nAnd to be clear - even if (and I\'m not taking a position either way yet)\nwe said that d-i-b doesn\'t belong in the integrated release now, it\ndoesn\'t mean it never will.\n\nCheers,\nMark.\n\n\n\n','<51A7141C.3030400@openstack.org>',NULL),('<1369907042.11918.77.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 10:44:02',3600,'2013-05-30 09:44:02',NULL,'[openstack-dev] *How* to keep up with code reviews','Hey\n\nOn Thu, 2013-05-30 at 03:23 -0500, Dolph Mathews wrote:\n> Following Russell Bryant\'s quest to analyze our review-related performance\n> [1], I started wondering how we can go about improving those numbers.\n> Specifically, how can we reduce the average wait time for feedback on a\n> change?\n> \n> The simple answer: provide a better way to put reviewers in front of\n> changes worth reviewing. So, how about:\n> \n>   $ next-review\n>   https://review.openstack.org/29429 Make nova.virt.fake.FakeDriver useable\n> in integration testing\n> \n> This change was selected from all my watched projects in gerrit and\n> next-review automatically opens the review in my browser.\n> \n> To get started:\n> \n>   $ pip install next-review\n> \n> The logic for selecting an ideal review has a lot room for improvement\n> (e.g. based on bug priority, blueprint priority, pending feature freezes,\n> etc).\n\nHave you seen reviewday?\n\n  http://status.openstack.org/reviews/#keystone\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gUmZw-u_H+WVT4wmT1TUJ=XsH-RRXoiG=n-QEJu=rcogA@mail.gmail.com>',NULL),('<1369928249.3586.152.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 10:37:29',-18000,'2013-05-30 15:37:29',NULL,'[openstack-dev] Translatable strings in CLIs','On Thu, 2013-05-30 at 16:01 +0100, Hugh Saunders wrote:\n\n> On 30 May 2013 15:27, Doug Hellmann <doug.hellmann at dreamhost.com>\n> wrote:\n>         Should we do this work in the existing clients, or in the\n>         unified client? https://wiki.openstack.org/wiki/UnifiedCLI\n> \n> \n> Interesting, I hadn\'t come across that. Would make sense to make\n> messages in that translatable. \n> \n> \n> I\'d be interested in other opinions on whether it is sufficient to\n> focus effort on the unified cli or if the existing per-project CLIs\n> need translatable messages as well? \n\nIf I understand correctly, the unified CLI will be using the other\npackages in library mode, so if any of the API portion of those packages\nraise exceptions, it would be good to have those translatable.  Also,\nI\'ve seen something about making the REST APIs honor the Accept-Language\nHTTP header; it might be worthwhile to investigate how that header might\nbe set from the libraries as well.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAAD+Y3WZ-52y0-mWFBv0LF4QhB4Zh1vuvK7=aAPF7MPbz7a=eA@mail.gmail.com>',NULL),('<1369932620.11918.134.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 17:50:20',3600,'2013-05-30 16:50:20',NULL,'[openstack-dev] Some Oslo changes','Hey\n\nWe had some good discussions at the design summit which have evolved our\nthinking around Oslo a little bit. I thought I\'d try and summarize\nchanges which have happened since then.\n\nFirstly, I\'ve tried to update the wiki page to better explain what Oslo\nis all about:\n\n  https://wiki.openstack.org/wiki/Oslo\n\nOne of the things the wiki page talks about is how oslo-core is a group\nof \"generalist reviewers\" but that each Oslo API should also have a\nspecialist maintainer. I\'ve added a list of API maintainers to the\noslo-incubator repo and explained what their responsibilities are:\n\n  https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS\n\nWe\'ve also now started to talk about Oslo as a \"program\" rather than a\n\"project\" (credit to Monty for the term). Somewhat related to that,\nwe\'ve now included the pbr and hacking libraries in Oslo. The idea is\nthat libraries don\'t need to be called \"oslo.foo\" to be part of Oslo.\nSome libraries may be more suitable for adoption outside of OpenStack so\ndon\'t want to be constrained by the \"Oslo brand\".\n\nThe actual practical impact of pbr and hacking being a part of Oslo\nright now is that oslo-core have +2 permissions on these projects (while\nMonty and Joe/Sean remain as the \"specialist maintainers\" for pbr and\nhacking respectively) and we\'re committed to maintaining a reasonable\nlevel of API compatibility. We may evolve this in future into having all\nprojects aligned to the same versioning scheme, same release schedule\nand same API compat commitment, but it\'s early days yet.\n\nWe\'ve also set up a slot to hold project meetings and agreed we\'d only\nhold the meeting when someone has a topic they want to discuss:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n\nThe next meeting will be on Friday, May 7th to sync up on Oslo messaging\nprogress:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging\n\nFinally, I\'m really excited that we\'ve added Flavio Percoco and Zhongyue\nLuo. Many thanks to them for their awesome work on Oslo!\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1369934186.3586.159.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-30 12:16:26',-18000,'2013-05-30 17:16:26',NULL,'[openstack-dev] [oslo] deprecating openstack.common.wsgi','On Thu, 2013-05-30 at 16:57 +0000, Kurt Griffiths wrote:\n> Actually, the number of routes tested by John were anything but\n> realistic, if that\'s what you are referring to. With something more\n> like 10-20 routes, which is what you would expect with a data API,\n\nI think 10-20 routes is actually rather low, at least for a data API as\ncomplex as Nova.\n\n>  Falcon still performs like a champ, and there\'s a tree-based router\n> in the works that would make even insanely large numbers of deep\n> routes perform extremely well (although I\'m not yet convinced there is\n> a real-world use case for that).\n\nI wrote my own replacement for Routes (I call it URLTree); some\nbenchmarks show that it consistently performs significantly better than\nRoutes across the board.  I was surprised to see this with only 10\nrandomly selected routes, and when you get to numbers on the order of\n100 (which is where I suspect nova is), the increase in performance is\nquite impressive.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CDCCDBBB.7D80%kurt.griffiths@rackspace.com>',NULL),('<1369998459.11918.157.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 12:07:39',3600,'2013-05-31 11:07:39',NULL,'[openstack-dev] *How* to keep up with code reviews','On Thu, 2013-05-30 at 18:36 -0500, Dolph Mathews wrote:\n> On Thu, May 30, 2013 at 4:42 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> \n> >\n> >\n> >\n> > On Thu, May 30, 2013 at 3:57 PM, Dolph Mathews <dolph.mathews at gmail.com>wrote:\n> >\n> >>\n> >> On Thu, May 30, 2013 at 5:10 AM, Thierry Carrez <thierry at openstack.org>wrote:\n> >>\n> >>> Mark McLoughlin wrote:\n> >>> > Have you seen reviewday?\n> >>> >\n> >>> >   http://status.openstack.org/reviews/#keystone\n> >>>\n> >>> Both tools have their merits (which could probably be merged into the\n> >>> one good solution):\n> >>>\n> >>> reviewday gives priority to important features or critical bugs, and\n> >>> presents a list. It\'s a bit heavy (due to querying LP for priority) so\n> >>> it\'s refreshed periodically.\n> >>>\n> >>> next-review tries to skip reviews that have been -1ed (to present you\n> >>> the \"next review to consider\") and gives priority to old reviews. Its\n> >>> advice is based on fresh data.\n> >>>\n> >>\n> >> It\'s also personalized to what projects you\'re watching, what reviews\n> >> you\'ve already covered, what reviews you\'ve commented on and generally\n> >> tries to filter out as much noise as possible to put you in front of a\n> >> single review that would benefit from your immediate attention.\n> >>\n> >>\n> >\n> >\n> > While I like the web interface of reviewday which allows me to see the\n> > overall picture of what is ready for review, I like the personalized of\n> > next-review telling me what I have already reviewed, is it possible to get\n> > reviewday to be personalized the same way next-review is?\n> >\n> > On a related note, if you search for \"is:open CodeReview+2 Verified+1\n> > -Verified-1 -CodeReview-2 is:watched\" on review.openstack.org you can see\n> > what patches have no negative feedback and at least one +2 already.\n> >\n> >\n> Ooh, I didn\'t know you could query by Verified/CodeReview-- I\'ll have to\n> take advantage of that. Thanks!\n\nI actually use \'git review -l\' quite a bit and do things like\n\n  $> git review -l --mine | grep -v V=-1\n\nto exclude reviews which are failing tests\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gWEqgfJnw1bTvMdH7jJNRaj6-WX3RgcOfw2KTGNzv4AKg@mail.gmail.com>',NULL),('<136E780C-E855-4EDC-8380-8D310F796FBC@RACKSPACE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 20:10:54',0,'2014-05-29 20:10:54',NULL,'[openstack-dev] [Barbican][Heat] Reviews requested for Barbican\n	resources','Hello Barbican devs. I was wondering if we could get some of you to weigh in on a couple of reviews for adding Barbican support in Heat. We seem to be churning a bit around current and future features supported by the resources and could use some expert opinions.\n\nBlueprint: https://blueprints.launchpad.net/heat/+spec/barbican-resources\nOrder Resource: https://review.openstack.org/81906\nSecret Resource: https://review.openstack.org/79355\n\nThanks in advance for your time.\n\n',NULL,NULL),('<1370003482.11918.168.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 13:31:22',3600,'2013-05-31 12:31:22',NULL,'[openstack-dev] TC membership evolution, take 2','On Tue, 2013-05-28 at 15:29 +0200, Thierry Carrez wrote:\n\n> To kick off this second attempt, we had an interesting session at the\n> Design Summit where various goals were discussed and various solutions\n> proposed and compared. I summarized the current state of affairs on the\n> wiki at:\n> \n> https://wiki.openstack.org/wiki/TC_Membership_Models\n> \n> I\'d like everyone interested with this discussion to have a look at this\n> page. If you see goals that we missed, please suggest them on the thread\n> here, along with how well each currently-proposed solution would score\n> against it. Same if you think some model was not scored fairly against\n> existing stated goals. Finally, if you have an alternate model which\n> you\'d like to suggest, feel free to do so. I\'ll keep the wiki page\n> updated based on the ML discussion.\n\nOk, here\'s two things I\'d add:\n\n- Collaborative - the more emphasis we place on voting structures and\nrepresentation, the more bureaucractic our governance become, the more\nthe focus drifts from collaborating based on trust and shared interests\ntowards a combative model based on mistrust and competing interests.\n\n- Flexible - no governance is ever perfect and we must assume that our\ngovernance model will need to evolve over time as the challenges we face\nchange. This is true not only for the top-level OpenStack project\ngovernance, but also for the governance of individual projects, programs\nand teams.\n\nGranted, they\'re a bit harder to define than others ... but here\'s an\nattempt at scoring the models:\n\n\"PTLs+5\" (current model)\n\n * Collaborative: -1 (emphasis on representation)\n * Flexible: -1 (assumes PTL model)\n\n\"Best 7 PTLs + 6\" model\n\n * Collaborative: -1 (emphasis on representation)\n * Flexible: -1 (assumes PTL model)\n\n\"All-directly-elected 11\" model\n\n * Collaborative: +2 (focused on getting good people, not representation of interests)\n * Flexible: +2 (unlikely we\'ll need to change this much as OpenStack changes)\n\n\"Core PTLs + x\" model\n\n * Collaborative: -1 (emphasises representation of core projects)\n * Flexible: -1 (assumes PTL model)\n\n\"Category\" model\n\n * Collaborative: -1 (emphasis on representation)\n * Flexible: -1 (categories will have to be updated)\n\n\"no-PTL\" model\n\n * Collaborative: +1 (we assume collaboration with project leads will happen naturally)\n * Flexible: +1 (assumes PTL model)\n\n\"6 categorized PTLs + 7 directly-elected\" model\n\n * Collaborative: -2 (massive emphasis on ensuring representation)\n * Flexible: -2 (assumes PTL model, categories will have to be kept up to date)\n\nCheers,\nMark.\n\n\n\n','<51A4B140.6000005@openstack.org>',NULL),('<1370004000.11918.176.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 13:40:00',3600,'2013-05-31 12:40:00',NULL,'[openstack-dev] TC membership evolution, take 2','On Tue, 2013-05-28 at 15:29 +0200, Thierry Carrez wrote:\n\n> https://wiki.openstack.org/wiki/TC_Membership_Models\n> \n> I\'d like everyone interested with this discussion to have a look at this\n> page. If you see goals that we missed, please suggest them on the thread\n> here, along with how well each currently-proposed solution would score\n> against it. Same if you think some model was not scored fairly against\n> existing stated goals. Finally, if you have an alternate model which\n> you\'d like to suggest, feel free to do so. I\'ll keep the wiki page\n> updated based on the ML discussion.\n\nAnd here\'s an attempt at a completely different model which I don\'t\nexpect anyone to like, but might spark some ideas:\n\n\"Rough Consensus, Veto Triggers Plebiscite\"\n\nAll ATCs are members of the Technical Committee. Technical Committee\nmeetings become a forum to bring together people across the project\ninterested in specific topics. The detailed discussions happen over the\nmailing list. Project leaders use their influence to help drive\nconsensus. Any ATC who feels that a proposal is being forced through and\ndoesn\'t reflect a rough consensus can veto the proposal and trigger an\nimmediate plebiscite of members present. If a vote is triggered, the\nproposal requires a two thirds majority to pass. We build a culture of\nempowering people to JFDI with a - hopefully rarely used - safety valve.\n\nCheers,\nMark.\n\n\n\n','<51A4B140.6000005@openstack.org>',NULL),('<1370004316.11918.179.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 13:45:16',3600,'2013-05-31 12:45:16',NULL,'[openstack-dev] TC membership evolution, take 2','On Fri, 2013-05-31 at 08:06 -0400, Sean Dague wrote:\n> And if that\'s true... why not just give the flat 11 a shot. If it seems \n> to work, cool. Super low maintenance, no bikeshedding on categories, no \n> PTL growth concerns blocking things from getting incubated.\n> \n> If not, in 6 months or a year we revisit. Which we\'d have to do on any \n> category based model anyway. If OpenStack has taught me anything, it\'s \n> that predicting where OpenStack is going to be in a year is really hard. \n> Encoding the future structure of the TC, based on a snapshot of what \n> OpenStack seems to care about today, just seems doomed to unoptimal results. \n\nThat\'s very much my feeling too.\n\nI\'m actually pretty disappointed that some of us see so much danger!\n(Will Robinson) in the flat 11 model.\n\nCheers,\nMark.\n\n\n\n','<51A8925E.7080702@dague.net>',NULL),('<1370004675.11918.184.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 13:51:15',3600,'2013-05-31 12:51:15',NULL,'[openstack-dev] TC membership evolution, take 2','On Fri, 2013-05-31 at 07:49 -0400, Monty Taylor wrote:\n> Or, since we\'re technical:\n> \n> slots = dict(\n>     compute=None,\n>     storage=None,\n>     networking=None,\n>     infra=None,\n>     ops=None,\n>     cross=None)\n> at_large = list()\n> \n> for candidate in election_results_sorted_by_rank:\n>     ptl = candidate.get_ptl_category()\n>     if not slots[ptl]:\n>         slots[ptl] = candidate\n>         continue\n>     if len(at_large) < 7:\n>         at_large.append(candidate)\n>         continue \n\nI gave a talk on OpenStack governance at a local meetup a couple of\nweeks ago. I\'m already not delighted at how bureaucratic we seem. This\nwould take the biscuit :)\n\nI\'m honestly not sure I\'d ever get to a point where I can explain this\noff the top of my head to a newbie in a reasonable amount of time.\n\nAt some point, a governance structure seems so overly bureaucratic for\nthe task at hand that many pragmatic, \"I just want to build stuff\"\npeople won\'t even care to take the time to figure out the structure.\n\nCheers,\nMark.\n\n\n\n','<51A88E48.8010606@inaugust.com>',NULL),('<1370011347.11918.186.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 15:42:27',3600,'2013-05-31 14:42:27',NULL,'[openstack-dev] Import ordering for oslo imports','On Fri, 2013-05-31 at 10:33 -0400, David Ripton wrote:\n> hacking\'s HACKING.rst says:\n> \n>    {{stdlib imports in human alphabetical order}}\n>    \\n\n>    {{third-party lib imports in human alphabetical order}}\n>    \\n\n>    {{nova imports in human alphabetical order}}\n>    \\n\n>    \\n\n>    {{begin your code}}\n> \n> But should oslo imports (in code outside oslo itself) go in the \n> third-party section or the project section?  oslo is kind of both -- \n> it\'s a separate project but it\'s part of OpenStack, not truly third-party.\n> \n> I\'ve seen it both ways in code I\'ve reviewed lately, and it would be \n> nice to be consistent.\n\nIf you mean e.g. oslo.config imports, they should go in the\n\"third-party\" section - i.e. it\'s code from outside the nova repo\n\nIf you mean code copied from oslo-incubator, then that does live in the\nnova repo and should go in the \'nova imports\' section\n\nCheers,\nMark.\n\n\n\n','<51A8B4A8.9070508@redhat.com>',NULL),('<1370013307.11918.206.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 16:15:07',3600,'2013-05-31 15:15:07',NULL,'[openstack-dev] Oslo messaging API design','On Mon, 2013-05-13 at 11:27 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Mon, May 13, 2013 at 11:02 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         Hey Doug,\n>         \n>         On Mon, 2013-05-13 at 10:43 -0400, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         > On Sat, May 11, 2013 at 1:07 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         >         On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:\n>         >         > Hey\n>         >         >\n>         >         > I\'ve been working on gathering requirements and design ideas for a\n>         >         > re-design of Oslo\'s RPC and notifications API. The goals are:\n>         >         >\n>         >         >   1) A simple and easy to understand RPC abstraction which enables\n>         >         >      all of the intra project communication patterns we need for\n>         >         >      OpenStack\n>         >         >\n>         >         >   2) It should be possible to implement the RPC abstraction using a\n>         >         >      variety of messaging transports, not just AMQP or AMQP-like\n>         >         >\n>         >         >   3) It should be a stable API with plenty of room for backwards\n>         >         >      compatible evolution in the future so that we can release it as a\n>         >         >      standalone library\n>         >         >\n>         >         > Here\'s what I have so far:\n>         >         >\n>         >         >   https://wiki.openstack.org/wiki/Oslo/Messaging\n>         >\n>         >\n>         >         Just a quick status update. We\'re using this etherpad to coordinate:\n>         >\n>         >           https://etherpad.openstack.org/HavanaOsloMessaging\n>         >\n>         >         and this branch:\n>         >\n>         >           https://github.com/markmc/oslo-incubator/commits/messaging\n>         >\n>         >         At this point, we\'ve got a pretty solid API design, a working fake\n>         >         driver and some simple test code.\n>         >\n>         >\n>         > Have you given any thought to how the MessageHandlingServer can listen\n>         > on more than one target? That\'s an important use case for ceilometer,\n>         > which I didn\'t address in my earlier changes.\n>         >\n>         >\n>         > Do we need to support different transports (and drivers), or just\n>         > multiple targets?\n>         \n>         \n>         I guess I was thinking you\'d just create multiple servers, but you\n>         probably really want a single executor and dispatcher pair with multiple\n>         listeners.\n>         \n>         Would something like this work?\n>         \n>             def start(self):\n>                 if self._executor is not None:\n>                     return\n>                 self._executor = self._executor_cls(self.conf, self.dispatcher)\n>                 self.listen(self.transport, self.target)\n>                 self._executor.start()\n>         \n>             def listen(self, transport, target):\n>                 self._executor.add_listener(transport._listen(target))\n> \n> \n> I am worried there might be a case where the executor will have a hard\n> time adding a listener after it has been started. How would the\n> blocking executor do that, for example?\n\nVery interesting question and after spending a good deal of time on it,\nthe only conclusion I\'ve really come to is we need to spend more time\nthinking about it. Oh, and I need to go investigate tulip like you\noriginally said ... :)\n\nI\'m not sure it\'s so much the problem of how to add a listener after it\nhas been started. It\'s more a question of how best to go about\nsupporting multiple listeners at all.\n\nFirstly, what are the semantics of the blocking executor? That start()\nwill block and messages will be dispatched in the thread which called\nstart()? Right?\n\nOr do we go further, and say that the blocking executor never creates\nany (native) threads? Is that an implementation detail, or is it\nimportant semantics for some classes of applications?\n\nI would have thought that a \"no threads\" semantic would be a useful\nthing to support, but looking at e.g. the python-qpid library I see that\nit creates threads without giving the caller any option in the matter.\n\nBut, I digress ...\n\nIf the blocking executor semantics is purely that start() blocks and\nmessages are dispatched in the calling thread, then we can implement\nsupport for multiple listeners by spawning off threads which call\nlistener.poll() and put messages on a queue for the calling start()\nthread to dispatch. Adding another listener is simply a matter of\nspawning off a new polling thread.\n\nAnd a further digression ...\n\nI would have liked if we could have relied on listeners exposing a\nselect()able file handle and we could implement the blocking executor\nvery simply using select(). I was all happy because I got this working\nwith kombu:\n\n  https://gist.github.com/markmc/5685616\n\nbut I\'m 95% certain there\'s no selectable file handle exposed by\npython-qpid :(\n\nPerhaps we could add a simple abstraction for transports that don\'t\nsupport this - i.e. create a thread to poll for messages and add them to\na selectable queue. We just require that listeners are selectable and\nmove the responsibility for polling in a thread out of the executor and\ninto the transport driver.\n\nBut, with all that said, we\'re using eventlet right now and making\nlisteners selectable just isn\'t interesting in that context. I\'d be\ntempted to just say the blocking executor doesn\'t support multiple\nlisteners right now.\n\nHmm.\n\nCheers,\nMark.\n\n\n\n','<CADb+p3SiJTG4PLMKtREjD-VfpnLgFPDLpAPFon=8xtowfJaYfg@mail.gmail.com>',NULL),('<1370014290.3586.167.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 10:31:30',-18000,'2013-05-31 15:31:30',NULL,'[openstack-dev] [Nova] Proposal to add Brian Elliott to\n nova-core','On Fri, 2013-05-31 at 10:00 -0400, Russell Bryant wrote:\n> I propose that we add Brian Elliott to the nova-core team.\n\n+1!\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51A8ACF1.3060206@redhat.com>',NULL),('<1370014844.11918.207.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 16:40:44',3600,'2013-05-31 15:40:44',NULL,'[openstack-dev] [Nova] Proposal to add Brian Elliott to\n nova-core','On Fri, 2013-05-31 at 10:00 -0400, Russell Bryant wrote:\n> Greetings,\n> \n> I propose that we add Brian Elliott to the nova-core team.\n> \n> Brian has been consistently heavily involved in reviews over the last\n> few months [1] where he has been providing good feedback [2][3].\n> \n> He has also done excellent work on the Nova code [2][3].\n> \n> Please reply with +1s or any concerns.\n\n+1 :)\n\nCheers,\nMark.\n\n\n\n','<51A8ACF1.3060206@redhat.com>',NULL),('<1370015730.11918.220.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 16:55:30',3600,'2013-05-31 15:55:30',NULL,'[openstack-dev] TC membership evolution, take 2','On Fri, 2013-05-31 at 09:08 -0400, Monty Taylor wrote:\n> \n> On 05/31/2013 08:40 AM, Mark McLoughlin wrote:\n> > On Tue, 2013-05-28 at 15:29 +0200, Thierry Carrez wrote:\n> > \n> >> https://wiki.openstack.org/wiki/TC_Membership_Models\n> >>\n> >> I\'d like everyone interested with this discussion to have a look at this\n> >> page. If you see goals that we missed, please suggest them on the thread\n> >> here, along with how well each currently-proposed solution would score\n> >> against it. Same if you think some model was not scored fairly against\n> >> existing stated goals. Finally, if you have an alternate model which\n> >> you\'d like to suggest, feel free to do so. I\'ll keep the wiki page\n> >> updated based on the ML discussion.\n> > \n> > And here\'s an attempt at a completely different model which I don\'t\n> > expect anyone to like, but might spark some ideas:\n> > \n> > \"Rough Consensus, Veto Triggers Plebiscite\"\n> > \n> > All ATCs are members of the Technical Committee. Technical Committee\n> > meetings become a forum to bring together people across the project\n> > interested in specific topics. The detailed discussions happen over the\n> > mailing list. Project leaders use their influence to help drive\n> > consensus. Any ATC who feels that a proposal is being forced through and\n> > doesn\'t reflect a rough consensus can veto the proposal and trigger an\n> > immediate plebiscite of members present. If a vote is triggered, the\n> > proposal requires a two thirds majority to pass. We build a culture of\n> > empowering people to JFDI with a - hopefully rarely used - safety valve.\n> \n> I\'m going to read that as a joke, because if I do, it\'s actually quite\n> funny.\n\nYou mean, you don\'t like it? Awww ... :)\n\nI wouldn\'t go so far as to call the above a joke - more of a thought\nexperiment :)\n\n> I mean, I\'ve watched Debian try to get things done over the\n> years, and it\'s a comical expression of exactly how JFDI such a thing\n> winds up being.\n> \n> We aren\'t talking about 20 people here. If we were, sure. We\'re talking\n> about over 800. The mailing list is a TERRIBLE way to discover\n> consensus, and in the history of OpenStack it has never one time worked.\n> The mailing list is a great way to uncover points of view.\n\nVoting isn\'t exactly an awesome way of uncovering consensus either ...\nbut it does gets a decision made. The risk is that you rush to a vote\ntoo early on something and it gets through by a narrow margin even\nthough you could have built a better consensus.\n\nMy point about the mailing list was that TC meetings shouldn\'t be where\nthe considered and thoughtful happens ... because a mailing list\ndiscussion gives people a better chance to actually think about things\nand listen to each other.\n\nBut yes, a real-time, follow-up discussion maybe be required to hammer\nout some compromise so a consensus can be hammered out.\n\n> It\'s all well and good to eye-roll the \"ridiculous structure\" that we\n> have and to wave ones hands in the air and laugh at concerns about undue\n> influence. I\'d like to counter that with the fact that we are a project\n> with 800 developers after 3 years, over 200 companies, and we are\n> churning out results like a banshee. I think we have thusfar done an\n> excellent job in not making things too bureaucratic, with the one\n> exception that we ask people to vote every once in a while.\n\nI agree, it\'s working very well. Indeed, the title of that talk was\n\"OpenStack Governance: What it is and why it\'s working\".\n\nAs we evolve it, though, I\'ll always advocate for less bureaucracy\nrather than more.\n\nFor example, I think some of our current governance probably really\nhelped when we were still building trust between project leaders and\nconcerned about corporate control. I think there\'s a huge amount of\ntrust around these days, and maybe we should embrace that a bit more.\n\n> Fine, let\'s do an all-direct-elected TC. I don\'t think it\'s going to be\n> that much of a problem. But let\'s address the actual issue, and not\n> battle a bureaucracy that simply isn\'t there and also simply isn\'t a\n> problem.\n\nIt\'s the addition of bureaucracy to cope with the growth of the project\nthat\'s being discussed here.\n\n> You wanna explain the TC structure under the 6+7 model to newbs? How\n> about this:\n> \n> OpenStack is a collection of projects. Each project has a leader that is\n> elected from the contributors to that that project. Each project leader\n> has control of his or her project, but occasionally there are topics\n> where it is advantageous for OpenStack to do things consistently. To\n> that end, there is a Technical Committee, which is comprised of a set of\n> the project leads, and a set of at large members.\n> \n> Done. It took me 2 minutes to explain. It\'s not even crazy, because I\n> wasn\'t going out of my way to make it sound complex. How does the voting\n> system for that body work? Screw it - that\'s an advanced topic, and most\n> people will never care enough to pay attention.\n\nI don\'t buy the fudge, frankly :)\n\nHow the project leads are chosen does matter or we wouldn\'t be debating\nit. Anyone interested in how our governance works will attempt to\nunderstand it.\n\nCheers,\nMark.\n\n\n\n','<51A8A0B3.6070708@inaugust.com>',NULL),('<1370016173.11918.227.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 17:02:53',3600,'2013-05-31 16:02:53',NULL,'[openstack-dev] TC membership evolution, take 2','On Fri, 2013-05-31 at 14:53 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > \"Rough Consensus, Veto Triggers Plebiscite\"\n> > \n> > All ATCs are members of the Technical Committee. Technical Committee\n> > meetings become a forum to bring together people across the project\n> > interested in specific topics. The detailed discussions happen over the\n> > mailing list. Project leaders use their influence to help drive\n> > consensus. Any ATC who feels that a proposal is being forced through and\n> > doesn\'t reflect a rough consensus can veto the proposal and trigger an\n> > immediate plebiscite of members present. If a vote is triggered, the\n> > proposal requires a two thirds majority to pass. We build a culture of\n> > empowering people to JFDI with a - hopefully rarely used - safety valve.\n> \n> Ew. I\'ve been part of such open source communities in the past and you\n> always end up spending your time voting on everything. You\'d be\n> surprised how many people like to be consulted on every question. It\n> makes up a very brittle community that is easy to disrupt... Commit\n> once, veto and trigger plebiscites on every topic for one year.\n\nThat\'s a risk, for sure. The reason I suggest this (and I\'m not trying\nto say it\'s actually a serious proposal) is that I think our community\'s\nreaction to this new world would be that we\'d have very, very few votes.\n\nI don\'t have anything to back that up other than a feeling that our\nculture would not entertain people who regularly veto and lose the\nresulting vote. Maybe you only get one veto per release cycle :)\n\n> You need leadership in a project to make hard calls and go somewhere. If\n> you make sure that leadership is representative of your contributors,\n> you end up with a pretty efficient combination.\n\nAbsolutely you need leadership. The best leadership (IMHO) builds a\nrough consensus, rather than a slim majority in a combative vote.\n\nIndeed, the rough consensus approach is exactly what you\'re doing in\nthis thread :)\n\nCheers,\nMark.\n\n\n\n\n\n','<51A89D61.9090800@openstack.org>',NULL),('<1370016365.11918.229.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-31 17:06:05',3600,'2013-05-31 16:06:05',NULL,'[openstack-dev] *How* to keep up with code reviews','On Fri, 2013-05-31 at 07:27 -0400, Monty Taylor wrote:\n> I love this tool. Thank you dolph.\n\nHmm, my contributions to this thread may have sounded like \"we already\nhave tools for this, we don\'t need more\" :)\n\nNothing could be further from the truth, the more tools, ideas and tips\nwe share for coping with the review load, the better. Nice work Dolph!\n\nCheers,\nMark.\n\n\n\n','<51A88925.6000002@inaugust.com>',NULL),('<1370250612.30626.14.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-03 10:10:12',3600,'2013-06-03 09:10:12',NULL,'[openstack-dev] [Ceilometer] Switching keystoneclient','Hi,\n\nWhen cloud X has a certain keystoneclient handler which is different to\nthe normal one the standard way of switching it out is using\npaste.app_factory.  Ceilometer uses Pecan which doesn\'t use Paste so is\nthere a way to do this?\n\nI\'m currently working on Libra\'s (an LBaaS solution) API server which\nuses Pecan, I\'ve made an acl.py which dynamically loads the keystone\npart but there may well be a better solution out there.\n\nKind Regards\n-- \nAndrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/\n\n\n\n',NULL,NULL),('<1370375845.2744.44.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-04 15:57:25',-14400,'2013-06-04 19:57:25',NULL,'[openstack-dev] [barbican] Date/time/timezone parsing','On Tue, 2013-06-04 at 19:50 +0000, John Wood wrote:\n> Hello folks, \n> \n> \n> We noticed that the \'timeutils.py\' module\'s \'parse_isotime()\' function\n> in Oslo Incubator doesn\'t properly parse all ISO8601-compliant\n> strings, or else raise parse errors for non compliant strings.  Has\n> anyone else noticed this behavior?\n> \n> \n> This is a problem for Barbican as we need to precisely know when to\n> expire a secret to avoid unpleasant surprises, but this \'off by a few\n> hours\' issue may not be a problem for other parts of OpenStack.\n> \n> \n> For example, if you try to pass a string of the form (no \':mm\' after\n> the final \'hh\'):\n> \n> \n> YYYY-MM-DDThh:mm:ss?hh\n> \n> \n> ...results in the timezone offset being ignored. Likewise for this\n> form (single digit timezone):\n> \n> \n> YYYY-MM-DDThh:mm:ss?h:mm\n> \n> \n> ...results in the timezone being ignored.  \n> \n> \n> As a concrete example, the following failed to observe the timezone:\n> \n> \n> 013-06-14T12:06:30.629256-5:00\n> \n> \n> whereas this following works:\n> \n> \n> 013-06-14T12:06:30.629256-05:00\n> \n\nYou should always use UTC dates in barbican, using/allowing timezones is\nonly going to hit you back, badly.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<49F5BF8205841548AB38409969C7AB3F7ED5E8F7@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1370424538.13290.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 10:28:58',3600,'2013-06-05 09:28:58',NULL,'[openstack-dev] Reminder: Oslo project meeting','Hi\n\nWe\'re having an IRC meeting on Friday to sync up again on the messaging\nwork planned for Havana:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n  https://etherpad.openstack.org/HavanaOsloMessaging\n\nSee you on #openstack-meeting at 1400 UTC\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1370431723.13290.35.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 12:28:43',3600,'2013-06-05 11:28:43',NULL,'[openstack-dev] Oslo messaging API design','On Fri, 2013-05-31 at 16:15 +0100, Mark McLoughlin wrote:\n> On Mon, 2013-05-13 at 11:27 -0400, Doug Hellmann wrote:\n> > \n> > \n> > \n> > On Mon, May 13, 2013 at 11:02 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> >         Hey Doug,\n> >         \n> >         On Mon, 2013-05-13 at 10:43 -0400, Doug Hellmann wrote:\n> >         >\n> >         >\n> >         >\n> >         > On Sat, May 11, 2013 at 1:07 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> >         >         On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:\n> >         >         > Hey\n> >         >         >\n> >         >         > I\'ve been working on gathering requirements and design ideas for a\n> >         >         > re-design of Oslo\'s RPC and notifications API. The goals are:\n> >         >         >\n> >         >         >   1) A simple and easy to understand RPC abstraction which enables\n> >         >         >      all of the intra project communication patterns we need for\n> >         >         >      OpenStack\n> >         >         >\n> >         >         >   2) It should be possible to implement the RPC abstraction using a\n> >         >         >      variety of messaging transports, not just AMQP or AMQP-like\n> >         >         >\n> >         >         >   3) It should be a stable API with plenty of room for backwards\n> >         >         >      compatible evolution in the future so that we can release it as a\n> >         >         >      standalone library\n> >         >         >\n> >         >         > Here\'s what I have so far:\n> >         >         >\n> >         >         >   https://wiki.openstack.org/wiki/Oslo/Messaging\n> >         >\n> >         >\n> >         >         Just a quick status update. We\'re using this etherpad to coordinate:\n> >         >\n> >         >           https://etherpad.openstack.org/HavanaOsloMessaging\n> >         >\n> >         >         and this branch:\n> >         >\n> >         >           https://github.com/markmc/oslo-incubator/commits/messaging\n> >         >\n> >         >         At this point, we\'ve got a pretty solid API design, a working fake\n> >         >         driver and some simple test code.\n> >         >\n> >         >\n> >         > Have you given any thought to how the MessageHandlingServer can listen\n> >         > on more than one target? That\'s an important use case for ceilometer,\n> >         > which I didn\'t address in my earlier changes.\n> >         >\n> >         >\n> >         > Do we need to support different transports (and drivers), or just\n> >         > multiple targets?\n> >         \n> >         \n> >         I guess I was thinking you\'d just create multiple servers, but you\n> >         probably really want a single executor and dispatcher pair with multiple\n> >         listeners.\n> >         \n> >         Would something like this work?\n> >         \n> >             def start(self):\n> >                 if self._executor is not None:\n> >                     return\n> >                 self._executor = self._executor_cls(self.conf, self.dispatcher)\n> >                 self.listen(self.transport, self.target)\n> >                 self._executor.start()\n> >         \n> >             def listen(self, transport, target):\n> >                 self._executor.add_listener(transport._listen(target))\n> > \n> > \n> > I am worried there might be a case where the executor will have a hard\n> > time adding a listener after it has been started. How would the\n> > blocking executor do that, for example?\n> \n> Very interesting question and after spending a good deal of time on it,\n> the only conclusion I\'ve really come to is we need to spend more time\n> thinking about it. Oh, and I need to go investigate tulip like you\n> originally said ... :)\n\nWell, that was quite an adventure.\n\nYou might have seen a blog I wrote on the general topic of async I/O and\ntulip:\n\n  http://blogs.gnome.org/markmc/2013/06/04/async-io-and-python/\n\nAnd now I\'ve tried to play with an implementation for a tulip based\nexecutor:\n\n  https://github.com/markmc/oslo-incubator/blob/8509b8b/openstack/common/messaging/_executors/impl_tulip.py\n\nIn terms of the capabilities of listeners, I\'m thinking there are three\npossibilities:\n\n  1) listeners who can poll for messages asynchronously - i.e. can\n     expose a method to poll for messages which returns a coroutine\n     object (listener would have a poll_async() method)\n\n  2) listeners who can poll for messages in a non-blocking fashion and\n     give us a select()able read file descriptor (listener would have\n     a poll() method and accept a timeout kwarg to poll())\n\n  3) listeners who must block to poll for a message\n\nWe could require that all listeners expose an interface for (1) and hide\nthe fact they can do (2) or (3), or we can just make the executor handle\nall three modes.\n\nIn my mockup, the process_async(), process_selectable() and\nprocess_blocking() methods correspond to these three modes. It seems\nfairly plausible to me, but I could be missing something huge since I\nhaven\'t even tried to run the code :)\n\nBut there\'s also the dispatch callback side to think of. In the tulip\nexecutor code, I\'m assuming the callback is async (i.e. it will return a\ncoroutine object or future) so it needs to be paired with a tulip\ndispatcher which would know whether the target method is async and\nexecute it in a thread pool if not\n\ni.e. we\'d have something like:\n\n  @messaging.expose(async=True)\n  def do_something(self):\n      result = yield from self.remote_server.get_something_async()\n      return self.db_api.store_async(result)\n\nor:\n\n  @messaging.expose()\n      result = self.remote_server.get_something()\n      return self.db_api.store(result)\n\nand in the latter case, the tulip based dispatcher would know to use a\nthread pool.\n\nThat implies that you need to pair a tulip-aware executor with a\ntulip-aware dispatcher. We\'ll probably need to do something similar for\neventlet too.\n\nMaybe a dispatcher should return metadata from the expose() decorator\nand a partial which encapsulates the invocation on the target method and\nits the executor that actually executes it? The problem right now is\nthat the dispatcher finds the target and immediately decides how to\nexecute it, but we want executor specific logic about how to execute it.\n\nI think we\'re getting close to an answer :)\n\nOh, your original question was about multiple listeners - that still\nseems perfectly doable to me. In the tulip executor, we\'d just add a new\nmessaging processing task for that listener.\n\nCheers,\nMark.\n\n\n\n','<1370013307.11918.206.camel@sorcha>',NULL),('<1370439583.22798.1.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 09:39:43',-14400,'2013-06-05 13:39:43',NULL,'[openstack-dev] [barbican] Date/time/timezone parsing','On Wed, 2013-06-05 at 12:36 +0000, Jarret Raim wrote:\n> On 6/4/13 9:13 PM, \"John Dennis\" <jdennis at redhat.com> wrote:\n> \n> >On 06/04/2013 07:01 PM, John Wood wrote:\n> >> Simo, we were planning to normalize times into UTC prior to putting\n> >>into datastore, but didn\'t know if it would be too stringent to make\n> >>clients also conform to UTC to use the API. Using UTC on both sides of\n> >>the API does seem safer and more robust overall though, so we could\n> >>enforce this in our code base for sure.\n> >>\n> >> Would anyone out there object to a UTC-only mode of operation for\n> >>barbican?\n> >\n> >Time values should always be in UTC. The only time (no pun intended) a\n> >time value should be in local time is when it is displayed to the user\n> >or accepted as user input, after which it should immediately be\n> >converted to UTC. Following the rule that time values are always UTC\n> >will prevent any number of nasty problems that can easily be avoided.\n> \n> \n> The API will store all date times as UTC. However, when a customer\n> specifies a timezone offset in a message, we have two options. Either we\n> accept the message, modify the UTC time to correctly represent the\n> requested date time (e.g. Apply the offset) or reject the message as\n> malformed. \n> \n> The current iso8601 implementation allows us to do neither. In some cases\n> it incorrectly parses the timezone offset (or ignores it) and does not\n> throw an error. I\'m fine with rejecting a message with an offset if that\'s\n> the way that the rest of the APIs work. Is there a way to do that with the\n> current olso / iso8601 implementation? I guess we could roll our own, but\n> that seems like something property belonging to the parsing library.\n\nI would say the library needs to be fixed and an option added to refuse\nany date not in UTC format.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CDD49A23.69F89%jarret.raim@rackspace.com>',NULL),('<1370456815.939924976@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-06-05 13:26:55',-18000,'2013-06-05 18:26:55',NULL,'[openstack-community] Help needed to staff and present in OpenStack\n	booth at Cloud Expo','\n\nHi all,  Cloud Expo East is next week, June 10-13, at the Javits Center in NYC.  We have an exciting booth there that allows for 10-15 minute presentations or demos.  We invite you to come present in our booth.  Presentations and demos must represent OpenStack and not your companies, however.  We also need booth volunteers to talk with folks. \n \nThe show hours are\nMonday, June 10, 6:30-8pm (reception)\n Tuesday, June 11, 10am-12:30pm, 3-5:30pm\nWednesday, June 12, 10am-12:30pm, 3-5:30pm\nThursday, June 13, 10am-12:30pm, 2:30-5pm \nIf you can help out in either regard, please sign up as soon as possible at [https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDBXMzYwb3ZiT1dGbzV0RFpXLV80ZGc&usp=drive_web#gid=0] https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDBXMzYwb3ZiT1dGbzV0RFpXLV80ZGc&usp=drive_web#gid=0\nRegister at [https://www.blueskyz.com/v3/Login.aspx?ClientID=19&EventID=70] https://www.blueskyz.com/v3/Login.aspx?ClientID=19&EventID=70\n\nFill out the Attendee Information form\nSelect the VIP Gold Pass Registration Option\n\nEnter the Discount Code: openstackVIPgold (unlimited - pass it on!)\n\nThe price will re-set from $2,000 to $0.\nThank you!-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130605/a11722db/attachment.html>\n\n',NULL,NULL),('<1370463947.13290.41.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 21:25:47',3600,'2013-06-05 20:25:47',NULL,'[openstack-dev] Fwd: Eventlet 0.13 is going to have minor\n incompatible change in subprocess API','On Wed, 2013-06-05 at 13:33 -0400, Doug Hellmann wrote:\n> Do we have an eventlet expert available to figure out if this is going to\n> bite us?\n> \n> Doug\n> \n> ---------- Forwarded message ----------\n> From: Sergey Shepelev <temotor at gmail.com>\n> Date: Tue, Jun 4, 2013 at 1:26 PM\n> Subject: Eventlet 0.13 is going to have minor incompatible change in\n> subprocess API\n> To: comp-lang-python-announce at moderators.isc.org\n> \n...\n> If you are curious what\'s going on, here\'s the full story:\n> Python 3.3 introduced `timeout` kwarg to lots of methods of subprocess\n> module. The RHEL guys backported it to their Python 2.6 package. At some\n> point, the code they used started to use subprocess from Eventlet which\n> does not have the `timeout` kwarg.\n> https://bitbucket.org/eventlet/eventlet/issue/89\n> https://bitbucket.org/eventlet/eventlet/pull-request/30\n> Now in Eventlet, I am going to introduce the `timeout` argument and to make\n> it forward compatible with Python3, it\'s going to get first place, like in\n> stdlib.\n> To interested people, you may leave a comment in this discussion or in this\n> Github thread: https://github.com/eventlet/eventlet/pull/34\n\nThis is actually really good news. We\'ll be able to remove\ncontrib/redhat-eventlet.patch from all projects when it\'s released.\n\nCheers,\nMark.\n\n\n\n','<CADb+p3SpSRT-LgMqcfFpsO7OmfAQcU=8mwYKYCEpVLOLOkScnA@mail.gmail.com>',NULL),('<1370470663.13290.45.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-06-05 23:17:43',3600,'2013-06-05 22:17:43',NULL,'[OpenStack Foundation] Board Meeting - May 30th','On Thu, 2013-05-30 at 21:13 +0200, Jonathan Bryce wrote:\n> Hi everyone,\n> \n> The OpenStack Foundation Board of Directors had a telephone meeting\n> today at 9:00am PDT/1600 UTC. The meeting lasted just about 2 hours,\n> but the Board ran through quite a few updates and short discussions on\n> a number of topics.\n\nThanks Jonathan!\n\nI\'ve posted my summary:\n\n  http://blogs.gnome.org/markmc/2013/06/05/may-30th-openstack-foundation-board-meeting/\n\nCheers,\nMark.\n\n\n\n','<F02596CA-FC0E-4470-968E-FEF3191CC780@openstack.org>',NULL),('<1370495821.13290.48.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-06-06 06:17:01',3600,'2013-06-06 05:17:01',NULL,'[OpenStack Foundation] [Foundation Board] Board Meeting - May\n 30th','On Thu, 2013-06-06 at 10:07 +1000, Tristan Goode wrote:\n> I thought the policy of the Board was no blogging until after the minutes\n> are approved, and not Jonathan?s _unofficial_ summary?\n\nNope, the policy is to wait for Jonathan\'s summary.\n\n> Should the Board not be providing news first to the members, and then we\n> can enjoy the Daily Show.\n\nCharming.\n\nThanks,\nMark.\n\n\n\n','<b0522f931e01472bcc3f05c26fe6d429@mail.gmail.com>',NULL),('<1370511941.13290.67.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 10:45:41',3600,'2013-06-06 09:45:41',NULL,'[openstack-dev] How to handle forking of projects','On Thu, 2013-06-06 at 10:34 +0200, Matthias Runge wrote:\n> Hey,\n> I came to this question over the the following review:\n> https://review.openstack.org/#/c/31725/\n> \n> The situation is: Horizon ships a bundled library query-table-sorter,\n> which hasn\'t seen a release since ages.\n> The proposed commit changes the bundled lib, effectively creating a fork.\n> \n> Is that allowed/desired, or how should we handle this?\n\nI agree with you that we should avoid forking a library.\n\nMaybe it wouldn\'t be ridiculous to have a patch file in the source tree\nthat gets applied to the library by e.g. devstack and we tell OpenStack\ndistributors they need to include the patch in their version of the\nlibrary ... assuming everyone isn\'t just using the bundled version. I\ndunno.\n\n> As a side note, that plugin is licensed as GPL (without a version) and MIT.\n> \n> Are we allowed to bundle this at all?\n\nGood question, referred to legal-discuss here:\n\n  http://lists.openstack.org/pipermail/legal-discuss/2013-June/000077.html\n\nCheers,\nMark.\n\n\n\n','<51B049A1.4070509@redhat.com>',NULL),('<1370518606.13290.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 12:36:46',3600,'2013-06-06 11:36:46',NULL,'[openstack-dev] TC membership evolution to All-directly-elected\n model','On Thu, 2013-06-06 at 12:24 +0200, Thierry Carrez wrote:\n> Hi everyone,\n> \n> At the TC meeting Tuesday, members agreed on the need to change the TC\n> membership model, but diverged on the ideal solution. Three models were\n> mentioned in various preference orders. It was suggested to set up a\n> Condorcet poll to help select the model which was the most consensual\n> and the most likely to reach the threshold of two-thirds of members (10\n> \"yes\") necessary to pass a TC charter modification (\"special motion\").\n> \n> The Condorcet winner of this poll[1] is the \"All-directly-elected\"\n> model: Direct election of TC members over the whole ATC membership using\n> a staggered election every 6 months resulting in one-year seats. Total\n> members would be 11 or 13.\n>\n> Now we need to further discuss and refine the details of this model to\n> come to a clear motion which will be voted on at a future TC meeting.\n> \n> One of the details we need to discuss is the exact number of members. 11\n> or 13 ? In the 11 case, we\'d renew 5 members every Fall and 6 every\n> Spring. In the 13 case, we\'d renew 6 every Fall and 7 every Spring. A\n> minimum of 6 members would be necessary to hold a meeting in the 11\n> case, and a minimum of 7 members would be necessary in the 13 case.\n> Special motions would take 8 \"YES\" in a 11-member TC, while they would\n> require 9 \"YES\" in a 13-member TC. Personally I don\'t care that much\n> either way, I think both would work.\n\nSlight preference for 13, since it might give us more diversity. Don\'t\nsee a big downside to having 2 more people.\n\n> Another detail is how to encourage diversity while keeping the\n> simplicity of the model. One way to do that might be to use the\n> experimental \"proportional\" algorithm from CIVS[2]. As markwash\n> suggested, I think we could run the first election(s) as pure Condorcet\n> but save the (anonymized) ballots and check what the results would have\n> been with the \"proportional\" option enabled. If they seem to still\n> result in natural Condorcet winners but give us additional protection\n> against block voting, we\'d consider enabling that option for future\n> elections.\n\nSounds good.\n\n> Final detail would be how to run the transition from the current TC. We\n> currently have 2 people recently-elected to a one-year term and 13\n> people elected for a six-month term[3]. As a transition, the idea would\n> be to elect in the Fall 2013 election 9 people (5 one-year member and 4\n> six-month members) in the case of a 11-member committee, or 11 people (6\n> one-year member and 5 six-month members) in the case of a 13-member\n> committee. The next election in Spring would then see the normal renewal\n> of 6 (over 11) or 7 (over 13) members.\n\nAgain, sounds good.\n\nCheers,\nMark.\n\n\n\n','<51B0634D.6040302@openstack.org>',NULL),('<1370525915.13290.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 14:38:35',3600,'2013-06-06 13:38:35',NULL,'[openstack-dev] How to handle forking of projects','On Thu, 2013-06-06 at 11:53 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Thu, 2013-06-06 at 10:34 +0200, Matthias Runge wrote:\n> >> Hey,\n> >> I came to this question over the the following review:\n> >> https://review.openstack.org/#/c/31725/\n> >>\n> >> The situation is: Horizon ships a bundled library query-table-sorter,\n> >> which hasn\'t seen a release since ages.\n> >> The proposed commit changes the bundled lib, effectively creating a fork.\n> >>\n> >> Is that allowed/desired, or how should we handle this?\n> > \n> > I agree with you that we should avoid forking a library.\n> \n> We should avoid bundling in the first place... But those one-file .js\n> projects put those good principles to a hard reality test by making it\n> very convenient to copy and very inconvenient to depend on.\n\nRight, agree :)\n\nCheers,\nMark.\n\n\n\n','<51B05C1F.8000608@openstack.org>',NULL),('<1370554564.3446.19.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 16:36:04',-18000,'2013-06-06 21:36:04',NULL,'[openstack-dev] [CI] Problem with logs.openstack.org?','I\'m getting 403 errors from logs.openstack.org while trying to look at\nlogs from changes I\'m reviewing.  Examples include:\n\n * http://logs.openstack.org/29288/14/gate/gate-nova-pep8/28090 (failed)\n * http://logs.openstack.org/29288/14/check/gate-nova-pep8/27940 (old success)\n * http://logs.openstack.org/31402/3/check/gate-nova-pep8/27838 (different patch)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1370581545.1387536.1395844242572.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 10:30:42',-14400,'2014-03-26 14:30:42',NULL,'[openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0','Hi,\nI currently have a patch up for review (https://review.openstack.org/#/c/81373/) to limit psutil be <2.0.0.\n2.0.0 just came out a couple weeks ago, and breaks the API in a major way.  Until we can port our code to the\nlatest version, I suggest we limit the version of psutil to 1.x (currently there\'s a lower bound in the 1.x\nrange, just not an upper bound).\n\nBest Regards,\nSolly Ross\n\n\n','<1454129091.1384795.1395844068356.JavaMail.zimbra@redhat.com>',NULL),('<1370618721.3446.21.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-07 10:25:21',-18000,'2013-06-07 15:25:21',NULL,'[openstack-dev] [Quantum] Unit tests run time','On Fri, 2013-06-07 at 16:55 +0400, Eugene Nikanorov wrote:\n> It\'s not stable in my case.\n> Rebooting VM brought test run time back to 900 sec with tox -e py27\n\nHave you checked how much memory gets used by the test suite?  When I\'ve\nhad test runs take long periods of time, I\'ve discovered that it\'s due\nto heavy swapping, due to memory leaks in whatever test suite I was\nrunning at the time, and I did report a bug on the quantum test suite\nleaking memory like a sieve.  (Though that report was long ago, and I\nthink that specific issue was fixed?)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAJfiwOTvfvfnt88Cmg3NfFgrQHk+SPA3qCz0KvvkCi7KWqdk=g@mail.gmail.com>',NULL),('<1370620942.13290.95.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-07 17:02:22',3600,'2013-06-07 16:02:22',NULL,'[openstack-dev] [OSLO] New Messaging API - Mark are you around?','Hi,\n\nOn Fri, 2013-05-17 at 14:36 -0400, Eric Windisch wrote:\n> Mark: \n> \n> \n> Haven\'t seen you around IRC for a few days. Just making sure you\'re\n> alive?\n\nYou know about timezones, right?\n\n2013-05-17T13:25:18  *** markmc has joined #openstack-dev\n2013-05-17T13:59:00  <dhellmann> markmc: is the oslo team meeting today? the agenda is empty.\n2013-05-17T13:59:19  <markmc> dhellmann, right, no topics proposed, so no meeting :)\n2013-05-17T13:59:28  <dhellmann> cool, thanks :-)\n2013-05-17T13:59:37  *** markmc is now known as markymark\n2013-05-17T17:41:44  *** markymark has quit IRC\n2013-05-17T18:10:05  *** ewindisch has joined #openstack-dev\n\n>  I\'ve been on vacation myself and have only returned a couple days\n> ago.\n> \n> \n> I\'ve been looking at doing a port of the ZeroMQ driver for the new\n> messaging API. I\'m running into some troubles and would like to\n> discuss.\n\nCool.\n\n> One immediate question is what calls IncomingMessage.reply()?\n\nThe executor:\n\nhttps://github.com/markmc/oslo-incubator/blob/4beea4a/openstack/common/messaging/_executors/base.py#L33\n\n>  It also isn\'t clear how the consuming process, upon receiving a\n> message from the Listener.poll() knows to send a reply()? Perhaps this\n> is always done?  That would seem to leave a lot of messages sent over\n> the wire that get ignored or never get consumed?  Perhaps you just\n> haven\'t gotten to this yet in the new API implementation?\n\nThe executor pulls a message from the listener, dispatches it and sends\nback a reply or exception, if there was either.\n\n> There is much yet to do, mostly cleaning up, stripping out old code,\n> polish, and \"making it work again\". However, the new abstraction has\n> already resulted in dropping >10% of the LOC. My branch:\n> https://github.com/ewindisch/oslo-incubator/commit/a7a8921030b70be1cb48674d3df43be00e51ffb9\n\nYeah, you\'re going to need a ZmqIncomingMessage class which knows how to\nsend a reply.\n\nAlso, why are you spawning a greenthread when sending a cast ?\n\nOther than that, looks like a good start.\n\nOne thing I\'m thinking about after seeing this \"real\" driver is that\nwhatever I/O framework you\'re using, you\'ll have one thread/coroutine\nthat\'s a server pulling off messages and dispatching them and other\nthreads/coroutines blocked in call() waiting to pull its reply off the\nqueue. I think that\'s what we\'re doing now with eventlet and the kombu\nand qpid drivers at least, but I\'m not sure yet there aren\'t nasty\nissues implied for other drivers or I/O frameworks.\n\nCheers,\nMark.\n\n\n\n\n','<272CA455F8FC4068A08EE5BB8BA2CFC7@cloudscaling.com>',NULL),('<1370625391.451223861@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-06-07 12:16:31',-18000,'2013-06-07 17:16:31',NULL,'[openstack-community] Additional booth staff and booth\n	presentations/demos welcome for Cloud Expo and HostingCon','\nDearest Community and Marketing,  We could use more help for Cloud Expo on Wed-Thurs, June 12-13 at NYC\'s Javits Convention Center.  All are welcome - free registration info below. \n \nHostingCon is in the Austin Convention Center, expo is open June 18-19.  For this one, you have to already have your own pass.  OpenStack is the official show t-shirt provider - they\'re very Austintatious.\n \nWe\'re soliciting presentations and demos for both booths as well as staffing volunteers.  I\'ll be at both shows and would love to meet you in person!  If you\'ll be there, please visit.\n \nIf you can participate, please sign up at these public, editable GoogleDocs.  There are two tabs on each: booth staff and presentations/demos.  Thank you. \n \nCloud Expo (booth #340):\n[https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDBXMzYwb3ZiT1dGbzV0RFpXLV80ZGc&usp=drive_web#gid=0] https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDBXMzYwb3ZiT1dGbzV0RFpXLV80ZGc&usp=drive_web#gid=0\n \nRegistration for Cloud Expo:\n[https://www.blueskyz.com/v3/Login.aspx?ClientID=19&EventID=70] https://www.blueskyz.com/v3/Login.aspx?ClientID=19&EventID=70\n\nFill out the Attendee Information form\nSelect the VIP Gold Pass Registration Option\n\nEnter the Discount Code: openstackVIPgold\n\nThe price will re-set from $2,000 to $0.\n \nHostingCon (booth #912):\n[https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDJERDVCaUtnRUV3ajc5cEV1RXlMSFE&usp=drive_web#gid=0] https://docs.google.com/spreadsheet/ccc?key=0ArUDleqDPUTAdDJERDVCaUtnRUV3ajc5cEV1RXlMSFE\n \nMust already be registered for HostingCon.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130607/42c9b91e/attachment.html>\n\n',NULL,NULL),('<1370893045.20775.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 20:37:25',3600,'2013-06-10 19:37:25',NULL,'[openstack-dev] Replacement for setuptools_git in pbr','Hey\n\nOn Mon, 2013-06-10 at 15:04 -0400, Monty Taylor wrote:\n> Hey all!\n> \n> I know that setuptools_git caused some of you a giant headache. I\'ve got\n> a patch submitted for pbr that replaces it with something that operates\n> in a smarter manner, and I _think_ addresses the concerns that have been\n> expressed.\n> \n> I\'d really appreciate if the folks who had concerns would look at it and\n> poke at it and tell me where it\'s going to break for them.\n> \n> https://review.openstack.org/#/c/30522/\n\nI went back through the archives and I\'ve cc-ed those who were most\ninterested in this last time around:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2012-December/thread.html#3656\n\nCheers,\nMark.\n\n\n\n','<51B6233A.4060904@inaugust.com>',NULL),('<1370896362.20775.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 21:32:42',3600,'2013-06-10 20:32:42',NULL,'[openstack-dev] Automation around binary dependencies','Hi\n\nOn Mon, 2013-06-10 at 20:50 +1200, Robert Collins wrote:\n> We have a hole in our otherwise pretty robust dependency management :\n> binary packages. At the moment, the most reliable way to get a dev\n> environment working is to either copy from a wiki page like\n> https://wiki.openstack.org/wiki/DependsOnUbuntu, or to run devstack\n> once :).\n> \n> This is something I\'ve said before we should automate... I was\n> starting to look at tempest in the weekend, and yet again running up\n> the curve of \'what packages are needed for this specific project\',\n> when I hit my tolerance threshold and thus, rage-fueled-code.\n> \n> https://github.com/rbtcollins/bindep is a draft project which would\n> allow capturing in machine readable form the dependencies needed for\n> our CI environments, for developers, and for binary deployment. It\n> *isn\'t* a replacement or wrapper for tools like dpkg and rpm : there\n> are good tools for that already. What it would let us do is record\n> within each project the dependencies the project actually has for each\n> use case : no more patching devstack to educate it about new binary\n> dependencies.\n\nHaving metadata in each project describing its non-python requirements\nis definitely a good thing. As is having some way of turning that\nmetadata into a \"check these deps are satisfied\" or \"install these deps\"\ndisto-specific command.\n\nI think it\'s great you\'ve kicked this off - it\'s a great starting point\nfor finding a workable solution. I\'m actually kinda surprised we never\nhad e.g. tools/install-deps.sh type scripts long ago.\n\nThe first thing I notice is that the list of requirements is a list of\ndebian packages and versions. Obviously, anyone who doesn\'t use a debian\ndistro wouldn\'t like to have to cater first for debian and then for\ntheir preferred distro when adding a dep. I think the project has gone\nbeyond having a single first class distro, so I think this needs\nimproving.\n\n(I\'ve an obvious bias here - but the concern honestly does go beyond\njust me)\n\nWhat might work is if we built in a dependence on the\nopenstack/requirements repo. Like for python deps, we\'d use that repo to\ndescribe the unified set of dependencies for all of openstack and\nindividual projects would specify a subset of those dependencies.\n\nWe could also use openstack/requirements to maintain a mapping of distro\nagnostic requirement name/version to distro specific package\nname/version. Maybe bindep would look use the distro mapping table to\napply other-requirements.txt or maybe we\'d have a utility to copy the\nappropriate parts of the mapping table into other-requirements.txt.\n\nBikeshed - other-requirements could be system-requirements.txt or\ndistro-requirements.txt ?\n\nAnyway, just some ideas ...\n\n> I think this could live very happily as an oslo component, like pbr\n> does. It provides a small CLI, and a Python library which can be used\n> from things like pbr or CI scripts, if they want to layer on it.\n\nIt could come under oslo, but I\'d like to see it gain a good deal of\ntraction first. Obviously adding other-requirements.txt to projects\nwould be a good first step. Using it in devstack would be next?\n\nBasically, I think this could move to stackforge and we could see how it\nevolves before moving it to oslo.\n\nWhy wait?\n\nWell, if we include it in oslo, it will imply some interface stability\nguarantees that will make it harder to evolve the idea.\n\nAlso, oslo-core is already finding the review workload pretty hard to\nkeep on top of ... so I\'m reluctant to pull in another project which is\nvery new and isn\'t in use anywhere yet. We have lots of work with our\ncore focus on the project\'s copy-and-paste technical debt.\n\nSo, again - I\'m up for including it oslo at some point, but let\'s get it\nin use in a bunch of places first.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ09=j+E0iz4daQ_kJusWyTwyyMPUqRxFpaUR9m-sy-YsA@mail.gmail.com>',NULL),('<1370933975.20775.38.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-06-11 07:59:35',3600,'2013-06-11 06:59:35',NULL,'[openstack-tc] Official Python 3 Policy','On Mon, 2013-06-10 at 20:32 -0700, Joe Gordon wrote:\n> Hi TC,\n> \n> As many of you have probably seen, there has been a community effort to\n> begin the slow process to making OpenStack python 3 compatible. There is\n> even a weekly meeting discussion it (\n> http://eavesdrop.openstack.org/meetings/python3/2013/)\n> \n> As this is inherently a massive cross project effort, I was hoping the TC\n> would comment on the python 3 efforts.\n\nAfter looking the python 3.3 based Tulip project, I\'m even more keen for\nus to get onto Python3:\n\n  http://blogs.gnome.org/markmc/2013/06/04/async-io-and-python/\n\n> * What versions of python we want to compatible with\n\nLooking at e.g. Fedora 19 and \"Red Hat Software Collections 1.0 Beta\"\nI\'d say 3.3. But maybe there are obvious 3.2 based distros we want to\nsupport. I haven\'t looked further.\n\n> * Do we *want* all projects to by python 3 compatible or should we focus\n> our efforts on oslo and client libraries etc?\n\nDefinitely want All eventually, but we need to focus on baby steps.\n\n> * Do we want to begin gating on some python 3 compatibility?\n> https://github.com/openstack-dev/hacking/commit/e0ab03637da65bfc6035091989b62fc70ae363a5\n\nThat change looks like a very good idea.\n\nMore generally, I\'d say that when each individual project gains python 3\ncompat we should add a gating test to make sure it doesn\'t regress.\n\nCheers,\nMark.\n\n\n\n','<CAHXdxOd_tK_j19wCGoWH7nAQJGNatiyL7pvRVYN2-P8WQSV3HQ@mail.gmail.com>',NULL),('<1370944568.20775.53.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-11 10:56:08',3600,'2013-06-11 09:56:08',NULL,'[openstack-dev] Urgent PBR code reviews','Hi Julien,\n\nOn Tue, 2013-06-11 at 10:58 +0200, Julien Danjou wrote:\n> Hi there,\n> \n> I\'d like to emphasize that Ceilometer CI is failing for now 5 days, and\n> that we can\'t get anything merged, due to a pbr issue. Monty has fixed\n> this a few day ago, but it would be really great if we could speed up\n> things by reviewing, approving his work and get a new release:\n> \n>      https://review.openstack.org/#/q/status:open+project:openstack-dev/pbr+branch:master+topic:27519,n,z\n\nI don\'t think the issue here is \"people aren\'t reviewing fast enough\",\nfrankly. The patches are getting a pretty decent amount of attention\nfrom reviewers.\n\nThere are a bunch of issues we need to think about here:\n\n  - I don\'t see a bug report for this:\n\n      https://bugs.launchpad.net/pbr\n      https://bugs.launchpad.net/ceilometer\n\n    I\'ve just dug about and found e.g.:\n\n      http://logs.openstack.org/32108/1/check/gate-ceilometer-python27/2657/console.html.gz\n\n      pkg_resources.VersionConflict: (requests 1.2.3 (/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/lib/python2.7/site-packages), Requirement.parse(\'requests>=1.1,<1.2.1\'))\n\n    Is that the issue?\n\n    The details should be in a Critical bug.\n\n  - It\'s not clear to me what change in pbr caused the problem. Was it \n    the use of easy_install ?\n\n      https://review.openstack.org/31778\n\n  - Whatever the patch that caused the issue was, why haven\'t we \n    reverted it?\n\n  - If we can\'t revert it, why haven\'t we just removed the broken pbr \n    version from pypi?\n\n  - Which of Monty\'s 9 patches fixes the issue?\n\n      https://review.openstack.org/#/q/project:openstack-dev/pbr+status:open+owner:mordred,n,z\n\n    Does it depend on patches which aren\'t absolutely required to fix \n    this critical issue?\n\n  - We now have this ceilometer issue, an issue with quantumclient:\n\n      https://bugs.launchpad.net/pbr/+bug/1187452\n\n    and a oslo.config related issue:\n\n      https://review.openstack.org/30938\n\n    all waiting on a fixed pbr release.\n\n\nI\'m going to review the latest updates to the patches, but at a time\nlike this we actually need the minimum possible churn and some clear\nthinking ... not super fast reviewing of a big stack of changes. What\'s\nthe quickest and least risky thing we can do to get Ceilometer\nunblocked?\n\nCheers,\nMark.\n\n\n\n','<871u89nhvt.fsf@dex.adm.naquadah.org>',NULL),('<1370946870.20775.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-11 11:34:30',3600,'2013-06-11 10:34:30',NULL,'[openstack-dev] Urgent PBR code reviews','On Tue, 2013-06-11 at 12:05 +0200, Julien Danjou wrote:\n> On Tue, Jun 11 2013, Mark McLoughlin wrote:\n> \n> Hi Mark,\n> \n> > I don\'t think the issue here is \"people aren\'t reviewing fast enough\",\n> > frankly. The patches are getting a pretty decent amount of attention\n> > from reviewers.\n> \n> Hehe, then I\'m just making sure the amount of attention doesn\'t\n> decrease. :-)\n> \n> >   - I don\'t see a bug report for this:\n> >\n> >       https://bugs.launchpad.net/pbr\n> >       https://bugs.launchpad.net/ceilometer\n> >\n> >     I\'ve just dug about and found e.g.:\n> >\n> >       http://logs.openstack.org/32108/1/check/gate-ceilometer-python27/2657/console.html.gz\n> >\n> >       pkg_resources.VersionConflict: (requests 1.2.3 (/home/jenkins/workspace/gate-ceilometer-python27/.tox/py27/lib/python2.7/site-packages), Requirement.parse(\'requests>=1.1,<1.2.1\'))\n> >\n> >     Is that the issue?\n> \n> No, this is easy to fix, and while trying to fix it at:\n> \n>     https://review.openstack.org/#/c/32124/\n> \n> I\'ve ended with this problem first:\n> \n>   http://logs.openstack.org/32124/1/check/gate-ceilometer-python26/2672/console.html.gz\n> \n> Which I tried to solve by disabling our nova test\n\nOk, that does look like an issue with the easy_install change in pbr.\nI\'ve filed a bug with all the details I know of:\n\n  https://bugs.launchpad.net/pbr/+bug/1189848\n\n> , and then got into this problem:\n> \n>   http://logs.openstack.org/32124/4/check/gate-ceilometer-docs/1550/console.html.gz\n> \n> Which I\'ve no damn idea where it comes from.\n\nLovely.\n\nHowever, I think we need to fix pbr so that you don\'t have to disable\nthe nova tests.\n\n> >   - It\'s not clear to me what change in pbr caused the problem. Was it \n> >     the use of easy_install ?\n> >\n> >       https://review.openstack.org/31778\n> \n> I couldn\'t tell, Monty might have a better idea. I already spent hours\n> trying to guess where these errors came from, and stopped right after\n> Monty told me it was pbr and it\'ll fix it. :)\n\nOk, let\'s learn a lesson though - we need to make sure stuff gets\nrecorded in launchpad or commit messages.\n\nIRC conversations are all very well, but anyone looking at the reviews\n(or even looking at the git history in future) miss all that valuable\ncontext.\n\n> [? not answering the other questions of Mark since I don\'t have the\n>   answers :-) ?]\n> \n> > I\'m going to review the latest updates to the patches, but at a time\n> > like this we actually need the minimum possible churn and some clear\n> > thinking ... not super fast reviewing of a big stack of changes. What\'s\n> > the quickest and least risky thing we can do to get Ceilometer\n> > unblocked?\n> \n> I\'ll be happy with any solution going back or forward, FWIW.\n\nAt this point, I\'d suggest we delete the newer versions from pypi and\nroll back to 0.5.11 ... if that\'s possible.\n\nIdeally, we\'d have a way of testing that pbr changes don\'t regress stuff\nbefore we push the release to pypi. My approach with oslo.config is to\ntag pre-release versions and reference them directly on\ntarballs.openstack.org, but that\'s probably challenging to do with pbr.\n\nI\'ve suggested before that we should push pre-release versions of\noslo.config to our pypi mirror before promoting them to pypi.python.org\nbut we\'d also need to ensure that all OpenStack developers use that\nmirror when running devstack or unit tests locally.\n\nCheers,\nMark.\n\n\n\n','<87wqq1m081.fsf@dex.adm.naquadah.org>',NULL),('<1370955284.20775.65.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-11 13:54:44',3600,'2013-06-11 12:54:44',NULL,'[openstack-dev] Urgent PBR code reviews','On Tue, 2013-06-11 at 08:42 -0400, David Shrewsbury wrote:\n> On Jun 11, 2013, at 6:34 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > At this point, I\'d suggest we delete the newer versions from pypi and\n> > roll back to 0.5.11 ... if that\'s possible.\n> \n> That\'s not really ideal since earlier versions have a bug (that 0.5.12 was\n> attempting to fix) where required python packages were not being installed.\n> You wouldn\'t notice it unless you were trying to install from a fresh Python\n> environment.\n\nYes, we\'d have to do a follow up release with a non-regression-causing\nfix for that.\n\nhttps://review.openstack.org/32124 is approved, so this is all academic\nat this point. I hope.\n\nPoint is that if we find we\'ve introduced a serious regression, we\nshould revert the regression-causing change and approach the issue again\nwithout the mistakes-causing pressure of \"OMG, everything\'s broken, fix\nit quick\".\n\nCheers,\nMark.\n\n\n\n','<3B8B5785-9960-438A-BEEF-1C678D2F86EA@gmail.com>',NULL),('<1371035562.20775.77.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-06-12 12:12:42',3600,'2013-06-12 11:12:42',NULL,'[openstack-tc] Special motion: TC membership evolution to\n All-directly-elected model','On Wed, 2013-06-12 at 13:10 +0200, Thierry Carrez wrote:\n> Hi!\n> \n> I drafted a formal special motion based on the outcome of the thread on\n> openstack-dev:\n> \n> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010255.html\n> \n> We should vote on that at the next meeting. Since it\'s a special motion,\n> it will need 10 \"yes\" in order to pass. So if you can\'t come to that\n> meeting, please designate a trusted proxy to replace you :)\n> \n> Please follow-up on the -dev thread if you have any comment.\n\n(meta comment only :)\n\nAs usual, very nice work on the drafting. Thanks Thierry\n\nCheers,\nMark.\n\n\n\n','<51B85713.9060903@openstack.org>',NULL),('<1371039266.20775.79.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 13:14:26',3600,'2013-06-12 12:14:26',NULL,'[openstack-dev] Apache header check in hacking 0.6','On Wed, 2013-06-12 at 07:52 -0400, Sean Dague wrote:\n> The current debate is whether or not this is defined policy. My feeling \n> was the results of the TC discussion meant that this was defined policy. \n> 95%+ of code files currently do this, it ensures that there is no \n> ambiguity on the fact that these files are under this license. Various \n> interpretations of copyright might say they are not required, but as we \n> have, by convention, already basically implemented this policy, I\'d like \n> to just finish the enforcement in hacking so it\'s yet another thing we \n> don\'t need to manually review for. \n\nAgree, it\'s pretty clearly our de-facto policy that we include a license\nheader in python files.\n\nCheers,\nMark.\n\n\n\n','<51B86108.30107@dague.net>',NULL),('<1371058879-sup-9677@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 11:08:05',-25200,'2013-06-12 18:08:05',NULL,'[openstack-dev] Expired tokens in Keystone','Excerpts from Craig E. Ward\'s message of 2013-06-12 09:54:21 -0700:\n> I am working with a Folsom installation of OpenStack. The Keystone database \n> (mysql) gets very large. The token table has millions of rows of expired \n> tokens. Is there a reason not to delete these from the table?\n> \n\nAs Dolph mentions, Havana has a command for flushing tokens. However, if\nyou use it on your million row table, you risk affecting token creation:\n\nhttps://bugs.launchpad.net/keystone/+bug/1188378\n\nBasically to maintain transaction isolation, InnoDB must lock the gaps\nbetween rows it has marked for deletion while it does a delete. Also\ndelete will end up reading pages into the buffer pool, so if you are\ntight on the size of that you will waste cache pages.\n\nhttp://www.mysqlperformanceblog.com/2012/03/27/innodbs-gap-locks/\n\nI\'m working on a solution now, though it will likely have to have a\nmysql specific method, and then a more naive method for other SQL engines.\n\nAnother thing you can do is use percona toolkit\'s pt-archiver command:\n\npt-archiver --source h=dbhost,D=keystone,t=token --purge --where \"expires < NOW()\" --primary-key-only --sleep-coef 1.0 --txn-size 500\n\nThis will delete the rows in a more friendly way. Read more here:\n\nhttp://www.percona.com/doc/percona-toolkit/2.1/pt-archiver.html\n\nI have been using this to keep a live table under control while I work\non the fix for the flush command.\n\n\n','<51B8A7BD.1020003@ISI.EDU>',NULL),('<1371100347-sup-4818@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 22:17:25',-25200,'2013-06-13 05:17:25',NULL,'[openstack-dev] headsup - tripleo heat templates now on\n	stackforge','Excerpts from Steven Hardy\'s message of 2013-06-12 06:14:58 -0700:\n> On Wed, Jun 12, 2013 at 03:22:00PM +1200, Robert Collins wrote:\n> > https://github.com/stackforge/tripleo-heat-templates has the templates\n> > for bringing up OpenStack w/TripleO.\n> \n> Awesome, very interesting, thanks for sharing! :)\n> \n> Can you provide, or direct me to, any description of your usage of the\n> Metadata section for instances, e.g stuff like:\n> \n\nI\'m working on some docs to put in the repo now that will explain things.\n\n> OpenStack::Role: stateful\n> OpenStack::ImageBuilder::Elements: [ heat-api, heat-engine ]\n> \n> I know you have some alternate in-instance agents which replace\n> heat-cfntools, but I\'d really like more detail to fully understand how it\n> all fits together.  In particular, I\'m intrigued by the stateful role?\n> \n\nOur replacements for a lot of what cfn-init does are os-config-applier\n(soon to be renamed os-apply-config) and os-refresh-config. They are\nlimited in scope intentionally, and rely on cfn-hup to read new Metadata.\nThey are also designed to have the elements drive most of what they do\nas software that is delivered along with the image.\n\nOpenStack::Role was something I added to drive a PoC which I wrote\nthere in the same repo called, unassumingly, \'merge.py\'. It merges any\ninstances which have the same role into one. This was my answer for how\nto co-locate services. It has a lot of drawbacks and I\'m not sure if it\nis worth pursuing.\n\nThe ImageBuilder::Elements part drives another PoC script I have which\nbuilds the image, uploads it to glance, and then deploys the stack. I\nam also hoping that these element names can help us validate the rest\nof the Metadata section.\n\n\n','<20130612131457.GB3635@t430slt.redhat.com>',NULL),('<1371103793.26914.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 07:09:53',3600,'2013-06-13 06:09:53',NULL,'[openstack-dev] [oslo] Option registration convention?','On Thu, 2013-06-13 at 13:35 +0800, Zhongyue Luo wrote:\n> Hi, all\n> \n> \n> I\'m facing problems with sample config file generation on some\n> projects.\n> \n> \n> The doc web team is working on finding a way to get all options for\n> all projects (or as needed) to create more up-to-date and accurate doc\n> config tables.  They are planning to make the process as generic as\n> possible to work with the source for any project so as to generate all\n> config options, so that we can then have the options list converted to\n> docbook format and update the docs site.\n> \n> \n> Currently, listing of all register options can be done in Nova and\n> Cinder using the tools below\n> https://github.com/openstack/nova/blob/master/tools/conf/generate_sample.sh\n> \n> https://github.com/openstack/cinder/blob/master/tools/conf/generate_sample.sh\n> \n> \n> \n> So our plan is to move the \"generate_sample.sh\" to oslo with an\n> additional docbook format ouput module which will enable:\n> ./generate_sample.sh /opt/stack/nova\n> ./generate_sample.sh /opt/stack/quantum\n> \n> ./generate_sample.sh /opt/stack/keystone\n> \n> \n> \n> The module which traverses the target file handed by\n> \"generate_sample.sh\" is\n> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/config/generator.py\n> \n> \n> \n> The \"generate_sample.sh\" looks for files containing \"Opt(\" which means\n> that file has a high chance of defining and registering an option\n> inside. For instance,\n> \n> \n> resource_tracker_opts = [\n> \n> \n>     cfg.IntOpt(\'reserved_host_disk_mb\', default=0,\n> \n> \n>                help=\'Amount of disk in MB to reserve for the host\'),\n> \n> \n>     cfg.IntOpt(\'reserved_host_memory_mb\', default=512,\n> \n> \n>                help=\'Amount of memory in MB to reserve for the host\'),\n> \n> \n>     cfg.StrOpt(\'compute_stats_class\',\n> \n> \n>                default=\'nova.compute.stats.Stats\',\n> \n> \n>                help=\'Class that will manage stats for the local\n> compute host\')\n> \n> \n> ]\n> \n> \n> CONF = cfg.CONF\n> \n> \n> CONF.register_opts(resource_tracker_opts)\n> \n> \n> \n> \n> So if a file is passed to \"generator.py\", a module object is created\n> by importing the target file and all attributes in that module\n> object which are oslo.config.cfg.Opt sub-classes or a list of\n> oslo.config.cfg.Opt sub-classes are printed out in the sample config\n> file.\n> \n> \n> Therefore the assumption was that an option will be defined and\n> registered in the same module.\n> \n> \n> However, some projects have options defined and registered on\n> different modules. For instance,\n> https://github.com/openstack/keystone/blob/master/keystone/common/config.py\n> \n> \n> Here, the options are defined but instead of directly registering\n> them, it provides a function which registers the options. And the\n> actual registration happens in,\n> https://github.com/openstack/keystone/blob/master/keystone/config.py#L24\n> \n> \n> \n> Another pattern which is hard to detect the registered options is,\n> https://github.com/openstack/glance/blob/master/glance/cmd/scrubber.py#L54\n> \n> \n> \n> This line is not only registering a option inside a function but the\n> option is also declared inside cfg.register_opt() which is makes it\n> even harder to detect the option.\n> \n> \n> How can we solve this problem of not being able to detect options?\n\nWell, first thing I\'d say is that I wouldn\'t worry about handling every\npossible way of declaring cfg config options.\n\nWe can have a convention for how to register config options and a tool\nthat supports projects using that convention.\n\nI think we have that now, but keystone chooses not to follow that\nconvention ... e.g.\n\n  https://review.openstack.org/4547\n\nI\'m pretty sure part of my argument for those keystone changes was that\nthe sample config file generator wouldn\'t work with keystone as it\nstands now.\n\nSo, IMHO - any project which doesn\'t follow the convention should just\ncome up with its own custom approach to automating config documentation.\n\n\n>  I have two suggestions.\n> \n> \n> First method is to change how generate.py works.\n> Rake all modules in project which imports oslo.config.cfg and create a\n> module object of it to inspect the cfg.CONF object inside.\n> We can cache all the options which were already seen and print out\n> newly discovered options.\n\nOk, so we\'d actually look in cfg.CONF for registered options rather than\njust looking at *declared* options.\n\nI don\'t think we should rely on everything being visible through\ncfg.CONF. There can be good reasons not to use the global object. Also,\nthe cfgfilter thing in oslo-incubator would mean that not all options\nare visible through cfg.CONF.\n\n> The downside of this solution is that we have to call a private\n> function in ConfigOpts called _all_opt_infos() to look at all options\n> registered.\n> https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L1822\n> \n> We would have to create a public api version of it.\n\nI think it would be useful to have an API which would return the Opt\nobject associated with a given config option name:\n\n  def lookup(self, name, group=None):\n      return self._get_opt_info(opt_name, group)[\'opt\']\n\n\nand then we can just do:\n\n  def print_help(conf, group=None):\n      d = conf if group is None else conf[group]\n      for key in d.keys():\n          if isinstance(conf.GroupAttr, d[key]):\n              print_help(conf, group=key)\n          else:\n              print key, conf.lookup(key, group).help\n\n> The second option is to make it a convention that all options should\n> be declared in global view and also registered in the same module\n> where they were defined.\n\nHmm, why would that help?\n\nDoesn\'t the current tool just require that you declare options at\ntop-level module scope i.e.\n\n  my_opt = cfg.StrOpt(...)\n  my_opts = [cfg.StrOpt(...), cfg.IntOpt(...)\n\nbut the problem with keystone is it is dynamically creating the opt\nobjects at runtime.\n\n> However it would be difficult to write a hacking.py routine to check\n> this and there will be significant amount of code we have to change.\n> \n> \n> So some questions,\n> 1) Is it worth documenting all the options in a project?\n\nYes.\n\n> 2) Should there be a convention of declaring and registering options?\n\nThere is a convention, but keystone doesn\'t follow it.\n\nAlso, I think the important thing for the sample generator should be the\nconvention for declaring options, not registering options.\n\n>  Or just have generate.py handle things on its own.\n> 3) Any objections of adding a public version of _all_opt_infos()?\n\nNo objection to something like the lookup() above, but we already have a\nway of iterating over registered options and groups.\n\nCheers,\nMark.\n\n\n\n\n','<CAFf0h6fT59iAAZZatEsO11v9iV0C8axD+_RWE=JEcWLnxdMNdg@mail.gmail.com>',NULL),('<1371111793.26914.25.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 09:23:13',3600,'2013-06-13 08:23:13',NULL,'[openstack-dev] [oslo] Option registration convention?','On Thu, 2013-06-13 at 15:01 +0800, Zhongyue Luo wrote:\n> \n> \n> \n> On Thu, Jun 13, 2013 at 2:09 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Thu, 2013-06-13 at 13:35 +0800, Zhongyue Luo wrote:\n\n>         \n>         > The downside of this solution is that we have to call a private\n>         > function in ConfigOpts called _all_opt_infos() to look at all options\n>         > registered.\n>         > https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L1822\n>         >\n>         > We would have to create a public api version of it.\n>         \n>         \n>         I think it would be useful to have an API which would return the Opt\n>         object associated with a given config option name:\n>         \n>           def lookup(self, name, group=None):\n>               return self._get_opt_info(opt_name, group)[\'opt\']\n>         \n>         \n>         and then we can just do:\n>         \n>           def print_help(conf, group=None):\n>               d = conf if group is None else conf[group]\n>               for key in d.keys():\n>                   if isinstance(conf.GroupAttr, d[key]):\n>                       print_help(conf, group=key)\n>                   else:\n>                       print key, conf.lookup(key, group).help\n> \n> \n> But don\'t we already have the Opt object retrieved from the module object?\n> I\'m not sure I understand this part.\n\nYou asked about an API for introspecting a ConfigOpts object and this is\nmy suggestion for that API.\n\nBut, yes - if we just probe module-level option declarations, rather\nthan introspect cfg.CONF then we don\'t need this API.\n\n>         >  Or just have generate.py handle things on its own.\n>         > 3) Any objections of adding a public version of _all_opt_infos()?\n>         \n>         \n>         No objection to something like the lookup() above, but we already have a\n>         way of iterating over registered options and groups.\n> \n> \n> cfg.CONF.items() is what you\'re referring to, right?\n\nWell, more like conf.keys() ... but yes, that\'s what I mean.\n\nCheers,\nMark.\n\n\n\n\n','<CAFf0h6fxsTpiKu6Pi0jqvMLcmzfZG9uVbsFwWJRuv2WcLnhvjA@mail.gmail.com>',NULL),('<1371118382.26914.27.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 11:13:02',3600,'2013-06-13 10:13:02',NULL,'[openstack-dev] [Heat] Autoscaling and the Rackspace Otter\n project','On Thu, 2013-06-13 at 10:45 +0100, Steven Hardy wrote:\n> On Wed, Jun 12, 2013 at 05:06:31PM -0500, Christopher Armstrong wrote:\n\n> > I believe the consensus is that the work on the new HOT format and\n> > underlying design changes is a prerequisite for the autoscaling work that\n> > Thomas and I are to do, so we\'ll definitely help with that. I\'ll let\n> > someone with a better understanding chime in about that.\n> \n> As others have mentioned, I\'m not clear on this coupling between template\n> and Autoscaling, it seems like this superset of AS functionality will just\n> require a new resource/resources to provide the interface, and as\n> previously discussed, probably an API which allows AS functionality to be\n> consumed without directly creating a Heat template (we may do that behind\n> the scenes though..)\n\nIs there any reason for the non-template based autoscaling API to be\npart of Heat at all? Why would it not be a separate standalone\nautoscaling service?\n\nHeat exposing any non-template based API seems odd to me\n\nCheers,\nMark.\n\n\n\n','<20130613094513.GB25436@t430slt.redhat.com>',NULL),('<1371119262.26914.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 11:27:42',3600,'2013-06-13 10:27:42',NULL,'[openstack-dev] DB migrations CI [was [Fwd: Re:\n [Openstack-operators] Slow db migration in havana]]','Hey Michael,\n\nJust forwarding this to openstack-dev since I had to go digging for\ndetails when I saw you mention it on twitter. Really nice work!\n\nFull thread here:\n\nhttp://lists.openstack.org/pipermail/openstack-operators/2013-June/thread.html#3133\n\nCheers,\nMark.\n\n-------- Forwarded Message --------\n> From: Michael Still <mikal at stillhq.com>\n> To: Nikola ?ipanov <ndipanov at redhat.com>\n> Cc: openstack-operators at lists.openstack.org\n> <openstack-operators at lists.openstack.org>\n> Subject: Re: [Openstack-operators] Slow db migration in havana\n> Date: Wed, 12 Jun 2013 18:31:06 +1000\n> \n> On Wed, Jun 12, 2013 at 6:32 PM, Nikola ?ipanov <ndipanov at redhat.com> wrote:\n> > On 12/06/13 00:11, Michael Still wrote:\n> \n> >> Perhaps tweaking this migration is ok as long as its functionally\n> >> identical -- early deployers just suck up some pain, and later\n> >> deployments run a bit faster. Is that possible?\n> >\n> > I think this is the best option - I will not change the migration\n> > functionally - just tweak it\'s performance (hopefully). I will be\n> > posting a patch later today (in CET tz) so you can run it on your\n> > dataset and see if there are any significant improvements.\n> >\n> > I would definitely prefer this over reverting/removing the migration,\n> > provided we can make good (or any) performance gains.\n> \n> Agreed. For reference, any patchset proposed with a change to a file\n> in nova/db/sqlalchemy/migrate_repo/versions will get run through my\n> tester automatically. Results are posted to\n> http://openstack.stillhq.com/ci/\n> \n> The eventual plan is to have this code comment on reviews like\n> smokestack or jenkins, but the code is very new so I want to make sure\n> its right first.\n> \n> However, restating a migration in a patchset probably wont work with\n> my test script, as master is applied first. That\'s something I should\n> probably fix in my tester. I\'ll take a look at that soon.\n> \n> Cheers,\n> Michael\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n',NULL,NULL),('<1371121680.26914.36.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 12:08:00',3600,'2013-06-13 11:08:00',NULL,'[openstack-dev] [Heat] Autoscaling and the Rackspace Otter\n project','On Thu, 2013-06-13 at 11:56 +0100, Steven Hardy wrote:\n> On Thu, Jun 13, 2013 at 11:13:02AM +0100, Mark McLoughlin wrote:\n> > On Thu, 2013-06-13 at 10:45 +0100, Steven Hardy wrote:\n> > > On Wed, Jun 12, 2013 at 05:06:31PM -0500, Christopher Armstrong wrote:\n> > \n> > > > I believe the consensus is that the work on the new HOT format and\n> > > > underlying design changes is a prerequisite for the autoscaling work that\n> > > > Thomas and I are to do, so we\'ll definitely help with that. I\'ll let\n> > > > someone with a better understanding chime in about that.\n> > > \n> > > As others have mentioned, I\'m not clear on this coupling between template\n> > > and Autoscaling, it seems like this superset of AS functionality will just\n> > > require a new resource/resources to provide the interface, and as\n> > > previously discussed, probably an API which allows AS functionality to be\n> > > consumed without directly creating a Heat template (we may do that behind\n> > > the scenes though..)\n> > \n> > Is there any reason for the non-template based autoscaling API to be\n> > part of Heat at all? Why would it not be a separate standalone\n> > autoscaling service?\n> \n> Long term, probably not, short term yes, because the heat-engine provides\n> the actual AS logic behind the API, and it\'s not yet abtracted in a way\n> which can easily be separated.\n> \n> The potential roadmap we discussed during sessions at summit was something\n> like:\n> \n> 1. Add an AS API to heat, to provide more granular control of AS\n> functionality (and access to features not supported by our current CFN\n> resource abstractions)\n> \n> 2. Allow AS API to provide AS functionality without specifying a heat\n> template, e.g by passing a list of Instance uuids (we\'d probably initially\n> create a heat template internally to do this)\n> \n> 3. Work on separating out the AS logic such that it is consumable without\n> the other heat core services (main heat API and heat-engine)\n> \n> 4. Split off into a new incubated standalone AS project\n> \n> \n> This is essentially the roadmap I proposed back in May, which nobody\n> objected to:\n> \n> http://lists.openstack.org/pipermail/openstack-dev/2013-May/008349.html\n> \n> Of course the alternative is to start a separate Autoscaling standalone\n> project from scratch now, but IMHO the incremental add-features then split\n> approach results in better collaboration and less duplicated effort\n> (considering we already have a working Autoscaling solution, which is part\n> of Openstack, in Heat)\n> \n> The other thing worth mentioning is that there\'s work happening right now\n> to integrate with the new ceilometer alarms functionality - when this is\n> done I expect autoscaling to be even simpler than it is now, basically\n> alarms in ceilometer will trigger orchestration actions in Heat, where we\n> just provide the orchestration/workflow of the scale up/down\n\nYep, I love the dependency diagram of the blueprints:\n\nhttps://blueprints.launchpad.net/ceilometer/+spec/alarming\n\nExciting stuff!\n\n> I think it\'s too early to say for sure if a separate project providing\n> Autoscaling is justified - my current feeling is that when integration with\n> ceilometer is complete it probably won\'t be but we\'ll have to get that work\n> done then evaluate.\n\nOk. For me, I just can\'t get my head around the idea that heat (the\nproject, as opposed to the heat api service) would be responsible for\nanything that isn\'t specific to templates/stacks. Autoscaling is\ndefinitely something I could imagine people caring about even if they\ndon\'t care about the template/stack orchestration domain.\n\nOr another way of thinking about it is if autoscaling was a standalone\nservice provided by the heat project, anyone running that service would\nhave to look very carefully at any heat security advisories to check\nwhether it applies to the autoscaling service.\n\nBut I\'m fine with the \"let\'s build it as a standalone service in Heat\nand then see if it makes sense to split it out\" approach.\n\nCheers,\nMark.\n\n\n\n','<20130613105633.GC25436@t430slt.redhat.com>',NULL),('<1371137094.3446.85.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 10:24:54',-18000,'2013-06-13 15:24:54',NULL,'[openstack-dev] [oslo] Option registration convention?','On Thu, 2013-06-13 at 13:35 +0800, Zhongyue Luo wrote:\n> First method is to change how generate.py works. Rake all modules in\n> project which imports oslo.config.cfg and create a module object of it\n> to inspect the cfg.CONF object inside. We can cache all the options\n> which were already seen and print out newly discovered options. The\n> downside of this solution is that we have to call a private function\n> in ConfigOpts called _all_opt_infos() to look at all options\n> registered.\n> https://github.com/openstack/oslo.config/blob/master/oslo/config/cfg.py#L1822\n> \n> We would have to create a public api version of it.\n> \n> \n> \n> The second option is to make it a convention that all options should\n> be declared in global view and also registered in the same module\n> where they were defined. However it would be difficult to write a\n> hacking.py routine to check this and there will be significant amount\n> of code we have to change. \n\nA third option is to create a decorator that sets an attribute on these\nfunctions that install config options; then, you just look for functions\nwith that attribute set and make sure they get called.  Then just go\nthrough all the projects and make sure that decorator is set up on all\nsuch functions.  That should require minimal code changes across the\nOpenStack projects while still giving you what you need to auto-generate\nsample configurations and documentation?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAFf0h6fT59iAAZZatEsO11v9iV0C8axD+_RWE=JEcWLnxdMNdg@mail.gmail.com>',NULL),('<1371160220.3446.101.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 16:50:20',-18000,'2013-06-13 21:50:20',NULL,'[openstack-dev] Cells design issue','At present, all the information that allows cells to communicate to each\nother?including the Rabbit username and password?is stored in the\ndatabase, in clear text; while not really a security issue (if someone\ncan read your database, you\'re already on quicksand, security wise),\nthis is somewhat undesirable.  I would like to try to address this\nissue, but I can really only come up with two basic approaches, both of\nwhich will cause some migration issues, so I\'m hoping to kick off a\ndiscussion as to which will be the more acceptable solution.\n\nThe first potential solution is to simply encrypt the password in the\ndatabase.  (Actually, I intend to first merge all of the RPC information\ninto a single database field, then encrypt that; that will make it\neasier to allow for alternate communication mechanisms in the future.)\nThe problem with this approach is the key management problem: we either\nhave to encrypt the data during the migration, or provide a mechanism\nwhereby the data may be lazily encrypted at runtime; and we must also\nallow for rekeying later on.\n\nThe second potential solution is to drop the cells table from the\ndatabase and place all the data regarding cells (including the\nconnection information) into a configuration file.  (Not the master\nconfiguration file; my vision here is to add a single option that says\nto load cells data from an auxiliary JSON file, a la policies.)  The\nproblem with this approach, of course, is that the data has to be\nmigrated out of the database and into that JSON file in some fashion;\nthis can\'t really be adequately handled via database migrations.  We\nalso necessarily lose the ability to add and remove cells via the API.\n\nI have thought of one way to at least partially mitigate the downsides\nof the second solution: allow the cell data to come from the database OR\nthe file.  We could then create a simple tool that could allow you to\nextract the data from the database and store it in a file later on,\nafter the migration.  In this scenario, the \"cells\" table remains for\nthe Havana release, then a later migration would remove it for Icehouse.\nWe would still need to ensure that the pending deprecation is carefully\ndocumented, along with the migration strategy, so that existing users\naren\'t caught by surprise?\n\nThoughts?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n',NULL,NULL),('<1371161517.3446.106.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 17:11:57',-18000,'2013-06-13 22:11:57',NULL,'[openstack-dev] Cells design issue','On Fri, 2013-06-14 at 09:52 +1200, Robert Collins wrote:\n> On 14 June 2013 09:50, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:\n> > Thoughts?\n> \n> How/why is a cell different from a node in this respect? [Serious question].\n\nSo, for inter-node communication within a given nova instance (cell),\nthere is a single Rabbit queue (or whatever) that all the nova services\nconnect to.  Since there\'s only one, this queue can be identified via\nconfiguration.\n\nWith cells, it\'s different; each cell essentially has its own queue that\nit listens to.  (This could be the single Rabbit queue that all its\nservices listen to, I think, or could be something totally different\nreserved solely for inter-cell communication.)  This means that, for one\ncell to talk to another, it must know how to talk to that other cell,\nand thus that data must be bound together with the information about\nwhat cells exist.  At present, we do this through the database.\n\nMake sense?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAJ3HoZ1NfomPckW=S07HvGj+JhfyH8SWxObCDdg=sA3YkW0hoA@mail.gmail.com>',NULL),('<1371191169.26914.134.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 07:26:09',3600,'2013-06-14 06:26:09',NULL,'[openstack-dev] Cells design issue','On Thu, 2013-06-13 at 16:50 -0500, Kevin L. Mitchell wrote:\n> At present, all the information that allows cells to communicate to each\n> other?including the Rabbit username and password?is stored in the\n> database, in clear text; while not really a security issue (if someone\n> can read your database, you\'re already on quicksand, security wise),\n> this is somewhat undesirable.  I would like to try to address this\n> issue, but I can really only come up with two basic approaches, both of\n> which will cause some migration issues, so I\'m hoping to kick off a\n> discussion as to which will be the more acceptable solution.\n> \n> The first potential solution is to simply encrypt the password in the\n> database.  (Actually, I intend to first merge all of the RPC information\n> into a single database field, then encrypt that; that will make it\n> easier to allow for alternate communication mechanisms in the future.)\n\nBear in mind that we\'re adding the notion of a transport URL to\noslo.messaging, partly for cells:\n\n  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_URLs\n\n> The problem with this approach is the key management problem: we either\n> have to encrypt the data during the migration, or provide a mechanism\n> whereby the data may be lazily encrypted at runtime; and we must also\n> allow for rekeying later on.\n> \n> The second potential solution is to drop the cells table from the\n> database and place all the data regarding cells (including the\n> connection information) into a configuration file.  (Not the master\n> configuration file; my vision here is to add a single option that says\n> to load cells data from an auxiliary JSON file, a la policies.)  The\n> problem with this approach, of course, is that the data has to be\n> migrated out of the database and into that JSON file in some fashion;\n> this can\'t really be adequately handled via database migrations.  We\n> also necessarily lose the ability to add and remove cells via the API.\n\nPutting it in a config file and losing the cells management API seems\nfine to me. Not entirely sure why, but it doesn\'t feel unlike a lot of\nother stuff we have in our config files.\n\nIs there any reason not to just put it in nova.conf as transport URLs?\n\n(By nova.conf, I mean cfg.CONF for nova which means you could happily do\ne.g. --config-file nova-cells.conf too)\n\n> I have thought of one way to at least partially mitigate the downsides\n> of the second solution: allow the cell data to come from the database OR\n> the file.  We could then create a simple tool that could allow you to\n> extract the data from the database and store it in a file later on,\n> after the migration.  In this scenario, the \"cells\" table remains for\n> the Havana release, then a later migration would remove it for Icehouse.\n> We would still need to ensure that the pending deprecation is carefully\n> documented, along with the migration strategy, so that existing users\n> aren\'t caught by surprise?\n\nMakes sense to me.\n\nCheers,\nMark.\n\n\n\n','<1371160220.3446.101.camel@einstein>',NULL),('<1371223988.3446.110.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 10:33:08',-18000,'2013-06-14 15:33:08',NULL,'[openstack-dev] Cells design issue','On Fri, 2013-06-14 at 07:26 +0100, Mark McLoughlin wrote:\n> > The first potential solution is to simply encrypt the password in the\n> > database.  (Actually, I intend to first merge all of the RPC information\n> > into a single database field, then encrypt that; that will make it\n> > easier to allow for alternate communication mechanisms in the future.)\n> \n> Bear in mind that we\'re adding the notion of a transport URL to\n> oslo.messaging, partly for cells:\n> \n>   https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_URLs\n\nAh, interesting.  I had two different approaches to storing the RPC\nconnection information, and one of them was a URI-esque approach.  The\nother was a JSON blob, which I felt might be better in the end, but I\'ll\ndefinitely take a look at this?\n\n> > The second potential solution is to drop the cells table from the\n> > database and place all the data regarding cells (including the\n> > connection information) into a configuration file.  (Not the master\n> > configuration file; my vision here is to add a single option that says\n> > to load cells data from an auxiliary JSON file, a la policies.)  The\n> > problem with this approach, of course, is that the data has to be\n> > migrated out of the database and into that JSON file in some fashion;\n> > this can\'t really be adequately handled via database migrations.  We\n> > also necessarily lose the ability to add and remove cells via the API.\n> \n> Putting it in a config file and losing the cells management API seems\n> fine to me. Not entirely sure why, but it doesn\'t feel unlike a lot of\n> other stuff we have in our config files.\n> \n> Is there any reason not to just put it in nova.conf as transport URLs?\n\nWe need different credentials for each cell, and this approach pulls\n*all* of the cells information out of the database, including such\nthings as weighting factors; that wouldn\'t fit well in a transport URL.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<1371191169.26914.134.camel@sorcha>',NULL),('<1371225700.26914.147.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 17:01:40',3600,'2013-06-14 16:01:40',NULL,'[openstack-dev] [Oslo] Code review I7ec346db: Improve usability\n when backdoor_port is nonzero','On Thu, 2013-06-13 at 12:29 -0500, Ray Pekowski wrote:\n> I suppose that since my patch for this code review was given a -2 it needs\n> to be discussed in this mailing list.\n\nBear in mind that not everyone reading this thread would know what\nreview you\'re talking about. It\'s this one:\n\n  https://review.openstack.org/31714\n\n> The code review addresses this as a usability problem, but perhaps by\n> approaching it as a bug fix, the community will be more amenable to the\n> proposed solution.  The bug is the failure of enabling the eventlet\n> backdoor functionality on all but the first service that comes up when the\n> backdoor_port is configured to be anything other than 0.  Why provide an\n> option that will 100% fail in a common situation (more than one service)\n> unless one specific value is configured?\n> \n> I see two solutions:\n> \n> 1) Change the backdoor_port configuration option to a boolean named\n> enabled_backdoor and always use a port number of 0.  I don\'t like this\n> solution.\n\nHonestly, I think it would be perfectly fine if we did two simple\nthings:\n\n  1) Logged (at INFO) level the port number chosen\n\n       [INFO] Eventlet backdoor listening on port 4321\n\n  2) Changed the help string for backdoor_port to say \"set to zero to\n     enable the backdoor on a random port and non-zero to enable it on a\n     specific port. The chosen port is displayed in the service\'s log \n     file.\"\n\nSo, yes you hit a usability issue with a pretty obscure feature. But\nlet\'s not get too side-tracked on this - a tiny patch goes a long way to\nstop anyone hitting that same issue.\n\nLong term, I think services will have a more useful service control RPC\nAPI for administrators as suggested by Vish a while ago:\n\n  https://etherpad.openstack.org/grizzly-common-services-control\n\nit\'s through this interface we\'d expose a more usable way of querying\nthe backdoor port.\n\n> 2) Change the backdoor_port configuration option name to\n> backdoor_starting_port and find a non-conflicting port by iteratively\n> incrementing the port number until an unused port is found.  The first\n> service gets backdoor_starting_port and the second service likely gets\n> backdoor_starting_port+1 and so on.\n> \n> I like the second option.  I have submitted a new patch that implements it\n> and logs a message about backdoor_port being deprecated if it is found.\n> \n> Please evaluate whether this new patch removes the objection that raised\n> the -2, namely that using a port number other than the one specified on the\n> backdoor_port would be unexpected and bad behavior.\n\nI don\'t think the starting_port thing helps too much - fundamentally,\nyou still need to be prepared to figure out which service ended up on\nwhich port.\n\nCheers,\nMark.\n\n\n\n','<CAJcv3CQOv1ZGK6zRGLF_EvoArG0x7V52tSSQjTPyr=rMZ-BMGg@mail.gmail.com>',NULL),('<1371328652.19.1369118248368.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-21 06:37:28',0,'2013-05-21 06:37:28',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-quantum-python26-stable-grizzly #41','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/41/changes>\n\n\n\n','<1321127753.15.1369031967817.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1371460477.31410.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 10:14:37',3600,'2013-06-17 09:14:37',NULL,'[openstack-dev] Cells design issue','On Fri, 2013-06-14 at 12:41 -0700, Chris Behrens wrote:\n> On Jun 13, 2013, at 11:26 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > Is there any reason not to just put it in nova.conf as transport URLs?\n> > \n> > (By nova.conf, I mean cfg.CONF for nova which means you could happily do\n> > e.g. --config-file nova-cells.conf too)\n> \n> The issue with using cfg.CONF is that we need the same config options\n> for each cell.  So, I guess you\'d have to dynamically create the\n> config groups with cell name as the group name? and have some sort of\n> global option or an option in a different config group that specifies\n> the list of cells.  I think it just gets kinda nasty.  But let me know\n> if I\'m missing a good way to do it.  It seems like JSON is going to be\n> a little more flexible. :)\n\nI don\'t know whether I like it yet or not, but here\'s how it might look:\n\n [cells]\n parents = parent1\n children = child1, child2\n\n [cell:parent1]\n transport_url = qpid://host1/nova\n\n [cell:child1]\n transport_url = qpid://host2/child1_nova\n\n [cell:child2]\n transport_url = qpid://host2/child2_nova\n\nCode for parsing that is:\n\n from oslo.config import cfg\n\n cells_opts = [\n     cfg.ListOpt(\'parents\', default=[]),\n     cfg.ListOpt(\'children\', default=[]),\n ]\n\n cell_opts = [\n     cfg.StrOpt(\'api_url\'),\n     cfg.StrOpt(\'transport_url\'),\n     cfg.FloatOpt(\'weight_offset\', default=0.0),\n     cfg.FloatOpt(\'weight_scale\', default=1.0),\n ]\n\n conf = cfg.CONF\n conf([\'--config-file=cells.conf\'])\n conf.register_opts(cells_opts, group=\'cells\')\n\n def get_cell(conf, name):\n     group_name = \'cell:\' + name\n     conf.register_opts(cell_opts, group=group_name)\n     return conf[group_name]\n\n for cell in conf.cells.parents + conf.cells.children:\n     print cell, get_cell(conf, cell).items()\n\n\nOk ... I think I do like it :)\n\nCheers,\nMark.\n\n\n\n','<4C0C9202-50DA-44E4-9C33-BEA0532245F2@codestud.com>',NULL),('<1371463428.31410.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 11:03:48',3600,'2013-06-17 10:03:48',NULL,'[openstack-dev] [Oslo] RPC trusted messaging','Hey,\n\nOn Mon, 2013-06-17 at 11:36 +0200, Julien Danjou wrote:\n> Hi there,\n> \n> What\'s the plan about RPC trusted messaging?\n> \n> Ceilometer has a blueprint depending on:\n> \n>   https://blueprints.launchpad.net/nova/+spec/trusted-messaging\n> \n> which if I read correctly is superseded. I guess there should be a\n> blueprint or something into Oslo about that, but I\'m not able to find\n> anything.\n\nHere it is:\n\n  https://blueprints.launchpad.net/oslo/+spec/trusted-messaging\n\nalso some notes here:\n\n  https://etherpad.openstack.org/HavanaOsloMessaging\n\nBasically, there\'s been a huge amount of good progress on this, but the\nfirst thing which needs to be merged is key distribution support in\nkeystone.\n\nCheers,\nMark.\n\n\n\n','<87k3ltulii.fsf@dex.adm.naquadah.org>',NULL),('<1371504889.27711.218.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 23:34:49',7200,'2013-06-17 21:34:49',NULL,'[openstack-dev] [metrics] Code contribution by 3rd party\n consultant on behalf of a corporation','For the reports on contributions to releases, we\'re counting individual\ncontrobibutions (as gitdm guys do), and then we have a table (which\nshould have pretty much the same info that the gitdm table has), which\nstates that developer D works for company C for such and such period.\nSo, I guess we use basically the same methodology.\n\nAn Monty suggests, if a certain developer can be counted as working for\na certain company during a certain period, it really doesn\'t matter if\nshe/he is working subcontracted, or what.\n\nI see two cases that could not be tracked with this schema:\n\n- Developer D working for company B and C at the same time (maybe\nbecause of subcontracting, or whatever). The only chance I see here is\nto label each commit somehow, maybe with the \"Contributed for:\n<affiliation>\" field suggested by Stefano.\n\n- Developer D working for company C, which during a certain period is\nsubcontracting for company D. In this  case, both D and C could be\ninterested in appearing as \"contributors\", probably in different\nclassifications. If we come to direct affiliations, C would be the\ncontributor. If we come to \"who is paying\", it would be D. Probably\nhaving both rankings would be important: company C would be interested\nin others knowing that they have expertise in working in OpenStack,\nwhile company D would be interested in showing their contributions. This\ncould be tracked with an extended table, including not only affiliation\n(as we do now), but also subcontracting (for which company is really\nworking each developer, for each period).\n\nOf course, both cases could happen at the same time, but I don\'t know if\nthat actually happens.\n\nIn addition, it is important to notice that we\'re also trying to track\nclosing tickets, messages, etc. which complicates things, since we would\nneed (in the case of tracking specific contributions) similar labels for\nall of this.\n\nJust my two (euro)cents,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\nOn Mon, 2013-06-17 at 20:50 +0000, Qing He wrote:\n> [Qing] my  one cent:\n> \n> -----Original Message-----\n> From: Monty Taylor [mailto:mordred at inaugust.com] \n> Sent: Monday, June 17, 2013 1:39 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [metrics] Code contribution by 3rd party consultant on behalf of a corporation\n> \n> It depends on a little bit on where you want the stats to show up.\n> \n> In gitdm, there is already a place you can put a date range on a\n> person to attach them to a company. I\'d start with just putting an\n> entry into the gitdm files showing that, for instance, Contractor A\n> worked for Company B for the Month of May.\n> \n> If you think it\'s conceivable that a single contractor might be\n> working in parallel for more than one company at the same time and\n> that we might want to track that patch C was done for Company B but\n> patch D was done for Company E, we might need to look in to something\n> more complex - but honestly, that seems like a kindof unlikley\n> situation, no?\n> \n> [Qing] In one situation this could happen: Contractor A gets work from\n> multiple companies and deals out tasks (e.g., offshore) and all the\n> tasks dealt out would be checked in under contractor A when finished.\n> \n> On 06/17/2013 04:33 PM, Chan, Winson C wrote:\n> > Metrics team,\n> > \n> >  \n> > \n> > Is there a best practice for counting commits made by a 3^rd party \n> > consultants/contractors (with multiple affiliations) on behalf of \n> > another corporation?  I recently had a conversation with Stefano and \n> > he suggested adding a \"Contributed for: <affiliation>\" in the commit \n> > message.  Stefano recommended that I get the dialog started here...\n> > \n> >  \n> > \n> > Thanks.\n> > \n> > Winson\n[...]\n\n\n\n','<08751C58B8AC2D45AC34FC099D5DD54003D3E3@BLUPRD0810MB390.namprd08.prod.outlook.com>',NULL),('<1371507213.31410.44.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 23:13:33',3600,'2013-06-17 22:13:33',NULL,'[openstack-dev] multiple message backends','Hi Paul\n\nOn Mon, 2013-06-17 at 15:18 -0600, Paul Mathews wrote:\n> Mark,\n> \n> As mentioned at the summit, we\'ve been looking into migrating from qpid \n> to zmq. We have gone through the process of migrating nodes from one set \n> of controllers to another, but that brought about it\'s own set of \n> problems for us. As a result of that, I\'ve written a patch for our use \n> that allows us to have services listen on both zmq and qpid backends.\n\nI think that\'s something we could consider supporting in the new\noslo.messaging API:\n\n  https://github.com/markmc/oslo.messaging\n\nBasically, you\'d have something like this:\n\n  qpid_transport = messaging.get_transport(CONF, \'qpid:///...\')\n  zmq_transport = messaging.get_transport(CONF, \'qpid:///...\')\n\n  server = messaging.get_rpc_server(qpid_transport, target, endpoints)\n  server.listen(zmq_transport)\n  server.start()\n\nSee also:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-May/008960.html\n\nThe use case we think is most likely is where ceilometer needs to\nconsume notifications from different brokers.\n\n\n> We \n> first check and see if the zmq receiver on the intended host is \n> listening. If it is, we deliver normally via zmq; if not, we assume the \n> destination is listening on qpid, and deliver the message to the qpid \n> host. I\'m not thrilled with the current implementation in respect to \n> checking if the host is listening for zmq connections first, but due to \n> the asynchronous way in which zmq operates, it\'s the best solution I\'ve \n> been able to come up with. I can\'t see multiple rpc backends as \n> something most people would use, and I do think my current \n> implementation of zmq checking could be more elegant. I\'m fairly \n> confident it would be easy to modify to encompass rabbitmq as well, but \n> as we don\'t use it, I haven\'t looked at any of their code. I\'m tempted \n> to just throw our patches up as a blog post or something, but I wonder \n> whether it\'s something the community might be interested in getting \n> mainlined. Do you feel like this is something I should submit for \n> review, or might there be technical or other reasons to leave it out?\n\nI\'m not 100% sure I follow all of the above, so please let me know if I\nmissed something.\n\nThanks,\nMark.\n\n\n\n\n','<51BF7D3F.9090307@bluehost.com>',NULL),('<1371534617.31410.51.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-18 06:50:17',3600,'2013-06-18 05:50:17',NULL,'[openstack-dev] tags to deleted branches','On Tue, 2013-06-18 at 00:20 -0400, Monty Taylor wrote:\n> \n> On 06/18/2013 12:09 AM, P?draig Brady wrote:\n> > I notice on some projects like nova and quantum (I presume with milestone proposed commits)\n> > that the 2013.2.b1 tag was created on the now removed milestone-proposed branch.\n> > Therefore `git describe` and `git log --decorate` etc. on master, ignore the latest tag.\n> > I was wondering if it would be better to tag on master itself?\n> > Also could these tags be retroactively be adjusted to point to corresponding master commits?\n> \n> Well, we release from the tag, so we can\'t move them. We\'ve discussed\n> merging milestone-proposed back in to master after release - but there\'s\n> a few logistical issues about doing that. Perhaps we should revisit that\n> discussion.\n\nThat strikes me as a little artificial. For the final release, the tag\nis the starting point of the stable branch and that makes total sense.\n\nThen again, if it makes git-describe output nicer, maybe there\'s no\nharm.\n\nBtw, this merge commit on master shouldn\'t change master at all .. it\nshould be e.g.\n\n  $> git checkout 0e760b3\n  $> git merge -s ours 2013.2.b1\n  $> git show --pretty=raw 0e760b3 | grep \'^tree\'\n  tree aae4de9b4e193a3784d7530fdcda0cce6f905683\n  $> git show --pretty=raw HEAD | grep \'^tree\'\n  tree aae4de9b4e193a3784d7530fdcda0cce6f905683\n\nI\'ve filed a bug:\n\n  https://bugs.launchpad.net/openstack-ci/+bug/1192039\n\nCheers,\nMark.\n\n\n\n','<51BFE006.3030300@inaugust.com>',NULL);
INSERT INTO `messages` VALUES ('<1371535041.31410.55.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-18 06:57:21',3600,'2013-06-18 05:57:21',NULL,'[openstack-dev] [tripleo] new reviewers?','On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote:\n> So, I\'ve been pretty happy with reviews from Chris Jones and Clint\n> Byrum - would like to propose them for the tripleo review team(s).\n\nFWIW, it\'s not clear what team you mean - the triple projects on\nstackforge are os-config-applier, os-refresh-config, diskimage-builder,\ntripleo-heat-elements and tripleo-image-elements.\n\nThe os-config-applier-core team covers the first two and\ndiskimage-builder-core covers the latter three.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ2rmtVMAAC4EZkQ9O6P+8WHugMxgph-Ky3Vg26XNFanUA@mail.gmail.com>',NULL),('<1371570802-sup-7133@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-18 08:54:34',-25200,'2013-06-18 15:54:34',NULL,'[openstack-dev] [tripleo] new reviewers?','Excerpts from Robert Collins\'s message of 2013-06-18 03:06:40 -0700:\n> On 18 June 2013 17:57, Mark McLoughlin <markmc at redhat.com> wrote:\n> > On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote:\n> >> So, I\'ve been pretty happy with reviews from Chris Jones and Clint\n> >> Byrum - would like to propose them for the tripleo review team(s).\n> >\n> > FWIW, it\'s not clear what team you mean - the triple projects on\n> > stackforge are os-config-applier, os-refresh-config, diskimage-builder,\n> > tripleo-heat-elements and tripleo-image-elements.\n> >\n> > The os-config-applier-core team covers the first two and\n> > diskimage-builder-core covers the latter three.\n> \n> Right, this is a little messy; we didn\'t appreciate enough of the\n> structure of gerrit when setting it up. I think it would be nice to\n> collapse down to one, or maybe two teams. That said, Chris and Clint\n> are reviewing everywhere, and are not members of both teams, so I\'m\n> proposing to ensure they are both in both teams.\n\nGiven that information, +1 Chris for os-config-applier-core\n\n(and I much appreciate the nomination for diskimage-builder-core :))\n\n\n','<CAJ3HoZ1n=+o8-QF4d292_YSfJ1HE2gCCRgn29g94pXGaX2=few@mail.gmail.com>',NULL),('<1371570930-sup-9166@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-18 08:58:21',-25200,'2013-06-18 15:58:21',NULL,'[openstack-dev] The future of run_tests.sh','Excerpts from Thierry Carrez\'s message of 2013-06-18 01:59:57 -0700:\n> Joe Gordon wrote:\n> > Reasons to keep run_tests.sh:\n> > \n> > * there is no possibility to run tests with testtools instead of testr.\n> > This feature allows us to use the debugger.\n> > * in some projects tox doesn\'t use a testr wrapper to report progress\n> > while tests are running \n> > * building the sdist can be slow (slow == noticeable)\n> \n> It also makes unit testing easily discoverable. After a repo clone it\'s\n> rather obvious that run_tests.sh will run tests. If you remove it,\n> people have to go through some effort to discover and run \"tox -epy27\".\n> \n\nJust to clarify, you\'re better off running \'tox\'. Not having py26 around\nis not an error, it will just be noted and skipped. This will also run\npep8 for you which is a fairly cheap operation and will catch any broken\nformatting early. This works fine with a passed in test module as well\n(though the global pep8 is still run w/o the arg)\n\n\n','<51C0218D.5010004@openstack.org>',NULL),('<1371571153-sup-3157@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-18 09:22:18',-25200,'2013-06-18 16:22:18',NULL,'[openstack-dev] The future of run_tests.sh','Excerpts from Sascha Peilicke\'s message of 2013-06-18 00:48:23 -0700:\n> On 06/18/2013 01:01 AM, Joe Gordon wrote:\n> > Hi All,\n> >\n> > A patch to move the run_tests.sh script into oslo-incubator\n> > (https://review.openstack.org/#/c/32736/), has brought up the bigger\n> > question of what is the future of \'./run_tests.sh.\'\n> >\n> > This seems like a topic that directly affects all developers, so it\n> > sounded like it should be brought to the Mailing list.\n> >\n> > Reasons to keep run_tests.sh:\n> >\n> > * there is no possibility to run tests with testtools instead of testr.\n> > This feature allows us to use the debugger.\n> > * in some projects tox doesn\'t use a testr wrapper to report progress\n> > while tests are running\n> > * building the sdist can be slow (slow == noticeable)\n> >\n> >\n> > Monty\'s Rant:\n> >\n> > \"So, I\'m SUPER torn on this.\n> >\n> > On the one hand, we use tox in the gate, and run_tests.sh hides that\n> > from people and then they get confused about why some change they made\n> > to run_tests.sh doesn\'t get reflected in the reality of the project.\n> >\n> > On the other hand, what Victor says is true. We need to land a couple of\n> > changes to upstream tox that would allow it to not run develop each time\n> > - but we seem to have a hard time doing that.\n> >\n> > On the third hand, we\'d doing an INSANE amount of work to make working\n> > with testing in a venv \"easy\" and what we\'ve wound up with is a\n> > situation where we have multiple competing incompatible ways of doing\n> > things.\n> >\n> > Here\'s what I do: source .tox/py27/bin/activate testr run --parallel\n> > testr run --parallel testr run some-test testr run --failing deactivate\n> >\n> > Sometimes, if I\'m being fancy, I\'ll do: virtualenv foo foo/bin/pip\n> > install -r requirements.txt -r test-requirements.txt\n> >\n> > I believe vish just installs the depends directly on his box and skips\n> > venvs altogether.\n> \n> It\'s not only vish but basically how distros test their packages, \n> actually :-)\n> \n> > It turns out that testr is a powerful tool with a nice UI. Instead of\n> > putting wrappers around it, perhaps we should add support for our output\n> > stream thing we like to it upstream. We should also add support to it\n> > for dropping into a debugger directly, so that the testtools issue goes\n> > away. Then we should land a patch to upstream tox to get it to do\n> > setup.py develop instead of sdist+ install.\n> >\n> > If we did that, we could have \"run tox\" be the simple answer for anyone\n> > who just wants to run whatever the gate runs, because that will always\n> > work. And if they want to do fancier things, they should learn about\n> > venvs and testr.\n> \n> \"run tox\" would work for distros too, they only have to patch tox.ini with:\n> \n> [testenv]\n> sitepackages = True\n\nSounds to me like tox needs a switch that runs the tests without the\nvirtualenv. This can be done right now by running tox --showconfig and\nparsing that to get the commands, but something like tox --no-venv should\nbe easy to do and useful to all.\n\n> \n> to avoid\n> \n> >\n> > However, if we ARE going to keep a run_tests.sh file in our trees, we\n> > should certainly have a single copy and have it behave consistently.\n> >\n> > Please note that some projects actually do just have run_tests.sh as a\n> > thin wrapper around tox.\"\n> >\n> >\n> > What do you think? Should we keep run_tests as is and port to oslo, or\n> > should we revisit the role of run_tests.sh?\n> \n> I don\'t think the demands for testing on the gate are necessarily the \n> same for developers and/or packagers. For gating, we want fast, i.e. \n> parallel testing. Developers want PDB and running individual tests. \n> That\'s why nosetests is and remains so popular. However, packagers hate \n> everything that messes up their build environment. This includes stuff \n> that downloads from the interwebs or ignores the underlying systems. \n> Thus virtualenvs, setuptools_git, sphinx.ext.intersphinx & co. are a no \n> go and usually patched away. \"./run_tests.sh -N -P\" does a good job but \n> \"nostests\" is equally suitable for package testing. By contrast, tox \n> still creates a venv with \"sitepackages = True\", which is overhead for \n> no gain. When you test distro packages, you don\'t need several testenvs, \n> test against the Python interpreter your packages where build against \n> and don\'t care for PEP-8.\n> \n\nTo be clear, tox runs individual tests just fine, simply pass in a module\nto run. Agreed that it takes quite a bit of digging to get to a point\nwhere you can use pdb.\n\nTrying to be everything to everyone is almost never a good idea. However,\nwhat is a good idea is loosely integrating and not repeating ourselves.\n.testr.conf and tox.ini have all of the info necessary to run tests. If\nrun_tests.sh does need to stay, I would propose that it parse these\nfiles as much as possible so that when the gate changes, so does the way\ndevelopers run tests.\n\n\n','<51C010C7.7060402@suse.com>',NULL),('<1371627834.2402.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 08:43:54',3600,'2013-06-19 07:43:54',NULL,'[openstack-dev] [RFC] Remove nova plugins framework','Hi\n\nWe merged a plugins framework[1] into Nova[2] and oslo-incubator[3]\nalmost a year ago and AFAICT hasn\'t seen use beyond the two initial\nwikimedia extensions[4][5] for Nova.\n\nThe framework basically allows a way for a single plugin to register API\nextensions and notification hooks. Both of these can be done by directly\nusing config opts like osapi_compute_extension and notification_driver\nso IMHO this framework really only helps if we expected to (and wanted\nto) lots of these plugins in the wild.\n\nThe reason I even noticed this is that I was considering whether\noslo.messaging would need to include the equivalent of the current\nnotification API\'s add_driver() function. This is only used by the\nplugins framework.\n\nWe have a MAINTAINERS file in oslo-incubator that explains how APIs need\nto be actively maintained and in use by multiple projects or the APIs\nwill be removed from oslo-incubator.:\n\n  https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS\n\nThe plugins framework is listed as orphaned and is only in use by Nova.\n\nI\'ve put up these patches to remove it:\n\n  https://review.openstack.org/33595\n  https://review.openstack.org/33597\n\nAny objections?\n\nThanks,\nMark.\n\n[1] - https://wiki.openstack.org/wiki/Novaplugin\n[2] - https://review.openstack.org/9668\n[3] - https://review.openstack.org/9276\n[4] - https://lists.launchpad.net/openstack/msg12045.html\n[5] - https://github.com/andrewbogott/novawikiplugins\n\n\n\n',NULL,NULL),('<1371631996.2402.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 09:53:16',3600,'2013-06-19 08:53:16',NULL,'[openstack-dev] [RFC] Remove nova plugins framework','On Wed, 2013-06-19 at 10:20 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > We merged a plugins framework[1] into Nova[2] and oslo-incubator[3]\n> > almost a year ago and AFAICT hasn\'t seen use beyond the two initial\n> > wikimedia extensions[4][5] for Nova.\n> \n> I\'d suggest to be a bit careful with that... It\'s a bit hard to tell\n> whether it\'s being used, since some parties may take advantage of this\n> plugin framework and we don\'t really know about them.\n> \n> Maybe ask about anyone using those on the general ML ? Can it be\n> \"deprecated\" in Havana instead of removed ?\n\nWell, the implication of that would be oslo.messaging supporting an API\nthat we won\'t need in future.\n\nIt\'s not totally clear what our level of support is for external plugins\nlike this is. Certainly the API extensions hooks in Nova aren\'t\nsomething we\'ve committed to maintaining API stability around.\n\nWhich means that this interface is unstable. If you were using it in\nFolsom or Grizzly, you have to be prepared for it to change in Havana.\n\nAnd the change isn\'t actually as big a deal as it sounds even for people\nwho may we using it - you just register your API extensions via the\nosapi_compute_extension config option and your notification driver via\nthe notification_driver config option. There\'s a very clear migration\npath.\n\n> I also CCed Andrew Boggott (original author) to make sure he is aware of\n> this discussion.\n\nYeah, I did too - mailman just stripped the CC in the copy it sent to\nthe list. Rather annoying.\n\nCheers,\nMark.\n\n\n\n','<51C169CE.2050507@openstack.org>',NULL),('<1371636222.2402.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-19 11:03:42',3600,'2013-06-19 10:03:42',NULL,'[openstack-dev] [ironic] Legal issue with the name \"Ironic\"','Hi Roman,\n\nThanks for raising this, but it really isn\'t desirable to raise issues\nlike this in such a public forum.\n\nWe should all refrain from discussing this issue on this thread.\n\nI\'ve added a FAQ here:\n\n  https://wiki.openstack.org/wiki/LegalIssuesFAQ#Legal_Concerns_Over_Project_Names\n\nand will get an proper answer added so people have a better idea what to\ndo in future.\n\nThanks,\nMark.\n\n\n\n','<08D65BE3-C62B-4832-9106-C832781B8509@mirantis.com>',NULL),('<1371638558.34686.YahooMailNeo@web5706.biz.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-06-19 03:42:38',-25200,'2013-06-19 10:42:38',NULL,'[Openstack-operators] Spawning Error in launching instances','I install openstack essex. when i try to launch instance i am gettting error that spawning error. what type of error this one. How i can solve this one??\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130619/2a0baee2/attachment.html>\n\n',NULL,NULL),('<1371731314.2402.82.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-20 13:28:34',3600,'2013-06-20 12:28:34',NULL,'[openstack-dev] Defining API Success in OpenStack APIs\n (specifically Swift)','On Thu, 2013-06-20 at 07:21 -0400, Sean Dague wrote:\n> The following patch review came into Tempest yesterday to stop checking \n> for specific 20x codes on a number of Swift API - \n> https://review.openstack.org/#/c/33689/\n> \n> The official documentation for these APIs says the following - \n> http://docs.openstack.org/api/openstack-object-storage/1.0/content/retrieve-account-metadata.html\n> \n> \"The HTTP return code will be 2xx (between 200 and 299, inclusive) if \n> the request succeeds\"\n> \n> This seems kind of broken to me that that\'s the contract provided. I\'ve \n> got a -1 on the patch right now, but I think this is worth raising for \n> broader discussion. It seems to go somewhat contrary to \n> https://wiki.openstack.org/wiki/APIChangeGuidelines and to the spirit of \n> having stable, well defined interfaces.\n> \n> So I guess I open up the question of is it ok for OpenStack core \n> projects to not commit to success codes for API calls? If so, we\'ll let \n> the test change into Tempest. If not, we probably need to call that out \n> on API standards.\n\nIn one way, it\'s actually perfectly valid. A perfectly written client\nshould perhaps have generic logic around handling different status\ncodes. For example, if it requires that an action be completed, it\nshould know to poll for completion if it gets a 202 Accepted.\n\nIf clients were written with that kind of logic, then all would be well\nwith our \"return code between 200 and 299\" contract but the reality is\nthat people will code their clients - no matter what the docs say -to\nthe specific return codes we send back right now and they\'ll probably\nbreak if we change the status codes.\n\nSo, yeah - pragmatically speaking, I think we need to commit to not\nchanging success return codes for existing clients. Maybe new clients\ncould opt-in to the new behaviour somehow if we do need to change.\n\nCheers,\nMark.\n\n\n\n','<51C2E5B0.5020501@dague.net>',NULL),('<1371742737.3446.142.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-20 10:38:57',-18000,'2013-06-20 15:38:57',NULL,'[openstack-dev] XML Support for Nova v3 API','On Thu, 2013-06-20 at 10:04 +0930, Christopher Yeoh wrote:\n> Just wondering what people thought about how necessary it is to keep\n> XML support for the Nova v3 API, given that if we want to drop it\n> doing so during the v2->v3 transition is pretty much the ideal time to\n> do so.\n> \n> The current plan is to keep it and is what we have been doing so far\n> when porting extensions, but there are pretty obvious long term\n> development and test savings if we only have one API format to\n> support.\n\nI vote for dropping XML like a hot rock.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CANCY3eejPd2WbQneTLZ5pHGRW7XYECQBqGpojkM_KTkzmP-W3A@mail.gmail.com>',NULL),('<1371761842.3446.156.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-20 15:57:22',-18000,'2013-06-20 20:57:22',NULL,'[openstack-dev] XML Support for Nova v3 API','On Thu, 2013-06-20 at 16:02 -0400, Sean Dague wrote:\n> There are lots of nice things we could do, given time and people. But \n> the reality is that relatively few people are actually working on the \n> API code, documentation, tooling around it.\n> \n> I would much rather have us deliver a world class JSON API with \n> validation and schema and comprehensive testing, than the current state \n> of our JSON + XML approach which is poorly documented and only partially \n> tested.\n\n+10000.  Let\'s drop XML like a hot rock.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51C35FC0.9050704@dague.net>',NULL),('<1371797772.27737.2.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-21 14:56:12',28800,'2013-06-21 06:56:12',NULL,'[openstack-dev] [Heat] re: discussion about passing metadata\n into provider stacks as parameters','On Fri, 2013-06-21 at 15:49 +1000, Angus Salkeld wrote:\n> On 20/06/13 22:19 -0400, cbjchen at linux.vnet.ibm.com wrote:\n> >\n> >So anyway, let\'s get back to the topic this thread was discussing \n> >about - \"passing meta data into provider stacks\".\n> >\n> >It seems that we have all reached an agreement that deletepolicy and \n> >updatepolicy will be passed as params, and metadata will be exposed \n> >to provider templates through a function\n> >\n> >In terms of implemetation,\n> >\n> >MetaData:\n> >\n> >- add a resolve method to template.py to handle  \n> >{\'Fn::ProvidedResource\': \'Metadata\'}\n> \n> I think the name needs a little thought, how about:\n> \n> {\'Fn::ResourceFacade\': \'Metadata\'}\n> \n> -Angus\n\nYeah, sounds better~\n\n> >\n> >DeletePolicy/UpdatePolicy:\n> >\n> >- add stack_resource.StackResource.compose_policy_params() -> Json \n> >encoded delete and update policies\n> >\n> >- have create_with_template update params with delete/update policies \n> >composed by compose_policy_params\n> >(json-parameters implementation is already in review, hope it will be \n> >available soon)\n> >\n> >\n> >I will start the implementation if there is no objection.\n> >\n> >\n> >Liang\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<20130621054952.GA11083@redhat.com>',NULL),('<1371832083.3446.161.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-21 11:28:02',-18000,'2013-06-21 16:28:02',NULL,'[openstack-dev] Cells design issue','On Fri, 2013-06-21 at 09:16 -0700, Armando Migliaccio wrote:\n> In my view a cell should only know about the queue it\'s connected to,\n> and let the \'global\' message queue to do its job of dispatching the\n> messages to the right recipient: that would solve the problem\n> altogether.\n\nThere is no \"global\" message queue in the context of cells.\n\n> Were federated queues and topic routing not considered fit for the\n> purpose? I guess the drawback with this is that it is tight to Rabbit.\n\nAgain, there\'s no single message queue in the context of cells.  I\'m\nassuming that was to avoid a bottleneck, but Chris Behrens would be able\nto say better exactly why this design choice was made.  All I\'m doing in\nthis discussion is trying to address one element of the current design;\nI\'m not trying to redesign cell communication.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CAGjnL0CTKiFUXv3MQaDXN6H=XO50DfyASh7BQ+W1YfQcsVD2qg@mail.gmail.com>',NULL),('<1371834582.2402.110.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-21 18:09:42',3600,'2013-06-21 17:09:42',NULL,'[openstack-dev] Cells design issue','On Fri, 2013-06-21 at 09:30 -0700, Chris Behrens wrote:\n> > On Mon, Jun 17, 2013 at 2:14 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n> > I don\'t know whether I like it yet or not, but here\'s how it might\n> look:\n> > \n> >  [cells]\n> >  parents = parent1\n> >  children = child1, child2\n> > \n> >  [cell:parent1]\n> >  transport_url = qpid://host1/nova\n> > \n> >  [cell:child1]\n> >  transport_url = qpid://host2/child1_nova\n> > \n> >  [cell:child2]\n> >  transport_url = qpid://host2/child2_nova\n> [?]\n> \n> Yeah, that\'s what I was picturing if going that route.  I guess the\n> code for it is not bad at all.  But with oslo.config, can I reload\n> (re-parse) the config file later, or does the service need to be\n> restarted?\n\nSupport for reloading should get merged soon:\n\nhttps://review.openstack.org/32231\n\nCheers,\nMark.\n\n\n\n','<8E80AFC9-E241-4A7C-8120-EF7422D0ABFA@codestud.com>',NULL),('<1372110618.2370.52.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 22:50:18',3600,'2013-06-24 21:50:18',NULL,'[openstack-dev] Termination of the title line of commit messages','Hey,\n\nPulling this out of gerrit for discussion.\n\nBackground is one of my patches to diskimage-builder was -1ed because I\nterminated the title line of the commit message with a period:\n\n  https://review.openstack.org/33262\n\nThis is actually the exact opposite to what I consider normal practice\nfor git commit messages as I explained in the review and the tripleo\nwiki page, so I proposed a hacking change here:\n\n  https://review.openstack.org/33789\n\nThe rationale for *not* having a period is:\n\n  * With the 50 char limit, space is at a premium on the first line\n\n  * The first line is often used as the Subject: in [PATCH] emails -\n    subject lines in emails generally don\'t end in a period\n\n  * Examples in:\n\n      https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure\n\n    don\'t end in period\n\n    (Note - the \"should not end with a period\" was only added by me \n    recently)\n\n  * Another common reference on git commit messages\n\n      http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn\'t either\n\n  * In git\'s own git repo, 1.43% of commit messages in the last year \n    ended in a period\n\n  * I\'m not aware of any other OpenStack project which enforces this. \n    Looking at the history of various projects for the past year (and \n    excluding merge commits which don\'t end with a period), the use of \n    period termination runs at between 10 and 30%.\n\nUnlike other nitpicking I tend to do with commit messages, I previously\nnever thought this was worth even mentioning to committers but if some\nreviewers were going to start -1ing people for the *correct* style then\nI figured it was best to clear it up.\n\nNow, for Robert\'s comments in the review:\n\n> It would have been nice for this to be discussed rather than dropping\n> into the communal standards without warning;\n\nI tried my best do explain why period termination is broken in the\ndiskimage-builder review and wiki page, so it\'s not like I was trying to\navoid a discussion.\n\nIn any case, if I, jogo and sdague got this wrong somehow, the mistake\nis only a git-revert away from being corrected.\n\n> the prior documentation *did not* require a period,\n\nYes, but the examples didn\'t use a period which obviously means a policy\nto *require* a period is a bit bizarre.\n\nI\'m pretty confident that danpb didn\'t mention this when he wrote the\npage because he either felt it was obvious or not worth mentioning. I\'ve\ncc-ed him to be sure.\n\n> and the reference that was sourced that\n> doesn\'t use them is one in the git-via-email world which is not how\n> OpenStack does *any* of it\'s git communications, so the \'gets used\n> like subject line of emails\' point is entirely irrelevant.\n\ngit was born came from a git-via-email world and its usage conventions\nreflect that. I raised the subject line point to try and explain how git\nconventions may have arisen.\n\n> In TripleO we have been using a period because the first line of the\n> commit message acts like the first line of a docstring: it is a pithy\n> description of the object it describes. Docstrings are also space\n> limited, and yet PEP8 happily requires good sentence structure and\n> grammar there.\n\nIt\'s not a docstring, though. It\'s a git commit message.\n\n> tl;dr - this is an unpythonic change, and the lack of discussion is\n> quite annoying.\n\nWell, the former point is irrelevant and hopefully this email corrects\nthe latter point :)\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1372111014.2370.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-24 22:56:54',3600,'2013-06-24 21:56:54',NULL,'[openstack-dev] Termination of the title line of commit messages','On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:\n> Hey,\n> \n> Pulling this out of gerrit for discussion.\n> \n> Background is one of my patches to diskimage-builder was -1ed because I\n> terminated the title line of the commit message with a period:\n> \n>   https://review.openstack.org/33262\n> \n> This is actually the exact opposite to what I consider normal practice\n> for git commit messages as I explained in the review and the tripleo\n> wiki page, so I proposed a hacking change here:\n> \n>   https://review.openstack.org/33789\n> \n> The rationale for *not* having a period is:\n> \n>   * With the 50 char limit, space is at a premium on the first line\n> \n>   * The first line is often used as the Subject: in [PATCH] emails -\n>     subject lines in emails generally don\'t end in a period\n> \n>   * Examples in:\n> \n>       https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure\n> \n>     don\'t end in period\n> \n>     (Note - the \"should not end with a period\" was only added by me \n>     recently)\n> \n>   * Another common reference on git commit messages\n> \n>       http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html doesn\'t either\n> \n>   * In git\'s own git repo, 1.43% of commit messages in the last year \n>     ended in a period\n> \n>   * I\'m not aware of any other OpenStack project which enforces this. \n>     Looking at the history of various projects for the past year (and \n>     excluding merge commits which don\'t end with a period), the use of \n>     period termination runs at between 10 and 30%.\n> \n> Unlike other nitpicking I tend to do with commit messages, I previously\n> never thought this was worth even mentioning to committers but if some\n> reviewers were going to start -1ing people for the *correct* style then\n> I figured it was best to clear it up.\n> \n> Now, for Robert\'s comments in the review:\n> \n> > It would have been nice for this to be discussed rather than dropping\n> > into the communal standards without warning;\n> \n> I tried my best do explain why period termination is broken in the\n> diskimage-builder review and wiki page, so it\'s not like I was trying to\n> avoid a discussion.\n> \n> In any case, if I, jogo and sdague got this wrong somehow, the mistake\n> is only a git-revert away from being corrected.\n> \n> > the prior documentation *did not* require a period,\n> \n> Yes, but the examples didn\'t use a period which obviously means a policy\n> to *require* a period is a bit bizarre.\n> \n> I\'m pretty confident that danpb didn\'t mention this when he wrote the\n> page because he either felt it was obvious or not worth mentioning. I\'ve\n> cc-ed him to be sure.\n> \n> > and the reference that was sourced that\n> > doesn\'t use them is one in the git-via-email world which is not how\n> > OpenStack does *any* of it\'s git communications, so the \'gets used\n> > like subject line of emails\' point is entirely irrelevant.\n> \n> git was born came from a git-via-email world and its usage conventions\n> reflect that. I raised the subject line point to try and explain how git\n> conventions may have arisen.\n> \n> > In TripleO we have been using a period because the first line of the\n> > commit message acts like the first line of a docstring: it is a pithy\n> > description of the object it describes. Docstrings are also space\n> > limited, and yet PEP8 happily requires good sentence structure and\n> > grammar there.\n> \n> It\'s not a docstring, though. It\'s a git commit message.\n> \n> > tl;dr - this is an unpythonic change, and the lack of discussion is\n> > quite annoying.\n> \n> Well, the former point is irrelevant and hopefully this email corrects\n> the latter point :)\n\nI missed this point:\n\n> Also not that space is limited to 50 characters by choice, not\n> necessity (the very same external reference about git commit messages\n> pointed out that 50 is not a hard limit). It is a hard limit for us...\n> because we chose to make it so. \n\nIt\'s another pretty common git usage convention - I think the idea is to\nmake output like \'git log --oneline\' fit on 80 char terminals. The\nnumbers don\'t add up, though, so maybe it\'s another thing from the\ngit-via-email world. Also, the idea is probably to take into account\nthat the first line can be quoted by e.g. \'Merge \"foo\"\' or \'Revert\n\"foo\"\' in the first line of other commit messages.\n\nCheers,\nMark.\n\n\n\n','<1372110618.2370.52.camel@sorcha>',NULL),('<1372170870.2370.93.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 15:34:30',3600,'2013-06-25 14:34:30',NULL,'[openstack-dev] OpenStack Programs','Hey,\n\nOn Mon, 2013-06-24 at 11:50 +0200, Thierry Carrez wrote:\n\n> The TC would bless the *mission statement* of the program rather than\n> the specific set of projects implemented to reach that goal.\n\nThis is a really nice way of putting it and you\'ve captured a bunch of\nother stuff very well too.\n\nThe main thing I think about is the integrated release[1] - i.e. the\ncategories I care about are \"officially part of the release\" and\n\"official and important OpenStack projects which aren\'t part of the\nrelease\".\n\nMaybe this is just about a program\'s mission statement - as part of the\nmission statement, you explain what the program will contribute to the\nrelease. In the case of Oslo, it produces libraries to be included in\nthe release. In the case of Infrastructure, it doesn\'t produce anything\nto be included in the release.\n\nIn the case of TripleO, does it produce anything to be included in the\nrelease? I think it should, but it\'s not the entirety of its mission\nstatement either. That, for me, is the really interesting thing to\ndiscuss about TripleO - what does it intend to produce for inclusion in\nthe integrated release?\n\nIn terms of incubation, you could say \"new projects that are intended\nfor inclusion in the integrated release will go through incubation\" ...\nbut that doesn\'t make sense in all cases. For example, there\'s not much\nvalue in new oslo libraries going through an incubation cycle because\nnothing would be able to use the library until it had exited incubation.\n\nCheers,\nMark.\n\n[1] - ok, some caveats on what I mean by \"integrated release\" ...\n\nWe\'re producing software for people who want to build clouds. A software\n\"product\", for want of a better term.\n\nRight now, we say the official \"service projects\" (definition: a project\nwhich exposes a REST API?) are \"integrated projects\" and that\'s what\'s\ncontained in our release. I think we also say that Oslo libraries are\npart of the integrated release.\n\nThe way I see it, our release is a product and should contain any\nofficial OpenStack software which provides a more complete experience\nfor people deploying OpenStack clouds.\n\nThe only change that would mean right now is that the client libraries\nand docs would be part of the integrated release. Even if there are some\nwonky details - like we have good reason to *also* release clients\nindependently of the release cycle for a different set of target users\n(i.e. cloud users, not cloud builders) and that complete docs aren\'t a\nblocker for the integrated release going out - I think the release is\nweirdly incomplete without those considered a part of it.\n\nAlso, before any jumps in with \"we shouldn\'t have releases, trunk should\nalways be releasable\" ... that\'s mostly orthogonal. We\'d still have a\nconcept of an integrated product - which includes more than just the\nserver products - which is always releaseable.\n\n\n\n','<51C8166E.9070202@openstack.org>',NULL),('<1372171580.2370.101.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 15:46:20',3600,'2013-06-25 14:46:20',NULL,'[openstack-dev] OpenStack Programs','On Mon, 2013-06-24 at 13:14 -0400, Monty Taylor wrote:\n> > * Where would openstack/requirements fall ?\n> \n> I think openstack/requirements sits under oslo - although right now\n> it\'s a joint-venture between oslo and infra. \n\nIf you look at the Oslo \"mission statement(s)\":\n\n  https://wiki.openstack.org/wiki/Oslo\n\n  The Oslo program produces a set of python libraries containing\n  infrastructure code shared by OpenStack projects. The APIs provided by\n  these libraries should be high quality, stable, consistent and\n  generally useful. \n\n  The Oslo program brings together generalist code reviewers and\n  specialist API maintainers. They share a common interest in tackling\n  copy-and-paste technical debt across the OpenStack project.\n\nthen the overlap with openstack/requirements isn\'t at all obvious.\n\nNot to try and lump this solely on Thierry or anything, but I see this\nas a release/distribution management concern - the fundamental question\nis what external dependencies (and what version of those) is it sane for\nus to require in order to deploy OpenStack?\n\nLooking again at the review criteria:\n\n  https://wiki.openstack.org/wiki/Requirements\n\nthose questions are all about keeping a firm control over what external\nrisks we expose ourselves (e.g. flakey upstreams) and that the\ndependency is compatible with our release goals (e.g. license, python\nversion, distro availability).\n\nCheers,\nMark.\n\n\n\n','<51C87E5E.9080108@inaugust.com>',NULL),('<1372189718.2370.162.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-25 20:48:38',3600,'2013-06-25 19:48:38',NULL,'[openstack-dev] OpenStack Programs','On Tue, 2013-06-25 at 18:58 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > [1] - ok, some caveats on what I mean by \"integrated release\" ...\n> > \n> > We\'re producing software for people who want to build clouds. A software\n> > \"product\", for want of a better term.\n> > \n> > Right now, we say the official \"service projects\" (definition: a project\n> > which exposes a REST API?) are \"integrated projects\" and that\'s what\'s\n> > contained in our release. I think we also say that Oslo libraries are\n> > part of the integrated release.\n> \n> I think I have a slightly different view.\n> \n> We as a project produce a number of deliverables. Some of those (the\n> \"integrated projects\") are released as a common, coordinated release at\n> the end of our 6-month development cycles. The others (which include the\n> python client libraries and the Oslo libraries) are released as-needed,\n> although in some cases they borrow the same release cycle.\n\nOslo follows the the same release cycle as the server projects, because\nthey\'re part of the same \"product\" - the deliverables of Oslo don\'t have\nany (intended) use other than as part of the integrated release. They\'re\nnot \"borrowing\" the same release cycle out of convenience, they\'re\nfundamentally part of the same development cycle.\n\nTo take another example - say we split the Nova virt drivers out into\nseparate projects with a well defined interface between them and Nova\nproper. They still should be part of the release. In this case, they\'d\nstill be in the Nova program, but it\'s the same idea - Oslo libraries\nare primarily just parts of the server projects split out and shared.\n\n> I don\'t think we should start overloading the meaning of \"integrated\".\n> So the way I see it you would have teams, potentially producing\n> deliverables. If one of those deliverables is to be part of the\n> \"integrated release\" then you want to become a \"Project\" and you need to\n> go through Incubation so that we check that you won\'t fuck up the rest\n> of the integrated projects. If your team works on other deliverables\n> (Documentation, Oslo libraries) or helps other teams (Infrastructure,\n> Release) then you can apply to become a \"Program\".\n\nI\'m not trying to overload terms here - \"integrated\", \"project\",\n\"program\", etc. I need to parse and re-read your definitions of those\nbecause there\'s some subtleties in your think that surprise me ... and\nI\'m not sure why all of these distinctions are so important.\n\nYour subtlety seems to be that only the server products are in the\nrelease and stuff like the OpenStack-producted libraries you need and\nthe documentation to support it are some separate deliverable from the\nrelease?\n\nIs the distinction you\'re making that the only things in the release\nshould be things which have gone through incubation?\n\nTo my mind, the single most important thing we do is produce a software\n\"product\" (or \"release\", or \"distribution\") for people building clouds.\nI can\'t see how documentation, client libraries and supporting libraries\naren\'t a fundamental part of that thing.\n\n> All the deliverables from Projects + Programs are OpenStack deliverables\n> and contributing to them grants you ATC status, and in return Projects\n> and Programs are under the oversight of the TC.\n\nI honestly don\'t really care much about ATC status in all of this. I\'d\nbe happy for that to be really broad - any sort of a contribution to\nanything officially part of the project.\n\n> Do you think we need to distinguish between those deliverables, and tag\n> some of them as being part of the OpenStack \"product\", and some others\n> as merely production helpers ? I\'m not sure that would add a lot of value...\n\nThere are things we expect people to download from OpenStack and use to\nbuild a cloud. Producing that set of things is our main focus.\n\nThere are things (i.e. clients) that we expect people to download from\nOpenStack and use to interact with OpenStack clouds. This is actually a\nsubset of the above, because you can\'t build a cloud without these\nthings.\n\nThere are things which are critically important to helping us produce\nall of the above, but we don\'t expect cloud builders or cloud users to\never need them.\n\nAgain, the first set of things and the target users (i.e. cloud\nbuilders) are the main reason we\'re here. I think we should be really\nclear about what\'s included in that set of things.\n\nMy first question for any new program - and something I\'d expect to see\nin their mission statement - is what things (if anything) the program\nwill be contributing to the set of things that will be compelling for\ncloud builders.\n\nCheers,\nMark.\n\n\n\n','<51C9CC2E.7000609@openstack.org>',NULL),('<1372209526.16573.107.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 11:18:46',36000,'2013-06-26 01:18:46',NULL,'[openstack-dev] swift & keystone failing in devstack','On Tue, 2013-06-25 at 09:30 -0600, Pete Zaitcev wrote:\n> On Tue, 25 Jun 2013 08:50:49 +0100\n> Michael Kerrin <michael.kerrin at hp.com> wrote:\n> \n> > we raised a bug https://bugs.launchpad.net/devstack/+bug/1193112 where the \n> \n> > $  /opt/stack/swift/bin/swift-proxy-server /etc/swift/proxy-server.conf -v\n> > Traceback (most recent call last):\n> >   File \"/opt/stack/swift/bin/swift-proxy-server\", line 22, in <module>\n> >     run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n> > [.....]\n> >   File \"/opt/stack/keystone/keystone/middleware/s3_token.py\", line 65, in \n> > __init__\n> >     self.http_client_class = environment.httplib.HTTPConnection\n> > AttributeError: \'NoneType\' object has no attribute \'HTTPConnection\'\n> \n> The issue is that there\'s no \"environment\" module in Swift,\n> and the s3_token is loaded in the context of Swift\'s WSGI pipeline.\n> \n> > I raised a work around here https://review.openstack.org/#/c/34207/ not in the \n> > hope that this code will get committed but in the hope that someone will see \n> > this and know what to do. That review is also a work around for anyone hit by \n> > this bug.\n> > \n> > So if anyone knows what to do for this bug please help,\n> \n> The most expedient fix is to undo the part of commit 3afd9791\n> which breaks s3_token. I cc-ed Jamie and Adam on it. Actually,\n> Michael, since you\'re the sufferer, why don\'t you go ahead and\n> propose the change instead of 34207? I\'ll be happy +1 it.\n\nThis change was supposed to be a completely keystone internal change and\ni didn\'t realize that it was being used by devstack. Sorry to everyone\nwho got caught up in it. \n\nSo i\'ve added a review to revert this change regarding middleware held\nin the keystone server. https://review.openstack.org/#/c/34484/\n\nIn a more general sense code from within keystone shouldn\'t be being\nused by devstack at all and if it needs to be used then i agree that it\nshould be moved. I\'ve added a new bug\nhttps://bugs.launchpad.net/keystone/+bug/1194688 to track ideas and the\nprogress of this. \n\n> Beyond that, we have a few choices:\n>  - Add environment to Swift\n>    - Either do it like 34207, but that makes Swift depend on Keystone\n>      (Michael forgot to adjust requirements.txt, but never mind the\n>       small stuff)\n>    - Or duck-type environment, like swob\n\nEnvironment is a way to make transparent whether things are coming from\neventlet or from the stdlib. I\'d like to make this a pattern that\neveryone implements but it shouldn\'t be done to fix this bug.\n\n>  - Pull s3_token out of Keystone\n>    - Put it into python-keystoneclient, where auth_token already\n>      resides. Same environment, same code rules apply. This is going to\n>      ruin my webob-destruction party in review 32825, but I\'ll survive.\n\nThis would be the most obvious solution. \n\n>    - Put it into swift3. I cc-ed Tomo to see if he\'d welcome it.\n>      The rationale here is that originally s3_token was kept inside\n>      Keystone codebase because the protocol between it and the server\n>      could change at any minute. Hopefuly this no longer applies\n>      and this protocol is going to be a side channel in v3 without\n>      any changes. Chmouel?\n\nI would like to see this as it is a niggling pain of mine that keystone\ndepends upon swift for this middleware. Maybe a way of breaking this\nwould be to put some s3token functions onto keystoneclient, and make the\nmiddleware use those? \n\n>    - Put it into Swift, alongside keystoneauth. Not sure about\n>      that one.\n\n\n> I would like to see s3_token migrate to swift3. I\'m willing to put\n> a couple of patches together to make it happen. Just need Chmouel\n> agree that the protocol is stable enough, and Tomo agree, of course.\n> \n> -- Pete\n\n\n\n\n\n','<20130625093037.0fa1eb5b@lembas.zaitcev.lan>',NULL),('<1372249727.2370.229.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 13:28:47',3600,'2013-06-26 12:28:47',NULL,'[openstack-dev] OpenStack Programs','On Wed, 2013-06-26 at 14:15 +0200, Thierry Carrez wrote:\n> 4. Be potentially able to define a set of projects that are \"the\n> OpenStack product\" (markmc) \n\nRandom thought on this ...\n\nIf one of the release deliverables was e.g. a openstack.org/havana page\nwhich included links to the tarballs of the server projects, the same\nfor the client and oslo libs, and also links to the docs ... then that\ncould be the definition of our \"product\".\n\nThe difficulty, of course, is that it\'s not actually all that useful as\na starting point for users. Does anyone install the tarballs directly?\nSo we\'d need to make it clear that this is about documenting what\'s in\nthe official OpenStack release rather than a starting page for users.\n\nCheers,\nMark.\n\n\n\n','<51CADB6A.7020905@openstack.org>',NULL),('<1372260459.3446.165.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 10:27:39',-18000,'2013-06-26 15:27:39',NULL,'[openstack-dev] [Nova] Nominating John Garbutt for nova-core','On Wed, 2013-06-26 at 11:09 -0400, Russell Bryant wrote:\n> I would like to nominate John Garbutt for the nova-core team.\n\n+1\n\n> John has been involved with nova for a long time now.  He\'s primarily\n> known for his great work on the xenapi driver.  However, he has been\n> contributing and reviewing in other areas, as well.  Based on my\n> experience with him I think he would be a good addition, so it would be\n> great to have him on board to help keep up with the review load.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51CB042E.5080802@redhat.com>',NULL),('<1372265852.134411333@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-06-26 11:57:32',-18000,'2013-06-26 16:57:32',NULL,'[openstack-community] Inquiring about interest in Partner Pavilion\n	at Cloud Expo Europe Feb 26-27, 2014 in London','\n\nWe\'re holding a very good, central, large space at the subject event for an OpenStack Pavilion, similar to what we are doing at OSCON (July 22-26, Portland) and Gartner Data Center Conference (Dec 9-12, Las Vegas - spaces still available!).  The venue is ExCeL, which is close to the Canary Wharf financial/business district and easily accessible via public transportation.\n \nTwo members have expressed interest to date (StackOps and Canonical).  We don\'t have a cost to participate yet; European shows are more expensive than in the US.  I expect it to be approximately in the range of $5,000 - 8,000 US.\n \nPlease let me know if your firm is interested by early next week.  This is not a commitment but will give me an idea on how much space to confirm.  If you have your own presence at this event, priority will be given to those which do not.  Thank you.\n -- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130626/b0c757d2/attachment.html>\n\n',NULL,NULL),('<1372332252.16347.YahooMailNeo@web126201.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-27 04:24:12',-25200,'2013-06-27 11:24:12',NULL,'[openstack-dev] CFP: IJDSN Special Issue on Emerging Sensor-Cloud\n	Technology for Pervasive Services and Applications','\n[Apologies in advance, if you receive multiple copies of this CFP due to cross-posting]\n \n\nInternational Journal of Distributed Sensor Networks\nSpecial Issue on Emerging Sensor-Cloud Technology for Pervasive Services and Applications\n\nURL: http://www.hindawi.com/journals/ijdsn/si/161297/cfp/\n\n\nCall for Papers\n\nWith the recent advancement of low-power wireless communication and \nmobile computing, the wireless sensor networks (WSNs) paradigm has \nbecome an integral part of our daily lives. However, the \nresource-constrained features of WSNs in terms of memory, computation,\nenergy, communication, mobility, and scalability hinder the large-scale \ndeployment of WSNs. The emergence of cloud computing is seen as an \nenabling technology to solve many of these constraints. WSN, when \nintegrates with cloud, is considered as a sensor-cloud\ntechnology, which can effectively collect, process, store, and analyze \nreal-time data feeds from heterogeneous WSNs and provide quality of \nservice (QoS) provisioning for different community and context-centric \nsensing applications. The sensor cloud leverages\nscalable, on-demand, and powerful storage and processing infrastructure \nof cloud to support complete sensor data life cycle and provides \nubiquitous access of these data to users at lower costs. Despite the \nhuge potential of sensor cloud, it is currently being\nused at a limited scale in different applications. As this technology is\n emerging, many research opportunities have just started to unveil.This \nspecial issue invites high-quality unpublished research articles \narticulating new perspectives highlights, open issues,\nand challenges for the large-scale adoption of sensor cloud for \npervasive services and applications. In particular, it aims to present \nthe most recent achievements in sensor-cloud domain and envisions future\n directions. Potential topics include, but are not\nlimited to:\n\n- Complex real-time event processing? and management in sensor cloud\n- Efficient information dissemination mechanisms in sensor cloud\n- QoS and QoI (quality of information)? improvements for sensor cloud\n- Power-efficient MAC and routing protocols for sensor cloud\n- Dynamic resource allocation algorithms for sensor cloud\n- Collaborative multimedia sensing in sensor-cloud paradigm\n- Fault tolerance, reliability, and resiliency\n- Data mining techniques for sensor cloud\n- Social network data fusion in sensor cloud\n- Energy-efficient sensor-cloud system\n- Security and privacy in sensor-cloud paradigm\n- Sensor-cloud-based surveillance system\n- Cloud-based WBAN for pervasive applications\n\n\nSubmission Guidelines\n\n\nBefore submission authors should carefully read over the journal?s Author Guidelines, which are located at http://www.hindawi.com/journals/ijdsn/guidelines/. Prospective authors\nshould submit an electronic copy of their complete manuscript through the journal Manuscript Tracking System at http://mts.hindawi.com/submit/journals/ijdsn/sct/ according to the\nfollowing timetable:\n\nImportant Dates\n \n\nManuscript Due: Friday, 4 October 2013\nFirst Round of Reviews: Friday, 27 December 2013\nPublication Date: Friday, 21 February 2014\n\nLead Guest Editor\n\nMohammad Mehedi Hassan, \nDepartment of Information Systems College of Computer and Information Sciences, King Saud University, Riyadh, Saudi Arabia\nmmhassan at ksu.edu.sa\n\nGuest Editors\n\nAl-Sakib Khan Pathan, \nFaculty of Information and Communication Technology, International Islamic University Malaysia, Kuala Lumpur, Malaysia\n\nsakib.pathan at gmail.com\n\nEui-Nam Huh, \nDepartment of Computer Engineering, Kyung Hee University, Suwon, Republic of Korea\njohnhuh at khu.ac.kr\n\nJemal Abawajy, \nSchool of Information Technology, Deakin University, Australia\njemal.abawajy at deakin.edu.au\n?\n===========================\nMohammad Mehedi Hassan, PhD\nAssistant Professor\nInformation Systems Department\nCollege of Computer and Information Sciences\nChair of Pervasive and Mobile Computing\nKing Saud University, Riyadh, KSA\nEmail: mmhassan at ksu.edu.sa, mehedi at ieee.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130627/68edfeb1/attachment.html>\n\n',NULL,NULL),('<1372375734.16573.120.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-28 09:28:54',36000,'2013-06-27 23:28:54',NULL,'[openstack-dev] Http library usage by clients','On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:\n> On 27 June 2013 04:55, Adam Young <ayoung at redhat.com> wrote:\n> > Right now Keystone provides so called bearer tokens: This means that whoever\n> > has a token can do whatever the token entitles him to do. If I\n> > manage to get somebody\'s token I can do whatever this person is able to do.\n> > To fix it, the other services that use tokens to:\n> >\n> > 1. Authenticate the identity\n> > 2. Match the name in the token to the  identity that authenticated the\n> > connection.\n> \n> I am confused: HTTP is a message orientated protocol, connection based\n> authentication is a terrible antipattern. Do you really mean\n> \'connection\' here?\n\nMore the HTTPs handshake i guess, the point is to have for example a\nclient certificate or kerberos identity that is used to connect to the\nindividual servers.\n\nWhen a token is generated from keystone we put into the token a\nreference to the kerberos or cert that was used to generate the token,\nthen when this token is used on a server the auth_token middleware\nensures that the same kerberos principal or certificate is used to make\nthat connection as made the original. That means even if you get the\ntoken unless you have the cert/kerberos id you can\'t use it. \n\nThe full blueprint is:\nhttps://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token\n\n> > If the names match then you can be sure that the user that connected to the\n> > service and presented a token is the same user that acquired the token from\n> > keystone in the first place.\n> \n> That would prevent the use case of \'create a token and hand it off\'\n> which AIUI Heat depends on/will depend on.\n\nYes it would, but this is where heat would need to make use of the\ntrusts mechanism that was released with Grizzly, something that i\nunderstand is planned anyway. \n\n> > To make this happen we need to add authentication to the connections between\n> > clients and services.\n> \n> Again, if you mean actual TCP Connection here then this design is deeply flawed.\n> \n> Whats the actual problem we\'re trying to solve (vs this proposed solution).\n> \n> -Rob\n> \n\n\n\n\n\n','<CAJ3HoZ2ZbHuCFD95y-wKY3c-NQC46wN7oweCZdEPBjOUhe+k8g@mail.gmail.com>',NULL),('<1372376222.16573.124.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-28 09:37:02',36000,'2013-06-27 23:37:02',NULL,'[openstack-dev] Http library usage by clients','On Thu, 2013-06-27 at 11:39 -0400, Jay Pipes wrote:\n> On 06/26/2013 12:55 PM, Adam Young wrote:\n> > Glance:\n> > - Uses httplib for communication\n> > - Uses keystoneclient within cli\n> > - Checks that socket is patched before importing eventlet for httplib.\n> \n> For the record, Glance uses httplib, not httplib2, for its \n> request/response handling because httplib2 does not support \n> chunked-transfer encoding. This is the same reason that Swift\'s client \n> and server communication uses the httplib library over httplib2 -- it\'s \n> kind of important when you have multi-GB file transfers ;)\n> \n> I note that the requests library supports chunked transfer:\n> \n> http://docs.python-requests.org/en/latest/user/advanced.html#chunk-encoded-requests\n> \n> Might be time for the Glance developers to consider switching out \n> httplib for requests?\n> \n> I noticed that the original email did not include Swift. Is there a \n> reason for not including it?\n\nNope, complete oversight: \n\nSwift: \n- Uses keystoneclient within swiftclient library\n- Uses httplib\n- Uses eventlet for https connections if socket is patched.\n\n> All the best,\n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<51CC5CA5.7040701@gmail.com>',NULL),('<1372377296.16573.139.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-28 09:54:56',36000,'2013-06-27 23:54:56',NULL,'[openstack-dev] Http library usage by clients','On Thu, 2013-06-27 at 16:35 +0200, Thierry Carrez wrote:\n> Adam Young wrote:\n> > Right now Keystone provides so called bearer tokens: This means that whoever has a token can do whatever the token entitles him to do. If I\n> > manage to get somebody\'s token I can do whatever this person is able to do.\n> \n> Right. Tokens are considered secrets for that reason.\n> \n> > To fix it, the other services that use tokens to:\n> > \n> > 1. Authenticate the identity\n> > 2. Match the name in the token to the  identity that authenticated the connection. \n> > \n> > If the names match then you can be sure that the user that connected to the service and presented a token is the same user that acquired the token from keystone in the first place.\n> \n> That sounds like an extra layer of security rather than a \"fix\" ?\n> \n> > To make this happen we need to add authentication to the connections between clients and services.  \n> > \n> > To be able to do that we need to \n> > 1. Enable multiple forms of authentication per client.  The best way to do this is to use a common client library, which we have developed in keystoneclient \n> > 2. Use the \'requests\' libraray for HTTP across all clients\n> > 3. Enable running the API servers in Apache HTTPD.  Making Eventlet support X509 CLient certs and Kerberos is going to be difficult, and the likelihood of introducing a security problem is high.\n> \n> Devil\'s advocate says: the key idea behind Keystone was to centralize\n> authentication, though. Doesn\'t this extra layer kind of defeat that ?\n> Why would you need tokens at all, with a strongly-authenticated\n> connection to the API servers ?\n\nNo, because the role of keystone is authentication and authorization.\nJust because you can securely connect to an API server does that mean\nyou are a valid user? It\'s a likely scenario that not everyone in an\norganization with a kerberos ID is going to actually have an account or\nany permissions in an openstack deployment. Also what roles and\npermission does the user have when they connect?\n\nWhen connecting to a strongly-authenticated server the server needs no\nknowledge of your ldap tree or user list, it simply needs to compare\nwhat it receives via kerberos or client cert with what keystone has\nvalidated and put in the token. This is also handled completely within\nthe auth_token middleware from keystoneclient and so will not be\nsomething that will impact development of other projects, but a security\nfeature that deployments may enable.\n\nIt will also always be an optional feature.\n\n> > [...]\n> > So this raises a couple of points. \n> > - We need to get Nova, Quantum and Cinder to use keystoneclient.\n> \n> I\'m actually surprised that they don\'t, so +1 :)\n> \n> > - Eventlet is mostly gone from the clients already. I\'m not sure how\n> > many of those http requests would end up actually blocking.\n> \n> +1\n> \n> > - It would appear that clients have all at some point taken a central\n> > layout approach and with it taken httplib. We probably can\'t get them\n> > all changed over to requests before we try to add kerberos.\n> \n> I\'m not sure they would be so opposed to the idea. Especially\n> considering the next point.\n> \n> > - There is already a number of concerns around the way we use https. By\n> > default httplib does not verify https certificates, requests does and\n> > provides global ways of setting the bundle.\n> > https://wiki.openstack.org/wiki/SecureClientConnections already\n> > advocates for the transfer to requests with some interesting examples\n> > like https://bugs.launchpad.net/python-glanceclient/+bug/1079692\n> > (Server\'s name isn\'t verified when using https)\n> \n> We definitely need a more consistent support of https rather than so\n> many different implementations that fail in so many different ways. FWIW\n> we\'d consider absence of server cert checking in Python client libraries\n> connections as a vulnerability, so please report as a security bug any\n> occurrence of that.\n> \n> Regards,\n> \n\n\n\n\n\n','<51CC4DCF.9010904@openstack.org>',NULL),('<1372387522.31944.7.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-27 22:45:22',-14400,'2013-06-28 02:45:22',NULL,'[openstack-dev] Http library usage by clients','On Thu, 2013-06-27 at 17:49 -0700, Clint Byrum wrote:\n> On 2013-06-27 16:28, Jamie Lennox wrote:\n> > On Fri, 2013-06-28 at 07:01 +1200, Robert Collins wrote:\n> >> On 27 June 2013 04:55, Adam Young <ayoung at redhat.com> wrote:\n> >>> Right now Keystone provides so called bearer tokens: This means that \n> >>> whoever\n> >>> has a token can do whatever the token entitles him to do. If I\n> >>> manage to get somebody\'s token I can do whatever this person is able \n> >>> to do.\n> >>> To fix it, the other services that use tokens to:\n> >>> \n> >>> 1. Authenticate the identity\n> >>> 2. Match the name in the token to the  identity that authenticated \n> >>> the\n> >>> connection.\n> >> \n> >> I am confused: HTTP is a message orientated protocol, connection \n> >> based\n> >> authentication is a terrible antipattern. Do you really mean\n> >> \'connection\' here?\n> > \n> > More the HTTPs handshake i guess, the point is to have for example a\n> > client certificate or kerberos identity that is used to connect to the\n> > individual servers.\n> > \n> > When a token is generated from keystone we put into the token a\n> > reference to the kerberos or cert that was used to generate the token,\n> > then when this token is used on a server the auth_token middleware\n> > ensures that the same kerberos principal or certificate is used to \n> > make\n> > that connection as made the original. That means even if you get the\n> > token unless you have the cert/kerberos id you can\'t use it.\n> > \n> > The full blueprint is:\n> > https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token\n> > \n> \n> So you need the cert/kerberos ticket to both create and use the token. \n> So this means you are really trying to solve the problem of us \n> transmitting whole tokens for each request, making them open to \n> interception during transmission or theft from backing storage.\n> \n> >>> If the names match then you can be sure that the user that connected \n> >>> to the\n> >>> service and presented a token is the same user that acquired the \n> >>> token from\n> >>> keystone in the first place.\n> >> \n> >> That would prevent the use case of \'create a token and hand it off\'\n> >> which AIUI Heat depends on/will depend on.\n> > \n> > Yes it would, but this is where heat would need to make use of the\n> > trusts mechanism that was released with Grizzly, something that i\n> > understand is planned anyway.\n> > \n> \n> Indeed it is. But right now, the most excellent \"make an EC2 keypair \n> and sign stuff with it\" scheme is working out pretty well. That scheme \n> at least eliminates the transmission vulnerability.\n\nUsing a private key to sign requests is certainly an option that is\ncertainly to be considered.\n\nIn order to do that thought it would be easier if all clients would use\nthe same http library and keystone client so that signing can also be\ndone mostly transparently to the clients by hooking into the http\nlibrary and signing the request before it is sent.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<e98ee46dc07c0caf97477f74657bed6e@secure.spamaps.org>',NULL),('<1372443879.76.1382422353853.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-22 06:12:33',0,'2013-10-22 06:12:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #47','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/47/>\n\n------------------------------------------\n[...truncated 1464 lines...]\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5b0da90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5b0da90>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55a9410>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55a9410>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-cfeb4b72-927d-44c4-82ab-dfe52710ab43\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x33057d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x33057d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x33057d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x33057d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2013-10-21T06:11:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'21\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:11:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:11:59+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:11:59-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:11:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x648f490>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1ea82d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 88.17 secs:\n    25.83    TestScrubber.test_scrubber_app\n    20.23    TestScrubber.test_delayed_delete\n    14.43    TestGlanceControl.test_reload\n    14.18    TestGlanceControl.test_respawn\n    13.51    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1109 tests in 588.563s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.47\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.7\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.IAMncr9QSC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/47/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise23\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise23/47\n[SCP] Copying console log.\n\n\n','<499774831.72.1382335961093.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1372521941.14525.36.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-06-29 17:05:41',3600,'2013-06-29 16:05:41',NULL,'[OpenStack Foundation] Board Meeting - June 27th','On Fri, 2013-06-28 at 07:10 -0500, Jonathan Bryce wrote:\n> Yesterday, the Foundation Board of Directors held another telephone\n> meeting. The agenda for the meeting can be found on the wiki:\n> https://wiki.openstack.org/wiki/Governance/Foundation/27June2013BoardMeeting\n\nThanks Jonathan, here\'s my notes from the meeting:\n\n  http://blogs.gnome.org/markmc/2013/06/29/june-27th-openstack-foundation-board-meeting/\n\nCheers,\nMark.\n\n\n\n','<B607621C-1028-459F-A28A-82D5492FF88A@openstack.org>',NULL),('<1372691028.2416.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 16:03:48',3600,'2013-07-01 15:03:48',NULL,'[openstack-dev] RFC: Basic definition of OpenStack Programs and\n first batch','Hey Thierry\n\nI actually didn\'t notice this go by last week, the other thread got all\nthe attention.\n\nOn Wed, 2013-06-26 at 14:51 +0200, Thierry Carrez wrote:\n> Hi everyone,\n> \n> Yesterday at the TC meeting we agreed that as a first step to\n> establishing programs, we should have a basic definition of them and\n> establish the first (undisputed) ones.\n> \n> We can solve harder questions (like if \"horizontal efforts\" should be a\n> program or a separate thing, or where each current official repo exactly\n> falls) as a second step.\n> \n> So here is my proposal for step 1:\n> \n> \"\"\"\n> \'OpenStack Programs\' are efforts which are essential to the completion\n> of our mission, but which do not produce deliverables included in the\n> common release of OpenStack \'integrated\' projects every 6 months, like\n> Projects do.\n\nHmm, this wasn\'t what I understood our direction to be.\n\nAnd maybe this highlights a subtle difference in thinking - as I see it,\nOslo absolutely is producing release deliverables. For example, in what\nway was oslo.config 1.1.0 *not* a part of the grizzly release?\n\nThe idea that documentation isn\'t a part of our releases seems a bit off\ntoo.\n\nThis distinction feels like it\'s based on an extremely constrained\ndefinition of what constitutes a release.\n\n> Programs can create any code repository and produce any deliverable\n> they deem necessary to achieve their goals.\n> \n> Programs are placed under the oversight of the Technical Committee, and\n> contributing to one of their code repositories grants you ATC status.\n> \n> Current efforts or teams which want to be recognized as an \'OpenStack\n> Program\' should place a request to the Technical Committee, including a\n> clear mission statement describing how they help the OpenStack general\n> mission and how that effort is essential to the completion of our\n> mission. Programs do not need to go through an Incubation period.\n> \n> The initial Programs are \'Documentation\', \'Infrastructure\', \'QA\' and\n> \'Oslo\'. Those programs should retroactively submit a mission statement\n> and initial lead designation, if they don\'t have one already.\n> \"\"\"\n> \n> This motion is expected to be discussed and voted at the next TC\n> meeting, so please comment on this thread.\n\nIt\'s funny, I think we\'re all fine with the idea of Programs but can\'t\nquite explain what distinguishes a program from a project, etc. and\nwe\'re reaching for things like \"programs don\'t produce release\ndeliverables\" or \"projects don\'t have multiple code repositories\". I\'m\nnervous of picking a distinguishing characteristic that will\nartificially limit what Programs can do.\n\nSay we go with the \"no release deliverables\" definition and, by\nextension, Oslo wasn\'t a program ... then what happens if the QA team\nwanted a start producing a release deliverable? Say, a test suite to\nvalidate that your Havana deployment isn\'t screwed up? Would they have\nto drop the \"program\" moniker?\n\nHow about we say the distinction is whether a project exposes a public\nREST API?\n\n  \'OpenStack Programs\' are efforts which are essential to the completion\n  of our mission. However, while they may produce release deliverables \n  which are included in our coordinated release every 6 months, \n  programs do not include projects which implement REST APIs intended to\n  be exposed to the users of OpenStack clouds. Such projects are known \n  as \'integrated\' projects and join our releases through the incubation \n  process.\n\nIn terms of the issue of integrated projects also producing client\nlibraries, that ties in nicely with the REST API distinction - if a\nproject is producing a server which exposes an API, of course it should\nalso produce a client for that API.\n\nCheers,\nMark.\n\n\n\n','<51CAE3EB.7030104@openstack.org>',NULL),('<1372691580.2416.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 16:13:00',3600,'2013-07-01 15:13:00',NULL,'[openstack-dev] [OSLO] Current DB status','(Oslo is not an acronym)\n\nOn Mon, 2013-07-01 at 18:07 +0300, Gary Kotton wrote:\n> Hi,\n> Can someone please clarify what the DB status is in OSLO. Last week the \n> code was imported to Neutron (aka Quantum). The review process is Nova \n> has been -1\'ed due to issues with the common code \n> (https://review.openstack.org/#/c/34671/).\n> What is the current status? Does the code need to be reverted from OSLO \n> if it is is problematic?\n\nAs you know, the DB code in Oslo requires latest oslo.config.\n\nLast week, we identify yet another issue with installing latest\noslo.config in a very specific situation:\n\n  https://bugs.launchpad.net/tripleo/+bug/1194807/comments/18\n\nBasically, it looks like \'pip install -r quantum/requirements.txt\' in a\nfresh venv *won\'t* get you latest oslo.config.\n\nIt looks like there may be a bug in pip itself and I\'m still\ninvestigating it.\n\nCheers,\nMark.\n\n\n\n','<51D19B41.6040004@redhat.com>',NULL),('<1372693783.2416.34.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 16:49:43',3600,'2013-07-01 15:49:43',NULL,'[openstack-dev] [OSLO] Current DB status','On Mon, 2013-07-01 at 18:32 +0300, Gary Kotton wrote:\n> On 07/01/2013 06:13 PM, Mark McLoughlin wrote:\n> > (Oslo is not an acronym)\n> \n> ok.\n> \n> can someone please clarify what the database status is in Oslo?\n\nWhat apart from the oslo.config issue do you want clarified?\n\nMark.\n\n\n\n','<51D1A11E.3010206@redhat.com>',NULL),('<1372694878.2416.38.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 17:07:58',3600,'2013-07-01 16:07:58',NULL,'[openstack-dev] [OSLO] Current DB status','On Mon, 2013-07-01 at 18:59 +0300, Gary Kotton wrote:\n> On 07/01/2013 06:49 PM, Mark McLoughlin wrote:\n> > On Mon, 2013-07-01 at 18:32 +0300, Gary Kotton wrote:\n> >> On 07/01/2013 06:13 PM, Mark McLoughlin wrote:\n> >>> (Oslo is not an acronym)\n> >> ok.\n> >>\n> >> can someone please clarify what the database status is in Oslo?\n> > What apart from the oslo.config issue do you want clarified?\n> \n> Boris had concerns about the slave database support. He mentioned that \n> the blueprint may be blocked - \n> https://blueprints.launchpad.net/nova/+spec/db-slave-handle. \n\nIt\'s blocked in the sense that Nova can\'t yet use oslo.config because of\nthe aforementioned issue.\n\n> This patch \n> updates to oslo.config-1.2.0a2 - so it may address the blueprints \n> blocking item.\n> \n> My concern here is about the process. I was under the assumption, and \n> may be wrong here, is that if code is approved in Oslo the is can be \n> consumed by other projects. Over the last few months we have had a large \n> amount of database issues in Neutron and moved to the Oslo DB code to \n> address these.\n\nYes, we\'ve had (and continue to have) problems - no project has been\nable to use new oslo.config features because of a series of python\npackaging related issues.\n\nIf you\'re suggesting that e.g. the DB code in oslo-incubator should\navoid requiring oslo-config-1.2.0, that wouldn\'t help quantum much since\nthe dependency on 1.2.0 was added in order to enable behaviour that\nquantum required.\n\nCheers,\nMark.\n\n\n\n','<51D1A764.8000508@redhat.com>',NULL),('<1372696425.2416.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 17:33:45',3600,'2013-07-01 16:33:45',NULL,'[openstack-dev] RFC: Basic definition of OpenStack Programs and\n first batch','On Mon, 2013-07-01 at 09:12 -0700, Monty Taylor wrote:\n\n> So I think that tying a definition directly to whether or not there is a\n> release artifact or when that gets produced is missing the point and\n> wrong. The point is that there are _efforts_ that we want to address,\n> and those efforts may not have a clear cut simple \"main\" source code\n> repository.\n\nI assume by \"a definition\", you mean \"a definition of what programs are\"\nrather than \"the mission statement of a particular program\".\n\nIf so, then yeah - \"efforts that don\'t have release deliverables\" isn\'t\nthe distinguishing characteristic of programs IMHO.\n\nHowever, I do think it\'s a good thing for programs\' mission statements\nto discuss their release deliverables. Otherwise the mission statement\nrisks being completely vague. If a program wanted to significantly\nchange its intentions wrt release deliverables, it should bring an\nupdated mission statement to the TC.\n\nIf we don\'t want server projects to be programs, then the distinguishing\ncharacteristic of programs is that they\'re not server projects :)\n\nIf we do want server projects to be programs, then \"program\" is an\nall-encompassing term for all of our distinct efforts.\n\nCheers,\nMark.\n\n\n\n','<51D1AA60.7000504@inaugust.com>',NULL),('<1372696525.2416.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 17:35:25',3600,'2013-07-01 16:35:25',NULL,'[openstack-dev] [OSLO] Current DB status','On Mon, 2013-07-01 at 19:33 +0300, Gary Kotton wrote:\n> On 07/01/2013 07:07 PM, Mark McLoughlin wrote:\n> > On Mon, 2013-07-01 at 18:59 +0300, Gary Kotton wrote:\n> >> On 07/01/2013 06:49 PM, Mark McLoughlin wrote:\n> >>> On Mon, 2013-07-01 at 18:32 +0300, Gary Kotton wrote:\n> >>>> On 07/01/2013 06:13 PM, Mark McLoughlin wrote:\n> >>>>> (Oslo is not an acronym)\n> >>>> ok.\n> >>>>\n> >>>> can someone please clarify what the database status is in Oslo?\n> >>> What apart from the oslo.config issue do you want clarified?\n> >> Boris had concerns about the slave database support. He mentioned that\n> >> the blueprint may be blocked -\n> >> https://blueprints.launchpad.net/nova/+spec/db-slave-handle.\n> > It\'s blocked in the sense that Nova can\'t yet use oslo.config because of\n> > the aforementioned issue.\n> >\n> >> This patch\n> >> updates to oslo.config-1.2.0a2 - so it may address the blueprints\n> >> blocking item.\n> >>\n> >> My concern here is about the process. I was under the assumption, and\n> >> may be wrong here, is that if code is approved in Oslo the is can be\n> >> consumed by other projects. Over the last few months we have had a large\n> >> amount of database issues in Neutron and moved to the Oslo DB code to\n> >> address these.\n> > Yes, we\'ve had (and continue to have) problems - no project has been\n> > able to use new oslo.config features because of a series of python\n> > packaging related issues.\n> >\n> > If you\'re suggesting that e.g. the DB code in oslo-incubator should\n> > avoid requiring oslo-config-1.2.0, that wouldn\'t help quantum much since\n> > the dependency on 1.2.0 was added in order to enable behaviour that\n> > quantum required.\n> \n> The Oslo DB code requires oslo.config-1.2.0a2. This config version has \n> supported for \'deprecated_opts\' - which enabled the common DB code to \n> support Neutron and Nova DB configuration variables.\n> \n> I was not aware that that the slave blueprint was blocked because it was \n> waiting for a specific config version (hopefully the Nova DB patch deals \n> with as it uses the required config). My concern was that Oslo code was \n> approved in one project (Neutron) and in another it raises question \n> (Nova). Basically it would be nice to know if there are issues with the \n> Oslo DB support and if so what needs to be done to address them.\n\nThe blueprint says:\n\n  https://blueprints.launchpad.net/nova/+spec/db-slave-handle\n\n  \"This is blocked until we can get oslo.config 1.2.0a2 into nova. \n   Currently it breaks unit tests when you run with tox.\"\n\nWhich is the same issue as the one described here:\n\n  https://bugs.launchpad.net/oslo/+bug/1194807\n\nCheers,\nMark.\n\n\n\n','<51D1AF4D.7060205@redhat.com>',NULL),('<1372700105-sup-1563@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 10:35:24',-25200,'2013-07-01 17:35:24',NULL,'[openstack-dev] [Keystone] Best way to do something MySQL-specific?','The way the new keystone-manage command \"token_flush\" works right now\nis quite broken by MySQL and InnoDB\'s gap locking behavior:\n\nhttps://bugs.launchpad.net/1188378\n\nPresumably other SQL databases like PostgreSQL will have similar problems\nwith doing massive deletes, but I am less familiar with them.\n\nI am trying to solve this in keystone, and my first attempt is here:\n\nhttps://review.openstack.org/#/c/32044/\n\nHowever, MySQL does not support using \"LIMIT\" in a sub-query that\nis feeding an IN() clause, so that approach will not work. Likewise,\nsqlalchemy does not support the MySQL specific extension to DELETE which\nallows it to have a LIMIT clause.\n\nNow, I can do some hacky things, like just deleting all of the expired\ntokens from the oldest single second, but that could also potentially\nbe millions of tokens, and thus, millions of gaps to lock.\n\nSo, there is just not one way to work for all databases, and we have to\nhave a special mode for MySQL.\n\nI was wondering if anybody has suggestions and/or examples of how to do\nthat with sqlalchemy.\n\n\n',NULL,NULL),('<1372706386.2416.52.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 20:19:46',3600,'2013-07-01 19:19:46',NULL,'[openstack-dev] RFC: Basic definition of OpenStack Programs and\n first batch','On Mon, 2013-07-01 at 18:46 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> >> \"\"\"\n> >> \'OpenStack Programs\' are efforts which are essential to the completion\n> >> of our mission, but which do not produce deliverables included in the\n> >> common release of OpenStack \'integrated\' projects every 6 months, like\n> >> Projects do.\n> > \n> > Hmm, this wasn\'t what I understood our direction to be.\n> > \n> > And maybe this highlights a subtle difference in thinking - as I see it,\n> > Oslo absolutely is producing release deliverables. For example, in what\n> > way was oslo.config 1.1.0 *not* a part of the grizzly release?\n> > \n> > The idea that documentation isn\'t a part of our releases seems a bit off\n> > too.\n> \n> I suspect what I call \"common release of OpenStack \'integrated\' projects\n> every 6 months\" is what you call \"server projects\" later in the thread.\n> \n> We publish a number of things, and a subset of them (which I call \"the\n> integrated release\") are released together every 6 months. Oslo\n> libraries are also released, but on a different cadence. Docs are\n> released, usually with a slight delay. I call those \"deliverables\", to\n> avoid confusion with the first set...\n> \n> I think we are on the same line, just not using the term \"release\" for\n> the same thing ?\n\nOslo libraries and docs are very much on the same cadence - as in the\ntrue meaning of the word, \"rhythm\". The fact that, for process reasons,\noslo libraries get released a little before the server releases and, for\npragmatic reasons, docs get released a little after the server releases\nchanges little in my mind - everyone\'s working in the same cycle to\nproduce a single, integrated OpenStack product.\n\nCheers,\nMark.\n\n\n\n','<51D1B269.2030405@openstack.org>',NULL),('<1372706791.2416.57.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 20:26:31',3600,'2013-07-01 19:26:31',NULL,'[openstack-dev] RFC: Basic definition of OpenStack Programs and\n first batch','On Mon, 2013-07-01 at 18:41 +0200, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > So I think that tying a definition directly to whether or not there is a\n> > release artifact or when that gets produced is missing the point and\n> > wrong. The point is that there are _efforts_ that we want to address,\n> > and those efforts may not have a clear cut simple \"main\" source code\n> > repository.\n> \n> I can certainly agree that all those things are efforts which may or may\n> not produce stuff that may or may not be part of the \"integrated\" subset\n> of the things we end up publishing.\n> \n> The two reason why I was trying to draw a line in the sand between\n> \"Projects\" and \"Programs\" was that:\n> \n> (1) \"Projects\" are mentioned in the TC charter (and the foundation\n> bylaws), so they are not going away easily.. hence me trying to preserve\n> them while introducing Programs\n\nAh, interesting - if I had thought about it, I would have presumed that\npretty much all the verbiage in the TC charter would apply equally to\nprograms.\n\n> (2) \"Projects\" go through Incubation, while \"Programs\" don\'t need any\n> incubation period. (They go through incubation because they are part of\n> the \"integrated release\", which is not everything we release, but the\n> subset of stuff we publish on a 6-month release cadence. They go through\n> incubation so that we can make sure their addition will not screw up\n> existing \"integrated\" projects and they are actually \"integrated\" with\n> the other projects. They go through incubation so that we can make sure\n> they can fit in the stable maintenance, vulnerability management and\n> release management processes.)\n\nOslo libraries have plenty of opportunity to screw everything else too\nand needs as much release management as everything else. So, that\ndistinction doesn\'t really make much sense.\n\nThe \"exposes a user-facing REST API\" distinction is enough to explain\nthe need for Incubation ... for now, at least.\n\nCheers,\nMark.\n\n\n\n','<51D1B151.2040704@openstack.org>',NULL),('<1372714386-sup-3152@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 14:52:34',-25200,'2013-07-01 21:52:34',NULL,'[openstack-dev] [oslo.config] Config files overriding CLI: The path\n	of most surprise.','Last week I went to use oslo.config in a utility I am writing called\nos-collect-config[1]...\n\nWhile running unit tests on the main() method that is used for the CLI,\nI was surprised to find that my unit tests were picking up values from\na config file I had created just as a test. The tests can be fixed to\ndisable config file lookups, but what was more troublesome was that the\nconfig file was overriding values I was passing in as sys.argv.\n\nI have read the thread[2] which suggest that CLI should defer to config\nfile because config files are somehow less permanent than the CLI.\n\nI am writing today to challenge that notion, and also to suggest that even\nif that is the case, it is inappropriate to have oslo.config operate in\nsuch a profoundly different manner than basically any other config library\nor system software in general use. CLI options are _for config files_\nand if packagers are shipping configurations in systemd unit files,\nupstart jobs, or sysvinits, they are doing so to control the concerns\nof that particular invocation of whatever command they are running,\nand not to configure the software entirely.\n\nCLI args are by definition ephemeral, even if somebody might make them\n\"permanent\" in their system, I doubt any packager would then expect that\nthese CLI args would be overridden by any config files. This default is\njust wrong, and needs to be fixed.\n\n[1] https://github.com/SpamapS/os-collect-config.git\n[2] http://lists.openstack.org/pipermail/openstack-dev/2013-May/008691.html\n\nClint Byrum\nHP Cloud Services\n\n\n',NULL,NULL),('<1372716771.2416.95.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 23:12:51',3600,'2013-07-01 22:12:51',NULL,'[openstack-dev] [oslo.config] Config files overriding CLI: The\n path of most surprise.','On Mon, 2013-07-01 at 14:52 -0700, Clint Byrum wrote:\n> Last week I went to use oslo.config in a utility I am writing called\n> os-collect-config[1]...\n> \n> While running unit tests on the main() method that is used for the CLI,\n> I was surprised to find that my unit tests were picking up values from\n> a config file I had created just as a test. The tests can be fixed to\n> disable config file lookups, but what was more troublesome was that the\n> config file was overriding values I was passing in as sys.argv.\n> \n> I have read the thread[2] which suggest that CLI should defer to config\n> file because config files are somehow less permanent than the CLI.\n> \n> I am writing today to challenge that notion, and also to suggest that even\n> if that is the case, it is inappropriate to have oslo.config operate in\n> such a profoundly different manner than basically any other config library\n> or system software in general use. CLI options are _for config files_\n> and if packagers are shipping configurations in systemd unit files,\n> upstart jobs, or sysvinits, they are doing so to control the concerns\n> of that particular invocation of whatever command they are running,\n> and not to configure the software entirely.\n> \n> CLI args are by definition ephemeral, even if somebody might make them\n> \"permanent\" in their system, I doubt any packager would then expect that\n> these CLI args would be overridden by any config files. This default is\n> just wrong, and needs to be fixed.\n\nHave you seen this?\n\n  https://review.openstack.org/#/c/29459/\n\nMark.\n\n> \n> [1] https://github.com/SpamapS/os-collect-config.git\n> [2] http://lists.openstack.org/pipermail/openstack-dev/2013-May/008691.html\n> \n> Clint Byrum\n> HP Cloud Services\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1372714386-sup-3152@fewbar.com>',NULL),('<1372722578.16573.164.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 09:49:38',36000,'2013-07-01 23:49:38',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:\n> Hi folks\n> \n> I\'m interested in it too.\n> I\'m working on VPN support for Neutron.\n> Public key authentication is one of feature milestone in the IPsec\n> implementation.\n> But I believe key-pair management api and the implementation will be\n> quite similar in Key for IPsec and Nova.\n> \n> so I\'m +1 for moving key management for Keystone.\n> \n> Best\n> Nachi\n\nI don\'t know how nova\'s keypair management works but i assume we are\ntalking about keys for ssh-ing into new virtual machines rather than\nkeys for authentication against nova.\n\nKeystone\'s v3 api has credentials storage (see\nhttps://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md ), is this sufficient on behalf of keystone? There is some support in the current master of keystoneclient for working with these credentials.\n\nOtherwise would the upcoming barbican be a more appropriate place?\n\nIf i\'ve got this wrong and we are using these keys to actually\nauthenticate against nova then if someone can point me to the code i\'ll\nsee how hard it is to transfer to keystone.\n\n> \n> \n> 2013/7/1 Thierry Carrez <thierry at openstack.org>:\n> > Russell Bryant wrote:\n> >> On 07/01/2013 01:10 PM, Jay Pipes wrote:\n> >>> On 07/01/2013 12:23 PM, Mauro S M Rodrigues wrote:\n> >>>> +1.. make sense to me, I always thought that was weird hehe\n> >>>> Say the word and we will remove it from v3.\n> >>>\n> >>> Well, it\'s not weird, per-se... I mean I understand why it is the way it\n> >>> is. Nova, of course, preceded Keystone.\n> >>>\n> >>> But, it sounds like this would be something to put on the Icehouse\n> >>> horizon? Can the Nova and Keystone PTLs comment if there is interest in\n> >>> this?\n> >>\n> >> There is interest from me.  Dolph?\n> >\n> > Dolph is not around this week, so the answer may take a while :)\n> >\n> > --\n> > Thierry Carrez (ttx)\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CABJepwjysA-F9Kgh0fxZpKhAmnYU0Lf3TFTf9wuB_1KFCsPD8g@mail.gmail.com>',NULL),('<1372726138036.42e5d05d@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-01 17:48:59',-25200,'2013-07-02 00:48:59',NULL,'[openstack-dev] [nova] Nova API extensions NOT to be ported to\n v3','On Tue, Jul 2, 2013 at 1:44 AM, Anne Gentle <annegentle at justwriteclick.com=\"mailto:annegentle at justwriteclick.com\">> wrote:\n\nIt\'s pretty rare to assign a doc team person to an API spec, typically the PTL works on it. We do have Diane Fleming on the doc team for API work and she\'s super knowledgeable and helpful. I have her working with Keystone team on their v3 right now, possibly we can have her help you as well if we plan and scope the work. Or you can identify someone with the right knowledge. Let\'s talk more at the meeting on?Tuesday July 9, 2013, 1300 UTC.\n\n\n\n\n\n\n\n\n\n\n\n?\n?I\'ll be there. Thanks!\n\n\n?\n?Chris\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130701/b45be60f/attachment.html>\n\n','<CAD0KtVE4vmVy0bgEc8VrWUJw25Vad2_bXm0uexuT=dsBF9Akyg@mail.gmail.com>',NULL),('<1372733959.16573.176.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 12:59:19',36000,'2013-07-02 02:59:19',NULL,'[openstack-dev] [Openstack] Keystone store-quota-data blueprint','On Tue, 2013-07-02 at 02:03 +0000, Everett Toews wrote:\n> This topic came up at the last summit in Portland at [1] and [2].\n> \n> \n> Yehia and another colleague of his from HP had a design that was\n> discussed and it seemed like they were going to start work on it.\n> Another developer from CERN expressed interest too. I\'m not sure if\n> anything ever really got started on it.\n> \n> \n> I think you\'ll want to wait until Dolph gets back (next week?) before\n> doing any major work on it. Ask him before moving forward.\n\nAlso know that Dolph has said that nothing that affects the API will be\naccepted after h-2 so it would have to be finished, reviewed and\ncommited by the 16th. Given that he\'s away and the discussion that would\nbe around this I\'d say it\'s very tight. \n\n\n> Regards,\n> Everett\n> \n> \n> [1] http://openstacksummitapril2013.sched.org/event/c0c6befcb4361e54d5c7e45b2f772de7\n> [2] http://openstacksummitapril2013.sched.org/event/7bf2cdde2dfad733b499d9c2a3f60b08\n> \n> \n> P.S. This email really belongs in openstack-dev\n> \n> On Jul 1, 2013, at 10:24 AM, Dmitry Stepanenko wrote:\n> \n> > Hi folks,\n> > \n> > \n> > we\'re going to work on store-quota-data blueprint\n> > (https://blueprints.launchpad.net/keystone/+spec/store-quota-data).\n> > Did anyone already work on it?\n> > \n> > \n> > Thanks & regards,\n> > Dmitry\n> > _______________________________________________\n> > Mailing list: https://launchpad.net/~openstack\n> > Post to     : openstack at lists.launchpad.net\n> > Unsubscribe : https://launchpad.net/~openstack\n> > More help   : https://help.launchpad.net/ListHelp\n> \n> _______________________________________________\n> Mailing list: https://launchpad.net/~openstack\n> Post to     : openstack at lists.launchpad.net\n> Unsubscribe : https://launchpad.net/~openstack\n> More help   : https://help.launchpad.net/ListHelp\n\n\n\n\n\n','<0C7DE9B4-750C-4AE8-A7A8-3FB29A135841@rackspace.com>',NULL),('<1372749556-sup-4260@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 00:24:55',-25200,'2013-07-02 07:24:55',NULL,'[openstack-dev] [oslo.config] Config files overriding CLI: The\n	path of most surprise.','Excerpts from Mark McLoughlin\'s message of 2013-07-01 15:12:51 -0700:\n> On Mon, 2013-07-01 at 14:52 -0700, Clint Byrum wrote:\n> > Last week I went to use oslo.config in a utility I am writing called\n> > os-collect-config[1]...\n> > \n> > While running unit tests on the main() method that is used for the CLI,\n> > I was surprised to find that my unit tests were picking up values from\n> > a config file I had created just as a test. The tests can be fixed to\n> > disable config file lookups, but what was more troublesome was that the\n> > config file was overriding values I was passing in as sys.argv.\n> > \n> > I have read the thread[2] which suggest that CLI should defer to config\n> > file because config files are somehow less permanent than the CLI.\n> > \n> > I am writing today to challenge that notion, and also to suggest that even\n> > if that is the case, it is inappropriate to have oslo.config operate in\n> > such a profoundly different manner than basically any other config library\n> > or system software in general use. CLI options are _for config files_\n> > and if packagers are shipping configurations in systemd unit files,\n> > upstart jobs, or sysvinits, they are doing so to control the concerns\n> > of that particular invocation of whatever command they are running,\n> > and not to configure the software entirely.\n> > \n> > CLI args are by definition ephemeral, even if somebody might make them\n> > \"permanent\" in their system, I doubt any packager would then expect that\n> > these CLI args would be overridden by any config files. This default is\n> > just wrong, and needs to be fixed.\n> \n> Have you seen this?\n> \n>   https://review.openstack.org/#/c/29459/\n> \n\nI had not, but this only provides a workaround, I think. If I read\nit right, it means I have to specify --config-file to change the\nprecedence. So running:\n\n\'program --config-file /etc/program/program.conf --foo\'\n\nis different than\n\n\'program --foo --config-file /etc/program/program.conf\'\n\nRight?\n\nThis is a passable workaround, but it doesn\'t change the fact that\nthe default behavior is to read the config files last if they are not\nspecified on the command line.\n\n\n','<1372716771.2416.95.camel@sorcha>',NULL),('<1372751509.2416.98.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 08:51:49',3600,'2013-07-02 07:51:49',NULL,'[openstack-dev] [oslo.config] Config files overriding CLI: The\n path of most surprise.','On Tue, 2013-07-02 at 00:24 -0700, Clint Byrum wrote:\n> Excerpts from Mark McLoughlin\'s message of 2013-07-01 15:12:51 -0700:\n> > On Mon, 2013-07-01 at 14:52 -0700, Clint Byrum wrote:\n> > > Last week I went to use oslo.config in a utility I am writing called\n> > > os-collect-config[1]...\n> > > \n> > > While running unit tests on the main() method that is used for the CLI,\n> > > I was surprised to find that my unit tests were picking up values from\n> > > a config file I had created just as a test. The tests can be fixed to\n> > > disable config file lookups, but what was more troublesome was that the\n> > > config file was overriding values I was passing in as sys.argv.\n> > > \n> > > I have read the thread[2] which suggest that CLI should defer to config\n> > > file because config files are somehow less permanent than the CLI.\n> > > \n> > > I am writing today to challenge that notion, and also to suggest that even\n> > > if that is the case, it is inappropriate to have oslo.config operate in\n> > > such a profoundly different manner than basically any other config library\n> > > or system software in general use. CLI options are _for config files_\n> > > and if packagers are shipping configurations in systemd unit files,\n> > > upstart jobs, or sysvinits, they are doing so to control the concerns\n> > > of that particular invocation of whatever command they are running,\n> > > and not to configure the software entirely.\n> > > \n> > > CLI args are by definition ephemeral, even if somebody might make them\n> > > \"permanent\" in their system, I doubt any packager would then expect that\n> > > these CLI args would be overridden by any config files. This default is\n> > > just wrong, and needs to be fixed.\n> > \n> > Have you seen this?\n> > \n> >   https://review.openstack.org/#/c/29459/\n> > \n> \n> I had not, but this only provides a workaround, I think. If I read\n> it right, it means I have to specify --config-file to change the\n> precedence. So running:\n> \n> \'program --config-file /etc/program/program.conf --foo\'\n> \n> is different than\n> \n> \'program --foo --config-file /etc/program/program.conf\'\n> \n> Right?\n\nThat\'s correct, yes.\n\n> This is a passable workaround, but it doesn\'t change the fact that\n> the default behavior is to read the config files last if they are not\n> specified on the command line.\n\nNope, config files are read first:\n\n $> cat t.py\n from oslo.config import cfg\n\n cfg.CONF.register_cli_opt(cfg.BoolOpt(\'debug\'))\n cfg.CONF(prog=\'t\')\n\n print cfg.CONF.config_file, cfg.CONF.debug\n\n $> cat ~/t.conf \n [DEFAULT]\n debug = True\n $> python t.py\n [\'/home/markmc/t.conf\'] True\n $> python t.py --nodebug\n [\'/home/markmc/t.conf\'] False\n\nCheers,\nMark.\n\n\n\n','<1372749556-sup-4260@fewbar.com>',NULL),('<1372752791.2416.102.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 09:13:11',3600,'2013-07-02 08:13:11',NULL,'[openstack-dev] [horizon] Removing the .mo files from Horizon\n git','On Tue, 2013-07-02 at 09:58 +0200, Thierry Carrez wrote:\n> Thomas Goirand wrote:\n> > So, shouldn\'t the .mo files be generated at build time only, and be kept\n> > out of the Git?\n> \n> +1\n\nYep, agree too.\n\nInterestingly, last time I checked, devstack doesn\'t actually compile\nthe message catalogs (python setup.py compile_catalog).\n\nI\'ve been meaning to fix that for a while now, but it\'s fallen by the\nwayside. I\'ve unassigned myself from the bug for now:\n\n  https://bugs.launchpad.net/devstack/+bug/995287\n\nCheers,\nMark.\n\n\n\n','<51D2883D.6050101@openstack.org>',NULL),('<1372768004.30537.3.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 08:26:44',-14400,'2013-07-02 12:26:44',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','On Mon, 2013-07-01 at 21:03 -0400, Jay Pipes wrote:\n> On 07/01/2013 07:49 PM, Jamie Lennox wrote:\n> > On Mon, 2013-07-01 at 14:09 -0700, Nachi Ueno wrote:\n> >> Hi folks\n> >>\n> >> I\'m interested in it too.\n> >> I\'m working on VPN support for Neutron.\n> >> Public key authentication is one of feature milestone in the IPsec\n> >> implementation.\n> >> But I believe key-pair management api and the implementation will be\n> >> quite similar in Key for IPsec and Nova.\n> >>\n> >> so I\'m +1 for moving key management for Keystone.\n> >>\n> >> Best\n> >> Nachi\n> >\n> > I don\'t know how nova\'s keypair management works but i assume we are\n> > talking about keys for ssh-ing into new virtual machines rather than\n> > keys for authentication against nova.\n> >\n> > Keystone\'s v3 api has credentials storage (see\n> > https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md ), is this sufficient on behalf of keystone? There is some support in the current master of keystoneclient for working with these credentials.\n> >\n> > Otherwise would the upcoming barbican be a more appropriate place?\n> >\n> > If i\'ve got this wrong and we are using these keys to actually\n> > authenticate against nova then if someone can point me to the code i\'ll\n> > see how hard it is to transfer to keystone.\n> \n> Actually, no, I think you have it right (though the correct link is \n> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md)\n> \n> I think the main work, though, has to be in removing/replacing the Nova \n> API /keypairs stuff with calls to Keystone\'s v3/credentials API.\n> \n> Would the appropriate way to do this be to add an API shim into Nova\'s \n> API that simply calls out to the Keystone v3/credentials API IFF \n> Keystone\'s v3 API is enabled in the deployment? Then, deprecate the old \n> code and when Keystone v2 API is sunsetted, then remove the old Nova \n> keypairs API codepaths?\n\nI guess you also need to handle a migration of the data from one store\nto the other ?\nOr are these data migrations left as an exercise to the admins ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51D226E7.6030605@gmail.com>',NULL),('<1372774291.2416.106.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 15:11:31',3600,'2013-07-02 14:11:31',NULL,'[openstack-dev] [OSLO] Current DB status','On Mon, 2013-07-01 at 17:35 +0100, Mark McLoughlin wrote:\n> On Mon, 2013-07-01 at 19:33 +0300, Gary Kotton wrote:\n> > On 07/01/2013 07:07 PM, Mark McLoughlin wrote:\n> > > On Mon, 2013-07-01 at 18:59 +0300, Gary Kotton wrote:\n> > >> On 07/01/2013 06:49 PM, Mark McLoughlin wrote:\n> > >>> On Mon, 2013-07-01 at 18:32 +0300, Gary Kotton wrote:\n> > >>>> On 07/01/2013 06:13 PM, Mark McLoughlin wrote:\n> > >>>>> (Oslo is not an acronym)\n> > >>>> ok.\n> > >>>>\n> > >>>> can someone please clarify what the database status is in Oslo?\n> > >>> What apart from the oslo.config issue do you want clarified?\n> > >> Boris had concerns about the slave database support. He mentioned that\n> > >> the blueprint may be blocked -\n> > >> https://blueprints.launchpad.net/nova/+spec/db-slave-handle.\n> > > It\'s blocked in the sense that Nova can\'t yet use oslo.config because of\n> > > the aforementioned issue.\n> > >\n> > >> This patch\n> > >> updates to oslo.config-1.2.0a2 - so it may address the blueprints\n> > >> blocking item.\n> > >>\n> > >> My concern here is about the process. I was under the assumption, and\n> > >> may be wrong here, is that if code is approved in Oslo the is can be\n> > >> consumed by other projects. Over the last few months we have had a large\n> > >> amount of database issues in Neutron and moved to the Oslo DB code to\n> > >> address these.\n> > > Yes, we\'ve had (and continue to have) problems - no project has been\n> > > able to use new oslo.config features because of a series of python\n> > > packaging related issues.\n> > >\n> > > If you\'re suggesting that e.g. the DB code in oslo-incubator should\n> > > avoid requiring oslo-config-1.2.0, that wouldn\'t help quantum much since\n> > > the dependency on 1.2.0 was added in order to enable behaviour that\n> > > quantum required.\n> > \n> > The Oslo DB code requires oslo.config-1.2.0a2. This config version has \n> > supported for \'deprecated_opts\' - which enabled the common DB code to \n> > support Neutron and Nova DB configuration variables.\n> > \n> > I was not aware that that the slave blueprint was blocked because it was \n> > waiting for a specific config version (hopefully the Nova DB patch deals \n> > with as it uses the required config). My concern was that Oslo code was \n> > approved in one project (Neutron) and in another it raises question \n> > (Nova). Basically it would be nice to know if there are issues with the \n> > Oslo DB support and if so what needs to be done to address them.\n> \n> The blueprint says:\n> \n>   https://blueprints.launchpad.net/nova/+spec/db-slave-handle\n> \n>   \"This is blocked until we can get oslo.config 1.2.0a2 into nova. \n>    Currently it breaks unit tests when you run with tox.\"\n> \n> Which is the same issue as the one described here:\n> \n>   https://bugs.launchpad.net/oslo/+bug/1194807\n\nOk, I think I\'ve everything lined up to unblock this:\n\n  https://review.openstack.org/#/q/I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c,n,z\n\nCheers,\nMark.\n\n\n\n','<1372696525.2416.48.camel@sorcha>',NULL),('<1372774583.2416.108.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 15:16:23',3600,'2013-07-02 14:16:23',NULL,'[openstack-dev] [oslo.config] Config files overriding CLI: The\n path of most surprise.','tl;dr - this has been fixed on master for a while and the fix is\nincluded in oslo.config-1.2.0a3\n\n  http://docs.openstack.org/developer/oslo.config/#a3\n\nMark.\n\n\n\n','<1372714386-sup-3152@fewbar.com>',NULL),('<1372777007.30537.42.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 10:56:47',-14400,'2013-07-02 14:56:47',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','On Tue, 2013-07-02 at 10:07 -0400, Jay Pipes wrote:\n> On 07/02/2013 09:49 AM, Jarret Raim wrote:\n> > I\'ve spent some time thinking about how Barbican (Key Management) can help\n> > in this workflow.\n> >\n> > We will have the ability to generate SSH keys (and a host of other key &\n> > certificate types). This is backed by cryptographically sound code and\n> > we\'ve spent some time figuring out the entropy problem and HSM support. If\n> > the keys are stored in Barbican, we\'d get the audit / logging and other\n> > functionality needed for compliance.\n> \n> What does the above mean? What about Barbican is audited/logged that \n> isn\'t in Keystone and why wouldn\'t such auditing/logging be added to \n> Keystone if it were needed for compliance? I\'m trying to figure out why \n> there is yet another OpenStack-related project for storing \n> keys/credentials when Keystone already exists.\n\nBarbican is meant to store primarily private/simmetric keys in a way\nthat allows user to get access to them after proper keystone\nintegration. This material is particularly sensitive and it was felt\nthat we needed a specific service that would have a higher level of\nscrutiny and security. This is better achieved if the tool does only one\nthing with a smallest code footprint than if it is merged together with\nunrelated code. Auditing of code is expensive (mostly in terms of\ntime/eyes), so keeping a specialized service for these keys makes sense.\n\n>  > We also get federation which will\n> > allow customers of public Clouds (or shared private Clouds) to maintain\n> > custody of their own keys rather than storing them in the provider.\n> \n> I don\'t understand. Users already have custody of their own keys. The \n> only thing that Keystone/Nova has is the public key fingerprint [1], not \n> the private key...\n\nYou acatually have the public key, not just the fingerprint, but indeed\nI do not see why abrbican should be involved here.  apublic key does not\nneed the same level of protection of a private key or a symmetric\nencryption key, so by storing this data in barbican we would only\nneedlessly expose barbican to more access patternsand more\nlogging/auditing volume than is needed. \n\n> > There seem to be a couple of ways to take advantage of this functionality.\n> > If a key is specific to a user, then Keystone could store a URI to the key\n> > in Barbican and Nova could request it on server creation. Alternatively,\n> > the user could pass a URI to a key into Nova directly. If we want to move\n> > to always enabling SSH key access only on boot, Nova could create a key\n> > under the requesting tenant in Barbican and use it on server create.\n> \n> OK, so the above would basically be a \"driver\" in Keystone parlance for \n> the credentials module, where Keystone would just store the key in \n> Barbican and retrieve said key.\n> \n> At this point, though, what exactly is the point of Barbican over a \n> simple database or KVS driver?\n\nNot much, and perhaps even worsen the situation as I hinted above, but I\nthink Jared assumed you were talking about generating/storing private\nkeys, and as you noted it is not the case.\n\n> > Things get more interesting when we are talking about IPSec certificates\n> > and the like. Barbican seems a more logical place to generate / store /\n> > share these types of keys than Keystone.\n> \n> Generate...perhaps. Store... I doubt it. Share...I think Keystone is the \n> most logical place to share credentials. After all, it\'s the \n> authentication/identity component in OpenStack.\n\nNope, if you need to store private keys that you need to routinely\nretrieve and re-distribute then barbican is the right and only place.\n\n> While encryption and key generation are interesting topics, they are \n> tangential to the fact that credentials are an attribute of the \n> identity/user, and that information is in Keystone.\n\nIf \'access credentials\' remain buried (as in they cannot never be\nretrieved) in Keystone (or whatever IdM service it bridges to) then it\nis probably the right place as it performs authentication anyway and\nneeds direct access to these credentials internally in some cases.\n\nBut Keystone is not the right place to function as storage and retrieval\nsystem for private keys that\'s barbican\'s turf.\n\nSo for the nova keypairs I think Keystone is the natural place, as that\ninformation doesn\'t need strong protection, it\'s just public keys.\nFor private keys Keystone wouldn\'t do, and a URL redirection scheme as\nproposed by Jarret makes a lot of sense in this case.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<51D2DE88.2000906@gmail.com>',NULL),('<1372786813.30537.100.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 13:40:13',-14400,'2013-07-02 17:40:13',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','On Tue, 2013-07-02 at 08:12 -0700, Bryan D. Payne wrote:\n> \n>         > I don\'t understand. Users already have custody of their own\n>         keys. The\n>         > only thing that Keystone/Nova has is the public key\n>         fingerprint [1], not\n>         > the private key...\n>         \n>         \n>         You acatually have the public key, not just the fingerprint,\n>         but indeed\n>         I do not see why abrbican should be involved here.  apublic\n>         key does not\n>         need the same level of protection of a private key or a\n>         symmetric\n>         encryption key, so by storing this data in barbican we would\n>         only\n>         needlessly expose barbican to more access patternsand more\n>         logging/auditing volume than is needed.\n> \n> \n> I believe you\'re confusing a couple of points here.  In this case, for\n> public keys, what matters is integrity.  For the other cases that you\n> mentioned, both integrity and confidentiality matter.  I believe that\n> given the high integrity requirements that it *does* make sense to\n> store these in a more protected location.\n> \n> \n> +1 for using Barbican\n> \nIf you do not trust keystone to give you the right information you have\nalready lost as keystone is used (afaik) to check for authorization\nanyway.\n\nCan you be a little bit more explicit on the threat model you have in\nmind and what guarantees Barbican would give you that would make it more\nsuitable to store public key than Keystone ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CAFpPvXBr+mSt8Mw6N0_8eY=FTW3Wh2Yku9QBUSuuf-FDnc5Y=Q@mail.gmail.com>',NULL),('<1372786984.30537.102.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 13:43:04',-14400,'2013-07-02 17:43:04',NULL,'[openstack-dev] Move keypair management out of Nova and into\n Keystone?','On Tue, 2013-07-02 at 16:55 +0000, Tiwari, Arvind wrote:\n> Hi Simo,\n> \n> I am lost.\n>  \n> Does Barbican is product came out of https://wiki.openstack.org/wiki/KeyManager BP?\n\nYes Barbican is an implementation of this Blueprint afaik.\n\n> If yes, then why it is deviating from the BP which says Key Manager will be separate service but not a part of Keystone.\n\nSorry I don\'t follow, Barbican is separated from Keystone.\n\n> If no, then why we are thinking about new Key manager (which seems to me a subset of above BP)? \n\nNew ?\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<0EF5F110A32BED44A0C6438BB5C35B39051AB222@G4W3210.americas.hpqcorp.net>',NULL),('<1372794237.2416.124.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 20:43:57',3600,'2013-07-02 19:43:57',NULL,'[openstack-dev] Distro defaults [was Re: [oslo.config] Config files\n overriding CLI: The path of most surprise.]','On Tue, 2013-07-02 at 17:48 +0000, Jeremy Stanley wrote:\n> On 2013-07-01 15:10:26 -0700 (-0700), Mark Washenberger wrote:\n> [...]\n> > The talk about permanence confuses me, unless we mean that more\n> > permanent values are overridden by less permanent ones.\n> [...]\n> \n> I think the \"permanence\" counter argument (which I don\'t agree with,\n> just recounting it for completeness) was that command-line arguments\n> may be embedded in init scripts by some distributions and then\n> administrators would be surprised when their modifications to the\n> configuration files weren\'t respected.\n\nYes, that was what the \"permanence\" discussion related to. The example I\nwas thinking of was \'--logfile /var/log/nova/api.log\' which doesn\'t seem\nlike a ridiculous thing to pass via the command line.\n\nSince we\'ve clearly moved on, I\'m not sure replaying old points is very\nconstructive, but you have hit on an interesting topic, so ... :)\n\n> Ultimately, however, any time\n> distribution defaults which could be set in packaged configuration\n> are instead being set with the service command-line in packaged init\n> scripts, I would tend to just consider that a (serious) packaging\n> bug and certainly nothing we should be catering to as a project.\n\nThat\'s very ... stringent. But I do mostly agree. Distros shouldn\'t\nstick a tonne of distro defaults on the command line of services.\n\nThe two principles that matter IMHO are:\n\n  1) users should be able to override defaults\n\n  2) if a user deletes their config file, they get back to the defaults\n\nSomething we\'ve experimented with in Red Hat OpenStack is to put distro\ndefaults in e.g. /usr/share/nova/nova-dist.conf. You can see some of the\nthinking here, for example:\n\n  https://bugzilla.redhat.com/show_bug.cgi?id=887334#c4\n\nThe alternative approach would be to patch the code with distro\ndefaults.\n\nNow, you could say that distros shouldn\'t need to modify the defaults.\nThat\'s fair, but I don\'t think there\'s anything too crazy in our distro\ndefaults either:\n\n  https://github.com/redhat-openstack/openstack-nova/blob/master/nova.conf\n\nAnyone got other thoughts on how distros should handle this?\n\nCheers,\nMark.\n\n\n\n','<20130702174823.GD1472@yuggoth.org>',NULL),('<1372798521.2185.YahooMailNeo@web120401.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-02 13:55:21',-25200,'2013-07-02 20:55:21',NULL,'[Openstack-operators] Instance Scheduling on Hosts','I have two groups of hosts as compute nodes:\n\nBigGroup: a few machines with very big RAM\nSmallGroup: a lot of machines with smaller RAM each.\n\nMy goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.\nI tried the \"AggregateInstanceExtraSpecsFilter\" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn\'t work and all the instance boots will end up to error.\nAny idea?\n\nMore over does anyone know how can I assign higher cost to bigger nodes for weighting?\n\nThanks,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130702/6fb8fbaf/attachment.html>\n\n',NULL,NULL),('<1372802209.52753.YahooMailNeo@web120401.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-02 14:56:49',-25200,'2013-07-02 21:56:49',NULL,'[Openstack-operators] Instance Scheduling on Hosts','This is exactly what I\'m looking for, but don\'t know how!\nWould you please describe a bit more?\n\nThanks\n\n\n________________________________\n From: Narayan Desai <narayan.desai at gmail.com>\nTo: Ahmad Ahmadi <ahmadidamha at yahoo.com> \nCc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \nSent: Tuesday, July 2, 2013 3:30 PM\nSubject: Re: [Openstack-operators] Instance Scheduling on Hosts\n \n\n\nWe accomplished with a scheduler filter that only routes big mem requests to nodes with large memory footprint and doesn\'t consider these for smaller instance types.\n?-nld\n\n\n\nOn Tue, Jul 2, 2013 at 3:55 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:\n\nI have two groups of hosts as compute nodes:\n>\n>BigGroup: a few machines with very big RAM\n>SmallGroup: a lot of machines with smaller RAM each.\n>\n>\n>My goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.\n>I tried the \"AggregateInstanceExtraSpecsFilter\" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn\'t work and all the instance boots will end up to error.\n>Any idea?\n>\n>\n>More over does anyone know how can I assign higher cost to bigger nodes for weighting?\n>\n>\n>Thanks,\n>\n>_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130702/8702591b/attachment.html>\n\n','<CABweQmKoepGgt9AsuOerBCOUitLR=ytWzCkRnZhWd0oMH9q3Yw@mail.gmail.com>',NULL),('<1372804148-sup-9554@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 15:52:50',-25200,'2013-07-02 22:52:50',NULL,'[openstack-dev] trove and heat integration status','Excerpts from Michael Basnight\'s message of 2013-07-02 15:17:09 -0700:\n> Howdy,\n> \n> one of the TC requests for integration of trove was to integrate heat. While this is a small task for single instance installations, when we get into clustering it seems a bit more painful. Id like to submit the following as a place to start the discussion for why we would/wouldnt integrate heat (now). This is, in NO WAY, to say we will not integrate heat. Its just a matter of timing and requirements for our \'soon to be\' cluster api. I am, however, targeting getting trove to work in a rpm environment, as it is tied to apt currently.\n\nHi Michael. I do think that it is very cool that Trove will be making\nuse of Heat for cluster configuration.\n\n> \n> 1) Companies who are looking at trove are not yet looking at heat, and a hard dependency might stifle growth of the product initially\n>     ? CERN\n\nI\'m sure these users don\'t explicitly want \"MySQL\" (or whatever DB\nyou use) and \"RabbitMQ\" (or whatever RPC you use) either, but they\nare plumbing, and thus things that need to be deployed in the larger\narchitecture.\n\n> 2) homogeneous LaunchConfiguration\n>     ? a database cluster is heterogeneous\n>     ? Our cluster configuration will need to specify different sized slaves, and allow a customer to upgrade a single slaves configuration\n>     ? heat said if this is something that has a good use case, they could potentially make it happen (not sure of timeframe)\n\nThere\'s no requirement that you use AWS::EC2::AutoScalingGroup or\nOS::Heat::InstanceGroup. In fact I find them rather cumbersome and\nlimited. Since all Heat templates are just data structures (expressed\nas yaml or json) you can just maintain an array of instances of the size\nthat you want.\n\n> 3) have to modify template to scale out\n>     ? This doable but will require hacking a template in code and pushing that template\n>     ? I assume removing a slave will require the same finagling of the template\n>     ? I understand that a better version of this is coming (not sure of timeframe)\n> \n\nThe word template makes it sound like it is a text only thing. It is\na data structure, and as such, it is quite easy to modify and maintain\nin code.\n\nAs an example, lets say you have this as your template for a database cluster:\n\n# in yaml\nResources:\n  Master0000ReadyWaitCond:\n    Type: AWS::CloudFormation::WaitCondition\n    Properties:\n      Timeout: 120\n  Master0000ReadyWaitCondHandle:\n    Type: AWS::CloudFormation::WaitConditionHandle\n    Properties:\n      WaitConditionName: {Ref: Master0000ReadyWaitCond}\n  Master0000:\n    Type: AWS::EC2::Instance\n    Properties:\n      InstanceType: reallyfastandlotsofram\n      ImageId: trove-mysql\n    Metadata:\n      ReadyWaitCondition: {Ref: Master0000ReadyWaitCondHandle}\n\n\nThis will boot up, with the reference image, and if you have appropriate\nsoftware (such as heat-cfntools or  os-apply-config and os-refresh-config)\nin your image it will read the Metadata section and signal back to Heat\nwhen ReadyWaitCond is satisfied. With that, Trove can poll the status\nof that resource to find out if the master is ready.\n\nNow, to add a slave:\n\n# in yaml\nResources:\n  Master0000ReadyWaitCond:\n    Type: AWS::CloudFormation::WaitCondition\n    Properties:\n      Timeout: 120\n  Master0000ReadyWaitCondHandle:\n    Type: AWS::CloudFormation::WaitConditionHandle\n    Properties:\n      WaitConditionName: {Ref: Master0000ReadyWaitCond}\n  Master0000:\n    Type: AWS::EC2::Instance\n    Properties:\n      InstanceType: reallyfastandlotsofram\n      ImageId: trove-mysql\n    Metadata:\n      ReadyWaitCondition: {Ref: Master0000ReadyWaitCondHandle}\n      Users:\n        - name: slave0000\n        - password: some_random_string\n  Slave0000ReadyWaitCond:\n    Type: AWS::CloudFormation::WaitCondition\n    Properties:\n      Timeout: 120\n  Slave0000ReadyWaitCondHandle:\n    Type: AWS::CloudFormation::WaitConditionHandle\n    Properties:\n      WaitConditionName: {Ref: Slave0000ReadyWaitCond}\n  Slave0000:\n    Type: AWS::EC2::Instance\n    DependsOn: Master0000ReadyWaitCond\n    Properties:\n      InstanceType: kindofawesome\n      ImageId: trove-mysql\n    Metadata:\n      Master:\n        Address: {Fn::GetAtt: [Master0000, PrivateIp]}\n        User:\n          name: slave0000\n          password: some_random_string\n      ReadyWaitCondition: {Ref: SlaveReadyWaitCondHandle}\n\n\nI hope all of that makes some sense. Eventually yes, resizable arrays\nof servers will be in the new format, HOT, but for now, the CFN method\nis still useful as you get signals and dependency graph management.\n\n\n','<151AF842-FF63-4EFC-8B9C-6FD96B2A0782@gmail.com>',NULL),('<1372820960-sup-8990@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 20:17:30',-25200,'2013-07-03 03:17:30',NULL,'[openstack-dev] trove and heat integration status','Excerpts from Michael Basnight\'s message of 2013-07-02 19:04:01 -0700:\n> On Jul 2, 2013, at 3:52 PM, Clint Byrum wrote:\n> \n> > Excerpts from Michael Basnight\'s message of 2013-07-02 15:17:09 -0700:\n> >> Howdy,\n> >> \n> >> one of the TC requests for integration of trove was to integrate heat. While this is a small task for single instance installations, when we get into clustering it seems a bit more painful. Id like to submit the following as a place to start the discussion for why we would/wouldnt integrate heat (now). This is, in NO WAY, to say we will not integrate heat. Its just a matter of timing and requirements for our \'soon to be\' cluster api. I am, however, targeting getting trove to work in a rpm environment, as it is tied to apt currently.\n> > \n> > Hi Michael. I do think that it is very cool that Trove will be making\n> > use of Heat for cluster configuration.\n> \n> I know it really fits the bill!\n> \n> > \n> >> \n> >> 1) Companies who are looking at trove are not yet looking at heat, and a hard dependency might stifle growth of the product initially\n> >>    ? CERN\n> > \n> > I\'m sure these users don\'t explicitly want \"MySQL\" (or whatever DB\n> > you use) and \"RabbitMQ\" (or whatever RPC you use) either, but they\n> > are plumbing, and thus things that need to be deployed in the larger\n> > architecture.\n> \n> Well sure but i also dont want to stop trove from adoption because a company has not investigated heat. Rabbit and the DB are shared resources between all OpenStack services. Heat and Trove are not.\n> \n\nI do understand that. Heat has some growing up to do before it is in the\nsame category as those other pieces. Please keep us in the loop where\nyou need features and/or bug fixes for Heat.\n\n> > \n> >> 2) homogeneous LaunchConfiguration\n> >>    ? a database cluster is heterogeneous\n> >>    ? Our cluster configuration will need to specify different sized slaves, and allow a customer to upgrade a single slaves configuration\n> >>    ? heat said if this is something that has a good use case, they could potentially make it happen (not sure of timeframe)\n> > \n> > There\'s no requirement that you use AWS::EC2::AutoScalingGroup or\n> > OS::Heat::InstanceGroup. In fact I find them rather cumbersome and\n> > limited. Since all Heat templates are just data structures (expressed\n> > as yaml or json) you can just maintain an array of instances of the size\n> > that you want.\n> \n> Oh good!\n> \n> > \n> >> 3) have to modify template to scale out\n> >>    ? This doable but will require hacking a template in code and pushing that template\n> >>    ? I assume removing a slave will require the same finagling of the template\n> >>    ? I understand that a better version of this is coming (not sure of timeframe)\n> >> \n> > \n> > The word template makes it sound like it is a text only thing. It is\n> > a data structure, and as such, it is quite easy to modify and maintain\n> > in code.\n> > ...\n> > I hope all of that makes some sense. Eventually yes, resizable arrays\n> > of servers will be in the new format, HOT, but for now, the CFN method\n> > is still useful as you get signals and dependency graph management.\n> \n> It does, with one caveat. Can i say slave00001 has a flavor of 512m and slave00002 has a flavor 2048m? I didnt see that in the example. Its really useful for a reporting slave to be smaller than a master, and for a particular slave to be larger due to any sort of requirement that i cant necessarily dictate! \n\nOf course flavor can differ per-server. That is kind of my point, the cfn\ntemplate format is fairly low level, making Heat into sort of a really\nsmart client library for all of OpenStack. So you can really maintain\nthe list of slaves however you want. You could have ReportingSlave0001\nand QuerySlave0002 or just use UUID\'s for them and give them names\nin Metadata.\n\n\n','<F5E7DF47-74DE-4F1F-9377-34913C8DEC03@gmail.com>',NULL),('<1372848979.2416.180.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-07-03 11:56:19',3600,'2013-07-03 10:56:19',NULL,'[openstack-tc] Charter changed to reflect \'programs\'','On Wed, 2013-07-03 at 12:44 +0200, Thierry Carrez wrote:\n> Hi TC members,\n> \n> As discussed yesterday, I modified the Charter to introduce \'Programs\'\n> and replace mentions of \'Projects\' wherever necessary:\n> \n> https://wiki.openstack.org/w/index.php?title=Governance%2FFoundation%2FTechnicalCommittee&diff=25309&oldid=24429\n> \n> The official \'Projects\' page was renamed to \'Programs\' and updated:\n> https://wiki.openstack.org/wiki/Programs\n> \n> This page will be updated with links to mission statements as we\n> retroactively create them.\n> \n> I also started a page describing the process to become a new program:\n> https://wiki.openstack.org/wiki/Governance/NewPrograms\n> \n> If you can think of any information a new program should provide with\n> its request, please update the wikipage directly.\n\nAll looks good to me. Nice work.\n\nI\'d perhaps rephrase \"election for PTL seats\" as \"election for PTL\npositions\" ... the word \"seat\" makes it sound like a seat on the TC\nitself.\n\nAlso, tiny distinction here, but the \"defined term\" we have is \"an\nIntegrated project\" more than \"the integrated release\", so I\'d change:\n\n  The process new projects can follow to become part of the OpenStack \n  \'Integrated\' release is described.\n\nto:\n\n  The process new projects can follow to become an Integrated project \n  and part of the OpenStack coordinated release is described here.\n\nCheers,\nMark.\n\n\n\n','<51D4007B.6040008@openstack.org>',NULL),('<1372864214.921313279@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-07-03 10:10:14',-18000,'2013-07-03 15:10:14',NULL,'[OpenStack Foundation] Board Meeting - June 27th','\nI also wanted to take the opportunity to thank Alice King for all of her contributions to OpenStack over the years.\n \nMany of you may know that she led the drafting committee, who helped craft our bylaws, as well as leading the legal affairs committee after the Foundation was formed.\n \nHowever, you may not be aware that she was instrumental in the early stages of openstack, even before it had a name (she helped us with the name, in fact) including the search for a suitable license (Apache 2.0 ftw!).  While I\'m at it I\'ll give a shout out to Sabina Jausovec who also did a huge amount of work to support OpenStack from a legal perspective.\n \nMark\n \n \n \n \nOn Friday, June 28, 2013 7:10am, \"Jonathan Bryce\" <jonathan at openstack.org> said:\n\n\n\n> Yesterday, the Foundation Board of Directors held another telephone meeting. The\n> agenda for the meeting can be found on the wiki:\n> https://wiki.openstack.org/wiki/Governance/Foundation/27June2013BoardMeeting\n> \n> The first action item was approving a minor amendment to the Foundation\'s\n> Certificate of Incorporation to correct an error in the 10th article covering the\n> disposal of assets should the Foundation corporate entity ever be dissolved. The\n> Board unanimously approved the amendment.\n> \n> After that, Lauren Sell briefly introduced a draft Transparency Policy that she\n> had been working on with our legal counsel and the Transparency Committee. There\n> will be a mailing list discussion to finalize the Policy before it\'s adopted. Next\n> Lauren and Mark Collier provided an update on the November summit in Hong Kong as\n> well as some of the preliminary venue searches for the 2014 summits. They also\n> discussed the activities of the Marketing Community\n> (https://wiki.openstack.org/wiki/Governance/Foundation/Marketing). If you are\n> involved in marketing with an OpenStack organization, I\'d encourage you to join\n> the Marketing Community and help out with some of the initiatives that are\n> underway there.\n> \n> Alice King, Nissa Strottman and Steve Pentlicki of the Legal Affairs Committee led\n> a discussion on potential options for patent cooperation among OpenStack\n> organizations. Board members are going to follow up with their individual legal\n> and IP departments to provide feedback on the options presented. The Board\n> approved adding Van Lindberg to the Legal Affairs Committee to replace Alice King\n> who is stepping down as she starts her own law practice. Many thanks to Alice, who\n> has provided legal guidance for OpenStack since the very beginning and was a\n> leader of the drafting committee last year as the Foundation was established.\n> \n> As the meeting wrapped up, the Board had brief updates on the continuing\n> discussion around definition of core and status updates on a number of other items\n> that are being scheduled for discussion at the next Board meetings.\n> \n> The next Board meeting is scheduled for August 6th at 9:00am PDT/1600 UTC.\n> \n> Jonathan\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130703/7a754c47/attachment.html>\n\n','<B607621C-1028-459F-A28A-82D5492FF88A@openstack.org>',NULL),('<1372868071.27711.738.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 18:14:31',7200,'2013-07-03 16:14:31',NULL,'[openstack-dev] [Metrics][Nova] Using Bicho database to get stats\n	about code review','Hi all,\n\nBicho [1] now has a Gerrit backend, which has been tested with\nOpenStack\'s Gerrit. We have used it to produce the MySQL database dump\navailable at [2] ( gerrit.mysql.7z ). You can use it to compute the\nmetrics mentioned in the previous threads about code review, and some\nothers.\n\n[1] https://github.com/MetricsGrimoire/Bicho\n[2] http://activity.openstack.org/dash/browser/data/db/\n\nThe database dump will be updated daily, starting in a few days.\n\nFor some examples on how to run queries on it, or how to produce the\ndatabase using Bicho, fresh from OpenStack\'s gerrit, have a look at [3].\n\n[3] https://github.com/MetricsGrimoire/Bicho/wiki/Gerrit-backend\n\nAt some point, we plan to visualize the data as a part of the\ndevelopment dashboard [4], so any comment on interesting metrics, or\nbugs, will be welcome. For now, we\'re taking not of all metrics\nmentioned in the previous posts about code review stats.\n\n[4] http://activity.openstack.org/dash/browser/\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n',NULL,NULL),('<1372872639.27711.754.camel@parato.mi.casa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 19:30:39',7200,'2013-07-03 17:30:39',NULL,'[openstack-dev] [Metrics][Nova] Using Bicho database to get\n stats about code review','On Wed, 2013-07-03 at 12:30 -0400, Russell Bryant wrote:\n> On 07/03/2013 12:14 PM, Jesus M. Gonzalez-Barahona wrote:\n> > Hi all,\n> > \n> > Bicho [1] now has a Gerrit backend, which has been tested with\n> > OpenStack\'s Gerrit. We have used it to produce the MySQL database dump\n> > available at [2] ( gerrit.mysql.7z ). You can use it to compute the\n> > metrics mentioned in the previous threads about code review, and some\n> > others.\n> > \n> > [1] https://github.com/MetricsGrimoire/Bicho\n> > [2] http://activity.openstack.org/dash/browser/data/db/\n> > \n> > The database dump will be updated daily, starting in a few days.\n> > \n> > For some examples on how to run queries on it, or how to produce the\n> > database using Bicho, fresh from OpenStack\'s gerrit, have a look at [3].\n> > \n> > [3] https://github.com/MetricsGrimoire/Bicho/wiki/Gerrit-backend\n> > \n> > At some point, we plan to visualize the data as a part of the\n> > development dashboard [4], so any comment on interesting metrics, or\n> > bugs, will be welcome. For now, we\'re taking not of all metrics\n> > mentioned in the previous posts about code review stats.\n> > \n> > [4] http://activity.openstack.org/dash/browser/\n> \n> Thanks for sharing!  I don\'t think I understand the last sentence,\n> though.  Can you clarify?\n> \n\nOooops. It should read \"For now, we\'re taking notice of all metrics\nmentioned in the previous posts about code review stats.\" That would\nmean that, in a while, we expect to produce charts on the evolution of\nsome of those metrics over time.\n\nSorry for the typo.\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<51D451B0.7000508@redhat.com>',NULL),('<1372887085.92988.YahooMailNeo@web120404.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-03 14:31:25',-25200,'2013-07-03 21:31:25',NULL,'[Openstack-operators] Instance Scheduling on Hosts','I\'m using folsom. Getting scheduler error.\nHere are my commands, nova.conf and log file:\n \n\n\n________________________________\n From: Sylvain Bauza <sylvain.bauza at digimind.com>\nTo: Ahmad Ahmadi <ahmadidamha at yahoo.com> \nCc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \nSent: Wednesday, July 3, 2013 7:16 AM\nSubject: Re: [Openstack-operators] Instance Scheduling on Hosts\n \n\n\nI ended up successfully in creating flavors with aggregate hosts metadata and the filter you mentioned on my Folsom install.\n\nI followed the same configuration steps [1]\n\nWhat kind of error are you getting ? Is nova-scheduler failing\n        or nova-compute ? Check the logs to get the exact error, please\n        :-)\n\n-Sylvain\n\n[1] :\nhttp://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html#d6e10301\n\n\nLe 02/07/2013 22:55, Ahmad Ahmadi a ?crit?:\n\nI have two groups of hosts as compute nodes:\n>\n>BigGroup: a few machines with very big RAM\n>SmallGroup: a lot of machines with smaller RAM each.\n>\n>\n>My goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.\n>I tried the \"AggregateInstanceExtraSpecsFilter\" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn\'t work and all the instance boots will end up to error.\n>Any idea?\n>\n>\n>More over does anyone know how can I assign higher cost to bigger nodes for weighting?\n>\n>\n>Thanks,\n>\n>\n>\n>_______________________________________________\nOpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130703/85c0c9dc/attachment.html>\n-------------- next part --------------\nAn embedded and charset-unspecified text was scrubbed...\nName: command.txt\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130703/85c0c9dc/attachment.txt>\n-------------- next part --------------\nAn embedded and charset-unspecified text was scrubbed...\nName: log.txt\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130703/85c0c9dc/attachment-0001.txt>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: nova.conf\nType: application/octet-stream\nSize: 534 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130703/85c0c9dc/attachment.obj>\n\n','<51D4242A.5010008@digimind.com>',NULL),('<1372887428-sup-1395@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 14:45:27',-25200,'2013-07-03 21:45:27',NULL,'[openstack-dev] [heat] as-update-policy implementation questions','Excerpts from Chan, Winson C\'s message of 2013-06-18 23:22:15 -0700:\n> Is the expectation here that the update policy for the auto-scaling group is enforced only when either the launch configuration or subnet group membership is changed in the auto-scaling group?  The LaunchConfigurationName is not currently listed as an update_allowed_properties in the AutoScalingGroup.  Update handling is not implemented in LaunchConfiguration either.  Also, VPCZoneIdentifier for listing subnet group membership is not implemented in the AutoScalingGroup either.  Should there be blueprints to handle these before working on the update policy?\n\nI\'m afraid I can\'t be much help here. The way AWS works is not really of\nany concern to me. The way I think InstanceGroup and AutoScalingGroup\nshould work isn\'t really compatible with CloudFormation, so I don\'t\nthink it is worthwhile to lend too much credence to \"how things are now\".\n\nIf you want it to work like AWS, I suggest testing on AWS and then\nfiling/fixing bugs against Heat. However, if you want a rolling updates\nmechanism to be practical and highly useful, I\'d suggest reviewing the\nrolling-updates blueprint/spec and helping to improve it. I\'d like to\nrewrite the spec actually, as I have learned a lot since writing it and\nnow have some better ideas on how to implement it.\n\n\n','<CDE69C26.60C9%winson.c.chan@intel.com>',NULL),('<1372892337.60012.YahooMailNeo@web120404.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-03 15:58:57',-25200,'2013-07-03 22:58:57',NULL,'[Openstack-operators] Instance Scheduling on Hosts','I\'m using folsom. Getting scheduler error.\n\nMy commands in order:\n# nova aggregate-create smlAgg nova\n+----+--------+-------------------+-------+----------+\n| Id | Name?? | Availability Zone | Hosts | Metadata |\n+----+--------+-------------------+-------+----------+\n| 10 | smlAgg | nova????????????? |?????? |????????? |\n+----+--------+-------------------+-------+----------+\n# nova aggregate-set-metadata 10 mem=true\nAggregate 10 has been successfully updated.\n+----+--------+-------------------+-------+-------------------+\n| Id | Name?? | Availability Zone | Hosts | Metadata????????? |\n+----+--------+-------------------+-------+-------------------+\n| 10 | smlAgg | nova????????????? | []??? | {u\'mem\': u\'true\'} |\n+----+--------+-------------------+-------+-------------------+\n# nova aggregate-add-host 10 n005\nAggregate 10 has been successfully updated.\n+----+--------+-------------------+-----------+-------------------+\n| Id | Name?? | Availability Zone | Hosts???? | Metadata????????? |\n+----+--------+-------------------+-----------+-------------------+\n| 10 | smlAgg | nova????????????? | [u\'n005\'] | {u\'mem\': u\'true\'} |\n+----+--------+-------------------+-----------+-------------------+\n# nova aggregate-add-host 10 n006\nAggregate 10 has been successfully updated.\n+----+--------+-------------------+--------------------+-------------------+\n| Id | Name?? | Availability Zone | Hosts????????????? | Metadata????????? |\n+----+--------+-------------------+--------------------+-------------------+\n| 10 | smlAgg | nova????????????? | [u\'n005\', u\'n006\'] | {u\'mem\': u\'true\'} |\n+----+--------+-------------------+--------------------+-------------------+\n# nova aggregate-add-host 10 n007\nAggregate 10 has been successfully updated.\n+----+--------+-------------------+-----------------------------+-------------------+\n| Id | Name?? | Availability Zone | Hosts?????????????????????? | Metadata????????? |\n+----+--------+-------------------+-----------------------------+-------------------+\n| 10 | smlAgg | nova????????????? | [u\'n005\', u\'n006\', u\'n007\'] | {u\'mem\': u\'true\'} |\n+----+--------+-------------------+-----------------------------+-------------------+\n# nova-manage instance_type set_key --name=m1.tiny? --key=mem --value=true\nKey mem set to true on instance type m1.tiny\n# nova flavor-show m1.tiny\n+----------------------------+-------------------+\n| Property?????????????????? | Value???????????? |\n+----------------------------+-------------------+\n| OS-FLV-DISABLED:disabled?? | False???????????? |\n| OS-FLV-EXT-DATA:ephemeral? | 0???????????????? |\n| disk?????????????????????? | 0???????????????? |\n| extra_specs??????????????? | {u\'mem\': u\'true\'} |\n| id???????????????????????? | 1???????????????? |\n| name?????????????????????? | m1.tiny?????????? |\n| os-flavor-access:is_public | True????????????? |\n| ram??????????????????????? | 512?????????????? |\n| rxtx_factor??????????????? | 1.0?????????????? |\n| swap?????????????????????? |?????????????????? |\n| vcpus????????????????????? | 1???????????????? |\n+----------------------------+-------------------+\n# nova boot --image c6714433-1653-463c-906a-9511e3e6b21b --flavor m1.tiny test\n+-------------------------------------+---------------------------------------------------------------------------------+\n| Property??????????????????????????? | Value?????????????????????????????????????????????????????????????????????????? |\n+-------------------------------------+---------------------------------------------------------------------------------+\n| OS-DCF:diskConfig?????????????????? | MANUAL????????????????????????????????????????????????????????????????????????? |\n| OS-EXT-SRV-ATTR:host??????????????? | None??????????????????????????????????????????????????????????????????????????? |\n| OS-EXT-SRV-ATTR:hypervisor_hostname | None??????????????????????????????????????????????????????????????????????????? |\n| OS-EXT-SRV-ATTR:instance_name?????? | instance-00000250?????????????????????????????????????????????????????????????? |\n| OS-EXT-STS:power_state????????????? | 0?????????????????????????????????????????????????????????????????????????????? |\n| OS-EXT-STS:task_state?????????????? | None??????????????????????????????????????????????????????????????????????????? |\n| OS-EXT-STS:vm_state???????????????? | error?????????????????????????????????????????????????????????????????????????? |\n| accessIPv4????????????????????????? |???????????????????????????????????????????????????????????????????????????????? |\n| accessIPv6????????????????????????? |???????????????????????????????????????????????????????????????????????????????? |\n| adminPass?????????????????????????? | ************??????????????????????????????????????????????????????????????????? |\n| config_drive??????????????????????? |???????????????????????????????????????????????????????????????????????????????? |\n| created???????????????????????????? | 2013-07-03T21:23:22Z??????????????????????????????????????????????????????????? |\n| fault?????????????????????????????? | {u\'message\': u\'NoValidHost\', u\'code\': 500, u\'created\': u\'2013-07-03T21:23:23Z\'} |\n| flavor????????????????????????????? | m1.tiny???????????????????????????????????????????????????????????????????????? |\n| hostId????????????????????????????? |???????????????????????????????????????????????????????????????????????????????? |\n| id????????????????????????????????? | 53e42fa5-8d72-4f80-8586-eb7f20cd14d0??????????????????????????????????????????? |\n| image?????????????????????????????? | CentOS_6??????????????????????????????????????????????????????????????????????? |\n| key_name??????????????????????????? | None??????????????????????????????????????????????????????????????????????????? |\n| metadata??????????????????????????? | {}????????????????????????????????????????????????????????????????????????????? |\n| name??????????????????????????????? | test??????????????????????????????????????????????????????????????????????????? |\n| security_groups???????????????????? | [{u\'name\': u\'default\'}]???????????????????????????????????????????????????????? |\n| status????????????????????????????? | ERROR?????????????????????????????????????????????????????????????????????????? |\n| tenant_id?????????????????????????? | 4c2340f60b7c48a0a2504eeefe2ff74a??????????????????????????????????????????????? |\n| updated???????????????????????????? | 2013-07-03T21:23:23Z??????????????????????????????????????????????????????????? |\n| user_id???????????????????????????? | 3800b26a95c44e7abd1c080f7695560a??????????????????????????????????????????????? |\n+-------------------------------------+---------------------------------------------------------------------------------+\n\n\nnova.conf:\nscheduler_driver??????????????????????? =nova.scheduler.multi.MultiScheduler\ncompute_scheduler_driver??????????????? =nova.scheduler.filter_scheduler.FilterScheduler\nscheduler_available_filters???????????? =nova.scheduler.filters.all_filters\nscheduler_default_filters?????????????? =AggregateInstanceExtraSpecsFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter\nleast_cost_functions??????????????????? =nova.scheduler.least_cost.compute_fill_first_cost_fn\ncompute_fill_first_cost_fn_weight?????? =-1.0\nscheduler_host_subset_size???????? =1\n\n\n\n\nlog:\n==> /var/log/nova/scheduler.log <==\n2013-07-03 15:23:23 WARNING nova.scheduler.driver [req-8616e45a-2826-4d2f-9870-b5b80ea81740 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] [instance: 53e42fa5-8d72-4f80-8586-eb7f20cd14d0] Setting instance to ERROR state.\n\n \n\n\n________________________________\n From: Sylvain Bauza <sylvain.bauza at digimind.com>\nTo: Ahmad Ahmadi <ahmadidamha at yahoo.com> \nCc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \nSent: Wednesday, July 3, 2013 7:16 AM\nSubject: Re: [Openstack-operators] Instance Scheduling on Hosts\n \n\n\nI ended up successfully in creating flavors with aggregate hosts metadata and the filter you mentioned on my Folsom install.\n\nI followed the same configuration steps [1]\n\nWhat kind of error are you getting ? Is nova-scheduler failing\n        or nova-compute ? Check the logs to get the exact error, please\n        :-)\n\n-Sylvain\n\n[1] :\nhttp://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html#d6e10301\n\n\nLe 02/07/2013 22:55, Ahmad Ahmadi a ?crit?:\n\nI have two groups of hosts as compute nodes:\n>\n>BigGroup: a few machines with very big RAM\n>SmallGroup: a lot of machines with smaller RAM each.\n>\n>\n>My goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.\n>I tried the \"AggregateInstanceExtraSpecsFilter\" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn\'t work and all the instance boots will end up to error.\n>Any idea?\n>\n>\n>More over does anyone know how can I assign higher cost to bigger nodes for weighting?\n>\n>\n>Thanks,\n>\n>\n>\n>_______________________________________________\nOpenStack-operators mailing list OpenStack-operators at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130703/a31cb6e6/attachment.html>\n\n','<51D4242A.5010008@digimind.com>',NULL),('<1372971912.2416.304.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-04 22:05:12',3600,'2013-07-04 21:05:12',NULL,'[openstack-dev] [Oslo] Bringing audit standards to Openstack','On Thu, 2013-07-04 at 16:50 -0400, Gordon Chung wrote:\n> initially, we drafted this to be part of Ceilometer but as we\'ve worked\n> through it, we\'ve noticed it is applicable in multiple projects. during the\n> course of our discussions with Keystone developers to assure we were\n> recording the correct data for audit, we found that Keystone itself had a\n> blueprint to add notifications and log audit data for their APIs:\n> https://blueprints.launchpad.net/keystone/+spec/notifications.\n> \n> i thought i\'d present this on the mailing list to gather feedback on the\n> idea of adopting CADF and discuss possibly its inclusion in Oslo so that\n> all the projects can use the same open standard when capturing events. \n\nMy usual recommendation is to prove out the concept in a single project\nand then, when you go to add it to another project, move it to\noslo-incubator.\n\nCheers,\nMark.\n\n\n\n','<OF63958B1F.B9BC6010-ON85257B9E.0071B47F-85257B9E.007278E2@ca.ibm.com>',NULL),('<1372987487.68281750@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-05 11:24:47',36000,'2013-07-05 01:24:47',NULL,'[Openstack-docs] Autogenerate-config-tables code patch','Hi,\n\nUp until now, the code for the automatically generated configuration tables Steven and I have been working on has lived in a separate github repo. It\'s now well enough under way that I\'d like to bring it in to openstack-manuals under tools.\n\nHere\'s the patch:\n\nhttps://review.openstack.org/35726\n\nCode review appreciated, as the standards are higher in openstack-manuals than they are in \'fifieldt\' ;)\n\nRegards,\n\n\nTom\n\n\n\n',NULL,NULL),('<1373273453.2407.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-08 09:50:53',3600,'2013-07-08 08:50:53',NULL,'[openstack-dev] sqlalchemy 0.8 and Grizzly','On Mon, 2013-07-08 at 15:53 +0800, Thomas Goirand wrote:\n> Hi,\n> \n> Since python-sqlalchemy 0.8.2 has been uploaded to Sid, Quantum is\n> uninstallable there right now (see #715294).\n> \n> I am wondering: what\'s wrong with sqlalchemy >= 0.8, so that it is\n> written explicitly in the requirements that we shouldn\'t use it? Is\n> there a chance that having such a version of sqlalchemy will make all of\n> OpenStack grizzly fail? What are the consequences? Would it be safe to\n> simply patch the requirements file and ignore this?\n\nDon\'t really have a comment on the specifics, but ...\n\nWe should definitely avoid being overly aggressive with our version caps\nbecause they cause issues like this.\n\nThe principle should be that we take the time to understand the\ndependencies versioning scheme and use a the version cap which we think\nwill insulate us from incompatible changes without preventing us from\nusing perfectly compatible versions.\n\nThat\'s not always easy. If a library makes a commitment to changing it\'s\nmajor version if it makes an incompatible change, you can do:\n\n  >=x.y.z,<x+1\n\nbut there are cases where we know that minor version number increases\nare very likely to include incompatible changes so we do:\n\n  >=x.y.z,<x.y+1\n\nThat\'s the case with sqlalchemy, I guess. Before 0.8 ever existed, we\nexpected that 0.8 would contain incompatible changes.\n\nCheers,\nMark.\n\n\n\n','<51DA700F.6010400@debian.org>',NULL),('<1373315406-sup-4724@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-08 13:35:34',-25200,'2013-07-08 20:35:34',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','Excerpts from Adam Young\'s message of 2013-07-08 13:18:55 -0700:\n> On 07/01/2013 01:35 PM, Clint Byrum wrote:\n> > The way the new keystone-manage command \"token_flush\" works right now\n> > is quite broken by MySQL and InnoDB\'s gap locking behavior:\n> >\n> > https://bugs.launchpad.net/1188378\n> >\n> > Presumably other SQL databases like PostgreSQL will have similar problems\n> > with doing massive deletes, but I am less familiar with them.\n> >\n> > I am trying to solve this in keystone, and my first attempt is here:\n> >\n> > https://review.openstack.org/#/c/32044/\n> >\n> > However, MySQL does not support using \"LIMIT\" in a sub-query that\n> > is feeding an IN() clause, so that approach will not work. Likewise,\n> > sqlalchemy does not support the MySQL specific extension to DELETE which\n> > allows it to have a LIMIT clause.\n> >\n> > Now, I can do some hacky things, like just deleting all of the expired\n> > tokens from the oldest single second, but that could also potentially\n> > be millions of tokens, and thus, millions of gaps to lock.\n> >\n> > So, there is just not one way to work for all databases, and we have to\n> > have a special mode for MySQL.\n> >\n> > I was wondering if anybody has suggestions and/or examples of how to do\n> > that with sqlalchemy.\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> In general, if you have millions of roles, you need a real database.  I \n> would not try to work through SQL Alchemy for this. Instead, you \n> probably just want to make sure that the token_flush is run fairly \n> regularly on your database.\n> \n\nI\'m not sure I understand you.\n\n* I am asking about millions of tokens, not roles.\n* I am asking about MySQL.. presumably a \"real\" database.\n* In the bug, I am suggesting that running token_flush once every\n  second will be _a disaster_ on a busy site with MySQL because of\n  the gap locking behavior in InnoDB. We need to delete a small number\n  per transaction.\n\n\n','<51DB1EAF.20808@redhat.com>',NULL),('<1373332843-sup-8308@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-08 20:06:22',-25200,'2013-07-09 03:06:22',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','Excerpts from Adam Young\'s message of 2013-07-08 17:32:30 -0700:\n> On 07/08/2013 04:35 PM, Clint Byrum wrote:\n> > Excerpts from Adam Young\'s message of 2013-07-08 13:18:55 -0700:\n> >> On 07/01/2013 01:35 PM, Clint Byrum wrote:\n> >>> The way the new keystone-manage command \"token_flush\" works right now\n> >>> is quite broken by MySQL and InnoDB\'s gap locking behavior:\n> >>>\n> >>> https://bugs.launchpad.net/1188378\n> >>>\n> >>> Presumably other SQL databases like PostgreSQL will have similar problems\n> >>> with doing massive deletes, but I am less familiar with them.\n> >>>\n> >>> I am trying to solve this in keystone, and my first attempt is here:\n> >>>\n> >>> https://review.openstack.org/#/c/32044/\n> >>>\n> >>> However, MySQL does not support using \"LIMIT\" in a sub-query that\n> >>> is feeding an IN() clause, so that approach will not work. Likewise,\n> >>> sqlalchemy does not support the MySQL specific extension to DELETE which\n> >>> allows it to have a LIMIT clause.\n> >>>\n> >>> Now, I can do some hacky things, like just deleting all of the expired\n> >>> tokens from the oldest single second, but that could also potentially\n> >>> be millions of tokens, and thus, millions of gaps to lock.\n> >>>\n> >>> So, there is just not one way to work for all databases, and we have to\n> >>> have a special mode for MySQL.\n> >>>\n> >>> I was wondering if anybody has suggestions and/or examples of how to do\n> >>> that with sqlalchemy.\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> In general, if you have millions of roles, you need a real database.  I\n> >> would not try to work through SQL Alchemy for this. Instead, you\n> >> probably just want to make sure that the token_flush is run fairly\n> >> regularly on your database.\n> >>\n> > I\'m not sure I understand you.\n> >\n> > * I am asking about millions of tokens, not roles.\n> Heh, I mean Rows, and somehow type roles.\n> \n> > * I am asking about MySQL.. presumably a \"real\" database.\n>   I have to admit I am a bit of a Postgresql Bigot. I don\'t really \n> consider MySQL a real database, althought it has improved a lot over the \n> years.  I am not up to speed on\"InnoDB\'s gap locking behavior\" but it is \n> not something I would expect to be a problem in Postgresql.\n> \n\nYou may want to update your snark! MySQL has its warts which are pretty\neasy to take shots at, but it has been a \"real\" ACID compliant database\nfor well over a decade.\n\nPlease have a read at how InnoDB\'s isolation level handling works\n[1]. You can compare it to Postgres [2]. InnoDB\'s default isolation\nlevel, repeatable read, has a locking behavior that is particularly\nugly for indexes like \'token.valid\'. Put simply, you can\'t add more\nvalid tokens until you\'re done deleting any valid expired tokens (if\nyou mention valid in the delete, which flush_tokens does not).\n\nThis is because token.valid == 1 may end up locked during the entire\nDELETE. The same could be true for expires too, even the primary key,\nthough that is typically not locked with ranges.\n\nYes, Postgres\'s behaviors are much more desirable here, as inserts almost\ngo unmentioned in the postgres description of transaction isolation. But\nthere are well documented ways of working around this weirdness. I had\nforgotten that one way is to use READ UNCOMMITTED. That should avoid\nany of the large range locks and work with MySQL, Postgres, and Sqlite.\n\n[1] http://dev.mysql.com/doc/refman/5.5/en/set-transaction.html#isolevel_repeatable-read\n[2] http://www.postgresql.org/docs/9.1/static/transaction-iso.html#MVCC-SERIALIZABILITY\n\n> > * In the bug, I am suggesting that running token_flush once every\n> >    second will be _a disaster_ on a busy site with MySQL because of\n> >    the gap locking behavior in InnoDB. We need to delete a small number\n> >    per transaction.\n> once every second would be strange indeed.  I would think maybe once \n> every five minutes or so.  Schedule your clean up IAW your deployment \n> and usage.\n> \n> Deleting a chunk of tokens in bulk would be preferable to doing client \n> side iteration, I can;t see how that would not be the case.\n> \n\nOnce every second or once every 5 minutes, the locks pile up the longer\nthe DELETE takes.\n\nUsing pt-archiver, the locks span just a few hundred rows at a time, and\nwe can also be \"gentle\" with the server, sleeping a bit between deletes,\nwhich allows us to not waste precious OLTP time on archiving/deleting.\n\n\n','<51DB5A1E.2050908@redhat.com>',NULL),('<1373340851.5657.29.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 13:34:11',36000,'2013-07-09 03:34:11',NULL,'[openstack-dev] [Keystone] Best way to do something\n MySQL-specific?','On Mon, 2013-07-08 at 21:55 -0400, Adam Young wrote:\n> \n> Tokens are, for the most part, immutable.  Once they are written, they\n> don\'t change except if they get revoked.  This is a fairly rare\n> occurance, but it does happen.\n> \n> Deleting tokens based on age should be fairly straight forward, and\n> locks should not need to be held for a significant amount of time.\n> \n> My guess, however, is that the problem is SQL Alchemy:\n> \n>         query = session.query(TokenModel)\n>         query = query.filter(TokenModel.expires < timeutils.utcnow())\n>         query.delete(synchronize_session=False)\n> \n> If it is doing a fetch and then the delete, then the rows would be\n> held for a short period of time.\n> \n> Direct SQL might be a better approach:  prepare a statement:\n> \n> \"delete from token where expires < $1\"\n\nSqlalchemy already generates this statement.  \n\n> and then bind and execute in one command.\n> \n> However, it seems to me that the conflict detection is the problem.  I\n> don\'t know if there is a way to state \"ignore any future queries that\n> would match this criteria.\"   It does seem to me that even doing this\n> degree of conflict detection is somewhat violating the principal of\n> Isolation.\n> \n> There might be an approach using table partitioning as well, where you\n> only write to partition one, and delete from partition 2, and then\n> swap.\n> \n> \n> \n> \n> \n> On 07/08/2013 09:13 PM, Robert Collins wrote:\n> \n> > On 9 July 2013 12:32, Adam Young <ayoung at redhat.com> wrote:\n> >  \n> >                 * I am asking about MySQL.. presumably a \"real\"\n> >                 database.\n> >          I have to admit I am a bit of a Postgresql Bigot. I don\'t\n> >         really consider MySQL a real database, althought it has\n> >         improved a lot over the years.  I am not up to speed\n> >         on\"InnoDB\'s gap locking behavior\" but it is not something I\n> >         would expect to be a problem in Postgresql.\n> > \n> > PostgreSQL has similar but different characteristics, particular the\n> > latest iteration of isolation behaviour where locks are held on *the\n> > result of a query*, not on \'specific rows returned\' - the difference\n> > being that adding a new row that matches the query for rows to\n> > delete, would encounter a conflict. You also need to delete small\n> > numbers of rows at a time, though the reason in the plumbing is\n> > different. There are some nasty interlocks you can cause with very\n> > large deletes and autovacuum too - if you trigger deadlock detection\n> > it still takes /minutes/ to detect and cleanup, whereas we want\n> > sub-second liveness.\n> >  \n> >         once every second would be strange indeed.  I would think\n> >         maybe once every five minutes or so.  Schedule your clean up\n> >         IAW your deployment and usage.\n> > \n> > 5m intervals exacerbate the issue until it\'s solved. If the cleanup\n> > deletes no more than (say) 1000 rows per iteration, it could run\n> > every 5 minutes but when run keep going until the db is cleaned.\n> >  \n> >         Deleting a chunk of tokens in bulk would be preferable to\n> >         doing client side iteration, I can;t see how that would not\n> >         be the case.\n> > \n> > right, so I think Clint prefers that too, the question is how to get\n> > sqlalchemy to output the appropriate sql for postgresql and mysql,\n> > which is different. \n> > \n\nI\'m not experienced with large databases but i wrote the token_flush so\ni\'m interested. What am i missing that we can\'t just add a --limit\nparameter to the command line tool so \"keystone-manage token_flush\n--limit=1000\" which is (as was mentioned) deleting 1000 in a command. \n\nSA will be able to generate a nested query like:\n\"delete from token where id in (select id from token limit 1000)\" \nfor all databases. What sort of hit is something nested like that? Then\nyou tweak the limit and the frequency but i would suggest 1000 every 5\nminutes should result in a net negative token count and wouldn\'t come\nclose to the locks. \n\nIt will take time to clear the backlog but it is supposed to be a\nmaintenance utility. \n\n\n> > \n> > -Rob\n> >  \n> > \n> > -- \n> > Robert Collins <rbtcollins at hp.com>\n> > Distinguished Technologist\n> > HP Cloud Services \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<51DB6D7B.40202@redhat.com>',NULL),('<1373364663.2407.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 11:11:03',3600,'2013-07-09 10:11:03',NULL,'[openstack-dev] Program description for Oslo','Hey\n\nThe mission statement is what we\'ve been using for a while. The\n\"official title\" is new.\n\n  Official Title: OpenStack Common Libraries\n  PTL: Mark McLoughlin <markmc at redhat.com>\n  Mission Statement:\n    To produce a set of python libraries containing infrastructure code \n    shared by OpenStack projects. The APIs provided by these libraries\n    should be high quality, stable, consistent and generally applicable.\n\nI did consider explicitly mentioning technical debt with something like:\n\n  Mission Statement:\n    To tackle copy-and-paste technical debt in OpenStack by producing a\n    set of python libraries containing infrastructure code shared by\n    OpenStack projects. The APIs provided by these libraries should be\n    high quality, stable, consistent and generally applicable.\n\nBut for wholly new code, that sounds like you need to introduce\ncopy-and-paste technical debt before it can be considered in scope for\nOslo :)\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1373364796.2407.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 11:13:16',3600,'2013-07-09 10:13:16',NULL,'[openstack-dev] Draft Mission statement for tripleo','On Tue, 2013-07-09 at 20:21 +1200, Robert Collins wrote:\n> On 9 July 2013 20:12, Thierry Carrez <thierry at openstack.org> wrote:\n> \n> > Robert Collins wrote:\n> > > I thought I would get some input on a draft statement before submitting\n> > > one for the TC to vote on.\n> > >\n> > > We\'re very focused on using OpenStack components in the delivery as much\n> > > as possible - growing the capabilities of OpenStack rather than working\n> > > around things; so I\'ve captured that in the mission statement. While\n> > > we\'re focused on trunk deploys today, I think that is more tactical than\n> > > mission-level : we\'d be totally happy to work with releases (as well)\n> > > should interested people want to step up and help maintain stable\n> > > branches of the tripleo heat templates etc.\n> > >\n> > > So - here is the draft:\n> > >\n> > > Official Title: OpenStack Deployment\n> > > PTL: Robert Collins <robertc at robertcollins.net\n> > > <mailto:robertc at robertcollins.net>>\n> > > Mission Statement:\n> > >   Develop and maintain the tooling and infrastructure needed to\n> > >   deploy OpenStack in production, using OpenStack itself wherever\n> > >   possible.\n> >\n> > Looks good. Personally I\'d probably not say \"needed to deploy OpenStack\n> > in production\", which sounds a bit exclusive: I\'m not sure we want to\n> > bless one deployment method and exclude others... Maybe something like\n> > \"...tooling and infrastructure able to deploy OpenStack in production at\n> > scale, reusing OpenStack itself...\"\n> \n> \n> \n> So tripleo scales down too, the same potential issue you raise with\n> excluding other deployment methodologies applies if we say \'at scale\', in\n> reverse ;).\n> \n> How about\n> >   Develop and maintain tooling and infrastructure able to\n> >   deploy OpenStack in production, using OpenStack itself wherever\n> >   possible.\n> \n> That is s/the// - removing the implication of a singleton, and\n> s/needed/able/\n\nNice, I like it.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ1wci7Yq3HnDcm=w64=daXckTjmab=C3RCZhxm6f8F8OQ@mail.gmail.com>',NULL),('<1373366029.2407.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 11:33:49',3600,'2013-07-09 10:33:49',NULL,'[openstack-dev] Program description for Oslo','On Tue, 2013-07-09 at 11:21 +0100, Martyn Taylor wrote:\n> On 09/07/13 11:11, Mark McLoughlin wrote:\n> > Hey\n> >\n> > The mission statement is what we\'ve been using for a while. The\n> > \"official title\" is new.\n> >\n> >    Official Title: OpenStack Common Libraries\n> >    PTL: Mark McLoughlin <markmc at redhat.com>\n> >    Mission Statement:\n> >      To produce a set of python libraries containing infrastructure code\n> >      shared by OpenStack projects. The APIs provided by these libraries\n> >      should be high quality, stable, consistent and generally applicable.\n> >\n> > I did consider explicitly mentioning technical debt with something like:\n> >\n> >    Mission Statement:\n> >      To tackle copy-and-paste technical debt in OpenStack by producing a\n> >      set of python libraries containing infrastructure code shared by\n> >      OpenStack projects. The APIs provided by these libraries should be\n> >      high quality, stable, consistent and generally applicable.\n> >\n> > But for wholly new code, that sounds like you need to introduce\n> > copy-and-paste technical debt before it can be considered in scope for\n> > Oslo :)\n> >\n> > Cheers,\n> > Mark.\n> \n> Is it worth adding some emphasis on documentation in there somewhere?  \n> Specifically documentation for using the libraries and frameworks \n> offered by Oslo in OpenStack.  Maybe:\n> \n>    Mission Statement:\n>      To produce a set of python libraries containing infrastructure code\n>      shared by OpenStack projects. The APIs provided by these libraries\n>      should be high quality, stable, consistent, well documented and  \n>      generally applicable.\n\nI would have seen that as implicit, but no problem including it.\n\nCheers,\nMark.\n\n\n\n','<51DBE416.1020709@redhat.com>',NULL),('<1373367917.2407.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 12:05:17',3600,'2013-07-09 11:05:17',NULL,'[openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder,\n Glance)','On Mon, 2013-07-08 at 14:15 +0200, Nikola ?ipanov wrote:\n> On 05/07/13 14:26, Boris Pavlovic wrote:\n> > Hi all, \n> > \n> > I would like to explain very high level steps of our work: \n> > 1) Sync work with DB in all projects (We have what we have, let it be in\n> > one place)\n> > 2) Refactor work with DB in one place (not independently in all projects) \n> > \n> > So I understand that our code around DB is not ideal, but let it be in\n> > one place at first.\n> > \n> \n> This is fine in principle, however I don\'t think we should push it\n> without considering the details (where the devil is apparently).\n> I am arguing that DB archiving should be re-done and is broken\n> conceptually (example below), and I think it would be suboptimal (to say\n> the least) to get it everywhere first and then fix it.\n> \n> Just saying a hand-wavy \"yeah, but once it\'s in Oslo we can fix it\" is\n> wrong - especially for functionality that is younger than the time it\n> will likely take it to \'graduate\' Oslo.\n\nI\'m not following this DB archiving debate closely enough to take a\nposition either way, but ....\n\nI think what you\'re really arguing is that no other project should adopt\nthis approach to DB archiving. I\'m fine with saying that it shouldn\'t\nmove into oslo-incubator if it will only be used in Nova.\n\nSo - the debate to have is which projects are proposing to adopt this DB\narchiving strategy and whether it makes sense for them to adopt it as is\nand fix it up later, or adopt an entirely different approach.\n\nCheers,\nMark.\n\n\n\n','<51DAAD4E.2000208@redhat.com>',NULL),('<1373374182.2407.93.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 13:49:42',3600,'2013-07-09 12:49:42',NULL,'[openstack-dev] Program description for Oslo','On Tue, 2013-07-09 at 08:41 -0400, Jonathan Bryce wrote:\n> Any reason for not just calling it \"OpenStack Commons\"?\n\nYes - we\'re very much focused on libraries of shared code. When we used\nthe name \"OpenStack Common\" previously, people made all sorts of weird\nassumptions about what could go in there.\n\nCheers,\nMark.\n\n> Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> >Hey\n> >\n> >The mission statement is what we\'ve been using for a while. The\n> >\"official title\" is new.\n> >\n> >  Official Title: OpenStack Common Libraries\n> >  PTL: Mark McLoughlin <markmc at redhat.com>\n> >  Mission Statement:\n> >    To produce a set of python libraries containing infrastructure code \n> >    shared by OpenStack projects. The APIs provided by these libraries\n> >    should be high quality, stable, consistent and generally applicable.\n> >\n> >I did consider explicitly mentioning technical debt with something like:\n> >\n> >  Mission Statement:\n> >    To tackle copy-and-paste technical debt in OpenStack by producing a\n> >    set of python libraries containing infrastructure code shared by\n> >    OpenStack projects. The APIs provided by these libraries should be\n> >    high quality, stable, consistent and generally applicable.\n> >\n> >But for wholly new code, that sounds like you need to introduce\n> >copy-and-paste technical debt before it can be considered in scope for\n> >Oslo :)\n> >\n> >Cheers,\n> >Mark.\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<370av6qw9lrlv71i1sgjyrk3.1373373685859@email.android.com>',NULL),('<1373382777-sup-2459@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 08:21:04',-25200,'2013-07-09 15:21:04',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','Excerpts from Adam Young\'s message of 2013-07-09 06:19:19 -0700:\n> On 07/08/2013 11:06 PM, Clint Byrum wrote:\n> > Excerpts from Adam Young\'s message of 2013-07-08 17:32:30 -0700:\n> >> On 07/08/2013 04:35 PM, Clint Byrum wrote:\n> >>> Excerpts from Adam Young\'s message of 2013-07-08 13:18:55 -0700:\n> >>>> On 07/01/2013 01:35 PM, Clint Byrum wrote:\n> >>>>> The way the new keystone-manage command \"token_flush\" works right now\n> >>>>> is quite broken by MySQL and InnoDB\'s gap locking behavior:\n> >>>>>\n> >>>>> https://bugs.launchpad.net/1188378\n> >>>>>\n> >>>>> Presumably other SQL databases like PostgreSQL will have similar problems\n> >>>>> with doing massive deletes, but I am less familiar with them.\n> >>>>>\n> >>>>> I am trying to solve this in keystone, and my first attempt is here:\n> >>>>>\n> >>>>> https://review.openstack.org/#/c/32044/\n> >>>>>\n> >>>>> However, MySQL does not support using \"LIMIT\" in a sub-query that\n> >>>>> is feeding an IN() clause, so that approach will not work. Likewise,\n> >>>>> sqlalchemy does not support the MySQL specific extension to DELETE which\n> >>>>> allows it to have a LIMIT clause.\n> >>>>>\n> >>>>> Now, I can do some hacky things, like just deleting all of the expired\n> >>>>> tokens from the oldest single second, but that could also potentially\n> >>>>> be millions of tokens, and thus, millions of gaps to lock.\n> >>>>>\n> >>>>> So, there is just not one way to work for all databases, and we have to\n> >>>>> have a special mode for MySQL.\n> >>>>>\n> >>>>> I was wondering if anybody has suggestions and/or examples of how to do\n> >>>>> that with sqlalchemy.\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>> In general, if you have millions of roles, you need a real database.  I\n> >>>> would not try to work through SQL Alchemy for this. Instead, you\n> >>>> probably just want to make sure that the token_flush is run fairly\n> >>>> regularly on your database.\n> >>>>\n> >>> I\'m not sure I understand you.\n> >>>\n> >>> * I am asking about millions of tokens, not roles.\n> >> Heh, I mean Rows, and somehow type roles.\n> >>\n> >>> * I am asking about MySQL.. presumably a \"real\" database.\n> >>    I have to admit I am a bit of a Postgresql Bigot. I don\'t really\n> >> consider MySQL a real database, althought it has improved a lot over the\n> >> years.  I am not up to speed on\"InnoDB\'s gap locking behavior\" but it is\n> >> not something I would expect to be a problem in Postgresql.\n> >>\n> > You may want to update your snark! MySQL has its warts which are pretty\n> > easy to take shots at, but it has been a \"real\" ACID compliant database\n> > for well over a decade.\n> My snark is more recently generated than that.  There are plenty of \n> places where MySQL has fallen down.\n> \n> InnoDB support was not mandatory, and without it, MySQL was not really \n> ACID compliant.  Using InnoDB was troublesome enough that the RHEL 6 \n> version of MySQL defaults to MyISAM.\n> \n\nIts not so much that it was troublesome to use InnoDB as it was that\npeople were used to MyISAM\'s few mis-features (fulltext and delayed\ninserts mostly) and needed a long warning (run up to 5.5) that the\ndefault was changing. Before 5.5 was released, Drizzle _completely\nremoved_ MyISAM because it causes way more problems than it solves.\n\n> >\n> > Please have a read at how InnoDB\'s isolation level handling works\n> > [1]. You can compare it to Postgres [2]. InnoDB\'s default isolation\n> > level, repeatable read, has a locking behavior that is particularly\n> > ugly for indexes like \'token.valid\'. Put simply, you can\'t add more\n> > valid tokens until you\'re done deleting any valid expired tokens (if\n> > you mention valid in the delete, which flush_tokens does not).\n> >\n> > This is because token.valid == 1 may end up locked during the entire\n> > DELETE. The same could be true for expires too, even the primary key,\n> > though that is typically not locked with ranges.\n> >\n> > Yes, Postgres\'s behaviors are much more desirable here, as inserts almost\n> > go unmentioned in the postgres description of transaction isolation. But\n> > there are well documented ways of working around this weirdness. I had\n> > forgotten that one way is to use READ UNCOMMITTED. That should avoid\n> > any of the large range locks and work with MySQL, Postgres, and Sqlite.\n> \n> \n> I think the real solution is for us to stop writing tokens to the \n> Database.  If we are using PKI tokens, there is no need for a database \n> entry for valid tokens, only for revoked tokens.\n> \n> That makes this whole thing into a non-problem.\n\nYes please! Is this something that is in development, or at least recorded\nin a bug that someone like me can grab? I would love for that to be the\ndefault behavior.\n\nOf course, that would not solve the issue for those who want to audit\ntokens (is this a large contingent of users?). In fact the flush tokens\ncommand would be bad for those users as well, whereas pt-archiver\'s\nnibbling approach that copies rows out of the table into another database\nwould work quite nicely.\n\n\n','<51DC0DD7.5020703@redhat.com>',NULL),('<1373383421.2407.98.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 16:23:41',3600,'2013-07-09 15:23:41',NULL,'[openstack-dev] Program Proposal: refstack','Hey,\n\nOn Tue, 2013-07-09 at 11:01 -0400, Monty Taylor wrote:\n> Hey all,\n> \n> I\'d like to propose an official program to the TC - refstack, a program\n> for verifying interoperability between implementations via FITS testing.\n> \n> Official Title: OpenStack Interoperability\n> Initial PTL: Monty Taylor <mordred at inaugust.com>\n> Mission Statement:\n>   Develop and maintain FITS testing and interoperability reporting for\n>   OpenStack deployments and distributions.\n> \n> For a little background, the specific incarnation of the idea for this\n> came up at the last in-person Foundation Board meeting, and I think it\'s\n> a good idea. Also, it turns out there?s a reference in the logo\n> guidelines stating that any FITS defined by the TC and made available by\n> OpenStack needs to be passed before the logos can be used for a product.\n> \n> Follow on discussions were held at the summit, and a general approach of\n> basing the testing of clouds on tempest was agreed to. The general idea\n> is that for any given cloud, refstack will run tempest against the cloud\n> in a standard configuration (not re-configuring tempest on a per-cloud\n> basis) This will result in a set of passing and failing tests. That\n> output then needs to be processed and presented in a way that it can be\n> the basis of determining which elements are compliant and not. The\n> ultimate decisions around which elements would be \'required\' to be a\n> compliant deployment would come back to the TC, and how that compliance\n> translates in to trademark usage goes back to the board. But it\'s the\n> job of refstack to be able to test the candidate cloud and report on its\n> actual capabilities.\n> \n> In conjunction with this a \'reference\' deployment config is needed, so\n> that we can validate that our test is passable. At the moment I would\n> expect this to be the de-facto standard which is devstack, but that\'s\n> ultimately a happenstance and opportunistic config, and over time the\n> refstack program would be involved in helping to define a deployment\n> configuration or configurations that we as a community feel should\n> reasonably be expected to pass our own FITS testing.\n> \n> Expected outputs:\n>  - A service for submission of cloud endpoint information for testing\n>  - Processing of tempest output into a service compliance report\n>  - One or more deployment configurations that can, themselves, pass the\n> testing 100%\n\nWhat\'s the progress been to date? What team of folks has been working on\nit?\n\nI see:\n\n  http://refstack.org/\n  https://etherpad.openstack.org/RefStackBlueprint\n  https://github.com/openstack-ops/refstack\n\nThis should be similar to how we evaluate project proposals - I\'d expect\nto see a decent amount of initial progress and a fairly well solidified\nteam before accepting a new program.\n\nCheers,\nMark.\n\n\n\n','<51DC25AE.2060104@inaugust.com>',NULL),('<1373384610.2407.101.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 16:43:30',3600,'2013-07-09 15:43:30',NULL,'[openstack-dev] Program description for Oslo','On Tue, 2013-07-09 at 11:39 -0400, Doug Hellmann wrote:\n> \n> \n> \n> On Tue, Jul 9, 2013 at 6:11 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         Hey\n>         \n>         The mission statement is what we\'ve been using for a while. The\n>         \"official title\" is new.\n>         \n>           Official Title: OpenStack Common Libraries\n>           PTL: Mark McLoughlin <markmc at redhat.com>\n>           Mission Statement:\n>             To produce a set of python libraries containing infrastructure code\n>             shared by OpenStack projects. The APIs provided by these libraries\n>             should be high quality, stable, consistent and generally applicable.\n> \n> \n> +1\n> \n> \n> What sort of code would not be \"infrastructure\" but would be \"shared\n> by OpenStack projects\"? Is the \"infrastructure\" redundant?\n\nSimply saying \"code\" isn\'t enterprisey enough\n\n(Point taken, removed :)\n\nMark.\n\n\n\n\n\n','<CADb+p3S_tZfH0cCSJ1P6JQ7M+6E_njxiiBu5o3A5Z5n7purm4A@mail.gmail.com>',NULL),('<1373385314.77546.YahooMailNeo@web193302.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 23:55:14',28800,'2013-07-09 15:55:14',NULL,'[openstack-dev] [Keystone] How to write unit tests for db methods?','How to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130709/87b3d34a/attachment.html>\n\n',NULL,NULL),('<1373393076-sup-3721@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-09 11:05:02',-25200,'2013-07-09 18:05:02',NULL,'[openstack-dev] Draft Mission statement for tripleo','Excerpts from Robert Collins\'s message of 2013-07-09 01:21:34 -0700:\n> How about\n> >   Develop and maintain tooling and infrastructure able to\n> >   deploy OpenStack in production, using OpenStack itself wherever\n> >   possible.\n> \n\n+1\n\n\n','<CAJ3HoZ1wci7Yq3HnDcm=w64=daXckTjmab=C3RCZhxm6f8F8OQ@mail.gmail.com>',NULL),('<1373453762.70307.YahooMailNeo@web193305.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 18:56:02',28800,'2013-07-10 10:56:02',NULL,'[openstack-dev] [Keystone] How to write unit tests for db\n	methods?','I have added 2 tables to keystone. I have methods which do the read/write/update/delete of records in these tables. I want to write unit test for all this. These methods of mine inherit from keystone.common.sql and hence any call that these methods will make will go to the db returned by keystone.common.sql when creating a session. For writing a unit test this db should be a test db and not the production db. So, how can I have a session of test db? or is there altogether a different way of writing the unit test.\n\n\n\n\n________________________________\n From: Dolph Mathews <dolph.mathews at gmail.com>\nTo: Akshat Kakkar <the_akshat at yahoo.co.in>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Tuesday, 9 July 2013 7:39 PM\nSubject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n \n\n\nI\'m assuming you\'re referring to testing backend drivers as opposed to database migrations (tests/test_sql_upgrade.py).\n\nBackend agnostic tests land in tests/test_backend.py. Backend-specific tests, overrides, etc belong in tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.\n\nGenerally, you can\'t assume that keystone is backed by a database, however, as it\'s entirely possible to deploy without one.\n\n\n\nOn Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n\nHow to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n\n\n-- \n\n-Dolph \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/e0a68a70/attachment.html>\n\n','<CAC=h7gW5HXKFFYXHChJ0jFQ4rdmgSkVy3FHCUUDjqrPn701gOg@mail.gmail.com>',NULL),('<1373457767.9581.59.camel@atomic.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-10 08:02:47',-14400,'2013-07-10 12:02:47',NULL,'[openstack-qa] Draft QA mission statement','On Tue, 2013-07-09 at 09:24 -0400, Sean Dague wrote:\n> Official Title: OpenStack Quality Assurance\n> PTL: TBD\n> Mission Statement: Develop and maintain tools to ensure the upstream \n> stability and quality of OpenStack, and it\'s release readiness at any \n> point during the cycle.\n> \n> Trying to not get too far behind the other programs, here\'s a draft \n> mission statement. Word smithing would be appreciated.\n\nMaybe I\'m being too pedantic, but the statement above is focused\nentirely on the development and maintenance of tools and says nothing\nabout the execution of these tools, thus implying another group will\ntake that responsibility.  I do not believe that to be the case :-)  \n\n\"Develop, maintain, and initiate tools and plans to ensure the upstream\nstability and quality of OpenStack, and its release readiness at any\npoint during the cycle.\"\n\n- jkt\n\n-- \n--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*\nJay Turner, Director, Quality Engineering    jkt at redhat.com    Red Hat, Inc.\n\n        \"Only two things are infinite, the universe and human\n        stupidity, and I\'m not sure about the former.\" - Albert Einstein\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-qa/attachments/20130710/e4555efd/attachment.pgp>\n\n','<51DC0F00.6080109@dague.net>',NULL),('<1373481175.2407.176.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 19:32:55',3600,'2013-07-10 18:32:55',NULL,'[openstack-dev] [Review] Use of exception for non-exceptional\n cases','On Wed, 2013-07-10 at 11:01 -0700, Nachi Ueno wrote:\n> HI folks\n> \n> I would like to ask the review criteria in the community.\n> \n> Should we use exception for non-exceptional cases when we can use\n>  parameter checking?\n> \n> Example1:  Default value for array index\n> \n> try:\n>    value = list[5]\n> except IndexError:\n>     value = \'default_value\'\n> \n> This can be also written as,\n> \n>      list_a[3] if len(list_a) > 3 else \'default_value\'\n> \n> \"ask for forgiveness, not permission\" is one of way in python,\n> however, on the other hand, google python code style guide says,\n> -------------\n> Minimize the amount of code in a try/except block. The larger the body\n> of the try, the more likely that an exception will be raised by a line\n> of code that you didn\'t expect to raise an exception. In those cases,\n> the try/except block hides a real error.\n> ---------------\n> http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Exceptions\n\nI don\'t think this statement contradicts the intent of EAFP.\n\n> Personally, I prefer not to use exception for such cases.\n\nMy instinct is the same, but EAFP does seem to be the python way. There\nare times I can tolerate the EAFP approach but, even then, I generally\nthink LBYL is cleaner.\n\nI can live with something like this:\n\n  try:\n      return obj.foo\n  except AttributeError:\n      pass\n\nbut this is obviously broken:\n\n  try:\n      return self.do_something(obj.foo)\n  except AttributeError:\n      pass\n\nsince AttributeError will mask a typo with the do_something() call or an\nAttributeError raised from inside do_something()\n\nBut I fail to see what\'s wrong with this:\n\n  if hasattr(obj, \'foo\'):\n      return obj.foo\n\nCheers,\nMark.\n\n\n\n','<CABJepwjxxMWe-Ynkjga7T8HdnORrapekfmy2JaweK8e5vwkrDw@mail.gmail.com>',NULL),('<1373509440-sup-9248@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 19:42:48',-25200,'2013-07-11 02:42:48',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','Excerpts from Adam Young\'s message of 2013-07-10 19:14:45 -0700:\n> On 07/09/2013 09:51 PM, Robert Collins wrote:\n> > PostgreSQL doesn\'t do gap locks, but instead you have to deal with \n> > http://wiki.postgresql.org/wiki/SSI : the transaction that is deleting \n> > 1M rows, for instance, will have a query that may return rows which \n> > another transaction is adding; if so one of the two will be rolled \n> > back. This is in many ways equivalent from the point of view of \n> > writing good SQL that will work well on both systems.\n> \n> This is not a problem with token cleanup path, though. Tokens are \n> cleaned up based on expiry time, a value that is written and never \n> changed.  Tokens should never be removed from the database until their \n> expiry has been hit, or valid tokens will be denied.\n> \n\nNote that when the memory limit is reached, memcached will delete the\nleast recently used key in a slab that is full, whether it has reached\nits TTL or not. If backends have to guarantee tokens will live for the\nlife of the token, memcached is inappropriate without ensuring it never\nfills up or using the -M flag, which will then break a basic assumption\nthat items over TTL will be removed to free up space.\n\nI think at some point clients have to expect tokens that should still\nbe valid might not be, and look at \"invalid token\" as a re-triable error.\n\n\n','<51DE1515.6070107@redhat.com>',NULL),('<1373510895-sup-4385@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 20:11:36',-25200,'2013-07-11 03:11:36',NULL,'[openstack-dev] [Keystone] Best way to do something\n	MySQL-specific?','Excerpts from Adam Young\'s message of 2013-07-10 19:17:24 -0700:\n> On 07/09/2013 07:33 PM, Jay Pipes wrote:\n> > On 07/08/2013 05:18 PM, Sean Dague wrote:\n> >> On 07/01/2013 01:35 PM, Clint Byrum wrote:\n> >>> The way the new keystone-manage command \"token_flush\" works right now\n> >>> is quite broken by MySQL and InnoDB\'s gap locking behavior:\n> >>>\n> >>> https://bugs.launchpad.net/1188378\n> >>>\n> >>> Presumably other SQL databases like PostgreSQL will have similar \n> >>> problems\n> >>> with doing massive deletes, but I am less familiar with them.\n> >>>\n> >>> I am trying to solve this in keystone, and my first attempt is here:\n> >>>\n> >>> https://review.openstack.org/#/c/32044/\n> >>>\n> >>> However, MySQL does not support using \"LIMIT\" in a sub-query that\n> >>> is feeding an IN() clause, so that approach will not work. Likewise,\n> >>> sqlalchemy does not support the MySQL specific extension to DELETE \n> >>> which\n> >>> allows it to have a LIMIT clause.\n> >>>\n> >>> Now, I can do some hacky things, like just deleting all of the expired\n> >>> tokens from the oldest single second, but that could also potentially\n> >>> be millions of tokens, and thus, millions of gaps to lock.\n> >>>\n> >>> So, there is just not one way to work for all databases, and we have to\n> >>> have a special mode for MySQL.\n> >>>\n> >>> I was wondering if anybody has suggestions and/or examples of how to do\n> >>> that with sqlalchemy.\n> >>\n> >> Honestly, my answer is typically to ask Jay, he understands a lot of the\n> >> ways to get SQLA to do the right thing in mysql.\n> >\n> > LOL, /me blushes.\n> >\n> > In this case, I\'d propose something like this, which should work fine \n> > for any database:\n> >\n> > cutoff = timeutils.utcnow() - 60  # one minute ago...\n> >\n> > # DELETE in 500 record chunks\n> > q = session.query(\n> >         TokenModel.id).filter(\n> >             TokenModel.expires < cutoff)).limit(500)\n> > while True:\n> >     results = q.all()\n> >     if len(results):\n> >         ids_to_delete = [r[0] for r in results]\n> >         session.query(TokenModel).filter(\n> >             TokenModel.id.in_(ids_to_delete)).delete()\n> >     else:\n> >         break\n> >\n> > Code not tested, use with caution, YMMV, etc etc...\n> \n> \n> It seems to me that it would still have the problem described in the \n> original post.  Even if you are only deleteing 500 at atime, all of the \n> tokens from the original query will be locked...but I guess that the \n> \"add new\" behavior will only have to check against a subset of the \n> tokens in the database.\n> \n\nBecause it is only a read, only the index being used must be locked,\nand only the gaps in the range that were seen. So token.expires <=cutoff\nwill be locked. Nothing creating new tokens will run into this.\n\nOf course, the locks can be avoided altogether with READ COMMITTED or\nREAD UNCOMMITTED. The problem only manifests in a SELECT when using\nREPEATABLE READ.\n\n> Are we really generating so many tokens that deleting the expired tokens \n> once per second is prohibitive?  That points to something else being wrong.\n> \n\nIn a proof of concept deployment with somewhat constant load testing\nI have seen an average of 20k - 40k tokens per hour expire. Seems to\nme that tokens are just simply not being reused as that is about 10 -\n20 times the number of actual operations done in that hour.\n\nRunning flush_tokens in a loop with sleep 1 would indeed work here. But\nif I ever stop running that in a loop, even for 15 minutes, then the\ntokens will back up and I\'ll be stuck with a massive delete again.\n\nI will test Jay\'s solution, it is closest to what I originally attempted\nbut does not suffer from MySQL\'s limitations and will likely be a single\nmethod that works reasonably well for all dbs.\n\n\n','<51DE15B4.5040402@redhat.com>',NULL),('<1373527553.2407.180.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 08:25:53',3600,'2013-07-11 07:25:53',NULL,'[openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder,\n Glance)','On Wed, 2013-07-10 at 14:14 -0600, John Griffith wrote:\n\n>         \n> Given that Cinder doesn\'t have anybody actively engaged in this other\n> than what\'s being proposed and worked on by Boris and folks, we\'d be a\n> willing candidate for most of these changes, particularly if they\'re\n> accepted in Nova to begin with.\n> \n> \n> The question of having it in oslo-incubator or not, I think ultimately\n> that\'s likely to be the best thing, but as is evident by this thread\n> it seems there are a number of things that are going to have to be\n> sorted before that happens, and I\'m not convinced that \"move things to\n> OSLO first then fix\" is the right answer.  In my opinion things should\n> be pretty solid before they go into the OSLO repo, but that\'s just my\n> 2 cents.\n> \n> \n> AS is evident by the approval of the BP\'s in Cinder and the reviews on\n> the patches that have been submitted thus far Cinder is fine going the\n> direction/implementations that have been proposed by Boris.  I would\n> like to see the debate around the archiving strategy and use of\n> alembic settled, but regardless on the Cinder side I would like to\n> move forward and make progress and as there\'s no other real effort to\n> move forward with improving the DB code in Cinder (which I think is\n> needed and very valuable) I\'m fine with most of what\'s being proposed.\n\nMy conclusion from that (admittedly based on limited understanding)\nwould be that everything Boris is proposing makes sense to copy from\nNova to oslo-incubator so Cinder can re-use it, with the exception of\nthe DB archiving strategy.\n\ni.e. we\'d improve Nova\'s DB archiving strategy before having Cinder\nadopt it.\n\nCheers,\nMark.\n\n\n\n\n','<CA+qL3LWSDQNhN9G7aBRboTB5uq1q2nNEiCuNK++B0JvT-22fMQ@mail.gmail.com>',NULL),('<1373528507-sup-8562@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 00:43:44',-25200,'2013-07-11 07:43:44',NULL,'[openstack-dev] [TripleO] mid-cycle sprint?','Excerpts from Robert Collins\'s message of 2013-07-10 20:54:26 -0700:\n> Clint suggested we do a mid-cycle sprint at the weekly meeting a\n> fortnight ago, but ETIME and stuff - so I\'m following up.\n> \n> HP would be delighted to host a get-together of TripleO contributors\n> [or \'I will be contributing soon, honest\'] folk.\n> \n> We\'re proposing a late August / early Sept time - a couple weeks\n> before H3, so we can be dealing with features that have landed //\n> ensuring necessary features *do* land.\n> \n> That would give a start date of the 19th or 26th August. Probable\n> venue of either Sunnyvale, CA or Seattle.\n\nWife booked a trip out of town August 27 - Sep 2 so that time frame is\nunavailable to me.\n\n\n','<CAJ3HoZ2keQXFngGyKEoj-Q3uxA3CVdxdRM6qtaQvccodCu_XcA@mail.gmail.com>',NULL),('<1373531953.2407.229.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 09:39:13',3600,'2013-07-11 08:39:13',NULL,'[openstack-dev] Blueprint: Separate translation domain for log\n	messages','Hi Daisy,\n\nOn Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote:\n> Hi, Mark\n> \n> I think there is a blueprint we discussed in the Havana summit to\n> separate translation domains. \n> https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> \n> I don\'t see any progress there.\n> Do you have any plan to implement it?\n> The translation team set the command line message as high priority,\n> but log messages as low priority.\n> So we want the domains can be separated.\n\nGiven that there\'s been no progress on this, I suggest we take a\npragmatic approach to allow us to move forward\n\n  - The fact that the \"high priority\" and \"low priority\" messages are \n    mixed together means we can\'t get to high levels of translations \n    for the high priority messages.\n\n  - It\'s time we deal with this issue around high priority messages with\n    some urgency, even if that means hurting the ability to have low\n    priority messages translated.\n\n  - In other words, we should submit patches to have the low priority \n    messages no longer marked for translation.\n\n  - Once someone comes up with a solution for a separate translation \n    domain for low priority messages, we can go back and mark the low \n    priority messages for translation again.\n\n  - This sounds like a lot of churn, but every low priority message \n    will need to be touched even if we come up with a solution for a \n    separate translation domain e.g. changing _() to l_()\n\nThe key thing here is to have some very concrete rules about which\nmessages are high priority and low priority. The question is more subtle\nthan it seems.\n\nFor example, if a Nova instance fails to boot, we include the \"instance\nfault\" in the detailed \"nova show\" output. Should those fault messages\nbe translated? If so, tracking down all the possible error messages that\nmight wind up there is actually quite difficult.\n\nThat said, I\'d be happy if we erred on the side of \"if we\'re not sure\nwhether it\'s user-visible, let\'s assume it\'s not\" approach.\n\nCheers,\nMark.\n\n\n\n','<OF9B53FA10.3F899E18-ON48257BA4.003539A9-48257BA4.004BE2A5@cn.ibm.com>',NULL),('<1373532627.2407.237.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 09:50:27',3600,'2013-07-11 08:50:27',NULL,'[openstack-dev] [Review] Use of exception for non-exceptional\n cases','On Wed, 2013-07-10 at 21:14 +0200, Thomas Herv? wrote:\n> \n> \n> On Wed, Jul 10, 2013 at 8:32 PM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Wed, 2013-07-10 at 11:01 -0700, Nachi Ueno wrote:\n>         \n>         > Personally, I prefer not to use exception for such cases.\n>         \n> \n> \n> The key here is \"personally\". I don\'t think we have to agree on all\n> style issues.\n\nWhen it results in a patch submitter getting a -1 from one person for\nchoosing EAFP and a -1 from another person for choosing LBYL, then\nyes ... actually we do need to agree.\n\n>         My instinct is the same, but EAFP does seem to be the python\n>         way. There\n>         are times I can tolerate the EAFP approach but, even then, I\n>         generally\n>         think LBYL is cleaner.\n>         \n>         I can live with something like this:\n>         \n>           try:\n>               return obj.foo\n>           except AttributeError:\n>               pass\n>         \n>         but this is obviously broken:\n>         \n>           try:\n>               return self.do_something(obj.foo)\n>           except AttributeError:\n>               pass\n>         \n>         since AttributeError will mask a typo with the do_something()\n>         call or an\n>         AttributeError raised from inside do_something()\n>         \n>         But I fail to see what\'s wrong with this:\n>         \n>           if hasattr(obj, \'foo\'):\n>               return obj.foo\n> \n> \n> hasattr is a bit dangerous as it catches more exceptions than it needs\n> too. See for example \n> http://stackoverflow.com/questions/903130/hasattr-vs-try-except-block-to-deal-with-non-existent-attributes/16186050#16186050 for an explanation.\n\nThat answer does begin with this, though:\n\n  I almost always use hasattr: it\'s the correct choice for most cases.\n\nand, frankly, a __getattr__() method that returns ValueError is broken.\n\ni.e. the conclusion would be that we should only avoid hasattr() in some\nvery limited cases where the underlying __getattr__() does weird things\nor where using it can result in a race condition.\n\nCheers,\nMark.\n\n\n\n\n','<CA+G4qugqqs1SoA5ocEVTnBPf3iXgyMQ2VCuHX-TOS9n2FerBuQ@mail.gmail.com>',NULL),('<1373533183.2407.239.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 09:59:43',3600,'2013-07-11 08:59:43',NULL,'[openstack-dev] Blueprint: Separate translation domain for log\n messages','On Thu, 2013-07-11 at 09:56 +0100, Joe Gordon wrote:\n> \n> \n> \n> On Thu, Jul 11, 2013 at 9:39 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         Hi Daisy,\n>         \n>         On Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote:\n>         > Hi, Mark\n>         >\n>         > I think there is a blueprint we discussed in the Havana summit to\n>         > separate translation domains.\n>         > https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n>         >\n>         > I don\'t see any progress there.\n>         > Do you have any plan to implement it?\n>         > The translation team set the command line message as high priority,\n>         > but log messages as low priority.\n>         > So we want the domains can be separated.\n>         \n>         Given that there\'s been no progress on this, I suggest we take a\n>         pragmatic approach to allow us to move forward\n>         \n>           - The fact that the \"high priority\" and \"low priority\" messages are\n>             mixed together means we can\'t get to high levels of translations\n>             for the high priority messages.\n>         \n>           - It\'s time we deal with this issue around high priority messages with\n>             some urgency, even if that means hurting the ability to have low\n>             priority messages translated.\n>         \n>           - In other words, we should submit patches to have the low priority\n>             messages no longer marked for translation.\n>         \n>           - Once someone comes up with a solution for a separate translation\n>             domain for low priority messages, we can go back and mark the low\n>             priority messages for translation again.\n>         \n>           - This sounds like a lot of churn, but every low priority message\n>             will need to be touched even if we come up with a solution for a\n>             separate translation domain e.g. changing _() to l_()\n>         \n>         The key thing here is to have some very concrete rules about which\n>         messages are high priority and low priority. The question is more subtle\n>         than it seems.\n> \n> \n> What about starting with log messages are all low priority (except\n> perhaps for the error level?).  A quick grep shows these are *roughly*\n> half of the translations.\n\nI\'m cool with that as a first baby step. Whatever it takes to get the\nnumber of log messages down to something that is reasonable to expect\ntranslators to translate.\n\nUnless it\'s plausible for a translator to get to 100% of our messages,\nthen some of the highly user-visible messages won\'t be translated.\n\nCheers,\nMark.\n\n\n\n\n','<CAHXdxOdsRskembZH-Ac1JGXRbpVU+rFEDxxmJ+POkPw81d9+Vg@mail.gmail.com>',NULL),('<1373534423.2407.247.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 10:20:23',3600,'2013-07-11 09:20:23',NULL,'[openstack-dev] [Review] Use of exception for non-exceptional\n cases','On Wed, 2013-07-10 at 19:49 -0400, Monty Taylor wrote:\n> I\'d like top-post and hijack this thread for another exception related\n> thing:\n> \n> a) Anyone writing code such as:\n> \n> try:\n>   blah()\n> except SomeException:\n>   raise SomeOtherExceptionLeavingOutStackContextFromSomeException\n> \n> should be mocked ruthlessly.\n\nOk, mock me ruthlessly then.\n\nPart of designing any API is specifying what predictable exceptions it\nwill raise. For any predictable error condition, you don\'t want callers\nto have to catch random exceptions from the underlying libraries you\nmight be calling into.\n\nSay if I was designing an image downloading API, I\'d do something like\nthis:\n\n  https://gist.github.com/markmc/5973868\n\nAssume there\'s a tonne more stuff that the API would do. You don\'t want\ncallers to have to catch socket.error exceptions and whatever other\nexceptions might be thrown.\n\nThat works out as:\n\n  Traceback (most recent call last):\n    File \"t.py\", line 20, in <module>\n      download_image(\'localhost\', 3366, \'foobar\')\n    File \"t.py\", line 18, in download_image\n      raise ImageDownloadFailure(host, port, path, e.strerror)\n  __main__.ImageDownloadFailure: Failed to download foobar from localhost:3366: Connection refused\n\nWhich is a pretty clear exception.\n\nBut I think what you\'re saying is missing is the stack trace from the\nunderlying exception.\n\nAs I understood it, Python doesn\'t have a way of chaining exceptions\nlike this but e.g. Java does. A little bit more poking right now shows\nup this:\n\n  http://www.python.org/dev/peps/pep-3134/\n\ni.e. we can\'t do the right thing until Python 3, where we\'d do:\n\n def download_image(host, port, path):\n     try:\n         s = socket.create_connection((host, port))\n     except socket.error as e:\n         raise ImageDownloadFailure(host, port, path, e.strerror) from e\n\nI haven\'t read the PEP in detail yet, though.\n\nCheers,\nMark.\n\n\n\n','<51DDF303.8040007@inaugust.com>',NULL),('<1373534580.86817.YahooMailNeo@web193301.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 17:23:00',28800,'2013-07-11 09:23:00',NULL,'[openstack-dev] [Keystone] How to write unit tests for\n	db	methods?','\nThe methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used.\n\nI have implemented the things on the lines of trusts only.? Similar to trusts, I am also having RESTful APIs and unit tests for them are succesfully written. In test_backend_sql.py, it is seen that no unit tests are defined for trusts. So, it\'s confusing for me to implement the unit test for my backend sql code.\n\nI know I am confusing the things and I apologise for that, but I am asking because of that confusion only!\n\n\n\n________________________________\n From: Adam Young <ayoung at redhat.com>\nTo: openstack-dev at lists.openstack.org \nSent: Thursday, 11 July 2013 4:28 AM\nSubject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n \n\n\nOn 07/10/2013 06:56 AM, Akshat Kakkar wrote:\n\nI have added 2 tables to keystone.\nThis should be done in a migration, and should be tested using the\n    test_db_update.py file.\n\n\nI have methods which do the read/write/update/delete of records in these tables. \nPLease explain.? We are not doing direct sql, but rather using SQLalchemy.\n\n\n\nI want to write unit test for all this. These methods of mine inherit from keystone.common.sql and hence any call that these methods will make will go to the db returned by keystone.common.sql when creating a session. For writing a unit test this db should be a test db and not the production db. So, how can I have a session of test db? or is there altogether a different way of writing the unit test.\n>\nSee test_backend_sql.py\n\n\n>\n>\n>\n>\n>________________________________\n> From: Dolph Mathews <dolph.mathews at gmail.com>\n>To: Akshat Kakkar <the_akshat at yahoo.co.in>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \n>Sent: Tuesday, 9 July 2013 7:39 PM\n>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n> \n>\n>\n>I\'m assuming you\'re referring to testing backend drivers as opposed to database migrations (tests/test_sql_upgrade.py). \n>\n>\n>Backend agnostic tests land in tests/test_backend.py. Backend-specific tests, overrides, etc belong in tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.\n>\n>\n>Generally, you can\'t assume that keystone is backed by a database, however, as it\'s entirely possible to deploy without one.\n>\n>\n>\n>On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n>\n>How to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>\n>\n>\n>\n-- \n>\n>\n>\n-Dolph \n>\n>\n>\n>\n>_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130711/d61e5f92/attachment.html>\n\n','<51DE184C.5030401@redhat.com>',NULL),('<1373541132.2407.268.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 12:12:12',3600,'2013-07-11 11:12:12',NULL,'[openstack-dev] The danger of capping python-*clients in core\n projects, and forbidding it in the future','On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote:\n> On Wednesday, July 10, 2013, Sean Dague wrote:\n> \n> > Yesterday in the very exciting run around to figure out why the gate was\n> > broken, we realized something interesting. Because of the way the gate\n> > process pip requirements (one project at a time), on a current gate run we\n> > actually install and uninstall python-keystoneclient 4 times in a normal\n> > run, flipping back and forth from HEAD to 0.2.5.\n> >\n> > http://paste.openstack.org/**show/39880/<http://paste.openstack.org/show/39880/>- shows what\'s going on\n> >\n> > The net of this means that if any of the projects specify a capped client,\n> > it has the potential for preventing that client from being tested in the\n> > gate. This is very possibly part of the reason we ended up with a broken\n> > python-keystoneclient 0.3.0 released.\n> \n> \n> > I think we need to get strict on projects and prevent them from capping\n> > their client requirements. That will also put burden on clients that they\n> > don\'t break backwards compatibility (which I think was a goal regardless).\n> > However there is probably going to be a bit of pain getting from where we\n> > are today, to this world.\n> \n> \n> Thanks for investigating the underlying issue! I think the same\n> policy should apply a bit further to any code we develop and consume\n> ourselves as a community (oslo.config, etc). I have no doubt that\'s the\n> standard we strive for, but it\'s all too easy to throw a cap into a\n> requirements file and forget about it.\n\nI don\'t think we\'ve ever capped oslo.config anywhere. Got a pointer to\nwhat triggered that concern?\n\nWe should/could be capping oslo.config like this:\n\n  oslo.config>=1.1.0,<2.0\n\nbecause the API stability commitment is that we won\'t break the API\nwithout bumping the release number to 2.0. I don\'t anticipate doing 2.0\nsoon/ever, so I\'ve never pushed ahead with that capping.\n\nCheers,\nMark.\n\n\n\n','<CAC=h7gUz+7gwjJ=U9wRzB+Q_GN95d3OgPoBf+KoYAPqDECHAcA@mail.gmail.com>',NULL),('<1373548588.23490.52.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-11 09:16:28',-14400,'2013-07-11 13:16:28',NULL,'[Openstack-docs] Linking to external install guides','On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:\n> On 10/07/13 15:40, Andreas Jaeger wrote:\n> > On 07/10/2013 02:34 AM, Tom Fifield wrote:\n> >> I\'ll take a bullish line, which may not necessarily be achievable:\n> >>\n> >> \"\"\"\n> >> On the day that the press release for Havana is sent out, we need -by\n> >> hook or by crook!- to have installation instructions for RHEL and\n> >> Ubuntu, and ideally SUSE and Debian too.\n> >> \"\"\"\n> >\n> > What kind of instructions are you looking at? The \"Basic installation\"\n> > ones, the current \"installation guides\" - or both?\n> >\n> > Andreas\n> \n> Thanks for the reply!!\n> \n> I think the answer is: \"something\" ;)\n> \n> My personal impression is:\n> * the basic install guide is too basic right now\n> * the install guides are too heavy\n> \n> so ideally what I would be looking for as a deployer is something that \n> gives me a basic installation, with a bit of explanation on why the \n> steps are being taken.\n> \n> \n> However, I believe Shaun McCance is taking a very serious look at the \n> installation guides right now and should be able to provide an \n> authoritative answer.\n\nThat\'s more or less my impression. I don\'t like that there\'s two guides.\nIt\'s asking readers to make an upfront decision that they\'re probably\nnot in a position to make. My preference would be a single install guide\nthat\'s structured such that you get a basic, working install within the\nfirst few chapters, and can choose your own adventure after that.\n\nThe current full install guide feels random, like pieces were added to\nit over time without a lot of thought to the overall narrative. The\nbasic install guide is nice for what it is. I\'d just prefer it were\nincorporated into a larger work.\n\nAnd I believe very strongly that your docs should be ready on release\nday. They\'re part of your fanfare, and should be linked to from your\nmarketing materials.\n\n--\nShaun\n\n\n\n\n','<51DCF520.4040408@openstack.org>',NULL),('<1373550662.2407.277.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 14:51:02',3600,'2013-07-11 13:51:02',NULL,'[openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder,\n Glance)','On Thu, 2013-07-11 at 13:18 +0400, Boris Pavlovic wrote:\n> Mark, John, Nikola,\n> \n> \n> Current in oslo we would like to put only 2 functions:\n> \n> 1) generic method for creating shadow table\n> 2) generic method that the columns are same in shadow and main table\n> \n> \n> So migration that adds shadow table could be done after all other\n> works, when we finish improving of db-archiving utils (that moves\n> deleted rows to shadow tables), to avoid problems that noticed\n> Nikola. \n> \n> \n> These 2 functions won\'t be affected and will be used in future in\n> cinder, glance and they are already used in Nova. So I don\'t see any \n> problem to push it into oslo at this moment. \n\nIt\'s not clear to me that Cinder or Glance are planning to use these in\nthe Havana cycle.\n\n>From afar, they both sound like they are part of the current Nova DB\narchiving strategy that we\'re saying needs improvement before it is\nadopted by other projects.\n\nCheers,\nMark.\n\n\n\n\n','<CAD85om1Y1Dk0X06WNJ-QWdH0Bgxau8JKvosHC9-pNVpF1WDFrw@mail.gmail.com>',NULL),('<1373557565.2407.285.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 16:46:05',3600,'2013-07-11 15:46:05',NULL,'[openstack-dev] Current biggest OpenStack gate fail culprit -\n neutron bug #1194026','On Thu, 2013-07-11 at 09:28 -0600, John Griffith wrote:\n> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith <dms at danplanet.com> wrote:\n> \n> > > In the corner to my left, our current largest gate reset culprit\n> > > appears to be neutron bug #1194026 - weighing in with 62 rechecks\n> > > since June 24th (http://status.openstack.org/rechecks/)\n> >\n> > So, with some of the highest rates of patch traffic we\'ve seen over the\n> > last couple of weeks before the H2 deadline, I think this is really\n> > becoming a problem. I think merge times are through the roof as a\n> > result.\n> >\n> > Since the neutron gate is not a full tempest run, I think we should\n> > consider making a temporary change. I know that turning it into a\n> > non-voting job is not a popular solution, and I hate to even suggest\n> > it. However, it\'s just a subset of the tests anyway and I think the\n> >\n> \n> Well to be blunt, if there\'s not even anybody assigned to the defect and\n> it\'s significantly impacting\n> the progress of every other project.  I don\'t know that it\'s such a bad\n> idea.  The process worked, it\n> identified an issue, now it\'s known/understood however it\'s causing\n> significant turmoil everywhere else.\n> Are we gaining anything by having it continue to fail and do rechecks for\n> the next week?\n\nI feel a similar way to this as I do about regressions for which we\'ve\nidentified a root cause patch, even though it\'s a completely separate\nthing. In those cases, we should take decisive action to revert quickly.\n\nThis is holding people up, there\'s level of failure is unacceptable,\ncontinuing to frustrate people is not going to get it fixed faster. In\nthis case, we should take decisive action and make it non-voting\nquickly.\n\nCheers,\nMark.\n\n\n\n','<CA+qL3LXR4a+7mSWRpRYhdTTPL7F7CJMhoYOTGMfDbqbLU2jasQ@mail.gmail.com>',NULL),('<1373573734.2407.314.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-07-11 21:15:34',3600,'2013-07-11 20:15:34',NULL,'[openstack-tc] Spider \"What is Core\" Discussion Continued -\n Monday 7/15 1-3pm Central','On Thu, 2013-07-11 at 10:01 -0400, Russell Bryant wrote:\n> On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com wrote:\n> > Board & TC Members,\n> > \n> >  \n> > \n> > Alan and I have planned another 2 hour discussion session around the\n> > spider chart / what is core action plan.  The goal for this meeting is\n> > to refine the 6 positions that we?ve articulated and identify additional\n> > ones needed (my gut says, 4+ more).\n> > \n> >  \n> > \n> > If you have not been part of this meeting, we?ll explain what?s going on\n> > in the 1^st 15 minutes (and there?s information in the etherpad too). \n> > I?m working on a post about it too, but you?ll have to wait for that.\n> \n> > Background info: https://etherpad.openstack.org/Board-2013-SpiderDiscussion\n> \n> This is the first time I\'ve seen this.\n\nGiven that I\'m on the board, it\'s not the first time I\'ve seen it.\n\nWith my \"board hat\" on, I buy into the high level goal here - encourage\na marketplace of compatible OpenStack clouds by making the use of the\ntrademark in association with a public cloud contingent on it passing\nsome conformance tests.\n\nI\'ve never really evolved my thinking much beyond that, though. For\nexample, you could imagine taking this too far and eliminating any\nopportunity for OpenStack service providers to compete.\n\nI do think this is important to work through and am happy that someone\nis trying to make progress on it. Someone needs to.\n\n> I must admit that my initial\n> reaction is that I\'m not comfortable with the direction this seems to be\n> taking.\n> \n> I understand the need to have a solid definition of what \"core\" means.\n> I also assume that the goal here is to eventually arrive at some set of\n> definitions and policies.\n> \n> However, some of the specific items discussed on this etherpad are\n> things that are in my opinion, in TC (or even project specific\n> governance) territory, and should be considered out of scope for any\n> policy coming from the board.\n\nNow with my \"TC hat\" on ...\n\nYes, some of these positions do appear to be the kind of things that\ndon\'t make sense for the board to be trying to enforce without the TC\'s\nbuy-in. We could assume the request here is for the TC to consider\nwhether it could imagine adopting these positions itself.\n\nThere\'s a much deeper underlying assumption here that I\'m beginning to\nwonder whether we really should be taking it for granted.\n\nThe assumption is that the TC (and by extension, the project) actually\nwants to get involved with conformance testing as part of a trademark\nprogram at this point.\n\nMonty\'s proposal to make this conformance testing effort an official\nprogram is actually fairly enlightening - has a sufficiently large group\nof contributors formed around this effort such that we could say this is\nsomething the project clearly wants to take responsibility for at this\npoint?\n\nJust because the board has strayed into a technical area doesn\'t mean\nthe TC needs to automatically feel responsible for it. If the board\ndecided to bring OpenStack APIs to some body for formal standardization,\nthat too would be technical but I wouldn\'t be assuming the project would\ntake responsibility for it.\n\n...\n\nI think I\'d like to see the board (and whoever else is interested in\nhelping) make some progress on actually implementing a conformance\nprogram based on the status quo.\n\nIf the board wants to say that projects without a \"plug-in model\" can\'t\nbe core and won\'t be part of the conformance program, so be it. If the\ntempest project isn\'t interest in accepting the patches needed to make\nit suitable for conformance testing, so be it.\n\nPerhaps some of the policy decisions the board adopts results in\nprojects making some technical changes (like adopting a plug-in model so\nthey can be core) ... that smacks a little of extortion, but maybe we\'re\nok with it because the project is still free to make its own decision.\n\nIf the board goes too far by instituting a policy that is far away from\nthe technical policy, it will put the efficacy of the conformance\ntesting in jeopardy ... so there\'s a natural balance.\n\n...\n\nThe way we\'re approaching this now smacks of inevitable stalemate.\n\nI\'m thinking of an approach whereby the TC unblocks those interested in\nmaking progress on conformance testing for a foundation trademark\nprogram:\n\n  - the TC takes the stance that this is a board initiated effort and\n    its policy is not endorsed by the TC\n\n  - individual TC members may well contribute actively to the effort\n\n  - the TC will later consider an application to bring the already\n    well established conformance testing effort in as an official\n    program\n\n...\n\nSorry, too long\n\nCheers,\nMark.\n\n\n\n','<51DEBAC9.6030605@redhat.com>',NULL),('<1373577417.2407.337.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-07-11 22:16:57',3600,'2013-07-11 21:16:57',NULL,'[openstack-tc] Spider \"What is Core\" Discussion Continued -\n Monday 7/15 1-3pm Central','On Thu, 2013-07-11 at 16:13 -0500, Dolph Mathews wrote:\n> \n> On Thu, Jul 11, 2013 at 3:15 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>         On Thu, 2013-07-11 at 10:01 -0400, Russell Bryant wrote:\n>         > On 07/10/2013 02:53 PM, Rob_Hirschfeld at Dell.com wrote:\n>         > > Board & TC Members,\n>         > >\n>         > >\n>         > >\n>         > > Alan and I have planned another 2 hour discussion session around the\n>         > > spider chart / what is core action plan.  The goal for this meeting is\n>         > > to refine the 6 positions that we?ve articulated and identify additional\n>         > > ones needed (my gut says, 4+ more).\n>         > >\n>         > >\n>         > >\n>         > > If you have not been part of this meeting, we?ll explain what?s going on\n>         > > in the 1^st 15 minutes (and there?s information in the etherpad too).\n>         > > I?m working on a post about it too, but you?ll have to wait for that.\n>         >\n>         > > Background info: https://etherpad.openstack.org/Board-2013-SpiderDiscussion\n>         >\n>         > This is the first time I\'ve seen this.\n>         \n>         \n>         Given that I\'m on the board, it\'s not the first time I\'ve seen it.\n>         \n>         With my \"board hat\" on, I buy into the high level goal here - encourage\n>         a marketplace of compatible OpenStack clouds by making the use of the\n>         trademark in association with a public cloud contingent on it passing\n>         some conformance tests.\n>         \n>         I\'ve never really evolved my thinking much beyond that, though. For\n>         example, you could imagine taking this too far and eliminating any\n>         opportunity for OpenStack service providers to compete.\n> \n> \n> I don\'t perceive it as \"competition\" when it boils down to MyOpenStack\n> vs YourOpenStack because comparing API feature sets is like comparing\n> apples and oranges. End users don\'t win (see monty\'s example of not\n> being able to use CDN), and so OpenStack suffers. Service providers\n> can always compete on performance, reliability, cost, etc.\n\nYeah, I was a bit obtuse - I\'ve heard people talking about conformance\ntesting involving performance tests. Not sure if anyone still thinks\nthat\'s on the table, but that\'s the type of thing I mean.\n\nCheers,\nMark.\n\n\n\n\n','<CAC=h7gU1yDi9qJ8t-aiwNUPj8A=bhV5=3YU_vzu0dqt9j_qNRQ@mail.gmail.com>',NULL),('<1373649962-sup-335@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-12 10:28:45',-25200,'2013-07-12 17:28:45',NULL,'[openstack-dev] [TripleO] mid-cycle sprint?','Excerpts from Devananda van der Veen\'s message of 2013-07-12 09:02:49 -0700:\n> Neither week is possible for me. There\'s that thing in the desert... So\n> while I\'d like to attend, I don\'t think my absence will affect the rest of\n> you being productive :)\n> \n\nI see no reason to write off the Mojave desert in August as a potential\nsprint location. What could possibly go wrong?\n\nI am unavailable 8/26 - 9/5.. so the week before that would be better\nfor me.\n\n\n','<CAExZKEpv8oe8ct33e-=fMykYbhAhE7+QGpZycbG=nOjfTOOepA@mail.gmail.com>',NULL),('<1373898961.13951.YahooMailNeo@web193303.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-15 22:36:01',28800,'2013-07-15 14:36:01',NULL,'[openstack-dev] [Keystone] How to write unit tests for\n	db	methods?','As in my methods, I do not pass session object from outside so I am followin the unit test for catalog. But what I am unable to understand is that there are some test in test_backend.py and some in test_backend_sql.py. What is the difference in between the two?\n\n\n________________________________\n From: Adam Young <ayoung at redhat.com>\nTo: Akshat Kakkar <the_akshat at yahoo.co.in> \nCc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>; \"dolph.mathews at gmail.com\" <dolph.mathews at gmail.com> \nSent: Thursday, 11 July 2013 4:29 PM\nSubject: Re: [openstack-dev] [Keystone] How to write unit tests for db	methods?\n \n\n\nOn 07/11/2013 05:23 AM, Akshat Kakkar wrote:\n\n\n>The methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used.\n>\n>\n>I have implemented the things on the lines of trusts only.? Similar to trusts, I am also having RESTful APIs and unit tests for them are succesfully written. In test_backend_sql.py, it is seen that no unit tests are defined for trusts. So, it\'s confusing for me to implement the unit test for my backend sql code.\nYeah, trusts themselves are pretty simple as far as REST, and they\n    are exercised via the Token backend code as well as test_auth.py and\n    test_v3_auth.py.\n\nLook at the tests for identity and catalog, those should be a better\n    example to follow.\n\n\n\n\n>\n>I know I am confusing the things and I apologise for that, but I am asking because of that confusion only!\n>\n>\n>\n>\n>________________________________\n> From: Adam Young <ayoung at redhat.com>\n>To: openstack-dev at lists.openstack.org \n>Sent: Thursday, 11 July 2013 4:28 AM\n>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n> \n>\n>\n>On 07/10/2013 06:56 AM, Akshat Kakkar wrote:\n>\n>I have added 2 tables to keystone.\n>This should be done in a migration, and should be\n                  tested using the test_db_update.py file.\n>\n>\n>I have methods which do the read/write/update/delete of records in these tables. \nPLease explain.? We are not doing direct sql, but rather using SQLalchemy.\n>\n>\n>\n>I want to write unit test for all this. These methods of mine inherit from keystone.common.sql and hence any call that these methods will make will go to the db returned by keystone.common.sql when creating a session. For writing a unit test this db should be a test db and not the production db. So, how can I have a session of test db? or is there altogether a different way of writing the unit test.\n>>\nSee test_backend_sql.py\n>\n>\n>>\n>>\n>>\n>>\n>>________________________________\n>> From: Dolph Mathews <dolph.mathews at gmail.com>\n>>To: Akshat Kakkar <the_akshat at yahoo.co.in>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org>see  \n>>Sent: Tuesday, 9 July 2013 7:39 PM\n>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n>> \n>>\n>>\n>>I\'m assuming you\'re referring to testing backend drivers as opposed to database migrations (tests/test_sql_upgrade.py). \n>>\n>>\n>>Backend agnostic tests land in tests/test_backend.py. Backend-specific tests, overrides, etc belong in tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.\n>>\n>>\n>>Generally, you can\'t assume that keystone is backed by a database, however, as it\'s entirely possible to deploy without one.\n>>\n>>\n>>\n>>On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n>>\n>>How to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n>>>\n>>>_______________________________________________\n>>>OpenStack-dev mailing list\n>>>OpenStack-dev at lists.openstack.org\n>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>\n>>\n>>\n>>\n-- \n>>\n>>\n>>\n-Dolph \n>>\n>>\n>>\n>>\n>>_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130715/f7f75842/attachment.html>\n\n','<51DEC147.3010304@redhat.com>',NULL),('<1373899954-sup-5162@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-15 08:02:08',-25200,'2013-07-15 15:02:08',NULL,'[openstack-dev] Proposal for new Program: OpenStack Deployment','Excerpts from Anne Gentle\'s message of 2013-07-10 07:47:19 -0700:\n> Hi Robert,\n> \n> What\'s your plan for documenting the efforts so that others can do this in\n> their environments? Is there any documentation currently for which you can\n> send links?\n> \n\nWe\'ve been documenting the bootstrap procedure in this file:\n\nhttps://github.com/tripleo/incubator/blob/master/devtest.md\n\nThis is intended as much as a \"how to get started\" as it is \"how does\nthis actually work?\". We intend to have a much leaner set of instructions\nthat will have many of these steps scripted.\n\nAlso elements have their own README.md which is intended to inform deployers\nwhat to do with each piece:\n\nhttps://github.com/stackforge/tripleo-image-elements/tree/master/elements/neutron-openvswitch-agent\nhttps://github.com/stackforge/tripleo-image-elements/tree/master/elements/keystone\n\nLong term I see us assembling those into a holistic deployment guide, and\nmapping the configurations and relationships defined in the Heat templates\nand elements to the corresponding parts of each project\'s manual.\n\n\n','<CAD0KtVFrw-h=z20yvL2QJ2Z=aTkYnB_A14mfK6GELzGdiegksA@mail.gmail.com>',NULL),('<1373975916.624.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 12:58:36',3600,'2013-07-16 11:58:36',NULL,'[openstack-dev] olso-config dev requirement','On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote:\n> On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor <mordred at inaugust.com> wrote:\n> \n> > I was looking in to dependency processing as part of some pbr change,\n> > which got me to look at the way we\'re doing oslo-config dev requirements\n> > again. To start, this email is not about causing us to change what we\'re\n> > doing, only possibly the mechanics of what we put in the\n> > requirements.txt file- or to get a more specific example of what we\'re\n> > solving so that I can make a test case for it and ensure we\'re handling\n> > it properly.\n> >\n> > Currently, we have this:\n> >\n> > -f\n> >\n> > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3\n> > oslo.config>=1.2.0a3\n> >\n> > As the way to specify to install >- 1.2.0a3 of oslo.config. I believe\n> > this construct has grown in response to a sequence of issues, but it\'s\n> > complex and fragile, so I\'d like to explore what\'s going on.\n> >\n> > The simplest answer would be simply to replace it with:\n> >\n> > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz\n> >\n> > which will quite happily cause pip to install the contents of that\n> > tarball. It does not declare a version, but it\'s not necessary to,\n> > because the tarball has only one version that it is. Is there a problem\n> > we have identified where the wrong thing is happening?\n> >\n> \n> > I\'ve tested that I get the right thing in a virtualenv if I make that\n> > change from pip installing a tarball, pip installing the requirements\n> > directly and python setup.py install. Is there anything I\'m missing?\n> >\n> > Monty\n> >\n> \n> \n> Without the version specifier, we are relying on all projects to install\n> the right version from that tarball link when we run devstack, but we have\n> no guarantee that they are moving to new releases in lockstep.\n\nYep, that\'s it. The thing to test would be if some projects have the\n1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends\non an API that\'s new in 1.2.0a3.\n\nCheers,\nMark.\n\n\n\n','<CADb+p3QGKJ0RY2ExutFU8=NsJtN2cZdC3zjW=OhYBYYXAxf6OQ@mail.gmail.com>',NULL),('<1373981028.84600.YahooMailNeo@web193302.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 21:23:48',28800,'2013-07-16 13:23:48',NULL,'[openstack-dev] [Keystone] How to write unit tests for db\n	methods?','If I follow tests for \"Catalog\", I see that only one test is overwritten in test_backend_sql.py while the remaining 2 test are new (i.e. not declared in test_backend.py). I am only having SQL driver interface. So, should I write any test in test_backend.py or not?\nCan I write tests only in test_backend_sql.py and a blank class definition in test_backend.py and nothing anywhere else?\nWhat all care should I take in doing this?\n\n\n\n________________________________\n From: Dolph Mathews <dolph.mathews at gmail.com>\nTo: Akshat Kakkar <the_akshat at yahoo.co.in> \nCc: Adam Young <ayoung at redhat.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Monday, 15 July 2013 5:44 PM\nSubject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n \n\n\n\n\nOn Mon, Jul 15, 2013 at 9:36 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n\nAs in my methods, I do not pass session object from outside so I am followin the unit test for catalog. But what I am unable to understand is that there are some test in test_backend.py and some in test_backend_sql.py. What is the difference in between the two?\n\nTests in test_backend.py are run against all implementations of a driver\'s interface (KVS, SQL, LDAP, memcache, etc). Each driver type has a module (e.g. test_backend_sql.py) that?sets up & tears down a backend for the driver,?inherits tests from test_backend.py, overwrites/extends tests as necessary to document exceptions to the expected behavior (e.g. LDAP doesn\'t support multiple domains). Follow the inheritance hierarchy for any given class in test_backend_sql.py to illustrate.\n?\n\n>\n>\n>________________________________\n> From: Adam Young <ayoung at redhat.com>\n>To: Akshat Kakkar <the_akshat at yahoo.co.in> \n>Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>; \"dolph.mathews at gmail.com\" <dolph.mathews at gmail.com> \n>Sent: Thursday, 11 July 2013 4:29 PM\n>\n>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db	methods?\n> \n>\n>\n>On 07/11/2013 05:23 AM, Akshat Kakkar wrote:\n>\n>\n>>The methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used.\n>>\n>>\n>>I have implemented the things on the lines of trusts only.? Similar to trusts, I am also having RESTful APIs and unit tests for them are succesfully written. In test_backend_sql.py, it is seen that no unit tests are defined for trusts. So, it\'s confusing for me to implement the unit test for my backend sql code.\n>Yeah, trusts themselves are pretty simple as far as REST, and they\n    are exercised via the Token backend code as well as test_auth.py and\n    test_v3_auth.py.\n>\n>Look at the tests for identity and catalog, those should be a better\n    example to follow.\n>\n>\n>\n>\n>>\n>>I know I am confusing the things and I apologise for that, but I am asking because of that confusion only!\n>>\n>>\n>>\n>>\n>>________________________________\n>> From: Adam Young <ayoung at redhat.com>\n>>To: openstack-dev at lists.openstack.org \n>>Sent: Thursday, 11 July 2013 4:28 AM\n>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n>> \n>>\n>>\n>>On 07/10/2013 06:56 AM, Akshat Kakkar wrote:\n>>\n>>I have added 2 tables to keystone.\n>>This should be done in a migration, and should be\n                  tested using the test_db_update.py file.\n>>\n>>\n>>I have methods which do the read/write/update/delete of records in these tables. \nPLease explain.? We are not doing direct sql, but rather using SQLalchemy.\n>>\n>>\n>>\n>>I want to write unit test for all this. These methods of mine inherit from keystone.common.sql and hence any call that these methods will make will go to the db returned by keystone.common.sql when creating a session. For writing a unit test this db should be a test db and not the production db. So, how can I have a session of test db? or is there altogether a different way of writing the unit test.\n>>>\nSee test_backend_sql.py\n>>\n>>\n>>>\n>>>\n>>>\n>>>\n>>>________________________________\n>>> From: Dolph Mathews <dolph.mathews at gmail.com>\n>>>To: Akshat Kakkar <the_akshat at yahoo.co.in>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org>see  \n>>>Sent: Tuesday, 9 July 2013 7:39 PM\n>>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n>>> \n>>>\n>>>\n>>>I\'m assuming you\'re referring to testing backend drivers as opposed to database migrations (tests/test_sql_upgrade.py). \n>>>\n>>>\n>>>Backend agnostic tests land in tests/test_backend.py. Backend-specific tests, overrides, etc belong in tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.\n>>>\n>>>\n>>>Generally, you can\'t assume that keystone is backed by a database, however, as it\'s entirely possible to deploy without one.\n>>>\n>>>\n>>>\n>>>On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n>>>\n>>>How to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n>>>>\n>>>>_______________________________________________\n>>>>OpenStack-dev mailing list\n>>>>OpenStack-dev at lists.openstack.org\n>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>>\n-- \n>>>\n>>>\n>>>\n-Dolph \n>>>\n>>>\n>>>\n>>>\n>>>_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>\n>\n>\n\n\n-- \n\n-Dolph \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130716/66988e26/attachment.html>\n\n','<CAC=h7gWoR2ek6=M+WTBXDG91YHQhk4NcQkpgBYC3+2WcyZgppg@mail.gmail.com>',NULL),('<1373982134.10134.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 14:42:14',3600,'2013-07-16 13:42:14',NULL,'[openstack-dev] Program Proposal: DevStack','On Mon, 2013-07-15 at 14:14 -0400, Russell Bryant wrote:\n> On 07/15/2013 11:39 AM, Dean Troyer wrote:\n> > DevStack plays multiple roles in the development process for OpenStack.\n> \n> Does it really make sense to be its own program?  There was mention of\n> just making it a part of infra or QA.  QA actually makes the most sense\n> to me, since devstack\'s primary use case is to make it easy to test\n> OpenStack.\n\nHow about if the title of the program was \'Developer Tools\'?\n\nIs devstack the only project which would fall into that bucket?\n\nCheers,\nMark.\n\n\n\n','<51E43C12.1040806@redhat.com>',NULL),('<1373986186.10134.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 15:49:46',3600,'2013-07-16 14:49:46',NULL,'[openstack-dev] Program Proposal: DevStack','On Tue, 2013-07-16 at 16:07 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > On Mon, 2013-07-15 at 14:14 -0400, Russell Bryant wrote:\n> >> On 07/15/2013 11:39 AM, Dean Troyer wrote:\n> >>> DevStack plays multiple roles in the development process for OpenStack.\n> >>\n> >> Does it really make sense to be its own program?  There was mention of\n> >> just making it a part of infra or QA.  QA actually makes the most sense\n> >> to me, since devstack\'s primary use case is to make it easy to test\n> >> OpenStack.\n> > \n> > How about if the title of the program was \'Developer Tools\'?\n> > \n> > Is devstack the only project which would fall into that bucket?\n> \n> The trick with programs is that it\'s not just about finding themes and\n> aggregate existing projects around them. At the heart of a program is an\n> existing team of people that works (well) together towards that common goal.\n> \n> Putting devstack in a \"Developer tools\" bucket only makes sense if the\n> team that cares about devstack also cares about those other \"developer\n> tools\". You don\'t really want to create an ugly stepchild effect by\n> adding random projects onto unwanting people\'s plates.\n\nYep, agree.\n\nCheers,\nMark.\n\n\n\n','<51E553BD.4070107@openstack.org>',NULL),('<1373989609.89164.YahooMailNeo@web193305.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 23:46:49',28800,'2013-07-16 15:46:49',NULL,'[openstack-dev] [Keystone] How to write unit tests for db\n	methods?','So that means all tests in test_backend.py and a blank class definition in test_backend_sql.py.\n\nCertain test require some pre-existing db records. Normally we should do it in setUp method, but I think in keystone we have do it some other way. Should it be in a non-test method within the class and that method can be called everytime there is such requirement of pre-existing db records. Is this correct or am I missing anything?\nWhat about deleting those records? Should I do it explicitly or it will be automatically taken care in tearDown?\n\n\n\n\n________________________________\n From: Dolph Mathews <dolph.mathews at gmail.com>\nTo: Akshat Kakkar <the_akshat at yahoo.co.in> \nCc: Adam Young <ayoung at redhat.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Tuesday, 16 July 2013 5:30 PM\nSubject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n \n\n\n\n\nOn Tue, Jul 16, 2013 at 8:23 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n\nIf I follow tests for \"Catalog\", I see that only one test is overwritten in test_backend_sql.py while the remaining 2 test are new (i.e. not declared in test_backend.py). I am only having SQL driver interface. So, should I write any test in test_backend.py or not?\n>\n\nYes.\n?\nCan I write tests only in test_backend_sql.py and a blank class definition in test_backend.py and nothing anywhere else?\n>\n\nNo; do it the other way around, even if you only have one driver implementation.\n?\nWhat all care should I take in doing this?\n>\n\nFeel free to put what you have up for review (consider maintaining it as WIP) and we can give you some more specific direction from there.\n?\n\n>\n>\n>________________________________\n> From: Dolph Mathews <dolph.mathews at gmail.com>\n>To: Akshat Kakkar <the_akshat at yahoo.co.in> \n>Cc: Adam Young <ayoung at redhat.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \n>Sent: Monday, 15 July 2013 5:44 PM\n>\n>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n> \n>\n>\n>\n>\n>On Mon, Jul 15, 2013 at 9:36 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n>\n>As in my methods, I do not pass session object from outside so I am followin the unit test for catalog. But what I am unable to understand is that there are some test in test_backend.py and some in test_backend_sql.py. What is the difference in between the two?\n>\n>\n>Tests in test_backend.py are run against all implementations of a driver\'s interface (KVS, SQL, LDAP, memcache, etc). Each driver type has a module (e.g. test_backend_sql.py) that?sets up & tears down a backend for the driver,?inherits tests from test_backend.py, overwrites/extends tests as necessary to document exceptions to the expected behavior (e.g. LDAP doesn\'t support multiple domains). Follow the inheritance hierarchy for any given class in test_backend_sql.py to illustrate.\n>?\n>\n>>\n>>\n>>________________________________\n>> From: Adam Young <ayoung at redhat.com>\n>>To: Akshat Kakkar <the_akshat at yahoo.co.in> \n>>Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>; \"dolph.mathews at gmail.com\" <dolph.mathews at gmail.com> \n>>Sent: Thursday, 11 July 2013 4:29 PM\n>>\n>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db	methods?\n>> \n>>\n>>\n>>On 07/11/2013 05:23 AM, Akshat Kakkar wrote:\n>>\n>>\n>>>The methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used.\n>>>\n>>>\n>>>I have implemented the things on the lines of trusts only.? Similar to trusts, I am also having RESTful APIs and unit tests for them are succesfully written. In test_backend_sql.py, it is seen that no unit tests are defined for trusts. So, it\'s confusing for me to implement the unit test for my backend sql code.\n>>Yeah, trusts themselves are pretty simple as far as REST, and they\n    are exercised via the Token backend code as well as test_auth.py and\n    test_v3_auth.py.\n>>\n>>Look at the tests for identity and catalog, those should be a better\n    example to follow.\n>>\n>>\n>>\n>>\n>>>\n>>>I know I am confusing the things and I apologise for that, but I am asking because of that confusion only!\n>>>\n>>>\n>>>\n>>>\n>>>________________________________\n>>> From: Adam Young <ayoung at redhat.com>\n>>>To: openstack-dev at lists.openstack.org \n>>>Sent: Thursday, 11 July 2013 4:28 AM\n>>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n>>> \n>>>\n>>>\n>>>On 07/10/2013 06:56 AM, Akshat Kakkar wrote:\n>>>\n>>>I have added 2 tables to keystone.\n>>>This should be done in a migration, and should be\n                  tested using the test_db_update.py file.\n>>>\n>>>\n>>>I have methods which do the read/write/update/delete of records in these tables. \nPLease explain.? We are not doing direct sql, but rather using SQLalchemy.\n>>>\n>>>\n>>>\n>>>I want to write unit test for all this. These methods of mine inherit from keystone.common.sql and hence any call that these methods will make will go to the db returned by keystone.common.sql when creating a session. For writing a unit test this db should be a test db and not the production db. So, how can I have a session of test db? or is there altogether a different way of writing the unit test.\n>>>>\nSee test_backend_sql.py\n>>>\n>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>________________________________\n>>>> From: Dolph Mathews <dolph.mathews at gmail.com>\n>>>>To: Akshat Kakkar <the_akshat at yahoo.co.in>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org>see  \n>>>>Sent: Tuesday, 9 July 2013 7:39 PM\n>>>>Subject: Re: [openstack-dev] [Keystone] How to write unit tests for db methods?\n>>>> \n>>>>\n>>>>\n>>>>I\'m assuming you\'re referring to testing backend drivers as opposed to database migrations (tests/test_sql_upgrade.py). \n>>>>\n>>>>\n>>>>Backend agnostic tests land in tests/test_backend.py. Backend-specific tests, overrides, etc belong in tests/test_backend_sql.py, tests/test_backend_kvs.py, etc.\n>>>>\n>>>>\n>>>>Generally, you can\'t assume that keystone is backed by a database, however, as it\'s entirely possible to deploy without one.\n>>>>\n>>>>\n>>>>\n>>>>On Tue, Jul 9, 2013 at 10:55 AM, Akshat Kakkar <the_akshat at yahoo.co.in> wrote:\n>>>>\n>>>>How to write unit tests in keystone for the methods which are directly calling the backend db? I understand that for testing purpose it should be a *fake db*, but how to do that in keystone?\n>>>>>\n>>>>>_______________________________________________\n>>>>>OpenStack-dev mailing list\n>>>>>OpenStack-dev at lists.openstack.org\n>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n-- \n>>>>\n>>>>\n>>>>\n-Dolph \n>>>>\n>>>>\n>>>>\n>>>>\n>>>>_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n>>>\n>>>_______________________________________________\n>>>OpenStack-dev mailing list\n>>>OpenStack-dev at lists.openstack.org\n>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n>\n>-- \n>\n>\n>-Dolph \n>\n>\n\n\n-- \n\n-Dolph \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130716/ce531e6a/attachment.html>\n\n','<CAC=h7gVPbdXUjv841CKepJFALD0m+WWS91x9rHGr=t197suNpQ@mail.gmail.com>',NULL),('<1374000609.10134.30.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 19:50:09',3600,'2013-07-16 18:50:09',NULL,'[openstack-dev] olso-config dev requirement','On Tue, 2013-07-16 at 13:37 -0400, Monty Taylor wrote:\n> \n> On 07/16/2013 11:42 AM, Doug Hellmann wrote:\n> > \n> > \n> > \n> > On Tue, Jul 16, 2013 at 7:58 AM, Mark McLoughlin <markmc at redhat.com\n> > <mailto:markmc at redhat.com>> wrote:\n> > \n> >     On Mon, 2013-07-15 at 14:28 -0400, Doug Hellmann wrote:\n> >     > On Mon, Jul 15, 2013 at 11:03 AM, Monty Taylor\n> >     <mordred at inaugust.com <mailto:mordred at inaugust.com>> wrote:\n> >     >\n> >     > > I was looking in to dependency processing as part of some pbr\n> >     change,\n> >     > > which got me to look at the way we\'re doing oslo-config dev\n> >     requirements\n> >     > > again. To start, this email is not about causing us to change\n> >     what we\'re\n> >     > > doing, only possibly the mechanics of what we put in the\n> >     > > requirements.txt file- or to get a more specific example of what\n> >     we\'re\n> >     > > solving so that I can make a test case for it and ensure we\'re\n> >     handling\n> >     > > it properly.\n> >     > >\n> >     > > Currently, we have this:\n> >     > >\n> >     > > -f\n> >     > >\n> >     > >\n> >     http://tarballs..openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2..0a3\n> >     <http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3>\n> >     > > oslo.config>=1.2.0a3\n> >     > >\n> >     > > As the way to specify to install >- 1.2.0a3 of oslo.config. I\n> >     believe\n> >     > > this construct has grown in response to a sequence of issues,\n> >     but it\'s\n> >     > > complex and fragile, so I\'d like to explore what\'s going on.\n> >     > >\n> >     > > The simplest answer would be simply to replace it with:\n> >     > >\n> >     > > http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a3.tar.gz\n> >     > >\n> >     > > which will quite happily cause pip to install the contents of that\n> >     > > tarball. It does not declare a version, but it\'s not necessary to,\n> >     > > because the tarball has only one version that it is. Is there a\n> >     problem\n> >     > > we have identified where the wrong thing is happening?\n> >     > >\n> >     >\n> >     > > I\'ve tested that I get the right thing in a virtualenv if I make\n> >     that\n> >     > > change from pip installing a tarball, pip installing the\n> >     requirements\n> >     > > directly and python setup.py install. Is there anything I\'m missing?\n> >     > >\n> >     > > Monty\n> >     > >\n> >     >\n> >     >\n> >     > Without the version specifier, we are relying on all projects to\n> >     install\n> >     > the right version from that tarball link when we run devstack, but\n> >     we have\n> >     > no guarantee that they are moving to new releases in lockstep.\n> > \n> >     Yep, that\'s it. The thing to test would be if some projects have the\n> >     1.2.0a2 tarball link and an one has the 1.2.0a3 link because it depends\n> >     on an API that\'s new in 1.2.0a3.\n> > \n> > \n> > It\'s worse than that. What gets installed will depend on the order\n> > devstack installs the projects and what their respective requirements\n> > lists say. It is possible to end up with compatible source code\n> > installed, but with a version number that setuptools thinks is not\n> > compatible based on projects\' requirements. In that case, setuptools may\n> > not let us load plugins, so services will start but not actually work.\n> \n> Thank you. This is what I needed here.\n> \n> BTW - I put this up:\n> \n> https://review.openstack.org/#/c/35705/\n> \n> To take a stab at installing our global requirements list first, and\n> then installing our projects in that environment. I also just made:\n> \n> https://review.openstack.org/#/c/37295/\n> \n> Which would add oslo.config and oslo.messaging as git repos to the\n> devstack system, so that we can track trunk like we do with the other\n> projects.\n\nAwesome, thanks - I\'ve had that on my TODO list for weeks.\n\nIt\'s probably a bit early about oslo.messaging, since nothing\'s using it\nyet ... but no harm in having it in there.\n\nThanks again,\nMark.\n\n\n\n','<51E584D1.3050006@inaugust.com>',NULL),('<1374003989.10134.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 20:46:29',3600,'2013-07-16 19:46:29',NULL,'[openstack-dev] [OSLO] Comments/Questions on Messaging Wiki','Hi William,\n\nI think Doug has done a good job of answering all these, but here\'s\nanother set of answers to make sure there\'s no confusion :)\n\nOn Fri, 2013-07-12 at 17:40 -0400, William Henry wrote:\n> Hi all, \n> \n> I\'ve been reading through the Messaging Wiki and have some comments.\n\nThe docs generated from the code are now up on:\n\n  http://docs.openstack.org/developer/oslo.messaging/\n\nThere should be some useful clarifying stuff in there too. Indeed some\nof thinking has moved on a bit since the wiki page was written.\n\n>  Not criticisms, just comments and questions. \n> I have found this to be a very useful document. Thanks. \n> \n> 1. \"There are multiple backend transport drivers which implement the\n> API semantics using different messaging systems - e.g. RabbitMQ, Qpid,\n> ZeroMQ. While both sides of a connection must use the same transport\n> driver configured in the same way, the API avoids exposing details of\n> transports so that code written using one transport should work with\n> any other transport.\" \n> \n> The good news for AMQP 1.0 users is that technically \"boths sides of\n> the connection\" do not have to use same transport driver. In pre-AMQP\n> 1.0 days this was the case. But today interoperability between AMQP\n> 1.0 implementations has been demonstrated. \n\nYeah, the point was more that like you need to use the zmq driver on\nboth sides.\n\nI could imagine us having multiple \"amqp 1.0\" interoperable drivers. I\ndon\'t know what the use case would be for using one of those drivers on\none side and another on the other side, but there\'s no reason why it\nshould be impossible.\n\n> 2. I notice under the RPC concepts section that you mention Exchanges\n> as a container in which topics are scoped. Is this exchange a pre AMQP\n> 1.0 artifact or just a general term for oslo.messaging that is loosely\n> based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you\n> assuming that messaging implementations have something called an\n> exchange? Or do you mean that messaging implementations can scope a\n> topic and in oslo we call that scoping an exchange? \n\nYeah, it really is only loosely related to the AMQP concept.\n\nIt\'s purely a namespace thing. You could e.g. have two Nova deployments\nwith exactly the same messaging transport (and e.g. sending messages\nover the same broker, using the same topic names, etc.) and you could\nkeep them separated from one another by using a different exchange name\nfor each.\n\nThe reason we\'ve stuck with the name \"exchange\" is that we have a\n\"control_exchange\" configuration variable (defaulting to e.g. \'nova\')\nthat servers roughly this purpose now and we want to continue using it\nrather than renaming it to something else.\n\nWhich raises a point about all of this - we need to be able to\ninteroperate with existing OpenStack deployments using the current RPC\ncode. So, we really don\'t have the luxury of changing on-the-wire\nformats, basic messaging semantics, configuration settings, etc.\n\noslo.messaging is mostly about cleaning up the python API which services\nuse to issue/receive RPCs and send notifications.\n\n> 3. Some messaging nomenclature: The way the wiki describes RPC \"\n> Invoke Method on One of Multiple Servers \" is more like a queue than a\n> topic. In messaging a queue is something that multiple consumers can\n> attach to and one of them gets and services a message/request. A topic\n> is where 1+ consumers are \"connected\" and each receives a the message\n> and each can service it as it sees fit. In pre-AMQP 1.0 terms what\n> this seems to describe is a direct exchange. And a direct excahnge can\n> have multiple consumers listening to a queue on that exchange.\n> (Remember that fanout is just a generalization of topic in that all\n> consumers get all fanout messages - there are no sub-topics etc.) \n> \n> In AMQP 1.0 the addressing doesn\'t care or know about exchanges but it\n> can support this queue type behavior on an address or topic type\n> behavior on an address. \n> \n> I know this isn\'t about AMQP specifically but therefore this is even\n> more important. Topics are pub/sub with multiple consumer/services\n> responding to a single message. Queues are next consumer up gets the\n> next message. \n> \n> (BTW I\'ve seen this kind of confusion also in early versions of\n> MCollective in Puppet.) \n> \n> It might be better to change some of the references to \"topic\" to\n> \"address\". This would solve the problem. i.e. a use case where one of\n> many servers listening on an address services a message/request. And\n> later all of servers listening on an address service a\n> message/request. Addressing also solves the one-to-one as the address\n> is specific to the server (and the others don\'t have to receive and\n> reject the message).\n\nIt sounds to me like the qpid-proton based transport driver could easily\nmap the semantics we expect from topic/fanout to amqp 1.0 addresses.\n\nThe \'topic\' nomenclature is pretty baked in the various services doing\nRPC and notifications, especially in the naming of configuration\noptions.\n\nThe basic semantics is a nova compute service listens on the \'compute\'\ntopic on the \'nova\' exchange and a client can cause a method to be\ninvoked on the service with either of the following targets:\n\n  Target(exchange=\'nova\', topic=\'compute\')\n  Target(exchange=\'nova\', topic=\'compute\', server=\'compute1\')\n  Target(exchange=\'nova\', topic=\'compute\', fanout=True)\n\nIn the first case, any compute service will do. In the second, you want\nto invoke the method on a particular compute service. The the latter\ncase, you want to invoke it on all compute services.\n\nCheers,\nMark.\n\n\n\n','<422668456.3678926.1373665207391.JavaMail.root@redhat.com>',NULL),('<1374004195.10134.50.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 20:49:55',3600,'2013-07-16 19:49:55',NULL,'[openstack-dev] Program Proposal: Trove','Hey,\n\nOn Tue, 2013-07-16 at 10:37 -0700, Michael Basnight wrote:\n> Official Title: OpenStack Database as a Service\n> Initial PTL: Michael Basnight <mbasnight at gmail.com>\n> \n> Mission Statement: To provide scalable and reliable Cloud Database as\n> a Service functionality for both relational and non-relational\n> database engines, and to continue to improve its fully-featured and\n> extensible open source framework.\n\nSeems fine to me, but I\'d see adding non-relational support as an\nexpansion of Trove\'s scope as approved by the TC.\n\nI know we discussed whether it should be in scope from the beginning,\nbut I thought we didn\'t want rule out the possibility of an entirely new\nteam of folks coming up with a NoSQL as a Service project.\n\nCheers,\nMark.\n\n\n\n','<9B08A7F0-3227-4724-907C-B1CF3F88EC27@gmail.com>',NULL),('<1374008234.10134.54.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 21:57:14',3600,'2013-07-16 20:57:14',NULL,'[openstack-dev] [OSLO] Comments/Questions on Messaging Wiki','On Tue, 2013-07-16 at 16:34 -0400, William Henry wrote:\n> \n> ----- Original Message -----\n> > \n> > \n> > ----- Original Message -----\n> > > Hi William,\n> > > \n> > > I think Doug has done a good job of answering all these, but here\'s\n> > > another set of answers to make sure there\'s no confusion :)\n> > > \n> > > On Fri, 2013-07-12 at 17:40 -0400, William Henry wrote:\n> > > > Hi all,\n> > > > \n> > > > I\'ve been reading through the Messaging Wiki and have some comments.\n> > > \n> > > The docs generated from the code are now up on:\n> > > \n> > >   http://docs.openstack.org/developer/oslo.messaging/\n> > > \n> > > There should be some useful clarifying stuff in there too. Indeed some\n> > > of thinking has moved on a bit since the wiki page was written.\n> > > \n> > > >  Not criticisms, just comments and questions.\n> > > > I have found this to be a very useful document. Thanks.\n> > > > \n> > > > 1. \"There are multiple backend transport drivers which implement the\n> > > > API semantics using different messaging systems - e.g. RabbitMQ, Qpid,\n> > > > ZeroMQ. While both sides of a connection must use the same transport\n> > > > driver configured in the same way, the API avoids exposing details of\n> > > > transports so that code written using one transport should work with\n> > > > any other transport.\"\n> > > > \n> > > > The good news for AMQP 1.0 users is that technically \"boths sides of\n> > > > the connection\" do not have to use same transport driver. In pre-AMQP\n> > > > 1.0 days this was the case. But today interoperability between AMQP\n> > > > 1.0 implementations has been demonstrated.\n> > > \n> > > Yeah, the point was more that like you need to use the zmq driver on\n> > > both sides.\n> > > \n> > > I could imagine us having multiple \"amqp 1.0\" interoperable drivers. I\n> > > don\'t know what the use case would be for using one of those drivers on\n> > > one side and another on the other side, but there\'s no reason why it\n> > > should be impossible.\n> > > \n> > > > 2. I notice under the RPC concepts section that you mention Exchanges\n> > > > as a container in which topics are scoped. Is this exchange a pre AMQP\n> > > > 1.0 artifact or just a general term for oslo.messaging that is loosely\n> > > > based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you\n> > > > assuming that messaging implementations have something called an\n> > > > exchange? Or do you mean that messaging implementations can scope a\n> > > > topic and in oslo we call that scoping an exchange?\n> > > \n> > > Yeah, it really is only loosely related to the AMQP concept.\n> > > \n> > > It\'s purely a namespace thing. You could e.g. have two Nova deployments\n> > > with exactly the same messaging transport (and e.g. sending messages\n> > > over the same broker, using the same topic names, etc.) and you could\n> > > keep them separated from one another by using a different exchange name\n> > > for each.\n> > > \n> > > The reason we\'ve stuck with the name \"exchange\" is that we have a\n> > > \"control_exchange\" configuration variable (defaulting to e.g. \'nova\')\n> > > that servers roughly this purpose now and we want to continue using it\n> > > rather than renaming it to something else.\n> > > \n> > > Which raises a point about all of this - we need to be able to\n> > > interoperate with existing OpenStack deployments using the current RPC\n> > > code. So, we really don\'t have the luxury of changing on-the-wire\n> > > formats, basic messaging semantics, configuration settings, etc.\n> > > \n> > > oslo.messaging is mostly about cleaning up the python API which services\n> > > use to issue/receive RPCs and send notifications.\n> > > \n> > > > 3. Some messaging nomenclature: The way the wiki describes RPC \"\n> > > > Invoke Method on One of Multiple Servers \" is more like a queue than a\n> > > > topic. In messaging a queue is something that multiple consumers can\n> > > > attach to and one of them gets and services a message/request. A topic\n> > > > is where 1+ consumers are \"connected\" and each receives a the message\n> > > > and each can service it as it sees fit. In pre-AMQP 1.0 terms what\n> > > > this seems to describe is a direct exchange. And a direct excahnge can\n> > > > have multiple consumers listening to a queue on that exchange.\n> > > > (Remember that fanout is just a generalization of topic in that all\n> > > > consumers get all fanout messages - there are no sub-topics etc.)\n> > > > \n> > > > In AMQP 1.0 the addressing doesn\'t care or know about exchanges but it\n> > > > can support this queue type behavior on an address or topic type\n> > > > behavior on an address.\n> > > > \n> > > > I know this isn\'t about AMQP specifically but therefore this is even\n> > > > more important. Topics are pub/sub with multiple consumer/services\n> > > > responding to a single message. Queues are next consumer up gets the\n> > > > next message.\n> > > > \n> > > > (BTW I\'ve seen this kind of confusion also in early versions of\n> > > > MCollective in Puppet.)\n> > > > \n> > > > It might be better to change some of the references to \"topic\" to\n> > > > \"address\". This would solve the problem. i.e. a use case where one of\n> > > > many servers listening on an address services a message/request. And\n> > > > later all of servers listening on an address service a\n> > > > message/request. Addressing also solves the one-to-one as the address\n> > > > is specific to the server (and the others don\'t have to receive and\n> > > > reject the message).\n> > > \n> > > It sounds to me like the qpid-proton based transport driver could easily\n> > > map the semantics we expect from topic/fanout to amqp 1.0 addresses.\n> > > \n> > > The \'topic\' nomenclature is pretty baked in the various services doing\n> > > RPC and notifications, especially in the naming of configuration\n> > > options.\n> > > \n> > > The basic semantics is a nova compute service listens on the \'compute\'\n> > > topic on the \'nova\' exchange and a client can cause a method to be\n> > > invoked on the service with either of the following targets:\n> > > \n> > >   Target(exchange=\'nova\', topic=\'compute\')\n> > >   Target(exchange=\'nova\', topic=\'compute\', server=\'compute1\')\n> > >   Target(exchange=\'nova\', topic=\'compute\', fanout=True)\n> > > \n> > > In the first case, any compute service will do. In the second, you want\n> > > to invoke the method on a particular compute service. The the latter\n> > > case, you want to invoke it on all compute services.\n> > \n> > This really helps understand some of what I\'ve read. Thanks.\n> > \n> > It seems that exchange is really just a high level qualifier of a namespace\n> > for the most part.\n\nYep.\n\n> > Q: if in the above last Target, fanout was false (fanout=False) would that\n> > mean that you are expecting queue type behavior in that instance? i.e. I\n> > want only one consumer, I don\'t care which one, but only one consumer to\n> > service this request? So that syntax would change the semantics from pub/sub\n> > topic (i.e. all subscribers to the topic get it) to a queue semantic (first\n> > consumer to acquire the message causes it to dequeue and be not available t\n> > others?\n> \n> Actually rereading this I think it does. i.e. the first example is essentially fanout=false.\n\nRight, exactly.\n\nAnd this doesn\'t make sense:\n\n  Target(exchange=\'nova\', topic=\'compute\', server=\'compute1\', fanout=True)\n\nCheers,\nMark.\n\n\n\n','<1550760654.1489200.1374006896607.JavaMail.root@redhat.com>',NULL),('<1374009107.10134.55.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 22:11:47',3600,'2013-07-16 21:11:47',NULL,'[openstack-dev] Reminder: Oslo project meeting','Hi\n\nWe\'re having an IRC meeting on Friday to sync up again on the messaging\nwork going on:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n  https://etherpad.openstack.org/HavanaOsloMessaging\n\nFeel free to add other topics to the wiki\n\nSee you on #openstack-meeting at 1400 UTC\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1374085787.26919.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-17 19:29:47',3600,'2013-07-17 18:29:47',NULL,'[openstack-dev] [cinder] Proposal for Ollie Leahy to\n	join	cinder-core','On Wed, 2013-07-17 at 21:19 +0300, Avishay Traeger wrote:\n> -1\n> \n> I\'m sorry to do that, and it really has nothing to do with Ollie or his\n> work (which I appreciate very much).  The main reason is that right now\n> Cinder core has 8 members:\n> 1. Avishay Traeger (IBM)\n> 2. Duncan Thomas (HP)\n> 3. Eric Harney (RedHat)\n> 4. Huang Zhiteng (Intel)\n> 5. John Griffith (SolidFire)\n> 6. Josh Durgin (Inktank)\n> 7. Mike Perez (DreamHost)\n> 8. Walt Boring (HP)\n> \n> Adding another core team member from HP means that 1/3 of the core team is\n> from HP.  I believe that we should strive to have the core team be as\n> diverse as possible, with as many companies as possible represented (big\n> and small alike).  I think that\'s one of the keys to keeping a project\n> healthy and on the right track (nothing against HP - I would say the same\n> for IBM or any other company).\n\nThe affiliation of core team members should not come into a decision\nlike this.\n\nIt is assumed that all core team members are wearing their \"upstream\nhat\" and aren\'t there merely to represent their employers interests.\n\nCheers,\nMark.\n\n\n\n','<OF8D26073C.5181C8DF-ONC2257BAB.0063B10F-C2257BAB.0064B215@il.ibm.com>',NULL),('<1374118128284.917d8bbb@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-17 20:28:49',-25200,'2013-07-18 03:28:49',NULL,'[openstack-dev] [Nova] New DB column or new DB table?','How is this different than extra_specs used by the filter scheduler?\nhttp://docs.openstack.org/developer/nova/devref/filter_scheduler.html\n\nI did some very old blueprints related to heterogeneous architectures that had similar goals. ?\nhttps://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types\n\n\nFully support the idea, but probably can adapt the existing functionality to also target metric data.\n?\nSent from Mailbox for iPad\n\nOn Wed, Jul 17, 2013 at 10:56 PM, Lu, Lianhao <lianhao.lu at intel.com>\nwrote:\n\n> Hi fellows,\n> Currently we\'re implementing the BP https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. The main idea is to have an extensible plugin framework on nova-compute where every plugin can get different metrics(e.g. CPU utilization, memory cache utilization, network bandwidth, etc.) to store into the DB, and the nova-scheduler will use that data from DB for scheduling decision.\n> Currently we adds a new table to store all the metric data and have nova-scheduler join loads the new table with the compute_nodes table to get all the data(https://review.openstack.org/35759). Someone is concerning about the performance penalty of the join load operation when there are many metrics data stored in the DB for every single compute node. Don suggested adding a new column in the current compute_nodes table in DB, and put all metric data into a dictionary key/value format and store the json encoded string of the dictionary into that new column in DB. \n> I\'m just wondering which way has less performance impact, join load with a new table with quite a lot of rows, or json encode/decode a dictionary with a lot of key/value pairs?\n> Thanks,\n> -Lianhao\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130717/ee57979c/attachment.html>\n\n','<857BE142E5399E46B20FD45B9DB8A7BC10F3130C@SHSMSX102.ccr.corp.intel.com>',NULL),('<1374161195.3569.1.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 10:26:35',-18000,'2013-07-18 15:26:35',NULL,'[openstack-dev] Opinions needed: Changing method signature in\n RPC callback ...','On Thu, 2013-07-18 at 11:09 -0300, Sandy Walsh wrote:\n> 3. some other ugly python hack that I haven\'t thought of yet.\n\nI have two possibilities, though neither is really ideal.  One is to\nprovide a duplicate call for registering the callback, but where the\ncallback has the extra arguments.  The other is to use the functions in\nthe \"inspect\" module to determine what convention the callback is\nexpecting.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<51E7F721.5070004@rackspace.com>',NULL),('<1374162019.23490.94.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-18 11:40:19',-14400,'2013-07-18 15:40:19',NULL,'[Openstack-docs] Intro and example installations','Hi all,\n\nI want to ask the list for input on example installations of OpenStack.\nBut since I\'ve failed to introduce myself to the list, let me do that.\n\nI\'ve been doing open source documentation for GNOME for a long time.\nIn fact, this September I will have been the GNOME docs team lead for\nten years. I also run the Open Help Conference each year, which is how\nI met Anne. I do freelance documentation work as a day job. Currently,\nI\'m doing upstream OpenStack documentation work under contract with\nCisco, working on the installation guides.\n\nWhat I\'d like to do is compile a list of example deployments that we\ncan use to guide and evaluate the installation docs. Obviously, it\ncan\'t be comprehensive, given how flexible OpenStack is. Thinks of\npersonas, except configurations instead of people.\n\nDoes anybody have any real-world cases they can distill into examples?\nIdeally we\'d have half a dozen example setups: how many nodes, what\'s\nrunning on what, etc. More importantly, why was OpenStack set up this\nway, what advantages does it have, and what are the drawbacks.\n\nMy general plan is to have a single installation guide, with the first\ncouple chapters providing the simplest evolvable installation, and the\nrest being a sort of choose-your-own-adventure on adding to that basic\ninstallation. Having example setups would help a lot in getting the\nstructure right.\n\nThanks,\nShaun\n\n\n\n\n',NULL,NULL),('<1374163173.94770.YahooMailNeo@web120403.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-18 08:59:33',-25200,'2013-07-18 15:59:33',NULL,'[Openstack-operators] Instance Scheduling on Hosts','Thank you for the suggestions on the topic.\nI ended up to add these lines to the RamFilter file \"/usr/lib/python2.6/site-packages/nova/scheduler/filters/ram_filter.py\":\n----\n??????? if usable_ram >= big_ram_node and requested_ram < big_ram_flavor:\n??????????? LOG.debug(_(\"%(host_state)s has %(usable_ram)s MB usable ram,\"\n??????????????????? \"which is too much for a %(requested_ram)s MB VM\"),\n??????????????????? locals())\n??????????? return False\n----\n\nwhere \"big_ram_node\" and \"big_ram_flavor\" are the thresholds I considered for big VMs and big resources.\n\nBy this means I beleive it became more flexible, such that, if all the regular nodes were occupied, the small VMs would go on the big nodes.\n \n\n\n________________________________\n From: Narayan Desai <narayan.desai at gmail.com>\nTo: Ahmad Ahmadi <ahmadidamha at yahoo.com> \nCc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \nSent: Tuesday, July 2, 2013 7:33 PM\nSubject: Re: [Openstack-operators] Instance Scheduling on Hosts\n \n\n\nWe put this in a filter (/usr/share/pyshared/nova/scheduler/filters/hostname_filter.py)\n\nIn our case, we have several different classes of hardware. (gpu, idp, mem) We\'ve created a series of instance types for each chassis type (mem.100, idp.50, etc, with the appropriate resource definitions). Our users mostly use these.\n\nI just realized that the basic instance types aren\'t being filtered from running on special chassis types (mem, and gpu). We haven\'t hit this so far because we have 50X more IDP nodes than mem or GPU, but we\'ve just been lucky.\n\nTo fix that, you could remove the blank lines between clauses and bottom out with a case that enforces that the node name is one of your lowmem nodes for the generic instance types.\n?-nld\n\n\nfrom nova.scheduler import filters\n\nfrom nova import log as logging\nfrom nova import utils\n\nLOG = logging.getLogger(__name__)\n\nclass HostnameFilter(filters.BaseHostFilter):\n? ? \"\"\"Assign instance type name prefix to specific hostnames\"\"\"\n\n? ? def host_passes(self, host_state, filter_properties):\n? ? ? ? #LOG.warning(\"Flavor name %s\", filter_properties.get(\'instance_type\')[\'name\'].split(\'.\')[0])\n? ? ? ? #LOG.warning(\"host_state %s\", host_state)\n? ? ? ? #LOG.warning(\"host name %s\", host_state.host)\n\n? ? ? ? if filter_properties.get(\'instance_type\')[\'name\'].split(\'.\')[0] == \'mem\':\n? ? ? ? ? ? if host_state.host.startswith(\'m\',1):\n? ? ? ? ? ? ? ? return True\n\n? ? ? ? if filter_properties.get(\'instance_type\')[\'name\'].split(\'.\')[0] == \'idp\':\n? ? ? ? ? ? if host_state.host.startswith(\'c\',1):\n? ? ? ? ? ? ? ? return True\n\n? ? ? ? if filter_properties.get(\'instance_type\')[\'name\'].split(\'.\')[0] == \'gpu\':\n? ? ? ? ? ? if host_state.host.startswith(\'g\',1):\n? ? ? ? ? ? ? ? return True\n\n\n\nOn Tue, Jul 2, 2013 at 4:56 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:\n\nThis is exactly what I\'m looking for, but don\'t know how!\n>Would you please describe a bit more?\n>\n>Thanks\n>\n>\n>________________________________\n> From: Narayan Desai <narayan.desai at gmail.com>\n>To: Ahmad Ahmadi <ahmadidamha at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, July 2, 2013 3:30 PM\n>Subject: Re: [Openstack-operators] Instance Scheduling on Hosts\n> \n>\n>\n>We accomplished with a scheduler filter that only routes big mem requests to nodes with large memory footprint and doesn\'t consider these for smaller instance types.\n>?-nld\n>\n>\n>\n>On Tue, Jul 2, 2013 at 3:55 PM, Ahmad Ahmadi <ahmadidamha at yahoo.com> wrote:\n>\n>I have two groups of hosts as compute nodes:\n>>\n>>BigGroup: a few machines with very big RAM\n>>SmallGroup: a lot of machines with smaller RAM each.\n>>\n>>\n>>My goal is to assigne bigger instances (from bigger flavors) to BigGroup and smaller instances to SmallGroup.\n>>I tried the \"AggregateInstanceExtraSpecsFilter\" filtering with assigning different keys to instances and making aggregated hosts (http://docs.openstack.org/folsom/openstack-compute/admin/content/host-aggregates.html), but didn\'t work and all the instance boots will end up to error.\n>>Any idea?\n>>\n>>\n>>More over does anyone know how can I assign higher cost to bigger nodes for weighting?\n>>\n>>\n>>Thanks,\n>>\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130718/50de665c/attachment.html>\n\n','<CABweQmJ6eKs=E47OguBQ1DcxqqickKvX+Coqz3hASW9Vq=cq2Q@mail.gmail.com>',NULL),('<1374165563-sup-1173@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 09:55:06',-25200,'2013-07-18 16:55:06',NULL,'[openstack-dev] [Heat] Long-term,\n	how do we make heat image/flavor name agnostic?','Excerpts from Adrian Otto\'s message of 2013-07-18 06:31:10 -0700:\n> Robert,\n> \n> On Jul 18, 2013, at 3:08 AM, Robert Collins <robertc at robertcollins.net>\n>  wrote:\n> \n> > On 18 July 2013 08:53, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:\n> >> I spent a bunch of time working with and understanding Heat in H2, and I find myself with one overarching question which I wonder if anyone\'s thought about or even answered already...\n> >> \n> >> At present, the CloudFormation template format is the first-class means of doing things in Heat. CloudFormation was created for Amazon, and Amazon has this massive convenience of having a (more or less) static list of images and flavors that they control. Therefore in CloudFormation everything is specified by a unique, specific name.\n> >> \n> >> OpenStack doesn\'t have this luxury. We have as many image and flavor names as we have deployments. Now, there are simple answers...\n> >> \n> >>  1. Name everything the way Amazon does, or\n> >>  2. Alter your templates.\n> >> \n> >> But personally, I don\'t like either of these options. I think in the long term we win at platform/ecosystem by making it possible to take a template off the internet and having it work on *any* OpenStack cloud.\n> >> \n> >> To get there, we need a system that chooses images based on metadata (platform, architecture, distro) and flavors based on actual minimum requirements.\n> > \n> > We do? Why do we?\n> \n> One of our goals with the HOT approach (rather than CloudFormation templates) is to make templates portable between different OpenStack clouds. We\'d like to get it to a point where whether you are using a public or private cloud, or different public clouds, that you just use the same template and it just works. This is what we refer to when we talk about making orchestration Declarative. We want it to be declarative for the things that will differ between clouds. It can have aspects that are Imperative for the things that we can expect to remain the same between clouds. This way we get to a point whee we can have a thriving ecosystem of templates that don\'t need to be fooled with in order to use them.\n> \n> Note that we don\'t expect to necessarily get there in the first iteration, but I think this vision is important so we know where to head through our refinements.\n> \n> > Note that your characterisation of Amazon is in my experience\n> > inaccurate - a very common pattern there is uploading custom images\n> > (such as those that we build for OpenStack using diskimage-builder).\n> > An OpenStack cloud should let users upload their own images to glance\n> > in the same way, and then you have 3): use golden images, name your\n> > personal images the same in every cloud you burst to; done.\n> \n> This amounts to roughly the same amount of fooling/adjusting as you would need to do if you just changed the image name in the template file. We want to eliminate this entire category of fooling around. If you have orchestration, and a CM system integrated together, the reliance on custom images diminishes considerably.\n> \n\nCustom images have their place. They have some distinct advantages over\nsystems that are routinely and repeatedly customized in-service. To focus\non custom or vanilla images solely is a mistake. While you might get\n\"easy\" portability because you start from a common base, you are also\ngetting more entropy, and more susceptibility to external failures.\n\nThere is no one right answer, but there is definitely data to prove both\napproaches have merit.\n\n> > Also note that the presence of golden images makes a \'just fit the\n> > broad characteristics\' a more complex problem than perhaps you think\n> > it is... You need some additional \'is it the right built image\' aspect\n> > too.\n> > \n> > So I would tackle this using 4) provide a mapping layer that bridges\n> > template to cloud and lets you translate:\n> > - image names\n> > - flavors\n> > - keypair\n> > - perhaps volumes and other things\n> \n> Mappings is one of the high level concepts in CFN that I think can be completely eliminated with auto-discovery.\n> \n\nYou say potato...\n\nMapping and auto discovery are largely the same thing. Robert is saying\nhe\'s going to write an app template which says it wants a provider for\n\"my-custom-image\".  You are saying you will write a template that says\nit wants \"ubuntu\" and \"puppet\". We need both use cases to be simple and\nstraight forward.\n\n\n','<5E940A59-D793-482C-A94E-62304C79E5BF@rackspace.com>',NULL),('<1374169783.2293.32.camel@tmckaylt.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 13:49:43',-14400,'2013-07-18 17:49:43',NULL,'[openstack-dev] Savanna EDP sequence diagrams added for\n	discussion...','Hi all,\n\n  Here is a page to hold sequence diagrams for Savanna EDP, \nbased on current launchpad blueprints.  We thought it might be helpful to \ncreate some diagrams for discussion as the component specs are written and the\nAPI is worked out:\n\n  https://wiki.openstack.org/wiki/Savanna/EDP_Sequences\n\n  (The main page for EDP is here https://wiki.openstack.org/wiki/Savanna/EDP )\n\n  There is an initial sequence there, along with a link to the source \nfor generating the PNG with PlantUML.  Feedback would be great, either \nthrough IRC, email, comments on the wiki, or by modifying \nthe sequence and/or posting additional sequences.\n\n  The sequences can be generated/modified easily with with Plantuml which \ninstalls as a single jar file:\n\n  http://plantuml.sourceforge.net/download.html\n \n  java -jar plantuml.jar\n\n  Choose the directory which contains plantuml text files and it will\nmonitor, generate, and update PNGs as you save/modify text files. I thought\nit was broken the first time I ran it because there are no controls :)\nVery simple.\n\nBest,\n\nTrevor\n\n\n\n',NULL,NULL),('<1374172862.32311.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 19:41:02',3600,'2013-07-18 18:41:02',NULL,'[openstack-dev] [Oslo-incubator] Request for meeting','Hi,\n\nOn Thu, 2013-07-18 at 13:15 -0500, Lance D Bragstad wrote:\n> \n> Hey all,\n> \n> Just wanted to throw a word out to see if we could get an Oslo meeting\n> scheduled, or if anyone else has some topics that would be relevant to\n> discuss pertaining to recent Oslo work. I have a change in Oslo that I\n> would like to discuss, but I don\'t think it would justify a meeting on it\'s\n> own. Just wondering if anyone else had some things to bring up to justify\n> holding a meeting.\n> \n> https://review.openstack.org/#/c/34834/.\n> \n> If we don\'t get one scheduled this week due to late notice I completely\n> understand. Thanks all!\n\nThere\'s a meeting scheduled for tomorrow:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-July/012020.html\n\nCheers,\nMark.\n\n\n\n','<OFA96DA403.693A5822-ON86257BAC.006390DD-86257BAC.00644E18@us.ibm.com>',NULL),('<1374178571.16543395.1400781880929.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 14:04:40',-14400,'2014-05-22 18:04:40',NULL,'[openstack-dev] [NFV][Neutron] Link to patch/review for allowing\n instances to receive vlan tagged traffic','Hi Alan/Balazs,\n\nIn one of the NFV BoF sessions in Atlanta one of you (I assume one of you anyway!) noted in the etherpad [1] (line 89) that Ericsson had submitted a patch to Neutron which would allow instances to use tagged vlan traffic. Do you happen to have a link handy to the review for this?\n\nThanks in advance,\n\nSteve\n\n[1] https://etherpad.openstack.org/p/juno-nfv-bof\n\n\n','<70240185.16536856.1400781632425.JavaMail.zimbra@redhat.com>',NULL),('<1374179194.2293.35.camel@tmckaylt.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 16:26:34',-14400,'2013-07-18 20:26:34',NULL,'[openstack-dev] [Savanna-all] Savanna EDP sequence diagrams\n added for discussion...','fyi, updates to the diagram based on feedback\n\nOn Thu, 2013-07-18 at 13:49 -0400, Trevor McKay wrote:\n> Hi all,\n> \n>   Here is a page to hold sequence diagrams for Savanna EDP, \n> based on current launchpad blueprints.  We thought it might be helpful to \n> create some diagrams for discussion as the component specs are written and the\n> API is worked out:\n> \n>   https://wiki.openstack.org/wiki/Savanna/EDP_Sequences\n> \n>   (The main page for EDP is here https://wiki.openstack.org/wiki/Savanna/EDP )\n> \n>   There is an initial sequence there, along with a link to the source \n> for generating the PNG with PlantUML.  Feedback would be great, either \n> through IRC, email, comments on the wiki, or by modifying \n> the sequence and/or posting additional sequences.\n> \n>   The sequences can be generated/modified easily with with Plantuml which \n> installs as a single jar file:\n> \n>   http://plantuml.sourceforge.net/download.html\n>  \n>   java -jar plantuml.jar\n> \n>   Choose the directory which contains plantuml text files and it will\n> monitor, generate, and update PNGs as you save/modify text files. I thought\n> it was broken the first time I ran it because there are no controls :)\n> Very simple.\n> \n> Best,\n> \n> Trevor\n> \n> \n\n\n\n\n','<1374169783.2293.32.camel@tmckaylt.redhat.com>',NULL),('<1374200169.32040.208.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 22:16:09',-14400,'2013-07-19 02:16:09',NULL,'[openstack-dev] [barbican] Use common openstack crypto from oslo ?','I was taking a look at Barbican sources on github and I noticed there is\nan implementation of a crypto class there.\n\nI was wondering if Barbican can be made to use the crypto utils pushed\nto oslo-incubator instead of using a project specific version.\n\nI ask because the implementation seem incomplete plus it seem to me (but\nit is late) that _strip_pad will just fail when the plaintext is an\nexact multiple of the block_size.\n\nLet me know if you need help using the (now) common crypto utils\nfunctions instead.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n',NULL,NULL),('<1374201831.32040.210.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 22:43:51',-14400,'2013-07-19 02:43:51',NULL,'[openstack-dev] [barbican] Use common openstack crypto from\n oslo ?','On Thu, 2013-07-18 at 22:16 -0400, Simo Sorce wrote:\n> I was taking a look at Barbican sources on github and I noticed there is\n> an implementation of a crypto class there.\n> \n> I was wondering if Barbican can be made to use the crypto utils pushed\n> to oslo-incubator instead of using a project specific version.\n> \n> I ask because the implementation seem incomplete plus it seem to me (but\n> it is late) that _strip_pad will just fail when the plaintext is an\n> exact multiple of the block_size.\n\nNVM about this detail, _strip_pad is just fine, I knew I should not\ntrust my eyes this late :)\n\n> Let me know if you need help using the (now) common crypto utils\n> functions instead.\n\nThe suggestion to use the common code and offer for help stands though.\n\nSimo.\n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<1374200169.32040.208.camel@willson.li.ssimo.org>',NULL),('<1374246514.32311.28.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-19 16:08:34',3600,'2013-07-19 15:08:34',NULL,'[openstack-dev] Reminder: Oslo project meeting','On Tue, 2013-07-16 at 22:11 +0100, Mark McLoughlin wrote:\n> Hi\n> \n> We\'re having an IRC meeting on Friday to sync up again on the messaging\n> work going on:\n> \n>   https://wiki.openstack.org/wiki/Meetings/Oslo\n>   https://etherpad.openstack.org/HavanaOsloMessaging\n> \n> Feel free to add other topics to the wiki\n> \n> See you on #openstack-meeting at 1400 UTC\n\nLogs are published here:\n\n  http://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-07-19-14.00.html\n\nCheers,\nMark.\n\n\n\n','<1374009107.10134.55.camel@sorcha>',NULL),('<1374594718-sup-8657@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 09:03:46',-25200,'2013-07-23 16:03:46',NULL,'[openstack-dev] [Heat] Multi region support for Heat','Excerpts from Steve Baker\'s message of 2013-07-22 21:43:05 -0700:\n> On 07/23/2013 10:46 AM, Angus Salkeld wrote:\n> > On 22/07/13 16:52 +0200, Bartosz G?rski wrote:\n> >> Hi folks,\n> >>\n> >> I would like to start a discussion about the blueprint I raised about\n> >> multi region support.\n> >> I would like to get feedback from you. If something is not clear or\n> >> you have questions do not hesitate to ask.\n> >> Please let me know what you think.\n> >>\n> >> Blueprint:\n> >> https://blueprints.launchpad.net/heat/+spec/multi-region-support\n> >>\n> >> Wikipage:\n> >> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat\n> >>\n> >\n> > What immediatley looks odd to me is you have a MultiCloud Heat talking\n> > to other Heat\'s in each region. This seems like unneccessary\n> > complexity to me.\n> > I would have expected one Heat to do this job.\n> \n> It should be possible to achieve this with a single Heat installation -\n> that would make the architecture much simpler.\n> \n\nAgreed that it would be simpler and is definitely possible.\n\nHowever, consider that having a Heat in each region means Heat is more\nresilient to failure. So focusing on a way to make multiple Heat\'s\ncollaborate, rather than on a way to make one Heat talk to two regions\nmay be a more productive exercise.\n\n\n','<51EE09D9.4030906@redhat.com>',NULL),('<1374597215-sup-6238@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 09:39:35',-25200,'2013-07-23 16:39:35',NULL,'[openstack-dev] [tripleo] removing sudoers.d rules from\n	disk-image-builder','Excerpts from Robert Collins\'s message of 2013-07-23 02:52:11 -0700:\n> We have a bunch of sudo rules in disk-image-builder. They are there\n> primarily so we could have passwordless sudo on jenkins boxes, but\n> working with the infra team now, it looks like we\'d run on\n> devstack-gate nodes, not on jenkins directly, so they aren\'t needed\n> for that.\n> \n> They don\'t add appreciable security for end users as they are\n> trivially bypassed with link attacks.\n> \n> And for distributors they are not something you want to install from a package.\n> \n> The only thing the *do* do is permit long running builds to run\n> unattended by users with out reprompting for sudo; but this isn\'t an\n> issue for most users, as we download the bulk of data before hitting\n> the first sudo call.\n> \n> So I\'d like to change things to say:\n>  - either run sudo disk-image-create or\n>  - setup passwordless sudo or\n>  - don\'t run unattended.\n> \n> and delete the sudoers.d rules as being a distraction, one we no longer need.\n> \n> Opinions?\n\nKeeping it simple seems more useful in keeping diskimage-builder users\nsecure than specifying everything. Perhaps a user who wants to chase\nhigher security will do so using SELinux or AppArmor. +1 for the plan.\n\n\n','<CAJ3HoZ0Y6CwqpkzZTSBrU3X3UDd5-d4UhnHvsjs3q-mGMOacCQ@mail.gmail.com>',NULL),('<1374614280-sup-6826@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 15:00:10',-25200,'2013-07-23 22:00:10',NULL,'[openstack-dev] A simple way to improve nova scheduler','Excerpts from Boris Pavlovic\'s message of 2013-07-19 07:52:55 -0700:\n> Hi all,\n> \n> \n> \n> In Mirantis Alexey Ovtchinnikov and me are working on nova scheduler\n> improvements.\n> \n> As far as we can see the problem, now scheduler has two major issues:\n> \n> \n> 1) Scalability. Factors that contribute to bad scalability are these:\n> \n> *) Each compute node every periodic task interval (60 sec by default)\n> updates resources state in DB.\n> \n> *) On every boot request scheduler has to fetch information about all\n> compute nodes from DB.\n> \n> 2) Flexibility. Flexibility perishes due to problems with:\n> \n> *) Addiing new complex resources (such as big lists of complex objects e.g.\n> required by PCI Passthrough\n> https://review.openstack.org/#/c/34644/5/nova/db/sqlalchemy/models.py)\n> \n> *) Using different sources of data in Scheduler for example from cinder or\n> ceilometer.\n> \n> (as required by Volume Affinity Filter\n> https://review.openstack.org/#/c/29343/)\n> \n> \n> We found a simple way to mitigate this issues by avoiding of DB usage for\n> host state storage.\n> \n> \n> A more detailed discussion of the problem state and one of a possible\n> solution can be found here:\n> \n> https://docs.google.com/document/d/1_DRv7it_mwalEZzLy5WO92TJcummpmWL4NWsWf0UWiQ/edit#\n> \n\nThis is really interesting work, thanks for sharing it with us. The\ndiscussion that has followed has brought up some thoughts I\'ve had for\na while about this choke point in what is supposed to be an extremely\nscalable cloud platform (OpenStack).\n\nI feel like the discussions have all been centered around making \"the\"\nscheduler(s) intelligent.  There seems to be a commonly held belief that\nscheduling is a single step, and should be done with as much knowledge\nof the system as possible by a well informed entity.\n\nCan you name for me one large scale system that has a single entity,\nhuman or computer, that knows everything about the system and can make\ngood decisions quickly?\n\nThis problem is screaming to be broken up, de-coupled, and distributed.\n\nI keep asking myself these questions:\n\nWhy are all of the compute nodes informing all of the schedulers?\n\nWhy are all of the schedulers expecting to know about all of the compute nodes?\n\nCan we break this problem up into simpler problems and distribute the load to\nthe entire system?\n\nThis has been bouncing around in my head for a while now, but as a\nshallow observer of nova dev, I feel like there are some well known\nscaling techniques which have not been brought up. Here is my idea,\nforgive me if I have glossed over something or missed a huge hole:\n\n* Schedulers break up compute nodes by hash table, only caring about\n  those in their hash table.\n* Schedulers, upon claiming a compute node by hash table, poll compute\n  node directly for its information.\n* Requests to boot go into fanout.\n* Schedulers get request and try to satisfy using only their own compute\n  nodes.\n* Failure to boot results in re-insertion in the fanout.\n\nThis gives up the certainty that the scheduler will find a compute node\nfor a boot request on the first try. It is also possible that a request\ngets unlucky and takes a long time to find the one scheduler that has\nthe one last \"X\" resource that it is looking for. There are some further\noptimization strategies that can be employed (like queues based on hashes\nalready tried.. etc).\n\nAnyway, I don\'t see any point in trying to hot-rod the intelligent\nscheduler to go super fast, when we can just optimize for having many\nmany schedulers doing the same body of work without blocking and without\npounding a database.\n\n\n','<CAD85om0ZRWP5k5vHas=gG31p71sAr60-_85__g+PSFOsOuc2JQ@mail.gmail.com>',NULL),('<1374622187.18186.3.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 19:29:47',-14400,'2013-07-23 23:29:47',NULL,'[openstack-dev] [keystone] Extending policy checking to include\n target entities','On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote:\n> ...the problem is that if the object does not exists we might not be able tell whether the use is authorized or not (since authorization might depend on attributes of the object itself)....so how do we know wether to lie or not?\n\nIf the error you return is always \'Not Found\', why do you care ?\n\nSimo.\n\n> Henry\n> On 23 Jul 2013, at 21:23, David Chadwick wrote:\n> \n> > \n> > \n> > On 23/07/2013 19:02, Henry Nash wrote:\n> >> One thing we could do is:\n> >> \n> >> - Return Forbidden or NotFound if we can determine the correct answer\n> >> - When we can\'t (i.e. the object doesn\'t exist), then return NotFound\n> >> unless a new config value \'policy_harden\' (?) is set to true (default\n> >> false) in which case we translate NotFound into Forbidden.\n> > \n> > I am not sure that this achieves your objective of no data leakage through error codes, does it?\n> > \n> > Its not a question of determining the correct answer or not, its a question of whether the user is authorised to see the correct answer or not\n> > \n> > regards\n> > \n> > David\n> >> \n> >> Henry\n> >> On 23 Jul 2013, at 18:31, Adam Young wrote:\n> >> \n> >>> On 07/23/2013 12:54 PM, David Chadwick wrote:\n> >>>> When writing a previous ISO standard the approach we took was as follows\n> >>>> \n> >>>> Lie to people who are not authorised.\n> >>> \n> >>> Is that your verbage?  I am going to reuse that quote, and I would\n> >>> like to get the attribution correct.\n> >>> \n> >>>> \n> >>>> So applying this approach to your situation, you could reply Not\n> >>>> Found to people who are authorised to see the object if it had\n> >>>> existed but does not, and Not Found to those not authorised to see\n> >>>> it, regardless of whether it exists or not. In this case, only those\n> >>>> who are authorised to see the object will get it if it exists. Those\n> >>>> not authorised cannot tell the difference between objects that dont\n> >>>> exist and those that do exist\n> >>> \n> >>> So, to try and apply this to a semi-real example:  There are two types\n> >>> of URLs.  Ones that are like this:\n> >>> \n> >>> users/55FEEDBABECAFE\n> >>> \n> >>> and ones like this:\n> >>> \n> >>> domain/66DEADBEEF0000/users/55FEEDBABECAFE\n> >>> \n> >>> \n> >>> In the first case, you are selecting against a global collection, and\n> >>> in the second, against a scoped collection.\n> >>> \n> >>> For unscoped, you have to treat all users as equal, and thus a 404\n> >>> probably makes sense.\n> >>> \n> >>> For a scoped collection we could return a 404 or a 403 Forbidden\n> >>> <https://en.wikipedia.org/wiki/HTTP_403> based on the users\n> >>> credentials:  all resources under domain/66DEADBEEF0000  would show up\n> >>> as 403s regardless of existantce or not if the user had no roles in\n> >>> the domain 66DEADBEEF0000.  A user that would be allowed access to\n> >>> resources in 66DEADBEEF0000  would get a 403 only for an object that\n> >>> existed but that they had no permission to read, and 404 for a\n> >>> resource that doesn\'t exist.\n> >>> \n> >>> \n> >>> \n> >>> \n> >>>> \n> >>>> regards\n> >>>> \n> >>>> David\n> >>>> \n> >>>> \n> >>>> On 23/07/2013 16:40, Henry Nash wrote:\n> >>>>> Hi\n> >>>>> \n> >>>>> As part of bp\n> >>>>> https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n> >>>>> I have uploaded some example WIP code showing a proposed approach\n> >>>>> for just a few API calls (one easy, one more complex). I\'d\n> >>>>> appreciate early feedback on this before I take it any further.\n> >>>>> \n> >>>>> https://review.openstack.org/#/c/38308/\n> >>>>> \n> >>>>> A couple of points:\n> >>>>> \n> >>>>> - One question is on how to handle errors when you are going to get\n> >>>>> a target object before doing you policy check.  What do you do if\n> >>>>> the object does not exist?  If you return NotFound, then someone,\n> >>>>> who was not authorized  could troll for the existence of entities by\n> >>>>> seeing whether they got NotFound or Forbidden. If however, you\n> >>>>> return Forbidden, then users who are authorized to, say, manage\n> >>>>> users in a domain would aways get Forbidden for objects that didn\'t\n> >>>>> exist (since we can know where the non-existant object was!).  So\n> >>>>> this would modify the expected return codes.\n> >>>>> \n> >>>>> - I really think we need some good documentation on how to bud\n> >>>>> keystone policy files.  I\'m happy to take a first cut as such a\n> >>>>> thing - what do you think the right place is for such documentation\n> >>>>> \n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>> \n> >>>> \n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> <mailto:OpenStack-dev at lists.openstack.org>\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> >> \n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<00A4FC5C-3BA3-4B4E-BAA9-D83FDD72C3A3@linux.vnet.ibm.com>',NULL),('<1374644511.31189.37.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 15:41:51',36000,'2013-07-24 05:41:51',NULL,'[openstack-dev] Proposal for API version discovery','On Thu, 2013-05-02 at 00:46 +0000, Gabriel Hurley wrote:\n> Based on input from several of the PTLs (and others), I\'d like to propose the following outline for how version discovery should be handled across heterogeneous clouds:\n> \n> https://etherpad.openstack.org/api-version-discovery-proposal\n> \n> Further discussion is absolutely welcome, and I would like to propose it as a topic for review by the Technical Committee at the next meeting since it involves a significant cross-project standardization effort.\n> \n> All the best,\n> \n>     - Gabriel\n\nSo I started on this somewhat independently before i found the blueprint\nand given I have a semi working implementation i\'ve got a few questions\nor essentially an area i find inconsistent.\n\nAFAIK there are no other serious attempts at this so i\'ve got nothing to\ngo off. Also for the time being I don\'t care about HATEOS, or future\ndiscovery protocols, just getting something that works for keystone now.\n\nI think the way version is treated in the current blueprint is off.\nLooking at \'Auth with a Specified Version\' point 2 says that we should\nnot infer the version from the URL and point 3 says that if i provide a\nversion number with a non-versioned endpoint to retrieve possible\nversions and instantiate a client if an endpoint is available for that\nversion.\n\nI don\'t think that we should be checking the url for what is and what\nisn\'t a versioned endpoint for the same reasons we shouldn\'t be\nretrieving the version from the URL. \n\nWhat i would like to do is treat the version parameter as the requested\nversion, rather than using it to prevent a lookup for versions. What\nthis means is that i can say: \n        client.Client(auth_url=\"http://example.com:5000/\", user=foo,\n        version=2.0, ...)\nand retrieve a version 2 client from a provider that may provide both\nversions v2 & v3. This will still require a lookup of the auth_url even\nthough version is specified. \n\nKeystone (not sure on others) provides version information at GET /v2.0\n(and other versions) as well as GET / so if i say:\n        client.Client(endpoint=\"http://example.com:5000/v2.0\",\n        version=2.0, token=foo)\nIt should be validated that the endpoint is capable of using the V2 api\nand doing:\n        client.Client(endpoint=\"http://example.com:5000/v2.0\",\n        version=3.0, token=foo)\nshould fail immediately.\n\nTo summarize: every call to client.Client should result in a query to\ncheck available versions. The version parameter is an indicator of what\nversion client should be retrieved from those specified as available and\nit should fail if it can\'t deliver. If you _really_ want to use a\nparticular client without a lookup you should use the original\nkeystoneclient.v2_0.Client which is what is returned from a successful\nclient.Client (with version=2) call anyway and takes the same\nparameters.\n\nI\'ve posted the work for review: https://review.openstack.org/#/c/38414/\nand would appreciate comments/clarification. \n\n\nThanks, \n\nJamie\n \n\n\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<BD35DBE010D5B64589500D43F775F2365B330DCE@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1374646118-sup-1634@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-23 23:40:29',-25200,'2013-07-24 06:40:29',NULL,'[openstack-dev] [Heat] Multi region support for Heat','Excerpts from Adrian Otto\'s message of 2013-07-23 21:22:14 -0700:\n> Clint,\n> \n> On Jul 23, 2013, at 10:03 AM, Clint Byrum <clint at fewbar.com>\n>  wrote:\n> \n> > Excerpts from Steve Baker\'s message of 2013-07-22 21:43:05 -0700:\n> >> On 07/23/2013 10:46 AM, Angus Salkeld wrote:\n> >>> On 22/07/13 16:52 +0200, Bartosz G?rski wrote:\n> >>>> Hi folks,\n> >>>> \n> >>>> I would like to start a discussion about the blueprint I raised about\n> >>>> multi region support.\n> >>>> I would like to get feedback from you. If something is not clear or\n> >>>> you have questions do not hesitate to ask.\n> >>>> Please let me know what you think.\n> >>>> \n> >>>> Blueprint:\n> >>>> https://blueprints.launchpad.net/heat/+spec/multi-region-support\n> >>>> \n> >>>> Wikipage:\n> >>>> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat\n> >>>> \n> >>> \n> >>> What immediatley looks odd to me is you have a MultiCloud Heat talking\n> >>> to other Heat\'s in each region. This seems like unneccessary\n> >>> complexity to me.\n> >>> I would have expected one Heat to do this job.\n> >> \n> >> It should be possible to achieve this with a single Heat installation -\n> >> that would make the architecture much simpler.\n> >> \n> > \n> > Agreed that it would be simpler and is definitely possible.\n> > \n> > However, consider that having a Heat in each region means Heat is more\n> > resilient to failure. So focusing on a way to make multiple Heat\'s\n> > collaborate, rather than on a way to make one Heat talk to two regions\n> > may be a more productive exercise.\n> \n> I agree with Angus, Steve Baker, and Randall on this one. We should aim for simplicity where practical. Having Heat services interacting with other Heat services seems like a whole category of complexity that\'s difficult to justify. If it were implemented as Steve Baker described, and the local Heat service were unavailable, the client may still have the option to use a Heat service in another region and still successfully orchestrate. That seems to me like a failure mode that\'s easier for users to anticipate and plan for.\n> \n\nI\'m all for keeping the solution simple. However, I am not for making\nit simpler than it needs to be to actually achieve its stated goals.\n\n> Can you further explain your perspective? What sort of failures would you expect a network of coordinated Heat services to be more effective with? Is there any way this would be more simple or more elegant than other options?\n\nI expect partitions across regions to be common. Regions should be\nexpected to operate completely isolated from one another if need be. What\nis the point of deploying a service to two regions, if one region\'s\nfailure means you cannot manage the resources in the standing region?\n\nActive/Passive means you now have an untested passive heat engine in\nthe passive region. You also have a lot of pointers to update when the\nactive is taken offline or when there is a network partition. Also split\nbrain is basically guaranteed in that scenario.\n\nActive/Active(/Active/...), where each region\'s Heat service collaborates\nand owns its own respective pieces of the stack, means that on partition,\none is simply prevented from telling one region to scale/migrate/\netc. onto another one. It also affords a local Heat the ability to\nreplace resources in a failed region with local resources.\n\nThe way I see it working is actually pretty simple. One stack would\nlead to resources in multiple regions. The collaboration I speak of\nwould simply be that if given a stack that requires crossing regions,\nthe other Heat is contacted and the same stack is deployed. Cross-region\nattribute/ref sharing would need an efficient way to pass data about\nresources as well.\n\nAnyway, I\'m not the one doing the work, so I\'ll step back from the\nposition, but if I were a user who wanted multi-region, I\'d certainly\nwant _a plan_ from day 1 to handle partitions.\n\n\n','<737BF790-775E-44E7-93DA-0CD1941DCD74@rackspace.com>',NULL),('<1374680546.6484.129.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 16:42:26',3600,'2013-07-24 15:42:26',NULL,'[openstack-dev] Julien Danjou and Ben Nemec now on oslo-core','Hey\n\nI just wanted to welcome Ben and Julien to oslo-core. They have both\nbeen doing a lot of high quality reviews lately and it\'s much\nappreciated.\n\nWelcome to the team!\n\nCheers,\nMark.\n\n\n\n',NULL,NULL),('<1374684816-sup-9223@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 10:02:26',-25200,'2013-07-24 17:02:26',NULL,'[openstack-dev] [nova] [baremetal] Mixed bare-metal +\n	hypervisor cloud using grizzly','First off, welcome! :)\n\nFYI, this is the development mailing list. Questions like the one below\nmay find more helpful answers on the general OpenStack users\' mailing list.\nI have CC\'d that list so that this response can be seen there, too, I suggest\nyou re-send your original message there as well.\n\nSee https://launchpad.net/~openstack for that list.\n\nSome info in-line.\n\nExcerpts from Zsolt Haraszti\'s message of 2013-07-23 10:00:59 -0700:\n> Hi,\n> \n> We are very interested to set up a small OpenStack cloud with a portion of\n> the servers used as bare-metal servers and the rest used as \"normal\" KVM\n> hypervisor compute nodes. We are using grizzly, and launch with devstack\n> for simplicity.\n> \n\nI hope you are just trying to develop and not running in production. Devstack\nis not meant for production, and you will spend more time fighting with it\nto get it production ready than you would manually deploying everything.\n\nAlso baremetal is not meant to be multi-tenant. The nodes are not wiped when\na server is deleted, and thus the next tenant may very well be able to read\nunused disk contents. Also there are other places to hide \"evil\" in a machine\nthan just the local disks.\n\n> For a proof-of-concept, I set up an all-in-one node (also acting as KVM\n> compute node). Now I am trying to attach a second compute node running in\n> baremetal mode.\n> \n> Is this known to work?\n> \n\nIt is known to not work. One hypervisor per cloud is all that is allowed.\n\n> As a side note, devstack did not seem to support very well our case, i.e.,\n> when the control node is not the baremetal node. A number of the automated\n> steps were skipped. We worked around this by manually creating the nova_bm\n> database, db sync-ing it, creating and uploading the deploy and test\n> images, and adding a bare-metal flavor. If there were interest, I would be\n> willing to look into modifying devstack to support our case.\n> \n\nDevstack is meant for rapid development of OpenStack. You haven\'t actually\nstated your end use case, but if it is anything other than development of\nOpenStack, you need a new tool.\n\n> After this, I was able to enroll an IPMI-enabled 3rd server as a\n> baremetal-node, but I am unable to create a BM instance on it. The instance\n> gets created in the DB, but the scheduler errors out with NoValidHost. I\n> started debugging the issue by investigating the logs and looking into the\n> code. I see a few things that I suspect may not be right:\n> \n> If I add the second compute node as a normal KVM node, I can see the\n> scheduler on the all-in-one node to show both compute nodes refreshing\n> every 60 seconds. If I re-add the 2nd compute node in BM mode, I can see no\n> more updates coming from that node in the scheduler.\n> \n> Also, I dug into the scheduler code a bit, and I can see that in the\n> scheduler/host_manager.HostManager.get_all_host_states() the call\n> to db.compute_node_get_all(context) returns only one node, the all-in-one.\n> \n> Both of the above suggests that the scheduler may have no visibility of the\n> BM compute node, hence my troubles.\n> \n\nRight, that is because you can only have one hypervisor type.\n\n> I can debug this further, but I though I ask first. Any pointers would be\n> much appreciated.\n> \n\nYou may be interested in the OpenStack Deployment program (aka TripleO):\n\nhttps://github.com/openstack/tripleo-incubator\n\nAnd the current steps to deploy a development centric OpenStack:\n\nhttps://github.com/openstack/tripleo-incubator/blob/master/devtest.md\n\n(These steps, unlike devstack, are meant to be a framework for deploying\nproduction clouds.)\n\n\n','<CA+_7afNyM2b8EGfH8aDK8kzoZuGO+-a9HbEk-WS6a3jUaneLKw@mail.gmail.com>',NULL),('<1374686658.6484.172.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 18:24:18',3600,'2013-07-24 17:24:18',NULL,'[openstack-dev] Python 3','On Wed, 2013-07-24 at 09:31 -0700, Alex Gaynor wrote:\n> I believe Red Hat\'s new \"Software Collections\" things address this issue,\n> this is to the point which Django (which has historically used RHEL as a\n> barometer for when we could drop Pythons) will drop 2.6 in our next release.\n\nYep, that\'s a very good point.\n\nWe\'re as keen as anyone else to get off Python 2.6 and AIUI some folks\non our team are hoping to get RDO Havana onto the 2.7 SCL from here:\n\n  https://fedorahosted.org/SoftwareCollections/\n\nSo, assuming nothing crazy crops up, we should be getting close to a\npoint where dropping 2.6 support upstream would not be a big issue for\nRHEL users.\n\nCheers,\nMark.\n\n> On Wed, Jul 24, 2013 at 9:00 AM, Monty Taylor <mordred at inaugust.com> wrote:\n> \n> >\n> >\n> > On 07/23/2013 03:02 PM, Brian Curtin wrote:\n> > >\n> > > On Jul 23, 2013, at 3:51 PM, Eric Windisch <eric at cloudscaling.com\n> > > <mailto:eric at cloudscaling.com>>\n> > >  wrote:\n> > >\n> > >>\n> > >>\n> > >>\n> > >> On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton <logan at bacoosta.com\n> > >> <mailto:logan at bacoosta.com>> wrote:\n> > >>\n> > >>     I\'m sure this has been asked before, but what exactly is the plan\n> > >>     for Python 3 support?\n> > >>\n> > >>     Is the plan to support 2 and 3 at the same time? I was looking\n> > >>     around for a blue print or something but I can\'t seem to find\n> > >>     anything.\n> > >>\n> > >>\n> > >> I suppose a wiki page is due.  This was discussed at the last summit:\n> > >> https://etherpad.openstack.org/havana-python3\n> > >>\n> > >> The plan is to support Python 2.6+ for the 2..x series and Python\n> > >> 3.3+. This effort has begun for libraries (oslo) and clients. Work is\n> > >> appreciated on the primary projects, but will ultimately become\n> > >> stalled if the library work is not first completed.\n> >\n> > I\'d like to add that at some point in the future it is our desire to\n> > drop support for 2.6, as supporting 2.7 and 3.3+ is way easier than also\n> > supporting 2.6. At the moment, I believe our main factor on that is the\n> > current version of RHEL. Fingers crossed for a new one soon... :)\n> >\n> > We are also just finishing up getting 3.3 enabled build slaves in the CI\n> > gate, so as projects get 3.3 compliant, we should be able to start\n> > testing that.\n> >\n> > > FWIW, I came across https://wiki.openstack.org/wiki/Python3Deps and\n> > > updated \"routes\", which currently works with 3.3. One small step, for\n> > free!\n> > >\n> > > I\'m a newcomer to this list, but I\'m a CPython core contributor and am\n> > > working in Developer Relations at Rackspace, so supporting Python 3 is\n> > > right up my alley.\n> >\n> > Excellent! Welcome, glad to have you.\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAFRnB2VZOA_uRYbfjVO=TcBWYZEjTt6qdQqiqMGyysfRSVsKag@mail.gmail.com>',NULL),('<1374687790.6484.182.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 18:43:10',3600,'2013-07-24 17:43:10',NULL,'[openstack-dev] Discussing Amazon API compatibility\n [Nova][Swift]','On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote:\n> Hello\n> \n> I have seen lots of discussions on blogs and twitter heating up around\n> Amazon API compatibility and OpenStack. This seems like a recurring\n> topic, often raised by pundits and recently joined by members of the\n> community. I think it\'s time to bring the discussions inside our\n> community to our established channels and processes. Our community has\n> established ways to discuss and take technical decisions, from the more\n> accessible General mailing list to the Development list to the Design\n> Summits, the weekly project meetings, the reviews on gerrit and the\n> governing bodies Technical Committee and Board of Directors.\n> \n> While we have not seen a large push in the community recently via\n> contributions or deployments, Amazon APIs have been an option for\n> deployments from the early days of OpenStack.\n> \n> I would like to have this discussion inside the established channels of\n> our community and get the opinions from those that maintain that\n> OpenStack should increase efforts for Amazon APIs compatibility, and\n> ultimately it would be good to see code contributions.\n> \n> Do you think OpenStack should have an ongoing effort to imitate Amazon\'s\n> API? If you think it should, how would you lead the effort?\n\nI think AWS compatible APIs for any of our services is a great feature.\nI\'d love to tell people they can try out OpenStack by pointing their\nexisting AWS based deployment tools at an OpenStack cloud.\n\nJust yesterday, I saw a comment on IRC along the lines of \"wow, Nova has\nan EC2 API ... I should totally try out using knife with that\".\n\nTwo things seem straightforward and obvious to me - our primary API is\nthe OpenStack \"native\" APIs and, yet, any built-in AWS compatibility we\ncan get is mucho goodness.\n\nThat said, it\'s not \"AWS compat == goodness\" statements we need ... we\nneed people who are keen to contribute to the work.\n\nHowever, the very least we should do is make it clear that if anyone\n*does* step up and do that work, that we\'ll welcome the contributions\nwith open arms.\n\nCheers,\nMark.\n\n\n\n','<51EFF7F8.4090306@openstack.org>',NULL),('<1374690745.3569.24.camel@einstein>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 13:32:25',-18000,'2013-07-24 18:32:25',NULL,'[openstack-dev] Usage of mox through out the Openstack project.','On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:\n> 1. Change mox usage to more python3 friendly such as mock.\n> (https://pypi.python.org/pypi/mock/1.0.1). However this will cause\n> alot of code churn in the projects as we move away from mox to mock.\n> \n> \n> 2. Use the python3 fork called pymox\n> (https://github.com/emonty/pymox). This project has reasonable\n> compatibility with mox and is python3 compatible. Using this option\n> causes less code churn. IMHO this would be the better option.\n\nMy personal preference is that we move to mock; I think it is a better\nmethodology, and I like its features.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\n\n\n\n','<CANZa-eLBNXsdfi4mLnCzmqSB3RdxCCxBEgG-O_Vqos80tUgSuw@mail.gmail.com>',NULL),('<1374691052.396910243@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 14:37:32',-14400,'2013-07-24 18:37:32',NULL,'[openstack-dev] Usage of mox through out the Openstack project.','+1 I prefer mock over mox as well. It\'s more readable and intuitive. I\'ve had a number of bad mox experiences lately so I\'m a tad biased.\n\n-Alex\n\n-----Original Message-----\nFrom: \"Jay Pipes\" <jaypipes at gmail.com>\nSent: Wednesday, July 24, 2013 2:24pm\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Usage of mox through out the Openstack project.\n\nOn 07/24/2013 02:19 PM, Alex Gaynor wrote:\n> I think moving towards mock is a better long term strategy:\n>\n> a) I don\'t you\'re correct that it\'s the most familiar for most python\n> developers. By PyPi installs (A TERRIBLE METRIC, but it\'s all we have).\n> Mock has 24k in the last week, mox has 3.5k\n> b) mock is a part of the standard library starting with python 3.3, this\n> will lead to even more adoption.\n\n++. I personally prefer mock over mox.\n\n-jay\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<51F01BDC.6010504@gmail.com>',NULL),('<1374692287.874825188@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-24 14:58:07',-14400,'2013-07-24 18:58:07',NULL,'[openstack-dev] Usage of mox through out the Openstack project.','+1 to everything Russell just said and of course Blueprints for this. One for #3 (changing from mox -> Mock) would be good so that anyone who is bored or finds this urgent can collaborate. Also, we need to make sure reviewers are aware (Hopefully they are reading this).\n\n-Alex\n\n-----Original Message-----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nSent: Wednesday, July 24, 2013 2:45pm\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Usage of mox through out the Openstack project.\n\nOn 07/24/2013 02:32 PM, Kevin L. Mitchell wrote:\n> On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:\n>> 1. Change mox usage to more python3 friendly such as mock.\n>> (https://pypi.python.org/pypi/mock/1.0.1). However this will cause\n>> alot of code churn in the projects as we move away from mox to mock.\n>>\n>>\n>> 2. Use the python3 fork called pymox\n>> (https://github.com/emonty/pymox). This project has reasonable\n>> compatibility with mox and is python3 compatible. Using this option\n>> causes less code churn. IMHO this would be the better option.\n> \n> My personal preference is that we move to mock; I think it is a better\n> methodology, and I like its features.\n> \n\nThat\'s fine with me if everyone feels that way.  I\'m afraid it\'s not a\nquick move because of how much we\'re using mox.  A practical approach\nwould probably be:\n\n1) Prefer mock for new tests.\n\n2) Use suggestion #2 above to mitigate the Python 3 concern.\n\n3) Convert tests to mock over time, opportunistically, as tests are\nbeing updated anyway.  (Or if someone *really* wants to take this on as\na project ...)\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<51F020DF.20202@redhat.com>',NULL),('<1374855212-sup-1251@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-26 09:22:57',-25200,'2013-07-26 16:22:57',NULL,'[openstack-dev] A simple way to improve nova scheduler','Excerpts from Joe Gordon\'s message of 2013-07-24 11:43:46 -0700:\n> On Wed, Jul 24, 2013 at 12:24 PM, Russell Bryant <rbryant at redhat.com> wrote:\n> \n> > On 07/23/2013 06:00 PM, Clint Byrum wrote:\n> > > This is really interesting work, thanks for sharing it with us. The\n> > > discussion that has followed has brought up some thoughts I\'ve had for\n> > > a while about this choke point in what is supposed to be an extremely\n> > > scalable cloud platform (OpenStack).\n> > >\n> > > I feel like the discussions have all been centered around making \"the\"\n> > > scheduler(s) intelligent.  There seems to be a commonly held belief that\n> > > scheduling is a single step, and should be done with as much knowledge\n> > > of the system as possible by a well informed entity.\n> > >\n> > > Can you name for me one large scale system that has a single entity,\n> > > human or computer, that knows everything about the system and can make\n> > > good decisions quickly?\n> > >\n> > > This problem is screaming to be broken up, de-coupled, and distributed.\n> > >\n> > > I keep asking myself these questions:\n> > >\n> > > Why are all of the compute nodes informing all of the schedulers?\n> >\n>  >\n> > > Why are all of the schedulers expecting to know about all of the compute\n> > nodes?\n> >\n> \n> So the scheduler can try to find the globally optimum solution, see below.\n> \n\nRight, that seems like a costly requirement that most won\'t need.\n\n> > >\n> > > Can we break this problem up into simpler problems and distribute the\n> > load to\n> > > the entire system?\n> > >\n> > > This has been bouncing around in my head for a while now, but as a\n> > > shallow observer of nova dev, I feel like there are some well known\n> > > scaling techniques which have not been brought up. Here is my idea,\n> > > forgive me if I have glossed over something or missed a huge hole:\n> > >\n> > > * Schedulers break up compute nodes by hash table, only caring about\n> > >   those in their hash table.\n> > > * Schedulers, upon claiming a compute node by hash table, poll compute\n> > >   node directly for its information.\n> >\n> \n> For people who want to schedule on information that is constantly changing\n> (such as CPU load, memory usage etc).  How often would you poll?\n> \n\nThats a great question. The initial poll is mostly \"how are you\nnow?\". After that I\'m not sure polling would be the best strategy,\nso perhaps a broadcast topic per-scheduler would still make sense.\nAnd perhaps that broadcast topic would be enough to not even need the\ninitial handshake.\n\n> > > * Requests to boot go into fanout.\n> > > * Schedulers get request and try to satisfy using only their own compute\n> > >   nodes.\n> > > * Failure to boot results in re-insertion in the fanout.\n> >\n> \n> With this model we loose the ability to find the global optimum host to\n> schedule on, and can only find an optimal solution.  Which sounds like a\n> reasonable scale trade off.  Going forward I can image nova having several\n> different schedulers for different requirements.  As someone who is\n> deploying at a massive scale will probably accept an optimal solution (and\n> a scheduler that scales better) but someone with a smaller cloud will want\n> the globally optimum solution.\n> \n\nWhat you may have missed on first pass, is that if you just have 1\nscheduler, you do have globally optimum scheduling. So it is not lost,\nit is just factored out as you add schedulers. It is also quite simple\nto know when to add schedulers.. when your boot request latency gets\ntoo high.\n\n\n','<CAHXdxOfXg5TYi1X1VJOGp1oOy=bJ0r2pyzG-dPOPJs8moH=fRQ@mail.gmail.com>',NULL),('<1374856587-sup-6535@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-26 09:43:31',-25200,'2013-07-26 16:43:31',NULL,'[openstack-dev] [Heat] Multi region support for Heat','Excerpts from Zane Bitter\'s message of 2013-07-26 06:37:09 -0700:\n> On 25/07/13 19:07, Bartosz G?rski wrote:\n> > We want to start from something simple. At the beginning we are assuming\n> > no dependencies between resources from different region. Our first use\n> > case (the one on the wikipage) uses this assumptions. So this is why it\n> > can be easily split on two separate single region templates.\n> >\n> > Our goal is to support dependencies between resources from different\n> > regions. Our second use case (I will add it with more details to the\n> > wikipage soon) is similar to deploying two instances (app server + db\n> > server) wordpress in two different regions (app server in the first\n> > region and db server in the second). Regions will be connected to each\n> > other via VPN connection . In this case configuration of app server\n> > depends on db server. We need to know IP address of created DB server to\n> > properly configure App server. It forces us to wait with creating app\n> > server until db server will be created.\n> \n> That\'s still a fairly simple case that could be handled by a pair of \n> OS::Heat::Stack resources (one provides a DBServerIP output it is passed \n> as a parameter to the other region using {\'Fn::GetAtt\': \n> [\'FirstRegionStack\', \'Outputs.DBServerIP\']}. But it\'s possible to \n> imagine circumstances where that approach is at least suboptimal (e.g. \n> when creating the actual DB server is comparatively quick, but we have \n> to wait for the entire template, which might be slow).\n> \n\nIf you break that stack up into two stacks, db and \"other slow stuff\"\nthen you can get the Output of the db stack earlier, so that is a\nsolvable problem.\n\n> > More complicated use case with load balancers and more regions are also\n> > in ours minds.\n> \n> Good to know, thanks. I\'ll look forward to reading more about it on the \n> wiki.\n> \n> What I\'d like to avoid is a situation where anything _appears_ to be \n> possible (Nova server and Cinder volume in different regions? Sure! \n> Connect \'em together? Sure!), and the user only finds out later that it \n> doesn\'t work. It would be much better to structure the templates in such \n> a way that only things that are legitimate are expressible. That\'s not \n> an achievable goal, but IMO we want to be much closer to the latter than \n> the former.\n> \n\nThese are all predictable limitations and can be handled at the parsing\nlevel.  You will know as soon as you have template + params whether or\nnot that cinder volume in region A can be attached to the nova server\nin region B.\n\nI\'m still convinced that none of this matters if you rely on a single Heat\nin one of the regions. The whole point of multi region is to eliminate\na SPOF.\n\n\n','<51F27B85.1050609@redhat.com>',NULL),('<1374860669-sup-847@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-26 10:53:30',-25200,'2013-07-26 17:53:30',NULL,'[openstack-dev] [tripleo] removing sudoers.d rules from\n	disk-image-builder','Excerpts from Robert Collins\'s message of 2013-07-25 15:39:13 -0700:\n> On 26 July 2013 10:19, Thierry Carrez <thierry at openstack.org> wrote:\n> > Chris Jones wrote:\n> >> I agree with your analysis of the effects of the sudoers file and I\n> >> think it makes a great argument for recommending people run the main\n> >> command itself with sudo, rather than a blanket passwordless sudo, but\n> >> really all we need to say is \"this tool needs to be run as root\" and let\n> >> people make their own decision :)\n> >\n> > Ideally the tool would detect if it\'s run with root privileges and\n> > prompt for password if it\'s not. That way you have two options:\n> > - run sudo TOOL (convenient, can run unattended)\n> > - run TOOL and get prompted (less convenient, slightly more secure)\n> >\n> > If the tool is run by a real user I don\'t think it\'s worth going through\n> > the pain of using rootwrap, although it could be used to implement\n> > smarter privilege escalation rules (like the PathFilter that looks into\n> > canonical paths and is therefore not vulnerable to linking attacks).\n> \n> Many such tools are still vulnerable to race conditions, The only ones\n> I\'m aware of that are not are apparmor and selinux :).\n\nI looked at this and thought \"maybe we could maintain AA and SELinux\nrules!\".\n\nI think it would reveal that one needs so much access to the system\nand the internet (or a populated cache...)  that it needs to be on a\ndedicated bastion host anyway, and as others have suggested, running some\nparts as non-root is mostly to avoid accidentally damaging the build host.\n\nTo those who would say \"but.. the elements...\" Like any other software,\nelements need to be from a trusted source, and/or audited directly.\n\nSo, to be more clear than my last +1, I think removing the file from\nthe source tree, and documenting that one needs to allow blanket sudo\nfor it to work is a valid step forward.\n\n\n','<CAJ3HoZ29PK+_cVfq+M3Axus6L45kBz7J4ZhiaPZfDM83CSCkSw@mail.gmail.com>',NULL),('<1374861502.614626686@emailsrvr.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-26 12:58:22',-18000,'2013-07-26 17:58:22',NULL,'[openstack-dev] Discussing Amazon API compatibility\n	[Nova][Swift]','\nGreat idea Justin and you\'re just the stacker to do it :)  I believe Everett Toews has done some work on this.\n \nOn Friday, July 26, 2013 12:44pm, \"Justin Santa Barbara\" <justin at fathomdb.com> said:\n\n\n\n\n\n\n I think that there is a new driverfor amazon compatibility that has shown up recently: Netflix\'s efforts\n to make their software stack Open Source[1]\n...\n There are a couple of approaches here: one is to change the the other\n open source software to use openstack apis natively. I think this\n is best long term, but we have relatively little expertise in these\n other projects\n\nI\'m pretty familiar with Netflix\'s open-source efforts, and deeply familiar with Java and OpenStack.  If anybody out there is willing to sponsor adding support for OpenStack to the Netflix projects, then please get in contact with me.  Let\'s liberate Netflix from AWS!\nJustin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130726/1b362d37/attachment.html>\n\n','<CAFoXKmogHP7=XKeOe12EJfnROkRou=pPbcSPth-zYkODH+2-Pw@mail.gmail.com>',NULL),('<13748657.3385832.1417723091237.JavaMail.yahoo@jws10633.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 19:58:11',0,'2014-12-04 19:58:11',NULL,'[openstack-dev] 答复:  [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force','\nOriginal message bounced and I didn\'t notice. ?\nthanks,manish\n-----\nSubject:?Re: [openstack-dev] ??: [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force\n\nThanks Rossella.? I\'ll take a look this week.? My name is also on the etherpad already and can help with this.? Somehow missed this thread earlier.\nregards, \n\n     On Friday, November 28, 2014 7:42 AM, Rossella Sblendido <rsblendido at suse.com> wrote:\n   \n\n On 11/27/2014 12:21 PM, marios wrote:\n> Hi, so far we have this going\n> https://etherpad.openstack.org/p/restructure-l2-agent\n\nI finally pushed a design spec based on the etherpad above,\nhttps://review.openstack.org/#/c/137808/ .\nAnybody interested please comment on the review.\n\ncheers,\n\nRossella\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141204/7f996854/attachment.html>\n\n','<5478974D.9030303@suse.com>',NULL),('<1375031058.2376.YahooMailBasic@web160201.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-28 10:04:18',-25200,'2013-07-28 17:04:18',NULL,'[Openstack-operators] Shared storage HA question','>> I have issue with creating shared storage for Openstack. Main idea is to \n>> create 100% redundant shared storage from two servers (kind of network \n>> RAID from two servers).\n>> I have two identical servers with many disks inside. What solution can \n>> any one provide for such schema? I need shared storage for running VMs \n>> (so live migration can work) and also for cinder-volumes.\n\n>> One solution is to install Linux on both servers and use DRBD + OCFS2, \n>> any comments on this?\n>> Also I heard about Quadstor software and it can create network RAID and \n>> present it via iSCSI.\n\nMy two cents worth from a generic concept point view of a network mirror\n\nKey factors to evaluate\n1. Write latency\n2. Active-active or use active-passive with automatic ip address failover (using CARP etc)\n3. Split brain handling\n4. How soon after a node failure are the two node brought in sync.\n\nquadstor shines in many aspects and  DRBD + SCST is a good alternative. You should evaluate both in my opinion.\n\n-Tia\n\n\n',NULL,NULL),('<1375038361.11265.YahooMailBasic@web160218.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-07-28 12:06:01',-25200,'2013-07-28 19:06:01',NULL,'[Openstack-operators] Shared storage HA question','\n--------------------------------------------\nOn Sun, 7/28/13, Tia Song <song_tia at yahoo.com> wrote:\n\n Subject: [Openstack-operators] Shared storage HA question\n To: openstack-operators at lists.openstack.org\n Date: Sunday, July 28, 2013, 10:04 AM\n \n >> I have issue with creating\n shared storage for Openstack. Main idea is to \n >> create 100% redundant shared storage from two\n servers (kind of network \n >> RAID from two servers).\n >> I have two identical servers with many disks\n inside. What solution can \n >> any one provide for such schema? I need shared\n storage for running VMs \n >> (so live migration can work) and also for\n cinder-volumes.\n \n >> One solution is to install Linux on both servers\n and use DRBD + OCFS2, \n >> any comments on this?\n >> Also I heard about Quadstor software and it can\n create network RAID and \n >> present it via iSCSI.\n \n>> My two cents worth from a generic concept point view of a\n network mirror\n \n>> Key factors to evaluate\n>> 1. Write latency\n>> 2. Active-active or use active-passive with automatic ip\n address failover (using CARP etc)\n>> 3. Split brain handling\n>> 4. How soon after a node failure are the two node brought in\n sync.\n \n>> quadstor shines in many aspects and? DRBD + SCST is a\n>> good alternative. You should evaluate both in my opinion.\n\nForgot one major aspect. Fencing.\n1. How easy it is to setup fencing ?\n2. Reliability. Definitely hardware fencing ILO, IPMI etc\n3. Test, test, test. Simulate heavy IO, bring down the network between the two nodes etc.\n\n-Tia\n\n \n\n \n _______________________________________________\n OpenStack-operators mailing list\n OpenStack-operators at lists.openstack.org\n http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n \n\n\n','<1375031058.2376.YahooMailBasic@web160201.mail.bf1.yahoo.com>',NULL),('<1375095340.54674.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 03:55:40',-25200,'2013-07-29 10:55:40',NULL,'[Openstack] Share your localrc file for devstack','Networking for quantum is still kicking my butt.\n\nWould any devstack users be kind enough to post your localrc network settings here?\n\nI am using a allinone devstack node.\n\nThank you!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/2f7a5eb4/attachment.html>\n\n',NULL,NULL),('<1375095514.50377.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 03:58:34',-25200,'2013-07-29 10:58:34',NULL,'[Openstack] Share your localrc file for devstack','Networking for quantum is still kicking my butt.\n\nWould any devstack users be kind enough to post your localrc network settings here?\n\nI am using a stand-alone devstack node. 1 node with 2 nics.\n\nThank you!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/5ff03a59/attachment.html>\n\n',NULL,NULL),('<1375110002-sup-7041@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-29 08:40:29',-25200,'2013-07-29 15:40:29',NULL,'[openstack-dev] [Heat] Multi region support for Heat','Excerpts from Zane Bitter\'s message of 2013-07-29 00:51:38 -0700:\n> On 29/07/13 02:04, Angus Salkeld wrote:\n> > On 26/07/13 09:43 -0700, Clint Byrum wrote:\n> >> Excerpts from Zane Bitter\'s message of 2013-07-26 06:37:09 -0700:\n> >>> On 25/07/13 19:07, Bartosz G?rski wrote:\n> >>> > We want to start from something simple. At the beginning we are\n> >>> assuming\n> >>> > no dependencies between resources from different region. Our first use\n> >>> > case (the one on the wikipage) uses this assumptions. So this is\n> >>> why it\n> >>> > can be easily split on two separate single region templates.\n> >>> >\n> >>> > Our goal is to support dependencies between resources from different\n> >>> > regions. Our second use case (I will add it with more details to the\n> >>> > wikipage soon) is similar to deploying two instances (app server + db\n> >>> > server) wordpress in two different regions (app server in the first\n> >>> > region and db server in the second). Regions will be connected to each\n> >>> > other via VPN connection . In this case configuration of app server\n> >>> > depends on db server. We need to know IP address of created DB\n> >>> server to\n> >>> > properly configure App server. It forces us to wait with creating app\n> >>> > server until db server will be created.\n> >>>\n> >>> That\'s still a fairly simple case that could be handled by a pair of\n> >>> OS::Heat::Stack resources (one provides a DBServerIP output it is passed\n> >>> as a parameter to the other region using {\'Fn::GetAtt\':\n> >>> [\'FirstRegionStack\', \'Outputs.DBServerIP\']}. But it\'s possible to\n> >>> imagine circumstances where that approach is at least suboptimal (e.g.\n> >>> when creating the actual DB server is comparatively quick, but we have\n> >>> to wait for the entire template, which might be slow).\n> >>>\n> >\n> > How about we add an actual heat resource?\n> >\n> > So you could aggregate stacks.\n> >\n> > We kinda have one with \"OS::Heat::Stack\", but it doesn\'t use\n> \n> (aside: this doesn\'t actually exist yet, we only have \n> AWS::CloudFormation::Stack at present.)\n> \n> > python-heatclient. We could solve this by adding an \"endpoint\"\n> >   property to the \"OS::Heat::Stack\" resource. Then if it is not\n> > local then it uses python-heatclient to create the nested stack\n> > remotely.\n> \n> Yes, that\'s what I was trying (and failing) to suggest.\n> \n> >\n> > Just a thought.\n> >\n> > -Angus\n> >\n> >>\n> >> If you break that stack up into two stacks, db and \"other slow stuff\"\n> >> then you can get the Output of the db stack earlier, so that is a\n> >> solvable problem.\n> \n> +1\n> \n> >>> > More complicated use case with load balancers and more regions are\n> >>> also\n> >>> > in ours minds.\n> >>>\n> >>> Good to know, thanks. I\'ll look forward to reading more about it on the\n> >>> wiki.\n> >>>\n> >>> What I\'d like to avoid is a situation where anything _appears_ to be\n> >>> possible (Nova server and Cinder volume in different regions? Sure!\n> >>> Connect \'em together? Sure!), and the user only finds out later that it\n> >>> doesn\'t work. It would be much better to structure the templates in such\n> >>> a way that only things that are legitimate are expressible. That\'s not\n> >>> an achievable goal, but IMO we want to be much closer to the latter than\n> >>> the former.\n> >>>\n> >>\n> >> These are all predictable limitations and can be handled at the parsing\n> >> level.  You will know as soon as you have template + params whether or\n> >> not that cinder volume in region A can be attached to the nova server\n> >> in region B.\n> \n> That\'s true, but IMO it\'s even better if it\'s obvious at the time you \n> are writing the template. e.g. if (as is currently the case) there is no \n> mechanism within a template to select a region for each resource, then \n> it\'s obvious you have to write separate templates for each region (and \n> combine them somehow).\n> \n\nThe language doesn\'t need to be training wheels for template writers. The\nlanguage parser should just make it obvious when you\'ve done something\npatently impossible. Because cinderclient will only work with a region\nat a time, we can make that presumption at that resource level, and flag\nthe problem during creation before any resources have been allocated.\n\nBut it would be quite presumptuous of Heat, at a language layer, to\nsay all things are single region.  There\'s an entirely good use case\nfor cross-region volumes and if it is ever implemented that way, and\ncinderclient got some multi-region features, we wouldn\'t want users\nto be faced with a big rewrite of their templates just to make use of\nthem. We should just be able to do the cross region thing now, because\nwe have that capability.\n\nI dislike the language defining everything and putting users in too\ntight of a box. How many times have you been using a DSL and shaken your\nfists in the air, \"get out of my way!\"? I would suggest that cross region\nsupport is handled resource by resource.\n\n> >> I\'m still convinced that none of this matters if you rely on a single\n> >> Heat\n> >> in one of the regions. The whole point of multi region is to eliminate\n> >> a SPOF.\n> \n> So the idea here would be that you spin up a master template in one \n> region, and this would contain OS::Heat::Stack resources that use \n> python-heatclient to connect to Heat APIs in other regions to spin up \n> the constituent stacks in each region. If a region goes down, even if it \n> is the one with your master template, that\'s no problem because you can \n> still interact with the constituent stacks directly in whatever \n> region(s) you _can_ reach.\n> \n\nInteracting with a nested stack directly would be a very uncomfortable\nproposition. How would this affect changes from the master? Would the\nmaster just overwrite any changes I make or refuse to operate?\n\n> So it solves the non-obviousness problem and the single-point-of-failure \n> problem in one fell swoop. The question for me is whether there are \n> legitimate use cases that this would shut out.\n> \n\nWith this solution to those problems, you have a new non-obvious problem\nwhich is the split brain I describe above. If master goes down, you have\nto play the master\'s role, and when the master returns, does it just\ngive up because you\'ve tainted its stacks? Do you develop new API commands\nto help resolve this? Use merge techniques?\n\nI believe that those problems are no less complex than the problem of\nhow to make Heat engines simply act as peers that need to share data.\n\n\n','<51F61F0A.3000100@redhat.com>',NULL),('<1375112869-sup-6070@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 09:13:13',-25200,'2013-07-29 16:13:13',NULL,'[Openstack] [Spam] Re: what is the meaning to alliance with\n	VMWare?','Excerpts from Peter Cheung\'s message of 2013-07-29 07:29:10 -0700:\n> Dear Brian     thanks for reply. May be because there is no cheap AIX, so linux and AIX can be sell in different price range. But in here, the market is : openstack compete with ESXi or ESX essential plus. We are a consultancy firm, our sales are competing with VMware sales. In HK, vmware sales even want us die. If we die, the only competitor left is microsoft.The war here is very obvious.\n\nHi Peter. I understand that at times, sales negotiations can be like war,\nwith your client being the innocent bystanders caught in the middle.\n\nBut markets are not war-zones. Wars intrinsically expend\nresources. Markets, however, grow resources and make things more\nefficient, until they are outmoded, and then they shrink naturally.\n\nSo looking at VMware as a combatant on the field of battle, they are\nintimidating and evoke fear. I would not want to do battle with this\nwell trained highly motivated battle group.\n\nIf, however, we look at VMware as neighbors, the feelings are different. I\nbelieve that they\'re really just interested in developing the huge\nuntapped resources which are basically unavailable to them without the\ncooperation and lower cost model of projects like OpenStack. \n\nTo use an analogy, if VMware is FedEx, OpenStack is \"people who want\nefficient roads and airports.\"\n\n\n','<BAY177-W36BA840C86A8C79E7902EBB5550@phx.gbl>',NULL),('<1375118104-sup-3585@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 10:43:08',-25200,'2013-07-29 17:43:08',NULL,'[Openstack] [Spam] RE: [Spam] Re: what is the meaning to\n	alliance with VMWare?','Excerpts from Peter Cheung\'s message of 2013-07-29 09:52:46 -0700:\n> Thanks Clint. If we treat VMWare as a neighbor, we meet another trouble, how can we pack openstack and vmware into a single solution? what kind of customer need such as solution?\n> Compete with VMWare seems to be the right choice, openstack has a great advantage in price and community. People may say vmware features are still better, but we just need some more time to catch up. This is just my opinion.\n> \n\nYou\'re treating OpenStack like it is a product. It is a platform, and\nwe build products on top of that platform.\n\nWe don\'t need to worry about packing OpenStack and VMware together. If\nthere are users who need such a thing, healthy cooperation in the market\nwill enable them. Any abuse of the market will just delay growth into\nthose users\' section of the market by wasting their money and/or time.\n\nHead-on competition is not the only course of action, and in fact in\nthis situation, that is probably the course of most disaster. Neighbors\ndon\'t have to compete directly. They can improve the market conditions\nby solidifying the infrastructure, and thus have sustainable shares of\na growing healthy market. The competition is real already, and it will\nincrease, but lets not fixate on it when there are huge opportunities\nthat allow us to side-step it altogether.\n\n\n','<BAY177-W472A2AE7C5E2F08B18CB75B5550@phx.gbl>',NULL),('<1375122137-sup-5288@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-29 11:42:57',-25200,'2013-07-29 18:42:57',NULL,'[openstack-dev] [Heat] Multi region support for Heat','Excerpts from Zane Bitter\'s message of 2013-07-29 10:21:29 -0700:\n> On 29/07/13 17:40, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2013-07-29 00:51:38 -0700:\n> >> >On 29/07/13 02:04, Angus Salkeld wrote:\n> >>> > >On 26/07/13 09:43 -0700, Clint Byrum wrote:\n> >>>> > >>\n> >>>> > >>These are all predictable limitations and can be handled at the parsing\n> >>>> > >>level.  You will know as soon as you have template + params whether or\n> >>>> > >>not that cinder volume in region A can be attached to the nova server\n> >>>> > >>in region B.\n> >> >\n> >> >That\'s true, but IMO it\'s even better if it\'s obvious at the time you\n> >> >are writing the template. e.g. if (as is currently the case) there is no\n> >> >mechanism within a template to select a region for each resource, then\n> >> >it\'s obvious you have to write separate templates for each region (and\n> >> >combine them somehow).\n> >> >\n> > The language doesn\'t need to be training wheels for template writers. The\n> \n> Sure it does ;)\n> \n> But seriously, the language should reflect the underlying model.\n> \n\nAnd therein lies the debate, what does Heat model? If part of it is\n\"resources\" then the language needs to be really open to new resources that\nmay do things not conceived of today.\n\n> > language parser should just make it obvious when you\'ve done something\n> > patently impossible. Because cinderclient will only work with a region\n> > at a time, we can make that presumption at that resource level, and flag\n> > the problem during creation before any resources have been allocated.\n> >\n> > But it would be quite presumptuous of Heat, at a language layer, to\n> > say all things are single region.\n> \n> Well, CloudFormation has made that presumption. And while I would \n> *never* suggest that we limit ourselves to features that CloudFormation \n> supports, it behooves us to pause and consider why that might be. (I\'m \n> thinking here of a great many things in Heat, not just this particular \n> one.) Because if we do just charge ahead with every idea, the complexity \n> of the resulting system will be baroque.\n> \n\nIndeed, I am actually most worried about the complexity of solutions that\nwill be built around Heat if we do not define how it models regions or\nif we do not include the inherent isolation a region implies in that\ndefinition.\n\n> > There\'s an entirely good use case\n> > for cross-region volumes and if it is ever implemented that way, and\n> > cinderclient got some multi-region features, we wouldn\'t want users\n> > to be faced with a big rewrite of their templates just to make use of\n> > them. We should just be able to do the cross region thing now, because\n> > we have that capability.\n> \n> This is interesting, because I think of Availability Zones within a \n> Region as \"things that are separated somewhat, but still make sense to \n> be used together sometimes\" and Regions as \"things that don\'t make sense \n> to be used together\". So we have this three-tier system already (local, \n> different AZ, different Region) that cloud providers can use to specify \n> the capabilities of resources, yet we propose to make two of those tiers \n> effectively equivalent? That doesn\'t sound like we are effectively \n> modelling the problem domain.\n> \n> If we accept that distinction between AZs and Regions, then your example \n> is, by definition, not going to happen. Presumably you don\'t accept that \n> definition though, so I\'d be curious to hear what everybody else thinks \n> it means when a cloud provider creates a separate Region.\n> \n\nI see AZ as resources that share _some_ infrastructure (such as a\nkeystone catalog). Regions are completely isolated from one another at\nthe infrastructure level, though they may have eventually-consistent\nshared data (like a username/password db).\n\n> > I dislike the language defining everything and putting users in too\n> > tight of a box. How many times have you been using a DSL and shaken your\n> > fists in the air, \"get out of my way!\"? I would suggest that cross region\n> > support is handled resource by resource.\n> \n> Probably only because I haven\'t used a lot of DSLs but, honestly, I \n> genuinely can\'t ever recall that happening. However, I wish I had a \n> dollar for every time I\'ve tried desperately to get some combination of \n> things that worked individually to work together and ended up having to \n> read the source code to figure out that it wasn\'t supported.\n> \n\nRight, and good early errors and documentation are something I think we\nare not so good at right now.\n\n> >>>> > >>I\'m still convinced that none of this matters if you rely on a single\n> >>>> > >>Heat\n> >>>> > >>in one of the regions. The whole point of multi region is to eliminate\n> >>>> > >>a SPOF.\n> >> >\n> >> >So the idea here would be that you spin up a master template in one\n> >> >region, and this would contain OS::Heat::Stack resources that use\n> >> >python-heatclient to connect to Heat APIs in other regions to spin up\n> >> >the constituent stacks in each region. If a region goes down, even if it\n> >> >is the one with your master template, that\'s no problem because you can\n> >> >still interact with the constituent stacks directly in whatever\n> >> >region(s) you_can_  reach.\n> >> >\n> > Interacting with a nested stack directly would be a very uncomfortable\n> > proposition. How would this affect changes from the master? Would the\n> > master just overwrite any changes I make or refuse to operate?\n> \n> Heat resources (with the exception of a few hacks that are implemented \n> internally *cough*AutoScaling*cough*) are stateless. We only really \n> store the uuid of the target resource.\n> \n> So if you updated the template for the nested stack directly, the Heat \n> engine with the master stack wouldn\'t notice or care. If you deleted it \n> then you should probably delete it from the master stack before you try \n> to do an update that modifies it, but that should go smoothly because \n> Heat ignores NotFound errors when trying to delete resources. We can and \n> probably should improve on that by checking that resources still exist \n> during an update, and recreating them if not.\n> \n\nOh yes please, I actually started on a patch to do exactly that as it\nwould make Heat immensely more robust. This single idea probably deserves\na blueprint.\n\n> Note that this is completely possible now, for all resources that have \n> their own API + nested stacks as well. (Updates after out-of-band \n> changes are actually a much bigger problem for virtually everything \n> _but_ nested stacks, which is one reason I suggested limiting \n> foreign-region resources to only nested stacks, rather than the \n> competing proposal from others in this thread to allow it for all \n> resource types.) This proposal doesn\'t change anything at all in this \n> regard, aside from increasing the chance that you might want to make use \n> of it.\n> \n> >> >So it solves the non-obviousness problem and the single-point-of-failure\n> >> >problem in one fell swoop. The question for me is whether there are\n> >> >legitimate use cases that this would shut out.\n> >> >\n> > With this solution to those problems, you have a new non-obvious problem\n> > which is the split brain I describe above. If master goes down, you have\n> > to play the master\'s role, and when the master returns, does it just\n> > give up because you\'ve tainted its stacks? Do you develop new API commands\n> > to help resolve this? Use merge techniques?\n> \n> Other than the \"replace a deleted resource on update\" thing mentioned \n> above, nothing should be necessary afaict.\n> \n> > I believe that those problems are no less complex than the problem of\n> > how to make Heat engines simply act as peers that need to share data.\n> \n> Looking back over your proposal, you seem to be suggesting more or less \n> the same thing happening under the hood. The only difference I can \n> detect is that I want the structure of the templates to explicitly model \n> how it works, whereas you want to infer from one multi-region template \n> which resources go to each region.\n\nAgreed, we\'re not far off.\n\nHowever, I don\'t want there to be a SPOF. If there is a \"master\" template\nthat just has nested stacks with regions in it somewhere, that is a SPOF.\nIt is a SPOF because it will facilitate the information sharing between\nthe stacks in various regions, and thus is critical to rolling out\nchanges when there is a failure somewhere.\n\nIf the regional Heat engines are peers, and the templates are synchronized\nto the regions that are dictated by the template+params, then when one\nregion goes down, the others still have everything they need to adapt to\nthe problem. The admin can update the original template with a new region\nfor all of the unavailable resources, or just delete them, or create\nnew ones in the surviving region. When the original failed region comes\nback online, it will be left in a state of conflict with the surviving\nregion\'s template, and thus be unable to share data with the surviving\nregion until a resolution can be found by the admin, such as perhaps the\nadmin manually pushing the new template to the previously failed region.\n\nI don\'t find this to be complex. This is fairly standard high availability\nsplit brain handling behavior. However, I need to once again step\nback from the conversation as I don\'t believe I will be working on an\nimplementation any time soon.\n\n\n','<51F6A499.1060109@redhat.com>',NULL),('<1375132931.993723029@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-29 17:22:11',-14400,'2013-07-29 21:22:11',NULL,'[openstack-dev] [Keystone] Reviews needed: Normalize datetimes to\n	account for tz','\nHi,\n\nThere is a patch in review which resolves bug [https://bugs.launchpad.net/python-keystoneclient/+bug/1195924] 1195924 - link [https://review.openstack.org/#/c/35403/] https://review.openstack.org/#/c/35403/.\n \nTo ensure appropriate timezone offsets are considered while checking the token expirations - this fix is Critical. Can reviewers please send in their feedback/+2s to get it moving forward? \n \nthanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130729/89959a03/attachment.html>\n\n',NULL,NULL),('<1375133386.40612024@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-29 17:29:46',-14400,'2013-07-29 21:29:46',NULL,'[openstack-dev] Glance Image List','\nyou could always try using the user as an admin or an admin user itself!\n \nthanks,\n-Nikhil\n\n\n-----Original Message-----\nFrom: \"Jacob Godin\" <jacobgodin at gmail.com>\nSent: Monday, July 29, 2013 5:22pm\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Glance Image List\n\n\n\nHey all,\nDoes anyone know if there is builtin functionality to list images for all tenants? If not, is there a best practice? I\'m using Python APIs.\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130729/0023748a/attachment.html>\n\n','<CA+WiSK6wo25Xfnkq1W9kcCY0JUs2y+mY3KoVf_UXZm12bRR-+A@mail.gmail.com>',NULL),('<1375152918.9244.51.camel@dirk.catalyst.net.nz>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-30 14:55:18',43200,'2013-07-30 02:55:18',NULL,'[Openstack] Inaugral Meeting of the NZ OpenStack Users Group','Hey,\n\nA bunch of us who are working with OpenStack in New Zealand are putting\ntogether a users group. If you\'re working with or on OpenStack, or even\nif you just want to, then we\'d love to hear from you.\n\nThe first meeting is to determine where everyone is at with OpenStack.\nDo you have a 3 node or a 10,000 node cluster[1]? Are you a core\ndeveloper on an OpenStack project, or do you want to be? (Does that\nthought terrify you? That\'s okay as well.)\n\nFrom this initial meeting we\'d like to work out what topic areas are of\ninterest to the larger group, and who is willing to talk about their\nareas of interest.\n\nPractical details:\n\nWhen:     6pm on 26 August\nDuration: Probably an hour and a half\nWebsite:  http://www.meetup.com/New-Zealand-OpenStack-User-Group\nLocation:\n  Level 3\n  Catalyst House \n  150 Willis Street\n  Wellington\n  New Zealand\n\nThe front door of Catalyst House locks at 6pm, there\'ll be a sign on the\ndoor with someones\' phone number on it.\n\nThere\'ll be beer, non-beer and nibbles. [2]\n\nCheers!\n\n[0] This footnote pointed to http://www.openstack.org for non-OpenStack folks\n[1] You don\'t need to have a cluster to come along, that\'s okay, we can\nhelp there as well. \n[2] Thank you to Catalyst IT for sponsoring this event.\n\n-- \nAndrew Ruthven, Wellington, New Zealand\nAt home: andrew at etc.gen.nz |     linux.conf.au 2014 \n                           | Come swan on the Swan River\n                           | http://lca2014.linux.org.au\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130730/2c96b4c0/attachment.pgp>\n\n',NULL,NULL),('<1375161711.44999.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 22:21:51',-25200,'2013-07-30 05:21:51',NULL,'[Openstack] Share your localrc file for devstack','Thank you all for your help.\n\nOn thing I am still not clear on is, do I have to enter IP information for variables like:?\n\nFLOATING_RANGE=\nFIXED_RANGE=\nFIXED_NETWORK_SIZE=\nFLAT_INTERFACE=\n\nMy current localrc file contents looks like:\n-------------------------------------------------\nHOST_IP=10.12.7.25\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=password\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service quantum\nenable_service q-lbaas\n\nenable_service ceilometer ? ? ? ? ??\nenable_service ceilometer-acompute ?\nenable_service ceilometer-acentral ?\nenable_service ceilometer-collector?\nenable_service ceilometer-api?\n-------------------------------------------------\n\n\n\nThanks again for your help!\n\n\n\n________________________________\n From: Dean Troyer <dtroyer at gmail.com>\nTo: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Tuesday, July 30, 2013 1:46 AM\nSubject: Re: [Openstack] Share your localrc file for devstack\n \n\nOn Mon, Jul 29, 2013 at 7:48 AM, Jake G. <Dj_dark_junglist at yahoo.com> wrote:\n> I have a single Ubuntu? host with 2 nics.\n> One nic has a static IP\n> And the other is up but no config.\n>\n> What about flat networking and all that stuff that goes into the localrc\n> file?\n\nSmall steps...make it work with only the static IP NIC first, then try\nto use the second NIC as your VM network (assuming that is what you\nwant).\n\nThe config I posted is a near-equivalent to nova network\'s flat model.\n\ndt\n\n--\n\nDean Troyer\ndtroyer at gmail.com\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/27753820/attachment.html>\n\n','<CAOJFoEv3ZiEaY0F-3WcefutwNu6iroFsF1ehbK4yyaX94PjX0Q@mail.gmail.com>',NULL),('<1375164205.63999.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-29 23:03:25',-25200,'2013-07-30 06:03:25',NULL,'[Openstack] Share your localrc file for devstack','Thank you all for your help.\n\nOn thing I am still not clear on is, do I have to enter IP information for variables like:?\n\nFLOATING_RANGE=\nFIXED_RANGE=\nFIXED_NETWORK_SIZE=\nFLAT_INTERFACE=\n\nMy current localrc file contents looks like:\n-------------------------------------------------\nHOST_IP=10.12.7.25\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=password\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service quantum\nenable_service q-lbaas\n\nenable_service ceilometer ? ? ? ? ??\nenable_service ceilometer-acompute ?\nenable_service ceilometer-acentral ?\nenable_service ceilometer-collector?\nenable_service ceilometer-api?\n-------------------------------------------------\n\n\n\nThanks again for your help!\n\n\n________________________________\n From: Dean Troyer <dtroyer at gmail.com>\nTo: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Tuesday, July 30, 2013 1:46 AM\nSubject: Re: [Openstack] Share your localrc file for devstack\n \n\nOn Mon, Jul 29, 2013 at 7:48 AM, Jake G. <Dj_dark_junglist at yahoo.com> wrote:\n> I have a single Ubuntu? host with 2 nics.\n> One nic has a static IP\n> And the other is up but no config.\n>\n> What about flat networking and all that stuff that goes into the localrc\n> file?\n\nSmall steps...make it work with only the static IP NIC first, then try\nto use the second NIC as your VM network (assuming that is what you\nwant).\n\nThe config I posted is a near-equivalent to nova network\'s flat model.\n\ndt\n\n--\n\nDean Troyer\ndtroyer at gmail.com\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130729/7aba8cb5/attachment.html>\n\n','<CAOJFoEv3ZiEaY0F-3WcefutwNu6iroFsF1ehbK4yyaX94PjX0Q@mail.gmail.com>',NULL),('<1375172963.86174.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-30 01:29:23',-25200,'2013-07-30 08:29:23',NULL,'[Openstack] Prevent Devstack from creating demo project.','Hi All!\n\nWondering if there is a way to prevent devstack from creating a demo project and just leave the admin project as the default project?\n\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130730/c4832683/attachment.html>\n\n',NULL,NULL),('<1375237847.27539.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-30 19:30:47',-25200,'2013-07-31 02:30:47',NULL,'[Openstack] Share your localrc file for devstack','Thank you all for your help.\n\n\n\nOn thing I am still not clear on is, do I have to enter IP information for variables like:?\n\nFLOATING_RANGE=\nFIXED_RANGE=\nFIXED_NETWORK_SIZE=\nFLAT_INTERFACE=\n\nMy current localrc file contents looks like:\n-------------------------------------------------\nHOST_IP=10.12.7.25 ? <-------------------------------This is my eth0 NIC>\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=password\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service quantum\nenable_service q-lbaas\n\nenable_service ceilometer ? ? ? ? ??\nenable_service ceilometer-acompute ?\nenable_service ceilometer-acentral ?\nenable_service ceilometer-collector?\nenable_service ceilometer-api?\n-------------------------------------------------\n\n\n\nThanks again for your help!\n\n\n________________________________\n From: Dean Troyer <dtroyer at gmail.com>\nTo: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Tuesday, July 30, 2013 1:46 AM\nSubject: Re: [Openstack] Share your localrc file for devstack\n \n\nOn Mon, Jul 29, 2013 at 7:48 AM, Jake G. <Dj_dark_junglist at yahoo.com> wrote:\n> I have a single Ubuntu? host with 2 nics.\n> One nic has a static IP\n> And the other is up but no config.\n>\n> What about flat networking and all that stuff that goes into the localrc\n> file?\n\nSmall steps...make it work with only the static IP NIC first, then try\nto use the second NIC as your VM network (assuming that is what you\nwant).\n\nThe config I posted is a near-equivalent to nova network\'s flat model.\n\ndt\n\n--\n\nDean Troyer\ndtroyer at gmail.com\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130730/9cf64d59/attachment.html>\n\n','<1375164205.63999.YahooMailNeo@web163003.mail.bf1.yahoo.com>',NULL),('<1375252826.58344.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-30 23:40:26',-25200,'2013-07-31 06:40:26',NULL,'[Openstack] Prevent Devstack from creating demo project.','I noticed that networking is half configured for demo and half for admin.\nAnyone know why this is and is it possible to prevent this?\nI tried commenting out the demo user in the code but then I am left with the half of the networking that is created for admin only.\n\nThanks\n\n\n\n\n________________________________\n From: Ruslan Kamaldinov <rkamaldinov at mirantis.com>\nTo: Shake Chen <shake.chen at gmail.com> \nCc: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Wednesday, July 31, 2013 3:34 PM\nSubject: Re: [Openstack] Prevent Devstack from creating demo project.\n \n\nYou can add the following line to your local.sh file:\nkeystone tenant-delete demo\n\n\nlocal.sh is executed automatically at the successful conclusion of stack.sh.\nIt\'ll take care of demo project.\n\n\nOn Tue, Jul 30, 2013 at 7:40 PM, Shake Chen <shake.chen at gmail.com> wrote:\n> I also have same question. The demo project make user confuse.\n>\n>\n> On Tue, Jul 30, 2013 at 4:29 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>\n>> Hi All!\n>>\n>> Wondering if there is a way to prevent devstack from creating a demo\n>> project and just leave the admin project as the default project?\n>>\n>> Thanks!\n>>\n>> _______________________________________________\n>> Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ?  : openstack at lists.openstack.org\n>> Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n>\n> --\n> Shake Chen\n>\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to? ?  : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130730/78bbd0a8/attachment.html>\n\n','<CAPW-O+EccDuW5SyOekRinmpKQqh=f56ay96rmpRwG3h8dmc4fQ@mail.gmail.com>',NULL),('<1375253993.29965.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-30 23:59:53',-25200,'2013-07-31 06:59:53',NULL,'[Openstack] Explaintion needed for localrc file','Could someone please explain what the below are and how it relates to the openstack host network`s Network settings (eg. eth0 and eth1)\n\n# network\nFLAT_INTERFACE=eth0\nFIXED_RANGE=10.0.0.0/20\nNETWORK_GATEWAY=10.0.0.1\nFLOATING_RANGE=192.168.174.1/24\nEXT_GW_IP=192.168.174.1\n\nThank you!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130730/24a60ed1/attachment.html>\n\n',NULL,NULL),('<1375266770.5.1376633809729.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-16 06:16:49',0,'2013-08-16 06:16:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #6','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/6/>\n\n------------------------------------------\n[...truncated 3737 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 331.01 secs:\n    152.72    KcMasterTestCase.test_admin_requires_adminness\n    82.96    KcEssex3TestCase.test_admin_requires_adminness\n    80.81    Kc11TestCase.test_admin_requires_adminness\n    7.49    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    7.03    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1300 tests in 807.185s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.7\nargparse==1.2.1\nastroid==1.0.0\nbeautifulsoup4==4.3.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.11\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.6.1\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.6\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==1.0.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.6\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.hP2TPRmNzO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-7/6\n[SCP] Copying console log.\n\n\n','<1502344485.1.1376547367746.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1375284990.23490.170.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-31 11:36:30',-14400,'2013-07-31 15:36:30',NULL,'[Openstack-docs] Use of XML xi:include with xpointer','XInclude doesn\'t let you add child elements to the included element,\nbut you can include multiple elements with XInclude, just not with\nthe element() scheme. The xpointer() scheme allows you to use XPath,\nso you can put something at the end by manually duplicating the\nsection element, then including the child content of the target\nsection element:\n\n<section id=\"some_id\">\n  <xi:include href=\"some_file.xml\"\n             xpointer=\"xpointer(id(\'some_id\')/*)\"/>\n  <para>Something at the end</para>\n</section>\n\nIt\'s more complicated to put something at the beginning, because\nyou have to account for things like title and info elements. Not\naccounting for titleabbrev and subtitle:\n\n<section id=\"some_id\">\n  <xi:include href=\"some_file.xml\"\n             xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n                       xpointer(id(\'some_id\')/db:title)\">\n    <xi:fallback/>\n  </xi:include>\n  <xi:include href=\"some_file.xml\"\n             xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n                       xpointer(id(\'some_id\')/db:info)\">\n    <xi:fallback/>\n  </xi:include>\n  <para>Something at the beginning</para>\n  <xi:include href=\"some_file.xml\"\n             xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n                       xpointer(id(\'some_id\')/*\n                       [not(self::db:title or self::db:info)]\n                       )\"/>\n  <para>Something at the end</para>\n</section>\n\nKind of messy, but still more long-term maintainable than manually\nincluding each child element of the target section.\n\nI wrote a howto on XInclude a couple years back, which you might\nfind useful:\n\nhttp://blogs.gnome.org/shaunm/2011/07/21/understanding-xinclude/\n\n--\nShaun\n\nOn Wed, 2013-07-31 at 02:41 +0000, Sean Roberts wrote:\n> Both actually. I want to place a submit bug link at the end of each\n> section. Also want to add some text at the beginning for many of the\n> included sections describing training objectives. \n> \n> \n> I\'d also be interested in ideas on using xslt to rip and replace tags.\n> But that probably can wait a little bit. \n> \n> ~sean\n> \n> On Jul 30, 2013, at 9:18, \"Anne Gentle\"\n> <annegentle at justwriteclick.com> wrote:\n> \n> \n> > Hi Sean, \n> > Do you want some sort of \"glue text\" so that the guide can be read\n> > in a linear way? Or is it text that you\'ll use over and over, such\n> > as \"Now go take the test.\" Let us know what you\'re trying to do. \n> > \n> > \n> > You can\'t really strip a tag at a time without XSLT (the transform\n> > code that lives in the Maven plugin).\n> > Anne\n> > \n> > \n> > On Tue, Jul 30, 2013 at 9:19 AM, Sean Roberts\n> > <seanrob at yahoo-inc.com> wrote:\n> >         Ideas on how to add text to the included section or final\n> >         page? Part of the problem may be from that I\'m stuck using\n> >         the chapter or section of the original XML. If I could\n> >         include, strip the section tags, then I could add text no\n> >         problem. \n> >         \n> >         ~sean\n> >         \n> >         On Jul 30, 2013, at 6:54, \"Anne Gentle\"\n> >         <annegentle at justwriteclick.com> wrote:\n> >         \n> >         \n> >         > I think DocBook sees the markup as a closed section\n> >         > followed by a para whic is invalid.\n> >         > \n> >         > Anne Gentle \n> >         > Content Stacker\n> >         > anne at openstack.org\n> >         > \n> >         > \n> >         > \n> >         > On Jul 30, 2013, at 8:38 AM, Sean Roberts\n> >         > <seanrob at yahoo-inc.com> wrote:\n> >         > \n> >         > \n> >         > > I am pulling in a section through <xi:include\n> >         > > href=\"http.....xpointer=\"element(foobar)\"></xi:include>\n> >         > > If I want to use additional text, I\'m forced to make it\n> >         > > a section as well. I want to add text to the beginning\n> >         > > or end of the the included section. \n> >         > > I tried <xi:include\n> >         > > href=\"http.....xpointer=\"element(foobar)\"><para>blah\n> >         > > blah</para></xi:include>\n> >         > > , which shows up without error in oxygen, but maven\n> >         > > seems to strip it out during HTML build. \n> >         > > \n> >         > > ~sean\n> >         > > \n> >         > > On Jul 30, 2013, at 6:24, \"Anne Gentle\"\n> >         > > <annegentle at justwriteclick.com> wrote:\n> >         > > \n> >         > > \n> >         > > > Hi Sean,  \n> >         > > > Post your XML code so we can take a closer look, or a\n> >         > > > link to the patch and the file name so we can look at\n> >         > > > it. \n> >         > > > Thanks!\n> >         > > > Anne\n> >         > > > \n> >         > > > \n> >         > > > On Tue, Jul 30, 2013 at 2:56 AM, Sean Roberts\n> >         > > > <seanrob at yahoo-inc.com> wrote:\n> >         > > >         I have another question. I\'m bringing in the\n> >         > > >         sections which is the smallest page into the\n> >         > > >         built HTML. I\'m trying to add text and links\n> >         > > >         within the final HTML page without success.\n> >         > > >         Oxygen shows the link and text fine, but the\n> >         > > >         maven built site only has the included\n> >         > > >         section. Perhaps some adjustment within the\n> >         > > >         pom file...\n> >         > > >         \n> >         > > >         ~sean\n> >         > > >         \n> >         > > >         On Jul 29, 2013, at 9:34, \"Diane Fleming\"\n> >         > > >         <diane.fleming at rackspace.com> wrote:\n> >         > > >         \n> >         > > >         \n> >         > > >         > I don\'t know if this will work, but this is\n> >         > > >         how I used xpointer to pull in\n> >         > > >         > content from one file to another:\n> >         > > >         >\n> >         > > >         >\n> >         > > >         > Target file (pulls in content)\n> >         > > >         >\n> >         > > >         > <title>Overview</title>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over1)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over2)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over3)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over4)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over5)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over6)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over7)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over8)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over9)\"/>\n> >         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >         > > >         >                xpointer=\"element(over10)\"/>\n> >         > > >         > <xi:include href=\"section_virt_ext.xml\"/>\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >\n> >         > > >         > Source file\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >    <title>Overview</title>\n> >         > > >         >    <section\n> >         > > >         xml:id=\"cn_overview\"><title>Cloud\n> >         > > >         Networks</title>\n> >         > > >         >    <para xml:id=\"over1\">Cloud Networks lets\n> >         > > >         you create a virtual\n> >         > > >         >        Layer 2 network, known as an isolated\n> >         > > >         network, which gives you\n> >         > > >         >        greater control and security when you\n> >         > > >         deploy web applications.\n> >         > > >         > </para>\n> >         > > >         >    <para xml:id=\"over2\">When you create a\n> >         > > >         next generation Cloud\n> >         > > >         >        Server, Cloud Networks enables you to\n> >         > > >         attach one or more\n> >         > > >         >        networks to your server. You can\n> >         > > >         attach an isolated network\n> >         > > >         >        that you have created or a Rackspace\n> >         > > >         network. </para>\n> >         > > >         >    <para xml:id=\"over3\">If you install the\n> >         > > >         &virt_ext;, you can create\n> >         > > >         >        a virtual interface to a specified\n> >         > > >         Rackspace or isolated\n> >         > > >         >        network and attach that network to an\n> >         > > >         existing server\n> >         > > >         >        instance. You can also list virtual\n> >         > > >         interfaces for and delete\n> >         > > >         >        virtual interfaces from a server\n> >         > > >         instance. For information\n> >         > > >         >        about the &virt_ext;, see <xref\n> >         > > >         linkend=\"section_virt_ext\"\n> >         > > >         >        />.</para>\n> >         > > >         >\n> >         > > >         >\n> >         > > >         > etc.\n> >         > > >         >\n> >         > > >         >\n> >         > > >         > Diane\n> >         > > >         >\n> >         > > >         >\n> >         > > >         ----------------------------------------------\n> >         > > >         > Diane Fleming\n> >         > > >         > Software Developer II - US\n> >         > > >         >\n> >         > > >         > diane.fleming at rackspace.com\n> >         > > >         > Cell  512.323.6799\n> >         > > >         > Office 512.874.1260\n> >         > > >         > Skype drfleming0227\n> >         > > >         > Google-plus diane.fleming at gmail.com\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >\n> >         > > >         >\n> >         > > >         > On 7/29/13 9:27 AM, \"Sean Roberts\"\n> >         > > >         <seanrob at yahoo-inc.com> wrote:\n> >         > > >         >\n> >         > > >         >> I\'m working on reusing content from remote\n> >         > > >         XML formatted sources to\n> >         > > >         >> create new content. I\'m using xi:include\n> >         > > >         xpointer to a section of an\n> >         > > >         >> existing XML file. Using the editor oxygen\n> >         > > >         I can see the remote content,\n> >         > > >         >> so I know my href is valid. But maven fails\n> >         > > >         to build the html from the\n> >         > > >         >> xml returning bad pointer.\n> >         > > >         >>\n> >         > > >         >> The remote content isn\'t using DTD or\n> >         > > >         XMLschema. I\'m hoping I can figure\n> >         > > >         >> out how to walk the structure without\n> >         > > >         having to.\n> >         > > >         >> Any XML peoples that can help?\n> >         > > >         >>\n> >         > > >         >> ~sean\n> >         > > >         >>\n> >         > > >         _______________________________________________\n> >         > > >         >> Openstack-docs mailing list\n> >         > > >         >> Openstack-docs at lists.openstack.org\n> >         > > >         >>\n> >         > > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >         > > >         >\n> >         > > >         >\n> >         > > >         \n> >         > > >         _______________________________________________\n> >         > > >         Openstack-docs mailing list\n> >         > > >         Openstack-docs at lists.openstack.org\n> >         > > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >         > > >         \n> >         > > > \n> >         > > > \n> >         > > > \n> >         > > > \n> >         > > > -- \n> >         > > > Anne Gentle\n> >         > > > annegentle at justwriteclick.com\n> > \n> > \n> > \n> > \n> > -- \n> > Anne Gentle\n> > annegentle at justwriteclick.com\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<BF351DE2-BFCE-4B9A-B2F4-E55ED82AA379@yahoo-inc.com>',NULL),('<1375308624.2383.337.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-31 23:10:24',3600,'2013-07-31 22:10:24',NULL,'[openstack-dev] [Nova] Proposal to add Nikola Đipanov to nova-core','On Wed, 2013-07-31 at 15:10 -0400, Russell Bryant wrote:\n> Greetings,\n> \n> I propose that we add Nikola ?ipanov to the nova-core team [1].\n> \n> Nikola has been actively contributing to nova for a while now, both in\n> code and reviews.  He provides high quality reviews. so I think he would\n> make a good addition to the review team.\n> \n>     https://review.openstack.org/#/q/reviewer:ndipanov at redhat.com,n,z\n> \n>     https://review.openstack.org/#/q/owner:ndipanov at redhat.com,n,z\n> \n> Please respond with +1/-1.\n\n+1, I like Nikola\'s reviews\n\nMark.\n\n\n\n','<51F96114.5050402@redhat.com>',NULL),('<1375324725.63144.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-07-31 19:38:45',-25200,'2013-08-01 02:38:45',NULL,'[Openstack] Explaintion needed for localrc file','Thank you very much for this.?Helped a lot\n\nOne question.\n\nFLOATING_RANGE= (range not used on the local network), could you explain a little bit more? \nSay my host has the IP of 192.168.100.25 on eth0.\nDoes this mean I should use something different than 192.168.100.0/24? \n\nThanks\n\n\n________________________________\n From: Salvatore Orlando <sorlando at nicira.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, August 1, 2013 6:38 AM\nSubject: Re: [Openstack] Explaintion needed for localrc file\n \n\n\nHi Jake,\n\nmost of the info here have been shamelessly copied from?http://devstack.org/guides/single-machine.html\nIn general devstack.org has plenty of information to understand how it deploys openstack and troubleshoot issues.\n\nSalvatore\n\n\n\n\nOn 31 July 2013 08:59, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nCould someone please explain what the below are and how it relates to the openstack host network`s Network settings (eg. eth0 and eth1)\n>\n>\n># network\n>FLAT_INTERFACE=eth0\n\nEthernet interface that connects the host to your local network. This is the interface that should be configured with the static IP?\n?\nFIXED_RANGE=10.0.0.0/20\n\nconfigure the internal address space used by the instances?\nNETWORK_GATEWAY=10.0.0.1\n\nUsed by neutron to configure internal subnet\'s default gateway.\n?\nFLOATING_RANGE=192.168.174.1/24\n\nShould be configured?to a range not used on the local network, i.e. 192.168.1.224/27. This configures IP addresses ending in 225-254 to be used as floating IPs.\n?\nEXT_GW_IP=192.168.174.1\n\nNot sure where it is used. ?(Neutron uses a variable called PUBLIC_NETWORK_GATEWAY for a very similar purpose)\n\n>\n>Thank you!\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130731/9762a117/attachment.html>\n\n','<CAGR=i3gxY3bM-DGpDk-Lr_W0N+0GAQ_MdYt_gyU8K9-RsO2V7A@mail.gmail.com>',NULL),('<1375347333.38193.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 16:55:33',28800,'2013-08-01 08:55:33',NULL,'[Openstack] How does host sends it\'s information to nova scheduler?','Hi,\n\nI have been trying to find out how does nova scheduler gets the?\ninformation from the hosts. I understand that there is a file named\nhost_manager.py that is responsible for polling each host present in?\nnova.db and retrieve it\'s information. But what I want to know is how?\neach host sends it\'s information and from where?\n\nP.S.: I have installed openstack using devstack on Ubuntu 12.04\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/fb959e8d/attachment.html>\n\n',NULL,NULL),('<1375349657.42660.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 02:34:17',-25200,'2013-08-01 09:34:17',NULL,'[Openstack] Full list of options for devstack localrc file','I am trying to find a full list of devstack localrc options especially for configuring neutron/quantum networking part.\n\nThanks for you help!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/9f3489db/attachment.html>\n\n',NULL,NULL),('<1375351103.2383.349.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-01 10:58:23',3600,'2013-08-01 09:58:23',NULL,'[openstack-dev] Program Proposal: Release cycle management','On Thu, 2013-08-01 at 11:39 +0200, Thierry Carrez wrote:\n> Following past discussions[1] on the TC, here is my proposal to cover\n> for release management, stable branch management and VMT efforts within\n> OpenStack.\n> \n> Feel free to suggest title or wording changes :)\n> \n> \"\"\"\n> Official Title: Release cycle management\n> PTL: Thierry Carrez\n> \n> Mission Statement:\n> To organize the release cycle and the work necessary to produce\n> time-based, coordinated releases of the integrated components of\n> OpenStack. To collect bugfix backports and produce stable point releases\n> for the previously-released branch. To coordinate the publication of\n> security patches and advisories (OSSA) for security-supported branches.\n> \n> Expected deliverables:\n> Signed release tarballs, security advisories, release tooling and automation\n> \n> Team members:\n> Members of the Release Managers team, the stable-maint team and the\n> Vulnerability Management team. (Note: All members must become ATCs\n> through direct contribution to other supported OpenStack repositories)\n> \"\"\"\n\nSounds pretty spot on to me.\n\nYou could go into more details and mention producing the release\nschedule, running project meetings, milestone releases, stable branch\nreleases, etc. etc. but it\'s just all details implicit in the mission\nabove.\n\nCheers,\nMark.\n\n\n\n','<51FA2CD3.9020509@openstack.org>',NULL),('<1375351332.2383.352.camel@sorcha>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 11:02:12',3600,'2013-08-01 10:02:12',NULL,'[Openstack] [openstack-dev]  Ceilometer and notifications','On Thu, 2013-08-01 at 10:36 +0200, Julien Danjou wrote:\n> On Thu, Aug 01 2013, Sam Morrison wrote:\n> \n> > OK so is it that ceilometer just leaves the message on the queue or\n> > only consumes certain messages?\n> \n> Ceilometer uses its own queue. There might be other processes consuming\n> this notifications, so removing them may be not a good idea.\n> \n> The problem may be that the notification sender create a queue by\n> default even if there\'s no consumer on that. Maybe that\'s something we\n> should avoid doing in Oslo (Cc\'ing -dev to get advice on that).\n\nI\'m missing the context here, but it sounds like the default\nnotifications queue created isn\'t the one consumed by ceilometer so it\nfills up and we just shouldn\'t be creating that queue.\n\nSounds reasonable to me. Definitely file a bug for it.\n\nCheers,\nMark.\n\n\n\n','<87wqo5959b.fsf@dex.adm.naquadah.org>',NULL),('<1375351332.2383.352.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-01 11:02:12',3600,'2013-08-01 10:02:12',NULL,'[openstack-dev] [Openstack] Ceilometer and notifications','On Thu, 2013-08-01 at 10:36 +0200, Julien Danjou wrote:\n> On Thu, Aug 01 2013, Sam Morrison wrote:\n> \n> > OK so is it that ceilometer just leaves the message on the queue or\n> > only consumes certain messages?\n> \n> Ceilometer uses its own queue. There might be other processes consuming\n> this notifications, so removing them may be not a good idea.\n> \n> The problem may be that the notification sender create a queue by\n> default even if there\'s no consumer on that. Maybe that\'s something we\n> should avoid doing in Oslo (Cc\'ing -dev to get advice on that).\n\nI\'m missing the context here, but it sounds like the default\nnotifications queue created isn\'t the one consumed by ceilometer so it\nfills up and we just shouldn\'t be creating that queue.\n\nSounds reasonable to me. Definitely file a bug for it.\n\nCheers,\nMark.\n\n\n\n','<87wqo5959b.fsf@dex.adm.naquadah.org>',NULL),('<1375352167.10318.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 03:16:07',-25200,'2013-08-01 10:16:07',NULL,'[Openstack] Full list of options for devstack localrc file','I saw that but it does not say how to setup IP ranges and what not.\n\nFor public gateway, floating ips, private ips, private gateway, etc\n\n\n\n\n\n\n________________________________\n From: Sunil Thaha <sunil.thaha at gmail.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, August 1, 2013 7:11 PM\nSubject: Re: [Openstack] Full list of options for devstack localrc file\n \n\nThis wiki https://wiki.openstack.org/wiki/NeutronDevstack has the\ndetails for configuring neutron.\n\n--\nS\n\nOn Thu, Aug 1, 2013 at 7:34 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n> I am trying to find a full list of devstack localrc options especially for\n> configuring neutron/quantum networking part.\n>\n> Thanks for you help!\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to? ?  : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/11d3f8da/attachment.html>\n\n','<CA+67yafotW6kvEzQfp-Lnj-T9zOoxB5O22s8bArpbtzu0=AzqQ@mail.gmail.com>',NULL),('<1375352187.46216.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 18:16:27',28800,'2013-08-01 10:16:27',NULL,'[Openstack] How does host sends it\'s information to nova\n	scheduler?','Hi Lau,\n\nThank you. That\'s what I was looking for.\n\nThanks\n?\n~Peeyush Gupta\n\n\n________________________________\n From: Jay Lau <jay.lau.513 at gmail.com>\nTo: Peeyush Gupta <gpeeyush at ymail.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, 1 August 2013 3:34 PM\nSubject: Re: [Openstack] How does host sends it\'s information to nova scheduler?\n \n\n\nSorry, forget the attachment.\n\nThanks,\n\nJay\n\n\n\n\n2013/8/1 Jay Lau <jay.lau.513 at gmail.com>\n\nHi Peeyush, \n>\n>Please refer to attached diagram as the report process, but this logic is going to be removed in hanva-3, refer to https://blueprints.launchpad.net/nova/+spec/no-compute-fanout-to-scheduler for detail.\n>\n>Thanks, \n>\n>Jay\n>\n>\n>\n>\n>\n>\n>\n>2013/8/1 Peeyush Gupta <gpeeyush at ymail.com>\n>\n>Hi,\n>>\n>>\n>>I have been trying to find out how does nova scheduler gets the?\n>>information from the hosts. I understand that there is a file named\n>>host_manager.py that is responsible for polling each host present in?\n>>nova.db and retrieve it\'s information. But what I want to know is how?\n>>each host sends it\'s information and from where?\n>>\n>>\n>>P.S.: I have installed openstack using devstack on Ubuntu 12.04\n>>\n>>\n>>Thanks.?\n>>~Peeyush Gupta\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/c3ff366f/attachment.html>\n\n','<CAFyztAGQcvQik37Jri9-aeyzJLZOhQUPe63zT5Uh0h1KK5KMsg@mail.gmail.com>',NULL),('<1375352934.6862.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 03:28:54',-25200,'2013-08-01 10:28:54',NULL,'[Openstack] Devstack grizzly networking help!!!!!!!!!!! please','Please i need help here. I am dying, about to kill my PC and give up on openstack......soo frustrated!!!\n\nAllinone Devstack grizzly deployment here, but I cannot get the networking right no matter how I configure it.\n\n\nMy Physical Host NIC settings are:\n-----------------------------------------\nauto eth0\niface eth0 inet static\n? ? ? ? address 192.168.100.24\n? ? ? ? netmask 255.255.255.0\n? ? ? ? network 192.168.100.0\n? ? ? ? broadcast 192.168.100.255\n? ? ? ? gateway 192.168.100.254\n\n#Secondary network\nauto eth1\n? ? ? ? iface eth1 inet manual\n? ? ? ? up ifconfig $IFACE 0.0.0.0 up\n? ? ? ? up ip link set $IFACE promisc on\n? ? ? ? down ip link set $IFACE promisc off\n? ? ? ? down ifconfig $IFACE down\n------------------------------------------\n\nWhat should my localrc file correctly look like? I really dont understand this. Should the floating IPs be on the same subnet as my host IP?\nfor example, HOST_IP=192.168.100.24/24 ? ? ? FLOATING_RANGE=192.168.100.0/24\n\nif I dont configure any ips ranges then I always get a 172. IP for my public network and cannot get internet to my instances.\n\nThank you for your help\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/da167331/attachment-0001.html>\n\n',NULL,NULL),('<1375421877.46306.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-01 22:37:57',-25200,'2013-08-02 05:37:57',NULL,'[Openstack]  Devstack Grizzly networking help needed','HI all, Another day of failed attempts to get this right. Would appreciate any help you can give.?Its been almost 3 weeks and I haven\'t been able to get past this point.\n\n\nI have an All-in-one Devstack grizzly deployment here, but I cannot get the networking right no matter how I configure it.\n\n\nMy Physical Host NIC settings are:\n-----------------------------------------\nauto eth0\niface eth0 inet static\n? ? ? ? address 192.168.100.24\n? ? ? ? netmask 255.255.255.0\n? ? ? ? network 192.168.100.0\n? ? ? ? broadcast 192.168.100.255\n? ? ? ? gateway 192.168.100.254\n\n#Secondary network not connected to anything(cable not plugged in)\nauto eth1\n? ? ? ? iface eth1 inet manual\n? ? ? ? up ifconfig $IFACE 0.0.0.0 up\n? ? ? ? up ip link set $IFACE promisc on\n? ? ? ? down ip link set $IFACE promisc off\n? ? ? ? down ifconfig $IFACE down\n------------------------------------------\n\nWhat should my localrc file correctly look like? I really dont understand this. Should the floating IPs be on the same subnet as my host IP?\nfor example, HOST_IP=192.168.100.24/24 with the GW 192.168.100.254 ? ? ? FLOATING_RANGE=192.168.100.0/24\n\nif I dont configure any ips ranges then I always get a 172. IP for my public network and my instances do not get a IP from DHCP services.\n\nThank you for your help\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130801/5ead0d60/attachment.html>\n\n','<1375352934.6862.YahooMailNeo@web163003.mail.bf1.yahoo.com>',NULL),('<1375427958.29593.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-02 00:19:18',-25200,'2013-08-02 07:19:18',NULL,'[Openstack] Devstack Grizzly networking help needed','HI Salvatore,?\n\nThank you for your reply and sorry for being a pain in the butt.?\nWhat I really need help with is the initial setup in the localrc file. I dont really understand how each piece works.\n\nThe internal network can be any ip range and gateway, but I do not understand the public network part.\n\nDoes the floating range have to match the subnet that my eth0 ip is on?\nif I specify the floating range to 192.168.100.0/24 devstack still gives me a gateway starting 172.x.x.x that is configured in br-ex interface\n\nDoes it not matter what the floating range ips are?\n\nThis is my localrc file. Can you tell me where I am going wrong first before we get into the serious troubleshooting? Thank you soo much!\n\n-------------------------------\n\nHOST_IP=192.168.100.24\n\n#network\nFLAT_INTERFACE=eth0\nFIXED_RANGE=10.0.0.0/24\nNETWORK_GATEWAY=10.0.0.1\nFLOATING_RANGE=192.168.100.0/24\n?\n\nADMIN_PASSWORD=VMDa53K1g\nMYSQL_PASSWORD=VMDa53K1g\nRABBIT_PASSWORD=VMDa53K1g\nSERVICE_PASSWORD=VMDa53K1g\nSERVICE_TOKEN=VMDa53K1g\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service quantum\nenable_service q-lbaas\n\n?\n\n\n\n\n________________________________\n From: Salvatore Orlando <sorlando at nicira.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Friday, August 2, 2013 3:51 PM\nSubject: Re: [Openstack] Devstack Grizzly networking help needed\n \n\n\nThe fact that you do not get addresses from the dhcp server has little to do with the floating IP range, and getting a 172.x.x.x network when no range is specified is the default behaviour.\nIf you refer to \'public network\' to the one where you\'re going to create floating IPs, then usually addresses are not distributed by DHCP there.\n\nThe fact that you do not get DHCP addresses on the private network, on a simple setup like the single-host one, might mean we need to look at failures in openstack services rather than devstack configuration issues.\n\nI assume that you\'re using neutron (this is what I recall from your previous posts), and that the following servcies are running in devstack (check if they crashed too!).\n1) quantum-server\n2) quantum-agent\n3) quantum-dhcp-agent\n4) quantum-l3-agent\n5) quantum-meta\n\n1) Check the NICs on your instance; if you don\'t find any then perhaps the interface driver in nova is not working - set NOVA_VIF_DRIVER to?nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver in your localrc (this should be the default value anyway) - or go to nova.conf and set libvirt_vif_driver to the above value\n2) If the NICs are present, verify they\'re being plugged into br-int. Otherwise either check again nova\'s libvirt_vif_driver, or check if you have br-int at all! If you don\'t then probably openvswitch-switch is not running and this is likely to be your issue\n3) If all the interfaces are up and running, we should focus on why DHCP traffic is being dropped. One reason might be the DHCP agent is not responding at all. Verify that you do not have errors in the DHCP agent log\n4) If none of the above bullets helps you, then you can try and boot to vms and give them manually the address neutron selected for them, and then see if you have connectivity. Then we will be able to say whether we need to look at a DHCP problem or a general connectivity issue.\n\nSalvatore\n\n\n\nOn 2 August 2013 07:37, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nHI all, Another day of failed attempts to get this right. Would appreciate any help you can give.?Its been almost 3 weeks and I haven\'t been able to get past this point.\n>\n>\n>I have an All-in-one Devstack grizzly deployment here, but I cannot get the networking right no matter how I configure it.\n>\n>\n>\n>\n>My Physical Host NIC settings are:\n>-----------------------------------------\n>auto eth0\n>iface eth0 inet static\n>? ? ? ? address 192.168.100.24\n>? ? ? ? netmask 255.255.255.0\n>? ? ? ? network 192.168.100.0\n>? ? ? ? broadcast 192.168.100.255\n>? ? ? ? gateway 192.168.100.254\n>\n>\n>#Secondary network not connected to anything(cable not plugged in)\n>auto eth1\n>? ? ? ? iface eth1 inet manual\n>? ? ? ? up ifconfig $IFACE 0.0.0.0 up\n>? ? ? ? up ip link set $IFACE promisc on\n>? ? ? ? down ip link set $IFACE promisc off\n>? ? ? ? down ifconfig $IFACE down\n>------------------------------------------\n>\n>\n>What should my localrc file correctly look like? I really dont understand this. Should the floating IPs be on the same subnet as my host IP?\n>for example, HOST_IP=192.168.100.24/24 with the GW 192.168.100.254 ? ? ? FLOATING_RANGE=192.168.100.0/24\n>\n>\n>if I dont configure any ips ranges then I always get a 172. IP for my public network and my instances do not get a IP from DHCP services.\n>\n>\n>Thank you for your help\n>\n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130802/778d784e/attachment.html>\n\n','<CAGR=i3ixwK7NnKAD6JLQZcQLTPuz7dVSOsUzJCT3YAy_ynVYRA@mail.gmail.com>',NULL),('<1375433052.3736.107.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 10:44:12',7200,'2013-08-02 08:44:12',NULL,'[openstack-dev] [Stackalytics] 0.1 release [metrics]','On Fri, 2013-07-26 at 07:40 -0700, Thierry Carrez wrote:\n> Stefano Maffulli wrote:\n> > On 07/23/2013 07:25 AM, Roman Prykhodchenko wrote:\n> >> I still think counting lines of code is evil because it might encourage\n> >> some developers to write longer code just for statistics.\n> > \n> > Data becomes evil when you decide to use them for evil purposes :) I\n> > don\'t think that lines of code is a bad metric per se: like any other\n> > metric it becomes bad when used in an evile context. I\'m getting more\n> > and more convinced that it\'s a mistake to show ranks and classifications\n> > in the dashboard and I\'ll be deleting all the ones that we may have on\n> > http://activity.openstack.org. (see\n> > https://bugs.launchpad.net/openstack-community/+bug/1205139)\n> > \n> > Counting anything in OpenStack, from commits to number of reviews is not\n> > a race, we don\'t need to *rank* top contributors.\n> \n> While I think those stats are useless to identify \"top\" contributors\n> (since the precise metric used will influence who ends up in the top\n> spots), I think they are useful to identify who does not contribute at\n> all. In that case 0 commits = 0 lines of code = 0 reviews and the metric\n> used does not matter that much.\n> \n> You could say we should not be in the business of shaming people, but\n> remember that since we use a permissive license, societal pressures\n> (rather than institutional pressures like the license) are the only way\n> to force companies to contribute back. The Apache license lets you not\n> contribute back, but that doesn\'t mean companies who claim to be an\n> OpenStack open source team player can get away with not contributing\n> anything at all...\n\nI would say that the important issue is to have the detailed data. If\nfor some person (or company) it is important to count lines of code, or\ncommits, or closed tickets, or whatever, you can go for it and that\'s\nall. Data is just data: you can mine it for the answers to your own\nquestions.\n\nThis said, I also agree with Thierry in that \"highlighting\" important\naspects for the project can only help. That can be used to put some\n\"social pressure\" on users of the software, as he suggests. That may\nalso be used to highlight who is contributing the most (as Stefano said,\nit may be useful to know which companies are engaging more with the\nproject, and in some cases that\'s clear by almost any metric. Or to\ntrack the time-to-review per project. Or to show open tickets over time.\n\nMy impression is that we still need some time to learn which metrics are\ninteresting enough to visualize them. And contribution metrics are a\npart of them.\n\nSaludos,\n\n	Jesus.\n\n\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<51F28A50.4020706@openstack.org>',NULL),('<1375435930.49849.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-02 17:32:10',28800,'2013-08-02 09:32:10',NULL,'[Openstack] Which filter is based on CPUs availability?','Hi,\n\nI am trying to figure out how the filters act based on CPU ?availability.\nI understand there is a RAM filter, which decides the RAM allocation\nratio, so that RAM of a particular host does\'t get over used. Now, in the\nsame way CPUs can also be overused, if I keep launching\ninstances.\n?\nIs there any filter that takes care of that? A filter that can reject a host\nif the CPUs are overused.?\n\nThanks.\n\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130802/0653d829/attachment.html>\n\n',NULL,NULL),('<1375437479.42183.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-02 17:57:59',28800,'2013-08-02 09:57:59',NULL,'[Openstack] Which filter is based on CPUs availability?','Yeah, that\'s the one.?\n\nThanks.\n?\n~Peeyush Gupta\n\n\n________________________________\n From: JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com>\nTo: Peeyush Gupta <gpeeyush at ymail.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, 2 August 2013 3:23 PM\nSubject: Re: [Openstack] Which filter is based on CPUs availability?\n \n\n\nCoreFilter??\n\n\nhttp://docs.openstack.org/trunk/openstack-compute/admin/content/scheduler-filters.html#corefilter \n\n\n\n---JuanFra\n\n\n2013/8/2 Peeyush Gupta <gpeeyush at ymail.com>\n\nHi,\n>\n>\n>I am trying to figure out how the filters act based on CPU ?availability.\n>I understand there is a RAM filter, which decides the RAM allocation\n>ratio, so that RAM of a particular host does\'t get over used. Now, in the\n>same way CPUs can also be overused, if I keep launching\n>instances.\n>?\n>Is there any filter that takes care of that? A filter that can reject a host\n>if the CPUs are overused.?\n>\n>\n>Thanks.\n>\n>~Peeyush Gupta\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130802/b870e14d/attachment.html>\n\n','<CAGXO4kxB1ePSkea6EObRNN=xA5sAjVZX5RJ7g9oFdy_OvgGabQ@mail.gmail.com>',NULL),('<1375437491.11290.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 10:58:11',3600,'2013-08-02 09:58:11',NULL,'[openstack-dev] Python overhead for rootwrap','On Thu, 2013-07-25 at 14:40 -0600, Mike Wilson wrote:\n> In my opinion:\n> \n> 1. Stop using rootwrap completely and get strong argument checking support\n> into sudo (regex).\n> 2. Some sort of long lived rootwrap process, either forked by the service\n> that want\'s to shell out or a general purpose rootwrapd type thing.\n> \n> I prefer #1 because it\'s surprising that sudo doesn\'t do this type of thing\n> already. It _must_ be something that everyone wants. But #2 may be quicker\n> and easier to implement, my $.02.\n\nIMHO, #1 set the discussion off in a poor direction.\n\nWho exactly is stepping up to do this work in sudo? Unless there\'s\nsomeone with a even prototype patch in hand, any insistence that we base\nour solution on this hypothetical feature is an unhelpful diversion.\n\nAnd even if this work was done, it will be a long time before it\'s in\nall the distros we support, so improving rootwrap or finding an\nalternate solution will still be an important discussion.\n\nCheers,\nMark.\n\n\n\n','<CAFshShNhPRdQEODo8tEF4FSMMhUAi4Kj1OxR_k=mrim5SzthpQ@mail.gmail.com>',NULL),('<1375458797-sup-7722@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-02 08:54:49',-25200,'2013-08-02 15:54:49',NULL,'[Openstack] ssh login for Grizzly ubuntu 12.04','Please do not reply to one thread to start a new one.\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette#Threading\n\nExcerpts from raghavendra.lad\'s message of 2013-08-02 05:39:17 -0700:\n> Hi Openers,\n> \n> I have installed the Grizzly version of openstack . I request if anybody can provide steps how to ssh to instance. I would be grateful.\n> \n> Any help would be highly appreciated.\n> \n> Regards,\n> Raghavendra Lad\n> \n\n\n','<E39ABD579F2BEE4F96385323FF5069E005D75D8C@048-CH1MPN1-201.048d.mgd.msft.net>',NULL),('<1375458917-sup-373@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-02 09:10:13',-25200,'2013-08-02 16:10:13',NULL,'[Openstack] Diskless Compute Nodes?','Excerpts from Mark Chaney\'s message of 2013-08-02 04:36:16 -0700:\n> So I am planning on setting up my first openstack cloud a little like so where my Compute nodes will be diskless: \n> \n> http://content.screencast.com/users/MACscr/folders/Snagit/media/539491bf-c5ed-49e8-88a5-d812f954176e/2013-08-02_04-54-29.png\n> \n> I will be using Ceph for Object Storage and also RBD for the VM storage. Since the Compute nodes will be diskless, I will have to boot them through pxe and load the OS into memory and then also when guests are booted, they will have to be done through their Volumes since Ephemeral storage will not be available.\n> \n> Since I unfortunately seem to be going against the standard practice, I am wondering if anyone has any suggestions on any deployment or management tools that I might be able to use to better create my openstack mini cloud and also manage it (adding new nodes, storage, etc). Unfortunately it looks like tools like Fuel for Openstack or the Rackspace Private Cloud toolset not only do not support diskless Compute nodes, but also do not even support Ceph. I know I could build everything from scratch, but thats not only going to be time consuming, but a pain to maintain in the future. The TripleO project seems to have a lot of promise, but unfortunately appears to be a bit to early in its dev cycle and also at least at its current state, to be a bit over my head.\n> \n\nHi Mark, we had a nice discussion in #tripleo last night, and I really\nthink you bring an interesting operating paradigm to OpenStack with\ndiskless compute nodes.\n\nTripleO is not chasing your use case, but it would not be that hard to\nadd it. TripleO relies on Nova\'s baremetal at the moment, and will rely\non Ironic (split out baremetal support) when it reaches parity. Nova\nbaremetal currently works like this:\n\n* Copy image out of glance into raw image file on compute node\n* PXE boot target machine into \"deployment\" ramdisk\n  - deploy ramdisk exposes \"the disk\" via iscsi\n  - deploy ramdisk calls back to nova\'s baremetal helper to notify that iscsi is ready\n* attach to machine\'s iscsi and dd raw image file onto iscsi disk\n* PXE boot target machine into the initrd+kernel from the image, root is located via label\n\nI have not been following Ironic\'s details closely, but I believe it\nis only a more refined implementation of the above. In order to support\nbooting baremetal from a Ceph volume, you\'d need this pattern:\n\n* Create Ceph volume from image using Cinder\n* PXE boot target machine into initrd+kernel from image\n  - initrd uses ec2 metadata service to locate  Ceph RBD volume info\n  - initrd mounts RBD volume as root disk and boots\n\nSo, I don\'t think there are major technical hurdles to get over, just code to write.\n\n\n','<E6918601-2ED3-4F2A-99BC-727370F0FAD3@lists.macscr.com>',NULL),('<1375460025.11290.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 17:13:45',3600,'2013-08-02 16:13:45',NULL,'[openstack-dev] [Infra] New \"Bug\" tags in commit messages','On Fri, 2013-08-02 at 09:00 -0700, James E. Blair wrote:\n> Hi,\n> \n> Anthony Dodd has recently implemented some cool new features that we\n> discussed at the summit -- driving more automation from commit messages.\n> Here\'s what you need to know to use the new features:\n> \n> Use header style references when referencing a bug in your commit\n> log. The following styles are now supported and recommended [1]:\n> \n>     Closes-Bug: #1234567 -- use \'Closes-Bug\' if the commit is intended to\n>     fully fix and close the bug being referenced.\n> \n>     Partial-Bug: #1234567 -- use \'Partial-Bug\' if the commit is only a\n>     partial fix and more work is needed.\n> \n>     Related-Bug: #1234567 -- use \'Related-Bug\' if the commit is merely\n>     related to the referenced bug.\n> \n> While it is perfectly fine to reference a bug at any point within your\n> commit log, in order for proper automation to take place, ensure that\n> you reference your bugs on their own line, and preferably at the bottom\n> of the commit log near the Change-Id header as prescribed in our wiki\n> [2].\n> \n> The Regular Expression which we use to parse commit logs for bug\n> references is case-insensitive. Using the header \'closes-bug\' is\n> identical to using \'Closes-Bug\' in terms of the automation it will\n> affect.\n> \n> If your fix spans multiple commits, then simply use the \'Partial-Bug\'\n> header when you reference your bug. Then, when you are ready to close\n> the bug with a final commit, use the \'Closes-Bug\' header.\n> \n> If you are having a lot of difficulty remembering to use the recommended\n> header styles, have no fear! Referencing your bugs the old school way\n> still works. That is:\n> \n>     bug #123454321 -- this will invoke the \'Closes-Bug\' functionality.\n> \n>     fixes bug: #123454321 -- this will invoke the \'Closes-Bug\'\n>     functionality.\n> \n>     resolves bug: #123454321 -- this will invoke the \'Closes-Bug\'\n>     functionality.\n> \n>     Supplying an unknown bug header?such as \'Mega-Bug: #123454321\' -- will\n>     simply invoke the \'Related-Bug\' functionality for safety reasons.\n> \n> [1] For original summit discussion, see\n>     https://etherpad.openstack.org/drive-automation-from-commitmsg\n> \n> [2] https://wiki.openstack.org/wiki/GitCommitMessages\n> \n> Thanks again, Anthony, for doing this!\n\nNice! This is going to be really useful, especially the ability to\nmention bugs without the commit being seen as a fix for the bug, and the\nability to say a commit is a partial fix.\n\nCheers,\nMark.\n\n\n\n','<87y58kgk1j.fsf@meyer.lemoncheese.net>',NULL),('<1375495646053.4ecfbbe5@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 19:07:26',-25200,'2013-08-03 02:07:26',NULL,'[openstack-dev] [nova][glance] Future of nova\'s image API','Hi Joe,\n\n\n?\n?Am on my phone so can\'t find the links at the moment but there was some discussion around this when working out what we should leave out of the v3 api. Some people had concerns about exposing the glance api publicly and so wanted to retain the images support in Nova.\n\n\n?\n?So the consensus seemed to be to leave the images support in, but to demote it from core. So people who don\'t want it exclude the os-images extension.\n\n\n\n\n?Just as I write this I\'ve realised that the servers api currently returns links to the image used for the instance. And that won\'t be valid if the images extension is not loaded. So probably have some work to do there to support ?that properly.\n\n\nRegards,\n\n\nChris?\n\n\n\n\n\n\n\n\nOn Sat, Aug 3, 2013 at 6:54 AM, Joe Gordon <joe.gordon0 at gmail.com=\"mailto:joe.gordon0 at gmail.com\">> wrote:\nHi All,\n\neven though Glance, has been pulled out of Nova years ago, Nova still has a images API that proxies back to Glance. ?Since Nova is in the process of creating a new, V3, API, we know have a chance to re-evaluate this API.?\n\n\n\n\n* Do we still need this in Nova, is there any reason to not just use Glance directly? ?I have vague concerns about making Glance API publicly accessible, but I am not sure what the underlying reason is\n\n\n* If it is still needed in Nova today, can we remove it in the future and if so what is the timeline?\n\n\nbest,\nJoe Gordon\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/738807ca/attachment.html>\n\n','<CAHXdxOd4hUipAQaq+8TL81XaN1nzUQs8e=qa=PXzkYBSk0Ezew@mail.gmail.com>',NULL),('<1375496572000.3a835a14@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-02 19:22:52',-25200,'2013-08-03 02:22:52',NULL,'[openstack-dev] [Nova] Review request: Blurprint of API\n validation','On Sat, Aug 3, 2013 at 9:16 AM, Doug Hellmann <doug.hellmann at dreamhost.com=\"mailto:doug.hellmann at dreamhost.com\">> wrote:\n\n\n\nOn Fri, Aug 2, 2013 at 5:19 PM, Russell Bryant <rbryant at redhat.com> wrote:\nOn 08/02/2013 05:13 PM, Doug Hellmann wrote:\n\n> When we discussed this earlier, there was concern about moving to a\n\n> completely new toolset for the new API in Havana because of other\n\n> changes going on at the same time (something to do with extensions,\n\n> IIRC). I agreed it made sense to stick with our current tools to avoid\n\n> adding risk to the schedule. If that schedule has slipped into the next\n\n> release, or if you feel there is time after all, then I would also\n\n> prefer to go ahead with the general consensus reached at the Havana\n\n> summit and use WSME.\n\n\nThe Nova v3 API schedule has slipped. ?A huge amount of progress has\n\nbeen made, but it\'s going to be marked experimental in Havana. ?We\'re\n\ngoing to wrap it up for Icehouse. ?So, there\'s another release cycle\n\navailable to work on the v3 API infrastructure.\n\n\nSounds good.\n\n\n\n\n\n\n?\n?I think the critical bit will be if we can move to wsme with minimal to no changes to the ?code for the extensions. Or at least a way that it can be done in-place easily without breaking everything. Eg some transition phase where wsme can support the wsgi api temporarily.?\n\n\nOtherwise we\'re in for either a giant patch which will be hard to merge or a similar rather painful process to what we\'ve had to do for the extension framework changes in Havana.\n\n\n?\n?Chris\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/cc4fd7f4/attachment.html>\n\n','<CADb+p3TMW9B8cYXmV8_yP0Wm6RoyXOSVWmojRN9=vyAo=0sZ7Q@mail.gmail.com>',NULL),('<1375684860.5411.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 14:41:00',28800,'2013-08-05 06:41:00',NULL,'[Openstack] How to use AggregateCoreFilter?','Hi,?\n\nI am trying to use AggregateCoreFilter. I understand that first I have to add\nit to the nova.conf file. After adding it is functioning. But what I am not able\nto understand is that how to use it with aggregates.\n\nThe description says:??AggregateCoreFilter supports per-aggregate cpu_allocation_ratio.\n\nNow, I have created an aggregate and I want to use cpu_allocatio_ratio =some_value on\nthe hosts of this aggregates. How can I do that? How do I make it work on the hosts\nof a particular aggregate?\n\nThanks.?\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/ca16f04e/attachment.html>\n\n',NULL,NULL),('<1375690151.85017.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 01:09:11',-25200,'2013-08-05 08:09:11',NULL,'[Openstack] Instance cannot access internet','Hi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n\nAfter creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n\nI attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\nBut I did set the gateway to 192.168.100.98\n\nThank you in advance.\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/2f05b46d/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OSerror01.jpg\nType: image/jpeg\nSize: 197861 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/2f05b46d/attachment-0001.jpg>\n\n',NULL,NULL),('<1375690580.51322.YahooMailNeo@web194604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 16:16:20',28800,'2013-08-05 08:16:20',NULL,'[Openstack] How to use AggregateCoreFilter?','Hi Qiu,\n\nThat works. Thank You.\n?\n~Peeyush Gupta\n\n\n________________________________\n From: Qiu Yu <unicell at gmail.com>\nTo: Peeyush Gupta <gpeeyush at ymail.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, 5 August 2013 12:21 PM\nSubject: Re: [Openstack] How to use AggregateCoreFilter?\n \n\nYou may use following command to specify aggregate\'s cpu_allocation_ratio value.\n\nnova aggregate-set-metadata <aggregate id> cpu_allocation_ratio=<some value>\n\n--\nQiu Yu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/0f6455e8/attachment.html>\n\n','<CAM_HZbA86G4N8jJv-Q_FrrumaMXbY2i_EOCr8k7suOcs-kw8aQ@mail.gmail.com>',NULL),('<1375694556.89563.YahooMailNeo@web194606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 17:22:36',28800,'2013-08-05 09:22:36',NULL,'[Openstack] Can a aggregate have more than one availability zone?','Hi all,\n\nI have been trying to create an aggregate. Now, I understand I can\ndo this using nova create-aggregate and I can provide availability zone?\nwith this command. There is an aggregate-update command that changes\nthe availability zone. I want to have more than one availability zone for my\naggregate. Is it possible?\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/81c7c71d/attachment.html>\n\n',NULL,NULL),('<1375698558.75843.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 03:29:18',-25200,'2013-08-05 10:29:18',NULL,'[Openstack] Instance cannot access internet','I added a floating IP but still didn\'t fix the issue. Attached the screenshot to show I did.\n\nI have a feeling the issue is on my first picture where I said there is a missing IP. This could mean I dont have a route to the 192.168.100.x public network.?\n\nWhat do you think?\n\n\n\n\n\n________________________________\n From: Somanchi Trinath-B39208 <B39208 at freescale.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, August 5, 2013 7:06 PM\nSubject: RE: [Openstack] Instance cannot access internet\n \n\n\n \nAs the Picture shows You haven?t assigned Floating IP ??? \n?\nCheck the Floating IP assignment.\n?\n-\nTrinath Somanchi\n( trinath.somanchi at freescale.com )\n?\nFrom:Jake G. [mailto:dj_dark_junglist at yahoo.com] \nSent: Monday, August 05, 2013 1:39 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Instance cannot access internet\n?\nHi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n?\nAfter creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n?\nI attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\nBut I did set the gateway to 192.168.100.98\n?\nThank you in advance.\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/2679235e/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OSerror02.jpg\nType: image/jpeg\nSize: 55547 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/2679235e/attachment-0001.jpg>\n\n','<6032CA456358BF4D893A9274BE58D92C010DA7D8@039-SN1MPN1-003.039d.mgd.msft.net>',NULL),('<1375699026.88236.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 03:37:06',-25200,'2013-08-05 10:37:06',NULL,'[Openstack] Instance cannot access internet','- Yes My br-ex bridge has the IP 192.168.100.1 which I can ping from the 192.168.100.X network.\n-I cannot ping 192.168.100.98 from the?the 192.168.100.X network and?Openstack Host\n\n\n------ My openvswith layout-----\nsudo ovs-vsctl show\n3e02cdce-70d3-4f04-8f85-ec76aa63967b\n? ? Bridge br-ex\n? ? ? ? Port \"qg-8f16644e-43\"\n? ? ? ? ? ? Interface \"qg-8f16644e-43\"\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port br-ex\n? ? ? ? ? ? Interface br-ex\n? ? ? ? ? ? ? ? type: internal\n? ? Bridge br-int\n? ? ? ? Port br-int\n? ? ? ? ? ? Interface br-int\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port \"qvo2a3d522a-28\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"qvo2a3d522a-28\"\n? ? ? ? Port \"tap2a713313-38\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"tap2a713313-38\"\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port \"qr-504a0174-ce\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"qr-504a0174-ce\"\n? ? ? ? ? ? ? ? type: internal\n----------------------------------------------\n\n\n\n________________________________\n From: nilesh pawar <nilesh56 at gmail.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, August 5, 2013 7:30 PM\nSubject: Re: [Openstack] Instance cannot access internet\n \n\n\nHi \ncan u try to ping 192.168.100.98.\nAlso is ur br-ext over quantum node having an IP.?\n\n\n\n\nOn Mon, Aug 5, 2013 at 1:39 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nHi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n>\n>\n>After creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n>\n>\n>I attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\n>But I did set the gateway to 192.168.100.98\n>\n>\n>Thank you in advance.Jake\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n\n-- \nNilesh Pawar\n? \nAvoid the Gates of Hell.  Use Linux\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/3a827d59/attachment.html>\n\n','<CAEGUSHP6RuZwouifDdR_DwXOYDxYZ1mfC7n7XfmMEuOgZa2BWw@mail.gmail.com>',NULL),('<1375751070.38070.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-05 18:04:30',-25200,'2013-08-06 01:04:30',NULL,'[Openstack] Instance cannot access internet','I cant really see any other issue other than the missing gateway from my network topology view which should be set to 192.168.100.98\n\n\nFrom the host, I cannot ping GW IP 192.168.100.98 or instance floating IP 192.168.100.100 but I can ping the br-ex IP 192.168.100.1\nFrom the instance, I can ping the GW IP 10.0.0.1, another instance IP 10.0.0.4, but unable to ping anything outside of the 10.0.0.x network\n\n\nHow can I check if there is a proper route from 10.0.0.X to 192.168.100.X in openstack? In other words, how can I check if the router was properly configured on the backend?\n\nThank you!\n\n\n\n\n\n________________________________\n From: Jake G. <dj_dark_junglist at yahoo.com>\nTo: Somanchi Trinath-B39208 <B39208 at freescale.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, August 5, 2013 7:29 PM\nSubject: Re: [Openstack] Instance cannot access internet\n \n\n\nI added a floating IP but still didn\'t fix the issue. Attached the screenshot to show I did.\n\nI have a feeling the issue is on my first picture where I said there is a missing IP. This could mean I dont have a route to the 192.168.100.x public network.?\n\nWhat do you think?\n\n\n\n\n\n________________________________\n From: Somanchi Trinath-B39208 <B39208 at freescale.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, August 5, 2013 7:06 PM\nSubject: RE: [Openstack] Instance cannot access internet\n \n\n\n \nAs the Picture shows You haven?t assigned Floating IP ??? \n?\nCheck the Floating IP assignment.\n?\n-\nTrinath Somanchi\n( trinath.somanchi at freescale.com )\n?\nFrom:Jake G. [mailto:dj_dark_junglist at yahoo.com] \nSent: Monday, August 05, 2013 1:39 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Instance cannot access internet\n?\nHi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n?\nAfter creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n?\nI attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\nBut I did set the gateway to 192.168.100.98\n?\nThank you in advance.\nJake\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/dd9d657b/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OSerror01.jpg\nType: image/jpeg\nSize: 238444 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130805/dd9d657b/attachment-0001.jpg>\n\n','<1375698558.75843.YahooMailNeo@web163001.mail.bf1.yahoo.com>',NULL),('<1375758135-sup-1656@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-05 20:03:26',-25200,'2013-08-06 03:03:26',NULL,'[openstack-dev] Dropping or weakening the \'only import modules\'\n	style guideline - H302','Excerpts from Robert Collins\'s message of 2013-08-05 19:26:20 -0700:\n> I wanted to get a temperature reading from everyone on this style guideline.\n> \n> My view on it is that it\'s a useful heuristic but shouldn\'t be a\n> golden rule applied everywhere. Things like matches are designed to be\n> used as a dsl:\n>     self.assertThat(foo, Or(Equals(\"1\"), Equals(\"2\")))\n> \n> rather than what H302 enforces:\n>     self.assertThat(foo, matchers.Or(matchers.Equals(\"1\"),\n> matchers.Equals(\"2\")))\n> \n> Further, conflicting module names become harder to manage, when one\n> could import just the thing.\n> \n> Some arguments for requiring imports of modules:\n>  - makes the source of symbols obvious\n>    - Actually, it has no impact on that as the import is still present\n> and clear in the file. import * would obfuscate things, but I\'m not\n> arguing for that.\n>    - and package/module names can (and are!) still ambiguous. Like\n> \'test.\' - whats that? -> consult the imports.\n>  - makes mocking more reliable\n>    - This is arguably the case, but it\'s a mirage: it isn\'t a complete\n> solution because modules still need to be mocked at every place they\n> are dereferenced : only import modules helps to the extent that one\n> never mocks modules. Either way this failure mode of mocking is\n> usually very obvious IME : but keeping the rule as a recommendation,\n> *particularly* when crossing layers to static resources is a good\n> idea.\n>  - It\'s in the Google Python style guide\n> (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports)\n>    - shrug :)\n> \n> What I\'d like us to do is weaken it from a MUST to a MAY, unless noone\n> cares about it at all, in which case lets just turn it off entirely.\n\n\nYou\'ve convinced me. Monty\'s point about the complexity of making sure\nwhat is imported in code is actually a module makes it expensive without\nmuch benefit.\n\nI say remove it entirely.\n\n\n','<CAJ3HoZ0XvkhyHimkEvZYXOXACDJGOZtw18dmyfKGgPma_Pe93Q@mail.gmail.com>',NULL),('<1375766364.470.11.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 15:19:24',36000,'2013-08-06 05:19:24',NULL,'[openstack-dev] [Keystone] V3 Extensions Discoverability','Hi all, \n\nPartially in response to the trusts API review in keystoneclient\n(https://review.openstack.org/#/c/39899/ ) and my work on keystone API\nversion discoverability (spell-check disagrees but I\'m going to assume\nthat\'s a word - https://review.openstack.org/#/c/38414/ ) I was thinking\nabout how we should be able to know what/if an extension is available. I\neven made a basic blueprint for how i think it should work:\nhttps://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API.\n\nIs this intentional? I was starting to make a review to add it to\nidentity-api but is there the intention that extensions should show up\nwithin the endpoint APIs? There is no reason it couldn\'t work that way\nand DELETE would just fail. \n\nI am not convinced that it is a good idea though and I just want to\ncheck if this is something that has been discussed or purposefully\nhandled this way or something we need to add.\n\n\nThanks, \n\nJamie \n\n\n\n',NULL,NULL),('<1375770332.24389.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-06 07:25:32',3600,'2013-08-06 06:25:32',NULL,'[Openstack-operators] Removing the nova-clear-rabbit-queues','Hi\n\nJust a heads-up that I have proposed removing the\nnova-clear-rabbit-queues script since rabbitmq itself now has a CLI\nwhich can be used instead:\n\n  https://review.openstack.org/40355\n\nThis is related to the work around the oslo.messaging library we\'re\nhoping to add during Havana.\n\nFeedback welcome\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1375789172.2300.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-06 19:39:32',28800,'2013-08-06 11:39:32',NULL,'[Openstack] DB access not allowed for libvirt driver?','Hi all,\n\nI am trying to access nova.db from nova.virt.libvirt.driver for some\nexperiment purposes. When I tried that, I got an error saying \"DB\nnot allowed: nova compute\".\n\nWhy am I getting this? Is libvirt driver not allowed to talk to db?\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130806/ab6d2044/attachment.html>\n\n',NULL,NULL),('<1375804416.3010.10.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 11:53:36',-14400,'2013-08-06 15:53:36',NULL,'[openstack-dev] Blueprint for Nova native image building','Hello,\n\nA blueprint has been registered regarding API additions to Nova to\nenable the creation of base images from external OS install sources.\nThis provides a way to build images from scratch via native OS installer\ntools using only the resources provided through Nova.  These images can\nthen be further customized by other tools that expect an existing image\nas an input, such as disk image builder.\n\nBlueprint -\nhttps://blueprints.launchpad.net/nova/+spec/base-image-creation\n\nSpecification - https://wiki.openstack.org/wiki/NovaImageCreationAPI\n\nIf this is a topic that interests you, please have a look (the spec is\nnot very long) and join the conversation.\n\nPlease note that this blueprint follows on from proof of concept work\nfor native image building discussed on this list in April:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html\n\nThank you,\n-Ian\n\n\n\n',NULL,NULL),('<1375809949.23490.198.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-06 13:25:49',-14400,'2013-08-06 17:25:49',NULL,'[Openstack-docs] Use of XML xi:include with xpointer','On Mon, 2013-08-05 at 16:10 -0500, David Cramer wrote:\n> Unfortunately, the (confusingly named) xpointer scheme was only ever\n> supported by libxml (xsltproc/xmllint). We\'re using Calabash to process\n> the xml which supports the xpath() scheme. In my other post I provide\n> examples of how to grab all the children of an element or all except for\n> the title.\n\nAh, my fault. I\'m so used to working with libxml that I\'d forgotten that\nxinclude/xpointer interoperability was hampered by the lack of agreement\non the xpointer schemes.\n\n> In my experiments, I haven\'t gotten Calabash to be namespace-aware when\n> handling the xpath expressions. I\'ve posted a question to xproc-dev\n> about this to find out what\'s up.\n\nDoes it not respect the xmlns() scheme? That seems to be some sort of\nstandard, according to this page:\n\nhttp://www.w3.org/2005/04/xpointer-schemes/\n\n\n> \n> On 07/31/2013 10:36 AM, Shaun McCance wrote:\n> > XInclude doesn\'t let you add child elements to the included element,\n> > but you can include multiple elements with XInclude, just not with\n> > the element() scheme. The xpointer() scheme allows you to use XPath,\n> > so you can put something at the end by manually duplicating the\n> > section element, then including the child content of the target\n> > section element:\n> > \n> > <section id=\"some_id\">\n> >   <xi:include href=\"some_file.xml\"\n> >              xpointer=\"xpointer(id(\'some_id\')/*)\"/>\n> >   <para>Something at the end</para>\n> > </section>\n> > \n> > It\'s more complicated to put something at the beginning, because\n> > you have to account for things like title and info elements. Not\n> > accounting for titleabbrev and subtitle:\n> > \n> > <section id=\"some_id\">\n> >   <xi:include href=\"some_file.xml\"\n> >              xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n> >                        xpointer(id(\'some_id\')/db:title)\">\n> >     <xi:fallback/>\n> >   </xi:include>\n> >   <xi:include href=\"some_file.xml\"\n> >              xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n> >                        xpointer(id(\'some_id\')/db:info)\">\n> >     <xi:fallback/>\n> >   </xi:include>\n> >   <para>Something at the beginning</para>\n> >   <xi:include href=\"some_file.xml\"\n> >              xpointer=\"xmlns(db=http://docbook.org/ns/docbook)\n> >                        xpointer(id(\'some_id\')/*\n> >                        [not(self::db:title or self::db:info)]\n> >                        )\"/>\n> >   <para>Something at the end</para>\n> > </section>\n> > \n> > Kind of messy, but still more long-term maintainable than manually\n> > including each child element of the target section.\n> > \n> > I wrote a howto on XInclude a couple years back, which you might\n> > find useful:\n> > \n> > http://blogs.gnome.org/shaunm/2011/07/21/understanding-xinclude/\n> > \n> > --\n> > Shaun\n> > \n> > On Wed, 2013-07-31 at 02:41 +0000, Sean Roberts wrote:\n> >> Both actually. I want to place a submit bug link at the end of each\n> >> section. Also want to add some text at the beginning for many of the\n> >> included sections describing training objectives. \n> >>\n> >>\n> >> I\'d also be interested in ideas on using xslt to rip and replace tags.\n> >> But that probably can wait a little bit. \n> >>\n> >> ~sean\n> >>\n> >> On Jul 30, 2013, at 9:18, \"Anne Gentle\"\n> >> <annegentle at justwriteclick.com> wrote:\n> >>\n> >>\n> >>> Hi Sean, \n> >>> Do you want some sort of \"glue text\" so that the guide can be read\n> >>> in a linear way? Or is it text that you\'ll use over and over, such\n> >>> as \"Now go take the test.\" Let us know what you\'re trying to do. \n> >>>\n> >>>\n> >>> You can\'t really strip a tag at a time without XSLT (the transform\n> >>> code that lives in the Maven plugin).\n> >>> Anne\n> >>>\n> >>>\n> >>> On Tue, Jul 30, 2013 at 9:19 AM, Sean Roberts\n> >>> <seanrob at yahoo-inc.com> wrote:\n> >>>         Ideas on how to add text to the included section or final\n> >>>         page? Part of the problem may be from that I\'m stuck using\n> >>>         the chapter or section of the original XML. If I could\n> >>>         include, strip the section tags, then I could add text no\n> >>>         problem. \n> >>>         \n> >>>         ~sean\n> >>>         \n> >>>         On Jul 30, 2013, at 6:54, \"Anne Gentle\"\n> >>>         <annegentle at justwriteclick.com> wrote:\n> >>>         \n> >>>         \n> >>>         > I think DocBook sees the markup as a closed section\n> >>>         > followed by a para whic is invalid.\n> >>>         > \n> >>>         > Anne Gentle \n> >>>         > Content Stacker\n> >>>         > anne at openstack.org\n> >>>         > \n> >>>         > \n> >>>         > \n> >>>         > On Jul 30, 2013, at 8:38 AM, Sean Roberts\n> >>>         > <seanrob at yahoo-inc.com> wrote:\n> >>>         > \n> >>>         > \n> >>>         > > I am pulling in a section through <xi:include\n> >>>         > > href=\"http.....xpointer=\"element(foobar)\"></xi:include>\n> >>>         > > If I want to use additional text, I\'m forced to make it\n> >>>         > > a section as well. I want to add text to the beginning\n> >>>         > > or end of the the included section. \n> >>>         > > I tried <xi:include\n> >>>         > > href=\"http.....xpointer=\"element(foobar)\"><para>blah\n> >>>         > > blah</para></xi:include>\n> >>>         > > , which shows up without error in oxygen, but maven\n> >>>         > > seems to strip it out during HTML build. \n> >>>         > > \n> >>>         > > ~sean\n> >>>         > > \n> >>>         > > On Jul 30, 2013, at 6:24, \"Anne Gentle\"\n> >>>         > > <annegentle at justwriteclick.com> wrote:\n> >>>         > > \n> >>>         > > \n> >>>         > > > Hi Sean,  \n> >>>         > > > Post your XML code so we can take a closer look, or a\n> >>>         > > > link to the patch and the file name so we can look at\n> >>>         > > > it. \n> >>>         > > > Thanks!\n> >>>         > > > Anne\n> >>>         > > > \n> >>>         > > > \n> >>>         > > > On Tue, Jul 30, 2013 at 2:56 AM, Sean Roberts\n> >>>         > > > <seanrob at yahoo-inc.com> wrote:\n> >>>         > > >         I have another question. I\'m bringing in the\n> >>>         > > >         sections which is the smallest page into the\n> >>>         > > >         built HTML. I\'m trying to add text and links\n> >>>         > > >         within the final HTML page without success.\n> >>>         > > >         Oxygen shows the link and text fine, but the\n> >>>         > > >         maven built site only has the included\n> >>>         > > >         section. Perhaps some adjustment within the\n> >>>         > > >         pom file...\n> >>>         > > >         \n> >>>         > > >         ~sean\n> >>>         > > >         \n> >>>         > > >         On Jul 29, 2013, at 9:34, \"Diane Fleming\"\n> >>>         > > >         <diane.fleming at rackspace.com> wrote:\n> >>>         > > >         \n> >>>         > > >         \n> >>>         > > >         > I don\'t know if this will work, but this is\n> >>>         > > >         how I used xpointer to pull in\n> >>>         > > >         > content from one file to another:\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         > Target file (pulls in content)\n> >>>         > > >         >\n> >>>         > > >         > <title>Overview</title>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over1)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over2)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over3)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over4)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over5)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over6)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over7)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over8)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over9)\"/>\n> >>>         > > >         > <xi:include href=\"ch_gs_overview.xml\"\n> >>>         > > >         >                xpointer=\"element(over10)\"/>\n> >>>         > > >         > <xi:include href=\"section_virt_ext.xml\"/>\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         > Source file\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >    <title>Overview</title>\n> >>>         > > >         >    <section\n> >>>         > > >         xml:id=\"cn_overview\"><title>Cloud\n> >>>         > > >         Networks</title>\n> >>>         > > >         >    <para xml:id=\"over1\">Cloud Networks lets\n> >>>         > > >         you create a virtual\n> >>>         > > >         >        Layer 2 network, known as an isolated\n> >>>         > > >         network, which gives you\n> >>>         > > >         >        greater control and security when you\n> >>>         > > >         deploy web applications.\n> >>>         > > >         > </para>\n> >>>         > > >         >    <para xml:id=\"over2\">When you create a\n> >>>         > > >         next generation Cloud\n> >>>         > > >         >        Server, Cloud Networks enables you to\n> >>>         > > >         attach one or more\n> >>>         > > >         >        networks to your server. You can\n> >>>         > > >         attach an isolated network\n> >>>         > > >         >        that you have created or a Rackspace\n> >>>         > > >         network. </para>\n> >>>         > > >         >    <para xml:id=\"over3\">If you install the\n> >>>         > > >         &virt_ext;, you can create\n> >>>         > > >         >        a virtual interface to a specified\n> >>>         > > >         Rackspace or isolated\n> >>>         > > >         >        network and attach that network to an\n> >>>         > > >         existing server\n> >>>         > > >         >        instance. You can also list virtual\n> >>>         > > >         interfaces for and delete\n> >>>         > > >         >        virtual interfaces from a server\n> >>>         > > >         instance. For information\n> >>>         > > >         >        about the &virt_ext;, see <xref\n> >>>         > > >         linkend=\"section_virt_ext\"\n> >>>         > > >         >        />.</para>\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         > etc.\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         > Diane\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         ----------------------------------------------\n> >>>         > > >         > Diane Fleming\n> >>>         > > >         > Software Developer II - US\n> >>>         > > >         >\n> >>>         > > >         > diane.fleming at rackspace.com\n> >>>         > > >         > Cell  512.323.6799\n> >>>         > > >         > Office 512.874.1260\n> >>>         > > >         > Skype drfleming0227\n> >>>         > > >         > Google-plus diane.fleming at gmail.com\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         > On 7/29/13 9:27 AM, \"Sean Roberts\"\n> >>>         > > >         <seanrob at yahoo-inc.com> wrote:\n> >>>         > > >         >\n> >>>         > > >         >> I\'m working on reusing content from remote\n> >>>         > > >         XML formatted sources to\n> >>>         > > >         >> create new content. I\'m using xi:include\n> >>>         > > >         xpointer to a section of an\n> >>>         > > >         >> existing XML file. Using the editor oxygen\n> >>>         > > >         I can see the remote content,\n> >>>         > > >         >> so I know my href is valid. But maven fails\n> >>>         > > >         to build the html from the\n> >>>         > > >         >> xml returning bad pointer.\n> >>>         > > >         >>\n> >>>         > > >         >> The remote content isn\'t using DTD or\n> >>>         > > >         XMLschema. I\'m hoping I can figure\n> >>>         > > >         >> out how to walk the structure without\n> >>>         > > >         having to.\n> >>>         > > >         >> Any XML peoples that can help?\n> >>>         > > >         >>\n> >>>         > > >         >> ~sean\n> >>>         > > >         >>\n> >>>         > > >         _______________________________________________\n> >>>         > > >         >> Openstack-docs mailing list\n> >>>         > > >         >> Openstack-docs at lists.openstack.org\n> >>>         > > >         >>\n> >>>         > > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >>>         > > >         >\n> >>>         > > >         >\n> >>>         > > >         \n> >>>         > > >         _______________________________________________\n> >>>         > > >         Openstack-docs mailing list\n> >>>         > > >         Openstack-docs at lists.openstack.org\n> >>>         > > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> >>>         > > >         \n> >>>         > > > \n> >>>         > > > \n> >>>         > > > \n> >>>         > > > \n> >>>         > > > -- \n> >>>         > > > Anne Gentle\n> >>>         > > > annegentle at justwriteclick.com\n> >>>\n> >>>\n> >>>\n> >>>\n> >>> -- \n> >>> Anne Gentle\n> >>> annegentle at justwriteclick.com\n> >> _______________________________________________\n> >> Openstack-docs mailing list\n> >> Openstack-docs at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> > \n> > \n> > _______________________________________________\n> > Openstack-docs mailing list\n> > Openstack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<520014CB.8070207@rackspace.com>',NULL),('<1375814066.097118890@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 14:34:26',-14400,'2013-08-06 18:34:26',NULL,'[openstack-dev] Dropping or weakening the \'only import modules\'\n	style guideline - H302','another -1 from me for dropping it from hacking.\n\nI\'ve been bitten by both lack of explicit usage and review bikeshedding on this exact thing.\n\n-Alex\n\n-----Original Message-----\nFrom: \"Sean Dague\" <sean at dague.net>\nSent: Tuesday, August 6, 2013 7:32am\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] Dropping or weakening the \'only import modules\' style guideline - H302\n\nOn 08/05/2013 10:38 PM, Monty Taylor wrote:\n>\n>\n> On 08/05/2013 11:26 PM, Robert Collins wrote:\n>> I wanted to get a temperature reading from everyone on this style guideline.\n>>\n>> My view on it is that it\'s a useful heuristic but shouldn\'t be a\n>> golden rule applied everywhere. Things like matches are designed to be\n>> used as a dsl:\n>>      self.assertThat(foo, Or(Equals(\"1\"), Equals(\"2\")))\n>>\n>> rather than what H302 enforces:\n>>      self.assertThat(foo, matchers.Or(matchers.Equals(\"1\"),\n>> matchers.Equals(\"2\")))\n>>\n>> Further, conflicting module names become harder to manage, when one\n>> could import just the thing.\n>>\n>> Some arguments for requiring imports of modules:\n>>   - makes the source of symbols obvious\n>>     - Actually, it has no impact on that as the import is still present\n>> and clear in the file. import * would obfuscate things, but I\'m not\n>> arguing for that.\n>>     - and package/module names can (and are!) still ambiguous. Like\n>> \'test.\' - whats that? -> consult the imports.\n>>   - makes mocking more reliable\n>>     - This is arguably the case, but it\'s a mirage: it isn\'t a complete\n>> solution because modules still need to be mocked at every place they\n>> are dereferenced : only import modules helps to the extent that one\n>> never mocks modules. Either way this failure mode of mocking is\n>> usually very obvious IME : but keeping the rule as a recommendation,\n>> *particularly* when crossing layers to static resources is a good\n>> idea.\n>>   - It\'s in the Google Python style guide\n>> (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports)\n>>     - shrug :)\n>>\n>> What I\'d like us to do is weaken it from a MUST to a MAY, unless noone\n>> cares about it at all, in which case lets just turn it off entirely.\n>\n> Enforcing it is hard. The code that does it has to import and then make\n> guesses on failures.\n>\n> Also - I agree with Robert on this. I _like_ writing my code to not\n> import bazillions of things... but I think the hard and fast rule makes\n> things crappy at times.\n\nThe reason we go hard and fast on certain rules is to reduce review time \nby people. If something is up for debate we get bikeshedding in reviews \nwhere one reviewer tells someone to do it one way, 2 days later they \nupdate their review, another reviewer comes in and tells them to do it \nthe otherway. (This is not theoretical, it happens quite often, if you \ndo a lot of reviews you see it all the time.) It also ends up being \nsomething reviewers can stop caring about, because the machine will pick \nit up. Giving them the ability to focus on higher order issues, and \nstill keeping the code from natural entropy.\n\nMUST == computer can do it, less work for core review time (which is \nrealistically one of our most constrained resources in OpenStack)\nMAY == humans have to make a judgement call, which means more work for \nour already constrained review teams\n\nI\'ve found H302 to really be useful on reviewing large chunks of code \nI\'ve not been in much before. And get seriously annoyed being in \nprojects that don\'t have it enforced yet (tempest is guilty of that). \nBeing able to quickly know what namespace things are out of saves time.\n\nHonestly, after spending the year with the constraint in OpenStack, I\'m \nnever going to import modules directly in my personal projects, as I \nthink the benefits of the explicitness have shown themselves pretty well.\n\nSo I\'m a soft -1 on dropping it from hacking.\n\n	-Sean\n\n-- \nSean Dague\nhttp://dague.net\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5200DEDF.4000102@dague.net>',NULL),('<1375814923-sup-3313@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 11:53:38',-25200,'2013-08-06 18:53:38',NULL,'[openstack-dev] [DevStack] Python dependencies: PyPI vs distro\n	packages','Excerpts from Dean Troyer\'s message of 2013-08-05 10:03:07 -0700:\n> * about-face on all-packages to all-PyPI (mtaylor): I\'m still on the\n> use packages where possible side but DevStack specifically is not in\n> the packaging business.  If it were we\'d do what Java folk (*sorry*)\n> have long taken the approach for non-trivial apps to just include the\n> whole damn runtime.  Write once duplicate everywhere.\n> \n\nJust as an FYI, we have gone with the virtualenv + pypi for everything\napproach in TripleO. Each project gets its own virtualenv and its own\nisolated python path.\n\nThis has exposed a few problems (most recently Heat was broken without\nat least one thing that pulled in Babel in its virtualenv because it did\nnot explicitly list Babel in requirements.txt), but these are straight\nforward and need fixing anyway.\n\nI was a bit resistant to this approach at first, but this has produced\na very simple system that is also isolated from the python oddities of\nany system level tools.\n\n\n','<CAOJFoEvCHW+waMy+6isBRBcR5Mtn-vdPLxoYmCYJcm-xS4-PFg@mail.gmail.com>',NULL),('<1375817399-sup-1453@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 12:40:56',-25200,'2013-08-06 19:40:56',NULL,'[openstack-dev] [Keystone] V3 Extensions Discoverability','Excerpts from Jay Pipes\'s message of 2013-08-06 10:34:30 -0700:\n> On 08/06/2013 01:21 PM, David Chadwick wrote:\n> >\n> >\n> > On 06/08/2013 18:11, Jay Pipes wrote:\n> >> What SMTP, DNS and LDAP extensions are in use by systems that need to\n> >> interoperate in the same way that Keystone does? <-- This is a genuine\n> >> question, not sarcasm. I\'m truly curious.\n> >\n> > Take SMTP for example. My Thunderbird client needs to know what\n> > authentication extensions are implemented by the POP3 server and SMTP\n> > server that it is talking to, in order to send and receive email in a\n> > secure manner.\n> >\n> > In the same way, once Keystone supports say federated login as an\n> > extension, a client will need to know if this extension is supported or\n> > not. If not, it wont be able to offer it to the end user. (It is not a\n> > sensible design for a client to send an extension protocol message to a\n> > server and get a 400 Bad Request response. This tells the client\n> > nothing. 501 Not Implemented might be a more informative response, but\n> > in this case the server has to know that an extension was requested and\n> > we have to document that this is the standard response to an\n> > unimplemented extension).\n> \n> Ah, OK, so I think we\'re actually closer to one another than first \n> glance. So, I *entirely* agree that if API extensions are \n> available/supported by an API, then there should be an easy way to \n> discover those extensions -- /endpoints is perfectly fine.\n> \n> I also agree that a *protocol* should have the flexibility, within its \n> bytestream construct, to extend its scope over time, *without needing to \n> change the underlying protocol*. So, for example, a protocol that leaves \n> itself some way of \"growing\" over time is, by nature, A Good Thing (tm).\n> \n> However, I do *not* believe that resource additions to a REST-ful API \n> necessitate a new API \"extension\" that must be treated like something \n> that is fundamentally different from the existing resources published in \n> the API.\n> \n> Por ejemplo,\n> \n> I do not believe the adding a /regions resource should require me to add \n> an API \"extension\" just to add the resource to the API. I believe we \n> should be able to propose the adding of the /regions resource, debate \n> it, and then add it to a v3.x Keystone API.\n> \n> There isn\'t anything about a region resource that is fundamentally \n> different from some other resource managed by Keystone -- like domains \n> or endpoints -- and therefore I don\'t believe that adding a /regions \n> resource endpoint should require anything more than a bump in the \n> version of the API.\n> \n\nAgreed Jay. The successful extensible protocols like IMAP and SMTP are\nmerely allowing new arguments to existing fundamental functions.\n\nHTTP allows different MIME types. There is no Content-Type extension to\nthe HTTP protocol. It also allows X-anything, but these are only ways\nfor a specific group to use the protocol as defined to communicate.\n\nIf there is something missing from keystone\'s model, it should be\nadded to the API. This does sound more like a cultural problem than a\ntechnical one. Nobody should be afraid to add things to an API. I think\nsometimes API writers are put into an ivory tower because they are also\nheld to higher standards for rigor and documentation. But we should all\nbe capable of applying that standard to ourselves at some point. \n\nIt would help if we explicitly state that new API bits are encouraged,\nrather than making the warm safe place \"extension land\".\n\n\n','<520133A6.2050906@gmail.com>',NULL),('<1375824548.2720.2.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-06 23:29:08',7200,'2013-08-06 21:29:08',NULL,'[Openstack] Quantum agent-list not present in Debian\n	Grizzly	packages','Hi,\n\nplease submit this as a bug to the Debian BTS, so I\nwont forget to fix it.\n\nThomas\n\nOn Tue Aug?  6 2013 10:20:21 PM CEST, guillaume at cheramy.name <guillaume at cheramy.name> wrote:\n\n> Hello,\n> \n> ??? I try too install Openstack Grizzly on Debian Wheezy serveurs with\n> http://archive.gplhost.com/debian repos. My installation is a 3 node\n> with OVS plugins like this :\n> https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst\n> \n> So when I arrive in last part, in network creation \"Add the router to\n> the running l3 agent \" the command quantum agent-list doesn\'t exist.\n> \n> Thanks for your help\n> -- \n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \'\'~``\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  ( o o )\n> +------------------.oooO--(_)--Oooo.---------------------+\n> | Guillaume Ch?ramy - Guidtz? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> | French open source system administrator? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> | E-Mail : guillaume at cheramy.name? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> | Website : http://blog.cheramy.name? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  (? ?  )? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  |\n> +---------------------\\ (----(? ?  )-----------------------+\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \\_)? ? ?  ) /\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  (_/\n> \n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to? ?  \n>?  : openstack at lists.openstack.org Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<52015A85.7020404@cheramy.name>',NULL),('<1375826794.3010.25.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 18:06:34',-14400,'2013-08-06 22:06:34',NULL,'[openstack-dev] Blueprint for Nova native image building','On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:\n> \n> On 08/06/2013 03:46 PM, Russell Bryant wrote:\n> > On 08/06/2013 12:20 PM, Russell Bryant wrote:\n> >> On 08/06/2013 11:53 AM, Ian Mcleod wrote:\n> >>> Hello,\n> >>>\n> >>> A blueprint has been registered regarding API additions to Nova to\n> >>> enable the creation of base images from external OS install sources.\n> >>> This provides a way to build images from scratch via native OS installer\n> >>> tools using only the resources provided through Nova.  These images can\n> >>> then be further customized by other tools that expect an existing image\n> >>> as an input, such as disk image builder.\n> >>>\n> >>> Blueprint -\n> >>> https://blueprints.launchpad.net/nova/+spec/base-image-creation\n> >>>\n> >>> Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI\n> >>>\n> >>> If this is a topic that interests you, please have a look (the spec is\n> >>> not very long) and join the conversation.\n> >>>\n> >>> Please note that this blueprint follows on from proof of concept work\n> >>> for native image building discussed on this list in April:\n> >>>\n> >>> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html\n> >>\n> >> Thanks of the update on this work.\n> >>\n> >> I see that your proof of concept shows how this can work as a tool\n> >> outside of Nova:\n> >>\n> >> https://github.com/redhat-openstack/image-building-poc\n> >>\n> >> So, my biggest question is whether or not it makes sense for this to be\n> >> a Nova feature or not.  If something can be implemented as a consumer of\n> >> Nova, my default answer is that it should stay outside of nova until I\n> >> am convinced otherwise.  :-)\n\nThe proof of concept approach is limited to full-virt hypervisors.  It\'s\nunclear to me if there\'s a way we can make this work for Xen-backed\ninstalls without the kind of lower level access to the virt environment\nthat we\'ll get if we exist inside of Nova.\n\nMore generally, it\'s likely that we\'ll have more flexibility to behave\nin a sane/optimized manner based on backing hypervisor if the code is\ninside of Nova.  For example, we\'ve talked about improving our detection\nof a failed install by monitoring disk IO.\n\n> >>\n> >> It sounds like this is mostly an extension to nova that implements a\n> >> series of operations that can be done just as well outside of Nova.  Are\n> >> there enhancements you are making or scenarios that won\'t work at all\n> >> unless it lives inside of Nova?\n\nOther than the Xen issue above, I\'m not sure there\'s anything that\nsimply won\'t work at all, though there are things that perhaps won\'t\nscale as well or won\'t run as quickly.\n\n> >>\n> >> If it doesn\'t end up on the server side, it could potentially be\n> >> implemented as an extension to novaclient.\n> >>\n> > \n> > Also, whatever we end up with, I\'d like to see it hypervisor agnostic as\n> > much as possible.  I just came across this xen specific patch:\n> > \n> > https://review.openstack.org/#/c/38650/\n> \n> Yes to everything Russel said. I\'d like to see the tool be standalone.\n> Then, if there is a desire to provide the ability to run it via an api,\n> the tool could be consumed (similar discussions have happened around\n> putting diskimage-builder behind a service as well)\n> \n> That said - if we did service-ify the tool, wouldn\'t glance be a more\n> appropriate place for that sort of thing?\n\nPossibly, though the proof of concept (and we hope our proposed\nnova-based re-implementation) can build both glance images and cinder\nvolume backed images.\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<52014855.4050105@inaugust.com>',NULL),('<1375830980.470.12.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-07 09:16:20',36000,'2013-08-06 23:16:20',NULL,'[openstack-dev] Proposing Morgan Fainberg for keystone-core','+1\n\nOn Tue, 2013-08-06 at 14:20 -0500, Dolph Mathews wrote:\n> Through feedback on code reviews and blueprints, Morgan clearly has\n> the best interests of the project itself in mind. I\'d love for his\n> votes to carry a bit more weight!\n> \n> \n>   https://review.openstack.org/#/dashboard/2903\n> \n> \n> Respond with +1/-1\'s before Friday, thanks!\n> \n> \n> -Dolph\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n\n\n','<CAC=h7gXHqhqaDJ8n5cqLVhGhuvscQm6fB8FJgvGqybQBbF28Mw@mail.gmail.com>',NULL),('<1375831516.470.16.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-07 09:25:16',36000,'2013-08-06 23:25:16',NULL,'[openstack-dev] [Keystone] V3 Extensions Discoverability','On Tue, 2013-08-06 at 11:17 -0400, Adam Young wrote:\n> On 08/06/2013 10:54 AM, Dolph Mathews wrote:\n> \n> > \n> > On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams\n> > <jorge.williams at rackspace.com> wrote:\n> >         \n> >         On Aug 6, 2013, at 8:36 AM, Adam Young wrote:\n> >         \n> >         > On 08/06/2013 01:19 AM, Jamie Lennox wrote:\n> >         >> Hi all,\n> >         >>\n> >         >> Partially in response to the trusts API review in\n> >         keystoneclient\n> >         >> (https://review.openstack.org/#/c/39899/ ) and my work on\n> >         keystone API\n> >         >> version discoverability (spell-check disagrees but I\'m\n> >         going to assume\n> >         >> that\'s a word - https://review.openstack.org/#/c/38414/ )\n> >         I was thinking\n> >         >> about how we should be able to know what/if an extension\n> >         is available. I\n> >         >> even made a basic blueprint for how i think it should\n> >         work:\n> >         >>\n> >         https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-extensions and then realized that GET /extensions is only a V2 API.\n> >         >\n> >         > I\'m not certain that the extensions should really be in\n> >         the v2 or v3.  It always seemed to me that Extensions should\n> >         be parallel to, and separate from, the core API.\n> >         \n> >         \n> >         \n> >         I agree. Extensions should not be in core, but the mechanism\n> >         by which extensions are discovered should be part of the\n> >         core...right?\n> > \n> > \n> > Agree. The fact that you call GET /v2.0/extensions or\n> > GET /v3/extensions instead of GET /extensions just means that we can\n> > iterate on the \"extensions\" response itself, not necessarily that\n> > the extension *only* applies to particular version API being queried\n> > (that\'s a different issue).\n> \n> Agreed.  That makes sense.\n> \n> \n> So the APIs should be:\n> \n> v2.0/extensions\n> or\n> v3/extensions\n> \n> but those should return links to:\n> \n> extensions/some_extension\n\nThis was my thoughts as well, there is no reason for the extension to be\nversioned behind our keystone API because we don\'t expect the extension\napi to change with the core api. Extension discoverability should be\nbehind our API because we reserve the right to change how extensions are\ndiscovered. \n\nI think it also somewhat answers my question that we should be providing\na /v3/extensions rather than putting these into /v3/endpoints.\n\n> >  \n> >         \n> >         -jOrGe W.\n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> > \n> > \n> > \n> > \n> > -- \n> > \n> > \n> > -Dolph \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<52011392.6020007@redhat.com>',NULL),('<1375843937-sup-7609@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 19:54:08',-25200,'2013-08-07 02:54:08',NULL,'[openstack-dev] [Heat] The way to use one config file with new\n	oslo module','Excerpts from Emilien Macchi\'s message of 2013-08-06 09:09:08 -0700:\n> Hi,\n> \n> Since https://review.openstack.org/#/c/36476/ has been merged, heat\n> could use only one configuration file : heat.conf instead of\n> heat-engine.conf, heat-api.conf, etc.\n> \n> I would like your thoughts about deleting old configuration files, since\n> that could break something in the CI.\n> \n> I already made a first patch here : https://review.openstack.org/#/c/40257/\n> But let\'s discuss about it before continuing to work on this patch.\n> \n> Cheers,\n> \n\nDoes oslo.config or anything in oslo-incubator give us some help with\ndeprecating old config files?\n\nWe haven\'t had a release with the current layout, which was done somewhat\naggressively because grizzly\'s Heat wasn\'t really integrated. But I don\'t\nlike the idea of moving config files that have been in place for a long\ntime without giving users some heads up about the move.\n\nAs for removing the old sample confs, I am all for it.\n\n\n','<52011FA4.4040403@enovance.com>',NULL),('<1375855731.43292.YahooMailNeo@web194604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 14:08:51',28800,'2013-08-07 06:08:51',NULL,'[Openstack] How do I define my own hints?','Hi,\n\nI have been trying to use some hints at the boot time. Now, there\nare some predefined hints to be used with nova boot command. I?\nunderstand that if I give any undefined hint then it will be silently ignored.\n\nSo, how can I define my own hint, so that ?I can use it with nova boot command?\n\nThanks.?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130807/236b2b0b/attachment.html>\n\n',NULL,NULL),('<1375856021-sup-4788@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 23:21:09',-25200,'2013-08-07 06:21:09',NULL,'[openstack-dev] [DevStack] Python dependencies: PyPI vs distro\n	packages','Excerpts from Joshua Harlow\'s message of 2013-08-06 21:03:58 -0700:\n> It does seem sad that the state of package management is this bad. \n> \n> It\'d would be equally interesting to hear how others rollback changes (another thing yum doesn\'t do so well, since it doesn\'t have a good ability to rollback dependent changes, especially when said rollback would alter a lot of versions and requirements). Maybe apt does this better. Idk.\n> \n> How are others working through that? \n> \n\nRoll back is an illusion. Time does not go in reverse.\n\nIn TripleO with Heat, the vision is to have known working images, and\nunknown images. If an unknown image is mid-rollout and has problems,\nthe working image should be re-deployed. You can call this Rollback,\nbut it is really just a new deployment that is intended to be the same\nas the old version.\n\nTrying to do this piecemeal, package by package, means you suffer when\na packager has messed up a maintainer script or an admin has edited a\nfile in-place. Your root file-system\'s state has as much influence on\nyour overall system state as the database.\n\nI\'m not saying packages are not useful for system maintenance. But they\ncarry some penalties that only really start to matter when you have lots\nof machines. Using a virtualenv and testing it for everything we know\nwe want to do means knowing when that virtualenv rolls out that it has\na good chance of performing the same way.\n\n\n','<57FFDBC8-90E8-4614-A039-398E1305B704@yahoo-inc.com>',NULL),('<1375856201.17.1352505891861.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:04:51',0,'2012-11-10 00:04:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #88','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/88/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.01\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.35\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.06\n    test_public_versions                                        OK  0.05\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 18.923s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 6.71 secs:\n    2.12       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    2.09       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    1.08       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.35       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at f1cc3cfc42db902589785320547204388aa170a3#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 217bd202dd9a7359efb8b49799eb0626866a203f#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/88\n[SCP] Copying console log.\n\n\n','<1427292782.3.1352419480763.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1375862829.470.38.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-07 18:07:09',36000,'2013-08-07 08:07:09',NULL,'[openstack-dev] [Keystone] Validating UUID tokens with V3 API','Regarding my blueprint\nhttps://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-auth-token\nand Guang\'s bug\nhttps://bugs.launchpad.net/python-keystoneclient/+bug/1207922\n(auth_token middleware always use v2.0 to request admin token), i\'m\ntrying to make a v3 client capable of validating a UUID token. \n\nFor V2 without domains the concept of an admin user/role is simple and\nso to validate UUID tokens from auth_token middleware you simply need a\nusername/password or token. \n\nFor V3 do we have any concept of what policies will need to be in place\nto say that a user has the privilege to validate another user\'s token.\nThe problem comes in that to use the client we should scope a user to a\ndomain or a project. If you don\'t do this you don\'t receive the catalog\nof links, and the client is not populated with the management_url you\nshould be using for identity. A solution to this would be to hack around\nthe issue and just assume that if a v3 client is instantiated with an\nunscoped client then you assume that the management url is the same as\nthe client discovered url. This is generally wrong, but also i\'m not\nsure that the call to POST /v3/auth/token makes sense when authenticated\nwith an unscoped token.\n\nUsing username in v3 is also not appropriate without specifying the\ndomain name that the username is unique to so at the very least this\nwill need to get added to auth_token. \n\nHowever what happens with a scoped token? If auth_token has a token\nscoped differently to the token it is validating then the same \'admin\'\nrole should not apply (at least theoretically, i\'ve only been an\nobserver on the roles/domains debates). \n\nThe best way i can see out of it is a special type of role or domain\nwhose users have certain permissions across all the keystone domains. Is\nthere something like this already? Is the \'admin\' concept global across\ndomains? \n\nCan someone with a better understanding of roles, policy, and domains in\nV3 explain how this should work? \n\n\nThanks, \n\nJamie \n\n\n\n',NULL,NULL),('<1375869455.32309.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 17:57:35',28800,'2013-08-07 09:57:35',NULL,'[Openstack] How do I access filter properties from libvirt driver?','Hi,\n\nI have been trying to access an instance\'s filter properties\nthrough libvirt driver. I understand that the instance info received?\nby libvirt doesn\'t contain filter properties.?\n\nIs there any API for this? How can libvirt driver access the\nfilter properties?\n?\nThanks.\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130807/e7678974/attachment.html>\n\n',NULL,NULL),('<1375887987.11505142.1406158967506.JavaMail.zimbra@zmail22.collab.prod.int.phx2.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 19:42:47',-14400,'2014-07-23 23:42:47',NULL,'[openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon	mode support','+1\n\nSent from my Android phone using TouchDown (www.nitrodesk.com)\n\n\n-----Original Message-----\nFrom: Yuriy Taraday [yorik.sar at gmail.com]\nReceived: Thursday, 24 Jul 2014, 0:42\nTo: OpenStack Development Mailing List [openstack-dev at lists.openstack.org]\nSubject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon	mode support\n\nHello.\n\nI\'d like to propose making a spec freeze exception for rootwrap-daemon-mode\nspec [1].\n\nIts goal is to save agents\' execution time by using daemon mode for\nrootwrap and thus avoiding python interpreter startup time as well as sudo\noverhead for each call. Preliminary benchmark shows 10x+ speedup of the\nrootwrap interaction itself.\n\nThis spec have a number of supporters from Neutron team (Carl and Miguel\ngave it their +2 and +1) and have all code waiting for review [2], [3], [4].\nThe only thing that has been blocking its progress is Mark\'s -2 left when\noslo.rootwrap spec hasn\'t been merged yet. Now that\'s not the case and code\nin oslo.rootwrap is steadily getting approved [5].\n\n[1] https://review.openstack.org/93889\n[2] https://review.openstack.org/82787\n[3] https://review.openstack.org/84667\n[4] https://review.openstack.org/107386\n[5]\nhttps://review.openstack.org/#/q/project:openstack/oslo.rootwrap+topic:bp/rootwrap-daemon-mode,n,z\n\n-- \n\nKind regards, Yuriy.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/40999955/attachment.html>\n-------------- next part --------------\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<CABocrW5a7gBZsCfEqi3taKmWSsHWBzSWESTCu7SX1RmjjTxaLQ@mail.gmail.com>',NULL),('<1375895960-sup-107@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-07 10:20:11',-25200,'2013-08-07 17:20:11',NULL,'[openstack-dev] [glance] Should image size/checksum be\n	immutable for active images?','Excerpts from stuart.mclaren\'s message of 2013-08-07 02:13:15 -0700:\n> \n> Typically its the not-very-interesting case of changing\n> the size from 0 to the real size after the data has uploaded.\n> \n> That happens before the image state transitions to \'active\'.\n> \n\nShouldn\'t the size be NULL, not 0, since it is unknown?\n\nIf that is the case, seems like you should be able to reliably allow a\ntransition from NULL to a value, but not from a value to anything else.\n\n\n','<alpine.DEB.2.00.1308071008010.14307@tc-unix2.ilo.cpqcorp.net>',NULL),('<1375897898-sup-1225@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-07 11:00:46',-25200,'2013-08-07 18:00:46',NULL,'[openstack-dev] Blueprint for Nova native image building','Excerpts from Ian McLeod\'s message of 2013-08-06 15:06:34 -0700:\n> On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:\n> > \n> > On 08/06/2013 03:46 PM, Russell Bryant wrote:\n> > > On 08/06/2013 12:20 PM, Russell Bryant wrote:\n> > >> On 08/06/2013 11:53 AM, Ian Mcleod wrote:\n> > >>> Hello,\n> > >>>\n> > >>> A blueprint has been registered regarding API additions to Nova to\n> > >>> enable the creation of base images from external OS install sources.\n> > >>> This provides a way to build images from scratch via native OS installer\n> > >>> tools using only the resources provided through Nova.  These images can\n> > >>> then be further customized by other tools that expect an existing image\n> > >>> as an input, such as disk image builder.\n> > >>>\n> > >>> Blueprint -\n> > >>> https://blueprints.launchpad.net/nova/+spec/base-image-creation\n> > >>>\n> > >>> Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI\n> > >>>\n> > >>> If this is a topic that interests you, please have a look (the spec is\n> > >>> not very long) and join the conversation.\n> > >>>\n> > >>> Please note that this blueprint follows on from proof of concept work\n> > >>> for native image building discussed on this list in April:\n> > >>>\n> > >>> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html\n> > >>\n> > >> Thanks of the update on this work.\n> > >>\n> > >> I see that your proof of concept shows how this can work as a tool\n> > >> outside of Nova:\n> > >>\n> > >> https://github.com/redhat-openstack/image-building-poc\n> > >>\n> > >> So, my biggest question is whether or not it makes sense for this to be\n> > >> a Nova feature or not.  If something can be implemented as a consumer of\n> > >> Nova, my default answer is that it should stay outside of nova until I\n> > >> am convinced otherwise.  :-)\n> \n> The proof of concept approach is limited to full-virt hypervisors.  It\'s\n> unclear to me if there\'s a way we can make this work for Xen-backed\n> installs without the kind of lower level access to the virt environment\n> that we\'ll get if we exist inside of Nova.\n> \n> More generally, it\'s likely that we\'ll have more flexibility to behave\n> in a sane/optimized manner based on backing hypervisor if the code is\n> inside of Nova.  For example, we\'ve talked about improving our detection\n> of a failed install by monitoring disk IO.\n> \n\nFlexibility can also be looked at as complexity. Complexity in Nova\nis expensive in many ways. But just poking a few more holes into\nNova via the API would be a simple and effective way to manage that\ncomplexity. Exposing some lower level things would get you the needed\npieces for your iPXE setup, and Monitoring disk IO is what ceilometer\ndoes. Is there something else non-obvious that you need inside Nova?\n\nIf you had an API to get at the hypervisor bits you need, and the\ncapability to monitor the progress, then I think your service can just\nrun standalone and be another endpoint for users, with its own client.\n\nAnother option is to write this as a resource plugin for Heat, as its job\nis to control multi-service operations. However, that will likely be an\nunpopular option until Heat grows an imperative API for things like this.\n\n\n','<1375826794.3010.25.camel@localhost.localdomain>',NULL),('<1375930667.57086.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 19:57:47',-25200,'2013-08-08 02:57:47',NULL,'[Openstack] Instance cannot access internet','Still cannot get out to the internet.??I change my subnet to192.168.100.0/24 which should be able to communicate now.\nBut I still have the same problem.?Could it be a problem with br-ex or br-int? Do I need to add my external NIC on my host to the br-ex bridge?\n\nOn the network topology view the gateway for the public network still does not display properly. Like it is missing.\n\n\nThis is my ovs-vsctl show results\n? ? Bridge br-ex\n\n? ? ? ? Port \"qg-1be1e87e-73\"\n? ? ? ? ? ? Interface \"qg-1be1e87e-73\"\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port br-ex\n? ? ? ? ? ? Interface br-ex\n? ? ? ? ? ? ? ? type: internal\n? ? Bridge br-int\n? ? ? ? Port br-int\n? ? ? ? ? ? Interface br-int\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port \"qvo2a3d522a-28\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"qvo2a3d522a-28\"\n? ? ? ? Port \"tap2a713313-38\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"tap2a713313-38\"\n? ? ? ? ? ? ? ? type: internal\n? ? ? ? Port \"qr-c1f31811-32\"\n? ? ? ? ? ? tag: 1\n? ? ? ? ? ? Interface \"qr-c1f31811-32\"\n? ? ? ? ? ? ? ? type: internal\n? ? ovs_version: \"1.4.3\"\n-----------------------------------------------------\n\nThanks again\n\n\n\nOn 2013/08/06, at 18:08, Rahul Sharma <rahulsharmaait at gmail.com> wrote:\n\n\nHi Jake,\n>\n>Is your public network having the IP-Address scheme 192.168.100.XX?\n>\n>From your configuration, I could see that you have allocated 192.168.100.96/27 from public network to openstack. That means, machines in range 192.168.100.96 to 192.168.100.127 would be able to communicate among each other. 192.168.100.1/24 or 192.168.100.1/27 won\'t be able to communicate with the public-ip address range(192.168.100.96/27) which you have specified because of subnetting.\n>\n>-Regards\n>Rahul Sharma\n>\n>\n>\n>\n>On Tue, Aug 6, 2013 at 6:34 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>I cant really see any other issue other than the missing gateway from my network topology view which should be set to 192.168.100.98\n>>\n>>\n>>\n>>\n>>From the host, I cannot ping GW IP 192.168.100.98 or instance floating IP 192.168.100.100 but I can ping the br-ex IP 192.168.100.1\n>>From the instance, I can ping the GW IP 10.0.0.1, another instance IP 10.0.0.4, but unable to ping anything outside of the 10.0.0.x network\n>>\n>>\n>>\n>>How can I check if there is a proper route from 10.0.0.X to 192.168.100.X in openstack? In other words, how can I check if the router was properly configured on the backend?\n>>\n>>\n>>Thank you!\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>________________________________\n>> From: Jake G. <dj_dark_junglist at yahoo.com>\n>>To: Somanchi Trinath-B39208 <B39208 at freescale.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Monday, August 5, 2013 7:29 PM\n>>Subject: Re: [Openstack] Instance cannot access internet\n>> \n>>\n>>\n>>I added a floating IP but still didn\'t fix the issue. Attached the screenshot to show I did.\n>>\n>>\n>>I have a feeling the issue is on my first picture where I said there is a missing IP. This could mean I dont have a route to the 192.168.100.x public network.?\n>>\n>>\n>>What do you think?\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>________________________________\n>> From: Somanchi Trinath-B39208 <B39208 at freescale.com>\n>>To: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Monday, August 5, 2013 7:06 PM\n>>Subject: RE: [Openstack] Instance cannot access internet\n>> \n>>\n>>\n>>As the Picture shows You haven?t assigned Floating IP ??? \n>>?\n>>Check the Floating IP assignment.\n>>?\n>>-\n>>Trinath Somanchi\n>>( trinath.somanchi at freescale.com )\n>>?\n>>From:Jake G. [mailto:dj_dark_junglist at yahoo.com] \n>>Sent: Monday, August 05, 2013 1:39 PM\n>>To: openstack at lists.openstack.org\n>>Subject: [Openstack] Instance cannot access internet\n>>?\n>>Hi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n>>?\n>>After creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n>>?\n>>I attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\n>>But I did set the gateway to 192.168.100.98\n>>?\n>>Thank you in advance.\n>>Jake\n>>\n>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to? ?  : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130807/470c60eb/attachment.html>\n\n','<BE5DFCB5-5C32-4B81-8B4E-5346C4CE4A58@yahoo.com>',NULL),('<1375932562.28093.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-07 20:29:22',-25200,'2013-08-08 03:29:22',NULL,'[Openstack] Instance cannot access internet','What do you mean by external interface? I access and get internet through eth0 on my host.\nSo does that mean I will use eth0?\n\nJust want to be sure cause some documents say I should add my private interface(eth1) to br-ex\n\nThank you!\n\n\n\n\n________________________________\n From: Ritesh Nanda <riteshnanda09 at gmail.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: nilesh pawar <nilesh56 at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, August 8, 2013 12:14 PM\nSubject: Re: [Openstack] Instance cannot access internet\n \n\n\nhello jake,\n\nCan\'t see that you have added any external interface to br-ex in ovs-vsctl show command output.\n\n\novs-vsctl add-br br-ex\novs-vsctl add-port br-ex <external interface>\nip link set up br-ex \n\n\n\n\nOn Mon, Aug 5, 2013 at 4:07 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\n- Yes My br-ex bridge has the IP 192.168.100.1 which I can ping from the 192.168.100.X network.\n>-I cannot ping 192.168.100.98 from the?the 192.168.100.X network and?Openstack Host\n>\n>\n>\n>\n>------ My openvswith layout-----\n>sudo ovs-vsctl show\n>3e02cdce-70d3-4f04-8f85-ec76aa63967b\n>? ? Bridge br-ex\n>? ? ? ? Port \"qg-8f16644e-43\"\n>? ? ? ? ? ? Interface \"qg-8f16644e-43\"\n>? ? ? ? ? ? ? ? type: internal\n>? ? ? ? Port br-ex\n>? ? ? ? ? ? Interface br-ex\n>? ? ? ? ? ? ? ? type: internal\n>? ? Bridge br-int\n>? ? ? ? Port br-int\n>? ? ? ? ? ? Interface br-int\n>? ? ? ? ? ? ? ? type: internal\n>? ? ? ? Port \"qvo2a3d522a-28\"\n>? ? ? ? ? ? tag: 1\n>? ? ? ? ? ? Interface \"qvo2a3d522a-28\"\n>? ? ? ? Port \"tap2a713313-38\"\n>? ? ? ? ? ? tag: 1\n>? ? ? ? ? ? Interface \"tap2a713313-38\"\n>? ? ? ? ? ? ? ? type: internal\n>? ? ? ? Port \"qr-504a0174-ce\"\n>? ? ? ? ? ? tag: 1\n>? ? ? ? ? ? Interface \"qr-504a0174-ce\"\n>? ? ? ? ? ? ? ? type: internal\n>----------------------------------------------\n>\n>\n>\n>\n>\n>________________________________\n> From: nilesh pawar <nilesh56 at gmail.com>\n>To: Jake G. <dj_dark_junglist at yahoo.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Monday, August 5, 2013 7:30 PM\n>Subject: Re: [Openstack] Instance cannot access internet\n> \n>\n>\n>Hi \n>can u try to ping 192.168.100.98.\n>Also is ur br-ext over quantum node having an IP.?\n>\n>\n>\n>\n>On Mon, Aug 5, 2013 at 1:39 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>Hi all! I have finally made some progress on networking, but now I have an issue with accessing the internet from an instance.?\n>>\n>>\n>>After creating an instance, it receives a private IP from DHCP services (including DNS servers) which I can see in the console. Trying to ping yahoo.com does not work but I can ping 10.0.0.1 which is the private network gateway.\n>>\n>>\n>>I attached some helpful screenshots. I did notice that in the Network Topology view, there is no gateway IP address for the Public network showing,\n>>But I did set the gateway to 192.168.100.98\n>>\n>>\n>>Thank you in advance.Jake\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>-- \n>Nilesh Pawar\n>? \n>Avoid the Gates of Hell.  Use Linux\n>\n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n\n-- \n\n?With Regards? \n\n?Ritesh Nanda\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130807/d484ab48/attachment.html>\n\n','<CAO5CbpDrUHJwPsXubm2ybN4VFHqJodm0Mw-f6_WCtNG2DegJHA@mail.gmail.com>',NULL),('<1375953283.95388.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-08 02:14:43',-25200,'2013-08-08 09:14:43',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer) feature?','Hi all!\nHow can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\nI used RDO to deploy Openstack on a single node.\n\n\nThank you! Jake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130808/c7791794/attachment.html>\n\n',NULL,NULL),('<1375958189.24389.184.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-08-08 11:36:29',3600,'2013-08-08 10:36:29',NULL,'[OpenStack Foundation] Foundation Board of Directors Meeting','On Wed, 2013-08-07 at 09:26 +0800, Jonathan Bryce wrote:\n> The OpenStack Foundation Board of Directors held a telephone meeting\n> on Tuesday August 6th at 9am PDT for about 2 hours.\n\nNice summary Jonathan. I\'ve posted a windbag version as usual:\n\nhttp://blogs.gnome.org/markmc/category/openstack-foundation-board-meeting/\n\nCheers,\nMark.\n\n\n\n','<A9AC4592-C69B-442D-AAC3-88BD86228DAE@openstack.org>',NULL),('<1375958384.24389.187.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 11:39:44',3600,'2013-08-08 10:39:44',NULL,'[openstack-dev] Osl and dangerous code merging','What do you mean by \"dangerous code merging\" in the subject? The body of\nyour mail doesn\'t make any reference to whatever \"danger\" you\'re seeing.\n\nOn Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote:\n> Hi All,\n> \n> Could somebody answer me, why we are merging oslo code in other projects\n> and don\'t use\n> git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)\n\nThe idea of using submodules has come a few times. I don\'t have a\nfundamental objection to it, except any time I\'ve seen submodules used\nin a project they\'ve been extremely painful for everyone involved.\n\nI\'d be happy to look at a demo of a submodule based system for projects\nto use code from oslo-incubator.\n\nMark.\n\n\n\n','<CAD85om2bM4b9rCdF_N_WeTuEqvZ1RvHAHoSWoYCdj2mhk_STSQ@mail.gmail.com>',NULL),('<1375958756.24389.192.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 11:45:56',3600,'2013-08-08 10:45:56',NULL,'[openstack-dev] Motion to start using Gerrit for TC votes','On Thu, 2013-08-08 at 10:55 +0200, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> >> * How do we handle proxies ? Giving temporary +2 to a non-TC member\n> >> sounds like a bit of pain\n> > \n> > I do not think we\'d need proxies anymore - as the vote wouldn\'t have to\n> > happen within the IRC meeting.\n> \n> Maybe it\'s just me, but I usually wait for the meeting to actually make\n> my mind about a motion. I\'m listening to the objections others raise and\n> sometimes discover they noticed something I missed, get convinced by\n> them and join them. That\'s why so many discussions end up with\n> consensus: a common TC position forms during the meeting.\n> \n> I think that\'s a very good thing, and I would hate to lose that.\n> Encouraging pre-meeting/async vote on the code review sounds like a step\n> in losing this consensus mode in which we operated until now.\n> \n> Proxying is not just about carrying a pre-determined vote and pasting it\n> on an IRC channel... It\'s about trusting someone to make the decision\n> you would have made if you had been present.\n> \n> So I\'d rather set up proxies with a temporary +2/-2 right than encourage\n> people to skip the meeting, the discussion and the opportunity to get TC\n> members consensus in our decisions.\n\nI think what Monty might be getting at is that TC decisions would no\nlonger happen by default with people voting at a particular TC meeting.\nRather a discussion would happen on the mailing list with people casting\ntheir votes in gerrit as the discussion evolves and, at some point, a\nproposal has enough +2 votes (and no -2 votes) such that it\'s\nautomatically considered passed.\n\nMaybe this could be a good default way for us to decide on things, but\nif we reach an impasse in gerrit or if a decision has been reached in\ngerrit by some required date, then we have a final TC IRC meeting and\nstandard meetbot vote to settle it.\n\nCheers,\nMark.\n\n\n\n','<52035D1E.3040602@openstack.org>',NULL),('<1375959946.24389.207.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 12:05:46',3600,'2013-08-08 11:05:46',NULL,'[openstack-dev] Osl and dangerous code merging','On Thu, 2013-08-08 at 11:49 +0100, Daniel P. Berrange wrote:\n> On Thu, Aug 08, 2013 at 11:39:44AM +0100, Mark McLoughlin wrote:\n> > What do you mean by \"dangerous code merging\" in the subject? The body of\n> > your mail doesn\'t make any reference to whatever \"danger\" you\'re seeing.\n> > \n> > On Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote:\n> > > Hi All,\n> > > \n> > > Could somebody answer me, why we are merging oslo code in other projects\n> > > and don\'t use\n> > > git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)\n> > \n> > The idea of using submodules has come a few times. I don\'t have a\n> > fundamental objection to it, except any time I\'ve seen submodules used\n> > in a project they\'ve been extremely painful for everyone involved.\n> > \n> > I\'d be happy to look at a demo of a submodule based system for projects\n> > to use code from oslo-incubator.\n> \n> submodules certainly could work as a way to avoid the cut+paste\n> approach we currently do. I agree though that they do add an\n> extra layer of pain & suffering for developers who don\'t fully\n> understand what they\'re doing. We use them in libvirt and try\n> to hide the pain behind clever scripts which attempt to keep\n> the submodule properly synced, but we still get pretty frequent\n> problem reports from devs who\'ve managed to get themselves into\n> a mess with the submodule state.\n\nYes, libvirt forms part of my negative experience of submodules :)\n\n> If we want to improve our interaction with oslo then IMHO more\n> effort should be spent on turning bits of oslo-incubator into\n> stable, standalone modules, removing the cut+paste need entirely.\n\nTotally. Code is not intended to live in oslo-incubator forever and\nwe\'re having increasing success in moving stuff out:\n\nhttps://wiki.openstack.org/wiki/Oslo#Libraries\n\nCheers,\nMark.\n\n\n\n','<20130808104923.GP14664@redhat.com>',NULL),('<1375960863.24389.212.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 12:21:03',3600,'2013-08-08 11:21:03',NULL,'[openstack-dev] Osl and dangerous code merging','On Thu, 2013-08-08 at 15:11 +0400, Boris Pavlovic wrote:\n> Mark, \n> \n> \n> >> What do you mean by \"dangerous code merging\" in the subject? The\n> body of\n> >> your mail doesn\'t make any reference to whatever \"danger\" you\'re\n> seeing.\n> \n> \n> \n> I mean that cut and paste approach is really unsafe. For example some\n> new member is able to change oslo code directly during syncing with\n> some project,\n>  and nobody will be able to catch such things.\n> \n> \n> I didn\'t catch any of such situation, but I saw a lot of attempts to\n> change openstack/common/* directly.\n> (and it is really close situation..)\n\nGot examples?\n\nIt\'s a reviewer\'s responsibility to enforce that openstack/commmon/*\ncode is just synced from oslo-incubator without modifications, but\nthere\'s always an element of trust in reviewing - you can\'t completely\nguard against people doing dumb or nefarious things.\n\nWe could come up with some automation where the oslo-incubator git\ncommit ID corresponding to each file is included in each project\'s repo\nand a test checks that the file does in fact correspond to that commit\nID. Needs someone willing to implement it.\n\n> >> The idea of using submodules has come a few times. I don\'t have a\n> >> fundamental objection to it, except any time I\'ve seen submodules\n> used\n> >> in a project they\'ve been extremely painful for everyone involved.\n> \n> \n> \n> oslo-incubator sync util and submodules solves the same problem,\n> almost in same way: \n> sync util -> copy paste code from <hash>\n> submodules -> just set <hash> of commit from what to use code\n> \n> \n> So I think the problem is not in submodules, problem is in approach of\n> common code for different projects.\n> But IMHO it is much better to have problems around creating common\n> code that is used by all projects, then to make\n> N different solutions for N different projects doing almost the same\n> things. \n> \n> \n> \n> \n> >> I\'d be happy to look at a demo of a submodule based system for\n> projects\n> >> to use code from oslo-incubator.\n> \n> \n> \n> Probably we should just try, and analyze what approach is better?\n\nSounds good. Just needs someone willing to implement it.\n\nCheers,\nMark.\n\n\n\n\n','<CAD85om1AXZsUbUA0jsMeVtCYefgqXsmZu6kmEd+jYyBmhLORuQ@mail.gmail.com>',NULL),('<1375967113.24389.217.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 14:05:13',3600,'2013-08-08 13:05:13',NULL,'[openstack-dev] Osl and dangerous code merging','On Thu, 2013-08-08 at 14:32 +0200, Flavio Percoco wrote:\n> On 08/08/13 11:49 +0100, Daniel P. Berrange wrote:\n> >On Thu, Aug 08, 2013 at 11:39:44AM +0100, Mark McLoughlin wrote:\n> >> What do you mean by \"dangerous code merging\" in the subject? The body of\n> >> your mail doesn\'t make any reference to whatever \"danger\" you\'re seeing.\n> >>\n> >> On Thu, 2013-08-08 at 14:16 +0400, Boris Pavlovic wrote:\n> >> > Hi All,\n> >> >\n> >> > Could somebody answer me, why we are merging oslo code in other projects\n> >> > and don\'t use\n> >> > git submodules (http://git-scm.com/book/en/Git-Tools-Submodules)\n> >>\n> >> The idea of using submodules has come a few times. I don\'t have a\n> >> fundamental objection to it, except any time I\'ve seen submodules used\n> >> in a project they\'ve been extremely painful for everyone involved.\n> >>\n> >> I\'d be happy to look at a demo of a submodule based system for projects\n> >> to use code from oslo-incubator.\n> >\n> >submodules certainly could work as a way to avoid the cut+paste\n> >approach we currently do. I agree though that they do add an\n> >extra layer of pain & suffering for developers who don\'t fully\n> >understand what they\'re doing. We use them in libvirt and try\n> >to hide the pain behind clever scripts which attempt to keep\n> >the submodule properly synced, but we still get pretty frequent\n> >problem reports from devs who\'ve managed to get themselves into\n> >a mess with the submodule state.\n> >\n> >If we want to improve our interaction with oslo then IMHO more\n> >effort should be spent on turning bits of oslo-incubator into\n> >stable, standalone modules, removing the cut+paste need entirely.\n> >\n> \n> +1\n> \n> It is always good to refresh the WHYs of the approach we\'re using but,\n> would it make sense to have a F.A.Q on Oslo\'s wiki explaining some of\n> the recurrent questions?\n\nI think a lot of it is covered on the wiki page, but feel free to add a\nnew entry to:\n\nhttps://wiki.openstack.org/wiki/Oslo#FAQs\n\nMark.\n\n\n\n','<20130808123256.GG16793@redhat.com>',NULL),('<1375972131.1519.24.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 09:28:51',-18000,'2013-08-08 14:28:51',NULL,'[openstack-dev] Blueprint for Nova native image building','On Wed, 2013-08-07 at 12:05 -0400, Russell Bryant wrote:\n> On 08/07/2013 10:46 AM, Daniel P. Berrange wrote:\n> > On Tue, Aug 06, 2013 at 12:20:00PM -0400, Russell Bryant wrote:\n> >> On 08/06/2013 11:53 AM, Ian Mcleod wrote:\n> >>> Hello,\n> >>>\n> >>> A blueprint has been registered regarding API additions to Nova to\n> >>> enable the creation of base images from external OS install sources.\n> >>> This provides a way to build images from scratch via native OS installer\n> >>> tools using only the resources provided through Nova.  These images can\n> >>> then be further customized by other tools that expect an existing image\n> >>> as an input, such as disk image builder.\n> >>>\n> >>> Blueprint -\n> >>> https://blueprints.launchpad.net/nova/+spec/base-image-creation\n> >>>\n> >>> Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI\n> >>>\n> >>> If this is a topic that interests you, please have a look (the spec is\n> >>> not very long) and join the conversation.\n> >>>\n> >>> Please note that this blueprint follows on from proof of concept work\n> >>> for native image building discussed on this list in April:\n> >>>\n> >>> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html\n> >>\n> >> Thanks of the update on this work.\n> >>\n> >> I see that your proof of concept shows how this can work as a tool\n> >> outside of Nova:\n> >>\n> >> https://github.com/redhat-openstack/image-building-poc\n> >>\n> >> So, my biggest question is whether or not it makes sense for this to be\n> >> a Nova feature or not.  If something can be implemented as a consumer of\n> >> Nova, my default answer is that it should stay outside of nova until I\n> >> am convinced otherwise.  :-)\n> >>\n> >> It sounds like this is mostly an extension to nova that implements a\n> >> series of operations that can be done just as well outside of Nova.  Are\n> >> there enhancements you are making or scenarios that won\'t work at all\n> >> unless it lives inside of Nova?\n> >>\n> >> If it doesn\'t end up on the server side, it could potentially be\n> >> implemented as an extension to novaclient.\n> > \n> > I think the key thing is that want to make sure we don\'t have all\n> > clients apps having to re-invent the wheel. The way the proof of\n> > concept was done as a standalone tool, would entail such wheel\n> > re-invention by any frontend to Nova like the \'nova\' cli and\n> > Horizon dashboard. Possibly you could mitigate that if you could\n> > actually put all the smarts in the python-novaclient library API\n> > so it was shared by all frontend apps.\n> \n> Yeah, I was thinking python-novaclient.  The \'nova\' command line tool is\n> just a wrapper around the library portion.\n> \n> > IIUC, though there is some state information that it is desirable\n> > to maintain while the images are being built. You\'d probably\n> > such state visible to all clients talking to the same nova instance,\n> > not hidden away in the client side where its only visible to that\n> > single frontend instance.\n> \n> That\'s an interesting point.  Do we care about having an image build\n> executing by the command line to show up in the UI as an image build?\n> Right now it\'s just going to be another nova instance.  We have to do it\n> on the server side to do any better.  I\'m not even sure it could\n> integrate well with Horizon doing it in python-novaclient.  I don\'t\n> think you could start another session and see the operation in progress.\n\nPerhaps it\'s worth revisiting the basic question:\n\nIs scratch image building (as distinct from run time customization) a\ntask that benefits from being exposed as a distinct activity available\nto a typical Horizon user or as structured resource available to other\nservices via REST?\n\nThe blueprint assumes the answer is yes.\n\nBut, is scratch image building in fact low level and infrequent enough\nto live happily as a standalone tool?  (Oz for Nova, if you will.)\n\n\n\n','<5202702C.4070509@redhat.com>',NULL),('<1375972154.1519.25.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 09:29:14',-18000,'2013-08-08 14:29:14',NULL,'[openstack-dev] Blueprint for Nova native image building','On Wed, 2013-08-07 at 11:00 -0700, Clint Byrum wrote:\n> Excerpts from Ian McLeod\'s message of 2013-08-06 15:06:34 -0700:\n> > On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:\n> > > \n> > > On 08/06/2013 03:46 PM, Russell Bryant wrote:\n> > > > On 08/06/2013 12:20 PM, Russell Bryant wrote:\n> > > >> On 08/06/2013 11:53 AM, Ian Mcleod wrote:\n> > > >>> Hello,\n> > > >>>\n> > > >>> A blueprint has been registered regarding API additions to Nova to\n> > > >>> enable the creation of base images from external OS install sources.\n> > > >>> This provides a way to build images from scratch via native OS installer\n> > > >>> tools using only the resources provided through Nova.  These images can\n> > > >>> then be further customized by other tools that expect an existing image\n> > > >>> as an input, such as disk image builder.\n> > > >>>\n> > > >>> Blueprint -\n> > > >>> https://blueprints.launchpad.net/nova/+spec/base-image-creation\n> > > >>>\n> > > >>> Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI\n> > > >>>\n> > > >>> If this is a topic that interests you, please have a look (the spec is\n> > > >>> not very long) and join the conversation.\n> > > >>>\n> > > >>> Please note that this blueprint follows on from proof of concept work\n> > > >>> for native image building discussed on this list in April:\n> > > >>>\n> > > >>> http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html\n> > > >>\n> > > >> Thanks of the update on this work.\n> > > >>\n> > > >> I see that your proof of concept shows how this can work as a tool\n> > > >> outside of Nova:\n> > > >>\n> > > >> https://github.com/redhat-openstack/image-building-poc\n> > > >>\n> > > >> So, my biggest question is whether or not it makes sense for this to be\n> > > >> a Nova feature or not.  If something can be implemented as a consumer of\n> > > >> Nova, my default answer is that it should stay outside of nova until I\n> > > >> am convinced otherwise.  :-)\n> > \n> > The proof of concept approach is limited to full-virt hypervisors.  It\'s\n> > unclear to me if there\'s a way we can make this work for Xen-backed\n> > installs without the kind of lower level access to the virt environment\n> > that we\'ll get if we exist inside of Nova.\n> > \n> > More generally, it\'s likely that we\'ll have more flexibility to behave\n> > in a sane/optimized manner based on backing hypervisor if the code is\n> > inside of Nova.  For example, we\'ve talked about improving our detection\n> > of a failed install by monitoring disk IO.\n> > \n> \n> Flexibility can also be looked at as complexity. Complexity in Nova\n> is expensive in many ways. But just poking a few more holes into\n> Nova via the API would be a simple and effective way to manage that\n> complexity. Exposing some lower level things would get you the needed\n> pieces for your iPXE setup, and Monitoring disk IO is what ceilometer\n> does. Is there something else non-obvious that you need inside Nova?\n\nIf Ceilometer can provide the disk IO data, and the Nova API can be\nexpanded to allow direct specification of a kernel, ramdisk _and_ kernel\ncommand line for Xen PV (and ideally, any other backing hypervisor that\nsupports direct boot), then we\'d likely have what we need to do this\noutside of Nova.\n\nThere may be some performance penalty that comes with adding an extra\n\"hop\" when moving around kernels and ramdisks.  (I\'m guessing the path\nwould become origin -> glance -> compute node versus, potentially,\norigin directly to compute node.)\n\n> \n> If you had an API to get at the hypervisor bits you need, and the\n> capability to monitor the progress, then I think your service can just\n> run standalone and be another endpoint for users, with its own client.\n> \n> Another option is to write this as a resource plugin for Heat, as its job\n> is to control multi-service operations. However, that will likely be an\n> unpopular option until Heat grows an imperative API for things like this.\n\nThat\'s an interesting idea.\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1375897898-sup-1225@fewbar.com>',NULL),('<1375972175.1519.26.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 09:29:35',-18000,'2013-08-08 14:29:35',NULL,'[openstack-dev] Blueprint for Nova native image building','On Wed, 2013-08-07 at 15:53 +0100, Daniel P. Berrange wrote:\n> On Wed, Aug 07, 2013 at 10:34:57AM -0400, Russell Bryant wrote:\n> > On 08/06/2013 06:06 PM, Ian McLeod wrote:\n> > > On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:\n> > > The proof of concept approach is limited to full-virt hypervisors.  It\'s\n> > > unclear to me if there\'s a way we can make this work for Xen-backed\n> > > installs without the kind of lower level access to the virt environment\n> > > that we\'ll get if we exist inside of Nova.\n> > \n> > Can you write up some more detail on this point?\n> > \n> > > More generally, it\'s likely that we\'ll have more flexibility to behave\n> > > in a sane/optimized manner based on backing hypervisor if the code is\n> > > inside of Nova.  For example, we\'ve talked about improving our detection\n> > > of a failed install by monitoring disk IO.\n> > \n> > If we were to service-ify this, it would be interesting to look into\n> > using Ceilometer for monitoring.\n> \n> NB, \n> \n> > \n> > >>>>\n> > >>>> It sounds like this is mostly an extension to nova that implements a\n> > >>>> series of operations that can be done just as well outside of Nova.  Are\n> > >>>> there enhancements you are making or scenarios that won\'t work at all\n> > >>>> unless it lives inside of Nova?\n> > > \n> > > Other than the Xen issue above, I\'m not sure there\'s anything that\n> > > simply won\'t work at all, though there are things that perhaps won\'t\n> > > scale as well or won\'t run as quickly.\n> > \n> > Why would it be slower?\n\nI\'m thinking specifically about the task of constructing the boot\nenvironment used to launch the installer.  We had envisioned doing this\ndirectly on the compute node, potentially avoiding adding a \"hop\"\nthrough glance for the kernel and ramdisk (or the bootable install image\nwhere appropriate).\n\n> \n> I don\'t think there\'s any particular reason why Xen should be slower\n> or less scalable from an architectural POV here. Any perf differences\n> would be just those inherant to the hypervisor platform in question.\n> \n> > How about scale?  Just the increased API load?  I wouldn\'t expect this\n> > to be something done frequently.  It\'s more API calls, but removes a\n> > long running task from inside nova (longer than anything else that\n> > exists in nova today).\n\nAgain, I\'m thinking mainly of the load associated with preparing the\ninstaller environment, which would be farmed out to the compute nodes\nrather than happening on either the client or the node hosting the image\nbuilding service API.\n\n> \n> In terms of load, all the heavy I/O & CPU burn would be in the context\n> of a VM running in nova. So I don\'t think this approach to image building\n> is would be introducing any new architectural scalability problems. Indeed\n> this is the main attraction of running the OS installer inside a VM managed\n> by Nova - the image builder just takes advantage of all Nova\'s support for\n> resource manager/VM scheduler placement etc.\n> \n> > >> Yes to everything Russel said. I\'d like to see the tool be standalone.\n> > >> Then, if there is a desire to provide the ability to run it via an api,\n> > >> the tool could be consumed (similar discussions have happened around\n> > >> putting diskimage-builder behind a service as well)\n> > >>\n> > >> That said - if we did service-ify the tool, wouldn\'t glance be a more\n> > >> appropriate place for that sort of thing?\n> > > \n> > > Possibly, though the proof of concept (and we hope our proposed\n> > > nova-based re-implementation) can build both glance images and cinder\n> > > volume backed images.\n> > \n> > I like this idea (glance seeming to make more sense conceptually).\n> \n> I\'ve gone back & forth with thinking about whether it makes sense in\n> glance or nova, and don\'t have a strong opinion either way really.\n> From a technical POV I think it could be made to work in either without\n> much bother.\n> \n> > It seems like the main sticking point is whether or not it can be made\n> > to work for all (or most) hypervisors from outside of nova.  Can we dig\n> > into this point a bit deeper?\n> \n> I think that it ought to be possible to make it work for any hypervisor\n> that is doing full-machine virt (ie not container drivers like LXC). We\n> may not have sufficient APIs, or we may not have enough features implemented\n> in some virt drivers, but that\'s just a case of donkey work, rather than\n> any architectural blocker.\n> \n> Daniel\n\n\n\n\n','<20130807145355.GT2464@redhat.com>',NULL),('<1375988153-sup-8474@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 12:03:36',-25200,'2013-08-08 19:03:36',NULL,'[openstack-dev] Python overhead for rootwrap','Excerpts from Joshua Harlow\'s message of 2013-08-08 10:39:38 -0700:\n> A very neat option. I hadn\'t thought about tasks having policies on them.\n> \n> It does seem like a correct way to go, and a way that could help in some of the rootwrap area.\n> \n> Good idea jay, the taskflow devs I think are starting to consider this idea and how it might be possible.\n> \n> There is as u said a long road, but I think this is just the way it goes, for better or worse.\n> \n\nThis is a neat option, and it is actually quite similar to the proposed\n\"use DBUS\" solution.\n\nBasically we can achieve the goal two similar ways:\n\n1) Write a python taskflow worker that runs as root and exposes\n\"run_XXXCMDXXX_as_root_on_node_105058\" as a capability which the\nnova-compute will then eventually ask for. This will require security\nin taskflow that has perhaps not been considered up until now.\n\n2) DBUS enable iptables/brctl/ovs/etc. -- Longer time to develop,\nbut tighter security and more universal benefit/contribution from the\ngreater Linux community.\n\nDoing these are not mutually exclusive. We can do 1 and then improve\nperformance and security by attacking the pieces that make sense for\nsolution 2 (thus relieving the need for run_XXXCMDXXX_as_root).\n\n\n','<CE292582.42A17%harlowja@yahoo-inc.com>',NULL),('<1375988709-sup-2881@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 12:08:51',-25200,'2013-08-08 19:08:51',NULL,'[openstack-dev] Blueprint for Nova native image building','Excerpts from Ian McLeod\'s message of 2013-08-08 07:29:14 -0700:\n> On Wed, 2013-08-07 at 11:00 -0700, Clint Byrum wrote:\n> > Flexibility can also be looked at as complexity. Complexity in Nova\n> > is expensive in many ways. But just poking a few more holes into\n> > Nova via the API would be a simple and effective way to manage that\n> > complexity. Exposing some lower level things would get you the needed\n> > pieces for your iPXE setup, and Monitoring disk IO is what ceilometer\n> > does. Is there something else non-obvious that you need inside Nova?\n> \n> If Ceilometer can provide the disk IO data, and the Nova API can be\n> expanded to allow direct specification of a kernel, ramdisk _and_ kernel\n> command line for Xen PV (and ideally, any other backing hypervisor that\n> supports direct boot), then we\'d likely have what we need to do this\n> outside of Nova.\n> \n> There may be some performance penalty that comes with adding an extra\n> \"hop\" when moving around kernels and ramdisks.  (I\'m guessing the path\n> would become origin -> glance -> compute node versus, potentially,\n> origin directly to compute node.)\n> \n\nThis hop penalty is already paid every time an image is booted for the\nfirst time on a compute host. OpenStack has a vested interest in making\nthis as fast as possible. Another option is to look at what Ironic is\ndoing to address the same problem.\n\n\n','<1375972154.1519.25.camel@localhost.localdomain>',NULL),('<1375991193-sup-7823@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 13:16:22',-25200,'2013-08-08 20:16:22',NULL,'[openstack-dev] [Heat] event table is a ticking time bomb','Last night while reviewing a feature which would add more events to the\nevent table, it dawned on me that the event table really must be removed.\n\nhttps://bugs.launchpad.net/heat/+bug/1209492\n\ntl;dr: users can write an infinite number of rows to the event table at\na fairly alarming rate just by creating and updating a very large stack\nthat has no resources that cost any time or are even billable (like an\nautoscaling launch configuration).\n\nThe table has no purge function, so the only way to clear out old events\nis to delete the stack, or manually remove them directly in the database.\n\nWe\'ve all been through this before, logging to a database seems great\nuntil you actually do it.\n\nI have some ideas for how to solve it, but I wanted to get a wider\naudience:\n\n1) Make the event list a ring buffer. Have rows 0 - $MAX_BUFFER_SIZE in\neach stack, and simply write each new event to the next open position,\nwrapping at $MAX_BUFFER_SIZE. Pros: little change to current code,\njust need an offset column added and code that will properly wrap to 0\nat $MAX_BUFFER_SIZE. Cons: still can incur heavy transactional load on\nthe database server.A\n\n1.b) Same, but instead of rows, just maintain a blob and append the rows\nas json list. Lowers transactional load but would push some load onto\nthe API servers and such to parse these out, and would make pagination\nchallenging. Blobs also can be a drain on DB server performance.\n\n2) Write a purge script. Delete old ones. Pros: No code change, just\nnew code to do purging. Cons: same as 1, plus more vulnerability to an\naggressive attacker who can fit a lot of data in between purges. Also\nlarge scale deletes can be really painful (see: keystone sql token\nbackend).\n\n3) Log events to Swift. I can\'t seem to find information on how/if\nappending works there. Tons of tiny single-row files is an option, but I\nwant to hear from people with more swift knowledge if that is a viable,\nperformant option. Pros: Scale to the moon. Can charge tenant for usage\nand let them purge events as needed. Cons: Adds swift as a requirement\nof Heat.\n\n4) Provide a way for users to receive logs via HTTP POST. Pros: Simple\nand punts the problem to the users. Cons: users will be SoL if they\ndon\'t have a place to have logs posted to.\n\n5) Provide a way for users to receive logs via messaging service like\nMarconi.  Pros/Cons: same as HTTP, but perhaps a little more confusing\nand ambitious given Marconi\'s short existence.\n\n6) Provide a pluggable backend for logging. This seems like the way most\nOpenStack projects solve these issues, which is to let the deployers\nchoose and/or provide their own way to handle a sticky problem. Pros:\nSimple and flexible for the future. Cons: Would require writing at least\none backend provider that does what the previous 5 options suggest.\n\nTo be clear: Heat cannot really exist without this, as it is the only way\nto find out what your stack is doing or has done.\n\n\n',NULL,NULL),('<1375998772.24389.273.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 22:52:52',3600,'2013-08-08 21:52:52',NULL,'[openstack-dev] [Oslo] oslo.version and pbr','On Sun, 2013-08-04 at 13:41 -0400, Monty Taylor wrote:\n> Hey all!\n> \n> Currently, there is runtime version handling code in pbr. It\'s been a\n> cause of concern for some folks because it means that pbr becomes a\n> runtime rather than just a build time dependency - so the suggestion has\n> come across that we split it out into its own library.\n> \n> This becomes even more important, because I\'d also like to take the\n> extra version handling code that\'s in nova (that allows for version\n> override files in /etc that the distributors can drop in) and add it to\n> the mix. That code as currently written depends on oslo.config - and I\n> definitely do not want to make pbr depend on oslo.config.\n> \n> So - the proposal is:\n> \n> - make an oslo.version library based on the current code in pbr\n> - bring the nova version code over, and keep its depend on oslo.config\n> \n> That way, pbr can go back to being a build-time need - and the people\n> who want the runtime version discovery code probably won\'t mind also\n> consuming oslo.config.\n> \n> Also, now that pbr doesn\'t need setuptools-git or d2to1 any more, I\n> think as soon as the version code is split into oslo.version, I\'d like\n> to release a 1.0 of pbr and call it both done and API stable.\n> \n> Sound decent to everyone?\n\nIt looks like you\'ve tweaked your thinking on this, since oslo.version\ncopies the \"look for a config file in some well known directories\" code\ninto oslo.version:\n\n  https://github.com/emonty/oslo.version/\n\nThat\'s totally cool with me. Depending on oslo.config just for\nfind_config_files() would be gratuitous.\n\nThanks for doing this.\n\nCheers,\nMark.\n\n\n\n','<51FE9264.6030405@inaugust.com>',NULL),('<1376001320.24389.285.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 23:35:20',3600,'2013-08-08 22:35:20',NULL,'[openstack-dev] Change in openstack/keystone[master]: Implement\n domain specific Identity backends','Hi Henry,\n\nOn Tue, 2013-08-06 at 22:10 +0100, Henry Nash wrote:\n> Hi Mark,\n> \n> Of particular interest are your views on the changes to keystone/common/config.py.  The requirement is that we need to be able to instantiate multiple conf objects (built from different sets of config files).  We tried two approaches to this:\n> \n> https://review.openstack.org/#/c/39530/11 which attempts to keep the current keystone config helper apps (register_bool() etc.) by passing on the conf instance, and\n> https://review.openstack.org/#/c/39530/12 which removes these helper apps and just calls the methods on the conf itself (conf.register_opt())\n> \n> Both functionally work, but interested in your views on both approaches.\n\nDefinitely prefer more of the latter, since I\'ve proposed it myself\npreviously :)\n\n  https://review.openstack.org/4547\n\nThere are some common patterns of cfg usage which keystone is unusual in\nnot adopting:\n\n  - declare options as a list, or multiple lists at the top of modules:\n\n      foo_opts = [\n          cfg.StrOpt(\'bar\'),\n          cfg.ListOpt(\'foo\'),\n      ]\n\n  - declare options in the modules in which they\'re used, rather than \n    having a single module which declares all options for the project. \n    See this blueprint:\n \n      https://blueprints.launchpad.net/nova/+spec/scope-config-opts\n\n    for where I moved all of the option declarations out of the \n    nova.config module.\n\n    I recall this being a problem for keystone recently - I think it \n    may have been a keystone.middleware module imported keystone.config \n    which defined logging options which may have been defined \n    elsewhere. This kind of thing is easier to avoid if the config \n    options are scoped to the module which uses them.\n\n  - iff the code in this module needs to only work with cfg.CONF, then \n    register the options with cfg.CONF at the top of the module:\n\n      CONF = cfg.CONF\n      CONF.register_opts(foo_opts)\n\n    otherwise register the options before they\'re used:\n\n      def bar(conf, ..):\n          ...\n          conf.register_opts(foo_opts)\n          if conf.foo:\n              ...\n\n      def blaa(conf, ..):\n          ...\n          conf.register_opts(foo_opts)\n          if conf.bar:\n              ...\n\nHope that helps,\nMark.\n\n\n\n','<074729CE-981E-443B-BDB2-AD543F5A8375@linux.vnet.ibm.com>',NULL),('<1376002383.976618344@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-08-08 17:53:03',-18000,'2013-08-08 22:53:03',NULL,'[openstack-community] Going to USENIX LISA in Washington DC, Nov 3-8?','\n\n \nIf you are attending USENIX LISA in November and would be willing to spend an hour or two in the hackspace, please reply to kathyc at openstack.org.  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130808/448a372a/attachment.html>\n\n',NULL,NULL),('<1376026882.91253.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-08 22:41:22',-25200,'2013-08-09 05:41:22',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer)\n	feature?','I have enabled LBaas on my openstack, but after adding a pool, vip, members, and monitor successfully I am still unable to get load balancing working.?\nI found this blog to help me so far?http://kimizhang.wordpress.com/2013/08/08/openstack-grizzly-quantum-advanced-features-2/\n\nWhen I run # ps -ef | grep haproxy I dont get much:?\nroot 27508 2718 0 14:16 pts/1 00:00:00 grep haproxy\n\nMy logs show an issue with haproxy:\n\nRuntimeError:?\nCommand: [\'sudo\', \'quantum-rootwrap\', \'/etc/quantum/rootwrap.conf\', \'ip\', \'netns\', \'exec\', \'qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029\', \'haproxy\', \'-f\', \'/var\n/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf\', \'-p\', \'/var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\']\nExit code: 255\nStdout: \'\'\nStderr: \'exec of haproxy failed: No such file or directory\\n\'\n2013-08-09 14:16:17 ? ?ERROR [quantum.plugins.services.agent_loadbalancer.agent.manager] Unable to refresh device for pool: e10951cd-4cca-4ba4-acc0-0ccde6817029\nTraceback (most recent call last):\n? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/agent/manager.py\", line 189, in refresh_device\n? ? self.driver.create(logical_config)\n? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 48, in create\n? ? self._spawn(logical_config)\n? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 70, in _spawn\n? ? ns.netns.execute(cmd)\n? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py\", line 414, in execute\n? ? check_exit_code=check_exit_code)\n? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py\", line 61, in execute\n? ? raise RuntimeError(m)\n\nAny ideas?\n\n\n________________________________\n From: Eugene Nikanorov <enikanorov at mirantis.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, August 8, 2013 7:04 PM\nSubject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n \n\n\nHi Jake,\n\nRegarding lbaas in grizzly working on RHEL/Centos - it may be problematic as host operation system must support network namespaces.?\nIf you do have support for network namespaces then you need to do the following steps to setup lbaas service in quantum:\n\n\n1) specify lbaas plugin in quantum.conf:\nservice_plugins= lbaas_plugin_classpath.\ncheck quantum/plugins/services/agent_loadbalancer/plugin.py for correct path as currently the name and path has changed.\n\n2) to enable lbaas service in horizon you need to do the following:\nadd the following piece of code to?horizon/openstack_dashboard/local/local_settings.py :\n\nOPENSTACK_QUANTUM_NETWORK = {\n? ? \'enable_lb\': False\n}\n\n3) start quantum-lbaas-agent on the host providing quantum.conf and lbaas-agent.ini. lbaas-agent.ini should reflect core plugin configuration (should have proper interface driver)\n\nNote that if host os has no namespace support, all of above will work (e.g. REST API will be functional), but you would not be able to deploy loadbalancer as lbaas agent can only work with namespaces.\n\nThanks,\nEugene.\n\n\n\nOn Thu, Aug 8, 2013 at 1:14 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nHi all!\n>How can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\n>I used RDO to deploy Openstack on a single node.\n>\n>\n>\n>Thank you! Jake\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130808/864090a3/attachment.html>\n\n','<CAJfiwOSV2DCQpSM_z8eowi8mtG+_ijFPRziD=_-kdw39RCB7vA@mail.gmail.com>',NULL),('<1376034277.27241.YahooMailNeo@web28803.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-08-09 08:44:37',3600,'2013-08-09 07:44:37',NULL,'[openstack-community] First OpenStack Bucharest meet up in Romania','Hello everyone,\n\n\nWe are pleased to announce the first meetup for the Bucharest OpenStack UserGroup in Romania.\n\nIt is held on Monday - August 12, 2013 5:00 - 7:00 (CEST - GMT+2) live and Google hangout\n\nMore details at:\nhttp://www.meetup.com/Openstack-Bucharest/\n\nFeel free to join,?\n\n\nThanks & Best Regards,\nAdrian Moti\n+40755069103\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130809/602ef8e4/attachment.html>\n\n','<CAOehM_V5nL2PUYRvf692m74p3vqA-s49aFjZOfTgA_93NJBWgA@mail.gmail.com>',NULL),('<1376034622.12186.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-09 00:50:22',-25200,'2013-08-09 07:50:22',NULL,'[Openstack] Baremetal Provisioning for Openstack','Hi all,\n\nHow can I install/enable the baremetal provisioning feature for Openstack Grizzly? Any good resources, links??\n\nMy host is a single node CentOS fully working Openstack server installed with RDO packstack.\n\n\nThank you,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130809/6a2b3fe1/attachment.html>\n\n',NULL,NULL),('<1376037045.38267.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-09 01:30:45',-25200,'2013-08-09 08:30:45',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer)\n	feature?','Good call!\nLooks like i did but the service wont start. Do you have a sample haproxy.cfg file that will work with Openstack?\n\nThank you\n\n\n________________________________\n From: Eugene Nikanorov <enikanorov at mirantis.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 9, 2013 3:08 PM\nSubject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n \n\n\nDo you have haproxy package installed on your host?\n\n\n\nOn Fri, Aug 9, 2013 at 9:41 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nI have enabled LBaas on my openstack, but after adding a pool, vip, members, and monitor successfully I am still unable to get load balancing working.?\n>I found this blog to help me so far?http://kimizhang.wordpress.com/2013/08/08/openstack-grizzly-quantum-advanced-features-2/\n>\n>\n>When I run # ps -ef | grep haproxy I dont get much:?\n>root 27508 2718 0 14:16 pts/1 00:00:00 grep haproxy\n>\n>\n>My logs show an issue with haproxy:\n>\n>\n>RuntimeError:?\n>Command: [\'sudo\', \'quantum-rootwrap\', \'/etc/quantum/rootwrap.conf\', \'ip\', \'netns\', \'exec\', \'qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029\', \'haproxy\', \'-f\', \'/var\n>/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf\', \'-p\', \'/var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\']\n>Exit code: 255\n>Stdout: \'\'\n>Stderr: \'exec of haproxy failed: No such file or directory\\n\'\n>2013-08-09 14:16:17 ? ?ERROR [quantum.plugins.services.agent_loadbalancer.agent.manager] Unable to refresh device for pool: e10951cd-4cca-4ba4-acc0-0ccde6817029\n>Traceback (most recent call last):\n>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/agent/manager.py\", line 189, in refresh_device\n>? ? self.driver.create(logical_config)\n>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 48, in create\n>? ? self._spawn(logical_config)\n>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 70, in _spawn\n>? ? ns.netns.execute(cmd)\n>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py\", line 414, in execute\n>? ? check_exit_code=check_exit_code)\n>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py\", line 61, in execute\n>? ? raise RuntimeError(m)\n>\n>\n>Any ideas?\n>\n>\n>\n>________________________________\n> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>To: Jake G. <dj_dark_junglist at yahoo.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, August 8, 2013 7:04 PM\n>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n> \n>\n>\n>Hi Jake,\n>\n>\n>Regarding lbaas in grizzly working on RHEL/Centos - it may be problematic as host operation system must support network namespaces.?\n>If you do have support for network namespaces then you need to do the following steps to setup lbaas service in quantum:\n>\n>\n>\n>1) specify lbaas plugin in quantum.conf:\n>service_plugins= lbaas_plugin_classpath.\n>check quantum/plugins/services/agent_loadbalancer/plugin.py for correct path as currently the name and path has changed.\n>\n>\n>2) to enable lbaas service in horizon you need to do the following:\n>add the following piece of code to?horizon/openstack_dashboard/local/local_settings.py :\n>\n>\n>OPENSTACK_QUANTUM_NETWORK = {\n>? ? \'enable_lb\': False\n>}\n>\n>\n>3) start quantum-lbaas-agent on the host providing quantum.conf and lbaas-agent.ini. lbaas-agent.ini should reflect core plugin configuration (should have proper interface driver)\n>\n>\n>Note that if host os has no namespace support, all of above will work (e.g. REST API will be functional), but you would not be able to deploy loadbalancer as lbaas agent can only work with namespaces.\n>\n>\n>Thanks,\n>Eugene.\n>\n>\n>\n>On Thu, Aug 8, 2013 at 1:14 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>Hi all!\n>>How can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\n>>I used RDO to deploy Openstack on a single node.\n>>\n>>\n>>\n>>Thank you! Jake\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130809/c86a51cc/attachment.html>\n\n','<CAJfiwOT=ZhAJeS=HYuVBk60EH9ZLL24epCOs61cP=uoObdDypw@mail.gmail.com>',NULL),('<1376037542.75678.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-09 01:39:02',-25200,'2013-08-09 08:39:02',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer)\n	feature?','Yes this is my Kernel> ?2.6.32-358.114.1.openstack.el6.x86_64\nand I enable:?\n\nuse_namespaces = True\n\novs_use_veth = True\n\nin?/etc/quantum/dhcp_agent.ini and etc/quantum/l3_agent.ini\n\n\n\n\n________________________________\n From: Eugene Nikanorov <enikanorov at mirantis.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 9, 2013 5:33 PM\nSubject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n \n\n\nJake, haproxy.cfg is created by lbaas agent when you deploy an instance.\nAre you sure your host os has namespace support?\n\nEugene.\n\n\n\nOn Fri, Aug 9, 2013 at 12:30 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nGood call!\n>Looks like i did but the service wont start. Do you have a sample haproxy.cfg file that will work with Openstack?\n>\n>\n>Thank you\n>\n>\n>\n>________________________________\n> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>To: Jake G. <dj_dark_junglist at yahoo.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, August 9, 2013 3:08 PM\n>\n>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n> \n>\n>\n>Do you have haproxy package installed on your host?\n>\n>\n>\n>On Fri, Aug 9, 2013 at 9:41 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>I have enabled LBaas on my openstack, but after adding a pool, vip, members, and monitor successfully I am still unable to get load balancing working.?\n>>I found this blog to help me so far?http://kimizhang.wordpress.com/2013/08/08/openstack-grizzly-quantum-advanced-features-2/\n>>\n>>\n>>When I run # ps -ef | grep haproxy I dont get much:?\n>>root 27508 2718 0 14:16 pts/1 00:00:00 grep haproxy\n>>\n>>\n>>My logs show an issue with haproxy:\n>>\n>>\n>>RuntimeError:?\n>>Command: [\'sudo\', \'quantum-rootwrap\', \'/etc/quantum/rootwrap.conf\', \'ip\', \'netns\', \'exec\', \'qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029\', \'haproxy\', \'-f\', \'/var\n>>/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf\', \'-p\', \'/var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\']\n>>Exit code: 255\n>>Stdout: \'\'\n>>Stderr: \'exec of haproxy failed: No such file or directory\\n\'\n>>2013-08-09 14:16:17 ? ?ERROR [quantum.plugins.services.agent_loadbalancer.agent.manager] Unable to refresh device for pool: e10951cd-4cca-4ba4-acc0-0ccde6817029\n>>Traceback (most recent call last):\n>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/agent/manager.py\", line 189, in refresh_device\n>>? ? self.driver.create(logical_config)\n>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 48, in create\n>>? ? self._spawn(logical_config)\n>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 70, in _spawn\n>>? ? ns.netns.execute(cmd)\n>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py\", line 414, in execute\n>>? ? check_exit_code=check_exit_code)\n>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py\", line 61, in execute\n>>? ? raise RuntimeError(m)\n>>\n>>\n>>Any ideas?\n>>\n>>\n>>\n>>________________________________\n>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Thursday, August 8, 2013 7:04 PM\n>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>> \n>>\n>>\n>>Hi Jake,\n>>\n>>\n>>Regarding lbaas in grizzly working on RHEL/Centos - it may be problematic as host operation system must support network namespaces.?\n>>If you do have support for network namespaces then you need to do the following steps to setup lbaas service in quantum:\n>>\n>>\n>>\n>>1) specify lbaas plugin in quantum.conf:\n>>service_plugins= lbaas_plugin_classpath.\n>>check quantum/plugins/services/agent_loadbalancer/plugin.py for correct path as currently the name and path has changed.\n>>\n>>\n>>2) to enable lbaas service in horizon you need to do the following:\n>>add the following piece of code to?horizon/openstack_dashboard/local/local_settings.py :\n>>\n>>\n>>OPENSTACK_QUANTUM_NETWORK = {\n>>? ? \'enable_lb\': False\n>>}\n>>\n>>\n>>3) start quantum-lbaas-agent on the host providing quantum.conf and lbaas-agent.ini. lbaas-agent.ini should reflect core plugin configuration (should have proper interface driver)\n>>\n>>\n>>Note that if host os has no namespace support, all of above will work (e.g. REST API will be functional), but you would not be able to deploy loadbalancer as lbaas agent can only work with namespaces.\n>>\n>>\n>>Thanks,\n>>Eugene.\n>>\n>>\n>>\n>>On Thu, Aug 8, 2013 at 1:14 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>\n>>Hi all!\n>>>How can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\n>>>I used RDO to deploy Openstack on a single node.\n>>>\n>>>\n>>>\n>>>Thank you! Jake\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130809/707fbca5/attachment.html>\n\n','<CAJfiwOQz584=Cf0SHHHR3YsRP3bZX4OWVz2UM896y-=r+E76jQ@mail.gmail.com>',NULL),('<1376063280-sup-6944@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-09 08:56:31',-25200,'2013-08-09 15:56:31',NULL,'[openstack-dev] [Heat] event table is a ticking time bomb','Excerpts from Sandy Walsh\'s message of 2013-08-09 06:16:55 -0700:\n> \n> On 08/08/2013 11:36 PM, Angus Salkeld wrote:\n> > On 08/08/13 13:16 -0700, Clint Byrum wrote:\n> >> Last night while reviewing a feature which would add more events to the\n> >> event table, it dawned on me that the event table really must be removed.\n> > \n> > \n> >>\n> >> https://bugs.launchpad.net/heat/+bug/1209492\n> >>\n> >> tl;dr: users can write an infinite number of rows to the event table at\n> >> a fairly alarming rate just by creating and updating a very large stack\n> >> that has no resources that cost any time or are even billable (like an\n> >> autoscaling launch configuration).\n> >>\n> >> The table has no purge function, so the only way to clear out old events\n> >> is to delete the stack, or manually remove them directly in the database.\n> >>\n> >> We\'ve all been through this before, logging to a database seems great\n> >> until you actually do it.\n> >>\n> >> I have some ideas for how to solve it, but I wanted to get a wider\n> >> audience:\n> >>\n> >> 1) Make the event list a ring buffer. Have rows 0 - $MAX_BUFFER_SIZE in\n> >> each stack, and simply write each new event to the next open position,\n> >> wrapping at $MAX_BUFFER_SIZE. Pros: little change to current code,\n> >> just need an offset column added and code that will properly wrap to 0\n> >> at $MAX_BUFFER_SIZE. Cons: still can incur heavy transactional load on\n> >> the database server.A\n> >>\n> >> 1.b) Same, but instead of rows, just maintain a blob and append the rows\n> >> as json list. Lowers transactional load but would push some load onto\n> >> the API servers and such to parse these out, and would make pagination\n> >> challenging. Blobs also can be a drain on DB server performance.\n> >>\n> >> 2) Write a purge script. Delete old ones. Pros: No code change, just\n> >> new code to do purging. Cons: same as 1, plus more vulnerability to an\n> >> aggressive attacker who can fit a lot of data in between purges. Also\n> >> large scale deletes can be really painful (see: keystone sql token\n> >> backend).\n> >>\n> >> 3) Log events to Swift. I can\'t seem to find information on how/if\n> >> appending works there. Tons of tiny single-row files is an option, but I\n> >> want to hear from people with more swift knowledge if that is a viable,\n> >> performant option. Pros: Scale to the moon. Can charge tenant for usage\n> >> and let them purge events as needed. Cons: Adds swift as a requirement\n> >> of Heat.\n> >>\n> >> 4) Provide a way for users to receive logs via HTTP POST. Pros: Simple\n> >> and punts the problem to the users. Cons: users will be SoL if they\n> >> don\'t have a place to have logs posted to.\n> >>\n> >> 5) Provide a way for users to receive logs via messaging service like\n> >> Marconi.  Pros/Cons: same as HTTP, but perhaps a little more confusing\n> >> and ambitious given Marconi\'s short existence.\n> >>\n> >> 6) Provide a pluggable backend for logging. This seems like the way most\n> >> OpenStack projects solve these issues, which is to let the deployers\n> >> choose and/or provide their own way to handle a sticky problem. Pros:\n> >> Simple and flexible for the future. Cons: Would require writing at least\n> >> one backend provider that does what the previous 5 options suggest.\n> >>\n> >> To be clear: Heat cannot really exist without this, as it is the only way\n> >> to find out what your stack is doing or has done.\n> > \n> > btw Clint I have ditched that \"Recorder\" patch as Ceilometer is\n> > getting a Alarm History api soon, so we can defer to that for that\n> > functionality (alarm transitions).\n> > \n> > But we still need a better way to record events/logs for the user.\n> > So I make this blueprint a while ago:\n> > https://blueprints.launchpad.net/heat/+spec/user-visible-logs\n> > \n> > I am becomming more in favor of user options rather than deployer\n> > options if possible. So provide resources for Marconi, Meniscus and\n> > what ever...\n> > Although what is nice about Marconi is you could then hook up what\n> > ever you want to it.\n> \n> Logs are one thing (and Meniscus is a great choice for that), but events\n> are the very thing CM is designed to handle. Wouldn\'t it make sense to\n> push them back into there?\n> \n\nI\'m not sure these events make sense in the current Ceilometer (I assume\nthat is \"CM\" above) context. These events are:\n\n... Creating stack A\n... Creating stack A resource A\n... Created stack A resource A\n... Created stack A\n\nUsers will want to be able to see all of the events for a stack, and\nlikely we need to be able to paginate through them as well.\n\nThey are fundamental and low level enough for Heat that I\'m not sure\nputting them in Ceilometer makes much sense, but maybe I don\'t understand\nCeilometer..  or \"CM\" is something else entirely. :)\n\n\n','<5204EBC7.40701@rackspace.com>',NULL),('<1376065170-sup-9276@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-09 09:35:57',-25200,'2013-08-09 16:35:57',NULL,'[openstack-dev] Ensuring that we have OpenStack-friendly deployment\n	options. (point: AGPL is problematic)','While looking at some of the emerging technologies coming into stackforge\nand moving toward incubation and/or incubation, an interesting trend\nhas appeared.\n\nEverybody is using MongoDB!\n\nNow, don\'t get me wrong. MongoDB is being chosen for its technical\nexcellence in these problem areas. I think MongoDB is a fine choice for\nmany OpenStack users.\n\nHowever, for many others, the AGPL license is problematic. There is enough\nvagueness in the added \"network access\" clause, that some organizations\ndo not want to take the risk of deploying AGPL software.\n\nSo, I\'d like to make a plea to projects to consider this, and evaluate\nproviding backends for free software that is more friendly to OpenStack\nusers. Since we have an Apache license, apache licensed projects are\nthe simplest to consider. Also GPLv2 projects have been accepted by\norganizations large and small, and GPLv3 is usually ok (some orgs don\'t\nlike the patent provisions). BSD licenses also are usually acceptable\nsince they put almost no burden on the org and allow relicensing.\n\nHere is a list of MongoDB alternatives that I would like to see backends\nfor when plain old SQL will simply not do:\n\nApache license:\n\n- Riak\n- Cassandra\n- ElasticSearch\n- LogStash\n\nBSD 3-clause:\n\n- Redis\n\nAnyway, this is just something to consider as you all start and improve\nmore amazing projects.\n\n\n',NULL,NULL),('<1376299000.99455.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 02:16:40',-25200,'2013-08-12 09:16:40',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer)\n	feature?','Ok i started from scratch and now everything is working just fine. Thank you for all your help.?\nIn the end I believe it was because I did not have haproxy installed.?\n\n\n\n\n________________________________\n From: Eugene Nikanorov <enikanorov at mirantis.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 9, 2013 7:50 PM\nSubject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n \n\n\nuse_namespaces has no effect, lbaas agent?in grizzly?always relies on namespace support.\n\nCould you execute the failing command manually??\nThat needs to be done after you create a vip for the pool.\nThe command should look like this:\nsudo quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029 haproxy -f /var\n/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf -p /var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\n\n<e10951cd-4cca-4ba4-acc0-0ccde6817029> should be replaced with actual pool_id\n\nCould you also verify that path and file?/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf exist?\n\nThanks,\nEugene.\n\n\n\nOn Fri, Aug 9, 2013 at 12:39 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nYes this is my Kernel> ?2.6.32-358.114.1.openstack.el6.x86_64\n>and I enable:?\n>\n>\n>use_namespaces = True\n>\n>ovs_use_veth = True\n>\n>\n>in?/etc/quantum/dhcp_agent.ini and etc/quantum/l3_agent.ini\n>\n>\n>\n>\n>\n>\n>\n>________________________________\n> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>To: Jake G. <dj_dark_junglist at yahoo.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, August 9, 2013 5:33 PM\n>\n>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n> \n>\n>\n>Jake, haproxy.cfg is created by lbaas agent when you deploy an instance.\n>Are you sure your host os has namespace support?\n>\n>\n>Eugene.\n>\n>\n>\n>On Fri, Aug 9, 2013 at 12:30 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>Good call!\n>>Looks like i did but the service wont start. Do you have a sample haproxy.cfg file that will work with Openstack?\n>>\n>>\n>>Thank you\n>>\n>>\n>>\n>>________________________________\n>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Friday, August 9, 2013 3:08 PM\n>>\n>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>> \n>>\n>>\n>>Do you have haproxy package installed on your host?\n>>\n>>\n>>\n>>On Fri, Aug 9, 2013 at 9:41 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>\n>>I have enabled LBaas on my openstack, but after adding a pool, vip, members, and monitor successfully I am still unable to get load balancing working.?\n>>>I found this blog to help me so far?http://kimizhang.wordpress.com/2013/08/08/openstack-grizzly-quantum-advanced-features-2/\n>>>\n>>>\n>>>When I run # ps -ef | grep haproxy I dont get much:?\n>>>root 27508 2718 0 14:16 pts/1 00:00:00 grep haproxy\n>>>\n>>>\n>>>My logs show an issue with haproxy:\n>>>\n>>>\n>>>RuntimeError:?\n>>>Command: [\'sudo\', \'quantum-rootwrap\', \'/etc/quantum/rootwrap.conf\', \'ip\', \'netns\', \'exec\', \'qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029\', \'haproxy\', \'-f\', \'/var\n>>>/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf\', \'-p\', \'/var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\']\n>>>Exit code: 255\n>>>Stdout: \'\'\n>>>Stderr: \'exec of haproxy failed: No such file or directory\\n\'\n>>>2013-08-09 14:16:17 ? ?ERROR [quantum.plugins.services.agent_loadbalancer.agent.manager] Unable to refresh device for pool: e10951cd-4cca-4ba4-acc0-0ccde6817029\n>>>Traceback (most recent call last):\n>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/agent/manager.py\", line 189, in refresh_device\n>>>? ? self.driver.create(logical_config)\n>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 48, in create\n>>>? ? self._spawn(logical_config)\n>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 70, in _spawn\n>>>? ? ns.netns.execute(cmd)\n>>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py\", line 414, in execute\n>>>? ? check_exit_code=check_exit_code)\n>>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py\", line 61, in execute\n>>>? ? raise RuntimeError(m)\n>>>\n>>>\n>>>Any ideas?\n>>>\n>>>\n>>>\n>>>________________________________\n>>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Thursday, August 8, 2013 7:04 PM\n>>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>>> \n>>>\n>>>\n>>>Hi Jake,\n>>>\n>>>\n>>>Regarding lbaas in grizzly working on RHEL/Centos - it may be problematic as host operation system must support network namespaces.?\n>>>If you do have support for network namespaces then you need to do the following steps to setup lbaas service in quantum:\n>>>\n>>>\n>>>\n>>>1) specify lbaas plugin in quantum.conf:\n>>>service_plugins= lbaas_plugin_classpath.\n>>>check quantum/plugins/services/agent_loadbalancer/plugin.py for correct path as currently the name and path has changed.\n>>>\n>>>\n>>>2) to enable lbaas service in horizon you need to do the following:\n>>>add the following piece of code to?horizon/openstack_dashboard/local/local_settings.py :\n>>>\n>>>\n>>>OPENSTACK_QUANTUM_NETWORK = {\n>>>? ? \'enable_lb\': False\n>>>}\n>>>\n>>>\n>>>3) start quantum-lbaas-agent on the host providing quantum.conf and lbaas-agent.ini. lbaas-agent.ini should reflect core plugin configuration (should have proper interface driver)\n>>>\n>>>\n>>>Note that if host os has no namespace support, all of above will work (e.g. REST API will be functional), but you would not be able to deploy loadbalancer as lbaas agent can only work with namespaces.\n>>>\n>>>\n>>>Thanks,\n>>>Eugene.\n>>>\n>>>\n>>>\n>>>On Thu, Aug 8, 2013 at 1:14 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>>\n>>>Hi all!\n>>>>How can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\n>>>>I used RDO to deploy Openstack on a single node.\n>>>>\n>>>>\n>>>>\n>>>>Thank you! Jake\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/a9b02d2c/attachment.html>\n\n','<CAJfiwOTADd91B3jVBW4c_ndGn8XspP+DotLh7HSkz4OUigChXg@mail.gmail.com>',NULL),('<1376299072.54246.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 02:17:52',-25200,'2013-08-12 09:17:52',NULL,'[Openstack] Baremetal Provisioning for Openstack','Hi all,\n\n\n\nHow can I install/enable the baremetal provisioning feature for Openstack Grizzly? Any good resources, links??\n\nMy host is a single node CentOS fully working Openstack server installed with RDO packstack.\n\n\nThank you,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/29e8b4bb/attachment.html>\n\n','<1376034622.12186.YahooMailNeo@web163003.mail.bf1.yahoo.com>',NULL),('<1376302852.90072.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 03:20:52',-25200,'2013-08-12 10:20:52',NULL,'[Openstack] Baremetal Provisioning for Openstack','Thanks! I know how to use google. haha thats a funny site.\nThe only reason I ask here is because I am having trouble finding a good resource or documentation from google results.\nNot all good blogs show up on google btw.\n\nBest regards,\nJake\n\n\n\n________________________________\n From: Daniel Ellison <daniel at syrinx.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Monday, August 12, 2013 7:03 PM\nSubject: Re: [Openstack] Baremetal Provisioning for Openstack\n \n\nOn Aug 12, 2013, at 5:17 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n> \n> How can I install/enable the baremetal provisioning feature for Openstack Grizzly? Any good resources, links? \n\nhttp://lmgtfy.com/?q=openstack+grizzly+baremetal\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/bc339636/attachment.html>\n\n','<97BA4294-EC13-4759-A47A-E7764A7A43BF@syrinx.net>',NULL),('<1376304139.33656.YahooMailNeo@web161603.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-12 03:42:19',-25200,'2013-08-12 10:42:19',NULL,'[Openstack-operators] Query','Hello,\n\nCurrently I\'m working on openstack jcloud API. I\'m looking for jCloud API for some of the requirements. Can you please help me in the following points:\n\n1) to?Get list of networks\n(including its subnet details) for a particular tenant\n2) to?Upload image on\nopenstack using glance\n?\n\n?\nPavan Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130812/2ef2b866/attachment.html>\n\n',NULL,NULL),('<1376327567-sup-5976@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-12 10:26:40',-25200,'2013-08-12 17:26:40',NULL,'[openstack-dev] Extension to volume creation (filesystem and\n	label)','Excerpts from Greg Poirier\'s message of 2013-08-10 22:11:06 -0700:\n> Since we can\'t guarantee that a volume, when attached, will become a\n> specified device name, we would like to be able to create a filesystem and\n> label it (so that we can programmatically interact with it when\n> provisioning systems, services, etc).\n> \n> What we are trying to decide is whether this should be the responsibility\n> of Nova or Cinder. Since Cinder essentially has all of the information\n> about the volume and is already responsible for creating the volume\n> (against the configured backend), why not also give it the ability to mount\n> the volume (assuming support for it on the backend exists), run\n> mkfs.<filesystem_type>, and then use tune2fs to label the volume with (for\n> example) the volume\'s UUID?\n\nLike others, I am a little dubious about adding a filesystem to these\ndisks for a number of reasons. It feels like a violation of \"its just\na bunch of bits\".\n\nHave you considered putting a GPT on it instead?\n\nWith a GPT you have a UUID for the disk which you can communicate to the\nhost via metadata service. With that you can instruct gdisk to partition\nthe right disk programattically and create the filesystem with native\nin-instance tools.\n\nThis is pure meta-data, and defines a lot less than a filesystem, so it\nfeels like a bigger win for the general purpose case of volumes.  It will\nwork for any OS that supports GPT, which is likely _every_ modern PC OS.\n\n\n','<CANpjuCtEgYUsE7ti2ZD_2uRYbvbFO8zYneBvjAhpHGp+j2v6-g@mail.gmail.com>',NULL),('<1376328872.82227.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 10:34:32',-25200,'2013-08-12 17:34:32',NULL,'[Openstack] Best deployment tool for openstack production\n	environment','Hi all,\n\nI have been messing around with a few different tools for deploying openstack, but most of them seem they are designed for test environments.\n\nJust wonder what everyone\'s opinion is on the best tool for deploying a production quality environment? Or is it best to install each component?\none by one without using a deployment tool?\n\nThank you,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/e90a6ca0/attachment.html>\n\n',NULL,NULL),('<1376337665-sup-653@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-12 13:11:11',-25200,'2013-08-12 20:11:11',NULL,'[openstack-dev] [Heat] event table is a ticking time bomb','Excerpts from Doug Hellmann\'s message of 2013-08-12 12:08:58 -0700:\n> On Fri, Aug 9, 2013 at 11:56 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Sandy Walsh\'s message of 2013-08-09 06:16:55 -0700:\n> > >\n> > > On 08/08/2013 11:36 PM, Angus Salkeld wrote:\n> > > > On 08/08/13 13:16 -0700, Clint Byrum wrote:\n> > > >> Last night while reviewing a feature which would add more events to\n> > the\n> > > >> event table, it dawned on me that the event table really must be\n> > removed.\n> > > >\n> > > >\n> > > >>\n> > > >> https://bugs.launchpad.net/heat/+bug/1209492\n> > > >>\n> > > >> tl;dr: users can write an infinite number of rows to the event table\n> > at\n> > > >> a fairly alarming rate just by creating and updating a very large\n> > stack\n> > > >> that has no resources that cost any time or are even billable (like an\n> > > >> autoscaling launch configuration).\n> > > >>\n> > > >> The table has no purge function, so the only way to clear out old\n> > events\n> > > >> is to delete the stack, or manually remove them directly in the\n> > database.\n> > > >>\n> > > >> We\'ve all been through this before, logging to a database seems great\n> > > >> until you actually do it.\n> > > >>\n> > > >> I have some ideas for how to solve it, but I wanted to get a wider\n> > > >> audience:\n> > > >>\n> > > >> 1) Make the event list a ring buffer. Have rows 0 - $MAX_BUFFER_SIZE\n> > in\n> > > >> each stack, and simply write each new event to the next open position,\n> > > >> wrapping at $MAX_BUFFER_SIZE. Pros: little change to current code,\n> > > >> just need an offset column added and code that will properly wrap to 0\n> > > >> at $MAX_BUFFER_SIZE. Cons: still can incur heavy transactional load on\n> > > >> the database server.A\n> > > >>\n> > > >> 1.b) Same, but instead of rows, just maintain a blob and append the\n> > rows\n> > > >> as json list. Lowers transactional load but would push some load onto\n> > > >> the API servers and such to parse these out, and would make pagination\n> > > >> challenging. Blobs also can be a drain on DB server performance.\n> > > >>\n> > > >> 2) Write a purge script. Delete old ones. Pros: No code change, just\n> > > >> new code to do purging. Cons: same as 1, plus more vulnerability to an\n> > > >> aggressive attacker who can fit a lot of data in between purges. Also\n> > > >> large scale deletes can be really painful (see: keystone sql token\n> > > >> backend).\n> > > >>\n> > > >> 3) Log events to Swift. I can\'t seem to find information on how/if\n> > > >> appending works there. Tons of tiny single-row files is an option,\n> > but I\n> > > >> want to hear from people with more swift knowledge if that is a\n> > viable,\n> > > >> performant option. Pros: Scale to the moon. Can charge tenant for\n> > usage\n> > > >> and let them purge events as needed. Cons: Adds swift as a requirement\n> > > >> of Heat.\n> > > >>\n> > > >> 4) Provide a way for users to receive logs via HTTP POST. Pros: Simple\n> > > >> and punts the problem to the users. Cons: users will be SoL if they\n> > > >> don\'t have a place to have logs posted to.\n> > > >>\n> > > >> 5) Provide a way for users to receive logs via messaging service like\n> > > >> Marconi.  Pros/Cons: same as HTTP, but perhaps a little more confusing\n> > > >> and ambitious given Marconi\'s short existence.\n> > > >>\n> > > >> 6) Provide a pluggable backend for logging. This seems like the way\n> > most\n> > > >> OpenStack projects solve these issues, which is to let the deployers\n> > > >> choose and/or provide their own way to handle a sticky problem. Pros:\n> > > >> Simple and flexible for the future. Cons: Would require writing at\n> > least\n> > > >> one backend provider that does what the previous 5 options suggest.\n> > > >>\n> > > >> To be clear: Heat cannot really exist without this, as it is the only\n> > way\n> > > >> to find out what your stack is doing or has done.\n> > > >\n> > > > btw Clint I have ditched that \"Recorder\" patch as Ceilometer is\n> > > > getting a Alarm History api soon, so we can defer to that for that\n> > > > functionality (alarm transitions).\n> > > >\n> > > > But we still need a better way to record events/logs for the user.\n> > > > So I make this blueprint a while ago:\n> > > > https://blueprints.launchpad.net/heat/+spec/user-visible-logs\n> > > >\n> > > > I am becomming more in favor of user options rather than deployer\n> > > > options if possible. So provide resources for Marconi, Meniscus and\n> > > > what ever...\n> > > > Although what is nice about Marconi is you could then hook up what\n> > > > ever you want to it.\n> > >\n> > > Logs are one thing (and Meniscus is a great choice for that), but events\n> > > are the very thing CM is designed to handle. Wouldn\'t it make sense to\n> > > push them back into there?\n> > >\n> >\n> > I\'m not sure these events make sense in the current Ceilometer (I assume\n> > that is \"CM\" above) context. These events are:\n> >\n> > ... Creating stack A\n> > ... Creating stack A resource A\n> > ... Created stack A resource A\n> > ... Created stack A\n> >\n> > Users will want to be able to see all of the events for a stack, and\n> > likely we need to be able to paginate through them as well.\n> >\n> > They are fundamental and low level enough for Heat that I\'m not sure\n> > putting them in Ceilometer makes much sense, but maybe I don\'t understand\n> > Ceilometer..  or \"CM\" is something else entirely. :)\n> >\n> \n> CM is indeed ceilometer.\n> \n> The plan for the event API there is to make it admin-only (at least for\n> now). If this is data the user wants to see, that may change the plan for\n> the API or may mean storing it in ceilometer isn\'t a good fit.\n> \n\nVisibility into these events is critical to tracking the progress of\nany action done to a Heat stack:\n\n+---------------------+----+------------------------+--------------------+----------------------+\n| logical_resource_id | id | resource_status_reason | resource_status    | event_time           |\n+---------------------+----+------------------------+--------------------+----------------------+\n| AccessPolicy        | 24 | state changed          | CREATE_IN_PROGRESS | 2013-08-12T19:45:36Z |\n| AccessPolicy        | 25 | state changed          | CREATE_COMPLETE    | 2013-08-12T19:45:36Z |\n| User                | 26 | state changed          | CREATE_IN_PROGRESS | 2013-08-12T19:45:36Z |\n| Key                 | 28 | state changed          | CREATE_IN_PROGRESS | 2013-08-12T19:45:38Z |\n| User                | 27 | state changed          | CREATE_COMPLETE    | 2013-08-12T19:45:38Z |\n| Key                 | 29 | state changed          | CREATE_COMPLETE    | 2013-08-12T19:45:39Z |\n| notcompute          | 30 | state changed          | CREATE_IN_PROGRESS | 2013-08-12T19:45:40Z |\n+---------------------+----+------------------------+--------------------+----------------------+\n\nSo unless there is a plan to make this a user centric service, it does\nnot seem like a good fit.\n\n> Are these \"events\" transmitted in the same way as notifications? If so, we\n> may already have the data.\n> \n\nThe Heat engine records them while working on the stack. They have a\nfairly narrow, well defined interface, so it should be fairly easy to\naddress the storage issue with a backend abstraction.\n\n\n','<CADb+p3S7w6eF-Ks-H5YQKynLppYnw+sEmj7101SitqfxALO=0g@mail.gmail.com>',NULL),('<1376355083.12855.11.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 10:51:23',36000,'2013-08-13 00:51:23',NULL,'[openstack-dev] [keystone] Pagination','I\'m not sure where it would make sense within the API to return the name\nof the page/per_page variables to the client that doesn\'t involve having\nalready issued the call (ie returning the names within the links box\nmeans you\'ve already issued the query). If we standardize on the\npage/per_page combination then this can be handled at the controller\nlevel then the driver has permission to simply ignore it - or have the\ncontroller do the slicing after the driver has returned.\n\nTo weigh in on the other question i think it should be checked that page\nis an integer, unless per_page is specified in which case default to 1.\n\nFor example: \n\nGET /v3/users?page=\n\nI would expect to return all users as page is not set. However: \n\nGET /v3/users?per_page=30\n\nAs per_page is useless without a page i think we can default to page=1.\n\nAs an aside are we indexing from 1?\n\nOn Mon, 2013-08-12 at 19:05 -0500, Dolph Mathews wrote:\n> The way paginated links are defined by the v3 API (via `next` and\n> `previous` links), it can be completely up to the driver as to what\n> the query parameters look like. So, the client shouldn\'t have (nor\n> require) any knowledge of how to build query parameters for\n> pagination. It just needs to follow the links it\'s given.\n> \n> \n> \'page\' and \'per_page\' are trivial for the controller to implement (as\n> it\'s just slicing into an list... as shown)... so that\'s a reasonable\n> default behavior (for when a driver does not support pagination).\n> However, if the underlying driver DOES support pagination, it should\n> provide a way for the controller to ask for the query parameters\n> required to specify the next/previous links (so, one driver could\n> return `marker` and `limit` parameters while another only exposes the\n> `page` number, but not quantity `per_page`).\n> \n> \n> On Mon, Aug 12, 2013 at 4:34 PM, Henry Nash\n> <henryn at linux.vnet.ibm.com> wrote:\n>         Hi\n>         \n>         \n>         I\'m working on extending the pagination into the backends.\n>          Right now, we handle the pagination in the v3 controller\n>         class....and in fact it is disabled right now and we return\n>         the whole list irrespective of whether page/per-page is set in\n>         the query string, e.g.:\n>         \n>         \n>             def paginate(cls, context, refs):\n>                 \"\"\"Paginates a list of references by page & per_page\n>         query strings.\"\"\"\n>                 # FIXME(dolph): client needs to support pagination\n>         first\n>                 return refs\n>         \n>         \n>                 page = context[\'query_string\'].get(\'page\', 1)\n>                 per_page = context[\'query_string\'].get(\'per_page\', 30)\n>                 return refs[per_page * (page - 1):per_page * page]\n>         \n>         \n>         I wonder both for the V3 controller (which still needs to\n>         handle pagination for backends that do not support it) and the\n>         backends that do....whether we could use wether \'page\' is\n>         defined in the query-string as an indicator as to whether we\n>         should paginate or not?  That way clients who can handle it\n>         can ask for it, those that don\'twill just get everything.  \n>         \n>         \n>         Henry\n>         \n>         \n> \n> \n> \n> \n> -- \n> \n> \n> -Dolph\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAC=h7gXSFA1psMrTOY0BSgtw1J4ncNuTk8JCmq-xjTsEyOWyqw@mail.gmail.com>',NULL),('<1376362534-sup-3387@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 19:58:02',-25200,'2013-08-13 02:58:02',NULL,'[Openstack] Baremetal Provisioning for Openstack','Excerpts from Daniel Ellison\'s message of 2013-08-12 03:03:00 -0700:\n> On Aug 12, 2013, at 5:17 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n> > \n> > How can I install/enable the baremetal provisioning feature for Openstack Grizzly? Any good resources, links? \n> \n> http://lmgtfy.com/?q=openstack+grizzly+baremetal\n\n-1\n\nPlease be respectful. Jake is using this list for exactly what is\nintended. I have nothing but praise for a user who reaches out and asks\nfor help. I think we can all assume that users have searched for answers\nand are now bringing a complicated question to a group of experienced\nusers and/or developers like ourselves.\n\n\n','<97BA4294-EC13-4759-A47A-E7764A7A43BF@syrinx.net>',NULL),('<1376362691-sup-3053@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 20:04:30',-25200,'2013-08-13 03:04:30',NULL,'[Openstack] Baremetal Provisioning for Openstack','Excerpts from Jake G.\'s message of 2013-08-12 19:10:42 -0700:\n> I was trying to find information from other than official openstack documentation. Every time I have followed the openstack docs I have either rendered my whole openstack server unusable or can never get said feature to work. So I am a bit weary to follow, because I have no way to clone my current physical server test environment before i make changes at this time. \n> \n\nHi Jake. You may want to try switching to one of the fine sets of\npuppet recipes or chef cookbooks that will give you a working Grizzly\nsystem that you can re-build from scratch in case you break it. You\nmight also be interested in the \"OpenStack on OpenStack\", or \"TripleO\"\nproject which takes an image based approach and will give you an image\nyou can re-deploy to refresh your server. More info here:\n\nhttp://github.com/openstack/tripleo-incubator\n\n> One thing I need clarification on is, the nova driver that needs to be replaced. What happens to the previous driver and can I no longer use that with KVM? \n> \n\nhttp://docs.openstack.org/grizzly/openstack-compute/admin/content/selecting-a-hypervisor.html\n\nThis explains that for the most part you can only have one hypervisor\nat a time, though there are ways around that.\n\nBecause of the inherent security problems with baremetal nodes, it is\ngenerally considered a very bad idea to run multiple tenants on nova\'s\nbaremetal system at this time. It is suitable for a single tenant though.\n\nGood luck!\n-C\n\np.s. Please don\'t \"top post\". For mailing list archives and for some\nusers who have text based Email clients, the information flow works\nbetter if newer things are below what they\'re referring to.\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette\n\n\n','<D60401A6-830F-48DB-8255-5BDB911B1E44@yahoo.com>',NULL),('<1376363748.39224.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 20:15:48',-25200,'2013-08-13 03:15:48',NULL,'[Openstack] More than one compute_driver in nova.conf','\n\nI was wondering how to handle changing the?compute_driver in nova.conf? I currently have the default\n\ncompute_driver = libvirt.LibvirtDriver\n\nlibvirt_type=kvm\n\n\nI want to be able to add the driver for baremetal provisioning, but I am unclear on how to do this.\nCan there be more than one?compute_driver or do I have to replace?compute_driver = libvirt.LibvirtDriver with the new driver.\n\nIf I can only replace what will happen to my existing KVM and nova operations??\nAlso, I am just using the bearmetal driver as an example. This same question can be applied to any other feature that requires a different?compute_driver.\n\nBear metal driver example ?http://docs.openstack.org/grizzly/openstack-compute/admin/content/baremetal.html\n\nThank you!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/c4a748de/attachment.html>\n\n',NULL,NULL),('<1376371764.65243.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-12 22:29:24',-25200,'2013-08-13 05:29:24',NULL,'[Openstack] Baremetal Provisioning for Openstack','On 13/08/13 12:10, Jake G. wrote:\n\n> I was trying to find information from other than official openstack documentation. Every time I have followed the openstack docs I have either rendered my whole openstack server unusable or can never get said feature to work. So I am a bit weary to follow, because I have no way to clone my current physical server test environment before i make changes at this time. \n\nOn 13/08/13 1:45 PM,?Tom Fifield?wrote:\n>Hi Jake,\n\nDocs here. Just wanted to apologise for your experience and let you know\nthat we are working very hard on a new set of docs for you for the next\nrelease (which will be easier to maintain, and therefore easier for the\nfew of us working on it to keep up to date/accurate).\n\nAlso wanted to say that if bad things do happen, don\'t hesitate to send\nangry rants to: https://bugs.launchpad.net/openstack-manuals/+filebug -\nwe\'d seriously love some feedback so we can fix :)\n\nRegards,\nTom\n\nHi Tom,?\nThanks for the update. I am very excited about that news for sure.\nI did not intend for my message to be a rant. Hope it didn\'t sounds that way.?\nI just have not had much luck with the official docs in my particular set up.\n\nI am still very new to openstack so i wouldn\'t know where to begin to file a bug, because?\nI?wouldn\'t?recognize if something was a bug or if its something I am doing wrong.\n\nBut thanks for the encouragement!\n\nBest,\nJake?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130812/96e8736f/attachment.html>\n\n','<5209B9F0.6050907@openstack.org>',NULL),('<1376378547.53448.YahooMailNeo@web190106.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 15:22:27',28800,'2013-08-13 07:22:27',NULL,'[openstack-dev] Difference between RBAC polices thats stored in\n	policy.json and policies that can be created using\n	openstack/identity/v3/policies','Hi ,\n\nI am trying to understand Difference between RBAC polices thats stored in policy.json and policies that can be created using openstack/identity/v3/policies.\nI got answer from openstack forum that I can use both DB and policy.json based implementation for RBAC policy management.\n\nCan you please tell me how to use DB based RBAC ?   I can elaborate my question\n?1. In policy.json(keystone) I am able to define rule called -  admin_required \n?2. Similarly I can define rules  line custome_role_required\n?3. Then I can add this rule against each services (like for eg :  identity:list_users = custom_role_required\n\nHow can I use this for DB based RBAC policies?\n\nAlso there are code like   self.policy_api.enforce(context, creds, \'admin_required\', {})   in many places (this is in wsgi.py) \n\nHow can I utilize the same code and at the same time move the policy definition to DB\n\nThanks a million,\nSudheesh\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/2bea42c8/attachment.html>\n\n',NULL,NULL),('<1376378714.73160.YahooMailNeo@web190105.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 15:25:14',28800,'2013-08-13 07:25:14',NULL,'[openstack-dev] Can we use two nova schedulers at the same time?','Hi,\n\n1) Can nova have more than one scheduler at a time?   Standard Scheduler + one custom scheduler?\n\n2) If its possible to add multiple schedulers - how we should configure it. lets say I have  a scheduler called \'Scheduler\'  . So nova conf may look like below\nscheduler_manager = nova.scheduler.filters.SchedulerManager\nscheduler_driver = nova.scheduler.filter.Scheduler Then how can I add a second scheduler\n\n3) If there are 2 schedulers - will both of these called when creating a VM?\n\n\nI am asking these questions based on a response I got from ask openstack forum\n\nThanks,\nSudheesh\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/387662ef/attachment.html>\n\n',NULL,NULL),('<1376380647.71843.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-13 15:57:27',28800,'2013-08-13 07:57:27',NULL,'[Openstack] Doubt regarding json filter','Hi,\n\nI have been trying to use json filter. In the documentation,\nit says that I can make my filter using json hints. JSON filter\nhas its own pre-defined variables like $free_ram_mb, $free_disk_mb\netc. I was wondering if it is possible to define other variables, so?\nthat I can define a filter suiting my needs? If yes, then where should\nthe new variables be defined?\n\nThanks\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130813/2b6d7af3/attachment.html>\n\n',NULL,NULL),('<1376385391.87619.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-13 02:16:31',-25200,'2013-08-13 09:16:31',NULL,'[Openstack] Error in bare metal configuration','Hi all,\n\nHaving an issue deploying baremetal on a new packstack created Openstack Griz server created soley for bare metal testing.\nI have been following this?https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework?but after I run:\n\n# nova-baremetal-manage db sync\n\nI get the error:\nCommand failed, please check log for more info\n2013-08-13 18:06:05.056 3412 CRITICAL nova [-] \'module\' object has no attribute \'DatabaseNotControlledError\'\n2013-08-13 18:06:05.056 3412 TRACE nova Traceback (most recent call last):\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 221, in <module>\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? main()\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 213, in main\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? fn(*fn_args, **fn_kwargs)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 101, in sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? bmdb_migration.db_sync(version)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/migration.py\", line 34, in db_sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? return IMPL.db_sync(version=version)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/sqlalchemy/migration.py\", line 71, in db_sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? current_version = db_version()\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/sqlalchemy/migration.py\", line 85, in db_version\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? except versioning_exceptions.DatabaseNotControlledError:\n2013-08-13 18:06:05.056 3412 TRACE nova AttributeError: \'module\' object has no attribute \'DatabaseNotControlledError\'\n2013-08-13 18:06:05.056 3412 TRACE nova?\n\nI see a similar error reported here but the answer is not confirmed.?https://lists.launchpad.net/openstack/msg24081.html\n\nThanks for your help\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130813/7189ae17/attachment.html>\n\n',NULL,NULL),('<1376387864.84647.YahooMailNeo@web190106.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 17:57:44',28800,'2013-08-13 09:57:44',NULL,'[openstack-dev] Can we use two nova schedulers at the same time?','I have one quick question regarding the 3rd point you have mentioned (Multiple scheduler configurations\nwithin a single (potentially heterogeneous) Nova deployment)\n\nIn this case ultimately when a VM is created - would it have gone through all the schedulers or just one scheduler which was dynamically selected?\nIs there any chance of having 2 schedulers? impacting creation of one VM?\n\n\nThanks,\nSudheesh\n\n________________________________\n From: Alex Glikson <GLIKSON at il.ibm.com>\nTo: sudheesh sk <sudh03 at yahoo.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Tuesday, 13 August 2013 1:45 PM\nSubject: Re: [openstack-dev] Can we use two nova schedulers at the same time?\n \n\n\nThere are roughly three cases. \n1. Multiple identical instances of the\nscheduler service. This is typically done to increase scalability, and\nis already supported (although sometimes may result in provisioning failures\ndue to race conditions between scheduler instances). There is a single\nqueue of provisioning requests, all the scheduler instances are subscribed,\nand each request will be processed by one of the instances (randomly, more\nor less). I think this is not the option that you referred to, though. \n2. Multiple cells, each having its own\nscheduler. This is also supported, but is applicable only if you decide\nto use cells (e.g., in large-scale geo-distributed deployments). \n3. Multiple scheduler configurations\nwithin a single (potentially heterogeneous) Nova deployment, with dynamic\nselection of configuration/policy at run time (for simplicity let\'s assume\njust one scheduler service/runtime). This capability is under development\n(https://review.openstack.org/#/c/37407/) , targeting Havana. The current design\nis that the admin will be able to override scheduler properties (such as\ndriver, filters, etc) using flavor extra specs. In some cases you would\nwant to combine this capability with a mechanism that would ensure disjoint\npartitioning of the managed compute nodes between the drivers. This can\nbe currently achieved by using host aggregates and AggregateInstanceExtraSpec\nfilter of FilterScheduler. For example, if you want to apply driver_A on\nhosts in aggregate_X, and dirver_B on hosts in aggregate_Y, you would have\nflavor AX specifying driver_A and properties that would map to aggregate_X,\nand similarly for BY. \n\nHope this helps. \n\nRegards, \nAlex \n\n\n\nFrom: ? ? ?\n?sudheesh sk <sudh03 at yahoo.com> \nTo: ? ? ?\n?\"openstack-dev at lists.openstack.org\"\n<openstack-dev at lists.openstack.org>,  \nDate: ? ? ?\n?13/08/2013 10:30 AM \nSubject: ? ?\n? ?[openstack-dev]\nCan we use two nova schedulers at the same time? \n________________________________\n \n\n\nHi, \n\n1) Can nova have more than one scheduler\nat a time? Standard Scheduler + one custom scheduler? \n\n2) If its possible to add multiple schedulers\n- how we should configure it. lets say I have a scheduler called \'Scheduler\'\n. So nova conf may look like below scheduler_manager = nova.scheduler.filters.SchedulerManager\nscheduler_driver = nova.scheduler.filter.Scheduler Then how can I add a\nsecond scheduler \n\n3) If there are 2 schedulers - will both\nof these called when creating a VM? \n\n\nI am asking these questions based on a response\nI got from ask openstack forum \n\nThanks, \nSudheesh_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/b4bc7cfa/attachment.html>\n\n','<OFA59F40E9.246D0754-ONC2257BC6.002A7973-C2257BC6.002D6004@il.ibm.com>',NULL),('<1376428199.24389.327.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 22:09:59',3600,'2013-08-13 21:09:59',NULL,'[openstack-dev] Reminder: Oslo project meeting','Hi\n\nWe\'re having an IRC meeting on Friday to sync up again on the messaging\nwork going on:\n\n  https://wiki.openstack.org/wiki/Meetings/Oslo\n  https://etherpad.openstack.org/HavanaOsloMessaging\n\nFeel free to add other topics to the wiki\n\nSee you on #openstack-meeting at 1400 UTC\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1376434442.16153.11.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 18:54:02',-14400,'2013-08-13 22:54:02',NULL,'[openstack-dev] [keystone] [oslo] postpone key distribution bp\n	until icehouse?','On Tue, 2013-08-13 at 17:20 -0500, Dolph Mathews wrote:\n> With regard\n> to: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n> \nWell I am of course biased so take my comments with a grain of salt,\nthat said...\n> \n> During today\'s project status meeting [1], the state of KDS was\n> discussed [2]. To quote ttx directly: \"we\'ve been bitten in the past\n> with late security-sensitive stuff\" and \"I\'m a bit worried to ship\n> late code with such security implications as a KDS.\"\n\nIs ttx going to review any \"security implications\" ? The code does not\nmature just because is sit there untouched for more or less time.\n\n>  I share the same concern, especially considering the API only\n> recently went up for formal review [3],\n\nWhile the API may be important it has little to no bearing over the\nsecurity properties of the underlying code and mechanism.\nThe document to review to understand and/or criticize the \"security\nimplications\" is this: https://wiki.openstack.org/wiki/MessageSecurity\nand it has been available for quite a few months.\n\n>  and the WIP implementation is still failing smokestack [4].\n\nThis is a red herring, unfortunately Smokestack doesn\'t say why it is\nfailing but we suppose it is due to something python 2.6 doesn\'t like\n(only the centos machine fails). I have been developing on 2.7 and was\nplanning to do a final test on a machine with 2.6 once I had reviews\nagreeing no more fundamental changes were needed.\n> \n> I\'m happy to see the reviews in question continue to receive their\n> fair share of attention over the next few weeks, but can (and should?)\n> merging be delayed until icehouse while more security-focused eyes\n> have time to review the code?\n\nI would agree to this only if you can name individuals that are going to\ndo a \"security review\", otherwise I see no real reason to delay, as it\nwill cost time to keep patches up to date, and I\'d rather not do that if\nno one is lining up to do a \"security review\".\n\nFWIW I did circulate the design for the security mechanism internally in\nRed Hat to some people with some expertise in crypto matters.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<CAC=h7gU1WXp62S34NOViM8eP6bfUVGXpAGxyp5h8s07PVQbPBQ@mail.gmail.com>',NULL),('<1376445133-sup-9043@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 18:56:49',-25200,'2013-08-14 01:56:49',NULL,'[openstack-dev] Swift, netifaces, PyPy, and cffi','Excerpts from Alex Gaynor\'s message of 2013-08-13 14:58:56 -0700:\n> Hi all,\n> \n> (This references this changeset: https://review.openstack.org/#/c/38415/)\n> \n> One of the goals I\'ve been working at has been getting swift running on\n> PyPy (and from there, the rest of OpenStack). The last blocking issue in\n> swift is that it currently uses netifaces, which is a C-extension that\n> doesn\'t on PyPy. I\'ve proposed to replace this dependency with a cffi based\n> binding to the system.\n> \n> For those not familiar, cffi is a tool for binding to C libraries, similar\n> to ctypes (in the stdlib), except more expressive, less error prone, and\n> faster; some of our downstream dependencies already use it.\n> \n> One of the issues that came up in this review however, is that cffi is not\n> packaged in the most recent Ubuntu LTS (and likely other distributions),\n> although it is available in raring, and in a PPA (\n> http://packages.ubuntu.com/raring/python-cffi and\n> https://launchpad.net/~pypy/+archive/ppa?field.series_filter=preciserespectively).\n> \n> As a result of this, we wanted to get some feedback on which direction is\n> best to go:\n> \n> a) cffi-only approach, this is obviously the simplest approach, and works\n> everywhere (assuming you can install a PPA, use pip, or similar for cffi)\n\nThere are a lot of dependencies of Grizzly and Havana that aren\'t in\nthe official release of Ubuntu 12.04. That is why Canonical created\nthe cloud archive, so that users can keep everything that isn\'t\n\"OpenStack+Dependencies\" on the LTS.\n\nThe fact that cffi is already available in a release makes it even\nmore likely that it will be a straight forward backport to the cloud\narchive. However, is Ubuntu 12.04\'s pypy 1.8 sufficient?  Ubuntu 13.04\nand 12.10 have 1.9, and saucy (the presumed 13.10) has 2.0.2.\n\n\n','<CAFRnB2XbBtHn0YLUiAuShb_nM6qJdwZf-D5XcFqmBmzqWwCLAA@mail.gmail.com>',NULL),('<1376504453.2814.11.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 14:20:53',-14400,'2013-08-14 18:20:53',NULL,'[openstack-dev] [keystone] [oslo] postpone key distribution bp\n until icehouse?','On Wed, 2013-08-14 at 12:35 -0300, Thierry Carrez wrote:\n> Simo Sorce wrote:\n> >> During today\'s project status meeting [1], the state of KDS was\n> >> discussed [2]. To quote ttx directly: \"we\'ve been bitten in the past\n> >> with late security-sensitive stuff\" and \"I\'m a bit worried to ship\n> >> late code with such security implications as a KDS.\"\n> > \n> > Is ttx going to review any \"security implications\" ? The code does not\n> > mature just because is sit there untouched for more or less time.\n> \n> This is me wearing my vulnerability management hat on. The trick is that\n> we (the VMT) have to support security issues for code that will be\n> shipped in stable/havana. The most embarrassing security issues we had\n> in the past were with code that didn\'t see a fair amount of time in\n> master before we had to start supporting it.\n> \n> So for us there is a big difference between landing the KDS now and have\n> it security-supported after one month of usage, and landing it in a few\n> weeks and have it security-supported after 7 months of usage. After 7\n> months I\'m pretty sure most of the embarrassing issues will be ironed out.\n> \n> I don\'t really want us to repeat the mistakes of the past where we\n> shipped really new code in keystone that ended up not really usable, but\n> which we still had to support security-wise due to our policy.\n> \n> By \"security implications\", I mean that this is a domain (like, say,\n> token expiration) where even basic bugs can easily create a\n> vulnerability. We just don\'t have the bandwidth to ship an embargoed\n> security advisory for every bug that will be found in the KDS one month\n> from now.\n\nI understand and appreciate that, so are you saying you want to veto KDS\nintroduction in Havana on this ground ?\n\n> > I would agree to this only if you can name individuals that are going to\n> > do a \"security review\", otherwise I see no real reason to delay, as it\n> > will cost time to keep patches up to date, and I\'d rather not do that if\n> > no one is lining up to do a \"security review\".\n> >\n> > FWIW I did circulate the design for the security mechanism internally in\n> > Red Hat to some people with some expertise in crypto matters.\n> \n> Are you saying it won\'t have significantly less issues in 7 months just\n> by the virtue of being landed in master and put into use in various\n> projects ? Or that it was so thoroughly audited that my fears are\n> unwarranted ?\n\nBugs can always happen, and whether 7 month of being used in development\nmakes a difference when it comes to security relevant bugs I can\'t say.\nI certainly am not going to claim my work flawless, I know better than\nthat :)\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<520BA3CE.8000001@openstack.org>',NULL),('<1376504484.2814.13.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 14:21:24',-14400,'2013-08-14 18:21:24',NULL,'[openstack-dev] [keystone] [oslo] postpone key distribution bp\n until icehouse?','On Wed, 2013-08-14 at 12:41 -0300, Thierry Carrez wrote:\n> Dolph Mathews wrote:\n> > With regard\n> > to: https://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n> > [...]\n> \n> Dolph: you don\'t mention Barbican at all, does that mean that the issue\n> is settled and the KDS should live in keystone ?\n> \n> A side-benefit of landing early in Icehouse rather than late in Havana,\n> IMHO, was that we could put everyone in the same room (and around the\n> same beers) and get a single path forward.\n> \n> I\'m a bit worried (that\'s with my release management hat on) that if\n> everyone discovers that Barbican is the way to go for key distribution\n> at the Hong-Kong summit, we would now have to deprecate the in-Keystone\n> KDS over several releases just because it landed a few weeks too early.\n> \n> That said I haven\'t followed closely the latest discussions on this, so\n> maybe this is not as much duplication of effort as I think ?\n\nFor the Nth time KDS and Barbican do not do the same job, no more than\nKeystone auth paths and barbican do the same job. All three use crypto\nand \'keys\' ... in completely different ways.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<520BA541.90702@openstack.org>',NULL),('<1376504943.2814.15.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 14:29:03',-14400,'2013-08-14 18:29:03',NULL,'[openstack-dev] [keystone] [oslo] postpone key distribution bp\n until icehouse?','On Wed, 2013-08-14 at 14:06 -0300, Thierry Carrez wrote:\n> Adam Young wrote:\n> > On 08/13/2013 06:20 PM, Dolph Mathews wrote:\n> >> During today\'s project status meeting [1], the state of KDS was\n> >> discussed [2]. To quote ttx directly: \"we\'ve been bitten in the past\n> >> with late security-sensitive stuff\" and \"I\'m a bit worried to ship\n> >> late code with such security implications as a KDS.\" I share the same\n> >> concern, especially considering the API only recently went up for\n> >> formal review [3], and the WIP implementation is still failing\n> >> smokestack [4].\n> > \n> > Since KDS is a security tightening in acase where there is no security\n> > at all, adding it in can only improve security.\n> \n> It\'s not really a question of \"more security\" or \"less security\"... It\'s\n> about putting young sensitive code into a release, with the risk of\n> having to issue a lot of security advisories for early bugs.\n> \n> I\'m all for that code to land in the icehouse master branch as soon as\n> it opens and that it gets put into good use by projects throughout the\n> icehouse development cycle. I just think the benefits of waiting\n> outweigh the benefits of landing it now.\n> \n> I explained why I prefer it to land in a few weeks rather than now...\n> Can someone explain why they prefer the reverse ? Why does it have to be\n> in havana ?\n\nBecause it was painful top rebase due to the migrations code, however\nsince Adam landed the code that splits migrations so that extensions can\nhave their own separate code for that I think the burden will be\nsubstantially lower.\n\nIf this is your final word on the matter I\'ll take notice that the work\nwill be deferred till Icehouse and I will slightly demote its priority\nin my work queue.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<520BB928.4000708@openstack.org>',NULL),('<1376579737.184621853@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-08-15 10:15:37',-18000,'2013-08-15 15:15:37',NULL,'[openstack-community] Want to attend LinuxCon/CloudOpen in New Orleans, September 16-18?','\nOpenStack is a Gold Sponsor of [http://events.linuxfoundation.org/events/cloudopen-north-america] LinuxCon/CloudOpen North America in September.  We have a booth there and are looking for OpenStack developers to help staff it during these hours:\nMonday, September 16, 9am - 7:30pm\nTuesday, September 17, 9am - 4pm\nLinuxCon/CloudOpen events are some of my favorites.  They offer the opportunity to talk with fantastic developers, listen to exciting keynote speakers (including our own Jonathan Bryce), and attend relevant technical sessions.  Not to mention the great evening parties in New Orleans - one of the most fun cities in the world.\n\n\nI\'ll confirm up to 8 volunteers so each will have just a few hours of booth duty.  We\'ll provide full conference passes so you can enjoy everything the event has to offer.  I will send registration and hotel information with your confirmation. Please reply to me directly if you can help out.  Thank you very much.\n\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130815/335070fb/attachment.html>\n\n',NULL,NULL),('<1376582289.09661594@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-15 11:58:09',-14400,'2013-08-15 15:58:09',NULL,'[openstack-dev] [glance] [ceilometer] Periodic Auditing In\n	Glance','I don\'t know any actual numbers but I would have the concern that images tend to stick around longer than instances. For example, if someone takes daily snapshots of their server and keeps them around for a long time, the number of exists events would go up and up.\n\nJust a thought, could be a valid avenue of concern.\n\n-Alex\n\n-----Original Message-----\nFrom: \"Doug Hellmann\" <doug.hellmann at dreamhost.com>\nSent: Thursday, August 15, 2013 11:17am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [glance] [ceilometer] Periodic Auditing In Glance\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nNova generates a single exists event for each instance, and that doesn\'t\ncause a lot of trouble as far as I\'ve been able to see.\n\nWhat is the relative number of images compared to instances in a \"typical\"\ncloud?\n\nDoug\n\n\nOn Tue, Aug 13, 2013 at 7:20 PM, Neal, Phil <phil.neal at hp.com> wrote:\n\n> I\'m a little concerned that a batch payload won\'t align with \"exists\"\n> events generated from other services. To my recollection, Cinder, Trove and\n> Neutron all emit exists events on a per-instance basis....a consumer would\n> have to figure out a way to handle/unpack these separately if they needed a\n> granular feed. Not the end of the world, I suppose, but a bit inconsistent.\n>\n> And a minor quibble: batching would also make it a much bigger issue if a\n> consumer missed a notification....though I guess you could counteract that\n> by increasing the frequency (but wouldn\'t that defeat the purpose?)\n>\n> >\n> >\n> >\n> > On 08/13/2013 04:35 PM, Andrew Melton wrote:\n> > >> I\'m just concerned with the type of notification you\'d send. It has to\n> > >> be enough fine grained so we don\'t lose too much information.\n> > >\n> > > It\'s a tough situation, sending out an image.exists for each image with\n> > > the same payload as say image.upload would likely create TONS of\n> traffic.\n> > > Personally, I\'m thinking about a batch payload, with a bare minimum of\n> the\n> > > following values:\n> > >\n> > > \'payload\': [{\'id\': \'uuid1\', \'owner\': \'tenant1\', \'created_at\':\n> > > \'some_date\', \'size\': 100000000},\n> > >                {\'id\': \'uuid2\', \'owner\': \'tenant2\', \'created_at\':\n> > > \'some_date\', \'deleted_at\': \'some_other_date\', \'size\': 200000000}]\n> > >\n> > > That way the audit job/task could be configured to emit in batches\n> which\n> > > a deployer could tweak the settings so as to not emit too many\n> messages.\n> > > I definitely welcome other ideas as well.\n> >\n> > Would it be better to group by tenant vs. image?\n> >\n> > One .exists per tenant that contains all the images owned by that tenant?\n> >\n> > -S\n> >\n> >\n> > > Thanks,\n> > > Andrew Melton\n> > >\n> > >\n> > > On Tue, Aug 13, 2013 at 4:27 AM, Julien Danjou <julien at danjou.info\n> > > <mailto:julien at danjou.info>> wrote:\n> > >\n> > >     On Mon, Aug 12 2013, Andrew Melton wrote:\n> > >\n> > >     > So, my question to the Ceilometer community is this, does this\n> > >     sound like\n> > >     > something Ceilometer would find value in and use? If so, would\n> this be\n> > >     > something\n> > >     > we would want most deployers turning on?\n> > >\n> > >     Yes. I think we would definitely be happy to have the ability to\n> drop\n> > >     our pollster at some time.\n> > >     I\'m just concerned with the type of notification you\'d send. It\n> has to\n> > >     be enough fine grained so we don\'t lose too much information.\n> > >\n> > >     --\n> > >     Julien Danjou\n> > >     // Free Software hacker / freelance consultant\n> > >     // http://julien.danjou.info\n> > >\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n\n','<CADb+p3RZCB=SdnMLw8jBDhT4RxN0-AQc05mhE_Oms6owZiQ_Dw@mail.gmail.com>',NULL),('<1376593358-sup-2103@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-15 12:13:21',-25200,'2013-08-15 19:13:21',NULL,'[openstack-dev] [heat] Autoscaling event invocation','Excerpts from Chris Alfonso\'s message of 2013-08-15 11:02:13 -0700:\n> Hello,\n> \n> I would like to utilize Heat\'s autoscaling feature, but probably in a way it\n> was not initially designed to be used.\n> \n> In summary what I would like to do is from within OpenShift monitor host\n> system capacity and when necessary invoke the scale up or down event.  The\n> trick here is I can\'t just let Heat create a host configured exactly like the\n> previous host that Heat created for OpenShift.  I need to be able to provide\n> parameters to the scaling event invocation so that when the host comes online\n> the OpenShift infrastructure knows what to do with the host. The parameters\n> to provide might vary depending on the design approach in Heat\'s autoscaling.\n> I should be able either specify a template to be used that outlines how to\n> set up the host OR I should be able to pass in user data that can be passed\n> into the template that was used initially when setting up the scaling group.\n> \n> I\'ve outlined the desired functionality in more detail here (the autoscaling\n> portion):\n> https://github.com/openshift/openshift-pep/blob/master/openshift-pep-007.md\n> \n> I would like to start the discusion with the Heat group here on how best to\n> proceed with Heat\'s autoscaling and understand how the feature is evolving.\n\nThis isn\'t really auto scaling, this is just \"scaling\". Auto scaling\ninvolves easily clonable and destroyable instances. OpenShift servers\nare neither due to the state they appear to require.\n\nThat said, I want some of this too for TripleO so that we can pass in\nunique credentials for each member of a group but still have the same\ntemplate for them.\n\nFor the future, I hope we have a nice imperative way to just say\n\"remove insance 4 from resource group A\". For now, you can emulate\nthat by maintaining a nested stack that represents \"all the things\",\nand doing updates when you want to add/remove.\n\n\n','<20130815180212.GC44944@dhcp129-11.rdu.redhat.com>',NULL),('<1376622751712.ad7a41b4@Nodemailer>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-08-15 20:12:32',-25200,'2013-08-16 03:12:32',NULL,'[openstack-hpc] Fwd: Re: [openstack-dev] GPU passthrough support blueprints for OpenStack​','Don\'t know if you caught this on the main dev list. ?\n\n    ?\nSent from Mailbox for iPhone\n\n---------- Forwarded message ----------\nFrom: \"Brian Schott\" <brian.schott at nimbisservices.com>\nDate: Wed, Aug 14, 2013 at 9:53 AM\nSubject: Re: [openstack-dev] GPU passthrough support blueprints for OpenStack\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n\n> Thanks for the pointers.  I\'ll try to work with the UCS-ISI team that currently maintains those stories and see if we can reconcile or close the old blueprints.  \n> -------------------------------------------------\n> Brian Schott, CTO\n> Nimbis Services, Inc.\n> brian.schott at nimbisservices.com\n> ph: 443-274-6064  fx: 443-274-6060\n> On Aug 14, 2013, at 6:03 AM, Bob Ball <bob.ball at citrix.com> wrote:\n>> Hi Brian,\n>> \n>> Instead of specific GPU pass-through there are blueprints for generic PCI pass through at https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base - these are being worked on for Havana and we\'re hopeful they will get in (possibly libvirt only) \n>> \n>> In terms of vGPU rather than whole-GPU pass through, the slides are correct that XenServer support is very nearly here: http://www.xenserver.org/discuss-virtualization/q-and-a/nvidia-vgpu-on-xenserver-eg-gpu-hypervisor.html\n>> \n>> Support for static allocation of vGPU is likely going to be the first phase - and adding it as a resource similar to RAM/CPU isn\'t likely to be proposed until a second phase.\n>> \n>> As such, I think the integration should be very similar to PCI pass through above.\n>> \n>> \n>> Bob \n>> \n>>> -----Original Message-----\n>>> From: Brian Schott [mailto:brian.schott at nimbisservices.com]\n>>> Sent: 13 August 2013 23:07\n>>> To: openstack-dev at lists.openstack.org\n>>> Subject: [openstack-dev] GPU passthrough support blueprints for OpenStack\n>>> \n>>> Are there more recent blueprints related to adding GPU pass-through\n>>> support?  All that I can find are some stale blueprints that I created around\n>>> the Cactus timeframe (while wearing a different hat) that are pretty out of\n>>> date.\n>>> \n>>> I just heard a rumor that folks are doing Nvidia GRID K2 GPU passthrough\n>>> with KVM successfully using linux 3.10.6 kernel with RHEL.\n>>> \n>>> In addition, Lorin and I did some GPU passthrough testing back in the spring\n>>> with GRID K2 on HyperV, libvirt+xen, and XenServer.  Slides are here:\n>>> http://www.slideshare.net/bfschott/nimbis-schott-\n>>> openstackgpustatus20130618\n>>> \n>>> The virtualization support for  GPU-enabled virtual desktops and GPGPU\n>>> seems to have stabilized this year for server deployments.  How is this going\n>>> to be supported in OpenStack?\n>>> \n>>> Brian\n>>> \n>>> -------------------------------------------------\n>>> Brian Schott, CTO\n>>> Nimbis Services, Inc.\n>>> brian.schott at nimbisservices.com\n>>> ph: 443-274-6064  fx: 443-274-6060\n>>> \n>>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20130815/3183857e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 506 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-hpc/attachments/20130815/3183857e/attachment.pgp>\n\n','<3A6C7EC2-56C2-41CE-9830-51A902FE1807@nimbisservices.com>',NULL),('<1376667946.24389.353.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 16:45:46',3600,'2013-08-16 15:45:46',NULL,'[openstack-dev] Reminder: Oslo project meeting','On Tue, 2013-08-13 at 22:09 +0100, Mark McLoughlin wrote:\n> Hi\n> \n> We\'re having an IRC meeting on Friday to sync up again on the messaging\n> work going on:\n> \n>   https://wiki.openstack.org/wiki/Meetings/Oslo\n>   https://etherpad.openstack.org/HavanaOsloMessaging\n> \n> Feel free to add other topics to the wiki\n> \n> See you on #openstack-meeting at 1400 UTC\n\nLogs here:\n\nhttp://eavesdrop.openstack.org/meetings/oslo/2013/oslo.2013-08-16-14.00.html\n\nCheers,\nMark.\n\n\n\n','<1376428199.24389.327.camel@sorcha>',NULL),('<1376677532-sup-5363@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 11:35:13',-25200,'2013-08-16 18:35:13',NULL,'[openstack-dev] [Heat] How the autoscale API should control\n	scaling in Heat','Excerpts from Zane Bitter\'s message of 2013-08-16 09:36:23 -0700:\n> On 16/08/13 00:50, Christopher Armstrong wrote:\n> > *Introduction and Requirements*\n> >\n> > So there\'s kind of a perfect storm happening around autoscaling in Heat\n> > right now. It\'s making it really hard to figure out how I should compose\n> > this email. There are a lot of different requirements, a lot of\n> > different cool ideas, and a lot of projects that want to take advantage\n> > of autoscaling in one way or another: Trove, OpenShift, TripleO, just to\n> > name a few...\n> >\n> > I\'ll try to list the requirements from various people/projects that may\n> > be relevant to autoscaling or scaling in general.\n> >\n> > 1. Some users want a service like Amazon\'s Auto Scaling or Rackspace\'s\n> > Otter -- a simple API that doesn\'t really involve orchestration.\n> > 2. If such a API exists, it makes sense for Heat to take advantage of\n> > its functionality instead of reimplementing it.\n> \n> +1, obviously. But the other half of the story is that the API is likely \n> be implemented using Heat on the back end, amongst other reasons because \n> that implementation already exists. (As you know, since you wrote it ;)\n> \n> So, just as we will have an RDS resource in Heat that calls Trove, and \n> Trove will use Heat for orchestration:\n> \n>    user => [Heat =>] Trove => Heat => Nova\n> \n> there will be a similar workflow for Autoscaling:\n> \n>    user => [Heat =>] Autoscaling -> Heat => Nova\n> \n\nAfter a lot of consideration and an interesting IRC discussion, I think\nthe point above makes it clear for me. Autoscaling will have a simpler\nimplementation by making use of Heat\'s orchestration capabilities,\nbut the fact that Heat will also use autoscaling is orthogonal to that.\n\nThat does beg the question of why this belongs in Heat. Originally\nwe had taken the stance that there must be only one control system,\nlest they have a policy-based battle royale. If we only ever let\nautoscaled resources be controlled via Heat (via nested stack produced\nby autoscaling), then there can be only one.. control service (Heat).\n\nBy enforcing that autoscaling always talks to \"the world\" via Heat though,\nI think that reaffirms for me that autoscaling, while not really the same\nproject (seems like it could happily live in its own code tree), will\nbe best served by staying inside the \"OpenStack Orchestration\" program.\n\nThe question of private RPC or driving it via the API is not all that\ninteresting to me. I do prefer the SOA method and having things talk via\ntheir respective public APIs as it keeps things loosely coupled and thus\neasier to fit into one\'s brain and debug/change.\n\n\n','<520E5507.8090608@redhat.com>',NULL),('<1376678300-sup-4096@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 11:44:46',-25200,'2013-08-16 18:44:46',NULL,'[openstack-dev] Gate breakage process - Let\'s fix! (related but\n	not specific to neutron)','Excerpts from Maru Newby\'s message of 2013-08-16 11:25:07 -0700:\n> Neutron has been in and out of the gate for the better part of the past month, and it didn\'t slow the pace of development one bit.  Most Neutron developers kept on working as if nothing was wrong, blithely merging changes with no guarantees that they weren\'t introducing new breakage.  New bugs were indeed merged, greatly increasing the time and effort required to get Neutron back in the gate.  I don\'t think this is sustainable, and I\'d like to make a suggestion for how to minimize the impact of gate breakage.\n> \n> For the record, I don\'t think consistent gate breakage in one project should be allowed to hold up the development of other projects.  The current approach of skipping tests or otherwise making a given job non-voting for innocent projects should continue.  It is arguably worth taking the risk of relaxing gating for those innocent projects rather than halting development unnecessarily.\n> \n> However, I don\'t think it is a good idea to relax a broken gate for the offending project.  So if a broken job/test is clearly Neutron related, it should continue to gate Neutron, effectively preventing merges until the problem is fixed.  This would both raise the visibility of breakage beyond the person responsible for fixing it, and prevent additional breakage from slipping past were the gating to be relaxed.\n> \n> Thoughts?\n> \n\nI think this is a cultural problem related to the code review discussing\nfrom earlier in the week.\n\nWe are not looking at finding a defect and reverting as a good thing where\nhigh fives should be shared all around. Instead, \"you broke the gate\"\nseems to mean \"you are a bad developer\". I have been a bad actor here too,\ngetting frustrated with the gate-breaker and saying the wrong thing.\n\nThe problem really is \"you _broke_ the gate\". It should be \"the gate has\nfound a defect, hooray!\". It doesn\'t matter what causes the gate to stop,\nit is _always_ a defect. Now, it is possible the defect is in tempest,\nor jenkins, or HP/Rackspace\'s clouds where the tests run. But it is\nalways a defect that what worked before, does not work now.\n\nDefects are to be expected. None of us can write perfect code. We should\nbe happy to revert commits and go forward with an enabled gate while\nthe team responsible for the commit gathers information and works to\ncorrect the issue.\n\n\n','<0A70B897-5539-4B9A-9EA7-A14ED63E8567@redhat.com>',NULL),('<1376683206-sup-9574@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 13:00:55',-25200,'2013-08-16 20:00:55',NULL,'[openstack-dev] Proposal oslo.db lib','Excerpts from Ben Nemec\'s message of 2013-08-16 11:10:09 -0700:\n> On 2013-08-16 11:58, Jay Pipes wrote:\n> > On 08/16/2013 09:52 AM, Boris Pavlovic wrote:\n> >> Hi all,\n> >> \n> >> We (OpenStack contributors) done a really huge and great work around \n> >> DB\n> >> code in Grizzly and Havana to unify it, put all common parts into\n> >> oslo-incubator, fix bugs, improve handling of sqla exceptions, provide\n> >> unique keys, and to use  this code in different projects instead of\n> >> custom implementations. (well done!)\n> >> \n> >> oslo-incubator db code is already used by: Nova, Neutron, Cinder,\n> >> Ironic, Ceilometer.\n> >> \n> >> In this moment we finished work around Glance:\n> >> https://review.openstack.org/#/c/36207/\n> >> \n> >> And working around Heat and Keystone.\n> >> \n> >> So almost all projects use this code (or planing to use it)\n> >> \n> >> Probably it is the right time to start work around moving oslo.db code\n> >> to separated lib.\n> >> \n> >> We (Roman, Viktor and me) will be glad to help to make oslo.db lib:\n> >> \n> >> E.g. Here are two drafts:\n> >> 1) oslo.db lib code: https://github.com/malor/oslo.db\n> >> 2) And here is this lib in action: \n> >> https://review.openstack.org/#/c/42159/\n> >> \n> >> \n> >> Thoughts?\n> > \n> > ++\n> > \n> > Are you going to create a separate Launchpad project for the library\n> > and track bugs against it separately? Or are you going to use the oslo\n> > project in Launchpad for that?\n> \n> At the moment all of the oslo.* projects are just grouped under the \n> overall Oslo project in LP.  Unless there\'s a reason to do otherwise I \n> would expect that to be true of oslo.db too.\n\nHas that decision been re-evaluated recently?\n\nI feel like bug trackers are more useful when they are more focused. But\nperhaps there are other reasons behind using a shared bug tracker.\n\n\n','<49583e6494db8a6408481371d029772e@localhost>',NULL),('<1376713148-sup-8746@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 21:26:12',-25200,'2013-08-17 04:26:12',NULL,'[openstack-dev] Gate breakage process - Let\'s fix! (related but\n	not specific to neutron)','Excerpts from Maru Newby\'s message of 2013-08-16 16:42:23 -0700:\n> \n> On Aug 16, 2013, at 11:44 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Maru Newby\'s message of 2013-08-16 11:25:07 -0700:\n> >> Neutron has been in and out of the gate for the better part of the past month, and it didn\'t slow the pace of development one bit.  Most Neutron developers kept on working as if nothing was wrong, blithely merging changes with no guarantees that they weren\'t introducing new breakage.  New bugs were indeed merged, greatly increasing the time and effort required to get Neutron back in the gate.  I don\'t think this is sustainable, and I\'d like to make a suggestion for how to minimize the impact of gate breakage.\n> >> \n> >> For the record, I don\'t think consistent gate breakage in one project should be allowed to hold up the development of other projects.  The current approach of skipping tests or otherwise making a given job non-voting for innocent projects should continue.  It is arguably worth taking the risk of relaxing gating for those innocent projects rather than halting development unnecessarily.\n> >> \n> >> However, I don\'t think it is a good idea to relax a broken gate for the offending project.  So if a broken job/test is clearly Neutron related, it should continue to gate Neutron, effectively preventing merges until the problem is fixed.  This would both raise the visibility of breakage beyond the person responsible for fixing it, and prevent additional breakage from slipping past were the gating to be relaxed.\n> >> \n> >> Thoughts?\n> >> \n> > \n> > I think this is a cultural problem related to the code review discussing\n> > from earlier in the week.\n> > \n> > We are not looking at finding a defect and reverting as a good thing where\n> > high fives should be shared all around. Instead, \"you broke the gate\"\n> > seems to mean \"you are a bad developer\". I have been a bad actor here too,\n> > getting frustrated with the gate-breaker and saying the wrong thing.\n> > \n> > The problem really is \"you _broke_ the gate\". It should be \"the gate has\n> > found a defect, hooray!\". It doesn\'t matter what causes the gate to stop,\n> > it is _always_ a defect. Now, it is possible the defect is in tempest,\n> > or jenkins, or HP/Rackspace\'s clouds where the tests run. But it is\n> > always a defect that what worked before, does not work now.\n> > \n> > Defects are to be expected. None of us can write perfect code. We should\n> > be happy to revert commits and go forward with an enabled gate while\n> > the team responsible for the commit gathers information and works to\n> > correct the issue.\n> \n> You\'re preaching to the choir, and I suspect that anyone with an interest in software quality is likely to prefer problem solving to finger pointing.  However, my intent with this thread was not to promote more constructive thinking about defect detection.  Rather, I was hoping to communicate a flaw in the existing process and seek consensus on how that process could best be modified to minimize the cost of resolving gate breakage.\n> \n\nI believe that the process is a symptom of the culture. If we were\nmore eager to revert/discover/fix/re-submit on failure, we wouldn\'t\nbe turning off the gate for things. Instead we cling to whatever has\nhad the requisite \"+2/approval\" as if passing the stringent review has\nimparted our code with magical powers which will eventually morph into\na passing gate.\n\nIn a perfect world we could make our CI infrastructure bisect the failures\nto try and isolate the commits that did them so at least anybody can see\nthe commit that did the damage and revert it quickly. Realistically, most\nof the time we remove from the gate because the failures are intermittent\nand take _forever_ to discover, so that may not even be possible.\n\nI am suggesting that we all change our perspective and embrace \"revert\nthis immediately\" as \"thank you for finding that defect\" not \"you jerk\nwhy did you revert my code\". It may still be hard to find which commit\nto revert, but at least one can spend that time with the idea that they\nwill be rewarded, rather than punished, for their efforts.\n\n\n','<41B369F4-BB1C-4FAA-A5BE-12570D03E9F8@redhat.com>',NULL),('<1376715224-sup-5729@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-16 21:57:58',-25200,'2013-08-17 04:57:58',NULL,'[openstack-dev] Launchpad bug tracker defects (was: Proposal\n	oslo.db lib)','Excerpts from Thierry Carrez\'s message of 2013-08-16 13:55:46 -0700:\n> Jay Pipes wrote:\n> >>>> Are you going to create a separate Launchpad project for the library\n> >>>> and track bugs against it separately? Or are you going to use the oslo\n> >>>> project in Launchpad for that?\n> >>>\n> >>> At the moment all of the oslo.* projects are just grouped under the\n> >>> overall Oslo project in LP.  Unless there\'s a reason to do otherwise I\n> >>> would expect that to be true of oslo.db too.\n> >>\n> >> Has that decision been re-evaluated recently?\n> >>\n> >> I feel like bug trackers are more useful when they are more focused. But\n> >> perhaps there are other reasons behind using a shared bug tracker.\n> > \n> > +1\n> > \n> > The alternative (relying on users to tag bugs consistently) is error-prone.\n> \n> The reason is that it\'s actually difficult to get a view of all \"oslo\"\n> bugs due to Launchpad shortcomings (a project can only be in one project\n> group). So keeping them in a single \"project\" simplifies the work of\n> people that look after all of \"Oslo\".\n> \n> This should be fixed in the future with a task tracker that handles\n> project groups sanely, and then there is no reason at all to use the\n> same project for different repositories.\n> \n\nI know this sounds like a crazy idea, but have we looked at investing any\ntime in adding this feature to Launchpad?\n\nTripleO has the same problem. We look at bugs for:\n\ntripleo\ndiskimage-builder\nos-apply-config\nos-collect-config\nos-refresh-config\n\nNow, having all of those in one project is simply not an option, as they\nare emphatically different things. Part of TripleO is allowing users to\nswap pieces out for others, so having clear lines between components is\ncritical.\n\nI remember similar problems working on juju, juju-jitsu, charm-tools,\nand juju-core.\n\nSeems like it would be worth a small investment in Launchpad vs. having\nto switch to another tracker.\n\n\n','<520E91D2.9000408@openstack.org>',NULL),('<1376734230.76885.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-17 18:10:30',28800,'2013-08-17 10:10:30',NULL,'[Openstack] problem in creating builder files in swift','hello all!\n\n\nI am installing and configuring swift using the commands given in the \nbook \"software defined storage with openstack swift\" by Joe Arnold.\n\nI am working on Ubuntu 12.04\nI had downloaded swift, install it, configure files, prepare the drives, mount and reboot\nThen, I again give \'mount\' command and following results are recieved.\n\narun at arun-Aspire-5742:~$ mount\n/dev/sda4 on / type ext4 (rw,errors=remount-ro)\nproc on /proc type proc (rw,noexec,nosuid,nodev)\nsysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\nnone on /sys/fs/fuse/connections type fusectl (rw)\nnone on /sys/kernel/debug type debugfs (rw)\nnone on /sys/kernel/security type securityfs (rw)\nudev on /dev type devtmpfs (rw,mode=0755)\ndevpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\ntmpfs on /run type\n tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\nnone on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\nnone on /run/shm type tmpfs (rw,nosuid,nodev)\ngvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n\n\nThen, I proceed further for creating the builder files\n\narun at arun-Aspire-5742:~$ cd /etc/swift\narun at arun-Aspire-5742:/etc/swift$ su -\nPassword: \n\nroot at arun-Aspire-5742:~# cd /etc/swift\nroot at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder account.builder create 18 3 24\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n??? import pkg_resources\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n??? working_set.require(__requires__)\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n??? needed = self.resolve(parse_requirements(requirements))\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in\n resolve\n??? raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: dnspython>=1.10.0\nroot at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder container.builder create 18 3 24\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n??? import pkg_resources\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n??? working_set.require(__requires__)\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n??? needed = self.resolve(parse_requirements(requirements))\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n??? raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: dnspython>=1.10.0\nroot at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder\n object.builder create 18 3 24\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n??? import pkg_resources\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n??? working_set.require(__requires__)\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n??? needed = self.resolve(parse_requirements(requirements))\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n??? raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: dnspython>=1.10.0\nroot at arun-Aspire-5742:/etc/swift# \nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n??? import\n pkg_resources\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n??? working_set.require(__requires__)\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n??? needed = self.resolve(parse_requirements(requirements))\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n??? raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: dnspython>=1.10.0\n\n\nI was doubtful that these results are not correct and there is some problem in creating builder files.\n\nI install the python package dnspython using  \'apt-get install\' command\nThen, I try to create builder file\nBut, again, I get the? same error\n\nroot at arun-Aspire-5742:~# cd /opt/swift/etc\nroot at arun-Aspire-5742:/opt/swift/etc# sudo apt-get install python-dnspython\nReading package lists... Done\nBuilding dependency tree?????? \nReading state information... Done\nThe following NEW packages will be installed:\n? python-dnspython\n0 upgraded, 1 newly installed, 0 to remove and 590 not upgraded.\nNeed to get 99.2 kB of archives.\nAfter this operation, 548 kB of additional disk space will be used.\nGet:1 http://us.archive.ubuntu.com/ubuntu/ precise/main python-dnspython all 1.9.4-0ubuntu3 [99.2 kB]\nFetched 99.2\n kB in 3s (30.7 kB/s)????????????????????? \nSelecting previously unselected package python-dnspython.\n(Reading database ... 150833 files and directories currently installed.)\nUnpacking python-dnspython (from .../python-dnspython_1.9.4-0ubuntu3_all.deb) ...\nSetting up python-dnspython (1.9.4-0ubuntu3) ...\n\nroot at arun-Aspire-5742:/opt/swift/etc# cd /etc/swift\nroot at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder account.builder create 18 3 24\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n??? import pkg_resources\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2711, in <module>\n??? parse_requirements(__requires__), Environment()\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\",\n line 584, in resolve\n??? raise DistributionNotFound(req)\npkg_resources.DistributionNotFound: dnspython>=1.10.0\nroot at arun-Aspire-5742:/etc/swift# \n\nplease help me in this regard\n\n---\n\nthanks\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130817/f38c089e/attachment.html>\n\n',NULL,NULL),('<1376765724.22506.YahooMailNeo@web141204.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-17 11:55:24',-25200,'2013-08-17 18:55:24',NULL,'[openstack-dev] single quantum/neutron server','\n\n?Hello,?\nI have 2 different openstack clusters. They share glance and keystone. I am trying to configure them to share quantum service as well. For that I am running a common network node that is running all the agents (quantum-dhcp/quantum-l3/quantum-metadata/quantum-openvswitch agents) with user namespace option enabled and using gre. With this configuration, sharing quantum between two clusters works except the metadata service. metadata agent ini points to metadata host of cluster 1. So, instance launched on cluster 2 is not able to find the metadata information. ?What is the best way to use common quantums service between openstack clusters.\nThanks,\n-vj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130817/04d0d450/attachment.html>\n\n',NULL,NULL),('<137682554.42226.1379365655352.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-16 14:07:35',-25200,'2013-09-16 21:07:35',NULL,'[openstack-dev] [nova] [Pci passthrough] bug? -- \'NoneType\' object\n has no attribute \'support_requests\'','\n Hi,\n\n I\'m testing PCI passthrough features on Havana (single node installation).\nI\'ve installed OpenStack on CentOS 6.4 using EPEL.\nThe pci_passthrough_filter doesn\'t seem to be able to get the object \'host_state.pci_stats\'. \nIs it a bug?\n\n Thanks,\n David\n\n Here is the information of the test environment:\n\n1. /etc/nova.conf\n\npci_alias={\"name\":\"test\", \"product_id\":\"7190\", \"vendor_id\":\"8086\"}\npci_passthrough_whitelist=[{\"vendor_id\":\"8086\",\"product_id\":\"7190\"}]\n\n\nscheduler_available_filters=nova.scheduler.filters.all_filters\nscheduler_available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter\n\nscheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter,PciPassthroughFilter\n\n2. flavor\n\n# nova flavor-list --extra-specs\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+---------------------------------------+\n| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public | extra_specs                           |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+---------------------------------------+\n| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      | {u\'pci_passthrough:alias\': u\'test:1\'} |\n\n\n3. RPM information of nova-scheduler:\nName        : openstack-nova-scheduler\nArch        : noarch\nVersion     : 2013.2\nRelease     : 0.19.b3.el6\nSize        : 2.3 k\nRepo        : installed\n>From repo   : openstack-havana\n\n\n4. /var/log/nova/scheduler.log\n\n2013-09-16 17:04:51.259 13088 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'file = nova.image.download.file\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:70\n2013-09-16 17:04:51.259 13088 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'file = nova.image.download.file\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:70\n2013-09-16 17:04:51.259 13088 WARNING nova.scheduler.utils [req-267b2f38-825f-4609-82ef-6d4164e227b1 8ace6a952a0f4a9d81c435a2c8194fe9 656fecdc92df43c2a047316e5a1e3a24] [instance: 9a7e57e1-8c6f-4a18-94f0-c406aae99f9a] Setting instance to ERROR state.\n2013-09-16 17:04:51.398 13088 ERROR nova.openstack.common.rpc.amqp [req-267b2f38-825f-4609-82ef-6d4164e227b1 8ace6a952a0f4a9d81c435a2c8194fe9 656fecdc92df43c2a047316e5a1e3a24] Exception during message handling\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\", line 461, in _process_data\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     **args)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\", line 172, in dispatch\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     result = getattr(proxyobj, method)(ctxt, **kwargs)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/manager.py\", line 160, in run_instance\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     context, ex, request_spec)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/manager.py\", line 147, in run_instance\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     legacy_bdm_in_spec)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py\", line 87, in schedule_run_instance\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     filter_properties, instance_uuids)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py\", line 336, in _schedule\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     filter_properties, index=num)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/host_manager.py\", line 397, in get_filtered_hosts\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     hosts, filter_properties, index)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/filters.py\", line 82, in get_filtered_objects\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     list_objs = list(objs)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/filters.py\", line 43, in filter_all\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     if self._filter_one(obj, filter_properties):\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/filters/__init__.py\", line 27, in _filter_one\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     return self.host_passes(obj, filter_properties)\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/scheduler/filters/pci_passthrough_filter.py\", line 41, in host_passes\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp     return host_state.pci_stats.support_requests(\n2013-09-16 17:04:51.398 13088 TRACE nova.openstack.common.rpc.amqp AttributeError: \'NoneType\' object has no attribute \'support_requests\'\n\n\n\n','<1467203592.42016.1379363678493.JavaMail.root@zm.isi.edu>',NULL),('<1376879333.93106.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-18 19:28:53',-25200,'2013-08-19 02:28:53',NULL,'[Openstack]  Error in baremetal setup','Hi all,\n\n\n\nHaving an issue deploying baremetal on a new packstack created Openstack Griz server created soley for bare metal testing.\nI have been following this?https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework?but after I run:\n\n# nova-baremetal-manage db sync\n\nI get the error:\nCommand failed, please check log for more info\n2013-08-13 18:06:05.056 3412 CRITICAL nova [-] \'module\' object has no attribute \'DatabaseNotControlledError\'\n2013-08-13 18:06:05.056 3412 TRACE nova Traceback (most recent call last):\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 221, in <module>\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? main()\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 213, in main\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? fn(*fn_args, **fn_kwargs)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/bin/nova-baremetal-manage\", line 101, in sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? bmdb_migration.db_sync(version)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/migration.py\", line 34, in db_sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? return IMPL.db_sync(version=version)\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/sqlalchemy/migration.py\", line 71, in db_sync\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? current_version = db_version()\n2013-08-13 18:06:05.056 3412 TRACE nova ? File \"/usr/lib/python2.6/site-packages/nova/virt/baremetal/db/sqlalchemy/migration.py\", line 85, in db_version\n2013-08-13 18:06:05.056 3412 TRACE nova ? ? except versioning_exceptions.DatabaseNotControlledError:\n2013-08-13 18:06:05.056 3412 TRACE nova AttributeError: \'module\' object has no attribute \'DatabaseNotControlledError\'\n2013-08-13 18:06:05.056 3412 TRACE nova?\n\nI see a similar error reported here but the answer is not confirmed.?https://lists.launchpad.net/openstack/msg24081.html\n\nThanks for your help\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130818/d88fce55/attachment.html>\n\n','<1376385391.87619.YahooMailNeo@web163001.mail.bf1.yahoo.com>',NULL),('<1376899626.52989.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 16:07:06',28800,'2013-08-19 08:07:06',NULL,'[Openstack] problem in creating builder files in swift','thank you very much sir, for the suggestion. It work.\ni had successfully created the builder files.\n\nnow, I have to configure logging to a single local file\nfor this, according to book, I have to create a /etc/rsyslog.d/0-swift.conf with contents local0.* /var/log/swift/all.log\n\nI run the following command:\nroot at arun-Aspire-5742:/etc/swift# sudo cat \'local0.*/var/log/swift/all.log\' > /etc/rsyslog.d/0-swift.conf\ncat: local0.*/var/log/swift/all.log: No such file or directory\n\n\nbut I got error\n\nPlease help me in this regard\n\n---\n\nThanks\nPragya Jain\n\n\n\n\n>________________________________\n> From: Amanda Plimpton <amanda at swiftstack.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Sunday, 18 August 2013 5:16 AM\n>Subject: Re: problem in creating builder files in swift\n> \n>\n>\n>Dear Pragya Jain,\n>\n>Joe may correct me or have additional insight but looking at the log you provided the last last line of \"pkg_resources.\n>DistributionNotFound: dnspython>=1.10.0\" is saying that the system was looking a dnspython version that was equal to or greater than 1.10.0. I also see that earlier in the log it showed \"Setting up python-dnspython (1.9.4-0ubuntu3)\". If you upgrade the 1.9.4 version to a 1.10.0 version that error should no longer occur.\n>\n>\n>Thank you,\n>Amanda\n>\n>\n>\n>\n>On Sat, Aug 17, 2013 at 12:52 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello, sir!\n>>\n>>I install the python package dnspython using  \'apt-get install\' command\n>>Then, I try to create builder file\n>>But, again, I get the? same error\n>>\n>>please help me in this regard\n>>\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo apt-get install python-dnspython\n>>Reading package lists... Done\n>>Building dependency tree?????? \n>>Reading state information... Done\n>>The following NEW packages will be installed:\n>>? python-dnspython\n>>0 upgraded, 1 newly installed, 0 to remove and 590 not upgraded.\n>>Need to get 99.2 kB of archives.\n>>After this operation, 548 kB of additional disk space will be used.\n>>Get:1 http://us.archive.ubuntu.com/ubuntu/ precise/main python-dnspython all 1.9.4-0ubuntu3 [99.2 kB]\n>>Fetched 99.2\n kB in 3s (30.7 kB/s)????????????????????? \n>>Selecting previously unselected package python-dnspython.\n>>(Reading database ... 150833 files and directories currently installed.)\n>>Unpacking python-dnspython (from .../python-dnspython_1.9.4-0ubuntu3_all.deb) ...\n>>Setting up python-dnspython (1.9.4-0ubuntu3) ...\n>>\n>>root at arun-Aspire-5742:/opt/swift/etc# cd /etc/swift\n>>\n>>root at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder account.builder create 18 3 24\n>>Traceback (most recent call last):\n>>? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n>>??? import pkg_resources\n>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2711, in <module>\n>>??? parse_requirements(__requires__), Environment()\n>>\n>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\",\n line 584, in resolve\n>>??? raise DistributionNotFound(req)\n>>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>>root at arun-Aspire-5742:/etc/swift# \n>>\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>To: Joe Arnold <joe at swiftstack.com> \n>>>Cc: \"contact at swiftstack.com\" <contact at swiftstack.com> \n>>>Sent: Saturday, 17 August 2013 12:30 AM\n>>>\n>>>Subject: Re: problem in creating builder files in swift\n>>> \n>>>\n>>>\n>>>Thanks for the reply, Sir!\n>>>But, I don\'t know how to come over this problem\n>>>and, what commands should I use to remove this error?\n>>>\n>>>Please help me in this regard.\n>>>\n>>>---\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Joe Arnold <joe at swiftstack.com>\n>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>Cc: \"contact at swiftstack.com\" <contact at swiftstack.com> \n>>>>Sent: Friday, 16 August 2013 10:16 PM\n>>>>Subject: Re: problem in creating builder files in swift\n>>>> \n>>>>\n>>>>\n>>>>Hi Pragya,\n>>>>It appears that you are missing a python package based on the error message. Try digging into the error message around dnspython not found. We\'re always moving the code base ahead, so that may be something new (or gasp!) something that was overlooked in the book.\n>>>>\n>>>>\n>>>>Thanks!\n>>>>-Joe Arnold\n>>>>--CEO, SwiftStack Inc.\n>>>>http:// SwiftStack.com\n>>>>\n>>>>\n>>>>On Friday, August 16, 2013, pragya jain  wrote:\n>>>>\n>>>>hello,\n>>>>>\n>>>>>\n>>>>>I am installing and configuring swift using the commands given in the book \"software defined storage with openstack swift\" by Joe Arnold.\n>>>>>\n>>>>>I am working on Ubuntu 12.04\n>>>>>I had downloaded swift, install it, configure files, prepare the drives, mount and reboot\n>>>>>Then, I again give \'mount\' command and following results are recieved.\n>>>>>\n>>>>>\n>>>>>arun at arun-Aspire-5742:~$ mount\n>>>>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>>>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>>>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>>>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>>>>none on /sys/kernel/debug type debugfs (rw)\n>>>>>none on /sys/kernel/security type securityfs (rw)\n>>>>>udev on /dev type devtmpfs (rw,mode=0755)\n>>>>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>>>>tmpfs on /run type\n tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>>>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>>>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>>>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>>>>\n>>>>>\n>>>>>\n>>>>>Then, I proceed further for creating the builder files\n>>>>>\n>>>>>\n>>>>>arun at arun-Aspire-5742:~$ cd /etc/swift\n>>>>>arun at arun-Aspire-5742:/etc/swift$ su -\n>>>>>Password: \n>>>>>\n>>>>>root at arun-Aspire-5742:~# cd /etc/swift\n>>>>>root at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder account.builder create 18 3 24\n>>>>>Traceback (most recent call last):\n>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n>>>>>??? import pkg_resources\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n>>>>>??? working_set.require(__requires__)\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n>>>>>??? needed = self.resolve(parse_requirements(requirements))\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in\n resolve\n>>>>>??? raise DistributionNotFound(req)\n>>>>>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>>>>>root at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder container.builder create 18 3 24\n>>>>>Traceback (most recent call last):\n>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n>>>>>??? import pkg_resources\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n>>>>>??? working_set.require(__requires__)\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n>>>>>??? needed = self.resolve(parse_requirements(requirements))\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n>>>>>??? raise DistributionNotFound(req)\n>>>>>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>>>>>root at arun-Aspire-5742:/etc/swift# sudo swift-ring-builder\n object.builder create 18 3 24\n>>>>>Traceback (most recent call last):\n>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n>>>>>??? import pkg_resources\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n>>>>>??? working_set.require(__requires__)\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n>>>>>??? needed = self.resolve(parse_requirements(requirements))\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n>>>>>??? raise DistributionNotFound(req)\n>>>>>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>>>>>root at arun-Aspire-5742:/etc/swift# \n>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder\n>>>>>Traceback (most recent call last):\n>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 4, in <module>\n>>>>>??? import\n pkg_resources\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2707, in <module>\n>>>>>??? working_set.require(__requires__)\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 686, in require\n>>>>>??? needed = self.resolve(parse_requirements(requirements))\n>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n>>>>>??? raise DistributionNotFound(req)\n>>>>>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>>>>>\n>>>>>\n>>>>>\n>>>>>I am doubtful that these results are not correct and there is some problem in creating builder files.\n>>>>>Please help me in this regard how should I proceed further?\n>>>>>\n>>>>>\n>>>>>Thanks\n>>>>>\n>>>>>\n>>>>>Regards \n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>\n>>>>-- \n>>>>CEO, SwiftStack Inc.\n>>>>http://swiftstack.com\n>>>>+1-415-999-0282\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130819/f84b5fa5/attachment.html>\n\n','<CAJQZngBpwXUBBAEK1m9SxmcAffwyD6jBErcPOH=gp9L9UQJUQw@mail.gmail.com>',NULL),('<1376903637.19444.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 02:13:57',-25200,'2013-08-19 09:13:57',NULL,'[Openstack] Baremetal OS image support','Hi all!\n\nJust wondering if the baremetal provisioning driver supports any other OS`s images besides ubuntu?\nREHL, CentOS, etc...?\n\nThanks!\n\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130819/50548941/attachment.html>\n\n',NULL,NULL),('<1376908020.22647.YahooMailNeo@web190101.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-19 18:27:00',28800,'2013-08-19 10:27:00',NULL,'[openstack-dev] Can I Expose the host-aggregate as availability\n	zone?','Hi,\n\n1) Can I Expose\nthe host-aggregate as availability zone?\n\n\n2) Is there anyway to make the Host Aggregate dynamically growing (with each VM creation- add the host to host aggregate if its not already there)?\n\nThanks,\nSudheesh\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/8e471b7c/attachment.html>\n\n','<CAD85om13tO86WwKZ-Hmwg3BWjGwFSMp-oxuXoEynsqDmQwYXBg@mail.gmail.com>',NULL),('<1376908200.65624.YahooMailNeo@web190102.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-19 18:30:00',28800,'2013-08-19 10:30:00',NULL,'[openstack-dev] Can I Expose the host-aggregate as availability\n	zone?','\n\nHi,\n\n\n1) Can I Expose\nthe host-aggregate as availability zone?\n\n\n2) Is there anyway to make the Host Aggregate dynamically growing (with each VM creation- add the host to host aggregate if its not already there)?\n\nThanks,\nSudheesh\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/834aa696/attachment.html>\n\n','<1376908020.22647.YahooMailNeo@web190101.mail.sg3.yahoo.com>',NULL),('<1376912096.7065.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-19 04:34:56',-25200,'2013-08-19 11:34:56',NULL,'[openstack-dev] Tempest test failing for neutron','On submitted a Patch for neutron test case\nhttps://review.openstack.org/#/c/42598/\n\n\n?unrelated tests from tempest seem to be failing.\nhttp://logs.openstack.org/98/42598/2/check/gate-tempest-devstack-vm-neutron-full/4388bc6/console.html\n\nOne of the test failure is listed below.\n\nAny idea why this is happening and how to fix this?\n\n======================================================================\n2013-08-19 11:11:47.424 | FAIL: tempest.api.compute.admin.test_fixed_ips.FixedIPsTestJson.test_set_reserve[gate]\n2013-08-19 11:11:47.425 | tempest.api.compute.admin.test_fixed_ips.FixedIPsTestJson.test_set_reserve[gate]\n2013-08-19 11:11:47.425 | ----------------------------------------------------------------------\n2013-08-19 11:11:47.425 | _StringException: Empty attachments:\n2013-08-19 11:11:47.425 |   stderr\n2013-08-19 11:11:47.426 |   stdout\n2013-08-19 11:11:47.426 | \n2013-08-19 11:11:47.426 | Traceback (most recent call last):\n2013-08-19 11:11:47.427 |   File \"tempest/api/compute/admin/test_fixed_ips.py\", line 74, in test_set_reserve\n2013-08-19 11:11:47.427 |     resp, body = self.client.reserve_fixed_ip(self.ip, body)\n2013-08-19 11:11:47.427 |   File \"tempest/services/compute/json/fixed_ips_client.py\", line 39, in reserve_fixed_ip\n2013-08-19 11:11:47.428 |     resp, body = self.post(url, json.dumps(body), self.headers)\n2013-08-19 11:11:47.428 |   File \"tempest/common/rest_client.py\", line 259, in post\n2013-08-19 11:11:47.428 |     return self.request(\'POST\', url, headers, body)\n2013-08-19 11:11:47.428 |   File \"tempest/common/rest_client.py\", line 387, in request\n2013-08-19 11:11:47.429 |     resp, resp_body)\n2013-08-19 11:11:47.429 |   File \"tempest/common/rest_client.py\", line 432, in _error_checker\n2013-08-19 11:11:47.429 |     raise exceptions.NotFound(resp_body)\n2013-08-19 11:11:47.430 | NotFound: Object not found\n2013-08-19 11:11:47.430 | Details: {\"itemNotFound\": {\"message\": \"Fixed IP 10.1.0.4 not found\", \"code\": 404}}\n2013-08-19 11:11:47.430 | \n2013-08-19 11:11:47.431 | \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130819/c2f5edcb/attachment.html>\n\n',NULL,NULL),('<1376928852-sup-1728@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 09:18:45',-25200,'2013-08-19 16:18:45',NULL,'[Openstack] Baremetal OS image support','Excerpts from Jake G.\'s message of 2013-08-19 02:13:57 -0700:\n> Hi all!\n> \n> Just wondering if the baremetal provisioning driver supports any other OS`s images besides ubuntu?\n> REHL, CentOS, etc...?\n\nHi Jake,\n\nAny Linux OS that can be PXE booted should work. You just need to be\nable to upload a compatible kernel and initrd and attach them to the\nimage in glance. We have a script which will do just that (note that it\nrequires diskimage-builder too).\n\nhttps://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/load-image\n\n\n','<1376903637.19444.YahooMailNeo@web163002.mail.bf1.yahoo.com>',NULL),('<1376930948-sup-8908@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 09:53:32',-25200,'2013-08-19 16:53:32',NULL,'[Openstack] Baremetal OS image support','Excerpts from Matt Hogstrom\'s message of 2013-08-19 09:39:14 -0700:\n> Linux as a starting point makes sense, but, wouldn\'t the long term plan include any bootable instance?  I would find it interesting to boot Windows, a KVM instance (fits Linux), Solaris x86, FreeBSD to name a few.\n> \n\nAnything that can be net-booted is in the realm of possibility of course.\n\nhttps://git.openstack.org/cgit/openstack/ironic/tree/ironic/nova/pxe.py\n\nYou will see there that the method for booting the box is pxelinux,\nhence the requirment for Linux.\n\nIf you really are interested in booting those, by all means, submit\nthose patches! :)\n\n-C\n\np.s., you may want to try to conform to this to improve mailing list\nreadability: https://wiki.openstack.org/wiki/MailingListEtiquette#Replies\n\n\n','<57403480-CA05-4948-8096-0758DDAE3BD9@hogstrom.org>',NULL),('<1376973094.14528.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 21:31:34',-25200,'2013-08-20 04:31:34',NULL,'[Openstack] Baremetal OS image support','Thanks for the reply. That is good to here.\nHowever, My baremetal host is CentOS 6.4 so i am unable to run diskimage-builder.\nIs there another way to create images for baremetal? Or perhaps pre-made images somewhere?\nThanks\n\n________________________________\n From: Clint Byrum <clint at fewbar.com>\nTo: openstack <openstack at lists.openstack.org> \nSent: Tuesday, August 20, 2013 1:18 AM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nExcerpts from Jake G.\'s message of 2013-08-19 02:13:57 -0700:\n> Hi all!\n> \n> Just wondering if the baremetal provisioning driver supports any other OS`s images besides ubuntu?\n> REHL, CentOS, etc...?\n\nHi Jake,\n\nAny Linux OS that can be PXE booted should work. You just need to be\nable to upload a compatible kernel and initrd and attach them to the\nimage in glance. We have a script which will do just that (note that it\nrequires diskimage-builder too).\n\nhttps://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/load-image\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130819/54445ad6/attachment.html>\n\n','<1376928852-sup-1728@fewbar.com>',NULL),('<1376994361.6522.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 11:26:01',3600,'2013-08-20 10:26:01',NULL,'[openstack-dev] Code review study','On Thu, 2013-08-15 at 14:12 +1200, Robert Collins wrote:\n> This may interest data-driven types here.\n> \n> https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/\n> \n> Note specifically the citation of 200-400 lines as the knee of the review\n> effectiveness curve: that\'s lower than I thought - I thought 200 was\n> clearly fine - but no.\n\nThe full study is here:\n\nhttp://support.smartbear.com/resources/cc/book/code-review-cisco-case-study.pdf\n\nThis is an important subject and I\'m glad folks are studying it, but I\'m\nsceptical about whether the \"Defect density vs LOC\" is going to help us\ncome up with better guidelines than we have already.\n\nObviously, a metric like LOC hides some serious subtleties. Not all\nchanges are of equal complexity. We see massive refactoring patches\n(like s/assertEquals/assertEqual/) that are actually safer than gnarly,\nsingle-line, head-scratcher bug-fixes. The only way the report addresses\nthat issue with the underlying data is by eliding >10k LOC patches.\n\nThe \"one logical change per commit\" is a more effective guideline than\nany LOC based guideline:\n\nhttps://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes\n\nIMHO, the number of distinct logical changes in a patch has a more\npredictable impact on review effectiveness than the LOC metric.\n\nCheers,\nMark.\n\n\n\n','<CAJ3HoZ2bDqSwA0AWvTA=mnrqXT1-QKdL1j5t+UYjNnr_k2xvKA@mail.gmail.com>',NULL),('<1377010932.6522.60.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 16:02:12',3600,'2013-08-20 15:02:12',NULL,'[openstack-dev] Code review study','On Tue, 2013-08-20 at 11:26 +0100, Mark McLoughlin wrote:\n> On Thu, 2013-08-15 at 14:12 +1200, Robert Collins wrote:\n> > This may interest data-driven types here.\n> > \n> > https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/\n> > \n> > Note specifically the citation of 200-400 lines as the knee of the review\n> > effectiveness curve: that\'s lower than I thought - I thought 200 was\n> > clearly fine - but no.\n> \n> The full study is here:\n> \n> http://support.smartbear.com/resources/cc/book/code-review-cisco-case-study.pdf\n> \n> This is an important subject and I\'m glad folks are studying it, but I\'m\n> sceptical about whether the \"Defect density vs LOC\" is going to help us\n> come up with better guidelines than we have already.\n> \n> Obviously, a metric like LOC hides some serious subtleties. Not all\n> changes are of equal complexity. We see massive refactoring patches\n> (like s/assertEquals/assertEqual/) that are actually safer than gnarly,\n> single-line, head-scratcher bug-fixes. The only way the report addresses\n> that issue with the underlying data is by eliding >10k LOC patches.\n> \n> The \"one logical change per commit\" is a more effective guideline than\n> any LOC based guideline:\n> \n> https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes\n> \n> IMHO, the number of distinct logical changes in a patch has a more\n> predictable impact on review effectiveness than the LOC metric.\n\nWow, I didn\'t notice Joe had started to enforce that here:\n\n  https://review.openstack.org/41695\n\nand the exact example I mentioned above :)\n\nWe should not enforce rules like this blindly.\n\nMark.\n\n\n\n','<1376994361.6522.56.camel@sorcha>',NULL),('<1377013490-sup-3344@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 08:49:01',-25200,'2013-08-20 15:49:01',NULL,'[Openstack] Baremetal OS image support','Excerpts from Jake G.\'s message of 2013-08-19 21:31:34 -0700:\n> Thanks for the reply. That is good to here.\n> However, My baremetal host is CentOS 6.4 so i am unable to run diskimage-builder.\n> Is there another way to create images for baremetal? Or perhaps pre-made images somewhere?\n\nYou can build images on any Ubuntu or Fedora box, including VMs.\n\nI would also gladly +2 patches to make dib work on CentOS/RHEL 6 as well,\ngiven that we will likely be supporting those in OpenStack for a long\ntime to come.\n\nThanks to _you_ for using OpenStack :)\n-Clint\n\np.s. I personally would appreciate it if you would conform to the\ninterleaved reply style that is suggested here:\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette#Replies\n\n\n','<1376973094.14528.YahooMailNeo@web163006.mail.bf1.yahoo.com>',NULL),('<1377014326.6522.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 16:58:46',3600,'2013-08-20 15:58:46',NULL,'[openstack-dev] Stats on blueprint design info / creation times','On Mon, 2013-08-19 at 14:38 -0300, Thierry Carrez wrote:\n> Note that in some cases, some \"improvements\" that do not clearly fall\n> into the \"bug\" category are landed without a blueprint link (or a bug\n> link). So a first step could be to require that a review always\n> references a bug or a blueprint before it\'s landed. Then, improve the\n> quality of the information present in said bug/blueprint.\n\nI think that a \"every review must reference a bug or blueprint\" rule\nwould encourage more of this process checkbox behaviour.\n\nBlueprints are useful for some things:\n\n  - where a longer design rationale than is appropriate for a commit \n    message is required\n  - where it\'s a feature we want to raise awareness around\n  - where it\'s something that\'s going to take a while to bake and we \n    need to track its progress\n  - etc.\n\n(We\'ve seen already how DocImpact can be used to obviate the need for\n\"docs folks should look at this\" use case. We could do similarly for\nQA.)\n\nAnd for bugs:\n\n  - where the person with info about a problem isn\'t the person fixing \n    it\n  - where there\'s important background information (like detailed logs) \n    which can\'t be summarized appropriately in a commit message\n  - where we want it tracked as a must-have for a given release\n  - etc.\n\nSo, I\'m totally fine with someone showing up with a standalone commit\n(i.e. no bug or blueprint) and a nice explanatory commit message, if the\nbug or blueprint would not provide any of the value listed above.\n\nWhere a bug or blueprint doesn\'t provide such value, you often see\npeople with terse commit messages referencing a process checkbox bug or\nblueprint ... and that isn\'t helping anything.\n\nCheers,\nMark.\n\n\n\n','<52125812.9030602@openstack.org>',NULL),('<1377022186-sup-1206@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 11:21:06',-25200,'2013-08-20 18:21:06',NULL,'[openstack-dev] Code review study','Excerpts from Mark McLoughlin\'s message of 2013-08-20 03:26:01 -0700:\n> On Thu, 2013-08-15 at 14:12 +1200, Robert Collins wrote:\n> > This may interest data-driven types here.\n> > \n> > https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/\n> > \n> > Note specifically the citation of 200-400 lines as the knee of the review\n> > effectiveness curve: that\'s lower than I thought - I thought 200 was\n> > clearly fine - but no.\n> \n> The full study is here:\n> \n> http://support.smartbear.com/resources/cc/book/code-review-cisco-case-study.pdf\n> \n> This is an important subject and I\'m glad folks are studying it, but I\'m\n> sceptical about whether the \"Defect density vs LOC\" is going to help us\n> come up with better guidelines than we have already.\n> \n> Obviously, a metric like LOC hides some serious subtleties. Not all\n> changes are of equal complexity. We see massive refactoring patches\n> (like s/assertEquals/assertEqual/) that are actually safer than gnarly,\n> single-line, head-scratcher bug-fixes. The only way the report addresses\n> that issue with the underlying data is by eliding >10k LOC patches.\n> \n\nI\'m not so sure that it is obvious what these subtleties are, or they\nwould not be subtleties, they would be glaring issues.\n\nI agree that LOC changed is an imperfect measure. However, so are the\nhacking rules. They, however, have allowed us to not spend time on these\nthings. We whole-heartedly embrace an occasional imperfection by deferring\nto something that can be measured by automation and thus free up valuable\ntime for other activities more suited to limited reviewer/developer time.\n\nI\'d like to see automation enforce change size. And just like with\nhacking, it would not be possible without a switch like \"#noqa\" that\none can put in the commit message that says \"hey automation, this is\na trivial change\".  That is something a reviewer can also see as a cue\nthat this change, while big, should be trivial.\n\n> The \"one logical change per commit\" is a more effective guideline than\n> any LOC based guideline:\n> \n> https://wiki.openstack.org/wiki/GitCommitMessages#Structural_split_of_changes\n> \n> IMHO, the number of distinct logical changes in a patch has a more\n> predictable impact on review effectiveness than the LOC metric.\n\nIndeed, however, automating a check for that may be very difficult. I\nhave seen tools like PMD[1] that try very hard to measure the complexity\nof code and the risk of change, and those might be interesting to see,\nbut I\'m not sure they are reliable enough to put in the OpenStack gate.\n\n[1] http://pmd.sourceforge.net/\n\n\n','<1376994361.6522.56.camel@sorcha>',NULL),('<1377027283.6522.78.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-20 20:34:43',3600,'2013-08-20 19:34:43',NULL,'[openstack-dev] [keystone] [oslo] postpone key distribution bp\n until icehouse?','On Wed, 2013-08-14 at 18:02 -0300, Thierry Carrez wrote:\n> Simo Sorce wrote:\n> > On Wed, 2013-08-14 at 14:06 -0300, Thierry Carrez wrote:\n> >> I explained why I prefer it to land in a few weeks rather than now...\n> >> Can someone explain why they prefer the reverse ? Why does it have to be\n> >> in havana ?\n> > \n> > Because it was painful top rebase due to the migrations code, however\n> > since Adam landed the code that splits migrations so that extensions can\n> > have their own separate code for that I think the burden will be\n> > substantially lower.\n> > \n> > If this is your final word on the matter I\'ll take notice that the work\n> > will be deferred till Icehouse and I will slightly demote its priority\n> > in my work queue.\n> \n> Like I said in the other email, I don\'t really have \"the final word\" on\n> this, Dolph has. I can only influence his decision. Personally, with the\n> information I have so far, I think the benefits of waiting outweigh the\n> drawbacks, but that may be just me and my fear of repeating past mistakes.\n\nDuring the Oslo meeting last Friday, we decided it would be best to\ndefer the secure messaging feature until Icehouse. While the code seems\npretty complete, it\'ll naturally need some settling in time, time to\nmake all the projects use it and then stuff like docs, devstack support,\netc.\n\nI\'m looking forward to see this land early in Icehouse.\n\nPart of the implications of this is that we\'ll focus efforts on adding\nthis feature to oslo.messaging in Icehouse rather than the rpc library\nin oslo-incubator.\n\nCheers,\nMark.\n\n\n\n\n','<520BF05C.1050703@openstack.org>',NULL),('<1377053276.75040.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 19:47:56',-25200,'2013-08-21 02:47:56',NULL,'[Openstack] Use of VIPs in Openstack','Hi!\n\nI was wondering if it is possible to use a Virtual IP or VIP for clustering services (LVS, SQL, etc...) or for 3rd party load balancers?\nI dont see a way to assign an IP address to multiple instances for this purpose.\n\nThanks,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/1b1d3c37/attachment.html>\n\n',NULL,NULL),('<1377054199.81633.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 20:03:19',-25200,'2013-08-21 03:03:19',NULL,'[Openstack] Baremetal OS image support','\n\nFrom:Clint Byrum <clint at fewbar.com>\n\nTo: openstack <openstack at lists.openstack.org> \nSent: Wednesday, August 21, 2013 12:49 AM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nExcerpts from Jake G.\'s message of 2013-08-19 21:31:34 -0700:\n> Thanks for the reply. That is good to here.\n> However, My baremetal host is CentOS 6.4 so i am unable to run diskimage-builder.\n> Is there another way to create images for baremetal? Or perhaps pre-made images somewhere?\n\nYou can build images on any Ubuntu or Fedora box, including VMs.\n\nI would also gladly +2 patches to make dib work on CentOS/RHEL 6 as well,\ngiven that we will likely be supporting those in OpenStack for a long\ntime to come.\n\nThanks to _you_ for using OpenStack :)\n-Clint\n\np.s. I personally would appreciate it if you would conform to the\ninterleaved reply style that is suggested here:\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette#Replies\n\n\n\n\n________________________________\n\n\nThanks Clint!\nI built a seperate ubuntu server to run diskbuilder, however now when I run?\n#?bin/ramdisk-image-create deploy -k $KERNEL -o my-deploy-ramdisk\nI get the error?ramdisk-image-create: invalid option -- \'k\'\n\n\nHave you see this error?\n\nAlso, do you happen to know of any resources where i can download?pre-made images?\nAll the sites I have seen are for \"cloud\" images only. Could these possibly work as well?\n\n-jake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/2a6ad968/attachment.html>\n\n','<1377013490-sup-3344@fewbar.com>',NULL),('<1377054712.89827.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-20 20:11:52',-25200,'2013-08-21 03:11:52',NULL,'[Openstack] Use of VIPs in Openstack','Great job! that looks awesome. ?Cant wait for the patch to release. ?\n\n\n________________________________\n From: Aaron Rosen <arosen at nicira.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Wednesday, August 21, 2013 12:04 PM\nSubject: Re: [Openstack] Use of VIPs in Openstack\n \n\n\nHi Jake,?\n\nThis patch implements that exact usecase:?https://review.openstack.org/#/c/38230/?. Hopefully, we\'ll get this in by the end of the week.?\n\nBest,?\n\nAaron\n\n\n\nOn Tue, Aug 20, 2013 at 7:47 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\nHi!\n>\n>\n>I was wondering if it is possible to use a Virtual IP or VIP for clustering services (LVS, SQL, etc...) or for 3rd party load balancers?\n>I dont see a way to assign an IP address to multiple instances for this purpose.\n>\n>\n>Thanks,\n>Jake\n>\n>\n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130820/d361a029/attachment.html>\n\n','<CANAD0X-1aj-x=MsQnyHAYBPoyQB4Fp3vsT=0j3yWVK-up_c=Kg@mail.gmail.com>',NULL),('<1377077874.20398.YahooMailNeo@web163005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-21 02:37:54',-25200,'2013-08-21 09:37:54',NULL,'[Openstack] Baremetal OS image support','\n\n\n________________________________\n From: Robert Collins <robertc at robertcollins.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Wednesday, August 21, 2013 6:24 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nOn 21 August 2013 15:03, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n> From: Clint Byrum <clint at fewbar.com>\n> To: openstack <openstack at lists.openstack.org>\n> Sent: Wednesday, August 21, 2013 12:49 AM\n>\n> Subject: Re: [Openstack] Baremetal OS image support\n\n\n> I built a seperate ubuntu server to run diskbuilder, however now when I run\n> # bin/ramdisk-image-create deploy -k $KERNEL -o my-deploy-ramdisk\n> I get the error ramdisk-image-create: invalid option -- \'k\'\n>\n> Have you see this error?\n\nYou may be following old documentation - where did you get the sample\ncommand line? -k is no longer needed, and hasn\'t been accepted for a\nmonth or so.\n\n> Also, do you happen to know of any resources where i can download pre-made\n> images?\n> All the sites I have seen are for \"cloud\" images only. Could these possibly\n> work as well?\n\nWe\'ll make some available again soon, but for the moment you should\nuse diskimage-builder to setup the deploy ramdisk.\n\n-Rob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n________________________________\n\n\n\nHi Rob,\nThank you for the info. I look forward to those images.\n\nI am using this document for baremetal deployment, which has the -k in it ->?https://wiki.openstack.org/wiki/Baremetal\nThis seem to be the only documentation available for how to implement the baremetal feature. Would you know of a better doc?\n\nThanks again!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130821/a11e54fb/attachment.html>\n\n','<CAJ3HoZ36-bdc07+RdWLhGf4izyrLw_OhbxgCSe2N6+-+PaNQew@mail.gmail.com>',NULL),('<1377089388.37286.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-21 20:49:48',28800,'2013-08-21 12:49:48',NULL,'[Openstack] Host capabilities are not getting updated.','Hi,\n\nI have been trying to use some additional capabilities in host.\nAs shown in the following link:\n\nhttp://russellbryantnet.wordpress.com/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n\n\nI created a flavor and an aggregate. But when I try to\nboot the instance using the flavor, it results in error because\nComputeCapabilitiesFilter returns 0 hosts. I investigated further\nand found that the host\'s capabilities werent being updated.\n\nHow can I rectify this?\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130821/19a66da4/attachment.html>\n\n',NULL,NULL),('<1377090684.93264.YahooMailNeo@web194604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-21 21:11:24',28800,'2013-08-21 13:11:24',NULL,'[openstack-dev] Host capabilities are not getting updated','Hi,\n\nI have been trying to use some additional capabilities in host.\nAs shown in the following link:\n\nhttp://russellbryantnet.wordpress.com/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n\n\nI created a flavor and an aggregate. But when I try to\nboot the instance using the flavor, it results in error because\nComputeCapabilitiesFilter returns 0 hosts. I investigated further\nand found that the host\'s capabilities werent being updated.\n\nHow can I rectify this?\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130821/7bb1c6bf/attachment.html>\n\n',NULL,NULL),('<137710221.10910454.1398361951859.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 13:52:31',-14400,'2014-04-24 17:52:31',NULL,'[openstack-dev] [OpenStack][Nova] infinite attempts left','Hi Gareth,\nIn the future, please use the operator mailing list\n(see https://wiki.openstack.org/wiki/Mailing_Lists) for questions like this.\n\nTo answer your question, however, it indicates that nova-manage was unable\nto establish an connection to the database, and will retry an infinite number\nof times (i.e. it won\'t time out).\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Gareth\" <academicgareth at gmail.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Thursday, April 24, 2014 5:42:06 AM\nSubject: [openstack-dev] [OpenStack][Nova] infinite attempts left\n\nWhen run \"nova-manage db sync\" \n\nit outputs a lot of logs and \"SQL connection failed. infinite attempts left\" \n\nWhat does that means? \n\n-- \nGareth \n\nCloud Computing, OpenStack, Distributed Storage, Fitness, Basketball \nOpenStack contributor, kun_huang at freenode \nMy promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me \nand I\'ll donate $1 or ?1 to an open organization you specify. \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAhuP_9txoin5NqXXg8k9NbPwpD21WAxQOMamWyRaMWQX8cpTA@mail.gmail.com>',NULL),('<1377119368930.d48ada4e@Nodemailer>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-21 14:09:29',-25200,'2013-08-21 21:09:29',NULL,'[Openstack-operators] Using metadata with quantum','Juan:\n\n    \n      \n\n\n    Check out this blog post from Darragh O\'Reilly about how to configure access to the metadata service when not using the l3-agent:\n\n    \n      \n\n\n    \n      http://techbackground.blogspot.com/2013/06/metadata-via-dhcp-namespace.html?m=1\n    \n\n    \n\n\n      \n\n\n    Lorin\n?\nSent from Mailbox for iPhone\n\n\n    \nOn Wed, Aug 21, 2013 at 4:56 PM, Juan Jos? Pavlik Salles <jjpavlik at gmail.com=\"mailto:jjpavlik at gmail.com\">> wrote:\n\n    \n      Hi guys, i\'m trying to get my metadata working with quantum. I don\'t have L3-agent and i\'m using provider network with ovs and vlans. So far i have quantum-dhcp working great and my VMs get IP with no problems, but during boot they get stuck trying to access to the metadata service.\n\n\nIs it possible to access to the metadata service without using quantum-l3-agent??\n\n\nMy network node runs quantum-server, quantum-dhcp-agent, quantum-openvswitch-agent and quantum-metadata-service. I\'ve configured metada_agent like this:\n\n\n\n[DEFAULT]\n# Show debugging output in log (sets DEBUG log level output)\ndebug = True\nverbose = True\n\n\n# The Quantum user information for accessing the Quantum API.\n\nauth_url = http://172.19.136.1:35357/v2.0\nauth_region = RegionOne\nadmin_tenant_name = service\nadmin_user = quantum\nadmin_password = yedAA567\n\n\n\n# IP address used by Nova metadata server\n####cambiar esto!!! a una IP balanceada, posiblemente 172.19.136.1\nnova_metadata_ip = 172.19.136.12\n\n\n# TCP Port used by Nova metadata server\n\nnova_metadata_port = 8775\n\n\n# When proxying metadata requests, Quantum signs the Instance-ID header with a\n# shared secret to prevent spoofing. ?You may select any string for a secret,\n\n# but it must match here and in the configuration used by the Nova Metadata\n# Server. NOTE: Nova uses a different key: quantum_metadata_proxy_shared_secret\n# metadata_proxy_shared_secret =\n\nmetadata_proxy_shared_secret = XXXX\n\n\nWhat else should i do? I still get?\n\n\n?20130821 20:29:36,057 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [22/120s]: http error [504]\n\n20130821 20:29:45,117 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [31/120s]: http error [504]\n20130821 20:29:55,181 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [41/120s]: http error [504]\n\n20130821 20:30:04,241 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [50/120s]: http error [504]\n20130821 20:30:14,308 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [60/120s]: http error [504]\n\n20130821 20:30:23,369 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [69/120s]: http error [504]\n20130821 20:30:34,436 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [80/120s]: http error [504]\n\n20130821 20:30:43,505 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [89/120s]: http error [504]\n20130821 20:30:54,577 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [101/120s]: http error [504]\n\n20130821 20:31:03,636 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [110/120s]: http error [504]\n20130821 20:31:12,648 ?util.py[WARNING]: \'http://169.254.169.254/20090404/metadata/instanceid\' failed [119/120s]: socket timeout [timed out]\n\n\n\nduring boots.\n\n\nSomehow my network node should take this requests to 169.254.169.254, i have no idea how to do that.?\n\n\nThanks!\n\n\n-- \nPavlik Salles Juan Jos?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130821/bca28e08/attachment.html>\n\n','<CAKCETkcHzc8-UDFx==Dy2i+aHhxdxigcEtU4ussADFghPwKyAA@mail.gmail.com>',NULL),('<1377148608.6522.86.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-22 06:16:48',3600,'2013-08-22 05:16:48',NULL,'[openstack-dev] [Oslo.db] Configuration options','On Thu, 2013-08-22 at 01:14 +0000, Joshua Harlow wrote:\n> Agreed, any thoughts from the oslo folks on how this could be done\n> (without a major refactoring??). Can it even be done?\n> \n> It will be a continuous problem for libraries which want to be\n> integrated with the various openstack projects, especially if those\n> libraries use oslo code, since there is now a weird \'action at a\n> distance\' on config shared between the project and the library. To me\n> this is one of the pain points in a global CFG object, maybe for\n> things that oslo will \'librarize\' those libraries should not have a\n> strong coupling to said global CFG but should prefer a local config\n> \'object\' to be passed in (of which the project using the oslo library\n> can by default pass in the global CFG object to it, if the project\n> desires to use it this way).\n\nTake a look at the oslo.messaging API:\n\nhttp://docs.openstack.org/developer/oslo.messaging/transport.html\n\nSee? No dependence on a global config object. And the ability to connect\nto alternate brokers via a transport_url.\n\nSo, yes - moving any API out of oslo-incubator into a standalone library\nis all about cleaning up issues like this.\n\nMark.\n\n\n\n','<CE3AB1FF.437BE%harlowja@yahoo-inc.com>',NULL),('<1377159462.92917.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 16:17:42',28800,'2013-08-22 08:17:42',NULL,'[Openstack] problem in setting up TempAuth authentication and\n	authrization with swift','hello all \n\n\nI am configuring swift on my PC on Ubuntu 12.04.\n\nafter configuring logging to a single, local file, I have to configure proxy server.\nI changed the swift_hash_path_suffix using the command \n\nroot at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n\nThen, start proxy server process \n\nroot at arun-Aspire-5742:~# sudo swift-init proxy start \n\nStarting proxy-server...(/etc/swift/proxy-server.conf)\n\nnow, I have to set up TempAuth authentication and authrization with swift \n\nFor this, I run following commands:\nroot at arun-Aspire-5742:~# sudo swift-init account start \n\nStarting account-server...(/etc/swift/account-server.conf) \n\nroot at arun-Aspire-5742:~# sudo swift-init proxy restart \n\nSignal proxy-server  pid: 2485  signal: 15 \n\nproxy-server (2485) appears to have stopped \n\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag_2648\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/ \n\n* About to connect() to localhost port 80 (#0) \n\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host \n\n* Closing connection #0\ncurl: (7) couldn\'t connect to host \n\nBut, it shows an error in connecting to host.\n\nPlease help me in this regard.\n\n---\nThanks \n\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/4ada2327/attachment.html>\n\n',NULL,NULL),('<1377159831.90542.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 01:23:51',-25200,'2013-08-22 08:23:51',NULL,'[Openstack] Baremetal OS image support','\n\n\n\n________________________________\n From: Robert Collins <robertc at robertcollins.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Wednesday, August 21, 2013 6:43 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nOn 21 August 2013 21:37, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\n> Hi Rob,\n> Thank you for the info. I look forward to those images.\n>\n> I am using this document for baremetal deployment, which has the -k in it ->\n> https://wiki.openstack.org/wiki/Baremetal\n> This seem to be the only documentation available for how to implement the\n> baremetal feature. Would you know of a better doc?\n\nThat page was a little stale; I\'ve done a super-minimal update to it.\n\nCheers,\nRob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n________________________________\n\n\nThanks for the update.\n\nHowever there is a line in the documentation:\nglance image-create --name deploy-initrd --public --disk-format ari < my-deploy-ramdisk\nThat I am not sure about. After creating the images using diskbuilder, I have no file named \"my-deploy-ramdisk\"\nI do have?my-deploy-ramdisk.initramfs and?my-deploy-ramdisk.kernel.\nIf I were to guess, I should use the?my-deploy-ramdisk.initramfs file for this command?\n\nThanks\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/f4414821/attachment.html>\n\n','<CAJ3HoZ03j_75AKi4r-9gmp04oHDLpT-JhXrJsxyHKor4eR31bA@mail.gmail.com>',NULL),('<1377162085.32501.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 02:01:25',-25200,'2013-08-22 09:01:25',NULL,'[Openstack] Baremetal OS image support','\n\n\n________________________________\n From: Robert Collins <robertc at robertcollins.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Thursday, August 22, 2013 5:25 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nYes. that should be the initramfs; please update the wiki (or let me\nknow and I will).\n\n-Rob\n\nOn 22 August 2013 20:23, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>\n> ________________________________\n> From: Robert Collins <robertc at robertcollins.net>\n> To: Jake G. <dj_dark_junglist at yahoo.com>\n> Sent: Wednesday, August 21, 2013 6:43 PM\n>\n> Subject: Re: [Openstack] Baremetal OS image support\n>\n> On 21 August 2013 21:37, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>> Hi Rob,\n>> Thank you for the info. I look forward to those images.\n>>\n>> I am using this document for baremetal deployment, which has the -k in it\n>> ->\n>> https://wiki.openstack.org/wiki/Baremetal\n>> This seem to be the only documentation available for how to implement the\n>> baremetal feature. Would you know of a better doc?\n>\n> That page was a little stale; I\'ve done a super-minimal update to it.\n>\n> Cheers,\n> Rob\n>\n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n>\n> ________________________________\n>\n> Thanks for the update.\n>\n> However there is a line in the documentation:\n>\n> glance image-create --name deploy-initrd --public --disk-format ari <\n> my-deploy-ramdisk\n>\n> That I am not sure about. After creating the images using diskbuilder, I\n> have no file named \"my-deploy-ramdisk\"\n> I do have my-deploy-ramdisk.initramfs and my-deploy-ramdisk.kernel.\n> If I were to guess, I should use the my-deploy-ramdisk.initramfs file for\n> this command?\n>\n> Thanks\n> Jake\n>\n>\n>\n>\n\n\n________________________________\n\n\nThanks for the clarification. I updated the wiki for you.\n\nOne thing that is missing from the wiki is how to properly prepare the hardware that you want to enroll into openstack.\n1. Does it need to have an OS already installed?\n2. Does it need some sort of PXE driver or similiar?\n\nI am at the point of enrolling my hardware but its just an empty box with no IP and no OS.\n\nThank you\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/c81bdd83/attachment-0001.html>\n\n','<CAJ3HoZ05Hdeo4GTry1D2U7sibkT1aFS=Sd_pgDR2txnYZgMvrw@mail.gmail.com>',NULL),('<1377188270-sup-725@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-22 09:23:38',-25200,'2013-08-22 16:23:38',NULL,'[openstack-dev] Announcing Tuskar project and PTL nominations','Excerpts from Martyn Taylor\'s message of 2013-08-22 04:23:55 -0700:\n> Hi Sylvain,\n> \n> We are currently working on design docs.  We\'ll be adding some \n> architecture diagrams and description to our documentation soon.\n> \n> To answer your question re: provisioning and images.\n> \n> In our currently implementation (which is very early days), we took \n> images that were built from by Triple O, namely the overcloud \n> non-compute and compute images and we use these directly.  in the demo \n> environment you seen in the video, we used Triple O CI to set up the \n> machine, register the relevant overcloud images with glance and so on.\n> \n> In Tuskar, we lifted from TripleO a copy of the triple-o overcloud heat \n> template and made some modifications.  We split out the non-compute and \n> compute sections, this allows us to add multiple entries of each of the \n> non-compute and compute sections (based on what is registered in Tuskar) \n> we then add a section to enforce deployment of the particular images \n> onto particular bare metal machines.  (This allows us to match hardware \n> to OpenStack services).  We do this by using the force_hosts capability \n> in the nova bare metal driver: \n> https://blueprints.launchpad.net/nova/+spec/baremetal-force-node.\n> \n> We also add some extra commands to the Heat template to registers \n> flavors and associates the flavors, host aggregates and baremetal nodes \n> in the overcloud nova control instance.  This allows us to tell the nova \n> scheduler to match any instance requests with flavors that were \n> registered with a resource class in Tuskar with particular hardware that \n> has also been added to that resource class.\n> \n\nThese one-time bootstrap things are difficult to coordinate. We\'ve been\nmoving them out of the instances and into scripts which do it all via\nAPIs. It would be great to coordinate with you on all of this.\n\n> As Tomas mentioned, our initial release is really just a Proof of \n> Concept.  We\'ll be working to add more complex features and probably \n> rework much of our \"short cuts\".  Our aim though is to contribute as \n> much as possible (or as much that makes sense) of Tuskar upstream into \n> TripleO or any other component that we utilize and extend and have \n> Tuskar really concentrate on how to utilize existing components to \n> manage and deploy an OpenStack at large scale.\n\nMartyn, and the rest of the Tuskar team: This is awesome!\n\nThanks so much for sharing and working with us to make this happen. Please\nlet us know if there\'s anything more we can do for you in TripleO.\n\nIn case you aren\'t sending anybody, just a quite invite, it is not too\nlate to book travel to the TripleO sprint at the HPCS offices in Seattle,\nSep 16 - 20. :)\n\n\n','<5215F4CB.6070003@redhat.com>',NULL),('<1377230114.97903.YahooMailNeo@web161605.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-22 20:55:14',-25200,'2013-08-23 03:55:14',NULL,'[Openstack-operators] StackTach setup','Hi,\n\n?I want to unsubscribe form this mailer List. please let me know the link.\n?\nPavan Gupta\n\n\n________________________________\n From: Denis Loshakov <dloshakov at gmail.com>\nTo: Joe Topjian <joe.topjian at cybera.ca> \nCc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \nSent: Thursday, August 22, 2013 7:19 PM\nSubject: Re: [Openstack-operators] StackTach setup\n \n\nYep I think mine version is new one, because if i remove lines about \ntopics and queue I get this error:\nTraceback (most recent call last):\n?  File \"worker/start_workers.py\", line 33, in <module>\n? ?  for exchange in deployment.get(\'topics\').keys():\nAttributeError: \'NoneType\' object has no attribute \'keys\'\n\n\n\nOn 22.08.2013 6:36, Joe Topjian wrote:\n> Sure, here\'s the stacktach_worker_config.json:\n>\n>? ? ? {\n>? ? ? ? ? \"name\": \"openstack\",\n>? ? ? ? ? \"durable_queue\": false,\n>? ? ? ? ? \"rabbit_host\": \"192.168.1.1\",\n>? ? ? ? ? \"rabbit_port\": 5672,\n>? ? ? ? ? \"rabbit_userid\": \"nova\",\n>? ? ? ? ? \"rabbit_password\": \"passyword\",\n>? ? ? ? ? \"rabbit_virtual_host\": \"/\"\n>? ? ? },\n>\n> I\'m not sure about the queue_name param or the topics param. I noticed\n> you have those in your config file but I don\'t have them in mine. I\n> figured since you have a minimum of the same options as me, your config\n> would be OK. I might be running an older version of StackTach, so maybe\n> those options are now needed.\n>\n> Also, here are the options in my nova.conf file:\n>\n> notification_topics=monitor\n> notification_driver=nova.openstack.common.notifier.rabbit_notifier\n> instance_usage_audit_period=hour\n>\n> The last option is only recognized by nova-compute.\n>\n> Hope that helps,\n> Joe\n>\n>\n> On Wed, Aug 21, 2013 at 7:14 AM, Denis Loshakov <dloshakov at gmail.com\n> <mailto:dloshakov at gmail.com>> wrote:\n>\n>? ?  Finally got it up and running.\n>? ?  Problem was in python and path, after second clean install from\n>? ?  scratch everything is fine.\n>? ?  But no luck with data anyway. In manual there is nothing about\n>? ?  \"topics\", also there is custom queue \"queue_name\": \"stacktach\".\n>? ?  Can you explain what it is about? Can you paste your\n>? ?  stacktach_worker_config.json\n>\n>? ?  Thanks\n>\n>\n>? ?  On 21.08.2013 10 <tel:21.08.2013%2010>:39, Denis Loshakov wrote:\n>\n>? ? ? ?  Here is list of pip install:\n>? ? ? ? root at stacktach:/opt/www/__stacktach$ pip install -r\n>? ? ? ?  ./etc/pip-requires.txt\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  Django>=1.4.2\n>? ? ? ?  in /usr/local/lib/python2.7/dist-__packages (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 1))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  MySQL-python>=1.2.3 in /usr/local/lib/python2.7/dist-__packages\n>? ? ? ?  (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 2))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-__packages\n>? ? ? ?  (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 3))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  kombu>=2.4.7\n>? ? ? ?  in /usr/local/lib/python2.7/dist-__packages (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 4))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  librabbitmq>=1.0.0 in /usr/local/lib/python2.7/dist-__packages\n>? ? ? ?  (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 5))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  prettytable>=0.7.2 in /usr/local/lib/python2.7/dist-__packages\n>? ? ? ?  (from -r\n>? ? ? ?  ./etc/pip-requires.txt (line 6))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  argparse in\n>? ? ? ?  /usr/lib/python2.7 (from -r ./etc/pip-requires.txt (line 7))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade): Pympler in\n>? ? ? ?  /usr/local/lib/python2.7/dist-__packages (from -r\n>? ? ? ?  ./etc/pip-requires.txt\n>? ? ? ?  (line 8))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  requests in\n>? ? ? ?  /usr/local/lib/python2.7/dist-__packages (from -r\n>? ? ? ?  ./etc/pip-requires.txt\n>? ? ? ?  (line 9))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade): south in\n>? ? ? ?  /usr/local/lib/python2.7/dist-__packages (from -r\n>? ? ? ?  ./etc/pip-requires.txt\n>? ? ? ?  (line 10))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  greenlet>=0.3\n>? ? ? ?  in /usr/local/lib/python2.7/dist-__packages (from\n>? ? ? ?  eventlet>=0.9.17->-r\n>? ? ? ?  ./etc/pip-requires.txt (line 3))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  anyjson>=0.3.3\n>? ? ? ?  in /usr/local/lib/python2.7/dist-__packages (from kombu>=2.4.7->-r\n>? ? ? ?  ./etc/pip-requires.txt (line 4))\n>? ? ? ?  Requirement already satisfied (use --upgrade to upgrade):\n>? ? ? ?  amqp>=1.0.13,<1.1.0 in /usr/local/lib/python2.7/dist-__packages\n>? ? ? ?  (from\n>? ? ? ?  kombu>=2.4.7->-r ./etc/pip-requires.txt (line 4))\n>? ? ? ?  Cleaning up...\n>\n>\n>? ? ? ?  On 21.08.2013 10 <tel:21.08.2013%2010>:27, Denis Loshakov wrote:\n>\n>? ? ? ? ? ?  Hi, here is some debug info from logfile.\n>? ? ? ? ? ?  2013-08-21 09:24:29,893 - stacktach.stacklog - ERROR -\n>? ? ? ? ? ?  name=cloudcat,\n>? ? ? ? ? ?  exchange=glance, exception=No module named librabbitmq.\n>? ? ? ? ? ?  Reconnecting\n>? ? ? ? ? ?  in 5s\n>? ? ? ? ? ?  Traceback (most recent call last):\n>? ? ? ? ? ? ? ?  File \"/opt/www/stacktach/worker/__worker.py\", line 182,\n>? ? ? ? ? ?  in run\n>? ? ? ? ? ? ? ? ?  consumer.run()\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/mixins.py\"__, line\n>? ? ? ? ? ?  164, in run\n>? ? ? ? ? ? ? ? ?  errors = (self.connection.connection___errors +\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/utils/____init__.py\",\n>? ? ? ? ? ?  line\n>? ? ? ? ? ?  294, in __get__\n>? ? ? ? ? ? ? ? ?  value = obj.__dict__[self.__name__] = self.__get(obj)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/__connection.py\",\n>? ? ? ? ? ?  line 822, in connection_errors\n>? ? ? ? ? ? ? ? ?  return self.transport.connection___errors\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/__connection.py\",\n>? ? ? ? ? ?  line 789, in transport\n>? ? ? ? ? ? ? ? ?  self._transport = self.create_transport()\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/__connection.py\",\n>? ? ? ? ? ?  line 528, in create_transport\n>? ? ? ? ? ? ? ? ?  return self.get_transport_cls()(__client=self)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/__connection.py\",\n>? ? ? ? ? ?  line 535, in get_transport_cls\n>? ? ? ? ? ? ? ? ?  transport_cls = get_transport_cls(transport___cls)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/transport/____init__.py\",\n>? ? ? ? ? ?  line 105, in get_transport_cls\n>? ? ? ? ? ? ? ? ?  _transport_cache[transport] = resolve_transport(transport)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/transport/____init__.py\",\n>? ? ? ? ? ?  line 89, in resolve_transport\n>? ? ? ? ? ? ? ? ?  return symbol_by_name(transport)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/utils/____init__.py\",\n>? ? ? ? ? ?  line\n>? ? ? ? ? ?  80, in symbol_by_name\n>? ? ? ? ? ? ? ? ?  module = imp(module_name, package=package, **kwargs)\n>? ? ? ? ? ? ? ?  File \"/usr/lib/python2.7/importlib/____init__.py\", line\n>? ? ? ? ? ?  37, in\n>? ? ? ? ? ?  import_module\n>? ? ? ? ? ? ? ? ?  __import__(name)\n>? ? ? ? ? ? ? ?  File\n>? ? ? ? ? ?  \"/usr/local/lib/python2.7/__dist-packages/kombu/transport/__librabbitmq.py\",\n>? ? ? ? ? ?  line 23, in <module>\n>? ? ? ? ? ? ? ? ?  raise ImportError(\"No module named librabbitmq\")\n>? ? ? ? ? ?  ImportError: No module named librabbitmq\n>\n>\n>\n>? ? ? ? ? ?  On 21.08.2013 8:19, Denis Loshakov wrote:\n>\n>? ? ? ? ? ? ? ?  Hi, thank fro quick reply.\n>? ? ? ? ? ? ? ?  Here is output from start_workers.y process.\n>? ? ? ? ? ? ? ? root at stacktach:/opt/www/__stacktach$ python\n>? ? ? ? ? ? ? ?  worker/start_workers.py\n>? ? ? ? ? ? ? ?  Starting worker for \'cloudmouse nova\'\n>? ? ? ? ? ? ? ?  Starting worker for \'cloudmouse glance\'\n>? ? ? ? ? ? ? ?  Starting worker for \'cloudmouse keystone\'\n>\n>? ? ? ? ? ? ? ?  Ah, there is logfile, didn\'t know that (my shame).\n>? ? ? ? ? ? ? ?  There are plenty errors, I think i\'ll do from scratch\n>? ? ? ? ? ? ? ?  and ley you know\n>? ? ? ? ? ? ? ?  results.\n>\n>? ? ? ? ? ? ? ?  Thanks for tip.\n>\n>? ? ? ? ? ? ? ?  On 20.08.2013 17:11, Joe Topjian wrote:\n>\n>? ? ? ? ? ? ? ? ? ?  Hi Denis,\n>\n>? ? ? ? ? ? ? ? ? ?  Thanks for the configs. I verified them against mine\n>? ? ? ? ? ? ? ? ? ?  and they look\n>? ? ? ? ? ? ? ? ? ?  good.\n>\n>? ? ? ? ? ? ? ? ? ?  When you run start_workers.py, do you see anything\n>? ? ? ? ? ? ? ? ? ?  printed out such as\n>? ? ? ? ? ? ? ? ? ?  \"Starting worker for openstack_devel\"? This is done\n>? ? ? ? ? ? ? ? ? ?  here:\n>\n>? ? ? ? ? ? ? ? ? ? https://github.com/rackerlabs/__stacktach/blob/master/worker/__worker.py#L161\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/rackerlabs/stacktach/blob/master/worker/worker.py#L161>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ?  Additionally, there should be a worker.log file\n>? ? ? ? ? ? ? ? ? ?  where line 162 will be\n>? ? ? ? ? ? ? ? ? ?  printed.\n>\n>? ? ? ? ? ? ? ? ? ?  I just want to confirm you\'re seeing those\n>? ? ? ? ? ? ? ? ? ?  logs/messages because if you\n>? ? ? ? ? ? ? ? ? ?  don\'t, something might be wrong with the workers\n>? ? ? ? ? ? ? ? ? ?  themselves prior to\n>? ? ? ? ? ? ? ? ? ?  reaching Rabbit.\n>\n>? ? ? ? ? ? ? ? ? ?  Thanks,\n>? ? ? ? ? ? ? ? ? ?  Joe\n>\n>\n>? ? ? ? ? ? ? ? ? ?  On Tue, Aug 20, 2013 at 4:27 AM, Denis Loshakov\n>? ? ? ? ? ? ? ? ? ?  <dloshakov at gmail.com <mailto:dloshakov at gmail.com>\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com>>> wrote:\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? Hello, thanks for help.\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? First about configs:\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? stacktach_config.sh:\n>? ? ? ? ? ? ? ? ? ? ? ? ? export STACKTACH_DB_NAME=\"stacktach\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export STACKTACH_DB_HOST=\"\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export STACKTACH_DB_USERNAME=\"____stacktach\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export STACKTACH_DB_PASSWORD=\"____stacktach123\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export STACKTACH_DB_PORT=\"3306\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export\n>? ? ? ? ? ? ? ? ? ?  STACKTACH_INSTALL_DIR=\"/opt/____www/stacktach/\"\n>? ? ? ? ? ? ? ? ? ? ? ? ? export\n>\n>? ? ? ? ? ? ? ? ? ?  STACKTACH_DEPLOYMENTS_FILE=\"/____opt/www/stacktach/etc/____stacktach_worker_config.json\"\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? export\n>\n>? ? ? ? ? ? ? ? ? ?  STACKTACH_VERIFIER_CONFIG=\"/____opt/www/stacktach/etc/____stacktach_verifier_config.____json\"\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? export DJANGO_SETTINGS_MODULE=\"____settings\"\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? stacktach_worker_config.json:\n>? ? ? ? ? ? ? ? ? ? ? ? ? {\"deployments\": [\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  {\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"name\": \"openstack_devel\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"durable_queue\": false,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit_host\": \"10.0.2.20\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit_port\": 5672,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit_userid\": \"nova\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit_password\": \"nova\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit_virtual_host\": \"/\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"exit_on_exception\": false,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"queue_name\": \"stacktach\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"topics\": {\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"nova\": [\"monitor.info\n>? ? ? ? ? ? ? ? ? ?  <http://monitor.info> <http://monitor.info>\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? \"monitor.error\"],\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"glance\": [\"monitor_glance.info\n>? ? ? ? ? ? ? ? ? ?  <http://monitor_glance.info>\n>? ? ? ? ? ? ? ? ? ? ? ? ? <http://monitor_glance.info>\",\n>? ? ? ? ? ? ? ? ? ?  \"monitor_glance.error\"],\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"keystone\":\n>? ? ? ? ? ? ? ? ? ?  [\"monitor_keystone.info <http://monitor_keystone.info>\n>? ? ? ? ? ? ? ? ? ? ? ? ? <http://monitor_keystone.info>__\",\n>? ? ? ? ? ? ? ? ? ?  \"monitor_keystone.error\"]\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  }\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  }]\n>? ? ? ? ? ? ? ? ? ? ? ? ? }\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? stacktach_verifier_config.____json:\n>? ? ? ? ? ? ? ? ? ? ? ? ? {\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"tick_time\": 30,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"settle_time\": 5,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"settle_units\": \"minutes\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"pool_size\": 2,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"enable_notifications\": true,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"rabbit\": {\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"durable_queue\": false,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"host\": \"10.0.2.20\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"port\": 5672,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"userid\": \"nova\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"password\": \"nova\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"virtual_host\": \"/\",\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"topics\": {\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"nova\": [\"notifications.info\n>? ? ? ? ? ? ? ? ? ?  <http://notifications.info>\n>? ? ? ? ? ? ? ? ? ?  <http://notifications.info>\"],\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"glance\": [\"notifications.info\n>? ? ? ? ? ? ? ? ? ?  <http://notifications.info>\n>? ? ? ? ? ? ? ? ? ? ? ? ? <http://notifications.info>\"],\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  \"keystone\": [\"notifications.info\n>? ? ? ? ? ? ? ? ? ?  <http://notifications.info>\n>? ? ? ? ? ? ? ? ? ? ? ? ? <http://notifications.info>\"]\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  }\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  }\n>? ? ? ? ? ? ? ? ? ? ? ? ? }\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? Testing connectivity with Rabbit host:\n>? ? ? ? ? ? ? ? ? ? ? ? ? root at stacktach:/opt/www/____stacktach/etc$\n>? ? ? ? ? ? ? ? ? ?  telnet 10.0.2.20 5672\n>? ? ? ? ? ? ? ? ? ? ? ? ? Trying 10.0.2.20...\n>? ? ? ? ? ? ? ? ? ? ? ? ? Connected to 10.0.2.20.\n>? ? ? ? ? ? ? ? ? ? ? ? ? Escape character is \'^]\'.\n>? ? ? ? ? ? ? ? ? ? ? ? ? qeqw\n>? ? ? ? ? ? ? ? ? ? ? ? ? ^]\n>? ? ? ? ? ? ? ? ? ? ? ? ? telnet> quit\n>? ? ? ? ? ? ? ? ? ? ? ? ? Connection closed.\n>? ? ? ? ? ? ? ? ? ? ? ? ? root at stacktach:/opt/www/____stacktach/etc$\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? Run simple web server:\n>? ? ? ? ? ? ? ? ? ? ? ? ? python manage.py runserver 10.0.2.18:8000\n>? ? ? ? ? ? ? ? ? ?  <http://10.0.2.18:8000> <http://10.0.2.18:8000>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? Create database and populate it:\n>? ? ? ? ? ? ? ? ? ? ? ? ? python manage.py syncdb\n>? ? ? ? ? ? ? ? ? ? ? ? ? python manage.py migrate\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? And finally run workers:\n>? ? ? ? ? ? ? ? ? ? ? ? ? python ../worker/start_workers.py\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? I tried to sniff by port 5672 or sniff by\n>? ? ? ? ? ? ? ? ? ?  src/dst nothing.\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? Thats my story.\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? On 19.08.2013 17:36, Joe Topjian wrote:\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Hi Denis,\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? I have a StackTach installation from quite\n>? ? ? ? ? ? ? ? ? ?  a while ago --\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? probably from\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? when the manual was relevant, so I can try\n>? ? ? ? ? ? ? ? ? ?  to help.\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? What issue are you running into? Can you\n>? ? ? ? ? ? ? ? ? ?  confirm that your\n>? ? ? ? ? ? ? ? ? ?  stacktach\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? workers are connecting to your Rabbit\n>? ? ? ? ? ? ? ? ? ?  server? Have you added\n>? ? ? ? ? ? ? ? ? ?  the\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? additional notification options to nova to\n>? ? ? ? ? ? ? ? ? ?  have it send\n>? ? ? ? ? ? ? ? ? ?  events to\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Rabbit? Can you reach the webpage without\n>? ? ? ? ? ? ? ? ? ?  error?\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Thanks,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Joe\n>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? On Mon, Aug 19, 2013 at 7:35 AM, Denis Loshakov\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <dloshakov at gmail.com\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com>\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com>>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <mailto:dloshakov at gmail.com\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com>\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com\n>? ? ? ? ? ? ? ? ? ?  <mailto:dloshakov at gmail.com>>>>\n>? ? ? ? ? ? ? ? ? ?  wrote:\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  Hi, I\'ve tried to setup StackTach\n>? ? ? ? ? ? ? ? ? ? https://github.com/rackerlabs/______stacktach\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/rackerlabs/____stacktach>\n>\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/__rackerlabs/__stacktach\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/rackerlabs/__stacktach>>\n>\n>? ? ? ? ? ? ? ? ? ? ?  <https://github.com/____rackerlabs/stacktach\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/__rackerlabs/stacktach>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <https://github.com/__rackerlabs/stacktach\n>? ? ? ? ? ? ? ? ? ?  <https://github.com/rackerlabs/stacktach>>>. The\n>? ? ? ? ? ? ? ? ? ?  manual is\n>? ? ? ? ? ? ? ? ? ?  not so\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  fresh but I managed to setup, but\n>? ? ? ? ? ? ? ? ? ?  stacktach doesn\'t go to\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Rabbit server.\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  Any one have any experience with\n>? ? ? ? ? ? ? ? ? ?  StackTach setup?\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  Thanks.\n>\n>\n>? ? ? ? ? ? ? ? ? ? ?  _____________________________________________________\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  OpenStack-operators mailing list\n>\n>? ? ? ? ? ? ? ? ? ? ? OpenStack-operators at lists.__op____enstack.org\n>? ? ? ? ? ? ? ? ? ?  <http://op__enstack.org>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? <http://openstack.org>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  <mailto:OpenStack-operators@\n>? ? ? ? ? ? ? ? ? ?  <mailto:OpenStack-operators@>____lists.openstack.org\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org>\n>\n>? ? ? ? ? ? ? ? ? ?  <mailto:OpenStack-operators at __lists.openstack.org\n>? ? ? ? ? ? ? ? ? ?  <mailto:OpenStack-operators at lists.openstack.org>>>\n>\n>? ? ? ? ? ? ? ? ? ? http://lists.openstack.org/______cgi-bin/mailman/listinfo/______openstack-operators\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>\n>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>>\n>\n>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>\n>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators\n>? ? ? ? ? ? ? ? ? ?  <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>>>\n>\n>\n>\n>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? --\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Joe Topjian\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Systems Architect\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Cybera Inc.\n>\n>? ? ? ? ? ? ? ? ? ?  www.cybera.ca <http://www.cybera.ca>\n>? ? ? ? ? ? ? ? ? ?  <http://www.cybera.ca> <http://www.cybera.ca>\n>\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Cybera is a not-for-profit organization\n>? ? ? ? ? ? ? ? ? ?  that works to spur and\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? support\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? innovation, for the economic benefit of\n>? ? ? ? ? ? ? ? ? ?  Alberta, through the\n>? ? ? ? ? ? ? ? ? ?  use\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? of cyberinfrastructure.\n>\n>\n>\n>\n>? ? ? ? ? ? ? ? ? ?  --\n>? ? ? ? ? ? ? ? ? ?  Joe Topjian\n>? ? ? ? ? ? ? ? ? ?  Systems Architect\n>? ? ? ? ? ? ? ? ? ?  Cybera Inc.\n>\n>? ? ? ? ? ? ? ? ? ?  www.cybera.ca <http://www.cybera.ca>\n>? ? ? ? ? ? ? ? ? ?  <http://www.cybera.ca>\n>\n>? ? ? ? ? ? ? ? ? ?  Cybera is a not-for-profit organization that works\n>? ? ? ? ? ? ? ? ? ?  to spur and support\n>? ? ? ? ? ? ? ? ? ?  innovation, for the economic benefit of Alberta,\n>? ? ? ? ? ? ? ? ? ?  through the use\n>? ? ? ? ? ? ? ? ? ?  of cyberinfrastructure.\n>\n>\n>\n>\n> --\n> Joe Topjian\n> Systems Architect\n> Cybera Inc.\n>\n> www.cybera.ca <http://www.cybera.ca>\n>\n> Cybera is a not-for-profit organization that works to spur and support\n> innovation, for the economic benefit of Alberta, through the use\n> of cyberinfrastructure.\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130822/94344201/attachment.html>\n\n','<521616E5.7080608@gmail.com>',NULL),('<1377232649.77354.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 21:37:29',-25200,'2013-08-23 04:37:29',NULL,'[Openstack] Baremetal - Hardware preparation','Hi all,\n\nI have been following this doc?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?\nto setup openstack for baremetal provisioning. I have configured oopenstack properly, created an image,\nand now I am ready to enroll my physical hardware. However, there seems to be no mention of how to?\nprepare my physical hardware.\n\nDoes anyone know what is required and what is the process to prepare my hardware?\n\nThank you for your help,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/9d8db5a7/attachment.html>\n\n',NULL,NULL),('<1377239024.42573.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 23:23:44',-25200,'2013-08-23 06:23:44',NULL,'[Openstack] Baremetal - Hardware preparation','I understand your points and that is taken care of, but how exactly is Openstack going to connect to the hardware if the hardware has no OS and no IP?\nHow should the hardware be prepared so I can give Openstack the information it needs to enroll the hardware??\n\n\nThanks,\nJake\n\n\n\n\n________________________________\n From: \"K, Shanthakumar\" <shanthakumar.k at hp.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 23, 2013 3:08 PM\nSubject: RE: [Openstack] Baremetal - Hardware preparation\n \n\n\n \nHi Jake,\n?\nYour physical hardware should be maximum enough to support your OS configurations and ?baremetal flavor you have created.\n?\nEx: \n1.?????? Your physical hardware should contain minimum configurations to run an operating system\n2.?????? You need to take care of your Baremetal Flavor created WRT to your available hardware.\n??????????????? \n?\nThanks\nShanthakumar K\n?\nFrom:Jake G. [mailto:dj_dark_junglist at yahoo.com] \nSent: Friday, August 23, 2013 10:07 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Baremetal - Hardware preparation\n?\nHi all,\n?\nI have been following this doc?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?\nto setup openstack for baremetal provisioning. I have configured oopenstack properly, created an image,\nand now I am ready to enroll my physical hardware. However, there seems to be no mention of how to?\nprepare my physical hardware.\n?\nDoes anyone know what is required and what is the process to prepare my hardware?\n?\nThank you for your help,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/bca02ff0/attachment.html>\n\n','<23261B8C079082499641DD0AE94EA2BF191F930F@G9W0337.americas.hpqcorp.net>',NULL),('<1377240310.80684.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-22 23:45:10',-25200,'2013-08-23 06:45:10',NULL,'[Openstack] Baremetal - Hardware preparation','I am sorry if my explanation was hard to follow.\n\nIn order to enroll my hardware, Openstack requires the Servers IP address, username and password.\nSince I have no OS installed on the hardware(physical server) I have no IP address and no username/password\n\nOn the hardware side only(not openstack) what needs to be done in order for Openstack to control the hardware?\n\nThanks\n\n\n\n________________________________\n From: \"K, Shanthakumar\" <shanthakumar.k at hp.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 23, 2013 3:32 PM\nSubject: RE: [Openstack] Baremetal - Hardware preparation\n \n\n\n \nPlease refer the hardware enrollment section under https://wiki.openstack.org/wiki/Baremetal.\n?\n1.????? Ensure your hardware is under same network backbone to communicate\n2.????? Enroll the hardware properly as mentioned in the guide \n3.????? Nova baremetal driver will take care of the communication and you could see the logs in nova compute upon successful enrollment \n?\nThanks\nShanthakumar K\n?\nFrom:Jake G. [mailto:dj_dark_junglist at yahoo.com] \nSent: Friday, August 23, 2013 11:54 AM\nTo: K, Shanthakumar\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Baremetal - Hardware preparation\n?\nI understand your points and that is taken care of, but how exactly is Openstack going to connect to the hardware if the hardware has no OS and no IP?\nHow should the hardware be prepared so I can give Openstack the information it needs to enroll the hardware??\n?\nThanks,\nJake\n?\n?\n?\n\n________________________________\n \nFrom:\"K, Shanthakumar\" <shanthakumar.k at hp.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 23, 2013 3:08 PM\nSubject: RE: [Openstack] Baremetal - Hardware preparation\n?\nHi Jake,\n?\nYour physical hardware should be maximum enough to support your OS configurations and ?baremetal flavor you have created.\n?\nEx: \n1.?????? Your physical hardware should contain minimum configurations to run an operating system\n2.?????? You need to take care of your Baremetal Flavor created WRT to your available hardware.\n??????????????? \n?\nThanks\nShanthakumar K\n?\nFrom:Jake G. [mailto:dj_dark_junglist at yahoo.com] \nSent: Friday, August 23, 2013 10:07 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Baremetal - Hardware preparation\n?\nHi all,\n?\nI have been following this doc?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?\nto setup openstack for baremetal provisioning. I have configured oopenstack properly, created an image,\nand now I am ready to enroll my physical hardware. However, there seems to be no mention of how to?\nprepare my physical hardware.\n?\nDoes anyone know what is required and what is the process to prepare my hardware?\n?\nThank you for your help,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130822/3cf6d311/attachment.html>\n\n','<23261B8C079082499641DD0AE94EA2BF191F9357@G9W0337.americas.hpqcorp.net>',NULL),('<1377243817.36194.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-23 15:43:37',28800,'2013-08-23 07:43:37',NULL,'[Openstack] Does devstack installs swift?','Hi,\n\nI have installed openstack using devstack on Ubuntu 12.04 LTS.\nI tried to find swift in the installation, but couldn\'t. I mean, all other\ncomponents are there like nova, cinder, horizon etc. but there is no\nswift. I couldn\'t find any process by the name of swift either. Is it the?\ncase that devstack doesn\'t install swift? If yes, then how can I install\nit explicitly?\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130823/d7c12bd9/attachment.html>\n\n',NULL,NULL),('<1377270422.589115380@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-23 11:07:02',-14400,'2013-08-23 15:07:02',NULL,'[openstack-dev] [Glance] import task meeting 15:00 UTC Monday\n	26 August','It works for me and I\'ll have some research done on the bullet points until then.\n\nthanks,\n-Nikhil\n\n-----Original Message-----\nFrom: \"Brian Rosmaita\" <brian.rosmaita at RACKSPACE.COM>\nSent: Friday, August 23, 2013 9:33am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Glance] import task meeting 15:00 UTC Monday 26 August\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nWould 15:00 UTC Tuesday 27 August work for all interested parties?\n________________________________\nFrom: Joshua Harlow [harlowja at yahoo-inc.com]\nSent: Thursday, August 22, 2013 9:13 PM\nTo: OpenStack Development Mailing List\nCc: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Glance] import task meeting 15:00 UTC Monday 26 August\n\nMaybe lets try tuesday?\n\nSent from my really tiny device...\n\nOn Aug 22, 2013, at 3:38 PM, \"Mark Washenberger\" <mark.washenberger at markwash.net<mailto:mark.washenberger at markwash.net>> wrote:\n\nEek, I might not actually be able to make this time on Monday. I\'m free from 9:30 Pacific Monday and on. Would Tuesday work? Or tomorrow?\n\n\nOn Thu, Aug 22, 2013 at 2:33 PM, Brian Rosmaita <brian.rosmaita at rackspace.com<mailto:brian.rosmaita at rackspace.com>> wrote:\nWe\'re shooting for 15:00 UTC Monday 26 August.  (Let me know ASAP if you really want to be in on this and can\'t make it, but this is probably the best time available.)\n\nTopics:\n(1) taskflow seam for integration\n(2) tasks api and executor interface\n(3) indexable column in db for tasks to be queryable\n\nSee http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-08-22-20.02.log.html for brief discussion of these topics during today\'s glance meeting.\n\nMore info:\nhttps://etherpad.openstack.org/havana-glance-requirements\nhttps://etherpad.openstack.org/LG39UnQA7z\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<4D27423EB14FEE4E9E5F88A15764C51A7EC3F289@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1377272247-sup-5114@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-23 08:38:03',-25200,'2013-08-23 15:38:03',NULL,'[openstack-dev] [heat] Propose Liang Chen for heat-core','Excerpts from Steven Hardy\'s message of 2013-08-22 08:57:31 -0700:\n> Hi,\n> \n> I\'d like to propose that we add Liang Chen to the heat-core team[1]\n> \n> Liang has been doing some great work recently, consistently providing good\n> review feedback[2][3], and also sending us some nice patches[4][5], implementing\n> several features and fixes for Havana.\n> \n> Please respond with +1/-1.\n> \n\n+1 and huzzah!\n\n\n','<20130822155730.GA2236@t430slt.redhat.com>',NULL),('<1377320682.35716.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-24 13:04:42',28800,'2013-08-24 05:04:42',NULL,'[Openstack] Fw: problem in setting up TempAuth authentication and\n	authrization with swift','hello sir!\n\nI tried the commands again.\n\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# sudo useradd swift\nuseradd: user \'swift\' already exists\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy restart\nSignal proxy-server? pid: 2514? signal: 15\nproxy-server (2514) appears to have stopped\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy restart\nSignal proxy-server? pid: 3008? signal: 15\nproxy-server (3008) appears to have stopped\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~#\n curl -v -H \'X-Auth-User:prag_2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n*?? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\nagain, the same problem is coming.\nBut if I am giving the  command \nsudo swift-init proxy start\nIt shows proxy server is running\n\nroot at arun-Aspire-5742:~# sudo swift-init proxy startproxy-server running (3024 - /etc/swift/proxy-server.conf)\nproxy-server already started...\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag_2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n*?? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\n\nPlease help me in this regard.\n\n---\n\nThanksPragya Jain\n\n\n\n----- Forwarded Message -----\n>From: pragya jain <prag_2648 at yahoo.co.in>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 22 August 2013 1:47 PM\n>Subject: problem in setting up TempAuth authentication and authrization with swift\n> \n>\n>\n>hello all \n>\n>\n>\n>I am configuring swift on my PC on Ubuntu 12.04.\n>\n>\n>after configuring logging to a single, local file, I have to configure proxy server.\n>I changed the swift_hash_path_suffix using the command \n>\n>root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>\n>\n>Then, start proxy server process \n>\n>root at arun-Aspire-5742:~# sudo swift-init proxy start \n>\n>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>\n>\n>now, I have to set up TempAuth authentication and authrization with swift \n>\n>For this, I run following commands:\n>root at arun-Aspire-5742:~# sudo swift-init account start \n>\n>Starting account-server...(/etc/swift/account-server.conf) \n>\n>root at arun-Aspire-5742:~# sudo swift-init proxy restart \n>\n>Signal proxy-server  pid: 2485  signal: 15 \n>\n>proxy-server (2485) appears to have stopped \n>\n>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag_2648\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/ \n>\n>* About to connect() to localhost port 80 (#0) \n>\n>*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host \n>\n>* Closing connection #0\ncurl: (7) couldn\'t connect to host \n>\n>\n>But, it shows an error in connecting to host.\n>\n>\n>Please help me in this regard.\n>\n>\n>---\n>Thanks \n>\n>\n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130824/676d020e/attachment.html>\n\n','<1377159462.92917.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1377329547.76843.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-24 15:32:27',28800,'2013-08-24 07:32:27',NULL,'[Openstack] problem in editing swift_hash_path_suffix','hello,\n\nI have to configure proxy server.\nFor this, \n\nI have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n\nfor this, I use the following commands:\nroot at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n\n\nwith this command, swift.conf file is opened:\n\n[swift-hash]\n\n# swift_hash_path_suffix and swift_hash_path_prefix are used as part of the\n# the hashing algorithm when determining data placement in the cluster.\n# These values should remain secret and MUST NOT change\n# once a cluster has been\n deployed.\n\nswift_hash_path_suffix = changeme\nswift_hash_path_prefix = changeme\n\n\n# The swift-constraints section sets the basic constraints on data\n# saved in the swift cluster.\n\n[swift-constraints]\n\n# max_file_size is the largest \"normal\" object that can be saved in\n# the cluster. This is also the limit on the size of each segment of\n# a \"large\" object when using the large object manifest support.\n# This value is set in bytes. Setting it to lower than 1MiB will cause\n# some tests to fail. It is STRONGLY recommended to leave this value at\n# the default (5 * 2**30 + 2).\n\n#max_file_size = 5368709122\n\n\n# max_meta_name_length is the max number of bytes in the utf8 encoding\n# of the name portion of a metadata header.\n\n#max_meta_name_length = 128\n\n\n# max_meta_value_length is the max number of bytes in the utf8 encoding\n# of a metadata value\n\n#max_meta_value_length =\n 256\n\n\n# max_meta_count is the max number of metadata keys that can be stored\n# on a single account, container, or object\n\nbut, I am not able to change the value of swift_hash_path_suffix.\nPlease help me in this regard.\n\n---\nThanks\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130824/469293e0/attachment.html>\n\n',NULL,NULL),('<1377407699.6563141.1353664508297.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 04:55:08',-18000,'2012-11-23 09:55:08',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n> Angus Salkeld wrote:\n>\n> Another option:\n> We implement a collector plugin in nova that gets configured in\n> ceilometer.conf as the compute instrumentator.\n\nSo this plugin lives in the nova repo and then get loaded by the\nceilo compute agent?\n\nWouldn\'t we have to address the same kind of versioning issues?\n\ni.e. ceilo would want to pick up a stable version of the nova plugin,\nand the nova plugin would need to depend on a stable version of\nwhatever ceilo interface it uses to publish the measurements.\n\nCheers,\nEoghan\n\n> Then ceilometer doesn\'t have to implement anything specific at all.\n> We do still need a list_instances() but that\'s all.\n> \n> I thought that we have support for this right now in ceilometer.\n> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/manager.py\n> \n> We just move the plugin to nova and use it.\n> \n> - Fast (no rest or rpc)\n> - ceilometer controls the sampling rate\n> - no duplicate code\n> - easier to add support for the other virt types in nova where\n>    the code and knowledge is.\n> \n> Angus\n> \n> >\n> >But just to confirm I understand the suggestion, by *direct* usage\n> >do you mean simply calling the currently installed nova virt code\n> >but at a level that is unlikely to change? (say by pushing some\n> >internals of the driver implementation into the driver API)\n> >\n> >> You\'d be right to be concerned that you\'d need to implement that\n> >> same code for other hypervisors, but here\'s the thing - the\n> >> get_disks() and block_stats() methods in the libvirt virt driver\n> >> aren\'t part of the virt driver abstraction. Other drivers neither\n> >> implement them, nor do we have common data structures for the\n> >> values\n> >> they\'d return. In other words, the abstraction layer with multiple\n> >> implementations doesn\'t yet exist.\n> >\n> >Yeah, looking at the inconsistencies in the level of support for the\n> >ComputeDriver.get_diagnostics() function, I was figuring we\'d need\n> >to\n> >potentially live with the API used by ceilo not being universally\n> >supported across all hypervisors initially (but it still would be\n> >less limiting than a direct libvirt dependency).\n> >\n> >> You know what\'s weird? The get_disks() and block_stats() methods\n> >> appear unused in Nova.\n> >\n> >Yeah, I think pretty much the same logic is re-implemented in\n> >LibvirtDriver.get_diagnostics.get_io_devices() in the libvirt case\n> >at least - not good!\n> >\n> >> > But in any case, one concern with nova-compute emitting these\n> >> > data\n> >> > as either notifications or else making direct calls into a\n> >> > ceilo-\n> >> > provided library was that such a loaded service is likely to\n> >> > run into timeliness issues.\n> >>\n> >> If the data is purely for metering, the timeliness issue isn\'t a\n> >> concern right?\n> >\n> >Less of an issue certainly for pure metering (longer period, less\n> >sensitive to irregular cadence).\n> >\n> >> > There\'s been a fair amount of fuzziness around the distinction\n> >> > between instrumentation and monitoring, but this falls into the\n> >> > latter camp for me. Its not so much about the internal dynamics\n> >> > of nova, as the user-visible behavior (e.g. is my instance\n> >> > running\n> >> > hot or am I pushing loads of data through the network, as\n> >> > opposed\n> >> > how long did that API call to update the instance take to\n> >> > service\n> >> > end-to-end or how many connections are in that pool).\n> >>\n> >> Metering vs monitoring/instrumentation, not monitoring vs\n> >> instrumentation :)\n> >\n> >I kinda see the split more as metering/monitoring vs\n> >instrumentation.\n> >\n> >Well, actually more like metering/user-oriented-monitoring vs\n> >cloud-operator-oriented-monitoring/instrumentation.\n> >\n> >Currently ceilo is aiming to at least address both metering and\n> >user-oriented-monitoring, and possibly more in time.\n> >\n> >> If we were just designing a solution for metering, would we go for\n> >> the notifications option?\n> >\n> >Probably, but the scope of ceilo has widened a bit from pure\n> >metering.\n> >\n> >Cheers,\n> >Eoghan\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20121122223235.GA22689@redhat.com>',NULL),('<1377498985.92309.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-26 14:36:25',28800,'2013-08-26 06:36:25',NULL,'[Openstack] problem in setting up Tempauth authentication &\n	authorization with Swift','hello,\n\nI have to configure proxy server.\nFor this, \n\nI have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n\nfor this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n\nmake following changes (highlighted) in the file:\nswift_hash_path_suffix =pragya \nswift_hash_path_prefix =jain \n\nsave and exit.\nthen, I run the command:\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\n\nNow, I have to set up Tempauth authentication & authorization with Swift\nfor this, I run the following command:\nroot at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n\nmake following changes (highlighted) in the file:\nallow_account_management =true \n...\n[filter:tempauth]\nuse = egg:swift#tempauth\n...\nuser_admin_admin = admin .admin .reseller_admin\nuser_test_tester = testing .admin\nuser_test2_tester2 = testing2 .admin\nuser_test_tester3 = testing3\nuser_prag2648_pragya = pj2648.admin.reseller_admin\n...\n\nsave and exit\nThen, run following commands:\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy restart\nSignal proxy-server? pid: 2476? signal: 15\nproxy-server (2476) appears to have stopped\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n*?? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\nBut, there is an error in establising a connection.\n\nif, I run the command to start proxy server, then it shows that proxy server is already started.\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nproxy-server running (2935 - /etc/swift/proxy-server.conf)\nproxy-server already started...\n\nPlease help me in this regard.\n---\n\nThanks \n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130826/f189121a/attachment.html>\n\n',NULL,NULL),('<1377516022.12220.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-26 19:20:22',28800,'2013-08-26 11:20:22',NULL,'[Openstack] Is Packstack a development environment?','Hi all,\n\nI have been using openstack through devstack on Ubuntu 12.04 LTS.\nNow, I want to try out packstack, but before that I want to know if I\nwould similar environment through packstack. I can make changes in the\nfile present in /opt/stack directory and can see the changes reflected. Is it\npossible with packstack? Does packstack only provides easier installation\nor is a development environment too?\n\nThanks,\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130826/c277dc75/attachment.html>\n\n',NULL,NULL),('<1377530689.79522.YahooMailNeo@web172405.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-26 16:24:49',3600,'2013-08-26 15:24:49',NULL,'[Openstack] Intermittent connectivity problems from\n	qrouter	namespace','\n\nbadly configured tunnels can cause the symptoms you see. So you\ncould focus on that if your quantum network is using gre tunnels. \n\nRun \'ovs-vsctl show\' on each node and check the remote_ip of each\nport on br-tun. \n\n\n>________________________________\n> From: Mina Nagy Zaki <mnzaki at gmail.com>\n>To: openstack <openstack at lists.openstack.org> \n>Sent: Saturday, 24 August 2013, 11:38\n>Subject: [Openstack] Intermittent connectivity problems from qrouter????namespace\n> \n>\n>I\'m using nova 2013.1.2 with quantum/neutron.\n>\n>I have a router with a fixed net and an external gateway. There\'s\n>unexplained packet loss from the router\'s network namespace to the\n>VM\'s fixed IPs. I\'ve seen it with ARP requests, ping requests, and\n>pretty much everything else. Sometimes they just don\'t go through for\n>a while. I\'ve also seen a pattern of 2s, 1s, 0.5s ping times on the\n>first 3 packets, then normal ping times of <1ms.\n>VM -> external network traffic is working great though.\n>\n>I\'ve tried monitoring the OVS flows and they don\'t seem to change.\n>I\'ve been tcpdumping the interfaces, and packets simply fail to make\n>it over the qbrXXXXX bridge sometimes.\n>\n>Also, after a \'warm up\' period of trying to ping the machines and\n>failing, once a few packets make it through it starts working\n>semi-reliably.\n>\n>I\'m lost. Where do I start with this????\n>\n>-- \n>Mina Nagy Zaki\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ???: openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n\n\n','<CA+wCMiZHf8tMinkt8Z-eWS8zzgrUBF2GDOoefzr966a6pucJZQ@mail.gmail.com>',NULL),('<1377538642.635325460@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-27 03:37:22',36000,'2013-08-26 17:37:22',NULL,'[Openstack-docs] Help with build','\n\n-----Original Message-----\nFrom: \"Anne Gentle\" <anne at openstack.org>\nSent: Tuesday, 27 August, 2013 01:03\nTo: \"Lorin Hochstein\" <lorin at nimbisservices.com>\nCc: \"Andreas Jaeger\" <aj at suse.com>, \"openstack-docs at lists.openstack.org\" <openstack-docs at lists.openstack.org>\nSubject: Re: [Openstack-docs] Help with build\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\nOn Mon, Aug 26, 2013 at 9:56 AM, Lorin Hochstein\n<lorin at nimbisservices.com>wrote:\n\n> Anne:\n>\n> Once we have the customized schema file, it will be fairly trivial to\n> update the script to point to it (one line change in validate.py):\n>\n>\n> https://github.com/openstack/openstack-manuals/blob/master/tools/validate.py#L63\n>\n>\nOh that is cool. Plus I got to use the word Pythonista.\n\nThanks Lorin!\n\nDavid hopefully this .rng file can be easily substituted.\n\n\n> Lorin\n>\n>\n> On Mon, Aug 26, 2013 at 10:54 AM, Anne Gentle <anne at openstack.org> wrote:\n>\n>>\n>>\n>>\n>> On Mon, Aug 26, 2013 at 9:50 AM, Lorin Hochstein <\n>> lorin at nimbisservices.com> wrote:\n>>\n>>>\n>>> On Mon, Aug 26, 2013 at 10:43 AM, Anne Gentle <anne at openstack.org>wrote:\n>>>\n>>>>\n>>>>\n>>>>\n>>>> On Mon, Aug 26, 2013 at 9:29 AM, Lorin Hochstein <\n>>>> lorin at nimbisservices.com> wrote:\n>>>>\n>>>>>\n>>>>> On Mon, Aug 26, 2013 at 9:37 AM, Anne Gentle <anne at openstack.org>wrote:\n>>>>>\n>>>>>>\n>>>>>>\n>>>>>> On Mon, Aug 26, 2013 at 6:21 AM, Andreas Jaeger <aj at suse.com> wrote:\n>>>>>>\n>>>>>>> On 08/26/2013 04:32 AM, Tom Fifield wrote:\n>>>>>>> > Hi,\n>>>>>>> >\n>>>>>>> > I\'ve tried to fix this one https://review.openstack.org/#/c/43032\n>>>>>>> >\n>>>>>>> > for build for a bit, but it\'s hard without a line number for the\n>>>>>>> > validation error. I\'ve isolated it to the file\n>>>>>>> > section_object-storage-features.xml.\n>>>>>>> >\n>>>>>>> > Any ideas?\n>>>>>>>\n>>>>>>>\n>>>>>>> I found the culprit:\n>>>>>>> Remove from line 748 this include:\n>>>>>>>\n>>>>>>>             <xi:include\n>>>>>>> href=\"../common/tables/swift-proxy-server-(filter:slo).xml\"/>\n>>>>>>>\n>>>>>>> I guess you need to wrap that in a section but can\'t debug further\n>>>>>>> now,\n>>>>>>>\n>>>>>>>\n>>>>>> Yep,  the para table elements need to be wrapped in a section.\n>>>>>>\n>>>>>> I\'m hesitant to stop validating individual files because many people\n>>>>>> need to use a non-validating editor. Can we find a way to validate\n>>>>>> individual files against a schema that we all agree to?\n>>>>>>\n>>>>>\n>>>>> Anne:\n>>>>>\n>>>>> Is the individual file validation useful for people using a\n>>>>> non-validating editor? Given that validate.py now runs maven on all changed\n>>>>> books and will fail if a book doesn\'t build, is there any value added by\n>>>>> running validation against individual files?\n>>>>>\n>>>>> The only advantage I could imagine is if the individual file\n>>>>> validation gave clearer error messages than maven, but I\'m not even sure if\n>>>>> that\'s the case.\n>>>>>\n>>>>\n>>>> I\'m thinking of the scenario where Tom got an error message from Maven\n>>>> but still couldn\'t find the error. When I use a validating editor it\'s easy\n>>>> to find. When I\'m not, it\'s not. So my sense of the overall need is for\n>>>> more fine-grained indicators to locate and troubleshoot.\n>>>>\n>>>>\n>>>\n>>> Ah, gotcha.\n>>>\n>>> In that case, David, can you generate that customized schema you made\n>>> reference to earlier (less constrained in what\'s allowed in the root node)?\n>>> We can add it to the repository and use that for individual file checking.\n>>>\n>>>\n>> Do any Pythonistas know if it\'s possible to customize the lxml library to\n>> insert your own customized schema? That\'s a potential shortcut I think.\n\nJust wanted to say thanks to all for looking at this build, and I\'m even happier that my frustrations started a constructive discussion  - it\'s sounding awesome :D\n\n\nRegards,\n\nTom\n\n\n\n\n\n','<CAD0KtVE3zZXOnPi5TFSyUXHfV8dG0MVQ2FyYe_GB7zw93k7nFA@mail.gmail.com>',NULL),('<1377574113.40556.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 11:28:33',28800,'2013-08-27 03:28:33',NULL,'[Openstack] [swift] complete reinstallation steps needed','Hi Tim,\n\ninstall upgraded version of dns-python using the command:\n\npip install \"dnspython==1.11.0\"\n\nPragya Jain\n\n\n\n\n\n>________________________________\n> From: \"Snider, Tim\" <Tim.Snider at netapp.com>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 27 August 2013 8:20 AM\n>Subject: [Openstack] [swift] complete reinstallation steps needed\n> \n>\n>\n> \n>Thru a series of missteps I (apparently) have mismatched Swift related python files / libraries installed on at least one node. ?swift-init start main? ?results in:\n>root at swift21:~# swift-init start main\n>Traceback (most recent call last):\n>? File \"/usr/local/bin/swift-init\", line 4, in <module>\n>??? from pkg_resources import require; require(\'swift==1.9.2.6.g3b48a71\')\n>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 2711, in <module>\n>??? parse_requirements(__requires__), Environment()\n>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 584, in resolve\n>??? raise DistributionNotFound(req)\n>pkg_resources.DistributionNotFound: dnspython>=1.10.0\n>?\n>Python indicates I?m at 1.9.2.6?\n>root at swift21:~# python -c \'import swift; print swift.__version__\'1.9.2.6.g3b48a71????????? \n>?\n>The last installation commands attempted are:\n>apt-get --reinstall -y install python-coverage python-dev python-nose python-simplejson python-xattr python-eventlet python-greenlet python-pastedeploy python-netifaces python-pip python-dnspython python-mock\n>apt-get install -y --reinstall python-software-properties\n>apt-get install -y --reinstall curl gcc memcached rsync sqlite3 xfsprogs git-core python-setuptools\n>apt-get -y --reinstalls install python-coverage python-dev python-nose python-simplejson python-xattr python-eventlet python-greenlet python-pastedeploy python-netifaces python-pip python-dnspython python-mock\n>apt-get -y --reinstall install python-coverage python-dev python-nose python-simplejson python-xattr python-eventlet python-greenlet python-pastedeploy python-netifaces python-pip python-dnspython python-mock\n>apt-get install --reinstall -y swift-account swift-container swift-object\n>?\n>What is need to completely reinstall Swift and all related files? Any advice/hints are appreciated. \n>?\n>Thanks,\n>Tim\n>?\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/f7f36ad8/attachment.html>\n\n','<DC700C5A3AE74041B17F41EE35500AB93D6CF860@SACEXCMBX03-PRD.hq.netapp.com>',NULL),('<1377575877.45579.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 11:57:57',28800,'2013-08-27 03:57:57',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello \n\n\nPlease help me in setting up Tempauth authentication & authorization with Swift.\nsame error is continued.\n\n\n----- Forwarded Message -----\n>From: pragya jain <prag_2648 at yahoo.co.in>\n>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Cc: anita goel <goel.anita at gmail.com> \n>Sent: Monday, 26 August 2013 12:06 PM\n>Subject: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>hello,\n>\n>I have to configure proxy server.\n>For this, \n>\n>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>\n>\n>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>\n>make following changes (highlighted) in the file:\n>swift_hash_path_suffix =pragya \n>swift_hash_path_prefix =jain \n>\n>save and exit.\n>then, I run the command:\n>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>\n>Now, I have to set up Tempauth authentication & authorization with Swift\n>for this, I run the following command:\n>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>\n>make following changes (highlighted) in the file:\n>allow_account_management =true \n>...\n>[filter:tempauth]\n>use = egg:swift#tempauth\n>...\n>user_admin_admin = admin .admin .reseller_admin\n>user_test_tester = testing .admin\n>user_test2_tester2 = testing2 .admin\n>user_test_tester3 = testing3\n>user_prag2648_pragya = pj2648.admin.reseller_admin\n>...\n>\n>save and exit\n>Then, run following commands:\n>root at arun-Aspire-5742:~# sudo swift-init account start\n>Starting account-server...(/etc/swift/account-server.conf)\n>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>Signal proxy-server? pid: 2476? signal: 15\n>proxy-server (2476) appears to have stopped\n>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>* About to connect() to localhost port 80\n (#0)\n>*?? Trying 127.0.0.1... Connection refused\n>* couldn\'t connect to host\n>* Closing connection #0\n>curl: (7) couldn\'t connect to host\n>\n>But, there is an error in establising a connection.\n>\n>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>proxy-server already started...\n>\n>Please help me in this regard.\n>---\n>\n>Thanks \n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/0f20761a/attachment.html>\n\n','<1377498985.92309.YahooMailNeo@web193603.mail.sg3.yahoo.com>',NULL),('<1377589080.20136.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 00:38:00',-25200,'2013-08-27 07:38:00',NULL,'[Openstack] [Baremetal] Hardware enrollment need help','Hi All,\n\nStill trying to get baremetal provisioning to work, but I don\'t really understand the below commands. Would appreciate any help.\n\nI have a kinda old NEC rack server that has a BMC module on it. I only have an IP address for the BMC module and that\'s it. I do not have a user or password\nthat I can set for that nor do I have the options to create one.?\n\nPerhaps someone can explain exactly what is needed to enroll my hardware or does anyone else know of more detailed documentation? ?\nThis is the only documentation I can find on the feature ->?https://wiki.openstack.org/wiki/Baremetal#Hardware_Enrollment\n\nThank you!\n\n\n# create a \"node\" for each machine # extract the \"id\" from the result and use that in the next step nova baremetal-node-create --pm_address=... --pm_user=... --pm_password=... \\ $COMPUTE-HOST-NAME $CPU $RAM $DISK $FIRST-MAC # for each NIC on the node, including $FIRST-MAC, also create an interface nova baremetal-interface-create $ID $MAC\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/0bec4f37/attachment.html>\n\n',NULL,NULL),('<1377590096.39405.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 00:54:56',-25200,'2013-08-27 07:54:56',NULL,'[Openstack] Baremetal - Hardware preparation','Hi Philip,\n\nThanks for the info IPMI. What I was searching for is how to prepare hardware for enrollment, which is lacking in the wiki I mentioned.\n\nNEC BMC module actually has its own management Ethernet port and most settings can only be managed via the management boot CD. There is a webbased GUI but its mostly for monitoring and remote console only.\n\nThere are no options to set a?IPMI username and password.?\n\nPerhaps my hardware is too old for this type of usage.\n\nThanks for you help,\nJake\n\n\n\n\n\n\n________________________________\n From: Philip Keogh <pkeogh at compusoftcs.com>\nTo: Jake G. <Dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 23, 2013 6:17 PM\nSubject: Re: [Openstack] Baremetal - Hardware preparation\n \n\n\niLO is just one of many vendor solutions that implements IPMI, an industry standard which NEC server BMCs also support.?See http://support.express.nec.co.jp/wpaper/rwu/rwu.pdf for more info on that particular server line.?110Rh-1 supports IPMI 2.0.\n\nOn many systems there is simply a prompt during POST to configure the BMC, which often shares the primary NIC on lower end servers. You can use ipmitool to test connectivity, authentication and chassis power commands independent of OpenStack. See?http://ipmitool.sourceforge.net/manpage.html for more.\n\n\nNote the OpenStack wiki you linked references the IP and credentials for the IPMI interface, which is completely independent of any OS.?I also recommend looking through?http://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface for more on the standard.\n??\n\nOn Aug 23, 2013, at 1:01 AM, Jake G. <Dj_dark_junglist at yahoo.com> wrote:\n\niLo is an HP product only.\n>\n>\n>\n>On 2013/08/23, at 16:35, \"K, Shanthakumar\" <shanthakumar.k at hp.com> wrote:\n>\n>\n> \n>>Irrespective of hardware it should work. Please use your ilo management IP Address, username & password for enrollment and proceed further.\n>>?\n>>Thanks\n>>Shanthakumar K\n>>?\n>>From:Jake G. [mailto:Dj_dark_junglist at yahoo.com] \n>>Sent: Friday, August 23, 2013 1:00 PM\n>>To: K, Shanthakumar\n>>Cc: openstack at lists.openstack.org\n>>Subject: Re: [Openstack] Baremetal - Hardware preparation\n>>?\n>>I wish I had ilo. My test hardware is not an HP server unfortunately.\n>>?\n>>It\'s an older NEC Express5800/110Rh-1\n>>\n>>On 2013/08/23, at 16:27, \"K, Shanthakumar\" <shanthakumar.k at hp.com> wrote:\n>>I got your concern, Your physical hardware needs to be in iLO / power management. So that you will have management ?ilo IP address, username and password to enroll your hardware.\n>>>?\n>>>FYI: You don?t need to have OS installed in your physical hardware to enroll hardware for your baremetal.\n>>>?\n>>>Thanks\n>>>Shanthakumar K\n>>>?\n>>>From:Jake G. [mailto:dj_dark_junglist at yahoo.com] \n>>>Sent: Friday, August 23, 2013 12:15 PM\n>>>To: K, Shanthakumar\n>>>Cc: openstack at lists.openstack.org\n>>>Subject: Re: [Openstack] Baremetal - Hardware preparation\n>>>?\n>>>I am sorry if my explanation was hard to follow.\n>>>?\n>>>In order to enroll my hardware, Openstack requires the Servers IP address, username and password.\n>>>Since I have no OS installed on the hardware(physical server) I have no IP address and no username/password\n>>>?\n>>>On the hardware side only(not openstack) what needs to be done in order for Openstack to control the hardware?\n>>>?\n>>>Thanks\n>>>?\n>>>?\n>>>\n>>>________________________________\n>>> \n>>>From:\"K, Shanthakumar\" <shanthakumar.k at hp.com>\n>>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, August 23, 2013 3:32 PM\n>>>Subject: RE: [Openstack] Baremetal - Hardware preparation\n>>>?\n>>>Please refer the hardware enrollment section under https://wiki.openstack.org/wiki/Baremetal.\n>>>?\n>>>1.????? Ensure your hardware is under same network backbone to communicate\n>>>2.????? Enroll the hardware properly as mentioned in the guide \n>>>3.????? Nova baremetal driver will take care of the communication and you could see the logs in nova compute upon successful enrollment \n>>>?\n>>>Thanks\n>>>Shanthakumar K\n>>>?\n>>>From:Jake G. [mailto:dj_dark_junglist at yahoo.com] \n>>>Sent: Friday, August 23, 2013 11:54 AM\n>>>To: K, Shanthakumar\n>>>Cc: openstack at lists.openstack.org\n>>>Subject: Re: [Openstack] Baremetal - Hardware preparation\n>>>?\n>>>I understand your points and that is taken care of, but how exactly is Openstack going to connect to the hardware if the hardware has no OS and no IP?\n>>>How should the hardware be prepared so I can give Openstack the information it needs to enroll the hardware??\n>>>?\n>>>Thanks,\n>>>Jake\n>>>?\n>>>?\n>>>?\n>>>\n>>>________________________________\n>>> \n>>>From:\"K, Shanthakumar\" <shanthakumar.k at hp.com>\n>>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, August 23, 2013 3:08 PM\n>>>Subject: RE: [Openstack] Baremetal - Hardware preparation\n>>>?\n>>>Hi Jake,\n>>>?\n>>>Your physical hardware should be maximum enough to support your OS configurations and ?baremetal flavor you have created.\n>>>?\n>>>Ex: \n>>>1.?????? Your physical hardware should contain minimum configurations to run an operating system\n>>>2.?????? You need to take care of your Baremetal Flavor created WRT to your available hardware.\n>>>??????????????? \n>>>?\n>>>Thanks\n>>>Shanthakumar K\n>>>?\n>>>From:Jake G. [mailto:dj_dark_junglist at yahoo.com] \n>>>Sent: Friday, August 23, 2013 10:07 AM\n>>>To: openstack at lists.openstack.org\n>>>Subject: [Openstack] Baremetal - Hardware preparation\n>>>?\n>>>Hi all,\n>>>?\n>>>I have been following this doc?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?\n>>>to setup openstack for baremetal provisioning. I have configured oopenstack properly, created an image,\n>>>and now I am ready to enroll my physical hardware. However, there seems to be no mention of how to?\n>>>prepare my physical hardware.\n>>>?\n>>>Does anyone know what is required and what is the process to prepare my hardware?\n>>>?\n>>>Thank you for your help,\n>>>Jake\n>>>?\n>>>?<ATT00001.c>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/6951d452/attachment.html>\n\n','<CB8C7924-2732-4F15-8BA0-E7E2FE2778EE@compusoftcs.com>',NULL),('<1377622559-sup-5866@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 10:15:31',-25200,'2013-08-27 17:15:31',NULL,'[openstack-dev] [OpenStack-dev] Rechecks and Reverifies','Excerpts from John Griffith\'s message of 2013-08-27 09:42:37 -0700:\n> On Tue, Aug 27, 2013 at 10:26 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:\n> \n> > I wonder if there\'s any sort of automation we can apply to this, for\n> > example having known rechecks have \"signatures\" and if a failure matches\n> > the signature it auto applies the recheck.\n> >\n> \n> I think we kinda already have that, the recheck list and the bug ID\n> assigned to it no?  Automatically scanning said list and doing the recheck\n> automatically seems like overkill in my opinion.  At some point human\n> though/interaction is required and I don\'t think it\'s too much to ask a\n> technical contributor to simply LOOK at the output from the test runs\n> against their patches and help out a bit. At the very least if you didn\'t\n> test your patch yourself and waited for Jenkins to tell you it\'s broken I\n> would hope that a submitter would at least be motivated to fix their own\n> issue that they introduced.\n> \n\nIt is worth thinking about though, because \"ask a technical contributor\nto simply LOOK\" is a lot more expensive than \"let a script confirm the\nfailure and tack it onto the list for rechecks\".\n\nUbuntu has something like this going for all of their users and it is\npretty impressive.\n\nApport and/or whoopsie see crashes and look at the\nbacktraces/coredumps/etc and then (with user permission) submit a\nsignature to the backend. It is then analyzed and the result is this:\n\nhttp://errors.ubuntu.com/\n\nKnown false positives are shipped along side packages so that they do\nnot produce noise, and known points of pain for debugging are eased by\nincluding logs and other things in bug reports when users are running\nthe dev release. This results in a much better metric for what bugs to\naddress first. IIRC update-manager also checks in with a URL that is\ninformed partially by this data about whether or not to update packages,\nso if there is a high fail rate early on, the server side will basically\nsignal update-manager \"don\'t update right now\".\n\nI\'d love to see our CI system enhanced to do all of the pattern\nmatching to group failures by common patterns, and then when a technical\ncontributor looks at these groups they have tons of data points to _fix_\nthe problem rather than just spending their precious time identifying it.\n\nThe point of the recheck system, IMHO, isn\'t to make running rechecks\neasier, it is to find and fix bugs.\n\n\n','<CA+qL3LVztJyEPu+yrM9ojSnrEM5CmVUHi4tFDf_biXSYJCD-Bg@mail.gmail.com>',NULL),('<1377644853-sup-3686@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 16:11:09',-25200,'2013-08-27 23:11:09',NULL,'[openstack-dev] [TRIPLEO] Derekh for tripleo core','Excerpts from Robert Collins\'s message of 2013-08-27 14:25:47 -0700:\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt\n> \n> - Derek is reviewing fairly regularly and has got a sense of the\n> culture etc now, I think.\n> \n> So - calling for votes for Derek to become a TripleO core reviewer!\n\n+1\n\n> \n> I think we\'re nearly at the point where we can switch to the \'two\n> +2\'s\' model - what do you think?\n> \n\nI am reluctant to go there just yet. We have a couple of absentee\nmembers of core at the moment and thus we really only have 4 active\nreviewers. That is \"n+1\", but I worry about reviewers getting fatigued\nor feeling pressure to get to more reviews rather than feeling pressure\nto do a few really thorough reviews.\n\nSo I think we should let derekh\'s presence on core be felt for a few\nweeks and then re-visit the +4 requirement then.\n\n\n','<CAJ3HoZ3XfzNbSJo5irSsdUHNL7X0kvruEJcicXm=49=EsoPxFg@mail.gmail.com>',NULL),('<1377645782-sup-7263@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 16:24:40',-25200,'2013-08-27 23:24:40',NULL,'[openstack-dev] [heat] Heat mission statement','Excerpts from Robert Collins\'s message of 2013-08-27 14:13:37 -0700:\n> On 28 August 2013 06:54, Steven Hardy <shardy at redhat.com> wrote:\n> > We had some recent discussions regarding the Heat mission statement and\n> > came up with:\n> >\n> > \"To explicitly model the relationships between OpenStack resources of all\n> > kinds; and to harness those models, expressed in forms accessible to both\n> > humans and machines, to manage infrastructure resources throughout the\n> > lifecycle of applications.\"\n> \n> Bingo!\n> \n> > The ideas, iterations and some discussion is captured in this etherpad:\n> >\n> > https://etherpad.openstack.org/heat-mission\n> >\n> > If anyone has any remaining comments, please speak now, but I think most of\n> > those involved in the discussion thus-far have reached the point of wishing\n> > to declare it final ;)\n> \n> I think there is some confusion about implementation vs intent here\n> :). Or at least I hope so. I wouldn\'t expect Nova\'s mission statement\n> to talk about \'modelling virtual machines\' : modelling is internal\n> jargon, not a mission!\n> \n> What you want, IMO, is for a moderately technical sysadmin to read the\n> mission statement and go \'hell yeahs, I want to use Heat\'.\n> \n> \"Create a human and machine accessible service for managing the entire\n> lifecycle of infrastructure and applications within OpenStack clouds.\"\n> \n\nReading the two next to eachother, this evoked The Emperor\'s New Groove\nfor me.\n\n\"Why do we even have that lever?\"\n\nRobert this encapsulates what I think of Heat perfectly. +1 from me.\n\n\n','<CAJ3HoZ0qF00+ZJXiJRyvmCD4eckJARo0+kf+RCsXdKJ0Jg2Jag@mail.gmail.com>',NULL),('<1377648512.2803.19.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 19:08:32',-18000,'2013-08-28 00:08:32',NULL,'[openstack-dev] Blueprint for Nova native image building','Russell,\n\nThanks for the reminder to follow up on list.\n\nTo summarize my read of this thread, the strong consensus seems to be to\nkeep the detailed mechanics of building individual operating systems out\nof nova itself.  It also seems there\'s no universally agreed upon\nalternative location for it within the existing components, though the\nplugable asynchronous import proposal for glance seems like a sensible\ncandidate.\n\nWhat we\'ve opted to do for the moment is focus on expanding our original\nstandalone proof of concept to support more operating systems and more\ncleanly support both network and DVD/iso based installs, in part based\non the expanded block device mapping work that Nikola has been doing.\n\nWe\'re also working on a smaller/targeted enhancement to nova to allow\nspecifying a kernel command line, in addition to a ramdisk and kernel\nwhen booting an instance.  This will allow us to avoid crafting custom\nboot media when installing Linux under both KVM and, most likely, Xen\nhypervisors.  Dennis\' initial patch set for this:\n\nhttps://review.openstack.org/#/c/43513/\n\n-Ian\n\nOn Mon, 2013-08-26 at 13:46 -0400, Russell Bryant wrote:\n> I believe this is where the thread stopped a couple weeks ago.  I was\n> just curious what has happened since.  How did you interpret all of the\n> feedback given, and what direction have you decided to take next?\n> \n> Thanks,\n> \n\n\n\n\n','<521B9485.3050901@redhat.com>',NULL),('<1377652413-sup-4036@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 18:38:18',-25200,'2013-08-28 01:38:18',NULL,'[openstack-dev] [savanna] Service Relationships and Dependencies','Excerpts from John Speidel\'s message of 2013-08-27 09:29:18 -0700:\n> Some services/components are related or have dependencies on other \n> services and components.As an example, in HDP, the Hive service depends \n> on HBase and Zookeeper.In Savanna, there is no way to express this \n> relationship.If a user wanted to deploy Hive, they would need to know to \n> install both HBase and Zookeeper a priori.Also, because the list of \n> service components(node processes) that is provided to a user to be used \n> in node groups is a flat list, only the component name gives any \n> indication as to what service the components belong to.Because of this, \n> it will likely be difficult for the user to understand exactly what \n> components are required to be installed for a given \n> service(s).Currently, the HDP stack consists of approximately 25 service \n> components.\n> \n> \n> A primary reason that it isn\'t currently possible to express \n> service/component relationships is that topology is defined from the \n> bottom up.This means that a user first selects components and assigns \n> them to a node template.The users first interaction is with components, \n> not services.Currently, the user will not know if a given topology is \n> valid until an attempt is made to deploy a cluster and validate is \n> called on the plugin.At this point, if the topology were invalid, the \n> user would need to go back and create new node and cluster templates.\n> \n> \n> \n> One way to express service relationships would be to define topology top \n> down, with the user first selecting services.After selecting services, \n> the related service components could be listed and the required \n> components could be noted. This approach is a significant change to how \n> Savanna currently works, has not been thoroughly thought through and and \n> is only meant to promote conversation on the matter.\n> \n> \n> \n> After making new services available from the HDP plugin, it is clear \n> that defining a desired (valid) topology will be very difficult and \n> error prone with the current savanna architecture.I look forward to \n> discussing solutions to this matter with the community.\n> \n> \n\nI understand that Savanna is laser-focused on Hadoop, however, it\nseems really odd that Savanna would have its own way to define service\ndependencies and deployments.\n\nHeat is specifically meant to aid users in deploying multi-node services\nwith complicated dependency graphs. While I do agree this would be a\ndeparture from the way Savanna works, it would also be in-line with what\nTrove is doing for the same reasons.\n\nSo, as you move toward a service dependency graph, please consider using\nHeat to orchestrate nodes, and enhancing it where Savanna needs it to\nwork better, rather than pouring more into a Savanna only solution. I\nthink in the end it will result in a simpler solution for Savanna, and\na better Heat as well.\n\n\n','<521CD3DE.60200@hortonworks.com>',NULL),('<1377654658.42436.YahooMailNeo@web163006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 18:50:58',-25200,'2013-08-28 01:50:58',NULL,'[Openstack] Japan users mailing list?','Hi all,\n\nJust wondering if there is a mailing list for users in Japan?\nIf so I would love to join.\n\n?????????\n?????????????????????????\n??????????????????????\n????????????\n\nThanks,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/7bf3461c/attachment.html>\n\n',NULL,NULL),('<1377664155.64276.YahooMailNeo@web163002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 21:29:15',-25200,'2013-08-28 04:29:15',NULL,'[Openstack] Japan users mailing list?','Thanks for the links!\nI work in Japan at a Japanese company so my Japanese is fine :)\n\n\nBest,\nJake\n\n\n\n\n________________________________\n From: Shinobu Kinjo <shinobu.kinjo at oist.jp>\nTo: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Wednesday, August 28, 2013 12:39 PM\nSubject: RE: [Openstack] Japan users mailing list?\n \n\n\n \nJake,\n\nHere\'s url for openstack community in japan.\n\nhttp://openstack.jp/community.html\n\nYou can register to the mailing list for the users group at the following url.\n\nhttp://groups.google.com/group/openstack-ja\n\n\nI hope you can understand Japanese well...\n\nRgds,\nKinjo\n\n\n----\nO I S T\nOkinawa Institute of Science and Technology Graduate School\n1919-1 Tancha, Onna-son, Kunigami-gun\nOkinawa, Japan 904-0495\n? T: +81-98-966-2093? \n? M: +81-80-6800-6447\n? shinobu.kinjo at oist.jp\n? www.oist.jp\n\n\n________________________________\n \nFrom: Jake G. [dj_dark_junglist at yahoo.com]\nSent: Wednesday, August 28, 2013 10:50\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Japan users mailing list?\n\n\nHi all,\n\nJust wondering if there is a mailing list for users in Japan?\nIf so I would love to join.\n\n?????????\n?????????????????????????\n??????????????????????\n????????????\n\nThanks,\nJake\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/d3b17a59/attachment.html>\n\n','<BB082CD7FD87F04889C900D4CBC96571E0646025@OISTEXMBX21.oist.local>',NULL),('<1377666788.87428.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-27 22:13:08',-25200,'2013-08-28 05:13:08',NULL,'[Openstack] [Baremetal] Hardware enrollment need help please','Hi All,\n\n\n\nStill trying to get baremetal provisioning to work, but I don\'t really understand the below commands. Would appreciate any help.\n\nI have a kinda old NEC rack server that has a BMC module on it. I only have an IP address for the BMC module and that\'s it. I do not have a user or password\nthat I can set for that nor do I have the options to create one.?\n\nPerhaps someone can explain exactly what is needed to enroll my hardware or does anyone else know of more detailed documentation? ?\nThis is the only documentation I can find on this feature ->?https://wiki.openstack.org/wiki/Baremetal#Hardware_Enrollment\n\nSince this feature is more popular in Japan, I wonder if there are any resources available in Japanese?\n\nThank you!\n\n\n# create a \"node\" for each machine # extract the \"id\" from the result and use that in the next step nova baremetal-node-create --pm_address=... --pm_user=... --pm_password=... \\ $COMPUTE-HOST-NAME $CPU $RAM $DISK $FIRST-MAC # for each NIC on the node, including $FIRST-MAC, also create an interface nova baremetal-interface-create $ID $MAC\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130827/d4ce3ecd/attachment.html>\n\n','<1377589080.20136.YahooMailNeo@web163003.mail.bf1.yahoo.com>',NULL),('<1377677091.84244.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-28 01:04:51',-25200,'2013-08-28 08:04:51',NULL,'[Openstack] [Baremetal] Hardware enrollment need help please','Hi Ryota,\n\nThanks for the reply. I figured this out about 30 mins ago. Didn\'t know the web GUI user account was the same for the IPMI authentication.\n\nAfter enrolling the hardware in Openstack finally, when I try to deploy I get an error, which I cant find in the logs. My guess is Openstack server cannot communicate with the hardware.\nBooting the hardware from PXE also cannot find the openstack server to get an ip from.\n\nOne step at a time eh? haha\n\nThanks!\nJake\n\n\n\n\n________________________________\n From: Ryota Mibu <r-mibu at cq.jp.nec.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Wednesday, August 28, 2013 4:33 PM\nSubject: RE: [Openstack] [Baremetal] Hardware enrollment need help please\n \n\nHi Jake,\n\n\nYou can find the default user account and password to access BMC through IPMI in \" EXPRESSSCOPE Engine 2? User\'s Guide p.8\".\n\nhttp://support.necam.com/kbtools/Sdocs.cfm?id=2BF43967-2A61-4E68-B8CB-981A7D4F94D9\n\nIt could be wrong in the version of BMC on your server or if you used some configuration tool to build. So I suggest you to login to BMC Web console and configure user account and password.\n\nNote: You can check pm_{address,user,password} by running ipmitool in your env as follows:\n?  # echo \'<pm_password>\' > pw\n?  # ipmitool -H <pm_address> -U <pm_user> -I lanplus -f pw power status\n\n\nRegards,\nRyota.\n\n>-----Original Message-----\n>From: Jake G. [mailto:dj_dark_junglist at yahoo.com]\n>Sent: Wednesday, August 28, 2013 2:13 PM\n>To: openstack at lists.openstack.org\n>Subject: [Openstack] [Baremetal] Hardware enrollment need help please\n>\n>Hi All,\n>\n>\n>Still trying to get baremetal provisioning to work, but I don\'t really understand the below commands. Would appreciate\n>any help.\n>\n>I have a kinda old NEC rack server that has a BMC module on it. I only have an IP address for the BMC module and\n>that\'s it. I do not have a user or password\n>that I can set for that nor do I have the options to create one.\n>\n>Perhaps someone can explain exactly what is needed to enroll my hardware or does anyone else know of more detailed\n>documentation?\n>This is the only documentation I can find on this feature ->\n>https://wiki.openstack.org/wiki/Baremetal#Hardware_Enrollment\n>\n>Since this feature is more popular in Japan, I wonder if there are any resources available in Japanese?\n>\n>Thank you!\n>\n>\n> # create a \"node\" for each machine\n> # extract the \"id\" from the result and use that in the next step\n> nova baremetal-node-create --pm_address=... --pm_user=... --pm_password=... \\\n>?  $COMPUTE-HOST-NAME $CPU $RAM $DISK $FIRST-MAC\n>\n> # for each NIC on the node, including $FIRST-MAC, also create an interface\n> nova baremetal-interface-create $ID $MAC\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130828/4b97ec9b/attachment.html>\n\n','<1FAA045BFF455543B55A30E48415AA08CB921E@BPXM06GP.gisp.nec.co.jp>',NULL),('<1377704754.58821.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-28 23:45:54',28800,'2013-08-28 15:45:54',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','thanks pangj for the translation.\nI really don\'t know traditional chinese.\nAlso thanks Hugo for the question.\n\nBut I am installing and configuring swift on my PC.\nI am not using multiple nodes.\n\n----\n\nPragya Jain\n\n\n\n\n>________________________________\n> From: pangj <pangj at laposte.net>\n>To: openstack at lists.openstack.org \n>Sent: Tuesday, 27 August 2013 11:32 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>On 2013-8-27 13:43, Kuo Hugo wrote:\n>> swift.conf??? hash key ???node ????????\n>>\n>\n>Hugo,\n>I am afraid he doesn\'t know traditional Chinese since the email address \n>shows he is coming from India.\n>\n>To pragya jain, what Hugo said:\n>Are the hash keys in swift.conf on all nodes are the same?\n>\n>Regards.\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130828/e4ae43a6/attachment.html>\n\n','<521C40EE.1070800@laposte.net>',NULL),('<1377705664.3899.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 00:01:04',28800,'2013-08-28 16:01:04',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nPlease help me in knowing how to use 8080 port \n\n\n\n\n\n>________________________________\n> From: Amanda Plimpton <amanda at swiftstack.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com> \n>Sent: Tuesday, 27 August 2013 9:40 AM\n>Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hello,\n>\n>Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>\n>\n>Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/ \n>\n>\n>\n>Thank you,\n>Amanda\n>\n>SwiftStack Inc.\n>swiftstack.com\n>\n>\n>\n>\n>On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir!\n>>\n>>\n>>Please help me in setting up Tempauth authentication & authorization with Swift.\n>>same error is continued.\n>>\n>>\n>>----- Forwarded Message -----\n>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Cc: anita goel <goel.anita at gmail.com> \n>>>\n>>>Sent: Monday, 26 August 2013 12:06 PM\n>>>Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>hello,\n>>>\n>>>I have to configure proxy server.\n>>>For this, \n>>>\n>>>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>>>\n>>>\n>>>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>\n>>>make following changes (highlighted) in the file:\n>>>swift_hash_path_suffix =pragya \n>>>swift_hash_path_prefix =jain \n>>>\n>>>save and exit.\n>>>then, I run the command:\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>\n>>>Now, I have to set up Tempauth authentication & authorization with Swift\n>>>for this, I run the following command:\n>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>\n>>>make following changes (highlighted) in the file:\n>>>allow_account_management =true \n>>>...\n>>>[filter:tempauth]\n>>>use = egg:swift#tempauth\n>>>...\n>>>user_admin_admin = admin .admin .reseller_admin\n>>>user_test_tester = testing .admin\n>>>user_test2_tester2 = testing2 .admin\n>>>user_test_tester3 = testing3\n>>>user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>...\n>>>\n>>>save and exit\n>>>Then, run following commands:\n>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>Signal proxy-server? pid: 2476? signal: 15\n>>>proxy-server (2476) appears to have stopped\n>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>* About to connect() to localhost port 80\n (#0)\n>>>*?? Trying 127.0.0.1... Connection refused\n>>>* couldn\'t connect to host\n>>>* Closing connection #0\n>>>curl: (7) couldn\'t connect to host\n>>>\n>>>But, there is an error in establising a connection.\n>>>\n>>>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>proxy-server already started...\n>>>\n>>>Please help me in this regard.\n>>>---\n>>>\n>>>Thanks \n>>>\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/5a7372c6/attachment.html>\n\n','<CAJQZngAYJVqSWVhk9HnO6N8F2s4V-MHAtH1joJb2z+h1C9mN=w@mail.gmail.com>',NULL),('<1377752492.62463.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-28 22:01:32',-25200,'2013-08-29 05:01:32',NULL,'[Openstack] Baremetal OS image support','Hi Rob,\n\nI have a question on the part you changed on the?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?page.\n\n\nbin/ramdisk-image-create deploy -a i386 -o my-deploy-ramdisk\n\nWhat if I am creating a x86_64 image? what should this line look like?\n\nThank you,\nJake\n\n\n\n\n________________________________\n From: Robert Collins <robertc at robertcollins.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Wednesday, August 21, 2013 6:43 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nOn 21 August 2013 21:37, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\n> Hi Rob,\n> Thank you for the info. I look forward to those images.\n>\n> I am using this document for baremetal deployment, which has the -k in it ->\n> https://wiki.openstack.org/wiki/Baremetal\n> This seem to be the only documentation available for how to implement the\n> baremetal feature. Would you know of a better doc?\n\nThat page was a little stale; I\'ve done a super-minimal update to it.\n\nCheers,\nRob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130828/b0b74c12/attachment.html>\n\n','<CAJ3HoZ03j_75AKi4r-9gmp04oHDLpT-JhXrJsxyHKor4eR31bA@mail.gmail.com>',NULL),('<1377755510.20626.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 13:51:50',28800,'2013-08-29 05:51:50',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir\n\nThanks for the suggestion.\n\n(1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n\nroot at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n\nand make following changes:\n\nuser_admin_admin = admin .admin .reseller_admin\nuser_test_tester = testing .admin\nuser_test2_tester2 = testing2 .admin\nuser_test_tester3 = testing3\n\nuser_prag2648_pragya =pj2648 .admin .reseller_admin\n\nand then\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n*?? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\n(2) I also tired the connection with user admin:admin\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n*?? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\n(3) I also run the command to verify the port number of proxy\nroot at arun-Aspire-5742:~# ps aux | grep proxy\nnobody??? 2124? 0.0? 0.0?? 5384? 1164 ???????? S??? 10:39?? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\nroot????? 2724? 0.0? 0.0?? 4368?? 828 pts/0??? R+?? 10:52?? 0:00 grep --color=auto proxy\nroot at arun-Aspire-5742:~# netstat -antulp\nActive Internet connections (servers and established)\nProto Recv-Q Send-Q Local Address?????????? Foreign Address???????? State?????? PID/Program name\ntcp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????? LISTEN????? 931/memcached?? \ntcp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????? LISTEN????? 2124/dnsmasq??? \ntcp??????? 0????? 0 127.0.0.1:631?????????? 0.0.0.0:*?????????????? LISTEN????? 623/cupsd?????? \ntcp??????? 0????? 0 115.184.7.223:51521???? 74.125.236.132:80?????? TIME_WAIT?? -?????????????? \ntcp??????? 1????? 0 115.184.7.223:46280???? 91.189.89.144:80??????? CLOSE_WAIT? 1663/ubuntu-geoip-p\ntcp??????? 0????? 0 115.184.7.223:60563???? 173.194.38.147:80?????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:43256???? 124.124.201.179:80????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:41791???? 124.124.201.169:80????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:36669???? 124.124.252.9:80??????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:51747???? 173.194.38.184:80?????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:54229???? 74.125.236.44:443?????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:36185???? 173.194.36.26:80??????? TIME_WAIT?? -?????????????? \ntcp??????? 0????? 0 115.184.7.223:38854???? 74.125.236.109:80?????? TIME_WAIT?? -?????????????? \ntcp6?????? 0????? 0 ::1:631???????????????? :::*??????????????????? LISTEN????? 623/cupsd?????? \nudp??????? 0????? 0 0.0.0.0:5353??????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\nudp??????? 0????? 0 0.0.0.0:53489?????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\nudp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????????????????? 931/memcached?? \nudp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????????????????? 2124/dnsmasq??? \nudp6?????? 0????? 0 :::5353???????????????? :::*??????????????????????????????? 619/avahi-daemon: r\nudp6?????? 0????? 0 :::36705??????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n\nPlease help to proceed further.\n\n---\n\nThanks\n\nPragya jain\n\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Wednesday, 28 August 2013 9:59 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hi?\n>\n>\n>1)?user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ??\n>2) Verify the port number of proxy by?\n>$> ps aux | grep proxy?\n>>$> netstat -antulp?\n>\n>\n>3) Check the Proxy for how to setup bind_port?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>\n>\n>\n>\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir,\n>>\n>>Please help me in knowing how to use 8080 port \n>>\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com> \n>>>Sent: Tuesday, 27 August 2013 9:40 AM\n>>>Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hello,\n>>>\n>>>Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>\n>>>\n>>>Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/ \n>>>\n>>>\n>>>\n>>>Thank you,\n>>>Amanda\n>>>\n>>>SwiftStack Inc.\n>>>swiftstack.com\n>>>\n>>>\n>>>\n>>>\n>>>On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir!\n>>>>\n>>>>\n>>>>Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>same error is continued.\n>>>>\n>>>>\n>>>>----- Forwarded Message -----\n>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Cc: anita goel <goel.anita at gmail.com> \n>>>>>\n>>>>>Sent: Monday, 26 August 2013 12:06 PM\n>>>>>\n>>>>>Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>hello,\n>>>>>\n>>>>>I have to configure proxy server.\n>>>>>For this, \n>>>>>\n>>>>>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>>>>>\n>>>>>\n>>>>>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>\n>>>>>make following changes (highlighted) in the file:\n>>>>>swift_hash_path_suffix =pragya \n>>>>>swift_hash_path_prefix =jain \n>>>>>\n>>>>>save and exit.\n>>>>>then, I run the command:\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>\n>>>>>Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>for this, I run the following command:\n>>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>\n>>>>>make following changes (highlighted) in the file:\n>>>>>allow_account_management =true \n>>>>>...\n>>>>>[filter:tempauth]\n>>>>>use = egg:swift#tempauth\n>>>>>...\n>>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>>user_test_tester = testing .admin\n>>>>>user_test2_tester2 = testing2 .admin\n>>>>>user_test_tester3 = testing3\n>>>>>user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>...\n>>>>>\n>>>>>save and exit\n>>>>>Then, run following commands:\n>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>Signal proxy-server? pid: 2476? signal: 15\n>>>>>proxy-server (2476) appears to have stopped\n>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>* About to connect() to localhost port 80\n (#0)\n>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>* couldn\'t connect to host\n>>>>>* Closing connection #0\n>>>>>curl: (7) couldn\'t connect to host\n>>>>>\n>>>>>But, there is an error in establising a connection.\n>>>>>\n>>>>>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>proxy-server already started...\n>>>>>\n>>>>>Please help me in this regard.\n>>>>>---\n>>>>>\n>>>>>Thanks \n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/bff9af51/attachment.html>\n\n','<CA++_uhv6FyK0AfoeSUVDntgT-XuS5M5E3RP+JACEXXJ8T9q1TQ@mail.gmail.com>',NULL),('<1377765810.77854.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 16:43:30',28800,'2013-08-29 08:43:30',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir\n\nThanks for the help\n\nroot at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n/usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n\n\nthis is the result of the command.\n\nplease help in this regard.\n\n-----\nPragya Jain\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013 1:20 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Obviously, There\'s no proxy server running on your node.?\n>\n>\n>Please execute it on the node where proxy-server located:?\n>(I assume the binary is in /usr/bin and conf file is in /etc/swift)?\n>\n>$> /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>\n>\n>\n>What\'s the result ?\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir\n>>\n>>Thanks for the suggestion.\n>>\n>>(1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>\n>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>\n>>and make following changes:\n>>\n>>\n>>user_admin_admin = admin .admin .reseller_admin\n>>user_test_tester = testing .admin\n>>user_test2_tester2 = testing2 .admin\n>>user_test_tester3 = testing3\n>>\n>>user_prag2648_pragya =pj2648 .admin .reseller_admin\n>>\n>>and then\n>>\n>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>Starting account-server...(/etc/swift/account-server.conf)\n>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>\n>>Starting\n proxy-server...(/etc/swift/proxy-server.conf)\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>* About to connect() to localhost port 80 (#0)\n>>*?? Trying 127.0.0.1... Connection refused\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>\n>>(2) I also tired the connection with user admin:admin\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>\n>>* About to connect() to localhost port 80 (#0)\n>>*?? Trying 127.0.0.1... Connection refused\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>\n>>(3) I also run the command to verify the port number of proxy\n>>root at arun-Aspire-5742:~# ps aux | grep proxy\n>>nobody??? 2124? 0.0? 0.0?? 5384? 1164\n ???????? S??? 10:39?? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>root????? 2724? 0.0? 0.0?? 4368?? 828 pts/0??? R+?? 10:52?? 0:00 grep --color=auto proxy\n>>root at arun-Aspire-5742:~# netstat -antulp\n>>Active Internet connections (servers and established)\n>>Proto Recv-Q Send-Q Local Address?????????? Foreign Address???????? State?????? PID/Program name\n>>tcp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????? LISTEN????? 931/memcached?? \n>>tcp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????? LISTEN????? 2124/dnsmasq??? \n>>tcp??????? 0????? 0 127.0.0.1:631?????????? 0.0.0.0:*?????????????? LISTEN????? 623/cupsd?????? \n>>tcp??????? 0????? 0 115.184.7.223:51521???? 74.125.236.132:80?????? TIME_WAIT?? -?????????????? \n>>tcp??????? 1????? 0 115.184.7.223:46280???? 91.189.89.144:80??????? CLOSE_WAIT? 1663/ubuntu-geoip-p\n>>tcp??????? 0????? 0 115.184.7.223:60563???? 173.194.38.147:80?????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:43256???? 124.124.201.179:80????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:41791???? 124.124.201.169:80????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:36669???? 124.124.252.9:80??????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:51747???? 173.194.38.184:80?????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:54229???? 74.125.236.44:443?????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:36185???? 173.194.36.26:80??????? TIME_WAIT?? -?????????????? \n>>tcp??????? 0????? 0 115.184.7.223:38854???? 74.125.236.109:80?????? TIME_WAIT?? -?????????????? \n>>tcp6?????? 0????? 0\n ::1:631???????????????? :::*??????????????????? LISTEN????? 623/cupsd?????? \n>>udp??????? 0????? 0 0.0.0.0:5353??????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>udp??????? 0????? 0 0.0.0.0:53489?????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>udp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????????????????? 931/memcached?? \n>>udp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????????????????? 2124/dnsmasq??? \n>>udp6?????? 0????? 0\n :::5353???????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>udp6?????? 0????? 0 :::36705??????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>\n>>Please help to proceed further.\n>>\n>>---\n>>\n>>Thanks\n>>\n>>Pragya jain\n>>\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Wednesday, 28 August 2013 9:59 PM\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hi?\n>>>\n>>>\n>>>1)?user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ??\n>>>2) Verify the port number of proxy by?\n>>>$> ps aux | grep proxy?\n>>>>$> netstat -antulp?\n>>>\n>>>\n>>>3) Check the Proxy for how to setup bind_port?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir,\n>>>>\n>>>>Please help me in knowing how to use 8080 port \n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com> \n>>>>>Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Hello,\n>>>>>\n>>>>>Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>\n>>>>>\n>>>>>Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/ \n>>>>>\n>>>>>\n>>>>>\n>>>>>Thank you,\n>>>>>Amanda\n>>>>>\n>>>>>SwiftStack Inc.\n>>>>>swiftstack.com\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>hello sir!\n>>>>>>\n>>>>>>\n>>>>>>Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>same error is continued.\n>>>>>>\n>>>>>>\n>>>>>>----- Forwarded Message -----\n>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Cc: anita goel <goel.anita at gmail.com> \n>>>>>>>\n>>>>>>>Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>\n>>>>>>>Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>hello,\n>>>>>>>\n>>>>>>>I have to configure proxy server.\n>>>>>>>For this, \n>>>>>>>\n>>>>>>>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>>>>>>>\n>>>>>>>\n>>>>>>>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>\n>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>swift_hash_path_suffix =pragya \n>>>>>>>swift_hash_path_prefix =jain \n>>>>>>>\n>>>>>>>save and exit.\n>>>>>>>then, I run the command:\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>\n>>>>>>>Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>for this, I run the following command:\n>>>>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>\n>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>allow_account_management =true \n>>>>>>>...\n>>>>>>>[filter:tempauth]\n>>>>>>>use = egg:swift#tempauth\n>>>>>>>...\n>>>>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>>>>user_test_tester = testing .admin\n>>>>>>>user_test2_tester2 = testing2 .admin\n>>>>>>>user_test_tester3 = testing3\n>>>>>>>user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>...\n>>>>>>>\n>>>>>>>save and exit\n>>>>>>>Then, run following commands:\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>Signal proxy-server? pid: 2476? signal: 15\n>>>>>>>proxy-server (2476) appears to have stopped\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 80\n (#0)\n>>>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>\n>>>>>>>But, there is an error in establising a connection.\n>>>>>>>\n>>>>>>>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>proxy-server already started...\n>>>>>>>\n>>>>>>>Please help me in this regard.\n>>>>>>>---\n>>>>>>>\n>>>>>>>Thanks \n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/9c2eaaa8/attachment.html>\n\n','<CA++_uhse2UXCmH_j6qqNHEa9D_b+mmUNxZFNdDcy0Sni=zLx+g@mail.gmail.com>',NULL),('<1377767543.33056.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 17:12:23',28800,'2013-08-29 09:12:23',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nI run the command:\n\nroot at arun-Aspire-5742:~# find / -name swift-proxy-server\n/opt/swift/build/scripts-2.7/swift-proxy-server\n/opt/swift/bin/swift-proxy-server\n/usr/local/bin/swift-proxy-server\n/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n\nroot at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nTraceback (most recent call last):\n? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n??? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n??? self.require(requires)[0].run_script(script_name, ns)\n? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n??? execfile(script_filename, namespace, namespace)\n? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n??? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n??? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n??? bind_addr[0], bind_addr[1], bind_timeout))\nException: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n\n\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013 2:19 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption)?\n>\n>\n>$> find / -name swift-proxy-server\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir\n>>\n>>\n>>Thanks for the help\n>>\n>>\n>>root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>/usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>\n>>\n>>\n>>this is the result of the command.\n>>\n>>\n>>please help in this regard.\n>>\n>>\n>>-----\n>>Pragya Jain\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Thursday, 29 August 2013 1:20 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Obviously, There\'s no proxy server running on your node.?\n>>>\n>>>\n>>>Please execute it on the node where proxy-server located:?\n>>>(I assume the binary is in /usr/bin and conf file is in /etc/swift)?\n>>>\n>>>$> /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>\n>>>\n>>>\n>>>What\'s the result ?\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir\n>>>>\n>>>>Thanks for the suggestion.\n>>>>\n>>>>(1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>\n>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>\n>>>>and make following changes:\n>>>>\n>>>>\n>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>user_test_tester = testing .admin\n>>>>user_test2_tester2 = testing2 .admin\n>>>>user_test_tester3 = testing3\n>>>>\n>>>>user_prag2648_pragya =pj2648 .admin .reseller_admin\n>>>>\n>>>>and then\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>\n>>>>Starting\n proxy-server...(/etc/swift/proxy-server.conf)\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>* About to connect() to localhost port 80 (#0)\n>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>\n>>>>(2) I also tired the connection with user admin:admin\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>\n>>>>* About to connect() to localhost port 80 (#0)\n>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>\n>>>>(3) I also run the command to verify the port number of proxy\n>>>>root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>nobody??? 2124? 0.0? 0.0?? 5384? 1164\n ???????? S??? 10:39?? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>root????? 2724? 0.0? 0.0?? 4368?? 828 pts/0??? R+?? 10:52?? 0:00 grep --color=auto proxy\n>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>Active Internet connections (servers and established)\n>>>>Proto Recv-Q Send-Q Local Address?????????? Foreign Address???????? State?????? PID/Program name\n>>>>tcp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????? LISTEN????? 931/memcached?? \n>>>>tcp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????? LISTEN????? 2124/dnsmasq??? \n>>>>tcp??????? 0????? 0 127.0.0.1:631?????????? 0.0.0.0:*?????????????? LISTEN????? 623/cupsd?????? \n>>>>tcp??????? 0????? 0 115.184.7.223:51521???? 74.125.236.132:80?????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 1????? 0 115.184.7.223:46280???? 91.189.89.144:80??????? CLOSE_WAIT? 1663/ubuntu-geoip-p\n>>>>tcp??????? 0????? 0 115.184.7.223:60563???? 173.194.38.147:80?????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:43256???? 124.124.201.179:80????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:41791???? 124.124.201.169:80????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:36669???? 124.124.252.9:80??????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:51747???? 173.194.38.184:80?????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:54229???? 74.125.236.44:443?????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:36185???? 173.194.36.26:80??????? TIME_WAIT?? -?????????????? \n>>>>tcp??????? 0????? 0 115.184.7.223:38854???? 74.125.236.109:80?????? TIME_WAIT?? -?????????????? \n>>>>tcp6?????? 0????? 0\n ::1:631???????????????? :::*??????????????????? LISTEN????? 623/cupsd?????? \n>>>>udp??????? 0????? 0 0.0.0.0:5353??????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>>>udp??????? 0????? 0 0.0.0.0:53489?????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>>>udp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????????????????? 931/memcached?? \n>>>>udp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????????????????? 2124/dnsmasq??? \n>>>>udp6?????? 0????? 0\n :::5353???????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>>>udp6?????? 0????? 0 :::36705??????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>>>\n>>>>Please help to proceed further.\n>>>>\n>>>>---\n>>>>\n>>>>Thanks\n>>>>\n>>>>Pragya jain\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Hi?\n>>>>>\n>>>>>\n>>>>>1)?user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ??\n>>>>>2) Verify the port number of proxy by?\n>>>>>$> ps aux | grep proxy?\n>>>>>>$> netstat -antulp?\n>>>>>\n>>>>>\n>>>>>3) Check the Proxy for how to setup bind_port?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>+Hugo Kuo+\n>>>>>hugo at swiftstack.com\n>>>>>\n>>>>>tonytkdk at gmail.com\n>>>>>\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>\n>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>\n>>>>>hello sir,\n>>>>>>\n>>>>>>Please help me in knowing how to use 8080 port \n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com> \n>>>>>>>Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>Hello,\n>>>>>>>\n>>>>>>>Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>\n>>>>>>>\n>>>>>>>Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/ \n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>Thank you,\n>>>>>>>Amanda\n>>>>>>>\n>>>>>>>SwiftStack Inc.\n>>>>>>>swiftstack.com\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>\n>>>>>>>hello sir!\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>same error is continued.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>Cc: anita goel <goel.anita at gmail.com> \n>>>>>>>>>\n>>>>>>>>>Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>\n>>>>>>>>>Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>hello,\n>>>>>>>>>\n>>>>>>>>>I have to configure proxy server.\n>>>>>>>>>For this, \n>>>>>>>>>\n>>>>>>>>>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>\n>>>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>>>swift_hash_path_suffix =pragya \n>>>>>>>>>swift_hash_path_prefix =jain \n>>>>>>>>>\n>>>>>>>>>save and exit.\n>>>>>>>>>then, I run the command:\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>\n>>>>>>>>>Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>for this, I run the following command:\n>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>\n>>>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>>>allow_account_management =true \n>>>>>>>>>...\n>>>>>>>>>[filter:tempauth]\n>>>>>>>>>use = egg:swift#tempauth\n>>>>>>>>>...\n>>>>>>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>user_test_tester = testing .admin\n>>>>>>>>>user_test2_tester2 = testing2 .admin\n>>>>>>>>>user_test_tester3 = testing3\n>>>>>>>>>user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>...\n>>>>>>>>>\n>>>>>>>>>save and exit\n>>>>>>>>>Then, run following commands:\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>Signal proxy-server? pid: 2476? signal: 15\n>>>>>>>>>proxy-server (2476) appears to have stopped\n>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>* About to connect() to localhost port 80\n (#0)\n>>>>>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>>But, there is an error in establising a connection.\n>>>>>>>>>\n>>>>>>>>>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>proxy-server already started...\n>>>>>>>>>\n>>>>>>>>>Please help me in this regard.\n>>>>>>>>>---\n>>>>>>>>>\n>>>>>>>>>Thanks \n>>>>>>>>>\n>>>>>>>>>Pragya Jain\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/1d6ffb85/attachment.html>\n\n','<CA++_uhsXKUwpLmFAXVo7BLy9nRd_g8Gfw+R5gBfd+CyfJA+ACA@mail.gmail.com>',NULL),('<1377768176.9373.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 17:22:56',28800,'2013-08-29 09:22:56',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:~# netstat -antulp | grep 8080 \ntcp??????? 0????? 0 0.0.0.0:8080??????????? 0.0.0.0:*?????????????? LISTEN????? 2421/python??? \n\nuser = swift\n\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013 2:47 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>$> netstat -antulp | grep 8080?\n>\n>\n>1) is 8080 port been used ?\n>2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir,\n>>\n>>I run the command:\n>>\n>>root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>/opt/swift/build/scripts-2.7/swift-proxy-server\n>>/opt/swift/bin/swift-proxy-server\n>>/usr/local/bin/swift-proxy-server\n>>/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>\n>>root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>Traceback (most recent call last):\n>>? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>??? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>??? self.require(requires)[0].run_script(script_name, ns)\n>>? File\n \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>??? execfile(script_filename, namespace, namespace)\n>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>??? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>??? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>??? bind_addr[0], bind_addr[1], bind_timeout))\n>>Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Thursday, 29 August 2013 2:19 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption)?\n>>>\n>>>\n>>>$> find / -name swift-proxy-server\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir\n>>>>\n>>>>\n>>>>Thanks for the help\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>/usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>\n>>>>\n>>>>\n>>>>this is the result of the command.\n>>>>\n>>>>\n>>>>please help in this regard.\n>>>>\n>>>>\n>>>>-----\n>>>>Pragya Jain\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Obviously, There\'s no proxy server running on your node.?\n>>>>>\n>>>>>\n>>>>>Please execute it on the node where proxy-server located:?\n>>>>>(I assume the binary is in /usr/bin and conf file is in /etc/swift)?\n>>>>>\n>>>>>$> /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>\n>>>>>\n>>>>>\n>>>>>What\'s the result ?\n>>>>>\n>>>>>\n>>>>>+Hugo Kuo+\n>>>>>hugo at swiftstack.com\n>>>>>\n>>>>>tonytkdk at gmail.com\n>>>>>\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>\n>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>\n>>>>>hello sir\n>>>>>>\n>>>>>>Thanks for the suggestion.\n>>>>>>\n>>>>>>(1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>>and make following changes:\n>>>>>>\n>>>>>>\n>>>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>>>user_test_tester = testing .admin\n>>>>>>user_test2_tester2 = testing2 .admin\n>>>>>>user_test_tester3 = testing3\n>>>>>>\n>>>>>>user_prag2648_pragya =pj2648 .admin .reseller_admin\n>>>>>>\n>>>>>>and then\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>\n>>>>>>Starting\n proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>>(2) I also tired the connection with user admin:admin\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>\n>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>>(3) I also run the command to verify the port number of proxy\n>>>>>>root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>nobody??? 2124? 0.0? 0.0?? 5384? 1164\n ???????? S??? 10:39?? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>root????? 2724? 0.0? 0.0?? 4368?? 828 pts/0??? R+?? 10:52?? 0:00 grep --color=auto proxy\n>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>Active Internet connections (servers and established)\n>>>>>>Proto Recv-Q Send-Q Local Address?????????? Foreign Address???????? State?????? PID/Program name\n>>>>>>tcp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????? LISTEN????? 931/memcached?? \n>>>>>>tcp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????? LISTEN????? 2124/dnsmasq??? \n>>>>>>tcp??????? 0????? 0 127.0.0.1:631?????????? 0.0.0.0:*?????????????? LISTEN????? 623/cupsd?????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:51521???? 74.125.236.132:80?????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 1????? 0 115.184.7.223:46280???? 91.189.89.144:80??????? CLOSE_WAIT? 1663/ubuntu-geoip-p\n>>>>>>tcp??????? 0????? 0 115.184.7.223:60563???? 173.194.38.147:80?????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:43256???? 124.124.201.179:80????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:41791???? 124.124.201.169:80????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:36669???? 124.124.252.9:80??????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:51747???? 173.194.38.184:80?????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:54229???? 74.125.236.44:443?????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:36185???? 173.194.36.26:80??????? TIME_WAIT?? -?????????????? \n>>>>>>tcp??????? 0????? 0 115.184.7.223:38854???? 74.125.236.109:80?????? TIME_WAIT?? -?????????????? \n>>>>>>tcp6?????? 0????? 0\n ::1:631???????????????? :::*??????????????????? LISTEN????? 623/cupsd?????? \n>>>>>>udp??????? 0????? 0 0.0.0.0:5353??????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>>>>>udp??????? 0????? 0 0.0.0.0:53489?????????? 0.0.0.0:*?????????????????????????? 619/avahi-daemon: r\n>>>>>>udp??????? 0????? 0 127.0.0.1:11211???????? 0.0.0.0:*?????????????????????????? 931/memcached?? \n>>>>>>udp??????? 0????? 0 127.0.0.1:53??????????? 0.0.0.0:*?????????????????????????? 2124/dnsmasq??? \n>>>>>>udp6?????? 0????? 0\n :::5353???????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>>>>>udp6?????? 0????? 0 :::36705??????????????? :::*??????????????????????????????? 619/avahi-daemon: r\n>>>>>>\n>>>>>>Please help to proceed further.\n>>>>>>\n>>>>>>---\n>>>>>>\n>>>>>>Thanks\n>>>>>>\n>>>>>>Pragya jain\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>Hi?\n>>>>>>>\n>>>>>>>\n>>>>>>>1)?user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ??\n>>>>>>>2) Verify the port number of proxy by?\n>>>>>>>$> ps aux | grep proxy?\n>>>>>>>>$> netstat -antulp?\n>>>>>>>\n>>>>>>>\n>>>>>>>3) Check the Proxy for how to setup bind_port?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>+Hugo Kuo+\n>>>>>>>hugo at swiftstack.com\n>>>>>>>\n>>>>>>>tonytkdk at gmail.com\n>>>>>>>\n>>>>>>>+886 935004793\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>\n>>>>>>>hello sir,\n>>>>>>>>\n>>>>>>>>Please help me in knowing how to use 8080 port \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com> \n>>>>>>>>>Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Hello,\n>>>>>>>>>\n>>>>>>>>>Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/ \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Thank you,\n>>>>>>>>>Amanda\n>>>>>>>>>\n>>>>>>>>>SwiftStack Inc.\n>>>>>>>>>swiftstack.com\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>>hello sir!\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>same error is continued.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>Cc: anita goel <goel.anita at gmail.com> \n>>>>>>>>>>>\n>>>>>>>>>>>Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>\n>>>>>>>>>>>Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>hello,\n>>>>>>>>>>>\n>>>>>>>>>>>I have to configure proxy server.\n>>>>>>>>>>>For this, \n>>>>>>>>>>>\n>>>>>>>>>>>I have to edit /etc/swift/swift.conf and change the \nswift_hash_path_suffix to something secret and then, start the proxy \nserver process\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>for this, I use the following commands:root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>\n>>>>>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>>>>>swift_hash_path_suffix =pragya \n>>>>>>>>>>>swift_hash_path_prefix =jain \n>>>>>>>>>>>\n>>>>>>>>>>>save and exit.\n>>>>>>>>>>>then, I run the command:\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>\n>>>>>>>>>>>Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>for this, I run the following command:\n>>>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>\n>>>>>>>>>>>make following changes (highlighted) in the file:\n>>>>>>>>>>>allow_account_management =true \n>>>>>>>>>>>...\n>>>>>>>>>>>[filter:tempauth]\n>>>>>>>>>>>use = egg:swift#tempauth\n>>>>>>>>>>>...\n>>>>>>>>>>>user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>user_test_tester = testing .admin\n>>>>>>>>>>>user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>user_test_tester3 = testing3\n>>>>>>>>>>>user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>...\n>>>>>>>>>>>\n>>>>>>>>>>>save and exit\n>>>>>>>>>>>Then, run following commands:\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>Signal proxy-server? pid: 2476? signal: 15\n>>>>>>>>>>>proxy-server (2476) appears to have stopped\n>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>* About to connect() to localhost port 80\n (#0)\n>>>>>>>>>>>*?? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>\n>>>>>>>>>>>But, there is an error in establising a connection.\n>>>>>>>>>>>\n>>>>>>>>>>>if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>proxy-server already started...\n>>>>>>>>>>>\n>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>---\n>>>>>>>>>>>\n>>>>>>>>>>>Thanks \n>>>>>>>>>>>\n>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>_______________________________________________\n>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/142763b8/attachment.html>\n\n','<CA++_uhun6YFowdHK401VPzQa2AJ4xW5uSMQm5v43_Aw-E49Jfg@mail.gmail.com>',NULL),('<1377775079.21343.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 19:17:59',28800,'2013-08-29 11:17:59',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','Thanks Kuo very much for this help.\nconnection is successfully established.\n\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013 3:46 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>tonytkdk at gmail.com\n>+886 935004793\n>\n>\n>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>\n>> user = swift\n>>\n>> ________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>> To: pragya jain <prag_2648 at yahoo.co.in>\n>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>> Sent: Thursday, 29 August 2013 2:47 PM\n>>\n>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> gt; netstat -antulp | grep 8080 \n>>\n>> 1) is 8080 port been used ?\n>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>\n>>\n>>\n>> +Hugo Kuo+\n>> hugo at swiftstack.com\n>> tonytkdk at gmail.com\n>> +886 935004793\n>>\n>>\n>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>> hello sir,\n>>\n>> I run the command:\n>>\n>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>> /opt/swift/bin/swift-proxy-server\n>> /usr/local/bin/swift-proxy-server\n>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>\n>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>> Traceback (most recent call last):\n>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>> ? ? execfile(script_filename, namespace, namespace)\n>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>\n>>\n>> ________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>> To: pragya jain <prag_2648 at yahoo.co.in>\n>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>> Sent: Thursday, 29 August 2013 2:19 PM\n>>\n>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>\n>> gt; find / -name swift-proxy-server\n>>\n>>\n>>\n>> +Hugo Kuo+\n>> hugo at swiftstack.com\n>> tonytkdk at gmail.com\n>> +886 935004793\n>>\n>>\n>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>> hello sir\n>>\n>> Thanks for the help\n>>\n>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>\n>> this is the result of the command.\n>>\n>> please help in this regard.\n>>\n>> -----\n>> Pragya Jain\n>>\n>> ________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>> To: pragya jain <prag_2648 at yahoo.co.in>\n>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>> Sent: Thursday, 29 August 2013 1:20 PM\n>>\n>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> Obviously, There\'s no proxy server running on your node. \n>>\n>> Please execute it on the node where proxy-server located: \n>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>\n>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>\n>> What\'s the result ?\n>>\n>> +Hugo Kuo+\n>> hugo at swiftstack.com\n>> tonytkdk at gmail.com\n>> +886 935004793\n>>\n>>\n>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>> hello sir\n>>\n>> Thanks for the suggestion.\n>>\n>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>\n>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>\n>> and make following changes:\n>>\n>>\n>> user_admin_admin = admin .admin .reseller_admin\n>> user_test_tester = testing .admin\n>> user_test2_tester2 = testing2 .admin\n>> user_test_tester3 = testing3\n>>\n>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>\n>> and then\n>>\n>> root at arun-Aspire-5742:~# sudo swift-init account start\n>> Starting account-server...(/etc/swift/account-server.conf)\n>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>\n>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>> * About to connect() to localhost port 80 (#0)\n>> * ? Trying 127.0.0.1... Connection refused\n>> * couldn\'t connect to host\n>> * Closing connection #0\n>> curl: (7) couldn\'t connect to host\n>>\n>> (2) I also tired the connection with user admin:admin\n>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>\n>> * About to connect() to localhost port 80 (#0)\n>> * ? Trying 127.0.0.1... Connection refused\n>> * couldn\'t connect to host\n>> * Closing connection #0\n>> curl: (7) couldn\'t connect to host\n>>\n>> (3) I also run the command to verify the port number of proxy\n>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>> root at arun-Aspire-5742:~# netstat -antulp\n>> Active Internet connections (servers and established)\n>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>\n>> Please help to proceed further.\n>>\n>> ---\n>>\n>> Thanks\n>>\n>> Pragya jain\n>>\n>>\n>> ________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>> To: pragya jain <prag_2648 at yahoo.co.in>\n>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>> Sent: Wednesday, 28 August 2013 9:59 PM\n>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> Hi \n>>\n>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>> 2) Verify the port number of proxy by \n>>\n>> gt; ps aux | grep proxy \n>> gt; netstat -antulp \n>>\n>>\n>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>\n>>\n>>\n>>\n>>\n>> +Hugo Kuo+\n>> hugo at swiftstack.com\n>> tonytkdk at gmail.com\n>> +886 935004793\n>>\n>>\n>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>> hello sir,\n>>\n>> Please help me in knowing how to use 8080 port\n>>\n>>\n>> ________________________________\n>> From: Amanda Plimpton <amanda at swiftstack.com>\n>> To: pragya jain <prag_2648 at yahoo.co.in>\n>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>> Sent: Tuesday, 27 August 2013 9:40 AM\n>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> Hello,\n>>\n>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>\n>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>\n>>\n>> Thank you,\n>> Amanda\n>>\n>> SwiftStack Inc.\n>> swiftstack.com\n>>\n>>\n>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>> hello sir!\n>>\n>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>> same error is continued.\n>>\n>> ----- Forwarded Message -----\n>> From: pragya jain <prag_2648 at yahoo.co.in>\n>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>> Cc: anita goel <goel.anita at gmail.com>\n>> Sent: Monday, 26 August 2013 12:06 PM\n>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>\n>> hello,\n>>\n>> I have to configure proxy server.\n>> For this,\n>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>\n>> for this, I use the following commands:\n>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>\n>> make following changes (highlighted) in the file:\n>> swift_hash_path_suffix =pragya\n>> swift_hash_path_prefix =jain\n>>\n>> save and exit.\n>> then, I run the command:\n>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>\n>> Now, I have to set up Tempauth authentication & authorization with Swift\n>> for this, I run the following command:\n>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>\n>> make following changes (highlighted) in the file:\n>> allow_account_management =true\n>> ...\n>> [filter:tempauth]\n>> use = egg:swift#tempauth\n>> ...\n>> user_admin_admin = admin .admin .reseller_admin\n>> user_test_tester = testing .admin\n>> user_test2_tester2 = testing2 .admin\n>> user_test_tester3 = testing3\n>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>> ...\n>>\n>> save and exit\n>> Then, run following commands:\n>> root at arun-Aspire-5742:~# sudo swift-init account start\n>> Starting account-server...(/etc/swift/account-server.conf)\n>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>> Signal proxy-server ?pid: 2476 ?signal: 15\n>> proxy-server (2476) appears to have stopped\n>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>> * About to connect() to localhost port 80 (#0)\n>> * ? Trying 127.0.0.1... Connection refused\n>> * couldn\'t connect to host\n>> * Closing connection #0\n>> curl: (7) couldn\'t connect to host\n>>\n>> But, there is an error in establising a connection.\n>>\n>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>> proxy-server already started...\n>>\n>> Please help me in this regard.\n>> ---\n>>\n>> Thanks\n>>\n>> Pragya Jain\n>>\n>>\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to ? ? : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/e7203d7b/attachment.html>\n\n','<CA++_uhsNgh_UwQQWiR1A1ZFF=DNap+T_pLkH1J8gkwXrL4BqTQ@mail.gmail.com>',NULL),('<1377784746.26442.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 21:59:06',28800,'2013-08-29 13:59:06',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nconnection is established successfully. But, when I try to create an account, I face the problem.\n\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n< Content-Length: 0\n< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n< Date: Thu, 29 Aug 2013 12:22:46 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# python\nPython 2.7.3 (default, Apr 10 2013, 05:46:21)?\n[GCC 4.6.3] on linux2\nType \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>> import swift.common.memcached as memcached\n>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\nAUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n< Date: Thu, 29 Aug 2013 12:30:55 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n\nPlease help me in this regard.\n\n---\n\nPragya Jain\n\n>________________________________\n> From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Kuo Hugo <tonytkdk at gmail.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013 4:47 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Thanks Kuo very much for this help.\n>connection is successfully established.\n>\n>\n>\n>\n>\n>\n>>________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Thursday, 29 August 2013 3:46 PM\n>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>> \n>>\n>>\n>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>\n>>\n>>+Hugo Kuo+\n>>hugo at swiftstack.com\n>>tonytkdk at gmail.com\n>>+886 935004793\n>>\n>>\n>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>\n>>> user = swift\n>>>\n>>> ________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>\n>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> gt; netstat -antulp | grep 8080 \n>>>\n>>> 1) is 8080 port been used ?\n>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>\n>>>\n>>>\n>>> +Hugo Kuo+\n>>> hugo at swiftstack.com\n>>> tonytkdk at gmail.com\n>>> +886 935004793\n>>>\n>>>\n>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>> hello sir,\n>>>\n>>> I run the command:\n>>>\n>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>> /opt/swift/bin/swift-proxy-server\n>>> /usr/local/bin/swift-proxy-server\n>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>\n>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>> Traceback (most recent call last):\n>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>> ? ? execfile(script_filename, namespace, namespace)\n>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>\n>>>\n>>> ________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>\n>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>\n>>> gt; find / -name swift-proxy-server\n>>>\n>>>\n>>>\n>>> +Hugo Kuo+\n>>> hugo at swiftstack.com\n>>> tonytkdk at gmail.com\n>>> +886 935004793\n>>>\n>>>\n>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>> hello sir\n>>>\n>>> Thanks for the help\n>>>\n>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>\n>>> this is the result of the command.\n>>>\n>>> please help in this regard.\n>>>\n>>> -----\n>>> Pragya Jain\n>>>\n>>> ________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>\n>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> Obviously, There\'s no proxy server running on your node. \n>>>\n>>> Please execute it on the node where proxy-server located: \n>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>\n>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>\n>>> What\'s the result ?\n>>>\n>>> +Hugo Kuo+\n>>> hugo at swiftstack.com\n>>> tonytkdk at gmail.com\n>>> +886 935004793\n>>>\n>>>\n>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>> hello sir\n>>>\n>>> Thanks for the suggestion.\n>>>\n>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>\n>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>\n>>> and make following changes:\n>>>\n>>>\n>>> user_admin_admin = admin .admin .reseller_admin\n>>> user_test_tester = testing .admin\n>>> user_test2_tester2 = testing2 .admin\n>>> user_test_tester3 = testing3\n>>>\n>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>\n>>> and then\n>>>\n>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>> Starting account-server...(/etc/swift/account-server.conf)\n>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>\n>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>> * About to connect() to localhost port 80 (#0)\n>>> * ? Trying 127.0.0.1... Connection refused\n>>> * couldn\'t connect to host\n>>> * Closing connection #0\n>>> curl: (7) couldn\'t connect to host\n>>>\n>>> (2) I also tired the connection with user admin:admin\n>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>\n>>> * About to connect() to localhost port 80 (#0)\n>>> * ? Trying 127.0.0.1... Connection refused\n>>> * couldn\'t connect to host\n>>> * Closing connection #0\n>>> curl: (7) couldn\'t connect to host\n>>>\n>>> (3) I also run the command to verify the port number of proxy\n>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>> root at arun-Aspire-5742:~# netstat -antulp\n>>> Active Internet connections (servers and established)\n>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>\n>>> Please help to proceed further.\n>>>\n>>> ---\n>>>\n>>> Thanks\n>>>\n>>> Pragya jain\n>>>\n>>>\n>>> ________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> Hi \n>>>\n>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>> 2) Verify the port number of proxy by \n>>>\n>>> gt; ps aux | grep proxy \n>>> gt; netstat -antulp \n>>>\n>>>\n>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>\n>>>\n>>>\n>>>\n>>>\n>>> +Hugo Kuo+\n>>> hugo at swiftstack.com\n>>> tonytkdk at gmail.com\n>>> +886 935004793\n>>>\n>>>\n>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>> hello sir,\n>>>\n>>> Please help me in knowing how to use 8080 port\n>>>\n>>>\n>>> ________________________________\n>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> Hello,\n>>>\n>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>\n>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>\n>>>\n>>> Thank you,\n>>> Amanda\n>>>\n>>> SwiftStack Inc.\n>>> swiftstack.com\n>>>\n>>>\n>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>> hello sir!\n>>>\n>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>> same error is continued.\n>>>\n>>> ----- Forwarded Message -----\n>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>> Cc: anita goel <goel.anita at gmail.com>\n>>> Sent: Monday, 26 August 2013 12:06 PM\n>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>\n>>> hello,\n>>>\n>>> I have to configure proxy server.\n>>> For this,\n>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>\n>>> for this, I use the following commands:\n>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>\n>>> make following changes (highlighted) in the file:\n>>> swift_hash_path_suffix =pragya\n>>> swift_hash_path_prefix =jain\n>>>\n>>> save and exit.\n>>> then, I run the command:\n>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>\n>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>> for this, I run the following command:\n>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>\n>>> make following changes (highlighted) in the file:\n>>> allow_account_management =true\n>>> ...\n>>> [filter:tempauth]\n>>> use = egg:swift#tempauth\n>>> ...\n>>> user_admin_admin = admin .admin .reseller_admin\n>>> user_test_tester = testing .admin\n>>> user_test2_tester2 = testing2 .admin\n>>> user_test_tester3 = testing3\n>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>> ...\n>>>\n>>> save and exit\n>>> Then, run following commands:\n>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>> Starting account-server...(/etc/swift/account-server.conf)\n>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>> proxy-server (2476) appears to have stopped\n>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>> * About to connect() to localhost port 80 (#0)\n>>> * ? Trying 127.0.0.1... Connection refused\n>>> * couldn\'t connect to host\n>>> * Closing connection #0\n>>> curl: (7) couldn\'t connect to host\n>>>\n>>> But, there is an error in establising a connection.\n>>>\n>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>> proxy-server already started...\n>>>\n>>> Please help me in this regard.\n>>> ---\n>>>\n>>> Thanks\n>>>\n>>> Pragya Jain\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to ? ? : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/f67c3c61/attachment.html>\n\n','<1377775079.21343.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1377803832.50212.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 20:17:12',3600,'2013-08-29 19:17:12',NULL,'[Openstack] A document question','\n\nI think the doc is ok - the sql string is no longer needed in the nova.conf on the compute nodes. \n\nWith nova-conductor the compute node does not access the db\nhttps://russellbryantnet.wordpress.com/2012/11/19/a-new-nova-service-nova-conductor/\n\n>________________________________\n> From: Anne Gentle <anne at openstack.org>\n>To: \"Gangur, Hrushikesh (HP Converged Cloud - R&D - Sunnyvale)\" <hrushikesh.gangur at hp.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 29 August 2013, 19:34\n>Subject: Re: [Openstack] A document question\n> \n>\n>\n>Hm, but the OVS_MultiNode guide uses a nova-compute.conf file that doesn\'t contain a mysql connection line.?\n>\n>\n>So what\'s different about Joshua\'s install that\'s requiring mysql knowledge on his compute node??\n>\n>\n>\n>On Thu, Aug 29, 2013 at 12:42 PM, Gangur, Hrushikesh (HP Converged Cloud - R&D - Sunnyvale) <hrushikesh.gangur at hp.com> wrote:\n>\n>It has to have db connection string in nova.conf. Refer this article: https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/OVS_MultiNode/OpenStack_Grizzly_Install_Guide.rst\n>>?\n>>From:Joshua Skains [mailto:Joshua.Skains at evault.com] \n>>Sent: Thursday, August 29, 2013 10:32 AM\n>>To: openstack at lists.openstack.org\n>>Subject: [Openstack] A document question\n>>?\n>>http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_compute.html\n>>?\n>>I noticed the nova instance on the compute node does not get connected to MySQL? Is that correct?\n>>?\n>>JMS\n>>?\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ???: openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n\n\n','<CAD0KtVE-bjcrRP+sTeesgJm+h78sczWgK1t7tFmTL0NwBicBnQ@mail.gmail.com>',NULL),('<1377805497.20.1387001141195.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-14 06:05:40',0,'2013-12-14 06:05:40',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-havana #6','See <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/6/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise18 in workspace <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/>\nCheckout:periodic-horizon-docs-havana / <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/> - hudson.remoting.Channel at 1faa1b85:precise18\nUsing strategy: Default\nLast Built Revision: Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/horizon\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/horizon\nCommencing build of Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\nChecking out Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\n[periodic-horizon-docs-havana] $ /bin/bash -xe /tmp/hudson286685432669360717.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack horizon /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=horizon\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n++ org=openstack\n++ project=horizon\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack horizon /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=horizon\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z horizon ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/horizon /opt/requirements/projects.txt\nopenstack/horizon\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/requirements.txt,> -r<https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/test-requirements.txt>\nvenv inst: <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/dist/horizon-jenkins.periodic.horizon.docs.havana.6.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-havana/precise18\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-havana/precise18/6\n[SCP] Copying console log.\n\n\n','<1824755389.6.1386915518697.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1377836466.15919.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 21:21:06',-25200,'2013-08-30 04:21:06',NULL,'[Openstack] Install/Enable Quantum lbass (load balancer)\n	feature?','Hi,\n\nI am not sure about Ubuntu. I was never able to get openstack working on Ubuntu so I gave up, but this is the process I used to set up LBaas on CentOS\nPlease replace commands with Ubuntu style commands\n\n\n??Add Quantum LBaas service to Openstack RDO\n\n1. install haproxy if it not already installed\n# yum install haproxy -y\n# reboot\n\n2. Make sure you have the modified kernel that supports namespaces. (not necessary on Ubuntu. Already supports namespaces)\n# uname -r?\nShould look something like this. Your version may be different -> 2.6.32-358.114.1.openstack.el6.x86_64\n\n3. Add following line in /etc/quantum/quantum.conf on your quantum-server host and restart quantum-server\n# vi /etc/quantum/quantum.conf\n---------------------------------\nservice_plugins = quantum.plugins.services.agent_loadbalancer.plugin.LoadBalancerPlugin\n---------------------------------\n# /etc/init.d/quantum-server restart\n\n4. Insert the following line in /etc/openstack-dashboard/local_settings on horizon host, and restart httpd. This enables LBaaS operations on Dashboard WebUI\n# vi /etc/openstack-dashboard/local_settings\n--------------------------------- ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??\nOPENSTACK_QUANTUM_NETWORK = { ??\n\'enable_lb\': True\n}\n---------------------------------\n# service httpd restart\n\n5. Update the following lines in /etc/quantum/lbaas_agent.ini , then restart quantum-lbaas-agent service\n# vi /etc/quantum/lbaas_agent.ini\n---------------------------------\novs_use_veth = True\nuse_namespaces = True\ninterface_driver = quantum.agent.linux.interface.OVSInterfaceDriver\ndevice_driver = quantum.plugins.services.agent_loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver\nuser_group = haproxy\n---------------------------------\n# /etc/init.d/quantum-lbaas-agent restart\n\n\nThis process worked for me, you could give it a try.\n\nBest,\nJake\n\n\n\n\n________________________________\n From: Mahardhika <mahardika.gilang at andalabs.com>\nTo: Jake G. <dj_dark_junglist at yahoo.com>; Eugene Nikanorov <enikanorov at mirantis.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Friday, August 30, 2013 1:01 PM\nSubject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n \n\n\nDoes lbass can get install on ubuntu based system? how to check it?\n\nOn 8/12/2013 4:16 PM, Jake G. wrote:\n\nOk i started from scratch and now everything is working just fine. Thank you for all your help.?\n>In the end I believe it was because I did not have haproxy installed.?\n>\n>\n>\n>\n>\n>\n>\n>________________________________\n> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>To: Jake G. <dj_dark_junglist at yahoo.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, August 9, 2013 7:50 PM\n>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n> \n>\n>\n>use_namespaces has no effect, lbaas agent?in grizzly?always relies on namespace support. \n>\n>\n>Could you execute the failing command manually??\n>That needs to be done after you create a vip for the pool.\n>The command should look like this:\n>sudo quantum-rootwrap /etc/quantum/rootwrap.conf ip netns exec qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029 haproxy -f /var\n>/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf -p /var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\n>\n>\n><e10951cd-4cca-4ba4-acc0-0ccde6817029> should be replaced with actual pool_id\n>\n>Could you also verify that path and file?/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf exist?\n>\n>\n>Thanks,\n>Eugene.\n>\n>\n>\n>On Fri, Aug 9, 2013 at 12:39 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>\n>Yes this is my Kernel> ?2.6.32-358.114.1.openstack.el6.x86_64\n>>and I enable:?\n>>\n>>\n>>use_namespaces = True\n>>\n>>ovs_use_veth = True\n>>\n>>\n>>in?/etc/quantum/dhcp_agent.ini and etc/quantum/l3_agent.ini\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>________________________________\n>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Friday, August 9, 2013 5:33 PM \n>>\n>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>> \n>>\n>>\n>>Jake, haproxy.cfg is created by lbaas agent when you deploy an instance. \n>>Are you sure your host os has namespace support?\n>>\n>>\n>>Eugene.\n>>\n>>\n>>\n>>On Fri, Aug 9, 2013 at 12:30 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>\n>>Good call!\n>>>Looks like i did but the service wont start. Do you have a sample haproxy.cfg file that will work with Openstack?\n>>>\n>>>\n>>>Thank you\n>>>\n>>>\n>>>\n>>>________________________________\n>>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, August 9, 2013 3:08 PM \n>>>\n>>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>>> \n>>>\n>>>\n>>>Do you have haproxy package installed on your host?\n>>>\n>>>\n>>>\n>>>On Fri, Aug 9, 2013 at 9:41 AM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>>\n>>>I have enabled LBaas on my openstack, but after adding a pool, vip, members, and monitor successfully I am still unable to get load balancing working.?\n>>>>I found this blog to help me so far?http://kimizhang.wordpress.com/2013/08/08/openstack-grizzly-quantum-advanced-features-2/\n>>>>\n>>>>\n>>>>When I run # ps -ef | grep haproxy I dont get much:?\n>>>>root 27508 2718 0 14:16 pts/1 00:00:00 grep haproxy\n>>>>\n>>>>\n>>>>My logs show an issue with haproxy:\n>>>>\n>>>>\n>>>>RuntimeError:?\n>>>>Command: [\'sudo\', \'quantum-rootwrap\', \'/etc/quantum/rootwrap.conf\', \'ip\', \'netns\', \'exec\', \'qlbaas-e10951cd-4cca-4ba4-acc0-0ccde6817029\', \'haproxy\', \'-f\', \'/var\n>>>>/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/conf\', \'-p\', \'/var/lib/quantum/lbaas/e10951cd-4cca-4ba4-acc0-0ccde6817029/pid\']\n>>>>Exit code: 255\n>>>>Stdout: \'\'\n>>>>Stderr: \'exec of haproxy failed: No such file or directory\\n\'\n>>>>2013-08-09 14:16:17 ? ?ERROR [quantum.plugins.services.agent_loadbalancer.agent.manager] Unable to refresh device for pool: e10951cd-4cca-4ba4-acc0-0ccde6817029\n>>>>Traceback (most recent call last):\n>>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/agent/manager.py\", line 189, in refresh_device\n>>>>? ? self.driver.create(logical_config)\n>>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 48, in create\n>>>>? ? self._spawn(logical_config)\n>>>>? File \"/usr/lib/python2.6/site-packages/quantum/plugins/services/agent_loadbalancer/drivers/haproxy/namespace_driver.py\", line 70, in _spawn\n>>>>? ? ns.netns.execute(cmd)\n>>>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/ip_lib.py\", line 414, in execute\n>>>>? ? check_exit_code=check_exit_code)\n>>>>? File \"/usr/lib/python2.6/site-packages/quantum/agent/linux/utils.py\", line 61, in execute\n>>>>? ? raise RuntimeError(m)\n>>>>\n>>>>\n>>>>Any ideas?\n>>>>\n>>>>\n>>>>\n>>>>________________________________\n>>>> From: Eugene Nikanorov <enikanorov at mirantis.com>\n>>>>To: Jake G. <dj_dark_junglist at yahoo.com> \n>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>Sent: Thursday, August 8, 2013 7:04 PM\n>>>>Subject: Re: [Openstack] Install/Enable Quantum lbass (load balancer) feature?\n>>>> \n>>>>\n>>>>\n>>>>Hi Jake, \n>>>>\n>>>>\n>>>>Regarding lbaas in grizzly working on RHEL/Centos - it may be problematic as host operation system must support network namespaces.?\n>>>>If you do have support for network namespaces then you need to do the following steps to setup lbaas service in quantum:\n>>>>\n>>>>\n>>>>\n>>>>1) specify lbaas plugin in quantum.conf:\n>>>>service_plugins=\nlbaas_plugin_classpath.\n>>>>check quantum/plugins/services/agent_loadbalancer/plugin.py for correct path as currently the name and path has changed.\n>>>>\n>>>>\n>>>>2) to enable lbaas service in horizon you need to do the following:\n>>>>add the following piece of code to?horizon/openstack_dashboard/local/local_settings.py :\n>>>>\n>>>>\n>>>>OPENSTACK_QUANTUM_NETWORK = {\n>>>>? ? \'enable_lb\': False\n>>>>}\n>>>>\n>>>>\n>>>>3) start quantum-lbaas-agent on the host providing quantum.conf and lbaas-agent.ini. lbaas-agent.ini should reflect core plugin configuration (should have proper interface driver)\n>>>>\n>>>>\n>>>>Note that if host os has no namespace support, all of above will work (e.g. REST API will be functional), but you would not be able to deploy loadbalancer as lbaas agent can only work with namespaces.\n>>>>\n>>>>\n>>>>Thanks,\n>>>>Eugene.\n>>>>\n>>>>\n>>>>\n>>>>On Thu, Aug 8, 2013 at 1:14 PM, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n>>>>\n>>>>Hi all!\n>>>>>How can we install/enable the Quantum-lbaas (load balancer) feature for Openstack Grizzly? I dont see any docs for RHEL/CentOS specific installs.?\n>>>>>I used RDO to deploy Openstack on a single node.\n>>>>>\n>>>>>\n>>>>>\n>>>>>Thank you! Jake\n>>>>>_______________________________________________\n>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n>\n>\n>\n>_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to     : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\n\n-- \nRegards,\nMahardhika Gilang\n\nPT. Andalabs Technology \nGedung Gravira\nJl. Cideng Barat no. 54\nJakarta Pusat 10150\n\nHP : 0852 139 55861\nEmail : mahardika.gilang at andalabs.com \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/82ef132a/attachment.html>\n\n','<5220192D.2050600@andalabs.com>',NULL),('<1377840941.9818.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 13:35:41',28800,'2013-08-30 05:35:41',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nI am working on single node.\nPlease let me know how to check network topology and ring structure.\n\n\n\n\n>________________________________\n> From: Gareth <academicgareth at gmail.com>\n>To: Kuo Hugo <tonytkdk at gmail.com> \n>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 8:11 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Pragya\n>\n>\n>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>\n>\n>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>\n>\n>\n>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>\n>Hi Pragya,?\n>>\n>>\n>>I need more information.?\n>>\n>>\n>>1) Please draw a network topology of your environment\n>>2) How many nodes do you have? ?\n>>3) What\'s the ring looks like ?\n>>\n>>\n>>\n>>Hugo Kuo\n>>hugo at swiftstack.com\n>>\n>>tonytkdk at gmail.com\n>>\n>>+886 935004793\n>>\n>>\n>>\n>>\n>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>>hello sir,\n>>>\n>>>\n>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>\n>>>\n>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /auth/v1.0/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Auth-User:prag2648:pragya\n>>>> X-Auth-Key:pj2648\n>>>>?\n>>>< HTTP/1.1 200 OK\n>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>< Content-Length: 0\n>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>>root at arun-Aspire-5742:~# python\n>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>[GCC 4.6.3] on linux2\n>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>> import swift.common.memcached as memcached\n>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>?\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>* ? Trying 127.0.0.1... Connection refused\n>>>* couldn\'t connect to host\n>>>* Closing connection #0\n>>>curl: (7) couldn\'t connect to host\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>?\n>>>< HTTP/1.1 503 Internal Server Error\n>>>< Content-Length: 118\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>\n>>>\n>>>Please help me in this regard.\n>>>\n>>>\n>>>---\n>>>\n>>>\n>>>Pragya Jain\n>>>\n>>>>________________________________\n>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>\n>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>Thanks Kuo very much for this help.\n>>>>connection is successfully established.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>\n>>>>>\n>>>>>+Hugo Kuo+\n>>>>>hugo at swiftstack.com\n>>>>>tonytkdk at gmail.com\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>\n>>>>>> user = swift\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>\n>>>>>> 1) is 8080 port been used ?\n>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir,\n>>>>>>\n>>>>>> I run the command:\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>> Traceback (most recent call last):\n>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>\n>>>>>> gt; find / -name swift-proxy-server\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir\n>>>>>>\n>>>>>> Thanks for the help\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>\n>>>>>> this is the result of the command.\n>>>>>>\n>>>>>> please help in this regard.\n>>>>>>\n>>>>>> -----\n>>>>>> Pragya Jain\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>\n>>>>>> Please execute it on the node where proxy-server located: \n>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>\n>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> What\'s the result ?\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir\n>>>>>>\n>>>>>> Thanks for the suggestion.\n>>>>>>\n>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> and make following changes:\n>>>>>>\n>>>>>>\n>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>> user_test_tester = testing .admin\n>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>> user_test_tester3 = testing3\n>>>>>>\n>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>\n>>>>>> and then\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>> Active Internet connections (servers and established)\n>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>\n>>>>>> Please help to proceed further.\n>>>>>>\n>>>>>> ---\n>>>>>>\n>>>>>> Thanks\n>>>>>>\n>>>>>> Pragya jain\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Hi \n>>>>>>\n>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>> 2) Verify the port number of proxy by \n>>>>>>\n>>>>>> gt; ps aux | grep proxy \n>>>>>> gt; netstat -antulp \n>>>>>>\n>>>>>>\n>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir,\n>>>>>>\n>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Hello,\n>>>>>>\n>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>\n>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>\n>>>>>>\n>>>>>> Thank you,\n>>>>>> Amanda\n>>>>>>\n>>>>>> SwiftStack Inc.\n>>>>>> swiftstack.com\n>>>>>>\n>>>>>>\n>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>> hello sir!\n>>>>>>\n>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>> same error is continued.\n>>>>>>\n>>>>>> ----- Forwarded Message -----\n>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> hello,\n>>>>>>\n>>>>>> I have to configure proxy server.\n>>>>>> For this,\n>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>\n>>>>>> for this, I use the following commands:\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>\n>>>>>> make following changes (highlighted) in the file:\n>>>>>> swift_hash_path_suffix =pragya\n>>>>>> swift_hash_path_prefix =jain\n>>>>>>\n>>>>>> save and exit.\n>>>>>> then, I run the command:\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>\n>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>> for this, I run the following command:\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> make following changes (highlighted) in the file:\n>>>>>> allow_account_management =true\n>>>>>> ...\n>>>>>> [filter:tempauth]\n>>>>>> use = egg:swift#tempauth\n>>>>>> ...\n>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>> user_test_tester = testing .admin\n>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>> user_test_tester3 = testing3\n>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>> ...\n>>>>>>\n>>>>>> save and exit\n>>>>>> Then, run following commands:\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>> proxy-server (2476) appears to have stopped\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> But, there is an error in establising a connection.\n>>>>>>\n>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>> proxy-server already started...\n>>>>>>\n>>>>>> Please help me in this regard.\n>>>>>> ---\n>>>>>>\n>>>>>> Thanks\n>>>>>>\n>>>>>> Pragya Jain\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> _______________________________________________\n>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n>-- \n>\n>Gareth\n>\n>\n>Cloud Computing, OpenStack, Fitness, Basketball\n>OpenStack contributor\n>Company: UnitedStack\n>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>and I\'ll donate $1 or ?1 to an open organization you specify.\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130830/922eb426/attachment-0001.html>\n\n','<CAAhuP_9LLRBB1U1rK668MX3tSTykRBPy08F7Kpn7X+tf1neeNQ@mail.gmail.com>',NULL),('<1377840952-sup-6417@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-29 22:36:18',-25200,'2013-08-30 05:36:18',NULL,'[openstack-dev] [TRIPLEO] Derekh for tripleo core','(sent 2 days ago, but re-sending this as it never seemed to have arrived\non the mailing list)\n\nExcerpts from Robert Collins\'s message of 2013-08-27 14:25:47 -0700:\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt\n> \n> - Derek is reviewing fairly regularly and has got a sense of the\n> culture etc now, I think.\n> \n> So - calling for votes for Derek to become a TripleO core reviewer!\n\n+1\n\n> \n> I think we\'re nearly at the point where we can switch to the \'two\n> +2\'s\' model - what do you think?\n> \n\nI am reluctant to go there just yet. We have a couple of absentee\nmembers of core at the moment and thus we really only have 4 active\nreviewers. That is \"n+1\", but I worry about reviewers getting fatigued\nor feeling pressure to get to more reviews rather than feeling pressure\nto do a few really thorough reviews.\n\nSo I think we should let derekh\'s presence on core be felt for a few\nweeks and then re-visit the +4 requirement then.\n\n\n','<CAJ3HoZ3XfzNbSJo5irSsdUHNL7X0kvruEJcicXm=49=EsoPxFg@mail.gmail.com>',NULL),('<1377841091.5686.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 13:38:11',28800,'2013-08-30 05:38:11',NULL,'[Openstack] problem in creating account in swift','hello sir,\n\nPlease help me to know how to check port of account server and how can I connect to them directly.\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Thursday, 29 August 2013 8:59 PM\n>Subject: Re: problem in creating account in swift\n> \n>\n>\n>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>\n>\n>\n>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>\n>>\n>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>Starting account-server...(/etc/swift/account-server.conf)\n>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /auth/v1.0/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Auth-User:prag2648:pragya\n>>> X-Auth-Key:pj2648\n>>>?\n>>< HTTP/1.1 200 OK\n>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>< Content-Length: 0\n>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>>root at arun-Aspire-5742:~# python\n>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>[GCC 4.6.3] on linux2\n>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>> import swift.common.memcached as memcached\n>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>?\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>* ? Trying 127.0.0.1... Connection refused\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>?\n>>< HTTP/1.1 503 Internal Server Error\n>>< Content-Length: 118\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>\n>>\n>>Please help me in this regard.\n>>\n>>\n>>---\n>>\n>>\n>>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130830/506fdcfd/attachment.html>\n\n','<CA+_JKzpzeVFZRrY0Z0RS7Mz3+eDhbJ1EzFWLzT_AmZ5rzFiACw@mail.gmail.com>',NULL),('<1377842788.43846.YahooMailNeo@web163001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 23:06:28',-25200,'2013-08-30 06:06:28',NULL,'[Openstack] Baremetal OS image support','Hi! Also I found another issue with the wiki\n\nglance image-create --name deploy-vmlinuz --public --disk-format aki < vmlinuz-$KERNEL\n\nSeems to be no longer a valid command since you edited the diskbuilder portion of?the?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?page.\n\nCan you confirm this?\n\n\n\n\n________________________________\n From: Jake G. <dj_dark_junglist at yahoo.com>\nTo: Robert Collins <robertc at robertcollins.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Thursday, August 29, 2013 2:01 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\n\nHi Rob,\n\nI have a question on the part you changed on the?https://wiki.openstack.org/wiki/Baremetal#Image_Requirements?page.\n\n\nbin/ramdisk-image-create deploy -a i386 -o my-deploy-ramdisk\n\nWhat if I am creating a x86_64 image? what should this line look like?\n\nThank you,\nJake\n\n\n\n\n________________________________\n From: Robert Collins <robertc at robertcollins.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nSent: Wednesday, August 21, 2013 6:43 PM\nSubject: Re: [Openstack] Baremetal OS image support\n \n\nOn 21 August 2013 21:37, Jake G. <dj_dark_junglist at yahoo.com> wrote:\n\n> Hi Rob,\n> Thank you for the info. I look forward to those images.\n>\n> I am using this document for baremetal deployment, which has the -k in it\n ->\n> https://wiki.openstack.org/wiki/Baremetal\n> This seem to be the only documentation available for how to implement the\n> baremetal feature. Would you know of a better doc?\n\nThat page was a little stale; I\'ve done a super-minimal update to it.\n\nCheers,\nRob\n\n-- \nRobert Collins <rbtcollins at hp.com>\nDistinguished Technologist\nHP Converged Cloud\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130829/59732b1a/attachment.html>\n\n','<1377752492.62463.YahooMailNeo@web163003.mail.bf1.yahoo.com>',NULL),('<1377843725.53401.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 14:22:05',28800,'2013-08-30 06:22:05',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n/etc/swift/account.builder, build version 1\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n/etc/swift/container.builder, build version 1\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n/etc/swift/object.builder, build version 1\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:~# ps aux | grep swift\nswift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\nswift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\nswift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\nswift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\nswift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\nswift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nswift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nswift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nswift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nswift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\nroot ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\nroot at arun-Aspire-5742:~# df -h\nFilesystem ? ? ?Size ?Used Avail Use% Mounted on\n/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\nudev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\ntmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\nnone ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\nnone ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\nroot at arun-Aspire-5742:~# ls /srv/node/*\n/srv/node/d1:\n\n/srv/node/d2:\n\n/srv/node/d3:\nroot at arun-Aspire-5742:~# netstat -antulp\nActive Internet connections (servers and established)\nProto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\ntcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\nISHED 941/memcached ??\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\ntcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\ntcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\nudp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\nudp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\nudp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\nudp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\nudp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\nudp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\nroot at arun-Aspire-5742:~# swift-init all status\nNo container-updater running\nNo account-auditor running\nNo object-replicator running\nproxy-server running (5192 - /etc/swift/proxy-server.conf)\nNo container-replicator running\nNo object-auditor running\nNo object-expirer running\nNo container-auditor running\nNo container-server running\naccount-server running (5174 - /etc/swift/account-server.conf)\nNo account-reaper running\nNo container-sync running\nNo account-replicator running\nNo object-updater running\nNo object-server running\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 11:23 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hi Pragya :?\n>\n>\n>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>\n>\n>\n>Check rings :\n>$> swift-ring-builder /etc/swift/object.builder\n>>$> swift-ring-builder /etc/swift/container.builder\n>>$> swift-ring-builder /etc/swift/account.builder\n>\n>\n>Check Swift workers :?\n>$> swift-init all status\n>>$> ps aux | grep swift\n>>$> df -h?\n>>$> ls /srv/node/*\n>>$> netstat -antulp\n>\n>\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir,\n>>\n>>\n>>I am working on single node.\n>>Please let me know how to check network topology and ring structure.\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Gareth <academicgareth at gmail.com>\n>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Pragya\n>>>\n>>>\n>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>\n>>>\n>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>\n>>>\n>>>\n>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>\n>>>Hi Pragya,?\n>>>>\n>>>>\n>>>>I need more information.?\n>>>>\n>>>>\n>>>>1) Please draw a network topology of your environment\n>>>>2) How many nodes do you have? ?\n>>>>3) What\'s the ring looks like ?\n>>>>\n>>>>\n>>>>\n>>>>Hugo Kuo\n>>>>hugo at swiftstack.com\n>>>>\n>>>>tonytkdk at gmail.com\n>>>>\n>>>>+886 935004793\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>hello sir,\n>>>>>\n>>>>>\n>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Auth-User:prag2648:pragya\n>>>>>> X-Auth-Key:pj2648\n>>>>>>?\n>>>>>< HTTP/1.1 200 OK\n>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>< Content-Length: 0\n>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>>root at arun-Aspire-5742:~# python\n>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>[GCC 4.6.3] on linux2\n>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>?\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>* couldn\'t connect to host\n>>>>>* Closing connection #0\n>>>>>curl: (7) couldn\'t connect to host\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>?\n>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>< Content-Length: 118\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>\n>>>>>\n>>>>>Please help me in this regard.\n>>>>>\n>>>>>\n>>>>>---\n>>>>>\n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>>________________________________\n>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>\n>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>Thanks Kuo very much for this help.\n>>>>>>connection is successfully established.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>\n>>>>>>>\n>>>>>>>+Hugo Kuo+\n>>>>>>>hugo at swiftstack.com\n>>>>>>>tonytkdk at gmail.com\n>>>>>>>+886 935004793\n>>>>>>>\n>>>>>>>\n>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>\n>>>>>>>> user = swift\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>\n>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir,\n>>>>>>>>\n>>>>>>>> I run the command:\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>> Traceback (most recent call last):\n>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>\n>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir\n>>>>>>>>\n>>>>>>>> Thanks for the help\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>\n>>>>>>>> this is the result of the command.\n>>>>>>>>\n>>>>>>>> please help in this regard.\n>>>>>>>>\n>>>>>>>> -----\n>>>>>>>> Pragya Jain\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>\n>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>\n>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> What\'s the result ?\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir\n>>>>>>>>\n>>>>>>>> Thanks for the suggestion.\n>>>>>>>>\n>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> and make following changes:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>> user_test_tester = testing .admin\n>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>\n>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>\n>>>>>>>> and then\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>\n>>>>>>>> Please help to proceed further.\n>>>>>>>>\n>>>>>>>> ---\n>>>>>>>>\n>>>>>>>> Thanks\n>>>>>>>>\n>>>>>>>> Pragya jain\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Hi \n>>>>>>>>\n>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>\n>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>> gt; netstat -antulp \n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir,\n>>>>>>>>\n>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Hello,\n>>>>>>>>\n>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>\n>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> Thank you,\n>>>>>>>> Amanda\n>>>>>>>>\n>>>>>>>> SwiftStack Inc.\n>>>>>>>> swiftstack.com\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>> hello sir!\n>>>>>>>>\n>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>> same error is continued.\n>>>>>>>>\n>>>>>>>> ----- Forwarded Message -----\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> hello,\n>>>>>>>>\n>>>>>>>> I have to configure proxy server.\n>>>>>>>> For this,\n>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>\n>>>>>>>> for this, I use the following commands:\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>\n>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>\n>>>>>>>> save and exit.\n>>>>>>>> then, I run the command:\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>\n>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>> for this, I run the following command:\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>> allow_account_management =true\n>>>>>>>> ...\n>>>>>>>> [filter:tempauth]\n>>>>>>>> use = egg:swift#tempauth\n>>>>>>>> ...\n>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>> user_test_tester = testing .admin\n>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>> user_test_tester3 = testing3\n>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>> ...\n>>>>>>>>\n>>>>>>>> save and exit\n>>>>>>>> Then, run following commands:\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>\n>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>> proxy-server already started...\n>>>>>>>>\n>>>>>>>> Please help me in this regard.\n>>>>>>>> ---\n>>>>>>>>\n>>>>>>>> Thanks\n>>>>>>>>\n>>>>>>>> Pragya Jain\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> _______________________________________________\n>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>>-- \n>>>\n>>>Gareth\n>>>\n>>>\n>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>OpenStack contributor\n>>>Company: UnitedStack\n>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130830/af57ed96/attachment.html>\n\n','<CA++_uhvFTX0E=yv5Pi_i+Tk+7b3Ja0B7e=omk5n00=MLPXBeTw@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1377848263.9780.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 15:37:43',28800,'2013-08-30 07:37:43',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\n>this shows problem:\nroot at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n/etc/swift/account.builder, build version 1\n>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>The minimum number of hours before a partition can be reassigned is 24\n>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>port ? ? ?name weight partitions balance meta\n>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>\n>\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>Traceback (most recent call last):\n>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>? ? self.require(requires)[0].run_script(script_name, ns)\n>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>? ? execfile(script_filename, namespace, namespace)\n>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>? ? builder = RingBuilder.load(argv[1])\n>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>cPickle.UnpicklingError: invalid load key, \'\'.\n>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>-su: syntax error near unexpected token `newline\'\n>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>curl: (7) couldn\'t connect to host\n>\n>\n\nPlease help\n\n\n\n>________________________________\n> From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Kuo Hugo <tonytkdk at gmail.com> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 11:52 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>/etc/swift/account.builder, build version 1\n>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>The minimum number of hours before a partition can be reassigned is 24\n>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>/etc/swift/container.builder, build version 1\n>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>The minimum number of hours before a partition can be reassigned is 24\n>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>/etc/swift/object.builder, build version 1\n>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>The minimum number of hours before a partition can be reassigned is 24\n>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>root at arun-Aspire-5742:~# ps aux | grep swift\n>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>root at arun-Aspire-5742:~# df -h\n>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>root at arun-Aspire-5742:~# ls /srv/node/*\n>/srv/node/d1:\n>\n>\n>/srv/node/d2:\n>\n>\n>/srv/node/d3:\n>root at arun-Aspire-5742:~# netstat -antulp\n>Active Internet connections (servers and established)\n>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>ISHED 941/memcached ??\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>root at arun-Aspire-5742:~# swift-init all status\n>No container-updater running\n>No account-auditor running\n>No object-replicator running\n>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>No container-replicator running\n>No object-auditor running\n>No object-expirer running\n>No container-auditor running\n>No container-server running\n>account-server running (5174 - /etc/swift/account-server.conf)\n>No account-reaper running\n>No container-sync running\n>No account-replicator running\n>No object-updater running\n>No object-server running\n>\n>\n>\n>>________________________________\n>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Friday, 30 August 2013 11:23 AM\n>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>> \n>>\n>>\n>>Hi Pragya :?\n>>\n>>\n>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>\n>>\n>>\n>>Check rings :\n>>$> swift-ring-builder /etc/swift/object.builder\n>>>$> swift-ring-builder /etc/swift/container.builder\n>>>$> swift-ring-builder /etc/swift/account.builder\n>>\n>>\n>>Check Swift workers :?\n>>$> swift-init all status\n>>>$> ps aux | grep swift\n>>>$> df -h?\n>>>$> ls /srv/node/*\n>>>$> netstat -antulp\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>+Hugo Kuo+\n>>hugo at swiftstack.com\n>>\n>>tonytkdk at gmail.com\n>>\n>>+886 935004793\n>>\n>>\n>>\n>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>>hello sir,\n>>>\n>>>\n>>>I am working on single node.\n>>>Please let me know how to check network topology and ring structure.\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Gareth <academicgareth at gmail.com>\n>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>Pragya\n>>>>\n>>>>\n>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>\n>>>>\n>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>\n>>>>\n>>>>\n>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>\n>>>>Hi Pragya,?\n>>>>>\n>>>>>\n>>>>>I need more information.?\n>>>>>\n>>>>>\n>>>>>1) Please draw a network topology of your environment\n>>>>>2) How many nodes do you have? ?\n>>>>>3) What\'s the ring looks like ?\n>>>>>\n>>>>>\n>>>>>\n>>>>>Hugo Kuo\n>>>>>hugo at swiftstack.com\n>>>>>\n>>>>>tonytkdk at gmail.com\n>>>>>\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>\n>>>>>hello sir,\n>>>>>>\n>>>>>>\n>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>> Host: localhost:8080\n>>>>>>> Accept: */*\n>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>> X-Auth-Key:pj2648\n>>>>>>>?\n>>>>>>< HTTP/1.1 200 OK\n>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>< Content-Length: 0\n>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>><?\n>>>>>>* Connection #0 to host localhost left intact\n>>>>>>* Closing connection #0\n>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>[GCC 4.6.3] on linux2\n>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>?\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>> Host: localhost:8080\n>>>>>>> Accept: */*\n>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>?\n>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>< Content-Length: 118\n>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>><?\n>>>>>>* Connection #0 to host localhost left intact\n>>>>>>* Closing connection #0\n>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>\n>>>>>>\n>>>>>>Please help me in this regard.\n>>>>>>\n>>>>>>\n>>>>>>---\n>>>>>>\n>>>>>>\n>>>>>>Pragya Jain\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>\n>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>connection is successfully established.\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>+Hugo Kuo+\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>\n>>>>>>>>> user = swift\n>>>>>>>>>\n>>>>>>>>> ________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>\n>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>\n>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> +Hugo Kuo+\n>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>> +886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>> hello sir,\n>>>>>>>>>\n>>>>>>>>> I run the command:\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> ________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>\n>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>\n>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> +Hugo Kuo+\n>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>> +886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>> hello sir\n>>>>>>>>>\n>>>>>>>>> Thanks for the help\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>\n>>>>>>>>> this is the result of the command.\n>>>>>>>>>\n>>>>>>>>> please help in this regard.\n>>>>>>>>>\n>>>>>>>>> -----\n>>>>>>>>> Pragya Jain\n>>>>>>>>>\n>>>>>>>>> ________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>\n>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>\n>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>\n>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>\n>>>>>>>>> What\'s the result ?\n>>>>>>>>>\n>>>>>>>>> +Hugo Kuo+\n>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>> +886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>> hello sir\n>>>>>>>>>\n>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>\n>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>\n>>>>>>>>> and make following changes:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>\n>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>\n>>>>>>>>> and then\n>>>>>>>>>\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>\n>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>> * Closing connection #0\n>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>\n>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>> * Closing connection #0\n>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>\n>>>>>>>>> Please help to proceed further.\n>>>>>>>>>\n>>>>>>>>> ---\n>>>>>>>>>\n>>>>>>>>> Thanks\n>>>>>>>>>\n>>>>>>>>> Pragya jain\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> ________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> Hi \n>>>>>>>>>\n>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>\n>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> +Hugo Kuo+\n>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>> +886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>> hello sir,\n>>>>>>>>>\n>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> ________________________________\n>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> Hello,\n>>>>>>>>>\n>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>\n>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> Thank you,\n>>>>>>>>> Amanda\n>>>>>>>>>\n>>>>>>>>> SwiftStack Inc.\n>>>>>>>>> swiftstack.com\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>> hello sir!\n>>>>>>>>>\n>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>> same error is continued.\n>>>>>>>>>\n>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>\n>>>>>>>>> hello,\n>>>>>>>>>\n>>>>>>>>> I have to configure proxy server.\n>>>>>>>>> For this,\n>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>\n>>>>>>>>> for this, I use the following commands:\n>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>\n>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>\n>>>>>>>>> save and exit.\n>>>>>>>>> then, I run the command:\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>\n>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>> for this, I run the following command:\n>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>\n>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>> allow_account_management =true\n>>>>>>>>> ...\n>>>>>>>>> [filter:tempauth]\n>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>> ...\n>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>> ...\n>>>>>>>>>\n>>>>>>>>> save and exit\n>>>>>>>>> Then, run following commands:\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>> * Closing connection #0\n>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>\n>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>> proxy-server already started...\n>>>>>>>>>\n>>>>>>>>> Please help me in this regard.\n>>>>>>>>> ---\n>>>>>>>>>\n>>>>>>>>> Thanks\n>>>>>>>>>\n>>>>>>>>> Pragya Jain\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>> _______________________________________________\n>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>_______________________________________________\n>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>>-- \n>>>>\n>>>>Gareth\n>>>>\n>>>>\n>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>OpenStack contributor\n>>>>Company: UnitedStack\n>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>\n>>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130830/0400f7ec/attachment.html>\n\n','<1377843725.53401.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1377848357.48550.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 15:39:17',28800,'2013-08-30 07:39:17',NULL,'[Openstack] Fw: Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','\n\n\n\n----- Forwarded Message -----\n>From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Kuo Hugo <tonytkdk at gmail.com> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 1:07 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>hello sir,\n>\n>>this shows problem:\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>\n>>\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>Traceback (most recent call last):\n>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>? ? execfile(script_filename, namespace, namespace)\n>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>? ? builder = RingBuilder.load(argv[1])\n>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>-su: syntax error near unexpected token `newline\'\n>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>curl: (7) couldn\'t connect to host\n>>\n>>\n>\n>\n>Please help\n>\n>\n>\n>>________________________________\n>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Friday, 30 August 2013 11:52 AM\n>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>> \n>>\n>>\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>/etc/swift/container.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>/etc/swift/object.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>root at arun-Aspire-5742:~# df -h\n>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>/srv/node/d1:\n>>\n>>\n>>/srv/node/d2:\n>>\n>>\n>>/srv/node/d3:\n>>root at arun-Aspire-5742:~# netstat -antulp\n>>Active Internet connections (servers and established)\n>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>ISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>root at arun-Aspire-5742:~# swift-init all status\n>>No container-updater running\n>>No account-auditor running\n>>No object-replicator running\n>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>No container-replicator running\n>>No object-auditor running\n>>No object-expirer running\n>>No container-auditor running\n>>No container-server running\n>>account-server running (5174 - /etc/swift/account-server.conf)\n>>No account-reaper running\n>>No container-sync running\n>>No account-replicator running\n>>No object-updater running\n>>No object-server running\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hi Pragya :?\n>>>\n>>>\n>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>\n>>>\n>>>\n>>>Check rings :\n>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>\n>>>\n>>>Check Swift workers :?\n>>>$> swift-init all status\n>>>>$> ps aux | grep swift\n>>>>$> df -h?\n>>>>$> ls /srv/node/*\n>>>>$> netstat -antulp\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I am working on single node.\n>>>>Please let me know how to check network topology and ring structure.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Pragya\n>>>>>\n>>>>>\n>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>\n>>>>>\n>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>\n>>>>>Hi Pragya,?\n>>>>>>\n>>>>>>\n>>>>>>I need more information.?\n>>>>>>\n>>>>>>\n>>>>>>1) Please draw a network topology of your environment\n>>>>>>2) How many nodes do you have? ?\n>>>>>>3) What\'s the ring looks like ?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Hugo Kuo\n>>>>>>hugo at swiftstack.com\n>>>>>>\n>>>>>>tonytkdk at gmail.com\n>>>>>>\n>>>>>>+886 935004793\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>>hello sir,\n>>>>>>>\n>>>>>>>\n>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>Please help me in this regard.\n>>>>>>>\n>>>>>>>\n>>>>>>>---\n>>>>>>>\n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>\n>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>connection is successfully established.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>+886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>\n>>>>>>>>>> user = swift\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>\n>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> I run the command:\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>\n>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the help\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>\n>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>\n>>>>>>>>>> please help in this regard.\n>>>>>>>>>>\n>>>>>>>>>> -----\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>\n>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>\n>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>\n>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> and make following changes:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>\n>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>\n>>>>>>>>>> and then\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>\n>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hi \n>>>>>>>>>>\n>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>\n>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hello,\n>>>>>>>>>>\n>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>\n>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> Thank you,\n>>>>>>>>>> Amanda\n>>>>>>>>>>\n>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>> swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>> hello sir!\n>>>>>>>>>>\n>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>> same error is continued.\n>>>>>>>>>>\n>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> hello,\n>>>>>>>>>>\n>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>> For this,\n>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>\n>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>\n>>>>>>>>>> save and exit.\n>>>>>>>>>> then, I run the command:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>\n>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> allow_account_management =true\n>>>>>>>>>> ...\n>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>> ...\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>> ...\n>>>>>>>>>>\n>>>>>>>>>> save and exit\n>>>>>>>>>> Then, run following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>\n>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>\n>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> _______________________________________________\n>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>-- \n>>>>>\n>>>>>Gareth\n>>>>>\n>>>>>\n>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>OpenStack contributor\n>>>>>Company: UnitedStack\n>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130830/1a41ccec/attachment-0001.html>\n\n','<1377848263.9780.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1377880310-sup-3050@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-30 09:39:39',-25200,'2013-08-30 16:39:39',NULL,'[openstack-dev] [Heat] Instance naming in IG/ASG and problems\n	related to UpdatePolicy','Excerpts from Chan, Winson C\'s message of 2013-08-30 07:23:18 -0700:\n> The ideal I think is to just use some random short id for the name of the instances and then store a creation timestamp somewhere with the resource and use the timestamp to determine the age of the instances for removal.  Thoughts?\n> \n\n+1 for this approach. Simple and straight forward answer to all of the\nproblems spelled out above.\n\nHowever, I do not see this timestamp in the resource table, but in the\nresource_data table. I would suggest adding a created_at column to the\nresource table, as the data table may be misleading.\n\nAs an arbitrary but predictable algorithm, because timestamps can be equal\nfor many many resources, I would also suggest sorting on the resource\nid. This just makes it so that one can predict which instances _should_\nbe removed before a downsize.\n\nSo, I\'d recommend a fully covering index for that query.. created_at, id.\n\n\n','<CE45F8E5.8F3B%winson.c.chan@intel.com>',NULL),('<1377925457.14583.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-31 13:04:17',28800,'2013-08-31 05:04:17',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nI start all services using the command:\n\nroot at arun-Aspire-5742:~# sudo swift-init all start\nStarting container-updater...(/etc/swift/container-server.conf)\nStarting account-auditor...(/etc/swift/account-server.conf)\nStarting object-replicator...(/etc/swift/object-server.conf)\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nStarting container-replicator...(/etc/swift/container-server.conf)\nStarting object-auditor...(/etc/swift/object-server.conf)\nUnable to locate config for object-expirer\nStarting container-auditor...(/etc/swift/container-server.conf)\nStarting container-server...(/etc/swift/container-server.conf)\nStarting account-server...(/etc/swift/account-server.conf)\nStarting account-reaper...(/etc/swift/account-server.conf)\nStarting container-sync...(/etc/swift/container-server.conf)\nStarting account-replicator...(/etc/swift/account-server.conf)\nStarting object-updater...(/etc/swift/object-server.conf)\nStarting object-server...(/etc/swift/object-server.conf)\n\nroot at arun-Aspire-5742:~# sudo apt-get install rsync\nReading package lists... Done\nBuilding dependency tree ? ? ??\nReading state information... Done\nrsync is already the newest version.\n0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\nroot at arun-Aspire-5742:~# vi /etc/default/rsync\n\nset rsync_enable = true\n\nthen,\n\nroot at arun-Aspire-5742:~# service rsync start\n?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n* About to connect() to localhost port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n< Date: Sat, 31 Aug 2013 04:32:36 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n* About to connect() to localhost port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n< Date: Sat, 31 Aug 2013 04:35:26 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 1:15 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hmm....?\n>\n>\n>1) No Container and Object servers are running?\n>2) Only one drive in the ring\n>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>4) Did you setup rsync yet ??\n>\n>\n>Maybe you can follow the online document to complete the above items.?\n>\n>\n>Good luck~\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>/etc/swift/container.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>/etc/swift/object.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>root at arun-Aspire-5742:~# df -h\n>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>/srv/node/d1:\n>>\n>>\n>>/srv/node/d2:\n>>\n>>\n>>/srv/node/d3:\n>>root at arun-Aspire-5742:~# netstat -antulp\n>>Active Internet connections (servers and established)\n>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>ISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>root at arun-Aspire-5742:~# swift-init all status\n>>No container-updater running\n>>No account-auditor running\n>>No object-replicator running\n>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>No container-replicator running\n>>No object-auditor running\n>>No object-expirer running\n>>No container-auditor running\n>>No container-server running\n>>account-server running (5174 - /etc/swift/account-server.conf)\n>>No account-reaper running\n>>No container-sync running\n>>No account-replicator running\n>>No object-updater running\n>>No object-server running\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hi Pragya :?\n>>>\n>>>\n>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>\n>>>\n>>>\n>>>Check rings :\n>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>\n>>>\n>>>Check Swift workers :?\n>>>$> swift-init all status\n>>>>$> ps aux | grep swift\n>>>>$> df -h?\n>>>>$> ls /srv/node/*\n>>>>$> netstat -antulp\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I am working on single node.\n>>>>Please let me know how to check network topology and ring structure.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Pragya\n>>>>>\n>>>>>\n>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>\n>>>>>\n>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>\n>>>>>Hi Pragya,?\n>>>>>>\n>>>>>>\n>>>>>>I need more information.?\n>>>>>>\n>>>>>>\n>>>>>>1) Please draw a network topology of your environment\n>>>>>>2) How many nodes do you have? ?\n>>>>>>3) What\'s the ring looks like ?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Hugo Kuo\n>>>>>>hugo at swiftstack.com\n>>>>>>\n>>>>>>tonytkdk at gmail.com\n>>>>>>\n>>>>>>+886 935004793\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>>hello sir,\n>>>>>>>\n>>>>>>>\n>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>Please help me in this regard.\n>>>>>>>\n>>>>>>>\n>>>>>>>---\n>>>>>>>\n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>\n>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>connection is successfully established.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>+886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>\n>>>>>>>>>> user = swift\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>\n>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> I run the command:\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>\n>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the help\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>\n>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>\n>>>>>>>>>> please help in this regard.\n>>>>>>>>>>\n>>>>>>>>>> -----\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>\n>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>\n>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>\n>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> and make following changes:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>\n>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>\n>>>>>>>>>> and then\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>\n>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hi \n>>>>>>>>>>\n>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>\n>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hello,\n>>>>>>>>>>\n>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>\n>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> Thank you,\n>>>>>>>>>> Amanda\n>>>>>>>>>>\n>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>> swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>> hello sir!\n>>>>>>>>>>\n>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>> same error is continued.\n>>>>>>>>>>\n>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> hello,\n>>>>>>>>>>\n>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>> For this,\n>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>\n>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>\n>>>>>>>>>> save and exit.\n>>>>>>>>>> then, I run the command:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>\n>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> allow_account_management =true\n>>>>>>>>>> ...\n>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>> ...\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>> ...\n>>>>>>>>>>\n>>>>>>>>>> save and exit\n>>>>>>>>>> Then, run following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>\n>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>\n>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> _______________________________________________\n>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>-- \n>>>>>\n>>>>>Gareth\n>>>>>\n>>>>>\n>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>OpenStack contributor\n>>>>>Company: UnitedStack\n>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130831/b697a9e6/attachment.html>\n\n','<CA++_uhsZBr4PK8bveA2A-x1MSxd+eObmm-mCL+mToy3MKK5PXA@mail.gmail.com>',NULL),('<1377934637.10448.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-31 15:37:17',28800,'2013-08-31 07:37:17',NULL,'[Openstack] Fw: problem in creating account in swift','root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n/etc/swift/account.builder, build version 1\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n* About to connect() to 10.0.2.15 port 6000 (#0)\n* ? Trying 10.0.2.15... Connection timed out\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\n/etc/swift/account-server.conf file says:\n\n[DEFAULT]\n# bind_ip = 0.0.0.0\n# bind_port = 6002\n# bind_timeout = 30\n# backlog = 4096\n# user = swift\n# swift_dir = /etc/swift\n# devices = /srv/node\n# mount_check = true\n# disable_fallocate = false\n....\n\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n* About to connect() to 10.0.2.15 port 6002 (#0)\n* ? Trying 10.0.2.15... Connection timed out\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Saturday, 31 August 2013 12:49 PM\n>Subject: Re: Fw: problem in creating account in swift\n> \n>\n>\n>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>\n>By default the account server\'s listen on 6002:\n>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>\n>\n>\n>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>\n>\n>Can you connect to the account server on 6002?\n>\n>\n>Here\'s how you remove/add a server from the ring:\n>http://docs.openstack.org/developer/swift/admin_guide.html\n>\n>\n>\n>\n>\n>\n>\n>\n>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>I run the following commands:\n>>\n>>\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>\n>>\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>* ? Trying 10.0.2.15... Connection timed out\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>\n>>\n>>/etc/swift/account-server.conf file says:\n>>\n>>\n>>[DEFAULT]\n>># bind_ip = 0.0.0.0\n>># bind_port = 6002\n>># bind_timeout = 30\n>># backlog = 4096\n>># user = swift\n>># swift_dir = /etc/swift\n>># devices = /srv/node\n>># mount_check = true\n>># disable_fallocate = false\n>>....\n>>\n>>\n>>I am working on single node.\n>>\n>>\n>>----\n>>\n>>\n>>Pragya Jain\n>>Delhi, India\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>\n>>>Subject: Re: Fw: problem in creating account in swift\n>>> \n>>>\n>>>\n>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>\n>>>\n>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>\n>>>\n>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I start all services using the command:\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>Unable to locate config for object-expirer\n>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>Reading package lists... Done\n>>>>Building dependency tree ? ? ??\n>>>>Reading state information... Done\n>>>>rsync is already the newest version.\n>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>\n>>>>\n>>>>set rsync_enable = true\n>>>>\n>>>>\n>>>>then,\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>* About to connect() to localhost port 80 (#0)\n>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>* About to connect() to localhost port 8080 (#0)\n>>>>* ? Trying 127.0.0.1... connected\n>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>> Host: localhost:8080\n>>>>> Accept: */*\n>>>>> X-Auth-User:prag2648:pragya\n>>>>> X-Auth-key:pj2648\n>>>>>?\n>>>>< HTTP/1.1 200 OK\n>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>< Content-Type: text/html; charset=UTF-8\n>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>< Content-Length: 0\n>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>><?\n>>>>* Connection #0 to host localhost left intact\n>>>>* Closing connection #0\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>* About to connect() to localhost port 80 (#0)\n>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>* About to connect() to localhost port 8080 (#0)\n>>>>* ? Trying 127.0.0.1... connected\n>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>> Host: localhost:8080\n>>>>> Accept: */*\n>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>?\n>>>>< HTTP/1.1 503 Internal Server Error\n>>>>< Content-Length: 118\n>>>>< Content-Type: text/html; charset=UTF-8\n>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>><?\n>>>>* Connection #0 to host localhost left intact\n>>>>* Closing connection #0\n>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>\n>>>>>\n>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>\n>>>>>\n>>>>>^ on the 10.0.2.15 host\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>\n>>>>>>\n>>>>>>----- Forwarded Message -----\n>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>hello sir,\n>>>>>>>\n>>>>>>>\n>>>>>>>this shows problem:\n>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>Traceback (most recent call last):\n>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>\n>>>>>>>\n>>>>>>>Please help\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>and then\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>-Clay\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>>hello sir,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>?\n>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>><?\n>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>?\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>?\n>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>><?\n>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>---\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130831/a7d369e6/attachment.html>\n\n','<CA+_JKzqn_a0iEbDmR+OwqrBLD=n+nv_p4dMzZtT=DtJ8bo0Z3A@mail.gmail.com>',NULL),('<1377936089.10264.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-31 16:01:29',28800,'2013-08-31 08:01:29',NULL,'[Openstack] Fw: problem in creating account in swift','hello sir,\n\nI run the following command:\n\nroot at arun-Aspire-5742:~# sudo netstat -plnt\nActive Internet connections (only servers)\nProto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?948/memcached ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2589/python ? ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:6000 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2613/python ? ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:6001 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2593/python ? ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2594/python ? ??\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?4137/dnsmasq ? ?\ntcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?579/cupsd ? ? ??\ntcp ? ? ? ?0 ? ? ?0 0.0.0.0:873 ? ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2816/rsync ? ? ?\ntcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?579/cupsd ? ? ??\ntcp6 ? ? ? 0 ? ? ?0 :::873 ? ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?2816/rsync ? ? ?\n\nroot at arun-Aspire-5742:~#?cat /var/log/syslog\npaste the result on?http://paste.openstack.org/\nPaste #45522\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Saturday, 31 August 2013 1:15 PM\n>Subject: Re: Fw: problem in creating account in swift\n> \n>\n>\n>so what port is it listening on?\n>\n>\n>`sudo netstat -plnt`\n>\n>\n>\n>The logs man... the logs. ?`cat /var/log/syslog` copy the whole thing in?http://paste.openstack.org/ if you have to.\n>\n>\n>\n>\n>\n>\n>\n>On Sat, Aug 31, 2013 at 12:37 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>\n>>\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>* ? Trying 10.0.2.15... Connection timed out\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>\n>>\n>>/etc/swift/account-server.conf file says:\n>>\n>>\n>>[DEFAULT]\n>># bind_ip = 0.0.0.0\n>># bind_port = 6002\n>># bind_timeout = 30\n>># backlog = 4096\n>># user = swift\n>># swift_dir = /etc/swift\n>># devices = /srv/node\n>># mount_check = true\n>># disable_fallocate = false\n>>....\n>>\n>>\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n>>* About to connect() to 10.0.2.15 port 6002 (#0)\n>>* ? Trying 10.0.2.15... Connection timed out\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Sent: Saturday, 31 August 2013 12:49 PM\n>>>\n>>>Subject: Re: Fw: problem in creating account in swift\n>>> \n>>>\n>>>\n>>>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>>>\n>>>By default the account server\'s listen on 6002:\n>>>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>>>\n>>>\n>>>\n>>>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>>>\n>>>\n>>>Can you connect to the account server on 6002?\n>>>\n>>>\n>>>Here\'s how you remove/add a server from the ring:\n>>>http://docs.openstack.org/developer/swift/admin_guide.html\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I run the following commands:\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>/etc/swift/account.builder, build version 1\n>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>* couldn\'t connect to host\n>>>>* Closing connection #0\n>>>>curl: (7) couldn\'t connect to host\n>>>>\n>>>>\n>>>>/etc/swift/account-server.conf file says:\n>>>>\n>>>>\n>>>>[DEFAULT]\n>>>># bind_ip = 0.0.0.0\n>>>># bind_port = 6002\n>>>># bind_timeout = 30\n>>>># backlog = 4096\n>>>># user = swift\n>>>># swift_dir = /etc/swift\n>>>># devices = /srv/node\n>>>># mount_check = true\n>>>># disable_fallocate = false\n>>>>....\n>>>>\n>>>>\n>>>>I am working on single node.\n>>>>\n>>>>\n>>>>----\n>>>>\n>>>>\n>>>>Pragya Jain\n>>>>Delhi, India\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>>>\n>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>>>\n>>>>>\n>>>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>>>\n>>>>>\n>>>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>hello sir,\n>>>>>>\n>>>>>>\n>>>>>>I start all services using the command:\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>>>Unable to locate config for object-expirer\n>>>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>>>Reading package lists... Done\n>>>>>>Building dependency tree ? ? ??\n>>>>>>Reading state information... Done\n>>>>>>rsync is already the newest version.\n>>>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>>>\n>>>>>>\n>>>>>>set rsync_enable = true\n>>>>>>\n>>>>>>\n>>>>>>then,\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>> Host: localhost:8080\n>>>>>>> Accept: */*\n>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>> X-Auth-key:pj2648\n>>>>>>>?\n>>>>>>< HTTP/1.1 200 OK\n>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>< Content-Length: 0\n>>>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>>>><?\n>>>>>>* Connection #0 to host localhost left intact\n>>>>>>* Closing connection #0\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>> Host: localhost:8080\n>>>>>>> Accept: */*\n>>>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>?\n>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>< Content-Length: 118\n>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>>>><?\n>>>>>>* Connection #0 to host localhost left intact\n>>>>>>* Closing connection #0\n>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>>>\n>>>>>>>\n>>>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>>>\n>>>>>>>\n>>>>>>>^ on the 10.0.2.15 host\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>\n>>>>>>>\n>>>>>>>>\n>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>hello sir,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>this shows problem:\n>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>Traceback (most recent call last):\n>>>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Please help\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>and then\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>-Clay\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>><?\n>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>><?\n>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>---\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130831/d635f855/attachment.html>\n\n','<CA+_JKzqwxQp473VceUmCn=A29xgRYGy8gro2wuFXsDVjgV75Hg@mail.gmail.com>',NULL),('<1377944314.18624.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-31 18:18:34',28800,'2013-08-31 10:18:34',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002\n> Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\nit shows a bad request error in retrieving the content of account\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 11:23 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hi Pragya :?\n>\n>\n>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>\n>\n>\n>Check rings :\n>$> swift-ring-builder /etc/swift/object.builder\n>>$> swift-ring-builder /etc/swift/container.builder\n>>$> swift-ring-builder /etc/swift/account.builder\n>\n>\n>Check Swift workers :?\n>$> swift-init all status\n>>$> ps aux | grep swift\n>>$> df -h?\n>>$> ls /srv/node/*\n>>$> netstat -antulp\n>\n>\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>\n>hello sir,\n>>\n>>\n>>I am working on single node.\n>>Please let me know how to check network topology and ring structure.\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Gareth <academicgareth at gmail.com>\n>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Pragya\n>>>\n>>>\n>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>\n>>>\n>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>\n>>>\n>>>\n>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>\n>>>Hi Pragya,?\n>>>>\n>>>>\n>>>>I need more information.?\n>>>>\n>>>>\n>>>>1) Please draw a network topology of your environment\n>>>>2) How many nodes do you have? ?\n>>>>3) What\'s the ring looks like ?\n>>>>\n>>>>\n>>>>\n>>>>Hugo Kuo\n>>>>hugo at swiftstack.com\n>>>>\n>>>>tonytkdk at gmail.com\n>>>>\n>>>>+886 935004793\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>hello sir,\n>>>>>\n>>>>>\n>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Auth-User:prag2648:pragya\n>>>>>> X-Auth-Key:pj2648\n>>>>>>?\n>>>>>< HTTP/1.1 200 OK\n>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>< Content-Length: 0\n>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>>root at arun-Aspire-5742:~# python\n>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>[GCC 4.6.3] on linux2\n>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>?\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>* couldn\'t connect to host\n>>>>>* Closing connection #0\n>>>>>curl: (7) couldn\'t connect to host\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>?\n>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>< Content-Length: 118\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>\n>>>>>\n>>>>>Please help me in this regard.\n>>>>>\n>>>>>\n>>>>>---\n>>>>>\n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>>________________________________\n>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>\n>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>Thanks Kuo very much for this help.\n>>>>>>connection is successfully established.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>\n>>>>>>>\n>>>>>>>+Hugo Kuo+\n>>>>>>>hugo at swiftstack.com\n>>>>>>>tonytkdk at gmail.com\n>>>>>>>+886 935004793\n>>>>>>>\n>>>>>>>\n>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>\n>>>>>>>> user = swift\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>\n>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir,\n>>>>>>>>\n>>>>>>>> I run the command:\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>> Traceback (most recent call last):\n>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>\n>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir\n>>>>>>>>\n>>>>>>>> Thanks for the help\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>\n>>>>>>>> this is the result of the command.\n>>>>>>>>\n>>>>>>>> please help in this regard.\n>>>>>>>>\n>>>>>>>> -----\n>>>>>>>> Pragya Jain\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>\n>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>\n>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> What\'s the result ?\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir\n>>>>>>>>\n>>>>>>>> Thanks for the suggestion.\n>>>>>>>>\n>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> and make following changes:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>> user_test_tester = testing .admin\n>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>\n>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>\n>>>>>>>> and then\n>>>>>>>>\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>\n>>>>>>>> Please help to proceed further.\n>>>>>>>>\n>>>>>>>> ---\n>>>>>>>>\n>>>>>>>> Thanks\n>>>>>>>>\n>>>>>>>> Pragya jain\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Hi \n>>>>>>>>\n>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>\n>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>> gt; netstat -antulp \n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> +Hugo Kuo+\n>>>>>>>> hugo at swiftstack.com\n>>>>>>>> tonytkdk at gmail.com\n>>>>>>>> +886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>> hello sir,\n>>>>>>>>\n>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> ________________________________\n>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> Hello,\n>>>>>>>>\n>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>\n>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> Thank you,\n>>>>>>>> Amanda\n>>>>>>>>\n>>>>>>>> SwiftStack Inc.\n>>>>>>>> swiftstack.com\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>> hello sir!\n>>>>>>>>\n>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>> same error is continued.\n>>>>>>>>\n>>>>>>>> ----- Forwarded Message -----\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>\n>>>>>>>> hello,\n>>>>>>>>\n>>>>>>>> I have to configure proxy server.\n>>>>>>>> For this,\n>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>\n>>>>>>>> for this, I use the following commands:\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>\n>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>\n>>>>>>>> save and exit.\n>>>>>>>> then, I run the command:\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>\n>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>> for this, I run the following command:\n>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>\n>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>> allow_account_management =true\n>>>>>>>> ...\n>>>>>>>> [filter:tempauth]\n>>>>>>>> use = egg:swift#tempauth\n>>>>>>>> ...\n>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>> user_test_tester = testing .admin\n>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>> user_test_tester3 = testing3\n>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>> ...\n>>>>>>>>\n>>>>>>>> save and exit\n>>>>>>>> Then, run following commands:\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>> * couldn\'t connect to host\n>>>>>>>> * Closing connection #0\n>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>\n>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>> proxy-server already started...\n>>>>>>>>\n>>>>>>>> Please help me in this regard.\n>>>>>>>> ---\n>>>>>>>>\n>>>>>>>> Thanks\n>>>>>>>>\n>>>>>>>> Pragya Jain\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>> _______________________________________________\n>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>>-- \n>>>\n>>>Gareth\n>>>\n>>>\n>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>OpenStack contributor\n>>>Company: UnitedStack\n>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130831/e638af8f/attachment-0001.html>\n\n','<CA++_uhvFTX0E=yv5Pi_i+Tk+7b3Ja0B7e=omk5n00=MLPXBeTw@mail.gmail.com>',NULL),('<1378017133.20549.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-01 14:32:13',28800,'2013-09-01 06:32:13',NULL,'[Openstack] Fw: problem in creating account in swift','hello sir,\n\nI did the following job:\n\narun at arun-Aspire-5742:~$ su -\nPassword:?\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n< Content-Length: 0\n< X-Trans-Id: tx8f658e6bd3b244b793815-005222de45\n< Date: Sun, 01 Sep 2013 06:27:17 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: tx1c1cb6e3a9f64b56a9550-005222dea4\n< Date: Sun, 01 Sep 2013 06:28:54 GMT\n<?\n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txa4c98c518382430ab9f5f-005222dede\n< Date: Sun, 01 Sep 2013 06:29:51 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~#?\n\nBut it again shows internal server error.\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Saturday, 31 August 2013 7:38 PM\n>Subject: Re: Fw: problem in creating account in swift\n> \n>\n>\n>I was only just connecting to the account directly (127.0.0.1:6002) to prove a point - normally clients would always only talk to the proxy (127.0.0.1:8080).\n>\n>curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>\n>... should work?\n>\n>\n>\n>On Sat, Aug 31, 2013 at 3:17 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/ * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002 > Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n>>it shows a bad request error in retrieving the content of account\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Sent: Saturday, 31 August 2013 1:42 PM\n>>>\n>>>Subject: Re: Fw: problem in creating account in swift\n>>> \n>>>\n>>>\n>>>so that was only a couple of minutes of logs and it was ll the boring info lines from the background daemons. ?Let\'s stop those while we troubeshoot:\n>>>\n>>>\n>>>`swift-init rest stop`\n>>>\n>>>\n>>>\n>>>the listening servers show there\'s something listening on all interfaces on 6002. ?It doesn\'t make sense that you wouldn\'t be able to connect to it? ?Maybe this machine isn\'t really 10.0.2.15? ?Can you ping it? ?Maybe there\'s a weird route? ?Try localhost:\n>>>\n>>>\n>>>`curl http://localhost:6002`\n>>>\n>>>\n>>>can you /msg clayg on Freenode so we can chat realtime?\n>>>\n>>>\n>>>\n>>>On Sat, Aug 31, 2013 at 1:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I run the following command:\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo netstat -plnt\n>>>>Active Internet connections (only servers)\n>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?948/memcached ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2589/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6000 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2613/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6001 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2593/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2594/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?4137/dnsmasq ? ?\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?579/cupsd ? ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:873 ? ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2816/rsync ? ? ?\n>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?579/cupsd ? ? ??\n>>>>tcp6 ? ? ? 0 ? ? ?0 :::873 ? ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?2816/rsync ? ? ?\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~#?cat /var/log/syslog\n>>>>paste the result on?http://paste.openstack.org/\n>>>>Paste #45522\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Sent: Saturday, 31 August 2013 1:15 PM\n>>>>>\n>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>so what port is it listening on?\n>>>>>\n>>>>>\n>>>>>`sudo netstat -plnt`\n>>>>>\n>>>>>\n>>>>>\n>>>>>The logs man... the logs. ?`cat /var/log/syslog` copy the whole thing in?http://paste.openstack.org/ if you have to.\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Sat, Aug 31, 2013 at 12:37 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>>\n>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>\n>>>>>>\n>>>>>>[DEFAULT]\n>>>>>># bind_ip = 0.0.0.0\n>>>>>># bind_port = 6002\n>>>>>># bind_timeout = 30\n>>>>>># backlog = 4096\n>>>>>># user = swift\n>>>>>># swift_dir = /etc/swift\n>>>>>># devices = /srv/node\n>>>>>># mount_check = true\n>>>>>># disable_fallocate = false\n>>>>>>....\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n>>>>>>* About to connect() to 10.0.2.15 port 6002 (#0)\n>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>* couldn\'t connect to host\n>>>>>>* Closing connection #0\n>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Sent: Saturday, 31 August 2013 12:49 PM\n>>>>>>>\n>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>>>>>>>\n>>>>>>>By default the account server\'s listen on 6002:\n>>>>>>>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>>>>>>>\n>>>>>>>\n>>>>>>>Can you connect to the account server on 6002?\n>>>>>>>\n>>>>>>>\n>>>>>>>Here\'s how you remove/add a server from the ring:\n>>>>>>>http://docs.openstack.org/developer/swift/admin_guide.html\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>\n>>>>>>>hello sir,\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>I run the following commands:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>* couldn\'t connect to host\n>>>>>>>>* Closing connection #0\n>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>[DEFAULT]\n>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>># bind_port = 6002\n>>>>>>>># bind_timeout = 30\n>>>>>>>># backlog = 4096\n>>>>>>>># user = swift\n>>>>>>>># swift_dir = /etc/swift\n>>>>>>>># devices = /srv/node\n>>>>>>>># mount_check = true\n>>>>>>>># disable_fallocate = false\n>>>>>>>>....\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>I am working on single node.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>----\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Pragya Jain\n>>>>>>>>Delhi, India\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>>>>>>>\n>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>>hello sir,\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I start all services using the command:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>>>>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>>>>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>>>>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>>>>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>>>>>>>Unable to locate config for object-expirer\n>>>>>>>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>>>>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>>>>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>>>>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>>>>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>>>>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>>>>>>>Reading package lists... Done\n>>>>>>>>>>Building dependency tree ? ? ??\n>>>>>>>>>>Reading state information... Done\n>>>>>>>>>>rsync is already the newest version.\n>>>>>>>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>set rsync_enable = true\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>then,\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>>>>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>> X-Auth-key:pj2648\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>^ on the 10.0.2.15 host\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>this shows problem:\n>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>Traceback (most recent call last):\n>>>>>>>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Please help\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>and then\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>-Clay\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130901/30924fb5/attachment.html>\n\n','<CA+_JKzqTQX3fR+Pvp_NLy46RSbkLy4+yjnGkjh6cGXkiodRgOw@mail.gmail.com>',NULL),('<1378026974.41892.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-01 17:16:14',28800,'2013-09-01 09:16:14',NULL,'[Openstack] Fw: problem in creating account in swift','\n\nhello,\n\nplease help me in this regard.\n\n\n\n>________________________________\n> From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Clay Gerrard <clay.gerrard at gmail.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Sunday, 1 September 2013 12:02 PM\n>Subject: Re: [Openstack] Fw: problem in creating account in swift\n> \n>\n>\n>hello sir,\n>\n>\n>I did the following job:\n>\n>\n>arun at arun-Aspire-5742:~$ su -\n>Password:?\n>root at arun-Aspire-5742:~# sudo swift-init account start\n>Starting account-server...(/etc/swift/account-server.conf)\n>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>* About to connect() to localhost port 8080 (#0)\n>* ? Trying 127.0.0.1... connected\n>> GET /auth/v1.0/ HTTP/1.1\n>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>> Host: localhost:8080\n>> Accept: */*\n>> X-Auth-User:prag2648:pragya\n>> X-Auth-Key:pj2648\n>>?\n>< HTTP/1.1 200 OK\n>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>< X-Auth-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>< Content-Type: text/html; charset=UTF-8\n>< X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>< Content-Length: 0\n>< X-Trans-Id: tx8f658e6bd3b244b793815-005222de45\n>< Date: Sun, 01 Sep 2013 06:27:17 GMT\n><?\n>* Connection #0 to host localhost left intact\n>* Closing connection #0\n>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>* About to connect() to 127.0.0.1 port 8080 (#0)\n>* ? Trying 127.0.0.1... connected\n>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>> Host: 127.0.0.1:8080\n>> Accept: */*\n>> X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>?\n>< HTTP/1.1 503 Internal Server Error\n>< Content-Length: 118\n>< Content-Type: text/html; charset=UTF-8\n>< X-Trans-Id: tx1c1cb6e3a9f64b56a9550-005222dea4\n>< Date: Sun, 01 Sep 2013 06:28:54 GMT\n><?\n>* Connection #0 to host 127.0.0.1 left intact\n>* Closing connection #0\n><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://localhost:8080/v1/AUTH_prag2648/\n>* About to connect() to localhost port 8080 (#0)\n>* ? Trying 127.0.0.1... connected\n>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>> Host: localhost:8080\n>> Accept: */*\n>> X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>?\n>< HTTP/1.1 503 Internal Server Error\n>< Content-Length: 118\n>< Content-Type: text/html; charset=UTF-8\n>< X-Trans-Id: txa4c98c518382430ab9f5f-005222dede\n>< Date: Sun, 01 Sep 2013 06:29:51 GMT\n><?\n>* Connection #0 to host localhost left intact\n>* Closing connection #0\n><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>root at arun-Aspire-5742:~#?\n>\n>\n>But it again shows internal server error.\n>\n>\n>\n>>________________________________\n>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>Sent: Saturday, 31 August 2013 7:38 PM\n>>Subject: Re: Fw: problem in creating account in swift\n>> \n>>\n>>\n>>I was only just connecting to the account directly (127.0.0.1:6002) to prove a point - normally clients would always only talk to the proxy (127.0.0.1:8080).\n>>\n>>curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>\n>>... should work?\n>>\n>>\n>>\n>>On Sat, Aug 31, 2013 at 3:17 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/ * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002 > Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n>>>it shows a bad request error in retrieving the content of account\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>Sent: Saturday, 31 August 2013 1:42 PM\n>>>>\n>>>>Subject: Re: Fw: problem in creating account in swift\n>>>> \n>>>>\n>>>>\n>>>>so that was only a couple of minutes of logs and it was ll the boring info lines from the background daemons. ?Let\'s stop those while we troubeshoot:\n>>>>\n>>>>\n>>>>`swift-init rest stop`\n>>>>\n>>>>\n>>>>\n>>>>the listening servers show there\'s something listening on all interfaces on 6002. ?It doesn\'t make sense that you wouldn\'t be able to connect to it? ?Maybe this machine isn\'t really 10.0.2.15? ?Can you ping it? ?Maybe there\'s a weird route? ?Try localhost:\n>>>>\n>>>>\n>>>>`curl http://localhost:6002`\n>>>>\n>>>>\n>>>>can you /msg clayg on Freenode so we can chat realtime?\n>>>>\n>>>>\n>>>>\n>>>>On Sat, Aug 31, 2013 at 1:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>hello sir,\n>>>>>\n>>>>>\n>>>>>I run the following command:\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# sudo netstat -plnt\n>>>>>Active Internet connections (only servers)\n>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?948/memcached ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2589/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6000 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2613/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6001 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2593/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2594/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?4137/dnsmasq ? ?\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:873 ? ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>tcp6 ? ? ? 0 ? ? ?0 :::873 ? ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~#?cat /var/log/syslog\n>>>>>paste the result on?http://paste.openstack.org/\n>>>>>Paste #45522\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Sent: Saturday, 31 August 2013 1:15 PM\n>>>>>>\n>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>so what port is it listening on?\n>>>>>>\n>>>>>>\n>>>>>>`sudo netstat -plnt`\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>The logs man... the logs. ?`cat /var/log/syslog` copy the whole thing in?http://paste.openstack.org/ if you have to.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Sat, Aug 31, 2013 at 12:37 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>\n>>>>>>>\n>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>\n>>>>>>>\n>>>>>>>[DEFAULT]\n>>>>>>># bind_ip = 0.0.0.0\n>>>>>>># bind_port = 6002\n>>>>>>># bind_timeout = 30\n>>>>>>># backlog = 4096\n>>>>>>># user = swift\n>>>>>>># swift_dir = /etc/swift\n>>>>>>># devices = /srv/node\n>>>>>>># mount_check = true\n>>>>>>># disable_fallocate = false\n>>>>>>>....\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 10.0.2.15 port 6002 (#0)\n>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Sent: Saturday, 31 August 2013 12:49 PM\n>>>>>>>>\n>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>>>>>>>>\n>>>>>>>>By default the account server\'s listen on 6002:\n>>>>>>>>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Can you connect to the account server on 6002?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Here\'s how you remove/add a server from the ring:\n>>>>>>>>http://docs.openstack.org/developer/swift/admin_guide.html\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>>hello sir,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I run the following commands:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>[DEFAULT]\n>>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>>># bind_port = 6002\n>>>>>>>>># bind_timeout = 30\n>>>>>>>>># backlog = 4096\n>>>>>>>>># user = swift\n>>>>>>>>># swift_dir = /etc/swift\n>>>>>>>>># devices = /srv/node\n>>>>>>>>># mount_check = true\n>>>>>>>>># disable_fallocate = false\n>>>>>>>>>....\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I am working on single node.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>----\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Pragya Jain\n>>>>>>>>>Delhi, India\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I start all services using the command:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>>>>>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>>>>>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>>>>>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>>>>>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>>>>>>>>Unable to locate config for object-expirer\n>>>>>>>>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>>>>>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>>>>>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>>>>>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>>>>>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>>>>>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>>>>>>>>Reading package lists... Done\n>>>>>>>>>>>Building dependency tree ? ? ??\n>>>>>>>>>>>Reading state information... Done\n>>>>>>>>>>>rsync is already the newest version.\n>>>>>>>>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>set rsync_enable = true\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>then,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>>>>>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>> X-Auth-key:pj2648\n>>>>>>>>>>>>?\n>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>>>>>>>>><?\n>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>?\n>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>>>>>>>>><?\n>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>^ on the 10.0.2.15 host\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>this shows problem:\n>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>Traceback (most recent call last):\n>>>>>>>>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Please help\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>and then\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>-Clay\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130901/c6663773/attachment.html>\n\n','<1378017133.20549.YahooMailNeo@web193603.mail.sg3.yahoo.com>',NULL),('<1378027684.37580.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-01 17:28:04',28800,'2013-09-01 09:28:04',NULL,'[Openstack] problem in retrieving the account data','root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/ * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002 > Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\nit shows a bad request error in retrieving the content of account\nthen, I did thefolowing job:\n\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n< Content-Length: 0\n< X-Trans-Id: tx8f658e6bd3b244b793815-005222de45\n< Date: Sun, 01 Sep 2013 06:27:17 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: tx1c1cb6e3a9f64b56a9550-005222dea4\n< Date: Sun, 01 Sep 2013 06:28:54 GMT\n<?\n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txa4c98c518382430ab9f5f-005222dede\n< Date: Sun, 01 Sep 2013 06:29:51 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~#?\n\nBut it again shows internal server error.\n---\n\nPlease help me in this regard.\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130901/6d95189e/attachment.html>\n\n',NULL,NULL),('<1378111281.3136.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-02 16:41:21',28800,'2013-09-02 08:41:21',NULL,'[openstack-dev] Adding a new column to a table.','Hi,\n\nI have been trying to add a new column to compute_nodes table.\nI understand the table is defined at db.sqlalchemy.models.py. So,\nI added a new field in the file and restarted the nova-compute process.\nBut, there is no change in the table. What am I doing wrong? Where?\nshould I make changes to add the column?\n\nP.S: I am using devstack on Ubuntu 12.04 LTS\n\nThanks,\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130902/a9ca2281/attachment.html>\n\n',NULL,NULL),('<1378112469.18962.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-02 17:01:09',28800,'2013-09-02 09:01:09',NULL,'[Openstack] Adding a new column to a table.','\n\nHi,\n\nI have been trying to add a new column to compute_nodes table.\nI understand the table is defined at db.sqlalchemy.models.py. So,\nI added a new field in the file and restarted the nova-compute process.\nBut, there is no change in the table. What am I doing wrong? Where?\nshould I make changes to add the column?\n\nP.S: I am using devstack on Ubuntu 12.04 LTS\n\nThanks,\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130902/72ee83ed/attachment.html>\n\n','<1378111281.3136.YahooMailNeo@web194605.mail.sg3.yahoo.com>',NULL),('<1378131670.96925.YahooMailNeo@web172405.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-09-02 15:21:10',3600,'2013-09-02 14:21:10',NULL,'[Openstack-operators] Quantum Security Groups not working -\n	iptables rules are not Evaluated','\nit is not working because you are using the ovs bridge compatibility module.\n\nRe, \nDarragh.\n\n>________________________________\n> From: Sebastian Porombka <porombka at uni-paderborn.de>\n>To: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Monday, 2 September 2013, 14:48\n>Subject: [Openstack-operators] Quantum Security Groups not working - iptables rules are not Evaluated\n> \n>\n>\n>Hi folks.\n>\n>\n>We\'re currently on the way to deploy an openstack (grizzly) cloud environment?\n>and suffering in problems implementing the security groups like described in [1].\n>\n>\n>The (hopefully) relevant configuration settings are:\n>\n>\n>/etc/nova/nova.conf\n>[?]\n>security_group_api=quantum\n>network_api_class=nova.network.quantumv2.api.API\n>libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver\n>firewall_driver=nova.virt.firewall.NoopFirewallDriver\n>[?]\n>\n>\n>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\n>[?]\n>firewall_driver = quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n>[?]\n>\n>\n>The Networks for the vm\'s are attached to the compute-nodes via VLAN?\n>encapsulation and correctly mapped to the vm\'s.\n>\n>\n>From our point of view - we\'re understanding the need of the?\n>\"ovs-bridge <> veth glue <> linux-bridge (for filtering) <> vm\"-construction?\n>and observed the single components in our deployment. See [2]\n>\n>\n>Everything is working except the security groups.?\n>We observed that ip-tables rules are generated for the?quantum-openvswi-* chains of iptables.?\n>And the traffic arriving untagged (native vlan for management) on the machine is processed by iptables but not?\n>the traffic which arrived encapsulated.\n>\n>\n>The traffic which is unpacked by openvswitch and is bridged via the veth and the tap into?\n>the machine isn\'t processed by the iptables rules.\n>\n>\n>We have no remaining clue/idea how to solve this issue? :(\n>\n>\n>Greetings\n>? ?Sebastian\n>\n>\n>[1]?http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html\n>[2]?http://pastebin.com/WXMH6y4A\n>\n>\n>--\n>Sebastian Porombka,?M.Sc.?\n>Zentrum f?r Informations- und Medientechnologien (IMT)\n>Universit?t Paderborn\n>\n>\n>E-Mail:?porombka at uni-paderborn.de\n>Tel.: 05251/60-5999\n>Fax:?05251/60-48-5999\n>Raum: N5.314?\n>\n>\n>--------------------------------------------\n>Q: Why is this email five sentences or less?\n>A:?http://five.sentenc.es\n>\n>\n>Please consider the environment before printing this email.\n>_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n>\n\n\n','<CE4A6242.49182%porombka@uni-paderborn.de>',NULL),('<1378135717.92851.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-09-02 16:28:37',3600,'2013-09-02 15:28:37',NULL,'[Openstack-operators] Quantum Security Groups not working -\n	iptables rules are not Evaluated','Hi Lorin,\n\nsure, sorry for the beverity. It seems the brcompat is being used because qbr0188455b-25 appears in the \'ovs-vsctl show\' output - so it was created as an OVS bridge, but it should have been created as a Linux bridge. I have never used brcompat, but I believe it intercepts calls from brctl and configures OVS bridges instead of Linux bridges. I\'m not sure how to uninstall/disable it - it\'s probably an Operating System package.\n\nI don\'t think any Openstack doc says to install/enable it.\n\nRe,\nDarragh.\n\n>________________________________\n> From: Lorin Hochstein <lorin at nimbisservices.com>\n>To: Darragh O\'Reilly <dara2002-openstack at yahoo.com> \n>Cc: Sebastian Porombka <porombka at uni-paderborn.de>; \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Monday, 2 September 2013, 16:00\n>Subject: Re: [Openstack-operators] Quantum Security Groups not working - iptables rules are not Evaluated\n> \n>\n>\n>Darragh:\n>\n>\n>Can you elaborate on this a little more? Do you mean that the \"brcompat\" kernel module has been loaded, and this breaks security groups with the ovs plugin? Should we add something in the documentation about this??\n>\n>\n>Lorin\n>\n>\n>\n>\n>Do you mean that the problem is that the ovs-brcompatd service is running??\n>\n>\n>openvswitch-brcompat package is installed??\n>\n>\n>\n>On Mon, Sep 2, 2013 at 10:21 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>\n>>it is not working because you are using the ovs bridge compatibility module.\n>>\n>>Re,\n>>Darragh.\n>>\n>>>________________________________\n>>> From: Sebastian Porombka <porombka at uni-paderborn.de>\n>>>To: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org>\n>>>Sent: Monday, 2 September 2013, 14:48\n>>>Subject: [Openstack-operators] Quantum Security Groups not working - iptables rules are not Evaluated\n>>\n>>>\n>>>\n>>>\n>>>Hi folks.\n>>>\n>>>\n>>>We\'re currently on the way to deploy an openstack (grizzly) cloud environment?\n>>>and suffering in problems implementing the security groups like described in [1].\n>>>\n>>>\n>>>The (hopefully) relevant configuration settings are:\n>>>\n>>>\n>>>/etc/nova/nova.conf\n>>>[?]\n>>>security_group_api=quantum\n>>>network_api_class=nova.network.quantumv2.api.API\n>>>libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver\n>>>firewall_driver=nova.virt.firewall.NoopFirewallDriver\n>>>[?]\n>>>\n>>>\n>>>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\n>>>[?]\n>>>firewall_driver = quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n>>>[?]\n>>>\n>>>\n>>>The Networks for the vm\'s are attached to the compute-nodes via VLAN?\n>>>encapsulation and correctly mapped to the vm\'s.\n>>>\n>>>\n>>>From our point of view - we\'re understanding the need of the?\n>>>\"ovs-bridge <> veth glue <> linux-bridge (for filtering) <> vm\"-construction?\n>>>and observed the single components in our deployment. See [2]\n>>>\n>>>\n>>>Everything is working except the security groups.?\n>>>We observed that ip-tables rules are generated for the?quantum-openvswi-* chains of iptables.?\n>>>And the traffic arriving untagged (native vlan for management) on the machine is processed by iptables but not?\n>>>the traffic which arrived encapsulated.\n>>>\n>>>\n>>>The traffic which is unpacked by openvswitch and is bridged via the veth and the tap into?\n>>>the machine isn\'t processed by the iptables rules.\n>>>\n>>>\n>>>We have no remaining clue/idea how to solve this issue? :(\n>>>\n>>>\n>>>Greetings\n>>>? ?Sebastian\n>>>\n>>>\n>>>[1]?http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html\n>>>[2]?http://pastebin.com/WXMH6y4A\n>>>\n>>>\n>>>--\n>>>Sebastian Porombka,?M.Sc.?\n>>>Zentrum f?r Informations- und Medientechnologien (IMT)\n>>>Universit?t Paderborn\n>>>\n>>>\n>>>E-Mail:?porombka at uni-paderborn.de\n>>>Tel.: 05251/60-5999\n>>>Fax:?05251/60-48-5999\n>>>Raum: N5.314?\n>>>\n>>>\n>>>--------------------------------------------\n>>>Q: Why is this email five sentences or less?\n>>>A:?http://five.sentenc.es\n>>>\n>>>\n>>>Please consider the environment before printing this email.\n>>>_______________________________________________\n>>>OpenStack-operators mailing list\n>>>OpenStack-operators at lists.openstack.org\n>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>\n>>>\n>>>\n>>\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>\n>\n>\n>-- \n>\n>Lorin Hochstein\n>\n>Lead Architect - Cloud Services\n>Nimbis Services, Inc.\n>www.nimbisservices.com\n>\n>\n\n\n','<CADzpNMXaPHQCdgjCwOJDK-fC4E6KF14K_gvr5AHnwknEwH4N8w@mail.gmail.com>',NULL),('<1378185194.47042.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-02 22:13:14',-25200,'2013-09-03 05:13:14',NULL,'[Openstack] Ironic release date?','Hi all,\n\nI have been unable to get the nova baremetal driver to work to save my life,\nso I was wondering when Ironic is expected to be released?\n\nThis year, next year sometime?\n\nThanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130902/fb5fd648/attachment.html>\n\n',NULL,NULL),('<1378192902.4661.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-03 15:21:42',28800,'2013-09-03 07:21:42',NULL,'[Openstack] Fw: problem in creating account in swift','root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogSep ?1 11:59:51 arun-Aspire-5742 proxy-server ERROR with Account server 10.0.2.15:6000/d1 re: Trying to GET /v1/AUTH_prag2648/: ConnectionTimeout (0.5s) (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\nSep ?1 11:59:51 arun-Aspire-5742 proxy-server ERROR with Account server 10.0.2.15:6002/d1 re: Trying to GET /v1/AUTH_prag2648/: ConnectionTimeout (0.5s) (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\nSep ?1 11:59:51 arun-Aspire-5742 proxy-server Account GET returning 503 for [] (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\nSep ?1 11:59:51 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 01/Sep/2013/06/29/51 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk9867f9725a1246a1af3e30b9f7161eb5 - 118 - txa4c98c518382430ab9f5f-005222dede - 1.2649 - -\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Sunday, 1 September 2013 10:36 PM\n>Subject: Re: Fw: problem in creating account in swift\n> \n>\n>\n>Still looks like a connection error to me, I think we\'ve established the account server is running on 127.0.0.1:6002 - so is that\'s what\'s in the ring after all?\n>\n>you could also `grep txa4c98c518382430ab9f5f-005222dede /var/log/syslog` and see what error the proxy was getting.\n>\n>-Clay \n>\n>\n>\n>-\n>\n>\n>\n>On Sat, Aug 31, 2013 at 11:32 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>I did the following job:\n>>\n>>\n>>arun at arun-Aspire-5742:~$ su -\n>>Password:?\n>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>Starting account-server...(/etc/swift/account-server.conf)\n>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /auth/v1.0/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Auth-User:prag2648:pragya\n>>> X-Auth-Key:pj2648\n>>>?\n>>< HTTP/1.1 200 OK\n>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>< X-Auth-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>< Content-Length: 0\n>>< X-Trans-Id: tx8f658e6bd3b244b793815-005222de45\n>>< Date: Sun, 01 Sep 2013 06:27:17 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: 127.0.0.1:8080\n>>> Accept: */*\n>>> X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>?\n>>< HTTP/1.1 503 Internal Server Error\n>>< Content-Length: 118\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Trans-Id: tx1c1cb6e3a9f64b56a9550-005222dea4\n>>< Date: Sun, 01 Sep 2013 06:28:54 GMT\n>><?\n>>* Connection #0 to host 127.0.0.1 left intact\n>>* Closing connection #0\n>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://localhost:8080/v1/AUTH_prag2648/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>?\n>>< HTTP/1.1 503 Internal Server Error\n>>< Content-Length: 118\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Trans-Id: txa4c98c518382430ab9f5f-005222dede\n>>< Date: Sun, 01 Sep 2013 06:29:51 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>root at arun-Aspire-5742:~#?\n>>\n>>\n>>But it again shows internal server error.\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Sent: Saturday, 31 August 2013 7:38 PM\n>>>\n>>>Subject: Re: Fw: problem in creating account in swift\n>>> \n>>>\n>>>\n>>>I was only just connecting to the account directly (127.0.0.1:6002) to prove a point - normally clients would always only talk to the proxy (127.0.0.1:8080).\n>>>\n>>>curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>\n>>>... should work?\n>>>\n>>>\n>>>\n>>>On Sat, Aug 31, 2013 at 3:17 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/ * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002 > Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n>>>>it shows a bad request error in retrieving the content of account\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Sent: Saturday, 31 August 2013 1:42 PM\n>>>>>\n>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>so that was only a couple of minutes of logs and it was ll the boring info lines from the background daemons. ?Let\'s stop those while we troubeshoot:\n>>>>>\n>>>>>\n>>>>>`swift-init rest stop`\n>>>>>\n>>>>>\n>>>>>\n>>>>>the listening servers show there\'s something listening on all interfaces on 6002. ?It doesn\'t make sense that you wouldn\'t be able to connect to it? ?Maybe this machine isn\'t really 10.0.2.15? ?Can you ping it? ?Maybe there\'s a weird route? ?Try localhost:\n>>>>>\n>>>>>\n>>>>>`curl http://localhost:6002`\n>>>>>\n>>>>>\n>>>>>can you /msg clayg on Freenode so we can chat realtime?\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Sat, Aug 31, 2013 at 1:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>hello sir,\n>>>>>>\n>>>>>>\n>>>>>>I run the following command:\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# sudo netstat -plnt\n>>>>>>Active Internet connections (only servers)\n>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?948/memcached ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2589/python ? ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6000 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2613/python ? ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6001 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2593/python ? ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2594/python ? ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?4137/dnsmasq ? ?\n>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:873 ? ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>>tcp6 ? ? ? 0 ? ? ?0 :::873 ? ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~#?cat /var/log/syslog\n>>>>>>paste the result on?http://paste.openstack.org/\n>>>>>>Paste #45522\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Sent: Saturday, 31 August 2013 1:15 PM\n>>>>>>>\n>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>so what port is it listening on?\n>>>>>>>\n>>>>>>>\n>>>>>>>`sudo netstat -plnt`\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>The logs man... the logs. ?`cat /var/log/syslog` copy the whole thing in?http://paste.openstack.org/ if you have to.\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Sat, Aug 31, 2013 at 12:37 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>* couldn\'t connect to host\n>>>>>>>>* Closing connection #0\n>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>[DEFAULT]\n>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>># bind_port = 6002\n>>>>>>>># bind_timeout = 30\n>>>>>>>># backlog = 4096\n>>>>>>>># user = swift\n>>>>>>>># swift_dir = /etc/swift\n>>>>>>>># devices = /srv/node\n>>>>>>>># mount_check = true\n>>>>>>>># disable_fallocate = false\n>>>>>>>>....\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n>>>>>>>>* About to connect() to 10.0.2.15 port 6002 (#0)\n>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>* couldn\'t connect to host\n>>>>>>>>* Closing connection #0\n>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Sent: Saturday, 31 August 2013 12:49 PM\n>>>>>>>>>\n>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>>>>>>>>>\n>>>>>>>>>By default the account server\'s listen on 6002:\n>>>>>>>>>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Can you connect to the account server on 6002?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Here\'s how you remove/add a server from the ring:\n>>>>>>>>>http://docs.openstack.org/developer/swift/admin_guide.html\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>>hello sir,\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I run the following commands:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>[DEFAULT]\n>>>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>>>># bind_port = 6002\n>>>>>>>>>># bind_timeout = 30\n>>>>>>>>>># backlog = 4096\n>>>>>>>>>># user = swift\n>>>>>>>>>># swift_dir = /etc/swift\n>>>>>>>>>># devices = /srv/node\n>>>>>>>>>># mount_check = true\n>>>>>>>>>># disable_fallocate = false\n>>>>>>>>>>....\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I am working on single node.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>----\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Pragya Jain\n>>>>>>>>>>Delhi, India\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>>>>>>>>>\n>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>\n>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>I start all services using the command:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>>>>>>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>Unable to locate config for object-expirer\n>>>>>>>>>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>>>>>>>>>Reading package lists... Done\n>>>>>>>>>>>>Building dependency tree ? ? ??\n>>>>>>>>>>>>Reading state information... Done\n>>>>>>>>>>>>rsync is already the newest version.\n>>>>>>>>>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>set rsync_enable = true\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>then,\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>>>>>>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>> X-Auth-key:pj2648\n>>>>>>>>>>>>>?\n>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>>>>>>>>>><?\n>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>>?\n>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>>>>>>>>>><?\n>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>^ on the 10.0.2.15 host\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>this shows problem:\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>>>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>>Traceback (most recent call last):\n>>>>>>>>>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>>>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>>>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>>>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>>>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>>>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Please help\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>and then\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>-Clay\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130903/a5a2af45/attachment.html>\n\n','<CA+_JKzpkDF-OBjRtf+C0YAFxt9SHPVQm-AiRWvHJ2tY9nW3hSw@mail.gmail.com>',NULL),('<1378197122.74235.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-03 01:32:02',-25200,'2013-09-03 08:32:02',NULL,'[Openstack] Ironic release date?','Hi Sylvain,\n\nThank you very much. Not sure what I am doing wrong here but seems like there are some steps missing or mistakes on the wiki.\n\nI very much look forward to you blog! I joined the irc channel. Hope to catch you there. (iLikeIT)\n\nBest,\nJake\n\n\n\n\n________________________________\n From: Sylvain Bauza <sylvain.bauza at bull.net>\nTo: Jake G. <dj_dark_junglist at yahoo.com> \nCc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \nSent: Tuesday, September 3, 2013 5:13 PM\nSubject: Re: [Openstack] Ironic release date?\n \n\n\nHi Jake,\n\nCome in #openstack-ironic, I\'ll try to help you as much as I can.\n      I tested the latest baremetal driver using devstack and real\n      baremetal hosts (using IPMI), it works like a charm.\n\n\nBtw, I\'m planning to write a blogpost about how to devstack using\n      baremetal driver. Hope it will help you.\n\n-Sylvain\n\nLe 03/09/2013 07:13, Jake G. a ?crit?:\n\nHi all,\n>\n>\n>I have been unable to get the nova baremetal driver to work to save my life,\n>so I was wondering when Ironic is expected to be released?\n>\n>\n>This year, next year sometime?\n>\n>\n>Thanks!\n>\n>\n>_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130903/db7212ab/attachment.html>\n\n','<52259A2A.2080103@bull.net>',NULL),('<1378215189.67447.YahooMailNeo@web172401.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-09-03 14:33:09',3600,'2013-09-03 13:33:09',NULL,'[Openstack-operators] OpenStack-operators Digest, Vol 35,\n	Issue 1','Yungho,\n\njust to note: you can use more than one of vlan/gre/flat at the same time - ie your installation can have both gre and vlan.\n\n\nAs Lorin says, gre mode is easier to setup because it is completely decoupled from the physical layer 2 network. I think gre would be particularly useful in large installations where tenants frequently create/destroy networks on demand. But the networks are isolated from the real world and require floating ips, and so an l3-agent which might be a chokepoint or a single point of failure - I\'m not sure what the l3-agent load balancing or failover options are with Grizzly. Also performance may suffer because the physical NICs TCP off-load engines never get triggered. \n\n\nWith vlan mode instances can access real networks and routers without need for floating IPs.\n\n\nRe,\nDarragh.\n\n\n>________________________________\n> From: Lorin Hochstein <lorin at nimbisservices.com>\n>To: yungho <yungho5054 at gmail.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, 3 September 2013, 4:24\n>Subject: Re: [Openstack-operators] OpenStack-operators Digest, Vol 35,????Issue 1\n> \n>\n>\n>Youngho:\n>\n>\n>On Mon, Sep 2, 2013 at 10:51 PM, yungho <yungho5054 at gmail.com> wrote:\n>\n>Hello,\n>>? ? ? ?I CentOs6.4 environment to deploy OpenStack G version, Controller Node, Network Node, Compute Node. Networks using Quantum, but is still on the Quantum network model do not know, and want to know under what circumstances the use of gre, under what circumstances the vlan mode.\n>>\n>>\n>>\n>\n>\n>Do you have administrative privileges on the networking switch that connects your compute hosts together? If so, I would recommend using vlan mode. You will need to configure your switch appropriately.\n>\n>\n>If you aren\'t able to modify the settings on your switch, or if your nodes are not all connected to the same L2 network, then you will need to use GRE tunnels.\n>\n>\n>I believe that GRE will work for pretty much all scenarios (since it just requires IP connectivity), but I think it introduces some overhead. However, I have no first-hand experience with it.\n>\n>\n>Take care,\n>\n>\n>Lorin\n>--?\n>\n>Lorin Hochstein\n>\n>Lead Architect - Cloud Services\n>Nimbis Services, Inc.\n>www.nimbisservices.com\n>_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n>\n\n\n','<CADzpNMUDv9zGMDYixrRi0J6HMPam136Uxqqq96snr7EtKp92xA@mail.gmail.com>',NULL),('<1378235096-sup-2047@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-03 12:12:51',-25200,'2013-09-03 19:12:51',NULL,'[Openstack] Slow API operations','Excerpts from Guilherme Russi\'s message of 2013-09-03 11:52:39 -0700:\n> Query OK, 502150 rows affected (32 min 2.77 sec) and nothing has changed,\n> lol.\n\nThere\'s also indexes in Havana that help a lot, you might consider adding\nthem manually:\n\nALTER TABLE token ADD INDEX ix_token_valid (valid);\nALTER TABLE token ADD INDEX ix_token_expires (expires);\n\nNote that a 500,000 row delete is _brutal_ on your server. We use this\nin TripleO:\n\nhttps://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/keystone/cleanup-keystone-tokens.sh\n\nIt allows space in between the deletes for other things to happen,\nand also deletes in a more efficient way to not thrash around the table\ndeleting things in index order.\n\nAlso, if you don\'t need the content of your token table for audit purposes\nand you can afford the RAM, you should definitely consider switching to\nthe memcached backend for tokens. If you do want to stay with the SQL\nbackend, make sure your MySQL is tuned for tons of tiny transactions\nand has enough memory to keep the working set in RAM.\n\n\n','<CAKz5Ux8wCDj9XOKHvX2hN64iaTWRApt5FPevA-FM8eAqtoY8QA@mail.gmail.com>',NULL),('<1378250729.59671.YahooMailNeo@web141001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-03 16:25:29',-25200,'2013-09-03 23:25:29',NULL,'[Openstack] Cinder question','Hello,\nI had a Cinder question, and maybe its pretty basic:-)\n\nIsn\'t there a way to attach the same Cinder volume to two different VMs, whether same physical server or different? I don\'t mean across different data centers, but any domain (zone, or whatever) within the same data center?\n\nThanks.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130903/49d98d70/attachment.html>\n\n',NULL,NULL),('<1378266992-sup-4247@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-03 21:02:32',-25200,'2013-09-04 04:02:32',NULL,'[openstack-dev] [keystone][heat] Question re deleting trusts\n	via trust token','Excerpts from Dolph Mathews\'s message of 2013-09-03 16:12:00 -0700:\n> On Tue, Sep 3, 2013 at 5:52 PM, Steven Hardy <shardy at redhat.com> wrote:\n> \n> > Hi,\n> >\n> > I have a question for the keystone folks re the expected behavior when\n> > deleting a trust.\n> >\n> > Is it expected that you can only ever delete a trust as the user who\n> > created it, and that you can *not* delete the trust when impersonating that\n> > user using a token obtained via that trust?\n> >\n> \n> We have some tests in keystone somewhat related to this scenario, but\n> nothing that asserts that specific behavior-\n> \n> https://github.com/openstack/keystone/blob/master/keystone/tests/test_auth.py#L737-L763\n> \n> > The reason for this question, is for the Heat use-case, this may represent\n> > a significant operational limitation, since it implies that the user who\n> > creates the stack is the only one who can ever delete it.\n> >\n> \n> I don\'t follow this implication-- can you explain further? I don\'t see how\n> the limitation above (if it exists) would impact this behavior or be a\n> blocker for the design below.\n> \n\nThe way heatclient works right now, it will obtain a trust from\nkeystone, and then give that trust to Heat to use while it is managing\nthe stack. However, if this user was just one user in a team of users\nwho manage that stack, then when the stack is deleted, neither heat,\nnor the user who is deleting the stack will be able to delete the trust\nthat was given to Heat.\n\nThis presents an operational hurdle for Heat users, as they will have to\nhave a stack \"owner\" user that is shared amongst a team. Otherwise they\nmay be stuck in a situation where the creating user is not available to\ndelete a stack that must be deleted for some reason.\n\nIdeally as a final operation with the trust Heat, or the user doing the\ndelete, would be able to use the trust to delete itself.\n\n\n','<CAC=h7gUQHind9fteqc1XENvE9VRQdRJPuypx2yQCx_m9geQVgg@mail.gmail.com>',NULL),('<1378273753.54877.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 13:49:13',28800,'2013-09-04 05:49:13',NULL,'[Openstack] Fw: problem in creating account in swift','root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\nobject.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\naccount.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\ncontainer.builder, build version 11\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# cd ~\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Length: 0\n< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n< Date: Wed, 04 Sep 2013 05:41:52 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n< Date: Wed, 04 Sep 2013 05:43:26 GMT\n<?\n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n< Date: Wed, 04 Sep 2013 05:44:05 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Sent: Tuesday, 3 September 2013 9:03 PM\n>Subject: Re: Fw: problem in creating account in swift\n> \n>\n>\n>Ok, so the 10.0.2.15 address must still be in the rings instead of 127.0.0.1\n>\n>\n>Did you verify what\'s in the ring with `swift-ring-builder account.builder`? ?Did you rebalance and restart services?\n>\n>\n>\n>On Tue, Sep 3, 2013 at 12:21 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogSep ?1 11:59:51 arun-Aspire-5742 proxy-server ERROR with Account server 10.0.2.15:6000/d1 re: Trying to GET /v1/AUTH_prag2648/: ConnectionTimeout (0.5s) (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\n>>Sep ?1 11:59:51 arun-Aspire-5742 proxy-server ERROR with Account server 10.0.2.15:6002/d1 re: Trying to GET /v1/AUTH_prag2648/: ConnectionTimeout (0.5s) (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\n>>Sep ?1 11:59:51 arun-Aspire-5742 proxy-server Account GET returning 503 for [] (txn: txa4c98c518382430ab9f5f-005222dede) (client_ip: 127.0.0.1)\n>>Sep ?1 11:59:51 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 01/Sep/2013/06/29/51 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk9867f9725a1246a1af3e30b9f7161eb5 - 118 - txa4c98c518382430ab9f5f-005222dede - 1.2649 - -\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Sent: Sunday, 1 September 2013 10:36 PM\n>>>\n>>>Subject: Re: Fw: problem in creating account in swift\n>>> \n>>>\n>>>\n>>>Still looks like a connection error to me, I think we\'ve established the account server is running on 127.0.0.1:6002 - so is that\'s what\'s in the ring after all?\n>>>\n>>>you could also `grep txa4c98c518382430ab9f5f-005222dede /var/log/syslog` and see what error the proxy was getting.\n>>>\n>>>-Clay \n>>>\n>>>\n>>>\n>>>-\n>>>\n>>>\n>>>\n>>>On Sat, Aug 31, 2013 at 11:32 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I did the following job:\n>>>>\n>>>>\n>>>>arun at arun-Aspire-5742:~$ su -\n>>>>Password:?\n>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>* About to connect() to localhost port 8080 (#0)\n>>>>* ? Trying 127.0.0.1... connected\n>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>> Host: localhost:8080\n>>>>> Accept: */*\n>>>>> X-Auth-User:prag2648:pragya\n>>>>> X-Auth-Key:pj2648\n>>>>>?\n>>>>< HTTP/1.1 200 OK\n>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>< X-Auth-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>>< Content-Type: text/html; charset=UTF-8\n>>>>< X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>>< Content-Length: 0\n>>>>< X-Trans-Id: tx8f658e6bd3b244b793815-005222de45\n>>>>< Date: Sun, 01 Sep 2013 06:27:17 GMT\n>>>><?\n>>>>* Connection #0 to host localhost left intact\n>>>>* Closing connection #0\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>* ? Trying 127.0.0.1... connected\n>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>> Host: 127.0.0.1:8080\n>>>>> Accept: */*\n>>>>> X-Storage-Token: AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>>>?\n>>>>< HTTP/1.1 503 Internal Server Error\n>>>>< Content-Length: 118\n>>>>< Content-Type: text/html; charset=UTF-8\n>>>>< X-Trans-Id: tx1c1cb6e3a9f64b56a9550-005222dea4\n>>>>< Date: Sun, 01 Sep 2013 06:28:54 GMT\n>>>><?\n>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>* Closing connection #0\n>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>* About to connect() to localhost port 8080 (#0)\n>>>>* ? Trying 127.0.0.1... connected\n>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>> Host: localhost:8080\n>>>>> Accept: */*\n>>>>> X-Storage-Token:AUTH_tk9867f9725a1246a1af3e30b9f7161eb5\n>>>>>?\n>>>>< HTTP/1.1 503 Internal Server Error\n>>>>< Content-Length: 118\n>>>>< Content-Type: text/html; charset=UTF-8\n>>>>< X-Trans-Id: txa4c98c518382430ab9f5f-005222dede\n>>>>< Date: Sun, 01 Sep 2013 06:29:51 GMT\n>>>><?\n>>>>* Connection #0 to host localhost left intact\n>>>>* Closing connection #0\n>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>root at arun-Aspire-5742:~#?\n>>>>\n>>>>\n>>>>But it again shows internal server error.\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Sent: Saturday, 31 August 2013 7:38 PM\n>>>>>\n>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>I was only just connecting to the account directly (127.0.0.1:6002) to prove a point - normally clients would always only talk to the proxy (127.0.0.1:8080).\n>>>>>\n>>>>>curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>\n>>>>>... should work?\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Sat, Aug 31, 2013 at 3:17 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder add z1-127.0.0.1:6002/d1 100\nWARNING: No region specified for z1-127.0.0.1:6002/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6002R127.0.0.1:6002/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder add z1-127.0.0.1:6001/d1 100\nWARNING: No region specified for z1-127.0.0.1:6001/d1. Defaulting to region 1.\nDevice d1r1z1-127.0.0.1:6001R127.0.0.1:6001/d1_\"\" with 100.0 weight got id 1\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder add z1-127.0.0.1:6000/d1 100\nWARNING: No region specified for z1-127.0.0.1:6000/d1. Defaulting to region 1.\nDevice d2r1z1-127.0.0.1:6000R127.0.0.1:6000/d1_\"\" with 100.0 weight got id 2\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder rebalance\nReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalance \nReassigned 262144 (100.00%) partitions. Balance is now 33.33.\n-------------------------------------------------------------------------------\nNOTE: Balance of 33.33 indicates you should push this  ring, wait at least 24 hours, and rebalance/repush.\n-------------------------------------------------------------------------------\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder pretend_min_part_hours_passed\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder rebalanceReassigned 131072 (50.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder rebalanceReassigned 262144 (100.00%) partitions. Balance is now 0.00.\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/ * About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:/etc/swift# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>* About to connect() to localhost port 8080 (#0)\n*   Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n< Content-Length: 0\n< X-Trans-Id: tx21f0255793574234b88aa-005221bf20\n< Date: Sat, 31 Aug 2013 10:02:08 GMT\n< \n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 80 (#0)\n*   Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:/etc/swift# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1:6002/v1/AUTH_prag2648/ * About to connect() to 127.0.0.1 port 6002 (#0)\n*   Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:6002 > Accept: */*\n> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n> \n< HTTP/1.1 400 Bad Request\n< Content-Length: 32\n< Content-Type: text/plain\n< Date: Sat, 31 Aug 2013 10:04:14 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n>>>>>>it shows a bad request error in retrieving the content of account\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>Sent: Saturday, 31 August 2013 1:42 PM\n>>>>>>>\n>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>so that was only a couple of minutes of logs and it was ll the boring info lines from the background daemons. ?Let\'s stop those while we troubeshoot:\n>>>>>>>\n>>>>>>>\n>>>>>>>`swift-init rest stop`\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>the listening servers show there\'s something listening on all interfaces on 6002. ?It doesn\'t make sense that you wouldn\'t be able to connect to it? ?Maybe this machine isn\'t really 10.0.2.15? ?Can you ping it? ?Maybe there\'s a weird route? ?Try localhost:\n>>>>>>>\n>>>>>>>\n>>>>>>>`curl http://localhost:6002`\n>>>>>>>\n>>>>>>>\n>>>>>>>can you /msg clayg on Freenode so we can chat realtime?\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Sat, Aug 31, 2013 at 1:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>\n>>>>>>>hello sir,\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>I run the following command:\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# sudo netstat -plnt\n>>>>>>>>Active Internet connections (only servers)\n>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?948/memcached ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2589/python ? ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6000 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2613/python ? ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6001 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2593/python ? ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2594/python ? ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?4137/dnsmasq ? ?\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:873 ? ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?579/cupsd ? ? ??\n>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 :::873 ? ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?2816/rsync ? ? ?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~#?cat /var/log/syslog\n>>>>>>>>paste the result on?http://paste.openstack.org/\n>>>>>>>>Paste #45522\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Sent: Saturday, 31 August 2013 1:15 PM\n>>>>>>>>>\n>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>so what port is it listening on?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>`sudo netstat -plnt`\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>The logs man... the logs. ?`cat /var/log/syslog` copy the whole thing in?http://paste.openstack.org/ if you have to.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>On Sat, Aug 31, 2013 at 12:37 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\'http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>[DEFAULT]\n>>>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>>>># bind_port = 6002\n>>>>>>>>>># bind_timeout = 30\n>>>>>>>>>># backlog = 4096\n>>>>>>>>>># user = swift\n>>>>>>>>>># swift_dir = /etc/swift\n>>>>>>>>>># devices = /srv/node\n>>>>>>>>>># mount_check = true\n>>>>>>>>>># disable_fallocate = false\n>>>>>>>>>>....\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6002/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 10.0.2.15 port 6002 (#0)\n>>>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>Sent: Saturday, 31 August 2013 12:49 PM\n>>>>>>>>>>>\n>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>ok, so you\'re getting the exact same error the proxy is - unable to connect. ?I\'m sure that is in the log - can you check?\n>>>>>>>>>>>\n>>>>>>>>>>>By default the account server\'s listen on 6002:\n>>>>>>>>>>>http://docs.openstack.org/developer/swift/deployment_guide.html#account-server-configuration\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>not 6000 - so your ring is pointing your proxy at the wrong place (or your account server is listening on the wrong port, however you want to look at it)\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Can you connect to the account server on 6002?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Here\'s how you remove/add a server from the ring:\n>>>>>>>>>>>http://docs.openstack.org/developer/swift/admin_guide.html\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>On Fri, Aug 30, 2013 at 11:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>\n>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>I run the following commands:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://10.0.2.15:6000/v1/AUTH_prag2648/\n>>>>>>>>>>>>* About to connect() to 10.0.2.15 port 6000 (#0)\n>>>>>>>>>>>>* ? Trying 10.0.2.15... Connection timed out\n>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>/etc/swift/account-server.conf file says:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>[DEFAULT]\n>>>>>>>>>>>># bind_ip = 0.0.0.0\n>>>>>>>>>>>># bind_port = 6002\n>>>>>>>>>>>># bind_timeout = 30\n>>>>>>>>>>>># backlog = 4096\n>>>>>>>>>>>># user = swift\n>>>>>>>>>>>># swift_dir = /etc/swift\n>>>>>>>>>>>># devices = /srv/node\n>>>>>>>>>>>># mount_check = true\n>>>>>>>>>>>># disable_fallocate = false\n>>>>>>>>>>>>....\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>----\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>Delhi, India\n>>>>>>>>>>>>\n>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>Sent: Saturday, 31 August 2013 11:22 AM\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Right so the service seems to start, but then the proxy can\'t seem to talk to it. ?Maybe the proxy is looking in the wrong?place? ?You said you can\'t connect to the account-server on 10.0.2.15:6000 earlier - which is where the ring seems to indicate the proxy should be looking for it - can you connect now? ?What port does the account server(s) config file *say* they\'re listening on? ?After you start them - are they listening there? ? What is the topology of your cluster - is it just the one node?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I really could guess about *why* that is happening all day, but the proxy logs would just tell us. ?Can you read /var/log/syslog?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Where are you located? ?Maybe we could find you some real over the shoulder help?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 10:05 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>I start all services using the command:\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init all start\n>>>>>>>>>>>>>>Starting container-updater...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>>>Starting account-auditor...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>Starting object-replicator...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>Starting container-replicator...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>>>Starting object-auditor...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>>>Unable to locate config for object-expirer\n>>>>>>>>>>>>>>Starting container-auditor...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>>>Starting container-server...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>Starting account-reaper...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>Starting container-sync...(/etc/swift/container-server.conf)\n>>>>>>>>>>>>>>Starting account-replicator...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>Starting object-updater...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>>>Starting object-server...(/etc/swift/object-server.conf)\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo apt-get install rsync\n>>>>>>>>>>>>>>Reading package lists... Done\n>>>>>>>>>>>>>>Building dependency tree ? ? ??\n>>>>>>>>>>>>>>Reading state information... Done\n>>>>>>>>>>>>>>rsync is already the newest version.\n>>>>>>>>>>>>>>0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# vi /etc/default/rsync\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>set rsync_enable = true\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>then,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# service rsync start\n>>>>>>>>>>>>>>?* Starting rsync daemon rsync ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ OK ]?\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>> X-Auth-key:pj2648\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>< X-Trans-Id: tx44b17cb561a84a34bee95-00522171e4\n>>>>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:32:36 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Storage-Token: AUTH_tk06aa273c010b4e7d886b7ec78fbef396\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Trans-Id: txbe793299553c42f2820dc-005221728d\n>>>>>>>>>>>>>>< Date: Sat, 31 Aug 2013 04:35:26 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:14 PM\n>>>>>>>>>>>>>>>Subject: Re: Fw: problem in creating account in swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>yeah sorry on the ring-builder command, i\'m going from memory... so... the account server isn\'t running - any idea why? ?can you start it?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>swift-container-server /etc/swift/container-server.conf\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>^ on the 10.0.2.15 host\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 12:29 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>----- Forwarded Message -----\n>>>>>>>>>>>>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:54 PM\n>>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>this shows problem:\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replic\n>>>>>>>>>>>>>>>>>port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>>>>Traceback (most recent call last):\n>>>>>>>>>>>>>>>>>? File \"/usr/local/bin/swift-ring-builder\", line 5, in <module>\n>>>>>>>>>>>>>>>>>? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-ring-builder\')\n>>>>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>>? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>>? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>>? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-ring-builder\", line 808, in <module>\n>>>>>>>>>>>>>>>>>? ? builder = RingBuilder.load(argv[1])\n>>>>>>>>>>>>>>>>>? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/ring/builder.py\", line 993, in load\n>>>>>>>>>>>>>>>>>? ? builder = pickle.load(open(builder_file, \'rb\'))\n>>>>>>>>>>>>>>>>>cPickle.UnpicklingError: invalid load key, \'\'.\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://<ip>:<port>\n>>>>>>>>>>>>>>>>>-su: syntax error near unexpected token `newline\'\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl http://10.0.2.15:6000\n>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Please help\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 12:35 PM\n>>>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>swift-ring-builder /etc/swift/account.ring.gz\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>and then\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>curl http://<ip>:<port>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>you can also check the proxy logs - it should have the backend requests there you could still the urls from them and make sure they match what\'s in the ring.\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>-Clay\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 10:38 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>Please help me to know how to check port of account server and how can I connect to them directly.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 8:59 PM\n>>>>>>>>>>>>>>>>>>>>Subject: Re: problem in creating account in swift\n>>>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>Probably something in the rings, maybe the wrong ports for the account servers? ?Or maybe something in the account server config - what port are they on? ?can you connect to them directly? ?The proxy log lines would say exactly what caused the 503 - can see anything in /var/log/syslog - or maybe /var/log/swift ?\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>On Thu, Aug 29, 2013 at 7:01 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/e47fff18/attachment.html>\n\n','<CA+_JKzrzoZs1t5LWM8+4=+-E=Yq7RL7iNtM-DwOY6S+Sr+5WGA@mail.gmail.com>',NULL),('<1378273811.42276.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 13:50:11',28800,'2013-09-04 05:50:11',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\nobject.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\naccount.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\ncontainer.builder, build version 11\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# cd ~\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Length: 0\n< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n< Date: Wed, 04 Sep 2013 05:41:52 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n< Date: Wed, 04 Sep 2013 05:43:26 GMT\n<?\n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n< Date: Wed, 04 Sep 2013 05:44:05 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n\n\n\n\n>________________________________\n> From: Gareth <academicgareth at gmail.com>\n>To: Kuo Hugo <tonytkdk at gmail.com> \n>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 8:11 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Pragya\n>\n>\n>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>\n>\n>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>\n>\n>\n>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>\n>Hi Pragya,?\n>>\n>>\n>>I need more information.?\n>>\n>>\n>>1) Please draw a network topology of your environment\n>>2) How many nodes do you have? ?\n>>3) What\'s the ring looks like ?\n>>\n>>\n>>\n>>Hugo Kuo\n>>hugo at swiftstack.com\n>>\n>>tonytkdk at gmail.com\n>>\n>>+886 935004793\n>>\n>>\n>>\n>>\n>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>\n>>hello sir,\n>>>\n>>>\n>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>\n>>>\n>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /auth/v1.0/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Auth-User:prag2648:pragya\n>>>> X-Auth-Key:pj2648\n>>>>?\n>>>< HTTP/1.1 200 OK\n>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>< Content-Length: 0\n>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>>root at arun-Aspire-5742:~# python\n>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>[GCC 4.6.3] on linux2\n>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>> import swift.common.memcached as memcached\n>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>?\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>* ? Trying 127.0.0.1... Connection refused\n>>>* couldn\'t connect to host\n>>>* Closing connection #0\n>>>curl: (7) couldn\'t connect to host\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>?\n>>>< HTTP/1.1 503 Internal Server Error\n>>>< Content-Length: 118\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>\n>>>\n>>>Please help me in this regard.\n>>>\n>>>\n>>>---\n>>>\n>>>\n>>>Pragya Jain\n>>>\n>>>>________________________________\n>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>\n>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>Thanks Kuo very much for this help.\n>>>>connection is successfully established.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>\n>>>>>\n>>>>>+Hugo Kuo+\n>>>>>hugo at swiftstack.com\n>>>>>tonytkdk at gmail.com\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>\n>>>>>> user = swift\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>\n>>>>>> 1) is 8080 port been used ?\n>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir,\n>>>>>>\n>>>>>> I run the command:\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>> Traceback (most recent call last):\n>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>\n>>>>>> gt; find / -name swift-proxy-server\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir\n>>>>>>\n>>>>>> Thanks for the help\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>\n>>>>>> this is the result of the command.\n>>>>>>\n>>>>>> please help in this regard.\n>>>>>>\n>>>>>> -----\n>>>>>> Pragya Jain\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>\n>>>>>> Please execute it on the node where proxy-server located: \n>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>\n>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> What\'s the result ?\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir\n>>>>>>\n>>>>>> Thanks for the suggestion.\n>>>>>>\n>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> and make following changes:\n>>>>>>\n>>>>>>\n>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>> user_test_tester = testing .admin\n>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>> user_test_tester3 = testing3\n>>>>>>\n>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>\n>>>>>> and then\n>>>>>>\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>> Active Internet connections (servers and established)\n>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>\n>>>>>> Please help to proceed further.\n>>>>>>\n>>>>>> ---\n>>>>>>\n>>>>>> Thanks\n>>>>>>\n>>>>>> Pragya jain\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Hi \n>>>>>>\n>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>> 2) Verify the port number of proxy by \n>>>>>>\n>>>>>> gt; ps aux | grep proxy \n>>>>>> gt; netstat -antulp \n>>>>>>\n>>>>>>\n>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> +Hugo Kuo+\n>>>>>> hugo at swiftstack.com\n>>>>>> tonytkdk at gmail.com\n>>>>>> +886 935004793\n>>>>>>\n>>>>>>\n>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>> hello sir,\n>>>>>>\n>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>\n>>>>>>\n>>>>>> ________________________________\n>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> Hello,\n>>>>>>\n>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>\n>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>\n>>>>>>\n>>>>>> Thank you,\n>>>>>> Amanda\n>>>>>>\n>>>>>> SwiftStack Inc.\n>>>>>> swiftstack.com\n>>>>>>\n>>>>>>\n>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>> hello sir!\n>>>>>>\n>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>> same error is continued.\n>>>>>>\n>>>>>> ----- Forwarded Message -----\n>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>\n>>>>>> hello,\n>>>>>>\n>>>>>> I have to configure proxy server.\n>>>>>> For this,\n>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>\n>>>>>> for this, I use the following commands:\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>\n>>>>>> make following changes (highlighted) in the file:\n>>>>>> swift_hash_path_suffix =pragya\n>>>>>> swift_hash_path_prefix =jain\n>>>>>>\n>>>>>> save and exit.\n>>>>>> then, I run the command:\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>\n>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>> for this, I run the following command:\n>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>\n>>>>>> make following changes (highlighted) in the file:\n>>>>>> allow_account_management =true\n>>>>>> ...\n>>>>>> [filter:tempauth]\n>>>>>> use = egg:swift#tempauth\n>>>>>> ...\n>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>> user_test_tester = testing .admin\n>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>> user_test_tester3 = testing3\n>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>> ...\n>>>>>>\n>>>>>> save and exit\n>>>>>> Then, run following commands:\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>> proxy-server (2476) appears to have stopped\n>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>> * couldn\'t connect to host\n>>>>>> * Closing connection #0\n>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>\n>>>>>> But, there is an error in establising a connection.\n>>>>>>\n>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>> proxy-server already started...\n>>>>>>\n>>>>>> Please help me in this regard.\n>>>>>> ---\n>>>>>>\n>>>>>> Thanks\n>>>>>>\n>>>>>> Pragya Jain\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> _______________________________________________\n>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n>-- \n>\n>Gareth\n>\n>\n>Cloud Computing, OpenStack, Fitness, Basketball\n>OpenStack contributor\n>Company: UnitedStack\n>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>and I\'ll donate $1 or ?1 to an open organization you specify.\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/bba101db/attachment.html>\n\n','<CAAhuP_9LLRBB1U1rK668MX3tSTykRBPy08F7Kpn7X+tf1neeNQ@mail.gmail.com>',NULL),('<1378273871.52383.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 13:51:11',28800,'2013-09-04 05:51:11',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\nobject.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\naccount.builder, build version 14\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\ncontainer.builder, build version 11\n262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\nThe minimum number of hours before a partition can be reassigned is 24\nDevices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\nroot at arun-Aspire-5742:/etc/swift# cd ~\nroot at arun-Aspire-5742:~# sudo swift-init account start\nStarting account-server...(/etc/swift/account-server.conf)\nroot at arun-Aspire-5742:~# sudo swift-init proxy start\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nroot at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /auth/v1.0/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Auth-User:prag2648:pragya\n> X-Auth-Key:pj2648\n>?\n< HTTP/1.1 200 OK\n< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n< Content-Length: 0\n< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n< Date: Wed, 04 Sep 2013 05:41:52 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n< Date: Wed, 04 Sep 2013 05:43:26 GMT\n<?\n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n* About to connect() to 127.0.0.1 port 80 (#0)\n* ? Trying 127.0.0.1... Connection refused\n* couldn\'t connect to host\n* Closing connection #0\ncurl: (7) couldn\'t connect to host\nroot at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n* About to connect() to localhost port 8080 (#0)\n* ? Trying 127.0.0.1... connected\n> GET /v1/AUTH_prag2648/ HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: localhost:8080\n> Accept: */*\n> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>?\n< HTTP/1.1 503 Internal Server Error\n< Content-Length: 118\n< Content-Type: text/html; charset=UTF-8\n< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n< Date: Wed, 04 Sep 2013 05:44:05 GMT\n<?\n* Connection #0 to host localhost left intact\n* Closing connection #0\n<html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\nroot at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n\n\n\n\n>________________________________\n> From: Kuo Hugo <tonytkdk at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 30 August 2013 1:15 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Hmm....?\n>\n>\n>1) No Container and Object servers are running?\n>2) Only one drive in the ring\n>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>4) Did you setup rsync yet ??\n>\n>\n>Maybe you can follow the online document to complete the above items.?\n>\n>\n>Good luck~\n>\n>\n>\n>\n>\n>\n>+Hugo Kuo+\n>hugo at swiftstack.com\n>\n>tonytkdk at gmail.com\n>\n>+886 935004793\n>\n>\n>\n>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>\n>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>/etc/swift/account.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>/etc/swift/container.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>/etc/swift/object.builder, build version 1\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>root at arun-Aspire-5742:~# df -h\n>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>/srv/node/d1:\n>>\n>>\n>>/srv/node/d2:\n>>\n>>\n>>/srv/node/d3:\n>>root at arun-Aspire-5742:~# netstat -antulp\n>>Active Internet connections (servers and established)\n>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>ISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>root at arun-Aspire-5742:~# swift-init all status\n>>No container-updater running\n>>No account-auditor running\n>>No object-replicator running\n>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>No container-replicator running\n>>No object-auditor running\n>>No object-expirer running\n>>No container-auditor running\n>>No container-server running\n>>account-server running (5174 - /etc/swift/account-server.conf)\n>>No account-reaper running\n>>No container-sync running\n>>No account-replicator running\n>>No object-updater running\n>>No object-server running\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hi Pragya :?\n>>>\n>>>\n>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>\n>>>\n>>>\n>>>Check rings :\n>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>\n>>>\n>>>Check Swift workers :?\n>>>$> swift-init all status\n>>>>$> ps aux | grep swift\n>>>>$> df -h?\n>>>>$> ls /srv/node/*\n>>>>$> netstat -antulp\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I am working on single node.\n>>>>Please let me know how to check network topology and ring structure.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Pragya\n>>>>>\n>>>>>\n>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>\n>>>>>\n>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>\n>>>>>Hi Pragya,?\n>>>>>>\n>>>>>>\n>>>>>>I need more information.?\n>>>>>>\n>>>>>>\n>>>>>>1) Please draw a network topology of your environment\n>>>>>>2) How many nodes do you have? ?\n>>>>>>3) What\'s the ring looks like ?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Hugo Kuo\n>>>>>>hugo at swiftstack.com\n>>>>>>\n>>>>>>tonytkdk at gmail.com\n>>>>>>\n>>>>>>+886 935004793\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>>hello sir,\n>>>>>>>\n>>>>>>>\n>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>Please help me in this regard.\n>>>>>>>\n>>>>>>>\n>>>>>>>---\n>>>>>>>\n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>\n>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>connection is successfully established.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>+886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>\n>>>>>>>>>> user = swift\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>\n>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> I run the command:\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>\n>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the help\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>\n>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>\n>>>>>>>>>> please help in this regard.\n>>>>>>>>>>\n>>>>>>>>>> -----\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>\n>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>\n>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir\n>>>>>>>>>>\n>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>\n>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> and make following changes:\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>\n>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>\n>>>>>>>>>> and then\n>>>>>>>>>>\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>\n>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hi \n>>>>>>>>>>\n>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>\n>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>> +886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>> hello sir,\n>>>>>>>>>>\n>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> ________________________________\n>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> Hello,\n>>>>>>>>>>\n>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>\n>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> Thank you,\n>>>>>>>>>> Amanda\n>>>>>>>>>>\n>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>> swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>\n>>>>>>>>>> hello sir!\n>>>>>>>>>>\n>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>> same error is continued.\n>>>>>>>>>>\n>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>\n>>>>>>>>>> hello,\n>>>>>>>>>>\n>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>> For this,\n>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>\n>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>\n>>>>>>>>>> save and exit.\n>>>>>>>>>> then, I run the command:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>\n>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>\n>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>> allow_account_management =true\n>>>>>>>>>> ...\n>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>> ...\n>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>> ...\n>>>>>>>>>>\n>>>>>>>>>> save and exit\n>>>>>>>>>> Then, run following commands:\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>> * Closing connection #0\n>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>\n>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>\n>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>\n>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>> ---\n>>>>>>>>>>\n>>>>>>>>>> Thanks\n>>>>>>>>>>\n>>>>>>>>>> Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>> _______________________________________________\n>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>-- \n>>>>>\n>>>>>Gareth\n>>>>>\n>>>>>\n>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>OpenStack contributor\n>>>>>Company: UnitedStack\n>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/0b9b6771/attachment.html>\n\n','<CA++_uhsZBr4PK8bveA2A-x1MSxd+eObmm-mCL+mToy3MKK5PXA@mail.gmail.com>',NULL),('<1378310367.23.1383028266795.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-29 06:31:06',0,'2013-10-29 06:31:06',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #46','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/46/>\n\n------------------------------------------\n[...truncated 21069 lines...]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  176.774\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          106.460\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                 100.584\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       42.835\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]             42.314\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        40.449\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       36.863\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        35.435\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         33.828\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     31.851\n\n----------------------------------------------------------------------\nRan 1401 tests in 1258.998s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-615111-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-615111.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-615111/46/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<76345201.19.1382941806408.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1378322446.5262.YahooMailNeo@web141001.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 12:20:46',-25200,'2013-09-04 19:20:46',NULL,'[Openstack] Mapping - keystone to Swift','Hello,\nIs there any documentation about what is the mapping between keystone constructs and Swift constructs?\n\nKeystone has tenants, users, roles and Swift has accounts.\n\nTenants map 1-1 to Swift accounts, and users within a tenant(or account) can access each others objects and containers if they are admin(role). What does a user map to in Swift though, or is it just used within Keystone, for local or say, AD users? Also, does a role map to anything within Swift? It is a bit confusing, because Swift requires admin access to create objects, is that only specific to keystone as an auth. Some clarity around this would really help.\n\nCheers.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/8e13f1f7/attachment.html>\n\n',NULL,NULL),('<1378322480.24181.YahooMailNeo@web141006.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 12:21:20',-25200,'2013-09-04 19:21:20',NULL,'[Openstack] Cinder question','It definitely would be something useful. Dont know why it is not already implemented.\n\n\n________________________________\n From: Swapnil Kulkarni <swapnilkulkarni2608 at gmail.com>\nTo: Razique Mahroua <razique.mahroua at gmail.com> \nCc: Openstack Openstack <openstack at lists.openstack.org> \nSent: Wednesday, September 4, 2013 2:44 AM\nSubject: Re: [Openstack] Cinder question\n \n\n\nGuys,\n\n\nYou might want to have a look at https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume\n\nIts already proposed\n\n\n\nBest Regards,\nSwapnil Kulkarni\nswapnilkulkarni2608 at gmail.com\n+91-87960 10622(c)\nhttp://in.linkedin.com/in/coolsvap\n\n\n\n\nOn Wed, Sep 4, 2013 at 2:24 PM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n\nIt doesn\'t necessarily uses iscsi,?\n>but yes I definitely agree man !\n>\n>\n>Le 4 sept. 2013 ? 10:37, Martinx - ????? <thiagocmartinsc at gmail.com> a ?crit :\n>\n>\n>This is a must!! It would be great to attach 1 volume, to multiple instances!!\n>>Sounds pretty basic, since it uses iSCSI, there is no reason to not allow this...\n>>\n>>\n>>Cheers!\n>>Thiago\n>>\n>>\n>>\n>>On 3 September 2013 20:25, Mark Brown <ntdeveloper2002 at yahoo.com> wrote:\n>>\n>>Hello,\n>>>I had a Cinder question, and maybe its pretty basic:-)\n>>>\n>>>Isn\'t there a way to attach the same Cinder volume to two different VMs, whether same physical server or different? I don\'t mean across different data centers, but any domain (zone, or whatever) within the same data center?\n>>>\n>>>Thanks.\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ????: openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/c0c96304/attachment.html>\n\n','<CAN_H9NgPEQL5NxexSN2EnY+4ZGVW0Ttzyk1sENgD+hSos802iw@mail.gmail.com>',NULL),('<1378344450.9130.27.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-04 20:27:30',-18000,'2013-09-05 01:27:30',NULL,'[Openstack] Keystone \'NoneType\' object is unsubscriptable error','What happens after you add a service,\n\ncurl -X POST -H \"X-Auth-Token: <auth-token>\" -H \"Content-type:\napplication/json\" --data \'{\"OS-KSADM:service\":\n{\"name\":\"Test\",\"type\":\"test\",\"extra\":\"{}\"}}\'\nhttp://0.0.0.0:35357/v2.0/OS-KSADM/services\n\n\n\nSean\n\n\nOn Thu, 2013-09-05 at 00:39 +0000, Goldstone, Robin J. wrote:\n> I am trying to install the RDO OpenStack distribution on a RHEL 6.4\n> system.  The install is failing during keystone configuration as\n> follows:\n> ^[[1;35merr: /Stage[main]/Cinder::Keystone::Auth/Keystone_service[cinder]: Could not evaluate: Execution of \'/usr/bin/keystone --endpoint http://127.0.0.1:35357/v2.0/ service-list\' returned 1: \'NoneType\' object is unsubscriptable\n> \n> \n> If I run the command interactively I get the same error:\n> # brutus1 /etc/keystone > export\n> OS_SERVICE_TOKEN=49c056f8688540fcb933cf7335537676\n> # brutus1 /etc/keystone > export\n> OS_SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0 \n> # brutus1 /etc/keystone > keystone service-list\n> \'NoneType\' object is unsubscriptable\n> \n> \n> The keystone service appears to be running and connected to the mysql\n> database:\n> # brutus1 /root > ps -ef|grep keystone\n> keystone  8451     1  0 17:20 ?\n>  00:00:00 /usr/bin/python /usr/bin/keystone-all\n> --config-file /etc/keystone/keystone.conf\n> # brutus1 /root > lsof -i|grep keystone\n> keystone- 8451 keystone    4u  IPv4  21614      0t0  TCP *:35357\n> (LISTEN)\n> keystone- 8451 keystone    6u  IPv4  21616      0t0  TCP\n> *:commplex-main (LISTEN)\n> keystone- 8451 keystone    8u  IPv4  21961      0t0  TCP\n> ebrutus1:54531->ebrutus1:mysql (ESTABLISHED)\n> \n> \n> The mysql database appears to have been properly initialized though\n> hardly any of the tables have anything in them.\n> \n> \n> mysql> use keystone;\n> Reading table information for completion of table and column names\n> You can turn off this feature to get a quicker startup with -A\n> \n> \n> Database changed\n> mysql> show tables;\n> +------------------------+\n> | Tables_in_keystone     |\n> +------------------------+\n> | credential             |\n> | domain                 |\n> | ec2_credential         |\n> | endpoint               |\n> | group                  |\n> | group_domain_metadata  |\n> | group_project_metadata |\n> | migrate_version        |\n> | policy                 |\n> | project                |\n> | role                   |\n> | service                |\n> | token                  |\n> | trust                  |\n> | trust_role             |\n> | user                   |\n> | user_domain_metadata   |\n> | user_group_membership  |\n> | user_project_metadata  |\n> +------------------------+\n> 19 rows in set (0.00 sec)\n> \n> \n> mysql> select * from service;\n> Empty set (0.00 sec)\n> \n> \n> I cranked up the debug level in the keystone log file and here is what\n> I see:\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> ******************** REQUEST ENVIRON ********************\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SCRIPT_NAME\n> = /v2.0\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] webob.adhoc_attrs\n> = {\'response\': <Response at 0x2373510 200 OK>}\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] REQUEST_METHOD =\n> GET\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] PATH_INFO\n> = /OS-KSADM/services\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_PROTOCOL =\n> HTTP/1.0\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_X_AUTH_TOKEN\n> = 49c056f8688540fcb933cf7335537676\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_USER_AGENT =\n> python-keystoneclient\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] eventlet.posthooks\n> = []\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_NAME =\n> 127.0.0.1\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] REMOTE_ADDR =\n> 127.0.0.1\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] eventlet.input =\n> <eventlet.wsgi.Input object at 0x236b8d0>\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.url_scheme =\n> http\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_PORT =\n> 35357\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.input =\n> <eventlet.wsgi.Input object at 0x236b8d0>\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_HOST =\n> 127.0.0.1:35357\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.multithread =\n> True\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_ACCEPT = */*\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.version = (1,\n> 0)\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] openstack.context\n> = {\'token_id\': \'49c056f8688540fcb933cf7335537676\', \'is_admin\': True}\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] GATEWAY_INTERFACE\n> = CGI/1.1\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.run_once =\n> False\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.errors =\n> <open file \'<stderr>\', mode \'w\' at 0x2aaaaaae81e0>\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.multiprocess\n> = False\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] CONTENT_TYPE =\n> text/plain\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> HTTP_ACCEPT_ENCODING = identity, deflate, compress, gzip\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> ******************** REQUEST BODY ********************\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] arg_dict: {}\n> 2013-09-04 17:37:48     INFO [sqlalchemy.engine.base.Engine] SELECT\n> service.id AS service_id, service.type AS service_type, service.extra\n> AS service_extra\n> FROM service\n> 2013-09-04 17:37:48     INFO [sqlalchemy.engine.base.Engine] ()\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> ******************** RESPONSE HEADERS ********************\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Vary =\n> X-Auth-Token\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Content-Type =\n> application/json\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Content-Length =\n> 25\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> ******************** RESPONSE BODY ********************\n> 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> {\"OS-KSADM:services\": []}\n> 2013-09-04 17:37:48     INFO [access] 127.0.0.1 - -\n> [05/Sep/2013:00:37:48 +0000] \"GET\n> http://127.0.0.1:35357/v2.0/OS-KSADM/services HTTP/1.0\" 200 25\n> 2013-09-04 17:37:48    DEBUG [eventlet.wsgi.server] 127.0.0.1 - -\n> [04/Sep/2013 17:37:48] \"GET /v2.0/OS-KSADM/services HTTP/1.1\" 200 153\n> 0.008193\n> \n> \n> \n> \n> I have tried completely wiping out and reinstalling RDO but it chokes\n> at the same point.   Myself, along with several other people, have\n> reported this error on the RDO forum but no one over there has\n> responded so I thought I would try my luck over here.  If anyone has\n> an idea of what my problem is, or can offer advice on further\n> troubleshooting, please let me know.  \n> \n> \n> Thank you in advance.\n> Robin Goldstone, LLNL\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130904/c97ac837/attachment.html>\n\n','<D17A8FDF3CC59847983F6B75C05DB38B1544A0@PRDEXMBX-06.the-lab.llnl.gov>',NULL),('<1378355540.21486.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-05 12:32:20',28800,'2013-09-05 04:32:20',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\nSep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\nSep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\nSep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Wednesday, 4 September 2013 9:12 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>\n>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>\n>\n>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>\n>\n>swift-ring-builder account.builder reblanace\n>\n>\n>-Clay\n>\n>\n>\n>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>object.builder, build version 14\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>account.builder, build version 14\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>container.builder, build version 11\n>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>The minimum number of hours before a partition can be reassigned is 24\n>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>Starting account-server...(/etc/swift/account-server.conf)\n>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /auth/v1.0/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Auth-User:prag2648:pragya\n>>> X-Auth-Key:pj2648\n>>>?\n>>< HTTP/1.1 200 OK\n>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>< Content-Length: 0\n>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: 127.0.0.1:8080\n>>> Accept: */*\n>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>?\n>>< HTTP/1.1 503 Internal Server Error\n>>< Content-Length: 118\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>><?\n>>* Connection #0 to host 127.0.0.1 left intact\n>>* Closing connection #0\n>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>* ? Trying 127.0.0.1... Connection refused\n>>* couldn\'t connect to host\n>>* Closing connection #0\n>>curl: (7) couldn\'t connect to host\n>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>* About to connect() to localhost port 8080 (#0)\n>>* ? Trying 127.0.0.1... connected\n>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>> Host: localhost:8080\n>>> Accept: */*\n>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>?\n>>< HTTP/1.1 503 Internal Server Error\n>>< Content-Length: 118\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>><?\n>>* Connection #0 to host localhost left intact\n>>* Closing connection #0\n>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Hmm....?\n>>>\n>>>\n>>>1) No Container and Object servers are running?\n>>>2) Only one drive in the ring\n>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>4) Did you setup rsync yet ??\n>>>\n>>>\n>>>Maybe you can follow the online document to complete the above items.?\n>>>\n>>>\n>>>Good luck~\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>+Hugo Kuo+\n>>>hugo at swiftstack.com\n>>>\n>>>tonytkdk at gmail.com\n>>>\n>>>+886 935004793\n>>>\n>>>\n>>>\n>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>\n>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>/etc/swift/account.builder, build version 1\n>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>/etc/swift/container.builder, build version 1\n>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>/etc/swift/object.builder, build version 1\n>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>root at arun-Aspire-5742:~# df -h\n>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>/srv/node/d1:\n>>>>\n>>>>\n>>>>/srv/node/d2:\n>>>>\n>>>>\n>>>>/srv/node/d3:\n>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>Active Internet connections (servers and established)\n>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>ISHED 941/memcached ??\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>No container-updater running\n>>>>No account-auditor running\n>>>>No object-replicator running\n>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>No container-replicator running\n>>>>No object-auditor running\n>>>>No object-expirer running\n>>>>No container-auditor running\n>>>>No container-server running\n>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>No account-reaper running\n>>>>No container-sync running\n>>>>No account-replicator running\n>>>>No object-updater running\n>>>>No object-server running\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Hi Pragya :?\n>>>>>\n>>>>>\n>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>\n>>>>>\n>>>>>\n>>>>>Check rings :\n>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>\n>>>>>\n>>>>>Check Swift workers :?\n>>>>>$> swift-init all status\n>>>>>>$> ps aux | grep swift\n>>>>>>$> df -h?\n>>>>>>$> ls /srv/node/*\n>>>>>>$> netstat -antulp\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>+Hugo Kuo+\n>>>>>hugo at swiftstack.com\n>>>>>\n>>>>>tonytkdk at gmail.com\n>>>>>\n>>>>>+886 935004793\n>>>>>\n>>>>>\n>>>>>\n>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>\n>>>>>hello sir,\n>>>>>>\n>>>>>>\n>>>>>>I am working on single node.\n>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>Pragya\n>>>>>>>\n>>>>>>>\n>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>\n>>>>>>>\n>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>\n>>>>>>>Hi Pragya,?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>I need more information.?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Hugo Kuo\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>>hello sir,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>< Content-Length: 0\n>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>?\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>< Content-Length: 118\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Please help me in this regard.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>---\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Pragya Jain\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>\n>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>\n>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>\n>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>\n>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>\n>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>\n>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>\n>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>\n>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>\n>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>\n>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>\n>>>>>>>>>>>> -----\n>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>\n>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>\n>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>\n>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>\n>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>\n>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>\n>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>\n>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>\n>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>\n>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>\n>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>\n>>>>>>>>>>>> and then\n>>>>>>>>>>>>\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>\n>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>\n>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>\n>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>\n>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>\n>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>\n>>>>>>>>>>>> ---\n>>>>>>>>>>>>\n>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>\n>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> Hi \n>>>>>>>>>>>>\n>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>\n>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>\n>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>\n>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>\n>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>\n>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>\n>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>\n>>>>>>>>>>>> hello,\n>>>>>>>>>>>>\n>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>> For this,\n>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>\n>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>\n>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>\n>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>\n>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>\n>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>> ...\n>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>> ...\n>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>> ...\n>>>>>>>>>>>>\n>>>>>>>>>>>> save and exit\n>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>\n>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>\n>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>\n>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>> ---\n>>>>>>>>>>>>\n>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>\n>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>_______________________________________________\n>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>-- \n>>>>>>>\n>>>>>>>Gareth\n>>>>>>>\n>>>>>>>\n>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>OpenStack contributor\n>>>>>>>Company: UnitedStack\n>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130905/3bad8284/attachment.html>\n\n','<CA+_JKzoVgC2Gwicj7SwhD39wCL7fiWf_xoZvysAbLj72yMtSQA@mail.gmail.com>',NULL),('<1378396142.2340.132.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-05 16:49:02',3600,'2013-09-05 15:49:02',NULL,'[openstack-dev] [Nova] FFE Request: oslo-messaging','Hi\n\nOn Thu, 2013-09-05 at 10:43 -0400, Davanum Srinivas wrote:\n> Mark,\n> \n> Has this changeset get through a full tempest with QPid enabled?\n\nNo, I\'ve only done local testing with the qpid transport to date.\n\nI think Smokestack is the only CI tool actively testing the qpid driver.\nI ran out of time adding oslo.messaging to Smokestack before heading off\non vacation, but I expect I\'ll get to it next week.\n\nCheers,\nMark.\n\n\n> \n> thanks,\n> dims\n> \n> \n> On Thu, Sep 5, 2013 at 10:17 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > Hi\n> >\n> > I\'d like to request a feature freeze exception for the final (and\n> > admittedly the largest) patch in the series of 40 patches to port Nova to\n> > oslo.messaging:\n> >\n> >   https://review.openstack.org/39929\n> >\n> > While this change doesn\'t provide any immediate user-visible benefit, it\n> > would be massively helpful in maintaining momentum behind the effort all\n> > through the Havana cycle to move the RPC code from oslo-incubator into a\n> > library.\n> >\n> > In terms of risk of regression, there is certainly some risk but that risk\n> > is mitigated by the fact that the core code of each of the transport\n> > drivers has been modified minimally. The idea was to delay re-factoring\n> > these drivers until we were sure that we hadn\'t caused any regressions in\n> > Nova. The code has been happily passing the devstack/tempest based\n> > integration tests for 10 days now.\n> >\n> > Thanks,\n> > Mark.\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n> \n\n\n\n\n','<CANw6fcFOTou1s+a8pPnz3wiK3XThQ=D2yvOAdwhn1-LD02e21Q@mail.gmail.com>',NULL),('<1378396272.2340.135.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-05 16:51:12',3600,'2013-09-05 15:51:12',NULL,'[openstack-dev] [Nova] FFE Request: oslo-messaging','On Thu, 2013-09-05 at 11:00 -0400, Russell Bryant wrote:\n> On 09/05/2013 10:17 AM, Mark McLoughlin wrote:\n> > Hi\n> > \n> > I\'d like to request a feature freeze exception for the final (and\n> > admittedly the largest) patch in the series of 40 patches to port Nova\n> > to oslo.messaging:\n> > \n> >   https://review.openstack.org/39929\n> > \n> > While this change doesn\'t provide any immediate user-visible benefit, it\n> > would be massively helpful in maintaining momentum behind the effort all\n> > through the Havana cycle to move the RPC code from oslo-incubator into a\n> > library.\n> > \n> > In terms of risk of regression, there is certainly some risk but that\n> > risk is mitigated by the fact that the core code of each of the\n> > transport drivers has been modified minimally. The idea was to delay\n> > re-factoring these drivers until we were sure that we hadn\'t caused any\n> > regressions in Nova. The code has been happily passing the\n> > devstack/tempest based integration tests for 10 days now.\n> \n> When do you expect major refactoring to happen in oslo.messaging?  I get\n> that the current code was minimally modified, but I just want to\n> understand how the timelines line up with the release and ongoing\n> maintenance of the Havana release.\n\nYep, good question.\n\nAFAIR we discussed this at the last Oslo IRC meeting and decided that\nre-factoring will wait until Icehouse so we can more easily sync fixes\nfrom oslo-incubator to oslo.messaging.\n\nPorting Quantum, Cinder, Ceilometer and Heat, memoving the code from\noslo-incubator and re-factoring the drivers in oslo.messaging would be\ngoals for early on in the Icehouse cycle.\n\nCheers,\nMark.\n\n\n\n','<52289C75.1050404@redhat.com>',NULL),('<1378397580.9130.31.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-05 11:13:00',-18000,'2013-09-05 16:13:00',NULL,'[Openstack] Keystone \'NoneType\' object is unsubscriptable error','Robin,\n\nI would suggest opening a bug in launchpad, to let the project\nmaintainers know about this issue. I do not see any related bugs.\n\n=Bug=Search=====\nhttps://bugs.launchpad.net/keystone?field.searchtext=%27NoneType%27\n+object+is+unsubscriptable\n\n==New==Bug====\nhttps://bugs.launchpad.net/keystone/+filebug\n \n\n\n\nSean\n\n\nOn Thu, 2013-09-05 at 15:59 +0000, Goldstone, Robin J. wrote:\n> Sean,\n> \n> \n> It appears that the curl interface works just fine:\n> # brutus1 /root > curl -X POST -H \"X-Auth-Token:\n> 49c056f8688540fcb933cf7335537676\" -H \"Content-type: application/json\"\n> --data \'{\"OS-KSADM:service\":\n> {\"name\":\"Test\",\"type\":\"test\",\"extra\":\"{}\"}}\'\n> http://0.0.0.0:35357/v2.0/OS-KSADM/services\n> {\"OS-KSADM:service\": {\"type\": \"test\", \"name\": \"Test\", \"id\":\n> \"6d54ea4d2752435aba19893a9de24695\"}}\n> # brutus1 /root > curl -X GET -H \"X-Auth-Token:\n> 49c056f8688540fcb933cf7335537676\"\n> http://0.0.0.0:35357/v2.0/OS-KSADM/services\n> {\"OS-KSADM:services\": [{\"type\": \"test\", \"name\": \"Test\", \"id\":\n> \"6d54ea4d2752435aba19893a9de24695\"}]}\n> \n> \n> I also verified directly in the mysql database:\n> mysql> use keystone;\n> Reading table information for completion of table and column names\n> You can turn off this feature to get a quicker startup with -A\n> \n> \n> Database changed\n> mysql> select * from service;\n> +----------------------------------+------+------------------+\n> | id                               | type | extra            |\n> +----------------------------------+------+------------------+\n> | 6d54ea4d2752435aba19893a9de24695 | test | {\"name\": \"Test\"} |\n> +----------------------------------+------+------------------+\n> 1 row in set (0.00 sec)\n> \n> \n> mysql>\n> \n> \n> But access via the keystone client still fails with the same error:\n> # brutus1 /root > keystone service-list\n> \'NoneType\' object is unsubscriptable\n> \n> \n> -Robin\n> \n> \n> From: Sean McCully <sean_mccully at yahoo.com>\n> Reply-To: \"sean_mccully at yahoo.com\" <sean_mccully at yahoo.com>\n> Date: Wednesday, September 4, 2013 6:27 PM\n> To: \"Robin J. Goldstone\" <goldstone1 at llnl.gov>\n> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Keystone \'NoneType\' object is unsubscriptable\n> error\n> \n> \n> \n> What happens after you add a service,\n> \n> curl -X POST -H \"X-Auth-Token: <auth-token>\" -H \"Content-type:\n> application/json\" --data \'{\"OS-KSADM:service\":\n> {\"name\":\"Test\",\"type\":\"test\",\"extra\":\"{}\"}}\'\n> http://0.0.0.0:35357/v2.0/OS-KSADM/services\n> \n> \n> \n> Sean\n> \n> \n> On Thu, 2013-09-05 at 00:39 +0000, Goldstone, Robin J. wrote: \n> \n> > I am trying to install the RDO OpenStack distribution on a RHEL 6.4\n> > system.  The install is failing during keystone configuration as\n> > follows:\n> > ^[[1;35merr: /Stage[main]/Cinder::Keystone::Auth/Keystone_service[cinder]: Could not evaluate: Execution of \'/usr/bin/keystone --endpoint http://127.0.0.1:35357/v2.0/ service-list\' returned 1: \'NoneType\' object is unsubscriptable\n> > \n> > \n> > If I run the command interactively I get the same error: \n> > # brutus1 /etc/keystone > export\n> > OS_SERVICE_TOKEN=49c056f8688540fcb933cf7335537676\n> > # brutus1 /etc/keystone > export\n> > OS_SERVICE_ENDPOINT=http://127.0.0.1:35357/v2.0 \n> > # brutus1 /etc/keystone > keystone service-list \n> > \'NoneType\' object is unsubscriptable \n> > \n> > \n> > The keystone service appears to be running and connected to the\n> > mysql database:\n> > # brutus1 /root > ps -ef|grep keystone \n> > keystone  8451     1  0 17:20 ?\n> >  00:00:00 /usr/bin/python /usr/bin/keystone-all\n> > --config-file /etc/keystone/keystone.conf\n> > # brutus1 /root > lsof -i|grep keystone \n> > keystone- 8451 keystone    4u  IPv4  21614      0t0  TCP *:35357\n> > (LISTEN)\n> > keystone- 8451 keystone    6u  IPv4  21616      0t0  TCP\n> > *:commplex-main (LISTEN)\n> > keystone- 8451 keystone    8u  IPv4  21961      0t0  TCP\n> > ebrutus1:54531->ebrutus1:mysql (ESTABLISHED)\n> > \n> > \n> > The mysql database appears to have been properly initialized though\n> > hardly any of the tables have anything in them.\n> > \n> > \n> > mysql> use keystone; \n> > Reading table information for completion of table and column names\n> > You can turn off this feature to get a quicker startup with -A\n> > \n> > \n> > Database changed \n> > mysql> show tables; \n> > +------------------------+ \n> > | Tables_in_keystone     | \n> > +------------------------+ \n> > | credential             | \n> > | domain                 | \n> > | ec2_credential         | \n> > | endpoint               | \n> > | group                  | \n> > | group_domain_metadata  | \n> > | group_project_metadata | \n> > | migrate_version        | \n> > | policy                 | \n> > | project                | \n> > | role                   | \n> > | service                | \n> > | token                  | \n> > | trust                  | \n> > | trust_role             | \n> > | user                   | \n> > | user_domain_metadata   | \n> > | user_group_membership  | \n> > | user_project_metadata  | \n> > +------------------------+ \n> > 19 rows in set (0.00 sec) \n> > \n> > \n> > mysql> select * from service; \n> > Empty set (0.00 sec) \n> > \n> > \n> > I cranked up the debug level in the keystone log file and here is\n> > what I see:\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > ******************** REQUEST ENVIRON ********************\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SCRIPT_NAME\n> > = /v2.0\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > webob.adhoc_attrs = {\'response\': <Response at 0x2373510 200 OK>}\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] REQUEST_METHOD =\n> > GET\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] PATH_INFO\n> > = /OS-KSADM/services\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_PROTOCOL\n> > = HTTP/1.0\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > HTTP_X_AUTH_TOKEN = 49c056f8688540fcb933cf7335537676\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_USER_AGENT\n> > = python-keystoneclient\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > eventlet.posthooks = []\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_NAME =\n> > 127.0.0.1\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] REMOTE_ADDR =\n> > 127.0.0.1\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] eventlet.input =\n> > <eventlet.wsgi.Input object at 0x236b8d0>\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.url_scheme\n> > = http\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] SERVER_PORT =\n> > 35357\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.input =\n> > <eventlet.wsgi.Input object at 0x236b8d0>\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_HOST =\n> > 127.0.0.1:35357\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.multithread\n> > = True\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] HTTP_ACCEPT =\n> > */*\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.version =\n> > (1, 0)\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > openstack.context = {\'token_id\': \'49c056f8688540fcb933cf7335537676\',\n> > \'is_admin\': True}\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > GATEWAY_INTERFACE = CGI/1.1\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.run_once =\n> > False\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] wsgi.errors =\n> > <open file \'<stderr>\', mode \'w\' at 0x2aaaaaae81e0>\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > wsgi.multiprocess = False\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] CONTENT_TYPE =\n> > text/plain\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > HTTP_ACCEPT_ENCODING = identity, deflate, compress, gzip\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] \n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > ******************** REQUEST BODY ********************\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] \n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] arg_dict: {}\n> > 2013-09-04 17:37:48     INFO [sqlalchemy.engine.base.Engine] SELECT\n> > service.id AS service_id, service.type AS service_type,\n> > service.extra AS service_extra\n> > FROM service \n> > 2013-09-04 17:37:48     INFO [sqlalchemy.engine.base.Engine] ()\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > ******************** RESPONSE HEADERS ********************\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Vary =\n> > X-Auth-Token\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Content-Type =\n> > application/json\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] Content-Length =\n> > 25\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi] \n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > ******************** RESPONSE BODY ********************\n> > 2013-09-04 17:37:48    DEBUG [keystone.common.wsgi]\n> > {\"OS-KSADM:services\": []}\n> > 2013-09-04 17:37:48     INFO [access] 127.0.0.1 - -\n> > [05/Sep/2013:00:37:48 +0000] \"GET\n> > http://127.0.0.1:35357/v2.0/OS-KSADM/services HTTP/1.0\" 200 25\n> > 2013-09-04 17:37:48    DEBUG [eventlet.wsgi.server] 127.0.0.1 - -\n> > [04/Sep/2013 17:37:48] \"GET /v2.0/OS-KSADM/services HTTP/1.1\" 200\n> > 153 0.008193\n> > \n> > \n> > \n> > \n> > I have tried completely wiping out and reinstalling RDO but it\n> > chokes at the same point.   Myself, along with several other people,\n> > have reported this error on the RDO forum but no one over there has\n> > responded so I thought I would try my luck over here.  If anyone has\n> > an idea of what my problem is, or can offer advice on further\n> > troubleshooting, please let me know.  \n> > \n> > \n> > Thank you in advance. \n> > Robin Goldstone, LLNL \n> > \n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130905/1e0dea2c/attachment.html>\n\n','<D17A8FDF3CC59847983F6B75C05DB38B15483D@PRDEXMBX-06.the-lab.llnl.gov>',NULL),('<1378411114-sup-8934@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-05 12:59:41',-25200,'2013-09-05 19:59:41',NULL,'[Openstack] Instance CPU frequency resizing','Hi Batsayan, welcome to the OpenStack list! :)\n\nPlease don\'t hijack threads, it creates a lot of confusion, and many\npeople will not even see your message as they may have already filtered\nout the thread.\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette#Threading\n\nInstead, start a new thread by emailing a new message to\nopenstack at lists.openstack.org.\n\nThanks!\n\nExcerpts from Batsayan Das\'s message of 2013-09-04 20:18:38 -0700:\n>  Hi,\n> \n> In my test scenario, I need two medium ubuntu instance. The only difference between the instances is CPU frequency. For example instance1\'s CPU operates at 2GHz, whereas instance2\'s CPU operates at 1GHz.? \n> Is it possible to do this cpu frequency control through openstack/devstack?\n> \n> Regards,\n> Batsayan Das\n> Tata Consultancy Services\n> Mailto: batsayan.das at tcs.com\n> Website: http://www.tcs.com\n> ____________________________________________\n> Experience certainty.    IT Services\n>             Business Solutions\n>             Consulting\n\n\n','<OFF5C1E60F.D280B183-ON65257BDD.00122F75-65257BDD.00122F77@tcs.com>',NULL),('<1378421046.860730706@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-05 17:44:06',-18000,'2013-09-05 22:44:06',NULL,'[openstack-community] Compute Midwest','\nIs anyone, in addition to Chris Kemp (thank you, Chris!), participating in [http://computemidwest.com/] Compute Midwest in Kansas City October 25-27?  If you are interested in presenting or facilitating OpenStack exercises during the 24 hour Hackathon, please contact the organizer directly at [http://www.kcitp.com/about/contact/] http://www.kcitp.com/about/contact/ and cc me.  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130905/b56e3e47/attachment.html>\n\n',NULL,NULL),('<1378442357.82006.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-06 12:39:17',28800,'2013-09-06 04:39:17',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','please help me in this regard.\n\n\n\n>________________________________\n> From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Clay Gerrard <clay.gerrard at gmail.com> \n>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 5 September 2013 10:02 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>\n>\n>\n>\n>\n>>________________________________\n>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>> \n>>\n>>\n>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>\n>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>\n>>\n>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>\n>>\n>>swift-ring-builder account.builder reblanace\n>>\n>>\n>>-Clay\n>>\n>>\n>>\n>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>object.builder, build version 14\n>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>The minimum number of hours before a partition can be reassigned is 24\n>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>account.builder, build version 14\n>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>The minimum number of hours before a partition can be reassigned is 24\n>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>container.builder, build version 11\n>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>The minimum number of hours before a partition can be reassigned is 24\n>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /auth/v1.0/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Auth-User:prag2648:pragya\n>>>> X-Auth-Key:pj2648\n>>>>?\n>>>< HTTP/1.1 200 OK\n>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>< Content-Length: 0\n>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: 127.0.0.1:8080\n>>>> Accept: */*\n>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>?\n>>>< HTTP/1.1 503 Internal Server Error\n>>>< Content-Length: 118\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>><?\n>>>* Connection #0 to host 127.0.0.1 left intact\n>>>* Closing connection #0\n>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>* ? Trying 127.0.0.1... Connection refused\n>>>* couldn\'t connect to host\n>>>* Closing connection #0\n>>>curl: (7) couldn\'t connect to host\n>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>* About to connect() to localhost port 8080 (#0)\n>>>* ? Trying 127.0.0.1... connected\n>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>> Host: localhost:8080\n>>>> Accept: */*\n>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>?\n>>>< HTTP/1.1 503 Internal Server Error\n>>>< Content-Length: 118\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>><?\n>>>* Connection #0 to host localhost left intact\n>>>* Closing connection #0\n>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>Hmm....?\n>>>>\n>>>>\n>>>>1) No Container and Object servers are running?\n>>>>2) Only one drive in the ring\n>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>4) Did you setup rsync yet ??\n>>>>\n>>>>\n>>>>Maybe you can follow the online document to complete the above items.?\n>>>>\n>>>>\n>>>>Good luck~\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>+Hugo Kuo+\n>>>>hugo at swiftstack.com\n>>>>\n>>>>tonytkdk at gmail.com\n>>>>\n>>>>+886 935004793\n>>>>\n>>>>\n>>>>\n>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>/etc/swift/account.builder, build version 1\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>/etc/swift/container.builder, build version 1\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>/etc/swift/object.builder, build version 1\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>/srv/node/d1:\n>>>>>\n>>>>>\n>>>>>/srv/node/d2:\n>>>>>\n>>>>>\n>>>>>/srv/node/d3:\n>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>Active Internet connections (servers and established)\n>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>ISHED 941/memcached ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>No container-updater running\n>>>>>No account-auditor running\n>>>>>No object-replicator running\n>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>No container-replicator running\n>>>>>No object-auditor running\n>>>>>No object-expirer running\n>>>>>No container-auditor running\n>>>>>No container-server running\n>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>No account-reaper running\n>>>>>No container-sync running\n>>>>>No account-replicator running\n>>>>>No object-updater running\n>>>>>No object-server running\n>>>>>\n>>>>>\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>Hi Pragya :?\n>>>>>>\n>>>>>>\n>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Check rings :\n>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>\n>>>>>>\n>>>>>>Check Swift workers :?\n>>>>>>$> swift-init all status\n>>>>>>>$> ps aux | grep swift\n>>>>>>>$> df -h?\n>>>>>>>$> ls /srv/node/*\n>>>>>>>$> netstat -antulp\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>+Hugo Kuo+\n>>>>>>hugo at swiftstack.com\n>>>>>>\n>>>>>>tonytkdk at gmail.com\n>>>>>>\n>>>>>>+886 935004793\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>>hello sir,\n>>>>>>>\n>>>>>>>\n>>>>>>>I am working on single node.\n>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Pragya\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>\n>>>>>>>>Hi Pragya,?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I need more information.?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Hugo Kuo\n>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>\n>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>\n>>>>>>>>>+886 935004793\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>\n>>>>>>>>>hello sir,\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>?\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>---\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Pragya Jain\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>\n>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> -----\n>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>\n>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>> ...\n>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>> ...\n>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>_______________________________________________\n>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>-- \n>>>>>>>>\n>>>>>>>>Gareth\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>OpenStack contributor\n>>>>>>>>Company: UnitedStack\n>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130906/f26e6b45/attachment.html>\n\n','<1378355540.21486.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1378470622.2340.162.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-06 13:30:22',3600,'2013-09-06 12:30:22',NULL,'[openstack-dev] [Nova] FFE Request: oslo-messaging','On Fri, 2013-09-06 at 10:59 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > I\'d like to request a feature freeze exception for the final (and\n> > admittedly the largest) patch in the series of 40 patches to port Nova\n> > to oslo.messaging:\n> > \n> >   https://review.openstack.org/39929\n> \n> I\'m generally adverse to granting feature freeze exceptions to code\n> refactoring: the user benefit of having them in the release is\n> inexistent, while they introduce some risk by changing deep code\n> relatively late in the cycle. That\'s why I prefer those to be targeted\n> to earlier development milestones, this avoids having to make hard calls\n> once all the work is done and almost completed.\n\nYes, absolutely understood.\n\nTo be clear - while I think there\'s a strong case for an exception here,\nI am very close to this, so I would be cool with a denial of this\nrequest.\n\n> That said, if the risk is under control and the patch is ready to merge,\n> I\'m fine with this as long as there is some other benefits in having it\n> *in* the release rather than landed first thing in icehouse.\n> \n> Would having it *in* the release facilitate stable/havana branch\n> maintenance, for example ?\n> \n> > While this change doesn\'t provide any immediate user-visible benefit, it\n> > would be massively helpful in maintaining momentum behind the effort all\n> > through the Havana cycle to move the RPC code from oslo-incubator into a\n> > library.\n> \n> Could you expand on why this would be a lot more helpful to have it in\n> the release rather than early in icehouse ?\n> \n> And to have all cards on the table, how much sense would the alternative\n> make (i.e. not land this final patch while a lot of this feature code\n> has already been merged) ?\n\nIf the patch was merged now, while it\'s not a user-visible feature\nper-se, I think oslo.messaging is something we would celebrate in the\nHavana release e.g.\n\n  While OpenStack continues to add new projects and developers while, \n  in parallel, aggressively takes steps to enable the project to scale. \n  The oslo.messaging library added in the Havana release is an example \n  of where code which was previously copied and pasted between projects \n  and has now been re-factored out into a shared library with a clean \n  API. This library will provide a structured way for OpenStack \n  projects to collaborate on adopting new messaging patterns and \n  features without the disruption of incompatible API changes nor the \n  pain of keeping copied and pasted code in sync.\n\nObviously, as Oslo PTL, I think this is an important theme that we\nshould continue to emphasise and build momentum around. The messaging\nlibrary is by far the most significant example so far of how this\nprocess of creating libraries can be effective. Nova using the library\nin the Havana release would (IMHO) be the signal that this process is\nworking and hopefully inspire others to take a similar approach with\nother chunks of common code.\n\nConversely, if we delayed merging this code until Icehouse, I think it\nwould leave somewhat of a question mark hanging over oslo.messaging and\nOslo going into the summit:\n\n  Is this oslo.messaging thing for real? Or will it be abandoned and we\n  need to continue with the oslo-incubator RPC code? Why is it taking so\n  long to create these libraries? This sucks!\n\nThat\'s all very meta, I know. But I do really believe making progress\nwith Oslo libraries is important for OpenStack long-term. While it\'s not\na user-visible benefit per-se, I do think this work benefits the project\nbroadly and is also something worth marketing.\n\nWe measure our progress in terms of what we achieved in each release\ncycle. I think we\'ve made great progress on oslo.messaging in Havana,\nbut unless a project uses it in the release it won\'t be something we\nreally celebrate until Icehouse.\n\nIf we agree the risk is manageable, I hope the above shows there is\nample benefit in comparison to the risk.\n\nThanks,\nMark.\n\n\n\n','<52299987.9010503@openstack.org>',NULL),('<1378499260-sup-8404@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-06 13:49:28',-25200,'2013-09-06 20:49:28',NULL,'[openstack-dev] [tripleo] Scaling of TripleO','Excerpts from James Slagle\'s message of 2013-09-06 10:27:32 -0700:\n> The purpose of this email is to brainstorm some ideas about how TripleO could\n> be scaled out for large deployments.\n> \n\nThanks for thinking this through and taking the time to vet the ideas\nTripleO has presented thus far.\n\n> Idea 0\n> ------\n> According to what we\'ve read (and watched), the TripleO idea is that you\'re\n> going to have a single undercloud composed of at least 2 machines running the\n> undercloud services (nova, glance, keystone, neutron, rabbitmq, mysql) in HA\n> mode. The way you would add horizontal scale to this model is by adding more\n> undercloud machines running the same stack of services in HA mode, so they\n> could share the workload.\n> \n> Does this match others current thinking about TripleO at scale?\n> \n> I attempted to diagram this idea at [1].  Sorry, if it\'s a bit crude :).  A\n> couple points to mention about the diagram:\n>  * it\'s showing scalability as opposed to full HA. there\'s a shared message\n>    bus, would be shared db\'s, a load balancer in front of API services, etc.\n>  * For full HA, you can add additional nodes that didn\'t share single points of\n>    failures (like the bus).\n\nI\'m not sure I agree that the bus is a SPOF. Both qpid and rabbit+kombu can\noperate in HA active/active mode, so why would those be SPOFs? Certainly\nnot a _likely_ SPOF.\n\n>  * The green lines are meant to show the management network domain, and can be\n>    thought of roughly as \"managed by\".\n>  * Logical Rack is just meant to imply \"a grouping of baremetal hardware\".  It\n>    might be a physical rack, but it doesn\'t have to be.\n>  * Just of note, there\'s a box there representing where we feel Tuskar would\n>    get plugged in.\n> \n> Pros/Cons (+/-):\n> + Easy to install (You start with only one machine in the\n>   datacenter  running the whole stack of services in HA mode and from there you\n>   can  just expand it to another machine, enroll the rest of the\n> machines in  the\n>   datacenter and you\'re ready to go.)\n> + Easy to upgrade (Since we have fully HA, you could then turn off one machine\n>   in the control plane triggering a HA failover, update that machine, bring it\n>   up, turn off another machine in the control plane,  etc...)\n> - Every node in the overcloud has to be able to talk back to controller rack\n>   (e.g. heat/nova)\n\nNote that this is just OpenStack\'s architecture. Heat and Nova both\nhave separated their API from their smarts to make it very straight\nforward to isolate tenant access from deeper resources. So each node\njust needs access to nova and heat API endpoints, and both in very\nlimited, predictable capacities. I think that mitigates this to a very\nminor concern.\n\n> - Possible performance issues when bringing up a large number of machines.\n>   (think hyperscale).\n\nThis is perhaps the largest concern, but is why we\'ve always suggested\nthat eventually the scaled out compute boxes will work better with some\nhardware affinity.\n\n> - Large failure domain.  If the HA cluster fails, you\'ve lost all visibility\n>   into and management of the infrastructure.\n\nThe point of HA is to make the impact and frequency of these failures\nvery small. So this one is also mitigated by \"doing HA well\".\n\n> - What does the IPMI network look like in this model?  Can we assume full IPMI\n>   connectivity across racks, logical or physical?\n> \n\nUndercloud compute needs to be able to access IPMI. The current nova\nbaremetal requires assigning specific hardware to specific compute nodes,\nso each rack can easily get its own compute node.\n\n> In addition, here are a couple of other ideas to bring to the conversation.\n> Note that all the ideas assume 1 Overcloud.\n> \n> Idea 1\n> ------\n> The thought here is to have 1 Undercloud again, but be able to deploy N\n> Undercloud Leaf Nodes as needed for scale.  The Leaf Node is a smaller subset\n> of services than what is needed on the full Undercloud Node.  Essentially, it\n> is enough services to do baremetal provisioning, Heat orchestration, and\n> Neutron for networking.  Diagram of this idea is at [2].  In the diagram, there\n> is one Leaf Node per logical rack.\n> \n\nI think this is very close to the near-term evolution I\'ve been thinking\nabout for TripleO. We want to get good at deploying a simple architecture\nfirst, but then we know we don\'t need to be putting the heat engines,\nnova schedulers, etc, on every scale-out box in the undercloud.\n\n> In this model, the Undercloud provisions and deploys Leaf Nodes as needed when\n> new hardware is added to the environment.  The Leaf Nodes then handle\n> deployment requests from the Undercloud for the Overcloud nodes.\n> \n> As such, there is some scalability built into the architecture in a distributed\n> fashion.  Adding more scalability and HA would be accomplished in a similar\n> fashion to Idea 0, by adding additional HA Leaf Nodes, etc.\n> \n> Pros/Cons (+/-):\n> + As scale is added with more Leaf Nodes, it\'s a smaller set of services.\n> - Additional image management of the Leaf Node image\n\nI think if you\'ve accepted image management for 3 images (undercloud,\novercloud-control, overcloud-compute), adding one more is not such a\ndaunting thing. The benefit is that there is less software running that\nmay break your services.\n\n> - Additional rack space wasted for the Leaf Node\n\nThis is unavoidable for scale-out IMO. There is certainly a scenario where\nwe can convert some of these to overcloud resources after an initial data center\nbring-up, so that also mitigates the impact.\n\n> + Smaller failure domain as the logical rack is only dependent on the Leaf\n>   Node.\n> + The ratio of HA Management Nodes would be smaller because of the offloaded\n>   services.\n\nI\'m not sure I follow what an \"HA Management Node\" is.\n\n> + Better security due to IPMI/RMCP isolation within the rack.\n> \n> Idea 2\n> ------\n> In this idea, there are N Underclouds, each with the full set of Undercloud\n> services.  As new hardware is brought online, an Undercloud is deployed (if\n> desired) for scalability.  Diagram for this idea is at [3].\n> \n> A single Control Undercloud handles deployment and provisioning of the other\n> Underclouds.  This is similar to the seed vm concept of TripleO for Undercloud\n> deployment.  However, in this model, the Control Undercloud is not meant to be\n> short lived or go away, so we didn\'t want to call this the seed directly.\n> \n> Again, HA can be added in a similar fashion to the other ideas.\n> \n> In a way, this idea is not all that different from Idea 0.  It could be thought\n> of as using an Idea 0 to deploy other Idea 0\'s.  However, it allows for some\n> additional constraints around network and security with the isolation of each\n> Undercloud in the logical rack.\n> \n> Pros/Cons (+/-):\n> + network/security isolation\n> - multiple Undercloud complexity\n\nThis is probably the main reason I am skeptical at this idea. We\nshouldn\'t have to make a whole new cloud/region/etc. just to scale what\nis essentially a homogeneous service. It adds management complexity,\nand complexity is far worse than a small amount of image management\n(which seems to be main difference between 1 and 2).\n\nAll great ideas, thanks for sharing!\n\n\n','<CAHV77z9anUZ1fqkfik8WbeoxTP=M9nAGOSguvNZ9erVHg38roQ@mail.gmail.com>',NULL),('<1378529123.39925.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-07 04:45:34',0,'2013-09-07 04:45:34',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir,\n\nI did the following job:\n\nroot at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n\nmount: no such partition found\nroot at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\nmount: no such partition found\nroot at arun-Aspire-5742:~# cd /opt/swift/etc\nroot at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\nmount: no such partition found\nroot at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\nmount: no such partition found\nroot at arun-Aspire-5742:/opt/swift/etc# cd ~\nroot at arun-Aspire-5742:~# mount d1 /srv/node/d1\nmount: special device d1 does not exist\nroot at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\nroot at arun-Aspire-5742:~# mount d1 /srv/node/d1\nmount: special device d1 does not exist\nroot at arun-Aspire-5742:~# cd /opt/swift/etc\nroot at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\nmount: special device d1 does not exist\nroot at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n\nroot at arun-Aspire-5742:~# mount\n/dev/sda4 on / type ext4 (rw,errors=remount-ro)\nproc on /proc type proc (rw,noexec,nosuid,nodev)\nsysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\nnone on /sys/fs/fuse/connections type fusectl (rw)\nnone on /sys/kernel/debug type debugfs (rw)\nnone on /sys/kernel/security type securityfs (rw)\nudev on /dev type devtmpfs (rw,mode=0755)\ndevpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\ntmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\nnone on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\nnone on /run/shm type tmpfs (rw,nosuid,nodev)\ngvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n\nI am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 6 September 2013 8:58 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>\n>\n>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>\n>\n>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>\n>\n>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>\n>\n>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>\n>\n>\n>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>please help me in this regard.\n>>\n>>\n>>\n>>>________________________________\n>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>\n>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>\n>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>\n>>>>\n>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>\n>>>>\n>>>>swift-ring-builder account.builder reblanace\n>>>>\n>>>>\n>>>>-Clay\n>>>>\n>>>>\n>>>>\n>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>object.builder, build version 14\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>account.builder, build version 14\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>container.builder, build version 11\n>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Auth-User:prag2648:pragya\n>>>>>> X-Auth-Key:pj2648\n>>>>>>?\n>>>>>< HTTP/1.1 200 OK\n>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>< Content-Length: 0\n>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: 127.0.0.1:8080\n>>>>>> Accept: */*\n>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>?\n>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>< Content-Length: 118\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>><?\n>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>* Closing connection #0\n>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>* couldn\'t connect to host\n>>>>>* Closing connection #0\n>>>>>curl: (7) couldn\'t connect to host\n>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>* ? Trying 127.0.0.1... connected\n>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>> Host: localhost:8080\n>>>>>> Accept: */*\n>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>?\n>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>< Content-Length: 118\n>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>><?\n>>>>>* Connection #0 to host localhost left intact\n>>>>>* Closing connection #0\n>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>Hmm....?\n>>>>>>\n>>>>>>\n>>>>>>1) No Container and Object servers are running?\n>>>>>>2) Only one drive in the ring\n>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>4) Did you setup rsync yet ??\n>>>>>>\n>>>>>>\n>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>\n>>>>>>\n>>>>>>Good luck~\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>+Hugo Kuo+\n>>>>>>hugo at swiftstack.com\n>>>>>>\n>>>>>>tonytkdk at gmail.com\n>>>>>>\n>>>>>>+886 935004793\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>\n>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>/srv/node/d1:\n>>>>>>>\n>>>>>>>\n>>>>>>>/srv/node/d2:\n>>>>>>>\n>>>>>>>\n>>>>>>>/srv/node/d3:\n>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>Active Internet connections (servers and established)\n>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>ISHED 941/memcached ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>No container-updater running\n>>>>>>>No account-auditor running\n>>>>>>>No object-replicator running\n>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>No container-replicator running\n>>>>>>>No object-auditor running\n>>>>>>>No object-expirer running\n>>>>>>>No container-auditor running\n>>>>>>>No container-server running\n>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>No account-reaper running\n>>>>>>>No container-sync running\n>>>>>>>No account-replicator running\n>>>>>>>No object-updater running\n>>>>>>>No object-server running\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Hi Pragya :?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Check rings :\n>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Check Swift workers :?\n>>>>>>>>$> swift-init all status\n>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>$> df -h?\n>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>$> netstat -antulp\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>+Hugo Kuo+\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>>hello sir,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I am working on single node.\n>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Pragya\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>\n>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>\n>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>\n>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>\n>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>?\n>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>><?\n>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>?\n>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>><?\n>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>---\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>\n>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>-- \n>>>>>>>>>>\n>>>>>>>>>>Gareth\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>_______________________________________________\n>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 7.png\nType: image/png\nSize: 235590 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0007.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 8.png\nType: image/png\nSize: 245769 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0008.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 9.png\nType: image/png\nSize: 218571 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0009.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 10.png\nType: image/png\nSize: 223820 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0010.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 11.png\nType: image/png\nSize: 203445 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0011.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 12.png\nType: image/png\nSize: 205103 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0012.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot 13.png\nType: image/png\nSize: 210400 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130907/91cb1b5d/attachment-0013.png>\n\n','<CA+_JKzou=5NsA9PkbtJvyDvCt6oXFWDUE+NYx6bn_e_5RxgKNA@mail.gmail.com>',NULL),('<1378657960.37178.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-09 00:32:40',28800,'2013-09-08 16:32:40',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:~# cat /proc/partitions\nmajor minor ?#blocks ?name\n\n? ?8 ? ? ? ?0 ?488386584 sda\n? ?8 ? ? ? ?1 ? ? 102400 sda1\n? ?8 ? ? ? ?2 ?102294528 sda2\n? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n? ?8 ? ? ? ?4 ?180702208 sda4\n? ?8 ? ? ? ?5 ?102398278 sda5\n? ?8 ? ? ? ?6 ?102398278 sda6\n? ?8 ? ? ? ?7 ? ? 487424 sda7\n? 11 ? ? ? ?0 ? ?1048575 sr0\n? 11 ? ? ? ?1 ? ? ?99328 sr1\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Saturday, 7 September 2013 9:50 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>\n>\n>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>\n>\n>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>\n>\n>That should be:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>\n>\n>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>\n>\n>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>\n>\n>`sudo mkfs.xfs -L d1 /dev/sdb`\n>`sudo mkfs.xfs -L d2 /dev/sdc`\n>\n>`sudo mkfs.xfs -L d3 /dev/sdd`\n>\n>\n>\n>and maybe:\n>\n>\n>`sudo mkfs.xfs -L d4 /dev/sde`\n>\n>\n>\n>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>\n>\n>\n>\n>\n>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>I did the following job:\n>>\n>>\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>\n>>\n>>root at arun-Aspire-5742:~# mount\n>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>none on /sys/kernel/debug type debugfs (rw)\n>>none on /sys/kernel/security type securityfs (rw)\n>>udev on /dev type devtmpfs (rw,mode=0755)\n>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>\n>>\n>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>\n>>>\n>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>\n>>>\n>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>\n>>>\n>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>\n>>>\n>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>\n>>>\n>>>\n>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>please help me in this regard.\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>\n>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>\n>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>\n>>>>>>\n>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>\n>>>>>>\n>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>\n>>>>>>\n>>>>>>-Clay\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>object.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>account.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>container.builder, build version 11\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Hmm....?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>2) Only one drive in the ring\n>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Good luck~\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>+Hugo Kuo+\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>/srv/node/d1:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d2:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d3:\n>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>No container-updater running\n>>>>>>>>>No account-auditor running\n>>>>>>>>>No object-replicator running\n>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>No container-replicator running\n>>>>>>>>>No object-auditor running\n>>>>>>>>>No object-expirer running\n>>>>>>>>>No container-auditor running\n>>>>>>>>>No container-server running\n>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>No account-reaper running\n>>>>>>>>>No container-sync running\n>>>>>>>>>No account-replicator running\n>>>>>>>>>No object-updater running\n>>>>>>>>>No object-server running\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check rings :\n>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>\n>>>>>>>>>>+886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>-- \n>>>>>>>>>>>>\n>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>_______________________________________________\n>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130909/d2f8dfba/attachment.html>\n\n','<CA+_JKzpENJixGP8Fc90TsbmEv4z98H3hQ=cmg2VB2Yhy7zhhQw@mail.gmail.com>',NULL),('<1378671166.323.1359010031121.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-24 06:47:10',0,'2013-01-24 06:47:10',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #77','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/77/>\n\n------------------------------------------\n[...truncated 16813 lines...]\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_confirming (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 124, in test_create_image_when_vm_eq_resized_task_eq_resize_confirming\n    self._test_create_image_409_base(\"resized\", \"resize_confirming\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_finish (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 116, in test_create_image_when_vm_eq_resized_task_eq_resize_finish\n    self._test_create_image_409_base(\"resized\", \"resize_finish\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_migrated (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 112, in test_create_image_when_vm_eq_resized_task_eq_resize_migrated\n    self._test_create_image_409_base(\"resized\", \"resize_migrated\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_migrating (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 108, in test_create_image_when_vm_eq_resized_task_eq_resize_migrating\n    self._test_create_image_409_base(\"resized\", \"resize_migrating\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'task_state\': \'NULL\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_prep (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 104, in test_create_image_when_vm_eq_resized_task_eq_resize_prep\n    self._test_create_image_409_base(\"resized\", \"resize_prep\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test_create_image_when_vm_eq_resized_task_eq_resize_reverting (tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 120, in test_create_image_when_vm_eq_resized_task_eq_resize_reverting\n    self._test_create_image_409_base(\"resized\", \"resize_reverting\")\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 80, in _test_create_image_409_base\n    self.update_state(self.shared_server[\'id\'], \'active\', None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.compute.images.test_images_whitebox.ImagesWhiteboxTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 227, in run\n    self.tearDown()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 350, in tearDown\n    self.teardownContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 366, in teardownContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 42, in tearDownClass\n    cls.update_state(server[\'id\'], \"active\", None)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images_whitebox.py\", line 64, in update_state\n    self.connection.execute(stmt, autocommit=True)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1449, in execute\n    params)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1584, in _execute_clauseelement\n    compiled_sql, distilled_params\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1698, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1691, in _execute_context\n    context)\n  File \"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py\", line 331, in do_execute\n    cursor.execute(statement, parameters)\nProgrammingError: (ProgrammingError) column \"deleted\" is of type integer but expression is of type boolean\nLINE 1: ...SET vm_state=\'active\', task_state=\'NULL\', deleted=false WHER...\n                                                             ^\nHINT:  You will need to rewrite or cast the expression.\n \'UPDATE instances SET vm_state=%(vm_state)s, task_state=%(task_state)s, deleted=%(deleted)s WHERE instances.uuid = %(uuid_1)s\' {\'deleted\': False, \'vm_state\': \'active\', \'uuid_1\': u\'a82df58a-719e-46da-b002-294d3ea1aae6\', \'task_state\': \'NULL\'}\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 573 tests in 1512.938s\n\nFAILED (SKIP=70, errors=25)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/rabbitmq/rabbit at devstack-1358985706-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/rabbitmq/rabbit at devstack-1358985706.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/77/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1976825158.302.1358923019758.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1378700314.31551.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-09 12:18:34',28800,'2013-09-09 04:18:34',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','root at arun-Aspire-5742:~# cat /proc/partitions\nmajor minor ?#blocks ?name\n\n? ?8 ? ? ? ?0 ?488386584 sda\n? ?8 ? ? ? ?1 ? ? 102400 sda1\n? ?8 ? ? ? ?2 ?102294528 sda2\n? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n? ?8 ? ? ? ?4 ?180702208 sda4\n? ?8 ? ? ? ?5 ?102398278 sda5\n? ?8 ? ? ? ?6 ?102398278 sda6\n? ?8 ? ? ? ?7 ? ? 487424 sda7\n? 11 ? ? ? ?0 ? ?1048575 sr0\n? 11 ? ? ? ?1 ? ? ?99328 sr1\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sdb\nmkfs.xfs: cannot open /dev/sdb: No medium found\n\npleases reply.\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Saturday, 7 September 2013 9:50 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>\n>\n>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>\n>\n>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>\n>\n>That should be:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>\n>\n>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>\n>\n>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>\n>\n>`sudo mkfs.xfs -L d1 /dev/sdb`\n>`sudo mkfs.xfs -L d2 /dev/sdc`\n>\n>`sudo mkfs.xfs -L d3 /dev/sdd`\n>\n>\n>\n>and maybe:\n>\n>\n>`sudo mkfs.xfs -L d4 /dev/sde`\n>\n>\n>\n>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>\n>\n>\n>\n>\n>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>I did the following job:\n>>\n>>\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>\n>>\n>>root at arun-Aspire-5742:~# mount\n>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>none on /sys/kernel/debug type debugfs (rw)\n>>none on /sys/kernel/security type securityfs (rw)\n>>udev on /dev type devtmpfs (rw,mode=0755)\n>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>\n>>\n>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>\n>>>\n>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>\n>>>\n>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>\n>>>\n>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>\n>>>\n>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>\n>>>\n>>>\n>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>please help me in this regard.\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>\n>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>\n>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>\n>>>>>>\n>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>\n>>>>>>\n>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>\n>>>>>>\n>>>>>>-Clay\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>object.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>account.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>container.builder, build version 11\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Hmm....?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>2) Only one drive in the ring\n>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Good luck~\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>+Hugo Kuo+\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>/srv/node/d1:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d2:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d3:\n>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>No container-updater running\n>>>>>>>>>No account-auditor running\n>>>>>>>>>No object-replicator running\n>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>No container-replicator running\n>>>>>>>>>No object-auditor running\n>>>>>>>>>No object-expirer running\n>>>>>>>>>No container-auditor running\n>>>>>>>>>No container-server running\n>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>No account-reaper running\n>>>>>>>>>No container-sync running\n>>>>>>>>>No account-replicator running\n>>>>>>>>>No object-updater running\n>>>>>>>>>No object-server running\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check rings :\n>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>\n>>>>>>>>>>+886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>-- \n>>>>>>>>>>>>\n>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>_______________________________________________\n>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130909/31ee5649/attachment.html>\n\n','<CA+_JKzpENJixGP8Fc90TsbmEv4z98H3hQ=cmg2VB2Yhy7zhhQw@mail.gmail.com>',NULL),('<1378740889-sup-4360@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-09 08:38:18',-25200,'2013-09-09 15:38:18',NULL,'[Openstack] [openstack-dev] [TROVE] database instance creation','Excerpts from Michael Basnight\'s message of 2013-09-09 07:57:34 -0700:\n> On Sep 9, 2013, at 7:39 AM, Giuseppe Galeota <giuseppegaleota at gmail.com> wrote:\n> \n> > So, I think that \"Trove is designed to support a single-tenant database within a Nova instance\" is a misleading definition. What do you think?\n> \n> What exactly is misleading about that? Don\'t get me wrong, I\'ve been working on trove for a long time, so to me, the definition makes sense. But if its misleading for newcomers, lets work to make it sound less so!\n> \n> Also, removing openstack-dev list. This is more general question stuff that\'s suited for openstack mailing list. \n> \n\nThe misleading thing to me is that it sounds like I only get one database\nuser. As in, it creates an instance, spins up MySQL, and creates a single\ntenant inside the database.\n\nIt also is ambiguous enough that one might miss the significance of the\ndash and hear that it creates a single, tenant-database.\n\nAs nice as succinct descriptions are, it may be worth clarifying all of\nthe objects in the sentence.\n\nPerhaps: \"Trove is designed to support a multi-user database for a single\nOpenStack tenant within a Nova instance.\"\n\n\n','<FF27994E-333D-4CD9-89B4-722D252CC60D@gmail.com>',NULL),('<1378745268.85593.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 00:47:48',28800,'2013-09-09 16:47:48',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','hello sir\nroot at arun-Aspire-5742:~# cat /proc/partitions\nmajor minor ?#blocks ?name\n\n? ?8 ? ? ? ?0 ?488386584 sda\n? ?8 ? ? ? ?1 ? ? 102400 sda1\n? ?8 ? ? ? ?2 ?102294528 sda2\n? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n? ?8 ? ? ? ?4 ?180702208 sda4\n? ?8 ? ? ? ?5 ?102398278 sda5\n? ?8 ? ? ? ?6 ?102398278 sda6\n? ?8 ? ? ? ?7 ? ? 487424 sda7\n? 11 ? ? ? ?0 ? ?1048575 sr0\n? 11 ? ? ? ?1 ? ? ?99328 sr1\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sdb\nmkfs.xfs: cannot open /dev/sdb: No medium found\n\npleases help me.\n\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Saturday, 7 September 2013 9:50 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>\n>\n>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>\n>\n>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>\n>\n>That should be:\n>\n>\n>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>\n>\n>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>\n>\n>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>\n>\n>`sudo mkfs.xfs -L d1 /dev/sdb`\n>`sudo mkfs.xfs -L d2 /dev/sdc`\n>\n>`sudo mkfs.xfs -L d3 /dev/sdd`\n>\n>\n>\n>and maybe:\n>\n>\n>`sudo mkfs.xfs -L d4 /dev/sde`\n>\n>\n>\n>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>\n>\n>\n>\n>\n>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir,\n>>\n>>\n>>I did the following job:\n>>\n>>\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>mount: no such partition found\n>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>mount: special device d1 does not exist\n>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>\n>>\n>>root at arun-Aspire-5742:~# mount\n>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>none on /sys/kernel/debug type debugfs (rw)\n>>none on /sys/kernel/security type securityfs (rw)\n>>udev on /dev type devtmpfs (rw,mode=0755)\n>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>\n>>\n>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>\n>>>\n>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>\n>>>\n>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>\n>>>\n>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>\n>>>\n>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>\n>>>\n>>>\n>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>please help me in this regard.\n>>>>\n>>>>\n>>>>\n>>>>>________________________________\n>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>\n>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>\n>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>\n>>>>>>\n>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>\n>>>>>>\n>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>\n>>>>>>\n>>>>>>-Clay\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>object.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>account.builder, build version 14\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>container.builder, build version 11\n>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>< Content-Length: 0\n>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>* couldn\'t connect to host\n>>>>>>>* Closing connection #0\n>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>> Host: localhost:8080\n>>>>>>>> Accept: */*\n>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>?\n>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>< Content-Length: 118\n>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>><?\n>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>* Closing connection #0\n>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Hmm....?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>2) Only one drive in the ring\n>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>Good luck~\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>+Hugo Kuo+\n>>>>>>>>hugo at swiftstack.com\n>>>>>>>>\n>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>\n>>>>>>>>+886 935004793\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>/srv/node/d1:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d2:\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>/srv/node/d3:\n>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>No container-updater running\n>>>>>>>>>No account-auditor running\n>>>>>>>>>No object-replicator running\n>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>No container-replicator running\n>>>>>>>>>No object-auditor running\n>>>>>>>>>No object-expirer running\n>>>>>>>>>No container-auditor running\n>>>>>>>>>No container-server running\n>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>No account-reaper running\n>>>>>>>>>No container-sync running\n>>>>>>>>>No account-replicator running\n>>>>>>>>>No object-updater running\n>>>>>>>>>No object-server running\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check rings :\n>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>\n>>>>>>>>>>+886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>>hello sir,\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>\n>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>-- \n>>>>>>>>>>>>\n>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>_______________________________________________\n>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130910/0a8acb2b/attachment.html>\n\n','<CA+_JKzpENJixGP8Fc90TsbmEv4z98H3hQ=cmg2VB2Yhy7zhhQw@mail.gmail.com>',NULL),('<1378796670.5509.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 15:04:30',28800,'2013-09-10 07:04:30',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','thanks clay, for the help.\n\nI run some commands to survey what\'s on the system:\n\nroot at arun-Aspire-5742:~# df\nFilesystem ? ? 1K-blocks ? ?Used Available Use% Mounted on\n/dev/sda4 ? ? ?177866264 4164648 164666508 ? 3% /\nudev ? ? ? ? ? ? 2918600 ? ? ? 4 ? 2918596 ? 1% /dev\ntmpfs ? ? ? ? ? ?1170364 ? ? 892 ? 1169472 ? 1% /run\nnone ? ? ? ? ? ? ? ?5120 ? ? ? 4 ? ? ?5116 ? 1% /run/lock\nnone ? ? ? ? ? ? 2925908 ? ? 216 ? 2925692 ? 1% /run/shm\n\nroot at arun-Aspire-5742:~# cat /proc/mounts\nrootfs / rootfs rw 0 0\nsysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0\nproc /proc proc rw,nosuid,nodev,noexec,relatime 0 0\nudev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0\ndevpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0\ntmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0\n/dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0\nnone /sys/fs/fuse/connections fusectl rw,relatime 0 0\nnone /sys/kernel/debug debugfs rw,relatime 0 0\nnone /sys/kernel/security securityfs rw,relatime 0 0\nnone /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0\nnone /run/shm tmpfs rw,nosuid,nodev,relatime 0 0\ngvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\n\nroot at arun-Aspire-5742:~# ls /sys/block\nloop0 ?loop3 ?loop6 ?ram1 ? ram12 ?ram15 ?ram4 ?ram7 ?sda ?sr1\nloop1 ?loop4 ?loop7 ?ram10 ?ram13 ?ram2 ? ram5 ?ram8 ?sdb\nloop2 ?loop5 ?ram0 ? ram11 ?ram14 ?ram3 ? ram6 ?ram9 ?sr0\n\nroot at arun-Aspire-5742:~# sudo blkid\n/dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\"?\n/dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\"?\n/dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\"?\n/dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\"?\n/dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\"?\n/dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\"?\n/dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"?\n\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2\nmkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\nmkfs.xfs: Use the -f option to force overwrite.\n\nwhich device should I label as \"d1\"?\nhow many devices should I label ?as \"d1\", \"d2\" etc.?\n\nPlease help me in this regard.\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 10 September 2013 12:01 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>So it looks like you do not have a device \'/dev/sdd\' - which device do you want to use as \"d1\" - sda2, sda4, sda5, sda6, sda7 ???\n>\n>\n>\n>On Mon, Sep 9, 2013 at 9:47 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir\n>>root at arun-Aspire-5742:~# cat /proc/partitions\n>>major minor ?#blocks ?name\n>>\n>>\n>>? ?8 ? ? ? ?0 ?488386584 sda\n>>? ?8 ? ? ? ?1 ? ? 102400 sda1\n>>? ?8 ? ? ? ?2 ?102294528 sda2\n>>? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n>>? ?8 ? ? ? ?4 ?180702208 sda4\n>>? ?8 ? ? ? ?5 ?102398278 sda5\n>>? ?8 ? ? ? ?6 ?102398278 sda6\n>>? ?8 ? ? ? ?7 ? ? 487424 sda7\n>>? 11 ? ? ? ?0 ? ?1048575 sr0\n>>? 11 ? ? ? ?1 ? ? ?99328 sr1\n>>root at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sdb\n>>mkfs.xfs: cannot open /dev/sdb: No medium found\n>>\n>>\n>>pleases help me.\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Saturday, 7 September 2013 9:50 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>>>\n>>>\n>>>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>>>\n>>>\n>>>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>>>\n>>>\n>>>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>>>\n>>>\n>>>That should be:\n>>>\n>>>\n>>>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>>>\n>>>\n>>>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>>>\n>>>\n>>>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>>>\n>>>\n>>>`sudo mkfs.xfs -L d1 /dev/sdb`\n>>>`sudo mkfs.xfs -L d2 /dev/sdc`\n>>>\n>>>`sudo mkfs.xfs -L d3 /dev/sdd`\n>>>\n>>>\n>>>\n>>>and maybe:\n>>>\n>>>\n>>>`sudo mkfs.xfs -L d4 /dev/sde`\n>>>\n>>>\n>>>\n>>>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I did the following job:\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# mount\n>>>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>>>none on /sys/kernel/debug type debugfs (rw)\n>>>>none on /sys/kernel/security type securityfs (rw)\n>>>>udev on /dev type devtmpfs (rw,mode=0755)\n>>>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>>>\n>>>>\n>>>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>\n>>>>>\n>>>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>>>\n>>>>>\n>>>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>>>\n>>>>>\n>>>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>>>\n>>>>>\n>>>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>please help me in this regard.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>\n>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>>>\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>>>\n>>>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>-Clay\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>>>object.builder, build version 14\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>>>account.builder, build version 14\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>>>container.builder, build version 11\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>< Content-Length: 0\n>>>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>< Content-Length: 118\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>< Content-Length: 118\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Hmm....?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>>>2) Only one drive in the ring\n>>>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Good luck~\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>\n>>>>>>>>>>+886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>>>/srv/node/d1:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>/srv/node/d2:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>/srv/node/d3:\n>>>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>>>No container-updater running\n>>>>>>>>>>>No account-auditor running\n>>>>>>>>>>>No object-replicator running\n>>>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>No container-replicator running\n>>>>>>>>>>>No object-auditor running\n>>>>>>>>>>>No object-expirer running\n>>>>>>>>>>>No container-auditor running\n>>>>>>>>>>>No container-server running\n>>>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>>>No account-reaper running\n>>>>>>>>>>>No container-sync running\n>>>>>>>>>>>No account-replicator running\n>>>>>>>>>>>No object-updater running\n>>>>>>>>>>>No object-server running\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>>>\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Check rings :\n>>>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>\n>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>\n>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>-- \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>_______________________________________________\n>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130910/dfb09e8c/attachment-0001.html>\n\n','<CA+_JKzrX4_wgkCBfE36T7seYFsq7OtJgfJgnyQC_nFRJgO_+2A@mail.gmail.com>',NULL),('<1378804670.30929.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-10 17:17:50',28800,'2013-09-10 09:17:50',NULL,'[openstack-dev] Conductor API has no attribute \"xxxxxx\"','Hi all,\n\n\nI have been trying to add a new table to the database. Now, I have created?\nthe table and I am going through conductor API to populate/update it. I have?\ndefined some function to achieve the task. There function are defined in conductor?\nand db api, along with in conductor.manage and db.sqlalchemy.api. When I try?\nto run the system it says?\n\n?AttributeError: \'ConductorAPI\' object?has no attribute \'xxxxxx\'\n\nwhile the function is properly defined in Conductor API as well as manager and?\ndb.API. I back traced the flow of the code and it looks like the code reaches till\nconductor.api. The function at the conductor API is defined as:\n\n#In class LocalAPI\ndef xxxxxx(self, context, node_id, values):\n? ? ? ? return self._manager.xxxxxx(context, node_id, values)\n\nNow, after this it gives the error. Though the function is present in conductor.manager.\nPlease help me find out why am I getting this error.\n\nThanks\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130910/cdf64fc4/attachment.html>\n\n',NULL,NULL),('<1378804887.33900.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 17:21:27',28800,'2013-09-10 09:21:27',NULL,'[Openstack] Conductor API has no attribute \"xxxxxx\"','\n\nHi all,\n\n\nI have been trying to add a new table to the database. Now, I have created?\nthe table and I am going through conductor API to populate/update it. I have?\ndefined some function to achieve the task. There function are defined in conductor?\nand db api, along with in conductor.manage and db.sqlalchemy.api. When I try?\nto run the system it says?\n\n?AttributeError: \'ConductorAPI\' object?has no attribute \'xxxxxx\'\n\nwhile the function is properly defined in Conductor API as well as manager and?\ndb.API. I back traced the flow of the code and it looks like the code reaches till\nconductor.api. The function at the conductor API is defined as:\n\n#In class LocalAPI\ndef xxxxxx(self, context, node_id, values):\n? ? ? ? return self._manager.xxxxxx(context, node_id, values)\n\nNow, after this it gives the error. Though the function is present in conductor.manager.\nPlease help me find out why am I getting this error.\n\nThanks\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130910/1876418f/attachment.html>\n\n','<1378804670.30929.YahooMailNeo@web194603.mail.sg3.yahoo.com>',NULL),('<1378828505.53367.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-10 23:55:05',28800,'2013-09-10 15:55:05',NULL,'[openstack-dev] Conductor API has no attribute \"xxxxxx\"','Hi Dan,\n\nYeah, I figured that out. I was already using objects, but\nI didn\'t add the interface to the conductor.rpcapi. It\'s working\nfine now.\n\nThanks.\n?\n~Peeyush Gupta\n\n\n________________________________\n From: Dan Smith <dms at danplanet.com>\nTo: Peeyush Gupta <gpeeyush at ymail.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Tuesday, 10 September 2013 5:29 PM\nSubject: Re: [openstack-dev] Conductor API has no attribute \"xxxxxx\"\n \n\n> I have been trying to add a new table to the database.\n\nJust FYI, new database interfaces should be added using objects, which\nare automatically remotable. New conductor interfaces should not be\nadded to make database queries.\n\n> #In class LocalAPI\n> def xxxxxx(self, context, node_id, values):\n> ? ? ? ? return self._manager.xxxxxx(context, node_id, values)\n> \n\nIs this on top of master?\n\nAdding to api -> rpcapi -> manager should do the trick. It would be\nhelpful to know what you\'re trying to build this on top of, as well as\na little more detail about what you\'ve added.\n\n--Dan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130910/ef60bc43/attachment.html>\n\n','<20130910045939.077581f5@theine.danplanet.com>',NULL),('<1378829061-sup-7857@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-10 09:29:29',-25200,'2013-09-10 16:29:29',NULL,'[openstack-dev] [TripleO] summit.openstack.org track label for\n	TripleO -> Deployment','Excerpts from Thierry Carrez\'s message of 2013-09-10 00:56:29 -0700:\n> Robert Collins wrote:\n> > Thierry, is it possible to change this to \'Deployment\' rather than\n> > TripleO in the summit tool? I think it would avoid folk interested in\n> > Tuskar failing to find a place to submit their proposals, and as a\n> > program we are multi-project - Tomas and I have just discussed this in\n> > the tripleo meeting slot and think it would be a good idea.\n> \n> Note that only official programs get time to the Design Summit,\n> unofficial projects have to go to the unconference. That said, nothing\n> prevents you from having one session from the TripleO track explore the\n> possibilities of (and relationship with) Tuskar. You decide the content :)\n> \n> We could even rename the track \"Deployment\" (which is your program name)\n> but I fear that such a generic name would trigger dozens of off-topic\n> suggestions: non-design discussions or having nothing to do with your\n> program. Those would generate a lot of disappointment when you end up\n> having to refuse them all...\n\nI have to agree that the current TripleO set of work won\'t get discussed\nas much if we open it up to all deployment. But to exclude all of the\nother ideas about deployment from our discussions seems the wrong way\nto go about growing this part of OpenStack.\n\nOne of the principles we\'ve held most high in TripleO since I joined\nthe project has been to decouple everything that can be decoupled. So\nwhile we are driving at a particular realistic deployment, we are not\nexcluding alternate courses. Diskimage-builder originally only worked on\nUbuntu, but we decoupled that, and now it has Fedora and RHEL. We are\ncurrently working on accepting changes to allow qpid instead of rabbit\nas well.  While we are working at an image update based solution using\nthe os-*-config tools, we would gladly welcome changes to enable a more\ntraditional approach to deployment using the other tools.\n\nMy point is this: The summit isn\'t just about us sitting around pushing\nour vision.  We need to be open to the OpenStack Deployment tool chain\nsupporting other deployment models. So while I\'m not sure calling it\n\"Deployment\" will have a positive effect, I am also not sure that calling\nit \"TripleO\" is the right answer either. Thoughts?\n\n\n','<522ED0AD.30201@openstack.org>',NULL),('<1378835754.28581.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-11 01:55:54',28800,'2013-09-10 17:55:54',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','thanks clay, for the help.\n\nI run some commands to survey what\'s on the system:\n\nroot at arun-Aspire-5742:~# df\nFilesystem ? ? 1K-blocks ? ?Used Available Use% Mounted on\n/dev/sda4 ? ? ?177866264 4164648 164666508 ? 3% /\nudev ? ? ? ? ? ? 2918600 ? ? ? 4 ? 2918596 ? 1% /dev\ntmpfs ? ? ? ? ? ?1170364 ? ? 892 ? 1169472 ? 1% /run\nnone ? ? ? ? ? ? ? ?5120 ? ? ? 4 ? ? ?5116 ? 1% /run/lock\nnone ? ? ? ? ? ? 2925908 ? ? 216 ? 2925692 ? 1% /run/shm\n\nroot at arun-Aspire-5742:~# cat /proc/mounts\nrootfs / rootfs rw 0 0\nsysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0\nproc /proc proc rw,nosuid,nodev,noexec,relatime 0 0\nudev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0\ndevpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0\ntmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0\n/dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0\nnone /sys/fs/fuse/connections fusectl rw,relatime 0 0\nnone /sys/kernel/debug debugfs rw,relatime 0 0\nnone /sys/kernel/security securityfs rw,relatime 0 0\nnone /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0\nnone /run/shm tmpfs rw,nosuid,nodev,relatime 0 0\ngvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\n\nroot at arun-Aspire-5742:~# ls /sys/block\nloop0 ?loop3 ?loop6 ?ram1 ? ram12 ?ram15 ?ram4 ?ram7 ?sda ?sr1\nloop1 ?loop4 ?loop7 ?ram10 ?ram13 ?ram2 ? ram5 ?ram8 ?sdb\nloop2 ?loop5 ?ram0 ? ram11 ?ram14 ?ram3 ? ram6 ?ram9 ?sr0\n\nroot at arun-Aspire-5742:~# sudo blkid\n/dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\"?\n/dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\"?\n/dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\"?\n/dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\"?\n/dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\"?\n/dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\"?\n/dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"?\n\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2\nmkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\nmkfs.xfs: Use the -f option to force overwrite.\n\nwhich device should I label as \"d1\"?\nhow many devices should I label ?as \"d1\", \"d2\" etc.?\n\nPlease help me in this regard.\n\n\n\n>________________________________\n> From: Clay Gerrard <clay.gerrard at gmail.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 10 September 2013 12:01 AM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>So it looks like you do not have a device \'/dev/sdd\' - which device do you want to use as \"d1\" - sda2, sda4, sda5, sda6, sda7 ???\n>\n>\n>\n>On Mon, Sep 9, 2013 at 9:47 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello sir\n>>root at arun-Aspire-5742:~# cat /proc/partitions\n>>major minor ?#blocks ?name\n>>\n>>\n>>? ?8 ? ? ? ?0 ?488386584 sda\n>>? ?8 ? ? ? ?1 ? ? 102400 sda1\n>>? ?8 ? ? ? ?2 ?102294528 sda2\n>>? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n>>? ?8 ? ? ? ?4 ?180702208 sda4\n>>? ?8 ? ? ? ?5 ?102398278 sda5\n>>? ?8 ? ? ? ?6 ?102398278 sda6\n>>? ?8 ? ? ? ?7 ? ? 487424 sda7\n>>? 11 ? ? ? ?0 ? ?1048575 sr0\n>>? 11 ? ? ? ?1 ? ? ?99328 sr1\n>>root at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sdb\n>>mkfs.xfs: cannot open /dev/sdb: No medium found\n>>\n>>\n>>pleases help me.\n>>\n>>\n>>\n>>\n>>\n>>>________________________________\n>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>Sent: Saturday, 7 September 2013 9:50 PM\n>>>\n>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>> \n>>>\n>>>\n>>>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>>>\n>>>\n>>>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>>>\n>>>\n>>>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>>>\n>>>\n>>>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>>>\n>>>\n>>>That should be:\n>>>\n>>>\n>>>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>>>\n>>>\n>>>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>>>\n>>>\n>>>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>>>\n>>>\n>>>`sudo mkfs.xfs -L d1 /dev/sdb`\n>>>`sudo mkfs.xfs -L d2 /dev/sdc`\n>>>\n>>>`sudo mkfs.xfs -L d3 /dev/sdd`\n>>>\n>>>\n>>>\n>>>and maybe:\n>>>\n>>>\n>>>`sudo mkfs.xfs -L d4 /dev/sde`\n>>>\n>>>\n>>>\n>>>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello sir,\n>>>>\n>>>>\n>>>>I did the following job:\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>mount: no such partition found\n>>>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>>>mount: special device d1 does not exist\n>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>>>\n>>>>\n>>>>root at arun-Aspire-5742:~# mount\n>>>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>>>none on /sys/kernel/debug type debugfs (rw)\n>>>>none on /sys/kernel/security type securityfs (rw)\n>>>>udev on /dev type devtmpfs (rw,mode=0755)\n>>>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>>>\n>>>>\n>>>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>>>\n>>>>>________________________________\n>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>>>\n>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>> \n>>>>>\n>>>>>\n>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>\n>>>>>\n>>>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>>>\n>>>>>\n>>>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>>>\n>>>>>\n>>>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>>>\n>>>>>\n>>>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>please help me in this regard.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>>________________________________\n>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>\n>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>>>\n>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>> \n>>>>>>>\n>>>>>>>\n>>>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>>>\n>>>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>-Clay\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>>>object.builder, build version 14\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>>>account.builder, build version 14\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>>>container.builder, build version 11\n>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>< Content-Length: 0\n>>>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>< Content-Length: 118\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>* Closing connection #0\n>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>> Accept: */*\n>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>?\n>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>< Content-Length: 118\n>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>>>><?\n>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>* Closing connection #0\n>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>>________________________________\n>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>>>\n>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>> \n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Hmm....?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>>>2) Only one drive in the ring\n>>>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>Good luck~\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>\n>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>\n>>>>>>>>>>+886 935004793\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>\n>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>>>/srv/node/d1:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>/srv/node/d2:\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>/srv/node/d3:\n>>>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>>>No container-updater running\n>>>>>>>>>>>No account-auditor running\n>>>>>>>>>>>No object-replicator running\n>>>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>No container-replicator running\n>>>>>>>>>>>No object-auditor running\n>>>>>>>>>>>No object-expirer running\n>>>>>>>>>>>No container-auditor running\n>>>>>>>>>>>No container-server running\n>>>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>>>No account-reaper running\n>>>>>>>>>>>No container-sync running\n>>>>>>>>>>>No account-replicator running\n>>>>>>>>>>>No object-updater running\n>>>>>>>>>>>No object-server running\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>>________________________________\n>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>>>\n>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>> \n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Check rings :\n>>>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>\n>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>\n>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>\n>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>-- \n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>_______________________________________________\n>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130911/2e6ac633/attachment.html>\n\n','<CA+_JKzrX4_wgkCBfE36T7seYFsq7OtJgfJgnyQC_nFRJgO_+2A@mail.gmail.com>',NULL),('<1378861142-sup-2911@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 17:59:29',-25200,'2013-09-11 00:59:29',NULL,'[Openstack] Why GlusterFS should not be integrated with\n	OpenStack','Excerpts from Muralidhar Balcha\'s message of 2013-09-10 16:23:09 -0700:\n> I strongly believe this is the wrong forum to discuss pro and cons of a\n> particular offering here. Obviously no one solution fits all and every\n> products have merits.\n> \n\nWhat forum would you suggest people share OpenStack case studies in?\n\n\n','<CAMQ6KJYHT7Z5fgGNuvD78AyVhyvvo=jVZwQ_8+PWYpGP7qSYuQ@mail.gmail.com>',NULL),('<1378878487.7381.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-11 13:48:07',28800,'2013-09-11 05:48:07',NULL,'[Openstack] Fw: problem in setting up Tempauth authentication &\n	authorization with Swift','please help me in this regard.\n\n\n\n>________________________________\n> From: pragya jain <prag_2648 at yahoo.co.in>\n>To: Clay Gerrard <clay.gerrard at gmail.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 10 September 2013 11:25 PM\n>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n> \n>\n>\n>thanks clay, for the help.\n>\n>\n>I run some commands to survey what\'s on the system:\n>\n>\n>root at arun-Aspire-5742:~# df\n>Filesystem ? ? 1K-blocks ? ?Used Available Use% Mounted on\n>/dev/sda4 ? ? ?177866264 4164648 164666508 ? 3% /\n>udev ? ? ? ? ? ? 2918600 ? ? ? 4 ? 2918596 ? 1% /dev\n>tmpfs ? ? ? ? ? ?1170364 ? ? 892 ? 1169472 ? 1% /run\n>none ? ? ? ? ? ? ? ?5120 ? ? ? 4 ? ? ?5116 ? 1% /run/lock\n>none ? ? ? ? ? ? 2925908 ? ? 216 ? 2925692 ? 1% /run/shm\n>\n>\n>root at arun-Aspire-5742:~# cat /proc/mounts\n>rootfs / rootfs rw 0 0\n>sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0\n>proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0\n>udev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0\n>devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0\n>tmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0\n>/dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0\n>none /sys/fs/fuse/connections fusectl rw,relatime 0 0\n>none /sys/kernel/debug debugfs rw,relatime 0 0\n>none /sys/kernel/security securityfs rw,relatime 0 0\n>none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0\n>none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0\n>gvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\n>\n>\n>root at arun-Aspire-5742:~# ls /sys/block\n>loop0 ?loop3 ?loop6 ?ram1 ? ram12 ?ram15 ?ram4 ?ram7 ?sda ?sr1\n>loop1 ?loop4 ?loop7 ?ram10 ?ram13 ?ram2 ? ram5 ?ram8 ?sdb\n>loop2 ?loop5 ?ram0 ? ram11 ?ram14 ?ram3 ? ram6 ?ram9 ?sr0\n>\n>\n>root at arun-Aspire-5742:~# sudo blkid\n>/dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\"?\n>/dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\"?\n>/dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\"?\n>/dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\"?\n>/dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\"?\n>/dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\"?\n>/dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"?\n>\n>\n>root at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2\n>mkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\n>mkfs.xfs: Use the -f option to force overwrite.\n>\n>\n>which device should I label as \"d1\"?\n>how many devices should I label ?as \"d1\", \"d2\" etc.?\n>\n>\n>Please help me in this regard.\n>\n>\n>\n>>________________________________\n>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>Sent: Tuesday, 10 September 2013 12:01 AM\n>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>> \n>>\n>>\n>>So it looks like you do not have a device \'/dev/sdd\' - which device do you want to use as \"d1\" - sda2, sda4, sda5, sda6, sda7 ???\n>>\n>>\n>>\n>>On Mon, Sep 9, 2013 at 9:47 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hello sir\n>>>root at arun-Aspire-5742:~# cat /proc/partitions\n>>>major minor ?#blocks ?name\n>>>\n>>>\n>>>? ?8 ? ? ? ?0 ?488386584 sda\n>>>? ?8 ? ? ? ?1 ? ? 102400 sda1\n>>>? ?8 ? ? ? ?2 ?102294528 sda2\n>>>? ?8 ? ? ? ?3 ? ? ? ? ?1 sda3\n>>>? ?8 ? ? ? ?4 ?180702208 sda4\n>>>? ?8 ? ? ? ?5 ?102398278 sda5\n>>>? ?8 ? ? ? ?6 ?102398278 sda6\n>>>? ?8 ? ? ? ?7 ? ? 487424 sda7\n>>>? 11 ? ? ? ?0 ? ?1048575 sr0\n>>>? 11 ? ? ? ?1 ? ? ?99328 sr1\n>>>root at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sdb\n>>>mkfs.xfs: cannot open /dev/sdb: No medium found\n>>>\n>>>\n>>>pleases help me.\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>>________________________________\n>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>Sent: Saturday, 7 September 2013 9:50 PM\n>>>>\n>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>> \n>>>>\n>>>>\n>>>>ok, so it looks like no device with label d1 exists, so you can\'t mount it, and the account-server can\'t find it.\n>>>>\n>>>>\n>>>>Devices get labeled when you put the file system on them (the `mkfs.xfs` command)\n>>>>\n>>>>\n>>>>I saw in screenshot 10 you had mis-typed the mkfs.xfs command:\n>>>>\n>>>>\n>>>>`sudo mkfs.xfs -f -i size=512 -L d3/dev/sdd`\n>>>>\n>>>>\n>>>>That should be:\n>>>>\n>>>>\n>>>>`sudo mkfs.xfs -f -i size=512 -L d3 /dev/sdd`\n>>>>\n>>>>\n>>>>notice the space between the label \"d3\" and the device \"/dev/sdd\"\n>>>>\n>>>>\n>>>>Also, fairly recently people have stopped recommending the larger inode size, so the commands should be:\n>>>>\n>>>>\n>>>>`sudo mkfs.xfs -L d1 /dev/sdb`\n>>>>`sudo mkfs.xfs -L d2 /dev/sdc`\n>>>>\n>>>>`sudo mkfs.xfs -L d3 /dev/sdd`\n>>>>\n>>>>\n>>>>\n>>>>and maybe:\n>>>>\n>>>>\n>>>>`sudo mkfs.xfs -L d4 /dev/sde`\n>>>>\n>>>>\n>>>>\n>>>>... actually how many devices do you have in the system? ?Can I get a paste of the full output of `cat /proc/partitions`?\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>On Fri, Sep 6, 2013 at 9:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>hello sir,\n>>>>>\n>>>>>\n>>>>>I did the following job:\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>>\n>>>>>mount: no such partition found\n>>>>>root at arun-Aspire-5742:~# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>>mount: no such partition found\n>>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 /srv/node/d1\n>>>>>mount: no such partition found\n>>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo mount -t xfs -o noatime,nodiratime,logbufs=8 -L d1 \\srv/node/d1\n>>>>>mount: no such partition found\n>>>>>root at arun-Aspire-5742:/opt/swift/etc# cd ~\n>>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>>mount: special device d1 does not exist\n>>>>>root at arun-Aspire-5742:~# vi /etc/swift/account-server.conf\n>>>>>root at arun-Aspire-5742:~# mount d1 /srv/node/d1\n>>>>>mount: special device d1 does not exist\n>>>>>root at arun-Aspire-5742:~# cd /opt/swift/etc\n>>>>>root at arun-Aspire-5742:/opt/swift/etc# mount d1 /srv/node/d1\n>>>>>mount: special device d1 does not exist\n>>>>>root at arun-Aspire-5742:/opt/swift/etc# sudo reboot\n>>>>>\n>>>>>\n>>>>>root at arun-Aspire-5742:~# mount\n>>>>>/dev/sda4 on / type ext4 (rw,errors=remount-ro)\n>>>>>proc on /proc type proc (rw,noexec,nosuid,nodev)\n>>>>>sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)\n>>>>>none on /sys/fs/fuse/connections type fusectl (rw)\n>>>>>none on /sys/kernel/debug type debugfs (rw)\n>>>>>none on /sys/kernel/security type securityfs (rw)\n>>>>>udev on /dev type devtmpfs (rw,mode=0755)\n>>>>>devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)\n>>>>>tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)\n>>>>>none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)\n>>>>>none on /run/shm type tmpfs (rw,nosuid,nodev)\n>>>>>gvfs-fuse-daemon on /home/arun/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=arun)\n>>>>>\n>>>>>\n>>>>>I am attaching some screenshots which tells what I had done earlier when I was preparing and mounting the devices.\n>>>>>\n>>>>>>________________________________\n>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>Sent: Friday, 6 September 2013 8:58 PM\n>>>>>>\n>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>> \n>>>>>>\n>>>>>>\n>>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage?127.0.0.1:6002/d1?(txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>>\n>>>>>>\n>>>>>>The account server on 127.0.0.1:6002/d1 returned 507 indicating it couldn\'t find a useable file system for the device labeled d1.\n>>>>>>\n>>>>>>\n>>>>>>The account server has a config option \"devices\" in the \"DEFAULT\" section of \"/etc/swift/account-server.conf\" that will indicate the base mount point for devices (typicailly it\'s \"/srv/node\"). ?That path is prepended to the device name that\'s sent in the request (\"d1\" in this case).\n>>>>>>\n>>>>>>\n>>>>>>So there should be a filesystem (xfs typically) mounted at \"/srv/node/d1\"\n>>>>>>\n>>>>>>\n>>>>>>Try mounting it manually `mount d1 /srv/node/d1` and double check the output from `mount` and your \"/etc/fstab\"\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Thu, Sep 5, 2013 at 9:39 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>please help me in this regard.\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>>________________________________\n>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>To: Clay Gerrard <clay.gerrard at gmail.com> \n>>>>>>>>\n>>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>Sent: Thursday, 5 September 2013 10:02 AM\n>>>>>>>>\n>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>> \n>>>>>>>>\n>>>>>>>>\n>>>>>>>>root at arun-Aspire-5742:~# grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslogSep ?4 11:14:04 arun-Aspire-5742 account-server 127.0.0.1 - - [04/Sep/2013:05:44:04 +0000] \"GET /d1/19164/AUTH_prag2648\" 507 - \"txb0d8717ab05c4cf0bdebd-005226c8a4\" \"GET http://localhost:8080/v1/AUTH_prag2648/\" \"proxy-server 3182\" 0.0021 \"\"\n>>>>>>>>Sep ?4 11:14:04 arun-Aspire-5742 proxy-server ERROR Insufficient Storage 127.0.0.1:6002/d1 (txn: txb0d8717ab05c4cf0bdebd-005226c8a4)\n>>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server Account GET returning 503 for [507] (txn: txb0d8717ab05c4cf0bdebd-005226c8a4) (client_ip: 127.0.0.1)\n>>>>>>>>Sep ?4 11:14:05 arun-Aspire-5742 proxy-server 127.0.0.1 127.0.0.1 04/Sep/2013/05/44/05 GET /v1/AUTH_prag2648/ HTTP/1.0 503 - curl/7.22.0%20%28i686-pc-linux-gnu%29%20libcurl/7.22.0%20OpenSSL/1.0.1%20zlib/1.2.3.4%20libidn/1.23%20librtmp/2.3 AUTH_tk4be7b90194c747468c4973675db15ca5 - 118 - txb0d8717ab05c4cf0bdebd-005226c8a4 - 0.2774 - -\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>>________________________________\n>>>>>>>>> From: Clay Gerrard <clay.gerrard at gmail.com>\n>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>Cc: \"pangj at laposte.net\" <pangj at laposte.net>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>Sent: Wednesday, 4 September 2013 9:12 PM\n>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>> \n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>So the builder files look right, you should grep the logs for the transaction id of the request that 503\'d and see if the proxy is still getting connection errors (i.e. still trying to connect to 10.0.2.15)\n>>>>>>>>>\n>>>>>>>>>grep txb0d8717ab05c4cf0bdebd-005226c8a4 /var/log/syslog\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>If the proxy is still going to the old 10.0.2.15 you need to rebalance your rings\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>swift-ring-builder account.builder reblanace\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>-Clay\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>On Tue, Sep 3, 2013 at 10:51 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>\n>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder object.builder\n>>>>>>>>>>object.builder, build version 14\n>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6000 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder account.builder\n>>>>>>>>>>account.builder, build version 14\n>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>? ? ? ? ? ? ?2 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6002 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>root at arun-Aspire-5742:/etc/swift# swift-ring-builder container.builder\n>>>>>>>>>>container.builder, build version 11\n>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>? ? ? ? ? ? ?1 ? ? ? 1 ? ? 1 ? ? ? 127.0.0.1 ?6001 ? ? ? 127.0.0.1 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>root at arun-Aspire-5742:/etc/swift# cd ~\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>< X-Auth-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Storage-Token: AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>< X-Trans-Id: txc07e87d3d4b8487b85d89-005226c820\n>>>>>>>>>>< Date: Wed, 04 Sep 2013 05:41:52 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1:8080/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: 127.0.0.1:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Trans-Id: tx2301beb46542488597d23-005226c87d\n>>>>>>>>>>< Date: Wed, 04 Sep 2013 05:43:26 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host 127.0.0.1 left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://127.0.0.1/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>> Accept: */*\n>>>>>>>>>>> X-Storage-Token:AUTH_tk4be7b90194c747468c4973675db15ca5\n>>>>>>>>>>>?\n>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>< X-Trans-Id: txb0d8717ab05c4cf0bdebd-005226c8a4\n>>>>>>>>>>< Date: Wed, 04 Sep 2013 05:44:05 GMT\n>>>>>>>>>><?\n>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>* Closing connection #0\n>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>root at arun-Aspire-5742:~# grep txa4c98c518382430ab9f5f-005222dede /var/log/syslogroot at arun-Aspire-5742:~#?\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>>>________________________________\n>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>Sent: Friday, 30 August 2013 1:15 PM\n>>>>>>>>>>>\n>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>> \n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Hmm....?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>1) No Container and Object servers are running?\n>>>>>>>>>>>2) Only one drive in the ring\n>>>>>>>>>>>3) No device been mount to /srv/node/* , unless you are disabling mount_check\n>>>>>>>>>>>4) Did you setup rsync yet ??\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Maybe you can follow the online document to complete the above items.?\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>Good luck~\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>\n>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>\n>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>\n>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>/etc/swift/account.builder, build version 1\n>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6000 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6000 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>>/etc/swift/container.builder, build version 1\n>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6001 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6001 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>>/etc/swift/object.builder, build version 1\n>>>>>>>>>>>>262144 partitions, 3.000000 replicas, 1 regions, 1 zones, 1 devices, 0.00 balance\n>>>>>>>>>>>>The minimum number of hours before a partition can be reassigned is 24\n>>>>>>>>>>>>Devices: ? ?id ?region ?zone ? ? ?ip address ?port ?replication ip ?replication port ? ? ?name weight partitions balance meta\n>>>>>>>>>>>>? ? ? ? ? ? ?0 ? ? ? 1 ? ? 1 ? ? ? 10.0.2.15 ?6002 ? ? ? 10.0.2.15 ? ? ? ? ? ? ?6002 ? ? ? ?d1 100.00 ? ? 786432 ? ?0.00?\n>>>>>>>>>>>>root at arun-Aspire-5742:~# ps aux | grep swift\n>>>>>>>>>>>>swift ? ? 5174 ?0.0 ?0.1 ?18700 11548 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>>swift ? ? 5181 ?0.0 ?0.1 ?18976 ?9624 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>>swift ? ? 5182 ?0.0 ?0.1 ?18992 ?9616 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>>swift ? ? 5183 ?0.0 ?0.1 ?18992 ?9620 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>>swift ? ? 5184 ?0.0 ?0.1 ?18992 ?9632 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-account-server /etc/swift/account-server.conf\n>>>>>>>>>>>>swift ? ? 5192 ?0.0 ?0.2 ?18296 11812 ? ? ? ? ?Ss ? 10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>swift ? ? 5197 ?0.0 ?0.2 ?23512 15552 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>swift ? ? 5198 ?0.0 ?0.2 ?23524 15628 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>swift ? ? 5199 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>swift ? ? 5200 ?0.0 ?0.2 ?23524 15300 ? ? ? ? ?S ? ?10:45 ? 0:00 /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>root ? ? ?6986 ?0.0 ?0.0 ? 4388 ? 828 pts/0 ? ?S+ ? 11:46 ? 0:00 grep --color=auto swift\n>>>>>>>>>>>>root at arun-Aspire-5742:~# df -h\n>>>>>>>>>>>>Filesystem ? ? ?Size ?Used Avail Use% Mounted on\n>>>>>>>>>>>>/dev/sda4 ? ? ? 170G ?3.8G ?158G ? 3% /\n>>>>>>>>>>>>udev ? ? ? ? ? ?2.8G ?4.0K ?2.8G ? 1% /dev\n>>>>>>>>>>>>tmpfs ? ? ? ? ? 1.2G ?908K ?1.2G ? 1% /run\n>>>>>>>>>>>>none ? ? ? ? ? ?5.0M ?4.0K ?5.0M ? 1% /run/lock\n>>>>>>>>>>>>none ? ? ? ? ? ?2.8G ?220K ?2.8G ? 1% /run/shm\n>>>>>>>>>>>>/dev/sda2 ? ? ? ?98G ? 25G ? 73G ?26% /media/D8EA06E4EA06BEAE\n>>>>>>>>>>>>/dev/sda5 ? ? ? ?98G ? 54G ? 45G ?55% /media/8AE41BA8E41B9613\n>>>>>>>>>>>>root at arun-Aspire-5742:~# ls /srv/node/*\n>>>>>>>>>>>>/srv/node/d1:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>/srv/node/d2:\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>/srv/node/d3:\n>>>>>>>>>>>>root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>Active Internet connections (servers and established)\n>>>>>>>>>>>>Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?941/memcached ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5192/python ? ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 0.0.0.0:6002 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?5174/python ? ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?6936/dnsmasq ? ?\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 101.58.138.11:56680 ? ? 207.171.162.71:443 ? ? ?ESTABLISHED 2042/chrome ? ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45287 ? ? ? ? ESTABL\n>>>>>>>>>>>>ISHED 941/memcached ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 127.0.0.1:45292 ? ? ? ? ESTABLISHED 941/memcached ??\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45287 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5197/python ? ??\n>>>>>>>>>>>>tcp ? ? ? ?1 ? ? ?0 101.58.138.11:34377 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1674/ubuntu-geoip-p\n>>>>>>>>>>>>tcp ? ? ? ?0 ? ? ?0 127.0.0.1:45292 ? ? ? ? 127.0.0.1:11211 ? ? ? ? ESTABLISHED 5198/python ? ??\n>>>>>>>>>>>>tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?596/cupsd ? ? ??\n>>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 941/memcached ??\n>>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:46638 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 6936/dnsmasq ? ?\n>>>>>>>>>>>>udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 576/avahi-daemon: r\n>>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::55335 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>>udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?576/avahi-daemon: r\n>>>>>>>>>>>>root at arun-Aspire-5742:~# swift-init all status\n>>>>>>>>>>>>No container-updater running\n>>>>>>>>>>>>No account-auditor running\n>>>>>>>>>>>>No object-replicator running\n>>>>>>>>>>>>proxy-server running (5192 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>No container-replicator running\n>>>>>>>>>>>>No object-auditor running\n>>>>>>>>>>>>No object-expirer running\n>>>>>>>>>>>>No container-auditor running\n>>>>>>>>>>>>No container-server running\n>>>>>>>>>>>>account-server running (5174 - /etc/swift/account-server.conf)\n>>>>>>>>>>>>No account-reaper running\n>>>>>>>>>>>>No container-sync running\n>>>>>>>>>>>>No account-replicator running\n>>>>>>>>>>>>No object-updater running\n>>>>>>>>>>>>No object-server running\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>\n>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>Cc: Gareth <academicgareth at gmail.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>Sent: Friday, 30 August 2013 11:23 AM\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>> \n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Hi Pragya :?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>I\'m in highly recommends that you can go through the Swift online document?http://docs.openstack.org/developer/swift/index.html .?\n>>>>>>>>>>>>>It\'s a good place to understand the basic architecture, especially swift *terms*?\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Check rings :\n>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/object.builder\n>>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/container.builder\n>>>>>>>>>>>>>>$> swift-ring-builder /etc/swift/account.builder\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>Check Swift workers :?\n>>>>>>>>>>>>>$> swift-init all status\n>>>>>>>>>>>>>>$> ps aux | grep swift\n>>>>>>>>>>>>>>$> df -h?\n>>>>>>>>>>>>>>$> ls /srv/node/*\n>>>>>>>>>>>>>>$> netstat -antulp\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>2013/8/30 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>I am working on single node.\n>>>>>>>>>>>>>>Please let me know how to check network topology and ring structure.\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>> From: Gareth <academicgareth at gmail.com>\n>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>Cc: pragya jain <prag_2648 at yahoo.co.in>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>Sent: Friday, 30 August 2013 8:11 AM\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Pragya\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>The v1.0 auth uses tempauth for swift, like what you config in proxy-server.conf. All account data is read from that file, so you couldn\'t add/delete account in tempauth without modifying config file and restart swift.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>BTW, your curl link here \"curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\'?http://localhost:8080/v1/AUTH_prag2648/\" actually is a GET request, which means getting account data. If you config everything correctly, it must have valid response. And you logs are a better way to find what happened in this request (set log level to DEBUG, and you will get more details).\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>On Fri, Aug 30, 2013 at 7:47 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Hi Pragya,?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>I need more information.?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>1) Please draw a network topology of your environment\n>>>>>>>>>>>>>>>>2) How many nodes do you have? ?\n>>>>>>>>>>>>>>>>3) What\'s the ring looks like ?\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>Hugo Kuo\n>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>hello sir,\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>connection is established successfully. But, when I try to create an account, I face the problem.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>> GET /auth/v1.0/ HTTP/1.1\n>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>> X-Auth-User:prag2648:pragya\n>>>>>>>>>>>>>>>>>> X-Auth-Key:pj2648\n>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>< HTTP/1.1 200 OK\n>>>>>>>>>>>>>>>>>< X-Storage-Url: http://localhost:8080/v1/AUTH_prag2648\n>>>>>>>>>>>>>>>>>< X-Auth-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>< X-Storage-Token: AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>< Content-Length: 0\n>>>>>>>>>>>>>>>>>< X-Trans-Id: txe2ab76a7617e40399f456-00521f3d16\n>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:22:46 GMT\n>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# python\n>>>>>>>>>>>>>>>>>Python 2.7.3 (default, Apr 10 2013, 05:46:21)?\n>>>>>>>>>>>>>>>>>[GCC 4.6.3] on linux2\n>>>>>>>>>>>>>>>>>Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>>>>>>>>>>>>>>>>>>> import swift.common.memcached as memcached\n>>>>>>>>>>>>>>>>>>>> memcache = memcached.MemcacheRing([\'127.0.0.1:11211\'])\n>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/user/prag2648:pragya\')\n>>>>>>>>>>>>>>>>>AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>>> print memcache.get(\'AUTH_/token/AUTH_tk3867b7599d5346559ee0baaa09e0f40d\')\n>>>>>>>>>>>>>>>>>[1377865366.826027, \'prag2648,prag2648:pragya,.reseller_admin,AUTH_prag2648\']\n>>>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://127.0.0.1/v1/Auth_prag2648/\n>>>>>>>>>>>>>>>>>* About to connect() to 127.0.0.1 port 80 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>* couldn\'t connect to host\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>>curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>root at arun-Aspire-5742:~# curl -v -H \'X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\' http://localhost:8080/v1/AUTH_prag2648/\n>>>>>>>>>>>>>>>>>* About to connect() to localhost port 8080 (#0)\n>>>>>>>>>>>>>>>>>* ? Trying 127.0.0.1... connected\n>>>>>>>>>>>>>>>>>> GET /v1/AUTH_prag2648/ HTTP/1.1\n>>>>>>>>>>>>>>>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/\n>>>>>>>>>>>>>>>>>1.2.3.4 libidn/1.23 librtmp/2.3\n>>>>>>>>>>>>>>>>>> Host: localhost:8080\n>>>>>>>>>>>>>>>>>> Accept: */*\n>>>>>>>>>>>>>>>>>> X-Storage-Token:AUTH_tk3867b7599d5346559ee0baaa09e0f40d\n>>>>>>>>>>>>>>>>>>?\n>>>>>>>>>>>>>>>>>< HTTP/1.1 503 Internal Server Error\n>>>>>>>>>>>>>>>>>< Content-Length: 118\n>>>>>>>>>>>>>>>>>< Content-Type: text/html; charset=UTF-8\n>>>>>>>>>>>>>>>>>< X-Trans-Id: txd6fd9eead36e4b74b0869-00521f3efe\n>>>>>>>>>>>>>>>>>< Date: Thu, 29 Aug 2013 12:30:55 GMT\n>>>>>>>>>>>>>>>>><?\n>>>>>>>>>>>>>>>>>* Connection #0 to host localhost left intact\n>>>>>>>>>>>>>>>>>* Closing connection #0\n>>>>>>>>>>>>>>>>><html><h1>Service Unavailable</h1><p>The server is currently unavailable. Please try again at a later time.</p></html>root at arun-Aspire-5742:~#?\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Please help me in this regard.\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>---\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>Pragya Jain\n>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>To: Kuo Hugo <tonytkdk at gmail.com> \n>>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 4:47 PM\n>>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>Thanks Kuo very much for this help.\n>>>>>>>>>>>>>>>>>>connection is successfully established.\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>________________________________\n>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>>To: pragya jain <prag_2648 at yahoo.co.in> \n>>>>>>>>>>>>>>>>>>>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>>>>>>>>>>>>>>>>>>>Sent: Thursday, 29 August 2013 3:46 PM\n>>>>>>>>>>>>>>>>>>>Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>> \n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost:8080/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>+Hugo Kuo+\n>>>>>>>>>>>>>>>>>>>hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>>tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>>+886 935004793\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp | grep 8080\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:8080 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2421/python ? \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> user = swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:47 PM\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> gt; netstat -antulp | grep 8080 \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 1) is 8080 port been used ?\n>>>>>>>>>>>>>>>>>>>> 2) What\'s the value of *user* parameter in proxy-server.conf ?https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L7\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> I run the command:\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>>> /opt/swift/build/scripts-2.7/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>> /opt/swift/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>> /usr/local/bin/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>> /usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/local/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>> Traceback (most recent call last):\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/bin/swift-proxy-server\", line 5, in <module>\n>>>>>>>>>>>>>>>>>>>> ? ? pkg_resources.run_script(\'swift==1.9.2\', \'swift-proxy-server\')\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 499, in run_script\n>>>>>>>>>>>>>>>>>>>> ? ? self.require(requires)[0].run_script(script_name, ns)\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/lib/python2.7/dist-packages/pkg_resources.py\", line 1235, in run_script\n>>>>>>>>>>>>>>>>>>>> ? ? execfile(script_filename, namespace, namespace)\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/EGG-INFO/scripts/swift-proxy-server\", line 22, in <module>\n>>>>>>>>>>>>>>>>>>>> ? ? run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 251, in run_wsgi\n>>>>>>>>>>>>>>>>>>>> ? ? sock = get_socket(conf, default_port=kwargs.get(\'default_port\', 8080))\n>>>>>>>>>>>>>>>>>>>> ? File \"/usr/local/lib/python2.7/dist-packages/swift-1.9.2-py2.7.egg/swift/common/wsgi.py\", line 168, in get_socket\n>>>>>>>>>>>>>>>>>>>> ? ? bind_addr[0], bind_addr[1], bind_timeout))\n>>>>>>>>>>>>>>>>>>>> Exception: Could not bind to 0.0.0.0:8080 after trying for 30 seconds\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 2:19 PM\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> find out the swift-proxy-server binary in your OS. ?(The path in example just an assumption) \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> gt; find / -name swift-proxy-server\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Thanks for the help\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>> /usr/bin/python: can\'t open file \'/usr/bin/swift-proxy-server\': [Errno 2] No such file or directory\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> this is the result of the command.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> please help in this regard.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> -----\n>>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>>> Sent: Thursday, 29 August 2013 1:20 PM\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Obviously, There\'s no proxy server running on your node. \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Please execute it on the node where proxy-server located: \n>>>>>>>>>>>>>>>>>>>> (I assume the binary is in /usr/bin and conf file is in /etc/swift) \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> gt; /usr/bin/python /usr/bin/swift-proxy-server /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> What\'s the result ?\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello sir\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Thanks for the suggestion.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> (1) I give the space between pj2648 and .admin and also between .admin and .reseller_admin and tried the connection again, but face the same problem\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> and make following changes:\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648 .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> and then\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> (2) I also tired the connection with user admin:admin\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:admin:admin\' -H \'X-Auth-Key:admin\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> (3) I also run the command to verify the port number of proxy\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# ps aux | grep proxy\n>>>>>>>>>>>>>>>>>>>> nobody ? ?2124 ?0.0 ?0.0 ? 5384 ?1164 ? ? ? ? ?S ? ?10:39 ? 0:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/sendsigs.omit.d/network-manager.dnsmasq.pid --listen-address=127.0.0.1 --conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=0 --proxy-dnssec\n>>>>>>>>>>>>>>>>>>>> root ? ? ?2724 ?0.0 ?0.0 ? 4368 ? 828 pts/0 ? ?R+ ? 10:52 ? 0:00 grep --color=auto proxy\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# netstat -antulp\n>>>>>>>>>>>>>>>>>>>> Active Internet connections (servers and established)\n>>>>>>>>>>>>>>>>>>>> Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?931/memcached ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 127.0.0.1:631 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51521 ? ? 74.125.236.132:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?1 ? ? ?0 115.184.7.223:46280 ? ? 91.189.89.144:80 ? ? ? ?CLOSE_WAIT ?1663/ubuntu-geoip-p\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:60563 ? ? 173.194.38.147:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:43256 ? ? 124.124.201.179:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:41791 ? ? 124.124.201.169:80 ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36669 ? ? 124.124.252.9:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:51747 ? ? 173.194.38.184:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:54229 ? ? 74.125.236.44:443 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:36185 ? ? 173.194.36.26:80 ? ? ? ?TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp ? ? ? ?0 ? ? ?0 115.184.7.223:38854 ? ? 74.125.236.109:80 ? ? ? TIME_WAIT ? - ? ? ? ? ? ? ?\n>>>>>>>>>>>>>>>>>>>> tcp6 ? ? ? 0 ? ? ?0 ::1:631 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ?LISTEN ? ? ?623/cupsd ? ? ?\n>>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:5353 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 0.0.0.0:53489 ? ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:11211 ? ? ? ? 0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 931/memcached ?\n>>>>>>>>>>>>>>>>>>>> udp ? ? ? ?0 ? ? ?0 127.0.0.1:53 ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? ? ? ? ? ? ? 2124/dnsmasq ? \n>>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::5353 ? ? ? ? ? ? ? ? :::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>> udp6 ? ? ? 0 ? ? ?0 :::36705 ? ? ? ? ? ? ? ?:::* ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?619/avahi-daemon: r\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Please help to proceed further.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Pragya jain\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>>> From: Kuo Hugo <tonytkdk at gmail.com>\n>>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> Cc: Amanda Plimpton <amanda at swiftstack.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>>> Sent: Wednesday, 28 August 2013 9:59 PM\n>>>>>>>>>>>>>>>>>>>> Subject: Re: [Openstack] Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Hi \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 1) user_prag2648_pragya = pj2648.admin.reseller_admin try to have a space between pj2648 and .admin . How about to test with user admin:admin ? \n>>>>>>>>>>>>>>>>>>>> 2) Verify the port number of proxy by \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> gt; ps aux | grep proxy \n>>>>>>>>>>>>>>>>>>>> gt; netstat -antulp \n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 3) Check the Proxy for how to setup bind_port https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> +Hugo Kuo+\n>>>>>>>>>>>>>>>>>>>> hugo at swiftstack.com\n>>>>>>>>>>>>>>>>>>>> tonytkdk at gmail.com\n>>>>>>>>>>>>>>>>>>>> +886 935004793\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> 2013/8/29 pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello sir,\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Please help me in knowing how to use 8080 port\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ________________________________\n>>>>>>>>>>>>>>>>>>>> From: Amanda Plimpton <amanda at swiftstack.com>\n>>>>>>>>>>>>>>>>>>>> To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> Cc: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>>> Sent: Tuesday, 27 August 2013 9:40 AM\n>>>>>>>>>>>>>>>>>>>> Subject: Re: Fw: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Hello,\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Did Edward\'s suggestion of using port 8080 help at all? The error seems to indicate a network setting issue. You may wish to double check the settings and configuration.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Given your interest in Swift I would also recommend locating a nearby OpenStack group or attending an event such as http://openstackindia.wordpress.com/2013/08/14/openstack-india-day-2013-announced/\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Thank you,\n>>>>>>>>>>>>>>>>>>>> Amanda\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> SwiftStack Inc.\n>>>>>>>>>>>>>>>>>>>> swiftstack.com\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> On Mon, Aug 26, 2013 at 8:55 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello sir!\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Please help me in setting up Tempauth authentication & authorization with Swift.\n>>>>>>>>>>>>>>>>>>>> same error is continued.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> ----- Forwarded Message -----\n>>>>>>>>>>>>>>>>>>>> From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>>>>>>>>>>>>>>> To: \"joe at swiftstack.com\" <joe at swiftstack.com>; \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com>; \"contact at swiftstack.com\" <contact at swiftstack.com>; \"openstack at ask.openstack.org\" <openstack at ask.openstack.org>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>>>>>>>>>>>>>>> Cc: anita goel <goel.anita at gmail.com>\n>>>>>>>>>>>>>>>>>>>> Sent: Monday, 26 August 2013 12:06 PM\n>>>>>>>>>>>>>>>>>>>> Subject: problem in setting up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> hello,\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> I have to configure proxy server.\n>>>>>>>>>>>>>>>>>>>> For this,\n>>>>>>>>>>>>>>>>>>>> I have to edit /etc/swift/swift.conf and change the swift_hash_path_suffix to something secret and then, start the proxy server process\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> for this, I use the following commands:\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/swift.conf\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>>> swift_hash_path_suffix =pragya\n>>>>>>>>>>>>>>>>>>>> swift_hash_path_prefix =jain\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> save and exit.\n>>>>>>>>>>>>>>>>>>>> then, I run the command:\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Now, I have to set up Tempauth authentication & authorization with Swift\n>>>>>>>>>>>>>>>>>>>> for this, I run the following command:\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# vi /etc/swift/proxy-server.conf\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> make following changes (highlighted) in the file:\n>>>>>>>>>>>>>>>>>>>> allow_account_management =true\n>>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>>> [filter:tempauth]\n>>>>>>>>>>>>>>>>>>>> use = egg:swift#tempauth\n>>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>>> user_admin_admin = admin .admin .reseller_admin\n>>>>>>>>>>>>>>>>>>>> user_test_tester = testing .admin\n>>>>>>>>>>>>>>>>>>>> user_test2_tester2 = testing2 .admin\n>>>>>>>>>>>>>>>>>>>> user_test_tester3 = testing3\n>>>>>>>>>>>>>>>>>>>> user_prag2648_pragya = pj2648.admin.reseller_admin\n>>>>>>>>>>>>>>>>>>>> ...\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> save and exit\n>>>>>>>>>>>>>>>>>>>> Then, run following commands:\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init account start\n>>>>>>>>>>>>>>>>>>>> Starting account-server...(/etc/swift/account-server.conf)\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy restart\n>>>>>>>>>>>>>>>>>>>> Signal proxy-server ?pid: 2476 ?signal: 15\n>>>>>>>>>>>>>>>>>>>> proxy-server (2476) appears to have stopped\n>>>>>>>>>>>>>>>>>>>> Starting proxy-server...(/etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# curl -v -H \'X-Auth-User:prag2648:pragya\' -H \'X-Auth-Key:pj2648\' http://localhost/auth/v1.0/\n>>>>>>>>>>>>>>>>>>>> * About to connect() to localhost port 80 (#0)\n>>>>>>>>>>>>>>>>>>>> * ? Trying 127.0.0.1... Connection refused\n>>>>>>>>>>>>>>>>>>>> * couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>> * Closing connection #0\n>>>>>>>>>>>>>>>>>>>> curl: (7) couldn\'t connect to host\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> But, there is an error in establising a connection.\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> if, I run the command to start proxy server, then it shows that proxy server is already started.\n>>>>>>>>>>>>>>>>>>>> root at arun-Aspire-5742:~# sudo swift-init proxy start\n>>>>>>>>>>>>>>>>>>>> proxy-server running (2935 - /etc/swift/proxy-server.conf)\n>>>>>>>>>>>>>>>>>>>> proxy-server already started...\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Please help me in this regard.\n>>>>>>>>>>>>>>>>>>>> ---\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Thanks\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> Pragya Jain\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>> _______________________________________________\n>>>>>>>>>>>>>>>>>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>>> Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>_______________________________________________\n>>>>>>>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>-- \n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Gareth\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>Cloud Computing, OpenStack, Fitness, Basketball\n>>>>>>>>>>>>>>>OpenStack contributor\n>>>>>>>>>>>>>>>Company: UnitedStack\n>>>>>>>>>>>>>>>My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me?\n>>>>>>>>>>>>>>>and I\'ll donate $1 or ?1 to an open organization you specify.\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>>\n>>>>>>>>>>_______________________________________________\n>>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>>\n>>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130911/1ed65e25/attachment.html>\n\n','<1378835754.28581.YahooMailNeo@web193604.mail.sg3.yahoo.com>',NULL),('<1378898967.38416.YahooMailNeo@web194606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-11 19:29:27',28800,'2013-09-11 11:29:27',NULL,'[openstack-dev] Doubt regarding Resource Tracker','Hi,\n\nI have been trying to understand the working of resource tracker.\nI understand that it is responsible to retrieve the data from the host and\nsave it to the database. What I am not able to figure out is how exactly\nthe compute node table is populated for the first time? Because after that\nresource tracker compare the data and update the changes.\nAgain, does resource tracker work periodically? or is it triggered when\nan instance is spawned or deleted?\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130911/8ea3799d/attachment.html>\n\n',NULL,NULL),('<1378898991.59139.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-11 19:29:51',28800,'2013-09-11 11:29:51',NULL,'[Openstack] Doubt regarding Resource Tracker','\n\nHi,\n\nI have been trying to understand the working of resource tracker.\nI understand that it is responsible to retrieve the data from the host and\nsave it to the database. What I am not able to figure out is how exactly\nthe compute node table is populated for the first time? Because after that\nresource tracker compare the data and update the changes.\nAgain, does resource tracker work periodically? or is it triggered when\nan instance is spawned or deleted?\n\nThanks.\n?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130911/4122f4dc/attachment.html>\n\n','<1378898967.38416.YahooMailNeo@web194606.mail.sg3.yahoo.com>',NULL),('<1378900802.10275.YahooMailNeo@web120603.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-11 05:00:02',-25200,'2013-09-11 12:00:02',NULL,'[openstack-community] Problem in Running Openstack Swift!!!','Dear Community Members,\n\nI have installed OpenStack Swift on Ubuntu 13.04 Raring Ringtail using this link:\nhttp://docs.openstack.org/developer/swift/development_saio.html\n\n\nNow when I performed a step 12 of section?http://docs.openstack.org/developer/swift/development_saio.html#setting-up-scripts-for-running-swift?, I am getting this error:\n\nImportError: No module named middleware.reconCan anyone help in this regard. I tried the solution given on this link but no use: https://answers.launchpad.net/swift/+question/204244I ve tried it but nothing happened. I will appreciate if anyone can guide me. Regards,\nMuhammad Raheel Arshad\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130911/15445153/attachment.html>\n\n',NULL,NULL),('<1378905675-sup-53@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-11 07:54:25',-25200,'2013-09-11 14:54:25',NULL,'[openstack-dev] [Heat] How the autoscale API should control\n	scaling in Heat','Excerpts from Steven Hardy\'s message of 2013-09-11 05:59:02 -0700:\n> On Wed, Sep 11, 2013 at 03:51:02AM +0000, Adrian Otto wrote:\n> > It would be better if we could explain Autoscale like this:\n> > \n> > Heat -> Autoscale -> Nova, etc.\n> > -or-\n> > User -> Autoscale -> Nova, etc.\n> > \n> > This approach allows use cases where (for whatever reason) the end user does not want to use Heat at all, but still wants something simple to be auto-scaled for them. Nobody would be scratching their heads wondering why things are going in circles.\n> > \n> > From an implementation perspective, that means the auto-scale service needs at least a simple linear workflow capability in it that may trigger a Heat orchestration if there is a good reason for it. This way, the typical use cases don\'t have anything resembling circular dependencies. The source of truth for how many members are currently in an Autoscaling group should be the Autoscale service, not in the Heat database. If you want to expose that in list-stack-resources output, then cause Heat to call out to the Autoscale service to fetch that figure as needed. It is irrelevant to orchestration. Code does not need to be duplicated. Both Autoscale and Heat can use the same exact source code files for the code that launches/terminates instances of resources.\n> \n> So I take issue with the \"circular dependencies\" statement, nothing\n> proposed so far has anything resembling a circular dependency.\n> \n> I think it\'s better to consider traditional encapsulation, where two\n> projects may very well make use of the same class from a library.  Why is\n> it less valid to consider code reuse via another interface (ReST service)?\n> \n> The point of the arguments to date, AIUI is to ensure orchestration actions\n> and management of dependencies don\'t get duplicated in any AS service which\n> is created.\n> \n\nThis is the crux of the reason that Heat should be involved. In the\ndriving analogy, Heat is not some boot perched on a ladder waiting for\nautoscaling to drop a bowling ball on it to turn the car. It is more\nlike power steering. The driver puts an input into the system, and the\npower steering does the hard work. If you ever need the full power of\npower steering, then designing the system to be able to bypass power\nsteering sometimes will make it _more_ complex, not less.\n\nMeanwhile, as the problems that need to be solved become more complex,\nHeat will be there to simplify the solutions. If it is ever making system\ncontrol more complex, that is Heat\'s failure and we need to make Heat\nsimpler. What we should get out of the habit of is bypassing Heat and\nbuilding new control systems because Heat doesn\'t yet do what we want\nit to do.\n\nTo any who would roll their own orchestration rather than let Heat\ndo it:\n\nIf Heat adds an unacceptable amount of latency, please file a bug.\n\nIf Heat adds complexity, please file a bug.\n\nIf you\'ve already done that.. I owe you a gold star. :)\n\n\n','<20130911125900.GA17409@t430slt.redhat.com>',NULL),('<1378911316-sup-9000@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-11 07:59:08',-25200,'2013-09-11 14:59:08',NULL,'[openstack-dev] [Heat] How the autoscale API should control\n	scaling in Heat','Excerpts from Joshua Harlow\'s message of 2013-09-11 01:00:37 -0700:\n> +1\n> \n> The assertions are not just applicable to autoscaling but to software in general. I hope we can make autoscaling \"just enough\" simple to work.\n> \n> The circular heat<=>trove example is one of those that does worry me a little. It feels like something is not structured right if that it is needed (rube goldberg like). I am not sure what could be done differently, just my gut feeling that something is \"off\".\n> \n\nJoshua, can you elaborate on \"the circular heat<=>trove example\"?\n\nI don\'t see Heat and Trove\'s relationship as circular. Heat has a Trove\nresource, and (soon? now?) Trove can use Heat to simplify its control\nof underlying systems. This is a stack, not a circle, or did I miss\nsomething?\n\n\n','<9DAD6FE3-9E80-49DA-A745-A75DC0C75264@yahoo-inc.com>',NULL),('<1378916739.610828650@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-11 12:25:39',-14400,'2013-09-11 16:25:39',NULL,'[Openstack] Fwd: Making the Hong Kong Summit as inclusive as\n	possible','By social contract, is anyone even *allowed* to disagree in this thread? :P\n\nI like the ideas of adding an explicit anti-discrimination section to our current Code of Conduct and adding \"By registering you agree to abide by our code of conduct\" to the conference registration form/page.\n\n-Alex\n\n-----Original Message-----\nFrom: \"Thierry Carrez\" <thierry at openstack.org>\nSent: Wednesday, September 11, 2013 11:11am\nTo: openstack at lists.openstack.org\nSubject: Re: [Openstack] Fwd: Making the Hong Kong Summit as inclusive as possible\n\nEric Windisch wrote:\n> Are Bill & Ted really our patrons of anti-harassment? We need something\n> more substantial than a Bill & Ted quote. Party on!\n\nI\'m not saying what we have is sufficient. I\'m just accurately\ndescribing the current state.\n\n-- \nThierry Carrez (ttx)\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n',NULL,NULL),('<1378919209-sup-3994@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-11 10:20:18',-25200,'2013-09-11 17:20:18',NULL,'[openstack-dev] [heat][oslo] mysql, sqlalchemy and sql_mode','Excerpts from Steven Hardy\'s message of 2013-09-11 03:37:40 -0700:\n> Hi all,\n> \n> I\'m investigating some issues, where data stored to a text column in mysql\n> is silently truncated if it\'s too big.\n> \n> It appears that the default configuration of mysql, and the sessions\n> established via sqlalchemy is to simply warn on truncation rather than\n> raise an error.\n> \n> This seems to me to be almost never what you want, since on retrieval the\n> data is corrupt and bad/unexpected stuff is likely.\n> \n> This AFAICT is a mysql specific issue[1], which can be resolved by setting\n> sql_mode to \"traditional\"[2,3], after which an error is raised on truncation,\n> allowing us to catch the error before the data is stored.\n> \n> My question is, how do other projects, or oslo.db, handle this atm?\n> \n> It seems we either have to make sure the DB enforces the schema/model, or\n> validate every single value before attempting to store, which seems like an\n> unreasonable burden given that the schema changes pretty regularly.\n> \n> Can any mysql, sqlalchemy and oslo.db experts pitch in with opinions on\n> this?\n\nI do think that setting stricter sql modes is the right way to go.\n\nNote that I worked around this within Heat for JSON fields thusly:\n\nhttps://git.openstack.org/cgit/openstack/heat/commit/?id=1e16ed2d\n\nHowever, I do think we should make it a priority to protect the database\nand the entire service from abnormally large values. The moment at which\nwe are serializing a data structure to the database is a bit late to\nmitigate the cost of handling it. Here is an example of the kind of\nborder protection we need:\n\nhttps://review.openstack.org/#/c/44585/\n\nI want to detect that we overflowed a big column, and I think that if\nit ever actually happens, it is a critical bug.\n\n\n','<20130911103739.GA7595@t430slt.redhat.com>',NULL),('<1378922787-sup-5852@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-11 11:10:39',-25200,'2013-09-11 18:10:39',NULL,'[openstack-dev] [Heat] How the autoscale API should control\n	scaling in Heat','Excerpts from Joshua Harlow\'s message of 2013-09-11 09:11:06 -0700:\n> Sure,\n> \n> I was thinking that since heat would do autoscaling persay, then heat would say ask trove to make more databases (autoscale policy here) then this would cause trove to actually callback into heat to make more instances.\n> \n> Just feels a little weird, idk.\n> \n> Why didn\'t heat just make those instances \"on behalf of trove\" to begin with and then tell trove \"make these instances into databases\". Then trove doesn\'t really need to worry about calling into heat to do the instance creation \"work\", and trove can just worry about converting those \"blank instances \" into databases (for example).\n> \n> But maybe I am missing other context also :)\n> \n\nThat sort of optimization would violate encapsulation and make the system\nmore complex.\n\nHeat doing Trove\'s provisioning and coordinating Trove\'s interaction with\nother pieces of the system is an implementation detail, safely hidden\nbehind Trove. Interaction between other pieces of the end user\'s stack\nand Trove is limited to what Trove wants to expose.\n\n\n','<F09086A5-0639-46B1-9FAC-276604718658@yahoo-inc.com>',NULL),('<1378956326.20243.22.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-12 13:25:26',36000,'2013-09-12 03:25:26',NULL,'[openstack-dev] [Keystone] Enforcing cert validation in auth_token\n	middleware','With the aim of replacing httplib and cert validation with requests[1]\nI\'ve put forward the following review to use the requests library for\nauth_token middleware. \n\nhttps://review.openstack.org/#/c/34161/\n\nThis adds 2 new config options.\n- The ability to provide CAs to validate https connections against.\n- The ability to set insecure to ignore https validation. \n\nBy default request will validate connections against the system CAs by\ndefault. So given that we currently don\'t verify SSL connections, do we\nneed to default insecure to true?\n\nMaintaining compatibility should win here as i imagine there are a great\nnumber of auth_token deployments using SSL with invalid/self-signed\ncertificates that would be broken, but defaulting to insecure just seems\nwrong. \n\nGiven that keystone isn\'t the only project moving away from httplib, how\nare other projects handling this? How do we end up with reasonable\ndefaults? Is there any amount of warning that we could give to change a\ndefault like this - or is this another one of those version 1.0 issues?\n\n\nJamie\n\n\n\n[1] https://bugs.launchpad.net/keystone/+bug/1188189 \n\n\n\n',NULL,NULL),('<1378965953.55607.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-12 14:05:53',28800,'2013-09-12 06:05:53',NULL,'[Openstack] problem in preparing and labeling the drives in order\n	to mount them','I have to prepare and label the drives in order to mount them.\nI run some commands to survey what\'s on the system:\nroot at arun-Aspire-5742:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda4 177866264 4164648 164666508 3% / udev 2918600 4 2918596 1% /dev tmpfs 1170364 892 1169472 1% /run none 5120 4 5116 1% /run/lock none 2925908 216 2925692 1% /run/shm\nroot at arun-Aspire-5742:~# cat /proc/mounts rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0 /dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 gvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\nroot at arun-Aspire-5742:~# ls /sys/block loop0 loop3 loop6 ram1 ram12 ram15 ram4 ram7 sda sr1 loop1 loop4 loop7 ram10 ram13 ram2 ram5 ram8 sdb loop2 loop5 ram0 ram11 ram14 ram3 ram6 ram9 sr0\nroot at arun-Aspire-5742:~# sudo blkid /dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\" /dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\" /dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\" /dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\" /dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\" /dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\" /dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2 mkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\nmkfs.xfs: Use the -f option to force overwrite.\nNow, my problem is: I don\'t understand which device should I label as \"d1\"? how many devices should I label as \"d1\", \"d2\" etc.?\nPlease help me in this regard.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130912/915e3103/attachment.html>\n\n',NULL,NULL),('<1378966005.47414.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-12 14:06:45',28800,'2013-09-12 06:06:45',NULL,'[Openstack] Fw: problem in preparing and labeling the drives in\n	order to mount them','\n\n\n\n----- Forwarded Message -----\n>From: pragya jain <prag_2648 at yahoo.co.in>\n>To: \"clay.gerrard at gmail.com\" <clay.gerrard at gmail.com> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 12 September 2013 11:35 AM\n>Subject: problem in preparing and labeling the drives in order to mount them\n> \n>\n>\n>I have to prepare and label the drives in order to mount them.\n>I run some commands to survey what\'s on the system:\n>root at arun-Aspire-5742:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda4 177866264 4164648 164666508 3% / udev 2918600 4 2918596 1% /dev tmpfs 1170364 892 1169472 1% /run none 5120 4 5116 1% /run/lock none 2925908 216 2925692 1% /run/shm\n>root at arun-Aspire-5742:~# cat /proc/mounts rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0 /dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 gvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\n>root at arun-Aspire-5742:~# ls /sys/block loop0 loop3 loop6 ram1 ram12 ram15 ram4 ram7 sda sr1 loop1 loop4 loop7 ram10 ram13 ram2 ram5 ram8 sdb loop2 loop5 ram0 ram11 ram14 ram3 ram6 ram9 sr0\n>root at arun-Aspire-5742:~# sudo blkid /dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\" /dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\" /dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\" /dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\" /dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\" /dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\" /dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"\n>root at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2 mkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\n>mkfs.xfs: Use the -f option to force overwrite.\n>Now, my problem is: I don\'t understand which device should I label as \"d1\"? how many devices should I label as \"d1\", \"d2\" etc.?\n>Please help me in this regard.\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130912/39fc07d3/attachment.html>\n\n','<1378965953.55607.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1378966300.79577.YahooMailNeo@web120604.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-11 23:11:40',-25200,'2013-09-12 06:11:40',NULL,'[openstack-community] Problem in Running Openstack Swift!!!','Then what\'s this place for? Can you please guide. I am a beginner in OpenStack and don\'t know much\n\nRegards,\nRaheel\n\n\n________________________________\n From: Stefano Maffulli <stefano at openstack.org>\nTo: Muhammad Raheel Arshad <raheel_com88 at yahoo.com> \nCc: \"community at lists.openstack.org\" <community at lists.openstack.org> \nSent: Thursday, September 12, 2013 2:21 AM\nSubject: Re: [openstack-community] Problem in Running Openstack Swift!!!\n \n\nHello Muhammad\n\nOn Wed 11 Sep 2013 05:00:02 AM PDT, Muhammad Raheel Arshad wrote:\n> I have installed OpenStack Swift on Ubuntu 13.04 Raring Ringtail using\n> this link:\n> http://docs.openstack.org/developer/swift/development_saio.html\n[...]\n\nthis is not the right place to ask such question. Please use \nhttps://ask.openstack.org or the General mailing list \nhttps://wiki.openstack.org/wiki/MailingLists#General_List, if you \nprefer.\n\nRegards,\nStefano\n\n--\nAsk and answer questions on https://ask.openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130911/7aa4535a/attachment-0001.html>\n\n','<5230DECE.9070300@openstack.org>',NULL),('<1379007046.83893012@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-12 13:30:46',-14400,'2013-09-12 17:30:46',NULL,'[Openstack] Nova Client CLI Tool: Configure nova client CLI\n	tool to consume image APIs from Glance service','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130912/dd333181/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 5929 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130912/dd333181/attachment.jpg>\n\n','<7A0D7FA093BE9640AB68E72FFCD595400D133A@FR712WXCHMBA09.zeu.alcatel-lucent.com\n >',NULL),('<1379017602.1613.31.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-12 15:26:42',-18000,'2013-09-12 20:26:42',NULL,'[openstack-dev] Block Device Mapping: progress,\n	issues and future RFEs','All,\n\nNikola has been working on some very helpful improvements to the block\ndevice mapping code.  These are being tracked here:\n\nhttps://blueprints.launchpad.net/nova/+spec/improve-block-device-handling\n\nWe have been using these new features during development of our native\nimage building tool for Nova.  We\'re slightly uncertain about which\nelements of this feature will be landing in Havana and wanted to discuss\non-list.\n\nOur understanding is that the following types of mappings are possible\nwith code changes targeted for Havana:\n\n1) When using purely cinder volumes, essentially any combination of the\nmapping types listed in the feature specification is now possible.\n\n2) Glance images may also be specified in the device mapping structure,\nbut they will be converted to volumes prior to instance launch.\n\n3) A single glance image may be passed in at launch time, in concert\nwith any of the mappings above, and will be mapped and otherwise behave\nin the same way as it would in the absence of any mappings.\n\n\nOne feature that we do not expect, but would like to see in future\nrevisions:\n\n4) RFE: Multiple glance images mapped in as arbitrary block devices but not\nconverted to volumes.  These would instead be temporary/ephemeral copies\nof the glance content, ideally with the possibility of caching.  This\nwould allow us to, among other things, launch an instance with a \"blank\"\nglance root disk image as well as a glance backed version of the\ninstallation ISO image for a given OS.  It would also allow for ISO\nbacked installations even in environments where cinder is not present. \n\n\nThus far we have encountered the following issues:\n\n1) When mapping a volume as a cdrom device, it is still presented as a\ndisk device.  This is reported here:\n\nhttps://bugs.launchpad.net/nova/+bug/1223890\n\n2) When passing in a glance image combined with the v2 block device\nmappings, the glance image seems to be ignored - Only the mapped block\ndevices are present.  Having this work in the way described above would\nbe very helpful as it would allow us to continue to save the results of\nour native installs via glance snapshots.  Without this change, any\ninstalls that require a mapped block device (which means any install\nthat uses an ISO image) must be done to a volume backed block device.\nThis, in turn, makes delivering the result as a glance image\nsignificantly more complicated.\n\nThoughts?\n\n-Ian\n\n\n\n',NULL,NULL),('<1379096074-sup-4903@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-13 11:35:43',-25200,'2013-09-13 18:35:43',NULL,'[openstack-dev] TC Meeting / Savanna Incubation Follow-Up','Excerpts from Michael Basnight\'s message of 2013-09-13 08:26:07 -0700:\n> On Sep 13, 2013, at 6:56 AM, Alexander Kuznetsov wrote:\n> > On Thu, Sep 12, 2013 at 7:30 PM, Michael Basnight <mbasnight at gmail.com> wrote:\n> > On Sep 12, 2013, at 2:39 AM, Thierry Carrez wrote:\n> > \n> > > Sergey Lukjanov wrote:\n> > >\n> > >> [...]\n> > >> As you can see, resources provisioning is just one of the features and the implementation details are not critical for overall architecture. It performs only the first step of the cluster setup. We?ve been considering Heat for a while, but ended up direct API calls in favor of speed and simplicity. Going forward Heat integration will be done by implementing extension mechanism [3] and [4] as part of Icehouse release.\n> > >>\n> > >> The next part, Hadoop cluster configuration, already extensible and we have several plugins - Vanilla, Hortonworks Data Platform and Cloudera plugin started too. This allow to unify management of different Hadoop distributions under single control plane. The plugins are responsible for correct Hadoop ecosystem configuration at already provisioned resources and use different Hadoop management tools like Ambari to setup and configure all cluster  services, so, there are no actual provisioning configs on Savanna side in this case. Savanna and its plugins encapsulate the knowledge of Hadoop internals and default configuration for Hadoop services.\n> > >\n> > > My main gripe with Savanna is that it combines (in its upcoming release)\n> > > what sounds like to me two very different services: Hadoop cluster\n> > > provisioning service (like what Trove does for databases) and a\n> > > MapReduce+ data API service (like what Marconi does for queues).\n> > >\n> > > Making it part of the same project (rather than two separate projects,\n> > > potentially sharing the same program) make discussions about shifting\n> > > some of its clustering ability to another library/project more complex\n> > > than they should be (see below).\n> > >\n> > > Could you explain the benefit of having them within the same service,\n> > > rather than two services with one consuming the other ?\n> > \n> > And for the record, i dont think that Trove is the perfect fit for it today. We are still working on a clustering API. But when we create it, i would love the Savanna team\'s input, so we can try to make a pluggable API thats usable for people who want MySQL or Cassandra or even Hadoop. Im less a fan of a clustering library, because in the end, we will both have API calls like POST /clusters, GET /clusters, and there will be API duplication between the projects.\n> > \n> > I think that Cluster API (if it would be created) will be helpful not only for Trove and Savanna.  NoSQL, RDBMS and Hadoop are not unique software which can be clustered. What about different kind of messaging solutions like RabbitMQ, ActiveMQ or J2EE containers like JBoss, Weblogic and WebSphere, which often are installed in clustered mode. Messaging, databases, J2EE containers and Hadoop have their own management cycle. It will be confusing to make Cluster API a part of Trove which has different mission - database management and provisioning.\n> \n> Are you suggesting a 3rd program, cluster as a service? Trove is trying to target a generic enough? API to tackle different technologies with plugins or some sort of extensions. This will include a scheduler to determine rack awareness. Even if we decide that both Savanna and Trove need their own API for building clusters, I still want to understand what makes the Savanna API and implementation different, and how Trove can build an API/system that can encompass multiple datastore technologies. So regardless of how this shakes out, I would urge you to go to the Trove clustering summit session [1] so we can share ideas.\n> \n\nKudos to Trove for pushing forward on their Heat implementation. I\'d\nlike to see Savannah go in the same direction. I read the \"why not heat\"\nand it is all a bug list for Heat. Lets fix those bugs so that the next\nclusterable solution that needs a simplified API can just grab Heat and\nget it done without a special domain specific orchestration backend.\n\nIf the backend were shared, would we care so much that there is no common\n\"clustering\" imperative API for users?\n\nThis way Savanna\'s API is focused on helping users solve their \"data\nprocessing\" problems, and Trove is focused on helping users solve their\n\"data storage\" problems. And if users need to build a cluster of things\nthat don\'t exist yet as a handy simplified API, Heat is there for them\nas a general purpose tool for building clusters.\n\n\n','<3B24626A-164E-474E-AA98-01B59713BEB2@gmail.com>',NULL),('<1379110271.4331.15.camel@goku>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-13 17:11:11',-18000,'2013-09-13 22:11:11',NULL,'[Openstack] openstack meta-data','Is it possible to update instance meta-data, for example to set the\npublic hostname?\n\nThanks in advance,\nFrancesco\n\n\n\n',NULL,NULL),('<1379136093.65084.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-14 13:21:33',28800,'2013-09-14 05:21:33',NULL,'[Openstack] problem in preparing and labeling the drives in order\n	to mount them for configuring openstack swift','hello sir,\nI have to prepare and label the drives in order to mount them.\nI run some commands to survey what\'s on the system:\nroot at arun-Aspire-5742:~# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda4 177866264 4164648 164666508 3% / udev 2918600 4 2918596 1% /dev tmpfs 1170364 892 1169472 1% /run none 5120 4 5116 1% /run/lock none 2925908 216 2925692 1% /run/shm\nroot at arun-Aspire-5742:~# cat /proc/mounts rootfs / rootfs rw 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,relatime,size=2918600k,nr_inodes=198985,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,relatime,size=1170364k,mode=755 0 0 /dev/disk/by-uuid/5259827c-cc52-43f4-bc2c-7aac2f927b02 / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0 none /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /sys/kernel/debug debugfs rw,relatime 0 0 none /sys/kernel/security securityfs rw,relatime 0 0 none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0 gvfs-fuse-daemon /home/arun/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0\nroot at arun-Aspire-5742:~# ls /sys/block loop0 loop3 loop6 ram1 ram12 ram15 ram4 ram7 sda sr1 loop1 loop4 loop7 ram10 ram13 ram2 ram5 ram8 sdb loop2 loop5 ram0 ram11 ram14 ram3 ram6 ram9 sr0\nroot at arun-Aspire-5742:~# sudo blkid /dev/sda1: LABEL=\"System Reserved\" UUID=\"12BA0286BA026717\" TYPE=\"ntfs\" /dev/sda2: UUID=\"D8EA06E4EA06BEAE\" TYPE=\"ntfs\" /dev/sda4: UUID=\"5259827c-cc52-43f4-bc2c-7aac2f927b02\" TYPE=\"ext4\" /dev/sda5: UUID=\"8AE41BA8E41B9613\" TYPE=\"ntfs\" /dev/sda6: UUID=\"3A14E4D814E497E1\" TYPE=\"ntfs\" /dev/sda7: UUID=\"a7c2ed39-1081-4702-9aed-a42b80a07cff\" TYPE=\"swap\" /dev/sr1: LABEL=\"20110729_053228\" TYPE=\"iso9660\"\nroot at arun-Aspire-5742:~# sudo mkfs.xfs -L d1 /dev/sda2 mkfs.xfs: /dev/sda2 appears to contain an existing filesystem (ntfs).\nmkfs.xfs: Use the -f option to force overwrite.\nNow, my problem is: I don\'t understand which device should I label as \"d1\"? how many devices should I label as \"d1\", \"d2\" etc.?\nPlease help me in this regard.\n----\n\nThanks\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130914/9bcb7d49/attachment.html>\n\n',NULL,NULL),('<1379183993.4086.12.camel@goku>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-14 13:39:53',-18000,'2013-09-14 18:39:53',NULL,'[Openstack] openstack meta-data','Hello,\nthanks for the help! I hadn\'t seen the command in the documentation,\nthis can be helpful.\nBTW my problem is to update metadata every time a machine is launched.\nFor example let\'s talk about the hostname. Every time I launch a\nmachine, I would like to have well-configured metadata, with the\nparameter public-hostname already set to a customized value. I don\'t\nwant the instance name as public-hostname.\n\nI hope I was clear and thanks again for the help,\nFrancesco\n\n\n\nOn Sat, 2013-09-14 at 07:18 +0000, Tim Bell wrote:\n> You can update the metadata associated with an instance using the \'nova meta\' command. However, this only updates the metadata (i.e.\n> key value pairs) rather than the other attributes.\n> \n> Changing the server name would not alter the hostname of the VM, it would only alter the description in Nova.\n> \n> Can you explain a little more what you would like to be doing ?\n> \n> Tim\n> \n> > -----Original Message-----\n> > From: Francesco Ceccarelli [mailto:ceccarel at fnal.gov]\n> > Sent: 14 September 2013 00:11\n> > To: openstack at lists.openstack.org\n> > Subject: [Openstack] openstack meta-data\n> > \n> > Is it possible to update instance meta-data, for example to set the public hostname?\n> > \n> > Thanks in advance,\n> > Francesco\n> > \n> > \n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D971B85A@CERNXCHG01.cern.ch>',NULL),('<1379337129.64166.YahooMailBasic@web121603.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-16 06:12:09',-25200,'2013-09-16 13:12:09',NULL,'[Openstack] Object versioning not working','Hi,\n\nI am trying swift object versioning using swift CLIs (using swift post to change meta data).\nIn container-server.conf, I have set the flag allow_versions = true.\n\nWith CLI, I added meta data as follows:\n\n swift stat testing\n  Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\nContainer: testing\n  Objects: 3\n    Bytes: 157\n Read ACL: -v\nWrite ACL: \n  Sync To: \n Sync Key: \nMeta X-Versions-Location: test_cont\nAccept-Ranges: bytes\nX-Timestamp: 1379065681.40505\nContent-Type: text/plain; charset=utf-8\n\n\nswift stat test_cont\n  Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\nContainer: test_cont\n  Objects: 3\n    Bytes: 42\n Read ACL: \nWrite ACL: \n  Sync To: \n Sync Key: \nAccept-Ranges: bytes\nX-Timestamp: 1379066009.84224\nContent-Type: text/plain; charset=utf-8\n\nIf I upload a new content of the object in testing container, I am expecting a version to be created in test_cont container.\nBut it is not the case.\n\nI was expecting once the flag is set and meta data is changed, old versions should be stored in test_cont dirs but it is not the case\nEven swift restart didn\'t help.\n\nAny idea ? if my expectation is wrong or swift versioning has issues?\nI am using swift 1.4.0 version\n\nswift --version\nswift 1.4.0\n\nThanks for your time\n\nRaghavendra\n\n\n\n\n',NULL,NULL),('<1379409395.65102.YahooMailBasic@web121603.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-17 02:16:35',-25200,'2013-09-17 09:16:35',NULL,'[Openstack] Object versioning not working','Hi,\n\nThanks for the clarification. \n\nMay be a different thread but I have issue generating tokens.\nI am using RDO all in one openstack with swift installed (with authtoken).\nThe reason I tried swift CLI was I am not getting how to generate the auth token to give it in curl commands.\nWith web search, whatever token I generate, I am getting unauthorized when I run command like below you gave.\n\nAny webpage, discussions or document explaining generating swift token and using  it in curl can be helpful as it has blocked my work.\nCurrent set of openstack documents lack examples for using authtoken.\n\nThanks\nRaghavendra\n\n\n\n\n--------------------------------------------\nOn Tue, 9/17/13, Clay Gerrard <clay.gerrard at gmail.com> wrote:\n\n Subject: Re: [Openstack] Object versioning not working\n To: \"Raghavendra Rangrej\" <rrrangrej at yahoo.com>\n Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n Date: Tuesday, September 17, 2013, 2:13 AM\n \n If you look at the raw API\n response from a HEAD on the \"testing\" container\n (maybe with curl) I think you\'ll see that you\'ve set\n the wrong metadata key.\n You should set \"X-Version-Location:\n test_cont\" instead of\n \"X-Container-Meta-X-Version-Location:\n test_cont\"\n \n The `-m` option for `swift post` is only for\n setting user metadata; unfortunately it doesn\'t look\n like you can set arbitrary headers with `swift\n post`:\n https://bugs.launchpad.net/swift/+bug/1226256\n \n \n I did this:\n curl -H \'x-auth-token:\n <your-auth-token-goes-here>\' http://localhost:8080/v1/AUTH_test/testing\n -X POST -H \'x-versions-location: test_cont\'\n \n \n -Clay\n \n \n On Mon, Sep 16, 2013 at\n 6:12 AM, Raghavendra Rangrej <rrrangrej at yahoo.com>\n wrote:\n \n Hi,\n \n \n \n I am trying swift object versioning using swift CLIs (using\n swift post to change meta data).\n \n In container-server.conf, I have set the flag allow_versions\n = true.\n \n \n \n With CLI, I added meta data as follows:\n \n \n \n ?swift stat testing\n \n ? Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\n \n Container: testing\n \n ? Objects: 3\n \n ? ? Bytes: 157\n \n ?Read ACL: -v\n \n Write ACL:\n \n ? Sync To:\n \n ?Sync Key:\n \n Meta X-Versions-Location: test_cont\n \n Accept-Ranges: bytes\n \n X-Timestamp: 1379065681.40505\n \n Content-Type: text/plain; charset=utf-8\n \n \n \n \n \n swift stat test_cont\n \n ? Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\n \n Container: test_cont\n \n ? Objects: 3\n \n ? ? Bytes: 42\n \n ?Read ACL:\n \n Write ACL:\n \n ? Sync To:\n \n ?Sync Key:\n \n Accept-Ranges: bytes\n \n X-Timestamp: 1379066009.84224\n \n Content-Type: text/plain; charset=utf-8\n \n \n \n If I upload a new content of the object in testing\n container, I am expecting a version to be created in\n test_cont container.\n \n But it is not the case.\n \n \n \n I was expecting once the flag is set and meta data is\n changed, old versions should be stored in test_cont dirs but\n it is not the case\n \n Even swift restart didn\'t help.\n \n \n \n Any idea ? if my expectation is wrong or swift versioning\n has issues?\n \n I am using swift 1.4.0 version\n \n \n \n swift --version\n \n swift 1.4.0\n \n \n \n Thanks for your time\n \n \n \n Raghavendra\n \n \n \n \n \n \n \n _______________________________________________\n \n Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n \n Post to ? ? : openstack at lists.openstack.org\n \n Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n \n \n \n \n\n\n','<CA+_JKzr6=qj8ePHmqJe=N_Jb-WLaPXJVq-aPB80uEzwg3J_ZKw@mail.gmail.com>',NULL),('<1379414213.60377.YahooMailBasic@web121606.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-17 03:36:53',-25200,'2013-09-17 10:36:53',NULL,'[Openstack] Object versioning not working','Hi,\n\nI got hold of generating tokens two ways. For the benefit of  future users having similar query (archiving), putting it below.\n\n1. keystone token-get\n\nOR \n\n2. curl -d \'{\"auth\":{\"tenantName\": \"tenantname\", \n\"passwordCredentials\":{\"username\": \"nik\", \"password\": \"password\"}}}\' -H \n\"Content-type: application/json\" http://IP:35357/v2.0/tokens \n\nThanks\nRaghavendra\n\n--------------------------------------------\nOn Tue, 9/17/13, Raghavendra Rangrej <rrrangrej at yahoo.com> wrote:\n\n Subject: Re: [Openstack] Object versioning not working\n To: \"Clay Gerrard\" <clay.gerrard at gmail.com>\n Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n Date: Tuesday, September 17, 2013, 2:46 PM\n \n Hi,\n \n Thanks for the clarification. \n \n May be a different thread but I have issue generating\n tokens.\n I am using RDO all in one openstack with swift installed\n (with authtoken).\n The reason I tried swift CLI was I am not getting how to\n generate the auth token to give it in curl commands.\n With web search, whatever token I generate, I am getting\n unauthorized when I run command like below you gave.\n \n Any webpage, discussions or document explaining generating\n swift token and using? it in curl can be helpful as it\n has blocked my work.\n Current set of openstack documents lack examples for using\n authtoken.\n \n Thanks\n Raghavendra\n \n \n \n \n --------------------------------------------\n On Tue, 9/17/13, Clay Gerrard <clay.gerrard at gmail.com>\n wrote:\n \n  Subject: Re: [Openstack] Object versioning not working\n  To: \"Raghavendra Rangrej\" <rrrangrej at yahoo.com>\n  Cc: \"openstack at lists.openstack.org\"\n <openstack at lists.openstack.org>\n  Date: Tuesday, September 17, 2013, 2:13 AM\n  \n  If you look at the raw API\n  response from a HEAD on the \"testing\" container\n  (maybe with curl) I think you\'ll see that you\'ve set\n  the wrong metadata key.\n  You should set \"X-Version-Location:\n  test_cont\" instead of\n  \"X-Container-Meta-X-Version-Location:\n  test_cont\"\n  \n  The `-m` option for `swift post` is only for\n  setting user metadata; unfortunately it doesn\'t look\n  like you can set arbitrary headers with `swift\n  post`:\n  https://bugs.launchpad.net/swift/+bug/1226256\n  \n  \n  I did this:\n  curl -H \'x-auth-token:\n  <your-auth-token-goes-here>\' http://localhost:8080/v1/AUTH_test/testing\n  -X POST -H \'x-versions-location: test_cont\'\n  \n  \n  -Clay\n  \n  \n  On Mon, Sep 16, 2013 at\n  6:12 AM, Raghavendra Rangrej <rrrangrej at yahoo.com>\n  wrote:\n  \n  Hi,\n  \n  \n  \n  I am trying swift object versioning using swift CLIs\n (using\n  swift post to change meta data).\n  \n  In container-server.conf, I have set the flag\n allow_versions\n  = true.\n  \n  \n  \n  With CLI, I added meta data as follows:\n  \n  \n  \n  ?swift stat testing\n  \n  ? Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\n  \n  Container: testing\n  \n  ? Objects: 3\n  \n  ? ? Bytes: 157\n  \n  ?Read ACL: -v\n  \n  Write ACL:\n  \n  ? Sync To:\n  \n  ?Sync Key:\n  \n  Meta X-Versions-Location: test_cont\n  \n  Accept-Ranges: bytes\n  \n  X-Timestamp: 1379065681.40505\n  \n  Content-Type: text/plain; charset=utf-8\n  \n  \n  \n  \n  \n  swift stat test_cont\n  \n  ? Account: AUTH_1335922166fb4c43a4929f4fba670f3712dw\n  \n  Container: test_cont\n  \n  ? Objects: 3\n  \n  ? ? Bytes: 42\n  \n  ?Read ACL:\n  \n  Write ACL:\n  \n  ? Sync To:\n  \n  ?Sync Key:\n  \n  Accept-Ranges: bytes\n  \n  X-Timestamp: 1379066009.84224\n  \n  Content-Type: text/plain; charset=utf-8\n  \n  \n  \n  If I upload a new content of the object in testing\n  container, I am expecting a version to be created in\n  test_cont container.\n  \n  But it is not the case.\n  \n  \n  \n  I was expecting once the flag is set and meta data is\n  changed, old versions should be stored in test_cont dirs\n but\n  it is not the case\n  \n  Even swift restart didn\'t help.\n  \n  \n  \n  Any idea ? if my expectation is wrong or swift versioning\n  has issues?\n  \n  I am using swift 1.4.0 version\n  \n  \n  \n  swift --version\n  \n  swift 1.4.0\n  \n  \n  \n  Thanks for your time\n  \n  \n  \n  Raghavendra\n  \n  \n  \n  \n  \n  \n  \n  _______________________________________________\n  \n  Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n  \n  Post to ? ? : openstack at lists.openstack.org\n  \n  Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n  \n  \n  \n \n \n\n\n','<1379409395.65102.YahooMailBasic@web121603.mail.ne1.yahoo.com>',NULL),('<1379449775.769824428@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-17 16:29:35',-14400,'2013-09-17 20:29:35',NULL,'[openstack-dev] [nova] Review request','Hi all!\n\nI have a patch up for allowing Nova to talk to Glance via either the V1 or V2 API. This is currently blocked by the feature freeze, but if some folks could look at it so I can have it ready to roll when the freeze ends I\'d really appreciate it!\n\nhttps://review.openstack.org/#/c/46507/\n\nThanks,\n\nEddie\n\n\n\n\n',NULL,NULL),('<1379449899.588923432@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-17 16:31:39',-14400,'2013-09-17 20:31:39',NULL,'[openstack-dev] [python-glanceclient] Review request','Hi,\n\nCould I get some reviews on this patch? It\'s adding CLI support for using Glance V2 API from the client.\n\nhttps://review.openstack.org/#/c/42741/\n\nThanks,\n\nEddie\n\n\n\n\n',NULL,NULL),('<1379513613.029913077@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-18 10:13:33',-14400,'2013-09-18 14:13:33',NULL,'[openstack-dev] [python-glanceclient] Review request','(Hope this isn\'t a dup - sent it yesterday but never saw it come through tho another I sent around the same time did. My apologies if it is.)\n\nHi,\n\nCould I get some reviews on this patch? It\'s adding CLI support for using Glance V2 API from the client.\n\nhttps://review.openstack.org/#/c/42741/\n\nThanks,\n\nEddie\n\n\n\n\n\n',NULL,NULL),('<1379518939.504116829@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-18 11:42:19',-14400,'2013-09-18 15:42:19',NULL,'[openstack-dev] [glance] Review request','(Hope this isn\'t a dup - sent it earlier but never saw it come through. My apologies if it is.)\n\nHi,\n\nCould I get some reviews on this patch? It\'s adding CLI support for using Glance V2 API from the client.\n\nhttps://review.openstack.org/#/c/42741/\n\nThanks,\n\nEddie\n\n\n\n\n\n\n',NULL,NULL),('<1379538050.23890.16.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-18 17:00:50',-14400,'2013-09-18 21:00:50',NULL,'[Openstack-docs] Basic Install Guides','Hi Solly,\n\nAs Andreas and Anne mentioned, I\'m working on restructuring things so we\ndon\'t have a separate \"basic\" install guide. The install guide will be\nstructured such that the first few chapters give a basic install, and\nyou can pick and choose the later chapters to add or change services.\n\nI was planning on having the basic portion just use nova-network, based\non the feedback I\'ve gotten from others. Although there\'s concern that\nstarting with a nova-network-based install and swapping in Neutron will\nbe too difficult.\n\nI could use help with the Neutron chapter, or it probably won\'t end up\nin the Havana release. I\'m trying to get a patch in tonight. Then we can\ntalk about where to fit stuff in.\n\nThanks,\nShaun\n\nOn Wed, 2013-09-18 at 15:52 -0400, Solly Ross wrote:\n> Does the Install Guide specifically avoid including documentation on\n> Neutron setups, or is that just something that needs to be done?\n> \n> ----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Solly Ross\" <sross at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Wednesday, September 18, 2013 3:37:15 PM\n> Subject: Re: [Openstack-docs] Basic Install Guides\n> \n> On 09/18/2013 09:29 PM, Solly Ross wrote:\n> > Hello All,\n> > I wanted to inquire as to the state/future of the basic install\n> guides.  Currently, as far a I can tell, there are three \"basic\n> install guides\": the one at the root of the basic install docs\n> (http://docs.openstack.org/trunk/basic-install/content/basic-install_intro.html), which seems to be the most robust although slightly out of date wrt the naming of neutron; the yum-specific guide; and the apt-specific guide (which is a bit of a misnomer, since the first guide is also written for apt).  While the latter two appear to be more up to date with naming, they are also much less detailed and seem to leave out important information.\n> > \n> > I have followed the first of the listed basic install guides in an\n> attempt to convert its more detailed information to\n> Fedora/RHEL-compatible instructions.\n> > \n> > My question is this: which basic install guides should get updated?\n> The tool-specific guides (the latter two) appear to target a slightly\n> different setup than the first guide.  Should the first of the three\n> guides be removed and its instructions merged into the APT-specific\n> guide?  Should the APT-specific guide be scrapped (with an updated\n> version of the first guide taking its place) and the yum-specific\n> guide updated to match the setup of the first guide?\n> \n> In general, update the version that is the git master. We had build\n> all\n> guides from the same sources.\n> \n> *BUT* with the current restructering of the documentation, the basic\n> install guide is dead and will not be published for future releases.\n> \n> You should put your efforts in the Install Guide, it\'s in the git repo\n> under \"doc/install-guide\" - and build in three different versions from\n> the same sources.\n> \n> The current set of books that we plan to release for Havana are\n> available via http://docs.openstack.org/trunk/\n> \n> Andreas\n\n\n\n\n','<1569960459.24369223.1379533933922.JavaMail.root@redhat.com>',NULL),('<1379560692.2374.16.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-19 13:18:12',36000,'2013-09-19 03:18:12',NULL,'[Openstack] Keystone pluggable auth?','Can you clarify a bit please? Keystone is working on a pluggable auth\nmodel based off nova\'s, however it isn\'t implemented yet. \n\nIf you mean choosing the identity api version for working with nova i\ncan\'t really help there.\n\nJamie \n\n\nOn Mon, 2013-09-16 at 11:36 -0600, Wyllys Ingersoll wrote:\n> \n> \n> Just wondering if the new pluggable auth feature for Keystone is only\n> available for V3 auth protocol or if it can work with v2 also?\n> \n> \n> -Wyllys Ingersoll\n>  Evault\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n','<CE5CB9DC.4EC1%wyllys.ingersoll@evault.com>',NULL),('<1379573071.25010.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-19 14:44:31',28800,'2013-09-19 06:44:31',NULL,'[openstack-dev] Error during puppet run','Hi all,\n\nI have been trying to install openstack using packstack on\nFedora 19. Now, when I run \"packstack --allinone\", I get the?\nfollowing error:\n\n?ERROR : Error during puppet run : Error: mysqladmin -u root ?password \'b6ca73d0f2c4444e\' returned 1 instead of one of [0]\n\nCan anyone help me to figure out why am I facing this issue?\n\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130919/6fac35fe/attachment.html>\n\n',NULL,NULL),('<1379616161.19266.YahooMailNeo@web194606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 02:42:41',28800,'2013-09-19 18:42:41',NULL,'[openstack-dev] Error during puppet run','Hi Craig,\n\nThanks for your answer. I removed everything and it eventually (after removing\nseveral errors!) worked. But I am stuck at one point. Now, the error says:\n\nERROR : Error during puppet run : Error: Could not start Service[httpd]: Execution of \'/sbin/service httpd start\' returned 1:\n\n\nAny idea about this?\n\nThanks,\n?\n~Peeyush Gupta\n\n\n________________________________\n From: Craig E. Ward <cward at isi.edu>\nTo: Peeyush Gupta <gpeeyush at ymail.com>; OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Thursday, 19 September 2013 9:18 PM\nSubject: Re: [openstack-dev] Error during puppet run\n \n\nThe mysqladmin command returned an error status. It could be that your mysql root password is different from the one used by packstack, which passes it down to puppet. You could run the command in an interactive shell and see what error message gets produced.\n\nIf the system already had mysql installed, the root account password likely was already set. If you don\'t need that installation, uninstall mysql, remove its directories, and let packstack install it again. The command that failed probably was issued because packstack/puppet assumed a fresh install and tried to set the root password to something other than null. (A good thing to do with a fresh install of mysql.)\n\nIf you need any of the databases already in mysql, then you\'ll need to find a way to tell packstack to not have puppet do the install. I\'ve only performed some simple experimental installations using packstack; I don\'t know how to tell it not to install mysql.\n\nCraig\n\n\nOn 9/18/13 11:44 PM, Peeyush Gupta wrote:\n> Hi all,\n> \n> I have been trying to install openstack using packstack on\n> Fedora 19. Now, when I run \"packstack --allinone\", I get the\n> following error:\n> \n>?  ERROR : Error during puppet run : Error: mysqladmin -u root? password \'b6ca73d0f2c4444e\' returned 1 instead of one of [0]\n> \n> Can anyone help me to figure out why am I facing this issue?\n> \n> Thanks,\n> ~Peeyush Gupta\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- Craig E. Ward\nUniversity of Southern California\nInformation Sciences Institute\ncward at ISI.EDU\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/a0c147c9/attachment.html>\n\n','<523B1CCB.5050309@ISI.EDU>',NULL),('<1379622623.7974.125.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-19 13:30:23',-25200,'2013-09-19 20:30:23',NULL,'[openstack-dev] Client and Policy','On Thu, 2013-09-19 at 15:22 -0500, Dolph Mathews wrote:\n> \n> On Thu, Sep 19, 2013 at 2:59 PM, Adam Young <ayoung at redhat.com> wrote:\n>         I can submit a summit proposal.  I was thinking of making it\n>         more general than just the Policy piece.  Here is my proposed\n>         session.  Let me know if it rings true:\n>         \n>         \n>         Title: Extracting Shared Libraries from incubator\n>         \n>         Some of the security-sensitive code in OpenStack is coped into\n>         various projects from Oslo-Incubator.  If there is a CVE\n>         identified in one of these pieces, there is no rapid way to\n>         update them short of syncing code to all projects.  This\n>         meeting is to identify the pieces of Oslo-incubator that\n>         should be extracted into stand alone libraries.\n>         \n> \n> \n> I believe the goal of oslo-incubator IS to spin out common code into\n> standalone libraries in the long run, as appropriate.\n\nIndeed.\n\nhttps://wiki.openstack.org/wiki/Oslo\n\n  Mission Statement:\n\n    To produce a set of python libraries containing code shared by \n    OpenStack projects\n\nhttps://wiki.openstack.org/wiki/Oslo#Incubation\n\n  Incubation shouldn\'t be seen as a long term option for any API - it \n  is merely a stepping stone to inclusion into a published Oslo\n  library. \n\n>         Some of the code would be best reviewed by members of other\n>         projects:  Network specific code by Neutron, Policy by\n>         Keystone, and so forth.  As part of the discussion, we will\n>         identify a code review process that gets the right reviewers\n>         for those subprojects.\n> \n> \n> It sounds like the real goal is \"how do we get relevant/interested\n> reviewers in front of oslo reviews without overloading them with\n> noise?\" I\'m sure that\'s a topic that Mark already has an opinion on,\n> so I\'ve opened this thread this to openstack-dev.\n\nTo take the specific example of the policy API, if someone actively\nwanted to help the process of moving it into a standalone library should\nvolunteer to help Flavio out as a maintainer:\n\n  https://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS\n\n  == policy ==\n\n  M: Flavio Percoco <flavio at redhat.com>\n  S: Maintained\n  F: policy.py\n\n\nAnother aspect is how someone would go about helping do reviews on a\nspecific API in oslo-incubator. That\'s a common need - e.g. for\nmaintainers of virt drivers in Nova - and AIUI, these folks just\nsubscribe to all gerrit notifications for the module and then use mail\nfilters to make sure they see changes to the files they\'re interested\nin.\n\nThanks,\nMark.\n\n\n\n\n','<CAC=h7gUSrkrKTjOiVXFq0wHEAi084NMccjfOQZP=ySGrwpaHGA@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1379657530.2374.29.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 16:12:10',36000,'2013-09-20 06:12:10',NULL,'[openstack-dev] Client and Policy','(Resend this as i realize it didn\'t get to the list) \n\n\nI just want to clarify where some of this discussion came from. I\nactually think that oslo does a great job at keeping so many project up\nto date with common code without the restrictions that going to a\nlibrary straight away. The problem is I don\'t think it will work for\ncode that should exist client side.\n\nThe most obvious example we have of this is the currently in oslo\napiclient/exceptions.py. This is a really good set of exceptions however\nif novaclient imports exceptions to\nnovaclient.openstack.common.apiclient.exceptions and keystoneclient does\nit to keystoneclient.openstack.common.apiclient.exceptions then there\nare NOT the same objects. It will be a fairly common situation where\nsomeone is using a number of clients together and so this is a bad\nsituation. So for client side code we may not be able to go through the\nstandard oslo process to achieve a common base library. \n\nThis brought up the issue of auth_token and whether it should eventually\nlive in keystoneclient. The problem with having it live in\nkeystoneclient is that if there is a CVE in auth_token, or for example\nwe wish to push the recent changes to allow CA validation on HTTPS\nconnections in auth_token - the only way to do this is to push the most\ncutting edge version of keystoneclient into the global requirements.txt\nand pushed throughout OpenStack. Now I\'m still confident that this\nwouldn\'t cause any API issues regarding the use of keystoneclient\nhowever the vast majority of keystoneclient does not need to be on this\nschedule and i\'m sure it would be a problem for packagers.\n\nPolicy is not my main focus here - though i agree it should be more\nrelated to keystone, but we should be able to affect these changes in\nOSLO. The thought was if we were to spin auth_token out of\nkeystoneclient into a new package (and i haven\'t really heard a name for\nit i like yet - i\'ll call it python-openstackauth) then this package\nwould make a good resting place for oslo policy. This would also become\na good place for the auth_plugins that are currently in nova and we are\ntrying to push through to other clients.\n\nSo splitting two libraries out of OSLO/keystoneclient, baseclient and\nopenstackauth, openstackauth would depend on baseclient, keystoneclient\nwould depend on baseclient, openstackauth may require a dependency on\nkeystoneclient for populating auth_token fields.\n\n\nJamie \n\n\nOn Thu, 2013-09-19 at 13:30 -0700, Mark McLoughlin wrote:\n> On Thu, 2013-09-19 at 15:22 -0500, Dolph Mathews wrote:\n> > \n> > On Thu, Sep 19, 2013 at 2:59 PM, Adam Young <ayoung at redhat.com> wrote:\n> >         I can submit a summit proposal.  I was thinking of making it\n> >         more general than just the Policy piece.  Here is my proposed\n> >         session.  Let me know if it rings true:\n> >         \n> >         \n> >         Title: Extracting Shared Libraries from incubator\n> >         \n> >         Some of the security-sensitive code in OpenStack is coped into\n> >         various projects from Oslo-Incubator.  If there is a CVE\n> >         identified in one of these pieces, there is no rapid way to\n> >         update them short of syncing code to all projects.  This\n> >         meeting is to identify the pieces of Oslo-incubator that\n> >         should be extracted into stand alone libraries.\n> >         \n> > \n> > \n> > I believe the goal of oslo-incubator IS to spin out common code into\n> > standalone libraries in the long run, as appropriate.\n> \n> Indeed.\n> \n> https://wiki.openstack.org/wiki/Oslo\n> \n>   Mission Statement:\n> \n>     To produce a set of python libraries containing code shared by \n>     OpenStack projects\n> \n> https://wiki.openstack.org/wiki/Oslo#Incubation\n> \n>   Incubation shouldn\'t be seen as a long term option for any API - it \n>   is merely a stepping stone to inclusion into a published Oslo\n>   library. \n> \n> >         Some of the code would be best reviewed by members of other\n> >         projects:  Network specific code by Neutron, Policy by\n> >         Keystone, and so forth.  As part of the discussion, we will\n> >         identify a code review process that gets the right reviewers\n> >         for those subprojects.\n> > \n> > \n> > It sounds like the real goal is \"how do we get relevant/interested\n> > reviewers in front of oslo reviews without overloading them with\n> > noise?\" I\'m sure that\'s a topic that Mark already has an opinion on,\n> > so I\'ve opened this thread this to openstack-dev.\n> \n> To take the specific example of the policy API, if someone actively\n> wanted to help the process of moving it into a standalone library should\n> volunteer to help Flavio out as a maintainer:\n> \n>   https://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS\n> \n>   == policy ==\n> \n>   M: Flavio Percoco <flavio at redhat.com>\n>   S: Maintained\n>   F: policy.py\n> \n> \n> Another aspect is how someone would go about helping do reviews on a\n> specific API in oslo-incubator. That\'s a common need - e.g. for\n> maintainers of virt drivers in Nova - and AIUI, these folks just\n> subscribe to all gerrit notifications for the module and then use mail\n> filters to make sure they see changes to the files they\'re interested\n> in.\n> \n> Thanks,\n> Mark.\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<1379622623.7974.125.camel@sorcha>',NULL),('<1379670852.29116.27.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 11:54:12',7200,'2013-09-20 09:54:12',NULL,'[openstack-dev] [Metrics] Activity_Board now in infra','Hi all,\n\nThe OpenStack Development Dashboard [1] is now in infra [2]. If you want\nto browse details about how to get the data (JSON and SQL), how to clone\n& deploy the dashboard elsewhere, or how to reproduce the data retrieval\nand analysis process, you can refer to the README [3] or the wiki [4].\n\n[1] http://activity.openstack.org/dash/\n[2] http://git.openstack.org/cgit/openstack-infra/activity-board/\n[3]\nhttp://git.openstack.org/cgit/openstack-infra/activity-board/tree/README.md\n[4] https://wiki.openstack.org/wiki/Activity_Board\n\nBug reports and patches are welcome. For reports, please use the\nOpenStack_Community tracker [5] (tag: \"activityboard\"). For patches,\nplease use the usual code review process.\n\n[5] https://launchpad.net/openstack-community\n\nAny feedback is welcome.\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n',NULL,NULL),('<1379698476-sup-4691@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 10:47:10',-25200,'2013-09-20 17:47:10',NULL,'[openstack-dev] Fwd: [Openstack-devel] PGP key signing party\n	during the HK summit','Excerpts from Mike Spreitzer\'s message of 2013-09-20 07:46:47 -0700:\n> What\'s the threat model here?\n> \n\nRight now most verification loops in OpenStack rely on SSL and the PKI\nthat it brings along.\n\nThis is vulnerable to centralized compromise on several levels, and does\nnot help if the server itself is compromised. Rubygems anyone?\n\nHowever, if I have verified the keys that have signed the git tags,\nI can make use of that git repo with confidence. It does not matter if\nall of the OpenStack infra is compromised, they can\'t fake signing stuff\nwith my key unless they have it.\n\nAlso if we are auto-signing anything, the infra team can sign the\nkey for the auto-signer, so we can also secure any mirrored copies of\nautomatically built artifcats against server side tampering.\n\n\n','<OF96BA8F52.4909289F-ON85257BEC.005128AD-85257BEC.0051302D@us.ibm.com>',NULL),('<1379699269-sup-2977@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 10:50:22',-25200,'2013-09-20 17:50:22',NULL,'[openstack-dev] Fwd: [Openstack-devel] PGP key signing party\n	during the HK summit','Excerpts from Thomas Goirand\'s message of 2013-09-19 23:33:47 -0700:\n> \n> Hi,\n> \n> Has anyone thought about having a PGP key signing party during the\n> summit? Guys from the Linux kernel thought it was useless, but after the\n> hack of kernel.org, they started to understand it was useful, and now\n> they do have a \"web of trust\". As a package maintainer, I would very\n> much like to have a signing event during the next HK summit, and collect\n> signatures so that I can check the pgp signed tags, which to my very\n> satisfaction, starts to appear for every package release (not sure if\n> this comes from the fact I\'ve been annoying everyone about it in this\n> list, though that\'s a very good thing).\n\nI have been to two such events and they are extremely beneficial for growing\nthe PGP web of trust.\n\nhttp://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html#overview\n\nGiven the size of the summit, I suggest the hash based method.\n\n\n','<523BEC4B.9030805@debian.org>',NULL),('<1379707694-sup-2646@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 13:12:20',-25200,'2013-09-20 20:12:20',NULL,'[openstack-dev] [Heat] question about stack updates,\n	instance groups and wait conditions','Excerpts from Simon Pasquier\'s message of 2013-09-17 05:57:58 -0700:\n> Hello,\n> \n> I\'m testing stack updates with instance group and wait conditions and \n> I\'d like to get feedback from the Heat community.\n> \n> My template declares an instance group resource with size = N and a wait \n> condition resource with count = N (N being passed as a parameter of the \n> template). Each group\'s instance is calling cfn-signal (with a different \n> id!) at the end of the user data script and my stack creates with no error.\n> \n> Now when I update my stack to run N+X instances, the instance group gets \n> updated with size=N+X but since the wait condition is deleted and \n> recreated, the count value should either be updated to X or my existing \n> instances should re-execute cfn-signal.\n\nThat is a bug, the count should be something that can be updated in-place.\n\nhttps://bugs.launchpad.net/heat/+bug/1228362\n\nOnce that is fixed, there will be an odd interaction between the groups\nthough. Any new instances will add to the count, but removed instances\nwill not decrease it. I\'m not sure how to deal with that particular quirk.\n\nThat said, rolling updates will likely produce some changes to the way\nupdates interact with wait conditions so that we can let instances and/or\nmonitoring systems feed back when an instance is ready. That will also\nhelp deal with the problem you are seeing.\n\nIn the mean time, cfn-hup is exactly what you want, and I see no problem\nwith re-running cfn-signal after an update to signal that the update\nhas applied.\n\n\n','<523851D6.9030906@bull.net>',NULL),('<1379711429-sup-8596@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-20 16:14:52',-25200,'2013-09-20 23:14:52',NULL,'[Openstack] [Heat/havana]: Heat delete occasionally fails','Excerpts from Juha Tynninen\'s message of 2013-09-19 23:29:26 -0700:\n> Hi,\n> \n> In havana deleting the stack occasionally fails to timeout \"Error: Timed\n> out trying to delete user\". If tried again the the delete can be succesfull.\n> \n> 2013-09-20 08:58:56.910 ERROR heat.engine.resource [-] Delete Restarter\n> \"RestartPolicy\"\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource Traceback (most recent\n> call last):\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource   File\n> \"/opt/stack/heat/heat/engine/resource.py\", line 527, in delete\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource     handle_data =\n> self.handle_delete()\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource   File\n> \"/opt/stack/heat/heat/engine/signal_responder.py\", line 61, in handle_delete\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource\n> self.keystone().delete_stack_user(self.resource_id)\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource   File\n> \"/opt/stack/heat/heat/common/heat_keystoneclient.py\", line 269, in\n> delete_stack_user\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource     raise\n> exception.Error(reason)\n> 2013-09-20 08:58:56.910 TRACE heat.engine.resource Error: Timed out trying\n> to delete user\n\nThis is a legitimate time out when trying to delete A user that is\ndefined in your template.\n\nUnfortunately, it is a static timeout, but it is also 10 seconds. That\nis a long time for keystone to take to delete a user!\n\n\n','<CAHYuhGzA3LdNCoWNDmQeTnQ=xFc+kAVdU0swbUwgUQ+AZ8GYdQ@mail.gmail.com>',NULL),('<1379713450.52968734@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 17:44:10',-14400,'2013-09-20 21:44:10',NULL,'[openstack-dev] [Glance][Swift] Glance using swiftclient without\n	multithreading','\nHi all,\n \nIt seems that glance uses swiftclient and misses out a multithreading option.\n[https://github.com/openstack/glance/blob/master/glance/store/swift.py#L574] https://github.com/openstack/glance/blob/master/glance/store/swift.py#L574\n[https://github.com/openstack/glance/blob/master/glance/store/swift.py#L651] https://github.com/openstack/glance/blob/master/glance/store/swift.py#L651\n \nswitclient from command line gives the option of downloading multiple segments using the same.\n[https://github.com/openstack/python-swiftclient/blob/master/bin/swift#L202] https://github.com/openstack/python-swiftclient/blob/master/bin/swift#L202\n \nI was wondering if we should have a bp/bug for this and what all implications do we think it might have on the download/upload process?\n \nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/9d17cfc8/attachment.html>\n\n',NULL,NULL),('<1379741854.94769.YahooMailNeo@web140806.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-20 22:37:34',-25200,'2013-09-21 05:37:34',NULL,'[Openstack] use openstack in Cisco VMDC 3 datacenter',' \nHello\nsorry for my commonplace question,Im new in\nopenstack technology!\nWe have started to build a new\ndatacenter based on cisco vmdc 3.1 technology.\n\nwe want to serv IaaS as a\nservice(public & private cloud).\nBut, Im confused, with cisco 1000 v and\nvmware solution for virtualization, zenoss for monitoring and etc,\nwhat is the role of openstack technology?\nDoes it merge all of these solution\nfrom central point?\nHow can we use openstack solution for implementing a cisco vmdc 3.1?\ncan anybody guide me about its benefits\non this field?\nBest Regards\nHabibi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130920/9f31c3a0/attachment.html>\n\n',NULL,NULL),('<1379918242.7974.127.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 07:37:22',3600,'2013-09-23 06:37:22',NULL,'[openstack-dev] Oslo PTL election','Hey\n\nI meant to send this as soon as nominations opened - I figure that\nincumbent PTLs should make it clear if they don\'t intend to nominate\nthemselves for re-election.\n\nTo that end - I\'m not going to put myself forward for election as Oslo\nPTL this time around. This is purely based on a gut instinct that doing\nso will actually be better for Oslo. I still care a great deal about\nOslo\'s mission and will continue to work on Oslo in Icehouse, e.g. doing\nreviews and getting the oslo.messaging work over the line.\n\nI think the legacy of cut-and-paste code across OpenStack is a serious\nthreat to OpenStack\'s future progress and tackling it effectively is\ngoing to require the help of many more of the core developers from other\nprojects. I\'m hoping that by not being PTL, there\'ll be more space for\nothers to jump in and help drive Oslo\'s direction with new ideas and new\napproaches.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1379918572.7974.130.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 07:42:52',3600,'2013-09-23 06:42:52',NULL,'[openstack-dev] [Oslo] PTL Candidacy','On Sat, 2013-09-21 at 09:16 -0400, Doug Hellmann wrote:\n> I am running for PTL for the OpenStack Common Libraries (Oslo) project.\n\nExcellent!\n\nDoug has been a superb contributor to Oslo and I\'ve particularly\nappreciated his keen eye for Python API design. I\'ve no doubt that Doug\nwould make a wonderful PTL for Oslo.\n\nThanks,\nMark.\n\n\n\n','<CADb+p3SHQeOOCgYyttc2YsU3JLBjadOoJVdtSPhNMhXMCY_pvQ@mail.gmail.com>',NULL),('<1379965505.923418017@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-09-23 14:45:05',-18000,'2013-09-23 19:45:05',NULL,'[openstack-community] FOSE 2014 Gov\'t Conference Call for Papers\n	Open Through October 25','\nFOSE 2014 will be held May 13-15, 2014 in Washington DC.  This is primarily a US Federal Government IT event, with 3-4% of it\'s 8,000+ attendees from international governments.\n \nSeveral US government agencies use OpenStack including NSA, NASA, NRO, Argonne National Lab (Dept. of Energy) and more.  OpenStack members sponsored the 2013 event including NetApp, Dell, VMware and Microsoft.\n \nThe Call for Papers is open through October 25 at [http://fose.com/events/2013-conference/information/attendee/call-for-presentations.aspx] http://fose.com/events/2013-conference/information/attendee/call-for-presentations.aspx.  The conference theme is Technology Solutions Found Here; there is a Cloud & Virtualization track; and sample topics are listed. \n \nWe encourage OpenStack government users and government-skilled companies to participate in this conference with speaking sessions.  We are considering a BoF as well.  Thank you for submitting your session proposals by the October 25 (5pm ET) deadline.\n \nAbout FOSE:\nFOSE is the nation?s premier event for government technology professionals who need tools, resources, and best practices to transition to the cloud, mitigate cybersecurity threats, and achieve the goals of the DGS while managing uncertainty and the critical need to make it all happen on-time and on-budget.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130923/cad42358/attachment.html>\n\n',NULL,NULL),('<1379976679-sup-2849@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 15:53:15',-25200,'2013-09-23 22:53:15',NULL,'[openstack-dev] [heat] [scheduler] Bringing things together for\n	Icehouse','Excerpts from Keith Bray\'s message of 2013-09-23 12:22:16 -0700:\n> \n> I think this picture is relevant to Heat context:\n> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o\n> 0R9U/edit\n> \n> \n> As more and more types of compute (containers, VMs, bare metal) and other\n> resources (geographically dispersed) become available from the cloud with\n> boarder capabilities (e.g. regionally dispersed backups,\n> failover/recovery, etc.), the concept of scheduling and optimizing\n> resource placement becomes more important, particularly when a customer\n> wants to deploy an application that has multiple underlying resource needs\n> but doesn\'t want to know (or care) about specifying the details of those\n> resources and their placement.\n> \n> I\'m not advocating that this does or does not belongs in Heat (in general\n> I think Stack resource placement, region, etc., belongs with the template\n> author or authoring system, and I think physical resource placement\n> belongs with the underlying service, Nova, Trove, etc.), but I appreciate\n> Mike including Heat on this. I for one would vote that we consider this\n> \"in-context\" for discussion purposes, regardless of action.  Placement\n> coordination across disparate resource services is likely to become a more\n> prominent problem, and given Heat has the most holistic view of the\n> application topology stack within the cloud, Heat may have something to\n> offer in being a piece of the solution.\n\nJust to restate what you and Zane have just said succintly: There is\ndefinitely a need for Heat to be able to communicate to the API\'s any\nplacement details that can be communicated. However, Heat should not\nactually be \"scheduling\" anything.\n\n\n','<CE65EA56.7EDA7%keith.bray@rackspace.com>',NULL),('<1379987064.6107587.1390869755119.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 19:42:35',-18000,'2014-01-28 00:42:35',NULL,'[openstack-dev] [keystone][heat] Migration to keystone v3\n	API	questions','\n\n----- Original Message -----\n> From: \"Steven Hardy\" <shardy at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Thursday, 23 January, 2014 9:21:47 PM\n> Subject: [openstack-dev] [keystone][heat] Migration to keystone v3 API	questions\n> \n> Hi all,\n> \n> I\'ve recently been working on migrating the heat internal interfaces to use\n> the keystone v3 API exclusively[1].\n> \n> This work has mostly been going well, but I\'ve hit a couple of issues which\n> I wanted to discuss, so we agree the most appropriate workarounds:\n> \n> 1. keystoneclient v3 functionality not accessible when catalog contains a\n> v2 endppoint:\n> \n> In my test environment my keystone endpoint looks like:\n> \n> http://127.0.0.1:5000/v2.0\n> \n> And I\'d guess this is similar to the majority of real deployments atm?\n> \n> So when creating a keystoneclient object I\'ve been doing:\n> \n> from keystoneclient.v3 import client as kc_v3\n> v3_endpoint = self.context.auth_url.replace(\'v2.0\', \'v3\')\n> client = kc_v3.Client(auth_url=v3_endpoint, ...\n> \n> Which, assuming the keystone service has both v2 and v3 API\'s enabled\n> works, but any attempt to use v3 functionality fails with 404 because\n> keystoneclient falls back to using the v2.0 endpoint from the catalog.\n> \n> So to work around this I do this:\n> \n> client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...\n> client.authenticate()\n> \n> Which results in the v3 features working OK.\n> \n> So my questions are:\n> - Is this a reasonable workaround for production environments?\n> - What is the roadmap for moving keystone endpoints to be version agnostic?\n> - Is there work ongoing to make the client smarter in terms of figuring out\n>   what URL to use (version negotiation or substituting the appropriate path\n>   when we are in an environment with a legacy v2.0 endpoint..)\n\nThis is a known issue and something that has come up for discussion many times and \nwe don\'t have a great solution for it. This problem won\'t be unique to keystone it\nis a side effect of having versioned endpoints in the service catalog. \n\nWe are slowly attempting to transition the entire service catalog over to \nunversioned endpoints. There is a lot of problems though regarding this and \nmaintaining comptability with existing clients and installations. There are some\nhacks we are discussing that will hopefully allow us to transition keystone and \nthe other clients over - this is but one advantage of getting a more common client\ngoing. \n\nTo more directly answer the question, there is slow work ongoing in this area but\nfor the time being the best advice i have is to set \nclient.management_url = v3_endpoint and it will override the service \ncatalog for the lifetime of the client (endpoint= should work but your above example \nwill involve to authentication requests). \n\nIf you have any ideas on how to handle this transition and provide backwards compat\nI\'d love to hear them. \n\n> 2. Client (CLI) support for v3 API\n> \n> What is the status re porting keystoneclient to provide access to the v3\n> functionality on the CLI?\n> \n> In particular, Heat is moving towards using domains to encapsulate the\n> in-instance users it creates[2], so administrators will require some way to\n> manage users in a non-default domain, e.g to get visibility of what Heat is\n> doing in that domain and debug in the event of any issues.\n> \n> If anyone can provide any BP links or insight that would be much\n> appreciated!\n\nThere is general consensus here that we will not be providing CLI access to\nthe V3 API via the keystoneclient package. This responsibility has been \ndumped on^H^H^H taken over by the common openstack client. I am not aware of \nwhen OSC will be considered production ready. \n\n\nSorry i couldn\'t bring more positive news,\n\nJamie\n\n> Thanks,\n> \n> Steve\n> \n> [1] https://blueprints.launchpad.net/heat/+spec/keystone-v3-only\n> [2] https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140123112146.GB15264@t430slt.redhat.com>',NULL),('<1379994350-sup-1671@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 20:57:41',-25200,'2013-09-24 03:57:41',NULL,'[openstack-dev] [heat] [scheduler] Bringing things together for\n	Icehouse','Excerpts from Mike Spreitzer\'s message of 2013-09-23 20:31:32 -0700:\n> I was not trying to raise issues of geographic dispersion and other higher \n> level structures, I think the issues I am trying to raise are relevant \n> even without them.  This is not to deny the importance, or relevance, of \n> higher levels of structure.  But I would like to first respond to the \n> discussion that I think is relevant even without them.\n> \n> I think it is valuable for OpenStack to have a place for holistic \n> infrastructure scheduling.  I am not the only one to argue for this, but I \n> will give some use cases.  Consider Hadoop, which stresses the path \n> between Compute and Block Storage.  In the usual way of deploying and \n> configuring Hadoop, you want each data node to be using directly attached \n> storage.  You could address this by scheduling one of those two services \n> first, and then the second with constraints from the first --- but the \n> decisions made by the first could paint the second into a corner.  It is \n> better to be able to schedule both jointly.  Also consider another \n> approach to Hadoop, in which the block storage is provided by a bank of \n> storage appliances that is equidistant (in networking terms) from all the \n> Compute.  In this case the Storage and Compute scheduling decisions have \n> no strong interaction --- but the Compute scheduling can interact with the \n> network (you do not want to place Compute in a way that overloads part of \n> the network).\n> \n> Once a holistic infrastructure scheduler has made its decisions, there is \n> then a need for infrastructure orchestration.  The infrastructure \n> orchestration function is logically downstream from holistic scheduling. I \n> do not favor creating a new and alternate way of doing infrastructure \n> orchestration in this position.  Rather I think it makes sense to use \n> essentially today\'s heat engine.\n> \n\nOk, now I think I understand you.\n\nWhat you\'re talking about, in many ways, is very similar to what the\nautoscale-interested folk have been proposing. Something that sits\noutside of Heat and makes use of other information (alarms/policy/etc)\nto tweak a Heat stack.\n\nOnly this service would make use of information before a stack was\neven created.\n\nI like it, and I do think that it should be \"part of heat\" because it will\nbe making use of Heat\'s templating to make those decisions. However,\nI also think it should be a separate repository/project within the\n\"OpenStack Orchestration\" program, to keep it honest with regard to\ninterfaces. Heat\'s infrastructure-focused service is already big enough,\nwe don\'t need to grow it even more with only slightly-related code.\n\nAlso I imagine there are many ways to skin this cat, and thus we may see\nalternative holistic schedulers for specific applications (Savannah may\nuse a hadoop specific approach, as you suggested). There is also the\npossibility of chaining schedulers.\n\nThe Tuskar project also comes to mind, as the deployment of baremetal with\na mind toward network topology and physical placement (racks/rooms/etc)\nfor the explicit purpose of deploying OpenStack is itself a form of\nholistic scheduling.\n\n> Today Heat is the only thing that takes a holistic view of \n> patterns/topologies/templates, and there are various pressures to expand \n> the mission of Heat.  A marquee expansion is to take on software \n> orchestration.  I think holistic infrastructure scheduling should be \n> downstream from the preparatory stage of software orchestration (the other \n> stage of software orchestration is the run-time action in and supporting \n> the resources themselves).  There are other pressures to expand the \n> mission of Heat too.  This leads to conflicting usages for the word \n> \"heat\": it can mean the infrastructure orchestration function that is the \n> main job of today\'s heat engine, or it can mean the full expanded mission \n> (whatever you think that should be).  I have been mainly using \"heat\" in \n> that latter sense, but I do not really want to argue over naming of bits \n> and assemblies of functionality.  Call them whatever you want.  I am more \n> interested in getting a useful arrangement of functionality.  I have \n> updated my picture at \n> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U \n> --- do you agree that the arrangement of functionality makes sense?\n\nI do now. I stand by the original position that Heat, as it exists today,\nwould simply pass along infrastructure scheduling decisions made by a\nholistic scheduler. However I think it would be unwise to try and develop\nthese things apart from one another as it may encourage fracturing the\ntemplate language. So I would propose that if there is a more general\npurpose attempt at holistic scheduling via Heat templates that it be\ndone as a separate service/repository within the Heat program.\n\n\n','<OF2570BC5D.9BBF4A70-ON85257BF0.00109212-85257BF0.00135DF7@us.ibm.com>',NULL),('<1380024474.73553.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-24 20:07:54',28800,'2013-09-24 12:07:54',NULL,'[Openstack] problem in understanding interaction between swift\n	proxy and other servers through swift source code','Hello,\n\nI am studying swift source code.\n\nMy problem is:\n1) What are the roles of class AccountController defined in swift / proxy / controllers / account.py and class AccountController defined in swift / account / server.py\n2) How these two classes differ from each other and?\n3) How these two class interact with each other i.e.?\nAccording to my understanding, when a user make a request, __call__() function defined in Application class in swift / proxy /server.py is executed, which ,in turn, calls handle_request() function which sends the control to the swift / proxy / controllers?\n\nNow, I can\'t understand through which function call will the control go to account server\n\nPlease help me in this regard\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130924/c5bcc137/attachment.html>\n\n',NULL,NULL),('<1380040300-sup-8392@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-09-24 09:42:19',-25200,'2013-09-24 16:42:19',NULL,'[OpenStack-Infra] Suggestion for helping gate users deal with\n	crisis...','Hello infra rockstars. First and foremost, thank you for keeping the\nwell oiled machinery of the OpenStack infrastructure running. It is a\nmarvel of modern engineering, and I am not just saying that because I\nam prone to hyperbole.\n\nLast night while the gate was exploding a few of us noticed, and\nweren\'t really sure what to do. ttx was whitelisted in the statusbot,\nbut untrained in how to handle it. I dug through jenkins configs and\nlogs but I am completely ignorant of zuul and thus would have done\nmore damage than not had I been able to coax anything out of the system\n(luckily I am also completely unprivileged.. good job :).\n\nI\'d like to suggest that infra develop a play book for dealing\nwith crisis. This is not just for those of you with the power to fix\nthings. This is a public document that helps people understand what to do,\nwho to wait for, who to contact, and how to do so, when things are broken.\n\nStatusbot works well as an \"Office Barbrady\" style \"nothing to see here,\nmove along\", but it is not so useful in helping to get the ball rolling\non a solution after hours in the US. Had there been a play book with\nroles listed, the statusbot would have been made use of. As in:\n\n\"In the event of any failure, the statusbot should be updated by someone\nwho is whitelisted in this file [link to the file] in git.\" Those\nindividuals can send a message in this format, in #openstack-infra to\nupdate the status:\n\n   #status Pypi mirror problems causing gate failures. Please stand-by...\n\nThis should be in a wiki page or published document somewhere that is\nlinked \"basically everywhere\". This allows those who see a failure as\na crisis to click through, and find a warm fuzzy of options to take. It\nalso helps take the burden off the infra team for educating everyone on\nhow to deal with crisis. It is especially helpful in scaling the team\nout, as new members can learn how the team operates in general via the\nplay book rather than having to wait for a crisis to happen.\n\nAnyway, just a suggestion. As I don\'t know the plays, I cannot write\nthis page, but I would have been able to share the link with the few\nothers who were affected by the outage last night, and that might have\nreduced their stress level a bit.\n\n\n',NULL,NULL),('<1380047131.67181.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-24 19:25:31',3600,'2013-09-24 18:25:31',NULL,'[Openstack] OpenStack Grizzly Quantum Networking','hi Clint,\n\ntry these commands:\n\n\nquantum router-interface-delete demo-router fadfa51f-c588-4f1b-8084-4305a8e00486\nquantum router-gateway-clear demo-router\nquantum router-delete demo-router\n\nRe, Darragh.\n\n\n>________________________________\n> From: Clint Dilks <clintd at waikato.ac.nz>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 24 September 2013, 2:54\n>Subject: Re: [Openstack] OpenStack Grizzly Quantum Networking\n> \n>\n>\n>Hi,\n>\n>As a follow up to this I was trying to delete all configured networks and start again, but I seem to be stuck in a loop where I can\'t delete a router because it has active ports, and yet I can\'t delete active ports because they belong to a router.\n>\n>[root at blitzen nova]# quantum router-list\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>| id?????????????????????????????????? | name??????? | external_gateway_info????????????????????????????????? |\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>| e6493ab3-a6b6-476e-a7d6-f1f199810efd | demo-router | {\"network_id\": \"f045b171-7456-4006-9732-420bf5b70017\"} |\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>[root at blitzen nova]# quantum port-list -c id -c fixed_ips -c device_owner\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>| id?????????????????????????????????? | fixed_ips???????????????????????????????????????????????????????????????????????????? | device_owner???????????? |\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>| 0d08328c-e51f-4995-8dc8-b0eb4fae87d7 | {\"subnet_id\": \"fadfa51f-c588-4f1b-8084-4305a8e00486\", \"ip_address\": \"10.5.5.1\"}?????? | network:router_interface |\n>| eaad9cce-e9a6-44db-970b-2785403739c1 | {\"subnet_id\": \"a91622d4-f874-48e1-9791-d6acdeff4d2d\", \"ip_address\": \"130.217.79.200\"} | network:router_gateway?? |\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>[root at blitzen nova]# quantum router-delete e6493ab3-a6b6-476e-a7d6-f1f199810efd\n>Router e6493ab3-a6b6-476e-a7d6-f1f199810efd still has active ports\n>[root at blitzen nova]# quantum port-delete 0d08328c-e51f-4995-8dc8-b0eb4fae87d7\n>Port 0d08328c-e51f-4995-8dc8-b0eb4fae87d7 has owner network:router_interface and therefore cannot be deleted directly via the port API.\n>\n>So how would I go about deleting these networks?\n>\n>\n>\n>\n>\n>\n>\n>\n>\n>On Tue, Sep 24, 2013 at 11:00 AM, Clint Dilks <clintd at waikato.ac.nz> wrote:\n>\n>Hi\n>>\n>>I am currently trying to get Grizzly up and running on CentOS 6.4.\n>>I have followed http://docs.openstack.org/grizzly/basic-install/yum/content/ as closely as I can and from both a dashboard and OpenStack command line viewpoint all OpenStack services are up and running and it appears that VM\'s can be lauched and stopped without any obvious errors being recorded? but I can\'t interact with them using things like ping or ssh.\n>>\n>>\n>>Below is information I think may be useful to fix the issue.? Thanks for any insight you care to share.\n>>\n>>\n>>Currently I have a single machine running all services\n>>\n>>Management Network 10.10.11.2/24 em2\n>>Bridge linked to em1? 130.217.79.2/24\n>>\n>>\n>>We want people to be able to create VM\'s that they can access via 130.217.79.0/24 addresses.\n>>\n>>\n>>So as an initial test I follow the example listed in the guide above and created a demo-net\'\n>>http://docs.openstack.org/grizzly/basic-install/yum/content/basic-install_network.html\n>>\n>>Key details below\n>>\n>>TENANT_NAME=\"demo\"\nTENANT_NETWORK_NAME=\"demo-net\"\nTENANT_SUBNET_NAME=\"${TENANT_NETWORK_NAME}-subnet\"\nTENANT_ROUTER_NAME=\"demo-router\"\nFIXED_RANGE=\"10.5.5.0/24\"\nNETWORK_GATEWAY=\"10.5.5.1\"Then I ran\n>>\n>>quantum net-create public --router:external=True\n>>\n>>quantum subnet-create --ip_version 4 --gateway 130.217.79.1 public 130.217.79.0/24 \\\n>>--allocation-pool start=130.217.79.200,end=130.217.79.250 --disable-dhcp --name public-subnet\n>>\n>>quantum router-gateway-set demo-router publicUsing this config instances will launch and if I assign a machine to the public network, the network topology appears to be what we want.? But in the guides section about lauching your first vm? ( http://docs.openstack.org/grizzly/basic-install/yum/content/basic-install_operate.html )? it states that ip netns should show two pieces of information qrouter and qdhcp.? I am only seeing qrouter.\n>>\n>>\n>>Should what I have set up work ?? Or have I missed something fundamental ?\n>>\n>>\n>>As it was the default quantum should be configured to use gre + tunnels,? I am using? 2.6.32-358.118.1.openstack.el6.x86_64 to add the functionality that is missing from the default CentOS kernel.\n>>\n>>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini contains the following, would it be simpler to get what we need using a VLAN configuration ?\n>>\n>>[DATABASE]\n>>sql_connection = mysql://quantum:openstack-csl at 10.10.11.2/quantum\n>>reconnect_interval = 2\n>>\n>>[OVS]\n>>tenant_network_type = gre\n>>enable_tunneling = True\n>>tunnel_id_ranges = 1:1000\n>>local_ip = 10.10.11.2\n>>\n>>[AGENT]\n>>polling_interval = 2\n>>\n>>[SECURITYGROUP]\n>>firewall_driver = quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n>>\n>>\n>>\n>>\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ???: openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n\n\n','<CACdTQcVCb2KVPBjV8TTNc2pEXER6hm6ZTrjRyVHwbQ=sb-a7Jw@mail.gmail.com>',NULL),('<1380047143-sup-2909@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-09-24 11:34:49',-25200,'2013-09-24 18:34:49',NULL,'[OpenStack-Infra] Suggestion for helping gate users deal with\n	crisis...','Excerpts from jeblair\'s message of 2013-09-24 10:15:10 -0700:\n> Clint Byrum <clint at fewbar.com> writes:\n> > I\'d like to suggest that infra develop a play book for dealing\n> > with crisis. This is not just for those of you with the power to fix\n> > things. This is a public document that helps people understand what to do,\n> > who to wait for, who to contact, and how to do so, when things are broken.\n> >\n> > Statusbot works well as an \"Office Barbrady\" style \"nothing to see here,\n> > move along\", but it is not so useful in helping to get the ball rolling\n> > on a solution after hours in the US. Had there been a play book with\n> > roles listed, the statusbot would have been made use of. As in:\n> >\n> > \"In the event of any failure, the statusbot should be updated by someone\n> > who is whitelisted in this file [link to the file] in git.\" Those\n> > individuals can send a message in this format, in #openstack-infra to\n> > update the status:\n> >\n> >    #status Pypi mirror problems causing gate failures. Please stand-by...\n> >\n> > This should be in a wiki page or published document somewhere that is\n> > linked \"basically everywhere\". This allows those who see a failure as\n> > a crisis to click through, and find a warm fuzzy of options to take. It\n> > also helps take the burden off the infra team for educating everyone on\n> > how to deal with crisis. It is especially helpful in scaling the team\n> > out, as new members can learn how the team operates in general via the\n> > play book rather than having to wait for a crisis to happen.\n> >\n> > Anyway, just a suggestion. As I don\'t know the plays, I cannot write\n> > this page, but I would have been able to share the link with the few\n> > others who were affected by the outage last night, and that might have\n> > reduced their stress level a bit.\n> \n> Now you know where that documentation would live if it existed.  We try\n> to document everything about the system on ci.openstack.org.  If you are\n> at all curious about the project infrastructure, I highly recommend it.\n> \n> Our goal is not to be project gatekeepers.  We have robots for that.\n> Our goal is to facilitate everyone\'s participation in the project\n> infrastructure.  In most cases, privileged access is not required to\n> triage or solve problems.  I believe some was used in this case (to\n> manually add a package to the pypi mirror in order to speed up the\n> solution), but generally when something breaks, anyone in the project\n> has the power to fix it.  The best way to get the ball rolling on a\n> solution is for someone to start working on it.  And yes, then someone\n> should post a status update so people know it\'s being worked on.\n> \n> I\'m wary of writing a playbook that says \"if something breaks, contact\n> so-and-so to fix it\".  That\'s not how this thing works.  It\'s more like\n> \"if something breaks, start trying to fix it\".  And while I understand\n> that not everyone is capable of diagnosing and fixing every problem,\n> quite a number of people have managed to track down, diagnose, and fix\n> problems in this system without being infra rockstars.\n> \n\nIndeed, the playbook I have in mind is not \"this is how things are,\nand these are the people who do the things\". Ideally each playbook entry\nis tied to a bug that has long term ordering problems or just a ton of\nwork pending.\n\n> Keep in mind, this failure, and indeed, most failures are not\n> infrastructure failures.  They are actually the gate working as\n> designed.  It is _supposed_ to \'break\' when it is not possible to test\n> changes under the constraints we have set.  So a more traditional\n> \"enterprise service\" playbook doesn\'t help -- there are no simple levers\n> to pull, every such problem is different and requires a unique solution,\n> and everyone is empowered to create that solution.\n> \n\nIndeed, I have noticed that there are rarely easy answers, as all of\nthe easy answers are automated properly. :)\n\nI think what I\'m looking for is something along the lines of \"this\nis what is supposed to be happening right now\", for those who are not\ninvolved day to day in that decision stream.\n\n\n','<87r4cew38h.fsf@meyer.lemoncheese.net>',NULL),('<1380051905.11356.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-24 20:45:05',3600,'2013-09-24 19:45:05',NULL,'[Openstack] OpenStack Grizzly Quantum Networking','Clint,\n\nyou need to boot your VMs attached to the private network and not the public network. Then you must allocate and associate floating ips. Also remember to open ports in the security groups.\n\nRe, Darragh.\n\n\n>________________________________\n> From: Clint Dilks <clintd at waikato.ac.nz>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Tuesday, 24 September 2013, 2:54\n>Subject: Re: [Openstack] OpenStack Grizzly Quantum Networking\n> \n>\n>\n>Hi,\n>\n>As a follow up to this I was trying to delete all configured networks and start again, but I seem to be stuck in a loop where I can\'t delete a router because it has active ports, and yet I can\'t delete active ports because they belong to a router.\n>\n>[root at blitzen nova]# quantum router-list\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>| id?????????????????????????????????? | name??????? | external_gateway_info????????????????????????????????? |\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>| e6493ab3-a6b6-476e-a7d6-f1f199810efd | demo-router | {\"network_id\": \"f045b171-7456-4006-9732-420bf5b70017\"} |\n>+--------------------------------------+-------------+--------------------------------------------------------+\n>[root at blitzen nova]# quantum port-list -c id -c fixed_ips -c device_owner\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>| id?????????????????????????????????? | fixed_ips???????????????????????????????????????????????????????????????????????????? | device_owner???????????? |\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>| 0d08328c-e51f-4995-8dc8-b0eb4fae87d7 | {\"subnet_id\": \"fadfa51f-c588-4f1b-8084-4305a8e00486\", \"ip_address\": \"10.5.5.1\"}?????? | network:router_interface |\n>| eaad9cce-e9a6-44db-970b-2785403739c1 | {\"subnet_id\": \"a91622d4-f874-48e1-9791-d6acdeff4d2d\", \"ip_address\": \"130.217.79.200\"} | network:router_gateway?? |\n>+--------------------------------------+---------------------------------------------------------------------------------------+--------------------------+\n>[root at blitzen nova]# quantum router-delete e6493ab3-a6b6-476e-a7d6-f1f199810efd\n>Router e6493ab3-a6b6-476e-a7d6-f1f199810efd still has active ports\n>[root at blitzen nova]# quantum port-delete 0d08328c-e51f-4995-8dc8-b0eb4fae87d7\n>Port 0d08328c-e51f-4995-8dc8-b0eb4fae87d7 has owner network:router_interface and therefore cannot be deleted directly via the port API.\n>\n>So how would I go about deleting these networks?\n>\n>\n>\n>\n>\n>\n>\n>\n>\n>On Tue, Sep 24, 2013 at 11:00 AM, Clint Dilks <clintd at waikato.ac.nz> wrote:\n>\n>Hi\n>>\n>>I am currently trying to get Grizzly up and running on CentOS 6.4.\n>>I have followed http://docs.openstack.org/grizzly/basic-install/yum/content/ as closely as I can and from both a dashboard and OpenStack command line viewpoint all OpenStack services are up and running and it appears that VM\'s can be lauched and stopped without any obvious errors being recorded? but I can\'t interact with them using things like ping or ssh.\n>>\n>>\n>>Below is information I think may be useful to fix the issue.? Thanks for any insight you care to share.\n>>\n>>\n>>Currently I have a single machine running all services\n>>\n>>Management Network 10.10.11.2/24 em2\n>>Bridge linked to em1? 130.217.79.2/24\n>>\n>>\n>>We want people to be able to create VM\'s that they can access via 130.217.79.0/24 addresses.\n>>\n>>\n>>So as an initial test I follow the example listed in the guide above and created a demo-net\'\n>>http://docs.openstack.org/grizzly/basic-install/yum/content/basic-install_network.html\n>>\n>>Key details below\n>>\n>>TENANT_NAME=\"demo\"\nTENANT_NETWORK_NAME=\"demo-net\"\nTENANT_SUBNET_NAME=\"${TENANT_NETWORK_NAME}-subnet\"\nTENANT_ROUTER_NAME=\"demo-router\"\nFIXED_RANGE=\"10.5.5.0/24\"\nNETWORK_GATEWAY=\"10.5.5.1\"Then I ran\n>>\n>>quantum net-create public --router:external=True\n>>\n>>quantum subnet-create --ip_version 4 --gateway 130.217.79.1 public 130.217.79.0/24 \\\n>>--allocation-pool start=130.217.79.200,end=130.217.79.250 --disable-dhcp --name public-subnet\n>>\n>>quantum router-gateway-set demo-router publicUsing this config instances will launch and if I assign a machine to the public network, the network topology appears to be what we want.? But in the guides section about lauching your first vm? ( http://docs.openstack.org/grizzly/basic-install/yum/content/basic-install_operate.html )? it states that ip netns should show two pieces of information qrouter and qdhcp.? I am only seeing qrouter.\n>>\n>>\n>>Should what I have set up work ?? Or have I missed something fundamental ?\n>>\n>>\n>>As it was the default quantum should be configured to use gre + tunnels,? I am using? 2.6.32-358.118.1.openstack.el6.x86_64 to add the functionality that is missing from the default CentOS kernel.\n>>\n>>/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini contains the following, would it be simpler to get what we need using a VLAN configuration ?\n>>\n>>[DATABASE]\n>>sql_connection = mysql://quantum:openstack-csl at 10.10.11.2/quantum\n>>reconnect_interval = 2\n>>\n>>[OVS]\n>>tenant_network_type = gre\n>>enable_tunneling = True\n>>tunnel_id_ranges = 1:1000\n>>local_ip = 10.10.11.2\n>>\n>>[AGENT]\n>>polling_interval = 2\n>>\n>>[SECURITYGROUP]\n>>firewall_driver = quantum.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n>>\n>>\n>>\n>>\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ???: openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n\n\n','<CACdTQcVCb2KVPBjV8TTNc2pEXER6hm6ZTrjRyVHwbQ=sb-a7Jw@mail.gmail.com>',NULL),('<1380091106-sup-4264@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-24 23:46:57',-25200,'2013-09-25 06:46:57',NULL,'[openstack-dev] [heat] [scheduler] Bringing things together for\n	Icehouse (now featuring software orchestration)','Excerpts from Mike Spreitzer\'s message of 2013-09-24 22:03:21 -0700:\n> Let me elaborate a little on my thoughts about software orchestration, and \n> respond to the recent mails from Zane and Debo.  I have expanded my \n> picture at \n> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U \n> and added a companion picture at \n> https://docs.google.com/drawings/d/1TCfNwzH_NBnx3bNz-GQQ1bRVgBpJdstpu0lH_TONw6g \n> that shows an alternative.\n> \n> One of the things I see going on is discussion about better techniques for \n> software orchestration than are supported in plain CFN.  Plain CFN allows \n> any script you want in userdata, and prescription of certain additional \n> setup elsewhere in cfn metadata.  But it is all mixed together and very \n> concrete.  I think many contributors would like to see something with more \n> abstraction boundaries, not only within one template but also the ability \n> to have modular sources.\n> \n\nYes please. Orchestrate things, don\'t configure them. That is what\nconfiguration tools are for.\n\nThere is a third stealth-objective that CFN has caused to linger in\nHeat. That is \"packaging cloud applications\". By allowing the 100%\nconcrete CFN template to stand alone, users can \"ship\" the template.\n\nIMO this marrying of software assembly, config, and orchestration is a\nconcern unto itself, and best left outside of the core infrastructure\norchestration system.\n\n> I work closely with some colleagues who have a particular software \n> orchestration technology they call Weaver.  It takes as input for one \n> deployment not a single monolithic template but rather a collection of \n> modules.  Like higher level constructs in programming languages, these \n> have some independence and can be re-used in various combinations and \n> ways.  Weaver has a compiler that weaves together the given modules to \n> form a monolithic model.  In fact, the input is a modular Ruby program, \n> and the Weaver compiler is essentially running that Ruby program; this \n> program produces the monolithic model as a side effect.  Ruby is a pretty \n> good language in which to embed a domain-specific language, and my \n> colleagues have done this.  The modular Weaver input mostly looks \n> declarative, but you can use Ruby to reduce the verboseness of, e.g., \n> repetitive stuff --- as well as plain old modularity with abstraction.  We \n> think the modular Weaver input is much more compact and better for human \n> reading and writing than plain old CFN.  This might not be obvious when \n> you are doing the \"hello world\" example, but when you get to realistic \n> examples it becomes clear.\n> \n> The Weaver input discusses infrastructure issues, in the rich way Debo and \n> I have been advocating, as well as software.  For this reason I describe \n> it as an integrated model (integrating software and infrastructure \n> issues).  I hope for HOT to evolve to be similarly expressive to the \n> monolithic integrated model produced by the Weaver compiler.\n> \n\nIndeed, we\'re dealing with this very problem in TripleO right now. We need\nto be able to compose templates that vary slightly for various reasons.\n\nA ruby DSL is not something I think is ever going to happen in\nOpenStack. But python has its advantages for DSL as well. I have been\ntrying to use clever tricks in yaml for a while, but perhaps we should\njust move to a client-side python DSL that pushes the compiled yaml/json\ntemplates into the engine.\n\n\n','<OFF7F06DD7.E08DFF47-ON85257BF1.0014E15B-85257BF1.001BC674@us.ibm.com>',NULL),('<1380097750.61062.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-25 09:29:10',3600,'2013-09-25 08:29:10',NULL,'[Openstack] OpenStack Grizzly Quantum Networking','Clint,\n\nyeah sorry, I meant boot to the network named \"demo-net\". I think you may have the credentials of the admin user in your environment, but demo-net belongs to user \"demo\". I think you need to open a new console and load the credentials of the demo user into its environment, then try the boot command again.\n\n\nkeystone tenant-list\n\nquantum net-list -c id -c name -c tenant_id\n\n\nTo see which credentials you have in you environment do:\n\nset | grep ^OS\n\nRe, Darragh.\n\n\n>________________________________\n> From: Clint Dilks <clintd at waikato.ac.nz>\n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Wednesday, 25 September 2013, 0:06\n>Subject: Re: [Openstack] OpenStack Grizzly Quantum Networking\n> \n>\n>\n>Ok\n>\n>So looking at this further I believe I am doing something wrong with the virtual networking rather than the physical side of things.\n>I now believe that what Darragh means is that my instances should boot on the internal virtual network rather than the public, which makes sense but there is a issue that I don\'t understand.? \n>\n>\n>net-list shows two networks at I would expect, so I believe that I should be able to tell a vm to boot using demo-net but the tools only allow me to boot if I specify the network as public.? What could be wrong here ?\n>\n>\n>\n>\n>[root at blitzen ~]# quantum net-list\n>+--------------------------------------+----------+------------------------------------------------------+\n>| id?????????????????????????????????? | name???? | subnets????????????????????????????????????????????? |\n>+--------------------------------------+----------+------------------------------------------------------+\n>| b04a786f-d251-4796-bfcf-6486bec467db | demo-net | 06075526-7210-461b-94f1-87c25ad231ab 10.10.11.0/24?? |\n>| f2c7206c-a860-4206-ab5b-34bd9b7d2553 | public?? | f326c5d0-f127-4da5-9065-c3211c9a81b8 130.217.79.0/24 |\n>+--------------------------------------+----------+------------------------------------------------------+\n>\n>nova boot --flavor 1 --image f5058a7e-b0dc-4be2-983e-822f7e586090 --key-name default_key? --nic net-id=b04a786f-d251-4796-bfcf-6486bec467db clintd\n>ERROR: The resource could not be found. (HTTP 404) (Request-ID: req-0d538673-43ff-4a11-9aba-3b907c129e5c)\n>\n>nova boot --flavor 1 --image f5058a7e-b0dc-4be2-983e-822f7e586090 --key-name default_key? --nic net-id=f2c7206c-a860-4206-ab5b-34bd9b7d2553 clintd\n>+-------------------------------------+--------------------------------------+\n>| Property??????????????????????????? | Value??????????????????????????????? |\n>+-------------------------------------+--------------------------------------+\n>| status????????????????????????????? | BUILD??????????????????????????????? |\n>| updated???????????????????????????? | 2013-09-24T22:47:27Z???????????????? |\n>| OS-EXT-STS:task_state?????????????? | scheduling?????????????????????????? |\n>| OS-EXT-SRV-ATTR:host??????????????? | None???????????????????????????????? |\n>| key_name??????????????????????????? | default_key????????????????????????? |\n>| image?????????????????????????????? | Fedora?????????????????????????????? |\n>| hostId????????????????????????????? |????????????????????????????????????? |\n>| OS-EXT-STS:vm_state???????????????? | building???????????????????????????? |\n>| OS-EXT-SRV-ATTR:instance_name?????? | instance-0000000d??????????????????? |\n>| OS-EXT-SRV-ATTR:hypervisor_hostname | None???????????????????????????????? |\n>| flavor????????????????????????????? | m1.tiny????????????????????????????? |\n>| id????????????????????????????????? | b09b9547-be68-49e0-b271-f57515e44a54 |\n>| security_groups???????????????????? | [{u\'name\': u\'default\'}]????????????? |\n>| user_id???????????????????????????? | 19839209541e446da8642c67e82a63ab???? |\n>| name??????????????????????????????? | clintd?????????????????????????????? |\n>| adminPass?????????????????????????? | chRqXA9mQhxp???????????????????????? |\n>| tenant_id?????????????????????????? | b41aca749a214b449ad6b3a124d113f7???? |\n>| created???????????????????????????? | 2013-09-24T22:47:27Z???????????????? |\n>| OS-DCF:diskConfig?????????????????? | MANUAL?????????????????????????????? |\n>| metadata??????????????????????????? | {}?????????????????????????????????? |\n>| accessIPv4????????????????????????? |????????????????????????????????????? |\n>| accessIPv6????????????????????????? |????????????????????????????????????? |\n>| progress??????????????????????????? | 0??????????????????????????????????? |\n>| OS-EXT-STS:power_state????????????? | 0??????????????????????????????????? |\n>| OS-EXT-AZ:availability_zone???????? | nova???????????????????????????????? |\n>| config_drive??????????????????????? |????????????????????????????????????? |\n>+-------------------------------------+--------------------------------------+\n>\n>\n>\n>\n>\n>\n>\n>\n>\n>On Wed, Sep 25, 2013 at 9:08 AM, Clint Dilks <clintd at waikato.ac.nz> wrote:\n>\n>Hi \n>>\n>>Thanks to everyone whom replied to this thread I will try deleting the ports shortly.\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>Clint,\n>>>\n>>>you need to boot your VMs attached to the private network and not the public network. Then you must allocate and associate floating ips. Also remember to open ports in the security groups.\n>>>\n>>\n>>\n>>\n>>Darragh,\n>>\n>>\n>>In the guide I was following they used two networks \n>>\n>>\n>>10.10.10.0/24 (which they call internal)\n>>\n>>10.0.0.0/24 (which they call external)\n>>\n>>\n>>So I believed I should be able to replace where ever they use 10.0.0.0/24 with 130.217.79.0? (br-ex is currently attached to an address in this range)\n>>\n>>\n>>Are you saying that in fact I should have two private networks say mirroring the guide, but then also have a nic configured for 130.217.79.x ?\n>>\n>>\n>>Or do you just mean that keeping things as I have them currently I should just create the public-subnet within the 10.10.10.0/24 ?\n>>?\n>>\n>>\n>>\n>>\n>>?\n>>\n>>>Re, Darragh.\n>>>\n>>>\n>>>\n>>\n>\n>\n>\n\n\n','<CACdTQcVAebMs-0Q4xp-cCm13uVHfyrMn3fYv_mQnNOJ+Jf3R_g@mail.gmail.com>',NULL),('<1380134897-sup-6307@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 11:50:38',-25200,'2013-09-25 18:50:38',NULL,'[openstack-dev] [Heat] PTL candidacy','I would like to formally announce my candidacy for Heat PTL.\n\nIt has been my extreme pleasure to work with the fine Heat development\ncommunity since this past December. My interest in Heat started with using\nit as one of the many cogs in the TripleO deployment machine. However,\nI have grown to really appreciate just how much work it takes to ship\na stable orchestration engine.\n\nI see PTL as a communication focal point and an enabling position for\nthe development community around Heat. As a good friend once describe\na similar position to me, the PTL is \"the servant of the servants\".\nOf course, one duty of that servant is to relieve the others of turmoil\nwhen there is need for a PTL hammer swing. I have clashed at times with\nthe other Heat developers, but I think that is a sign of a healthy dialog,\nand not a sign of trouble at all. We are all expressing our opinions in\na healthy manner, and that should lead to a better code base and more\nrational decisions.\n\nIn Icehouse, I see Heat becoming more user driven. We have seen several\nreal users pop up here late in the Havana cycle, and I think we will see\nquite a few more over the next cycle. I\'d like to address any concerns\nthey have while deploying Havana, and make Icehouse the most boring,\nand thus useful release of Heat ever. Will we ship features? Oh yes of\ncourse we will ship features. We are integrating Heat with all of the\nother relevant projects and there will have to be a feature explosion to\naccommodate all of that. But primarily, we need to take care of the users,\nand ship a stable, useful Orchestration system and supporting tools.\n\nSo, I humbly prostrate myself upon the Heat developers and ask that you\nconsider me for such a position.\n\nSome facts for those who are data driven:\n\n* http://russellbryant.net/openstack-stats/heat-reviewers-90.txt shows\n  me as 4th in review volumeover the last 90 days.\n* The same link also shows that if you sort by ascending +/-% of core\n  devs, I am by far the meanest core reviewer. More time spent in release\n  meetings as PTL probably means you will have to deal with less of my\n  incessant nit picking.\n* https://bugs.launchpad.net/heat/+bugs?search=Search&field.bug_reporter=clint-fewbar\n  I have opened 22 bugs that are still open (and many that are closed.) I\n  have quite a bit of motivation to aid the Heat development community\n  in getting not only my bugs, but as many of the bugs in Heat addressed\n  as possible.\n* My name is not, in fact, Steve. You may consider this a pro, or a con.\n\nClint Byrum\nSenior Server/Cloud Software Engineer - HP\n\n\n',NULL,NULL),('<1380135162-sup-9495@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 11:54:46',-25200,'2013-09-25 18:54:46',NULL,'[openstack-dev] Current list of confirmed PTL Candidates','Excerpts from Joshua Harlow\'s message of 2013-09-25 11:15:21 -0700:\n> I agree with all that u guys are saying and I think that the current PTL\'s\n> have done a great job and I know that there is a lot to take under\n> consideration when submitting a potential PTL candidacy and that its all\n> about delegating, integrating, publicizing.\n> \n> I don\'t think any of that is in question.\n> \n> I am just more concerned about the \'diversity\' issue, which looking at\n> https://wiki.openstack.org/wiki/PTL_Elections_Fall_2013#Candidates is imho\n> lacking (1 person elections aren\'t really elections). Now of course this\n> may not be an immediate problem, but it does not seem to be the ideal\n> situation a community would be in; I just imagine a community that has a\n> multi-person elections (those multi-people don\'t need to be at each others\n> throats, or even competitors, or any of that) and which thrives off the\n> diversity of those different people.\n> \n> It just seems like something we can work on as a community, to ensure that\n> there is diversity.\n> \n\nAlright, you all convinced me that having some diversity in the elections\nfor PTL is a good thing, and thus I\'m going to offer my services as Heat\nPTL this cycle. May Gerrit have mercy on their commit messages.\n\n\n','<CE687121.485E9%harlowja@yahoo-inc.com>',NULL),('<1380140068-sup-4695@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 13:23:07',-25200,'2013-09-25 20:23:07',NULL,'[openstack-dev] [heat] [scheduler] Bringing things together for\n	Icehouse (now featuring software orchestration)','Excerpts from Thomas Spatzier\'s message of 2013-09-25 00:59:44 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 25.09.2013 08:46:57:\n> > From: Clint Byrum <clint at fewbar.com>\n> > To: openstack-dev <openstack-dev at lists.openstack.org>,\n> > Date: 25.09.2013 08:48\n> > Subject: Re: [openstack-dev] [heat] [scheduler] Bringing things\n> > together for Icehouse (now featuring software orchestration)\n> >\n> > Excerpts from Mike Spreitzer\'s message of 2013-09-24 22:03:21 -0700:\n> > > Let me elaborate a little on my thoughts about software orchestration,\n> and\n> > > respond to the recent mails from Zane and Debo.  I have expanded my\n> > > picture at\n> > > https://docs.google.com/drawings/d/\n> > 1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U\n> > > and added a companion picture at\n> > > https://docs.google.com/drawings/d/1TCfNwzH_NBnx3bNz-\n> > GQQ1bRVgBpJdstpu0lH_TONw6g\n> > > that shows an alternative.\n> > >\n> > > One of the things I see going on is discussion about better techniques\n> for\n> > > software orchestration than are supported in plain CFN.  Plain CFN\n> allows\n> > > any script you want in userdata, and prescription of certain additional\n> \n> > > setup elsewhere in cfn metadata.  But it is all mixed together and very\n> \n> > > concrete.  I think many contributors would like to see something with\n> more\n> > > abstraction boundaries, not only within one template but also the\n> ability\n> > > to have modular sources.\n> > >\n> >\n> > Yes please. Orchestrate things, don\'t configure them. That is what\n> > configuration tools are for.\n> >\n> > There is a third stealth-objective that CFN has caused to linger in\n> > Heat. That is \"packaging cloud applications\". By allowing the 100%\n> > concrete CFN template to stand alone, users can \"ship\" the template.\n> >\n> > IMO this marrying of software assembly, config, and orchestration is a\n> > concern unto itself, and best left outside of the core infrastructure\n> > orchestration system.\n> >\n> > > I work closely with some colleagues who have a particular software\n> > > orchestration technology they call Weaver.  It takes as input for one\n> > > deployment not a single monolithic template but rather a collection of\n> > > modules.  Like higher level constructs in programming languages, these\n> > > have some independence and can be re-used in various combinations and\n> > > ways.  Weaver has a compiler that weaves together the given modules to\n> > > form a monolithic model.  In fact, the input is a modular Ruby program,\n> \n> > > and the Weaver compiler is essentially running that Ruby program; this\n> > > program produces the monolithic model as a side effect.  Ruby is a\n> pretty\n> > > good language in which to embed a domain-specific language, and my\n> > > colleagues have done this.  The modular Weaver input mostly looks\n> > > declarative, but you can use Ruby to reduce the verboseness of, e.g.,\n> > > repetitive stuff --- as well as plain old modularity with abstraction.\n> We\n> > > think the modular Weaver input is much more compact and better for\n> human\n> > > reading and writing than plain old CFN.  This might not be obvious when\n> \n> > > you are doing the \"hello world\" example, but when you get to realistic\n> > > examples it becomes clear.\n> > >\n> > > The Weaver input discusses infrastructure issues, in the rich way Debo\n> and\n> > > I have been advocating, as well as software.  For this reason I\n> describe\n> > > it as an integrated model (integrating software and infrastructure\n> > > issues).  I hope for HOT to evolve to be similarly expressive to the\n> > > monolithic integrated model produced by the Weaver compiler.\n> \n> I don\'t fully get this idea of HOT consuming a monolithic model produced by\n> some compiler - be it Weaver or anything else.\n> I thought the goal was to develop HOT in a way that users can actually\n> write HOT, as opposed to having to use some \"compiler\" to produce some\n> useful model.\n> So wouldn\'t it make sense to make sure we add the right concepts to HOT to\n> make sure we are able to express what we want to express and have things\n> like composability, re-use, substitutability?\n> \n\nWe saw this in the history of puppet in fact, where the DSL was always the\nproblem when trying to make less-than-obvious components, and eventually\npuppet had to grow a full \"ruby dsl\" to avoid those mistakes and keep up\nwith Chef\'s language-first approach.\n\n> > >\n> >\n> > Indeed, we\'re dealing with this very problem in TripleO right now. We\n> need\n> > to be able to compose templates that vary slightly for various reasons.\n> >\n> > A ruby DSL is not something I think is ever going to happen in\n> > OpenStack. But python has its advantages for DSL as well. I have been\n> > trying to use clever tricks in yaml for a while, but perhaps we should\n> > just move to a client-side python DSL that pushes the compiled yaml/json\n> > templates into the engine.\n> \n> As said in my comment above, I would like to see us focusing on the\n> agreement of one language - HOT - instead of yet another DSL.\n> There are things out there that are well established (like chef or puppet),\n> and HOT should be able to efficiently and intuitively use those things and\n> orchestrate components built using those things.\n> \n> Anyway, this might be off the track that was originally discussed in this\n> thread (i.e. holistic scheduling and so on) ...\n>\n\nSo yes, we should make sure to interface with other tools. But it stands\nto reason that not all orchestration solutions are representable as a\nseries of data structures. We need loops, and conditionals, and callables,\nso that we can write reusable, testable components. Fighting that just\nmeans punting it off to a compiler anyway.\n\nOrchestration DSL authors are not immune to the sort of pitfalls any\nother language authors may encounter, so we shouldn\'t consider the\nproblem space special and ignore the principles other languages have\nembraced to avoid the dark scary spots.\n\nI think we already have some summit suggestions for discussing HOT,\nit would be good to come prepared with some visions for the future\nof HOT so that we can hash these things out, so I\'d like to see this\ndiscussion continue.\n\n\n','<OF4EE96BED.DC60B243-ONC1257BF1.002B3D4B-C1257BF1.002BEC0F@de.ibm.com>',NULL),('<1380170931-sup-4517@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 21:49:06',-25200,'2013-09-26 04:49:06',NULL,'[openstack-dev] [elastic-recheck] Announcing elastic-recheck','Excerpts from Joe Gordon\'s message of 2013-09-25 17:56:15 -0700:\n> Hi All,\n> \n> TL;DR: We will be automatically identifying your flaky tempest runs, so you\n> just have to confirm that you hit bug x, not identify which bug you hit.\n> \n\n\\o/\n\n\n','<CAHXdxOfFn9DQRRkuDwOsJ+8Y2D8KLvRbxzWWbsZWJyBJus4hHQ@mail.gmail.com>',NULL),('<1380173219.69172.YahooMailNeo@web163501.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-25 22:26:59',-25200,'2013-09-26 05:26:59',NULL,'[Openstack] How are OpenStack security groups implemented?','Hi,\n\nHow are OpenStack security groups implemented? Is the firewall on the host that implements those rules? Is it implemented by Nova or networking component?\n\nWhat operations happens in the background when a particular port is added into an exception??\n\nThanks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130925/531730a0/attachment.html>\n\n',NULL,NULL),('<1380199029.67855.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-26 13:37:09',3600,'2013-09-26 12:37:09',NULL,'[Openstack] loop on network with openvswitch + vlans','Pavel,\n\n\n?why are you restarting Open vSwitch?I think these steps should work when you have to:\n\n- stop quantum-ovs-plugin-agent\n- stop openvswitch services\n- start openvswitch services\n- run quantum-ovs-cleanup\n- start quantum-ovs-plugin-agent\n\n\nRe, Darragh.\n? \n\n>Message: 3\n>Date: Thu, 26 Sep 2013 13:50:36 +0200\n>From: Pavel Stano <stano at websupport.sk>\n>To: openstack at lists.openstack.org\n>Subject: [Openstack] loop on network with openvswitch + vlans\n>Message-ID: <52441F8C.50509 at websupport.sk>\n>Content-Type: text/plain; charset=ISO-8859-1; format=flowed\n>\n>Hi,\n>\n>we encountered some problem on our setup with openvswitch with multiple \n>nodes.\n>When openstack is running ok and we restart openvswitch on 2 or more \n>compute nodes, flow tables on br-int will be cleared and \n>quantum-plugin-openvswitch-agent will not re-configure it until it will \n>be restarted too.\n>Ports are still attached to br-int but without flows.\n>So after flows are cleared there occur loop on network.\n>\n>We want to fix it by modifing openvswitch init script to dump/load flows \n>when stop/start/restart, it dont do it automatically. Or another \n>alterantive is forcibly remove br-int when stopping openvwswitch.\n>\n>And of course automatically restart quantum-plugin-openvswitch-agent \n>after openvswitch restart.\n>\n>Anyone encounter same problem and/or have some better solution ?\n>\n>Thanks\n>--\n>[ Ohodnotte kvalitu mailu: http://nicereply.com/websupport/Stano/ ]\n>\n>Pavel Stano | Troubleshooter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130926/3858c253/attachment.html>\n\n',NULL,NULL),('<1380210077.13436630@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 11:41:17',-14400,'2013-09-26 15:41:17',NULL,'[openstack-dev] New Pycharm License','\nHey Devs,\n \nIt\'s almost been a year since I sent out the first email and I\'ve been getting a few emails lately about alerts that the current license is about to expire. Well, I\'ve got a hold of our new license, good for another year. This\'ll give you access to the new Pro edition of Pycharm and any updates for a year.\n \nAs this list is public, I can\'t email the license out to everyone, so please reply to this email and I\'ll get you the license.\n \nAlso, please note that if your current license expires, Pycharm will continue to work. You will just stop receiving updates until you\'ve entered this new license.\n \nThanks,\nAndrew Melton\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/0e084c3a/attachment.html>\n\n',NULL,NULL),('<1380212570-sup-4308@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 09:48:26',-25200,'2013-09-26 16:48:26',NULL,'[openstack-dev] [keystone] Case sensitivity & backend databases','Excerpts from Henry Nash\'s message of 2013-09-25 01:45:32 -0700:\n> Hi\n> \n> Do we specify somewhere whether text field matching in the API is case sensitive or in-sensitive?  I\'m thinking about filters, as well as user and domain names in authentication.  I think our current implementation will always be case sensitive for filters  (since we do that in python and do not, yet, pass the filters to the backends), while authentication will reflect the \"case sensitivity or lack thereof\" of the underlying database.  I believe that MySQL is case in-sensitive by default, while Postgres, sqllite and others are case-sensitive by default.  If using an LDAP backend, then I think this is case-sensitive.\n> \n> The above seems to be inconsistent.  It might become even more so when we pass the filters to the backend.  Given that other projects already pass filters to the backend, we may also have inter-project inconsistencies that bleed through to the user experience.  Should we make at least a recommendation that the backend should case-sensitive (you can configure MySQL to be so)?  Insist on it? Ignore it and keep things as they are?\n\nThe collation controls case sensitivity. The default collations in MySQL\nare all case in-sensitive, and this is a good thing for many reasons. I\ndon\'t want a user \"spamaps\" on the same domain where I have \"SpamapS\".\n\nIf you want to force it, you can do so at many levels, from the server\ndown to the column.  utf8_bin would be the case-sensitive collation to\nuse. But that is not actually what you want.\n\nThe problem and the part where programmers get surprised by this is\nthat we are calling fields VARCHAR when we mean VARBINARY. Strings that\nalways need to be 100% identical and are not for human consumption,\nshould be _BINARY_.\n\nIn the keystone user table, id, extra, password, and domain_id are all\n\"varchar\". This is a common mistake in SQL column design. Since user\nis a utf8 table, the index on id varchar(64) is 64*3 bytes wide. This\nis because we have to reserve enough space for 64 UTF-8 characters (and\nMySQL only does up to 3-byte UTF8, really obscure UTF-8 can be as long\nas 6 bytes!). We don\'t intend to interpret this as a human ever. So,\nthis should be VARBINARY(64) everywhere it is used.\n\nThe change would have several effects:\n\n1) Indexes that mention the field would shrink by 128 bytes per key.\n\n2) One could have two rows with identical hex values in id that varied\nonly by case. -- This is not an actual problem, but an effect of the\nchange.\n\n3) Sorting by this field will now just use the binary value of each\ncharacter, not the language collation. When do you sort by a hex id?\n\nAnyway, doing this on all ID fields and obviously-not-utf8-containing\nfields will have a net effect of making the database leaner, so I think\nit is worth a wide spread effort not just in keystone but in all of\nOpenStack.\n\n\n','<8F574BBB-FA62-455A-BE89-89F5A19731BC@linux.vnet.ibm.com>',NULL),('<1380214252.16268.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-27 00:50:52',28800,'2013-09-26 16:50:52',NULL,'[Openstack] Fw: problem in understanding interaction between swift\n	proxy and other servers through swift source code','hello,\n\nI am forwarding this mail again.\nPlease help me in this regard.\n\n---\nThanks?\n\nPragya Jain\n\n\n----- Forwarded Message -----\n>From: pragya jain <prag_2648 at yahoo.co.in>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Cc: anita goel <goel.anita at gmail.com> \n>Sent: Tuesday, 24 September 2013 5:37 PM\n>Subject: problem in understanding interaction between swift proxy and other servers through swift source code\n> \n>\n>\n>Hello,\n>\n>\n>I am studying swift source code.\n>\n>\n>My problem is:\n>1) What are the roles of class AccountController defined in swift / proxy / controllers / account.py and class AccountController defined in swift / account / server.py\n>2) How these two classes differ from each other and?\n>3) How these two class interact with each other i.e.?\n>According to my understanding, when a user make a request, __call__() function defined in Application class in swift / proxy /server.py is executed, which ,in turn, calls handle_request() function which sends the control to the swift / proxy / controllers?\n>\n>\n>Now, I can\'t understand through which function call will the control go from proxy server to other (account/container/object) ?server\n>\n>\n>Please help me in this regard\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/e7d93cf9/attachment.html>\n\n','<1380024474.73553.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1380215239-sup-7032@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-26 10:10:37',-25200,'2013-09-26 17:10:37',NULL,'[Openstack] config_drive with Cinder boot from volume','Excerpts from Byron McCollum\'s message of 2013-09-26 06:30:57 -0700:\n> Are you talking about booting from a volume that was created from an image (bootable volume)?\n> \n> Depending on cloud-init\'s configuration, it might be configured to only run on first boot. If that volume had previously been used to boot an instance, cloud-init will not run on subsequent boots from the volume.\n> \n\nThis is not true. cloud-init will run at every boot, and use the\nmeta-data it has access to to determine the current instance-id, and if\nit has changed, cloud-init will run first-boot processes again such as\ngenerating SSH keys and running cloud-config.\n\nIt sounds to me like cloud-init isn\'t even able to access the config\ndrive and thus can\'t determine the instance-id.\n\nI wonder if the boot-from-volume has changed something about the\ndevices, and thus is getting in the way of how cloud-init discovers\nthe config-drive.\n\nYour best bet is the console log, which will be where cloud-init prints\nout what it is doing.\n\n\n','<B6D394B4-0391-4EFA-B6D0-2161AE372BEA@rackspace.com>',NULL),('<1380216009.83676.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-26 18:20:09',3600,'2013-09-26 17:20:09',NULL,'[Openstack] loop on network with openvswitch + vlans','Pavel,\n\nsorry - ignore my previous email and don\'t run quantum-ovs-cleanup. Steps should be: \n\n- stop quantum-ovs-plugin-agent\n- stop openvswitch services\n- start openvswitch services\n- start quantum-ovs-plugin-agent\n\nRe, Darragh.\n>________________________________\n> From: Darragh O\'Reilly <dara2002-openstack at yahoo.com>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Thursday, 26 September 2013, 13:37\n>Subject: Re: [Openstack] loop on network with openvswitch + vlans\n> \n>\n>\n>Pavel,\n>\n>\n>\n>?why are you restarting Open vSwitch? I think these steps should work when you have to:\n>\n>- stop quantum-ovs-plugin-agent\n>- stop openvswitch services\n>- start openvswitch services\n>- run quantum-ovs-cleanup\n>- start quantum-ovs-plugin-agent\n>\n>\n>\n>Re, Darragh.\n>? \n>\n>>Message: 3\n>>Date: Thu, 26 Sep 2013 13:50:36 +0200\n>>From: Pavel Stano <stano at websupport.sk>\n>>To: openstack at lists.openstack.org\n>>Subject: [Openstack] loop on network with openvswitch + vlans\n>>Message-ID: <52441F8C.50509 at websupport.sk>\n>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed\n>>\n>>Hi,\n>>\n>>we encountered some problem on our setup with openvswitch with multiple \n>>nodes.\n>>When openstack is running ok and we restart openvswitch on 2 or more \n>>compute nodes, flow tables on\nbr-int will be cleared and \n>>quantum-plugin-openvswitch-agent will not re-configure it until it will \n>>be restarted too.\n>>Ports are still attached to br-int but without flows.\n>>So after flows are cleared there occur loop on network.\n>>\n>>We want to fix it by modifing openvswitch init script to dump/load flows \n>>when stop/start/restart, it dont do it automatically. Or another \n>>alterantive is forcibly remove br-int when stopping openvwswitch.\n>>\n>>And of course automatically restart quantum-plugin-openvswitch-agent \n>>after openvswitch restart.\n>>\n>>Anyone encounter same problem and/or have some better solution ?\n>>\n>>Thanks\n>>--\n>>[ Ohodnotte kvalitu mailu: http://nicereply.com/websupport/Stano/ ]\n>>\n>>Pavel Stano | Troubleshooter\n>\n>\n>\n\n\n','<1380199029.67855.YahooMailNeo@web172402.mail.ir2.yahoo.com>',NULL),('<1380265013.61327.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-27 14:56:53',28800,'2013-09-27 06:56:53',NULL,'[Openstack] Fw: problem in understanding interaction between\n	swift	proxy and other servers through swift source code','Thanks Zhang for the reply.\nbut my question is:\nAccording to swift source code,\nthrough which function call, the proxy server interact with account server, i.e., flow of control go from proxy server code to account server code?\n\nThanks again\n\nPragya Jain\n\n\n\n\n>________________________________\n> From: Hua ZZ Zhang <zhuadl at cn.ibm.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 27 September 2013 7:25 AM\n>Subject: Re: [Openstack] Fw: problem in understanding interaction between swift	proxy and other servers through swift source code\n> \n>\n>\n>\n>\n>pragya jain ---2013-09-27 ?? 12:52:40---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n> \n>\n>To \n> \n>\n>\n>cc \n> \n>\n>\n>Subject \n>    \n>hello,\n>\n>I am forwarding this mail again.\n>Please help me in this regard.\n>\n>---\n>Thanks \n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/140b602e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/140b602e/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/140b602e/attachment-0001.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: pic18614.gif\nType: image/gif\nSize: 1255 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/140b602e/attachment-0002.gif>\n\n','<OF5A0E14C2.ECDC5BFE-ON48257BF3.000900F8-48257BF3.000AA916@cn.ibm.com>',NULL),('<1380269489.96608.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-27 16:11:29',28800,'2013-09-27 08:11:29',NULL,'[Openstack] Fw: problem in understanding interaction between\n	swift	proxy and other servers through swift source code','But, Sir, At which line of code in the func?\ndef?_make_request(self, nodes, part, method, path, headers, query,? ? ? ? ? ? ? ? ? ? ? logger_thread_locals):?\nflow of control move to the AccoountController class defined in swift/account/server.py (for example)\n\ndef _make_request(self, nodes, part, method, path, headers, query,\n??????????????????????logger_thread_locals):\n????????\"\"\"\nSends an HTTP request to a single node and aggregates the result.\nIt attempts the primary node, then iterates over the handoff nodes\nas needed.\n\n:param nodes: an iterator of the backend server and handoff servers\n:param part: the partition number\n:param method: the method to send to the backend\n:param path: the path to send to the backend\n:param headers: a list of dicts, where each dict represents one\nbackend request that should be made.\n:param query: query string to send to the backend.\n:param logger_thread_locals: The thread local values to be set on the\nself.app.logger to retain transaction\nlogging information.\n:returns: a swob.Response object\n\"\"\"\n????????self.app.logger.thread_locals = logger_thread_locals\n????????for node in nodes:\n????????????try:\n????????????????start_node_timing = time.time()\n????????????????with ConnectionTimeout(self.app.conn_timeout):\n????????????????????conn = http_connect(node[\'ip\'], node[\'port\'],\n????????????????????????????????????????node[\'device\'], part, method, path,\n????????????????????????????????????????headers=headers, query_string=query)\n????????????????????conn.node = node\n????????????????self.app.set_node_timing(node, time.time() - start_node_timing)\n????????????????with Timeout(self.app.node_timeout):\n????????????????????resp = conn.getresponse()\n????????????????????if not is_informational(resp.status) and \\\n????????????????????????????not is_server_error(resp.status):\n????????????????????????return resp.status, resp.reason, resp.getheaders(), \\\n????????????????????????????resp.read()\n????????????????????elif resp.status == HTTP_INSUFFICIENT_STORAGE:\n????????????????????????self.error_limit(node, _(\'ERROR Insufficient Storage\'))\n????????????except (Exception, Timeout):\n????????????????self.exception_occurred(node, self.server_type,\n????????????????????????????????????????_(\'Trying to %(method)s%(path)s\') %\n????????????????????????????????????????{\'method\': method, \'path\': path})\n\n---\n\nThank you very much?\n\nPragya Jain\n\n>________________________________\n> From: Hua ZZ Zhang <zhuadl at cn.ibm.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 27 September 2013 1:12 PM\n>Subject: Re: [Openstack] Fw: problem in understanding interaction between swift	proxy and other servers through swift source code\n> \n>\n>\n>in swift/proxy/controllers/base.py\n>\n>def make_requests(self, req, ring, part, method, path, headers,\n>? ? ? ? ? ? ? ? ? ? ? query_string=\'\'):\n>\n>def?_make_request(self, nodes, part, method, path, headers, query,\n>? ? ? ? ? ? ? ? ? ? ? logger_thread_locals):\n>\n>\n>pragya jain ---2013-09-27 ?? 02:55:44---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n> \n>\n>To \n> \n>\n>\n>cc \n> \n>\n>\n>Subject \n>    \n>Thanks Zhang for the reply.\n>but my question is:\n>According to swift source code,\n>through which function call, the proxy server interact with account server, i.e., flow of control go from proxy server code to account server code?\n>\n>Thanks again\n>\n>Pragya Jain\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/fbc37b17/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/fbc37b17/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/fbc37b17/attachment-0001.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: pic11525.gif\nType: image/gif\nSize: 1255 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130927/fbc37b17/attachment-0002.gif>\n\n','<OF5B8C9D26.809BBCAC-ON48257BF3.002A1F98-48257BF3.002A719D@cn.ibm.com>',NULL),('<1380286192.49935.YahooMailNeo@web162905.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-27 05:49:52',-25200,'2013-09-27 12:49:52',NULL,'[openstack-dev] VM instances Can not connect to external','I think you just have to add a dns-nameserver on the private network. Like 8.8.8.8 .\nI hope it helps.\n\n________________________________\n From: Yongsheng Gong <gongysh at unitedstack.com>\nTo: OpenStack Development Mailing List <openstack-dev at lists.openstack.org> \nSent: Friday, September 27, 2013 2:15 PM\nSubject: Re: [openstack-dev] VM instances Can not connect to external\n \n\n\nhave u enable the port interface of br-ex? For example ifconfig eth1 up\n\n\n\nOn Fri, Sep 27, 2013 at 7:26 PM, Jeff Cai <Jeff_Cai at symantec.com> wrote:\n\nI did all that the doc tells me to do, which includes\n>setting up a bridge in the network node.\n>?\n>Just like http://docs.openstack.org/grizzly/basic-install/apt/content/basic-install_network.html#basic-install_network-services\n>?\n>I did the Procedure 2.2-4 and 2.2-5.\n>?\n>Jeff\n>?\n>From:Ashok Kumaran [mailto:ashokkumaran.b at gmail.com] \n>Sent: Friday, September 27, 2013 6:33 PM\n>To: OpenStack Development Mailing List\n>Subject: Re: [openstack-dev] VM instances Can not connect to external\n>?\n>You have IP forwarding enabled?\n>?\n>Did you create br-ex bridge and associated the external as a port to it?\n>?\n>On Fri, Sep 27, 2013 at 3:33 PM, Jeff Cai <Jeff_Cai at symantec.com> wrote:\n>Hi,\n>?\n>I set up openstack environment on Ubuntu 12.0.4 with 3 nodes according to the starter guide on docs.openstack.org. Everything works well except that the VM instances cannot connect to outside. Among VM instances they can connect to each other.\n>?\n>Attached the network diagram:\n>?\n>?\n>In VM, it can ping the demo-router address 10.5.5.1 (internal) and 10.200.29.33 (external). But it cannot ping out the other external addresses.\n>?\n>Both the public and demo-net network work normally:\n>?\n>Project?? Network Name????? Subnets Associated???????????????????????? Shared???????? Status?????????? Admin State\n>admin ???public? ?????????????????????????public-subnet 10.200.29.0/24????? No? ????????????????Active ?????????????Up\n>demo??? demo-net????????????????? demo-net-subnet 10.5.5.0/24???? No????????????????? Active????????????? Up\n>?\n>But the port where the demo router is DOWN\n>?\n>?\n>(bd10e227)?????????????? 10.200.29.33???? network:router_gateway????????????? DOWN?????????? UP\n>?\n>?\n>The port info:\n>?\n>Port\n>\n>________________________________\n>\n>Name\n>None\n>ID\n>bd10e227-8f83-4804-9f68-a0e643e451e5\n>Network ID\n>d415febb-b387-40e0-9416-32c1b19d5b46\n>Project ID\n>-\n>Fixed IP\n>IP address: 10.200.29.33, Subnet ID 6781dfdc-508b-46c3-89ce-5624f95448d0\n>Mac Address\n>fa:16:3e:e2:b2:b3\n>Status\n>DOWN\n>Admin State\n>UP\n>Attached Device\n>Device Owner: network:router_gateway\n>Device ID: 5d43330d-c0ee-4bd5-a76f-b15daad1df2e\n>?\n>?\n>Could anyone please give me some clues to solve this problem?\n>?\n>Best Regards\n>?\n>Jeff Cai\n>?\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n>?\n>?\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130927/9a263a92/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 29450 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130927/9a263a92/attachment.png>\n\n','<CAEM-rjQvr0kj94fx0oYENm5EZjtruRZ1AyEvdVcuAn2ZGbf57A@mail.gmail.com>',NULL),('<1380295351-sup-6511@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-27 08:58:16',-25200,'2013-09-27 15:58:16',NULL,'[openstack-dev] [scheduler] [heat] Policy specifics','Excerpts from Zane Bitter\'s message of 2013-09-27 06:58:40 -0700:\n> On 27/09/13 08:58, Mike Spreitzer wrote:\n> > I have begun to draft some specifics about the sorts of policies that\n> > might be added to infrastructure to inform a smart unified placement\n> > engine.  These are cast as an extension to Heat templates.  See\n> > https://wiki.openstack.org/wiki/Heat/PolicyExtension.  Comments solicited.\n> \n> Mike,\n> These are not the kinds of specifics that are of any help at all in \n> figuring out how (or, indeed, whether) to incorporate holistic \n> scheduling into OpenStack.\n\nI agree that the things in that page are a wet dream of logical deployment\nfun. However, I think one can target just a few of the basic ones,\nand see a real achievable case forming. I think I grasp Mike\'s ideas,\nso I\'ll respond to your concerns with what I think. Note that it is\nhighly likely I\'ve gotten some of this wrong.\n\n> \n> - What would a holistic scheduling service look like? A standalone \n> service? Part of heat-engine?\n\nI see it as a preprocessor of sorts for the current infrastructure engine.\nIt would take the logical expression of the cluster and either turn\nit into actual deployment instructions or respond to the user that it\ncannot succeed. Ideally it would just extend the same Heat API.\n\n> - How will the scheduling service reserve slots for resources in advance \n> of them being created? How will those reservations be accounted for and \n> billed?\n> - In the event that slots are reserved but those reservations are not \n> taken up, what will happen?\n\nI dont\' see the word \"reserve\" in Mike\'s proposal, and I don\'t think this\nis necessary for the more basic models like Collocation and Anti-Collocation.\n\nReservations would of course make the scheduling decisions more likely to\nsucceed, but it isn\'t necessary if we do things optimistically. If the\nstack create or update fails, we can retry with better parameters.\n\n> - Once scheduled, how will resources be created in their proper slots as \n> part of a Heat template?\n\nIn goes a Heat template (sorry for not using HOT.. still learning it. ;)\n\nResources:\n  ServerTemplate:\n    Type: Some::Defined::ProviderType\n  HAThing1:\n    Type: OS::Heat::HACluster\n    Properties:\n      ClusterSize: 3\n      MaxPerAZ: 1\n      PlacementStrategy: anti-collocation\n      Resources: [ ServerTemplate ]\n\nAnd if we have at least 2 AZ\'s available, it feeds to the heat engine:\n\nResources:\n  HAThing1-0:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        availability-zone: zone-A\n  HAThing1-1:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        availability-zone: zone-B\n  HAThing1-2:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        availability-zone: zone-A\n\nIf not, holistic scheduler says back \"I don\'t have enough AZ\'s to\nsatisfy MaxPerAZ\".\n\nNow, if Nova grows anti-affininty under the covers that it can manage\ndirectly, a later version can just spit out:\n\nResources:\n  HAThing1-0:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        instance-group: 0\n        affinity-type: anti\n  HAThing1-1:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        instance-group: 1\n        affinity-type: anti\n  HAThing1-2:\n    Type: Some::Defined::ProviderType\n      Parameters:\n        instance-group: 0\n        affinity-type: anti\n\nThe point is that the user cares about their servers not being in the\nsame failure domain, not how that happens.\n\n> - What about when the user calls the APIs directly? (i.e. does their own \n> orchestration - either hand-rolled or using their own standalone Heat.)\n\nThis has come up with autoscaling too. \"Undefined\" - that\'s not your stack.\n\n> - How and from where will the scheduling service obtain the utilisation \n> data needed to perform the scheduling? What mechanism will segregate \n> this information from the end user?\n\nI do think this is a big missing piece. Right now it is spread out\nall over the place. Keystone at least has regions, so that could be\nincorporated now. I briefly dug through the other API\'s and don\'t see\na way to enumerate AZ\'s or cells. Perhaps it is hiding in extensions?\n\nI don\'t think this must be segregated from end users. An API for \"show\nme the placement decisions I can make\" seems useful for anybody trying\nto automate deployments. Anyway, probably best to keep it decentralized\nand just make it so that each service can respond with lists of arguments\nto their API that are likely to succeed.\n\n> - How will users communicate their scheduling constraints to OpenStack? \n> (Through which API and in what form?)\n\nSee above. Via the Heat API, a Heat-ish template that is turned into\nconcrete Heat instructions.\n\n> - What value does this provide (over and above non-holistic scheduler \n> hints passed in individual API calls) to end users? Public cloud \n> operators? Private cloud operators? How might the value be shared \n> between users and operators, and how would that be accounted for?\n\nSee above, logically expressing what you actually want means the tool\ncan improve its response to that. Always expressing things concretely\nmeans that improvements on the backend are harder to realize.\n\nUltimately, it is an end-user tool, but the benefit to a cloud operator\ncould be significant.  If one AZ is getting flooded, one can stop\nresponding to it, or add hints in the API ranking the AZ lower than\nthe others in preference. Users using the holistic scheduler will begin\nusing the new AZ without having to be educated about it.\n\n> - Does this fit within the scope of an existing OpenStack program? Which \n> one? Why?\n\nHeat. You want users to use holistic scheduling when it can work for them,\nso having it just be a tweak to their templates is a win.\n\n> - What changes are required to existing services to accommodate this \n> functionality?\n> \n\nMore exposure of what details can be exploited.\n\n\n','<52458F10.1@redhat.com>',NULL),('<1380309831-sup-181@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-27 12:28:45',-25200,'2013-09-27 19:28:45',NULL,'[openstack-dev] [scheduler] [heat] Policy specifics','Excerpts from Mike Spreitzer\'s message of 2013-09-27 11:51:20 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 09/27/2013 11:58:16 AM:\n> \n> > From: Clint Byrum <clint at fewbar.com>\n> > To: openstack-dev <openstack-dev at lists.openstack.org>, \n> > Date: 09/27/2013 12:01 PM\n> > Subject: Re: [openstack-dev] [scheduler] [heat] Policy specifics\n> > \n> > > - Does this fit within the scope of an existing OpenStack program? \n> Which \n> > > one? Why?\n> > \n> > Heat. You want users to use holistic scheduling when it can work for \n> them,\n> > so having it just be a tweak to their templates is a win.\n> \n> I think this is actually a pretty interesting question.  If we recognize \n> that the heat program has a bigger view (all kinds of orchestration) than \n> today\'s heat engine (infrastructure orchestration), this can partly help \n> untangle heat/not-heat debate.   Holistic infrastructure scheduling is a \n> form of scheduling, and the nova scheduler group has some interest in it, \n> but it is inherently not limited to nova.  I think it fits best between \n> software orchestration preparation and infrastructure orchestration --- in \n> the middle of the interests of the heat program. I think we may want to \n> recognize that the best flow of processing does not necessarily intersect \n> the interests of a given program in only one contiguous region.\n> \n\nSo I think I responded incorrectly. The _program_ is \"OpenStack\nOrchestration\".  The project could call itself heat-something else too,\nor could have another name entirely.\n\nThey need to be connected in some way, as the user experience should be\ncongruent whether users use concrete or holistic templating. Also being\nable to mix the two would be key to letting users solve problems that\nthe holistic scheduler cannot yet solve.\n\nThis reaches into other programs too. Trove, Savanna, etc., are all trying\nto provide the user with a simplified interface to spin up common cluster\ntypes. This would be ideal for expressing and deploying those clusters.\n\n\n','<OF355901A2.9000DE55-ON85257BF3.0062F1E1-85257BF3.00679376@us.ibm.com>',NULL),('<1380345596.66234.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-28 13:19:56',28800,'2013-09-28 05:19:56',NULL,'[Openstack] Fw: problem in understanding interaction between\n	swift	proxy and other servers through swift source code','Thanks a lot for the response, Sir\n\n\n\n>________________________________\n> From: Hua ZZ Zhang <zhuadl at cn.ibm.com>\n>To: pragya jain <prag_2648 at yahoo.co.in> \n>Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Friday, 27 September 2013 2:45 PM\n>Subject: Re: [Openstack] Fw: problem in understanding interaction between swift	proxy and other servers through swift source code\n> \n>\n>\n>see underlined code below. it is invoked by sending http request and get result from response.\n>\n>\n>pragya jain ---2013-09-27 ?? 04:10:21---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n> \n>\n>To \n> \n>\n>\n>cc \n> \n>\n>\n>Subject \n>    \n>But, Sir, At which line of code in the func \n>def?_make_request(self, nodes, part, method, path, headers, query,\n>? ? ? ? ? ? ? ? ? ? ? logger_thread_locals): \n>flow of control move to the AccoountController class defined in swift/account/server.py (for example)\n>\n>def?_make_request(self, nodes, part, method, path, headers, query,\n>? ? ? ? ? ? ? ? ? ? ? logger_thread_locals):\n>? ? ? ? \"\"\"\n>? ? ? ? Sends an HTTP request to a single node and\n>aggregates the result.\n>? ? ? ? It attempts the primary node, then iterates over the handoff nodes\n>? ? ? ? as needed.\n>\n>? ? ? ? :param nodes: an iterator of the backend server and handoff servers\n>? ? ? ? :param part: the partition number\n>? ? ? ? :param method: the method to send to the\n>backend\n>? ? ? ? :param path: the path to send to the backend\n>? ? ? ? :param headers: a list of dicts, where each dict represents one\n>? ? ? ? ? ? ? ? ? ? ? ? backend request that should be made.\n>? ? ? ? :param query: query string to send to the backend.\n>? ? ? ? :param logger_thread_locals: The thread local values to be set on the\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?self.app.logger to retain transaction\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?logging information.\n>? ? ? ? :returns: a swob.Response object\n>? ? ? ? \"\"\"\n>? ? ? ? self.app.logger.thread_locals =?logger_thread_locals\n>? ? ? ? for?node in?nodes:\n>? ? ? ? ? ? try:\n>? ? ? ? ? ? ? ? start_node_timing =?time.time()\n>? ? ? ? ? ? ? ? with?ConnectionTimeout(self.app.conn_timeout):\n>? ? ? ? ? ? ? ? ? ??conn =?http_connect(node[\'ip\'], node[\'port\'],\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? node[\'device\'], part, method, path,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? headers=headers, query_string=query)\n>? ? ? ? ? ? ? ? ? ? conn.node =?node\n>? ? ? ? ? ? ? ? self.app.set_node_timing(node, time.time() -?start_node_timing)\n>? ? ? ? ? ? ? ? with?Timeout(self.app.node_timeout):\n>? ? ? ? ? ? ? ? ? ??resp =?conn.getresponse()\n>? ? ? ? ? ? ? ? ? ? if?not?is_informational(resp.status) and?\\\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? not?is_server_error(resp.status):\n>? ? ? ? ? ? ? ? ? ? ? ? return?resp.status, resp.reason, resp.getheaders(), \\\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? resp.read()\n>? ? ? ? ? ? ? ? ? ? elif?resp.status ==?HTTP_INSUFFICIENT_STORAGE:\n>? ? ? ? ? ? ? ? ? ? ? ? self.error_limit(node, _(\'ERROR Insufficient Storage\'))\n>? ? ? ? ? ? except?(Exception, Timeout):\n>? ? ? ? ? ? ? ? self.exception_occurred(node, self.server_type,\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _(\'Trying to %(method)s %(path)s\') %\n>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? {\'method\': method, \'path\': path})\n>\n>---\n>\n>Thank you very much \n>\n>Pragya Jain \n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130928/750578b0/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130928/750578b0/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130928/750578b0/attachment-0001.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: pic29732.gif\nType: image/gif\nSize: 1255 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130928/750578b0/attachment-0002.gif>\n\n','<OFDD5CA053.5F641D50-ON48257BF3.00329F36-48257BF3.0032F025@cn.ibm.com>',NULL),('<1380373358.14875680.1353584050433.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-22 06:34:10',-18000,'2012-11-22 11:34:10',NULL,'[openstack-dev] Horizon project meeting time','\"Gabriel Hurley\" <Gabriel.Hurley at nebula.com> wrote:\n> It\'s been pointed out to me that this is bleeding into Friday evening\n> even for people on the Eastern US let alone Europe, so let me\n> propose two alternate options:\n> \n>     1. Tuesday at 23:00 UTC (quite late for European folks)\n>     2. Tuesday at 22:00 UTC in a second meeting room (this overlaps\n>     with Red Dwarf\'s meeting)\n> \n> Thoughts?\n\nIt\'d be great to have this meeting, thank you for organising it! As another European both options are kind of late so the earliest time would be better. Looking at the meetings calendar though, there are a couple of free earlier time slots that might also suit:\n\n   18:00 or 19:00 UTC on Mondays\n   19:00 UTC on Wednesdays\n   18:00 UTC on Thursdays\n\nMaybe one of these could work.\n\nCheers,\n\nJulie\n\n\n','<BD35DBE010D5B64589500D43F775F236338A8968@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1380467969-sup-9679@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-29 08:20:38',-25200,'2013-09-29 15:20:38',NULL,'[Openstack] Implementing DB as a Service','Excerpts from Ali Nazemian\'s message of 2013-09-29 08:02:00 -0700:\n> Hi,\n> I am looking for a way to run dbaas in our organization. I want to know\n> that is there any way to do that using open stack? If yes how that is\n> possible?\n> Regards.\n> \n\nCurrently the Trove project is in incubation to become fully integrated\nwith the OpenStack releases.\n\nhttp://docs.openstack.org/developer/trove/\n\n\n','<CAEYSxhUtD4c+KQ7O3B=qFLQZwdPZJ64R32tdG4DZOPnRLPWcoQ@mail.gmail.com>',NULL),('<1380494228503.12ef4457@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-29 15:37:10',-25200,'2013-09-29 22:37:10',NULL,'[Openstack] Implementing DB as a Service','Mi. B\n\n?\nSent from Mailbox for iPhone\n\nOn Sun, Sep 29, 2013 at 6:02 PM, Martinx - ?????\n<thiagocmartinsc at gmail.com> wrote:\n\n> A bit off-topic but, what about LDAP as a Service? Is there something\n> happening in this field?!\n> I think that would be great to be able to give for each tenant, the ability\n> to manage its own user / domains easily and integrated in someway with\n> OpenStack, later, it is possible to fully integrate with services like\n> Postfix, IMAP, Samba, etc...\n> Best,\n> Thiago\n> On 29 September 2013 16:29, Michael Basnight <mbasnight at gmail.com> wrote:\n>> On Sep 29, 2013, at 12:13 PM, Ali Nazemian wrote:\n>>\n>> > Is there any way to use Trove with Postgresql DB?\n>>\n>> Currently no, but there are some persons in the community who will be\n>> helping with this soon(ish). If this is something you are interested in\n>> helping to develop, we would <3 you!\n>>\n>> _______________________________________________\n>> Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130929/5b7bee59/attachment.html>\n\n','<CAJSM8J0nmGD90S6dh6Ccse0swA9qU54F+Qd5_WgqYdi8QRsLuw@mail.gmail.com>',NULL),('<1380552312.70592931@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 10:45:12',-14400,'2013-09-30 14:45:12',NULL,'[openstack-dev] [Glance] Proposed S3 multi-part upload\n	functionality','Ozawa, +1 to what Zhi said. Go ahead and submit a patch for review and we can consider it for Icehouse. Also try to attend the glance meeting if possible and we can discuss it there.\n\nHaving better uploads/downloads and specifically better error handling for uploads and downloads would definitely help conserve resources and improve time taken.\n\nIccha\n\n-----Original Message-----\nFrom: \"Zhi Yan Liu\" <lzy.dev at gmail.com>\nSent: Monday, September 30, 2013 1:29am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Glance] Proposed S3 multi-part upload functionality\n\nOn Mon, Sep 30, 2013 at 12:22 PM, Masashi Ozawa <mozawa at cloudian.com> wrote:\n> Hi everyone,\n>\n> We already created the blueprint for this feature below belore, if\n> Glance can use S3 MultiPart Upload REST API for the large objects in\n> future release as Amazon recommends it for the large object to be\n> uploaded, I believe that it\'s very useful for the customers and a good\n> thing for AWS and other S3 servers.\n>\n> https://blueprints.launchpad.net/glance/+spec/s3-multi-part-upload\n>\n> However it\'s not in the future release list so we actually implemeted\n> this feature based on Grizzly for an internal testing porpose and it\n> works so far.\n>\n> Made the implementation strategy below. So please review this so that\n> we can hopefully have this feature in the future openstack release.\n>\n> - Proposal S3 multi-part upload functionality\n> https://etherpad.openstack.org/s3-multi-part-upload\n>\n> thanks,\n> - Ozawa\n> --\n> Cloudian KK - http://cloudian.jp/\n> Masashi Ozawa <mozawa at cloudian.com>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nHello Masashi Ozawa,\n\nI consider it\'s a worth enhancement for s3 store driver, with a minor\nchange and a boto requirement update. You can just prepare your patch\nbase on the trunk code and commit it to Gerrit to allow team take a\nreview If you like.\nActually I\'m just thinking if a resume-broken-transfer (image\nuploading and downloading) is a useful thing for Glance as a common\nrequirement/enhancement. Any thoughts from you(s)?\n\nthanks,\nzhiyan\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAN__O6uamODeuQyE6x6dUGABUsSjO2uHY8jqGwe+G7Y+EjigEw@mail.gmail.com>',NULL),('<1380552635.905523993@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 10:50:35',-14400,'2013-09-30 14:50:35',NULL,'[openstack-dev] Waiting for someone to verify/look into a bug I\n	have opened for Glance Client tool','Maty,\n\nCan you link the launchpad bug? I have used image-list for glance v2 and it seemed to work fine for me. Maybe you could provide more details? \nAlso maybe we should continue this discussion on openstack mailing list than the dev list?\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"GROSZ, Maty (Maty)\" <maty.grosz at alcatel-lucent.com>\nSent: Monday, September 30, 2013 9:40am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Waiting for someone to verify/look into a bug I have opened for Glance Client tool\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi,\n\nI have opened a bug for Glance Client tool some weeks ago (at September 8th) - and I still didn\'t receive any comment on it. Is it right? Am I wrong? Anything...\nI will really appreciate if someone from the Glance client tool will have a look on the bug (see below).\n\nThanks,\n\nMaty.\n\nFrom launchpad:\n\nHi,\n\nWhen I am running Glance Client tool against glance service using the following command:\n\n> glance --debug --os-image-api-version 2 image-list\n\nI get the followng output:\n\ncurl -i -X GET -H \'X-Auth-Token: rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs\' -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' -k https://cb.alucloud.local/al-openstack/v2/schemas/image\n(9, \'Bad file descriptor\')\n\n--------------------------------------------------------------------------------------------------------------------------------------------\n\n*BUT* when I am running just the exact curl command you see in the debug log\n\n> curl -i -X GET -H \'X-Auth-Token: rO0ABXc4ACAyYzlkYTk4ZDQwZGVmNWU2MDE0MGZjZDI0OThiMzk3MQAGbWdyb3N6AAQzMDQ3AAABQP0JOAs\' -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' -k https://cb.alucloud.local/al-openstack/v2/schemas/image\n\nI get what am I expecting to get - the JSON schema:\n\nHTTP/1.1 200 OK\nDate: Sun, 08 Sep 2013 09:51:04 GMT\nContent-Type: application/json\nContent-Length: 4958\nConnection: close\n\n{\"type\":\"object\",\"properties\":{\"id\":{\"type\":\"string\"},\"name\":{\"type\":\"string\"},\"visibility\":{\"type\":\"string\",\"enum\":[\"public\",\"private\"]},\"file\":{\"type\":\"string\"},\"status\":{\"type\":\"string\"},\"minDisk\":{\"type\":\"integer\"},\"minRam\":{\"type\":\"integer\"},\"progress\":{\"type\":\"integer\"},\"userId\":{\"type\":\"string\"},\"metadata\":{\"type\":\"object\"},\"self\":{\"type\":\"string\"},\"size\":{\"type\":\"number\"},\"schema\":{\"type\":\"string\"},\"checksum\":{\"type\":\"string\"},\"customerId\":{\"type\":\"string\"},\"updated_at\":{\"type\":\"string\"},\"created_at\":{\"type\":\"string\"},\"container_format\":{\"type\":\"string\",\"enum\":[\"ovf\",\"bare\",\"aki\",\"ari\",\"ami\"]},\"disk_format\":{\"type\":\"string\",\"enum\":[\"raw\",\"vhd\",\"vmdk\",\"vdi\",\"iso\",\"qcow2\",\"aki\",\"ari\",\"ami\"]},\"name\":\"image\"}\n\n\n\n\n','<7A0D7FA093BE9640AB68E72FFCD595400DB980@FR712WXCHMBA09.zeu.alcatel-lucent.com\n >',NULL),('<1380553081-sup-2570@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 08:33:06',-25200,'2013-09-30 15:33:06',NULL,'[openstack-dev] [scheduler] [heat] Policy specifics','Excerpts from Zane Bitter\'s message of 2013-09-30 03:33:32 -0700:\n> On 27/09/13 17:58, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2013-09-27 06:58:40 -0700:\n> >> On 27/09/13 08:58, Mike Spreitzer wrote:\n> >>> I have begun to draft some specifics about the sorts of policies that\n> >>> might be added to infrastructure to inform a smart unified placement\n> >>> engine.  These are cast as an extension to Heat templates.  See\n> >>> https://wiki.openstack.org/wiki/Heat/PolicyExtension.  Comments solicited.\n> >>\n> >> Mike,\n> >> These are not the kinds of specifics that are of any help at all in\n> >> figuring out how (or, indeed, whether) to incorporate holistic\n> >> scheduling into OpenStack.\n> >\n> > I agree that the things in that page are a wet dream of logical deployment\n> > fun. However, I think one can target just a few of the basic ones,\n> > and see a real achievable case forming. I think I grasp Mike\'s ideas,\n> > so I\'ll respond to your concerns with what I think. Note that it is\n> > highly likely I\'ve gotten some of this wrong.\n> \n> Thanks for having a crack at this Clint. However, I think your example \n> is not apposite, because it doesn\'t actually require any holistic \n> scheduling. You can easily do anti-colocation of a bunch of servers just \n> using scheduler hints to the Nova API (stick one in each zone until you \n> run out of zones). This just requires Heat to expose the scheduler hints \n> portion of the Nova API. To my mind this stuff is so basic that it falls \n> squarely in the category of what you said in a previous thread:\n> \n\nThe implementation of the basic case is quite simple, but still useful\nto implement. The point is that by making it easier to write templates\nthat express this, the cloud provider makes it easier to load balance\nbetween AZ\'s based on real load, not round robin by the user. A healthy\nbalancing across AZ\'s serves provider and user better. Could we do this\nas a resource in Heat? Yes! But we could do all of it as a resource in\nHeat, and I\'m not entirely convinced that it is a good idea to take\nthat approach.  I don\'t want to get into the actual implementation,\nbut rather \"what are the road blocks to a minimally useful solution.\"\n\n> > There is\n> > definitely a need for Heat to be able to communicate to the API\'s any\n> > placement details that can be communicated. However, Heat should not\n> > actually be \"scheduling\" anything.\n> \n> But in any event, most of your answers appear to be predicated on this \n> very simple case, not on a holistic scheduler. I think you are vastly \n> underestimating the complexity of the problem.\n> \n\nThey\'re predicated on the simplicity of the discussion of that feature.\nReading through all of them, I see the same problem repeated over and\nover. \"Given input from the cloud provider and a logical expression of\nthe end goal from the user, produce a concrete plan\". What Mike started\nwith was \"That sounds like what Nova does, but there should be something\nthat coordinates it across all services.\"\n\n> What Mike is proposing is something more sophisticated, whereby you can \n> solve for the optimal scheduling of resources of different types across \n> different APIs. There may be a case for including this in Heat, but it \n> needs to be made, and IMO it needs to be made by answering these kinds \n> of questions at a similar level of detail to the symmetric dyadic \n> primitives wiki page.\n> \n> BTW there is one more question I should add:\n> \n> - Who will implement and maintain this service/feature, and the \n> associated changes to existing services?\n> \n\nI was thinking Mike was suggesting he\'d be interested in working on it.\nThen again, maybe Mike is just probing to see if OpenStack would be open\nto a commercial version of this. :)\n\nTalking about it here helps the rest of the OpenStack contributing\ncompanies think about it. Ultimately, until a user wants it, it should\nnot get done, as we have plenty of users who want plenty of things that\nare not yet done. But perhaps talking about the idea will convince users\nthis would solve their problems.\n\nThat said, I do think we should wrap up the discussion if we don\'t have\nany volunteers and/or enthusiastic users soon. :)\n\n> >> - What would a holistic scheduling service look like? A standalone\n> >> service? Part of heat-engine?\n> >\n> > I see it as a preprocessor of sorts for the current infrastructure engine.\n> > It would take the logical expression of the cluster and either turn\n> > it into actual deployment instructions or respond to the user that it\n> > cannot succeed. Ideally it would just extend the same Heat API.\n> >\n> >> - How will the scheduling service reserve slots for resources in advance\n> >> of them being created? How will those reservations be accounted for and\n> >> billed?\n> >> - In the event that slots are reserved but those reservations are not\n> >> taken up, what will happen?\n> >\n> > I dont\' see the word \"reserve\" in Mike\'s proposal, and I don\'t think this\n> > is necessary for the more basic models like Collocation and Anti-Collocation.\n> \n> Right, but we\'re not talking about only the basic models. Reservations \n> are very much needed according to my understanding of the proposal, \n> because the whole point is to co-ordinate across multiple services in a \n> way that is impossible to do atomically.\n> \n\nI\'m not sure why one would want to even _try_ to do something atomically\nin a massively distributed system across disparate systems. Also the\npoint is not to coordinate these things, but to produce a plan to\ncoordinate them.  If you look at it optimistically, you deal with the\nset-backs as the concrete plan goes into place. AZ full now? Fail the\nplan, recalculate, try again. Route shut down? Fail the plan, recalculate.\n\n> > Reservations would of course make the scheduling decisions more likely to\n> > succeed, but it isn\'t necessary if we do things optimistically. If the\n> > stack create or update fails, we can retry with better parameters.\n> >\n> >> - Once scheduled, how will resources be created in their proper slots as\n> >> part of a Heat template?\n> >\n> > In goes a Heat template (sorry for not using HOT.. still learning it. ;)\n> >\n> > Resources:\n> >    ServerTemplate:\n> >      Type: Some::Defined::ProviderType\n> >    HAThing1:\n> >      Type: OS::Heat::HACluster\n> >      Properties:\n> >        ClusterSize: 3\n> >        MaxPerAZ: 1\n> >        PlacementStrategy: anti-collocation\n> >        Resources: [ ServerTemplate ]\n> >\n> > And if we have at least 2 AZ\'s available, it feeds to the heat engine:\n> >\n> > Resources:\n> >    HAThing1-0:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          availability-zone: zone-A\n> >    HAThing1-1:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          availability-zone: zone-B\n> >    HAThing1-2:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          availability-zone: zone-A\n> >\n> > If not, holistic scheduler says back \"I don\'t have enough AZ\'s to\n> > satisfy MaxPerAZ\".\n> >\n> > Now, if Nova grows anti-affininty under the covers that it can manage\n> > directly, a later version can just spit out:\n> >\n> > Resources:\n> >    HAThing1-0:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          instance-group: 0\n> >          affinity-type: anti\n> >    HAThing1-1:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          instance-group: 1\n> >          affinity-type: anti\n> >    HAThing1-2:\n> >      Type: Some::Defined::ProviderType\n> >        Parameters:\n> >          instance-group: 0\n> >          affinity-type: anti\n> >\n> > The point is that the user cares about their servers not being in the\n> > same failure domain, not how that happens.\n> >\n> >> - What about when the user calls the APIs directly? (i.e. does their own\n> >> orchestration - either hand-rolled or using their own standalone Heat.)\n> >\n> > This has come up with autoscaling too. \"Undefined\" - that\'s not your stack.\n> \n> Well, when we have the new autoscaling service you\'ll still be able to \n> create an autoscaling group using your own standalone Heat engine. If \n> the provider has a scheduling service, why shouldn\'t you be able to use \n> that with your own standalone Heat engine too?\n> \n\nI misundertsood your question originally. Agreed that this is an interesting\nuse case and one that would be good to support.\n\n> >> - How and from where will the scheduling service obtain the utilisation\n> >> data needed to perform the scheduling? What mechanism will segregate\n> >> this information from the end user?\n> >\n> > I do think this is a big missing piece. Right now it is spread out\n> > all over the place. Keystone at least has regions, so that could be\n> > incorporated now. I briefly dug through the other API\'s and don\'t see\n> > a way to enumerate AZ\'s or cells. Perhaps it is hiding in extensions?\n> >\n> > I don\'t think this must be segregated from end users. An API for \"show\n> > me the placement decisions I can make\" seems useful for anybody trying\n> > to automate deployments. Anyway, probably best to keep it decentralized\n> > and just make it so that each service can respond with lists of arguments\n> > to their API that are likely to succeed.\n> \n> I think you\'re thinking about the very simplest case still (e.g. list of \n> AZs - we have that already). To implement a completely general \n> scheduling service you\'re going to need data down to the level of e.g. \n> which machines are overcommitted and by how much. Good luck convincing \n> public cloud providers to make this available through a user-facing API. \n> The unintended consequences only _begin_ with pathological user \n> behaviour, and end somewhere in the realm of lawsuits, financial \n> reporting and competitive analysis.\n> \n\nI don\'t expect the public cloud providers to expose \"which machines are\novercommitted\".  I did gloss over those two things as one in my response,\nand I have to agree that there are things you want to expose to users,\nand things you don\'t. I believe that we have a RBAC system in OpenStack\nto satisfy this requirement.\n\nUsers are mining this data out of Amazon right now anyway btw. Have seen\nthe graphite installations with \"instances are doing X IOPS today in Y\nregion\". But I digress, mined data is not the same as fetched data.\n\nAnyway, the API for end users is just \"show me the networks I can attach\nto\" and \"show me the volume services\", most/all of which we probably\nhave today. The scheduler would in fact need access to the metrics to\ntie those to.\n\n> As Mike pointed out downthread, the scheduler primarily serves the cloud \n> provider\'s interest. That means the raw input data is at best (when \n> compared to the actual scheduler output) a record of exactly how much \n> the provider does or does not care about users, and at worst a basis for \n> users building their own scheduler that serves only their own interest.\n> \n> So the scheduler service needs some privileged access to the internals \n> of each service. Heat is unprivileged (it just calls public APIs - you \n> can run your own locally). How to resolve that mismatch is a key \n> question if scheduling is to become part of Heat.\n> \n\nYou are painting cloud providers as uncaring slum lords. Of course there\nwill be slum lords in any ecosystem, but there will also be high quality\nservice providers and private cloud operators with high expectations that\ncan use this type of feature as something to benefit only the users at a\nhigh cost.\n\n\n','<5249537C.9010103@redhat.com>',NULL),('<1380591924-sup-9126@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 18:52:43',-25200,'2013-10-01 01:52:43',NULL,'[openstack-dev] [Spam] Heat stack-create fails in TripleO\n	devtest environment','Excerpts from hideyasu hayashi\'s message of 2013-09-30 18:29:24 -0700:\n> Dear List,\n> \n> \n> \n>  Hi, I set up TripleO devtest environment on VMware(Ubuntu 12.04.3 LTS)\n> according to devtest described in\n> http://docs.openstack.org/developer/tripleo-incubator/devtest.html\n> \n> \n> \n>  There are 50 steps. I set up following the procedures, but it fails.\n> \n>  Does anyone know how to debug?\n> \n>  If anyone was successful, tell me your enviroment.(OS..)\n> \n> \n> \n>  (TripleO devtest URL)\n> \n>  http://docs.openstack.org/developer/tripleo-incubator/devtest.html\n> \n> \n> \n>   (Failed detail)\n> \n> \n> \n>  We are failed in step 27th, that create UnderCloud Stack with Heat.\n> \n> \n> \n>  --27. Deploy an undercloud: -----------------\n> \n>   heat stack-create -f\n> $TRIPLEO_ROOT/tripleo-heat-templates/undercloud-vm.yaml \\\n> \n>     -P\n> \"PowerUserName=$(whoami);AdminToken=${UNDERCLOUD_ADMIN_TOKEN};AdminPassword=${UNDERCLOUD_ADMIN_PASSWORD};GlancePassword=${UNDERCLOUD_GLANCE_PASSWORD};HeatPassword=${UNDERCLOUD_HEAT_PASSWORD};NeutronPassword=${UNDERCLOUD_NEUTRON_PASSWORD};NovaPassword=${UNDERCLOUD_NOVA_PASSWORD};BaremetalArch=${NODE_ARCH}\"\n> \\\n> \n>     undercloud\n> \n>  ----------------------------------------\n> \n> \n> \n>  I had run the command \"heat stack-create -f $TRIPLEO_ROOT/tripleo..\",but\n>  stack_staus result an  failed.\n> \n> \n> \n>   ---- heat creat result ------------------------\n> \n>   root at ubuntu:~/tripleo# heat stack-list\n> \n> \n> +--------------------------------------+-------------+---------------+----------------------+\n> \n>   | id                                   | stack_name  | stack_status  |\n> creation_time        |\n> \n> \n> +--------------------------------------+-------------+---------------+----------------------+\n> \n>   | c28d0e20-9270-4716-9b0c-ce7b80c96dab | undercloud  | CREATE_FAILED |\n> 2013-09-25T09:24:37Z |\n> \n> \n> +--------------------------------------+-------------+---------------+----------------------+\n> \n\nHello Hideyasu, thanks for trying out TripleO!\n\nThe usual cause of a failure at this point is failing SSH from seed VM\nto host.\n\nCommands to debug:\n\n## show the list of events and the specific resource that failed.\nheat event-list undercloud\n\n## show the error message that caused the failure\nheat event-show undercloud resource_name event_id\n\nNow, most likely, you have an error on the creation of the \"notcompute\"\nresource. If so, you will have a server in ERROR state here:\n\n## list my servers\nnova list\n\nIf so, try\n\n# Show details about the server\nnova show server_id\n\nThis may or may not be helpful, as many problems boil down to \"I couldn\'t\nfind a host to deploy to\".\n\nYou can look on the seed VM for clues in\n/var/log/upstart/nova-compute.log.\n\nIt takes 60 seconds to see the registered baremetal nodes in the nova\nscheduler, so just deleting the stack and trying again can work. This is\nlikely since you are running a nested VM, so timeouts are common because\neverything takes a _lot_ longer on nested vms. I highly recommend getting\nreal hardware to use if you can.\n\n## delete stack\nheat stack-delete undercloud\n\nI hope all of this helps.\n\n\n','<CAJgp57byLHuG3fAq5Ynms1H=7bfdXLM1S2317fzL6EeduSsSow@mail.gmail.com>',NULL),('<1380607456-sup-7974@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 23:31:44',-25200,'2013-10-01 06:31:44',NULL,'[openstack-dev] [heat] [scheduler] Bringing things together for\n	Icehouse (now featuring software orchestration)','Excerpts from Georgy Okrokvertskhov\'s message of 2013-09-30 11:44:26 -0700:\n> Hi,\n> \n> I am working on the OpenStack project Murano which actually had to solve\n> the same problem with software level orchestration. Right now Murano has a\n> DSL language which allows you to define a workflow for a complex service\n> deployment.\n> Murano uses Heat for infrastructure managements and actually there is a\n> part of DSL language which allows you to generate Heat template for\n> deployment.\n> \n> This is a native to OpenStack project written in Python following all\n> OpenStack community rules. Before creating Murano we evaluated different\n> software orchestrators like SaltStack, Chef and Puppet+mcollective. All of\n> them have capabilities for software management but all of them are not\n> native to OpenStack. I think it will be quite reasonable to have something\n> under full control of OpenStack community then use something which is not\n> native (even in programming language) to OpenStack.\n> \n> Here is a link to the project overview:\n> https://wiki.openstack.org/wiki/Murano/ProjectOverview\n> \n> Right now Murano is concentrated on Windows services management but we also\n> working on Linux Agent to allow Linux software configuration too.\n> \n\nHi!\n\nWe\'ve written some very basic tools to do server configuration for the\nOpenStack on OpenStack (TripleO) Deployment program. Hopefully we can\navert you having to do any duplicate work and join forces.\n\nNote that configuring software and servers is not one job. The tools we\nhave right now:\n\nos-collect-config - agent to collect data from config sources and trigger\ncommands on changes. [1]\n\nos-refresh-config - run scripts to manage state during config changes\n(run-parts but more structured) [2]\n\nos-apply-config - write config files [3]\n\n[1] http://pypi.python.org/pypi/os-collect-config\n[2] http://pypi.python.org/pypi/os-refresh-config\n[3] http://pypi.python.org/pypi/os-apply-config\n\nWe do not have a tool to do run-time software installation, because we\nare working on an image based deployment method (thus building images\nwith diskimage-builder).  IMO, there are so many good tools already\nwritten that get this job done, doing one just for the sake of it being\nOpenStack native is a low priority.\n\nHowever, a minimal thing is needed for Heat users so they can use it to\ninstall those better tools for ongoing run-time configuration. cfn-init\nis actually pretty good. Its only crime other than being born of Amazon\nis that it also does a few other jobs, namely file writing and service\nmanagement.\n\nAnyway, before you run off and write an agent, I hope you will take a look\nat os-collect-config and considering using it. For the command to run, I\nrecommend os-refresh-config as you can have it run a progression of config\ntools. For what to run in the configuration step of os-refresh-config,\ncfn-init would work, however there is a blueprint for a native interface\nthat might be a bit different here:\n\nhttps://blueprints.launchpad.net/heat/+spec/native-tools-bootstrap-config\n\n> When do you have a meeting for HOT software configuration discussion? I\n> think we can add value here for Heat as we have already required components\n> for software orchestration with full integration with OpenStack and\n> Keystone in particular.\n\nHeat meets at 2000 UTC every Wednesday.\n\nTripleO meets at 2000 UTC every Tuesday.\n\nHope to see you there!\n\n\n','<CAG_6_omt+89mgifEwZvhBRaRqiKUs+78SBVAk8jULNBnu0J0tg@mail.gmail.com>',NULL),('<1380609419-sup-5770@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-30 23:38:53',-25200,'2013-10-01 06:38:53',NULL,'[openstack-dev] [scheduler] [heat] Policy specifics (for\n	holistic infrastructure scheduling)','Mike, this has been really fun, but it is starting to feel like a\nrabbit hole.\n\nThe case for having one feels legitimate. However, at this point, I think\nsomeone will need to actually build it, or the idea is just a pipe dream.\n\nExcerpts from Mike Spreitzer\'s message of 2013-09-30 19:21:22 -0700:\n> OK, let\'s take the holistic infrastructure scheduling out of Heat.  It \n> really belongs at a lower level anyway.  Think of it as something you slap \n> on top of Nova, Cinder, Neutron, etc. and everything that is going to use \n> them goes first through the holistic scheduler, to give it a chance to \n> make some joint decisions.  Zane has been worried about conflicting \n> decisions being made, but if everything goes through the holistic \n> infrastructure scheduling service then there does not need to be an issue \n> with other parallel decision-making services (more on this below).  For a \n> public cloud, think of this holistic infrastructure scheduling as part of \n> the service that the cloud offers to the public; the public says what it \n> wants, and the various levels of schedulers work on delivering it; the \n> internals are not exposed to the public.  For example, a cloud user may \n> say \"spread my cluster across at least two racks, not too unevenly\"; you \n> do not want that public cloud customer to be in the business of knowing \n> how many racks are in the cloud, knowing how much each one is currently \n> being used, and picking which rack will contain which members of his \n> cluster.  For a private cloud, the holistic infrastructure scheduler \n> should have the same humility as the lower schedulers: offer enough \n> visibility and control to the clients that they can make decisions if they \n> want to (thus, nobody needs to \"go around\" the holistic infrastructure \n> scheduler if they already know what they want).\n> \n> You do not want to ask the holistic infrastructure scheduler to schedule \n> resources one by one; you want to ask it to allocate a whole \n> pattern/template/topology.  There is thus no need for infrastructure \n> orchestration prior to holistic infrastructure scheduling.\n> \n> Once the holistic infrastructure scheduler has done its job, there is a \n> need for infrastructure orchestration.  What should we use for that?\n> \n> OK, more on the business of conflicting decisions.  For the sake of \n> scalability and modularity, the holistic infrastructure scheduler should \n> delegate as much decision-making as it can to more specific services.  The \n> job of the holistic infrastructure scheduler is to make joint decisions \n> when there are strong interactions between services.  You can fudge this \n> either way (have the holistic infrastructure scheduler make more or less \n> decisions than ideal), but if you want the best then I think the principle \n> I stated is what would guide.  So what if a delegated decision conflicts \n> with a holistic decision?  Don\'t do that.  Divide the decision-making \n> responsibilities into distinct domains, for example with the holistic \n> scheduler making relatively big-picture decisions and individual resource \n> services filling in the details.\n> \n> That said, there can still be nasty surprises from lower layers.  Even if \n> the design has carefully partitioned decision-making responsibilities, \n> irregular things can still happen (e.g., authorized people can do \n> something unexpected).  Even if nothing intentionally does anything \n> irregular, there remains the possibility of bugs.  The holistic \n> infrastructure scheduler should be prepared for nasty surprises, and \n> getting information that is as authoritative as possible to begin with \n> (promptness doesn\'t hurt either).\n> \n> Then there is the question of the scalability of the holistic \n> infrastructure scheduler.  One hard kernel of that is solving the \n> optimization problem.  Nobody should expect the scheduler to find the \n> truly optimal solution; this is an NP-hard problem.  However, there exist \n> optimization algorithms that produce pretty good approximations in modest \n> amounts of time.  Additionally: if the patterns are small relative to the \n> size of the whole zone being scheduled then it should be possible to do \n> concurrent decision-making with optimistic concurrency control (as Clint \n> has mentioned).\n> \n> You would not want one holistic infrastructure scheduler for a whole \n> geographically distributed cloud.  You could use a hierarchical \n> arrangement, with one top-level decision-maker dividing a pattern between \n> availability zones (by which I mean the sort of large independent domains \n> that are typically known by that term) and then a subsidiary scheduler for \n> each availability zone.\n> \n> Regards,\n> Mike\n\n\n','<OFBB043657.A82003F7-ON85257BF7.00067AEA-85257BF7.000CF0F9@us.ibm.com>',NULL),('<1380615881.5982.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-01 09:24:41',3600,'2013-10-01 08:24:41',NULL,'[Openstack] No internet connection to the VMs','Giulio,\n\nthe packets from the instance are leaving the devstack VM with the floating IP as the source address. Even if they do get out to the Internet, upstream routers would not know what to do with the return packets which have the floating IP as the destination address.\n\nTry this on the devstack VM:\n\nsudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE\n\nThen the packets will be SNATed to the devstack VM IP before they leave.\n\nRe, Darragh.\n\n> Giulio Vito de Musso giulio.vito.demusso at gmail.com\n> Mon Sep 30 21:31:03 UTC 2013\n> \n>???? Previous message: [Openstack] OVS bandwidth limiting\n>???? Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]\n> \n> Hi to all,\n> \n> I\'m facing a problem with Devstack+Neutron+LBaaS.\n> I installed Devstack+Neutron+LBaaS? onto a Ubuntu 12.04 VM adding the\n> following lines to Devstack\'s localrc and then running stack.sh\n> \n> \n> > disable_service n-net\n> > enable_service q-svc\n> > enable_service q-agt\n> > enable_service q-dhcp\n> > enable_service q-l3\n> > enable_service q-meta\n> > enable_service neutron\n> > enable_service tempest\n> > enable_service q-lbaas\n> \n> \n> At the end of the installation I create a network with a \"mySubnet\" subnet\n> (with a 192.168.0.0/24 IP range and the DNS IPs set properly), a\n> \"myKeypair\" keypair, a \"myRouter\" router and link the router to the\n> \"public\" (as external gateway) and \"mySubnet\" networks.\n> Then I launch a Ubuntu Cloud 12.04 VM in Horizon associating the mySubnet\n> network, the myKeypair keypair and a brand new floating IP.\n> \n> I can ping and SSH the VM from the Devstack machine and the VM can ping the\n> Devstack machine, the br-ex and the myRouter; the problem is that the VM\n> cannot access the Internet.\n> In particular, it seems that the VM cannot ping the DNS server (infact it\n> cannot resolve any Internet hostname) even though the br-ex bridge is up\n> running.\n> \n> What can be the problem? I\'m stuck at this point for three weeks and cannot\n> go forward in my LBaaS analysis.\n> \n> Thanks\n> Giulio\n\n\n\n',NULL,NULL),('<1380639759.74883.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-01 16:02:39',3600,'2013-10-01 15:02:39',NULL,'[Openstack-operators] [Grizzly] Multiple l3-agent hosts,\n	single network.','Sam,\n\n\nbeing able to reach http but not https sites sounds like the mtu issue we have seen before. As a quick test try reducing the mtu on the instance:\n\n$ sudo ip link set mtu 1400 dev eth0\n\nand see if the wget to the https site works.\n\n\nRe, Darragh.\n\n\n>Hello,\n>\n>\n>I have two external network hosts (test1 and test2) both running the l3 agent on the same network (XXX.YYY.0.0/24). ?I am using OVS/namespace/gre networking. ?When a neutron/quantum router is set to use the l3-agent on test1 everything works fine. ?If I set the same router to use the l3-agent on test2 I experience some odd problems: ?From within a VM using the router on test2 I can wget files from http sites but not from https sites. ?I have noticed that the iptables (not within any namespace) are VERY different for the two servers:\n>\n>\n>Working l3-agent (test1) iptables:?http://paste.openstack.org/show/47695/\n>Non-working l3-agent (test2) iptables:?http://paste.openstack.org/show/47696/\n>\n>\n>Notice that the iptables for test1 contain chains for the security groups such as?quantum-openvswi-i435b8f52-6. ?I do not see anything like this on test2.\n>\n>\n>\n>\n>Does anyone have any idea what might be causing this issue?\n>\n>\n>Thanks!\n>Sam\n>\n>\n>\n>\n>_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n>\n\n\n','<mailman.8.1380628802.25113.openstack-operators@lists.openstack.org>',NULL),('<1380661545.97248.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-01 22:05:45',3600,'2013-10-01 21:05:45',NULL,'[Openstack-operators] [Grizzly] Multiple l3-agent hosts,\n	single network.','Sam,\n\nI wrote a blog post about this a while back http://techbackground.blogspot.ie/2013/06/path-mtu-discovery-and-gre.html\n\nBasically the GRE tunnel between the node with the instance and the node with the quantum router is reducing the overall path MTU, and the ICMP error sent back to the sender requesting the packet size to be reduced is being blocked or ignored.\n\nJust today I have been looking at the Linux 3.5 kernel and OVS 1.11.0, and the behaviour seems to have changed - now there is IP fragementation happening between the nodes instead.\n\nRe, Darragh.\n\n\n\n\n>________________________________\n> From: Samuel Winchenbach <swinchen at gmail.com>\n>To: Darragh O\'Reilly <dara2002-openstack at yahoo.com> \n>Cc: \"openstack-operators at lists.openstack.org\" <openstack-operators at lists.openstack.org> \n>Sent: Tuesday, 1 October 2013, 21:02\n>Subject: Re: [Openstack-operators] [Grizzly] Multiple l3-agent hosts, single network.\n> \n>\n>\n>That worked great. ? What is going on there? ?\n>\n>\n>If I run the VM on the same physical machine as the L3 agent I do not need to set the MTU.\n>\n>\n>Interesting.\n>\n>\n>Sam\n>\n>\n>\n>On Tue, Oct 1, 2013 at 11:02 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>Sam,\n>>\n>>\n>>being able to reach http but not https sites sounds like the mtu issue we have seen before. As a quick test try reducing the mtu on the instance:\n>>\n>>$ sudo ip link set mtu 1400 dev eth0\n>>\n>>and see if the wget to the https site works.\n>>\n>>\n>>Re, Darragh.\n>>\n>>\n>>\n>>>Hello,\n>>>\n>>>\n>>>I have two external network hosts (test1 and test2) both running the l3 agent on the same network (XXX.YYY.0.0/24). ?I am using OVS/namespace/gre networking. ?When a neutron/quantum router is set to use the l3-agent on test1 everything works fine. ?If I set the same router to use the l3-agent on test2 I experience some odd problems: ?From within a VM using the router on test2 I can wget files from http sites but not from https sites. ?I have noticed that the iptables (not within any namespace) are VERY different for the two servers:\n>>>\n>>>\n>>>Working l3-agent (test1) iptables:?http://paste.openstack.org/show/47695/\n>>>Non-working l3-agent (test2) iptables:?http://paste.openstack.org/show/47696/\n>>>\n>>>\n>>>Notice that the iptables for test1 contain chains for the security groups such as?quantum-openvswi-i435b8f52-6. ?I do not see anything like this on test2.\n>>>\n>>>\n>>>\n>>>\n>>>Does anyone have any idea what might be causing this issue?\n>>>\n>>>\n>>>Thanks!\n>>>Sam\n>>>\n>>>\n>>>\n>>>\n>>>_______________________________________________\n>>>OpenStack-operators mailing list\n>>>OpenStack-operators at lists.openstack.org\n>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>\n>>>\n>>>\n>>\n>>_______________________________________________\n>>OpenStack-operators mailing list\n>>OpenStack-operators at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131001/19c17d8c/attachment.html>\n\n','<CAK9s_Nzf1ya54rUpXZEnsUPTA3JdY-6HHLAJtkacBg8GApPLbg@mail.gmail.com>',NULL),('<1380707640.27187.203.camel@sorcha>','http://lists.openstack.org/pipermail/transparency',NULL,'2013-10-02 10:54:00',3600,'2013-10-02 09:54:00',NULL,'[Transparency] Transparency Committee - Quick meeting before\n Thursday?','On Tue, 2013-10-01 at 12:29 -0500, Lauren Sell wrote:\n> Hi everyone --\n> \n> Would it make sense to get together briefly so we have a proper update\n> for the board meeting?\n> \n> I would love to get the transparency policy wrapped up and circulated\n> to the Board, so we can approve it during this week\'s meeting (not\n> sure if it requires a vote), although there are still a few\n> dependencies with the mailing list/doc store and ombudsman plans. We\n> could always publish a v1 and update it once those items are complete.\n> \n> You can see the latest version of the policy here. I spent some time\n> responding to and resolving comments that were made when we originally\n> sent it out to the mailing list for feedback, but there are still a\n> few remaining questions we can discuss:\n> https://docs.google.com/a/openstack.org/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit\n\nNice work Lauren\n\nI left some comments inline, but I\'m happy with the current state\n\nThanks,\nMark.\n\n\n\n','<7627FC23-6C3D-4F27-8B7B-F6D447692B73@openstack.org>',NULL),('<1380708014.27187.209.camel@sorcha>','http://lists.openstack.org/pipermail/transparency',NULL,'2013-10-02 11:00:14',3600,'2013-10-02 10:00:14',NULL,'[Transparency] Transparency Committee - Quick meeting before\n Thursday?','On Wed, 2013-10-02 at 10:54 +0100, Mark McLoughlin wrote:\n> On Tue, 2013-10-01 at 12:29 -0500, Lauren Sell wrote:\n> > Hi everyone --\n> > \n> > Would it make sense to get together briefly so we have a proper update\n> > for the board meeting?\n> > \n> > I would love to get the transparency policy wrapped up and circulated\n> > to the Board, so we can approve it during this week\'s meeting (not\n> > sure if it requires a vote), although there are still a few\n> > dependencies with the mailing list/doc store and ombudsman plans. We\n> > could always publish a v1 and update it once those items are complete.\n> > \n> > You can see the latest version of the policy here. I spent some time\n> > responding to and resolving comments that were made when we originally\n> > sent it out to the mailing list for feedback, but there are still a\n> > few remaining questions we can discuss:\n> > https://docs.google.com/a/openstack.org/document/d/1sGBtza-mjRXcDzFBSS9aUrYlAtu1se-eerHZN16DPyU/edit\n> \n> Nice work Lauren\n> \n> I left some comments inline, but I\'m happy with the current state\n\nActually - a possible late addition\n\nThere\'s been some lengthy debate over email amongst the election\ncommittee members over the past few days and I\'m sad that there was such\na limited audience for the discussion.\n\nPerhaps a policy that, by default, new committees should conduct their\nbusiness using a public mailing list - either co-opting an existing one,\nor creating a new one.\n\ni.e. just like the transparency committee has done? :)\n\nMark.\n\n\n\n','<1380707640.27187.203.camel@sorcha>',NULL),('<1380738508.57.1383459072939.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:11:12',0,'2013-11-03 06:11:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #40','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/40/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/registry/client.py\",> line 89, in do_request\n    action, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4ce8990>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4ce8990>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x40e1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x40e1790>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-7204a34f-a212-49af-93f6-698889824efa\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:10:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:10:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:10:47+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'47\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:10:47-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'47\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:10:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5617810>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x18fad50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 69.63 secs:\n    15.61    TestGlanceControl.test_bouncing\n    14.09    TestScrubber.test_delayed_delete\n    13.82    TestGlanceControl.test_reload\n    13.56    TestGlanceControl.test_respawn\n    12.55    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 525.384s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-40\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.3DRKYzeLrT\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/40/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise5/40\n[SCP] Copying console log.\n\n\n','<455006930.28.1383199742120.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1380774313.53317210@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 00:25:13',-14400,'2013-10-03 04:25:13',NULL,'[openstack-dev] Nominating Zhi Yan Liu for glance-core','Hey,\n\nI would like to nominate Zhi Yan Liu(lzydev) for glance core. I think Zhi has been an active reviewer/contributor to the glance community [1] and has always been on top of reviews.\n\nThanks for the good work Zhi!\n\nIccha\n\n[1] http://russellbryant.net/openstack-stats/glance-reviewers-30.txt\n\n\n\n',NULL,NULL),('<1380774480.170914829@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 00:28:00',-14400,'2013-10-03 04:28:00',NULL,'[openstack-dev] Nominating Fei Long Wang for glance core','Hey,\n\nI would like to nominate Fei Long Wang(flwang) for glance core. I think Fei has been an active reviewer/contributor to the glance community [1] and has always been on top of reviews.\n\nThanks for the good work Fei!\n\nIccha\n\n[1] http://russellbryant.net/openstack-stats/glance-reviewers-30.txt\n\n\n\n',NULL,NULL),('<1380812872-sup-4457@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 08:10:43',-25200,'2013-10-03 15:10:43',NULL,'[openstack-dev] [Heat] question about stack updates,\n	instance groups and wait conditions','Excerpts from Simon Pasquier\'s message of 2013-10-03 07:12:51 -0700:\n> Hi Clint,\n> \n> Thanks for the reply! I\'ll update the bug you raised with more \n> information. In the meantime, I agree with you that cfn-hup is enough \n> for now.\n> \n> BTW, is there any bug or missing feature that would prevent me from \n> replacing cfn-hup by os-collect-config?\n> \n\nThe only problem might be that currently os-collect-config can only watch\none path, but it was designed to watch multiple paths. That is just a bug,\nand hopefully will get fixed soon.\n\nAlso cfn-init will not know how to read the config info that\nos-collect-config produces, so if you are using cfn-init it is still\nbetter to use cfn-hup.\n\n\n','<524D7B63.7010901@bull.net>',NULL),('<1380817183-sup-6774@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-04 22:20:51',-25200,'2013-10-05 05:20:51',NULL,'[openstack-dev] [savanna] neutron and private networks','Excerpts from Fox, Kevin M\'s message of 2013-10-03 08:59:25 -0700:\n> I\'ve been trying to use heat more and ran into similar issues with its metadata server bits not working on private namespaces too. Long term it may need to be made netns aware as well.\n> \n\nHi Kevin, could you please file a bug in Heat with any details you can\nshare about your experience. Thanks!\n\nhttps://launchpad.net/heat/+filebug\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C63E2947B@EMAIL05.pnl.gov>',NULL),('<1380824524.946329801@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 14:22:04',-14400,'2013-10-03 18:22:04',NULL,'[openstack-dev] [Glance] tasks/async workers sync up.','\nHi folks,\n \nI was hoping to see if you all were free sometime tomorrow (Friday) Oct 4th at 14:00 UTC to do a sync up on the patch we\'ve had going on for async workers (full PS here:- [https://review.openstack.org/#/c/46117/] https://review.openstack.org/#/c/46117/ ).\n \nVenkatesh and I are working full time on this and trying to address some of the comments we\'ve received. Zhi has suggested some important changes and, if we can have a general meeting/consensus about the direction this impl should go it would make things easy going forward. The design currently does not have dynamic loading of the modules; besides that if there were major concerns, we would really appreciate some feedback from community on them as well.\n \nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131003/1bb1c654/attachment.html>\n\n',NULL,NULL),('<1380824929.54841387@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 14:28:49',-14400,'2013-10-03 18:28:49',NULL,'[openstack-dev] Nominating Zhi Yan Liu for glance-core','\n+1\n \n-Nikhil\n\n\n-----Original Message-----\nFrom: \"Iccha Sethi\" <iccha.sethi at rackspace.com>\nSent: Thursday, October 3, 2013 12:25am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Nominating Zhi Yan Liu for glance-core\n\n\n\nHey,\n\nI would like to nominate Zhi Yan Liu(lzydev) for glance core. I think Zhi has been an active reviewer/contributor to the glance community [1] and has always been on top of reviews.\n\nThanks for the good work Zhi!\n\nIccha\n\n[1] http://russellbryant.net/openstack-stats/glance-reviewers-30.txt\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131003/7fbed70d/attachment.html>\n\n','<1380774313.53317210@apps.rackspace.com>',NULL),('<1380824942.056421425@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 14:29:02',-14400,'2013-10-03 18:29:02',NULL,'[openstack-dev] Nominating Fei Long Wang for glance core','\n+1\n \n-Nikhil\n\n\n-----Original Message-----\nFrom: \"Iccha Sethi\" <iccha.sethi at rackspace.com>\nSent: Thursday, October 3, 2013 12:28am\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] Nominating Fei Long Wang for glance core\n\n\n\nHey,\n\nI would like to nominate Fei Long Wang(flwang) for glance core. I think Fei has been an active reviewer/contributor to the glance community [1] and has always been on top of reviews.\n\nThanks for the good work Fei!\n\nIccha\n\n[1] http://russellbryant.net/openstack-stats/glance-reviewers-30.txt\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131003/63f0cece/attachment.html>\n\n','<1380774480.170914829@apps.rackspace.com>',NULL),('<1380896864.22066.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-04 15:27:44',3600,'2013-10-04 14:27:44',NULL,'[Openstack] how to tell dhcp-agent to advertice certain routes?','Hi Ilkka,\n\n\nif\n I\'m understanding things correctly, the goal is to have a provider \nnetwork with a non-Quantum external router and metadata at the same \ntime. If so, you can do this by using the metadata proxy from the DHCP \nagent, and there is no need for a Quantum router. There is a trick to \nsetting up the external subnet - you must disable the gateway_ip field \nand push out the default route as a static route instead. This is \nbecause the DHCP agent will not push out the static route for \n169.254.169.254/32 when the subnet\'s gateway_ip is set. See https://github.com/openstack/neutron/blob/2013.1.1/quantum/agent/linux/dhcp.py#L355\n\nSo the command would like this if the router is at 10.0.0.254:\n\nquantum subnet-create net1 10.0.0.0/24 --name sub1 \\\n--no-gateway \\\n--host-route destination=0.0.0.0/0,nexthop=10.0.0.254 \\\n--allocation-pool start=10.0.0.1,end=10.0.0.253\n\nNow\n with enable_isolated_metadata=True, the DHCP agent will also push out a\n static route for 169.254.169.254/32 with the DHCP IP as the nexthop.\n\nIn Havana this has changed a little - the default route will be pushed out as the gateway route - see https://github.com/openstack/neutron/commit/86088a2241e6caaa31974b38f8024795c3d032f0 \n\nRe, Darragh.\n\n\n> Date: Fri, 04 Oct 2013 09:07:39 +0300\n> From: Ilkka Tengvall <ilkka.tengvall at cybercom.com>\n> To: Jonathan Proulx <jon at jonproulx.com>\n> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain\n>???? routes?\n> Message-ID: <524E5B2B.7040108 at cybercom.com>\n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed\n> \n> On 01.10.2013 17:55, Jonathan Proulx wrote:\n> > On Tue, Oct 01, 2013 at 12:01:24PM +0300, Ilkka Tengvall wrote:\n> > I\'m not using the quantum metadata service.? I can get away with this\n> > becasue I have relatively few networks and are all more or less in the\n> > same administrative domain.\n> >\n> > I\'m running the nova metadata service on the controler node and have\n> > interfaces on the contorller on all the networks I want metadata on.\n> \n> This would work only if you don\'t use namespaces. Once you enable\n> namespaces, you have overlapping ip ranges (possibly), and then you need\n> quantum-metadata-proxy. That beast takes care of the overlapping ip\'s\n> before the stuff gets to nova-metadata.\n> \n> So without namespaces you should be safe. See here if you want further\n> know about the issue:\n> \n> http://techbackground.blogspot.fi/2013/06/metadata-via-quantum-router.html\n> http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html\n> \n> Anyway as a feedback to my own original question, we solved (fingers\n> crossed :)) the issue by:\n> \n> 1. adding a port with given ip into network,\n>???? which is different than the physical gateway\n> 2. create a router with given port (this will\n>???? create NAT rules for quantum metadata)\n> 3. Tell the subnet to have default gw via the physical router\n> 4. Tell the subnet to advertice route to 169.254.169.254 via the\n>???? quantum router port made at step 1.\n> \n> The issue found here is that grizzly quantumclient is not able to create\n> quantum router with given port (backport, anyone ;)), you need to do it\n> via API (e.g. curl), or use the neutronclient from havana to do it,\n> where it\'s fixed.\n> \n> I hope this helps someone else running into the same situation with\n> provider networks, external router and metadata, it sure would\'ve helped\n> us, along with the info that vlans on bond are broken in Red Hat (any\n> kernel < 3.3):\n> \n> http://openstack.redhat.com/forum/discussion/598/dhcp-responces-get-lost-with-ovs-provider-vlans#Item_8\n> \n> BR,\n> \n> Ilkka\n> EOF\n> Date: Fri, 04 Oct 2013 09:07:39 +0300\n> From: Ilkka Tengvall <ilkka.tengvall at cybercom.com>\n> To: Jonathan Proulx <jon at jonproulx.com>\n> Cc: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] how to tell dhcp-agent to advertice certain\n>???? routes?\n> Message-ID: <524E5B2B.7040108 at cybercom.com>\n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed\n> \n> On 01.10.2013 17:55, Jonathan Proulx wrote:\n> > On Tue, Oct 01, 2013 at 12:01:24PM +0300, Ilkka Tengvall wrote:\n> > I\'m not using the quantum metadata service.? I can get away with this\n> > becasue I have relatively few networks and are all more or less in the\n> > same administrative domain.\n> >\n> > I\'m running the nova metadata service on the controler node and have\n> > interfaces on the contorller on all the networks I want metadata on.\n> \n> This would work only if you don\'t use namespaces. Once you enable\n> namespaces, you have overlapping ip ranges (possibly), and then you need\n> quantum-metadata-proxy. That beast takes care of the overlapping ip\'s\n> before the stuff gets to nova-metadata.\n> \n> So without namespaces you should be safe. See here if you want further\n> know about the issue:\n> \n> http://techbackground.blogspot.fi/2013/06/metadata-via-quantum-router.html\n> http://techbackground.blogspot.ie/2013/06/metadata-via-dhcp-namespace.html\n> \n> Anyway as a feedback to my own original question, we solved (fingers\n> crossed :)) the issue by:\n> \n> 1. adding a port with given ip into network,\n>???? which is different than the physical gateway\n> 2. create a router with given port (this will\n>???? create NAT rules for quantum metadata)\n> 3. Tell the subnet to have default gw via the physical router\n> 4. Tell the subnet to advertice route to 169.254.169.254 via the\n>???? quantum router port made at step 1.\n> \n> The issue found here is that grizzly quantumclient is not able to create\n> quantum router with given port (backport, anyone ;)), you need to do it\n> via API (e.g. curl), or use the neutronclient from havana to do it,\n> where it\'s fixed.\n> \n> I hope this helps someone else running into the same situation with\n> provider networks, external router and metadata, it sure would\'ve helped\n> us, along with the info that vlans on bond are broken in Red Hat (any\n> kernel < 3.3):\n> \n> http://openstack.redhat.com/forum/discussion/598/dhcp-responces-get-lost-with-ovs-provider-vlans#Item_8\n> \n> BR,\n> \n> Ilkka\n\n\n\n',NULL,NULL),('<1380901722-sup-2733@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-04 09:08:32',-25200,'2013-10-04 16:08:32',NULL,'[openstack-dev] [TripleO] Undercloud Ceilometer','Excerpts from Ladislav Smola\'s message of 2013-10-04 08:28:22 -0700:\n> Hello,\n> \n> just a few words about role of Ceilometer in the Undercloud and the work \n> in progress.\n> \n> Why we need Ceilometer in Undercloud:\n> ---------------------------------------------------\n> \n> In Tuskar-UI, we will display number of statistics, that will show \n> Undercloud metrics.\n> Later also number of alerts and notifications, that will come from \n> Ceilometer.\n> \n> But I do suspect, that the Heat will use the Ceilometer Alarms, similar \n> way it is using it for\n> auto-scaling in Overcloud. Can anybody confirm?\n\nI have not heard of anyone want to \"auto scale\" baremetal for the\npurpose of scaling out OpenStack itself. There is certainly a use case\nfor it when we run out of compute resources and happen to have spare\nhardware around. But unlike on a cloud where you have several\napplications all contending for the same hardware, in the undercloud we\nhave only one application, so it seems less likely that auto-scaling\nwill be needed. We definitely need \"scaling\", but I suspect it will not\nbe extremely elastic.\n\nWhat will be needed, however, is metrics for the rolling updates feature\nwe plan to add to Heat. We want to make sure that a rolling update does\nnot adversely affect the service level of the running cloud. If we\'re\nearly in the process with our canary-based deploy and suddenly CPU load is\nshooting up on all of the completed nodes, something, perhaps Ceilometer,\nshould be able to send a signal to Heat, and trigger a rollback.\n\n> \n> What is planned in near future\n> ---------------------------------------\n> \n> The Hardware Agent capable of obtaining statistics:\n> https://blueprints.launchpad.net/ceilometer/+spec/monitoring-physical-devices\n> It uses SNMP inspector for obtaining the stats. I have tested that with \n> the Devtest tripleo setup\n> and it works.\n> \n> The planned architecture is to have one Hardware Agent(will be merged to \n> central agent code)\n> placed on Control Node (or basically anywhere). That agent will poll \n> SNMP daemons placed on\n> hardware in the Undercloud(baremetals, network devices). Any objections \n> why this is a bad idea?\n> \n> We will have to create a Ceilometer Image element, snmpd element is \n> already there, but we should\n> test it. Anybody volunteers for this task? There will be a hard part: \n> doing the right configurations.\n> (firewall, keystone, snmpd.conf) So it\'s all configured in a clean and a \n> secured way. That would\n> require a seasoned sysadmin to at least observe the thing. Any \n> volunteers here? :-)\n> \n> The IPMI inspector for Hardware agent just started:\n> https://blueprints.launchpad.net/ceilometer/+spec/ipmi-inspector-for-monitoring-physical-devices\n> Seems it should query the Ironic API, which would provide the data \n> samples. Any objections?\n> Any volunteers for implementing this on Ironic side?\n> \n> devananda and lifeless had a greatest concern about the scalability of a \n> Central agent. The Ceilometer\n> is not doing any scaling right now, but they are planning Horizontal \n> scaling of the central agent\n> for the future. So this is a very important task for us, for larger \n> deployments. Any feedback about\n> scaling? Or changing of architecture for better scalability?\n> \n\nI share their concerns. For < 100 nodes it is no big deal. But centralized\nmonitoring has a higher cost than distributed monitoring. I\'d rather see\nagents on the machines themselves do a bit more than respond to polling\nso that load is distributed as much as possible and non-essential\nnetwork chatter is reduced.\n\nI\'m extremely interested in the novel approach that Assimilation\nMonitoring [1] is taking to this problem, which is to have each node\nmonitor itself and two of its immediate neighbors on a switch and\nsome nodes monitor an additional node on a different switch. Failures\nare reported to an API server which uses graph database queries to\ndetermine at what level the failure occurred (single node, cascading,\nor network level).\n\nIf Ceilometer could incorporate that type of light-weight high-scale\nmonitoring ethos, rather than implementing something we know does not\nscale well at the level of scale OpenStack needs to be, I\'d feel a lot\nbetter about pushing it out as part of the standard deployment.\n\n[1] http://assimmon.org/\n\n\n','<524EDE96.7080908@redhat.com>',NULL),('<1380907131.23890.117.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-04 13:18:51',-14400,'2013-10-04 17:18:51',NULL,'[Openstack-docs] What\'s Up Doc? Oct 2 2013','On Wed, 2013-10-02 at 10:35 -0500, Anne Gentle wrote:\n> \n> 2. High priority doc work:\n> \n> The install guide is the highest priority right now. Shaun is working\n> on drafts in his Github repo at [2] and will patch to\n> openstack-manuals this week, today (hump day!) or tomorrow.\n\n> 2. https://github.com/shaunix/openstack-manuals/tree/master/doc/install-guide\n\nStatus:\n\n* There are places where I\'m not sure on the setup on Ubuntu and\nOpenSUSE. Grep for \'FIXME\'.\n\n* Needs the Overview and Sample Architecture sections filled out. Can\nprobably reuse old content or something in common for Overview. Sample\nArchitecture lays out the architecture and assumptions used in the\ninstall guide. I tend to write intros last.\n\n* Needs a short conceptual overview of Glance.\n\n* Needs a section on KVM configuration. The Grizzly docs have a\nperfectly good section, but it\'s disappeared from git. I\'ll find it. It\ndoes need to be slightly updated to account for systemd-based systems.\n\n* Needs some very basic network stuff to allow you to access booted\nimages. The Grizzly docs are pretty good, so I\'ll mostly just copy that\nover.\n\n* Needs text on booting and playing around with images. This is mostly\njust to verify that stuff is working and to show you what you can now\nfinally do, five chapters in.\n\n* Needs the chapter on Cinder written. There\'s some stuff in the Grizzly\ndocs, but not a lot.\n\n* Needs the chapter on Swift written. There\'s a lot of stuff in the\nGrizzly docs. It needs to be adapted, and may need to be pared down.\n\n* Needs the chapter on Neutron. Solly Ross was interested in this.\n\n* Needs your feedback on what might be missing or what\'s wrong.\n\nThanks,\nShaun\n\n\n\n\n\n','<CAD0KtVHJJrSUBig-ng92AR5Eit0D+qndkUn3-gvY0vM=0KEvtA@mail.gmail.com>',NULL),('<1380919254.50159385@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-04 16:40:54',-14400,'2013-10-04 20:40:54',NULL,'[openstack-dev] [Glance] tasks/async workers sync up.','\nHi all,\n \nPlease find below a brief summary of what went on in the meeting for convenience sake:-\n \nTODO:\n---------\n1. nikhil: To request for timings for a sync up meeting twice a week outside of weekly Glance meeting\n2. flwang: to ensure out split patches are updated and ready for review\n3. venkatesh and nikhil: to work on POC for dynamic loading of the executors to load deployer specific ones\n4. venkatesh: to work on a separate patch for DB optimization\n5. flwang: to modify tasks list call to return sparse list - one without input, result, message\n6. rosmaita: to modify the docs to ensure they are okay with what API returns\n7. reviewers: reviews :)\n\n\n\n\nNotes:\n--------\n1. re-evaluate the executor interface design after working on stevedore\n2. DB is okay with current model - some performance improvements can be done in the future\n3. API to return sparse list (which must include \'status\') while a show on tasks will give all details - Doc change\n4. community is okay with soft-deletes - hard-deletes would be looked at later point in time\n5. expires_at field goes in some glance.conf, default value to be 48 hours\n6. more research on the glance-janitor script or some kind of scrubber which deletes tasks after current_time > expires_at\n \nPlease let me know if you\'ve any questions.\nThanks,\n-Nikhil\n\n\n-----Original Message-----\nFrom: \"Nikhil Komawar\" <nikhil.komawar at rackspace.com>\nSent: Thursday, October 3, 2013 2:22pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Glance] tasks/async workers sync up.\n\n\n\nHi folks,\n \nI was hoping to see if you all were free sometime tomorrow (Friday) Oct 4th at 14:00 UTC to do a sync up on the patch we\'ve had going on for async workers (full PS here:- [https://review.openstack.org/#/c/46117/] https://review.openstack.org/#/c/46117/ ).\n \nVenkatesh and I are working full time on this and trying to address some of the comments we\'ve received. Zhi has suggested some important changes and, if we can have a general meeting/consensus about the direction this impl should go it would make things easy going forward. The design currently does not have dynamic loading of the modules; besides that if there were major concerns, we would really appreciate some feedback from community on them as well.\n \nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131004/acacc84e/attachment.html>\n\n','<1380824524.946329801@apps.rackspace.com>',NULL),('<1380928458.2354.77.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-05 00:14:18',3600,'2013-10-04 23:14:18',NULL,'[OpenStack Foundation] October 3 Board Meeting','Hey\n\nOn Fri, 2013-10-04 at 16:58 -0500, Jonathan Bryce wrote:\n> The OpenStack Foundation Board of Directors had a telephone meeting\n> yesterday.\n\nMy summary here as usual:\n\nhttp://blogs.gnome.org/markmc/2013/10/03/oct-3rd-openstack-foundation-board-meeting/\n\nCheers,\nMark.\n\n\n\n','<83CA15EF-5F92-4773-B19E-1487775888F7@openstack.org>',NULL),('<1380949363.15488.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-05 13:02:43',28800,'2013-10-05 05:02:43',NULL,'[Openstack] problem in understanding account reaper,\n	auditor and replicator code in swift source code','Hello,\n\nI am studying swift source code.\n\nMy problem is:\n\nWhen we start swift, and start swift account processes by giving the command:\n$ sudo swift-init accoount-reaper start\n$ sudo swift-init accoount-auditor start\n$ sudo swift-init accoount-replicator start\n\nwhich functions are invoked in swift sourcecode?\nAre they the __init__ functions defined in the class AccountReaper in swift/account/reaper.py, class AccountAuditor in swift/account/auditor.py and class AccountReplicator in swift/account/replicator.py respectively\n\nPlease help me in this regard.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131005/f949aab8/attachment.html>\n\n',NULL,NULL),('<1381049320.393.1367042869873.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:07:49',0,'2013-04-27 06:07:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/>\nCheckout:periodic-horizon-python26-stable-grizzly / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/> - hudson.remoting.Channel at 7edde1f6:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\nChecking out Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\n[periodic-horizon-python26-stable-grizzly] $ /bin/bash -xe /tmp/hudson4499246154867710018.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.N5lurNGXGv\n+ TMPDIR=/tmp/tmp.N5lurNGXGv\n+ trap \'rm -rf /tmp/tmp.N5lurNGXGv\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.horizon.python26.stable.grizzly.17\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python26-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 42991 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python26-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182611.957488-819863317\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.N5lurNGXGv\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-04-41\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'e6bac6a9-ceb0-4978-9eda-f761b52dbc76\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'04aa8c8dad0ffedcddc16423454703b73df5de91\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 42991 166.78.48.192 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\nNo distributions at all found for Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.N5lurNGXGv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1381156931.7265.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-07 15:42:11',3600,'2013-10-07 14:42:11',NULL,'[Openstack] about tempest','Nitesh,\n\nthese look good:\n\nhttps://docs.google.com/presentation/d/1M3XhAco_0u7NZQn3Gz53z9VOHHrkQBzEs5gt43ZvhOc/edit#slide=id.g712053f_0_76\n\nhttp://dague.net/presentations/tempest-101/#/\n\nRe, darragh.\n\n> Message: 5\n> Date: Mon, 7 Oct 2013 12:44:15 +0530\n> From: Nitesh Selkari <niteshselkari at gmail.com>\n> To: openstack at lists.openstack.org\n> Subject: [Openstack] about tempest\n> Message-ID:\n>???? <CABqg5zpCxAk=7ctU-TjzcXxrfEXKWZ55hNjH4cACZWwWxj1uew at mail.gmail.com>\n> Content-Type: text/plain; charset=ISO-8859-1\n> \n> Hi,\n> I am Nitesh. I am new to open stack community. I wanted to know about\n> tempest,that is, how to write test cases for open stack , how to? test\n> individual component of open stack. I? referred some open stack\n> tempest testing documents (github) but unable to get the flow of\n> testing procedure. Please help me with some kind of documentation or\n> links from where I can get the flow of testing procedure.\n> \n> Regards\n> Nitesh Selkari\n\n\n',NULL,NULL),('<1381157887.2354.121.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-07 15:58:07',3600,'2013-10-07 14:58:07',NULL,'[openstack-dev] TC candidacy','Hi\n\nI\'d like to offer my self as a candidate for the Technical Committee\nelection.\n\n\nAbout me\n\nI\'ve been working on OpenStack for over two years now and have\nparticularly focused my contributions on Nova and Oslo, but have also\ncontributed in smaller ways to most other OpenStack projects.\n\nFor the past year or more, I\'ve been a member of the Technical Committee\nas Oslo PTL.\n\nI\'m a proud Red Hatter and am also a member of the OpenStack Foundation\nBoard of Directors.\n\n\nThe Past Year\n\nI\'m very happy with some of the progress and decisions the TC made over\nthe past year.\n\nWe welcomed Heat, Ceilometer, Trove, Savannah, Marconi into the\nOpenStack family either as integrated or incubating projects. The TC\ncarefully considered each of these applications and my own rule of thumb\nwas \"does it have a healthy contributor community and is it a sensible\ngrowth of OpenStack\'s scope?\". I love to see this sustainable growth in\nour project and community.\n\nIn a similar vein, I\'m really excited that TripleO has been added as an\nofficial OpenStack program. One of OpenStack\'s biggest criticisms has\nalways been that it is difficult to deploy and manage. TripleO is an\nawesome idea but, more importantly, is a way for all of us to work\ntogether to build tools and processes for deploying and managing our\nsoftware.\n\nIn terms of more meta changes, I\'m really happy that the TC has moved to\na model where all seats are directly elected. This removed the concern\nthat adding new projects would make the TC unmanageably large so that\ncan no longer be used as an excuse to not add new projects. I also hope\nthat this election model will result in more members who are interested\nin cross-project concerns.\n\nI\'m proud of the work we did with the foundation board to adopt the term\n\"integrated\" as a way to separate the TC controlled \"accepted into the\nOpenStack integrated release process\" status from the board controlled\n\"allowed to use associate OpenStack trademark\" status. This is really\nimportant because it allows the TC to evaluate new project applications\non a purely technical basis.\n\nI think it\'s really positive that we adopted the concept of \"programs\"\nas a recognition that not all important efforts and contributor groups\nare focused around a particular server project. Our community has a very\ndiverse set of contributor groups and all of them play an important\nrole.\n\nFinally, I\'m happy to see us starting to use gerrit to track TC\ndecisions in a way that is easily referenceable. Looking back over the\nlast year of TC decisions would have been a lot easier with \'git log\'!\nSee https://review.openstack.org/50066 :)\n\n\nNext Year\n\nI want to see the TC continue to be welcoming to new projects and\ncontributor groups. That said, I\'d like us to continue improve how we\ndeliberate over these applications. For example, maybe we assign\nspecific TC members with aspects of the project to report back on - e.g.\narchitecture, development process, contributor diversity, test coverage,\netc.\n\nI\'m also really eager to encourage any experiments with evolving our\nproject governance model. I think we\'re seeing several projects with\nmultiple leaders who are essentially peers and having to choose a PTL\ncan be an artificial elevation of one person over their peers. I stepped\ndown as Oslo PTL because I want Oslo to have a bunch of strong leaders,\nrather than be dominated by one person.\n\nFinally, I\'d like the TC to be used more often as a forum for people to\ndevelop their ideas about the project. We should view the TC as a group\nof project leaders who are happy, as a group, to help people out with\nadvice and mentorship.\n\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1381180013.2354.194.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-07 22:06:53',3600,'2013-10-07 21:06:53',NULL,'[OpenStack Foundation] Individual Member Director Elections','Hi Jim,\n\nOn Mon, 2013-10-07 at 10:12 -0700, James E. Blair wrote:\n> Hi,\n> \n> During the October 3 meeting, the board discussed the election process\n> for the individual member directors and made some fairly shocking\n> conclusions.\n> \n> As you may recall, there has been concern about this process since its\n> inception, and the board has spent some time dealing with this.\n> \n> On November 16, 2012:\n>   RESOLVED, that the Board will bring in outside experts and conduct a\n>   proper legal review before making changes to the cumulative voting\n>   process prior to the next election.\n> \n> And on February 12 2013:\n>   RESOLVED, that the following members of the Board shall be appointed\n>   to an Election Committee, to be chaired by Mr. Moore:\n>   ...\n> \n> From what I gather, that election committee produced a report that was\n> delivered to the directors.  I have not read it because it has not been\n> made public; nor do I believe that any input from the wider community\n> was solicited.  But based on that report, the board concluded that the\n> individual member director election process is fine the way it is and\n> does not need to change.\n> \n> I believe this is, to anyone who has been paying attention for the past\n> year, quite a shocking determination to make.\n\nAll your points are well made and thanks for taking the time to make\nthem.\n\nI do very much agree with your points about the election system and\nfavoured a change to STV but, yet, I did vote to not change the system\nthis year because:\n\n  - there was a general feeling that relatively few perceive the \n    problem here. Comparing our ~6000 members to the numbers expressing \n    serious concerns on this mailing list, you can see why.\n\n  - the current system does appear to have elected committed board \n    members who act on behalf of the membership rather than their \n    affiliation. That could be a self-serving perspective, though.\n\n  - with such a large electorate, getting a majority of a 25+% voter \n    turnout to vote for an election system change is going to require a \n    lot of awareness raising. I\'m trying to imagine a massive \"our\n    election system is broken, it\'s critical you turn out to fix it\" \n    being a positive thing. I\'m also concious that if we did hold a \n    vote to move to STV and it was rejected, that could be the end of \n    the matter forever.\n\n  - I do think the code of conduct will have an influence and prevent \n    \"bad\" voter behaviour. I\'m basing that on the strong endorsement \n    all board members appear to give the code.\n\n  - I was in favour of the max-4-votes-per-candidate \"tweak\" because we\n    initially thought that would not require a bylaws change. This would\n    have had an immediate positive effect IMHO.\n\ni.e. my conclusion was that we should make a tweak for this cycle and\nrevisit if/when this becomes a big enough issue again to mobilize a\nlarge enough chunk of the electorate.\n\nUltimately, though, my concern is how our membership numbers means there\nis a massive difference in commitment/engagement between our members.\nThe number of members who are closely engaged with the project (and no,\nI don\'t just mean ATCs) is huge by any standards but they are most\nlikely dwarfed by the number of less engaged members. That numbers game\nhad a big impact on this debate IMHO.\n\n\nAll that said, it\'s fair to say the election committee realized only\nlast week that we should have been far more transparent and e.g. had a\nmailing list like the transparency committee has. I should take\nresponsibility for that since your concerns about the committee\'s\nworkings is like a mirror image of mine from last year:\n\n  http://lists.openstack.org/pipermail/foundation/2012-November/001250.html\n\nThe report of the committee was intended to be published, I trust it\nwill be soon.\n\n\nThanks again,\nMark.\n\n\n\n','<8761t9qa2x.fsf@meyer.lemoncheese.net>',NULL),('<1381207005.12147.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-08 12:36:45',28800,'2013-10-08 04:36:45',NULL,'[Openstack] Which functions are invoked in swift source code','hello all,\n\nwhen we give the command?\n$ sudo swift-init accoount-auditor start\n\n\n?__init__ functions defined in the class?AccountAuditor in swift/account/auditor.py is invoked.\n\n??\nBut, I don\'t understand\n1. How does the control go to run_forever() or run_once() function defined in the same class?\n2. Who will decide whether to run?run_forever() function or run_once() function?\n\nPlease help me in this regard\n------\n\nThanks?\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131008/53ee37f0/attachment.html>\n\n',NULL,NULL),('<1381244491.2354.259.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-08 16:01:31',3600,'2013-10-08 15:01:31',NULL,'[OpenStack Foundation] Individual Member Director Elections','On Tue, 2013-10-08 at 09:52 -0400, Monty Taylor wrote:\n> None of the members of the board have behaved in a corrupt manner, nor\n> have they behaved as second representatives of their corporations\n> explicit interests. In fact, the appointed representatives haven\'t even\n> done that.\n\nCompletely agree with that. It goes without saying that individual\nmember directors should represent the community not their employer, but\nI\'ve been surprised and impressed that even the platinum and gold member\ndirectors (who are there explicitly to represent those companies) have\nnot sought to push corporate interests over the project\'s interests.\n\nIn that respect, we have established a healthy culture on the board but\nit\'s really only obvious if you sit in on the board meetings. I can\ntotally relate to being sceptical about that.\n\nHonestly, if the board was actually filled with the kind of corporate\nbickering many of us feared, it would be a lot easier to feel we would\nhave the necessary support to make this change.\n\nMark.\n\n\n\n','<52540E0A.3000002@inaugust.com>',NULL),('<1381244691-sup-2270@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-08 08:22:29',-25200,'2013-10-08 15:22:29',NULL,'[openstack-dev] [TRIPLEO] tripleo-core update october','I don\'t meant to pick on you personally Ji??, but I have singled this\nmessage out because I feel you have captured the objections to Robert\'s\ninitial email well.\n\nExcerpts from Ji?? Str?nsk?\'s message of 2013-10-08 04:30:29 -0700:\n> On 8.10.2013 11:44, Martyn Taylor wrote:\n> > Whilst I can see that deciding on who is Core is a difficult task, I do\n> > feel that creating a competitive environment based on no. reviews will\n> > be detrimental to the project.\n> >\n> > I do feel this is going to result in quantity over quality. Personally,\n> > I\'d like to see every commit properly reviewed and tested before getting\n> > a vote and I don\'t think these stats are promoting that.\n> \n> +1. I feel that such metric favors shallow \"i like this code\"-reviews as \n> opposed to deep \"i verified that it actually does what it \n> should\"-reviews. E.g. i hit one such example just today morning on \n> tuskarclient. If i just looked at the code as the other reviewer did, \n> we\'d let in code that doesn\'t do what it should. There\'s nothing bad on \n> making a mistake, but I wouldn\'t like to foster environment of quick \n> shallow reviews by having such metrics for core team.\n> \n\n\nI think you may not have worked long enough with Robert Collins to\nunderstand what Robert is doing with the stats. While it may seem that\nRobert has simply drawn a line in the sand and is going to sit back and\nwait for everyone to cross it before nominating them, nothing could be\nfurther from the truth.\n\nAs one gets involved and start -1\'ing and +1\'ing, one can expect feedback\nfrom all of us as core reviewers. It is part of the responsibility of\nbeing a core reviewer to communicate not just with the submitter of\npatches, but also with the other reviewers. If I see shallow +1\'s from\npeople consistently, I\'m going to reach out to those people and ask them\nto elaborate on their reviews, and I\'m going to be especially critical\nof their -1\'s.\n\n> I think it\'s also important who actually *writes* the code, not just who \n> does reviews. I find it odd that none of the people who most contributed \n> to any of the Tuskar projects in the last 3 months would make it onto \n> the core list [1], [2], [3].\n> \n\nI think having written a lot of code in a project is indeed a good way\nto get familiar with the code. However, it is actually quite valuable\nto have reviewers on a project who did not write _any_ of the code,\nas their investment in the code itself is not as deep. They will look\nat each change with fresh eyes and bring fewer assumptions.\n\nReviewing is a different skill than coding, and thus I think it is o-k\nto measure it differently than coding.\n\n> This might also suggest that we should be looking at contributions to \n> the particular projects, not just the whole program in general. We\'re \n> such a big program that one\'s staleness towards some of the components \n> (or being short on global review count) doesn\'t necessarily mean the \n> person is not important contributor/reviewer on some of the other \n> projects, and i\'d also argue this doesn\'t affect the quality of his work \n> (e.g. there\'s no relationship between tuskarclient and say, t-i-e, \n> whatsoever).\n> \n\nIndeed, I don\'t think we would nominate or approve a reviewer if they\njust did reviews, and never came in the IRC channel, participated in\nmailing list discussions, or tried to write patches. It would be pretty\ndifficult to hold a dialog in reviews with somebody who is not involved\nwith the program as a whole.\n\n> So i\'d say we should get on with having a greater base of core folks and \n> count on people using their own good judgement on where will they \n> exercise their +/-2 powers (i think it\'s been working very well so far), \n> or alternatively split tripleo-core into some subteams.\n> \n\nIf we see the review queue get backed up and response times rising, I\ncould see a push to grow the core review team early. But we\'re talking\nabout a 30 day sustained review contribution. That means for 30 days\nyou\'re +1\'ing instead of +2\'ing, and then maybe another 30 days while we\nfigure out who wants core powers and hold a vote.\n\nIf this is causing anyone stress, we should definitely address that and\nmake a change. However, I feel the opposite. Knowing what is expected\nand being able to track where I sit on some of those expectations is\nextremely comforting. Of course, easy to say up here with my +2/-2. ;)\n\n\n','<5253ECD5.4030006@redhat.com>',NULL),('<1381281387-sup-8564@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-08 18:51:53',-25200,'2013-10-09 01:51:53',NULL,'[openstack-dev] [Heat] HOT Software orchestration proposal for\n	workflows','Excerpts from Stan Lagun\'s message of 2013-10-08 13:53:45 -0700:\n> Hello,\n> \n> I?m one of the engineer working on Murano project. Recently we started a\n> discussion about Murano and Heat Software orchestration and I want to\n> continue this discussion with more technical details.\n> \n> In our project we do deployment of complex multi-instance Windows services.\n> Those services usually require specific multi-VM orchestration that is\n> currently impossible or at least not that easy to achieve with Heat. As you\n> are currently doing HOT software orchestration design we would like to\n> participate in HOT Software orchestration design and contribute into it, so\n> that the Heat could address use-cases which we believe are very common.\n> \n> For example here is how deployment of a SQL Server cluster goes:\n> \n>    1.\n> \n>    Allocate Windows VMs for SQL Server cluster\n>    2.\n\nHeat does this quite well. :)\n\n> \n>    Enable secondary IP address from user input on all SQL Windows instances\n>    3.\n\nI don\'t understand what that means.\n\n> \n>    Install SQL Server prerequisites on each node\n>    4.\n> \n\nAutomating software installation is a very common aspect of most\nconfiguration tools.\n\n>    Choose a master node and install Failover Cluster on it\n>    5.\n> \n\nLeader election should be built in to services that take advantage of\nit. External leader election is really hard without all of the\nprimitives built into the service. Otherwise you have to resort to\nthings like STONITH to avoid split brain. If Heat tries to do this, it\nwill just result in a complicated design with very few happy users.\n\n>    Configure all nodes so that they know which one of them is the master\n>    6.\n> \n\nAnyway, Heat can do this quite well. The template author can just choose\none, and flag it as the master in the resource\'s Metadata. Point all\nothers at that one using Ref\'s to it.\n\n\"Configuring\" nodes should be something an automated configuration tool\ndoes well. It is pretty straight forward to have a tool fetch the\nMetadata of a resource via the Heat API and feed it to a configuration\ntool. Or you can even teach your config tool to read the Metadata.\n\n>    Install SQL Server on all nodes\n>    7.\n> \n\nSame as before - any automated software installation tool should\nsuffice.\n\n>    Initialize AlwaysOn on all nodes except for the master\n>    8.\n> \n\nI don\'t know what that means.\n\n>    Initialize Primary replica\n>    9.\n> \n>    Initialize secondary replicas\n> \n\nI also don\'t know what that entails, but I would suspect that it is the\nkind of thing you do via the SQL server API once everything is done.\n\nFor that, you just need to poll a waitcondition and when all of the\nnodes have signaled the waitcondition, run this.\n\n> \n> All of the steps must take place in appropriate order depending on the\n> state of other nodes. Some steps require an output from previous steps and\n> all of them require some input parameters. SQL Server requires an Active\n> Directory service in order to use Failover mechanism and installation of\n> Active Directory with primary and secondary controllers is a complex\n> workflow of its own.\n> \n> That is why it is necessary to have some central coordination service which\n> would handle deployment workflow and perform specific actions (create VMs\n> and other OpenStack resources, do something on that VM) on each stage\n> according to that workflow. We think that Heat is the best place for such\n> service.\n> \n\nI\'m not so sure. Heat is part of the Orchestration program, not workflow.\n\n> Our idea is to extend HOT DSL by adding  workflow definition capabilities\n> as an explicit list of resources, components? states and actions. States\n> may depend on each other so that you can reach state X only after you?ve\n> reached states Y and Z that the X depends on. The goal is from initial\n> state to reach some final state ?Deployed?.\n> \n\nOrchestration is not workflow, and HOT is an orchestration templating\nlanguage, not a workflow language. Extending it would just complect two\nvery different (though certainly related) tasks.\n\nI think the appropriate thing to do is actually to join up with the\nTaskFlow project and consider building it into a workflow service or tools\n(it is just a library right now).\n\n> There is such state graph for each of our deployment entities (service,\n> VMs, other things). There is also an action that must be performed on each\n> state.\n\nHeat does its own translation of the orchestration template into a\nworkflow right now, but we have already discussed using TaskFlow to\nbreak up the orchestration graph into distributable jobs. As we get more\nsophisticated on updates (rolling/canary for instance) we\'ll need to\nbe able to reason about the process without having to glue all the\npieces together.\n\n> We propose to extend HOT DSL with workflow definition capabilities where\n> you can describe step by step instruction to install service and properly\n> handle errors on each step.\n> \n> We already have an experience in implementation of the DSL, workflow\n> description and processing mechanism for complex deployments and believe\n> we?ll all benefit by re-using this experience and existing code, having\n> properly discussed and agreed on abstraction layers and distribution of\n> responsibilities between OS components. There is an idea of implementing\n> part of workflow processing mechanism as a part of Convection proposal,\n> which would allow other OS projects to benefit by using this.\n> \n> We would like to discuss if such design could become a part of future Heat\n> version as well as other possible contributions from Murano team.\n> \n\nThanks really for thinking this through. Windows servers are not unique in\nthis regard. Puppet and chef are pretty decent at expressing single-node\nworkflows but they are awkward for deferring control and resuming on other\nnodes, so I do think there is a need for a general purpose distributed\nworkflow definition tool.\n\nI\'m not, however, convinced that extending HOT would yield a better\nexperience for users. I\'d prefer to see HOT have a well defined interface\nfor where to defer to external workflows. Wait conditions are actually\ndecent at that, and I\'m sure with a little more thought we can make them\nmore comfortable to use.\n\n\n','<CAOCoZiZdmdu6Gm+zVvYG=xfbDdWUHzk4z2-95W4jmVnDbXaMog@mail.gmail.com>',NULL),('<1381321828.2354.298.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-09 13:30:28',3600,'2013-10-09 12:30:28',NULL,'[OpenStack Foundation] Individual Member Director Elections','On Wed, 2013-10-09 at 14:23 +0200, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> >   - with such a large electorate, getting a majority of a 25+% voter \n> >     turnout to vote for an election system change is going to require a \n> >     lot of awareness raising. I\'m trying to imagine a massive \"our\n> >     election system is broken, it\'s critical you turn out to fix it\" \n> >     being a positive thing. I\'m also concious that if we did hold a \n> >     vote to move to STV and it was rejected, that could be the end of \n> >     the matter forever.\n> \n> Frankly, if getting a 25+% voter turnout is seen as an impossible task,\n> that means the membership is fundamentally broken. And I think it is,\n> due to the low bar of entry and lack of membership expiration.\n\nStrongly agree.\n\n> A precondition to any rule that defines a minimum membership turnout is\n> to keep the membership sane and active. If we keep members forever, then\n> we are bound to have stale entries in that database and getting 25% (or\n> even 5%) turnout will one day just be impossible.\n> \n> So the first step in fixing this mess is to sanitize the membership. I\n> would send out emails to existing members and give them two weeks to\n> confirm they are still active and would like to participate to the\n> upcoming elections. Send a reminder after one week, then remove all\n> entries that did not click the right button. It\'s no big deal anyway,\n> they can re-add themselves very easily if they want.\n> \n> In parallel, I would go through the list and remove obvious duplicates\n> entries. Looking at the members directory, there are a LOT of them, and\n> each of them makes that 25% target less likely.\n\nNice ideas.\n\n> Then we should not fear changing the rules, because that 25% target\n> would actually work the way it was intended, not as a rule to block all\n> future changes.\n\nYep, it would help a lot.\n\nThanks,\nMark.\n\n\n\n','<52554AB8.4060503@openstack.org>',NULL),('<1381331331.8456540.1401372945658.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 10:15:45',-14400,'2014-05-29 14:15:45',NULL,'[openstack-dev] [sahara] summit wrap-up: subprojects','\n\n----- Original Message -----\n> Re sahara-image-elements we found a bunch of issues that we should\n> solve and that\'s why I think that keeping current releasing is still\n> the best option.\n> \n> - we should test it better and depend on stable diskimage-builder version\n> The dib is now published to pypi, so, we could make\n> sahara-image-elements in dib-style and publish it to pypi in the same\n> style. It makes us able to add some sanity tests for images checking\n> and add gate jobs for running them (it could be done anyway, but this\n> approach with separated repo looks more consistent). Developing\n> sahara-image-elements as a pip-installable project we could add\n> diskimage-builder to the requirements.txt of it and manage it\'s\n> version, it\'ll provide us good flexibility - for example, we\'ll be\n> able to specify to use \"latest release dib\".\n> - all scripts and dib will not be installed with sahara (50/50)\n\nI think if we are going to make sahara-image-elements into a full-fledged pypi package we should refactor diskimage-create.sh into a python script. It will give up better options for argument parsing and I feel more control over the flow of operations.\n\nmike\n\n\n','<CA+GZd78jQSi_V=wneNXF_QW49iBYZVkwtxVeCEKfg6yYx7+QWg@mail.gmail.com>',NULL),('<1381334510-sup-7806@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-09 10:19:42',-25200,'2013-10-09 17:19:42',NULL,'[openstack-dev] [Heat] HOT Software orchestration proposal for\n	workflows','Excerpts from Georgy Okrokvertskhov\'s message of 2013-10-09 08:37:36 -0700:\n> Hi,\n> \n> In addition I want to add couple words about flexibility and debugging\n> capabilities. I believe it is quite important for HOT template engine to\n> control all aspects of deployment process execution including software\n> components. Right now I believe Heat lack of control of what is going on\n> the VM side.  In my opinion, HOT template user should be able to define\n> what steps are necessary to deploy complex environment and more important,\n> he should be able to provide a hints to the engine how to deal with errors\n> during deployment. Centralized orchestration sees the whole picture of the\n> environment status while scripts on VM usually have quite limited view.\n> Workflows specification can have on_error actions and centralized\n> orchestration will be capable to make smart decision on how to handle\n> errors during deployment.\n> \n\nWhat you have described above is some of what I\'d like to see in HOT.\nIt is an evolution beyond the limitations of the waitcondition that\nkeeps things simple. Basically, orchestration providing a hook point\nat which a portion of the workflow is deferred to some other tool. The\ntool signals back when it is done, or has an error. We have that now,\nbut now, the errors just halt the process. We definitely need a way to\nsay something like this:\n\non_error_code: {default: {rebuild_resources: [ Instance1, Loadbalancer1]}}\n\nThe OS::Heat::HARestarter was sort of an attempt at some of this.\n\nI take issue with a tool that wants to control everything. That may be\nthe easy way out, however I believe that it will lead to a very large,\nvery complex tool that users will be suspicious of.\n\nFor me, I\'d like to know where my orchestration ends, and my software\nconfiguration, installation, and state management all begin. The interface\ncan be such that Heat doesn\'t have to be omniscient and omnipotent.\nIt just has to help simplify the task of orchestration and get out of\nworkflow/config/installation/etc.\'s way.\n\n> I think we need to have a design discussion about the architecture of this\n> centralized orchestration. From the one side, this orchestration should\n> have the whole information about environment state and as Heat has full\n> exposure to the environment it sounds reasonable to have such orchestration\n> as a part of Heat. At the other side, HOT template should be quite simple\n> to be useful, so additional workflows concepts might overload DSL syntax\n> and additional independent orchestration level also sounds quite reasonable\n> and this is what we have now as a Murano project.\n>\n\nIt sounds like you have learned a lot on this journey and it would\ndefinitely be valuable to collaborate with you so that we can make sure\nHeat accommodates the use cases you have uncovered.\n\n> It will be nice to have some initial live discussion before the summit as\n> not all developers will be on summit. What do you think about Google\n> hangout session at the end of this week or on the next week?\n> \n\nI find that summit sessions are most useful when we are at a point where\nthere are just a few decision points to get through. If we come with too\nmuch already done, then group-think will take over and less-well-formed\nideas will get squelched. If we come without clearly defined decisions\nto make, then we\'ll bike-shed for the full 40 minutes.\n\nSo, given that, I think a brief pre-summit discussion is a good idea to\nhelp us figure out where we may have conflicting views and then we can\ncome ready to hash those out in a high bandwidth environment.\n\n\n','<CAG_6_o=DF4zPXSLcLODirpi11+Mv-gY3tKt+g+0rPVv7CFBnfA@mail.gmail.com>',NULL),('<1381415385.2354.387.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-10 15:29:45',3600,'2013-10-10 14:29:45',NULL,'[openstack-dev] [Oslo] Change ListOpt and DictOpt default values','Hi Flavio,\n\nOn Thu, 2013-10-10 at 14:40 +0200, Flavio Percoco wrote:\n> Greetings,\n> \n> I\'d like to propose to change both ListOpt and DictOpt default values\n> to [] and {} respectively. These values are, IMHO, saner defaults than\n> None for this 2 options and behavior won\'t be altered - unles `is not\n> None` is being used.\n> \n> Since I may be missing some history, I\'d like to ask if there\'s a\n> reason why None was kept as the default `default` value for this 2 options?\n> \n> As mentioned above, this change may be backward incompatible in cases\n> like:\n> \n>     if conf.my_list_opt is None:\n>         ....\n> \n> Does anyone if there are cases like this?\n\nI\'d need a lot of persuasion that this won\'t break some use of\noslo.config somewhere. Not \"why would anyone do that?\" hand-waving.\nPeople do all sorts of weird stuff with APIs.\n\nIf people really think this is a big issue, I\'d make it opt-in. Another\nboolean flag like the recently added validate_default_values.\n\nAs regards bumping the major number and making incompatible changes - I\nthink we should only consider that when there\'s a tonne of legacy\ncompatibility stuff that we want to get rid of. For example, if we had a\nbunch of opt-in flags like these, then there\'d come a point where we\'d\nsay \"let\'s do 2.0 and clean those up\". However, doing such a thing is\ndisruptive and I\'d only be in favour of it if the backwards compat\nsupport was really getting in our way.\n\nThanks,\nMark.\n\n\n\n','<20131010124000.GB816@redhat.com>',NULL),('<1381416820.2354.390.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-10 15:53:40',3600,'2013-10-10 14:53:40',NULL,'[OpenStack Foundation] Individual Member Director Elections','Hi\n\nOn Mon, 2013-10-07 at 22:06 +0100, Mark McLoughlin wrote:\n> All that said, it\'s fair to say the election committee realized only\n> last week that we should have been far more transparent and e.g. had a\n> mailing list like the transparency committee has. \n\nOk, we\'ve now rectified this much at least. See:\n\n  http://lists.openstack.org/cgi-bin/mailman/listinfo/elections-committee\n\nThanks to Monty for getting it set up\n\nMark.\n\n\n\n','<1381180013.2354.194.camel@sorcha>',NULL),('<1381442751.45939.YahooMailNeo@web160504.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-10 15:05:51',-25200,'2013-10-10 22:05:51',NULL,'[openstack-dev] [Neutron] Extraroute and router extensions','Hi Rudra, Nachi.\n\nGlad to see this discussion on the mailing list! The ExtraRoute routes are fairly\nlimited and it would be great to be able to store more complete routing\ninformation in Neutron. I\'ve submitted a blueprint proposing expanding ExtraRoute\nparameters to include more information (extended-route-params). But it still\nhas a problem where routes are stored in a list and are not indexed. So an update\ncould be painful.\n\nCould you share what attributes would you like to see in your RIB API?\n\nThanks!\nArtem\n\nP.S. I\'m OpenStack newbie, looking forward to learning from and working with you!\n\n>Hi Rudra\n>\n>ExtraRoute bp was designed for adding some \"extra\" routing for the router.\n>The spec is very handy for simple and small use cases.\n>However it won\'t fit large use cases, because it takes all route in a Json List.\n># It means we need to send full route for updating.\n>\n>As Salvatore suggests, we need to keep backward compatibility.\n>so, IMO, we should create Routing table extension.\n>\n>I\'m thinking about this in the context of L3VPN (MPLS) extension.\n>My Idea is to have a RIB API in the Neutron.\n>For vpnv4 routes it may have RT or RDs.\n>\n>Best\n>Nachi \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131010/2bedb008/attachment.html>\n\n',NULL,NULL),('<1381447678-sup-9670@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-10 16:47:05',-25200,'2013-10-10 23:47:05',NULL,'[openstack-dev] [Heat] HOT Software orchestration proposal for\n	workflows','Excerpts from Angus Salkeld\'s message of 2013-10-10 15:27:48 -0700:\n> On 10/10/13 11:59 +0400, Stan Lagun wrote:\n> >This rises number of questions:\n> >\n> >1. What about conditional dependencies? Like config3 depends on config1 AND\n> >config2 OR config3.\n> \n> We have the AND, but not an OR. To depend on two resources you just\n> have 2 references to the 2 resources.\n> \n\nAND is concrete. OR is not. I don\'t actually think it is useful for what\nHeat is intended to do. This is not not packaging, this is deploying.\nFor deploying, Heat needs to know _what to do_, not \"what is possible\".\n\n> >\n> >2. How do I pass values between configs? For example config1 requires value\n> >from user input and config2 needs an output value obtained from applying\n> >config1\n> \n> {Fn::GetAtt: [config2, the_name_of_the_attribute]}\n> \n\nThis is a little bit misleading. Heat does not have any good ways to\nget a \"value obtained from applying config1\". The \"data\" attribute of\nthe WaitCondition is the only way I know, and it is really unwieldy,\nas it can basically only dump a json string of all of the things each\nsignaler has fed back in.\n\nThat said, I wonder how many of the \"value obtained from applying config1\"\nwould be satisfied by the recently proposed \"random string generation\"\nresource. Most of the time what people want to communicate back is just\nauth details. If we push auth details in from Heat to both sides, that\nalleviates all of my current use cases for this type of feature.\n\n> >\n> >3. How would you do error handling? For example config3 on server3 requires\n> >config1 to be applied on server1 and config2 on server2. Suppose that there\n> >was an error while applying config2 (and config1 succeeded). How do I\n> >specify reaction for that? Maybe I need then to try to apply config4 to\n> >server2 and continue or maybe just roll everything back\n> \n> We currently have no \"on_error\" but it is not out of scope. The\n> current action is either to rollback the stack or leave it in the\n> failed state (depending on what you choose).\n> \n\nRight, I can definitely see more actions being added as we identify the\ncommonly desired options.\n\n> >\n> >4. How these config dependencies play with nested stacks and resources like\n> >LoadBalancer that create such stacks? How do I specify that myConfig\n> >depends on HA proxy being configured if that config was declared in nested\n> >stack that is generated by resource\'s Python code and is not declared in my\n> >HOT template?\n> \n> It is normally based on the actual data/variable that you are\n> dependant on.\n> loadbalancer: depends on autoscaling instance_list\n> (actually in the loadbalancer config would be a \"GetAtt: [scalegroup, InstanceList]\")\n> \n> Then if you want to depend on that config you could depend on an\n> attribute of that resource that changes on reconfigure.\n> \n> config1:\n>    type: OS::SoftwareConfig::Ssh\n>    properties:\n>      script: {GetAtt: [scalegroup, InstanceList]}\n>      hosted_on: loadbalancer\n>      ...\n> \n> config2:\n>    type: OS::SoftwareConfig::Ssh\n>    properties:\n>      script: {GetAtt: [config1, ConfigAppliedCount]}\n>      hosted_on: somewhere_else\n>      ...\n> \n> I am sure we could come up with some better syntax for this. But\n> the logic seems easily possible to me.\n> \n> As far as nested stacks go: you just need an output to be useable\n> externally - basically design your API.\n> \n> >\n> >5. The solution is not generic. For example I want to write HOT template\n> >for my custom load-balancer and a scalable web-servers group. Load balancer\n> >config depends on all configs of web-servers. But web-servers are created\n> >dynamically (autoscaling). That means dependency graph needs to be also\n> >dynamically modified. But if you explicitly list config names instead of\n> >something like \"depends on all configs of web-farm X\" you have no way to\n> >describe such rule. In other words we need generic dependency, not just\n> >dependency on particular config\n> \n> Why won\'t just depending on the scaling group be enough? if it needs\n> to be updated it will update all within the group before progressing\n> to the dependants.\n> \n\nIn the example, loadbalancer doesn\'t have to depend on all of the nodes\nbeing configured.  Why would it? It gets a signal when the list changes,\nbut it can be created as soon as the _group_ is created.\n\nAnyway, no dependency is needed. Your LB has health checks, you feed\nthem in, and when the webservers are configured, they pass, and it sends\ntraffic there.\n\n> >\n> >6. What would you do on STACK UPDATE that modifies the dependency graph?\n> >\n> >The notation of configs and there\n> \n> What we normally do go through the resources, see what can be updated:\n> - without replacement\n> - needs deleting\n> - is new\n> - requires updating\n> \n> Each resource type can define what will require replacing or not.\n> \n> I think we can achieve what you want with some small improvements to\n> the HOT format and with some new resource types - IMHO.\n\nAgree with Angus here. I think we\'re closer to your use case than you\nthink. :)\n\n\n','<20131010222748.GA20890@redhat.com>',NULL),('<1381488146.2354.424.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-11 11:42:26',3600,'2013-10-11 10:42:26',NULL,'[OpenStack Foundation] [Fwd: [Elections-committee] Summarizing our\n	latest thinking]','Hey\n\nJust so this doesn\'t get lost in the noise, the elections-committee do\nhave an open mailing list now. See below for a summary I put together.\nTroy, Tim and Monty followed up with some points I missed:\n\nhttp://lists.openstack.org/pipermail/elections-committee/2013-October/thread.html\n\nMark.\n\n-------- Forwarded Message --------\n> From: Mark McLoughlin <markmc at redhat.com>\n> Reply-to: Mark McLoughlin <markmc at redhat.com>\n> To: elections-committee at lists.openstack.org\n> Subject: [Elections-committee] Summarizing our latest thinking\n> Date: Thu, 10 Oct 2013 16:16:57 +0100\n> \n> Hi\n> \n> Since the foundation list thread kicked off, there\'s been a bunch of\n> discussion on the foundation-board list and directly amongst ourselves. \n> \n> Now that we have this list, I think the first thing we need to do is\n> summarize where those discussions have lead to.\n> \n> Here\'s my attempt, but please pile on with anything I missed. Also, I\n> haven\'t put anyone\'s name against any of these positions for fear of\n> misrepresenting anyone.\n> \n> \n>  * The advice that we cannot tweak the cumulative voting system without \n>    a bylaws change changes things. We now have the choice between:\n> \n>      1) do nothing\n>      2) hold a vote on making any change change to the system\n>      3) hold a vote on tweaking the cumulative system\n>      4) hold a vote on changing to a particular system like\n>         STV/Condorcet\n> \n>    I have expressed my order of preference as 4, 2, 3, 1\n> \n>  * Apparently the membership numbers have greatly increased over the \n>    6,000 members which I talked about. I don\'t see a public reference \n>    to this number anywhere, so I won\'t repeat it here.\n> \n>  * There is debate over whether we could take a vote on a bylaws change \n>    in time for the next election cycle or whether it would have to be \n>    taken at the same time as the next round of elections.\n> \n>    My take is that doing it with this years elections could give a\n>    better chance of turnout and we\'re unlikely to get a vote ready with \n>    sufficient campaigning in advance of that anyway.\n> \n>  * Some feel that having multiple members affiliated with the same \n>    organization on the board is a serious and related issue. We have \n>    discussed whether we should hold a vote on this. Personally, I\'m fine\n>    with including it as another vote along with the election system \n>    vote.\n> \n>  * We discussed whether our concern about getting a sufficient turnout \n>    for a bylaws change points to a more fundamental underlying issue \n>    with our membership. Some discussion about whether members should \n>    automatically lose their membership if they do not vote in an\n>    election.\n> \n>  * We have had some discussion about STV vs Condorcet that would be \n>    great to share, but I\'m not best placed to summarize it\n> \n>  * Our original report is still waiting to be published along with all \n>    other supporting materials from the Oct 3rd meeting\n> \n> Mark.\n> \n> \n> _______________________________________________\n> Elections-committee mailing list\n> Elections-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/elections-committee\n\n\n\n\n',NULL,NULL),('<1381503395.2354.446.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-11 15:56:35',3600,'2013-10-11 14:56:35',NULL,'[OpenStack Foundation] Agreement on requiring board candidates\n to attend the meetings, and,\n why didn\'t this dogpile dial into the last meeting?','On Fri, 2013-10-11 at 14:42 +0000, Atwood, Mark wrote:\n\n> And finally, for many parts of the OpenStack community, this is our\n> *job*.  We get paid to do this.  Dialing into a Board meeting and\n> listening in should be as important in attending as the various\n> meetings and con calls and all-hands and stand-ups that we do for our\n> employers.  Where were all the PTLs, the TC members, the couple of\n> dozen other community engagement folks?\n\nIf I wasn\'t on the board, and if there was a detailed summary of the\ntopics published after the meeting, then I\'d read that rather than\ndialling in just to listen.\n\nI do think it would be worthwhile for people to attend in-person for an\nhour or two if they happen to be convenient to the venue, but that\'s\nmore from a \"look these are real people, people who care about\nOpenStack\" perspective.\n\nMark.\n\n\n\n','<28D8420C-4AAB-4033-BA59-7A55A140CEB5@hp.com>',NULL),('<1381505159.2354.463.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-11 16:25:59',3600,'2013-10-11 15:25:59',NULL,'[OpenStack Foundation] Agreement on requiring board candidates\n to attend the meetings, and,\n why didn\'t this dogpile dial into the last meeting?','On Fri, 2013-10-11 at 11:19 -0400, Richard Fontana wrote:\n> On Fri, Oct 11, 2013 at 03:56:35PM +0100, Mark McLoughlin wrote:\n> > On Fri, 2013-10-11 at 14:42 +0000, Atwood, Mark wrote:\n> > \n> > > And finally, for many parts of the OpenStack community, this is our\n> > > *job*.  We get paid to do this.  Dialing into a Board meeting and\n> > > listening in should be as important in attending as the various\n> > > meetings and con calls and all-hands and stand-ups that we do for our\n> > > employers.  Where were all the PTLs, the TC members, the couple of\n> > > dozen other community engagement folks?\n> > \n> > If I wasn\'t on the board, and if there was a detailed summary of the\n> > topics published after the meeting, then I\'d read that rather than\n> > dialling in just to listen.\n> > \n> > I do think it would be worthwhile for people to attend in-person for an\n> > hour or two if they happen to be convenient to the venue, but that\'s\n> > more from a \"look these are real people, people who care about\n> > OpenStack\" perspective.\n> \n> I\'ve attended part or all of a couple of the board meetings by phone.\n> \n> One thing I have found rather puzzling is the orientation towards use\n> of webex, though I realize there is a backup traditional dialin. I\n> have wondered whether this might have some subtle effect in\n> discouraging some to attend the meetings virtually, since the natural\n> assumption is that webex is going to provide some fuller experience\n> (as otherwise I am not sure why it would be used at all). \n> \n> In the case of one meeting, I struggled without success in trying to\n> use webex via two devices I had available and the annoyance of that\n> experience almost led me to decide not to then dial in. I dunno,\n> perhaps my experience is atypical. What precisely does webex provide\n> that a traditional conference call service would not, for purposes of\n> OpenStack Foundation board meetings?\n\nI think the main benefit is screen sharing for slides. I\'ve never had it\nwork, though.\n\nOh, also the ability to mute everyone but the directors and see the name\nof who is talking.\n\n> In the case of one of the in-person board meetings I attended by\n> dialing in, it was possible to hear at best 40% or so of what was\n> said.\n\nYeah, dialling in to an in-person meeting is a waste of time.\n\nMy suggestion was people attend the in-person meetings in-person if they\nhappen to be in the area. They\'re often held the day before the\nopenstack summit.\n\nMark.\n\n\n\n','<20131011151919.GA7317@redhat.com>',NULL),('<1381509008-sup-2610@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-11 09:40:19',-25200,'2013-10-11 16:40:19',NULL,'[openstack-dev] [Heat] HOT Software orchestration proposal for\n	workflows','Excerpts from Stan Lagun\'s message of 2013-10-11 07:22:37 -0700:\n> Hello,\n> \n> Thanks Angus, Clint, I\'ve got your design.\n> \n> It seems that Murano can built on top of that. With service metadata\n> knowledge Murano can generate HOT templates with set of interdependent\n> configs.\n> Here is what will be needed:\n> \n> 1. Ability to implement support for custom software configuration tool\n> (type: OS::SoftwareConfig::MuranoAgent)\n\nThese are really syntactic sugar, but you can implement them as resource\nplugins for users who want Murano resources. In the absence of this,\njust putting things in the free form metadata area of the resource that\nthe MuranoAgent can interpret would suffice.\n\n> 2. Ability to provide arbitrary input values for the config\n\nWe already have that, there\'s a free-form json document called \"metadata\"\nattached to every resource. Or maybe I missed what you mean here. The\nnew capability that is in the works that will make that better is to\nhave multiple reusable metadata blocks referenced on one instance.\n\n> 3. Ability to return arbitrary (JSON-compatible) data structure from config\n> application and use attributes of that structure as an input for other\n> configs\n\nNote that I\'d like to see more use cases specified for this ability. The\nrandom string generator that Steve Baker has put up should handle most\ncases where you just need passwords. Generated key sharing might best\nbe deferred to something like Barbican which does a lot more than Heat\nto try and keep your secrets safe.\n\n> 4. Ability to provide config body that is an input to Murano Agent of\n> arbitrary size\n\nIsn\'t this the same as 2?\n\n> 5. Work well with large graph of configs with a lot of dependencies.\n> Independent configs on different VMs should be applied in parallel.\n>\n\nYes this does look good. For dependent configs, the exsiting wait\ncondition can be used.\n\n> Does it confirm to your plans?\n> \n\nI think it confirms that we\'re heading toward consensus on where to draw\nthe software config vs. infrastructure orchestration line. That is very\nexciting. :)\n\n\n','<CAOCoZiZSiwA80L1hRkvNt4z7WSxk3tfeumaU25kdjrw2-OZOrg@mail.gmail.com>',NULL),('<1381510546.20746.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-11 17:55:46',3600,'2013-10-11 16:55:46',NULL,'[Openstack] clear dns_nameservers','Hi Alejandro,\n\nyou need to do:\n\n\n$ neutron subnet-update fixed --dns_nameservers action=clear\n\nRe, Darragh.\n\n> Hi,\n> \n> After updating a quantum attribute, I\'m looking for a way to \"clear\"\n> the field dns_nameservers\n> \n> +------------------+-------------------------------------------------------+\n> | Field??????????? | Value???????????????????????????????????????????????? |\n> +------------------+-------------------------------------------------------+\n> | allocation_pools | {\"start\": \"192.168.123.50\", \"end\": \"192.168.123.254\"} |\n> | cidr???????????? | 192.168.123.0/24????????????????????????????????????? |\n> | dns_nameservers? |?????????????????????????????????????????????????????? |\n> | enable_dhcp????? | True????????????????????????????????????????????????? |\n> | gateway_ip?????? | 192.168.123.49??????????????????????????????????????? |\n> | host_routes????? |?????????????????????????????????????????????????????? |\n> | id?????????????? | 336674e1-eded-4e5b-a87c-744281bab14b????????????????? |\n> | ip_version?????? | 4???????????????????????????????????????????????????? |\n> | name???????????? | fixed???????????????????????????????????????????????? |\n> | network_id?????? | f6dd957c-3079-499d-a6bb-b34e278b23a6????????????????? |\n> | tenant_id??????? | d765841b7e9b450a8d0d91f3b1189ded????????????????????? |\n> +------------------+-------------------------------------------------------+\n> :~ # neutron subnet-update fixed --dns_nameservers list=true 8.8.8.7 8.8.8.8\n> Updated subnet: fixed\n> :~ # neutron subnet-show fixed\n> +------------------+-------------------------------------------------------+\n> | Field??????????? | Value???????????????????????????????????????????????? |\n> +------------------+-------------------------------------------------------+\n> | allocation_pools | {\"start\": \"192.168.123.50\", \"end\": \"192.168.123.254\"} |\n> | cidr???????????? | 192.168.123.0/24????????????????????????????????????? |\n> | dns_nameservers? | 8.8.8.7?????????????????????????????????????????????? |\n> |????????????????? | 8.8.8.8?????????????????????????????????????????????? |\n> | enable_dhcp????? | True????????????????????????????????????????????????? |\n> | gateway_ip?????? | 192.168.123.49??????????????????????????????????????? |\n> | host_routes????? |?????????????????????????????????????????????????????? |\n> | id?????????????? | 336674e1-eded-4e5b-a87c-744281bab14b????????????????? |\n> | ip_version?????? | 4???????????????????????????????????????????????????? |\n> | name???????????? | fixed???????????????????????????????????????????????? |\n> | network_id?????? | f6dd957c-3079-499d-a6bb-b34e278b23a6????????????????? |\n> | tenant_id??????? | d765841b7e9b450a8d0d91f3b1189ded????????????????????? |\n> +------------------+-------------------------------------------------------+\n> \n> \n> :~ # neutron subnet-update fixed --dns_nameservers list=false\n> Invalid input for dns_nameservers. Reason: Invalid data format for\n> nameserver: \'list=false\'.\n> \n> :~ # neutron subnet-update fixed --dns_nameservers\n> Invalid input for dns_nameservers. Reason: Invalid data format for\n> nameserver: \'True\'.\n> \n> :~ # neutron subnet-update fixed --dns_nameservers list=false 8.8.8.7 8.8.8.8\n> Invalid input for dns_nameservers. Reason: \'list=false\' is not a valid\n> nameserver.\n> \n> :~ # quantum subnet-update fixed --dns_nameservers list=false \"\"\n> Invalid input for dns_nameservers. Reason: \'list=false\' is not a valid\n> nameserver.\n> \n> :~ # neutron subnet-update fixed --dns-nameservers \"\"\n> Invalid input for dns_nameservers. Reason: Invalid data format for\n> nameserver: \'\'.\n> \n> Any idea how can I clear this field?\n> \n> Thanks,\n> Alejandro\n\n\n\n',NULL,NULL),('<1381516056-sup-9030@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-11 11:34:31',-25200,'2013-10-11 18:34:31',NULL,'[openstack-dev] \"Thanks for fixing my patch\"','Recently in the TripleO meeting we identified situations where we need\nto make it very clear that it is ok to pick up somebody else\'s patch\nand finish it. We are broadly distributed, time-zone-wise, and I know\nother teams working on OpenStack projects have the same situation. So\nwhen one of us starts the day and sees an obvious issue with a patch,\nwe have decided to take action, rather than always -1 and move on. We\nclarified for our core reviewers that this does not mean that now both\nof you cannot +2. We just need at least one person who hasn\'t been in\nthe code to also +2 for an approval*.\n\nI think all projects can benefit from this model, as it will raise\nvelocity. It is not perfect for everything, but it is really great when\nrunning up against deadlines or when a patch has a lot of churn and thus\nmay take a long time to get through the \"rebase gauntlet\".\n\nSo, all of that said, I want to encourage all OpenStack developers to\nsay \"thanks for fixing my patch\" when somebody else does so. It may seem\nobvious, but publicly expressing gratitude will make it clear that you\ndo not take things personally and that we\'re all working together.\n\nThanks for your time -Clint\n\n* If all core reviewers have been in on the patch, then any two +2\'s\nwork.\n\n\n',NULL,NULL),('<1381530567.58261.YahooMailNeo@web125905.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-11 15:29:27',-25200,'2013-10-11 22:29:27',NULL,'[OpenStack Foundation] Agreement on requiring board candidates\n	to attend the meetings','If you are a board director, you should be at the board meetings. I consider it to be as important as attending my yahoo staff meetings. If you do not attend the meeting, then you can not be part of the decision making, which is the purpose of the meeting. It is hard for some companies and/or people to attend every board meeting. If you know up front that this is the case, then either reprioritize or don\'t join the board. This seems very boolean to me. I would certainly advise any prospective board members on this point. Let me know if I am missing something here.\n?\n\n\nSean Roberts\nInfrastructure Strategy\nseanrob at yahoo-inc.com\nDirect (408) 349-5234??Mobile (925) 980-4729\n?\n701 First Avenue, Sunnyvale, CA, 94089-0703, US\nPhone (408) 349-3300??Fax (408) 349-3301\n\n\n\nOn Friday, October 11, 2013 2:25 PM, Joshua McKenty <joshua at pistoncloud.com> wrote:\n \nThis may be the first time I\'ve ever disagreed with Tim, but I certainly do today.\nWe require new Gold Member applicants to demonstrate the activity that they plan on engaging in.\nWe expect new core team members to demonstrate a history of reviewing code.\nThe only case in which we don\'t expect candidates to demonstrate their willingness and ability to undertake the primary activity of the office, is for the board of directors.\nAttendance at at least 50% of the board meetings is already mandatory for directors (see the bylaws), I simply suggested applying that criteria to candidates as well.\nI heartily agree that we need to adjust TZ and locale (you may recall my argument with John Igoe on that topic at an earlier board meeting) - but that\'s entirely beside the point.\nMost folks have more important things to do than attend board meetings - which is exactly why they don\'t belong on the board! \nIf that\'s true when they\'re a candidate, why would it be false after they were elected?\nOn Oct 11, 2013 10:18 AM, \"Monty Taylor\" <mordred at inaugust.com> wrote:\n\n\n>\n>On 10/11/2013 12:50 PM, Tim Bell wrote:\n>>\n>>\n>> As one of the people who does not have their OpenStack activities within\n>> their job role and who lives in a timezone which until today Jrequired\n>> out-of-working-hours conferences, I think it is asking too much for\n>> mandatory participation in board meetings as a bar for entry.\n>>\n>>\n>>\n>> There are many other criteria that we can apply such as membership of a\n>> user group, participation in mailing lists, blogging their experiences\n>> or attendance at summits which is a more significant contribution than\n>> dialing in for a 6 hour call ending at 2 a.m. in the morning.\n>>\n>>\n>>\n>> In choosing to stand for election, the candidate accepts the activities\n>> that come with it. However, to require people to do their ?articles?\n>> before consideration for board membership does not seem the most\n>> effective use of some excellent community contributors.\n>>\n>>\n>>\n>> Let?s find some other criteria.\n>\n>As always a voice of reason. Thanks Tim.\n>\n>\n>> *From:*Nick Barcet [mailto:nick at enovance.com]\n>> *Sent:* 11 October 2013 17:34\n>> *To:* Foundation Mailing List\n>> *Subject:* Re: [OpenStack Foundation] Agreement on requiring board\n>> candidates to attend the meetings, and, why didn\'t this dogpile dial\n>> into the last meeting?\n>>\n>>\n>>\n>> My 2c on this is that making participation mandatory is ok, as long as\n>> we also accept valid excuses for exceptional reasons, which can cover:\n>> time compatibility, prior engagements, etc... ?I\'ve missed two board\n>> meeting this year, one which was scheduled in the middle of my night,\n>> the other because I had to give a presentation on the role of a board\n>> member which was scheduled at the same time. In both case I tried to\n>> catch up immediately after (thanks for Alan?s help).\n>>\n>> I do think these cases (and there are certainly others) are valid reason\n>> to be exceptionally excused and would be consider a mandatory/no excuse\n>> rule be completely counter productive to our objectives.\n>>\n>> Nick\n>>\n>>\n>>\n>>\n>>\n>> On Fri, Oct 11, 2013 at 11:19 AM, Richard Fontana <rfontana at redhat.com\n>> <mailto:rfontana at redhat.com>> wrote:\n>>\n>> ? ? On Fri, Oct 11, 2013 at 03:56:35PM +0100, Mark McLoughlin wrote:\n>> ? ? > On Fri, 2013-10-11 at 14:42 +0000, Atwood, Mark wrote:\n>> ? ? >\n>> ? ? > > And finally, for many parts of the OpenStack community, this is our\n>> ? ? > > *job*. ?We get paid to do this. ?Dialing into a Board meeting and\n>> ? ? > > listening in should be as important in attending as the various\n>> ? ? > > meetings and con calls and all-hands and stand-ups that we do\n>> ? ? for our\n>> ? ? > > employers. ?Where were all the PTLs, the TC members, the couple of\n>> ? ? > > dozen other community engagement folks?\n>> ? ? >\n>> ? ? > If I wasn\'t on the board, and if there was a detailed summary of the\n>> ? ? > topics published after the meeting, then I\'d read that rather than\n>> ? ? > dialling in just to listen.\n>> ? ? >\n>> ? ? > I do think it would be worthwhile for people to attend in-person\n>> ? ? for an\n>> ? ? > hour or two if they happen to be convenient to the venue, but that\'s\n>> ? ? > more from a \"look these are real people, people who care about\n>> ? ? > OpenStack\" perspective.\n>>\n>> ? ? I\'ve attended part or all of a couple of the board meetings by phone.\n>>\n>> ? ? One thing I have found rather puzzling is the orientation towards use\n>> ? ? of webex, though I realize there is a backup traditional dialin. I\n>> ? ? have wondered whether this might have some subtle effect in\n>> ? ? discouraging some to attend the meetings virtually, since the natural\n>> ? ? assumption is that webex is going to provide some fuller experience\n>> ? ? (as otherwise I am not sure why it would be used at all).\n>>\n>> ? ? In the case of one meeting, I struggled without success in trying to\n>> ? ? use webex via two devices I had available and the annoyance of that\n>> ? ? experience almost led me to decide not to then dial in. I dunno,\n>> ? ? perhaps my experience is atypical. What precisely does webex provide\n>> ? ? that a traditional conference call service would not, for purposes of\n>> ? ? OpenStack Foundation board meetings?\n>>\n>> ? ? In the case of one of the in-person board meetings I attended by\n>> ? ? dialing in, it was possible to hear at best 40% or so of what was\n>> ? ? said.\n>>\n>> ? ? - RF\n>>\n>>\n>> ? ? _______________________________________________\n>> ? ? Foundation mailing list\n>> ? ? Foundation at lists.openstack.org <mailto:Foundation at lists.openstack.org>\n>> ? ? http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>\n>>\n>>\n>>\n>> --\n>> Nick Barcet <nick at enovance.com <mailto:nick at enovance.com>>\n>> VP Products - eNovance\n>> a.k.a. nicolas, nijaba\n>>\n>>\n>>\n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>>\n>\n>_______________________________________________\n>Foundation mailing list\n>Foundation at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131011/61acd058/attachment.html>\n\n','<CALOyBR11WKYg-FtjT5z81NLCYN-dYiE=Y=qC8=qqB=1HTmwNQA@mail.gmail.com>',NULL),('<1381541221.98334.YahooMailNeo@web160501.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-11 18:27:01',-25200,'2013-10-12 01:27:01',NULL,'[openstack-dev] [Neutron] Extraroute and router extensions','Great!\n\nLooking forward to seeing more of this discussion. I\'ve mentioned that I submitted a blueprint request extending ExtraRoute extension to include more routing attributes. It\'s located here: https://blueprints.launchpad.net/neutron/+spec/extended-route-params/ and it contains editable google doc. I don\'t know if it is of much use as it talks heavily about extra route extension. Please feel free to copy any part if you would find it useful (e.g. screenshot) or if you would appreciate any help with your blueprint I\'d be very glad to pitch in.\n\n\nHave a good weekend.\n\nSincerely,\nArtem Dmytrenko\n\n\nOn Friday, October 11, 2013 3:02 PM, Nachi Ueno <nachi at ntti3.com> wrote:\n \nHi Artem\n\nThank you for your pointing out this.\nI\'m still thinking about the design. Once I got the draft, I\'ll share\nit in the bp and here..\n\nBest\nNachi\n\n\n2013/10/10 Artem Dmytrenko <nextone92 at yahoo.com>:\n> Hi Rudra, Nachi.\n>\n> Glad to see this discussion on the mailing list! The ExtraRoute routes are\n> fairly\n> limited and it would be great to be able to store more complete routing\n> information in Neutron. I\'ve submitted a blueprint proposing expanding\n> ExtraRoute\n> parameters to include more information (extended-route-params). But it still\n> has a problem where routes are stored in a list and are not indexed. So an\n> update\n> could be painful.\n>\n> Could you share what attributes would you like to see in your RIB API?\n>\n> Thanks!\n> Artem\n>\n> P.S.\n>? I\'m OpenStack newbie, looking forward to learning from and working with\n> you!\n>\n>>Hi Rudra\n>>\n>>ExtraRoute bp was designed for adding some \"extra\" routing for the router.\n>>The spec is very handy for simple and small use cases.\n>>However it won\'t fit large use cases, because it takes all route in a Json\n>> List.\n>># It means we need to send full route for updating.\n>>\n>>As Salvatore suggests, we need to keep backward compatibility.\n>>so, IMO, we should create Routing table extension.\n>>\n>>I\'m thinking about this in the context of L3VPN (MPLS) extension.\n>>My Idea is to have a RIB API in the Neutron.\n>>For vpnv4 routes it may have RT or RDs.\n>>\n>>Best\n>>Nachi\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131011/771eaed8/attachment.html>\n\n','<CABJepwgoh5x=rxqCKAG-u5uSGK+cJM0ME+RiMMHCY-uM_+dm7g@mail.gmail.com>',NULL),('<1381593585.23890.154.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-12 11:59:45',-14400,'2013-10-12 15:59:45',NULL,'[Openstack-docs] Havana Install Guide - Status','Andreas has been on top of openSUSE, though of course extra testing eyes\nare never a bad thing. Currently, the guide is targeting Ubuntu and not\nDebian, but only because nobody\'s done the testing work for Debian.\n\nIt would be nice if somebody actually tested RHEL. I\'m writing against\nFedora 19, which has some substantial changes from RHEL6. I\'m somewhat\naware of these because I still have an F14 box in my house, but it would\nbe good to actually test RHEL6.\n\nAnd as I\'m typing this, I\'m thinking we need a way of tracking which\nsections were testing on which systems when and by whom. Otherwise we\nrun the risk of new material not getting tested. Maybe just a list on\nthe etherpad?\n\n--\nShaun\n\nOn Sat, 2013-10-12 at 11:13 -0400, Nick Chase wrote:\n> OK, I got Debian up and running first, so unless you REALLY want\n> OpenSUSE first, I\'m starting on that now.\n> \n> \n> ----  Nick\n> \n> \n> On Sat, Oct 12, 2013 at 10:54 AM, Nicholas Chase <nchase at mirantis.com>\n> wrote:\n>         \n>         \n>         On 10/12/2013 8:09 AM, Tom Fifield wrote:\n>                 On 12/10/13 16:39, chandan kumar wrote:\n>                                                 On 10/11/13 8:13 AM,\n>                                                 \"Tom Fifield\"\n>                                                 <tom at openstack.org>\n>                                                 wrote:\n>                                                         The following\n>                                                         is the status\n>                                                         of the recent\n>                                                         Havana Install\n>                                                         Guide work:\n>                                                         \n>                                                         Overview and\n>                                                         architecture\n>                                                         * Needs an\n>                                                         edit\n>                                                         * Sample\n>                                                         Architectures\n>                                                         is in, but\n>                                                         needs diagrams\n>                                                         and checking\n>                                                         for\n>                                                         accuracy\n>                                                         against the\n>                                                         rest of the\n>                                                         document\n>                                                         \n>                                                         Basic\n>                                                         Operating\n>                                                         System\n>                                                         Configuration\n>                                                         * Tested 100%\n>                                                         OK for Ubuntu\n>                                                         * Needs\n>                                                         testing for\n>                                                         RHEL, Fedora,\n>                                                         OpenSUSE,\n>                                                         Debian\n>         \n>         \n>         I can pick up OpenSUSE or Debian; which one do you want first?\n>         \n>         ----  Nick\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<CA+p99GmOvN49Sd15ObXNZbnkAcX_4vUtjgFdY5YJT_PkQyEZ=A@mail.gmail.com>',NULL),('<1381643184.5087.8.camel@lark.home>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-13 11:16:24',19800,'2013-10-13 05:46:24',NULL,'[Openstack] debian grizzly nova-common mysql dbconfig issues','Hello,\n\nI am setting up a grizzly compute node on a Debian Wheezy box. I am\nusing the archive.gplhost.com repository.\n\nWhen installing nova-common, the debconf scripts ask for database\ninformation. It does not ask for the host where the database is. It\nsimply assumes that the db server will be on the localhost. This is not\nthe case for me, because the mysql server is running on the controller\nnode.\n\nI skipped/ignored that step and went ahead. I noticed that debconf was\nrunning \'nova-manage db sync\' and failing. I am not sure what db\nmanipulation it is trying to do. The OpenStack manuals dont talk about\nany db configuration from the compute node. Should the nova on the\ncompute-node update anything in the db? Should I force nova-manage to\nrun again with the right db settings?\n\nJoe\n\n-- \nJoe Steeve\nHiPro IT Solutions Private Limited\nhttp://hipro.co.in/\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131013/2183690f/attachment.pgp>\n\n',NULL,NULL),('<1381645415.1828.2.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-13 14:23:35',28800,'2013-10-13 06:23:35',NULL,'[Openstack] debian grizzly nova-common mysql dbconfig issues','On Sun Oct 13 2013 01:46:24 PM HKT, Joe Steeve <js at hipro.co.in> wrote:\n\n> Hello,\n> \n> I am setting up a grizzly compute node on a Debian Wheezy box. I am\n> using the archive.gplhost.com repository.\n> \n> When installing nova-common, the debconf scripts ask for database\n> information. It does not ask for the host where the database is. It\n> simply assumes that the db server will be on the localhost. This is not\n> the case for me, because the mysql server is running on the controller\n> node.\n\napt-get install dbconfig-common\ndpkg-reconfigure dbconfig-common\n\n:)\n\nThomas\n\n\n\n','<1381643184.5087.8.camel@lark.home>',NULL),('<1381766481-sup-6578@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-14 09:04:20',-25200,'2013-10-14 16:04:20',NULL,'[Openstack] PaaS project in OpenStack','Excerpts from Frans Thamura\'s message of 2013-10-14 08:45:20 -0700:\n> Hi all\n> \n> Just a little question\n> \n> Will there is a PaaS stack in Openstack.\n> \n> A little curiousity, will openshift part of openstack one day? Redhat\n> guy?...... or cf.\n> \n\n*** Warning, heavy use of \"the cloud is transportation\" analogy follows. ***\n\nJust like FedEx bought Kinkos, and UPS bought Mailboxes etc., eventually\nonce the infrastructure gets efficient, it makes sense to give consumers\na full service option. However these things are vastly different, so it\nwould make sense for OpenStack to adopt some PaaS that has gotten\nsuccessful rather than try and build one. Retail just works differently\nthan logistics.\n\n\n','<CAOeeQyqzkEYvt+HXyXJqUT6WEZ71_ryO6t9-OZVyUrRDeU3X3g@mail.gmail.com>',NULL),('<1381773571.6655.0.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 13:59:31',-14400,'2013-10-14 17:59:31',NULL,'[openstack-dev] [Keystone][oslo] Trusted Messaging Question','On Fri, 2013-10-11 at 17:49 +0000, Sangeeta Singh wrote:\n> Hi,\n> \n> \n> I had some questions about the trusted messaging project.\n> \n\n> >      1. During your design did you consider a kerberos style\n> >         ticketing service for KDS? If yes what were the reasons\n> >         against it?\n> >      2. The Keystone documentation does say that it can support\n> >         kerberos style authentication. Are there any know\n> >         implementations and deployments?\n> >      3. Does the secured messaging framework supports plugging in\n> >         one\'s own key service or is there a plan of going in that\n> >         direction. I think that would something that would be useful\n> >         to the community giving the flexibility to hook up different\n> >         security enforcing agents similar to the higher level\n> >         message abstractions to allow multiple message transport in\n> >         the oslo messaging library.\n> > I am interested to know how can one use the proposed framework and\n> > be able to plugin different key distribution mechanism.\n> > \n\nJust to keep the list in the loop, as we had a quick conversation on\nIRC.\n\n1. we did consider using Kerberos, however we felt that introducing such\na big dependency point-blank was a bit of a stretch, plus we are trying\nto address issues for which Kerberos does not have standard answers\n(yet), like for group messages or broadcasts (and the current solution\ndoesn\'t work well for this last case either). So in the end I proposed a\nsimplified system that would allow us to experiment with all the pieces\nand introduce the necessary interfaces in more agile way. The aim has\nalways been to experiment and find out the corner cases and be able to\nchange the system if needed.\n\n2. KDS is a symmetric key management system exclusively dedicated to the\nRPC messaging layer, it has nothing to do with Keystone authentication.\nKeystone can use HTTP authentication so you can plug in things like\nmod_auth_kerb in apache in front of keystone. Same for x509 certs, but\nagain these are orthogonal uses.\n\n3. As I explained on IRC, the idea for the secure messaging  code was to\ndraw a \'template\' for the client side. So that additional methods could\nbe plugged in. The securemessage class is quite abstract and all\nself-contained, so that it should be easy to drop in a replacement that\nuses a different security mechanism.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n\n','<CE7D8847.3B166%singhs@yahoo-inc.com>',NULL),('<1381775233-sup-3852@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 11:30:45',-25200,'2013-10-14 18:30:45',NULL,'[openstack-dev] baremetal nova boot issue','Excerpts from Ravikanth Samprathi\'s message of 2013-10-14 11:15:15 -0700:\n> Thank you for your help and pointers Rob.\n> I followed instructions from the baremetal wiki and i am lost in the last\n> step.\n> \n> First:\n> I setup pxelinux.cfg/default to point to my-initrd and my-vmlinuz for pxe\n> boot.\n> My baremetal node goes into this prompt:\n> (initramfs)\n> I dont know if the above is correct.\n> \n> Second:\n> Then i do nova boot, which gives me this:\n> root at os:/tftpboot# nova boot --flavor my-baremetal-flavor --image my-image\n> my-baremetal-node\n> +-------------------------------------+--------------------------------------+\n> | Property                            |\n> Value                                |\n> +-------------------------------------+--------------------------------------+\n> | status                              |\n> BUILD                                |\n> | updated                             |\n> 2013-10-14T18:08:50Z                 |\n> | OS-EXT-STS:task_state               |\n> scheduling                           |\n> | OS-EXT-SRV-ATTR:host                |\n> None                                 |\n> | key_name                            |\n> None                                 |\n> | image                               |\n> my-image                             |\n> | hostId\n> |                                      |\n> | OS-EXT-STS:vm_state                 |\n> building                             |\n> | OS-EXT-SRV-ATTR:instance_name       |\n> instance-00000021                    |\n> | OS-EXT-SRV-ATTR:hypervisor_hostname |\n> None                                 |\n> | flavor                              |\n> my-baremetal-flavor                  |\n> | id                                  |\n> c9fd52de-e93e-44dd-9009-9395e964829e |\n> | security_groups                     | [{u\'name\':\n> u\'default\'}]              |\n> | user_id                             |\n> 251bd0a9388a477b9c24c99b223e7b2a     |\n> | name                                |\n> my-baremetal-node                    |\n> | adminPass                           |\n> 5kHEX46xremR                         |\n> | tenant_id                           |\n> 8a34123d83824f3ea52527c5a28ad81e     |\n> | created                             |\n> 2013-10-14T18:08:49Z                 |\n> | OS-DCF:diskConfig                   |\n> MANUAL                               |\n> | metadata                            |\n> {}                                   |\n> | accessIPv4\n> |                                      |\n> | accessIPv6\n> |                                      |\n> | progress                            |\n> 0                                    |\n> | OS-EXT-STS:power_state              |\n> 0                                    |\n> | OS-EXT-AZ:availability_zone         |\n> nova                                 |\n> | config_drive\n> |                                      |\n> +-------------------------------------+--------------------------------------+\n> root at os:/tftpboot#\n> \n> Before doing this, I have done the nova-baremetal-create and interface add,\n> and this is what i get:\n> ======================================================================\n> \n> root at os:/tftpboot# nova baremetal-node-create os 1 1024 10 00:50:56:AA:20:54\n> +------------------+-------------------+\n> | Property         | Value             |\n> +------------------+-------------------+\n> | instance_uuid    | None              |\n> | pm_address       | None              |\n> | interfaces       | []                |\n> | prov_vlan_id     | None              |\n> | cpus             | 1                 |\n> | memory_mb        | 1024              |\n> | prov_mac_address | 00:50:56:AA:20:54 |\n> | service_host     | os                |\n> | local_gb         | 10                |\n> | id               | 2                 |\n> | pm_user          | None              |\n> | terminal_port    | None              |\n> +------------------+-------------------+\n> root at os:/tftpboot# nova baremetal-interface-add 2 00:50:56:AA:20:54\n> +-------------+-------------------+\n> | Property    | Value             |\n> +-------------+-------------------+\n> | datapath_id | 0                 |\n> | id          | 2                 |\n> | port_no     | 0                 |\n> | address     | 00:50:56:AA:20:54 |\n> +-------------+-------------------+\n> \n> The baremetal node is stuck at (initramfs) no auto powering and no auto\n> booting happens.\n> I have not given --pm options , should i give that and if so what are the\n> values?\n> What am i missing?\n\nIf you don\'t give the power driver an address and credentials to turn\nthe machine on and off, you can\'t expect automatic deployment to work.\nYou will need IPMI credentials and an IP that the compute node can reach\nto turn the machine on/off using the IPMI protocol.\n\nIf your machines do not have IPMI, and they are not Tilera based, you\nwill need to write a power driver to turn them on and off.\n\n\n','<CAFuk=T3LJ=R73mxU7WcUxZrN9teDGhCR+Atn04hP2iXL-3-1Mw@mail.gmail.com>',NULL),('<1381776650-sup-8167@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 11:51:32',-25200,'2013-10-14 18:51:32',NULL,'[openstack-dev] baremetal nova boot issue','No, I said if your machines are not IPMI, and are not Tilera based, then\nthey will not work.\n\nIf they are IPMI, they will work.\n\nExcerpts from Ravikanth Samprathi\'s message of 2013-10-14 11:42:31 -0700:\n> You mean there is no power driver for anything other than tilera?  I am\n> using supermicro intel based baremetal nodes. And for testing am simulating\n> using VMs are baremetals as well.\n> Please let me know.\n> Thanks\n> Ravi\n> \n> On Mon, Oct 14, 2013 at 11:30 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Ravikanth Samprathi\'s message of 2013-10-14 11:15:15 -0700:\n> > > Thank you for your help and pointers Rob.\n> > > I followed instructions from the baremetal wiki and i am lost in the last\n> > > step.\n> > >\n> > > First:\n> > > I setup pxelinux.cfg/default to point to my-initrd and my-vmlinuz for pxe\n> > > boot.\n> > > My baremetal node goes into this prompt:\n> > > (initramfs)\n> > > I dont know if the above is correct.\n> > >\n> > > Second:\n> > > Then i do nova boot, which gives me this:\n> > > root at os:/tftpboot# nova boot --flavor my-baremetal-flavor --image\n> > my-image\n> > > my-baremetal-node\n> > >\n> > +-------------------------------------+--------------------------------------+\n> > > | Property                            |\n> > > Value                                |\n> > >\n> > +-------------------------------------+--------------------------------------+\n> > > | status                              |\n> > > BUILD                                |\n> > > | updated                             |\n> > > 2013-10-14T18:08:50Z                 |\n> > > | OS-EXT-STS:task_state               |\n> > > scheduling                           |\n> > > | OS-EXT-SRV-ATTR:host                |\n> > > None                                 |\n> > > | key_name                            |\n> > > None                                 |\n> > > | image                               |\n> > > my-image                             |\n> > > | hostId\n> > > |                                      |\n> > > | OS-EXT-STS:vm_state                 |\n> > > building                             |\n> > > | OS-EXT-SRV-ATTR:instance_name       |\n> > > instance-00000021                    |\n> > > | OS-EXT-SRV-ATTR:hypervisor_hostname |\n> > > None                                 |\n> > > | flavor                              |\n> > > my-baremetal-flavor                  |\n> > > | id                                  |\n> > > c9fd52de-e93e-44dd-9009-9395e964829e |\n> > > | security_groups                     | [{u\'name\':\n> > > u\'default\'}]              |\n> > > | user_id                             |\n> > > 251bd0a9388a477b9c24c99b223e7b2a     |\n> > > | name                                |\n> > > my-baremetal-node                    |\n> > > | adminPass                           |\n> > > 5kHEX46xremR                         |\n> > > | tenant_id                           |\n> > > 8a34123d83824f3ea52527c5a28ad81e     |\n> > > | created                             |\n> > > 2013-10-14T18:08:49Z                 |\n> > > | OS-DCF:diskConfig                   |\n> > > MANUAL                               |\n> > > | metadata                            |\n> > > {}                                   |\n> > > | accessIPv4\n> > > |                                      |\n> > > | accessIPv6\n> > > |                                      |\n> > > | progress                            |\n> > > 0                                    |\n> > > | OS-EXT-STS:power_state              |\n> > > 0                                    |\n> > > | OS-EXT-AZ:availability_zone         |\n> > > nova                                 |\n> > > | config_drive\n> > > |                                      |\n> > >\n> > +-------------------------------------+--------------------------------------+\n> > > root at os:/tftpboot#\n> > >\n> > > Before doing this, I have done the nova-baremetal-create and interface\n> > add,\n> > > and this is what i get:\n> > > ======================================================================\n> > >\n> > > root at os:/tftpboot# nova baremetal-node-create os 1 1024 10\n> > 00:50:56:AA:20:54\n> > > +------------------+-------------------+\n> > > | Property         | Value             |\n> > > +------------------+-------------------+\n> > > | instance_uuid    | None              |\n> > > | pm_address       | None              |\n> > > | interfaces       | []                |\n> > > | prov_vlan_id     | None              |\n> > > | cpus             | 1                 |\n> > > | memory_mb        | 1024              |\n> > > | prov_mac_address | 00:50:56:AA:20:54 |\n> > > | service_host     | os                |\n> > > | local_gb         | 10                |\n> > > | id               | 2                 |\n> > > | pm_user          | None              |\n> > > | terminal_port    | None              |\n> > > +------------------+-------------------+\n> > > root at os:/tftpboot# nova baremetal-interface-add 2 00:50:56:AA:20:54\n> > > +-------------+-------------------+\n> > > | Property    | Value             |\n> > > +-------------+-------------------+\n> > > | datapath_id | 0                 |\n> > > | id          | 2                 |\n> > > | port_no     | 0                 |\n> > > | address     | 00:50:56:AA:20:54 |\n> > > +-------------+-------------------+\n> > >\n> > > The baremetal node is stuck at (initramfs) no auto powering and no auto\n> > > booting happens.\n> > > I have not given --pm options , should i give that and if so what are the\n> > > values?\n> > > What am i missing?\n> >\n> > If you don\'t give the power driver an address and credentials to turn\n> > the machine on and off, you can\'t expect automatic deployment to work.\n> > You will need IPMI credentials and an IP that the compute node can reach\n> > to turn the machine on/off using the IPMI protocol.\n> >\n> > If your machines do not have IPMI, and they are not Tilera based, you\n> > will need to write a power driver to turn them on and off.\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n\n\n','<CAFuk=T0kq=OjMKa2+phXE3-RgMC=VX6WndwgMh4Rhq-xkqLJSw@mail.gmail.com>',NULL),('<1381780811-sup-8684@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 13:04:48',-25200,'2013-10-14 20:04:48',NULL,'[openstack-dev] [Mistral] Announcing a new task scheduling and\n	orchestration service for OpenStack','Excerpts from Renat Akhmerov\'s message of 2013-10-14 12:40:28 -0700:\n> Hi OpenStackers,\n> \n> I am proud to announce the official launch of the Mistral project. At Mirantis we have a team to start contributing to the project right away. We invite anybody interested in task service & state management to join the initiative.\n> \n> Mistral is a new OpenStack service designed for task flow control, scheduling, and execution. The project will implement Convection proposal (https://wiki.openstack.org/wiki/Convection) and provide an API and domain-specific language that enables users to manage tasks and their dependencies, and to define workflows, triggers, and events. The service will provide the ability to schedule tasks, as well as to define and manage external sources of events to act as task execution triggers. \n\nWhy exactly aren\'t you just calling this Convection and/or collaborating\nwith the developers who came up with it?\n\n\n','<49471F16-92EF-4538-98F6-EB7C5D3B351B@mirantis.com>',NULL),('<1381802282.6655.5.camel@willson.li.ssimo.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-14 21:58:02',-14400,'2013-10-15 01:58:02',NULL,'[openstack-dev] Keystone Apache2 Installation Question','On Mon, 2013-10-14 at 14:31 -0700, Fox, Kevin M wrote:\n> Hi Adam,\n> \n> I was trying to get both kerberos negotiate and kerberos basic auth working. Negotiate does not seem to be supported by any of the clients so I think it will be a fair amount of work to get working.\n> \n> /keystone/main/v2.0/tokens can\'t support having an apache auth module on it, it seems because it is overloaded to do too many things. After playing around with it, it looks like some services (like horizon) assume they can give it a token and get back a restricted token without doing basic auth/negotiate all the time. You can\'t put auth around it in apache and Require valid-user and still have it perform its other functions. the tokens endpoint needs to be able to be split out so that you can do something like /auth/<type>/tokens so you can put a different handler on each url and /tokens has all the rest of the functionality. I guess this will have to wait for Icehouse.\n> \n> I also played around with basic auth as an alternative in the mean time to negotiate and ran into that same issue. It also requires changes to not just python-keystoneclient but a lot of the other python-*clients as well, and even then, horizon breaks as described above.\n> \n> I found a work around for basic auth though that is working quite nicely. I\'m trying to get the patch through our legal department, but they are tripping over the contributor agreement. :/\n> \n> The trick is, if you are using basic auth, you only support a username/password anyway and havana keystone is plugable in its handling of username/passwords.\n> \n> So, I\'ll just tell you the idea of the patch so you can work on reimplementing it if you\'d like.\n>  * I made a new file /usr/lib/python2.6/site-packages/keystone/identity/backends/basic_auth_sql.py\n>  * I made a class Identity that inherits from the sql Identity class.\n>  * I overrode the _check_password function.\n>  * I took the username/password and base64 encoded it, then make a http request with it to whatever http basic auth service url you want to validate with. apache on localhost works great.\n>  * Check the result for status 200. You can even fall back to the super class\'s _chck_password to support both basic auth and sql passwords if you\'d like.\n> \n> The interesting bit about this configuration is keystone does not need to be embedded in apache to support apache basic auth, while still providing you most of the flexability of apache basic auth plugins. The only thing that doesn\'t work is REMOTE_USER rewriting. Though you could probably add that feature in somehow using a http response header or something.\n\nIf all you end up using is basic auth, what is the point of using\nKerberos at all ?\n\nBasic Auth should never be used with kerberos except in exceptional\ncases.\n\nSimo.\n\n-- \nSimo Sorce * Red Hat, Inc * New York\n\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C652814BD@EMAIL05.pnl.gov>',NULL),('<1381803644.2581.10.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-15 12:20:44',36000,'2013-10-15 02:20:44',NULL,'[openstack-dev] [keystoneclient] self-signed keystone not\n accessible from other services','On Mon, 2013-10-14 at 18:36 -0700, Bhuvan Arumugam wrote:\n> Just making sure i\'m not the only one facing this problem.\n> https://bugs.launchpad.net/nova/+bug/1239894\n\nYep, we thought this may raise some issues but insecure by default was\njust not acceptable. \n\n> keystoneclient v0.4.0 was released last week and used by all openstack\n> services now. The insecure=False, as defined in\n> keystoneclient.middleware.auth_token. The keystone client is happy as\n> long as --insecure flag is used. There is no way to configure it in\n> other openstack services like nova, neutron or glance while it is\n> integrated with self-signed keystone instance.\n\nI\'m not following the problem. As you mentioned before the equivalent\nsetting for --insecure in auth_token is setting insecure=True in the\nservice\'s config file along with all the other keystone auth_token\nsettings. The equivalent when using the client library is passing\ninsecure=True to the client initialization. \n\n> We should introduce new config parameter keystone_api_insecure and\n> configure keystoneclient behavior based on this parameter. The config\n> parameter should be defined in all other openstack services, as all of\n> them integrate with keystone.\n\nA new config parameter where? I guess we could make insecure in\nauth_token also response to an OS_SSL_INSECURE but that pattern is not\nfollowed for any other service or parameter. \n\n> Until it\'s resolved, I think the known workaround is to use\n> keystoneclient==0.3.2.\n> \n> \n> Is there any other workaround for this issue?\n\nSigned certificates.\n\n> -- \n> Regards,\n> Bhuvan Arumugam\n> www.livecipher.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAK0Yc05ax=FspxFx5VV1_bVjMSKXtdJ8LnMhRX3UXj601gvPew@mail.gmail.com>',NULL),('<1381854019.948619504@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-10-15 11:20:19',-18000,'2013-10-15 16:20:19',NULL,'[openstack-community] Interested in helping at the OpenStack booth at LinuxCon/CloudOpen Europe?','\nWe have a small booth at this Edinburgh event, open Monday-Tuesday, Oct 21-22.  Folks from NetApp and Red Hat have volunteered, thank you.  If you\'re going, or interested in attending, OpenStack booth duty is really fun.  You meet very interested people with questions ranging from \"how do I get started\" to detailed implementation conversations. We welcome additional volunteers!  Please reply to Shari Mahrdt, shari at openstack.org,  and me if interested.  We will provide full conferences passes so you can attend keynotes and sessions as well.  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131015/d94075e9/attachment.html>\n\n',NULL,NULL),('<1381913241.20133.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-16 09:47:21',3600,'2013-10-16 08:47:21',NULL,'[Openstack-operators] OpenvSwitch Latency issues','Jacob,\n\nwhat operating and kernel are you using?\nwhat ovs datapath (dpkg -l openv\\*) ?\nwhat version of openstack?\n\nMaybe it is an issue getting in and/or out of the router namespace. Try running tcpdump on the qr-xxxxxx-xx (from namespace) and the physical interface in br-ex (from root namespace), and do a ping from namespace to outside. Then compare the timestamps on the two tcpdumps. Then try a ping from outside to in.\n\n\nJame Page reported a router performance issue recently, and setting ovs_use_veth=true somehow fixed it.\n\nhttp://lists.openstack.org/pipermail/openstack/2013-October/001811.html\n\n\nRe, Darragh.\n\n\n\n',NULL,NULL),('<1381924490.4835.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-16 12:54:50',3600,'2013-10-16 11:54:50',NULL,'[Openstack] Introducing \"Show my network state\" utility','Hi Giuliano,\n\ngreat idea and nice work. I haven\'t tried it yet as I guess I would need to install X-Windows on servers. Also having to add a sudoers entry makes it less convenient too.\n\nIt would be great if you could write a non-graphical helper program that could be called by sudo and it would run all the network commands and save them to a file (text - xml or json preferrably). Then the file could be copied to a laptop and opened with the gui program. Just like you can use -w with tcpdump and open the output file with WireShark. Then people would be able to quickly wget the script/program, run it, and upload the file somewhere. Then others could download the file and open it with the gui, to help diagnose a problem.\n\n\nRe, Darragh.\n\n> Hi all!\n> I\'ve made a simple network utility and I\'d like to share it with the\n> community!\n> It\'s called \"Show my network state\" and it\'s a graphical network topology\n> visualizer for a single host.\n> I made it to simplify the network management of Openstack nodes. All that\n> OVS bridges, veth pairs and patch ports were simply a mess to read from\n> command line so I decided to realize \"visual dashboard\" to show them all.\n> The code is BSD licensed and hosted on GITHUB.\n> \n> \n> Please let me know if you find it useful!\n> I\'d also like to receive some feedback, errors, etc.\n> \n> The Website is the following:\n> https://sites.google.com/site/showmynetworkstate/\n> \n> \n> Giuliano\n\n\n',NULL,NULL),('<1381926174.23890.162.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-16 08:22:54',-14400,'2013-10-16 12:22:54',NULL,'[Openstack-docs] Havana nova install - success','On Wed, 2013-10-16 at 17:43 +1100, Tom Fifield wrote:\n> Hi,\n> \n> I am confirming success with the havana nova install instructions on \n> ubuntu 12.04\n> \n> * Nova-network multi-host does not work with nova-conductor, and so \n> needs database configuration. Credit: Sina Sadeghi, Joe Topjian\n> \n> https://review.openstack.org/#/c/52010/\n\nShould we not even run nova-conductor then? Does anything talk to it if\nthe compute nodes don\'t?\n\n--\nShaun\n\n\n\n\n','<525E3588.7010705@openstack.org>',NULL),('<1381947231.68461.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-16 19:13:51',3600,'2013-10-16 18:13:51',NULL,'[Openstack-docs] Havana Install - Neutron chapter','\n\nI can test the steps on Ubuntu as I have a script that can auto install everything else. Let me know which plugin to do.\n\n\nRe, Darragh.\n\n\n',NULL,NULL),('<1381947391.78228.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-16 19:16:31',3600,'2013-10-16 18:16:31',NULL,'[Openstack-docs] Havana Install - Neutron chapter','\n\nI can test the steps on Ubuntu as I have a script that can auto install everything else. Let me know which plugin to do.\n\nRe, Darragh.\n\n\n\n',NULL,NULL),('<1381949217-sup-1046@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-16 12:02:13',-25200,'2013-10-16 19:02:13',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Zane Bitter\'s message of 2013-10-16 06:16:33 -0700:\n> On 16/10/13 00:48, Steve Baker wrote:\n> > I\'ve just written some proposals to address Heat\'s HOT software\n> > configuration needs, and I\'d like to use this thread to get some feedback:\n> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config\n> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config\n> \n> Wow, nice job, thanks for writing all of this up :)\n> \n> > Please read the proposals and reply to the list with any comments or\n> > suggestions.\n> \n> For me the crucial question is, how do we define the interface for \n> synchronising and passing data from and to arbitrary applications \n> running under an arbitrary configuration management system?\n> \n> Compared to this, defining the actual format in which software \n> applications are specified in HOT seems like a Simple Matter of \n> Bikeshedding ;)\n> \n\nAgreed. This is one area where juju excels (making cross-node message\npassing simple). So perhaps we should take a look at what works from the\njuju model and copy it.\n\n> (BTW +1 for not having the relationships, hosted_on always reminded me \n> uncomfortably of INTERCAL[1]. We already have DependsOn for resources \n> though, and might well need it here too.)\n>\n\nAlso agreed. The way the new proposal has it, it feels more like\ncomposing a workflow.\n\n> I\'m not a big fan of having Heat::Puppet, Heat::CloudInit, Heat::Ansible \n> &c. component types insofar as they require your cloud provider to \n> support your preferred configuration management system before you can \n> use it. (In contrast, it\'s much easier to teach your configuration \n> management system about Heat because you control it yourself, and \n> configuration management systems are already designed for plugging in \n> arbitrary applications.)\n> \n\nAlso agree. Having Heat know too much about anything that has many\nimplementations is a bit of a layer violation. Heat has an interface,\nand we should make it really easy for the popular tools to consume\nsaid interface. I could see us having a separate set of shims, like\nheat-puppet, and heat-salt, that are helpers for those systems to consume\ndata from Heat more smoothly.\n\n> I\'d love to be able to put this control in the user\'s hands by just \n> using provider templates - i.e. you designate PuppetServer.yaml as the \n> provider for an OS::Nova::Server in your template and it knows how to \n> configure Puppet and handle the various components. We could make \n> available a library of such provider templates, but users wouldn\'t be \n> limited to only using those.\n> \n\nThis I don\'t think I understand well enough to pass judgement on. My\nunderstanding of providers is that they are meant to make templates more\nportable between clouds that have different capabilities. Mapping that\nonto different CM systems feels like a stretch and presents a few\nquestions for me. How do I have two OS::Nova::Server\'s using different\nCM systems when I decide to deploy something that uses salt instead of\nchef?\n\nAs long as components can be composed of other components, then it seems\nto me that you would just want the CM system to be a component. If you\nfind yourself including the same set of components constantly.. just\nmake a bigger component out of them.\n\n\n','<525E91B1.4090106@redhat.com>',NULL),('<138197A8-FEC4-4213-BEE8-DA3CCACC5A5D@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 16:56:01',-18000,'2014-11-19 21:56:01',NULL,'[openstack-dev] [Neutron] DB: transaction isolation and related\n	questions','\n> On Nov 19, 2014, at 4:14 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> \n> One simply cannot rely on multi-statement transactions to always succeed.\n\nagree, but the thing you want is that the transaction either succeeds or explicitly fails, the latter hopefully in such a way that a retry can be added which has a chance at succeeding, if needed.  We have transaction replay logic in place in nova for example based on known failure conditions like concurrency exceptions, and this replay logic works, because it starts a new transaction.   In this specific case, since it?s looping within a transaction where the data won?t change, it?ll never succeed, and the retry mechanism is useless.   But the isolation mode change won?t really help here as pointed out by Jay; discrete transactions have to be used instead.\n\n\n\n','<1416431412-sup-6582@fewbar.com>',NULL),('<1381991248-sup-6600@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-16 23:32:22',-25200,'2013-10-17 06:32:22',NULL,'[openstack-dev] [Heat]Blueprint for retry function with\n	idenpotency in Heat','Excerpts from Mitsuru Kanabuchi\'s message of 2013-10-16 04:47:08 -0700:\n> \n> Hi all,\n> \n> We proposed a blueprint that supports API retry function with idenpotency for Heat.\n> Prease review the blueprint.\n> \n>   https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency\n> \n\nThis looks great. It addresses some of what I\'ve struggled with while\nthinking of how to handle the retry problem.\n\nI went ahead and linked bug #1160052 to the blueprint, as it is one that\nI\'ve been trying to get a solution for.\n\nI took the liberty of targeting your blueprint at icehouse. If you don\'t\nthink it is likely to get done in icehouse, please raise that with us at\nthe weekly meeting if you can and we can remove it from the list.\n\nNote that there is another related blueprint here:\n\nhttps://blueprints.launchpad.net/heat/+spec/retry-failed-update\n\n\n','<20131016204708.021c1ca19c87e02e18271656@po.ntts.co.jp>',NULL),('<1381993160-sup-9322@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-17 00:00:11',-25200,'2013-10-17 07:00:11',NULL,'[Openstack] six dependencies for nova and keystone client','Excerpts from Sam Morrison\'s message of 2013-10-16 21:06:41 -0700:\n> It looks like there is an issue with six with havana nova (milestone-proposed).\n> \n> Nova has: \n> six<1.4.0\n\nhavana global requirements is >=1.4.1, so nova is in error here.\n\nIt needs to be fixed to be in sync with the global requirements.\n\n\n','<12810B7F-B106-43AD-B0F1-9973776D7F55@gmail.com>',NULL),('<1382032771-sup-9615@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 11:06:33',-25200,'2013-10-17 18:06:33',NULL,'[openstack-dev] Building on Debian: Havana unit tests at build\n	time report','Excerpts from Thomas Goirand\'s message of 2013-10-17 00:16:22 -0700:\n> Hi,\n> \n> As you know, I maintain OpenStack both for Debian Sid, and a backport\n> for Wheezy (non-official) repository (since using the backports\n> repository for OpenStack wouldn\'t be practical). Below is the result of\n> the building OpenStack Havana (latest RC) under both these environments.\n> \n> I would really appreciate if people from each of the concerned projects\n> could pay attention to this report, and provide fixes. It doesn\'t have\n> to be merged into the final release (I of course understand that we are\n> running out of time), though if there\'s a proposed patch, even if it\'s\n> not yet merged and still with \"work in progress\" status, that\'s fine for\n> me. I can use in a Debian specific patch (under debian/patches), and\n> upload later on.\n> \n> Another thing which struck me: OpenStack really works well in Sid, even\n> with SQLAlchemy 0.8.2, apart from this Nova glitch which *must* be\n> fixed. I really hope someone will come with a patch for it.\n> \n> I\'d like also to point out that if I am publishing this report, it\n> really is because I expect others to work on it. Remember that I\'m alone\n> doing the Debian packaging work (as opposed to a full team for Ubuntu),\n> and that you cannot expect that *I* fix (all) things. I simply don\'t\n> have enough time to work on it myself, unfortunately. So help wanted... :)\n> \n> Last thing: please test and use Debian (Sid or my Wheezy backport\n> repository) for OpenStack!\n> \n\nA link to instructions on setting up a wheezy box for this testing would\nbe helpful.\n\n> * Heat\n> ======\n> \n> No unit test failure / error (in both Sid and Wheezy). However, Heat\n> doesn\'t include a -P option in ./run_tests.sh, and insists on running\n> the PEP8 checks, which fails because Sid has pyflakes 0.7.3, and Heat\n> wants 0.7.2:\n> \n\nrun_tests.sh is there for _your_ convenience. And by you I mean\npackagers and others who want to run the tests with system python.\n\nIMO you\'d be better off adding a --no-venv option to tox to run the\nprescribed commands with system python, or even just parsing tox.ini to\ndo that yourself. You\'ll find that the commands in tox.ini are better\nmaintained, since they are gated.\n\nAnyway, I\'d gladly accept a patch to add -P.\n\n> pkg_resources.VersionConflict: (pyflakes 0.7.3\n> (/usr/lib/python2.7/dist-packages), Requirement.parse(\'pyflakes==0.7.2\'))\n> \n> I had the same problem with Sid, with the PEP8 1.4.4 which I maintain as\n> backport (and Heat expects 1.4.5). I could work it out, though I don\'t\n> think it\'s worse the trouble (as it will not change the useability of\n> the package), so I just gave up on it.\n> \n> Also, heat uses /usr/bin/coverage. Please switch to python -m coverage\n> (IMO, the best way...), or check if /usr/bin/coverage and if not, use\n> /usr/bin/python-coverage.\n\nI appreciate this message, however, the bug tracker is over there ->\nhttps://bugs.launchpad.net/heat/+filebug\n\n\n','<525F8EC6.3050101@debian.org>',NULL),('<1382037160.033316912@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 15:12:40',-14400,'2013-10-17 19:12:40',NULL,'[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs\n	in Nova','I don\'t oppose having the version autodiscovered. But I do feel the option should be available to override if desired. I\'ve had many problems with over the years with autoconfiguring systems not doing what I need to be willing to depend on them 100% without a manual override available if at all possible. I\'m thinking particularly for testing or upgrade evaluation scenarios. For example, you want to turn on v2 in glance and evaluate it for a bit before committing to using it for all of your nova nodes.\n\nThe current patch also had a couple of comments from Dan Prince and Chris Behrens early on when this was brought up there supporting the use of a config value.\n\nFrom the implementation side of things, to do this properly would require some changes to the glanceclient to allow querying of available versions. Lacking that ability currently is one reason this is currently a config value. Once the client supports this, the nova side change would likely be quite small.\n\nMight I propose a compromise?\n\n1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted.\n\n2) Immediately file two blueprints:\n   - python-glanceclient - expose a way to discover available versions\n   - nova - depends on the glanceclient bp and allowing autodiscovery of glance version\n            and making the config value optional (tho not deprecated / removed)\n\nThanks,\n\nEddie Sheffield\n\n-----Original Message-----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nSent: Thursday, October 17, 2013 2:00pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova\n\nThe following blueprint has been proposed for Nova:\n\n    https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api\n\nIt proposes a new config option for Nova to allow choosing whether Nova\nshould use v1 or v2 of the Glance API.  I\'d like to know if we can do\nthis without a config option.\n\nCan Nova just discover which versions and pick one (v2) ?  And if you\ndon\'t like the way Nova picks one, a deployer can just only expose one\nof the APIs on the API endpoint that Nova uses.\n\nThoughts?\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<526025D9.8000108@redhat.com>',NULL),('<1382038375-sup-7935@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 12:35:17',-25200,'2013-10-17 19:35:17',NULL,'[openstack-dev] RFC: Freeze deps versions in requirements (was\n	[tripleo], but that\'s a general topic)','Excerpts from Thomas Goirand\'s message of 2013-10-17 08:33:44 -0700:\n> See above. Also, remember that package maintainers are a few (me alone\n> for Debian, maybe 5 people in Ubuntu/Canonical) fighting hundreds of\n> developers who wish not to be disturbed. However, in this particular\n> case, the majority isn\'t always right. ;)\n> \n\nIt makes me sad that you feel this is a fight.\n\nWe (developers of OpenStack) want users to find and use OpenStack. You\nare one of the many channels by which they do that. So please, it is not\na fight, it is a dialog between peers.\n\n> *I* do not control all of the version of Python modules that gets into\n> Debian (I\'m not sure if I should add \"luckily\" or \"unfortunately\" ...).\n> \n\nThe hard work of integration is making things work with what you have.\nWe will do everything we can to stabilize the requirements as quickly as\npossible. But sometimes its just not going to align with the distro\nmodel. I think you\'ve done a fine job, and I think OpenStack in general\nhas been responsive to your feedback.\n\n\n','<52600358.4030206@debian.org>',NULL),('<1382054130.96312066@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 19:55:30',-14400,'2013-10-17 23:55:30',NULL,'[openstack-dev] [Glance] async workers interface design.','\nHi all,\n \nThere seem to be varying ideas about the worker interface design for our blueprint [https://blueprints.launchpad.net/openstack/?searchtext=async-glance-workers] async-glance-workers. Fei and Zhi already have posted detailed comments on [https://review.openstack.org/#/c/46117/21] https://review.openstack.org/#/c/46117/21 (PS 21). Venkatesh, Alex and I have worked on it at varying periods of times and brainstormed different ideas as well. I know Zhi is also, very interested in the design and making it as configurable as possible.\n \nRecently, a patch has been uploaded to [https://review.openstack.org/#/c/46117] https://review.openstack.org/#/c/46117 giving a direction to the interface we\'r hoping to achieve. The following are some of the high level pros and cons to this approach which we would like to discuss in the upcoming sync up(s) on #openstack-glance :-\n \nPros:\nEstablishes clear distinction between an executor and a script (or script package)\neg. executor can be of type eventlet or rpc and script  (or script package) can be of type import/export/clone\nEstablishes a good understanding of the contract between Glance and script packages\nGives the deployer the ability to keep their script packages as simple as possible or even add complexity to them if needed without marrying such script packages with Glance code.\nA standard way of invoking asynchronous tasks via Glance.\nCons:\nNot all script packages would be supported by Glance.\nThere would be no modules which include classes like TaskImportScript, TaskExportScript within Glance domain logic- if they are needed for some sort of inheritance. However, the script packages themselves can have them and be as extensible as it gets.\n(Trying to use the word \"script packages\" as I\'m trying to help understand that they would even be configurable using stevedore and be something similar to the example package given [https://github.com/dreamhost/stevedore/tree/master/stevedore/example] here. If using stevedore, they would have their own setup file and namespace defined.) \n \nAll the script_packages would be having a standard module say named as \"main\" - which Glance task executor calls and initiates the execution. (\"main\" can be analogous to the python [https://github.com/dreamhost/stevedore/blob/master/stevedore/example/load_as_extension.py] script given in the above example or can even be a simple script which runs the task)  Glance provides access to it\'s code on contractual basis - viz. the params that would be passed in are defined at the executor level. For example - in case of import we seem to need db_api, store_api, notifier_api, task_id, req.context. These can be used to invoke calls from within Glance modules like sqlalchemy/api or notifier/api etc. From this point on, it\'s responsibility of the script to achieve the result it needs. This design seem to fit in the requirements which many people have posted in the review comments without adding too many configuration options within glance; keeping it maintainable as well.\n \nAnother idea about the interface design which Zhi layed-out is linked below. I have browsed through it however, am not completely familiar with the design\'s end goal. Would like to do a differential analysis sometime soon.\n[http://paste.openstack.org/show/48644/] http://paste.openstack.org/show/48644/\n \nYour opinions are very welcome!\n \nIf you prefer, please try to sync up with us on the #openstack-glance channel while we try to fit the design as per the use cases.\nThanks,\n-Nikhil\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131017/d9b5f032/attachment.html>\n\n',NULL,NULL),('<1382058730-sup-4257@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 18:16:12',-25200,'2013-10-18 01:16:12',NULL,'[openstack-dev] Change in openstack/heat[master]: Implement a\n	Heat-native resource group','Excerpts from Mike Spreitzer\'s message of 2013-10-17 17:19:58 -0700:\n> What is the rationale for this new feature?  Since there is already an \n> autoscaling group implemented by Heat, what is the added benefit here? And \n> why is it being done as another heat-native thing rather than as an \n> independent service (e.g., as outlined in \n> https://wiki.openstack.org/wiki/Heat/AutoScaling for an autoscaling group \n> service)?\n\nThis supports that design quite well.\n\nThe point is to be able to group and clone any resource, not just\nserver/instance. So autoscaling might be configured to manage a group\nof Trove database instances which are then fed as a list to a group of\nseparately autoscaled webservers.\n\n\n','<OF58A97803.208256E5-ON85257C08.000153B3-85257C08.0001D46A@us.ibm.com>',NULL),('<1382065758-sup-6954@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-17 20:29:34',-25200,'2013-10-18 03:29:34',NULL,'[openstack-dev] [Heat] Plugin to use Docker containers a\n	resources in a template','Excerpts from Sam Alba\'s message of 2013-10-17 18:06:04 -0700:\n> Hi all,\n> \n> I\'ve been recently working on a Docker plugin for Heat that makes it\n> possible to use Docker containers as resources.\n> \n> I\'ve just opened the repository:\n> https://github.com/dotcloud/openstack-heat-docker\n> \n> It\'s now possible to do that via Nova (since there is now a Docker\n> driver for it). But the idea here is not to replace the Nova driver\n> with this Heat plugin, the idea is just to propose a different path.\n> \n> Basically, Docker itself has a Rest API[1] with all features needed to\n> deploy and manage containers, the Nova driver uses this API. However\n> having the Nova API in front of it makes it hard to bring all Docker\n> features to the user, basically everything has to fit into the Nova\n> API. For instance, docker commit/push are mapped to nova snapshots,\n> etc... And a lot of Docker features are not available yet; I admit\n> that some of them will be hard to support (docker Env variables,\n> Volumes, etc... how should they fit in Nova?).\n> \n\nAgreed, I never thought docker was an excellent fit at the nova driver\nlevel. It certainly seems useful, but not necessarily excellent.\n\n> The idea of this Docker plugin for Heat is to use the whole Docker API\n> directly from a template. All possible parameters for creating a\n> container from the Docker API[2] can be defined from the template.\n> This allows more flexibility.\n>\n\nI just looked through the README and examples quickly, and it is\nfantastic. I think this is a nice example of how to integrate\na non-OpenStack component into a Heat template.\n\nI have some thoughts on next steps:\n\n1) Consider moving it to Heat\'s contrib directory. Being gated and wrapped\nin OpenStack procedures means you will get more OpenStack contribution. Of\ncourse, if your community is more at home where the repo is, then leave\nit there. We don\'t _need_ plugins to be in contrib.\n\n2) Docker.handle_delete will fail in glorious fashion if you have deleted\nthe container already from outside. We follow a general paradigm where\nif the underlying components of the resource are not found, consider that\n\"success\" and exit the handle_delete method. This also helps if a delete\nfailed in some other way and you are retrying the delete.\n\n3) Would be really cool to also have a traditional Heat template that\none can nest for deploying docker itself on an OS::Nova::Server. Combine\nthat with the random string generator for passwords and you can have a\nfully automatic Heat controlled deployment of docker things.\n\n> Since this approach is a bit different from the normal OpenStack\n> workflow (for instance, Nova\'s role is to abstract all computing units\n> right now), I am interested to get feedback on this.\n> \n\nThis isn\'t all that far off from what an OS::Trove::Database resource\nwould be. You are encapsulating another management tool that simplifies\na common task and gives it an API into a resource to relieve people of\nthe need to repeat all of the API orchestration that they would have to\ndo in-server.\n\n\n','<CAJv9qeTSU07P-Rb39efLaYpQTuG8qH_OGQeF66_759G6cwjc+w@mail.gmail.com>',NULL),('<1382112784.2360.28.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-18 18:13:04',7200,'2013-10-18 16:13:04',NULL,'[openstack-dev] [Metrics] Improving the data about\n contributor/affiliation/time','On Fri, 2013-10-18 at 08:33 -0400, Sean Dague wrote:\n> On 10/17/2013 05:34 PM, Stefano Maffulli wrote:\n> > [...]\n> > Four sources of data for this reporting is bad and not sustainable.\n> >\n> > Since it seems commonly accepted that all developers need to be members\n> > of the Foundation, and that Foundation members need to state their\n> > affiliation when they join and keep such data current when it changes, I\n> > think the Foundation is in a good place to provide the authoritative\n> > data for all projects to use.\n> \n> I\'m not sure it is well understoond that all members have to join the \n> foundation. We don\'t make that a requirement on someone slinging a \n> patch. It would be nice to know what percentage of ATCs actually are \n> foundation members at the moment (presumably that number is easy to \n> generate?)\n\nMy impression is that we need a data source that covers all contributors\nas much as possible. As you said, even for developers it is not always\nthe case. If you are also interested in tracking bug reporters or\nmessage posters, for example, that is even less the case. Linking\naffiliation information to Foundation membership could be risky from\nthis point of view.\n\nA different issue is that the Foundation maintains a system for claiming\nor fixing affiliation information, so that all of us producing metrics\ncan use it. It could be based on the current datasets (the best of them,\nor maybe a combination of some of them), and could provide some\ninterface for easy and public proposal of changes. It should also\nprovide some interface so that any metrics collecting system can use it.\n\nFor being useful, it should also include data for identification of\ndevelopers (usually, the email addresses they are using in the different\nOpenStack repositories), since developers not only change organization,\nthey also tend to change identification from time to time.\n\n> The thing is, the Foundation data currently seems to be the least \n> accurate of all the data sets. Also, the lack of affiliation over time \n> is really a problem for this project, especially if one of the driving \n> factors for so much interest in statistics comes from organizations \n> wanting to ensure contributions by their employees get counted. A \n> significant percentage of top contributors to OpenStack have not \n> remained at a single employer over their duration to contributing to \n> OpenStack, and I expect that to be the norm as the project ages.\n> \n> Also, both gitdm and stackalytics have active open developer communities \n> (and they are open source all the way down, don\'t need non open \n> components to run), so again, I\'m not sure why defaulting to the least \n> open platform makes any sense.\n\nJust for the record, the MetricsGrimoire / vizGrimoire stack that is\nproducing the dashboards at http://activity.openstack.org/dash/ is also\ncomplete open source, with an open developer community, see\nhttp://metricsgrimoire.github.io and http://vizgrimoire.github.io\n\nAll the data is also available, in the form of JSON files and SQL\ndatabases, see\nhttp://activity.openstack.org/dash/newbrowser/browser/data/db/\n(which includes affilation data)\n\nThis said, I\'m not intending that our affiliation datasets are the best\nones. We\'d be more than happy to collaborate with the rest to produce a\ncommon dataset, or to revert to some other if it proves better\nmaintained. In fact, we have already incorporated affiliation data from\ngitdm and (partially) from stackalytics.\n\n> Member affiliation in the Foundation database can also only be fixed by \n> the individual. In the other tools people in the know can fix it. It \n> means we get a wikipedia effect in getting the data more accurate, as \n> you can fix any issue you see, not just your own.\n\nThis is something very important, from my point of view. The ability of\nchanging any data you may find inaccurate, along with the use of a\nreview system, just to ensure that we don\'t include malicious requests\nfor change, would be desired features for any system we use.\n\n> If the foundation member database was it\'s own thing, had a REST API to \n> bulk fetch, and supported temporal associations, and let others propose \n> updates to people\'s affiliation, then it would be an option. But right \n> now it seems very far from being useful, and is probably the least, not \n> most, accurate version of the world.\n[...]\n\n>From my point of view, having a REST API would be helpful, but not a\nmust. The usual way to include bulk data for us is to retrieve the\nexternal bulk data, compare it with the current we have, and decide (in\npart by hand) on the differences one by one, trying to incorporate the\nmost reliable option. If the external data were always more reliable, it\nwould be a matter of just comparing and using the external data when a\nmatch is found, and could be done automatically. And no REST data is\nreally needed for this.\n\nSupport of temporal associations, proposal of updates by anyone, review\nsystem, and support for multiple identites, would be very convenient.\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<52612AB0.7040800@dague.net>',NULL),('<1382172308-sup-8612@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-19 01:52:04',-25200,'2013-10-19 08:52:04',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n	OpenStack projects (and [trove]\n	python-troveclient_0.1.4-1_amd64.changes REJECTED)','Excerpts from Thomas Goirand\'s message of 2013-10-18 23:01:50 -0700:\n> \n> Hi there,\n> \n> TroveClient just got rejected by Debian FTP masters. Reply from Luke\n> Faraone is below.\n> \n> In general, I would strongly advise that a clean COPYRIGHT-HOLDER file\n> is created with the copyright holders in them. Why? Because it is hard\n> to distinguish between authors and copyright holders, which are very\n> distinct things. Listing the authors in debian/copyright doesn\'t seem to\n> satisfy the FTP masters as well... :(\n> \n> FYI, my reply was that I knew some of the authors were working for\n> Rackspace, because I met them in Portland, and that I knew Rackspace was\n> one of the copyright holders. Though that\'s of course not enough for the\n> Debian FTP masters.\n> \n> Your thoughts?\n\nRecently there was a movement to remove the copyright headers from all\nthe files in OpenStack. Some folk disagreed with this movement, and the\ncompromise was that they were discouraged but allowed.\n\nNobody who writes code wants to hear that they have to think about\nlicensing, copyrights, etc. But at a bare minimum, copyrights should be\nasserted somewhere in each project\'s repository.\n\nNow, some people will say \"thats what we have git for\". I suggest to\nthose who would suggest we just trust git commit logs that this is\nnot sufficient. For instance, I submit code with my personal email\naddress, even though it is all work-for-hire and thus sending copyrights\nto HP rather than me individually.\n\nI suggest that we just put Copyright headers back in the source files.\nThat will make Debian\'s licensecheck work fairly automatically. A single\nfile that tries to do exactly what debian/copyright would do seems a bit\nodd.\n\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n> -------- Original Message --------\n> Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED\n> Date: Sat, 19 Oct 2013 04:00:19 +0000\n> From: Luke Faraone <ftpmaster at ftp-master.debian.org>\n> To: PKG OpenStack <openstack-devel at lists.alioth.debian.org>, Thomas\n> Goirand <zigo at debian.org>\n> \n> \n> Dear maintainer,\n> \n> debian/copyright is **not** an AUTHORS list. This package appears to be\n> Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some\n> other\n> companies, not copyrighted each individual employee at HP who worked on it.\n> \n> Your automated debian/copyright generation is most probably suboptimal for\n> most packages, and is most certainly not a substitute for manual review.\n> One\n> missed copyright holder:\n> \n> python-troveclient-0.1.4\\troveclient\\base.py:\n>     Copyright 2010 Jacob Kaplan-Moss\n> \n> Cheers,\n> \n> Luke Faraone\n> FTP Team\n> \n> \n> ===\n> \n> Please feel free to respond to this email if you don\'t understand why\n> your files were rejected, or if you upload new files which address our\n> concerns.\n> \n\n\n','<5262204E.1010108@debian.org>',NULL),('<138220855.687531.1402588894056.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 18:01:34',7200,'2014-06-12 16:01:34',NULL,'[openstack-dev] Import errors in tests are not reported in\n python 2.7','> On 06/12/2014 10:32 AM, Thomas Herve wrote:\n> > Hi all,\n> > \n> > I don\'t know if it\'s a know issue or not, but I noticed on one of my patch\n> > (https://review.openstack.org/#/c/99648/) that the 2.7 gate was passing\n> > whereas the 2.6 is failing because of import errors. It seems to be a\n> > problem related to the difference in the discover module, so presumably an\n> > issue in testtools. The problem appears locally when using tox, so it\'s\n> > fairly annoying not to be able to trust the test result.\n> > \n> > Thanks,\n> > \n> \n> I\'m actually really confused by the testr commands that are generated\n> here -\n> http://logs.openstack.org/48/99648/2/check/gate-heat-python27/aa8fead/console.html\n> \n> vs. what you see in a Nova unit test run.\n> \n> Is there some particular wrappers you have kicking off in the unit tests?\n\nHum, not that I know. Our tox.ini does \"python setup.py testr --slowest\"\n\n--\nThomas\n\n\n','<5399C80F.6050503@dague.net>',NULL),('<1382337369.4715.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-10-21 07:36:09',3600,'2013-10-21 06:36:09',NULL,'[openstack-tc] Icehouse TC opening','On Sun, 2013-10-20 at 16:00 +0100, Monty Taylor wrote:\n\n> Ok. I\'m counting this as lazy consensus. April has responded that they\n> have a private wine room we can use and it fits up to 18 - so if a few\n> of us have partners, then great (please still RSVP) I\'m going to grab it\n> for 8pm. It\'ll be a tasting menu - so if, when you RSVP to me, you can\n> list any food alergies or dietary restrictions, that would be great (I\n> know some of you have some, but I do not remember what they are)\n\nSounds great Monty, count me in\n\nMark.\n\n\n\n','<5263F004.9040908@inaugust.com>',NULL),('<1382348014.2628.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-21 10:33:34',3600,'2013-10-21 09:33:34',NULL,'[Openstack] Neutron ML2 plugin Ubuntu package?','\n\nis there a Ubuntu package for the Neutron ML2 plugin? I can\'t find it in the Havana cloud-archive on Precise.\n\nvagrant at precise64:/$ cat /etc/apt/sources.list.d/cloudarchive-havana.list \ndeb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/havana main\ndeb-src http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/havana main\n\nvagrant at precise64:/$ apt-cache search neutron | grep -i ml2\nvagrant at precise64:/$\n\nvagrant at precise64:/$ apt-cache search neutron-plugin\nneutron-plugin-bigswitch - Neutron is a virtual network service for Openstack - BigSwitch plugin\nneutron-plugin-brocade - Neutron is a virtual network service for Openstack - Brocade plugin\nneutron-plugin-cisco - Neutron is a virtual network service for Openstack - Cisco plugin\nneutron-plugin-hyperv - Neutron is a virtual network service for Openstack - Hyper-V plugin\nneutron-plugin-linuxbridge - Neutron is a virtual network service for Openstack - linuxbridge plugin\nneutron-plugin-linuxbridge-agent - Neutron is a virtual network service for Openstack - linuxbridge plugin agent\nneutron-plugin-metaplugin - Neutron is a virtual network service for Openstack - Metaplugin plugin\nneutron-plugin-metering-agent - Neutron is a virtual network service for Openstack - metering plugin\nneutron-plugin-midonet - Neutron is a virtual network service for Openstack - Midonet plugin\nneutron-plugin-mlnx-agent - Neutron is a virtual network service for Openstack - mlnx plugin agent\nneutron-plugin-nec - Neutron is a virtual network service for Openstack - NEC plugin\nneutron-plugin-nec-agent - Neutron is a virtual network service for Openstack - NEC plugin agent\nneutron-plugin-nicira - Neutron is a virtual network service for Openstack - Nicira plugin\nneutron-plugin-openvswitch - Neutron is a virtual network service for Openstack - Open vSwitch plugin\nneutron-plugin-openvswitch-agent - Neutron is a virtual network service for Openstack - Open vSwitch plugin agent\nneutron-plugin-plumgrid - Neutron is a virtual network service for Openstack - PLUMgrid plugin\nneutron-plugin-ryu - Neutron is a virtual network service for Openstack - RYU plugin\nneutron-plugin-ryu-agent - Neutron is a virtual network service for Openstack - RYU plugin agent\nneutron-plugin-vpn-agent - Neutron is a virtual network service for Openstack - vpn plugin\n\n\nI installed neutron-server thinking that it should now default to ml2, but it is ovs:\n\nvagrant at precise64:/$ cat /etc/default/neutron-server\n# defaults for neutron-server\n# path to config file corresponding to the core_plugin specified in\n# neutron.conf\nNEUTRON_PLUGIN_CONFIG=\"/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini\"\n\nAny ideas?\n\nThanks,\nDarragh.\n\n\n\n',NULL,NULL),('<1382362109.4715.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 14:28:29',3600,'2013-10-21 13:28:29',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Sat, 2013-10-19 at 08:24 -0400, Monty Taylor wrote:\n> \n> On 10/19/2013 05:49 AM, Michael Still wrote:\n> > On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > \n> >> I suggest that we just put Copyright headers back in the source files.\n> >> That will make Debian\'s licensecheck work fairly automatically. A single\n> >> file that tries to do exactly what debian/copyright would do seems a bit\n> >> odd.\n> >\n> > The problem here is that the copyright headers were wrong. They aren\'t\n> > religiously added to, and sometimes people have tried to \"gift\" code\n> > to the Foundation by saying the code is copyright the Foundation,\n> > which isn\'t always true. So, we can\'t lean on these headers for\n> > accurate statements of copyright.\n> \n> This is correct. As with many things that are harder for us than for\n> other people, we have >=1000 developers and the history thus-far has\n> been for people to be rather antagonistic and annoyed when someone tries\n> to suggest proper copyright attribution.\n> \n> What we CAN say is that every single commit is Apache licensed. Our CLA\n> and enforcement of it, sad as this statement makes me, ensures that we\n> know that.\n\nRight. We work hard to ensure that all copyright holders license their\ncontribution under the Apache License. A CLA isn\'t the only way of doing\nthis, but it\'s what we do now.\n\n> I\'m not sure what to do re: FTP masters. Could someone expand for me\n> like I\'m an idiot what the goal they are trying to achieve is? I _think_\n> that they\'re trying to make sure that the code is free software and that\n> it is annotated somewhere that we know this to be true, yeah? Is there\n> an additional thing being attempted?\n\nIn other words, what exactly is a list of copyright holders good for? It\ndoesn\'t affect the license and there\'s no requirement under the Apache\nLicense for Debian to credit the copyright holders.\n\nIt would be really silly of us to burden ourselves with maintaining\nlists of copyright holders if no-one can explain how it helps anything.\n\nMark.\n\n\n\n','<52627A10.3090407@inaugust.com>',NULL),('<1382374522.11346346.1391202213151.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 16:03:33',-18000,'2014-01-31 21:03:33',NULL,'[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous\n hardware support','So after reading the replies on this thread, it seems like I (and others advocating\na custom scheduler) may have overthought things a bit.  The reason this route was\nsuggested was because of conflicting goals for Icehouse:\n\na) homogeneous nodes (to simplify requirements)\nb) support diverse hardware sets (to allow as many users as possible to try Tuskar)\n\nOption b) requires either a custom scheduler or forcing nodes to have the same attributes,\nand the answer to that question is where much of the debate lies.\n\nHowever, taking a step back, maybe the real answer is:\n\na) homogeneous nodes\nb) document. . .\n   - **unsupported** means of \"demoing\" Tuskar (set node attributes to match flavors, hack\n     the scheduler, etc)\n   - our goals of supporting heterogeneous nodes for the J-release.\n\nDoes this seem reasonable to everyone?\n\n\nMainn\n\n----- Original Message -----\n> On 30 January 2014 23:26, Tomas Sedovic <tsedovic at redhat.com> wrote:\n> > Hi all,\n> >\n> > I\'ve seen some confusion regarding the homogenous hardware support as the\n> > first step for the tripleo UI. I think it\'s time to make sure we\'re all on\n> > the same page.\n> >\n> > Here\'s what I think is not controversial:\n> >\n> > 1. Build the UI and everything underneath to work with homogenous hardware\n> > in the Icehouse timeframe\n> > 2. Figure out how to support heterogenous hardware and do that (may or may\n> > not happen within Icehouse)\n> >\n> > The first option implies having a single nova flavour that will match all\n> > the boxes we want to work with. It may or may not be surfaced in the UI (I\n> > think that depends on our undercloud installation story).\n> \n> I don\'t agree that (1) implies a single nova flavour. In the context\n> of the discussion it implied avoiding doing our own scheduling, and\n> due to the many moving parts we never got beyond that.\n> \n> My expectation is that (argh naming of things) a service definition[1]\n> will specify a nova flavour, right from the get go. That gives you\n> homogeneous hardware for any service\n> [control/network/block-storage/object-storage].\n> \n> Jaromir\'s wireframes include the ability to define multiple such\n> definitions, so two definitions for compute, for instance (e.g. one\n> might be KVM, one Xen, or one w/GPUs and the other without, with a\n> different host aggregate configured).\n> \n> As long as each definition has a nova flavour, users with multiple\n> hardware configurations can just create multiple definitions, done.\n> \n> That is not entirely policy driven, so for longer term you want to be\n> able to say \'flavour X *or* Y can be used for this\', but as a early\n> iteration it seems very straight forward to me.\n> \n> > Now, someone (I don\'t honestly know who or when) proposed a slight step up\n> > from point #1 that would allow people to try the UI even if their hardware\n> > varies slightly:\n> \n> > 1.1 Treat similar hardware configuration as equal\n> \n> I think this is a problematic idea, because of the points raised\n> elsewhere in the thread.\n> \n> But more importantly, it\'s totally unnecessary. If one wants to handle\n> minor variations in hardware (e.g. 1TB vs 1.1TB disks) just register\n> them as being identical, with the lowest common denominator - Nova\n> will then treat them as equal.\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ0KxD4aj5HWZkiiDMQqVKpxgT_sheQ1Y0CyeejBzMuEDw@mail.gmail.com>',NULL),('<1382376107-sup-7333@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 10:28:58',-25200,'2013-10-21 17:28:58',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n	OpenStack projects (and [trove]\n	python-troveclient_0.1.4-1_amd64.changes REJECTED)','Excerpts from Robert Collins\'s message of 2013-10-20 02:25:43 -0700:\n> On 20 October 2013 02:35, Monty Taylor <mordred at inaugust.com> wrote:\n> \n> > However, even as a strong supporter of accurate license headers, I would\n> > like to know more about the FTP masters issue. I dialog with them, as\n> > folks who deal with this issue and its repercutions WAY more than any of\n> > us might be really nice.\n> \n> Debian takes it\'s responsibilities under copyright law very seriously.\n> The integrity of the debian/copyright metadata is checked on the first\n> upload for a package (and basically not thereafter, which is either\n> convenient or pragmatic or a massive hole in rigour depending on your\n> point of view. The goal is to ensure that a) the package is in the\n> right repository in Debian (main vs nonfree) and b) that Debian can\n> redistribute it and c) that downstreams of Debian who decide to use\n> the package can confidently do so. Files with differing redistribution\n> licenses that aren\'t captured in debian/copyright are an issue for c);\n> files with different authors and the same redistribution licence\n> aren\'t a problem for a/b/c *but* the rules the FTP masters enforce\n> don\'t make that discrimination: the debian/copyright file needs to be\n> a concordance of both copyright holders and copyright license.\n> \n> Personally, I think it should really only be a concordance of\n> copyright licenses, and the holders shouldn\'t be mentioned, but thats\n> not the current project view.\n> \n\nThe benefit to this is that by at least hunting down project leadership\nand getting an assertion and information about the copyright holder\nsituation, a maintainer tends to improve clarity upstream. Often things\nthat are going into NEW are, themselves, new to the world, and often\nthose projects have not done the due diligence to state their license\nand take stock of their copyright owners. I think that is one reason\nthe process survives despite perhaps going further than is necessary to\nmaintain Debian\'s social contract integrity.\n\nI think OpenStack has taken enough care to ensure works are attributable\nto their submitters that Debian should have a means to accept that\nthis project is indeed licensed as such. Perhaps a statement detailing\nthe process OpenStack uses to ensure this can be drafted and included\nin each repository. It is not all that dissimilar to what MySQL did by\nstating the OpenSource linking exception for libmysqlclient\'s\nGPL license explicitly in a file that is now included with the tarballs.\n\n\n','<CAJ3HoZ1Q5SEf+R=8UhXR7=1x_72EAkm-0BMP0HZwk7-tbF0KXw@mail.gmail.com>',NULL),('<1382381469.90540.YahooMailBasic@web160503.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 11:51:09',-25200,'2013-10-21 18:51:09',NULL,'[openstack-dev] Distributed Virtual Router Discussion','Hi Swaminathan.\n\nI work for a virtual networking startup called Midokura and I\'m very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I\'m asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality.\n\nNote that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams?\n\nLooking forward to further discussing this topic with you!\n\nSincerely,\nArtem Dmytrenko\n\n--------------------------------------------\nOn Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) <swaminathan.vasudevan at hp.com> wrote:\n\n Subject: [openstack-dev] Distributed Virtual Router Discussion\n To: \"yong sheng gong (gongysh at unitedstack.com)\" <gongysh at unitedstack.com>, \"cloudbengo at gmail.com\" <cloudbengo at gmail.com>, \"OpenStack Development Mailing List (openstack-dev at lists.openstack.org)\" <openstack-dev at lists.openstack.org>\n Date: Monday, October 21, 2013, 12:18 PM\n \n \n \n  \n  \n \n \n \n \n Hi Folks, \n I am currently working on a\n blueprint for Distributed Virtual Router. \n If anyone interested in\n being part of the discussion please let me know. \n I have put together a first\n draft of my blueprint and have posted it on Launchpad for\n review. \n https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr\n \n  ? \n  ? \n Thanks. \n  ? \n Swaminathan Vasudevan \n Systems Software Engineer\n (TC) \n  ? \n  ? \n HP Networking \n Hewlett-Packard \n 8000 Foothills Blvd \n M/S 5541 \n Roseville, CA - 95747 \n tel: 916.785.0937 \n fax: 916.785.1815 \n email: swaminathan.vasudevan at hp.com\n \n  ? \n  ? \n \n \n \n \n -----Inline Attachment Follows-----\n \n _______________________________________________\n OpenStack-dev mailing list\n OpenStack-dev at lists.openstack.org\n http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n \n\n\n','<4094DC7712AF5D488899847517A3C5B064AF116C@G9W0729.americas.hpqcorp.net>',NULL),('<1382388321.4715.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 21:45:21',3600,'2013-10-21 20:45:21',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Mon, 2013-10-21 at 10:28 -0700, Clint Byrum wrote:\n> Excerpts from Robert Collins\'s message of 2013-10-20 02:25:43 -0700:\n> > On 20 October 2013 02:35, Monty Taylor <mordred at inaugust.com> wrote:\n> > \n> > > However, even as a strong supporter of accurate license headers, I would\n> > > like to know more about the FTP masters issue. I dialog with them, as\n> > > folks who deal with this issue and its repercutions WAY more than any of\n> > > us might be really nice.\n> > \n> > Debian takes it\'s responsibilities under copyright law very seriously.\n> > The integrity of the debian/copyright metadata is checked on the first\n> > upload for a package (and basically not thereafter, which is either\n> > convenient or pragmatic or a massive hole in rigour depending on your\n> > point of view. The goal is to ensure that a) the package is in the\n> > right repository in Debian (main vs nonfree) and b) that Debian can\n> > redistribute it and c) that downstreams of Debian who decide to use\n> > the package can confidently do so. Files with differing redistribution\n> > licenses that aren\'t captured in debian/copyright are an issue for c);\n> > files with different authors and the same redistribution licence\n> > aren\'t a problem for a/b/c *but* the rules the FTP masters enforce\n> > don\'t make that discrimination: the debian/copyright file needs to be\n> > a concordance of both copyright holders and copyright license.\n> > \n> > Personally, I think it should really only be a concordance of\n> > copyright licenses, and the holders shouldn\'t be mentioned, but thats\n> > not the current project view.\n> > \n> \n> The benefit to this is that by at least hunting down project leadership\n> and getting an assertion and information about the copyright holder\n> situation, a maintainer tends to improve clarity upstream.\n\nBy \"improve clarity\", you mean \"compile an accurate list of all\ncopyright holders\"? Why is this useful information?\n\nSure, we could also \"improve clarity\" by compiling a list of all the\ncities in the world where some OpenStack code has been authored ... but\n*why*?\n\n>  Often things\n> that are going into NEW are, themselves, new to the world, and often\n> those projects have not done the due diligence to state their license\n> and take stock of their copyright owners.\n\nI think OpenStack has done plenty of due diligence around the licensing\nof its code and that all copyright holders agree to license their code\nunder those terms.\n\n> I think that is one reason\n> the process survives despite perhaps going further than is necessary to\n> maintain Debian\'s social contract integrity.\n\nThis is related to some \"social contract\"? Please explain.\n\n> I think OpenStack has taken enough care to ensure works are attributable\n> to their submitters that Debian should have a means to accept that\n> this project is indeed licensed as such. Perhaps a statement detailing\n> the process OpenStack uses to ensure this can be drafted and included\n> in each repository. It is not all that dissimilar to what MySQL did by\n> stating the OpenSource linking exception for libmysqlclient\'s\n> GPL license explicitly in a file that is now included with the tarballs.\n\nYou objected to someone else on this thread conflating copyright\nownership and licensing. Now you do the same. There is absolutely no\nambiguity about OpenStack\'s license.\n\nOur CLA process for new contributors is documented here:\n\n  https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement\n\nThe key thing for Debian to understand is that all OpenStack\ncontributors agree to license their code under the terms of the Apache\nLicense. I don\'t see why a list of copyright holders would clarify the\nlicensing situation any further.\n\nMark.\n\n\n\n','<1382376107-sup-7333@clint-HP>',NULL),('<1382388519.4715.35.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 21:48:39',3600,'2013-10-21 20:48:39',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:\n> On 10/21/2013 09:28 PM, Mark McLoughlin wrote:\n> > In other words, what exactly is a list of copyright holders good for?\n> \n> At least avoid pain and reject when uploading to the Debian NEW queue...\n\nI\'m sorry, that is downstream Debian pain. It shouldn\'t be inflicted on\nupstream unless it is generally a useful thing.\n\nMark.\n\n\n\n','<52656AAA.70502@debian.org>',NULL),('<1382388904.4715.40.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 21:55:04',3600,'2013-10-21 20:55:04',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Tue, 2013-10-22 at 01:45 +0800, Thomas Goirand wrote:\n> On 10/20/2013 09:00 PM, Jeremy Stanley wrote:\n> > On 2013-10-20 22:20:25 +1300 (+1300), Robert Collins wrote:\n> > [...]\n> >> OTOH registering one\'s nominated copyright holder on the first\n> >> patch to a repository is probably a sustainable overhead. And it\'s\n> >> probably amenable to automation - a commit hook could do it locally\n> >> and a check job can assert that it\'s done.\n> > \n> > I know the Foundation\'s got work underway to improve the affiliate\n> > map from the member database, so it might be possible to have some\n> > sort of automated job which proposes changes to a copyright holders\n> > list in each project by running a query with the author and date of\n> > each commit looking for new affiliations. That seems like it would\n> > be hacky, fragile and inaccurate, but probably still more reliable\n> > than expecting thousands of contributors to keep that information up\n> > to date when submitting patches?\n> \n> My request wasn\'t to go *THAT* far. The main problem I was facing was\n> that troveclient has a few files stating that HP was the sole copyright\n> holder, when it clearly was not (since I have discussed a bit with some\n> the dev team in Portland, IIRC some of them are from Rackspace...).\n\nTalk to the Trove developers and politely ask them whether the copyright\nnotices in their code reflects what they see as the reality.\n\nI\'m sure it would help them if you pointed out to them some significant\nchunks of code from the commit history which don\'t appear to have been\nwritten by a HP employee.\n\nSimply adding a Rackspace copyright notice to a file or two which has\nhad a significant contribution by someone from Rackspace would be enough\nto resolve your concerns completely.\n\ni.e. if you spot in inaccuracy in the copyright headers, just make it\neasy for us people to fix it and I\'m sure they will.\n\nMark.\n\n\n\n','<52656829.60104@debian.org>',NULL),('<1382391002-sup-7237@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-21 14:44:10',-25200,'2013-10-21 21:44:10',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n	OpenStack projects (and [trove]\n	python-troveclient_0.1.4-1_amd64.changes REJECTED)','Excerpts from Mark McLoughlin\'s message of 2013-10-21 13:45:21 -0700:\n> On Mon, 2013-10-21 at 10:28 -0700, Clint Byrum wrote:\n> > Excerpts from Robert Collins\'s message of 2013-10-20 02:25:43 -0700:\n> > > On 20 October 2013 02:35, Monty Taylor <mordred at inaugust.com> wrote:\n> > > \n> > > > However, even as a strong supporter of accurate license headers, I would\n> > > > like to know more about the FTP masters issue. I dialog with them, as\n> > > > folks who deal with this issue and its repercutions WAY more than any of\n> > > > us might be really nice.\n> > > \n> > > Debian takes it\'s responsibilities under copyright law very seriously.\n> > > The integrity of the debian/copyright metadata is checked on the first\n> > > upload for a package (and basically not thereafter, which is either\n> > > convenient or pragmatic or a massive hole in rigour depending on your\n> > > point of view. The goal is to ensure that a) the package is in the\n> > > right repository in Debian (main vs nonfree) and b) that Debian can\n> > > redistribute it and c) that downstreams of Debian who decide to use\n> > > the package can confidently do so. Files with differing redistribution\n> > > licenses that aren\'t captured in debian/copyright are an issue for c);\n> > > files with different authors and the same redistribution licence\n> > > aren\'t a problem for a/b/c *but* the rules the FTP masters enforce\n> > > don\'t make that discrimination: the debian/copyright file needs to be\n> > > a concordance of both copyright holders and copyright license.\n> > > \n> > > Personally, I think it should really only be a concordance of\n> > > copyright licenses, and the holders shouldn\'t be mentioned, but thats\n> > > not the current project view.\n> > > \n> > \n> > The benefit to this is that by at least hunting down project leadership\n> > and getting an assertion and information about the copyright holder\n> > situation, a maintainer tends to improve clarity upstream.\n> \n> By \"improve clarity\", you mean \"compile an accurate list of all\n> copyright holders\"? Why is this useful information?\n> \n> Sure, we could also \"improve clarity\" by compiling a list of all the\n> cities in the world where some OpenStack code has been authored ... but\n> *why*?\n> \n\nIf you don\'t know who the copyright holders are, you cannot know that\nthe license being granted is actually enforceable. What if the Trove\ndevelopers just found some repo lying out in the world and slapped an\nApache license on it? We aren\'t going to do an ehaustive investigation,\nbut we want to know _who_ granted said license.\n\n> >  Often things\n> > that are going into NEW are, themselves, new to the world, and often\n> > those projects have not done the due diligence to state their license\n> > and take stock of their copyright owners.\n> \n> I think OpenStack has done plenty of due diligence around the licensing\n> of its code and that all copyright holders agree to license their code\n> under those terms.\n> \n> > I think that is one reason\n> > the process survives despite perhaps going further than is necessary to\n> > maintain Debian\'s social contract integrity.\n> \n> This is related to some \"social contract\"? Please explain.\n> \n\nhttp://www.debian.org/social_contract\n\n> > I think OpenStack has taken enough care to ensure works are attributable\n> > to their submitters that Debian should have a means to accept that\n> > this project is indeed licensed as such. Perhaps a statement detailing\n> > the process OpenStack uses to ensure this can be drafted and included\n> > in each repository. It is not all that dissimilar to what MySQL did by\n> > stating the OpenSource linking exception for libmysqlclient\'s\n> > GPL license explicitly in a file that is now included with the tarballs.\n> \n> You objected to someone else on this thread conflating copyright\n> ownership and licensing. Now you do the same. There is absolutely no\n> ambiguity about OpenStack\'s license.\n> \n\nI\'m not sure that was me, but I would object to conflating it, yes. They\nare not the same thing, but they are related. Only a copyright holder\ncan grant a copyright license.\n\n> Our CLA process for new contributors is documented here:\n> \n>   https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement\n> \n> The key thing for Debian to understand is that all OpenStack\n> contributors agree to license their code under the terms of the Apache\n> License. I don\'t see why a list of copyright holders would clarify the\n> licensing situation any further.\n> \n\nSo Debian has a rule that statements like these need to be delivered to\ntheir users along with the end-user binaries (it relates to the social\ncontract and the guidelines attached to the contract.\n\nhttps://review.openstack.org/static/cla.html\n\nArticle 2 is probably sufficient to say that it only really matters that\nall of the copyrighted material came from people who signed the CLA,\nand that the \"Project Manager\" (OpenStack Foundation) grants the license\non the code. I assume the other CLA\'s have the same basic type of\nlicense being granted to the OpenStack Foundation.\n\nSo my recommendation stands, that we can clarify it in the released\ntarballs with a single document. I suggest that document have the text\nof the CLA\'s (since there are different CLA\'s for different types of\nsubmitters), and an assertion that all of the code in the underlying\nrepository has been submitted by individuals who have signed at least one\nof these CLA\'s. That _should_ be sufficient for Debian\'s FTP masters,\nand if not, then for the Debian governing bodies that would be able to\noverride the FTP masters.\n\nOh and I am not a lawyer, but I am a Debian developer and I am concerned\nthat we make it clear exactly what users\' rights are.\n\n\n','<1382388321.4715.33.camel@sorcha>',NULL),('<1382421498.4715.51.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 06:58:18',3600,'2013-10-22 05:58:18',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Tue, 2013-10-22 at 01:09 +0100, Monty Taylor wrote:\n\n> The last thing we need to do is validate in any manner that somehow the\n> CLA makes our Apache Licensed Free Software more Free or more Valid than\n> if we did not have our useless CLA.\n\nAgree with this. My simplified way of thinking about this is that the\nterms of the CLA are the same as the terms of the license and the CLA is\njust a way of getting contributors to explicitly say that all code they\ncontribute will be under the terms of the license.\n\nAs Richard Fontana pointed out on this list before, Signed-off-by could\nserve a similar process (while supporting the notion of a patch having\nmultiple authors) with much less hassle, confusion and false security.\n\nMark.\n\n\n\n','<5265C245.9070209@inaugust.com>',NULL),('<1382423044.4715.57.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 07:24:04',3600,'2013-10-22 06:24:04',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Tue, 2013-10-22 at 14:09 +0800, Thomas Goirand wrote:\n> On 10/22/2013 04:55 AM, Mark McLoughlin wrote:\n> > Talk to the Trove developers and politely ask them whether the copyright\n> > notices in their code reflects what they see as the reality.\n> > \n> > I\'m sure it would help them if you pointed out to them some significant\n> > chunks of code from the commit history which don\'t appear to have been\n> > written by a HP employee.\n> \n> I did this already. Though if I raised the topic in this list (as\n> opposed to contact the Trove maintainers privately), this was for a\n> broader scope, to make sure it doesn\'t happen again and again.\n> \n> > Simply adding a Rackspace copyright notice to a file or two which has\n> > had a significant contribution by someone from Rackspace would be enough\n> > to resolve your concerns completely.\n> \n> But how to make sure that there\'s no *other* copyright holders, and that\n> my debian/copyright is right? Currently, there\'s no way...\n\nI\'ve never seen a project where copyright headers weren\'t occasionally\nmissing some copyright holders. I suspect Debian has managed just fine\nwith those projects and can manage just fine with OpenStack\'s copyright\nheaders too.\n\nMark.\n\n\n\n','<526616A4.6020909@debian.org>',NULL),('<1382427566.4715.62.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 08:39:26',3600,'2013-10-22 07:39:26',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes\n REJECTED)','On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote:\n> On 10/22/2013 04:48 AM, Mark McLoughlin wrote:\n> > On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:\n> >> On 10/21/2013 09:28 PM, Mark McLoughlin wrote:\n> >>> In other words, what exactly is a list of copyright holders good for?\n> >>\n> >> At least avoid pain and reject when uploading to the Debian NEW queue...\n> > \n> > I\'m sorry, that is downstream Debian pain.\n> \n> I agree, it is painful, though it is a necessary pain. Debian has always\n> been strict with copyright stuff. This should be seen as a freeness Q/A,\n> so that we make sure everything is 100% free, rather than an annoyance.\n\nA list of copyright holders does nothing to improve the \"freeness\" of\nOpenStack.\n\n> > It shouldn\'t be inflicted on\n> > upstream unless it is generally a useful thing.\n> \n> There\'s no other ways to do things, unfortunately. How would I make sure\n> a software is free, and released in the correct license, if upstream\n> doesn\'t declare it properly? There\'s been some cases on packages I\n> wanted to upload, where there was just:\n> \n> Classifier: License :: OSI Approved :: MIT License\n> \n> in *.egg-info/PKG-INFO, and that\'s it. If the upstream authors don\'t fix\n> this by adding a clear LICENSE file (with the correct definition of the\n> MIT License, which is confusing because there\'s been many of them), then\n> the package couldn\'t get in. Lucky, upstream authors of that python\n> module fixed that, and the package was re-uploaded and validated by the\n> FTP masters.\n\nI fully understand the importance of making it completely clear what the\nlicense of a project is and have had to package projects that don\'t make\nthis clear. Fedora\'s guidelines on the subject are e.g.\n\nhttps://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text\n\n> I\'m not saying that this was the case for Trove (the exactitude of the\n> copyright holder list in debian/copyright is less of an issue), though\n> I\'m just trying to make you understand that you can\'t just ignore the\n> issue and say \"I don\'t care, that\'s Debian\'s problem\". This simply\n> doesn\'t work (unless you would prefer OpenStack package to *not* be in\n> Debian, which I\'m sure isn\'t the case here).\n\nI can say \"Debian policies that no-one can provide any justification for\nis Debian\'s problem\". And that\'s the case with this supposed \"Debian\nrequires a complete list of copyright holders\" policy.\n\nMark.\n\n\n\n','<526618EC.6070808@debian.org>',NULL),('<1382455516-sup-1569@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 08:31:01',-25200,'2013-10-22 15:31:01',NULL,'[openstack-dev] [Tempest] Do we need more people reviewing tempest?','I recently submitted a _tiny_ change to tempest to enable Python3\nporting in python-keystoneclient.\n\nhttps://review.openstack.org/#/c/51736/\n\nIt has one +2 now, but 8 days after submitting it is still waiting for\na second +2. It is not special though, there are 59 \"waiting on reviewer\":\n\nhttp://russellbryant.net/openstack-stats/tempest-openreviews.html\n\nDo we need to put out a call for more people to do reviews on tempest? Is\nthe team just temporarily short-handed?\n\nAnyway, tempest is pretty important to OpenStack quality, so it feels\nlike something we should all be helping with. I\'d be happy to carve out\na small bit of my usual review time to do tempest reviews, but I don\'t\nthink I can solve the problem with what I can add. Since we all bring\nknowledge of the systems being tested, I wonder if all core reviewers\nfrom all projects can commit just a little time to tempest (rather than\njust having the core reviewers for tempest be a small team) ?\n\n\n',NULL,NULL),('<1382457337-sup-8450@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 09:21:25',-25200,'2013-10-22 16:21:25',NULL,'[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all\n	OpenStack projects (and [trove]\n	python-troveclient_0.1.4-1_amd64.changes REJECTED)','Excerpts from Monty Taylor\'s message of 2013-10-21 17:09:41 -0700:\n> \n> On 10/21/2013 10:44 PM, Clint Byrum wrote:\n> > Excerpts from Mark McLoughlin\'s message of 2013-10-21 13:45:21 -0700:\n> > \n> > If you don\'t know who the copyright holders are, you cannot know that\n> > the license being granted is actually enforceable. What if the Trove\n> > developers just found some repo lying out in the world and slapped an\n> > Apache license on it? We aren\'t going to do an ehaustive investigation,\n> > but we want to know _who_ granted said license.\n> \n> You know I think you\'re great, but this argument doesn\'t hold up.\n> \n> If the trove developers found some repo in the world and slapped an\n> apache license AND said:\n> \n> Copyright 2012 Michael Basnight\n> \n> in the header, and Thomas put that in debian/copyright, the Debian FTP\n> masters would very happily accept it.\n> \n\nThe copyright header is a data point. Now somebody looking to vet the\nlicense situation can go and contact Michael Basnight, and look at the\nhistory of the code itself. They can validate that Michael Basnight was\nan early author, made announcements, isn\'t a habitual code stealer, etc.\n\nIs this correct? No, but it gives someone looking to do due diligence\nconfirmation that Michael had the right to license the code.\n\nNo headers, and no information anywhere just makes an investigation that\nmuch harder.\n\nSo it is just a data point for auditing. The problem, which Robert\nCollins alluded to, is that nobody is actually auditing things this way.\n\nThis is something to bring up in Debian. I think I\'ll work off list with\nThomas to draft something for Debian which proposes a clarification\nor relaxation of the copyright holder interpretation of Debian policy\ncurrently adopted by the FTP masters.\n\n> I think that authors should attribute their work, because I think that\n> they should care. However, if they don\'t, that\'s fine. There is SOME\n> attribution in the file, and that attribution itself is correct. HP did\n> write some of the file. Rackspace also did but did not bother to claim\n> having done so.\n> \n> debian/copyright should reflect what\'s in the files - it\'s what the\n> project is stating through the mechanisms that we have available to us.\n> I appreciate Thomas trying to be more precise here, but I think it\'s\n> actually too far. If you think that there is a bug in the copyright\n> header, you need to contact the project, via email, bug or patch, and\n> fix it. At THAT point, you can fix the debian/copyright file.\n> \n> Until then, you need to declare to Debian what we are declaring to you.\n> \n\nIndeed, this hasn\'t come up, presumably, because the other\ndebian/copyright files have done just that. That is definitely the path of\nleast resistance, and the one I have taken. This is not trivial either,\nAs somebody who made a feeble attempt at documenting the copyright\nholders for MySQL (all of you reading this have no idea how hard Monty\nis cackling right now), I can say that it is basically pointless to do\nanything except automatically generate from existing sources and spot\ncheck.\n\n> > \n> > I\'m not sure that was me, but I would object to conflating it, yes. They\n> > are not the same thing, but they are related. Only a copyright holder\n> > can grant a copyright license.\n> \n> Listing the holders in debian/copyright does not prove that the asserted\n> holder is a valid holder. It only asserts that _someone_ has asserted\n> that copyright.\n> \n> It means that, should someone sue you for copyright infringement, there\n> is someone you can go to for clarification.\n> \n\nThat sounds pretty valuable to me. Imagine Debian has some big\ncorporation sending them cease and desist letters and threats of\ncopyright infringement lawsuits. It would be useful to be able to\ndeflect that efficiently given their limited resources.\n\n> >> Our CLA process for new contributors is documented here:\n> >>\n> >>   https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement\n> >>\n> >> The key thing for Debian to understand is that all OpenStack\n> >> contributors agree to license their code under the terms of the Apache\n> >> License. I don\'t see why a list of copyright holders would clarify the\n> >> licensing situation any further.\n> >>\n> > \n> > So Debian has a rule that statements like these need to be delivered to\n> > their users along with the end-user binaries (it relates to the social\n> > contract and the guidelines attached to the contract.\n> > \n> > https://review.openstack.org/static/cla.html\n> > \n> > Article 2 is probably sufficient to say that it only really matters that\n> > all of the copyrighted material came from people who signed the CLA,\n> > and that the \"Project Manager\" (OpenStack Foundation) grants the license\n> > on the code. I assume the other CLA\'s have the same basic type of\n> > license being granted to the OpenStack Foundation.\n> > \n> > So my recommendation stands, that we can clarify it in the released\n> > tarballs with a single document. I suggest that document have the text\n> > of the CLA\'s (since there are different CLA\'s for different types of\n> > submitters), and an assertion that all of the code in the underlying\n> > repository has been submitted by individuals who have signed at least one\n> > of these CLA\'s. That _should_ be sufficient for Debian\'s FTP masters,\n> > and if not, then for the Debian governing bodies that would be able to\n> > override the FTP masters.\n> > \n> > Oh and I am not a lawyer, but I am a Debian developer and I am concerned\n> > that we make it clear exactly what users\' rights are.\n> \n> I believe our CLA is bullshit.\n> \n> Our code has an Apache License on it. All of our files have Apache\n> license headers on them. They are all Apache licensed.\n> \n> The users rights, as per the Debian Social Contract, are clearly stated\n> - they are the rights, granted to the user, under the auspices of the\n> Apache License.\n> \n> Who granted those rights to the user is immaterial to how the license\n> operates. A correct list of everyone who may have contributed lines of\n> code to the file is also immaterial.\n> \n> The source from which Debian is receiving the code, has attached a\n> license to the software. It is Free Software.\n> \n> Our CLA was useless bullshit when our corporate lawyers forced it on us.\n> It is useless bullshit now. It will be useless bullshit until we rip it\n> out of the hands of our corporate lawyers and stomp it on the ground\n> until it is dead and the people who added it senselessly to our process\n> feel very silly that they do not have the ability to read the\n> quite-clear terms of the Apache License itself.\n> \n> The last thing we need to do is validate in any manner that somehow the\n> CLA makes our Apache Licensed Free Software more Free or more Valid than\n> if we did not have our useless CLA.\n> \n\nI\'d appreciate it if you would include your _actual_ feelings in these\nemails and not mince words next time Monty.\n\nPoint taken, no CLA in tarballs. Up until this point I actually thought\nthe CLA was something that was part of the community ethos, some kind of\n\"look we are making it better for companies\". Did not realize it was\njust a legal shim put in by the corporate lawyer drones.\n\n\n','<5265C245.9070209@inaugust.com>',NULL),('<1382479470-sup-5858@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 15:28:17',-25200,'2013-10-22 22:28:17',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Georgy Okrokvertskhov\'s message of 2013-10-22 13:32:40 -0700:\n> Hi Thomas,\n> \n> I agree with you on semantics part. At the same time I see a potential\n> question which might appear - if semantics is limited by few states visible\n> for Heat engine, then who actually does software orchestration?\n> Will it be reasonable then to have software orchestration as separate\n> subproject for Heat as a part of \"Orchestration\" OpenStack program? Heat\n> engine will then do dependency tracking and will use components as a\n> reference for software orchestration engine which will perform actual\n> deployment and high level software components coordination.\n> \n> This separated software orchestration engine may address all specific\n> requirements proposed by different teams in this thread without affecting\n> existing Heat engine.\n> \n\nI\'m not sure I know what \"software orchestration\" is, but I will take a\nstab at a succinct definition:\n\nCoordination of software configuration across multiple hosts.\n\nIf that is what you mean, then I believe what you actually want is\nworkflow. And for that, we have the Mistral project which was recently\nannounced [1].\n\nUse that and you will simply need to define your desired workflow and\nfeed it into Mistral using a Mistral Heat resource. We can create a\nnice bootstrapping resource for Heat instances that shims the mistral\nworkflow execution agent into machines (or lets us use one already there\nvia custom images).\n\nI can imagine it working something like this:\n\nresources:\n  mistral_workflow_handle:\n    type: OS::Mistral::WorkflowHandle\n  web_server:\n    type: OS::Nova::Server\n    components:\n      mistral_agent:\n        component_type: mistral\n        params:\n          workflow_: {ref: mistral_workflow_handle}\n  mysql_server:\n    type: OS::Nova::Server\n    components:\n      mistral_agent:\n        component_type: mistral\n        params:\n          workflow_handle: {ref: mistral_workflow_handle}\n  mistral_workflow:\n    type: OS::Mistral::Workflow\n    properties:\n      handle: {ref: mistral_workflow_handle}\n      workflow_reference: mysql_webapp_workflow\n      params:\n        mysql_server: {ref: mysql_server}\n        webserver: {ref: web_server}\n\n\nAnd then the workflow is just defined outside of the Heat template (ok\nI\'m sure somebody will want to embed it, but I prefer stronger\nseparation). Something like this gets uploaded as\n\"mysql_webapp_workflow\":\n\n[ \'step1\': \'install_stuff\',\n  \'step2\': \'wait(step1)\',\n  \'step3\': \'allocate_sql_user(server=%mysql_server%)\'\n  \'step4\': \'credentials=wait_and_read(step3)\'\n  \'step5\': \'write_config_file(server=%webserver%)\' ]\n\nOr maybe it is declared as a graph, or whatever, but it is not Heat\'s\nproblem how to do workflows, it just feeds the necessary data from\norchestration into the workflow engine. This also means you can use a\nnon OpenStack workflow engine without any problems.\n\nI think after having talked about this, we should have workflow live in\nits own program.. we can always combine them if we want to, but having a\nclear line would mean keeping the interfaces clean.\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html\n\n\n','<CAG_6_okZZvuKuzG6FyOR8JKUB8uHmq+cpnuxTXaqLWb+xY=Hnw@mail.gmail.com>',NULL),('<13824FFE-F3FF-4466-82DE-B9F52A19D387@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-09 18:40:08',-14400,'2013-09-09 22:40:08',NULL,'[openstack-dev] [Neutron] Bug #1209011','Carl-\n\nThanks for pointing this out.  I\'ve fixed the bug status.\n\nmark\n\nOn Sep 9, 2013, at 6:33 PM, \"Baldwin, Carl (HPCS Neutron)\" <carl.baldwin at hp.com> wrote:\n\n> Hi all,\n> \n> This bug was marked as fix released for H-3.  However, the fix that was\n> merged was reverted due to gate breakage.  The patch was resubmitted as\n> https://review.openstack.org/#/c/42412/ and fixes the gate breakage but\n> this new patch has not been merged.  So, the bug state of \"Yix released\"\n> is not accurate.\n> \n> This bug needs one of the following two actions:\n> \n> 1) The new patch accepted and bug state changed to \"Fix Committed.\"\n> 1) Bug state reverted to \"In Progress.\"\n> \n> Thanks,\n> Carl\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CE53A907.86D5%carl.baldwin@hp.com>',NULL),('<1382503632.40.1383372450470.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:07:30',0,'2013-11-02 06:07:30',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-nova-docs-stable-folsom #38','See <https://jenkins01.openstack.org/job/periodic-nova-docs-stable-folsom/38/>\n\n\n\n',NULL,NULL),('<1382535935-sup-4420@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-23 06:51:10',-25200,'2013-10-23 13:51:10',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Thomas Spatzier\'s message of 2013-10-23 00:08:23 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 23.10.2013 00:28:17:\n> > From: Clint Byrum <clint at fewbar.com>\n> > To: openstack-dev <openstack-dev at lists.openstack.org>,\n> > Date: 23.10.2013 00:30\n> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal\n> >\n> > Excerpts from Georgy Okrokvertskhov\'s message of 2013-10-22 13:32:40\n> -0700:\n> > > Hi Thomas,\n> > >\n> > > I agree with you on semantics part. At the same time I see a potential\n> > > question which might appear - if semantics is limited by few states\n> visible\n> > > for Heat engine, then who actually does software orchestration?\n> > > Will it be reasonable then to have software orchestration as separate\n> > > subproject for Heat as a part of \"Orchestration\" OpenStack program?\n> Heat\n> > > engine will then do dependency tracking and will use components as a\n> > > reference for software orchestration engine which will perform actual\n> > > deployment and high level software components coordination.\n> > >\n> > > This separated software orchestration engine may address all specific\n> > > requirements proposed by different teams in this thread without\n> affecting\n> > > existing Heat engine.\n> > >\n> >\n> > I\'m not sure I know what \"software orchestration\" is, but I will take a\n> > stab at a succinct definition:\n> >\n> > Coordination of software configuration across multiple hosts.\n> >\n> > If that is what you mean, then I believe what you actually want is\n> > workflow. And for that, we have the Mistral project which was recently\n> > announced [1].\n> \n> My view of \"software orchestration\" in a sense of what Heat should be able\n> to do is being able to bring up software installations (e.g. web server, a\n> DBMS, a custom application) on-top of a bare compute resource by invoking a\n> software config tool (e.g. Chef, Puppet ...) at the right point in time and\n> let that tool do the actual work.\n> Invoke does not necessarily mean to call an API of such a tool, but rather\n> make sure it is bootstrapped and maybe gets a \"go\" signal to start.\n> \"software orchestration\" could then further mean to give CM tools across\n> hosts the \"go\" signal when the config on one host has completed. This be\n> enabled by the signaling enhancements Steve Baker mentioned in one of his\n> recent mails.\n> \n> For such kind of stuff, I think we could live without workflows but do it\n> purely declaratively. Of course, a workflow could be the underlying\n> mechanism, but I would not want to express this in a template. If users\n> have very complex problems to solve and cannot live with the simple\n> software orchestration I outlined, then still a workflow could be used for\n> everying on-top of the OS.\n> \n> Anyway, that was just my view and others most probably have different views\n> again, so seems like we really have to sort out terminology :-)\n> \n\nRight, we can do a lot without any external workflow help. We may be\nable to do basically everything without external workflow help, however\nI want to make sure that users have a well defined method for solving\ntheir problems before Heat has a way to declaratively solve them.\n\n> >\n> > Use that and you will simply need to define your desired workflow and\n> > feed it into Mistral using a Mistral Heat resource. We can create a\n> > nice bootstrapping resource for Heat instances that shims the mistral\n> > workflow execution agent into machines (or lets us use one already there\n> > via custom images).\n> >\n> > I can imagine it working something like this:\n> >\n> > resources:\n> >   mistral_workflow_handle:\n> >     type: OS::Mistral::WorkflowHandle\n> >   web_server:\n> >     type: OS::Nova::Server\n> >     components:\n> >       mistral_agent:\n> >         component_type: mistral\n> >         params:\n> >           workflow_: {ref: mistral_workflow_handle}\n> >   mysql_server:\n> >     type: OS::Nova::Server\n> >     components:\n> >       mistral_agent:\n> >         component_type: mistral\n> >         params:\n> >           workflow_handle: {ref: mistral_workflow_handle}\n> >   mistral_workflow:\n> >     type: OS::Mistral::Workflow\n> >     properties:\n> >       handle: {ref: mistral_workflow_handle}\n> >       workflow_reference: mysql_webapp_workflow\n> >       params:\n> >         mysql_server: {ref: mysql_server}\n> >         webserver: {ref: web_server}\n> >\n> \n> While I can imagine that this works, I think for a big percentage of use\n> cases I would be nice to avoid this inter-weaving of workflow constructs\n> with a HOT template. I think we could do a purely declarative approach (if\n> we scope software orchestration in context of Heat right), and not define\n> such handles and references.\n> We are trying to shield this from the users in other cases in HOT\n> (WaitConditionHandle and references), so why introduce it here ...\n> \n\nI totally agree. Once the bits above work and are available as individual\npieces for users to construct things with, the lowest common denominator\nparts can become components/provider/etc. or be optimized into resource\nplugins.\n\nMy point is to focus on getting the interface between multi-host\nworkflow and Heat well defined and serving at least one use case. In\nthis context, Puppet and Chef, and \'cfn-init\' are all single-instance\nworkflow engines btw.\n\n\n','<OF20F2021C.B97D3A61-ONC1257C0D.00259515-C1257C0D.00273858@de.ibm.com>',NULL),('<1382552753-sup-5079@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-23 11:36:24',-25200,'2013-10-23 18:36:24',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Patrick Petit\'s message of 2013-10-23 10:58:22 -0700:\n> Dear Steve and All,\n> \n> If I may add up on this already busy thread to share our experience with \n> using Heat in large and complex software deployments.\n> \n\nThanks for sharing Patrick, I have a few replies in-line.\n\n> I work on a project which precisely provides additional value at the \n> articulation point between resource orchestration automation and \n> configuration management. We rely on Heat and chef-solo respectively for \n> these base management functions. On top of this, we have developed an \n> event-driven workflow to manage the life-cycles of complex software \n> stacks which primary purpose is to support middleware components as \n> opposed to end-user apps. Our use cases are peculiar in the sense that \n> software setup (install, config, contextualization) is not a one-time \n> operation issue but a continuous thing that can happen any time in \n> life-span of a stack. Users can deploy (and undeploy) apps long time \n> after the stack is created. Auto-scaling may also result in an \n> asynchronous apps deployment. More about this latter. The framework we \n> have designed works well for us. It clearly refers to a PaaS-like \n> environment which I understand is not the topic of the HOT software \n> configuration proposal(s) and that\'s absolutely fine with us. However, \n> the question for us is whether the separation of software config from \n> resources would make our life easier or not. I think the answer is \n> definitely yes but at the condition that the DSL extension preserves \n> almost everything from the expressiveness of the resource element. In \n> practice, I think that a strict separation between resource and \n> component will be hard to achieve because we\'ll always need a little bit \n> of application\'s specific in the resources. Take for example the case of \n> the SecurityGroups. The ports open in a SecurityGroup are application \n> specific.\n>\n\nComponents can only be made up of the things that are common to all users\nof said component. Also components would, if I understand the concept\ncorrectly, just be for things that are at the sub-resource level.\nSecurity groups and open ports would be across multiple resources, and\nthus would be separately specified from your app\'s component (though it\nmight be useful to allow components to export static values so that the\nport list can be referred to along with the app component).\n\n> Then, designing a Chef or Puppet component type may be harder than it \n> looks at first glance. Speaking of our use cases we still need a little \n> bit of scripting in the instance\'s user-data block to setup a working \n> chef-solo environment. For example, we run librarian-chef prior to \n> starting chef-solo to resolve the cookbook dependencies. A cookbook can \n> present itself as a downloadable tarball but it\'s not always the case. A \n> chef component type would have to support getting a cookbook from a \n> public or private git repo (maybe subversion), handle situations where \n> there is one cookbook per repo or multiple cookbooks per repo, let the \n> user choose a particular branch or label, provide ssh keys if it\'s a \n> private repo, and so forth. We support all of this scenarios and so we \n> can provide more detailed requirements if needed.\n>\n\nCorrect me if I\'m wrong though, all of those scenarios are just variations\non standard inputs into chef. So the chef component really just has to\nallow a way to feed data to chef.\n\n> I am not sure adding component relations like the \'depends-on\' would \n> really help us since it is the job of config management to handle \n> software dependencies. Also, it doesn\'t address the issue of circular \n> dependencies. Circular dependencies occur in complex software stack \n> deployments. Example. When we setup a Slum virtual cluster, both the \n> head node and compute nodes depend on one another to complete their \n> configuration and so they would wait for each other indefinitely if we \n> were to rely on the \'depends-on\'. In addition, I think it\'s critical to \n> distinguish between configuration parameters which are known ahead of \n> time, like a db name or user name and password, versus contextualization \n> parameters which are known after the fact generally when the instance is \n> created. Typically those contextualization parameters are IP addresses \n> but not only. The fact packages x,y,z have been properly installed and \n> services a,b,c successfully started is contextualization information \n> (a.k.a facts) which may be indicative that other components can move on \n> to the next setup stage.\n> \n\nThe form of contextualization you mention above can be handled by a\nslightly more capable wait condition mechanism than we have now. I\'ve\nbeen suggesting that this is the interface that workflow systems should\nuse.\n\n> The case of complex deployments with or without circular dependencies is \n> typically resolved by making the system converge toward the desirable \n> end-state through running idempotent recipes. This is our approach. The \n> first configuration phase handles parametrization which in general \n> brings an instance to CREATE_COMPLETE state. A second phase follows to \n> handle contextualization at the stack level. As a matter of fact, a new \n> contextualization should be triggered every time an instance enters or \n> leave the CREATE_COMPLETE state which may happen any time with \n> auto-scaling. In that phase, circular dependencies can be resolved \n> because all contextualization data can be compiled globally. Notice that \n> Heat doesn\'t provide a purpose built resource or service like Chef\'s \n> data-bag for the storage and retrieval of metadata. This a gap which IMO \n> should be addressed in the proposal. Currently, we use a kludge that is \n> to create a fake AWS::AutoScaling::LaunchConfiguration resource to store \n> contextualization data in the metadata section of that resource.\n>\n\nThat is what we use in TripleO as well:\n\nhttp://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-source.yaml#n143\n\nWe are not doing any updating of that from within our servers though.\nThat is an interesting further use of the capability.\n\n> Aside from the HOT software configuration proposal(s). There are two \n> critical enhancements in Heat that would make software life-cycles \n> management much easier. In fact, they are actual blockers for us.\n> \n> The first one would be to support asynchronous notifications when an \n> instance is created or deleted as a result of an auto-scaling decision. \n> As stated earlier, contextualization needs to apply in a stack every \n> time a instance enters or leaves the CREATE_COMPLETE state. I am not \n> referring to a Ceilometer notification but a Heat notification that can \n> be consumed by a Heat client.\n> \n\nI think this fits into something that I want for optimizing\nos-collect-config as well (our in-instance Heat-aware agent). That is\na way for us to wait for notification of changes to Metadata without\npolling.\n\n> The second one would be to support a new type of AWS::IAM::User (perhaps \n> OS::IAM::User) resource whereby one could pass Keystone credentials to \n> be able to specify Ceilometer alarms based on application\'s specific \n> metrics (a.k.a KPIs).\n> \n\nIt would likely be OS::Keystone::User, and AFAIK this is on the list of\nde-AWS-ification things.\n\n> I hope this is making sense to you and can serve as a basis for further \n> discussions and refinements.\n> \n\nReally great feedback Patrick, thanks again for sharing!\n\n\n','<52680E3E.6000800@bull.net>',NULL),('<1382676493.35.1352592643548.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-11 00:10:43',0,'2012-11-11 00:10:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-diablo #89','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/89/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/>\nCheckout:periodic-swift-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/> - hudson.remoting.Channel at 183b7230:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson703458604063314895.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-diablo/89\n[SCP] Copying console log.\n\n\n','<2100914017.22.1352506247847.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1382692547.19002.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-25 10:15:47',3600,'2013-10-25 09:15:47',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','Hi Thiago,\n\nyou have configured DHCP to push out a MTU of 1400. Can you confirm that the 1400 MTU is actually getting out to the instances by running \'ip link\' on them?\n\nThere is an open problem where the veth used to connect the OVS and Linux bridges causes a performance drop on some kernels - https://bugs.launchpad.net/nova-project/+bug/1223267 .? If you are using the LibvirtHybridOVSBridgeDriver VIF driver, can you try changing to LibvirtOpenVswitchDriver and repeat the iperf test between instances on different compute-nodes.\n\nWhat NICs (maker+model) are you using? You could try disabling any off-load functionality - \'ethtool -k <iface-used-for-gre>\'.\n\nWhat kernal are you using: \'uname -a\'?\n\nRe, Darragh.\n\n> Hi Daniel,\n\n> \n> I followed that page, my Instances MTU is lowered by DHCP Agent but, same\n> result: poor network performance (internal between Instances and when\n> trying to reach the Internet).\n> \n> No matter if I use \"dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf +\n> \"dhcp-option-force=26,1400\"\" for my Neutron DHCP agent, or not (i.e. MTU =\n> 1500), the result is almost the same.\n> \n> I\'ll try VXLAN (or just VLANs) this weekend to see if I can get better\n> results...\n> \n> Thanks!\n> Thiago\n\n\n',NULL,NULL),('<1382711288.61463.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-25 15:28:08',3600,'2013-10-25 14:28:08',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','Hi Thiago,\n\nfor the VIF error: you will need to change qemu.conf as described here:\nhttp://openvswitch.org/openstack/documentation/\n\nRe, Darragh.\n\n\n\n\nOn Friday, 25 October 2013, 15:14, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n \nHi Darragh,\n>\n>\n>Yes, Instances are getting MTU 1400.\n>\n>\n>I\'m using?LibvirtHybridOVSBridgeDriver at my Compute Nodes. I\'ll check BG 1223267 right now!?\n>\n>\n>\n>\n>The?LibvirtOpenVswitchDriver doesn\'t work, look:\n>\n>\n>http://paste.openstack.org/show/49709/\n>\n>\n>\n>http://paste.openstack.org/show/49710/\n>\n>\n>\n>\n>\n>My NICs are \"RTL8111/8168/8411 PCI Express Gigabit Ethernet\", Hypervisors motherboard are MSI-890FXA-GD70.\n>\n>\n>The command \"ethtool -K eth1 gro off\" did not had any effect on the communication between instances on different hypervisors, still poor, around 248Mbit/sec, when its physical path reach 1Gbit/s (where GRE is built).\n>\n>\n>My Linux version is \"Linux hypervisor-1 3.8.0-32-generic #47~precise1-Ubuntu\", same kernel on Network Node\" and others nodes too (Ubuntu 12.04.3 installed from scratch for this Havana deployment).\n>\n>\n>The only difference I can see right now, between my two hypervisors, is that my second is just a spare machine, with a slow CPU but, I don\'t think it will have a negative impact at the network?throughput, since I have only 1 Instance running into it (plus a qemu-nbd process eating 90% of its CPU). I\'ll replace this CPU tomorrow, to redo this tests again but, I don\'t think that this is the source of my problem. The MOBOs of two hypervisors are?identical, 1 3Com (manageable) switch connecting the two.\n>\n>\n>Thanks!\n>Thiago\n>\n>\n>\n>On 25 October 2013 07:15, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>Hi Thiago,\n>>\n>>you have configured DHCP to push out a MTU of 1400. Can you confirm that the 1400 MTU is actually getting out to the instances by running \'ip link\' on them?\n>>\n>>There is an open problem where the veth used to connect the OVS and Linux bridges causes a performance drop on some kernels - https://bugs.launchpad.net/nova-project/+bug/1223267 .? If you are using the LibvirtHybridOVSBridgeDriver VIF driver, can you try changing to LibvirtOpenVswitchDriver and repeat the iperf test between instances on different compute-nodes.\n>>\n>>What NICs (maker+model) are you using? You could try disabling any off-load functionality - \'ethtool -k <iface-used-for-gre>\'.\n>>\n>>What kernal are you using: \'uname -a\'?\n>>\n>>Re, Darragh.\n>>\n>>\n>>> Hi Daniel,\n>>\n>>>\n>>> I followed that page, my Instances MTU is lowered by DHCP Agent but, same\n>>> result: poor network performance (internal between Instances and when\n>>> trying to reach the Internet).\n>>>\n>>> No matter if I use \"dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf +\n>>> \"dhcp-option-force=26,1400\"\" for my Neutron DHCP agent, or not (i.e. MTU =\n>>> 1500), the result is almost the same.\n>>>\n>>> I\'ll try VXLAN (or just VLANs) this weekend to see if I can get better\n>>> results...\n>>>\n>>> Thanks!\n>>> Thiago\n>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131025/fed9be83/attachment.html>\n\n','<CAJSM8J12FeH6s3cK5BCqjWh2kFf+SVCLv25N4vqPHR-agE2wtw@mail.gmail.com>',NULL),('<1382714218.36448817@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-26 02:16:58',39600,'2013-10-25 15:16:58',NULL,'[Openstack-docs] Install Guide: nova-network setup?','There\'s no problem with this ... we\'re using multi host HA. no need for anything on controller\n\n\n\n',NULL,NULL),('<1382716127-sup-2842@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-25 09:04:31',-25200,'2013-10-25 16:04:31',NULL,'[openstack-dev] [nova] Thoughs please on how to address a\n	problem with mutliple deletes leading to a nova-compute\n	thread pool problem','Excerpts from Day, Phil\'s message of 2013-10-25 03:46:01 -0700:\n> Hi Folks,\n> \n> We\'re very occasionally seeing problems where a thread processing a create hangs (and we\'ve seen when taking to Cinder and Glance).  Whilst those issues need to be hunted down in their own rights, they do show up what seems to me to be a weakness in the processing of delete requests that I\'d like to get some feedback on.\n> \n> Delete is the one operation that is allowed regardless of the Instance state (since it\'s a one-way operation, and users should always be able to free up their quota).   However when we get a create thread hung in one of these states, the delete requests when they hit the manager will also block as they are synchronized on the uuid.   Because the user making the delete request doesn\'t see anything happen they tend to submit more delete requests.   The Service is still up, so these go to the computer manager as well, and eventually all of the threads will be waiting for the lock, and the compute manager will stop consuming new messages.\n> \n> The problem isn\'t limited to deletes - although in most cases the change of state in the API means that you have to keep making different calls to get past the state checker logic to do it with an instance stuck in another state.   Users also seem to be more impatient with deletes, as they are trying to free up quota for other things. \n> \n> So while I know that we should never get a thread into a hung state into the first place, I was wondering about one of the following approaches to address just the delete case:\n> \n> i) Change the delete call on the manager so it doesn\'t wait for the uuid lock.  Deletes should be coded so that they work regardless of the state of the VM, and other actions should be able to cope with a delete being performed from under them.  There is of course no guarantee that the delete itself won\'t block as well. \n> \n\nAlmost anything unexpected that isn\'t \"start the creation\" results in\njust marking an instance as an ERROR right? So this approach is actually\npretty straight forward to implement. You don\'t really have to make\nother operations any more intelligent than they already should be in\ncleaning up half-done operations when they encounter an error. It might\nbe helpful to suppress or de-prioritize logging of these errors when it\nis obvious that this result was intended.\n\n> ii) Record in the API server that a delete has been started (maybe enough to use the task state being set to DELETEING in the API if we\'re sure this doesn\'t get cleared), and add a periodic task in the compute manager to check for and delete instances that are in a \"DELETING\" state for more than some timeout. Then the API, knowing that the delete will be processes eventually can just no-op any further delete requests.\n> \n\ns/API server/database/ right? I like the coalescing approach where you\nno longer take up more resources for repeated requests.\n\nI don\'t like the garbage collection aspect of this plan though.Garbage\ncollection is a trade off of user experience for resources. If your GC\nthread gets too far behind your resources will be exhausted. If you make\nit too active, it wastes resources doing the actual GC. Add in that you\nhave a timeout before things can be garbage collected and I think this\nbecomes a very tricky thing to tune, and it may not be obvious it needs\nto be tuned until you have a user who does a lot of rapid create/delete\ncycles.\n\n> iii) Add some hook into the ServiceGroup API so that the timer could depend on getting a free thread from the compute manager pool (ie run some no-op task) - so that of there are no free threads then the service becomes down. That would (eventually) stop the scheduler from sending new requests to it, and make deleted be processed in the API server but won\'t of course help with commands for other instances on the same host.\n> \n\nI\'m not sure I understand this one.\n\n> iv) Move away from having a general topic and thread pool for all requests, and start a listener on an instance specific topic for each running instance on a host (leaving the general topic and pool just for creates and other non-instance calls like the hypervisor API).   Then a blocked task would only affect request for a specific instance.\n> \n\nA topic per record will get out of hand rapidly. If you think of the\ninstance record in the DB as the topic though, then (i) and (iv) are\nactually quite similar.\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006E9C155@G6W2490.americas.hpqcorp.net>',NULL),('<1382717498.5452.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-25 17:11:38',3600,'2013-10-25 16:11:38',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','\n\nthe uneven ssh performance is strange - maybe learning on the tunnel mesh is not stablizing. It is easy to mess it up by giving a wrong local_ip in the ovs-plugin config file. Check the tunnels ports on br-tun with \'ovs-vsctl show\'. Is each one using the correct IPs? Br-tun should have N-1 gre-x ports - no more! Maybe you can put \'ovs-vsctl show\' from the nodes on paste.openstack if there are not to many?\n\nRe, Darragh.\n\n\n\n\nOn Friday, 25 October 2013, 16:20, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n \nI think can say... \"YAY!!\" ? ?:-D\n>\n>\n>With \"LibvirtOpenVswitchDriver\" my internal communication is the double now! It goes from ~200 (with LibvirtHybridOVSBridgeDriver) to 400Mbit/s (with LibvirtOpenVswitchDriver)! Still far from 1Gbit/s (my physical path limit) but, more acceptable now.\n>\n>\n>The command \"ethtool -K eth1 gro off\" still makes no difference.\n>\n>\n>So, there is only 1 remain problem, when traffic pass trough L3 / Namespace, it is still useless. Even the SSH connection into my Instances, via its Floating IPs, is slow as hell, sometimes it just stops responding for a few seconds, and becomes online again \"out-of-nothing\"...\n>\n>\n>I just detect a weird \"behavior\", when I run \"apt-get update\" from instance-1, it is slow as I said plus, its ssh connection (where I\'m running apt-get update), stops responding right after I run \"apt-get update\" AND, all my others ssh connections also stops working too! For a few seconds... This means that when I run \"apt-get update\" from within instance-1, the SSH session of instance-2 is affected too!! There is something pretty bad going on at L3 / Namespace.\n>\n>\n>BTW, do you think that a ~400MBit/sec intra-vm-communication (GRE tunnel) on top of a 1Gbit ethernet is acceptable?! It is still less than a half...\n>\n>\n>Thank you!\n>Thiago\n>\n>\n>On 25 October 2013 12:28, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>Hi Thiago,\n>>\n>>\n>>for the VIF error: you will need to change qemu.conf as described here:\n>>http://openvswitch.org/openstack/documentation/\n>>\n>>\n>>Re, Darragh.\n>>\n>>\n>>\n>>\n>>On Friday, 25 October 2013, 15:14, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n>> \n>>Hi Darragh,\n>>>\n>>>\n>>>Yes, Instances are getting MTU 1400.\n>>>\n>>>\n>>>I\'m using?LibvirtHybridOVSBridgeDriver at my Compute Nodes. I\'ll check BG 1223267 right now!?\n>>>\n>>>\n>>>\n>>>\n>>>The?LibvirtOpenVswitchDriver doesn\'t work, look:\n>>>\n>>>\n>>>http://paste.openstack.org/show/49709/\n>>>\n>>>\n>>>\n>>>http://paste.openstack.org/show/49710/\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>My NICs are \"RTL8111/8168/8411 PCI Express Gigabit Ethernet\", Hypervisors motherboard are MSI-890FXA-GD70.\n>>>\n>>>\n>>>The command \"ethtool -K eth1 gro off\" did not had any effect on the communication between instances on different hypervisors, still poor, around 248Mbit/sec, when its physical path reach 1Gbit/s (where GRE is built).\n>>>\n>>>\n>>>My Linux version is \"Linux hypervisor-1 3.8.0-32-generic #47~precise1-Ubuntu\", same kernel on Network Node\" and others nodes too (Ubuntu 12.04.3 installed from scratch for this Havana deployment).\n>>>\n>>>\n>>>The only difference I can see right now, between my two hypervisors, is that my second is just a spare machine, with a slow CPU but, I don\'t think it will have a negative impact at the network?throughput, since I have only 1 Instance running into it (plus a qemu-nbd process eating 90% of its CPU). I\'ll replace this CPU tomorrow, to redo this tests again but, I don\'t think that this is the source of my problem. The MOBOs of two hypervisors are?identical, 1 3Com (manageable) switch connecting the two.\n>>>\n>>>\n>>>Thanks!\n>>>Thiago\n>>>\n>>>\n>>>\n>>>On 25 October 2013 07:15, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>>>\n>>>Hi Thiago,\n>>>>\n>>>>you have configured DHCP to push out a MTU of 1400. Can you confirm that the 1400 MTU is actually getting out to the instances by running \'ip link\' on them?\n>>>>\n>>>>There is an open problem where the veth used to connect the OVS and Linux bridges causes a performance drop on some kernels - https://bugs.launchpad.net/nova-project/+bug/1223267 .? If you are using the LibvirtHybridOVSBridgeDriver VIF driver, can you try changing to LibvirtOpenVswitchDriver and repeat the iperf test between instances on different compute-nodes.\n>>>>\n>>>>What NICs (maker+model) are you using? You could try disabling any off-load functionality - \'ethtool -k <iface-used-for-gre>\'.\n>>>>\n>>>>What kernal are you using: \'uname -a\'?\n>>>>\n>>>>Re, Darragh.\n>>>>\n>>>>\n>>>>> Hi Daniel,\n>>>>\n>>>>>\n>>>>> I followed that page, my Instances MTU is lowered by DHCP Agent but, same\n>>>>> result: poor network performance (internal between Instances and when\n>>>>> trying to reach the Internet).\n>>>>>\n>>>>> No matter if I use \"dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf +\n>>>>> \"dhcp-option-force=26,1400\"\" for my Neutron DHCP agent, or not (i.e. MTU =\n>>>>> 1500), the result is almost the same.\n>>>>>\n>>>>> I\'ll try VXLAN (or just VLANs) this weekend to see if I can get better\n>>>>> results...\n>>>>>\n>>>>> Thanks!\n>>>>> Thiago\n>>>>\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131025/3e0c1e78/attachment.html>\n\n','<CAJSM8J0BdqiZganE67ya6UUma5T1Es1T5KAjvj2ip0gjrwsC6A@mail.gmail.com>',NULL),('<1382717613-sup-297@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-25 09:25:50',-25200,'2013-10-25 16:25:50',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Angus Salkeld\'s message of 2013-10-24 18:48:16 -0700:\n> On 24/10/13 11:54 +0200, Patrick Petit wrote:\n> >Hi Clint,\n> >Thank you! I have few replies/questions in-line.\n> >Cheers,\n> >Patrick\n> >On 10/23/13 8:36 PM, Clint Byrum wrote:\n> >>I think this fits into something that I want for optimizing\n> >>os-collect-config as well (our in-instance Heat-aware agent). That is\n> >>a way for us to wait for notification of changes to Metadata without\n> >>polling.\n> >Interesting... If I understand correctly that\'s kinda replacement of \n> >cfn-hup... Do you have a blueprint pointer or something more \n> >specific? While I see the benefits of it, in-instance notifications \n> >is not really what we are looking for. We are looking for a \n> >notification service that exposes an API whereby listeners can \n> >register for Heat notifications. AWS Alarming / CloudFormation has \n> >that. Why not Ceilometer / Heat? That would be extremely valuable for \n> >those who build PaaS-like solutions above Heat. To say it bluntly, \n> >I\'d like to suggest we explore ways to integrate Heat with Marconi.\n> \n> Yeah, I am trying to do a PoC of this now. I\'ll let you know how\n> it goes.\n> \n> I am trying to implement the following:\n> \n> heat_template_version: 2013-05-23\n> parameters:\n>    key_name:\n>      type: String\n>    flavor:\n>      type: String\n>      default: m1.small\n>    image:\n>      type: String\n>      default: fedora-19-i386-heat-cfntools\n> resources:\n>    config_server:\n>      type: OS::Marconi::QueueServer\n>      properties:\n>        image: {get_param: image}\n>        flavor: {get_param: flavor}\n>        key_name: {get_param: key_name}\n> \n>    configA:\n>      type: OS::Heat::OrderedConfig\n>      properties:\n>        marconi_server: {get_attr: [config_server, url]}\n>        hosted_on: {get_resource: serv1}\n>        script: |\n>          #!/bin/bash\n>          logger \"1. hello from marconi\"\n> \n>    configB:\n>      type: OS::Heat::OrderedConfig\n>      properties:\n>        marconi_server: {get_attr: [config_server, url]}\n>        hosted_on: {get_resource: serv1}\n>        depends_on: {get_resource: configA}\n>        script: |\n>          #!/bin/bash\n>          logger \"2. hello from marconi\"\n> \n>    serv1:\n>      type: OS::Nova::Server\n>      properties:\n>        image: {get_param: image}\n>        flavor: {get_param: flavor}\n>        key_name: {get_param: key_name}\n>        user_data: |\n>          #!/bin/sh\n>          # poll <marconi url>/v1/queues/{hostname}/messages\n>          # apply config\n>          # post a response message with any outputs\n>          # delete request message\n> \n\nIf I may diverge this a bit, I\'d like to consider the impact of\nhosted_on on reusability in templates. hosted_on feels like an\nanti-pattern, and I\'ve never seen anything quite like it. It feels wrong\nfor a well contained component to then reach out and push itself onto\nsomething else which has no mention of it.\n\nI\'ll rewrite your template as I envision it working:\n\nresources:\n   config_server:\n     type: OS::Marconi::QueueServer\n     properties:\n       image: {get_param: image}\n       flavor: {get_param: flavor}\n       key_name: {get_param: key_name}\n\n   configA:\n     type: OS::Heat::OrderedConfig\n     properties:\n       marconi_server: {get_attr: [config_server, url]}\n       script: |\n         #!/bin/bash\n         logger \"1. hello from marconi\"\n\n   configB:\n     type: OS::Heat::OrderedConfig\n     properties:\n       marconi_server: {get_attr: [config_server, url]}\n       depends_on: {get_resource: configA}\n       script: |\n         #!/bin/bash\n         logger \"2. hello from marconi\"\n\n   serv1:\n     type: OS::Nova::Server\n     properties:\n       image: {get_param: image}\n       flavor: {get_param: flavor}\n       key_name: {get_param: key_name}\n       components:\n         - configA\n         - configB\n       user_data: |\n         #!/bin/sh\n         # poll <marconi url>/v1/queues/{hostname}/messages\n         # apply config\n         # post a response message with any outputs\n         # delete request message\n\nThis only becomes obvious why it is important when you want to do this:\n\n    configC:\n      type: OS::Heat::OrderedConfig\n      properties:\n        script: |\n          #!/bin/bash\n          logger \"?. I can race with A, no dependency needed\"\n\n    serv2:\n      type: OS::Nova::Server\n      properties:\n      ...\n      components:\n        - configA\n        - configC\n\nThis is proper composition, where the caller defines the components, not\nthe callee. Now you can re-use configA with a different component in the\nsame template. As we get smarter we can have these configs separate from\nthe template and reusable across templates.\n\nAnyway, I\'d like to see us stop talking about hosted_on, and if it has\nbeen implemented, that it be deprecated and eventually removed, as it is\njust plain confusing.\n\n\n','<20131025014816.GA28808@redhat.com>',NULL),('<1382722105.16084.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-25 18:28:25',3600,'2013-10-25 17:28:25',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','\n\nok, the tunnels look fine. One thing that looks funny on the network node are these untagged tap* devices. I guess you switched to using veths and then? switched back to not using them. I don\'t know if they matter, but you should clean them up by stopping everthing, running neutron-ovs-cleanup (check bridges empty) and reboot.\n\nBridge br-int Port \"tapa1376f61-05\" Interface \"tapa1376f61-05\" ...\nPort \"qr-a1376f61-05\"\n            tag: 1\n            Interface \"qr-a1376f61-05\"\n                type: internal\n\nRe, Darragh.\n\n\n\n\nOn Friday, 25 October 2013, 17:28, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n \nHere we go:\n>\n>\n>---\n>root at net-node-1:~# grep local_ip /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini?\n>local_ip = 10.20.2.52\n>\n>\n>root at net-node-1:~# ip r | grep 10.\\20\n>10.20.2.0/24 dev eth1 ?proto kernel ?scope link ?src 10.20.2.52?\n>---\n>\n>\n>---\n>root at hypervisor-1:~# grep local_ip /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini\n>local_ip = 10.20.2.53\n>\n>\n>root at hypervisor-1:~# ip r | grep 10.\\20\n>10.20.2.0/24 dev eth1 ?proto kernel ?scope link ?src 10.20.2.53?\n>---\n>\n>\n>---\n>root at hypervisor-2:~# grep local_ip /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini\n>local_ip = 10.20.2.57\n>\n>\n>root at hypervisor-2:~# ip r | grep 10.\\20\n>10.20.2.0/24 dev eth1 ?proto kernel ?scope link ?src 10.20.2.57\n>---\n>\n>\n>Each \"ovs-vsctl show\":\n>\n>\n>net-node-1:?http://paste.openstack.org/show/49727/\n>\n>\n>hypervisor-1:?http://paste.openstack.org/show/49728/\n>\n>\n>hypervisor-2:?http://paste.openstack.org/show/49729/\n>\n>\n>\n>\n>\n>Best,\n>Thiago\n>\n>\n>\n>On 25 October 2013 14:11, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>\n>>\n>>the uneven ssh performance is strange - maybe learning on the tunnel mesh is not stablizing. It is easy to mess it up by giving a wrong local_ip in the ovs-plugin config file. Check the tunnels ports on br-tun with \'ovs-vsctl show\'. Is each one using the correct IPs? Br-tun should have N-1 gre-x ports - no more! Maybe you can put \'ovs-vsctl show\' from the nodes on paste.openstack if there are not to many?\n>>\n>>\n>>Re, Darragh.\n>>\n>>\n>>\n>>\n>>On Friday, 25 October 2013, 16:20, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n>> \n>>I think can say... \"YAY!!\" ? ?:-D\n>>>\n>>>\n>>>With \"LibvirtOpenVswitchDriver\" my internal communication is the double now! It goes from ~200 (with LibvirtHybridOVSBridgeDriver) to 400Mbit/s (with LibvirtOpenVswitchDriver)! Still far from 1Gbit/s (my physical path limit) but, more acceptable now.\n>>>\n>>>\n>>>The command \"ethtool -K eth1 gro off\" still makes no difference.\n>>>\n>>>\n>>>So, there is only 1 remain problem, when traffic pass trough L3 / Namespace, it is still useless. Even the SSH connection into my Instances, via its Floating IPs, is slow as hell, sometimes it just stops responding for a few seconds, and becomes online again \"out-of-nothing\"...\n>>>\n>>>\n>>>I just detect a weird \"behavior\", when I run \"apt-get update\" from instance-1, it is slow as I said plus, its ssh connection (where I\'m running apt-get update), stops responding right after I run \"apt-get update\" AND, all my others ssh connections also stops working too! For a few seconds... This means that when I run \"apt-get update\" from within instance-1, the SSH session of instance-2 is affected too!! There is something pretty bad going on at L3 / Namespace.\n>>>\n>>>\n>>>BTW, do you think that a ~400MBit/sec intra-vm-communication (GRE tunnel) on top of a 1Gbit ethernet is acceptable?! It is still less than a half...\n>>>\n>>>\n>>>Thank you!\n>>>Thiago\n>>>\n>>>\n>>>On 25 October 2013 12:28, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>>>\n>>>Hi Thiago,\n>>>>\n>>>>\n>>>>for the VIF error: you will need to change qemu.conf as described here:\n>>>>http://openvswitch.org/openstack/documentation/\n>>>>\n>>>>\n>>>>Re, Darragh.\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>On Friday, 25 October 2013, 15:14, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n>>>> \n>>>>Hi Darragh,\n>>>>>\n>>>>>\n>>>>>Yes, Instances are getting MTU 1400.\n>>>>>\n>>>>>\n>>>>>I\'m using?LibvirtHybridOVSBridgeDriver at my Compute Nodes. I\'ll check BG 1223267 right now!?\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>The?LibvirtOpenVswitchDriver doesn\'t work, look:\n>>>>>\n>>>>>\n>>>>>http://paste.openstack.org/show/49709/\n>>>>>\n>>>>>\n>>>>>\n>>>>>http://paste.openstack.org/show/49710/\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>My NICs are \"RTL8111/8168/8411 PCI Express Gigabit Ethernet\", Hypervisors motherboard are MSI-890FXA-GD70.\n>>>>>\n>>>>>\n>>>>>The command \"ethtool -K eth1 gro off\" did not had any effect on the communication between instances on different hypervisors, still poor, around 248Mbit/sec, when its physical path reach 1Gbit/s (where GRE is built).\n>>>>>\n>>>>>\n>>>>>My Linux version is \"Linux hypervisor-1 3.8.0-32-generic #47~precise1-Ubuntu\", same kernel on Network Node\" and others nodes too (Ubuntu 12.04.3 installed from scratch for this Havana deployment).\n>>>>>\n>>>>>\n>>>>>The only difference I can see right now, between my two hypervisors, is that my second is just a spare machine, with a slow CPU but, I don\'t think it will have a negative impact at the network?throughput, since I have only 1 Instance running into it (plus a qemu-nbd process eating 90% of its CPU). I\'ll replace this CPU tomorrow, to redo this tests again but, I don\'t think that this is the source of my problem. The MOBOs of two hypervisors are?identical, 1 3Com (manageable) switch connecting the two.\n>>>>>\n>>>>>\n>>>>>Thanks!\n>>>>>Thiago\n>>>>>\n>>>>>\n>>>>>\n>>>>>On 25 October 2013 07:15, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>>>>>\n>>>>>Hi Thiago,\n>>>>>>\n>>>>>>you have configured DHCP to push out a MTU of 1400. Can you confirm that the 1400 MTU is actually getting out to the instances by running \'ip link\' on them?\n>>>>>>\n>>>>>>There is an open problem where the veth used to connect the OVS and Linux bridges causes a performance drop on some kernels - https://bugs.launchpad.net/nova-project/+bug/1223267 .? If you are using the LibvirtHybridOVSBridgeDriver VIF driver, can you try changing to LibvirtOpenVswitchDriver and repeat the iperf test between instances on different compute-nodes.\n>>>>>>\n>>>>>>What NICs (maker+model) are you using? You could try disabling any off-load functionality - \'ethtool -k <iface-used-for-gre>\'.\n>>>>>>\n>>>>>>What kernal are you using: \'uname -a\'?\n>>>>>>\n>>>>>>Re, Darragh.\n>>>>>>\n>>>>>>\n>>>>>>> Hi Daniel,\n>>>>>>\n>>>>>>>\n>>>>>>> I followed that page, my Instances MTU is lowered by DHCP Agent but, same\n>>>>>>> result: poor network performance (internal between Instances and when\n>>>>>>> trying to reach the Internet).\n>>>>>>>\n>>>>>>> No matter if I use \"dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf +\n>>>>>>> \"dhcp-option-force=26,1400\"\" for my Neutron DHCP agent, or not (i.e. MTU =\n>>>>>>> 1500), the result is almost the same.\n>>>>>>>\n>>>>>>> I\'ll try VXLAN (or just VLANs) this weekend to see if I can get better\n>>>>>>> results...\n>>>>>>>\n>>>>>>> Thanks!\n>>>>>>> Thiago\n>>>>>>\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131025/0746d874/attachment-0001.html>\n\n','<CAJSM8J3Np_W13mag5oapFcvOVbkD_ocwi1xy_C3o7+x1gcp8iA@mail.gmail.com>',NULL),('<1382751940.434.1367129205032.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:06:45',0,'2013-04-28 06:06:45',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python26-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-cinder-python26-stable-grizzly/18/>\n\n\n\n',NULL,NULL),('<1382776118.52791.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-26 09:28:38',3600,'2013-10-26 08:28:38',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','Hi Thiago,\n\nso just to confirm - on the same netnode machine, with the same OS, kernal and OVS versions - Grizzly is ok and Havana is not?\n\nAlso, on the network node, are there any errors in the neutron logs, the syslog, or /var/log/openvswitch/* ?\n\n\nRe, Darragh.\n\n\n\n\nOn Saturday, 26 October 2013, 5:25, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n \nLOL... One day, Internet via \"Quantum Entanglement\"! Oops, Neutron! ? ? =P\n>\n>\n>\n>I\'ll ignore the problems related to the \"performance between two instances on different hypervisors\" for now. My priority is the connectivity issue with the External networks... At least, internal is slow but it works.\n>\n>\n>I\'m about to remove the L3 Agent / Namespaces entirely from my topology... It is a shame because it is pretty cool! With Grizzly I had no problems at all. Plus, I need to put Havana into production ASAP! ? ?:-/\n>\n>\n>Why I\'m giving it up (of L3 / NS) for now? Because I tried:\n>\n>\n>The option \"tenant_network_type\" with gre, vxlan and vlan (range physnet1:206:256 configured at the 3Com switch as tagged).\n>\n>\n>From the instances, the connection with External network is always slow, no matter if I choose for Tenants, GRE, VXLAN or VLAN.\n>\n>\n>For example, right now, I\'m using VLAN, same problem.\n>\n>\n>Don\'t you guys think that this can be a problem with the bridge \"br-ex\" and its internals ? Since I swapped the \"Tenant Network Type\" 3 times, same result... But I still did not removed the br-ex from the scene.\n>\n>\n>If someone wants to debug it, I can give the root password, no problem, it is just a lab... ? =)\n>\n>\n>Thanks!\n>Thiago\n>\n>\n>On 25 October 2013 19:45, Rick Jones <rick.jones2 at hp.com> wrote:\n>\n>On 10/25/2013 02:37 PM, Martinx - ????? wrote:\n>>\n>>WOW!! Thank you for your time Rick! Awesome answer!! ? ?=D\n>>>\n>>>I\'ll do this tests (with ethtool GRO / CKO) tonight but, do you think\n>>>that this is the main root of the problem?!\n>>>\n>>>\n>>>I mean, I\'m seeing two distinct problems here:\n>>>\n>>>1- Slow connectivity to the External network plus SSH lags all over the\n>>>cloud (everything that pass trough L3 / Namespace is problematic), and;\n>>>\n>>>2- Communication between two Instances on different hypervisors (i.e.\n>>>maybe it is related to this GRO / CKO thing).\n>>>\n>>>\n>>>So, two different problems, right?!\n>>>\n>>\nOne or two problems I cannot say. ? ?Certainly if one got the benefit of stateless offloads in one direction and not the other, one could see different performance limits in each direction.\n>>\n>>All I can really say is I liked it better when we were called Quantum, because then I could refer to it as \"Spooky networking at a distance.\" ?Sadly, describing Neutron as \"Networking with no inherent charge\" doesn\'t work as well :)\n>>\n>>rick jones\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131026/d992e727/attachment.html>\n\n','<CAJSM8J1Dkxy015G2=+wXH7Z05Vb7o__FRnokk40_e0_x4JM_Uw@mail.gmail.com>',NULL),('<1382779412-sup-1593@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-26 02:25:01',-25200,'2013-10-26 09:25:01',NULL,'[openstack-dev] [heat] Proposal for new heat-core member','Excerpts from Steven Dake\'s message of 2013-10-25 12:12:54 -0700:\n> Hi,\n> \n> I would like to propose Randall Burt for Heat Core.  He has shown \n> interest in Heat by participating in IRC and providing high quality \n> reviews.  The most important aspect in my mind of joining Heat Core is \n> output and quality of reviews.  Randall has been involved in Heat \n> reviews for atleast 6 months.  He has had 172 reviews over the last 6 \n> months staying \"in the pack\" [1] of core heat reviewers.  His 90 day \n> stats are also encouraging, with 97 reviews (compared to the top \n> reviewer Steve Hardy with 444 reviews).  Finally his 30 day stats also \n> look good, beating out 3 core reviewers [2] on output with good quality \n> reviews.\n> \n\n+1\n\n!!\n\n> Please have a vote +1/-1 and take into consideration: \n> https://wiki.openstack.org/wiki/Heat/CoreTeam\n> \n> Regards,\n> -steve\n> \n> [1]http://russellbryant.net/openstack-stats/heat-reviewers-180.txt \n> <http://russellbryant.net/openstack-stats/heat-reviewers-180.txt>\n> [2]http://russellbryant.net/openstack-stats/heat-reviewers-30.txt \n> <http://russellbryant.net/openstack-stats/heat-reviewers-30.txt>\n\n\n','<526AC2B6.7060303@redhat.com>',NULL),('<1382948291.9301.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 08:18:11',0,'2013-10-28 08:18:11',NULL,'[openstack-dev] RFC: Filtering boring commit subjects from\n ChangeLog','On Sun, 2013-10-27 at 21:50 -0400, Monty Taylor wrote:\n> Hey all!\n> \n> We\'re adding a little bit of code to pbr to make the auto-generated\n> ChangeLog files a bit more useful. Currently, they are just the git\n> changelog, which is kinda useless. So we wrote this:\n> \n> https://review.openstack.org/#/c/52367/\n> \n> which produces output like this:\n> \n> http://paste.openstack.org/show/49999  # on a tag\n> and\n> http://paste.openstack.org/show/50001  # not on a tag\n> \n> It underscores the need for commit subjects to communicate something,\n> which is a good thing.\n> \n> With that there, it makes changes like:\n> * Updated from global requirements\n> and\n> * Update my mailmap\n> \n> Kinda lame in the changelog. So we were thinking - what if we recognized\n> one or more subject tags to skip things going into the ChangeLog file.\n> My first thought was:\n> \n> NIT:  # use this for tiny commits that are not really worth changelogging\n> \n> and\n> \n> AUTO: # use for commits generated by our machines, such as the global\n> requirements sync or the Translations sync.\n> \n> What do people think? Should we bother? Are those good? Would something\n> else be better? It\'s sort of an opt-in feature, so adding it SHOULDN\'T\n> bork too many people.\n\nSo long as it isn\'t so SHOUTY it could work out nicely :)\n\nGetting these ChangeLogs published is goodness - the more the more\npeople see their one-line message around the place, the more people\nthey\'ll make an effort to write a decent one.\n\nCheers,\nMark.\n\n\n\n','<526DC2DD.2030901@inaugust.com>',NULL),('<1382949117.97911.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-28 08:31:57',0,'2013-10-28 08:31:57',NULL,'[Openstack] MTU 1400? No thanks! - VXLAN users not affected!','Hi Thiago,\n\nyou don\'t say what version of OVS. It must be >=1.10.0 because you are using\nVXLAN. From that version the way MTU and tunnels is handled has changed.\n\nSee \"- Tunneling: \" in http://openvswitch.org/releases/NEWS-1.10.0\n\nHere is a tcpdump with with OVS 1.10.2? where all interfaces have an MTU of \n\n1500. GRE tunnels are used and there are no connectivity problems.\n\nhttp://paste.openstack.org/show/50025/\nThe messages with \"IP truncated-ip - 18 bytes missing!\" mean IP fragmentation \n\nis happening.\n\n\nRe, Darragh.\n\n\n> Guys,\n> \n> I am not detecting any problems related to \"MTU = 1500\" when using VXLAN!\n> \n> It is easy to reproduce the \"GRE MTU problem\", when using GRE tunnels with\n> MTU = 1500, from a Instance, it is impossible to use RubyGems (Ubuntu 12.04\n> Instance), for example, \"gem install bundler\" (neither \"bundle install\"\n> your RoR App) doesn\'t work with MTU 1500 on top of a GRE tunnel, with MTU\n> 1400 is fine.\n> \n> But, now with VXLAN, I\'m using MTU 1500 again without any problems!\n> \n> Honestly, I don\'t know for sure if RubyGems changed too or, if it is\n> related to VXLAN being a bit better than GRE, anyway, I\'ll keep my Havana\n> cloud running with MTU 1500 from now on.\n> \n> Cheers!\n> Thiago\n\n\n',NULL,NULL),('<1382949410.9301.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-10-28 08:36:50',0,'2013-10-28 08:36:50',NULL,'[openstack-tc] Dropping in on the board meeting in HK?','And it\'s open to everyone, not just TC members. Bring friends :)\n\nMark.\n\nOn Sun, 2013-10-27 at 21:54 -0400, Monty Taylor wrote:\n> https://wiki.openstack.org/wiki/Governance/Foundation/4Nov2013BoardMeeting\n> \n> 10:50 - 11:50 	Executive session\n> \n> Is the only time we\'ll kick you out of the room.\n> \n> On 10/27/2013 09:09 PM, Michael Still wrote:\n> > Please sir, when are the non-executive bits?\n> > \n> > Will you save a chair for me this time?\n> > \n> > Michael\n> > \n> > On Mon, Oct 28, 2013 at 11:45 AM, Monty Taylor <mordred at inaugust.com> wrote:\n> >> You are all 100% welcome for all of it except the executive session. I\'d\n> >> love to have you there.\n> >>\n> >> On 10/27/2013 08:41 PM, Michael Still wrote:\n> >>> Does anyone here know if there\'s any plan for TC members to \"drop in\"\n> >>> on the board meeting like we did in San Diego? I\'m just wondering if I\n> >>> should allow time for that or not.\n> >>>\n> >>> Thanks,\n> >>> Michael\n> >>>\n> >>\n> >> _______________________________________________\n> >> OpenStack-TC mailing list\n> >> OpenStack-TC at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> > \n> > \n> > \n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n\n','<526DC3BD.7030908@inaugust.com>',NULL),('<1382950817.45314.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-28 09:00:17',0,'2013-10-28 09:00:17',NULL,'[Openstack] Directional network performance issues with Neutron\n	+ OpenvSwitch','Thiago,\n\nsome more answers below.\n\nBtw: I saw the problem with a \"qemu-nbd -c\" process using all the cpu on the compute. It happened just once - must be a bug in it. You can disable libvirt injection if you don\'t want it by setting \"libvirt_inject_partition = -2\" in nova.conf.\n\n\nOn Saturday, 26 October 2013, 16:58, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n\nHi Darragh,\n>\n>\n>Yes, on the same net-node machine, Grizzly works, Havana don\'t... But, for Grizzly, I have Ubuntu 12.04 with Linux 3.2 and >OVS?1.4.0-1ubuntu1.6.\n\n\nso we don\'t know if the problem is due to Neutron, the Ubuntu kernel or OVS. I suspect the kernel as it implements the routing/natting, interfaces and namespaces.? I don\'t think Neutron Havana changes how these things are setup too much.\n\nCan you try running Havana on a network node with the Linux 3.2 kernel?\n\n\n>\n>\n>If I replace the Havana net-node hardware entirely, the problem persist (i.e. it \"follows\" Havana net-node), so, I think, it can not be related to the hardware.\n>\n>\n>I tried Havana with both OVS 1.10.2 (from Cloud Archive) and with OVS 1.11.0 (compiled and installed by myself using dpkg-buildpackage / dpkg).\n>\n>\n>My logs (including Open vSwitch) right after starting an Instance (nothing at OVS logs):\n>\n>\n>http://paste.openstack.org/show/49870/\n>\n>\n>\n>I tried everything, including installing the Network Node on top of a KVM virtual machine or directly on a dedicated server, same result, the problem follows Hanava node (virtual or physical). Grizzly Network Node works both on a KVM VM or on a dedicated server.\n>\n>\n>Regards,\n>Thiago\n>\n>\n>\n>On 26 October 2013 06:28, Darragh OReilly wrote:\n>\n>Hi Thiago,\n>>\n>>so just to confirm - on the same netnode machine, with the same OS, kernal and OVS versions - Grizzly is ok and Havana is not?\n>>\n>>Also, on the network node, are there any errors in the neutron logs, the syslog, or /var/log/openvswitch/* ?\n>>\n>>\n>>\n>>Re, Darragh.\n>>\n>>\n>>\n>>\n>>On Saturday, 26 October 2013, 5:25, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n>> \n>>LOL... One day, Internet via \"Quantum Entanglement\"! Oops, Neutron! ? ? =P\n>>>\n>>>\n>>>\n>>>I\'ll ignore the problems related to the \"performance between two instances on different hypervisors\" for now. My priority is the connectivity issue with the External networks... At least, internal is slow but it works.\n>>>\n>>>\n>>>I\'m about to remove the L3 Agent / Namespaces entirely from my topology... It is a shame because it is pretty cool! With Grizzly I had no problems at all. Plus, I need to put Havana into production ASAP! ? ?:-/\n>>>\n>>>\n>>>Why I\'m giving it up (of L3 / NS) for now? Because I tried:\n>>>\n>>>\n>>>The option \"tenant_network_type\" with gre, vxlan and vlan (range physnet1:206:256 configured at the 3Com switch as tagged).\n>>>\n>>>\n>>>From the instances, the connection with External network is always slow, no matter if I choose for Tenants, GRE, VXLAN or VLAN.\n>>>\n>>>\n>>>For example, right now, I\'m using VLAN, same problem.\n>>>\n>>>\n>>>Don\'t you guys think that this can be a problem with the bridge \"br-ex\" and its internals ? Since I swapped the \"Tenant Network Type\" 3 times, same result... But I still did not removed the br-ex from the scene.\n>>>\n>>>\n>>>If someone wants to debug it, I can give the root password, no problem, it is just a lab... ? =)\n>>>\n>>>\n>>>Thanks!\n>>>Thiago\n>>>\n>>>\n>>>On 25 October 2013 19:45, Rick Jones <rick.jones2 at hp.com> wrote:\n>>>\n>>>On 10/25/2013 02:37 PM, Martinx - ????? wrote:\n>>>>\n>>>>WOW!! Thank you for your time Rick! Awesome answer!! ? ?=D\n>>>>>\n>>>>>I\'ll do this tests (with ethtool GRO / CKO) tonight but, do you think\n>>>>>that this is the main root of the problem?!\n>>>>>\n>>>>>\n>>>>>I mean, I\'m seeing two distinct problems here:\n>>>>>\n>>>>>1- Slow connectivity to the External network plus SSH lags all over the\n>>>>>cloud (everything that pass trough L3 / Namespace is problematic), and;\n>>>>>\n>>>>>2- Communication between two Instances on different hypervisors (i.e.\n>>>>>maybe it is related to this GRO / CKO thing).\n>>>>>\n>>>>>\n>>>>>So, two different problems, right?!\n>>>>>\n>>>>\nOne or two problems I cannot say. ? ?Certainly if one got the benefit of stateless offloads in one direction and not the other, one could see different performance limits in each direction.\n>>>>\n>>>>All I can really say is I liked it better when we were called Quantum, because then I could refer to it as \"Spooky networking at a distance.\" ?Sadly, describing Neutron as \"Networking with no inherent charge\" doesn\'t work as well :)\n>>>>\n>>>>rick jones\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>\n>\n>\n\n\n','<CAJSM8J3QfBZOaYC8ACbcmy2PHc5nFcPPMt4x=H1C+DYVHKMzXg@mail.gmail.com>',NULL),('<1382973211.484222971@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 11:13:31',-14400,'2013-10-28 15:13:31',NULL,'[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs\n	in Nova','So...I\'ve been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn\'t communicated with until very late in the process. Nothing \"sees\" the servers at the level where the driver is determined. Also there isn\'t a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed.\n\nSo to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level.\n\nDoable, but a much larger task than I first was thinking.\n\nAlso, I don\'t really want the added overhead of getting the api versions before every call, so I\'m thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well.\n\nThoughts?\n\nEddie\n\n-----Original Message-----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nSent: Thursday, October 17, 2013 4:38pm\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova\n\nOn 10/17/2013 03:12 PM, Eddie Sheffield wrote:\n> I don\'t oppose having the version autodiscovered. But I do feel the option should be available to override if desired. I\'ve had many problems with over the years with autoconfiguring systems not doing what I need to be willing to depend on them 100% without a manual override available if at all possible. I\'m thinking particularly for testing or upgrade evaluation scenarios. For example, you want to turn on v2 in glance and evaluate it for a bit before committing to using it for all of your nova nodes.\n> \n> The current patch also had a couple of comments from Dan Prince and Chris Behrens early on when this was brought up there supporting the use of a config value.\n> \n> From the implementation side of things, to do this properly would require some changes to the glanceclient to allow querying of available versions. Lacking that ability currently is one reason this is currently a config value. Once the client supports this, the nova side change would likely be quite small.\n> \n> Might I propose a compromise?\n> \n> 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted.\n> \n> 2) Immediately file two blueprints:\n>    - python-glanceclient - expose a way to discover available versions\n>    - nova - depends on the glanceclient bp and allowing autodiscovery of glance version\n>             and making the config value optional (tho not deprecated / removed)\n\nSupporting both seems reasonable.  At least then *most* people don\'t\nneed to worry about it and it \"just works\", but the override is there if\nnecessary, since multiple people seem to be expressing a desire to have\nit available.\n\nCan we just do this all at once?  Adding this to glanceclient doesn\'t\nseem like a huge task.\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<52604ABB.5030107@redhat.com>',NULL),('<1382975624-sup-6776@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 09:12:49',-25200,'2013-10-28 16:12:49',NULL,'[openstack-dev] distibuted caching system in front of mysql\n	server for openstack transactions','Excerpts from Dolph Mathews\'s message of 2013-10-28 08:40:19 -0700:\n> It\'s not specific to mysql (or sql at all), but keystone is using\n> dogpile.cache around driver calls to a similar effect.\n> \n>   http://dogpilecache.readthedocs.org/en/latest/\n> \n> It can persist to memcache, redis, etc.\n> \n\nI once heard a quote.. \"I had a performance problem, so I added caching.\nnow I have two performance problems.\"\n\nCaching is unbelievably awesome in the jobs it can do well. When the\nproblem is straight forward and the requirements are few, it is just the\nright thing to relieve engineering pressure to make an application more\nscalable.\n\nHowever, IMO, more than narrow, well defined cache usage is a sign\nthat the application needs some reworking to scale.\n\nI like the principle of \"let\'s use dogpile so we don\'t have to reinvent\nmulti-level caching\". However, let\'s make sure we look at each\nperformance issue individually, rather than just throwing them all in\na cache box and waving the memcache wand.\n\n> \n> https://github.com/openstack/keystone/blob/master/keystone/common/cache/core.py\n> \n> On Fri, Oct 25, 2013 at 6:53 PM, Qing He <Qing.He at radisys.com> wrote:\n> \n> >  All,****\n> >\n> > Has anyone looked at the options of putting a distributed caching system\n> > in front of mysql server to improve performance? This should be similar to\n> > Oracle Coherence, or VMware VFabric SQLFire.****\n> >\n> > ** **\n> >\n> > Thanks,****\n> >\n> > ** **\n> >\n> > Qing****\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n\n\n','<CAC=h7gV=fhZZvfvrCjNhAEbFoMvpPZ_755FaYsfT_wXE4D4KoQ@mail.gmail.com>',NULL),('<1382977080-sup-2853@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 09:29:29',-25200,'2013-10-28 16:29:29',NULL,'[openstack-dev] [nova] Thoughs please on how to address a\n	problem with mutliple deletes leading to a nova-compute\n	thread pool problem','Excerpts from Joshua Harlow\'s message of 2013-10-28 09:01:44 -0700:\n> Except I think the CAP theorem would say that u can\'t accurately give back there quota under thing like network partitions.\n> \n> If nova-compute and the message queue have a network partition then u can release there quota but can\'t actually delete there vms. I would actually prefer to not release there quota, but then this should be a deployer decision and not a one size fits all decision (IMHO).\n> \n\nCAP encourages convergence models to satisfy problems with consistency.\nQuotas and records of allocated resources are records of intention and\nwe can converge the physical resources with the expressed intentions\nlater. The speed with which you do that is part of the cost of network\npartition failures and should be considered when assessing and mitigating\nrisk.\n\nIt is really bad customer service to tell somebody \"Yes I know you\'ve\nasked me to stop charging you, but my equipment has failed so I MUST\nkeep charging you.\" Reminds me of that gym membership I tried to\ncancel... _TRIED_.\n\n\n','<3A47F7B2-0537-4EBC-A4A6-DF61841931B5@yahoo-inc.com>',NULL),('<1382978568-sup-1693@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 09:47:40',-25200,'2013-10-28 16:47:40',NULL,'[openstack-dev] [Heat] Network topologies','Excerpts from Steven Hardy\'s message of 2013-10-28 07:47:06 -0700:\n> On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote:\n> > Heat Developers,\n> > \n> > I am one of the core developers for Neutron who is lately working on the\n> > concept of \"Network Topologies\". I want to discuss with you if the\n> > following blueprint will make sense to have in heat or neutron code:\n> > https://blueprints.launchpad.net/neutron/+spec/network-topologies-api\n> > \n> > Basically, I want to let tenants ?save?, ?duplicate? and ?share? network\n> > topologies by means of an API and a standardized JSON format that describes\n> > network topologies. This google document provides detailed description:\n> > https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit#\n> > \n> > There is a concern in Neutron of not duplicating efforts done by Heat team\n> > and also to find the right place for this API.\n> > \n> > The intended work does NOT include any application driven orchestration\n> > system, does NOT include any already existing or vender-specific standard\n> > format for describing topologies, actually we want to standardized one\n> > based on Neutron but it is still on discussion.\n> > \n> > If Heat developers could provide their point of view about this proposal,\n> > wether it should be moved to Heat or it is fine to keep it in Neutron.\n> \n> This seems related to a discussion I had last week re the Neutron services\n> insertion and chaining functionality:\n> \n> https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering\n> \n> It does seem that you (Neutron) are moving towards functionality which\n> requires more explicit management of dependencies, state and workflow, such\n> that it may make sense to implement, some of it at least, in Heat.\n> \n> My opinion is that we should expose all of the underlying Neutron\n> capabilities (individual bits of functionality) via Heat resources, which I\n> think we\'re currently doing quite well (see [1] for the current list of\n> supported functionality)\n> \n> Then any functionality requiring aggregation of resources where\n> dependencies and state are used to create a workflow, should probably\n> happen in Heat, IMHO.  It doesn\'t make sense to me to have two projects\n> building a dependency graph, managing state, and orchestrating workflow for\n> the same underlying Neutron features.\n> \n\nCould not have said it better myself, thanks Steve.\n\nOne thing this brings to mind is the proposal for adopt/abandon. This\nmay be a new use case for that feature in Heat.\n\nNeutron would be able to adopt all of the standing network topology to\ndo the serialization into a HOT template, and give it to the Neutron user.\n\nThen to reverse the process Neutron can accept this Heat template\nback from the user, and just use it to spin up the topology, but then\nimmediately abandon the stack. We get the workflow and dependency feature\nwithout having to leave a dangling stack around for Neutron to clean up.\n\nThat would make it easier for users to interact with this feature without\nactually needing to interact with Heat, and would also reduce Neutron\'s\nfootprint in Heat.\n\n\n','<20131028144705.GB19049@t430slt.redhat.com>',NULL),('<1383001417-sup-6606@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 16:26:07',-25200,'2013-10-28 23:26:07',NULL,'[openstack-dev] [Heat] HOT Software configuration proposal','Excerpts from Steve Baker\'s message of 2013-10-28 15:43:02 -0700:\n> On 10/26/2013 05:25 AM, Clint Byrum wrote:\n> > Excerpts from Angus Salkeld\'s message of 2013-10-24 18:48:16 -0700:\n> >> On 24/10/13 11:54 +0200, Patrick Petit wrote:\n> >>> Hi Clint,\n> >>> Thank you! I have few replies/questions in-line.\n> >>> Cheers,\n> >>> Patrick\n> >>> On 10/23/13 8:36 PM, Clint Byrum wrote:\n> >>>> I think this fits into something that I want for optimizing\n> >>>> os-collect-config as well (our in-instance Heat-aware agent). That is\n> >>>> a way for us to wait for notification of changes to Metadata without\n> >>>> polling.\n> >>> Interesting... If I understand correctly that\'s kinda replacement of \n> >>> cfn-hup... Do you have a blueprint pointer or something more \n> >>> specific? While I see the benefits of it, in-instance notifications \n> >>> is not really what we are looking for. We are looking for a \n> >>> notification service that exposes an API whereby listeners can \n> >>> register for Heat notifications. AWS Alarming / CloudFormation has \n> >>> that. Why not Ceilometer / Heat? That would be extremely valuable for \n> >>> those who build PaaS-like solutions above Heat. To say it bluntly, \n> >>> I\'d like to suggest we explore ways to integrate Heat with Marconi.\n> >> Yeah, I am trying to do a PoC of this now. I\'ll let you know how\n> >> it goes.\n> >>\n> >> I am trying to implement the following:\n> >>\n> >> heat_template_version: 2013-05-23\n> >> parameters:\n> >>    key_name:\n> >>      type: String\n> >>    flavor:\n> >>      type: String\n> >>      default: m1.small\n> >>    image:\n> >>      type: String\n> >>      default: fedora-19-i386-heat-cfntools\n> >> resources:\n> >>    config_server:\n> >>      type: OS::Marconi::QueueServer\n> >>      properties:\n> >>        image: {get_param: image}\n> >>        flavor: {get_param: flavor}\n> >>        key_name: {get_param: key_name}\n> >>\n> >>    configA:\n> >>      type: OS::Heat::OrderedConfig\n> >>      properties:\n> >>        marconi_server: {get_attr: [config_server, url]}\n> >>        hosted_on: {get_resource: serv1}\n> >>        script: |\n> >>          #!/bin/bash\n> >>          logger \"1. hello from marconi\"\n> >>\n> >>    configB:\n> >>      type: OS::Heat::OrderedConfig\n> >>      properties:\n> >>        marconi_server: {get_attr: [config_server, url]}\n> >>        hosted_on: {get_resource: serv1}\n> >>        depends_on: {get_resource: configA}\n> >>        script: |\n> >>          #!/bin/bash\n> >>          logger \"2. hello from marconi\"\n> >>\n> >>    serv1:\n> >>      type: OS::Nova::Server\n> >>      properties:\n> >>        image: {get_param: image}\n> >>        flavor: {get_param: flavor}\n> >>        key_name: {get_param: key_name}\n> >>        user_data: |\n> >>          #!/bin/sh\n> >>          # poll <marconi url>/v1/queues/{hostname}/messages\n> >>          # apply config\n> >>          # post a response message with any outputs\n> >>          # delete request message\n> >>\n> > If I may diverge this a bit, I\'d like to consider the impact of\n> > hosted_on on reusability in templates. hosted_on feels like an\n> > anti-pattern, and I\'ve never seen anything quite like it. It feels wrong\n> > for a well contained component to then reach out and push itself onto\n> > something else which has no mention of it.\n> >\n> > I\'ll rewrite your template as I envision it working:\n> >\n> > resources:\n> >    config_server:\n> >      type: OS::Marconi::QueueServer\n> >      properties:\n> >        image: {get_param: image}\n> >        flavor: {get_param: flavor}\n> >        key_name: {get_param: key_name}\n> >\n> >    configA:\n> >      type: OS::Heat::OrderedConfig\n> >      properties:\n> >        marconi_server: {get_attr: [config_server, url]}\n> >        script: |\n> >          #!/bin/bash\n> >          logger \"1. hello from marconi\"\n> >\n> >    configB:\n> >      type: OS::Heat::OrderedConfig\n> >      properties:\n> >        marconi_server: {get_attr: [config_server, url]}\n> >        depends_on: {get_resource: configA}\n> >        script: |\n> >          #!/bin/bash\n> >          logger \"2. hello from marconi\"\n> >\n> >    serv1:\n> >      type: OS::Nova::Server\n> >      properties:\n> >        image: {get_param: image}\n> >        flavor: {get_param: flavor}\n> >        key_name: {get_param: key_name}\n> >        components:\n> >          - configA\n> >          - configB\n> >        user_data: |\n> >          #!/bin/sh\n> >          # poll <marconi url>/v1/queues/{hostname}/messages\n> >          # apply config\n> >          # post a response message with any outputs\n> >          # delete request message\n> >\n> > This only becomes obvious why it is important when you want to do this:\n> >\n> >     configC:\n> >       type: OS::Heat::OrderedConfig\n> >       properties:\n> >         script: |\n> >           #!/bin/bash\n> >           logger \"?. I can race with A, no dependency needed\"\n> >\n> >     serv2:\n> >       type: OS::Nova::Server\n> >       properties:\n> >       ...\n> >       components:\n> >         - configA\n> >         - configC\n> >\n> > This is proper composition, where the caller defines the components, not\n> > the callee. Now you can re-use configA with a different component in the\n> > same template. As we get smarter we can have these configs separate from\n> > the template and reusable across templates.\n> >\n> > Anyway, I\'d like to see us stop talking about hosted_on, and if it has\n> > been implemented, that it be deprecated and eventually removed, as it is\n> > just plain confusing.\n> >\n> My components proposals had no hosted_on, but I\'ve been thinking about\n> the implications of implementing software configuration as resources,\n> and one of the natural consequences might be that hosted_on is the best\n> way of establishing the relationship with compute and its\n> configurations. Let me elaborate.\n> \n> Lets say that Heat has resource types for software configuration, with\n> the following behaviours:\n> * like other resources, a config resource goes into CREATE IN_PROGRESS\n> as soon as its dependencies are satisfied (these dependencies may be\n> values signalled from other config resources)\n> * a config resource goes to state CREATE COMPLETE when it receives a\n> signal that configuration on the compute resource is complete (by some\n> mechanism; wait condition, marconi message, whatevs)\n> * the relationship between config resources and compute resources are\n> achieved with existing intrinsic functions (get_resource, get_attr)\n> \n> This lifecycle behaviour means that a configuration resource can only\n> run on a single compute resource, and that relationship needs to be\n> established somehow. Config resources will have a quirk in that they\n> need to provide 2 sources of configuration data at different times:\n> 1) cloud-init config-data (or other boot-only mechanism), which must be\n> available when the compute resource goes into CREATE IN_PROGRESS\n> 2) the actual configuration data (oac metadata, puppet manifest, chef\n> recipe) which the compute resource needs to be able to fetch and execute\n> whenever it becomes available.\n> \n> The data in 1) implies that the compute needs to depend on the config,\n> but then all concurrency is lost (this won\'t matter for a\n> cloud-init-only config resource).  Either way, the data for 1) will need\n> to be available when the config resource is still in state INIT\n> COMPLETE, which may impose limitations on how that is defined (ie\n> get_resource, get_attr not allowed).\n> \n> So, 2 concrete examples for handling config/compute dependencies:\n> \n> hosted_on\n> ---------\n> resources:\n>   configA\n>     type: Heat::ScriptConfig\n>     properties:\n>        hosted_on:\n>          get_resource: the_server\n>        script: |\n>          #!/bin/bash\n>          logger \"1. hello config A\"\n>   configB\n>     type: Heat::ScriptConfig\n>     properties:\n>        hosted_on:\n>          get_resource: the_server\n>        script: |\n>          #!/bin/bash\n>          logger \"1. hello config B\"\n>   the_server:\n>     type: OS::Nova::Server\n> \n> Here, configA and configB go into CREATE IN_PROGRESS as soon as\n> the_server is CREATE COMPLETE. configA and configB go into CREATE\n> COMPLETE when heat-engine receives a signal that they are complete. This\n> signal may include values that other resources depend on to start their\n> creation.\n> \n\nMy biggest objection to hosted_on is that if I want to reuse configA.. I\ncan\'t without an additional level of abstraction. This feels awkward,\nand will be an awkward thing for users. In addition, it is very unclear\nwhat what will actually be on \"the_server\" when looking at \"the_server\".\n\nNobody has answered my question where else this sort of pattern is used.\n\n> OS::Nova::Server config_resources\n> ---------------------------------\n> resources:\n>   configA\n>     type: Heat::ScriptConfig\n>     properties:\n>        script: |\n>          #!/bin/bash\n>          logger \"1. hello config A\"\n>   configB\n>     type: Heat::ScriptConfig\n>     properties:\n>        script: |\n>          #!/bin/bash\n>          logger \"1. hello config B\"\n>   the_server:\n>     type: OS::Nova::Server\n>     properties:\n>       config_resources:\n>         - {get_resource: configA}\n>         - {get_resource: configB}\n> \n> Here there would need to be some bypassing of dependency calculation to\n> allow configA and configB to be created after the_server, maybe by:\n> * special treatment of config_resources to prevent dependencies being\n> created\n> * a get_resource variant which doesn\'t create a hard dependency\n> (get_resource_deferred?)\n> \n\nIMO no, these are not best expressed as resources in the same way that\npython classes are not expressed as objects.\n\nThe template above reads more like code. If used as a component, configA\nremains reusable throughout the rest of the template as it grows and\nchanges, and it is very obvious what is expected on \"the_server\". Each\nserver using configA gets its very own completion waitcondition for that\ninstantiation of the component.\n\nThis is why I liked the components concept, rather than have them as\nresources. It seems clear to me that components are parse-time objects,\nso if I refer to the same component 4 times, I really want 4 copies of\nit. Resources, on the other hand, are real things that are instantiated.\n\n> Neither the hosted_on nor the config_resources behaviours are ideal, but\n> I\'m leaning towards hosted_on at the moment since it doesn\'t require any\n> new soft-dependency mechanism.\n> \n\nIMO hosted_on is a new dependency mechanism, so avoiding the more clear\nparadigm for the reason of not introducing dependency mechanism seems a\nbit backwards too.\n\n> As for composability, what *actually* needs to be composable is the\n> contents of the script (manifest, recipe) property. Everything else in a\n> config resource is just stack-specific wiring.  There are a couple of\n> ways this composability could be achieved:\n> 1) resource provider in the user environment which specifies the script\n> property\n> 2) __include__ or some equivalent client-side inclusion mechanism\n> \n\nAt first it seems like all of it is just per-stack wiring, but the point\nis that even just inside a stack, you will want to reuse whole components,\nnot just the script/cloud-config/etc.\n\nI\'ve done a client side __include__ method for TripleO. It works fine\nactually. But since we\'re developing a language, we need to think\nlonger and harder than \"works for me\", otherwise we will make the PHP\nof orchestration languages.\n\nI\'d like to see components as a first class facility in HOT so that users\ncan compose templates in a logical straight forward manner. The proposals\nthat you have laid out provide workable but less discoverable mechanisms.\n\n\n','<526EE876.8030001@redhat.com>',NULL),('<1383020676.949910143@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 00:24:36',-14400,'2013-10-29 04:24:36',NULL,'[openstack-dev] [Glance] Design Summit etherpads','Here is a list of Glance etherpads for the design summit sessions - https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Glance .\n\nFeel free to add in notes.\n\nThanks,\nIccha\n\n\n\n',NULL,NULL),('<1383029056.32073.1.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 14:44:16',28800,'2013-10-29 06:44:16',NULL,'[openstack-dev] [heat] Proposal for new heat-core member','+1 !\n\nOn Fri, 2013-10-25 at 12:12 -0700, Steven Dake wrote:\n> Hi,\n> \n> I would like to propose Randall Burt for Heat Core.  He has shown\n> interest in Heat by participating in IRC and providing high quality\n> reviews.  The most important aspect in my mind of joining Heat Core is\n> output and quality of reviews.  Randall has been involved in Heat\n> reviews for atleast 6 months.  He has had 172 reviews over the last 6\n> months staying \"in the pack\" [1] of core heat reviewers.  His 90 day\n> stats are also encouraging, with 97 reviews (compared to the top\n> reviewer Steve Hardy with 444 reviews).  Finally his 30 day stats also\n> look good, beating out 3 core reviewers [2] on output with good\n> quality reviews.\n> \n> Please have a vote +1/-1 and take into consideration:\n> https://wiki.openstack.org/wiki/Heat/CoreTeam\n> \n> Regards,\n> -steve\n> \n> [1] http://russellbryant.net/openstack-stats/heat-reviewers-180.txt\n> [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<526AC2B6.7060303@redhat.com>',NULL),('<1383063118.263925025@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 12:11:58',-14400,'2013-10-29 16:11:58',NULL,'[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs\n	in Nova','\n\"John Garbutt\" <john at johngarbutt.com> said:\n\n> Going back to Joe\'s comment:\n>> Can both of these cases be covered by configuring the keystone catalog?\n> +1\n> \n> If both v1 and v2 are present, pick v2, otherwise just pick what is in\n> the catalogue. That seems cool. Not quite sure how the multiple glance\n> endpoints works in the keystone catalog, but should work I assume.\n> \n> We hard code nova right now, and so we probably want to keep that route too?\n\nNova doesn\'t use the catalog from Keystone when talking to Glance. There is a config value \"glance_api_servers\" which defines a list of Glance servers that gets randomized and cycled through. I assume that\'s what you\'re referring to with \"we hard code nova.\" But currently there\'s nowhere in this path (internal nova to glance) where the keystone catalog is available.\n\nI think some of the confusion may be that Glanceclient at the programmatic client level doesn\'t talk to keystone. That happens happens higher in the CLI level which doesn\'t come into play here.\n\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n>> On 10/17/2013 03:12 PM, Eddie Sheffield wrote:\n>>> Might I propose a compromise?\n>>>\n>>> 1) For the VERY short term, keep the config value and get the change otherwise\n>>> reviewed and hopefully accepted.\n>>>\n>>> 2) Immediately file two blueprints:\n>>>    - python-glanceclient - expose a way to discover available versions\n>>>    - nova - depends on the glanceclient bp and allowing autodiscovery of glance\n>>> version\n>>>             and making the config value optional (tho not deprecated / removed)\n>>\n>> Supporting both seems reasonable.  At least then *most* people don\'t\n>> need to worry about it and it \"just works\", but the override is there if\n>> necessary, since multiple people seem to be expressing a desire to have\n>> it available.\n> \n> +1\n> \n>> Can we just do this all at once?  Adding this to glanceclient doesn\'t\n>> seem like a huge task.\n> \n> I worry about us never getting the full solution, but it seems to have\n> got complicated.\n\nThe glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It\'s getting Nova to use this info that\'s a bit sticky.\n\n> On 28 October 2013 15:13, Eddie Sheffield <eddie.sheffield at rackspace.com> wrote:\n>> So...I\'ve been working on this some more and hit a bit of a snag. The\n>> Glanceclient change was easy, but I see now that doing this in nova will require\n>> a pretty huge change in the way things work. Currently, the API version is\n>> grabbed from the config value, the appropriate driver is instantiated, and calls\n>> go through that. The problem comes in that the actually glance server isn\'t\n>> communicated with until very late in the process. Nothing \"sees\" the servers at\n>> the level where the driver is determined. Also there isn\'t a single glance server\n>> but a list of them, and in the even of certain communication failures the list is\n>> cycled through until success or a number of retries has passed.\n>>\n>> So to change this to auto configuring will require turning this upside down,\n>> cycling through the servers at a higher level, choosing the appropriate driver\n>> for that server, and handling retries at that same level.\n>>\n>> Doable, but a much larger task than I first was thinking.\n>>\n>> Also, I don\'t really want the added overhead of getting the api versions before\n>> every call, so I\'m thinking that going through the list of servers at startup and\n>> discovering the versions then and caching that somehow would be helpful as well.\n>>\n>> Thoughts?\n> \n> I do worry about that overhead. But with Joe\'s comment, does it not\n> just boil down to caching the keystone catalog in the context?\n> \n> I am not a fan of all the specific talk to glance code we have in\n> nova, moving more of that into glanceclient can only be a good thing.\n> For the XenServer itegration, for efficiency reasons, we need glance\n> to talk from dom0, so it has dom0 making the final HTTP call. So we\n> would need a way of extracting that info from the glance client. But\n> that seems better than having that code in nova.\n\nI know in Glance we\'ve largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well.\n\nEddie\n\n\n\n','<CABib2_oVRuvLQh2AY5Fq3SoQRZe0zNVhgH5SZh6OwFf2FOxBWg@mail.gmail.com>',NULL),('<1383066573-sup-9651@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 10:24:05',-25200,'2013-10-29 17:24:05',NULL,'[openstack-dev] [Trove] Templates in Trove','Excerpts from Robert Myers\'s message of 2013-10-29 07:54:59 -0700:\n> I\'m pulling this conversation out of the gerrit review as I think it needs\n> more discussion.\n> \n> https://review.openstack.org/#/c/53499/\n> \n\nAfter reading the comments in that review, it seems to me that you\ndon\'t need a client side template for your Heat template.\n\nThe only argument for templating is \"If I want some things to be\ncustom I can\'t have them custom.\"\n\nYou may not realize this, but Heat templates already have basic string\nreplacement facilities and mappings, which is _all_ you need here.\n\nUse parameters. Pass _EVERYTHING_ into the stacks you\'re creating as\nparameters. Then let admins customize using Heat, not _another_\nlanguage.\n\nFor instance, somebody brought up wanting to have UserData be\ncustomizable. It is like this now:\n\nUserData:\n  Fn::Base64:\n    Fn::Join:\n    - \'\'\n    - [\"#!/bin/bash -v\\n\",\n        \"/opt/aws/bin/cfn-init\\n\",\n        \"sudo service trove-guest start\\n\"]\n\nSince you\'re using yaml, you don\'t have to se Fn::Join like in json,\nso simplify to this first:\n\nUserData:\n  Fn::Base64: |\n    #!/bin/bash -v\n    /opt/aws/bin/cfn-init\n    sudo service trove-guest start\n\nNow, the suggestion was that users might want to do a different prep\nper service_type. First, we need to make service_type a parameter\n\n\nParameters:\n  service_type:\n    Type: String\n    Default: mysql\n\nNow we need to shove it in where needed:\n\nMetadata:\n  AWS::CloudFormation::Init:\n    config:\n      files:\n        /etc/guest_info:\n          content:\n            Fn::Join:\n            - \'\'\n            - [\"[DEFAULT]\\nguest_id=\", {Ref: InstanceId},\n              \"\\nservice_type=\", {Ref: service_type}, \"]\"\n          mode: \'000644\'\n          owner: root\n          group: root\n\nNow, if a user wants to have a different script:\n\nMappings:\n  ServiceToScript:\n    mysql:\n      script: |\n        #!/bin/bash -v\n        /opt/aws/bin/cfn-init\n        sudo service trove-guest start\n    galera:\n      script: |\n        #!/bin/bash\n        /opt/aws/bin/cfn-init\n        galera-super-thingy\n        sudo service trove-guest start\n\n\nAnd then they replace the userdata as such:\n\nUserData:\n  Fn::FindInMap:\n    - ServiceToScript\n    - {Ref: service_type}\n    - script\n\nPlease can we at least _try_ not to reinvent things!\n\n\n','<CAPB8wWGvr36G22NHSX33XzOJfgm8GKWj5UFDxm53_GgEA9YgNA@mail.gmail.com>',NULL),('<1383149064.402426571@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 12:04:24',-14400,'2013-10-30 16:04:24',NULL,'[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs\n	in Nova','\n\n\"Mark Washenberger\" <mark.washenberger at markwash.net> said:\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> > I am not a fan of all the specific talk to glance code we have in\n>> > nova, moving more of that into glanceclient can only be a good thing.\n>> > For the XenServer itegration, for efficiency reasons, we need glance\n>> > to talk from dom0, so it has dom0 making the final HTTP call. So we\n>> > would need a way of extracting that info from the glance client. But\n>> > that seems better than having that code in nova.\n>>\n>> I know in Glance we\'ve largely taken the view that the client should be as\n>> thin and lightweight as possible so users of the client can make use of it\n>> however they best see fit. There was an earlier patch that would have moved\n>> the whole image service layer into glanceclient that was rejected. So I\n>> think there is a division in philosophies here as well.\n> \n> \n> \n> Indeed, I think I was being a bit of a stinker on this issue. Mea culpa.\n> \n> I\'ve had some time to think and I realized that there is a bit of\n> complexity here that needs to be untangled. Historically, the glance client\n> (and I think *most* openstack clients) have had versioned directories that\n> attempt to be as faithful a representation of the given version of an API\n> as possible. That was a history I was trying to maintain for continuity\'s\n> sake in the past.\n> \n> However, with some more thought, this historical objective seems literally\n> insane to me. In fact, it makes it basically impossible to publish a useful\n> client library because such a library has no control to smooth over\n> backwards incompatibility from one major version to the next.\n> \n> At this point I\'m a lot more interested in Ghe\'s patch (\n> https://review.openstack.org/#/c/33327/)\n> \n> I\'m a bit concerned that we might need to make the image client interface\n> even more stripped down in order to focus support on the intersection of v1\n> and v2 of the image api. In particular, I\'m not sure how well the old nova\n> image service api will deal with invalid property values (v2 has property\n> schemas). And there\'s no support AFAICT for image sharing, and image\n> sharing should not be used in v1 for security reasons.\n> \n> On the other hand, maybe we don\'t really want to move forward based on how\n> nova viewed the image repository in the past. There might be a better image\n> client api waiting to be discovered by some intrepid openstacker. This\n> could make sense as well if there is some traction for eventually\n> deprecating the v1 api. But in any case, it does sound like we need an\n> image client with its own proper api that can be ported from version to\n> version.\n> \n> </ramble>\n\nHmmm, pretty big turnaround but one I mostly agree with. I would like to see more discussion on what this unified interface would look like rather than just pulling in what\'s in Nova (tho we might converge on that anyway.) I do worry about what to do about unique functionality in the various API versions. It might be that the most common functionality is exposed in the service interface, and if you need some of the more API specific functionality you can use the lower-level client interfaces. Alternatively the interface might contain everything possible; and where it can, smooth over the differences and where it can\'t, raise NotImplemented exceptions.\n\nMark, can we get some discussion of this in our Glance meeting tomorrow (10/31)?\n\nEddie\n\n\n\n\n','<CAJyP2C-3BY2GjzZu5gyQGYMcxB+ZROr9d5wjTeonj8jnprO-Aw@mail.gmail.com>',NULL),('<1383152543-sup-6039@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 10:42:53',-25200,'2013-10-30 17:42:53',NULL,'[openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey','So, recently we\'ve had quite a long thread in gerrit regarding locking\nin Heat:\n\nhttps://review.openstack.org/#/c/49440/\n\nIn the patch, there are two distributed lock drivers. One uses SQL,\nand suffers from all the problems you might imagine a SQL based locking\nsystem would. It is extremely hard to detect dead lock holders, so we\nend up with really long timeouts. The other is ZooKeeper.\n\nI\'m on record as saying we\'re not using ZooKeeper. It is a little\nembarrassing to have taken such a position without really thinking things\nthrough. The main reason I feel this way though, is not because ZooKeeper\nwouldn\'t work for locking, but because I think locking is a mistake.\n\nThe current multi-engine paradigm has a race condition. If you have a\nstack action going on, the state is held in the engine itself, and not\nin the database, so if another engine starts working on another action,\nthey will conflict.\n\nThe locking paradigm is meant to prevent this. But I think this is a\nhuge mistake.\n\nThe engine should store _all_ of its state in a distributed data store\nof some kind. Any engine should be aware of what is already happening\nwith the stack from this state and act accordingly. That includes the\nengine currently working on actions. When viewed through this lense,\nto me, locking is a poor excuse for serializing the state of the engine\nscheduler.\n\nIt feels like TaskFlow is the answer, with an eye for making sure\nTaskFlow can be made to work with distributed state. I am not well\nversed on TaskFlow\'s details though, so I may be wrong. It worries me\nthat TaskFlow has existed a while and doesn\'t seem to be solving real\nproblems, but maybe I\'m wrong and it is actually in use already.\n\nAnyway, as a band-aid, we may _have_ to do locking. For that, ZooKeeper\nhas some real advantages over using the database. But there is hesitance\nbecause it is not widely supported in OpenStack. What say you, OpenStack\ncommunity? Should we keep ZooKeeper out of our.. zoo?\n\n\n',NULL,NULL),('<1383161546-sup-6036@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 12:37:37',-25200,'2013-10-30 19:37:37',NULL,'[openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey','Excerpts from Joshua Harlow\'s message of 2013-10-30 11:57:30 -0700:\n> As for the mutex and locking and all that problem.\n> \n> I would expect locking to be a necessity at some point for openstack.\n> \n> Even if the state transitions are the locks themselves (that?s still a\n> lock by another name imho) and u need a reliable way to store and change\n> those state transitions (aka what the last one was, what the next one is).\n> A database can be likely ok here but is not ideal as complexity increases.\n> The other part that I think zookeepr addresses is similar to how it is\n> used in nova, where its used as a \'liveness\' system, where instead of\n> consistently updating a database with heartbeats zookeeper itself\n> maintains that information without requiring constant updates to a DB\n> (which doesn\'t scale).\n\nI\'m not so concerned with locks under the covers, I am concerned with\nlocking as a paradigm. It is too low level for what Heat is aiming at.\nYes of course serialization can and often does rely on locking. My point\nis really that we should not care how serialization happens, we should\njust express the work-flow, and let the underlying mechanisms distribute\nand manage it as it is completed. My sincerest hope is that we can make\nTaskFlow do this.\n\n\n','<CE96A297.4B4E2%harlowja@yahoo-inc.com>',NULL),('<1383168022-sup-1147@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 14:20:38',-25200,'2013-10-30 21:20:38',NULL,'[openstack-dev] [Solum] Solum transitioned to openstack-dev','Excerpts from Adrian Otto\'s message of 2013-10-30 12:08:28 -0700:\n> Hi,\n> \n> The Solum team has agreed[1] to use openstack-dev, and has closed its project-specific mailing list. We look forward to discussing ongoing design and development efforts here. We are also transitioning to an openstack meeting channel for subsequent public meetings.\n\nWelcome! :)\n\n\n','<398A7889-8C7F-4003-A4CA-8B2995FB57F5@rackspace.com>',NULL),('<1383175077.2767.0.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 09:17:57',36000,'2013-10-30 23:17:57',NULL,'[openstack-dev] [keystone] Support for external	authentication\n (i.e. REMOTE_USER) in Havana','On Wed, 2013-10-30 at 10:27 +0100, ?lvaro L?pez Garc?a wrote:\n> Hi Tim.\n> \n> On Tue 29 Oct 2013 (16:18), Tim Bell wrote:\n> > \n> > We also need some standardisation on the command line options for the client portion (such as --os-auth-method, --os-x509-cert etc.) . Unfortunately, this is not yet in Oslo so there would be multiple packages to be enhanced.\n> \n> I totally agree. We need a common pluggable authentication mechanism\n> for the clients (since Keystone supports it, the clients should support\n> it). I improved the simple system that was in novaclient [1], but it should\n> be moved to keystone client. There was some movement to port this to [2]\n> but the change was abandoned in favour of a more complex solutions: one\n> that never came in (oslo [3]) and another from Jamie Lennox in [4] that\n> is still a WIP.\n> \n> [1] https://review.openstack.org/#/c/23820/\n> [2] https://review.openstack.org/#/c/36427/\n> [3] https://review.openstack.org/#/c/28043/\n> [4] https://blueprints.launchpad.net/python-keystoneclient/+spec/auth-plugins\n> \n> Regards, \n\nCompletely agree, we\'re working on this but it\'s currently postponed\nuntil we\'ve had a chance to discuss it at the summit. \n\n\n\n\n','<20131030092719.GA29821@yuso.ifca.es>',NULL),('<1383176997.2767.7.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-31 09:49:57',36000,'2013-10-30 23:49:57',NULL,'[Openstack] [2 swift-proxy/keystone install] Requests only\n works when swift talk to its own keystone','Keystone signs the information in auth token with a certificate that in\nmost setups was generated for that instance of keystone. Swift will use\nauth_token middleware to fetch the certificates of keystone so that it\ncan verify that the tokens are correct. \n\nMy guess is that the two keystone instances are using different\ncertificates and you are trying to validate a token with the other\nkeystone instance (other certificates) and it won\'t work.\n\nIf you are using the same keystone instance then it is possible that the\nauth_token middleware in swift has cached the certificates for the other\nkeystone instance, so even though you have updated the values in swift\nit is using the old certificates.\n\nTry deleting the certificates found in the folder specified by\nsigning_dir in the swift setup and make sure you are issuing the tokens\nfrom the keystone instance you are validating them against.\n\n\nJamie\n\nOn Wed, 2013-10-30 at 18:47 +0100, thorfinn at poivron.org wrote:\n> Hi all.\n> \n> * Hypervisor 1 : 192.168.1.120\n> 	- Keystone 1	: 192.168.3.141\n> 	- Swift-proxy 1	: 192.168.3.111\n> * Hypervisor 2 : 192.168.1.122\n> 	- Keystone 2	: 192.168.3.241\n> 	- Swift-proxy 2	: 192.168.3.211\n> \n> Keystone servers have the same mysql server, database and \n> configuration, so it\'s not a data issue.\n> Every server can ping and talk to all the other ones.\n> \n> When I talk to Swift-proxy 1, connected to Keystone 1 it works.\n> Same to Swift-proxy 2, connected to Keystone 2.\n> \n> If I connect Swift-proxy 1 to Keystone 2, it doesn\'t work anymore.\n> Same for Swift-proxy 2 to Keystone 1.\n> \n> All the servers are using Ubuntu 12.04.3/Havana and are up-to-date.\n> \n> When it works, I have this (keystone 2 connected to swift-proxy 2) :\n> # swift -V 2 -v -A http://192.168.3.241:5000/v2.0 -U service:swift -K \n> swift stat\n> StorageURL: \n> http://192.168.3.211:8080/v1/AUTH_5becb4a93e7f498bbe83534f4481dc0d\n> Auth Token: \n> MIIGTQYJKoZIhvcNAQcCoIIGPjCCBjoCAQExCTAHBgUrDgMCGjCCBKMGCSqGSIb3DQEHAaCCBJQEggSQeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0xMC0zMFQxNzozMzowMC4zNTI4MzAiLCAiZXhwaXJlcyI6ICIyMDEzLTEwLTMxVDE3OjMzOjAwWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogIlNlcnZpY2UgVGVuYW50IiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAibmFtZSI6ICJzZXJ2aWNlIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjIxMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjIxMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAiaWQiOiAiMzdhZWQxODc3NmQ5NDUzZGI3MmE3ODc1ZWM3ZTY5ZGEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjExOjgwODAvdjEvQVVUSF81YmVjYjRhOTNlN2Y0OThiYmU4MzUzNGY0NDgxZGMwZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImF!\n kbW\n>  luVVJMIj\n> ogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjM1MzU3L3YyLjAiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjI0MTo1MDAwL3YyLjAiLCAiaWQiOiAiMGJmNzIxNjM1MmFjNDE4ZmEzODVkNWZmM2ZmODlmMzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAic3dpZnQiLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjYzZWVjNjMyYWI3NTRiYzY5NTgzY2M0YTI5Yjc0MDVmIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAic3dpZnQifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiZjUwNjczYjliNDUwNDQyZGI1OGRkYTExYjQ4M2ZkMmUiXX19fTGCAYEwggF9AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbQIBATAHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQASAXjP5gHiUWfl0e8gfh2O4n7IEoerLDmmTR07tQw1ibqyxyyhdNAVuThrceu0z3-VrHyeiuYcWAlJZzI6okeo02CDc7SRK4CjHLG9m8q80UrLOfT1-PbKes16ULKbGJpsBYykVXTV8ts+wQVAYcS73f2bwp6+Ki0Cygtfqkmvq!\n Net\n>  7hDtSsvT\n> yAGKiLo0TbOYOpF96NelPwuzGAm2y-bcOhCCdJKo8iFEotTXK0SQzUQ78r3Mh1fsd6asoHRZxKKc0oXWm3KgJy1X-isnqopCMutDPPQCAXABOFb-OSovLMmmOS8ZZbII7RTd1e1z1sFYv3d67b0oc2A4e8DWAaVj\n>     Account: AUTH_5becb4a93e7f498bbe83534f4481dc0d\n> Containers: 4\n>     Objects: 11\n>       Bytes: 158989835\n> Accept-Ranges: bytes\n> X-Timestamp: 1382628587.87452\n> Content-Type: text/plain; charset=utf-8\n> \n> Oct 30 18:32:59 dev-api-002 proxy-server Verify error: Command \n> \'openssl\' returned non-zero exit status 4\n> Oct 30 18:32:59 dev-api-002 proxy-server Authorization failed for token \n> MIIGTQYJKoZIhvcNAQcCoIIGPjCCBjoCAQExCTAHBgUrDgMCGjCCBKMGCSqGSIb3DQEHAaCCBJQEggSQeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMj\n> AxMy0xMC0zMFQxNzozMjo1OC44NTY3MzEiLCAiZXhwaXJlcyI6ICIyMDEzLTEwLTMxVDE3OjMyOjU4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogIlNlcnZpY2UgVGVuYW50IiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNWJl\n> Y2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAibmFtZSI6ICJzZXJ2aWNlIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjIxMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlOD\n> M1MzRmNDQ4MWRjMGQiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjIxMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAiaWQiOiAiMzdhZWQxODc3NmQ5NDUzZGI3MmE3ODc1\n> ZWM3ZTY5ZGEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjExOjgwODAvdjEvQVVUSF81YmVjYjRhOTNlN2Y0OThiYmU4MzUzNGY0NDgxZGMwZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2\n> lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjM1MzU3L3YyLjAiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjI0MTo1MDAwL3YyLjAiLCAiaWQiOiAiMGJmNzIx\n> NjM1MmFjNDE4ZmEzODVkNWZmM2ZmODlmMzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidX\n> Nlcm5hbWUiOiAic3dpZnQiLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjYzZWVjNjMyYWI3NTRiYzY5NTgzY2M0YTI5Yjc0MDVmIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAic3dpZnQifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAs\n> ICJyb2xlcyI6IFsiZjUwNjczYjliNDUwNDQyZGI1OGRkYTExYjQ4M2ZkMmUiXX19fTGCAYEwggF9AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbQIBAT\n> AHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQCzitgoJ4ltBsCNN8xnLy3GlopgV5OlVRBa4fbHXcNT6expAdTYtx4I8q1cIF279NPVJO9T8hsedMSHwOxZvxJKskwFuuwUWT+cTBzkxlrY11Njmg9dGwQiJ1Pbb8oA3YZcgWjz6aY+1RajN-Lq9ugCidsY5tzFrHTwPed1VOcu\n> Wq2MKcMIqmt2m5b\n> Oct 30 18:32:59 dev-api-002 proxy-server Invalid user token - deferring \n> reject downstream\n> \n> Why the error if it works ?\n> \n> When it doesn\'t work, I have this (keystone 2 connected to swift-proxy \n> 1) :\n> # swift -V 2 -v -A http://192.168.3.241:5000/v2.0 -U service:swift -K \n> swift stat\n> Account HEAD failed: \n> http://192.168.3.111:8080/v1/AUTH_5becb4a93e7f498bbe83534f4481dc0d 401 \n> Unauthorized\n> \n> Oct 30 18:34:53 dev-api-001 proxy-server Verify error: Command \n> \'openssl\' returned non-zero exit status 4\n> Oct 30 18:34:53 dev-api-001 proxy-server Authorization failed for token \n> MIIGTQYJKoZIhvcNAQcCoIIGPjCCBjoCAQExCTAHBgUrDgMCGjCCBKMGCSqGSIb3DQEHAaCCBJQEggSQeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMj\n> AxMy0xMC0zMFQxNzozNDo1My42NTY0NTMiLCAiZXhwaXJlcyI6ICIyMDEzLTEwLTMxVDE3OjM0OjUzWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogIlNlcnZpY2UgVGVuYW50IiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNWJl\n> Y2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAibmFtZSI6ICJzZXJ2aWNlIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjExMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlOD\n> M1MzRmNDQ4MWRjMGQiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjExMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAiaWQiOiAiMzdhZWQxODc3NmQ5NDUzZGI3MmE3ODc1\n> ZWM3ZTY5ZGEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMTExOjgwODAvdjEvQVVUSF81YmVjYjRhOTNlN2Y0OThiYmU4MzUzNGY0NDgxZGMwZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2\n> lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjM1MzU3L3YyLjAiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjI0MTo1MDAwL3YyLjAiLCAiaWQiOiAiMGJmNzIx\n> NjM1MmFjNDE4ZmEzODVkNWZmM2ZmODlmMzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidX\n> Nlcm5hbWUiOiAic3dpZnQiLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjYzZWVjNjMyYWI3NTRiYzY5NTgzY2M0YTI5Yjc0MDVmIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAic3dpZnQifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAs\n> ICJyb2xlcyI6IFsiZjUwNjczYjliNDUwNDQyZGI1OGRkYTExYjQ4M2ZkMmUiXX19fTGCAYEwggF9AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbQIBAT\n> AHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQAZRHKSulq-73euRy9HrYxMTU-HtRizyySVYkoo3CTCOgxFZz3CzelBIcp6HJySC6DVAW4Uz-xcTmtp1hju3vx3yAVstWtCczO-YZX4bUy4XFmfNje2ydJl5M2sSAUZ8160Vn3QnajesaRIvnu9w8WcpWsmaYjbx15ou2CzWnvH\n> j0V1lLTgA28dh90\n> Oct 30 18:34:53 dev-api-001 proxy-server Invalid user token - deferring \n> reject downstream\n> Oct 30 18:34:55 dev-api-001 proxy-server Verify error: Command \n> \'openssl\' returned non-zero exit status 4\n> Oct 30 18:34:55 dev-api-001 proxy-server Authorization failed for token \n> MIIGTQYJKoZIhvcNAQcCoIIGPjCCBjoCAQExCTAHBgUrDgMCGjCCBKMGCSqGSIb3DQEHAaCCBJQEggSQeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMj\n> AxMy0xMC0zMFQxNzozNDo1NS4xNTA5MjUiLCAiZXhwaXJlcyI6ICIyMDEzLTEwLTMxVDE3OjM0OjU1WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogIlNlcnZpY2UgVGVuYW50IiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiNWJl\n> Y2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAibmFtZSI6ICJzZXJ2aWNlIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjExMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlOD\n> M1MzRmNDQ4MWRjMGQiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjExMTo4MDgwL3YxL0FVVEhfNWJlY2I0YTkzZTdmNDk4YmJlODM1MzRmNDQ4MWRjMGQiLCAiaWQiOiAiMzdhZWQxODc3NmQ5NDUzZGI3MmE3ODc1\n> ZWM3ZTY5ZGEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMTExOjgwODAvdjEvQVVUSF81YmVjYjRhOTNlN2Y0OThiYmU4MzUzNGY0NDgxZGMwZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2\n> lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjM1MzU3L3YyLjAiLCAicmVnaW9uIjogInJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTkyLjE2OC4zLjI0MTo1MDAwL3YyLjAiLCAiaWQiOiAiMGJmNzIx\n> NjM1MmFjNDE4ZmEzODVkNWZmM2ZmODlmMzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xOTIuMTY4LjMuMjQxOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidX\n> Nlcm5hbWUiOiAic3dpZnQiLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjYzZWVjNjMyYWI3NTRiYzY5NTgzY2M0YTI5Yjc0MDVmIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAic3dpZnQifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAs\n> ICJyb2xlcyI6IFsiZjUwNjczYjliNDUwNDQyZGI1OGRkYTExYjQ4M2ZkMmUiXX19fTGCAYEwggF9AgEBMFwwVzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxGDAWBgNVBAMMD3d3dy5leGFtcGxlLmNvbQIBAT\n> AHBgUrDgMCGjANBgkqhkiG9w0BAQEFAASCAQCXUDhH+Q8xUS6upUb8TtF2Uk-h2m-w84CmeJxKc-n7qGuozrZe7KPcrKp002ojDIY+CmGulWtXQD-IJ6V4hcjaVbmoxMIIVmMulxt1G2dLLIrtQCIUwnNFsOaaBiEZTus8DlpjIHGrLfcBRtzjewQXUA5PuRXC-ebtgE7wphMv\n> ETodRWB5zKixqmL\n> Oct 30 18:34:55 dev-api-001 proxy-server Invalid user token - deferring \n> reject downstream\n> \n> I have the same kind of logs entry than the working example but twice.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n','<55b674af724ca927e364ed149235af35@poivron.org>',NULL),('<1383180939-sup-2077@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 18:04:09',-25200,'2013-10-31 01:04:09',NULL,'[openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey','Excerpts from Joshua Harlow\'s message of 2013-10-30 17:46:44 -0700:\n> This works as long as you have 1 DB and don\'t fail over to a secondary\n> slave DB.\n> \n> Now u can say we all must use percona (or similar) for this, but then\n\nDid you mean Galera which provides multiple synchronous masters?\n\n> that?s a change in deployment as well (and imho a bigger one). This is\n> where the concept of a quorum in zookeeper comes into play, the\n> transaction log that zookeeper maintains will be consistent among all\n> members in that quorum. This is a typical zookeeper deployment strategy\n> (select how many nodes u want for that quorum being an important question).\n>\n\nGalera uses more or less the exact same mechanism.\n\n> It also doesn\'t handle the case where u can automatically recover from the\n> current resource owner (nova-compute for example) dying.\n>\n\nI don\'t know what that means.\n\n> Your atomic \"check-if-owner-is-empty-and-store-instance-as-owner\" is now\n> user initiated instead of being automatic (zookeeper provides these kind\n> of notifications via its watch concept). So that makes it hard for say an\n> automated system (heat?) to react to these failures in any other way than\n> repeated polling (or repeated retries or periodic tasks) which means that\n> heat will not be able to react to failure in a \'live\' manner. So this to\n> me is the liveness question that zookeeper is designed to help out with,\n> of course u can simulate this in a DB and repeated polling (as long as u\n> don\'t try to do anything complicated with mysql, like replicas/slaves with\n> transaction logs that may not be caught up and that u might have to fail\n> over to if problems happen, since u are on your own if this happens).\n>\n\nRight, even if you have a Galera cluster you still have to poll it or\nuse wonky things like triggers hooked up to memcache/gearman/amqp UDF\'s\nto get around polling latency.\n\nI think your point is that a weird MySQL is just as disruptive to \"the\nnormal OpenStack deployment\" as a weird service like ZooKeeper.\n\n\n','<CE96F442.4B577%harlowja@yahoo-inc.com>',NULL),('<1383195778.462528780@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 00:02:58',-18000,'2013-10-31 05:02:58',NULL,'[openstack-dev] [Solum] Separation of concerns for 0.1 git\n	deploy blueprint','Hi Clayton,\n\nThank you for creating these diagrams. They are a great starting point for discussions\naround the git deploy blueprint.\n\nSome questions/comments:\n\nIn both the diagrams, what do the arrows indicate? \nData flow, control-flow, or some kind of ordering relationship?\nEspecially, the arrow from \'respond to client\' to \'HEAT\' box in the top diagram\nis a bit confusing. Correct me if I am wrong, but my guess is that the meaning\nof that arrow is, \'stack create\' will happen after responding to client has happened.\nAlthough, this may not be necessarily true (both those steps can happen in async manner).\n\nSecond, how do you envision tying together the two diagrams/high-level flows?\nSpecifically, once we have a built artifact (second diagram), how do we go about deploying it?\n\nWe could either have, build abstraction -> REST API -> deploy abstraction,\nor, build abstraction -> deploy abstraction. What are your thoughts on this?\n\nBest regards,\nDevdatta\n\n\n-----Original Message-----\nFrom: \"Adrian Otto\" <adrian.otto at rackspace.com>\nSent: Wednesday, October 30, 2013 8:01pm\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Solum] Separation of concerns for 0.1 git deploy blueprint\n\nClayton,\n\nThanks for adding the diagram illustrating the flow. I expect that \"respond to client\" may not be a synchronous flow, rather that if creation of a repo takes a while that the API may return a 202 Accepted, and the client can poll a status attribute to determine completion and learn the actual location of the repo created. So in that case \"respond to client\" also might mean \"update async status\". This will be particularly important in cases where an external SCM system is used (perhaps Github).\n\nI agree that this will be a helpful reference to guide our upcoming interactive design sessions. I have created the first call for participation, which will also be separately announced:\n\nhttps://wiki.openstack.org/wiki/Solum/BreakoutMeetings\n\nAdrian\n\nOn Oct 30, 2013, at 2:45 PM, Clayton Coleman <ccoleman at redhat.com> wrote:\n\n> In the IRC meeting yesterday [1] we discussed splitting the individual topics for the git deploy blueprint [2] into rough sub areas.  To help frame the abstractions we\'ve been discussing I roughed out a flow based on two user inputs, REST API create and a git push and then tried to draw boxes around the related bits.  The abstractions roughly correspond to the potential areas that can be the focus of break out discussions (and if they don\'t a good discussion of why is always helpful).\n> \n> Squiggly boxes are potential plugin points and/or strong responsibility boundaries.  Feedback desirable.\n> \n> [1] http://irclogs.solum.io/2013/solum.2013-10-29-16.01.txt\n> [2] https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/GitIntegration#Flow_Boundaries\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<A6A1CCBB-89D9-406D-8D0C-3ED3D27B6984@rackspace.com>',NULL),('<1383200089-sup-8301@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 23:16:27',-25200,'2013-10-31 06:16:27',NULL,'[openstack-dev] [TripleO] TripleO core reviewer update -\n	november','Excerpts from Robert Collins\'s message of 2013-10-30 02:06:38 -0700:\n> Hi, like most OpenStack projects we need to keep the core team up to\n> date: folk who are not regularly reviewing will lose context over\n> time, and new folk who have been reviewing regularly should be trusted\n> with -core responsibilities.\n> \n> In this months review:\n>  - James Slagle for -core\n\n+1\n\n>  - Arata Notsu to be removed from -core\n\n+1\n\n>  - Devananda van der veen to be removed from -core\n\n+1\n\n\n','<CAJ3HoZ0M8i200Ykj3aAmT9GSaSVuRnL+0t2o4xFhWPeTik-xyA@mail.gmail.com>',NULL),('<1383226232.9301.606.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 13:30:32',0,'2013-10-31 13:30:32',NULL,'[openstack-dev] When is it okay for submitters to say \'I don\'t\n want to add tests\' ?','On Thu, 2013-10-31 at 15:37 +1300, Robert Collins wrote:\n> This is a bit of a social norms thread....\n> \n> I\'ve been consistently asking for tests in reviews for a while now,\n> and I get the occasional push-back. I think this falls into a few\n> broad camps:\n> \n> A - there is no test suite at all, adding one in unreasonable\n> B - this thing cannot be tested in this context (e.g. functional tests\n> are defined in a different tree)\n> C - this particular thing is very hard to test\n> D - testing this won\'t offer benefit\n> E - other things like this in the project don\'t have tests\n> F - submitter doesn\'t know how to write tests\n> G - submitter doesn\'t have time to write tests\n\nNice breakdown.\n\n> Now, of these, I think it\'s fine not add tests in cases A, B, C in\n> combination with D, and D.\n> \n> I don\'t think E, F or G are sufficient reasons to merge something\n> without tests, when reviewers are asking for them. G in the special\n> case that the project really wants the patch landed - but then I\'d\n> expect reviewers to not ask for tests or to volunteer that they might\n> be optional.\n\nI totally agree with the sentiment but, especially when it\'s a newcomer\nto the project, I try to put myself in the shoes of the patch submitter\nand double-check whether what we\'re asking is reasonable.\n\nFor example, if someone shows up to Nova with their first OpenStack\ncontribution, it fixes something which is unquestionably a bug - think\ntypo like \"raise NotFund(\'foo\')\" - and testing this code patch requires\nmore than adding a simple new scenario to existing tests ...\n\nThat, for me, is an example of \"-1, we need a test! untested code is\nbroken!\" is really shooting the messenger, not valuing the newcomers\ncontribution and risks turning that person off the project forever.\nReviewers being overly aggressive about this where the project doesn\'t\nhave full test coverage to begin with really makes us seem unwelcoming.\n\nIn cases like that, I\'d be of a mind to go \"+2 Awesome! Thanks for\ncatching this! It would be great to have a unit test for this, but it\'s\nclear the current code is broken so I\'m fine with merging the fix\nwithout a test\". You could say it\'s now the reviewers responsibility to\nmerge a test, but if that requirement then turns off reviewers even\nreviewing such a patch, then that doesn\'t help either.\n\nSo, with all of this, let\'s make sure we don\'t forget to first\nappreciate the effort that went into submitting the patch that lacks\ntests.\n\nMark.\n\n\n\n','<CAJ3HoZ0AYFDXKscbjQ7Vds-qNmOebLWRFB8rsshLPsscuzE-5A@mail.gmail.com>',NULL),('<1383227179-sup-2624@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 06:56:16',-25200,'2013-10-31 13:56:16',NULL,'[openstack-dev] When is it okay for submitters to say \'I don\'t\n	want to add tests\' ?','Excerpts from Mark McLoughlin\'s message of 2013-10-31 06:30:32 -0700:\n> On Thu, 2013-10-31 at 15:37 +1300, Robert Collins wrote:\n> > This is a bit of a social norms thread....\n> > \n> > I\'ve been consistently asking for tests in reviews for a while now,\n> > and I get the occasional push-back. I think this falls into a few\n> > broad camps:\n> > \n> > A - there is no test suite at all, adding one in unreasonable\n> > B - this thing cannot be tested in this context (e.g. functional tests\n> > are defined in a different tree)\n> > C - this particular thing is very hard to test\n> > D - testing this won\'t offer benefit\n> > E - other things like this in the project don\'t have tests\n> > F - submitter doesn\'t know how to write tests\n> > G - submitter doesn\'t have time to write tests\n> \n> Nice breakdown.\n> \n> > Now, of these, I think it\'s fine not add tests in cases A, B, C in\n> > combination with D, and D.\n> > \n> > I don\'t think E, F or G are sufficient reasons to merge something\n> > without tests, when reviewers are asking for them. G in the special\n> > case that the project really wants the patch landed - but then I\'d\n> > expect reviewers to not ask for tests or to volunteer that they might\n> > be optional.\n> \n> I totally agree with the sentiment but, especially when it\'s a newcomer\n> to the project, I try to put myself in the shoes of the patch submitter\n> and double-check whether what we\'re asking is reasonable.\n> \n\nEven with a long time contributor, empathy is an important part of\nconstructing reviews. We could make more robotic things that review for\ntest coverage, but we haven\'t, because this is a gray area. The role of\na reviewer isn\'t just get patches merged and stop defects. It is also to\ngrow the other developers.\n\n> For example, if someone shows up to Nova with their first OpenStack\n> contribution, it fixes something which is unquestionably a bug - think\n> typo like \"raise NotFund(\'foo\')\" - and testing this code patch requires\n> more than adding a simple new scenario to existing tests ...\n>\n\nThis goes back to my recent suggestion to help the person not with a -1\nor a +2, but with an additional patch that fixes it.\n\n> That, for me, is an example of \"-1, we need a test! untested code is\n> broken!\" is really shooting the messenger, not valuing the newcomers\n> contribution and risks turning that person off the project forever.\n> Reviewers being overly aggressive about this where the project doesn\'t\n> have full test coverage to begin with really makes us seem unwelcoming.\n> \n> In cases like that, I\'d be of a mind to go \"+2 Awesome! Thanks for\n> catching this! It would be great to have a unit test for this, but it\'s\n> clear the current code is broken so I\'m fine with merging the fix\n> without a test\". You could say it\'s now the reviewers responsibility to\n> merge a test, but if that requirement then turns off reviewers even\n> reviewing such a patch, then that doesn\'t help either.\n> \n\nI understand entirely why you choose this, and I think that is fine. I,\nhowever, see this as a massive opportunity to teach. That code was only\nbroken because it was allowed it to be merged without tests. By letting\nthat situation continue, we only fix it today. The next major refactoring\nhas a high chance now of breaking that part of the code again.\n\nSo, rather than +2, I suggest -1 with compassion. Engage with the\nsubmitter. If you don\'t know them, take a look at how hard it would be\nto write a test for the behavior and give pointers to the exact test\nsuite that would need to be changed, or suggest a new test suite and\npoint at a good example to copy.\n\n> So, with all of this, let\'s make sure we don\'t forget to first\n> appreciate the effort that went into submitting the patch that lacks\n> tests.\n> \n\nI\'m not going to claim that I\'ve always practiced \"-1 with compassion\",\nso thanks for reminding us all that we\'re not just reviewing code, we\nare having a dialog with real live people.\n\n\n','<1383226232.9301.606.camel@sorcha>',NULL),('<1383231170.9301.620.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 14:52:50',0,'2013-10-31 14:52:50',NULL,'[OpenStack Foundation] OpenStack core and interoperability','On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:\n> There is a VERY specific and strong reason why this is not the approach,\n> and that\'s because it disincentivies people from working on OpenStack\n> itself. We already have the problem with Neutron where not enough\n> companies are working on the core of neutron because they\'re all only\n> working on their vendor plugins. If OpenStack all of a sudden became a\n> set of interfaces, then the goal of an Open cloud would, I\'m pretty\n> certain, become lost.\n\nRob talks about using having three tools - our culture, our velocity and\nour trademark. The first two could be as effective at having people\nchoose to use OpenStack itself rather than a compatible implementation\nof its interfaces.\n\nI could see us having two trademark programs \"OpenStack Cloud\" - where\nyou know that the provider is running a \"faithful implementation\" of\nOpenStack code - and \"OpenStack Compatible Cloud\" - where you just know\nthe provider is compatible with the interfaces.\n\nI\'d see having \"OpenStack Compatible Cloud\" as the first priority.\n\nIf we can figure out how to build a sane \"OpenStack Cloud\" program in\nshort order, then awesome. But it shouldn\'t hold back the first program.\n\nMark.\n\n\n\n','<52726C06.9010408@inaugust.com>',NULL),('<1383231481.9301.623.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 14:58:01',0,'2013-10-31 14:58:01',NULL,'[OpenStack Foundation] OpenStack core and interoperability','On Thu, 2013-10-31 at 14:52 +0000, Mark McLoughlin wrote:\n> On Thu, 2013-10-31 at 07:41 -0700, Monty Taylor wrote:\n> > There is a VERY specific and strong reason why this is not the approach,\n> > and that\'s because it disincentivies people from working on OpenStack\n> > itself. We already have the problem with Neutron where not enough\n> > companies are working on the core of neutron because they\'re all only\n> > working on their vendor plugins. If OpenStack all of a sudden became a\n> > set of interfaces, then the goal of an Open cloud would, I\'m pretty\n> > certain, become lost.\n> \n> Rob talks about using having three tools - our culture, our velocity and\n> our trademark. The first two could be as effective at having people\n> choose to use OpenStack itself rather than a compatible implementation\n> of its interfaces.\n> \n> I could see us having two trademark programs \"OpenStack Cloud\" - where\n> you know that the provider is running a \"faithful implementation\" of\n> OpenStack code - and \"OpenStack Compatible Cloud\" - where you just know\n> the provider is compatible with the interfaces.\n> \n> I\'d see having \"OpenStack Compatible Cloud\" as the first priority.\n> \n> If we can figure out how to build a sane \"OpenStack Cloud\" program in\n> short order, then awesome. But it shouldn\'t hold back the first program.\n\nOh, and to be clear - if it did happen this way, I\'d quite happily\ndeprecate the \"OpenStack Compatible Cloud\" program once we have the\n\"OpenStack Cloud\" program in place.\n\nOr maybe there\'s only one program and the \"use OpenStack code\"\nrequirement gets added in the future.\n\nSo, I agree that it is not a long-term goal for OpenStack to be a\nstandards organization encouraging multiple alternate implementations of\nits APIs.\n\nBut we do need to get moving on encouraging interoperability between\npublic clouds, even if that means making a short term tactical decision\nthat we don\'t need to require they use OpenStack code for everything.\n\nMark.\n\n\n\n','<1383231170.9301.620.camel@sorcha>',NULL),('<1383236179.88580.YahooMailNeo@web120401.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-10-31 09:16:19',-25200,'2013-10-31 16:16:19',NULL,'[Openstack-operators] Cinder volumes inaccessible after reboot of\n	cinder node','Hello,\n\nFor the volume management, I have a separate node which runs cinder.\nWhenever I reboot this machine, the existing volumes get \"inactive\" and I cannot attach them to any VM. Even when I lvchange them to active, I cannot attach them either.\n\nAnd here is compute log when I try to attach a volume to VM:\n\n2013-10-21 16:33:38 AUDIT nova.compute.manager [req-edf41883-2d87-47f7-a113-c71d94595df1 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] Attaching volume 370ccf0c-8d12-4e88-8cbc-2b12d9a4595f to /dev/vdb\n2013-10-21 16:33:39 WARNING nova.virt.libvirt.volume [req-edf41883-2d87-47f7-a113-c71d94595df1 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] ISCSI volume not yet found at: vdb. Will rescan & retry. ?Try number: 0\n2013-10-21 16:33:40 WARNING nova.virt.libvirt.volume [req-edf41883-2d87-47f7-a113-c71d94595df1 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] ISCSI volume not yet found at: vdb. Will rescan & retry. ?Try number: 1\n2013-10-21 16:33:44 WARNING nova.virt.libvirt.volume [req-edf41883-2d87-47f7-a113-c71d94595df1 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] ISCSI volume not yet found at: vdb. Will rescan & retry. ?Try number: 2\n2013-10-21 16:33:54 ERROR nova.compute.manager [req-edf41883-2d87-47f7-a113-c71d94595df1 3800b26a95c44e7abd1c080f7695560a 4c2340f60b7c48a0a2504eeefe2ff74a] [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] Failed to attach volume 370ccf0c-8d12-4e88-8cbc-2b12d9a4595f at /dev/vdb\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] Traceback (most recent call last):\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2046, in _attach_volume\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? mountpoint)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 117, in wrapped\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? temp_level, payload)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? self.gen.next()\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 92, in wrapped\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? return f(*args, **kw)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 642, in attach_volume\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? mount_device)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 634, in volume_driver_method\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? return method(connection_info, *args, **kwargs)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/utils.py\", line 760, in inner\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? retval = f(*args, **kwargs)\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/volume.py\", line 165, in connect_volume\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] ? ? % (host_device))\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8] NovaException: iSCSI device not found at /dev/disk/by-path/ip-10.1.0.13:3260-iscsi-iqn.2010-10.org.openstack:volume-370ccf0c-8d12-4e88-8cbc-2b12d9a4595f-lun-1\n2013-10-21 16:33:54 23470 TRACE nova.compute.manager [instance: b6a6ddcd-c785-40bc-9fe6-f68b682fb2f8]\n2013-10-21 16:33:55 23470 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\", line 276, in _process_data\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? rval = self.proxy.dispatch(ctxt, version, method, **args)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\", line 145, in dispatch\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return getattr(proxyobj, method)(ctxt, **kwargs)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 117, in wrapped\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? temp_level, payload)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 92, in wrapped\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return f(*args, **kw)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 175, in decorated_function\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? pass\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 161, in decorated_function\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return function(self, context, *args, **kwargs)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 196, in decorated_function\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? kwargs[\'instance\'][\'uuid\'], e, sys.exc_info())\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 190, in decorated_function\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return function(self, context, *args, **kwargs)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2020, in attach_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? context, instance.get(\'uuid\'), mountpoint)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2016, in attach_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? mountpoint, instance)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2055, in _attach_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? connector)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2046, in _attach_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? mountpoint)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 117, in wrapped\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? temp_level, payload)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/exception.py\", line 92, in wrapped\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return f(*args, **kw)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 642, in attach_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? mount_device)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 634, in volume_driver_method\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? return method(connection_info, *args, **kwargs)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/utils.py\", line 760, in inner\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? retval = f(*args, **kwargs)\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/volume.py\", line 165, in connect_volume\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp ? ? % (host_device))\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp NovaException: iSCSI device not found at /dev/disk/by-path/ip-10.1.0.13:3260-iscsi-iqn.2010-10.org.openstack:volume-370ccf0c-8d12-4e88-8cbc-2b12d9a4595f-lun-1\n2013-10-21 16:33:55 23470 TRACE nova.openstack.common.rpc.amqp\n\n\nThank you,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131031/3a619e25/attachment.html>\n\n',NULL,NULL),('<1383244059.2030.16.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 13:27:39',-18000,'2013-10-31 18:27:39',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n	\"unconference\"?','Hello,\n\nWould any of you attending the summit be interested in snagging an\nunconference session to discuss the state of play with image creation,\ncustomization and import?\n\nI can contribute an overview and demonstration of our Nova-native image\nbuilding tool.\n\nI\'d be interested in exploring integration points with Disk Image\nBuilder and Glance.\n\nAny takers?\n\n-Ian\n\n\n\n',NULL,NULL),('<1383245014-sup-5799@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 11:49:55',-25200,'2013-10-31 18:49:55',NULL,'[openstack-dev] When is it okay for submitters to say \'I don\'t\n	want to add tests\' ?','Excerpts from Khanh-Toan Tran\'s message of 2013-10-31 07:22:06 -0700:\n> Hi all,\n> \n> As a newbie of the community, I\'m not familiar with unittest and how to use it here. I\'ve learned that Jenkins runs tests\n> everytime we submit some code. But how to write the test and what is a \'good test\' and a \'bad test\'? I saw some commits\n> in gerrit but am unable to say if the written test is enough to judge the code, since it is the author of the code who writes\n> the test. Is there a framework to follow or some rules/pratices to respect?\n> \n> Do you have some links to help me out?\n> \n\nThis is a nice synopsis of the concept of test driven development:\n\nhttp://net.tutsplus.com/tutorials/python-tutorials/test-driven-development-in-python/\n\nIn OpenStack we always put tests in  _base_module_name_/tests, So if you\nare working on nova, you can see the unit tests in:\n\nnova/tests\n\nYou can generally always run the tests by installing the \'tox\' python\nmodule/command on your system and running \'tox\' in the root of the git\nrepository.\n\nProjects use various testing helpers to make tests easier to read and\nwrite. The most common one is testtools. A typical test will look like\nthis:\n\n\nimport testtools\n\nfrom basemodule import submodule\n\n\nclass TestSubmoduleFoo(testtools.TestCase):\n    def test_foo_apple(self):\n        self.assertEquals(1, submodule.foo(\'apple\'))\n\n    def test_foo_banana(self):\n        self.assertEquals(0, submodule.foo(\'banana\'))\n\n\nOften unit tests will include mocks and fakes to hide real world\ninterfacing code from the unit tests. You would do well to read up on\nhow those concepts work as well, google for \'python test mocking\' and\n\'python test fakes\'.\n\nGood luck, and #openstack-dev is always there to try and help. :)\n\n\n','<252647036.7481984.1383229326981.JavaMail.root@cloudwatt.com>',NULL),('<1383245419-sup-3094@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 11:56:42',-25200,'2013-10-31 18:56:42',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n	\"unconference\"?','Excerpts from Ian McLeod\'s message of 2013-10-31 11:27:39 -0700:\n> Hello,\n> \n> Would any of you attending the summit be interested in snagging an\n> unconference session to discuss the state of play with image creation,\n> customization and import?\n> \n> I can contribute an overview and demonstration of our Nova-native image\n> building tool.\n> \n> I\'d be interested in exploring integration points with Disk Image\n> Builder and Glance.\n> \n> Any takers?\n\nI am certain that one of the tripleo-core devs will want to be there,\nif not many of us. We don\'t have that many sessions scheduled so I\'d\nsuggest just trying to aim at when we\'re not having Deployment sessions.\n\n\n','<1383244059.2030.16.camel@localhost.localdomain>',NULL),('<1383247229.2030.19.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 14:20:29',-18000,'2013-10-31 19:20:29',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n \"unconference\"?','On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote:\n> Excerpts from Ian McLeod\'s message of 2013-10-31 11:27:39 -0700:\n> > Hello,\n> > \n> > Would any of you attending the summit be interested in snagging an\n> > unconference session to discuss the state of play with image creation,\n> > customization and import?\n> > \n> > I can contribute an overview and demonstration of our Nova-native image\n> > building tool.\n> > \n> > I\'d be interested in exploring integration points with Disk Image\n> > Builder and Glance.\n> > \n> > Any takers?\n> \n> I am certain that one of the tripleo-core devs will want to be there,\n> if not many of us. We don\'t have that many sessions scheduled so I\'d\n> suggest just trying to aim at when we\'re not having Deployment sessions.\n\nThose are exclusively on Tuesday, yes?\n\nhttp://icehousedesignsummit.sched.org/overview/type/tripleo+%\n28deployment%29#.UnKs1x8u2al\n\nSo any time Wednesday onward?\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1383245419-sup-3094@clint-HP>',NULL),('<1383249935.2030.24.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 15:05:35',-18000,'2013-10-31 20:05:35',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n \"unconference\"?','On Thu, 2013-10-31 at 12:50 -0700, Mark Washenberger wrote:\n> \n> \n> \n> On Thu, Oct 31, 2013 at 12:20 PM, Ian McLeod <imcleod at redhat.com>\n> wrote:\n>         On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote:\n>         > Excerpts from Ian McLeod\'s message of 2013-10-31 11:27:39\n>         -0700:\n>         > > Hello,\n>         > >\n>         > > Would any of you attending the summit be interested in\n>         snagging an\n>         > > unconference session to discuss the state of play with\n>         image creation,\n>         > > customization and import?\n>         > >\n>         > > I can contribute an overview and demonstration of our\n>         Nova-native image\n>         > > building tool.\n>         > >\n>         > > I\'d be interested in exploring integration points with\n>         Disk Image\n>         > > Builder and Glance.\n>         > >\n>         > > Any takers?\n\n> \n> Sounds like a good opportunity!\n>  \n\n>         \n>         So any time Wednesday onward?\n> \n> \n> That broad schedule constraint is good for Glance as well, as all of\n> our sessions are on Tuesday.\n\nCool.  I\'m not arriving until late Monday.  I\'ve asked russellb to try\nto grab an unconference slot.  However, I suppose I should just extend\nthis request to anyone who is interested.\n\nSo, could I ask that any interested parties look at the unconference\nsignup sheet when you arrive and, if you don\'t already see:\n\n\"Image Building and Customization\"\n\nplease grab a time slot from Wednesday onward?\n\n-Ian\n\n> \n> \n>  \n>         \n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAJyP2C8awsxkG=w3jrkJjjJ=YhktE16o9sO1GmRaVPkvoOV9+Q@mail.gmail.com>',NULL),('<1383250852-sup-4290@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 13:39:42',-25200,'2013-10-31 20:39:42',NULL,'[openstack-dev] [heat] [savanna] [trove] Place for software\n	configuration','Excerpts from Alexander Kuznetsov\'s message of 2013-10-31 10:51:54 -0700:\n> Hi Heat, Savanna and Trove teams,\n> \n> All this projects have common part related to software configuration\n> management.  For creation,  an environment  user should specify a hardware\n> parameter for vms:  choose flavor, decide use cinder or not, configure\n> networks for virtual machines, choose topology for hole deployment. Next\n> step is linking of software parameters with hardware specification. From\n> the end user point of view, existence of three different places and three\n> different ways (HEAT Hot DSL, Trove clustering API and Savanna Hadoop\n> templates) for software configuration is not convenient, especially if user\n> want to create an environment simultaneously involving components from\n> Savanna, Heat and Trove.\n> \n\nI\'m having a hard time extracting the problem statement. I _think_ that\nthe problem is:\n\nAs a user I want to tune my software for my available hardware.\n\nSo what you\'re saying is, if you select a flavor that has 4GB of RAM\nfor your application, you want to also tell your application that it\ncan use 3GB of RAM for an in-memory cache. Likewise, if one has asked\nTrove for an 8GB flavor, they will want to tell it to use 6.5GB of RAM\nfor InnoDB buffer cache.\n\nWhat you\'d like to see is one general pattern to express these types\nof things?\n\n> I can suggest two approaches to overcome this situations:\n> \n> Common library in oslo. This approach allows a deep domain specific\n> customization. The user will still have 3 places with same UI where user\n> should perform configuration actions.\n> \n> Heat or some other component for software configuration management. This\n> approach is the best for end users. In feature possible will be some\n> limitation on deep domain specific customization for configuration\n> management.\n\nCan you maybe be more concrete with your proposed solutions? The lack\nof a clear problem statement combined with these vague solutions has\nthoroughly confused me.\n\n\n','<CAA-P=7rvZD7k4ErFuKeOQ6PgN=eQoff49zTH7nY8WDhv8xUevA@mail.gmail.com>',NULL),('<1383253404.27911.4.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 21:03:24',0,'2013-10-31 21:03:24',NULL,'[OpenStack Foundation] OpenStack core and interoperability','On Thu, 2013-10-31 at 13:55 -0500, Mark Collier wrote:\n> The OpenStack Mission is to:\n> \n> To produce the ubiquitous OpenSource Cloud Computing platform that\n> will meet the needs of public and private clouds regardless of size,\n> by being simple to implement and massively scalable.\n> \n> IMHO the operative (action) word is \"produce.\"  This is why I agree\n> with Monty that it is critical that if we start somewhere, it should\n> be with a program based on people running the code, who have a vested\n> interest in the code\'s continual evolution and survival.  If we take\n> our eye of of that it could invite fragmentation and dilution of any\n> meaning for \"what is openstack\".\n> \n> \n> That said, it seems to me that technically speaking, we might only\n> need 1 set of tests that could feed the two distinct programs being\n> described (\"openstack cloud\" and \"compatible\").  So there might be to\n> two (marketing/business/logo) *programs* with unique requirements\n> other than testing, but with one test suite.\n> \n> \n> Therefore, IMHO, the best place to start is with the development of\n> the test itself while continuing to discuss the ways in which the\n> results might be applied to two distinct (logo) *prorgrams*.  Now I\n> understand that you cant develop a test in the absence of requirements\n> such as which projects to include, but we could probably come up with\n> a sensible starting point and add additional coverage over time\n> (increasing test coverage not necessarily implying that each must pass\n> to qualify for a specific program).\n\nOk, I\'d be totally cool with all that ... if I had any idea how we were\ngoing to go about creating \"a program based on people running the code\".\nI see a near bottomless pit of issues we\'d need to work through before\nputting that into place and I don\'t want to block making\ninteroperability progress on these issues.\n\nAm I missing something? What\'s (roughly) your take on how such a program\nwould work?\n\nTo be clear, I mean - assuming we know what code should be required to\nrun - how do we express those requirements precisely and certify that\nproviders are meeting them?\n\nThanks,\nMark.\n\n\n\n','<CAOpdJzEcHF+NDj7czXAcPjPsvq7BqhusNp+6Zy+ZiT=1p0p7Lg@mail.gmail.com>',NULL),('<1383254567.27911.12.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 21:22:47',0,'2013-10-31 21:22:47',NULL,'[OpenStack Foundation] OpenStack core and interoperability','On Thu, 2013-10-31 at 10:57 -0600, Monty Taylor wrote:\n> I don\'t see compatible as being any easier for us to put in place than\n> OpenStack. Both require us to make the same high level decision about\n> which services need to be either run or implemented. The difference is\n> in enforcement or assertion. I think we can do both.\n\nHow would we express which code is required and how would providers\n(self-)certify that they are running that code?\n\nDo we require zero modifications to the required code? If modifications\nare allowed, how do we express what level of modifications? Or do we\njust make it a good faith \"we haven\'t made any fundamental changes\"\nassertion?\n\nAre providers required to just run the required code, or actually route\nall user requests through that code? Are they allowed they put other\ncode between the user and the required code?\n\nOr do we require providers to submit a report of what upstream code\nthey\'re running and we (a human, on behalf of the Foundation) makes a\njudgement call based on guidelines as to whether this is a faithful\nimplementation? If we go this route - i.e. making it a question of a\njudgement call - how do we make those judgement calls totally fair and\ntransparent? We certainly don\'t want accusations of us rejecting a\nprovider because we don\'t like them.\n\nThe \"OpenStack compatible\" thing *is* either - the self-certification\nprocess is \"run these tests, you must pass them all\". Totally\nunambiguous.\n\nMark.\n\n\n\n','<nrym2m8451uuk4yl6yb80b6k.1383238648096@email.android.com>',NULL),('<1383255358.27911.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 21:35:58',0,'2013-10-31 21:35:58',NULL,'[openstack-dev] welcoming new committers (was Re: When is it\n okay for submitters to say \'I don\'t	want to add tests\' ?)','On Thu, 2013-10-31 at 11:49 -0700, Stefano Maffulli wrote:\n\n> Another idea that Tom suggested is to use gerrit automation to send back\n> to first time committers something in addition to the normal \'your patch\n> is waiting for review\' message. The message could be something like:\n> \n> > thank you for your first contribution to OpenStack. Your patch will\n> > now be tested automatically by OpenStack testing frameworks and once\n> > the automatic tests pass, it will be reviewed by other friendly\n> > developers. They will give you comments and may require you to refine\n> > it.\n> > \n> > Nobody gets his patch approved at first try so don\'t be concerned\n> > when someone will require you to do more iterations.\n> > \n> > Patches usually take 3 to 7 days to be approved so be patient and be\n> > available on IRC to ask and answer questions about your work. The\n> > more you participate in the community the more rewarding it is for\n> > you. You may also notice that the more you get to know people and get\n> > to be known, the faster your patches will be reviewed and eventually\n> > approved. Get to know others and be known by doing code reviews:\n> > anybody can and should do it.\n...\n\nVery nicely done. I really like it.\n\nThanks,\nMark.\n\n> PS I put the text on\n> https://etherpad.openstack.org/p/welcome-new-committers for refinements.\n> \n\n\n\n\n','<5272A62E.4000504@openstack.org>',NULL),('<1383256433.27911.23.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-31 21:53:53',0,'2013-10-31 21:53:53',NULL,'[OpenStack Foundation] OpenStack core and interoperability','On Thu, 2013-10-31 at 17:24 -0400, Monty Taylor wrote:\n> This is how it works now. You\'re required to run the code.\n> \n> Thing is, this is about legal contracts. So enforcement is hazy.\n> Essentially, if hp signs a trademark usage thing that says we have to\n> run it, our own lawyers won\'t let us do different. I think the first\n> step is to say \"OpenStack requires you run the code\" ... Then as\n> violations are brought to our attention, we look in to it.\n\nYou mean this?\n\nhttps://www.openstack.org/brand/openstack-cloud/\n\nWe could just add \"must pass API compatibility tests\" to those technical\nrequirements.\n\nWe might also list some other projects which \"must be included in their\nentirety in the product\".\n\nWould you see any further refinement of the requirements?\n\nIf we thought we could go ahead with those requirements and open the\nprogram to non-Platinum/Gold members, then great.\n\nThat allows us to get down to the real business of deciding which APIs\nare required and considering changing the list of required projects.\n\nMark.\n\n\n\n','<mfu7vicly606tja4ogblraux.1383254640751@email.android.com>',NULL),('<1383259556.69917.YahooMailIosMobile@web28805.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 22:45:56',0,'2013-10-31 22:45:56',NULL,'[openstack-dev] Re : welcoming new committers (was Re: When is it\n	okay for submitters to say \'I don\'t want to add tests\' ?)','Hi all, <br/><br/>Adding a message for new comers is a good idea. <br/>I am a new Horizon contributor, some of my fixes have been merged (thanks to Upstream University :-) and reviewers of course) but I still hesitate to do code review. To my mind, it is reserved to \"known\" developpers whose opinion matters... <br/><br/>- Romain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131031/0e54d848/attachment.html>\n\n','<5272A62E.4000504@openstack.org>',NULL),('<1383314560.24751.YahooMailNeo@web28803.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 14:02:40',0,'2013-11-01 14:02:40',NULL,'[openstack-dev] Re : welcoming new committers','> Indeed :) Can you share with us briefly what you found interesting in\n> the sessions of Upstream University? Which ones did you go to?\n\nUpsteam University acted like a starter to me. I attended the september session in Paris.\n\nI\'m interested in OpenStack since Essex but I did not dare submit my first patch.\nFolks at UU make this happen.\nDuring the two days group session we have learned the basics of Open Source and how to interact with such a community.\nThen, weekly assessments and phone calls allow us to stay motivated and thus not to give up. We are given valuable advices to get our fixes accepted.\n\nGuys at Upstream University are really cool and proficient.\n\n\n> Well, I think that anybody\'s opinion matters and you\'re not a new\n> OpenStack developer anymore. You have your own experience and your\n> reviews may definitely help somebody even newer than you to get his/her\n> patch refined before the more experienced developers get to it. I\'m sure\n> your comments, even without a vote, would help. Chime in then :)\n\nThanks for your kind words. \nI\'m going to start reviewing. I take note of what Jeremy Stanley said:\n\"OpenStack does not lack developers... it lacks reviewers.\"\n\n-Romain \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131101/5af7bd49/attachment.html>\n\n','<5272E52D.8030906@openstack.org>',NULL),('<1383330874.1734.23.camel@rupert>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-01 14:34:34',-14400,'2013-11-01 18:34:34',NULL,'[Openstack-docs] On translations and ITS','I have some experience (read: bias) in translation tools, so I\'m writing\nup a synopsis in the hopes in will be useful for the documentation\ntranslation session at the summit next week.\n\nDocument translation generally follows a three-step process:\n\n1) Segmentation: A program takes the XML files and breaks it up into\nchunks (often paragraphs) that can be individually translated and\ntracked. These are usually stored in either PO or XLIFF files, but in\nsome systems they might be records in a database.\n\n2) Translation: Translators translate those segments. They might edit\nthe PO or XLIFF files directly. They might use a graphical front-end.\nThey might do it through a web site that hides the files from them, but\nstill presents the individual segments.\n\n3) Merging: A program takes the translated segments, matches them up to\nthe appropriate nodes in the source document, and writes a localized XML\nfile.\n\nOnline tools like Transifex, Zanata, and Pootle are really about step 2,\nbut they often include code for steps 1 and 3 to give you an all-in-one\npackage. Unfortunately, to my knowledge, none of them use the W3C\nInternationalization Tag Set (ITS) to accomplish those steps. Luckily,\nthey let you provide POT files and can give you PO files, which means\nyou can plug your own code in for steps 1 and 3.\n\nITS is a W3C recommendation that provides a standard way to specify what\nparts of a document are translatable, what elements are inline, and\nvarious other things that are really critical for good segmentation. ITS\n2.0 was released this week, and addresses a whole slew of other issues.\n\nhttp://www.w3.org/TR/its20/\n\nITS lets you assert things about elements on a global level using XPath\nexpression. For example, let\'s say we don\'t want any of our screen\nelements to be translated. We could use a rule like this:\n\n<its:translateRule translate=\"no\" selector=\"//db:screen\"/>\n\nMagically, hundreds of messages will disappear from translators\' view,\nallowing them time to have dinner with their families instead. You can\nalso mark things locally. So for example, if we don\'t want to exclude\nall screen elements from translation, then on the ones we do want to\nexclude, we\'d write this:\n\n<screen its:translate=\"no\">\n\nYou can also specify which elements are within text (inline), which are\nspace-preserving, where there are references to external resources like\nimages that have to be localized, and lots more.\n\nBiased opinion: If you have an XML translation process that doesn\'t\ninvolve ITS, you\'re doing something wrong. (Disclosure: I was on the\nworking group that created ITS 2.0, and I\'m the developer of itstool.)\n\nThere are a number of tools that support ITS. Many of them work with PO\nor XLIFF files, so you can plug them into most online translation tools.\nI happen to be fond of my program, itstool, which supports PO files and\nhas a number of extensions that have been useful for other open source\nprojects like GNOME. \n\nhttp://itstool.org/\n\nIf you want a workflow that uses XLIFF files, you should look into\nOkapi, a fantastic open source framework that supports ITS.\n\nhttp://okapi.sourceforge.net/\n\nI do have a dog in this race, so I\'m trying not to be too pushy. But\nthere are a lot of smart people who spent a lot of time figuring this\nstuff out. If you have non-ITS segmentation and merging code, you\'ll\njust end up chasing problems that have already been solved.\n\nIf it\'s not obvious, I love talking about this stuff. So feel free to\nask me questions.\n\nThanks,\nShaun\n\n\n\n\n',NULL,NULL),('<1383357553.30249.10.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-01 21:59:13',-14400,'2013-11-02 01:59:13',NULL,'[Openstack-docs] On translations and ITS','On Sat, 2013-11-02 at 09:39 +1100, Tom Fifield wrote:\n> (CC OpenStack-i18n - consider joining!)\n> \n> A very nice lead in discussion to our two sessions related to this at\n> the summit :)\n> \n> Right now, we have some custom code for 1 that has been customised for\n> the OpenStack docs (for example, it excludes screen elements ;)), giving\n> some of the practical benefits of ITS. It\'s in tools/generatepot.\n\nThanks Tom. I didn\'t realize we actually had our own segmentation and\nmerging tools in openstack-manuals. That makes it easier to decide on\neach piece of the puzzle separately.\n\nLooking at the scripts, I see they\'re actually using xml2po for all the\nheavy lifing. xml2po was written around 2003/2004 by Danilo ?egan with\nhelp from Claude Paroz. I inherited maintainership of it around 2009. I\ntried to bend it to do things it wasn\'t designed for until I discovered\nITS. I began rearchitecting xml2po on top of ITS in 2010. itstool is the\nresult of that work.\n\n> Looking forward to discussing more next week.\n> \n> Regards,\n> \n> \n> Tom\n> \n> On 02/11/13 05:34, Shaun McCance wrote:\n> > I have some experience (read: bias) in translation tools, so I\'m writing\n> > up a synopsis in the hopes in will be useful for the documentation\n> > translation session at the summit next week.\n> > \n> > Document translation generally follows a three-step process:\n> > \n> > 1) Segmentation: A program takes the XML files and breaks it up into\n> > chunks (often paragraphs) that can be individually translated and\n> > tracked. These are usually stored in either PO or XLIFF files, but in\n> > some systems they might be records in a database.\n> > \n> > 2) Translation: Translators translate those segments. They might edit\n> > the PO or XLIFF files directly. They might use a graphical front-end.\n> > They might do it through a web site that hides the files from them, but\n> > still presents the individual segments.\n> > \n> > 3) Merging: A program takes the translated segments, matches them up to\n> > the appropriate nodes in the source document, and writes a localized XML\n> > file.\n> > \n> > Online tools like Transifex, Zanata, and Pootle are really about step 2,\n> > but they often include code for steps 1 and 3 to give you an all-in-one\n> > package. Unfortunately, to my knowledge, none of them use the W3C\n> > Internationalization Tag Set (ITS) to accomplish those steps. Luckily,\n> > they let you provide POT files and can give you PO files, which means\n> > you can plug your own code in for steps 1 and 3.\n> > \n> > ITS is a W3C recommendation that provides a standard way to specify what\n> > parts of a document are translatable, what elements are inline, and\n> > various other things that are really critical for good segmentation. ITS\n> > 2.0 was released this week, and addresses a whole slew of other issues.\n> > \n> > http://www.w3.org/TR/its20/\n> > \n> > ITS lets you assert things about elements on a global level using XPath\n> > expression. For example, let\'s say we don\'t want any of our screen\n> > elements to be translated. We could use a rule like this:\n> > \n> > <its:translateRule translate=\"no\" selector=\"//db:screen\"/>\n> > \n> > Magically, hundreds of messages will disappear from translators\' view,\n> > allowing them time to have dinner with their families instead. You can\n> > also mark things locally. So for example, if we don\'t want to exclude\n> > all screen elements from translation, then on the ones we do want to\n> > exclude, we\'d write this:\n> > \n> > <screen its:translate=\"no\">\n> > \n> > You can also specify which elements are within text (inline), which are\n> > space-preserving, where there are references to external resources like\n> > images that have to be localized, and lots more.\n> > \n> > Biased opinion: If you have an XML translation process that doesn\'t\n> > involve ITS, you\'re doing something wrong. (Disclosure: I was on the\n> > working group that created ITS 2.0, and I\'m the developer of itstool.)\n> > \n> > There are a number of tools that support ITS. Many of them work with PO\n> > or XLIFF files, so you can plug them into most online translation tools.\n> > I happen to be fond of my program, itstool, which supports PO files and\n> > has a number of extensions that have been useful for other open source\n> > projects like GNOME. \n> > \n> > http://itstool.org/\n> > \n> > If you want a workflow that uses XLIFF files, you should look into\n> > Okapi, a fantastic open source framework that supports ITS.\n> > \n> > http://okapi.sourceforge.net/\n> > \n> > I do have a dog in this race, so I\'m trying not to be too pushy. But\n> > there are a lot of smart people who spent a lot of time figuring this\n> > stuff out. If you have non-ITS segmentation and merging code, you\'ll\n> > just end up chasing problems that have already been solved.\n> > \n> > If it\'s not obvious, I love talking about this stuff. So feel free to\n> > ask me questions.\n> > \n> > Thanks,\n> > Shaun\n> > \n> > \n> > \n> > _______________________________________________\n> > Openstack-docs mailing list\n> > Openstack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<52742D9D.9000400@openstack.org>',NULL),('<1383366576-sup-3915@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 21:30:51',-25200,'2013-11-02 04:30:51',NULL,'[openstack-dev] [Heat] Do we need to clean up resource_id after\n	deletion?','Excerpts from Christopher Armstrong\'s message of 2013-11-01 11:34:56 -0700:\n> Vijendar and I are trying to figure out if we need to set the resource_id\n> of a resource to None when it\'s being deleted.\n> \n> This is done in a few resources, but not everywhere. To me it seems either\n> \n> a) redundant, since the resource is going to be deleted anyway (thus\n> deleting the row in the DB that has the resource_id column)\n> b) actively harmful to useful debuggability, since if the resource is\n> soft-deleted, you\'ll not be able to find out what physical resource it\n> represented before it\'s cleaned up.\n> \n> Is there some specific reason we should be calling resource_id_set(None) in\n> a check_delete_complete method?\n> \n\nI\'ve often wondered why some do it, and some don\'t.\n\nSeems to me that it should be done not inside each resource plugin but\nin the generic resource handling code.\n\nHowever, I have not given this much thought. Perhaps others can provide\ninsight into why it has been done that way.\n\n\n','<CAPkRfUSs5iSUy7Ss50+g7ZDH28E=YXxLTWs98Ycxy93ZS0toPw@mail.gmail.com>',NULL),('<1383387606.21448.YahooMailIosMobile@web28802.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-02 10:20:06',0,'2013-11-02 10:20:06',NULL,'[openstack-dev] Re : Re: Manual to build an application on open\n	stack',' > I am trying to build an app that resides on the cloud and would want to perform some basic storage management operations. <br/><br/>So, you want to build an app atop Swift ?<br/><br/>-Romain<br/>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131102/f8cc9b4c/attachment.html>\n\n','<CAL6MZqf-R2Qgb8V=0PayZLgPmxtO39debvNuNWm31ZPJyuYcpQ@mail.gmail.com>',NULL),('<1383600504.2998.33.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-04 16:28:24',-18000,'2013-11-04 21:28:24',NULL,'[Openstack-docs] [Openstack-i18n]  On translations and ITS','On Mon, 2013-11-04 at 01:28 +0800, Ying Chun Guo wrote:\n> Thank you for your sharing, Shaun.\n> I\'m the author of slicing and merging scripts.\n> \n> ITS looks like a useful standard and ITS tools should be helpful.\n> Can you share more about the usage of ITS tools?\n> Which on-line translation tools support embedded ITS tools?\n> Besides itstool.org, are there any other ITS tools that support po\n> files?\n\nHere\'s some information about the tools that support ITS 2.0:\n\nhttp://www.w3.org/International/its/wiki/ITS_Implementations\n\nAs for PO files, I\'m not really sure. I was the only person on the\nworking group that was actively working with them. Most of them use\nXLIFF instead. I believe Okapi actually has PO support, but they don\'t\nmake a big deal of it. Okapi is primarily an XLIFF-based framework.\n\nUsing the itstool command line is very similar to using the xml2po\ncommand line. I realize our scripts don\'t actually use the xml2po\ncommand line. Instead, they\'re Python scripts that import the xml2po\nlibrary and reimplement the wrapper code.\n\nI don\'t know the complete history of the scripts, so I can\'t speak to\neverything they do. But I think one of the reasons for them is to\noverride how particular elements are handled, and the only way to do\nthat in xml2po is to write a custom mode in Python.\n\nBasically, itstool was written so that people wouldn\'t have to do what\nyou did to accomplish what you accomplished. Here\'s the file you\'d use\nto make literallayout, programlisting, and screen non-translatable.\n\n<its:rules\n xmlns:its=\"http://www.w3.org/2005/11/its\"\n xmlns:db=\"http://docbook.org/ns/docbook\"\n version=\"2.0\">\n<its:translateRule translate=\"no\"\n selector=\"//db:literallayout | //db:programlisting | //db:screen\"/>\n</its:rules>\n\nI\'d be interested to hear what other problems the custom scripts are\naddressing. A lot of problems are solved by using ITS, but you might\nhave come across issues I haven\'t.\n\n> > Shaun McCance <shaunm at gnome.org> \n> > 2013/11/02 09:59\n> > \n> > To\n> > \n> > Tom Fifield <tom at openstack.org>, \n> > \n> > cc\n> > \n> > \"openstack-i18n at lists.openstack.org\" <openstack-\n> > i18n at lists.openstack.org>, openstack-docs at lists.openstack.org\n> > \n> > Subject\n> > \n> > Re: [Openstack-i18n] [Openstack-docs] On translations and ITS\n> > \n> > On Sat, 2013-11-02 at 09:39 +1100, Tom Fifield wrote:\n> > > (CC OpenStack-i18n - consider joining!)\n> > > \n> > > A very nice lead in discussion to our two sessions related to this\n> at\n> > > the summit :)\n> > > \n> > > Right now, we have some custom code for 1 that has been customised\n> for\n> > > the OpenStack docs (for example, it excludes screen elements ;)),\n> giving\n> > > some of the practical benefits of ITS. It\'s in tools/generatepot.\n> > \n> > Thanks Tom. I didn\'t realize we actually had our own segmentation\n> and\n> > merging tools in openstack-manuals. That makes it easier to decide\n> on\n> > each piece of the puzzle separately.\n> > \n> > Looking at the scripts, I see they\'re actually using xml2po for all\n> the\n> > heavy lifing. xml2po was written around 2003/2004 by Danilo ?egan\n> with\n> > help from Claude Paroz. I inherited maintainership of it around\n> 2009. I\n> > tried to bend it to do things it wasn\'t designed for until I\n> discovered\n> > ITS. I began rearchitecting xml2po on top of ITS in 2010. itstool is\n> the\n> > result of that work.\n> > \n> > > Looking forward to discussing more next week.\n> > > \n> > > Regards,\n> > > \n> > > \n> > > Tom\n> > > \n> > > On 02/11/13 05:34, Shaun McCance wrote:\n> > > > I have some experience (read: bias) in translation tools, so I\'m\n> writing\n> > > > up a synopsis in the hopes in will be useful for the\n> documentation\n> > > > translation session at the summit next week.\n> > > > \n> > > > Document translation generally follows a three-step process:\n> > > > \n> > > > 1) Segmentation: A program takes the XML files and breaks it up\n> into\n> > > > chunks (often paragraphs) that can be individually translated\n> and\n> > > > tracked. These are usually stored in either PO or XLIFF files,\n> but in\n> > > > some systems they might be records in a database.\n> > > > \n> > > > 2) Translation: Translators translate those segments. They might\n> edit\n> > > > the PO or XLIFF files directly. They might use a graphical\n> front-end.\n> > > > They might do it through a web site that hides the files from\n> them, but\n> > > > still presents the individual segments.\n> > > > \n> > > > 3) Merging: A program takes the translated segments, matches\n> them up to\n> > > > the appropriate nodes in the source document, and writes a\n> localized XML\n> > > > file.\n> > > > \n> > > > Online tools like Transifex, Zanata, and Pootle are really about\n> step 2,\n> > > > but they often include code for steps 1 and 3 to give you an\n> all-in-one\n> > > > package. Unfortunately, to my knowledge, none of them use the\n> W3C\n> > > > Internationalization Tag Set (ITS) to accomplish those steps.\n> Luckily,\n> > > > they let you provide POT files and can give you PO files, which\n> means\n> > > > you can plug your own code in for steps 1 and 3.\n> > > > \n> > > > ITS is a W3C recommendation that provides a standard way to\n> specify what\n> > > > parts of a document are translatable, what elements are inline,\n> and\n> > > > various other things that are really critical for good\n> segmentation. ITS\n> > > > 2.0 was released this week, and addresses a whole slew of other\n> issues.\n> > > > \n> > > > http://www.w3.org/TR/its20/\n> > > > \n> > > > ITS lets you assert things about elements on a global level\n> using XPath\n> > > > expression. For example, let\'s say we don\'t want any of our\n> screen\n> > > > elements to be translated. We could use a rule like this:\n> > > > \n> > > > <its:translateRule translate=\"no\" selector=\"//db:screen\"/>\n> > > > \n> > > > Magically, hundreds of messages will disappear from translators\'\n> view,\n> > > > allowing them time to have dinner with their families instead.\n> You can\n> > > > also mark things locally. So for example, if we don\'t want to\n> exclude\n> > > > all screen elements from translation, then on the ones we do\n> want to\n> > > > exclude, we\'d write this:\n> > > > \n> > > > <screen its:translate=\"no\">\n> > > > \n> > > > You can also specify which elements are within text (inline),\n> which are\n> > > > space-preserving, where there are references to external\n> resources like\n> > > > images that have to be localized, and lots more.\n> > > > \n> > > > Biased opinion: If you have an XML translation process that\n> doesn\'t\n> > > > involve ITS, you\'re doing something wrong. (Disclosure: I was on\n> the\n> > > > working group that created ITS 2.0, and I\'m the developer of\n> itstool.)\n> > > > \n> > > > There are a number of tools that support ITS. Many of them work\n> with PO\n> > > > or XLIFF files, so you can plug them into most online\n> translation tools.\n> > > > I happen to be fond of my program, itstool, which supports PO\n> files and\n> > > > has a number of extensions that have been useful for other open\n> source\n> > > > projects like GNOME. \n> > > > \n> > > > http://itstool.org/\n> > > > \n> > > > If you want a workflow that uses XLIFF files, you should look\n> into\n> > > > Okapi, a fantastic open source framework that supports ITS.\n> > > > \n> > > > http://okapi.sourceforge.net/\n> > > > \n> > > > I do have a dog in this race, so I\'m trying not to be too pushy.\n> But\n> > > > there are a lot of smart people who spent a lot of time figuring\n> this\n> > > > stuff out. If you have non-ITS segmentation and merging code,\n> you\'ll\n> > > > just end up chasing problems that have already been solved.\n> > > > \n> > > > If it\'s not obvious, I love talking about this stuff. So feel\n> free to\n> > > > ask me questions.\n> > > > \n> > > > Thanks,\n> > > > Shaun\n> > > > \n> > > > \n> > > > \n> > > > _______________________________________________\n> > > > Openstack-docs mailing list\n> > > > Openstack-docs at lists.openstack.org\n> > > >\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > > > \n> > > \n> > > \n> > > _______________________________________________\n> > > Openstack-docs mailing list\n> > > Openstack-docs at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> > \n> > \n> > _______________________________________________\n> > Openstack-i18n mailing list\n> > Openstack-i18n at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<OF0A57757F.53CC26A5-ON48257C18.005F6F6A-48257C18.0060072E@cn.ibm.com>',NULL),('<1383614860-sup-8730@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-05 09:31:39',28800,'2013-11-05 01:31:39',NULL,'[openstack-dev] [Heat] Network topologies','Excerpts from Kyle Mestery (kmestery)\'s message of 2013-11-05 06:35:04 +0800:\n> On Nov 2, 2013, at 3:12 PM, Salvatore Orlando <sorlando at nicira.com> wrote:\n> > \n> > Hi.\n> > \n> > I looked at the detailed API specification submitted by Edgar.\n> > I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work.\n> > On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else.\n> > \n> > First, the \"use cases\" section merely re-states the objective session. I think that section should somehow address the questions \"why do we need this API?\" \"How having an API for storing network topologies would be useful for us\".\n> > \n> > The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals?\n> > \n> \n> Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion!\n> \n> Thanks,\n> Kyle\n> \n> [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1\n> \n\nHi Kyle, can you copy this to etherpad.openstack.org and link it from\nhttps://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads\n\nThanks!\n\n\n','<6756625F-7FD6-48A1-A596-CB6BF59D4AE2@cisco.com>',NULL),('<1383615639-sup-9112@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-05 09:46:13',28800,'2013-11-05 01:46:13',NULL,'[openstack-dev] [Solum]: Welcome to the community site for\n	Solum !!','This is cool, I think other OpenStack projects would do well to have a\nmore user-centric landing page.\n\nI have a suggestion for a logo for Solum though ...\n\nhttp://www.openstack.org/brand/openstack-logo/\n\nWhat I mean is, rather than create a new brand.. enhance the OpenStack\nbrand with users.\n\nExcerpts from Roshan Agrawal\'s message of 2013-11-05 09:25:33 +0800:\n> The community site for Solum has gone live! www.Solum.io<http://www.Solum.io>  - this is a landing page for all things Solum related.\n> \n> Also check out the blog section on the site.\n> \n> The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn\'t too bad either, is it?\n\n\n','<9C1B7917DE16F44D855E72328D666ED1231BB7C3@ORD1EXD03.RACKSPACE.CORP>',NULL),('<1383617459.2009.5.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 20:10:59',-21600,'2013-11-05 02:10:59',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n \"unconference\"?','(Forgive the top-post)\n\nDone.\n\nI have requested: \n3:30 - 4:10 PM\nMeeting Room 2\n\"The State of Image Building\"\n\nAs I say, I can speak briefly to the work we\'ve been doing with Nova\nnative image building but would be very interested to meet up with other\ninterested parties who are approaching the fundamental problem of image\nconstruction and customization in OpenStack.\n\n-Ian\n\nOn Thu, 2013-10-31 at 15:05 -0500, Ian McLeod wrote:\n> On Thu, 2013-10-31 at 12:50 -0700, Mark Washenberger wrote:\n> > \n> > \n> > \n> > On Thu, Oct 31, 2013 at 12:20 PM, Ian McLeod <imcleod at redhat.com>\n> > wrote:\n> >         On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote:\n> >         > Excerpts from Ian McLeod\'s message of 2013-10-31 11:27:39\n> >         -0700:\n> >         > > Hello,\n> >         > >\n> >         > > Would any of you attending the summit be interested in\n> >         snagging an\n> >         > > unconference session to discuss the state of play with\n> >         image creation,\n> >         > > customization and import?\n> >         > >\n> >         > > I can contribute an overview and demonstration of our\n> >         Nova-native image\n> >         > > building tool.\n> >         > >\n> >         > > I\'d be interested in exploring integration points with\n> >         Disk Image\n> >         > > Builder and Glance.\n> >         > >\n> >         > > Any takers?\n> \n> > \n> > Sounds like a good opportunity!\n> >  \n> \n> >         \n> >         So any time Wednesday onward?\n> > \n> > \n> > That broad schedule constraint is good for Glance as well, as all of\n> > our sessions are on Tuesday.\n> \n> Cool.  I\'m not arriving until late Monday.  I\'ve asked russellb to try\n> to grab an unconference slot.  However, I suppose I should just extend\n> this request to anyone who is interested.\n> \n> So, could I ask that any interested parties look at the unconference\n> signup sheet when you arrive and, if you don\'t already see:\n> \n> \"Image Building and Customization\"\n\n\n\n\n> \n> please grab a time slot from Wednesday onward?\n> \n> -Ian\n> \n> > \n> > \n> >  \n> >         \n> >         >\n> >         > _______________________________________________\n> >         > OpenStack-dev mailing list\n> >         > OpenStack-dev at lists.openstack.org\n> >         >\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1383249935.2030.24.camel@localhost.localdomain>',NULL),('<1383621068.2009.11.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 21:11:08',-21600,'2013-11-05 03:11:08',NULL,'[openstack-dev] HK Summit - Image Creation and Customization\n \"unconference\"?','Apologies, updated with the day. (Thursday)\n\nOn Mon, 2013-11-04 at 20:10 -0600, Ian McLeod wrote:\n> (Forgive the top-post)\n> \n> Done.\n> \n> I have requested: \nThursday\n\n> 3:30 - 4:10 PM\n> Meeting Room 2\n> \"The State of Image Building\"\n> \n> As I say, I can speak briefly to the work we\'ve been doing with Nova\n> native image building but would be very interested to meet up with other\n> interested parties who are approaching the fundamental problem of image\n> construction and customization in OpenStack.\n> \n> -Ian\n> \n> On Thu, 2013-10-31 at 15:05 -0500, Ian McLeod wrote:\n> > On Thu, 2013-10-31 at 12:50 -0700, Mark Washenberger wrote:\n> > > \n> > > \n> > > \n> > > On Thu, Oct 31, 2013 at 12:20 PM, Ian McLeod <imcleod at redhat.com>\n> > > wrote:\n> > >         On Thu, 2013-10-31 at 11:56 -0700, Clint Byrum wrote:\n> > >         > Excerpts from Ian McLeod\'s message of 2013-10-31 11:27:39\n> > >         -0700:\n> > >         > > Hello,\n> > >         > >\n> > >         > > Would any of you attending the summit be interested in\n> > >         snagging an\n> > >         > > unconference session to discuss the state of play with\n> > >         image creation,\n> > >         > > customization and import?\n> > >         > >\n> > >         > > I can contribute an overview and demonstration of our\n> > >         Nova-native image\n> > >         > > building tool.\n> > >         > >\n> > >         > > I\'d be interested in exploring integration points with\n> > >         Disk Image\n> > >         > > Builder and Glance.\n> > >         > >\n> > >         > > Any takers?\n> > \n> > > \n> > > Sounds like a good opportunity!\n> > >  \n> > \n> > >         \n> > >         So any time Wednesday onward?\n> > > \n> > > \n> > > That broad schedule constraint is good for Glance as well, as all of\n> > > our sessions are on Tuesday.\n> > \n> > Cool.  I\'m not arriving until late Monday.  I\'ve asked russellb to try\n> > to grab an unconference slot.  However, I suppose I should just extend\n> > this request to anyone who is interested.\n> > \n> > So, could I ask that any interested parties look at the unconference\n> > signup sheet when you arrive and, if you don\'t already see:\n> > \n> > \"Image Building and Customization\"\n> \n> \n> \n> \n> > \n> > please grab a time slot from Wednesday onward?\n> > \n> > -Ian\n> > \n> > > \n> > > \n> > >  \n> > >         \n> > >         >\n> > >         > _______________________________________________\n> > >         > OpenStack-dev mailing list\n> > >         > OpenStack-dev at lists.openstack.org\n> > >         >\n> > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >         \n> > >         \n> > >         \n> > >         _______________________________________________\n> > >         OpenStack-dev mailing list\n> > >         OpenStack-dev at lists.openstack.org\n> > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >         \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<1383617459.2009.5.camel@localhost.localdomain>',NULL),('<1383636691-sup-7924@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-05 15:34:08',28800,'2013-11-05 07:34:08',NULL,'[openstack-dev] [Solum]: Welcome to the community site for\n	Solum !!','Excerpts from Adrian Otto\'s message of 2013-11-05 15:10:09 +0800:\n> Clint,\n> \n> The rules about use of the OpenStack brand are clear, and Solum is not allowed to use it. We are a part of the OpenStack ecosystem, but the OpenStack brand (trademark/logo) is reserved for those projects that are Integrated or Core. At this point what we need is a good collaboration among contributors, with participation from other OpenStack ecosystem projects. I think we are on the right track, and our community is forming nicely. When we have shippable software and are ready to build a user base, that\'s when the branding issues will matter more.\n> \n\nAgreed on all points. I\'m sure we could have a lively debate on what a\nshippable Solum looks like.\n\nMy point is, I don\'t believe that it is wise to build the Solum brand\nuntil you are ready to seek full integration with OpenStack.\n\n\n','<A5E45A13-F73C-4105-BE9D-169ED87560F7@rackspace.com>',NULL),('<1383689486-sup-4710@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-06 06:16:33',28800,'2013-11-05 22:16:33',NULL,'[openstack-dev] [heat][keystone] APIs, roles,\n	request scope and admin-ness','Excerpts from Steven Hardy\'s message of 2013-11-03 00:06:39 +0800:\n> Hi all,\n> \n> Looking to start a wider discussion, prompted by:\n> https://review.openstack.org/#/c/54651/\n> https://blueprints.launchpad.net/heat/+spec/management-api\n> https://etherpad.openstack.org/p/heat-management-api\n> \n> Summary - it has been proposed to add a management API to Heat, similar in\n> concept to the admin/public API topology used in keystone.\n> \n> I\'m concerned that this may not be a pattern we want to propagate throughout\n> OpenStack, and that for most services, we should have one API to access data,\n> with the scope of the data returned/accessible defined by the roles held by\n> the user (ie making proper use of the RBAC facilities afforded to us via\n> keystone).\n> \n> In the current PoC patch, a users admin-ness is derived from the fact that\n> they are accessing a specific endpoint, and that policy did not deny them\n> access to that endpoint.  I think this is wrong, and we should use keystone\n> roles to decide the scope of the request.\n> \n> The proposal seems to consider tenants as the top-level of abstraction, with\n> the next level up being a global service provider admin, but this does not\n> consider the keystone v3 concept of domains [1], or that you may wish to\n> provide some of these admin-ish features to domain-admin users (who will\n> adminster data accross multiple tenants, just like has been proposed), via the\n> public-facing API.\n> \n> It seems like we need a way of scoping the request (via data in the context),\n> based on a heirarchy of admin-ness, like:\n> \n> 1. Normal user\n> 2. Tenant Admin (has admin role in a tenant)\n> 3. Domain Admin (has admin role in all tenants in the domain)\n> 4. Service Admin (has admin role everywhere, like admin_token for keystone)\n> \n> The current \"is_admin\" flag which is being used in the PoC patch won\'t allow\n> this granularity of administrative boundaries to be represented, and splitting\n> admin actions into a separate API will prevent us providing tenant and domain\n> level admin functionality to customers in a public cloud environment.\n> \n> It has been mentioned that in keystone, if you have admin in one tenant, you\n> are admin everywhere, which is a pattern I think we should not follow -\n> keystone folks, what are your thoughts in terms of roadmap to make role\n> assignment (at the request level) scoped to tenants rather than globally\n> applied?  E.g what data can we add to move from X-Roles in auth_token, to\n> expressing roles in multiple tenants and domains?\n> \n\nRight, roles should be tenant and domain scoped, and the roles that we\nconsume in our policy definitions should not need to know anything about\nthe hierarchy. It seems very broken to me that there would be no way to\nmake a user who can only create more users in their tenant in Keystone.\nLikewise, I would consider Heat broken if I had to use a special API\nfor doing things with a role I already have that is just scoped more\nbroadly than a single tenant or domain.\n\n> Basically, I\'m very concerned that we discuss this, get a clear roadmap which\n> will work with future keystone admin/role models, and is not a short-term hack\n> which we won\'t want to maintain long-term.\n> \n> What are peoples thoughts on this?\n\nLet\'s try and find a keystone dev or two in the hallway at the summit\nand get some clarity on the way Keystone is intended to work, which may\nhelp us decide if we want to follow their admin-specific-API paradigm or\nnot.\n\n\n','<20131102160638.GC21437@t430slt.redhat.com>',NULL),('<1383700030-sup-4543@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-06 09:10:16',28800,'2013-11-06 01:10:16',NULL,'[openstack-dev] A Tool for Making OpenStack Log Reading a Bit\n	Easier','I often use ccze to look at logs. It has some built in things like\ncoloring the words \"warn\" or \"warning\" yellow and \"error\" red. It would\nbe great to have this filter added as another ccze plugin.\n\nExcerpts from Solly Ross\'s message of 2013-11-06 05:58:02 +0800:\n> Hello All,\n> The other day, I was reading through a debug-level OpenStack log, and came to the realization that reading OpenStack debug-level logs was difficult, to say the least -- they can be very busy, and it is hard to quickly filter out relevant information.  Thus, I wrote a little Perl script to make reading dense debug-level logs a bit easier: https://github.com/DirectXMan12/os_log_prettifier.  I figured that I\'d share it with other people.  Basically, the script highlights certain key details using color and bolding (via ANSI control codes), and can filter lines based on subject (in the form of \'x.y.z\') or message type, using regular expressions.  I hope people find it useful!\n> \n> Best Regards,\n> Solly Ross\n> \n\n\n','<1399043596.20241154.1383688682476.JavaMail.root@redhat.com>',NULL),('<1383724573.2359.3.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-06 17:56:13',36000,'2013-11-06 07:56:13',NULL,'[openstack-dev] [heat][keystone] APIs, roles,\n request scope and admin-ness','On Wed, 2013-11-06 at 06:16 +0800, Clint Byrum wrote:\n> Excerpts from Steven Hardy\'s message of 2013-11-03 00:06:39 +0800:\n> > Hi all,\n> > \n> > Looking to start a wider discussion, prompted by:\n> > https://review.openstack.org/#/c/54651/\n> > https://blueprints.launchpad.net/heat/+spec/management-api\n> > https://etherpad.openstack.org/p/heat-management-api\n> > \n> > Summary - it has been proposed to add a management API to Heat, similar in\n> > concept to the admin/public API topology used in keystone.\n> > \n> > I\'m concerned that this may not be a pattern we want to propagate throughout\n> > OpenStack, and that for most services, we should have one API to access data,\n> > with the scope of the data returned/accessible defined by the roles held by\n> > the user (ie making proper use of the RBAC facilities afforded to us via\n> > keystone).\n\nI feel that i can speak for the keystone developers when i say avoid\nthis at all costs! Currently in the implementation of keystone what is\nexposed on the admin port is the same as the public port with the\nintention that we can hopefully remove adminURL altogether. \n\n> > In the current PoC patch, a users admin-ness is derived from the fact that\n> > they are accessing a specific endpoint, and that policy did not deny them\n> > access to that endpoint.  I think this is wrong, and we should use keystone\n> > roles to decide the scope of the request.\n> > \n> > The proposal seems to consider tenants as the top-level of abstraction, with\n> > the next level up being a global service provider admin, but this does not\n> > consider the keystone v3 concept of domains [1], or that you may wish to\n> > provide some of these admin-ish features to domain-admin users (who will\n> > adminster data accross multiple tenants, just like has been proposed), via the\n> > public-facing API.\n> > \n> > It seems like we need a way of scoping the request (via data in the context),\n> > based on a heirarchy of admin-ness, like:\n> > \n> > 1. Normal user\n> > 2. Tenant Admin (has admin role in a tenant)\n> > 3. Domain Admin (has admin role in all tenants in the domain)\n> > 4. Service Admin (has admin role everywhere, like admin_token for keystone)\n> > \n> > The current \"is_admin\" flag which is being used in the PoC patch won\'t allow\n> > this granularity of administrative boundaries to be represented, and splitting\n> > admin actions into a separate API will prevent us providing tenant and domain\n> > level admin functionality to customers in a public cloud environment.\n> > \n> > It has been mentioned that in keystone, if you have admin in one tenant, you\n> > are admin everywhere, which is a pattern I think we should not follow -\n> > keystone folks, what are your thoughts in terms of roadmap to make role\n> > assignment (at the request level) scoped to tenants rather than globally\n> > applied?  E.g what data can we add to move from X-Roles in auth_token, to\n> > expressing roles in multiple tenants and domains?\n> > \n> \n> Right, roles should be tenant and domain scoped, and the roles that we\n> consume in our policy definitions should not need to know anything about\n> the hierarchy. It seems very broken to me that there would be no way to\n> make a user who can only create more users in their tenant in Keystone.\n> Likewise, I would consider Heat broken if I had to use a special API\n> for doing things with a role I already have that is just scoped more\n> broadly than a single tenant or domain.\n\nThis is possible with the v3 api.\n\n> > Basically, I\'m very concerned that we discuss this, get a clear roadmap which\n> > will work with future keystone admin/role models, and is not a short-term hack\n> > which we won\'t want to maintain long-term.\n> > \n> > What are peoples thoughts on this?\n> \n> Let\'s try and find a keystone dev or two in the hallway at the summit\n> and get some clarity on the way Keystone is intended to work, which may\n> help us decide if we want to follow their admin-specific-API paradigm or\n> not.\n\nThere are a number of us at summit (myself included). Our sessions tend\nto be in the afternoon so you can probably find at least 1 dev in the\ndev lounge at the other times. \n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<1383689486-sup-4710@clint-HP>',NULL),('<1383791511-sup-658@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-07 10:36:46',28800,'2013-11-07 02:36:46',NULL,'[Openstack] [Heat] Locked Outputs','Excerpts from Andrew Plunk\'s message of 2013-11-07 06:48:33 +0800:\n> Hello All,\n> \n> Imagine for a minute that you are displaying outputs from heat, but some of those outputs could have sensitive data (think passwords or private keys). It would be beneficial to allow outputs to be accessed once, and then go into a locked state. This could result in the following:\n> \n\nThis is an interesting concept. I\'d like to start with a problem\nstatement though, as it is not clear what this is meant to solve.\n\n> 1). After an output is accessed for the first time, the output will become locked, and subsequent calls to the engine to return that output will return nothing.\n> example:\n> >show stack \n> \n> \"outputs\": {\n>   \"password\": \"password\"\n>  }\n> \n> >show stack\n> \n> \"outputs\": {\n> }\n> \n> \n> 2). Another option is after an output is accessed for the first time, the output will become locked, and subsequent calls to the engine will return the output with a flag saying that this output has been locked, allowing whatever is consuming that output to take the necessary action.\n> example:\n> \n> >show stack\n> \n> \"outputs\": {\n>   \"password\": {\n>     \"value\": \"password\",\n>     \"locked\": false\n>   }\n> }\n> \n> >show stack\n> \n> \"outputs\": {\n>   \"password\": {\n>     \"value\": \"password\",\n>     \"locked\": true\n>   }\n> }\n> \n> \n> The outputs section of the template for either case would could look like:\n> outputs:\n>   password:\n>     value: { get_attr: [ some_resource, some_value ] }\n>     description: The password\n>     view_once: True\n> \n\nSo it seems that the problem you are seeking to solve is limiting access\nto sensitive outputs. The solution mentioned above certainly narrows\nthe attack surface, but it suffers from a DOS race condition where a\nbad actor can lock you out of your own resource.\n\nI have a different idea for that, which is to encrypt the output using\npublic key cryptography.\n\nheat stack-create -f mytemplate.yaml -P PasswordRecipientKey=\"$(gpg\n--armor --print-key me at foo.com)\"\n\nAnd then have an output type of \"Encrypted\"\n\nOutputs:\n  Password:\n    Type: Encrypted\n    Keys:\n      - {Ref: PasswordRecipientKey}\n\nNow you can simply decrypt this with your local gpg key. heatclient\ncould even automatically do this for you making it transparent as long\nas you have a gpg key agent running.\n\n\n','<CDEAE34515107A4A92D7B32C0E5DFD4E012F49E9@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1383803809.738.26.camel@dabdike>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 13:56:49',28800,'2013-11-07 05:56:49',NULL,'[openstack-dev] Bad review patterns','On Thu, 2013-11-07 at 00:21 +0000, Day, Phil wrote:\n> > \n> > Leaving a mark.\n> > ===============\n> > \n> > You review a change and see that it is mostly fine, but you feel that since you\n> > did so much work reviewing it, you should at least find\n> > *something* wrong. So you find some nitpick and -1 the change just so that\n> > they know you reviewed it.\n> > \n> > This is quite obvious. Just don\'t do it. It\'s OK to spend an hour reviewing\n> > something, and then leaving no comments on it, because it\'s simply fine, or\n> > because we had to means to test someting (see the first pattern).\n> > \n> > \n> \n> Another one that comes into this category is adding a -1 which just says \"I agree with\n> the other -1\'s in here\".   If you have some additional perspective and can expand on\n> it then that\'s fine - otherwise it adds very little and is just review count chasing.\n> \n> It\'s an unfortunate consequence of counting and publishing review stats that having\n> such a measure will inevitable also drive behavour.\n\nPerhaps a source of the problem is early voting.  Feeling pressure to\nadd a +/-1 (or even 2) without fully asking what\'s going on in the code\nleads to premature adjudication.\n\nFor instance, I have to do a lot of reviews in SCSI; I\'m a subject\nmatter expert, so I do recognise some bad coding patterns and ask for\nthem to be changed unconditionally, but a lot of the time I don\'t\nnecessarily understand why the code was done in the way it was, so I\nask.  Before I get the answer I\'m not really qualified to judge the\nmerits.\n\nJames\n\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006EC1A4E@G5W2737.americas.hpqcorp.net>',NULL),('<1383933429.2998.126.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-08 12:57:09',-18000,'2013-11-08 17:57:09',NULL,'[Openstack-docs] Inconsistency wrt hostnames in replaceable','Reviewing some patches, I realize we\'re not all on the same page when it\ncomes to whether to put hostnames in replaceable. That is, which one of\nthese do we write?\n\nqpid_hostname=controller\n\nqpid_hostname=<replaceable>controller</replaceable>\n\nIn the latter case, you\'re making it clear that it can be replaced with\nsomething different, if you\'re doing things differently. In the former,\nreplaceable is reserved for things that must be replaced by the user,\nlike passwords or randomly generated IDs.\n\nI tend to lean toward only using replaceable when we expect the user\nmust replace the text, so that it stands out in the reader\'s mind. After\nall, this is OpenStack, so everything *could* conceivably be changed. We\ndon\'t want to wrap the whole book in one big replaceable. :)\n\n--\nShaun\n\n\n\n\n',NULL,NULL),('<1383935052.61514045@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-08 12:24:12',-21600,'2013-11-08 18:24:12',NULL,'[openstack-dev] [Solum] Some initial code copying for\n	db/migration','There are several different points being raised here,\nall very interesting. Trying to separate them below.\n\n1) Using objects as an abstraction for versioned data:\n   This seems like a good direction overall, especially from the point-of-view\n   of backwards compatibility of consumers of the object. However, after looking through some\n   of the objects defined in nova/objects/, I am not sure if I understand how\n   this works. Specifically, it is not clear to me how might the consumer of the \n   object be able to query different versions of it at runtime.\n\n\n2) Using objects as an abstraction to support different kinds of backends\n   (SQL and non-SQL backends):\n   - Again, a good direction overall. From implementation point-of-view though\n   this may become tricky, in the sense that the object layer would need to be\n   designed with just the right amount of logic so as to be able to work with either \n   a SQL or a non-SQL backend. It will be good to see some examples of how this might \n   be done if there are any existing examples somewhere.\n\n\n3) From Solum\'s point-of-view, the concern around the potential downtime\n   that may be incurred in the API-layer because of breaking object model changes,\n   and so, investigating how to design this correctly right from the start.\n   - This is a valid concern. We will have to design for this at sometime or other anyways.\n   Doing this first up might be good with regards to understanding how the decision of\n   using versioned objects would tie with the API layer implemented in Pecan+WSME.\n   I don\'t have much experience with either, so would love to hear about it from those who do.\n\n\nBest Regards,\nDevdatta\n\n\n-----Original Message-----\nFrom: \"Clayton Coleman\" <ccoleman at redhat.com>\nSent: Thursday, November 7, 2013 8:26pm\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nCc: \"Dan Smith\" <dms at danplanet.com>\nSubject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration\n\n----- Original Message -----\n> >   https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420\n> >   https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43\n> \n> This API and these models are what we are trying to avoid exposing to\n> the rest of nova. By wrapping these in our NovaObject-based structures,\n> we can bundle versioned data and methods together which is what we need\n> for cross-version compatibility and parity for the parts of nova that\n> are not allowed to talk to the database directly.\n> \n> See the code in nova/objects/* for the implementations. Right now, these\n> just call into the db_api.py, but eventually we want to move the actual\n> database implementation into the objects themselves and hopefully\n> dispense with most or all of the sqlalchemy/* stuff. This also provides\n> us the ability to use other persistence backends that aren\'t supported\n> by sqlalchemy, or that don\'t behave like it does.\n> \n> If you\'re going to be at the summit, come to the \"objects\" session on\n> Thursday where we\'ll talk about this in more detail. Other projects have\n> expressed interest in moving the core framework into Oslo so that we\'re\n> all doing things in roughly the same way. It would be good to get you\n> started on \"the right way\" early on before you have the migration hassle\n> we\'re currently \"enjoying\" in Nova :)\n> \n> --Dan\n> \n\nThe summit session was excellent - next step for me is to look through what the right abstraction is going to be for objects that keeps the db details properly isolated and the API surface on /objects suitably coarse (in line with the long discussion in Nova about non-SQL backends, the consensus of which is that the domain object model needs to abstract whole interaction flows, vs granular steps).  I\'ll try to have some example code to debate after I get back from summit.\n\nEven assuming Solum has a fairly small persistence model, in the long run I believe it\'s fair to say that the ability to perform live upgrades will become critical for all operators.  One of the side effects of supporting potentially millions of applications (at the high end, and not an unreasonable estimate for hosted environments) is that any period of downtime at the API level will prevent users from making deployments, which is a direct line-of-business concern.  Designing around live upgrades - specifically, the requirement that code must be aware of two versions of a schema at the same time - implies that the domain model must be able to be aware of those versions on an object basis.  For reference, [1] and [2] contain some of the Nova discussion, and Nova in icehouse is going to be moving this way.  I\'d prefer (it\'s important to Red Hat) to design for that from the beginning and be working towards that end.\n\nDo folks have additional questions or concerns about my exploration of a versioned domain object model from day one?  Are there others who would like to embrace quick and dirty and explicitly ignore this issue until we have a Solum prototype running?  \n\n[1] https://etherpad.openstack.org/p/NovaIcehouseSummitUpgrades\n[2] https://etherpad.openstack.org/p/NovaIcehouseSummitObjects\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1132772258.20363315.1383877567046.JavaMail.root@redhat.com>',NULL),('<1383D603-7913-47AA-8CC5-E7E2AA5F5957@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-10 13:16:10',-25200,'2013-07-10 20:16:10',NULL,'[openstack-dev] How Nova-api should deal with secgroup\n	identifier being UUID in Quantum ?','Personally I think that we shouldn\'t enforce the id. The id should be treated as a unique string and it is just an implementation detail that the nova-network backend uses an integer. We had a number of other resources in nova that were implemented on the backend as integers and later changed to using uuids.\n\nVish\nOn Jul 10, 2013, at 3:12 AM, Jordan Pittier <jpittier at octo.com> wrote:\n\n> Hi,\n> Any ideas on this one ? Maybe I should forward this email to a more specific ML ?\n> \n> \n> On Thu, Jul 4, 2013 at 4:36 PM, Jordan Pittier <jpittier at octo.com> wrote:\n> Hi guys,\n> \n> As you may know :\n> * with Quantum, secgroups are uniquely identified by UUID.\n> * with Nova-Net, secgroups are uniquely identified by numerical ID. \n> \n> At the moment Nova-api, before calling Nova-Net or Quantum,(see nova/api/openstack/compute/contrib/security_group*) performs some calls to validate_id(), defined in :\n> * nova/network/security_group/quantum_drive.py for Quantum\n> * nova/compute/api.py for Nova-Net\n> \n> Validate_id() raises an HTTPBadRequest in case the identifier is not an UUID for Quantum or an ID for Nova-Net.\n> \n> \n> The first thing to notice is that : (1) It\'s Nova-API that performs identifier validation and raises the exception.\n> \n> \n> This API mismatch breaks 4 Tempest tests (see bugs.launchpad.net/tempest/+bug/1182384) and could be confusing to the user as Sean Dague reported in this bug report.\n> \n> I see several approaches to deal with this :\n> 1) This API change can\'t be hidden, clients (and Tempest) must refer to security groups by their specific identifier. Ie Clients must be aware of the backing network implementation. (see review.openstack.org/#/c/29899/)\n> 2) Encapsulate all calls to validate_id() in a try/catch HTTPBadRequest and raise a HTTPNotFound instead (exception translation)\n> 3) Don\'t do any kind of validation neither for Nova-Net not Quantum. Some unit tests in test_quantum_security_groups.TestQuantumSecurityGroups must be adapted/removed. (see review.openstack.org/#/c/35285/ patchset 2 and 4 for 2 different approaches). Let Quantum and Nova-Net deal with malformed inputs.\n> \n> What do you think ? \n> Thanks a lot !\n> Jordan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/c09c6163/attachment.html>\n\n','<CACfnAwZWUYeLodXOKzp3ozLBgGvs47PPKe1X-q0w7qy+ETZanw@mail.gmail.com>',NULL),('<1384004572443.75a96f65@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-09 05:42:53',-28800,'2013-11-09 13:42:53',NULL,'[openstack-dev] No Review button - how to add a comment','Hi Michael,\n\n\n\n\nMy guess would be that you\'re not logged in - look in the top right hand corner. The review button should appear once you have logged in.?\n\n\n\n\nRegards,\n\n\n\n\nChris?\n\n?\nSent from Mailbox for iPhone\n\nOn Sat, Nov 9, 2013 at 9:38 PM, Michael Bright <mjbrightfr at gmail.com>\nwrote:\n\n> OK, so I needed to add a comment to a patch set I proposed\n> https://review.openstack.org/#/c/51263\n> but I don\'t see the \"Review\" button, only a couple of \"Diff\" options.\n> Is there a way I can add comments to the current patch set?\n> Thanks in advance,\n> Mike.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131109/26e8735f/attachment.html>\n\n','<CAMZ8oZ0vQMAVc6ZaV_yJ-TyvLNnFJFWz3RA+_sgnYWEUM+pvmw@mail.gmail.com>',NULL),('<1384043607-sup-920@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-09 16:37:00',-28800,'2013-11-10 00:37:00',NULL,'[Openstack] Heat Template','Hi Daniel, if you are using the latest trunk, you can do this:\n\nresources:\n  yourServer:\n    type: OS::Nova::Server\n    properties:\n      user_data: |\n        Here is the raw data\n      user_data_format: RAW\n\nNote that when using this RAW format, Heat will not configure the server\nfor usage with heat-cfntools. If you want to use the default way, you\ncan just make your user_data script an executable which writes out the\ncontent you want at a local file.\n\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server\n\nExcerpts from Daniel Kuffner\'s message of 2013-11-06 06:14:42 -0800:\n> Hello,\n> \n> Can somebody point me out how I can specify user data in a heat template?\n> I would like consume user data via metadata service.\n> \n> thanks a lot\n> Daniel\n> \n\n\n','<CABf-1jZ4w3HB_xja8VfzSqhtFuB=ZpWHAdzVdB5qi+YD4u+ykw@mail.gmail.com>',NULL),('<1384129009-sup-1698@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-10 16:18:58',-28800,'2013-11-11 00:18:58',NULL,'[openstack-dev] [Solum] Command Line Interface for Solum','Excerpts from Noorul Islam K M\'s message of 2013-11-10 07:15:34 -0800:\n> \n> Hello all,\n> \n> I registered a new blueprint [1] for command line client interface for\n> Solum. We need to decide whether we should have a separate repository\n> for this or go with new unified CLI framework [2]. Since Solum is not\n> part of OpenStack I think it is not the right time to go with the\n> unified CLI.\n> \n\nSolum will not be the last project that will want to eventually be part\nof the openstack unified client, but must get through the governance\nprocess first.\n\nWhat about working out a plugin system for the openstack client? Then\nall of the different clients become a plugin. Projects that are just\nOpenStack related would need to have their plugins installed separately\nbut would work the same whether they\'ve been integrated or are still\njust related (or all the things in-between).\n\n\n','<87habkuw2x.fsf@noman.maa.corp.collab.net>',NULL),('<1384185463.3753.65.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 15:57:43',0,'2013-11-11 15:57:43',NULL,'[openstack-dev] [openstack-tc] Proposal to recognize indirect\n contributions to our code base','Hi Nick,\n\nOn Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n> Dear TC members,\n> \n> Our companies are actively encouraging our respective customers to have the\n> patches they mission us to make be contributed back upstream.  In order to\n> encourage this behavior from them and others, it would be nice that if\n> could gain some visibility as \"sponsors\" of the patches in the same way we\n> get visibility as \"authors\" of the patches today.\n> \n> The goal here is not to provide yet another way to count affiliations of\n> direct contributors, nor is it a way to introduce sales pitches in contrib.\n>  The only acceptable and appropriate use of the proposal we are making is\n> to signal when a patch made by a contributor for another comany than the\n> one he is currently employed by.\n> \n> For example if I work for a company A and write a patch as part of an\n> engagement with company B, I would signal that Company B is the sponsor of\n> my patch this way, not Company A.  Company B would under current\n> circumstances not get any credit for their indirect contribution to our\n> code base, while I think it is our intent to encourage them to contribute,\n> even indirectly.\n> \n> To enable this, we are proposing that the commit text of a patch may\n> include a\n>    sponsored-by: <sponsorname>\n> line which could be used by various tools to report on these commits.\n>  Sponsored-by should not be used to report on the name of the company the\n> contributor is already affiliated to.\n\nHonestly, I\'ve an immediately negative reaction to the prospect of e.g.\n\n  Sponsored-By: Red Hat\n  Sponsored-By: IBM\n\nappearing in our commit messages.\n\nI feel strongly that the project is first and foremost a community of\nindividuals and we instinctively push as much of corporate backing side\nof things outside of the project. We try to spend as little time as\npossible talking about our affiliations as possible.\n\nAnd, IMHO, the git commit log is particularly sacred ground - almost\nabove anything else, it is a place for purely technical details.\n\nHowever, I do think we\'ll be able to figure out some way of making it\neasier for tools to track more complex affiliations.\n\nOur affiliation databases are all keyed off email addresses right now,\nso how about if we allowed for encoding affiliation/sponsorship in\naddresses? e.g.\n\n  Author: Mark McLoughlin <markmc+ibm at redhat.com>\n\nand we could register that address as \"work done by Mark on behalf of\nIBM\" ?\n\nMark.\n\n\n\n','<CAEcpoL-1QfR+2fJXSX8yZ+Xr0PFxGZd=rMFbPxHQiDqwz8r-jw@mail.gmail.com>',NULL),('<1384185463.3753.65.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-11-11 15:57:43',0,'2013-11-11 15:57:43',NULL,'[openstack-tc] Proposal to recognize indirect contributions to\n our code base','Hi Nick,\n\nOn Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n> Dear TC members,\n> \n> Our companies are actively encouraging our respective customers to have the\n> patches they mission us to make be contributed back upstream.  In order to\n> encourage this behavior from them and others, it would be nice that if\n> could gain some visibility as \"sponsors\" of the patches in the same way we\n> get visibility as \"authors\" of the patches today.\n> \n> The goal here is not to provide yet another way to count affiliations of\n> direct contributors, nor is it a way to introduce sales pitches in contrib.\n>  The only acceptable and appropriate use of the proposal we are making is\n> to signal when a patch made by a contributor for another comany than the\n> one he is currently employed by.\n> \n> For example if I work for a company A and write a patch as part of an\n> engagement with company B, I would signal that Company B is the sponsor of\n> my patch this way, not Company A.  Company B would under current\n> circumstances not get any credit for their indirect contribution to our\n> code base, while I think it is our intent to encourage them to contribute,\n> even indirectly.\n> \n> To enable this, we are proposing that the commit text of a patch may\n> include a\n>    sponsored-by: <sponsorname>\n> line which could be used by various tools to report on these commits.\n>  Sponsored-by should not be used to report on the name of the company the\n> contributor is already affiliated to.\n\nHonestly, I\'ve an immediately negative reaction to the prospect of e.g.\n\n  Sponsored-By: Red Hat\n  Sponsored-By: IBM\n\nappearing in our commit messages.\n\nI feel strongly that the project is first and foremost a community of\nindividuals and we instinctively push as much of corporate backing side\nof things outside of the project. We try to spend as little time as\npossible talking about our affiliations as possible.\n\nAnd, IMHO, the git commit log is particularly sacred ground - almost\nabove anything else, it is a place for purely technical details.\n\nHowever, I do think we\'ll be able to figure out some way of making it\neasier for tools to track more complex affiliations.\n\nOur affiliation databases are all keyed off email addresses right now,\nso how about if we allowed for encoding affiliation/sponsorship in\naddresses? e.g.\n\n  Author: Mark McLoughlin <markmc+ibm at redhat.com>\n\nand we could register that address as \"work done by Mark on behalf of\nIBM\" ?\n\nMark.\n\n\n\n','<CAEcpoL-1QfR+2fJXSX8yZ+Xr0PFxGZd=rMFbPxHQiDqwz8r-jw@mail.gmail.com>',NULL),('<1384189725.3753.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 17:08:45',0,'2013-11-11 17:08:45',NULL,'[openstack-dev] [openstack-tc] Proposal to recognize indirect\n contributions to our code base','On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:\n> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:\n> > Hi Nick,\n> > \n> > On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n> >> Dear TC members,\n> >>\n> >> Our companies are actively encouraging our respective customers to have the\n> >> patches they mission us to make be contributed back upstream.  In order to\n> >> encourage this behavior from them and others, it would be nice that if\n> >> could gain some visibility as \"sponsors\" of the patches in the same way we\n> >> get visibility as \"authors\" of the patches today.\n> >>\n> >> The goal here is not to provide yet another way to count affiliations of\n> >> direct contributors, nor is it a way to introduce sales pitches in contrib.\n> >>  The only acceptable and appropriate use of the proposal we are making is\n> >> to signal when a patch made by a contributor for another comany than the\n> >> one he is currently employed by.\n> >>\n> >> For example if I work for a company A and write a patch as part of an\n> >> engagement with company B, I would signal that Company B is the sponsor of\n> >> my patch this way, not Company A.  Company B would under current\n> >> circumstances not get any credit for their indirect contribution to our\n> >> code base, while I think it is our intent to encourage them to contribute,\n> >> even indirectly.\n> >>\n> >> To enable this, we are proposing that the commit text of a patch may\n> >> include a\n> >>    sponsored-by: <sponsorname>\n> >> line which could be used by various tools to report on these commits.\n> >>  Sponsored-by should not be used to report on the name of the company the\n> >> contributor is already affiliated to.\n> > \n> > Honestly, I\'ve an immediately negative reaction to the prospect of e.g.\n> > \n> >   Sponsored-By: Red Hat\n> >   Sponsored-By: IBM\n> > \n> > appearing in our commit messages.\n> > \n> > I feel strongly that the project is first and foremost a community of\n> > individuals and we instinctively push as much of corporate backing side\n> > of things outside of the project. We try to spend as little time as\n> > possible talking about our affiliations as possible.\n> > \n> > And, IMHO, the git commit log is particularly sacred ground - almost\n> > above anything else, it is a place for purely technical details.\n> \n> This was exactly my reaction, as well.  I just hadn\'t been able to come\n> up with a good alternate proposal, yet.\n> \n> > However, I do think we\'ll be able to figure out some way of making it\n> > easier for tools to track more complex affiliations.\n> > \n> > Our affiliation databases are all keyed off email addresses right now,\n> > so how about if we allowed for encoding affiliation/sponsorship in\n> > addresses? e.g.\n> > \n> >   Author: Mark McLoughlin <markmc+ibm at redhat.com>\n> > \n> > and we could register that address as \"work done by Mark on behalf of\n> > IBM\" ?\n> \n> That doesn\'t seem any better to me.  It actually seems more likely to\n> break, since someone could be using an email address with \'+\' in it for\n> some other reason, right?\n\nOh, I\'m not saying we parse the \"ibm\" bit and key off that. Just that we\ncan associate affiliation with email address while still allowing people\nto use the same email address for everything.\n\nA better example - say Robert De Niro works for Nebula but uses his\ngmail address for everything:\n\n  Author: Robert De Niro <taxidriver at gmail.com>\n\nbut if he did some work sponsored by the NSA, he could do:\n\n  Author: Robert De Niro <taxidriver+soldmysoul at gmail.com>\n\nand we\'d have the tracking tools associate the first email address with\nNebula and the second with the NSA.\n\n> I think it may be worth looking at this from a different angle.  Perhaps\n> we should tone down the focus on company metrics, and perhaps remove\n> them completely from anything we control or have influence over.\n\nI\'m down with that. We\'ve definitely jumped the shark on this.\n\nMark.\n\n\n\n','<528108B8.8070007@redhat.com>',NULL),('<1384189725.3753.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-11-11 17:08:45',0,'2013-11-11 17:08:45',NULL,'[openstack-tc] Proposal to recognize indirect contributions to\n our code base','On Mon, 2013-11-11 at 11:41 -0500, Russell Bryant wrote:\n> On 11/11/2013 10:57 AM, Mark McLoughlin wrote:\n> > Hi Nick,\n> > \n> > On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n> >> Dear TC members,\n> >>\n> >> Our companies are actively encouraging our respective customers to have the\n> >> patches they mission us to make be contributed back upstream.  In order to\n> >> encourage this behavior from them and others, it would be nice that if\n> >> could gain some visibility as \"sponsors\" of the patches in the same way we\n> >> get visibility as \"authors\" of the patches today.\n> >>\n> >> The goal here is not to provide yet another way to count affiliations of\n> >> direct contributors, nor is it a way to introduce sales pitches in contrib.\n> >>  The only acceptable and appropriate use of the proposal we are making is\n> >> to signal when a patch made by a contributor for another comany than the\n> >> one he is currently employed by.\n> >>\n> >> For example if I work for a company A and write a patch as part of an\n> >> engagement with company B, I would signal that Company B is the sponsor of\n> >> my patch this way, not Company A.  Company B would under current\n> >> circumstances not get any credit for their indirect contribution to our\n> >> code base, while I think it is our intent to encourage them to contribute,\n> >> even indirectly.\n> >>\n> >> To enable this, we are proposing that the commit text of a patch may\n> >> include a\n> >>    sponsored-by: <sponsorname>\n> >> line which could be used by various tools to report on these commits.\n> >>  Sponsored-by should not be used to report on the name of the company the\n> >> contributor is already affiliated to.\n> > \n> > Honestly, I\'ve an immediately negative reaction to the prospect of e.g.\n> > \n> >   Sponsored-By: Red Hat\n> >   Sponsored-By: IBM\n> > \n> > appearing in our commit messages.\n> > \n> > I feel strongly that the project is first and foremost a community of\n> > individuals and we instinctively push as much of corporate backing side\n> > of things outside of the project. We try to spend as little time as\n> > possible talking about our affiliations as possible.\n> > \n> > And, IMHO, the git commit log is particularly sacred ground - almost\n> > above anything else, it is a place for purely technical details.\n> \n> This was exactly my reaction, as well.  I just hadn\'t been able to come\n> up with a good alternate proposal, yet.\n> \n> > However, I do think we\'ll be able to figure out some way of making it\n> > easier for tools to track more complex affiliations.\n> > \n> > Our affiliation databases are all keyed off email addresses right now,\n> > so how about if we allowed for encoding affiliation/sponsorship in\n> > addresses? e.g.\n> > \n> >   Author: Mark McLoughlin <markmc+ibm at redhat.com>\n> > \n> > and we could register that address as \"work done by Mark on behalf of\n> > IBM\" ?\n> \n> That doesn\'t seem any better to me.  It actually seems more likely to\n> break, since someone could be using an email address with \'+\' in it for\n> some other reason, right?\n\nOh, I\'m not saying we parse the \"ibm\" bit and key off that. Just that we\ncan associate affiliation with email address while still allowing people\nto use the same email address for everything.\n\nA better example - say Robert De Niro works for Nebula but uses his\ngmail address for everything:\n\n  Author: Robert De Niro <taxidriver at gmail.com>\n\nbut if he did some work sponsored by the NSA, he could do:\n\n  Author: Robert De Niro <taxidriver+soldmysoul at gmail.com>\n\nand we\'d have the tracking tools associate the first email address with\nNebula and the second with the NSA.\n\n> I think it may be worth looking at this from a different angle.  Perhaps\n> we should tone down the focus on company metrics, and perhaps remove\n> them completely from anything we control or have influence over.\n\nI\'m down with that. We\'ve definitely jumped the shark on this.\n\nMark.\n\n\n\n','<528108B8.8070007@redhat.com>',NULL),('<1384193658-sup-259@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 10:19:50',-28800,'2013-11-11 18:19:50',NULL,'[openstack-dev] [qa] Policy on spelling and grammar','Excerpts from David Kranz\'s message of 2013-11-11 09:58:59 -0800:\n> I have seen a wide variety of -1\'ing (and in many cases approving) \n> patches for minor spelling or grammatical errors and think we need a \n> policy about this. Given the large number of contributors for whom \n> English is not their native language, I would be in favor of rejecting \n> spelling errors in variable or method names but being more lenient in \n> comments, commit messages, READMEs, etc. What do you all think?\n> \n\nThe point of code review is to find defects. Misspelled words are defects\nin the English language encoded in the change. In fact, commit messages\nin particular are critical to get right as they cannot ever be fixed,\nand they are generally the most useful when under a stressful situation\ntrying to determine the nature of a regression.\n\nMany of our contributors are also newbies to python, and we do not let\nthem get away with obvious mistakes in python code. English is just a\nlanguage with a different interpreter (a more forgiving one, for sure,\nbut also one with many versions at various stages of implementation).\n\nIn fact, our large percentage of non-native english speakers is a reason\nto be extremely careful about grammar and spelling so as not to confuse\nnon-native speakers with incorrect grammar and spelling.\n\nI believe that if a -1 for a spelling mistake is causing more than an\nextremely short turn around time then either the submitter is not engaged\nwith the project and thus not responsive to the -1, or the reviewers\nare over-taxed and the given project needs more reviewers.\n\n\n','<52811AE3.2000605@redhat.com>',NULL),('<1384194100-sup-4710@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-11 10:30:33',-28800,'2013-11-11 18:30:33',NULL,'[Openstack] [Heat] Locked Outputs','Excerpts from Randall Burt\'s message of 2013-11-11 06:45:54 -0800:\n> (sorry for the double-post Steve)\n> \n> I agree with Steve here. Clint\'s suggestion is good, but wouldn\'t it prevent the practical use of that value inside the orchestration itself? Also, how would I use that method for outputs that are generated from attributes? I think we can do something similar to what we do for parameters and allow outputs to be tagged as \"hidden\". That way, those values would be masked for normal stack-show, resource-show, etc. Then we add a new api call to get the unmasked value of an output; something like:\n> \n\nWe don\'t generally use the outputs inside the stack, they are for use\noutside the stack. For nested stacks the key would need to be generated\nand passed in, the same way one would do in the client version. This is\nthe most problematic part of using the encrypted output that I proposed.\n\n> /stacks/{stack_name}/{stack_id}/outputs/{output_key}/value?unmask=true\n> \n> Instead of the query param, we could also simply say that by convention, when the output value is requested this way, its always unmasked).\n> \n\nThat is indeed a nice middle ground. Add to it a policy definition that\nwould allow one to have users that can show stacks and create stacks but\nnot view hidden outputs and this becomes a decent way to contain users\nwhile enabling privileged users.\n\n\n','<507CF8C8-D13F-4702-9643-5016DFBC4430@rackspace.com>',NULL),('<1384195373.96589.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 10:42:53',-28800,'2013-11-11 18:42:53',NULL,'[openstack-dev] [Solum]: Welcome to the community site for\n	Solum !!','Congrats!\n\n\n\nOn Monday, November 11, 2013 11:51 PM, Russell Bryant <rbryant at redhat.com> wrote:\n \nOn 11/11/2013 01:05 PM, Roshan Agrawal wrote:\n>> One nit, instead of linking to github, it would be better to link to OpenStack\'s\n>> git interface since that\'s what we\'re trying to provide as the canonical repo\n>> now.\n>> http://git.openstack.org/cgit/stackforge/solum\n>> Russell Bryant\n> \n> Russell, done. Checkout latest @ solum.io\n\nThanks.\n\nNow that it isn\'t a github link, I don\'t think you can use the octocat\nanymore.\n\nhttps://github.com/logos\n\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131111/975c89c5/attachment.html>\n\n','<52811F5F.9050903@redhat.com>',NULL),('<1384195597.2903.10.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 12:46:37',-21600,'2013-11-11 18:46:37',NULL,'[openstack-dev] Shall backward compatibility env. vars be\n removed from python-clients?','On Sat, 2013-11-09 at 14:14 +0800, Sam Morrison wrote:\n> I think you need to do option 2 and print deprecation warnings, then the question becomes for how long.\n> \n> I think there is a policy for this and that it is deprecate in N remove in N+1\n> Clients are a bit different so maybe keep it for ~6 months?\n\nThe thing here is, these environment variables have already been\ndeprecated for quite some time.  The question is, have they been\ndeprecated long enough that we\'re clear to drop them entirely?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<069A17FF-555B-47A5-83EF-CA3519AD05E8@gmail.com>',NULL),('<1384196398-sup-4208@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 11:01:57',-28800,'2013-11-11 19:01:57',NULL,'[openstack-dev] Horizon PTL candidacy','Excerpts from Matthias Runge\'s message of 2013-11-11 00:04:52 -0800:\n> On 11/10/2013 11:53 PM, John Dickinson wrote:\n> > A random off-the-top-of-my-head use case would be to subscribe to\n> > events from creating or changing objects in a particular Swift\n> > account or container. This would allow much more efficient listings\n> > in Horizon for active containers (and may also be consumed by other\n> > listeners too).\n> > \n> > --John\n> > \n> \n> yupp.\n> There are many many usecases for this, and we\'d get rid of pulling\n> services for status.\n> \n\nNote that Heat can also make use of this, and a need for such things\ncame up during several session discussions. I forget who said this,\nbut it sums up the problem:\n\n\"Polling sucks\"\n\nI\'d hope that we keep it a public API of some sorts, so that users can\nalso take advantage of it.\n\n\n','<52808FA4.8020608@redhat.com>',NULL),('<1384199797.2903.12.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 13:56:37',-21600,'2013-11-11 19:56:37',NULL,'[openstack-dev] Shall backward compatibility env. vars be\n removed from python-clients?','On Mon, 2013-11-11 at 13:35 -0600, Dean Troyer wrote:\n> Related but different are the now-long-undocumented option names with\n> underscores in them.  I\'ve noticed new undocumented ones get added\n> from time to time alongside the same option with dashes.  ??? \n\nI discourage those when I catch them in novaclient, but I figure if we\ncan remove the NOVA_* environment variables, we can probably also remove\nthose wholesale, and that should effectively discourage the\npattern-matching that causes developers to try to include them in the\nfirst place :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAOJFoEtcFOwr958nt4b3aYrMePxoJ52LfWUtyFrpw_KC++P_jQ@mail.gmail.com>',NULL),('<1384209308.3753.134.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 22:35:08',0,'2013-11-11 22:35:08',NULL,'[openstack-dev] Bad review patterns','On Fri, 2013-11-08 at 09:32 +1300, Robert Collins wrote:\n> On 7 November 2013 13:15, Day, Phil <philip.day at hp.com> wrote:\n> >\n> >\n> \n> >>\n> >> Core reviewers look for the /comments/ from people, not just the votes. A\n> >> +1 from someone that isn\'t core is meaningless unless they are known to be\n> >> a thoughtful code reviewer. A -1 with no comment is also bad, because it\n> >> doesn\'t help the reviewee get whatever the issue is fixed.\n> >>\n> >> It\'s very much not OK to spend an hour reviewing something and then +1\n> >> with no comment: if I, and I think any +2er across the project see a patch that\n> >> needs an hour of review, with a commentless +1, we\'ll likely discount the +1\n> >> as being meaningful.\n> >>\n> >\n> > I don\'t really get what you\'re saying here Rob.   It seems to me an almost inevitable\n> > part of the review process that useful comments are going to be mostly negative.\n> > If someone has invested that amount of effort because the patch is complex, or\n> > It took then a while to work their way back into that part of the systems, etc, but\n> > having given the code careful consideration they decide it\'s good - do you want\n> > comments in there saying \"I really like your code\", \"Well done on fixing such a\n> > complex problem\" or some such ?\n> \n> Negative comments are fine: I was saying that statistically, having an\n> hour-long patch (which BTW puts it waaay past the diminishing returns\n> on patch size tradeoff) to review and then having nothing at all to\n> say about it is super suspect. Sure, having nothing to say on a 10\n> line patch - hit a +1, move on. But something that takes an hour to\n> review? I\'d expect at minimum the thing to prompt some suggestions\n> *even while it gets a +1*.\n> \n> > I just don\'t see how you can use a lack or presence of positive feedback in a +1 as\n> > any sort of indication on the quality of that +1.   Unless you start asking reviewers\n> > to pr?cis the change in their own words to show that they understood it I don\'t\n> > really see how additional positive comments help in most cases.   Perhaps if you\n> > have some specific examples of this it would help to clarify\n> \n> It might even be negative feedback. Like - \"this patch is correct but\n> the fact it had to be done as one patch shows our code structure here\n> is wonky. If you could follow up with something to let us avoid future\n> mammoth patches, that would be awesome.\"\n> \n> Again, I\'m talking about hour long reviews, which is the example Radomir gave.\n> \n> Another way of presenting what I\'m saying is this: Code reviews are a\n> dialogue. How often in a discussion with a live human would you have\n> no feedback at all, if they were reading a speech to you. You might go\n> \'that was a great speech\' (+2) and *still* have something to add. As\n> an observer given a very long speech, and an audience, I\'d suspect\n> folk went to sleep if they didn\'t have commentary :)\n\nTotally agree with you here. I almost completely discount +1s with no\ncomments on a large patch.\n\nI make a habit of leaving comments in reviews - positive, negative,\nneutral, whatever. If I have something to say which might be useful to\nthe author, other reviewers, my future self, whatever ... then I\'ll say\nit.\n\ne.g. if I spend 10 minutes looking at one part of a patch, ultimately\nconvincing myself that there really is no better approach and the author\nhas made the right tradeoffs ... then I\'ll say it. I\'ll briefly describe\nthe tradeoffs, the other options that I guess the author considered and\ndiscounted.\n\nI sometimes feel guilty about this because I know patch authors just\nwant their +2 and often don\'t want to read through my verbiage ... but,\nas you say, this is a dialogue and the dialogue can yield some\ninteresting thoughts and ideas.\n\nMark.\n\n\n\n','<CAJ3HoZ2GKS1pCMQs8MnyJRUPgB28oArPAdVj-raKmxSumwVY9w@mail.gmail.com>',NULL),('<1384209779.3753.138.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 22:42:59',0,'2013-11-11 22:42:59',NULL,'[openstack-dev] Bad review patterns','On Thu, 2013-11-07 at 20:40 -0500, David Ripton wrote:\n> On 11/07/2013 07:54 PM, Sean Dague wrote:\n> > On 11/08/2013 01:37 AM, Pedro Roque Marques wrote:\n> >> Radomir,\n> >> An extra issue that i don\'t believe you\'ve covered so far is about comment ownership. I\'ve just read an email on the list that follows a pattern that i\'ve heard many complaints about:\n> >> 	-1 with a reasonable comment, submitter addresses the comment, reviewer never comes back.\n> >>\n> >> Reviewers do need to allocate time to come back and follow up on the answers to their comments.\n> >>\n> >> Perhaps there is an issue with the incentive system. You can earn karma by doing a code review... certainly you want to incentivise developers that help the project by improving the code quality. But if the incentive system allows for \"drive by shooting\" code reviews that can be a problem.\n> >\n> > It\'s not really an incentive system problem, this is some place where\n> > there are some gerrit limitations (especially when your list of reviewed\n> > code is long). Hopefully once we get a gerrit upgrade we can dashboard\n> > out some new items like that via the new rest API.\n> >\n> > I agree that reviewers could be doing better. But definitely also\n> > realize that part of this is just that there is *so* much code to review.\n> >\n> > Realize that most core reviewers aren\'t ignoring or failing to come back\n> > on patches intentionally. There is just *so* much of it. I feel guilty\n> > all the time by how big a review queue I have, but I also need a few\n> > hours a day not doing OpenStack (incredible to believe). This is where\n> > non core reviewers can really help in addressing the first couple of\n> > rounds of review to prune and improve the easy stuff.\n> >\n> > We\'re all in this together,\n> \n> Is there a way for Gerrit to only send email when action is required, \n> rather than on any change to any review you\'ve touched?  If Gerrit sent \n> less mail, it would be easier to treat its mails as a critical call to \n> action to re-review.  (There\'s probably a way to use fancy message \n> filtering to accomplish this, but that would only work for people \n> willing/able to set up such filtering.)\n\nI know you\'re discounting filtering here, but FWIW I filter on the email\nbody containing:\n\n  Gerrit-Reviewer: Mark McLoughlin\n\nso that I have all email related to reviews I\'m subscribed to in a\nsingle folder. I try hard to stay on top of this folder to avoid being a\ndrive-by-reviewer.\n\nI group the mails by thread, so I don\'t mind all the email gerrit sends\nout but if e.g. I wanted to only see notifications of new patch sets I\'d\nfilter on:\n\n  Gerrit-MessageType: newpatchset\n\nMark.\n\n\n\n','<527C4105.3090807@redhat.com>',NULL),('<1384211314.3753.148.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 23:08:34',0,'2013-11-11 23:08:34',NULL,'[openstack-dev] [Nova] Configuration validation','Hi Nikola,\n\nOn Mon, 2013-11-11 at 12:44 +0100, Nikola ?ipanov wrote:\n> Hey all,\n> \n> During the summit session on the the VMWare driver roadmap, a topic of\n> validating the passed configuration prior to starting services came up\n> (see [1] for more detail on how it\'s connected to that specific topic).\n> \n> Several ideas were thrown around during the session mostly documented in\n> [1].\n> \n> There are a few more cases when something like this could be useful (see\n> bug [2] and related patch [3]), and I was wondering if a slightly\n> different approach might be useful. For example use an already existing\n> validation hook in the service class [4] to call into a validation\n> framework that will potentially stop the service with proper\n> logging/notifications. The obvious benefit would be that there is no\n> pre-run required from the user, and the danger of running a\n> misconfigured stack is smaller.\n\nOne thing worth trying would be to encode the validation rules in the\nconfig option declaration.\n\nSome rules could be straightforward, like:\n\nopts = [\n  StrOpt(\'foo_url\',\n         validate_rule=cfg.MatchesRegexp(\'(git|http)://\')),\n]\n\nbut the rule you describe is more complex e.g.\n\ndef validate_proxy_url(conf, group, key, value):\n    if not conf.vnc_enabled:\n        return\n    if conf.ssl_only and value.startswith(\"http://\"):\n        raise ValueError(\'ssl_only option detected, but ...\')\n\nopts = [\n  StrOpt(\'novncproxy_base_url\',\n         validate_rule=validate_proxy_url),\n  ...\n]\n\nI\'m not sure I love this yet, but it\'s worth experimenting with.\n\nMark.\n\n\n\n','<5280C332.9090506@redhat.com>',NULL),('<1384211889.3753.153.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 23:18:09',0,'2013-11-11 23:18:09',NULL,'[openstack-dev] [nova] Do we have some guidelines for mock, stub,\n mox when writing unit test?','On Mon, 2013-11-11 at 12:07 +0000, John Garbutt wrote:\n> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)\n> <andrea.rosa at hp.com> wrote:\n> > Hi\n> >\n> >>Generally mock is supposed to be used over mox now for python 3 support.\n> >\n> > That is my understanding too\n> \n> +1\n> \n> But I don\'t think we should waste all our time re-writing all our mox\n> and stub tests. Lets just leave this to happen organically for now as\n> we add and refactor tests. We probably need to take the hit at some\n> point, but that doesn\'t feel like we should do that right now.\n\nHmm, I don\'t follow this stance.\n\nAdding Python3 support is a goal we all share.\n\nIf we\'re saying that the use of mox stands in the way of that goal, but\nthat we\'d really prefer if people didn\'t work on porting tests from mox\nto mock yet ... then are we saying we don\'t value people working on\nporting to Python3?\n\nAnd if we plan to use a Python3 compatible version of mox[1], then isn\'t\nthe Python3 argument irrelevant and saying \"use mock for new tests\" just\nmeans we\'ll end up with a mixture of mox and mock?\n\nThanks,\nMark.\n\n[1] - https://github.com/emonty/pymox\n\n\n\n','<CABib2_oQcWL1YbPTgPZTO18Fz-S1mWgb9_2=8U9UmatLvQ3u4w@mail.gmail.com>',NULL),('<1384220932-sup-8795@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 19:59:10',-28800,'2013-11-12 03:59:10',NULL,'[openstack-dev] [qa] Policy on spelling and grammar','Excerpts from Tim Bell\'s message of 2013-11-11 11:28:46 -0800:\n> \n> As a speaker of the Queen\'s English, I find flavor to be incorrect. Does that mean I can -1 any patch that does not use flavour ?\n> \n\nPEP8 states that \"English\" should be used. In \"English\" either spelling\nis correct because no localization is actually specified. If we said UK\nEnglish I\'d add u\'s to flavor and color. But we do not, so the words\njust have alternate spellings. We should consider fixing that and being\nclear that we use one or the other, but as it is now, I think one should\nleave these spelling quirks alone.\n\n> At CERN, we are working with 130 countries in a single community. The value of the contribution of non-english speakers far exceeds the occasional misunderstandings.\n> \n> Giving grammar/spellings -1 excludes major sections of the community from contribution.\n> \n\nI think there is a tactful and helpful way for a native english speaker\nto correct a non-native speaker in code review. I don\'t see how\ncorrecting things \"excludes\" the submitter. Quite the contrary, it is up\nfront and honest, which should build trust. If only half of the native\nspeakers -1 for spelling and grammar it will only create confusion.\n\n> As our aim is meritocracy (in python, computer architecture and design rather than spelling), I\'d propose\n> \n> - If someone identifies a need for clarification/correction as part of a review, they also submit the replacement text rather than just -1.\n> - The submitter incorporates that change into a patch\n> \n\nAgreed that it is a good idea to be very clear and make specific\ncorrections. This is different from more complex issues where it is more\nappropriate, usually, to make problem statements and let the submitter\nlearn from that.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9817D8A@CERNXCHG02.cern.ch>',NULL),('<1384228903-sup-900@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-11 20:12:34',-28800,'2013-11-12 04:12:34',NULL,'[openstack-dev] [qa] Policy on spelling and grammar','Excerpts from Sean Dague\'s message of 2013-11-11 14:19:41 -0800:\n> On 11/11/2013 02:28 PM, Tim Bell wrote:\n> > \n> > As a speaker of the Queen\'s English, I find flavor to be incorrect. Does that mean I can -1 any patch that does not use flavour ?\n> > \n> > At CERN, we are working with 130 countries in a single community. The value of the contribution of non-english speakers far exceeds the occasional misunderstandings.\n> > \n> > Giving grammar/spellings -1 excludes major sections of the community from contribution.\n> > \n> > As our aim is meritocracy (in python, computer architecture and design rather than spelling), I\'d propose\n> > \n> > - If someone identifies a need for clarification/correction as part of a review, they also submit the replacement text rather than just -1.\n> > - The submitter incorporates that change into a patch\n> \n> Agreed. If anyone -1s a patch for English, it better have a complete\n> word for word set of replacement text as part of that review.\n> \n> Also, grammar eventually becomes the eye of the beholder, and personal\n> preference, and regional difference, and style, and.... there are a lot\n> of variables here. The heated debate over whether or not a period ends a\n> commit subject shows how gray that is (I honestly only hold firm to\n> keeping that no-period rule in hacking so people would stop -1ing over\n> it, because there were actually opposing -1 wars over adding / removing\n> that period).\n> \n\nThe period argument is over and I think it exposed that we rely on the\nautomation for teaching as much as we do for gating.\n\nIf there are opposing positions on grammar I think that is no different\nthan whether to use a list comprehension or not. Other reviewers should\nweigh in and the votes should dictate what passes through review.\nDisagreement is o-k, and I don\'t think it is a bad idea to disagree even\non grammar, as ultimately it will make more information available to other\nsubmitters and reviewers which should help homogenize the development\ncommunity around the path of least resistance.\n\n> So unless it\'s actually getting in the way of the contribution being\n> understood in the future, I\'d much rather people leave \'0\' scored\n> comments with the grammar / spelling micro-nits.\n> \n\nI assert that it gets in the way of contributions being understood in\nthe future. Even for a native speaker, a spelling mistake can interrupt\ncognitive flow, and grammar problems often lead to ambiguity that is not\nobvious until context changes in other parts of the text.\n\n> There is a real reason for that, many of us with a lot of reviews\n> completely purge anything with a -1. If you score things with a \'0\'\n> review, core reviewers will still look at the code. But I\'d hate to have\n> this giant gauntlet of grammar before the code is getting looked at by\n> +2ers. That seems a pretty high discouragement to new non native English\n> speakers.\n\nThis is a separate issue which I believe we need to change in our\nculture. We are letting the preference of any single gerrit user dictate\nwho will see a review.\n\nIf there are too many reviews to also be able to click through\nand investigate -1\'s, this still just tells me that we are short on\nreviewers. I revisit the -1\'s in all the projects I watch. It is one way\nthat I \"review the reviewers\". A few times I have reversed some minority\n-1 positions with my +2, and then I notice it gets attention immediately\nfrom other reviewers and gets approved. It should not be invisible,\nit should just be another review.\n\n\n','<528157FD.7040309@dague.net>',NULL),('<1384248455-sup-3439@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 01:28:54',-28800,'2013-11-12 09:28:54',NULL,'[openstack-dev] [qa] Policy on spelling and grammar','Excerpts from Radomir Dopieralski\'s message of 2013-11-12 00:53:40 -0800:\n> On 11/11/13 20:47, Christopher Armstrong wrote:\n> [...]\n> > It would be so much nicer if there were some easy way for the reviewer\n> > himself to fix the typos directly (in a way that can trivially be\n> > accepted by the submitter of the patch into his own patch -- with a\n> > click of a button).\n> \n> Well, you can do it with one copy-paste, edit and command. But then it\n> has to be approved by one more person, so it doesn\'t necessarily make it\n> much faster.\n> \n\nIn TripleO we specifically allowed an exception for a reviewer to\nsubmit a fixup to a patch and then the original author to review the\npatch. So in that case, it does speed things up.\n\n\n','<5281EC94.1030403@sheep.art.pl>',NULL),('<1384278011-sup-8869@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 10:32:50',-28800,'2013-11-12 18:32:50',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Thomas Spatzier\'s message of 2013-11-11 08:57:58 -0800:\n> \n> Hi all,\n> \n> I have just posted the following wiki page to reflect a refined proposal\n> for HOT software configuration based on discussions at the design summit\n> last week. Angus also put a sample up in an etherpad last week, but we did\n> not have enough time to go thru it in the design session. My write-up is\n> based on Angus\' sample, actually a refinement, and on discussions we had in\n> breaks, plus it is trying to reflect all the good input from ML discussions\n> and Steve Baker\'s initial proposal.\n> \n> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP\n> \n> Please review and provide feedback.\n\nHi Thomas, thanks for spelling this out clearly.\n\nI am still -1 on anything that specifies the place a configuration is\nhosted inside the configuration definition itself. Because configurations\nare encapsulated by servers, it makes more sense to me that the servers\n(or server groups) would specify their configurations. If changing to a\nmore logical model is just too hard for TOSCA to adapt to, then I suggest\nthis be an area that TOSCA differs from Heat. We don\'t need two models\nfor communicating configurations to servers, and I\'d prefer Heat stay\nfocused on making HOT template authors\' and users\' lives better.\n\nI have seen an alternative approach which separates a configuration\ndefinition from a configuration deployer. This at least makes it clear\nthat the configuration is a part of a server. In pseudo-HOT:\n\nresources:\n  WebConfig:\n    type: OS::Heat::ChefCookbook\n    properties:\n      cookbook_url: https://some.test/foo\n      parameters:\n        endpoint_host:\n          type: string\n  WebServer:\n    type: OS::Nova::Server\n    properties:\n      image: webserver\n      flavor: 100\n  DeployWebConfig:\n    type: OS::Heat::ConfigDeployer\n    properties:\n      configuration: {get_resource: WebConfig}\n      on_server: {get_resource: WebServer}\n      parameters:\n        endpoint_host: {get_attribute: [ WebServer, first_ip]}\n\nI have implementation questions about both of these approaches though,\nas it appears they\'d have to reach backward in the graph to insert\ntheir configuration, or have a generic bucket for all configuration\nto be inserted. IMO that would look a lot like the method I proposed,\nwhich was to just have a list of components attached directly to the\nserver like this:\n\ncomponents:\n  WebConfig:\n    type: Chef::Cookbook\n    properties:\n      cookbook_url: https://some.test/foo\n      parameters:\n        endpoing_host:\n          type: string\nresources:\n  WebServer:\n    type: OS::Nova::Server\n    properties:\n      image: webserver\n      flavor: 100\n    components:\n      - webconfig:\n        component: {get_component: WebConfig}\n        parameters:\n          endpoint_host: {get_attribute: [ WebServer, first_ip ]}\n\nOf course, the keen eye will see the circular dependency there with the\nWebServer trying to know its own IP. We\'ve identified quite a few use\ncases for self-referencing attributes, so that is a separate problem we\nshould solve independent of the template composition problem.\n\nAnyway, I prefer the idea that parse-time things are called components\nand run-time things are resources. I don\'t need a database entry for\n\"WebConfig\" above. It is in the template and entirely static, just\nsitting there as a reusable chunk for servers to pull in as-needed.\n\nAnyway, I don\'t feel that we resolved any of these issues in the session\nabout configuration at the summit. If we did, we did not record them\nin the etherpad or the blueprint. We barely got through the prepared\nlist of requirements and only were able to spell out problems, not\nany solutions. So forgive me if I missed something and want to keep on\ndiscussing this.\n\n\n','<OF3DD9F04D.D2C47B25-ONC1257C20.005CB9DD-C1257C20.005D32E9@de.ibm.com>',NULL),('<1384281288-sup-5589@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 10:36:31',-28800,'2013-11-12 18:36:31',NULL,'[openstack-dev] [qa] moratorium on new negative tests in Tempest','Excerpts from Sean Dague\'s message of 2013-11-12 10:01:06 -0800:\n> During the freeze phase of Havana we got a ton of new contributors\n> coming on board to Tempest, which was super cool. However it meant we\n> had this new influx of negative tests (i.e. tests which push invalid\n> parameters looking for error codes) which made us realize that human\n> creation and review of negative tests really doesn\'t scale. David Kranz\n> is working on a generative model for this now.\n> \n\nAre there some notes or other source material we can follow to understand\nthis line of thinking? I don\'t agree or disagree with it, as I don\'t\nreally understand, so it would be helpful to have the problems enumerated\nand the solution hypothesis stated. Thanks!\n\n\n','<52826CE2.3090309@dague.net>',NULL),('<1384284195-sup-2633@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 11:24:00',-28800,'2013-11-12 19:24:00',NULL,'[openstack-dev] [nova] [heat] Custom Flavor creation through\n	Heat','Excerpts from Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo)\'s message of 2013-11-12 09:25:19 -0800:\n> Hi,\n> \n> In Telecom Cloud applications, the requirements for every application are different. One application might need 10 CPUs, 10GB RAM and no disk. Another application might need 1 CPU, 512MB RAM and 100GB Disk. This varied requirements directly affects the flavors which need to be created for different applications (virtual instances). Customer has his own custom requirements for CPU, RAM and other hardware requirements. So, based on the requests from the customers, we believe that the flavor creation should be done along with the instance creation, just before the instance is created. Most of the flavors will be specific to that application and therefore will not be suitable by other instances.\n> \n> The obvious way is to allow users to create flavors and boot customized instances through Heat. As of now, users can launch instances through heat along with predefined nova flavors only. We have made some changes in our setup and tested it. This change allows creation of customized nova flavors using heat templates. We are also using extra-specs in the flavors for use in our private cloud deployment.\n> This gives an option to the user to mention custom requirements for the flavor in the heat template directly along with the instance details. There is one problem in the nova flavor creation using heat templates. Admin privileges are required to create nova flavors. There should be a way to allow a normal user to create flavors.\n> \n> Your comments and suggestions are most welcome on how to handle this problem !!!\n\nSeems like you just need to setup your Nova policy to allow a role to do\nflavor creation:\n\n\"compute_extension:flavormanage\": \"rule:admin_api\",\n\"compute_extension:v3:flavor-manage\": \"rule:admin_api\",\n\nAnd then enhance Heat to make those API calls.\n\n\n','<1A252E4E4F511F4F99C4999A8A7E5F7415C4045B@DEMUMBX011.nsn-intra.net>',NULL),('<1384290615.2372.83.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-11-12 21:10:15',0,'2013-11-12 21:10:15',NULL,'[OpenStack Foundation] OpenStack core and interoperability ->\n Meeting 11/20 in SFO','Hi Rob,\n\nThis just came up in the TC meeting and I volunteered to pass on some\nfeedback that I think we were all agreed on:\n\n  * This discussion is inevitably going to get pretty technical as we \n    start grappling with what will be required and what won\'t be. The \n    TC feels it should have some involvement in that and would like to \n    nominate some of its members to join.\n\n  * It would be great to open these discussions as widely as possible. \n    An all day, in-person meeting in SF, with 8 days warning is \n    particularly difficult for interested people to join in with. The \n    TC favours IRC for meetings, but conference calls could work too.\n\nAlso, it would be great to have a wiki page describing the goal of the\ncommittee, who\'s involved, what the mailing list is, tracking the\noutcomes of meetings, etc.\n\nThanks,\nMark.\n\nOn Mon, 2013-11-11 at 16:53 -0600, Rob_Hirschfeld at Dell.com wrote:\n> Thanks Josh.\n> \n> I thought to add the specific that we know so far.\n> \n> If any can join, we\'re talking about Wed 11/20 at the Piston SFO office.  The meeting will be *all day* but you can attend parts\n> \n> IMHO, this is planning for the kick-off, not the actual kick-off.  However, we need to decide quickly if a by-laws change is needed.  That\'s the primary objective for this meeting.\n> \n> Here\'s a tentative agenda (to be ordered based on availability of Mark Radcliff)\n> \n> Objective:  Determine if a by-laws change is needed & plan for kick-off.\n> \n> Some topics to review:\n> \n> *         Process & Logistics\n> \n> *         Name of committee (Alan was suggesting \"elephant\" as a follow on for \"spider\")\n> \n> *         Should be change the bylaws to be more process (less project) oriented?  If so, how/when?\n> \n> *         Review the principles, make sure the text makes sense\n> \n> *         Identify \"elephants\" in the process that we need to address/avoid/postpone\n> \n> *         Timeline for implementation\n> \n> *         Identify technical gaps (beyond RefStack)\n> \n> *         RefStack review & planning\n> \n> *         Discuss community involvement process\n> \n> \n> From: Joshua McKenty [mailto:joshua at pistoncloud.com]\n> Sent: Monday, November 11, 2013 12:59 PM\n> To: Jeremy Stanley; Hirschfeld, Rob\n> Cc: foundation at lists.openstack.org\n> Subject: Re: [OpenStack Foundation] OpenStack core and interoperability\n> \n> Rob Hirschfeld and I are chairing the newly approved Interoperability Committee, and we have a kickoff meeting next week. I\'m reasonably confident that we\'ll have a preliminary model for FITS certification by the time of the Icehouse Summit.\n> \n> We\'re going to repurpose the existing FITS mailing list for this, so if you want to follow along, you should sign up there.\n> \n> --\n> \n> Joshua McKenty\n> Chief Technology Officer\n> Piston Cloud Computing, Inc.\n> +1 (650) 242-5683\n> +1 (650) 283-6846\n> http://www.pistoncloud.com\n> \n> \"Oh, Westley, we\'ll never survive!\"\n> \"Nonsense. You\'re only saying that because no one ever has.\"\n> \n> On Nov 10, 2013, at 3:03 PM, Jeremy Stanley <fungi at yuggoth.org<mailto:fungi at yuggoth.org>> wrote:\n> \n> \n> On 2013-10-31 18:06:03 -0500 (-0500), Mark Collier wrote:\n> [...]\n> \n> As of January 1st, 2012, your product must pass any Faithful\n> Implementation Test Suite (FITS) defined by the Technical\n> Committee that will be made available on http://www.openstack.org\n> /FITS , to verify that you are implementing a sufficiently\n> current and complete version of the software (and exposing\n> associated APIs) to ensure compatibility and interoperability.\n> [...]\n> \n> \"OpenStack FITS. Coming soon. The OpenStack Faithful Implementation\n> Test Suite will be available in early 2012.\"\n> \n> I guess we\'re a little behind there. Is there any benefit to\n> revising that ETA or do we wait until there\'s a more solid timeline\n> established?\n> --\n> Jeremy Stanley\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n','<8ECF809A9B9C9D4190291BA3E1B55E273AD8348E@AUSX7MCPS301.AMER.DELL.COM>',NULL),('<1384290615.2372.83.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-11-12 21:10:15',0,'2013-11-12 21:10:15',NULL,'[openstack-tc] [OpenStack Foundation] OpenStack core and\n interoperability -> Meeting 11/20 in SFO','Hi Rob,\n\nThis just came up in the TC meeting and I volunteered to pass on some\nfeedback that I think we were all agreed on:\n\n  * This discussion is inevitably going to get pretty technical as we \n    start grappling with what will be required and what won\'t be. The \n    TC feels it should have some involvement in that and would like to \n    nominate some of its members to join.\n\n  * It would be great to open these discussions as widely as possible. \n    An all day, in-person meeting in SF, with 8 days warning is \n    particularly difficult for interested people to join in with. The \n    TC favours IRC for meetings, but conference calls could work too.\n\nAlso, it would be great to have a wiki page describing the goal of the\ncommittee, who\'s involved, what the mailing list is, tracking the\noutcomes of meetings, etc.\n\nThanks,\nMark.\n\nOn Mon, 2013-11-11 at 16:53 -0600, Rob_Hirschfeld at Dell.com wrote:\n> Thanks Josh.\n> \n> I thought to add the specific that we know so far.\n> \n> If any can join, we\'re talking about Wed 11/20 at the Piston SFO office.  The meeting will be *all day* but you can attend parts\n> \n> IMHO, this is planning for the kick-off, not the actual kick-off.  However, we need to decide quickly if a by-laws change is needed.  That\'s the primary objective for this meeting.\n> \n> Here\'s a tentative agenda (to be ordered based on availability of Mark Radcliff)\n> \n> Objective:  Determine if a by-laws change is needed & plan for kick-off.\n> \n> Some topics to review:\n> \n> *         Process & Logistics\n> \n> *         Name of committee (Alan was suggesting \"elephant\" as a follow on for \"spider\")\n> \n> *         Should be change the bylaws to be more process (less project) oriented?  If so, how/when?\n> \n> *         Review the principles, make sure the text makes sense\n> \n> *         Identify \"elephants\" in the process that we need to address/avoid/postpone\n> \n> *         Timeline for implementation\n> \n> *         Identify technical gaps (beyond RefStack)\n> \n> *         RefStack review & planning\n> \n> *         Discuss community involvement process\n> \n> \n> From: Joshua McKenty [mailto:joshua at pistoncloud.com]\n> Sent: Monday, November 11, 2013 12:59 PM\n> To: Jeremy Stanley; Hirschfeld, Rob\n> Cc: foundation at lists.openstack.org\n> Subject: Re: [OpenStack Foundation] OpenStack core and interoperability\n> \n> Rob Hirschfeld and I are chairing the newly approved Interoperability Committee, and we have a kickoff meeting next week. I\'m reasonably confident that we\'ll have a preliminary model for FITS certification by the time of the Icehouse Summit.\n> \n> We\'re going to repurpose the existing FITS mailing list for this, so if you want to follow along, you should sign up there.\n> \n> --\n> \n> Joshua McKenty\n> Chief Technology Officer\n> Piston Cloud Computing, Inc.\n> +1 (650) 242-5683\n> +1 (650) 283-6846\n> http://www.pistoncloud.com\n> \n> \"Oh, Westley, we\'ll never survive!\"\n> \"Nonsense. You\'re only saying that because no one ever has.\"\n> \n> On Nov 10, 2013, at 3:03 PM, Jeremy Stanley <fungi at yuggoth.org<mailto:fungi at yuggoth.org>> wrote:\n> \n> \n> On 2013-10-31 18:06:03 -0500 (-0500), Mark Collier wrote:\n> [...]\n> \n> As of January 1st, 2012, your product must pass any Faithful\n> Implementation Test Suite (FITS) defined by the Technical\n> Committee that will be made available on http://www.openstack.org\n> /FITS , to verify that you are implementing a sufficiently\n> current and complete version of the software (and exposing\n> associated APIs) to ensure compatibility and interoperability.\n> [...]\n> \n> \"OpenStack FITS. Coming soon. The OpenStack Faithful Implementation\n> Test Suite will be available in early 2012.\"\n> \n> I guess we\'re a little behind there. Is there any benefit to\n> revising that ETA or do we wait until there\'s a more solid timeline\n> established?\n> --\n> Jeremy Stanley\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n','<8ECF809A9B9C9D4190291BA3E1B55E273AD8348E@AUSX7MCPS301.AMER.DELL.COM>',NULL),('<1384291448.2372.87.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 21:24:08',0,'2013-11-12 21:24:08',NULL,'[openstack-dev] [nova] Do we have some guidelines for mock, stub,\n mox when writing unit test?','On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:\n> Maybe we should have some 60% rule... that is: If you change more than\n> half of a test... you should *probably* rewrite the test in Mock.\n\nA rule needs a reasoning attached to it :)\n\nWhy do we want people to use mock?\n\nIs it really for Python3? If so, I assume that means we\'ve ruled out the\npython3 port of mox? (Ok by me, but would be good to hear why) And, if\nthat\'s the case, then we should encourage whoever wants to port mox\nbased tests to mock.\n\nOr maybe it has nothing to do with Python3 at all? Maybe we just like\nmock more? But do we like it enough to have a mixture of mock and mox\nacross the codebase?\n\nMark.\n\n> ----- Original Message -----\n> > From: \"John Garbutt\" <john at johngarbutt.com>\n> > To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing List (not for usage questions)\"\n> > <openstack-dev at lists.openstack.org>\n> > Sent: Tuesday, November 12, 2013 9:31:25 AM\n> > Subject: Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?\n> > \n> > On 11 November 2013 23:18, Mark McLoughlin <markmc at redhat.com> wrote:\n> > > On Mon, 2013-11-11 at 12:07 +0000, John Garbutt wrote:\n> > >> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)\n> > >> <andrea.rosa at hp.com> wrote:\n> > >> > Hi\n> > >> >\n> > >> >>Generally mock is supposed to be used over mox now for python 3 support.\n> > >> >\n> > >> > That is my understanding too\n> > >>\n> > >> +1\n> > >>\n> > >> But I don\'t think we should waste all our time re-writing all our mox\n> > >> and stub tests. Lets just leave this to happen organically for now as\n> > >> we add and refactor tests. We probably need to take the hit at some\n> > >> point, but that doesn\'t feel like we should do that right now.\n> > >\n> > > Hmm, I don\'t follow this stance.\n> > >\n> > > Adding Python3 support is a goal we all share.\n> > >\n> > > If we\'re saying that the use of mox stands in the way of that goal, but\n> > > that we\'d really prefer if people didn\'t work on porting tests from mox\n> > > to mock yet ... then are we saying we don\'t value people working on\n> > > porting to Python3?\n> > >\n> > > And if we plan to use a Python3 compatible version of mox[1], then isn\'t\n> > > the Python3 argument irrelevant and saying \"use mock for new tests\" just\n> > > means we\'ll end up with a mixture of mox and mock?\n> > \n> > Good point, I forgot about the port of mox to python3.\n> > \n> > I liked the idea of \"prefer mock\", with a view that at some point in\n> > the future there is only a small amount of mox related code left, that\n> > can easily get moved to mock.\n> > \n> > I guess its a trade off between review capacity, risk of breaking\n> > existing tests, and risk of never reaching that end goal.\n> > \n> > We already have stubs and mox, which do tend to fight each other,\n> > adding a third does seem like a bad plan, unless there is a very good\n> > reason, which I always had in my head as python3 support. Hmm... I do\n> > prefer mock to mox, but not that strongly.\n> > \n> > John\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n\n\n\n\n','<1913011672.12206217.1384290716592.JavaMail.root@vmware.com>',NULL),('<1384292397.2372.90.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 21:39:57',0,'2013-11-12 21:39:57',NULL,'[openstack-dev] Motion - Amend TC charter language to reflect\n Gender Parity','Hi Anita,\n\nOn Tue, 2013-11-12 at 15:50 -0500, Anita Kuno wrote:\n> Currently some of the language found in the TC charter does not yet \n> reflect gender parity[0].\n> \n> I encountered this myself while officiating the TC election, \n> particularly the section on Candidates for PTL seats[1].\n> \n> I move that the language of the TC charter reflect gender parity.\n> \n> \n> [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee\n> [1]Candidates for PTL seats\n> Any APC can propose his candidacy for the corresponding program PTL \n> election. Sitting PTLs are eligible to run for re-election each cycle, \n> provided they continue to meet the criteria.\n\nI think it goes without saying that it makes sense to fix this.\nPersonally, I\'m annoyed I didn\'t notice this before now.\n\nCare to suggest alternate wording and submit it as a patch to our\ngovernance repo?\n\nThis is the canonical TC charter document:\n\n  https://git.openstack.org/cgit/openstack/governance/tree/reference/charter\n\nThanks,\nMark.\n\n\n\n','<528294A8.6020102@anteaya.info>',NULL),('<1384292397.2372.90.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-11-12 21:39:57',0,'2013-11-12 21:39:57',NULL,'[openstack-tc] [openstack-dev] Motion - Amend TC charter\n language to reflect Gender Parity','Hi Anita,\n\nOn Tue, 2013-11-12 at 15:50 -0500, Anita Kuno wrote:\n> Currently some of the language found in the TC charter does not yet \n> reflect gender parity[0].\n> \n> I encountered this myself while officiating the TC election, \n> particularly the section on Candidates for PTL seats[1].\n> \n> I move that the language of the TC charter reflect gender parity.\n> \n> \n> [0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee\n> [1]Candidates for PTL seats\n> Any APC can propose his candidacy for the corresponding program PTL \n> election. Sitting PTLs are eligible to run for re-election each cycle, \n> provided they continue to meet the criteria.\n\nI think it goes without saying that it makes sense to fix this.\nPersonally, I\'m annoyed I didn\'t notice this before now.\n\nCare to suggest alternate wording and submit it as a patch to our\ngovernance repo?\n\nThis is the canonical TC charter document:\n\n  https://git.openstack.org/cgit/openstack/governance/tree/reference/charter\n\nThanks,\nMark.\n\n\n\n','<528294A8.6020102@anteaya.info>',NULL),('<1384292977.2372.92.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 21:49:37',0,'2013-11-12 21:49:37',NULL,'[openstack-dev] [nova] Do we have some guidelines for mock, stub,\n mox when writing unit test?','On Tue, 2013-11-12 at 16:42 -0500, Chuck Short wrote:\n> \n> Hi\n> \n> \n> On Tue, Nov 12, 2013 at 4:24 PM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Tue, 2013-11-12 at 13:11 -0800, Shawn Hartsock wrote:\n>         > Maybe we should have some 60% rule... that is: If you change\n>         more than\n>         > half of a test... you should *probably* rewrite the test in\n>         Mock.\n>         \n>         \n>         A rule needs a reasoning attached to it :)\n>         \n>         Why do we want people to use mock?\n>         \n>         Is it really for Python3? If so, I assume that means we\'ve\n>         ruled out the\n>         python3 port of mox? (Ok by me, but would be good to hear why)\n>         And, if\n>         that\'s the case, then we should encourage whoever wants to\n>         port mox\n>         based tests to mock.\n>         \n> \n> \n> The upstream maintainer is not going to port mox to python3 so we have\n> a fork of mox called mox3. Ideally, we would drop the usage of mox in\n> favour of mock so we don\'t have to carry a forked mox.\n\nIsn\'t that the opposite conclusion you came to here:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-July/012474.html\n\ni.e. using mox3 results in less code churn?\n\nMark.\n\n\n\n\n','<CANZa-e+KK48gFiqCAb1Yy0mVeZxe8NBE5KgG6j3wuo=_uED-eg@mail.gmail.com>',NULL),('<1384300183-sup-9896@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 16:34:34',-28800,'2013-11-13 00:34:34',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Angus Salkeld\'s message of 2013-11-12 15:22:44 -0800:\n> On 12/11/13 10:32 -0800, Clint Byrum wrote:\n> >Excerpts from Thomas Spatzier\'s message of 2013-11-11 08:57:58 -0800:\n> >>\n> >> Hi all,\n> >>\n> >> I have just posted the following wiki page to reflect a refined proposal\n> >> for HOT software configuration based on discussions at the design summit\n> >> last week. Angus also put a sample up in an etherpad last week, but we did\n> >> not have enough time to go thru it in the design session. My write-up is\n> >> based on Angus\' sample, actually a refinement, and on discussions we had in\n> >> breaks, plus it is trying to reflect all the good input from ML discussions\n> >> and Steve Baker\'s initial proposal.\n> >>\n> >> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP\n> >>\n> >> Please review and provide feedback.\n> >\n> >Hi Thomas, thanks for spelling this out clearly.\n> >\n> >I am still -1 on anything that specifies the place a configuration is\n> >hosted inside the configuration definition itself. Because configurations\n> >are encapsulated by servers, it makes more sense to me that the servers\n> >(or server groups) would specify their configurations. If changing to a\n> >more logical model is just too hard for TOSCA to adapt to, then I suggest\n> >this be an area that TOSCA differs from Heat. We don\'t need two models\n> >for communicating configurations to servers, and I\'d prefer Heat stay\n> >focused on making HOT template authors\' and users\' lives better.\n> >\n> >I have seen an alternative approach which separates a configuration\n> >definition from a configuration deployer. This at least makes it clear\n> >that the configuration is a part of a server. In pseudo-HOT:\n> >\n> >resources:\n> >  WebConfig:\n> >    type: OS::Heat::ChefCookbook\n> >    properties:\n> >      cookbook_url: https://some.test/foo\n> >      parameters:\n> >        endpoint_host:\n> >          type: string\n> >  WebServer:\n> >    type: OS::Nova::Server\n> >    properties:\n> >      image: webserver\n> >      flavor: 100\n> >  DeployWebConfig:\n> >    type: OS::Heat::ConfigDeployer\n> >    properties:\n> >      configuration: {get_resource: WebConfig}\n> >      on_server: {get_resource: WebServer}\n> >      parameters:\n> >        endpoint_host: {get_attribute: [ WebServer, first_ip]}\n> \n> \n> This is what Thomas defined, with one optimisation.\n> - The webconfig is a yaml template.\n> \n> As you say the component is static - if so why even put it inline in\n> the template (well that was my thinking, it seems like a template not\n> really a resource).\n> \n\nDoing it in-line or pulled in via some other method, I think making\nthings composable calls for both.\n\n> >\n> >I have implementation questions about both of these approaches though,\n> >as it appears they\'d have to reach backward in the graph to insert\n> >their configuration, or have a generic bucket for all configuration\n> \n> Yeah, it does depend on the implementation. If we use Mistral the\n> agent will need to ask Mistral for the tasks that apply to the server.\n> \n> $ mistral task-consume \\\n>   --tags=instance_id=$(my_instance_id);stack_id=$(stack_id)\n> \n\nActually that makes perfect sense. Thanks. If we have a hidden work-flow\nhandle for any resources that have need of it passed in much the same\nway we pass in the cfn-metadata-server now, that would allow us to write\nour work-flow afterward. The image can decide when it wants to start\ndoing work-flows and can decide to just spin until the work-flow exists\nand is enabled. For the tiny-work-flow case of one task it works the\nsame as the complicated work-flow, so I think this sounds like a\nworkable plan.. assuming a work-flow service. :)\n\n> >to be inserted. IMO that would look a lot like the method I proposed,\n> >which was to just have a list of components attached directly to the\n> >server like this:\n> >\n> >components:\n> >  WebConfig:\n> >    type: Chef::Cookbook\n> >    properties:\n> >      cookbook_url: https://some.test/foo\n> >      parameters:\n> >        endpoing_host:\n> >          type: string\n> >resources:\n> >  WebServer:\n> >    type: OS::Nova::Server\n> >    properties:\n> >      image: webserver\n> >      flavor: 100\n> >    components:\n> >      - webconfig:\n> >        component: {get_component: WebConfig}\n> >        parameters:\n> >          endpoint_host: {get_attribute: [ WebServer, first_ip ]}\n> I\'d change this to:\n> \n>      components:\n>        - webconfig:\n>          component: {get_file: ./my_configs/webconfig.yaml}\n>          parameters:\n>            endpoint_host: {get_attribute: [ WebServer, first_ip ]}\n> \n> This *could* be a short hand notation like the volumes property on\n> aws instances.\n> \n\nThat makes sense.\n\n> >\n> >Of course, the keen eye will see the circular dependency there with the\n> >WebServer trying to know its own IP. We\'ve identified quite a few use\n> >cases for self-referencing attributes, so that is a separate problem we\n> >should solve independent of the template composition problem.\n> \n> (aside) I don\'t like the idea of self ref as it breaks the idea that\n>          references are resolved top down. Basically we have to put in\n>          a nasty hack to produce broken behaviour (first resolution is\n>          bogus and only following resoultions are possibly correct).\n> \n> In this case just use the deployer to break your circular dep?\n>\n\nYes I think I have to just accept that it is easier to reason about a\nsecond resource that gathers all of the configuration. Given a simple\nwork-flow service that allows processing said configuration, I think\nthis will make as much sense as anything else.\n\n> >\n> >Anyway, I prefer the idea that parse-time things are called components\n> >and run-time things are resources. I don\'t need a database entry for\n> >\"WebConfig\" above. It is in the template and entirely static, just\n> >sitting there as a reusable chunk for servers to pull in as-needed.\n> \n> IMO is should just be a template/formatted file.\n> \n\nI\'d prefer that we have the ability to pull in a chunk of in-line template\nas well. Perhaps that is the template resource, I have not thought that\nthrough. It is not o-k, IMO, to push things off entirely to external\nfiles/urls/\"providers\", etc. That is just cumbersome and unnecessary for\na common case which is to deploy two things using the same base config\nwith parameters having different values.\n\nOf course, for my use case of having different topologies reusing bits\nof config, it is perfect to have the reusable bits split into different\nfiles.\n\n\n','<20131112232244.GC6558@redhat.com>',NULL),('<1384310387-sup-6186@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 18:40:56',-28800,'2013-11-13 02:40:56',NULL,'[openstack-dev] [qa] moratorium on new negative tests in Tempest','Excerpts from Clint Byrum\'s message of 2013-11-12 10:36:31 -0800:\n> Excerpts from Sean Dague\'s message of 2013-11-12 10:01:06 -0800:\n> > During the freeze phase of Havana we got a ton of new contributors\n> > coming on board to Tempest, which was super cool. However it meant we\n> > had this new influx of negative tests (i.e. tests which push invalid\n> > parameters looking for error codes) which made us realize that human\n> > creation and review of negative tests really doesn\'t scale. David Kranz\n> > is working on a generative model for this now.\n> > \n> \n> Are there some notes or other source material we can follow to understand\n> this line of thinking? I don\'t agree or disagree with it, as I don\'t\n> really understand, so it would be helpful to have the problems enumerated\n> and the solution hypothesis stated. Thanks!\n\nThanks to all for explaining the motivations fully. I understand now, and\nagree with all of the points made (including how incredibly frustrating\nit is to come up with all of the conceptual ways to get errors back).\n\n\n','<1384281288-sup-5589@clint-HP>',NULL),('<1384310527-sup-3639@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-12 18:46:46',-28800,'2013-11-13 02:46:46',NULL,'[Openstack] [Heat] Locked Outputs','Excerpts from Andrew Plunk\'s message of 2013-11-12 17:24:25 -0800:\n> Thanks for reiterating that Zane. The problem I have is I want to display generated passwords once, and only once in a ui. I want the ability to flag or conditionally display outputs based on conditions. \n> \n\nA problem is stated with a cause and an effect \"Users may lose control of\nthe UI after the first time outputs are displayed, leading to credential\ncompromise\".\n\nAnother example: \"English encourages use of overloaded terms which\ncan be ambiguous, requiring multiple iterations to communicate ideas\neffectively.\"\n\nSolution: \"I want to define terms more clearly before using them in\nsentences.\"\n\n\"I want to ...\" is a _solution_.\n\nMaybe we can try one more time?\n\n\n','<CDEAE34515107A4A92D7B32C0E5DFD4E012F58C7@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1384322487.63060.YahooMailNeo@web121302.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-11-12 22:01:27',-28800,'2013-11-13 06:01:27',NULL,'[Openstack-operators] REg installation of Openstack','\n\nSir\nWe are trying to install openstack Grizzly version following DevStack \ninstallation procedure on Ubuntu 12.0 and Dell R210 servers\n\nAfter installing controller node and when we try to install compute nodes \n\n??? We are not able to communicate between the controller and compute nodes to complete installation setup.\nKindly inform whether the error can be corrected.\nThanking you\nG sudha Sadasivam\nProfessor, CSEPSG College of Technology\n\n\n\nOn Wednesday, November 13, 2013 11:27 AM, sudha sadhasivam <sudhasadhasivam at yahoo.com> wrote:\n \nSir\nWe are trying to install openstack Grizzly version following DevStack installation procedure on Ubuntu 12.0 and Dell R210 servers\n\nAfter installing controller node and when we try to install compute nodes \n\n??? We are not able to communicate between the controller and compute nodes to complete installation setup.\nKindly inform whether the error can be corrected.\nThanking you\nG sudha Sadasivam\nProfessor, CSE\nPSG College of Technology\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20131112/0c6aa3da/attachment.html>\n\n','<1384322256.40712.YahooMailNeo@web121303.mail.ne1.yahoo.com>',NULL),('<1384333088-sup-5809@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 00:59:56',-28800,'2013-11-13 08:59:56',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Thomas Spatzier\'s message of 2013-11-13 00:28:59 -0800:\n> Angus Salkeld <asalkeld at redhat.com> wrote on 13.11.2013 00:22:44:\n> > From: Angus Salkeld <asalkeld at redhat.com>\n> > To: openstack-dev at lists.openstack.org,\n> > Date: 13.11.2013 00:25\n> > Subject: Re: [openstack-dev] [Heat] HOT software configuration\n> > refined after design summit discussions\n> >\n> > On 12/11/13 10:32 -0800, Clint Byrum wrote:\n> > >Excerpts from Thomas Spatzier\'s message of 2013-11-11 08:57:58 -0800:\n> > >>\n> > >> Hi all,\n> > >>\n> > >> I have just posted the following wiki page to reflect a refined\n> proposal\n> > >> for HOT software configuration based on discussions at the design\n> summit\n> > >> last week. Angus also put a sample up in an etherpad last week, but we\n> did\n> > >> not have enough time to go thru it in the design session. My write-up\n> is\n> > >> based on Angus\' sample, actually a refinement, and on discussionswe\n> had in\n> > >> breaks, plus it is trying to reflect all the good input from ML\n> discussions\n> > >> and Steve Baker\'s initial proposal.\n> > >>\n> > >>\n> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP\n> > >>\n> > >> Please review and provide feedback.\n> > >\n> > >Hi Thomas, thanks for spelling this out clearly.\n> > >\n> > >I am still -1 on anything that specifies the place a configuration is\n> > >hosted inside the configuration definition itself. Because\n> configurations\n> > >are encapsulated by servers, it makes more sense to me that the servers\n> > >(or server groups) would specify their configurations. If changing to a\n> > >more logical model is just too hard for TOSCA to adapt to, then I\n> suggest\n> > >this be an area that TOSCA differs from Heat. We don\'t need two models\n> > >for communicating configurations to servers, and I\'d prefer Heat stay\n> > >focused on making HOT template authors\' and users\' lives better.\n> > >\n> > >I have seen an alternative approach which separates a configuration\n> > >definition from a configuration deployer. This at least makes it clear\n> > >that the configuration is a part of a server. In pseudo-HOT:\n> > >\n> > >resources:\n> > >  WebConfig:\n> > >    type: OS::Heat::ChefCookbook\n> > >    properties:\n> > >      cookbook_url: https://some.test/foo\n> > >      parameters:\n> > >        endpoint_host:\n> > >          type: string\n> > >  WebServer:\n> > >    type: OS::Nova::Server\n> > >    properties:\n> > >      image: webserver\n> > >      flavor: 100\n> > >  DeployWebConfig:\n> > >    type: OS::Heat::ConfigDeployer\n> > >    properties:\n> > >      configuration: {get_resource: WebConfig}\n> > >      on_server: {get_resource: WebServer}\n> > >      parameters:\n> > >        endpoint_host: {get_attribute: [ WebServer, first_ip]}\n> >\n> >\n> > This is what Thomas defined, with one optimisation.\n> > - The webconfig is a yaml template.\n> >\n> > As you say the component is static - if so why even put it inline in\n> > the template (well that was my thinking, it seems like a template not\n> > really a resource).\n> \n> Yes, exactly. Our idea was to put it in its own file since it is really\n> static and having it in its own file makes it much more reusable.\n> With \'WebConfig\' defined inline in the template as in the snippet above,\n> you will have to update many template files where you use the component,\n> whereas you will only have to touch one place when it is in its own file.\n> Ok, the example above looks simple, but in reality we will see more complex\n> sets of parameters etc.\n> Maybe for very simple use cases, we can allow a shortcut of inlining it in\n> the template (I mentioned this in the wiki) and avoid the need for a\n> separate file.\n> \n\nI think I understand now, and we\'re all basically on the same page. As\nusual, I was confused by the subtleties.\n\nI think the in-line capability is critical to have in the near-term\nplan, but would +2 an implementation that left it out at the beginning.\n\nBefore we \"ratify\" this and people run off and write code, I\'d like to\npresent my \"problems\" in TripleO and try to see if I can express them\nusing the spec you\'ve laid out. Will try and do that in the next couple\nof days.\n\n\n','<OFF721AFC1.A4A43219-ONC1257C22.002E4E5B-C1257C22.002E998D@de.ibm.com>',NULL),('<1384368517.145828871@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 12:48:37',-21600,'2013-11-13 18:48:37',NULL,'[openstack-dev] [Solum] Some initial code copying for\n	db/migration','+1 for ease of iteration till we decide on the model \n(and so not worry about remotability right now :)).\n\nJust to verify that I understand the proposed strawman commit,\nit will use nova/object/* like hierarchy to define Solum specific domain objects\nin which specific methods would be exposed whose implementation will use \nsqlalchemy ORM calls internally.\n\nSounds good to me.\n\nAs long as we are able to discuss and debate the perceived advantages of the object approach\n(that it makes handling versioned data easier, and that it allows using sql and non-sql\n backends) we should be good.\n\nBtw, thanks for sending across link to the F1 paper.\n\nRegards,\n- Devdatta\n\n\n-----Original Message-----\nFrom: \"Clayton Coleman\" <ccoleman at redhat.com>\nSent: Wednesday, November 13, 2013 12:29pm\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nCc: \"devdatta kulkarni\" <devdatta.kulkarni at rackspace.com>\nSubject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration\n\n----- Original Message -----\n> \n> The abstraction will probably always leak something, but in general it comes\n> down to isolating a full transaction behind a coarse method.  Was going to\n> try to demonstrate that as I went.\n> \n\nI\'ve almost got something ready for feedback and review - before I do that I wanted to follow up with remotability and it\'s relative importance:\n\nIs remotability of DB interactions a prime requirement for all OpenStack services? Judging by what I\'ve seen so far, it\'s primarily to ensure that DB passwords are isolated from the API code, with a tiny amount of being able to scale business logic independently.  Are there other reasons?\n\nFor DB password separation, it\'s never been a huge concern to us operationally - do others have strong enough opinions either way to say that it continues to be important vs. not?\n\nFor the separated scale behavior, at the control plane scale outs we suspect we\'ll have (2-20?), does separating the api and a background layer provide benefit?\n   \nThe other items that have been mentioned that loosely couple with remotability are versioned upgrades, but we can solve those in a combined layer as well with an appropriately chosen API abstraction.  \n\nIf remotability of DB calls is not a short term or medium term objective, then I was going to put together a strawman commit that binds domain object implementation subclasses that are tied to sqlalchemy ORM, but with the granular create/save/update calls called out and enforced.  If it is a short/medium objective, we\'d use the object field list to copy from the ORM, with the duplicate object creation that it entails.  The former is easier to iterate on as we develop to decide on the model, the latter is easier to make remoteable (can\'t have the SQL orm state inside the object that is being serialized easily).  There\'s an argument the latter enforces stronger code guarantees as well (there\'s no way for people to use tricky orm magic methods added to the object, although that\'s a bit less of an issue with sqlalchemy than other models).\n\nThoughts?\n\n\n\n\n','<206905471.22823954.1384367352663.JavaMail.root@redhat.com>',NULL),('<1384371265.27772.YahooMailNeo@web141203.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 11:34:25',-28800,'2013-11-13 19:34:25',NULL,'[openstack-dev]  [Nova][Baremetal]: pxe image on hard disk','\n\nUsing baremetal provisioning, I was able to provision a physical server with an image. However, after I disconnected the server from openstack cluster and tried to boot the physical server with hard disk, it could not find the image. Is there a way to persist the pxe image on to the hard disk so that it could be used later by the server to boot from its hard disk?\nThanks,\n-vj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131113/14de8c47/attachment.html>\n\n',NULL,NULL),('<1384377387.8703.17.camel@seamus.fc.hp.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 21:16:28',0,'2013-11-13 21:16:28',NULL,'[openstack-dev] Proposal to recognize indirect contributions to\n our code base','On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n\n> To enable this, we are proposing that the commit text of a patch may\n> include a \n>    sponsored-by: <sponsorname>\n> line which could be used by various tools to report on these commits.\n>  Sponsored-by should not be used to report on the name of the company\n> the contributor is already affiliated to.\n> \n> We would appreciate to see your comments on the subject and eventually\n> get your approval for it\'s use.\n\nRather than including this sponsor information directly in commit logs,\nthe metrics tools could attribute specific changesets to a different\norganization.  This would override the normal attribution that the\nmetrics tools would otherwise make based solely on the committer\'s own\naffiliation.\n\ngitdm already special-cases some commits. For example, we do this to\ncompletely omit changesets that should not be counted towards\ncontribution metrics, such as automated commits from Jenkins or\ntranslations [1].   Stackalytics has a similar mechanism [2], and\nactivity.openstack.org (metrics-grimoire) may also provide similar\nfunctionality.\n\nThis approach moves the recognition completely out of band from the git\ncommit, and closer to where (presumably) it will be recognized by the\ncommunity and the sponsor.  Yet it would allows special attributions to\nbe transparently documented and maintained by, and within, the\ncommunity.\n\nDan\n\n[1]\nhttps://github.com/openstack-infra/gitdm/blob/master/openstack-config/grizzly - the list of commit IDs in parentheses are omitted from metrics totals\n[2]\nhttps://github.com/stackforge/stackalytics/blob/master/etc/corrections.json - stackalytics provides for finer-grained \"corrections\" to specific changesets.\n\n','<CAEcpoL-1QfR+2fJXSX8yZ+Xr0PFxGZd=rMFbPxHQiDqwz8r-jw@mail.gmail.com>',NULL),('<1384385059.5673.20.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 00:24:19',3600,'2013-11-13 23:24:19',NULL,'[openstack-dev] Proposal to recognize indirect contributions to\n our code base','On Wed, 2013-11-13 at 21:16 +0000, Stangel, Dan wrote:\n> On Mon, 2013-11-11 at 15:20 +0100, Nicolas Barcet wrote:\n> \n> > To enable this, we are proposing that the commit text of a patch may\n> > include a \n> >    sponsored-by: <sponsorname>\n> > line which could be used by various tools to report on these commits.\n> >  Sponsored-by should not be used to report on the name of the company\n> > the contributor is already affiliated to.\n> > \n> > We would appreciate to see your comments on the subject and eventually\n> > get your approval for it\'s use.\n> \n> Rather than including this sponsor information directly in commit logs,\n> the metrics tools could attribute specific changesets to a different\n> organization.  This would override the normal attribution that the\n> metrics tools would otherwise make based solely on the committer\'s own\n> affiliation.\n> \n> gitdm already special-cases some commits. For example, we do this to\n> completely omit changesets that should not be counted towards\n> contribution metrics, such as automated commits from Jenkins or\n> translations [1].   Stackalytics has a similar mechanism [2], and\n> activity.openstack.org (metrics-grimoire) may also provide similar\n> functionality.\n> \n> This approach moves the recognition completely out of band from the git\n> commit, and closer to where (presumably) it will be recognized by the\n> community and the sponsor.  Yet it would allows special attributions to\n> be transparently documented and maintained by, and within, the\n> community.\n\nI find this approach quite doable. On the one hand, any developer not\ninterested would not need to do anything about all this, and will not\neven find that information by reading commit logs or other\ndeveloper-oriented information. On the other, those interested will\nupdate that out-of-band information according to their interests. Anyone\ninterested in knowing about all of this, will be able of finding, and\nchecking, the relevant information.\n\nThe only thing would be to define a format for specifying how a certain\nchangeset is attributed to a certain organization. Probably we need to\nconsider at least two cases:\n\n- Commits by a certain developer, during a certain period.\n\n- Specific commits.\n\nA format could be something like:\n\nAttribution:Commit-period:Developer:start_date:end_date\nAttribution:Single-commit:commit_hash\n\nAttribution would be the name of the organization being \"attributed\".\n\nA file managed with the usual code review process could include all this\ninformation.\n\nThose commits not matched by this file would be attributed \"as usual\".\n\nWell, just my two eurocents...\n\nSaludos,\n\n	Jesus.\n\n> Dan\n> \n> [1]\n> https://github.com/openstack-infra/gitdm/blob/master/openstack-config/grizzly - the list of commit IDs in parentheses are omitted from metrics totals\n> [2]\n> https://github.com/stackforge/stackalytics/blob/master/etc/corrections.json - stackalytics provides for finer-grained \"corrections\" to specific changesets.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<1384377387.8703.17.camel@seamus.fc.hp.com>',NULL),('<1384392237-sup-9647@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 19:26:17',-28800,'2013-11-14 03:26:17',NULL,'[openstack-dev] [ALL] Removing generate_uuid() from uuidutils','Excerpts from Michael Still\'s message of 2013-11-13 13:24:52 -0800:\n> On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch <eric at cloudscaling.com> wrote:\n> \n> > I don\'t think it is a problem to remove the code in oslo first, as\n> > long as no other oslo-incubator code uses it. Projects don\'t have to\n> > sync the code and could always revert should that they do.\n> \n> I strongly disagree. It stops projects from syncing with oslo until\n> they go through the code churn to remove the method.\n> \n> > However, like Mark, I\'m inclined to consider the value of\n> > is_uuid_like. While undoubtedly useful, is one method sufficient to\n> > warrant creating a new top-level module. Waiting for it to hit the\n> > standard library will take quite a long time...\n> >\n> > There are other components of oslo that are terse and questionable as\n> > standalone libraries. For these, it might make sense to aggressively\n> > consider rolling some modules together?\n> >\n> > One clear example would be log.py and log_handler.py, another would be\n> > periodic_task.py and loopingcall.py\n> \n> I\'m not sure I see the harm in leaving small but widely used modules\n> in oslo incubator. If we really want to release everything as a\n> library, can\'t we just have a generic catchall one for the small\n> things? oslo.therest perhaps?\n\nIt seems to me that we have two different encodetures in oslo:\n\n1) Useful reusable code. config, logging, db access, etc.\n2) Common OpenStack conventions/formats/etc.\n\nOur usage of this module is just a level of indirection for all of us\nto share. I don\'t mind having a tiny library that makes things more\nconsistent.\n\nI suggest that if something is found to be a common OpenStack convention,\nit can go in a library that we call something clever, like \"kevin\", or\n\"oslo.common\".\n\n\n','<CAEd1pt5E4GUNsZfoHJ3SCAftbYAi5t+VCgHXQXdbjUnvq5jAiA@mail.gmail.com>',NULL),('<1384443700.78364.YahooMailAndroidMobile@web28803.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 15:41:40',0,'2013-11-14 15:41:40',NULL,'[openstack-dev] Split of the openstack-dev list','Good idea.\n\n-romain\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/85ec3d0f/attachment.html>\n\n','<5284CC57.7010403@openstack.org>',NULL),('<1384457558-sup-4374@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-14 11:46:46',-28800,'2013-11-14 19:46:46',NULL,'[openstack-dev] Split of the openstack-dev list','Excerpts from Thierry Carrez\'s message of 2013-11-14 05:12:55 -0800:\n> Hi everyone,\n> \n> I think that we have recently reached critical mass for the\n> openstack-dev mailing-list, with 2267 messages posted in October, and\n> November well on its way to pass 2000 again. Some of those are just\n> off-topic (and I\'ve been regularly fighting against them) but most of\n> them are just about us covering an ever-increasing scope, stretching the\n> definition of what we include in \"openstack development\".\n> \n> Therefore I\'d like to propose a split between two lists:\n> \n> *openstack-dev*: Discussions on future development for OpenStack\n> official projects\n> \n> *stackforge-dev*: Discussions on development for stackforge-hosted projects\n> \n> Non-official \"OpenStack-related\" projects would get discussed in\n> stackforge-dev (or any other list of their preference), while\n> openstack-dev would be focused on openstack official programs (including\n> incubated & integrated projects).\n> \n> That means discussion about Solum, Mistral, Congress or Murano\n> (stackforge/* repos in gerrit) would now live on stackforge-dev.\n> Discussions about Glance, TripleO or Oslo libraries (openstack*/* repos\n> on gerrit) would happen on openstack-dev. This will allow easier\n> filtering and prioritization; OpenStack developers interested in\n> tracking promising stackforge projects would subscribe to both lists.\n> \n> That will not solve all issues. We should also collectively make sure\n> that *usage questions are re-routed* to the openstack general\n> mailing-list, where they belong. Too many people still answer off-topic\n> questions here on openstack-dev, which encourages people to be off-topic\n> in the future (traffic on the openstack general ML has been mostly\n> stable, with only 868 posts in October). With those actions, I hope that\n> traffic on openstack-dev would drop back to the 1000-1500 range, which\n> would be more manageable for everyone.\n> \n\nAllow me an analogy if you will:\n\nConsider a burgeoning city. There are people who have been around a long\ntime. Some are politicians, some work for the city, some are just good\ncitizens. These people see newcomers in the commons and greet them with\nopen arms. Those who have only been around a while see those and see that\nthis is a city where new people are welcome, and they do the same as the\nold timers, welcoming new residents and visitors alike, and they also\nfeel even more welcome than before they noticed that. Though newcomers\nmust wait a while and gain the trust of the old-timers to call themselves\ncitizens, they are already encouraged to participate in discussions at\nevery level and to organize themselves in the same way as the old-timers.\n\nNow consider a different city. Things are quiet in the commons. Newcomers\nare greeted with a sign. \"Newcomers over there->\". That part of town is\nunknown to the rest of the world. It has less infrastructure. It also\nhas very little representation in the government. The line is very clear\nbetween the citizens and the newcomers. When the newcomers want to become\nfull citizens, they have to go before a council of old-timers, some of\nwhom have specifically decided to ignore newcomers until this moment.\n\nNow, choose which city will grow faster and produce more innovation.\n\n\n','<5284CC57.7010403@openstack.org>',NULL),('<1384534884.2372.215.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 17:01:24',0,'2013-11-15 17:01:24',NULL,'[openstack-dev] [Nova] New API requirements, review of GCE','On Fri, 2013-11-15 at 11:28 -0500, Russell Bryant wrote:\n> Greetings,\n> \n> We\'ve talked a lot about requirements for new compute drivers [1].  I\n> think the same sort of standards shold be applied for a new third-party\n> API, such as the GCE API [2].\n> \n> Before we can consider taking on a new API, it should have full test\n> suite coverage.  Ideally this would be extensions to tempest.  It should\n> also be set up to run on every Nova patch via CI.\n> \n> Beyond that point, now is a good time to re-consider how we want to\n> support new third-party APIs.  Just because EC2 is in the tree doesn\'t\n> mean that has to be how we support them going forward.  Should new APIs\n> go into their own repositories?\n> \n> I used to be against this idea.  However, as Nova\'s has grown, the\n> importance of finding the right spots to split is even higher.  My\n> objection was primarily based on assuming we\'d have to make the Python\n> APIs stable.  I still do not think we should make them stable, but I\n> don\'t think that\'s a huge issue, since it should be mitigated by running\n> CI so the API maintainers quickly get notified when updates are necessary.\n> \n> Taking on a whole new API seems like an even bigger deal than accepting\n> a new compute driver, so it\'s an important question.\n> \n> If we went this route, I would encourage new third-party APIs to build\n> themselves up in a stackforge repo.  Once it\'s far enough along, we\n> could then evaluate officially bringing it in as an official sub-project\n> of the OpenStack Compute program.\n\nI do think there should be a high bar for new APIs. More than just CI,\nbut that there is a viable group of contributors around the API who are\ninvolved in OpenStack more generally than just maintaining the API in\nquestion.\n\nI don\'t at all like the idea of drivers or APIs living in separate repos\nand building on unstable Nova APIs. Anything which we accept is a part\nof OpenStack should not get randomly made unusable by one contributor\nwhile other contributors constantly have to scramble to catch up. Either\nstuff winds up being broken too often or we stifle progress in Nova\nbecause we\'re afraid to make breaking changes.\n\nI happened to meet Thijs Metsch, the maintainer of OCCI for Nova\nyesterday:\n\n  https://github.com/tmetsch/occi-os\n  https://wiki.openstack.org/wiki/Occi\n\nand he described how often he had to fix the API implementation to adapt\nto changes in Nova\'s API. My advice was to work towards having the API\nbe included in Nova (understand that it\'s a long road and there would be\na bunch of difficult requirements) or take the less technically\nattractive option of proxying the OCCI API to the stable OpenStack REST\nAPI.\n\nFor someone like Thijs, choosing a middle road where the API\nimplementation is going to be constantly broken is going to suck for him\nand his users.\n\nMark.\n\n\n\n','<52864BBD.8080703@redhat.com>',NULL),('<1384535563-sup-860@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 09:14:55',-28800,'2013-11-15 17:14:55',NULL,'[openstack-dev] [Savanna] DiskBuilder / savanna-image-elements','Excerpts from Erik Bergenholtz\'s message of 2013-11-15 08:20:36 -0800:\n> Team - \n> \n> We?d like to move our disk creation mechanism over to using DiskBuilder so that users can build (and modify) their own VM images. We?d like to piggy back off of the existing mechanism that the vanilla plugin uses. It looks like I should be able to add image-elements to savanna-image-elements/elements directory for the HDP specific setup. Any concerns with this approach? From an organizational standpoint, it would make sense to separate elements from various plugins by creating a directory hierarchy under the elements directory; i.e. a directory for each plugin to keep them separated.\n> \n\nI don\'t know how exactly Savanna calls diskimage-builder, but it\nwould indeed make sense for there to be directories for each set of\nconcerns. One just needs to add each directory that should be searched\nto ELEMENTS_PATH (colon separated).  This also makes it possible to\noverride an element by putting a directory earlier in ELEMENTS_PATH,\nas the first found element for each name wins.\n\n\n','<912248EF-3431-4498-9607-AE8A55B5A38A@hortonworks.com>',NULL),('<1384536762.2372.218.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 17:32:42',0,'2013-11-15 17:32:42',NULL,'[openstack-dev] [Nova] New API requirements, review of GCE','On Fri, 2013-11-15 at 12:19 -0500, Russell Bryant wrote:\n> On 11/15/2013 12:01 PM, Mark McLoughlin wrote:\n> > On Fri, 2013-11-15 at 11:28 -0500, Russell Bryant wrote:\n> >> Greetings,\n> >>\n> >> We\'ve talked a lot about requirements for new compute drivers [1].  I\n> >> think the same sort of standards shold be applied for a new third-party\n> >> API, such as the GCE API [2].\n> >>\n> >> Before we can consider taking on a new API, it should have full test\n> >> suite coverage.  Ideally this would be extensions to tempest.  It should\n> >> also be set up to run on every Nova patch via CI.\n> >>\n> >> Beyond that point, now is a good time to re-consider how we want to\n> >> support new third-party APIs.  Just because EC2 is in the tree doesn\'t\n> >> mean that has to be how we support them going forward.  Should new APIs\n> >> go into their own repositories?\n> >>\n> >> I used to be against this idea.  However, as Nova\'s has grown, the\n> >> importance of finding the right spots to split is even higher.  My\n> >> objection was primarily based on assuming we\'d have to make the Python\n> >> APIs stable.  I still do not think we should make them stable, but I\n> >> don\'t think that\'s a huge issue, since it should be mitigated by running\n> >> CI so the API maintainers quickly get notified when updates are necessary.\n> >>\n> >> Taking on a whole new API seems like an even bigger deal than accepting\n> >> a new compute driver, so it\'s an important question.\n> >>\n> >> If we went this route, I would encourage new third-party APIs to build\n> >> themselves up in a stackforge repo.  Once it\'s far enough along, we\n> >> could then evaluate officially bringing it in as an official sub-project\n> >> of the OpenStack Compute program.\n> > \n> > I do think there should be a high bar for new APIs. More than just CI,\n> > but that there is a viable group of contributors around the API who are\n> > involved in OpenStack more generally than just maintaining the API in\n> > question.\n> > \n> > I don\'t at all like the idea of drivers or APIs living in separate repos\n> > and building on unstable Nova APIs. Anything which we accept is a part\n> > of OpenStack should not get randomly made unusable by one contributor\n> > while other contributors constantly have to scramble to catch up. Either\n> > stuff winds up being broken too often or we stifle progress in Nova\n> > because we\'re afraid to make breaking changes.\n> > \n> > I happened to meet Thijs Metsch, the maintainer of OCCI for Nova\n> > yesterday:\n> > \n> >   https://github.com/tmetsch/occi-os\n> >   https://wiki.openstack.org/wiki/Occi\n> > \n> > and he described how often he had to fix the API implementation to adapt\n> > to changes in Nova\'s API. My advice was to work towards having the API\n> > be included in Nova (understand that it\'s a long road and there would be\n> > a bunch of difficult requirements) or take the less technically\n> > attractive option of proxying the OCCI API to the stable OpenStack REST\n> > API.\n> > \n> > For someone like Thijs, choosing a middle road where the API\n> > implementation is going to be constantly broken is going to suck for him\n> > and his users.\n> \n> Thanks for the comments.  Very interesting ...\n> \n> A significantly high bar such that having it in the tree isn\'t a drain\n> on nova development (significant commitment by the maintainers, as well\n> as solid test coverage) makes sense.\n> \n> Would we consider ripping it out if contribution goes down, or testing\n> doesn\'t keep up?\n\nI\'d think so, but it should be a pretty serious drop - stuff coming and\ngoing regularly would be more of an issue for users than reduced\nquality.\n\n> If so, do we apply the same standards to the EC2 API?\n> How much time do we give EC2 to get up to this standard before we rip\n> it out?\n\nI hadn\'t understood the EC2 API to be in such a woeful state. Are we\nsaying the implementation is so bad it\'s not at all useful for users? Or\nthat a lack of testing means we see a far higher rather of regressions\nthan in e.g. the OpenStack API? Or just that we don\'t see much progress\non it?\n\nMark.\n\n\n\n','<528657BA.9020006@redhat.com>',NULL),('<1384537210-sup-243@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 09:51:15',-28800,'2013-11-15 17:51:15',NULL,'[openstack-dev] Split of the openstack-dev list (summary so far)','Excerpts from Stefano Maffulli\'s message of 2013-11-15 09:12:05 -0800:\n> On 11/15/2013 02:06 AM, Thierry Carrez wrote:\n> > Arguments in favor of splitting openstack-dev / stackforge-dev\n> > * People can easily filter out all non-openstack discussions\n> > * Traffic would drop by about 25%\n> \n> I\'m not so convinced about this figure, as others pointed out.\n> \n> > * Removes confusion as to which projects are actually \"in openstack\"\n> > \n> > Arguments in favor of keeping it the same\n> > * Provides a cross-pollination forum where external projects can learn\n> > * More chaos creates more innovation\n> \n> chaos creates just chaos in this context :) I don\'t buy Clint\'s rhetoric\n> applied to this case :)\n> \n\nYou say that like chaos is all bad. The trade-off is that the chaos\ncreate\'s chain reactions often leading to _more_ energy being released.\nThis is not always the most efficient use of energy, but it does unlock\nenergy that may never have been realized. I have to wonder if Mistral\nwould have been created the way it was if TaskFlow discussions were\ndivided between the \"core\" list and stackforge list.\n\nI think this is rather interesting, that we are debating how to scale a\nlist of \"compute\" nodes that we call developers by effectively creating\n\"cells\". We all know that this only solves one problem and now creates\nanother one. One cell can still be overloaded. The balance between the\ntwo is simply not going to hold true.\n\nPerhaps the answer is instead to look at why the compute nodes feel that\nthey need to look at every single broadcast topic. Are we all using\nhorrible email clients (probably, because all email clients are\nhorrible) or are we just inept? Could we benefit from some training on\nthis subject? Better tools? A cultural acceptance that some people will\nlikely miss some messages?\n\n> Anyway, I\'ve looked at my folder and it looks like 90% of the messages\n> to openstack-dev have topics in the subject line. Filtering on the\n> client side should be easy to do and I\'d like to have a few volunteers\n> run an experiment over one week to see if filters can ease the pain.\n>\n\nI don\'t filter at all. I use sup-mail, which is an unmaintained ruby\nbased client like notmuch that has one benefit worth using an unmaintained\nruby anything. It very easily allows \"killing\" threads without deleting\nthem. This means that as soon as I see a subject line is not interesting,\nI press & on the thread, and it is gone from my view. Until I do a local\nsearch with \'\\\', which then searches the local xapian index and may show\nkilled threads. Neat huh?  This may be why I don\'t favor splitting,\nbecause I don\'t get overwhelmed by long threads.. they\'re gone 1 or 2\nmessages in.\n\nI\'m not suggesting that everybody switch to sup. But rather that we try\nto investigate why the list is overwhelming people before we just split\nit in two, which I do believe will have large unintended and difficult\nto detect consequences.\n\n> I\'d also like to get to an agreement that support requests sent to\n> openstack-dev should not be answered and instead should be redirected\n> gently to openstack at lists. and/or ask.openstack.org.\n> \n\nMy general sense is that this is already happening.\n\n\n','<528655E5.70906@openstack.org>',NULL),('<1384538249.2372.227.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 17:57:29',0,'2013-11-15 17:57:29',NULL,'[openstack-dev] [RFC] Straw man to start the incubation /\n graduation requirements discussion','On Wed, 2013-11-13 at 06:57 -0500, Sean Dague wrote:\n> (Apologies, this started on the TC list, and really should have started\n> on -dev, correctly posting here now for open discussion)\n> \n> There were a few chats at summit about this, mostly on the infra /\n> devstack / qa side of the house. Consider the following a straw man to\n> explain the current state of the world, and what I\'d like to see change here\n> I call out projects by name here, not to\n> make fun of them, but that I think concrete examples bring the point\n> home much more than abstract arguments (at least for me).\n> \n> This is looking at raising the bar quite a bit along the way. However,\n> as someone that spends a lot of time trying to keep the whole ball of\n> wax holding together, and is spending a lot of time retroactively trying\n> to get projects into our integrated gate (and huge pain to everyone, as\n> their gate commits get bounced by racey projects), I think we really\n> need to up this bar if we want a 20 integrated project version of\n> OpenStack to hold together.\n\nThanks for doing this. The requirements look good to me.\n\nI think it\'s about time we gathered all requirements together and\nproperly documented them so people realize there\'s a much bigger\npicture. I\'ve started pulling together some stuff here:\n\n  https://etherpad.openstack.org/p/incubation-and-integration-requirements\n\nbut clearly there\'s a lot of work to do.\n\nOne thing I really, really want is for the rules to be accompanied with\na good explanation of what the rules are there to achieve. We cannot let\nourselves turn into a community that over-zealously applies rules to the\nextent that the rules do more damage than good.\n\nThere\'s always got to be a judgement call involved. I\'m happy that\nCeilometer graduated, even though it doesn\'t have gating tests. I think\nit has been a positive addition and I\'d rather have it without the\ngating tests than not at all.\n\nThe guidelines like this will greatly encourage projects to up their\ngame and hopefully we\'ll rarely be faced with a generally awesome\nproject wanting to graduate but it not having integration tests.\nHowever, if that did happen, we need it to at least be possible for us\nto have a rational, big-picture conversation about whether some\nrule-bending is the best thing overall for the project.\n\nMark.\n\n\n\n','<52836939.40808@dague.net>',NULL),('<1384539198.2372.241.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 18:13:18',0,'2013-11-15 18:13:18',NULL,'[openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd\n week of January, Montreal, QC, Canada','On Fri, 2013-11-15 at 12:47 -0500, Anita Kuno wrote:\n> On 11/15/2013 12:34 PM, Russell Bryant wrote:\n> > On 11/15/2013 12:16 PM, Kyle Mestery (kmestery) wrote:\n> >> On Nov 15, 2013, at 11:04 AM, Dan Smith <dms at danplanet.com> wrote:\n> >>>> Thanks for weighing in, I do hope to keep the conversation going.\n> >>> Add my name to the list of people that won\'t be considering the trip as\n> >>> a result.\n> >>>\n> >> Are people really saying that if they show up for this Tempest sprint\n> >> with a logo shirt they would actually take it off and wear a white shirt\n> >> provided by someone, or that this will prevent them from going at all?\n> >> I can\'t even believe we\'re having this conversation on the list, frankly.\n> > I\'m saying that I find it so ridiculous, that I wouldn\'t consider going\n> > at all.\n> >\n> > I find the suggestion that I would be given a different shit to wear so\n> > offensive, that I have to waste time having this conversation to condemn\n> > it publicly.  I have a lot of pride in OpenStack, and don\'t want anyone\n> > to think that everyone finds this sort of requirement acceptable in our\n> > community.\n> I respect this about you, Russell and it is one of the many reasons I am \n> so glad to work with you.\n> \n> Had this level of pride in OpenStack been prevalent during the Neutron \n> design summit sessions, it wouldn\'t even have occured to me to mention it.\n> \n> I hope to attract people with this level of pride in OpenStack to the \n> code sprint and my thought was that eliminating logos would support that \n> goal.\n> \n> What would you suggest to attract and foster this level of pride in \n> OpenStack in the code sprint attendees?\n> \n> I will also note, that while you clearly stated the Neutron is being \n> considered for deprecation - t-shirts prevail as an issue on this \n> thread. I consider that rather interesting to observe.\n\nI think you\'re expressing a similar sentiment to e.g. \"there should be\nmore Neutron developers who work on core Neutron rather than just their\ndrivers\". I\'m cool with that, and totally agree.\n\nChoosing to pick on people\'s choice of clothing is just a bizarre way of\nexpressing that concern, though.\n\nBear in mind how often I talk about this being a community of\nindividuals, we should all wear our \"project hats\", that our affiliation\nshould be secondary to our commitment to our project, ...\n\nDictating what people can wear to an OpenStack event is not my idea of\nwhat OpenStack is all about. It\'s not my idea of the \"mutual respect\"\nyou talk about.\n\nMark.\n\n\n\n','<52865E2F.4000708@anteaya.info>',NULL),('<1384560101.28260.0.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 16:01:41',-28800,'2013-11-16 00:01:41',NULL,'[openstack-dev] [nova][api] Is this a potential issue','On Fri, 2013-11-15 at 17:19 -0500, Andrew Laski wrote:\n> On 11/15/13 at 07:30am, Dan Smith wrote:\n> >> You\'re not missing anything.  But I think that\'s a bug, or at least an\n> >> unexpected change in behaviour from how it used to work.  If you follow\n> >> instance_update() in nova.db.sqlalchemy.api just the presence of\n> >> expected_task_state triggers the check.  So we may need to find a way to\n> >> pass that through with the save method.\n> >\n> >This came up recently. We decided that since we no longer have a kwargs\n> >dictionary to test for the presence or absence of that flag, that we\n> >would require setting it to a tuple, which is already supported for\n> >allowing multiple state possibilities. So, if you pass\n> >expected_task_state=(None,) then it will do the right thing.\n> >\n> >Make sense?\n> \n> Perfect.  I thought the old method was a bit counterintuitive and \n> started thinking this would be better after I sent the email earlier.\n> \n\nI checked and seems most usage of instance.save() with\nexpected_state=None assume an exception and need change. Can I assume\nthis rule apply to all?\n\nIf yes, would it be possible to create a special task_state as IDLE, to\ndistinguish it better? When no task on-going, the task_state will be\nIDLE, instead of None.\n\n--jyh\n\n\n\n\n\n\n\n\n\n','<20131115221916.GL18846@crypt>',NULL),('<1384673029.58791.YahooMailAndroidMobile@web171205.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-17 07:23:49',0,'2013-11-17 07:23:49',NULL,'[Openstack] Folsom: No handlers could be found for\n	logger	\"keystoneclient.client\"','Krish, check your database. Looks like keystone cannot find the tenant table.? Do you have the database setup? Login to? your database and check if you see tenant database and if all the tables are there.\n\n----------------\nRadek ?migielski\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131117/6fa80f9e/attachment.html>\n\n','<CAL6MZqfZsTpU=pc34+scv-3YWVxo3E-8CfYTNU8gUMtr2Vux9w@mail.gmail.com>',NULL),('<1384684880.66590.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-17 18:41:20',28800,'2013-11-17 10:41:20',NULL,'[Openstack] problem in starting swift','hi all,\n\nI am installing swift on my system using the guidelines given in the link \n\nhttp://docs.openstack.org/developer/swift/development_saio.html\n\nwhen Setting up scripts for running Swift\nat the command \n\nroot at arun-Aspire-5742:~# startmain\n\nI got the following error:\nhttp://paste.openstack.org/show/53458/\n\nplease help me to overcome this problem.\n\nThanks in advance \n\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131117/fa93f204/attachment.html>\n\n',NULL,NULL),('<1384757177.16852.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 06:46:17',0,'2013-11-18 06:46:17',NULL,'[Openstack] [Foundation Board] Resolutions from the Technical\n	Committee','Hi Mark,\n\nOn Thu, 2013-11-14 at 07:58 -0600, mark at openstack.org wrote:\n> Yes.\n> \n> Also, there are two trademark concepts being mixed here.\n> \n> 1)\n> *Can* the projects themselves use the word \"OpenStack\" such as\n> \"OpenStack Orchestration\"?  \n> Answer: yes absolutely. This is already a done deal and we are already\n> doing it in practice. And its covered under the bylaws once they are\n> included in the integrated release by TC vote. There is no need for\n> further action.\n\nThat\'s not our understanding. See the parts of the bylaws quoted here:\n\n  https://git.openstack.org/cgit/openstack/governance/tree/resolutions/20131106-ceilometer-and-heat-official-names\n\nI think it\'s pretty clear that unless a \'module\' (e.g. Heat) is added to\nthe \'Core OpenStack Project\' by the board on the recommendation of the\nTC, it can\'t call itself e.g. OpenStack Orchestration.\n\nMark.\n\n\n\n','<E1VgxTa-0008J8-0C@lists.openstack.org>',NULL),('<1384758339.91280.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 15:05:39',28800,'2013-11-18 07:05:39',NULL,'[Openstack] problem in starting swift','ThanksZhang\n\n\nroot at arun-Aspire-5742:~# pico /root/swift/swift/common/middleware/recon.py\nit shows the file at the place\n\n\n\n\nOn Monday, 18 November 2013 4:32 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote:\n \nMake sure module of recon is in place under this path and can be accessible:\n>/root/swift/swift/common/middleware/recon.py\n>\n>-Edward\n>\n>\n>pragya jain ---2013-11-17 ?? 06:49:40---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n>pragya jain <prag_2648 at yahoo.co.in>? \n>2013-11-17 ?? 06:41 \n>Please respond to\n>pragya jain <prag_2648 at yahoo.co.in>  \n>\n>To \n>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>  \n>\n>\n>cc \n> \n>\n>\n>Subject \n>[Openstack] problem in starting swift     \n>\n>hi all,\n>\n>I am installing swift on my system using the guidelines given in the link \n>http://docs.openstack.org/developer/swift/development_saio.html\n>\n>when Setting up scripts for running Swift\n>at the command \n>root at arun-Aspire-5742:~# startmain\n>\n>I got the following error:\n>http://paste.openstack.org/show/53458/\n>\n>please help me to overcome this problem.\n>\n>Thanks in advance \n>\n>Pragya Jain\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/47375d61/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/47375d61/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/47375d61/attachment-0001.gif>\n\n','<OF384FEF45.3601987F-ON48257C27.000DB396-48257C27.000DFE13@cn.ibm.com>',NULL),('<1384758342.97837.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 15:05:42',28800,'2013-11-18 07:05:42',NULL,'[Openstack] problem in starting swift','ThanksZhang\n\n\nroot at arun-Aspire-5742:~# pico /root/swift/swift/common/middleware/recon.py\nit shows the file at the place\n\nbut the error is still there\n\n\n\n\nOn Monday, 18 November 2013 4:32 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote:\n \nMake sure module of recon is in place under this path and can be accessible:\n>/root/swift/swift/common/middleware/recon.py\n>\n>-Edward\n>\n>\n>pragya jain ---2013-11-17 ?? 06:49:40---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n>pragya jain <prag_2648 at yahoo.co.in>? \n>2013-11-17 ?? 06:41 \n>Please respond to\n>pragya jain <prag_2648 at yahoo.co.in>  \n>\n>To \n>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>  \n>\n>\n>cc \n> \n>\n>\n>Subject \n>[Openstack] problem in starting swift     \n>\n>hi all,\n>\n>I am installing swift on my system using the guidelines given in the link \n>http://docs.openstack.org/developer/swift/development_saio.html\n>\n>when Setting up scripts for running Swift\n>at the command \n>root at arun-Aspire-5742:~# startmain\n>\n>I got the following error:\n>http://paste.openstack.org/show/53458/\n>\n>please help me to overcome this problem.\n>\n>Thanks in advance \n>\n>Pragya Jain\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/6e097b27/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/6e097b27/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131118/6e097b27/attachment-0001.gif>\n\n','<OF384FEF45.3601987F-ON48257C27.000DB396-48257C27.000DFE13@cn.ibm.com>',NULL),('<1384760238.45436.YahooMailNeo@web172405.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 07:37:18',0,'2013-11-18 07:37:18',NULL,'[Openstack] [neutron] neutron-ovs-cleanup: which distros\n	require manual invocation','Hi Lorin,\n\nI had a look at a Ubuntu installation and the package install scripts do not \n\nconfigure neutron-ovs-cleanup to run at boot time. \n\nOVS\n has its own database, and at boot it recreates any internal interfaces \n\n(qr-, qg- and dhcp taps) in the root namespace. The l3 and dhcp \nagents don\'t \n\nseem to have a problem with that. They create their \nnamespaces and move the \n\ninterfaces into them and ensure the mac addresses are correct.\n\nI think neutron-ovs-cleanup is only needed if you are not using network \n\nnamespaces. But I don\'t know why you would want to do that as Ubuntu Precise\nalways had namespace support.\n\nRegards,\nDarragh.\n\n>Hi Nick:\n>\n>The Red Hat packages include a service script (I assume at\n>/etc/init.d/neutron-ovs-cleanup) that invokes /usr/bin/neutron-ovs-cleanup\n>automatically at the appropriate time. I was asking whether there was an\n>equivalent service script in Ubuntu that invokes\n>/usr/bin/neutron-ovs-cleanup on boot.\n>\n>Lorin\n>\n>\n>On Fri, Nov 15, 2013 at 2:05 AM, Nick Maslov <azpekt at gmail.com> wrote:\n>\n>> Hi,\n>>\n>> Sure:\n>>\n>> root at net01-001:/etc/neutron# dpkg -S /usr/bin/neutron-ovs-cleanup\n>> *neutron-common*: /usr/bin/neutron-ovs-cleanup\n>>\n>> Cheers,\n>> NM\n>> --\n>> Nick Maslov\n>> Sent with Airmail <http://airmailapp.com/tracking>\n>>\n>> On November 14, 2013 at 7:56:12 PM, Lorin Hochstein (\n>> lorin at nimbisservices.com <//lorin at nimbisservices.com>) wrote:\n>>\n>>? Hi Nick:\n>>\n>> Can you let me know which Ubuntu package contains the neutron-ovs-cleanup\n>> service file?\n>>\n>> You can use \"dpkg -S\" to get this info: dpkg -S /path/to/file\n>>\n>> Thanks,\n>>\n>> Lorin\n>>\n>>\n>> On Thu, Nov 14, 2013 at 11:44 AM, Nick Maslov <azpekt at gmail.com> wrote:\n>>\n>>>? Hi Lorin,\n>>>\n>>>? I`m on Ubuntu - seems like this service is installed as well - I see it\n>>> as part of my network node installation.\n>>>\n>>>? Cheers,\n>>>? NM\n>>> --\n>>> Nick Maslov\n>>> Sent with Airmail <http://airmailapp.com/tracking>\n>>>\n>>> On November 13, 2013 at 5:06:14 AM, Lorin Hochstein (\n>>> lorin at nimbisservices.com <//lorin at nimbisservices.com>) wrote:\n>>>\n>>>?? I?d like to update the havana install guide about the need to invoke\n>>> neutron-ovs-cleanup before rebooting nodes where there?s an openvswitch tap\n>>> device created (L3 agent, DHCP agent). See <\n>>> https://bugs.launchpad.net/openstack-manuals/+bug/1156861>.\n>>>\n>>> It seems like the RHEL packages install a neutron-ovs-cleanup service\n>>> that does the right thing, so no operator intervention is necessary when\n>>> rebooting network nodes on RHEL.\n>>>\n>>> However, I have no idea if this is the case for SUSE, Ubuntu, or Debian\n>>> installations, and the install guides are now distro-specific. Anybody know\n>>> if these other distro packages install a neutron-ovs-cleanup service?\n>>>\n>>>?? Lorin\n>>>\n>>>??? _______________________________________________\n>>> Mailing list:\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to : openstack at lists.openstack.org\n>>> Unsubscribe :\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>> --\n>> Lorin Hochstein\n>> Lead Architect - Cloud Services\n>> Nimbis Services, Inc.\n>> www.nimbisservices.com\n\n\n',NULL,NULL),('<1384763845.16852.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 08:37:25',0,'2013-11-18 08:37:25',NULL,'[Openstack] [Foundation Board] Resolutions from the Technical\n	Committee','On Mon, 2013-11-18 at 07:40 +0000, Radcliffe, Mark wrote:\n> We need to distinguish between (1) adding the modules to the \"Core\n> OpenStack Project\" which requires a recommendation by the TC and\n> approval by the Board and (2) adding the modules to an integrated\n> release (including Core OpenStack Project) which uses the OpenStack\n> brand.\n\nWe already clearly make this distinction. That was the primary\nconclusion of the Incubation Update Committee:\n\nhttps://wiki.openstack.org/wiki/Governance/Foundation/IncubationUpdate2013\n\n> We don\'t yet have approval for adding these modules to the Core\n> OpenStack Project (Hypothetical 1). However, adding the modules to an\n> integrated release (including Core OpenStack Project) using the\n> OpenStack brand is permitted (Hypothetical 2).  However, the use of a\n> term \"Orchestration\" with the OpenStack mark, such as OpenStack\n> Orchestration needs Board approval.\n\nYes, that\'s the TC\'s reasoning behind recommending to the board that\nHeat and Ceilometer be added to the \"Core OpenStack Project\".\n\nAnd the TC sees a big distinction between this meaning of \"Core\nOpenStack Project\" and \"the set of functionality/APIs/code which must be\nincluded in products licensed to use the OpenStack brand\".\n\nThe latter meaning of \"core\" is not defined in or covered by the bylaws\nAFAICT.\n\nMark.\n\n\n\n','<E682AA2FC88ADD4589420BFC6BE3A9215AE605@SANDMBX01v.Piper.Root.Local>',NULL),('<1384772677.16852.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 11:04:37',0,'2013-11-18 11:04:37',NULL,'[Openstack] [Foundation Board] Resolutions from the Technical\n Committee','On Fri, 2013-11-15 at 09:53 +0100, Thierry Carrez wrote:\n> Stefano Maffulli wrote:\n> > On 11/14/2013 09:56 AM, Boris Renski wrote:\n> >> If per bylaws any integrated project can called itself \"OpenStack Blah\"\n> >> then we return to the question of current difference between integrated\n> >> and core. It seems like there is no alignment. Jonathan\'s opinion\n> >> contradicts Thierry\'s. \n> > \n> > I don\'t see this contradiction between what Thierry says and what\n> > Jonathan says. On the contrary, I see Jonathan\'s words confirming what\n> > Thierry said.\n> > \n> > My understanding is that both are saying that since OpenStack\n> > Orchestration and Metering are released together with other packages\n> > (modules) in *one*, *integrated* release managed by the TC, they can be\n> > called \'OpenStack\'-something under art. 4.1(b) of the bylaws. My\n> > understanding is that Trove will likely be in the same situation as Heat\n> > once it graduates out of incubation.\n> \n> I\'ll admit that the language in the bylaws was a bit confusing to me\n> (and others on the TC), which is why we submitted this resolution in the\n> first place. Both Mark and Jonathan clarified that projects integrated\n> in the common OpenStack release (\"integrated\" projects) can all call\n> themselves \"OpenStack Blah\" without needing to ask permission from the\n> BoD. That just makes sense and is consistent with the way we operated in\n> the past, so I\'m definitely fine with that.\n> \n> I think we can go back to ignoring this confusing \"Core OpenStack\n> project\" language and continue using the term \"core\" to designate the\n> subset of integrated projects that you are /required/ to implement to\n> call your implementation \"an OpenStack cloud\".\n\nHmm, I missed this part of the thread before replying to Mark\'s earlier\nmail.\n\nBasically, we\'re choosing here an interpretation of the bylaws which\nsays any project included in the integrated release can automatically\ncall itself OpenStack Foo.\n\nHowever, there\'s clearly an intent here to distinguish between projects\nclassified as part of the \"Core OpenStack Project\" and other projects\nincluded in the integrated release.\n\nIf the distinction isn\'t \"can call itself OpenStack Foo\", then what\nexactly is the distinction now?\n\nMark.\n\n\n\n','<5285E0EC.50807@openstack.org>',NULL),('<1384773466.16852.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-18 11:17:46',0,'2013-11-18 11:17:46',NULL,'[Openstack] [Foundation Board] Resolutions from the Technical\n	Committee','On Thu, 2013-11-14 at 23:06 -0600, Jonathan Bryce wrote:\n> The current difference in implementation is that to be part of the\n> Core OpenStack Project, a module must receive Board approval to be in\n> that set. Another intended difference is that the Core OpenStack\n> Project definition would be used as a means of collecting the projects\n> for various trademark licensing and interop requirements. That part of\n> the implementation is still in progress with the ongoing work of the\n> Board.\n> \n> The Bylaws were drafted to take into account the expected direction\n> that these initiatives were going to move based off the drafting\n> meetings we had last year, and they included some ?forward looking?\n> provisions like this. Same thing with the FITS testing piece of the\n> trademark licenses that gives the TC the right to approve a test suite\n> for usage.\n\nSo, to my question of the intent of the difference between \"Core\nOpenStack Project\" and Integrated ...\n\nYou\'re saying the intent was not about:\n\n  1) *Can* the projects themselves use the word \"OpenStack\" such as\n  \"OpenStack Orchestration\"?\n\nbut rather it was intended to be solely about:\n\n  2) *Must* a commercial product or service branded \"OpenStack\" use\n  heat or ceilometer or project X from the integrated release?\n\nAm I understand you correctly?\n\nIf so, I think we have a bunch of work to do to clarify the bylaws ...\nbecause I think those of us on the TC side who read the bylaws and tried\nto divine the intent came to the conclusion it was entirely about (1)\nand *nothing* to do with (2).\n\nMark.\n\n\n\n','<8F3C13C1-5151-4FBD-983F-2CB8ED97F383@jbryce.com>',NULL),('<1384781785.53156.YahooMailNeo@web163804.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 05:36:25',-28800,'2013-11-18 13:36:25',NULL,'[openstack-dev] [Solum] SFO Design Workshop','Do we need to register on event brite if joining over IRC / Google Hangout?\n\n\n\n\nOn Saturday, November 16, 2013 3:43 AM, Roshan Agrawal <roshan.agrawal at RACKSPACE.COM> wrote:\n \nWe are all set for the Solum design workshops at SFO on Nov 19,20. The etherpad page below has schedule and agenda details\nhttps://etherpad.openstack.org/p/SolumSFOCommunityWorkshop\n\nPlease sign up as topic leads/scribe for the sessions listed in the agenda.\n\nWe also have etherpad pages setup for each track of discussion, and we can fill in content right away to prep for the lively discussions next week. We also have a happy hour planned on the evening of Tuesday, and have lunch arrangements on the house.\n\nLooking forward to a fun and productive two days at SFO! \n\nThanks & Regards,\nRoshan Agrawal\nDirect:??? 512.874.1278\nMobile:? 512.354.5253\nRoshan.agrawal at rackspace.com\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/4daa3542/attachment.html>\n\n','<9C1B7917DE16F44D855E72328D666ED1231C6271@ORD1EXD03.RACKSPACE.CORP>',NULL),('<1384792277.16852.63.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 16:31:17',0,'2013-11-18 16:31:17',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','Hi Julien,\n\nOn Mon, 2013-11-18 at 11:05 +0100, Julien Danjou wrote:\n> Hi Oslo developers,\n> \n> It seems my latest patch? on oslo.messaging scared Mark, so I\'ll try to\n> discuss it a bit on this mailing list as it is more convenient.\n\nScared, heh :)\n\n> I\'ve created a blueprint? as requested by Mark.\n\nOk, so it\'s a ceilometer blueprint and says:\n\n  \"The goal of this blueprint is to be able to use oslo.messaging\n   without using a configuration file/object, while keeping its usage\n   possible and not breaking compatibility with OpenStack applications.\"\n\nWhy is that important to ceilometer? Ceilometer heavily uses the RPC\ncode already and uses the config object.\n\nIs this about allowing Ceilometer to consume from multiple brokers?\nWhere will the configuration be stored for each broker connection? In\nthe ceilometer database? Why won\'t transport URLs be sufficient for that\nuse case given that we know it works fine for Nova cells?\n\nI\'m struggling to care about this until I have some insight into why\nit\'s important. And it\'s a bit frustrating to have to guess the\nrationale for this. Like commit messages, blueprints should be as much\nabout the why as the what.\n\n> That seems necessary since it will be spread on several patch.\n\nIt\'s not about multiple patches, it\'s about something which needs to be\ndesigned and thought through in advance.\n\n> Now to the core. oslo.messaging API mixes usage of parameters and\n> configuration file object. Such as you have to provide a configuration\n> object for basic API usage, even if you don\'t have a configuration\n> object.\n> \n> It seems to me that having this separation of concerns in oslo.messaging\n> would be good idea. My plan is to move out the configuration object out\n> of the basic object, like I did in the first patch.\n> \n> I don\'t plan to break the configuration handling or so, I just think it\n> should be handled in a separate, individually testable part of the code.\n\nAs I said in the review, I\'m totally fine with the idea of allowing\noslo.messaging to be used without a configuration object ... but I think\nthe common use case is to use it with a configuration object and I don\'t\nwant to undermine the usability of the library in the common use case.\n\nOne way of approach this would be to describe how the new API would look\nlike from the perspective of Nova[1] - i.e. if you are using a config\nobject, what does the API look like?\n\nThe other thing I want to figure out is how we expose the configuration\noptions in the API in a way that allows us to maintain API compatibility\nas we move and rename the config options. That\'s doable, but needs some\nthought.\n\nThanks,\nMark.\n\n[1] - https://review.openstack.org/39929\n\n\n\n','<87txfat47z.fsf@dex.adm.naquadah.org>',NULL),('<1384793083.16852.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 16:44:43',0,'2013-11-18 16:44:43',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','Hey Doug,\n\nOn Mon, 2013-11-18 at 11:29 -0500, Doug Hellmann wrote:\n> On Mon, Nov 18, 2013 at 5:05 AM, Julien Danjou <julien at danjou.info> wrote:\n> \n> > Hi Oslo developers,\n> >\n> > It seems my latest patch? on oslo.messaging scared Mark, so I\'ll try to\n> > discuss it a bit on this mailing list as it is more convenient.\n> >\n> > I\'ve created a blueprint? as requested by Mark. That seems necessary\n> > since it will be spread on several patch.\n> >\n> > Now to the core. oslo.messaging API mixes usage of parameters and\n> > configuration file object. Such as you have to provide a configuration\n> > object for basic API usage, even if you don\'t have a configuration\n> > object.\n> >\n> \n> IIRC, one of the concerns when oslo.messaging was split out was\n> maintaining support for existing deployments with configuration files that\n> worked with oslo.rpc. We had said that we would use URL query parameters\n> for optional configuration values (with the required values going into\n> other places in the URL), but that format wouldn\'t be backwards compatible\n> if a deployment already had the other configuration settings listed\n> individually.\n\nI hadn\'t ever considered exposing all configuration options via the URL.\nWe have a lot of fairly random options, that I don\'t think you need to\nconfigure per-connection if you have multiple connections in the one\napplication.\n\n> One way to address that difference is to make the use of oslo.config an\n> explicit step, before instantiating a Transport using a URL. Given a URL\n> for a transport and an oslo.config object, an application could ask\n> oslo.messaging to build a new URL containing all of the settings from the\n> config that apply. Something like:\n> \n>     from oslo.config import cfg\n>     from oslo.messaging import config as om_config\n>     from oslo.messaging import transport\n> \n>     base_url = cfg.CONF.rpc_url\n>     full_url = om_config.update_url_from_config(base_url, cfg.CONF)\n> \n>     trans = transport.get_transport(full_url)\n\nI don\'t think anyone would thanks us for the horrific URLs that would\nresult from this.\n\nBut if we did this, I\'d just make it:\n\n  from oslo.config import cfg\n  from oslo.messaging import config as om_config\n\n  transport = om_config.get_transport_from_config(cfg.CONF)\n\n> update_url_from_config() would use the base_url to determine the driver,\n> load the option definitions for that driver, then pull the values out of\n> the config object and construct a new URL starting with the base and\n> including the extra settings (thus preserving backwards-compatibility for\n> the existing config files).\n> \n> Applications that do not use oslo.config would just call get_transport().\n> \n> As an alternative, and to preserve API compatibility with the existing\n> release of oslo.messaging, we could just change get_transport() to allow\n> the first argument to be None (instead of removing it entirely). When it is\n> a valid config object, we would go through the steps we do now to get\n> configuration options. When it is None, we would skip those steps.\n\nAPI compatibility isn\'t yet important. We haven\'t done a first release\nyet and no projects are using the library.\n\nMark.\n\n\n\n','<CADb+p3TRWnVMDbw3ojMpUAadrzfi6uhdh1EZwtt0-_=gxg48Pw@mail.gmail.com>',NULL),('<1384793180.16852.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 16:46:20',0,'2013-11-18 16:46:20',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','On Mon, 2013-11-18 at 17:37 +0100, Julien Danjou wrote:\n> On Mon, Nov 18 2013, Mark McLoughlin wrote:\n\n> > I\'m struggling to care about this until I have some insight into why\n> > it\'s important. And it\'s a bit frustrating to have to guess the\n> > rationale for this. Like commit messages, blueprints should be as much\n> > about the why as the what.\n> \n> Sure. I ought to think that having an application that wants to leverage\n> oslo.messaging but is not using oslo.config and is retrieving its\n> parameter from another way is a good enough argument.\n\nIt\'s a theoretical benefit versus the very practical \"design an API for\nthe use cases that are actually important to OpenStack projects\".\n\n> > As I said in the review, I\'m totally fine with the idea of allowing\n> > oslo.messaging to be used without a configuration object ... but I think\n> > the common use case is to use it with a configuration object and I don\'t\n> > want to undermine the usability of the library in the common use case.\n> \n> Understood. I know it\'s already a pain to transition from RPC to\n> messaging, and I don\'t want to add more burden on that transition.\n\nCool, thanks.\n\nMark.\n\n\n\n','<87hab9r7if.fsf@dex.adm.naquadah.org>',NULL),('<1384799745.28260.1.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 10:35:45',-28800,'2013-11-18 18:35:45',NULL,'[openstack-dev] [nova][api] Is this a potential issue','On Mon, 2013-11-18 at 10:18 -0500, Andrew Laski wrote:\n> On 11/15/13 at 04:01pm, yunhong jiang wrote:\n> >On Fri, 2013-11-15 at 17:19 -0500, Andrew Laski wrote:\n\n> >If yes, would it be possible to create a special task_state as IDLE, to\n> >distinguish it better? When no task on-going, the task_state will be\n> >IDLE, instead of None.\n> \n> I\'m starting on some work right now which will break task_state off into \n> it\'s own model and API resource.  In my opinion we don\'t need to model \n> the idea of no task running, we can check if there are tasks for the \n> instance or not.  So I think that using None is fine here and we \n> shouldn\'t add an IDLE state.\n> \nGot it, thanks.\n\n--jyh\n> >\n> >--jyh\n> >\n> >\n> >\n> >\n> >\n> >\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<20131118151848.GO18846@crypt>',NULL),('<1384807685.16852.82.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 20:48:05',0,'2013-11-18 20:48:05',NULL,'[openstack-dev] [Nova][db] Changing migrations','On Mon, 2013-11-18 at 18:46 +0100, Nikola ?ipanov wrote:\n> Dear OpenStack devs,\n> \n> A recent review [1] dragged into spotlight how damaging improper use of\n> external code inside migrations can be.\n> \n> Basically in my mind the incident raises 2 issues that I think we should\n> look into:\n> \n> 1) How can we make reviewing changes with db migrations more robust\n> \n> Since we use sqlalchemy-migrate to version our database, the package\'s\n> documentation [2] states how care needs to be taken when importing code\n> inside a db migration script. It seems like this can be taken care of\n> with a hacking rule that will fail the patch if anything outside a\n> subset of modules is imported and used. I might be missing an angle\n> where such an approach could cause issues, so feel free to comment in\n> replies. IIUC - this is something we might want to enforce even when/if\n> we move to using Alembic for migrations.\n> \n> 2) What are acceptable changes\n> \n> The patch also raised the question of what is acceptable level of\n> changes. The only guidelines I could find are [3] and they seem fuzzy\n> enough that we might want to be more specific, or introduce stricter\n> testing guidelines.\n> \n> All comments are more than welcome,\n> \n> Thanks,\n> \n> Nikola\n> \n> [1] https://review.openstack.org/#/c/39929/\n> [2]\n> https://sqlalchemy-migrate.readthedocs.org/en/v0.7.2/versioning.html#edit-the-change-script\n> [3] https://wiki.openstack.org/wiki/DbMigrationChangeGuidelines\n\nThanks for the link Nikola.\n\nIt\'s pretty much as I guessed in the review. The intent is:\n\n  https://sqlalchemy-migrate.readthedocs.org/en/v0.7.2/versioning.html#writing-scripts-with-consistent-behavior\n\n  \"You don?t want your change scripts? behavior changing\"\n\nThat totally makes sense. You don\'t want one version of migration 173 to\ndo something different from another version of migration 173.\n\nOne approach to achieving consistent behaviour is to only import library\nAPIs whose behaviour never changes and never change the migration\'s\ncode.\n\nAnother approach is to carefully review any changes which have the\npotential to cause migration behaviour changes.\n\nAnother approach is to add tests for the behaviour so that if you can\'t\naccidentally change the behaviour.\n\nThe point is we need to be careful to avoid changes in behaviour. By all\nmeans, let\'s have guidelines which capture our experience around how\nbest to do that ... but let\'s not pick one of those approaches and\nenforce it in such a way that leaves no room to - if needed - use a\ndifferent approach to achieve the same thing.\n\nThis isn\'t a question of style, where multiple approaches are valid and\nwe just need to pick one to avoid nitpicking and arbitrary\ninconsistency.\n\nMark.\n\n\n\n','<528A526F.8050002@redhat.com>',NULL),('<1384807943.16852.85.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 20:52:23',0,'2013-11-18 20:52:23',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','On Mon, 2013-11-18 at 18:22 +0000, Joshua Harlow wrote:\n> I see it as important (and not theoretical).\n> \n> I\'d like to use oslo.messaging (and oslo.messaging.rpc) in taskflow (to\n> prototype how a distributed engine would work using it) and bringing in a\n> library which requires global configuration is almost a non-starter for\n> me. Although taskflow is targeted at being used in openstack it still is a\n> generic library and a library shouldn\'t bring in dependencies which are\n> only configurable in 1 manner (via a global config via oslo.cfg); to me\n> that?s bad style & forces an ideology on users of taskflow (which limits\n> adoption).\n\nThere is no requirement for global configuration.\n\nHack up a prototype of how you want to use this, show me how you want it\nto be configured, what your ideal API is ... more than happy to discuss\nwell informed specifics.\n\nMark.\n\n\n\n','<CEAF987C.4D249%harlowja@yahoo-inc.com>',NULL),('<1384815239.16852.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 22:53:59',0,'2013-11-18 22:53:59',NULL,'[openstack-dev] [Cinder][Glance] OSLO update','On Mon, 2013-11-18 at 17:24 +0000, Duncan Thomas wrote:\n> Random OSLO updates with no list of what changed, what got fixed etc\n> are unlikely to get review attention - doing such a review is\n> extremely difficult. I was -2ing them and asking for more info, but\n> they keep popping up. I\'m really not sure what the best way of\n> updating from OSLO is, but this isn\'t it.\n\nBest practice is to include a list of changes being synced, for example:\n\n  https://review.openstack.org/54660\n\nEvery so often, we throw around ideas for automating the generation of\nthis changes list - e.g. cinder would have the oslo-incubator commit ID\nfor each module stored in a file in git to tell us when it was last\nsynced.\n\nMark.\n\n\n\n','<CAOyZ2aEUXeJ2TX0vkX0w6Tjv=3q4XyPvLWgtXMkrVvs9DLtOAA@mail.gmail.com>',NULL),('<1384816375.16852.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 23:12:55',0,'2013-11-18 23:12:55',NULL,'[openstack-dev] Incubation request for Manila','Hi,\n\nOn Thu, 2013-10-10 at 15:00 +0000, Swartzlander, Ben wrote:\n> Please consider our formal request for incubation status of the Manila project:\n> https://wiki.openstack.org/wiki/Manila_Overview\n\nNote that the Manila application was discussed at last week\'s TC\nmeeting.\n\nI tried to take some notes here:\n\n  https://etherpad.openstack.org/p/ManilaIncubationApplication\n\nbut the full logs are at:\n\n  http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-11-12-20.01.html\n\nFinal discussion and voting on the application is due to happen at\ntomorrow\'s meeting.\n\nMark.\n\n\n\n','<53E7920A93307949AC19339A21136DC91371EBFE@SACEXCMBX01-PRD.hq.netapp.com>',NULL),('<1384816375.16852.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-11-18 23:12:55',0,'2013-11-18 23:12:55',NULL,'[openstack-tc] [openstack-dev] Incubation request for Manila','Hi,\n\nOn Thu, 2013-10-10 at 15:00 +0000, Swartzlander, Ben wrote:\n> Please consider our formal request for incubation status of the Manila project:\n> https://wiki.openstack.org/wiki/Manila_Overview\n\nNote that the Manila application was discussed at last week\'s TC\nmeeting.\n\nI tried to take some notes here:\n\n  https://etherpad.openstack.org/p/ManilaIncubationApplication\n\nbut the full logs are at:\n\n  http://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-11-12-20.01.html\n\nFinal discussion and voting on the application is due to happen at\ntomorrow\'s meeting.\n\nMark.\n\n\n\n','<53E7920A93307949AC19339A21136DC91371EBFE@SACEXCMBX01-PRD.hq.netapp.com>',NULL),('<1384818732-sup-327@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 15:59:47',-28800,'2013-11-18 23:59:47',NULL,'[openstack-dev] Introducing the new OpenStack service for\n	Containers','Excerpts from Sam Alba\'s message of 2013-11-18 14:05:47 -0800:\n> Hello everyone,\n> \n> As some of you already know - in Hong-Kong during the last OpenStack\n> Summit - we ran a design session in the Nova topic titled \"Docker\n> support in OpenStack\". The session concluded in developing a new\n> OpenStack service for supporting containers instead of modifying Nova\n> to support both VMs and containers.\n> \n> As said earlier, I am proposing a first draft of the spec for the\n> service. I\'ve explicitly CC\'ed all people who signed up at the end of\n> the design session.\n> \n> Here is it: https://etherpad.openstack.org/p/containers-service\n> \n> Once we agree on the HTTP API and on the plugin API, the idea is to\n> implement a first simple version that would support mono-host. Then it\n> would evolve in multi-host really quickly by adding a scheduler and a\n> messaging layer (more details in the etherpad).\n> \n\nThis is cool and I agree that having containers as a service makes more\nsense for a number of reasons.\n\nHowever, you have not included any concrete use cases in the etherpad\nabove.\n\nThings without real world use cases tend to devolve quickly into coding\nparties IMO. \"Oh look at the lovely spec and implementation we are\nmaking.\" Meanwhile the real users with real use cases are hard to get\nright and thus end up going elsewhere because they are \"proposing hacks\".\n\nAlso, I would love to see the first implementation of multi-node take\nthe gearman route and just have \"workers\" (compute-equivalent) register\ntheir container capabilities and clients (API servers) push container\njobs into those capability queues.\n\n\n','<CAJv9qeQ1ZVLD0yM-GQzfeJjoVEm_jqS+-SPDgHj85G6cMf54nw@mail.gmail.com>',NULL),('<1384819714.9583.3.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 16:08:34',-28800,'2013-11-19 00:08:34',NULL,'[openstack-dev] [Nova] Does Nova really need an SQL database?','On Mon, 2013-11-18 at 14:09 -0800, Joe Gordon wrote:\n> \n> Phil Day discussed this at the summit and I have finally gotten around\n> to posting a POC of this. \n> \n> https://review.openstack.org/#/c/57053/\n\nHi, Joe, why you think the DB is not exact state in your followed commit\nmessage? I think the DB is updated to date by resource tracker, am I\nright (the resource tracker get the underlying resource information\nperiodically but I think that information is mostly static). And I think\nthe scheduler retry mainly comes from the race condition of multiple\nscheduler instance.\n\n\"We already have the concept that the DB isn\'t the exact state of the\nworld, right now it\'s updated every 10 seconds. And we use the scheduler\nretry mechanism to handle cases where the scheduler was wrong. \"\n\n\n\n','<CAHXdxOfiW5yjCc+EcLRjeo+z-dT3K7MkKddBFamzGJT04KG+CA@mail.gmail.com>',NULL),('<1384820224.9583.5.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 16:17:04',-28800,'2013-11-19 00:17:04',NULL,'[openstack-dev] [nova][object] One question to the resource\n tracker session','On Fri, 2013-11-15 at 22:42 +0000, Jiang, Yunhong wrote:\n> I have no particular part thus any part that need help is ok for me.\n> \n> My own purpose is to support dynamic resource claim to support live migration to instance with hardware allocated. For instance with device assigned (PCI device, USB or everything), we can\'t migrate it unless it\'s unplugged.\n> \n> Also currently the resource tracker is more than tracker, it in fact also update host to the instance, which I assume should be done by conducto. It even create the migration object, which I  think should also be created by conductor. IIUC, the reason is to keep the atomic operation to avoid race with the audit. \n> \n> Combine the above two, I\'m considering if we can change current resource tracker. Instead of passing the instance/flavor, a new object, resource requirement is used.  The process is: the conductor calculate the resource requirement for the instance on both building and resize , and passing it to the resource tracker, the resource tracker will add the hypervisor overhead, and then claim it. If the claim is success, the resource tracker save this resource requirement to the database.\n> \n> For build time, this should work well. For resize, this should also work, only that the instance will have two resource requirement. And there will be no race condition here. Other than that, another benefit is, the resource tracker don\'t need care for the flavor anymore. I\'m not sure if we can totally remove the new_/old_ flavor information in system_metadata, but we can move the key user of it.\n> \n> Your opinion?\n> \n\nPaul/Andrew, I created a documentation about my idea at\nhttps://docs.google.com/document/d/1gI_GE0-H637lTRIyn2UPfQVebfk5QjDi6ohObt6MIc0 , can you have a look on it?\n\nThanks\n--jyh\n\n\n\n','<DDCAE26804250545B9934A2056554AA01FBC7916@ORSMSX108.amr.corp.intel.com>',NULL),('<1384823926.9583.9.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 17:18:46',-28800,'2013-11-19 01:18:46',NULL,'[openstack-dev] [Nova] Does Nova really need an SQL database?','On Mon, 2013-11-18 at 15:32 -0800, Joe Gordon wrote:\n> \n> \n> \n> On Mon, Nov 18, 2013 at 4:08 PM, yunhong jiang\n> <yunhong.jiang at linux.intel.com> wrote:\n>         On Mon, 2013-11-18 at 14:09 -0800, Joe Gordon wrote:\n>         >\n>         > Phil Day discussed this at the summit and I have finally\n>         gotten around\n>         > to posting a POC of this.\n>         >\n>         > https://review.openstack.org/#/c/57053/\n>         \n>         \n>         Hi, Joe, why you think the DB is not exact state in your\n>         followed commit\n>         message? I think the DB is updated to date by resource\n>         tracker, am I\n>         right (the resource tracker get the underlying resource\n>         information\n>         periodically but I think that information is mostly static).\n>         And I think\n>         the scheduler retry mainly comes from the race condition of\n>         multiple\n>         scheduler instance.\n> \n> \n> \n> \n> You answered the question yourself, the compute nodes (indirectly)\n> update the DB periodically, so the further you are from the last\n> periodic update the less up to date the DB is.\n> \nBut the compute node will also update the DB if any claim changes\nbetween the period, and also considering currently the resource tracker\ncalculate the instance usage (like RAM, core etc) itself instead of\ndepends on hyper-visor report, I think the DB information should be\nconsidered mostly up to date.\n\nOf course, I\'m not against the information cache.\n\n--jyh\n> \n> Its there for both reasons.  But yes it was originally put there\n> because of the multi scheduler race condition.\n>  \n>         \n>         \"We already have the concept that the DB isn\'t the exact state\n>         of the\n>         world, right now it\'s updated every 10 seconds. And we use the\n>         scheduler\n>         retry mechanism to handle cases where the scheduler was wrong.\n>         \"\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAHXdxOfYE9FtBUb_LLX-VHNff8cn-pitz=yqDGyaRfaDqJWB=g@mail.gmail.com>',NULL),('<1384834982.89472.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-19 12:23:02',28800,'2013-11-19 04:23:02',NULL,'[Openstack] problem in starting swift','hello Zhang\n\nI follow the steps mentioned in the link given by you.\nbut the error is still there.\n\nPlease help.\n\n\n\n\n\nOn Monday, 18 November 2013 10:04 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote:\n \ntry work-around on ask.openstack.org here: \n>	* https://ask.openstack.org/en/question/4996/importerror-running-swift/\n>\n>pragya jain ---2013-11-18 ?? 03:37:20---pragya jain <prag_2648 at yahoo.co.in>\n>\n>\n>pragya jain <prag_2648 at yahoo.co.in>? \n>2013-11-18 ?? 03:05 \n>Please respond to\n>pragya jain <prag_2648 at yahoo.co.in>  \n>\n>To \n>Hua ZZ Zhang/China/IBM at IBMCN  \n>\n>\n>cc \n>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>  \n>\n>\n>Subject \n>Re: [Openstack] problem in starting swift     \n>\n>Thanks?Zhang\n>\n>root at arun-Aspire-5742:~# pico /root/swift/swift/common/middleware/recon.py\n>it shows the file at the place\n>\n>\n>On Monday, 18 November 2013 4:32 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote: Make sure module of recon is in place under this path and can be accessible:\n>/root/swift/swift/common/middleware/recon.py\n>\n>-Edward\n>\n>\n>pragya jain ---2013-11-17 ?? 06:49:40---pragya jain <prag_2648 at yahoo.co.in>\n> \n>pragya jain <prag_2648 at yahoo.co.in>??\n>2013-11-17 ?? 06:41?\n>\n>\n>Please respond to\n>pragya jain <prag_2648 at yahoo.co.in>  To \n>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>? \n>cc  \n>Subject \n>[Openstack] problem in starting swift?    \n>hi all,\n>\n>I am installing swift on my system using the guidelines given in the link \n>http://docs.openstack.org/developer/swift/development_saio.html\n>\n>when Setting up scripts for running Swift\n>at the command \n>root at arun-Aspire-5742:~# startmain\n>\n>I got the following error:\n>http://paste.openstack.org/show/53458/\n>\n>please help me to overcome this problem.\n>\n>Thanks in advance \n>\n>Pragya Jain\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131119/4058466a/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131119/4058466a/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ecblank.gif\nType: image/gif\nSize: 45 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131119/4058466a/attachment-0001.gif>\n\n','<OFFAD2CDC3.F21DD15F-ON48257C27.002C3124-48257C27.002C5F2D@cn.ibm.com>',NULL),('<1384855310.25106.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-19 10:01:50',0,'2013-11-19 10:01:50',NULL,'[Openstack] Need help - Compute Node restarted - Ramdom\n	Instances doesn\'t get and IP anymore','Hi Thiago,\n\nI did a qucik test with Havana on Ubuntu 12.04 with QEMU, OVS 1.10.2 and the OVS hybrid driver. Started an instance, rebooted the compute node, and the instance goes to status STOPPED. Then ran \'nova start instance-name\', and it starts ok, but DHCP does not work.\n\nIn the logs I see OVS starting first and recreating the qvoxxxxxx-xx port and interface from its database. Then nova-compute starts and creates the qbr Linux bridge and qvb interface, but it is not recreating the? qvo port and interface because they already exist.? Everything looks ok, and the DHCP requests are getting to qvo, but they are not getting into br-int.\n\nIt seems the qvo interface needs to be created by Nova (using the ip command) before the OVS port is created with the same name. Otherwise OVS does not seem to enslave the interface. \n\nI added this upstart script to run cleanup which will delete the ports on br-int before nova-compute and the OVS agent start:\n\nroot at compute1:~# cat /etc/init/neutron-ovs-cleanup.conf \nstart on starting nova-compute or neutron-plugin-openvswitch-agent\nscript\n? /usr/bin/neutron-ovs-cleanup\nend script\n\nNow nova-compute has to recreate everything, and the instance is getting an IP with DHCP. Maybe you can try this out in your test environment.\n\nRe, Darragh.\n\n\n\n>Guys,\n>\n>My Havana (Ubuntu based) Compute Node was restarted and lots of Instances\n>does not get an IP anymore.\n>\n>Tips?!\n>\n>It is ramdom, I mean, some instances of this same compute node are normal,\n>while others have no IP.\n>\n>I really need help here because my client\'s web site is completely off line\n>now...\n>\n>I\'m using Per-Tenant router with private networks + VXLAN.\n>\n>Tks!\n>Thiago\n\n\n',NULL,NULL),('<1384878640-sup-166@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 08:33:42',-28800,'2013-11-19 16:33:42',NULL,'[openstack-dev] [Neutron][LBaaS] SSL Termination write-up','Excerpts from Vijay Venkatachalam\'s message of 2013-11-19 05:48:43 -0800:\n> Hi Sam, Eugene, & Avishay, etal,\n> \n>                 Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments!\n> \n> https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit\n> \n> Would like comments/discussion especially on the following note:\n> \n> SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don\'t store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller.\n> \n> I would expect the certificates to become an independent resource in future thereby causing backward compatibility issues.\n> \n\nPerhaps Barbican can be leveraged for this, it seems that it was\nspecifically designed for the use case. Quoting from their README:\n\nDesign Goals\n\n 1. Provide a central secret-store capable of distributing secret / keying material to all types of deployments including ephemeral Cloud instances.\n 2. Support reasonable compliance regimes through reporting and auditability.\n 3. Application adoption costs should be minimal or non-existent.\n 4. Build a community and ecosystem by being open-source and extensible.\n 5. Improve security through sane defaults and centralized management of policies for all secrets.\n 6. Out of band communication mechanism to notify and protect sensitive assets.\n\nhttps://github.com/stackforge/barbican\n\n\n','<26B082831A2B1A4783604AB89B9B2C080DE2DC81@SINPEX01CL03.citrite.net>',NULL),('<1384883024-sup-1571@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 10:03:47',-28800,'2013-11-19 18:03:47',NULL,'[openstack-dev] [Heat] Continue discussing multi-region\n	orchestration','Excerpts from Zane Bitter\'s message of 2013-11-15 12:41:53 -0800:\n> Good news, everyone! I have created the missing whiteboard diagram that \n> we all needed at the design summit:\n> \n> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram\n> \n> I\'ve documented 5 possibilities. (1) is the current implementation, \n> which we agree we want to get away from. I strongly favour (2) for the \n> reasons listed. I don\'t think (3) has many friends. (4) seems to be \n> popular despite the obvious availability problem and doubts that it is \n> even feasible. Finally, I can save us all some time by simply stating \n> that I will -2 on sight any attempt to implement (5).\n> \n> When we\'re discussing this, please mention explicitly the number of the \n> model you are talking about at any given time.\n> \n> If you have a suggestion for a different model, make your own diagram! \n> jk, you can sketch it or something for me and I\'ll see if I can add it.\n\nThanks for putting this together Zane. I just now got around to looking\nclosely.\n\nOption 2 is good. I\'d love for option 1 to be made automatic by making\nthe client smarter, but parsing templates in the client will require\nsome deep thought before we decide it is a good idea.\n\nI\'d like to consider a 2a, which just has the same Heat engines the user\nis talking to being used to do the orchestration in whatever region\nthey are in. I think that is actually the intention of the diagram,\nbut it looks like there is a \"special\" one that talks to the engines\nthat actually do the work.\n\n2 may morph into 3 actually, if users don\'t like the nested stack\nrequirement for 2, we can do the work to basically make the engine create\na nested stack per region. So that makes 2 a stronger choice for first\nimplementation.\n\n4 has an unstated pro, which is that attack surface is reduced. This\nmakes more sense when you consider the TripleO case where you may want\nthe undercloud (hardware cloud) to orchestrate things existing in the\novercloud (vm cloud) but you don\'t want the overcloud administrators to\nbe able to control your entire stack.\n\nGiven CAP theorem, option 5, the global orchestrator, would be doable\nwith not much change as long as partition tolerance were the bit we gave\nup. We would just have to have a cross-region RPC bus and database. Of\ncourse, since regions are most likely to be partitioned, that is not\nreally a good choice. Trading partition tolerance for consistency lands\nus in the complexity black hole. Trading out availability makes it no\nbetter than option 4.\n\n\n','<52868711.5070900@redhat.com>',NULL),('<1384884165.18698.50.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 10:02:45',-28800,'2013-11-19 18:02:45',NULL,'[openstack-dev] Introducing the new OpenStack service for\n Containers','On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:\n> Hey all\n> \n> Not having been at the summit (maybe the next one), could somebody\n> give a really short explanation as to why it needs to be a separate\n> service?\n> It sounds like it should fit within the Nova area. It is, after all,\n> just another hypervisor type, or so it seems.\n\nI can take a stab at this:  Firstly, a container is *not* a hypervisor.\nHypervisor based virtualisation is done at the hardware level (so with\nhypervisors you boot a second kernel on top of the virtual hardware),\ncontainer based virtualisation is done at the OS (kernel) level (so all\ncontainers share the same kernel ... and sometimes even huge chunks of\nthe OS). With recent advances in the Linux Kernel, we can make a\ncontainer behave like a hypervisor (full OS/IaaS virtualisation), but\nquite a bit of the utility of containers is that they can do much more\nthan hypervisors, so they shouldn\'t be constrained by hypervisor APIs\n(which are effectively virtual hardware APIs).\n\nIt is possible to extend the Nova APIs to control containers more fully,\nbut there was resistance do doing this on the grounds that it\'s\nexpanding the scope of Nova, hence the new project.\n\nJames\n\n\n\n\n','<2F6B0AEE-1044-4072-92F2-1F8BC90F1C23@demonware.net>',NULL),('<1384885094.9583.12.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 10:18:14',-28800,'2013-11-19 18:18:14',NULL,'[openstack-dev] [nova] Core pinning','On Tue, 2013-11-19 at 12:52 +0000, Daniel P. Berrange wrote:\n> On Wed, Nov 13, 2013 at 02:46:06PM +0200, Tuomas Paappanen wrote:\n> > Hi all,\n> > \n> > I would like to hear your thoughts about core pinning in Openstack.\n> > Currently nova(with qemu-kvm) supports usage of cpu set of PCPUs\n> > what can be used by instances. I didn\'t find blueprint, but I think\n> > this feature is for isolate cpus used by host from cpus used by\n> > instances(VCPUs).\n> > \n> > But, from performance point of view it is better to exclusively\n> > dedicate PCPUs for VCPUs and emulator. In some cases you may want to\n> > guarantee that only one instance(and its VCPUs) is using certain\n> > PCPUs.  By using core pinning you can optimize instance performance\n> > based on e.g. cache sharing, NUMA topology, interrupt handling, pci\n> > pass through(SR-IOV) in multi socket hosts etc.\n> > \n> > We have already implemented feature like this(PoC with limitations)\n> > to Nova Grizzly version and would like to hear your opinion about\n> > it.\n> > \n> > The current implementation consists of three main parts:\n> > - Definition of pcpu-vcpu maps for instances and instance spawning\n> > - (optional) Compute resource and capability advertising including\n> > free pcpus and NUMA topology.\n> > - (optional) Scheduling based on free cpus and NUMA topology.\n> > \n> > The implementation is quite simple:\n> > \n> > (additional/optional parts)\n> > Nova-computes are advertising free pcpus and NUMA topology in same\n> > manner than host capabilities. Instances are scheduled based on this\n> > information.\n> > \n> > (core pinning)\n> > admin can set PCPUs for VCPUs and for emulator process, or select\n> > NUMA cell for instance vcpus, by adding key:value pairs to flavor\'s\n> > extra specs.\n> > \n> > EXAMPLE:\n> > instance has 4 vcpus\n> > <key>:<value>\n> > vcpus:1,2,3,4 --> vcpu0 pinned to pcpu1, vcpu1 pinned to pcpu2...\n> > emulator:5 --> emulator pinned to pcpu5\n> > or\n> > numacell:0 --> all vcpus are pinned to pcpus in numa cell 0.\n> > \n> > In nova-compute, core pinning information is read from extra specs\n> > and added to domain xml same way as cpu quota values(cputune).\n> > \n> > <cputune>\n> >       <vcpupin vcpu=\'0\' cpuset=\'1\'/>\n> >       <vcpupin vcpu=\'1\' cpuset=\'2\'/>\n> >       <vcpupin vcpu=\'2\' cpuset=\'3\'/>\n> >       <vcpupin vcpu=\'3\' cpuset=\'4\'/>\n> >       <emulatorpin cpuset=\'5\'/>\n> > </cputune>\n> > \n> > What do you think? Implementation alternatives? Is this worth of\n> > blueprint? All related comments are welcome!\n> \n> I think there are several use cases mixed up in your descriptions\n> here which should likely be considered independantly\n> \n>  - pCPU/vCPU pinning\n> \n>    I don\'t really think this is a good idea as a general purpose\n>    feature in its own right. It tends to lead to fairly inefficient\n>    use of CPU resources when you consider that a large % of guests\n>    will be mostly idle most of the time. It has a fairly high\n>    administrative burden to maintain explicit pinning too. This\n>    feels like a data center virt use case rather than cloud use\n>    case really.\n> \n>  - Dedicated CPU reservation\n> \n>    The ability of an end user to request that their VM (or their\n>    group of VMs) gets assigned a dedicated host CPU set to run on.\n>    This is obviously something that would have to be controlled\n>    at a flavour level, and in a commercial deployment would carry\n>    a hefty pricing premium.\n> \n>    I don\'t think you want to expose explicit pCPU/vCPU placement\n>    for this though. Just request the high level concept and allow\n>    the virt host to decide actual placement\n> \n>  - Host NUMA placement.\n> \n>    By not taking NUMA into account currently the libvirt driver\n>    at least is badly wasting resources. Having too much cross-numa\n>    node memory access by guests just kills scalability. The virt\n>    driver should really automaticall figure out cpu & memory pinning\n>    within the scope of a NUMA node automatically. No admin config\n>    should be required for this.\n> \n>  - Guest NUMA topology\n> \n>    If the flavour memory size / cpu count exceeds the size of a\n>    single NUMA node, then the flavour should likely have a way to\n>    express that the guest should see multiple NUMA nodes. The\n>    virt host would then set guest NUMA topology to match the way\n>    it places vCPUs & memory on host NUMA nodes. Again you don\'t\n>    want explicit pcpu/vcpu mapping done by the admin for this.\n> \n> \n> \n> Regards,\n> Daniel\n\nQuite clear splitting and +1 for P/V pin option.\n\n--jyh\n\n\n\n\n','<20131119125213.GJ23854@redhat.com>',NULL),('<1384885883-sup-6253@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 10:35:27',-28800,'2013-11-19 18:35:27',NULL,'[openstack-dev] [Nova] Does Nova really need an SQL database?','Excerpts from Chris Friesen\'s message of 2013-11-19 09:29:00 -0800:\n> On 11/18/2013 06:47 PM, Joshua Harlow wrote:\n> > An idea related to this, what would need to be done to make the DB have\n> > the exact state that a compute node is going through (and therefore the\n> > scheduler would not make unreliable/racey decisions, even when there are\n> > multiple schedulers). It\'s not like we are dealing with a system which\n> > can not know the exact state (as long as the compute nodes are connected\n> > to the network, and a network partition does not occur).\n> \n> How would you synchronize the various schedulers with each other? \n> Suppose you have multiple scheduler nodes all trying to boot multiple \n> instances each.\n> \n> Even if each at the start of the process each scheduler has a perfect \n> view of the system, each scheduler would need to have a view of what \n> every other scheduler is doing in order to not make racy decisions.\n> \n\nYour question assumes they need to be \"in sync\" at a granular level.\n\nEach scheduler process can own a different set of resources. If they\neach grab instance requests in a round-robin fashion, then they will\nfill their resources up in a relatively well balanced way until one\nscheduler\'s resources are exhausted. At that time it should bow out of\ntaking new instances. If it can\'t fit a request in, it should kick the\nrequest out for retry on another scheduler.\n\nIn this way, they only need to be in sync in that they need a way to\nagree on who owns which resources. A distributed hash table that gets\nrefreshed whenever schedulers come and go would be fine for that.\n\n\n','<528B9FDC.2040608@windriver.com>',NULL),('<1384888067.17335.9.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 11:07:47',-28800,'2013-11-19 19:07:47',NULL,'[openstack-dev] Introducing the new OpenStack service for\n Containers','On Tue, 2013-11-19 at 13:46 -0500, Eric Windisch wrote:\n> On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley\n> <James.Bottomley at hansenpartnership.com> wrote:\n> > On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:\n> >> Hey all\n> >>\n> >> Not having been at the summit (maybe the next one), could somebody\n> >> give a really short explanation as to why it needs to be a separate\n> >> service?\n> >> It sounds like it should fit within the Nova area. It is, after all,\n> >> just another hypervisor type, or so it seems.\n> >\n> > I can take a stab at this:  Firstly, a container is *not* a hypervisor.\n> > Hypervisor based virtualisation is done at the hardware level (so with\n> > hypervisors you boot a second kernel on top of the virtual hardware),\n> > container based virtualisation is done at the OS (kernel) level (so all\n> > containers share the same kernel ... and sometimes even huge chunks of\n> > the OS). With recent advances in the Linux Kernel, we can make a\n> > container behave like a hypervisor (full OS/IaaS virtualisation), but\n> > quite a bit of the utility of containers is that they can do much more\n> > than hypervisors, so they shouldn\'t be constrained by hypervisor APIs\n> > (which are effectively virtual hardware APIs).\n> >\n> > It is possible to extend the Nova APIs to control containers more fully,\n> > but there was resistance do doing this on the grounds that it\'s\n> > expanding the scope of Nova, hence the new project.\n> \n> It might be worth noting that it was also brought up that\n> hypervisor-based virtualization can offer a number of features that\n> bridge some of these gaps, but are not supported in, nor may ever be\n> supported in Nova.\n> \n> For example, Daniel brings up an interesting point with the\n> libvirt-sandbox feature. This is one of those features that bridges\n> some of the gaps. There are also solutions, however brittle, for\n> introspection that work on hypervisor-driven VMs. It is not clear what\n> the scope or desire for these features might be, how they might be\n> sufficiently abstracted between hypervisors and guest OSes, nor how\n> these would fit into any of the existing or planned compute API\n> buckets.\n\nIt\'s certainly possible, but some of them are possible in the same way\nas it\'s possible to get a square peg into a round hole by beating the\ncorners flat with a sledge hammer ... it works, but it\'s much less\nhassle just to use a round peg because it actually fits the job.\n\n> Having a separate service for managing containers draws a thick line\n> in the sand that will somewhat stiffen innovation around\n> hypervisor-based virtualization. That isn\'t necessarily a bad thing,\n> it will help maintain stability in the project. However, the choice\n> and the implications shouldn\'t be ignored.\n\nHow about this: we get the container API agreed and we use a driver\nmodel like Nova (we have to anyway since there about four different\ncontainer technologies interested in this), then we see if someone wants\nto do a hypervisor driver emulating the features.\n\nJames\n\n\n\n\n','<CALnZm-Ys8PORYcM8Th=4kHp-Sw0c_MUH6=cj-3bkDS=Szg9ydQ@mail.gmail.com>',NULL),('<1384890019.3541.12.camel@pafuent-mobl4>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 19:40:21',0,'2013-11-19 19:40:21',NULL,'[openstack-dev] [Heat] Version Negotiation Middleware Accept Header\n issue','Hi,\n	I noticed that the Accept HTTP Header checked in the Version\nNegotiation Middleware by Heat is the same MIME type used by Glance\n(\"application/vnd.openstack.images-\")\n	Is this OK, or should it be something like\n\"application/vnd.openstack.orchestration-\"?\n	If this is the case I would proceed to file a bug.\n\nThanks.\nPablo.\n\n',NULL,NULL),('<1384890442-sup-3738@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 11:51:23',-28800,'2013-11-19 19:51:23',NULL,'[openstack-dev] [Nova] Does Nova really need an SQL database?','Excerpts from Chris Friesen\'s message of 2013-11-19 11:37:02 -0800:\n> On 11/19/2013 12:35 PM, Clint Byrum wrote:\n> \n> > Each scheduler process can own a different set of resources. If they\n> > each grab instance requests in a round-robin fashion, then they will\n> > fill their resources up in a relatively well balanced way until one\n> > scheduler\'s resources are exhausted. At that time it should bow out of\n> > taking new instances. If it can\'t fit a request in, it should kick the\n> > request out for retry on another scheduler.\n> >\n> > In this way, they only need to be in sync in that they need a way to\n> > agree on who owns which resources. A distributed hash table that gets\n> > refreshed whenever schedulers come and go would be fine for that.\n> \n> That has some potential, but at high occupancy you could end up refusing \n> to schedule something because no one scheduler has sufficient resources \n> even if the cluster as a whole does.\n> \n\nI\'m not sure what you mean here. What resource spans multiple compute\nhosts?\n\n> This gets worse once you start factoring in things like heat and \n> instance groups that will want to schedule whole sets of resources \n> (instances, IP addresses, network links, cinder volumes, etc.) at once \n> with constraints on where they can be placed relative to each other.\n> \n\nActually that is rather simple. Such requests have to be serialized\ninto a work-flow. So if you say \"give me 2 instances in 2 different\nlocations\" then you allocate 1 instance, and then another one with\n\'not_in_location(1)\' as a condition.\n\n\n','<528BBDDE.70709@windriver.com>',NULL),('<1384890870-sup-6012@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 12:50:48',-28800,'2013-11-19 20:50:48',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Steve Baker\'s message of 2013-11-18 12:52:04 -0800:\n> \n> Regarding apply_config/remove_config, if a SoftwareApplier resource is\n> deleted it should trigger any remove_config and wait for the server to\n> acknowledge when that is complete. This allows for any\n> evacuation/deregistering workloads to be executed.\n> \n\nI\'m a little worried about the road that leads us down. Most configuration\nsoftware defines forward progress only. Meaning, if you want something\nnot there, you don\'t remove it from your assertions, you assert that it\nis not there.\n\nThe reason this is different than the way we operate with resources is\nthat resources are all under Heat\'s direct control via well defined\nAPIs. In-instance things, however, will be indirectly controlled. So I\nfeel like focusing on a \"diff\" mechanism for user-deployed tools may be\nunnecessary and might confuse. I\'d much rather have a \"converge\"\nmechanism for the users to focus on.\n\n\n','<528A7DF4.1060303@redhat.com>',NULL),('<1384896002-sup-7668@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 13:28:31',-28800,'2013-11-19 21:28:31',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Steve Baker\'s message of 2013-11-19 13:06:21 -0800:\n> On 11/20/2013 09:50 AM, Clint Byrum wrote:\n> > Excerpts from Steve Baker\'s message of 2013-11-18 12:52:04 -0800:\n> >> Regarding apply_config/remove_config, if a SoftwareApplier resource is\n> >> deleted it should trigger any remove_config and wait for the server to\n> >> acknowledge when that is complete. This allows for any\n> >> evacuation/deregistering workloads to be executed.\n> >>\n> > I\'m a little worried about the road that leads us down. Most configuration\n> > software defines forward progress only. Meaning, if you want something\n> > not there, you don\'t remove it from your assertions, you assert that it\n> > is not there.\n> >\n> > The reason this is different than the way we operate with resources is\n> > that resources are all under Heat\'s direct control via well defined\n> > APIs. In-instance things, however, will be indirectly controlled. So I\n> > feel like focusing on a \"diff\" mechanism for user-deployed tools may be\n> > unnecessary and might confuse. I\'d much rather have a \"converge\"\n> > mechanism for the users to focus on.\n> >\n> >\n> A specific use-case I\'m trying to address here is tripleo doing an\n> update-replace on a nova compute node. The remove_config contains the\n> workload to evacuate VMs and signal heat when the node is ready to be\n> shut down. This is more involved than just \"uninstall the things\".\n> \n> Could you outline in some more detail how you think this could be done?\n> \n\nSo for that we would not remove the software configuration for the\nnova-compute, we would assert that the machine needs vms evacuated.\nWe want evacuation to be something we explicitly do, not a side effect\nof deleting things. Perhaps having delete hooks for starting delete\nwork-flows is right, but it set off a red flag for me so I want to make\nsure we think it through.\n\nAlso IIRC, evacuation is not necessarily an in-instance thing. It looks\nmore like the weird thing we\'ve been talking about lately which is\n\"how do we orchestrate tenant API\'s\":\n\nhttps://etherpad.openstack.org/p/orchestrate-tenant-apis\n\n\n','<528BD2CD.3040904@redhat.com>',NULL),('<1384904700-sup-1893@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 16:08:47',-28800,'2013-11-20 00:08:47',NULL,'[openstack-dev] [Nova] Does Nova really need an SQL database?','Excerpts from Chris Friesen\'s message of 2013-11-19 12:18:16 -0800:\n> On 11/19/2013 01:51 PM, Clint Byrum wrote:\n> > Excerpts from Chris Friesen\'s message of 2013-11-19 11:37:02 -0800:\n> >> On 11/19/2013 12:35 PM, Clint Byrum wrote:\n> >>\n> >>> Each scheduler process can own a different set of resources. If they\n> >>> each grab instance requests in a round-robin fashion, then they will\n> >>> fill their resources up in a relatively well balanced way until one\n> >>> scheduler\'s resources are exhausted. At that time it should bow out of\n> >>> taking new instances. If it can\'t fit a request in, it should kick the\n> >>> request out for retry on another scheduler.\n> >>>\n> >>> In this way, they only need to be in sync in that they need a way to\n> >>> agree on who owns which resources. A distributed hash table that gets\n> >>> refreshed whenever schedulers come and go would be fine for that.\n> >>\n> >> That has some potential, but at high occupancy you could end up refusing\n> >> to schedule something because no one scheduler has sufficient resources\n> >> even if the cluster as a whole does.\n> >>\n> >\n> > I\'m not sure what you mean here. What resource spans multiple compute\n> > hosts?\n> \n> Imagine the cluster is running close to full occupancy, each scheduler \n> has room for 40 more instances.  Now I come along and issue a single \n> request to boot 50 instances.  The cluster has room for that, but none \n> of the schedulers do.\n> \n\nYou\'re assuming that all 50 come in at once. That is only one use case\nand not at all the most common.\n\n> >> This gets worse once you start factoring in things like heat and\n> >> instance groups that will want to schedule whole sets of resources\n> >> (instances, IP addresses, network links, cinder volumes, etc.) at once\n> >> with constraints on where they can be placed relative to each other.\n> \n> > Actually that is rather simple. Such requests have to be serialized\n> > into a work-flow. So if you say \"give me 2 instances in 2 different\n> > locations\" then you allocate 1 instance, and then another one with\n> > \'not_in_location(1)\' as a condition.\n> \n> Actually, you don\'t want to serialize it, you want to hand the whole set \n> of resource requests and constraints to the scheduler all at once.\n> \n> If you do them one at a time, then early decisions made with \n> less-than-complete knowledge can result in later scheduling requests \n> failing due to being unable to meet constraints, even if there are \n> actually sufficient resources in the cluster.\n> \n> The \"VM ensembles\" document at\n> https://docs.google.com/document/d/1bAMtkaIFn4ZSMqqsXjs_riXofuRvApa--qo4UTwsmhw/edit?pli=1 \n> has a good example of how one-at-a-time scheduling can cause spurious \n> failures.\n> \n> And if you\'re handing the whole set of requests to a scheduler all at \n> once, then you want the scheduler to have access to as many resources as \n> possible so that it has the highest likelihood of being able to satisfy \n> the request given the constraints.\n\nThis use case is real and valid, which is why I think there is room for\nmultiple approaches. For instance the situation you describe can also be\ndealt with by just having the cloud stay under-utilized and accepting\nthat when you get over a certain percentage utilized spurious failures\nwill happen. We have a similar solution in the ext3 filesystem on Linux.\nDon\'t fill it up, or suffer a huge performance penalty.\n\n\n','<528BC788.8050207@windriver.com>',NULL),('<1384913819.11781239.1417435977062.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 07:12:57',-18000,'2014-12-01 12:12:57',NULL,'[openstack-dev] [neutron] force_gateway_on_subnet,\n please don\'t deprecate','\n\n----- Original Message -----\n> \n> My proposal here, is, _let?s not deprecate this setting_, as it?s a valid use\n> case of a gateway configuration, and let?s provide it on the reference\n> implementation.\n\nI agree. As long as the reference implementation works with the setting off\nthere\'s no need to deprecate it. I still think the default should be set to True\nthough.\n\nKeep in mind that the DHCP agent will need changes as well.\n\n> \n> TL;DR\n> \n> I?ve been looking at this yesterday, during a test deployment\n> on a site where they provide external connectivity with the\n> gateway outside subnet.\n> \n> And I needed to switch it of, to actually be able to have any external\n> connectivity.\n> \n> https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L121\n> \n> This is handled by providing an on-link route to the gateway first,\n> and then adding the default gateway.\n> \n> It looks to me very interesting (not only because it?s the only way to work\n> on that specific site [2][3][4]), because you can dynamically wire RIPE\n> blocks to your server, without needing to use an specific IP for external\n> routing or broadcast purposes, and instead use the full block in openstack.\n> \n> \n> I have a tiny patch to support this on the neutron l3-agent [1] I yet need to\n> add the logic to check ?gateway outside subnet?, then add the ?onlink?\n> route.\n> \n> \n> [1]\n> \n> diff --git a/neutron/agent/linux/interface.py\n> b/neutron/agent/linux/interface.py\n> index 538527b..5a9f186 100644\n> --- a/neutron/agent/linux/interface.py\n> +++ b/neutron/agent/linux/interface.py\n> @@ -116,15 +116,16 @@ class LinuxInterfaceDriver(object):\n> namespace=namespace,\n> ip=ip_cidr)\n> \n> - if gateway:\n> - device.route.add_gateway(gateway)\n> -\n> new_onlink_routes = set(s[\'cidr\'] for s in extra_subnets)\n> + if gateway:\n> + new_onlink_routes.update([gateway])\n> existing_onlink_routes = set(device.route.list_onlink_routes())\n> for route in new_onlink_routes - existing_onlink_routes:\n> device.route.add_onlink_route(route)\n> for route in existing_onlink_routes - new_onlink_routes:\n> device.route.delete_onlink_route(route)\n> + if gateway:\n> + device.route.add_gateway(gateway)\n> \n> def delete_conntrack_state(self, root_helper, namespace, ip):\n> \"\"\"Delete conntrack state associated with an IP address.\n> \n> [2] http://www.soyoustart.com/\n> [3] http://www.ovh.co.uk/\n> [4] http://www.kimsufi.com/\n> \n> \n> Miguel ?ngel Ajo\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<95DCE311E0DE421D8C881E5CCD80E5D8@redhat.com>',NULL),('<1384915934-sup-3222@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-19 18:54:27',-28800,'2013-11-20 02:54:27',NULL,'[openstack-dev] [Nova] New API requirements, review of GCE','Excerpts from Robert Collins\'s message of 2013-11-19 16:22:41 -0800:\n> On 20 November 2013 13:00, Sean Dague <sean at dague.net> wrote:\n> >> As long as the metadataservice doesn\'t move out :) - that one I think\n> >> is pretty core and we have no native replacement [configdrive is not a\n> >> replacement :P].\n> >\n> >\n> > Slightly off tangent thread.\n> >\n> > So we recently moved devstack gate to do con fig drive instead of metadata\n> > service, and life was good (no one really noticed). In what ways is\n> > configdrive insufficient compared to metadata service? And is that something\n> > that we should be tackling?\n> \n> * The metadata service can be trivially updated live - and Heat wants\n> to use this to get rid of it\'s own metadata service... whereas config\n> drive requires unplugging the device, updating the data and replugging\n> - and thats a bit more invasive.\n> \n\nThis one is key. Both Trove and Savanna have run into the same\nlimitation as Heat: networks that cannot reach the API endpoints don\'t\nget to have their API specific Metadata that updates over time. By\nputting it in the EC2 metadata service, we can access it via the Neutron\nproxy and then Heat/Trove/Savanna can update it later to provide a\ncontrol bus for in-instance tools.\n\n\n','<CAJ3HoZ1Cu72nv5m51opC5pbQFvqP7+CjwdLgyt3W9qVHSsAZTw@mail.gmail.com>',NULL),('<1384934719.8.1377670689451.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-28 06:18:09',0,'2013-08-28 06:18:09',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #10','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/10/>\n\n\n\n','<1711834456.6.1377499376379.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1384935624-sup-2119@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 00:29:28',-28800,'2013-11-20 08:29:28',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Thomas Spatzier\'s message of 2013-11-19 23:35:40 -0800:\n> Excerpts from Steve Baker\'s message on 19.11.2013 21:40:54:\n> > From: Steve Baker <sbaker at redhat.com>\n> > To: openstack-dev at lists.openstack.org,\n> > Date: 19.11.2013 21:43\n> > Subject: Re: [openstack-dev] [Heat] HOT software configuration\n> > refined after design summit discussions\n> >\n> <snip>\n> > I think there needs to a CM tool specific agent delivered to the server\n> > which os-collect-config invokes. This agent will transform the config\n> > data (input values, CM script, CM specific specialness) to a CM tool\n> > invocation.\n> >\n> > How to define and deliver this agent is the challenge. Some options are:\n> > 1) install it as part of the image customization/bootstrapping (golden\n> > images or cloud-init)\n> > 2) define a (mustache?) template in the SoftwareConfig which\n> > os-collect-config transforms into the agent script, which\n> > os-collect-config then executes\n> > 3) a CM tool specific implementation of SoftwareApplier builds and\n> > delivers a complete agent to os-collect-config which executes it\n> >\n> > I may be leaning towards 3) at the moment. Hopefully any agent can be\n> > generated with a sufficiently sophisticated base SoftwareApplier type,\n> > plus maybe some richer intrinsic functions.\n> \n> This is good summary of options; about the same we had in mind. And we were\n> also leaning towards 3. Probably the approach we would take is to get a\n> SoftwareApplier running for one CM tool (e.g. Chef), then look at another\n> tool (base shell scripts), and then see what the generic parts art that can\n> be factored into a base class.\n> \n> > >> The POC I\'m working on is actually backed by a REST API which does\n> dumb\n> > >> (but structured) storage of SoftwareConfig and SoftwareApplier\n> entities.\n> > >> This has some interesting implications for managing SoftwareConfig\n> > >> resources outside the context of the stack which uses them, but lets\n> not\n> > >> worry too much about that *yet*.\n> > > Sounds good. We are also defining some blueprints to break down the\n> overall\n> > > software config topic. We plan to share them later this week, and then\n> we\n> > > can consolidate with your plans and see how we can best join forces.\n> > >\n> > >\n> > At this point it would be very helpful to spec out how specific CM tools\n> > are invoked with given inputs, script, and CM tool specific options.\n> \n> That\'s our plan; and we would probably start with scripts and chef.\n> \n> >\n> > Maybe if you start with shell scripts, cfn-init and chef then we can all\n> > contribute other CM tools like os-config-applier, puppet, ansible,\n> > saltstack.\n> >\n> > Hopefully by then my POC will at least be able to create resources, if\n> > not deliver some data to servers.\n> \n> We\'ve been thinking about getting metadata to the in-instance parts on the\n> server and whether the resources you are building can serve the purpose.\n> I.e. pass and endpoint to the SoftwareConfig resources to the instance and\n> let the instance query the metadata from the resource. Sounds like this is\n> what you had in mind, so that would be a good point for integrating the\n> work. In the meantime, we can think of some shortcuts.\n> \n\nNote that os-collect-config is intended to be a light-weight generic\nin-instance agent to do exactly this. Watch for Metadata changes, and\nfeed them to an underlying tool in a predictable interface. I\'d hope\nthat any of the appliers would mostly just configure os-collect-config\nto run a wrapper that speaks os-collect-config\'s interface.\n\nThe interface is defined in the README:\n\nhttps://pypi.python.org/pypi/os-collect-config\n\nIt is inevitable that we will extend os-collect-config to be able to\ncollect config data from whatever API these config applier resources\nmake available. I would suggest then that we not all go off and reinvent\nos-collect-config for each applier, but rather enhance os-collect-config\nas needed and write wrappers for the other config tools which implement\nits interface.\n\nos-apply-config already understands this interface for obvious reasons.\n\nBash scripts can use os-apply-config to extract individual values, as\nyou might see in some of the os-refresh-config scripts that are run as\npart of tripleo. I don\'t think anything further is really needed there.\n\nFor chef, some kind of ohai plugin to read os-collect-config\'s collected\ndata would make sense.\n\n\n','<OF9A73EB2B.EB827B58-ONC1257C29.00288F05-C1257C29.0029B7B9@de.ibm.com>',NULL),('<1384939728.18538.1.camel@gnm40439.pcdir.int.gnl>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 09:28:48',0,'2013-11-20 09:28:48',NULL,'[openstack-dev] [Neutron][LBaaS] SSL Termination write-up','Hi,\n\nYes, definitely yes.\n\nIt\'s just a bootstrap problem - you can\'t both have a reliable,\nresilient loadbalancer that can be respawned, and not store all the data\nnecessary to respawn it.\n\nI agree there are privacy concerns, just as there are with any hoster.\nBut if you don\'t trust your hoster with your SSL certs, you probably\nshouldn\'t host any content that matters with them.\n\nCheers,\n\nOn Wed, 2013-11-20 at 08:43 +0000, Samuel Bercovici wrote:\n> Hi Stephen,\n> \n> When this was discussed in the past, customer were not happy about storing their SSL certificates in the OpenStack database as plain fields as they felt that this is not secured enough.\n> Do you say, that you are OK with storing SSL certificates in  the OpenStack database?\n> \n> -Sam.\n> \n> \n> -----Original Message-----\n> From: Stephen Gran [mailto:stephen.gran at theguardian.com] \n> Sent: Wednesday, November 20, 2013 10:15 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL Termination write-up\n> \n> On 19/11/13 16:33, Clint Byrum wrote:\n> > Excerpts from Vijay Venkatachalam\'s message of 2013-11-19 05:48:43 -0800:\n> >> Hi Sam, Eugene,&  Avishay, etal,\n> >>\n> >>                  Today I spent some time to create a write-up for SSL Termination not exactly design doc. Please share your comments!\n> >>\n> >> https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYT\n> >> vMkMJ_inbo/edit\n> >>\n> >> Would like comments/discussion especially on the following note:\n> >>\n> >> SSL Termination requires certificate management. The ideal way is to handle this via an independent IAM service. This would take time to implement so the thought was to add the certificate details in VIP resource and send them directly to device. Basically don\'t store the certificate key in the DB there by avoiding security concerns of maintaining certificates in controller.\n> \n> I don\'t see why it does.  Nothing in openstack needs to trust user-uploaded certs.  Just storing them as independent certificate objects that can be referenced by N VIPs makes sense to me.\n> \n> If the backend is SSL, I would think you could do one of:\n> a) upload client certs\n> b) upload CA that has signed backend certs\n> c) opt to disable cert checking for backends\n> \n> With the default being c).\n> \n> Cheers,\n> --\n> Stephen Gran\n> Senior Systems Integrator - theguardian.com Please consider the environment before printing this email.\n> ------------------------------------------------------------------\n> Visit theguardian.com   \n> \n> On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad   \n> Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.\n> Visit subscribe.theguardian.com\n> \n> This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately.\n> Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way.\n>  \n> Guardian News & Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software.\n>  \n> Guardian News & Media Limited\n>  \n> A member of Guardian Media Group plc\n> Registered Office\n> PO Box 68164\n> Kings Place\n> 90 York Way\n> London\n> N1P 2AP\n>  \n> Registered in England Number 908396\n> \n> --------------------------------------------------------------------------\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nStephen Gran\nSenior Systems Integrator - The Guardian\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit theguardian.com   \n\nOn your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad   \nSave up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.\nVisit subscribe.theguardian.com\n\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n--------------------------------------------------------------------------\n\n\n\n','<F36E8145F2571242A675F56CF60964560126D115@ILMB2.corp.radware.com>',NULL),('<1384939845.18538.3.camel@gnm40439.pcdir.int.gnl>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 09:30:45',0,'2013-11-20 09:30:45',NULL,'[openstack-dev] [Neutron][LBaaS] SSL Termination write-up','Hi,\n\nOn Wed, 2013-11-20 at 08:24 +0000, Samuel Bercovici wrote:\n> Hi,\n> \n>  \n> \n> Evgeny has outlined the wiki for the proposed change at:\n> https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL which is in line\n> with what was discussed during the summit.\n> \n> The\n> https://docs.google.com/document/d/1tFOrIa10lKr0xQyLVGsVfXr29NQBq2nYTvMkMJ_inbo/edit discuss in addition Certificate Chains.\n> \n>  \n> \n> What would be the benefit of having a certificate that must be\n> connected to VIP vs. embedding it in the VIP?\n\nYou could reuse the same certificate for multiple loadbalancer VIPs.\nThis is a fairly common pattern - we have a dev wildcard cert that is\nself-signed, and is used for lots of VIPs.\n\n> When we get a system that can store certificates (ex: Barbican), we\n> will add support to it in the LBaaS model.\n\nIt probably doesn\'t need anything that complicated, does it?\n\nCheers,\n-- \nStephen Gran\nSenior Systems Integrator - The Guardian\n\nPlease consider the environment before printing this email.\n------------------------------------------------------------------\nVisit theguardian.com   \n\nOn your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad   \nSave up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.\nVisit subscribe.theguardian.com\n\nThis e-mail and all attachments are confidential and may also\nbe privileged. If you are not the named recipient, please notify\nthe sender and delete the e-mail and all attachments immediately.\nDo not disclose the contents to another person. You may not use\nthe information for any purpose, or store, or copy, it in any way.\n \nGuardian News & Media Limited is not liable for any computer\nviruses or other material transmitted with or as part of this\ne-mail. You should employ virus checking software.\n \nGuardian News & Media Limited\n \nA member of Guardian Media Group plc\nRegistered Office\nPO Box 68164\nKings Place\n90 York Way\nLondon\nN1P 2AP\n \nRegistered in England Number 908396\n\n--------------------------------------------------------------------------\n\n\n\n','<F36E8145F2571242A675F56CF60964560126D097@ILMB2.corp.radware.com>',NULL),('<1384986578-sup-2738@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 14:41:16',-28800,'2013-11-20 22:41:16',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Mike Spreitzer\'s message of 2013-11-20 13:46:25 -0800:\n> Clint Byrum <clint at fewbar.com> wrote on 11/19/2013 04:28:31 PM:\n> > From: Clint Byrum <clint at fewbar.com>\n> > To: openstack-dev <openstack-dev at lists.openstack.org>, \n> > Date: 11/19/2013 04:30 PM\n> > Subject: Re: [openstack-dev] [Heat] HOT software configuration \n> > refined after design summit discussions\n> > \n> > Excerpts from Steve Baker\'s message of 2013-11-19 13:06:21 -0800:\n> > > On 11/20/2013 09:50 AM, Clint Byrum wrote:\n> > > > Excerpts from Steve Baker\'s message of 2013-11-18 12:52:04 -0800:\n> > > >> Regarding apply_config/remove_config, if a SoftwareApplier resource \n> is\n> > > >> deleted it should trigger any remove_config and wait for the server \n> to\n> > > >> acknowledge when that is complete. This allows for any\n> > > >> evacuation/deregistering workloads to be executed.\n> > > >>\n> > > > I\'m a little worried about the road that leads us down. Most \n> configuration\n> > > > software defines forward progress only. Meaning, if you want \n> something\n> > > > not there, you don\'t remove it from your assertions, you assert that \n> it\n> > > > is not there.\n> \n> I am worried too.  But I do not entirely follow your reasoning.  When I \n> UPDATE a stack with a new template, am I supposed to write in that \n> template not just what I want the stack to be but also how that differs \n> from what it currently is?  That is not REST.  Not that I am a total REST \n> zealot, but I am a fan of managing in terms of desired state.  But I agree \n> there is a conflict between defining a \'remove\' operation and the \"forward \n> progress only\" mindset of most config tooling.\n> \n\nI am worried about the explosion of possibilities that comes from trying\nto deal with all of the diff\'s possible inside an instance. If there is an\nactual REST interface for a thing, then yes, let\'s use that. For instance,\nif we are using docker, there is in fact a very straight forward way to\nsay \"remove entity X\". If we are using packages we have the same thing.\nHowever, if we are just trying to write chef configurations, we have to\nwrite reverse chef configurations.\n\nWhat I meant to convey is \"let\'s give this piece of the interface a lot of\nthought\". Not \"this is wrong to even have.\" Given a couple of days now,\nI think we do need \"apply\" and \"remove\". We should also provide really\nsolid example templates for this concept.\n\n> > > > ...\n> > > A specific use-case I\'m trying to address here is tripleo doing an\n> > > update-replace on a nova compute node. The remove_config contains the\n> > > workload to evacuate VMs and signal heat when the node is ready to be\n> > > shut down. This is more involved than just \"uninstall the things\".\n> > > \n> > > Could you outline in some more detail how you think this could be \n> done?\n> > > \n> > \n> > So for that we would not remove the software configuration for the\n> > nova-compute, we would assert that the machine needs vms evacuated.\n> > We want evacuation to be something we explicitly do, not a side effect\n> > of deleting things.\n> \n> Really?  You want to force the user to explicitly say \"evacuate the VMs\" \n> in all the various ways a host deletion can happen?  E.g., when an \n> autoscaling group of hosts shrinks?\n> \n\nAutoscaling doesn\'t really fly with stateful services IMO. Also for\nTripleO\'s use case, auto-scaling is not really a high priority. Hardware\nisn\'t nearly as easily allocatable as VM\'s.\n\nAnyway, there is a really complicated work-flow for decomissioning\nany stateful service, and it differs wildly between them. I do want to\nhave a place to define that work-flow and reliably trigger it when it\nneeds to be triggered. I do not want it to _only_ be available in the\n\"delete this resource\" case, and I also do not want it to _always_\nbe run in that case, as I may legitimately be destroying the data too.\nI need a way to express that intention, and in my mind, the way to do\nthat is to first complete an evacuation and then delete the thing.\n\nBetter ideas are _most_ welcome.\n\n\n','<OF6198B1DD.E6AA0D6B-ON85257C29.0076E9B7-85257C29.00779B42@us.ibm.com>',NULL),('<1384988486-sup-92@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 15:03:02',-28800,'2013-11-20 23:03:02',NULL,'[openstack-dev] [Heat] Continue discussing multi-region\n	orchestration','Excerpts from Mike Spreitzer\'s message of 2013-11-20 11:09:34 -0800:\n> OTOH, the more we restrict what can be done, the less useful this really \n> is.\n\nI would be more specific and say it as \"...the less divergent behavior\nis actually possible.\"\n\nIt will be quite a bit more useful if it is boring and restricted but\ndoes what it claims to do extremely well.\n\n\n','<OF247A4B1D.CB4A49D3-ON85257C29.0068B72F-85257C29.00693F30@us.ibm.com>',NULL),('<1384988882-sup-394@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 15:17:06',-28800,'2013-11-20 23:17:06',NULL,'[openstack-dev] How to stage client major releases in Gerrit?','Excerpts from Mark Washenberger\'s message of 2013-11-20 10:14:42 -0800:\n> Hi folks,\n> \n> The project python-glanceclient is getting close to needing a major release\n> in order to finally remove some long-deprecated features, and to make some\n> minor adjustments that are technically backwards-incompatible.\n> \n> Normally, our release process works great. When we cut a release (say\n> 1.0.0), if we realize it doesn\'t contain a feature we need, we can just add\n> the feature and release a new minor version (say 1.1.0). However, when it\n> comes to cutting out the fat for a major release, if we find a feature that\n> we failed to remove before releasing 1.0.0, we\'re basically screwed. We\n> have to keep that feature around until we feel like releasing 2.0.0.\n> \n> In order to mitigate that risk, I think it would make a lot of sense to\n> have a place to stage and carefully consider all the breaking changes we\n> want to make. I also would like to have that place be somewhere in Gerrit\n> so that it fits in with our current submission and review process. But if\n> that place is the \'master\' branch and we take a long time, then we can\'t\n> really release any bug fixes to the v0 series in the meantime.\n> \n> I can think of a few workarounds, but they all seem kinda bad. For example,\n> we could put all the breaking changes together in one commit, or we could\n> do all this prep in github.\n> \n> My question is, is there a correct way to stage breaking changes in Gerrit?\n> Has some other team already dealt with this problem?\n> \n> DISCLAIMER:\n> For the purposes of this discussion, it will be utterly unproductive to\n> discuss the relative merits of backwards-breaking changes. Rather let\'s\n> assume that all breaking changes that would eventually land in the next\n> major release are necessary and have been properly communicated well in\n> advance. If a given breaking change is *not* proper, well that\'s the kind\n> of thing I want to catch in gerrit reviews in the staging area!\n\nI understand what you\'re trying to do with this disclaimer. The message\nabove just _screams_ for this discussion, so why not cut it off at the\npass? However, glanceclient being a library, not discussing the fact\nthat you\'re breaking an established API is like not discussing ice at\nthe north pole.\n\nIf you want to be able to change interfaces without sending a missile\nup the tail pipe of every project who depends on your code, call it\nglanceclient2. That solves all of your stated problems from above. You can\nstill deprecate glanceclient and stop maintaining it after some overlap\ntime. And if users hate glanceclient2, then they can keep glanceclient\nalive with all of its warts.\n\n\n','<CAJyP2C8FAXRFA=TXDhRkCPbr21b=PKZ1FRf8c_08R2goehGK-w@mail.gmail.com>',NULL),('<1384992819.7512.11.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 10:13:39',36000,'2013-11-21 00:13:39',NULL,'[openstack-dev] How to stage client major releases in Gerrit?','On Wed, 2013-11-20 at 15:17 -0800, Clint Byrum wrote:\n> Excerpts from Mark Washenberger\'s message of 2013-11-20 10:14:42 -0800:\n> > Hi folks,\n> > \n> > The project python-glanceclient is getting close to needing a major release\n> > in order to finally remove some long-deprecated features, and to make some\n> > minor adjustments that are technically backwards-incompatible.\n> > \n> > Normally, our release process works great. When we cut a release (say\n> > 1.0.0), if we realize it doesn\'t contain a feature we need, we can just add\n> > the feature and release a new minor version (say 1.1.0). However, when it\n> > comes to cutting out the fat for a major release, if we find a feature that\n> > we failed to remove before releasing 1.0.0, we\'re basically screwed. We\n> > have to keep that feature around until we feel like releasing 2.0.0.\n> > \n> > In order to mitigate that risk, I think it would make a lot of sense to\n> > have a place to stage and carefully consider all the breaking changes we\n> > want to make. I also would like to have that place be somewhere in Gerrit\n> > so that it fits in with our current submission and review process. But if\n> > that place is the \'master\' branch and we take a long time, then we can\'t\n> > really release any bug fixes to the v0 series in the meantime.\n> > \n> > I can think of a few workarounds, but they all seem kinda bad. For example,\n> > we could put all the breaking changes together in one commit, or we could\n> > do all this prep in github.\n> > \n> > My question is, is there a correct way to stage breaking changes in Gerrit?\n> > Has some other team already dealt with this problem?\n> > \n> > DISCLAIMER:\n> > For the purposes of this discussion, it will be utterly unproductive to\n> > discuss the relative merits of backwards-breaking changes. Rather let\'s\n> > assume that all breaking changes that would eventually land in the next\n> > major release are necessary and have been properly communicated well in\n> > advance. If a given breaking change is *not* proper, well that\'s the kind\n> > of thing I want to catch in gerrit reviews in the staging area!\n> \n> I understand what you\'re trying to do with this disclaimer. The message\n> above just _screams_ for this discussion, so why not cut it off at the\n> pass? However, glanceclient being a library, not discussing the fact\n> that you\'re breaking an established API is like not discussing ice at\n> the north pole.\n> \n> If you want to be able to change interfaces without sending a missile\n> up the tail pipe of every project who depends on your code, call it\n> glanceclient2. That solves all of your stated problems from above. You can\n> still deprecate glanceclient and stop maintaining it after some overlap\n> time. And if users hate glanceclient2, then they can keep glanceclient\n> alive with all of its warts.\n\nSorry, completely disagree with this. This is the point of having a\nmajor version number in client libraries, when you need to do backward\nincompatible changes then you bump the major version. You can continue\nto develop the 0.x and 1.x series in parallel for some amount of time\nand that\'s common.\n\nIf your application doesn\'t work with the 1.x series then you modify\nyour requirements to indicate this.\n\nIf this is going to be a problem in openstack then we need to figure out\na way of dealing with it because the client libraries are in general a\nmess and i know that at least keystone is not far off needing to make\nbackward incompatible changes to start to clean it up.\n\nSorry about your disclaimer :)\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<1384988882-sup-394@clint-HP>',NULL),('<1384993469.7512.19.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 10:24:29',36000,'2013-11-21 00:24:29',NULL,'[openstack-dev] [Swift]  Server Side Encryption','On Wed, 2013-11-20 at 13:26 +0200, David Hadas wrote:\n> Hi all,\n> \n> We created a wiki page discussing the addition of software side encryption\n> to Swift:\n> \"The general scheme is to create a swift proxy middleware that will encrypt\n> and sign the object data during PUT and check the signature + decrypt it\n> during GET. The target is to create two domains - the user domain between\n> the client and the middleware where the data is decrypted and the system\n> domain between the middleware and the data at rest (on the device) where\n> the data is encrypted.\n> Design goals include: (1) Extend swift as necessary but without changing\n> existing swift behaviors and APIs; (2) Support encrypting data incoming\n> from unchanged clients\"\n> \n> See:  https://wiki.openstack.org/wiki/Swift/server-side-enc\n> We would like to invite feedback.\n\nPlease make sure to have a look at the KDS service proposal and how it\ndeals with encrypting keys for storage.\nhttps://review.openstack.org/#/c/37118/ It is abandoned as it has been\ndecided it should be split into its own service rather than live in\nkeystone however the principals won\'t change much. \n\nIt handles using a master encryption key to generate a per host key with\nwhich it signs and encrypts using the crypto functions that are already\nin oslo. \n\nThat part of the code isn\'t too hard to write on a per use basis but if\nserver side encryption is going to become more widely adopted by\nprojects then I am interested in helping extract this functionality into\nsomething generic for OSLO.\n\n> DH\n> \n> \n> Regards,\n> David Hadas,\n> Openstack Swift ATC, Architect, Master Inventor\n> IBM Research Labs, Haifa\n> Tel:    Int+972-4-829-6104\n> Fax:   Int+972-4-829-6112\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<OF89F20AAA.79D86C3B-ONC2257C29.003A6E7E-C2257C29.003EE387@il.ibm.com>',NULL),('<1384999734.7512.32.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 12:08:54',36000,'2013-11-21 02:08:54',NULL,'[openstack-dev] [keystone][py3] Usage of httpretty','Chuck, \n\nSo it is being used to handle stubbing returns from requests and httplib\nrather than having to having fake handlers in place in our testing code,\nor stubbing out the request library and continually having to update the\narguments being passed to keep the mocks working. From my looking around\nit is the best library for this sort of job.\n\nWhen i evalutated it for keystoneclient upstream\n(https://github.com/gabrielfalcao/HTTPretty/ ) was quickly responsive\nand had CI tests that seemed to be checking python 3 support. I haven\'t\nseen as much happening recently as there are pull requests upstream for\npython 3 fixes that just don\'t seem to be moving anywhere. The CI for\npython 3 was also commented out at some point.\n\nIt also turns out to be a PITA to package correctly. I attempted this\nfor fedora, and i know there was someone attempting the same for gentoo.\nI have a pull request upstream that would at least get the dependencies\nunder control.\n\nI do not want to go back to stubbing the request library, or having a\nfake client path that is only used in testing. However I have also\nnoticed it is the cause of at least some of our python 3 problems.\n\nIf there are other libraries out there that can do the same job we\nshould consider them though i am holding some hope for upstream.\n\n\nJamie\n\n\nOn Wed, 2013-11-20 at 14:27 -0800, Morgan Fainberg wrote:\n> Chuck,\n> \n> The reason to use httpretty is that it handles everything at the\n> socket layer, this means if we change out urllib for requests or some\n> other transport to make HTTP requests to we don\'t need to refactor\n> every one of the mock/mox subouts to match the exact set of parameters\n> to be passed.  Httpretty makes managing this significantly easier\n> (hence was the reasoning to move towards it).  Though, I\'m sure Jamie\n> Lennox can provide more insight into deeper specifics as he did most\n> of the work to convert it.\n> \n> At least the above is my understanding of the reasoning.\n> \n> --Morgan\n> \n> On Wed, Nov 20, 2013 at 2:08 PM, Dolph Mathews <dolph.mathews at gmail.com> wrote:\n> > I don\'t have a great answer -- do any projects depend on it other than\n> > python-keystoneclient? I\'m happy to see it removed -- I see the immediate\n> > benefit but it\'s obviously not significant relative to python 3 support.\n> >\n> > BTW, this exact issue is being tracked here-\n> > https://bugs.launchpad.net/python-keystoneclient/+bug/1249165\n> >\n> >\n> >\n> >\n> > On Wed, Nov 20, 2013 at 3:28 PM, Chuck Short <chuck.short at canonical.com>\n> > wrote:\n> >>\n> >> Hi,\n> >>\n> >> I was wondering for the reason behind the usage httpretty in\n> >> python-keystoneclient. It seems to me like a total overkill for a test. It\n> >> also has some problems with python3 support that is currently blocking\n> >> python3 porting as well.\n> >>\n> >> Regards\n> >> chuck\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >\n> >\n> > --\n> >\n> > -Dolph\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CABEb+dQG7sabrMaPbpZQX9Yty_a2ViW+Jx9gmn7vhLksjTpTcg@mail.gmail.com>',NULL),('<1385012403-sup-6884@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 21:42:35',-28800,'2013-11-21 05:42:35',NULL,'[openstack-dev] [keystone][py3] Usage of httpretty','Excerpts from Chuck Short\'s message of 2013-11-20 19:21:14 -0800:\n> Hi,\n> \n> So maybe if it gets to the point where it gets too be much of a porblem we\n> should just put it on stackforge.\n> \n\nThat should be the last resort, when upstream is deemed dead. I\'m guessing\nupstream would not like to fade away into extinction as users migrate\nto python 3. We should be comfortable helping out any way we can upstream.\n\nThe library sounds like a viable option for test isolation. Perhaps we\ncan just offer to help fix upstream\'s py3k CI.\n\n\n','<CANZa-eLAxM8xjaquxGqODk3LkkP31pR+qPMy2ywcYQ=OCWqDAQ@mail.gmail.com>',NULL),('<1385012690.16083.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-21 13:44:50',28800,'2013-11-21 05:44:50',NULL,'[Openstack] problem in starting swift','Thanks for the reply Sir\n\nBut please help me to know how can I check out my swift source.\n\nPlease help.\n\nThanks Again\n\nPragya Jain\n\n\n\n\n\n\n\nOn Wednesday, 20 November 2013 4:37 AM, Clay Gerrard <clay.gerrard at gmail.com> wrote:\n \nTry this:\n>\n>\n>sudo apt-get install python-pip\n>pip install -U pip\n>sudo apt-get purge python-pip\n>cd <myswiftsourcecheckout>\n>sudo pip install -e .\n>\n>\n>GL,\n>\n>\n>-clayg\n>\n>\n>\n>On Tue, Nov 19, 2013 at 2:04 AM, Razique Mahroua <razique.mahroua at gmail.com> wrote:\n>\n>Hi,\n>>you can follow that link:\n>>https://ask.openstack.org/en/question/4996/importerror-running-swift/\n>>\n>>- Razique\n>>\n>>On 18 Nov 2013, at 20:23, pragya jain wrote:\n>>\n>>\n>>hello Zhang\n>>>\n>>>I follow the steps mentioned in the link given by you.\n>>>but the error is still there.\n>>>\n>>>Please help.\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Monday, 18 November 2013 10:04 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote:\n>>>\n>>>try work-around on ask.openstack.org here:\n>>>\n>>>? ? ? ? * https://ask.openstack.org/en/question/4996/importerror-running-swift/\n>>>>\n>>>>\n>>>>pragya jain ---2013-11-18 ?? 03:37:20---pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>\n>>>>pragya jain <prag_2648 at yahoo.co.in>?\n>>>>2013-11-18 ?? 03:05\n>>>>Please respond to\n>>>>pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>\nTo\n>>>>Hua ZZ Zhang/China/IBM at IBMCN\n>>>>\n>>>>\n>>>>cc\n>>>>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>\n>>>>\n>>>>Subject\n>>>>\n>>>>Re: [Openstack] problem in starting swift\n>>>>\n>>>>\n>>>>Thanks?Zhang\n>>>>\n>>>>root at arun-Aspire-5742:~# pico /root/swift/swift/common/middleware/recon.py\n>>>>it shows the file at the place\n>>>>\n>>>>\n>>>>On Monday, 18 November 2013 4:32 AM, Hua ZZ Zhang <zhuadl at cn.ibm.com> wrote: Make sure module of recon is in place under this path and can be accessible:\n>>>>/root/swift/swift/common/middleware/recon.py\n>>>>\n>>>>-Edward\n>>>>\n>>>>\n>>>>\n>>>>pragya jain ---2013-11-17 ?? 06:49:40---pragya jain <prag_2648 at yahoo.co.in>\n>>>>\n>>>>pragya jain <prag_2648 at yahoo.co.in>??\n>>>>2013-11-17 ?? 06:41?\n>>>>\n>>>>\n>>>>Please respond to\n>>>>\npragya jain <prag_2648 at yahoo.co.in> ?To\n>>>>\"openstack at lists.openstack.org\" <openstack at lists.openstack.org>?\n>>>>cc\n>>>>Subject\n>>>>\n>>>>[Openstack] problem in starting swift?\n>>>>\n>>>>hi all,\n>>>>\n>>>>I am installing swift on my system using the guidelines given in the link\n>>>>http://docs.openstack.org/developer/swift/development_saio.html\n>>>>\n>>>>when Setting up scripts for running Swift\n>>>>at the command\n>>>>root at arun-Aspire-5742:~# startmain\n>>>>\n>>>>I got the following error:\n>>>>http://paste.openstack.org/show/53458/\n>>>>\n>>>>please help me to overcome this problem.\n>>>>\n>>>>Thanks in advance\n>>>>\n>>>>Pragya Jain\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>______________________________________________\n>>>>\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131121/391a4377/attachment.html>\n\n','<CA+_JKzrjT+X912ECZ2xc-PJAMCNd6fXzwz=MbODoUAsJqtUWMg@mail.gmail.com>',NULL),('<1385015936-sup-4911@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 22:41:31',-28800,'2013-11-21 06:41:31',NULL,'[openstack-dev] [Heat] HOT software configuration refined after\n	design summit discussions','Excerpts from Mike Spreitzer\'s message of 2013-11-20 15:16:45 -0800:\n> Clint Byrum <clint at fewbar.com> wrote on 11/20/2013 05:41:16 PM:\n> \n> > Autoscaling doesn\'t really fly with stateful services IMO.\n> \n> I presume you\'re concerned about the \"auto\" part, not the \"scaling\".  Even \n> a stateful group is something you may want to scale; it just takes a more \n> complex set of operations to accomplish that.  If we can make a Heat \n> autoscaling group invoke the right set of operations, why not?\n> \n\nIt is most definitely possible and necessary. We _must_ do this.\n\nIt does not fly with today\'s limited auto-scaling.\n\nIf we can get the link between orchestration and work-flow working well,\nthe end result should be harmonious automation and then automatic scaling\nwill indeed be possible for stateful services.\n\n\n','<OF7819CBC8.473F4239-ON85257C29.007FA165-85257C29.007FE05F@us.ibm.com>',NULL),('<1385017125-sup-7398@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-20 23:09:11',-28800,'2013-11-21 07:09:11',NULL,'[openstack-dev] Propose \"project story wiki\" idea','Excerpts from Boris Pavlovic\'s message of 2013-11-19 21:33:08 -0800:\n> Hi stackers,\n> \n> \n> Currently what I see is growing amount of interesting projects, that at\n> least I would like to track. But reading all mailing lists, and reviewing\n> all patches in all interesting projects to get high level understanding of\n> what is happing in project now, is quite hard or even impossible task (at\n> least for me). Especially after 2 weeks vacation =)\n> \n> \n> The idea of this proposal is that every OpenStack project should have\n> \"story\" wiki page. It means to publish every week one short message that\n> contains most interesting updates for the last week, and high level road\n> map for future week. So reading this for 10-15 minutes you can see what\n> changed in project, and get better understanding of high level road map of\n> the project.\n\nI like the idea, but I don\'t like having _more_ wiki pages.\n\nI think the weekly IRC meeting would be a good place for this to be\nmaintained.\n\nWe can have an agenda item \"Updates\". Before the meeting people can add\nany and the chair can paste those in. Then any that people come up with\nduring the meeting can be stated by attendees.\n\n<chair> #topic Updates\n<chair> * Core reviewer added: foo-person, congratulations!\n<SpamapS> * Completed py3k fixes for python-barclient\n\nThis way the updates are sent along with any other relevant discussions\nfrom the meeting, and subscribers can still just follow pages they\'re\nalready used to following.\n\nMeanwhile the Updates topic can be automatically extracted from the\nmeeting logs and highlighted in a special section of the main project\nwiki page. Perhaps the same automation can maintain a page which includes\nall of the other projects\' updates for a one stop shop.\n\nIf people like this idea and want to try it out I\'d be happy to throw\ntogether a script to do the log extraction.\n\nAnyway, less manual == more fun == more engagement.\n\n\n','<CAD85om3-pLpk14CTCOsJUC9P5-6eyqo09fM+xGc8ME4N+Zogkg@mail.gmail.com>',NULL),('<1385026288-sup-9115@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 01:32:39',-28800,'2013-11-21 09:32:39',NULL,'[openstack-dev] Propose \"project story wiki\" idea','Excerpts from Boris Pavlovic\'s message of 2013-11-21 00:16:04 -0800:\n> Clint,\n> \n> The main idea is to have processed by human history of project.\n> \n> It is really impossible to aggregate automatically all data from different\n> sources:\n> IRC (main project chat/dev chat/meetings), Mailing Lists, Code, Reviews,\n> Summit discussions, using project specific knowledge and history of  the\n> project.To get short messages like here\n> https://wiki.openstack.org/wiki/Rally/Updates\n> \n> So the idea is that in each project we should have the persons that will\n> aggregate for others all these sources and present really short, high level\n> view of situation. And these messages should be in one place (wiki/or other\n> platform (not mailing lists)) for project. So we will be able quick to get\n> what happens with project for last few months and what are current goals.\n> This will be also very very useful for new contributors.\n> \n> So Aggregation of data is good (and should be done), but it is not enough..\n> \n\nI did not suggest aggregation of data. We have TONS of that, and we\ndon\'t need more.\n\nI suggested a very simple way for project leaders and members to maintain\nthe current story during the meetings.\n\n\n','<CAD85om3CWGKvg66T6AtF8ej+kgheiWRNuk59bK3jSKOmBaDxGg@mail.gmail.com>',NULL),('<1385030568.61022.YahooMailNeo@web172405.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-21 10:42:48',0,'2013-11-21 10:42:48',NULL,'[Openstack] Need help - Compute Node restarted - Ramdom\n	Instances doesn\'t get and IP anymore','\nI think this needs to be fixed in the Ubuntu packaging. Neutron-ovs-cleanup needs to run after openvswitch-switch starts and before nova-compute starts. But care needs to be taken for the case where neutron-dhcp-agent and/or neutron-l3-agent also runs on a node with nova-compute. Cleanup should run before these start too. It\'s easy to do this with the system V init system, but I\'m not sure how with upstart.\n\nRe, Darragh.\n\n\n\n\nOn Thursday, 21 November 2013, 7:50, Jian Wen <jian.wen at canonical.com> wrote:\n \nIt is?https://bugs.launchpad.net/neutron/+bug/1091605\n>\n>\n>The patch fixes the above bug introduces another bug:?\n>https://bugzilla.redhat.com/show_bug.cgi?id=1010941\n>\n>\n>\n>\n>On Thu, Nov 21, 2013 at 2:18 PM, Jean-Daniel BUSSY <silversurfer972 at gmail.com> wrote:\n>\n>Nice! Thanks Thiago for the details.\n>>Looks like this bug should be reported.\n>>\n>>\n>>Cheers\n>>\n>>\n>>\n>>BUSSY Jean-Daniel\n>>Cloud Engineer | GREE\n>>Mobile: +81 090-3317-1337\n>>Email: silversurfer972 at gmail.com\n>>\n>>\n>>\n>>On Tue, Nov 19, 2013 at 7:01 PM, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>>\n>>Hi Thiago,\n>>>\n>>>I did a qucik test with Havana on Ubuntu 12.04 with QEMU, OVS 1.10.2 and the OVS hybrid driver. Started an instance, rebooted the compute node, and the instance goes to status STOPPED. Then ran \'nova start instance-name\', and it starts ok, but DHCP does not work.\n>>>\n>>>In the logs I see OVS starting first and recreating the qvoxxxxxx-xx port and interface from its database. Then nova-compute starts and creates the qbr Linux bridge and qvb interface, but it is not recreating the? qvo port and interface because they already exist.? Everything looks ok, and the DHCP requests are getting to qvo, but they are not getting into br-int.\n>>>\n>>>It seems the qvo interface needs to be created by Nova (using the ip command) before the OVS port is created with the same name. Otherwise OVS does not seem to enslave the interface.\n>>>\n>>>I added this upstart script to run cleanup which will delete the ports on br-int before nova-compute and the OVS agent start:\n>>>\n>>>root at compute1:~# cat /etc/init/neutron-ovs-cleanup.conf\n>>>start on starting nova-compute or neutron-plugin-openvswitch-agent\n>>>script\n>>>? /usr/bin/neutron-ovs-cleanup\n>>>end script\n>>>\n>>>Now nova-compute has to recreate everything, and the instance is getting an IP with DHCP. Maybe you can try this out in your test environment.\n>>>\n>>>Re, Darragh.\n>>>\n>>>\n>>>\n>>>\n>>>>Guys,\n>>>>\n>>>>My Havana (Ubuntu based) Compute Node was restarted and lots of Instances\n>>>>does not get an IP anymore.\n>>>>\n>>>>Tips?!\n>>>>\n>>>\n>>>>It is ramdom, I mean, some instances of this same compute node are normal,\n>>>>while others have no IP.\n>>>>\n>>>\n>>>>I really need help here because my client\'s web site is completely off line\n>>>>now...\n>>>>\n>>>>I\'m using Per-Tenant router with private networks + VXLAN.\n>>>>\n>>>>Tks!\n>>>>Thiago\n>>>\n>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>\n>\n>\n>\n>-- \n>\n>Cheers,\n>Jian\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131121/810c2cf7/attachment.html>\n\n','<CAMunoaPwCScAqDcMAzvBBQcsiBeMVM5OLOschubqN67Y-Ks-HA@mail.gmail.com>',NULL),('<1385042546.20444.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-21 14:02:26',0,'2013-11-21 14:02:26',NULL,'[openstack-dev] Propose \"project story wiki\" idea','On Thu, 2013-11-21 at 10:43 +0100, Thierry Carrez wrote:\n> Stefano Maffulli wrote:\n> > On 11/19/2013 09:33 PM, Boris Pavlovic wrote:\n> >> The idea of this proposal is that every OpenStack project should have\n> >> \"story\" wiki page. It means to publish every week one short message that\n> >> contains most interesting updates for the last week, and high level road\n> >> map for future week. So reading this for 10-15 minutes you can see what\n> >> changed in project, and get better understanding of high level road map\n> >> of the project.\n> > \n> > I like the idea.\n> > \n> > I have received requests to include high level summaries from all\n> > projects in the weekly newsletter but it\'s quite impossible for me to do\n> > that as I don\'t have enough understanding of each project to extrapolate\n> > the significant news from the noise. [...]\n> \n> This is an interesting point. From various discussions I had with people\n> over the last year, the thing the development community is really really\n> after is weekly technical news that would cover updates from major\n> projects as well as deep dives into new features, tech conference CFPs,\n> etc. The reference in the area (and only example I have) is LWN\n> (lwn.net) and their awesome weekly coverage of what happens in Linux\n> kernel development and beyond.\n> \n> The trick is, such coverage requires editors with a deep technical\n> knowledge, both to be able to determine significant news from marketing\n> noise *and* to be able to deep dive into a new feature and make an\n> article out of it that makes a good read for developers or OpenStack\n> deployers. It\'s also a full-time job, even if some of those deep-dive\n> articles could just be contributed by their developers.\n> \n> LWN is an exception rather than the rule in the tech press. It would be\n> absolutely awesome if we managed to build something like it to cover\n> OpenStack, but finding the right people (the right skill set + the will\n> and the time to do it) will be, I fear, extremely difficult.\n> \n> Thoughts ? Volunteers ?\n\nYeah, I think there\'s a huge opportunity for something like this. Look\nat the volume of interesting stuff that\'s going on on this list.\nHighlighting and summarising some of the more important and interesting\nof these discussions in high quality articles would be incredibly\nuseful.\n\nIt will be hard to pull off though. You need good quality writing but,\nmore importantly, really strong editorial control who understands what\npeople want to read.\n\nMark.\n\n\n\n','<528DD5C3.8050206@openstack.org>',NULL),('<1385058881.12780.50445737.6F025121@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-21 10:34:41',-28800,'2013-11-21 18:34:41',NULL,'[Openstack] Error details in Horizon','I started using OpenStack the other day using RDO and was able to get it\nworking. One thing I notice is the Horizon interface doesn\'t display\nerror or troubleshooting information. For example, I am having problems\nbooting an instance of Fedora 19. Horizon only says \"Error\" with no\nvisibility into why the error happened or advice on next steps.\n\nIs this expected or is there something I need to enable to receive more\ninformation through Horizon? If the former, are there planned\nimprovements to the logging?\n\nThank you.\n\n\n',NULL,NULL),('<1385085095.2318.19.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 11:51:35',36000,'2013-11-22 01:51:35',NULL,'[openstack-dev] [Keystone][Oslo] Future of Key Distribution\n Server, Trusted Messaging','So i\'ve a feeling that this was proposed and dismissed once before. I\ndon\'t remember why.\n\nSo my concern with barbican is that i\'m under the impression that\nbarbican was going to be an \'overcloud\' service. That\'s a really bad way\nof putting it, but it is service and user facing and discovered via the\nservice catalog. \n\nThis feature will need to be configured at a lower level (runs in\nsituations without a token) and so we will need to configure the\nservices to point to an IP for the KDS service. \n\nIs this an expected deployment of barbican (i can\'t see why not)?\n\nJamie\n\nOn Thu, 2013-11-21 at 20:08 +0000, Jarret Raim wrote:\n> The Barbican team has been taking a look at the KDS feature and the\n> proposed patch and I think this may be better placed in Barbican rather\n> than Keystone. The patch, from what I can tell, seems to require that a\n> service account create & use a key under its own tenant. In this use case,\n> Barbican can handle the entire exchange and Keystone can just provide\n> auth/auth for the process. This would allow for some great additional\n> features including guaranteed entropy and additional security through the\n> use of HSMs, auditing / logging, etc.\n> \n> Barbican is pretty far along at this point and it doesn?t appear to be a\n> huge amount of work to move the patch over as it doesn?t seem to use any\n> Keystone internals.\n> \n> What would people think about this approach? We?re happy to help move the\n> patch over and I?m certainly happy to merge it as it feels like a good\n> feature for barbican.\n> \n> \n> \n> \n> Jarret\n> \n> \n> \n> \n> \n> \n> On 11/21/13, 12:55 AM, \"Russell Bryant\" <rbryant at redhat.com> wrote:\n> \n> >Greetings,\n> >\n> >I\'d like to check in on the status of this API addition:\n> >\n> >    https://review.openstack.org/#/c/40692/\n> >\n> >The last comment is:\n> >\n> >   \"propose against stackforge as discussed at summit?\"\n> >\n> >I don\'t see a session about this and from a quick look, don\'t see notes\n> >related to it in other session etherpads.\n> >\n> >When was this discussed?  Can you summarize it?\n> >\n> >Last I heard, this was just being deferred to be merged early in\n> >Icehouse [1].\n> >\n> >This is blocking one of the most important security features for\n> >OpenStack, IMO (trusted messaging) [2].  We\'ve been talking about it for\n> >years.  Someone has finally made some real progress on it and I feel\n> >like it has been given little to no attention.\n> >\n> >I\'m not thrilled about the prospect of this going into a new project for\n> >multiple reasons.\n> >\n> > - Given the priority and how long this has been dragging out, having to\n> >wait for a new project to make its way into OpenStack is not very\n> >appealing.\n> >\n> > - A new project needs to be able to stand on its own legs.  It needs to\n> >have a reasonably sized development team to make it sustainable.  Is\n> >this big enough for that?\n> >\n> >What\'s the thinking on this?\n> >\n> >[1]\n> >http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html\n> >[2] https://review.openstack.org/#/c/37913/\n> >\n> >-- \n> >Russell Bryant\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CEB3C3C6.82CBC%jarret.raim@rackspace.com>',NULL),('<1385137957-sup-2694@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 08:47:13',-28800,'2013-11-22 16:47:13',NULL,'[openstack-dev] Introducing the new OpenStack service for\n	Containers','Excerpts from Thierry Carrez\'s message of 2013-11-22 01:50:39 -0800:\n> Tim Bell wrote:\n> > Can we make sure that the costs for the end users are also considered as\n> > part of this ?\n> > \n> > -          Configuration management will need further modules\n> > -          Dashboard confusion as we get multiple tabs\n> > -          Accounting, Block Storage, Networking, Orchestration\n> > confusion as the concepts diverge\n> > \n> > Is this really a good idea to create another project considering the\n> > needs of the whole openstack community ?\n> \n> Personally, it will have to prove a really different API and set of use\n> cases to justify the cost of a separate project. I\'m waiting to see what\n> they come up with, but IMHO it\'s \"compute\" in both cases. We\'ve seen\n> with the libvirt-sandbox discussion that using technology (hypervisor\n> vs. container) to draw the line between the use cases is a bit\n> over-simplifying the problem.\n> \n\nAgreed, I think it has been over simplified, but that is what you do\nwhen you\'re not driven by a well understood real use-case, something I\nhave yet to see from this discussion.\n\n> I don\'t really want us to create a container service and end up\n> implementing the same hypervisor backends than in Nova, just because\n> hypervisors can perfectly also be used to serve lightweight\n> application-centric workloads. Or the other way around (keep Docker\n> support in Nova since you can perfectly run an OS in a container). At\n> first glance, extending the Nova API to also cover lightweight\n> app-centric use cases would avoid a ton of duplication...\n> \n\nAgreed. There are a few weird things that come to mind though. One of\nthose is that I imagine users would like to do something like this:\n\nhost_id=$(container-thing allocate-host --flavor small  appserver)\ndb_id=$(container-thing allocate-host --flavor huge dbserver)\napp_id=$(container-thing run --host $host_id --image app-image)\nproxy_id=$(container-thing run --host $host_id --image proxy-image)\ncache_id=$(container-thing run --host $host_id --image cache-image)\ndb_id=$(container-thing run --host $db_id)\n\nAs in, they\'d probably like to have VMs spun up and then chopped up\ninto containers. If this is implemented first inside nova, that may end\nup being a rats nest and hard to separate later.  The temptation to use\nprivate API\'s is really strong. But if it is outside nova, the separation\nstays clear and the two can be used without one-another very easily.\n\n> If the main concern is to keep Nova small and manageable, I\'d rather rip\n> out pieces like nova-network or the scheduler, which are clearly not\n> \"compute\".\n> \n\nIndeed, and those things are under way. :)\n\n\n','<528F28EF.6000503@openstack.org>',NULL),('<1385146149.4314.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 18:49:09',0,'2013-11-22 18:49:09',NULL,'[openstack-dev] [Keystone][Oslo] Future of Key Distribution\n Server, Trusted Messaging','On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:\n> Russell Bryant wrote:\n> > [...]\n> > I\'m not thrilled about the prospect of this going into a new project for\n> > multiple reasons.\n> > \n> >  - Given the priority and how long this has been dragging out, having to\n> > wait for a new project to make its way into OpenStack is not very appealing.\n> > \n> >  - A new project needs to be able to stand on its own legs.  It needs to\n> > have a reasonably sized development team to make it sustainable.  Is\n> > this big enough for that?\n> \n> Having it in Barbican (and maybe have Barbican join under the identity\n> program) would mitigate the second issue. But the first issue stands,\n> and I share your concerns.\n\nYes, I agree. It\'s disappointing that this change of plans looks like\nits going to push out the ability of an OpenStack deployment to be\nsecured.\n\nIf this becomes a Barbican API, then we might be able to get the code\nworking quickly ... but it will still be some time before Barbican is an\nintegrated project, and so securing OpenStack will only be possible if\nyou use this non-integrated project.\n\nMark.\n\n\n\n','<528F2C1F.3060301@openstack.org>',NULL),('<1385159411.4314.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 22:30:11',0,'2013-11-22 22:30:11',NULL,'[openstack-dev] [Nova] Proposal to add Matt Riedemann to\n nova-core','On Fri, 2013-11-22 at 15:53 -0500, Russell Bryant wrote:\n> Greetings,\n> \n> I would like to propose adding Matt Riedemann to the nova-core review team.\n> \n> Matt has been involved with nova for a long time, taking on a wide range\n> of tasks.  He writes good code.  He\'s very engaged with the development\n> community.  Most importantly, he provides good code reviews and has\n> earned the trust of other members of the review team.\n> \n> https://review.openstack.org/#/dashboard/6873\n> https://review.openstack.org/#/q/owner:6873,n,z\n> https://review.openstack.org/#/q/reviewer:6873,n,z\n> \n> Please respond with +1/-1, or any further comments.\n\n+1, definitely a great addition to the team\n\nMark.\n\n\n\n','<528FC43A.6010301@redhat.com>',NULL),('<1385191914-sup-7984@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 23:35:06',-28800,'2013-11-23 07:35:06',NULL,'[openstack-dev] [Solum] Working group on language packs','Excerpts from Clayton Coleman\'s message of 2013-11-22 21:43:40 -0800:\n> \n> > On Nov 22, 2013, at 9:54 PM, Monty Taylor <mordred at inaugust.com> wrote:\n> > \n> > \n> > \n> >> On 11/22/2013 11:34 AM, Clayton Coleman wrote:\n> >> I have updated the language pack (name subject to change) blueprint\n> >> with the outcomes from the face2face meetings, and drafted a\n> >> specification that captures the discussion so far.  The spec is\n> >> centered around the core idea of transitioning base images into\n> >> deployable images (that can be stored in Nova and sent to Glance).\n> >> These are *DRAFT* and are intended for public debate.\n> >> \n> >> https://blueprints.launchpad.net/solum/+spec/lang-pack \n> >> https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts\n> >> \n> >> Please take this opportunity to review these documents and offer\n> >> criticism and critique via the ML - I will schedule a follow up deep\n> >> dive for those who expressed interest in participation [1] after US\n> >> Thanksgiving.\n> > \n> > Hi!\n> > \n> > I\'d strongly suggest looking at the diskimage-builder project that\'s\n> > part of the TripleO program. Someone has already done a POC of turning\n> > it in to an aaS, and there are already people working on tying\n> > diskimage-builder elements and heat templates. Given that OpenStack has\n> > prior art and work in this direction, you should be able to accelerate\n> > getting to your goals pretty quickly.\n> \n> diskimage-builder is definitely a primary tool choice for an openstack deployer creating vm images, and should certainly be promoted where possible.  I\'ll add an example to the doc.\n> \n> The spec does try to be agnostic to the actual image creation technology in play - organizations using containers or Windows images may have alternative preferences about the underlying mechanism by which they generate images.  Decoupling the image creation from how the image is used is a key goal, especially since organizations often want to separate environment preparation and development along role lines.\n\nWindows images are special, yes. For those, perhaps chat with the Murano\nfolk?\n\nContainers will work fine in diskimage-builder. One only needs to hack\nin the ability to save in the container image format rather than qcow2.\n\nI actually think diskimage-builder would be really useful for container\nbuilding, as it doesn\'t make any assumptions about things like having a\nkernel. In fact we\'ve discussed the possibility of using lxc to do the\nimage builds instead of chroot so that the builds would be more\nisolated from the build host.\n\n\n','<20321551-45E1-448C-A366-118493C8537D@redhat.com>',NULL),('<1385313971-sup-9787@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-24 09:55:44',-28800,'2013-11-24 17:55:44',NULL,'[openstack-dev] [Solum] git-Integration working group','Excerpts from Adrian Otto\'s message of 2013-11-22 18:51:16 -0800:\n> Monty,\n> \n> On Nov 22, 2013, at 6:24 PM, Monty Taylor <mordred at inaugust.com>\n>  wrote:\n> \n> > On 11/22/2013 05:37 PM, Krishna Raman wrote:\n> >> Hello all,\n> >> \n> >> I would like to kickoff the Git integration discussion. Goal of this\n> >> subgroup is to go through the git-integration blueprint [1] and break it\n> >> up into smaller blueprints that we can execute on.\n> >> \n> >> We have to consider 2 workflows:\n> >>   1) For Milestone 1, pull based git workflow where user uses a public\n> >> git repository (possibly on github) to trigger the build\n> >>   2) For later milestones, a push based workflow where the git\n> >> repository is maintained by Solum\n> > \n> > Hi!\n> \n> Hi, thanks for chiming in here.\n> \n> > I\'m a little disappointed that we\'ve decided to base the initial\n> > workflow on something that is not related to the world-class git-based\n> > developer tooling that the OpenStack project has already produced. We\n> > have a GIANT amount of tooling in this space, and it\'s all quite\n> > scalable. There is also the intent by 3 or 4 different groups to make it\n> > more re-usable/re-consumable, including thoughts in making sure that we\n> > can drive it from and have it consume heat.\n> \n> The initial work will be something pretty trivial. It\'s just a web hook on a git push. The workflow in this case is not customizable, and has basically no features. The intent is to iterate on this to make it much more compelling over time, soon after the minimum integration, we will put a real workflow system in place. We did discuss Zuul and Nodepool, and nobody had any objection to learning more about those. This might be a bit early in our roadmap to be pulling them in, but if there is an easy way to use them early in our development, we\'d like to explore that.\n> \n\nZuul and nodepool are things to optimize large scale testing. git-review\nand gerrit, on the other hand, are the frontend that it sounds like\nthis trivial \"just a push\" process would try to replace. I don\'t think\nit is wise to ignore the success of those two pieces of the OpenStack\ninfrastructure. If what you\'re doing is only ever going to be a simple\npush, so be it. However, I doubt that it will remain so simple.\n\nIs there some reason _not_ to just consume these as-is?\n\n> >> Devdatta has created 2 blueprints for consideration: [2] [3]\n> >> \n> >> I have set up a doodle to poll for a /recurring/ meeting time for this\n> >> subgroup: http://doodle.com/7wypkzqe9wep3d33#table   (Timezone support\n> >> is enabled)\n> >> \n> >> Currently the plan is to try G+ hangouts to run this meetings and scribe\n> >> on #solum. This will limit us to a\n> >> max of 10 participants. If we have more interest, we will need to see\n> >> how to change the meetings.\n> > \n> > We have IRC meeting channels for meetings. They are logged - and they\n> > have the benefit that they do not require non-Open Source software to\n> > access. If you have them in IRC, the team from OpenStack who is already\n> > working on developer workflow around git can potentially participate.\n> > \n> > I don\'t mean to be negative, but if you want to be a PaaS for OpenStack,\n> > I would strongly consider not using G+ when we have IRC, and I would\n> > strongly suggest engaging with the Infra projects that already know how\n> > to do git-based workflow and action triggering.\n> \n> We just finished holding the Solum Community Design Workshop in San Francisco. We had both irc and G+ in addition to etherpad for shared notetaking. What we found is that that collaboration was faster and more effective when we used the G+ tool. The remote participants had a strong preference for it, and requested that we use it for the breakout meetings as well. The breakout design meetings will have a scribe who will transcribe the interaction in IRC so it will also be logged.\n> \n\nWe struggled with this in Ubuntu as well. Ultimately, our fine friends at\nGoogle have created what seems to be one of the most intuitive distributed\ncollaboration tools the world has ever seen. I think Monty is right,\nand that we should strive to use the tools the rest of OpenStack uses\nwhenever possible, and we should strive to be 100% self hosted.\n\nHowever, I do think G+ has enough benefit at times to deal with the fact\nthat it is not free and we can\'t really host our own.\n\n\n','<C987115E-8455-48B2-9FEF-2E055DE9771F@rackspace.com>',NULL),('<1385335704.2819.3.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 09:28:24',36000,'2013-11-24 23:28:24',NULL,'[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs\n in Nova','On Fri, 2013-11-22 at 20:07 -0600, Matt Riedemann wrote:\n> \n> On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote:\n> > On 11/22/2013 06:01 PM, Christopher Yeoh wrote:\n> >>\n> >> On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann\n> >> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>> wrote:\n> >>\n> >>      ...\n> >>      21:51:42 <dolphm> i just hope that the version discovery mechanism\n> >>      is smart enough to realize when it\'s handed a versioned endpoint,\n> >>      and happily run with that\n> >>      ...\n> >>      21:52:00 <dolphm> (by calling that endpoint and doing proper discovery)\n> >>      ...\n> >>      21:52:24 <russellb> dolphm: yeah, need to handle that gracefully ...\n> >>\n> >>\n> >>\n> >> Just one point here (and perhaps I\'m misunderstanding what was meant),\n> >> but if the catalog points to a versioned endpoint\n> >> shouldn\'t we just use that version rather than trying to discover what\n> >> other versions may be\n> >> available. Although we\'ll have cases of it just being set to a versioned\n> >> endpoint because thats how it\n> >> has been done in the past I think we should be making the assumption\n> >> that if we\'re pointed to a specific version,\n> >> that is the one we should be using.\n> >\n> > Agreed, and I think that\'s what Dolph and I meant.\n> >\n> \n> That also covers the override case that was expressed a few different \n> times in this thread, giving the admin the ability to pin his \n> environment to the version he knows and trusts during, for example, \n> upgrades, and then slowly transitioning to a newer API.  The nice thing \n> with that approach is it should keep config options with hard-coded \n> versions out of nova.conf which is what was being proposed in the \n> glance and cinder v2 blueprint patches.\n\nSo the way we have this in keystone at least is that querying GET / will\nreturn all available API versions and querying /v2.0 for example is a\nsimilar result with just the v2 endpoint. So you can hard pin a version\nby using the versioned URL. \n\nI spoke to somebody the other day about the discovery process in\nservices. The long term goal should be that the service catalog contains\nunversioned endpoints and that all clients should do discovery. For\nkeystone the review has been underway for a while now:\nhttps://review.openstack.org/#/c/38414/ the basics of this should be\nable to be moved into OSLO for other projects if required. \n\nJamie\n\n> --\n> \n> Thanks,\n> \n> Matt Riedemann\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<52900DFB.2030107@linux.vnet.ibm.com>',NULL),('<1385356795-sup-4773@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 01:23:44',-28800,'2013-11-25 09:23:44',NULL,'[openstack-dev] Unwedging the gate','Excerpts from Joe Gordon\'s message of 2013-11-24 21:00:58 -0800:\n> Hi All,\n> \n> TL;DR Last week the gate got wedged on nondeterministic failures. Unwedging\n> the gate required drastic actions to fix bugs.\n> \n> \n<snip>\n\n(great write-up, thank you for the details, and thank you for fixing\nit!)\n\n> \n> Now that we have the gate back into working order, we are working on the\n> next steps to prevent this from happening again.  The two most immediate\n> changes are:\n> \n>    - Doing a better job of triaging gate bugs  (\n>    http://lists.openstack.org/pipermail/openstack-dev/2013-November/020048.html\n>     ).\n> \n> \n>    - In the next few days we will remove  \'reverify no bug\' (although you\n>    will still be able to run \'reverify bug x\'.\n> \n\nI am curious, why not also disable \'recheck no bug\'?\n\nI see this as a failure of bug triage. A bug that has more than 1\nrecheck/reverify attached to it is worth a developer\'s time. The data\ngathered through so many test runs is invaluable when chasing races like\nthe ones that cause these intermittent failures. If every core dev of\nevery project spent 10 working minutes every day looking at the rechecks\npage to see if there is an untriaged recheck there, or just triaging bugs\nin general, I suspect we\'d fix these a lot quicker.\n\nI do wonder if we would be able to commit enough resources to just run\ntwo copies of the gate in parallel each time and require both to pass.\nDoubling the odds* that we will catch an intermittent failure seems like\nsomething that might be worth doubling the compute resources used by\nthe gate.\n\n*I suck at math. Probably isn\'t doubling the odds. Sounds\ngood though. ;)\n\n\n','<CAHXdxOfH9o_bzvgqxXh9e=sja+f=k3ns7jHBEb-80zYBLkFDkA@mail.gmail.com>',NULL),('<1385384136.2867037@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 07:55:36',-18000,'2013-11-25 12:55:36',NULL,'[openstack-dev] [Glance] Regarding Glance\'s behaviour when\n	updating an image ...','Hey David,\n\nI noticed the same thing a couple of days ago and had filed this bug: https://bugs.launchpad.net/glance/+bug/1249409\n\nGlance v2 api should not be allowing re-uploads IMO. Feel free to add to the comments there.\n\nThanks,\nIccha\n\n-----Original Message-----\nFrom: \"David koo\" <david.koo at huawei.com>\nSent: Sunday, November 24, 2013 10:23pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Glance] Regarding Glance\'s behaviour when updating an image ...\n\nHi All,\n\n    Newbie stacker here ...\n\n    I have a basic question regarding the indended behaviour of Glance\'s\nimage update API: What is the indended behaviour of Glance when updating\nan already uploaded image file?\n\n    The functional test indicates that the intended behaviour is to\ndisallow such updates:\n        glance/tests/v2/test_images.py:test_image_lifecycle:210\n            # Uploading duplicate data should be rejected with a 409\n            ...\n\n    When I configure Glance to use the local filesystem backend I do\nindeed get a 409 conflict but when I configure Glance to use Swift as\nthe backend the operation succeeds and the original image file is\nreplaced.\n\n    On a related note, when using the local filesystem backend though I\nget a 409 conflict, it leaves the image in the \"saving\" state - I think\nit shouldn\'t change the state of the image. There\'s a bug logged\nregarding this behaviour (bug 1241379) and I\'m working on the fix. But\nin light of the above question perhaps I should file another bug\nregarding the Swift storage backend?\n\n--\nKoo\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<B5A18EA8FCC1814E9B14B968A3C370423D9B5CE4@SZXEMA510-MBX.china.huawei.com>',NULL),('<1385398039-sup-449@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 08:54:51',-28800,'2013-11-25 16:54:51',NULL,'[openstack-dev] Unwedging the gate','Excerpts from Robert Collins\'s message of 2013-11-25 01:30:11 -0800:\n> On 25 November 2013 22:23, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > I do wonder if we would be able to commit enough resources to just run\n> > two copies of the gate in parallel each time and require both to pass.\n> > Doubling the odds* that we will catch an intermittent failure seems like\n> > something that might be worth doubling the compute resources used by\n> > the gate.\n> >\n> > *I suck at math. Probably isn\'t doubling the odds. Sounds\n> > good though. ;)\n> \n> We already run the code paths that were breaking 8 or more times.\n> Hundreds of times in fact for some :(.\n> \n> The odds of a broken path triggering after it gets through, assuming\n> each time we exercise it is equally likely to show it, are roughly\n> 3/times-exercised-in-landing. E.g. if we run a code path 300 times and\n> it doesn\'t show up, then it\'s quite possible that it has a 1%\n> incidence rate.\n\nWe don\'t run through 300 times of the same circumstances. We may pass\nthrough indidivual code paths that have a race condition 300 times, but\nthe circumstances are probably only right for failure in 1 or 2 of them.\n\n1% overall then, doesn\'t matter so much as how often does it fail when\nthe conditions for failure are optimal. If we can increase the ocurrences\nof the most likely failure conditions, then we do have a better chance\nof catching the failure.\n\n\n','<CAJ3HoZ01=bqChogOWRbecqdEOtGr-wGPk2Px+bqWfCSoeqXCUA@mail.gmail.com>',NULL),('<1385398495-sup-1187@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 09:55:03',-28800,'2013-11-25 17:55:03',NULL,'[openstack-dev] Unwedging the gate','Excerpts from Monty Taylor\'s message of 2013-11-25 06:52:02 -0800:\n> \n> On 11/25/2013 04:23 AM, Clint Byrum wrote:\n> > Excerpts from Joe Gordon\'s message of 2013-11-24 21:00:58 -0800:\n> >> Hi All,\n> >>\n> >> TL;DR Last week the gate got wedged on nondeterministic failures. Unwedging\n> >> the gate required drastic actions to fix bugs.\n> >>\n> >>\n> > <snip>\n> > \n> > (great write-up, thank you for the details, and thank you for fixing\n> > it!)\n> > \n> >>\n> >> Now that we have the gate back into working order, we are working on the\n> >> next steps to prevent this from happening again.  The two most immediate\n> >> changes are:\n> >>\n> >>    - Doing a better job of triaging gate bugs  (\n> >>    http://lists.openstack.org/pipermail/openstack-dev/2013-November/020048.html\n> >>     ).\n> >>\n> >>\n> >>    - In the next few days we will remove  \'reverify no bug\' (although you\n> >>    will still be able to run \'reverify bug x\'.\n> >>\n> > \n> > I am curious, why not also disable \'recheck no bug\'?\n> \n> recheck no bug still has a host of valid use cases. Often times I use it\n> when I upload a patch, it fails because of a thing somewhere else, we\n> fix that, and I need to recheck the patch because it should work now.\n> \n> It\'s also not nearly as dangerous as reverify no bug.\n> \n\n\"...somewhere else, we fix that...\" -- Would it be useful to track that\nin a bug? Would that help elastic-recheck work better if all the problems\ncaused by a bug elsewhere were reported as bugs?\n\n\n','<52936412.9050305@inaugust.com>',NULL),('<1385399929.7250.1.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 11:18:49',-21600,'2013-11-25 17:18:49',NULL,'[openstack-dev] [Nova] Remove ratelimits from nova v3 api','On Mon, 2013-11-25 at 07:38 -0500, David Hill wrote:\n>    Is removing the ratelimiting code part of the roadmap?  I fear that\n> if it\'s removed now, it may have to be re-implemented in the future as\n> the cloud deployments become more mainstream ... Without ratelimit,\n> some evil users could DOS Openstack !\n\nI\'m going to suggest that something like Turnstile[1] with\nnova_limits[2] is the way to go here for ratelimiting.\n\n[1] https://pypi.python.org/pypi/turnstile\n[2] https://pypi.python.org/pypi/nova_limits\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<710D4D6CE160654C87478D18385BB997267BE4F56B@MDC-MAIL-CMS01.ubisoft.org>',NULL),('<1385422095-sup-8659@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 15:46:45',-28800,'2013-11-25 23:46:45',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Tim Schnell\'s message of 2013-11-25 14:51:39 -0800:\n> Hi Steve,\n> \n> As one of the UI developers driving the requirements behind these new\n> blueprints I wanted to take a moment to assure you and the rest of the\n> Openstack community that the primary purpose of pushing these requirements\n> out to the community is to help improve the User Experience for Heat for\n> everyone. Every major UI feature that I have implemented for Heat has been\n> included in Horizon, see the Heat Topology, and these requirements should\n> improve the value of Heat, regardless of the UI.\n> \n> \n> Stack/template metadata\n> We have a fundamental need to have the ability to reference some\n> additional metadata about a template that Heat does not care about. There\n> are many possible use cases for this need but the primary point is that we\n> need a place in the template where we can iterate on the schema of the\n> metadata without going through a lengthy design review. As far as I know,\n> we are the only team attempting to actually productize Heat at the moment\n> and this means that we are encountering requirements and requests that do\n> not affect Heat directly but simply require Heat to allow a little wiggle\n> room to flesh out a great user experience.\n> \n\nWiggle room is indeed provided. But reviewers need to understand your\nmotivations, which is usually what blueprints are used for. If you\'re\ngetting push back, it is likely because your blueprints to not make the\nuse cases and long term vision obvious.\n\n> There is precedence for an optional metadata section that can contain any\n> end-user data in other Openstack projects and it is necessary in order to\n> iterate quickly and provide value to Heat.\n> \n\nNobody has said you can\'t have meta-data on stacks, which is what other\nprojects use.\n\n> There are many use cases that can be discussed here, but I wanted to\n> reiterate an initial discussion point that, by definition,\n> \"stack/template_metadata\" does not have any hard requirements in terms of\n> schema or what does or does not belong in it.\n> \n> One of the initial use cases is to allow template authors to categorize\n> the template as a specific \"type\".\n> \n>     template_metadata:\n>         short_description: Wordpress\n> \n>     \n\nInteresting. Would you support adding a \"category\" keyword to python so\nwe don\'t have to put it in setup.cfg and so that the egg format doesn\'t\nneed that section? Pypi can just parse the python to categorize the apps\nwhen they\'re uploaded. We could also have a file on disk for qcow2 images\nthat we upload to glance that will define the meta-data.\n\nTo be more direct, I don\'t think the templates themselves are where this\nmeta-data belongs. A template is self-aware by definition, it doesn\'t\nneed the global metadata section to tell it that it is WordPress. For\nanything else that needs to be globally referenced there are parameters.\nHaving less defined inside the template means that you get _more_ wiggle\nroom for your template repository.\n\nI 100% support having a template catalog. IMO it should be glance,\nwhich is our catalog service in OpenStack. Who cares if nova or heat are\nconsuming images or templates. It is just sharable blobs of data and\nmeta-data in a highly scalable service. It already has the concept of\nglobal and tenant-scope. It just needs an image type of \'hot\' and then\nheat can start consuming templates from glance. And the template authors\nshould maintain some packaging meta-data in glance to communicate to\nusers that this is \"Wordpress\" and \"Single-Node\". If Glance\'s meta-data\nis too limiting, expand it! I\'m sure image authors and consumers would\nappreciate that.\n\n> This would let the client of the Heat API group the templates by type\n> which would create a better user experience when selecting or managing\n> templates. The the end-user could select \"Wordpress\" and drill down\n> further to select templates with different options, \"single node\", \"2 web\n> nodes\", etc...\n> \n\nThat is all api stuff, not language stuff.\n\n> Once a feature has consistently proven that it adds value to Heat or\n> Horizon, then I would suggest that we can discuss the schema for that\n> feature and codify it then.\n> \n> In order to keep the discussion simple, I am only responding to the need\n> for stack/template metadata at the moment but I\'m sure discussions on the\n> management api and template catalog will follow.\n> \n\nYour example puts the template catalog in front of this feature, and I\nthink that exposes this feature as misguided.\n\n\n','<CEB93046.6F72%tim.schnell@rackspace.com>',NULL),('<1385448146.95008.YahooMailBasic@web162902.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-11-25 22:42:26',-28800,'2013-11-26 06:42:26',NULL,'[OpenStack-Infra] Subscription to the TryStack facebook Group','HI Team\n\nI am Prasanna Viswakumar,  with Cisco Systems Bangalore.  \n\n \nI placed a request sometime ago to get myself enrolled to the Trystack facebook group\nso that I can start to use TryStack.   We need this as we plan to integrate OpenStack\nwith one of our products.\n\n Am yet to get approved.  Can someone help ? Appreciate it in advance.\n\nBest\nPrasanna, V\n\n\n',NULL,NULL),('<1385484624.4379.28.camel@hp-a6734f>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-26 11:50:24',-18000,'2013-11-26 16:50:24',NULL,'[Openstack] Ubuntu Image for VM','On Tue, 2013-11-26 at 08:41 +0000, Sahid Ferdjaoui wrote:\n> Hi Mahardhika,\n> \n>     http://cloud-images.ubuntu.com/\n> \n> They are resized during the boot.\n> s.\n\nHi, just to note: The Ubuntu 10.04 (lucid) qcow images on the\ncloud-images site don\'t automatically resize. The Amazon-style (AMI/AKI)\nones do. This is due to Ubuntu 10.04 having an outdated version of the\n\"cloud-init\" package installed.\n\nThis issue only affects the Ubuntu 10.04 images; 12.04 and all newer\nversions do resize the qcow2 images correctly on first boot.\n\n-- \nCalvin Walton <calvin.walton at kepstin.ca>\n\n\n\n','<248306297.17538009.1385455298963.JavaMail.root@cloudwatt.com>',NULL),('<1385489214-sup-5259@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 10:19:20',-28800,'2013-11-26 18:19:20',NULL,'[openstack-dev] [all project] Treating recently seen recheck\n	bugs as critical across the board','Excerpts from Thierry Carrez\'s message of 2013-11-26 03:23:51 -0800:\n> Dolph Mathews wrote:\n> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins\n> > <robertc at robertcollins.net <mailto:robertc at robertcollins.net>> wrote:\n> > \n> >     So my proposal is that we make it part of the base hygiene for a\n> >     project that any recheck bugs being seen (either by elastic-recheck or\n> >     manual inspection) be considered critical and prioritised above\n> >     feature work.\n> > \n> > I agree with the notion here (that fixing transient failures is\n> > critically high priority work for the community) -- but marking the bug\n> > as \"critical\" priority is just a subjective abuse of the priority field.\n> > A non-critical bug is not necessarily non-critical work. The \"critical\"\n> > status should be reserved for issues that are actually non-shippable,\n> > catastrophically breaking issues.\n> \n> It\'s a classic bugtracking dilemma where the \"Importance\" field is both\n> used to describe bug impact and priority... while they don\'t always match.\n> \n\nIf I\'m on the fence between 1 importance or the other, I look at the bug\nlist of the two importance lists:\n\nFor instance, there are all 122 High importance bugs in Nova, and 6\nCritical bugs.\n\nIf we are comfortable with developers choosing to fix all 122 of the other\nHigh bugs before this bug, then make it High. If not, make it Critical.\nLikewise, if we are uncomfortable with this bug being chosen before any\nof the 6 Critical bugs, then make it High.\n\nI realize those two choices could make a person uncomfortable and wish for\nsomething in-between like \"Hitical\" or \"Criticigh\", but micro-management\nis no way to actually get things done and it does only take a few seconds\nto reprioritize as we add insight and data over time.\n\n> That said, the \"impact\" of those bugs, considering potential development\n> activity breakage, *is* quite critical (they all are timebombs which\n> will create future gate fails if not handled at top priority).\n> \n> So I think marking them Critical + tagging them is not that much of an\n> abuse, if we start including the gate impact in our bug Impact\n> assessments. That said, I\'m also fine with High+Tag, as long as it\n> triggers the appropriate fast response everywhere.\n> \n\nIMO the tags are a distraction to triage. Critical or High is enough of\na conundrum to resolve. The tags will certainly help guide trackers, and\nthey should add them, but the person doing triage should mostly focus on\n\"will the patient die?\" type questions.\n\n\n','<529484C7.9060108@openstack.org>',NULL),('<1385504183.4314.108.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:16:23',0,'2013-11-26 22:16:23',NULL,'[openstack-dev] [Nova] Proposal to re-add Dan Prince to\n nova-core','On Tue, 2013-11-26 at 14:32 -0500, Russell Bryant wrote:\n> Greetings,\n> \n> I would like to propose that we re-add Dan Prince to the nova-core\n> review team.\n> \n> Dan Prince has been involved with Nova since early in OpenStack\'s\n> history (Bexar timeframe).  He was a member of the nova-core review team\n> from May 2011 to June 2013.  He has since picked back up with nova\n> reviews [1].  We always say that when people leave nova-core, we would\n> love to have them back if they are able to commit the time in the\n> future.  I think this is a good example of that.\n> \n> Please respond with +1s or any concerns.\n\nNice, definitely agree.\n\nMark.\n\n\n\n','<5294F75E.8090102@redhat.com>',NULL),('<1385504802.4314.112.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:26:42',0,'2013-11-26 22:26:42',NULL,'[openstack-dev] [nova] [QA] Triaging Bugs during Review','On Tue, 2013-11-26 at 13:06 -0800, Vishvananda Ishaya wrote:\n> Hi Everyone,\n> \n> I tend to follow merges and look for valuable havana backports. A few bug\n> fixes have merged recently where the associated bug is untriaged (i.e. the\n> severity is listed as \'Unknown\'). I assume that reviewers of a bugfix\n> patch are viewing the associated bugs. It makes sense for core-reviewers\n> to do some related bug triaging work in the process. It also would be\n> very helpful if they could be tagged for potential backport at the same time.\n> \n> So I\'m suggesting two things during review:\n> \n> 1. If you are reviewing a patch and the severity of the associated bug is\n>    set as unknown, then you set an appropriate severity[1].\n> 2. If the bug is important and seems relatively self-contained that you\n>    mark it with the havana-backport-potential tag during review.\n> \n> These two things should only take a matter of seconds, and will greatly help\n> the stable-maintainers team.\n> \n> I will add these responsibilities to the review checklist[2] unless I hear\n> some disagreement here.\n\nFWIW, I totally agree and do this out of habit. Thanks for raising it.\n\nBut ... oh wow! We have 103 Nova bugs tagged with\nhavana-backport-potential?\n\n  https://bugs.launchpad.net/nova/+bugs?field.tag=havana-backport-potential\n\nAre some of these getting backported but the tag isn\'t being removed?\nThe thinking originally was that the tag would be removed as soon as a\nhavana task for the bug was opened.\n\nMark.\n\n\n\n','<5CEE170C-8051-43C9-82A5-4DA952252F36@gmail.com>',NULL),('<1385505557.4314.121.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:39:17',0,'2013-11-26 22:39:17',NULL,'[openstack-dev] [all project] Treating recently seen recheck\n bugs as critical across the board','On Tue, 2013-11-26 at 12:29 -0800, Joe Gordon wrote:\n> On Nov 26, 2013 8:48 AM, \"Dolph Mathews\" <dolph.mathews at gmail.com> wrote:\n> >\n> >\n> > On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <thierry at openstack.org>\n> wrote:\n> >>\n> >> Dolph Mathews wrote:\n> >> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins\n> >> > <robertc at robertcollins.net <mailto:robertc at robertcollins.net>> wrote:\n> >> >\n> >> >     So my proposal is that we make it part of the base hygiene for a\n> >> >     project that any recheck bugs being seen (either by\n> elastic-recheck or\n> >> >     manual inspection) be considered critical and prioritised above\n> >> >     feature work.\n> >> >\n> >> > I agree with the notion here (that fixing transient failures is\n> >> > critically high priority work for the community) -- but marking the bug\n> >> > as \"critical\" priority is just a subjective abuse of the priority\n> field.\n> >> > A non-critical bug is not necessarily non-critical work. The \"critical\"\n> >> > status should be reserved for issues that are actually non-shippable,\n> >> > catastrophically breaking issues.\n> >>\n> >> It\'s a classic bugtracking dilemma where the \"Importance\" field is both\n> >> used to describe bug impact and priority... while they don\'t always\n> match.\n> >\n> >\n> > ++\n> >\n> >>\n> >> That said, the \"impact\" of those bugs, considering potential development\n> >> activity breakage, *is* quite critical (they all are timebombs which\n> >> will create future gate fails if not handled at top priority).\n> >\n> >\n> > I generally agree, but I don\'t think it\'s fair to say that the impact of\n> a transient is universally a single priority, either. Some transient issues\n> occur more frequently and therefore have higher impact.\n> >\n> >>\n> >> So I think marking them Critical + tagging them is not that much of an\n> >> abuse, if we start including the gate impact in our bug Impact\n> >> assessments. That said, I\'m also fine with High+Tag, as long as it\n> >> triggers the appropriate fast response everywhere.\n> >\n> >\n> > I\'m fine with starting them at High, and elevating to Critical as\n> appropriate.\n> >\n> > Is the idea here to automatically apply a tag + priority as a result of\n> \"recheck/reverify bug X\" ? (as long as existing priority isn\'t overwritten!)\n> \n> I certainly hope we don\'t automatically set priority based on raw recheck\n> data. We have a second list of bugs that we feed to elastic-recheck this\n> list is reviewed for duplicates and include fingerprints see we can better\n> assess the bug frequency.  I think the idea is to mark bugs from that list\n> as critical.  I also think it should be a manual process. As a bug should\n> be reviewed (does it have enough detail etc) before setting it to critical.\n\n[Just to circle back and clarify my ?0.02c during the TC and project\nmeetings tonight]\n\nAny recheck bug which appears regularly in the graphs here:\n\n  http://status.openstack.org/elastic-recheck/\n\nmeans that a human has looked at it, determined a fingerprint for it, we\nhave a bunch of details about it and we have data as to it\'s regularity.\nAny such bug is fair game to be marked Critical.\n\nIf it is still there a month later, but no-one is making any progress on\nit and it\'s happening pretty irregularly ... then I think we\'ll see a\ndesire to move it back from Critical to High again so that the Critical\nlist isn\'t cluttered with stuff people are no longer paying close\nattention to.\n\nSo, yeah - the intent sounds good to me.\n\nThanks,\nMark.\n\n\n\n','<CAHXdxOdiWNB0V6aZq+Qupd4NQazhYxwbcmVjPZ5NV4dZ+tf1HQ@mail.gmail.com>',NULL),('<1385506492.4314.123.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:54:52',0,'2013-11-26 22:54:52',NULL,'[openstack-dev] [Oslo] Improving oslo-incubator update.py','On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:\n> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco <flavio at redhat.com> wrote:\n> \n> > Greetings,\n> >\n> > Based on the recent discussion that came out about not having enough\n> > information in the commit message when syncing oslo-incubator modules,\n> > I was thinking that besides encouraging people to write better commit\n> > messages, we could also improve the script we use to sync those\n> > modules.\n> >\n> > Some of the changes that I\'ve been thinking of:\n> >\n> >    1) Store the commit sha from which the module was copied from.\n> >    Every project using oslo, currently keeps the list of modules it\n> >    is using in `openstack-modules.conf` in a `module` parameter. We\n> >    could store, along with the module name, the sha of the commit it\n> >    was last synced from:\n> >\n> >        module=log,commit\n> >\n> >        or\n> >\n> >        module=log\n> >        log=commit\n> >\n> \n> The second form will be easier to manage. Humans edit the module field and\n> the script will edit the others.\n\nHow about adding it as a comment at the end of the python files\nthemselves and leaving openstack-common.conf for human editing?\n\nMark.\n\n\n\n','<CADb+p3Qy6qY++iwdp5u9cVz06xOa-sQqegpRkui5fVPD8id3tQ@mail.gmail.com>',NULL),('<1385506716.4314.127.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:58:36',0,'2013-11-26 22:58:36',NULL,'[openstack-dev] [Oslo] Improving oslo-incubator update.py','On Fri, 2013-11-22 at 16:24 +0000, Duncan Thomas wrote:\n> On 22 November 2013 14:59, Ben Nemec <openstack at nemebean.com> wrote:\n> \n> > One other thought I had was to add the ability to split one Oslo sync up\n> > into multiple commits, either one per module, or even one per Oslo commit\n> > for some really large module changes (I\'m thinking of the 1000 line db sync\n> > someone mentioned recently).  It would be more review churn, but at least it\n> > would keep the changes per review down to a more reasonable level.   I\'m not\n> > positive it would be beneficial, but I thought I\'d mention it.\n> \n> Cinder (often but not always me) tends to reject merges that do more\n> that one module at a time, because it makes it far harder to review\n> and spot problems, so some from of automation of this would be great.\n\nYes, it\'s good practice to sync related changes in individual commits,\nrather than one big oslo sync.\n\nAn example from a previous sync I did in Cinder:\n\n  https://review.openstack.org/#/c/12409/ (cfg)\n  https://review.openstack.org/#/c/12411/ (zmq)\n  https://review.openstack.org/#/c/12410/ (notifier)\n  https://review.openstack.org/#/c/12412/ (misc)\n\nThese were all proposed at the same time, but I split related notable\nchanges into their own commits and then had a \"misc\" sync for more\ntrivial stuff.\n\nMark.\n\n\n\n','<CAOyZ2aEaUrzTNGeoxT9yejbxqKfvxaDmsfRuf+1HBSKN7fcNGQ@mail.gmail.com>',NULL),('<1385508956.4314.132.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 23:35:56',0,'2013-11-26 23:35:56',NULL,'[openstack-dev] How to best make User Experience a priority in\n every project','On Wed, 2013-11-20 at 11:06 -0600, Dean Troyer wrote:\n> On Wed, Nov 20, 2013 at 9:09 AM, Thierry Carrez <thierry at openstack.org>wrote:\n> \n> > However, as was apparent in the Technical Committee meeting discussion\n> >\n> about it yesterday, most of us are not convinced that establishing and\n> > blessing a separate team is the most efficient way to give UX the\n> > attention it deserves. Ideally, UX-minded folks would get active\n> > *within* existing project teams rather than form some sort of\n> > counter-power as a separate team. In the same way we want scalability\n> > and security mindset to be present in every project, we want UX to be\n> > present in every project. It\'s more of an advocacy group than a\n> > \"program\" imho.\n> >\n> \n> Having been working on a cross-project project for a while now I can\n> confirm that there is a startling lack of coordination between projects on\n> the same/similar tasks.  Oslo was a HUGE step toward reducing that and\n> providing a good reference for code and libraries.  There is nothing today\n> for the intangible parts that are both user and developer facing such as\n> common message (log) formats, common terms (tenant vs project) and so on.\n> \n> I think the model of the OSSG is a good one.  After reading the log of\n> yesterday\'s meeting I think I would have thrown in that the need from my\n> perspective is for a coordination role as much as anything.\n> \n> The deliverables in the UX Program proposal seem a bit fuzzy to me as far\n> as what might go into the repo.  If it is interface specs, those should be\n> in either the project code repos docs/ tree or in the docs project\n> directly.  Same for a Human Interface Guide (HIG) that both Horizon and OSC\n> have (well, I did steal a lot of OSC\'s guide from Horizon\'s).\n\nOne straightforward example I could imagine from a UX Program is a REST\nAPI design guide which captures the current common patterns between our\ncurrent APIs and points the way for common patterns new APIs should aim\nto adopt. Same for our CLIs.\n\nOr you could imagine a set of terminology/concept definitions - project\nvs tenant anyone? :)\n\nBut, I think the basic point is that a group with common interests\nshould work on producing some concrete deliverables before being asked\nto be recognized as an official program.\n\nMark.\n\n\n\n','<CAOJFoEs+U-vQYWGeUdZNijmgD4VqEJJ3wB3Dn+gr2fGCzZSeSA@mail.gmail.com>',NULL),('<1385527225.13993.52565569.1DC16F4E@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-26 20:40:25',-28800,'2013-11-27 04:40:25',NULL,'[Openstack] Neutron crashing on controller node','I posted this on ask.openstack.org but didn\'t receive any responses so\ntrying here.\n\nI am on CentOS 6.4 and trying to setup Neutron. Unfortunately I\'m\ngetting a crash when starting on this server. The snipped server.log\nfile is...\n\n2013-11-25 23:41:16.756 8105 INFO neutron.common.config [-] Logging\nenabled!\n2013-11-25 23:41:16.757 8105 ERROR neutron.common.legacy [-] Skipping\nunknown group key: firewall_driver\n2013-11-25 23:41:16.762 8105 INFO neutron.common.config [-] Config paste\nfile: /etc/neutron/api-paste.ini\n2013-11-25 23:41:16.822 8105 INFO neutron.manager [-] Loading Plugin:\nneutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2\n2013-11-25 23:41:16.974 8105 INFO\nneutron.plugins.openvswitch.ovs_neutron_plugin [-] Network VLAN ranges:\n{}\n2013-11-25 23:41:17.009 8105 INFO\nneutron.plugins.openvswitch.ovs_neutron_plugin [-] Tunnel ID ranges:\n[(1, 1000)]\n2013-11-25 23:41:17.093 8105 ERROR neutron.service [-] In serve_wsgi()\n2013-11-25 23:41:17.093 8105 TRACE neutron.service Traceback (most\nrecent call last):\n2013-11-25 23:41:17.093 8105 TRACE neutron.service   File\n\"/usr/lib/python2.6/site-packages/neutron/service.py\", line 96, in\nserve_wsgi\n2013-11-25 23:41:17.093 8105 TRACE neutron.service     service.start()\n2013-11-25 23:41:17.093 8105 TRACE neutron.service   File\n\"/usr/lib/python2.6/site-packages/neutron/service.py\", line 65, in start\n2013-11-25 23:41:17.093 8105 TRACE neutron.service     self.wsgi_app =\n_run_wsgi(self.app_name)\n2013-11-25 23:41:17.093 8105 TRACE neutron.service   File\n\"/usr/lib/python2.6/site-packages/neutron/service.py\", line 109, in\n_run_wsgi\n2013-11-25 23:41:17.093 8105 TRACE neutron.service     app =\nconfig.load_paste_app(app_name)\n2013-11-25 23:41:17.093 8105 TRACE neutron.service   File\n\"/usr/lib/python2.6/site-packages/neutron/common/config.py\", line 144,\nin load_paste_app\n2013-11-25 23:41:17.093 8105 TRACE neutron.service     app =\ndeploy.loadapp(\"config:%s\" % config_path, name=app_name)\n2013-11-25 23:41:17.093 8105 TRACE neutron.service   File\n\"/usr/lib/python2.6/site-packages/PasteDeploy-1.5.0-py2.6.egg/paste/deploy/loadwsgi.py\",\nline 247, in load\napp\n<snip>\n2013-11-25 23:41:17.098 8105 TRACE neutron   File\n\"/usr/lib/python2.6/site-packages/oslo/config/cfg.py\", line 1583, in\n__inner\n2013-11-25 23:41:17.098 8105 TRACE neutron     result = f(self, *args,\n**kwargs)\n2013-11-25 23:41:17.098 8105 TRACE neutron   File\n\"/usr/lib/python2.6/site-packages/oslo/config/cfg.py\", line 1743, in\nregister_cli_opts\n2013-11-25 23:41:17.098 8105 TRACE neutron    \nself.register_cli_opt(opt, group, clear_cache=False)\n2013-11-25 23:41:17.098 8105 TRACE neutron   File\n\"/usr/lib/python2.6/site-packages/oslo/config/cfg.py\", line 1587, in\n__inner\n2013-11-25 23:41:17.098 8105 TRACE neutron     return f(self, *args,\n**kwargs)\n2013-11-25 23:41:17.098 8105 TRACE neutron   File\n\"/usr/lib/python2.6/site-packages/oslo/config/cfg.py\", line 1735, in\nregister_cli_opt\n2013-11-25 23:41:17.098 8105 TRACE neutron     raise\nArgsAlreadyParsedError(\"cannot register CLI option\")\n2013-11-25 23:41:17.098 8105 TRACE neutron ArgsAlreadyParsedError:\narguments already parsed: cannot register CLI option\n2013-11-25 23:41:17.098 8105 TRACE neutron\n\nWhat appears to be wrong?\n\n\n',NULL,NULL),('<1385527361-sup-3149@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:28:49',-28800,'2013-11-27 06:28:49',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Tim Schnell\'s message of 2013-11-26 13:24:22 -0800:\n> So the originally question that I attempted to pose was, \"Can we add a\n> schema-less metadata section to the template that can be used for a\n> variety of purposes?\". It looks like the answer is no, we need to discuss\n> the features that would go in the metadata section and add them to the HOT\n> specification if they are viable. I don\'t necessarily agree with this\n> answer but I accept it as viable and take responsibility for the\n> long-winded process that it took to get to this point.\n> \n> I think some valid points have been made and I have re-focused my efforts\n> into the following proposed solution.\n> \n> I am fine with getting rid of the concept of a schema-less metadata\n> section. If we can arrive at a workable design for a few use cases then I\n> think that we won\'t need to discuss any of the options that Zane mentioned\n> for handling the metadata section, comments, separate file, or in the\n> template body.\n> \n> Use Case #1\n> I see valid value in being able to group templates based on a type or\n> keyword. This would allow any client, Horizon or a Template Catalog\n> service, to better organize and handle display options for an end-user.\n> \n> I believe that Ladislav initially proposed a solution that will work here.\n> So I will second a proposal that we add a new top-level field to the HOT\n> specification called \"keywords\" that contains this template type.\n> \n>     keywords: wordpress, mysql, etc?\n> \n\nWhat is the \"use case\" here. For me, a use case needs to be specific to\nbe useful at helping to guide more generic feature design. What I see\nabove is a generic feature specification with no actual concrete need\nfor it. These keywords should be in the template description, which\nshould be full-text searchable anyway. \"Group templates based on a type\nor keyword.\" could mean a lot of things to a lot of different classes\nof Heat users.\n\n> \n> Use Case #2\n> The template author should also be able to explicitly define a help string\n> that is distinct and separate from the description of an individual\n> parameter. An example where this use case originated was with Nova\n> Keypairs. The description of a keypair parameter might be something like,\n> \"This is the name of a nova key pair that will be used to ssh to the\n> compute instance.\" A help string for this same parameter would be, \"To\n> learn more about nova keypairs click on this help article.\"\n> \n> I propose adding an additional field to the parameter definition:\n>     \n>     Parameters:\n>         <parameter name>:\n>             description: This is the name of a nova key pair that will be used to\n> ssh to the compute instance.\n>             help: To learn more about nova key pairs click on this <a\n> href=\"/some/url/\">help article</a>.\n>\n\n+1. A help string per parameter is a fantastic idea. Sounds like a nice\nanalog to doc-strings.\n\n> Use Case #3\n> Grouping parameters would help the client make smarter decisions about how\n> to display the parameters for input to the end-user. This is so that all\n> parameters related to some database resource can be intelligently grouped\n> together. In addition to grouping these parameters together, there should\n> be a method to ensuring that the order within the group of parameters can\n> be explicitly stated. This way, the client can return a group of database\n> parameters and the template author can indicate that the database instance\n> name should be first, then the username, then the password, instead of\n> that group being returned in a random order.\n> \n>     Parameters:\n>         db_name:\n>             group: db\n>             order: 0\n>         db_username:\n>             group: db\n>             order: 1\n>         db_password:\n>             group: db\n>             order: 2\n>         web_node_name:\n>             group: web_node\n>             order: 0\n>         keypair:\n>             group: web_node\n>             order: 1\n>\n\n+1 for grouping. Your use case is perfectly specified above. Love it.\n\nHowever, your format feels very forced. Integers for ordering? We have\nlists for that.\n\nHow about this:\n\nparameters:\n  db:\n    type: group\n    parameters:\n      - db_name\n      - db_username\n      - db_password\n  web_node:\n    type: group\n    parameters:\n      - web_node_name\n      - keypair\n  db_name:\n    type: string\n  ...\n\n\nThis way we are just providing the groupings outside of the parameters\nthemselves. Using a list means the order is as it appears here.\n\nAnother option is to allow specifying whole parameters in-line there,\nlike\n\nparameters:\n  db:\n    type: group\n    parameters:\n      - db_name:\n        type: string\n\nBut that opens up a can of worms that we can leave closed for now and\njust do the above.\n\n> These are the use cases that have been clearly defined. The original\n> purpose of the metadata section was to \"future-proof\" (I say future-proof,\n> you say pre-optimize ;) ) rapid iterations to potential client design. The\n> intent of the strategy was so that we did not overburden the Heat Core\n> team with requirements that may fluctuate or change as we attempt to\n> improve the user experience of Heat for the community. In hindsight I can\n> see how that intent was misconstrued and may have come off as\n> condescending and I apologize for that.\n> \n\nWhy would you be worried about overburdening _a team you can and should\njoin_? Heat core isn\'t for special people. It is for involved people.\nYou are going to be involved.. so.. join us.\n\nAlso _all_ of the requirements on Heat fluctuate wildly. That\'s what we\'re\nhere for. That\'s what makes Open Source amazing. You can get your wildly\nfluctuating stuff _in to the product_.  Just participate for real please!\n\n> I think that these proposed use cases will add real value to Heat and\n> would require only changes to the HOT specification. If these are\n> acceptable please let me know and I will drop the existing blueprint and\n> patches in favor of something that implements this design. If there are\n> issues to discuss here please suggest alternative solutions so that we can\n> continue to move forward with these improvements.\n> \n\nI think you\'re right for the one\'s you\'ve been clear about specifying.\nThese do add value. And perhaps the others do too. But what is weird\nfor me is that they\'re just showing up in reviews.. not on the ML first.\n\n> I have no doubt that this is just the beginning of plenty of requirements\n> being driven from an attempt to improve the overall end user experience of\n> Heat and I will continue to vet the use cases and proposed implementations\n> with the community before suggesting a solution. I know that this proposal\n> leaves out a few use cases that have been discussed like template\n> author/version and that is because I believe that some of the arguments\n> made are valid and should be looked into before proposing changes to Heat.\n> Most of those other use cases probably can be served from some other\n> solution like git or the future template catalog.\n\nAs Zane suggested.. just stuffing things in git would go a long way to\nmaking template metadata such as author/version/etc. available, and would\nalso cover efficient distribution, even security (via signed tags). Why\nnot follow the example OpenStack has set with python packaging and pbr,\nwhere things relating to VCS are just pulled from vcs rather than being\nmaintained in the wrong place (in code).\n\nMore and more I think that we need to think of a distribution format,\nand that format may well be based on git trees. If we put it all in the\ntemplate, we will just make inaccurate templates the norm.\n\n\n','<CEBA62BB.70BE%tim.schnell@rackspace.com>',NULL),('<1385533924-sup-6149@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 22:50:21',-28800,'2013-11-27 06:50:21',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Ladislav Smola\'s message of 2013-11-26 06:04:12 -0800:\n> Hello,\n> \n> seems too big to do the inline comments, so just a few notes here:\n> \n> If we truly want to have Templates portable, it would mean to have the \n> \'metadata\' somehow standardised, right?\n\nCan you point to another portable application distribution system where\nmeta-data about the applications has been standardized in the language\nitself? Can you give us data on how successful that is?\n\nI can point to plenty where the meta-data is specified outside the\napplication itself, because it makes sense that these are two different\nconcerns.\n\n> Otherwise if every UI will add their own metadata, then I hardly see the \n> templates as portable. I think first step would be then to delete\n> the metadata and add your own, unless you are fine to have 80% of the \n> template some metadata you don\'t use. That also won\'t\n> help the readability. What will help a readability are the verbose comments.\n>\n\nActually that is just the thing. Keeping them portable means making them\nuseful in different deployments without changing them. Deployments are\nnot all going to want to organize things by the same set of tags.\n\nConsider a private cloud used for deploying IT apps internally. They may\nwant to tag SugarCRM as \'sales\' and OpenERP as \'manufacturing\'. These\nare separate concerns, so they should not be in the same template.\n\nWhat _would_ be useful would be curation of those packaged Heat apps\ninto a generally useful \"default\" repository for Heat deployers to take\nadvantage of. A pypi for Heat, if you will. That would help to\nhomogenize things and prevent wasteful forking of the most generic\ntemplates. But the decisions of those curators should not be set in\nstone for all deployers.\n\n> I am not really sure how long it can take to add new specialized tags, \n> that are used only in Horizon and are well documented. I think showing\n> this, should get the patch merged very quickly. That seems to me like a \n> portable solution.\n> \n> IMO for the template catalogue we would probably need a new service, \n> something like Glance, so that\'s probably a more distant future.\n>\n\nWhy not just use glance? Where is this belief coming from that Glance\nwould be hard to add what is basically a single image type to? I\nunderstand SOA and we need to separate things. But \"registry of blobs\nof data\" has a service.\n\nIf people want to expose a user-uploadable HOT glance but not\na user-uploadable image glance, then have two endpoints, and two\nglances. But don\'t write a whole new piece of software just because\nmodifying an existing one seems hard.\n\n> For the use-cases:\n> -----------------------\n> \n> ad 1)\n> Something more general next to Description may be more useful, like \n> keywords, packages or components.\n> Example:\n> \n> Description...\n> Keywords: wordpress, mysql...\n> \n> Or you could parse it from e.g. packages (though that is not always \n> used, so being able to write it explicitly might be handy)\n>\n\nIf you take out the catalog though, this has no place in the template.\n\n> ad 2)\n> Maybe adding something like \'author\' tag may be a good idea, though you \n> can find all the history in git repo,\n> given you use https://github.com/openstack/heat-templates . If you have \n> different repo, adding something like\n> Origin: https://github.com/openstack/heat-templates maybe?\n> \n\nBoth of those things work great if you make git repo+meta-data file the\npackaging format.\n\nThings like Origin: get out of date really fast in my experience because\nthey are informational and not actually important to the use of the\npackage/code/etc.\n\n> ad 3)\n> So having a fix and documented schema seems to be a good way to be \n> portable, at least to me. I am not\n> against UI only tags inside the template, that are really useful for \n> everybody. We will find out by collectively\n> reviewing that, which usually brings some easier solution.\n> \n\nUI only tags are awesome, and I like them a lot.\n\n> Or you don\'t think, it will get too wild to have some \'metadata\' section \n> completely ignored by Heat? Seems\n> to me like there will be a lot of cases, when people won\'t push their \n> template to upstream, because of the\n> metadata they have added to their templates, that nobody else will ever \n> use. Is somebody else concerned\n> about this?\n\nI actually think such a section will be abused heavily to have different\ntemplates per deployment. Keeping this stuff out of the template means\ndeployers who need to arrange things differently can consume the\ntemplate without modifying it.\n\n\n','<5294AA5C.4080600@redhat.com>',NULL),('<1385549991.9695.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 10:59:51',0,'2013-11-27 10:59:51',NULL,'[openstack-dev] [Oslo] Improving oslo-incubator update.py','On Wed, 2013-11-27 at 11:50 +0100, Flavio Percoco wrote:\n> On 26/11/13 22:54 +0000, Mark McLoughlin wrote:\n> >On Fri, 2013-11-22 at 12:39 -0500, Doug Hellmann wrote:\n> >> On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco <flavio at redhat.com> wrote:\n> >> >    1) Store the commit sha from which the module was copied from.\n> >> >    Every project using oslo, currently keeps the list of modules it\n> >> >    is using in `openstack-modules.conf` in a `module` parameter. We\n> >> >    could store, along with the module name, the sha of the commit it\n> >> >    was last synced from:\n> >> >\n> >> >        module=log,commit\n> >> >\n> >> >        or\n> >> >\n> >> >        module=log\n> >> >        log=commit\n> >> >\n> >>\n> >> The second form will be easier to manage. Humans edit the module field and\n> >> the script will edit the others.\n> >\n> >How about adding it as a comment at the end of the python files\n> >themselves and leaving openstack-common.conf for human editing?\n> \n> I think having the commit sha will give us a starting point from which\n> we could start updating that module from. \n\nSure, my only point was about where the commit sha comes from - i.e.\nwhether it\'s from a comment at the end of the python module itself or in\nopenstack-common.conf\n\n> It will mostly help with\n> getting a diff for that module and the short commit messages where it\n> was modified.\n> \n> Here\'s a pseudo-buggy-algorithm for the update process:\n> \n>     (1) Get current sha for $module\n>     (2) Get list of new commits for $module\n>     (3) for each commit of $module:\n>         (3.1) for each modified_module in $commit\n>             (3.1.1) Update those modules up to $commit (1)(modified_module)\n>         (3.2) Copy the new file\n>         (3.3) Update openstack-common with the latest sha\n> \n> This trusts the granularity and isolation of the patches proposed in\n> oslo-incubator. However, in cases like \'remove vim mode lines\' it\'ll\n> fail assuming that updating every module is necessary - which is true\n> from a git stand point.\n\nThis is another variant of the kind of inter-module dependency smarts\nthat update.py already has ... I\'d be inclined to just omit those smarts\nand just require the caller to explicitly list the modules they want to\ninclude.\n\nMaybe update.py could include some reporting to help with that choice\nlike \"module foo depends on modules bar and blaa, maybe you want to\ninclude them too\" and \"commit XXX modified module foo, but also module\nbar and blaa, maybe you want to include them too\".\n\nMark.\n\n\n\n','<20131127105057.GD21199@redhat.com>',NULL),('<1385566572.9695.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 15:36:12',0,'2013-11-27 15:36:12',NULL,'[openstack-dev] [oslo] rpc concurrency control rfc','Hi,\n\nOn Wed, 2013-11-27 at 14:45 +0000, Edward Hope-Morley wrote:\n> Moving this to the ml as requested, would appreciate\n> comments/thoughts/feedback.\n\nThanks, I too would appreciate input from others.\n\n> So, I recently proposed a small patch to the oslo rpc code (initially in\n> oslo-incubator then moved to oslo.messaging) which extends the existing\n> support for limiting the rpc thread pool so that concurrent requests can\n> be limited based on type/method. The blueprint and patch are here:\n> \n> https://blueprints.launchpad.net/oslo.messaging/+spec/rpc-concurrency-control\n> \n> The basic idea is that if you have server with limited resources you may\n> want restrict operations that would impact those resources e.g. live\n> migrations on a specific hypervisor or volume formatting on particular\n> volume node. This patch allows you, admittedly in a very crude way, to\n> apply a fixed limit to a set of rpc methods. I would like to know\n> whether or not people think this is sort of thing would be useful or\n> whether it alludes to a more fundamental issue that should be dealt with\n> in a different manner.\n\nJust to be clear for everyone what we\'re talking about. Your patch means\nthat if an operator sees that requests to the \'foo\' and \'bar\' RPC\nmethods for a given service are overwhelming the capacity of the\nmachine, you can throttle them by adding e.g.\n\n  concurrency_control_enabled = true\n  concurrency_control_actions = foo,bar\n  concurrency_control_limit = 2\n\nto the service\'s configuration file.\n\nIf you accept the premise of what\'s required here, I think you really\nwant to have e.g. a json policy file which can control the concurrency\nlimit on each method individually:\n\n{\n    \"compute\": {\n        \"baseapi\": {\n            \"ping\": 10\n        },\n        \"\": {\n            \"foo\": 1,\n            \"bar\": 2\n        }\n    }\n}\n\nbut that starts feeling pretty ridiculous.\n\nMy concern is that we\'re avoiding addressing a more fundamental issue\nhere. From IRC:\n\n <markmc> \"avoid specific concurrent operations from consuming too many\n          system resources and starving other less resource intensive\n          actions\"\n <markmc> I\'d like us to think about whether we can come up with a\n          solution that fixes the problem for people, without them\n          having to mess with this type of configuration\n <markmc> but yeah ... if we can\'t figure out a way of doing that, there\n          is an argument for giving operators and interim workaround\n <markmc> I wouldn\'t be in favour of an interim fix without first\n          exploring the options for a more fundamental fix\n <markmc> this isn\'t easily removable later, because once people start\n          to rely on it we would need to put it through a deprecation\n          period to remove it\n <markmc> also, an interim solution like this takes away the pressure on\n          us to find a more fundamental solution ... and we may wind up\n          never doing that\n\n\nSo, I guess my first question is ... what specific RPC methods have you\nseen issues with and feel you need to throttle?\n\nThanks,\nMark.\n\n\n\n','<52960582.9040208@canoncial.com>',NULL),('<1385572334-sup-8256@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 09:12:52',-28800,'2013-11-27 17:12:52',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Zane Bitter\'s message of 2013-11-27 08:09:33 -0800:\n> In the longer term, there seems to be a lot of demand for some sort of \n> template catalog service, like Glance for templates. (I disagree with \n> Clint that it should actually _be_ Glance the project as we know it, for \n> the reasons Steve B mentioned earlier, but the concept is right.) And \n> this brings us back to a very similar situation to the operator-provided \n> template catalog (indeed, that use case would likely be subsumed by this \n> one).\n> \n\nCould you provide a stronger link to Steve B\'s comments, I think I\nmissed them. Thanks!\n\n\n','<5296193D.6070606@redhat.com>',NULL),('<1385574319.4512.8.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 09:45:19',-28800,'2013-11-27 17:45:19',NULL,'[openstack-dev] [nova] Maintaining backwards compatibility for\n RPC calls','On Wed, 2013-11-27 at 12:38 +0000, Day, Phil wrote:\n> Doesn?t this mean that you can?t deploy Icehouse (3.0) code into a\n> Havana system but leave the RPC version pinned at Havana until all of\n> the code has been updated ?  \n\nI think it\'s because this change is for computer manager, not for\nconductor or other service.\n\nThanks\n--jyh\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F14FB8@G6W2490.americas.hpqcorp.net>',NULL),('<1385574701.4512.11.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 09:51:41',-28800,'2013-11-27 17:51:41',NULL,'[openstack-dev] [Nova] Is there a way for the VM to identify\n that it is getting booted in OpenStack','On Wed, 2013-11-27 at 01:48 +0000, Vijay Venkatachalam wrote:\n> Hi,\n> \n>                 Is there a way for the VM to identify that it is\n> getting booted in OpenStack?\n> \n>                 As said in the below mail, once the VM knows it is\n> booting in OpenStack it will alter the boot sequence.\n> \n>  \n> \n>                 AWS provides signatures in the BIOS strings. \n> \n>  \n> \n> PS:\n> \n> Changed the title to be more friendly.\n> \n>  \n> \n> Thanks,\n> \n> Vijay V.\n> \n>  \n> \n>  \n> \n> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com] \n> Sent: Tuesday, November 26, 2013 8:58 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in\n> Hyper-V & ESX similar to KVM instantiated VMs?\n> \n> \n>  \n> \n> It is basically used to tailor the boot sequence if the VM gets booted\n> in OpenStack. For ex. it could do the following\n> \n>  \n> \n> 1.      Get IP through DHCP if booted in OpenStack\n> \n> 2.      Read config drive or contact metadata service and init the\n> system if booted in OpenStack\n> \n>  \n> \n> Thanks,\n> \n> Vijay V.\n> \n>  \n> \n> From: Bob Ball [mailto:bob.ball at citrix.com] \n> Sent: Tuesday, November 26, 2013 7:25 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Nova] Are BIOS strings configured in\n> Hyper-V & ESX similar to KVM instantiated VMs?\n> \n> \n>  \n> \n> It?s not certain that this will be implemented for the XenAPI driver.\n> \n>  \n> \n> Our view is that the BIOS strings shouldn?t be relied upon ? the\n> hypervisor can clearly set them to anything so it?s not really a\n> reliable way to configure the application.  Also note that in some\n> scenarios, such as PV guests in Xen clouds, you will not have any BIOS\n> to query.  Finally we?re not clear on the use case here - What?s the\n> use case for needing to know whether you VM is running under OpenStack\n> or not?\n> \n>  \n> \n> Bob\n> \n>  \n> \n> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com] \n> Sent: 26 November 2013 01:44\n> To: OpenStack Development Mailing List\n> (openstack-dev at lists.openstack.org)\n> Subject: [openstack-dev] [Nova] Are BIOS strings configured in Hyper-V\n> & ESX similar to KVM instantiated VMs?\n> \n> \n>  \n> \n> Hi,\n> \n>  \n> \n> In a KVM instantiated VM the following signature is present in the\n> BIOS of the VM\n> \n> The ?Manufacturer ? field in ?System Information? group is set to\n> ?OpenStack Foundation?\n> \n>  \n> \n> This helps the VM to identify that it is getting used in an OpenStack\n> environment.\n> \n>  \n> \n> As far as I know XenServer is planning to set the BIOS Strings in\n> IceHouse release.\n> \n>  \n> \n> Is this functionality available in other Hypervisors, especially\n> Hyper-V & ESX?\n> \n>  \n> \n> Thanks,\n> \n> Vijay V.\n> \n\nWhen you talking about \" used to tailor the boot sequence\", which\ncomponents will do that? Kernel or init script? If it\'s init script,\ncan\'t this be achieved through instance metadata? \n\nThanks\n--jyh\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<26B082831A2B1A4783604AB89B9B2C080DE48903@SINPEX01CL03.citrite.net>',NULL),('<1385578516.11536.3.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 10:55:16',-28800,'2013-11-27 18:55:16',NULL,'[openstack-dev] [Nova] Is there a way for the VM to identify\n that it is getting booted in OpenStack','On Wed, 2013-11-27 at 11:41 -0600, Chris Friesen wrote:\n> On 11/26/2013 07:48 PM, Vijay Venkatachalam wrote:\n> > Hi,\n> >\n> >                  Is there a way for the VM to identify that it is\n> > getting booted in OpenStack?\n> >\n> >                  As said in the below mail, once the VM knows it is\n> > booting in OpenStack it will alter the boot sequence.\n> \n> What does \"getting booted in OpenStack\" mean?  OpenStack supports \n> multiple hypervisors, so you could have something coming up via \n> kvm/vmware/Xen/baremetal/etc. but they\'re all \"getting booted in OpenStack\".\n> \n> Chris\n\nUsually guest can distinguish the hyper-visor underneath through cpuid,\nwhich has some leaf preserved for hyper-visor usage. I think Vijay is\ntalking about distinguish the cloud environment like openstack or AWS,\nbut I\'m not sure if that should go through the instance metadata.\n\n--jyh\n\n\n\n\n','<52962EB0.10106@windriver.com>',NULL),('<1385584358.30155.23.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-27 15:32:38',-18000,'2013-11-27 20:32:38',NULL,'[Openstack-docs] On auth_* configuration options','https://bugs.launchpad.net/openstack-manuals/+bug/1250583\n\nBug 1250583 asks why the Neutron api-paste.ini file doesn\'t include\nauth_port and auth_protocol. I looked through the entire install guide\nto see where we include which auth_* options. There\'s a pretty wide\nvariety. I\'ve attached a poor man\'s spreadsheet text file with the\nbreakdown.\n\nI didn\'t record where we set auth_strategy. I believe this doesn\'t have\nto be set for ini files, since paste.filter_factory specifies that, but\nperhaps it does for conf files. I also didn\'t record the variations on\nthe neutron_admin_auth_* options.\n\nDo we need to set auth_protocol? Does it not default to http? Do we need\nto set both auth_controller/auth_port/auth_protocol and auth_uri? Isn\'t\nauth_uri just a combination of the others? Should auth_uri always have\nan API version appended?\n\nI\'m confused. Steer me in the right direction please.\n\n--\nShaun\n\n\n-------------- next part --------------\n                                                     host        port   protocol  uri\nceilometer-install.xml   ceilometer.conf             controller  35357  http      -\ncinder-controller        cinder/api-paste.ini        controller  35357  http      -\ncinder-node              cinder/api-paste.ini        controller  35357  http      -\nglance-install           glance-api.conf             controller  35357  http      -\nglance-install           glance-registry.conf        controller  35357  http      -\nglance-install           glance-api-paste.ini        controller  -      -         -\nglance-install           glance-registry-paste.ini   controller  -      -         -\nheat-install             heat.conf                   controller  35357  http      http://controller:5000/v2.0\nheat-install             heat.conf[ec2_authtoken]    -           -      -         http://controller:5000/v2.0\nneutron-install(network) neutron.conf                controller  35357  http      -\nneutron-install(network) neutron/api-paste.ini       controller  -      -         http://controller:5000\nneutron-install(network) neutron/metadata_agent.ini  -           -      -         http://controller:5000/v2.0\nneutron-install(compute) neutron.conf                -           -      -         http://controller:35357/v2.0\nneutron-install(compute) neutron/api-paste.ini       controller  -      -         -\nneutron-install(control) neutron.conf                controller  -      -         http://controller:35357/v2.0\nneutron-provider-router- neutron/l3_agent.ini        -           -      -         http://controller:35357/v2.0\nneutron-provider-router- neutron/api-paste.ini       controller  -      -         -\nnova-compute             nova.conf                   controller  -      -         -\nnova-compute             nova.conf(ubuntu)           controller  35357  http      -\nnova-controller          nova.conf                   controller  35357  http      -\nnova-controller          nova/api-paste.ini          controller  5000   http      http://controller:5000/v2.0\n\n',NULL,NULL),('<1385585698.9695.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 20:54:58',0,'2013-11-27 20:54:58',NULL,'[openstack-dev] [TripleO] Summit session wrapup','Hi Jarda,\n\nOn Wed, 2013-11-27 at 14:39 +0100, Jaromir Coufal wrote:\n\n> I think here is the main point where I disagree and which leads to \n> different approaches. I don\'t think, that user of TripleO cares *only* \n> about deploying infrastructure without any knowledge where the things \n> go. This is overcloud user\'s approach - \'I want VM and I don\'t care \n> where it runs\'. Those are self-service users / cloud users. I know we \n> are OpenStack on OpenStack, but we shouldn\'t go that far that we expect \n> same behavior from undercloud users.\n\nNice, I think you\'re getting really close to identifying the conflicting\nassumptions/viewpoints here.\n\nWhat OpenStack - and cloud, in general - does is provide a nice\nself-service abstraction between the owners of the underlying resources\nand the end-user.\n\nWe take away an awful lot of placement control away from the\nself-service in order to allow the operator to provide a usable,\nlarge-scale, multi-tenant service.\n\nThe difference with TripleO is that we assume the undercloud operator\nand the undercloud user are one and the same. At least, that\'s what I\nassume we\'re designing for. I don\'t think we\'re designing for a\nsituation where there is an undercloud operator serving the needs of\nmultiple overcloud operators and it\'s important for the undercloud\noperator to have ultimate control over placement.\n\nThat\'s hardly the end of the story here, but it is one useful\ndistinction that could justify why this case might be different from the\nusual application-deployment-on-IaaS case.\n\n> I can tell you various examples of \n> why the operator will care about where the image goes and what runs on \n> specific node.\n> \n> /One quick example:/\n> I have three racks of homogenous hardware and I want to design it the \n> way so that I have one control node in each, 3 storage nodes and the \n> rest compute. With that smart deployment, I\'ll never know what my rack \n> contains in the end. But if I have control over stuff, I can say that \n> this node is controller, those three are storage and those are compute - \n> I am happy from the very beginning.\n\nIt is valid to ask why this knowledge is important to the user in this\ncase and why it makes them happy. Challenging such assumptions can lead\nto design breakthroughs, I\'m sure you agree.\n\ne.g. before AWS came along, you could imagine someone trying to shoot\ndown the entire premise of IaaS with similar arguments.\n\nOr the whole \"they\'d have asked for a faster horse\" thing.\n\n> Our targeted audience are sysadmins, operators. They hate \'magics\'. They \n> want to have control over things which they are doing. If we put in \n> front of them workflow, where they click one button and they get cloud \n> installed, they will get horrified.\n>\n> That\'s why I am very sure and convinced that we need to have ability for \n> user to have control over stuff. What node is having what role. We can \n> be smart, suggest and advice. But not hiding this functionality from \n> user. Otherwise, I am afraid that we can fail.\n> \n> Furthermore, if we put lots of restrictions (like homogenous hardware) \n> in front of users from the very beginning, we are discouraging people \n> from using TripleO-UI. We are young project and trying to hit as broad \n> audience as possible. If we do flexible enough approach to get large \n> audience interested, solve their problems, we will get more feedback, we \n> will get early adopters, we will get more contributors, etc.\n> \n> First, let\'s help cloud operator, who is having some nodes and wants to \n> deploy OpenStack on them. He wants to have control which node is \n> controller, which node is compute or storage. Then we can get smarter \n> and guide.\n\nYes, I buy this. And I think it\'s the point worth dwelling on.\n\nIt would be quite a bit of work to substantiate the point with hard data\n- e.g. doing user testing of mockups with and without placement control\n- so we have to at least try to build some consensus without that.\n\nWe could do some work on a more detailed description of the persona and\ntheir basic goals. This would clear up whether we\'re designing for the\ncase where one persona owns the undercloud and there\'s another overcloud\noperator persona.\n\nWe could also look at other tools targeted to similar use cases and see\nwhat they do.\n\nBut yeah - my instinct is that all of that would show that we\'d be\nfighting an uphill battle to persuade our users that this type of magic\nis what they want.\n\n...\n> === Implementation ===\n> \n> Above mentioned approach shouldn\'t lead to reimplementing scheduler. We \n> can still use nova-scheduler, but we can take advantage of extra params \n> (like unique identifier), so that we specify more concretely what goes \n> where.\n\nIt\'s hard to see how what you describe doesn\'t ultimately mean we\ncompletely by pass the Nova scheduler. Yes, if you request placement on\na specific node, it does still go through the scheduler ... but it\ndoesn\'t do any actual scheduling.\n\nMaybe we should separate the discussion/design around control nodes and\nresource (i.e. compute/storage) nodes. Mostly because there should be a\nlarge ratio of the latter to the former, so you\'d expect it to be less\nlikely for such fine grained control over resource nodes to be useful.\n\ne.g. maybe adding more compute nodes doesn\'t involve the user doing any\nplacement, and we just let the nova scheduler choose from the available\nnodes which are suitable for compute workloads.\n\nMark.\n\n\n\n','<5295F620.6080908@redhat.com>',NULL),('<1385585813-sup-5410@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 12:59:46',-28800,'2013-11-27 20:59:46',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Tim Schnell\'s message of 2013-11-27 09:16:24 -0800:\n> \n> On 11/27/13 10:09 AM, \"Zane Bitter\" <zbitter at redhat.com> wrote:\n> \n> >On 26/11/13 22:24, Tim Schnell wrote:\n> >> I propose adding an additional field to the parameter definition:\n> >>     \n> >>     Parameters:\n> >>         <parameter name>:\n> >>             description: This is the name of a nova key pair that will be used to\n> >> ssh to the compute instance.\n> >>             help: To learn more about nova key pairs click on this <a\n> >> href=\"/some/url/\">help article</a>.\n> >\n> >(Side note: you\'re seriously going to let users stick HTML in the\n> >template and then have the dashboard display it?  Yikes.)\n> \n> FWIW, I said the exact same thing to Keith Bray and his answer was, \"why\n> not?\"\n> \n\nBecause it is a cross site scripting problem. You are now allowing users\nto publish HTML as your site. If you can guarantee that users will only\never be shown their own template help, then it is o-k. But that seems\nlike an unlikely guarantee.\n\nJust use markdown, it has become the standard for these things.\n\n> The UI is already making determinations about what HTML to generate based\n> on the template. For example, the parameter label to display just\n> unslugifies the parameter key. This is a somewhat tangential discussion\n> though, and I do have reservations about it. Maybe Keith can jump in and\n> defend this better.\n> \n\nGenerating HTML is not displaying user input as HTML. There is a rather\nlarge difference.\n\n\n','<CEBB7C9C.724C%tim.schnell@rackspace.com>',NULL),('<1385586044-sup-3584@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 13:04:20',-28800,'2013-11-27 21:04:20',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Fox, Kevin M\'s message of 2013-11-27 08:58:16 -0800:\n> This use case is sort of a providence case. Where did the stack come from so I can find out more about it.\n> \n\nThis exhibits similar problems to our Copyright header problems. Relying\non authors to maintain their authorship information in two places is\ncumbersome and thus the one that is not automated will likely fall out\nof sync fairly quickly.\n\n> You could put a git commit field in the template itself but then it would be hard to keep updated.\n> \n\nOr you could have Heat able to pull from any remote source rather than\njust allowing submission of the template directly. It would just be\nanother column in the stack record. This would allow said support person\nto see where it came from by viewing the stack, which solves the use case.\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C667BED29@EMAIL05.pnl.gov>',NULL),('<1385586294-sup-5866@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-27 13:07:07',-28800,'2013-11-27 21:07:07',NULL,'[openstack-dev] [heat][horizon]Heat UI related requirements &\n	roadmap','Excerpts from Jay Pipes\'s message of 2013-11-27 10:57:56 -0800:\n> On 11/27/2013 01:28 AM, Clint Byrum wrote:\n> >> I propose adding an additional field to the parameter definition:\n> >>\n> >>      Parameters:\n> >>          <parameter name>:\n> >>              description: This is the name of a nova key pair that will be used to\n> >> ssh to the compute instance.\n> >>              help: To learn more about nova key pairs click on this <a\n> >> href=\"/some/url/\">help article</a>.\n> >\n> > +1. A help string per parameter is a fantastic idea. Sounds like a nice\n> > analog to doc-strings.\n> \n> Agreed. The above is a nice, straightforward addition.\n> \n> <snip>\n> \n> > +1 for grouping. Your use case is perfectly specified above. Love it.\n> >\n> > However, your format feels very forced. Integers for ordering? We have\n> > lists for that.\n> >\n> > How about this:\n> >\n> > parameters:\n> >    db:\n> >      type: group\n> >      parameters:\n> >        - db_name\n> >        - db_username\n> >        - db_password\n> >    web_node:\n> >      type: group\n> >      parameters:\n> >        - web_node_name\n> >        - keypair\n> >    db_name:\n> >      type: string\n> >    ...\n> >\n> > This way we are just providing the groupings outside of the parameters\n> > themselves. Using a list means the order is as it appears here.\n> \n> Actually, even simpler than that...\n> \n> parameters:\n>    db:\n>     - db_name:\n>       description: blah\n>       help: blah\n>     - db_username:\n>       description: blah\n>       help: blah\n> \n> After all, can\'t we assume that if the parameter value is a list, then \n> it is a group of parameters?\n\n+1\n\n\n','<529640B4.5070105@gmail.com>',NULL),('<1385712983.17868.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-29 16:16:23',28800,'2013-11-29 08:16:23',NULL,'[Openstack] Working with Vagrant and packstack','Hi all,\n\nI have been trying to set up an openstack environment using vagrant and packstack. I provisioned a Fedora-19 VM ?through vagrant and used a shell script to take care of installation and other things. The first thing that shell script does is \"yum install -y openstack-packstack\" and then \"packstack --allinone\". Now, the issue is that the second command requires me to enter the root\'s password explicitly. I mean it doesn\'t matter if I am running this as root or using sudo, I have to enter the password explicitly everytime. I tried to pass the password to the VM through pipes and other methods, but nothing works.\n\nDid anyone face the same problem? Is there any way around this? Or does it mean that I can\'t use puppet/packstack with vagrant?\n\nThanks,?\n\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131129/55afe1f2/attachment.html>\n\n',NULL,NULL),('<1385712983.17868.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-29 16:16:23',28800,'2013-11-29 08:16:23',NULL,'[openstack-dev] Working with Vagrant and packstack','Hi all,\n\nI have been trying to set up an openstack environment using vagrant and packstack. I provisioned a Fedora-19 VM ?through vagrant and used a shell script to take care of installation and other things. The first thing that shell script does is \"yum install -y openstack-packstack\" and then \"packstack --allinone\". Now, the issue is that the second command requires me to enter the root\'s password explicitly. I mean it doesn\'t matter if I am running this as root or using sudo, I have to enter the password explicitly everytime. I tried to pass the password to the VM through pipes and other methods, but nothing works.\n\nDid anyone face the same problem? Is there any way around this? Or does it mean that I can\'t use puppet/packstack with vagrant?\n\nThanks,?\n\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131129/55afe1f2/attachment.html>\n\n',NULL,NULL),('<1385737612.2475.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-29 15:06:52',0,'2013-11-29 15:06:52',NULL,'[openstack-dev] [Keystone][Oslo] Future of Key Distribution\n Server, Trusted Messaging','Hey\n\nAnyone got an update on this?\n\nThe keystone blueprint for KDS was marked approved on Tuesday:\n\n  https://blueprints.launchpad.net/keystone/+spec/key-distribution-server\n\nand a new keystone review was added on Sunday, but it must be a draft\nsince I can\'t access it:\n\n   https://review.openstack.org/58124\n\nThanks,\nMark.\n\n\n\n','<49F5BF8205841548AB38409969C7AB3F915BF553@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1385876507-sup-1144@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-30 21:49:02',-28800,'2013-12-01 05:49:02',NULL,'[openstack-dev] [Keystone][Oslo] Future of Key Distribution\n	Server, Trusted Messaging','Excerpts from Adam Young\'s message of 2013-11-25 20:25:50 -0800:\n> Back in the Day, Barbican was just one Service of Cloud Keep.  While I \n> would say that KDS belongs in the Cloud Keep, it is not the same as, and \n> should not be deployed with Barbican.  Is it possible to keep them as \n> separate services?  I think that is the right way to go.  Barbican is \n> for the  end users of Cloud, but KDS is not.  Does this make sense?\n> \n\nThey\'re doing the same fundamental thing for two different sets of users\nwith two overlapping use cases. Why would we implement two KDS services\nfor this?\n\nI also don\'t like that the discussions suggested that because it would\nbe hard to get Barbican incubated/integrated it should not be used. That\nis just crazy talk. TripleO merged with Tuskar because Tuskar is part of\ndeployment. \n\nSeems to me that pulling Barbican into the identity _program_, but still\nas its own project/repo/etc. would solve that problem.\n\n\n','<529422CE.4010303@redhat.com>',NULL),('<1385877394-sup-9125@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-30 21:57:34',-28800,'2013-12-01 05:57:34',NULL,'[openstack-dev] [heat][hadoop][template] Does anyone has a\n	hadoop template','Excerpts from Jay Lau\'s message of 2013-11-28 16:48:41 -0800:\n> Hi,\n> \n> I\'m now trying to deploy a hadoop cluster with heat, just wondering if\n> someone who has a heat template which can help me do the work.\n\n\nHi Jay, this is off topic for the openstack-dev mailing list. Please\nre-post your question on the general OpenStack user discussion list:\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<CAFyztAGA2VA_uzFJMuy8x0Dvc2ZMwZvfW7oSUVCc9S2d2opaAw@mail.gmail.com>',NULL),('<138589875.24395011.1407260981144.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 13:49:41',-14400,'2014-08-05 17:49:41',NULL,'[openstack-dev] [nova] libvirtError: XML error: Missing CPU\n model name on 2nd level vm','Hi Kevin,\nRunning devstack in a VM is perfectly doable.  Many developers use\ndevstack inside a VM (I run mine inside a VM launched using libvirt\non KVM).  I can\'t comment on the issue that you\'re encountering,\nbut perhaps something wasn\'t configured correctly when you launched the\nVM?\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Chen CH Ji\" <jichenjc at cn.ibm.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Friday, August 1, 2014 5:04:16 AM\n> Subject: [openstack-dev] [nova] libvirtError: XML error: Missing CPU model name on 2nd level vm\n> \n> \n> \n> Hi\n> I don\'t have a real PC to so created a test env ,so I created a 2nd level env\n> (create a kvm virtual machine on top of a physical host then run devstack o\n> the vm)\n> I am not sure whether it\'s doable because I saw following error when start\n> nova-compute service , is it a bug or I need to update my configuration\n> instead? thanks\n> \n> \n> 2014-08-01 17:04:51.532 DEBUG nova.virt.libvirt.config [-] Generated XML\n> (\'<cpu>\\n <arch>x86_64</arch>\\n <topology sockets=\"1\" cores=\"1\"\n> threads=\"1\"/>\\n</cpu>\\n\',) from (pid=16956) to_xml\n> /opt/stack/nova/nova/virt/libvirt/config.py:79\n> Traceback (most recent call last):\n> File \"/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py\", line 346, in\n> fire_timers\n> timer()\n> File \"/usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py\", line 56, in\n> __call__\n> cb(*args, **kw)\n> File \"/usr/lib/python2.7/dist-packages/eventlet/event.py\", line 163, in\n> _do_send\n> waiter.switch(result)\n> File \"/usr/lib/python2.7/dist-packages/eventlet/greenthread.py\", line 194, in\n> main\n> result = function(*args, **kwargs)\n> File \"/opt/stack/nova/nova/openstack/common/service.py\", line 490, in\n> run_service\n> service.start()\n> File \"/opt/stack/nova/nova/service.py\", line 164, in start\n> self.manager.init_host()\n> File \"/opt/stack/nova/nova/compute/manager.py\", line 1055, in init_host\n> self.driver.init_host(host=self.host)\n> File \"/opt/stack/nova/nova/virt/libvirt/driver.py\", line 633, in init_host\n> self._do_quality_warnings()\n> File \"/opt/stack/nova/nova/virt/libvirt/driver.py\", line 616, in\n> _do_quality_warnings\n> caps = self._get_host_capabilities()\n> File \"/opt/stack/nova/nova/virt/libvirt/driver.py\", line 2942, in\n> _get_host_capabilities\n> libvirt.VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES)\n> File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 179, in doit\n> result = proxy_call(self._autowrap, f, *args, **kwargs)\n> File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 139, in\n> proxy_call\n> rv = execute(f,*args,**kwargs)\n> File \"/usr/lib/python2.7/dist-packages/eventlet/tpool.py\", line 77, in\n> tworker\n> rv = meth(*args,**kwargs)\n> File \"/usr/lib/python2.7/dist-packages/libvirt.py\", line 3127, in baselineCPU\n> if ret is None: raise libvirtError (\'virConnectBaselineCPU() failed\',\n> conn=self)\n> libvirtError: XML error: Missing CPU model name\n> \n> Best Regards!\n> \n> Kevin (Chen) Ji ? ?\n> \n> Engineer, zVM Development, CSTL\n> Notes: Chen CH Ji/China/IBM at IBMCN Internet: jichenjc at cn.ibm.com\n> Phone: +86-10-82454158\n> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,\n> Beijing 100193, PRC\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OF37F84AC6.A68476CE-ON48257D27.00319801-48257D27.00322DEC@cn.ibm.com>',NULL),('<1385899550.8.1352419773466.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:09:33',0,'2012-11-09 00:09:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-diablo #87','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/87/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric4 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/>\nCheckout:periodic-swift-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/> - hudson.remoting.Channel at 781128cc:oneiric4\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson7826829540875206213.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-diablo/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1386058204.12996.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 16:10:04',28800,'2013-12-03 08:10:04',NULL,'[Openstack] problem in installing swift dependencies','hello all,\n\nI am trying to install and configure swift from a long period, but I am not successful in it till now\nlast time I had installed it using the instructions given at\nhttp://docs.openstack.org/developer/swift/development_saio.html\n\nwhen Setting up scripts for running Swift\nat the command\nroot at arun-Aspire-5742:~# startmain\n\nI got the following error:\nhttp://paste.openstack.org/show/53458/\nI uninstall ubuntu 12.04 desktop from my system, freshly reinstall it and again try to install and configure swift using same link http://docs.openstack.org/developer/swift/development_saio.html\n\nbut now I get the following error in the starting itself\nhttp://paste.openstack.org/show/54333/\n\nplease help me in this regard.\n-----------\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/d7ec4322/attachment.html>\n\n',NULL,NULL),('<1386064395.36836.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 17:53:15',28800,'2013-12-03 09:53:15',NULL,'[Openstack] problem in installing swift dependencies',' \nthanks for the reply jitendra\nI follow the link you mentioned\nbut I got the following error\nMedia change: please insert the disc labeled\n?\'Ubuntu 12.04 LTS _Precise Pangolin_ - Release i386 (20120423)\'\nin the drive \'/cdrom/\' and press enter\n\n\nthe steps I followed are:\n\npragya at pragya-Aspire-5742:~$ sudo\nsu - \n[sudo] password for pragya: \nroot at pragya-Aspire-5742:~# apt-get\ninstall swift openssh-server rsync memcached python-netifaces\npython-xattr python-memcache \nhttp://paste.openstack.org/show/54338/\nroot at pragya-Aspire-5742:~# mkdir\n-p /etc/swift \nroot at pragya-Aspire-5742:~# chown\n-R swift:swift /etc/swift/ \nroot at pragya-Aspire-5742:~# apt-get\ninstall python-software-properties \nhttp://paste.openstack.org/show/54339/\nroot at pragya-Aspire-5742:~# apt-get\nupdate && apt-get dist-upgrade \nhttp://paste.openstack.org/show/54341/\n\n-------------\n\nplease help \n\n\n\n\n\n\nOn Tuesday, 3 December 2013 2:53 PM, Jitendra Kumar Bhaskar <jitendra.b at pramati.com> wrote:\n \nHi Pragya,\n>\n>Try to follow http://docs.openstack.org/havana/install-guide/install/apt/content/general-installation-steps-swift.html to setup swift with at-least two nodes, one for proxy and one for storage node. Its running in our test lab with Havana.\n>\n>\n>\n>Regards\n>Jitendra Bhaskar\n>\n>\n>\n>\n>\n>\n>\n>\n>On Tue, Dec 3, 2013 at 1:40 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello all,\n>>\n>>\n>>I am trying to install and configure swift from a long period, but I am not successful in it till now\n>>last time I had installed it using the instructions given at\n>>http://docs.openstack.org/developer/swift/development_saio.html\n>>\n>>\n>>when Setting up scripts for running Swift\n>>at the command\n>>root at arun-Aspire-5742:~# startmain\n>>\n>>I got the following error:\n>>http://paste.openstack.org/show/53458/\n>>I uninstall ubuntu 12.04 desktop from my system, freshly reinstall it and again try to install and configure swift using same link http://docs.openstack.org/developer/swift/development_saio.html\n>>\n>>\n>>but now I get the following error in the starting itself\n>>http://paste.openstack.org/show/54333/\n>>\n>>\n>>please help me in this regard.\n>>-----------\n>>\n>>\n>>Pragya jain\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/ea36c9bb/attachment.html>\n\n','<CAFYoAqL7HNokNVhMvoLGoci9pztOJEX=FOs+wYwEBA24mGYJ=Q@mail.gmail.com>',NULL),('<1386067794.14959.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 18:49:54',28800,'2013-12-03 10:49:54',NULL,'[Openstack] problem in installing swift dependencies','please reply sir\n\n----------\n\npragya jain\n\n\n\nOn Tuesday, 3 December 2013 3:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \n \n>thanks for the reply jitendra\n>I follow the link you mentioned\n>but I got the following error\n>Media change: please insert the disc labeled\n>?\'Ubuntu 12.04 LTS _Precise Pangolin_ - Release i386 (20120423)\'\n>in the drive \'/cdrom/\' and press enter\n>\n>\n>\n>the steps I followed are:\n>\n>pragya at pragya-Aspire-5742:~$ sudo\nsu - \n>[sudo] password for pragya: \n>root at pragya-Aspire-5742:~# apt-get\ninstall swift openssh-server rsync memcached python-netifaces\npython-xattr python-memcache \n>http://paste.openstack.org/show/54338/\n>root at pragya-Aspire-5742:~# mkdir\n-p /etc/swift \n>root at pragya-Aspire-5742:~# chown\n-R swift:swift /etc/swift/ \n>root at pragya-Aspire-5742:~# apt-get\ninstall python-software-properties \n>http://paste.openstack.org/show/54339/\n>root at pragya-Aspire-5742:~# apt-get\nupdate && apt-get dist-upgrade \n>http://paste.openstack.org/show/54341/\n>\n>\n>-------------\n>\n>\n>please help \n>\n>\n>\n>\n>\n>\n>\n>\n>On Tuesday, 3 December 2013 2:53 PM, Jitendra Kumar Bhaskar <jitendra.b at pramati.com> wrote:\n> \n>Hi Pragya,\n>>\n>>Try to follow http://docs.openstack.org/havana/install-guide/install/apt/content/general-installation-steps-swift.html to setup swift with at-least two nodes, one for proxy and one for storage node. Its running in our test lab with Havana.\n>>\n>>\n>>\n>>Regards\n>>Jitendra Bhaskar\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>On Tue, Dec 3, 2013 at 1:40 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hello all,\n>>>\n>>>\n>>>I am trying to install and configure swift from a long period, but I am not successful in it till now\n>>>last time I had installed it using the instructions given at\n>>>http://docs.openstack.org/developer/swift/development_saio.html\n>>>\n>>>\n>>>when Setting up scripts for running Swift\n>>>at the command\n>>>root at arun-Aspire-5742:~# startmain\n>>>\n>>>I got the following error:\n>>>http://paste.openstack.org/show/53458/\n>>>I uninstall ubuntu 12.04 desktop from my system, freshly reinstall it and again try to install and configure swift using same link http://docs.openstack.org/developer/swift/development_saio.html\n>>>\n>>>\n>>>but now I get the following error in the starting itself\n>>>http://paste.openstack.org/show/54333/\n>>>\n>>>\n>>>please help me in this regard.\n>>>-----------\n>>>\n>>>\n>>>Pragya jain\n>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/2493f2fb/attachment.html>\n\n','<1386064395.36836.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1386089794.2860.15.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 10:56:34',-21600,'2013-12-03 16:56:34',NULL,'[Openstack] nova quota-class-show','On Wed, 2013-12-04 at 00:12 +0800, Peter Cheung wrote:\n> Dear All\n>    1) what is the parameter for \"nova quota-class-show\" ?\n\nThe name of a quota class.\n\n>    2) what is the different between \"nova quota-class-show\" and \"nova\n> quota-defaults\"?\n\nThe \"quota-class-show\" command shows you the quotas associated with the\ngiven quota class.  The \"quota-defaults\" shows you the default quotas\nthat are applied in the absence of quota class or tenant quotas.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<BAY177-W272CF71A9C69B745A061B1B5D50@phx.gbl>',NULL),('<1386109515.25853.151.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 22:25:15',0,'2013-12-03 22:25:15',NULL,'[openstack-dev] When should things get added to Oslo.Incubator','On Tue, 2013-12-03 at 22:07 +0000, Joshua Harlow wrote:\n\n> Process for process sake imho has been a problem for oslo.\n\nIt\'s been reiterated many times, but again - the only purpose of\noslo-incubator is as a place to evolve an API until we\'re ready to make\na commitment to API stability.\n\nIt\'s often easier to start a new API completely standalone, push it to\nPyPI and plan for API backwards compatibility from the start. No-one has\never said that such APIs need to go through oslo-incubator \"for process\nsake\".\n\nMark.\n\n\n\n','<CEC39492.4EB11%harlowja@yahoo-inc.com>',NULL),('<1386109833.25853.156.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 22:30:33',0,'2013-12-03 22:30:33',NULL,'[openstack-dev] When should things get added to Oslo.Incubator','On Wed, 2013-12-04 at 10:42 +1300, Robert Collins wrote:\n> Hey - https://review.openstack.org/#/c/57022/7//COMMIT_MSG - I\n> strongly suggested here that reusing the Nova object code is the first\n> step towards an objects library, and that we should be putting it in\n> olso; there are some reasonable concerns about this being experimental\n> but...\n> \n> The Oslo wiki page says:\n> The process of developing a new Oslo API usually begins by taking code\n> which is common to some OpenStack projects and moving it into the\n> oslo-incubator repository. New APIs live in the incubator until they\n> have matured to meet the criteria described above.\n> \n> So if this code lands in solum as-is, its now common - to me that\n> means we should be going straight to oslo.incubator and working on\n> shared code.\n> \n> However there\'s clearly an expectation mismatch - so - any thoughts?\n\nSpeaking to Devananda about the copy of the code in Ironic, he made the\ncase that Ironic was just going to sync the code from Nova without\nmaking modifications to it until the code was ready to graduate as a\nstandalone library or move to oslo-incubator.\n\nThat actually does make some sense - I\'ve often described oslo-incubator\nas \"managed copy and paste\". It still sucks, but not as much as the copy\nand paste we\'ve done previously where the multiple copies of the same\ncode evolved independently.\n\nNow, in the case of this Solum import, it does look like this is a fork\nof the Nova code. Unless there\'s some realistic plan to reconcile these\nforks, then I think it is a problem and quite short-sighted.\n\nMark.\n\n\n\n','<CAJ3HoZ1q0ky0R+KscGAg2epH1kR654=oM18V7oPen_T48mZryg@mail.gmail.com>',NULL),('<1386110395.25853.158.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 22:39:55',0,'2013-12-03 22:39:55',NULL,'[openstack-dev] When should things get added to Oslo.Incubator','On Tue, 2013-12-03 at 22:31 +0000, Joshua Harlow wrote:\n> Sure, no one has said it. But it seems to be implied, otherwise these\n> types of discussions wouldn\'t occur. Right?\n\nYou\'re assuming the Nova objects API is at a point where the maintainers\nof it feel ready to commit to API stability.\n\nMark.\n\n> On 12/3/13 2:25 PM, \"Mark McLoughlin\" <markmc at redhat.com> wrote:\n> \n> >On Tue, 2013-12-03 at 22:07 +0000, Joshua Harlow wrote:\n> >\n> >> Process for process sake imho has been a problem for oslo.\n> >\n> >It\'s been reiterated many times, but again - the only purpose of\n> >oslo-incubator is as a place to evolve an API until we\'re ready to make\n> >a commitment to API stability.\n> >\n> >It\'s often easier to start a new API completely standalone, push it to\n> >PyPI and plan for API backwards compatibility from the start. No-one has\n> >ever said that such APIs need to go through oslo-incubator \"for process\n> >sake\".\n> >\n> >Mark.\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<CEC39B67.4EB47%harlowja@yahoo-inc.com>',NULL),('<1386111048.25853.164.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 22:50:48',0,'2013-12-03 22:50:48',NULL,'[openstack-dev] creating a default for oslo config variables\n within a project?','On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:\n> On 2013-12-03 15:56, Sean Dague wrote:\n> > This cinder patch - https://review.openstack.org/#/c/48935/\n> > \n> > Is blocked on failing upgrade because the updated oslo lockutils won\'t\n> > function until there is a specific configuration variable added to the\n> > cinder.conf.\n> > \n> > That work around is proposed here -\n> > https://review.openstack.org/#/c/52070/3\n> > \n> > However I think this is exactly the kind of forward breaks that we want\n> > to prevent with grenade, as cinder failing to function after a rolling\n> > upgrade because a config item wasn\'t added is exactly the kind of pain\n> > we are trying to prevent happening to ops.\n> > \n> > So the question is, how is this done correctly so that a default can be\n> > set in the cinder code for this value, and it not require a config\n> > change to work?\n\nYou\'re absolutely correct, in principle - if the default value for\nlock_path worked for users before, we should absolutely continue to\nsupport it.\n\n> I don\'t know that I have a good answer on how to handle this, but for \n> context this change is the result of a nasty bug in lockutils that meant \n> external locks were doing nothing if lock_path wasn\'t set.  Basically \n> it\'s something we should never have allowed in the first place.\n> \n> As far as setting this in code, it\'s important that all of the processes \n> for a service are using the same value to avoid the same bad situation \n> we were in before.  For tests, we have a lockutils wrapper \n> (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282) that sets an environment variable to address this, but that only works if all of the processes are going to be spawned from within the same wrapper, and I\'m not sure how secure that is for production deployments since it puts all of the lock files in a temporary directory.\n\nRight, I don\'t think the previous default really \"worked\" - if you used\nthe default, then external locking was broken.\n\nI suspect most distros do set a default - I see RDO has this in its\ndefault nova.conf:\n\n  lock_path = /var/lib/nova/tmp\n\nSo, yes - this is all terrible.\n\nIMHO, rather than raise an exception we should log a big fat warning\nabout relying on the default and perhaps just treat the lock as an\nin-process lock in that case ... since that\'s essentially what it was\nbefore, right?\n\nMark.\n\n\n\n\n\n','<81d27b8263de0a93ab48a48c15ee7ba3@localhost>',NULL),('<1386111504.25853.168.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 22:58:24',0,'2013-12-03 22:58:24',NULL,'[openstack-dev] When should things get added to Oslo.Incubator','On Tue, 2013-12-03 at 22:44 +0000, Joshua Harlow wrote:\n> Sure sure, let me not make that assumption (can\'t speak for them), but\n> even libraries on pypi have to deal with API instability.\n\nYes, they do ... either by my maintaining stability, bumping their major\nversion number to reflect an incompatible change ... or annoying the\nhell out of their users!\n\n> Just more of suggesting, might as well bite the bullet (if objects folks\n> feel ok with this) and just learn to deal with the pypi method for dealing\n> with API instability (versions, deprecation...). Since code copying around\n> is just creating a miniature version of the same \'learning experience\'\n> except u lose the other parts (versioning, deprecation, ...) which comes\n> along with pypi and libraries.\n\nYes, if the maintainers of the API are prepared to deal with the demands\nof API stability, publishing the API as a standalone library would be\nfar more preferable.\n\nFailing that, oslo-incubator offers a halfway house which sucks, but not\nas as much as the alternative - projects copying and pasting each\nother\'s code and evolving their copies independently.\n\nMark.\n\n> Anyways, just a thought.\n> \n> -Josh\n> \n> On 12/3/13 2:39 PM, \"Mark McLoughlin\" <markmc at redhat.com> wrote:\n> \n> >On Tue, 2013-12-03 at 22:31 +0000, Joshua Harlow wrote:\n> >> Sure, no one has said it. But it seems to be implied, otherwise these\n> >> types of discussions wouldn\'t occur. Right?\n> >\n> >You\'re assuming the Nova objects API is at a point where the maintainers\n> >of it feel ready to commit to API stability.\n> >\n> >Mark.\n> >\n> >> On 12/3/13 2:25 PM, \"Mark McLoughlin\" <markmc at redhat.com> wrote:\n> >> \n> >> >On Tue, 2013-12-03 at 22:07 +0000, Joshua Harlow wrote:\n> >> >\n> >> >> Process for process sake imho has been a problem for oslo.\n> >> >\n> >> >It\'s been reiterated many times, but again - the only purpose of\n> >> >oslo-incubator is as a place to evolve an API until we\'re ready to make\n> >> >a commitment to API stability.\n> >> >\n> >> >It\'s often easier to start a new API completely standalone, push it to\n> >> >PyPI and plan for API backwards compatibility from the start. No-one\n> >>has\n> >> >ever said that such APIs need to go through oslo-incubator \"for process\n> >> >sake\".\n> >> >\n> >> >Mark.\n> >> >\n> >> >\n> >> >_______________________________________________\n> >> >OpenStack-dev mailing list\n> >> >OpenStack-dev at lists.openstack.org\n> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> >\n> >\n> \n\n\n\n\n','<CEC39E22.4EB5A%harlowja@yahoo-inc.com>',NULL),('<1386114307.25853.176.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 23:45:07',0,'2013-12-03 23:45:07',NULL,'[openstack-dev] [Olso][DB] Remove eventlet from oslo.db','On Mon, 2013-12-02 at 16:02 +0200, Victor Sergeyev wrote:\n> Hi folks!\n> \n> At the moment I and Roman Podoliaka are working on splitting of\n> openstack.common.db code into a separate library. And it would be nice to\n> drop dependency on eventlet before oslo.db is released.\n> \n> Currently, there is only one place in oslo.db where we use eventlet -\n> wrapping of DB API method calls to be executed by tpool threads. It wraps\n> DB API calls to be executed by tpool threads. This is only needed when\n> eventlet is used together with DB-API driver implemented as a Python C\n> extension (eventlet can\'t monkey patch C code, so we end up with DB API\n> calls blocking all green threads when using Python-MySQLdb). eventlet has a\n> workaround known as \'tpool\' which is basically a pool of real OS threads\n> that can play nicely with eventlet event loop. tpool feature is\n> experimental and known to have stability problems. There is a doubt that\n> anyone is using it in production at all. Nova API (and probably other API\n> services) has an option to prefork the process on start, so that they don\'t\n> need to use tpool when using eventlet together Python-MySQLdb.\n> \n> We\'d really like to drop tpool support from oslo.db, because as a library\n> we should not be bound to any particular concurrency model. If a target\n> project is using eventlet, we believe, it is its problem how to make it\n> play nicely with Python-MySQLdb lib, but not the problem of oslo.db.\n> Though, we could put tpool wrapper into another helper module within\n> oslo-incubator.\n> \n> But we would really-really like not to have any eventlet related code in\n> oslo.db.\n> \n> Are you using CONF.database.use_tpool in production? Does the approach with\n> a separate tpool wrapper class seem reasonable? Or we can just drop tpool\n> support at all, if no one is using it?\n\nAnother approach is to put the tpool wrapper class in a separate module\nwhich would be completely optional for users of the library.\n\nFor example, you could imagine people who don\'t want this doing:\n\n  from oslo import db\n\n  dbapi = db.DBAPI()\n\nbut if you want the tpool thing, you might do:\n\n  from oslo import db\n  from oslo.db import eventlet as db_eventlet\n\n  dbapi = db_eventlet.TpoolWrapper(db.DBAPI())\n\n(I\'m just making stuff up, but you get the idea)\n\nThe key thing is that eventlet isn\'t a hard dependency of the library,\nbut the useful eventlet integration is still available in the library if\nyou want it.\n\nWe did something similar in oslo.messaging, and the issues there were\nprobably more difficult to deal with.\n\nMark.\n\n\n\n','<CAOr8FYy_RR+66_vu3mXRwF+=M96n6T67TaRKn6OB8975qhu5wA@mail.gmail.com>',NULL),('<1386114307.25853.176.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-12-03 23:45:07',0,'2013-12-03 23:45:07',NULL,'[Openstack-operators] [openstack-dev] [Olso][DB] Remove\n	eventlet from oslo.db','On Mon, 2013-12-02 at 16:02 +0200, Victor Sergeyev wrote:\n> Hi folks!\n> \n> At the moment I and Roman Podoliaka are working on splitting of\n> openstack.common.db code into a separate library. And it would be nice to\n> drop dependency on eventlet before oslo.db is released.\n> \n> Currently, there is only one place in oslo.db where we use eventlet -\n> wrapping of DB API method calls to be executed by tpool threads. It wraps\n> DB API calls to be executed by tpool threads. This is only needed when\n> eventlet is used together with DB-API driver implemented as a Python C\n> extension (eventlet can\'t monkey patch C code, so we end up with DB API\n> calls blocking all green threads when using Python-MySQLdb). eventlet has a\n> workaround known as \'tpool\' which is basically a pool of real OS threads\n> that can play nicely with eventlet event loop. tpool feature is\n> experimental and known to have stability problems. There is a doubt that\n> anyone is using it in production at all. Nova API (and probably other API\n> services) has an option to prefork the process on start, so that they don\'t\n> need to use tpool when using eventlet together Python-MySQLdb.\n> \n> We\'d really like to drop tpool support from oslo.db, because as a library\n> we should not be bound to any particular concurrency model. If a target\n> project is using eventlet, we believe, it is its problem how to make it\n> play nicely with Python-MySQLdb lib, but not the problem of oslo.db.\n> Though, we could put tpool wrapper into another helper module within\n> oslo-incubator.\n> \n> But we would really-really like not to have any eventlet related code in\n> oslo.db.\n> \n> Are you using CONF.database.use_tpool in production? Does the approach with\n> a separate tpool wrapper class seem reasonable? Or we can just drop tpool\n> support at all, if no one is using it?\n\nAnother approach is to put the tpool wrapper class in a separate module\nwhich would be completely optional for users of the library.\n\nFor example, you could imagine people who don\'t want this doing:\n\n  from oslo import db\n\n  dbapi = db.DBAPI()\n\nbut if you want the tpool thing, you might do:\n\n  from oslo import db\n  from oslo.db import eventlet as db_eventlet\n\n  dbapi = db_eventlet.TpoolWrapper(db.DBAPI())\n\n(I\'m just making stuff up, but you get the idea)\n\nThe key thing is that eventlet isn\'t a hard dependency of the library,\nbut the useful eventlet integration is still available in the library if\nyou want it.\n\nWe did something similar in oslo.messaging, and the issues there were\nprobably more difficult to deal with.\n\nMark.\n\n\n\n','<CAOr8FYy_RR+66_vu3mXRwF+=M96n6T67TaRKn6OB8975qhu5wA@mail.gmail.com>',NULL),('<1386123927-sup-3010@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 18:57:58',-28800,'2013-12-04 02:57:58',NULL,'[openstack-dev] [Neutron] DHCP Agent Reliability','Excerpts from Maru Newby\'s message of 2013-12-03 08:08:09 -0800:\n> I\'ve been investigating a bug that is preventing VM\'s from receiving IP addresses when a Neutron service is under high load:\n> \n> https://bugs.launchpad.net/neutron/+bug/1192381\n> \n> High load causes the DHCP agent\'s status updates to be delayed, causing the Neutron service to assume that the agent is down.  This results in the Neutron service not sending notifications of port addition to the DHCP agent.  At present, the notifications are simply dropped.  A simple fix is to send notifications regardless of agent status.  Does anybody have any objections to this stop-gap approach?  I\'m not clear on the implications of sending notifications to agents that are down, but I\'m hoping for a simple fix that can be backported to both havana and grizzly (yes, this bug has been with us that long).\n> \n> Fixing this problem for real, though, will likely be more involved.  The proposal to replace the current wsgi framework with Pecan may increase the Neutron service\'s scalability, but should we continue to use a \'fire and forget\' approach to notification?  Being able to track the success or failure of a given action outside of the logs would seem pretty important, and allow for more effective coordination with Nova than is currently possible.\n> \n\nDropping requests without triggering a user-visible error is a pretty\nserious problem. You didn\'t mention if you have filed a bug about that.\nIf not, please do or let us know here so we can investigate and file\na bug.\n\nIt seems to me that they should be put into a queue to be retried.\nSending the notifications blindly is almost as bad as dropping them,\nas you have no idea if the agent is alive or not.\n\n\n','<534E7972-5835-4F31-9873-083BDA76A77A@redhat.com>',NULL),('<1386129337-sup-5185@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 19:59:28',-28800,'2013-12-04 03:59:28',NULL,'[openstack-dev] [Neutron] DHCP Agent Reliability','Excerpts from Maru Newby\'s message of 2013-12-03 19:37:19 -0800:\n> \n> On Dec 4, 2013, at 11:57 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Maru Newby\'s message of 2013-12-03 08:08:09 -0800:\n> >> I\'ve been investigating a bug that is preventing VM\'s from receiving IP addresses when a Neutron service is under high load:\n> >> \n> >> https://bugs.launchpad.net/neutron/+bug/1192381\n> >> \n> >> High load causes the DHCP agent\'s status updates to be delayed, causing the Neutron service to assume that the agent is down.  This results in the Neutron service not sending notifications of port addition to the DHCP agent.  At present, the notifications are simply dropped.  A simple fix is to send notifications regardless of agent status.  Does anybody have any objections to this stop-gap approach?  I\'m not clear on the implications of sending notifications to agents that are down, but I\'m hoping for a simple fix that can be backported to both havana and grizzly (yes, this bug has been with us that long).\n> >> \n> >> Fixing this problem for real, though, will likely be more involved.  The proposal to replace the current wsgi framework with Pecan may increase the Neutron service\'s scalability, but should we continue to use a \'fire and forget\' approach to notification?  Being able to track the success or failure of a given action outside of the logs would seem pretty important, and allow for more effective coordination with Nova than is currently possible.\n> >> \n> > \n> > Dropping requests without triggering a user-visible error is a pretty\n> > serious problem. You didn\'t mention if you have filed a bug about that.\n> > If not, please do or let us know here so we can investigate and file\n> > a bug.\n> \n> There is a bug linked to in the original message that I am already working on.  The fact that that bug title is \'dhcp agent doesn\'t configure ports\' rather than \'dhcp notifications are silently dropped\' is incidental.\n> \n\nGood point, I suppose that one bug is enough.\n\n> > \n> > It seems to me that they should be put into a queue to be retried.\n> > Sending the notifications blindly is almost as bad as dropping them,\n> > as you have no idea if the agent is alive or not.\n> \n> This is more the kind of discussion I was looking for.  \n> \n> In the current architecture, the Neutron service handles RPC and WSGI with a single process and is prone to being overloaded such that agent heartbeats can be delayed beyond the limit for the agent being declared \'down\'.  Even if we increased the agent timeout as Yongsheg suggests, there is no guarantee that we can accurately detect whether an agent is \'live\' with the current architecture.  Given that amqp can ensure eventual delivery - it is a queue - is sending a notification blind such a bad idea?  In the best case the agent isn\'t really down and can process the notification.  In the worst case, the agent really is down but will be brought up eventually by a deployment\'s monitoring solution and process the notification when it returns.  What am I missing? \n>\n\nI have not looked closely into what expectations are built in to the\nnotification system, so I may have been off base. My understanding was\nthey were not necessarily guaranteed to be delivered, but if they are,\nthen this is fine.\n\n> Please consider that while a good solution will track notification delivery and success, we may need 2 solutions:\n> \n> 1. A \'good-enough\', minimally-invasive stop-gap that can be back-ported to grizzly and havana.\n>\n\nI don\'t know why we\'d backport to grizzly. But yes, if we can get a\nnotable jump in reliability with a clear patch, I\'m all for it.\n\n> 2. A \'best-effort\' refactor that maximizes the reliability of the DHCP agent.\n> \n> I\'m hoping that coming up with a solution to #1 will allow us the breathing room to work on #2 in this cycle.\n>\n\nUnderstood, I like the short term plan and think long term having more\nCPU available to process more messages is a good thing, most likely in\nthe form of more worker processes.\n\n\n','<0BCFD776-AA49-4178-8D90-7487723A2E22@redhat.com>',NULL),('<1386130110-sup-8766@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 20:21:58',-28800,'2013-12-04 04:21:58',NULL,'[openstack-dev] creating a default for oslo config variables\n	within a project?','Excerpts from Sean Dague\'s message of 2013-12-03 16:05:47 -0800:\n> On 12/03/2013 06:13 PM, Ben Nemec wrote:\n> > On 2013-12-03 17:09, Sean Dague wrote:\n> >> On 12/03/2013 05:50 PM, Mark McLoughlin wrote:\n> >>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:\n> >>>> On 2013-12-03 15:56, Sean Dague wrote:\n> >>>>> This cinder patch - https://review.openstack.org/#/c/48935/\n> >>>>>\n> >>>>> Is blocked on failing upgrade because the updated oslo lockutils won\'t\n> >>>>> function until there is a specific configuration variable added to the\n> >>>>> cinder.conf.\n> >>>>>\n> >>>>> That work around is proposed here -\n> >>>>> https://review.openstack.org/#/c/52070/3\n> >>>>>\n> >>>>> However I think this is exactly the kind of forward breaks that we\n> >>>>> want\n> >>>>> to prevent with grenade, as cinder failing to function after a rolling\n> >>>>> upgrade because a config item wasn\'t added is exactly the kind of pain\n> >>>>> we are trying to prevent happening to ops.\n> >>>>>\n> >>>>> So the question is, how is this done correctly so that a default\n> >>>>> can be\n> >>>>> set in the cinder code for this value, and it not require a config\n> >>>>> change to work?\n> >>>\n> >>> You\'re absolutely correct, in principle - if the default value for\n> >>> lock_path worked for users before, we should absolutely continue to\n> >>> support it.\n> >>>\n> >>>> I don\'t know that I have a good answer on how to handle this, but for\n> >>>> context this change is the result of a nasty bug in lockutils that\n> >>>> meant\n> >>>> external locks were doing nothing if lock_path wasn\'t set.  Basically\n> >>>> it\'s something we should never have allowed in the first place.\n> >>>>\n> >>>> As far as setting this in code, it\'s important that all of the\n> >>>> processes\n> >>>> for a service are using the same value to avoid the same bad situation\n> >>>> we were in before.  For tests, we have a lockutils wrapper\n> >>>> (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282)\n> >>>> that sets an environment variable to address this, but that only\n> >>>> works if all of the processes are going to be spawned from within\n> >>>> the same wrapper, and I\'m not sure how secure that is for production\n> >>>> deployments since it puts all of the lock files in a temporary\n> >>>> directory.\n> >>>\n> >>> Right, I don\'t think the previous default really \"worked\" - if you used\n> >>> the default, then external locking was broken.\n> >>>\n> >>> I suspect most distros do set a default - I see RDO has this in its\n> >>> default nova.conf:\n> >>>\n> >>>   lock_path = /var/lib/nova/tmp\n> >>>\n> >>> So, yes - this is all terrible.\n> >>>\n> >>> IMHO, rather than raise an exception we should log a big fat warning\n> >>> about relying on the default and perhaps just treat the lock as an\n> >>> in-process lock in that case ... since that\'s essentially what it was\n> >>> before, right?\n> >>\n> >> So a default of lock_path = /tmp will work (FHS says that path has to be\n> >> there), even if not optimal. Could we make it a default value like that\n> >> instead of the current default which is null (and hence the problem).\n> > \n> > IIRC, my initial fix was something similar to that, but it got shot down\n> > because putting the lock files in a known world writeable location was a\n> > security issue.\n> > \n> > Although maybe if we put them in a subdirectory of /tmp and ensured that\n> > the permissions were such that only the user running the service could\n> > use that directory, it might be acceptable?  We could still log a\n> > warning if we wanted.\n> > \n> > This seems like it would have implications for people running services\n> > on Windows too, but we can probably find a way to make that work if we\n> > decide on a solution.\n> \n> How is that a security issue? Are the lock files being written with some\n> sensitive data in them and have g or o permissions on? The sticky bit\n> (+t) on /tmp will prevent other users from deleting the file.\n> \n\nRight, but it won\'t prevent users from creating a symlink with the same\nname.\n\nln -s /var/lib/nova/instances/xxxxx/image.raw /tmp/well.known.location\n\nNow when you do\n\nwith open(\'/tmp/well.known.location\', \'w\') as lockfile:\n  lockfile.write(\'Stuff\')\n\nNova has just truncated the image file and written \'Stuff\' to it.\n\nThe typical solution is to use a lock directory, /var/run/yourprogram,\nthat has restrictive enough permissions setup for your program to have\nexclusive use of it, and is created by root at boot time. That is what\nthe packages do now.\n\nIt would be good if everybody agreed on a default, %(nova_home)/locks\nor something, but root still must set it up with the right permissions\nbefore the program can use it. IMO that is fine, your upgrade should\ninclude a change to your init script/systemd unit/upstart job which\nensures that it exists before starting.\n\nWe could abstract this away with a nova-manage subcommand that is intended\nto be run as root but can inspect the config file. That would allow for\nsimpler documentation and the packagers would probably love you for it.\n:)\n\n\n','<529E71DB.4040907@dague.net>',NULL),('<1386138327.25553.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-04 14:25:27',28800,'2013-12-04 06:25:27',NULL,'[Openstack] problem in installing swift',' \nhello,\n\nI am installing swift using link http://docs.openstack.org/developer/swift/development_saio.html\n\nI am getting following error:\nroot at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \nThe program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \napt-get install xfsprogs \nroot at pragya-Aspire-5742:~# apt-get\ninstall xfsprogs \nReading package lists... Done \nBuilding dependency tree \nReading state information... Done \nxfsprogs is already the newest\nversion. \n0 upgraded, 0 newly installed, 0 to\nremove and 654 not upgraded. \nroot at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \nThe program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \napt-get install xfsprogs \n----------\nPlease help me in this regard\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131204/5c7e7d23/attachment.html>\n\n',NULL,NULL),('<1386145072.90017.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-04 16:17:52',28800,'2013-12-04 08:17:52',NULL,'[Openstack] problem in installing swift','I had installed all dependencies. i am sending my work.\n\n \nroot at pragya-Aspire-5742:~# apt-get\nupdate \nhttp://paste.openstack.org/show/54406/\nroot at pragya-Aspire-5742:~# \napt-get\ninstall curl gcc memcached rsync sqlite3 xfsprogs git-core libffi-dev\npython-setuptools \nhttp://paste.openstack.org/show/54407/\nroot at pragya-Aspire-5742:~#  apt-get\ninstall python-coverage python-dev python-nose python-simplejson\npython-xattr python-eventlet python-greenlet python-pastedeploy\npython-netifaces python-pip python-dnspython python-mock \nhttp://paste.openstack.org/show/54408/\nroot at pragya-Aspire-5742:~# apt-get\ninstall python-coverage python-dev python-nose python-simplejson\npython-xattr python-eventlet python-greenlet python-pastedeploy\npython-netifaces python-pip python-dnspython python-mock \nhttp://paste.openstack.org/show/54409/\nroot at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \nThe program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \napt-get install xfsprogs \nroot at pragya-Aspire-5742:~# apt-get\ninstall xfsprogs \nReading package lists... Done \nBuilding dependency tree \nReading state information... Done \nxfsprogs is already the newest\nversion. \n0 upgraded, 0 newly installed, 0 to\nremove and 654 not upgraded. \nroot at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \nThe program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \napt-get install xfsprogs \nroot at pragya-Aspire-5742:~# sudo\nmkfs.xfs /srv/swift-disk \nsudo: mkfs.xfs: command not found \nroot at pragya-Aspire-5742:~# sudo apt-get\ninstall -y xfsprogs \nReading package lists... Done \nBuilding dependency tree \nReading state information... Done \nxfsprogs is already the newest\nversion. \n0 upgraded, 0 newly installed, 0 to\nremove and 654 not upgraded. \nroot at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \nThe program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \napt-get install xfsprogs \n\n-----------\n\nPlease help\n\n\n\n\n\nOn Wednesday, 4 December 2013 1:21 PM, dheeru <dheerendra.madhusudhana at gmail.com> wrote:\n \nDid you install the dependencies as suggested in the link ? It is better to check\n>\n>\n>-Dheeru\n>@Community Service\n>\n>\n>\n>On Wed, Dec 4, 2013 at 11:55 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello,\n>>\n>>\n>>I am installing swift using link http://docs.openstack.org/developer/swift/development_saio.html\n>>\n>>\n>>I am getting following error:\n>>root at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \n>>The program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \n>>apt-get install xfsprogs \n>>root at pragya-Aspire-5742:~# apt-get\ninstall xfsprogs \n>>Reading package lists... Done \n>>Building dependency tree \n>>Reading state information... Done \n>>xfsprogs is already the newest\nversion. \n>>0 upgraded, 0 newly installed, 0 to\nremove and 654 not upgraded. \n>>root at pragya-Aspire-5742:~# mkfs.xfs\n/srv/swift-disk \n>>The program \'mkfs.xfs\' is currently not\ninstalled.  You can install it by typing: \n>>apt-get install xfsprogs \n>>----------\n>>Please help me in this regard\n>>\n>>\n>>Pragya jain\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n>-- \n>\n>-dheeru\n>@Community Service\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131204/f0f1b52a/attachment.html>\n\n','<CAKV+gufwHOnuSCTkzbhS0NEaTBtL8yd44qQEoXm+1_8njZ7RbQ@mail.gmail.com>',NULL),('<1386148325.25853.179.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 09:12:05',0,'2013-12-04 09:12:05',NULL,'[openstack-dev] [openstack-tc] [barbican] Curious about\n oslo.messaging (from Incubation Request for Barbican)','On Wed, 2013-12-04 at 05:01 +0000, John Wood wrote:\n> Hello folks,\n> \n> I was curious if there is an OpenStack project that would be a good\n> example to follow as we convert Barbican over to oslo messaging. \n> \n> I\'ve been examining existing OpenStack projects such as Ceilometer and\n> Keystone to see how they are utilizing oslo messaging. These projects\n> appear to be utilizing packages such as \'rpc\' and \'notifier\' from the\n> oslo-incubator project. It seems that the oslo.messaging project\'s\n> structure is different than the messaging structure of oslo-incubator\n> (there are newer classes such as Transport now for example). Is there\n> an example OpenStack project utilizing the oslo.messaging structure\n> that might be better for us to follow?\n> \n> The RPC approach of Ceilometer in particular seems well suited to\n> Barbican\'s use case, so seems to be a good option for us to follow,\n> unless there are better options folks can suggest.\n\nThe patch to port Nova might be helpful to you:\n\n  https://review.openstack.org/39929\n\n(Note - the patch is complete and ready to merge, it\'s just temporarily\nblocked on a separate Nova issue being resolved)\n\nMark.\n\n\n\n','<49F5BF8205841548AB38409969C7AB3F915C45AF@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1386152683.4232052.1397480900001.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 09:08:20',-14400,'2014-04-14 13:08:20',NULL,'[openstack-dev] [heat] Custom Resource','Hi Steve,\n\nThanks a lot for your prompt response. I can\'t agree more that the CFN custom resource implementation is complex with it\'s dependency on SNS and SQS. However, it  decouples the implementation of the resource life-cycle from the resource itself. IMO, this has some advantages from the template complexity and flexibility point of view. \n\nOn choices you mentioned:\n\n1. Custom Python Plugins - I do think this is the best approach for my use-cases. However, asking a customer to develop custom plugins and maintaining them can be too much ask(asking their 3rd party tool vendors to do it is even more difficult), than plugging in some of their existing infra script snippets.\n\n2. Provider Resource - Use of environment files for mapping nested template and exchange of parameters/attributes looks sleek. However, I am yet to understand how to wrap code snippets (many of them existing scripts) for the resource life-cycle in the nested template to achieve these use-cases. \n\nWith the CFN Custom resource, addition of some bits of code to the existing scripts to parse the JSON snippets based on the stack life-cycle method is what\'s required. \n\nHowever, my understanding of what\'s possible with the Provider Resource is limited at the moment. I\'ll spend more time and go through it before coming back with an answer to the use-case feasibility and constraints.\n\n\nRegards,\nRabi Mishra\n\n----- Original Message -----\n> Hi Rabi,\n> \n> On Mon, Apr 14, 2014 at 06:44:44AM -0400, Rabi Mishra wrote:\n> > Hi All,\n> > \n> > Recently, I\'ve come across some requirements for external\n> > integrations/resources that can be managed like stack resources\n> > (create,update,delete) from the stack.\n> > \n> > 1. Adding/Removing DNS records for instances created as part of a stack.\n> > 2. Integration with IPAM solutions for allocate/release of IPs (IP\n> > allocation pool for provider network)\n> > 3. Other custom integration for dynamic parameters to stacks.\n> > \n> > IMHO, it would probably make sense to create a custom resource like \'AWS\n> > CFN Custom Resource\'[1] that can be used for these kind of use cases. I\n> > have created a blueprint[2] for this.\n> \n> Heat already has a couple of ways for custom resources to be defined.\n> \n> The one which probably matches your requirements best is the \"provider\n> resource\" interface, which allows template defined resources to be mapped\n> to user-definable resource types, via an environment file:\n> \n> http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html\n> http://docs.openstack.org/developer/heat/template_guide/environment.html\n> \n> Provider resources can be defined by both users, and deployers (who can use\n> templates to e.g wrap an existing resource with something like DNS\n> registration logic, and expose the type transparently to the end-user)\n> \n> For deployer requirements not satisfied by provider resources (for example\n> integration with third-party services), Heat also provides a python plugin\n> API, which enables deployers to create their own resource plugins as\n> needed:\n> \n> http://docs.openstack.org/developer/heat/pluginguide.html\n> \n> Personally, I think these two models provide sufficient flexibility that we\n> should be able to avoid the burden of maintaining a CFN compatible custom\n> resource plugin API.  I\'ve not looked at it in detail, but the CFN model\n> you refer to has always seemed pretty complex to me, and seems like\n> something we don\'t necessarily want to replicate.\n> \n> If there are gaps where things are not yet possible via the provider\n> resource interface, I\'d rather discuss incremental improvements to that\n> instead of wholesale reimplementation of something compatible with AWS.\n> \n> Can you provide any more feedback on your use-cases, and whether the\n> interfaces I linked can be used to satisfy them?\n> \n> Steve\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140414110135.GB7005@t430slt.redhat.com>',NULL),('<1386185844-sup-9785@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 11:44:55',-28800,'2013-12-04 19:44:55',NULL,'[openstack-dev] creating a default for oslo config variables\n	within a project?','Excerpts from Sean Dague\'s message of 2013-12-04 10:51:16 -0800:\n> On 12/04/2013 11:56 AM, Ben Nemec wrote:\n> > On 2013-12-04 06:07, Sean Dague wrote:\n> >> On 12/03/2013 11:21 PM, Clint Byrum wrote:\n> >>> Excerpts from Sean Dague\'s message of 2013-12-03 16:05:47 -0800:\n> >>>> On 12/03/2013 06:13 PM, Ben Nemec wrote:\n> >>>>> On 2013-12-03 17:09, Sean Dague wrote:\n> >>>>>> On 12/03/2013 05:50 PM, Mark McLoughlin wrote:\n> >>>>>>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote:\n> >>>>>>>> On 2013-12-03 15:56, Sean Dague wrote:\n> >>>>>>>>> This cinder patch - https://review.openstack.org/#/c/48935/\n> >>>>>>>>>\n> >>>>>>>>> Is blocked on failing upgrade because the updated oslo\n> >>>>>>>>> lockutils won\'t\n> >>>>>>>>> function until there is a specific configuration variable added\n> >>>>>>>>> to the\n> >>>>>>>>> cinder.conf.\n> >>>>>>>>>\n> >>>>>>>>> That work around is proposed here -\n> >>>>>>>>> https://review.openstack.org/#/c/52070/3\n> >>>>>>>>>\n> >>>>>>>>> However I think this is exactly the kind of forward breaks that we\n> >>>>>>>>> want\n> >>>>>>>>> to prevent with grenade, as cinder failing to function after a\n> >>>>>>>>> rolling\n> >>>>>>>>> upgrade because a config item wasn\'t added is exactly the kind\n> >>>>>>>>> of pain\n> >>>>>>>>> we are trying to prevent happening to ops.\n> >>>>>>>>>\n> >>>>>>>>> So the question is, how is this done correctly so that a default\n> >>>>>>>>> can be\n> >>>>>>>>> set in the cinder code for this value, and it not require a config\n> >>>>>>>>> change to work?\n> >>>>>>>\n> >>>>>>> You\'re absolutely correct, in principle - if the default value for\n> >>>>>>> lock_path worked for users before, we should absolutely continue to\n> >>>>>>> support it.\n> >>>>>>>\n> >>>>>>>> I don\'t know that I have a good answer on how to handle this,\n> >>>>>>>> but for\n> >>>>>>>> context this change is the result of a nasty bug in lockutils that\n> >>>>>>>> meant\n> >>>>>>>> external locks were doing nothing if lock_path wasn\'t set. \n> >>>>>>>> Basically\n> >>>>>>>> it\'s something we should never have allowed in the first place.\n> >>>>>>>>\n> >>>>>>>> As far as setting this in code, it\'s important that all of the\n> >>>>>>>> processes\n> >>>>>>>> for a service are using the same value to avoid the same bad\n> >>>>>>>> situation\n> >>>>>>>> we were in before.  For tests, we have a lockutils wrapper\n> >>>>>>>> (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282)\n> >>>>>>>>\n> >>>>>>>> that sets an environment variable to address this, but that only\n> >>>>>>>> works if all of the processes are going to be spawned from within\n> >>>>>>>> the same wrapper, and I\'m not sure how secure that is for\n> >>>>>>>> production\n> >>>>>>>> deployments since it puts all of the lock files in a temporary\n> >>>>>>>> directory.\n> >>>>>>>\n> >>>>>>> Right, I don\'t think the previous default really \"worked\" - if\n> >>>>>>> you used\n> >>>>>>> the default, then external locking was broken.\n> >>>>>>>\n> >>>>>>> I suspect most distros do set a default - I see RDO has this in its\n> >>>>>>> default nova.conf:\n> >>>>>>>\n> >>>>>>>   lock_path = /var/lib/nova/tmp\n> >>>>>>>\n> >>>>>>> So, yes - this is all terrible.\n> >>>>>>>\n> >>>>>>> IMHO, rather than raise an exception we should log a big fat warning\n> >>>>>>> about relying on the default and perhaps just treat the lock as an\n> >>>>>>> in-process lock in that case ... since that\'s essentially what it\n> >>>>>>> was\n> >>>>>>> before, right?\n> >>>>>>\n> >>>>>> So a default of lock_path = /tmp will work (FHS says that path has\n> >>>>>> to be\n> >>>>>> there), even if not optimal. Could we make it a default value like\n> >>>>>> that\n> >>>>>> instead of the current default which is null (and hence the problem).\n> >>>>>\n> >>>>> IIRC, my initial fix was something similar to that, but it got shot\n> >>>>> down\n> >>>>> because putting the lock files in a known world writeable location\n> >>>>> was a\n> >>>>> security issue.\n> >>>>>\n> >>>>> Although maybe if we put them in a subdirectory of /tmp and ensured\n> >>>>> that\n> >>>>> the permissions were such that only the user running the service could\n> >>>>> use that directory, it might be acceptable?  We could still log a\n> >>>>> warning if we wanted.\n> >>>>>\n> >>>>> This seems like it would have implications for people running services\n> >>>>> on Windows too, but we can probably find a way to make that work if we\n> >>>>> decide on a solution.\n> >>>>\n> >>>> How is that a security issue? Are the lock files being written with\n> >>>> some\n> >>>> sensitive data in them and have g or o permissions on? The sticky bit\n> >>>> (+t) on /tmp will prevent other users from deleting the file.\n> >>>>\n> >>>\n> >>> Right, but it won\'t prevent users from creating a symlink with the same\n> >>> name.\n> >>>\n> >>> ln -s /var/lib/nova/instances/xxxxx/image.raw /tmp/well.known.location\n> >>>\n> >>> Now when you do\n> >>>\n> >>> with open(\'/tmp/well.known.location\', \'w\') as lockfile:\n> >>>   lockfile.write(\'Stuff\')\n> >>>\n> >>> Nova has just truncated the image file and written \'Stuff\' to it.\n> >>\n> >> So that\'s the generic case (and the way people often write this). But\n> >> the oslo lockutils code doesn\'t work that way. While it does open the\n> >> file for write, it does not actually write, it\'s using fcntl to hold\n> >> locks. That\'s taking a data structure on the fd in kernel memory (IIRC),\n> >> so it correctly gives it up if the process crashes.\n> >>\n> >> I\'m not saying there isn\'t some other possible security vulnerability\n> >> here as well, but it\'s not jumping out at me. So I\'d love to understand\n> >> that, because if we can close that exposure we can provide a working\n> >> default, plus a strong recommendation for how to do that *right*. I\'d be\n> >> totally happy with printing WARNING level at startup if lock_path = /tmp\n> >> that this should be adjusted.\n> > \n> > Full disclosure: I don\'t claim to be a security expert, so take my\n> > thoughts on this with a grain of salt.\n> > \n> > tldr: I still don\'t see a way to do this without breaking _something_.\n> > \n> > Unfortunately, while we don\'t actually write to the file, just opening\n> > it for write access truncates it.  So there remains the issue Clint\n> > raised if someone can make that file a link.  I suppose we could check\n> > for the bad things people might do, but I\'m pretty sure that way lies\n> > madness.\n> \n> Fair point, more coffee before I make statements like that I guess :).\n> \n> Follow up question: could we change it to open in \"a\" mode instead.\n> Still requires write access, but won\'t truncate.\n> \n\nThat would still allow them to DOS you by holding the locks\nindefinitely.\n\n> > As a followup to my suggestion to have lockutils create something like\n> > /tmp/oslo-lock-path and make it accessible only to the owner, I think\n> > there\'s still a problem because a malicious user could create that\n> > directory ahead of time and when OpenStack is run for the first time it\n> > would happily use the existing directory and potentially overwrite any\n> > linked files in it.  There might be ways to avoid that, but I suspect\n> > they would be racy (which I believe is why you\'re not supposed to use\n> > tmp paths that are known ahead of time).  Granted, I\'m not sure you\n> > should be installing to a system that already has malicious users on it,\n> > but I suspect security people would be less than thrilled with that answer.\n> > \n> > So the workable options that I see right now are to have it break on\n> > upgrade if lock_path is not set, or continue to break external locking\n> > by having it fall back to process locks when lock_path is not set, as\n> > Mark suggested.  I\'m not wild about either so I\'d love to hear if anyone\n> > has a third option.\n> \n> Honestly, I\'d love us to be clever and figure out a not dangerous way\n> through this, even if unwise (where we can yell at the user in the LOGs\n> loudly, and fail them in J if lock_dir=/tmp) that lets us progress\n> through this while gracefully bringing configs into line.\n>\n\nI\'m not very clever, so I tend to be afraid of clever solutions. :-P\n\n\n','<529F79A4.2070602@dague.net>',NULL),('<1386188434-sup-1007@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 12:25:26',-28800,'2013-12-04 20:25:26',NULL,'[openstack-dev] [Solum] MySQL Storage Engine','Excerpts from Paul Montgomery\'s message of 2013-12-04 12:04:06 -0800:\n> TLDR: Should Solum log a warning if operators do not use the InnoDB\n> storage engine with MySQL in Solum\'s control plane?\n> \n> \n> Details:\n> \n> I was looking at: https://review.openstack.org/#/c/57024/\n> Models.py to be specific.\n> \n> The default storage engine is InnoDB for MySQL which is good.  I took a\n> quick look at the storage engines and only InnoDB seems reasonable for the\n> Solum control plane (it is ACID complaint).  I assume that we\'ll all be\n> coding towards an ACID compliant database for performance (not having to\n> revalidate database writes and consistency and such) and ease of\n> development.\n> \n> If all of that is true, should we log a warning to the operator that they\n> are using an untested and potentially problematic storage engine (which in\n> a worst case scenario can corrupt their data)?  Should we even enable an\n> operator to change the storage engine through configuration?  I think\n> enabling that configuration is fine as long as we make sure that the\n> operator knows that they are on their own with this unsupported\n> configuration but I welcome thoughts from the group on this topic.\n> \n\nJust assume MyISAM _does not exist_. It is 2013 for crying out loud.\n\nIf somebody accidentally uses MyISAM, point at them and laugh, but then\ndo help them pick up the pieces when it breaks.\n\nIn all seriousness, if you can force the engine to InnoDB, do that.\nOtherwise, just ignore this. We are all consenting adults here and if\npeople cant\' RTFM on MySQL, they shouldn\'t be storing data in it.\n\n\n','<CEC4E338.12A5B%paul.montgomery@rackspace.com>',NULL),('<1386199742.2343.3.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 09:29:02',36000,'2013-12-04 23:29:02',NULL,'[openstack-dev] [Keystoneclient] [Keystone] Last released\n version of keystoneclient does not work with python33','Adrian, \n\nThe main blocker for the time being with keystoneclient and py3 is our\nuse of a library called HTTPretty in our testing - on which there is a\nvery recent thread. There is upstream work to make this py3 compatible\nbut i\'m not sure how quickly it\'s moving. \n\nAny code in keystoneclient itself that is not py33 compatible should be\nconsidered a bug - but obviously due to the missed testing we don\'t pick\nthis up very often.\n\nThere is no timeline at the moment, however anyone with py33 experience\nlooking to make this happen faster could contribute to this branch on\ngithub: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help\nupstream. Once there is a py33 release available keystoneclient will not\nbe far behind. \n\nJamie \n\nOn Wed, 2013-12-04 at 20:59 +0000, Adrian Otto wrote:\n> Dolph, \n> \n> \n> Is anyone already focusing on py33 compatibility for\n> python-keystoneclient? Has that effort been scoped? I\'d like to judge\n> whether it\'s reasonable to expect us to patch it up to be compatible\n> in the near term, or relax our expectations. For Solum, we are trying\n> to make all our code py33 compatible from the start, so we take it\n> seriously when the py33 gate fails. Please advise.\n> \n> \n> Thanks,\n> \n> \n> Adrian\n> \n> On Dec 4, 2013, at 12:24 PM, Dolph Mathews <dolph.mathews at gmail.com>\n>  wrote:\n> \n> > \n> > On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov\n> > <gokrokvertskhov at mirantis.com> wrote:\n> >         Hi, \n> >         \n> >         \n> >         I have failed tests in gate-solum-python33 because\n> >         kesytoneclient fails to import xmlrpclib. \n> >         The exact error is:\n> >         \"File\n> >         \"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py\", line 42, in <module>\n> >         2013-11-28 18:27:12.655 |     import xmlrpclib\n> >         2013-11-28 18:27:12.655 | ImportError: No module named\n> >         \'xmlrpclib\n> >         \"\n> >         This issue appeared because of xmlrpclib was renamed in\n> >         python33.\n> >         Is there any plan to release a new version\n> >         of keystoneclient with the fix for that issue? As I see it\n> >         is fixed in master.\n> >         \n> >         \n> >         If there is no new release for keystoneclient can you\n> >         recommend any workaround for this issue?\n> >         \n> >         \n> > \n> > \n> > I\'d be happy to make a release keystoneclient, but I don\'t believe\n> > that\'s the only issue with python 3 at the moment (at least on the\n> > CLI?). For example:\n> > \n> > \n> >   https://bugs.launchpad.net/python-keystoneclient/+bug/1249165\n> > \n> > \n> > In the current master, the above issue is only reproducible after\n> > syncing oslo (otherwise it fails on yet another python 3\n> > incompatibility).\n> >  \n> >         \n> >         Thanks\n> >         Georgy\n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n','<8C8ADE77-43C8-4929-8F5B-BD632F23E92B@rackspace.com>',NULL),('<1386201795-sup-242@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 16:06:35',-28800,'2013-12-05 00:06:35',NULL,'[openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n	released version of keystoneclient does not work with python33','Excerpts from Adrian Otto\'s message of 2013-12-04 15:44:45 -0800:\n> Jamie,\n> \n> Thanks for the guidance here. I am checking to see if any of our developers might take an interest in helping with the upstream work. At the very least, it might be nice to have some understanding of how much work there is to be done in HTTPretty.\n> \n\nSeems to me that we\'re still too early in the process for a downstream\napplication like Solum to gate on py3k. It will be more productive to\nfocus efforts on getting upstreams in-line and making sure they stay\nin-line.\n\n\n','<91EAC4DE-D15D-4F2D-92C2-7EEAB0CE446B@rackspace.com>',NULL),('<1386202295.6431.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 18:11:35',-21600,'2013-12-05 00:11:35',NULL,'[openstack-dev] Printing to stdout','On Wed, 2013-12-04 at 14:59 -0800, Abhishek Chanda wrote:\n> I am a new contributor. While poking around, I thought that a standard\n> way to print information to stdout is necessary in a number of places.\n> Is there a plan to put this into oslo? I could not find any existing\n> blueprint on this. I\'d be happy to take care of this.\n\nCan you be a little more specific?  In what context do you want to print\nto stdout?  That is, which client?  (Servers should never print to\nstdout; use the logging infrastructure for output.)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CACom5voRvPfF0=q54k3kgmcnorOW31bgSuCVVSsLZWgN5KuB-Q@mail.gmail.com>',NULL),('<1386206370.2343.25.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 11:19:30',36000,'2013-12-05 01:19:30',NULL,'[openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n released version of keystoneclient does not work with python33','Adrian, \n\nI had a look a little while ago and I don\'t *think* it\'s too bad.\nBecause it\'s hooking into sockets and dealing with web requests though\nthere is a lot of messing with what is unicode vs ascii and the py2 vs\npy3 differences. \n\nI\'m sure it\'s doable, but i hate those kind of problems :) \n\n>From a dev point of view it\'s a good library and i recommend the various\nclients look at it rather than our home grown client stubbing. \n\nInternally he\'s done some interesting things like maintaining his own\ncompat rather than just using six, and it\'s tested using an unknown\nframework that does a hook into PyObject * (CPython) which is just\nwrong. But we don\'t need to fix the whole project, just py33.\n\nJamie\n\n\nOn Wed, 2013-12-04 at 23:44 +0000, Adrian Otto wrote:\n> Jamie,\n> \n> Thanks for the guidance here. I am checking to see if any of our developers might take an interest in helping with the upstream work. At the very least, it might be nice to have some understanding of how much work there is to be done in HTTPretty.\n> \n> Cheers,\n> \n> Adrian\n> \n> On Dec 4, 2013, at 3:29 PM, Jamie Lennox <jamielennox at redhat.com>\n>  wrote:\n> \n> > Adrian, \n> > \n> > The main blocker for the time being with keystoneclient and py3 is our\n> > use of a library called HTTPretty in our testing - on which there is a\n> > very recent thread. There is upstream work to make this py3 compatible\n> > but i\'m not sure how quickly it\'s moving. \n> > \n> > Any code in keystoneclient itself that is not py33 compatible should be\n> > considered a bug - but obviously due to the missed testing we don\'t pick\n> > this up very often.\n> > \n> > There is no timeline at the moment, however anyone with py33 experience\n> > looking to make this happen faster could contribute to this branch on\n> > github: https://github.com/gabrielfalcao/HTTPretty/pull/124 and help\n> > upstream. Once there is a py33 release available keystoneclient will not\n> > be far behind. \n> > \n> > Jamie \n> > \n> > On Wed, 2013-12-04 at 20:59 +0000, Adrian Otto wrote:\n> >> Dolph, \n> >> \n> >> \n> >> Is anyone already focusing on py33 compatibility for\n> >> python-keystoneclient? Has that effort been scoped? I\'d like to judge\n> >> whether it\'s reasonable to expect us to patch it up to be compatible\n> >> in the near term, or relax our expectations. For Solum, we are trying\n> >> to make all our code py33 compatible from the start, so we take it\n> >> seriously when the py33 gate fails. Please advise.\n> >> \n> >> \n> >> Thanks,\n> >> \n> >> \n> >> Adrian\n> >> \n> >> On Dec 4, 2013, at 12:24 PM, Dolph Mathews <dolph.mathews at gmail.com>\n> >> wrote:\n> >> \n> >>> \n> >>> On Wed, Dec 4, 2013 at 1:26 PM, Georgy Okrokvertskhov\n> >>> <gokrokvertskhov at mirantis.com> wrote:\n> >>>        Hi, \n> >>> \n> >>> \n> >>>        I have failed tests in gate-solum-python33 because\n> >>>        kesytoneclient fails to import xmlrpclib. \n> >>>        The exact error is:\n> >>>        \"File\n> >>>        \"/home/jenkins/workspace/gate-solum-python33/.tox/py33/lib/python3.3/site-packages/keystoneclient/openstack/common/jsonutils.py\", line 42, in <module>\n> >>>        2013-11-28 18:27:12.655 |     import xmlrpclib\n> >>>        2013-11-28 18:27:12.655 | ImportError: No module named\n> >>>        \'xmlrpclib\n> >>>        \"\n> >>>        This issue appeared because of xmlrpclib was renamed in\n> >>>        python33.\n> >>>        Is there any plan to release a new version\n> >>>        of keystoneclient with the fix for that issue? As I see it\n> >>>        is fixed in master.\n> >>> \n> >>> \n> >>>        If there is no new release for keystoneclient can you\n> >>>        recommend any workaround for this issue?\n> >>> \n> >>> \n> >>> \n> >>> \n> >>> I\'d be happy to make a release keystoneclient, but I don\'t believe\n> >>> that\'s the only issue with python 3 at the moment (at least on the\n> >>> CLI?). For example:\n> >>> \n> >>> \n> >>>  https://bugs.launchpad.net/python-keystoneclient/+bug/1249165\n> >>> \n> >>> \n> >>> In the current master, the above issue is only reproducible after\n> >>> syncing oslo (otherwise it fails on yet another python 3\n> >>> incompatibility).\n> >>> \n> >>> \n> >>>        Thanks\n> >>>        Georgy\n> >>> \n> >>>        _______________________________________________\n> >>>        OpenStack-dev mailing list\n> >>>        OpenStack-dev at lists.openstack.org\n> >>>        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>> \n> >>> \n> >>> \n> >>> \n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> >> \n> >> \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<91EAC4DE-D15D-4F2D-92C2-7EEAB0CE446B@rackspace.com>',NULL),('<1386208776.2343.31.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 11:59:36',36000,'2013-12-05 01:59:36',NULL,'[openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n released version of keystoneclient does not work with python33','\nOn Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote:\n> On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto\n> <adrian.otto at rackspace.com> wrote:\n>         Jamie,\n>         \n>         Thanks for the guidance here. I am checking to see if any of\n>         our developers might take an interest in helping with the\n>         upstream work. At the very least, it might be nice to have\n>         some understanding of how much work there is to be done in\n>         HTTPretty.\n> \n> \n> (Dolph correct me if I am wrong, but...)\n> \n> \n> I don\'t think that there is much work to be done beyond getting that\n> pull request merged upstream.  Dolph ran the tests using the code from\n> the pull request somewhat successfully.  The errors that we saw were\n> just in keystoneclient code.\n\nBut I don\'t think that there own test suite runs under py33 with that\nbranch. So they\'ve hit the main issues, but we won\'t get a release in\nthat state. \n\n> -- \n> David\n> blog: http://www.traceback.org\n> twitter: http://twitter.com/dstanek\n> www: http://dstanek.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAO69Nd=3d3H6VCgewrW5rk838jBi_KK15vhE8OT0_efAp2NsQg@mail.gmail.com>',NULL),('<1386210433-sup-1034@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-04 20:54:35',-28800,'2013-12-05 04:54:35',NULL,'[openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n	released version of keystoneclient does not work with python33','Excerpts from Adrian Otto\'s message of 2013-12-04 16:53:16 -0800:\n> Clint,\n> \n> On Dec 4, 2013, at 4:06 PM, Clint Byrum <clint at fewbar.com>\n>  wrote:\n> \n> > Excerpts from Adrian Otto\'s message of 2013-12-04 15:44:45 -0800:\n> >> Jamie,\n> >> \n> >> Thanks for the guidance here. I am checking to see if any of our developers might take an interest in helping with the upstream work. At the very least, it might be nice to have some understanding of how much work there is to be done in HTTPretty.\n> >> \n> > \n> > Seems to me that we\'re still too early in the process for a downstream\n> > application like Solum to gate on py3k. It will be more productive to\n> > focus efforts on getting upstreams in-line and making sure they stay\n> > in-line.\n> \n> The py33 work is going to need to get done at some point. If we are py33 compatible from the start, there is less work to do later. I am suggesting that we clean up the upstreams. Keystone, and by association HTTPretty are Solum\'s upstreams for our auth feature. That\'s where I am suggesting we take a look.\n\nI totally agree, if you can do it now, fantastic. But you already depend\non python-keystoneclient, which has not done it yet. And they cannot do\nit because HTTPretty has not done it. So upstream is where the effort\nmust happen at the moment.\n\nDon\'t get me wrong, downstream applications like Solum are the driving\nforce behind the upstream library work. Solum should be pushing, always,\nfor py33 compliance. However, gating on it at this point would be ill\nadvised.\n\n\n','<ABC15BBD-E740-4734-8E19-B8ADB5A1C235@rackspace.com>',NULL),('<1386223360.56908.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 14:02:40',28800,'2013-12-05 06:02:40',NULL,'[Openstack] are results of functests and probetests right?','hello all,\nafter a long time of struggle of 3 months, I had installed swift successfully on my machine using the link http://docs.openstack.org/developer/swift/development_saio.html .\nBut, i have doubt on some results whether they are right. \nroot at pragya-VirtualBox:~# startmain\nStarting proxy-server...(/etc/swift/proxy-server.conf)\nStarting container-server...(/etc/swift/container-server/1.conf)\nStarting container-server...(/etc/swift/container-server/2.conf)\nStarting container-server...(/etc/swift/container-server/3.conf)\nStarting container-server...(/etc/swift/container-server/4.conf)\nStarting account-server...(/etc/swift/account-server/1.conf)\nStarting account-server...(/etc/swift/account-server/2.conf)\nStarting account-server...(/etc/swift/account-server/3.conf)\nStarting account-server...(/etc/swift/account-server/4.conf)\nStarting object-server...(/etc/swift/object-server/1.conf)\nStarting object-server...(/etc/swift/object-server/2.conf)\nStarting object-server...(/etc/swift/object-server/3.conf)\nStarting object-server...(/etc/swift/object-server/4.conf)\nroot at pragya-VirtualBox:~#curl -v -H \'X-Storage-User: test:tester\' -H \'X-Storage-Pass: testing\' http://127.0.0.1:8080/auth/v1.0 * About to connect() to 127.0.0.1 port 8080 (#0)\n*   Trying 127.0.0.1... connected \nGET /auth/v1.0 HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 127.0.0.1:8080 Accept: / X-Storage-User: test:tester X-Storage-Pass: testing\n>< HTTP/1.1 200 OK < X-Storage-Url: http://127.0.0.1:8080/v1/AUTH_test < X-Auth-Token: AUTH_tk93448ba4e6bb4cd491379daff388637f < Content-Type: text/html; charset=UTF-8 < X-Storage-Token: AUTH_tk93448ba4e6bb4cd491379daff388637f < Content-Length: 0 < X-Trans-Id: txf51e8a15f7a2477ba3ed0-0052a00d97 < Date: Thu, 05 Dec 2013 05:22:31 GMT <  * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 root at pragya-VirtualBox:~# curl -v -H \'X-Auth-Token: AUTH_tk93448ba4e6bb4cd491379daff388637f\' http://127.0.0.1:8080/v1/AUTH_test * About to connect() to 127.0.0.1 port 8080 (#0) *   Trying 127.0.0.1... connected GET /v1/AUTH_test HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 127.0.0.1:8080 Accept: / X-Auth-Token: AUTH_tk93448ba4e6bb4cd491379daff388637f\n>< HTTP/1.1 204 No Content < Content-Type: text/plain; charset=utf-8 < X-Account-Object-Count: 0 < X-Timestamp: 1386221096.76830 < X-Account-Bytes-Used: 0 < X-Account-Container-Count: 0 < X-Put-Timestamp: 1386221096.76830 < Content-Length: 0 < X-Trans-Id: txb4c0201ba5ac4179a363d-0052a00e28 < Date: Thu, 05 Dec 2013 05:24:56 GMT <  * Connection #0 to host 127.0.0.1 left intact * Closing connection #0 root at pragya-VirtualBox:~#  swift -A http://127.0.0.1:8080/auth/v1.0 -U test:tester -K testing stat Account: AUTH_test Containers: 0 Objects: 0 Bytes: 0 Content-Type: text/plain; charset=utf-8 X-Timestamp: 1386221206.86540 X-Trans-Id: txa106237afef342e09e338-0052a00e96 X-Put-Timestamp: 1386221206.86540 root at pragya-VirtualBox:~#  ~/swift/.functests \n>.....................................................................................................S............................................S......................................\nRan 185 tests in 84.345s\nOK (SKIP=2)\n/root\n......................\nRan 22 tests in 6.885s\nOK\n/root\nroot at pragya-VirtualBox:~# ~/swift/.probetests\nhttp://paste.openstack.org/show/54471/\nmy main doubt is in the result of probetest.\nPlease help\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/d7b772a6/attachment.html>\n\n',NULL,NULL),('<1386223422.74802.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 14:03:42',28800,'2013-12-05 06:03:42',NULL,'[Openstack] user interface for using swift','hello all\n\nI had installed swift using link http://docs.openstack.org/developer/swift/development_saio.html\n\nNow i want an user interface through which I can perform operations on swift. \n\n\nHow can I get an User interface for the same/\n\nPlease help.\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/fe5ba36a/attachment.html>\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1386231371.2343.33.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 18:16:11',36000,'2013-12-05 08:16:11',NULL,'[openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n released version of keystoneclient does not work with python33','On Thu, 2013-12-05 at 05:08 +0000, Adrian Otto wrote:\n> Hi Morgan!\n> \n> \n> Stackforge projects can be configured to make the CLA optional. I am\n> willing to speak to the HTTPretty maintainers about the benefits of\n> stackforge. Do we happen to know any of them? If not I can track them\n> down through email.\n> \n> \n> Adrian\n> \n\nThe main guy\'s email is fairly easy to find from his github page. But\nI\'m pretty sure he won\'t be interested. He\'s not involved in OpenStack\nat all. \n\nFeel free to try though. \n\nJamie\n> \n> \n> --\n> Adrian\n> \n> \n> -------- Original message --------\n> From: Morgan Fainberg \n> Date:12/04/2013 6:17 PM (GMT-08:00) \n> To: Jamie Lennox ,\"OpenStack Development Mailing List (not for usage\n> questions)\" \n> Subject: Re: [openstack-dev] [Keystoneclient] [Keystone] [Solum] Last\n> released version of keystoneclient does not work with python33 \n> \n> \n> \n> On December 4, 2013 at 18:05:07, Jamie Lennox (jamielennox at redhat.com)\n> wrote:\n> \n> > \n> > On Wed, 2013-12-04 at 20:48 -0500, David Stanek wrote: \n> > > On Wed, Dec 4, 2013 at 6:44 PM, Adrian Otto \n> > > <adrian.otto at rackspace.com> wrote: \n> > > Jamie, \n> > > \n> > > Thanks for the guidance here. I am checking to see if any of \n> > > our developers might take an interest in helping with the \n> > > upstream work. At the very least, it might be nice to have \n> > > some understanding of how much work there is to be done in \n> > > HTTPretty. \n> > > \n> > > \n> > > (Dolph correct me if I am wrong, but...) \n> > > \n> > > \n> > > I don\'t think that there is much work to be done beyond getting\n> > that \n> > > pull request merged upstream. Dolph ran the tests using the code\n> > from \n> > > the pull request somewhat successfully. The errors that we saw\n> > were \n> > > just in keystoneclient code. \n> > \n> > But I don\'t think that there own test suite runs under py33 with\n> > that \n> > branch. So they\'ve hit the main issues, but we won\'t get a release\n> > in \n> > that state. \n> Should we offer to bring HTTPretty under something like stackforge and\n> leverage our CI infrastructure?  Not sure how open the\n> owner/maintainers would be to this, but it would help to solve that\n> issue? downside is that pull-requests are no longer (gerrit instead)\n> used and IIRC CLA is still required for stackforge projects (might be\n> a detractor).  Just a passing thought (that might be irrelevant\n> depending on the owner/maintainer?s point of view).\n> \n> \n> \n> \n> ?Morgan\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<lrv7vn3gfgj5vxv51l8q28ng.1386220105275@email.android.com>',NULL),('<1386235260.79677.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 17:21:00',28800,'2013-12-05 09:21:00',NULL,'[Openstack] user interface for using swift','hello joe,\n\nI have CLI. But I want some GUI to perform all operations , eg., authentication, PUT/GET/DELETE/HEADetc. on account/container/object\n\nplease help\n\n\n\n\nOn Thursday, 5 December 2013 2:12 PM, Joe Hakim Rahme <joe.hakim.rahme at enovance.com> wrote:\n \nHello Pragya,\n>\n>I\'m not totally sure what you mean by user interface, but if you are looking for\n>a CLI client, you should check out python-swiftclient[1] easily available on\n>PyPI.\n>\n>---\n>Joe H. Rahme\n>\n>[1]: https://pypi.python.org/pypi/python-swiftclient/1.0\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/65eb0c27/attachment.html>\n\n','<367C5034-8992-4232-B815-3AEEB58ADD7D@enovance.com>',NULL),('<1386237803.14290.25.camel@t520.mbooth>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 10:03:23',0,'2013-12-05 10:03:23',NULL,'[openstack-dev] [policy] Let\'s make topics mandatory for\n openstack-dev','On Thu, 2013-12-05 at 11:35 +0200, Roman Prykhodchenko wrote:\n> Hi folks,\n> \n> Open Stack community grows continuously bringing more people and so new\n> initiatives and new projects. This growing amount of people, initiatives\n> and projects causes increasing the amount of discussions in our mailing\n> list.\n> \n> The problem which I\'m talking about is that controlling the mailing list\n> gets harder with the growth of the community. It takes too much time to\n> check for important emails and delete/archive the rest even now. And it\n> does not tend to get any easier in the future.\n> \n> Most of the email services and email clients support filtering incoming\n> emails. So one can automatically get rid of certain emails by creating\n> appropriate filters. Topics in subjects seem to be the best objects for\n> creating rules, i.e., when someone is interested only in Keystone he can\n> create an email filter for \'[keystone]\' substring in the subject.\n> \n> The problem with the topics is that a lot of emails in openstack-dev do\n> not contain topics in their subjects, which makes this kind of filtering\n> very ineffective.\n> \n> My proposal is to create an automated rule that rejects new emails, if\n> they do not contain any topic in their subject. What do you guys think?\n\nAlternatively, separate mailing lists for each current topic area. A\ntop-level mailing list could subscribe to all of them for anybody who\ntruly wants the fire hose.\n\nMatt\n\n\n\n','<52A048E0.4090500@mirantis.com>',NULL),('<1386243795.38440.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 19:43:15',28800,'2013-12-05 11:43:15',NULL,'[Openstack] user interface for using swift','thanks for reply sir,\n\nI had installed swift using link http://docs.openstack.org/developer/swift/development_saio.html\n\nNow, what should I do to use horizon for GUI with swift?\n\nPlease help\n\n\n\n\n\nOn Thursday, 5 December 2013 3:04 PM, Hai Quan Chen <chenhaiq at cn.ibm.com> wrote:\n \nThere is GUI in Horizon: \n>http://<horizon url>/project/containers \n>\n>\n>Best Regards!\n>\n>Chen Hai Quan (???) \n>Tivoli\n>TEL: 86-10-82454165\n>Mailto:chenhaiq at cn.ibm.com\n> \n>\n>\n>\n>\n>From: ? ? ?\n?pragya jain <prag_2648 at yahoo.co.in> \n>To: ? ? ?\n?Joe Hakim Rahme <joe.hakim.rahme at enovance.com>,\n\"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Date: ? ? ?\n?2013/12/05 17:25 \n>Subject: ? ?\n? ?Re: [Openstack]\nuser interface for using swift \n>>________________________________\n> \n>\n>\n>hello joe,\n>\n>I have CLI. But I want some GUI to perform all operations , eg., authentication,\nPUT/GET/DELETE/HEADetc. on account/container/object\n>\n>please help \n>\n> \n>On Thursday, 5 December 2013 2:12 PM, Joe\nHakim Rahme <joe.hakim.rahme at enovance.com> wrote: \n>Hello Pragya,\n>\n>I\'m not totally sure what you mean by user interface, but if you are looking\nfor\n>a CLI client, you should check out python-swiftclient[1] easily available\non\n>PyPI.\n>\n>---\n>Joe H. Rahme\n>\n>[1]: https://pypi.python.org/pypi/python-swiftclient/1.0\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/1f3d964c/attachment.html>\n\n','<OF9D0B3855.34F68679-ON48257C38.00347641-48257C38.00349F92@cn.ibm.com>',NULL),('<1386244688.42960.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 19:58:08',28800,'2013-12-05 11:58:08',NULL,'[Openstack] problem in creating container',' \nhello all,\n\nI had installed swift using link http://docs.openstack.org/developer/swift/development_saio.html\nI get an error in creating the container\n--------------\nroot at pragya-VirtualBox:~# sudo\nswift-init account start  \nStarting\naccount-server...(/etc/swift/account-server/1.conf)  \nStarting\naccount-server...(/etc/swift/account-server/2.conf)  \nStarting\naccount-server...(/etc/swift/account-server/3.conf)  \nStarting\naccount-server...(/etc/swift/account-server/4.conf)  \nroot at pragya-VirtualBox:~# sudo\nswift-init proxy restart  \nNo\nproxy-server running  \nStarting\nproxy-server...(/etc/swift/proxy-server.conf)  \nroot at pragya-VirtualBox:~# curl -v\n-H \'X-Storage-User: prag2648:prag\' -H \'X-Storage-Pass: pj2648\'\nhttp://127.0.0.1:8080/auth/v1.0  \nhttp://paste.openstack.org/show/54498/\nroot at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648  \nhttp://paste.openstack.org/show/54497/\nroot at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/photos  \nhttp://paste.openstack.org/show/54496/\nroot at pragya-VirtualBox:~# sudo\nswift-init container start\nStarting\ncontainer-server...(/etc/swift/container-server/1.conf)  \nStarting\ncontainer-server...(/etc/swift/container-server/2.conf)  \nStarting\ncontainer-server...(/etc/swift/container-server/3.conf)  \nStarting\ncontainer-server...(/etc/swift/container-server/4.conf)  \nroot at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/photos  \nhttp://paste.openstack.org/show/54495/\n----------------\n\nPlease help me in this regard\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/4edf64df/attachment.html>\n\n',NULL,NULL),('<1386259071-sup-1571@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 08:10:48',-28800,'2013-12-05 16:10:48',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> Why not just use glance?\n> \n\nI\'ve asked that question a few times, and I think I can collate the\nresponses I\'ve received below. I think enhancing glance to do these\nthings is on the table:\n\n1. Glance is for big blobs of data not tiny templates.\n2. Versioning of a single resource is desired.\n3. Tagging/classifying/listing/sorting\n4. Glance is designed to expose the uploaded blobs to nova, not users\n\nMy responses:\n\n1: Irrelevant. Smaller things will fit in it just fine.\n\n2: The swift API supports versions. We could also have git as a\nbackend. This feels like something we can add as an optional feature\nwithout exploding Glance\'s scope and I imagine it would actually be a\nwelcome feature for image authors as well. Think about Ubuntu maintaining\nofficial images. If they can keep the ID the same and just add a version\n(allowing users to lock down to a version if updated images cause issue)\nthat seems like a really cool feature for images _and_ templates.\n\n3: I\'m sure glance image users would love to have those too.\n\n4: Irrelevant. Heat will need to download templates just like nova, and\nmaking images publicly downloadable is also a thing in glance.\n\nIt strikes me that this might be a silo problem instead of an\nactual design problem. Folk should not be worried about jumping into\nGlance and adding features. Unless of course the Glance folk have\nreservations? (adding glance tag to the subject)\n\n\n','<529FDCE5.7000508@inaugust.com>',NULL),('<1386263250-sup-4405@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 09:10:37',-28800,'2013-12-05 17:10:37',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from James Slagle\'s message of 2013-12-05 08:35:12 -0800:\n> On Thu, Dec 5, 2013 at 11:10 AM, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> >> Why not just use glance?\n> >>\n> >\n> > I\'ve asked that question a few times, and I think I can collate the\n> > responses I\'ve received below. I think enhancing glance to do these\n> > things is on the table:\n> \n> I\'m actually interested in the use cases laid out by Heater from both\n> a template perspective and image perspective.  For the templates, as\n> Robert mentioned, Tuskar needs a solution for this requirement, since\n> it\'s deploying using templates.  For the images, we have the concept\n> of a \"golden\" image in TripleO and are heavily focused on image based\n> deployments.  Therefore, it seems to make sense that TripleO also\n> needs a way to version/tag known good images.\n> \n> Given that, I think it makes sense  to do this in a way so that it\'s\n> consumable for things other than just templates.  In fact, you can\n> almost s/template/image/g on the Heater wiki page, and it pretty well\n> lays out what I\'d like to see for images as well.\n> \n> > 1. Glance is for big blobs of data not tiny templates.\n> > 2. Versioning of a single resource is desired.\n> > 3. Tagging/classifying/listing/sorting\n> > 4. Glance is designed to expose the uploaded blobs to nova, not users\n> >\n> > My responses:\n> >\n> > 1: Irrelevant. Smaller things will fit in it just fine.\n> >\n> > 2: The swift API supports versions. We could also have git as a\n> > backend.\n> \n> I would definitely like to see a git backend for versioning.  No\n> reason to reimplement a different solution for what already works\n> well.  I\'m not sure we\'d want to put a whole image into git though.\n> Perhaps just it\'s manifest (installed components, software versions,\n> etc) in json format would go into git, and that would be associated\n> back to the binary image via uuid.  That would even make it easy to\n> diff changes between versions, etc.\n> \n\nRight, git for a big \'ol image makes little sense.\n\nI\'m suggesting that one might want to have two glances, one for images\nwhich just uses swift versions and would just expose a list of versions,\nand one for templates which would use git and thus expose more features\nlike a git remote for the repo. I\'m not sure if glance has embraced the\nextension paradigm yet, but this would fall nicely into it.\n\n> > This feels like something we can add as an optional feature\n> > without exploding Glance\'s scope and I imagine it would actually be a\n> > welcome feature for image authors as well. Think about Ubuntu maintaining\n> > official images. If they can keep the ID the same and just add a version\n> > (allowing users to lock down to a version if updated images cause issue)\n> > that seems like a really cool feature for images _and_ templates.\n> >\n> > 3: I\'m sure glance image users would love to have those too.\n> >\n> > 4: Irrelevant. Heat will need to download templates just like nova, and\n> > making images publicly downloadable is also a thing in glance.\n> >\n> > It strikes me that this might be a silo problem instead of an\n> > actual design problem. Folk should not be worried about jumping into\n> > Glance and adding features. Unless of course the Glance folk have\n> > reservations? (adding glance tag to the subject)\n> \n> I\'m +1 for adding these types of features to glance, or at least\n> something common, instead of making it specific to Heat templates.\n> \n\nRight, it may be that glance is too limited, but from what I\'ve seen,\nit is not and it already has the base concepts that \"HeaTeR\" wants to\nhave available.\n\n\n','<CAHV77z_svzLoycrB7YURvafMRqUW32o7P2_oiJ7xaqMTfSPL8g@mail.gmail.com>',NULL),('<1386263307.080313224@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-05 11:08:27',-21600,'2013-12-05 17:08:27',NULL,'[openstack-community] Links to process and branding for regional\n	OpenStack events','\nIn addition to http://www.openstack.org/brand/, there are these specific pages on the process and guidelines for organizing an OpenStack branded event:\n \n[http://www.openstack.org/marketing/Plan-or-Sponsor-an-OpenStack-Event/] http://www.openstack.org/marketing/Plan-or-Sponsor-an-OpenStack-Event/\n[https://www.openstack.org/brand/event-policy/] https://www.openstack.org/brand/event-policy/\n \nStay tuned for new regional event support capabilities and the list of 2014 industry events, coming in January.  Thank you.\n \nOn Thursday, December 5, 2013 6:00am, community-request at lists.openstack.org said:\n\n\n\n> Send Community mailing list submissions to\n> 	community at lists.openstack.org\n> \n> To subscribe or unsubscribe via the World Wide Web, visit\n> 	http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> or, via email, send a message with subject or body \'help\' to\n> 	community-request at lists.openstack.org\n> \n> You can reach the person managing the list at\n> 	community-owner at lists.openstack.org\n> \n> When replying, please edit your Subject line so it is more specific\n> than \"Re: Contents of Community digest...\"\n> \n> \n> Today\'s Topics:\n> \n>    1. Re: Idea: OpenStack Summit Indonesia (Stefano Maffulli)\n>    2. Re: Idea: OpenStack Summit Indonesia (Frans Thamura)\n>    3. Re: Idea: OpenStack Summit Indonesia (Sean Roberts)\n> \n> \n> ----------------------------------------------------------------------\n> \n> Message: 1\n> Date: Wed, 04 Dec 2013 11:55:03 -0800\n> From: Stefano Maffulli <stefano at openstack.org>\n> To: community at lists.openstack.org,  \"General, OpenStack\"\n> 	<openstack at lists.openstack.org>\n> Subject: Re: [openstack-community] Idea: OpenStack Summit Indonesia\n> Message-ID: <529F8897.4000007 at openstack.org>\n> Content-Type: text/plain; charset=ISO-8859-1\n> \n> Hi Frans,\n> \n> On 11/27/2013 05:23 AM, Frans Thamura wrote:\n> > The idea, several.topic in one day, rather one serial series\n> \n> there are a lot of events organized around the world about OpenStack but\n> only a few of them are organized by the OpenStack Foundation. What\n> usually happens is that a set of people/organizations decide to dedicate\n> one day or more for an OpenStack-related conference or meeting. The\n> European OpenStack days mentioned by Marton are one example, the ones in\n> Israel are another, OpenStack Tokio Day etc. The OpenStack Foundation\n> can support such events in different ways.\n> \n> If you and others in Indonesia want to organize a conference about\n> OpenStack all you have to do is to get started with a proposal for the\n> conference itself (will it be aimed at university students? local\n> government? businesses?), then think about a venue and dates and issue a\n> call for speakers. You may want to talk to your nearest Ambassador(s)\n> [in your case they may be Kavit Munshi, Ye Lu, Akira Yoshiyama and\n> Akihiro Hasegawa as they have other suggestions based on their experience].\n> \n> You may also want to get some support from local sponsors since that\n> will help the Foundation decide how to support it, if a sponsorship is\n> needed, etc.\n> \n> This suggestion is valid also for other groups around the world: if you\n> want to organize events for OpenStack talk to your nearest Ambassador\n> and pick their brain for ideas:\n> \n> http://www.openstack.org/blog/2013/11/announcing-our-first-openstack-ambassadors/\n> \n> Cheers,\n> /stef\n> \n> --\n> Ask and answer questions on https://ask.openstack.org\n> \n> \n> \n> ------------------------------\n> \n> Message: 2\n> Date: Thu, 5 Dec 2013 07:06:52 +0700\n> From: Frans Thamura <frans at meruvian.org>\n> To: Stefano Maffulli <stefano at openstack.org>\n> Cc: \"General, OpenStack\" <openstack at lists.openstack.org>,\n> 	\"community at lists.openstack.org\" <community at lists.openstack.org>\n> Subject: Re: [openstack-community] Idea: OpenStack Summit Indonesia\n> Message-ID:\n> 	<CAOeeQyqu1OixLsXUJBSJ3JPfQ2Y5P7aviURtZxL3TLwN927-9g at mail.gmail.com>\n> Content-Type: text/plain; charset=UTF-8\n> \n> Hi Stef\n> \n> I throw this idea, because want to know about brand restriction, i can\n> see that we can use OpenStack as a conference.\n> \n> Yes I think will be interesting if the conf (several speakers speak in\n> same time) use OpenStack name rather Cloud Conf.\n> \n> glad to know OpenStack Ambassador has been there and a lot of UG\n> people in our first os ambassadors.\n> \n> F\n> \n> --\n> Frans Thamura (???)\n> Shadow Master and Lead Investor\n> Meruvian.\n> Integrated Hypermedia Java Solution Provider.\n> \n> Mobile: +628557888699\n> Blog: http://blogs.mervpolis.com/roller/flatburger (id)\n> \n> FB: http://www.facebook.com/meruvian\n> TW: http://www.twitter.com/meruvian / @meruvian\n> Website: http://www.meruvian.org\n> \n> \"We grow because we share the same belief.\"\n> \n> \n> On Thu, Dec 5, 2013 at 2:55 AM, Stefano Maffulli <stefano at openstack.org>\n> wrote:\n> > Hi Frans,\n> >\n> > On 11/27/2013 05:23 AM, Frans Thamura wrote:\n> >> The idea, several.topic in one day, rather one serial series\n> >\n> > there are a lot of events organized around the world about OpenStack but\n> > only a few of them are organized by the OpenStack Foundation. What\n> > usually happens is that a set of people/organizations decide to dedicate\n> > one day or more for an OpenStack-related conference or meeting. The\n> > European OpenStack days mentioned by Marton are one example, the ones in\n> > Israel are another, OpenStack Tokio Day etc. The OpenStack Foundation\n> > can support such events in different ways.\n> >\n> > If you and others in Indonesia want to organize a conference about\n> > OpenStack all you have to do is to get started with a proposal for the\n> > conference itself (will it be aimed at university students? local\n> > government? businesses?), then think about a venue and dates and issue a\n> > call for speakers. You may want to talk to your nearest Ambassador(s)\n> > [in your case they may be Kavit Munshi, Ye Lu, Akira Yoshiyama and\n> > Akihiro Hasegawa as they have other suggestions based on their experience].\n> >\n> > You may also want to get some support from local sponsors since that\n> > will help the Foundation decide how to support it, if a sponsorship is\n> > needed, etc.\n> >\n> > This suggestion is valid also for other groups around the world: if you\n> > want to organize events for OpenStack talk to your nearest Ambassador\n> > and pick their brain for ideas:\n> >\n> >\n> http://www.openstack.org/blog/2013/11/announcing-our-first-openstack-ambassadors/\n> >\n> > Cheers,\n> > /stef\n> >\n> > --\n> > Ask and answer questions on https://ask.openstack.org\n> >\n> > _______________________________________________\n> > Community mailing list\n> > Community at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> \n> \n> \n> ------------------------------\n> \n> Message: 3\n> Date: Thu, 5 Dec 2013 02:17:15 +0000\n> From: Sean Roberts <seanrob at yahoo-inc.com>\n> To: Frans Thamura <frans at meruvian.org>\n> Cc: \"General, OpenStack\" <openstack at lists.openstack.org>,\n> 	\"community at lists.openstack.org\" <community at lists.openstack.org>\n> Subject: Re: [openstack-community] Idea: OpenStack Summit Indonesia\n> Message-ID: <2110C442-D2B2-4AB7-A508-3CC74EE5263D at yahoo-inc.com>\n> Content-Type: text/plain; charset=\"gb2312\"\n> \n> The community can use the brand along these lines http://www.openstack.org/brand/\n> \n> ~sean\n> \n> On Dec 4, 2013, at 16:10, \"Frans Thamura\"\n> <frans at meruvian.org<mailto:frans at meruvian.org>> wrote:\n> \n> Hi Stef\n> \n> I throw this idea, because want to know about brand restriction, i can\n> see that we can use OpenStack as a conference.\n> \n> Yes I think will be interesting if the conf (several speakers speak in\n> same time) use OpenStack name rather Cloud Conf.\n> \n> glad to know OpenStack Ambassador has been there and a lot of UG\n> people in our first os ambassadors.\n> \n> F\n> \n> --\n> Frans Thamura (???)\n> Shadow Master and Lead Investor\n> Meruvian.\n> Integrated Hypermedia Java Solution Provider.\n> \n> Mobile: +628557888699\n> Blog: http://blogs.mervpolis.com/roller/flatburger (id)\n> \n> FB: http://www.facebook.com/meruvian\n> TW: http://www.twitter.com/meruvian / @meruvian\n> Website: http://www.meruvian.org\n> \n> \"We grow because we share the same belief.\"\n> \n> \n> On Thu, Dec 5, 2013 at 2:55 AM, Stefano Maffulli\n> <stefano at openstack.org<mailto:stefano at openstack.org>> wrote:\n> Hi Frans,\n> \n> On 11/27/2013 05:23 AM, Frans Thamura wrote:\n> The idea, several.topic in one day, rather one serial series\n> \n> there are a lot of events organized around the world about OpenStack but\n> only a few of them are organized by the OpenStack Foundation. What\n> usually happens is that a set of people/organizations decide to dedicate\n> one day or more for an OpenStack-related conference or meeting. The\n> European OpenStack days mentioned by Marton are one example, the ones in\n> Israel are another, OpenStack Tokio Day etc. The OpenStack Foundation\n> can support such events in different ways.\n> \n> If you and others in Indonesia want to organize a conference about\n> OpenStack all you have to do is to get started with a proposal for the\n> conference itself (will it be aimed at university students? local\n> government? businesses?), then think about a venue and dates and issue a\n> call for speakers. You may want to talk to your nearest Ambassador(s)\n> [in your case they may be Kavit Munshi, Ye Lu, Akira Yoshiyama and\n> Akihiro Hasegawa as they have other suggestions based on their experience].\n> \n> You may also want to get some support from local sponsors since that\n> will help the Foundation decide how to support it, if a sponsorship is\n> needed, etc.\n> \n> This suggestion is valid also for other groups around the world: if you\n> want to organize events for OpenStack talk to your nearest Ambassador\n> and pick their brain for ideas:\n> \n> http://www.openstack.org/blog/2013/11/announcing-our-first-openstack-ambassadors/\n> \n> Cheers,\n> /stef\n> \n> --\n> Ask and answer questions on https://ask.openstack.org\n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org<mailto:Community at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org<mailto:Community at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> -------------- next part --------------\n> An HTML attachment was scrubbed...\n> URL:\n> <http://lists.openstack.org/pipermail/community/attachments/20131205/942f7d9f/attachment-0001.html>\n> \n> ------------------------------\n> \n> _______________________________________________\n> Community mailing list\n> Community at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/community\n> \n> \n> End of Community Digest, Vol 17, Issue 4\n> ****************************************\n>\n\n\n\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131205/0ff80e6c/attachment.html>\n\n','<mailman.9.1386244803.11402.community@lists.openstack.org>',NULL),('<1386263664-sup-7336@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 09:15:48',-28800,'2013-12-05 17:15:48',NULL,'[openstack-dev] creating a default for oslo config variables\n	within a project?','Excerpts from Julien Danjou\'s message of 2013-12-05 01:22:00 -0800:\n> On Wed, Dec 04 2013, Sean Dague wrote:\n> \n> > Honestly, I\'d love us to be clever and figure out a not dangerous way\n> > through this, even if unwise (where we can yell at the user in the LOGs\n> > loudly, and fail them in J if lock_dir=/tmp) that lets us progress\n> > through this while gracefully bringing configs into line.\n> \n> Correct me if I\'m wrong, but I think the correct way to deal with that\n> security problem is to use an atomic operation using open(2) with:\n>   open(pathname, O_CREAT | O_EXCL)\n> \n\nDOS by a malicious user creating it first is still trivial.\n\n> or mkstemp(3).\n> \n\nCan\'t use mkstemp as the point is this needs to be something shared\nbetween processes.\n\n\n','<87haanodon.fsf@dex.adm.naquadah.org>',NULL),('<1386266560-sup-6317@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 10:17:27',-28800,'2013-12-05 18:17:27',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Tim Schnell\'s message of 2013-12-05 09:49:03 -0800:\n> \n> On 12/5/13 11:33 AM, \"Randall Burt\" <randall.burt at RACKSPACE.COM> wrote:\n> \n> >On Dec 5, 2013, at 11:10 AM, Clint Byrum <clint at fewbar.com>\n> > wrote:\n> >\n> >> Excerpts from James Slagle\'s message of 2013-12-05 08:35:12 -0800:\n> >>> On Thu, Dec 5, 2013 at 11:10 AM, Clint Byrum <clint at fewbar.com> wrote:\n> >>>> Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> >>>>> Why not just use glance?\n> >>>>> \n> >>>> \n> >>>> I\'ve asked that question a few times, and I think I can collate the\n> >>>> responses I\'ve received below. I think enhancing glance to do these\n> >>>> things is on the table:\n> >>> \n> >>> I\'m actually interested in the use cases laid out by Heater from both\n> >>> a template perspective and image perspective.  For the templates, as\n> >>> Robert mentioned, Tuskar needs a solution for this requirement, since\n> >>> it\'s deploying using templates.  For the images, we have the concept\n> >>> of a \"golden\" image in TripleO and are heavily focused on image based\n> >>> deployments.  Therefore, it seems to make sense that TripleO also\n> >>> needs a way to version/tag known good images.\n> >>> \n> >>> Given that, I think it makes sense  to do this in a way so that it\'s\n> >>> consumable for things other than just templates.  In fact, you can\n> >>> almost s/template/image/g on the Heater wiki page, and it pretty well\n> >>> lays out what I\'d like to see for images as well.\n> >>> \n> >>>> 1. Glance is for big blobs of data not tiny templates.\n> >>>> 2. Versioning of a single resource is desired.\n> >>>> 3. Tagging/classifying/listing/sorting\n> >>>> 4. Glance is designed to expose the uploaded blobs to nova, not users\n> >>>> \n> >>>> My responses:\n> >>>> \n> >>>> 1: Irrelevant. Smaller things will fit in it just fine.\n> >>>> \n> >>>> 2: The swift API supports versions. We could also have git as a\n> >>>> backend.\n> >>> \n> >>> I would definitely like to see a git backend for versioning.  No\n> >>> reason to reimplement a different solution for what already works\n> >>> well.  I\'m not sure we\'d want to put a whole image into git though.\n> >>> Perhaps just it\'s manifest (installed components, software versions,\n> >>> etc) in json format would go into git, and that would be associated\n> >>> back to the binary image via uuid.  That would even make it easy to\n> >>> diff changes between versions, etc.\n> >>> \n> >> \n> >> Right, git for a big \'ol image makes little sense.\n> >> \n> >> I\'m suggesting that one might want to have two glances, one for images\n> >> which just uses swift versions and would just expose a list of versions,\n> >> and one for templates which would use git and thus expose more features\n> >> like a git remote for the repo. I\'m not sure if glance has embraced the\n> >> extension paradigm yet, but this would fall nicely into it.\n> >\n> >Alternatively, Glance could have configurable backends for each image\n> >type allowing for optimization without the (often times messy) extension\n> >mechanism? This is assuming it doesn\'t do this already - I really need to\n> >start digging here. In the spirit of general OpenStack architectural\n> >paradigms, as long as the service exposes a consistent interface for\n> >templates that includes versioning support, the back-end store and\n> >(possibly) the versioning \"engine\" should certainly be configurable.\n> >Swift probably makes a decent first/default implementation.\n> \n> I\'m not sure why we are attempting to fit a round peg in a square hole\n> here. Glance\'s entire design is built around serving images and there\n> absolutely is a difference between serving BLOBs versus relatively small\n> templates. Just look at the existing implementations, Heat already stores\n> the template directly in the database while Glance stores the blob in an\n> external file system.\n> \n\nWhat aspects of circles and squares do you find match glance and the\nHeater problem space? :-P\n\nIf this were as simple as geometric shape matching, my 4-year old could\ndo it, right? :) Let\'s use analogies, I _love_ analogies, but perhaps\nlets be more careful about whether they actually aid the discussion.\n\nThe blobs in the heat database are going to be a problem actually. I\'ve\ndealt with a very similar relatively large system, storing millions\nof resumes in a single table for a job candidate database. It performs\nhorribly even if you shard. These weren\'t 50MB resumes, these were 30 -\n50 kB resumes. That is because every time you need to pull all the rows\nyou have to pull giant amounts of data and generally just blow out all\nof the caches, buffers, etc. Keystone\'s token table for the sql token\nbackend has the same problem. RDBMS\'s are good at storing and retrieving\nrows of relatively predictably sized data. They suck for documents.\n\nHeat would do well to just store template references and fetch them in\nthe rare cases where the raw templates are needed (updates, user asks to\nsee it, etc). That could so easily be a glance reference.  And if Glance\nwas suddenly much smarter and more capable of listing/searching/etc. the\nthings in its database, then Heat gets a win, and so does Nova.\n\n> I\'m not opposed to having Glance as an optional configurable backend for\n> Heater but if you look at the existing database models for Glance, an\n> entirely separate schema would have to be created to support templates. I\n> also think that having Heater as a layer above Glance or whatever other\n> backend would allow for the flexibility for Heater\'s requirements to\n> diverge in the future from requirements that might make sense for images\n> but not templates.\n> \n\nHuh? How are templates any different from images? Stick the template\nin as the blob that is currently the image (note that there are\nrelatively small images too, like aki\'s for kernels which are just a\nfew MB). Add in some meta-data for finding/listing/displaying template\ndata efficiently. Bada-boom-bada-bing, you\'re done, right?\n\nI would love to hear about \"future requirements\" for Heater that won\'t\nfit into Glance. But thus far, I am struggling to see where this could\ngo that wouldn\'t be a place Glance also wants to go.\n\n\n','<CEC6173A.79AE%tim.schnell@rackspace.com>',NULL),('<1386267698-sup-5337@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 10:23:11',-28800,'2013-12-05 18:23:11',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Randall Burt\'s message of 2013-12-05 09:05:44 -0800:\n> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com>\n>  wrote:\n> \n> > Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> >> Why not just use glance?\n> >> \n> > \n> > I\'ve asked that question a few times, and I think I can collate the\n> > responses I\'ve received below. I think enhancing glance to do these\n> > things is on the table:\n> > \n> > 1. Glance is for big blobs of data not tiny templates.\n> > 2. Versioning of a single resource is desired.\n> > 3. Tagging/classifying/listing/sorting\n> > 4. Glance is designed to expose the uploaded blobs to nova, not users\n> > \n> > My responses:\n> > \n> > 1: Irrelevant. Smaller things will fit in it just fine.\n> \n> Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance.\n> \n\nOptimizations can be improved for various use cases. The design, however,\nhas no assumptions that I know about that would invalidate storing blobs\nof yaml/json vs. blobs of kernel/qcow2/raw image.\n\n\n','<C792F195-6134-4035-8725-57D3567D1DBA@rackspace.com>',NULL),('<1386273224.151919402@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 14:53:44',-18000,'2013-12-05 19:53:44',NULL,'[openstack-dev] [glance] Action-Requested: In progress\n	bugs/blueprints/abandoned patches','Hey Glance folks,\n\nIt seems there are a fairly large number of abandoned patches that are still valuable. Some were auto-abandoned by jenkins without negative reviews and others were -2\'d for the Havana feature freeze then abandoned and forgotten. \n\nI want to ask everyone to look over their abandoned patches and restore any that are still relevant. \n\nUse this link to see your abandoned patches, just replace \"alex-meade\" with your own launchpad id.\n\nhttps://review.openstack.org/#/q/status:abandoned+project:openstack/glance+owner:alex-meade,n,z\n\nAlso, if you have any \"in progress\" bugs/blueprints assigned to you that you are no longer working on, please unassign yourself.\n\nThanks,\n\n-Alex\n\n\n\n',NULL,NULL),('<1386278095-sup-5199@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 13:25:46',-28800,'2013-12-05 21:25:46',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Andrew Plunk\'s message of 2013-12-05 12:42:49 -0800:\n> >Excerpts from Randall Burt\'s message of 2013-12-05 09:05:44 -0800:\n> >> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com>\n> >>  wrote:\n> >>\n> >> > Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> >> >> Why not just use glance?\n> >> >>\n> >> >\n> >> > I\'ve asked that question a few times, and I think I can collate the\n> >> > responses I\'ve received below. I think enhancing glance to do these\n> >> > things is on the table:\n> >> >\n> >> > 1. Glance is for big blobs of data not tiny templates.\n> >> > 2. Versioning of a single resource is desired.\n> >> > 3. Tagging/classifying/listing/sorting\n> >> > 4. Glance is designed to expose the uploaded blobs to nova, not users\n> >> >\n> >> > My responses:\n> >> >\n> >> > 1: Irrelevant. Smaller things will fit in it just fine.\n> >>\n> >> Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance.\n> >>\n> >\n> >Optimizations can be improved for various use cases. The design, however,\n> >has no assumptions that I know about that would invalidate storing blobs\n> >of yaml/json vs. blobs of kernel/qcow2/raw image.\n> \n> I think we are getting out into the weeds a little bit here. It is important to think about these apis in terms of what they actually do, before the decision of combining them or not can be made.\n> \n> I think of HeatR as a template storage service, it provides extra data and operations on templates. HeatR should not care about how those templates are stored.\n> Glance is an image storage service, it provides extra data and operations on images (not blobs), and it happens to use swift as a backend.\n> \n> If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field \"minRam\" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it\'s own service, or becomes part of Heat.\n> \n\nI spoke at length via G+ with Randall and Tim about this earlier today.\nI think I understand the impetus for all of this a little better now.\n\nBasically what I\'m suggesting is that Glance is only narrow in scope\nbecause that was the only object that OpenStack needed a catalog for\nbefore now.\n\nHowever, the overlap between a catalog of images and a catalog of\ntemplates is quite comprehensive. The individual fields that matter to\nimages are different than the ones that matter to templates, but that\nis a really minor detail isn\'t it?\n\nI would suggest that Glance be slightly expanded in scope to be an\nobject catalog. Each object type can have its own set of fields that\nmatter to it.\n\nThis doesn\'t have to be a minor change to glance to still have many\nadvantages over writing something from scratch and asking people to\ndeploy another service that is 99% the same as Glance.\n\n\n','<CDEAE34515107A4A92D7B32C0E5DFD4E012FAB60@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1386278784-sup-5738@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 13:50:33',-28800,'2013-12-05 21:50:33',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Tim Schnell\'s message of 2013-12-05 13:07:17 -0800:\n> On 12/5/13 12:17 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> >Excerpts from Tim Schnell\'s message of 2013-12-05 09:49:03 -0800:\n> >> \n> >> On 12/5/13 11:33 AM, \"Randall Burt\" <randall.burt at RACKSPACE.COM> wrote:\n> >> \n> >> >On Dec 5, 2013, at 11:10 AM, Clint Byrum <clint at fewbar.com>\n> >> > wrote:\n> >I would love to hear about \"future requirements\" for Heater that won\'t\n> >fit into Glance. But thus far, I am struggling to see where this could\n> >go that wouldn\'t be a place Glance also wants to go.\n> \n> I know we covered this a bit in the hangout but one possibility that I\n> think I failed to articulate is the fact that the template is a parseable\n> data representation while an image is a binary object. In my original\n> email I mentioned having a discussion about moving some of the \"template\"\n> metadata like application information and documentation into the HOT\n> specification.\n> \n\nI\'ve gone on record before as saying that having things in the template\nschema that should be in the catalog is a mistake. I stand by that\nassertion. However that is just for HOT, I think for a full blown\npackaging format, that may not be the case and so I agree there may be\na case for parsing the contents of the uploaded object.\n\n> This has important ramifications for the user experience as well as\n> whether or not abstracting Glance to \"one-size-fits-all\" is actually\n> feasible at an implementation level. Ideally the Heat template would serve\n> as the source of truth for information like \"application-version\" and\n> \"template documentation\", in the original Heater proposal this is\n> important because this data would have to be extracted from the template\n> and stored in a metadata field if it is relevant to the way that Heater\n> allows you to search or index different templates.\n> \n\nGiven a separate service, how wold you design things differently than\nglance to make this parsing work. As I recall, when you create an\nimage for glance, it just makes a record in the registry and a place to\nupload it to in the storage. Would you do this differently? Does that\ninvalidate parsing?\n\nPresumably after uploading your template to storage, you would need a\nprocess which inspects the data and populates the registry. How would\nglance\'s design preclude this given the more generic object schema that\nwe discussed.\n\n> If we had to pass a duplicate version of this metadata in the HTTP Request\n> we could avoid grabbing this information from the template but we open up\n> data integrity issues. What happens when the end-user updates the metadata\n> but not the template? At the same time, I would reiterate that we can\'t\n> just make this data a \"Heater/Template Catalog\" metadata issue because we\n> want the experience of the template to be consistent regardless of how the\n> end-user obtains the template. This is why I would consider this\n> information to belong as part of the HOT specification.\n> \n\nDon\'t take this the wrong way, but that would be absurd. Either you\nmaintain it as the source of truth, or it is derived from the source\nof truth. \"What if\" I upload lolcatz instead of a template? I can\nhas meta-data where there is none? Let\'s stick to the main question:\nCan Glance\'s scope be expanded to have data derived from the objects\nthemselves. I think the answer is a resounding yes.\n\n> This is relevant to the Glance conversation because, just by the template\n> existing in a different format than an image, we have already introduced\n> logic in Glance that cannot be abstracted. We could most likely build an\n> abstraction layer that covers some large percentage of the overlap in CRUD\n> operations between images and templates but I do not think that we can\n> expect to do this for every use case with Heat templates.\n> \n\nWho said that there would not be logic per object type? The point was to\nhave a generic object registry, but not an abstract object registry. You\nstill instantiate them by uploading content and in doing so the objects\ntake on all of the attributes of their class. So images are opaque.\nThings that allow parsing are not.\n\n> I know that I cannot provide a future use case that would exemplify this\n> problem but I can imagine that if we choose this design path going\n> forward, then we will continue to increase the scope of Glance with every\n> new type of object (maybe Solum assemblies?).\n> \n\nIf Heater were its own service, and Solum assemblies were added,\nrequiring some new things like multi-file objects, would you support\nSolum developers wanting to write a new registry because their use-case\nis slightly different?\n\n> I do agree that in general, we should continue to attempt to drive\n> consistency and congruency across Openstack projects when possible. I am\n> just concerned that this design will take us down rabbit holes both now\n> and in the future when it comes to the implementation details. In the\n> bigger picture I am attempting to weigh the value of building this\n> complexity into Glance against putting Heater into its own project or Heat.\n> \n\nWriting a new service will take you down much deeper rabbit holes that\nlook a lot like the rabbit holes the Glance developers already went down,\nonly you won\'t have all of the collected wisdom that is wrapped up in\na service that has existed and been in use doing 90% of what you are\nsuggesting must be re-done in a slightly different way.\n\n\n','<CEC64355.7A0D%tim.schnell@rackspace.com>',NULL),('<1386279481.1375.74.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 21:38:01',0,'2013-12-05 21:38:01',NULL,'[openstack-dev] [oslo] maintenance policy for code graduating\n from the incubator','On Mon, 2013-12-02 at 11:00 -0500, Doug Hellmann wrote:\n\n> I have updated the Oslo wiki page with these details and would appreciate\n> feedback on the wording used there.\n> \n> https://wiki.openstack.org/wiki/Oslo#Graduation\n\nThanks Doug, that sounds perfect to me.\n\nMark.\n\n\n\n','<CADb+p3S1NSKidzoiSDHXeCBJCaV9DmvhQ=O8709Pes5iCWAkpQ@mail.gmail.com>',NULL),('<1386280430.1375.84.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 21:53:50',0,'2013-12-05 21:53:50',NULL,'[openstack-dev] [Nova][TripleO] Nested resources','Hi Kevin,\n\nOn Mon, 2013-12-02 at 12:39 -0800, Fox, Kevin M wrote:\n> Hi all,\n> \n> I just want to run a crazy idea up the flag pole. TripleO has the\n> concept of an under and over cloud. In starting to experiment with\n> Docker, I see a pattern start to emerge.\n> \n>  * As a User, I may want to allocate a BareMetal node so that it is\n> entirely mine. I may want to run multiple VM\'s on it to reduce my own\n> cost. Now I have to manage the BareMetal nodes myself or nest\n> OpenStack into them.\n>  * As a User, I may want to allocate a VM. I then want to run multiple\n> Docker containers on it to use it more efficiently. Now I have to\n> manage the VM\'s myself or nest OpenStack into them.\n>  * As a User, I may want to allocate a BareMetal node so that it is\n> entirely mine. I then want to run multiple Docker containers on it to\n> use it more efficiently. Now I have to manage the BareMetal nodes\n> myself or nest OpenStack into them.\n> \n> I think this can then be generalized to:\n> As a User, I would like to ask for resources of one type (One AZ?),\n> and be able to delegate resources back to Nova so that I can use Nova\n> to subdivide and give me access to my resources as a different type.\n> (As a different AZ?)\n> \n> I think this could potentially cover some of the TripleO stuff without\n> needing an over/under cloud. For that use case, all the BareMetal\n> nodes could be added to Nova as such, allocated by the \"services\"\n> tenant as running a nested VM image type resource stack, and then made\n> available to all tenants. Sys admins then could dynamically shift\n> resources from VM providing nodes to BareMetal Nodes and back as\n> needed.\n> \n> This allows a user to allocate some raw resources as a group, then\n> schedule higher level services to run only in that group, all with the\n> existing api.\n> \n> Just how crazy an idea is this?\n\nFWIW, I don\'t think it\'s a crazy idea at all - indeed I mumbled\nsomething similar a few times in conversation with random people over\nthe past few months :)\n\nWith the increasing interest in containers, it makes a tonne of sense -\nyou provision a number of VMs and now you want to carve them up by\nallocating containers on them. Right now, you\'d need to run your own\ninstance of Nova for that ... which is far too heavyweight.\n\nIt is a little crazy in the sense that it\'s a tonne of work, though.\nThere\'s not a whole lot of point in discussing it too much until someone\nshows signs of wanting to implement it :)\n\nOne problem is how the API would model this nesting, another problem is\nmaking the scheduler aware that some nodes are only available to the\ntenant which owns them but maybe a bigger problem is the security model\naround allowing a node managed by an untrusted become a compute node.\n\nMark.\n\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C667BED2E@EMAIL05.pnl.gov>',NULL),('<1386281664.1375.89.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 22:14:24',0,'2013-12-05 22:14:24',NULL,'[openstack-dev] [UX] Topics Summary','On Tue, 2013-12-03 at 09:36 +0100, Jaromir Coufal wrote:\n> Hey OpenStackers,\n> \n> based on the latest discussions, it was asked if we can try to post \n> regular updates of what is happening in our community (mostly on Askbot \n> forum: http://ask-openstackux.rhcloud.com).\n> \n> In this e-mail, I\'d like to summarize ongoing issues and try to cover \n> updates weekly (or each 14 days - based on content).\n\nJust catching up on this now and ... wow, that\'s a lot of really\nexciting stuff!\n\nThe full summary is great, but it could be really great to pull out a\ncouple of the most interesting wireframes or mockups as a highlight to\nwhet the appetite of casual followers like me :)\n\nThanks for all this,\nMark.\n\n> \n> Issues by priority:\n> ---------------\n> ** TripleO UI - Resource Management:* \n> http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/\n>      - TripleO UI is close to start to be implemented - we really need \n> to get resource on this topics\n>      - Resource Management is about to start - it was already reviewed \n> without any bigger objections, there are just smaller updates\n> ** TripleO UI - Deployment Management:* \n> http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/\n>      - Deployment Management is completely new section\n>      - Implementation needs to start ASAP\n>      - At the moment the concept is the most important, so we don\'t have \n> major changes later\n>      - We can get into granular details later\n>      - Review review review please\n> ** Horizon - Navigation:* \n> http://ask-openstackux.rhcloud.com/question/2/openstack-dashboard-navigation-redesign/?answer=99#post-id-99\n>      - After couple of proposals and discussions, at summit we decided \n> to go for vertical navigation\n>      - Updated Vertical navigation proposal (wireframes)\n> ** Horizon - Information Architecture: \n> *http://ask-openstackux.rhcloud.com/question/1/openstack-ui-information-architecture/?answer=94#post-id-94\n>      - Thanks to David we have updated IA and need more eyes on it\n>      - Anybody who is dealing with adding features to Horizon, please \n> have a look, feedback is warmly welcome\n> \n> Other also important topics:\n> ----------------------- (without any specific order)\n> ** OpenStack Personas*: \n> http://ask-openstackux.rhcloud.com/question/68/openstack-personas/\n>      - Couple of months ago there started initiative to create OpenStack \n> Personas\n>      - Based on Dave\'s document, Ju started the thread to move this \n> effort forward (should hep in various areas)\n>      - Matt shared with us their document for 3 personas which is very \n> helpful\n>      - Any other insights are very welcome\n> ** Horizon - Updating Modals layout:* \n> http://ask-openstackux.rhcloud.com/question/11/modals-and-supporting-different-screen-sizes/\n>      - Modals are not using the screen efficiently\n>      - Proposal for modal vs. embedded view (agreed on keeping modal)\n>      - We need to get updated characteristics for improving the layout \n> of modal window\n> ** Horizon - Improve \'Launching Instance\' workflow*\n>      - Based on Cedric\'s proposal we have couple of topics to discuss \n> around improving a UX of instance launching workflow\n>      * Horizon - Improve selection of flavor and image: \n> http://ask-openstackux.rhcloud.com/question/12/enhance-the-selection-of-a-flavor-and-an-image/\n>      * Horizon - Improve Boot source selection: \n> http://ask-openstackux.rhcloud.com/question/13/improve-boot-source-ux-ephemeral-vs-persistent-disk/\n> ** Horizon - Where to use wizards:* \n> http://ask-openstackux.rhcloud.com/question/81/wizard-ui-for-workflow/\n>      - Toshi started very useful discussion about where the wizards are \n> needed\n> ** Horizon - Mobile UI: \n> *http://ask-openstackux.rhcloud.com/question/67/horizon-mobile-ui/\n>      - Maxim started to move forward Mobile UI for Horizon, they already \n> have HTML5 prototype, check it out\n> ** TripleO UI - Node / Rack / Resource class details**:* \n> http://ask-openstackux.rhcloud.com/question/66/tuskar-ui-node-rack-and-resource-class-details/\n>      - Liz and I, we put together set of wireframes for infrastructure \n> detail pages\n>      - However, this one needs to be updated based on latest direction\n>      - We will re-use node details at the moment (racks and classes are \n> postponed)\n> ** Horizon - Overview enhancements: \n> *http://ask-openstackux.rhcloud.com/question/59/improvements-to-horizon-overview/\n>      - Liz put together proposal for improving Horizon\'s Overview page\n> ** Horizon - Icon set for instance actions*: \n> http://ask-openstackux.rhcloud.com/question/70/use-icon-set-instead-of-instanceaction-button/\n>      - Garry is proposing to use icons instead of dropdown for instance \n> actions\n>      - There is ongoing discussion about how to visualize Instance objects\n> \n> For the first bit, it was a little bit longer e-mail, but I hope it is \n> useful for you. If you have any proposal or feedback to this format, \n> please share it.\n> \n> Everybody interested in helping UX efforts to move forward, you are the \n> most certainly welcome\n> \n> Cheers\n> -- Jarda\n> \n> --- Jaromir Coufal (jcoufal)\n> --- OpenStack User Experience\n> --- IRC: #openstack-ux (at FreeNode)\n> --- Forum: http://ask-openstackux.rhcloud.com\n> --- Wiki: https://wiki.openstack.org/wiki/UX\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<529D9807.5040702@redhat.com>',NULL),('<1386283977.1375.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 22:52:57',0,'2013-12-05 22:52:57',NULL,'[openstack-dev] [openstack-tc] Incubation Request for Barbican','On Mon, 2013-12-02 at 22:09 +0000, Jarret Raim wrote:\n\n> It looks like the project was moved to its own repo in April. However, I\n> can?t seem to find the docs anywhere? The only thing I see is a design doc\n> here [1]. Are there plans for it to be packaged and put into Pypi?\n> \n...\n> \n> [1] https://wiki.openstack.org/wiki/Oslo/Messaging\n\nSorry for the slow response to this and that all you could find is that\ndesign document. I\'ve added a link to the full API docs from the design\ndoc:\n\n  http://docs.openstack.org/developer/oslo.messaging/\n\nMark.\n\n\n\n','<CEC2543C.83BC8%jarret.raim@rackspace.com>',NULL),('<1386283977.1375.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-12-05 22:52:57',0,'2013-12-05 22:52:57',NULL,'[openstack-tc] [openstack-dev] Incubation Request for Barbican','On Mon, 2013-12-02 at 22:09 +0000, Jarret Raim wrote:\n\n> It looks like the project was moved to its own repo in April. However, I\n> can?t seem to find the docs anywhere? The only thing I see is a design doc\n> here [1]. Are there plans for it to be packaged and put into Pypi?\n> \n...\n> \n> [1] https://wiki.openstack.org/wiki/Oslo/Messaging\n\nSorry for the slow response to this and that all you could find is that\ndesign document. I\'ve added a link to the full API docs from the design\ndoc:\n\n  http://docs.openstack.org/developer/oslo.messaging/\n\nMark.\n\n\n\n','<CEC2543C.83BC8%jarret.raim@rackspace.com>',NULL),('<1386284246.1375.98.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 22:57:26',0,'2013-12-05 22:57:26',NULL,'[openstack-dev] [openstack-tc] Incubation Request for Barbican','On Mon, 2013-12-02 at 17:33 -0500, Monty Taylor wrote:\n> \n> On 12/02/2013 05:09 PM, Jarret Raim wrote:\n...\n> >> I\'d like to address the use of Celery.\n> >>\n> >> WTF\n> >>\n> >> Barbican has been around for 9 months, which means that it does not\n> >> predate the work that has become oslo.messaging. It doesn\'t even try. It\n> >> uses a completely different thing.\n> >>\n> >> The use of celery needs to be replaced with oslo. Full stop. I do not\n> >> believe it makes any sense to spend further time considering a project\n> >> that\'s divergent on such a core piece. Which is a shame - because I\n> >> think that Barbican is important and fills an important need and I want\n> >> it to be in. BUT - We don\'t get to end-run around OpenStack project\n> >> choices by making a new project on the side and then submitting it for\n> >> incubation. It\'s going to be a pile of suck to fix this I\'m sure, and\n> >> I\'m sure that it\'s going to delay getting actually important stuff done\n> >> - but we deal with too much crazy as it is to pull in a non-oslo\n> >> messaging and event substrata.\n> > \n> > \n> > Is the challenge here that celery has some weird license requirements? Or\n> > that it is a new library?\n> \n> The second thing - as a thing to address functionality that has been in\n> OpenStack since the beginning.\n> \n> > When we started the Barbican project in February of this year,\n> > oslo.messaging did not exist. If I remember correctly, at the time we were\n> > doing architecture set up, the messaging piece was not available as a\n> > standalone library, was not available on PyPi and had no documentation.\n> \n> That is true. However, the equivalent oslo-incubator pieces were there.\n> You can also get the latest pre-release library here:\n> \n> -f\n> http://tarballs.openstack.org/oslo.messaging/oslo.messaging-1.2.0a11.tar.gz#egg=oslo.messaging-1.2.0a11\n> oslo.messaging>=1.2.0a11\n> \n> As soon as we get the wheel publication pre-release code working, those\n> will go to pypi.\n> \n> > It looks like the project was moved to its own repo in April. However, I\n> > can?t seem to find the docs anywhere? The only thing I see is a design doc\n> > here [1]. Are there plans for it to be packaged and put into Pypi?\n> > \n> > We are probably overdue to look at oslo.messaging again, but I don?t think\n> > it should be a blocker for our incubation. I\'m happy to take a look to see\n> > what we can do during the Icehouse release cycle. Would that be\n> > sufficient? \n> \n> I think it would go a long way if you had a roadmap for how you\'re going\n> to move to oslo.messaging from celery. The worrying part for me, to be\n> honest, is that you didn\'t sync up with the state of the art in that\n> subject across openstack but instead went to a library that clearly\n> no-one else was using. A couple of conversations with markmc or\n> dhellman, or anyone from oslo, or anyone from any of the projects that\n> are currently also using Rabbit (or zeromq or qpid) for the reasons\n> you\'re using it would have gotten you aligned pretty quickly with how\n> everyone else is doing this ... OR, and argument could have been made as\n> to why all of that was a terrible idea and that the whole project should\n> move to celery.\n> \n> It\'s not that oslo-incubator was unknown - you\'re using other things.\n> \n> When we look at incubating things, part of it is about the tech, but\n> part of it is the question about whether or not the project is going to\n> add to the whole\'s ability to be greater than the sum of its parts, of\n> if we\'re going to inherit another group of folks who will be balkanized\n> in the corner somewhere.\n> \n> I don\'t want to sound punitive, that\'s not my intent - and I want you\n> guys to succeed and to be a part of things. I just want to be careful\n> that we don\'t add more complexity and confusion into an already\n> difficult to fully digest landscape. I want to make sure that when we\n> release an integrated release of OpenStack that it\'s an actual\n> integrated stack that works together, and I want to make sure that we\n> have an integrated developer community.\n> \n> SO - without drawing a hard line in the sand or anything, I think that a\n> discussion of what the real concrete plans are around alignment with the\n> messaging strata in OpenStack is will probably be one of the more\n> important questions we look at.\n\nI agree that this is concerning. And that what\'s concerning isn\'t so\nmuch that the project did something different, but rather that choice\nwas apparently made because the project thought it was perfectly fine\nfor them to ignore what other OpenStack projects do and go off and do\nits own thing.\n\nWe can\'t make this growth in the number of OpenStack projects work if\neach project goes off randomly and does its own thing without any\nconcern for the difficulties that creates.\n\nMark.\n\n\n\n','<529D0ACC.50106@inaugust.com>',NULL),('<1386284246.1375.98.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-12-05 22:57:26',0,'2013-12-05 22:57:26',NULL,'[openstack-tc] [openstack-dev] Incubation Request for Barbican','On Mon, 2013-12-02 at 17:33 -0500, Monty Taylor wrote:\n> \n> On 12/02/2013 05:09 PM, Jarret Raim wrote:\n...\n> >> I\'d like to address the use of Celery.\n> >>\n> >> WTF\n> >>\n> >> Barbican has been around for 9 months, which means that it does not\n> >> predate the work that has become oslo.messaging. It doesn\'t even try. It\n> >> uses a completely different thing.\n> >>\n> >> The use of celery needs to be replaced with oslo. Full stop. I do not\n> >> believe it makes any sense to spend further time considering a project\n> >> that\'s divergent on such a core piece. Which is a shame - because I\n> >> think that Barbican is important and fills an important need and I want\n> >> it to be in. BUT - We don\'t get to end-run around OpenStack project\n> >> choices by making a new project on the side and then submitting it for\n> >> incubation. It\'s going to be a pile of suck to fix this I\'m sure, and\n> >> I\'m sure that it\'s going to delay getting actually important stuff done\n> >> - but we deal with too much crazy as it is to pull in a non-oslo\n> >> messaging and event substrata.\n> > \n> > \n> > Is the challenge here that celery has some weird license requirements? Or\n> > that it is a new library?\n> \n> The second thing - as a thing to address functionality that has been in\n> OpenStack since the beginning.\n> \n> > When we started the Barbican project in February of this year,\n> > oslo.messaging did not exist. If I remember correctly, at the time we were\n> > doing architecture set up, the messaging piece was not available as a\n> > standalone library, was not available on PyPi and had no documentation.\n> \n> That is true. However, the equivalent oslo-incubator pieces were there.\n> You can also get the latest pre-release library here:\n> \n> -f\n> http://tarballs.openstack.org/oslo.messaging/oslo.messaging-1.2.0a11.tar.gz#egg=oslo.messaging-1.2.0a11\n> oslo.messaging>=1.2.0a11\n> \n> As soon as we get the wheel publication pre-release code working, those\n> will go to pypi.\n> \n> > It looks like the project was moved to its own repo in April. However, I\n> > can?t seem to find the docs anywhere? The only thing I see is a design doc\n> > here [1]. Are there plans for it to be packaged and put into Pypi?\n> > \n> > We are probably overdue to look at oslo.messaging again, but I don?t think\n> > it should be a blocker for our incubation. I\'m happy to take a look to see\n> > what we can do during the Icehouse release cycle. Would that be\n> > sufficient? \n> \n> I think it would go a long way if you had a roadmap for how you\'re going\n> to move to oslo.messaging from celery. The worrying part for me, to be\n> honest, is that you didn\'t sync up with the state of the art in that\n> subject across openstack but instead went to a library that clearly\n> no-one else was using. A couple of conversations with markmc or\n> dhellman, or anyone from oslo, or anyone from any of the projects that\n> are currently also using Rabbit (or zeromq or qpid) for the reasons\n> you\'re using it would have gotten you aligned pretty quickly with how\n> everyone else is doing this ... OR, and argument could have been made as\n> to why all of that was a terrible idea and that the whole project should\n> move to celery.\n> \n> It\'s not that oslo-incubator was unknown - you\'re using other things.\n> \n> When we look at incubating things, part of it is about the tech, but\n> part of it is the question about whether or not the project is going to\n> add to the whole\'s ability to be greater than the sum of its parts, of\n> if we\'re going to inherit another group of folks who will be balkanized\n> in the corner somewhere.\n> \n> I don\'t want to sound punitive, that\'s not my intent - and I want you\n> guys to succeed and to be a part of things. I just want to be careful\n> that we don\'t add more complexity and confusion into an already\n> difficult to fully digest landscape. I want to make sure that when we\n> release an integrated release of OpenStack that it\'s an actual\n> integrated stack that works together, and I want to make sure that we\n> have an integrated developer community.\n> \n> SO - without drawing a hard line in the sand or anything, I think that a\n> discussion of what the real concrete plans are around alignment with the\n> messaging strata in OpenStack is will probably be one of the more\n> important questions we look at.\n\nI agree that this is concerning. And that what\'s concerning isn\'t so\nmuch that the project did something different, but rather that choice\nwas apparently made because the project thought it was perfectly fine\nfor them to ignore what other OpenStack projects do and go off and do\nits own thing.\n\nWe can\'t make this growth in the number of OpenStack projects work if\neach project goes off randomly and does its own thing without any\nconcern for the difficulties that creates.\n\nMark.\n\n\n\n','<529D0ACC.50106@inaugust.com>',NULL),('<1386284436.1375.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 23:00:36',0,'2013-12-05 23:00:36',NULL,'[openstack-dev] [openstack-tc] Incubation Request for Barbican','On Tue, 2013-12-03 at 16:43 +0000, Jarret Raim wrote:\n> > The API and developer documentation is at\n> >http://docs.openstack.org/developer/oslo.messaging/\n> \n> This is great, thanks for the link. Would there be any objections to\n> adding this to the github repo and the openstack wiki pages? I spent a\n> bunch of time looking and wasn?t able to turn this up.\n> \n> \n> Additionally, where is this documentation generated from? I looked at the\n> doc/ dir in the repo [1] and most of the files in there were empty.\n> \n> \n> [1] https://github.com/openstack/oslo.messaging/tree/master/doc/source\n\nIt\'s generated from inline docstrings in the code.\n\nMark.\n\n\n\n','<CEC365DA.83EC1%jarret.raim@rackspace.com>',NULL),('<1386287616.1375.107.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 23:53:36',0,'2013-12-05 23:53:36',NULL,'[openstack-dev] [openstack-tc] Incubation Request for Barbican','On Thu, 2013-12-05 at 23:37 +0000, Douglas Mendizabal wrote:\n> >\n> >I agree that this is concerning. And that what\'s concerning isn\'t so\n> >much that the project did something different, but rather that choice\n> >was apparently made because the project thought it was perfectly fine\n> >for them to ignore what other OpenStack projects do and go off and do\n> >its own thing.\n> >\n> >We can\'t make this growth in the number of OpenStack projects work if\n> >each project goes off randomly and does its own thing without any\n> >concern for the difficulties that creates.\n> >\n> >Mark.\n> \n> Hi Mark,\n> \n> You may have missed it, but barbican has added a blueprint to change our\n> queue to use oslo.messaging [1]\n> \n> I just wanted to clarify that we didn?t choose Celery because we thought\n> that ?it was perfectly fine to ignore what other OpenStack projects do?.\n> Incubation has been one of our goals since the project began.  If you?ve\n> taken the time to look at our code, you?ve seen that we have been using\n> oslo.config this whole time.  We chose Celery because it was\n> \n> a) Properly packaged like any other python library, so we could just\n> pip-install it.\n> b) Well documented\n> c) Well tested in production environments\n> \n> At the time none of those were true for oslo.messaging.  In fact,\n> oslo.messgaging still cannot be pip-installed as of today.  Obviously, had\n> we know that using oslo.messaging is hard requirement in advance, we would\n> have chosen it despite its poor distribution story.\n\nI do sympathise, but it\'s also true is that all other projects were\nusing the oslo-incubator RPC code at the time you chose Celery.\n\nI think all the verbiage in this thread about celery is just to\nreinforce that we need to be very sure that new projects feel a\nresponsibility to fit closely in with the rest of OpenStack. It\'s not\nabout technical requirements so much as social responsibility.\n\nBut look - I think you\'ve reacted well to the concern and hopefully if\nit feels like there was an overreaction that you can understand the\nbroader thing we\'re trying to get at here.\n\nThanks,\nMark.\n\n\n\n','<CEC66722.A597%douglas.mendizabal@rackspace.com>',NULL),('<1386287616.1375.107.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-12-05 23:53:36',0,'2013-12-05 23:53:36',NULL,'[openstack-tc] [openstack-dev] Incubation Request for Barbican','On Thu, 2013-12-05 at 23:37 +0000, Douglas Mendizabal wrote:\n> >\n> >I agree that this is concerning. And that what\'s concerning isn\'t so\n> >much that the project did something different, but rather that choice\n> >was apparently made because the project thought it was perfectly fine\n> >for them to ignore what other OpenStack projects do and go off and do\n> >its own thing.\n> >\n> >We can\'t make this growth in the number of OpenStack projects work if\n> >each project goes off randomly and does its own thing without any\n> >concern for the difficulties that creates.\n> >\n> >Mark.\n> \n> Hi Mark,\n> \n> You may have missed it, but barbican has added a blueprint to change our\n> queue to use oslo.messaging [1]\n> \n> I just wanted to clarify that we didn?t choose Celery because we thought\n> that ?it was perfectly fine to ignore what other OpenStack projects do?.\n> Incubation has been one of our goals since the project began.  If you?ve\n> taken the time to look at our code, you?ve seen that we have been using\n> oslo.config this whole time.  We chose Celery because it was\n> \n> a) Properly packaged like any other python library, so we could just\n> pip-install it.\n> b) Well documented\n> c) Well tested in production environments\n> \n> At the time none of those were true for oslo.messaging.  In fact,\n> oslo.messgaging still cannot be pip-installed as of today.  Obviously, had\n> we know that using oslo.messaging is hard requirement in advance, we would\n> have chosen it despite its poor distribution story.\n\nI do sympathise, but it\'s also true is that all other projects were\nusing the oslo-incubator RPC code at the time you chose Celery.\n\nI think all the verbiage in this thread about celery is just to\nreinforce that we need to be very sure that new projects feel a\nresponsibility to fit closely in with the rest of OpenStack. It\'s not\nabout technical requirements so much as social responsibility.\n\nBut look - I think you\'ve reacted well to the concern and hopefully if\nit feels like there was an overreaction that you can understand the\nbroader thing we\'re trying to get at here.\n\nThanks,\nMark.\n\n\n\n','<CEC66722.A597%douglas.mendizabal@rackspace.com>',NULL),('<1386335994.1375.135.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 13:19:54',0,'2013-12-06 13:19:54',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','Hi Julien,\n\nOn Mon, 2013-12-02 at 16:45 +0100, Julien Danjou wrote:\n> On Mon, Nov 18 2013, Julien Danjou wrote:\n> \n> >   https://blueprints.launchpad.net/oslo/+spec/messaging-decouple-cfg\n> \n> So I\'ve gone through the code and started to write a plan on how I\'d do\n> things:\n> \n>   https://wiki.openstack.org/wiki/Oslo/blueprints/messaging-decouple-cfg\n> \n> I don\'t think I missed too much, though I didn\'t run into all tiny\n> details.\n> \n> Please feel free to tell me if I miss anything obvious, otherwise I\'ll\n> try to start submitting patches, one at a time, to get this into shape\n> step by step.\n\nThanks for writing this up, I really appreciate it.\n\nI would like to spend more time getting to the bottom of what we\'re\ntrying to solve here.\n\nIf the goal is \"allow applications to use oslo.messaging without using\noslo.config\", then what\'s driving this? I\'m guessing some possible\nanswers:\n\n  1) I don\'t want to use a global CONF object\n\n     This is a strawman - I think we all realize the conf object you \n     pass to oslo.messaging doesn\'t have to be cfg.CONF. Just putting \n     it here to make sure no-one\'s confused about that.\n\n  2) I don\'t want to have configuration files or command line options in\n     order to use oslo.messaging\n\n     But, even now, you don\'t actually have to parse the command line or\n     any config files. See e.g. https://gist.github.com/markmc/7823230\n\n  3) Ok, but I want to be able to specify values for things like \n     rpc_conn_pool_size without using any config files.\n\n     We\'ve talked about allowing the use of query parameters for stuff \n     like this, but I don\'t love that. I think I\'d restrict query \n     parameters to those options which are fundamental to how you \n     connect to a given transport.\n\n     We could quite easily provide any API which would allow \n     constructing a ConfigOpts object with a bunch of options set and \n     without anyone having to use config files. Here\'s a PoC of how\n     that might look:\n\n       https://gist.github.com/markmc/7823420\n\n     (Now, if your reaction is \"OMG, you\'re using temporary config\n     files on disk, that\'s awful\" then just bear with me an ignore the \n     implementation details of get_config_from_dict(). We could very \n     easily make oslo.config support a mode like this without needing\n     to ever write anything to disk)\n\n     The point of this example is that we could add an oslo.messaging\n     API which takes a dict of config values and you never even know\n     that oslo.config is involved.\n\n  4) But I want the API to be explicit about what config options are \n     supported by the API\n\n     This could be something useful to discuss, because right now the \n     API hides configuration options rather than encoding them into the \n     API. This is to give us a bit more flexibility about changing \n     these over time (e.g. keeping backwards compat for old options for \n     a short time than other aspects of the API).\n\n     But actually, I\'m assuming this isn\'t what you\'re thinking since \n     your patch adds an free-form executor_kwargs dict.\n\n  5) But I want to avoid any dependency on oslo.config\n\n     This could be fundamentally what we\'re talking about here, but I \n     struggle to understand it - oslo.config is pretty tiny and it only \n     requires argparse, so if it\'s just an implementation detail that \n     you don\'t even notice if you\'re not using config files then what \n     exactly is the problem?\n\n\nBasically, my thinking is that something like this example:\n\n  https://gist.github.com/markmc/7823420\n\nwhere you can use oslo.messaging with just a dict of config values\n(rather than having to parse config files) should handle any reasonable\nconcern that I\'ve understood so far ... without having to change much at\nall.\n\nMark.\n\n\n\n','<87bo0zgstu.fsf@dex.adm.naquadah.org>',NULL),('<1386342332.1375.146.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 15:05:32',0,'2013-12-06 15:05:32',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','On Fri, 2013-12-06 at 15:41 +0100, Julien Danjou wrote:\n> On Fri, Dec 06 2013, Mark McLoughlin wrote:\n> \n> Hi Mark,\n> \n> > If the goal is \"allow applications to use oslo.messaging without using\n> > oslo.config\", then what\'s driving this? I\'m guessing some possible\n> > answers:\n> >\n> >   5) But I want to avoid any dependency on oslo.config\n> \n> I think that\'s the more important one to me.\n> \n> >      This could be fundamentally what we\'re talking about here, but I \n> >      struggle to understand it - oslo.config is pretty tiny and it only \n> >      requires argparse, so if it\'s just an implementation detail that \n> >      you don\'t even notice if you\'re not using config files then what \n> >      exactly is the problem?\n> \n> > Basically, my thinking is that something like this example:\n> >\n> >   https://gist.github.com/markmc/7823420\n> >\n> > where you can use oslo.messaging with just a dict of config values\n> > (rather than having to parse config files) should handle any reasonable\n> > concern that I\'ve understood so far ... without having to change much at\n> > all.\n> \n> I definitely agree with your arguments. There\'s a large number of\n> technical solutions that can be used to bypass the usage of oslo.config\n> and make it work with whatever you\'re using..\n> \n> I just can\'t stop thinking that a library shouldn\'t impose any use of a\n> configuration library. I can pick any library on PyPI, and, fortunately,\n> most of them don\'t come with a dependency on the favorite configuration\n> library of their author or related project, and its usage spread all\n> over the code base.\n> \n> While I do respect the fact that this is a library to be consumed mainly\n> in OpenStack (and I don\'t want to break that), I think we\'re also trying\n> to not be the new Zope and contribute in a sane way to the Python\n> ecosystem. And I think oslo.messaging doesn\'t do that right.\n> \n> Now if the consensus is to leave it that way, I honestly won\'t fight it\n> over and over. As Mark proved, there\'s a lot of way to circumvent the\n> oslo.config usage anyway.\n\nOk, let\'s say oslo.messaging didn\'t use oslo.config at all and just took\na free-form dict of configuration values. Then you\'d have this\nseparation whereby you can write code to retrieve those values from any\nnumber of possible configuration sources and pass them down to\noslo.messaging. I think that\'s what you\'re getting at?\n\nHowever, what you lose with that is a consistent way of defining a\nschema for those configuration options in oslo.messaging. Should a given\noption be an int, bool or a list? What should it\'s default be? etc. etc.\nThat stuff would live in the integration layer that maps from\noslo.config to a dict, even though it\'s totally useful when you just\nsupply a dict.\n\nI guess there\'s two sides to oslo.config - the option schemas and the\ncode to retrieve values from various sources (command line, config files\nor overrides/defaults). I think the option schemas is a useful\nimplementation detail in oslo.messaging, even if the values don\'t come\nfrom the usual oslo.config sources.\n\nMark.\n\n\n\n','<874n6mjb3n.fsf@dex.adm.naquadah.org>',NULL),('<1386349654-sup-6659@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 09:26:25',-28800,'2013-12-06 17:26:25',NULL,'[openstack-dev] [Tripleo] Core reviewer update Dec','Excerpts from Robert Collins\'s message of 2013-12-03 23:12:39 -0800:\n> Hi,\n>     like most OpenStack projects we need to keep the core team up to\n> date: folk who are not regularly reviewing will lose context over\n> time, and new folk who have been reviewing regularly should be trusted\n> with -core responsibilities.\n> \n> In this months review:\n>  - Ghe Rivero for -core\n\n+1, We\'ve been getting good reviews from Ghe for a while now. :)\n\n>  - Jan Provaznik for removal from -core\n>  - Jordan O\'Mara for removal from -core\n>  - Martyn Taylor for removal from -core\n>  - Jiri Tomasek for removal from -core\n>  - Jamomir Coufal for removal from -core\n\nI suggest we delay this removal for 30 days. I know it is easy to add\nthem back in, but I hesitate to disrupt the flow if these people all\nare willing to pick up the pace again. They may not have _immediate_\ncode knowledge but they should have enough historical knowledge that\nhas not gone completely stale in just the last 30-60 days.\n\nWhat I\'m suggesting is that review velocity will benefit from core being\na little more sticky, especially for sustained contributors who have\njust had their attention directed elsewhere briefly.\n\n\n','<CAJ3HoZ1Ye-UspWsOcc3F30A=gdZxk0nWy4KuYqAp3Lnh01=9iw@mail.gmail.com>',NULL),('<1386349879.2907.8.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-06 11:11:19',-21600,'2013-12-06 17:11:19',NULL,'[Openstack] Real-world policy.json and keystone settings','\nOn Thu, 2013-12-05 at 19:03 -0600, Scott Devoid wrote:\n> The TL;DR - We ran into problems with permissions for users within the\n> same tenant. With the current access controls it is impossible to fix\n> this without isolating each user in a personal project. Can we fix the\n> policy.json grammar to give us the access controls we want, or am I\n> stupid and missing something?\n\nI believe there is support for getting the functionality you want.  For\nany of the objects that have a user_id, you can use the policy rule\n\"user_id:%(user_id)s\", which will only be true if the user_id in the\ncontext is the same as the user_id on the object access is being checked\nagainst.  You might want to try that rule and see if it gives you what\nyou want?\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAJrQjSs-11FVCV8LWx2Ytdj+7ewnTvc5vovMzKQFyt-5CiEdVg@mail.gmail.com>',NULL),('<1386350124.1375.157.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 17:15:24',0,'2013-12-06 17:15:24',NULL,'[openstack-dev] [Oslo] Layering olso.messaging usage of config','On Fri, 2013-12-06 at 16:55 +0000, Joshua Harlow wrote:\n> I really have to agree with this. It\'s especially important if\n> oslo.messaging is also used in libraries like taskflow. If\n> oslo.messaging imposes that users of it must use oslo.config then by\n> using it in taskflow, taskflow then imposes the same oslo.config\n> usage.\n\nYou know, I think you either didn\'t read my (carefully considered) email\nor didn\'t take the time to understand it. That\'s incredibly frustrating.\n\nMy proposal would mean that oslo.messaging could be used like this:\n\n  from oslo import messaging\n\n  conf = messaging.get_config_from_dict(dict(rpc_conn_pool_size=100))\n \n  transport = messaging.get_transport(conf, \'qpid:///test\')\n \n  server = Server(transport)\n  server.start()\n  server.wait()\n\noslo.config is nothing but an implementation detail if you used\noslo.messaging in this way.\n\n(Julien had a more subtle concern about this which I can actually relate\nmore to)\n\n> This makes all libraries that use it inherently only useable in the\n> openstack ecosystem which I think is very bad opensource behavior (not\n> exactly open).\n\n\"bad open-source behaviour\"? Seriously?\n\nYeah, like gtk+ is only usable in the GNOME ecosystem because it uses\nglib and gtk+ authors are bad open-source people because they didn\'t\nallow an alternative to glib to be used. Bizarre statement, frankly.\n\n>  There are other reasons to, a configuration dict means u can have\n> many different active instances being simultaneously used (each with\n> its own config), with oslo.config since it is a static configuration\n> object u get 1 simultaneous instance. So this is yet another behavior\n> that I as a library provider thing is very unhealthy restriction to\n> impose on people that use taskflow.\n\n\"1 simultaneous instance\" ... you mean the cfg.CONF object?\n\nThere\'s no requirement to use that and I explained that in my email\ntoo ... even though I actually thought it should need no explaining at\nthis point.\n\nMark.\n\n\n\n','<60284262-8A38-4E7A-8DD2-F62BBDBE4E18@yahoo-inc.com>',NULL),('<1386352600-sup-8232@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 10:27:48',-28800,'2013-12-06 18:27:48',NULL,'[openstack-dev] [olso] [cinder] upgrade issues in lock_path in\n	cinder after oslo utils sync (was: creating a default for\n	oslo config variables within a project?)','Excerpts from Sean Dague\'s message of 2013-12-06 09:47:03 -0800:\n> So it still seems that we are at an impasse here on getting new olso\n> lockutils into cinder because it doesn\'t come with a working default.\n> \n> As a recap - https://review.openstack.org/#/c/48935/ (that sync)\n> \n> is blocked by failing upgrade testing, because lock_path has no default,\n> so it has to land config changes simultaneously on the commit otherwise\n> explode cinder on startup (as not setting that variable explodes as a\n> fatal error). I consider that an upgrade blocker, and am not comfortable\n> with the work around - https://review.openstack.org/#/c/52070/3\n> \n> I\'ve proposed an oslo patch that would give us a default plus an ERROR\n> log message if you used it - https://review.openstack.org/#/c/60274/\n> \n> The primary concern here is that it opens up a local DOS attack because\n> it\'s a well known directory. This is a valid concern. My feeling is you\n> are lost anyway if you have malicious users on your system, and if we\'ve\n> narrowed them down to only DOSing (which there other ways they could do\n> that), I think we\'ve narrowed the surface enough to make this acceptable\n> at the ERROR log level. However there are objections, so at this point\n> it seems like we needed to summarize the state of the world, get this\n> back onto the list with a more descriptive subject, and see who else\n> wants to weigh in.\n> \n\nSean I respect that pragmatism has to win out over paranoia at some\npoint, and this may very well be that point, so I\'m happy to step back\nfrom the issue if others feel like we\'re there.\n\nHowever, I think it is every program\'s duty to protect itself. Otherwise\nthose programs will be the weak links in the chains that lead to expanded\ncompromise. There are plenty of examples where just the ability to\nDOS one piece leads to things like being able to then expose further\nrace conditions. \"Defense in depth\" is something we should always be\nsupporting.\n\nHow do we handle python requirements changes? At the same point where we\npip install -U -r requirements.txt, we can also update the config file,\ncan we not? Or we can at least create /var/run/cinder and make sure it\nis owned by cinder and has the appropriate permissions. Could we make\nthat the default? That would eliminate the threat, and be a reasonably\neasy thing for users to make sure is in place well in advance of upgrades.\n\nAs I\'ve mentioned in the reviews, we have \'fail open\' or \'fail\nclosed\'. Security wants us to fail closed every time. But sometimes that\nmeans trading in too much convenience. I suggest that it is worth it in\nthis case, but I am just one person.\n\n\n','<52A20D97.7010303@dague.net>',NULL),('<1386354732-sup-6753@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 10:38:00',-28800,'2013-12-06 18:38:00',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Jay Pipes\'s message of 2013-12-05 21:32:54 -0800:\n> On 12/05/2013 04:25 PM, Clint Byrum wrote:\n> > Excerpts from Andrew Plunk\'s message of 2013-12-05 12:42:49 -0800:\n> >>> Excerpts from Randall Burt\'s message of 2013-12-05 09:05:44 -0800:\n> >>>> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com>\n> >>>>   wrote:\n> >>>>\n> >>>>> Excerpts from Monty Taylor\'s message of 2013-12-04 17:54:45 -0800:\n> >>>>>> Why not just use glance?\n> >>>>>>\n> >>>>>\n> >>>>> I\'ve asked that question a few times, and I think I can collate the\n> >>>>> responses I\'ve received below. I think enhancing glance to do these\n> >>>>> things is on the table:\n> >>>>>\n> >>>>> 1. Glance is for big blobs of data not tiny templates.\n> >>>>> 2. Versioning of a single resource is desired.\n> >>>>> 3. Tagging/classifying/listing/sorting\n> >>>>> 4. Glance is designed to expose the uploaded blobs to nova, not users\n> >>>>>\n> >>>>> My responses:\n> >>>>>\n> >>>>> 1: Irrelevant. Smaller things will fit in it just fine.\n> >>>>\n> >>>> Fitting is one thing, optimizations around particular assumptions about the size of data and the frequency of reads/writes might be an issue, but I admit to ignorance about those details in Glance.\n> >>>>\n> >>>\n> >>> Optimizations can be improved for various use cases. The design, however,\n> >>> has no assumptions that I know about that would invalidate storing blobs\n> >>> of yaml/json vs. blobs of kernel/qcow2/raw image.\n> >>\n> >> I think we are getting out into the weeds a little bit here. It is important to think about these apis in terms of what they actually do, before the decision of combining them or not can be made.\n> >>\n> >> I think of HeatR as a template storage service, it provides extra data and operations on templates. HeatR should not care about how those templates are stored.\n> >> Glance is an image storage service, it provides extra data and operations on images (not blobs), and it happens to use swift as a backend.\n> >>\n> >> If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field \"minRam\" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it\'s own service, or becomes part of Heat.\n> >>\n> >\n> > I spoke at length via G+ with Randall and Tim about this earlier today.\n> > I think I understand the impetus for all of this a little better now.\n> >\n> > Basically what I\'m suggesting is that Glance is only narrow in scope\n> > because that was the only object that OpenStack needed a catalog for\n> > before now.\n> >\n> > However, the overlap between a catalog of images and a catalog of\n> > templates is quite comprehensive. The individual fields that matter to\n> > images are different than the ones that matter to templates, but that\n> > is a really minor detail isn\'t it?\n> >\n> > I would suggest that Glance be slightly expanded in scope to be an\n> > object catalog. Each object type can have its own set of fields that\n> > matter to it.\n> >\n> > This doesn\'t have to be a minor change to glance to still have many\n> > advantages over writing something from scratch and asking people to\n> > deploy another service that is 99% the same as Glance.\n> \n> My suggestion for long-term architecture would be to use Murano for \n> catalog/metadata information (for images/templates/whatever) and move \n> the block-streaming drivers into Cinder, and get rid of the Glance \n> project entirely. Murano would then become the catalog/registry of \n> objects in the OpenStack world, Cinder would be the thing that manages \n> and streams blocks of data or block devices, and Glance could go away. \n> Imagine it... OpenStack actually *reducing* the number of projects \n> instead of expanding! :)\n> \n\nHave we not learned our lesson with Nova-Net/Neutron yet? Rewrites of\nexisting functionality are painful.\n\nThe Murano-concerned people have already stated they are starting over\non that catalog.\n\nI suggest they start over by expanding Glance\'s catalog. If the block\nstreaming bits of Glance need to move somewhere else, that sounds like a\ncompletely separate concern that distracts from this point.\n\nAnd to be clear, (I think I will just stop talking as I think I\'ve\nmade this point), my point is, we have a catalog, let\'s make it better.\n\n\n','<52A16186.1070009@gmail.com>',NULL),('<1386358497-sup-7008@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 11:36:27',-28800,'2013-12-06 19:36:27',NULL,'[openstack-dev] [TripleO] capturing build details in images','Excerpts from Robert Collins\'s message of 2013-12-04 14:19:44 -0800:\n> So - what about us capturing this information outside the image: we\n> can create a uuid for the build, and write a file in the image with\n> that uuid, and outside the image we can write:\n>  - all variables (no security ramifications now as this file can be\n> kept by whomever built the image)\n>  - command line args\n>  - version information for the toolchain etc.\n\nI forgot to weigh in on this. It has all been said already. I like the\nidea of this being a json file as well. +1.\n\n\n','<CAJ3HoZ1_d2yDjMb0DzAG-1NR_HMtjp5k_s7iAaBJLB1UwVeXXQ@mail.gmail.com>',NULL),('<1386359693-sup-7703@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 11:56:52',-28800,'2013-12-06 19:56:52',NULL,'[openstack-dev] [TripleO][Tuskar] Questions around Development\n	Process','Excerpts from Tzu-Mainn Chen\'s message of 2013-12-06 07:37:20 -0800:\n> Hey all,\n> \n> We\'re starting to work on the UI for tuskar based on Jarda\'s wireframes, and as we\'re doing so, we\'re realizing that\n> we\'re not quite sure what development methodology is appropriate.  Some questions:\n> \n> a) Because we\'re essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar\n> will simply disappear), it\'s difficult to do small incremental patches that support existing functionality.  Is it okay\n> to have patches that break functionality?  Are there good alternatives?\n> \n\nI think Tuskar is early enough in its\' life cycle that it has reached\nthat magical \"plan to throw one away\" point where you can actually do\nthis without disrupting anybody except yourselves, which actually sounds\nvaluable in this case since you have chosen a different course.\n\n\n','<1396895506.3163964.1386344240975.JavaMail.root@redhat.com>',NULL),('<1386368736-sup-1409@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 14:30:55',-28800,'2013-12-06 22:30:55',NULL,'[openstack-dev] [olso] [cinder] upgrade issues in lock_path in\n	cinder after oslo utils sync (was: creating a default for\n	oslo config variables within a project?)','Excerpts from Ben Nemec\'s message of 2013-12-06 13:38:16 -0800:\n>  \n> \n> On 2013-12-06 15:14, Yuriy Taraday wrote: \n> \n> > Hello, Sean. \n> > \n> > I get the issue with upgrade path. User doesn\'t want to update config unless one is forced to do so. \n> > But introducing code that weakens security and let it stay is an unconditionally bad idea. \n> > It looks like we have to weigh two evils: having troubles upgrading and lessening security. That\'s obvious. \n> > \n> > Here are my thoughts on what we can do with it: \n> > 1. I think we should definitely force user to do appropriate configuration to let us use secure ways to do locking. \n> > 2. We can wait one release to do so, e.g. issue a deprecation warning now and force user to do it the right way later. \n> > 3. If we are going to do 2. we should do it in the service that is affected not in the library because library shouldn\'t track releases of an application that uses it. It should do its thing and do it right (secure). \n> > \n> > So I would suggest to deal with it in Cinder by importing \'lock_path\' option after parsing configs and issuing a deprecation warning and setting it to tempfile.gettempdir() if it is still None.\n> \n> This is what Sean\'s change is doing, but setting lock_path to\n> tempfile.gettempdir() is the security concern. \n\nYuriy\'s suggestion is that we should let Cinder override the config\nvariable\'s default with something insecure. Basically only deprecate\nit in Cinder\'s world, not oslo\'s. That makes more sense from a library\nstandpoint as it keeps the library\'s expected interface stable.\n\n> \n> Since there seems to be plenty of resistance to using /tmp by default,\n> here is my proposal: \n> \n> 1) We make Sean\'s change to open files in append mode. I think we can\n> all agree this is a good thing regardless of any config changes. \n> \n> 2) Leave lockutils broken in Icehouse if lock_path is not set, as I\n> believe Mark suggested earlier. Log an error if we find that\n> configuration. Users will be no worse off than they are today, and if\n> they\'re paying attention they can get the fixed lockutils behavior\n> immediately. \n\nBroken how? Broken in that it raises an exception, or broken in that it\ncarries a security risk?\n\n\n','<5152e12f3a4834628f8cbfc6e719a510@localhost>',NULL),('<1386370818-sup-2020@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 15:04:13',-28800,'2013-12-06 23:04:13',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Randall Burt\'s message of 2013-12-06 14:43:05 -0800:\n> I too have warmed to this idea but wonder about the actual implementation around it. While I like where Edmund is going with this, I wonder if it wouldn\'t be valuable in the short-to-mid-term (I/J) to just add /templates to Glance (/assemblies, /applications, etc) along side /images.  Initially, we could have separate endpoints and data structures for these different asset types, refactoring the easy bits along the way and leveraging the existing data storage and caching bits, but leaving more disruptive changes alone. That can get the functionality going, prove some concepts, and allow all of the interested parties to better plan a more general v3 api.\n> \n\n+1 on bolting the different views for things on as new v2 pieces instead\nof trying to solve the API genericism immediately.\n\nI would strive to make this a facade, and start immediately on making\nGlance more generic under the hood.  Otherwise these will just end up\nas silos inside Glance instead of silos inside OpenStack.\n\n\n','<374942C5-1A25-48DC-9E06-6DAA772C1EE4@rackspace.com>',NULL),('<1386381249-sup-6719@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 17:55:14',-28800,'2013-12-07 01:55:14',NULL,'[openstack-dev] [heat] [glance] Heater Proposal','Excerpts from Jay Pipes\'s message of 2013-12-06 16:46:24 -0800:\n> On 12/06/2013 01:38 PM, Clint Byrum wrote:\n> > Excerpts from Jay Pipes\'s message of 2013-12-05 21:32:54 -0800:\n> >> On 12/05/2013 04:25 PM, Clint Byrum wrote:\n> >>> Excerpts from Andrew Plunk\'s message of 2013-12-05 12:42:49\n> >>> -0800:\n> >>>>> Excerpts from Randall Burt\'s message of 2013-12-05 09:05:44\n> >>>>> -0800:\n> >>>>>> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at\n> >>>>>> fewbar.com> wrote:\n> >>>>>>\n> >>>>>>> Excerpts from Monty Taylor\'s message of 2013-12-04\n> >>>>>>> 17:54:45 -0800:\n> >>>>>>>> Why not just use glance?\n> >>>>>>>>\n> >>>>>>>\n> >>>>>>> I\'ve asked that question a few times, and I think I can\n> >>>>>>> collate the responses I\'ve received below. I think\n> >>>>>>> enhancing glance to do these things is on the table:\n> >>>>>>>\n> >>>>>>> 1. Glance is for big blobs of data not tiny templates. 2.\n> >>>>>>> Versioning of a single resource is desired. 3.\n> >>>>>>> Tagging/classifying/listing/sorting 4. Glance is designed\n> >>>>>>> to expose the uploaded blobs to nova, not users\n> >>>>>>>\n> >>>>>>> My responses:\n> >>>>>>>\n> >>>>>>> 1: Irrelevant. Smaller things will fit in it just fine.\n> >>>>>>\n> >>>>>> Fitting is one thing, optimizations around particular\n> >>>>>> assumptions about the size of data and the frequency of\n> >>>>>> reads/writes might be an issue, but I admit to ignorance\n> >>>>>> about those details in Glance.\n> >>>>>>\n> >>>>>\n> >>>>> Optimizations can be improved for various use cases. The\n> >>>>> design, however, has no assumptions that I know about that\n> >>>>> would invalidate storing blobs of yaml/json vs. blobs of\n> >>>>> kernel/qcow2/raw image.\n> >>>>\n> >>>> I think we are getting out into the weeds a little bit here. It\n> >>>> is important to think about these apis in terms of what they\n> >>>> actually do, before the decision of combining them or not can\n> >>>> be made.\n> >>>>\n> >>>> I think of HeatR as a template storage service, it provides\n> >>>> extra data and operations on templates. HeatR should not care\n> >>>> about how those templates are stored. Glance is an image\n> >>>> storage service, it provides extra data and operations on\n> >>>> images (not blobs), and it happens to use swift as a backend.\n> >>>>\n> >>>> If HeatR and Glance were combined, it would result in taking\n> >>>> two very different types of data (template metadata vs image\n> >>>> metadata) and mashing them into one service. How would adding\n> >>>> the complexity of HeatR benefit Glance, when they are dealing\n> >>>> with conceptually two very different types of data? For\n> >>>> instance, should a template ever care about the field \"minRam\"\n> >>>> that is stored with an image? Combining them adds a huge\n> >>>> development complexity with a very small operations payoff, and\n> >>>> so Openstack is already so operationally complex that HeatR as\n> >>>> a separate service would be knowledgeable. Only clients of Heat\n> >>>> will ever care about data and operations on templates, so I\n> >>>> move that HeatR becomes it\'s own service, or becomes part of\n> >>>> Heat.\n> >>>>\n> >>>\n> >>> I spoke at length via G+ with Randall and Tim about this earlier\n> >>> today. I think I understand the impetus for all of this a little\n> >>> better now.\n> >>>\n> >>> Basically what I\'m suggesting is that Glance is only narrow in\n> >>> scope because that was the only object that OpenStack needed a\n> >>> catalog for before now.\n> >>>\n> >>> However, the overlap between a catalog of images and a catalog\n> >>> of templates is quite comprehensive. The individual fields that\n> >>> matter to images are different than the ones that matter to\n> >>> templates, but that is a really minor detail isn\'t it?\n> >>>\n> >>> I would suggest that Glance be slightly expanded in scope to be\n> >>> an object catalog. Each object type can have its own set of\n> >>> fields that matter to it.\n> >>>\n> >>> This doesn\'t have to be a minor change to glance to still have\n> >>> many advantages over writing something from scratch and asking\n> >>> people to deploy another service that is 99% the same as Glance.\n> >>\n> >> My suggestion for long-term architecture would be to use Murano\n> >> for catalog/metadata information (for images/templates/whatever)\n> >> and move the block-streaming drivers into Cinder, and get rid of\n> >> the Glance project entirely. Murano would then become the\n> >> catalog/registry of objects in the OpenStack world, Cinder would be\n> >> the thing that manages and streams blocks of data or block devices,\n> >> and Glance could go away. Imagine it... OpenStack actually\n> >> *reducing* the number of projects instead of expanding! :)\n> >\n> > Have we not learned our lesson with Nova-Net/Neutron yet? Rewrites\n> > of existing functionality are painful.\n> \n> I said *long-term* above, Clint.\n> \n> > The Murano-concerned people have already stated they are starting\n> > over on that catalog.\n> >\n> > I suggest they start over by expanding Glance\'s catalog. If the\n> > block streaming bits of Glance need to move somewhere else, that\n> > sounds like a completely separate concern that distracts from this\n> > point.\n> \n> Yes, the block streaming bits of Glance are separate -- sorry for\n> distracting from your point. However, Glance\'s architecture actually\n> went from having the registry and streaming pieces separated to having\n> the two pieces more closely interwoven in the last two release cycles.\n> It\'s harder now, IMO, to separate out the \"registry\" aspects of Glance \n> from the block management pieces. Which is why I suggested using Murano \n> as the catalog since there is already a separate catalog sub-project in \n> Murano and the Murano devs are familiar with this space.\n> \n> Please try not to shoot the messenger here -- I\'m only bringing up my \n> thoughts on where the various related projects seem to be moving.\n> \n> > And to be clear, (I think I will just stop talking as I think I\'ve\n> > made this point), my point is, we have a catalog, let\'s make it\n> > better.\n> \n> Well, we have multiple catalogs... which one shall we make better? \n> Sounds like contributors are coalescing around using Glance as the \n> catalog -- which is fine I suppose -- but I think it would have been \n> easier to use the old Glance Registry server (which now does not exist) \n> as this catalog service, than the newer Glance API, which has gotten \n> sidetracked with things like image tasks (which IMO should never have \n> been added to the Images API; the taskflow or Mistral projects should \n> have handled this functionality).\n> \n> Anyway, just figured I\'d offer some commentary. Sorry if you think I was \n> causing trouble.\n> \n\nYour commentary is much appreciated, and I apologize for shooting you,\nMr. Messenger. It really is your fault for being such an easy target! ;)\n\n\n','<52A26FE0.9070702@gmail.com>',NULL),('<1386400804-sup-9334@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 23:33:52',-28800,'2013-12-07 07:33:52',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Joshua Harlow\'s message of 2013-12-06 12:27:10 -0800:\n> Another idea that I\'ll put up for consideration (since I work with the\n> cloud-init codebase also).\n> \n> Cloud-init[1] which currently does lots of little useful initialization\n> types of activities (similar to the racker agents activities) has been\n> going through some of the same questions[2] as to should it be an agent\n> (or respond to some type of system signal on certain activities, like new\n> network metadata available). So this could be another way to go.\n> \n> Including (ccing) scott who probably has more ideas around this to :-)\n> \n> [1] https://launchpad.net/cloud-init\n> [2] https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1153626\n> \n\nI have a theory that cloud-init is so popular and useful precisely\nbecuase it does _not_ expand into ongoing-management territory. It is\nreally amazing at \"setting the table\" for instances when you choose\nnot to do image based software deployment. Even if you do image based\ndeployment, it is really great for abstracting away all the cloud details\nand customizing an instance.\n\nThe problem with conflating those two tasks is that early boot\nconfiguration carries quite a different set of constraints and assumptions\nwhen compared to what an agent will be tasked with.\n\nI would be interested in seeing the cloud-config piece pulled out into\nits own library. That syntax is pretty popular, and in fact was mostly\nmimicked by the cloudformation tool \'cfn-init\'. I suspect that they did\nnot just do this work in cloud-init because it is GPLv3, or because of the\nCanonical CLA.. two things that scare off IP-hungry companies like Amazon.\n\n\n','<CEC771D5.4F4D3%harlowja@yahoo-inc.com>',NULL),('<1386401971-sup-7348@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 23:44:25',-28800,'2013-12-07 07:44:25',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Sandy Walsh\'s message of 2013-12-06 12:12:16 -0800:\n> \n> On 12/06/2013 03:45 PM, Dmitry Mescheryakov wrote:\n> > Hello all,\n> > \n> > We would like to push further the discussion on unified guest agent. You\n> > may find the details of our proposal at [1].\n> > \n> > Also let me clarify why we started this conversation. Savanna currently\n> > utilizes SSH to install/configure Hadoop on VMs. We were happy with that\n> > approach until recently we realized that in many OpenStack deployments\n> > VMs are not accessible from controller. That brought us to idea to use\n> > guest agent for VM configuration instead. That approach is already used\n> > by Trove, Murano and Heat and we can do the same.\n> > \n> > Uniting the efforts on a single guest agent brings a couple advantages:\n> > 1. Code reuse across several projects.\n> > 2. Simplified deployment of OpenStack. Guest agent requires additional\n> > facilities for transport like message queue or something similar.\n> > Sharing agent means projects can share transport/config and hence ease\n> > life of deployers.\n> > \n> > We see it is a library and we think that Oslo is a good place for it.\n> > \n> > Naturally, since this is going to be a _unified_ agent we seek input\n> > from all interested parties.\n> \n> It might be worth while to consider building from the Rackspace guest\n> agents for linux [2] and windows [3]. Perhaps get them moved over to\n> stackforge and scrubbed?\n> \n> These are geared towards Xen, but that would be a good first step in\n> making the HV-Guest pipe configurable.\n> \n> [2] https://github.com/rackerlabs/openstack-guest-agents-unix\n> [3] https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver\n\nThis looks promising. The exchange plugin system would, I think, allow\nfor new exchanges that are not Xen specific to be created fairly easily.\nThe XenStore thing seems too low-level to use in the general case.\nHowever, the program itself seems to have the right kind of flexible/light\nweight structure.\n\nI think we\'ll end up having to add some things to Neutron to allow\npoking holes from VPC\'s into the cloud infrastructure safely. Once that\nis done we can use any communication protocol that we can pass through\nthat.\n\n\n','<52A22FA0.7010209@rackspace.com>',NULL),('<1386403113-sup-6676@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-07 00:08:59',-28800,'2013-12-07 08:08:59',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Joshua Harlow\'s message of 2013-12-06 23:53:47 -0800:\n> Agreed,\n> \n> Chatting earlier today on #cloud-init about all of this I think scott convinced me that maybe we (the joint we in the community at large) should think about asking ourselves what do we really want a guest agent for/to do?\n> \n> If it\'s for software installation or user management then aren\'t puppet, chef, juju (lots of others) good enough?\n> \n\nRight those are system management agents.\n\n> If it\'s for tracking what a vm is doing, aren\'t there many existing tools for this already (sounds like monitoring to me).\n>\n\nRight general purpose system monitoring is a solved problem.\n\n> Is there a good list of what people really want out of a guest agent (something unique that only a guest agent can do/is best at). If there is one and it was already posted, my fault (I am on my iPhone which is not best for emails...)\n>\n\nSo what is needed is domain specific command execution and segregation\nof capabilities.\n\nWith a general purpose config tool like chef or puppet, doing MySQL\nbackups or adding MySQL users isn\'t really what they do.\n\nOne might say that this is more like what fabric or mcollective do. That\nis definitely closer to what is desired. However there is still a\ndifferent desire that may not fit well with those tools.\n\nThose tools are meant to give administrators rights to things on the\nbox. But what Trove wants is to give the trove agent the ability to\nadd a given MySQL user, but not the ability to, for instance, read the\nrecords and pass them back to the trove service.\n\nLikewise, Hadoop needs to run hadoop jobs, but not have full SSH to\nthe machine. While the _nova_ admin with root on compute nodes may\nhave the ability to just peek in on VMs, there is value in keeping the\nTrove/Savanna/Heat admins segregated from that.\n\nSo basically there is a need for structure that general purpose tools\nmay not have. I admit though, it seems like that would be something\nother tools outside of OpenStack would want as well.\n\n\n','<BD8FBCB3-CA57-4932-A820-9868806EC97D@yahoo-inc.com>',NULL),('<1386412758.67248.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-07 18:39:18',28800,'2013-12-07 10:39:18',NULL,'[Openstack] problem in creating container','hello sir,?\n\nI am sending a copy of /var/log/syslog\nhttp://paste.openstack.org/show/54639/\n\n\nplease resolve my problem.\n\nThankyou very much\n\nPragya Jain\n\n\n\nOn Friday, 6 December 2013 2:29 AM, Clay Gerrard <clay.gerrard at gmail.com> wrote:\n \nReally can\'t say what\'s misconfigured with out the logs.\n>\n>\n>Since the container is 404 it\'s something with the account databases.\n>\n>\n>The container create will try to update the account databases, with account_autocreate the first container create will try to create the account database. ?It\'s that part that\'s failing, but it has to be in some weird way - probably some directory doesn\'t exist or some symlink is missing.\n>\n>\n>-Clay\n>\n>\n>\n>On Thu, Dec 5, 2013 at 3:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello all,\n>>\n>>\n>>I had installed swift using link http://docs.openstack.org/developer/swift/development_saio.html\n>>I get an error in creating the container\n>>--------------\n>>root at pragya-VirtualBox:~# sudo\nswift-init account start  \n>>Starting\naccount-server...(/etc/swift/account-server/1.conf)  \n>>Starting\naccount-server...(/etc/swift/account-server/2.conf)  \n>>Starting\naccount-server...(/etc/swift/account-server/3.conf)  \n>>Starting\naccount-server...(/etc/swift/account-server/4.conf)  \n>>root at pragya-VirtualBox:~# sudo\nswift-init proxy restart  \n>>No\nproxy-server running  \n>>Starting\nproxy-server...(/etc/swift/proxy-server.conf)  \n>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Storage-User: prag2648:prag\' -H \'X-Storage-Pass: pj2648\' http://127.0.0.1:8080/auth/v1.0  \n>>http://paste.openstack.org/show/54498/\n>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' http://127.0.0.1:8080/v1/AUTH_prag2648  \n>>http://paste.openstack.org/show/54497/\n>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT http://127.0.0.1:8080/v1/AUTH_prag2648/photos  \n>>http://paste.openstack.org/show/54496/\n>>root at pragya-VirtualBox:~# sudo\nswift-init container start\n>>Starting\ncontainer-server...(/etc/swift/container-server/1.conf)  \n>>Starting\ncontainer-server...(/etc/swift/container-server/2.conf)  \n>>Starting\ncontainer-server...(/etc/swift/container-server/3.conf)  \n>>Starting\ncontainer-server...(/etc/swift/container-server/4.conf)  \n>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT http://127.0.0.1:8080/v1/AUTH_prag2648/photos  \n>>http://paste.openstack.org/show/54495/\n>>----------------\n>>\n>>\n>>Please help me in this regard\n>>\n>>\n>>Pragya jain\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131207/07182561/attachment.html>\n\n','<CA+_JKzoV9Ke4cGV6rBW9LMP7SPPxmU7jNV-fHq88cYkyot-jKw@mail.gmail.com>',NULL),('<1386433950-sup-8970@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-07 08:46:00',-28800,'2013-12-07 16:46:00',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Robert Collins\'s message of 2013-12-07 00:17:19 -0800:\n> On 7 December 2013 21:08, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > So what is needed is domain specific command execution and segregation\n> > of capabilities.\n> \n> Sounds rather like mcollective.\n> \n\nIt does actually. If it weren\'t explicitly tied to Ruby for its agent\nplugins I\'d say it is a good drop-in candidate. There is actually an\nattempt to replace the ruby agent with C++ here:\n\nhttps://github.com/jedi4ever/mcollective-cpp-agents\n\nBut it is 2+ years old so it is not clear at all if it was successful.\n\nAnyway, even if we can\'t use mcollective, I think we can copy its model,\nwhich is basically to have an AMQP (they use STOMP.. simpler than AMQP)\nbroker sit between clients (Trove/Savanna/Heat) and agents. Then on the\nagents, you just have named plugins which can take inputs and produce\noutputs.\n\nSo you\'d put a \'mysql_db_crud\' plugin on Trove managed instances, and a\n\'hadoop_run_job\' plugin on Savanna instances. But the agent itself is\nbasically the same everywhere.\n\n\n','<CAJ3HoZ36iSV8vkWOjFoLovau6z3DOFfsxyZqMCuw63d36uZRGg@mail.gmail.com>',NULL),('<1386434767-sup-4368@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-07 08:48:32',-28800,'2013-12-07 16:48:32',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Nicolas Barcet\'s message of 2013-12-07 01:33:01 -0800:\n> On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > So what is needed is domain specific command execution and segregation\n> > of capabilities.\n> >\n> \n> To further this, I know that a lot of security minded people consider this\n> types of agent sorts of backdoors. Having one generic \"backdoor\" that can\n> do everything is something that could be less acceptable as you would not\n> have the choice to pinpoint what you\'d like to allow it to do, or then the\n> constraints in terms of fine grained access control becomes huge.   I did\n> not realize this until I too spoke with Scott about this.  Cloud-init, or\n> any such generic tool, should only enable deployment domain specific tool,\n> based on the specific needs of given use case, not become an agent\n> (backdoor) itself.\n> \n\nRight, we already have a backdoor agent on most OS\'s, it is called SSH\nand we are used to being _very_ careful about granting SSH access.\n\n> This said, I imagine we could get some benefits out of a generic\n> framework/library that could be used create such agents in a manner where\n> base authentication and access control is done properly.  This would allow\n> to simplify security analysis and impacts of agents developped using that\n> framework, but the framework itself should never become a generic binary\n> that is deploy everywhere by default and allow way too much in itself.\n>  Binary instances of agents written using the framework would be what could\n> be eventually deployed via cloud-init on a case by case basis.\n\nI think the mcollective model (see previous message about it) has\nundergone security review and is one to copy. It is mostly what you say.\nThe agent is only capable of doing what its plugins can do, and it only\nneeds to call out to a single broker, so poking holes for the agents to\nget out is fairly straight forward.\n\n\n','<CAEcpoL8uP8KyG8W8D52QvoBLweHbJYJRD5+cWdJQ-VYp-qycdQ@mail.gmail.com>',NULL),('<1386606622-sup-153@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 08:38:30',-28800,'2013-12-09 16:38:30',NULL,'[openstack-dev] [olso] [cinder] upgrade issues in lock_path in\n	cinder after oslo utils sync','Excerpts from Sean Dague\'s message of 2013-12-09 08:17:45 -0800:\n> On 12/06/2013 05:40 PM, Ben Nemec wrote:\n> > On 2013-12-06 16:30, Clint Byrum wrote:\n> >> Excerpts from Ben Nemec\'s message of 2013-12-06 13:38:16 -0800:\n> >>>\n> >>>\n> >>> On 2013-12-06 15:14, Yuriy Taraday wrote:\n> >>>\n> >>> > Hello, Sean.\n> >>> >\n> >>> > I get the issue with upgrade path. User doesn\'t want to update\n> >>> config unless one is forced to do so.\n> >>> > But introducing code that weakens security and let it stay is an\n> >>> unconditionally bad idea.\n> >>> > It looks like we have to weigh two evils: having troubles upgrading\n> >>> and lessening security. That\'s obvious.\n> >>> >\n> >>> > Here are my thoughts on what we can do with it:\n> >>> > 1. I think we should definitely force user to do appropriate\n> >>> configuration to let us use secure ways to do locking.\n> >>> > 2. We can wait one release to do so, e.g. issue a deprecation\n> >>> warning now and force user to do it the right way later.\n> >>> > 3. If we are going to do 2. we should do it in the service that is\n> >>> affected not in the library because library shouldn\'t track releases\n> >>> of an application that uses it. It should do its thing and do it\n> >>> right (secure).\n> >>> >\n> >>> > So I would suggest to deal with it in Cinder by importing\n> >>> \'lock_path\' option after parsing configs and issuing a deprecation\n> >>> warning and setting it to tempfile.gettempdir() if it is still None.\n> >>>\n> >>> This is what Sean\'s change is doing, but setting lock_path to\n> >>> tempfile.gettempdir() is the security concern.\n> >>\n> >> Yuriy\'s suggestion is that we should let Cinder override the config\n> >> variable\'s default with something insecure. Basically only deprecate\n> >> it in Cinder\'s world, not oslo\'s. That makes more sense from a library\n> >> standpoint as it keeps the library\'s expected interface stable.\n> > \n> > Ah, I see the distinction now.  If we get this split off into\n> > oslo.lockutils (which I believe is the plan), that\'s probably what we\'d\n> > have to do.\n> > \n> >>>\n> >>> Since there seems to be plenty of resistance to using /tmp by default,\n> >>> here is my proposal:\n> >>>\n> >>> 1) We make Sean\'s change to open files in append mode. I think we can\n> >>> all agree this is a good thing regardless of any config changes.\n> >>>\n> >>> 2) Leave lockutils broken in Icehouse if lock_path is not set, as I\n> >>> believe Mark suggested earlier. Log an error if we find that\n> >>> configuration. Users will be no worse off than they are today, and if\n> >>> they\'re paying attention they can get the fixed lockutils behavior\n> >>> immediately.\n> >>\n> >> Broken how? Broken in that it raises an exception, or broken in that it\n> >> carries a security risk?\n> > \n> > Broken as in external locks don\'t actually lock.  If we fall back to\n> > using a local semaphore it might actually be a little better because\n> > then at least the locks work within a single process, whereas before\n> > there was no locking whatsoever.\n> \n> Right, so broken as in \"doesn\'t actually locks, potentially completely\n> scrambles the user\'s data, breaking them forever.\"\n> \n\nThings I\'d like to see OpenStack do in the short term, ranked in ascending\norder of importance:\n\n4) Upgrade smoothly.\n3) Scale.\n2) Help users manage external risks.\n1) Not do what Sean described above.\n\nI mean, how can we even suggest silently destroying integrity?\n\nI suggest merging Sean\'s patch and putting a warning in the release\nnotes that running without setting this will be deprecated in the next\nrelease. If that is what this is preventing this debate should not have\nhappened, and I sincerely apologize for having delayed it. I believe my\nmistake was assuming this was something far more trivial than \"without\nthis patch we destroy users\' data\".\n\nI thought we were just talking about making upgrades work. :-P\n\n\n','<52A5ED29.1080304@dague.net>',NULL),('<1386607321.25209.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-10 00:42:01',28800,'2013-12-09 16:42:01',NULL,'[Openstack] problem in creating container','please reply.\n\nplease help to solve my problem of creating the container.\n\n\n\nOn Saturday, 7 December 2013 4:24 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello sir,?\n>\n>\n>I am sending a copy of /var/log/syslog\n>http://paste.openstack.org/show/54639/\n>\n>\n>\n>please resolve my problem.\n>\n>\n>Thankyou very much\n>\n>\n>Pragya Jain\n>\n>\n>\n>On Friday, 6 December 2013 2:29 AM, Clay Gerrard <clay.gerrard at gmail.com> wrote:\n> \n>Really can\'t say what\'s misconfigured with out the logs.\n>>\n>>\n>>Since the container is 404 it\'s something with the account databases.\n>>\n>>\n>>The container create will try to update the account databases, with account_autocreate the first container create will try to create the account database. ?It\'s that part that\'s failing, but it has to be in some weird way - probably some directory doesn\'t exist or some symlink is missing.\n>>\n>>\n>>-Clay\n>>\n>>\n>>\n>>On Thu, Dec 5, 2013 at 3:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hello all,\n>>>\n>>>\n>>>I had installed swift using link http://docs.openstack.org/developer/swift/development_saio.html\n>>>I get an error in creating the container\n>>>--------------\n>>>root at pragya-VirtualBox:~# sudo\nswift-init account start  \n>>>Starting\naccount-server...(/etc/swift/account-server/1.conf)  \n>>>Starting\naccount-server...(/etc/swift/account-server/2.conf)  \n>>>Starting\naccount-server...(/etc/swift/account-server/3.conf)  \n>>>Starting\naccount-server...(/etc/swift/account-server/4.conf)  \n>>>root at pragya-VirtualBox:~# sudo\nswift-init proxy restart  \n>>>No\nproxy-server running  \n>>>Starting\nproxy-server...(/etc/swift/proxy-server.conf)  \n>>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Storage-User: prag2648:prag\' -H \'X-Storage-Pass: pj2648\' http://127.0.0.1:8080/auth/v1.0  \n>>>http://paste.openstack.org/show/54498/\n>>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' http://127.0.0.1:8080/v1/AUTH_prag2648  \n>>>http://paste.openstack.org/show/54497/\n>>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT http://127.0.0.1:8080/v1/AUTH_prag2648/photos  \n>>>http://paste.openstack.org/show/54496/\n>>>root at pragya-VirtualBox:~# sudo\nswift-init container start\n>>>Starting\ncontainer-server...(/etc/swift/container-server/1.conf)  \n>>>Starting\ncontainer-server...(/etc/swift/container-server/2.conf)  \n>>>Starting\ncontainer-server...(/etc/swift/container-server/3.conf)  \n>>>Starting\ncontainer-server...(/etc/swift/container-server/4.conf)  \n>>>root at pragya-VirtualBox:~# curl -v\n-H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT http://127.0.0.1:8080/v1/AUTH_prag2648/photos  \n>>>http://paste.openstack.org/show/54495/\n>>>----------------\n>>>\n>>>\n>>>Please help me in this regard\n>>>\n>>>\n>>>Pragya jain\n>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131210/6db94b4a/attachment.html>\n\n','<1386412758.67248.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1386607512-sup-9699@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 08:46:35',-28800,'2013-12-09 16:46:35',NULL,'[openstack-dev] [Nova][Schduler] Volunteers wanted for a modest\n	proposal for an external scheduler in our lifetime','Excerpts from Herman Narkaytis\'s message of 2013-12-09 08:18:17 -0800:\n> Hi All,\n>   Last couple of month Mirantis team was working on new scalable scheduler\n> architecture. The main concept was proposed by Boris Pavlovic in the\n> following blue print\n> https://blueprints.launchpad.net/nova/+spec/no-db-scheduler and Alexey\n> Ovchinnikov prepared a bunch of patches\n> https://review.openstack.org/#/c/45867/9\n>   This patch set was intensively reviewed by community and there was a call\n> for some kind of documentation that describes overall architecture and\n> details of implementation. Here is an etherpad document\n> https://etherpad.openstack.org/p/scheduler-design-proposal (a copy in\n> google doc\n> https://docs.google.com/a/mirantis.com/document/d/1irmDDYWWKWAGWECX8bozu8AAmzgQxMCAAdjhk53L9aM/edit\n> ).\n>   Comments and critics are highly welcome.\n> \n\nLooks great. I think I would post this message as new rather than a\nreply. It it isn\'t really related to the original thread. Many people\nwho are interested in scheduler improvements may have already killed this\nthread in their mail reader and thus may miss your excellent message. :)\n\n\n','<CAPFmEhaxkWOe+8PJJqhF=zhYC+XXJaOWS8zTSKCSdHgGx4pW=g@mail.gmail.com>',NULL),('<1386610669-sup-4526@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 09:47:30',-28800,'2013-12-09 17:47:30',NULL,'[openstack-dev] [Nova][TripleO] Nested resources','Excerpts from Fox, Kevin M\'s message of 2013-12-09 09:34:06 -0800:\n> I\'m thinking more generic:\n> \n> The cloud provider will provide one or more \"suballocating\" images. The one Triple O uses to take a bare metal node and make vm\'s available would be the obvious one to make available initially. I think that one should not have a security concern since it is already being used in that way safely.\n\nI like where you\'re going with this, in that the cloud should eventually\nbecome \"self aware\" enough to be able to privision the baremetal resources\nit has and spin nova up on them. I do think that is quite far out. Right\nnow, we have two nova\'s.. an undercloud nova which owns all the baremetal,\nand an overcloud nova which owns all the vms. This is definitely nested,\nbut there is a hard line between the two.\n\nFor many people, that hard line is a feature. For others, it is a bug.  :)\n\n> \n> I think a docker based one shouldn\'t have the safety concern either, since I think docker containerizes network resources too? I could be wrong though.\n> \n\nThe baremetal-to-tenant issues have little to do with networking. They\nare firmware problems. Root just has too much power on baremetal.\nSomebody should make some hardware which defends against that. For now\nthe best thing is virtualization extensions.\n\nDocker isn\'t really going to fix that. The containerization that is\navailable is good, but does not do nearly as much as true virtualization\ndoes to isolate the user from the hardware. There\'s still a single\nkernel there, and thus, if you can trick that kernel, you can own the\nwhole box. I\'ve heard it descried as \"a little better than chroot\".\nAFAIK, the people using containers for multi-tenant are doing so by\nleveraging kernel security modules heavily.\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C667BED4C@EMAIL05.pnl.gov>',NULL),('<1386611346-sup-2865@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 10:19:31',-28800,'2013-12-09 18:19:31',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Steven Dake\'s message of 2013-12-09 09:41:06 -0800:\n> On 12/09/2013 09:41 AM, David Boucha wrote:\n> > On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor <mordred at inaugust.com \n> > <mailto:mordred at inaugust.com>> wrote:\n> >\n> >\n> >\n> >     On 12/08/2013 07:36 AM, Robert Collins wrote:\n> >     > On 8 December 2013 17:23, Monty Taylor <mordred at inaugust.com\n> >     <mailto:mordred at inaugust.com>> wrote:\n> >     >>\n> >     >\n> >     >> I suggested salt because we could very easily make trove and\n> >     savana into\n> >     >> salt masters (if we wanted to) just by having them import salt\n> >     library\n> >     >> and run an api call. When they spin up nodes using heat, we\n> >     could easily\n> >     >> have that to the cert exchange - and the admins of the site\n> >     need not\n> >     >> know _anything_ about salt, puppet or chef - only about trove\n> >     or savana.\n> >     >\n> >     > Are salt masters multi-master / HA safe?\n> >     >\n> >     > E.g. if I\'ve deployed 5 savanna API servers to handle load, and they\n> >     > all do this \'just import\', does that work?\n> >     >\n> >     > If not, and we have to have one special one, what happens when it\n> >     > fails / is redeployed?\n> >\n> >     Yes. You can have multiple salt masters.\n> >\n> >     > Can salt minions affect each other? Could one pretend to be a\n> >     master,\n> >     > or snoop requests/responses to another minion?\n> >\n> >     Yes and no. By default no - and this is protected by key\n> >     encryption and\n> >     whatnot. They can affect each other if you choose to explicitly grant\n> >     them the ability to. That is - you can give a minion an acl to\n> >     allow it\n> >     inject specific command requests back up into the master. We use\n> >     this in\n> >     the infra systems to let a jenkins slave send a signal to our salt\n> >     system to trigger a puppet run. That\'s all that slave can do though -\n> >     send the signal that the puppet run needs to happen.\n> >\n> >     However - I don\'t think we\'d really want to use that in this case,\n> >     so I\n> >     think they answer you\'re looking for is no.\n> >\n> >     > Is salt limited: is it possible to assert that we *cannot* run\n> >     > arbitrary code over salt?\n> >\n> >     In as much as it is possible to assert that about any piece of\n> >     software\n> >     (bugs, of course, blah blah) But the messages that salt sends to a\n> >     minion are \"run this thing that you have a local definition for\"\n> >     rather\n> >     than \"here, have some python and run it\"\n> >\n> >     Monty\n> >\n> >\n> >\n> > Salt was originally designed to be a unified agent for a system like \n> > openstack. In fact, many people use it for this purpose right now.\n> >\n> > I discussed this with our team management and this is something \n> > SaltStack wants to support.\n> >\n> > Are there any specifics things that the salt minion lacks right now to \n> > support this use case?\n> >\n> \n> David,\n> \n> If I am correct of my parsing of the salt nomenclature, Salt provides a \n> Master (eg a server) and minions (eg agents that connect to the salt \n> server).  The salt server tells the minions what to do.\n> \n> This is not desirable for a unified agent (atleast in the case of Heat).\n> \n> The bar is very very very high for introducing new *mandatory* *server* \n> dependencies into OpenStack.  Requiring a salt master (or a puppet \n> master, etc) in my view is a non-starter for a unified guest agent \n> proposal.  Now if a heat user wants to use puppet, and can provide a \n> puppet master in their cloud environment, that is fine, as long as it is \n> optional.\n> \n\nWhat if we taught Heat to speak salt-master-ese? AFAIK it is basically\nan RPC system. I think right now it is 0mq, so it would be relatively\nstraight forward to just have Heat start talking to the agents in 0mq.\n\n> A guest agent should have the following properties:\n> * minimal library dependency chain\n> * no third-party server dependencies\n> * packaged in relevant cloudy distributions\n> \n\nThat last one only matters if the distributions won\'t add things like\nagents to their images post-release. I am pretty sure \"work well in\nOpenStack\" is important for server distributions and thus this is at\nleast something we don\'t have to freak out about too much.\n\n> In terms of features:\n> * run shell commands\n> * install files (with selinux properties as well)\n> * create users and groups (with selinux properties as well)\n> * install packages via yum, apt-get, rpm, pypi\n> * start and enable system services for systemd or sysvinit\n> * Install and unpack source tarballs\n> * run scripts\n> * Allow grouping, selection, and ordering of all of the above operations\n> \n\nAll of those things are general purpose low level system configuration\nfeatures. None of them will be needed for Trove or Savanna. They need\nto do higher level things like run a Hadoop job or create a MySQL user.\n\n> Agents are a huge pain to maintain and package.  It took a huge amount \n> of willpower to get cloud-init standardized across the various \n> distributions.  We have managed to get heat-cfntools (the heat agent) \n> into every distribution at this point and this was a significant amount \n> of work.  We don\'t want to keep repeating this process for each \n> OpenStack project!\n> \n\ncloud-init is special because it _must_ be in the image to be relevant.\nIt is the early-boot enabler of all other agents. The effort that happened\nthere shouldn\'t ever have to happen again as long as we are good about\nalways noting when something is an early-boot feature versus an ongoing\nmanagement feature.\n\nEven with it packaged, we still can only use the lowest common denominator\namong popular distributions until the new feature arrives there, so it is\nreally not a great idea to base anything forward-thinking on cloud-init\nfeatures. What I expect to generally happen is when cloud-init grows\na feature, whole swathes of specialized code will be deprecated and\nreplaced with small snippets of declarations for cloud-init. But the\nold code will have to keep working until the old cloud-init dies.\n\nWhat we\'re talking about is an agent that enables other workloads. Heat\'s\ngeneral case is different from Savanna and Trove\'s.  Both Savanna and\nTrove build custom images and just spin those up precisely because it\nis not efficient to use a general purpose distribution to do something\nnarrowly focused like host a database or map/reduce software.\n\nHowever, there is enough overlap in what Heat wants to do that it makes\nsense that we should try to use the same agent for Heat users if\npossible.\n\nThe complication in this discussion I think comes from the fact that we\nreally have three distinct goals:\n\na. Enable communication in and out of private networks.\nb. Enable high level control of in-instance software.\nc. Light-weight general purpose post-boot customization.\n\nI think for (a) we have neutron-metadata-agent which could be enhanced\nto be more general instead of just forwarding EC2 metadata.\n\nFor (b) salt-minion with Trove/Savanna specific plugins would fit the\nbill as long as we can teach Heat to speak salt-master. This does not\nchange the dependency graph since Trove and Savanna will already be\ndeferring infrastructure management to Heat.\n\nFor (c) I have always liked cfn-init for light-weight post-boot\ncustomization and I think it should just be kept around and taught\nto speak the protocol we validate in (b). However, if (b) is in fact\nsalt\'s protocol, it would make sense to just make it easy to manage\nsalt and let salt\'s default rules take over. Since we\'ve also decided\nto make it easy to make puppet and chef rules easy to specify in HOT,\nthis fits nicely with current plans.\n\n\n','<52A600B2.8070102@redhat.com>',NULL),('<1386613982-sup-91@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 11:01:20',-28800,'2013-12-09 19:01:20',NULL,'[openstack-dev] [heat] Core criteria, review stats vs reality','Excerpts from Steven Hardy\'s message of 2013-12-09 03:31:36 -0800:\n> Hi all,\n> \n> So I\'ve been getting concerned about $subject recently, and based on some\n> recent discussions so have some other heat-core folks, so I wanted to start\n> a discussion where we can agree and communicate our expectations related to\n> nomination for heat-core membership (becuase we do need more core\n> reviewers):\n> \n> The issues I have are:\n> - Russell\'s stats (while very useful) are being used by some projects as\n>   the principal metric related to -core membership (ref TripleO\'s monthly\n>   cull/name&shame, which I am opposed to btw).  This is in some cases\n>   encouraging some stats-seeking in our review process, IMO.\n> \n\nThis is quite misleading, so please do put the TripleO reference in\ncontext:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-October/016186.html\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-October/016232.html\n\nReading the text of those two I think you can see that while the stats\nare a tool Robert is using to find the good reviewers, it is not \"the\nprincipal metric\".\n\nI also find it quite frustrating that you are laying accusations of\n\"stats-seeking\" without proof. That is just spreading FUD. I\'m sure that\nis not what you want to do, so I\'d like to suggest that we not accuse our\ncommunity of any kind of \"cheating\" or \"gaming\" of the system without\nactual proof. I would also suggest that these accusations be made in\nprivate and dealt with directly rather than as broad passive-aggressive\nnotes on the mailing list.\n\n> - Review quality can\'t be measured mechanically - we have some folks who\n>   contribute fewer, but very high quality reviews, and are also very active\n>   contributors (so knowledge of the codebase is not stale).  I\'d like to\n>   see these people do more reviews, but removing people from core just\n>   because they drop below some arbitrary threshold makes no sense to me.\n>\n\nNot sure I agree that it absolutely can\'t, but it certainly isn\'t\nsomething these stats are even meant to do.\n\nWe other reviewers must keep tabs on our aspiring core reviewers and\ntry to rate them ourselves based on whether or not they\'re spotting the\nproblems we would spot, and whether or not they\'re also upholding the\nculture we want to foster in our community. We express our rating of\nthese people when voting on a nomination in the mailing list.\n\nSo what you\'re saying is, there is more to our votes than the mechanical\nnumber. I\'d agree 100%. However, I think the numbers _do_ let people\nknow where they stand in one very limited aspect versus the rest of the\ncommunity.\n\nI would actually find it interesting if we had a meta-gerrit that asked\nus to \"review the reviews\". This type of system works fantastically for\nstackexchange. That would give us a decent mechanical number as well.\n\n> So if you\'re aiming for heat-core nomination, here\'s my personal wish-list,\n> but hopefully others can proide their input and we can update the wiki with\n> the resulting requirements/guidelines:\n> \n> - Make your reviews high-quality.  Focus on spotting logical errors,\n>   reducing duplication, consistency with existing interfaces, opportunities\n>   for reuse/simplification etc.  If every review you do is +1, or -1 for a\n>   trivial/cosmetic issue, you are not making a strong case for -core IMHO.\n> \n\nDisagree. I am totally fine having somebody in core who is really good\nat finding all of the trivial cosmetic issues. Those should mean that\nthe second +2\'er of their code is looking at code free of trivial and\ncosmetic issues that distract from the bigger issues.\n\n> - Send patches.  Some folks argue that -core membership is only about\n>   reviews, I disagree - There are many aspects of reviews which require\n>   deep knowledge of the code, e.g spotting structural issues, logical\n>   errors caused by interaction with code not modified by the patch,\n>   effective use of test infrastructure, etc etc.  This deep knowledge comes\n>   from writing code, not only reviewing it.  This also gives us a way to\n>   verify your understanding and alignment with our sylistic conventions.\n> \n\nThe higher the bar goes, the less reviewers we will have. There are\nplenty of people that will find _tons_ of real issues but won\'t submit\nvery many patches if any. However, I think there isn\'t any value in\narguing over this point as most of our reviewers are also submitting\npatches already.\n\n> - Fix bugs.  Related to the above, help us fix real problems by testing,\n>   reporting bugs, and fixing them, or take an existing bug and post a patch\n>   fixing it.  Ask an existing team member to direct you if you\'re not sure\n>   which bug to tackle.  Sending patches doing trivial cosmetic cleanups is\n>   sometimes worthwhile, but make sure that\'s not all you do, as we need\n>   -core folk who can find, report, fix and review real user-impacting\n>   problems (not just new features).  This is also a great way to build\n>   trust and knowledge if you\'re aiming to contribute features to Heat.\n>\n\nThere\'s a theme running through this message which is suggesting \"we do\nnot value small contributions as much as big ones.\". Core needs small\ncontributions too. I personally trust people to step back from a patch\nand say \"I am not versed enough in this code to +2 this.\" Meanwhile those\nsame people can help push patches through when they are in fact trivial,\nand thus lighten the load for folk with a heavier burden of reviewing\nmore complicated patches.\n\n> - Engage in discussions related to the project (here on the ML, helping\n>   users on the general list, in #heat on Freenode, attend our weekly\n>   meeting if it\'s not an anti-social time in your TZ)\n> \n\nYes please!\n\n> Anyone have any more thoughts to add here?\n> \n\nPlease let\'s be inclusive. OpenStack would be nothing if it just allowed\nthe best and brightest to contribute. The new and unpolished will become\nthe best and brightest not by keeping their training wheels on or swimming\nin the kiddie pool, but by working hard to keep up with everyone else.\n\n\n','<20131209113135.GA8050@t430slt.redhat.com>',NULL),('<1386615690-sup-2168@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 11:03:47',-28800,'2013-12-09 19:03:47',NULL,'[openstack-dev] [heat] Core criteria, review stats vs reality','Excerpts from Zane Bitter\'s message of 2013-12-09 09:52:25 -0800:\n> On 09/12/13 06:31, Steven Hardy wrote:\n> > Hi all,\n> >\n> > So I\'ve been getting concerned about $subject recently, and based on some\n> > recent discussions so have some other heat-core folks, so I wanted to start\n> > a discussion where we can agree and communicate our expectations related to\n> > nomination for heat-core membership (becuase we do need more core\n> > reviewers):\n> >\n> > The issues I have are:\n> > - Russell\'s stats (while very useful) are being used by some projects as\n> >    the principal metric related to -core membership (ref TripleO\'s monthly\n> >    cull/name&shame, which I am opposed to btw).  This is in some cases\n> >    encouraging some stats-seeking in our review process, IMO.\n> >\n> > - Review quality can\'t be measured mechanically - we have some folks who\n> >    contribute fewer, but very high quality reviews, and are also very active\n> >    contributors (so knowledge of the codebase is not stale).  I\'d like to\n> >    see these people do more reviews, but removing people from core just\n> >    because they drop below some arbitrary threshold makes no sense to me.\n> \n> +1\n> \n> Fun fact: due to the quirks of how Gerrit produces the JSON data dump, \n> it\'s not actually possible for the reviewstats tools to count +0 \n> reviews. So, for example, one can juice one\'s review stats by actively \n> obstructing someone else\'s work (voting -1) when a friendly comment \n> would have sufficed. This is one of many ways in which metrics offer \n> perverse incentives.\n> \n> Statistics can be useful. They can be particularly useful *in the \n> aggregate*. But as soon as you add a closed feedback loop you\'re no \n> longer measuring what you originally thought - mostly you\'re just \n> measuring the gain of the feedback loop.\n> \n\nI think I understand the psychology of stats and incentives, and I know\nthat this _may_ happen.\n\nHowever, can we please be more careful about how this is referenced?\nYour message above is suggesting the absolute _worst_ behavior from our\ncommunity. That is not what I expect, and I think anybody who was doing\nthat would be dealt with _swiftly_.\n\n\n','<52A60359.8000308@redhat.com>',NULL),('<1386626003.2746.142.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 21:53:23',0,'2013-12-09 21:53:23',NULL,'[openstack-dev] TransportURL and virtualhost/exchnage (was Re:\n [Oslo] Layering olso.messaging usage of config)','Hi Gordon,\n\nOn Fri, 2013-12-06 at 18:36 +0000, Gordon Sim wrote:\n> On 11/18/2013 04:44 PM, Mark McLoughlin wrote:\n> > On Mon, 2013-11-18 at 11:29 -0500, Doug Hellmann wrote:\n> >> IIRC, one of the concerns when oslo.messaging was split out was\n> >> maintaining support for existing deployments with configuration files that\n> >> worked with oslo.rpc. We had said that we would use URL query parameters\n> >> for optional configuration values (with the required values going into\n> >> other places in the URL)\n> [...]\n> > I hadn\'t ever considered exposing all configuration options via the URL.\n> > We have a lot of fairly random options, that I don\'t think you need to\n> > configure per-connection if you have multiple connections in the one\n> > application.\n> \n> I certainly agree that not all configuration options may make sense in a \n> URL. However if you will forgive me for hijacking this thread \n> momentarily on a related though tangential question/suggestion...\n> \n> Would it make sense to (and/or even be possible to) take the \'exchange\' \n> option out of the API, and let transports deduce their implied \n> scope/namespace purely from the transport URL in perhaps transport \n> specific ways?\n> \n> E.g. you could have rabbit://my-host/my-virt-host/my-exchange or \n> rabbit://my-host/my-virt-host or rabbit://my-host//my-exchange, and the \n> rabbit driver would ensure that the given virtualhost and or exchange \n> was used.\n> \n> Alternatively you could have zmq://my-host:9876 or zmq://my-host:6789 \n> to \'scope\' 0MQ communication channels. and hypothetically \n> something-new://my-host/xyz, where xyz would be interpreted by the \n> driver in question in a relevant way to scope the interactions over that \n> transport.\n> \n> Applications using RPC would then assume they were using a namespace \n> free from the danger of collisions with other applications, but this \n> would all be driven through transport specific configuration.\n> \n> Just a suggestion based on my initial confusion through ignorance on the \n> different scoping mechanisms described in the API docs. It may not be \n> feasible or may have negative consequences I have not in my naivety \n> foreseen.\n\nIt\'s not a completely unreasonable approach to take, but my thinking was\nthat a transport URL connects you to a conduit which multiple\napplications could be sharing so you need the application to specify its\nown application namespace.\n\ne.g. you can have \'scheduler\' topics for both Nova and Cinder, and you\nneed each application to specify its exchange whereas the administrator\nis in full control of the transport URL and doesn\'t need to worry about\napplication namespacing on the transport.\n\nThere are three ways the exchange appears in the API:\n\n  1) A way for an application to set up the default exchange it\n     operates in:\n\n         messaging.set_transport_defaults(control_exchange=\'nova\')\n\n     http://docs.openstack.org/developer/oslo.messaging/transport.html#oslo.messaging.set_transport_defaults\n\n  2) The server can explicitly say what exchange its listening on:\n\n         target = messaging.Target(exchange=\'nova\',\n                                   topic=\'scheduler\',\n                                   server=\'myhost\')\n         server = messaging.get_rpc_server(transport, target, endpoints)\n\n     http://docs.openstack.org/developer/oslo.messaging/server.html#oslo.messaging.get_rpc_server\n\n  3) The client can explicitly say what exchange to connect to:\n\n         target = messaging.Target(exchange=\'nova\',\n                                   topic=\'scheduler\')\n         client = messaging.RPCClient(transport, target)\n\n     http://docs.openstack.org/developer/oslo.messaging/rpcclient.html#oslo.messaging.RPCClient\n\nBut also the admin can override the default exchange so that e.g. you\ncould put two instances of the application on the same transport, but\nwith different exchanges.\n\nNow, in saying all that, we know that fanout topics of the same name\nwill conflict even if the exchange name is different:\n\n  https://bugs.launchpad.net/oslo.messaging/+bug/1173552\n\nSo that means the API doesn\'t work quite as intended yet, but I think\nthe idea makes sense.\n\nI\'m guessing you have a concern about how transports might implement\nthis application namespacing? Could you elaborate if so?\n\nThanks,\nMark.\n\n\n\n','<52A2192F.1070803@redhat.com>',NULL),('<1386627489.2746.150.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 22:18:09',0,'2013-12-09 22:18:09',NULL,'[openstack-dev] [olso] [cinder] upgrade issues in lock_path in\n cinder after oslo utils sync','On Mon, 2013-12-09 at 11:11 -0600, Ben Nemec wrote:\n> On 2013-12-09 10:55, Sean Dague wrote:\n> > On 12/09/2013 11:38 AM, Clint Byrum wrote:\n> >> Excerpts from Sean Dague\'s message of 2013-12-09 08:17:45 -0800:\n> >>> On 12/06/2013 05:40 PM, Ben Nemec wrote:\n> >>>> On 2013-12-06 16:30, Clint Byrum wrote:\n> >>>>> Excerpts from Ben Nemec\'s message of 2013-12-06 13:38:16 -0800:\n> >>>>>> \n> >>>>>> \n> >>>>>> On 2013-12-06 15:14, Yuriy Taraday wrote:\n> >>>>>> \n> >>>>>>> Hello, Sean.\n> >>>>>>> \n> >>>>>>> I get the issue with upgrade path. User doesn\'t want to update\n> >>>>>> config unless one is forced to do so.\n> >>>>>>> But introducing code that weakens security and let it stay is an\n> >>>>>> unconditionally bad idea.\n> >>>>>>> It looks like we have to weigh two evils: having troubles \n> >>>>>>> upgrading\n> >>>>>> and lessening security. That\'s obvious.\n> >>>>>>> \n> >>>>>>> Here are my thoughts on what we can do with it:\n> >>>>>>> 1. I think we should definitely force user to do appropriate\n> >>>>>> configuration to let us use secure ways to do locking.\n> >>>>>>> 2. We can wait one release to do so, e.g. issue a deprecation\n> >>>>>> warning now and force user to do it the right way later.\n> >>>>>>> 3. If we are going to do 2. we should do it in the service that \n> >>>>>>> is\n> >>>>>> affected not in the library because library shouldn\'t track \n> >>>>>> releases\n> >>>>>> of an application that uses it. It should do its thing and do it\n> >>>>>> right (secure).\n> >>>>>>> \n> >>>>>>> So I would suggest to deal with it in Cinder by importing\n> >>>>>> \'lock_path\' option after parsing configs and issuing a deprecation\n> >>>>>> warning and setting it to tempfile.gettempdir() if it is still \n> >>>>>> None.\n> >>>>>> \n> >>>>>> This is what Sean\'s change is doing, but setting lock_path to\n> >>>>>> tempfile.gettempdir() is the security concern.\n> >>>>> \n> >>>>> Yuriy\'s suggestion is that we should let Cinder override the config\n> >>>>> variable\'s default with something insecure. Basically only \n> >>>>> deprecate\n> >>>>> it in Cinder\'s world, not oslo\'s. That makes more sense from a \n> >>>>> library\n> >>>>> standpoint as it keeps the library\'s expected interface stable.\n> >>>> \n> >>>> Ah, I see the distinction now.  If we get this split off into\n> >>>> oslo.lockutils (which I believe is the plan), that\'s probably what \n> >>>> we\'d\n> >>>> have to do.\n> >>>> \n> >>>>>> \n> >>>>>> Since there seems to be plenty of resistance to using /tmp by \n> >>>>>> default,\n> >>>>>> here is my proposal:\n> >>>>>> \n> >>>>>> 1) We make Sean\'s change to open files in append mode. I think we \n> >>>>>> can\n> >>>>>> all agree this is a good thing regardless of any config changes.\n> >>>>>> \n> >>>>>> 2) Leave lockutils broken in Icehouse if lock_path is not set, as \n> >>>>>> I\n> >>>>>> believe Mark suggested earlier. Log an error if we find that\n> >>>>>> configuration. Users will be no worse off than they are today, and \n> >>>>>> if\n> >>>>>> they\'re paying attention they can get the fixed lockutils behavior\n> >>>>>> immediately.\n> >>>>> \n> >>>>> Broken how? Broken in that it raises an exception, or broken in \n> >>>>> that it\n> >>>>> carries a security risk?\n> >>>> \n> >>>> Broken as in external locks don\'t actually lock.  If we fall back to\n> >>>> using a local semaphore it might actually be a little better because\n> >>>> then at least the locks work within a single process, whereas before\n> >>>> there was no locking whatsoever.\n> >>> \n> >>> Right, so broken as in \"doesn\'t actually locks, potentially \n> >>> completely\n> >>> scrambles the user\'s data, breaking them forever.\"\n> >>> \n> >> \n> >> Things I\'d like to see OpenStack do in the short term, ranked in \n> >> ascending\n> >> order of importance:\n> >> \n> >> 4) Upgrade smoothly.\n> >> 3) Scale.\n> >> 2) Help users manage external risks.\n> >> 1) Not do what Sean described above.\n> >> \n> >> I mean, how can we even suggest silently destroying integrity?\n> >> \n> >> I suggest merging Sean\'s patch and putting a warning in the release\n> >> notes that running without setting this will be deprecated in the next\n> >> release. If that is what this is preventing this debate should not \n> >> have\n> >> happened, and I sincerely apologize for having delayed it. I believe \n> >> my\n> >> mistake was assuming this was something far more trivial than \"without\n> >> this patch we destroy users\' data\".\n> >> \n> >> I thought we were just talking about making upgrades work. :-P\n> > \n> > Honestly, I haven\'t looked exactly how bad the corruption would be. But\n> > we are locking to handle something around simultaneous db access in\n> > cinder, so I\'m going to assume the worst here.\n> \n> Yeah, my understanding is that this doesn\'t come up much in actual use \n> because lock_path is set in most production environments.  Still, \n> obviously not cool when your locks don\'t lock, which is why we made the \n> unpleasant change to require lock_path.  It wasn\'t something we did \n> lightly (I even sent something to the list before it merged, although I \n> got no responses at the time).\n\nWhat would happen if we required each service to set a sane default\nhere?\n\ne.g. for Nova, would a dir under $state_path work? It just needs to be a\ndirectory that isn\'t world-writeable but is writeable by whatever user\nNova is running as.\n\nPractically speaking, this just means that Cinder needs to do:\n\n  lockutils.set_defaults(lock_path=os.path.join(CONF.state_path, \'tmp\'))\n\nand the current behaviour of lockutils.py is fine.\n\nHmm, that feels like I\'m missing something?\n\nMark.\n\n\n\n','<4ba1de60bfeaef731b26af54c6fc8a99@localhost>',NULL),('<1386627736.2746.153.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 22:22:16',0,'2013-12-09 22:22:16',NULL,'[openstack-dev] Retiring \"reverify no bug\"','On Mon, 2013-12-09 at 10:49 -0800, James E. Blair wrote:\n> Hi,\n> \n> On Wednesday December 11, 2013 we will remove the ability to use\n> \"reverify no bug\" to re-trigger gate runs for changes that have failed\n> tests.\n> \n> This was previously discussed[1] on this list.  There are a few key\n> things to keep in mind:\n> \n> * This only applies to \"reverify\", not \"recheck\".  That is, it only\n>   affects the gate pipeline, not the check pipeline.  You can still use\n>   \"recheck no bug\" to make sure that your patch still works.\n> \n> * Core reviewers can still resubmit a change to the queue by leaving\n>   another \"Approved\" vote.  Please don\'t abuse this to bypass the intent\n>   of this change: to help identify and close gate-blocking bugs.\n> \n> * You may still use \"reverify bug #\" to re-enqueue if there is a bug\n>   report for a failure, and of course you are encouraged to file a bug\n>   report if there is not.  Elastic-recheck is doing a great job of\n>   indicating which bugs might have caused a failure.\n> \n> As discussed in the previous thread, the goal is to prevent new\n> transient bugs from landing in code by ensuring that if a change fails a\n> gate test that it is because of a known bug, and not because it\'s\n> actually introducing a bug, so please do your part to help in this\n> effort.\n\nI wonder could we make it standard practice for an infra bug to get\nfiled whenever there\'s a known issue causing gate jobs to fail so that\neveryone can use that bug number when re-triggering?\n\n(Apologies if that\'s already happening)\n\nI guess we\'d want to broadcast that bug number with statusbot?\n\nBasically, the times I\'ve used \'reverify no bug\' is where I see some job\nfailures that look like an infra issue that was already resolved.\n\nThanks,\nMark.\n\n\n\n','<87eh5l507a.fsf@meyer.lemoncheese.net>',NULL),('<1386629168.2746.161.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 22:46:08',0,'2013-12-09 22:46:08',NULL,'[openstack-dev] [Nova][TripleO] Nested resources','On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote:\n> On 6 December 2013 14:11, Fox, Kevin M <kevin.fox at pnnl.gov> wrote:\n> > I think the security issue can be handled by not actually giving the underlying resource to the user in the first place.\n> >\n> > So, for example, if I wanted a bare metal node\'s worth of resource for my own containering, I\'d ask for a bare metal node and use a \"blessed\" image that contains docker+nova bits that would hook back to the cloud. I wouldn\'t be able to login to it, but containers started on it would be able to access my tenant\'s networks. All access to it would have to be through nova suballocations. The bare resource would count against my quotas, but nothing run under it.\n> >\n> > Come to think of it, this sounds somewhat similar to what is planned for Neutron service vm\'s. They count against the user\'s quota on one level but not all access is directly given to the user. Maybe some of the same implementation bits could be used.\n> \n> This is a super interesting discussion - thanks for kicking it off.\n> \n> I think it would be fantastic to be able to use containers for\n> deploying the cloud rather than full images while still running\n> entirely OpenStack control up and down the stack.\n\nWhere I think it gets really interesting is to be able to auto-scale\ncontroller services (think nova-api based on request latency) in small\nincrements just you\'d expect to be able to manage a scale-out app on a\ncloud.\n\ni.e. our overcloud Heat stack would allocate some baremetal machines,\nbut then just schedule the controller services to run in small\ncontainers (or VMs) on any of those machines, and then have them\nauto-scale.\n\n> Briefly, what we need to be able to do that is:\n> \n>  - the ability to bring up an all in one node with everything on it to\n> \'seed\' the environment.\n>     - we currently do that by building a disk image, and manually\n> running virsh to start it\n\nI\'m not sure that would need to change.\n\n>  - the ability to reboot a machine *with no other machines running* -\n> we need to be able to power off and on a datacentre - and have the\n> containers on it come up correctly configured, networking working,\n> running etc.\n\nThat\'s tricky because your undercloud Nova DB/conductor needs to be\navailable for the machine to know what services it\'s supposed to be\nrunning. It sounds like a reasonable thing to want even for standard KVM\ncompute nodes too, though.\n\n>  - we explicitly want to be just using OpenStack APIs for all the\n> deployment operations after the seed is up; so no direct use of lxc or\n> docker or whathaveyou.\n\nYes.\n\nMark.\n\n\n\n','<CAJ3HoZ3wnREhdmAXi9Xw0UN4mE6xays2g0u-=8SmxkRJmmAfjw@mail.gmail.com>',NULL),('<1386630807.2746.172.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 23:13:27',0,'2013-12-09 23:13:27',NULL,'[openstack-dev] [heat] Core criteria, review stats vs reality','On Mon, 2013-12-09 at 10:00 -0500, Russell Bryant wrote:\n> On 12/09/2013 07:43 AM, Thierry Carrez wrote:\n> > Steven Hardy wrote:\n> >> [...]\n> >> The issues I have are:\n> >> - Russell\'s stats (while very useful) are being used by some projects as\n> >>   the principal metric related to -core membership (ref TripleO\'s monthly\n> >>   cull/name&shame, which I am opposed to btw).  This is in some cases\n> >>   encouraging some stats-seeking in our review process, IMO.\n> >>\n> >> - Review quality can\'t be measured mechanically - we have some folks who\n> >>   contribute fewer, but very high quality reviews, and are also very active\n> >>   contributors (so knowledge of the codebase is not stale).  I\'d like to\n> >>   see these people do more reviews, but removing people from core just\n> >>   because they drop below some arbitrary threshold makes no sense to me.\n> >> [...]\n> > \n> > In our governance each program\'s PTL is free to choose his preferred\n> > method of selecting core reviewers, but FWIW I fully agree with you here.\n> > \n> > Using the review stats as the principal metric in deciding -core\n> > membership is IMHO destructive in the long run. You can use it to check\n> > for minimum volume, but then review quality should be the main factor,\n> > and the only way to assess that is to see consistent quality reviews\n> > made by others and then suggest them for -core membership.\n> > \n> \n> Agreed here, as well.  While the stats provide some important insight,\n> it\'s far from the whole picture.\n\nThe stats exist and they\'re really the only concrete thing an aspiring\ncore reviewer can look at to judge how they\'re doing and whether/when\ntheir review contributions are likely to be valued enough for them to be\nadded to the team.\n\nRobert and Clint took issue with TripleO being painted in a bad light\nhere. I agree because I think Robert is actually setting an really\ninteresting example for other PTLs.\n\nFor example, thanks to his email, look at the feedback I have:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2013-December/021101.html\n\n  Mark is contributing great throughtful reviews, but the vast majority\n  are very recent - like Roman, I want to give him some more time\n  getting settled in with TripleO before proposing him for core.\n\nNevermind Robert\'s approach to the more delicate question of\nexpectations around some of the Tuskar developers who were added to\n-core when the projects merged.\n\nAs a PTL, I would have been reluctant to take this approach because it\'s\nso brutally personal. But OTOH the complete openness leaves it in no\ndoubt that everything is being done in absolute good faith and everyone\ncan be absolutely sure what is expected of them. I\'m very pleasantly\nsurprised at how well it works.\n\nMark.\n\n\n\n','<52A5DAF4.90808@redhat.com>',NULL),('<1386631796.2746.177.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 23:29:56',0,'2013-12-09 23:29:56',NULL,'[openstack-dev] [Oslo] First steps towards amqp 1.0','On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote:\n> Greetings,\n> \n> As $subject mentions, I\'d like to start discussing the support for\n> AMQP 1.0[0] in oslo.messaging. We already have rabbit and qpid drivers\n> for earlier (and different!) versions of AMQP, the proposal would be\n> to add an additional driver for a _protocol_ not a particular broker.\n> (Both RabbitMQ and Qpid support AMQP 1.0 now).\n> \n> By targeting a clear mapping on to a protocol, rather than a specific\n> implementation, we would simplify the task in the future for anyone\n> wishing to move to any other system that spoke AMQP 1.0. That would no\n> longer require a new driver, merely different configuration and\n> deployment. That would then allow openstack to more easily take\n> advantage of any emerging innovations in this space.\n\nSounds sane to me.\n\nTo put it another way, assuming all AMQP 1.0 client libraries are equal,\nall the operator cares about is that we have a driver that connect into\nwhatever AMQP 1.0 messaging topology they want to use.\n\nOf course, not all client libraries will be equal, so if we don\'t offer\nthe choice of library/driver to the operator, then the onus is on us to\npick the best client library for this driver.\n\n(Enjoying the rest of this thread too, thanks to Gordon for his\ninsights)\n\nMark.\n\n\n\n','<20131209150555.GC21846@redhat.com>',NULL),('<1386651797.1970.8.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-10 13:03:17',28800,'2013-12-10 05:03:17',NULL,'[Openstack] Ceph bootable cinder volume not working in Havana','On Tue Dec 10 2013 12:03:16 PM HKT, Haomai Wang <haomaiwang at gmail.com> wrote:\n\n> Could you give out your cinder.conf?\n> \n> On Tue, Dec 10, 2013 at 4:10 AM, Edward Lezondra\n> <Edward.Lezondra at imc-chicago.com> wrote:\n> > Hello,\n> > \n> > I?m having trouble getting a bootable cinder volume to work in Havana\n> > using Ceph. I managed to get glance working correctly. I got cinder\n> > volume to work, but once I try to create bootable cinder volume to an\n> > image it errors out.\n\nHi,\n\ndon\'t search, it is a known problem that isn\'t\nsolved yet, and even less backported to Havana.\nThe Ceph maintainers are currently working on this.\n\nThomas Goirand (zigo)\n\n\n\n','<CACJqLyb7jd0L-+=pn-nrwgK8+gsn=Mb=p67h5=1xVW80+cUk8w@mail.gmail.com>',NULL),('<1386661632.2746.187.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 07:47:12',0,'2013-12-10 07:47:12',NULL,'[openstack-dev] [Tripleo] Core reviewer update Dec','On Tue, 2013-12-10 at 13:31 +1300, Robert Collins wrote:\n\n> We have a bit of a bug in OpenStack today, IMO, in that there is more\n> focus on being -core than on being a good effective reviewer. IMO\n> that\'s backwards: the magic switch that lets you set +2 and -2 is a\n> responsibility, and that has some impact on the weight your comments\n> in reviews have on other people - both other core and non-core, but\n> the contribution we make by reviewing doesn\'t suddenly get\n> significantly better by virtue of being -core. There is an element of\n> trust and faith in personality etc - you don\'t want destructive\n> behaviour in code review, but you don\'t want that from anyone - it\'s\n> not a new requirement place on -core.\n\nFWIW, I see the this \"focus on being -core\" as an often healthy desire\nto be recognized as a good effective reviewer.\n\nI guess that\'s related to where you said something similar in the Heat\nthread:\n\n  http://www.mail-archive.com/openstack-dev at lists.openstack.org/msg11121.html\n\n  there is a meme going around (I don\'t know if it\'s true or not) that\n  some people are assessed - performance review stuff within vendor\n  organisations - on becoming core reviewers.\n\nFor example, if managers in these organizations said to people \"I want\nto spend a significant proportion of your time contributing good and\neffective upstream reviews\" that would be a good thing, right?\n\nOne way that such well intentioned managers could know whether the\nreviewing is good and effective is whether the reviewers are getting\nadded to the -core teams. That also seems mostly positive. Certainly\nbetter than looking at reviewer stats?\n\nMark.\n\n\n\n','<CAJ3HoZ1UXJz85VojPaVyW7z=w=y8thN3sirsdBV1_-V4UxWwXw@mail.gmail.com>',NULL),('<1386695429-sup-7696@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 09:31:47',-28800,'2013-12-10 17:31:47',NULL,'[openstack-dev] [Tripleo] Core reviewer update Dec','Excerpts from Robert Collins\'s message of 2013-12-09 16:31:37 -0800:\n> On 6 December 2013 21:56, Jaromir Coufal <jcoufal at redhat.com> wrote:\n> \n> >\n> > Hey there,\n> >\n> > thanks Rob for keeping eye on this. Speaking for myself, as current\n> > non-coder it was very hard to keep pace with others, especially when UI was\n> > on hold and I was designing future views. I\'ll continue working on designs\n> > much more, but I will also keep an eye on code which is going in. I believe\n> > that UX reviews will be needed before merging so that we assure keeping the\n> > vision. That\'s why I would like to express my will to stay within -core even\n> > when I don\'t deliver that big amount of reviews as other engineers. However\n> > if anybody feels that I should be just +1, I completely understand and I\n> > will give up my +2 power.\n> >\n> > -- Jarda\n> \n> Hey, so -\n> \n> I think there are two key things to highlight here. Firstly, there\'s\n> considerable support from other -core for delaying the removals this\n> month, so we\'ll re-evaluate in Jan (and be understanding then as there\n> is a big 1-2 week holiday in there).\n> \n> That said, I want to try and break down the actual implications here,\n> both in terms of contributions, recognition and what it means for the\n> project.\n> \n> Firstly, contributions. Reviewing isn\'t currently *directly*\n> recognised as a \'technical contribution\' by the bylaws: writing code\n> that land in the repository is, and there is a process for other\n> contributions (such as design, UX, and reviews) to be explicitly\n> recognised out-of-band. It\'s possible we should revisit that -\n> certainly I\'d be very happy to nominate people contributing through\n> that means as a TripleO ATC irrespective of their landing patches in a\n> TripleO code repository [as long as their reviews *are* helpful :)].\n> But thats a legalistic sort of approach. A more holistic approach is\n> to say that any activity that helps TripleO succeed in it\'s mission is\n> a contribution, and we should be fairly broad in our recognition of\n> that activity : whether it\'s organising contributed hardware for the\n> test cloud, helping admin the test cloud, doing code review, or UX\n> design - we should recognise and celebrate all of those things.\n> Specifically, taking the time to write a thoughtful code review which\n> avoids a bug landing in TripleO, or keeps the design flexible and\n> effective *is* contributing to TripleO.\n> \n> We have a bit of a bug in OpenStack today, IMO, in that there is more\n> focus on being -core than on being a good effective reviewer. IMO\n> that\'s backwards: the magic switch that lets you set +2 and -2 is a\n> responsibility, and that has some impact on the weight your comments\n> in reviews have on other people - both other core and non-core, but\n> the contribution we make by reviewing doesn\'t suddenly get\n> significantly better by virtue of being -core. There is an element of\n> trust and faith in personality etc - you don\'t want destructive\n> behaviour in code review, but you don\'t want that from anyone - it\'s\n> not a new requirement place on -core. What I\'d like to see is more of\n> a focus on review (design review, code review, architecture review) as\n> something we should all contribute towards - jointly share the burden.\n> For instance, the summit is a fantastic point for us to come together\n> and do joint design review of the work organisations are pushing on\n> for the next 6 months : thats a fantastic contribution. But when\n> organisations don\'t send people to the summit, because of $reasons,\n> that reduces our entire ability to catch problems with that planned\n> work : going to the summit is /hard work/ - long days, exhausting,\n> intense conversations. The idea (which I\'ve heard some folk mention)\n> that only -core folk would be sent to the summit is incredibly nutty!\n> \n\nWe are human.\n\nHumans see a word like core and they look it up in their internal\ndictionary. Apples have cores. Nuclear reactors have cores. You can\nextract a core sample from deep under a sheet of ice. In our mind,\ncores are at the _center_. The seeds are in the cores. Cores are where\nall the magic happens. They hold the secrets.\n\nSo it makes sense that when not-core sees core, they think \"I should\ndefer to this person.\" They do not think \"I am a peer.\" If the code\nreview process were a nuclear reactor, they are just shielding, or vent\ntubes. That person is part of _the core_.\n\nAnd having +2/-2/+A reinforces this. Core does not have to say much,\nthey can \"speak softly and carry a big -2 stick\".\n\nFinally, being confirmed by the rest of the team makes them special. It\nmakes them a leader.\n\nCan we change this? Before we run off and change everything, I think we\nmust also ask ourselves \"should we change this?\"\n\n> So what does it mean for TripleO when someone stops being -core\n> because of inactivity:\n> \n> Firstly it means they have *already* effectively stopped doing code\n> review at a high frequency: they are *not* contributing in a\n> substantial fashion through that avenue. It doesn\'t mean anything\n> about other avenues of contribution.\n> \n> Secondly, if they do notice something badly wrong with a patch, or a\n> patch that needs urgent landing, they can no longer do that\n> themselves: they need to find a -core and get the -core to do it.\n> \n> Thats really about it - there is no substantial impact on the core\n> review bandwidth for the team (they were already largely inactive).\n> \n\nThey also lose the ability to +1 or -1 changes to the core team.\n\nBut the bigger loss is that it means they lose a label that gives\ntheir voice amplification. It may not be intended that way, but I would\nchallenge anyone to explain that it is not that way. I would be surprised\nto see one review stream that does not have core reviewers setting the\ntone and driving almost all of the conversations.\n\nShould we change this? I don\'t think so. I think being a leader is\na burden unto itself. I also think that all reviewers can be trusted\nto hold off with just +1 instead of +2 if they don\'t feel like they\'re\nfamiliar enough with the code to +2. And I think it would make our\ngovernance unnecessarily complex if we tried to have two overlapping\ngroups for core review and leadership.\n\nSo for what it is worth, I think that we should make core more sticky\nand just give core people a reminder when they\'re not doing _all_ of\nthe duties that they\'ve signed up for. Your email showing people below\nthe line is an example of a reminder for those people. \"You are not\ndoing everything a leader must do.\"\n\n\n','<CAJ3HoZ1UXJz85VojPaVyW7z=w=y8thN3sirsdBV1_-V4UxWwXw@mail.gmail.com>',NULL),('<1386697993-sup-3213@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 09:55:10',-28800,'2013-12-10 17:55:10',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 08:15:15 -0800:\n> Guys,\n> \n> I see two major trends in the thread:\n> \n>  * use Salt\n>  * write our own solution with architecture similar to Salt or MCollective\n> \n> There were points raised pro and contra both solutions. But I have a\n> concern which I believe was not covered yet. Both solutions use either\n> ZeroMQ or message queues (AMQP/STOMP) as a transport. The thing is there is\n> going to be a shared facility between all the tenants. And unlike all other\n> OpenStack services, this facility will be directly accessible from VMs,\n> which leaves tenants very vulnerable to each other. Harm the facility from\n> your VM, and the whole Region/Cell/Availability Zone will be left out of\n> service.\n> \n> Do you think that is solvable, or maybe I overestimate the threat?\n> \n\nI think Salt would be thrilled if we tested and improved its resiliency\nto abuse. We\'re going to have to do that with whatever we expose to VMs.\n\n\n','<CALU-hjFznot+-Pc1EdYNf9fu=A9osAcVNYixjpKgTtZ7w=9SFg@mail.gmail.com>',NULL),('<1386698113-sup-7135@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 09:58:44',-28800,'2013-12-10 17:58:44',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 08:25:26 -0800:\n> And one more thing,\n> \n> Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].\n> Its design is somewhat different and can be expressed by the following\n> formulae:\n> \n> App -> Host (XenStore) <-> Guest Agent\n> \n> (taken from the wiki [3])\n> \n> It has an obvious disadvantage - it is hypervisor dependent and currently\n> implemented for Xen only. On the other hand such design should not have\n> shared facility vulnerability as Agent accesses the server not directly but\n> via XenStore (which AFAIU is compute node based).\n> \n\nI don\'t actually see any advantage to this approach. It seems to me that\nit would be simpler to expose and manage a single network protocol than\nit would be to expose hypervisor level communications for all hypervisors.\n\n\n','<CALU-hjEK-12xKnGNtHCLKnWDrJ3NnKpcxkjcWaXn7DifeXd4yw@mail.gmail.com>',NULL),('<1386698458-sup-8209@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 10:03:19',-28800,'2013-12-10 18:03:19',NULL,'[openstack-dev] [heat] Stack preview','Excerpts from Richard Lee\'s message of 2013-12-10 09:46:49 -0800:\n> Hey all,\n> \n> We\'re working on a\n> blueprint<https://blueprints.launchpad.net/heat/+spec/preview-stack>\n> that\n> adds the ability to preview what a given template+parameters would create\n> in terms of resources.  We think this would provide significant value for\n> blueprint authors and for other heat users that want to see what someone\'s\n> template would create before actually launching resources (and possibly\n> having to pay for them).\n> \n> We\'d love to hear any thoughts regarding this feature\n\nThanks for starting with use cases. I like the use case of being able\nto preview the damage this template will do to your bank account when\nconsuming templates without actually understanding the template language.\n\nI\'d love to see more details in the spec.\n\n\n','<CAJ39heyiOLLWbYrwqVg_XXWjaErAycnsMgHsosizd6BXzO18UA@mail.gmail.com>',NULL),('<1386700450-sup-2001@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 10:34:34',-28800,'2013-12-10 18:34:34',NULL,'[openstack-dev] [Heat] workflow for fixes involving numerous\n	changes','Excerpts from Steven Hardy\'s message of 2013-12-10 03:00:26 -0800:\n> On Tue, Dec 10, 2013 at 11:45:11AM +0200, Pavlo Shchelokovskyy wrote:\n> > - wouldn\'t it be better to keep all these changes in one bug and fix all\n> > misuses per file basis (with one file per patch-set for example)? It seems\n> > to me it would be easier to review in this way.\n> \n> One file per patch is not a good idea IMO, I think the review burden is\n> minimised if you make sure that each commit just contains the exact same\n> change to many files, then it\'s quick to click through them all and confirm\n> all looks OK.\n\n+1\n\n\n','<20131210110026.GB5227@t430slt.redhat.com>',NULL),('<1386700657.470217495@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 12:37:37',-21600,'2013-12-10 18:37:37',NULL,'[openstack-dev] [Solum] [Plan]','Hi Adrian,\n\nThanks for creating https://etherpad.openstack.org/p/solum-demystified\n\nI am really excited to see the examples. Especially cool is how\nexamples 2 and 3 demonstrate using a component (\"solum_glance_id\") created\nas part of example 1.\n\n\nSome questions/comments:\n\n1) Summarizing the sequence of events just to make sure I understand them correctly: \n   a) User selects a language pack and specifies its id in the plan file\n   b) User creates repo with the plan file in it.\n\n   After this the flow could be:\n   c.1) User uses solum cli to \'create\' an application by giving reference to \n      the repo uri\n       c.1.1) Solum creates a plan resource\n       c.1.2) Solum model interpreter creates a Heat stack and does the rest of the\n        things needed to create a assembly. \n       (The created plan resource does not play any part in assembly creation as such.\n        Its only role is being a \'trackback\' to track the plan from which the assembly was created.)\n\n   or, \n   c.2) User uses solum cli to \'create/register\' a plan by providing reference to the repo uri. \n        c.2.1) Solum creates the plan resource.\n   c.2) User uses solum cli to \'create\' an application by specifying the created plan\n        resource uri\n        (In this flow, the plan is actively used).\n      \n\n2) Addition of new solum specific attributes in a plan specification is interesting.\n   I imagine those can be contributed back as \"Solum\" profile to CAMP spec?\n\n\n3) Model interpreter for generating Heat stack from a plan is a nice idea.\n   For all: Are there any recommended libraries for this?\n\n\n4) Just to confirm, I assume that the api-spec-review etherpad (https://etherpad.openstack.org/p/solum-api-spec-review), \n   is for fyi purpose only. If someone wants to know what is the current thinking about API, they should\n   just look at the solum-demystified etherpad (https://etherpad.openstack.org/p/solum-demystified)\n\n\nThanks,\nDevdatta\n\n\n\n\n','<CECB86A3.12F9C%paul.montgomery@rackspace.com>',NULL),('<1386704517-sup-8868@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 11:55:34',-28800,'2013-12-10 19:55:34',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 11:08:58 -0800:\n> 2013/12/10 Clint Byrum <clint at fewbar.com>\n> \n> > Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 08:25:26 -0800:\n> > > And one more thing,\n> > >\n> > > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].\n> > > Its design is somewhat different and can be expressed by the following\n> > > formulae:\n> > >\n> > > App -> Host (XenStore) <-> Guest Agent\n> > >\n> > > (taken from the wiki [3])\n> > >\n> > > It has an obvious disadvantage - it is hypervisor dependent and currently\n> > > implemented for Xen only. On the other hand such design should not have\n> > > shared facility vulnerability as Agent accesses the server not directly\n> > but\n> > > via XenStore (which AFAIU is compute node based).\n> > >\n> >\n> > I don\'t actually see any advantage to this approach. It seems to me that\n> > it would be simpler to expose and manage a single network protocol than\n> > it would be to expose hypervisor level communications for all hypervisors.\n> >\n> \n> I think the Rackspace agent design could be expanded as follows:\n> \n> Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <->\n> XenStore <-> Guest Agent\n> \n> That is somewhat speculative because if I understood it correctly the\n> opened code covers only the second part of exchange:\n> \n> Python API / CMD interface <-> XenStore <-> Guest Agent\n> \n> Assuming I got it right:\n> While more complex, such design removes pressure from AMQP/ZeroMQ\n> providers: on the \'Agent on Compute\' you can easily control the amount of\n> messages emitted by Guest with throttling. It is easy since such agent runs\n> on a compute host. In the worst case, if it is happened to be abused by a\n> guest, it affect this compute host only and not the whole segment of\n> OpenStack.\n> \n\nThis still requires that we also write a backend to talk to the host\nfor all virt drivers. It also means that any OS we haven\'t written an\nimplementation for needs to be hypervisor-aware. That sounds like a\nnever ending battle.\n\nIf it is just a network API, it works the same for everybody. This\nmakes it simpler, and thus easier to scale out independently of compute\nhosts. It is also something we already support and can very easily expand\nby just adding a tiny bit of functionality to neutron-metadata-agent.\n\nIn fact we can even push routes via DHCP to send agent traffic through\na different neutron-metadata-agent, so I don\'t see any issue where we\nare piling anything on top of an overstressed single resource. We can\nhave neutron route this traffic directly to the Heat API which hosts it,\nand that can be load balanced and etc. etc. What is the exact scenario\nyou\'re trying to avoid?\n\n\n','<CALU-hjGLjiWKpfze3L9B1ubh0Sj0VyM4R3_XaLaPXiTiDLDU_A@mail.gmail.com>',NULL),('<1386708760-sup-4586@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-10 13:02:41',-28800,'2013-12-10 21:02:41',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 12:37:37 -0800:\n> >> What is the exact scenario you\'re trying to avoid?\n> \n> It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server\n> (Salt / Our own self-written server). Looking at the design, it doesn\'t\n> look like the attack could be somehow contained within a tenant it is\n> coming from.\n> \n\nWe can push a tenant-specific route for the metadata server, and a tenant\nspecific endpoint for in-agent things. Still simpler than hypervisor-aware\nguests. I haven\'t seen anybody ask for this yet, though I\'m sure if they\nrun into these problems it will be the next logical step.\n\n> In the current OpenStack design I see only one similarly vulnerable\n> component - metadata server. Keeping that in mind, maybe I just\n> overestimate the threat?\n> \n\nAnything you expose to the users is \"vulnerable\". By using the localized\nhypervisor scheme you\'re now making the compute node itself vulnerable.\nOnly now you\'re asking that an already complicated thing (nova-compute)\nadd another job, rate limiting.\n\n\n','<CALU-hjG0xZn8jZQONUSG2W29Yerf4R+Rmis06kot7zo2KH4C8w@mail.gmail.com>',NULL),('<1386749167.37101.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-11 16:06:07',28800,'2013-12-11 08:06:07',NULL,'[Openstack] cannot create container','hello,\n\nI had installed swift using link?http://docs.openstack.org/developer/swift/development_saio.html\n\nI am facing problem in creating container.\n\ncurl -v -H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUT http://127.0.0.1:8080/v1/AUTH_prag2648/photos\n\nhttp://paste.openstack.org/show/54495/\n\n\nI am also sending a copy of /var/log/syslog\n\nhttp://paste.openstack.org/show/54807/\n\n\nPlease help me in this regard.\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131211/b5e36877/attachment.html>\n\n',NULL,NULL),('<1386791174-sup-3898@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 11:47:27',-28800,'2013-12-11 19:47:27',NULL,'[openstack-dev] 答复: [OpenStack][Heat] AutoScaling scale down issue','Hi!\n\nThis list is for discussion of ongoing bugs and features in Heat. For\nuser-centric discussions, please use the main \"openstack\" mailing list:\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\nThanks!\n\nExcerpts from Haiming Yang\'s message of 2013-12-11 09:40:32 -0800:\n> I think it might be useful to think about how to integrate savana into heat.\n> When auto scale usually the first created node will be removed first.\n> \n> -----????-----\n> ???: \"Jay Lau\" <jay.lau.513 at gmail.com>\n> ????: ?2013/?12/?11 23:46\n> ???: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> ??: [openstack-dev] [OpenStack][Heat] AutoScaling scale down issue\n> \n> Greetings,\n> \n> \n> Here come a question related to heat auto scale down.\n> \n> \n> The scenario is as following:\n> \n> I was trying to deploy hadoop cluster with heat Auto Scaling template. \n> \n> When scale up a slave node, I can use user-data to do some post work for configuration file on hadoop master node base on the information of slave node (The mainly configuration file is conf/slaves as I need to put slave node to this file);\n> \n> But when scale down, seems I have no chance to do some configuration for the master node (Remove the scale down node from conf/slaves) as master node do not know which slave node was scale down.\n> \n> \n> Does anyone has some experience on this?\n> \n> \n> \n> Thanks,\n> \n> \n> Jay\n\n\n','<52a8a3ad.c1d9420a.7907.ffffe631@mx.google.com>',NULL),('<1386863212.19316.64.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2013-12-12 15:46:52',0,'2013-12-12 15:46:52',NULL,'[openstack-tc] J naming poll','On Thu, 2013-12-12 at 10:40 -0500, Doug Hellmann wrote:\n> On Thu, Dec 12, 2013 at 8:24 AM, Thierry Carrez <thierry at openstack.org>wrote:\n> \n> > Hi fellow members of the TC,\n> >\n> > We now have a set of 10 potential names for the J release [1], and need\n> > to pick the best method to select the winner. Historically we held a\n> > Launchpad poll (~openstack group) over a refined set of 4-5 options. The\n> > problem is, we don\'t really use the Launchpad ~openstack group anymore\n> > (used to be the subscribers to the openstack ML) and the group was\n> > therefore closed... so that\'s no longer the \"less worse\" option.\n> >\n> > A few proposed solutions:\n> >\n> > 1. \"Public\" CIVS vote, accessible to everyone with the link\n> > Easy to set up, but vote is limited to one per IP address, which can\n> > block legitimate voters while encouraging ballot stuffing.\n> >\n> > 2a. Private CIVS vote, link sent to openstack-dev subscribers\n> > A bit painful to set up (need to extract the 2926 subscribers emails,\n> > then feed them to CIVS by batches of less than 1000), but at least it\'s\n> > not gameable. One difference is that receiving a private vote email will\n> > result in more participation than the only-announced-on-ML Launchpad poll.\n> >\n> > 2b. Private CIVS vote, link sent to openstack list subscribers\n> > More painful to set up (8573 members), and CIVS advises against being\n> > used to run above \"a couple thousands voters\". That said it\'s probably\n> > the closest to the people who voted in the past (general list).\n> >\n> > 3. Launchpad poll over ~openstack\n> > The OpenStack group is still there, so technically we could still refine\n> > the list to 4-5 candidates and set up a poll there. It\'s not as good as\n> > Condorcet though, and would be more like \"the people who used to vote in\n> > previous names\" than \"the people who should vote now\".\n> >\n> > 4a. Screw popular voting, let\'s do a TC members condorcet\n> > Easy option. Might be seen as TC power landgrab, and it was funny to let\n> > the \"people\" decide.\n> >\n> > 4b. Screw voting, let\'s pick Jekyll and be done with it\n> > A variant of the previous option in case of consensus.\n> >\n> > I\'m open to other suggestions :)\n> >\n> \n> It seems like part of the problem is with the tooling. Do we need this vote\n> to be as secure as PTL or TC elections? Would a tool like survey monkey be\n> easier to work with for this case?\n\nYeah, I\'m kind of thinking the same - I\'d prefer this to be open to the\nwidest possible audience and I\'m not too worried about gaming.\n\nSo, I\'d tend to prefer (1) ... except the IP address limitation is\nunfortunate.\n\nMark.\n\n\n\n','<CADb+p3RBmmOVxB4Z8R58Swe45xTyb1=w5SPp89KzvoSg2KxBCw@mail.gmail.com>',NULL),('<1386864624.19316.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 16:10:24',0,'2013-12-12 16:10:24',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','On Wed, 2013-12-11 at 13:33 +0100, Ji?? Str?nsk? wrote:\n> Hi all,\n> \n> TL;DR: I believe that \"As an infrastructure administrator, Anna wants a \n> CLI for managing the deployment providing the same fundamental features \n> as UI.\" With the planned architecture changes (making tuskar-api thinner \n> and getting rid of proxying to other services), there\'s not an obvious \n> way to achieve that. We need to figure this out. I present a few options \n> and look forward for feedback.\n..\n\n> 1) Make a thicker python-tuskarclient and put the business logic there. \n> Make it consume other python-*clients. (This is an unusual approach \n> though, i\'m not aware of any python-*client that would consume and \n> integrate other python-*clients.)\n> \n> 2) Make a thicker tuskar-api and put the business logic there. (This is \n> the original approach with consuming other services from tuskar-api. The \n> feedback on this approach was mostly negative though.)\n\nFWIW, I think these are the two most plausible options right now.\n\nMy instinct is that tuskar could be a stateless service which merely\ncontains the business logic between the UI/CLI and the various OpenStack\nservices.\n\nThat would be a first (i.e. an OpenStack service which doesn\'t have a\nDB) and it is somewhat hard to justify. I\'d be up for us pushing tuskar\nas a purely client-side library used by the UI/CLI (i.e. 1) as far it\ncan go until we hit actual cases where we need (2).\n\nOne example worth thinking through though - clicking \"deploy my\novercloud\" will generate a Heat template and sent to the Heat API.\n\nThe Heat template will be fairly closely tied to the overcloud images\n(i.e. the actual image contents) we\'re deploying - e.g. the template\nwill have metadata which is specific to what\'s in the images.\n\nWith the UI, you can see that working fine - the user is just using a UI\nthat was deployed with the undercloud.\n\nWith the CLI, it is probably not running on undercloud machines. Perhaps\nyour undercloud was deployed a while ago and you\'ve just installed the\nlatest TripleO client-side CLI from PyPI. With other OpenStack clients\nwe say that newer versions of the CLI should support all/most older\nversions of the REST APIs.\n\nHaving the template generation behind a (stateless) REST API could allow\nus to define an API which expresses \"deploy my overcloud\" and not have\nthe client so tied to a specific undercloud version.\n\nMark.\n\n\n\n','<52A85BB1.7090804@redhat.com>',NULL),('<1386866772-sup-4388@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 08:53:23',-28800,'2013-12-12 16:53:23',NULL,'[openstack-dev] Generic question: Any tips for \'keeping up\'\n	with the mailing lists?','Excerpts from Justin Hammond\'s message of 2013-12-12 08:23:24 -0800:\n> I am a developer who is currently having troubles keeping up with the\n> mailing list due to volume, and my inability to organize it in my client.\n> I am nearly forced to use Outlook 2011 for Mac and I have read and\n> attempted to implement\n> https://wiki.openstack.org/wiki/MailingListEtiquette but it is still a lot\n> to deal with. I read once a topic or wiki page on using X-Topics but I\n> have no idea how to set that in outlook (google has told me that the\n> feature was removed).\n\nJustin I\'m sorry that the volume is catching up with you. I have a highly\noptimized email-list-reading work-flow using sup-mail and a few filters,\nand I still spend 2 hours a day sifting through all of the lists I am on\n(not just openstack lists). It is worth it to keep aware and to avoid\nduplicating efforts, even if it means I have to hit the \"kill this thread\"\nbutton a lot.\n\nWhomever is forcing you to use this broken client, I suggest that you\nexplain to them your situation. It is the reason for your problems. Note\nthat you can just subscribe to the list from a different address than\nyou post from, and configure a good e-mail client like Thunderbird to set\nyour From: address so that you still are representing your organization\nthe way you\'d like to. So if it is just a mail server thing, that is\none way around it.\n\nAlso the setup I use makes use of offlineimap, which can filter things\nfor you, so if you have IMAP access to your inbox, you can use that and\nthen just configure your client for local access (I believe Thunderbird\neven supports a local Maildir mode).\n\nAnyway, you _MUST_ have a threaded email client that quotes well for\nreplies. If not, I\'m afraid it will remain unnecessarily difficult to\nparticipate on this list.\n\n\n','<CECF3F1D.15280%justin.hammond@rackspace.com>',NULL),('<1386867535-sup-3109@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 09:02:58',-28800,'2013-12-12 17:02:58',NULL,'[openstack-dev] [Nova] [Neutron] How do we know a host is ready to\n	have servers scheduled onto it?','I\'ve been chasing quite a few bugs in the TripleO automated bring-up\nlately that have to do with failures because either there are no valid\nhosts ready to have servers scheduled, or there are hosts listed and\nenabled, but they can\'t bind to the network because for whatever reason\nthe L2 agent has not checked in with Neutron yet.\n\nThis is only a problem in the first few minutes of a nova-compute host\'s\nlife. But it is critical for scaling up rapidly, so it is important for\nme to understand how this is supposed to work.\n\nSo I\'m asking, is there a standard way to determine whether or not a\nnova-compute is definitely ready to have things scheduled on it? This\ncan be via an API, or even by observing something on the nova-compute\nhost itself. I just need a definitive signal that \"the compute host is\nready\".\n\n\n',NULL,NULL),('<1386869519-sup-1658@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 09:35:50',-28800,'2013-12-12 17:35:50',NULL,'[openstack-dev] [Nova] [Neutron] How do we know a host is ready\n	to have servers scheduled onto it?','Excerpts from Chris Friesen\'s message of 2013-12-12 09:19:42 -0800:\n> On 12/12/2013 11:02 AM, Clint Byrum wrote:\n> \n> > So I\'m asking, is there a standard way to determine whether or not a\n> > nova-compute is definitely ready to have things scheduled on it? This\n> > can be via an API, or even by observing something on the nova-compute\n> > host itself. I just need a definitive signal that \"the compute host is\n> > ready\".\n> \n> Is it not sufficient that \"nova service-list\" shows the compute service \n> as \"up\"?\n> \n\nI could spin waiting for \"at least one\". Not a bad idea actually. However,\nI suspect that will only handle the situations I\'ve gotten where the\nscheduler returns \"NoValidHost\".\n\nI say that because I think if it shows there, it matches the all hosts\nfilter and will have things scheduled on it. With one compute host I\nget failures after scheduling because neutron has no network segment to\nbind to. That is because the L2 agent on the host has not yet registered\nitself with Neutron.\n\n\n','<52A9F02E.20900@windriver.com>',NULL),('<1386869754-sup-4069@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 09:36:28',-28800,'2013-12-12 17:36:28',NULL,'[openstack-dev] [Nova] [Neutron] How do we know a host is ready\n	to have servers scheduled onto it?','Excerpts from Russell Bryant\'s message of 2013-12-12 09:09:04 -0800:\n> On 12/12/2013 12:02 PM, Clint Byrum wrote:\n> > I\'ve been chasing quite a few bugs in the TripleO automated bring-up\n> > lately that have to do with failures because either there are no valid\n> > hosts ready to have servers scheduled, or there are hosts listed and\n> > enabled, but they can\'t bind to the network because for whatever reason\n> > the L2 agent has not checked in with Neutron yet.\n> > \n> > This is only a problem in the first few minutes of a nova-compute host\'s\n> > life. But it is critical for scaling up rapidly, so it is important for\n> > me to understand how this is supposed to work.\n> > \n> > So I\'m asking, is there a standard way to determine whether or not a\n> > nova-compute is definitely ready to have things scheduled on it? This\n> > can be via an API, or even by observing something on the nova-compute\n> > host itself. I just need a definitive signal that \"the compute host is\n> > ready\".\n> \n> If a nova compute host has registered itself to start having instances\n> scheduled to it, it *should* be ready.  AFAIK, we\'re not doing any\n> network sanity checks on startup, though.\n> \n> We already do some sanity checks on startup.  For example, nova-compute\n> requires that it can talk to nova-conductor.  nova-compute will block on\n> startup until nova-conductor is responding if they happened to be\n> brought up at the same time.\n> \n> We could do something like this with a networking sanity check if\n> someone could define what that check should look like.\n> \n\nCould we ask Neutron if our compute host has an L2 agent yet? That seems\nlike a valid sanity check.\n\n\n','<52A9EDB0.1060002@redhat.com>',NULL),('<1386869877-sup-6356@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 09:47:28',-28800,'2013-12-12 17:47:28',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-12 09:24:13 -0800:\n> Clint, Kevin,\n> \n> Thanks for reassuring me :-) I just wanted to make sure that having direct\n> access from VMs to a single facility is not a dead end in terms of security\n> and extensibility. And since it is not, I agree it is much simpler (and\n> hence better) than hypervisor-dependent design.\n> \n> \n> Then returning to two major suggestions made:\n>  * Salt\n>  * Custom solution specific to our needs\n> \n> The custom solution could be made on top of oslo.messaging. That gives us\n> RPC working on different messaging systems. And that is what we really need\n> - an RPC into guest supporting various transports. What it lacks at the\n> moment is security - it has neither authentication nor ACL.\n> \n\nI bet salt would be super open to modularizing their RPC. Since\noslo.messaging includes ZeroMQ, and is a library now, I see no reason to\navoid opening that subject with our fine friends in the Salt community.\nPerhaps a few of them are even paying attention right here. :)\n\nThe benefit there is that we get everything except the plugins we want\nto write already done. And we could start now with the ZeroMQ-only\nsalt agent if we could at least get an agreement on principle that Salt\nwouldn\'t mind using an abstraction layer for RPC.\n\nThat does make the \"poke a hole out of private networks\" conversation\n_slightly_ more complex. It is one thing to just let ZeroMQ out, another\nto let all of oslo.messaging\'s backends out. But I think in general\nthey\'ll all share the same thing: you want an address+port to be routed\nintelligently out of the private network into something running under\nthe cloud.\n\nNext steps (all can be done in parallel, as all are interdependent):\n\n* Ask Salt if oslo.messaging is a path they\'ll walk with us\n* Experiment with communicating with salt agents from an existing\n  OpenStack service (Savanna, Trove, Heat, etc)\n* Deep-dive into Salt to see if it is feasible\n\nAs I have no cycles for this, I can\'t promise to do any, but I will\ntry to offer assistance if I can.\n\n\n','<CALU-hjGzSZjoMO=+NfwsTgUQipR0T1ZOhGMB5cjPFo3y8haCug@mail.gmail.com>',NULL),('<1386872260-sup-1663@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 10:36:43',-28800,'2013-12-12 18:36:43',NULL,'[openstack-dev] [Nova] [Neutron] How do we know a host is ready\n	to have servers scheduled onto it?','Excerpts from Kyle Mestery\'s message of 2013-12-12 09:53:57 -0800:\n> On Dec 12, 2013, at 11:44 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On 12/12/2013 12:36 PM, Clint Byrum wrote:\n> >> Excerpts from Russell Bryant\'s message of 2013-12-12 09:09:04 -0800:\n> >>> On 12/12/2013 12:02 PM, Clint Byrum wrote:\n> >>>> I\'ve been chasing quite a few bugs in the TripleO automated bring-up\n> >>>> lately that have to do with failures because either there are no valid\n> >>>> hosts ready to have servers scheduled, or there are hosts listed and\n> >>>> enabled, but they can\'t bind to the network because for whatever reason\n> >>>> the L2 agent has not checked in with Neutron yet.\n> >>>> \n> >>>> This is only a problem in the first few minutes of a nova-compute host\'s\n> >>>> life. But it is critical for scaling up rapidly, so it is important for\n> >>>> me to understand how this is supposed to work.\n> >>>> \n> >>>> So I\'m asking, is there a standard way to determine whether or not a\n> >>>> nova-compute is definitely ready to have things scheduled on it? This\n> >>>> can be via an API, or even by observing something on the nova-compute\n> >>>> host itself. I just need a definitive signal that \"the compute host is\n> >>>> ready\".\n> >>> \n> >>> If a nova compute host has registered itself to start having instances\n> >>> scheduled to it, it *should* be ready.  AFAIK, we\'re not doing any\n> >>> network sanity checks on startup, though.\n> >>> \n> >>> We already do some sanity checks on startup.  For example, nova-compute\n> >>> requires that it can talk to nova-conductor.  nova-compute will block on\n> >>> startup until nova-conductor is responding if they happened to be\n> >>> brought up at the same time.\n> >>> \n> >>> We could do something like this with a networking sanity check if\n> >>> someone could define what that check should look like.\n> >>> \n> >> Could we ask Neutron if our compute host has an L2 agent yet? That seems\n> >> like a valid sanity check.\n> > \n> > ++\n> > \n> This makes sense to me as well. Although, not all Neutron plugins have\n> an L2 agent, so I think the check needs to be more generic than that.\n> For example, the OpenDaylight MechanismDriver we have developed\n> doesn\'t need an agent. I also believe the Nicira plugin is agent-less,\n> perhaps there are others as well.\n> \n> And I should note, does this sort of integration also happen with cinder,\n> for example, when we\'re dealing with storage? Any other services which\n> have a requirement on startup around integration with nova as well?\n> \n\nDoes cinder actually have per-compute-host concerns? I admit to being a\nbit cinder-stupid here.\n\nAnyway, it seems to me that any service that is compute-host aware\nshould be able to respond to the compute host whether or not it is a)\naware of it, and b) ready to serve on it.\n\nFor agent-less drivers that is easy, you just always return True. And\nfor drivers with agents, you return false unless you can find an agent\nfor the host.\n\nSo something like:\n\nGET /host/%(compute-host-name)\n\nAnd then in the response include a \"ready\" attribute that would signal\nwhether all networks that should work there, can work there.\n\nAs a first pass, just polling until that is \"ready\" before nova-compute\nenables itself would solve the problems I see (and that I think users\nwould see as a cloud provider scales out compute nodes). Longer term\nwe would also want to aim at having notifications available for this\nso that nova-compute could subscribe to that notification bus and then\ndisable itself if its agent ever goes away.\n\nI opened this bug to track the issue. I suspect there are duplicates of\nit already reported, but would like to start clean to make sure it is\nanalyzed fully and then we can use those other bugs as test cases and\nconfirmation:\n\nhttps://bugs.launchpad.net/nova/+bug/1260440\n\n\n','<D1D86EC7-355C-4FFC-A937-9CC95ED6AB6F@siliconloons.com>',NULL),('<1386873605-sup-3933@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 10:48:25',-28800,'2013-12-12 18:48:25',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Jay Pipes\'s message of 2013-12-12 10:15:13 -0800:\n> On 12/10/2013 03:49 PM, Ian Wells wrote:\n> > On 10 December 2013 20:55, Clint Byrum <clint at fewbar.com\n> > <mailto:clint at fewbar.com>> wrote:\n> >\n> >     If it is just a network API, it works the same for everybody. This\n> >     makes it simpler, and thus easier to scale out independently of compute\n> >     hosts. It is also something we already support and can very easily\n> >     expand\n> >     by just adding a tiny bit of functionality to neutron-metadata-agent.\n> >\n> >     In fact we can even push routes via DHCP to send agent traffic through\n> >     a different neutron-metadata-agent, so I don\'t see any issue where we\n> >     are piling anything on top of an overstressed single resource. We can\n> >     have neutron route this traffic directly to the Heat API which hosts it,\n> >     and that can be load balanced and etc. etc. What is the exact scenario\n> >     you\'re trying to avoid?\n> >\n> >\n> > You may be making even this harder than it needs to be.  You can create\n> > multiple networks and attach machines to multiple networks.  Every point\n> > so far has been \'why don\'t we use <idea> as a backdoor into our VM\n> > without affecting the VM in any other way\' - why can\'t that just be one\n> > more network interface set aside for whatever management  instructions\n> > are appropriate?  And then what needs pushing into Neutron is nothing\n> > more complex than strong port firewalling to prevent the slaves/minions\n> > talking to each other.  If you absolutely must make the communication\n> > come from a system agent and go to a VM, then that can be done by\n> > attaching the system agent to the administrative network - from within\n> > the system agent, which is the thing that needs this, rather than within\n> > Neutron, which doesn\'t really care how you use its networks.  I prefer\n> > solutions where other tools don\'t have to make you a special case.\n> \n> I\'ve read through this email thread with quite a bit of curiosity, and I \n> have to say what Ian says above makes a lot of sense to me. If Neutron \n> can handle the creation of a \"management vNIC\" that has some associated \n> iptables rules governing it that provides a level of security for guest \n> <-> host and guest <-> $OpenStackService, then the transport problem \n> domain is essentially solved, and Neutron can be happily ignorant (as it \n> should be) of any guest agent communication with anything else.\n> \n\nIndeed I think it could work, however I think the NIC is unnecessary.\n\nSeems likely even with a second NIC that said address will be something\nlike 169.254.169.254 (or the ipv6 equivalent?).\n\nIf we want to attach that network as a second NIC instead of pushing a\nroute to it via DHCP, that is fine. But I don\'t think it actually gains\nmuch, and the current neutron-metadata-agent already facilitates the\nconversation between private guests and 169.254.169.254. We just need to\nmake sure we can forward more than port 80 through that.\n\n\n','<52A9FD31.7090208@gmail.com>',NULL),('<1386882971-sup-9406@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 13:19:22',-28800,'2013-12-12 21:19:22',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Steven Dake\'s message of 2013-12-12 12:32:55 -0800:\n> On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:\n> > Clint, Kevin,\n> >\n> > Thanks for reassuring me :-) I just wanted to make sure that having \n> > direct access from VMs to a single facility is not a dead end in terms \n> > of security and extensibility. And since it is not, I agree it is much \n> > simpler (and hence better) than hypervisor-dependent design.\n> >\n> >\n> > Then returning to two major suggestions made:\n> >  * Salt\n> >  * Custom solution specific to our needs\n> >\n> > The custom solution could be made on top of oslo.messaging. That gives \n> > us RPC working on different messaging systems. And that is what we \n> > really need - an RPC into guest supporting various transports. What it \n> > lacks at the moment is security - it has neither authentication nor ACL.\n> >\n> > Salt also provides RPC service, but it has a couple of disadvantages: \n> > it is tightly coupled with ZeroMQ and it needs a server process to \n> > run. A single transport option (ZeroMQ) is a limitation we really want \n> > to avoid. OpenStack could be deployed with various messaging \n> > providers, and we can\'t limit the choice to a single option in the \n> > guest agent. Though it could be changed in the future, it is an \n> > obstacle to consider.\n> >\n> > Running yet another server process within OpenStack, as it was already \n> > pointed out, is expensive. It means another server to deploy and take \n> > care of, +1 to overall OpenStack complexity. And it does not look it \n> > could be fixed any time soon.\n> >\n> > For given reasons I give favor to an agent based on oslo.messaging.\n> >\n> \n> An agent based on oslo.messaging is a potential security attack vector \n> and a possible scalability problem.  We do not want the guest agents \n> communicating over the same RPC servers as the rest of OpenStack\n\nI don\'t think we\'re talking about agents talking to the exact same\nRabbitMQ/Qpid/etc. bus that things under the cloud are talking to. That\nwould definitely raise some eyebrows. No doubt it will be in the realm\nof possibility if deployers decide to do that, but so is letting your\ndatabase server sit on the same flat network as your guests.\n\nI have a hard time seeing how using the same library is a security\nrisk though.\n\n\n','<52AA1D77.8040406@redhat.com>',NULL),('<1386884397.072212175@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 15:39:57',-21600,'2013-12-12 21:39:57',NULL,'[openstack-dev] [Solum] Using Zuul in the Git-pull blueprint','We followed on the Zuul question in this week\'s git-integration working group meeting.\n\nmordred has created an etherpad with a high-level description of Zuul and how it might\nfit with Solum\'t git integration workflow\n\nhttps://etherpad.openstack.org/p/ZuulSolum\n\nThe working group seemed to be coming to the consensus that we want to use a single workflow\nengine, as far as possible, for all of Solum\'s workflow needs.\nThis brought up the question about, what are really Solum\'s workflow requirements. \n\nAt a high-level, I think that Solum has three different kinds of workflows.\n\n1) Workflow around getting user code into Solum\n   - This is the git integration piece being worked out in the git-integration\n     working group.\n\n2) Workflow around creating language pack(s).\n   - The main workflow requirement here involves ability to run tests before creating a language pack.\n     There was some discussion in language-pack working group about this requirement.\n\n3) Workflow around deploying created language pack(s) in order to instantiate an assembly.\n   - The deployment may potentially contain several steps, some of which may be long running, such as\n   populating a database. Further, there may be a need to checkpoint intermediate steps\n   and retry the workflow from the failed point.\n\n\nmordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum)\nWe want to know if #2 and #3 can also be achieved by Zuul.\nIf not, we want to know what are the available options.\n\nmordred, thanks for the etherpad; looking forward to the digram :)\n\n\nthanks,\ndevkulkarni\n\n\n-----Original Message-----\nFrom: \"Roshan Agrawal\" <roshan.agrawal at RACKSPACE.COM>\nSent: Monday, December 9, 2013 10:57am\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n\n\n> -----Original Message-----\n> From: Krishna Raman [mailto:kraman at gmail.com]\n> Sent: Sunday, December 08, 2013 11:24 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n> \n> Hi all,\n> \n> We had a very good meeting last week around the git-pull blueprint. During\n> the discussion, Monty suggested using Zuul to manage the git repository\n> access and workflow.\n> While he is working on sending the group a diagram and description of what\n> he has in mind, I had a couple of other questions which I am hoping the\n> extended group will be able to answer.\n> \n> 1) Zuul is currently an infrastructure project.\n> 	- Is there anything that prevents us from using it in Solum?\n> 	- Does it need to be moved to a normal OpenStack project?\n> \n> 2) Zuul provides a sort of workflow engine. This workflow engine could\n> potentially be used to initiate and manage: API Post -> git flow -> lang pack\n> flow.\n> 	- Have there been any discussion after the F2F where we have\n> discussed using some other workflow engine?\n\nThere hasn\'t been further discussion since F2F.\nMost of the processes in Solum will really be customizable workflows, and use of a generic workflow engine is definitely worth discussing. We may still use to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow needs beyond that. \n\n> 	- Is Zuul\'s engine generic enough to be used in Solum? (Hoping\n> Monty can help with this one)\n> 		- Perhaps only use it to manage the API post -> git flow\n> stages?\n> \n> Thanks\n> -Krishna\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<9C1B7917DE16F44D855E72328D666ED1231E4A0E@ORD1EXD03.RACKSPACE.CORP>',NULL),('<1386905732.44385.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-13 11:35:32',28800,'2013-12-13 03:35:32',NULL,'[Openstack] cannot create container','I had installed swift using linkhttp://docs.openstack.org/developer/swift/development_saio.html\nI am facing problem in creating container.\ncurl -v -H \'X-Auth-Token: AUTH_tk850294e7f80b4ca09d9acda278466391\' -X PUThttp://127.0.0.1:8080/v1/AUTH_prag2648/photos?http://paste.openstack.org/show/54495/\nI am also sending a copy of /var/log/syslog?http://paste.openstack.org/show/54930/\nPlease help me in this regard.\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131213/2ac88f6c/attachment.html>\n\n',NULL,NULL),('<1386937466.19316.96.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 12:24:26',0,'2013-12-13 12:24:26',NULL,'[openstack-dev] Announcing Fuel','Hi Mike,\n\nOn Thu, 2013-12-12 at 18:31 +0400, Mike Scherbakov wrote:\n> Folks,\n> \n> Most of you by now have heard of Fuel, which we?ve been working on as a\n> related OpenStack project for a period of time -\n> <https://github.com/stackforge/fuel-main>see https://launchpad.net/fuel and\n> https://wiki.openstack.org/wiki/Fuel. The aim of the project is to provide\n> a distribution agnostic and plug-in agnostic engine for preparing,\n> configuring and ultimately deploying various ?flavors? of OpenStack in\n> production. We?ve also used Fuel in most of our customer engagements to\n> stand up an OpenStack cloud.\n> \n>  At the same time, we?ve been actively involved with TripleO, which we\n> believe to be a great effort in simplifying deployment, operations, scaling\n> (and eventually upgrading) of OpenStack.\n> \n> Per our discussions with core TripleO team during the Icehouse summit,\n> we?ve uncovered that while there are certain areas of collision, most of\n> the functionality in TripleO and Fuel is complementary. In general, Fuel\n> helps solve many problems around ?step zero? of setting up an OpenStack\n> environment, such as auto-discovery and inventory of bare metal hardware,\n> pre-deployment & post-deployment environment  checks, and wizard-driven\n> web-based configuration of OpenStack flavors. At the same time, TripleO has\n> made great progress in deployment, scaling and operations (with Tuskar).\n> \n> We?d like to propose an effort for community consideration to bring the two\n> initiatives closer together to eventually arrive at a distribution\n> agnostic, community supported framework covering the entire spectrum of\n> deployment, management and upgrades; from ?step zero? to a fully functional\n> and manageable production-grade OpenStack environment.\n\nGreat!\n\n> To that effect, we propose the following high-level roadmap plans for this\n> effort:\n> \n> \n>    -\n> \n>    Keep and continue to evolve bare-metal discovery and inventory module of\n>    Fuel, tightly integrating it with Ironic.\n>    -\n> \n>    Keep and continue to evolve Fuel?s wizard-driven OpenStack flavor\n>    configurator. In the near term we?ll work with the UX team to unify the\n>    user experience across Fuel, TripleO and Tuskar. We are also thinking about\n>    leveraging diskimagebuilder.\n>    -\n> \n>    Continue to evolve Fuel?s pre-deployment (DHCP, L2 connectivity checks)\n>    and post-deployment validation checks in collaboration with the TripleO and\n>    Tempest teams.\n>    -\n> \n>    Eventually replace Fuel?s current orchestration engine\n>    https://github.com/stackforge/fuel-astute/ with Heat\n\nThis all sounds great to me.\n\nI\'d especially like to see some more in-depth discussion about how your\nideas for a configuration wizard like this:\n\n  http://software.mirantis.com/wp-content/uploads/2013/10/New_Fuel_3.2_Wizard_1-of-3.png\n  http://software.mirantis.com/wp-content/uploads/2013/10/New_Fuel_3.2_Wizard_3-of-3.png\n\nfits into the UX discussions around initial deployment with TripleO\ngoing on, for example:\n\n  http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/\n  http://lists.openstack.org/pipermail/openstack-dev/2013-December/thread.html#21388\n  http://lists.openstack.org/pipermail/openstack-dev/2013-December/thread.html#20944\n\nThanks!\nMark.\n\n\n\n','<CAKYN3rPGnkCGZkPMYjiuh1p8wyrcD9rRpvj4BoaAMt1C+iS9qw@mail.gmail.com>',NULL),('<1386946812-sup-4483@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 07:03:24',-28800,'2013-12-13 15:03:24',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Sylvain Bauza\'s message of 2013-12-12 23:43:40 -0800:\n> Why the notifications couldn\'t be handled by Marconi ?\n> \n> That would be up to Marconi\'s team to handle security issues while it is\n> part of their mission statement to deliver a messaging service in between\n> VMs.\n\nFantastic point. :) Though we don\'t want communication between VMs,\nwe want communication between VMs and the cloud provider. Still it does\nfeel like Marconi would facilitate this.\n\nI\'m not up to speed on Marconi though, is it all HTTP for the\ncommunication? If so how is the overhead of polling addressed?\n\nWe could always teach Salt to speak over Marconi as easily as we could\nteach Salt to speak oslo.messaging. That would also make Salt more useful\nin any OpenStack cloud that had Marconi. :)\n\n\n','<CANWE-CnBXRnsLhc15wL-X=dfZrrL7poW9CSDx6thxQSsp2=9Qw@mail.gmail.com>',NULL),('<1386947065-sup-7761@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 07:10:05',-28800,'2013-12-13 15:10:05',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Scott Moser\'s message of 2013-12-13 06:28:08 -0800:\n> On Tue, 10 Dec 2013, Ian Wells wrote:\n> \n> > On 10 December 2013 20:55, Clint Byrum <clint at fewbar.com> wrote:\n> >\n> > > If it is just a network API, it works the same for everybody. This\n> > > makes it simpler, and thus easier to scale out independently of compute\n> > > hosts. It is also something we already support and can very easily expand\n> > > by just adding a tiny bit of functionality to neutron-metadata-agent.\n> > >\n> > > In fact we can even push routes via DHCP to send agent traffic through\n> > > a different neutron-metadata-agent, so I don\'t see any issue where we\n> > > are piling anything on top of an overstressed single resource. We can\n> > > have neutron route this traffic directly to the Heat API which hosts it,\n> > > and that can be load balanced and etc. etc. What is the exact scenario\n> > > you\'re trying to avoid?\n> > >\n> >\n> > You may be making even this harder than it needs to be.  You can create\n> > multiple networks and attach machines to multiple networks.  Every point so\n> > far has been \'why don\'t we use <idea> as a backdoor into our VM without\n> > affecting the VM in any other way\' - why can\'t that just be one more\n> > network interface set aside for whatever management  instructions are\n> > appropriate?  And then what needs pushing into Neutron is nothing more\n> > complex than strong port firewalling to prevent the slaves/minions talking\n> > to each other.  If you absolutely must make the communication come from a\n> \n> +1\n> \n> tcp/ip works *really* well as a communication mechanism.  I\'m planning on\n> using it to send this email.\n> \n> For controlled guests, simply don\'t break your networking.  Anything that\n> could break networking can break /dev/<hypervisor-socket> also.\n> \n\nWho discussed breaking networking?\n\n> Fwiw, we already have an extremely functional \"agent\" in just about every\n> [linux] node in sshd.  Its capable of marshalling just about anything in\n> and out of the node. (note, i fully realize there are good reasons for\n> more specific agent, lots of them exist).\n> \n\nThis was already covered way back in the thread. sshd is a backdoor\nagent, and thus undesirable for this purpose. Locking it down is more\neffort than adopting an agent which is meant to be limited to specific\ntasks.\n\nAlso SSH is a push agent, so Savanna/Heat/Trove would have to find the\nVM, and reach into it to do things. A pull agent scales well because you\nonly have to tell the nodes where to pull things from, and then you can\nadd more things to pull from behind that endpoint without having to\nupdate the nodes.\n\n> I\'ve really never understood \"we don\'t want to rely on networking as a\n> transport\".\n> \n\nYou may have gone to plaid with this one. Not sure what you mean. AFAICT\nthe direct-to-hypervisor tricks are not exactly popular in this thread.\nWere you referring to something else?\n\n\n','<alpine.DEB.2.02.1312130923390.4340@brickies>',NULL),('<1386951911-sup-7365@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 08:39:58',-28800,'2013-12-13 16:39:58',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Alessandro Pilotti\'s message of 2013-12-13 07:13:01 -0800:\n> Hi guys,\n> \n> This seems to become a pretty long thread with quite a lot of ideas. What do you think about setting up a meeting on IRC to talk about what direction to take?\n> IMO this has the potential of becoming a completely separated project to be hosted on stackforge or similar.\n> \n> Generally speaking, we already use Cloudbase-Init, which beside being the de facto standard Windows \"Cloud-Init type feature? (Apache 2 licensed) \n> has been recently used as a base to provide the same functionality on FreeBSD.\n> \n> For reference: https://github.com/cloudbase/cloudbase-init and http://www.cloudbase.it/cloud-init-for-windows-instances/\n> \n> We?re seriously thinking if we should transform Cloudbase-init into an agent or if we should keep it on line with the current ?init only, let the guest to the rest? approach which fits pretty\n> well with the most common deployment approaches (Heat, Puppet / Chef, Salt, etc). Last time I spoke with Scott about this agent stuff for cloud-init, the general intention was\n> to keep the init approach as well (please correct me if I missed something in the meantime).\n> \n> The limitations that we see, independently from which direction and tool will be adopted for the agent, are mainly in the metadata services and the way OpenStack users employ them to \n> communicate with Nova, Heat and the rest of the pack as orchestration requirements complexity increases:\n> \n\nHi, Allessandro. Really interesting thoughts. Most of what you have\ndescribed that is not about agent transport is what we discussed\nat the Icehouse summit under the topic of the hot-software-config\nblueprint. There is definitely a need for better workflow integration\nin Heat, and that work is happening now.\n\n> 1) We need a way to post back small amounts of data (e.g. like we already do for the encrypted Windows password) for status updates,\n> so that the users know how things are going and can be properly notified in case of post-boot errors. This might be irrelevant as long as you just create a user and deploy some SSH keys,\n> but becomes very important for most orchestration templates.\n>\n\nHeat already has this via wait conditions. hot-software-config will\nimprove upon this. I believe once a unified guest agent protocol is\nagreed upon we will make Heat use that for wait condition signalling.\n\n> 2) The HTTP metadata service accessible from the guest with its magic number is IMO quite far from an optimal solution. Since every hypervisor commonly \n> used in OpenStack (e.g. KVM, XenServer, Hyper-V, ESXi) provides guest / host communication services, we could define a common abstraction layer which will \n> include a guest side (to be included in cloud-init, cloudbase-init, etc) and a hypervisor side, to be implemented for each hypervisor and included in the related Nova drivers.\n> This has already been proposed / implemented in various third party scenarios, but never under the OpenStack umbrella for multiple hypervisors.\n> \n> Metadata info can be at that point retrieved and posted by the Nova driver in a secure way and proxied to / from the guest whithout needing to expose the metadata \n> service to the guest itself. This would also simplify Neutron, as we could get rid of the complexity of the Neutron metadata proxy. \n> \n\nThe neutron metadata proxy is actually relatively simple. Have a look at\nit. The basic way it works in pseudo code is:\n\nport = lookup_requesting_ip_port(remote_ip)\ninstance_id = lookup_port_instance_id(port)\nresponse = forward_and_sign_request_to_nova(REQUEST, instance_id, conf.nova_metadata_ip)\nreturn response\n\nFurthermore, if we have to embrace some complexity, I would rather do so\ninside Neutron than in an agent that users must install and make work\non every guest OS.\n\nThe dumber an agent is, the better it will scale and more resilient it\nwill be. I would credit this principle with the success of cloud-init\n(sorry, you know I love you Scott! ;). What we\'re talking about now is\nhaving an equally dumb, but differently focused agent.\n\n\n','<80918119-CD17-4B8A-988F-EB8497AFBAA2@cloudbasesolutions.com>',NULL),('<1386952832-sup-2172@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 08:46:55',-28800,'2013-12-13 16:46:55',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Sergey Lukjanov\'s message of 2013-12-13 07:46:34 -0800:\n> Hi Alessandro,\n> \n> it\'s a good idea to setup an IRC meeting for the unified agents. IMO it\'ll\n> seriously speedup discussion. The first one could be used to determine the\n> correct direction, then we can use them to discuss details and coordinate\n> efforts, it will be necessary regardless of the approach.\n> \n\nI\'d like for those who are going to do the actual work to stand up and\nbe counted before an IRC meeting. This is starting to feel bike-sheddy\nand the answer to bike-shedding is not more meetings.\n\nI am keenly interested in this, but have limited cycles to spare for it\nat this time. So I do not count myself as one of those people.\n\nI believe that a few individuals who are involved with already working\nspecialized agents will be doing the work to consolidate them and to fix\nthe bug that they all share (Heat shares this too) which is that private\nnetworks cannot reach their respective agent endpoints. I think those\nindividuals should review the original spec given the new information,\nrevise it, and present it here in a new thread. If there are enough of\nthem that they feel they should have a meeting, I suggest they organize\none. But I do not think we need more discussion on a broad scale.\n\nSpeaking of that, before I run out and report a bug that affects\nSavanna Heat and Trove, is there already a bug titled something like\n\"Guests cannot reach [Heat/Savanna/Trove] endpoints from inside private\nnetworks.\" ?\n\n(BTW, paint it yellow!)\n\n\n','<CA+GZd7_ERTvq=8R+2mCw9C_=9Cv50qxnwSOg39nd2Oy4c2Lh-w@mail.gmail.com>',NULL),('<1386953812.61292253@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 10:56:52',-21600,'2013-12-13 16:56:52',NULL,'[openstack-dev] [Solum] Using Zuul in the Git-pull blueprint','-----Original Message-----\nFrom: \"Krishna Raman\" <kraman at gmail.com>\nSent: Friday, December 13, 2013 9:44am\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n\nOn Dec 12, 2013, at 1:39 PM, devdatta kulkarni <devdatta.kulkarni at rackspace.com> wrote:\n\n> We followed on the Zuul question in this week\'s git-integration working group meeting.\n> \n> mordred has created an etherpad with a high-level description of Zuul and how it might\n> fit with Solum\'t git integration workflow\n> \n> https://etherpad.openstack.org/p/ZuulSolum\n> \n> The working group seemed to be coming to the consensus that we want to use a single workflow\n> engine, as far as possible, for all of Solum\'s workflow needs.\n> This brought up the question about, what are really Solum\'s workflow requirements. \n\nHi\n\nI had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group.\nI have also included answers to the questions below.\n\n> \n> At a high-level, I think that Solum has three different kinds of workflows.\n> \n> 1) Workflow around getting user code into Solum\n>   - This is the git integration piece being worked out in the git-integration\n>     working group.\n\nThis is possible using the Zuul workflows. Would potentially require a little work in Zuul.\n\n> \n> 2) Workflow around creating language pack(s).\n>   - The main workflow requirement here involves ability to run tests before creating a language pack.\n>     There was some discussion in language-pack working group about this requirement.\n\nThis is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows\nthat could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git \nand a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc.\nThis would be possible through Zuul without having to reinvent it on the other workflow engine.\n\n> \n> 3) Workflow around deploying created language pack(s) in order to instantiate an assembly.\n>   - The deployment may potentially contain several steps, some of which may be long running, such as\n>   populating a database. Further, there may be a need to checkpoint intermediate steps\n>   and retry the workflow from the failed point.\n\nThis is probably not a very good fit for Zuul. It can handle simple workflow but won?t be able to do the\ncomplex checkpointing, rollback, retry logic etc.\n\n> \n> \n> mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum)\n> We want to know if #2 and #3 can also be achieved by Zuul.\n> If not, we want to know what are the available options.\n> \n> mordred, thanks for the etherpad; looking forward to the digram :)\n\n\nZuul is workflow engine capable of running simple workflows. It is probably not suitable for all of Solum but would\nmanage the source -> DU flow quite nicely. Initially my thoughts were that I wanted to avoid having 2 workflow\nengines in Solum but there is another way to look at it?\n\nDuring out F2F, we had said that we should have a Solum API where we could just post DU images. This would\nallow someone to build the DU outside Solum and just provide it. We could use this same API as a clean interface to\nseparated out the DU build flow from the DU deploy flow. Once this is done, the DU build flow (#1, #2 above)\ncould be cleanly handled by Zuul and the DU deploy flow by whatever complex engine the rest of Solum would\nuse.\n\n>> I think this makes sense.\n\nIf I were to tie this discussion back to the various working groups and blueprints, I think\nthe git-integration and language-pack working groups are targeting the \"DU build flow\" (#1 and #2).\nOn the other hand, the work being done as part of \'specify-lang-pack\' blueprint and \'pluggable-template-generation\'\nare targeting parts of #3. There would be additional blueprints for other aspects of #3.\n\n- Devdatta\n\n\nThis approach has a few advantages:\n	* Re-uses what Openstack already uses but its build & CI process (and potentially makes it better)\n	* Allows operations who deploy Solum to customize their build process without having to change Solum\n	* Allows us to leverage the Zuul/OpenStack-infra team to help us solve the DU build flow instead of having \n	  to go alone\n\n?Krishna\n\n> \n> \n> thanks,\n> devkulkarni\n> \n> \n> -----Original Message-----\n> From: \"Roshan Agrawal\" <roshan.agrawal at RACKSPACE.COM>\n> Sent: Monday, December 9, 2013 10:57am\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n> \n> \n>> -----Original Message-----\n>> From: Krishna Raman [mailto:kraman at gmail.com]\n>> Sent: Sunday, December 08, 2013 11:24 PM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint\n>> \n>> Hi all,\n>> \n>> We had a very good meeting last week around the git-pull blueprint. During\n>> the discussion, Monty suggested using Zuul to manage the git repository\n>> access and workflow.\n>> While he is working on sending the group a diagram and description of what\n>> he has in mind, I had a couple of other questions which I am hoping the\n>> extended group will be able to answer.\n>> \n>> 1) Zuul is currently an infrastructure project.\n>> 	- Is there anything that prevents us from using it in Solum?\n>> 	- Does it need to be moved to a normal OpenStack project?\n>> \n>> 2) Zuul provides a sort of workflow engine. This workflow engine could\n>> potentially be used to initiate and manage: API Post -> git flow -> lang pack\n>> flow.\n>> 	- Have there been any discussion after the F2F where we have\n>> discussed using some other workflow engine?\n> \n> There hasn\'t been further discussion since F2F.\n> Most of the processes in Solum will really be customizable workflows, and use of a generic workflow engine is definitely worth discussing. We may still use to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow needs beyond that. \n> \n>> 	- Is Zuul\'s engine generic enough to be used in Solum? (Hoping\n>> Monty can help with this one)\n>> 		- Perhaps only use it to manage the API post -> git flow\n>> stages?\n>> \n>> Thanks\n>> -Krishna\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<0278CFEE-057E-4FD4-A1C9-089D07703DE5@gmail.com>',NULL),('<1386963742-sup-634@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 11:46:34',-28800,'2013-12-13 19:46:34',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Fox, Kevin M\'s message of 2013-12-13 11:32:01 -0800:\n> Hmm.. so If I understand right, the concern you started is something like:\n>  * You start up a vm\n>  * You make it available to your users to ssh into\n>  * They could grab the machine\'s metadata\n> \n> I hadn\'t thought about that use case, but that does sound like it would be a problem.\n> \n> Ok, so... the problem there is that you need a secrets passed to the vm but the network trick isn\'t secure enough to pass the secret, hence the config drive like trick since only root/admin can read the data.\n> \n> Now, that does not sound like it excludes the possibility of using the metadata server idea in combination with cloud drive to make things secure. You could use cloud drive to pass a cert, and then have the metadata server require that cert in order to ensure only the vm itself can pull any additional metadata.\n> \n> The unified guest agent could use the same cert/server to establish trust too.\n> \n> Does that address the issue?\n> \n\nThere is still no need for cloud drive.\n\ncloud-init can drop the route to the metadata network once it has fetched\nthis data, but before it has enabled SSHD by generating host keys.\n\nOr you can just treat everything in that metadata as compromised already,\nand just use a nonce to create a trust relationship with newly fetched\nsecrets stored as root on the box.\n\nThis is already a solved problem.\n\n\n','<81A22C12505EF7419E792D791BC28B3C013C667BED71@EMAIL05.pnl.gov>',NULL),('<1386964496.13534.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-14 03:54:56',28800,'2013-12-13 19:54:56',NULL,'[Openstack] can I access the data stored on swift through a web\n	browser','hello,\nI installed swift on my machine.?\nI store some data on it using swift command line.?\nNow, I want to know:?\ncan I access the data stored on swift through a web browser?\n\n----------\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131214/08f01beb/attachment.html>\n\n',NULL,NULL),('<1386965449-sup-4406@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 12:13:18',-28800,'2013-12-13 20:13:18',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-13 12:01:01 -0800:\n> Still, what about one more server process users will have to run? I see\n> unified agent as library which can be easily adopted by both exiting and\n> new OpenStack projects. The need to configure and maintain Salt server\n> process is big burden for end users. That idea will definitely scare off\n> adoption of the agent. And at the same time what are the gains of having\n> that server process? I don\'t really see to many of them.\n> \n\nThe Salt devs already mentioned that we can more or less just import\nsalt\'s master code and run that inside the existing server processes. So\nSavanna would have a salt master capability, and so would Heat Engine.\n\nIf it isn\'t eventlet friendly we can just fork it off and run it as its\nown child. Still better than inventing our own.\n\n\n','<CALU-hjEQPn7UC5dD0zXvPBaj_BK0qox6atjcjt=gWfUx5_tTGg@mail.gmail.com>',NULL),('<1386966763.2137.2.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 15:32:43',-18000,'2013-12-13 20:32:43',NULL,'[openstack-dev] [Solum] Language pack attributes schema','On Mon, 2013-12-09 at 13:02 -0800, Georgy Okrokvertskhov wrote:\n> Hi,\n> \n> \n> As a part of Language pack workgroup session we created an etherpad\n> for language pack attributes definition. Please find a first draft of\n> language pack attributes\n> here: https://etherpad.openstack.org/p/Solum-Language-pack-json-format\n> \n> \n> We have identified a minimal list of attributes which should be\n> supported by language pack API.\n> \n> Please, provide your feedback and\\or ideas in this etherpad. Once it\n> is reviewed we can use this as a basis for language packs in PoC.\n\nHi Georgy,\n\nWould it be possible to use YAML instead of JSON as the default format\nfor these description documents? I ask this only because HOT is YAML,\nand it would be good to align with Heat in that manner since much of\nwhat Solum aims to do is construct HOT templates, yes?\n\nBest,\n-jay\n\n\n\n\n','<CAG_6_okrguCK5nYrCMmge+XR64AHx5sbvsJwtJTKsakDnZAMiA@mail.gmail.com>',NULL),('<1386967803.2137.11.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 15:50:03',-18000,'2013-12-13 20:50:03',NULL,'[openstack-dev] [Nova][TripleO] Nested resources','On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote:\n> On 6 December 2013 14:11, Fox, Kevin M <kevin.fox at pnnl.gov> wrote:\n> > I think the security issue can be handled by not actually giving the underlying resource to the user in the first place.\n> >\n> > So, for example, if I wanted a bare metal node\'s worth of resource for my own containering, I\'d ask for a bare metal node and use a \"blessed\" image that contains docker+nova bits that would hook back to the cloud. I wouldn\'t be able to login to it, but containers started on it would be able to access my tenant\'s networks. All access to it would have to be through nova suballocations. The bare resource would count against my quotas, but nothing run under it.\n> >\n> > Come to think of it, this sounds somewhat similar to what is planned for Neutron service vm\'s. They count against the user\'s quota on one level but not all access is directly given to the user. Maybe some of the same implementation bits could be used.\n> \n> This is a super interesting discussion - thanks for kicking it off.\n\nIndeed. A very enlightening conversation :)\n\n> I think it would be fantastic to be able to use containers for\n> deploying the cloud rather than full images while still running\n> entirely OpenStack control up and down the stack.\n> \n> Briefly, what we need to be able to do that is:\n> \n>  - the ability to bring up an all in one node with everything on it to\n> \'seed\' the environment.\n>     - we currently do that by building a disk image, and manually\n> running virsh to start it\n\nIs this set in stone? In other words, is it a given that in order to\ncreate the seed undercloud, that you need to use DIB to do it? Instead\nof an image that is pre-constructed and virsh\'d into, what about\nconstructing one or more LXC templates, starting a set of LXC containers\nfor the various undercloud support services (db, mq, OpenStack services,\netc), installing those support services using\nconfig-mgmt-flavor-du-jour? Has this been considered as an option to\nDIB? (sorry if I\'m late to the discussion!) :)\n\n>  - the ability to reboot a machine *with no other machines running* -\n> we need to be able to power off and on a datacentre - and have the\n> containers on it come up correctly configured, networking working,\n> running etc.\n\nI think a container-based seed would work just fine here, yes?\n\n>  - we explicitly want to be just using OpenStack APIs for all the\n> deployment operations after the seed is up; so no direct use of lxc or\n> docker or whathaveyou.\n\nAgreed. I\'m talking about changing the thinking of the construction of\nthe seed undercloud, not the overcloud.\n\nBest,\n-jay\n\n\n\n','<CAJ3HoZ3wnREhdmAXi9Xw0UN4mE6xays2g0u-=8SmxkRJmmAfjw@mail.gmail.com>',NULL),('<1386969268.2137.19.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 16:14:28',-18000,'2013-12-13 21:14:28',NULL,'[openstack-dev] [keystone][heat] ec2tokens,\n v3 credentials and request signing','On Tue, 2013-12-10 at 15:13 +0000, Steven Hardy wrote:\n> I\'m just thinking it would be really great (from a user-of-keystone\n> perspective) if we could avoid further fragmentation and just have one type\n> of shared secret (a keystone token), which can be configured flexibly\n> enough to satisfy the various use-cases?\n\nAmen. No offense to those Keystone contributors who enjoy reading arcane\nacademic texts and RFCs about x.509, Kerberos, and PKI, but *users and\ndeployers* of OpenStack (and therefore users of Keystone) don\'t give a\nhoot about any of that stuff, nor should deployers and users *have to\nknow* about the arcane underbelly of security semantics in order to use\nOpenStack.\n\nAll deployers want is a simple, easy-to-understand authentication\nmechanism that *seamlessly* integrates with other OpenStack projects.\n\nAWS authentication works because it\'s simple and does its job without\nmaking life unnecessarily difficult for its users.\n\nBest,\n-jay\n\n\n\n','<20131210151346.GC5227@t430slt.redhat.com>',NULL),('<1386970473.2137.23.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 16:34:33',-18000,'2013-12-13 21:34:33',NULL,'[openstack-dev] [Nova] [Neutron] How do we know a host is ready\n to have servers scheduled onto it?','On Thu, 2013-12-12 at 21:01 +0000, Joshua Harlow wrote:\n> Maybe time to revive something like:\n> \n> https://review.openstack.org/#/c/12759/\n> \n> \n> From experience, all sites (and those internal to yahoo) provide a /status\n> (or equivalent) that is used for all sorts of things (from basic\n> load-balancing up/down) to other things like actually introspecting the\n> state of the process (or to get basics about what the process is doing).\n> Typically this is not exposed to the public (its why\n> http://www.yahoo.com/status works for me but not for u). It seems like\n> something like that could help (but of course not completely solve) the\n> type of response jay mentioned.\n\n>From reading through the review above, it looks like markmc had two main\nobjections:\n\na) The status/healthcheck middleware should not be in Oslo unless all\nOpenStack projects have an interest in using it\n\nb) Standardizing on a HEAD request to the root resource seemed like a\nbetter idea\n\nMark, has any of your thinking changed on the above? Regarding using\nHEAD, that limits the returned result to HTTP headers, versus perhaps\nreturning a list of dependent services that this service is waiting on\nin order to move into a \"healthy\" status.\n\nPersonally, I believe OpenStack has moved into a phase where having this\nkind of standardized status/healthcheck middleware would be very useful.\n\nBest,\n-jay\n\n\n\n','<CECF6371.4FF05%harlowja@yahoo-inc.com>',NULL),('<1386970659.2137.25.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 16:37:39',-18000,'2013-12-13 21:37:39',NULL,'[openstack-dev] [Nova] Support for Pecan in Nova','On Fri, 2013-12-13 at 12:52 +1030, Christopher Yeoh wrote:\n> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n<snip>\n>         \n>         +1. I agree with most of what Mike says above. The idea that\n>         there are core \"extensions\" in Nova\'s v3 API doesn\'t make a\n>         whole lot of sense to me.\n> \n> So would it help if we used the term \"plugin\" to talk about the\n> framework that the API is implemented with,\n> and extensions when talking about things which extend the core API? So\n> the whole of the API is implemented\n> using plugins, while the core plugins are not considered to be\n> extensions.\n\nYeah, that makes more sense :)\n\nBest,\n-jay\n\n\n\n\n','<CANCY3ee_iuZFkk0XPdoUN-29iU3NejR==F9MhmDtFWUgXdQhbQ@mail.gmail.com>',NULL),('<1386976903.2137.37.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 18:21:43',-18000,'2013-12-13 23:21:43',NULL,'[openstack-dev] [TripleO][Tuskar] Terminology','On Wed, 2013-12-11 at 14:15 -0500, Tzu-Mainn Chen wrote:\n> Hi,\n> \n> I\'m trying to clarify the terminology being used for Tuskar, which may be helpful so that we\'re sure\n> that we\'re all talking about the same thing :)  I\'m copying responses from the requirements thread\n> and combining them with current requirements to try and create a unified view.  Hopefully, we can come\n> to a reasonably rapid consensus on any desired changes; once that\'s done, the requirements can be\n> updated.\n> \n> * NODE a physical general purpose machine capable of running in many roles. Some nodes may have hardware layout that is particularly\n>        useful for a given role.\n\nMust a node be a physical machine? What about a container?\n\n>      * ROLE - a specific workload we want to map onto one or more nodes. Examples include \'undercloud control plane\', \'overcloud control\n>        plane\', \'overcloud storage\', \'overcloud compute\' etc.\n\nOK, so \"role\" has implications in both Keystone-land as well as various\nconfiguration management systems (Chef, Ansible). What about just using\nthe term \"workload\"?\n\n>          * MANAGEMENT NODE - a node that has been mapped with an undercloud role\n>          * SERVICE NODE - a node that has been mapped with an overcloud role\n\nI like the above breakdowns, but instead of \"mapped with an undercloud\nrole\", I\'d say \"runs an undercloud workload\" or similar.\n\n>             * COMPUTE NODE - a service node that has been mapped to an overcloud compute role\n>             * CONTROLLER NODE - a service node that has been mapped to an overcloud controller role\n>             * OBJECT STORAGE NODE - a service node that has been mapped to an overcloud object storage role\n>             * BLOCK STORAGE NODE - a service node that has been mapped to an overcloud block storage role\n>          * UNDEPLOYED NODE - a node that has not been mapped with a role\n>               * another option - UNALLOCATED NODE - a node that has not been allocated through nova scheduler (?)\n>                                    - (after reading lifeless\'s explanation, I agree that \"allocation\" may be a\n>                                       misleading term under TripleO, so I personally vote for UNDEPLOYED)\n\n\"FREE NODE\" would be my preference here.\n\n>      * INSTANCE - A role deployed on a node - this is where work actually happens.\n\nIf it\'s something that is deployed (eventually) using a Nova call, it\nshould be called an \"instance\", yes. ++\n\n> * DEPLOYMENT\n\nDid you want to add a definition to the term \"DEPLOYMENT\"? How about\nthis?\n\nDEPLOYMENT - A collection of nodes that comprise both the under and\novercloud\n\n>      * SIZE THE ROLES - the act of deciding how many nodes will need to be assigned to each role\n>            * another option - DISTRIBUTE NODES (?)\n>                                  - (I think the former is more accurate, but perhaps there\'s a better way to say it?)\n\nYeah, I agree with some others that \"SIZE THE ROLES\" sounds a bit odd.\nHow about \"SIZE THE DEPLOYMENT\" or \"DETERMINE DEPLOYMENT SCOPE\"?\n\n>      * SCHEDULING - the process of deciding which role is deployed on which node\n\nAgree with others that this isn\'t really scheduling in the sense that\nit\'s not a temporal activity. How about \"ASSIGN THE WORKLOADS\"?\n\n>      * SERVICE CLASS - a further categorization within a service role for a particular deployment.\n> \n>           * NODE PROFILE - a set of requirements that specify what attributes a node must have in order to be mapped to\n>                            a service class\n\nI think I still need some more information about the above two. They\nsound vaguely like Cobbler\'s system profiles... :)\n\nBest,\n-jay\n\n\n\n','<1272510562.5377720.1386789322036.JavaMail.root@redhat.com>',NULL),('<1386991292.2137.48.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 22:21:32',-18000,'2013-12-14 03:21:32',NULL,'[openstack-dev] [TripleO][Tuskar] Terminology','Thanks Mainn, comments inline :)\n\nOn Fri, 2013-12-13 at 19:31 -0500, Tzu-Mainn Chen wrote:\n> Thanks for the reply!  Let me try and address one particular section for now,\n> since it seems to be the part causing the most confusion:\n> \n> > >      * SERVICE CLASS - a further categorization within a service role for a\n> > >      particular deployment.\n> > > \n> > >           * NODE PROFILE - a set of requirements that specify what\n> > >           attributes a node must have in order to be mapped to\n> > >                            a service class\n> > \n> > I think I still need some more information about the above two. They\n> > sound vaguely like Cobbler\'s system profiles... :)\n> \n> I admit that this concept was a bit fuzzy for me as well, but after a few IRC\n> chats, I think I have a better handle on this.  Let me begin with my understanding of what\n> happens in Heat, using Heat terminology:\n> \n> A Heat stack template defines RESOURCES.  When a STACK is deployed using that template,\n> the resource information in the template is used to instantiate an INSTANCE of that\n> resource on a NODE.  Heat can pass a FLAVOR (flavors?) to nova-scheduler in order to\n> filter for appropriate nodes.\n> \n> So: based on that explanation, here\'s what Tuskar has been calling the above:\n> \n> HEAT TERM == TUSKAR TERM\n> ------------------------\n> NODE == NODE\n> STACK == DEPLOYMENT\n> INSTANCE == INSTANCE\n> RESOURCE == SERVICE CLASS (at the very least, it\'s a one-to-one correspondence)\n> FLAVOR == NODE PROFILE\n> ???    == ROLE\n> \n> The ??? is because ROLE is entirely a Tuskar concept, based on what TripleO views\n> as the fundamental kinds of building blocks for an overcloud: Compute, Controller,\n> Object Storage, Block Storage.  A ROLE essentially categorizes RESOURCES/SERVICE CLASSES;\n> for example, the Control ROLE might contain a control-db resource, control-secure resource,\n> control-api resource, etc.\n\nSo, based on your explanation above, perhaps it makes sense to just\nditch the concept of roles entirely? Is the concept useful more than\njust being a list of workloads that a node is running?\n\n> Heat cares only about the RESOURCE and not the ROLE; if the roles were named Foo1, Foo2, Foo3,\n> and Barney, Heat would not care.  Also, if the UI miscategorized, say, the control-db resource\n> under the Block Storage category - Heat would again not care, and the deploy action would work.\n> \n> From that perspective, I think the above terminology should either *be* the Heat term, or be\n> a word that closely corresponds to the intended purpose.  For example, I think DEPLOYMENT reasonably\n> describes a STACK, but I don\'t think SERVICE CLASS works for RESOURCE.  I also think ROLE should be\n> RESOURCE CATEGORY, since that seems to me to be the most straightforward description of its purpose.\n\nI agree with you that either the Tuskar terminology should match the\nHeat terminology, or there should be a good reason for it not to match\nthe Heat terminology.\n\nWith regards to \"stack\" vs. \"deployment\", perhaps it\'s best to just\nstick with \"stack\".\n\nFor \"service class\", \"node profile\", and \"role\", perhaps it may be\nuseful to scrap those terms entirely and use a term that the Solum\nproject has adopted for describing an application deployment: the\n\"plan\".\n\nIn Solum-land, the \"plan\" is simply the instructions for deploying the\napplication. In Tuskar-land, the \"plan\" would simply be the instructions\nfor setting up the undercloud. \n\nSo, instead of \"SIZE THE ROLES\", you would just be defining the \"plan\"\nin Tuskar.\n\nThoughts?\n-jay\n\n\n\n','<127443520.6768742.1386981065832.JavaMail.root@redhat.com>',NULL),('<1387033301.2137.52.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 10:01:41',-18000,'2013-12-14 15:01:41',NULL,'[openstack-dev] [Tempest][Neutron] Network client and API tests\n refactoring.','On Sat, 2013-12-14 at 15:26 +0400, Eugene Nikanorov wrote:\n> Hi tempest folks,\n> \n> While adding new API tests for Neutron I found out that network client\n> used in tempest could be improved in at least two ways:\n> 1) code duplication between xml and json versions could be removed\n> 2) client API could be made more flexible and similar to real neutron\n> client API. \n> E.g. instead of accepting fixed subset of properties of the resource,\n> methods could accept full dict with resource description.\n> \n> Implementing this two points will also require some changes in the\n> tests: for example, instead of calling\n>  network_client.create_network(name)\n> test should call:\n>  network_data = {\'name\': name, \'property2\': property, ...}\n>  network_client.create_network(network_data)\n> \n> Those both items require quite a bit of work and I\'m working on such\n> improvement right now.\n> My personal motivation for this is that I hate to add new client\n> methods by copy-pasting existing and\n> hardcoding stuff in them (and btw, I need to do it for both xml and\n> json versions)\n> \n> So before committing more than two hours on this, I wanted to ask if\n> such kind of change is desirable?\n> If so, I\'m going to present a sequence of patches that will implement\n> this plan.\n\nHi Eugene!\n\nIt\'s best to keep refactoring patches separate from any patches that add\nfunctionality or new tests to Tempest. I think the above improvements\nwould be a welcome change, but it\'s easier for reviewers if that\nrefactoring patch is all in one patch and not mixed in with new tests or\nadded functionality.\n\nAll the best,\n-jay\n\n\n\n','<CAJfiwOQhaYm5=Nc4SA2HFr-KWpD+00LqOfASC259Gm7DDmFaDQ@mail.gmail.com>',NULL),('<1387034585.2137.55.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 10:23:05',-18000,'2013-12-14 15:23:05',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','On Wed, 2013-12-11 at 09:32 -0500, Jay Dobies wrote:\n> On 12/11/2013 07:33 AM, Ji?? Str?nsk? wrote:\n> > 3) Keep tuskar-api and python-tuskarclient thin, make another library\n> > sitting between Tuskar UI and all python-***clients. This new project\n> > would contain the logic of using undercloud services to provide the\n> > \"tuskar experience\" it would expose python bindings for Tuskar UI and\n> > contain a CLI. (Think of it like traditional python-*client but instead\n> > of consuming a REST API, it would consume other python-*clients. I\n> > wonder if this is overengineering. We might end up with too many\n> > projects doing too few things? :) )\n> \n> This is the sort of thing I was describing with the facade image above. \n> Rather than beefing up python-tuskarclient, I\'d rather we have a \n> specific logic layer that isn\'t the CLI nor is it the bindings, but is \n> specifically for the purposes of coordination across multiple APIs.\n> \n> That said, I\'m -1 to my own facade diagram. I think that should live \n> service-side in the API.\n\nAnd this is what Dean said should be implemented as WSGI middleware,\nwhich I agree is likely the most flexible and architecturally-sound way\nof doing this.\n\nBest,\n-jay\n\n\n\n','<52A8778D.4030804@redhat.com>',NULL),('<1387034795.2137.58.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 10:26:35',-18000,'2013-12-14 15:26:35',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','On Wed, 2013-12-11 at 17:48 +0100, Ji?? Str?nsk? wrote:\n<snip>\n> >> When you say python- clients, is there a distinction between the CLI and\n> >> a bindings library that invokes the server-side APIs? In other words,\n> >> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?\n> \n> python-tuskarclient = Python bindings to tuskar-api + CLI, in one project\n> \n> tuskar-ui doesn\'t have it\'s own bindings, it depends on \n> python-tuskarclient for bindings to tuskar-api (and other clients for \n> bindings to other APIs). UI makes use just of the Python bindings part \n> of clients and doesn\'t interact with the CLI part. This is the general \n> OpenStack way of doing things.\n\nPlease everyone excuse my relative lateness in joining this discussion,\nbut I\'m wondering if someone could point me to discussions (or summit\nsession etherpads?) where the decision was made to give Tuskar a\nseparate UI from Horizon? I\'m curious what the motivations were around\nthis?\n\nThanks, and again, sorry for being late to the party! :)\n\n-jay\n\n\n\n','<52A8977B.3050709@redhat.com>',NULL),('<1387036278.2137.67.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 10:51:18',-18000,'2013-12-14 15:51:18',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','On Thu, 2013-12-12 at 15:22 +0100, Hugh O. Brock wrote:\n> On Thu, Dec 12, 2013 at 03:11:14PM +0100, Ladislav Smola wrote:\n> > Agree with this.\n> > \n> > Though I am an optimist,  I believe that this time, we can avoid\n> > calling multiple services in one request that depend on each other.\n> > About the multiple users at once, this should be solved inside the\n> > API calls of the services.\n> > \n> > So I think we should forbid building these complex API calls\n> > composites in the Tuskar-API. If we will want something like this,\n> > we should implement\n> > it properly inside the services itself. If we will not be able to\n> > convince the community about it, maybe it\'s just not that good\n> > feature. :-D\n> > \n> \n> It\'s worth adding that in the particular case Radomir sites (the\n> \"Deploy\" button), even with all the locks in the world, the resources\n> that we have supposedly requisitioned in the undercloud for the user may\n> have already been allocated to someone else by Nova -- because Nova\n> currently doesn\'t allow reservation of resources. (There is work under\n> way to allow this but it is quite a way off.) So we could find ourselves\n> claiming for the user that we\'re going to deploy an overcloud at a\n> certain scale and then find ourselves unable to do so.\n> \n> Frankly I think the whole multi-user case for Tuskar is far enough off\n> that I would consider wrapping a single-login restriction around the\n> entire thing and calling it a day... except that that would be\n> crazy. I\'m just trying to make the point that making these operations\n> really safe for multiple users is way harder than just putting a lock on\n> the tuskar API.\n\nThat\'s actually not that crazy, Hugh :) We\'ve deployed more than a half\ndozen availability zones, and I\'ve never seen anyone trample over each\nother trying to deploy OpenStack to the same set of bare-metal machines\nat the same time... it simply doesn\'t happen in the real world -- or at\nleast, it would be so exceedingly rare that trying to deal with this\nkind of thing is more of an academic exercise than anything else.\n\nInstead of focusing on locking issues -- which I agree are very\nimportant in the virtualized side of things where resources are\n\"thinner\" -- I believe that in the bare-metal world, a more useful focus\nwould be to ensure that the Tuskar API service treats related group\noperations (like \"deploy an undercloud on these nodes\") in a way that\ncan handle failures in a graceful and/or atomic way.\n\nFor example, if the construction or installation of one compute worker\nfailed, adding some retry or retry-after-wait-for-event logic would be\nmore useful than trying to put locks in a bunch of places to prevent\nmultiple sysadmins from trying to deploy on the same bare-metal nodes\n(since it\'s just not gonna happen in the real world, and IMO, if it did\nhappen, the sysadmins/deployers should be punished and have to clean up\ntheir own mess ;)\n\nBest,\n-jay\n\n\n\n','<20131212142226.GG6521@redhat.com>',NULL),('<1387036409.2137.69.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 10:53:29',-18000,'2013-12-14 15:53:29',NULL,'[openstack-dev] [Tempest][Neutron] Network client and API tests\n refactoring.','On Sat, 2013-12-14 at 19:09 +0400, Eugene Nikanorov wrote:\n> Hi Jay,\n> \n> Sure, that is understood. In fact such refactoring could be a big\n> change so I\'d split it to two or more patches.\n> Hope this will not overlap with ongoing neutron API tests development.\n\nHehe, given the sheer number of new tests that get added to Tempest\nevery week, I\'d say that any sort of base refactoring like this will\nneed to be heavily coordinated with the Tempest core reviewers and other\ncontributors pushing code!\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwOT4Jf4gOAGW92WyqTMEiGO6fdx6FG8u4WMtDMG9s8qnZA@mail.gmail.com>',NULL),('<1387037712-sup-7777@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 08:20:09',-28800,'2013-12-14 16:20:09',NULL,'[openstack-dev] [Nova][TripleO] Nested resources','Excerpts from Sylvain Bauza\'s message of 2013-12-14 06:23:48 -0800:\n> 2013/12/9 Clint Byrum <clint at fewbar.com>\n> \n> > Excerpts from Fox, Kevin M\'s message of 2013-12-09 09:34:06 -0800:\n> > > I\'m thinking more generic:\n> > >\n> > > The cloud provider will provide one or more \"suballocating\" images. The\n> > one Triple O uses to take a bare metal node and make vm\'s available would\n> > be the obvious one to make available initially. I think that one should not\n> > have a security concern since it is already being used in that way safely.\n> >\n> > I like where you\'re going with this, in that the cloud should eventually\n> > become \"self aware\" enough to be able to privision the baremetal resources\n> > it has and spin nova up on them. I do think that is quite far out. Right\n> > now, we have two nova\'s.. an undercloud nova which owns all the baremetal,\n> > and an overcloud nova which owns all the vms. This is definitely nested,\n> > but there is a hard line between the two.\n> >\n> > For many people, that hard line is a feature. For others, it is a bug.  :)\n> >\n> >\n> Could we imagine that an end-user would like to provision one undercloud\n> host plus a certain number of overcloud nodes so that the Scheduler for\n> undercloud Nova would deny other hosts but the ones provisioned ?\n\nYes I could imagine that. I also imagine that does not require any special\nknowledge of the undercloud that the overcloud\'s nova API doesn\'t already\nhave access to. The \"host\" is a thing in the overcloud after all.\n\n> As a contrary,  Scheduler for other undercloud Nova\'s need to deny the\n> provisioning of the nodes hosted by another tenant than the requester...\n> I played with TripleO a few months ago (August/September, before the merge\n> with Tuskar) so that\'s a bit unclear for me, but I\'m just saying we could\n> potentially achieve this by using Climate which does deploy its own\n> Scheduler Filter for making sure the proper hosts are booted.\n> \n\nCurrently undercloud nova has one tenant: the overcloud operator. It is\nsingle tenant, which means it has less complexity, but that also means you\ncan\'t hand hardware out directly to multiple tenants. That is why I say\nthat some consider it a feature, and some a bug. IMO that is how it should\nremain, and we should just enhance systems like Climate to be more aware\nof the topology of the hosts which are already an entity in the overcloud.\n\n\n','<CANWE-CmAo79MEJ9GP4GgvOMhkmM7RRX-b7q1fgsN0Fa3q0TYNw@mail.gmail.com>',NULL),('<1387046559.2137.70.camel@uberbox.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 13:42:39',-18000,'2013-12-14 18:42:39',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','On Sat, 2013-12-14 at 10:52 -0500, Tzu-Mainn Chen wrote:\n> > On Wed, 2013-12-11 at 17:48 +0100, Ji?? Str?nsk? wrote:\n> > <snip>\n> > > >> When you say python- clients, is there a distinction between the CLI and\n> > > >> a bindings library that invokes the server-side APIs? In other words,\n> > > >> the CLI is packaged as CLI+bindings and the UI as GUI+bindings?\n> > > \n> > > python-tuskarclient = Python bindings to tuskar-api + CLI, in one project\n> > > \n> > > tuskar-ui doesn\'t have it\'s own bindings, it depends on\n> > > python-tuskarclient for bindings to tuskar-api (and other clients for\n> > > bindings to other APIs). UI makes use just of the Python bindings part\n> > > of clients and doesn\'t interact with the CLI part. This is the general\n> > > OpenStack way of doing things.\n> > \n> > Please everyone excuse my relative lateness in joining this discussion,\n> > but I\'m wondering if someone could point me to discussions (or summit\n> > session etherpads?) where the decision was made to give Tuskar a\n> > separate UI from Horizon? I\'m curious what the motivations were around\n> > this?\n> > \n> > Thanks, and again, sorry for being late to the party! :)\n> > \n> > -jay\n> > \n> \n> Heya - just to clear up what I think might be a possible misconception here - the\n> Tuskar-UI is built on top of Horizon.  It\'s developed as a separate Horizon dashboard\n> - Infrastructure - that can be added into the OpenStack dashboard alongside the existing\n> dashboards - Project, Admin.  The Tuskar-UI developers are active within Horizon, and\n> there\'s currently an effort underway to get the UI placed under the Horizon program.\n> \n> Does that answer your question, or did I miss the thrust of it?\n\nThat precisely answers my questions! :) Thanks, Mainn!\n\n-jay\n\n\n\n','<739405524.6840727.1387036336080.JavaMail.root@redhat.com>',NULL),('<1387057048.33227826.1404802987841.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 00:03:07',-25200,'2014-07-08 07:03:07',NULL,'[openstack-dev] [nova] [VMware] Can someone help to look at\n this	bug https://bugs.launchpad.net/nova/+bug/1338881','Hi David,\n\n----- Original Message -----\n> From: \"Jian Hua Geng\" <gengjh at cn.ibm.com>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, July 8, 2014 8:00:01 AM\n> Subject: [openstack-dev] [nova] [VMware] Can someone help to look at this	bug\n> https://bugs.launchpad.net/nova/+bug/1338881\n> \n> \n> \n> Hi All,\n> \n> Can someone help to look at this bug that is regarding the non-admin user\n> connect to vCenter when run nova compute services?\n> \n\nI have commented on the bug.  I think that you need to add \'Sessions.TerminateSession\' privilege to your account.  This is required in order to terminate inactive sessions.\n\nThanks,\nRado\n\n\n','<OFDC98DAF9.EA08D48D-ON48257D0F.001B54F4-48257D0F.001B88AA@cn.ibm.com>',NULL),('<1387069170.6096.30.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-14 16:59:30',-28800,'2013-12-15 00:59:30',NULL,'[openstack-dev] Generic question: Any tips for \'keeping up\'\n with the mailing lists?','On Thu, 2013-12-12 at 16:23 +0000, Justin Hammond wrote:\n> I am a developer who is currently having troubles keeping up with the\n> mailing list due to volume, and my inability to organize it in my client.\n> I am nearly forced to use Outlook 2011 for Mac and I have read and\n> attempted to implement\n> https://wiki.openstack.org/wiki/MailingListEtiquette but it is still a lot\n> to deal with. I read once a topic or wiki page on using X-Topics but I\n> have no idea how to set that in outlook (google has told me that the\n> feature was removed).\n> \n> I\'m not sure if this is a valid place for this question, but I *am* having\n> difficulty as a developer.\n> \n> Thank you for anyone who takes the time to read this.\n\nI currently use the same technique I used to use with LKML (Linux Kernel\nMailing List) before we (finally) got subject specific lists and I could\njust subscribe to those instead.\n\nThe essential requirement is to have a threaded mail reader with a \"mark\nthread read\" function.  I use evolution where this is ctrl-H ctrl-K.  I\nskip through the threads marking those I\'m not interested in as read.\nSometimes I do this by subject other times by skimming the thread head\nemail.  When I\'m finished, everything I didn\'t skip as read is usually\nthe interesting stuff.\n\nThreads I\'m really interested in, I tag with an imap flag which I have\nan evolution search folder set on for flag+children (and which pops up\ninto my mail notification window), so I see immediately any activity on\ninteresting threads.\n\nI also use procmail on the mail server with a set of heuristics mostly\non subject for things I may be interested in, these get flagged as well,\nso they appear in my email notifications in evolution.  Likewise, things\nI\'m definitely not interested in get tagged as read by the heuristics.\n\nThe procmail thing is server side and means you need a sophisticated\nmail server, but anything that runs Linux should have sieve which should\nbe able to do this (not sure about gmail, because I\'ve never used it).\n\nJames\n\n\n\n\n','<CECF3F1D.15280%justin.hammond@rackspace.com>',NULL),('<1387094481-sup-4048@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-15 00:17:54',-28800,'2013-12-15 08:17:54',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Steven Dake\'s message of 2013-12-14 09:00:53 -0800:\n> On 12/13/2013 01:13 PM, Clint Byrum wrote:\n> > Excerpts from Dmitry Mescheryakov\'s message of 2013-12-13 12:01:01 -0800:\n> >> Still, what about one more server process users will have to run? I see\n> >> unified agent as library which can be easily adopted by both exiting and\n> >> new OpenStack projects. The need to configure and maintain Salt server\n> >> process is big burden for end users. That idea will definitely scare off\n> >> adoption of the agent. And at the same time what are the gains of having\n> >> that server process? I don\'t really see to many of them.\n> >>\n> \n> I tend to agree, I don\'t see a big advantage to using something like \n> salt, when the current extremely simplistic cfn-init + friends do the job.\n> \n> What specific problem does salt solve?  I guess I missed that context in \n> this long thread.\n> \n\nYes you missed the crux of the thread. There is a need to have agents that\nare _not_ general purpose like cfn-init and friends. They specifically\nneed to be narrow in focus and not give the higher level service operator\nbackdoor access to everything via SSH-like control.\n\nSalt works with plugins and thus the general purpose backdoor features\ncan be disabled definitively by not having them present, and then\nplugins for Trove/Savanna/et.al can be added. Since they are\noperator-controlled services these exotic agent configurations will be\nbuilt into operator-controlled images.\n\nFor Heat, the advantage is that you get unified transport in/out of\nprivate networks to a general purpose agent which matches the agent for\nthose higher level services.\n\n> > The Salt devs already mentioned that we can more or less just import\n> > salt\'s master code and run that inside the existing server processes. So\n> > Savanna would have a salt master capability, and so would Heat Engine.\n> I really don\'t think we want to introduce a salt executive into the heat \n> engine process address space, even if it is as simple as an import \n> operation.  Sounds like a debugging nightmare!\n> \n\nData is not that hard to collect in this case, so before we call this\ncomplicated or a debugging nightmare I think a bit of discovery would\ngo a long way. Also the engine is not likely to be where this would be,\n\"existing server processes\" also includes heat-api, which would make a\nlot more sense in this case.\n\n> > If it isn\'t eventlet friendly we can just fork it off and run it as its\n> > own child. Still better than inventing our own.\n> fork/exec is not the answer to scalability and availability I was \n> looking for :)  So, given that we need scale+availability, we are back \n> to managing a daemon outside the address space, which essentially \n> introduces another daemon to be scaled and ha-ified (and documented, \n> etc, see long zookeeper thread for my arguments against new server \n> processes...).  import is not the answer, or atleast it won\'t be for heat...\n> \n\nFork and run things that don\'t work well with eventlet does not mean fork\nand _exec_. Also this is not to address scalability or availability. It\nis to isolate code that does not behave exactly like the rest of our code.\n\n> Salt just seems like more trouble then it is worth, but I don\'t totally \n> understand the rationale for introducing it as a dependency in this \n> case, and I generally think dependencies are evil :)\n>\n\nI generally think dependencies are efficient ways of consuming existing\ncode. Should we not use pecan? eventlet?\n\n> What are we inventing our own again of?  cfn-init & friends already \n> exist, are dead simple, and have no need of anything beyond a metadata \n> server.  I would like to see that level of simplicity in any unified agent.\n> \n\nPlease do read the whole thread or at least the first message. We would\ninvent a framework for efficient agent communication and plugin based\nactions. Right now there are several agents and none of them work quite\nlike the others but all have the same basic goals. This is only about Heat\nbecause by adopting the same communication protocol we gain in-instance\norchestration in private networks.\n\n\n','<52AC8EC5.5000203@redhat.com>',NULL),('<1387235941.3160.119.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 23:19:01',0,'2013-12-16 23:19:01',NULL,'[openstack-dev] Re-initializing or dynamically configuring\n cinder driver','Hi,\n\nOn Sat, 2013-12-14 at 10:23 +0530, iKhan wrote:\n> Hi All,\n> \n> At present cinder driver can be only configured with adding entries in conf\n> file. Once these driver related entries are modified or added in conf file,\n> we need to restart cinder-volume service to validate the conf entries and\n> create a child process that runs in background.\n> \n> I am thinking of a way to re-initialize or dynamically configure cinder\n> driver. So that I can accept the configuration from user on fly and perform\n> operations. I think solution lies somewhere around \"oslo.config.cfg\", but I\n> am still unclear about how re-initializing can be achieved.\n> \n> Let know if anyone here is aware of any approach to re-initialize or\n> dynamically configure a driver.\n\nSome work on this was done in Oslo during Havana, see:\n\n  https://blueprints.launchpad.net/oslo/+spec/service-restart\n  https://blueprints.launchpad.net/oslo/+spec/cfg-reload-config-files\n\nThanks,\nMark.\n\n\n\n','<CADBmBnucKtsPwP45+5CTphFJ9LiEBZVODkmkcWBTcOcyxJJqEQ@mail.gmail.com>',NULL),('<1387236323.08948406@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 17:25:23',-21600,'2013-12-16 23:25:23',NULL,'[openstack-dev] a time-based resource management system','Hi Alan,\n\nLooks like an interesting project.\n\nSome questions/comments:\n\n1) For resources, are you targeting only VMs, or is the scope going to include other resources\n   as well (swift, load balancers, etc.)\n\n2) Is the scope of reservation limited to time/duration or do you envision\n   the scope to also include other kinds of contextual information (e.g. reserved capacity\n   threshold), if any?\n\n3) How are you currently specifying resource reservation policies?\n   Are you using any specific policy specification framework for this purpose?\n\n4) The details about mechanisms for session tracking and access revocation\n   would be interesting to understand. The wiki page mentions there is a prototype \n   implementation, but I did not find a link. Is there anything that you can share?\n\n5) In the implementation section, you mention that you are using roles and user access-list\n   maintained by nova to control access. I was wondering if you considered Keystone\n   to enforce time-based authorization policies of Cafe.\n\nGood luck.\n\nThanks,\n- Devdatta\n \n\n-----Original Message-----\nFrom: \"Alan Tan\" <yst1 at students.waikato.ac.nz>\nSent: Monday, December 16, 2013 4:41pm\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] a time-based resource management system\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi everyone,\n\n \n\nMy name is Alan and I am from the Cyber Security Lab in University of\nWaikato. \n\n \n\nWe have recently started deploying and using Openstack in our experimental\nprivate cloud testbed. The cloud testbed is mainly used in running our\nresearch and teaching purposes. However, we notice that current Openstack\nlacks the ability to control and manage user\'s access to resources in a\ntime-based manner. \n\n \n\nI.e. Current model for private clouds requires either the user to release\ntheir resources (VMs) voluntarily or for the administrators to manually\nremove the resources (VMs).\n\n \n\nThis makes capacity management a laborious effort in private clouds that\nhave a large user base. Hence, we have come up with the idea of an automatic\ntime-based resource management system that manages user access to resources\nin a time slot booking style. We have detailed our plans and design in the\nfollowing wiki page. We would love to hear feedbacks from the community and\nhopefully gather some interest in our project.\n\n \n\n <https://wiki.openstack.org/wiki/Cafe> https://wiki.openstack.org/wiki/Cafe\n\n \n\nWe look forward to hearing from you. We can be contacted via email. Our\naddresses are listed on the wiki page. \n\n \n\nThanks and have a good day.\n\n \n\nCheers,\n\nAlan\n\n \n\n\n\n\n\n','<03c801cefaaf$fd2c4200$f784c600$@students.waikato.ac.nz>',NULL),('<1387237784.3160.135.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 23:49:44',0,'2013-12-16 23:49:44',NULL,'[openstack-dev] [governance] Becoming a Program,\n before applying for incubation','Hi Thierry,\n\nOn Fri, 2013-12-13 at 15:53 +0100, Thierry Carrez wrote:\n> Hi everyone,\n> \n> TL;DR:\n> Incubation is getting harder, why not ask efforts to apply for a new\n> program first to get the visibility they need to grow.\n> \n> Long version:\n> \n> Last cycle we introduced the concept of \"Programs\" to replace the\n> concept of \"Official projects\" which was no longer working that well for\n> us. This was recognizing the work of existing teams, organized around a\n> common mission, as an integral part of \"delivering OpenStack\".\n> Contributors to programs become ATCs, so they get to vote in Technical\n> Committee (TC) elections. In return, those teams place themselves under\n> the authority of the TC.\n> \n> This created an interesting corner case. Projects applying for\n> incubation would actually request two concurrent things: be considered a\n> new \"Program\", and give \"incubated\" status to a code repository under\n> that program.\n> \n> Over the last months we significantly raised the bar for accepting new\n> projects in incubation, learning from past integration and QA mistakes.\n> The end result is that a number of promising projects applied for\n> incubation but got rejected on maturity, team size, team diversity, or\n> current integration level grounds.\n> \n> At that point I called for some specific label, like \"Emerging\n> Technology\" that the TC could grant to promising projects that just need\n> more visibility, more collaboration, more crystallization before they\n> can make good candidates to be made part of our integrated releases.\n> \n> However, at the last TC meeting it became apparent we could leverage\n> \"Programs\" to achieve the same result. Promising efforts would first get\n> their mission, scope and existing results blessed and recognized as\n> something we\'d really like to see in OpenStack one day. Then when they\n> are ready, they could have one of their deliveries apply for incubation\n> if that makes sense.\n> \n> The consequences would be that the effort would place itself under the\n> authority of the TC. Their contributors would be ATCs and would vote in\n> TC elections, even if their deliveries never make it to incubation. They\n> would get (some) space at Design Summits. So it\'s not \"free\", we still\n> need to be pretty conservative about accepting them, but it\'s probably\n> manageable.\n> \n> I\'m still weighing the consequences, but I think it\'s globally nicer\n> than introducing another status. As long as the TC feels free to revoke\n> Programs that do not deliver the expected results (or that no longer\n> make sense in the new world order) I think this approach would be fine.\n> \n> Comments, thoughts ?\n\nThanks for writing this up; a few thoughts ...\n\n\nI\'m not totally convinced we need such formality around the TC\nexpressing its support for an early-stage program/project/effort/team.\n\nHow about if we had an RFC process (hmm, but not in the IETF sense)\nwhereby an individual or team can submit a document expressing a\nposition and ask the TC to give its feedback? We would record that\nfeedback in the governance repo, and it would be a short piece of prose\n(perhaps even recording a diversity of views amongst the TC members)\nrather than a yes/no status vote.\n\nIn the case of a fledgling project, they\'d write up something like a\nfirst draft of an incubation application and we\'d give our feedback,\nencouragement, whatever.\n\n\nSetting a very low bar for the officialness of becoming a Program seems\nwrong to me - I wouldn\'t like to see Programs being added and then later\nremoved with any sort of regularity. Part of what people are looking for\nis an indication of what\'s coming down the track and the endorsement\nimplicit in becoming a Program - before a long-term viable team has been\nestablished - seems too strong for me.\n\n\nEven though this doesn\'t grant ATC status to the people working on those\nprojects, I\'m struggling to see that as a burning issue for anyone -\nhonestly, if you\'re working on an early-stage, keen-to-be-incubated\nproject then I\'d be surprised if you didn\'t find some small way to\ncontribute to one of our many ATC-granting projects.\n\n\nOne thing I\'m noticing that\'s missing from these new docs:\n\n  http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements\n  http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements\n\nis any caution around increasing the scope of OpenStack. I think we are\ncautious about this, but we haven\'t mentioned it beyond e.g.\n\n  ** Project must have a clear and defined scope\n  ** Project should not inadvertently duplicate functionality present in other\n     OpenStack projects. If they do, they should have a clear plan and timeframe\n     to prevent long-term scope duplication.\n  ** Project should leverage existing functionality in other OpenStack projects\n     as much as possible\n\nHow would something like:\n\n  ** Project must have a clear and defined scope which, in turn, represents\n     a measured and obvious progression for OpenStack as a whole\n\nsound?\n\n\nThanks again,\nMark.\n\n\n\n','<52AB1F6B.5010102@openstack.org>',NULL),('<1387238239.3160.137.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 23:57:19',0,'2013-12-16 23:57:19',NULL,'[openstack-dev] [oslo][glance] Oslo.cfg resets not really\n resetting the CONF','Hi\n\nOn Fri, 2013-12-13 at 14:14 +0530, Amala Basha Alungal wrote:\n> Hi,\n> \n> \n> \n> I stumbled into a situation today where in I had to write few tests that\n> modifies the oslo.config.cfg and in turn resets the values back in a tear\n> down. Acc to the docs, oslo.cfg reset() \"*Clears the object state and\n> unsets overrides and defaults.\" *but, it doesn\'t seem to be happening, as\n> the subsequent tests that are run retains these modified values and tests\n> behave abnormally. The patch has been submitted for review\n> here<https://review.openstack.org/#/c/60188/1>.\n> Am I missing something obvious?\n\n>From https://bugs.launchpad.net/oslo/+bug/1261376 :\n\n  reset() will clear any values read from the command line or config\n  files and it will also remove any values set with set_default() or \n  set_override()\n\n  However, it will not undo register_opt() - there is unregister_opt()\n  for that purpose\n\nMaybe if you pushed a version of https://review.openstack.org/60188\nwhich uses reset() and explain how it\'s not working as you expected?\n\nThanks,\nMark.\n\n\n\n','<CAO8WBBSkHmtYyBjRn=idyiWpwZcgupdtFNVEcZNmpLWwCHUwoA@mail.gmail.com>',NULL),('<1387261335.3160.140.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 06:22:15',0,'2013-12-17 06:22:15',NULL,'[openstack-dev] [oslo][glance] Oslo.cfg resets not really\n resetting the CONF','On Tue, 2013-12-17 at 11:17 +0530, Amala Basha Alungal wrote:\n> Hi Mark, Ben\n> \n> \n> The reset() method in turn calls the clear() method which does an\n> unregister_opt(). However the unregister_opt only unregisters the\n> config_opts. The entire set of options inside _opts remain as is.\n> We\'ve filed a bug on the oslo end. \n\nYes, that\'s working as designed.\n\nThose two options are registered by __call__() so reset() unregisters\nonly them.\n\nThe idea is that you can register lots and then do __call__() and\nreset() without affecting the registered options.\n\nMark.\n\n> On Tue, Dec 17, 2013 at 5:27 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         Hi\n>         \n>         On Fri, 2013-12-13 at 14:14 +0530, Amala Basha Alungal wrote:\n>         > Hi,\n>         >\n>         >\n>         >\n>         > I stumbled into a situation today where in I had to write\n>         few tests that\n>         > modifies the oslo.config.cfg and in turn resets the values\n>         back in a tear\n>         \n>         > down. Acc to the docs, oslo.cfg reset() \"*Clears the object\n>         state and\n>         > unsets overrides and defaults.\" *but, it doesn\'t seem to be\n>         happening, as\n>         > the subsequent tests that are run retains these modified\n>         values and tests\n>         > behave abnormally. The patch has been submitted for review\n>         \n>         > here<https://review.openstack.org/#/c/60188/1>.\n>         > Am I missing something obvious?\n>         \n>         \n>         From https://bugs.launchpad.net/oslo/+bug/1261376 :\n>         \n>           reset() will clear any values read from the command line or\n>         config\n>           files and it will also remove any values set with\n>         set_default() or\n>           set_override()\n>         \n>           However, it will not undo register_opt() - there is\n>         unregister_opt()\n>           for that purpose\n>         \n>         Maybe if you pushed a version of\n>         https://review.openstack.org/60188\n>         which uses reset() and explain how it\'s not working as you\n>         expected?\n>         \n>         Thanks,\n>         Mark.\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Thanks And Regards\n> Amala Basha\n> +91-7760972008\n\n\n\n\n','<CAO8WBBQ8bvEnwMoz3hueM4+L0Ka-ikqbKpfNWSBY5fUQ4EzJWA@mail.gmail.com>',NULL),('<138726534.28504633.1386771630629.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 14:20:30',0,'2013-12-11 14:20:30',NULL,'[openstack-dev] [Gating-Failures] Docs creation is failing','Hi, \n\nThe <1.2 rule for Sphinx doesn\'t help, as pointed out by Sean Dague here: \nhttp://lists.openstack.org/pipermail/openstack-dev/2013-December/021921.html ? \n\nThe <1.1.99 rule he proposes works for me (on python-swiftclient): \nhttps://review.openstack.org/#/c/61378/ \n\nRegards, \nFlorent Flament \n\n----- Original Message -----\n\nFrom: \"Sergey Lukjanov\" <slukjanov at mirantis.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Wednesday, December 11, 2013 2:45:02 PM \nSubject: Re: [openstack-dev] [Gating-Failures] Docs creation is failing \n\nHey, \n\ndoc jobs fails because sphinx 1.2 used, all project are now applying <1.2 rule for sphinx to fix it. \n\nHere is a thread with additional info: http://lists.openstack.org/pipermail/openstack-dev/2013-December/021863.html \n\nThanks. \n\n\nOn Wed, Dec 11, 2013 at 1:30 PM, Wangpan < hzwangpan at corp.netease.com > wrote: \n\n\n\n+1 \nhttp://logs.openstack.org/10/61310/2/check/gate-nova-docs/e4ca63f/console.html \n2013-12-11 \n\nWangpan \n\n???? Gary Kotton < gkotton at vmware.com > \n????? 2013-12-11 15:22 \n??? [openstack-dev] [Gating-Failures] Docs creation is failing \n???? \"OpenStack Development Mailing List (not for usage questions)\"< openstack-dev at lists.openstack.org > \n??? \nHi, \nAn example for this is: http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.html \nAny ideas? \nThanks \nGary \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n\n\n\n-- \nSincerely yours, \nSergey Lukjanov \nSavanna Technical Lead \nMirantis Inc. \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131211/9a9366a1/attachment.html>\n\n','<CA+GZd7_c=W_AkFJQEvrkHOU6cJ5GoRcgoNtMqv7pAAL=kWwRhQ@mail.gmail.com>',NULL),('<1387281359.3160.163.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 11:55:59',0,'2013-12-17 11:55:59',NULL,'[openstack-dev] [governance] Becoming a Program,\n before applying for incubation','On Tue, 2013-12-17 at 11:25 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > I\'m not totally convinced we need such formality around the TC\n> > expressing its support for an early-stage program/project/effort/team.\n> \n> This is a difficult balance.\n> \n> You want to help a number of projects attract more contributors and\n> reach critical mass. For that, they want visibility, and one way to give\n> them that is a formal blessing. On the other hand, we want to encourage\n> the spontaneous creation of teams and projects and reduce formality in\n> the early stages as much as possible...\n> \n> > How about if we had an RFC process (hmm, but not in the IETF sense)\n> > whereby an individual or team can submit a document expressing a\n> > position and ask the TC to give its feedback? We would record that\n> > feedback in the governance repo, and it would be a short piece of prose\n> > (perhaps even recording a diversity of views amongst the TC members)\n> > rather than a yes/no status vote.\n> > \n> > In the case of a fledgling project, they\'d write up something like a\n> > first draft of an incubation application and we\'d give our feedback,\n> > encouragement, whatever.\n> \n> I think that level of formality would not trigger enough visibility, so\n> we\'d be back to square 1 with projects applying for incubation because\n> it\'s the only way to get the visibility they need to attract enough\n> contributors.\n\nHow about if we had an \"emerging projects\" page where the TC feedback on\neach project would be listed?\n\nThat would give visibility to our feedback, without making it a yes/no\nblessing. Ok, whether to list any feedback about the project on the page\nis a yes/no decision, but at least it allows us to fully express why we\nfind the project promising, what people need to help with in order for\nit to be incubated, etc.\n\nWith a formal yes/no status, I think we\'d struggle with projects which\nwe\'re not quite ready to even bless with an \"emerging\" status but we\nstill want to encourage them - this allows us to bless a project as\n\"emerging\" but be explicit about our level of support for it.\n\n> So I think we need some official label. It can be attached to the\n> project (\"emerging technology\"), or it can be attached to the team and\n> its mission (\"incoming/wannabe/emerging program\").\n> \n> One benefit of applying it to the team is that the effort can then more\n> naturally graduate to become a full-fledged program when the project\n> gets incubated or integrated, without applying to \"become a program\".\n\nI\'m not loving the idea of blessing a team more or less independently of\nthe project they\'re producing.\n\nI\'d tend to be more wary of blessing a program rather than a fledgling\nproject - if a couple of developers show up and want to be blessed as\nthe \"lampshade program\", then I\'d feel we\'re placing an awful lot of\ntrust in them because we\'re making them responsible for everything\nlampshade related in OpenStack. If instead we were just saying \"we like\nthis lampshade project you\'re working on\", then we leave room for that\nproject to grow or wither or be obsoleted by another group working on a\ncompeting lampshade project.\n\n> > Setting a very low bar for the officialness of becoming a Program seems\n> > wrong to me - I wouldn\'t like to see Programs being added and then later\n> > removed with any sort of regularity. Part of what people are looking for\n> > is an indication of what\'s coming down the track and the endorsement\n> > implicit in becoming a Program - before a long-term viable team has been\n> > established - seems too strong for me.\n> \n> That\'s a fair remark. \"Programs\" come with some expectation of\n> durability and permanence, and using the same term might set\n> expectations wrong. If we settle for a team-attached label, we should\n> probably avoid using \"program\" in its name (and call it\n> \"incoming/wannabe/emerging effort\" or something).\n> \n> > Even though this doesn\'t grant ATC status to the people working on those\n> > projects, I\'m struggling to see that as a burning issue for anyone -\n> > honestly, if you\'re working on an early-stage, keen-to-be-incubated\n> > project then I\'d be surprised if you didn\'t find some small way to\n> > contribute to one of our many ATC-granting projects.\n> \n> Ideally I\'d like to address the case of the \"programs created from an\n> incubated project\" in the same governance change. With the expectation\n> of durable endorsement we\'d like to see attached with \"Programs\", it may\n> make sense to *not* automatically create a program when a project gets\n> incubated, but rather when a project is finally integrated.\n> \n> So two options here:\n> \n> - Consider incubated as emerging, not create a program and not grant ATC\n> status\n> \n> - Consider incubated as integrated, create a program and grant ATC status\n\nHonestly, I struggle to care much about ATC status or those programs\nwhich are associated with individual projects - the principles I care\nabout here are:\n\n  (1) that we should be fairly permissive about granting ATC status and\n\n  (2) programs allow us bless as official those efforts or teams who\n      aren\'t primarily proposing a project which will go through\n      incubation\n\nSo I\'d tend towards creating a program when a project is accepted into\nincubation.\n\n> > One thing I\'m noticing that\'s missing from these new docs:\n> > \n> >   http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements\n> >   http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements\n> > \n> > is any caution around increasing the scope of OpenStack. I think we are\n> > cautious about this, but we haven\'t mentioned it beyond e.g.\n> > \n> >   ** Project must have a clear and defined scope\n> >   ** Project should not inadvertently duplicate functionality present in other\n> >      OpenStack projects. If they do, they should have a clear plan and timeframe\n> >      to prevent long-term scope duplication.\n> >   ** Project should leverage existing functionality in other OpenStack projects\n> >      as much as possible\n> > \n> > How would something like:\n> > \n> >   ** Project must have a clear and defined scope which, in turn, represents\n> >      a measured and obvious progression for OpenStack as a whole\n> > \n> > sound?\n> \n> That\'s a bit orthogonal to this discussion, but +1 :)\n\nYeah, proposed here:\n\n  https://review.openstack.org/62612\n\nMark.\n\n\n\n','<52B026AB.1080308@openstack.org>',NULL),('<1387284860.3160.165.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 12:54:20',0,'2013-12-17 12:54:20',NULL,'[openstack-dev] [governance] Becoming a Program,\n before applying for incubation','On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > How about if we had an \"emerging projects\" page where the TC feedback on\n> > each project would be listed?\n> > \n> > That would give visibility to our feedback, without making it a yes/no\n> > blessing. Ok, whether to list any feedback about the project on the page\n> > is a yes/no decision, but at least it allows us to fully express why we\n> > find the project promising, what people need to help with in order for\n> > it to be incubated, etc.\n> > \n> > With a formal yes/no status, I think we\'d struggle with projects which\n> > we\'re not quite ready to even bless with an \"emerging\" status but we\n> > still want to encourage them - this allows us to bless a project as\n> > \"emerging\" but be explicit about our level of support for it.\n> \n> I agree that being able to express our opinion on a project in shades of\n> grey is valuable... The main drawback of using a non-boolean status for\n> that is that you can\'t grant any benefit to it. So we\'d not be able to\n> say \"emerging projects get design summit space\".\n> \n> They can still collaborate in unconference space or around empty tables,\n> but then we are back to the problem we are trying to solve: increase\n> visibility of promising projects pre-incubation.\n\nHave an emerging projects track and leave it up to the track coordinator\nto decide prioritize the most interesting sessions and the most advanced\nprojects (according to the TC\'s feedback)  ?\n\nMark.\n\n\n\n','<52B04710.8000605@openstack.org>',NULL),('<1387293740-sup-8142@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-17 07:25:03',-28800,'2013-12-17 15:25:03',NULL,'[Openstack] Keystone active/active','Excerpts from Anton Massoud\'s message of 2013-12-17 06:14:36 -0800:\n> Hi,\n> Could keystone HA active/active?\n> Any hints or links how to do that if possible ? Any special setting that is required\n\nKeystone is basically stateless if configured to use only the SQL and\nMemcache backends. Both of those can be made active/active. So just put\na load balancer in front of keystone and point it at an HA database,\nand you\'re good to go.\n\n\n','<28C561A029C4AD4CB43E4B382193FA79039AA645@ESESSMB207.ericsson.se>',NULL),('<1387312697-sup-50@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 12:40:29',-28800,'2013-12-17 20:40:29',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-17 08:01:38 -0800:\n> Folks,\n> \n> The discussion didn\'t result in a consensus, but it did revealed a great\n> number of things to be accounted. I\'ve tried to summarize top-level points\n> in the etherpad [1]. It lists only items everyone (as it seems to me)\n> agrees on, or suggested options where there was no consensus. Let me know\n> if i misunderstood or missed something. The etherpad does not list\n> advantages/disadvantages of options, otherwise it just would be too long.\n> Interested people might search the thread for the arguments :-) .\n> \n> I\'ve thought it over and I agree with people saying we need to move\n> further. Savanna needs the agent and I am going to write a PoC for it. Sure\n> the PoC will be implemented in project-independent way. I still think that\n> Salt limitations overweight its advantages, so the PoC will be done on top\n> of oslo.messaging without Salt. At least we\'ll have an example on how it\n> might look.\n> \n> Most probably I will have more questions in the process, for instance we\n> didn\'t finish discussion on enabling networking for the agent yet. In that\n> case I will start a new, more specific thread in the list.\n\nIf you\'re not going to investigate using salt, can I suggest you base\nyour POC on os-collect-config? It it would not take much to add two-way\ncommunication to it.\n\n\n','<CALU-hjG+=Km0A6msVO7FUtQF5L=XEr9joz5=raN1mQ9tVW+TFg@mail.gmail.com>',NULL),('<1387387494-sup-7564@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 09:36:08',-28800,'2013-12-18 17:36:08',NULL,'[openstack-dev] [trove] My thoughts on the Unified Guest Agent','Excerpts from Tim Simpson\'s message of 2013-12-18 07:34:14 -0800:\n> I\'ve been following the Unified Agent mailing list thread for awhile\n> now and, as someone who has written a fair amount of code for both of\n> the two existing Trove agents, thought I should give my opinion about\n> it. I like the idea of a unified agent, but believe that forcing Trove\n> to adopt this agent for use as its by default will stifle innovation\n> and harm the project.\n> \n\n\"Them\'s fightin words\". ;)\n\nThat is a very strong position to take. So I am going to hold your\nstatements of facts and assumptions to a very high standard below.\n\n> There are reasons Trove has more than one agent currently. While\n> everyone knows about the \"Reference Agent\" written in Python, Rackspace\n> uses a different agent written in C++ because it takes up less memory. The\n> concerns which led to the C++ agent would not be addressed by a unified\n> agent, which if anything would be larger than the Reference Agent is\n> currently.\n>\n\n\"Would be larger...\" - Please provide proof of that assumption or at least\na general hypothesis that we can test. Since nothing was agreed upon\nanyway, I don\'t know how you came to that conclusion. I would suggest\nthat any agent framework be held to an extremely high standard for\nfootprint for this very reason.\n\n> I also believe a unified agent represents the wrong approach\n> philosophically. An agent by design needs to be lightweight, capable\n> of doing exactly what it needs to and no more. This is especially true\n> for a project like Trove whose goal is to not to provide overly general\n> PAAS capabilities but simply installation and maintenance of different\n> datastores. Currently, the Trove daemons handle most logic and leave\n> the agents themselves to do relatively little. This takes some effort\n> as many of the first iterations of Trove features have too much logic\n> put into the guest agents. However through perseverance the subsequent\n> designs are usually cleaner and simpler to follow. A community approved,\n> \"do everything\" agent would endorse the wrong balance and lead to\n> developers piling up logic on the guest side. Over time, features would\n> become dependent on the Unified Agent, making it impossible to run or\n> even contemplate light-weight agents.\n> \n\nNobody has suggested writing an agent that does everything. A\nframework for agents to build on is what has been suggested. In fact\nI\'ve specifically been arguing to keep it focused on facilitating\nguest<->service communication and limiting its in-guest capabilities to\nnarrowly focused tasks.\n\n> Trove\'s interface to agents today is fairly loose and could stand to be\n> made stricter. However, it is flexible and works well enough. Essentially,\n> the duck typed interface of the trove.guestagent.api.API class is used\n> to send messages, and Trove conductor is used to receive them at which\n> point it updates the database. Because both of these components can be\n> swapped out if necessary, the code could support the Unified Agent when\n> it appears as well as future agents.\n> \n> It would be a mistake however to alter Trove\'s standard method of\n> communication to please the new Unified Agent. In general, we should\n> try to keep Trove speaking to guest agents in Trove\'s terms alone to\n> prevent bloat.\n>\n\nIf Trove\'s communication method is in fact superior to all others,\nthen perhaps we should discuss using that in the unified agent framework.\n\nAlso I\'d certainly be interested in hearing about whether or not you\nthink the C++ agent could made generic enough for any project to use.\nThat would be a nice win.\n\n\n','<34CF117D3A5D6841B2C08C30997DA520C01A5C6C@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1387388171-sup-659@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 09:38:24',-28800,'2013-12-18 17:38:24',NULL,'[openstack-dev] [trove] My thoughts on the Unified Guest Agent','Excerpts from Steven Dake\'s message of 2013-12-18 08:05:09 -0800:\n> On 12/18/2013 08:34 AM, Tim Simpson wrote:\n> > I\'ve been following the Unified Agent mailing list thread for awhile \n> > now and, as someone who has written a fair amount of code for both of \n> > the two existing Trove agents, thought I should give my opinion about \n> > it. I like the idea of a unified agent, but believe that forcing Trove \n> > to adopt this agent for use as its by default will stifle innovation \n> > and harm the project.\n> >\n> > There are reasons Trove has more than one agent currently. While \n> > everyone knows about the \"Reference Agent\" written in Python, \n> > Rackspace uses a different agent written in C++ because it takes up \n> > less memory. The concerns which led to the C++ agent would not be \n> > addressed by a unified agent, which if anything would be larger than \n> > the Reference Agent is currently.\n> >\n> > I also believe a unified agent represents the wrong approach \n> > philosophically. An agent by design needs to be lightweight, capable \n> > of doing exactly what it needs to and no more. This is especially true \n> > for a project like Trove whose goal is to not to provide overly \n> > general PAAS capabilities but simply installation and maintenance of \n> > different datastores. Currently, the Trove daemons handle most logic \n> > and leave the agents themselves to do relatively little. This takes \n> > some effort as many of the first iterations of Trove features have too \n> > much logic put into the guest agents. However through perseverance the \n> > subsequent designs are usually cleaner and simpler to follow. A \n> > community approved, \"do everything\" agent would endorse the wrong \n> > balance and lead to developers piling up logic on the guest side. Over \n> > time, features would become dependent on the Unified Agent, making it \n> > impossible to run or even contemplate light-weight agents.\n> >\n> > Trove\'s interface to agents today is fairly loose and could stand to \n> > be made stricter. However, it is flexible and works well enough. \n> > Essentially, the duck typed interface of the trove.guestagent.api.API \n> > class is used to send messages, and Trove conductor is used to receive \n> > them at which point it updates the database. Because both of these \n> > components can be swapped out if necessary, the code could support the \n> > Unified Agent when it appears as well as future agents.\n> >\n> > It would be a mistake however to alter Trove\'s standard method of \n> > communication to please the new Unified Agent. In general, we should \n> > try to keep Trove speaking to guest agents in Trove\'s terms alone to \n> > prevent bloat.\n> >\n> > Thanks,\n> >\n> > Tim\n> \n> Tim,\n> \n> You raise very valid points that I\'ll summarize into bullet points:\n> * memory footprint of a python-based agent\n> * guest-agent feature bloat with no clear path to refactoring\n> * an agent should do one thing and do it well\n> \n> The competing viewpoint is from downstream:\n> * How do you get those various agents into the various linux \n> distributions cloud images and maintain them\n> \n\nOnly Heat cares about this. Trove and Savanna would be pretty silly if\nthey tried to run on general purpose images. IMO Heat shouldn\'t care\neither and Heat operators should just make images that include Heat tools.\n\n\n','<52B1C7B5.4040307@redhat.com>',NULL),('<1387388317-sup-461@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 09:41:28',-28800,'2013-12-18 17:41:28',NULL,'[openstack-dev] Unified Guest Agent proposal','Excerpts from Dmitry Mescheryakov\'s message of 2013-12-18 09:32:30 -0800:\n> Clint, do you mean\n>   * use os-collect-config and its HTTP transport as a base for the PoC\n> or\n>   * migrate os-collect-config on PoC after it is implemented on\n> oslo.messaging\n> \n> I presume the later, but could you clarify?\n> \n\nos-collect-config speaks two HTTP API\'s: EC2 metadata and\nCloudFormation. I am suggesting that it would be fairly easy to teach\nit to also speak oslo.messaging. It currently doesn\'t have a two-way\ncommunication method, but that is only because we haven\'t needed that.\nIt wouldn\'t be difficult at all to have responders instead of collectors\nand send back a response after the command is run.\n\n\n','<CALU-hjER9vBAOYha+favf3NXwrDVWwr=qmxsD7OF2xeYc7q1Yw@mail.gmail.com>',NULL),('<1387389423-sup-6120@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 10:10:24',-28800,'2013-12-18 18:10:24',NULL,'[openstack-dev] [Heat] hybrid cloud & bursting question','Excerpts from =?ks_c_5601-1987?B?wMzB2L/4?=\'s message of 2013-12-18 01:26:22 -0800:\n> Hi, stackers,\n> \n> I know only little about Heat, and I can\'t wholly follow recent \n> discussions around multi-region support in this mailing list.\n> Please help me understand the roadmap or plan about hybrid cloud \n> and \"bursting\" in particular. \n> \n> I\'d like to ask the following questions to the developers who have \n> the same interests.\n> \n> 1) Can we use Heat to deploy to the AWS using the same template\n>    as in the OpenStack cloud?\n> \n\n\"Sort of\". If you stick to CloudFormation syntax then yes, that should\ncontinue to work as long as cloudformation syntax is supported.\n\n> 2) Will Heat support \"bursting\" when multi-region is supported?\n>    (i.e., auto scaling from the private cloud to the public cloud)\n>\n\nThat was not discussed at the Icehouse summit. What is planned is to\nallow separate resources in separate regions.\n\n> If these are not prepared in the Icehouse release, is it possible \n> in the J-release? Who\'s interested in these? Will it be able to \n> burst into Rackspace cloud or HP cloud using HOT within next year?\n> \n> We\'re also considering the development of the related features \n> if possible and want to know how to be involved step by step.\n> \n\nI think many people would like a feature like that. The best place to\ndiscuss this would be at the weekly IRC Meeting:\n\nhttps://wiki.openstack.org/wiki/Meetings/HeatAgenda\n\n\n','<002e01cefbd3$374e6980$a5eb3c80$@samsung.com>',NULL),('<1387403536-sup-3715@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 13:52:51',-28800,'2013-12-18 21:52:51',NULL,'[Openstack] [Heat] Basic questrions','Excerpts from S?awek Kap?o?ski\'s message of 2013-12-18 12:56:05 -0800:\n> Hello,\n> \n> I\'m tryin to understand and install heat on intrastructure. I hava one\n> node which is controller node with nova, ceilometer-agent-central,\n> horizon etc. installed and second host with only nova-compute. So\n> should I install heat and all its stuff (heat, heat-api, heat-engine)\n> only on host with nova controller or maybe on all hosts in\n> infrastructure?\n\nYou can run them all on the controller. There is no need to run them on\nthe compute host.\n\n\n','<20131218215605.2fed721e@laptop>',NULL),('<1387426283-sup-9783@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 20:11:46',-28800,'2013-12-19 04:11:46',NULL,'[openstack-dev] [heat] Nomination for heat-core','Excerpts from Steve Baker\'s message of 2013-12-18 18:21:46 -0800:\n> I would like to nominate Bartosz G?rski to be a heat-core reviewer. His\n> reviews to date have been valuable and his other contributions to the\n> project have shown a sound understanding of how heat works.\n> \n> Here is his review history:\n> https://review.openstack.org/#/q/reviewer:bartosz.gorski%2540ntti3.com+project:openstack/heat,n,z\n> \n> If you are heat-core please reply with your vote.\n> \n> cheers\n\n+1\n\nKeep it up Bartosz!\n\n\n','<52B2583A.9000002@redhat.com>',NULL),('<1387437725-sup-7678@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 23:28:16',-28800,'2013-12-19 07:28:16',NULL,'[openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents -\n	what is the actual problem?','So I\'ve seen a lot of really great discussion of the unified agents, and\nit has made me think a lot about the problem that we\'re trying to solve.\n\nI just wanted to reiterate that we should be trying to solve real problems\nand not get distracted by doing things \"right\" or even \"better\".\n\nI actually think there are three problems to solve.\n\n* Private network guest to cloud service communication.\n* Narrow scope highly responsive lean guest agents (Trove, Savanna).\n* General purpose in-instance management agent (Heat).\n\nSince the private network guests problem is the only one they all share,\nperhaps this is where the three projects should collaborate, and the\nother pieces should be left to another discussion.\n\nThoughts?\n\n\n',NULL,NULL),('<1387469555-sup-3956@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 08:21:17',-28800,'2013-12-19 16:21:17',NULL,'[openstack-dev] Incubation Request for Barbican','Excerpts from Sean Dague\'s message of 2013-12-19 04:14:51 -0800:\n> On 12/19/2013 12:10 AM, Mike Perez wrote:\n> > On Tue, Dec 17, 2013 at 1:59 PM, Mike Perez <thingee at gmail.com\n> > <mailto:thingee at gmail.com>> wrote:\n> <snip>\n> > I reviewed the TC meeting notes, and my question still stands.\n> > \n> > It seems the committee is touching on the point of there being a worry\n> > because if \n> > it\'s a single company running the show, they can pull resources away and\n> > the \n> > project collapses. My worry is just having one company attempting to\n> > design solutions \n> > to use cases that work for them, will later not work for those potential\n> > companies that would \n> > provide contributors.\n> > \n> > -Mike Perez\n> \n> Which is our fundamental chicken and egg problem. The Barbican team has\n> said they\'ve reached out to other parties, who have expressed interest\n> in joining, but no one else has.\n> \n> The Heat experience shows that a lot of the time companies won\'t kick in\n> resources until there is some kind of stamp of general approval.\n> \n\nI want to confirm this specific case. I joined the TripleO effort just\nabout a year ago. We needed an orchestration tool. If Heat hadn\'t been\nin incubation we would have considered all other options. Because it\nwas incubated, even though some others might have been more or less\nattractive, there was no question we would lend our efforts to Heat.\n\nHad we just decided to build our own, or try to enhance Ansible or\nsalt-cloud, we\'d have likely had to abandon that effort as Heat improved\nbeyond their scope in the context of managing OpenStack API\'s.\n\n> If you showed up early, with a commitment to work openly, the fact that\n> the project maps to your own use cases really well isn\'t a bug, it\'s a\n> feature. I don\'t want to hold up a team from incubating because other\n> people stayed on the sidelines. That was actually exactly what was going\n> on with Heat, where lots of entities thought they would keep that side\n> of the equation proprietary, or outside of OpenStack. By bringing Heat\n> in, we changed the equation, I think massively for the better.\n> \n\nRight, contributing to a project that is already part of\nOpenStack means you don\'t have to have _another_ conversation with\nmanagement/legal/etc. about contributing to _another_ OpenSource project\nwith slightly different governance/licensing/affiliation. An\norganization can align its strategy around OpenStack, earn influence on\nthe board/TC/dev teams/etc.\n\nSo when it is time to open source something as part of that, the org can,\nI hope, count on OpenStack to welcome them and shout to the world that\nthere is a new \"X\" in town and everybody else should take a good long\nlook at it and consider dropping their own \"X\" in favor of contributing\nto this one.\n\n\n','<52B2E33B.907@dague.net>',NULL),('<1387474924.46383.YahooMailNeo@web120603.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-19 09:42:04',-28800,'2013-12-19 17:42:04',NULL,'[Openstack] Need help with network config on a basic setup','Hi All,\n\nI need some help on bringing up my openstack setup. I am using the havana release.\n\nNote:\n Please excuse me writing a very long email. The intention is to provide\n as much detail as possible so that its easier for the community members\n to suggest a solution.\n\nI was able to create and bring up a guest instance on compute node. But,\n\nThe issue is:\nI\n am not able to SSH (from either controller on compute1) to the guest \nand I am not able to ping to guest IP (192.168.0.2). What am I missing \nor doing wrong?\n\n\nSetup details are:\n\n- I am using two servers each having 2 NIC ports:\n??? ??? 1) controller (SL6.3)?????????????? - em1(10.192.206.247); em2(192.168.0.10)\n??? ??? 2) compute1 (RHEL 6.4 x64)? - eth0(10.192.207.152); eth1(192.168.0.11)\n\n-\n em1 and eth0 are connected via a switch. This is the management network\n (hosts file has these IPs against controller/compute1 hostnames)\n\n-\n em2 and eth1 are connected directly by a cable. For my experimental \nsetup, I want this to be the data network (I guess its also called the \npublic interface)\n\n\nConfig Details are:\n\n\'nova list\' output on controller node:\n\n+--------------------------------------+--------+--------+------------+-------------+-------------------+\n|\n ID?????????????????????????????????? | Name?? | Status | Task State | Power State | Networks????????? |\n+--------------------------------------+--------+--------+------------+-------------+-------------------+\n| fffd4391-968a-41ff-b292-f2f56ce87abd | cirrOS | ACTIVE | None?????? | Running???? | vmnet=192.168.0.2 |\n+--------------------------------------+--------+--------+------------+-------------+-------------------+\n\nifcfg-eth0:\nDEVICE=eth0\nHWADDR=2C:44:FD:7F:04:B0\nTYPE=Ethernet\nUUID=9739295d-d4f7-4a1d-abd7-11397af8818a\nONBOOT=yes\nNM_CONTROLLED=\"no\"\nBOOTPROTO=dhcp\n\nifcfg-eth1:\nDEVICE=eth1\nHWADDR=2C:44:FD:7F:04:B1\nTYPE=Ethernet\nUUID=4d11464b-1304-43e6-abcc-e28f6c56894f\nIPADDR=192.168.0.11\nNETMASK=255.255.255.0\nDEFROUTE=yes\nONBOOT=yes\nNM_CONTROLLED=\"no\"\nBOOTPROTO=static\n\nnova.conf on compute1:\n-- truncated --\nflat_interface = eth1\nflat_network_bridge = br100\npublic_interface = eth1\n-- truncated --\n\nnetwork-create command used:\nnova network-create vmnet --fixed-range-v4=192.168.0.0/24 --bridge-interface=br100 --multi-host=T\n\nifcfg -a output on compute1:\nbr100???? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n????????? inet addr:192.168.0.1? Bcast:192.168.0.255? Mask:255.255.255.0\n?????????\n inet6 addr: fe80::542d:5dff:fe0c:f3d4/64 Scope:Link\n????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n-- truncated --\n\neth0????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B0\n????????? inet addr:10.192.207.152? Bcast:10.192.207.255? Mask:255.255.240.0\n????????? inet6 addr: fe80::2e44:fdff:fe7f:4b0/64 Scope:Link\n????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n-- truncated --\n\neth1????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n????????? inet6 addr: fe80::2e44:fdff:fe7f:4b1/64 Scope:Link\n????????? UP BROADCAST RUNNING MULTICAST?\n MTU:1500? Metric:1\n-- truncated --\n?\n?\nThanks,\nNishant\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131219/55688a47/attachment.html>\n\n',NULL,NULL),('<1387490287.74167098@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-19 15:58:07',-21600,'2013-12-19 21:58:07',NULL,'[openstack-community] 2014 Industry Events\' Call For Papers Open','\n\n \nOpenStack\'s 2013 industry event experience indicates speaking sessions can be the best way to reach the most receptive audiences.  Speaking at industry events is a great way to educate OpenStack users and potential users while indirectly promoting your company\'s expertise. \n \nYour innovative presentations are requested for these upcoming events. The CFP hotlinks will direct you to details on the recommended topics and the submission forms. Learn more about the events and attendees by clicking on the event hotlinks.\n \nAs always, please feel free to contact me with questions - kathyc at openstack.org.  Thank you and happy holidays!\n[http://www.oscon.com/oscon2014] OSCON 2014, event date July 20-24 in Portland, OR.  [http://www.oscon.com/oscon2014/public/cfp/308] CFP due by January 30.  Audience is primarily very technical, leading edge developers, sys admins and open source enthusiasts who are most likely familiar and/or working with OpenStack software. They will appreciate in-depth topics.  OSCON 2014 coincides with the the software\'s 4th birthday.\n[http://www.cloudcomputingexpo.com/] Cloud Expo East, event date June 10-12 in New York City. [http://www.cloudcomputingexpo.com/general/papers2014east.htm] CFP due by March 1.  Audience is primarily IT managers and staff. At the 2013 event, we experienced most of this audience was looking for benefits of cloud computing, how cloud is differentiated from virtualization, and had heard of OpenStack but did not yet have specific knowledge of the software.  On the other hand, there were a few very technical conversations.  NYC-based user stories and business cases welcome.\n[http://cloudwf.com/interested-in-speaking/] Cloud World Forum Europe, event date June 17-18 in London.  [http://cloudwf.com/interested-in-speaking/] CFP deadline  to come; not yet listed.  Audience is a mix of IT decision makers and management, and evenly split between multinational enterprises and SMB.  European case studies would be ideal.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20131219/b12ef4b8/attachment.html>\n\n',NULL,NULL),('<1387499486.56198.YahooMailAndroidMobile@web120605.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-19 16:31:26',-28800,'2013-12-20 00:31:26',NULL,'[Openstack] Need help with network config on a basic setup','Hi Dan,\n\nJust before launching the instance using \'nova boot\', I had run these commands on controller (ran only on controller):\n\n# nova secgroup-add-rule default tcp 22 22 0.0.0.0/0\n\n# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/\n\nI assumed that they will configure firewall correctly. Please let me know if I missed something.\n\nThanks,\nNishant\n\nSent from Yahoo! Mail on Android\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131219/2adb2261/attachment.html>\n\n',NULL,NULL),('<1387522247-sup-5311@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-19 22:54:33',-28800,'2013-12-20 06:54:33',NULL,'[openstack-dev] [oslo][nova] oslo common.service vs. screen and\n	devstack','Excerpts from Sean Dague\'s message of 2013-12-19 16:33:12 -0800:\n> So a few people had been reporting recently that unstack no longer stops\n> nova processes, which I only got around to looking at today. It turns\n> out the new common.service stack from oslo takes SIGHUP and treats it as\n> a restart. Which isn\'t wrong, but is new, and is incompatible with\n> screen (the way we use it). Because we use -X stuff, the resulting -X\n> quit sends SIGHUP to the child processes.\n> \n> So the question is, are we definitely in a state now where nova services\n> can and do want to support SIGHUP as restart?\n> \n> If so, is there interest in being able to disable that behavior at start\n> time, so we can continue with a screen based approach as well?\n> \n> If not, we\'ll need to figure out another way to approach the shutdown in\n> devstack. Which is fine, just work that wasn\'t expected.\n> \n\nPerhaps if the process is running in the foreground, as it does in\ndevstack, it should still terminate on SIGHUP rather than restart.\n\n\n','<52B39048.70106@dague.net>',NULL),('<1387556543-sup-1263@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-20 08:34:06',-28800,'2013-12-20 16:34:06',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','Excerpts from Radomir Dopieralski\'s message of 2013-12-20 01:13:20 -0800:\n> On 20/12/13 00:17, Jay Pipes wrote:\n> > On 12/19/2013 04:55 AM, Radomir Dopieralski wrote:\n> >> On 14/12/13 16:51, Jay Pipes wrote:\n> >>\n> >> [snip]\n> >>\n> >>> Instead of focusing on locking issues -- which I agree are very\n> >>> important in the virtualized side of things where resources are\n> >>> \"thinner\" -- I believe that in the bare-metal world, a more useful focus\n> >>> would be to ensure that the Tuskar API service treats related group\n> >>> operations (like \"deploy an undercloud on these nodes\") in a way that\n> >>> can handle failures in a graceful and/or atomic way.\n> >>\n> >> Atomicity of operations can be achieved by intoducing critical sections.\n> >> You basically have two ways of doing that, optimistic and pessimistic.\n> >> Pessimistic critical section is implemented with a locking mechanism\n> >> that prevents all other processes from entering the critical section\n> >> until it is finished.\n> > \n> > I\'m familiar with the traditional non-distributed software concept of a\n> > mutex (or in Windows world, a critical section). But we aren\'t dealing\n> > with traditional non-distributed software here. We\'re dealing with\n> > highly distributed software where components involved in the\n> > \"transaction\" may not be running on the same host or have much awareness\n> > of each other at all.\n> \n> Yes, that is precisely why you need to have a single point where they\n> can check if they are not stepping on each other\'s toes. If you don\'t,\n> you get race conditions and non-deterministic behavior. The only\n> difference with traditional, non-distributed software is that since the\n> components involved are communicating over a, relatively slow, network,\n> you have a much, much greater chance of actually having a conflict.\n> Scaling the whole thing to hundreds of nodes practically guarantees trouble.\n> \n\nRadomir, what Jay is suggesting is that it seems pretty unlikely that\ntwo individuals would be given a directive to deploy OpenStack into a\nsingle pool of hardware at such a scale where they will both use the\nwhole thing.\n\nWorst case, if it does happen, they both run out of hardware, one\nindividual deletes their deployment, the other one resumes. This is the\noptimistic position and it will work fine. Assuming you are driving this\nall through Heat (which, AFAIK, Tuskar still uses Heat) there\'s even a\nblueprint to support you that I\'m working on:\n\nhttps://blueprints.launchpad.net/heat/+spec/retry-failed-update\n\nEven if both operators put the retry in a loop, one would actually\nfinish at some point.\n\n> > Trying to make a complex series of related but distributed actions --\n> > like the underlying actions of the Tuskar -> Ironic API calls -- into an\n> > atomic operation is just not a good use of programming effort, IMO.\n> > Instead, I\'m advocating that programming effort should instead be spent\n> > coding a workflow/taskflow pipeline that can gracefully retry failed\n> > operations and report the state of the total taskflow back to the user.\n> \n> Sure, there are many ways to solve any particular synchronisation\n> problem. Let\'s say that we have one that can actually be solved by\n> retrying. Do you want to retry infinitely? Would you like to increase\n> the delays between retries exponentially? If so, where are you going to\n> keep the shared counters for the retries? Perhaps in tuskar-api, hmm?\n> \n\nI don\'t think a sane person would retry more than maybe once without\nchecking with the other operators.\n\n> Or are you just saying that we should pretend that the nondeteministic\n> bugs appearing due to the lack of synchronization simply don\'t exist?\n> They cannot be easily reproduced, after all. We could just close our\n> eyes, cover our ears, sing \"lalalala\" and close any bug reports with\n> such errors with \"could not reproduce on my single-user, single-machine\n> development installation\". I know that a lot of software companies do\n> exactly that, so I guess it\'s a valid business practice, I just want to\n> make sure that this is actually the tactic that we are going to take,\n> before commiting to an architectural decision that will make those bugs\n> impossible to fix.\n> \n\nOpenStack is non-deterministic. Deterministic systems are rigid and unable\nto handle failure modes of any kind of diversity. We tend to err toward\npushing problems back to the user and giving them tools to resolve the\nproblem. Avoiding spurious problems is important too, no doubt. However,\nwhat Jay has been suggesting is that the situation a pessimistic locking\nsystem would avoid is entirely user created, and thus lower priority\nthan say, actually having a complete UI for deploying OpenStack.\n\n\n','<52B40A30.5050801@sheep.art.pl>',NULL),('<1387557717-sup-6510@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-20 08:51:44',-28800,'2013-12-20 16:51:44',NULL,'[openstack-dev] [TripleO] Tuskar CLI after architecture changes','Excerpts from Ladislav Smola\'s message of 2013-12-20 05:48:40 -0800:\n> On 12/20/2013 02:37 PM, Imre Farkas wrote:\n> > On 12/20/2013 12:25 PM, Ladislav Smola wrote:\n> >> 2. Heat stack create, update\n> >> This is locked in the process of the operation, so nobody can mess with\n> >> it while it is updating or creating.\n> >> Once we will pack all operations that are now aside in this, we should\n> >> be alright. And that should be doable in I.\n> >> So we should push towards this, rather then building some temporary\n> >> locking solution in Tuskar-API.\n> >\n> > It\'s not the issue of locking, but the goal of Tuskar with the \n> > Provision button is not only a single stack creation. After Heat\'s job \n> > is done, the overcloud needs to be properly configured: Keystone needs \n> > to be initialized, the services need to be registered, etc. I don\'t \n> > think Horizon wants to add a background worker to handle such operations.\n> >\n> \n> Yes, that is a valid point. I hope we will be able to pack it all to \n> Heat Template in I. This could be the way \n> https://blueprints.launchpad.net/heat/+spec/hot-software-config\n> \n> Seems like the consensus is: It belongs to Heat. We are just not able to \n> do it that way now.\n> \n> So there is a question, whether we should try to solve it in Tuskar-API \n> temporarily. Or rather focus on the Heat.\n> \n\nInterestingly enough, what Imre has just mentioned isn\'t necessarily\ncovered by hot-software-config. That blueprint is specifically about\nconfiguring machines, but not API\'s.\n\nI think we actually need multi-cloud to support what Imre is talking\nabout. These are API operations that need to follow the entire stack\nbring-up, but happen in a different cloud (the new one).\n\nAssuming single servers instead of loadbalancers and stuff for simplicity:\n\n\nresources:\n  keystone:\n    type: OS::Nova::Server\n  glance:\n    type: OS::Nova::Server\n  nova:\n    type: OS::Nova::Server\n  cloud-setup:\n    type: OS::Heat::Stack\n    properties:\n      cloud-endpoint: str_join [ \'https://\', get_attribute [ \'keystone\', \'first_ip\' ], \':35357/\' ]\n      cloud-credentials: get_parameter [\'something\']\n      template:\n        keystone-catalog:\n          type: OS::Keystone::Catalog\n          properties:\n            endpoints:\n              - type: Compute\n                publicUrl: str_join [ \'https://\', get_attribute [ \'nova\', \'first_ip\' ], \':8447/\' ]\n              - type: Image\n                publicUrl: str_join [ \'https://\', get_attribute [ \'glance\', \'first_ip\' ], \':12345/\' ]\n\nWhat I mean is, you want the Heat stack to be done not when the hardware\nis up, but when the API\'s have been orchestrated.\n\n\n','<52B44AB8.20508@redhat.com>',NULL),('<1387558985-sup-3421@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-20 09:16:08',-28800,'2013-12-20 17:16:08',NULL,'[Openstack] How to configure multiple glance servers','Excerpts from Rajshree Thorat\'s message of 2013-12-18 21:33:59 -0800:\n> Hi All,\n> \n> I am trying multinode Grizzly deployment. On a separate node, I \n> registered glance services and relative endpoints\n> in keystone. If I want to run glance on multiple host servers, do I need \n> to register two glance services in keystone?\n\nNo.\n\n> or do I still just need one glance service but add more endpoints?\n>\n\nNo.\n\n> How I can launch a image on specific glance server?\n>\n\nSetup a load balancer on both that points to localhost and the other\nglance server. Haproxy is popular. Have glance listen on a different port\nand let haproxy serve the usual glance port. Then setup some method of\nhaving the hostname or IP shared. Simplest solution is to just use RRDNS.\nAlso if you already have a load balancer for other pieces then you can\njust use that.\n\nTo make that work right then you need to make the glance storage shared.\n\nMost of the storage backends are pretty massive scale. Your simplest\nchoice is probably to use the default \'file\' store and just share the\ndirectory via NFS.\n\nNote that you probably want to read this:\n\nhttp://docs.openstack.org/trunk/openstack-ops/content/cloud_controller_design.html#images\n\nand perhaps these:\n\nhttp://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-image-service.html\nhttp://docs.openstack.org/admin-guide-cloud/content/ch_introduction-to-openstack-compute.html#section_images-and-instances\n\n\n','<52B28547.7010702@gslab.com>',NULL),('<1387600917.9483751.1394786976000.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 09:49:36',3600,'2014-03-14 08:49:36',NULL,'[openstack-dev] [qa] Python 3.3 patches (using six)','Hi,\n\nI\'m working for eNovance and we are working on porting OpenStack to Python 3. Status of the port:\n\n  http://techs.enovance.com/6722/status-of-the-openstack-port-to-python-3-2\n  https://wiki.openstack.org/wiki/Python3\n\nI understand that it becomes late for Python 3 changes before Icehouse release, but I don\'t agree on the second part of your mail.\n\nDavid wrote:\n> (...) I\'m not sure it makes sense to do this work piecemeal until\n> we are near ready to introduce a py3 gate job.\n\nI\'m not sure that I understood correctly. You want first to see all Python 3 tests pass, and then accept changes to fix Python 3 issues? Adding a py33 gate is nice, but it is almost useless before it becomes voting if nobody reads failures. And I don\'t expect that anyone will care of the py33 gate before it becomes voting.\n\nIt\'s not possible to fix all Python 3 issues at once. It requires many small changes which are carefully viewed and discussed. It is not possible to see all issues at once neither. For example, you have first to fix obvious syntax errors to see less trivial Python 3 issues. Changes are done incrementally, as other changes in OpenStack.\n\nYes, it\'s possible to reintroduce Python 3 incompatible code, but I expect much fewer \"regressions\" compared to the number of fixed issues.\n\nCyril Roelandt is improving the hacking tool to detect the most obvious cases of Python 3 incompatible code:\n\n  https://review.openstack.org/#/c/80171/\n\nWe are working on clients and Olso Incubator first, but we are also preparing the port of servers.\n\nVictor\n\n\n','<531E349C.2010901@redhat.com>',NULL),('<1387659056-sup-6172@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-21 12:53:21',-28800,'2013-12-21 20:53:21',NULL,'[Openstack] Bringing focus to the Operators and Users at the\n	next summit','Excerpts from Matthew Ray\'s message of 2013-12-20 20:22:20 -0800:\n> Perhaps we could try to co-locate a future Operators mini-summit with\n> FOSDEM or SCALE (February) and/or OSCON (July)? Events like those are\n> conveniently scheduled between November and April and likely to already\n> have OpenStack-related developers/deployers planning on attending. The\n> logistics might not work for February, but we should start planning for the\n> future.\n> \n\nOSCON is an ideal venue for this. Certainly we should approach the\norganizers immediately as I\'m sure plans are already solidifying.\n\nFor SCALE I think we may be too late, as the CFP has closed and it is\njust 2 months away.\n\nWe\'re all busy, is there anybody who can step up and drive this?\n\n\n','<CACXEufNDnPZSXptrOi-CZGx2AbNui0c=U06ikRg7pad7GJW19A@mail.gmail.com>',NULL),('<1387735083.1598.YahooMailNeo@web120601.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-22 09:58:03',-28800,'2013-12-22 17:58:03',NULL,'[Openstack] Need help with network config on a basic setup','\nThe eth1 IP on compute node (192.168.0.11) seems to have disappeared but\n I can still ping this IP from controller. Is this behavior normal?\n?\nThanks,\nNishant\n\n\n\nOn Friday, December 20, 2013 6:01 AM, nishant kumar <nishant80 at yahoo.com> wrote:\n \nHi Dan,\nJust before launching the instance using \'nova boot\', I had run these commands on controller (ran only on controller):\n# nova secgroup-add-rule default tcp 22 22 0.0.0.0/0\n# nova secgroup-add-rule default icmp -1 -1 0.0.0.0/\nI assumed that they will configure firewall correctly. Please let me know if I missed something.\nThanks,\nNishant\nSent from Yahoo! Mail on Android \n\n\n\n________________________________\n From:  Daniel Ellison <daniel at syrinx.net>; \nTo:  nishant kumar <nishant80 at yahoo.com>; \nCc:  OpenStack List <openstack at lists.openstack.org>; \nSubject:  Re: [Openstack] Need help with network config on a basic setup \nSent:  Thu, Dec 19, 2013 6:11:09 PM \n\n\nIt may be simpler than that. Did you set up firewall rules to allow ICMP and SSH access to your instance? \"Access & Security\" then \"Security Groups\".\n\n+Dan\n\nOn Dec 19, 2013 12:42 PM, nishant kumar <nishant80 at yahoo.com> wrote:\n>\n> Hi All,\n>\n> I need some help on bringing up my openstack setup. I am using the havana release.\n>\n> Note: Please excuse me writing a very long email. The intention is to provide as much detail as possible so that its easier for the community members to suggest a solution.\n>\n> I was able to create and bring up a guest instance on compute node. But,\n>\n> The issue is:\n> I am not able to SSH (from either controller on compute1) to the guest and I am not able to ping to guest IP (192.168.0.2). What am I missing or doing\n wrong?\n>\n>\n> Setup details are:\n>\n> - I am using two servers each having 2 NIC ports:\n> ??? ??? 1) controller (SL6.3)?????????????? - em1(10.192.206.247); em2(192.168.0.10)\n> ??? ??? 2) compute1 (RHEL 6.4 x64)? - eth0(10.192.207.152); eth1(192.168.0.11)\n>\n> - em1 and eth0 are connected via a switch. This is the management network (hosts file has these IPs against controller/compute1 hostnames)\n>\n> - em2 and eth1 are connected directly by a cable. For my experimental setup, I want this to be the data network (I guess its also called the public interface)\n>\n>\n> Config Details are:\n>\n> \'nova list\' output on controller node:\n>\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n> | ID?????????????????????????????????? | Name?? |\n Status | Task State | Power State | Networks????????? |\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n> | fffd4391-968a-41ff-b292-f2f56ce87abd | cirrOS | ACTIVE | None?????? | Running???? | vmnet=192.168.0.2 |\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n>\n> ifcfg-eth0:\n> DEVICE=eth0\n> HWADDR=2C:44:FD:7F:04:B0\n> TYPE=Ethernet\n> UUID=9739295d-d4f7-4a1d-abd7-11397af8818a\n> ONBOOT=yes\n> NM_CONTROLLED=\"no\"\n> BOOTPROTO=dhcp\n>\n> ifcfg-eth1:\n> DEVICE=eth1\n> HWADDR=2C:44:FD:7F:04:B1\n> TYPE=Ethernet\n> UUID=4d11464b-1304-43e6-abcc-e28f6c56894f\n> IPADDR=192.168.0.11\n> NETMASK=255.255.255.0\n> DEFROUTE=yes\n> ONBOOT=yes\n> NM_CONTROLLED=\"no\"\n> BOOTPROTO=static\n>\n> nova.conf\n on compute1:\n> -- truncated --\n> flat_interface = eth1\n> flat_network_bridge = br100\n> public_interface = eth1\n> -- truncated --\n>\n> network-create command used:\n> nova network-create vmnet --fixed-range-v4=192.168.0.0/24 --bridge-interface=br100 --multi-host=T\n>\n> ifcfg -a output on compute1:\n> br100???? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n> ????????? inet addr:192.168.0.1? Bcast:192.168.0.255? Mask:255.255.255.0\n> ????????? inet6 addr: fe80::542d:5dff:fe0c:f3d4/64 Scope:Link\n> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n>\n> eth0????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B0\n> ????????? inet addr:10.192.207.152? Bcast:10.192.207.255? Mask:255.255.240.0\n> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b0/64 Scope:Link\n>\n ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n>\n> eth1????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b1/64 Scope:Link\n> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n> ?\n> ?\n> Thanks,\n> Nishant \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131222/452970ce/attachment.html>\n\n','<1387499486.56198.YahooMailAndroidMobile@web120605.mail.ne1.yahoo.com>',NULL),('<1387770774.524.YahooMailNeo@web120602.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-22 19:52:54',-28800,'2013-12-23 03:52:54',NULL,'[Openstack] Need help with network config on a basic setup','Hey Remo,\n\n$> ifconfig -a | grep \"192.168.0.11\"\n\nThe above returns no results.\n\nI have this IP in \'/etc/sysconfig/network-scripts/ifcfg-eth1\'. Maybe that is why I can ping it from controller?\n\n\n?\nThanks,\nNishant\n\n\n\nOn Sunday, December 22, 2013 11:37 PM, Remo Mattei <remo at mattei.org> wrote:\n \nAre you sure that no other instances have that ip?\n\n\nInviato da iPhone (?)\n\nIl giorno Dec 22, 2013, alle ore 9:58, nishant kumar <nishant80 at yahoo.com> ha scritto:\n\n\nThe eth1 IP on compute node (192.168.0.11) seems to have disappeared but I can still ping this IP from controller. Is this behavior normal?\n>?\n>Thanks,\n>Nishant\n>\n>\n>\n>On Friday, December 20, 2013 6:01 AM, nishant kumar <nishant80 at yahoo.com> wrote:\n> \n>Hi Dan,\n>Just before launching the instance using \'nova boot\', I had run these commands on controller (ran only on controller):\n># nova secgroup-add-rule default tcp 22 22 0.0.0.0/0\n># nova secgroup-add-rule default icmp -1 -1 0.0.0.0/\n>I assumed that they will configure firewall correctly. Please let me know if I missed something.\n>Thanks,\n>Nishant\n>Sent from Yahoo! Mail on Android \n>\n>\n>\n>________________________________\n> From:  Daniel Ellison <daniel at syrinx.net>; \n>To:  nishant kumar <nishant80 at yahoo.com>; \n>Cc:  OpenStack List <openstack at lists.openstack.org>; \n>Subject:  Re: [Openstack] Need help with network config on a basic setup \n>Sent:  Thu, Dec 19, 2013 6:11:09 PM \n>\n>\n>It may be simpler than that. Did you set up firewall rules to allow ICMP and SSH access to your instance? \"Access & Security\" then \"Security Groups\".\n>\n>+Dan\n>\n>On Dec 19, 2013 12:42 PM, nishant kumar <nishant80 at yahoo.com> wrote:\n>>\n>> Hi All,\n>>\n>> I need some help on bringing up my openstack setup. I am using the havana release.\n>>\n>> Note: Please excuse me writing a very long email. The intention is to provide as much detail as possible so that its easier for the community members to suggest a solution.\n>>\n>> I was able to create and bring up a guest instance on compute\n node. But,\n>>\n>> The issue is:\n>> I am not able to SSH (from either controller on compute1) to the guest and I am not able to ping to guest IP (192.168.0.2). What am I missing or doing\n wrong?\n>>\n>>\n>> Setup details are:\n>>\n>> - I am using two servers each having 2 NIC ports:\n>> ??? ??? 1) controller (SL6.3)?????????????? - em1(10.192.206.247); em2(192.168.0.10)\n>> ??? ??? 2) compute1 (RHEL 6.4 x64)? - eth0(10.192.207.152); eth1(192.168.0.11)\n>>\n>> - em1 and eth0 are connected via a switch. This is the management network (hosts file has these IPs against controller/compute1 hostnames)\n>>\n>> - em2 and eth1 are connected directly by a cable. For my experimental setup, I want this to be the data network (I guess its also called the public interface)\n>>\n>>\n>>\n Config Details are:\n>>\n>> \'nova list\' output on controller node:\n>>\n>> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n>> | ID?????????????????????????????????? | Name?? |\n Status | Task State | Power State | Networks????????? |\n>> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n>> | fffd4391-968a-41ff-b292-f2f56ce87abd | cirrOS | ACTIVE | None?????? | Running???? | vmnet=192.168.0.2 |\n>> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n>>\n>> ifcfg-eth0:\n>> DEVICE=eth0\n>> HWADDR=2C:44:FD:7F:04:B0\n>> TYPE=Ethernet\n>> UUID=9739295d-d4f7-4a1d-abd7-11397af8818a\n>> ONBOOT=yes\n>> NM_CONTROLLED=\"no\"\n>> BOOTPROTO=dhcp\n>>\n>> ifcfg-eth1:\n>> DEVICE=eth1\n>> HWADDR=2C:44:FD:7F:04:B1\n>> TYPE=Ethernet\n>> UUID=4d11464b-1304-43e6-abcc-e28f6c56894f\n>> IPADDR=192.168.0.11\n>> NETMASK=255.255.255.0\n>> DEFROUTE=yes\n>> ONBOOT=yes\n>> NM_CONTROLLED=\"no\"\n>> BOOTPROTO=static\n>>\n>> nova.conf\n on compute1:\n>> -- truncated --\n>> flat_interface = eth1\n>> flat_network_bridge = br100\n>> public_interface = eth1\n>> -- truncated --\n>>\n>> network-create command used:\n>> nova network-create vmnet --fixed-range-v4=192.168.0.0/24 --bridge-interface=br100 --multi-host=T\n>>\n>> ifcfg -a output on compute1:\n>> br100???? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n>> ????????? inet addr:192.168.0.1? Bcast:192.168.0.255? Mask:255.255.255.0\n>> ????????? inet6 addr: fe80::542d:5dff:fe0c:f3d4/64 Scope:Link\n>> ????????? UP BROADCAST RUNNING\n MULTICAST? MTU:1500? Metric:1\n>> -- truncated --\n>>\n>> eth0????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B0\n>> ????????? inet addr:10.192.207.152? Bcast:10.192.207.255? Mask:255.255.240.0\n>> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b0/64 Scope:Link\n>>\n ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n>> -- truncated --\n>>\n>> eth1????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n>> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b1/64 Scope:Link\n>> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n>> -- truncated --\n>> ?\n>> ?\n>> Thanks,\n>> Nishant \n>\n>\n!DSPAM:2,52b729f2311877236118410! \n_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ????: openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>!DSPAM:2,52b729f2311877236118410!\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131222/6618f93e/attachment.html>\n\n','<C96A78EF-A572-4714-8BB5-25BA204F1649@mattei.org>',NULL),('<1387771520878-27719.post@n7.nabble.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-12-22 20:05:20',-28800,'2013-12-23 04:05:20',NULL,'[openstack-community] A bug on OpenStack','Hi Experts,\n\nThe log I got is as below. VM creation failed with the below logs of \n/var/log/nova/compute.log, even though I increased the RPC response timer.\n\nI am assuming that message exchange between nova and nova-network failed due\nto the defect of amqp or something.\n\n5290 TRACE nova.openstack.common.rpc.amqp raise rpc_common.Timeout()\n5290 TRACE nova.openstack.common.rpc.amqp Timeout: Timeout while waiting on\nRPC response.\n5290 TRACE nova.openstack.common.rpc.amqp\n\nKind Regards,\n\nBirdKafka\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/A-bug-on-OpenStack-tp27710p27719.html\nSent from the Community mailing list archive at Nabble.com.\n\n\n','<003101ceff20$8bbba550$a332eff0$@oceanearth-corp.com>',NULL),('<1387802483.23194747.1370963385396.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 11:09:45',-14400,'2013-06-11 15:09:45',NULL,'[openstack-qa] Data encapsulation within Tempest','\n\n\n\n----- Original Message -----\n> From: \"Daryl Walleck\" <daryl.walleck at RACKSPACE.COM>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Sunday, June 9, 2013 11:54:53 PM\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> >> Why do we need so many \"if\" statements for username/password/tenant/etc in\n> >> the Manager class? or a >>better question is \"why is the Manager class\n> >> dependent on a specific implementation of an Identity >>component\"\n> >> (keystone)?\n> \n> >I don\'t really think we need a Manager class at all. It serves no purpose,\n> >IMO.\n> \n> In its current form the manager class is extremely verbose. However, I think\n> there is some value in having a single entry point into the clients. There\n> are better ways to do this dynamically that involve far less code.\n> \n\nLess code generally more readable.\n\nThe only additional thing we need to consider, how many places we need to modify\ncode in order to add new functionality.\n\n> >> In the \"services\" folder.\n> >> Why do we need two clients for JSON/XML?\n> \n> >Because both code paths need testing?\n> \n> It\'s very possible to get rid of the duplicate clients by extracting the one\n> thing that varies (serialization/deserialization) from the clients and\n> handle it elsewhere. This allowed us to greatly reduce the amount of\n> duplicated client code we have in CloudCafe.\n\nAgreed.\n\nThe request generations in all OpenStack per HTTP method type is very similar.\nWe just need several smart functions.\n \n> Daryl\n> \n> -----Original Message-----\n> From: Jay Pipes [mailto:jaypipes at gmail.com]\n> Sent: Sunday, June 9, 2013 2:50 PM\n> To: openstack-qa at lists.openstack.org\n> Subject: Re: [openstack-qa] Data encapsulation within Tempest\n> \n> On 06/09/2013 10:50 AM, Tal Kammer wrote:\n> <snip>\n> > Some code examples:\n> > In the \"base.py\" file in the identity section.\n> > Why does the BaseIdentityAdminTest class needs to hold so many clients\n> > inside it?\n> \n> No idea. I can\'t stand this aspect of it.\n> \n> > In the \"clients.py\" file.\n> > Why do we need an \"AdminManager\"/\"AltManager\"/\"ComputeAdminManager\"?\n> \n> See previous email with code from my proof of concept. Instead of using admin\n> manager, alt manager, and all that stuff, it uses role-based user\n> management, which is a much cleaner strategy than the current one, IMO.\n> \n> > Why do we need so many \"if\" statements for username/password/tenant/etc in\n> > the Manager class? or a better question is \"why is the Manager class\n> > dependent on a specific implementation of an Identity component\"\n> > (keystone)?\n> \n> I don\'t really think we need a Manager class at all. It serves no purpose,\n> IMO.\n> \n> > In the \"services\" folder.\n> > Why do we need two clients for JSON/XML?\n> \n> Because both code paths need testing?\n> \n> > I believe that all the examples above can easily be improved by\n> > encapsulation and separation of duties.\n> > for example, in the \"clients.py\":\n> > If we create an object named \"User\" (or a KeystoneUser) that will hold the\n> > proper credentials and send it to the Manager class directly, or better\n> > yet, to a KeystoneManager (that inherit/composite Manager) that knows what\n> > are the requirements for a keystone authentication, we simplified the way\n> > of using our code and consolidate five different classes into one.\n> \n> I don\'t believe we need a Manager class at all. We should use the\n> fixtures.Fixture class as our basic unit of test-needed resources and use\n> fixtures.TestWithFixtures to handle much of the plumbing.\n> \n> Best,\n> -jay\n> \n> > There are more examples of how encapsulation and separation of duties\n> > can help us down size the amount of code we write and help us be\n> > modular, but I will stop here as this mail got pretty long as it is :)\n> >\n> > Thoughts?\n> >\n> > Tal Kammer\n> > (tkammer on IRC)\n> >\n> > _______________________________________________\n> > openstack-qa mailing list\n> > openstack-qa at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >\n> \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C69519FBA@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1387813685.62243.YahooMailNeo@web120605.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-23 07:48:05',-28800,'2013-12-23 15:48:05',NULL,'[Openstack] Need help with network config on a basic setup','Got the solution!\n\nTo all who are not able to ping their VM instance, you need to run following on compute node:\n#> iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill\n\nI struggled with this issue for 5 days before stumbling on this link that has the correct solution:\nhttps://github.com/mseknibilel/OpenStack-Folsom-Install-guide/issues/14\n\n\n\nBIG RELIEF :-D\n\n?\nThanks,\nNishant\n\n\n\nOn Thursday, December 19, 2013 11:42 PM, Daniel Ellison <daniel at syrinx.net> wrote:\n \nIt may be simpler than that. Did you set up firewall rules to allow ICMP and SSH access to your instance? \"Access & Security\" then \"Security Groups\".\n\n+Dan\n\nOn Dec 19, 2013 12:42 PM, nishant kumar <nishant80 at yahoo.com> wrote:\n>\n> Hi All,\n>\n> I need some help on bringing up my openstack setup. I am using the havana release.\n>\n> Note: Please excuse me writing a very long email. The intention is to provide as much detail as possible so that its easier for the community members to suggest a solution.\n>\n> I was able to create and bring up a guest instance on compute node. But,\n>\n> The issue is:\n> I am not able to SSH (from either controller on compute1) to the guest and I am not able to ping to guest IP (192.168.0.2). What am I missing or doing wrong?\n>\n>\n> Setup details are:\n>\n> - I am using two servers each having 2 NIC ports:\n> ??? ??? 1) controller (SL6.3)?????????????? - em1(10.192.206.247); em2(192.168.0.10)\n> ??? ??? 2) compute1 (RHEL 6.4 x64)? - eth0(10.192.207.152); eth1(192.168.0.11)\n>\n> - em1 and eth0 are connected via a switch. This is the management network (hosts file has these IPs against controller/compute1 hostnames)\n>\n> - em2 and eth1 are connected directly by a cable. For my experimental setup, I want this to be the data network (I guess its also called the public interface)\n>\n>\n> Config Details are:\n>\n> \'nova list\' output on controller node:\n>\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n> | ID?????????????????????????????????? | Name?? | Status | Task State | Power State | Networks????????? |\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n> | fffd4391-968a-41ff-b292-f2f56ce87abd | cirrOS | ACTIVE | None?????? | Running???? | vmnet=192.168.0.2 |\n> +--------------------------------------+--------+--------+------------+-------------+-------------------+\n>\n> ifcfg-eth0:\n> DEVICE=eth0\n> HWADDR=2C:44:FD:7F:04:B0\n> TYPE=Ethernet\n> UUID=9739295d-d4f7-4a1d-abd7-11397af8818a\n> ONBOOT=yes\n> NM_CONTROLLED=\"no\"\n> BOOTPROTO=dhcp\n>\n> ifcfg-eth1:\n> DEVICE=eth1\n> HWADDR=2C:44:FD:7F:04:B1\n> TYPE=Ethernet\n> UUID=4d11464b-1304-43e6-abcc-e28f6c56894f\n> IPADDR=192.168.0.11\n> NETMASK=255.255.255.0\n> DEFROUTE=yes\n> ONBOOT=yes\n> NM_CONTROLLED=\"no\"\n> BOOTPROTO=static\n>\n> nova.conf on compute1:\n> -- truncated --\n> flat_interface = eth1\n> flat_network_bridge = br100\n> public_interface = eth1\n> -- truncated --\n>\n> network-create command used:\n> nova network-create vmnet --fixed-range-v4=192.168.0.0/24 --bridge-interface=br100 --multi-host=T\n>\n> ifcfg -a output on compute1:\n> br100???? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n> ????????? inet addr:192.168.0.1? Bcast:192.168.0.255? Mask:255.255.255.0\n> ????????? inet6 addr: fe80::542d:5dff:fe0c:f3d4/64 Scope:Link\n> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n>\n> eth0????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B0\n> ????????? inet addr:10.192.207.152? Bcast:10.192.207.255? Mask:255.255.240.0\n> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b0/64 Scope:Link\n> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n>\n> eth1????? Link encap:Ethernet? HWaddr 2C:44:FD:7F:04:B1\n> ????????? inet6 addr: fe80::2e44:fdff:fe7f:4b1/64 Scope:Link\n> ????????? UP BROADCAST RUNNING MULTICAST? MTU:1500? Metric:1\n> -- truncated --\n> ?\n> ?\n> Thanks,\n> Nishant\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/5014866a/attachment.html>\n\n',NULL,NULL),('<1387826604.2150.15.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-23 11:23:24',-28800,'2013-12-23 19:23:24',NULL,'[openstack-dev] Process for proposing patches attached to\n launchpad bugs?','On Fri, 2013-12-20 at 14:07 -0500, Russell Bryant wrote:\n> On 12/20/2013 09:32 AM, Dolph Mathews wrote:\n> > In the past, I\'ve been able to get authors of bug fixes attached to\n> > Launchpad bugs to sign the CLA and submit the patch through gerrit...\n> > although, in one case it took quite a bit of time (and thankfully it\n> > wasn\'t a critical fix or anything).\n> > \n> > This scenario just came up again (example: [1]), so I\'m asking\n> > preemptively... what if the author is unwilling / unable in signing the\n> > CLA and propose through gerrit, or it\'s a critical bug fix and waiting\n> > on an author to go through the CLA process is undesirable for the\n> > community? Obviously that\'s a bit of a fail on our part, but what\'s the\n> > most appropriate & expedient way to handle it?\n> > \n> > Can we propose the patch to gerrit ourselves?\n> > \n> > If so, who should appear as the --author of the commit? Who should\n> > appear as Co-Authored-By, especially when the committer helps to evolve\n> > the patch evolves further in review?\n> > \n> > Alternatively, am I going about this all wrong?\n> > \n> > Thanks!\n> > \n> > [1]: https://bugs.launchpad.net/keystone/+bug/1198171/comments/8\n> \n> It\'s not your code, so you really can\'t propose it without them having\n> signed the CLA, or propose it as your own.\n> \n> Ideally have someone else fix the same bug that hasn\'t looked at the patch.\n> \n> >From a quick look, it seems likely that this fix is small and straight\n> forward enough that the clean new implementation is going to end up\n> looking very similar.  Still, I think it\'s the right thing to do.\n\nWhat is the actual point of the CLA? since it seems to be a barrier to\ncontribution.  Why not do something affirmative like a DCO instead.  The\nsigned-off-by on a patch submitted by any mechanism (email list, patch\nto bugzilla, launchpad, gerrit) can then be included because it carries\nthe DCO affirmation with it.\n\nThe reason CLAs are such a barrier is that if you\'re an employee of a\ncompany, you have to get the approval of that company to sign them.  If\nthe company is used to this type of thing, it\'s usually a couple of days\nturn around.  If it\'s not, it can be painful weeks trying to explain to\nthe corporate counsel what you\'re trying to do (and why it won\'t affect\nthe company too much) ... a large number of developers simply give up in\nthe middle of this.\n\nThe only point the current CLA would serve would be to allow the\nOpenStack foundation to change the licence from ASL-2.0 to an ASL\nincompatible licence since DCO + ASL-2.0 seems to cover all the other\nterms in the current CLA.  Is that really worth all the pain?  I have a\nhard time coming up with another licence besides GPLv2 that is actually\nASL-2.0 incompatible, so any licensing switch could apparently be made\nwithout the need for a copyright grant.\n\nJames\n\n\n\n\n','<52B4955D.5070604@redhat.com>',NULL),('<1387843648.32234.YahooMailNeo@web160301.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-23 16:07:28',-28800,'2013-12-24 00:07:28',NULL,'[Openstack] neutron install guide wording question','Hi all,\n\nI?m currently going through the havana install guide for a yum-based distro and planning my required hardware. I was hoping to only use two hosts and needed some clarification around neutron:\n\nDo i need a dedicated network node (exclusive of controller and compute) if i want to use neutron as per the guide? The install guide (http://docs.openstack.org/havana/install-guide/install/yum/content/neutron-install-network-node.html) lists 3 scenarios, one each for dedicated network/compute/controller but the wording is confusing me:\n\nInstall Networking services on a dedicated network node\nInstall networking support on a dedicated compute node\nInstall networking support on a dedicated controller node\n\nI first thought these were mutually exclusive, If i wanted to run networking on it?s own node, use the first, if i wanted networking on compute use the second etc.\n\nBut i noticed the wording uses ?services? for network node and ?support? for the others. Is it correct to assume this example is NOT mutually exclusive and rather each step must be taken on individual respective nodes (one network, one compute and one controller) in a single cloud (i.e. therefor a minimum of 3 nodes)?\n\nThanks in advance,\n\nAugust\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131223/d5403f18/attachment.html>\n\n',NULL,NULL),('<1387875727.64477.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-24 17:02:07',28800,'2013-12-24 09:02:07',NULL,'[Openstack] how to integrate horizon with swift','I installed swift on my laptop by creating a virtual machine of ubuntu 12.04 LTS desktop using the document http://docs.openstack.org/developer/swift/development_saio.html\nIt provides CLI interface for working with swift.\nI need a GUI interface for the same.\nFor this purpose, I want to integrate Horizon with it.\nDoes it solve my purpose of GUI interface?\nAnd, what commands should I follow to integrate horizon with swift?\n-----------\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131224/b6b36070/attachment.html>\n\n',NULL,NULL),('<1387876507.97062.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-24 17:15:07',28800,'2013-12-24 09:15:07',NULL,'[Openstack] can I create account using swift CLI','I installed swift on my laptop by creating a virtual machine of ubuntu 12.04 LTS desktop using the document http://docs.openstack.org/developer/swift/development_saio.html\n\nI am using swift CLI for working with swift\n\nFor adding an account in Swift, I first modify /etc/swift/proxy-server.conf and add italic line in it.\n--------\n[filter:tempauth]\nuse = egg:swift#tempauth\nuser_admin_admin = admin .admin .reseller_admin\nuser_test_tester = testing .admin\nuser_test2_tester2 = testing2 .admin\nuser_test_tester3 = testing3\n*user_prag2648_pragya = pj2648 .admin .reseller_admin*\n--------\nand, then restart proxy\n\nMy question is:\nCan I create account using swift CLI?\nIf yes, then how?\nIf no, then Is there any other way to create an account?\n\n\nThanks \n\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131224/641af572/attachment.html>\n\n',NULL,NULL),('<1387878063.1792.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-24 17:41:03',28800,'2013-12-24 09:41:03',NULL,'[Openstack] what is the concept of partition space in swift','as said in many documents, Partition is a collection of stored data\naccount databases, container databases and objects\n\nMy question is:\n\n?- one partition space is responsible for storing anyone of three- account databases, container databases and objects.\nOr, one partition space contains all of the three?\n?- where do these partition space reside? Whether they reside on the ring or on the storage node?\n\nPlease help me to make it clear.\n------\nThanks in advance\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131224/e20e62d8/attachment.html>\n\n',NULL,NULL),('<1387878957.20678.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-24 17:55:57',28800,'2013-12-24 09:55:57',NULL,'[Openstack] how the replicator in swift replicate a good copy','as said in many documents, A hash file is created for each partition which contains hashes of each directory in the partition. Replicator continuously examines each partition. Each of three hash file are compared. If hashes are different, Directory that need to be replicated is copied over.\n\nMy question is:\n\n?- what is the mean of directory here? Is directory representing account database,container databese and objects?\n?- If there is any fault or difference found while comparing the hashes, What is copied over - the whole partition or the particular directory whose hash is different?\n\nPlease help me to make it clear.\n----\nThanks in advance\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131224/1435bcdf/attachment.html>\n\n',NULL,NULL),('<1387905705-sup-1398@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-24 09:26:14',-28800,'2013-12-24 17:26:14',NULL,'[openstack-dev] [TripleO] icehouse-1 test disk images setup','Excerpts from James Slagle\'s message of 2013-12-24 08:50:32 -0800:\n> I built some vm image files for testing with TripleO based off of the\n> icehouse-1 milestone tarballs for Fedora and Ubuntu.  If folks are\n> interested in giving them a try you can find a set of instructions and\n> how to download the images at:\n> \n> https://gist.github.com/slagle/981b279299e91ca91bd9\n> \n\nThis is great, thanks for working hard to make the onramp shorter. :)\n\n> The steps are similar to the devtest process, but you use the prebuilt\n> vm images for the undercloud and overcloud and don\'t need a seed vm.\n> When the undercloud vm is started it uses the OpenStack Configuration\n> Drive as a data source for cloud-init.  This eliminates some of the\n> manual configuration that would otherwise be needed.  To that end, the\n> steps currently use some different git repos for some of the tripleo\n> tooling since not all of that functionality is upstream yet.  I can\n> submit those upstream, but they didn\'t make a whole lot of sense\n> without the background, so I wanted to provide that first.\n> \n\nWhy would config drive be easier than putting a single json file in\n/var/lib/heat-cfntools/cfn-init-data the way the seed works?\n\nDo you experience problems with that approach that we haven\'t discussed?\n\nIf I were trying to shrink devtest from 3 clouds to 2, I\'d eliminate the\nundercloud, not the seed. The seed is basically an undercloud in a VM\nwith a static configuration. That is what you have described but done\nin a slightly different way. I am curious what the benefits of this\napproach are.\n\n> At the very least, this could be an easier way for developers to get\n> setup with tripleo to do a test overcloud deployment to develop on\n> things like Tuskar.\n> \n\nDon\'t let my questions discourage you. This is great as-is!\n\n\n','<CAHV77z-kmvg7+Mh6k-i5o3NCPU_sEN9ByCZKsyf_WZw0O=Sefg@mail.gmail.com>',NULL),('<1387920112-sup-4868@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-24 13:28:29',-28800,'2013-12-24 21:28:29',NULL,'[openstack-dev] [TripleO] icehouse-1 test disk images setup','Excerpts from James Slagle\'s message of 2013-12-24 10:40:23 -0800:\n> On Tue, Dec 24, 2013 at 12:26 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from James Slagle\'s message of 2013-12-24 08:50:32 -0800:\n> >> I built some vm image files for testing with TripleO based off of the\n> >> icehouse-1 milestone tarballs for Fedora and Ubuntu.  If folks are\n> >> interested in giving them a try you can find a set of instructions and\n> >> how to download the images at:\n> >>\n> >> https://gist.github.com/slagle/981b279299e91ca91bd9\n> >>\n> >\n> > This is great, thanks for working hard to make the onramp shorter. :)\n> >\n> >> The steps are similar to the devtest process, but you use the prebuilt\n> >> vm images for the undercloud and overcloud and don\'t need a seed vm.\n> >> When the undercloud vm is started it uses the OpenStack Configuration\n> >> Drive as a data source for cloud-init.  This eliminates some of the\n> >> manual configuration that would otherwise be needed.  To that end, the\n> >> steps currently use some different git repos for some of the tripleo\n> >> tooling since not all of that functionality is upstream yet.  I can\n> >> submit those upstream, but they didn\'t make a whole lot of sense\n> >> without the background, so I wanted to provide that first.\n> >>\n> >\n> > Why would config drive be easier than putting a single json file in\n> > /var/lib/heat-cfntools/cfn-init-data the way the seed works?\n> >\n> > Do you experience problems with that approach that we haven\'t discussed?\n> \n> That approach works fine if you\'re going to build the seed image.   In\n> devtest, you modify the cfn-init-data with a sed command, then include\n> it in your build seed image.  So, everyone that runs devtest ends up\n> with a unique seed image pretty much.\n> \n\nI had not considered this but it makes sense.\n\n> In this approach, everyone uses the same undercloud vm image.  In\n> order to make that work, their\'s a script to build the config drive\n> iso and that is then used to make config changes at boot time to the\n> undercloud.  Specifically, there\'s cloud-init data on the config drive\n> iso to update the virtual power manager user and ssh key, and sets the\n> user\'s ssh key in authorized keys.\n> \n\nIs this because it is less work to build an iso than to customize an\nexisting seed image? How hard would it be to just mount the guest image\nand drop the json file in it?\n\nAnyway I like the approach, though I generally do not like config drive.\n:)\n\n> >\n> > If I were trying to shrink devtest from 3 clouds to 2, I\'d eliminate the\n> > undercloud, not the seed. The seed is basically an undercloud in a VM\n> > with a static configuration. That is what you have described but done\n> > in a slightly different way. I am curious what the benefits of this\n> > approach are.\n> \n> True, there\'s not a whole lot of difference between eliminating the\n> seed or the undercloud.  You eliminate either one, then call your\n> first cloud whichever you want.  To me, the seed has always seemed\n> short lived, once you use it to deploy the undercloud it can go away\n> (eventually, anyway).  So, that\'s why I am calling the first cloud\n> here the undercloud.  Plus, since it will eventually include Tuskar\n> and deploy the overcloud, it seemed more inline with the current\n> devtest flow to call it an undercloud.\n> \n\nThe more I think about it the more I think we should just take the three\ncloud approach. The seed can be turned off as soon as the undercloud is\nrunning, but it allows testing and modification of the seed to undercloud\ntransfer, which is something we are going to need to put work in to at\nsome point. It would be a shame to force developers to switch gears and\nuse something entirely different when they need to get into that.\n\nPerhaps we could just use your config drive approach for the seed all\nthe time. Then users can start with pre-built images, but don\'t have to\nchange everything when they want to start changing said images.\n\nI\'m not 100% convinced that it is needed, but I\'d rather have one path\nthan two if we can manage that and not drive away potential\ncontributors.\n\n\n','<CAHV77z_NAyP1eRLK8hvSS8te4TLbMo8kbibnRMjZd3+B0aQevQ@mail.gmail.com>',NULL),('<1387920227.107.1384150354609.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-11 06:12:34',0,'2013-11-11 06:12:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #42','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/42/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5662f50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5662f50>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x551f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x551f150>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-366b3b1e-c760-4154-a461-7dc4301eb17d\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:12:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:12:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:12:01+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:12:01-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'01\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:12:01Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'01\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5efdd50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x24a16d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 70.24 secs:\n    14.76    TestScrubber.test_delayed_delete\n    14.15    TestGlanceControl.test_reload\n    13.90    TestGlanceControl.test_respawn\n    13.77    TestGlanceControl.test_bouncing\n    13.66    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 597.530s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-42\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ickBPBD4QK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/42/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-4/42\n[SCP] Copying console log.\n\n\n','<917296329.81.1383632053365.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1387956811.76550.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-25 15:33:31',28800,'2013-12-25 07:33:31',NULL,'[Openstack] Fw:  what is the concept of partition space in swift','\n\nhello all,\n\nPlease reply my question.\nPlease help.\n------\n\nPragya Jain\n\n\nOn Tuesday, 24 December 2013 3:33 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nas said in many documents, Partition is a collection of stored data\n>account databases, container databases and objects\n>\n>My question is:\n>\n>?- one partition space is responsible for storing anyone of three- account databases, container databases and objects.\n>Or, one partition space contains all of the three?\n>?- where do these partition space reside? Whether they reside on the ring or on the storage node?\n>\n>\n>Please help me to make it clear.\n>------\n>Thanks in advance\n>\n>\n>Pragya Jain\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131225/ad836b02/attachment.html>\n\n','<1387878063.1792.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1387956834.73818.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-25 15:33:54',28800,'2013-12-25 07:33:54',NULL,'[Openstack] Fw: how the replicator in swift replicate a good copy','hello all,\n\nPlease reply my question.\nPlease help.\n------\n\nPragya Jain\n\n\n\n\nOn Tuesday, 24 December 2013 3:25 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nas said in many documents, A hash file is created for each partition which contains hashes of each directory in the partition. Replicator continuously examines each partition. Each of three hash file are compared. If hashes are different, Directory that need to be replicated is copied over.\n>\n>My question is:\n>\n>?- what is the mean of directory here? Is directory representing account database,container databese and objects?\n>?- If there is any fault or difference found while comparing the hashes, What is copied over - the whole partition or the particular directory whose hash is different?\n>\n>Please help me to make it clear.\n>----\n>Thanks in advance\n>\n>Pragya jain\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131225/289701a7/attachment.html>\n\n','<1387878957.20678.YahooMailNeo@web193601.mail.sg3.yahoo.com>',NULL),('<1387956941.56200.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-25 15:35:41',28800,'2013-12-25 07:35:41',NULL,'[Openstack] Fw: can I create account using swift CLI','hello all,\n\nPlease reply my question.\nPlease help.\n------\n\nPragya Jain\n\n\n\n\nOn Tuesday, 24 December 2013 2:45 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nI installed swift on my laptop by creating a virtual machine of ubuntu 12.04 LTS desktop using the document http://docs.openstack.org/developer/swift/development_saio.html\n>\n>I am using swift CLI for working with swift\n>\n>For adding an account in Swift, I first modify /etc/swift/proxy-server.conf and add italic line in it.\n>--------\n>[filter:tempauth]\n>use = egg:swift#tempauth\n>user_admin_admin = admin .admin .reseller_admin\n>user_test_tester = testing .admin\n>user_test2_tester2 = testing2 .admin\n>user_test_tester3 = testing3\n>*user_prag2648_pragya = pj2648 .admin .reseller_admin*\n>--------\n>and, then restart proxy\n>\n>My question is:\n>Can I create account using swift CLI?\n>If yes, then how?\n>If no, then Is there any other way to create an\n account?\n>\n>\n>\n>\n>Thanks \n>\n>\n>\n>Pragya Jain\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131225/4d5add09/attachment.html>\n\n','<1387876507.97062.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1387956968.31563.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-25 15:36:08',28800,'2013-12-25 07:36:08',NULL,'[Openstack] Fw: how to integrate horizon with swift','\n\nhello all,\n\nPlease reply my question.\nPlease help.\n------\n\nPragya Jain\n\n\nOn Tuesday, 24 December 2013 2:32 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nI installed swift on my laptop by creating a virtual machine of ubuntu 12.04 LTS desktop using the document http://docs.openstack.org/developer/swift/development_saio.html\n>It provides CLI interface for working with swift.\n>I need a GUI interface for the same.\n>For this purpose, I want to integrate Horizon with it.\n>Does it solve my purpose of GUI interface?\n>And, what commands should I follow to integrate horizon with swift?\n>-----------\n>\n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131225/7c15f951/attachment.html>\n\n','<1387875727.64477.YahooMailNeo@web193601.mail.sg3.yahoo.com>',NULL),('<1388080414-sup-7005@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-26 09:54:04',-28800,'2013-12-26 17:54:04',NULL,'[Openstack] How to achieve HA and Scalability for Neutron','Excerpts from Jay Pipes\'s message of 2013-12-26 08:58:10 -0800:\n> On 12/26/2013 07:43 AM, skywalker.nick at gmail.com wrote:\n> > Hi stackers,\n> > I\'m preparing for an OpenStack cloud in the production system. I\'ve\n> > achieved HA and load balancing for most of the components to a certain\n> > degree.\n> > Finally I find it hard for Neutron to do such configuration. Are there\n> > any ways to run multiple l3-agents and dhcp-agents and cluster them\n> > together?\n> \n> Right, the Neutron L3 agent is the only OpenStack service that is not \n> stateless, and therefore you cannot use traditional load-balancing \n> across a set of identical nodes.\n> \n> That said, there\'s nothing wrong with running multiple L3 nodes, with \n> routers for different tenants hosted on different L3 agents. We do this \n> successfully in our deployment using a custom Neutron scheduler that my \n> colleague Alan Meadows wrote [1] and a Python script (also written by \n> Alan) that runs in cron looking for failures on an L3 agent and if \n> found, moves the routers from the failed node to a working one. [2]\n> \n\nThis sounds pretty great Jay. Do you have plans to submit it to Neutron\nas a standard feature? Pretty much everybody needs this.\n\n\n','<52BC6022.3030806@gmail.com>',NULL),('<1388244838-sup-7527@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-28 07:37:01',-28800,'2013-12-28 15:37:01',NULL,'[openstack-dev] [Openstack] Some question about image provision\n	in openstack','Excerpts from Pengfei Zhang\'s message of 2013-12-25 21:47:29 -0800:\n> Hi,\n>      I come across two question about the image provision and distribute in openstack(nova),\n> 1.Afaik, in current version, nova-compute use the curl to download image from glance (or other places). Are there any alternative methods to choose (such torrent)?\n\nWe\'ve been looking into alternatives as part of the TripleO project to\ndeploy OpenStack on top of itself. Torrent-like methods do look\npromising.\n\n> 2.In fact, to boot a VM above hypervisor, there is no need to transfer the whole image-file to local. Will the mechanism to transfer the image on demand makes sense?\n>\n\nThe simplest solution like that today that I know of is to put your\nimage storage in CEPH, setup Cinder to use CEPH, and then boot from\nvolume with thin provisioning. The image will never be \"transferred\",\nthe root volume will just always live on a writable CEPH snapshot.\n\n\n','<B322DD86-5DFB-46D5-9CE9-76D8C6A07BDD@gmail.com>',NULL),('<1388245644-sup-8622@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-28 07:57:58',-28800,'2013-12-28 15:57:58',NULL,'[openstack-dev] [nova] minimum review period for functional\n	changes that break backwards compatibility','Hi Phil. Thanks for the well reasoned and poignant message urging\ncaution and forethought in change management. I agree with all of the\nsentiments and think that we can do better in reasoning about the impact\nof changes. I think this just puts further exposure on the fact that\nNova needs reviewers desperately so that reviewers can slow down.\n\nHowever, I think this is primarily an exposure in our gate testing. If\nthere are older OS\'s we want to be able to support, we should be booting\nthem in the gate and testing that the ephemeral disk works on them. What\nis a cloud that can\'t boot workloads?\n\nWhile our ability to reason is a quite effective way to stop emergent\nproblems, we know these are precious and scarce resources, and thus\nwe should use mechanical methods before falling back to reviewers and\ndevelopers.\n\nSo, I\'d suggest that we add a test that the ephemeral disk mounts in\nany desired OS\'s to tempest. If that is infeasible (due to nested KVM\nin the gate being slllooooowwww) then I\'m afraid I don\'t have a solution.\n\nExcerpts from Day, Phil\'s message of 2013-12-28 07:21:16 -0800:\n> Hi Folks,\n> \n> I know it may seem odd to be arguing for slowing down a part of the review process, but I\'d like to float the idea that there should be a minimum review period for patches that change existing functionality in a way that isn\'t backwards compatible.\n> \n> The specific change that got me thinking about this is https://review.openstack.org/#/c/63209/ which changes the default fs type from ext3 to ext4.    I agree with the comments in the commit message that ext4 is a much better filesystem, and it probably does make sense to move to that as the new default at some point, however there are some old OS\'s that may still be in use that don\'t support ext4.  By making this change to the default without any significant notification period this change has the potential to brake existing images and snapshots.  It was already possible to use ext4 via existing configuration values, so there was no urgency to this change (and no urgency implied in the commit messages, which is neither a bug or blueprint).\n> \n> I\'m not trying to pick out the folks involved in this change in particular, it just happened to serve as a good and convenient example of something that I think we need to be more aware of and think about having some specific policy around.  On the plus side the reviewers did say they would wait 24 hours to see if anyone objected, and the actual review went over 4 days - but I\'d suggest that is still far too quick even in a non-holiday period for something which is low priority (the functionality could already be achieved via existing configuration options) and which is a change in default behaviour.  (In the period around a major holiday there probable needs to be an even longer wait).     I know there are those that don\'t want to see blueprints for every minor functional change to the system, but maybe this is a case where a blueprint being proposed and reviewed may have caught the impact of the change.    With a number of people now using a continual deployment approach any chan\n ge in default behaviour needs to be considered not just  for the benefits it brings but what it might break.  The advantage we have as a community is that there are lot of different perspectives that can be brought to bear on the impact of functional changes, but we equally have to make sure there is sufficient time for those perspectives to emerge.\n> \n> Somehow it feels that we\'re getting the priorities on reviews wrong when a low priority changes like this which can  go through in a matter of days, when there are bug fixes such as https://review.openstack.org/#/c/57708/ which have been sitting for over a month with a number of +1\'s which don\'t seem to be making any progress.\n> \n> Cheers,\n> Phil\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F5838B@G6W2490.americas.hpqcorp.net>',NULL),('<1388246630-sup-1666@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-28 08:23:45',-28800,'2013-12-28 16:23:45',NULL,'[openstack-dev] [Spam]  [TripleO] UnderCloud & OverCloud','Excerpts from LeslieWang\'s message of 2013-12-24 19:19:52 -0800:\n> Dear All,\n> Merry Christmas & Happy New Year!\n> I\'m new in TripleO. After some investigation, I have one question on UnderCloud & OverCloud. Per my understanding, UnderCloud will pre-install and set up all baremetal servers used for OverCloud. Seems like it assumes all baremetal server should be installed in advance. Then my question is from green and elasticity point of view. Initially OverCloud should have zero baremetal server. Per user demands, OverCloud Nova Scheduler should decide if I need more baremetal server, then talk to UnderCloud to allocate more baremetal servers, which will use Heat to orchestrate baremetal server starts. Does it make senses? Does it already plan in the roadmap?\n> If UnderCloud resources are created/deleted elastically, why not OverCloud talks to Ironic to allocate resource directly? Seems like it can achieve same goal. What else features UnderCloud will provide? Thanks in advance.\n> Best RegardsLeslie                           \n\nHaving the overcloud scheduler ask for new servers would be pretty\ninteresting. It takes most large scale servers several minutes just to\nPOST though, so I\'m not sure it is going to work out well if you care\nabout latency for booting VMs.\n\nWhat might work is to use an auto-scaler in the undercloud though, perhaps\nhaving it informed by the overcloud in some way for more granular policy\npossibilities, but even just knowing how much RAM and CPU are allocated\nacross the compute nodes would help to inform us when it is time for\nmore compute nodes.\n\nAlso the scale-up is fun, but scaling down is tougher. One can only scale\ndown off nodes that have no more compute workloads. If you have live\nmigration then you can kick off live migration before scale down, but\nin a highly utilized cluster I think that will be a net loss over time\nas the extra load caused by a large scale live migration will outweigh\nthe savings from turning off machines. The story might be different for\na system built on network based volumes like CEPH,  I\'m not sure.\n\nAnyway, this is really interesting to think about, but it is not\nsomething we\'re quite ready for yet. We\'re just getting to the point\nof being able to deploy software updates using images, and then I hope\nto focus on improving usage of Heat with rolling updates and the new\nsoftware config capabilities. After that it may be that we can look at\nhow to scale down a compute cluster automatically. :)\n\n\n','<BAY169-W522DEF3406C781553FB227B2C30@phx.gbl>',NULL),('<1388255541.61.1381905927231.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-16 06:45:26',0,'2013-10-16 06:45:26',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #36','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/36/>\n\n------------------------------------------\n[...truncated 20941 lines...]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_http_image[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_http_image[gate] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_image_with_min_ram[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_image_with_min_ram[gate] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_remote_image[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_remote_image[gate] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_then_upload[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_then_upload[gate] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_with_invalid_container_format[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_with_invalid_container_format[gate] ... ok\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_with_invalid_disk_format[gate]\ntempest.api.image.v1.test_images.CreateRegisterImagesTest.test_register_with_invalid_disk_format[gate] ... ok\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML)\nsetUpClass (tempest.api.network.test_security_groups.SecGroupTestXML) ... skipped u\'Neutron support is required\'\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_container_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_create_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_delete_container[gate,smoke] ... ok\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_limits.TestServerStackLimits.test_exceed_max_template_size_fails[gate]\ntempest.api.orchestration.stacks.test_limits.TestServerStackLimits.test_exceed_max_template_size_fails[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\nSlowest Tests\nTest id                                                                                                                              Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------------------  -----------\ntempest.api.compute.servers.test_servers_negative.ServersNegativeTestXML.test_personality_file_contents_not_encoded[gate,negative]   411.084\ntempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_unpause_non_existent_server[gate,negative]            410.367\ntempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON.test_personality_file_contents_not_encoded[gate,negative]  409.155\ntempest.api.compute.servers.test_servers_negative.ServersNegativeTestXML.test_unpause_non_existent_server[gate,negative]             408.688\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]                       197.706\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]               173.467\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                               79.915\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]                    38.377\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]                      37.851\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]                     35.337\n\n----------------------------------------------------------------------\nRan 1353 tests in 2197.799s\n\nOK (skipped=69)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-584082-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-584082.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-584082/36/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<840131399.59.1381818634031.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1388266565-sup-7701@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-28 13:40:08',-28800,'2013-12-28 21:40:08',NULL,'[openstack-dev] [Ironic]Communication between Nova and Ironic','Excerpts from LeslieWang\'s message of 2013-12-24 03:01:51 -0800:\n> Hi Oleg,\n> \n> Thanks for your promptly reply and detail explanation. Merry Christmas and wish you have a happy new year!\n> \n> At the same time, I think we can discuss more on Ironic is for backend driver for nova. I\'m new in ironic. Per my understanding, the purpose of bare metal as a backend driver is to solve the problem that some appliance systems can not be virtualized, but operator still wants same cloud management system to manage these systems. With the help of ironic, operator can achieve the goal, and use one openstack to manage these systems as VMs, create, delete, deploy image etc. this is one typical use case.\n> \n> In addition, actually I\'m thinking another interesting use case. Currently openstack requires ops to pre-install all servers. TripleO try to solve this problem and bootstrap openstack using openstack. However, what is missing here is dynamic power on VM/switches/storage only. Imagine initially lab only had one all-in-one openstack controller. The whole work flow can be:\n>   1. Users request one VM or baremetal server through portal.\n>   2. Horizon sends request to nova-scheduler\n>   3. Nova-scheduler finds no server, then invoke ironic api to power on one through IPMI, and install either hyper visor or appliance directly.\n>   4. If it need create VM, Nova-scheduler will find one compute node, and send message for further processing.\n> \n> Based on this use case, I\'m thinking whether it makes sense to embed this ironic invokation logic in nova-scheduler, or another approach is as overall orchestration manager, TripleO project has a TripleO-scheduler to firstly intercept the message, invoke ironic api, then heat api which calls nova api, neutron api, storage api.  In this case, TripleO only powers on baremetal server running VM, nova is responsible to power on baremetal server running appliance system. Sounds like latter one is a good solution, however the prior one also works. So can you please comment on it? Thanks!\n> \n\nI think this basically already works the way you desire. The scheduler\n_does_ decide to call ironic, it just does so through nova-compute RPC\ncalls. That is important, as this allows the scheduler to hand-off the\nentire work-flow of provisioning a machine to nova-compute in the exact\nsame way as is done for regular cloud workloads.\n\n\n','<BAY405-EAS309812DB05D532EF51FFB55B2C00@phx.gbl>',NULL),('<1388328526-sup-1649@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-29 06:53:30',-28800,'2013-12-29 14:53:30',NULL,'[openstack-dev] [nova] minimum review period for functional\n	changes that break backwards compatibility','Excerpts from Andreas Jaeger\'s message of 2013-12-28 23:05:45 -0800:\n> On 12/29/2013 07:50 AM, Robert Collins wrote:\n> > One possible reason to want a different judgment call is that the\n> > logic about impacted OS\'s was wrong - I claimed (correctly) that every\n> > OS has support for ext4, but neglected to consider the 13 year\n> > lifespan of RHEL...\n> > https://access.redhat.com/site/support/policy/updates/errata/ shows\n> > that RHEL 3 and 4 are both still supported, and neither support ext4.\n> > So folk that are running apps in those legacy environments indeed\n> > cannot move.\n> \n> SUSE Linux Enterprise Server 11 comes with ext3 as default as well - and\n> does not include ext4 support, so this really a bad change for SLES,\n> \n\nPerhaps people should run SP3?\n\nhttps://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/\n\nClaims that ext4 write support is included, it just has to be toggled\nto on.\n\nIt is also worth noting that this is just a convenience filesystem. You\ncan mkfs whatever you want on top of the block device.\n\n\n','<52BFC9C9.7070704@suse.com>',NULL),('<1388432210.76019.YahooMailNeo@web125903.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-30 11:36:50',-28800,'2013-12-30 19:36:50',NULL,'[Openstack-docs] Disqus on all books?','I tend to agree. Comments are more social, but quickly out of date. Bugs are actionable. If we should the link for an active bug against a page for the comments to be posted on launchpad, then that would be helpful.?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\n\nOn Monday, December 30, 2013 6:18 AM, Diane Fleming <diane.fleming at RACKSPACE.COM> wrote:\n \nNow that David Cramer has implemented the \"log a bug against this page\"\nfeature, I don\'t think we need disqus for these books.\n\nDisqus is not particularly useful (as far as I\'m concerned!)\n\n\nDiane\n----------------------------------------------\nDiane Fleming\nSoftware Developer II - US\n\ndiane.fleming at rackspace.com\nCell? 512.323.6799\nOffice 512.874.1260\nSkype drfleming0227\nGoogle-plus diane.fleming at gmail.com\n\n\n\n\n\n\nOn 12/30/13 4:19 AM, \"Andreas Jaeger\" <aj at suse.com> wrote:\n\n>I noticed that some of the manuals that we build from trunk do not have\n>disqus enabled:\n>* End User Guide\n>* Admin User Guide\n>* Cloud Administrator Guide\n>* Operations Guide\n>* Security Guide\n>* Virtual Machine Image Guide\n>* Training Guides\n>\n>Which of these should get disqus enabled?\n>\n>I can do the changes but like to know whether this is desired,\n>Andreas\n>-- \n> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>? SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>?  GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>? ? GPG fingerprint = 93A3 365E CE47 B889 DF7F? FED1 389A 563C C272 A126\n>\n>_______________________________________________\n>Openstack-docs mailing list\n>Openstack-docs at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20131230/3e4301c6/attachment.html>\n\n','<CEE6DC19.1FE1B%diane.fleming@rackspace.com>',NULL),('<1388432622.69543.YahooMailNeo@web125906.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-30 11:43:42',-28800,'2013-12-30 19:43:42',NULL,'[Openstack-docs] Publishing associate training guide','All looks good. Thanks for taking care of this Andreas.\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\n\nOn Sunday, December 29, 2013 11:07 AM, Andreas Jaeger <aj at suse.com> wrote:\n \nOn 12/29/2013 07:51 PM, Andreas Jaeger wrote:\n> On 12/29/2013 07:09 PM, Sean Roberts wrote:\n>> A lot less complicated. I agree with both of your proposals. \n>> - Should I create a patch to remove training guides from stable/havana?\n> \n> We do not remove anything from stable/havana - we only backport. So,\n> just leave it as is\n> \n>> - Andreas will modify the manuals job to publish to docs.openstack.org/training-guides?\n> \n> Upon further investigation, we do not need to change anything on the\n> publishing job, the following patch should be all you need:\n> https://review.openstack.org/64369\n> \n> what\'s missing is a patch to the various index.html files to add a link\n> to the training-guides. I\'ll do this as a followup later, let\'s get\n> first the patch above merged and test that it really does what we expect\n> it to do.\n\nHere\'s the patch https://review.openstack.org/#/c/64372/ - please do not\napprove before the other one is in and it has been double checked that\nthe links work as designed (see my first review comment),\n\n\n> [...]\n\nAndreas\n-- \nAndreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n? SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n?  GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n? ? GPG fingerprint = 93A3 365E CE47 B889 DF7F? FED1 389A 563C C272 A126\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20131230/cbbcd764/attachment.html>\n\n','<52C072E0.3030807@suse.com>',NULL),('<1388432688.21866.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-30 13:44:48',-21600,'2013-12-30 19:44:48',NULL,'[openstack-dev] [All] tagged commit messages','\nOn Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote:\n> I like the idea of having custom tags. I\'m a bit concerned about the\n> implications this might have with cross-project collaborations. I\n> mean, people contributing to more projects will have to be aware of\n> the many possible differences in this area.\n> \n> That being said, I can think of some cases where we this could be\n> useful for other projects. However, I\'d encourage to keep common tags\n> documented somewhere, perhaps this common tags shouldn\'t be part of\n> the `Tags:` \'field\', which you already mentioned above.\n\nIf I may be allowed a tangent?should a mechanism external to the commit\nmessage be allowed for attaching a tag to a review?  Consider the recent\next3/ext4 change: a reviewer could browse that and say, \"This should\nhave a DeploymentImpact tag.\"  With the tags as so far described in this\nthread, that has to be something added by the submitter (or a new\nversion of the patch uploaded by a reviewer).  Can we create a mechanism\nthat would allow a reviewer to attach such a tag without having to\nmodify any part of the review?  Can the mechanism allow such an\nattachment even if the review has already been merged?\n\nJust something to think about :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n\n','<20131230100457.GB3550@redhat.com>',NULL),('<1388453333-sup-5447@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-30 17:30:44',-28800,'2013-12-31 01:30:44',NULL,'[openstack-dev] [nova] - Revert change of default ephemeral fs\n	to ext4','Excerpts from Day, Phil\'s message of 2013-12-30 11:05:17 -0800:\n> Hi, so it seems we were saying the same thing - new vms get a shared \"blank\" (empty) file system,  not blank disc.  How big a problem it is that in many cases this will be the already created ext3 disk and not ext4 depends I guess on how important consistency is to you (to me its pretty important).  Either way the change as it stands wont give all new vms an ext4 fs as intended,  so its flawed in that regard.\n> \n> Like you I was thinking that we may have to move away from \"default\" being in the file name to fix this.\n> \n\nIndeed, \"default\"\'s meaning is mutable and thus it is flawed as a\ncache key.\n\n\n','<hi14iy5olepmrwgqanvh6l1w.1388430315165@email.android.com>',NULL),('<1388455755.93046.1368440503291.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-05-13 12:21:43',7200,'2013-05-13 10:21:43',NULL,'[Openstack-operators] Problem with multiple nova-consoleauth','On my setup, they run as active / active by the way, since I\'m using memcached for storing tokens. \n\n\n\n----- Original Message -----\n\nFrom: \"Razique Mahroua\" <razique.mahroua at gmail.com> \nTo: \"Emilien Macchi\" <emilien.macchi at enovance.com> \nCc: \"Juan Jos? Pavlik Salles\" <jjpavlik at gmail.com>, openstack-operators at lists.openstack.org \nSent: Monday, May 13, 2013 10:15:11 AM \nSubject: Re: [Openstack-operators] Problem with multiple nova-consoleauth \n\nHi, \nI myself use two instances of console-auth, but they act as active/ passive via Pacemaker/ Corosync \n\nregards, \n\nRazique Mahroua - Nuage & Co \nrazique.mahroua at gmail.com \nTel : +33 9 72 37 94 15 \n\n\nLe 13 mai 2013 ? 09:38, Emilien Macchi < emilien.macchi at enovance.com > a ?crit : \n\n\n\n\nHi, \n\n\nWe are running : \n\n\n    * 2 memcached servers on dedicated nodes \n    * 2 nova-consoleauth with memcached_servers flag in nova.conf (don\'t forget to install python-memcache on nova-consoleauth nodes) \n    * 2 nova-html5proxy in load balancing with HAproxy in front-end. \n\nIt works fine. \n\n\nCheers ! \n\n\nEmilien \n\n\n----- Original Message -----\n\nFrom: \"Juan Jos? Pavlik Salles\" < jjpavlik at gmail.com > \nTo: \"Sam Morrison\" < sorrison at gmail.com > \nCc: openstack-operators at lists.openstack.org \nSent: Monday, May 13, 2013 2:37:56 AM \nSubject: Re: [Openstack-operators] Problem with multiple nova-consoleauth \n\nGreat, thank guys!!, Should i run one memcache server??? instead of running many of them, one in every compute node, using the configuration John Dewey says. \n\n\n2013/5/12 Sam Morrison < sorrison at gmail.com > \n\n<blockquote>\n\nIf you run multiple consoleauths they need to talk to the same memcached server. \n\nSam \n\n\nOn 12/05/2013, at 11:46 AM, Juan Jos? Pavlik Salles < jjpavlik at gmail.com > wrote: \n\n\n<blockquote>\n\n\n\nHi guys, on friday i was trying to reach my vms through novnc proxy and i ran into some kind of odd behaviour. One every two attempts were successfull so we started watching logs. after a couple of hours stopping and starting services we realized that this strange behaviour was due to we had two nova-consoleauth instances running, one per compute node. We stopped one of the instances a everything started to work just fine, even both novncproxies. \nI found this https://bugs.launchpad.net/nova/+bug/989337 but it\'s suppossed to be fixed in folsom, and i\'m running grizzly. \n\nShould i run just one instance of nova-consoleauth? \n_______________________________________________ \n\nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n\n\n\n\n</blockquote>\n\n\n\n\n-- \nPavlik Salles Juan Jos? \n\n_______________________________________________ \nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n_______________________________________________ \nOpenStack-operators mailing list \nOpenStack-operators at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators \n\n</blockquote>\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130513/a8872e19/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130513/a8872e19/attachment.jpg>\n\n','<C75DC865-32D2-4F9A-A7FD-1BB0664383AD@gmail.com>',NULL),('<1388564631.78498.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-01 16:23:51',28800,'2014-01-01 08:23:51',NULL,'[Openstack] Happy new year all','happy new year to all stackers\n\npragya Jain\n\n\n\nOn Wednesday, 1 January 2014 10:50 AM, Remo Mattei <Remo at Mattei.org> wrote:\n \nyou have a good year David,?\n>\n>\n>Ciao\n>--?\n>Remo Mattei\n>\n>\n>\n>December 31, 2013 at 21:10:21, David Easter (deaster at mirantis.com) ha scritto:\n>It\'s midnight somewhere! ?(Past midnight in most\nplaces.??:-) \n>\n>\n>Happy New Year!\n>\n>\n>-David J. Easter\n>Product Line Manager, Mirantis\n>\n>On Tuesday, December 31, 2013, Dnsbed Ops wrote:\n>\n>happy new year all~\n>>\n>>\n>>\n>>Happy new year opensthackers :)\n>>>\n>>>\n>>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n!DSPAM:2,52c3a33d308721368617628! _______________________________________________ \n>\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>Post to     : openstack at lists.openstack.org \n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>\n>\n>!DSPAM:2,52c3a33d308721368617628! \n>\n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140101/40950ec2/attachment.html>\n\n','<etPan.52c3a35c.43f18422.cf1@Remos-Macbook.local>',NULL),('<1388565552.98774.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-01 16:39:12',28800,'2014-01-01 08:39:12',NULL,'[Openstack] international standard for object storage architecture','hello,\n\ni am searching for an international standard for object storage architecture on cloud.\nCan somebody help me?\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140101/483dc481/attachment.html>\n\n',NULL,NULL),('<1388596459.90573.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 01:14:19',28800,'2014-01-01 17:14:19',NULL,'[Openstack] international standard for object\n	storage	architecture','thanks for the reply\n\nare you definitely sure that there is not a general standard?\n\nand my 2nd question is:\nyou give three examples- swift, ceph and mogilefs\nswift and ceph are examples of object storage but mogilefs is a distributed file system. so, is it an example of file storage or object storage\n\nand what do you think about OSD standards?\n\nthanks again?\n\nPragya Jain\n\n\n\nOn Wednesday, 1 January 2014 2:36 PM, Dnsbed Ops <ops at dnsbed.com> wrote:\n \nWe have tested/used some object storage products including swift, ceph, \n>mogilefs. Each of them has the different design and implement. So I was \n>thinking a general standard does not exist yet.\n>\n>\n>\n>> i am searching for an international standard for object storage\n>> architecture on cloud.\n>> Can somebody help me?\n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140102/b4718c97/attachment.html>\n\n','<52C3D886.9090109@dnsbed.com>',NULL),('<1388619248-sup-4468@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-01 15:42:38',-28800,'2014-01-01 23:42:38',NULL,'[openstack-dev] [nova] minimum review period for functional\n	changes that break backwards compatibility','Excerpts from Tim Bell\'s message of 2014-01-01 13:30:32 -0800:\n> \n> > - Changes in default behaviour:   Always likely to affect existing systems in some way.   Maybe we should have an additional type of review vote that comes from people who are recognised as reperensting large production deployments ?\n> \n> This is my biggest worry...  there are changes which may be technically valid but have a significant disruptive impact on those people who are running clouds. Asking the people who are running production OpenStack clouds to review every patch to understand the risks and assess the migration impact is asking a lot.\n> \n> What processes are in place to ensure that a technically correct patch does not have major impact on those of us who are running large scale OpenStack clouds in production ? DocImpact tagging is not sufficient as this implies the change is the right thing to do but needs procedures defined.\n> \n\nIf it\'s not tested, it is broken. A wise group of developers once\nsaid that.\n\nI think most things like this become a non issue if we test them in the\ngate. If you are running a large production cloud and not making sure\nwhat is important to you is tested in the gate, then IMO, you are doing\nit wrong.\n\nAlso I\'d be shocked to see a deployer who just consumes what comes out\nof upstream without running their own private integration tests. So if\nyou don\'t have an integration test that makes sure you can still mount\nephemeral on supported images, then again, you\'re doing it wrong. It is\nbetter to get your stuff in the gate, but if you have something local\nthat you must keep private, you can still do that and still raise a\n\"please revert this patch\" bug.\n\nBasically don\'t rely on JUST the humans to catch things. When there is\na hole in the automation and humans do manage to catch things, that is\ngreat, but it should be a rarity. The catchers _SHOULD_ be adding tests\nto make sure that the hole is plugged. No amount of review process is\ngoing to be as effective as adequate test coverage.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D98F41D6@CERNXCHG02.cern.ch>',NULL),('<1388648330.8827.5.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 15:38:50',28800,'2014-01-02 07:38:50',NULL,'[Openstack] [OpenStack] How to add a RBD volume snapshot rollback\n operation to Cinder','Hi,\n\nFirst time mailing to a list.\n\nI\'m trying to add a RBD volume snapshot rollback operation to Cinder.\nI\'ve just got through WSGI part of Cinder API code and have read some\npieces of Cinder Volume. Now there is not much time for me to complete\nthe whole code base (with Ceph driver) very carefully, I need some\nadvice. \n\nIs adding a Extension Controller the most suitable way to do this? How\nto deal with snapshot and volume state transformation, would it affect\nother part of Cinder codes? What parts of Cinder codes I should pay\nspecial attention?\n\nMany thanks.\n\nSome background information: \n\nWe\'re planning to use Cinder bootable volume (Ceph RBD as backend) as\ninstance root disk in my company\'s OpenStack environment. Creating a\nvolume snapshot from image, and then use this snapshot to spawn instance\nroot volumes.\n\nTo backup volume state, I\'ve thought of Cinder-Backup service (still\nneed to add a in-use backup for Cinder), but it takes too much space (a\n80G volume would take at least 248G space for base backup image with x3\nCeph replication ratio). The other way is volume snapshot, but in this\ncase when restoring volume data, I have to create a new volume from\nsnapshot, destroy the original instance (there\'s no API to change a\ninstance\'s bootable volume), and create a new instance from new volume. \n\nThe old volume can not be removed, for a snapshot is referencing to it\n(the snapshot must be kept). If I do this again and again, there would\nbe many snapshots referencing to many different volumes, and I have to\nkeep these volumes (not used elsewhere), which is a mess.\n\n\n\n\n',NULL,NULL),('<1388652122.10057.14.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 16:42:02',28800,'2014-01-02 08:42:02',NULL,'[Openstack] [OpenStack] How to add a RBD volume snapshot\n rollback operation to Cinder','? 2014-01-02?? 16:01 +0800?Haomai Wang???\n> On Thu, Jan 2, 2014 at 3:38 PM, Changqian Zuo <dummyhacker85 at gmail.com> wrote:\n> > Hi,\n> >\n> > First time mailing to a list.\n> >\n> > I\'m trying to add a RBD volume snapshot rollback operation to Cinder.\n> > I\'ve just got through WSGI part of Cinder API code and have read some\n> > pieces of Cinder Volume. Now there is not much time for me to complete\n> > the whole code base (with Ceph driver) very carefully, I need some\n> > advice.\n> >\n> > Is adding a Extension Controller the most suitable way to do this? How\n> > to deal with snapshot and volume state transformation, would it affect\n> > other part of Cinder codes? What parts of Cinder codes I should pay\n> > special attention?\n> >\n> > Many thanks.\n> >\n> > Some background information:\n> >\n> > We\'re planning to use Cinder bootable volume (Ceph RBD as backend) as\n> > instance root disk in my company\'s OpenStack environment. Creating a\n> > volume snapshot from image, and then use this snapshot to spawn instance\n> > root volumes.\n> \n> From your description, it seemed that you can use rbd as nova backend directly.\n> \n> nova.conf:\n>  libvirt_image_type=\'rbd\'\n> \n> more options can be find at nova/virt/libvirt/imagebackend.py\n> \n> >\n> > To backup volume state, I\'ve thought of Cinder-Backup service (still\n> > need to add a in-use backup for Cinder), but it takes too much space (a\n> > 80G volume would take at least 248G space for base backup image with x3\n> > Ceph replication ratio). The other way is volume snapshot, but in this\n> > case when restoring volume data, I have to create a new volume from\n> > snapshot, destroy the original instance (there\'s no API to change a\n> > instance\'s bootable volume), and create a new instance from new volume.\n> >\n> > The old volume can not be removed, for a snapshot is referencing to it\n> > (the snapshot must be kept). If I do this again and again, there would\n> > be many snapshots referencing to many different volumes, and I have to\n> > keep these volumes (not used elsewhere), which is a mess.\n> >\n> >\n> >\n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \nThanks,\n\nI do know in Havana release, we could use RBD as Nova image storage.\nThere are reasons I choose such a way to launch an instance. Firstly,\nour company are moving from XCP to OpenStack, we have an old framework\nand business mode to manage Xen instance and VDIs, so hoping to fit\nOpenStack into this framework. The decision is made by my boss.\nSecondly, I myself would prefer this way, for it would be to easy to\nmanage root disk, for example, I could use Cinder Backup service to do\nsome remote backup. Using nova image, the root disk may not be easily\nseen.\n\n\n\n\n','<CACJqLyaa43y05DPr78byR78y1OqBgH9t5unAcoAVF1g7b0qBqg@mail.gmail.com>',NULL),('<1388657663.2237.5.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 18:14:23',28800,'2014-01-02 10:14:23',NULL,'[Openstack] [OpenStack] How to add a RBD volume snapshot\n rollback operation to Cinder','? 2014-01-02?? 16:53 +0800?Haomai Wang???\n> On Thu, Jan 2, 2014 at 4:42 PM, Changqian Zuo <dummyhacker85 at gmail.com> wrote:\n> > ? 2014-01-02?? 16:01 +0800?Haomai Wang???\n> >> On Thu, Jan 2, 2014 at 3:38 PM, Changqian Zuo <dummyhacker85 at gmail.com> wrote:\n> >> > Hi,\n> >> >\n> >> > First time mailing to a list.\n> >> >\n> >> > I\'m trying to add a RBD volume snapshot rollback operation to Cinder.\n> >> > I\'ve just got through WSGI part of Cinder API code and have read some\n> >> > pieces of Cinder Volume. Now there is not much time for me to complete\n> >> > the whole code base (with Ceph driver) very carefully, I need some\n> >> > advice.\n> >> >\n> >> > Is adding a Extension Controller the most suitable way to do this? How\n> >> > to deal with snapshot and volume state transformation, would it affect\n> >> > other part of Cinder codes? What parts of Cinder codes I should pay\n> >> > special attention?\n> >> >\n> >> > Many thanks.\n> >> >\n> >> > Some background information:\n> >> >\n> >> > We\'re planning to use Cinder bootable volume (Ceph RBD as backend) as\n> >> > instance root disk in my company\'s OpenStack environment. Creating a\n> >> > volume snapshot from image, and then use this snapshot to spawn instance\n> >> > root volumes.\n> >>\n> >> From your description, it seemed that you can use rbd as nova backend directly.\n> >>\n> >> nova.conf:\n> >>  libvirt_image_type=\'rbd\'\n> >>\n> >> more options can be find at nova/virt/libvirt/imagebackend.py\n> >>\n> >> >\n> >> > To backup volume state, I\'ve thought of Cinder-Backup service (still\n> >> > need to add a in-use backup for Cinder), but it takes too much space (a\n> >> > 80G volume would take at least 248G space for base backup image with x3\n> >> > Ceph replication ratio). The other way is volume snapshot, but in this\n> >> > case when restoring volume data, I have to create a new volume from\n> >> > snapshot, destroy the original instance (there\'s no API to change a\n> >> > instance\'s bootable volume), and create a new instance from new volume.\n> >> >\n> >> > The old volume can not be removed, for a snapshot is referencing to it\n> >> > (the snapshot must be kept). If I do this again and again, there would\n> >> > be many snapshots referencing to many different volumes, and I have to\n> >> > keep these volumes (not used elsewhere), which is a mess.\n> >> >\n> >> >\n> >> >\n> >> > _______________________________________________\n> >> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >> > Post to     : openstack at lists.openstack.org\n> >> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >>\n> >>\n> >>\n> > Thanks,\n> >\n> > I do know in Havana release, we could use RBD as Nova image storage.\n> > There are reasons I choose such a way to launch an instance. Firstly,\n> > our company are moving from XCP to OpenStack, we have an old framework\n> > and business mode to manage Xen instance and VDIs, so hoping to fit\n> > OpenStack into this framework. The decision is made by my boss.\n> > Secondly, I myself would prefer this way, for it would be to easy to\n> > manage root disk, for example, I could use Cinder Backup service to do\n> > some remote backup. Using nova image, the root disk may not be easily\n> > seen.\n> \n> Do you mean store all the images at Cinder too and clone bootable volume when\n> booting instance? Why need rollback?\n> \n> I\'m afraid that you can\'t get enough benefits from \"booting from volume\". There\n> exists many limits on this way. Such as injecting data failed, chaotic snapshot\n> management and others.\n> \n> \n> >\n> >\n> \n> \n> \n\nYes, we don\'t use ephemeral disk. We don\'t take instance snapshot,\ninstead, just take a volume snapshot (instance\'s root disk or data\nvolume, Yea, instance memory would be lost).\n\nThanks for the bug information. \n\n\n\n','<CACJqLybfAj3bcDAsYpWtx-r6eY-WzDDL4-h5SUTGZ3BZXsw7hA@mail.gmail.com>',NULL),('<1388679513-sup-9844@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-02 08:19:42',-28800,'2014-01-02 16:19:42',NULL,'[openstack-dev] [TripleO] Next weeks meeting cancelled?','Excerpts from Robert Collins\'s message of 2014-01-02 01:59:23 -0800:\n> A bunch of the TripleO folk are going to be at LCA. I\'d like to cancel\n> the meeting rather than get them all up at (IIRC) 3am.\n> \n> If folk who aren\'t going want to hold the meeting, thats fine - but I\n> won\'t be around to chair :)\n\nI think we may still have value for those of us not going to LCA. I\'ll\nchair.\n\n\n','<CAJ3HoZ2WEJtGkDZMJzf4c1-Y5AkbL8SbFQ+yCx2A6YJh1qiFOQ@mail.gmail.com>',NULL),('<1388686808-sup-9642@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 10:29:19',-28800,'2014-01-02 18:29:19',NULL,'[Openstack] Can I move keystone-signing-XXX files out of /tmp ?','Excerpts from Adam Young\'s message of 2014-01-02 08:51:04 -0800:\n> On 12/24/2013 11:30 AM, Xin Zhao wrote:\n> > Hello,\n> >\n> > I am running a Grizzly multi-host test cluster on RHEL6. On the \n> > controller node, there are several keystone-signing-XXXX files \n> > automatically created by the daemons. But if some disk cleanup scripts \n> > kick in and remove them, that will cause problem to the services. So I \n> > wonder if I can move them to a more permanent place like /var/cache/ ? \n> > Any advice and best practice experience on this will be greatly \n> > appreciated.\n> Yes, so long as the services get config option knowing where to look for \n> the files, they can and should live in /var/cache. That is what RDO does \n> by default.  /tmp is a \"safe default and  developer friendly\" solution, \n> but not necessary for a live deployment.\n\nOdd that /tmp is ok and yet /var/cache is used otherwise. Since /tmp is\nblown away at reboot, I\'d expect /var/run not /var/cache. But meh,\ndoesn\'t matter too much I suppose.\n\n> \n> >\n> > $ ls -lrt /tmp\n> >\n> >  keystone-signing-tdtD3g\n> >  keystone-signing-swift\n> >  keystone-signing-nova\n> >  keystone-signing-eEXjn_\n> >  keystone-signing-xwSFNi\n> >  keystone-signing-YqxWd2\n\nThese random dirs are good, but the predictable ones open nova and swift\nup to local DOS. That isn\'t really an appropriate production default.\nBefore I run off and file a bug without background, has this already\nbeen addressed? I did a shallow dive trying to find where these come\nfrom and only see the randomized ones, so perhaps a pointer to the code\nthat made those would help?\n\n\n','<52C598F8.2000507@redhat.com>',NULL),('<1388697057-sup-5223@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 13:13:15',-28800,'2014-01-02 21:13:15',NULL,'[Openstack] international standard for object storage\n	architecture','Excerpts from pragya jain\'s message of 2014-01-01 09:14:19 -0800:\n> thanks for the reply\n> \n> are you definitely sure that there is not a general standard?\n> \n> and my 2nd question is:\n> you give three examples- swift, ceph and mogilefs\n> swift and ceph are examples of object storage but mogilefs is a distributed file system. so, is it an example of file storage or object storage\n> \n\nMogileFS isn\'t really a file system. There is a FUSE plugin but nobody\nreally wants to use it that way. It works basically identically to S3\nand Swift for a single tenant, though its APIs is a native protocol\ninstead of HTTP (uploads and downloads are still HTTP). It doesn\'t have\nthe concept of \"containers\" and is just a big flat key/value store,\nand it doesn\'t have multi-tenants, but it is basically a predecessor of\ntoday\'s object stores.\n\n\n','<1388596459.90573.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1388705025-sup-9807@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-02 15:27:49',-28800,'2014-01-02 23:27:49',NULL,'[openstack-dev] [Ceilometer] Vertica Storage Driver Testing','Excerpts from Herndon, John Luke\'s message of 2014-01-02 15:16:26 -0800:\n> Hi,\n> \n> I?m working on adding a vertica (www.vertica.com) storage driver to\n> ceilometer. I would love to get this driver into upstream. However, I?ve\n> run into a bit of a snag with the tests. It looks like all of the existing\n> storage drivers have ?in-memory? versions that are used for unit tests.\n> Vertica does not have an in-memory implementation, and is not trivial to\n> set-up. Given this constraint, I don?t think it will be possible to run\n> unit tests ?out-of-the-box? against a real vertica database.\n\nWell arguably those other implementations aren\'t really running against\na real database either so I don\'t see a problem with this.\n\n> \n> Vertica is mostly sql compliant, so I could use a sqlite or h2 backend to\n> test the query parts of the driver. Data loading can?t be done with\n> sqlite, and will probably need to be tested with mocks. Is this an\n> acceptable approach for unit tests, or do the tests absolutely need to run\n> against the database under test?\n>\n\nA fake Vertica or mocking it out seems like a good idea. I\'m not deeply\ninvolved with Ceilometer, but in general I think it is preferable to\ntest only the _code_ in unit tests. However, it may be a good idea to\nadopt an approach similar to Nova\'s approach and require that a 3rd\nparty run Vertica integration tests in the gate.\n\n\n','<CEEB4158.163BA%john.herndon@hp.com>',NULL),('<1388720299-sup-5993@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 19:38:44',-28800,'2014-01-03 03:38:44',NULL,'[Openstack] international standard for object storage\n	architecture','Excerpts from Dnsbed Ops\'s message of 2014-01-02 18:15:12 -0800:\n> On 2014-1-3 5:13, Clint Byrum wrote:\n> > MogileFS isn\'t really a file system. There is a FUSE plugin but nobody\n> > really wants to use it that way. It works basically identically to S3\n> > and Swift for a single tenant, though its APIs is a native protocol\n> > instead of HTTP (uploads and downloads are still HTTP). It doesn\'t have\n> > the concept of \"containers\" and is just a big flat key/value store,\n> > and it doesn\'t have multi-tenants, but it is basically a predecessor of\n> > today\'s object stores.\n> \n> Really? We have been using Mogilefs as an object storage in the \n> production environment with multi-tenants supported based on its \n> \"domain\" features.\n> \n\nIt has been several years since I deployed MogileFS. I suppose it has\nlearned some new tricks. :)\n\n\n','<52C61D30.2080207@dnsbed.com>',NULL),('<1388936252-sup-1473@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 07:40:52',-28800,'2014-01-05 15:40:52',NULL,'[openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore','Excerpts from Rushi Agrawal\'s message of 2014-01-05 05:41:58 -0800:\n> I can see people arguing in future over which top IDE\'s/editor\'s trashfiles\n> should or shouldn\'t be included in the gitignores. Also, I believe the\n> concept of global gitignore is a fantastic one.\n> \n\nHas it ever actually happened? Looks a little like a straw man to me.\n\n> What I\'ll suggest is, just not include any of the editor/IDE files in\n> project gitignores, AND mention how to set global gitignores for these\n> trashfiles in the wiki page where we give details of Gerrit/Jenkins/Git\n> https://wiki.openstack.org/wiki/GerritWorkflow\n> or\n> https://wiki.openstack.org/wiki/GerritJenkinsGithub\n> to aid a novice.\n> \n\nI think leaving them in is perfectly o-k. Contributors who use different\neditors and get annoyed that their files aren\'t ignored will just submit\na patch. This patch will take almost zero cognitive load from reviewers.\n\nWe have Oslo for algorithms, not configurations. We have global\nrequirements to control external _dependencies_. This is about neither.\nLeave them in, add them when people submit them. How is this at all hard\nor controversial to just let this keep working the way it works now?\n\n\n','<CAJvOsSz5YXy6SafKQb0UPrMN_2Ajkx4xOu=W8expdvyVeZFkPQ@mail.gmail.com>',NULL),('<1388937592.1990.3.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 10:59:52',-18000,'2014-01-05 15:59:52',NULL,'[openstack-dev] [OpenStack][Gantt][filters]\n AvailabilityZoneFilter in Gantt and Oslo','On Sun, 2014-01-05 at 22:13 +0800, Jay Lau wrote:\n\n> What about split the AvailabilityZoneFilter in Gantt to two filters,\n> one is AvailabilityZoneFilter which has same logic with oslo, the\n> other we can name it as AggregateAvailabilityZoneFilter which will\n> only handle availability_zone from aggregation metadata, this can make\n> sure Gantt can sync AvailabilityZoneFilter from oslo and make\n> AvailabilityZoneFilter a common scheduler filter for both Gantt and\n> Cinder. What do you think?\n\n++, though I\'d call the aggregate-related one\nAvailabilityZoneAggregateFilter instead, since an AZ > Aggregate.\n\nBest,\n-jay\n\n\n\n\n','<CAFyztAGjmXmDZO2GhZvKHO8gjg3QFLEAvqqPq8Z+_qt99Rcz2g@mail.gmail.com>',NULL),('<1388937693.1990.4.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 11:01:33',-18000,'2014-01-05 16:01:33',NULL,'[openstack-dev] why do we use pip -U in tox.ini?','On Sun, 2014-01-05 at 10:47 -0500, Sean Dague wrote:\n> While waiting some inordinate amount of time to compile lxml for a \n> tempest pep8 test, I started to wonder why is it that we are using -U on \n> all our pip install commands in tox (it\'s a pretty common pattern across \n> projects).\n> \n> It seems like requirements should be sufficient. Forcing -U to the \n> latest all the time seems like it would actually mask a ton of problems, \n> and makes sitepackages = True to be largely useless.\n> \n> I\'m sure it went in for a reason, so I\'d love to understand the reason, \n> to make sure that my instinct in disabling it in Tempest doesn\'t have a \n> ton of side effects.\n\n+1 to removing it. Makes runtime of tests longer as well...\n\n-jay\n\n\n\n','<52C97E8A.9020003@dague.net>',NULL),('<1388938063-sup-4792@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 08:10:11',-28800,'2014-01-05 16:10:11',NULL,'[openstack-dev] why do we use pip -U in tox.ini?','Excerpts from Sean Dague\'s message of 2014-01-05 07:47:22 -0800:\n> While waiting some inordinate amount of time to compile lxml for a \n> tempest pep8 test, I started to wonder why is it that we are using -U on \n> all our pip install commands in tox (it\'s a pretty common pattern across \n> projects).\n> \n> It seems like requirements should be sufficient. Forcing -U to the \n> latest all the time seems like it would actually mask a ton of problems, \n> and makes sitepackages = True to be largely useless.\n> \n> I\'m sure it went in for a reason, so I\'d love to understand the reason, \n> to make sure that my instinct in disabling it in Tempest doesn\'t have a \n> ton of side effects.\n\nI tend to just use tox without -r, which means re-using the existing\nvirtualenv. It occasionally means a failed run because I\'ve missed a\nrequirements change, but that just means when I get a weird failure I\nrun with -r, which then builds me a new virtualenv.\n\nWould be cool if we could just have tox auto-detect when it even needs to\nrebuild the virtualenv, making this dance unnecessary, as I think that\nwould be preferable to what I suspect you\'re doing, which is running\nwith -r all the time?\n\n\n','<52C97E8A.9020003@dague.net>',NULL),('<1388938545-sup-8696@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 08:18:55',-28800,'2014-01-05 16:18:55',NULL,'[openstack-dev] [requirements] - taskflow preventing sqla 0.8\n	upgrade','I\'ve skimmed the rest of the thread and not seen something mentioned\nthat seems like it matters a lot. If I missed this suggestion buried\ndeep in the ensuing discussion, I apologize for that.\n\nSince TaskFlow wants to be generally consumable and not only driven as\nan OpenStack component, it should not be following global requirements.\nIt should actually expand its SQL Alchemy compatibility to all supported\nversions of SQLAlchemy. Ideally it would have a gate for each major\nversion of SQL Alchemy that upstream supports.\n\nOtherwise it will never even be able to work with any project that\ndoesn\'t share its SQL Alchemy version pin.\n\nExcerpts from Joshua Harlow\'s message of 2014-01-03 08:37:17 -0800:\n> So taskflow was tested with the version of sqlalchemy that was available and in the requirements at the time of its 0.1 release (taskflow syncs it\'s requirements from the same global requirements). From what I remember this is the same requirement that everyone else is bound to:\n> \n> SQLAlchemy>=0.7.8,<=0.7.99\n> \n> I can unpin it if this is desired (the openstack requirements repo has the same version restriction). What would be recommended here? As more code moves to pypi reusable libraries (oslo.db when it arrives comes to mind) I think this will be hit more often. Let\'s come up with a good strategy to follow.\n> \n> Thoughts??\n\n\n','<6CA42F6E-60B9-4AFF-99A8-F273B93F3C2A@yahoo-inc.com>',NULL),('<1388941213-sup-5353@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 09:03:21',-28800,'2014-01-05 17:03:21',NULL,'[openstack-dev] [Ceilometer] Vertica Storage Driver Testing','Excerpts from Herndon, John Luke\'s message of 2014-01-03 08:17:15 -0800:\n> \n> On 1/2/14, 7:06 PM, \"Sean Dague\" <sean at dague.net> wrote:\n> \n> >On 01/02/2014 08:36 PM, Robert Collins wrote:\n> >> On 3 January 2014 14:34, Robert Collins <robertc at robertcollins.net>\n> >>wrote:\n> >>> On 3 January 2014 12:40, Herndon, John Luke <john.herndon at hp.com>\n> >>>wrote:\n> >>>>\n> >>>>\n> >>>> On 1/2/14, 4:27 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> >>>>\n> >>>\n> >>>\n> >>>> I don?t think it would be that hard to get the review or gate jobs to\n> >>>>use\n> >>>> a real vertica instance, actually. Who do I talk to about that?\n> >>>\n> >>> http://ci.openstack.org/third_party.html\n> >>\n> >> Oh, if you meant setting up a gate variant to use vertica community\n> >> edition - I\'d run it past the ceilometer folk and then just submit\n> >> patches to devstack, devstack-gate and infra/config to do it.\n> >>\n> >> devstack - code for setting up a real vertica\n> >> devstack-gate - handles passing the right flags to devstack for the\n> >> configuration scenarios we test against\n> >> infra/config - has the jenkins job builder definitions to define the\n> >>jobs\n> >\n> >I think general policy (thus far) has been that we\'re not going to put\n> >non Open Source software into upstream gate jobs.\n> >\n> >So you really should approach this via 3rd party testing instead. The\n> >DB2 folks are approaching it that way, for that reason.\n> \n> Ok, that makes sense, but tbh, setting up 3rd party testing is going to be\n> as much or more work than writing the driver. Given schedule constraints,\n> it probably isn?t feasible right now. I think for starters, I will write\n> some unit tests that ensure that changes to the storage interface don?t\n> break the driver, and will work on a 3rd party testing strategy over time.\n> \n\n>From my perspective, I would -2 any change to projects I\'m a core on if\nthey just add a 3rd party driver without a commitment to testing. After\nseeing what Nova went through with this, it doesn\'t seem like a \"should\"\nbut a \"must\".\n\n\n','<CEEC2CDC.16403%john.herndon@hp.com>',NULL),('<1388948487-sup-639@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-05 11:04:21',-28800,'2014-01-05 19:04:21',NULL,'[Openstack] Deploying OpenStack on multiple nodes','Excerpts from Sayali Lunkad\'s message of 2013-12-24 04:23:53 -0800:\n> Hello,\n> \n> I need to deploy OpenStack on a distributed system mainly comprising of\n> Control, Compute and Network nodes (more if required). I need an\n> architecture that would help me to deploy it. I am not sure how things work\n> on a multi-node system, so any help would be highly appreciated.\n> I will be working on Ubuntu 12.04 OS.\n> \n\nNote that there is an OpenStack program to provide an automated deployment\nof OpenStack using OpenStack itself:\n\nHere is a succinct description:\n\nhttp://docs.openstack.org/developer/tripleo-incubator/deploying.html\n\nIf you follow this procedure you will get VMs on your machine that mimic\nthe way a full deployment will work:\n\nhttp://docs.openstack.org/developer/tripleo-incubator/devtest.html\n\nWe\'re not quite at a production level yet, but if you\'re interested in a\nfully automated deployment we could definitely use more user input! :)\n\n\n','<CAObJ2cG4vFeCvSJPsWeJmRVy6BB71toid_GohC8vS6-m06hodg@mail.gmail.com>',NULL),('<1388953296-sup-854@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-05 12:24:15',-28800,'2014-01-05 20:24:15',NULL,'[openstack-dev] [nova] - Revert change of default ephemeral fs\n	to ext4','As a follow-up, I\'ve filed this bug:\n\nhttps://bugs.launchpad.net/nova/+bug/1266262\n\nWe\'ll be working around this in TripleO by setting\ndefault_ephemeral_format for our baremetal clouds, but I feel we should\ndocument in Icehouse\'s release notes that the default will be changed\nto ext4 in Juno, so that deployers can set it to ext3 in their Icehouse\ndeployments.\n\nThe question I\'d have is should we print a warning if users leave it\nunset in their configs in Icehouse so they know what to expect in Juno,\nor is the documentation enough?\n\nExcerpts from Day, Phil\'s message of 2013-12-29 00:12:50 -0800:\n> Hi Folks,\n> \n> As highlighted in the thread \"minimal review period for functional changes\" I\'d like to propose that change is https://review.openstack.org/#/c/63209/ is reverted because:\n> \n> \n> -          It causes inconsistent behaviour in the system, as any existing \"default\" backing files will have ext3 in them, so a VM will now get either ext3 or 3ext4 depending on whether the host they get created on already has a backing file of the required size or not.   I don\'t think the existing design ever considered the default FS changing - maybe we shouldn\'t have files that include \"default\" as the file system type if it can change over time, and the name should always reflect the FS type.\n> \n> \n> \n> -          It introduces a new a new requirement for GuestOS\'s to have to support ext4 in order to work with the default configuration.   I think that\'s a significant enough change that it needs to be flagged, discussed, and planned.\n> \n> \n> \n> \n> \n> I\'m about to go off line for a few days and won\'t have anything other than patchy e-mail access, otherwise I\'d submit the change myself ;-)\n> \n> \n> Phil\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F589DB@G6W2490.americas.hpqcorp.net>',NULL),('<1389024746.1990.24.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 11:12:26',-18000,'2014-01-06 16:12:26',NULL,'[openstack-dev] [Ceilometer] time consuming of listing resource','On Mon, 2014-01-06 at 21:06 +0800, ?? wrote:\n> Hi jay,Thank you for the comments, I have simply tested the\n> performance of ceilometer with mysql driver.,while,the DB table may\n> become huge in few days.Unfortunately,the result is not satisfied .\n> As you said.both the schema level and the code level,the SQL driver in\n> Ceilometer should be optimized. thanks for your advicese.I will search\n> around about this.\n\nHi there :) Please do let me know what performance improvements you see\nby following the steps I listed below.\n\nAll the best,\n-jay\n\n> \n> ? 2013-12-29 00:16:47?\"Jay Pipes\" <jaypipes at gmail.com> ???\n> >On 12/28/2013 05:51 AM, ?? wrote:\n> >> Hi all?\n> >> I have reported a bug about time consuming of ?resource-list? in\n> >> ceilometer CLI?\n> >> https://bugs.launchpad.net/ceilometer/+bug/1264434\n> >>\n> >> In order to Identify the causes of this phenomenon, I have pdb the codes\n> >> in my invironment(configured  mysql as db driver):\n> >> the most import part of process of listing resource is implemented in\n> >> following codes:\n> >>\n> >> code of get_resources() in /ceilometer/storage/impl_sqlalchemy.py?\n> >> ????\n> >>   for meter, first_ts, last_ts in query.all():\n> >>              yield api_models.Resource(\n> >>                  resource_id=meter.resource_id,\n> >>                  project_id=meter.project_id,\n> >>                  first_sample_timestamp=first_ts,\n> >>                  last_sample_timestamp=last_ts,\n> >>                  source=meter.sources[0].id,\n> >>                  user_id=meter.user_id,\n> >>                  metadata=meter.resource_metadata,?\n> >>                  meter=[\n> >>                      api_models.ResourceMeter(\n> >>                          counter_name=m.counter_name,\n> >>                          counter_type=m.counter_type,\n> >>                          counter_unit=m.counter_unit,\n> >>                      )\n> >> for m in meter.resource.meters\n> >>                  ],\n> >>              )\n> >> The method  generate iterator of object of api_models.Resource for\n> >> ceilometer API to show.\n> >> 1.The operation ?query.all()? will query the DB table ?meter? with the\n> >> expression generated forward,in my invironment the DB table ?meter? have\n> >> more than 300000 items, so this operation may consume about 30 seconds;\n> >> 2.The operation\"for m in meter.resource.meters\" will circulate the\n> >> meters of this resource . a resource of server may have more than 100000\n> >> meter iterms in my invironment.  So the time of whole process is too\n> >> long. I think the meter of Resource object can be reduced and I have\n> >> tested this modification, it is OK for listing resource,and reduce the\n> >> most time consumption\n> >>\n> >> I have noticed that there are many methods of db operation may time\n> >> consumption.\n> >>\n> >> ps: I have configured the ceilometer pulling interval from 600s to 60s\n> >> in /etc/ceilometer/pipeline.yaml, but the invironment has just run 10 days!\n> >>\n> >> I\'m a beginner of ceilometer,and want to fix this bug,but I haven\'t\n> >> found a suitable way\n> >> may be someone can help me with this?\n> >\n> >Yep. The performance of the SQL driver in Ceilometer out-of-the-box with \n> >that particular line is unusable in our experience. We have our Chef \n> >cookbook literally patch Ceilometer\'s source code and comment out that \n> >particular line because it makes performance of Ceilometer unusable.\n> >\n> >I hate to say it, but the SQL driver in Ceilometer really needs an \n> >overhaul, both at the schema level and the code level:\n> >\n> >On the schema level:\n> >\n> >* The indexes, especially on sourceassoc, are wrong:\n> >  ** The order of the columns in the multi-column indexes like idx_sr, \n> >idx_sm, idx_su, idx_sp is incorrect. Columns used in predicates should \n> >*precede* columns (like source_id) that are used in joins. The way the \n> >indexes are structured now makes them unusable by the query optimizer \n> >for 99% of queries on the sourceassoc table, which means any queries on \n> >sourceassoc trigger a full table scan of the hundreds of millions of \n> >records in the table. Things are made worse by the fact that INSERT \n> >operations are slowed for each index on a table, and the fact that none \n> >of these indexes are used just means we\'re wasting cycles on each INSERT \n> >for no reason.\n> >  ** The indexes are across the entire VARCHAR(255) field width. This \n> >isn\'t necessary (and I would argue that the base field type should be \n> >smaller). Index width can be reduced (and performance increased) by \n> >limiting the indexable width to 32 (or smaller).\n> >\n> >The solution to the main indexing issues is to do the following:\n> >\n> >DROP INDEX idx_sr ON sourceassoc;\n> >CREATE INDEX idx_sr ON sourceassoc (resource_id(32), source_id(32));\n> >DROP INDEX idx_sp ON sourceassoc;\n> >CREATE INDEX idx_sp ON sourceassoc (project_id(32), source_id(32));\n> >DROP INDEX idx_su ON sourceassoc;\n> >CREATE INDEX idx_su ON sourceassoc (user_id(32), source_id(32));\n> >DROP INDEX idx_sm ON sourceassoc;\n> >CREATE INDEX idx_sm ON sourceassoc (meter_id, source_id(32));\n> >\n> >Keep in mind if you have (hundreds of) millions of records in the \n> >sourceassoc table, the above will take a long time to run. It will take \n> >hours, but you\'ll be happy you did it. You\'ll see the database \n> >performance increase dramatically.\n> >\n> >* The columns that refer to IDs of various kinds should not be UTF8. \n> >Changing these columns to a latin1 or even binary charset would cut the \n> >space requirements for the data and index storage by 65%. This means you \n> >can fit around 3x as many records in the same data and index pages. The \n> >more records you fit into an index page, the faster seeks and scans will be.\n> >\n> >* sourceassoc has no primary key.\n> >\n> >* The meter table has the following:\n> >\n> >   KEY ix_meter_id (id)\n> >\n> >   which is entirely redundant (id is the primary key) and does nothing \n> >but slow down insert operations for every record in the meter table.\n> >\n> >* The meter table mixes frequently searched and aggregated fields (like \n> >timestamp, counter_type, project_id) with infrequently accessed fields \n> >(like resource_metadata, which is a VARCHAR(5000)). This leads to poorer \n> >performance of aggregate queries on the meter table that use the \n> >clustered index (primary key) in aggregation (for an example, see the \n> >particular line of code that we comment out of Ceilometer above). A \n> >better performing schema would consolidate slim, frequently accessed \n> >fields into the main meter table and move infrequently accessed or \n> >searched fields into a meter_extra table. This would mean many more \n> >records of the main meter table can fit into a single InnoDB data page \n> >(the clustered index), which means faster seeks and scans for 99% of \n> >queries on that table.\n> >\n> >On the code level there are a variety of inefficient queries that are \n> >generated, and there are a number of places where using something like a \n> >memcache caching layer for common lookup queries could help reduce load \n> >on the DB server.\n> >\n> >I\'m hoping to push some patches in the early part of 2014 that address \n> >performance and scalability issues in the SQL driver for Ceilometer.\n> >\n> >Best,\n> >-jay\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<2f671a29.23174.14367a9d2ca.Coremail.liusheng1175@126.com>',NULL),('<1389025434.1990.28.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 11:23:54',-18000,'2014-01-06 16:23:54',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 19:40 +0900, Isaku Yamahata wrote:\n> On Fri, Dec 27, 2013 at 11:09:02AM +0100,\n> Salvatore Orlando <sorlando at nicira.com> wrote:\n> \n> > Hi,\n> > \n> > We now have several patches under review which improve a lot how neutron\n> > handles parallel testing.\n> > In a nutshell, these patches try to ensure the ovs agent processes new,\n> > removed, and updated interfaces as soon as possible,\n> > \n> > These patches are:\n> > https://review.openstack.org/#/c/61105/\n> > https://review.openstack.org/#/c/61964/\n> > https://review.openstack.org/#/c/63100/\n> > https://review.openstack.org/#/c/63558/\n> > \n> > There is still room for improvement. For instance the calls from the agent\n> > into the plugins might be consistently reduced.\n> > However, even if the above patches shrink a lot the time required for\n> > processing a device, we are still hitting a hard limit with the execution\n> > ovs commands for setting local vlan tags and clearing flows (or adding the\n> > flow rule for dropping all the traffic).\n> > In some instances this commands slow down a lot, requiring almost 10\n> > seconds to complete. This adds a delay in interface processing which in\n> > some cases leads to the hideous SSH timeout error (the same we see with bug\n> > 1253896 in normal testing).\n> > It is also worth noting that when this happens sysstat reveal CPU usage is\n> > very close to 100%\n> > \n> > From the neutron side there is little we can do. Introducing parallel\n> > processing for interface, as we do for the l3 agent, is not actually a\n> > solution, since ovs-vswitchd v1.4.x, the one executed on gate tests, is not\n> > multithreaded. If you think the situation might be improved by changing the\n> > logic for handling local vlan tags and putting ports on the dead vlan, I\n> > would be happy to talk about that.\n> \n> How about batching those ovsdb operations?\n> Instead of issueing many ovs-vsctl command,\n> ovs-vsctl -- command0 [args] -- command1 [args] -- ...\n> \n> Then, the number of ovs-vsctl will be reduced and ovs-vsctl issues\n> only single ovsdb transaction.\n\nhttps://bugs.launchpad.net/neutron/+bug/1264608\n\n:)\n\n-jay\n\n\n\n\n','<20140106104011.GA16731@private.email.ne.jp>',NULL),('<1389025789.1990.30.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 11:29:49',-18000,'2014-01-06 16:29:49',NULL,'[openstack-dev] Keystone Hashing MD5 to SHA256','On Mon, 2014-01-06 at 17:00 +0100, Tristan Cacqueray wrote:\n> On 01/06/2014 04:19 PM, Adam Young wrote:\n> > Dirk,\n> > \n> > If it were as  easy as just replaceing hteh hash algorithm, we would\n> > have done it a year + ago.  I\'m guessing you figured that by now.\n> > \n> > Here is the deal:  We need to be able to make things work side by side. \n> > Not sure how to do that, but I think the right solution is to make\n> > keystone configurable first, so that you can set the hashing algorithm\n> > in the config file, and that python-keystoneclient should be able to\n> > handle both.  Since the PKC  doesn\'t tend to talk to multiple Keystones,\n> > that should probably be sufficient.\n> > \n> > In the future, Keystones  need to be advertise, somehow, what Hashing\n> > algorithm it uses.  It probably can/should stick that data in the token.\n> > \n> > Thoughts?\n> > \n> \n> Hello list!\n> \n> How about we prefix the hash with the chosen algorithm, like the glibc\n> crypt method (ie: $id$hash) ? No prefix would mean the former md5.\n> \n> This would allow a smooth migration as multiple hash algorithm could be\n> used simultaneously and keystone wouldn\'t have to announce what\n> algorithm it uses...\n\n+1. Simple and effective.\n\n-jay\n\n\n\n','<52CAD321.7080604@enovance.com>',NULL),('<1389025933.1990.31.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-06 11:32:13',-18000,'2014-01-06 16:32:13',NULL,'[Openstack] [keystone] memcache token backend performance','On Mon, 2014-01-06 at 10:10 -0500, Adam Young wrote:\n> \n> On 01/03/2014 11:38 PM, Xu (Simon) Chen wrote:\n> \n> > Hi folks, \n> > \n> > \n> > I am having trouble with using memcache as the keystone token\n> > backend. I have three keystone nodes running active/active. Each is\n> > running keystone on apache (for kerberos auth). I recently switched\n> > from using sql backend to memcache, while have memcached running on\n> > all three of the keystone nodes. \n> > \n> \n> This triggers a memory of htere being something wonky with\n> Greenthreads,  the threading override in Eventlet, and Memcached.  But\n> you said Apache, so I think that you are not running with\n> greenthreads?\n> \n> There are numerous things out there about apache and memcached\n> performance.  For example, one article talks about filling up\n> partitions, etc.\n> \n> \n> > \n> > \n> > This setup would run well for a while, but then apache would start\n> > to hog CPUs, and memcached would increase to 30% or so. I tried to\n> > increase memcached cluster from 3 to 6 nodes, but in general the\n> > performance is much worse compared to sql backend.\n> Probably due to the need for replication.  In order to keep it\n> anywhere close to in sync,  it is going to require some non-trivial\n> subset of fully connectedness.\n\nInstead of doing replication of memcache, instead just tell your\nloadbalancer to have sticky sessions, and have each keystone server have\nits own dedicated memcache instance.\n\n-jay\n\n\n\n','<52CAC748.7000904@redhat.com>',NULL),('<1389026291.1990.34.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 11:38:11',-18000,'2014-01-06 16:38:11',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 17:04 +0100, Salvatore Orlando wrote:\n> I have already discussed the matter with Jay on IRC, even if for a\n> different issue.\n> In this specific case \'batching\' will have the benefit of reducing the\n> rootwrap overhead.\n\nRight.\n\n> However, it seems the benefit from batching is not resolutive. I admit\n> I have not run tests in the gate with batching; I\'ve just tested in an\n> environment without significant load, obtaining a performance increase\n> of less than 10%.\n\nWell, 10% is 10% better than nothing ;) And add in the (significant)\nrootwrap costs, and I think it\'s certainly worth looking into.\n\n> From what I gathered even if commands are \'batched\' to ovs-vsctl,\n> operations are still individually performed on the kernel module. I\n> did not investigate whether the cli commands sends a single or\n> multiple commands on the ovsdb interface.\n> Nevertheless, another thing to note is that it\'s not just ovs-vsctl\n> that becomes very slow, but also, and more often than that, ovs-ofctl,\n> for which there is no batching.\n\nAh, I did not realize ovs-ofctl had no batch mode. That\'s a shame...\n\n> Summarising, I\'m not opposed to batching for ovs-vsctl, and I would\n> definitely welcome it; I just don\'t think it will be the ultimate\n> solution.\n\nYep, understood.\n\nThanks!\n-jay\n\n\n\n\n','<CAGR=i3jfNKfuT=EqafBmOAbbWFY7bJwFsOeZZNHwVTiUqMqgXw@mail.gmail.com>',NULL),('<1389029843.1990.47.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 12:37:23',-18000,'2014-01-06 17:37:23',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 08:58 -0800, Joe Gordon wrote:\n\n> On Mon, Jan 6, 2014 at 8:38 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Mon, 2014-01-06 at 17:04 +0100, Salvatore Orlando wrote:\n>         > I have already discussed the matter with Jay on IRC, even if\n>         for a\n>         > different issue.\n>         > In this specific case \'batching\' will have the benefit of\n>         reducing the\n>         > rootwrap overhead.\n>         \n>         \n>         Right.\n>         \n>         > However, it seems the benefit from batching is not\n>         resolutive. I admit\n>         > I have not run tests in the gate with batching; I\'ve just\n>         tested in an\n>         > environment without significant load, obtaining a\n>         performance increase\n>         > of less than 10%.\n>         \n>         \n>         Well, 10% is 10% better than nothing ;) And add in the\n>         (significant)\n>         rootwrap costs, and I think it\'s certainly worth looking into.\n> \n> Have you tried running neutron without rootwrap, to get a baseline?\n\nSee:\nhttp://blog.gridcentric.com/bid/318277/Boosting-OpenStack-s-Parallel-Performance\n\nSpecifically the section titled \"Disable rootwrap scripts\",\n\nBest,\n-jay\n\n\n\n\n','<CAHXdxOezYj3RYgWS75sgTZ9R1f9T4yCTP7VerOy4O_x6yNi1Bg@mail.gmail.com>',NULL),('<1389031062-sup-4045@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 09:59:37',-28800,'2014-01-06 17:59:37',NULL,'[openstack-dev] [heat] Sofware Config progress','Excerpts from Susaant Kondapaneni\'s message of 2014-01-06 09:25:08 -0800:\n> Hi Steve,\n> \n> I am trying to understand the software config implementation. Can you\n> clarify the following:\n> \n> i. To use Software config and deploy in a template, instance resource MUST\n> always be accompanied by user_data. User_data should specify how to\n> bootstrap CM tool and signal it. Is that correct?\n> \n> ii. Supposing we were to use images which do not have cloud-init packaged\n> in them, (and a custom CM tool that won\'t require bootstrapping on the\n> instance itself), can we still use software config and deploy resources to\n> deploy software on such instances?\n\nIf you don\'t have cloud-init, you are entirely on your own. Heat\nrequires cloud-init to be able to do anything beyond boot an instance\nwith your specified parameters.\n\n> \n> iii. If ii. were possible who would signal the deployment resource to\n> indicate that the instance is ready for the deployment?\n> \n\nSo what you\'d end up with is userdata (in the nova/ec2/config-drive\nsense) in multi-part mime format that cloud-init expects. You can\nabsolutely write your own tools to interpret that (please don\'t,\ncloud-init is lovely) and then submit results back using the API as\ndefined. But... why?\n\n\n','<CALR54ZMV_z6OoqVDUbcVigON8+3mnD1Vns+AcNWbC4Go3bREAw@mail.gmail.com>',NULL),('<1389033341.1990.49.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 13:35:41',-18000,'2014-01-06 18:35:41',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote:\n\n> What about it? Also those numbers are pretty old at this point. I was\n> thinking disable rootwrap and run full parallel tempest against it.\n\nI think that is a little overkill for what we\'re trying to do here. We\nare specifically talking about combining many utils.execute() calls into\na single one. I think it\'s pretty obvious that the latter will be better\nperforming than the first, unless you think that rootwrap has no\nperformance overhead at all?\n\n-jay\n\n\n\n\n','<CAHXdxOfsCqsWMeAObywbxh_c3gs5H0LeKEiZw_ubaC8TNat5SQ@mail.gmail.com>',NULL),('<1389034122-sup-6759@clint-HP>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-06 10:49:47',-28800,'2014-01-06 18:49:47',NULL,'[Openstack] [keystone] memcache token backend performance','Excerpts from Jay Pipes\'s message of 2014-01-06 08:32:13 -0800:\n> On Mon, 2014-01-06 at 10:10 -0500, Adam Young wrote:\n> > \n> > On 01/03/2014 11:38 PM, Xu (Simon) Chen wrote:\n> > \n> > > Hi folks, \n> > > \n> > > \n> > > I am having trouble with using memcache as the keystone token\n> > > backend. I have three keystone nodes running active/active. Each is\n> > > running keystone on apache (for kerberos auth). I recently switched\n> > > from using sql backend to memcache, while have memcached running on\n> > > all three of the keystone nodes. \n> > > \n> > \n> > This triggers a memory of htere being something wonky with\n> > Greenthreads,  the threading override in Eventlet, and Memcached.  But\n> > you said Apache, so I think that you are not running with\n> > greenthreads?\n> > \n> > There are numerous things out there about apache and memcached\n> > performance.  For example, one article talks about filling up\n> > partitions, etc.\n> > \n> > \n> > > \n> > > \n> > > This setup would run well for a while, but then apache would start\n> > > to hog CPUs, and memcached would increase to 30% or so. I tried to\n> > > increase memcached cluster from 3 to 6 nodes, but in general the\n> > > performance is much worse compared to sql backend.\n> > Probably due to the need for replication.  In order to keep it\n> > anywhere close to in sync,  it is going to require some non-trivial\n> > subset of fully connectedness.\n> \n> Instead of doing replication of memcache, instead just tell your\n> loadbalancer to have sticky sessions, and have each keystone server have\n> its own dedicated memcache instance.\n\nWhats wrong with the usual memcached hyper-scale-out method of a list\nof servers and hashing the key to choose one?\n\n\n','<1389025933.1990.31.camel@cranky>',NULL),('<1389034925.1990.70.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 14:02:05',-18000,'2014-01-06 19:02:05',NULL,'[openstack-dev] [Gantt] Looking for some answers...','Hello Stackers,\n\nI was hoping to get some answers on a few questions I had regarding the\nGantt project [1]. Specifically, here are my queries:\n\n1) Why was Nova forked to the http://github.com/openstack/gantt\nrepository? Forking Nova just to then remove a bunch of code that\ndoesn\'t relate to the scheduler code means that we bring 10K+ commits\nand a git history along with the new project... this seems to be the\nwrong origin for a project the aims to be a separate service. There\'s a\nreason that Cinder and Neutron didn\'t start out as a fork of Nova, after\nall...\n\n2) Why is Gantt in the /openstack GitHub organization? Wouldn\'t\nthe /stackforge organization be more appropriate for a project that\nisn\'t integrated? If I understand some of the backstory behind Gantt,\nthe idea was to create a scheduler service from the existing Nova\nscheduler code in order to \"complete the work sometime in our lifetime\".\nWhile I understand the drive to start with something that already exists\nand iterate over it, I don\'t understand why the project went right into\nthe /openstack organization instead of following the /stackforge\nprocesses for housing code that bakes and gets iterated on before\nproposing for incubation. Some explanation would be great here.\n\n3) Where is feature planning happening for Gantt? The Launchpad site for\nGantt [2] is empty. Furthermore, there are a number of blueprints for\nimproving the Nova scheduler, notably the no-db-scheduler blueprint [3],\nwhich even has code submitted for it and is targeted to Icehouse-2. How\nare improvements like this planned to be ported (if at all) to Gantt?\n\n4) Is the aim of Gantt to provide a RESTful HTTP API in addition to the\nRPC-based API that the existing Nova scheduler exposes?\n\nThanks much in advance for answers, and apologies if these have been\nanswered before and I missed the ML threads or design summit\ndiscussions.\n\nBest,\n-jay\n\n[1] https://github.com/openstack/gantt/\n[2] http://blueprints.launchpad.net/gantt\n[3] https://blueprints.launchpad.net/nova/+spec/no-db-scheduler\n\n\n\n',NULL,NULL),('<1389035662.1990.72.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-06 14:14:22',-18000,'2014-01-06 19:14:22',NULL,'[Openstack] [keystone] memcache token backend performance','On Mon, 2014-01-06 at 10:49 -0800, Clint Byrum wrote:\n> Excerpts from Jay Pipes\'s message of 2014-01-06 08:32:13 -0800:\n> > On Mon, 2014-01-06 at 10:10 -0500, Adam Young wrote:\n> > > \n> > > On 01/03/2014 11:38 PM, Xu (Simon) Chen wrote:\n> > > \n> > > > Hi folks, \n> > > > \n> > > > \n> > > > I am having trouble with using memcache as the keystone token\n> > > > backend. I have three keystone nodes running active/active. Each is\n> > > > running keystone on apache (for kerberos auth). I recently switched\n> > > > from using sql backend to memcache, while have memcached running on\n> > > > all three of the keystone nodes. \n> > > > \n> > > \n> > > This triggers a memory of htere being something wonky with\n> > > Greenthreads,  the threading override in Eventlet, and Memcached.  But\n> > > you said Apache, so I think that you are not running with\n> > > greenthreads?\n> > > \n> > > There are numerous things out there about apache and memcached\n> > > performance.  For example, one article talks about filling up\n> > > partitions, etc.\n> > > \n> > > \n> > > > \n> > > > \n> > > > This setup would run well for a while, but then apache would start\n> > > > to hog CPUs, and memcached would increase to 30% or so. I tried to\n> > > > increase memcached cluster from 3 to 6 nodes, but in general the\n> > > > performance is much worse compared to sql backend.\n> > > Probably due to the need for replication.  In order to keep it\n> > > anywhere close to in sync,  it is going to require some non-trivial\n> > > subset of fully connectedness.\n> > \n> > Instead of doing replication of memcache, instead just tell your\n> > loadbalancer to have sticky sessions, and have each keystone server have\n> > its own dedicated memcache instance.\n> \n> Whats wrong with the usual memcached hyper-scale-out method of a list\n> of servers and hashing the key to choose one?\n\nNothing at all :)\n\n-jay\n\n\n\n','<1389034122-sup-6759@clint-HP>',NULL),('<1389036685.1990.78.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 14:31:25',-18000,'2014-01-06 19:31:25',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote:\n> \n> \n> \n> On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote:\n>         \n>         > What about it? Also those numbers are pretty old at this\n>         point. I was\n>         > thinking disable rootwrap and run full parallel tempest\n>         against it.\n>         \n>         \n>         I think that is a little overkill for what we\'re trying to do\n>         here. We\n>         are specifically talking about combining many utils.execute()\n>         calls into\n>         a single one. I think it\'s pretty obvious that the latter will\n>         be better\n>         performing than the first, unless you think that rootwrap has\n>         no\n>         performance overhead at all?\n> \n> \n> mocking out rootwrap with straight sudo, is a very quick way to\n> approximate the performance benefit of combining many utlils.execute()\n> calls together (at least rootwrap wise).  Also  it would tell us how\n> much of the problem is rootwrap induced and how much is other.\n\nYes, I understand that, which is what the article I linked earlier\nshowed?\n\n% time sudo ip link >/dev/null\nsudo ip link > /dev/null  0.00s user 0.00s system 43% cpu 0.009 total\n% sudo time quantum-rootwrap /etc/quantum/rootwrap.conf ip link\n> /dev/null\nquantum-rootwrap /etc/quantum/rootwrap.conf ip link  > /dev/null  0.04s\nuser 0.02s system 87% cpu 0.059 total\n\nA very tiny, non-scientific simple indication that rootwrap is around 6\ntimes slower than a simple sudo call.\n\nBest,\n-jay\n\n\n\n','<CAHXdxOc7_vANKXUfzOFUZKi-h0s3E5PySacVmNb+_kfhqn4TQg@mail.gmail.com>',NULL),('<1389038292.1990.83.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 14:58:12',-18000,'2014-01-06 19:58:12',NULL,'[openstack-dev] [Neutron] Multiple config files for neutron\n server','On Mon, 2014-01-06 at 23:45 +0400, Eugene Nikanorov wrote:\n> Hi folks,\n> \n> \n> Recently we had a discussion with Sean Dague on the matter.\n> Currently Neutron server has a number of configuration files used for\n> different purposes:\n>  - neutron.conf - main configuration parameters, plugins, db and mq\n> connections\n>  - plugin.ini - plugin-specific networking settings\n>  - conf files for ml2 mechanisms drivers (AFAIK to be able to use\n> several mechanism drivers we need to pass all of these conf files to\n> neutron server)\n>  - services.conf - recently introduced conf-file to gather\n> vendor-specific parameters for advanced services drivers.\n> Particularly, services.conf was introduced to avoid polluting\n> \'generic\' neutron.conf with vendor parameters and sections.\n> \n> \n> The discussion with Sean was about whether to add services.conf to\n> neutron-server launching command in devstack\n> (https://review.openstack.org/#/c/64377/ ). services.conf would be 3rd\n> config file that is passed to neutron-server along with neutron.conf\n> and plugin.ini.\n> \n> \n> Sean has an argument that providing many conf files in a command line\n> is not a good practice, suggesting setting up configuration directory\n> instead. There is no such capability in neutron right now so I\'d like\n> to hear opinions on this before putting more efforts in resolving this\n> in with other approach than used in the patch on review.\n\nI\'d say just put the additional conf file on the command line for now.\nAdding in support to oslo.cfg for a config directory can come later.\n\nJust my 2 cents,\n-jay\n\n\n\n\n','<CAJfiwOTJ_9CJsr2V1yQkRTSfehpbAmeV8LfswtNr2bfG8x7+vw@mail.gmail.com>',NULL),('<1389041454.1990.90.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 15:50:54',-18000,'2014-01-06 20:50:54',NULL,'[openstack-dev] [Neutron][qa] Parallel testing update','On Mon, 2014-01-06 at 21:24 +0100, Salvatore Orlando wrote:\n> This thread is starting to get a bit confusing, at least for people\n> with a single-pipeline brain like me!\n\nHeh, point taken.\n\n> <snip>\n\n> On the other hand, I would invite community members picking up some of\n> the bugs we\'ve registered for \'less frequent\' failures observed during\n> parallel testing; especially if you\'re coming to Montreal next week.\n\nMind tagging the bugs with \'less-frequent\' or even \'montreal\', so we can\nquickly search launchpad for them?\n\nThanks!\n-jay\n\n\n\n\n','<CAGR=i3i0+Czfs+S+5wuSRuY9DymaujyKseCnJ326WJxwzS60gg@mail.gmail.com>',NULL),('<1389045729.1990.95.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-06 17:02:09',-18000,'2014-01-06 22:02:09',NULL,'[openstack-dev] [Gantt] Looking for some answers...','Thanks to Vish, Don, and Russell for the answers. Much appreciated!\n\nBest,\n-jay\n\nOn Mon, 2014-01-06 at 11:30 -0800, Vishvananda Ishaya wrote:\n> On Jan 6, 2014, at 11:02 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > Hello Stackers,\n> > \n> > I was hoping to get some answers on a few questions I had regarding the\n> > Gantt project [1]. Specifically, here are my queries:\n> > \n> > 1) Why was Nova forked to the http://github.com/openstack/gantt\n> > repository? Forking Nova just to then remove a bunch of code that\n> > doesn\'t relate to the scheduler code means that we bring 10K+ commits\n> > and a git history along with the new project... this seems to be the\n> > wrong origin for a project the aims to be a separate service. There\'s a\n> > reason that Cinder and Neutron didn\'t start out as a fork of Nova, after\n> > all?\n> \n> Authorship history is nice, but this does seem a bit excessive. The cinder\n> strategy of a single squashed fork would have been/still be fine I?m sure.\n> > \n> > 2) Why is Gantt in the /openstack GitHub organization? Wouldn\'t\n> > the /stackforge organization be more appropriate for a project that\n> > isn\'t integrated? If I understand some of the backstory behind Gantt,\n> > the idea was to create a scheduler service from the existing Nova\n> > scheduler code in order to \"complete the work sometime in our lifetime\".\n> > While I understand the drive to start with something that already exists\n> > and iterate over it, I don\'t understand why the project went right into\n> > the /openstack organization instead of following the /stackforge\n> > processes for housing code that bakes and gets iterated on before\n> > proposing for incubation. Some explanation would be great here.\n> \n> This is split-out of existing code so it is following the same path as\n> cinder. The goal is to deprecate the existing nova scheduler in I. It currently\n> a new project under the nova program I believe.\n> \n> > \n> > 3) Where is feature planning happening for Gantt? The Launchpad site for\n> > Gantt [2] is empty. Furthermore, there are a number of blueprints for\n> > improving the Nova scheduler, notably the no-db-scheduler blueprint [3],\n> > which even has code submitted for it and is targeted to Icehouse-2. How\n> > are improvements like this planned to be ported (if at all) to Gantt?\n> \n> Not sure about the launchpad site. There is a regular scheduler group meeting\n> and as I understand it the hope will be to do the no-db-scheduler blueprint.\n> There was quite a bit of debate on whether to do the no-db-scheduler stuff\n> before or after the forklift and I think the consensus was to do the forklift\n> first.\n> \n> > \n> > 4) Is the aim of Gantt to provide a RESTful HTTP API in addition to the\n> > RPC-based API that the existing Nova scheduler exposes?\n> \n> In the short term the plan is to just replicate the rpc api, but I think\n> a REST api will be considered long term.\n> \n> Vish\n> \n> > \n> > Thanks much in advance for answers, and apologies if these have been\n> > answered before and I missed the ML threads or design summit\n> > discussions.\n> > \n> > Best,\n> > -jay\n> > \n> > [1] https://github.com/openstack/gantt/\n> > [2] http://blueprints.launchpad.net/gantt\n> > [3] https://blueprints.launchpad.net/nova/+spec/no-db-scheduler\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<BACF57EB-9DC0-4967-8E7E-9F24994058ED@gmail.com>',NULL),('<1389113558.1990.115.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 11:52:38',-18000,'2014-01-07 16:52:38',NULL,'[openstack-dev] [nova] minimum review period for functional\n changes that break backwards compatibility','On Tue, 2014-01-07 at 11:04 +0100, Thierry Carrez wrote:\n> Matt Riedemann wrote:\n> > There is discussion in this thread about \"wouldn\'t it be nice to have a\n> > tag on commits for changes that impact upgrades?\".  There is.\n> > \n> > http://lists.openstack.org/pipermail/openstack-dev/2013-October/016619.html\n> > \n> > https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references\n> > \n> > Here is an example of a patch going through the gate now with\n> > UpgradeImpact:\n> > \n> > https://review.openstack.org/#/c/62815/\n> \n> The good thing about \"UpgradeImpact\" is that it\'s less subjective than\n> \"OpsImpact\", and I think it catches what matters: backward-incompatible\n> changes, upgrades needing manual intervention (or smart workarounds in\n> packaging), etc.\n> \n> Additional benefit is that it\'s relevant for more than just the \"ops\"\n> population: packagers and the release notes writers also need to track\n> those.\n\n+1 for UpgradeImpact\n\n-jay\n\n\n\n','<52CBD121.50904@openstack.org>',NULL),('<1389123306.26071.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-07 14:35:06',-18000,'2014-01-07 19:35:06',NULL,'[Openstack] How to achieve HA and Scalability for Neutron','On Fri, 2014-01-03 at 18:33 +0800, Li Ma wrote:\n> > Right, the Neutron L3 agent is the only OpenStack service that is\n> > not stateless, and therefore you cannot use traditional\n> > load-balancing across a set of identical nodes.\n> \n> Hi jay, how about dhcp-agent? I\'ve went through the bps of neutron\n> for icehouse release. There\'s no related topics on dhcp-agent.\n> \n> I wonder how to implement the same functionality of dhcp-agent.\n\nHi Li, sorry for the delayed response!\n\nTechnically, the DHCP agent itself does not maintain any state. Rather,\nthe DHCP agent ensures that a DHCP server (dnsmasq) is running in the\nLinux network namespace and providing IP addresses in the tenant\'s\nsubnet to the VM\'s vNIC MAC addresses. The dnsmasq process, running in\nthe network namespace, *does* save state, though. Unless something has\nchanged recently, I believe the default behavior of Neutron is to start\na dnsmasq process within the tenant\'s network namespace on only *one*\nDHCP agent.\n\nHowever, it is definitely possible to instruct Neutron to place a\ndnsmasq process on multiple nodes with a DHCP agent servicing the node.\nIn fact, in the Chef OpenStack Network cookbook [1] there is a tool\nwritten by Alan Meadows called neutron-ha-tool.py [2] that contains code\n[3] that queries Neutron for a list of DHCP agents, and then ensures\nthat all DHCP agents provide a dnsmasq process for all networks. Check\nout the script and you\'ll see what I mean. We run it in a cron job and\nit ensures that if a node running a DHCP agent goes down, that there are\nother nodes providing the tenant subnet with DHCP servicing.\n\nAll the best,\n-jay\n\n[1] https://github.com/stackforge/cookbook-openstack-network\n[2]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/files/default/neutron-ha-tool.py\n[3]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/files/default/neutron-ha-tool.py#L254\n\n\n\n\n','<CALFEDVe=-K3xYpvRXmQNmPj5Qe9gaN7p=gVqn=chBOeAGy_fEw@mail.gmail.com>',NULL),('<1389123586-sup-318@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 11:40:50',-28800,'2014-01-07 19:40:50',NULL,'[openstack-dev] [heat] Sofware Config progress','I\'d say it isn\'t so much cloud-init that you need, but \"some kind\nof bootstrapper\". The point of hot-software-config is to help with\nin-instance orchestration. That\'s not going to happen without some way\nto push the desired configuration into the instance.\n\nExcerpts from Susaant Kondapaneni\'s message of 2014-01-07 11:16:16 -0800:\n> We work with images provided by vendors over which we do not always have\n> control. So we are considering the cases where vendor image does not come\n> installed with cloud-init. Is there a way to support heat software config\n> in such scenarios?\n> \n> Thanks\n> Susaant\n> \n> On Mon, Jan 6, 2014 at 4:47 PM, Steve Baker <sbaker at redhat.com> wrote:\n> \n> >  On 07/01/14 06:25, Susaant Kondapaneni wrote:\n> >\n> >  Hi Steve,\n> >\n> >  I am trying to understand the software config implementation. Can you\n> > clarify the following:\n> >\n> >  i. To use Software config and deploy in a template, instance resource\n> > MUST always be accompanied by user_data. User_data should specify how to\n> > bootstrap CM tool and signal it. Is that correct?\n> >\n> >   Yes, currently the user_data contains cfn-init formatted metadata which\n> > tells os-collect-config how to poll for config changes. What happens when\n> > new config is fetched depends on the os-apply-config templates and\n> > os-refresh-config scripts which are already on that image (or set up with\n> > cloud-init).\n> >\n> >  ii. Supposing we were to use images which do not have cloud-init\n> > packaged in them, (and a custom CM tool that won\'t require bootstrapping on\n> > the instance itself), can we still use software config and deploy resources\n> > to deploy software on such instances?\n> >\n> >   Currently os-collect-config is more of a requirement than cloud-init,\n> > but as Clint said cloud-init does a good job of boot config so you\'ll need\n> > to elaborate on why you don\'t want to use it.\n> >\n> >  iii. If ii. were possible who would signal the deployment resource to\n> > indicate that the instance is ready for the deployment?\n> >\n> > os-collect-config polls for the deployment data, and triggers the\n> > resulting deployment/config changes. One day this may be performed by a\n> > different agent like the unified agent that has been discussed. Currently\n> > os-collect-collect polls via a heat-api-cfn metadata call. This too may be\n> > done in any number of ways in the future such as messaging or long-polling.\n> >\n> > So you *could* consume the supplied user_data to know what to poll for\n> > subsequent config changes without cloud-init or os-collect-config, but you\n> > would have to describe what you\'re doing in detail for us to know if that\n> > sounds like a good idea.\n> >\n> >\n> >\n> >  Thanks\n> > Susaant\n> >\n> >\n> > On Fri, Dec 13, 2013 at 3:46 PM, Steve Baker <sbaker at redhat.com> wrote:\n> >\n> >>  I\'ve been working on a POC in heat for resources which perform software\n> >> configuration, with the aim of implementing this spec\n> >> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec\n> >>\n> >> The code to date is here:\n> >> https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z\n> >>\n> >> What would be helpful now is reviews which give the architectural\n> >> approach enough of a blessing to justify fleshing this POC out into a ready\n> >> to merge changeset.\n> >>\n> >> Currently it is possible to:\n> >> - create templates containing OS::Heat::SoftwareConfig and\n> >> OS::Heat::SoftwareDeployment resources\n> >> - deploy configs to OS::Nova::Server, where the deployment resource\n> >> remains in an IN_PROGRESS state until it is signalled with the output values\n> >> - write configs which execute shell scripts and report back with output\n> >> values that other resources can have access to.\n> >>\n> >> What follows is an overview of the architecture and implementation to\n> >> help with your reviews.\n> >>\n> >> REST API\n> >> ========\n> >> Like many heat resources, OS::Heat::SoftwareConfig and\n> >> OS::Heat::SoftwareDeployment are backed by \"real\" resources that are\n> >> invoked via a REST API. However in this case, the API that is called is\n> >> heat itself.\n> >>\n> >> The REST API for these resources really just act as structured storage\n> >> for config and deployments, and the entities are managed via the REST paths\n> >> /{tenant_id}/software_configs and /{tenant_id}/software_deployments:\n> >>\n> >> <https://review.openstack.org/#/c/58878/7/heat/api/openstack/v1/__init__.py>\n> >> https://review.openstack.org/#/c/58878/\n> >> RPC layer of REST API:\n> >> https://review.openstack.org/#/c/58877/\n> >> DB layer of REST API:\n> >> https://review.openstack.org/#/c/58876\n> >> heatclient lib access to REST API:\n> >> https://review.openstack.org/#/c/58885\n> >>\n> >> This data could be stored in a less structured datastore like swift, but\n> >> this API has a couple of important implementation details which I think\n> >> justify it existing:\n> >> - SoftwareConfig resources are immutable once created. There is no update\n> >> API to modify an existing config. This gives confidence that a config can\n> >> have a long lifecycle without changing, and a certainty of what exactly is\n> >> deployed on a server with a given config.\n> >> - Fetching all the deployments and configs for a given server is an\n> >> operation done repeatedly throughout the lifecycle of the stack, so is\n> >> optimized to be able to do in a single operation. This is called by using\n> >> the deployments index API call,\n> >> /{tenant_id}/software_deployments?server_id=<server_id>. The resulting list\n> >> of deployments include the their associated config data[1].\n> >>\n> >> OS::Heat::SoftwareConfig resource\n> >> =================================\n> >> OS::Heat::SoftwareConfig can be used directly in a template, but it may\n> >> end be more frequently used in a resource provider template which provides\n> >> a resource aimed at a particular configuration management tool.\n> >>\n> >> http://docs-draft.openstack.org/79/58879/7/check/gate-heat-docs/911a250/doc/build/html/template_guide/openstack.html#OS::Heat::SoftwareConfig\n> >> The contents of the config property will depend on the CM tool being\n> >> used, but at least one value in the config map will be the actual script\n> >> that the CM tool invokes.  An inputs and outputs schema is also defined\n> >> here. The group property is used when the deployments data is actually\n> >> delivered to the server (more on that later).\n> >>\n> >> Since a config is immutable, any changes to a OS::Heat::SoftwareConfig on\n> >> stack update result in replacement.\n> >>\n> >> OS::Heat::SoftwareDeployment resource\n> >> =====================================\n> >> OS::Heat::SoftwareDeployment joins a OS::Heat::SoftwareConfig resource\n> >> with a OS::Nova::Server resource. It allows server-specific input values to\n> >> be specified that map to the OS::Heat::SoftwareConfig inputs schema. Output\n> >> values that are signaled to the deployment resource are exposed as resource\n> >> attributes, using the names specified in the outputs schema. The\n> >> OS::Heat::SoftwareDeployment resource remains in an IN_PROGRESS state until\n> >> it receives a signal (containing any outputs) from the server.\n> >>\n> >> http://docs-draft.openstack.org/79/58879/7/check/gate-heat-docs/911a250/doc/build/html/template_guide/openstack.html#OS::Heat::SoftwareDeployment\n> >>\n> >> A deployment has its own actions and statuses that are specific to what a\n> >> deployment does, and OS::Heat::SoftwareDeployment maps this to heat\n> >> resource statuses and actions:\n> >> actions:\n> >> DEPLOY -> CREATE\n> >> REDEPLOY -> UPDATE\n> >> UNDEPLOY -> DELETE\n> >>\n> >> status (these could use some bikeshedding):\n> >> WAITING -> IN_PROGRESS\n> >> RECEIVED -> COMPLETE\n> >> FAILED -> FAILED\n> >>\n> >> In the config outputs schema there is a special flag for error_output. If\n> >> the signal response contains any value for any of these error_output\n> >> outputs then the deployment resource is put into the FAILED state.\n> >>\n> >> The SoftwareDeployment class subclasses SignalResponder which means that\n> >> a SoftwareDeployment creates an associated user and ec2 keypair. Since the\n> >> SoftwareDeployment needs to use the resource_id for the deployment resource\n> >> uuid, the user_id needs to be stored in resource-date instead. This non-wip\n> >> change enables that:\n> >> https://review.openstack.org/#/c/61902/\n> >>\n> >> During create, the deployment REST API is polled until status goes from\n> >> WAITING to RECEIVED. When handle_signal is called, the deployment is\n> >> updated via the REST API to set the status to RECEIVED (or FAILED), along\n> >> with any output values that were received.\n> >>\n> >> One alarming consequence of having a deployments API is that any tenant\n> >> user can create a deployment for any heat-created nova server and that\n> >> software will be deployed to that server, which is, um, powerful.\n> >>\n> >> There will need to be a deployment policy (probably an OS::Nova::Server\n> >> property) which limits to scope of what deployments are allowed on that\n> >> server. This could default to deployments in the same stack, but could\n> >> still allow deployments from anywhere.\n> >>\n> >> OS::Nova::Server support\n> >> ========================\n> >> https://review.openstack.org/#/c/58880\n> >> A new user_data_format=SOFTWARE_CONFIG is currently used to denote that\n> >> this server is configured via software config deployments. Like\n> >> user_data_format=HEAT_CFNTOOLS, nova_utils.build_userdata is used to build\n> >> the cloud-init parts required to support software config. However like\n> >> user_data_format=RAW anything specified in user_data will be parsed as\n> >> cloud-init data. If user_data is multi-part data then the parts will be\n> >> appended to the parts created in nova_utils.build_userdata.\n> >>\n> >> The agent used currently is os-collect-config. This is typically\n> >> configured to poll for metadata from a particular heat resource via the CFN\n> >> API using the configured ec2 keypair. In the current implementation the\n> >> resource which is polled is the OS::Nova::Server itself, since this is the\n> >> only resource known to exist at server boot time (deployment resources\n> >> depend on server resources, so have not been created yet). The ec2 keypair\n> >> comes from a user created implicitly with the server (similar to\n> >> SignalResponder resources). This means the template author doesn\'t need to\n> >> include User/AccessKey/AccessPolicy resources in their templates just to\n> >> enable os-collect-config metadata polling.\n> >>\n> >> Until now, polling the metadata for a resource just returns the metadata\n> >> which has been stored in the stack resource database. This implementation\n> >> changes metadata polling to actually query the deployments API to return\n> >> the latest deployments data. This means deployment state can be stored in\n> >> one place, and there is no need to keep various metadata stores updated\n> >> with any changed state.\n> >>\n> >> An actual template\n> >> ==================\n> >> http://paste.openstack.org/show/54988/\n> >> This template contains:\n> >> - a config resource\n> >> - 2 deployments which deploy that config with 2 different sets of inputs\n> >> - stack outputs which output the results of the deployments\n> >> - a server resource\n> >> - an os-refresh-config script delivered via cloud-config[2] which\n> >> executes config scripts with deployment inputs and signals outputs to the\n> >> provided webhook.\n> >>\n> >> /opt/stack/os-config-refresh/configure.d/55-heat-config-bash is a hook\n> >> specific for performing configuration via shell scripts, and only acts on\n> >> software config which has group=Heat::Shell. Each configuration management\n> >> tool will have its own hook, and will act on its own group namespace. Each\n> >> configuration management tool will also have its own way of passing inputs\n> >> and outputs. The hooks job is to invoke the CM tool with the given inputs\n> >> and script, then extract the outputs and signal heat.\n> >>\n> >> The server needs to have the CM tool and the hook already installed,\n> >> either by building a golden image or by using cloud-config during boot.\n> >>\n> >> Next steps\n> >> ==========\n> >> There is a lot left to do and I\'d like to spread the development load.\n> >> What happens next entirely depends on feedback to this POC, but here is my\n> >> ideal scenario:\n> >> - any feedback which causes churn on many of the current changes I will\n> >> address\n> >> - a volunteer is found to take the REST API/RPC/DB/heatclient changes and\n> >> make them ready to merge\n> >> - we continue to discuss and refine the resources, the changes to\n> >> OS::Nova::Server, and the example shell hook\n> >> - volunteers write hooks for different CM tools, Chef and Puppet hooks\n> >> will need to be attempted soon to validate this approach.\n> >>\n> >> Vaguely related changes include:\n> >> - Some solution for specifying cloud-init config, either the intrinsic\n> >> functions or cloud-init heat resources\n> >> - Some heatclient file inclusion mechanism - writing that python hook in\n> >> a heat yaml template was a bit painful ;)\n> >>\n> >> Trying for yourself\n> >> ===================\n> >> - Using diskimage-builder, create an ubuntu image with\n> >> tripleo-image-elements os-apply-config, os-refresh-config and\n> >> os-collect-config\n> >> - Create a local heat branch containing\n> >> https://review.openstack.org/#/q/topic:bp/cloud-init-resource,n,z and\n> >> https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z\n> >> - launch the above template with your created image\n> >>\n> >> cheers\n> >>\n> >> [1] https://review.openstack.org/#/c/58877/7/heat/engine/api.py\n> >> [2] This relies on these not-merged intrinsic functions\n> >> https://review.openstack.org/#/q/topic:bp/cloud-init-resource,n,z\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n\n\n','<CALR54ZMFU4jQVYBhOtEgnsaGDvtX2TgyrHHrfLC5fkBD7Js9Eg@mail.gmail.com>',NULL),('<1389123962.26071.16.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 14:46:02',-18000,'2014-01-07 19:46:02',NULL,'[openstack-dev] [Ceilometer] Sharing the load test result','On Mon, 2014-01-06 at 00:14 +0000, Deok-June Yi wrote:\n> Hi, Ceilometer team.\n> \n> I\'m writing to share my load test result and ask you for advice about\n> Ceilometer.\n> \n> Before starting, for whom doesn?t know Synaps [1], Synaps is\n> \'monitoring as a service\' project that provides AWS CloudWatch\n> compatible API. It was discussed to be merged with Ceilometer project\n> at Grizzly design phase, but Synaps developers could not join the\n> project for it at that time. And now Ceilometer has its own alarming\n> feature.\n> \n> A few days ago, I installed Ceilometer and Synaps on my test\n> environment and ran load test for over 2 days to evaluate their\n> alarming feature in the aspect of real-time requirement. Here I attached\n> test environment diagram and test result. The load model was as below.\n> 1.  Create 5,000 alarms\n> 2.  [Every 1 minute] Create 5,000 samples\n> \n> As a result, alarm evaluation time of Ceilometer was not predictable,\n> whereas Synaps evaluated all alarms within 2 seconds every minute.\n> \n> This comes from two different design decisions for alarm evaluation\n> between Ceilometer and Synaps. Synaps does not read database but read\n> in-memory and in-stream data for alarming while Ceilometer involves\n> database read operations with REST API call.\n\nSo you are saying that the Synaps server is storing 14,400,000 samples\nin memory (2 days of 5000 samples per minute)? Or are you saying that\nSynaps is storing just the 5000 alarm records in memory and then\nprocessing (determining if the alarm condition was met) the samples as\nthey pass through to a backend data store? I think it is the latter but\nI just want to make sure :)\n\nBest,\n-jay\n\n> I think Ceilometer is better to allow creating alarms with more complex\n> query on metrics. However Synaps is better if we have real-time\n> requirement with alarm evaluation.\n> \n> So, how about re-opening the blueprint, cw-publish [2]?  It was\n> discussed and designed [3] at the start of Grizzly development cycle,\n> but it has not been implemented. And now I would like to work for it. Or\n> is there any good idea to fulfill the real-time requirement with\n> Ceilometer?\n> \n> Please, don\'t hesitate in contacting me.\n> \n> Thank you, \n> June Yi\n> \n> [1] https://wiki.openstack.org/Synaps\n> [2] https://blueprints.launchpad.net/ceilometer/+spec/cw-publish\n> [3] https://wiki.openstack.org/wiki/Ceilometer/blueprints/multi-publisher\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<19.FE.09100.385F9C25@epcpsbgx2.samsung.com>',NULL),('<1389125861-sup-6283@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 12:23:24',-28800,'2014-01-07 20:23:24',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','What would be the benefit of using packages?\n\nWe\'ve specifically avoided packages because they complect[1] configuration\nand system state management with software delivery. The recent friction\nwe\'ve seen with MySQL is an example where the packages are not actually\nhelping us, they\'re hurting us because they encode too much configuration\ninstead of just delivering binaries.\n\nPerhaps those of us who have been involved a bit longer haven\'t done\na good job of communicating our reasons. I for one believe in the idea\nthat image based updates eliminate a lot of the entropy that comes along\nwith a package based updating system. For that reason alone I tend to\nlook at any packages that deliver configurable software as potentially\ndangerous (note that I think they\'re wonderful for libraries, utilities,\nand kernels. :)\n\n[1] http://www.infoq.com/presentations/Simple-Made-Easy\n\nExcerpts from James Slagle\'s message of 2014-01-07 12:01:07 -0800:\n> Hi,\n> \n> I\'d like to discuss some possible ways we could install the OpenStack\n> components from packages in tripleo-image-elements.  As most folks are\n> probably aware, there is a \"fork\" of tripleo-image-elements called\n> tripleo-puppet-elements which does install using packages, but it does\n> so using Puppet to do the installation and for managing the\n> configuration of the installed components.  I\'d like to kind of set\n> that aside for a moment and just discuss how we might support\n> installing from packages using tripleo-image-elements directly and not\n> using Puppet.\n> \n> One idea would be to add support for a new type (or likely 2 new\n> types: rpm and dpkg) to the source-repositories element.\n> source-repositories already knows about the git, tar, and file types,\n> so it seems somewhat natural to have additional types for rpm and\n> dpkg.\n> \n> A complication with that approach is that the existing elements assume\n> they\'re setting up everything from source.  So, if we take a look at\n> the nova element, and specifically install.d/74-nova, that script does\n> stuff like install a nova service, adds a nova user, creates needed\n> directories, etc.  All of that wouldn\'t need to be done if we were\n> installing from rpm or dpkg, b/c presumably the package would take\n> care of all that.\n> \n> We could fix that by making the install.d scripts only run if you\'re\n> installing a component from source.  In that sense, it might make\n> sense to add a new hook, source-install.d and only run those scripts\n> if the type is a source type in the source-repositories configuration.\n>  We could then have a package-install.d to handle the installation\n> from the packages type.   The install.d hook could still exist to do\n> things that might be common to the 2 methods.\n> \n> Thoughts on that approach or other ideas?\n> \n> I\'m currently working on a patchset I can submit to help prove it out.\n>  But, I\'d like to start discussion on the approach now to see if there\n> are other ideas or major opposition to that approach.\n> \n\n\n','<CAHV77z_NdriW5tqjnMAD-A7nzRPnaZo6ReO_zSRhttsmLo1x_g@mail.gmail.com>',NULL),('<1389127857.26071.23.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 15:50:57',-18000,'2014-01-07 20:50:57',NULL,'[openstack-dev] [Tempest][Solum] Writing functional tests in\n tempest style','On Mon, 2014-01-06 at 11:46 -0800, Georgy Okrokvertskhov wrote:\n\n> Thank you for your input. Right now this approach allows to run\n> integration tests with and without tempest. I think this is valuable\n> for the project as anyone can run integration tests on their laptop\n> having only keystone available.\n> \n> It will be great to have some input from Tempest team. Can we extract\n> some core tempest component to create a testing framework for projects\n> on stackforge? Having common integration test framework in tempest\n> style will help further project integration to OpenStack ecosystem\n> during incubation.\n\nHi Georgy,\n\nI created a blueprint for tracking this work:\n\nhttps://blueprints.launchpad.net/tempest/+spec/split-out-reusable-tempest-library\n\nIf I have some time this week, I\'ll look into estimating various\nbreakout work items for the blueprint.\n\nBest,\n-jay\n\n\n\n\n','<CAG_6_oki8N8Lkgdhf3wqEKxY6p6=g=74SF+fdxY0L1x_7o-jXw@mail.gmail.com>',NULL),('<1389131172-sup-9417@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 14:18:26',-28800,'2014-01-07 22:18:26',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from James Slagle\'s message of 2014-01-07 12:53:57 -0800:\n> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > What would be the benefit of using packages?\n> \n> We\'re building images on top of different distributions of Linux.\n> Those distributions themselves offer packaged and supported OpenStack\n> components.  So, one benefit is that you\'d be using what\'s \"blessed\"\n> by your distro if you chose to.  I think that\'s a farily common way\n> people are going to be used to installing components. The OpenStack\n> Installation guide says to install from packages, fwiw.\n> \n\nIndeed, this is how many people deploy traditional applications.\n\nHowever, what we\'re doing is intended to be a real, consumable deployment\nof OpenStack. Specifically one that is in the gate and scales out to\nany reasonable production load necessary.\n\nOne problem with scaling out to many nodes is that the traditional\napplication deployment patterns introduce too much entropy. This is really\nhard to patch out later. We are designing the software distribution system\nto avoid those problems from the beginning. Packages do the opposite,\nand encourage entropy by promising to try and update software with\nminimal invasion, thus enabling users to introduce one-off machines.\n\n> > We\'ve specifically avoided packages because they complect[1] configuration\n> > and system state management with software delivery. The recent friction\n> > we\'ve seen with MySQL is an example where the packages are not actually\n> > helping us, they\'re hurting us because they encode too much configuration\n> > instead of just delivering binaries.\n> \n> We\'re trying to do something fairly specific with the read only /\n> partition.  You\'re right, most packages aren\'t going to handle that\n> well.  So, yes you have a point from that perspective.\n>\n\nReadonly / is a really important feature of the deployment we\'re aiming\nat. Doing it with packages is quite possible. My point in asking why\nbother with packages is that when you have an entire image that has been\nverified and is known to work, what advantage does having a package for\neverything actually bring.\n\n> However, there are many examples of when packages help you.\n> Dependency resolution, version compatibility, methods of verification,\n> knowing what\'s installed, etc.  I don\'t think that\'s really an\n> argument or discussion worth having, because you either want to use\n> packages or you want to build it all from source.  There are\n> advantages/disadvantages to both methods, and what I\'m proposing is\n> that we support both methods, and not require everyone to only be able\n> to install from source.\n>\n\n\"Install from source\" is probably not the right way to put this. We\'re\ninstalling the virtualenvs from tarballs downloaded from pypi. We\'re\nalso installing 99.9% python, so we\'re not really going \"from source\",\nwe\'re just going \"from git\".\n\nBut anyway, I see your point and will capitulate that it is less weird\nfor people and thus may make the pill a little easier to swallow. But if\nI could have it my way, I\'d suggest that the packages be built to mirror\nthe structure of the element end-products as much as possible so that\nthey can be used with minimal change to elements.\n\n> > Perhaps those of us who have been involved a bit longer haven\'t done\n> > a good job of communicating our reasons. I for one believe in the idea\n> > that image based updates eliminate a lot of the entropy that comes along\n> > with a package based updating system. For that reason alone I tend to\n> > look at any packages that deliver configurable software as potentially\n> > dangerous (note that I think they\'re wonderful for libraries, utilities,\n> > and kernels. :)\n> \n> Using packages wouldn\'t prevent you from using the image based update\n> mechanism.  Anecdotally, I think image based updates could be a bit\n> heavy handed for something like picking up a quick security or bug fix\n> or the like.  That would be a scenario where a package update could\n> really be handy.  Especially if someone else (e.g., your distro) is\n> maintaining the package for you.\n> \n> For this proposal though, I was only talking about installation of the\n> components at image build time.\n> \n\nThe entire point of image based updates is that they are heavy handed.\nThe problem we\'re trying to solve is that you have a data center of (n)\nmachines and you don\'t want (n) unique sets of software,  where each\nmachine might have some hot fixes and not others. At 1000 machines it\nbecomes critical. At 10000 machines, the entropy matrix starts to get\nscary.\n\n\n','<CAHV77z_pmLivXdM4a7fiYrTbk1cpfUzk0XqH=JDAFsOYsuqOXQ@mail.gmail.com>',NULL),('<1389135050.3355035.1404749709717.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 12:15:09',-14400,'2014-07-07 16:15:09',NULL,'[openstack-dev] [Neutron] cloud-init IPv6 support','AFAIK, the cloud-init metadata service can currently be accessed only by sending a request to http://169.254.169.254, and no IPv6 equivalent is currently implemented. Does anyone working on this or tried to address this before?\n\nThanks,\nNir\n\n\n','<1304366979.3354114.1404749570649.JavaMail.zimbra@redhat.com>',NULL),('<1389135767-sup-5699@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 15:04:48',-28800,'2014-01-07 23:04:48',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Chris Jones\'s message of 2014-01-07 14:43:31 -0800:\n> Hi\n> \n> > On 7 Jan 2014, at 22:18, Clint Byrum <clint at fewbar.com> wrote:\n> > Packages do the opposite,\n> > and encourage entropy by promising to try and update software \n> \n> Building with packages doesn\'t require updating running systems with packages and more than building with git requires updating running systems with git pull.\n> One can simply build (and test!) a new image with updated packages and rebuild/takeover nodes.\n> \n\nIndeed, however one can _more_ simply build an image without package\ntooling...  and they will be more similar across multiple platforms.\n\nMy question still stands, what are the real advantages? So far the only\none that matters to me is \"makes it easier for people to think about\nusing it.\"\n\n\n','<071F926C-7746-45B7-BFB6-E60CD9298E9A@tenshu.net>',NULL),('<1389135901-sup-6612@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 15:12:39',-28800,'2014-01-07 23:12:39',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Fox, Kevin M\'s message of 2014-01-07 13:11:13 -0800:\n> I was going to stay silent on this one, but since you asked...\n> \n> /me puts his customer hat on\n> \n> We source OpenStack from RDO for the packages and additional integration testing that comes from the project instead of using OpenStack directly. I was a little turned off from Triple-O when I saw it was source only. The feeling being that it is \"too green\" for our tastes. Which may be inaccurate. While I might be convinced to use source, its a much harder sell to us currently then using packages.\n> \n\nKevin, thanks for sharing. I think I understand that it is just a new\nway of thinking and that makes it that much harder to consume.\n\nWe have good reasons for not using packages. And we\'re not just making\nthis up as a new crazy idea, we\'re copying what companies like Netflix\nhave published about running at scale. We need to do a better job at\nmaking sure why we\'re doing some of the things we\'re doing.\n\n\n','<1A3C52DFCD06494D8528644858247BF00C49E2@EX10MBOX03.pnnl.gov>',NULL),('<1389136650-sup-7934@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 15:45:40',-28800,'2014-01-07 23:45:40',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from James Slagle\'s message of 2014-01-07 15:03:33 -0800:\n> On Tue, Jan 7, 2014 at 5:18 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from James Slagle\'s message of 2014-01-07 12:53:57 -0800:\n> >> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum <clint at fewbar.com> wrote:\n> >> > What would be the benefit of using packages?\n> >>\n> >> We\'re building images on top of different distributions of Linux.\n> >> Those distributions themselves offer packaged and supported OpenStack\n> >> components.  So, one benefit is that you\'d be using what\'s \"blessed\"\n> >> by your distro if you chose to.  I think that\'s a farily common way\n> >> people are going to be used to installing components. The OpenStack\n> >> Installation guide says to install from packages, fwiw.\n> >>\n> >\n> > Indeed, this is how many people deploy traditional applications.\n> >\n> > However, what we\'re doing is intended to be a real, consumable deployment\n> > of OpenStack. Specifically one that is in the gate and scales out to\n> > any reasonable production load necessary.\n> >\n> > One problem with scaling out to many nodes is that the traditional\n> > application deployment patterns introduce too much entropy. This is really\n> > hard to patch out later. We are designing the software distribution system\n> > to avoid those problems from the beginning. Packages do the opposite,\n> > and encourage entropy by promising to try and update software with\n> > minimal invasion, thus enabling users to introduce one-off machines.\n> \n> This sounds more like an argument for a systems management approach\n> vs. installation.  I realize there\'s a big relation there.  However, I\n> don\'t think just using an image based system makes the entropy problem\n> go away.  At scale of 10,000 nodes (or more), you could easily have a\n> proliferation of images both that you\'ve built and that you\'ve\n> deployed.  You\'re not going to update everything at once.  Nor, do I\n> think you would only ever have 2 images running, for your latest\n> version N, and N-1..  You\'re going to have several different deployed\n> images running to account for hardware differences, updates that have\n> not yet been applied, migrations, etc.  My point is, the entropy\n> problem does not go away.  Ergo, it\'s not introduced by packages.\n> \n> Certainly it could be made worse by managing packages and their\n> updates by hand across 10,000 nodes.   But again, I don\'t think anyone\n> does that, they use a systems management tool that exists to\n> discourage drift and help with such entropy.\n> \n> Likewise, you\'re not going to be calling \"nova rebuild\" 10,000 times\n> manually when you want to do image based updates.  You\'d likely have\n> some tool (tuskar, something else, etc) that is going to manage that\n> for you, and help keep any drift in what images you actually have\n> deployed in check.\n> \n\nImage proliferation is far easier to measure than package proliferation.\nBut, that is not really the point.\n\nThe point is that we have a tool for software distribution that fits into\nour system management approach, and the distro packages do not take that\nsystem management approach into account.\n\nSo if you can\'t use the distro packages as-is, I\'m questioning what the\nactual benefit of using them at all is.\n\n> >\n> >> > We\'ve specifically avoided packages because they complect[1] configuration\n> >> > and system state management with software delivery. The recent friction\n> >> > we\'ve seen with MySQL is an example where the packages are not actually\n> >> > helping us, they\'re hurting us because they encode too much configuration\n> >> > instead of just delivering binaries.\n> >>\n> >> We\'re trying to do something fairly specific with the read only /\n> >> partition.  You\'re right, most packages aren\'t going to handle that\n> >> well.  So, yes you have a point from that perspective.\n> >>\n> >\n> > Readonly / is a really important feature of the deployment we\'re aiming\n> > at. Doing it with packages is quite possible. My point in asking why\n> > bother with packages is that when you have an entire image that has been\n> > verified and is known to work, what advantage does having a package for\n> > everything actually bring.\n> \n> Because distro packages are known to work, and thus you get higher\n> confidence from any image constructed from said packages.  At least, I\n> would, as opposed to installing from source (or \"from git\" as you say\n> below :).  It\'s the same reason I want to use a packaged kernel\n> instead of compiling it from source.  The benefit of the package is\n> not just in the compiling.  It\'s in the known good version and\n> compatibility with other known good versions I want to use.\n> \n\nI would disagree with \"known to work\". They are known to have been\ntested at some level. But IMO \"known to work\" requires testing _with\nyour workload_.\n\nSince you have to test your workload, why bother with the distro packages\nwhen you can get the upstream software and testing suite directly.\n\n> Am I going to implicitly trust any packages blindly or completely?  Of\n> course not. But, there is some confidence there in that the distro has\n> done some testing and said these versions are compatible, etc.\n> \n\nI think that confidence is misplaced and unnecessary. We provide test\nsuites to users and we will encourage users to test their own things. I\nimagine some will also ship packaged products based on TripleO that will\nalso be tested as a whole, not as individual packages.\n\n> >\n> >> However, there are many examples of when packages help you.\n> >> Dependency resolution, version compatibility, methods of verification,\n> >> knowing what\'s installed, etc.  I don\'t think that\'s really an\n> >> argument or discussion worth having, because you either want to use\n> >> packages or you want to build it all from source.  There are\n> >> advantages/disadvantages to both methods, and what I\'m proposing is\n> >> that we support both methods, and not require everyone to only be able\n> >> to install from source.\n> >>\n> >\n> > \"Install from source\" is probably not the right way to put this. We\'re\n> > installing the virtualenvs from tarballs downloaded from pypi. We\'re\n> > also installing 99.9% python, so we\'re not really going \"from source\",\n> > we\'re just going \"from git\".\n> \n> Yes, \"from source\" basically means \"from git\".  But, I fail to see the\n> distinction you\'re making in this context. Yes, the python source is\n> for all intents the same as the executable/library that is used at\n> runtime. Why are you opposed to installing that \"source\" from a\n> package vs a git repo?  What does using the git repo buy you?  If it\'s\n> avoiding the added complexity of the package, I already pointed out\n> some advantages to packaging as to why some people choose to use them\n> and thus accept that complexity\n> \n\nThe distinction is just that there\'s not a big advantage of the binaries\nbeing packaged separate from \"source\", that was all.\n\n> > But anyway, I see your point and will capitulate that it is less weird\n> > for people and thus may make the pill a little easier to swallow. But if\n> > I could have it my way, I\'d suggest that the packages be built to mirror\n> > the structure of the element end-products as much as possible so that\n> > they can be used with minimal change to elements.\n> \n> I don\'t know to what degree that\'s possible.  However, I think most\n> distros try to be as \"upstream\" friendly as possible.  In this\n> context, if the OpenStack community says \"this is how we recommend you\n> install our stuff, and our reference is t-i-e\", then I think packagers\n> and distros are inclined to follow that closely as much as possible.\n>\n\nPerhaps Fedora is more liberal, but I doubt Debian policy is\ngoing to allow default writing to /mnt/state or binaries in\n/opt/stack/venvs/nova/bin. :)\n\n> >\n> >> > Perhaps those of us who have been involved a bit longer haven\'t done\n> >> > a good job of communicating our reasons. I for one believe in the idea\n> >> > that image based updates eliminate a lot of the entropy that comes along\n> >> > with a package based updating system. For that reason alone I tend to\n> >> > look at any packages that deliver configurable software as potentially\n> >> > dangerous (note that I think they\'re wonderful for libraries, utilities,\n> >> > and kernels. :)\n> >>\n> >> Using packages wouldn\'t prevent you from using the image based update\n> >> mechanism.  Anecdotally, I think image based updates could be a bit\n> >> heavy handed for something like picking up a quick security or bug fix\n> >> or the like.  That would be a scenario where a package update could\n> >> really be handy.  Especially if someone else (e.g., your distro) is\n> >> maintaining the package for you.\n> >>\n> >> For this proposal though, I was only talking about installation of the\n> >> components at image build time.\n> >>\n> >\n> > The entire point of image based updates is that they are heavy handed.\n> > The problem we\'re trying to solve is that you have a data center of (n)\n> > machines and you don\'t want (n) unique sets of software,  where each\n> > machine might have some hot fixes and not others. At 1000 machines it\n> > becomes critical. At 10000 machines, the entropy matrix starts to get\n> > scary.\n> \n> I think I addressed this point earlier up.  But, using packages\n> doesn\'t mean (n) unique sets of software.  And using images doesn\'t\n> mean 1 unique set of software.  Certainly, we can come up with\n> solutions that aim to make it such that entropy is not introduced\n> accidentally.  And I think an image approach is a very good mechanism\n> for that.  But, even that does not protect completely against a well\n> meaning operator accidentally deploying the wrong thing, or making a\n> change that is not reflected in the image.  Just like we can\'t protect\n> against them logging in and running \"yum update foo\" inconsistently\n> across their deployment.\n> \n\nWe can stop all of those things with or without packages. My point isn\'t\nto say packages are harmful in an image-build-only context, it is to\nsay that I don\'t see the benefit.\n\nI think you\'re basically saying they\'re worth complexity because somebody\nelse tests them for you. I disagree, but I definitely would understand\nif people said I sound crazy and still want those packages.\n\n\n','<CAHV77z8fOrxmkyQCLuOLwxOLeU1ne1UOouuyQeBiSJX-u4bs2Q@mail.gmail.com>',NULL),('<1389148148-sup-2565@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 18:39:24',-28800,'2014-01-08 02:39:24',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from James Slagle\'s message of 2014-01-07 15:18:00 -0800:\n> On Tue, Jan 7, 2014 at 6:04 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Chris Jones\'s message of 2014-01-07 14:43:31 -0800:\n> >> Hi\n> >>\n> >> > On 7 Jan 2014, at 22:18, Clint Byrum <clint at fewbar.com> wrote:\n> >> > Packages do the opposite,\n> >> > and encourage entropy by promising to try and update software\n> >>\n> >> Building with packages doesn\'t require updating running systems with packages and more than building with git requires updating running systems with git pull.\n> >> One can simply build (and test!) a new image with updated packages and rebuild/takeover nodes.\n> >>\n> >\n> > Indeed, however one can _more_ simply build an image without package\n> > tooling...  and they will be more similar across multiple platforms.\n> >\n> > My question still stands, what are the real advantages? So far the only\n> > one that matters to me is \"makes it easier for people to think about\n> > using it.\"\n> \n> I\'m reminded of when I first started looking at TripleO there were a\n> few issues with installing from git (I\'ll say that from now on :)\n> related to all the python distribute -> setuptools migration.  Things\n> like if you\'re base cloud image had the wrong version of pip you\n> couldn\'t migrate to setuptools cleanly.  Then you had to run the\n> setuptools update twice, once to get the distribute legacy wrapper and\n> then again to latest setuptools.  If I recall there were other\n> problems with virtualenv incompatibilities as well.\n> \n> Arguably, installing from packages would have made that easier and less complex.\n\nNo argument, it would have been easier. But it would not have been less\ncomplex. The complexity would have been obscured.\n\nIt really would have just deferred the problem to the distro. That may\nbe a good thing, as the distro knows how to solve its own problems. But\nthen Fedora solves it, and Ubuntu solves it, and Debian solves it...\n\nOr, OpenStack solves it, once, and OpenStack\'s users roll on no matter\nwhat they choose for distro.\n\n> \n> Sure, the crux of the problem was likely that versions in the distro\n> were too old and they needed to be updated.  But unless we take on\n> building the whole OS from source/git/whatever every time, we\'re\n> always going to have that issue.  So, an additional benefit of\n> packages is that you can install a known good version of an OpenStack\n> component that is known to work with the versions of dependent\n> software you already have installed.\n> \n\nI disagree on the \"all or nothing\" argument. We can have a pre-packaged OS\nthat implements stable interfaces like POSIX, python-2.7 and even \"git\",\nand we can have a fast moving application like OpenStack riding on top\nof that in a self contained application container like a virtualenv or\neven a Docker container.\n\nThe Linux distro model is _really_ good at providing an OS, tools and\nlibraries. I am not so convinced that the distro model is actually\nany good for providing applications. I say that as one of the current\nmaintainers of MySQL, which mixes libraries and applications, in Debian.\n\nThe pain that the MySQL packaging team goes through just to have the thing\nwork similar to postgresql and apache is a little bit crazy-inducing,\nso please excuse me when I shake up the bottle and spray crazy all over\nthe list. :)\n\nAlso, \"known good\" is incredibly subjective, as \"good\" implies a set\nof expectations that are being met. But whatever that \"good\" means is\nfairly poorly defined and probably not automated. :P\n\n\n','<CAHV77z-dETJEcc4U91=cc-MtPkxMmc4nPJjUe_6CD1Rq9HchJQ@mail.gmail.com>',NULL),('<1389157283-sup-966@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 21:07:51',-28800,'2014-01-08 05:07:51',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Fox, Kevin M\'s message of 2014-01-07 16:27:35 -0800:\n> Another piece to the conversation I think is update philosophy. If\n> you are always going to require a new image and no customization after\n> build ever, ever, the messiness that source usually cause in the file\n> system image really doesn\'t matter. The package system allows you to\n> easily update, add, and remove packages bits at runtime cleanly. In\n> our experimenting with OpenStack, its becoming hard to determine\n> which philosophy is better. Golden Images for some things make a lot\n> of sense. For other random services, the maintenance of the Golden\n> Image seems to be too much to bother with and just installing a few\n> packages after image start is preferable. I think both approaches are\n> valuable. This may not directly relate to what is best for Triple-O\n> elements, but since we are talking philosophy anyway...\n> \n\nThe golden image approach should be identical to the package approach if\nyou are doing any kind of testing work-flow.\n\n\"Just install a few packages\" is how you end up with, as Robert said,\n\"snowflakes\". The approach we\'re taking with diskimage-builder should\nresult in that image building extremely rapidly, even if you compiled\nthose things from source.\n\nWhat I\'m suggesting is that you still need to test everything every\nchange you make, so you should just use the same work flow for\neverything.\n\n> Again though, I think if you wish to make the argument that packages\n> are undesirable, then ALL packages are probably undesirable for the same\n> reasons. Right? Why not make elements for all dependencies, instead\n> of using distro packages to get you 90% of the way there and then\n> using source just for OpenStack bits. If you always want the newest,\n> latest greatest Neutron, don\'t you want the newest VSwitch too? I\'d\n> argue though there is a point of diminishing returns with source that\n> packages fill. Then the argument is where is the point. Some folks think\n> the point is all the way over to \"just use packages for everything\".\n> \n\nI\'ve already stated that the distro is great for utilities, libraries,\ndrivers, kernels, etc. These are platform things, not application\nthings. OpenVSwitch _is_ part of the application, and I would entertain\nbuilding it for images if we found ourselves in need of hyper-advanced\nfeatures.\n\nWhat I\'ve bee suggesting is that if I\'m going to do the work to get\n\"latest OpenVSwitch\", if I do it in a source->image way, I don\'t have to\nrepeat it for every distribution\'s packaging tool chain.\n\n\n','<1A3C52DFCD06494D8528644858247BF00C4B5A@EX10MBOX03.pnnl.gov>',NULL),('<1389158804.26071.59.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 00:26:44',-18000,'2014-01-08 05:26:44',NULL,'[openstack-dev] [TripleO] Installing from packages in\n tripleo-image-elements','On Wed, 2014-01-08 at 17:20 +1300, Robert Collins wrote:\n> On 8 January 2014 12:18, James Slagle <james.slagle at gmail.com> wrote:\n> > Sure, the crux of the problem was likely that versions in the distro\n> > were too old and they needed to be updated.  But unless we take on\n> > building the whole OS from source/git/whatever every time, we\'re\n> > always going to have that issue.  So, an additional benefit of\n> > packages is that you can install a known good version of an OpenStack\n> > component that is known to work with the versions of dependent\n> > software you already have installed.\n> \n> The problem is that OpenStack is building against newer stuff than is\n> in distros, so folk building on a packaging toolchain are going to\n> often be in catchup mode - I think we need to anticipate package based\n> environments running against releases rather than CD.\n\nIt\'s about matching the expectations of the end user (deployer). If they\nlean towards a CD model, then git based OpenStack deployments are\nclearly a necessity -- otherwise we\'d need to maintain a set of package\narchives built (and tested!) for every project and every commit to\nmaster.\n\nIf they lean towards a more traditional release model, then OpenStack\npackages maintained (and tested!) by the distros are a better fit for\nthe end user.\n\nHowever...\n\nBoth camps should be able to experience the benefits of having an\nOpenStack undercloud building an OpenStack overcloud, without forcing\nthe end user to adopt a methodology they may not yet be comfortable\nwith.\n\nAs an aside, Fuel has an overcloud builder that uses Puppet to deploy\nOpenStack with packages [1]. I understand the Fuel dev team at Mirantis\nis keen to join forces with the Triple-O contributor community and\nreduce duplicative efforts. This may be the perfect place to pull some\npractices from Fuel to enable some flexibility in how\ntripleo-image-elements constructs things.\n\nIf you want a good indication of how much overlap there is, just look at\nthe list of puppet modules in Fuel [2] vs. the list of elements in t-i-e\n[3].\n\nSure, t-i-e is Bash scripts and Fuel is Puppet manifests, but they are\ntrying to do the same fundamental thing: produce an Overcloud entirely\nthrough automation. There are definite advantages to both approaches.\nWould be great to put our heads together and get the best of both\nworlds. I think the end user would benefit.\n\nAll the best,\n-jay\n\n[1] Just one example... here is the Glance installation by package:\nhttps://github.com/stackforge/fuel-library/blob/master/deployment/puppet/glance/manifests/registry.pp#L76\n[2]\nhttps://github.com/stackforge/fuel-library/tree/master/deployment/puppet\n[3]\nhttps://github.com/openstack/tripleo-image-elements/tree/master/elements\n\n\n\n','<CAJ3HoZ0e=Jx3Xw=dwNFf8yJteMk11_vtxDeAPUUogF3pjkiPJw@mail.gmail.com>',NULL),('<1389168132-sup-7998@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 00:16:20',-28800,'2014-01-08 08:16:20',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Jay Pipes\'s message of 2014-01-07 21:26:44 -0800:\n> On Wed, 2014-01-08 at 17:20 +1300, Robert Collins wrote:\n> > On 8 January 2014 12:18, James Slagle <james.slagle at gmail.com> wrote:\n> > > Sure, the crux of the problem was likely that versions in the distro\n> > > were too old and they needed to be updated.  But unless we take on\n> > > building the whole OS from source/git/whatever every time, we\'re\n> > > always going to have that issue.  So, an additional benefit of\n> > > packages is that you can install a known good version of an OpenStack\n> > > component that is known to work with the versions of dependent\n> > > software you already have installed.\n> > \n> > The problem is that OpenStack is building against newer stuff than is\n> > in distros, so folk building on a packaging toolchain are going to\n> > often be in catchup mode - I think we need to anticipate package based\n> > environments running against releases rather than CD.\n> \n> It\'s about matching the expectations of the end user (deployer). If they\n> lean towards a CD model, then git based OpenStack deployments are\n> clearly a necessity -- otherwise we\'d need to maintain a set of package\n> archives built (and tested!) for every project and every commit to\n> master.\n> \n> If they lean towards a more traditional release model, then OpenStack\n> packages maintained (and tested!) by the distros are a better fit for\n> the end user.\n> \n> However...\n> \n> Both camps should be able to experience the benefits of having an\n> OpenStack undercloud building an OpenStack overcloud, without forcing\n> the end user to adopt a methodology they may not yet be comfortable\n> with.\n> \n\nJay\'s statements highlight that I have not been clear during this\nthread. I don\'t mean to force any of the methods on anyone, and agree\nwith Jay that we should be able to leverage OpenStack to deploy OpenStack\nin many different ways.\n\nMy reason for questioning the value of packages is that we have limited\nresources, and I don\'t want to direct them toward an effort solely because\n\"thats what we\'ve always done\". I\'m a packager myself, so there is this\ndesire, sometimes, to just go back to the tools I\'m comfortable with.\n\nBut if there are developers who want and/or need to put time into using\npackages then by all means, I welcome you with open arms. I think the\nthread has proven to me that there is value in giving people the option\nto use TripleO\'s tools with packages.\n\n> As an aside, Fuel has an overcloud builder that uses Puppet to deploy\n> OpenStack with packages [1]. I understand the Fuel dev team at Mirantis\n> is keen to join forces with the Triple-O contributor community and\n> reduce duplicative efforts. This may be the perfect place to pull some\n> practices from Fuel to enable some flexibility in how\n> tripleo-image-elements constructs things.\n> \n> If you want a good indication of how much overlap there is, just look at\n> the list of puppet modules in Fuel [2] vs. the list of elements in t-i-e\n> [3].\n> \n\nNice comparison.\n\n> Sure, t-i-e is Bash scripts and Fuel is Puppet manifests, but they are\n> trying to do the same fundamental thing: produce an Overcloud entirely\n> through automation. There are definite advantages to both approaches.\n> Would be great to put our heads together and get the best of both\n> worlds. I think the end user would benefit.\n> \n\nRight, we are quite well aligned there. Where we run afoul of each\nother is that Puppet is a religion, and thus Fuel\'s puppet pieces are\nalienating the Chef believers. We\'d rather not do that in TripleO.\nReminding myself of this is why I realize above that \"not packages\"\nis also a religion, so I need to make sure I remain secular.\n\nI think we should actually use this as an example of where to plug\nPuppet in on top of the TripleO native tools which are emphatically not\never going to be a replacement for Puppet beyond the minimal needed to\nget a running, testable cloud.\n\nAnd then perhaps the Chef clergy can do the same, and we\'ll have a nice\nexample of how to layer tools on top of TripleO\'s modular design.\n\n> \n> [1] Just one example... here is the Glance installation by package:\n> https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/glance/manifests/registry.pp#L76\n> [2]\n> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet\n> [3]\n> https://github.com/openstack/tripleo-image-elements/tree/master/elements\n> \n\n\n','<1389158804.26071.59.camel@cranky>',NULL),('<1389172430.29732.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-08 17:13:50',28800,'2014-01-08 09:13:50',NULL,'[Openstack] research area in object storage','Hi all,?\n\nI am a Ph.D student, department of computer science, delhi university, Delhi, India\n\nI am working object storage as a service in cloud.\nI had studied the features provided by Amazon S3, Window Azure Blob Storage, EMC Atmos, Openstack Swift and Eucalyptus Walrus.\nI had studied Openstack Swift in detail like its documentation, whole source code etc.\nI had also installed it to make a feel of it.\nI am also going through software defined storage concept theoratically.\n\nCan somebody help me in suggesting some research area in which I can complete my thesis.\n\nThanks in advance?\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140108/a02a8840/attachment.html>\n\n',NULL,NULL),('<1389198541-sup-3572@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 08:36:50',-28800,'2014-01-08 16:36:50',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Derek Higgins\'s message of 2014-01-08 02:11:09 -0800:\n> On 08/01/14 05:07, Clint Byrum wrote:\n> > Excerpts from Fox, Kevin M\'s message of 2014-01-07 16:27:35 -0800:\n> >> Another piece to the conversation I think is update philosophy. If\n> >> you are always going to require a new image and no customization after\n> >> build ever, ever, the messiness that source usually cause in the file\n> >> system image really doesn\'t matter. The package system allows you to\n> >> easily update, add, and remove packages bits at runtime cleanly. In\n> >> our experimenting with OpenStack, its becoming hard to determine\n> >> which philosophy is better. Golden Images for some things make a lot\n> >> of sense. For other random services, the maintenance of the Golden\n> >> Image seems to be too much to bother with and just installing a few\n> >> packages after image start is preferable. I think both approaches are\n> >> valuable. This may not directly relate to what is best for Triple-O\n> >> elements, but since we are talking philosophy anyway...\n> >>\n> > \n> > The golden image approach should be identical to the package approach if\n> > you are doing any kind of testing work-flow.\n> > \n> > \"Just install a few packages\" is how you end up with, as Robert said,\n> > \"snowflakes\". The approach we\'re taking with diskimage-builder should\n> > result in that image building extremely rapidly, even if you compiled\n> > those things from source.\n> \n> This is the part of your argument I don\'t understand, creating images\n> with packages is no more likely to result in snowflakes then creating\n> images from sources in git.\n> \n> You would build an image using packages and at the end of the build\n> process you can lock the package versions. Regardless of how the image\n> is built you can consider it a golden image. This image is then deployed\n> to your hosts and not changed.\n> \n> We would still be using diskimage-builder the main difference to the\n> whole process is we would end up with a image that has more packages\n> installed and no virtual envs.\n> \n\nI\'m not saying building images from packages will encourage\nsnowflakes. I\'m saying installing and updating on systems using packages\nencourages snowflakes. Kevin was suggesting that the image workflow\nwouldn\'t fit for everything, and thus was opening up the \"just install\na few packages on a system\" can of worms. I\'m saying to Kevin, don\'t\ndo that, just make your image work-flow tighter, and suggesting it is\nworth it to do that to avoid having snowflakes.\n\n\n','<52CD243D.8050409@redhat.com>',NULL),('<1389199165-sup-6868@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 08:54:11',-28800,'2014-01-08 16:54:11',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from James Slagle\'s message of 2014-01-08 07:03:39 -0800:\n> On Tue, Jan 7, 2014 at 11:20 PM, Robert Collins\n> <robertc at robertcollins.net> wrote:\n> > On 8 January 2014 12:18, James Slagle <james.slagle at gmail.com> wrote:\n> >> Sure, the crux of the problem was likely that versions in the distro\n> >> were too old and they needed to be updated.  But unless we take on\n> >> building the whole OS from source/git/whatever every time, we\'re\n> >> always going to have that issue.  So, an additional benefit of\n> >> packages is that you can install a known good version of an OpenStack\n> >> component that is known to work with the versions of dependent\n> >> software you already have installed.\n> >\n> > The problem is that OpenStack is building against newer stuff than is\n> > in distros, so folk building on a packaging toolchain are going to\n> > often be in catchup mode - I think we need to anticipate package based\n> > environments running against releases rather than CD.\n> \n> I just don\'t see anyone not building on a packaging toolchain, given\n> that we\'re all running the distro of our choice and pip/virtualenv/etc\n> are installed from distro packages.  Trying to isolate the building of\n> components with pip installed virtualenvs was still a problem.  Short\n> of uninstalling the build tools packages from the cloud image and then\n> wget\'ing the pip tarball, I don\'t think there would have been a good\n> way around this particular problem.  Which, that approach may\n> certainly make some sense for a CD scenario.\n> \n\nI will definitely concede that we find problems at a high rate during\nimage builds, and that we would not if we just waited for others to solve\nthose problems. However, when we do solve those problems, we solve them\nfor everyone downstream from us. That is one reason it is so desirable\nto keep our work in TripleO as far upstream as possible. Package work is\ninherently downstream.\n\nAlso it is worth noting that problems at image build time are much simpler\nto handle, because they happen on a single machine generally. That is\none reason I down play those issues. For anyone not interested in running\nCD, we have the release process to handle such problems and they should\n_never_ see any of these issues, whether running from packages or on\nstable branches in the git repos.\n\n\n','<CAHV77z9kcLZeoXX9T9Fo-QbxuM-iFZE=r40O9vEc8oLkeLrK6Q@mail.gmail.com>',NULL),('<1389200066-sup-3741@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 09:01:29',-28800,'2014-01-08 17:01:29',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Jan Provaznik\'s message of 2014-01-08 03:00:19 -0800:\n> On 01/07/2014 09:01 PM, James Slagle wrote:\n> > Hi,\n> >\n> > I\'d like to discuss some possible ways we could install the OpenStack\n> > components from packages in tripleo-image-elements.  As most folks are\n> > probably aware, there is a \"fork\" of tripleo-image-elements called\n> > tripleo-puppet-elements which does install using packages, but it does\n> > so using Puppet to do the installation and for managing the\n> > configuration of the installed components.  I\'d like to kind of set\n> > that aside for a moment and just discuss how we might support\n> > installing from packages using tripleo-image-elements directly and not\n> > using Puppet.\n> >\n> > One idea would be to add support for a new type (or likely 2 new\n> > types: rpm and dpkg) to the source-repositories element.\n> > source-repositories already knows about the git, tar, and file types,\n> > so it seems somewhat natural to have additional types for rpm and\n> > dpkg.\n> >\n> > A complication with that approach is that the existing elements assume\n> > they\'re setting up everything from source.  So, if we take a look at\n> > the nova element, and specifically install.d/74-nova, that script does\n> > stuff like install a nova service, adds a nova user, creates needed\n> > directories, etc.  All of that wouldn\'t need to be done if we were\n> > installing from rpm or dpkg, b/c presumably the package would take\n> > care of all that.\n> >\n> > We could fix that by making the install.d scripts only run if you\'re\n> > installing a component from source.  In that sense, it might make\n> > sense to add a new hook, source-install.d and only run those scripts\n> > if the type is a source type in the source-repositories configuration.\n> >   We could then have a package-install.d to handle the installation\n> > from the packages type.   The install.d hook could still exist to do\n> > things that might be common to the 2 methods.\n> >\n> > Thoughts on that approach or other ideas?\n> >\n> > I\'m currently working on a patchset I can submit to help prove it out.\n> >   But, I\'d like to start discussion on the approach now to see if there\n> > are other ideas or major opposition to that approach.\n> >\n> \n> Hi James,\n> I think it would be really nice to be able install openstack+deps from \n> packages and many users (and cloud providers) would appreciate it.\n> \n> Among other things, with packages provided by a distro you get more \n> stability in compare to installing openstack from git repos and fetching \n> newest possible dependencies from pypi.\n> \n> In a real deployment setup  I don\'t want to use \"more-than-necessary\" \n> newer packages/dependencies when building images - taking an example \n> from last days I wouldn\'t have to bother with newer pip package which \n> breaks image building.\n> \n\nRight, from this perspective, you want to run OpenStack stable releases.\nThat should be fairly simple now by building images using the appropriate\nenvironment variables.\n\nHowever, we don\'t test that so it is likely to break as Icehouse diverges\nfrom Havana. So I think in addition to package-enabling, those who want\nto see TripleO work for stable releases should probably start looking at\ncreating stable branches of t-i-e and t-h-t to build images and templates\nfrom starting at the icehouse time-frame.\n\nSo given that I\'d suggest that packages take a back seat to making\nTripleO part of the integrated release of OpenStack. Otherwise we\'ll\njust have stable releases for the distros who have packages that work\nwith TripleO instead of for all distros.\n\n\n','<52CD2FC3.90204@redhat.com>',NULL),('<1389200498-sup-4794@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 09:03:55',-28800,'2014-01-08 17:03:55',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','Excerpts from Jay Dobies\'s message of 2014-01-08 08:09:51 -0800:\n> There were so many places in this thread that I wanted to jump in on as \n> I caught up, it makes sense to just summarize things in once place \n> instead of a half dozen quoted replies.\n> \n> I agree with the sentiments about flexibility. Regardless of my personal \n> preference on source v. packages, it\'s been my experience that the \n> general mindset of production deployment is that new ideas move slowly. \n> Admins are set in their ways and policies are in place on how things are \n> consumed.\n> \n> Maybe the newness of all things cloud-related and image-based management \n> for scale is a good time to shift the mentality out of packages (again, \n> I\'m not suggesting whether or not it should be shifted). But I worry \n> about adoption if we don\'t provide an option for people to use blessed \n> distro packages, either because of company policy or years of habit and \n> bias. If done correctly, there\'s no difference between a package and a \n> particular tag in a source repository, but there is a psychological \n> component there that I think we need to account for, assuming someone is \n> willing to bite off the implementation costs (which is sounds like there \n> is).\n> \n\nThanks for your thoughts Jay. I agree, what we\'re doing is kind of weird\nsounding. Not everybody will be on-board with their OpenStack cloud being\nwildly different from their existing systems. We definitely need to do\nwork to make it easy for them to get on the new train of thinking one\nstep at a time. Just having an OpenStack cloud will do a lot for any\norg that has none.\n\n\n','<52CD784F.8020901@redhat.com>',NULL),('<1389203293.441518070@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-01-08 11:48:13',-21600,'2014-01-08 17:48:13',NULL,'[openstack-community] Additional 2014 Industry Events\' Call For\n	Papers open','\nCall for Papers/presentations deadlines are coming up, in addition to the 3 sent in December (below).  Please note the HostingCon deadline of this Friday, January 10. The hosting industry is an important audience for OpenStack; we appreciate your support for this event.\n[http://www.hostingcon.com/] HostingCon, event date June 16-18 in Miami Beach, FL. Please submit talks at [http://www.hostingcon.com/speakers/speaking-proposal-guidelines/] http://www.hostingcon.com/speakers/speaking-proposal-guidelines/, by January 10.\n[https://www.usenix.org/conference/lisa14] USENIX LISA, event date November 9-14 in Seattle, WA.  CFP submissions due April 14 at https://www.usenix.org/sites/default/files/lisa14cfp_102813.pdf\nNote:  LISA was a great event for OpenStack in 2013, with over 1000 Large Installation System Admins participating.  We\'d like to propose a half day hands-on tutorial this year.  It\'s the week after the Paris Summit.  If you are interested in presenting the tutorial, please contact me (Kathy). \n \nThank you.\n \nOn Thursday, December 19, 2013 3:58pm, \"Kathy Cacciatore\" <kathyc at openstack.org> said:\n\n\n\n \n \nOpenStack\'s 2013 industry event experience indicates speaking sessions can be the best way to reach the most receptive audiences.  Speaking at industry events is a great way to educate OpenStack users and potential users while indirectly promoting your company\'s expertise. \n \nYour innovative presentations are requested for these upcoming events. The CFP hotlinks will direct you to details on the recommended topics and the submission forms. Learn more about the events and attendees by clicking on the event hotlinks.\n \nAs always, please feel free to contact me with questions - kathyc at openstack.org.  Thank you and happy holidays!\n[http://www.oscon.com/oscon2014] OSCON 2014, event date July 20-24 in Portland, OR.  [http://www.oscon.com/oscon2014/public/cfp/308] CFP due by January 30.  Audience is primarily very technical, leading edge developers, sys admins and open source enthusiasts who are most likely familiar and/or working with OpenStack software. They will appreciate in-depth topics.  OSCON 2014 coincides with the the software\'s 4th birthday.\n[http://www.cloudcomputingexpo.com/] Cloud Expo East, event date June 10-12 in New York City. [http://www.cloudcomputingexpo.com/general/papers2014east.htm] CFP due by March 1.  Audience is primarily IT managers and staff. At the 2013 event, we experienced most of this audience was looking for benefits of cloud computing, how cloud is differentiated from virtualization, and had heard of OpenStack but did not yet have specific knowledge of the software.  On the other hand, there were a few very technical conversations.  NYC-based user stories and business cases welcome.\n[http://cloudwf.com/interested-in-speaking/] Cloud World Forum Europe, event date June 17-18 in London.  [http://cloudwf.com/interested-in-speaking/] CFP deadline  to come; not yet listed.  Audience is a mix of IT decision makers and management, and evenly split between multinational enterprises and SMB.  European case studies would be ideal.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n \n\n\n\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140108/37c3fa98/attachment.html>\n\n',NULL,NULL),('<1389209362.26071.65.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 14:29:22',-18000,'2014-01-08 19:29:22',NULL,'[openstack-dev] [Neutron] Multiple config files for neutron\n server','On Wed, 2014-01-08 at 07:21 -0500, Sean Dague wrote:\n> On 01/06/2014 02:58 PM, Jay Pipes wrote:\n> > On Mon, 2014-01-06 at 23:45 +0400, Eugene Nikanorov wrote:\n> >> Hi folks,\n> >>\n> >>\n> >> Recently we had a discussion with Sean Dague on the matter.\n> >> Currently Neutron server has a number of configuration files used for\n> >> different purposes:\n> >>  - neutron.conf - main configuration parameters, plugins, db and mq\n> >> connections\n> >>  - plugin.ini - plugin-specific networking settings\n> >>  - conf files for ml2 mechanisms drivers (AFAIK to be able to use\n> >> several mechanism drivers we need to pass all of these conf files to\n> >> neutron server)\n> >>  - services.conf - recently introduced conf-file to gather\n> >> vendor-specific parameters for advanced services drivers.\n> >> Particularly, services.conf was introduced to avoid polluting\n> >> \'generic\' neutron.conf with vendor parameters and sections.\n> >>\n> >>\n> >> The discussion with Sean was about whether to add services.conf to\n> >> neutron-server launching command in devstack\n> >> (https://review.openstack.org/#/c/64377/ ). services.conf would be 3rd\n> >> config file that is passed to neutron-server along with neutron.conf\n> >> and plugin.ini.\n> >>\n> >>\n> >> Sean has an argument that providing many conf files in a command line\n> >> is not a good practice, suggesting setting up configuration directory\n> >> instead. There is no such capability in neutron right now so I\'d like\n> >> to hear opinions on this before putting more efforts in resolving this\n> >> in with other approach than used in the patch on review.\n> > \n> > I\'d say just put the additional conf file on the command line for now.\n> > Adding in support to oslo.cfg for a config directory can come later.\n> > \n> > Just my 2 cents,\n> \n> So the net of that is that in a production environment, in order to\n> change some services, you\'d be expected to change the init scripts to\n> list the right config files.\n\nGood point.\n\n> That seems *really* weird, and also really different from the rest of\n> OpenStack services. It also means you can\'t use the oslo config\n> generator to generate documented samples.\n> \n> If neutron had been running a grenade job, it would have blocked this\n> attempted change, because it would require adding config files between\n> releases.\n> \n> So this all smells pretty bad to me. Especially in the context of\n> migration paths from nova (which handles this very differently) => neutron.\n\nSo, I was under the impression that the Neutron changes to require a\nservices.conf had *already* been merged into master, and therefore the\nproblem domain here was not whether the services.conf addition was the\nright approach, but rather *how to deal with it in devstack*, and that\'s\nwhy I wrote to just add it to the command line in the devstack builder.\n\nA better (upstream in Neutron) solution would have been to use something\nlike an include.d/ directive in the nova.conf. But I thought that we\nwere past the implementation point in Neutron?\n\nBest,\n-jay\n\n\n\n','<52CD42DB.10203@dague.net>',NULL),('<1389209485.26071.66.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 14:31:25',-18000,'2014-01-08 19:31:25',NULL,'[openstack-dev] [nova] minimum review period for functional\n changes that break backwards compatibility','On Wed, 2014-01-08 at 14:26 +0100, Thierry Carrez wrote:\n> Tim Bell wrote:\n> > +1 from me too.... UpgradeImpact is a much better term.\n> \n> So this one is already documented[1], but I don\'t know if it actually\n> triggers anything yet.\n> \n> Should we configure it to post to openstack-operators, the same way as\n> SecurityImpact posts to openstack-security ?\n\nHuge +1 from me here.\n\n-jay\n\n\n\n','<52CD5218.6080901@openstack.org>',NULL),('<1389215129-sup-6872@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 13:17:59',-28800,'2014-01-08 21:17:59',NULL,'[openstack-dev] [TripleO] Installing from packages in\n	tripleo-image-elements','We\'re in agreement. What little entry there might be in a system of such\na small size would be entirely manageable by a single administrator...\n\nI care about that deployment, deeply, as that is how things like OpenStack\ntake root in IT departments.. with somebody playing around. However, what\nI care more about is that when that deployment goes from POC to reality,\nit can scale up to tens of admins and thousands of machines. If it cannot,\nif the user finds themselves doing things manually and handling problems\nby poking packages out to small classes of machines, then we have failed\nand OpenStack will be very costly for any org to scale out.\n\nExcerpts from Fox, Kevin M\'s message of 2014-01-08 09:22:15 -0800:\n> Let me give you a more concrete example, since you still think one size fits all here.\n> \n> I am using OpenStack on my home server now. In the past, I had one machine with lots of services on it. At times, I would update one service and during the update process, a different service would break.\n> \n> Last round of hardware purchasing got me an 8 core desktop processor with 16 gigs of ram. Enough to give every service I have its own processor and 2 gigs of ram. So, I decided to run OpenStack on the server to manage the service vm\'s.\n> \n> The base server  shares out my shared data with nfs, the vm\'s then re-export it in various ways like samba, dlna to my ps3, etc.\n> \n> Now, I could create a golden image for each service type with everything all setup and good to go. And infrastructure to constantly build updated ones.\n> \n> But in this case, grabbing Fedora cloud image or Ubuntu cloud image, and starting up the service with heat and a couple of line cloud init telling it to install just the package for the one service I need saves a ton of effort and space. The complexity is totally on the distro folks and not me. Very simple to maintain.\n> \n> I can get almost the stability of the golden image simply by pausing the working service vm, spawning a new one, and only if its sane, switch to it and delete the old. In fact, Heat is working towards (if not already done) having Heat itself do this process for you.\n> \n> I\'m all for golden images as a tool. We use them a lot. Like all tools though, there isn\'t one \"works for all cases best\" tool.\n> \n> I hope this use case helps.\n> \n> Thanks,\n> Kevin\n\n\n','<1A3C52DFCD06494D8528644858247BF00C4F55@EX10MBOX03.pnnl.gov>',NULL),('<1389242332.26071.83.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-08 23:38:52',-18000,'2014-01-09 04:38:52',NULL,'[openstack-dev] [Neutron][qa] Intermittent failure of tempest\n test test_network_basic_ops','On Wed, 2014-01-08 at 18:46 -0800, Sukhdev Kapur wrote:\n> Dear fellow developers, \n\n> I am running few Neutron tempest tests and noticing an intermittent\n> failure of tempest.scenario.test_network_basic_ops. \n\n> I ran this test 50+ times and am getting intermittent failure. The\n> pass rate is apps. 70%. The 30% of the time it fails mostly in\n> _check_public_network_connectivity. \n\n> Has anybody seen this? \n> If there is a fix or work around for this, please share your wisdom. \n\nUnfortunately, I believe you are running into this bug:\n\nhttps://bugs.launchpad.net/nova/+bug/1254890\n\nThe bug is Triaged in Nova (meaning, there is a suggested fix in the bug\nreport). It\'s currently affecting the gate negatively and is certainly\non the radar of the various PTLs affected.\n\nBest,\n-jay\n\n\n\n\n','<CA+wZVHSg8dbzknY4jPXgt6mkr5CvHs88e2nkGYrYzmdSU3zX9A@mail.gmail.com>',NULL),('<1389267006.10263.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-09 19:30:06',28800,'2014-01-09 11:30:06',NULL,'[Openstack] research area in object storage','thanks for the reply.\n\nI want to do something with software defined storage.\n\nplease suggest\n\n\n\nOn Wednesday, 8 January 2014 3:51 PM, Debojyoti Dutta <ddutta at gmail.com> wrote:\n \nOne way to start is to characterize and compare the performance of different backends for swift. That will open the doors to the next set of problems e.g. how do you optimize performance for certain classes of applications.?\n>\n>\n>You may also want to read the research papers by Sage et al. (ceph)\n>\n>\n>\n>debo\n>\n>\n>\n>\n>\n>On Wed, Jan 8, 2014 at 1:13 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>Hi all,?\n>>\n>>\n>>I am a Ph.D student, department of computer science, delhi university, Delhi, India\n>>\n>>\n>>I am working object storage as a service in cloud.\n>>I had studied the features provided by Amazon S3, Window Azure Blob Storage, EMC Atmos, Openstack Swift and Eucalyptus Walrus.\n>>I had studied Openstack Swift in detail like its documentation, whole source code etc.\n>>I had also installed it to make a feel of it.\n>>I am also going through software defined storage concept theoratically.\n>>\n>>\n>>Can somebody help me in suggesting some research area in which I can complete my thesis.\n>>\n>>\n>>Thanks in advance?\n>>Pragya Jain\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n>-- \n>-Debo~\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140109/a712d624/attachment.html>\n\n','<CADyX0K1aeckwnKyxuTVqPkD9-rkGzx3cKUTvyR-tJKSC9L3LTg@mail.gmail.com>',NULL),('<1389268897-sup-1407@clint-HP>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-01-09 05:04:00',-25200,'2014-01-09 12:04:00',NULL,'[OpenStack-Infra] An idea to scale Zuul','Excerpts from jeblair\'s message of 2014-01-08 23:59:45 -0700:\n> Hi,\n> \n> When Zuul gets very busy, it can end up launching hundreds of jobs\n> nearly simultaneously.  Each of them has to perform several git fetch\n> operations to obtain the changes needed for testing.  They fetch from\n> the git repos on the Zuul server because Zuul itself is creating those\n> commits by locally merging several changes together according to what\'s\n> in the queue.\n> \n> The acts of fetching and merging git patchsets (which is single\n> threaded) adds some load to the server, but in particular, serving those\n> git refs to 400 Jenkins nodes nearly simultaneously can also be a bit of\n> a burden.  It was too much for our previous server; we\'ve moved Zuul to\n> a faster server now, but it would be nice to have a more scalable\n> solution for the future.\n> \n> I\'d like to move the Zuul git merging component into a separate process\n> that can be located on a separate host (or hosts) and scaled out.\n> \n> The current zuul-server would continue to manage the queue and launch\n> jobs, but as it processes the queue and decides which changes should be\n> composed and built into zuul git refs, it would package the info about\n> each ref and put it on the gearman queue as a work item.  An instance of\n> the new component (zuul-merger) would fetch that job and fetch the\n> needed refs from Gerrit, and merge them.  It would also serve the\n> resulting git repo in the same way that Zuul does now.\n> \n> Zuul would not have to wait for a response before continuing to process\n> the queue, and since it\'s not doing any actual work, will be able to\n> move through the queue _much_ faster than currently.  Once Zuul _does_\n> receive a completion response from a zuul-merger, it can then launch the\n> jobs for that change.  It will pass the URL for that particular\n> zuul-merger (as ZUUL_URL) to the jobs so that they know from which\n> merger to fetch the zuul ref.  We can also use the cancel job\n> functionality in gearman if Zuul decides to reorder the queue.\n> \n> We can scale out the mergers horizontally and they can operate in\n> parallel, which should also improve the responsiveness of overall queue\n> processing.\n> \n> The only downside I currently foresee is that if we scale out the\n> mergers too much, we will see a performance impact on gerrit; therefore\n> we should anticipate having a reasonably small number of these (2-8,\n> perhaps).\n> \n> Since this is already quite modular, I think the implementation should\n> be relatively simple.\n> \n> How does that sound?\n\nThis takes advantage of my favorite part of the gearman worker/client\nmodel. You can have exactly as many workers as your back-end can handle,\nand then use the queue length as a direct measurement of latency which\nhelps you decide when to scale out the back-end (in this case, Gerrit).\n\n\n','<878uuphc7y.fsf@shiprock.lan>',NULL),('<1389277912-sup-331@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 07:32:47',-25200,'2014-01-09 14:32:47',NULL,'[openstack-dev] os-*-config in tripleo repositories','Excerpts from Derek Higgins\'s message of 2014-01-09 06:13:53 -0700:\n> It looks like we have some duplication and inconsistencies on the 3\n> os-*-config elements in the tripleo repositories\n> \n> os-apply-config (duplication) :\n>    We have two elements that install this\n>      diskimage-builder/elements/config-applier/\n>      tripleo-image-elements/elements/os-apply-config/\n> \n>    As far as I can tell the version in diskimage-builder isn\'t used by\n> tripleo and the upstart file is broke\n> ./dmesg:[   13.336184] init: Failed to spawn config-applier main\n> process: unable to execute: No such file or directory\n> \n>    To avoid confusion I propose we remove\n> diskimage-builder/elements/config-applier/ (or deprecated if we have a\n> suitable process) but would like to call it out here first to see if\n> anybody is using it or thinks its a bad idea?\n> \n> inconsistencies\n>   os-collect-config, os-refresh-config : these are both installed from\n> git into the global site-packages\n>   os-apply-config : installed from a released tarball into its own venv\n> \n>   To be consistent with the other elements all 3 I think should be\n> installed from git into its own venv, thoughts?\n> \n> If no objections I\'ll go ahead an do this next week,\n> \n\n+1 to all of your solutions. Thanks for cleaning up the mess we made. :)\n\n\n','<52CEA091.7000307@redhat.com>',NULL),('<1389280599.8225.3.camel@mblaptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-09 09:16:39',-21600,'2014-01-09 15:16:39',NULL,'[Openstack] Very Simple step-by-step Openstack\n Havana/Neutron/Openvswitch Installation guide','Marco,\nThis is very useful, at least for newbies like me.\nOne comment though, to make it even simpler, if you can add which file\nto edit when for example you setup the Network, or when you want to\nsetup the Database ( do not assume, we already know) :-).\nThanks,\nMounir\n\nOn Thu, 2014-01-09 at 10:55 +0000, Marco Fornaro wrote:\n> Hi Dimitrakis,\n> \n> Thanks\n> \n> I planned to:\n> ->Write point 10 of the guide (\" 10. Adding a Compute Node \") explaining how to easily add a compute node....and I guess I could end by next Monday\n> ->Write a guide poposing a full multi-node installation (honestly I already did that and tested, but there are some minor aspects I would like to check furter)\n> \n> Please feel free to post any suggested modify on this mailing list and/or on github\n> \n> BR\n> \n> Marco\n> \n> \n> -----Original Message-----\n> From: Georgios Dimitrakakis [mailto:giorgis at acmac.uoc.gr] \n> Sent: den 9 januari 2014 11:15\n> To: openstack at lists.openstack.org; openstack-docs at lists.openstack.org\n> Subject: Re: [Openstack] Very Simple step-by-step Openstack Havana/Neutron/Openvswitch Installation guide\n> \n>  Hi Marco!\n> \n>  It looks very interesting! Do you think that you will be able to point \n>  out the differences if someone would like to use two nodes (controller + \n>  compute) in order to setup openstack?\n> \n>  All the best,\n> \n>  G.\n> \n>  On Thu, 9 Jan 2014 10:03:05 +0000, Marco Fornaro wrote:\n> > Hi All,\n> >\n> > I wrote an unofficial as-easy-as-possible and step-by-step\n> > Installation guide for Openstack Havana+Neutron+Openvswitch:\n> >\n> > \n> > https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst\n> > [1]\n> >\n> > Please let me know what you think about and if it can be useful to\n> > anyone\n> >\n> > My Idea is to first check this guide \"easily\" published on github \n> > with\n> > users, and then propose a similar guide structure for some part of \n> > the\n> > official documentation (for instance as an example of complete\n> > installation)\n> >\n> > Best Regards\n> >\n> > Marco\n> >\n> >\n> >\n> > Links:\n> > ------\n> > [1]\n> > \n> > https://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst\n> \n\n\n\n\n','<C24481BC2FAA754ABE58127FA2A6273748B66E42@lhreml508-mbx>',NULL),('<1389281127.10695.4.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-09 15:25:28',0,'2014-01-09 15:25:28',NULL,'[Openstack] Designate DNSaaS installation issue','Hi Nick,\n\nI\'ll get psql re-tested this week, I expect it\'s something simple\ncausing the failure, but it\'s been a while since I\'ve tested with\nPostgreSQL.\n\nI\'ve filed bug #1267509 [1] on your behalf to track the issue, you can\nhit the \"This affects me too\" link at the top of the page to get\nnotified of progress.\n\n[1]: https://bugs.launchpad.net/designate/+bug/1267509\n\nThanks,\nKiall\n\nOn Mon, 2014-01-06 at 12:49 +0200, Nick Maslov wrote:\n> Hi Simon,\n> \n> \n> Say, are there any news on this issue?\n> \n> \n> Or - you can point me to a place in the code, where this check is -\n> and I will ask local python devs to help me with it.\n> \n> \n> Cheers,\n> NM\n> -- \n> Nick Maslov\n> Sent with Airmail\n> \n> On January 1, 2014 at 11:20:11 AM, Nick Maslov (azpekt at gmail.com)\n> wrote:\n> \n> > Hi Simon,\n> > \n> > \n> > Thanks a lot, will wait for updated version.\n> > \n> > \n> > Well, we decided to hit the Postgres road with this installation.\n> > And already had a lot of issues on that path, starting with small\n> > things like this to inability of Postgres to easily perform HA.\n> > \n> > \n> > Happy NY!\n> > \n> > \n> > -- \n> > Nick Maslov\n> > Sent with Airmail\n> > \n> > On December 31, 2013 at 5:27:10 PM, Simon McCartney\n> > (simon at mccartney.ie) wrote:\n> > \n> > > Hi Nick,  \n> > > \n> > > \n> > > I don\'t think we\'ve tested against Postgres recently, let me see\n> > > if we can get a Postgres test environment setup & tweak the SQLA\n> > > to keep Postgres happy.\n> > > \n> > > \n> > > (fwiw, we\'re using Percona/Galera MySQL clusters in production\n> > > with Designate)\n> > > \n> > > \n> > > Simon.\n> > > \n> > > On Tuesday, December 31, 2013, Nick Maslov wrote:\n> > >         Hi,\n> > >         \n> > >         \n> > >         I`m installing Designate as per this doc.\n> > >         \n> > >         \n> > >         When I try to use this command:\n> > >          designate-manage database-sync\n> > >         It fails with following:\n> > >         \n> > >         \n> > >         2013-12-31 12:20:39    DEBUG [migrate.versioning.util]\n> > >         Disposing SQLAlchemy engine Engine(postgres://designate:pa\n> > >         %24w0rd at pg01-001/designate)\n> > >         2013-12-31 12:20:39    ERROR [cliff.app] Postgresql ENUM\n> > >         type requires a name.\n> > >         ERROR: Postgresql ENUM type requires a name.\n> > >         \n> > >         \n> > >         I`m using PostgreSQL as backend for Designate. Can someone\n> > >         point me in the right direction, and maybe point to\n> > >         Designate developers?\n> > >         \n> > >         \n> > >         Thanks,\n> > >         NM\n> > >         \n> > >         \n> > >         \n> > >         -- \n> > >         Nick Maslov\n> > >         Sent with Airmail\n> > > \n> > > \n> > > --\n> > > Simon McCartney\n> > > E: simon at mccartney.ie\n> > > M: +44 7710 836 915\n> > > \n> > > \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 836 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140109/9f82bacb/attachment.pgp>\n\n','<etPan.52ca8a51.628c895d.5f4@mbp>',NULL),('<1389289643.20391.13.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-09 12:47:23',-18000,'2014-01-09 17:47:23',NULL,'[Openstack-operators] How do you keep your test env sync\'ed to\n production?','On Wed, 2014-01-08 at 23:56 -0700, Joe Topjian wrote:\n> Hi Jon,\n> \n> Our test environment consists of 8 bare-metal servers. One server\n> provides Cobbler and Puppet services and the other 7 are used for\n> OpenStack. The entire OpenStack configuration is managed through\n> Puppet.\n> \n> In the past, we would re-provision the bare-metal servers with a fresh\n> OS and then run Puppet to deploy OpenStack, but then we realized that\n> we could do everything nested inside an OpenStack environment. So the\n> bare-metal hardware is now a separate OpenStack environment which\n> allows us to test several different projects\' OpenStack configurations\n> under one main test cloud.\n\nThis sounds virtually identical to the Triple-O project\'s architecture\nof an undercloud and an overcloud -- and it makes sense, since a driving\nfactor behind Triple-O is continuous deployment testing. :)\n\nI\'m curious, though... how often do you change/update the *undercloud*\n-- the OpenStack installation that deploys the bare-metal machines? Is\nit just the *overcloud* that follows the master branches, or do you\nupdate the undercloud at a similar pace?\n\n> To create a test environment, we have Vagrant profiles for cloud\n> controllers, compute nodes, and swift nodes. Vagrant launches vms\n> inside the test cloud, does any needed bootstrapping (basically\n> emulating Cobbler\'s post-install hooks), the vms contact Puppet, and\n> are then configured with the latest production configuration.\n> \n> Our production network configurations have all been able to work in a\n> nested OpenStack environment. Sometimes this creates nested VLANs, but\n> we either ignore it or raise the MTU.\n\nAre you using Neutron? If so, what setup are you using for the\nundercloud and the overcloud? Are you using a flat or Vlan model for the\nundercloud and an SDN model (GRE? VxLAN?) for the overcloud?\n\n> The only thing that we cannot reliably reproduce in this environment\n> is the NetApp appliances that one production site runs. Unless NetApp\n> would like to send us a free 3240? =)\n\nLOL. We had the same issue in our testing environments at AT&T. :)\nStrangely, it was difficult to find a 3270 filer lying around that\nnobody wanted ;) So, instead we just tested on the iSCSI basic drivers\nfor Cinder.\n\n> \n> The other caveat is that launching instances has to be done with qemu\n> software virtualization. So far this has been fine. As long as an\n> instance can boot, receive an IP, attach a volume, etc, then\n> everything should be fine. We have not run into a case where an\n> OpenStack configuration has caused a certain type of image to fail.\n\nInteresting. Did you ever investigate using LXC containers instead of\nKVM/Qemu VMs for your testing environment OpenStack instances?\n\n> You make a good point about working with a production database dump.\n> I\'ll look into this for our environment.\n\n++ You may want to check with Mikal Still (cc\'d) about linking into\nturbo-hipster for testing schema migrations on \"realistic\" databases,\ntoo.\n\nBest,\n-jay\n\n\n\n\n','<CA+y7hvjqMWo8zk7vBuAGFF07sSx8GwNVfkCJr6b1QfEpywG3Sw@mail.gmail.com>',NULL),('<1389291052.20391.24.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 13:10:52',-18000,'2014-01-09 18:10:52',NULL,'[openstack-dev] [Neutron][qa] Intermittent failure of tempest\n test test_network_basic_ops','On Thu, 2014-01-09 at 09:09 +0100, Salvatore Orlando wrote:\n> I am afraid I need to correct you Jay!\n\nI always welcome corrections to things I\'ve gotten wrong, so no worries\nat all!\n\n> This actually appears to be bug 1253896 [1]\n\nAh, the infamous \"SSH bug\" :) Yeah, so last night I spent a few hours\ndigging through log files and running a variety of e-r queries trying to\nfind some patterns for the bugs that Joe G had sent an ML post about.\n\nI went round in circles, unfortunately :( When I thought I\'d found a\npattern, invariably I would doubt my initial findings and wander into\nnew areas in a wild goose chase.\n\nAt various times, I thought something was up with the DHCP agent, as\nthere were lots of \"No DHCP Agent found\" errors in the q-dhcp screen\nlogs. But I could not correlate any relationship with the failures in\nthe 4 bugs.\n\nThen I started thinking that there was a timing/race condition where a\nsecurity group was being added to the Nova-side servers cache before it\nhad actually been constructed fully on the Neutron-side. But I was not\nable to fully track down the many, many debug messages that are involved\nin the full sequence of VM launch :( At around 4am, I gave up and went\nto bed...\n\n> Technically, what we call \'bug\' here is actually a failure\n> manifestation.\n> So far, we have removed several bugs causing this failure. The last\n> patch was pushed to devstack around Christmas.\n> Nevertheless, if you look at recent comments and Joe\'s email, we still\n> have a non-negligible failure rate on the gate.\n\nUnderstood. I suspect actually that some of the various performance\nimprovements from Phil Day and others around optimizing certain server\nand secgroup list calls have made the underlying race conditions show up\nmore often -- since the list calls are completing much faster, which\nironically gives Neutron less time to complete setup operations!\n\nSo, a performance patch on the Nova side ends up putting more pressure\non the Neutron side, which causes the rate of occurrence for these\nsticky bugs (with potentially many root causes) to spike.\n\nSuch is life I guess :)\n\n> It is also worth mentioning that if you are running your tests with\n> parallelism enabled (ie: you\'re running tempest with tox -esmoke\n> rather than tox -esmokeserial) you will end up with a higher\n> occurrence of this failure due to more bugs causing it. These bugs are\n> due to some weakness in the OVS agent that we are addressing with\n> patches for blueprint neutron-tempest-parallel [2].\n\nInteresting. If you wouldn\'t mind, what makes you think this is a\nweakness in the OVS agent? I would certainly appreciate your expertise\nin this area, since it would help me in my own bug-searching endeavors.\n\nAll the best,\n-jay\n\n> Regards,\n> Salvatore\n> \n> \n> \n> \n> [1] https://bugs.launchpad.net/neutron/+bug/1253896\n> [2] https://blueprints.launchpad.net/neutron/+spec/neutron-tempest-parallel\n> \n> \n> On 9 January 2014 05:38, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Wed, 2014-01-08 at 18:46 -0800, Sukhdev Kapur wrote:\n>         > Dear fellow developers,\n>         \n>         > I am running few Neutron tempest tests and noticing an\n>         intermittent\n>         > failure of tempest.scenario.test_network_basic_ops.\n>         \n>         > I ran this test 50+ times and am getting intermittent\n>         failure. The\n>         > pass rate is apps. 70%. The 30% of the time it fails mostly\n>         in\n>         > _check_public_network_connectivity.\n>         \n>         > Has anybody seen this?\n>         > If there is a fix or work around for this, please share your\n>         wisdom.\n>         \n>         \n>         Unfortunately, I believe you are running into this bug:\n>         \n>         https://bugs.launchpad.net/nova/+bug/1254890\n>         \n>         The bug is Triaged in Nova (meaning, there is a suggested fix\n>         in the bug\n>         report). It\'s currently affecting the gate negatively and is\n>         certainly\n>         on the radar of the various PTLs affected.\n>         \n>         Best,\n>         -jay\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAGR=i3jtO6XxRYuwRMv1P6r2-HbC3jeskwPcXMzQ_CrJ-CJr4Q@mail.gmail.com>',NULL),('<1389292089.20391.30.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 13:28:09',-18000,'2014-01-09 18:28:09',NULL,'[openstack-dev] [oslo.config] Centralized config management','On Thu, 2014-01-09 at 10:23 +0100, Flavio Percoco wrote:\n> On 08/01/14 17:13 -0800, Nachi Ueno wrote:\n> >Hi folks\n> >\n> >OpenStack process tend to have many config options, and many hosts.\n> >It is a pain to manage this tons of config options.\n> >To centralize this management helps operation.\n> >\n> >We can use chef or puppet kind of tools, however\n> >sometimes each process depends on the other processes configuration.\n> >For example, nova depends on neutron configuration etc\n> >\n> >My idea is to have config server in oslo.config, and let cfg.CONF get\n> >config from the server.\n> >This way has several benefits.\n> >\n> >- We can get centralized management without modification on each\n> >projects ( nova, neutron, etc)\n> >- We can provide horizon for configuration\n> >\n> >This is bp for this proposal.\n> >https://blueprints.launchpad.net/oslo/+spec/oslo-config-centralized\n> >\n> >I\'m very appreciate any comments on this.\n> \n> I\'ve thought about this as well. I like the overall idea of having a\n> config server. However, I don\'t like the idea of having it within\n> oslo.config. I\'d prefer oslo.config to remain a library.\n> \n> Also, I think it would be more complex than just having a server that\n> provides the configs. It\'ll need authentication like all other\n> services in OpenStack and perhaps even support of encryption.\n> \n> I like the idea of a config registry but as mentioned above, IMHO it\'s\n> to live under its own project.\n\nHi Nati and Flavio!\n\nSo, I\'m -1 on this idea, just because I think it belongs in the realm of\nconfiguration management tooling (Chef/Puppet/Salt/Ansible/etc). Those\ntools are built to manage multiple configuration files and changes in\nthem. Adding a config server would dramatically change the way that\nconfiguration management tools would interface with OpenStack services.\nInstead of managing the config file templates as all of the tools\ncurrently do, the tools would need to essentially need to forego the\ntried-and-true INI files and instead write a bunch of code in order to\ndeal with REST API set/get operations for changing configuration data.\n\nIn summary, while I agree that OpenStack services have an absolute TON\nof configurability -- for good and bad -- there are ways to improve the\nusability of configuration without changing the paradigm that most\nconfiguration management tools expect. One such example is having\ninclude.d/ support -- similar to the existing oslo.cfg module\'s support\nfor a --config-dir, but more flexible and more like what other open\nsource programs (like Apache) have done for years.\n\nAll the best,\n-jay\n\n\n\n','<20140109092346.GE20674@redhat.com>',NULL),('<1389293602.20391.32.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 13:53:22',-18000,'2014-01-09 18:53:22',NULL,'[openstack-dev] [all] Organizing a Gate Blocking Bug Fix Day','On Thu, 2014-01-09 at 07:46 -0500, Sean Dague wrote:\n> I think we are all agreed that the current state of Gate Resets isn\'t \n> good. Unfortunately some basic functionality is really not working \n> reliably, like being able to boot a guest to a point where you can ssh \n> into it.\n> \n> These are common bugs, but they aren\'t easy ones. We\'ve had a few folks \n> digging deep on these, but we, as a community, are not keeping up with them.\n> \n> So I\'d like to propose Gate Blocking Bug Fix day, to be Monday Jan 20th. \n> On that day I\'d ask all core reviewers (and anyone else) on all projects \n> to set aside that day to *only* work on gate blocking bugs. We\'d like to \n> quiet the queues to not include any other changes that day so that only \n> fixes related to gate blocking bugs would be in the system.\n> \n> This will have multiple goals:\n>   #1 - fix some of the top issues\n>   #2 - ensure we classify (ER fingerprint) and register everything we\'re \n> seeing in the gate fails\n>   #3 - ensure all gate bugs are triaged appropriately\n> \n> I\'m hopefully that if we can get everyone looking at this one a single \n> day, we can start to dislodge the log jam that exists.\n> \n> Specifically I\'d like to get commitments from as many PTLs as possible \n> that they\'ll both directly participate in the day, as well as encourage \n> the rest of their project to do the same.\n\nI\'m in.\n\nDue to what ttx mentioned about I-2, I think the 13th Jan or 27th Jan\nMondays would be better.\n\nPersonally, I think sooner is better. The severity of the disruption is\nquite high, and action is needed ASAP.\n\nBest,\n-jay\n\n\n\n','<52CE9A2B.5060108@dague.net>',NULL),('<1389300020.23412.11.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 15:40:20',-18000,'2014-01-09 20:40:20',NULL,'[openstack-dev] [oslo.config] Centralized config management','Hope you don\'t mind, I\'ll jump in here :)\n\nOn Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:\n> Hi Jeremy\n> \n> Don\'t you think it is burden for operators if we should choose correct\n> combination of config for multiple nodes even if we have chef and\n> puppet?\n\nIt\'s more of a burden for operators to have to configure OpenStack in\nmultiple ways.\n\n> If we have some constraint or dependency in configurations, such logic\n> should be in openstack source code.\n\nCould you explain this a bit more? I generally view packages and things\nlike requirements.txt and setup.py [extra] sections as the canonical way\nof resolving dependencies. An example here would be great.\n\n> We can solve this issue if we have a standard way to know the config\n> value of other process in the other host.\n> \n> Something like this.\n> self.conf.host(\'host1\').firewall_driver\n\nThis is already in every configuration management system I can think of.\n\nIn Chef, a cookbook can call out to search (or partial search) for the\nnode in question and retrieve such information (called attributes in\nChef-world).\n\nIn Puppet, one would use Hiera to look up another node\'s configuration.\n\nIn Ansible, one would use a \"Dynamic Inventory\".\n\nIn Salt, you\'d use Salt Mine.\n\n> Then we can have a chef/or file baed config backend code for this for example.\n\nI actually think you\'re thinking about this in the reverse way to the\nway operators think about things. Operators want all configuration data\nmanaged by a singular system -- their configuration management system.\nAdding a different configuration data manager into the mix is the\nopposite of what most operators would like, at least, that\'s just in my\nexperience.\n\nAll the best,\n-jay\n\n\n\n','<CABJepwg3ZwhG-AKKJ_e3miLUiO4cY0V9iUc9n2hn7bq1sLDodg@mail.gmail.com>',NULL),('<1389303734.23412.24.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 16:42:14',-18000,'2014-01-09 21:42:14',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','On Thu, 2014-01-09 at 16:02 -0500, Tzu-Mainn Chen wrote:> There are a\nnumber of other models in the tuskar code[1], do we need to\n> > consider these now too?\n> > \n> > [1]:\n> > https://github.com/openstack/tuskar/blob/master/tuskar/db/sqlalchemy/models.py\n> \n> Nope, these are gone now, in favor of Tuskar interacting directly with Ironic, Heat, etc.\n\nHmm, not quite.\n\nIf compare the models in Ironic [1] to Tuskar\'s (link above), there are\nsome dramatic differences. Notably:\n\n* No Rack model in Ironic. Closest model seems to be the Chassis model\n[2], but the Ironic Chassis model doesn\'t have nearly the entity\nspecificity that Tuskar\'s Rack model has. For example, the following\n(important) attributes are missing from Ironic\'s Chassis model:\n - slots (how does Ironic know how many RU are in a chassis?)\n - location (very important for integration with operations inventory\nmanagement systems, trust me)\n - subnet (based on my experience, I\'ve seen deployers use a\nrack-by-rack or paired-rack control and data plane network static IP\nassignment. While Tuskar\'s single subnet attribute is not really\nadequate for describing production deployments that typically have 3+\nmanagement, data and overlay network routing rules for each rack, at\nleast Tuskar has the concept of networking rules in its Rack model,\nwhile Ironic does not)\n - state (how does Ironic know whether a rack is provisioned fully or\nnot? Must it query each each Node\'s powr_state field that has a\nchassis_id matching the Chassis\' id field?)\n - \n* The Tuskar Rack model has a field \"chassis_id\". I have no idea what\nthis is... or its relation to the Ironic Chassis model.\n\nAs much as the Tuskar Chassis model is lacking compared to the Tuskar\nRack model, the opposite problem exists for each project\'s model of\nNode. In Tuskar, the Node model is pretty bare and useless, whereas\nIronic\'s Node model is much richer.\n\nSo, it\'s not as simple as it may initially seem :)\n\nBest,\n-jay\n\n[1]\nhttps://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py\n[2]\nhttps://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py#L83\n\n\n\n\n','<470480930.15743677.1389301337684.JavaMail.root@redhat.com>',NULL),('<1389308499.23412.28.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 18:01:39',-18000,'2014-01-09 23:01:39',NULL,'[openstack-dev] Less option (was: [oslo.config] Centralized\n config management)','On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote:\n> On Thu, Jan 09 2014, Jay Pipes wrote:\n> \n> > Hope you don\'t mind, I\'ll jump in here :)\n> >\n> > On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:\n> >> Hi Jeremy\n> >> \n> >> Don\'t you think it is burden for operators if we should choose correct\n> >> combination of config for multiple nodes even if we have chef and\n> >> puppet?\n> >\n> > It\'s more of a burden for operators to have to configure OpenStack in\n> > multiple ways.\n> \n> I also think projects should try to minimize configuration options at\n> their minimum so operators are completely lost. Opening the sample\n> nova.conf and seeing 696 options is not what I would call user friendly.\n> \n> And also having working default. I know it\'s hard, but we should really\n> try to think about that sometimes.\n\n+100 :)\n\n-jay\n\n\n\n','<m261ps69yw.fsf_-_@danjou.info>',NULL),('<1389311052-sup-7772@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 16:45:09',-25200,'2014-01-09 23:45:09',NULL,'[openstack-dev] os-*-config in tripleo repositories','Excerpts from Dan Prince\'s message of 2014-01-09 11:56:16 -0700:\n> \n> ----- Original Message -----\n> > From: \"Derek Higgins\" <derekh at redhat.com>\n> > To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> > Sent: Thursday, January 9, 2014 8:13:53 AM\n> > Subject: [openstack-dev] os-*-config in tripleo repositories\n> > \n> > It looks like we have some duplication and inconsistencies on the 3\n> > os-*-config elements in the tripleo repositories\n> > \n> > os-apply-config (duplication) :\n> >    We have two elements that install this\n> >      diskimage-builder/elements/config-applier/\n> >      tripleo-image-elements/elements/os-apply-config/\n> > \n> >    As far as I can tell the version in diskimage-builder isn\'t used by\n> > tripleo and the upstart file is broke\n> > ./dmesg:[   13.336184] init: Failed to spawn config-applier main\n> > process: unable to execute: No such file or directory\n> > \n> >    To avoid confusion I propose we remove\n> > diskimage-builder/elements/config-applier/ (or deprecated if we have a\n> > suitable process) but would like to call it out here first to see if\n> > anybody is using it or thinks its a bad idea?\n> > \n> > inconsistencies\n> >   os-collect-config, os-refresh-config : these are both installed from\n> > git into the global site-packages\n> >   os-apply-config : installed from a released tarball into its own venv\n> > \n> >   To be consistent with the other elements all 3 I think should be\n> > installed from git into its own venv, thoughts?\n> \n> These all sound good to me and I\'ve got no issues with cleaning these up.\n> \n> I\'m not the biggest fan of having multiple venv\'s for each component though. Especially now that we have a global requirements.txt file where we can target a common baseline. Multiple venvs causes lots of duplicated libraries and increased image build time. Is anyone planning on making consolidated venv\'s an option? Or perhaps even just using a consolidated venv as the default where possible.\n> \n\nIt should probably be an option, as it is helpful to keep things isolated\nin CD where requirements do not stabilize all together, but for stable\nreleases it would make a lot of sense.\n\n\n','<1344107190.97087287.1389293776665.JavaMail.root@redhat.com>',NULL),('<1389337891.2965.16.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-10 17:11:31',36000,'2014-01-10 07:11:31',NULL,'[openstack-dev] [wsme] Undefined attributes in WSME','On Thu, 2014-01-09 at 11:16 +0100, Julien Danjou wrote:\n> On Thu, Jan 09 2014, Jamie Lennox wrote:\n> \n> > Is there any way to have WSME pass through arbitrary attributes to the\n> > created object? There is nothing that i can see in the documentation or code\n> > that would seem to support this.\n> >\n> > In keystone we have the situation where arbitrary data was able to be\n> > attached to our resources. For example there are a certain number of\n> > predefined attributes for a user including name, email but if you want to\n> > include an address you just add an \'address\': \'value\' to the resource\n> > creation and it will be saved and returned to you when you request the\n> > resource.\n> >\n> > Ignoring whether this is a good idea or not (it\'s done), is the option there\n> > that i missed - or is there any plans/way to support something like this?\n> \n> You can use something like:\n> \n>   class Resource(object):\n>       metadata = {wtypes.text: wtypes.text}\n> \n> Would that solve your problem?\n> \n\nThat would still only give me 1 level and i would then have to manually\nparse out the arguments i was expecting. Continuing the example there is\nnothing in the current implementation stopping people from using\n        \n        {\'address\': {\'street\': \'..\', \'country\': \'..\'}} \n        \nSo we can\'t just have the flat dictionary. (and i think wsme would fail\nif someone passed an integer value for example).\n\nWhat i\'m kind of hoping for is some sort of remainder value in wsme such\nthat i could define my base types:\n\n        class User(object): \n            id = wtypes.text\n            email = wtypes.text\n        \nand later have a user: \n\n        >>> user.id\n        \'9da353d02c0546ab9b3b402f58c6ab0d\'\n        >>> user.email\n        \'user at provider\'\n        >>> user.remainder\n        {\'address\': {\'country\': \'..\', \'street\': \'..\'}}\n\nnow i\'m obviously not expecting exactly that - but hoping for some kind\nof catch all that i can use. \n\nThanks, \n\nJamie\n\n\n\n','<m28uup8npo.fsf@danjou.info>',NULL),('<1389350070.12234.91.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-10 10:34:30',0,'2014-01-10 10:34:30',NULL,'[openstack-tc] Paris Design Summit Scheduling','On Thu, 2014-01-09 at 14:52 -0600, Lauren Sell wrote:\n> \n> We need to make a decision for the Paris design summit pretty quickly.\n> The Summit will take place the week of November 3 at the Palais des\n> Congres, and we?re planning to host the design sessions directly\n> across the street in the Le Meridien. We?ll run the keynote, expo and\n> breakout sessions Monday - Wednesday (three, rather than four days),\n> and we have the option to run the design sessions either Tuesday -\n> Friday or Wednesday - Saturday. \n\nLike Thierry, I see benefits and downsides to both options.\n\nWhat I think is most important is that we try something different from\nAtlanta to get another data point.\n\nHowever, both options will be something new - in Atlanta, we only have 1\nnon-overlapping day and 3 overlapping days. The choice for Paris is 2\nnon-overlapping and 2 overlapping days vs 3 non-overlapping and 1\noverlapping.\n\nI think I\'d prefer to try the more different option - Wednesday to\nSaturday.\n\nPerhaps we could also try to mix things up a little bit on the Saturday.\nFor example, we could have more smaller rooms (assuming the logistics\nallows for easy splitting of rooms) set up in boardroom style and some\nsort of on-the-day scheduling mechanism. This would allow us to have a\nbunch of smaller group discussions to wrap up some of the open questions\nfrom sessions during the week.\n\nThat\'s just a random idea on the format change - my thinking is that the\nfinal day on a Saturday would naturally have a different feel anyway, so\nif we embrace that we could avoid some of the fatigue.\n\nMark.\n\n\n\n','<65927ABC-3898-4FE5-9300-B9F1E64A92F7@openstack.org>',NULL),('<1389350704.12234.97.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-10 10:45:04',0,'2014-01-10 10:45:04',NULL,'[openstack-tc] Governance documents','On Wed, 2013-12-18 at 08:49 -0500, Sean Dague wrote:\n> On 12/18/2013 08:38 AM, Thierry Carrez wrote:\n> > Anne Gentle wrote:\n> >> Love the automation, dislike the landing of docs.openstack.org\n> >> <http://docs.openstack.org> as it connotes that my group is responsible.\n> >> How about www.openstack.org/governance\n> >> <http://www.openstack.org/governance>?\n> > \n> > Agree that we should not publish under docs.openstack.org but use\n> > another domain (or a subdomain of www.o.o).\n\nYeah, I didn\'t see it at first but Anne being concerned about any and\nall auto-published content from the project going to docs.openstack.org\nmakes total sense. That domain should be reserved for content the docs\nteam feel they have some control over.\n\nMaybe there\'s an argument for moving:\n\n  docs.openstack.org/developer/\n\nto\n\n  developer.openstack.org/docs/\n\n> > www.o.o/governance might imply more than we can reach, though\n> > (foundation + project). Maybe governance.o.o ?\n> \n> Good point on urls. http://openstack.org/tc/governance is probably where\n> this should go. If we aren\'t able to publish to there, that\'s a\n> technical issue that should get addressed.\n\nMinor point - I\'d reverse that to /governance/tc/\n\nIf anyone was motivated, I\'m sure the Foundation Board would welcome\nsome of their more static documents moving off the wiki too e.g.\n\n  https://wiki.openstack.org/wiki/Governance/Foundation/Mission\n  https://wiki.openstack.org/wiki/Governance/Foundation/Structure\n  https://wiki.openstack.org/wiki/Governance/Foundation/Funding\n\nMark.\n\n\n\n','<52B1A7E2.9080409@dague.net>',NULL),('<1389352653.12234.100.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-10 11:17:33',0,'2014-01-10 11:17:33',NULL,'[openstack-tc] Paris Design Summit Scheduling','On Fri, 2014-01-10 at 11:44 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > However, both options will be something new - in Atlanta, we only have 1\n> > non-overlapping day and 3 overlapping days. The choice for Paris is 2\n> > non-overlapping and 2 overlapping days vs 3 non-overlapping and 1\n> > overlapping.\n> \n> Note that the choice for Paris actually is \"1 non-overlapping and 2\n> overlapping days vs. 2 non-overlapping and 1 overlapping\", since the\n> conference is only scheduled for Mon-Wed.\n\nMath is hard :)\n\nI\'m talking about the days of the design summit, so ...\n\nAtlanta:\n\n  Overlapping: Tuesday/Wednesday/Thursday\n  Non-overlapping: Friday\n\nParis Option 1:\n\n  Overlapping: Tuesday/Wednesday\n  Non-overlapping: Thursday/Friday\n\nParis Option 2:\n\n  Overlapping: Wednesday\n  Non-overlapping: Thursday/Friday/Saturday\n\nMark.\n\n\n\n','<52CFCF09.6080104@openstack.org>',NULL),('<1389355274.12234.108.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-10 12:01:14',0,'2014-01-10 12:01:14',NULL,'[openstack-dev] Less option (was: [oslo.config] Centralized\n config management)','On Thu, 2014-01-09 at 16:34 -0800, Joe Gordon wrote:\n> On Thu, Jan 9, 2014 at 3:01 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Thu, 2014-01-09 at 23:56 +0100, Julien Danjou wrote:\n> > > On Thu, Jan 09 2014, Jay Pipes wrote:\n> > >\n> > > > Hope you don\'t mind, I\'ll jump in here :)\n> > > >\n> > > > On Thu, 2014-01-09 at 11:08 -0800, Nachi Ueno wrote:\n> > > >> Hi Jeremy\n> > > >>\n> > > >> Don\'t you think it is burden for operators if we should choose correct\n> > > >> combination of config for multiple nodes even if we have chef and\n> > > >> puppet?\n> > > >\n> > > > It\'s more of a burden for operators to have to configure OpenStack in\n> > > > multiple ways.\n> > >\n> > > I also think projects should try to minimize configuration options at\n> > > their minimum so operators are completely lost. Opening the sample\n> > > nova.conf and seeing 696 options is not what I would call user friendly.\n> > >\n> >\n> \n> \n> There was talk a while back about marking different config options as basic\n> and advanced (or something along those lines) to help make it easier for\n> operators.\n\nYou might be thinking of this session summit I led:\n\n  https://etherpad.openstack.org/p/grizzly-nova-config-options\n\nMy thinking was we first move config options into groups to make it\neasier for operators to make sense of the available options and then we\nwould classify them (as e.g. \"tuning\", \"experimental\", \"debug\") and\nexclude some classifications from the sample config file.\n\nSadly, I never even made good progress on \"Tedious Task 2 :: Group\".\n\nMark.\n\n\n\n','<CAHXdxOfuUQigsx9ELirtCF8M9JNN6GWdr_Ct0Nz3Sy-pynOq_g@mail.gmail.com>',NULL),('<1389363790-sup-2841@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-10 07:33:31',-25200,'2014-01-10 14:33:31',NULL,'[openstack-dev] [oslo.config] Centralized config management','Excerpts from Doug Hellmann\'s message of 2014-01-09 12:21:05 -0700:\n> On Thu, Jan 9, 2014 at 1:53 PM, Nachi Ueno <nachi at ntti3.com> wrote:\n> \n> > Hi folks\n> >\n> > Thank you for your input.\n> >\n> > The key difference from external configuration system (Chef, puppet\n> > etc) is integration with\n> > openstack services.\n> > There are cases a process should know the config value in the other hosts.\n> > If we could have centralized config storage api, we can solve this issue.\n> >\n> > One example of such case is neuron + nova vif parameter configuration\n> > regarding to security group.\n> > The workflow is something like this.\n> >\n> > nova asks vif configuration information for neutron server.\n> > Neutron server ask configuration in neutron l2-agent on the same host\n> > of nova-compute.\n> >\n> \n> That extra round trip does sound like a potential performance bottleneck,\n> but sharing the configuration data directly is not the right solution. If\n> the configuration setting names are shared, they become part of the\n> integration API between the two services. Nova should ask neutron how to\n> connect the VIF, and it shouldn\'t care how neutron decides to answer that\n> question. The configuration setting is an implementation detail of neutron\n> that shouldn\'t be exposed directly to nova.\n> \n\nThat is where I think my resistance to such a change starts. If Nova and\nNeutron need to share a value, they should just do that via their API\'s.\nThere is no need for a config server in the middle. If it is networking\nrelated, it lives in Neutron\'s configs, and if it is compute related,\nNova\'s configs.\n\nIs there any example where values need to be in sync but are not\nsharable via normal API chatter?\n\n> Running a configuration service also introduces what could be a single\n> point of failure for all of the other distributed services in OpenStack. An\n> out-of-band tool like chef or puppet doesn\'t result in the same sort of\n> situation, because the tool does not have to be online in order for the\n> cloud to be online.\n> \n\nConfiguration shouldn\'t ever have a rapid pattern of change, so even if\nthis service existed I\'d suggest that it would be used just like current\nconfig management solutions: scrape values out, write to config files.\n\n\n','<CADb+p3QQfw6u3THN4WqHWsyc91_X4SZNSNH3WN1zUv-pm9Y+-Q@mail.gmail.com>',NULL),('<1389387653.23412.47.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-10 16:00:53',-18000,'2014-01-10 21:00:53',NULL,'[openstack-dev] [Neutron] Partially Shared Networks','On Fri, 2014-01-10 at 17:06 +0000, CARVER, PAUL wrote:\n> If anyone is giving any thought to networks that are available to\n> multiple tenants (controlled by a configurable list of tenants) but\n> not visible to all tenants I?d like to hear about it.\n> \n> I?m especially thinking of scenarios where specific networks exist\n> outside of OpenStack and have specific purposes and rules for who can\n> deploy servers on them. We?d like to enable the use of OpenStack to\n> deploy to these sorts of networks but we can?t do that with the\n> current ?shared or not shared? binary choice. \n\nHi Paul :) Please see here:\n\nhttps://www.mail-archive.com/openstack-dev at lists.openstack.org/msg07268.html\n\nfor a similar discussion.\n\nbest,\n-jay\n\n\n\n\n','<A81F249089B6C7479786834457908C600ABFBFCA@MISOUT7MSGUSR9L.ITServices.sbc.com>',NULL),('<1389393315.673412477@emailsrvr.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-10 16:35:15',-21600,'2014-01-10 22:35:15',NULL,'[openstack-tc] Paris Design Summit Scheduling','\n \n \nOn Friday, January 10, 2014 10:12am, \"Russell Bryant\" <rbryant at redhat.com> said:\n\n\n\n> On 01/10/2014 05:34 AM, Mark McLoughlin wrote:\n> > On Thu, 2014-01-09 at 14:52 -0600, Lauren Sell wrote:\n> >>\n> >> We need to make a decision for the Paris design summit pretty quickly.\n> >> The Summit will take place the week of November 3 at the Palais des\n> >> Congres, and we?re planning to host the design sessions directly\n> >> across the street in the Le Meridien. We?ll run the keynote, expo\n> and\n> >> breakout sessions Monday - Wednesday (three, rather than four days),\n> >> and we have the option to run the design sessions either Tuesday -\n> >> Friday or Wednesday - Saturday.\n> >\n> > Like Thierry, I see benefits and downsides to both options.\n> >\n> > What I think is most important is that we try something different from\n> > Atlanta to get another data point.\n> >\n> > However, both options will be something new - in Atlanta, we only have 1\n> > non-overlapping day and 3 overlapping days. The choice for Paris is 2\n> > non-overlapping and 2 overlapping days vs 3 non-overlapping and 1\n> > overlapping.\n> >\n> > I think I\'d prefer to try the more different option - Wednesday to\n> > Saturday.\n> >\n> > Perhaps we could also try to mix things up a little bit on the Saturday.\n> > For example, we could have more smaller rooms (assuming the logistics\n> > allows for easy splitting of rooms) set up in boardroom style and some\n> > sort of on-the-day scheduling mechanism. This would allow us to have a\n> > bunch of smaller group discussions to wrap up some of the open questions\n> > from sessions during the week.\n> >\n> > That\'s just a random idea on the format change - my thinking is that the\n> > final day on a Saturday would naturally have a different feel anyway, so\n> > if we embrace that we could avoid some of the fatigue.\n> \n> I was pretty torn at first (like most others) but am liking this view\n> the most so far (try the more different option, and explore ideas to\n> help reduce the fatigue impact).\n \nI do to...  I say we go for the more differentiated option and see how it goes.  Having ATCs in more sessions earlier int he week, when there aren\'t conflicts, will be a really positive thing IMHO.\n \n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140110/8bb47f31/attachment.html>\n\n','<52D01BD4.5000302@redhat.com>',NULL),('<1389407841-sup-8495@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-10 19:38:48',-25200,'2014-01-11 02:38:48',NULL,'[openstack-dev] [oslo.config] Centralized config management','Excerpts from Nachi Ueno\'s message of 2014-01-10 13:42:30 -0700:\n> Hi Flavio, Clint\n> \n> I agree with you guys.\n> sorry, may be, I wasn\'t clear. My opinion is to remove every\n> configuration in the node,\n> and every configuration should be done by API from central resource\n> manager. (nova-api or neturon server etc).\n> \n> This is how to add new hosts, in cloudstack, vcenter, and openstack.\n> \n> Cloudstack: \"Go to web UI, add Host/ID/PW\".\n> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html\n> \n> vCenter: \"Go to vsphere client, Host/ID/PW\".\n> https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html\n> \n> Openstack,\n> - Manual\n>    - setup mysql connection config, rabbitmq/qpid connection config,\n> keystone config,, neturon config, xxxx\n> http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html\n> \n> We have some deployment system including chef / puppet / packstack, TripleO\n> - Chef/Puppet\n>    Setup chef node\n>    Add node/ apply role\n> - Packstack\n>    -  Generate answer file\n>       https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html\n>    -  packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2\n> - TripleO\n>    - UnderCloud\n>        nova baremetal node add\n>    - OverCloud\n>        modify heat template\n> \n> For residence in this mailing list, Chef/Puppet or third party tool is\n> easy to use.\n> However,  I believe they are magical tools to use for many operators.\n> Furthermore, these development system tend to take time to support\n> newest release.\n> so most of users, OpenStack release didn\'t means it can be usable for them.\n> \n> IMO, current way to manage configuration is the cause of this issue.\n> If we manage everything via API, we can manage cluster by horizon.\n> Then user can do \"go to horizon, just add host\".\n> \n> It may take time to migrate config to API, so one easy step is to convert\n> existing config for API resources. This is the purpose of this proposal.\n> \n\nHi Nachi. What you\'ve described is the vision for TripleO and Tuskar. We\ndo not lag the release. We run CD and will be in the gate \"real soon\nnow\" so that TripleO should be able to fully deploy Icehouse on Icehouse\nrelease day.\n\n\n','<CABJepwjtjPtS8FXBK_eULCaTAsv8dG72mKVzfTcWmhSthkWDOg@mail.gmail.com>',NULL),('<1389429087.11262.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-11 16:31:27',28800,'2014-01-11 08:31:27',NULL,'[Openstack] research area in object storage','hello vishesh\n\nthanks for suggestion.\nactually, I need to see four or five open source object storage.\nplease suggest me some more names\n\nthanks again\npragya jain\n\n\n\nOn Friday, 10 January 2014 7:48 PM, Vishesh kumar <linuxtovishesh at gmail.com> wrote:\n \nPragya,\n>\n>You can also have a look on CEPH \n>\n>\n>\n>On Wed, Jan 8, 2014 at 2:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>Hi all,?\n>>\n>>\n>>I am a Ph.D student, department of computer science, delhi university, Delhi, India\n>>\n>>\n>>I am working object storage as a service in cloud.\n>>I had studied the features provided by Amazon S3, Window Azure Blob Storage, EMC Atmos, Openstack Swift and Eucalyptus Walrus.\n>>I had studied Openstack Swift in detail like its documentation, whole source code etc.\n>>I had also installed it to make a feel of it.\n>>I am also going through software defined storage concept theoratically.\n>>\n>>\n>>Can somebody help me in suggesting some research area in which I can complete my thesis.\n>>\n>>\n>>Thanks in advance?\n>>Pragya Jain\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>-- \n>\n>Regards,\n>Vishesh Kumar\n>http://linuxmantra.com\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140111/1822456d/attachment.html>\n\n','<CAKpaJ1yACDKmmvpAz3sbJckr7bXhwq2trbCs+BEJZCtfTxh11g@mail.gmail.com>',NULL),('<1389469604.23412.80.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-11 14:46:44',-18000,'2014-01-11 19:46:44',NULL,'[Openstack] [Keystone] performance issues after havana upgrade','Hi Jonathan! I have not yet deployed Havana to production, however I\'ll\nadd some comments and suggestions below that you may want to try in\norder to isolate root cause...\n\nOn Sat, 2014-01-11 at 13:34 -0500, Jonathan Proulx wrote:\n> Hi All,\n> \n> recently upgraded my 1 controller 60 compute node Ubuntu 12.04(+cloud\n> archive) system from Grizlzy to Havana.  Now even before I let my\n> users back to the API I\'m barely able to do anything due to\n> authentication time outs.  I am using neutron which like to\n> authenticate *a lot*, I\'m not entierly convinced the real problem\n> isn\'t neutron reauthenticating a bajillion services a second, but\n> right now it looks like Keystone...\n> \n> I\'m using UUID Tokens with memcached backend.\n\nTwo requests:\n\n1) Could you paste your keystone.conf pls? I\'m curious, particularly,\nwhat backend you are using for the catalog driver and the identity\ndriver.\n\n2) How are you configuring memcache? Please let us know if you\'ve given\nmemcache a decent amount of memory to support the token cache. I\nbelieve, IIRC, our memcache-per-controller was 2GB, but we may have\nincreased that to 4GB... can\'t remember. In any case, it should be a\ndecent amount of memory if you have lots of token validation and/or\nrevocation calls happening.\n\nDo a little bit of memcache performance investigation for us, as well.\nIt will tell us if memcache is having trouble keeping up with constant\ncache flushing...\n\nIf you telnet to the memcached instance:\n\ntelnet <HOST> 11211\n\nand then type \"stats\" a few times in a minute. Keep an eye on the number\nreturned for \"evictions\". If that number increases substantially over\nthe time you do this mini-profile, it\'s an indication that memcached is\nhaving a tough time keeping up with the rate of cache insertions, and is\nlooking for least-used blocks to evict in order to find room to put new\nblocks in. This can sometimes be an indication you need to increase the\namount of memory for memcached.\n\n> Under Grizzly I had been using Peter Feiner\'s multi worker patches,\n> though this was only needed for peak loads (when starting 100\'s of\n> instances).  With just background noise of the running compute-nodes\n> (60) and instances (281) in default single worker (eventlet) mode\n> keystone runs at 100% and many client requests (from dash board or\n> CLI) time out.  Nova-compute nodes also frequently log timeouts when\n> trying to authenticate to the neutron service.\n> \n> Verbose keystone logs show very little activity even when running 100%\n> load, just a few \"INFO acceess\" type entries every few *minutes*.\n> Debug logging show many sqlalchemy actions per second for the neutron\n> user id and admin tenant id.\n\nOK, so clearly Keystone is configured to use the sql driver for at least\n*something*... likely the identity and/or catalog driver.\n\nIf you are using the sql driver for the catalog, I would highly advise\nswitching to the templated catalog driver. It\'s essentially a static\nfile that is cached by the driver and used as a string interpolation\ntemplate for the service catalog (used on EVERY single request for a new\ntoken, since the token includes the service catalog attached to the\ndomain/project/user).\n\n> I took the next obvious step and put keystone behind apache, while\n> that does get more servers running, performance if anything is even\n> worse while using virtually all of the 12 core controller node\'s CPUs\n> rather than just one of them.\n> \n> The logs quickly fill with data read timeouts:\n> \n> 2014-01-11 12:31:26.606 3054 INFO access [-] 192.168.128.43 - -\n> [11/Jan/2014:17:31:26 +0000] \"POST\n> http://192.168.128.15:35357/v2.0/tokens HTTP/1.1\" 500 167\n> 2014-01-11 12:31:26.621 3054 ERROR keystone.common.wsgi [-] request\n> data read error\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi Traceback\n> (most recent call last):\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py\", line 371,\n> in __call__\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi     response =\n> self.process_request(request)\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/keystone/middleware/core.py\", line\n> 110, in process_request\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi\n> params_json = request.body\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/webob/request.py\", line 677, in\n> _body__get\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi\n> self.make_body_seekable() # we need this to have content_length\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/webob/request.py\", line 922, in\n> make_body_seekable\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi     self.copy_body()\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/webob/request.py\", line 945, in\n> copy_body\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi     self.body\n> = self.body_file.read(self.content_length)\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi   File\n> \"/usr/lib/python2.7/dist-packages/webob/request.py\", line 1521, in\n> readinto\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi     data =\n> self.file.read(sz0)\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi IOError:\n> request data read error\n> 2014-01-11 12:31:26.621 3054 TRACE keystone.common.wsgi\n> \n> I\'ve played around with different process and tread count numbers in\n> the WSGIDaemonProcess apache directive, but while some seem make it\n> worse none have made it better.\n\nHmm. The traceback above really doesn\'t seem to indict either the token\nnor the catalog backend -- as the IOError is indicating that there is an\nissue in *reading the incoming WSGI request body* :(\n\nThat request body is being constructed clearly by one of the\npython-xxxclients -- probably python-neutronclient -- so perhaps it is\nworth doing some python-neutronclient CLI calls using --debug to see if\nyou can get an idea on why on Earth webob.Request is having problems\nconstructing a request body from the client call. Very odd indeed.\n\nBest,\n-jay\n\n> Clearly I must be doing something wrong since the single process\n> eventlet mode has significantly better performance than the\n> multiprocess wsgi mode.\n> \n> I\'ve also fiddled a bit with the dogpile cache settings, when running\n> a single stand alone process the \'memory\' backend seemed to make\n> things actually go, though after getting the pylibmc backend setup (or\n> I think setup there could well be more I\'m misisng), which didn\'t make\n> a noticible difference, I wasn\'t able to revert to the \'success\' or\n> the memory backend though for obvious reasons I wouldn\'t have wanted\n> to keep that one in production anyway.\n> \n> How can I either make Keystone go faster or Neutron authenticate less?\n> \n> -Jon\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<CABZB-sgAGAjKdJDCp6qE20WKqs0Kh8AyfEiEi-2N_e4Uc+wT9A@mail.gmail.com>',NULL),('<1389555641.23412.95.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-12 14:40:41',-18000,'2014-01-12 19:40:41',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:\n> >> So, it\'s not as simple as it may initially seem :)\n> >\n> > Ah, I should have been clearer in my statement - my understanding is that\n> > we\'re scrapping concepts like Rack entirely.\n> \n> That was my understanding as well. The existing Tuskar domain model was \n> largely placeholder/proof of concept and didn\'t necessarily reflect \n> exactly what was desired/expected.\n\nHmm, so this is a bit disappointing, though I may be less disappointed\nif I knew that Ironic (or something else?) planned to account for\ndatacenter inventory in a more robust way than is currently modeled.\n\nIf Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling\nthat an enterprise would use to deploy bare-metal hardware in a\ncontinuous fashion, then the modeling of racks, and the attributes of\nthose racks -- location, power supply, etc -- are a critical part of the\noverall picture.\n\nAs an example of why something like power supply is important... inside\nAT&T, we had both 8kW and 16kW power supplies in our datacenters. For a\n42U or 44U rack, deployments would be limited to a certain number of\ncompute nodes, based on that power supply.\n\nThe average power draw for a particular vendor model of compute worker\nwould be used in determining the level of compute node packing that\ncould occur for that rack type within a particular datacenter. This was\na fundamental part of datacenter deployment and planning. If the tooling\nintended to do bare-metal deployment of OpenStack in a continual manner\ndoes not plan to account for these kinds of things, then the chances\nthat tooling will be used in enterprise deployments is diminished.\n\nAnd, as we all know, when something isn\'t used, it withers. That\'s the\nlast thing I want to happen here. I want all of this to be the\nbare-metal deployment tooling that is used *by default* in enterprise\nOpenStack deployments, because the tooling \"fits\" the expectations of\ndatacenter deployers.\n\nIt doesn\'t have to be done tomorrow :) It just needs to be on the map\nsomewhere. I\'m not sure if Ironic is the place to put this kind of\nmodeling -- I thought Tuskar was going to be that thing. But really,\nIMO, it should be on the roadmap somewhere.\n\nAll the best,\n-jay\n\n\n\n','<52D0119C.7050205@redhat.com>',NULL),('<1389560978.23412.104.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-12 16:09:38',-18000,'2014-01-12 21:09:38',NULL,'[openstack-dev] [ ceilometer] The Pagination patches','On Fri, 2014-01-10 at 03:31 +0000, Gao, Fengqian wrote:\n> Since we still have no new conclusion for pagination for now, shall we\n> still go on with the current pagination solution?\n> \n> Please help to review patches:\n> \n> https://review.openstack.org/#/c/41869/\n> https://review.openstack.org/#/c/35454/\n\nHi Fengqian,\n\nPlease see my review on the first of the above patches. You need to\nensure that there is at least one unique column in the sort keys if\npagination is used.\n\nThere is a similar issue in the second patch (reviewing it now) that\nuses the sqlalchemy_utils (oslo.db) paginate_query() method...\n\nThe sqlalchemy_utils.paginate_query() method **requires** that sort_keys\ncontains a unique column [1]. The docstring for that method says:\n\n\"Pagination works by requiring a unique sort_key, specified by\nsort_keys. (If sort_keys is not unique, then we risk looping through\nvalues.)\"\n\nSo, care must be taken to pass sort_keys parameter to paginate_query()\nthat already contains at least one unique column in the sort keys.\n\nBest,\n-jay\n\n[1]\nhttps://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L66\n\n\n\n\n','<2B1FAA7A105B4A4D8AE1ED8CE67ABE61019447D8@SHSMSX101.ccr.corp.intel.com>',NULL),('<1389564839.23412.117.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-12 17:13:59',-18000,'2014-01-12 22:13:59',NULL,'[openstack-dev] [Ceilometer] Aggregation discussion','On Fri, 2014-01-10 at 17:10 +0400, Nadya Privalova wrote:\n> Idea:\n> The goal is to improve performance when user gets statistics for\n> meter. Now we have fixed list of statistics (min, max and so on).\n> During request a user may specify the following params:\n> 1. query\n> 2. group_by\n> 3. period\n> \n> The idea of bp is to pre-calculate some kind of requests and store\n> them to a separate table in database.\n\nPre-calculate when? :) During processing of samples, or during some\nperiodic job?\n\n> The pre-calculated statistics is called aggregates.\n\nThe term \"aggregate\" really just means a generic grouping or\nsummarization. If you are looking for a term that represents the\nrules/heuristics for maintaining rolling calculations, perhaps the term\n\"report\" is better?\n\n> Aggregates may be merged among each others and with any Statistics\'\n> objects. \n> Note, that aggregates will be transparent for users. No changes in api\n> is required during get_statistics.\n> \n> Example:\n> Let\'s assume we have 6 Samples about \'image\' meter. All of them belong\n> to one day (e.g. 1st May) but have happened in different times:\n> 11.50, 12.25, 12.50, 13.25, 13.50 and 14.25.  User would like to get\n> statistics about this meter from start = 11.30 till end = 14.30. So we\n> need to process all samples. \n> But we may process these samples earlier and already have\n> pre-calculated results for full hour 12.00 and 13.00. In this case we\n> may get  Sample 11.50 and 14.25 from \"meters\" table and merge\n> statistics for them with already calculated Statistic result from\n> \"aggregates\" table.\n> This example \"saved\" only 2 reads from DB. But if we consider metrics\n> from pollsters with interval = 5 sec (720 Samples per hour) we will\n> save 719 reads with aggregate usage.\n\nHmm. So, aggregation and grouping are the domain of data warehousing and\nOLAP Servers. I don\'t believe that putting this functionality directly\nin to Ceilometer is a good idea. I believe it would be better to\ndelegate this kind of functionality to well-known and used tools like\nPentaho [1], which can use a variety of different backend storage\nsystems.\n\nBottom line, I believe Ceilometer should focus strictly on the\ncollection of samples/alarms, the pre-processing of those things, and\nthe storage of those things, however I do not believe that Ceilometer\nshould become an OLAP analytics tool when existing ones already fill\nthat need.\n\nBest,\n-jay\n\n[1] http://www.pentaho.com/5.0 &\nhttp://en.wikipedia.org/wiki/Mondrian_OLAP_server\n\n\n\n\n','<CAKWrcJe2t-DMjyWd2aV-+Y2ZgL9+V+-PPp=TJGy8Gg+Nj5xfPw@mail.gmail.com>',NULL),('<1389569173-sup-8898@clint-HP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-12 15:27:37',-28800,'2014-01-12 23:27:37',NULL,'[openstack-dev] [gantt[ Patches to sync gantt up to the current\n	nova tree','Excerpts from Doug Hellmann\'s message of 2014-01-12 14:45:11 -0800:\n> On Sun, Jan 12, 2014 at 5:30 PM, Dugger, Donald D <donald.d.dugger at intel.com\n> > wrote:\n> \n> >  So I have 25 patches that I need to push to backport changes that have\n> > been made to the nova tree that apply to the gantt tree.  The problem is\n> > how do we want to approve these patches?  Given that they have already been\n> > reviewed and approved in the nova tree do we have to go through the\n> > overhead of doing new reviews in the gantt tree and, if not, how do we\n> > bypass that mechanism?\n> >\n> \n> Why is code being copied from nova directly?\n> \n\nI suspect because gantt forked a while ago, but development has been\nallowed to continue in nova\'s scheduler code. Seems like that should be\nstopped at some point soon to reduce the extra sync effort.\n\n\n','<CADb+p3RnT2skzZ9MA1ft-J0d2CA0uU2vg_Pq2VGcPP67KbVgLA@mail.gmail.com>',NULL),('<1389569639.3061.19.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 09:33:59',36000,'2014-01-12 23:33:59',NULL,'[openstack-dev] [wsme] Undefined attributes in WSME','On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:\n> \n> \n> \n> \n> On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox <jamielennox at redhat.com>\n> wrote:\n>         Is there any way to have WSME pass through arbitrary\n>         attributes to the created object? There is nothing that i can\n>         see in the documentation or code that would seem to support\n>         this.\n>         \n>         In keystone we have the situation where arbitrary data was\n>         able to be attached to our resources. For example there are a\n>         certain number of predefined attributes for a user including\n>         name, email but if you want to include an address you just add\n>         an \'address\': \'value\' to the resource creation and it will be\n>         saved and returned to you when you request the resource.\n>         \n>         Ignoring whether this is a good idea or not (it\'s done), is\n>         the option there that i missed - or is there any plans/way to\n>         support something like this?\n> \n> \n> There\'s a change in WSME trunk (I don\'t think we\'ve released it yet)\n> that allows the schema for a type to be changed after the class is\n> defined. There isn\'t any facility for allowing the caller to pass\n> arbitrary data, though. Part of the point of WSME is to define the\n> inputs and outputs of the API for validation.\n> \n> \n> How are the arbitrary values being stored in keystone? What sorts of\n> things can be done with them? Can an API caller query them, for\n> example?\n> \n> \n> Doug\n\nSo you can\'t query based on these arbitrary values but they are there as\npart of the resource. We have generic middleware that interprets the\nincoming json or xml to python dictionaries. Then we extract the\nqueryable information for storing into database cells. In the case of\nUser these are: id, name, password, enabled, domain_id,\ndefault_project_id. Everything else in the dictionary is stored in an\n\'extra\' column in the database as a JSON dictionary. When we reconstruct\nthe User object we recreate the extra dictionary and update it with the\nknown attributes. \n\nSo there is no restriction on types or depth of objects, and whilst you\ncan\'t query from those attributes they will always be present if you get\nor list the user. \n\nNote that User is probably a bad example in this because of LDAP and\nother backends but the idea is the same for all keystone resources.\n\n\nSo I don\'t think that changing the WSME type after definition is useful\nin this case. Is it the sort of thing that would be possible or accepted\nto add to WSME?\n\n>From the little bit of looking i\'ve done it appears that WSME loops over\nthe defined attributes of the class and extracts those from the message\nrather than looping over keys in the message which makes this more\ndifficult. Can WSME be made to decode all values in a purely python\nprimative way (eg don\'t decode dates, objects etc, just give python\ndictionaries like from a json.loads)?\n\nI would prefer not to have keystone using yet another framework from the\nrest of openstack, but should i just be looking to use jsonschema or\nsomething instead?\n\nJamie \n\n> \n>  \n>         \n>         Thanks,\n>         \n>         Jamie\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CADb+p3RU1K-5hgtY981zE6ZkLswSd6nVbyu3C4hh6qSJJfC-EQ@mail.gmail.com>',NULL),('<1389585165707.9845766b@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-12 19:52:46',-28800,'2014-01-13 03:52:46',NULL,'[openstack-dev] [nova] api schema validation pattern changes','On my phone so will be very brief but perhaps the extensions extension could publish the jsonschema(s) for the extension. I think the only complicating ?factor would be where extensions extend extensions but I think it\'s all doable.\n\n\n\n\nChris\n\n?\nSent from Mailbox for iPhone\n\nOn Mon, Jan 13, 2014 at 1:49 PM, Matthew Treinish <mtreinish at kortar.org>\nwrote:\n\n> <snip>\n>> > Last, is a question, is it possible to currently run the full API an build a\n>> > json schema for it all? Or to query these validating schemas? We *really*\n>> > want that over in tempest, so we can completely drop the manual creation of\n>> > negative testing, and just fuzz known bad against the schema definitions.\n>> \n>> Sorry, I\'m not sure I understand this question correctly.\n>> We need to define schemas for each API with the separated schema patches.\n>> It is impossible to define one schema for all APIs.\n>> \n>> \n>> Hi  David, Marc,\n>> \n>> I guess the negative test generator of Tempest would need each API definition.\n>> Glance can provide API definitions through API with jsonschema format, but\n>> Nova does not have such feature.\n>> We need to port these API schema from Nova to Tempest, I guess. right?\n>> \n> As I understand things after reviewing the first versions of the negative test\n> generator patch is that we have to hard code the schema into a file (right now\n> it\'s in the test file, but eventually it\'ll be an external input file). One of\n> my issues with doing that is it\'s highly manual process, essentially a copy and\n> paste from the nova tree. I think what we\'re looking for from this jsonschema\n> validation work is an API which we can query the API and get the jsonschema\n> definitions; similar to what the glance API offers.\n> I wouldn\'t advocate making the negative test generator be fully dynamic for the\n> same reason we don\'t autodetect which API versions and extensions/features are\n> enabled in tempest, but rather rely on the config file. But, instead have an\n> additional tool which could query the schema for all the endpoints in nova and\n> generate an input file for the negative test generator. That way we\'ll still\n> catch breaking API changes in the gate, but it\'s not a manual process to update\n> the input file with the schema definitions in tempest when there is a breaking\n> API change. (Which hopefully should almost never happen)\n> -Matt Treinish\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140112/ec1a9bca/attachment.html>\n\n','<20140113031426.GA2681@kortar.treinish>',NULL),('<1389608163.3.1374992789520.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-28 06:26:29',0,'2013-07-28 06:26:29',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #48','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/48/>\n\n------------------------------------------\n[...truncated 22450 lines...]\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 960bd2a4-e55a-4031-904f-1898fb6a60df |\n| id       | 31a9f185-6aed-4102-aca8-e378660f1986 |\n| volumeId | 31a9f185-6aed-4102-aca8-e378660f1986 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-540ff428 | grep in-use; do sleep 1; done\'\n| 31a9f185-6aed-4102-aca8-e378660f1986 | in-use | ex-vol-540ff428 |  1   |     None    |  False   | 960bd2a4-e55a-4031-904f-1898fb6a60df |\n++ date +%s\n+ end_time=1374991849\n+ echo \'Completed volume-attach in 3 seconds\'\nCompleted volume-attach in 3 seconds\n++ cinder list\n++ grep ex-vol-540ff428\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ echo \'| 31a9f185-6aed-4102-aca8-e378660f1986 | in-use | ex-vol-540ff428 |  1   |     None    |  False   | 960bd2a4-e55a-4031-904f-1898fb6a60df |\'\n++ read data\n+ VOL_ATTACH=960bd2a4-e55a-4031-904f-1898fb6a60df\n+ die_if_not_set 172 VOL_ATTACH \'Failure retrieving ex-vol-540ff428 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 960bd2a4-e55a-4031-904f-1898fb6a60df != 960bd2a4-e55a-4031-904f-1898fb6a60df ]]\n++ date +%s\n+ start_time=1374991850\n+ nova volume-detach 960bd2a4-e55a-4031-904f-1898fb6a60df 31a9f185-6aed-4102-aca8-e378660f1986\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-540ff428 | grep available; do sleep 1; done\'\n| 31a9f185-6aed-4102-aca8-e378660f1986 | available | ex-vol-540ff428 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1374991853\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1374991853\n+ cinder delete 31a9f185-6aed-4102-aca8-e378660f1986\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-540ff428; do sleep 1; done\'\n| 31a9f185-6aed-4102-aca8-e378660f1986 | deleting | ex-vol-540ff428 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1374991855\n+ echo \'Completed cinder delete in 2 seconds\'\nCompleted cinder delete in 2 seconds\n+ nova delete 960bd2a4-e55a-4031-904f-1898fb6a60df\n+ timeout 60 sh -c \'while nova list | grep -q 960bd2a4-e55a-4031-904f-1898fb6a60df; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1436.g7f5e65b.zip\nall runtests: commands[0] | python setup.py testr --slowest\nrunning testr\nNo handlers could be found for logger \"tempest.api.compute.base\"\nNo handlers could be found for logger \"tempest.cli.output_parser\"\nNo handlers could be found for logger \"tempest.cli\"\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpt04rFA\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpHpfz43\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpmcWT1U\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpbpv8Vq\n======================================================================\nFAIL: tempest.api.compute.admin.test_aggregates.AggregatesAdminTestXML.test_aggregate_add_host_create_server_with_az[gate]\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/admin/test_aggregates.py\", line 213, in test_aggregate_add_host_create_server_with_az\n    availability_zone=az_name)\n  File \"tempest/api/compute/base.py\", line 123, in create_server\n    name, image_id, flavor, **kwargs)\n  File \"tempest/services/compute/xml/servers_client.py\", line 304, in create_server\n    resp, body = self.post(\'servers\', str(Document(server)), self.headers)\n  File \"tempest/common/rest_client.py\", line 258, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 386, in request\n    resp, resp_body)\n  File \"tempest/common/rest_client.py\", line 436, in _error_checker\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {\'message\': \'The requested availability zone is not available\', \'code\': \'400\'}\n======================================================================\nFAIL: tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_create_server_with_az[gate]\ntags: worker-2\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/admin/test_aggregates.py\", line 213, in test_aggregate_add_host_create_server_with_az\n    availability_zone=az_name)\n  File \"tempest/api/compute/base.py\", line 123, in create_server\n    name, image_id, flavor, **kwargs)\n  File \"tempest/services/compute/json/servers_client.py\", line 81, in create_server\n    resp, body = self.post(\'servers\', post_body, self.headers)\n  File \"tempest/common/rest_client.py\", line 258, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 386, in request\n    resp, resp_body)\n  File \"tempest/common/rest_client.py\", line 436, in _error_checker\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'The requested availability zone is not available\', u\'code\': 400}}\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 133, in test_snapshot_pattern\n    self._create_security_group_rule()\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 84, in _create_security_group_rule\n    **ruleset)\n  File \"/opt/stack/new/python-novaclient/novaclient/v1_1/security_group_rules.py\", line 69, in create\n    \'security_group_rule\')\n  File \"/opt/stack/new/python-novaclient/novaclient/base.py\", line 141, in _create\n    _resp, body = self.api.client.post(url, body=body)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 232, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 213, in _cs_request\n    **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 195, in _time_request\n    resp, body = self.request(url, method, **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 189, in request\n    raise exceptions.from_response(resp, body, url, method)\nBadRequest: This rule already exists in group 1 (HTTP 400) (Request-ID: req-70e1b005-4d41-4a80-b7a7-28ee5f38fbfa)\n======================================================================\nFAIL: tempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/scenario/test_stamp_pattern.py\", line 203, in test_stamp_pattern\n    self._create_security_group_rule()\n  File \"tempest/scenario/test_stamp_pattern.py\", line 106, in _create_security_group_rule\n    **ruleset)\n  File \"/opt/stack/new/python-novaclient/novaclient/v1_1/security_group_rules.py\", line 69, in create\n    \'security_group_rule\')\n  File \"/opt/stack/new/python-novaclient/novaclient/base.py\", line 141, in _create\n    _resp, body = self.api.client.post(url, body=body)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 232, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 213, in _cs_request\n    **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 195, in _time_request\n    resp, body = self.request(url, method, **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 189, in request\n    raise exceptions.from_response(resp, body, url, method)\nBadRequest: This rule already exists in group 1 (HTTP 400) (Request-ID: req-2b3dedce-6650-4aa9-abbb-f299f14086d5)\n======================================================================\nFAIL: process-returncode\ntags: worker-0\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2374 tests in 873.418s\nFAILED (id=0, failures=6, skips=63)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/rabbitmq/rabbit at devstack-1374978670-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/rabbitmq/rabbit at devstack-1374978670.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/48/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1960154999.68.1374906550271.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1389617518.34263.YahooMailNeo@web173005.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 12:51:58',0,'2014-01-13 12:51:58',NULL,'[Openstack] Apparmor profile for dnsmasq','Hi all,\n\nwould you please share a valid Apparmor profile for dnsmasq (Ubuntu), if you have one, or a good reference about this topic in openStack?\n\n\nI tried to use the default profile provided by Canonical, but it still complains with some DENIED on Neutron node (Grizzly 2013.1.2), for examples:\n\nJan 13 06:25:19 neutron1 kernel: [2301400.755895] type=1400 audit(1389594319.479:124798688): apparmor=\"DENIED\" operation=\"open\" parent=19108 profile=\"/usr/sbin/dnsmasq\" name=\"/proc\n/9463/mounts\" pid=9463 comm=\"python\" requested_mask=\"r\" denied_mask=\"r\" fsuid=0 ouid=0\n\nJan 13 06:25:19 neutron1 kernel: [2301400.757665] type=1400 audit(1389594319.483:124798689): apparmor=\"DENIED\" operation=\"exec\" parent=9473 profile=\"/usr/sbin/dnsmasq\" name=\"/sbin/\nldconfig\" pid=9476 comm=\"sh\" requested_mask=\"x\" denied_mask=\"x\" fsuid=0 ouid=0\n\nJan 13 06:25:19 neutron1 kernel: [2301400.758668] type=1400 audit(1389594319.483:124798693): apparmor=\"DENIED\" operation=\"mknod\" parent=19108 profile=\"/usr/sbin/dnsmasq\" name=\"/tmp/RI6kSv\" pid=9463 comm=\"python\" requested_mask=\"c\" denied_mask=\"c\" fsuid=0 ouid=0\n\nJan 13 06:25:19 neutron1 kernel: [2301400.758737] type=1400 audit(1389594319.483:124798694): apparmor=\"DENIED\" operation=\"mknod\" parent=19108 profile=\"/usr/sbin/dnsmasq\" name=\"/var/tmp/bXIlha\" pid=9463 comm=\"python\" requested_mask=\"c\" denied_mask=\"c\" fsuid=0 ouid=0\n\nJan 13 06:25:19 neutron1 kernel: [2301400.758809] type=1400 audit(1389594319.483:124798695): apparmor=\"DENIED\" operation=\"mknod\" parent=19108 profile=\"/usr/sbin/dnsmasq\" name=\"/lens9X\" pid=9463 comm=\"python\" requested_mask=\"c\" denied_mask=\"c\" fsuid=0 ouid=0\n\nJan 13 06:25:19 neutron1 kernel: [2301400.758995] type=1400 audit(1389594319.483:124798696): apparmor=\"DENIED\" operation=\"mknod\" parent=11094 profile=\"/usr/sbin/dnsmasq\" name=\"/tmp/0XF3vE\" pid=9462 comm=\"python\" requested_mask=\"c\" denied_mask=\"c\" fsuid=0 ouid=0\n\nMany thanks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140113/b78f24ee/attachment.html>\n\n',NULL,NULL),('<1389618317.62278.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 13:05:17',0,'2014-01-13 13:05:17',NULL,'[Openstack] [Neutron] setup metadata proxy in Havana','Hi Jon,\n\nthe RST is probably because the curl request was to port 8775. Can you try again to port 80 and also use -n with tcpdump.? \n\nI was able to get metadata from the DHCP namespace proxy on a provider network with an external router working by pushing out a static route to 169.154.169.254 with DHCP. There are more details and a workarounds here https://bugs.launchpad.net/neutron/+bug/1236783? - Note I did not use enable_metadata_network.\n\nRegards,\nDarragh.\n\n>I\'m very near to having metadata service working in Havana I think,\n>but need a little help.\n>\n>Most of my instances are on a provider network that uses\n>neutron-dhcp-agent but an external router.? I have a single controller\n>setup using Ubuntu 12.04 and cloud archive.\n>\n>It looks like the service is listening in the right namespace on the\n>right linklocal IP.? Instances can ping 169.254.169.254, but http\n>access get and immediate RST\n>\n>What am I missing here?\n>\n>Details follow...\n>\n>Thanks,\n>-Jon\n>\n>configs:\n># grep metadata /etc/neutron/dhcp_agent.ini|grep -v ^#\n>enable_isolated_metadata = True\n>enable_metadata_network = True\n>\n># grep metadata /etc/neutron/metadata_agent.ini|grep -v ^#\n>nova_metadata_ip = 127.0.0.1\n>nova_metadata_port = 8775\n>metadata_proxy_shared_secret=<matching-secret>\n>\n># grep metadata /etc/nova/nova.conf|grep -v ^#\n>enabled_apis=ec2,osapi_compute,metadata\n>metadata_listen=0.0.0.0\n>neutron_metadata_proxy_shared_secret=<matching-secret>\n>service_neutron_metadata_proxy=True\n>\n>observations:\n>The neutron metadata proxy seems to be listening in the namespace of\n>the dhcpagent:\n>\n># ip netns exec qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d? netstat -tlp\n>Active Internet connections (only servers)\n>Proto Recv-Q Send-Q Local Address?????????? Foreign Address\n>State?????? PID/Program name\n>tcp??????? 0????? 0 *:http????????????????? *:*\n>LISTEN????? 6394/python\n>\n>ps 6394\n>? PID TTY????? STAT?? TIME COMMAND\n> 6394 ???????? S????? 5:05 python /usr/bin/quantum-ns-metadata-proxy\n>--pid_file=/var/lib/quantum/external/pids/0a1d0a27-cffa-4de3-92c5-9d\n>\n>And the interface in that namespace has the 169.254.169.254 address:\n>\n># ip netns exec qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d? ip addr\n>17: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN\n>??? link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n>??? inet 127.0.0.1/8 scope host lo\n>??? inet6 ::1/128 scope host\n>?????? valid_lft forever preferred_lft forever\n>1202: tap9bc9680d-2a: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue\n>state UNKNOWN\n>??? link/ether fa:16:3e:f8:df:73 brd ff:ff:ff:ff:ff:ff\n>??? inet 192.168.160.1/18 brd 192.168.191.255 scope global tap9bc9680d-2a\n>??? inet 169.254.169.254/16 brd 169.254.255.255 scope global tap9bc9680d-2a\n>??? inet6 fe80::f816:3eff:fef8:df73/64 scope link\n>\n>tcpdump of attempt to curl metadata from client meets RST:\n>\n>root at nimbus-0:/etc/apache2/conf.d# ip netns exec\n>qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d? tcpdump -i tap9bc9680d-2a\n>host 192.168.160.101\n>\n>16:51:22.445630 IP 160-101.openstack.34986 > 169.254.169.254.8775:\n>Flags [S], seq 2424502061, win 14600, options [mss 1460,sackOK,TS val\n>1316139 ecr 0,nop,wscale 3], length 0\n>16:51:22.445663 IP 169.254.169.254.8775 > 160-101.openstack.34986:\n>Flags [R.], seq 0, ack 2424502062, win 0, length 0\n>\n>2 packets captured\n>2 packets received by filter\n\n\n',NULL,NULL),('<1389622003.61597.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 14:06:43',0,'2014-01-13 14:06:43',NULL,'[Openstack] [Neutron] setup metadata proxy in Havana','\nOn Monday, 13 January 2014, 13:34, Jonathan Proulx <jon at jonproulx.com> wrote:\n\nOn Mon, Jan 13, 2014 at 8:05 AM, Darragh O\'Reilly\n><dara2002-openstack at yahoo.com> wrote:\n>> Hi Jon,\n>>\n>> the RST is probably because the curl request was to port 8775. Can you try again to port 80 and also use -n with tcpdump.\n>\n>Thanks for the extra eyes on that one, been a long weekend and not so\n>much in the good way, I didn\'t mean to be using :8775\n>\n>> I was able to get metadata from the DHCP namespace proxy on a provider network with an external router working by pushing out a static route to 169.154.169.254 with DHCP. There are more details and a workarounds here https://bugs.launchpad.net/neutron/+bug/1236783??- Note I did not use enable_metadata_network.\n>\n>That\'s basicaly what I had working with Grizzly.\n>\n>Now I\'m getting an internal server error because:\n>\n>connect(13, {sa_family=AF_FILE,\n>path=\"/var/lib/quantum/metadata_proxy\"}, 33) = -1 ECONNREFUSED\n>(Connection refused)\n\nhmm - I wonder if your problem is to do with a quantum/neutron naming mixup?\nWas this an upgrade install? Your state_path still seems to be /var/lib/quantum/\n\n\nIs the neutron-metadata-agent listening on /var/lib/neutron/metadata_proxy instead?\n\nlsof | grep metadata_proxy\n\n\n>\n>So I\'m thinking I need to extract some leftover Grizzly-quantum stuff.\n>\n>\n>Thanks,\n>-Jon\n>\n>\n\n\n','<CABZB-shS5OM9T2+_-jnGVRG21gdOpcAPf9CBUdSboToUKPCCgA@mail.gmail.com>',NULL),('<1389623033.4235.2.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 09:23:53',-18000,'2014-01-13 14:23:53',NULL,'[openstack-dev] [nova] api schema validation pattern changes','On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:\n> On my phone so will be very brief but perhaps the extensions extension\n> could publish the jsonschema(s) for the extension. I think the only\n> complicating  factor would be where extensions extend extensions but I\n> think it\'s all doable.\n\nAm I the only one that sees the above statement as another indication of\nwhy API extensions should eventually find their way into the dustbin of\nOpenStack history?\n\n-jay\n\n\n\n\n','<1389585165707.9845766b@Nodemailer>',NULL),('<1389626109.4235.5.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 10:15:09',-18000,'2014-01-13 15:15:09',NULL,'[openstack-dev] [nova] api schema validation pattern changes','On Mon, 2014-01-13 at 09:40 -0500, Ryan Petrello wrote:\n> Jay, I?ll +1 to that.  As I?ve been tinkering with potential Pecan support for the Nova API, I?ve run into the same issue w/ the API composition being seriously complicated (to the point where I?ve realized Pecan isn?t the hard part, it?s the bunch of cruft you need to tie in Pecan/Routes/Falcon/<fill in WSGI framework here>).\n\nIndeed. And don\'t get me wrong... I\'m not at all saying that Chris is to\nblame for anything (or any one person in particular). Just pointing out\nthat, IMO, the usefulness of API extensions is outweighed by the added\ncomplexity and churn that they bring with them.\n\n-jay\n\n> ---\n> Ryan Petrello\n> Senior Developer, DreamHost\n> ryan.petrello at dreamhost.com\n> \n> On Jan 13, 2014, at 9:23 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:\n> >> On my phone so will be very brief but perhaps the extensions extension\n> >> could publish the jsonschema(s) for the extension. I think the only\n> >> complicating  factor would be where extensions extend extensions but I\n> >> think it\'s all doable.\n> > \n> > Am I the only one that sees the above statement as another indication of\n> > why API extensions should eventually find their way into the dustbin of\n> > OpenStack history?\n> > \n> > -jay\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<4E3DB6BB-7D73-400F-BAD6-95ECBAD775C3@dreamhost.com>',NULL),('<1389627137.4235.10.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 10:32:17',-18000,'2014-01-13 15:32:17',NULL,'[openstack-dev] [Neutron] Partially Shared Networks','On Mon, 2014-01-13 at 10:23 +0000, Stephen Gran wrote:\n> Hi,\n> \n> I don\'t think that\'s what\'s being asked for. Just that there be more \n> than the current check for \'(isowner of network) or (shared)\'\n> \n> If the data point could be \'enabled for network\' for a given tenant, \n> that would be more flexible.\n\nAgreed, but I believe Mathieu is thinking more in terms of how such a\ncheck could be implemented. What makes this problematic (at least in my\nsimplistic understanding of Neutron wiring) is that there is no\nguarantee that tenant A\'s subnet does not overlap with tenant B\'s\nsubnet. Because Neutron allows overlapping subnets (since Neutron uses\nnetwork namespaces for isolating traffic), code would need to be put in\nplace that says, basically, \"if this network is shared between tenants,\nthen do not allow overlapping subnets, since a single, shared network\nnamespace will be needed that routes traffic between the tenants\".\n\nOr at least, that\'s what I *think* is part of the problem...\n\nBest,\n-jay\n\n> On 13/01/14 10:06, Mathieu Rohon wrote:\n> > Hi,\n> >\n> > This is something that we potentially could implement during the\n> > implementation of the isolated-network bp [1]\n> > Basically, on an isolated network, an ARP responder will respond to\n> > ARP request. For an L2 network which is totally isolated, ARP\n> > responder will only respond to arp-request of the gateway, other\n> > broadcast requests will be dropped (except for DHCP requests)\n> >\n> > We could enhance this feature to populate the arp-responder so that if\n> > tenant A and tenant B wants to be able to communicate on this shared\n> > and isolated network, ARP responder for the VM of tenant A will be\n> > populated with Mac address of VM of the Tenant B, and vice versa.\n> >\n> > [1] https://blueprints.launchpad.net/neutron/+spec/isolated-network\n> >\n> > On Fri, Jan 10, 2014 at 10:00 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> >> On Fri, 2014-01-10 at 17:06 +0000, CARVER, PAUL wrote:\n> >>> If anyone is giving any thought to networks that are available to\n> >>> multiple tenants (controlled by a configurable list of tenants) but\n> >>> not visible to all tenants I?d like to hear about it.\n> >>>\n> >>> I?m especially thinking of scenarios where specific networks exist\n> >>> outside of OpenStack and have specific purposes and rules for who can\n> >>> deploy servers on them. We?d like to enable the use of OpenStack to\n> >>> deploy to these sorts of networks but we can?t do that with the\n> >>> current ?shared or not shared? binary choice.\n> >>\n> >> Hi Paul :) Please see here:\n> >>\n> >> https://www.mail-archive.com/openstack-dev at lists.openstack.org/msg07268.html\n> >>\n> >> for a similar discussion.\n> >>\n> >> best,\n> >> -jay\n> >>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n\n\n\n\n','<52D3BE8C.4030609@theguardian.com>',NULL),('<1389628317.4235.15.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 10:51:57',-18000,'2014-01-13 15:51:57',NULL,'[openstack-dev] [Ceilometer] Aggregation discussion','On Mon, 2014-01-13 at 13:39 +0400, Nadya Privalova wrote:\n> Jay,\n> \n> \n> Thanks for comments!\n> \n> The question you raised was discussed several times within Ceilometer\n> team but as I understand there is no official resolution yet. \n> \n> I agree with you that statistics\' collection is the main Ceilometer\'s\n> goal. But at the same time there should be a way to visualize the\n> result of Ceilometer\'s work.\n> \n> My opinion is that the current set of data queries (get samples, get\n> statistics) is the minimum set and it\'s ok to keep it as a part of\n> Ceilometer\'s functionality. We need it at least for UI.\n\nYes, I\'ve seen the (excellent) wireframes that Jarda and others have\nbeen working on, and I can certainly see where the feature request comes\nfrom.\n\n> So, my proposal is to make this existing queries faster. Looks like\n> our vision are the same :)\n\nCertainly :)\n\n>         Pre-calculate when? :) During processing of samples, or during\n>         some\n>         periodic job?\n> \n> \n> It should be a periodic job, right.\n\nI\'m actually not so sure. If you spread the work of updating the\naggregate into the (multi-processed) collectors, then updating the\naggregates become less resource-intensive.\n\nIt\'s the same idea behind putting a SQL trigger on a table in an RDBMS\nthat updates a rolling aggregate. Doing the update work one little piece\nat a time can be more efficient than doing a large update on a periodic\njob -- particularly when, as is the case here, the long-running periodic\nupdate job would need to take locks on the base fact tables.\n\n> \n>         The term \"aggregate\" really just means a generic grouping or\n>         summarization. If you are looking for a term that represents\n>         the\n>         rules/heuristics for maintaining rolling calculations, perhaps\n>         the term\n>         \"report\" is better?\n> \n> \n> Hmm, I think that \'aggregate\' is ok. In \"my terminology\" an aggregate\n> is a ready set of statistics for concrete meter, period and query.\n> Anyway, will think about it.\n\nSure, not a big deal. Was just throwing out ideas, really. \"Aggregate\"\nis fine.\n\nBest,\n-jay\n\n\n\n\n','<CAKWrcJcWAu3kOWd4PYw3X5pZdi9fA7c7=E6T8a7GJvxod0DvwA@mail.gmail.com>',NULL),('<1389638771-sup-8068@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 10:49:31',-28800,'2014-01-13 18:49:31',NULL,'[openstack-dev] [oslo] Common SSH','Excerpts from Doug Hellmann\'s message of 2014-01-13 09:10:27 -0800:\n> On Mon, Jan 13, 2014 at 11:34 AM, Bhuvan Arumugam <bhuvan at apache.org> wrote:\n> \n> >\n> > On Mon, Jan 13, 2014 at 7:02 AM, Doug Hellmann <\n> > doug.hellmann at dreamhost.com> wrote:\n> >> Where are we doing those sorts of operations?\n> >>\n> >\n> > Currently, we don\'t upload/download files to remote server through\n> > ssh/scp. We do execute commands, pipe multiple commands in few tempest when\n> > ssh is enabled. With oslo/fabric, we may develop a common ground to deal\n> > with remote servers, be it executing commands or dealing with files.\n> >\n> \n> Are we using ssh to run commands anywhere else in OpenStack? Maybe in one\n> of the orchestration layers like heat or trove?\n\nHeat does not use SSH, though I believe it did in its early days.\n\nSSH belongs to the admins. I don\'t think OpenStack should be using it.\n\nI see the usefuleness in the tempest case, which tests that the key given\nis on the box, and may need to verify other things inside the instance.\n\nHowever things that won\'t work with a simple \"ssh to that box and report\nsuccess/fail\" could also be done just by having an image which calls\nback to tempest on boot.\n\n\n','<CADb+p3Sie+bO_4AX0jbg6T=dBixr_rrAT5ASt5XqZCPacWQmiQ@mail.gmail.com>',NULL),('<1389639024-sup-1798@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 10:54:09',-28800,'2014-01-13 18:54:09',NULL,'[openstack-dev] [oslo.config] Centralized config management','Excerpts from Nachi Ueno\'s message of 2014-01-13 10:35:07 -0800:\n> Hi Clint\n> \n> 2014/1/10 Clint Byrum <clint at fewbar.com>:\n> > Excerpts from Nachi Ueno\'s message of 2014-01-10 13:42:30 -0700:\n> >> Hi Flavio, Clint\n> >>\n> >> I agree with you guys.\n> >> sorry, may be, I wasn\'t clear. My opinion is to remove every\n> >> configuration in the node,\n> >> and every configuration should be done by API from central resource\n> >> manager. (nova-api or neturon server etc).\n> >>\n> >> This is how to add new hosts, in cloudstack, vcenter, and openstack.\n> >>\n> >> Cloudstack: \"Go to web UI, add Host/ID/PW\".\n> >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/host-add.html\n> >>\n> >> vCenter: \"Go to vsphere client, Host/ID/PW\".\n> >> https://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.solutions.doc%2FGUID-A367585C-EB0E-4CEB-B147-817C1E5E8D1D.html\n> >>\n> >> Openstack,\n> >> - Manual\n> >>    - setup mysql connection config, rabbitmq/qpid connection config,\n> >> keystone config,, neturon config, xxxx\n> >> http://docs.openstack.org/havana/install-guide/install/apt/content/nova-compute.html\n> >>\n> >> We have some deployment system including chef / puppet / packstack, TripleO\n> >> - Chef/Puppet\n> >>    Setup chef node\n> >>    Add node/ apply role\n> >> - Packstack\n> >>    -  Generate answer file\n> >>       https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/sect-Running_PackStack_Non-interactively.html\n> >>    -  packstack --install-hosts=192.168.1.0,192.168.1.1,192.168.1.2\n> >> - TripleO\n> >>    - UnderCloud\n> >>        nova baremetal node add\n> >>    - OverCloud\n> >>        modify heat template\n> >>\n> >> For residence in this mailing list, Chef/Puppet or third party tool is\n> >> easy to use.\n> >> However,  I believe they are magical tools to use for many operators.\n> >> Furthermore, these development system tend to take time to support\n> >> newest release.\n> >> so most of users, OpenStack release didn\'t means it can be usable for them.\n> >>\n> >> IMO, current way to manage configuration is the cause of this issue.\n> >> If we manage everything via API, we can manage cluster by horizon.\n> >> Then user can do \"go to horizon, just add host\".\n> >>\n> >> It may take time to migrate config to API, so one easy step is to convert\n> >> existing config for API resources. This is the purpose of this proposal.\n> >>\n> >\n> > Hi Nachi. What you\'ve described is the vision for TripleO and Tuskar. We\n> > do not lag the release. We run CD and will be in the gate \"real soon\n> > now\" so that TripleO should be able to fully deploy Icehouse on Icehouse\n> > release day.\n> \n> yeah, I\'m big fan of TripleO and Tuskar.\n> However, may be, it is difficult to let TripleO/Tuskar up-to-dated\n> with newest releases.\n> \n> so let\'s say Nova and neutron added new function in 3rd release (I3\n> for icehouse),\n> there is no way to support it in TripleO/Tuskar.\n> This is natural, because TripleO/Tuskar is 3rd party tool for nova or\n> neutron. (same as Chef/Puppet).\n> IMO, Tuskar API and existing projects(nova, neturon) should be\n> integrated in design level.\n> \n\nThis is false. TripleO is the official OpenStack deployment program. It\nis not a 3rd party tool. Of course sometimes TripleO may lag the same\nway Heat may lag other integrated release components. But that is one\nreason we have release meetings, blueprints, and summits, so that projects\nlike Heat and TripleO can be aware of what is landing in i3 and at least\nattempt to have some support in place ASAP.\n\nTrying to make this happen inside the individual projects instead of\nin projects dedicated to working well in this space is a recipe for\nfrustration, and I don\'t believe it would lead to any less lag. People\nwould just land features with \"FIXME: support config api\".\n\n\n','<CABJepwgU+zT2Hi0j7v1hC4x-29pbe+HghwF0hcnkGj4WhGsCHg@mail.gmail.com>',NULL),('<1389640300.4374.10.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 19:11:40',0,'2014-01-13 19:11:40',NULL,'[Openstack] Designate DNSaaS installation issue','Hi Nick,\n\nSeveral fixes to the migrations for PostgreSQL have now merged, and\nwe\'ve setup some automated tests to verify the migrations continue to\nfunction on SQLite / MySQL / PostgreSQL..\n\nSo - Hopefully that\'s the end of PostgreSQL issues :)\n\nThanks,\nKiall\n\nOn Sun, 2014-01-12 at 08:26 +0200, Nick Maslov wrote:\n> Thanks Kiall!\n> \n> \n> \n> \n> -- \n> Nick Maslov\n> Sent with Airmail\n> \n> On January 9, 2014 at 5:26:07 PM, Mac Innes, Kiall (kiall at hp.com)\n> wrote:\n> \n> > Hi Nick, \n> > \n> > I\'ll get psql re-tested this week, I expect it\'s something simple \n> > causing the failure, but it\'s been a while since I\'ve tested with \n> > PostgreSQL. \n> > \n> > I\'ve filed bug #1267509 [1] on your behalf to track the issue, you\n> > can \n> > hit the \"This affects me too\" link at the top of the page to get \n> > notified of progress. \n> > \n> > [1]: https://bugs.launchpad.net/designate/+bug/1267509 \n> > \n> > Thanks, \n> > Kiall \n> > \n> > On Mon, 2014-01-06 at 12:49 +0200, Nick Maslov wrote: \n> > > Hi Simon, \n> > > \n> > > \n> > > Say, are there any news on this issue? \n> > > \n> > > \n> > > Or - you can point me to a place in the code, where this check is\n> > - \n> > > and I will ask local python devs to help me with it. \n> > > \n> > > \n> > > Cheers, \n> > > NM \n> > > -- \n> > > Nick Maslov \n> > > Sent with Airmail \n> > > \n> > > On January 1, 2014 at 11:20:11 AM, Nick Maslov (azpekt at gmail.com) \n> > > wrote: \n> > > \n> > > > Hi Simon, \n> > > > \n> > > > \n> > > > Thanks a lot, will wait for updated version. \n> > > > \n> > > > \n> > > > Well, we decided to hit the Postgres road with this\n> > installation. \n> > > > And already had a lot of issues on that path, starting with\n> > small \n> > > > things like this to inability of Postgres to easily perform HA. \n> > > > \n> > > > \n> > > > Happy NY! \n> > > > \n> > > > \n> > > > -- \n> > > > Nick Maslov \n> > > > Sent with Airmail \n> > > > \n> > > > On December 31, 2013 at 5:27:10 PM, Simon McCartney \n> > > > (simon at mccartney.ie) wrote: \n> > > > \n> > > > > Hi Nick, \n> > > > > \n> > > > > \n> > > > > I don\'t think we\'ve tested against Postgres recently, let me\n> > see \n> > > > > if we can get a Postgres test environment setup & tweak the\n> > SQLA \n> > > > > to keep Postgres happy. \n> > > > > \n> > > > > \n> > > > > (fwiw, we\'re using Percona/Galera MySQL clusters in\n> > production \n> > > > > with Designate) \n> > > > > \n> > > > > \n> > > > > Simon. \n> > > > > \n> > > > > On Tuesday, December 31, 2013, Nick Maslov wrote: \n> > > > > Hi, \n> > > > > \n> > > > > \n> > > > > I`m installing Designate as per this doc. \n> > > > > \n> > > > > \n> > > > > When I try to use this command: \n> > > > > designate-manage database-sync \n> > > > > It fails with following: \n> > > > > \n> > > > > \n> > > > > 2013-12-31 12:20:39 DEBUG [migrate.versioning.util] \n> > > > > Disposing SQLAlchemy engine Engine(postgres://designate:pa \n> > > > > %24w0rd at pg01-001/designate) \n> > > > > 2013-12-31 12:20:39 ERROR [cliff.app] Postgresql ENUM \n> > > > > type requires a name. \n> > > > > ERROR: Postgresql ENUM type requires a name. \n> > > > > \n> > > > > \n> > > > > I`m using PostgreSQL as backend for Designate. Can someone \n> > > > > point me in the right direction, and maybe point to \n> > > > > Designate developers? \n> > > > > \n> > > > > \n> > > > > Thanks, \n> > > > > NM \n> > > > > \n> > > > > \n> > > > > \n> > > > > -- \n> > > > > Nick Maslov \n> > > > > Sent with Airmail \n> > > > > \n> > > > > \n> > > > > -- \n> > > > > Simon McCartney \n> > > > > E: simon at mccartney.ie \n> > > > > M: +44 7710 836 915 \n> > > > > \n> > > > > \n> > > _______________________________________________ \n> > > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n> > > Post to : openstack at lists.openstack.org \n> > > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n> > \n> > \n> > ____________________________________________________________________\n> > - signature.asc, 853 bytes\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 836 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140113/154f9e70/attachment.pgp>\n\n','<etPan.52d2359b.74b0dc51.4c98@mbp>',NULL),('<1389645449.4235.26.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 15:37:29',-18000,'2014-01-13 20:37:29',NULL,'[openstack-dev] [Neutron] Partially Shared Networks','On Mon, 2014-01-13 at 11:47 -0800, Rick Jones wrote:\n> On 01/13/2014 07:32 AM, Jay Pipes wrote:\n> > On Mon, 2014-01-13 at 10:23 +0000, Stephen Gran wrote:\n> >> Hi,\n> >>\n> >> I don\'t think that\'s what\'s being asked for. Just that there be more\n> >> than the current check for \'(isowner of network) or (shared)\'\n> >>\n> >> If the data point could be \'enabled for network\' for a given tenant,\n> >> that would be more flexible.\n> >\n> > Agreed, but I believe Mathieu is thinking more in terms of how such a\n> > check could be implemented. What makes this problematic (at least in my\n> > simplistic understanding of Neutron wiring) is that there is no\n> > guarantee that tenant A\'s subnet does not overlap with tenant B\'s\n> > subnet. Because Neutron allows overlapping subnets (since Neutron uses\n> > network namespaces for isolating traffic), code would need to be put in\n> > place that says, basically, \"if this network is shared between tenants,\n> > then do not allow overlapping subnets, since a single, shared network\n> > namespace will be needed that routes traffic between the tenants\".\n> >\n> > Or at least, that\'s what I *think* is part of the problem...\n> \n> Are such checks actually necessary?  That is to say, unless it will \n> completely fubar something internally ina database or something (versus \n> just having confused routing), I would think that it would be but a \n> nicety for Neutron runtime to warn the user(s) they were about to try to \n> connect overlapping subnets to the same router.  Nice to report it \n> perhaps as a warning, but not an absolutely required bit of \n> functionality to go forward.\n\nSure, good points.\n\n> If Tenant A and Tenant B were separate, recently merged companies, they \n> would have to work-out, in advance, issues of address overlap before \n> they could join their two networks.  At one level at least, we could \n> consider their trying to do the same sort of thing within the context of \n> Neutron as being the same.\n> \n> FWIW, here is an intra-tenant attempt to assign two overlapping subnets \n> to the same router.  Of course I\'m probably playing with older bits in \n> this particular sandbox and they won\'t reflect the current top-of-trunk:\n> \n> $ nova list\n> +--------------------------------------+------------------------+--------+------------+-------------+-------------------------------+\n> | ID                                   | Name                   | Status \n> | Task State | Power State | Networks                      |\n> +--------------------------------------+------------------------+--------+------------+-------------+-------------------------------+\n> | d97a46ed-19eb-4a87-8536-eb9ca4ba3895 | overlap-net0000_lg0000 | ACTIVE \n> | None       | Running     | overlap-net0000=192.168.123.2 |\n> | ad8d6c9c-9a4c-442e-aebf-fd30475b7675 | overlap-net0001_lg0000 | ACTIVE \n> | None       | Running     | overlap-net0001=192.168.123.2 |\n> +--------------------------------------+------------------------+--------+------------+-------------+-------------------------------+\n> $ neutron subnet-list\n> +--------------------------------------+--------------------+------------------+------------------------------------------------------+\n> | id                                   | name               | cidr \n>         | allocation_pools                                     |\n> +--------------------------------------+--------------------+------------------+------------------------------------------------------+\n> | d6015301-e5bf-4f1a-b3b3-5bde71a52496 | overlap-subnet0001 | \n> 192.168.123.0/24 | {\"start\": \"192.168.123.2\", \"end\": \"192.168.123.254\"} |\n> | faddcc32-7bb6-4cb2-862e-7738e5c54f6d | overlap-subnet0000 | \n> 192.168.123.0/24 | {\"start\": \"192.168.123.2\", \"end\": \"192.168.123.254\"} |\n> +--------------------------------------+--------------------+------------------+------------------------------------------------------+\n> $ neutron router-create overlap-router0001\n> Created a new router:\n> +-----------------------+--------------------------------------+\n> | Field                 | Value                                |\n> +-----------------------+--------------------------------------+\n> | admin_state_up        | True                                 |\n> | external_gateway_info |                                      |\n> | id                    | 88339018-d286-45ec-b2d2-ccb78ae78837 |\n> | name                  | overlap-router0001                   |\n> | status                | ACTIVE                               |\n> | tenant_id             | 57367642563150                       |\n> +-----------------------+--------------------------------------+\n> $ neutron router-interface-add overlap-router0001 overlap-subnet0000\n> Added interface b637cb32-c33a-4565-a6f3-b7ea22a02be0 to router \n> overlap-router0001.\n> $ neutron router-interface-add overlap-router0001 overlap-subnet0001\n> 400-{u\'QuantumError\': u\'Bad router request: Cidr 192.168.123.0/24 of \n> subnet d6015301-e5bf-4f1a-b3b3-5bde71a52496 overlaps with cidr \n> 192.168.123.0/24 of subnet faddcc32-7bb6-4cb2-862e-7738e5c54f6d\'}\n\nOK, so it looks like the plumbing is already in place, and all that\nwould need doing is lifting the restriction that a router only service a\nsingle tenant unless the network is globally shared...\n\nBut again, I\'m sure there\'s more to it than that ;)\n\n-jay\n\n\n\n','<52D442C7.9090501@hp.com>',NULL),('<1389645673.2746.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 14:41:13',-21600,'2014-01-13 20:41:13',NULL,'[openstack-dev] [Oslo] Improving oslo-incubator update.py','On Mon, 2014-01-13 at 12:07 -0500, Doug Hellmann wrote:\n> We can\'t just compute the hash of the modules in the project receiving\n> copies, and then look for them in the oslo-incubator repo, because we\n> modify the files as we copy them out (to update the import statements\n> and replace \"oslo\" with the receiving project name in some places like\n> config option defaults). \n\nWhy not embed the hash into the files as we copy them out, maybe as a\nspecially formatted comment at the end of the file?\n\nThat said, I\'ve always thought that oslo-incubator should be a library\nwe use directly, rather than a repository we copy out of.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CADb+p3TKG2foyJiTjHcVDt9eXcsACx+0-vWLX0w=4ho-HwEJ5Q@mail.gmail.com>',NULL),('<1389651198.17286.YahooMailNeo@web125902.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-13 14:13:18',-28800,'2014-01-13 22:13:18',NULL,'[Openstack-docs] rundown of 13jan2014 training manuals meeting','Action items\n	1. dguitarbite continue to work on gdoc https://docs.google.com/a/yahoo-inc.com/document/d/1w7XhcJzdZi_DMT4eenA9rBY7n3uPieCzIfllaQZkXag/edit?usp=sharing\n	2. dguitarbite moodle handoff readiness 08feb2014\n	3. colinmcnamara training guides contribution how to for user groups and corporate\n	4. dguitarbite email sina and sarob on commercial training guides experience so far\n	5. dguitarbite sarob finalize clean up of up aptira content in repo\nhttp://eavesdrop.openstack.org/meetings/training_manuals/2014/training_manuals.2014-01-13-17.01.html\n\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140113/97c0f416/attachment.html>\n\n',NULL,NULL),('<1389656544-sup-6811@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 15:55:28',-28800,'2014-01-13 23:55:28',NULL,'[openstack-dev] [TripleO] [Tuskar] Deployment Management\n	section - Wireframes','Excerpts from Walls, Jeffrey Joel (Cloud OS R&D)\'s message of 2014-01-13 06:54:11 -0800:\n> > From: Jaromir Coufal [mailto:jcoufal at redhat.com]\n> >> On 2014/10/01 19:02, Dougal Matthews wrote:\n> \n> > > - If I remove some instances, do I as the administrator need to care\n> > > which are removed? Do we need to choose or be informed at the end?\n> > This is great question on which we have long debates. I am convinced that I as\n> > administrator, do care which nodes I want to free up.\n> > \n> > But current TripleO approach is using heat template and there we can just\n> > specify number of nodes of that specific role. So it means that I decrease from\n> > 10 to 9 instances and app will take care for us for some node to be removed\n> > (AFAIK heat removes the last added node).\n> > \n> > So what we can do at the moment (until there is some way to specify which\n> > node to remove) is to inform user, which nodes were removed in the end... at\n> > least.\n> > \n> > In the future, I\'d like to enable user to have both ways available - just decrease\n> > number and let system to decide which nodes are going to be removed for him\n> > (but at least inform in advance which nodes are the chosen ones). Or, let user to\n> > choose by himself.\n> \n> Should a defect be filed against Heat then?  If I have a system that is currently running\n> my app server and heat comes along and deprovisions it (simply because it happened\n> to be running on the system that was spun up last), I\'m going to be quite upset.\n> \n\nYes indeed, there are a number of bugs in this area and I think they\'re\nso fundamental to our problems in TripleO that I haven\'t even taken the\ntime to file these bugs, which I should probably do.\n\nBasically what we need is two changes:\n\n1) Check for an already deleted server before deleting any. This is\nrelated to stack convergence:\n\nhttps://blueprints.launchpad.net/heat/+spec/stack-convergence\n\nThis will allow users to just delete a server they want to delete,\nand then update the template to reflect reality.\n\n2) Allow resources to be marked as critical or disposable. Critical\nresources would not ever be deleted for scaling purposes or during\nupdates. An update would fail if there were no disposable resources.\nScaling down would just need to be retried at this point.\n\nWith those two things, TripleO can make the default \"disposable\" for\nstateless resources, and \"critical\" for stateful resources. Tuskar would\njust report on problems in managing the Heat stack. Admins can then\ncontrol any business cases for evacuations/retirement of workloads/etc\nfor automation purposes.\n\nEventually perhaps we could use Mistral to manage that, but for now,\nI think just being able to protect and manually delete important nodes\nfor scale down is enough. Perhaps Tuskar could even pop up a dialog\nshowing them and allowing manual selection.\n\n\n','<5201E6AC0320A04B9C7D63F19055FED850B98BC7@G4W3299.americas.hpqcorp.net>',NULL),('<1389656659.2210.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 18:44:19',-18000,'2014-01-13 23:44:19',NULL,'[openstack-dev] [Neutron][Testr] Brand new checkout of\n Neutron... getting insane unit test run results','On Mon, 2014-01-13 at 22:16 +0000, Mark McClain wrote:\n> I?d rather us explicitly skip the tests if the module is not available.\n\nI think the danger with that is that you\'ll have developers running a\nbunch of tests, getting skipped results (not failures), and thinking\nthat everything is hunky-dory -- until they then get a bunch of failures\nin the gate and wonder why everything works fine for them but is\nbreaking in the gate.\n\nAfter looking at Sean\'s patch, I think it\'s an acceptable solution. It\'s\nnot ideal, but that\'s only because Neutron\'s (and Nova\'s) unit tests are\nnot really unit tests at all. They\'re functional tests that test\nsignificantly more than a single unit of code in each test method.\n\nIf the boundary tested in each test method were smaller and contained\nonly to a single unit of code, not dozens of function calls at once,\nthen it might be possible to simply mock.patch() the pyudev interface\nintersections instead of come up with a no-op Fake implementation of\nit...\n\nBest,\n-jay\n\n> On Jan 13, 2014, at 3:39 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com> wrote:\n> \n> > On Wed, Jan 01, 2014 at 07:56:22PM -0800, Clark Boylan wrote:\n> >> It looks like the problem is that there is a dependency on pyudev\n> >> which only works properly on Linux. The neutron setup_hook does\n> >> properly install pyudev on Linux (explains why the tests run in the\n> >> gate), but would not work properly on windows or OS X. I assume folks\n> >> are trying to run the tests on not Linux? Neutron may want to do\n> >> something similar to what Nova does when libvirt is not importable,\n> >> https://git.openstack.org/cgit/openstack/nova/tree/nova/tests/virt/libvirt/test_libvirt.py#n77\n> >> and use a fake in order to get the tests to run properly anyways.\n> > \n> > Thanks for pointing this out - I\'ve begun work on doing this, and that\n> > link was very helpful for figuring out what would need to be done.\n> > \n> > -- \n> > Sean M. Collins\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1C0E3118-F977-4E80-9FBB-8AA3826D4A6D@yahoo-inc.com>',NULL),('<1389666995.3061.26.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 12:36:35',36000,'2014-01-14 02:36:35',NULL,'[openstack-dev] [wsme] Undefined attributes in WSME','On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:\n> \n> \n> \n> \n> On Sun, Jan 12, 2014 at 6:33 PM, Jamie Lennox <jamielennox at redhat.com>\n> wrote:\n>         On Fri, 2014-01-10 at 10:23 -0500, Doug Hellmann wrote:\n>         >\n>         >\n>         >\n>         >\n>         > On Thu, Jan 9, 2014 at 12:02 AM, Jamie Lennox\n>         <jamielennox at redhat.com>\n>         > wrote:\n>         >         Is there any way to have WSME pass through arbitrary\n>         >         attributes to the created object? There is nothing\n>         that i can\n>         >         see in the documentation or code that would seem to\n>         support\n>         >         this.\n>         >\n>         >         In keystone we have the situation where arbitrary\n>         data was\n>         >         able to be attached to our resources. For example\n>         there are a\n>         >         certain number of predefined attributes for a user\n>         including\n>         >         name, email but if you want to include an address\n>         you just add\n>         >         an \'address\': \'value\' to the resource creation and\n>         it will be\n>         >         saved and returned to you when you request the\n>         resource.\n>         >\n>         >         Ignoring whether this is a good idea or not (it\'s\n>         done), is\n>         >         the option there that i missed - or is there any\n>         plans/way to\n>         >         support something like this?\n>         >\n>         >\n>         > There\'s a change in WSME trunk (I don\'t think we\'ve released\n>         it yet)\n>         > that allows the schema for a type to be changed after the\n>         class is\n>         > defined. There isn\'t any facility for allowing the caller to\n>         pass\n>         > arbitrary data, though. Part of the point of WSME is to\n>         define the\n>         > inputs and outputs of the API for validation.\n>         >\n>         >\n>         > How are the arbitrary values being stored in keystone? What\n>         sorts of\n>         > things can be done with them? Can an API caller query them,\n>         for\n>         > example?\n>         >\n>         >\n>         > Doug\n>         \n>         \n>         So you can\'t query based on these arbitrary values but they\n>         are there as\n>         part of the resource. We have generic middleware that\n>         interprets the\n>         incoming json or xml to python dictionaries. Then we extract\n>         the\n>         queryable information for storing into database cells. In the\n>         case of\n>         User these are: id, name, password, enabled, domain_id,\n>         default_project_id. Everything else in the dictionary is\n>         stored in an\n>         \'extra\' column in the database as a JSON dictionary. When we\n>         reconstruct\n>         the User object we recreate the extra dictionary and update it\n>         with the\n>         known attributes.\n>         \n>         So there is no restriction on types or depth of objects, and\n>         whilst you\n>         can\'t query from those attributes they will always be present\n>         if you get\n>         or list the user.\n>         \n>         Note that User is probably a bad example in this because of\n>         LDAP and\n>         other backends but the idea is the same for all keystone\n>         resources.\n>         \n>         \n>         So I don\'t think that changing the WSME type after definition\n>         is useful\n>         in this case. Is it the sort of thing that would be possible\n>         or accepted\n>         to add to WSME?\n>         \n>         From the little bit of looking i\'ve done it appears that WSME\n>         loops over\n>         the defined attributes of the class and extracts those from\n>         the message\n>         rather than looping over keys in the message which makes this\n>         more\n>         difficult. Can WSME be made to decode all values in a purely\n>         python\n>         primative way (eg don\'t decode dates, objects etc, just give\n>         python\n>         dictionaries like from a json.loads)?\n> \n> \n> WSME asserts that APIs should be well and clearly defined, so that\n> callers of the API can understand what they are supposed to (or\n> required to) pass in, and what they will receive as a response.\n> Accepting arbitrary data goes somewhat against this design goal.\n> \n> \n>         I would prefer not to have keystone using yet another\n>         framework from the\n>         rest of openstack, but should i just be looking to use\n>         jsonschema or\n>         something instead?\n> \n> \n> What requirement(s) led to keystone supporting this feature?\n\nI completely agree with you/WSME that this is a bad situation. I\'ve got\nno idea where the requirement came from however it is something that is\nsupported now and so not something we can back out of. \n\nI don\'t think WSME should advocate the situation, though it will already\nignore additional attributes i\'m wondering what would be involved with\njust collecting and stashing those additional attributes?\n\n\n> Doug\n> \n> \n>  \n>         \n>         Jamie\n>         \n>         >\n>         >\n>         >\n>         >         Thanks,\n>         >\n>         >         Jamie\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CADb+p3QKuxYwLVS_MgPyQBQ7z4dpL6J+Ude3Miia1h040BrncA@mail.gmail.com>',NULL),('<1389668381.2210.128.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-13 21:59:41',-18000,'2014-01-14 02:59:41',NULL,'[openstack-dev] [nova] api schema validation pattern changes','Caution! Long and opinionated response.\n\ntl;dr:\n\nA versioned API with no API extensions is *not* a static API. If you\nwant to look at a heavily versioned API without extensions for a Compute\ncontrol API that has successfully evolved over the years to meet its\ncustomers\' needs, you need look no further than the EC2 API.\n\nWe don\'t need API extensions and they make our Compute API laughably\ncomplex and cumbersome. We should ditch entirely the concept of API\nextensions in our next Compute API major release.\n\nDetails\n-------\n\nAll the gory details, including categorization of which API extensions\nneed to just go away and which extensions should just be part of the\ncore Compute API is below.\n\nOn Tue, 2014-01-14 at 06:29 +0800, Christopher Yeoh wrote:\n> We have around 50+ plugins and only slightly more than 10 are\n> considered to be \"core\". So with a static API we\'d have to have what I\n> think would be a pretty long discussion about what functionality we\n> will no longer support, and inevitably we\'ll end up with a much larger\n> subset of existing functionality that all Openstack deployers would\n> have to support. Including perhaps all the backend requirements as\n> having an API which doesn\'t actually work is I don\'t think an\n> improvement for client programs on not offering the API functionality\n> for a deployment in the first place.\n\nI am not describing a static API. More on that below...\n\nLet\'s actually talk specifics here, Chris.\n\nIn my opinion, out of 78 (!) existing extensions of the OpenStack API,\nthe *vast* majority of those extensions represent stuff that simply\nshould have been added to the main Compute API, plain and simple, with a\nsimple minor/revision version increment since the changes are not\nbackwards-incompatible at all. The remaining API extensions either\naren\'t appropriate for an Compute control API targeted at users/tenants\nor aren\'t appropriate for any HTTP API to begin with.\n\n== Should have just been in core API ==\n\nOut of the 78 extensions, I came up with 58 that should have just been\nadditions and/or modifications to the Compute API (with a version\nincrement):\n\nadmin_actions -- seriously...why wouldn\'t pause/unpause, etc be part of\nthe API? if some hypervisor doesn\'t support the action, then raise\nNotImplemented and return an HTTP 501 Not Implemented -- after all,\nthat\'s what a 501 was designed for, and client tooling for HTTP APIs\nshould understand that.\n\nattach_interfaces\nblock_device_mapping_v2_boot\ncertificates\nconsole_output\nevacuate\nfixed_ips\nflavor_access\nflavor_disabled\nflavor_rxtx\nflavor_swap\nflavorextradata\nflavorextraspecs\nflavormanage\nfloating_ip_dns\nfloating_ip_pools\nfloating_ips\nfloating_ips_bulk\ninstance_actions\nkeypairs\nmigrations\nmultinic\nmultiple_create\nos_networks\nos_tenant_networks\nquota_classes\nquotas\nrescue\nscheduler_hints\nsecurity_group_default_rules\nsecurity_groups\nserver_diagnostics\nserver_password\nserver_start_stop\nshelve\nsimple_tenant_usage\nused_limits\nused_limits_for_admin\nuser_quotas\nvirtual_interfaces\nvolume_attachment_update\nvolumes\n\nFor all of the above, there\'s really no reason NOT to have the\nfunctionality just be part of the core API.\n\nconsoles -- Should be part of the core API -- and even worse, there is a\nos-getVNCConsole extension and an os-getSPICEConsle extension entry\npoint instead of just allowing an extensible request dict input...\n\ncreateserverext\nextended_availability_zone\nextended_floating_ip\nextended_ips\nextended_ips_max\nextended_quotas\nextended_server_attributes\nextended_services\nextended_status\nextended_virtual_interfaces_net\nextended_volumes\nimage_size\nserver_usage (despite name, only adds launched_at and terminated_at\nattributes)\nuser_data\n\nAll of the above should have just been part of the core API, with\n\"extended attributes\" added in version increments to the API.\n\n== Should never have been in the API to begin with ==\n\nThe following extensions should never have been added to the Compute API\nat all, IMO. They are specific to particular hypervisors or deployers,\nare not tenant-facing and don\'t belong in a Compute control API at all. \n\nagents -- a list of *guest agents* that Xen, Virtualbox, and VMWare\nhypervisors talk to. Seriously, who cares in the sense of a public\nCompute control API? This is the domain of the operator... see below.\n\naggregates -- was originally XenServer-specific (resource pools)\nfunctionality that was added as an extension to the API with no regard\nto how or if the functionality would work in a non-XenServer\nenvironment. It should never have been accepted as an API extension. It\nwas providing XenServer-specific functionality for an API that is (and\nwas from the beginning) deliberately supposed to be agnostic of the\nunderlying hypervisor.\n\nassisted-volume-snapshots -- again, an API extension that is really just\njust about enabling some functionality for specific hypervisors and\nbackend storage (GlusterFS). There is *absolutely zero reason this needs\nto be part of the API*. If some drivers can take advantage of something\nto make something better for the user, what does that have to do with\nthe control API. Answer: nothing at all. This code again belongs in the\ndriver layer entirely.\n\navailability_zone -- yes, folks, believe it or not, Availability Zone is\nactually an API extension. What does this extension do? Well, it returns\nthe results of the EC2 API DescribeAvailabilityZone call. As such, it\ndoesn\'t belong in the OpenStack Compute API at all. Seriously, if\nsomebody wanted the results of DescribeAvailabilityZone, then call the\nEC2 API endpoint.\n\ncells and cells_capacities -- Cells are not tenant-facing, and they\nreally are an implementation detail. This should never have polluted the\nCompute API as an extension. It belongs elsewhere, either as a separate\nscheduler driver that has its own data store that describes the cell\nrelationships, or as an RPC-only API.\n\nconfig_drive -- It\'s an implementation detail and belongs in the driver\nlayer, not as something queryable or controllable via an HTTP control\nAPI.\n\ndeferred_delete -- Frankly, the functionality here is suspect and smells\nlike it was just ported as-is from a particular deployer\'s API... If\nthis kind of use case is common (doubtful), then the existing Compute\nAPI DELETE /servers should just have been enhanced to support \"forced\ndeletion\".\n\ndisk_config -- I still believe this is mostly an implementation detail\nand doesn\'t belong as an API extension.\n\nfping -- Eh... this isn\'t about a Compute API at all. It\'s a monitoring\nAPI -- specific to one implementation -- and doesn\'t belong in the\nCompute API.\n\nhide_server_addresses -- Should never have been a control API extension.\nBelongs as a simple configuration option and done at the manager layer.\n\nhosts\nhypervisors\ninstance_usage_audit_log\nservices\nbaremetal_nodes\nbaremetal_ext_status\n\nThe above are for operators, not for tenants or even \"admins\" in the\ntraditional sense of an admin of cloud resources. The Ironic API --\nwhich is targeted at operators -- is where this HTTP API stuff should\nhave gone, not in a Compute API that is targeted at users. Mixing\noperator APIs with tenant/user control APIs is wrong, IMO.\n\n> The other issue is how often with a static API we would have to do\n> version bumping. Icehouse is not unique in having the Nova API\n> extended in several areas and I doubt Juno would be any different. So\n> I expect even if we decided we could simply say \"no\" to new features\n> more often, with a static API we\'ll be releasing a new API version\n> every release for the forseable future - what sort of impact does that\n> have on deployers and users?\n\nThere\'s a difference between an API that does not have extensions and a\nstatic API. I am not describing a static API. I am describing an HTTP\ncontrol API that evolves over time with versioning. You know, just like\nthe EC2 API has -- dozens of times over the years. In fact, you will\nnote that new AWS EC2 API versions sometimes come out every two weeks.\nIs there some uproar when this happens? No. Developers just look at the\nversion changelog and documentation and go \"oh, hey, cool, new\nfunctionality.\"\n\n> I think this effect is magnified with continuous deployment. With a\n> static API and no ability to not immediately deploy an extension just\n> merged, do they have to have an API version bump every time an API\n> changing patch lands?\n\nI beg to differ. I would go so far as to say the existing API extension\nusage *hampers* deployers using a CD model. With a semver incremental\nAPI versioning system -- just like the one used for the Nova RPC API\nincidentally -- change is expected and appropriately discovered/handled.\nWith API extensions, it\'s just a mess of \"if extensionX.enabled do this,\nif extensionY.enabled do this\", etc.\n\nPlus, there\'s no accounting for dependencies between API extensions.\nCase in point: ever tried using the SimpleTenantUsage extension when the\nOS-SRV-USG extension isn\'t enabled? Don\'t bother. The first depends on\ndatabase schema changes that the latter introduces, but you\'d never know\nthat from the extension descriptor.\n\nHowever, you *would* be able to guard for that condition with\nincremental API versions, since the dependent OS-SRV-USG code would, by\nnature, have an earlier semver API version than the code that introduced\nthe SimpleTenantUsage calls.\n\n> And although we don\'t really have an official policy around it, I\n> think the API extension functionality has been used as a way of\n> allowing new functionality into Nova and evaluating it in place before\n> deciding whether or not it becomes a core part of Nova. \n\nI do understand this. But, I just think that it\'s mainly laziness that\ndrives this. Instead of doing the hard work of determining a useful API\nstructure ahead of time -- and validating that the new features actually\nfit the API audience -- it\'s just one more way of pushing immature or\nill-fitting code into a codebase.\n\nSorry for ranting.\n\nBest,\n-jay\n\n> Chris\n> \n> \n> \n>  \n>         -jay\n>         \n>         > ---\n>         > Ryan Petrello\n>         > Senior Developer, DreamHost\n>         > ryan.petrello at dreamhost.com\n>         >\n>         > On Jan 13, 2014, at 9:23 AM, Jay Pipes <jaypipes at gmail.com>\n>         wrote:\n>         >\n>         > > On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:\n>         > >> On my phone so will be very brief but perhaps the\n>         extensions extension\n>         > >> could publish the jsonschema(s) for the extension. I\n>         think the only\n>         > >> complicating  factor would be where extensions extend\n>         extensions but I\n>         > >> think it\'s all doable.\n>         > >\n>         > > Am I the only one that sees the above statement as another\n>         indication of\n>         > > why API extensions should eventually find their way into\n>         the dustbin of\n>         > > OpenStack history?\n>         > >\n>         > > -jay\n>         > >\n>         > >\n>         > >\n>         > > _______________________________________________\n>         > > OpenStack-dev mailing list\n>         > > OpenStack-dev at lists.openstack.org\n>         > >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CANCY3ecKnGBb8zXZ+kqfGMqXDwSh-xvu6h_irqwRk5RFd6E5HQ@mail.gmail.com>',NULL),('<1389676345.2210.137.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 00:12:25',-18000,'2014-01-14 05:12:25',NULL,'[openstack-dev] [nova] api schema validation pattern changes','On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote:\n> On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes <jaypipes at gmail.com>\n> wrote:\n>         \n>         We don\'t need API extensions and they make our Compute API\n>         laughably complex and cumbersome. We should ditch entirely the\n>         concept of API extensions in our next Compute API major\n>         release.\n> \n> I think it way too late in the cycle to make this sort of change for\n> the V3 API.\n\nCompletely agreed. I never said anything about v3. Specifically, in the\ntl;dr section I said \"in the next major API version\" we should get rid\nof API extensions.\n\n>         \n>         admin_actions -- seriously...why wouldn\'t pause/unpause, etc\n>         be part of\n>         the API? if some hypervisor doesn\'t support the action, then\n>         raise\n>         NotImplemented and return an HTTP 501 Not Implemented -- after\n>         all,\n>         that\'s what a 501 was designed for, and client tooling for\n>         HTTP APIs\n>         should understand that.\n> \n> \n> So interestingly the feedback we got at the HK design summit session\n> around admin_actions\n> is that we should split it up into multiple smaller extensions (and\n> this is going through\n> now). So deployers could more selectively deploy what they want to and\n> not include what\n> they don\'t want.\n\nIf it wasn\'t clear, I was not proposing changing anything to do with the\nexisting v3 API or any of the extensions. I am saying we should get rid\nof them for the next major version, which would be v4.\n\nBTW, I challenge you to find deployers that are clamouring for the\nability to \"selectively deploy\" some parts of the API and not\nothers...I\'d be happy to have conversations with these people and figure\nout what the real use cases are and what they\'re really after -- because\nI can almost guarantee it\'s not yet more API extensions.\n\n> > And although we don\'t really have an official policy around it, I\n> > think the API extension functionality has been used as a way of\n> > allowing new functionality into Nova and evaluating it in place\n> before\n> > deciding whether or not it becomes a core part of Nova.\n> \n> \n>         I do understand this. But, I just think that it\'s mainly\n>         laziness that\n>         drives this. Instead of doing the hard work of determining a\n>         useful API\n>         structure ahead of time -- and validating that the new\n>         features actually\n>         fit the API audience -- it\'s just one more way of pushing\n>         immature or\n>         ill-fitting code into a codebase.\n>         \n>         Sorry for ranting.\n> \n> \n> Ranting is fine with me :-) But if its something we wanted to do for\n> the V3 API we really should\n> \n> have had this sort of discussion at the *Havana* design summit.\n\nI\'ve brought up the problems before with API extensions numerous times,\nbut unfortunately, I haven\'t voiced enough concern over the last 18\nmonths or so, being lost a bit in ops-land. That said, I plan to\nvigorously argue for scrapping all API extensions in v4 at the Juno\nsummit. This practice has just gone on way too long...\n\n> FWIW I think we\'re getting a lot better at doing quality control on\n> APIs which are added.\n\nNo disagreement.\n\nBest,\n-jay\n\n\n\n\n','<CANCY3eecD1n4Vq=h0_UiOmeAi1JaNsovSR-6ycNo6dwC=Qvu1Q@mail.gmail.com>',NULL),('<1389708027.2210.138.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 09:00:27',-18000,'2014-01-14 14:00:27',NULL,'[openstack-dev] writing comments as complete sentences','On Tue, 2014-01-14 at 08:01 -0500, Doug Hellmann wrote:\n> Ned Batchelder had an interesting post a few days ago about why code\n> comments should be written as complete sentences, rather than\n> fragments. The main point is that with an unterminated phrase or\n> sentence fragment it isn\'t always clear that the thought has been\n> completed (i.e., maybe the full comment isn\'t even present in the\n> code). \n\n# Supported.\n\n-jay\n\n\n\n\n','<CADb+p3R_n36x5=UbWGb5+7O6vO5LRT596sp+ahNBBn43jSDjng@mail.gmail.com>',NULL),('<1389716983-sup-8015@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 09:21:00',-28800,'2014-01-14 17:21:00',NULL,'[openstack-dev] [heat] Sofware Config progress','Hey Steve, it has taken me about a month to get enough time to go\nthrough this. Thanks for doing it, comments in-line.\n\nExcerpts from Steve Baker\'s message of 2013-12-13 15:46:48 -0800:\n> I\'ve been working on a POC in heat for resources which perform software\n> configuration, with the aim of implementing this spec\n> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-spec\n> \n> The code to date is here:\n> https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z\n> \n> What would be helpful now is reviews which give the architectural\n> approach enough of a blessing to justify fleshing this POC out into a\n> ready to merge changeset.\n> \n> Currently it is possible to:\n> - create templates containing OS::Heat::SoftwareConfig and\n> OS::Heat::SoftwareDeployment resources\n> - deploy configs to OS::Nova::Server, where the deployment resource\n> remains in an IN_PROGRESS state until it is signalled with the output values\n> - write configs which execute shell scripts and report back with output\n> values that other resources can have access to.\n> \n> What follows is an overview of the architecture and implementation to\n> help with your reviews.\n> \n> REST API\n> ========\n> Like many heat resources, OS::Heat::SoftwareConfig and\n> OS::Heat::SoftwareDeployment are backed by \"real\" resources that are\n> invoked via a REST API. However in this case, the API that is called is\n> heat itself.\n> \n> The REST API for these resources really just act as structured storage\n> for config and deployments, and the entities are managed via the REST\n> paths /{tenant_id}/software_configs and /{tenant_id}/software_deployments:\n> <https://review.openstack.org/#/c/58878/7/heat/api/openstack/v1/__init__.py>https://review.openstack.org/#/c/58878/\n> RPC layer of REST API:\n> https://review.openstack.org/#/c/58877/\n> DB layer of REST API:\n> https://review.openstack.org/#/c/58876\n> heatclient lib access to REST API:\n> https://review.openstack.org/#/c/58885\n> \n> This data could be stored in a less structured datastore like swift, but\n> this API has a couple of important implementation details which I think\n> justify it existing:\n> - SoftwareConfig resources are immutable once created. There is no\n> update API to modify an existing config. This gives confidence that a\n> config can have a long lifecycle without changing, and a certainty of\n> what exactly is deployed on a server with a given config.\n> - Fetching all the deployments and configs for a given server is an\n> operation done repeatedly throughout the lifecycle of the stack, so is\n> optimized to be able to do in a single operation. This is called by\n> using the deployments index API call,\n> /{tenant_id}/software_deployments?server_id=<server_id>. The resulting\n> list of deployments include the their associated config data[1].\n>\n\nI\'m curious if we can use the existing Metadata for this. That would\nbe attractive to me, as that would keep the software deployments data\navailable to CFN-API based tools. For instance ohai can read the CFN\nAPI already, but not the Heat native in-instance API (since such a thing\nbasically does not exist).\n\nI\'m not suggesting they should both work at the same time. But I can\'t\nsee a time where they need to, so it seems logical enough to me to just\nhave the deployments bit populate the resource metadata, albeit with a\nbit more structure. I understand that means updating resource metadata\nafter booting the server which may be the very reason not having them be\nthe same thing is simpler.\n\n> OS::Heat::SoftwareConfig resource\n> =================================\n> OS::Heat::SoftwareConfig can be used directly in a template, but it may\n> end be more frequently used in a resource provider template which\n> provides a resource aimed at a particular configuration management tool.\n> http://docs-draft.openstack.org/79/58879/7/check/gate-heat-docs/911a250/doc/build/html/template_guide/openstack.html#OS::Heat::SoftwareConfig\n> The contents of the config property will depend on the CM tool being\n> used, but at least one value in the config map will be the actual script\n> that the CM tool invokes.  An inputs and outputs schema is also defined\n> here. The group property is used when the deployments data is actually\n> delivered to the server (more on that later).\n> \n\nCan you elaborate on \"the actual script that the CM tool invokes\" ?\n\nI have an extremely strong desire to never embed script code in an\norchestration template as it quickly becomes a quagmire of formatting\nproblems and poorly defined interfaces, IMO. Also my whole reason for\ndoing golden image based deployment is to have code all live in the\nimage and stay immutable through the deployed servers\' life time.\n\nSo I want to make sure I don\'t _have_ to do the script for some reason.\n\n> Since a config is immutable, any changes to a OS::Heat::SoftwareConfig\n> on stack update result in replacement.\n> \n> OS::Heat::SoftwareDeployment resource\n> =====================================\n> OS::Heat::SoftwareDeployment joins a OS::Heat::SoftwareConfig resource\n> with a OS::Nova::Server resource. It allows server-specific input values\n> to be specified that map to the OS::Heat::SoftwareConfig inputs schema.\n> Output values that are signaled to the deployment resource are exposed\n> as resource attributes, using the names specified in the outputs schema.\n> The OS::Heat::SoftwareDeployment resource remains in an IN_PROGRESS\n> state until it receives a signal (containing any outputs) from the server.\n> http://docs-draft.openstack.org/79/58879/7/check/gate-heat-docs/911a250/doc/build/html/template_guide/openstack.html#OS::Heat::SoftwareDeployment\n> \n> A deployment has its own actions and statuses that are specific to what\n> a deployment does, and OS::Heat::SoftwareDeployment maps this to heat\n> resource statuses and actions:\n> actions:\n> DEPLOY -> CREATE\n> REDEPLOY -> UPDATE\n> UNDEPLOY -> DELETE\n> \n> status (these could use some bikeshedding):\n> WAITING -> IN_PROGRESS\n> RECEIVED -> COMPLETE\n> FAILED -> FAILED\n> \n> In the config outputs schema there is a special flag for error_output.\n> If the signal response contains any value for any of these error_output\n> outputs then the deployment resource is put into the FAILED state.\n> \n> The SoftwareDeployment class subclasses SignalResponder which means that\n> a SoftwareDeployment creates an associated user and ec2 keypair. Since\n> the SoftwareDeployment needs to use the resource_id for the deployment\n> resource uuid, the user_id needs to be stored in resource-date instead.\n> This non-wip change enables that:\n> https://review.openstack.org/#/c/61902/\n> \n> During create, the deployment REST API is polled until status goes from\n> WAITING to RECEIVED. When handle_signal is called, the deployment is\n> updated via the REST API to set the status to RECEIVED (or FAILED),\n> along with any output values that were received.\n> \n> One alarming consequence of having a deployments API is that any tenant\n> user can create a deployment for any heat-created nova server and that\n> software will be deployed to that server, which is, um, powerful.\n> \n\nSeems like there is a whole policy can of worms there that all OpenStack\nservices probably need to address. AFAIK, any same-tenant user can just\ndelete any other user in the same tenant\'s servers, right? I\'m sure\nsomebody with Keystone knowledge (I\'m looking at you Mr. Hardy) would be\nable to tell us if such things exist now and whether or not we could\nmake a stronger bond between user and stack.\n\n> There will need to be a deployment policy (probably an OS::Nova::Server\n> property) which limits to scope of what deployments are allowed on that\n> server. This could default to deployments in the same stack, but could\n> still allow deployments from anywhere.\n> \n> OS::Nova::Server support\n> ========================\n> https://review.openstack.org/#/c/58880\n> A new user_data_format=SOFTWARE_CONFIG is currently used to denote that\n> this server is configured via software config deployments. Like\n> user_data_format=HEAT_CFNTOOLS, nova_utils.build_userdata is used to\n> build the cloud-init parts required to support software config. However\n> like user_data_format=RAW anything specified in user_data will be parsed\n> as cloud-init data. If user_data is multi-part data then the parts will\n> be appended to the parts created in nova_utils.build_userdata.\n> \n> The agent used currently is os-collect-config. This is typically\n> configured to poll for metadata from a particular heat resource via the\n> CFN API using the configured ec2 keypair. In the current implementation\n> the resource which is polled is the OS::Nova::Server itself, since this\n> is the only resource known to exist at server boot time (deployment\n> resources depend on server resources, so have not been created yet). The\n> ec2 keypair comes from a user created implicitly with the server\n> (similar to SignalResponder resources). This means the template author\n> doesn\'t need to include User/AccessKey/AccessPolicy resources in their\n> templates just to enable os-collect-config metadata polling.\n> \n\n\\o/\n\n> Until now, polling the metadata for a resource just returns the metadata\n> which has been stored in the stack resource database. This\n> implementation changes metadata polling to actually query the\n> deployments API to return the latest deployments data. This means\n> deployment state can be stored in one place, and there is no need to\n> keep various metadata stores updated with any changed state.\n> \n\nI do like that very much. :)\n\n> An actual template\n> ==================\n> http://paste.openstack.org/show/54988/\n> This template contains:\n> - a config resource\n> - 2 deployments which deploy that config with 2 different sets of inputs\n> - stack outputs which output the results of the deployments\n> - a server resource\n> - an os-refresh-config script delivered via cloud-config[2] which\n> executes config scripts with deployment inputs and signals outputs to\n> the provided webhook.\n\nYou have demonstrated exactly what I need here. One config definition, two\ndeployments of it on the same server with different parameters.  Huzzah!\n\nI\'m a little confused how the config.script gets access to $bar and $foo\nthough. ?\n\n> \n> /opt/stack/os-config-refresh/configure.d/55-heat-config-bash is a hook\n> specific for performing configuration via shell scripts, and only acts\n> on software config which has group=Heat::Shell. Each configuration\n> management tool will have its own hook, and will act on its own group\n> namespace. Each configuration management tool will also have its own way\n> of passing inputs and outputs. The hooks job is to invoke the CM tool\n> with the given inputs and script, then extract the outputs and signal heat.\n> \n> The server needs to have the CM tool and the hook already installed,\n> either by building a golden image or by using cloud-config during boot.\n> \n> Next steps\n> ==========\n> There is a lot left to do and I\'d like to spread the development load.\n> What happens next entirely depends on feedback to this POC, but here is\n> my ideal scenario:\n> - any feedback which causes churn on many of the current changes I will\n> address\n> - a volunteer is found to take the REST API/RPC/DB/heatclient changes\n> and make them ready to merge\n\nUsing this is a mid-term goal for me, but the Tuskar devs would probably\nlove to drop my old terrible merge.py and start working on translating\nthe TripleO templates to using this. So you will find a mid-term\nvolunteer in me, but you might find a sooner volunteer in them. :)\n\n> - we continue to discuss and refine the resources, the changes to\n> OS::Nova::Server, and the example shell hook\n> - volunteers write hooks for different CM tools, Chef and Puppet hooks\n> will need to be attempted soon to validate this approach.\n> \n> Vaguely related changes include:\n> - Some solution for specifying cloud-init config, either the intrinsic\n> functions or cloud-init heat resources\n> - Some heatclient file inclusion mechanism - writing that python hook in\n> a heat yaml template was a bit painful ;)\n\nThis has been an open question for a long time. Absent golden images, I\nthink you just need a simple way to express where to fetch the hooks from.\nThat could be hidden behind the SoftwareConfig resource so that the url\nhas a default where the cloud operator has put tools. Users could then\njust override that url when they want to write their own hooks.\n\n> \n> Trying for yourself\n> ===================\n> - Using diskimage-builder, create an ubuntu image with\n> tripleo-image-elements os-apply-config, os-refresh-config and\n> os-collect-config\n> - Create a local heat branch containing\n> https://review.openstack.org/#/q/topic:bp/cloud-init-resource,n,z and\n> https://review.openstack.org/#/q/topic:bp/hot-software-config,n,z\n> - launch the above template with your created image\n> \n\nAt the time you sent this I think I got this working.\n\nVery excited to help move this forward as much as I can.\n\n\n','<52AB9C68.2040002@redhat.com>',NULL),('<1389720190-sup-3923@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 09:59:36',-28800,'2014-01-14 17:59:36',NULL,'[openstack-dev] [heat] Sofware Config progress','Excerpts from Prasad Vellanki\'s message of 2014-01-13 23:23:15 -0800:\n> On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake <sdake at redhat.com> wrote:\n> \n> > that\n> \n> \n> Steve\n> Thanks for detailed email. Apologize for the delayed response but we have\n> been thinking about how does software config fit into configuring network\n> and service function devices. I agree with you that in general it is best\n> to get appliance vendors to put cloudinit into their images and thus get on\n> board with what every cloud is doing. I thought I would get some feedback\n> on the direction of Heat for configuring network devices and appliances.\n> \n> I am thinking there are few things to consider for configuring Network and\n> Network Service devices/Virtual Appliances.\n> \n> Neutron APIs along with the service APIs provide a way to configure network\n> devices by abstracting the APIs and have a plugin model for individual\n> devices. These APIs include Neutron core apis, Service API such as LBaaS,\n> FWaaS, VPNaaS. Though these are currently for physical devices, there is a\n> movement towards configuring Virtual Appliances too. These APIs will be\n> addressed via Heat Neutron resources.\n> \n> While *aaS do address configuring the supported service, they do not\n> address the bootstrapping of the device. Generally for most devices\n> bootstrapping is done via rest API and/or SSH. And for unsupported\n>  services that do not have these APIs one needs to use custom way to\n> configure where Heat can really help.  Bootstrapping includes installing\n> licences, configuring admin password, upgrade software  and some with more\n> than that. For this our thought is it would be great to have  Heat software\n> config/deployment do bootstrapping, upgrade etc.\n> \n\nI think what you need is a very small service VM that does this\nbootstrapping. We don\'t want the heat engine reaching into VMs directly.\nSo what you would want to do is have a service VM which SSH\'s in, or hits\nthose REST API\'s. Now, if one of those REST API\'s is stable enough that\nyour cloud provider _does_ want to be able to hit it, they can write a\nresource plugin and provide that.\n\nI think it might be cool to have a Heat resource which is just a server\nthat is deleted as soon as it signals a wait condition. That would enable\nthese sort of \"external bootstrap\" things quite nicely without costing\nusers or requiring them to remove the server definition after creating\nthe stack.\n\n\n','<CADstcNZjXjGgaYG1=wa=N6cW_XVs3SWEAOjsT+Q92=4Dshb8UQ@mail.gmail.com>',NULL),('<1389759593-sup-119@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 20:27:49',-28800,'2014-01-15 04:27:49',NULL,'[openstack-dev] [heat] Sofware Config progress','Excerpts from Prasad Vellanki\'s message of 2014-01-14 18:41:46 -0800:\n> Steve\n> \n> I did not mean to have custom solution at all. In fact that would be\n> terrible.  I think Heat model of software config and deployment is really\n> good. That allows configurators such as Chef, Puppet, Salt or Ansible to be\n> plugged into it and all users need to write are modules for those.\n> \n> What I was  thinking is if there is a way to use software config/deployment\n>  to do initial configuration of the appliance by using agentless system\n> such  as Ansible or Salt, thus requiring no cfminit. I am not sure this\n> will work either, since it might require ssh keys to be installed for\n> getting ssh to work without password prompting. But I do see that ansible\n> and salt support username/password option.\n> If this would not work, I agree that the best option is to make them\n> support cfminit...\n\nAnsible is not agent-less. It just makes use of an extremely flexible\nagent: sshd. :) AFAIK, salt does use an agent though maybe they\'ve added\nSSH support.\n\nAnyway, the point is, Heat\'s engine should not be reaching into your\nmachines. It talks to API\'s, but that is about it.\n\nWhat you really want is just a VM that spins up and does the work for\nyou and then goes away once it is done.\n\n\n','<CADstcNbB35adMfiL+KEUvrUX6gzPa8U8DyqH4KL=Ap5fcFt+6A@mail.gmail.com>',NULL),('<1389768634-sup-1734@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-14 23:08:00',-28800,'2014-01-15 07:08:00',NULL,'[openstack-dev] [TripleO] [Tuskar] Deployment Management\n	section - Wireframes','Excerpts from Vitaly Kramskikh\'s message of 2014-01-14 12:35:43 -0800:\n> Hi Jaromir,\n> \n> 2014/1/13 Jaromir Coufal <jcoufal at redhat.com>\n> \n> > So what we can do at the moment (until there is some way to specify which\n> > node to remove) is to inform user, which nodes were removed in the end...\n> > at least.\n> >\n> > In the future, I\'d like to enable user to have both ways available - just\n> > decrease number and let system to decide which nodes are going to be\n> > removed for him (but at least inform in advance which nodes are the chosen\n> > ones). Or, let user to choose by himself.\n> >\n> \n> I think the functionality to choose which node is allocated for each role\n> is needed to. I didn\'t realize how/if it is possible from the wireframes.\n> \n> For example, I have 3 racks. I want to allocate 1 node from each rack for\n> Controller and make other nodes Computes and then make each rack a separate\n> availability zone. In this case I need to specify which exact node will\n> become Controller.\n> \n> Is it possible to do this?\n> \n\nI think you can do it with rudimentary anti-affinity and affinity rules\nin Nova now. However I believe this would be supported by the instance\ngrouping spec:\n\nhttps://blueprints.launchpad.net/nova/+spec/instance-group-api-extension\n\nThere is also a Tuskar specific blueprint about this that I think would\nbuild on top of the instance grouping.\n\nhttps://blueprints.launchpad.net/nova/+spec/grouping-baremetal-nodes-for-scheduling\n\nI think that this may have to end up in the Ironic scheduler, as nova\ncompute nodes will potentially have many baremetal nodes. So a request\nwill land in Ironic that specifies a desire for a node \"not in group\nrack_1\" or \"in group rack_5\".\n\n\n','<CABX1ep6LWKvbq32JB=HNf7_DCPtk=9JpiMu0gjZ7t5dvZ8OJgg@mail.gmail.com>',NULL),('<1389807590.2348.49.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-15 12:39:50',-18000,'2014-01-15 17:39:50',NULL,'[Openstack-docs] Copyright statements in docs source files','On Tue, 2014-01-14 at 13:30 -0500, Rich Bowen wrote:\n> I\'ve actually had people ask me, when looking at files like this, if \n> they have to ask the author for permission to submit patches against \n> that file. If we can avoid making people even think that thought, we\'ve \n> done a good thing for the community.\n> \n> See also \n> http://producingoss.com/en/managing-volunteers.html#territoriality for \n> another take on this issue, just in case Karl\'s voice carries more \n> weight than mine.\n\nCurious. In GNOME, documents always carry full attribution and copyright\ninformation, and I\'ve never seen it be a deterrent to anybody working on\nthem. On the contrary, I\'ve found that letting people claim credit for\ntheir work can be a powerful motivator.\n\n--\nShaun\n\n\n\n\n\n','<52D58244.9010405@redhat.com>',NULL),('<1389809049-sup-6395@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 10:38:34',-28800,'2014-01-15 18:38:34',NULL,'[openstack-dev] [TripleO] [Tuskar] Deployment Management\n	section - Wireframes','Excerpts from Jaromir Coufal\'s message of 2014-01-15 02:05:52 -0800:\n> > 1) Check for an already deleted server before deleting any. This is\n> > related to stack convergence:\n> >\n> > https://blueprints.launchpad.net/heat/+spec/stack-convergence\n> >\n> > This will allow users to just delete a server they want to delete,\n> > and then update the template to reflect reality.\n> >\n> > 2) Allow resources to be marked as critical or disposable. Critical\n> > resources would not ever be deleted for scaling purposes or during\n> > updates. An update would fail if there were no disposable resources.\n> > Scaling down would just need to be retried at this point.\n> >\n> > With those two things, TripleO can make the default \"disposable\" for\n> > stateless resources, and \"critical\" for stateful resources. Tuskar would\n> > just report on problems in managing the Heat stack. Admins can then\n> > control any business cases for evacuations/retirement of workloads/etc\n> > for automation purposes.\n> This is nice feature, though it looks post-I business. I would focus \n> more on 1) at the moment. But it\'s good direction.\n> \n\n(2) is definitely a feature that we\'d have to propose and flesh out for\nJuno. I think it would solve a lot of the problems with auto scaling and\nallow it to work for workloads other than stateless app servers. I am not\nsure if it fits in with the autoscaling work that has been ongoing. Also\nI think we can live without it indefinitely, _if_ we can accept the scary\npart of the heat template size/count being a veritable \"Sword of Damacles\"\nhanging over the head of the resources in the group.\n\nFor (1), I think anything that does not follow the path of least surprise\nis a bug. The way reducing count/size of groups works now is a surprise\nif users have manually deleted resources already. So I filed (1) from\nabove as a bug:\n\nhttps://bugs.launchpad.net/heat/+bug/1269534\n\nThis should be a relatively simple fix, where the update just does a\ncheck_active on all of the resources that should exist, and if any don\'t,\nthen reduces the count of active resources. This flips the logic a bit\n(right now we check the count and template, and then reduce), but I\nthink we can at least _try_ to get this for I3. It also fits in with\nthe convergence blueprint which has been accepted for icehouse (but I\ndon\'t know if any work has been completed). I linked the bug to said\nblueprint.\n\n> > Eventually perhaps we could use Mistral to manage that, but for now,\n> > I think just being able to protect and manually delete important nodes\n> > for scale down is enough. Perhaps Tuskar could even pop up a dialog\n> > showing them and allowing manual selection.\n> Clint, this is exactly what I was asking for and thank you for bringing \n> this up. It would be awesome if we can do it. But I was told that this \n> is not very well possible with current TripleO approach.\n> \n> So my question is - when scaling down, are we able to show user a list \n> of participating nodes, let him select which nodes he wants to remove \n> and update the template to reflect the reality then? All in Icehouse \n> timeframe...?\n> \n\nFor Icehouse Tuskar should probably just focus on generating templates\nfor \"NovaCompute%d\" the way it does now, and then giving users a way to\nchoose which of those to terminate. If we can get that bug fixed though,\nthen Tuskar could just nova delete the selected servers and then update\nthe size of an instance group in Heat.\n\n\n','<52D65D80.2060303@redhat.com>',NULL),('<1389811471-sup-7452@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 10:49:04',-28800,'2014-01-15 18:49:04',NULL,'[openstack-dev] [Ironic] [TripleO] [Tuskar] Deployment\n	Management section - Wireframes','Excerpts from Ji?? Str?nsk?\'s message of 2014-01-13 07:45:53 -0800:\n> On 13.1.2014 11:43, Jaromir Coufal wrote:\n> > On 2014/10/01 21:17, Jay Dobies wrote:\n> >> Another question:\n> >>\n> >> - A Role (sounds like we\'re moving away from that so I\'ll call it\n> >> Resource Category) can have multiple Node Profiles defined (assuming I\'m\n> >> interpretting the + and the tabs in the Create a Role wireframe\n> >> correctly). But I don\'t see anywhere where a profile is selected when\n> >> scaling the Resource Category. Is the idea behind the profiles that you\n> >> can select how much power you want to provide in addition to how many\n> >> nodes?\n> >\n> > Yes, that is correct, Jay. I mentioned that in walkthrough and in\n> > wireframes with the note \"More views needed (for deploying, scaling,\n> > managing roles)\".\n> >\n> > I would say there might be two approaches - one is to specify which node\n> > profile you want to scale in order to select how much power you want to add.\n> >\n> > The other approach is just to scale the number of nodes in a role and\n> > let system decide the best match (which node profile is chosen will be\n> > decided on the best fit, probably).\n> \n> Hmm i\'m not sure i understand - what do you think by \"best fit\" here? \n> E.g. i have 32 GB RAM profile and 256 GB RAM profile in the compute role \n> (and i have unused machines available for both profiles), and i increase \n> compute node count by 2. What do i best-fit against?\n> \n\nCurrently nova-baremetal enforces an _exact_ match scheduler. So if we\nhave two nodes, 32G and 256G, and we try to create two servers in Nova\nwith the flavor that has 32G defined for RAM, Nova will fail to deploy\nour second server.\n\n> (Alternatively, if we want to support scaling a role using just one \n> spinner, even though the role has more profiles, maybe we could pick the \n> \"largest\" profile with unused nodes available?)\n> \n> >\n> > I lean towards the first approach, where you specify what role and which\n> > node profile you want to use for scaling. However this is just\n> > introduction of the idea and I believe we can get answers until we get\n> > to that step.\n> \n> +1. I think we\'ll want the first approach to be at least possible (maybe \n> not default). As a cloud operator, when i want deploy 2 more compute \n> nodes, i imagine there are situations when i do care whether i\'ll get \n> additional 64 GB or additional 512 GB capacity.\n> \n\nI believe Ironic will eventually have a different scheduler available\nwhich may help with this. However, until then we just have to have a\nflavor definition for every flavor of hardware that we want to address\ndifferently. Note that the GB in the baremetal nodes pool is just a\nnumber. One can certainly _say_ a box has 32G when it has 512G, and it\nwill go into the same pool.\n\n\n','<52D40A31.5010608@redhat.com>',NULL),('<1389811888-sup-9328@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 11:01:22',-28800,'2014-01-15 19:01:22',NULL,'[openstack-dev] [TripleO] [Tuskar] Deployment Management\n	section - Wireframes','Excerpts from Walls, Jeffrey Joel (Cloud OS R&D)\'s message of 2014-01-15 07:04:48 -0800:\n> > -----Original Message-----\n> > From: James Slagle [mailto:james.slagle at gmail.com]\n> > Sent: Wednesday, January 15, 2014 5:52 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management\n> > section - Wireframes\n> \n> > This does not seem quite right to me.  I don\'t think we want to be\n> > enabling or disabling different services in images at deployment time.\n> > That\'s one of the reasons that we have the element nature of\n> > diskimage-builder, so that you can build an image with the software\n> > components you want. Any service that you include in the image build\n> > is automatically enabled. If you want that image with a service\n> > disabled, you build a new image.\n> \n> I don\'t necessarily disagree with this assertion, but what this could\n> lead to is a proliferation of a bunch of very similar images.  Templatizing\n> some of the attributes (e.g., this package is enabled, that one isn\'t)\n> can reduce the potential explosion of images stored in glance.  If that\'s\n> a concern, then it needs to be addressed.  Note that this is true whether\n> tuskar does/helps with the image building or not.\n> \n\nWe have quite a proliferation of services already:\n\nhttp://docs.openstack.org/training-guides/content/figures/5/figures/image31.jpg\n\nRealistically, the number of individual services on that diagram (I\nrapidly counted 39.. I bet I\'m off) are the maximum number of image\ncontents we should ever have in a given deployment. Well plus heat which\nis two more. And maybe Trove.. and Designate.. Ok so lets say \"50\".\n\nOf course, users might recombine every service with every other service\nover the life-cycle of their deployment, but realistically, that might\nlead to _100_ individual image definitions in service at one time while\nnew topologies are being rolled out.\n\nI\'m o-k with that kind of proliferation. It is measurable and\ncontrollable. Also it is crazy. Realistically we\'re going to see maybe\n10 definitions.. controllers.. computes.. blocks.. swifts.. and some\nsupporting things.\n\nThe positive trade there is that we don\'t have to wonder how a box has\nchanged since it was deployed. It is always running all of the software\nwe deployed to it, with the config we defined now, or it is in an\nerror state.\n\n\n','<5201E6AC0320A04B9C7D63F19055FED850BA05AE@G4W3299.americas.hpqcorp.net>',NULL),('<1389816709.131.1365919625942.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-14 06:07:05',0,'2013-04-14 06:07:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #4','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/4/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-14 06:07:01    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:07:01,555 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-14 06:07:01,556 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:07:01,557 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,558 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,559 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-14 06:07:01,560 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-14 06:07:01,561 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-14 06:07:01  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-14 06:07:01,562 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:07:01    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-14 06:07:01,563 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,568 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.567893\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.567893\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01,569 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,570 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,570 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,572 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01,573 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.572311\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.572311\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01,574 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,575 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,576 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:07:01,577 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,577 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,579 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01,580 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.579380\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.579380\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01,581 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,582 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,583 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:07:01,583 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,584 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,586 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01,587 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.586252\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.586252\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01,588 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,589 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,590 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:07:01,590 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,591 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,593 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-14 06:07:01,595 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-14 06:07:01,595 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.594897\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-14T06:07:01.594897\', resource_metadata={}) from 0 transformer\n2013-04-14 06:07:01,596 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,597 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01,598 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-14 06:07:01,599 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-14 06:07:01,600 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-14 06:07:01    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.773s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.4\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a45.g4bf4390\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a308.g497b423\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.45jgDt0oQV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/4\n[SCP] Copying console log.\n\n\n','<157614606.115.1365833326029.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1389822313.5972.1.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 16:45:13',-18000,'2014-01-15 21:45:13',NULL,'[openstack-dev] a \"common\" client library','On Wed, 2014-01-15 at 14:37 -0500, Doug Hellmann wrote:\n> Several people have mentioned to me that they are interested in, or\n> actively working on, code related to a \"common\" client library --\n> something meant to be reused directly as a basis for creating a common\n> library for all of the openstack clients to use. There\'s a blueprint\n> [1] in oslo, and I believe the keystone devs and unified CLI teams are\n> probably interested in ensuring that the resulting API ends up meeting\n> all of our various requirements.\n> \n> If you\'re interested in this effort, please subscribe to the blueprint\n> and use that to coordinate efforts so we don\'t produce more than one\n> common library. ;-)\n\n++ on the effort. I did notice, however, that neutronclient is\nconspicuously absent from the Work Items in the blueprint\'s Whiteboard.\nIs there a reason for this, or just a mistaken omission?\n\nBest,\n-jay\n\n\n\n\n','<CADb+p3T2Az9iVLs8QMhqDU=0itgUVwP1jL6TZ23GmfUCcvoPJg@mail.gmail.com>',NULL),('<1389824099-sup-7443@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 14:28:37',-28800,'2014-01-15 22:28:37',NULL,'[openstack-dev] [TripleO][Tuskar] Editing Nodes','Excerpts from James Slagle\'s message of 2014-01-15 05:07:08 -0800:\n> I\'ll start by laying out how I see editing or updating nodes working\n> in TripleO without Tuskar:\n> \n> To do my initial deployment:\n> 1.  I build a set of images for my deployment for different roles. The\n> images are different based on their role, and only contain the needed\n> software components to accomplish the role they intend to be deployed.\n> 2.  I load the images into glance\n> 3.  I create the Heat template for my deployment, likely from\n> fragments that are already avaiable. Set quantities, indicate which\n> images (via image uuid) are for which resources in heat.\n> 4.  heat stack-create with my template to do the deployment\n> \n> To update my deployment:\n> 1.  If I need to edit a role (or create a new one), I create a new image.\n> 2.  I load the new image(s) into glance\n> 3.  I edit my Heat template, update any quantities, update any image uuids, etc.\n> 4.  heat stack-update my deployment\n> \n> In both cases above, I see the role of Tuskar being around steps 3 and 4.\n> \n\nAgreed!\n\nSteps 1 and 2 are really CI\'s responsibility in a CD cloud. The end of\nthe testing phase is \"new images in glance!\" For a stable release cloud,\na tool for pulling new released images from elsewhere into Glance would\nbe really useful, but worst case an admin downloads the new images and\nloads them manually.\n\n> I may be misinterpreting, but let me say that I don\'t think Tuskar\n> should be building images. There\'s been a fair amount of discussion\n> around a Nova native image building service [1][2]. I\'m actually not\n> sure what the status/concensus on that is, but maybe longer term,\n> Tuskar might call an API to kick off an image build.\n> \n\nTuskar should just deploy what it has available. I definitely could\nsee value in having an image updating service separate from Tuskar,\nbut I think there are many different answers for \"how do images arrive\nin Glance?\".\n\n> Ok, so given that frame of reference, I\'ll reply inline:\n> \n> On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies <jason.dobies at redhat.com> wrote:\n> > I\'m pulling this particular discussion point out of the Wireframes thread so\n> > it doesn\'t get lost in the replies.\n> >\n> > = Background =\n> >\n> > It started with my first bulletpoint:\n> >\n> > - When a role is edited, if it has existing nodes deployed with the old\n> > version, are the automatically/immediately updated? If not, how do we\n> > reflect that there\'s a difference between how the role is currently\n> > configured and the nodes that were previously created from it?\n> \n> I would think Roles need to be versioned, and the deployed version\n> recorded as Heat metadata/attribute. When you make a change to a Role,\n> it\'s a new version. That way you could easily see what\'s been\n> deployed, and if there\'s a newer version of the Role to deploy.\n> \n\nCould Tuskar version the whole deployment, but only when you want to\n\"make it so\" ? If it gets too granular, it becomes pervasive to try and\nkeep track of or to roll back. I think that would work well with a goal\nI\'ve always hoped Tuskar would work toward which would be to mostly just\nmaintain deployment as a Heat stack that nests the real stack with the\nparameters realized. With Glance growing Heat template storage capability,\nyou could just store these versions in Glance.\n\n> > Replies:\n> \n> I know you quoted the below, but I\'ll reply here since we\'re in a new thread.\n> \n> > \"I would expect any Role change to be applied immediately. If there is some\n> > change where I want to keep older nodes how they are set up and apply new\n> > settings only to new added nodes, I would create new Role then.\"\n> \n> -1 to applying immediately.\n> \n> When you edit a Role, it gets a new version. But nodes that are\n> deployed with the older version are not automatically updated.\n> \n> > \"We will have to store image metadata in tuskar probably, that would map to\n> > glance, once the image is generated. I would say we need to store the list\n> > of the elements and probably the commit hashes (because elements can\n> > change). Also it should be versioned, as the images in glance will be also\n> > versioned.\n> \n> I\'m not sure why this image metadata would be in Tuskar. I definitely\n> like the idea of knowing the versions/commit hashes of the software\n> components in your images, but that should probably be in Glance.\n> \n\nGlance is also growing more capabilities to store metadata and be\nsearchable. Tuskar doesn\'t need to reinvent this any more than Murano\nor Heat do.\n\n> > We can\'t probably store it in the Glance, cause we will first store the\n> > metadata, then generate image. Right?\n> \n> I\'m not sure I follow this point. But, mainly, I don\'t think Tuskar\n> should be automatically generating images.\n> \n> > Then we could see whether image was created from the metadata and whether\n> > that image was used in the heat-template. With versions we could also see\n> > what has changed.\n> \n> We\'ll be able to tell what image was used in the heat template, and\n> thus the deployment,  based on it\'s UUID.\n> \n> I love the idea of seeing differences between images, especially\n> installed software versions, but I\'m not sure that belongs in Tuskar.\n> That sort of utility functionality seems like it could apply to any\n> image you might want to launch in OpenStack, not just to do a\n> deployment.  So, I think it makes sense to have that as Glance\n> metadata or in Glance somehow. For instance, if I wanted to launch an\n> image that had a specific version of apache, it\'d be nice to be able\n> to see that when I\'m choosing an image to launch.\n> \n> > But there was also idea that there will be some generic image, containing\n> > all services, we would just configure which services to start. In that case\n> > we would need to version also this.\n> \n> -1 to this.  I think we should stick with specialized images per role.\n> I replied on the wireframes thread, but I don\'t see how\n> enabling/disabling services in a prebuilt image should work. Plus, I\n> don\'t really think it fits with the TripleO model of having an image\n> created based on it\'s specific \"role\" (I hate to use that term and\n> muddy the water....i mean in the generic sense here).\n> \n\nA generic image just requires more state management and configuration.\nThat seems like a net loss in efficiency, as both of those things move\nfailure modes into production instead of keeping them firmly rooted in\ntest/dev.\n\n<snip>\n\n> > - For the comment on a generic image with service configuration, the first\n> > thing that came to mind was the thread on creating images from packages [1].\n> > It\'s not the exact same problem, but see Clint Byrum\'s comments in there\n> > about drift. My gut feeling is that having specific images for each res-cat\n> > will be easier to manage than trying to edit what services are running on a\n> > node.\n> \n> +1.\n> \n\nPerhaps obviously, +1 as well. :)\n\n\n','<CAHV77z8n64KgxXrGP0+u5bqcv216ZY2yTMpGHikvpH=ULkFOfg@mail.gmail.com>',NULL),('<1389824490.5972.2.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 17:21:30',-18000,'2014-01-15 22:21:30',NULL,'[openstack-dev] [rally] Naming of a deployment','On Wed, 2014-01-15 at 21:46 +0000, Hugh Saunders wrote:\n> On 15 January 2014 21:14, Ilya Kharin <ikharin at mirantis.com> wrote:\n> \n>         Hi, guys,\n>         \n>         In Rally there is an entity that represents installed instance\n>         of OpenStack. \n>         What you think about a proper name for the entity? (a\n>         Deployment, a Cluster, an Installation, an Instance or\n>         something else)\n>  \n> I vote for Deployment. \n\n++\n\nBest,\n-jay\n\n\n\n\n','<CAAD+Y3VR1OiiE_7yGQUAbd_8G9X-MdQb1B=5umMbC7GpM3vqbA@mail.gmail.com>',NULL),('<1389825202-sup-9949@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 14:34:37',-28800,'2014-01-15 22:34:37',NULL,'[openstack-dev] [Nova] why don\'t we deal with \"claims\" when\n	live migrating an instance?','Hi Chris. Your thread may have gone unnoticed as it lacked the Nova tag.\nI\'ve added it to the subject of this reply... that might attract them.  :)\n\nExcerpts from Chris Friesen\'s message of 2014-01-15 12:32:36 -0800:\n> When we create a new instance via _build_instance() or \n> _build_and_run_instance(), in both cases we call instance_claim() to \n> reserve and test for resources.\n> \n> During a cold migration I see us calling prep_resize() which calls \n> resize_claim().\n> \n> How come we don\'t need to do something like this when we live migrate an \n> instance?  Do we track the hypervisor overhead somewhere in the instance?\n> \n> Chris\n> \n\n\n','<52D6F064.6090707@windriver.com>',NULL),('<1389849805-sup-8408@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 21:25:06',-28800,'2014-01-16 05:25:06',NULL,'[openstack-dev] Proposal for dd disk i/o performance blueprint\n	of cinder.','Excerpts from Alan Kavanagh\'s message of 2014-01-15 19:11:03 -0800:\n> Hi Paul\n> \n> I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) \" a tenant can not read another tenants disk......\" the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction so that no ghost images  or file retrieval is possible?\n> \n\nIs that really a path worth going down, given that tenant-A could just\ndrop evil firmware in any number of places, and thus all tenants afterward\nare owned anyway?\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E5BCEF8@eusaamb109.ericsson.se>',NULL),('<1389884284.2174.0.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 09:58:04',-18000,'2014-01-16 14:58:04',NULL,'[openstack-dev] [neutron] [third-party-testing]\n	Sharing	information','On Thu, 2014-01-16 at 10:39 +0000, Sullivan, Jon Paul wrote:\n> > -----Original Message-----\n> > From: Kyle Mestery [mailto:mestery at siliconloons.com]\n> > Sent: 15 January 2014 22:53\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [neutron] [third-party-testing] Sharing\n> > information\n> > \n> > FYI, here [1] are the meeting logs from today?s meeting.\n> > \n> > A couple of things have become apparent here:\n> > \n> > 1. No one has a working Neutron 3rd party testing rig yet which is\n> > voting\n> >     consistently. If I?ve missed something, please, someone correct me.\n> > 2. People are still hung on issues around Jenkins/gerrit integration.\n> \n> This issue can be very easily resolved if people were to use Jenkins Job Builder [2] for the creation of their Jenkins testing jobs.  This would allow the reuse of simple macros already in existence to guarantee correct configuration of Jenkins jobs at 3rd party sites.  This would also allow simple reuse of the code used by the infra team to create the openstack review and gate jobs, ensuring 3rd party testers can generate the correct code from the gerrit change and also publish results back in a standard way.\n> \n> I can\'t recommend Jenkins Job Builder highly enough if you use Jenkins.\n> \n> [2] https://github.com/openstack-infra/jenkins-job-builder\n\n++ It\'s a life-saver. We used it heavily in AT&T with our\nGerrit/Jenkins/Zuul CI system.\n\n-jay\n\n> > 3. There are issues with devstack failing, but these seem to be Neutron\n> >     plugin specific. I?ve encouraged people to reach out on both the\n> >     #openstack-neutron and #openstack-qa channels with questions.\n> > 4. There is still some confusion on what tests to run. I think this is\n> >     likely to be plugin dependent.\n> > 5. There is some confusion around what version of devstack to use.\n> >     My assumption has always been upstream master.\n> > \n> > Another general issue which I wanted to highlight here, which has been\n> > brought up before, is that for companies/projects proposing plugins,\n> > MechanismDrivers, and/or service plugins you really need someone active\n> > on both the mailing list as well as the IRC channels. This will help if\n> > your testing rig has issues, or if people need help understanding why\n> > your test setup is failing with their patch.\n> > \n> > So, that?s the Neutron 3rd party testing update as we near the deadline\n> > next week.\n> > \n> > Thanks!\n> > Kyle\n> > \n> > [1]\n> > http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2\n> > 014/networking_third_party_testing.2014-01-15-22.00.log.html\n> > \n> > On Jan 14, 2014, at 10:34 AM, Kyle Mestery <mestery at siliconloons.com>\n> > wrote:\n> > \n> > > Given the Tempest Sprint in Montreal, I still think we should have\n> > > this meeting on IRC. So, lets nail down the time as 2200 UTC on\n> > > #openstack-meeting-alt for tomorrow. If you can?t make it, I?ll send\n> > the meeting logs out.\n> > >\n> > > Thanks, look forward to seeing people there tomorrow!\n> > >\n> > > Kyle\n> > >\n> > > On Jan 14, 2014, at 9:49 AM, Lucas Eznarriaga <lucas at midokura.com>\n> > wrote:\n> > >\n> > >> Hi,\n> > >> I will also be available for a meeting tomorrow.\n> > >> @Mohammad, we are still working on our 3rd party testing setup so do\n> > not take Midokura CI Bot votes too seriously yet.\n> > >> So far I have followed the links on the etherpad to have the\n> > jenkins+gerrit trigger plugin working with the current setup that\'s what\n> > I haven\'t added anything else yet.\n> > >>\n> > >> Cheers,\n> > >> Lucas\n> > >>\n> > >>\n> > >>\n> > >> On Tue, Jan 14, 2014 at 3:55 PM, Edgar Magana <emagana at plumgrid.com>\n> > wrote:\n> > >> I like it and I am in favor.\n> > >> Some of us, will be in Montreal attending the sprint tempest session.\n> > Hopefully we can all take it from there.\n> > >>\n> > >> Edgar\n> > >>\n> > >>> On Jan 14, 2014, at 6:31 AM, Kyle Mestery <mestery at siliconloons.com>\n> > wrote:\n> > >>>\n> > >>> Thanks for sending this note Mohammad. I am all in favor of another\n> > >>> 3rd party testing meeting on IRC. How about if we shoot for\n> > >>> tomorrow, Wednesday the 15, at 2200 UTC? Please ack if that works\n> > for everyone.\n> > >>>\n> > >>> Thanks,\n> > >>> Kyle\n> > >>>\n> > >>>> On Jan 13, 2014, at 5:08 PM, Mohammad Banikazemi <mb at us.ibm.com>\n> > wrote:\n> > >>>>\n> > >>>> Hi everybody,\n> > >>>>\n> > >>>> I see that we already have at least two 3rd party testing setups\n> > (from Arista and Midokura) up and running. Noticed their votes on our\n> > newly submitted plugin.\n> > >>>> The etherpad which is to be used for sharing information about\n> > setting up 3rd party testing (as well as multi-node testing) [1] seems\n> > to have not been updated recently. Would those who have setup their 3rd\n> > party testing successfully be willing to share more information as to\n> > what they have done and possibly update the etherpad?\n> > >>>>\n> > >>>> Would it be of value to others if we have another IRC meeting to\n> > discuss this matter?\n> > >>>> (Kyle, I am sure you are busy so I took the liberty to send this\n> > >>>> note. Please let us know what you think.)\n> > >>>>\n> > >>>> Thanks,\n> > >>>>\n> > >>>> Mohammad\n> > >>>>\n> > >>>>\n> > >>>> [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest\n> > >>>>\n> > >>>> <graycol.gif>Kyle Mestery ---12/19/2013 09:17:44 AM---Apologies\n> > folks, I meant 2200 UTC Thursday. We\'ll still do the meeting today.\n> > >>>>\n> > >>>> From:    Kyle Mestery <mestery at siliconloons.com>\n> > >>>> To:    \"OpenStack Development Mailing List \\(not for usage\n> > questions\\)\" <openstack-dev at lists.openstack.org>,\n> > >>>> Date:    12/19/2013 09:17 AM\n> > >>>> Subject:    Re: [openstack-dev] [neutron] [third-party-testing]\n> > Reminder:    Meeting tomorrow\n> > >>>>\n> > >>>>\n> > >>>>\n> > >>>> Apologies folks, I meant 2200 UTC Thursday. We\'ll still do the\n> > >>>> meeting today.\n> > >>>>\n> > >>>>> On Dec 18, 2013, at 4:40 PM, Don Kehn <dekehn at gmail.com> wrote:\n> > >>>>>\n> > >>>>> Wouldn\'t 2200 UTC be in about 20 mins?\n> > >>>>>\n> > >>>>>\n> > >>>>> On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA <oda at valinux.co.jp>\n> > wrote:\n> > >>>>> Hi,\n> > >>>>>\n> > >>>>> It seems the meeting was not held on 2200 UTC on Wednesday\n> > (today).\n> > >>>>>\n> > >>>>> Do you mean 2200 UTC on Thursday ?\n> > >>>>>\n> > >>>>> Thanks.\n> > >>>>>\n> > >>>>> On Thu, 12 Dec 2013 11:43:03 -0600 Kyle Mestery\n> > >>>>> <mestery at siliconloons.com> wrote:\n> > >>>>>\n> > >>>>>> Hi everyone:\n> > >>>>>>\n> > >>>>>> We had a meeting around Neutron Third-Party testing today on IRC.\n> > >>>>>> The logs are available here [1]. We plan to host another meeting\n> > >>>>>> next week, and it will be at 2200 UTC on Wednesday in the\n> > >>>>>> #openstack-meeting-alt channel on IRC. Please attend and update\n> > >>>>>> the etherpad [2] with any items relevant to you before then.\n> > >>>>>>\n> > >>>>>> Thanks again!\n> > >>>>>> Kyle\n> > >>>>>>\n> > >>>>>> [1]\n> > >>>>>> http://eavesdrop.openstack.org/meetings/networking_third_party_te\n> > >>>>>> sting/2013/ [2]\n> > >>>>>> https://etherpad.openstack.org/p/multi-node-neutron-tempest\n> > >>>>>> _______________________________________________\n> > >>>>>> OpenStack-dev mailing list\n> > >>>>>> OpenStack-dev at lists.openstack.org\n> > >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>>>\n> > >>>>> On Wed, 18 Dec 2013 15:10:46 -0600 Kyle Mestery\n> > >>>>> <mestery at siliconloons.com> wrote:\n> > >>>>>\n> > >>>>>> Just a reminder, we\'ll be meeting at 2200 UTC on #openstack-\n> > meeting-alt.\n> > >>>>>> We\'ll be looking at this etherpad [1] again, and continuing\n> > >>>>>> discussions from last week.\n> > >>>>>>\n> > >>>>>> Thanks!\n> > >>>>>> Kyle\n> > >>>>>>\n> > >>>>>> [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest\n> > >>>>>>\n> > >>>>>> _______________________________________________\n> > >>>>>> OpenStack-dev mailing list\n> > >>>>>> OpenStack-dev at lists.openstack.org\n> > >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>>>\n> > >>>>> --\n> > >>>>> Itsuro ODA <oda at valinux.co.jp>\n> > >>>>>\n> > >>>>>\n> > >>>>> _______________________________________________\n> > >>>>> OpenStack-dev mailing list\n> > >>>>> OpenStack-dev at lists.openstack.org\n> > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>>>\n> > >>>>>\n> > >>>>>\n> > >>>>> --\n> > >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> > >>>>> Don Kehn\n> > >>>>> 303-442-0060\n> > >>>>> _______________________________________________\n> > >>>>> OpenStack-dev mailing list\n> > >>>>> OpenStack-dev at lists.openstack.org\n> > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>>\n> > >>>>\n> > >>>> _______________________________________________\n> > >>>> OpenStack-dev mailing list\n> > >>>> OpenStack-dev at lists.openstack.org\n> > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>>\n> > >>>\n> > >>> _______________________________________________\n> > >>> OpenStack-dev mailing list\n> > >>> OpenStack-dev at lists.openstack.org\n> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>\n> > >> _______________________________________________\n> > >> OpenStack-dev mailing list\n> > >> OpenStack-dev at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >>\n> > >> _______________________________________________\n> > >> OpenStack-dev mailing list\n> > >> OpenStack-dev at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> Thanks, \n> Jon-Paul Sullivan ? Cloud Services - @hpcloud\n> \n> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway.\n> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson\'s Quay, Dublin 2. \n> Registered Number: 361933\n>  \n> The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender.\n> \n> To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as \"HP CONFIDENTIAL\".\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<A5492763B7A1E640AEB5E1C05208B1F2543346AD@G9W0759.americas.hpqcorp.net>',NULL),('<1389884983.2174.5.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 10:09:43',-18000,'2014-01-16 15:09:43',NULL,'[openstack-dev] [rally] Naming of a deployment','On Thu, 2014-01-16 at 12:57 +0400, Oleg Gelbukh wrote:\n> On Thu, Jan 16, 2014 at 2:21 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Wed, 2014-01-15 at 21:46 +0000, Hugh Saunders wrote:\n>         > On 15 January 2014 21:14, Ilya Kharin <ikharin at mirantis.com>\n>         wrote:\n>         >\n>         >         Hi, guys,\n>         >\n>         >         In Rally there is an entity that represents\n>         installed instance\n>         >         of OpenStack.\n>         >         What you think about a proper name for the entity?\n>         (a\n>         >         Deployment, a Cluster, an Installation, an Instance\n>         or\n>         >         something else)\n>         >\n>         > I vote for Deployment.\n\n> Doesn\'t it sound a bit weird to deploy a Deployment? Otherwise, it\n> does not really matter how it is called as long as the naming is\n> consistent.\n\nWell, sure :) But it sounds equally weird to say \"install an\ninstallation\". The point here is the noun, which I believe \"deployment\"\nmost accurately describes what the thing is. The other terms have\nconnotation issues:\n\n* \"cluster\" -- is too generic, but also has connotations in HPC and\nvarious other technologies (databases, MQs, etc).\n\n* \"installation\" -- reminds me of a piece of performance art ;)\n\n* \"instance\" -- too much cross-terminology with server instance in Nova\nand Ironic\n\n> I have another question. Shoud we think about separation of Deployment\n> and Endpoint entities in API? Deployment is an object managed by\n> deployment engine, while Endpoint can refer to existing installation\n> which has nothing to do with deployment engine. It means that\n> different sets of operations are applicable to those entities. What do\n> you think?\n\nSure, I think that is a useful distinction.\n\nBest,\n-jay\n\n> --\n> Best regards,\n> Oleg Gelbukh\n>  \n>         \n>         \n>         ++\n>         \n>         Best,\n>         -jay\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAFkLEwppksMSJEEWigrFf3a61WM8vNGGmc4STTSfZxobx=rs0A@mail.gmail.com>',NULL),('<1389885469.2174.6.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 10:17:49',-18000,'2014-01-16 15:17:49',NULL,'[openstack-dev] Hat Tip to fungi','On Thu, 2014-01-16 at 08:44 -0500, Anita Kuno wrote:\n> Thank you, fungi.\n> \n> You have kept openstack-infra running for that last 2 weeks as the sole\n> plate-spinner whilst the rest of us were conferencing, working on the\n> gerrit upgrade or getting our laptop stolen.\n> \n> You spun up and configured two new Jenkinses (Jenkinsii?) and then deal\n> with the consequences of one expansion of our system slowing down\n> another. With Jim\'s help from afar, Zuul is now on a faster server. [0]\n> \n> All this while dealing with the every day business of keeping -infra\n> operating.\n> \n> I am so grateful for all you do.\n> \n> I tip my hat to you, sir.\n\nSeconded.\n\n-jay\n\n\n\n','<52D7E231.4050207@anteaya.info>',NULL),('<1389885635.2174.7.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-16 10:20:35',-18000,'2014-01-16 15:20:35',NULL,'[Openstack] Fwd: [nova] [rfc] drop XML from v3 API entirely','On Thu, 2014-01-16 at 07:22 -0500, Sean Dague wrote:\n> On 01/15/2014 10:41 PM, Tom Fifield wrote:\n> > On 15/01/14 22:02, Russell Bryant wrote:\n> >> On 01/13/2014 08:52 PM, Tom Fifield wrote:\n> >>> According to the most recent user survey, more than 30% of users consume\n> >>> the XML API.\n> >>\n> >> Do you have a reference with more detail on this?  Simply \"30%\" doesn\'t\n> >> really mean much without more detail on what the question was, what the\n> >> choices where, how many answered the question, etc ...\n> > \n> > Survey questions can of course be found at\n> > https://www.openstack.org/user-survey/. This particular one was found on\n> > the second page of the \"About your OpenStack Deployments\" section:\n> > \n> > \"\"\"\n> > What formats do you use for the API?\n> > [X] XML\n> > [X] JSON\n> > \"\"\"\n> > \n> > From the data from 2013-10-11:\n> > \n> > 30.67% of survey takers ticked XML\n> > 69.32% of survey takers ticked JSON\n> > \n> > of course this question allowed overlap - the ticking of both boxes. The\n> > overlap is 17.17% (or, if you prefer - 13.49% \"pure\" XML, and 52% \"pure\"\n> > JSON)\n> > \n> > \n> > 83% of deployments answered this question. As a comparison, this is a\n> > similar number to how many answered the \"hypervisors\" question (87%).\n> \n> That also assumes that survey responders understood the question the way\n> we are interpreting it. The actual question should have been:\n> \n> What toolkits do you use to interface with the OpenStack API?\n>  * OpenStack command line (i.e. nova cli)\n>  * openstack python libraries\n>  * jclouds\n>  * deltacloud\n>  ...\n>  * other - please specify\n>  * none - wrote our own\n> \n> If you wrote your own toolkit for accessing the OpenStack API what wire\n> format are you using?\n>  * JSON\n>  * XML\n> \n> If you wrote your own toolkit for accessing the OpenStack API what\n> programming language did you write it in?\n>  * C/C++\n>  * C#\n>  * Java\n>  * Python\n>  * Perl\n>  * PHP\n>  * Ruby\n>  * Other (please specify)\n> \n> Because the question as worded assumes far too much shared context and\n> understanding in what we were looking for. We all understood what we\n> wanted, but didn\'t unroll that in a specific enough way in the user survey.\n\nWell said, Sean. The above is a great set of questions to ask in the\nnext user survey (or sooner?).\n\nBest,\n-jay\n\n\n\n','<52D7CEEF.2090206@dague.net>',NULL),('<1389886175.2174.12.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-16 10:29:35',-18000,'2014-01-16 15:29:35',NULL,'[Openstack] Private images are not displayed in Horizon','On Thu, 2014-01-16 at 13:59 +0000, Narayanan, Krishnaprasad wrote:\n> Hi,\n> \n> The problem that I am facing is as the user who uploaded the image, I am unable to see it in the users account.\n\nIf this is indeed the case, then that is a bug.\n\nHowever... make really sure that you are indeed logged in as the tenant\nthat added the image. If you are using something like nova image-list to\nsee your images, ensure that you are not using a cached tenant token by\nissuing the nova image-list commands with the --no-cache CLI option.\n\nTo set the image as a public image, as an admin, issue the following\ncommand with the glance CLI tool:\n\nglance image-update --is-public=True <IMAGE_UUID>\n\nBest,\n-jay \n\n\n\n','<E65EEA4076DFA64CB0D578052EE5B8BA47E59063@E14MDB-01.zdv.Uni-Mainz.DE>',NULL),('<1389887357.2174.20.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-16 10:49:17',-18000,'2014-01-16 15:49:17',NULL,'[Openstack] [openstack-dev] [Neutron] auto configration of\n	local_ip','On Thu, 2014-01-16 at 17:41 +0900, NOTSU Arata wrote:\n> Hello,\n> \n> I\'m trying to add a new configuration option for Neutron OVS agent. Although I\'ve submitted a patch and it is being reviewed [1], I\'m posting to this mailing list seeking opinion from a wider range.\n> \n> At present, when you deploy an environment using Neutron + OVS + GRE/VXLAN, you have to set local_ip for tunnelling in neutron agent config (typically ovs_neutron_plugin.ini). As each host has different local_ip, preparing and maintaining the config files is a cumbersome work.\n> \n> So, I would like to introduce automatic configuration of local_ip in Neutron. Although such a management should be done by some management system, Neutron having this feature cloud be also helpful to the deployment system. It would reduce the need for the systems to implement such a feature on their own.\n> \n> Anyway, with this feature, instead of setting an actual IP address to local_ip, you set some options (criteria) for choosing an IP address suitable for local_ip among IP addresses assigned to the host. At runtime, OVS agent will choose an IP address according to the criteria. You will get the same effect as you set local_ip=<the IP address> by hand.\n> \n> The question is, what criteria is appropriate for the purpose. The criteria being mentioned so far in the review are:\n> \n> 1. assigned to the interface attached to default gateway\n> 2. being in the specified network (CIDR)\n> 3. assigned to the specified interface\n>    (1 can be considered a special case of 3)\n> \n> Any comment would be appreciated.\n\nHi Arata,\n\nI definitely understand the thoughts behind your patch. However, I\nbelieve this falls under the realm of configuration management tools\n(Chef/Puppet/Ansible/Salt/etc).\n\nAs an example of how the OpenStack Chef cookbooks deal with this\nparticular problem, we inject a local_ip variable into the\novs_neutron_plugin.ini.erb template [1]. This local_ip variable is\nassigned in the common.rb recipe [2]. The deployer can either manually\nset the local_ip to an address by setting the node\'s attribute directly,\nor the deployer can have the local_ip address determined based on a\nnamed network interface. See the code at [2] for this switching\nbehavior.\n\nIn summary, I believe it\'s best left to configuration management systems\nto do this type of thing (configuration of many nodes in a structured\nfashion), instead of having Neutron do this itself.\n\nBest,\n-jay\n\n[1]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/templates/default/plugins/openvswitch/ovs_neutron_plugin.ini.erb#L111\n[2]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/common.rb#L125\n\n\n\n','<52D79B50.9060801@virtualtech.jp>',NULL),('<1389887357.2174.20.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 10:49:17',-18000,'2014-01-16 15:49:17',NULL,'[openstack-dev] [Neutron] auto configration of local_ip','On Thu, 2014-01-16 at 17:41 +0900, NOTSU Arata wrote:\n> Hello,\n> \n> I\'m trying to add a new configuration option for Neutron OVS agent. Although I\'ve submitted a patch and it is being reviewed [1], I\'m posting to this mailing list seeking opinion from a wider range.\n> \n> At present, when you deploy an environment using Neutron + OVS + GRE/VXLAN, you have to set local_ip for tunnelling in neutron agent config (typically ovs_neutron_plugin.ini). As each host has different local_ip, preparing and maintaining the config files is a cumbersome work.\n> \n> So, I would like to introduce automatic configuration of local_ip in Neutron. Although such a management should be done by some management system, Neutron having this feature cloud be also helpful to the deployment system. It would reduce the need for the systems to implement such a feature on their own.\n> \n> Anyway, with this feature, instead of setting an actual IP address to local_ip, you set some options (criteria) for choosing an IP address suitable for local_ip among IP addresses assigned to the host. At runtime, OVS agent will choose an IP address according to the criteria. You will get the same effect as you set local_ip=<the IP address> by hand.\n> \n> The question is, what criteria is appropriate for the purpose. The criteria being mentioned so far in the review are:\n> \n> 1. assigned to the interface attached to default gateway\n> 2. being in the specified network (CIDR)\n> 3. assigned to the specified interface\n>    (1 can be considered a special case of 3)\n> \n> Any comment would be appreciated.\n\nHi Arata,\n\nI definitely understand the thoughts behind your patch. However, I\nbelieve this falls under the realm of configuration management tools\n(Chef/Puppet/Ansible/Salt/etc).\n\nAs an example of how the OpenStack Chef cookbooks deal with this\nparticular problem, we inject a local_ip variable into the\novs_neutron_plugin.ini.erb template [1]. This local_ip variable is\nassigned in the common.rb recipe [2]. The deployer can either manually\nset the local_ip to an address by setting the node\'s attribute directly,\nor the deployer can have the local_ip address determined based on a\nnamed network interface. See the code at [2] for this switching\nbehavior.\n\nIn summary, I believe it\'s best left to configuration management systems\nto do this type of thing (configuration of many nodes in a structured\nfashion), instead of having Neutron do this itself.\n\nBest,\n-jay\n\n[1]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/templates/default/plugins/openvswitch/ovs_neutron_plugin.ini.erb#L111\n[2]\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/recipes/common.rb#L125\n\n\n\n','<52D79B50.9060801@virtualtech.jp>',NULL),('<1389887524.2174.21.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 10:52:04',-18000,'2014-01-16 15:52:04',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','On Thu, 2014-01-16 at 11:25 +0100, Jaromir Coufal wrote:\n> On 2014/12/01 20:40, Jay Pipes wrote:\n> > On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:\n> >>>> So, it\'s not as simple as it may initially seem :)\n> >>>\n> >>> Ah, I should have been clearer in my statement - my understanding is that\n> >>> we\'re scrapping concepts like Rack entirely.\n> >>\n> >> That was my understanding as well. The existing Tuskar domain model was\n> >> largely placeholder/proof of concept and didn\'t necessarily reflect\n> >> exactly what was desired/expected.\n> >\n> > Hmm, so this is a bit disappointing, though I may be less disappointed\n> > if I knew that Ironic (or something else?) planned to account for\n> > datacenter inventory in a more robust way than is currently modeled.\n> >\n> > If Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling\n> > that an enterprise would use to deploy bare-metal hardware in a\n> > continuous fashion, then the modeling of racks, and the attributes of\n> > those racks -- location, power supply, etc -- are a critical part of the\n> > overall picture.\n> >\n> > As an example of why something like power supply is important... inside\n> > AT&T, we had both 8kW and 16kW power supplies in our datacenters. For a\n> > 42U or 44U rack, deployments would be limited to a certain number of\n> > compute nodes, based on that power supply.\n> >\n> > The average power draw for a particular vendor model of compute worker\n> > would be used in determining the level of compute node packing that\n> > could occur for that rack type within a particular datacenter. This was\n> > a fundamental part of datacenter deployment and planning. If the tooling\n> > intended to do bare-metal deployment of OpenStack in a continual manner\n> > does not plan to account for these kinds of things, then the chances\n> > that tooling will be used in enterprise deployments is diminished.\n> >\n> > And, as we all know, when something isn\'t used, it withers. That\'s the\n> > last thing I want to happen here. I want all of this to be the\n> > bare-metal deployment tooling that is used *by default* in enterprise\n> > OpenStack deployments, because the tooling \"fits\" the expectations of\n> > datacenter deployers.\n> >\n> > It doesn\'t have to be done tomorrow :) It just needs to be on the map\n> > somewhere. I\'m not sure if Ironic is the place to put this kind of\n> > modeling -- I thought Tuskar was going to be that thing. But really,\n> > IMO, it should be on the roadmap somewhere.\n> >\n> > All the best,\n> > -jay\n> \n> Perfect write up, Jay.\n> \n> I can second these needs based on talks I had previously.\n> \n> The goal is to primarily support enterprise deployments and they work \n> with racks, so all of that information such as location, power supply, \n> etc are important.\n> \n> Though this is pretty challenging area and we need to start somewhere. \n> As a proof of concept, Tuskar tried to provide similar views, then we \n> jumped into reality. OpenStack has no strong support in racks field for \n> the moment. As long as we want to deliver working deployment solution \n> ASAP and enhance it in time, we started with currently available features.\n> \n> We are not giving up racks entirely, they are just a bit pushed back, \n> since there is no real support in OpenStack yet. But to deliver more \n> optimistic news, regarding last OpenStack summit, Ironic intends to work \n> with all the racks information (location, power supply, ...). So once \n> Ironic contains all of that information, we can happily start providing \n> such capability for deployment setups, hardware overviews, etc.\n> \n> Having said that, for Icehouse I pushed for Node Tags to get in. It is \n> not the best experience, but using Node Tags, we can actually support \n> various use-cases for user (by him tagging nodes manually at the moment).\n\nTotally cool, Jarda. I appreciate your response and completely\nunderstand the prioritization.\n\nBest,\n-jay\n\n\n\n','<52D7B393.20902@redhat.com>',NULL),('<1389887730.2174.22.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 10:55:30',-18000,'2014-01-16 15:55:30',NULL,'[openstack-dev] a \"common\" client library','On Thu, 2014-01-16 at 09:03 +0100, Flavio Percoco wrote:\n> On 15/01/14 21:35 +0000, Jesse Noller wrote:\n> >\n> >On Jan 15, 2014, at 1:37 PM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n> >\n> >> Several people have mentioned to me that they are interested in, or actively working on, code related to a \"common\" client library -- something meant to be reused directly as a basis for creating a common library for all of the openstack clients to use. There\'s a blueprint [1] in oslo, and I believe the keystone devs and unified CLI teams are probably interested in ensuring that the resulting API ends up meeting all of our various requirements.\n> >>\n> >> If you\'re interested in this effort, please subscribe to the blueprint and use that to coordinate efforts so we don\'t produce more than one common library. ;-)\n> >>\n> >> Thanks,\n> >> Doug\n> >>\n> >>\n> >> [1] https://blueprints.launchpad.net/oslo/+spec/common-client-library-2\n> >\n> >*raises hand*\n> >\n> >Me me!\n> >\n> >I?ve been talking to many contributors about the Developer Experience stuff I emailed out prior to the holidays and I was starting blueprint work, but this is a great pointer. I?m going to have to sync up with Alexei.\n> >\n> >I think solving this for openstack developers and maintainers as the blueprint says is a big win in terms of code reuse / maintenance and consistent but more so for *end-user developers* consuming openstack clouds.\n> >\n> >Some background - there?s some terminology mismatch but the rough idea is the same:\n> >\n> >* A centralized ?SDK? (Software Development Kit) would be built condensing the common code and logic and operations into a single namespace.\n> >\n> >* This SDK would be able to be used by ?downstream? CLIs - essentially the CLIs become a specialized front end - and in some cases, only an argparse or cliff front-end to the SDK methods located in the (for example) openstack.client.api.compute\n> >\n> >* The SDK would handle Auth, re-auth (expired tokens, etc) for long-lived clients - all of the openstack.client.api.** classes would accept an Auth object to delegate management / mocking of the Auth / service catalog stuff to. This means developers building applications (say for example, horizon) don?t need to worry about token/expired authentication/etc.\n> >\n> >* Simplify the dependency graph & code for the existing tools to enable single binary installs (py2exe, py2app, etc) for end users of the command line tools.\n> >\n> >Short version: if a developer wants to consume an openstack cloud; the would have a single SDK with minimal dependencies and import from a single namespace. An example application might look like:\n> >\n> >from openstack.api import AuthV2\n> >from openstack.api import ComputeV2\n> >\n> >myauth = AuthV2(?., connect=True)\n> >compute = ComputeV2(myauth)\n> >\n> >compute.list_flavors()\n> >\n> \n> I know this is an example but, could we leave the version out of the\n> class name? Having something like:\n> \n> from openstack.api.v2 import Compute\n> \n>         or\n> \n> from openstack.compute.v2 import Instance\n> \n> (just made that up)\n> \n> for marconi we\'re using the later.\n\n++\n\n-jay\n\n\n\n','<20140116080311.GI2654@redhat.com>',NULL),('<1389889381.2174.23.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 11:23:01',-18000,'2014-01-16 16:23:01',NULL,'[openstack-dev] a \"common\" client library','On Thu, 2014-01-16 at 10:06 -0600, Dean Troyer wrote:\n> On Thu, Jan 16, 2014 at 9:37 AM, Jesse Noller\n> <jesse.noller at rackspace.com> wrote:\n>         On Jan 16, 2014, at 9:26 AM, Justin Hammond\n>         <justin.hammond at RACKSPACE.COM> wrote:\n>         > I\'m not sure if it was said, but which httplib using being\n>         > used (urllib3\n>         > maybe?). Also I noticed many people were talking about\n>         > supporting auth\n>         > properly, but are there any intentions to properly support\n>         > \'noauth\'\n>         > (python-neutronclient, for instance, doesn\'t support it\n>         > properly as of\n>         > this writing)? \n>         > \n>         Can you detail out noauth for me; and I would say the defacto\n>         httplib in python today is python-requests - urllib3 is also\n>         good but I would say from a *consumer* standpoint requests\n>         offers more in terms of usability / extensibility \n> \n> \n> requests is built on top of urllib3 so there\'s that...\n> \n> \n> The biggest reaon I favor using Jamie Lennox\'s new session layer stuff\n> in keystoneclient is that it better reflects the requests API instead\n> of it being stuffed in after the fact.  And as the one responsible for\n> that stuffing, it was pretty blunt and really needs to be cleaned up\n> more than Alessio did.\n> \n> \n> only a few libs (maybe just glance and swift?) don\'t use requests at\n> this point and I think the resistance there is the chunked transfers\n> they both do.\n\nRight, but requests supports chunked-transfer encoding properly, so\nreally there\'s no reason those clients could not move to a\nrequests-based codebase.\n\nBest,\n-jay\n\n> \n> I\'m really curious what \'noauth\' means against APIs that have few, if\n> any, calls that operate without a valid token.\n> \n> \n> dt\n> \n> \n> -- \n> \n> Dean Troyer\n> dtroyer at gmail.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAOJFoEvV2meTJivpP3D9Ez+7NnohKosUnAx2puH4xHcAHdpzdg@mail.gmail.com>',NULL),('<1389890104.2230616.1396914669309.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 19:51:09',-14400,'2014-04-07 23:51:09',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, April 7, 2014 4:00:30 PM\n> Subject: [openstack-dev] [TripleO] config options, defaults, oh my!\n> \n> So one interesting thing from the influx of new reviews is lots of\n> patches exposing all the various plumbing bits of OpenStack. This is\n> good in some ways (yay, we can configure more stuff), but in some ways\n> its kindof odd - like - its not clear when\n> https://review.openstack.org/#/c/83122/ is needed.\n> \n> I\'m keen to expose things that are really needed, but i\'m not sure\n> that /all/ options are needed - what do folk think?\n\nI think we can learn much from some of the more mature configuration management tools in the community on this front. Using puppet as an example here (although I\'m sure other tools may do similar things as well)... Take configuration of the Nova API server. There is a direct configuration parameter for \'neutron_metadata_proxy_shared_secret\' in the Puppet nova::api class. This parameter is exposed in the class (sort of the equivalent of a TripleO element) directly because it is convenient and many users may want to customize the value. There are however hundreds of Nova config options and most of them aren\'t exposed as parameters in the various Nova puppet classes. For these it is possible to define a nova_config resource to configure *any* nova.conf parameter in an ad hoc style for your own installation tuning purposes.\n\nI could see us using a similar model in TripleO where our elements support configuring common config elements directly, but we also allow people to tune extra \"undocumented\" options for their own use. There is always going to be a need for this as people need to tune things for their own installations with options that may not be appropriate for the common set of elements.\n\nStandardizing this mechanism across many of the OpenStack service elements would also make a lot of sense. Today we have this for Nova:\n\nnova:\n  verbose: False\n    - Print more verbose output (set logging level to INFO instead of default WARNING level).\n  debug: False\n    - Print debugging output (set logging level to DEBUG instead of default WARNING level).\n  baremetal:\n    pxe_deploy_timeout: \"1200\"\n  .....\n\nI could see us adding a generic mechanism like this to overlay with the existing (documented) data structure:\n\nnova:\n   config:\n       default.compute_manager: ironic.nova.compute.manager.ClusterComputeManager\n       cells.driver: nova.cells.rpc_driver.CellsRPCDriver\n\nAnd in this manner a user might be able to add *any* supported config param to the element.\n\n\n> Also, some things\n> really should be higher order operations - like the neutron callback\n> to nova right - that should be either set to timeout in nova &\n> configured in neutron, *or* set in both sides appropriately, never\n> one-half or the other.\n> \n> I think we need to sort out our approach here to be systematic quite\n> quickly to deal with these reviews.\n\nI totally agree. I was also planning to email the list about this very issue this week :) My email subject was going to be \"TripleO templates... an upstream maintenance problem\".\n\nFor the existing reviews today I think we should be somewhat selective about what parameters we expose as top level within the elements. That said we are missing some rather fundamental features to allow users to configure \"undocumented\" parameters as well. So we need to solve this problem quickly because there are certainly some configuration corner that users will need.\n\nAs is today we are missing some rather fundamental features in os-apply-config and the elements to be able to pull this off. What we really need is a generic INI style template generator. Or perhaps we could use something like augeus or even devstacks simple ini editing functions to pull this off. In any case the idea would be that we allow users to inject their own undocumented config parameters into the various service config files. Or perhaps we could auto-generate mustache templates based off of the upstream sample config files. Many approaches would work here I think...\n\n\n> \n> Here\'s an attempt to do so - this could become a developers guide patch.\n> \n> Config options in TripleO\n> ==================\n> \n> Non-API driven configuration falls into four categories:\n> A - fixed at buildtime (e.g. ld.so path)\n> B - cluster state derived\n> C - local machine derived\n> D - deployer choices\n> \n> For A, it should be entirely done within the elements concerned.\n> \n> For B, the heat template should accept parameters to choose the\n> desired config (e.g. the Neutron->Nova example able) but then express\n> the config in basic primitives in the instance metadata.\n> \n> For C, elements should introspect the machine (e.g. memory size to\n> determine mysql memory footprint) inside os-refresh-config scripts;\n> longer term we should make this an input layer to os-collect-config.\n> \n> For D, we need a sensible parameter in the heat template and probably\n> direct mapping down to instance metadata.\n> \n> But we have a broader question - when should something be configurable at\n> all?\n> \n> In my mind we have these scenarios:\n> 1) There is a single right answer\n> 2) There are many right answers\n> \n> An example of 1) would be any test-only option like failure injection\n> - the production value is always \'off\'. For 2), hypervisor driver is a\n> great example - anything other than qemu is a valid production value\n> :)\n> \n> But, it seems to me that these cases actually subdivide further -\n> 1a) single right answer, and the default is the right answer\n> 1b) single right answer and it is not the default\n> 2a) many right answers, and the default is the most/nearly most common one\n> 2b) many right answers, and the default is either not one of them or\n> is a corner case\n> \n> So my proposal here - what I\'d like to do as we add all these config\n> options to TripleO is to take the care to identify which of A/B/C/D\n> they are and code them appropriately, and if the option is one of 1b)\n> or 2b) make sure there is a bug in the relevant project about the fact\n> that we\'re having to override a default. If the option is really a\n> case of 1a) I\'m not sure we want it configurable at all.\n\nIdeally I think anything should be configurable (hard coding things is bad IMO... and it may make TripleO look bad too). That said I think if we follow a plan similar to what I laid out above we\'ll be able to be restrictive/selective about what we allow into elements as documented config parameters while also supporting the case where users need to potentially customize anything.\n\nAll the while I think our experiences in TripleO can be a nice feedback loop into some of the upstream OpenStack projects as well to help give advice on what the defaults should be. We may not always win the \"TripleO default should be the upstream default\" argument but that is Okay. Perhaps this is where the occasional in-element default (which is overridable) will come in handy.\n\n> \n> Thoughts?\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ15u=XromXPi=q=5RV26Kz4h8m+mPMvE-A2LtLhpTknhQ@mail.gmail.com>',NULL),('<1389902301.176532501@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 14:58:21',-18000,'2014-01-16 19:58:21',NULL,'[openstack-dev] [OpenStack-Dev] Cherry picking commit from\n	oslo-incubator','I think I agree with you John. Micromanaging the common library just makes more work. Is there any argument to not syncing everything? And do you mean cherry-picking only some of the changes in a single module?!? if that\'s the case then future syncing could get weird, really weird.\n\n-Alex\n\n-----Original Message-----\nFrom: \"John Griffith\" <john.griffith at solidfire.com>\nSent: Thursday, January 16, 2014 2:48pm\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [OpenStack-Dev] Cherry picking commit from oslo-incubator\n\nHey Everyone,\n\nA review came up today that cherry-picked a specific commit to OSLO\nIncubator, without updating the rest of the files in the module.  I\nrejected that patch, because my philosophy has been that when you\nupdate/pull from oslo-incubator it should be done as a full sync of\nthe entire module, not a cherry pick of the bits and pieces that you\nmay or may not be interested in.\n\nAs it turns out I\'ve received a bit of push back on this, so it seems\nmaybe I\'m being unreasonable, or that I\'m mistaken in my understanding\nof the process here.  To me it seems like a complete and total waste\nto have an oslo-incubator and common libs if you\'re going to turn\naround and just cherry pick changes, but maybe I\'m completely out of\nline.\n\nThoughts??\n\nJohn\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CA+qL3LUvy36qTrV-R3iWuceZPPY1Fty5i+nFeaqv1++eWbcL7w@mail.gmail.com>',NULL),('<1389910904-sup-5199@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 14:22:32',-28800,'2014-01-16 22:22:32',NULL,'[openstack-dev] Proposal for dd disk i/o performance blueprint\n	of cinder.','Excerpts from Fox, Kevin M\'s message of 2014-01-16 09:29:14 -0800:\n> Yeah, I think the evil firmware issue is separate and should be solved separately.\n> \n> Ideally, there should be a mode you can set the bare metal server into where firmware updates are not allowed. This is useful to more folks then just baremetal cloud admins. Something to ask the hardware vendors for.\n> \n\nYes, I think we call this mode \"virtualization\".\n\n\n','<1A3C52DFCD06494D8528644858247BF00C8C86@EX10MBOX03.pnnl.gov>',NULL),('<1389910960-sup-358@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 14:28:21',-28800,'2014-01-16 22:28:21',NULL,'[openstack-dev] Proposal for dd disk i/o performance blueprint\n	of cinder.','Excerpts from CARVER, PAUL\'s message of 2014-01-16 05:21:24 -0800:\n> \n> Alan Kavanagh wrote: \n> \n> >I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) \" a >tenant can not read another tenants disk......\" the next (2) was where in Ironic you provision a baremetal server that has an >onboard dish as part of the blade provisioned to a given tenant-A. then when tenant-A finishes his baremetal blade lease and >that blade comes back into the pool and tenant-B comes along, I was asking what open source tools guarantee data destruction >so that no ghost images  or file retrieval is possible?\n> \n> That is an excellent point. I think the needs of Ironic may be different from Cinder. As a volume manager Cinder isn\'t actually putting the raw disk under the control of a tenant. If it can be assured that (as is the case with NetApp and other storage vendor hardware) that a \"fake\" all zeros is returned on a read-before-first-write of a chunk of disk space then that\'s sufficient to address the case of some curious ne\'er-do-well allocating volumes purely for the purpose of reading them to see what\'s left on them.\n> \n> But with bare metal the whole physical disk is at the mercy of the tenant so you\'re right that it must be ensured that the none of the previous tenant\'s bits are left lying around to be snooped on.\n> \n> But I still think an *option* of wipe=none may be desirable because a cautious client might well take it into their own hands to wipe the disk before releasing it (and perhaps encrypt as well). In which case always doing an additional wipe is going to be more disk I/O for no real benefit.\n> \n\nI am of a mind that multi-tenant hardware is something that needs to be\ndesigned at the hardware level. I am not aware of anyone doing that.\n\nFor hardware that exists today, we have virtualization to protect the\nhardware from its users.  A single VM that takes all the resources will\nnot have most of the contention that lead to virtualization performance\nproblems, and will have the benefit of not requiring any sort of process\nto return it to the pool.\n\nFor the topic at hand, said VM will only have access to volumes in\nthe same way as VMs and thus the problem stays solved for multi-tenant\nhardware if we keep that restriction.\n\n\n','<A81F249089B6C7479786834457908C600AC12025@MISOUT7MSGUSR9N.ITServices.sbc.com>',NULL),('<1389916652.2733.38.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 09:57:32',36000,'2014-01-16 23:57:32',NULL,'[openstack-dev] a \"common\" client library','*snip*\n> \n> \n> Distinction between client layers won\'t get lost and would only be\n> improved. My basic idea is the following:\n> \n> 1) Transport layer would handle all transport related stuff - HTTP,\n> JSON encoding, auth, caching, etc.\n> \n> 2) Model layer (Resource classes, BaseManager, etc.) will handle data\n> representation, validation\n> \n> 3) API layer will handle all project specific stuff - url mapping,\n> etc. (This will be imported to use client in other applications)\n> \n> 4) Cli level will handle all stuff related to cli mapping - argparse,\n> argcomplete, etc.\n> \n> \n> >I believe the current effort referenced by the blueprint is focusing\n> on moving existing code into the incubator for reuse, to make it\n> easier to restructure later. Alexei, do I have that correct?\n> \n> You are right. The first thing we do is try to make all clients\n> look/work in similar way. After we\'ll continue our work with improving\n> overall structure.\n\nWow, this thread took off. I\'ll jump in here as it\'s as good a point as\nany. Sorry this will be long but i\'ve been working on this for a while. \n\nSo hopefully a few people know that we have been looking at addressing\nthis problem in keystoneclient as it really needs to be a/the base\nclient as it will handle authentication across all the projects.\n\nI completely agree with your 4 sections, though i would really love to\nsee some more detail around levels 2 and 3. \n\nSection 1: Transport layer\n\nFor the majority i\'m hoping that section 1 is in progress to being\nsolved. Keystoneclient introduced a session object which is designed to\nhandle HTTP communication for all the clients. This is a reusable object\nand will contain an auth plugin such that all communication through the\nsession object will be authenticated. There is follow on work here to\nhave the session object manage the service catalog for clients so that a\nclient will simply specify the service type and version it needs to\ncommunicate with. You can see the work around auth plugins and the\nfollow up here: https://review.openstack.org/#/c/60751/ (be aware that\nbackwards compatibility issues make it an ugly patch).\n\nThis solution was discussed at the HK summit and was generally accepted.\nFor an earlier draft of the vision around this see:\nhttp://www.jamielennox.net/blog/2013/09/27/apiclient-communications/\nwhich i should post a revision of. \n\nWith this is mind a base client should look like not much more than:\nhttps://review.openstack.org/#/c/60751/5/keystoneclient/baseclient.py\n\n\nSection 4: CLI\n\nRegarding section 4, my understanding is that all clients are moving\ntowards OSC for there CLI component. This is great. I personally like\nthe idea of the various python-*clients being controlled by their own\nproject as they are the people who best understand how to interact with\ntheir services and design an API that makes sense to them.\n\nI then would prefer that the CLI is controlled completely by OSC (not\nplugins back to the client) because this way we end up with one\ncentralized choke point so that the CLI interface is common across all\nthe projects. Client developers will need to submit reviews to OSC to\nadd new CLI commands and connect it back to the client library. This\nhowever is up to Dean and OSC, but i would prefer them to keep an eye on\nthis interface over the current system.\n\n\nSection 2 & 3: Models and Managers\n\nThis is the part i\'ve generally been concerned about. Firstly the idea\nof having client code in OSLO seems stupid to me. Unlike the servers the\nclients will often live in the same process as each other, particularly\nwith regards to exceptions this means that every client library now has\nthe same list of exceptions though in their own namespace so there is no\ncommon way to handle an exception type when dealing with multiple\nclients.\n\nMy concern with the common client code in OSLO is specifically that at\nno time has there ever been a conversation about what a client should be\ntrying to achieve or the best way to do it. The code in apiclient is a\nsnapshot of what was in use across a number of projects at that time and\nNOT any attempt to define a best practice. Whilst I understand the\ndesire to standardize, I and keystoneclient take backwards compatibility\nvery seriously and there is a lot of code in apiclient which does not\nfit what I think a client should do and i do not want to support it\ngoing forward.\n\nHaving said that I am very interested in figuring this out and defining\na common client framework. But it seems to me the sort of conversation\nthat we want to have at a summit session. Building this common framework\nbased on the current state of the clients is just formalizing the\ncurrent disaster.\n\n\n\nTo summarize, great! I\'m the number one supported of improving and\nunifying the clients. Please under there is existing work underway\ntowards this goal and that blindly copying oslo\'s apiclient everywhere\nmay be good for standardization but I don\'t think it really improves\nanything and i\'m not convinced it will make it easier to improve things\nlater.\n\n\nJamie\n\n\n\n> \n> 2014/1/16 Noorul Islam K M <noorul at noorul.com>\n>         Doug Hellmann <doug.hellmann at dreamhost.com> writes:\n>         \n>         > Several people have mentioned to me that they are interested\n>         in, or\n>         > actively working on, code related to a \"common\" client\n>         library -- something\n>         > meant to be reused directly as a basis for creating a common\n>         library for\n>         > all of the openstack clients to use. There\'s a blueprint [1]\n>         in oslo, and I\n>         > believe the keystone devs and unified CLI teams are probably\n>         interested in\n>         > ensuring that the resulting API ends up meeting all of our\n>         various\n>         > requirements.\n>         >\n>         > If you\'re interested in this effort, please subscribe to the\n>         blueprint and\n>         > use that to coordinate efforts so we don\'t produce more than\n>         one common\n>         > library. ;-)\n>         >\n>         \n>         \n>         Solum is already using it\n>         https://review.openstack.org/#/c/58067/\n>         \n>         I would love to watch this space.\n>         \n>         Regards,\n>         Noorul\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CA+h=+L8Ox4wpVcmLJRPf=K9SropbA+eSDfcjz=3byYytOxS_RA@mail.gmail.com>',NULL),('<1389918466-sup-5543@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 16:29:28',-28800,'2014-01-17 00:29:28',NULL,'[openstack-dev] [TripleO] milestone-proposed branches','Note that tripleo-incubator is special and should not be released. It\nis intentionally kept unfrozen and unreleased to make sure there is no\nillusion of stability.\n\nIf there are components in it that need releasing, they should be moved\ninto relevant projects or forked into their own projects.\n\nExcerpts from Ryan Brady\'s message of 2014-01-16 07:42:33 -0800:\n> +1 for releases.\n> \n> In the past I requested a tag for tripleo-incubator to make it easier to build a package and test.\n> \n> In my case a common tag would be easier to track than trying to gather all of the commit hashes where\n> the projects are compatible.\n> \n> Ryan\n> \n> ----- Original Message -----\n> From: \"James Slagle\" <james.slagle at gmail.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, January 16, 2014 10:13:58 AM\n> Subject: [openstack-dev] [TripleO] milestone-proposed branches\n> \n> At last summit, we talked about doing stable branches and releases for\n> the TripleO projects for Icehouse.\n> \n> I\'d like to propose doing a milestone-proposed branch[1] and tagged\n> release for icehouse milestones 2 and 3. Sort of as dry run and\n> practice, as I think it could help tease out some things we might not\n> have considered when we do try to do icehouse stable branches.\n> \n> The icehouse milestone 2 date is January 23rd [2]. So, if there is\n> concensus to do this, we probably need to get the branches created\n> soon, and then do any bugfixes in the branches (master too of course)\n> up unitl the 23rd.\n> \n> I think it\'d be nice if we had a working devtest to use with the\n> released tarballs.  This raises a couple of points:\n>  - We probably need a way in devtest to let people use a different\n> branch (or tarball) of the stuff that is git cloned.\n> - What about tripleo-incubator itself? We\'ve said in the past we don\'t\n> want to attempt to stabilize or release that due to it\'s \"incubator\n> nature\".  But, if we don\'t have a stable set of devtest instructions\n> (and accompanying scripts like setup-endpoints, etc), then using an\n> ever changing devtest with the branches/tarballs is not likely to work\n> for very long.\n> \n> And yes, I\'m volunteering to do the work to support the above, and the\n> release work :).\n> \n> Thoughts?\n> \n> [1] https://wiki.openstack.org/wiki/BranchModel\n> [2] https://wiki.openstack.org/wiki/Icehouse_Release_Schedule\n> \n> -- \n> -- James Slagle\n> --\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<643082535.1827285.1389886953448.JavaMail.root@redhat.com>',NULL),('<1389922588.25533.30.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 17:36:28',-28800,'2014-01-17 01:36:28',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','On Thu, 2014-01-16 at 01:28 +0100, Ian Wells wrote:\n> To clarify a couple of Robert\'s points, since we had a conversation\n> earlier:\n> On 15 January 2014 23:47, Robert Li (baoli) <baoli at cisco.com> wrote:\n>           ---  do we agree that BDF address (or device id, whatever\n>         you call it), and node id shouldn\'t be used as attributes in\n>         defining a PCI flavor?\n> \n> \n> Note that the current spec doesn\'t actually exclude it as an option.\n> It\'s just an unwise thing to do.  In theory, you could elect to define\n> your flavors using the BDF attribute but determining \'the card in this\n> slot is equivalent to all the other cards in the same slot in other\n> machines\' is probably not the best idea...  We could lock it out as an\n> option or we could just assume that administrators wouldn\'t be daft\n> enough to try.\n> \n> \n>                 * the compute node needs to know the PCI flavor.\n>         [...] \n>                           - to support live migration, we need to use\n>         it to create network xml\n> \n> \n> I didn\'t understand this at first and it took me a while to get what\n> Robert meant here.\n> \n> This is based on Robert\'s current code for macvtap based live\n> migration.  The issue is that if you wish to migrate a VM and it\'s\n> tied to a physical interface, you can\'t guarantee that the same\n> physical interface is going to be used on the target machine, but at\n> the same time you can\'t change the libvirt.xml as it comes over with\n> the migrating machine.  The answer is to define a network and refer\n> out to it from libvirt.xml.  In Robert\'s current code he\'s using the\n> group name of the PCI devices to create a network containing the list\n> of equivalent devices (those in the group) that can be macvtapped.\n> Thus when the host migrates it will find another, equivalent,\n> interface.  This falls over in the use case under consideration where\n> a device can be mapped using more than one flavor, so we have to\n> discard the use case or rethink the implementation.\n> \n> There\'s a more complex solution - I think - where we create a\n> temporary network for each macvtap interface a machine\'s going to use,\n> with a name based on the instance UUID and port number, and containing\n> the device to map.  Before starting the migration we would create a\n> replacement network containing only the new device on the target host;\n> migration would find the network from the name in the libvirt.xml, and\n> the content of that network would behave identically.  We\'d be\n> creating libvirt networks on the fly and a lot more of them, and we\'d\n> need decent cleanup code too (\'when freeing a PCI device, delete any\n> network it\'s a member of\'), so it all becomes a lot more hairy.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nIan/Robert, below is my understanding to the method Robet want to use,\nam I right?\n\na) Define a libvirt network as  \"Using a macvtap \"direct\" connection\"\nsection at \"http://libvirt.org/formatnetwork.html . For example, like\nfollowed one: \n<network>\n        <name> group_name1 </name>\n        <forward mode=\"bridge\">\n          <interface dev=\"eth20\"/>\n          <interface dev=\"eth21\"/>\n          <interface dev=\"eth22\"/>\n          <interface dev=\"eth23\"/>\n          <interface dev=\"eth24\"/>\n        </forward>\n      </network>\n\n\nb) When assign SRIOV NIC devices to an instance, as in \"Assignment from\na pool of SRIOV VFs in a libvirt <network> definition\" section in\nhttp://wiki.libvirt.org/page/Networking#PCI_Passthrough_of_host_network_devices , use libvirt network definition group_name1. For example, like followed one:\n\n  <interface type=\'network\'>\n    <source network=\'group_name1\'>\n  </interface>\n\n\nIf my understanding is correct, then I have something unclear yet:\na) How will the libvirt create the libvirt network (i.e. libvirt network\ngroup_name1)? Will it has be created when compute boot up, or it will be\ncreated before instance creation? I suppose per Robert\'s design, it\'s\ncreated when compute node is up, am I right?\n\nb) If all the interface are used up by instance, what will happen.\nConsidering that 4 interface allocated to the group_name1 libvirt\nnetwork, and user try to migrate 6 instance with \'group_name1\' network,\nwhat will happen?\n\nAnd below is my comments:\n\na) Yes, this is in fact different with the current nova PCI support\nphilosophy. Currently we assume Nova owns the devices, manage the device\nassignment to each instance. While in such situation, libvirt network is\nin fact another layer of PCI device management layer (although very\nthin) !\n\nb) This also remind me that possibly other VMM like XenAPI has special\nrequirement and we need input/confirmation from them also.\n\n\nAs how to resolve the issue, I think there are several solution:\n\na) Create one libvirt network for each SRIOV NIC assigned to each\ninstance dynamic, i.e. the libvirt network always has only one interface\nincluded, it may be static created or dynamical created. This solution\nin fact removes the allocation functionality of the libvirt network and\nleaves only the configuration functionality.\n\nb) Change Nova PCI to support a special type of PCI device attribute\n(like the PCI group). For these PCI attributes , the PCI device\nscheduler will match a PCI devices only if the attributes is specified\nclearly in the PCI flavor.\n  Below is an example:\n  considering two PCI SRIOV device:\n	Dev1: BDF=00:0.1, vendor_id=1, device_id=1, group=grp1\n	Dev2: BDF=00:1.1, vendor_id=1, device_id=2\n    i.e. Dev2 has no group attributes are specified.\n\n   And we mark \'group\' attribute as special attributes.\n\n   Considering follow flavors:\n        Flavor1: name=flv1, vendor_id=1\n	Flavor2: name=flv2, vendor_id=1, group=grp1\n	Flavor3: name=flv3, group=grp1.\n\n   The Dev1 will never be assigned to flv2.\n   This solution try to separate the devices managed by Nova exclusively\nand devices managed by Nova/libvirt together.\n\nAny idea?\n\nThanks\n--jyh\n\n\n\n','<CAPoubz7hbHoQAQ133HCRi=FnZizzo=Lkokk7ke755k2c57sPMg@mail.gmail.com>',NULL),('<1389933486-sup-5576@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 20:59:09',-28800,'2014-01-17 04:59:09',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','Excerpts from Jay Pipes\'s message of 2014-01-12 11:40:41 -0800:\n> On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:\n> > >> So, it\'s not as simple as it may initially seem :)\n> > >\n> > > Ah, I should have been clearer in my statement - my understanding is that\n> > > we\'re scrapping concepts like Rack entirely.\n> > \n> > That was my understanding as well. The existing Tuskar domain model was \n> > largely placeholder/proof of concept and didn\'t necessarily reflect \n> > exactly what was desired/expected.\n> \n> Hmm, so this is a bit disappointing, though I may be less disappointed\n> if I knew that Ironic (or something else?) planned to account for\n> datacenter inventory in a more robust way than is currently modeled.\n> \n> If Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling\n> that an enterprise would use to deploy bare-metal hardware in a\n> continuous fashion, then the modeling of racks, and the attributes of\n> those racks -- location, power supply, etc -- are a critical part of the\n> overall picture.\n> \n\nTo be clear, the goal first is to have them be the deployment tooling that\n_somebody_ would use in production. \"Enterprise\" is pretty amorphous. If\nI\'m running a start-up but it is a start-up that puts all of its money\ninto a 5000 node public cloud, am I enterprise?\n\nNothing in the direction that has been laid out precludes Tuskar and\nIronic from consuming one of the _many_ data center inventory management\nsolutions and CMDB\'s that exist now.\n\nIf there is a need for OpenStack to grow one, I think we will. Lord\nknows we\'ve reinvented half the rest of the things we needed. ;-)\n\nFor now I think Tuskar should focus on feeding multiple groups into Nova,\nand Nova and Ironic should focus on making sure they can handle multiple\ngroup memberships for compute resources and schedule appropriately. Do\nthat and it will be relatively straight forward to adapt to racks, pods,\npower supplies, or cooling towers.\n\n> As an example of why something like power supply is important... inside\n> AT&T, we had both 8kW and 16kW power supplies in our datacenters. For a\n> 42U or 44U rack, deployments would be limited to a certain number of\n> compute nodes, based on that power supply.\n> \n> The average power draw for a particular vendor model of compute worker\n> would be used in determining the level of compute node packing that\n> could occur for that rack type within a particular datacenter. This was\n> a fundamental part of datacenter deployment and planning. If the tooling\n> intended to do bare-metal deployment of OpenStack in a continual manner\n> does not plan to account for these kinds of things, then the chances\n> that tooling will be used in enterprise deployments is diminished.\n> \n\nRight the math can be done in advance and racks/psus/boxes grouped\nappropriately. Packing is one of those things that we need a \"wholistic\"\nscheduler for to be fully automated. I\'m not convinced that is even a\nmid-term win, when there are so many big use-cases that can be handled\nwith so much less complexity.\n\n> And, as we all know, when something isn\'t used, it withers. That\'s the\n> last thing I want to happen here. I want all of this to be the\n> bare-metal deployment tooling that is used *by default* in enterprise\n> OpenStack deployments, because the tooling \"fits\" the expectations of\n> datacenter deployers.\n> \n> It doesn\'t have to be done tomorrow :) It just needs to be on the map\n> somewhere. I\'m not sure if Ironic is the place to put this kind of\n> modeling -- I thought Tuskar was going to be that thing. But really,\n> IMO, it should be on the roadmap somewhere.\n\nI agree, however I think the primitive capabilities, informed by helpful\nuse-cases such as the one you describe above, need to be understood\nbefore we go off and try to model a UI around them.\n\n\n','<1389555641.23412.95.camel@cranky>',NULL),('<1389935378-sup-6231@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-16 21:15:49',-28800,'2014-01-17 05:15:49',NULL,'[openstack-dev] Proposal for dd disk i/o performance blueprint\n	of cinder.','Excerpts from Alan Kavanagh\'s message of 2014-01-16 20:28:05 -0800:\n> +1....makes sense to me. I will write up a Blueprint for this for review in Ironic and we take it from their. \n> \n> I don\'t see this as evil firmware, more a good process we need to automate as part of sanity checks before taking a leased baremetal back and making it available in the pool again, imho. Or do others see it differently, if so would like to hear so.\n> \n\nI think the effort that will go into chasing every piece of firmware\nand block of NVRAM where malicious tenants can stuff exploits would be\nbetter spent improving the performance of virtualization. I have no data\nto prove this.\n\nHowever what strikes me is that we _know_ how virtualization interacts\nwith the hardware, and can control PCI pass through and other potential\nplaces for malicious users to try and plant malware for the next tenant. I\nhave no idea what firmware does, as much of it is just opaque binary\nblobs, and thus I have no idea what secondary parts of the hardware it may\nexpect to be in a certain state that a bad actor may take advantage of.\n\nIf hardware vendors will stand by an automated way to do factory resets,\nthen perhaps that would be something Ironic could enable. But even that\nbecomes problematic.. because you want to factory reset everything.. and\nthen you need the factory defaults to be secure enough where you can\nuse them to re-initialize the hardware.\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E5BDE9E@eusaamb109.ericsson.se>',NULL),('<1389963403.7857.0.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 07:56:43',-18000,'2014-01-17 12:56:43',NULL,'[openstack-dev] [QA] The future of nosetests with Tempest','On Thu, 2014-01-16 at 22:56 -0500, Matthew Treinish wrote:\n> Hi everyone,\n> \n> With some recent changes made to Tempest compatibility with nosetests is going\n> away. We\'ve started using newer features that nose just doesn\'t support. One\n> example of this is that we\'ve started using testscenarios and we\'re planning to\n> do this in more places moving forward.\n> \n> So at Icehouse-3 I\'m planning to push the patch out to remove nosetests from the\n> requirements list and all the workarounds and references to nose will be pulled\n> out of the tree. Tempest will also start raising an unsupported exception when\n> you try to run it with nose so that there isn\'t any confusion on this moving\n> forward. We talked about doing this at summit briefly and I\'ve brought it up a\n> couple of times before, but I believe it is time to do this now. I feel for\n> tempest to move forward we need to do this now so that there isn\'t any ambiguity\n> as we add even more features and new types of testing.\n> \n> Now, this will have implications for people running tempest with python 2.6\n> since up until now we\'ve set nosetests. There is a workaround for getting\n> tempest to run with python 2.6 and testr see:\n> \n> https://review.openstack.org/#/c/59007/1/README.rst\n> \n> but essentially this means that when nose is marked as unsupported on tempest\n> python 2.6 will also be unsupported by Tempest. (which honestly it basically has\n> been for while now just we\'ve gone without making it official)\n\nThanks for the excellent explanation, Matthew, the above all makes\nsense.\n\n+1\n\nBest,\n-jay\n\n\n\n','<20140117035653.GA915@kortar.treinish>',NULL),('<1389968582.7857.6.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 09:23:02',-18000,'2014-01-17 14:23:02',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','On Thu, 2014-01-16 at 20:59 -0800, Clint Byrum wrote:\n> Excerpts from Jay Pipes\'s message of 2014-01-12 11:40:41 -0800:\n> > On Fri, 2014-01-10 at 10:28 -0500, Jay Dobies wrote:\n> > > >> So, it\'s not as simple as it may initially seem :)\n> > > >\n> > > > Ah, I should have been clearer in my statement - my understanding is that\n> > > > we\'re scrapping concepts like Rack entirely.\n> > > \n> > > That was my understanding as well. The existing Tuskar domain model was \n> > > largely placeholder/proof of concept and didn\'t necessarily reflect \n> > > exactly what was desired/expected.\n> > \n> > Hmm, so this is a bit disappointing, though I may be less disappointed\n> > if I knew that Ironic (or something else?) planned to account for\n> > datacenter inventory in a more robust way than is currently modeled.\n> > \n> > If Triple-O/Ironic/Tuskar are indeed meant to be the deployment tooling\n> > that an enterprise would use to deploy bare-metal hardware in a\n> > continuous fashion, then the modeling of racks, and the attributes of\n> > those racks -- location, power supply, etc -- are a critical part of the\n> > overall picture.\n> > \n> \n> To be clear, the goal first is to have them be the deployment tooling that\n> _somebody_ would use in production. \"Enterprise\" is pretty amorphous. If\n> I\'m running a start-up but it is a start-up that puts all of its money\n> into a 5000 node public cloud, am I enterprise?\n\nI, too, hate the term \"enterprise\". Sorry for using it.\n\nIn my post, you can replace \"enterprise\" with \"business that has legacy\nhardware inventory or datacenter deployment tooling/practices already in\nplace\".\n\n> Nothing in the direction that has been laid out precludes Tuskar and\n> Ironic from consuming one of the _many_ data center inventory management\n> solutions and CMDB\'s that exist now.\n\nOK, cool.\n\n> If there is a need for OpenStack to grow one, I think we will. Lord\n> knows we\'ve reinvented half the rest of the things we needed. ;-)\n\nLOL, touch?.\n\n> For now I think Tuskar should focus on feeding multiple groups into Nova,\n> and Nova and Ironic should focus on making sure they can handle multiple\n> group memberships for compute resources and schedule appropriately. Do\n> that and it will be relatively straight forward to adapt to racks, pods,\n> power supplies, or cooling towers.\n\nCompletely agreed, which is why I say in my post \"have it somewhere on\nthe roadmap\" and \"doesn\'t have to be done tomorrow\".\n\n> > As an example of why something like power supply is important... inside\n> > AT&T, we had both 8kW and 16kW power supplies in our datacenters. For a\n> > 42U or 44U rack, deployments would be limited to a certain number of\n> > compute nodes, based on that power supply.\n> > \n> > The average power draw for a particular vendor model of compute worker\n> > would be used in determining the level of compute node packing that\n> > could occur for that rack type within a particular datacenter. This was\n> > a fundamental part of datacenter deployment and planning. If the tooling\n> > intended to do bare-metal deployment of OpenStack in a continual manner\n> > does not plan to account for these kinds of things, then the chances\n> > that tooling will be used in enterprise deployments is diminished.\n> \n> Right the math can be done in advance and racks/psus/boxes grouped\n> appropriately. Packing is one of those things that we need a \"wholistic\"\n> scheduler for to be fully automated. I\'m not convinced that is even a\n> mid-term win, when there are so many big use-cases that can be handled\n> with so much less complexity.\n\nNo disagreement from me at all.\n\n> > And, as we all know, when something isn\'t used, it withers. That\'s the\n> > last thing I want to happen here. I want all of this to be the\n> > bare-metal deployment tooling that is used *by default* in enterprise\n> > OpenStack deployments, because the tooling \"fits\" the expectations of\n> > datacenter deployers.\n> > \n> > It doesn\'t have to be done tomorrow :) It just needs to be on the map\n> > somewhere. I\'m not sure if Ironic is the place to put this kind of\n> > modeling -- I thought Tuskar was going to be that thing. But really,\n> > IMO, it should be on the roadmap somewhere.\n> \n> I agree, however I think the primitive capabilities, informed by helpful\n> use-cases such as the one you describe above, need to be understood\n> before we go off and try to model a UI around them.\n\nYup, totally. I\'ll keep a-lurking and following along various threads,\noffering insight where I can.\n\nBest,\n-jay\n\n\n\n','<1389933486-sup-5576@fewbar.com>',NULL),('<1389969442.7857.8.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 09:37:22',-18000,'2014-01-17 14:37:22',NULL,'[openstack-dev] [ ceilometer] The Pagination patches','On Fri, 2014-01-17 at 06:59 +0000, Gao, Fengqian wrote:\n> Hi, Jay,\n> \n> Thanks for your reply.\n> According to you review comments, I rebase my code, please see my comments for your questions.\n> For the issue that ensure there is at least one unique column in the sort keys if pagination is used, I have an idea.\n> How about add the primary key at the end of sort keys list passed from users?\n\nThanks, Fengqian,\n\nYes, that is exactly what I was thinking... make a helper method that\nwraps paginate_query() and looks at the sort_keys and, if there is no\ncolumn that is unique, it will append the primary key column(s) to the\nsort keys.\n\nI\'ll review your latest patches later today (currently up in Montreal at\nthe Neutron/Tempest QA code sprint, so a little delayed...)\n\nBest,\n-jay\n\n> --fengqian\n> \n> -----Original Message-----\n> From: Jay Pipes [mailto:jaypipes at gmail.com] \n> Sent: Monday, January 13, 2014 5:10 AM\n> To: Gao, Fengqian\n> Cc: Julien Danjou (julien at danjou.info); Doug Hellmann (doug.hellmann at dreamhost.com); Lu, Lianhao; chungg at ca.ibm.com; dperaza at linux.vnet.ibm.com; akornienko at mirantis.com; openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev][ ceilometer] The Pagination patches\n> \n> On Fri, 2014-01-10 at 03:31 +0000, Gao, Fengqian wrote:\n> > Since we still have no new conclusion for pagination for now, shall we \n> > still go on with the current pagination solution?\n> > \n> > Please help to review patches:\n> > \n> > https://review.openstack.org/#/c/41869/\n> > https://review.openstack.org/#/c/35454/\n> \n> Hi Fengqian,\n> \n> Please see my review on the first of the above patches. You need to ensure that there is at least one unique column in the sort keys if pagination is used.\n> \n> There is a similar issue in the second patch (reviewing it now) that uses the sqlalchemy_utils (oslo.db) paginate_query() method...\n> \n> The sqlalchemy_utils.paginate_query() method **requires** that sort_keys contains a unique column [1]. The docstring for that method says:\n> \n> \"Pagination works by requiring a unique sort_key, specified by sort_keys. (If sort_keys is not unique, then we risk looping through values.)\"\n> \n> So, care must be taken to pass sort_keys parameter to paginate_query() that already contains at least one unique column in the sort keys.\n> \n> Best,\n> -jay\n> \n> [1]\n> https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L66\n> \n> \n\n\n\n\n','<2B1FAA7A105B4A4D8AE1ED8CE67ABE6101954E2F@SHSMSX101.ccr.corp.intel.com>',NULL),('<1389973197.7857.9.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-17 10:39:57',-18000,'2014-01-17 15:39:57',NULL,'[Openstack-operators] [grizzly][quantum] Router/DHCP interface\n OVS port tags not reliably implementing','I believe you may want to upgrade to OVS 1.11+ and see if the problem\npersists.\n\nBest,\n-jay\n\nOn Fri, 2014-01-17 at 13:32 +0200, Jesse Pretorius wrote:\n> I\'m getting inconsistent implementations of port tags for router\n> internal interfaces and DHCP interfaces when they\'re created in OVS by\n> the Quantum OVS Plugin.\n> \n> The resulting symptom is that when a new network/subnet is created\n> then either the instance is not able to get a DHCP address (this is\n> when the dhcp port isn\'t tagged) or the instance is unable to\n> communicate outside of its network (this is when the internal router\n> interface port isn\'t tagged).\n> \n> Environment:\n>  - Ubuntu 12.04.3 LTS\n>  - Grizzly 2013.1.3-0ubuntu1~cloud0\n>  - Quantum with GRE Tunneling\n>  - OpenVSwitch 1.4.0-1ubuntu1.5\n> \n> For example, what I should be seeing is something like this:\n> \n>         Port \"tap7ef1ee95-52\"\n>             tag: 30\n>             Interface \"tap7ef1ee95-52\"\n>                 type: internal\n>         Port \"qr-8bfc6675-3a\"\n>             tag: 13\n>             Interface \"qr-8bfc6675-3a\"\n>                 type: internal\n> \n> However, I end up seeing something like this:\n> \n>         Port \"tap2b520e87-5e\"\n>             Interface \"tap2b520e87-5e\"\n>                 type: internal\n>         Port \"qr-ba0036f3-7e\"\n>             Interface \"qr-ba0036f3-7e\"\n>                 type: internal\n> \n> It\'s not consistently happening - sometimes it actually is done\n> correctly.\n> \n> The workaround to repair this is either to manually tag the interfaces\n> (which can be done if at least one of the ports on the subnet was\n> correctly tagged) or to restart \'quantum-plugin-openvswitch-agent\',\n> which unfortunately causes a drop in connectivity for those which were\n> correctly tagged.\n> \n> Has anyone else seen this?\n> \n> Does anyone know of a bug fix or perhaps a better workaround?\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<CAGSrQvyYqQzK8oXLenor6rDi4ETNoGCudQLvo3YhdPQ2HLrHow@mail.gmail.com>',NULL),('<1389974541.7857.11.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 11:02:21',-18000,'2014-01-17 16:02:21',NULL,'[openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters\n and samples delete','On Fri, 2014-01-17 at 12:43 +0200, Dmitry Iakunchikov wrote:\n> Ceilometer\'s tests creates some data which could not be deleted. \n> For example: after creation new instance, ceilometer creates new\n> meters for this instance and there  is no possibility to delete them.\n> Even after instance deletion they would not be deleted.\n> \n> Should we take attention to this? And find some way to delete all\n> data, for example database wipe or patch to ceilometer client...\n\nYes, I think it would be perfectly fine to mark the timestamp of the\nbeginning and end of the ceilometer OSTF tests and then just go into the\nbackend storage and remove any meters that are within that timestamp\nrange...\n\nBest,\n-jay\n\n\n\n\n','<CAKyex5i2Yqw9XHE4J-S4ich+5RwirKCqrUqUpjZU+dOhKm8eRQ@mail.gmail.com>',NULL),('<1389975045.7857.12.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 11:10:45',-18000,'2014-01-17 16:10:45',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n and Libra','On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:\n> Hi all,\n> \n> I\'ve been looking at Neutron default LBaaS provider using haproxy, and while it\'s working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy implementation in Neutron seems to continue to evolve (like with https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I\'m wondering why we can\'t leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example?\n\nYep, it\'s a completely duplicative and wasteful effort.\n\nIt would be great for Libra developers to contribute to Neutron LBaaS.\n\nBest,\n-jay\n\n\n\n','<1151664728.828163.1389965670318.JavaMail.root@enovance.com>',NULL),('<1389976555.7857.15.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-17 11:35:55',-18000,'2014-01-17 16:35:55',NULL,'[Openstack-operators] [grizzly][quantum] Router/DHCP interface\n OVS port tags not reliably implementing','On Fri, 2014-01-17 at 17:58 +0200, Jesse Pretorius wrote:\n> On 17 January 2014 17:39, Jay Pipes <jaypipes at gmail.com> wrote:\n>         I believe you may want to upgrade to OVS 1.11+ and see if the\n>         problem\n>         persists.\n> \n> \n> Thanks Jay, although I don\'t see where that package is available for\n> Precise? Precise-updates has the version that I have. Saucy seems to\n> have 1.10. It would seem that the only option is to compile from\n> source.\n\nYup :( That\'s exactly what we do in our Chef cookbooks...\n\n> Why specifically 1.11+?\n\nWe discovered bugs in 1.04 around how the L2 GRE mesh was created that\nallowed a single tenant to inadvertently flood the mesh with traffic and\neffectively bring the whole tenant networking down. No idea if it\'s\nrelated to what you\'re seeing, but we moved to OVS 1.11+ and did not\nhave the same issues, and performance/scalability was generally much\nbetter.\n\nBest,\n-jay  \n\n\n\n','<CAGSrQvzQBqeiVvDj1Ha-UKF6wj+ZaLCA2ETC=_Wtz+KMDbBTHQ@mail.gmail.com>',NULL),('<1389986971-sup-610@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 12:09:10',-28800,'2014-01-17 20:09:10',NULL,'[openstack-dev] [TripleO] milestone-proposed branches','tl;dr: You\'re right, it would be useful. Points on what is blocking it\nbelow:\n\nExcerpts from James Slagle\'s message of 2014-01-17 05:18:01 -0800:\n> On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > Note that tripleo-incubator is special and should not be released. It\n> > is intentionally kept unfrozen and unreleased to make sure there is no\n> > illusion of stability.\n> \n> I think it would be nice if we could point people at a devtest that\n> they could use with our other released stuff. Without that, we might\n> make a change to devtest, such as showing the use of a new heat\n> parameter in our templates, and if they\'re trying to follow along with\n> a released tripleo-heat-templates then they would have a problem.\n> \n> Without a branch of incubator, there\'s no story or documentation\n> around using any of our released stuff.  You could follow along with\n> devtest to get an idea of how it\'s supposed to work and indeed it\n> might even work, but I don\'t think that\'s good enough. There is\n> tooling in incubator that has proved it\'s usefulness. Take an example\n> like setup-endpoints, what we\'re effectively saying without allowing\n> people to use that is that there is a useful tool that will setup\n> endpoints for you, but don\'t use it with our released stuff because\n> it\'s not gauranteed to work and instead make these 10\'ish calls to\n> keystone via some other method. Then you\'d also end up with a\n> different but parallel set of instructions for using our released\n> stuff vs. not.\n> \n\nI\'ll address the bigger points here below, but for the record, I think\nsetup-endpoints and register-endpoint are stable enough now that they\nshould just be included with keystoneclient or keystone. Perhaps rewritten\nas subcommands to the keystone cli, but even as-is they would be useful\nin keystoneclient\'s bin dir IMO.\n\n> This is prohibitive to someone who may want to setup a tripleo CI/CD\n> cloud deploying stable icehouse or from milestone branches. I think\n> people would just create their own fork of tripleo-incubator and use\n> that.\n> \n> > If there are components in it that need releasing, they should be moved\n> > into relevant projects or forked into their own projects.\n> \n> I\'d be fine with that approach, except that\'s pretty much everything\n> in incubator, the scripts, templates, generated docs, etc. Instead of\n> creating a new forked repo, why don\'t we just rename tripleo-incubator\n> to tripleo-deployment and have some stable branches that people could\n> use with our releases?\n> \n> I don\'t feel like that precludes tripleo from having no stability on\n> the master branch at all.\n\nIf we are prepared to make basic release-to-release stability guarantees\nfor everything in incubator (or kick the few things we aren\'t prepared\nto do that for out to a new incubator) then huzzah! Lets do what you\nsuggest above. :)\n\nI just don\'t think we\'re there yet, and I\'d rather see us fork off the\nthings that are ready as they get to that point rather than try to make\na giant push to freeze the whole thing. I\'m afraid we\'d have users in a\nbad position by expecting the icehouse version of assert-user to still\nbe there and keep working in Juno.\n\nTo put some analysis where my rhetoric is, I\'ve taken a look at all\nof the scripts. By my count there are 43 scripts, 10 of which are not\nreally part of \"TripleO\". By lines of code, there are about 1954 lines\nof actual code and 600 lines in the \"not TripleO\" parts. So between 20\nand 30 percent of the code shouldn\'t be part of TripleO and should be\npushed into their own releasable places. I\'ve included the\nclassifications below.\n\nAlso before any of it gets released we need:\n\n* Gating\n* Commitment to real documentation\n* Thierry\'s blessing. :)\n\n==Script classifications==\n\nCD cloud related - never freezes\nassert-users\nassert-admin-users\nassert-user -- Perhaps merge with os-adduser\n\n--Belongs in keystoneclient\nsetup-endpoints\nregister-endpoint\nos-adduser -- Might need a rename?\n\n--Belongs in glanceclient:\nload-image\n\n--Could be forked into a tripleo-devtest project:\nboot-seed-vm\nsetup-network\nconfigure-vm\ncreate-nodes\nset-os-type\ndevtest_setup.sh\ndevtest_seed.sh\ndevtest_variables.sh\ndevtest.sh\nrefresh-env\ncleanup-env\ndevtest_ramdisk.sh\nextract-docs.awk\ndevtest_undercloud.sh\ndevtest_overcloud.sh\nwrite-tripleorc\ninstall-dependencies\ndevtest_end.sh\nregister-nodes\nextract-docs\ndevtest_testenv.sh\ntakeovernode\n\n--Not devtest only, releasable, but specific to TripleO:\ninit-keystone\nsetup-overcloud-passwords\npull-tools\nsetup-seed-vm\nstack-ready\nuser-config\nget-vm-mac\nsetup-clienttools\nsetup-neutron\nsetup-undercloud-passwords\nsetup-baremetal\n\n--Useful, but too tiny for their own repo:\nos-make-password -- arguably we should just use pwgen\nwait_for\nsend-irc\n\n\n','<CAHV77z84dT1YzhN0F6TRA5EgmeTTPnb5RQx_azNxYi0AFoFZHA@mail.gmail.com>',NULL),('<1389988410.7857.28.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 14:53:30',-18000,'2014-01-17 19:53:30',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n and Libra','On Fri, 2014-01-17 at 17:03 +0000, Andrew Hutchings wrote:\n> On 17 Jan 2014, at 16:10, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:\n> >> Hi all,\n> >> \n> >> I\'ve been looking at Neutron default LBaaS provider using haproxy, and while it\'s working nicely, it seems to have several shortcomings in terms of scalability and high availability. The Libra project seems to offer a more robust alternative, at least for scaling. The haproxy implementation in Neutron seems to continue to evolve (like with https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I\'m wondering why we can\'t leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example?\n> > \n> > Yep, it\'s a completely duplicative and wasteful effort.\n> > \n> > It would be great for Libra developers to contribute to Neutron LBaaS.\n> \n> Hi Jay and Thomas,\n> \n> I am the outgoing technical lead of Libra for HP.  But will reply whilst the new technical lead (Marc Pilon) gets subscribed to this.\n\n:( I had no idea, Andrew!\n\n> I would go as far as duplicative or wasteful. Libra existed before Neutron LBaaS and is originally based on the Atlas API specifications.  Neutron LBaaS has started duplicating some of our features recently which we find quite flattering.\n\nI presume you meant you would *not* go as far as duplicative or\nwasteful :)\n\nSo, please don\'t take this the wrong way... but does anyone other than\nHP run Libra? Likewise, does anyone other than Rackspace run Atlas?\n\nI find it a little difficult to comprehend why, if Libra preceded work\non Neutron LBaaS, that it wasn\'t used as the basis of Neutron\'s LBaaS\nwork. I can understand this for Atlas, since it\'s Java, but Libra is\nPython code... so it\'s even more confusing to me.\n\nGranted, I don\'t know the history of Neutron LBaaS, but it just seems to\nbe that this particular area (LBaaS) has such blatantly overlapping\ncodebases with separate contributor teams. Just baffling really.\n\nAny background or history you can give me (however opinionated!) would\nbe very much appreciated :)\n\n> After the 5.x release of Libra has been stabilised we will be working towards integration with Neutron.  It is a very important thing on our roadmap and we are already working with 2 other large companies in Openstack to figure that piece out.\n\nWhich large OpenStack companies? Are these companies currently deploying\nLibra?\n\nThanks,\n-jay\n\n> If anyone else wants to get involved or just wants to play with Libra I?m sure the HP team would be happy to hear about it and help where they can.\n> \n> Hope this helps\n> \n> Kind Regards\n> Andrew\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<401EA80F-E8D6-468D-BACB-09149CF2D496@linuxjedi.co.uk>',NULL),('<1389992328.26665.8.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-17 15:58:48',-18000,'2014-01-17 20:58:48',NULL,'[Openstack-docs] Group info in autogenerated config reference','I\'ve been doing a lot of work on the autohelp.py script that generates\nour reference tables of configuration options. One of the problems it\nhad was that it couldn\'t distinguish between options with the same name\nin different groups. For example, these are both options in nova:\n\n[spice]\nenabled = False\n\n[osapi_v3]\nenabled = False\n\nThe old code would duplicate these, putting the reference for both of\nthem in both nova-spice.xml and nova-apiv3.xml. I\'ve fixed that.\n\nBut the DocBook still doesn\'t specify the group, which is a pretty\nimportant piece of information to have. I\'m trying to think of a good\nway to add it, and I\'d like feedback. Currently we have:\n\n<td>option = default</td><td>help string</td>\n\nWe could do\n\n<td><programlisting>[group]\noption = default</td><td>help string</td>\n\nThat\'s a pretty good indication of how you\'d actually write the config\nfile, but it makes the tables longer. We could do\n\n<td>[group]</td><td>option = default</td><td>help string</td>\n\nThat makes the tables wider, and/or gives less space to the help string.\nOr we could write out separate tables for anything that\'s in a group\nother than DEFAULT, and put the group name in the caption.\n\nThoughts?\n\n--\nShaun\n\n\n\n\n',NULL,NULL),('<1389994375.7857.39.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 16:32:55',-18000,'2014-01-17 21:32:55',NULL,'[openstack-dev] [neutron]\n	[third-party-testing]	Sharing	information','On Thu, 2014-01-16 at 15:37 +0000, Sullivan, Jon Paul wrote:\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > On Thu, 2014-01-16 at 10:39 +0000, Sullivan, Jon Paul wrote:\n> > > > From: Kyle Mestery [mailto:mestery at siliconloons.com]\n> > > >	\n> > > > FYI, here [1] are the meeting logs from today?s meeting.\n> > > >\n> > > > A couple of things have become apparent here:\n> > > >\n> > > > 1. No one has a working Neutron 3rd party testing rig yet which is\n> > > > voting\n> > > >     consistently. If I?ve missed something, please, someone correct\n> > me.\n> > > > 2. People are still hung on issues around Jenkins/gerrit\n> > integration.\n> > >\n> > > This issue can be very easily resolved if people were to use Jenkins\n> > Job Builder [2] for the creation of their Jenkins testing jobs.  This\n> > would allow the reuse of simple macros already in existence to guarantee\n> > correct configuration of Jenkins jobs at 3rd party sites.  This would\n> > also allow simple reuse of the code used by the infra team to create the\n> > openstack review and gate jobs, ensuring 3rd party testers can generate\n> > the correct code from the gerrit change and also publish results back in\n> > a standard way.\n> > >\n> > > I can\'t recommend Jenkins Job Builder highly enough if you use\n> > Jenkins.\n> > >\n> > > [2] https://github.com/openstack-infra/jenkins-job-builder\n> > \n> > ++ It\'s a life-saver. We used it heavily in AT&T with our\n> > Gerrit/Jenkins/Zuul CI system.\n> > \n> > -jay\n> \n> It seems to me that shared JJB macros could be the most concise and simple way\n> of describing 3rd party testing integration requirements.\n> \n> So the follow-on questions are:\n> 1. Can the 3rd party testing blueprint enforce, or at least link to,\n>    use of specific JJB macros for integration to the openstack gerrit?\n>       1a. Where should shared JJB code be stored?\n\nWell, technically, this already exists. The openstack-infra/config\nproject already has pretty much everything a 3rd party would ever need\nto setup an OpenStack environment, execute Tempest (or other) tests\nagainst the environment, save and publish artifacts, and send\nnotifications of test results upstream.\n\n> 2. Is it appropriate for 3rd party testers to share their tests as\n>    JJB code, if they are willing?\n>       2a. Would this live in the same location as (1a)?\n\nWhy would 3rd party testers be using anything other than Tempest for\nintegration testing? Put another way... if a 3rd party *is* using\nsomething other than Tempest, why not put it in Tempest :)\n\n> For those unfamiliar with JJB, here is a little example of what you might do:\n> \n> Example of (untested) JJB macro describing how to configure Jenkins to\n> trigger from gerrit:\n> <snip>\n\nAs much as JJB is total awesomesauce -- as it prevents people needing to\nmanually update Jenkins job config.xml files -- any 3rd party that is\nattempting to put together a test environment/platform for which you\nintend to interact with the upstream CI system should go check out\ndevstack-gate [1], read the scripts, and grok it.\n\nI\'m working on some instructions to assist admins in 3rd party testing\nlabs in setting all of their platform up using the upstream tools like\ndevstack-gate and JJB, and this documentation should be done around\nmiddle of next week. I\'ll post to the ML with links to that\ndocumentation when it\'s done.\n\nBest,\n-jay\n\n[1] https://github.com/openstack-infra/devstack-gate\n\n\n\n','<A5492763B7A1E640AEB5E1C05208B1F254334FC4@G9W0759.americas.hpqcorp.net>',NULL),('<1389998459.25533.38.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 14:40:59',-28800,'2014-01-17 22:40:59',NULL,'[openstack-dev] [Nova] why don\'t we deal with \"claims\" when\n live migrating an instance?','On Fri, 2014-01-17 at 09:39 -0800, Vishvananda Ishaya wrote:\n> \n> On Jan 16, 2014, at 9:41 PM, Jiang, Yunhong <yunhong.jiang at intel.com>\n> wrote:\n> \n> > I noticed the BP has been approved, but I really want to understand\n> > more on the reason, can anyone provide me some hints?\n> >  \n> > In the BP, it states that ?For resize, we need to confirm, as we\n> > want to give end user an opportunity to rollback?. But why do we\n> > want to give user an opportunity to rollback to resize? And why that\n> > reason does not apply to cold migration and live migration?\n> \n> \n> The confirm is so the user can verify that the instance is still\n> functional in the new state. We leave the old instance around so they\n> can abort and return to the old instance if something goes wrong. This\n> could apply to cold migration as well since it uses the same code\n> paths, but it definitely does not make sense in the case of\n> live-migration, because there is no old vm to revert to.\n\nThanks for clarification.\n> \n> In the case of cold migration, the state is quite confusing as\n> ?RESIZE_VERIFY?, and the need to confirm is not immediately obvious so\n> I think that is driving the change.\n> \nI didn\'t saw patch to change the state in that BP, so possibly it\'s\nstill on way.\n\nSo basically the idea is, while we keep the implementation code path\ncombined for resize/code migration as much as possible, but we will keep\nthem different from user point of view, like different configuration\noption, different state etc, right?\n> \n--jyh\n\n\n\n\n\n\n','<393FC184-0A48-45BB-BA31-F3B9C56EB122@gmail.com>',NULL),('<1389998727.25533.40.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 14:45:27',-28800,'2014-01-17 22:45:27',NULL,'[openstack-dev] [OpenStack][Nova][compute] Why prune all\n compute node stats when sync up compute nodes','On Thu, 2014-01-16 at 00:22 +0800, Jay Lau wrote:\n> Greeting,\n> \n> In compute/manager.py, there is a periodic task named as\n> update_available_resource(), it will update resource for each compute\n> periodically.\n> \n>  @periodic_task.periodic_task\n>     def update_available_resource(self, context):\n>         \"\"\"See driver.get_available_resource()\n> \n>         Periodic process that keeps that the compute host\'s\n> understanding of\n>         resource availability and usage in sync with the underlying\n> hypervisor.\n> \n>         :param context: security context\n>         \"\"\"\n>         new_resource_tracker_dict = {}\n>         nodenames = set(self.driver.get_available_nodes())\n>         for nodename in nodenames:\n>             rt = self._get_resource_tracker(nodename)\n>             rt.update_available_resource(context) <<<<<<<<<< Update\n> here\n>             new_resource_tracker_dict[nodename] = rt\n> \n> In resource_tracker.py,\n> https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L384\n> \n> self._update(context, resources, prune_stats=True)\n> \n> It always set prune_stats as True, this caused some problems for me.\n> As now I\'m putting some metrics to compute_node_stats table, those\n> metrics does not change frequently, so I did not update it frequently.\n> But the periodic task always prune the new metrics that I added.\n\n> \nIIUC, it\'s because the host resource may change dynamically, at least in\noriginal design?\n\n> What about add a configuration parameter in nova.cont to make\n> prune_stats as configurable?\n\nInstead of make prune_stats to be configuration, will it make more sense\nto be lazy update, i.e. not update the DB if no changes?\n> \n> Thanks,\n> \n> \n> Jay\n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAFyztAHvBphK6=g2n5kTgwLZ6XnDj-Ev8T82RNdwm1jABk1vCA@mail.gmail.com>',NULL),('<138AD4B2-05B6-4E87-8B44-4FF58CA251B9@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 11:44:53',-28800,'2014-11-19 19:44:53',NULL,'[openstack-dev] [api] Summit summary','On Nov 19, 2014, at 11:38, Everett Toews <everett.toews at RACKSPACE.COM> wrote:\n\n> Does anybody know what happened to the Etherpad? It?s completely blank now!!!\n> \n> If you check the Timeslider, it appears that it only ever existed on Nov. 15. Bizarre.\n\nI see it as blank now too, however I can see all of the previous revisions and content when I drag the timeslider back.\n\nmelanie (melwitt)\n\n\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/e3ba8edc/attachment.pgp>\n\n','<E96E61F8-7591-40A8-9D27-74949E7BEC42@rackspace.com>',NULL),('<1390003392.3949.15.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-17 16:03:12',-28800,'2014-01-18 00:03:12',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','On Fri, 2014-01-17 at 22:30 +0000, Robert Li (baoli) wrote:\n> Yunhong,\n> \n> I\'m hoping that these comments can be directly addressed:\n>       a practical deployment scenario that requires arbitrary\n> attributes.\n\nI\'m just strongly against to support only one attributes (your PCI\ngroup) for scheduling and management, that\'s really TOO limited.\n\nA simple scenario is, I have 3 encryption card:\n	Card 1 (vendor_id is V1, device_id =0xa)\n	card 2(vendor_id is V1, device_id=0xb)\n	card 3(vendor_id is V2, device_id=0xb)\n\n	I have two images. One image only support Card 1 and another image\nsupport Card 1/3 (or any other combination of the 3 card type). I don\'t\nonly one attributes will meet such requirement.\n\nAs to arbitrary attributes or limited list of attributes, my opinion is,\nas there are so many type of PCI devices and so many potential of PCI\ndevices usage, support arbitrary attributes will make our effort more\nflexible, if we can push the implementation into the tree.\n\n>       detailed design on the following (that also take into account\n> the\n> introduction of predefined attributes):\n>         * PCI stats report since the scheduler is stats based\n\nI don\'t think there are much difference with current implementation.\n\n>         * the scheduler in support of PCI flavors with arbitrary\n> attributes and potential overlapping.\n\nAs Ian said, we need make sure the pci_stats and the PCI flavor have the\nsame set of attributes, so I don\'t think there are much difference with\ncurrent implementation.\n\n>       networking requirements to support multiple provider\n> nets/physical\n> nets\n\nCan\'t the extra info resolve this issue? Can you elaborate the issue?\n\nThanks\n--jyh\n> \n> I guess that the above will become clear as the discussion goes on.\n> And we\n> also need to define the deliveries\n>  \n> Thanks,\n> Robert \n\n\n\n','<CEFF17B8.39ED9%baoli@cisco.com>',NULL),('<1390028989-sup-6373@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-01-17 23:14:11',-28800,'2014-01-18 07:14:11',NULL,'[OpenStack-Infra] Please turn off verification voting for Big\n	Switch CI','Excerpts from Mohammad Banikazemi\'s message of 2014-01-17 14:18:17 -0800:\n> \n> Thanks Sumit.\n> \n> I did not particularly care about the vote on my patch as the patch has a\n> -2 vote already (until we have our own 3rd party testing set up). I got\n> worried that other patches will receive the -1 and people all over will get\n> blocked. So that\'s why I got alarmed.\n> \n> There is one other point I would like to make: A 3rd party test shouldn\'t\n> be triggered on patches to a different plugin. Does that make sense?\n> \n> Here is an excerpt From [1]  under Testing Requirements:\n> \n> The Neutron team expects that the third party testing will provide a +/-1\n> verify vote for all changes to a plugin or driver?s code. In addition, the\n> Neutron team expects that the third party test will also vote on all code\n> submissions by the jenkins user.\n> \n> \n> The above should be perhaps modified to indicate the no -1 vote policy but\n> beyond that it says that essentially the 3rd party test needs to be done on\n> the corresponding plugin (and the Jenkins submissions).\n\nAs a concerned developer and user, allow me to register my dissent with\nthis position.\n\nWe don\'t have asymmetrical gates in OpenStack. If you\'re going to be\nin the gate, you\'re in the gate for _every_ change. Plugins _should_ be\nisolated, but if they\'re not, we may not find that unless we test _all_\nchanges with the plugin\'s integration tests.\n\nIMO, we should hold 3rd parties to a standard where if they\'re going to\nbe in the gate, they\'re reliable enough to do -1. Otherwise what is the\npoint of their +1\'s?\n\nI do acknowledge that I didn\'t get a bunch of patches -1\'d and thus I\nmay not understand the full impact of this situation.\n\n\n','<OFE105D8D1.706DDE17-ON85257C63.007A50B3-85257C63.007A867D@us.ibm.com>',NULL),('<1390055141.24304.5.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-18 09:25:41',-18000,'2014-01-18 14:25:41',NULL,'[Openstack-docs] Group info in autogenerated config reference','On Sat, 2014-01-18 at 07:49 -0600, Anne Gentle wrote:\n> I\'m leaning towards a full row for [DEFAULT] and other sections, like\n> Andreas describes. Then the filename itself is clear because it\'s\n> grouped in a table. \n\nI agree. I don\'t know why I didn\'t think of doing it that way.\n\n> One design oddity that sticks out is, why are there groupings if\n> they\'re not also logically in a single table anyway? Are devs picking\n> poor groupings or are there too many items in DEFAULT? I ask because I\n> would think the groupings would help with the mappings.\n\nIn some cases, it could be that we\'ve categorized poorly. Which options\ngo into which tables is entirely on our end. We might get some wrong.\nBut I think there\'s also inconsistency in whether developers even use\ngroups. When you have so many people working on a code base so large\nwith so many options, that\'s bound to happen.\n\nHaving the group in the flagmappings has made it easier for me to pick\ncategories though. And it helps to point out possible inconsistencies.\nFor example, the only [database] option in nova that isn\'t \"db\" is\nuse_tpool. Is that right? I don\'t know. But I never would have even\nnoticed without the group info. \n\n\n> Thanks for asking Shaun!\n> Anne\n> \n> \n> \n> \n> \n> \n> On Sat, Jan 18, 2014 at 2:13 AM, Andreas Jaeger <aj at suse.com> wrote:\n>         On 01/17/2014 09:58 PM, Shaun McCance wrote:\n>         > I\'ve been doing a lot of work on the autohelp.py script that\n>         generates\n>         > our reference tables of configuration options. One of the\n>         problems it\n>         > had was that it couldn\'t distinguish between options with\n>         the same name\n>         > in different groups. For example, these are both options in\n>         nova:\n>         >\n>         > [spice]\n>         > enabled = False\n>         >\n>         > [osapi_v3]\n>         > enabled = False\n>         >\n>         > The old code would duplicate these, putting the reference\n>         for both of\n>         > them in both nova-spice.xml and nova-apiv3.xml. I\'ve fixed\n>         that.\n>         >\n>         > But the DocBook still doesn\'t specify the group, which is a\n>         pretty\n>         > important piece of information to have. I\'m trying to think\n>         of a good\n>         > way to add it, and I\'d like feedback. Currently we have:\n>         >\n>         > <td>option = default</td><td>help string</td>\n>         >\n>         > We could do\n>         >\n>         > <td><programlisting>[group]\n>         > option = default</td><td>help string</td>\n>         >\n>         > That\'s a pretty good indication of how you\'d actually write\n>         the config\n>         > file, but it makes the tables longer. We could do\n>         >\n>         > <td>[group]</td><td>option = default</td><td>help\n>         string</td>\n>         >\n>         > That makes the tables wider, and/or gives less space to the\n>         help string.\n>         > Or we could write out separate tables for anything that\'s in\n>         a group\n>         > other than DEFAULT, and put the group name in the caption.\n>         >\n>         > Thoughts?\n>         \n>         \n>         I would do it similar to how the conf files look like, for\n>         example for\n>         this snippet\n>         [DEFAULT]\n>         option1 = text\n>         [database]\n>         connection= text\n>         \n>         This would be:\n>         <th>\n>         <tr>\n>         <td>option = default</td><td>help string</td>\n>         \n>         </tr>\n>         </th>\n>         <tbody>\n>         <tr>\n>         <th colspan=\"2\"><code>[DEFAULT]</code></th></tr>\n>         <tr>\n>         <td>option1 = text</td><td>Explanation</td>\n>         </tr>\n>         <th colspan=\"2\"><code>[database]</code></th></tr>\n>         <tr>connection = text...\n>         \n>         So, use a separate header line for each new section,\n>         \n>         Andreas\n>         --\n>          Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica:\n>         jaegerandi\n>           SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg,\n>         Germany\n>            GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG\n>         N?rnberg)\n>             GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C\n>         C272 A126\n>         \n>         _______________________________________________\n>         Openstack-docs mailing list\n>         Openstack-docs at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>         \n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<CAD0KtVECQwC8vUuPd0L86T2mxtqFcV2cS5su=NVgyHKO4BdAFg@mail.gmail.com>',NULL),('<1390068921.2168.6.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 13:15:21',-18000,'2014-01-18 18:15:21',NULL,'[openstack-dev] [Diesel] Proposal for new project','On Sat, 2014-01-18 at 03:31 +0000, Raymond, Rob wrote:\n> I would like to gauge interest in a new project named Diesel.\n> \n> https://wiki.openstack.org/wiki/Diesel\n> \n> If you are already familiar with Savanna, the best way to describe it is:\n> Savanna is to map reduce applications as Diesel is to web applications.\n> \n> The mission of Diesel is to allow OpenStack clouds to run applications.\n> The cloud administrator can control the non functional aspects, freeing up\n> the application developer to focus on their application and its\n> functionality.\n> \n> In the spirit of Google App Engine, Heroku, Engine Yard and others, Diesel\n> runs web applications in the cloud. It can be used by cloud administrators\n> to define the application types that they support. They are also\n> responsible for defining through Diesel how these applications run on top\n> of their cloud infrastructure. Diesel will control the availability and\n> scalability of the web application deployment.\n\nHi Rob,\n\nSo I\'ve read through the above wiki page a couple times, and I\'m really\nhaving trouble understanding how Diesel differs from Solum.\n\nIn the wiki page, you mention:\n\n\"Solum - Solum is focused on the development lifecycle for the\napplication. The application may be one that Diesel can run.\"\n\nCould you elaborate on how you envision how Diesel differs from Solum in\nits basic intent? Solum deploys applications into a cloud. Diesel is\nintended to \"run\" applications in clouds, but I\'m not sure how there is\na difference between deploying an application into a cloud and running\none.\n\nPerhaps I\'m just missing something, though, so perhaps you might\nelaboraste?\n\nBest,\n-jay\n\n\n\n','<CEFF4358.22B3%rob.raymond@hp.com>',NULL),('<1390071732.2168.17.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 14:02:12',-18000,'2014-01-18 19:02:12',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n and Libra','On Sat, 2014-01-18 at 09:06 +0000, Andrew Hutchings wrote:\n> \n> On 17 Jan 2014, at 19:53, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Fri, 2014-01-17 at 17:03 +0000, Andrew Hutchings wrote:\n> > > On 17 Jan 2014, at 16:10, Jay Pipes <jaypipes at gmail.com> wrote:\n> > > \n> > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:\n> > > > > Hi all,\n> > > > > \n> > > > > I\'ve been looking at Neutron default LBaaS provider using\n> > > > > haproxy, and while it\'s working nicely, it seems to have\n> > > > > several shortcomings in terms of scalability and high\n> > > > > availability. The Libra project seems to offer a more robust\n> > > > > alternative, at least for scaling. The haproxy implementation\n> > > > > in Neutron seems to continue to evolve (like with\n> > > > > https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy), but I\'m wondering why we can\'t leverage Libra. The APIs are a bit different, but the goals look very similar, and there is a waste of effort with 2 different implementations. Maybe we could see a Libra driver for Neutron LBaaS for example?\n> > > > \n> > > > Yep, it\'s a completely duplicative and wasteful effort.\n> > > > \n> > > > It would be great for Libra developers to contribute to Neutron\n> > > > LBaaS.\n> > > \n> > > Hi Jay and Thomas,\n> > > \n> > > I am the outgoing technical lead of Libra for HP.  But will reply\n> > > whilst the new technical lead (Marc Pilon) gets subscribed to\n> > > this.\n> > \n> > :( I had no idea, Andrew!\n> \n> Not a big deal, I have some cool stuff open source stuff in HP I?m\n> moving on to which I?m excited about and can help Openstack in other\n> ways.  You should hear about that in a few months time.\n\nCool. I look forward to that -- around summit time, eh?\n\n> > So, please don\'t take this the wrong way... but does anyone other\n> > than HP run Libra? Likewise, does anyone other than Rackspace run\n> > Atlas?\n> \n> No one else runs it in production that I know about, but there are\n> several trying it out and appearing to want to contribute.\n\nOK.\n\n> I find it a little difficult to comprehend why, if Libra preceded work\n> > on Neutron LBaaS, that it wasn\'t used as the basis of Neutron\'s\n> > LBaaS work. I can understand this for Atlas, since it\'s Java, but\n> > Libra is Python code... so it\'s even more confusing to me.\n> > \n> > Granted, I don\'t know the history of Neutron LBaaS, but it just\n> > seems to be that this particular area (LBaaS) has such blatantly\n> > overlapping codebases with separate contributor teams. Just baffling\n> > really.\n> > \n> > Any background or history you can give me (however opinionated!)\n> > would be very much appreciated :)\n> \n> I don?t know if we pre-dated the planning phase, judging by a later\n> email on this thread our planning phases were at the same time.  I\n> wasn?t a big part of the planning phase so it is difficult to comment\n> there.  But we had something we could use before we were in a place\n> where we could even try out Neutron.  Also to start with our API was\n> Java based (a Python replacement came later).\n\nK, good to understand.\n\n> > > After the 5.x release of Libra has been stabilised we will be\n> > > working towards integration with Neutron.  It is a very important\n> > > thing on our roadmap and we are already working with 2 other large\n> > > companies in Openstack to figure that piece out.\n> > \n> > Which large OpenStack companies? Are these companies currently\n> > deploying Libra?\n> \n> I?m not sure what is public and what isn?t so I won?t name names.\n> They are currently talking to us about the best ways of working with\n> us.  Both companies want to use Libra in different and interesting\n> ways.  They are not currently deploying it but are both playing with\n> it.  It is early days, they both approached us just before the\n> Christmas break.\n\nDid these companies say they had looked at Neutron LBaaS and found its\ndesign or implementation lacking in some way?\n\n> We know that working with the wider community with Libra has not been\n> our strong point.  It is something I want the team to rectify and they\n> are showing signs of making that happen.  People that are interested\n> in Libra are welcome to hang out in the #stackforge-libra IRC channel\n> to talk to us.\n\nCutting to the chase... have there been any discussions about the\nlong-term direction of Libra and Neutron LBaaS. I see little point\nhaving two OpenStack endpoints that implement the same basic load\nbalancing functionality.\n\nIs the main problem in aligning Libra and Neutron the fact that Libra is\na wholly-separate endpoint/project and Neutron LBaaS is part of the\nNeutron project?\n\nBest,\n-jay \n\n\n\n\n','<C5765F7F-129C-42A6-916D-180807C55631@linuxjedi.co.uk>',NULL),('<1390072461.5777.1.camel@debvm.dev-ninja.fr>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 20:14:21',3600,'2014-01-18 19:14:21',NULL,'[openstack-dev] [keystone] domain admin role query','Hi,\n\nFollowing-up on this thread (although late), I have detailed the steps\nallowing to have Keystone with multiple domains properly set:\nhttp://www.florentflament.com/blog/setting-keystone-v3-domains.html\n\nI hope that it may be useful for people willing to play with the\nIdentity v3 API and domains.\n\nFlorent Flament\n\nOn Wed, 2013-12-18 at 12:10 -0800, Ravi Chunduru wrote:\n> Thanks Dolph,\n>  It worked now. I specified domain id in the scope.\n> \n> \n> -Ravi.\n> \n> \n> On Wed, Dec 18, 2013 at 12:05 PM, Ravi Chunduru <ravivsn at gmail.com>\n> wrote:\n>         Hi Dolph,\n>           I dont have project yet to use in the scope. The intention\n>         is to get a token using domain admin credentials and create\n>         project using it.\n>         \n>         \n>         Thanks,\n>         -Ravi.\n>         \n>         \n>         On Wed, Dec 18, 2013 at 11:39 AM, Dolph Mathews\n>         <dolph.mathews at gmail.com> wrote:\n>                 \n>                 On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru\n>                 <ravivsn at gmail.com> wrote:\n>                         Thanks all for the information.\n>                         I have now v3 policies in place, the issue is\n>                         that as a domain admin I could not create a\n>                         project in the domain. I get 403 unauthorized\n>                         status.\n>                         \n>                         \n>                         I see that when as a  \'domain admin\' request a\n>                         token, the response did not have any roles.\n>                          In the token request, I couldnt specify the\n>                         project - as we are about to create the\n>                         project in next step.\n>                 \n>                 \n>                 Specify a domain as the \"scope\" to obtain domain-level\n>                 authorization in the resulting token.\n>                 \n>                 \n>                 See the third example under Scope:\n>                 \n>                 \n>                   https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#scope-scope\n>                  \n>                         \n>                         \n>                         Here is the complete request/response of all\n>                         the steps done.\n>                         https://gist.github.com/kumarcv/8015275\n>                         \n>                         \n>                         \n>                         I am assuming its a bug. Please let me know\n>                         your opinions.\n>                         \n>                         \n>                         Thanks,\n>                         -Ravi.\n>                         \n>                         \n>                         \n>                         \n>                         \n>                         \n>                         On Thu, Dec 12, 2013 at 3:00 PM, Henry Nash\n>                         <henryn at linux.vnet.ibm.com> wrote:\n>                                 Hi\n>                                 \n>                                 So the idea wasn\'t the you create a\n>                                 domain with the id of\n>                                 \'domain_admin_id\', rather that you\n>                                 create the domain that you plan to use\n>                                 for your admin domain, and then paste\n>                                 its (auto-generated) domain_id into\n>                                 the policy file.\n>                                 \n>                                 Henry\n>                                 On 12 Dec 2013, at 03:11, Paul\n>                                 Belanger\n>                                 <paul.belanger at polybeacon.com> wrote:\n>                                 \n>                                 > On 13-12-11 11:18 AM, Lyle, David\n>                                 wrote:\n>                                 >> +1 on moving the domain admin role\n>                                 rules to the default policy.json\n>                                 >>\n>                                 >> -David Lyle\n>                                 >>\n>                                 >> From: Dolph Mathews\n>                                 [mailto:dolph.mathews at gmail.com]\n>                                 >> Sent: Wednesday, December 11, 2013\n>                                 9:04 AM\n>                                 >> To: OpenStack Development Mailing\n>                                 List (not for usage questions)\n>                                 >> Subject: Re: [openstack-dev]\n>                                 [keystone] domain admin role query\n>                                 >>\n>                                 >>\n>                                 >> On Tue, Dec 10, 2013 at 10:49 PM,\n>                                 Jamie Lennox <jamielennox at redhat.com>\n>                                 wrote:\n>                                 >> Using the default policies it will\n>                                 simply check for the admin role and\n>                                 not care about the domain that admin\n>                                 is limited to. This is partially a\n>                                 left over from the V2 api when there\n>                                 wasn\'t domains to worry > about.\n>                                 >>\n>                                 >> A better example of policies are in\n>                                 the file\n>                                 etc/policy.v3cloudsample.json. In\n>                                 there you will see the rule for\n>                                 create_project is:\n>                                 >>\n>                                 >>   \"identity:create_project\":\n>                                 \"rule:admin_required and domain_id:\n>                                 %(project.domain_id)s\",\n>                                 >>\n>                                 >> as opposed to (in policy.json):\n>                                 >>\n>                                 >>   \"identity:create_project\":\n>                                 \"rule:admin_required\",\n>                                 >>\n>                                 >> This is what you are looking for to\n>                                 scope the admin role to a domain.\n>                                 >>\n>                                 >> We need to start moving the rules\n>                                 from policy.v3cloudsample.json to the\n>                                 default policy.json =)\n>                                 >>\n>                                 >>\n>                                 >> Jamie\n>                                 >>\n>                                 >> ----- Original Message -----\n>                                 >>> From: \"Ravi Chunduru\"\n>                                 <ravivsn at gmail.com>\n>                                 >>> To: \"OpenStack Development Mailing\n>                                 List\"\n>                                 <openstack-dev at lists.openstack.org>\n>                                 >>> Sent: Wednesday, 11 December, 2013\n>                                 11:23:15 AM\n>                                 >>> Subject: [openstack-dev]\n>                                 [keystone] domain admin role query\n>                                 >>>\n>                                 >>> Hi,\n>                                 >>> I am trying out Keystone V3 APIs\n>                                 and domains.\n>                                 >>> I created an domain, created a\n>                                 project in that domain, created an\n>                                 user in\n>                                 >>> that domain and project.\n>                                 >>> Next, gave an admin role for that\n>                                 user in that domain.\n>                                 >>>\n>                                 >>> I am assuming that user is now\n>                                 admin to that domain.\n>                                 >>> Now, I got a scoped token with\n>                                 that user, domain and project. With\n>                                 that\n>                                 >>> token, I tried to create a new\n>                                 project in that domain. It worked.\n>                                 >>>\n>                                 >>> But, using the same token, I could\n>                                 also create a new project in a\n>                                 \'default\'\n>                                 >>> domain too. I expected it should\n>                                 throw authentication error. Is it a\n>                                 bug?\n>                                 >>>\n>                                 >>> Thanks,\n>                                 >>> --\n>                                 >>> Ravi\n>                                 >>>\n>                                 >\n>                                 > One of the issues I had this week\n>                                 while using the\n>                                 policy.v3cloudsample.json was I had no\n>                                 easy way of creating a domain with the\n>                                 id of \'admin_domain_id\'.  I basically\n>                                 had to modify the SQL directly to do\n>                                 it.\n>                                 >\n>                                 > Any chance we can create a 2nd\n>                                 domain using \'admin_domain_id\' via\n>                                 keystone-manage sync_db?\n>                                 >\n>                                 > --\n>                                 > Paul Belanger | PolyBeacon, Inc.\n>                                 > Jabber: paul.belanger at polybeacon.com\n>                                 | IRC: pabelanger (Freenode)\n>                                 > Github:\n>                                 https://github.com/pabelanger |\n>                                 Twitter:\n>                                 https://twitter.com/pabelanger\n>                                 >\n>                                 >\n>                                 _______________________________________________\n>                                 > OpenStack-dev mailing list\n>                                 > OpenStack-dev at lists.openstack.org\n>                                 >\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                                 >\n>                                 \n>                                 \n>                                 \n>                                 _______________________________________________\n>                                 OpenStack-dev mailing list\n>                                 OpenStack-dev at lists.openstack.org\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                                 \n>                         \n>                         \n>                         \n>                         \n>                         -- \n>                         Ravi\n>                         \n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                 \n>                 \n>                 \n>                 \n>                 -- \n>                 \n>                 \n>                 -Dolph\n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         \n>         -- \n>         Ravi\n>         \n> \n> \n> \n> \n> -- \n> Ravi\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAEgw6ytLXRj9d5mzAnib6nyPtM3RJG+fhdFUEV167s-WOpAVOg@mail.gmail.com>',NULL),('<1390073374.2168.27.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 14:29:34',-18000,'2014-01-18 19:29:34',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n and Libra','On Fri, 2014-01-17 at 13:12 -0800, Alex Freedland wrote:\n> Andrew, Jay and all,\n> \n> Thank you for bringing this topic up. Incidentally, just a month ago\n> at OpenStack Israel I spoke to Monty and other HP folks about getting\n> the Libra initiatives integrated into LBaaS.  I am happy that this\n> discussion is now happening on the mailing list. \n> \n> I remember the history of how this got started. Mirantis was working\n> with a number of customers (GAP, PayPal, and a few others) who were\n> asking for LBaaS feature. At that time, Atlas was the default choice\n> in the community, but its Java-based implementation did not agree with\n> the rest of OpenStack. \n> \n> There was no Libra anywhere in the OpenStack sandbox, so we have\n> proposed a set of blueprints and Eugene Nikonorov and the team started\n> moving ahead with the implementation. Even before the code was\n> accepted into Quantum, a number of customers started to use it and a\n> number of vendors (F5, Radware, etc.) joined the community to add\n> there own plugins. \n> \n> Consequently, the decision was made to add LBaaS to Quantum (aka\n> Neutron).\n\nThanks for the above history, Alex, appreciated.\n\n> We would love to see the Libra developers join the Neutron team and\n> collaborate on the ways to bring the two initiatives together.\n\nAgreed. However, I\'m afraid progress towards alignment won\'t happen\nuntil there\'s a concerted effort between the two groups to resolve any\narchitectural differences and a create set of blueprints that outline\nthe work required to bring the best of both worlds together.\n\nBest,\n-jay \n\n\n\n\n','<CACbquAedZQ5aEsEL3J0jwBOv0CY9RK8pmYC+XyHM95rEsLiC5Q@mail.gmail.com>',NULL),('<1390076750-sup-1053@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-18 12:28:40',-28800,'2014-01-18 20:28:40',NULL,'[Openstack] About Openstack Installation','Excerpts from jeffty\'s message of 2014-01-18 03:25:07 -0800:\n> Hi Mayur,\n> \n> 4G is ok. Maybe you can try devstack, which will automatically install\n> openstack in on node for you. Although it use nova network with\n> FlatDHCPManager by default.\n> \n\nMayur did not state the final purpose of the cloud to build, but it is\nimportant to note, devstack is _not_ for production usage.\n\n> Here is the link:\n> \n> http://www.devstack.org\n> \n> You only need to?\n> \n> 1. Install a minimal Ubuntu (e.g. 12.04 LTS with only SSH service).\n> 2. Configure network to gain IP.\n> 3. Install git. e.g. apt-get -y install git\n> 4. Clone devstack. e.g. git clone\n> git://github.com/cloudbuilders/devstack.git\n\nThe official home for devstack is\nhttp://git.openstack.org/cgit/openstack-dev/devstack/\n\n> 5. Modify devstack\'s configuration file to define ip, password etc.\n> 6. Run devstack\'s installation script to install.\n> \n> Above can also be found in devstack\'s website.\n> \n> On 1/18/2014 6:15 PM, Mayur Patil wrote:\n> > Hi All, \n> > \n> >      I am newbie to Openstack. Prior to this I am having experience of\n> > using Eucalyptus.\n> > \n> >      So, my query is  \n> > \n> >      Recommended hardware is 16GB & 32GB RAM with two machines having at\n> > least dual\n> > \n> >      core processor.\n> > \n> >      But I am having Pentium Processor(VT enabled) & with 3 or 4 GB RAM  \n> > \n> >      (RAM can increase upto 8GB that I can afford) on each machine. \n> > \n> >      Then would these machines are feasible for Openstack installation?\n> > \n> >      Seeking for guidance,\n> > \n> >      Thanks !!\n> > -- \n> > *Cheers,\n> > Mayur*.\n> > \n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > \n> \n\n\n','<52DA6493.1020901@gmail.com>',NULL),('<1390079980-sup-3319@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-18 13:21:29',-28800,'2014-01-18 21:21:29',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n	and Libra','Excerpts from Jay Pipes\'s message of 2014-01-18 11:02:12 -0800:\n> Cutting to the chase... have there been any discussions about the\n> long-term direction of Libra and Neutron LBaaS. I see little point\n> having two OpenStack endpoints that implement the same basic load\n> balancing functionality.\n> \n> Is the main problem in aligning Libra and Neutron the fact that Libra is\n> a wholly-separate endpoint/project and Neutron LBaaS is part of the\n> Neutron project?\n\nIn the past I\'ve been told the only reason Libra/Atlas persist is that\nNeutron wasn\'t ready. To me that means \'lets go make Neutron better\'.\nBut then, I haven\'t been given any crazy short lead times for rolling\nout LBaaS.\n\n\n','<1390071732.2168.17.camel@serialcoder>',NULL),('<1390090380.237.1356655740076.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-28 00:49:00',0,'2012-12-28 00:49:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #88','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/88/>\n\n------------------------------------------\n[...truncated 11613 lines...]\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_reuse = True\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n# This should be the username of an alternate user WITHOUT\n# administrative privileges\nalt_username = alt_demo\n# The above non-administrative user\'s password\nalt_password = secret\n# The above non-administrative user\'s tenant name\nalt_tenant_name = alt_demo\n\n# Reference data for tests. The ref and ref_alt should be\n# distinct images/flavors.\nimage_ref = e0c7638d-2477-4c00-96ee-573c69a25f26\nimage_ref_alt = e0c7638d-2477-4c00-96ee-573c69a25f26\nflavor_ref = 1\nflavor_ref_alt = 2\n\n# Number of seconds to wait while looping to check the status of an\n# instance that is building.\nbuild_interval = 3\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... ok\nCREATE, GET, DELETE Volume ... ERROR\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nSKIP: VolumesActionsTest skipped as Cinder endpoint is not available\nSKIP: VolumesGetTestJSON skipped as Cinder endpoint is not available\nSKIP: VolumesGetTestXML skipped as Cinder endpoint is not available\nSKIP: VolumeListTestJSON skipped as Cinder endpoint is not available\nSKIP: VolumeListTestXML skipped as Cinder endpoint is not available\n\n======================================================================\nERROR: CREATE, GET, DELETE Volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/test_volumes_get.py\", line 68, in test_volume_create_get_delete\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 260, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 39 tests in 1627.526s\n\nFAILED (SKIP=13, errors=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/rabbitmq/rabbit at devstack-1356645034-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/rabbitmq/rabbit at devstack-1356645034.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-n-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/88/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1390147734-sup-132@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-19 08:19:37',-28800,'2014-01-19 16:19:37',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n	and Libra','Excerpts from Thomas Herve\'s message of 2014-01-19 01:52:56 -0800:\n> \n> > Hi,\n> > \n> > I haven?t read through those (need to go spend time with family so replying\n> > quickly) but given the dates the planning phases for Quantum/Neutron LBaaS\n> > and Libra LBaaS were at the same time.\n> > \n> > There was an internal evaluation of the current LBaaS solutions done at the\n> > time and it was believed by the people evaluating that Atlas was a good\n> > place to start. I came in just as that evaluation had finished (late August\n> > 2012) and the decision was pretty much made. In retrospect I may have\n> > personally gone the Mirantis LBaaS as a starting point. But either way there\n> > were some good starting places.\n> > \n> > Libra was initially a few trees so history is hard to track, but we had\n> > something in production by December that year.\n> > \n> > In response to Alex, the Libra team in HP is growing (it is currently still\n> > pretty small) and that should help us have more engineers to work with the\n> > Neutron team. The current goal is to get 5.x out of the door which adds\n> > things like metering/billing support and then planning how we can integrate\n> > well with Neutron. I believe the Libra team have a few diagrams flying\n> > around on a mutually beneficial way of doing that.\n> \n> Hi Andrew,\n> \n> Thanks for the all the responses. I certainly didn\'t want to throw the blame at one of the team, but I think we should try to converge. In particular Neutron LBaaS would benefit greatly from having a big deployment like HP. I hope the 2 teams can find a way to collaborate.\n> \n> There are benefits to have a different endpoint like Libra proposes, although now that LBaaS is integrated in Neutron it\'s going to be difficult to change. There is a tension in OpenStack currently between keeping the projects lean (by having small, independent code bases) and making deployments easy (by not having to deploy dozens of projects). I feel we haven\'t found a great answer yet.\n> \n\nI actually don\'t think having less services makes deployment easier.\nIf you\'re not using automation, sure, its harder to install a bunch of\nthings, but I don\'t think OpenStack should waste any time for people\nstuck in the 1990\'s. If you have automation, LBaaS as its own service\nis identical to LBaaS as a neutron agent.\n\nIn this case I think another interesting aspect is that LBaaS being built\nin to Neutron means that it can take advantage of where Neutron sits\nin the networking stack. Being setup already as the default gateway for\nnodes allows for things like LVS-DR where the packets are not rewritten,\nthey\'re just sent to the appropriate port\'s MAC.\n\nAlso another thing to consider is that by growing a service as much as\nis possible without forcing people to deploy a service they don\'t want,\nyou reduce entropy in both development (less duplication of effort)\nand in production (less moving parts).\n\n\n','<1886984122.1239833.1390125176403.JavaMail.root@enovance.com>',NULL),('<1390170830.24304.7.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-19 17:33:50',-18000,'2014-01-19 22:33:50',NULL,'[Openstack-docs] Automated CLI Reference','To what extent could this reuse code from the automated config\nreference? Is it also a matter of importing tons of stuff then\nintrospecting the modules?\n\n--\nShaun\n\n\nOn Fri, 2014-01-17 at 15:52 -0600, Anne Gentle wrote:\n> Hi again all, \n> \n> \n> Are we doing any work towards automating a CLI reference? \n> \n> \n> I ask because at the Summit we talked like we wanted it, but I don\'t\n> know if it has an owner. \n> \n> \n> Thanks -\n> Anne\n> \n> \n> On Tue, Nov 5, 2013 at 11:46 AM, Anne Gentle <anne at openstack.org>\n> wrote:\n>         \n>         \n>         \n>         On Tue, Nov 5, 2013 at 8:10 AM, Diane Fleming\n>         <diane.fleming at rackspace.com> wrote:\n>                 Great summary!\n>                 \n>                 \n>                 As for Cli reference, what about doing what we do for\n>                 API ref? Just a web page with list of calls and ref\n>                 info? There really isn\'t enough info for a book (I\n>                 think). \n>          \n>         Yes, that\'s the idea, automated. The output could certainly\n>         look nicer than monspaced text. And we\'d gather into one\n>         deliverable so as to avoid the appendix listing at the end of\n>         both user guides. What do you think?\n>         \n>         The CLI reference would be the listings of commands and\n>         subcommands, once you get to subcommands there may be a\n>         100-page book in there. Maybe 200. Think of nova help for\n>         example. Then the output for nova help boot, which is rather\n>         large, but nova help add-fixed-ip is just:\n>         usage: nova add-fixed-ip <server> <network-id>\n>         \n>         Add new IP address on a network to server.\n>         \n>         Positional arguments:\n>           <server>      Name or ID of server.\n>           <network-id>  Network ID.\n>         \n>         Here\'s the output of nova help: \n>         usage: nova [--version] [--debug] [--os-cache] [--timings]\n>                     [--timeout <seconds>] [--os-username\n>         <auth-user-name>]\n>                     [--os-password <auth-password>]\n>                     [--os-tenant-name <auth-tenant-name>]\n>                     [--os-tenant-id <auth-tenant-id>] [--os-auth-url\n>         <auth-url>]\n>                     [--os-region-name <region-name>] [--os-auth-system\n>         <auth-system>]\n>                     [--service-type <service-type>] [--service-name\n>         <service-name>]\n>                     [--volume-service-name <volume-service-name>]\n>                     [--endpoint-type <endpoint-type>]\n>                     [--os-compute-api-version <compute-api-ver>]\n>                     [--os-cacert <ca-certificate>] [--insecure]\n>                     [--bypass-url <bypass-url>]\n>                     <subcommand> ...\n>         \n>         Command-line interface to the OpenStack Nova API.\n>         \n>         Positional arguments:\n>           <subcommand>\n>             absolute-limits     Print a list of absolute limits for a\n>         user\n>             add-fixed-ip        Add new IP address on a network to\n>         server.\n>             add-floating-ip     Add a floating IP address to a server.\n>             add-secgroup        Add a Security Group to a server.\n>             agent-create        Create new agent build.\n>             agent-delete        Delete existing agent build.\n>             agent-list          List all builds.\n>             agent-modify        Modify existing agent build.\n>             aggregate-add-host  Add the host to the specified\n>         aggregate.\n>             aggregate-create    Create a new aggregate with the\n>         specified details.\n>             aggregate-delete    Delete the aggregate.\n>             aggregate-details   Show details of the specified\n>         aggregate.\n>             aggregate-list      Print a list of all aggregates.\n>             aggregate-remove-host\n>                                 Remove the specified host from the\n>         specified\n>                                 aggregate.\n>             aggregate-set-metadata\n>                                 Update the metadata associated with\n>         the aggregate.\n>             aggregate-update    Update the aggregate\'s name and\n>         optionally\n>                                 availability zone.\n>             availability-zone-list\n>                                 List all the availability zones.\n>             backup              Backup a instance by create a \'backup\'\n>         type snapshot.\n>             boot                Boot a new server.\n>             clear-password      Clear password for a server.\n>             cloudpipe-configure\n>                                 Update the VPN IP/port of a cloudpipe\n>         instance.\n>             cloudpipe-create    Create a cloudpipe instance for the\n>         given project.\n>             cloudpipe-list      Print a list of all cloudpipe\n>         instances.\n>             console-log         Get console log output of a server.\n>             coverage-report     Generate coverage report.\n>             coverage-reset      Reset coverage data.\n>             coverage-start      Start Nova coverage reporting.\n>             coverage-stop       Stop Nova coverage reporting.\n>             credentials         Show user credentials returned from\n>         auth.\n>             delete              Immediately shut down and delete\n>         specified server(s).\n>             diagnostics         Retrieve server diagnostics.\n>             dns-create          Create a DNS entry for domain, name\n>         and ip.\n>             dns-create-private-domain\n>                                 Create the specified DNS domain.\n>             dns-create-public-domain\n>                                 Create the specified DNS domain.\n>             dns-delete          Delete the specified DNS entry.\n>             dns-delete-domain   Delete the specified DNS domain.\n>             dns-domains         Print a list of available dns domains.\n>             dns-list            List current DNS entries for domain\n>         and ip or domain\n>                                 and name.\n>             endpoints           Discover endpoints that get returned\n>         from the\n>                                 authenticate services.\n>             evacuate            Evacuate server from failed host to\n>         specified one.\n>             fixed-ip-get        Retrieve info on a fixed ip.\n>             fixed-ip-reserve    Reserve a fixed IP.\n>             fixed-ip-unreserve  Unreserve a fixed IP.\n>             flavor-access-add   Add flavor access for the given\n>         tenant.\n>             flavor-access-list  Print access information about the\n>         given flavor.\n>             flavor-access-remove\n>                                 Remove flavor access for the given\n>         tenant.\n>             flavor-create       Create a new flavor\n>             flavor-delete       Delete a specific flavor\n>             flavor-key          Set or unset extra_spec for a flavor.\n>             flavor-list         Print a list of available\n>         \'flavors\' (sizes of\n>                                 servers).\n>             flavor-show         Show details about the given flavor.\n>             floating-ip-bulk-create\n>                                 Bulk create floating ips by range.\n>             floating-ip-bulk-delete\n>                                 Bulk delete floating ips by range.\n>             floating-ip-bulk-list\n>                                 List all floating ips.\n>             floating-ip-create  Allocate a floating IP for the current\n>         tenant.\n>             floating-ip-delete  De-allocate a floating IP.\n>             floating-ip-list    List floating ips for this tenant.\n>             floating-ip-pool-list\n>                                 List all floating ip pools.\n>             get-password        Get password for a server.\n>             get-spice-console   Get a spice console to a server.\n>             get-vnc-console     Get a vnc console to a server.\n>             host-action         Perform a power action on a host.\n>             host-describe       Describe a specific host.\n>             host-list           List all hosts by service.\n>             host-update         Update host settings.\n>             hypervisor-list     List hypervisors.\n>             hypervisor-servers  List instances belonging to specific\n>         hypervisors.\n>             hypervisor-show     Display the details of the specified\n>         hypervisor.\n>             hypervisor-stats    Get hypervisor statistics over all\n>         compute nodes.\n>             hypervisor-uptime   Display the uptime of the specified\n>         hypervisor.\n>             image-create        Create a new image by taking a\n>         snapshot of a running\n>                                 server.\n>             image-delete        Delete specified image(s).\n>             image-list          Print a list of available images to\n>         boot from.\n>             image-meta          Set or Delete metadata on an image.\n>             image-show          Show details about the given image.\n>             interface-attach    Attach a network interface to an\n>         instance.\n>             interface-detach    Detach a network interface from an\n>         instance.\n>             interface-list      List interfaces attached to an\n>         instance.\n>             keypair-add         Create a new key pair for use with\n>         instances.\n>             keypair-delete      Delete keypair given by its name.\n>             keypair-list        Print a list of keypairs for a user\n>             keypair-show        Show details about the given keypair.\n>             list                List active servers.\n>             list-secgroup       List Security Group(s) of a server.\n>             live-migration      Migrate running instance to a new\n>         machine.\n>             lock                Lock a server.\n>             meta                Set or Delete metadata on a server.\n>             migrate             Migrate a server. The new host will be\n>         selected by the\n>                                 scheduler.\n>             network-associate-host\n>                                 Associate host with network.\n>             network-associate-project\n>                                 Associate project with network.\n>             network-create      Create a network.\n>             network-disassociate\n>                                 Disassociate host and/or project from\n>         the given\n>                                 network.\n>             network-list        Print a list of available networks.\n>             network-show        Show details about the given network.\n>             pause               Pause a server.\n>             quota-class-show    List the quotas for a quota class.\n>             quota-class-update  Update the quotas for a quota class.\n>             quota-defaults      List the default quotas for a tenant.\n>             quota-delete        Delete quota for a tenant/user so\n>         their quota will\n>                                 Revert back to default.\n>             quota-show          List the quotas for a tenant/user.\n>             quota-update        Update the quotas for a tenant/user.\n>             rate-limits         Print a list of rate limits for a user\n>             reboot              Reboot a server.\n>             rebuild             Shutdown, re-image, and re-boot a\n>         server.\n>             remove-fixed-ip     Remove an IP address from a server.\n>             remove-floating-ip  Remove a floating IP address from a\n>         server.\n>             remove-secgroup     Remove a Security Group from a server.\n>             rename              Rename a server.\n>             rescue              Rescue a server.\n>             reset-network       Reset network of an instance.\n>             reset-state         Reset the state of an instance.\n>             resize              Resize a server.\n>             resize-confirm      Confirm a previous resize.\n>             resize-revert       Revert a previous resize (and return\n>         to the previous\n>                                 VM).\n>             resume              Resume a server.\n>             root-password       Change the root password for a server.\n>             scrub               Delete data associated with the\n>         project.\n>             secgroup-add-group-rule\n>                                 Add a source group rule to a security\n>         group.\n>             secgroup-add-rule   Add a rule to a security group.\n>             secgroup-create     Create a security group.\n>             secgroup-delete     Delete a security group.\n>             secgroup-delete-group-rule\n>                                 Delete a source group rule from a\n>         security group.\n>             secgroup-delete-rule\n>                                 Delete a rule from a security group.\n>             secgroup-list       List security groups for the current\n>         tenant.\n>             secgroup-list-rules\n>                                 List rules for a security group.\n>             secgroup-update     Update a security group.\n>             service-disable     Disable the service.\n>             service-enable      Enable the service.\n>             service-list        Show a list of all running services.\n>         Filter by host &\n>                                 binary.\n>             show                Show details about the given server.\n>             ssh                 SSH into a server.\n>             start               Start a server.\n>             stop                Stop a server.\n>             suspend             Suspend a server.\n>             unlock              Unlock a server.\n>             unpause             Unpause a server.\n>             unrescue            Unrescue a server.\n>             usage               Show usage data for a single tenant.\n>             usage-list          List usage data for all tenants.\n>             volume-attach       Attach a volume to a server.\n>             volume-create       Add a new volume.\n>             volume-delete       Remove a volume.\n>             volume-detach       Detach a volume from a server.\n>             volume-list         List all the volumes.\n>             volume-show         Show details about a volume.\n>             volume-snapshot-create\n>                                 Add a new snapshot.\n>             volume-snapshot-delete\n>                                 Remove a snapshot.\n>             volume-snapshot-list\n>                                 List all the snapshots.\n>             volume-snapshot-show\n>                                 Show details about a snapshot.\n>             volume-type-create  Create a new volume type.\n>             volume-type-delete  Delete a specific flavor\n>             volume-type-list    Print a list of available \'volume\n>         types\'.\n>             volume-update       Update volume attachment.\n>             x509-create-cert    Create x509 cert for a user in tenant.\n>             x509-get-root-cert  Fetch the x509 root cert.\n>             bash-completion     Prints all of the commands and options\n>         to stdout so\n>                                 that the nova.bash_completion script\n>         doesn\'t have to\n>                                 hard code them.\n>             help                Display help about this program or one\n>         of its\n>                                 subcommands.\n>             baremetal-interface-add\n>                                 Add a network interface to a baremetal\n>         node.\n>             baremetal-interface-list\n>                                 List network interfaces associated\n>         with a baremetal\n>                                 node.\n>             baremetal-interface-remove\n>                                 Remove a network interface from a\n>         baremetal node.\n>             baremetal-node-create\n>                                 Create a baremetal node.\n>             baremetal-node-delete\n>                                 Remove a baremetal node and any\n>         associated interfaces.\n>             baremetal-node-list\n>                                 Print list of available baremetal\n>         nodes.\n>             baremetal-node-show\n>                                 Show information about a baremetal\n>         node.\n>             cell-capacities     Get cell capacities for all cells or a\n>         given cell.\n>             cell-show           Show details of a given cell.\n>             force-delete        Force delete a server.\n>             restore             Restore a soft-deleted server.\n>             host-evacuate       Evacuate all instances from failed\n>         host to specified\n>                                 one.\n>             host-servers-migrate\n>                                 Migrate all instances of the specified\n>         host to other\n>                                 available hosts.\n>             instance-action     Show an action.\n>             instance-action-list\n>                                 List actions on a server.\n>             list-extensions     List all the os-api extensions that\n>         are available.\n>             host-meta           Set or Delete metadata on all\n>         instances of a host.\n>             migration-list      Print a list of migrations.\n>             net                 Show a network\n>             net-create          Create a network\n>             net-delete          Delete a network\n>             net-list            List networks\n>         \n>         Optional arguments:\n>           --version             show program\'s version number and exit\n>           --debug               Print debugging output\n>           --os-cache            Use the auth token cache.\n>           --timings             Print call timing info\n>           --timeout <seconds>   Set HTTP call timeout (in seconds)\n>           --os-username <auth-user-name>\n>                                 Defaults to env[OS_USERNAME].\n>           --os-password <auth-password>\n>                                 Defaults to env[OS_PASSWORD].\n>           --os-tenant-name <auth-tenant-name>\n>                                 Defaults to env[OS_TENANT_NAME].\n>           --os-tenant-id <auth-tenant-id>\n>                                 Defaults to env[OS_TENANT_ID].\n>           --os-auth-url <auth-url>\n>                                 Defaults to env[OS_AUTH_URL].\n>           --os-region-name <region-name>\n>                                 Defaults to env[OS_REGION_NAME].\n>           --os-auth-system <auth-system>\n>                                 Defaults to env[OS_AUTH_SYSTEM].\n>           --service-type <service-type>\n>                                 Defaults to compute for most actions\n>           --service-name <service-name>\n>                                 Defaults to env[NOVA_SERVICE_NAME]\n>           --volume-service-name <volume-service-name>\n>                                 Defaults to\n>         env[NOVA_VOLUME_SERVICE_NAME]\n>           --endpoint-type <endpoint-type>\n>                                 Defaults to env[NOVA_ENDPOINT_TYPE] or\n>         publicURL.\n>           --os-compute-api-version <compute-api-ver>\n>                                 Accepts 1.1 or 3, defaults to\n>                                 env[OS_COMPUTE_API_VERSION].\n>           --os-cacert <ca-certificate>\n>                                 Specify a CA bundle file to use in\n>         verifying a TLS\n>                                 (https) server certificate. Defaults\n>         to env[OS_CACERT]\n>           --insecure            Explicitly allow novaclient to perform\n>         \"insecure\" SSL\n>                                 (https) requests. The server\'s\n>         certificate will not be\n>                                 verified against any certificate\n>         authorities. This\n>                                 option should be used with caution.\n>           --bypass-url <bypass-url>\n>                                 Use this API endpoint instead of the\n>         Service Catalog\n>         \n>         See \"nova help COMMAND\" for help on a specific command.\n>         \n>         Here\'s the output for nova help boot:\n>         usage: nova boot [--flavor <flavor>] [--image <image>]\n>                          [--image-with <key=value>] [--boot-volume\n>         <volume_id>]\n>                          [--snapshot <snapshot_id>] [--num-instances\n>         <number>]\n>                          [--meta <key=value>] [--file\n>         <dst-path=src-path>]\n>                          [--key-name <key-name>] [--user-data\n>         <user-data>]\n>                          [--availability-zone <availability-zone>]\n>                          [--security-groups <security-groups>]\n>                          [--block-device-mapping <dev-name=mapping>]\n>                          [--block-device key1=value1[,key2=value2...]]\n>                          [--swap <swap_size>]\n>                          [--ephemeral size=<size>[,format=<format>]]\n>                          [--hint <key=value>]\n>                          [--nic\n>         <net-id=net-uuid,v4-fixed-ip=ip-addr,port-id=port-uuid>]\n>                          [--config-drive <value>] [--poll]\n>                          <name>\n>         \n>         Boot a new server.\n>         \n>         Positional arguments:\n>           <name>                Name for the new server\n>         \n>         Optional arguments:\n>           --flavor <flavor>     Name or ID of flavor (see \'nova\n>         flavor-list\').\n>           --image <image>       Name or ID of image (see \'nova\n>         image-list\').\n>           --image-with <key=value>\n>                                 Image metadata property (see \'nova\n>         image-show\').\n>           --boot-volume <volume_id>\n>                                 Volume ID to boot from.\n>           --snapshot <snapshot_id>\n>                                 Sapshot ID to boot from (will create a\n>         volume).\n>           --num-instances <number>\n>                                 boot multi instances at a time\n>         (limited by quota).\n>           --meta <key=value>    Record arbitrary key/value metadata\n>         to /meta.js on the\n>                                 new server. Can be specified multiple\n>         times.\n>           --file <dst-path=src-path>\n>                                 Store arbitrary files from <src-path>\n>         locally to <dst-\n>                                 path> on the new server. You may store\n>         up to 5 files.\n>           --key-name <key-name>\n>                                 Key name of keypair that should be\n>         created earlier\n>                                 with the command keypair-add\n>           --user-data <user-data>\n>                                 user data file to pass to be exposed\n>         by the metadata\n>                                 server.\n>           --availability-zone <availability-zone>\n>                                 The availability zone for instance\n>         placement.\n>           --security-groups <security-groups>\n>                                 Comma separated list of security group\n>         names.\n>           --block-device-mapping <dev-name=mapping>\n>                                 Block device mapping in the format\n>         <dev-\n>         \n>         name>=<id>:<type>:<size(GB)>:<delete-on-terminate>.\n>           --block-device key1=value1[,key2=value2...]\n>                                 Block device mapping with the keys:\n>         id=image_id,\n>                                 snapshot_id or volume_id,\n>         source=source type (image,\n>                                 snapshot, volume or blank),\n>         dest=destination type of\n>                                 the block device (volume or local),\n>         bus=device\'s bus,\n>                                 device=name of the device (e.g. vda,\n>         xda, ...),\n>                                 size=size of the block device in GB,\n>         format=device\n>                                 will be formatted (e.g. swap, ext3,\n>         ntfs, ...),\n>                                 bootindex=integer used for ordering\n>         the boot disks,\n>                                 type=device type (e.g. disk,\n>         cdrom, ...) and\n>                                 shutdown=shutdown behaviour (either\n>         preserve or\n>                                 remove).\n>           --swap <swap_size>    Create and attach a local swap block\n>         device of\n>                                 <swap_size> MB.\n>           --ephemeral size=<size>[,format=<format>]\n>                                 Create and attach a local ephemeral\n>         block device of\n>                                 <size> GB and format it to <format>.\n>           --hint <key=value>    Send arbitrary key/value pairs to the\n>         scheduler for\n>                                 custom use.\n>           --nic\n>         <net-id=net-uuid,v4-fixed-ip=ip-addr,port-id=port-uuid>\n>                                 Create a NIC on the server. Specify\n>         option multiple\n>                                 times to create multiple NICs. net-id:\n>         attach NIC to\n>                                 network with this UUID (required if no\n>         port-id), v4\n>                                 -fixed-ip: IPv4 fixed address for NIC\n>         (optional),\n>                                 port-id: attach NIC to port with this\n>         UUID (required\n>                                 if no net-id)\n>           --config-drive <value>\n>                                 Enable config drive\n>           --poll                Blocks while instance builds so\n>         progress can be\n>                                 reported.\n>         \n>         \n>         \n>          \n>                 \n>                 \n>                 As for horizon screenshots, do we need them? That GUI\n>                 is not that complicated and screenshots are a pain to\n>                 maintain (automated or not).  A better project might\n>                 be to add some online help to the GUI itself? \n>         \n>         \n>         I\'ll see if Summer can comment further. Workflows were a bit\n>         deal to Horizon and there\'s plenty we\'re not documenting that\n>         you can do in the Dashboard. I see this as just a research\n>         spike in viability.\n>         \n>         Thanks -\n>         Anne\n>         \n>          \n>                 \n>                 \n>                 Thanks Anne (and all)!\n>                 \n>                 Sent from my iPhone\n>                 \n>                 On Nov 5, 2013, at 3:25 AM, \"Anne Gentle\"\n>                 <anne at openstack.org> wrote:\n>                 \n>                 \n>                 > Hi all, \n>                 > \n>                 > The first four docs discussions are done and we\'ve\n>                 > got some decisions we want to bring to the group.\n>                 > Ideally these decisions will stick for the Icehouse\n>                 > time frame, the next six months. Tom, Summer,\n>                 > Stephen, and I were here but we want to be sure we\n>                 > came to the same conclusions on our own that our\n>                 > larger group would have as well. \n>                 > \n>                 > \n>                 > Doc automation:\n>                 > \n>                 > - We want to set up a doctools repo just for doc\n>                 > tools like the automation tools and gate tests.\n>                 > Should help with translation tools also. Open to ITS\n>                 > use.\n>                 > \n>                 > - Config items automation - Oslo will likely change\n>                 > enough this release that our tool needs to change as\n>                 > well. \n>                 > - CLI reference automation - part of the restructure\n>                 > discussion uncovered a need to streamline the Config\n>                 > ref to reference only, and also create a CLI\n>                 > reference for CLI reference only. We want to\n>                 > prioritize automating this as highly as config\n>                 > automation.\n>                 > - API doc automation - still under discussion, stay\n>                 > tuned after this Friday.\n>                 > - RST to XML workflow for training guides - Sean\n>                 > wants to filter the dev doc further.\n>                 > \n>                 > - Ceilometer has tables they auto-generate in their\n>                 > dev docs that they want to bring into\n>                 > openstack-manuals. \n>                 > \n>                 > - Horizon workflows: Summer had a great idea to\n>                 > automate screen captures of common workflows in the\n>                 > dashboard. This work would be great to do in the\n>                 > coming release, Summer is going to do a research\n>                 > spike into tooling.\n>                 > \n>                 > \n>                 > \n>                 > Restructure:\n>                 > \n>                 > Despite the tradeoff that we have to re-communicate\n>                 > some more moves to all the teams, we want to trim\n>                 > the configuration reference down to just listings of\n>                 > options, no how-to or explanatory information. Move\n>                 > this type of info to the Cloud Admin Guide. Are we\n>                 > good with this plan for Icehouse? \n>                 > \n>                 > Pull out CLI reference info from the end-user guide\n>                 > and admin user guide, put into a CLI reference that\n>                 > goes to the submenu level. Sound good? \n>                 > \n>                 > \n>                 > Install guide (always seems to be a topic of its\n>                 > own):\n>                 > - Continue with current guide, maintain and update\n>                 > for icehouse. \n>                 > \n>                 > - Look for 2-3 more resources to help with install\n>                 > guides.\n>                 > \n>                 > - Push for a real big testing drive a month before\n>                 > release instead of 2 weeks.\n>                 > \n>                 > \n>                 > \n>                 > Any questions? If you\'re not here, we sure wish you\n>                 > were here!\n>                 > \n>                 > \n>                 > As a side note, here are some pics from our women of\n>                 > OpenStack boat outing last night on the harbor. The\n>                 > grey fog was everywhere and we couldn\'t go on deck\n>                 > it was just too wet. But the buildings lighting up\n>                 > are amazing here, you can hardly capture the sights\n>                 > in photos.\n>                 > http://flic.kr/s/aHsjLUoHM2 \n>                 > \n>                 > Here\'s the one sightseeing day I\'ve had so far,\n>                 > going on a \"crystal bottom\" cable car ride to get to\n>                 > a big Buddha statue with a monastery nearby. \n>                 > http://flic.kr/s/aHsjLWowHf\n>                 > \n>                 > \n>                 > Anne \n>                 > \n>                 > _______________________________________________\n>                 > Openstack-docs mailing list\n>                 > Openstack-docs at lists.openstack.org\n>                 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>                 > \n>         \n>         \n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n\n','<CAD0KtVFFti8EPy-dxC7crzEDUec2xjQHiLx3B5-gh=VF12QkkA@mail.gmail.com>',NULL),('<1390174654.2947.1.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 09:37:34',36000,'2014-01-19 23:37:34',NULL,'[openstack-dev] a \"common\" client library','On Sat, 2014-01-18 at 09:13 -0500, Doug Hellmann wrote:\n> I like the idea of a fresh start, but I don\'t think that\'s\n> incompatible with the other work to clean up the existing clients.\n> That cleanup work could help with creating the backwards compatibility\n> layer, if a new library needs to include one, for example.\n> \n> \n> As far as namespace packages and separate client libraries, I\'m torn.\n> It makes sense, and I originally assumed we would want to take that\n> approach. The more I think about it, though, the more I like the\n> approach Dean took with the CLI, creating a single repository with a\n> team responsible for managing consistency in the UI.\n> \n> \n> Doug\n\nThis *is* the approach Dean took with the CLI. Have a package that\nprovides the CLI but then have the actual work handed off to the\nindividual clients (with quite a lot of glue).\n\n> \n> On Sat, Jan 18, 2014 at 1:00 AM, Jamie Lennox <jamielennox at redhat.com>\n> wrote:\n>         I can\'t see any reason that all of these situations can\'t be\n>         met.\n>         \n>         We can finally take the openstack pypi namespace, move\n>         keystoneclient -> openstack.keystone and similar for the other\n>         projects. Have them all based upon openstack.base and probably\n>         an openstack.transport for transport.\n>         \n>         For the all-in-one users we can then just have\n>         openstack.client which depends on all of the openstack.x\n>         projects. This would satisfy the requirement of keeping\n>         projects seperate, but having the one entry point for newer\n>         users. Similar to the OSC project (which could acutally rely\n>         on the new all-in-one).\n>         \n>         This would also satisfy a lot of the clients who have i know\n>         are looking to move to a version 2 and break compatability\n>         with some of the crap from the early days.\n>         \n>         I think what is most important here is deciding what we want\n>         from our clients and discussing a common base that we are\n>         happy to support - not just renaming the existing ones.\n>         \n>         (I don\'t buy the problem with large amounts of dependencies,\n>         if you have a meta-package you just have one line in\n>         requirements and pip will figure the rest out.)\n>         \n>         Jamie\n>         \n>         ----- Original Message -----\n>         > From: \"Jonathan LaCour\" <jonathan-lists at cleverdevil.org>\n>         > To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         > Sent: Saturday, 18 January, 2014 4:00:58 AM\n>         > Subject: Re: [openstack-dev] a \"common\" client library\n>         >\n>         \n>         > On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft <\n>         donald at stufft.io > wrote:\n>         >\n>         >\n>         >\n>         >\n>         > On Jan 16, 2014, at 4:06 PM, Jesse Noller <\n>         jesse.noller at RACKSPACE.COM >\n>         > wrote:\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > On Jan 16, 2014, at 2:22 PM, Renat Akhmerov <\n>         rakhmerov at mirantis.com > wrote:\n>         >\n>         >\n>         >\n>         >\n>         > Since it?s pretty easy to get lost among all the opinions\n>         I?d like to\n>         > clarify/ask a couple of things:\n>         >\n>         >\n>         >\n>         \n>         >     * Keeping all the clients physically separate/combining\n>         them in to a\n>         >     single library. Two things here:\n>         \n>         >         * In case of combining them, what exact project are\n>         we considering?\n>         >         If this list is limited to core projects like nova\n>         and keystone what\n>         >         policy could we have for other projects to join this\n>         list?\n>         >         (Incubation, graduation, something else?)\n>         \n>         >         * In terms of granularity and easiness of\n>         development I?m for keeping\n>         >         them separate but have them use the same boilerplate\n>         code, basically\n>         >         we need a OpenStack Rest Client Framework which is\n>         flexible enough\n>         >         to address all the needs in an abstract domain\n>         agnostic manner. I\n>         >         would assume that combining them would be an\n>         additional\n>         >         organizational burden that every stakeholder would\n>         have to deal\n>         >         with.\n>         >\n>         > Keeping them separate is awesome for *us* but really,\n>         really, really sucks\n>         > for users trying to use the system.\n>         >\n>         > I agree. Keeping them separate trades user usability for\n>         developer usability,\n>         > I think user usability is a better thing to strive for.\n>         > 100% agree with this. In order for OpenStack to be its most\n>         successful, I\n>         > believe firmly that a focus on end-users and deployers needs\n>         to take the\n>         > forefront. That means making OpenStack clouds as easy to\n>         consume/leverage as\n>         > possible for users and tool builders, and\n>         simplifying/streamlining as much\n>         > as possible.\n>         >\n>         > I think that a single, common client project, based upon\n>         package namespaces,\n>         > with a unified, cohesive feel is a big step in this\n>         direction.\n>         >\n>         > --\n>         > Jonathan LaCour\n>         >\n>         >\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CADb+p3RYSRznXj=J_Gw9gecmyTgTVALJSBWtCcWvzisxZd+Jgw@mail.gmail.com>',NULL),('<1390217035.61400.YahooMailNeo@web172404.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 11:23:55',0,'2014-01-20 11:23:55',NULL,'[openstack-dev] [Neutron] Apparently weird timeout issue','Hi Salvatore,\n\nI presume it\'s this one??\nhttp://logs.openstack.org/38/65838/4/check/check-tempest-dsvm-neutron-isolated/d108e4a/logs/tempest.txt.gz?#_2014-01-19_20_50_14_604\n\nIs it true that the cirros image just fires off a few dhcp discovers and then gives up? If so, then maybe it did so before the tagging happened. Do we have the instance console log? It took about 45 seconds from when the port was created to when it was tagged.\n\n2014-01-19 20:48:57.412 8142 DEBUG neutron.agent.linux.ovsdb_monitor [-] Output \nreceived from ovsdb monitor: \n{\"data\":[[\"3602a7b2-b559-4709-9bf0-53ae2af68d06\",\"insert\",\"tap496b808c-b5\"]],\"headings\":[\"row\",\"action\",\"name\"]}\n<snip>\n2014-01-19 20:49:41.925 8142 DEBUG neutron.agent.linux.utils [-] \nCommand:\n [\'sudo\', \'/usr/local/bin/neutron-rootwrap\', \n\'/etc/neutron/rootwrap.conf\', \'ovs-vsctl\', \'--timeout=10\', \'set\', \n\'Port\', \'tap496b808c-b5\', \'tag=64\']\nExit code: 0\n\nDarragh.\n\n\n>I have been seeing in the past 2 days timeout failures on gate jobs which I\n>am struggling to explain. An example is available in [1]\n>These are the usual failure that we associate with bug 1253896, but this\n>time I can verify that:\n>- The floating IP is correctly wired (IP and NAT rules)\n>- The DHCP port is correctly wired, as well as the VM port and the router\n>port\n>- The DHCP agent is correctly started for the network\n>\n>However, no DHCP DISCOVER request is sent. Only the DHCP RELEASE message is\n>seen.\n>Any help at interpreting the logs will be appreciated.\n>\n>\n>Salvatore\n>\n>[1] http://logs.openstack.org/38/65838\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/15409d81/attachment.html>\n\n',NULL,NULL),('<1390227817.2281.7.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 09:23:37',-18000,'2014-01-20 14:23:37',NULL,'[openstack-dev] [qa][Neutron][Tempest][Network] Break down\n NetworkBasicOps to smaller test cases','On Sun, 2014-01-19 at 07:17 -0500, Yair Fried wrote:\n> OK,\n> but considering my pending patch (#3 and #4)\n> what about:\n> \n> #1 -> #2\n> #1 -> #3\n> #1 -> #4\n> \n> instead of \n> \n> #1 -> #2 -> #3 -> #4\n> \n> a failure in #2 will prevent #3 and #4 from running even though they are completely unrelated\n\nSeems to me, that the above is a logical fault. If a failure in #2\nprevents #3 or #4 from running, then by nature they are related to #2.\n\n-jay\n\n\n\n','<9915376.189.1390133842438.JavaMail.yfried@yfried-mobl-rh>',NULL),('<1390227952.7374.1.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 14:25:58',0,'2014-01-20 14:25:58',NULL,'[openstack-dev] Introduction: Rich Megginson - Designate project','Hi Rich - Welcome!\n\nWe\'re mostly all on the #openstack-dns IRC channel, drop by and say\nhello ;)\n\nThanks,\nKiall\n\nOn Wed, 2014-01-15 at 18:24 -0700, Rich Megginson wrote:\n> Hello.  My name is Rich Megginson.  I am a Red Hat employee interested \n> in working on Designate (DNSaaS), primarily in the areas of integration \n> with IPA DNS, DNSSEC, and authentication (Keystone).\n> \n> I\'ve signed up for the openstack/launchpad/gerrit accounts.\n> \n> Be seeing you (online).\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 836 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/f629a9ac/attachment.pgp>\n\n','<52D734D3.9080200@redhat.com>',NULL),('<1390231439.3306.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 15:23:59',0,'2014-01-20 15:23:59',NULL,'[openstack-dev] [Neutron] Apparently weird timeout issue','\nI did a test to see what the dhcp client on cirros does. I killed the dhcp agent and started an instance. The instance sent the first dhcp offer after about 35 sec. Then another 60 sec later, and a final one after another 60 sec.\n\nSo a revised theory for what happened is this:? \n\n\nt=0 tempest starts vm and starts polling for ACTIVE status\nt=20 instance-->ACTIVE and tempest starts polling the floating ip for 60 sec\nt=40 instance does a dhcp discover - no response - so sets a timer for 60 sec\nt=45 ovs-agent sets the port vlan\nt=80 tempest gives up and kills vm\nt=100 instance would have sent another dhcp discover now if it had been let live\n\nI think it would be worth trying to change that test to poll for 120 seconds instead of 60.\n\n\nOn Monday, 20 January 2014, 11:23, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n \nHi Salvatore,\n>\n>\n>I presume it\'s this one??\n>http://logs.openstack.org/38/65838/4/check/check-tempest-dsvm-neutron-isolated/d108e4a/logs/tempest.txt.gz?#_2014-01-19_20_50_14_604\n>\n>\n>Is it true that the cirros image just fires off a few dhcp discovers and then gives up? If so, then maybe it did so before the tagging happened. Do we have the instance console log? It took about 45 seconds from when the port was created to when it was tagged.\n>\n>\n>2014-01-19 20:48:57.412 8142 DEBUG neutron.agent.linux.ovsdb_monitor [-] Output \nreceived from ovsdb monitor: \n{\"data\":[[\"3602a7b2-b559-4709-9bf0-53ae2af68d06\",\"insert\",\"tap496b808c-b5\"]],\"headings\":[\"row\",\"action\",\"name\"]}\n><snip>\n>2014-01-19 20:49:41.925 8142 DEBUG neutron.agent.linux.utils [-] \n>Command:\n [\'sudo\', \'/usr/local/bin/neutron-rootwrap\', \n\'/etc/neutron/rootwrap.conf\', \'ovs-vsctl\', \'--timeout=10\', \'set\', \n\'Port\', \'tap496b808c-b5\', \'tag=64\']\n>Exit code: 0\n>\n>\n>Darragh.\n>\n>\n>\n>>I have been seeing in the past 2 days timeout failures on gate jobs which I\n>>am struggling to explain. An example is\n available in [1]\n>>These are the usual failure that we associate with bug 1253896, but this\n>>time I can verify that:\n>>- The floating IP is correctly wired (IP and NAT rules)\n>>- The DHCP port is correctly wired, as well as the VM port and the router\n>>port\n>>- The DHCP agent is correctly started for the network\n>>\n>>However, no DHCP DISCOVER request is sent. Only the DHCP RELEASE message is\n>>seen.\n>>Any help at interpreting the logs will be appreciated.\n>>\n>>\n>>Salvatore\n>>\n>>[1] http://logs.openstack.org/38/65838\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/a38cdf90/attachment.html>\n\n','<1390217035.61400.YahooMailNeo@web172404.mail.ir2.yahoo.com>',NULL);
INSERT INTO `messages` VALUES ('<1390233094.26562.YahooMailNeo@web172401.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 15:51:34',0,'2014-01-20 15:51:34',NULL,'[openstack-dev] [Neutron] Apparently weird timeout issue','\nOn Monday, 20 January 2014, 15:33, Jay Pipes <jaypipes at gmail.com> wrote:\n\n>Sorry for top-posting -- using web mail client.\nno worries - it doesn\'t bother me.\n>\n>Is it possible to change the retry interval in Cirros (or cloud-init?) so that the backoff is less than 60 seconds?\nI think the udhcpc command line parameters are baked into the image. It\'s part of BusyBox, and I\'m not even sure if it\'s configurable from a script/text file.\n>\n>Best,\n>\n-jay\n>\n>\n>\n>\n>On Mon, Jan 20, 2014 at 10:23 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>\n>>I did a test to see what the dhcp client on cirros does. I killed the dhcp agent and started an instance. The instance sent the first dhcp offer after about 35 sec. Then another 60 sec later, and a final one after another 60 sec.\n>>\n>>\n>>So a revised theory for what happened is this:? \n>>\n>>t=0 tempest starts vm and starts polling for ACTIVE status\n>>t=20 instance-->ACTIVE and tempest starts polling the floating ip for 60 sec\n>>t=40 instance does a dhcp discover - no response - so sets a timer for 60 sec\n>>t=45 ovs-agent sets the port vlan\n>>t=80 tempest gives up and kills vm\n>>t=100 instance would have sent another dhcp discover now if it had been let live\n>>\n>>I think it would be worth trying to change that test to poll for 120 seconds instead of 60.\n>>\n>>\n>>\n>>On Monday, 20 January 2014, 11:23, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>> \n>>Hi Salvatore,\n>>>\n>>>\n>>>I presume it\'s this one??\n>>>http://logs.openstack.org/38/65838/4/check/check-tempest-dsvm-neutron-isolated/d108e4a/logs/tempest.txt.gz?#_2014-01-19_20_50_14_604\n>>>\n>>>\n>>>Is it true that the cirros image just fires off a few dhcp discovers and then gives up? If so, then maybe it did so before the tagging happened. Do we have the instance console log? It took about 45 seconds from when the port was created to when it was tagged.\n>>>\n>>>\n>>>2014-01-19 20:48:57.412 8142 DEBUG neutron.agent.linux.ovsdb_monitor [-] Output \nreceived from ovsdb monitor: \n{\"data\":[[\"3602a7b2-b559-4709-9bf0-53ae2af68d06\",\"insert\",\"tap496b808c-b5\"]],\"headings\":[\"row\",\"action\",\"name\"]}\n>>><snip>\n>>>2014-01-19 20:49:41.925 8142 DEBUG neutron.agent.linux.utils [-] \n>>>Command:\n[\'sudo\', \'/usr/local/bin/neutron-rootwrap\', \n\'/etc/neutron/rootwrap.conf\', \'ovs-vsctl\', \'--timeout=10\', \'set\', \n\'Port\', \'tap496b808c-b5\', \'tag=64\']\n>>>Exit code: 0\n>>>\n>>>\n>>>Darragh.\n>>>\n>>>\n>>>\n>>>>I have been seeing in the past 2 days timeout failures on gate jobs which I\n>>>>am struggling to explain. An example is\navailable in [1]\n>>>>These are the usual failure that we associate with bug 1253896, but this\n>>>>time I can verify that:\n>>>>- The floating IP is correctly wired (IP and NAT rules)\n>>>>- The DHCP port is correctly wired, as well as the VM port and the router\n>>>>port\n>>>>- The DHCP agent is correctly started for the network\n>>>>\n>>>>However, no DHCP DISCOVER request is sent. Only the DHCP RELEASE message is\n>>>>seen.\n>>>>Any help at interpreting the logs will be appreciated.\n>>>>\n>>>>\n>>>>Salvatore\n>>>>\n>>>>[1] http://logs.openstack.org/38/65838\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>\n>\n>\n\n\n','<CAAE6tVby6V_=+p5gcuw33XqzEE1XsReBRE7DC8KTB6XZ3qjYGw@mail.gmail.com>',NULL),('<1390240243.9651.4.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 12:50:43',-18000,'2014-01-20 17:50:43',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','On Mon, 2014-01-20 at 17:49 +0100, Sylvain Bauza wrote:\n> Hi Jay,\n> \n> Le 20/01/2014 17:34, Jay Pipes a ?crit :\n> \n> > On Mon, Jan 20, 2014 at 11:18 AM, Sylvain Bauza\n> > <sylvain.bauza at bull.net> wrote:\n> >         Jay, please be aware of the existence of Climate, which is a\n> >         Stackforge project for managing dedicated resources (like\n> >         AWS reserved instances). This is not another API extension,\n> >         but another API endpoint for creating what we call \"leases\"\n> >         which can be started now or in the future and last for a\n> >         certain amount of time. We personnally think there is a\n> >         space for Reservations in Openstack, and this needs to be\n> >         done as a service.\n> > \n> > \n> > Hi Sylvain! Hope all is well with you :)\n> \n> Thanks, doing well but a bit under pressure, as Climate has its 0.1\n> milestone this week...\n\nUnderstood :)\n\n> > So, I actually don\'t think the two concepts (reservations and\n> > \"isolated instances\") are competing ideas. Isolated instances are\n> > actually not reserved. They are simply instances that have a\n> > condition placed on their assignment to a particular compute node\n> > that the node must only be hosting other instances of one or more\n> > specified projects (tenants).\n> \n> I got your idea. This filter [1] already does most of the work,\n> although it relies on aggregates and requires admin management. The\n> main issue with isolated instances is that it requires kind of\n> capacity planning for making sure you can cope with the load, that\'s\n> why we placed the idea of having such a placement scheduler.\n> \n> [1] :\n> https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_multitenancy_isolation.py \n\nRight, the difference between that and my proposed solution would be\nthere would be no dependency on any aggregate at all.\n\nI do understand your point about capacity planning in light of such\nscheduling functionality -- due to the higher likelihood that compute\nnodes would be unable to service a more general workload from other\ntenants.\n\nBut I believe that the two concerns can be tackled separately.\n\nBest,\n-jay\n\n\n\n','<52DD53AA.9030402@bull.net>',NULL),('<1390241311.4923.4.camel@sbgat346.in2p3.fr>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-20 19:08:31',3600,'2014-01-20 18:08:31',NULL,'[Openstack-operators] neutron + OVS 1.11 (or 2.0.1)','Le vendredi 17 janvier 2014 ? 09:38 +0100, Robert Plestenjak a ?crit :\n> I\'m running this on my test cluster. Centos 6.5, OVS 1.11 and newest Havana from repo:\n> \n> http://repos.fedorapeople.org/repos/openstack/openstack-havana/rdo-release-havana-7.noarch.rpm\n> \n> - Robert\n\nHi,\n\nI am also running Scientific Linux 6.4 with\nopenvswitch-1.11.0_8ce28d-1.el6ost.x86_64 (provided by\nhttp://repos.fedorapeople.org/repos/openstack/openstack-havana/epel-6/)\n\nCheers,\n\nJerome\n\n> ----- Original Message -----\n> From: \"Aaron Rosen\" <aaronorosen at gmail.com>\n> To: \"George Shuklin\" <george.shuklin at gmail.com>\n> Cc: openstack-operators at lists.openstack.org\n> Sent: Thursday, January 16, 2014 5:11:12 PM\n> Subject: Re: [Openstack-operators] neutron + OVS 1.11 (or 2.0.1)\n> \n> \n> \n> \n> Hi, \n> \n> Can you give more details on how it breaks? Did you restart the agents so it reprograms the flows back down? \n> On Jan 16, 2014 2:06 AM, \"George Shuklin\" < george.shuklin at gmail.com > wrote: \n> \n> \n> Good day. \n> \n> Did anyone successfully combine havanna and OVS > 1.10? OVS 1.10 is really suck under specific types of load (was fixed in OVS 1.11 and later). But plain upgrade of OVS breaks neutron (under research). \n> \n> Did anyone walk that path? \n> \n> Thanks. \n> \n> ______________________________ _________________ \n> OpenStack-operators mailing list \n> OpenStack-operators at lists. openstack.org \n> http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-operators \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<78c22258-8455-44b8-82d8-bcb2de98622e@zimbra>',NULL),('<1390254054.9651.5.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 16:40:54',-18000,'2014-01-20 21:40:54',NULL,'[openstack-dev] [Neturon] firewall_driver and ML2 and\n vif_security discussion','On Mon, 2014-01-20 at 20:43 +0100, Ian Wells wrote:\n> To my mind, it would make that much more sense if Neutron created,\n> networked and firewalled a tap and returned it completely set up\n> (versus now, where the VM can start with a half-configured set of\n> separation and firewall rules that get patched up asynchronously).\n\nAmen.\n\n-jay\n\n\n\n\n','<CAPoubz7=CV_JfhN8Y3Ytyc5J64V18=4V_bbS1pmcPjEwsar6ug@mail.gmail.com>',NULL),('<1390257636.9651.29.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 17:40:36',-18000,'2014-01-20 22:40:36',NULL,'[openstack-dev] [neutron] [third-party-testing] Which patchset\n triggered the test','On Mon, 2014-01-20 at 14:26 -0500, Mohammad Banikazemi wrote:\n> Have a question regarding the Jenkins/Gerrit setup for third party\n> testing setups.\n> \n> When Jenkins get triggered by a patchset through the Gerrit trigger\n> plug-in, you can execute a set of shell scripts. How do you get the\n> information about the patchset that triggered the test? In particular,\n> in your scripts how do you figure out which patchset triggered the\n> test. Here is why I am asking this question:\n> During our earlier IRC calls we said, one approach for testing would\n> be using devstack to install OpenStack and run appropriate tests. The\n> devstack stack.sh brings in the master branch without the patchset\n> which triggered the test. How do I access the patchset I want to test?\n> Am I missing something here?\n\nAs mentioned by a previous poster, the Gerrit plugin populates some\nenvironment variables that you may use in your scripts in order to fetch\nand check out the appropriate git branch and SHA1 that corresponds to\nthe changeset and patch number.\n\nFor a great example of how this is done in the upstream CI system for\nthe gate, check out the devstack-gate project and the setup_workspace()\n[1] Bash function. This function calls the setup_project() [2] Bash\nfunction for each project that is registered for devstack to construct.\nThe devstack-gate-wrap.sh script is responsible for enumerating all of\nthe projects that devstack will install [3].\n\nsetup_project() is responsible for setting the git checkouts for all of\nthe OpenStack projects involved in the devstack installation --\nincluding the project for which the triggering changeset is for. The\nfunction calls git clone on the project\'s upstream cgit repository URI\n[4], and then calls git fetch on the branch and SHA1 (ref) that\nrepresents the proposed changeset in Gerrit.\n\nIn the setup_project() function, you will notice the use of the\nenvironment variables $ZUUL_BRANCH and $ZUUL_REF. The upstream CI system\nuses a Python service called Zuul [6] to manage the graph of in-progress\nchangesets that are currently going through the gate testing process.\nWhile your in-house testing platform won\'t likely be using Zuul, the\nGerrit plugin [7] to Jenkins *will* have a similar $GERRIT_BRANCH and\n$GERRIT_REFSPEC environment variable that you can use in your scripts\nthat contains the git ref you can use in scripts in your in-house\ntesting in the same way that devstack-gate uses $ZUUL_BRANCH and\n$ZUUL_REF.\n\nFinally, once your in-house setup script has constructed the devstack\nenvironment -- including all of the git checkout\'d code trees, then to\nrun the Neutron testing suite, simply do the following:\n\ncd /opt/stack/new/devstack\nsudo -H -u stack ./tools/configure_tempest.sh\ncd /opt/stack/new/tempest\nsudo -H -u tempest tox -esmoke-serial\n\nHow did I know to run the above commands? Well, because that\'s what the\ncheck-tempest-dsvm-neutron-isolated (configured in the\nopenstack-infra/config project here: [8]) test runs in the\ndevstack-gate.sh script here: [9] :)\n\nAll the best,\n-jay\n\np.s. I\'m putting together some documentation walking through how these\nmany CI systems and gate projects all work together to configure and run\ntests against a devstack environment in the gate. I should be done by\nWednesday or Thursday and will publish a link to the ML. Hopefully, the\ninstructions will be helpful for Cinder, Neutron, and other contributors\nlooking to set up 3rd party driver verification testing.\n\n[1]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L208\n[2]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L164\n[3]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L27\n[4]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L96\n[5]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L28\n[6] http://ci.openstack.org/zuul.html\n[7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger\n[8] \nhttps://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml#L184\nand\nhttps://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/devstack-gate.yaml#L203\n[9]\nhttps://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L299 \nand \nhttps://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L344\n\n\n\n\n','<OFEF682555.2C1407B5-ON85257C66.006A0279-85257C66.006AD5ED@us.ibm.com>',NULL),('<1390258278.9651.33.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 17:51:18',-18000,'2014-01-20 22:51:18',NULL,'[openstack-dev] Top Gate Reseting issues that need attention','On Mon, 2014-01-20 at 18:43 +0400, Eugene Nikanorov wrote:\n> Hi Sean,\n\n> I think the following 2 commits in neutron are essential for bringing\n> neutron jobs back to acceptable level of failure rate:\n> https://review.openstack.org/#/c/67537/\n> https://review.openstack.org/#/c/66670/\n\nThat second patch has the gate-tempest-dsvm-neutron-isolated job failing\ntrying to run keystone-manage pki-setup:\n\nImportError: No module named passlib.hash\n\n-jay\n\n\n\n','<CAJfiwORxJsFn_4YNZ=cGx2Pc5m8LcrUU22Z8tB323o2YKmomkA@mail.gmail.com>',NULL),('<1390262200.15032.YahooMailNeo@web141002.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-20 15:56:40',-28800,'2014-01-20 23:56:40',NULL,'[Openstack] [Swift] Object use cases','Hello,\nI wanted to get an idea about what kind of use cases Object is being used for, and had some questions around that.\n\n1. ?What kind of use cases is object used for in the public cloud? What kinds of data are enterprises storing most commonly?\n\n2. Is anyone deploying Swift within the data center for a private cloud object solution, and if yes, what are the use cases for that as compared to say, using a NAS solution within the data center? I am looking for concrete information on actual use cases in terms of kinds of applications and the kind of data stored.\n\n3. Are companies building applications with object as the back end in mind rather than file which is the more common case? Any examples?\n\nThanks in advance!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140120/ac658a02/attachment.html>\n\n',NULL,NULL),('<1390268165.16859.0.camel@serialcoder>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-20 20:36:05',-18000,'2014-01-21 01:36:05',NULL,'[openstack-dev] Top Gate Reseting issues that need attention','I wasn\'t saying it was frequent :) Just that it was happening on one of\nthe patches that Eugene said needed to go through :)\n\n-jay\n\nOn Mon, 2014-01-20 at 19:04 -0500, Joe Gordon wrote:\n> \n> \n> \n> On Mon, Jan 20, 2014 at 5:51 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Mon, 2014-01-20 at 18:43 +0400, Eugene Nikanorov wrote:\n>         > Hi Sean,\n>         \n>         > I think the following 2 commits in neutron are essential for\n>         bringing\n>         > neutron jobs back to acceptable level of failure rate:\n>         > https://review.openstack.org/#/c/67537/\n>         > https://review.openstack.org/#/c/66670/\n>         \n>         \n>         That second patch has the gate-tempest-dsvm-neutron-isolated\n>         job failing\n>         trying to run keystone-manage pki-setup:\n>         \n>         ImportError: No module named passlib.hash\n> \n> \n> message:\"ImportError: No module named passlib.hash\" has only two hits\n> in logstash both for patch 66670\n> \n> \n> \n> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiSW1wb3J0RXJyb3I6IE5vIG1vZHVsZSBuYW1lZCBwYXNzbGliLmhhc2hcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiMTcyODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM5MDI2MjQwNjMzOH0=\n> \n>  \n>         \n>         -jay\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAHXdxOemMyi5XJrDsBGETDYT4rvAEc5-kiWkBWc-BdZ5yi8-aw@mail.gmail.com>',NULL),('<1390310543.22572.YahooMailNeo@web172401.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 13:22:23',0,'2014-01-21 13:22:23',NULL,'[openstack-dev] [Neutron] Selectively disabling certain built\n	in	iptables rules','\n\nI think there is a blueprint for that. Anyway, see idea for current releases below:\n\n\n>Feel free to tell me this is a bad idea and scold me for even asking, but please\n>help me figure out how to do it anyway. This is for a specific tenant in a\n>specific lab that was built specifically for that one tenant to do some\n>experimental work that requires VMs to route and other VMs to act as\n>DHCP/PXEBoot servers.\n\nTherefore all the compute-nodes in that lab can be safely configured to use a\nfirewall_driver in ovs_neutron_plugin.ini that points to a customised firewall\nclass. If using Open vSwitch, this can be a subclass of \nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\nwith the spoofing methods conditionally overridden to be no-ops.\n\n>\n>I need to wrap a conditional around this line\n>https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L201\n>and this line\n>https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L241\n>for specific VM instances.\n>\n>The criteria could be something like pattern matching on the instance name, or\n>based on a specific flavor image type. I don\'t much care what the criteria is as\n>long as it\'s something the tenant can control. What I\'m hoping someone can\n\nNeutron does not know about flavors or images. But it has ports which have a \nname attribute that can be set to an arbitrary string, e.g. \'anti_spoof_off\'. The\nname does not need to be unique within the tenant. Then your overridden methods\ncould check for that string.\n\nSo when the tenant has to create a router or dhcp instance, they would first\ncreate the neutron ports with this name, and then pass these port-ids to Nova.\n\n>provide me with is an example line of code or two with which I can examine some\n>property of the image that has been created from within the specific file\n>referenced above in order to wrap if statements around those two lines of code\n>so that I can prevent them from adding those specific iptables rules in the\n>specific cases where my tenant needs to either route or respond to DHCP.\n>\n>Thanks\n>\n>--\n>Paul Carver\n\n\n\n',NULL,NULL),('<1390317773.15396.13.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-21 15:22:53',0,'2014-01-21 15:22:53',NULL,'[openstack-tc] recommendation to deprecate XML in new major API\n versions','On Tue, 2014-01-14 at 09:29 -0500, Doug Hellmann wrote:\n\n> I would like to see an affirmative statement from the TC like \"We are\n> planning to start dropping XML support in APIs during Juno in order to\n> focus our limited development resources\" (or a later release, or \"we are\n> going to keep doing XML whether we like it or not\") posted to the mailing\n> list for feedback, rather than the open-ended \"what do you want\" questions\n> we\'ve been posing.\n\nI\'m generally against us closing doors and saying \"we never want XML\nsupport, no matter how much work you\'re willing to do on it\". A ban on\nXML or a \"JSON is the one true representation\" statement isn\'t what\nwe\'re trying to achieve.\n\nWe want:\n\n  1) Clear guidance to users that XML support is known to be very week \n     and, due to lack of interest in developing and maintaining it, XML \n     support could get worse in future releases. I\'m thinking XML\n     support off by default, warnings in documentation, notices in\n     release notes, etc.\n\n  2) An understanding that because of the lack of active maintenance of \n     XML support, authors of new features can choose to regress XML \n     support. Semi-working XML support can\'t be allowed to hold up \n     progress.\n\nMark.\n\n\n\n','<CADb+p3ThDOPvVnH2LevZrfbCdLACpptWQVGJhz4dHyCz65fYeg@mail.gmail.com>',NULL),('<1390320343.16821.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-21 16:05:43',0,'2014-01-21 16:05:43',NULL,'[openstack-tc] recommendation to deprecate XML in new major API\n versions','On Tue, 2014-01-21 at 10:53 -0500, Doug Hellmann wrote:\n> \n> \n> On Tuesday, January 21, 2014, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Tue, 2014-01-14 at 09:29 -0500, Doug Hellmann wrote:\n>         \n>         > I would like to see an affirmative statement from the TC\n>         like \"We are\n>         > planning to start dropping XML support in APIs during Juno\n>         in order to\n>         > focus our limited development resources\" (or a later\n>         release, or \"we are\n>         > going to keep doing XML whether we like it or not\") posted\n>         to the mailing\n>         > list for feedback, rather than the open-ended \"what do you\n>         want\" questions\n>         > we\'ve been posing.\n>         \n>         I\'m generally against us closing doors and saying \"we never\n>         want XML\n>         support, no matter how much work you\'re willing to do on it\".\n>         A ban on\n>         XML or a \"JSON is the one true representation\" statement isn\'t\n>         what\n>         we\'re trying to achieve.\n> \n> \n> I think we can be clear about the level of support we can sustain\n> without being draconian. My point was just that we should always\n> expect someone to say \"yes, please keep XML support\" if we ask it as a\n> question. At the same time, saying directly that we don\'t\n> require projects to support XML is not the same as forbidding its use.\n> Our choice of phrasing will be important. \n\nYep. Add:\n\n  3) Be explicit that (new and existing) projects (or even new versions \n     of their APIs are (so far) only required to support a JSON\n     representation\n\n>         We want:\n>         \n>           1) Clear guidance to users that XML support is known to be\n>         very week\n>              and, due to lack of interest in developing and\n>         maintaining it, XML\n>              support could get worse in future releases. I\'m thinking\n>         XML\n>              support off by default, warnings in documentation,\n>         notices in\n>              release notes, etc.\n>         \n>           2) An understanding that because of the lack of active\n>         maintenance of\n>              XML support, authors of new features can choose to\n>         regress XML\n>              support. Semi-working XML support can\'t be allowed to\n>         hold up\n>              progress.\n> \n> \n> Is a semi-working API useful enough to even ship turned off by\n> default?\n\nFair point - maybe \"working enough to be useful to some, even if not\nperfect\" is a better way of putting it.\n\nProjects are free to remove any features that have decayed beyond\nusefulness because of lack of interest.\n\nMark.\n\n\n\n\n','<CADb+p3QUU+OQt5OLan9M49fcBE6qApG1SYXeLpV5=DzVkT1-yQ@mail.gmail.com>',NULL),('<1390321799.16821.29.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-21 16:29:59',0,'2014-01-21 16:29:59',NULL,'[openstack-tc] recommendation to deprecate XML in new major API\n versions','Just going back to the original email to put my reaction into\ncontext ...\n\nSee inline.\n\nOn Tue, 2014-01-14 at 06:51 -0500, Sean Dague wrote:\n> I started becoming really active in OpenStack during the Folsom cycle,\n> and one of the big cleanups that Dan Smith and I did was at the very end\n> of the cycle. There was 0 testing on the Nova XML API, and if you\n> actually tried to use it, you got inconsistent responses, or stack\n> traces. There were at least 6 critical bugs in that API because no one\n> used it. That got fix by dual stacking the Tempest tests. We did this\n> because we thought it would be embarresing for OpenStack to ship with an\n> interface that it said supported, and that it didn\'t in any real way.\n\nI value those contributions and I think everyone should.\n\n> So I feel personally responsible for not letting XML die back in Nova v2\n> by making it actually work.\n\nRight, the Nova project could have explicitly deprecated Nova v2 XML\nsupport and done something like:\n\n  1) turn it off by default\n\n  2) mention in the release notes that it\'s turned off by default \n     because of those bugs, with a link to the bugs\n\n  3) state then that it would be removed in Grizzly if it didn\'t\n     it hadn\'t been restored back to a basic level of usefulness\n\n> Since then, many projects have followed Nova\'s lead and added XML APIs,\n> which I think has been completely wrong headed.\n\nI\'d hate to see the TC take a position like that.\n\nAccepting contributions which add useful XML support is not necessarily\nwrong-headed.\n\n> The only reason we\n> didn\'t rip it out in Nova v2 is that it would be breaking in field\n> compatibility without an API version bump. (Something else I feel\n> strongly about).\n\nI agree that backwards compat is important and it makes it a harder\ncall. But if, for example, it remained unusably broken in Folsom stable\nthen no-one could possibly have been using it with Folsom so removing it\nin Grizzly shouldn\'t be such a backwards compat issue.\n\n> However, the proliferation has costs (really costs in terms of people time).\n>  - It increases the amount of code in the projects, it impacts the kind\n> of data the JSON apis can return because they have to be XML friendly.\n>  - It doubles the width of the validation interface (and XML validation\n> is more code costly from python because it\'s not a direct serialization\n> like python).\n>  - It dramatically increases the width of the Documentation interface,\n> as we need XML examples as well as JSON.\n\nIf a project\'s XML support was usable and well maintained, then I don\'t\nsee the issue with those.\n\nOr put it this way, if projects add XML support they should be aware\nthey are taking on these additional costs. So long as they are aware,\nthat\'s fine.\n\n> And it\'s not something that\'s currently universal.\n>  - glance doesn\'t have an XML API\n\nIt\'s hardly the only lack of consistency between our APIs and at lest\nthis one is programmatically negotiable.\n\n>  - the python clients don\'t implement XML data payload\n\nNot necessarily an issue IMHO - that XML support is generally not widely\nused or tested is probably the real issue you\'re alluding to.\n\n> It also inhibits us doing really great things with our API, like making\n> it end user fully discoverable with json schema (because then we\'d need\n> to figure out how we\'d address that on the XML side, and that complexity\n> tends to kill the innovation).\n\nI could imagine adding discoverability to the json representation\nwithout also adding it to XML ... but devils in the details.\n\nAs a general point, yes - new features often increases complexity and\nhas an impact on the ability to evolve other features.\n\n> With a new Nova API on the horizon, I think it\'s time to make a TC level\n> recommendation that XML payloads be deprecated, and that new major API\n> versions don\'t include them.\n\nI\'d be happy to say we don\'t think it is required, that projects should\nbe aware of the burden of supporting additional representations and\nperhaps outline the history of lack of active contributions to XML\nsupport in OpenStack generally.\n\nIOW, a cautionary tale but projects are free to make their own choice on\nthe matter.\n\n> I\'d like to bring this up for discussion either next week or the week\n> after, because I think that the way every version of this discussion has\n> gone in the past is a few people on a mailing list object, and we keep\n> the XML API. However I think that\'s not serving our users well, because\n> way too much energy gets diverted from really making our core JSON API\n> excellent for users.\n\nThere\'s a touch of \"contributor energy is a fungible resource\" thinking\nabout that which I don\'t like - people will make their own decisions\nabout where to invest their energy.\n\nBut I think you\'re talking again about the existence of unmaintained XML\nsupport forcing some people to spend energy on it - that is frustrating\nand I absolutely agree that projects should be free to address that if\nthey feel they\'re trapped in that situation.\n\nMark.\n\n\n\n','<52D524C3.1080304@dague.net>',NULL),('<1390322467.67285.YahooMailNeo@web141005.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-21 08:41:07',-28800,'2014-01-21 16:41:07',NULL,'[Openstack] [Swift] Object use cases','Thanks!\n\nAny others in the private cloud space also, other than file sharing? If you can list your experiences with customers on what kind of data they store and why use it as compared to, say a NAS as the questions in the original email specifies, that would be great:-)\n\nThanks in advance.\n\n\n\nOn Monday, January 20, 2014 5:19 PM, Dnsbed Ops <ops at dnsbed.com> wrote:\n \nOn 2014-1-21 7:56, Mark Brown wrote:\n\n> I wanted to get an idea about what kind of use cases Object is being\n> used for, and had some questions around that.\n>\n> 1.? What kind of use cases is object used for in the public cloud?\n\nDropbox\'s backend storage is the object storage Amazon S3.\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140121/0c81efcd/attachment.html>\n\n','<52DDC777.6030708@dnsbed.com>',NULL),('<1390331039.80777.YahooMailNeo@web172401.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 19:03:59',0,'2014-01-21 19:03:59',NULL,'[openstack-dev] [Neutron] Selectively disabling\n	certain	built	in iptables rules','\n\n>\n>Darragh O\'Reilly wrote:\n>\n>>Neutron does not know about flavors or images. But it has ports which have a \n>>name attribute that can be set to an arbitrary string, e.g. \'anti_spoof_off\'. The\n>>name does not need to be unique within the tenant. Then your overridden methods\n>>could check for that string.\n>\n>Everything in your response (and Ian\'s too) was interesting and helpful but I have\n>a further question on this specifically. This is entirely due to my ignorance, but\n>could you possibly point me to an example line of code somewhere that shows\n>something checking the port name attribute and doing something conditional\n>based on it? I\'m not sure exactly what to search on so I\'ve just been browsing\n>the code without finding anything that looks like it might be doing that.\n\nI don\'t know of any examples. You should be able to do something like this to skip\nlines when ports have a special name:\n\nif port[\'name\'] != \"no-anti-spoof\":\n??? # code for anti-spoof\n\n\n>\n\n\n',NULL,NULL),('<1390345605.2144.1.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 18:06:45',-18000,'2014-01-21 23:06:45',NULL,'[openstack-dev] Cinder unit test failure','On Tue, 2014-01-21 at 08:29 +0530, iKhan wrote:\n> I am worried which one is better in terms of performance? iniparse or\n> ConfigParser?\n> \n> I am aware iniparse will do a better job of maintaining INI file\'s\n> structure, but I am more interested in performance.\n\nThe parsing of INI files is the last thing you should be worried about\nfrom a performance perspective. It\'s not as if your project is built\naround the constant parsing and writing of INI files. It\'s done once on\nstartup. Who cares about the performance of this?\n\nBest,\n-jay\n\n\n\n\n','<CADBmBnuHOc8AGk+25dHdp0fsnN2qBmB1Uzugjb4OrT_Pc-3fBw@mail.gmail.com>',NULL),('<1390346899-sup-696@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 15:38:41',-28800,'2014-01-21 23:38:41',NULL,'[openstack-dev] Unified Guest Agent, PoC for os-collect-config','Excerpts from Dmitry Mescheryakov\'s message of 2014-01-21 09:30:17 -0800:\n> Hello folks,\n> \n> At the end of the previous discussion on the topic [1] I\'ve decided to make\n> a PoC based on oslo.messaging. Clint suggested and I agreed to make it for\n> os-collect-config. Actually I\'ve made a PoC for Savanna first :-) but\n> anyway here is the one for os-collect-config [2].\n> \n> I\'ve made a couple of observations:\n> \n> First, the os-collect-config naturally becomes an RPC server. That gives an\n> advantage of having feedback, i.e. knowing that the desired config was\n> actually received and applied.\n> \n> Second, with the oslo.messaging approach seems like there is almost nothing\n> to extract to common code. It is rather well seen on the minimal example\n> like os-config-apply. I thought there would be something to share between\n> projects using the agent, but so far it\n> looks like oslo.messaging already covers all the needs. Which IMHO is great!\n> \n> So, any thoughts?\n> \n\nPretty cool! Thanks for diving down this rabbit hole Dmitry.\n\nI have a few thoughts:\n\nI had originally thought that RPC would just become another collector. One\nthat is updated more actively. The loss of ec2/cfn/heat_local means that\nthis can\'t be used in the boot-strapping of the RPC itself the way we\nuse heat_local right now to bootstrap cfn.\n\nHowever, perhaps with Heat changes, cloud-init can just bootstrap the\nappropriate credentials and connection information in and this tool can\njust read that and only speak RPC.\n\nSeems like the next hurdle is to change from calling a single command\nwith some json populated to actual plugins that implement RPC calls.\nAlso replies would probably be important. :)\n\nAnyway, I\'m very interested to see how this progresses. Keep us posted!\n\n\n','<CALU-hjHY_xcdM8UNiwLiMus+LobmrF7zoZ7zEeKLMAU7c=h44g@mail.gmail.com>',NULL),('<1390355227.2144.10.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 20:47:07',-18000,'2014-01-22 01:47:07',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','On Tue, 2014-01-21 at 11:57 +0000, Day, Phil wrote:\n> > > > So, I actually don\'t think the two concepts (reservations and\n> > > > \"isolated instances\") are competing ideas. Isolated instances are\n> > > > actually not reserved. They are simply instances that have a\n> > > > condition placed on their assignment to a particular compute node\n> > > > that the node must only be hosting other instances of one or more\n> > > > specified projects (tenants).\n> > >\n> > > I got your idea. This filter [1] already does most of the work,\n> > > although it relies on aggregates and requires admin management. The\n> > > main issue with isolated instances is that it requires kind of\n> > > capacity planning for making sure you can cope with the load, that\'s\n> > > why we placed the idea of having such a placement scheduler.\n> > >\n> > > [1] :\n> > >\n> > https://github.com/openstack/nova/blob/master/nova/scheduler/filters/a\n> > > ggregate_multitenancy_isolation.py\n> > \n> > Right, the difference between that and my proposed solution would be\n> > there would be no dependency on any aggregate at all.\n> > \n> > I do understand your point about capacity planning in light of such scheduling\n> > functionality -- due to the higher likelihood that compute nodes would be\n> > unable to service a more general workload from other tenants.\n> > \n> > But I believe that the two concerns can be tackled separately.\n> > \n> Exactly - that\'s why I wanted to start this debate about the way forward for the Pcloud Blueprint, which was heading into some kind of middle ground.  As per my original post, and it sounds like the three of us are at least aligned I\'m proposing to spilt this into two streams:\n> \n> i) A new BP that introduces the equivalent of AWS dedicated instances. \n> 	User - Only has to specify that at boot time that the instance must be on a host used exclusively by that tenant.\n> 	Scheduler - ether finds a hoist which matches this constraint or it doesn\'t.   No linkage to aggregates (other than that from other filters), no need for the aggregate to have been pre-configured\n> 	Compute Manager - has to check the constraint (as with any other scheduler limit) and add the info that this is a dedicated instance to notification messages\n> 	Operator - has to manage capacity as they do for any other such constraint (it is a significant capacity mgmt issue, but no worse in my mind that having flavors that can consume most of a host) , and work out how they want to charge for such a model (flat rate additional charge for first such instance, charge each time a new host is used, etc).\n> \n> I think there is clear water between this and the existing aggregate based isolation.  I also think this is a different use case from reservations.   It\'s *mostly* like a new scheduler hint, but because it has billing impacts I think it needs to be more than just that - for example the ability to request a dedicated instance is something that should be controlled by a specific role.\n> \n> ii) Leave the concept of \"private clouds within a cloud\"  to something that can be handled at the region level.  I think there are valid use cases here, but it doesn?t make sense to try and get this kind of granularity within Nova.\n\nAbove sounds good to me. :)\n\n-jay\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F895F7@G6W2490.americas.hpqcorp.net>',NULL),('<1390355436.2144.13.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 20:50:36',-18000,'2014-01-22 01:50:36',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','On Tue, 2014-01-21 at 14:28 +0000, Day, Phil wrote:\n> > >\n> > > I think there is clear water between this and the existing aggregate based\n> > isolation.  I also think this is a different use case from reservations.   It\'s\n> > *mostly* like a new scheduler hint, but because it has billing impacts I think it\n> > needs to be more than just that - for example the ability to request a\n> > dedicated instance is something that should be controlled by a specific role.\n> > >\n> > \n> > I agree with that, that\'s another scheduler filter with extra scheduler hint,\n> > plus a notification message on the AMQP queue thanks to an handler. That\'s\n> > not role of Nova but Ceilometer to handle billable items and meters\n> > consolidation.\n> > That said, AWS dedicated instances are backed by VPC, so that\'s not fairly\n> > identical from what you propose here. Here the proposal is more likely\n> > making me thinking of AWS \"reserved\" instances without a contractual\n> > period.\n> > \n> > IMHO, this model is interesting but hard to use for operators, because they\n> > don\'t have visibility on the capacity. Anyway, if Nova would provide this\n> > feature, Climate would be glad using it (and on a personal note, I would be\n> > glad contributing to it).\n> > \n> \n> I think VPC in AWS is more of a network construct that anything to do with specific hosts - (i.e the difference between running nova-net or neutron in flat mode vs vlan or vxlan mode).\n\nThat is correct. VPC is about network isolation, not host isolation. At\nleast, that is how I understand the AWS VPC docs.\n\n> I agree that it is hard for an operator to work out how to charge for this - in effect it comes down to some sort of statistical model to work out what additional premium you need to charge to recover the cost of the capacity that is now not usable by other tenants.   This kind of thing becomes easier at scale than it is for very small systems.   So some/many operators may decide that they don\'t want to offer it (which is why it needs to be a specific feature in my mind, even if that does mean a minor bump to the API version in V3 and a new extension to provide the new option in V2 - sorry Jay).   It probably even merits its own specific quota value (max number of dedicated instances).   I\'m not sure that its really that much harder to manage than any other capacity issue though - for example if you define a flavor that occupies \n\nYup, agreed. It\'s difficult to guess what the capacity implications\nwould be without having solid numbers on customer demands for this\nfunctionality, including hard data on how long such instances would\ntypically live (see my previous point about re-using compute hosts for\nother purposes once the last dedicated instance is terminated on that\nhost).\n\nBest,\n-jay\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F898B4@G6W2490.americas.hpqcorp.net>',NULL),('<1390356046.2144.19.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 21:00:46',-18000,'2014-01-22 02:00:46',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','On Tue, 2014-01-21 at 14:21 +0000, Khanh-Toan Tran wrote:\n> > Exactly - that\'s why I wanted to start this debate about the way forward \n> > for the\n> > Pcloud Blueprint, which was heading into some kind of middle ground.  As \n> > per\n> > my original post, and it sounds like the three of us are at least aligned \n> > I\'m\n> > proposing to spilt this into two streams:\n> >\n> > i) A new BP that introduces the equivalent of AWS dedicated instances.\n> \n> Why do you want to transform pCloud into AWS dedicated instances? As I see \n> it,\n> pCloud is for requesting physical hosts (HostFlovors as in pcloud wiki) on \n> which\n> users can create their own instances (theoretically in unlimited number). \n> Therefore it should be charged per physical server\n> (HostFlavor), not by instances. It is completely different from AWS \n> dedicated instances\n> which is charged per instance. IMO, pcloud resembles Godrid Dedicated \n> Server, not\n> AWS Dedicated Instance.\n\nIt resembles managed/dedicated hosting. Not cloud.\n\n-jay\n\n\n\n','<021cc2d3.0000142c.00000011@cw-lap-8TWXLX1>',NULL),('<1390407239838.bc8e0c5c@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 08:14:00',-28800,'2014-01-22 16:14:00',NULL,'[openstack-dev] [Neutron][IPv6] A pair of mode keywords','Ian,?\n\n\nI think the last \"two attributes\" PDF from Shixiong\'s last email is trying to solve the problem you are saying, right?\n?\nXu Han Peng (xuhanp)\n\nOn Wed, Jan 22, 2014 at 8:15 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:\n\n> On 21 January 2014 22:46, Veiga, Anthony <Anthony_Veiga at cable.comcast.com>wrote:\n>>\n>>    Hi, Sean and Xuhan:\n>>\n>>  I totally agree. This is not the ultimate solution with the assumption\n>> that we had to use ?enable_dhcp?.\n>>\n>>  We haven?t decided the name of another parameter, however, we are open\n>> to any suggestions. As we mentioned during the meeting, the second\n>> parameter should highlight the need of addressing. If so, it should have at\n>> least four values:\n>>\n>>  1) off (i.e. address is assigned by external devices out of OpenStack\n>> control)\n>> 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq)\n>> 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting\n>> as DHCPv6 stateful server)\n>> 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from\n>> either OpenStack dnsmasq, or external router, and optional information is\n>> retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server)\n>>\n>>\n> So how does this work if I have an external DHCPv6 server and an internal\n> router?  (How baroque do we have to get?)  enable_dhcp, for backward\n> compatibility reasons, should probably disable *both* RA and DHCPv6,\n> despite the name, so we can\'t use that to disable the DHCP server.  We\n> could add a *third* attribute, which I hate as an idea but does resolve the\n> problem - one flag for each of the servers, one for the mode the servers\n> are operating in, and enable_dhcp which needs to DIAF but will persist till\n> the API is revved.\n> -- \n> Ian.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/8bb8c8dc/attachment.html>\n\n','<CAPoubz7ftfYdnicHkkTTkBugiBNk6Yn8sbo6bcxuK_3hwrdCNw@mail.gmail.com>',NULL),('<1390411083.2144.23.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-22 12:18:03',-18000,'2014-01-22 17:18:03',NULL,'[Openstack] Export tenant configuration','On Wed, 2014-01-22 at 17:21 +0100, Salvo Rapisarda wrote:\n> But you surely know that MySQL is not the only SQL back-end for \n> OpenStack services. ;-)\n\nI don\'t see any mention of MySQL below by Nick Ma.\n\n> This is why I was looking for an alternative solution for export/import \n> the structure of my project.\n\nWhat do you mean by \"structure of my project\"? The data for the various\nresources consumed by your project is stored in a number of databases.\nAdditionally, with data about the project itself is stored in the\nKeystone back-end storage (either RDBMS, KVS or LDAP).\n\nIf you want to port the network configuration from Grizzly to Havana, UI\nwould just make a snapshot of your Quantum database in Grizzly and start\nyour Havana database from that snapshot, and run the db schema\nmigrations on it.\n\nBest,\n-jay\n\n> Salvo.\n> \n> Il 22/01/2014 15.57, Nick Ma ha scritto:\n> > AFAIK, in OpenStack, all the data is stored in sql server and there\'s no\n> > so-called \"automatic script\" for this task, but you can dump the desired\n> > data from sql server and restore them into the new sql server. You can\n> > have a try.\n> >\n> > Nick Ma\n> >\n> > On 1/21/2014 10:24 PM, Salvo Rapisarda wrote:\n> >> Hello,\n> >>\n> >>\n> >> in OpenStack there is a function that export/import the structure of a\n> >> project (Network,Volume,VMs,ecc...) ?\n> >>\n> >> For example, I want to export a complex network configuration from a\n> >> Grizzly installation to Havana installation.\n> >>\n> >> I know that with a bash script it\'s possible to re-create my tenant\n> >> via nova command but exists an \"automated\" version?\n> >>\n> >> It is possible ?\n> >>\n> >> Thanks,\n> >> Salvo.\n> >>\n> >> _______________________________________________\n> >> Mailing list:\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >> Post to     : openstack at lists.openstack.org\n> >> Unsubscribe :\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >\n> \n> \n\n\n\n\n','<52DFF023.8070102@yahoo.it>',NULL),('<1390411585-sup-3865@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 09:45:45',-28800,'2014-01-22 17:45:45',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> I\'ve been thinking a bit more about how TripleO updates are developing\n> specifically with regards to compute nodes. What is commonly called the\n> \"update story\" I think.\n> \n> As I understand it we expect people to actually have to reboot a compute\n> node in the cluster in order to deploy an update. This really worries me\n> because it seems like way overkill for such a simple operation. Lets say\n> all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> I need to deploy it to *all* my compute instances. Do we really expect\n> people to actually have to reboot every single compute node in their\n> cluster for such a thing. And then do this again and again for each\n> update they deploy?\n> \n\nAgreed, if we make everybody reboot to push out a patch to libvirt, we\nhave failed. And thus far, we are failing to do that, but with good\nreason.\n\nRight at this very moment, we are leaning on \'rebuild\' in Nova, which\nreboots the instance. But this is so that we handle the hardest thing\nwell first (rebooting to have a new kernel).\n\nFor small updates we need to decouple things a bit more. There is a\nnotion of the image ID in Nova, versus the image ID that is actually\nrunning. Right now we update it with a nova rebuild command only.\n\nBut ideally we would give operators a tool to optimize and avoid the\nreboot when it is appropriate. The heuristic should be as simple as\ncomparing kernels. Once we have determined that a new image does not\nneed a reboot, we can just change the ID in Metadata, and an\nos-refresh-config script will do something like this:\n\nif [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\nthen;\n    download_new_image\n    mount_image /tmp/new_image\n    mount / -o remount,rw # Assuming we\'ve achieved ro root\n    rsync --one-file-system -a /tmp/new_image/ /\n    mount / -o remount,ro # ditto\nfi\n\nNo reboot required. This would run early in configure.d, so that any\npre-configure.d scripts will have run to quiesce services that can\'t\nhandle having their binaries removed out from under them (read:\nnon-Unix services). Then configure.d runs as usual, configures things,\nrestarts services, and we are now running the new image.\n\n> I understand the whole read only images thing plays into this too... but\n> I\'m wondering if there is a middle ground where things might work\n> better. Perhaps we have a mechanism where we can tar up individual venvs\n> from /opt/stack/ or perhaps also this is an area where real OpenStack\n> packages could shine. It seems like we could certainly come up with some\n> simple mechanisms to deploy these sorts of changes with Heat such that\n> compute host reboot can be avoided for each new deploy.\n\nGiven the scenario above, that would be a further optimization. I don\'t\nthink it makes sense to specialize for venvs or openstack services\nthough, so just \"ensure the root filesystems match\" seems like a\nworkable, highly efficient system. Note that we\'ve talked about having\nhighly efficient ways to widely distribute the new images as well.\n\nI would call your e-mail a documentation/roadmap bug. This plan may\nhave been recorded somewhere, but for me it has just always been in my\nhead as the end goal (thanks to Robert Collins for drilling the hole\nand pouring it in there btw ;).\n\n\n','<1029607256.9197253.1390411044993.JavaMail.root@redhat.com>',NULL),('<1390415433-sup-7948@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:46:55',-28800,'2014-01-22 18:46:55',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Dan Prince\'s message of 2014-01-22 10:15:20 -0800:\n> \n> ----- Original Message -----\n> > From: \"Clint Byrum\" <clint at fewbar.com>\n> > To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> > Sent: Wednesday, January 22, 2014 12:45:45 PM\n> > Subject: Re: [openstack-dev] [TripleO] our update story: can people live    with it?\n> > \n> > Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> > > I\'ve been thinking a bit more about how TripleO updates are developing\n> > > specifically with regards to compute nodes. What is commonly called the\n> > > \"update story\" I think.\n> > > \n> > > As I understand it we expect people to actually have to reboot a compute\n> > > node in the cluster in order to deploy an update. This really worries me\n> > > because it seems like way overkill for such a simple operation. Lets say\n> > > all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> > > I need to deploy it to *all* my compute instances. Do we really expect\n> > > people to actually have to reboot every single compute node in their\n> > > cluster for such a thing. And then do this again and again for each\n> > > update they deploy?\n> > > \n> > \n> > Agreed, if we make everybody reboot to push out a patch to libvirt, we\n> > have failed. And thus far, we are failing to do that, but with good\n> > reason.\n> > \n> > Right at this very moment, we are leaning on \'rebuild\' in Nova, which\n> > reboots the instance. But this is so that we handle the hardest thing\n> > well first (rebooting to have a new kernel).\n> > \n> > For small updates we need to decouple things a bit more. There is a\n> > notion of the image ID in Nova, versus the image ID that is actually\n> > running. Right now we update it with a nova rebuild command only.\n> > \n> > But ideally we would give operators a tool to optimize and avoid the\n> > reboot when it is appropriate. The heuristic should be as simple as\n> > comparing kernels.\n> \n> When we get to implementing such a thing I might prefer it not to be auto-magic. I can see a case where I want the new image but maybe not the new kernel. Perhaps this should be addressed when building the image (by using the older kernel)... but still. I could see a case for explicitly not wanting to reboot here as well.\n> \n\nI prefer choosing what to update at image build time. This is the time\nwhere it is most clear how, from a developer and deployer standpoint,\nto influence the update. I can diff images, I can freeze mirrors.. etc.\netc, all decoupled from anybody else and from production or test cycles.\n\nThat said, I do think it would be good for deployers to be able have\na way to control when reboots are and aren\'t allowed. That seems like\npolicy, which may be best handled in Nova.. so we can have a user that\ncan do updates to Heat Metadata/stacks, but not rebuilds in Nova.\n\nI have no idea of Heat\'s trust model will allow us to have such separation\nthough.\n\n> > Once we have determined that a new image does not\n> > need a reboot, we can just change the ID in Metadata, and an\n> > os-refresh-config script will do something like this:\n> > \n> > if [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\n> > then;\n> >     download_new_image\n> >     mount_image /tmp/new_image\n> >     mount / -o remount,rw # Assuming we\'ve achieved ro root\n> >     rsync --one-file-system -a /tmp/new_image/ /\n> >     mount / -o remount,ro # ditto\n> > fi\n> > \n> > No reboot required. This would run early in configure.d, so that any\n> > pre-configure.d scripts will have run to quiesce services that can\'t\n> > handle having their binaries removed out from under them (read:\n> > non-Unix services). Then configure.d runs as usual, configures things,\n> > restarts services, and we are now running the new image.\n> \n> Cool. I like this a good bit better as it avoids the reboot. Still, this is a rather large amount of data to copy around if I\'m only changing a single file in Nova.\n> \n\nI think in most cases transfer cost is worth it to know you\'re deploying\nwhat you tested. Also it is pretty easy to just do this optimization\nbut still be rsyncing the contents of the image. Instead of downloading\nthe whole thing we could have a box expose the mounted image via rsync\nand then all of the machines can just rsync changes. Also rsync has a\nbatch mode where if you know for sure the end-state of machines you can\npre-calculate that rsync and just ship that. Lots of optimization\npossible that will work fine in your just-update-one-file scenario.\n\nBut really, how much does downtime cost? How much do 10Gb NICs and\nswitches cost?\n\n> > \n> > > I understand the whole read only images thing plays into this too... but\n> > > I\'m wondering if there is a middle ground where things might work\n> > > better. Perhaps we have a mechanism where we can tar up individual venvs\n> > > from /opt/stack/ or perhaps also this is an area where real OpenStack\n> > > packages could shine. It seems like we could certainly come up with some\n> > > simple mechanisms to deploy these sorts of changes with Heat such that\n> > > compute host reboot can be avoided for each new deploy.\n> > \n> > Given the scenario above, that would be a further optimization. I don\'t\n> > think it makes sense to specialize for venvs or openstack services\n> > though, so just \"ensure the root filesystems match\" seems like a\n> > workable, highly efficient system. Note that we\'ve talked about having\n> > highly efficient ways to widely distribute the new images as well.\n> \n> Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> \n> 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> \n> 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> \n> 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n> \n\nThis seems like buying a few GB of transfer for an unknown amount of\ncomplexity.\n\n\n','<1217496495.9269263.1390414519991.JavaMail.root@redhat.com>',NULL),('<1390416446-sup-94@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:55:05',-28800,'2014-01-22 18:55:05',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Agreed, it is tricky if we try to only restart what we\'ve changed.\n\nOR, just restart everything. We can make endpoints HA and use rolling\nupdates to avoid spurious faults.\n\nThere are complex ways to handle things even smoother.. but I go back to\n\"What does complexity cost?\"\n\nExcerpts from Fox, Kevin M\'s message of 2014-01-22 10:32:02 -0800:\n> Another tricky bit left is how to handle service restarts as needed?\n> \n> Thanks,\n> Kevin\n> ________________________________________\n> From: Dan Prince [dprince at redhat.com]\n> Sent: Wednesday, January 22, 2014 10:15 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [TripleO] our update story: can people     live    with it?\n> \n> ----- Original Message -----\n> > From: \"Clint Byrum\" <clint at fewbar.com>\n> > To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> > Sent: Wednesday, January 22, 2014 12:45:45 PM\n> > Subject: Re: [openstack-dev] [TripleO] our update story: can people live      with it?\n> >\n> > Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> > > I\'ve been thinking a bit more about how TripleO updates are developing\n> > > specifically with regards to compute nodes. What is commonly called the\n> > > \"update story\" I think.\n> > >\n> > > As I understand it we expect people to actually have to reboot a compute\n> > > node in the cluster in order to deploy an update. This really worries me\n> > > because it seems like way overkill for such a simple operation. Lets say\n> > > all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> > > I need to deploy it to *all* my compute instances. Do we really expect\n> > > people to actually have to reboot every single compute node in their\n> > > cluster for such a thing. And then do this again and again for each\n> > > update they deploy?\n> > >\n> >\n> > Agreed, if we make everybody reboot to push out a patch to libvirt, we\n> > have failed. And thus far, we are failing to do that, but with good\n> > reason.\n> >\n> > Right at this very moment, we are leaning on \'rebuild\' in Nova, which\n> > reboots the instance. But this is so that we handle the hardest thing\n> > well first (rebooting to have a new kernel).\n> >\n> > For small updates we need to decouple things a bit more. There is a\n> > notion of the image ID in Nova, versus the image ID that is actually\n> > running. Right now we update it with a nova rebuild command only.\n> >\n> > But ideally we would give operators a tool to optimize and avoid the\n> > reboot when it is appropriate. The heuristic should be as simple as\n> > comparing kernels.\n> \n> When we get to implementing such a thing I might prefer it not to be auto-magic. I can see a case where I want the new image but maybe not the new kernel. Perhaps this should be addressed when building the image (by using the older kernel)... but still. I could see a case for explicitly not wanting to reboot here as well.\n> \n> > Once we have determined that a new image does not\n> > need a reboot, we can just change the ID in Metadata, and an\n> > os-refresh-config script will do something like this:\n> >\n> > if [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\n> > then;\n> >     download_new_image\n> >     mount_image /tmp/new_image\n> >     mount / -o remount,rw # Assuming we\'ve achieved ro root\n> >     rsync --one-file-system -a /tmp/new_image/ /\n> >     mount / -o remount,ro # ditto\n> > fi\n> >\n> > No reboot required. This would run early in configure.d, so that any\n> > pre-configure.d scripts will have run to quiesce services that can\'t\n> > handle having their binaries removed out from under them (read:\n> > non-Unix services). Then configure.d runs as usual, configures things,\n> > restarts services, and we are now running the new image.\n> \n> Cool. I like this a good bit better as it avoids the reboot. Still, this is a rather large amount of data to copy around if I\'m only changing a single file in Nova.\n> \n> >\n> > > I understand the whole read only images thing plays into this too... but\n> > > I\'m wondering if there is a middle ground where things might work\n> > > better. Perhaps we have a mechanism where we can tar up individual venvs\n> > > from /opt/stack/ or perhaps also this is an area where real OpenStack\n> > > packages could shine. It seems like we could certainly come up with some\n> > > simple mechanisms to deploy these sorts of changes with Heat such that\n> > > compute host reboot can be avoided for each new deploy.\n> >\n> > Given the scenario above, that would be a further optimization. I don\'t\n> > think it makes sense to specialize for venvs or openstack services\n> > though, so just \"ensure the root filesystems match\" seems like a\n> > workable, highly efficient system. Note that we\'ve talked about having\n> > highly efficient ways to widely distribute the new images as well.\n> \n> Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> \n> 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> \n> 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> \n> 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n> \n> >\n> > I would call your e-mail a documentation/roadmap bug.\n> \n> Fair enough. Thanks for the info.\n> \n> > This plan may have been recorded somewhere, but for me it has just always been in my\n> > head as the end goal (thanks to Robert Collins for drilling the hole\n> > and pouring it in there btw ;).\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1A3C52DFCD06494D8528644858247BF00D4A65@EX10MBOX03.pnnl.gov>',NULL),('<1390416794.2144.46.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 13:53:14',-18000,'2014-01-22 18:53:14',NULL,'[openstack-dev] [TripleO] our update story: can people\n	live	with it?','On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:\n> \n> ----- Original Message -----\n> > From: \"Clint Byrum\" <clint at fewbar.com>\n> > To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> > Sent: Wednesday, January 22, 2014 12:45:45 PM\n> > Subject: Re: [openstack-dev] [TripleO] our update story: can people live	with it?\n> > \n> > Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> > > I\'ve been thinking a bit more about how TripleO updates are developing\n> > > specifically with regards to compute nodes. What is commonly called the\n> > > \"update story\" I think.\n> > > \n> > > As I understand it we expect people to actually have to reboot a compute\n> > > node in the cluster in order to deploy an update. This really worries me\n> > > because it seems like way overkill for such a simple operation. Lets say\n> > > all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> > > I need to deploy it to *all* my compute instances. Do we really expect\n> > > people to actually have to reboot every single compute node in their\n> > > cluster for such a thing. And then do this again and again for each\n> > > update they deploy?\n> > > \n> > \n> > Agreed, if we make everybody reboot to push out a patch to libvirt, we\n> > have failed. And thus far, we are failing to do that, but with good\n> > reason.\n> > \n> > Right at this very moment, we are leaning on \'rebuild\' in Nova, which\n> > reboots the instance. But this is so that we handle the hardest thing\n> > well first (rebooting to have a new kernel).\n> > \n> > For small updates we need to decouple things a bit more. There is a\n> > notion of the image ID in Nova, versus the image ID that is actually\n> > running. Right now we update it with a nova rebuild command only.\n> > \n> > But ideally we would give operators a tool to optimize and avoid the\n> > reboot when it is appropriate. The heuristic should be as simple as\n> > comparing kernels.\n> \n> When we get to implementing such a thing I might prefer it not to be auto-magic. I can see a case where I want the new image but maybe not the new kernel. Perhaps this should be addressed when building the image (by using the older kernel)... but still. I could see a case for explicitly not wanting to reboot here as well.\n\n++\n\n> > Once we have determined that a new image does not\n> > need a reboot, we can just change the ID in Metadata, and an\n> > os-refresh-config script will do something like this:\n> > \n> > if [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\n> > then;\n> >     download_new_image\n> >     mount_image /tmp/new_image\n> >     mount / -o remount,rw # Assuming we\'ve achieved ro root\n> >     rsync --one-file-system -a /tmp/new_image/ /\n> >     mount / -o remount,ro # ditto\n> > fi\n> > \n> > No reboot required. This would run early in configure.d, so that any\n> > pre-configure.d scripts will have run to quiesce services that can\'t\n> > handle having their binaries removed out from under them (read:\n> > non-Unix services). Then configure.d runs as usual, configures things,\n> > restarts services, and we are now running the new image.\n> \n> Cool. I like this a good bit better as it avoids the reboot. Still, this is a rather large amount of data to copy around if I\'m only changing a single file in Nova.\n\nRight.\n\n> > \n> > > I understand the whole read only images thing plays into this too... but\n> > > I\'m wondering if there is a middle ground where things might work\n> > > better. Perhaps we have a mechanism where we can tar up individual venvs\n> > > from /opt/stack/ or perhaps also this is an area where real OpenStack\n> > > packages could shine. It seems like we could certainly come up with some\n> > > simple mechanisms to deploy these sorts of changes with Heat such that\n> > > compute host reboot can be avoided for each new deploy.\n> > \n> > Given the scenario above, that would be a further optimization. I don\'t\n> > think it makes sense to specialize for venvs or openstack services\n> > though, so just \"ensure the root filesystems match\" seems like a\n> > workable, highly efficient system. Note that we\'ve talked about having\n> > highly efficient ways to widely distribute the new images as well.\n> \n> Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> \n> 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> \n> 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> \n> 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n\n++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD\nenvironments, so this level of optimization will be frequently used.\nAnd, as I\'ve said before, optimizing for frequently-used scenarios is\nworth spending the time on. Optimizing for infrequently-occurring\nthings... not so much. :)\n\nBest,\n-jay\n\n\n\n','<1217496495.9269263.1390414519991.JavaMail.root@redhat.com>',NULL),('<1390418662.2144.48.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-22 14:24:22',-18000,'2014-01-22 19:24:22',NULL,'[Openstack] Export tenant configuration','On Wed, 2014-01-22 at 20:06 +0100, Salvo Rapisarda wrote:\n> Il 22/01/2014 18.18, Jay Pipes ha scritto:\n> > On Wed, 2014-01-22 at 17:21 +0100, Salvo Rapisarda wrote:\n> >> But you surely know that MySQL is not the only SQL back-end for\n> >> OpenStack services. ;-)\n> >\n> > I don\'t see any mention of MySQL below by Nick Ma.\n> \n> Sorry, you are right.\n> MySQL is my OpenStack sql backend. :)\n> \n> \n> >> This is why I was looking for an alternative solution for export/import\n> >> the structure of my project.\n> >\n> > What do you mean by \"structure of my project\"? The data for the various\n> > resources consumed by your project is stored in a number of databases.\n> > Additionally, with data about the project itself is stored in the\n> > Keystone back-end storage (either RDBMS, KVS or LDAP).\n> >\n> > If you want to port the network configuration from Grizzly to Havana, UI\n> > would just make a snapshot of your Quantum database in Grizzly and start\n> > your Havana database from that snapshot, and run the db schema\n> > migrations on it.\n> >\n> > Best,\n> > -jay\n> >\n> I know, but I think can be helpful to use a tool for generate, for \n> example, an XML file of my Project that is compatible with the all \n> releases of OpenStack.\n\nI think \"helpful\" and \"XML file\" should not be used in the same\nsentence.\n\nThat said, I\'m not sure such a thing would really be possible. So many\nschema changes happen from one release to another, never mind changes in\ncapabilities for underlying technologies like libvirt, OVS, etc...\n\nBest,\n-jay\n\n\n\n','<52E016A9.1070900@yahoo.it>',NULL),('<1390421200-sup-6700@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 12:12:36',-28800,'2014-01-22 20:12:36',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Jay Pipes\'s message of 2014-01-22 10:53:14 -0800:\n> On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:\n> > \n> > ----- Original Message -----\n> > > From: \"Clint Byrum\" <clint at fewbar.com>\n> > > To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> > > Sent: Wednesday, January 22, 2014 12:45:45 PM\n> > > Subject: Re: [openstack-dev] [TripleO] our update story: can people live    with it?\n> > > \n> > > Given the scenario above, that would be a further optimization. I don\'t\n> > > think it makes sense to specialize for venvs or openstack services\n> > > though, so just \"ensure the root filesystems match\" seems like a\n> > > workable, highly efficient system. Note that we\'ve talked about having\n> > > highly efficient ways to widely distribute the new images as well.\n> > \n> > Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> > \n> > 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> > \n> > 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> > \n> > 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n> \n> ++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD\n> environments, so this level of optimization will be frequently used.\n> And, as I\'ve said before, optimizing for frequently-used scenarios is\n> worth spending the time on. Optimizing for infrequently-occurring\n> things... not so much. :)\n\nI do understand that little tweaks are more common than whole software\nupdates.\n\nI also think that little tweaks must be tested just like big ones.\n\nSo I would argue that it is more important to optimize for trusting that\nwhat you tested is what is in production, and then to address any issues\nif that work-flow needs optimization. A system that leaves operators\nafraid to do a big update because \"it will trigger the bad path\" is a\nsystem that doesn\'t handle big updates well.\n\nIdeally we\'d optimize all 3 in all of the obvious ways before determining\nthat the \"one file\" update just isn\'t fast enough.\n\n\n','<1390416794.2144.46.camel@cranky>',NULL),('<1390421974.2144.56.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 15:19:34',-18000,'2014-01-22 20:19:34',NULL,'[openstack-dev] [qa][Neutron][Tempest][Network] Break down\n NetworkBasicOps to smaller test cases','On Tue, 2014-01-21 at 01:15 -0500, Yair Fried wrote:\n> I seem to be unable to convey my point using generalization, so I will give a specific example:\n> I would like to have \"update dns server\" as an additional network scenario. Currently I could add it to the existing module:\n> \n> 1. tests connectivity\n> 2. re-associate floating ip\n> 3. update dns server\n> \n> In which case, failure to re-associate ip will prevent my test from running, even though these are completely unrelated scenarios, and (IMO) we would like to get feedback on both of them.\n> \n> Another way, is to copy the entire network_basic_ops module, remove \"re-associate floating ip\" and add \"update dns server\". For the obvious reasons - this also seems like the wrong way to go.\n> \n> I am looking for an elegant way to share the code of these scenarios.\n\nWell, unfortunately, there are no very elegant answers at this time :)\n\nThe closest thing we have would be to create a fixtures.Fixture that\nconstructed a VM and associated the floating IP address to the instance.\nYou could then have separate tests that for checking connectivity and\nupdating the DNS server for that instance. However, fixtures are for\nresources that are shared between test methods and are not modified\nduring those test methods. They cannot be modified, because then\nparallel execution of the test methods may yield non-deterministic\nresults.\n\nThere would need to be a separate fixture for the instance that would\nhave the floating IP re-associated with it (because re-associating the\nfloating IP by nature is a modification to the resource).\n\nHaving a separate fixture means essentially doubling the amount of\nresources used by the test case class in question, which is why we\'re\npushing to just have all of the tests done serially in a single test\nmethod, even though that means that a failure to re-associate the\nfloating IP would mean that the update DNS server test would not be\nexecuted.\n\nChoose your poison.\n\nBest,\n-jay\n\n\n\n\n\n','<24842943.515.1390284935102.JavaMail.yfried@yfried-mobl-rh>',NULL),('<1390422571-sup-1084@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 12:36:18',-28800,'2014-01-22 20:36:18',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Fox, Kevin M\'s message of 2014-01-22 12:19:56 -0800:\n> I think most of the time taken to reboot is spent in bringing down/up the services though, so I\'m not sure what it really buys you if you do it all. It may let you skip the crazy long bootup time on \"enterprise\" hardware, but that could be worked around with kexec on the full reboot method too.\n> \n\nIf we could get kexec reliable.. but I have no evidence that it is\nanything but a complete flake.\n\nWhat it saves you is losing running processes that you don\'t end up\nkilling, which is expensive on many types of services.. Nova Compute\nbeing a notable example.\n\n\n','<1A3C52DFCD06494D8528644858247BF00D4B24@EX10MBOX03.pnnl.gov>',NULL),('<1390423095-sup-1501@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 12:54:53',-28800,'2014-01-22 20:54:53',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Keith Basil\'s message of 2014-01-22 12:27:50 -0800:\n> On Jan 22, 2014, at 1:53 PM, Jay Pipes wrote:\n> \n> > On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:\n> >> \n> >> ----- Original Message -----\n> >>> From: \"Clint Byrum\" <clint at fewbar.com>\n> >>> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> >>> Sent: Wednesday, January 22, 2014 12:45:45 PM\n> >>> Subject: Re: [openstack-dev] [TripleO] our update story: can people live    with it?\n> >>> \n> >>> Excerpts from Dan Prince\'s message of 2014-01-22 09:17:24 -0800:\n> >>>> I\'ve been thinking a bit more about how TripleO updates are developing\n> >>>> specifically with regards to compute nodes. What is commonly called the\n> >>>> \"update story\" I think.\n> >>>> \n> >>>> As I understand it we expect people to actually have to reboot a compute\n> >>>> node in the cluster in order to deploy an update. This really worries me\n> >>>> because it seems like way overkill for such a simple operation. Lets say\n> >>>> all I need to deploy is a simple change to Nova\'s libvirt driver. And\n> >>>> I need to deploy it to *all* my compute instances. Do we really expect\n> >>>> people to actually have to reboot every single compute node in their\n> >>>> cluster for such a thing. And then do this again and again for each\n> >>>> update they deploy?\n> >>>> \n> >>> \n> >>> Agreed, if we make everybody reboot to push out a patch to libvirt, we\n> >>> have failed. And thus far, we are failing to do that, but with good\n> >>> reason.\n> >>> \n> >>> Right at this very moment, we are leaning on \'rebuild\' in Nova, which\n> >>> reboots the instance. But this is so that we handle the hardest thing\n> >>> well first (rebooting to have a new kernel).\n> >>> \n> >>> For small updates we need to decouple things a bit more. There is a\n> >>> notion of the image ID in Nova, versus the image ID that is actually\n> >>> running. Right now we update it with a nova rebuild command only.\n> >>> \n> >>> But ideally we would give operators a tool to optimize and avoid the\n> >>> reboot when it is appropriate. The heuristic should be as simple as\n> >>> comparing kernels.\n> >> \n> >> When we get to implementing such a thing I might prefer it not to be auto-magic. I can see a case where I want the new image but maybe not the new kernel. Perhaps this should be addressed when building the image (by using the older kernel)... but still. I could see a case for explicitly not wanting to reboot here as well.\n> > \n> > ++\n> > \n> >>> Once we have determined that a new image does not\n> >>> need a reboot, we can just change the ID in Metadata, and an\n> >>> os-refresh-config script will do something like this:\n> >>> \n> >>> if [ \"$(cat /etc/image_id)\" != \"$(os-apply-config --key image_id)\" ] ;\n> >>> then;\n> >>>    download_new_image\n> >>>    mount_image /tmp/new_image\n> >>>    mount / -o remount,rw # Assuming we\'ve achieved ro root\n> >>>    rsync --one-file-system -a /tmp/new_image/ /\n> >>>    mount / -o remount,ro # ditto\n> >>> fi\n> >>> \n> >>> No reboot required. This would run early in configure.d, so that any\n> >>> pre-configure.d scripts will have run to quiesce services that can\'t\n> >>> handle having their binaries removed out from under them (read:\n> >>> non-Unix services). Then configure.d runs as usual, configures things,\n> >>> restarts services, and we are now running the new image.\n> >> \n> >> Cool. I like this a good bit better as it avoids the reboot. Still, this is a rather large amount of data to copy around if I\'m only changing a single file in Nova.\n> > \n> > Right.\n> > \n> >>> \n> >>>> I understand the whole read only images thing plays into this too... but\n> >>>> I\'m wondering if there is a middle ground where things might work\n> >>>> better. Perhaps we have a mechanism where we can tar up individual venvs\n> >>>> from /opt/stack/ or perhaps also this is an area where real OpenStack\n> >>>> packages could shine. It seems like we could certainly come up with some\n> >>>> simple mechanisms to deploy these sorts of changes with Heat such that\n> >>>> compute host reboot can be avoided for each new deploy.\n> >>> \n> >>> Given the scenario above, that would be a further optimization. I don\'t\n> >>> think it makes sense to specialize for venvs or openstack services\n> >>> though, so just \"ensure the root filesystems match\" seems like a\n> >>> workable, highly efficient system. Note that we\'ve talked about having\n> >>> highly efficient ways to widely distribute the new images as well.\n> >> \n> >> Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> >> \n> >> 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> >> \n> >> 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> >> \n> >> 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n> > \n> > ++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD\n> > environments, so this level of optimization will be frequently used.\n> > And, as I\'ve said before, optimizing for frequently-used scenarios is\n> > worth spending the time on. Optimizing for infrequently-occurring\n> > things... not so much. :)\n> \n> I don\'t understand the aversion to using existing, well-known tools to handle this?\n> \n\nThese tools are of course available to users and nobody is stopping them\nfrom using them. We are optimizing for not needing them. They are there\nand we\'re not going to explode if you use them. You just lose one aspect\nof what we\'re aiming at. I believe that having image based deploys will\nbe well received as long as it is simple to understand.\n\n> A hybrid model (blending 2 and 3, above) here I think would work best where\n> TripleO lays down a baseline image and the cloud operator would employ an well-known\n> and support configuration tool for any small diffs. \n>\n\nThese tools are popular because they control entropy and make it at\nleast more likely that what you tested ends up on the boxes.\n\nA read-only root partition is a much stronger control on entropy.\n\n> The operator would then be empowered to make the call for any major upgrades that\n> would adversely impact the infrastructure (and ultimately the users/apps).  He/She\n> could say, this is a major release, let\'s deploy the image.\n> \n> Something logically like this, seems reasonable:\n> \n>     if (system_change > 10%) {\n>       use TripleO;\n>       } else {\n>       use Existing_Config_Management;\n>     } \n> \n\nI think we can make deploying minor updates minimally invasive.\n\nWe\'ve kept it simple enough, this should be a fairly straight forward\noptimization cycle. And the win there is that we also improve things\nfor the 11% change.\n\n> It seems disruptive to force compute (or other) nodes to reboot on trivial updates.\n> \n\nNot sure if I did a really poor job of explaining this earlier or if\nyou missed the message. Reboots (eventually) will only be required on\nkernel updates.  We are focusing on the most painful thing first, and\nthen the non-kernel updates will just be an easier subset.\n\n> If we are to get further enterprise adoption of OpenStack, this seems like a huge\n> blocker.  This will be a very hard sell to get traditional IT folk to buy into\n> this approach:\n> \n>     \"Wait, *every* time I have to make a system change, I need to reboot my\n>      entire cloud?\"\n> \n> Elastic cloud concepts are already trying enough for the enterprise. \n> \n\nWe of course need to make sure we\'re not blowing up every IT department\nthat looks to adopt TripleO. My corporate overlords at HP tell me we have\nsome big, hard to convince customers that some might call \"enterprise\". :)\n\nThe selling point is that we can make assurances about the nodes that\npackage managers and config management tools will have to work much\nharder to make.\n\n\n','<E7023A7B-23B4-42FB-8F6A-6F7D92F96787@redhat.com>',NULL),('<1390423792.2144.60.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 15:49:52',-18000,'2014-01-22 20:49:52',NULL,'[openstack-dev] [TripleO] our update story: can people live\n with it?','On Wed, 2014-01-22 at 12:12 -0800, Clint Byrum wrote:\n> Excerpts from Jay Pipes\'s message of 2014-01-22 10:53:14 -0800:\n> > On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote:\n> > > \n> > > ----- Original Message -----\n> > > > From: \"Clint Byrum\" <clint at fewbar.com>\n> > > > To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> > > > Sent: Wednesday, January 22, 2014 12:45:45 PM\n> > > > Subject: Re: [openstack-dev] [TripleO] our update story: can people live    with it?\n> > > > \n> > > > Given the scenario above, that would be a further optimization. I don\'t\n> > > > think it makes sense to specialize for venvs or openstack services\n> > > > though, so just \"ensure the root filesystems match\" seems like a\n> > > > workable, highly efficient system. Note that we\'ve talked about having\n> > > > highly efficient ways to widely distribute the new images as well.\n> > > \n> > > Yes. Optimization! In the big scheme of things I could see 3 approaches being useful:\n> > > \n> > > 1) Deploy a full image and reboot if you have a kernel update. (entire image is copied)\n> > > \n> > > 2) Deploy a full image if you change a bunch of things and/or you prefer to do that. (entire image is copied)\n> > > \n> > > 3) Deploy specific application level updates via packages or tarballs. (only selected applications/packages get deployed)\n> > \n> > ++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD\n> > environments, so this level of optimization will be frequently used.\n> > And, as I\'ve said before, optimizing for frequently-used scenarios is\n> > worth spending the time on. Optimizing for infrequently-occurring\n> > things... not so much. :)\n> \n> I do understand that little tweaks are more common than whole software\n> updates.\n> \n> I also think that little tweaks must be tested just like big ones.\n> \n> So I would argue that it is more important to optimize for trusting that\n> what you tested is what is in production, and then to address any issues\n> if that work-flow needs optimization. A system that leaves operators\n> afraid to do a big update because \"it will trigger the bad path\" is a\n> system that doesn\'t handle big updates well.\n> \n> Ideally we\'d optimize all 3 in all of the obvious ways before determining\n> that the \"one file\" update just isn\'t fast enough.\n\nWell said. No disagreement from me.\n\nBest,\n-jay\n\n\n\n','<1390421200-sup-6700@fewbar.com>',NULL),('<1390427021.19257.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 16:43:41',-18000,'2014-01-22 21:43:41',NULL,'[openstack-dev] Changes coming in gate structure','On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:\n> <snip>\n> ==========================\n> Executive Summary\n> ==========================\n> To summarize, the effects of these changes will be:\n> \n>  - 1) Decrease the impact of failures resetting the entire gate queue\n>    by doing the heavy testing in the check queue where changes are not\n>    dependent on each other.\n> \n>  - 2) Run a slimmer set of jobs in the gate queue to maintain sanity,\n>    but not block as much on existing bugs in OpenStack.\n> \n>  - 3) As a result, this should increase our confidence that changes\n>    put into the gate will pass. This will help prevent gate resets,\n>    and the disruption they cause by needing to invalidate and restart\n>    the whole gate queue.\n\nAll good things, Sean ++.\n\nMight I also suggest one other thing that, IMO, would reduce gate\ncontention?\n\nWhat if we added an option to git review that would inject something\ninto the git commit message that would indicate the patch author felt\nthe patch does not need to have integration testing run against it.\n\nLots of patches make no substantive code changes and just clean up\nstyle, comments, or documentation. Having integration tests run for\nthese patches is just noise and provides no value. There should be a way\nto indicate to Zuul not to run integration testing if some marker is in\nthe commit message.\n\nFor example, let us imagine that issuing:\n\ngit review --skip-integration-tests\n\nwould cause a git commit hook to execute that injected this marker into\nthe commit message:\n\nSkip-Integration-Tests\n\nin the same way that the Change-Id commit hook injects the \n\nChange-Id: Ixxxxx\n\nline into the commit message.\n\nA -core reviewer would see Skip-Integration-Tests in the commit message.\nIf the -core reviewer disagreed with the patch author that the patch did\nnot have substantive code changes and actually wanted integration tests\nto be run for the patch, they could simply ask the patch author to run a\ngit commit --amend and remove the Skip-Integration-Tests line from the\ncommit message.\n\nIf a -core reviewer did a +1A on a patch that had a\nSkip-Integration-Test marker in the commit message, Zuul would simply\nnot execute the integration tests and would only execute things like\nrebase/merge conflict checks, and if all those basic tests succeeded,\nmerge the patch into the target branch.\n\nThis should significantly reduce the gate contention IMO, and should not\nbe difficult at all to implement.\n\nBest,\n-jay\n\n\n\n','<52E02C9E.501@dague.net>',NULL),('<1390430192-sup-2457@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 14:52:23',-28800,'2014-01-22 22:52:23',NULL,'[openstack-dev] Changes coming in gate structure','Excerpts from Jay Pipes\'s message of 2014-01-22 13:43:41 -0800:\n> On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:\n> > <snip>\n> > ==========================\n> > Executive Summary\n> > ==========================\n> > To summarize, the effects of these changes will be:\n> > \n> >  - 1) Decrease the impact of failures resetting the entire gate queue\n> >    by doing the heavy testing in the check queue where changes are not\n> >    dependent on each other.\n> > \n> >  - 2) Run a slimmer set of jobs in the gate queue to maintain sanity,\n> >    but not block as much on existing bugs in OpenStack.\n> > \n> >  - 3) As a result, this should increase our confidence that changes\n> >    put into the gate will pass. This will help prevent gate resets,\n> >    and the disruption they cause by needing to invalidate and restart\n> >    the whole gate queue.\n> \n> All good things, Sean ++.\n> \n> Might I also suggest one other thing that, IMO, would reduce gate\n> contention?\n> \n> What if we added an option to git review that would inject something\n> into the git commit message that would indicate the patch author felt\n> the patch does not need to have integration testing run against it.\n> \n> Lots of patches make no substantive code changes and just clean up\n> style, comments, or documentation. Having integration tests run for\n> these patches is just noise and provides no value. There should be a way\n> to indicate to Zuul not to run integration testing if some marker is in\n> the commit message.\n> \n\nI love the idea here, that there are changes that are not in fact\nchanging behavior.\n\nHowever, I am wary of asking reviewers to add another item to the review\nchecklist. Because not only do they then need to check to see if it is\nbeing used improperly, but that it is not being used properly. This is\na \"humans: be better\" change. So if it were to be done, the humans would\nneed some tools.\n\nWe could, however, do something fairly interesting with the automation\nwe do have. We could probably use some software analysis tools to make\na reasonable recommendation. We can use a tool such as radon to measure\nwhether the change actually changes McCabe complexity, or Halstead volume,\nand thus is a good candidate for the trivial change flag.\n\nAnyway, I like the optimization as long as it doesn\'t just shift more\nload onto core reviewers.\n\n\n','<1390427021.19257.9.camel@cranky>',NULL),('<1390440249.23323.1.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 20:24:09',-18000,'2014-01-23 01:24:09',NULL,'[openstack-dev] Changes coming in gate structure','On Wed, 2014-01-22 at 17:59 -0500, Sean Dague wrote:\n> On 01/22/2014 05:52 PM, Clint Byrum wrote:\n> > Excerpts from Jay Pipes\'s message of 2014-01-22 13:43:41 -0800:\n> >> On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:\n> >>> <snip>\n> >>> ==========================\n> >>> Executive Summary\n> >>> ==========================\n> >>> To summarize, the effects of these changes will be:\n> >>>\n> >>>  - 1) Decrease the impact of failures resetting the entire gate queue\n> >>>    by doing the heavy testing in the check queue where changes are not\n> >>>    dependent on each other.\n> >>>\n> >>>  - 2) Run a slimmer set of jobs in the gate queue to maintain sanity,\n> >>>    but not block as much on existing bugs in OpenStack.\n> >>>\n> >>>  - 3) As a result, this should increase our confidence that changes\n> >>>    put into the gate will pass. This will help prevent gate resets,\n> >>>    and the disruption they cause by needing to invalidate and restart\n> >>>    the whole gate queue.\n> >>\n> >> All good things, Sean ++.\n> >>\n> >> Might I also suggest one other thing that, IMO, would reduce gate\n> >> contention?\n> >>\n> >> What if we added an option to git review that would inject something\n> >> into the git commit message that would indicate the patch author felt\n> >> the patch does not need to have integration testing run against it.\n> >>\n> >> Lots of patches make no substantive code changes and just clean up\n> >> style, comments, or documentation. Having integration tests run for\n> >> these patches is just noise and provides no value. There should be a way\n> >> to indicate to Zuul not to run integration testing if some marker is in\n> >> the commit message.\n> >>\n> > \n> > I love the idea here, that there are changes that are not in fact\n> > changing behavior.\n> > \n> > However, I am wary of asking reviewers to add another item to the review\n> > checklist. Because not only do they then need to check to see if it is\n> > being used improperly, but that it is not being used properly. This is\n> > a \"humans: be better\" change. So if it were to be done, the humans would\n> > need some tools.\n> > \n> > We could, however, do something fairly interesting with the automation\n> > we do have. We could probably use some software analysis tools to make\n> > a reasonable recommendation. We can use a tool such as radon to measure\n> > whether the change actually changes McCabe complexity, or Halstead volume,\n> > and thus is a good candidate for the trivial change flag.\n> > \n> > Anyway, I like the optimization as long as it doesn\'t just shift more\n> > load onto core reviewers.\n> \n> I think that if you want to head down this road, the point shouldn\'t be\n> to make trivial changes skip the tests. It should be to put trivial\n> changes into a holding pen, and squash them down and bulk process them\n> in one go. Then they still get tested, but at much less cost.\n\nBoth good points.\n\n-jay\n\n\n\n','<52E04D5F.9010406@dague.net>',NULL),('<1390454991-sup-3439@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-22 21:32:32',-28800,'2014-01-23 05:32:32',NULL,'[Openstack] Export tenant configuration','Excerpts from Salvo Rapisarda\'s message of 2014-01-22 11:06:17 -0800:\n> Il 22/01/2014 18.18, Jay Pipes ha scritto:\n> > On Wed, 2014-01-22 at 17:21 +0100, Salvo Rapisarda wrote:\n> >> But you surely know that MySQL is not the only SQL back-end for\n> >> OpenStack services. ;-)\n> >\n> > I don\'t see any mention of MySQL below by Nick Ma.\n> \n> Sorry, you are right.\n> MySQL is my OpenStack sql backend. :)\n> \n> >> This is why I was looking for an alternative solution for export/import\n> >> the structure of my project.\n> >\n> > What do you mean by \"structure of my project\"? The data for the various\n> > resources consumed by your project is stored in a number of databases.\n> > Additionally, with data about the project itself is stored in the\n> > Keystone back-end storage (either RDBMS, KVS or LDAP).\n> >\n> > If you want to port the network configuration from Grizzly to Havana, UI\n> > would just make a snapshot of your Quantum database in Grizzly and start\n> > your Havana database from that snapshot, and run the db schema\n> > migrations on it.\n> >\n> > Best,\n> > -jay\n> >\n> I know, but I think can be helpful to use a tool for generate, for \n> example, an XML file of my Project that is compatible with the all \n> releases of OpenStack.\n\nIf you use Heat to manage your resources you already have this. Just\ndeploy your stack again.\n\nThere is work landing now which will allow Heat to adopt existing\nresources. So that would be a good format to use as the serialization\nof all the things in your cloud. Then you just need a tool that lists\nout everything and saves in the format. That would be quite useful to\nhelp drive Heat adoption I think. :)\n\n\n','<52E016A9.1070900@yahoo.it>',NULL),('<1390495084.8188.17.camel@lappy>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-24 02:38:04',36000,'2014-01-23 16:38:04',NULL,'[Openstack] [OSSA 2014-003] Live migration can leak root disk into\n ephemeral storage (CVE-2013-7130)','OpenStack Security Advisory: 2014-003\nCVE: CVE-2013-7130\nDate: January 23, 2014\n\nTitle: Live migration can leak root disk into ephemeral storage\nReporter: Loganathan Parthipan (HP)\nProducts: Nova\nAffects: All supported versions\n\nDescription:\nLoganathan Parthipan from Hewlett Packard reported a vulnerability in\nthe Nova libvirt driver. By spawning a server with the same flavor as\nanother user\'s migrated virtual machine, an authenticated user can\npotentially access that user\'s snapshot content resulting in information\nleakage. Only setups using KVM live block migration are affected.\n\n\nIcehouse (development branch) fix:\nhttps://review.openstack.org/#/c/68658/\n\nHavana (development branch) fix:\nhttps://review.openstack.org/#/c/68659/\n\nGrizzly fix:\nhttps://review.openstack.org/#/c/68660/\n\n\nReferences:\nhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7130\nhttps://bugs.launchpad.net/nova/+bug/1251590\n\n-- \nGrant Murphy\nOpenStack Vulnerability Management Team\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 230 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140124/1e424a3e/attachment.pgp>\n\n',NULL,NULL),('<1390495084.8188.17.camel@lappy>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2014-01-24 02:38:04',36000,'2014-01-23 16:38:04',NULL,'[openstack-announce] [OSSA 2014-003] Live migration can leak root\n disk into ephemeral storage (CVE-2013-7130)','OpenStack Security Advisory: 2014-003\nCVE: CVE-2013-7130\nDate: January 23, 2014\n\nTitle: Live migration can leak root disk into ephemeral storage\nReporter: Loganathan Parthipan (HP)\nProducts: Nova\nAffects: All supported versions\n\nDescription:\nLoganathan Parthipan from Hewlett Packard reported a vulnerability in\nthe Nova libvirt driver. By spawning a server with the same flavor as\nanother user\'s migrated virtual machine, an authenticated user can\npotentially access that user\'s snapshot content resulting in information\nleakage. Only setups using KVM live block migration are affected.\n\n\nIcehouse (development branch) fix:\nhttps://review.openstack.org/#/c/68658/\n\nHavana (development branch) fix:\nhttps://review.openstack.org/#/c/68659/\n\nGrizzly fix:\nhttps://review.openstack.org/#/c/68660/\n\n\nReferences:\nhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7130\nhttps://bugs.launchpad.net/nova/+bug/1251590\n\n-- \nGrant Murphy\nOpenStack Vulnerability Management Team\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 230 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20140124/1e424a3e/attachment.pgp>\n\n',NULL,NULL),('<1390498486.23323.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 12:34:46',-18000,'2014-01-23 17:34:46',NULL,'[openstack-dev] Next steps for Whole Host allocation / Pclouds','On Thu, 2014-01-23 at 17:05 +0000, Day, Phil wrote:\n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 22 January 2014 02:01\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] Next steps for Whole Host allocation / Pclouds\n> > \n> > On Tue, 2014-01-21 at 14:21 +0000, Khanh-Toan Tran wrote:\n> > > > Exactly - that\'s why I wanted to start this debate about the way\n> > > > forward for the Pcloud Blueprint, which was heading into some kind\n> > > > of middle ground.  As per my original post, and it sounds like the\n> > > > three of us are at least aligned I\'m proposing to spilt this into\n> > > > two streams:\n> > > >\n> > > > i) A new BP that introduces the equivalent of AWS dedicated instances.\n> > >\n> > > Why do you want to transform pCloud into AWS dedicated instances? As I\n> > > see it, pCloud is for requesting physical hosts (HostFlovors as in\n> > > pcloud wiki) on which users can create their own instances\n> > > (theoretically in unlimited number).\n> > > Therefore it should be charged per physical server (HostFlavor), not\n> > > by instances. It is completely different from AWS dedicated instances\n> > > which is charged per instance. IMO, pcloud resembles Godrid Dedicated\n> > > Server, not AWS Dedicated Instance.\n> > \n> > It resembles managed/dedicated hosting. Not cloud.\n> > \n> \n> I think there is a cross-over point here somewhere - call it \"managed cloud\" where the user doesn\'t want to run a cloud but does want (and is willing to pay for) some guarantee of isolation of hypervisors, but also wants to share other aspects of the cloud (images, volumes, VPC networks).\n\nThe above is perfectly fine. It is the \"isolated instance use case\".\nThat is still cloud, IMO. It\'s still using shared resources owned and\ncontrolled by the operator (just sharing is limited to a certain subset\nof tenants). It\'s also still entirely on-demand and fits into the normal\nflow of actions that any other request for resources uses.\n\n>  They get a degree of controlled Admin (can set up their own flavors for example) - but they are still only doing configuration type tasks, not operating the system as such - and probably most significantly they can build systems that are a combination of instances running on shared and dedicated servers.    That\'s kind of where pCLouds was evolving to - and  I think you can build such a beast more effectively by running multiple dedicated Nova\'s configured to take to a shared Glance/Cinder/Neutron. I.e this belongs on-Nova, not in-Nova\n\nAnd here is where I lose you :) \n\nThe above isn\'t really cloud, IMO. It is describing managed dedicated\nhosting, including all of the legacy high-touch, \"enterprise\nIT\"-centric, high-cost, \"let me do that backup for you\" business and\nsales model.\n\nI understand there are lots of sales and product organizations\nclamouring for such things... because it allows those organizations to\nbe lazy and rely on the same sales practices and marketing techniques\nthat have allowed them to trap IT organizations into a single-provider\nmodel for years.\n\nI\'m just not all that interested in furthering those use cases ;)\n\nAnd yes, I realize I sound like a spoiled, opinionated hipster coder\nsitting in a San Francisco coffee shop pontificating about a utopia free\nof enterprise IT providers.\n\n/me dons skinny jeans and a grows a late 19th-century moustache.\n\nBest,\n-jay\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F8EB50@G6W2490.americas.hpqcorp.net>',NULL),('<1390499453.23323.17.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 12:50:53',-18000,'2014-01-23 17:50:53',NULL,'[openstack-dev] [oslo][db] Mysql traditional session mode','On Thu, 2014-01-23 at 11:29 -0600, Ben Nemec wrote:\n> A while back a change (https://review.openstack.org/#/c/47820/) was made \n> to allow enabling mysql traditional mode, which tightens up mysql\'s \n> input checking to disallow things like silent truncation of strings that \n> exceed the column\'s allowed length and invalid dates (as I understand \n> it).\n> \n> IMHO, some compelling arguments were made that we should always be using \n> traditional mode and as such we started logging a warning if it was not \n> enabled.  It has recently come to my attention \n> (https://review.openstack.org/#/c/68474/) that not everyone agrees, so I \n> wanted to bring it to the list to get as wide an audience for the \n> discussion as possible and hopefully come to a consensus so we don\'t end \n> up having this discussion every few months.\n> \n> I remain of the opinion that traditional mode is a good thing and we \n> _should_ be enabling it.  I would call silent truncation and bogus date \n> values bugs that should be fixed, but maybe there are other implications \n> of this mode that I\'m not aware of.\n\nWhy traditional? Why not STRICT_ALL_TABLES?\n\n> It was also pointed out that the warning is logged even if the user \n> forces traditional mode through my.cnf.  While this certainly solves the \n> underlying problem, it doesn\'t change the fact that the application was \n> trying to do something bad.  We tried to make it clear in the log \n> message that this is a developer problem and the user needs to pester \n> the developer to enable the mode, but maybe there\'s more discussion that \n> needs to go on there as well.\n\nWhat I was trying to point out with that is that if I see a warning in a\nlog file about not enabling traditional mode, and yet I\'ve set my my.cnf\nserver sql_mode to STRICT_TRANS_TABLES, TRADITIONAL, or\nSTRICT_ALL_TABLES, then I shouldn\'t see a warning in the code...\n\nIt\'s easy enough to check... SHOW [GLOBAL] VARIABLES LIKE \'sql_mode\'...\n\nBest,\n-jay\n\n> Any thoughts on this would be welcomed.  Thanks.\n> \n> -Ben\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<d1fb09bdcba5b207f8422d9c180f8d2c@localhost>',NULL),('<1390501744-sup-4091@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 11:20:06',-28800,'2014-01-23 19:20:06',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Angus Thomas\'s message of 2014-01-23 04:57:20 -0800:\n> On 22/01/14 20:54, Clint Byrum wrote:\n> >> >\n> >> >I don\'t understand the aversion to using existing, well-known tools to handle this?\n> >> >\n> > These tools are of course available to users and nobody is stopping them\n> > from using them. We are optimizing for not needing them. They are there\n> > and we\'re not going to explode if you use them. You just lose one aspect\n> > of what we\'re aiming at. I believe that having image based deploys will\n> > be well received as long as it is simple to understand.\n> >\n> >> >A hybrid model (blending 2 and 3, above) here I think would work best where\n> >> >TripleO lays down a baseline image and the cloud operator would employ an well-known\n> >> >and support configuration tool for any small diffs.\n> >> >\n> > These tools are popular because they control entropy and make it at\n> > least more likely that what you tested ends up on the boxes.\n> >\n> > A read-only root partition is a much stronger control on entropy.\n> >\n> >> >The operator would then be empowered to make the call for any major upgrades that\n> >> >would adversely impact the infrastructure (and ultimately the users/apps).  He/She\n> >> >could say, this is a major release, let\'s deploy the image.\n> >> >\n> >> >Something logically like this, seems reasonable:\n> >> >\n> >> >     if (system_change > 10%) {\n> >> >       use TripleO;\n> >> >       } else {\n> >> >       use Existing_Config_Management;\n> >> >     }\n> >> >\n> > I think we can make deploying minor updates minimally invasive.\n> >\n> > We\'ve kept it simple enough, this should be a fairly straight forward\n> > optimization cycle. And the win there is that we also improve things\n> > for the 11% change.\n> >\n> \n> Hi Clint,\n> \n> For deploying minimally-invasive minor updates, the idea, if I\'ve \n> understood it correctly, would be to deploy a tarball which replaced \n> selected files on the (usually read-only) root filesystem. That would \n> allow for selective restarting of only the services which are directly \n> affected. The alternative, pushing out a complete root filesystem image, \n> would necessitate the same amount of disruption in all cases.\n> \n\nFTR, I have not said that chopping updates into things like tars of only\nthe difference between old and new image is a bad idea. Its a great idea\nto avoid transfer costs. It just doesn\'t solve the system state problem,\nnor do package updates.\n\nHow exactly would we determine which running things have imported\n/usr/lib/python2.7/wsgiref/__init__.py ? Assuming we have packages only,\nare we going to walk through its reverse dependencies and find any init\nscripts/systemd unit files, and restart them? Do we just pray there\nare no transitive dependencies or do we get really broad and do a first\nlevel deep just to be sure? This is fine, but it is complexity, and for\nwhat gain? If we make it not disruptive to restart any given service,\nwe don\'t have to be complex, and we can spend our energy on other\nthings.\n\nI don\'t think a tarball or packages make it any easier to know that we\nhave deployed the software and ensured there are no stale copies of code\nor configuration running. Any optimizations that can be done will need\nto be able to resolve system state with the whole software collection or\nwill have to carry the risk of stale software continuing to run.\n\nI\'m suggesting we focus our efforts on straight forward, easy to\nunderstand things: HA and tests.  Those things will have a much greater\nbenefit on the user than trying to disect diffs and figure out what\nthings to restart, IMO.\n\n> There are a handful of costs with that approach which concern me: It \n> simplifies the deployment itself, but increases the complexity of \n> preparing the deployment. The administrator is going to have to identify \n> the services which need to be restarted, based on the particular set of \n> libraries which are touched in their partial update, and put together \n> the service restart scripts accordingly.\n> \n\nThe cloud is for automation. Said administrator should be writing tests\nthat ensure they\'re running the software and configuration that they\nthink they are. We should also be writing tests for them and shipping\nsaid tests with each and every update, as that is something generally\nconsumable that will have a massive positive impact on trust in OpenStack.\n\n> We\'re also making the administrator responsible for managing the \n> sequence in which incremental updates are deployed. Since each \n> incremetal update will re-write a particular set of files, any machine \n> which gets updates 1,2, 3, there\'s an oversight, and then update 5 is \n> deployed would end up in an odd state, which would require additional \n> tooling to detect. Package based updates, with versioning and dependency \n> tracking on each package, mitigate that risk.\n> \n\nYes, a carefully constructed set of packages can know all of the\nversion combinations and they have asserted their dependencies so\npost configurations get run at the right times. I\'m well aware of what\nDebian and RPM packaging are capable of. I\'m also well aware that it\nis extremely hard to get right, and as the version matrix grows, and\npackage complexity grows, so do the bug list.\n\nI\'m arguing for extreme simplicity, followed by optimization where it\nis absolutely necessary. I see a lot of complexity in trying to optimize\nsystem state management.\n\n> Then there\'s the relationship between the state of running machines, \n> with applied partial updates, and the images which are put onto new \n> machines by Ironic. We would need to apply the partial updates to the \n> images which Ironic writes, or to have the tooling to ensure that newly \n> deployed machines immediately apply the set of applicable partial \n> updates, in sequence.\n> \n\nSo this seems to argue for what I am arguing for: Don\'t do partial\nupdates. Push out a new image and restart all the processes. If that\nfails, this isn\'t a partial update, it is a failed update and it gets\nrolled back. In the future we\'ll improve Heat a bit so we can do this in\na more graceful way but even as-is right now we can orchestrate this by\njust putting wait conditions between each node in the graph and having\nour testing system poke the wait conditions with success or fail.\n\n> Solving these issues feels like it\'ll require quite a lot of additional \n> tooling.\n> \n\nIndeed, Heat needs some work to make the rolling update work. And we\nneed to make TripleO deploy HA things so that we can update without\ndowntime. But we have to do those even if we don\'t do an incremental\nupdate story. And once we do those, getting all pedantic about each\nindividual service on each individual server is going to seem a lot less\nimportant.\n\n\n','<52E111B0.8040604@redhat.com>',NULL),('<1390514848.9398.0.camel@macnux.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 23:07:28',3600,'2014-01-23 22:07:28',NULL,'[openstack-dev] [Keystone] bp proposal: quotas on users and\n projects per domain','I understand that not everyone may be interested in such feature. \n\nOn the other hand, some (maybe shallow) Openstack users may be\ninterested in setting quotas on users or projects. Also, this feature\nwouldn\'t do any harm to the other users who wouldn\'t use it.\n\nIf some contributors are willing to spend some time in adding this\nfeature to Openstack, is there any reason not to accept it ?\n\nOn Thu, 2014-01-23 at 14:55 -0600, Dolph Mathews wrote:\n> \n> On Thu, Jan 23, 2014 at 9:59 AM, Florent Flament\n> <florent.flament-ext at cloudwatt.com> wrote:\n>         Hi,\n>         \n>         \n>         Although it is true that projects and users don\'t consume a\n>         lot of resources, I think that there may be cases where\n>         setting quotas (possibly large) may be useful.\n>         \n>         \n>         \n>         For instance, a cloud provider may wish to prevent domain\n>         administrators to mistakingly create an infinite number of\n>         users and/or projects, by calling APIs in a bugging loop.\n>         \n> \n> \n> That sounds like it would be better solved by API rate limiting, not\n> quotas.\n>  \n>         \n>         \n>         \n>         Moreover, if quotas can be disabled, I don\'t see any reason\n>         not to allow cloud operators to set quotas on users and/or\n>         projects if they wishes to do so for whatever marketing reason\n>         (e.g. charging more to allow more users or projects).\n>         \n> \n> \n> That\'s the shallow business decision I was alluding to, which I don\'t\n> think we have any reason to support in-tree.\n>  \n>         \n>         \n>         \n>         Regards,\n>         \n>         Florent Flament\n>         \n>         \n>         \n>         \n>         \n>         ______________________________________________________________\n>         From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n>         To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         Sent: Thursday, January 23, 2014 3:09:51 PM\n>         Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on\n>         users and projects per domain\n>         \n>         \n>         \n>         ... why? It strikes me as a rather shallow business decision\n>         to limit the number of users or projects in a system, as\n>         neither are actually cost-consuming resources.\n>         \n>         \n>         On Thu, Jan 23, 2014 at 6:43 AM, Matthieu Huin\n>         <matthieu.huin at enovance.com> wrote:\n>                 Hello,\n>                 \n>                 I\'d be interested in opinions and feedback on the\n>                 following blueprint:\n>                 https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas\n>                 \n>                 The idea is to add a mechanism preventing the creation\n>                 of users or projects once a quota per domain is met. I\n>                 believe this could be interesting for cloud providers\n>                 who delegate administrative rights under domains to\n>                 their customers.\n>                 \n>                 I\'d like to hear the community\'s thoughts on this,\n>                 especially in terms of viability.\n>                 \n>                 Many thanks,\n>                 \n>                 Matthieu Huin\n>                 \n>                 mhu at enovance.com\n>                 http://www.enovance.com\n>                 eNovance SaS - 10 rue de la Victoire 75009 Paris -\n>                 France\n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAC=h7gWH12x1s8oPsm4hF5DawnS6tD68NWvBW4sTpkr8CeYBXg@mail.gmail.com>',NULL),('<1390515986-sup-3332@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 14:31:09',-28800,'2014-01-23 22:31:09',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','If we\'re ready to head down the path of trying to isolate things and\nhave zero-downtime-on-one-box deploys, then CoreOS has basically solved\nthis with Docker.\n\nhttps://coreos.com/using-coreos/\n\nHowever, let\'s solve one thing at a time. Even with CoreOS, we still\nneed HA, and we still want to have rolling deploys that are driven by\ntests passing and monitoring.\n\nSo once we get those things, sure, lets grind our downtime windows down\nto next to nothing. :)\n\n(Also, really if we end up using Docker on top of TripleO, we\'d want to\nuse the OpenStack driver, and that would mean we\'re using OpenStack on\nOpenStack on OpenStack.. which is _QUINT-O_ ;)\n\nExcerpts from Fox, Kevin M\'s message of 2014-01-23 13:10:09 -0800:\n> Would docker work for this?\n> \n> Assume every service gets its own docker container. A deployed node is then a docker base image with a set of service containers. Updating an image could be:\n> Check if base part of image updated (kernel, docker). if so, full redeploy the node.\n> Sync each container image, restart container only if different?\n> \n> Maybe the same trick could be done with python virtualenvs instead...\n> \n> Kevin\n> ________________________________________\n> From: Chris Jones [cmsj at tenshu.net]\n> Sent: Thursday, January 23, 2014 7:17 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [TripleO] our update story: can people live        with it?\n> \n> Hi\n> \n> Not a tarball. The node would notice from Heat metadata that it should update to a new image and would fetch that image and sync the contents to its /. This would leave it bit for bit identical to a fresh deployment of the new image, at least on disk. The running state would differ and that still requires some design and implementation to figure out.\n> \n> Cheers,\n> --\n> Chris Jones\n> \n> > On 23 Jan 2014, at 12:57, Angus Thomas <athomas at redhat.com> wrote:\n> >\n> > On 22/01/14 20:54, Clint Byrum wrote:\n> >>> >\n> >>> >I don\'t understand the aversion to using existing, well-known tools to handle this?\n> >>> >\n> >> These tools are of course available to users and nobody is stopping them\n> >> from using them. We are optimizing for not needing them. They are there\n> >> and we\'re not going to explode if you use them. You just lose one aspect\n> >> of what we\'re aiming at. I believe that having image based deploys will\n> >> be well received as long as it is simple to understand.\n> >>\n> >>> >A hybrid model (blending 2 and 3, above) here I think would work best where\n> >>> >TripleO lays down a baseline image and the cloud operator would employ an well-known\n> >>> >and support configuration tool for any small diffs.\n> >>> >\n> >> These tools are popular because they control entropy and make it at\n> >> least more likely that what you tested ends up on the boxes.\n> >>\n> >> A read-only root partition is a much stronger control on entropy.\n> >>\n> >>> >The operator would then be empowered to make the call for any major upgrades that\n> >>> >would adversely impact the infrastructure (and ultimately the users/apps).  He/She\n> >>> >could say, this is a major release, let\'s deploy the image.\n> >>> >\n> >>> >Something logically like this, seems reasonable:\n> >>> >\n> >>> >     if (system_change > 10%) {\n> >>> >       use TripleO;\n> >>> >       } else {\n> >>> >       use Existing_Config_Management;\n> >>> >     }\n> >>> >\n> >> I think we can make deploying minor updates minimally invasive.\n> >>\n> >> We\'ve kept it simple enough, this should be a fairly straight forward\n> >> optimization cycle. And the win there is that we also improve things\n> >> for the 11% change.\n> >\n> > Hi Clint,\n> >\n> > For deploying minimally-invasive minor updates, the idea, if I\'ve understood it correctly, would be to deploy a tarball which replaced selected files on the (usually read-only) root filesystem. That would allow for selective restarting of only the services which are directly affected. The alternative, pushing out a complete root filesystem image, would necessitate the same amount of disruption in all cases.\n> >\n> > There are a handful of costs with that approach which concern me: It simplifies the deployment itself, but increases the complexity of preparing the deployment. The administrator is going to have to identify the services which need to be restarted, based on the particular set of libraries which are touched in their partial update, and put together the service restart scripts accordingly.\n> >\n> > We\'re also making the administrator responsible for managing the sequence in which incremental updates are deployed. Since each incremetal update will re-write a particular set of files, any machine which gets updates 1,2, 3, there\'s an oversight, and then update 5 is deployed would end up in an odd state, which would require additional tooling to detect. Package based updates, with versioning and dependency tracking on each package, mitigate that risk.\n> >\n> > Then there\'s the relationship between the state of running machines, with applied partial updates, and the images which are put onto new machines by Ironic. We would need to apply the partial updates to the images which Ironic writes, or to have the tooling to ensure that newly deployed machines immediately apply the set of applicable partial updates, in sequence.\n> >\n> > Solving these issues feels like it\'ll require quite a lot of additional tooling.\n> >\n> >\n> > Angus\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1A3C52DFCD06494D8528644858247BF00D8879@EX10MBOX03.pnnl.gov>',NULL),('<1390516316226.d40b4a74@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 14:31:56',-28800,'2014-01-23 22:31:56',NULL,'[openstack-dev] [Nova] Dropping XML support in the v3 compute\n API','On Fri, Jan 24, 2014 at 8:34 am, Russell Bryant <rbryant at redhat.com=\"mailto:rbryant at redhat.com\">> wrote:\nGreetings,\n\n\nRecently Sean Dague started some threads [1][2] about the future of XML\n\nsupport in Nova\'s compute API.  Specifically, he proposed [3] that we\n\ndrop XML support in the next major version of the API (v3).  I wanted to\n\nfollow up on this to make the outcome clear.\n\n\nI feel that we should move forward with this proposal and drop XML\n\nsupport from the v3 compute API.  The ongoing cost in terms of\n\ndevelopment, maintenance, documentation, and verification has been quite\n\nhigh.  After talking to a number of people about this, I do not feel\n\nthat keeping it provides enough value to justify the cost.?\n\n\n\n\n\n\n\n?+1\n\n\n?To clean the XML code out of the V3 API code (both Nova and Tempest) will involve a substantial number of patches though they will be pretty straightforward and easy to review. So to get this done in time it would be very helpful if some cores could commit to helping with the reviews.\n\n\n\nhttps://blueprints.launchpad.net/nova/+spec/remove-v3-xml-api\n\n\n\n\n\n\n\n?I\'m happy to do so, but since I\'ll probably be writing many of the patches we\'ll need others as well.\n\n?Chris\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/df280ca5/attachment.html>\n\n','<52E19092.9060100@redhat.com>',NULL),('<1390523074.23323.18.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-23 19:24:34',-18000,'2014-01-24 00:24:34',NULL,'[Openstack-operators] Keystone Grizzly to Havana upgrade','Hi Tim, sorry for top-posting, but I\'m curious whether you are using the\nv2 Keystone API or the v3 Keystone API (and whether you migrated API\nversions during your G -> H migration.\n\nBest,\n-jay\n\nOn Thu, 2014-01-23 at 21:09 +0000, Tim Bell wrote:\n>  \n> \n> Following on the sequence of quick notes for those doing Grizzly to\n> Havana upgrades.\n> \n>  \n> \n> At CERN, we?ve just migrated Keystone from Grizzly to Havana today. It\n> actually happened much faster than we had originally intended!\n> \n>  \n> \n> The overall approach taken was to try an online upgrade. We have a\n> keystone in each of our cells (so we can talk to each of them\n> independently of the top level cell API nodes) so these were good\n> candidates to upgrade first. We use Active Directory for the user\n> credentials so the Keystone service itself has a limited amount of\n> state only (related to EC2 credentials and token management).\n> \n>  \n> \n> For the main keystone instance, we were aiming to benefit from the\n> load balancing layer and that there were minimal database changes in\n> Keystone. The largest problem foreseen was the EC2 credentials since\n> these, in Grizzly, are stored in a different column to those in Havana\n> (just Credentials). These columns had to be kept in sync with a script\n> during the phase where both versions were running.\n> \n>  \n> \n> In practice, we performed the upgrade more rapidly than originally\n> planned as some of the clients gave errors when they had received a\n> token from a Grizzly keystone and were authenticating against a Havana\n> one. Thus, we upgraded all the keystone servers as soon as the final\n> functional tests in the production environment were completed on the\n> first keystone.\n> \n>  \n> \n> The detailed error message of the error on a Grizzly client was\n> \n>  \n> \n> 2014-01-23 09:10:02    ERROR [root] \'token\'\n> \n> Traceback (most recent call last):\n> \n>   File \"/usr/lib/python2.6/site-packages/keystone/common/wsgi.py\",\n> line 265, in __call__\n> \n>     result = method(context, **params)\n> \n>   File\n> \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line\n> 541, in validate_token\n> \n>     self._assert_default_domain(context, token_ref)\n> \n>   File\n> \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line\n> 482, in _assert_default_domain\n> \n>     if (token_ref[\'token_data\'][\'token\'][\'user\'][\'domain\'][\'id\'] !=\n> \n> KeyError: \'token\'\n> \n>  \n> \n> The solution was to complete the upgrade to Keystone on all the\n> servers.\n> \n>  \n> \n> Other than that, things are running fine and now we can start the work\n> to take advantage of the new features.\n> \n>  \n> \n> Tim\n> \n>  \n> \n> From: Tim Bell \n> Sent: 15 January 2014 20:23\n> To: openstack-operators at lists.openstack.org\n> Subject: Glance Grizzly to Havana upgrade\n> \n> \n>  \n> \n>  \n> \n> Quick warning to those doing the Grizzly to Havana migration,\n> \n>  \n> \n> Our upgrade went smoothly (around 45 minutes to complete).\n> \n>  \n> \n> Following the migration, we found that nova image-list and glance\n> image-list were showing different results.\n> \n>  \n> \n> The root cause was related to the bug\n> https://bugs.launchpad.net/glance/+bug/1152716. The fix for the\n> problem was to add the policy statement for the parameter\n> context_is_admin which is needed to limit access to private images for\n> projects.\n> \n>  \n> \n> Tim\n> \n>  \n> \n> --\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D996B21A@CERNXCHG02.cern.ch>',NULL),('<1390555348-sup-5334@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 01:26:54',-28800,'2014-01-24 09:26:54',NULL,'[openstack-dev] [Murano] Repositoris re-organization','Excerpts from Alexander Tivelkov\'s message of 2014-01-21 11:55:34 -0800:\n> Hi folks,\n> \n> As we are moving towards incubation application, I took a closer look at\n> what is going on with our repositories.\n> An here is what I found. We currently have 11 repositories at stackforge:\n> \n>    - murano-api\n>    - murano-conductor\n>    - murano-repository\n>    - murano-dashboard\n>    - murano-common\n>    - python-muranoclient\n>    - murano-metadataclient\n>    - murano-agent\n>    - murano-docs\n>    - murano-tests\n>    - murano-deployment\n> \n> This enourmous amount of repositories adds too much infrustructural\n> complexity, and maintaining the changes in in consistent and reliable\n> manner becomes a really tricky tasks. We often have changes which require\n> modifing two or more repositories - and thus we have to make several\n> changesets in gerrit, targeting different repositories. Quite often the\n> dependencies between these changesets are not obvious, the patches get\n> reviewed and approved on wrong order (yes, this also questions the quality\n> of the code review, but that is a different topic), which causes in\n> inconsostent state of the repositories.\n> \n\nSo, as somebody who does not run Murano, but who does care a lot about\ncontinuous delivery, I actually think keeping them separate is a great\nway to make sure you have ongoing API stability.\n\nSince all of those pieces can run on different machines, having the APIs\nable to handle both \"the old way\" and \"the new way\" is quite helpful in\na large scale roll out where you want to keep things running while you\nupdate.\n\nAnyway, that may not matter much, but it is one way to think about it.\n\n\n','<CAM6FM9TxXtzv7ba5So=X-M02+kjmHHLE3g5Lsesh3rRvL+-Cpg@mail.gmail.com>',NULL),('<1390555711-sup-5331@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 01:34:39',-28800,'2014-01-24 09:34:39',NULL,'[openstack-dev] [heat] question on proposed software config','Excerpts from Prasad Vellanki\'s message of 2014-01-24 00:21:06 -0800:\n> I have a question on agent as part of cfninit that communicates with heat\n> about config done state indication or config tool agent such as chef or\n> puppet communicating with chef server.\n> \n> Since the VM resides on the data network, how does it reach the heat server\n> that is on openstack management network. Is there a translation at network\n> node similar to metadata server for 169 network for heat server access or\n> chef server ? Of course I am assuming that chef server resides on\n> management network too.\n\nIn the chef examples talked about, you are either running chef solo,\nor deploying your own chef server. Heat is adding these things mostly to\nsimplify template writing for the common cases. One can specify any tool\nas long as there is a script to interpret the config items into inputs,\nand produce outputs.\n\nFor the heat service that instances talk to, Heat has a configuration\nsetting for the engine which controls the endpoint it passes in to\nmachines to inform them where to phone-home.\n\nIt does not use the EC2 metadata on 169.254.169.254, but it would be\ninteresting to just extend the EC2 metadata service to support Heat\nthings so that we could use this endpoint inside private networks.\n\nWithout that, as it works today, instances have to have a route to\nwhatever endpoint is configured.\n\n\n','<CADstcNa+Ah+FDR_DoTOdOPvdhGmLQAhd9K0oS4suqGGeV4KufQ@mail.gmail.com>',NULL),('<1390575929.2199.14.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 10:05:29',-18000,'2014-01-24 15:05:29',NULL,'[openstack-dev] [savanna] why swift-internal:// ?','Matt et al,\n\n  Yes, \"swift-internal\" was meant as a marker to distinguish it from\n\"swift-external\" someday. I agree, this could be indicated by setting \nother fields.\n\nLittle bit of implementation detail for scope:\n\n  In the current EDP implementation, SWIFT_INTERNAL_PREFIX shows up in\nessentially two places.  One is validation (pretty easy to change).\n\n  The other is in Savanna\'s binary_retrievers module where, as others\nsuggested, the auth url (proto, host, port, api) and admin tenant from\nthe savanna configuration are used with the user/passw to make a\nconnection through the swift client.\n\n  Handling of different types of job binaries is done in\nbinary_retrievers/dispatch.py, where the URL determines the treatment.\nThis could easily be extended to look at other indicators.\n\nBest,\n\nTrev\n\nOn Fri, 2014-01-24 at 07:50 -0500, Matthew Farrellee wrote:\n> andrew,\n> \n> what about having swift:// which defaults to the configured tenant and \n> auth url for what we now call swift-internal, and we allow for user \n> input to change tenant and auth url for what would be swift-external?\n> \n> in fact, we may need to add the tenant selection in icehouse. it\'s a \n> pretty big limitation to only allow a single tenant.\n> \n> best,\n> \n> \n> matt\n> \n> On 01/23/2014 11:15 PM, Andrew Lazarev wrote:\n> > Matt,\n> >\n> > For swift-internal we are using the same keystone (and identity protocol\n> > version) as for savanna. Also savanna admin tenant is used.\n> >\n> > Thanks,\n> > Andrew.\n> >\n> >\n> > On Thu, Jan 23, 2014 at 6:17 PM, Matthew Farrellee <matt at redhat.com\n> > <mailto:matt at redhat.com>> wrote:\n> >\n> >     what makes it internal vs external?\n> >\n> >     swift-internal needs user & pass\n> >\n> >     swift-external needs user & pass & ?auth url?\n> >\n> >     best,\n> >\n> >\n> >     matt\n> >\n> >     On 01/23/2014 08:43 PM, Andrew Lazarev wrote:\n> >\n> >         Matt,\n> >\n> >         I can easily imagine situation when job binaries are stored in\n> >         external\n> >         HDFS or external SWIFT (like data sources). Internal and\n> >         external swifts\n> >         are different since we need additional credentials.\n> >\n> >         Thanks,\n> >         Andrew.\n> >\n> >\n> >         On Thu, Jan 23, 2014 at 5:30 PM, Matthew Farrellee\n> >         <matt at redhat.com <mailto:matt at redhat.com>\n> >         <mailto:matt at redhat.com <mailto:matt at redhat.com>>> wrote:\n> >\n> >              trevor,\n> >\n> >              job binaries are stored in swift or an internal savanna db,\n> >              represented by swift-internal:// and savanna-db://\n> >         respectively.\n> >\n> >              why swift-internal:// and not just swift://?\n> >\n> >              fyi, i see mention of a potential future version of savanna w/\n> >              swift-external://\n> >\n> >              best,\n> >\n> >\n> >              matt\n> >\n> >              ___________________________________________________\n> >              OpenStack-dev mailing list\n> >              OpenStack-dev at lists.openstack.____org\n> >              <mailto:OpenStack-dev at lists.__openstack.org\n> >         <mailto:OpenStack-dev at lists.openstack.org>>\n> >         http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev\n> >         <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev>\n> >         <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev\n> >         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>>\n> >\n> >\n> >\n> >\n> >         _________________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.__org\n> >         <mailto:OpenStack-dev at lists.openstack.org>\n> >         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev\n> >         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n> >\n> >\n> >\n> >     _________________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.__org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<52E26194.4060806@redhat.com>',NULL),('<1390584918.23323.20.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-24 12:35:18',-18000,'2014-01-24 17:35:18',NULL,'[Openstack-operators] Keystone Grizzly to Havana upgrade','On Fri, 2014-01-24 at 06:28 +0000, Tim Bell wrote:\n> We\'re using the v2 API at the moment.\n\nOK, thx. For the record, we stuck with the v2 Keystone API as well,\nmostly because we had no need for any of the new features like domains,\ngroups, trusts, etc in the v3 API.\n\n> The overall approach we\'ve taken is to do the migration with identical function as the first step. Additional features can then be tested independently as smaller steps with clearer rollback. The concurrent version API features help greatly with this approach so we don\'t have simultaneous client/server upgrades.\n\nYup, makes total sense.\n\n> We\'re testing the v3 API at the moment and will start to use it in the near future. The domains features in particular are of great interest for us.\n\nCool, let us know how you fare.\n\nBest,\n-jay\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D996B805@CERNXCHG02.cern.ch>',NULL),('<1390587599-sup-9322@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 10:36:08',-28800,'2014-01-24 18:36:08',NULL,'[openstack-dev] [Nova] bp proposal: discovery of peer instances\n	through metadata service','Excerpts from Justin Santa Barbara\'s message of 2014-01-24 07:43:23 -0800:\n> Good points - thank you.  For arbitrary operations, I agree that it would\n> be better to expose a token in the metadata service, rather than allowing\n> the metadata service to expose unbounded amounts of API functionality.  We\n> should therefore also have a per-instance token in the metadata, though I\n> don\'t see Keystone getting the prerequisite IAM-level functionality for\n> two+ releases (?).\n> \n\nHeat has been working hard to be able to do per-instance limited access\nin Keystone for a while. A trust might work just fine for what you want.\n\n> However, I think I can justify peer discovery as the \'one exception\'.\n>  Here\'s why: discovery of peers is widely used for self-configuring\n> clustered services, including those built in pre-cloud days.\n>  Multicast/broadcast used to be the solution, but cloud broke that.  The\n> cloud is supposed to be about distributed systems, yet we broke the primary\n> way distributed systems do peer discovery. Today\'s workarounds are pretty\n> terrible, e.g. uploading to an S3 bucket, or sharing EC2 credentials with\n> the instance (tolerable now with IAM, but painful to configure).  We\'re not\n> talking about allowing instances to program the architecture (e.g. attach\n> volumes etc), but rather just to do the equivalent of a multicast for\n> discovery.  In other words, we\'re restoring some functionality we took away\n> (discovery via multicast) rather than adding programmable-infrastructure\n> cloud functionality.\n> \n\nAre you hesitant to just use Heat? This is exactly what it is supposed\nto do.. make a bunch of API calls and expose the results to instances\nfor use in configuration.\n\nIf you\'re just hesitant to use a declarative templating language, I\ntotally understand. The auto-scaling minded people are also feeling\nthis way. You could join them in the quest to create an imperative\ncluster-making API for Heat.\n\n> We expect the instances to start a gossip protocol to determine who is\n> actually up/down, who else is in the cluster, etc.  As such, we don\'t need\n> accurate information - we only have to help a node find one living peer.\n>  (Multicast/broadcast was not entirely reliable either!)  Further, instance\n> #2 will contact instance #1, so it doesn?t matter if instance #1 doesn?t\n> have instance #2 in the list, as long as instance #2 sees instance #1.  I\'m\n> relying on the idea that instance launching takes time > 0, so other\n> instances will be in the starting state when the metadata request comes in,\n> even if we launch instances simultaneously.  (Another reason why I don\'t\n> filter instances by state!)\n> \n> I haven\'t actually found where metadata caching is implemented, although\n> the constructor of InstanceMetadata documents restrictions that really only\n> make sense if it is.  Anyone know where it is cached?\n> \n> In terms of information exposed: An alternative would be to try to connect\n> to every IP in the subnet we are assigned; this blueprint can be seen as an\n> optimization on that (to avoid DDOS-ing the public clouds).  So I?ve tried\n> to expose only the information that enables directed scanning: availability\n> zone, reservation id, security groups, network ids & labels & cidrs & IPs\n> [example below].  A naive implementation will just try every peer; a\n> smarter implementation might check the security groups to try to filter it,\n> or the zone information to try to connect to nearby peers first.  Note that\n> I don?t expose e.g. the instance state: if you want to know whether a node\n> is up, you have to try connecting to it.  I don\'t believe any of this\n> information is at all sensitive, particularly not to instances in the same\n> project.\n> \n> On external agents doing the configuration: yes, they could put this into\n> user defined metadata, but then we\'re tied to a configuration system.  We\n> have to get 20 configuration systems to agree on a common format (Heat,\n> Puppet, Chef, Ansible, SaltStack, Vagrant, Fabric, all the home-grown\n> systems!)  It also makes it hard to launch instances concurrently (because\n> you want node #2 to have the metadata for node #1, so you have to wait for\n> node #1 to get an IP).\n> \n> More generally though, I have in mind a different model, which I call\n> \'configuration from within\' (as in \'truth comes from within\'). I don?t want\n> a big imperialistic configuration system that comes and enforces its view\n> of the world onto primitive machines.  I want a smart machine that comes\n> into existence, discovers other machines and cooperates with them.  This is\n> the Netflix pre-baked AMI concept, rather than the configuration management\n> approach.\n> \n\n:) We are on the same page. I really think Heat is where higher level\ninformation sharing of this type belongs. I do think it might make sense\nfor Heat to push things into user-data post-boot, rather than only expose\nthem via its own metadata service. However, even without that, you can\nachieve what you\'re talking about right now with Heat\'s separate metadata.\n\n> The blueprint does not exclude \'imperialistic\' configuration systems, but\n> it does enable e.g. just launching N instances in one API call, or just\n> using an auto-scaling group.  I suspect the configuration management\n> systems would prefer this to having to implement this themselves.\n> \n\nN instances in one API call is something Heat does well, and it does\nauto scaling too, so I feel like your idea is mostly just asking for a\nsimpler way to use Heat, which I think everyone would agree would be\ngood for all Heat users. :)\n\n\n','<CAFoXKmpT66MT0A-NtiDf7m83XdPk2YrYZnJtQc26qUguw2_ueA@mail.gmail.com>',NULL),('<1390588987-sup-1593@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 10:47:59',-28800,'2014-01-24 18:47:59',NULL,'[openstack-dev] MariaDB support','Excerpts from Tim Bell\'s message of 2014-01-24 10:32:26 -0800:\n> \n> We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to have MariaDB as the default MySQL-like DB.\n> \n> Can someone summarise the status of the OpenStack in terms of\n> \n> \n> -        What MySQL-flavor is/are currently tested in the gate ?\n> \n> -        What is supported by the current code ?\n> \n> -        Is there an agreed long term direction and if there are transitions, when will these occur ?\n> \n\nTim it is worth noting that, for the most part, MariaDB 5.5 is going to\nwork 99.9% the same as MySQL 5.5, which is, I believe, what is tested\nin the gate (since it is just what you get when apt-get installing\nmysql-server on Ubuntu). I have only heard of a few optimizer quirks in\nMariaDB that make it any different to vanilla MySQL.\n\nI do think that while we\'ve been able to make some assumptions about\nthis compatibility for a while, with MariaDB becoming a proper fork and\nnot just a derivative, we will likely need to start testing both.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D996D6B6@CERNXCHG02.cern.ch>',NULL),('<1390590909-sup-3179@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 11:18:54',-28800,'2014-01-24 19:18:54',NULL,'[openstack-dev] MariaDB support','Excerpts from Steven Dake\'s message of 2014-01-24 11:05:25 -0800:\n> On 01/24/2014 11:47 AM, Clint Byrum wrote:\n> > Excerpts from Tim Bell\'s message of 2014-01-24 10:32:26 -0800:\n> >> We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to have MariaDB as the default MySQL-like DB.\n> >>\n> >> Can someone summarise the status of the OpenStack in terms of\n> >>\n> >>\n> >> -        What MySQL-flavor is/are currently tested in the gate ?\n> >>\n> >> -        What is supported by the current code ?\n> >>\n> >> -        Is there an agreed long term direction and if there are transitions, when will these occur ?\n> >>\n> > Tim it is worth noting that, for the most part, MariaDB 5.5 is going to\n> > work 99.9% the same as MySQL 5.5, which is, I believe, what is tested\n> > in the gate (since it is just what you get when apt-get installing\n> > mysql-server on Ubuntu). I have only heard of a few optimizer quirks in\n> > MariaDB that make it any different to vanilla MySQL.\n> >\n> > I do think that while we\'ve been able to make some assumptions about\n> > this compatibility for a while, with MariaDB becoming a proper fork and\n> > not just a derivative, we will likely need to start testing both.\n> My understanding is later versions of MySQL change the on disk format \n> and possibly some other compatibility functionality, making testing both \n> a necessity since Red Hat ships Maria and Ubuntu plans to stick with MySQL.\n\nOn-disk format changes are completely opaque to OpenStack testing. That\ncomes with MariaDB 10 as they basically have decided to stop trying to\nkeep up with the Oracle firehose of engineering changes and go their own\nway. We would only care about that change if we wanted to have drop-in\nreplacement capability to test between the two.\n\nFor OpenStack, only SQL or protocol incompatibilities would matter. IMO\nMariaDB would be wise to be very careful not to ever break this. That\nis one of the things that really trashed early adoption of Drizzle IMO,\nbecause you had to change your app to speak Drizzle-SQL instead of just\nspeaking the same old (broken) MySQL.\n\nUs using the more strict traditional dialect will hopefully save us from\nthe fate of having to adapt to different forks of MySQL though.\n\n\n','<52E2B975.2070002@redhat.com>',NULL),('<1390591424.13885.74966349.4132BE66@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 11:23:44',-28800,'2014-01-24 19:23:44',NULL,'[openstack-dev] Gate Status - Friday Edition','On Fri, Jan 24, 2014, at 10:51 AM, John Griffith wrote:\n> On Fri, Jan 24, 2014 at 11:37 AM, Clay Gerrard <clay.gerrard at gmail.com>\n> wrote:\n> >>\n> >>\n> >> That\'s a pretty high rate of failure, and really needs investigation.\n> >\n> >\n> > That\'s a great point, did you look into the logs of any of those jobs?\n> > Thanks for bringing it to my attention.\n> >\n> > I saw a few swift tests that would pop, I\'ll open bugs to look into those.\n> > But the cardinality of the failures (7) was dwarfed by jenkins failures I\n> > don\'t quite understand.\n> >\n> > [EnvInject] - [ERROR] - SEVERE ERROR occurs: java.lang.InterruptedException\n> > (e.g.\n> > http://logs.openstack.org/86/66986/3/gate/gate-swift-python27/2e6a8fc/console.html)\n> >\n> > FATAL: command execution failed | java.io.InterruptedIOException (e.g.\n> > http://logs.openstack.org/84/67584/5/gate/gate-swift-python27/4ad733d/console.html)\n> >\n> > These jobs are blowing up setting up the workspace on the slave, and we\'re\n> > not automatically retrying them?  How can this only be effecting swift?\n> \n> It\'s certainly not just swift:\n> \n> http://logstash.openstack.org/#eyJzZWFyY2giOiJcImphdmEuaW8uSW50ZXJydXB0ZWRJT0V4Y2VwdGlvblwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxMzkwNTg5MTg4NjY5fQ==\n> \n> >\n> > -Clay\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThis isn\'t all doom and gloom, but rather an unfortunate side effect of\nhow Jenkins aborts jobs. When a job is aborted there are corner cases\nwhere Jenkins does not catch all of the exceptions that may happen and\nthat results in reporting the build as a failure instead of an abort.\nNow all of this would be fine if we never aborted jobs, but it turns out\nZuul aggressively aborts jobs when it knows the result of that job will\nnot help anything (either ability to merge or useful results to report\nback to code reviewers).\n\nI have a hunch (but would need to do a bunch of digging to confirm it)\nthat most of these errors are simply job aborts that happened in ways\nthat Jenkins couldn\'t recover from gracefully. Looking at the most\nrecent occurrence of this particular failure we see\nhttps://review.openstack.org/#/c/66307 failed\ngate-tempest-dsvm-neutron-large-ops. If we go to the comments on the\nchange we see that this particular failure was never reported, which\nimplies the failure happened as part of a build abort.\n\nThe other thing we can do to convince ourselves that this problem is\nmostly a poor reporting of job aborts is restricting our logstash search\nto build_queue:\"check\". Only the gate queue aborts jobs in this way so\noccurrences in the check queue would indicate an actual problem. If we\ndo that we see a bunch of \"hudson.remoting.RequestAbortedException\"\nwhich are also aborts not handled properly and since zuul shouldn\'t\nabort the check queue were probably a result of some human aborting jobs\nafter a Zuul restart.\n\nTL;DR I believe this is mostly a non issue and has to do with Zuul and\nJenkins quirks. If you see this error reported to Gerrit we should do\nmore digging.\n\nClark\n\n\n','<CA+qL3LWBHdFKsMJK-3Mb5v1DNU0HemB_J26MnvT-pGWXjXtV0Q@mail.gmail.com>',NULL),('<1390591483-sup-9913@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 11:35:51',-28800,'2014-01-24 19:35:51',NULL,'[openstack-dev] [Ironic] File Injection (and the lack thereof)','Excerpts from Devananda van der Veen\'s message of 2014-01-24 06:15:12 -0800:\n> In going through the bug list, I spotted this one and would like to discuss\n> it:\n> \n> \"can\'t disable file injection for bare metal\"\n> https://bugs.launchpad.net/ironic/+bug/1178103\n> \n> There\'s a #TODO in Ironic\'s PXE driver to *add* support for file injection,\n> but I don\'t think we should do that. For the various reasons that Robert\n> raised a while ago (\n> http://lists.openstack.org/pipermail/openstack-dev/2013-May/008728.html),\n> file injection for Ironic instances is neither scalable nor secure. I\'d\n> just as soon leave support for it completely out.\n> \n> However, Michael raised an interesting counter-point (\n> http://lists.openstack.org/pipermail/openstack-dev/2013-May/008735.html)\n> that some deployments may not be able to use cloud-init due to their\n> security policy.\n> \n\nI\'m not sure how careful we are about security while copying the image.\nGiven that we currently just use tftp and iSCSI, it seems like putting\nanother requirement on that for security (user-data, network config,\netc) is like pushing the throttle forward on the Titanic.\n\nI\'d much rather see cloud-init/ec2-metadata made to work better than\nsee us over complicate an already haphazard process with per-node\ncustomization. Perhaps We could make EC2 metadata work with SSL and bake\nCA certs into the images?\n\n\n','<CAExZKEq5s-4KqZeCXbxuhJkcgF5ihs5N5p+kq+HKbdau=drkxg@mail.gmail.com>',NULL),('<1390592628-sup-8012@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 11:47:23',-28800,'2014-01-24 19:47:23',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Day, Phil\'s message of 2014-01-24 04:39:10 -0800:\n> > On 01/22/2014 12:17 PM, Dan Prince wrote:\n> > > I\'ve been thinking a bit more about how TripleO updates are developing\n> > specifically with regards to compute nodes. What is commonly called the\n> > \"update story\" I think.\n> > >\n> > > As I understand it we expect people to actually have to reboot a compute\n> > node in the cluster in order to deploy an update. This really worries me\n> > because it seems like way overkill for such a simple operation. Lets say all I\n> > need to deploy is a simple change to Nova\'s libvirt driver. And I need to\n> > deploy it to *all* my compute instances. Do we really expect people to\n> > actually have to reboot every single compute node in their cluster for such a\n> > thing. And then do this again and again for each update they deploy?\n> > \n> > FWIW, I agree that this is going to be considered unacceptable by most\n> > people.  Hopefully everyone is on the same page with that.  It sounds like\n> > that\'s the case so far in this thread, at least...\n> > \n> > If you have to reboot the compute node, ideally you also have support for\n> > live migrating all running VMs on that compute node elsewhere before doing\n> > so.  That\'s not something you want to have to do for *every* little change to\n> > *every* compute node.\n> >\n> \n> Yep, my reading is the same as yours Russell, everyone agreed that there needs to be an update that avoids the reboot where possible (other parts of the thread seem to be focused on how much further the update can be optimized).\n> \n> What\'s not clear to me is when the plan is to have that support in TripleO - I tried looking for a matching Blueprint to see if it was targeted for Icehouse but can\'t match it against the five listed.   Perhaps Rob or Clint can clarify ?\n> Feels to me that this is a must have before anyone will really be able to use TripleO beyond a PoC for initial deployment.\n> \n\nRight now we are focused on the hard case, updates requiring\nreboot. Avoiding the reboot is a bit more than an optimization, but it\nis something we will get to once we\'ve nailed the harder case of handling\na new kernel and reboot gracefully.\n\nI for one have a fear that if we start with the easy case, we\'ll just\navoid the hard one, spend less time on it, and thus do it poorly.\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F9007A@G6W2490.americas.hpqcorp.net>',NULL),('<1390592846-sup-100@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 11:52:47',-28800,'2014-01-24 19:52:47',NULL,'[openstack-dev] [TripleO] our update story: can people live\n	with it?','Excerpts from Day, Phil\'s message of 2014-01-24 04:24:11 -0800:\n> > >\n> > > Cool. I like this a good bit better as it avoids the reboot. Still, this is a rather\n> > large amount of data to copy around if I\'m only changing a single file in Nova.\n> > >\n> > \n> > I think in most cases transfer cost is worth it to know you\'re deploying what\n> > you tested. Also it is pretty easy to just do this optimization but still be\n> > rsyncing the contents of the image. Instead of downloading the whole thing\n> > we could have a box expose the mounted image via rsync and then all of the\n> > machines can just rsync changes. Also rsync has a batch mode where if you\n> > know for sure the end-state of machines you can pre-calculate that rsync and\n> > just ship that. Lots of optimization possible that will work fine in your just-\n> > update-one-file scenario.\n> > \n> > But really, how much does downtime cost? How much do 10Gb NICs and\n> > switches cost?\n> > \n> \n> It\'s not as simple as just saying \"buy better hardware\" (although I do have a vested interest in that approach ;-)  - on a compute node the Network and Disk bandwidth is already doing useful work for paying customers.   The more overhead you put into that for updates, the more disruptive it becomes.\n> \n\nAgreed. The question becomes whether you should reserve a portion of\nyour resources for updates or let them push you into over-subscription.\nEither way, those are business decisions.\n\nAnd once we have a working system and we can say \"this costs X bitcoins\",\nwe can make a clear justification for somebody to spend developer time\nto push X downward.\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F8FFDC@G6W2490.americas.hpqcorp.net>',NULL),('<1390596766-sup-2257@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 12:53:23',-28800,'2014-01-24 20:53:23',NULL,'[openstack-dev] MariaDB support','Excerpts from Chuck Short\'s message of 2014-01-24 11:46:47 -0800:\n> On Fri, Jan 24, 2014 at 2:05 PM, Steven Dake <sdake at redhat.com> wrote:\n> \n> > On 01/24/2014 11:47 AM, Clint Byrum wrote:\n> >\n> >> Excerpts from Tim Bell\'s message of 2014-01-24 10:32:26 -0800:\n> >>\n> >>> We are reviewing options between MySQL and MariaDB. RHEL 7 beta seems to\n> >>> have MariaDB as the default MySQL-like DB.\n> >>>\n> >>> Can someone summarise the status of the OpenStack in terms of\n> >>>\n> >>>\n> >>> -        What MySQL-flavor is/are currently tested in the gate ?\n> >>>\n> >>> -        What is supported by the current code ?\n> >>>\n> >>> -        Is there an agreed long term direction and if there are\n> >>> transitions, when will these occur ?\n> >>>\n> >>>  Tim it is worth noting that, for the most part, MariaDB 5.5 is going to\n> >> work 99.9% the same as MySQL 5.5, which is, I believe, what is tested\n> >> in the gate (since it is just what you get when apt-get installing\n> >> mysql-server on Ubuntu). I have only heard of a few optimizer quirks in\n> >> MariaDB that make it any different to vanilla MySQL.\n> >>\n> >> I do think that while we\'ve been able to make some assumptions about\n> >> this compatibility for a while, with MariaDB becoming a proper fork and\n> >> not just a derivative, we will likely need to start testing both.\n> >>\n> > My understanding is later versions of MySQL change the on disk format and\n> > possibly some other compatibility functionality, making testing both a\n> > necessity since Red Hat ships Maria and Ubuntu plans to stick with MySQL.\n> \n> \n> Actually we have given the user the option to either run MySQL or Mariadb\n> on their server since it is both in the archive.\n> \n\nI have not seen anything that will promote MariaDB to main though, so\nhaving it \"in the archive\" isn\'t quite the same as having it \"in the\narchive that gets security updates\".\n\n\n','<CANZa-eJ9a3ZvvLydO_vGW0a5=7yndvHxx-_emaM9T5QPvQ7pfA@mail.gmail.com>',NULL),('<1390596844-sup-7618@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 12:55:25',-28800,'2014-01-24 20:55:25',NULL,'[openstack-dev] MariaDB support','Excerpts from Tim Bell\'s message of 2014-01-24 11:55:02 -0800:\n> \n> This is exactly my worry... at what point can I consider moving to MariaDB with the expectation that the testing confidence is equivalent to that which is currently available from MySQL ?\n> \n> The on-disk format is not so much a concern but there are many potential subtle differences in the API which can occur over time such as reserved words or recovery handling from certain errors.\n> \n> Currently, my \'operational\' hat says stay with MySQL. My \'community\' hat direction is less clear. Given that Ubuntu and Red Hat are not agreeing on the direction makes this likely to be an extended uncertainty.\n> \n> Maybe two yes/no answers would help....\n> \n> 1. Is there any current blocking gate tests with MariaDB ?\n> 2. Is there a plan to change this at a future release ?\n> \n> If the answer to 1 is no, the operational hat says to stay on MySQL currently.\n> \n> If the answer to 2 is yes, we should be planning to migrate.\n\nI think another question you may want to ask is \"are there gate blocking\ntests on RHEL/CentOS/etc.?\"\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D996EFE9@CERNXCHG02.cern.ch>',NULL),('<1390597119-sup-1949@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 13:09:04',-28800,'2014-01-24 21:09:04',NULL,'[openstack-dev] [Nova] bp proposal: discovery of peer instances\n	through metadata service','Excerpts from Justin Santa Barbara\'s message of 2014-01-24 12:29:49 -0800:\n> Clint Byrum <clint at fewbar.com> wrote:\n> \n> >\n> > Heat has been working hard to be able to do per-instance limited access\n> > in Keystone for a while. A trust might work just fine for what you want.\n> >\n> \n> I wasn\'t actually aware of the progress on trusts.  It would be helpful\n> except (1) it is more work to have to create a separate trust (it is even\n> more painful to do so with IAM) and (2) it doesn\'t look like we can yet\n> lock-down these delegations as much as people would probably want.  I think\n> IAM is the end-game in terms of the model that people actually want, and it\n> ends up being incredibly complex.  Delegation is very useful (particularly\n> because clusters could auto-scale themselves), but I\'d love to get an\n> easier solution for the peer discovery problem than where delegation ends\n> up.\n> \n> Are you hesitant to just use Heat? This is exactly what it is supposed\n> > to do.. make a bunch of API calls and expose the results to instances\n> > for use in configuration.\n> \n> > If you\'re just hesitant to use a declarative templating language, I\n> > totally understand. The auto-scaling minded people are also feeling\n> > this way. You could join them in the quest to create an imperative\n> > cluster-making API for Heat.\n> >\n> \n> I don\'t want to _depend_ on Heat.  My hope is that we can just launch 3\n> instances with the Cassandra image, and get a Cassandra cluster.  It might\n> be that we want Heat to auto-scale that cluster, Ceilometer to figure out\n> when to scale it, Neutron to isolate it, etc but I think we can solve the\n> basic discovery problem cleanly without tying in all the other services.\n>  Heat\'s value-add doesn\'t come from solving this problem!\n> \n\nI suppose we disagree on this fundamental point then.\n\nHeat\'s value-add really does come from solving this exact problem. It\nprovides a layer above all of the other services to facilitate expression\nof higher level concepts. Nova exposes a primitive API, where as Heat is\nmeant to have a more logical expression of the user\'s intentions. That\nincludes exposure of details of one resource to another (not just compute,\nswift containers, load balancers, volumes, images, etc).\n\n> :) We are on the same page. I really think Heat is where higher level\n> > information sharing of this type belongs. I do think it might make sense\n> > for Heat to push things into user-data post-boot, rather than only expose\n> > them via its own metadata service. However, even without that, you can\n> > achieve what you\'re talking about right now with Heat\'s separate metadata.\n> >\n> ...\n> \n> > N instances in one API call is something Heat does well, and it does\n> > auto scaling too, so I feel like your idea is mostly just asking for a\n> > simpler way to use Heat, which I think everyone would agree would be\n> > good for all Heat users. :)\n> \n> \n> I have a personal design goal of solving the discovery problem in a way\n> that works even on non-clouds.  So I can write a clustered service, and it\n> will run everywhere.  The way I see it is that:\n> \n>    - If we\'re on physical, the instance will use multicast & broadcast to\n>    find peers on the network.\n>    - If we\'re on OpenStack, the instance will use this blueprint to find\n>    its peers.  The instance may be launched through Nova, or Heat, or\n>    Puppet/Chef/Salt/etc.  I would like to see people use Heat, but I don\'t\n>    want to force people to use Heat.  If Heat starts putting a more accurate\n>    list of peers into metadata, I will check that first.  But if I can\'t find\n>    that list of peers that Heat provides, I will fall-back to whatever I can\n>    get from Nova so that I can cope with people not on Heat.\n>    - If we\'re on EC2, the user must configure an IAM role and assign it to\n>    their instances, and then we will query the list of instances.\n> \n> It gives me great pleasure that EC2 will end up needing the most\n> undifferentiated lifting from the user.\n> \n\nHeat is meant to be a facility for exactly what you want. If you don\'t\nwant to ask people to use it, you\'re just duplicating Heat functionality\nin Nova. Using Heat means no query/filter for the instances you want:\nyou have the exact addresses in your cluster.\n\nMy suggestion would be that if you want to hide all of the complexity\nof Heat from users, you add a simplified API to Heat that enables your\nuse case. In many ways that is exactly what Savanna, Trove, et.al are:\ndomain specific cluster API\'s backed by orchestration.\n\n\n','<CAFoXKmoRHa0cdAYesTvpNvVFXGapXgWVQYMcFLtvf_xMZUeNVQ@mail.gmail.com>',NULL),('<1390598691.11581.75005317.159AB786@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 13:24:51',-28800,'2014-01-24 21:24:51',NULL,'[openstack-dev] MariaDB support','On Fri, Jan 24, 2014, at 12:55 PM, Clint Byrum wrote:\n> Excerpts from Tim Bell\'s message of 2014-01-24 11:55:02 -0800:\n> > \n> > This is exactly my worry... at what point can I consider moving to MariaDB with the expectation that the testing confidence is equivalent to that which is currently available from MySQL ?\n> > \n> > The on-disk format is not so much a concern but there are many potential subtle differences in the API which can occur over time such as reserved words or recovery handling from certain errors.\n> > \n> > Currently, my \'operational\' hat says stay with MySQL. My \'community\' hat direction is less clear. Given that Ubuntu and Red Hat are not agreeing on the direction makes this likely to be an extended uncertainty.\n> > \n> > Maybe two yes/no answers would help....\n> > \n> > 1. Is there any current blocking gate tests with MariaDB ?\n> > 2. Is there a plan to change this at a future release ?\n> > \n> > If the answer to 1 is no, the operational hat says to stay on MySQL currently.\n> > \n> > If the answer to 2 is yes, we should be planning to migrate.\n> \n> I think another question you may want to ask is \"are there gate blocking\n> tests on RHEL/CentOS/etc.?\"\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThere is actually, but only for python2.6 unittests run on CentOS 6.5.\nAll of the tempest tests run on Ubuntu Precise with most jobs using\nMySQL and a few using PostgreSQL. None of the tests use MariaDB today.\nThere were folks working on getting Fedora nodes into nodepool to do\ntesting of some sort on Fedora (which would be MariaDB aiui), but ran\ninto trouble around nodepool\'s privilege expectations (something about\nsudo needing a proper tty and paramiko not being able to nicely provide\none). We should pick that work back up again, but Infra has been swamped\nrecently.\n\nIf we do end up adding MariaDB integration (tempest) tests I would not\nadd another set of tests. Instead we should probably swap out MySQL and\nuse MariaDB in one of the existing tests.\n\nClark\n\n\n','<1390596844-sup-7618@fewbar.com>',NULL),('<1390602419-sup-8415@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 14:27:24',-28800,'2014-01-24 22:27:24',NULL,'[openstack-dev] [Ironic] File Injection (and the lack thereof)','Excerpts from Joshua Harlow\'s message of 2014-01-24 14:17:38 -0800:\n> Cloud-init 0.7.5 (not yet released) will have the ability to read from an\n> ec2-metadata server using SSL.\n> \n> In a recent change I did we now use requests which correctly does SSL for\n> the ec2-metadata/ec2-userdata reading.\n> \n> - http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/910\n> \n> For ssl-certs that it will use by default (if not provided) will be looked\n> for in the following locations.\n> \n> - /var/lib/cloud/data/ssl\n>    - cert.pem\n>    - key\n> - /var/lib/cloud/instance/data/ssl\n>    - cert.pem\n>    - key\n> - ... Other custom paths (typically datasource dependent)\n> \n> So I think in 0.7.5 for cloud-init this support will be improved and as\n> long as there is a supporting ssl ec2 metadata endpoint then this should\n> all work out fine...\n\n\\o/ my heroes! ;)\n\n\n','<CF0817F1.545A1%harlowja@yahoo-inc.com>',NULL),('<1390604715-sup-7290@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 15:09:56',-28800,'2014-01-24 23:09:56',NULL,'[openstack-dev] [Ironic] File Injection (and the lack thereof)','Simplest thing is for deployers and image builders to inject the CA that\nthey want to trust.  Another option would be to establish an OpenStack\ncommunity CA and ship that along with cloud-init by default.\n\nThere are lots of options that don\'t involve out of band.\n\nExcerpts from Devananda van der Veen\'s message of 2014-01-24 14:41:44 -0800:\n> Awesome! But, Ironic will still need a way to inject the SSL cert into the\n> instance, eg. config-drive over virtual media, or something.\n> \n> -D\n>  On Jan 24, 2014 2:32 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> > Excerpts from Joshua Harlow\'s message of 2014-01-24 14:17:38 -0800:\n> > > Cloud-init 0.7.5 (not yet released) will have the ability to read from an\n> > > ec2-metadata server using SSL.\n> > >\n> > > In a recent change I did we now use requests which correctly does SSL for\n> > > the ec2-metadata/ec2-userdata reading.\n> > >\n> > > -\n> > http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/910\n> > >\n> > > For ssl-certs that it will use by default (if not provided) will be\n> > looked\n> > > for in the following locations.\n> > >\n> > > - /var/lib/cloud/data/ssl\n> > >    - cert.pem\n> > >    - key\n> > > - /var/lib/cloud/instance/data/ssl\n> > >    - cert.pem\n> > >    - key\n> > > - ... Other custom paths (typically datasource dependent)\n> > >\n> > > So I think in 0.7.5 for cloud-init this support will be improved and as\n> > > long as there is a supporting ssl ec2 metadata endpoint then this should\n> > > all work out fine...\n> >\n> > \\o/ my heroes! ;)\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n\n\n','<CAExZKEprXXOFOw+zEHGqL6WRQ1NzgnKmpjnE2FMVKSwiP_bUvg@mail.gmail.com>',NULL),('<1390609755-sup-3866@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 18:11:03',-28800,'2014-01-25 02:11:03',NULL,'[openstack-dev] [Ironic] Node groups and multi-node operations','Excerpts from Devananda van der Veen\'s message of 2014-01-22 16:44:01 -0800:\n> \n> 1: physical vs. logical grouping\n> - Some hardware is logically, but not strictly physically, grouped. Eg, 1U\n> servers in the same rack. There is some grouping, such as failure domain,\n> but operations on discrete nodes are discreet. This grouping should be\n> modeled somewhere, and some times a user may wish to perform an operation\n> on that group. Is a higher layer (tuskar, heat, etc) sufficient? I think so.\n> - Some hardware _is_ physically grouped. Eg, high-density cartridges which\n> share firmware state or a single management end-point, but are otherwise\n> discrete computing devices. This grouping must be modeled somewhere, and\n> certain operations can not be performed on one member without affecting all\n> members. Things will break if each node is treated independently.\n> \n\nWhat Tuskar wants to do is layer workloads on top of logical and physical\ngroupings. So it would pass to Nova \"Boot 4 machines with (flavor)\nand distinct(failure_domain_id)\"\n\nNow, this is not unique to baremetal. There are plenty of cloud workloads\nwhere one would like anti-affinity and other such things that will span\nmore than a single compute node. Right now these are at a very coarse\nlevel which is \"availability zone\". I think it is useful for Nova to\nbe able to have a list of aspects for each compute node which are not\nhierarchical and isolate failure domains which matter for different\nwork-loads.\n\nAnd with that, if we simply require at least one instance of nova-compute\nrunning for each set of aspects, Ironic does not have to model this data.\n\nHowever, in looking at how Ironic works and interacts with Nova, it\ndoesn\'t seem like there is any distinction of data per-compute-node\ninside Ironic.  So for this to work, I\'d have to run a whole bunch of\nironic instances, one per compute node. That seems like something we\ndon\'t want to do.\n\nSo perhaps if ironic can just model _a single_ logical grouping per node,\nit can defer any further distinctions up to Nova where it will benefit\nall workloads, not just Ironic.\n\n> 2: performance optimization\n> - Some operations may be optimized if there is an awareness of concurrent\n> identical operations. Eg, deploy the same image to lots of nodes using\n> multicast or bittorrent. If Heat were to inform Ironic that this deploy is\n> part of a group, the optimization would be deterministic. If Heat does not\n> inform Ironic of this grouping, but Ironic infers it (eg, from timing of\n> requests for similar actions) then optimization is possible but\n> non-deterministic, and may be much harder to reason about or debug.\n> \n\nI\'m wary of trying to get too deep on optimization this early. There\nare some blanket optimizations that you allude to here that I think will\nlikely work o-k with even the most minimal of clues.\n\n> 3: APIs\n> - Higher layers of OpenStack (eg, Heat) are expected to orchestrate\n> discrete resource units into a larger group operation. This is where the\n> grouping happens today, but already results in inefficiencies when\n> performing identical operations at scale. Ironic may be able to get around\n> this by coalescing adjacent requests for the same operation, but this would\n> be non-deterministic.\n\nAgreed, I think Ironic needs _some_ level of grouping to be efficient.\n\n> - Moving group-awareness or group-operations into the lower layers (eg,\n> Ironic) looks like it will require non-trivial changes to Heat and Nova,\n> and, in my opinion, violates a layer-constraint that I would like to\n> maintain. On the other hand, we could avoid the challenges around\n> coalescing. This might be necessary to support physically-grouped hardware\n> anyway, too.\n>\n\nI actually think that the changes to Heat and Nova are trivial. Nova\nneeds to have groups for compute nodes and the API needs to accept those\ngroups. Heat needs to take advantage of them via the API.\n\nThere is a non-trivial follow-on which is a \"wholistic\" scheduler which\nwould further extend these groups into other physical resources like\nnetworks and block devices. These all feel like logical evolutions of the\nidea of making somewhat arbitrary and overlapping groups of compute nodes.\n\n> \n> If Ironic coalesces requests, it could be done in either the\n> ConductorManager layer or in the drivers themselves. The difference would\n> be whether our internal driver API accepts one node or a set of nodes for\n> each operation. It\'ll also impact our locking model. Both of these are\n> implementation details that wouldn\'t affect other projects, but would\n> affect our driver developers.\n> \n> Also, until Ironic models physically-grouped hardware relationships in some\n> internal way, we\'re going to have difficulty supporting that class of\n> hardware. Is that OK? What is the impact of not supporting such hardware?\n> It seems, at least today, to be pretty minimal.\n\nI don\'t know much about hardware like that. I think it should just be\nanother grouping unless it affects the way Ironic talks to the hardware,\nat which point it probably belongs in a driver, no?\n\n\n','<CAExZKEoOSCVj1hwZ_R3fq0sx1f_jHLe3SDY=AXSFeXtqEvL-TQ@mail.gmail.com>',NULL),('<1390619413729.c88aef82@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 19:10:14',-28800,'2014-01-25 03:10:14',NULL,'[openstack-dev] [Neutron][IPv6] A pair of mode keywords','Shixiong,\n\n\nI\'m fine with the current two modes design.\n?\nXu Han Peng (xuhanp)\n\nOn Sat, Jan 25, 2014 at 5:17 AM, Shixiong Shang\n<sparkofwisdom.cloud at gmail.com> wrote:\n\n> Any decisions yet?\n> Shixiong\n> On Jan 23, 2014, at 7:45 AM, Veiga, Anthony <Anthony_Veiga at cable.comcast.com> wrote:\n>> \n>>> An openstack deployment with an external DHCP server is definetely a possible scenario; I don\'t think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox.\n>>> Therefore I would not disregard the possibility of an external DHCP server.\n>>> Regarding the new attributes, I pretty much agree on them. As there\'s overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a \'dhcpv4\' valid value for this attribute.\n>> \n>> \n>> We were initially intending to treat enable_dhcp as an on-off flag for IPv6.  If it\'s off, then we won\'t even bother with the other two attributes.  Because of the issues already being discussed elsewhere in Neutron, you can\'t assign multiple scopes to a subnet so it\'s safe to assume that there won\'t be an IPv4 scope in an IPv6 subnet.\n>> \n>>> \n>>> Salvatore\n>>> \n>>> \n>>> On 23 January 2014 04:21, Shixiong Shang <sparkofwisdom.cloud at gmail.com> wrote:\n>>>> Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what?\n>>>> \n>>>> Shixiong\n>>>> \n>>>> \n>>>> \n>>>> On Jan 22, 2014, at 11:20 AM, Collins, Sean <Sean_Collins2 at cable.comcast.com> wrote:\n>>>> \n>>>> > I don\'t know if it\'s reasonable to expect a deployment of OpenStack that\n>>>> > has an *external* DHCP server. It\'s certainly hard to imagine how you\'d\n>>>> > get the Neutron API and an external DHCP server to agree on an IP\n>>>> > assignment, since OpenStack expects to be the source of truth.\n>>>> >\n>>>> > --\n>>>> > Sean M. Collins\n>>>> > _______________________________________________\n>>>> > OpenStack-dev mailing list\n>>>> > OpenStack-dev at lists.openstack.org\n>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/7a1cb5f0/attachment.html>\n\n','<EFBCBEE4-3C78-43E2-9F25-6942E1B122DA@gmail.com>',NULL),('<1390631445-sup-2797@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-24 22:42:42',-28800,'2014-01-25 06:42:42',NULL,'[openstack-dev] [Ironic] Node groups and multi-node operations','Excerpts from Robert Collins\'s message of 2014-01-24 18:48:41 -0800:\n> On 25 Jan 2014 15:11, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> >\n> > Excerpts from Devananda van der Veen\'s message of 2014-01-22 16:44:01\n> -0800:\n> >\n> > What Tuskar wants to do is layer workloads on top of logical and physical\n> > groupings. So it would pass to Nova \"Boot 4 machines with (flavor)\n> > and distinct(failure_domain_id)\"\n> \n> Maybe. Maybe it would ask for a reservation and then ask for machines\n> within that reservation.... Until it is unopened we are speculating :-)\n> \n\nReservation is a better way to put it, I do agree with that.\n\n> > However, in looking at how Ironic works and interacts with Nova, it\n> > doesn\'t seem like there is any distinction of data per-compute-node\n> > inside Ironic.  So for this to work, I\'d have to run a whole bunch of\n> > ironic instances, one per compute node. That seems like something we\n> > don\'t want to do.\n> \n> Huh?\n>\n\nI can\'t find anything in Ironic that lets you group nodes by anything\nexcept chassis. It was not a serious discussion of how the problem would\nbe solved, just a point that without some way to tie ironic nodes to\ncompute-nodes I\'d have to run multiple ironics.\n\n> > So perhaps if ironic can just model _a single_ logical grouping per node,\n> > it can defer any further distinctions up to Nova where it will benefit\n> > all workloads, not just Ironic.\n> \n> Agreed with this.\n> \n> be deterministic. If Heat does not\n> > > inform Ironic of this grouping, but Ironic infers it (eg, from timing of\n> > > requests for similar actions) then optimization is possible but\n> > > non-deterministic, and may be much harder to reason about or debug.\n> > >\n> >\n> > I\'m wary of trying to get too deep on optimization this early. There\n> > are some blanket optimizations that you allude to here that I think will\n> > likely work o-k with even the most minimal of clues.\n> \n> +1 premature optimisation and the root of all evil...\n> \n> > > 3: APIs\n> r the same operation, but this would\n> > > be non-deterministic.\n> >\n> > Agreed, I think Ironic needs _some_ level of grouping to be efficient.\n> \n> What makes you think this? Ironic runs in the same data centre as Nova...\n> It it takes 20000 Api calls to boot 10000 physical machines is that really\n> a performance problem? When other that first power on would you do that\n> anyway?\n> \n\nThe API calls are meh. The image distribution and power fluctuations\nmay not be.\n\n> > > - Moving group-awareness or group-operations into the lower layers (eg,\n> > > Ironic) looks like it will require non-trivial changes to Heat and Nova,\n> > > and, in my opinion, violates a layer-constraint that I would like to\n> > > maintain. On the other hand, we could avoid the challenges around\n> > > coalescing. This might be necessary to support physically-grouped\n> hardware\n> > > anyway, too.\n> > >\n> >\n> > I actually think that the changes to Heat and Nova are trivial. Nova\n> > needs to have groups for compute nodes and the API needs to accept those\n> > groups. Heat needs to take advantage of them via the API.\n> \n> The changes to Nova would be massive and invasive as they would be\n> redefining the driver api....and all the logic around it.\n> \n\nI\'m not sure I follow you at all. I\'m suggesting that the scheduler have\na new thing to filter on, and that compute nodes push their unique ID\ndown into the Ironic driver so that while setting up nodes in Ironic one\ncan assign them to a compute node. That doesn\'t sound massive and\ninvasive.\n\n> > There is a non-trivial follow-on which is a \"wholistic\" scheduler which\n> > would further extend these groups into other physical resources like\n> > networks and block devices. These all feel like logical evolutions of the\n> > idea of making somewhat arbitrary and overlapping groups of compute nodes.\n> \n> The holistic scheduler can also be a holistic reserver plus reservation\n> aware scheduler -this avoids a lot of pain imo\n\nI think what I said still applies with that model, but it definitely\nbecomes a lot more robust.\n\n\n','<CAJ3HoZ2B6qyzJYzLCTB2zAjEK4jW29+Hf-S2cU-9_mJPPFvN2Q@mail.gmail.com>',NULL),('<1390662398-sup-2347@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-25 07:11:22',-28800,'2014-01-25 15:11:22',NULL,'[openstack-dev] [Ironic] Node groups and multi-node operations','Excerpts from Robert Collins\'s message of 2014-01-25 02:47:42 -0800:\n> On 25 January 2014 19:42, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Robert Collins\'s message of 2014-01-24 18:48:41 -0800:\n> \n> >> > However, in looking at how Ironic works and interacts with Nova, it\n> >> > doesn\'t seem like there is any distinction of data per-compute-node\n> >> > inside Ironic.  So for this to work, I\'d have to run a whole bunch of\n> >> > ironic instances, one per compute node. That seems like something we\n> >> > don\'t want to do.\n> >>\n> >> Huh?\n> >>\n> >\n> > I can\'t find anything in Ironic that lets you group nodes by anything\n> > except chassis. It was not a serious discussion of how the problem would\n> > be solved, just a point that without some way to tie ironic nodes to\n> > compute-nodes I\'d have to run multiple ironics.\n> \n> I don\'t understand the point. There is no tie between ironic nodes and\n> compute nodes. Why do you want one?\n> \n\nBecause sans Ironic, compute-nodes still have physical characteristics\nthat make grouping on them attractive for things like anti-affinity. I\ndon\'t really want my HA instances \"not on the same compute node\", I want\nthem \"not in the same failure domain\". It becomes a way for all\nOpenStack workloads to have more granularity than \"availability zone\".\n\nSo if we have all of that modeled in compute-nodes, then when adding\nphysical hardware to Ironic one just needs to have something to model\nthe same relationship for each physical hardware node. We don\'t have to\ndo it by linking hardware nodes to compute-nodes, but that would be\ndoable for a first cut without much change to Ironic.\n\n> >> What makes you think this? Ironic runs in the same data centre as Nova...\n> >> It it takes 20000 Api calls to boot 10000 physical machines is that really\n> >> a performance problem? When other that first power on would you do that\n> >> anyway?\n> >>\n> >\n> > The API calls are meh. The image distribution and power fluctuations\n> > may not be.\n> \n> But there isn\'t a strong connection between API call and image\n> distribution - e.g. (and this is my current favorite for \'when we get\n> to optimising\') a glance multicast service - Ironic would just add\n> nodes to the relevant group as they are requested, and remove when\n> they complete, and glance can take care of stopping the service when\n> there are no members in the group.\n> \n\nI think we agree here. Entirely. :)\n\n> >> > I actually think that the changes to Heat and Nova are trivial. Nova\n> >> > needs to have groups for compute nodes and the API needs to accept those\n> >> > groups. Heat needs to take advantage of them via the API.\n> >>\n> >> The changes to Nova would be massive and invasive as they would be\n> >> redefining the driver api....and all the logic around it.\n> >>\n> >\n> > I\'m not sure I follow you at all. I\'m suggesting that the scheduler have\n> > a new thing to filter on, and that compute nodes push their unique ID\n> > down into the Ironic driver so that while setting up nodes in Ironic one\n> > can assign them to a compute node. That doesn\'t sound massive and\n> > invasive.\n> \n> I think we\'re perhaps talking about different things - in the section\n> you were answering, I thought he was talking about whether the API\n> should offer operations on arbitrary sets of nodes at once, or whether\n> each operation should be a separate API call vs what I now think you\n> were talking about which was whether operations should be able to\n> describe logical relations to other instances/nodes. Perhaps if we use\n> the term \'batch\' rather than \'group\' to talk about the\n> multiple-things-at-once aspect, and grouping to talk about the\n> primarily scheduler related problems of affinity / anti affinity etc,\n> we can avoid future confusion.\n> \n\nYes, thats a good point. I was talking about modeling failure domains\nonly.  Batching API requests seems like an entirely different thing.\n\n\n','<CAJ3HoZ04aE9SMpp0shYmRCJrvy2-8FyfpF4EXRZJAvjSLJAf2g@mail.gmail.com>',NULL),('<1390663412-sup-9007@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-25 07:28:25',-28800,'2014-01-25 15:28:25',NULL,'[openstack-dev] [Neutron] Relationship between Neutron LBaaS\n	and Libra','Excerpts from Vishvananda Ishaya\'s message of 2014-01-21 12:16:12 -0800:\n> \n> On Jan 19, 2014, at 8:19 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Thomas Herve\'s message of 2014-01-19 01:52:56 -0800:\n> >> \n> >>> Hi,\n> >>> \n> >>> I haven?t read through those (need to go spend time with family so replying\n> >>> quickly) but given the dates the planning phases for Quantum/Neutron LBaaS\n> >>> and Libra LBaaS were at the same time.\n> >>> \n> >>> There was an internal evaluation of the current LBaaS solutions done at the\n> >>> time and it was believed by the people evaluating that Atlas was a good\n> >>> place to start. I came in just as that evaluation had finished (late August\n> >>> 2012) and the decision was pretty much made. In retrospect I may have\n> >>> personally gone the Mirantis LBaaS as a starting point. But either way there\n> >>> were some good starting places.\n> >>> \n> >>> Libra was initially a few trees so history is hard to track, but we had\n> >>> something in production by December that year.\n> >>> \n> >>> In response to Alex, the Libra team in HP is growing (it is currently still\n> >>> pretty small) and that should help us have more engineers to work with the\n> >>> Neutron team. The current goal is to get 5.x out of the door which adds\n> >>> things like metering/billing support and then planning how we can integrate\n> >>> well with Neutron. I believe the Libra team have a few diagrams flying\n> >>> around on a mutually beneficial way of doing that.\n> >> \n> >> Hi Andrew,\n> >> \n> >> Thanks for the all the responses. I certainly didn\'t want to throw the blame at one of the team, but I think we should try to converge. In particular Neutron LBaaS would benefit greatly from having a big deployment like HP. I hope the 2 teams can find a way to collaborate.\n> >> \n> >> There are benefits to have a different endpoint like Libra proposes, although now that LBaaS is integrated in Neutron it\'s going to be difficult to change. There is a tension in OpenStack currently between keeping the projects lean (by having small, independent code bases) and making deployments easy (by not having to deploy dozens of projects). I feel we haven\'t found a great answer yet.\n> >> \n> > \n> > I actually don\'t think having less services makes deployment easier.\n> > If you\'re not using automation, sure, its harder to install a bunch of\n> > things, but I don\'t think OpenStack should waste any time for people\n> > stuck in the 1990\'s. If you have automation, LBaaS as its own service\n> > is identical to LBaaS as a neutron agent.\n> \n> I?m sorry but this comment flatly ignores a huge amount of work. Let me point\n> out a few of the costs of adding a new service:\n> \n>  * Gating costs\n\nGating on an agent with a private RPC API inside Neutron doesn\'t seem\nall that different to gating a public API service and an agent with a\nprivate RPC API outside Neutron.\n\n>  * Packaging costs\n>  * Automation script costs\n> \n> These are non-trivial costs, and many of them are paid multiple times. A lot\n> of deployers maintain their own packages, and automation scripts need to be\n> written in many different forms (chef, pupput, salt, custom).\n\nSaid costs are nearly identical IMO for the same reason. You\'re either\nadding a neutron-lbaas-agent package, or a libra package. Same for\nautomation scripts. It is always \"deploying something different\".\n\nTo be clear though, I like LBaaS in Neutron. I just don\'t agree that\nmore services makes things cost more in the long run. SOA wants an API\nfor anything that can operate and scale without the other pieces.\n\n\n','<2991C879-6932-4D1F-ADD2-D23F8681024D@gmail.com>',NULL),('<139073041.1350140.1395654987243.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-24 05:56:27',-14400,'2014-03-24 09:56:27',NULL,'[Openstack-docs] Convention on <screen> use','Unless there are comments, I prefer one screen. Always seems to just add bloat otherwise, and it\'s not what the user actually sees. \n\nJust 2 cents though, \nSummer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: \"Andreas Jaeger\" <aj at suse.com>\n> Cc: \"openstack-docs\" <openstack-docs at lists.openstack.org>\n> Sent: Friday, March 21, 2014 11:15:24 PM\n> Subject: Re: [Openstack-docs] Convention on <screen> use\n\n> On Fri, Mar 21, 2014 at 3:52 AM, Andreas Jaeger < aj at suse.com > wrote:\n\n> > On 03/20/2014 09:37 PM, Diane Fleming wrote:\n> \n> > > But I\'m willing to go along with the consensus on this. And I totally\n> \n> > > agree that we need to have one convention that we all use.\n> \n> > >\n> \n> > > But here\'s why I like two screens:\n> \n> > >\n> \n> > > 1. You can insert text between the user input and the computer output,\n> \n> > > such an explanation of what the user might see in the output.\n> \n\n> > You still can do this, I see no problem with that.\n> \n\n> In the Ops Guide, we standardized on one screen wrapping <userinput> and\n> <computeroutput> but even so it was causing oddities with their transforms.\n\n> I\'d prefer <screen> around each.\n\n> Thanks,\n> Anne\n\n> > Andreas\n> \n> > --\n> \n> > Andreas Jaeger aj@{ suse.com , opensuse.org } Twitter/Identica: jaegerandi\n> \n> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n> \n> > GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n> \n> > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126\n> \n\n> > _______________________________________________\n> \n> > Openstack-docs mailing list\n> \n> > Openstack-docs at lists.openstack.org\n> \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140324/9f7c65da/attachment.html>\n\n','<CAD0KtVGMCCMMchE6G10acBFOoQGGsJDQTqVfK8hF-RvASZa1uw@mail.gmail.com>',NULL),('<1390749635.31865.4.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-26 10:20:35',-18000,'2014-01-26 15:20:35',NULL,'[openstack-dev] [glance]A question abount the\n x-image-meta-property parameter.','On Sun, 2014-01-26 at 18:48 +0800, Fei Long Wang wrote:\n> Hi Wang Hong,\n> \n> Good catch. I think the issue is caused by line 244-246, see\n> https://github.com/openstack/glance/blob/master/glance/common/utils.py#L244 For the case-matter issue, I think it\'s a bug. But as for the - to _, I would like to listen Jay\'s opinion since who is the original author. And obviously, it\'s intentional change.\n\nHi Wang Hong adnd Fei Long,\n\nIt\'s been a long time since I wrote that :) To be honest, I\'m not sure\nwhy -- other than just standardizing/normalizing the input, we did that.\nPerhaps it had something to do with vendor-specific properties that had\na prefix that used hyphens, but I\'m really not sure... perhaps I am\ngetting too old :)\n\nBest,\n-jay\n\n> Inactive hide details for ?? ---01/26/2014 05:14:02 PM---Hi all. If\n> I use the following command to create an image:?? ---01/26/2014\n> 05:14:02 PM---Hi all. If I use the following command to create an\n> image:\n> \n> From: ?? <w.wanghong1 at gmail.com>\n> To: openstack-dev at lists.openstack.org, \n> Date: 01/26/2014 05:14 PM\n> Subject: [openstack-dev] [glance]A question abount the\n> x-image-meta-property parameter.\n> \n> \n> \n> ______________________________________________________________________\n> \n> \n> \n> Hi all.\n> \n> If I use the following command to create an image: \n> curl -i -H \"X-Auth-Token:268c536db05b435bb6e631158744e3f6\" -H\n> \"x-image-meta-property-IMAGE-TYPE:xxx\" -H \"x-image-meta-name:test\" -X\n> POST http://127.0.0.1:9292/v1/images\n> \n> I will get the following results:\n> {\"image\": {\"status\": \"queued\", \"deleted\": false, \"container_format\":\n> null, \"min_ram\": 0, \"updated_at\": \"2014-01-26T08:51:54\", \"owner\":\n> \"9a38c1cda5344dd288331b988739c834\", \"min_disk\": 0, \"is_public\": false,\n> \"deleted_at\": null, \"id\": \"696ab97d-0e6f-46f1-8570-b6db707a748b\",\n> \"size\": 0, \"name\": \"test\", \"checksum\": null, \"created_at\":\n> \"2014-01-26T08:51:54\", \"disk_format\": null, \"properties\":\n> {\"image_type\": \"xxx\"}, \"protected\": false}}\n> \n> The capital letters in the property will be converted to lowercase\n> letters and \"-\" will be converted to \"_\"(\"IMAGE-TYPE\"=>\"image_type\").\n> \n> Is it a bug? Thanks.\n> \n> Best regards.\n> wanghong_______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<OFDD2FA76D.D3A37D40-ON48257C6C.003AC25A-48257C6C.003B6363@cn.ibm.com>',NULL),('<1390749895.31865.8.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-26 10:24:55',-18000,'2014-01-26 15:24:55',NULL,'[openstack-dev] Fw: [Glance] Is the \'killed\' state ever set in\n v2?','On Sun, 2014-01-26 at 06:36 -0800, Mark Washenberger wrote:\n> It does not seem very ReSTful--or very usable, for that matter--for a\n> resource to be permanently modified when you a PUT fails.\n\nHow so? What is not RESTful about changing the status of a resource\nbased on a PUT call?\n\n>  So I don\'t think we need the \'killed\' status. It was purposefully\n> left out of v2 images, which is not just a reskin of v1.\n\nNot arguing whether the killed status is good or not, but how does the\nV2 API indicate that an image is in some partial or error\'d state? FYI,\nthe image cache middleware, IIRC, looks for the specific state changes\nin images in determining when images move from when cache directory to\nanother (which in turn indicates which images are good to return to a\ncaller)...\n\n> Perhaps there is still a bug where an image is getting stuck in\n> \'saving\' or some other state when a PUT fails?\n\nThis was what the killed status was for.\n\nBest,\n-jay\n\n> \n> On Sun, Jan 26, 2014 at 5:10 AM, David Koo <kpublicmail at gmail.com>\n> wrote:\n>         \n>         Hi Fei,\n>         \n>             Thanks for the confirmation.\n>         \n>         > I think you\'re right. The \'killed\' status should be set in\n>         method upload()\n>         > if there is an upload failure, see\n>         >\n>         https://github.com/openstack/glance/blob/master/glance/common/utils.py#L244\n>         \n>         \n>         I think you meant:\n>         \n>         \n>         https://github.com/openstack/glance/blob/master/glance/api/v1/upload_utils.py#L244\n>         \n>         (the safe_kill() call) right?\n>         \n>         --\n>         Koo\n>         \n>         \n>         > ------------------ Original ------------------\n>         > From:  \"David Koo\"<kpublicmail at gmail.com>;\n>         > Date:  Jan 26, 2014\n>         > To:  \"OpenStack Development Mailing\n>         > List\"<openstack-dev at lists.openstack.org>;\n>         > Subject:  [openstack-dev] [Glance] Is the \'killed\' state\n>         ever set in v2?\n>         >\n>         > Hi All,\n>         >\n>         > While trying to work on a bug I was trying to simulate some\n>         image\n>         > download failures and found that apparently the \'killed\'\n>         state is never\n>         > set using v2 APIs.\n>         >\n>         > If I understand correctly, a file upload goes to\n>         > api.v2.image_data.ImageDataController.upload and goes all\n>         the way to\n>         > store.ImageProxy.set_data which proceeds to write to the\n>         backend store.\n>         >\n>         > If the backend store raises an exception it is simply\n>         propagated all the\n>         > way up. The notifier re-encodes the exceptions (which is the\n>         bug I was\n>         > looking at) but doesn\'t do anything about the image status.\n>         >\n>         > Nowhere does the image status seem to get set to \'killed\'.\n>         >\n>         > Before I log a bug I just wanted to confirm with everybody\n>         whether or\n>         > not I\'ve missed out on something.\n>         >\n>         > Thanks.\n>         >\n>         > --\n>         > Koo\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAJyP2C9F92pQbrqKBvX6d9hD-C6w_Cc2jg2nHWmf6pvk40TkBg@mail.gmail.com>',NULL),('<1390762359-sup-2583@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-26 12:12:08',-28800,'2014-01-26 20:12:08',NULL,'[openstack-dev] [Ironic] Node groups and multi-node operations','Excerpts from Devananda van der Veen\'s message of 2014-01-26 10:27:36 -0800:\n> On Sat, Jan 25, 2014 at 7:11 AM, Clint Byrum <clint at fewbar.com> wrote:\n> >\n> > Excerpts from Robert Collins\'s message of 2014-01-25 02:47:42 -0800:\n> > > On 25 January 2014 19:42, Clint Byrum <clint at fewbar.com> wrote:\n> > > > Excerpts from Robert Collins\'s message of 2014-01-24 18:48:41 -0800:\n> > >\n> > > >> > However, in looking at how Ironic works and interacts with Nova, it\n> > > >> > doesn\'t seem like there is any distinction of data per-compute-node\n> > > >> > inside Ironic.  So for this to work, I\'d have to run a whole bunch of\n> > > >> > ironic instances, one per compute node. That seems like something we\n> > > >> > don\'t want to do.\n> > > >>\n> > > >> Huh?\n> > > >>\n> > > >\n> > > > I can\'t find anything in Ironic that lets you group nodes by anything\n> > > > except chassis. It was not a serious discussion of how the problem would\n> > > > be solved, just a point that without some way to tie ironic nodes to\n> > > > compute-nodes I\'d have to run multiple ironics.\n> > >\n> > > I don\'t understand the point. There is no tie between ironic nodes and\n> > > compute nodes. Why do you want one?\n> > >\n> >\n> > Because sans Ironic, compute-nodes still have physical characteristics\n> > that make grouping on them attractive for things like anti-affinity. I\n> > don\'t really want my HA instances \"not on the same compute node\", I want\n> > them \"not in the same failure domain\". It becomes a way for all\n> > OpenStack workloads to have more granularity than \"availability zone\".\n> \n> Yes, and with Ironic, these same characteristics are desirable but are\n> no longer properties of a nova-compute node; they\'re properties of the\n> hardware which Ironic manages.\n> \n\nI agree, but I don\'t see any of that reflected in Ironic\'s API. I see\nnode CRUD, but not filtering or scheduling of any kind.\n\n> In principle, the same (hypothetical) failure-domain-aware scheduling\n> could be done if Ironic is exposing the same sort of group awareness,\n> as long as the nova \'ironic\" driver is passing that information up to\n> the scheduler in a sane way. In which case, Ironic would need to be\n> representing such information, even if it\'s not acting on it, which I\n> think is trivial for us to do.\n> \n> >\n> > So if we have all of that modeled in compute-nodes, then when adding\n> > physical hardware to Ironic one just needs to have something to model\n> > the same relationship for each physical hardware node. We don\'t have to\n> > do it by linking hardware nodes to compute-nodes, but that would be\n> > doable for a first cut without much change to Ironic.\n> >\n> \n> You\'re trading failure-domain awareness for fault-tolerance in your\n> control plane. by binding hardware to nova-compute. Ironic is designed\n> explicitly to decouple the instances of Ironic (and Nova) within the\n> control plane from the hardware it\'s managing. This is one of the main\n> shortcomings of nova baremetal, and it doesn\'t seem like a worthy\n> trade, even for a first approximation.\n> \n> > > >> The changes to Nova would be massive and invasive as they would be\n> > > >> redefining the driver api....and all the logic around it.\n> > > >>\n> > > >\n> > > > I\'m not sure I follow you at all. I\'m suggesting that the scheduler have\n> > > > a new thing to filter on, and that compute nodes push their unique ID\n> > > > down into the Ironic driver so that while setting up nodes in Ironic one\n> > > > can assign them to a compute node. That doesn\'t sound massive and\n> > > > invasive.\n> \n> This is already being done *within* Ironic as nodes are mapped\n> dynamically to ironic-conductor instances; the coordination for\n> failover/takeover needs to be improved, but that\'s incremental at this\n> point. Moving this mapping outside of Ironic is going to be messy and\n> complicated, and breaks the abstraction layer. The API change may seem\n> small, but it will massively overcomplicate Nova by duplicating all\n> the functionality of Ironic-conductor in another layer of the stack.\n> \n\nCan you point us to the design for this? I didn\'t really get that\nfrom browsing the code and docs, and I gave up trying to find a single\narchitecture document after very little effort.\n\n\n','<CAExZKEpUE+f_exUfJq+VFG7JLCY5qhr3Le-T1T4M6O8QxOaNPQ@mail.gmail.com>',NULL),('<1390776282.31865.40.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-26 17:44:42',-18000,'2014-01-26 22:44:42',NULL,'[openstack-dev] [Neutron] Representing PEM Format file as string','On Sun, 2014-01-26 at 16:36 -0600, Rajesh_Mohan3 at Dell.com wrote:\n> I am working on SSL VPN BP.\n> \n> CA certificate is one of the resources. We decided to use PEM formatted certificates. It is multi-line string \n> \n>   1 -----BEGIN CERTIFICATE-----\n>   2 MIID3TCCA0agAwIBAgIJAKRWnul3NJnrMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYD\n>  <snip>\n>  21 0vO728pEcn6QtOpU7ZjEv8JLKRHwyq8kwd8gKMflWZRng4R2dj3cdd24oYJxn5HW\n>  22 atXnq+N9H9dFgMfw5NNefwJrZ3zAE6mu0bAIoXVsKT2S\n>  23 -----END CERTIFICATE-----\n> \n> Is there a standard way to represent this as single line string? \n\nNo. The standard representation is not a single-line string :)\n\n> Maybe there is some other project that passes certificates on command line/url. \n\nYou should instead pass the filename on the command line. You should not\npass the value of the certificate in a URL.\n\nBest,\n-jay\n\n> I am looking for some accepted way to represent PEM formatted file on command line. \n> \n> I am thinking of concatenating all lines into single string and rebuilding the file when configuration file is generated.Will we hit any CLI size limitations if we pass long strings.\n> \n> Thanks,\n> -Rajesh Mohan\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<9B2A0C1C0939BE47BACEEF9D76C9F4A84F38E96927@AUSX7MCPS310.AMER.DELL.COM>',NULL),('<1390809610.7492.YahooMailNeo@web142305.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-27 00:00:10',-28800,'2014-01-27 08:00:10',NULL,'[Openstack] Need help on openstack mellanox quantum plugin setup','Hi there!\n\nI have setup a compute node with openstack networking enabled by the mellanox neutron plugin on RH6.4. I have enabled SR-IOV and created 4 VFs. They all show up in ifconfig. I tried creating an instance using \'nova boot\' command. However it is in error state.\n\nI created network, subnet and ports successfully by following this doc:\nhttp://www.mellanox.com/related-docs/applications/Mellanox-OpenStack-Solution-for-Red-Hat.pdf\n\nI created an instance using following command:\nnova boot --flavor 1 --image 7f8460fd-6928-49ae-bef8-055a1de3e39a cirrOS --nic port-id=98f537b2-27dc-4583-ad1a-85edbd74987a\n\nThe instance was in error state and eswitchd.log shows this:\n2014-01-26 09:41:36,549 DEBUG PF eth4, eths=[\'eth6\', \'eth7\', \'eth8\', \'eth9\'], vfs=[]\n- - - - - - - - - - - - truncated - - - - - - - - - - - -\n2014-01-26 10:43:13,320 DEBUG vnics are {}\n2014-01-26 10:43:13,746 DEBUG Handling message - {u\'action\': u\'get_vnics\', u\'fabric\': u\'*\'}\n2014-01-26 10:43:13,746 DEBUG fabrics =[\'default\']\n2014-01-26 10:43:13,747 DEBUG vnics are {}\n2014-01-26 10:43:14,565 DEBUG Handling message - {u\'fabric\': u\'default\', u\'dev_name\': None, u\'vnic_type\': u\'hostdev\', u\'action\': u\'create_port\', u\'vnic_mac\': u\'fa:16:3e:c9:c2:23\', u\'device_id\': u\'e106da24-9b10-4c4c-87a0-66276f025c6e\'}\n2014-01-26 10:43:14,565 ERROR exception on device allocation on dev? None - No available resources.\n2014-01-26 10:43:14,566 ERROR Create port operation failed\n\nMy queries are:\n??? - Does my setup look ok?\n??? - I guess since I am using SR-IOV, the adapter is presenting VFs as PFs to OS. Is this understanding correct?\n??? - vfs list is empty (Log says vfs=[]). Is this OK?\n\nPlease comment/advise on what could be the issue.\n\nThanks,\nNishant\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140127/2ad6806f/attachment.html>\n\n',NULL,NULL),('<1390835667.36225222@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 09:14:27',-21600,'2014-01-27 15:14:27',NULL,'[openstack-dev] [Solum] Proposed changes to solum-core','+1\n\n\n-----Original Message-----\nFrom: \"Murali Allada\" <murali.allada at RACKSPACE.COM>\nSent: Sunday, January 26, 2014 8:19pm\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nCc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Solum] Proposed changes to solum-core\n\n+1 \n\n\n\n> On Jan 25, 2014, at 9:04 AM, \"Roshan Agrawal\" <roshan.agrawal at RACKSPACE.COM> wrote:\n> \n> +1\n> ________________________________________\n> From: Rajesh Ramchandani [rajesh.ramchandani at cumulogic.com]\n> Sent: Friday, January 24, 2014 9:35 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Cc: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Solum] Proposed changes to solum-core\n> \n> +1\n> \n>> On Jan 24, 2014, at 5:35 PM, \"Adrian Otto\" <adrian.otto at rackspace.com> wrote:\n>> \n>> Solum Core Reviewers,\n>> \n>> I propose the following changes to solum-core:\n>> \n>> +asalkeld\n>> +noorul\n>> -mordred\n>> \n>> Thanks very much to mordred for helping me to bootstrap the reviewer team. Please reply with your votes.\n>> \n>> Thanks,\n>> \n>> Adrian\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<2D38BEE7-5EF9-44D2-A925-33FEEC227DA6@RACKSPACE.COM>',NULL),('<1390843957-sup-8970@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 09:48:23',-28800,'2014-01-27 17:48:23',NULL,'[openstack-dev] [TripleO] State preserving upgrades working,\n	next MVP selection?','Excerpts from Dan Prince\'s message of 2014-01-27 09:22:21 -0800:\n> \n> ----- Original Message -----\n> > From: \"Robert Collins\" <robertc at robertcollins.net>\n> > To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> > Sent: Sunday, January 26, 2014 3:30:22 PM\n> > Subject: [openstack-dev] [TripleO] State preserving upgrades working,    next MVP selection?\n> > \n> > So great news - we\'ve now got state preserving upgrades actually\n> > working - we can now upgrade a deployed cloud (with downtime) without\n> > tossing away all the users valuable data. Yay. This isn\'t entirely\n> > done as we have a couple of outstanding patches we\'re running early\n> > versions of, but - still, it\'s time to pick a new focus.\n> > \n> > So we need to pick the next step to focus on. In our roadmap we have:\n> > \n> > MVP4: Keep VMs running during deploys.\n> > \n> > This to my mind means two things:\n> >  - VMs need to not be interrupted\n> >  - network traffic needs to be uninterrupted\n> > \n> > Now, as the kernel can be upgraded in a deploy, this still requires us\n> > to presume that we may have to reboot a machine - so we\'re not at the\n> > point of focusing on high performance updates yet.\n> > \n> > Further consequences - we\'ll need two network nodes and two\n> > hypervisors, and live migration. 10m (the times-two reboot time for a\n> > server) is too long for the central DB to be down if we want\n> > neutron-agents not to get unhappy as well, so we\'ll really need two\n> > control plane nodes.\n> > \n> > So I think the next MVP needs the following cards:\n> >  - HA DB\n> >  - HA APIs\n> >  - rolling upgrades\n> >  - nova live migration\n> \n> It seems a bit fuzzy whether live migration violates the rules above\n> (no VM interruption, no network disruption). Live migration is certainly a\n> good feature to have in general... but wiring it into our upgrade strategy\n> seems like a bad idea. I would much rather see us put the effort into\n> an upgrade path which allows VMs to persist on the compute host machine\n> (uninterrupted) while the upgrade takes place. Live migrating things\n> back and forth all the time just seems like a thrashing, cool for a demo,\n> but bad idea in production sort of thing to me.\n> \n\nI\'m not sure I understand. You must terminate the VMs when you update\nthe kernel. Are you saying we should not handle kernel upgrades, or that\nwe should just focus on evacuation for kernel upgrades?\n\nEvacuation has the same problem, but with VM interruption added in. I\nthink we should actually offer either as an option, but we have to offer\none of them, or we\'ll have no way to update compute node kernels.\n\nThe non-kernel upgrade path is an order of magnitude easier, and we have\ndiscussed optimizations for it quite a bit already in other threads. We\'ll\nget to it. But leaving people without a way to upgrade the kernel on\ntheir compute nodes is not something I think we want to do.\n\n> \n> >  - neutron agent migration *or* neutron distributed-HA setup\n> >  - scale the heat template to have 2 control plane nodes\n> >  - scale the heat template to have 2 hypervisor nodes\n> \n> This is cool, especially for bare metal sorts of setups. For developers\n> though I would sort of like to consider a hybrid approach where we\n> still support a single control plan and compute (hypervisor) node for\n> the devtest scripts. Resources are just to limited to force everyone to\n> use HA setups by default, always. While HA is certainly important it is\n> only part of TripleO and there are many, things you might want to work\n> on without using it. So lets keep this as an optional production focused\n> sort of component.\n> \n\nI think that goes without saying. We can just develop in degraded mode. :)\n\n> > \n> > as a minimum - are these too granular or about right? I broke the heat\n> > template change into two because we can scale hypervisors right now,\n> > whereas control plane scaling will need changes and testing so that we\n> > only have one HA database created, not two non-HA setup in parallel\n> > :).\n> > \n> > I\'m going to put this into trello now, and will adjust as we discuss\n> > \n> > -Rob\n> > \n> > --\n> > Robert Collins <rbtcollins at hp.com>\n> > Distinguished Technologist\n> > HP Converged Cloud\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<2101942358.11634954.1390843341375.JavaMail.root@redhat.com>',NULL),('<1390848871.31865.97.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 13:54:31',-18000,'2014-01-27 18:54:31',NULL,'[openstack-dev] [Neutron] Representing PEM Format file as string','On Mon, 2014-01-27 at 10:49 -0800, Nachi Ueno wrote:\n> Hi Rajesh\n> \n> May I ask why we need single line representation of PEM format?\n> For CLI, we will use file_name as same as nova keypair-add.\n> We won\'t specify PEM on the URL.\n\n++\n\n-jay\n\n\n\n','<CABJepwh1RyTO=+EaV9QcjHn2C58Ci9=WC=R7Q4wb2p+v7ZT+qA@mail.gmail.com>',NULL),('<1390850493.31865.99.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 14:21:33',-18000,'2014-01-27 19:21:33',NULL,'[openstack-dev] [oslo] log message translations','On Mon, 2014-01-27 at 19:06 +0000, CARVER, PAUL wrote:\n> Joshua Harlow wrote:\n> >From what I know most all (correct me if I am wrong) open source projects\n> >don\'t translate log messages; so it seems odd to be the special snowflake\n> >project/s.\n> \n> >Do people find this type of translation useful?\n> \n> >It\'d be nice to know how many people really do so the benefit/drawbacks of\n> >doing it can be evaluated by real usage data.\n> \n> This is just a wild idea off the top of my head, but what about creating a log\n> translation service completely independent of running systems. Basically\n> I\'m thinking of a web based UI hosted on openstack.org where you can\n> upload a logfile or copy/paste log lines and receive it back in the language\n> of your choice.\n> \n> When googling for an error message it would definitely be better for\n> everyone to be using the same language because otherwise you\'ll\n> only find forum posts and so forth in your own language and probably\n> miss a solution posted in another language.\n> \n> But I can certainly see that some people might actually be able to figure\n> out problems for themselves if they could see the error in their native\n> language.\n> \n> So my idea is to log messages in English but create a standard way to\n> get a translated version.\n> \n> As a side effect, the usage of the web based translator server would\n> give a way to answer your question about how many people use it.\n> If it doesn\'t get any usage then people can stop investing the time in\n> creating the translations.\n\nHave you ever tried using Google Translate for anything more than very\nsimple phrases?\n\nThe results can be... well, interesting ;) And given the amount of\ntechnical terms used in these messages, I doubt GT or any automated\ntranslating service would provide a whole lot of value...\n\nBest,\n-jay\n\n\n\n','<A81F249089B6C7479786834457908C600AC2526D@MISOUT7MSGUSR9N.ITServices.sbc.com>',NULL),('<1390854989.31865.111.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 15:36:29',-18000,'2014-01-27 20:36:29',NULL,'[openstack-dev] Proposed Logging Standards','On Mon, 2014-01-27 at 08:07 -0500, Sean Dague wrote:\n> Back at the beginning of the cycle, I pushed for the idea of doing some\n> log harmonization, so that the OpenStack logs, across services, made\n> sense. I\'ve pushed a proposed changes to Nova and Keystone over the past\n> couple of days.\n> \n> This is going to be a long process, so right now I want to just focus on\n> making INFO level sane, because as someone that spends a lot of time\n> staring at logs in test failures, I can tell you it currently isn\'t.\n> \n> https://wiki.openstack.org/wiki/LoggingStandards is a few things I\'ve\n> written down so far, comments welcomed.\n> \n> We kind of need to solve this set of recommendations once and for all up\n> front, because negotiating each change, with each project, isn\'t going\n> to work (e.g - https://review.openstack.org/#/c/69218/)\n> \n> What I\'d like to find out now:\n> \n> 1) who\'s interested in this topic?\n> 2) who\'s interested in helping flesh out the guidelines for various log\n> levels?\n> 3) who\'s interested in helping get these kinds of patches into various\n> projects in OpenStack?\n> 4) which projects are interested in participating (i.e. interested in\n> prioritizing landing these kinds of UX improvements)\n> \n> This is going to be progressive and iterative. And will require lots of\n> folks involved.\n\nI\'m interested, can contribute patches (feel free to assign me) and can\ndo reviews.\n\nBest,\n-jay\n\n\n\n','<52E65A26.2060505@dague.net>',NULL),('<1390856521.2343.84.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 16:02:01',-18000,'2014-01-27 21:02:01',NULL,'[openstack-dev] [savanna] savannaclient v2 api','We should consider turning \"mains\" into a string instead of a list for\nv2.\n\nHive and Pig Oozie actions use mains, and each may only specify a single\n<script> element.  There is no utility akaik for having multiple mains\nassociated with a job.\n\nWorkflows with multiple actions might need multiple mains, but those\nhaven\'t been designed at this point.\n\nBest,\n\nTrevor\n\nOn Tue, 2014-01-14 at 12:24 -0500, Matthew Farrellee wrote:\n> https://blueprints.launchpad.net/savanna/+spec/v2-api\n> \n> I\'ve finished a review of the v1.0 and v1.1 APIs with an eye to making \n> them more consistent and RESTful.\n> \n> Please use this thread to comment on my suggestions for v1.0 & v1.1, or \n> to make further suggestions.\n> \n> Best,\n> \n> \n> matt\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<52D572BF.7070502@redhat.com>',NULL),('<1390860256.16278.9.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 14:04:16',-28800,'2014-01-27 22:04:16',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','On Mon, 2014-01-27 at 14:58 +0000, Robert Li (baoli) wrote:\n> Hi Folks,\n> \n> \n> In today\'s meeting, we discussed a scheduler issue for SRIOV. The\n> basic requirement is for coexistence of the following compute nodes in\n> a cloud:\n>       -- SRIOV only compute nodes\n>       -- non-SRIOV only compute nodes\n>       -- Compute nodes that can support both SRIOV and non-SRIOV\n> ports. Lack of a proper name, let\'s call them compute nodes with\n> hybrid NICs support, or simply hybrid compute nodes.\n> \n> \n> I\'m not sure if it\'s practical in having hybrid compute nodes in a\n> real cloud. But it may be useful in the lab to bench mark the\n> performance differences between SRIOV, non-SRIOV, and coexistence of\n> both.\n> \n> \n> In a cloud that supports SRIOV in some of the compute nodes, a request\n> such as:\n> \n> \n>      nova boot ?flavor m1.large ?image <image-uuid> --nic\n> net-id=<net-uuid> vm\n> \n> \n> doesn\'t require a SRIOV port. However, it\'s possible for the nova\n> scheduler to place it on a compute node that supports sriov port only.\n> Since neutron plugin runs on the controller, port-create would succeed\n> unless neutron knows the host doesn\'t support non-sriov port. But\n> connectivity on the node would not be established since no agent is\n> running on that host to establish such connectivity. \n> \n> \n> Irena brought up the idea of using host aggregate. This requires\n> creation of a non-SRIOV host aggregate, and use that in the above\n> \'nova boot\' command. It should work.\n> \n> \n> The patch I had introduced a new constraint in the existing PCI\n> passthrough filter. \n> \n> \n> The consensus seems to be having a better solution in a later release.\n> And for now, people can either use host aggregate or resort to their\n> own means.\n> \n> \n> Let\'s keep the discussion going on this. \n> \n> \n> Thanks,\n> Robert\n> \n> \n>  \n> \n> \n> \n> \n> \n> \n> On 1/24/14 4:50 PM, \"Robert Li (baoli)\" <baoli at cisco.com> wrote:\n> \n> \n>         Hi Folks,\n>         \n>         \n>         Based on Thursday\'s discussion and a chat with Irena, I took\n>         the liberty to add a summary and discussion points for SRIOV\n>         on Monday and onwards. Check it\n>         out https://wiki.openstack.org/wiki/Meetings/Passthrough.\n>         Please feel free to update it. Let\'s try to finalize it next\n>         week. The goal is to determine the BPs that need to get\n>         approved, and to start coding. \n>         \n>         \n>         thanks,\n>         Robert\n>         \n>         \n>         \n>         \n>         On 1/22/14 8:03 AM, \"Robert Li (baoli)\" <baoli at cisco.com>\n>         wrote:\n>         \n>         \n>                 Sounds great! Let\'s do it on Thursday.\n>                 \n>                 \n>                 --Robert\n>                 \n>                 \n>                 On 1/22/14 12:46 AM, \"Irena Berezovsky\"\n>                 <irenab at mellanox.com> wrote:\n>                 \n>                 \n>                         Hi Robert, all,\n>                         \n>                         I would suggest not to delay the SR-IOV\n>                         discussion to the next week.\n>                         \n>                         Let?s try to cover the SRIOV side and\n>                         especially the nova-neutron interaction points\n>                         and interfaces this Thursday.\n>                         \n>                         Once we have the interaction points well\n>                         defined, we can run parallel patches to cover\n>                         the full story.\n>                         \n>                          \n>                         \n>                         Thanks a lot,\n>                         \n>                         Irena \n>                         \n>                          \n>                         \n>                         From: Robert Li (baoli)\n>                         [mailto:baoli at cisco.com] \n>                         Sent: Wednesday, January 22, 2014 12:02 AM\n>                         To: OpenStack Development Mailing List (not\n>                         for usage questions)\n>                         Subject: [openstack-dev] [nova][neutron] PCI\n>                         passthrough SRIOV\n>                         \n>                         \n>                          \n>                         \n>                         Hi Folks,\n>                         \n>                         \n>                          \n>                         \n>                         \n>                         As the debate about PCI flavor versus host\n>                         aggregate goes on, I\'d like to move forward\n>                         with the SRIOV side of things in the same\n>                         time. I know that tomorrow\'s IRC will be\n>                         focusing on the BP review, and it may well\n>                         continue into Thursday. Therefore, let\'s start\n>                         discussing SRIOV side of things on Monday. \n>                         \n>                         \n>                          \n>                         \n>                         \n>                         Basically, we need to work out the details on:\n>                         \n>                         \n>                                 -- regardless it\'s PCI flavor or host\n>                         aggregate or something else, how to use it to\n>                         specify a SRIOV port. \n>                         \n>                         \n>                                 -- new parameters for ?nic\n>                         \n>                         \n>                                 -- new parameters for neutron\n>                         net-create/neutron port-create\n>                         \n>                         \n>                                 -- interface between nova and neutron\n>                         \n>                         \n>                                 -- nova side of work\n>                         \n>                         \n>                                 -- neutron side of work\n>                         \n>                         \n>                          \n>                         \n>                         \n>                         We should start coding ASAP.\n>                         \n>                         \n>                          \n>                         \n>                         \n>                         Thanks,\n>                         \n>                         \n>                         Robert\n>                         \n>                         \n>                          \n>                         \n>                         \n>                          \n>                         \n>                         \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI noticed that you discussed that prefer non-SRIOV compute node to SRIOV\ncompute node. I think that should be achieved through weight?\n\nThanks\n--jyh\n\n\n\n','<CF0BD58F.3C6D8%baoli@cisco.com>',NULL),('<1390862442.16278.13.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 14:40:42',-28800,'2014-01-27 22:40:42',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','On Mon, 2014-01-27 at 22:31 +0100, Ian Wells wrote:\n> In any case, as discussed in the meeting, this is an optimisation and\n> not something we have to solve in the initial release, because:\n>   \n\n+1 for this. We should keep it as future enhancement effort.\n\n--jyh\n\n\n\n','<CAPoubz5BuFJ=-YHk9ynzDEMKwfe78WYdbX2YM=BL2DEQgQbcpw@mail.gmail.com>',NULL),('<1390862538.16278.15.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 14:42:18',-28800,'2014-01-27 22:42:18',NULL,'[openstack-dev] [nova][neutron] PCI pass-through SRIOV','On Mon, 2014-01-27 at 21:14 +0000, Jani, Nrupal wrote:\n> Hi,\n> \n>  \n> \n> There are two possibilities for the hybrid compute nodes\n> \n> -         In the first case, a compute node has two NICs,  one SRIOV\n> NIC & the other NIC for the VirtIO\n> \n> -         In the 2nd case, Compute node has only one SRIOV NIC, where\n> VFs are used for the VMs, either macvtap or direct assignment.  And\n> the PF is used for the uplink to the linux bridge or OVS!!\n> \n>  \n> \n> My question to the team is whether we consider both of these\n> deployments or not?\n> \nNrupal, good question. I assume if a NIC will be used for vNIC type, it\nwill not be reported by hypervisor as assignable PCI devices since host\nwill own it and the OVS is setup based on it.\n\nIrena/Ian, please correct me. At least this is assumption in nova PCI\ncode, I think.\n\nThanks\n--jyh \n\n\n\n','<096DE3A060628644893976A610FDE6F26B89A300@FMSMSX154.amr.corp.intel.com>',NULL),('<1390881416.33636.YahooMailNeo@web142305.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-27 19:56:56',-28800,'2014-01-28 03:56:56',NULL,'[Openstack] Need help on openstack mellanox quantum plugin setup','Hey Irena,\n\nThanks for your reply. I will try what you suggested.\n\n\nI couldn\'t find instructions directly under the link you provided. I think you meant this:\nhttp://community.mellanox.com/docs/DOC-1317\n\nI got it from the mellanox community.\n\n?\nThanks,\nNishant\n\n\n\nOn Monday, January 27, 2014 2:26 PM, Irena Berezovsky <irenab at mellanox.com> wrote:\n \nHi Nishant,\nMellanox plugin supports two types of VF provisioning , as pci passthrough (hostdev) and as macvtap (mlnx_direct) vNIC.\nAccording to the log, you want to use the first flavor (hostdev). \n?\nPlease follow the following instructions in: http://Community.mellanox.com/community/develop/ - After the installation perform the following changes for ?setting the ?probe_vf? ?option in mlx4_core. In case you want all VFs to be used in pci passthrough mode, set the probe_vf = 0.\n?\nIn case you need further assistance, please contact us at Openstack at mellanox.com\n?\nBest Regards,\nIrena\n?\n?\nFrom:nishant kumar [mailto:nishantkumar_2k at yahoo.com] \nSent: Monday, January 27, 2014 10:19 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Need help on openstack mellanox quantum plugin setup\n?\nHi there!\n\nI have setup a compute node with openstack networking enabled by the mellanox neutron plugin on RH6.4. I have enabled SR-IOV and created 4 VFs. They all show up in ifconfig. I tried creating an instance using \'nova boot\' command. However it is in error state.\n\nI created network, subnet and ports successfully by following this doc:\nhttp://www.mellanox.com/related-docs/applications/Mellanox-OpenStack-Solution-for-Red-Hat.pdf\n\nI created an instance using following command:\nnova boot --flavor 1 --image 7f8460fd-6928-49ae-bef8-055a1de3e39a cirrOS --nic port-id=98f537b2-27dc-4583-ad1a-85edbd74987a\n\nThe instance was in error state and eswitchd.log shows this:\n2014-01-26 09:41:36,549 DEBUG PF eth4, eths=[\'eth6\', \'eth7\', \'eth8\', \'eth9\'], vfs=[]\n- - - - - - - - - - - - truncated - - - - - - - - - - - -\n2014-01-26 10:43:13,320 DEBUG vnics are {}\n2014-01-26 10:43:13,746 DEBUG Handling message - {u\'action\': u\'get_vnics\', u\'fabric\': u\'*\'}\n2014-01-26 10:43:13,746 DEBUG fabrics =[\'default\']\n2014-01-26 10:43:13,747 DEBUG vnics are {}\n2014-01-26 10:43:14,565 DEBUG Handling message - {u\'fabric\': u\'default\', u\'dev_name\': None, u\'vnic_type\': u\'hostdev\', u\'action\': u\'create_port\', u\'vnic_mac\': u\'fa:16:3e:c9:c2:23\', u\'device_id\': u\'e106da24-9b10-4c4c-87a0-66276f025c6e\'}\n2014-01-26 10:43:14,565 ERROR exception on device allocation on dev? None - No available resources.\n2014-01-26 10:43:14,566 ERROR Create port operation failed\n\nMy queries are:\n??? - Does my setup look ok?\n??? - I guess since I am using SR-IOV, the adapter is presenting VFs as PFs to OS. Is this understanding correct?\n??? - vfs list is empty (Log says vfs=[]). Is this OK?\n\nPlease comment/advise on what could be the issue.\n\nThanks,\nNishant\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140127/c661b11c/attachment.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E77882FAD87@MTLDAG02.mtl.com>',NULL),('<1390890949.56727.YahooMailNeo@web163806.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 22:35:49',-28800,'2014-01-28 06:35:49',NULL,'[openstack-dev] [Solum] Proposed changes to solum-core','Congrats new reviewers\n\n\n\nOn Tuesday, January 28, 2014 8:54 AM, Noorul Islam Kamal Malmiyoda <noorul at noorul.com> wrote:\n \nOn Tue, Jan 28, 2014 at 2:30 AM, Adrian Otto <adrian.otto at rackspace.com> wrote:\n> Solum Core Reviewers,\n>\n> Thanks everyone for your feedback. I have made the adjustments. Welcome to the core group Angus and Noorul. Thanks again Monty.\n>\n\n\nThank you all for the votes.\n\nRegards,\nNoorul\n\n\n\n> On Jan 27, 2014, at 12:54 PM, Kurt Griffiths <kurt.griffiths at rackspace.com>\n>? wrote:\n>\n>> +1\n>>\n>> On 1/27/14, 11:54 AM, \"Monty Taylor\" <mordred at inaugust.com> wrote:\n>>\n>>> On 01/24/2014 05:32 PM, Adrian Otto wrote:\n>>>> Solum Core Reviewers,\n>>>>\n>>>> I propose the following changes to solum-core:\n>>>>\n>>>> +asalkeld\n>>>> +noorul\n>>>> -mordred\n>>>>\n>>>> Thanks very much to mordred for helping me to bootstrap the reviewer\n>>>> team. Please reply with your votes.\n>>>\n>>> +1\n>>>\n>>> My pleasure - you guys seem like you\'re off to the races -a nd asalkeld\n>>> and noorul are both doing great.\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140127/209d8c8f/attachment.html>\n\n','<CA+H4GH88AVwEzJE2OCWLGKFLVSHmQ513-dqqq=e+ZFXMVT67hA@mail.gmail.com>',NULL),('<1390919582-sup-7888@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 06:38:42',-28800,'2014-01-28 14:38:42',NULL,'[openstack-dev] [Ceilometer] [TripleO] adding process/service\n	monitoring','Excerpts from Richard Su\'s message of 2014-01-27 17:59:34 -0800:\n> Hi,\n> \n> I have been looking into how to add process/service monitoring to\n> tripleo. Here I want to be able to detect when an openstack dependent\n> component that is deployed on an instance has failed. And when a failure\n> has occurred I want to be notified and eventually see it in Tuskar.\n> \n> Ceilometer doesn\'t handle this particular use case today. So I have been\n> doing some research and there are many options out there that provides\n> process checks: nagios, sensu, zabbix, and monit. I am a bit wary of\n> pulling one of these options into tripleo. There is some increased\n> operational and maintenance costs when pulling in each of them. And\n> physical device monitoring is currently in the works for Ceilometer\n> lessening the need for some of the other abilities that an another\n> monitoring tool would provide.\n> \n> For the particular use case of monitoring processes/services, at a high\n> level, I am considering writing a simple daemon to perform the check.\n> Checks and failures are written out as messages to the notification bus.\n> Interested parties like Tuskar or Ceilometer can subscribe to these\n> messages.\n> \n> In general does this sound like a reasonable approach?\n\nWriting a new one, no. But using notifications in OpenStack: yes!\n\nI suggest finding the simplest one possible and teaching it to send\nOpenStack notifications.\n\n> \n> There is also the question of how to configure or figure out which\n> processes we are interested in monitoring. I need to do more research\n> here but I\'m considering either looking at the elements listed by\n> diskimage-builder or by looking at the orc post-configure.d scripts to\n> find service that are restarted.\n> \n\nThere are basically two things you need to look for: things listening,\nand things connected to rabbitmq/qpid.\n\nSo one crazy way to find things to monitor is to look at netstat or ss\nand just monitor processes doing one of those things. I believe\nassimilation monitoring\'s nanoprobe daemon already has the listening\npart done:\n\nhttp://techthoughts.typepad.com/managing_computers/2012/10/zero-configuration-discovery-and-server-monitoring-in-the-assimilation-monitoring-project.html\n\nAlso you may want to do two orc scripts in post-configure.d:\n\n00-disruption-coming-stop-process-monitor\n99-all-clear-start-process-monitor\n\nAnyway, as Robert says, just keep it modular so that orgs that already\nhave a rich set of tools for this will be able to replace it.\n\n\n','<52E70F06.7070500@redhat.com>',NULL),('<1390925301.853827263@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-01-28 10:08:21',-21600,'2014-01-28 16:08:21',NULL,'[openstack-community] OpenStack Booth and Job Board at PyCon 2014','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140128/9bffd821/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: OpenStack job board.jpg\nType: image/jpeg\nSize: 112185 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140128/9bffd821/attachment-0001.jpg>\n\n',NULL,NULL),('<1390927350.31865.155.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 11:42:30',-18000,'2014-01-28 16:42:30',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology\n	Revival	#1	-	Roles','On Tue, 2014-01-28 at 10:02 -0500, Tzu-Mainn Chen wrote:\n> Yep, although the reason why - that no end-user will know what these terms mean -\n> has never been entirely convincing to me.\n\nWell, tenants would never see any of the Tuskar UI, so I don\'t think we\nneed worry about them. And if a deployer is enabling Tuskar -- and using\nTuskar/Triple-O for undercloud deployment -- then I would think that the\ndeployer would understand the concept/terminology of undercloud and\novercloud, since it\'s an essential concept in deploying with\nTriple-O. :)\n\nSo, in short, I don\'t see a problem with using the terms undercloud and\novercloud.\n\nBest,\n-jay\n\n\n\n','<612900875.8624338.1390921346097.JavaMail.root@redhat.com>',NULL),('<1390927545.31865.156.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 11:45:45',-18000,'2014-01-28 16:45:45',NULL,'[openstack-dev] [Fwd: Change in openstack/neutron[master]: Kill\n dnsmasq and ns-meta softly]','This might just be the most creative commit message of the year.\n\n-jay\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: \"Salvatore Orlando (Code Review)\" <review at openstack.org>\nSubject: Change in openstack/neutron[master]: Kill dnsmasq and ns-meta softly\nDate: Tue, 28 Jan 2014 11:13:47 +0000\nSize: 3280\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/0e9a7da9/attachment.mht>\n\n',NULL,NULL),('<1390927627.22978.46.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 11:47:07',-18000,'2014-01-28 16:47:07',NULL,'[openstack-dev] [savanna] How to handle diverging EDP job\n configuration settings','Hello all,\n\nIn our first pass at EDP, the model for job settings was very consistent\nacross all of our job types. The execution-time settings fit into this\n(superset) structure:\n\njob_configs = {\'configs\': {}, # config settings for oozie and hadoop\n	       \'params\': {},  # substitution values for Pig/Hive\n	       \'args\': []}    # script args (Pig and Java actions)\n\nBut we have some things that don\'t fit (and probably more in the\nfuture):\n\n1) Java jobs have \'main_class\' and \'java_opts\' settings\n   Currently these are handled as additional fields added to the\nstructure above.  These were the first to diverge.\n\n2) Streaming MapReduce (anticipated) requires mapper and reducer\nsettings (different than the mapred.xxxx.class settings for\nnon-streaming MapReduce)\n\nProblems caused by adding fields\n--------------------------------\nThe job_configs structure above is stored in the database. Each time we\nadd a field to the structure above at the level of configs, params, and\nargs, we force a change to the database tables, a migration script and a\nchange to the JSON validation for the REST api.\n\nWe also cause a change for python-savannaclient and potentially other\nclients.\n\nThis kind of change seems bad.\n\nProposal: Borrow a page from Oozie and add \"savanna.\" configs\n-------------------------------------------------------------\nI would like to fit divergent job settings into the structure we already\nhave.  One way to do this is to leverage the \'configs\' dictionary.  This\ndictionary primarily contains settings for hadoop, but there are a\nnumber of \"oozie.xxx\" settings that are passed to oozie as configs or\nset by oozie for the benefit of running apps.\n\nWhat if we allow \"savanna.\" settings to be added to configs?  If we do\nthat, any and all special configuration settings for specific job types\nor subtypes can be handled with no database changes and no api changes.\n\nDownside\n--------\nCurrently, all \'configs\' are rendered in the generated oozie workflow.\nThe \"savanna.\" settings would be stripped out and processed by Savanna,\nthereby changing that behavior a bit (maybe not a big deal)\n\nWe would also be mixing \"savanna.\" configs with config_hints for jobs,\nso users would potentially see \"savanna.xxxx\" settings mixed with oozie\nand hadoop settings.  Again, maybe not a big deal, but it might blur the\nlines a little bit.  Personally, I\'m okay with this.\n\nSlightly different\n------------------\nWe could also add a \"\'savanna-configs\': {}\" element to job_configs to\nkeep the configuration spaces separate.\n\nBut, now we would have \'savanna-configs\' (or another name), \'configs\',\n\'params\', and \'args\'.  Really? Just how many different types of values\ncan we come up with? :)\n\nI lean away from this approach.\n\nRelated: breaking up the superset\n---------------------------------\n\nIt is also the case that not every job type has every value type.\n\n             Configs   Params    Args\nHive            Y         Y        N\nPig             Y         Y        Y\nMapReduce       Y         N        N\nJava            Y         N        Y\n\nSo do we make that explicit in the docs and enforce it in the api with\nerrors?\n\nThoughts? I\'m sure there are some :)\n\nBest,\n\nTrevor\n\n\n\n  \n\n\n\n',NULL,NULL),('<1390949798.31865.165.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 17:56:38',-18000,'2014-01-28 22:56:38',NULL,'[openstack-dev] Proposed Logging Standards','On Tue, 2014-01-28 at 16:25 -0500, Brad Topol wrote:\n> So we are starting to add more cloud audit (aka CADF) support to\n> OpenStack.  We have support in Nova and infrastructure added to\n> Ceilometer and I am starting to add this capability to keystone.  This\n> work is based on sending events to ceilometer.  If this is related to\n> the audit work below I would like to be included.\n\nI don\'t believe Sean is talking about either notifications or\ntenant-facing activity. He is talking about Python log message\nconsistency and cleanup across OpenStack projects.\n\nBest,\n-jay\n\n\n\n','<OF38BF5714.E4C5C30B-ON85257C6E.007566AC-85257C6E.0075A85E@us.ibm.com>',NULL),('<1390950175.31865.166.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 18:02:55',-18000,'2014-01-28 23:02:55',NULL,'[openstack-dev] Configuration Discovery - Satori','On Tue, 2014-01-28 at 22:36 +0000, Adrian Otto wrote:\n> OpenStack Devs,\n> \n> I\'d like to introduce you to a team working on an interesting problem space. We would like to know what you think about Configuration Discovery. We plan to build a tool that aids in the process of automated configuration discovery.\n> \n> At Rackspace we work with customers who have pre-existing infrastructure and software running in production. To help them with changes, migrations, or configuration management, we often have to determine what they have in-place already. We have some tools and knowledge in-house that we use now, but we would like to create something even better in the open that would integrate well with OpenStack ecosystem projects like Heat, Solum, Murano, etc?\n> \n> The concept for the tool is simple. The inputs are facts we know about the current system (a username, API Key, URL, etc.) and the output is a set of structured configuration information. That information can be used for:\n> \n> - Generating Heat Templates\n> - Solum Application creation/import\n> - Creation of Chef recipes/cookbooks, Puppet modules, Ansible playbooks, setup scripts, etc..\n> - Configuration analysis (compare this config with a catalog of best practices)\n> - Configuration monitoring (has the configuration changed?)\n> - Troubleshooting\n> \n> We would like to hear from anyone interested in this problem domain, start a conversation on how this fits in the OpenStack ecosystem, and start exploring possible use cases that would be useful for users and operators of OpenStack clouds.\n> \n> For more information about the team, implementation, and prior art in this area, please see:\n> \n> https://wiki.openstack.org/wiki/Satori\n\nIn the Related Work section, you list:\n\nDevstructure Blueprint (https://github.com/devstructure/blueprint)\n\nThat is precisely what I would recommend. I don\'t see value in having a\nseparate OpenStack project that does this.\n\nBest,\n-jay\n\n\n\n','<2E511817-4C9A-4073-82CB-0283ABC575A7@rackspace.com>',NULL),('<1390954990.31865.168.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 19:23:10',-18000,'2014-01-29 00:23:10',NULL,'[openstack-dev] Configuration Discovery - Satori','On Tue, 2014-01-28 at 17:20 -0600, Caleb Groom wrote:\n> On January 28, 2014 at 5:05:56 PM, Jay Pipes (jaypipes at gmail.com)\n> wrote:\n> > In the Related Work section, you list:\n> > \n> > Devstructure Blueprint (https://github.com/devstructure/blueprint)\n> > \n> > That is precisely what I would recommend. I don\'t see value in\n> > having a\n> > separate OpenStack project that does this.\n> > \n> > Best,\n> > -jay\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> Hi Jay,\n> \n> \n> Devstructure Blueprint is scoped to gathering information about a\n> single server. We listed it as related because its a handy way to\n> handle reverse engineering once you?re logged into a server instance.\n> However, Satori has greater aims such as discovering the topology of\n> resources (load balancer, its configuration, nova instances behind the\n> load balancer, connected cinder instances, etc). For each relevant\n> server instance we could gather deep system knowledge by using the\n> projects listed in the Related section.\n\nSo why not improve Devstructure Blueprint and add in some plugins that,\ngiven some OpenStack creds, query things like the Neutron and Nova API\nendpoints for such information.\n\nI don\'t think this needs to be a separate OpenStack service.\n\nBest,\n-jay\n\n\n\n','<etPan.52e83b52.6b8b4567.315c@ML10YTFFT3>',NULL),('<1390968770.41418.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-28 20:12:50',-28800,'2014-01-29 04:12:50',NULL,'[openstack-dev] [oslo] VMware tools in oslo-incubator\n	or	straight to oslo.vmware','It might be more useful to make it a generic library which is used by relevant Openstack libraries\n\n\n\nOn Wednesday, January 29, 2014 3:36 AM, Donald Stufft <donald at stufft.io> wrote:\n \n\nOn Jan 28, 2014, at 5:01 PM, Julien Danjou <julien at danjou.info> wrote:\n\n> On Tue, Jan 28 2014, Doug Hellmann wrote:\n> \n>> There are several reviews related to adding VMware interface code to the\n>> oslo-incubator so it can be shared among projects (start at\n>> https://review.openstack.org/#/c/65075/7 if you want to look at the code).\n>> \n>> I expect this code to be fairly stand-alone, so I wonder if we would be\n>> better off creating an oslo.vmware library from the beginning, instead of\n>> bringing it through the incubator.\n>> \n>> Thoughts?\n> \n> This sounds like a good idea, but it doesn\'t look OpenStack specific, so\n> maybe building a non-oslo library would be better.\n> \n> Let\'s not zope it! :)\n\n+1 on not making it an oslo library.\n\n\n> \n> -- \n> Julien Danjou\n> # Free Software hacker # independent consultant\n> # http://julien.danjou.info\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-----------------\nDonald Stufft\nPGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/ca00759a/attachment.html>\n\n','<A6247394-93E1-4B0D-A070-8758C3F1102E@stufft.io>',NULL),('<1390988554.2381.153.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-29 09:42:34',0,'2014-01-29 09:42:34',NULL,'[openstack-tc] [Fwd: [OpenStack-DefCore] Engaging with the TC]','Hey\n\nJosh makes a case that a meeting between the board and TC is needed.\n\nIf it\'s to be an in-person meeting, then the Atlanta our next\nopportunity.\n\nHowever, to make it work, I think we need to:\n\n  1) Make a decision very quickly - I expect TC members will be making \n     travel plans already and many may be intending to arrive on the \n     evening of May 11.\n\n  2) Decide on a concrete agenda and schedule - what day and time would\n     we like this joint session, how long should it run and what\n     topic(s) do we wish to discuss?\n\n  3) Make this a meeting between peers - e.g. if this is part of the \n     board meeting, then we need proper seating arrangements so that TC\n     members aren\'t squashing in or sitting down the back in the cheap\n     seats\n\n  4) Sort out some procedural questions in advance - e.g. is this a \n     board meeting with TC members as invited guests or a joint session?\n     What constitutes TC and board quorum? Who will chair? Will any\n     votes be taken? - I think these should be straightforward to figure\n     out, but I wouldn\'t want to waste time on the day debating them.\n\nThanks,\nMark.\n\n-------- Forwarded Message --------\n> From: Mark McLoughlin <markmc at redhat.com>\n> Reply-to: Mark McLoughlin <markmc at redhat.com>\n> To: defcore-committee at lists.openstack.org\n> Subject: [OpenStack-DefCore] Engaging with the TC\n> Date: Mon, 27 Jan 2014 21:07:48 +0000\n> \n> Hi\n> \n> I couldn\'t make the last DefCore meeting because I was still on vacation\n> but, in any case, if I wasn\'t on vacation I would have been at the TC\n> meeting scheduled at the same time.\n> \n> As a more constructive suggestion than the board firing the TC[1], how\n> about the defcore committee join the TC at its next IRC meeting to\n> invite feedback on the draft summary? i.e. just like we\'re apparently\n> doing with George Reese and Andrew Clay Shafer?\n> \n> The only attempt I\'ve noticed the board make to have a joint Board/TC\n> meeting is to invite at short notice the TC to the Board meeting in\n> Portland. AFAIR when Thierry and Michael did turn up, the only thing we\n> discussed is how to organize a joint meeting[2]. When some TC members\n> joined the board meeting in Hong Kong, they were relegated to the cheap\n> seats at the back.\n> \n> OTOH it\'s entirely trivial to have members of the board join the TC\n> meeting. Unlike board meetings, the TC meeting is held at a predictable\n> time every week, anyone can propose items for the agenda and we have an\n> open floor at the end. It\'s worth a try, at least.\n> \n> Mark.\n> \n> [1] - http://www.youtube.com/watch?v=SH4Jw5NdwSs&t=3410\n> [2] - http://blogs.gnome.org/markmc/2013/05/25/april-14th-openstack-foundation-board-meeting/\n> \n> \n> _______________________________________________\n> Defcore-committee mailing list\n> Defcore-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee\n\n\n\n\n',NULL,NULL),('<1391004927.2306.2.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 09:15:27',-18000,'2014-01-29 14:15:27',NULL,'[openstack-dev] [savanna] How to handle diverging EDP job\n configuration settings','On Wed, 2014-01-29 at 14:35 +0400, Alexander Ignatov wrote:\n> Thank you for bringing this up, Trevor.\n> \n> EDP gets more diverse and it\'s time to change its model.\n> I totally agree with your proposal, but one minor comment.\n> Instead of \"savanna.\" prefix in job_configs wouldn\'t it be better to make it\n> as \"edp.\"? I think \"savanna.\" is too more wide word for this.\n\n+1, brilliant. EDP is perfect.  I was worried about the scope of\n\"savanna.\" too.\n\n> And one more bureaucratic thing... I see you already started implementing it [1], \n> and it is named and goes as new EDP workflow [2]. I think new bluprint should be \n> created for this feature to track all code changes as well as docs updates. \n> Docs I mean public Savanna docs about EDP, rest api docs and samples.\n\nAbsolutely, I can make it new blueprint.  Thanks.\n\n> [1] https://review.openstack.org/#/c/69712\n> [2] https://blueprints.launchpad.net/openstack/?searchtext=edp-oozie-streaming-mapreduce\n> \n> Regards,\n> Alexander Ignatov\n> \n> \n> \n> On 28 Jan 2014, at 20:47, Trevor McKay <tmckay at redhat.com> wrote:\n> \n> > Hello all,\n> > \n> > In our first pass at EDP, the model for job settings was very consistent\n> > across all of our job types. The execution-time settings fit into this\n> > (superset) structure:\n> > \n> > job_configs = {\'configs\': {}, # config settings for oozie and hadoop\n> > 	       \'params\': {},  # substitution values for Pig/Hive\n> > 	       \'args\': []}    # script args (Pig and Java actions)\n> > \n> > But we have some things that don\'t fit (and probably more in the\n> > future):\n> > \n> > 1) Java jobs have \'main_class\' and \'java_opts\' settings\n> >   Currently these are handled as additional fields added to the\n> > structure above.  These were the first to diverge.\n> > \n> > 2) Streaming MapReduce (anticipated) requires mapper and reducer\n> > settings (different than the mapred.xxxx.class settings for\n> > non-streaming MapReduce)\n> > \n> > Problems caused by adding fields\n> > --------------------------------\n> > The job_configs structure above is stored in the database. Each time we\n> > add a field to the structure above at the level of configs, params, and\n> > args, we force a change to the database tables, a migration script and a\n> > change to the JSON validation for the REST api.\n> > \n> > We also cause a change for python-savannaclient and potentially other\n> > clients.\n> > \n> > This kind of change seems bad.\n> > \n> > Proposal: Borrow a page from Oozie and add \"savanna.\" configs\n> > -------------------------------------------------------------\n> > I would like to fit divergent job settings into the structure we already\n> > have.  One way to do this is to leverage the \'configs\' dictionary.  This\n> > dictionary primarily contains settings for hadoop, but there are a\n> > number of \"oozie.xxx\" settings that are passed to oozie as configs or\n> > set by oozie for the benefit of running apps.\n> > \n> > What if we allow \"savanna.\" settings to be added to configs?  If we do\n> > that, any and all special configuration settings for specific job types\n> > or subtypes can be handled with no database changes and no api changes.\n> > \n> > Downside\n> > --------\n> > Currently, all \'configs\' are rendered in the generated oozie workflow.\n> > The \"savanna.\" settings would be stripped out and processed by Savanna,\n> > thereby changing that behavior a bit (maybe not a big deal)\n> > \n> > We would also be mixing \"savanna.\" configs with config_hints for jobs,\n> > so users would potentially see \"savanna.xxxx\" settings mixed with oozie\n> > and hadoop settings.  Again, maybe not a big deal, but it might blur the\n> > lines a little bit.  Personally, I\'m okay with this.\n> > \n> > Slightly different\n> > ------------------\n> > We could also add a \"\'savanna-configs\': {}\" element to job_configs to\n> > keep the configuration spaces separate.\n> > \n> > But, now we would have \'savanna-configs\' (or another name), \'configs\',\n> > \'params\', and \'args\'.  Really? Just how many different types of values\n> > can we come up with? :)\n> > \n> > I lean away from this approach.\n> > \n> > Related: breaking up the superset\n> > ---------------------------------\n> > \n> > It is also the case that not every job type has every value type.\n> > \n> >             Configs   Params    Args\n> > Hive            Y         Y        N\n> > Pig             Y         Y        Y\n> > MapReduce       Y         N        N\n> > Java            Y         N        Y\n> > \n> > So do we make that explicit in the docs and enforce it in the api with\n> > errors?\n> > \n> > Thoughts? I\'m sure there are some :)\n> > \n> > Best,\n> > \n> > Trevor\n> > \n> > \n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<0BD3E26D-C360-480E-AB52-975063C409E1@mirantis.com>',NULL),('<1391005404.2306.5.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 09:23:24',-18000,'2014-01-29 14:23:24',NULL,'[openstack-dev] [savanna] How to handle diverging EDP job\n configuration settings','So, assuming we go forward with this, the followup question is whether\nor not to move \"main_class\" and \"java_opts\" for Java actions into\n\"edp.java.main_class\" and \"edp.java.java_opts\" configs.\n\nI think yes.\n\nBest,\n\nTrevor\n\nOn Wed, 2014-01-29 at 09:15 -0500, Trevor McKay wrote:\n> On Wed, 2014-01-29 at 14:35 +0400, Alexander Ignatov wrote:\n> > Thank you for bringing this up, Trevor.\n> > \n> > EDP gets more diverse and it\'s time to change its model.\n> > I totally agree with your proposal, but one minor comment.\n> > Instead of \"savanna.\" prefix in job_configs wouldn\'t it be better to make it\n> > as \"edp.\"? I think \"savanna.\" is too more wide word for this.\n> \n> +1, brilliant. EDP is perfect.  I was worried about the scope of\n> \"savanna.\" too.\n> \n> > And one more bureaucratic thing... I see you already started implementing it [1], \n> > and it is named and goes as new EDP workflow [2]. I think new bluprint should be \n> > created for this feature to track all code changes as well as docs updates. \n> > Docs I mean public Savanna docs about EDP, rest api docs and samples.\n> \n> Absolutely, I can make it new blueprint.  Thanks.\n> \n> > [1] https://review.openstack.org/#/c/69712\n> > [2] https://blueprints.launchpad.net/openstack/?searchtext=edp-oozie-streaming-mapreduce\n> > \n> > Regards,\n> > Alexander Ignatov\n> > \n> > \n> > \n> > On 28 Jan 2014, at 20:47, Trevor McKay <tmckay at redhat.com> wrote:\n> > \n> > > Hello all,\n> > > \n> > > In our first pass at EDP, the model for job settings was very consistent\n> > > across all of our job types. The execution-time settings fit into this\n> > > (superset) structure:\n> > > \n> > > job_configs = {\'configs\': {}, # config settings for oozie and hadoop\n> > > 	       \'params\': {},  # substitution values for Pig/Hive\n> > > 	       \'args\': []}    # script args (Pig and Java actions)\n> > > \n> > > But we have some things that don\'t fit (and probably more in the\n> > > future):\n> > > \n> > > 1) Java jobs have \'main_class\' and \'java_opts\' settings\n> > >   Currently these are handled as additional fields added to the\n> > > structure above.  These were the first to diverge.\n> > > \n> > > 2) Streaming MapReduce (anticipated) requires mapper and reducer\n> > > settings (different than the mapred.xxxx.class settings for\n> > > non-streaming MapReduce)\n> > > \n> > > Problems caused by adding fields\n> > > --------------------------------\n> > > The job_configs structure above is stored in the database. Each time we\n> > > add a field to the structure above at the level of configs, params, and\n> > > args, we force a change to the database tables, a migration script and a\n> > > change to the JSON validation for the REST api.\n> > > \n> > > We also cause a change for python-savannaclient and potentially other\n> > > clients.\n> > > \n> > > This kind of change seems bad.\n> > > \n> > > Proposal: Borrow a page from Oozie and add \"savanna.\" configs\n> > > -------------------------------------------------------------\n> > > I would like to fit divergent job settings into the structure we already\n> > > have.  One way to do this is to leverage the \'configs\' dictionary.  This\n> > > dictionary primarily contains settings for hadoop, but there are a\n> > > number of \"oozie.xxx\" settings that are passed to oozie as configs or\n> > > set by oozie for the benefit of running apps.\n> > > \n> > > What if we allow \"savanna.\" settings to be added to configs?  If we do\n> > > that, any and all special configuration settings for specific job types\n> > > or subtypes can be handled with no database changes and no api changes.\n> > > \n> > > Downside\n> > > --------\n> > > Currently, all \'configs\' are rendered in the generated oozie workflow.\n> > > The \"savanna.\" settings would be stripped out and processed by Savanna,\n> > > thereby changing that behavior a bit (maybe not a big deal)\n> > > \n> > > We would also be mixing \"savanna.\" configs with config_hints for jobs,\n> > > so users would potentially see \"savanna.xxxx\" settings mixed with oozie\n> > > and hadoop settings.  Again, maybe not a big deal, but it might blur the\n> > > lines a little bit.  Personally, I\'m okay with this.\n> > > \n> > > Slightly different\n> > > ------------------\n> > > We could also add a \"\'savanna-configs\': {}\" element to job_configs to\n> > > keep the configuration spaces separate.\n> > > \n> > > But, now we would have \'savanna-configs\' (or another name), \'configs\',\n> > > \'params\', and \'args\'.  Really? Just how many different types of values\n> > > can we come up with? :)\n> > > \n> > > I lean away from this approach.\n> > > \n> > > Related: breaking up the superset\n> > > ---------------------------------\n> > > \n> > > It is also the case that not every job type has every value type.\n> > > \n> > >             Configs   Params    Args\n> > > Hive            Y         Y        N\n> > > Pig             Y         Y        Y\n> > > MapReduce       Y         N        N\n> > > Java            Y         N        Y\n> > > \n> > > So do we make that explicit in the docs and enforce it in the api with\n> > > errors?\n> > > \n> > > Thoughts? I\'m sure there are some :)\n> > > \n> > > Best,\n> > > \n> > > Trevor\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1391004927.2306.2.camel@tmckaylt.rdu.redhat.com>',NULL),('<1391012816.31865.173.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-01-29 11:26:56',-18000,'2014-01-29 16:26:56',NULL,'[Openstack-operators] Virtual Instance can\'t obtain IP address\n (OpenStack Havana)','On Wed, 2014-01-29 at 10:35 -0500, David Magda wrote:\n> On Wed, January 29, 2014 10:25, Alvise Dorigo wrote:\n> [...]\n> > So, it seems that the DHCP client\'s request correctly originates from the\n> > VM, and is correctly trasmitted to the network node by mean of the data\n> > network the two br-int interfaces are connected to; but for some reason\n> > the dhcp-agent doesn\'t receive anything, as proved by the null traffic on\n> > its tap.\n> >\n> > Any idea about what and how I could more deeply investigate ?\n> \n> On your network node, check the NIC settings for various offloading\n> \"optimizations\":\n> \n>     $ ethtool -k eth0 | grep offload\n>     tcp-segmentation-offload: off\n>     udp-fragmentation-offload: off [fixed]\n>     generic-segmentation-offload: off\n>     generic-receive-offload: off\n>     large-receive-offload: off [fixed]\n>     rx-vlan-offload: on\n>     tx-vlan-offload: on\n> \n> We recently solved this problem at $WORK by disabling GRO on our network\n> node.\n> \n> The other issue we\'ve come across that may be related is MTUs: since Open\n> vSwitch 1.9+ got rid of Path MTU Discovery, you may need to adjust your\n> MTUs:\n> \n>   http://techbackground.blogspot.ca/2013/06/path-mtu-discovery-and-gre.html\n> \n> There are two ways to fix this: if your network infrastructure has jumbo\n> frames (1500+) enabled, change the hardware NICs to have an MTU of 1546\n> (or larger). If you do not have jumbo frames enabled, configure the guests\n> to have an MTU of 1454 or smaller.\n> \n> One or both of these things (GRO and MTU) will probably be needed for a\n> properly functioning virtual network.\n\nAnne, it would be great to add David\'s findings/suggestions above to the\noperator\'s handbook. Also, Darragh\'s blog post contains some excellent\npointers around determining PMTU for network segments and how GRE\noverlay networks are affected by adjustments in that.\n\nBest,\n-jay\n\n\n\n','<812b7ac708f496837bc0844518e75290.squirrel@webmail.ee.ryerson.ca>',NULL),('<1391015933.2381.154.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-01-29 17:18:53',0,'2014-01-29 17:18:53',NULL,'[openstack-tc] [Fwd: Re: [Foundation Board] [Fwd:\n [OpenStack-DefCore] Engaging with the TC]]','-------- Forwarded Message --------\n> From: Joshua McKenty <joshua at pistoncloud.com>\n> To: Mark McLoughlin <markmc at redhat.com>\n> Cc: <foundation-board at lists.openstack.org> mailing list\n> <foundation-board at lists.openstack.org>\n> Subject: Re: [Foundation Board] [Fwd: [OpenStack-DefCore] Engaging\n> with the TC]\n> Date: Wed, 29 Jan 2014 09:09:51 -0800\n> \n> Yes!\n> \n> \n> The case is more that joint sessions are a requirement in the bylaws.\n> \n> \n> 1. I think we should definitely aim for a *short* joint session (2\n> hours, tops)\n> 2. I would propose we use a doodle poll for scheduling (with many\n> dozen participants, it seems infeasible to do it any other way).\n> I?m happy to collaborate on an agenda, and I threw an etherpad page up\n> for that purpose\n> https://etherpad.openstack.org/p/joint-tc-board-session-spring-2014-agenda\n> \n> \n> 3. Absolutely - I have to admit to being out of the loop on the fact\n> that TC members were planning on attending in HK, but we definitely\n> need enough seating for all of the TC and Board to convene.\n> \n> \n> 4. I definitely think of this as a joint session, and I would suggest\n> that either Thierry and Alan could co-chair, or perhaps that having\n> Jonathan chair would be simplest. I don?t believe there?s any\n> mechanism for joint voting - I think it?s a forum for discussion and\n> information sharing, and both the TC and Board can hold any required\n> votes in their own meetings afterwards. Equally, there would be no\n> Quorum requirements (although if we can?t round up at least 50% of\n> each body, we?ve probably failed).\n> \n> \n> My two cents. Oh, and I would appreciate if you could forward this to\n> the TC list.\n> \n> \n> Joshua\n> \n> \n> \n> On Jan 29, 2014, at 1:42 AM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n> \n> > Hey\n> > \n> > Josh makes a case that a meeting between the board and TC is needed.\n> > \n> > If it\'s to be an in-person meeting, then the Atlanta our next\n> > opportunity.\n> > \n> > However, to make it work, I think we need to:\n> > \n> >  1) Make a decision very quickly - I expect TC members will be\n> > making \n> >     travel plans already and many may be intending to arrive on the \n> >     evening of May 11.\n> > \n> >  2) Decide on a concrete agenda and schedule - what day and time\n> > would\n> >     we like this joint session, how long should it run and what\n> >     topic(s) do we wish to discuss?\n> > \n> >  3) Make this a meeting between peers - e.g. if this is part of the \n> >     board meeting, then we need proper seating arrangements so that\n> > TC\n> >     members aren\'t squashing in or sitting down the back in the\n> > cheap\n> >     seats\n> > \n> >  4) Sort out some procedural questions in advance - e.g. is this a \n> >     board meeting with TC members as invited guests or a joint\n> > session?\n> >     What constitutes TC and board quorum? Who will chair? Will any\n> >     votes be taken? - I think these should be straightforward to\n> > figure\n> >     out, but I wouldn\'t want to waste time on the day debating them.\n> > \n> > Thanks,\n> > Mark.\n> > \n> > -------- Forwarded Message --------\n> > > From: Mark McLoughlin <markmc at redhat.com>\n> > > Reply-to: Mark McLoughlin <markmc at redhat.com>\n> > > To: defcore-committee at lists.openstack.org\n> > > Subject: [OpenStack-DefCore] Engaging with the TC\n> > > Date: Mon, 27 Jan 2014 21:07:48 +0000\n> > > \n> > > Hi\n> > > \n> > > I couldn\'t make the last DefCore meeting because I was still on\n> > > vacation\n> > > but, in any case, if I wasn\'t on vacation I would have been at the\n> > > TC\n> > > meeting scheduled at the same time.\n> > > \n> > > As a more constructive suggestion than the board firing the TC[1],\n> > > how\n> > > about the defcore committee join the TC at its next IRC meeting to\n> > > invite feedback on the draft summary? i.e. just like we\'re\n> > > apparently\n> > > doing with George Reese and Andrew Clay Shafer?\n> > > \n> > > The only attempt I\'ve noticed the board make to have a joint\n> > > Board/TC\n> > > meeting is to invite at short notice the TC to the Board meeting\n> > > in\n> > > Portland. AFAIR when Thierry and Michael did turn up, the only\n> > > thing we\n> > > discussed is how to organize a joint meeting[2]. When some TC\n> > > members\n> > > joined the board meeting in Hong Kong, they were relegated to the\n> > > cheap\n> > > seats at the back.\n> > > \n> > > OTOH it\'s entirely trivial to have members of the board join the\n> > > TC\n> > > meeting. Unlike board meetings, the TC meeting is held at a\n> > > predictable\n> > > time every week, anyone can propose items for the agenda and we\n> > > have an\n> > > open floor at the end. It\'s worth a try, at least.\n> > > \n> > > Mark.\n> > > \n> > > [1] - http://www.youtube.com/watch?v=SH4Jw5NdwSs&t=3410\n> > > [2] -\n> > > http://blogs.gnome.org/markmc/2013/05/25/april-14th-openstack-foundation-board-meeting/\n> > > \n> > > \n> > > _______________________________________________\n> > > Defcore-committee mailing list\n> > > Defcore-committee at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee\n> > \n> > \n> > \n> > _______________________________________________\n> > Foundation-board mailing list\n> > Foundation-board at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n> \n> \n\n\n\n\n',NULL,NULL),('<1391020987.81123010@webmail.emailsrvr.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-01-29 12:43:07',-21600,'2014-01-29 18:43:07',NULL,'[openstack-community] Call for Papers - OSCON and OpenStack Day at\n	LinuxTag Berlin','\nJust a reminder that the OSCON (Open Source Conference, July 20-24 in Portland, OR) CFP submissions are due tomorrow, January 30.  Please submit DevOps topics of interest to [http://www.oscon.com/oscon2014/public/cfp/308] http://www.oscon.com/oscon2014/public/cfp/308.  We\'d love to have a long list of OpenStack sessions there this year, for OpenStack\'s 4th birthday.  We\'ll help drive attendees to all accepted sessions.\n \nAlso, just out, is the Call for Papers for the OpenStack Day at LinuxTag in Berlin on May 9.  Florian Haas and Martin Loschwitz of hastexo are organizing the track titled \"OpenStack: One IaaS platform for all needs\".  This is the Friday prior to the Atlanta OpenStack Summit; speaker submissions are very much appreciated.  Please use the [http://www.linuxtag.org/2014/en/] LinuxTag CFP submission process by February 7, and also drop an email to Florian and Martin at florian at hastexo.com and martin at hastexo.com. They welcome your inquiries as well.\n \nThank you for your support.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140129/a007fe4e/attachment.html>\n\n',NULL,NULL),('<1391033826.2306.17.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 17:17:06',-18000,'2014-01-29 22:17:06',NULL,'[openstack-dev] [savanna] Undoing a change in the alembic migrations','Hi Sergey,\n\n  In https://review.openstack.org/#/c/69982/1 we are moving the\n\'main_class\' and \'java_opts\' fields for a job execution into the\njob_configs[\'configs\'] dictionary.  This means that \'main_class\' and\n\'java_opts\' don\'t need to be in the database anymore.\n\n  These fields were just added in the initial version of the migration\nscripts.  The README says that migrations work \"from icehouse\". Since\nthis is the initial script, does that mean we can just remove references\nto those fields from the db models and the script, or do we need a new\nmigration script (002) to erase them?\n\nThanks,\n\nTrevor\n\n\n\n',NULL,NULL),('<1391042416.27339.6.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 19:40:16',-18000,'2014-01-30 00:40:16',NULL,'[openstack-dev] [Heat] How to model resources in Heat','On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:\n> I\'ve noticed a few code reviews for new Heat resource types - \n> particularly Neutron resource types - where folks are struggling to find \n> the appropriate way to model the underlying API in Heat. This is a \n> really hard problem, and is often non-obvious even to Heat experts, so \n> here are a few tips that might help.\n> \n> Resources are nouns, they model Things. Ideally Things that have UUIDs. \n> The main reason to have a resource is so you can reference its UUID (or \n> some attribute) and pass it to another resource or to the user via an \n> output.\n> \n> If two resources _have_ to be used together, they\'re really only one \n> resource. Don\'t split them up - especially if the one whose UUID other \n> resources depend on is the first to be created but not the only one \n> actually required by the resource depending on it.\n\nRight. The above is precisely why I raised concerns about the \"image\nimport/upload tasks\" work ongoing in Glance.\n\nhttps://wiki.openstack.org/wiki/Glance-tasks-import#Initial_Import_Request\n\nBest,\n-jay\n\n\n\n','<52E9950B.9020906@redhat.com>',NULL),('<1391044343.27339.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 20:12:23',-18000,'2014-01-30 01:12:23',NULL,'[openstack-dev] [Heat] How to model resources in Heat','On Wed, 2014-01-29 at 20:03 -0500, Zane Bitter wrote:\n> On 29/01/14 19:40, Jay Pipes wrote:\n> > On Wed, 2014-01-29 at 18:55 -0500, Zane Bitter wrote:\n> >> I\'ve noticed a few code reviews for new Heat resource types -\n> >> particularly Neutron resource types - where folks are struggling to find\n> >> the appropriate way to model the underlying API in Heat. This is a\n> >> really hard problem, and is often non-obvious even to Heat experts, so\n> >> here are a few tips that might help.\n> >>\n> >> Resources are nouns, they model Things. Ideally Things that have UUIDs.\n> >> The main reason to have a resource is so you can reference its UUID (or\n> >> some attribute) and pass it to another resource or to the user via an\n> >> output.\n> >>\n> >> If two resources _have_ to be used together, they\'re really only one\n> >> resource. Don\'t split them up - especially if the one whose UUID other\n> >> resources depend on is the first to be created but not the only one\n> >> actually required by the resource depending on it.\n> >\n> > Right. The above is precisely why I raised concerns about the \"image\n> > import/upload tasks\" work ongoing in Glance.\n> >\n> > https://wiki.openstack.org/wiki/Glance-tasks-import#Initial_Import_Request\n> \n> At least the dependencies there would be in the right order:\n> \n>    ImportTask <- Image <- Server\n> \n> but if you were to model this in Heat, there should just be an Image \n> resource that does the importing internally.\n> \n> (I\'m not touching the question of whether Heat should have a Glance \n> Image resource at all, which I\'m deeply ambivalent about.)\n\nI\'m not touching on that at all, either. \n\nI\'m just pointing out that the \"task\" resource object currently being\nworked on in the Glance API is not really a resource at all -- the\nresource is an Image. Whether or not the Image resource changes state\nduring certain events (like image upload or translation) does not mean\nthat state change should be represented as a resource in the API.\n\nBest,\n-jay\n\n\n\n','<52E9A4D5.3000206@redhat.com>',NULL),('<1391072457.4808.77136681.7555356D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 01:00:57',-28800,'2014-01-30 09:00:57',NULL,'[openstack-dev] Fwd: [TripleO] mid-cycle meetup?','I would love to attend and March should work fine for me.\n\n\n\n--\nGregory Haynes\ngreg at greghaynes.net\n\n\n\n\n\nOn Mon, Jan 27, 2014, at 01:53 AM, James Polley wrote:\n\nI\'d love to come, but at this stage I won\'t be able to travel before about March\n 3, which sounds like it\'s a few weeks later than most people were thinking of.\n\n\n---------- Forwarded message ----------\nFrom: Robert Collins\n<[1]robe... at robertcollins.net<[2]mailto:robe... at robertcollins.net>>\nDate: 24 January 2014 08:47\nSubject: [TripleO] mid-cycle meetup?\nTo:\n\"[3]openstack-operat... at lists.openstack.org<[4]mailto:openstack-operat... at lists.\nopenstack.org>\"\n<[5]openstack-operat... at lists.openstack.org<[6]mailto:openstack-operat... at lists.\nopenstack.org>>\n\n\nHi, sorry for proposing this at *cough* the mid-way point [christmas\nshutdown got in the way of internal acks...], but who would come if\nthere was a mid-cycle meetup? I\'m thinking the HP sunnyvale office as\na venue.\n\n-Rob\n\n--\nRobert Collins <[7]rbtcoll... at hp.com<[8]mailto:rbtcoll... at hp.com>>\nDistinguished Technologist\nHP Converged Cloud\n\n_______________________________________________\n\nOpenStack-dev mailing list\n\n[9]OpenStack-dev at lists.openstack.org\n\n[10]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nReferences\n\n1. mailto:robe... at robertcollins.net\n2. mailto:robe... at robertcollins.net\n3. mailto:openstack-operat... at lists.openstack.org\n4. mailto:openstack-operat... at lists.openstack.org\n5. mailto:openstack-operat... at lists.openstack.org\n6. mailto:openstack-operat... at lists.openstack.org\n7. mailto:rbtcoll... at hp.com\n8. mailto:rbtcoll... at hp.com\n9. mailto:OpenStack-dev at lists.openstack.org\n  10. http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/c88a7a90/attachment.html>\n\n','<CAPtRfUGcBa6txa94jgxycRYb1D+_CQVCkaivoBFkd2At3xvZew@mail.gmail.com>',NULL),('<1391088504-sup-2740@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 05:30:35',-28800,'2014-01-30 13:30:35',NULL,'[openstack-dev] [Heat] About LaunchConfiguration and Autoscaling','Excerpts from Thomas Herve\'s message of 2014-01-30 03:01:38 -0800:\n> Hi all,\n> \n> While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources.\n> \n> The LaunchConfiguration object basically holds properties to be able to fire new servers in a scaling group. In the new design, we will be able to start arbitrary resources, so we can\'t keep a strict LaunchConfiguration object as it exists, as we can have arbitrary properties.\n> \n\nIIRC, LaunchConfiguration is just part of the API for AWS\'s separate\nauto scaling service.\n\nSince we\'re auto scaling in Heat we have template intelligence in our\nauto scaler and thus we shouldn\'t need two resources.\n\n\n','<453795754.91464.1391079698430.JavaMail.zimbra@enovance.com>',NULL),('<1391096547.27339.15.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 10:42:27',-18000,'2014-01-30 15:42:27',NULL,'[openstack-dev] [nova] bp proposal: libvirt-resize-disk-down','On Thu, 2014-01-30 at 14:59 +0000, sahid wrote:\n> <snip>\n> The implementation will be separated in several commits:\n>   + Move shared utility methods to a common module:\n>     - virt.xenapi.vm_utils._get_partitions to virt.disk.utils.get_partitions\n>     - virt.libvirt.utils.copy_image to virt.disk.utils.copy_image\n>     - virt.xenapi.vm_utils._repair_filesystem to virt.disk.utils.repair_filesystem\n>   + Disk resize down implementation\n\nAbove looks like a good plan, and +1 for pulling useful generic code out\nof a particular driver into a reusable library.\n\n> Notes:\n>   - Another point we have to discuss, is that the current implementation just skips\n>     the fs resize if not supported, is it a good choice? \n\nFor metering/usage purposes, does the old size of ephemeral disk\ncontinue to be shown in usage records, or does the size of the disk in\nthe newly-selected instance type (flavor) get used? If the former, then\nthis would be an avenue for users to Get more disk space than they are\npaying for. Something to look into...\n\nBest,\n-jay\n\n> Should we have\n>     to raise an exception to inform the user that it is not possible to resize\n>     the instance? (if we have to raise an exception, a task will be added to the\n>     TODO to handle this case for resize up before working on resize down.)\n>   - The current workflow for a user is to confirm the resize when the state\n>     of the instance is VERIFY_RESIZE, I think we probably have to add a\n>     checklist of good pratices of how to verify a resize in the manual:\n>       http://docs.openstack.org/user-guide/content/nova_cli_resize.html\n> \n> Thanks a lot,\n> s.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1615156199.6815811.1391093985160.JavaMail.root@cloudwatt.com>',NULL),('<1391097040.2186.1.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 10:50:40',-18000,'2014-01-30 15:50:40',NULL,'[openstack-dev] [savanna] Choosing provisioning engine during\n cluster launch','+1\n\nHow about an undocumented config?\n\nTrev\n\nOn Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote:\n> i imagine this is something that can be useful in a development and \n> testing environment, especially during the transition period from direct \n> to heat. so having the ability is not unreasonable, but i wouldn\'t \n> expose it to users via the dashboard (maybe not even directly in the cli)\n> \n> generally i want to reduce the number of parameters / questions the user \n> is asked\n> \n> best,\n> \n> \n> matt\n> \n> On 01/30/2014 04:42 AM, Dmitry Mescheryakov wrote:\n> > I agree with Andrew. I see no value in letting users select how their\n> > cluster is provisioned, it will only make interface a little bit more\n> > complex.\n> >\n> > Dmitry\n> >\n> >\n> > 2014/1/30 Andrew Lazarev <alazarev at mirantis.com\n> > <mailto:alazarev at mirantis.com>>\n> >\n> >     Alexander,\n> >\n> >     What is the purpose of exposing this to user side? Both engines must\n> >     do exactly the same thing and they exist in the same time only for\n> >     transition period until heat engine is stabilized. I don\'t see any\n> >     value in proposed option.\n> >\n> >     Andrew.\n> >\n> >\n> >     On Wed, Jan 29, 2014 at 8:44 PM, Alexander Ignatov\n> >     <aignatov at mirantis.com <mailto:aignatov at mirantis.com>> wrote:\n> >\n> >         Today Savanna has two provisioning engines, heat and old one\n> >         known as \'direct\'.\n> >         Users can choose which engine will be used by setting special\n> >         parameter in \'savanna.conf\'.\n> >\n> >         I have an idea to give an ability for users to define\n> >         provisioning engine\n> >         not only when savanna is started but when new cluster is\n> >         launched. The idea is simple.\n> >         We will just add new field \'provisioning_engine\' to \'cluster\'\n> >         and \'cluster_template\'\n> >         objects. And profit is obvious, users can easily switch from one\n> >         engine to another without\n> >         restarting savanna service. Of course, this parameter can be\n> >         omitted and the default value\n> >         from the \'savanna.conf\' will be applied.\n> >\n> >         Is this viable? What do you think?\n> >\n> >         Regards,\n> >         Alexander Ignatov\n> >\n> >\n> >\n> >\n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         <mailto:OpenStack-dev at lists.openstack.org>\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> >     _______________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<52EA6091.6060604@redhat.com>',NULL),('<1391097145.2186.2.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 10:52:25',-18000,'2014-01-30 15:52:25',NULL,'[openstack-dev] [savanna] Choosing provisioning engine during\n cluster launch','My mistake, it\'s already there.  I missed the distinction between set on\nstartup and set per cluster.\n\nTrev\n\nOn Thu, 2014-01-30 at 10:50 -0500, Trevor McKay wrote:\n> +1\n> \n> How about an undocumented config?\n> \n> Trev\n> \n> On Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote:\n> > i imagine this is something that can be useful in a development and \n> > testing environment, especially during the transition period from direct \n> > to heat. so having the ability is not unreasonable, but i wouldn\'t \n> > expose it to users via the dashboard (maybe not even directly in the cli)\n> > \n> > generally i want to reduce the number of parameters / questions the user \n> > is asked\n> > \n> > best,\n> > \n> > \n> > matt\n> > \n> > On 01/30/2014 04:42 AM, Dmitry Mescheryakov wrote:\n> > > I agree with Andrew. I see no value in letting users select how their\n> > > cluster is provisioned, it will only make interface a little bit more\n> > > complex.\n> > >\n> > > Dmitry\n> > >\n> > >\n> > > 2014/1/30 Andrew Lazarev <alazarev at mirantis.com\n> > > <mailto:alazarev at mirantis.com>>\n> > >\n> > >     Alexander,\n> > >\n> > >     What is the purpose of exposing this to user side? Both engines must\n> > >     do exactly the same thing and they exist in the same time only for\n> > >     transition period until heat engine is stabilized. I don\'t see any\n> > >     value in proposed option.\n> > >\n> > >     Andrew.\n> > >\n> > >\n> > >     On Wed, Jan 29, 2014 at 8:44 PM, Alexander Ignatov\n> > >     <aignatov at mirantis.com <mailto:aignatov at mirantis.com>> wrote:\n> > >\n> > >         Today Savanna has two provisioning engines, heat and old one\n> > >         known as \'direct\'.\n> > >         Users can choose which engine will be used by setting special\n> > >         parameter in \'savanna.conf\'.\n> > >\n> > >         I have an idea to give an ability for users to define\n> > >         provisioning engine\n> > >         not only when savanna is started but when new cluster is\n> > >         launched. The idea is simple.\n> > >         We will just add new field \'provisioning_engine\' to \'cluster\'\n> > >         and \'cluster_template\'\n> > >         objects. And profit is obvious, users can easily switch from one\n> > >         engine to another without\n> > >         restarting savanna service. Of course, this parameter can be\n> > >         omitted and the default value\n> > >         from the \'savanna.conf\' will be applied.\n> > >\n> > >         Is this viable? What do you think?\n> > >\n> > >         Regards,\n> > >         Alexander Ignatov\n> > >\n> > >\n> > >\n> > >\n> > >         _______________________________________________\n> > >         OpenStack-dev mailing list\n> > >         OpenStack-dev at lists.openstack.org\n> > >         <mailto:OpenStack-dev at lists.openstack.org>\n> > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > >\n> > >\n> > >     _______________________________________________\n> > >     OpenStack-dev mailing list\n> > >     OpenStack-dev at lists.openstack.org\n> > >     <mailto:OpenStack-dev at lists.openstack.org>\n> > >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<1391097040.2186.1.camel@tmckaylt.rdu.redhat.com>',NULL),('<1391099291-sup-2890@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 09:09:17',-28800,'2014-01-30 17:09:17',NULL,'[openstack-dev] [Heat] About LaunchConfiguration and Autoscaling','Excerpts from Zane Bitter\'s message of 2014-01-30 07:38:38 -0800:\n> On 30/01/14 06:01, Thomas Herve wrote:\n> > Hi all,\n> >\n> > While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources.\n> >\n> > The LaunchConfiguration object basically holds properties to be able to fire new servers in a scaling group. In the new design, we will be able to start arbitrary resources, so we can\'t keep a strict LaunchConfiguration object as it exists, as we can have arbitrary properties.\n> >\n> > It may be still be interesting to store it separately to be able to reuse it between groups.\n> >\n> > So either we do this:\n> >\n> > group:\n> >    type: OS::Heat::ScalingGroup\n> >    properties:\n> >      scaled_resource: OS::Nova::Server\n> >      resource_properties:\n> >        image: my_image\n> >        flavor: m1.large\n> \n> The main advantages of this that I see are:\n> \n> * It\'s one less resource.\n> * We can verify properties against the scaled_resource at the place the \n> LaunchConfig is defined. (Note: in _both_ models these would be verified \n> at the same place the _ScalingGroup_ is defined.)\n> \n> > Or:\n> >\n> > group:\n> >    type: OS::Heat::ScalingGroup\n> >    properties:\n> >      scaled_resource: OS::Nova::Server\n> >      launch_configuration: server_config\n> > server_config:\n> >    type: OS::Heat::LaunchConfiguration\n> >    properties:\n> >      image: my_image\n> >      flavor: m1.large\n> \n> \n> I favour this one for a few reasons:\n> \n> * A single LaunchConfiguration can be re-used by multiple scaling \n> groups. Reuse is good, and is one of the things we have been driving \n> toward with e.g. software deployments.\n\nI agree with the desire for re-use. In fact I am somewhat desperate to\nhave it as we try to write templates which allow assembling different\ntopologies of OpenStack deployment.\n\nI would hope we would solve that at a deeper level, rather than making\nresources for the things we think will need re-use. I think nested stacks\nallow this level of re-use already anyway. Software config just allows\nsub-resource composition.\n\n\n','<52EA71FE.4000001@redhat.com>',NULL),('<1391110253-sup-5212@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 11:32:36',-28800,'2014-01-30 19:32:36',NULL,'[openstack-dev] [TripleO] devtest thoughts','Excerpts from Ben Nemec\'s message of 2014-01-30 11:08:44 -0800:\n> On 2014-01-30 09:28, James Slagle wrote:\n> > devtest, our TripleO setup, has been rapidly evolving. We\'ve added a\n> > fair amount of configuration options for stuff like using actual\n> > baremetal, and (soon) HA deployments by default. Also, the scripts\n> > (which the docs are generated from) are being used for both CD and CI.\n> > \n> > This is all great progress.\n> > \n> > However, due to these changes,  I think that devtest no longer works\n> > great as a tripleo developer setup. You haven\'t been able to complete\n> > a setup following our docs for >1 week now. The patches are in review\n> > to fix that, and they need to be properly reviewed and I\'m not saying\n> > they should be rushed. Just that it\'s another aspect of the problem of\n> > trying to use devtest for CI/CD and a dev setup.\n> > \n> > I think it might be time to have a developer setup vs. devtest, which\n> > is more of a documented tripleo setup at this point.\n> > \n> > In irc earlier this week (sorry if i misquoting the intent here), I\n> > saw mention of getting setup easier by just using a seed to deploy an\n> > overcloud.  I think that\'s a great idea.  We are all already probably\n> > doing it :). Why not document that in some sort of fashion?\n> > \n> > There would be some initial trade offs, around folks not necessarily\n> > understanding the full devtest process. But, you don\'t necessarily\n> > need to understand all of that to hack on the upgrade story, or\n> > tuskar, or ironic.\n> > \n> > These are just some additional thoughts around the process and mail I\n> > sent earlier this week:\n> > http://lists.openstack.org/pipermail/openstack-dev/2014-January/025726.html\n> > But, I thought this warranted a broader discussion.\n> \n> Another aspect I\'ve noticed lately is that there has been discussion \n> around making sure the defaults in devtest are production-ready, which \n> seems to contradict both parts of the name devtest. :-)\n> \n\nHm, can you point to some of those discussions? We want the defaults in\nall of OpenStack to be production ready, and we want devtest to work in\nthat way when it doesn\'t put undue burden on development or testing.\n\n\n','<f28e1539b7aa96df68571314a9c12e11@localhost>',NULL),('<1391110359-sup-4919@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 11:39:54',-28800,'2014-01-30 19:39:54',NULL,'[openstack-dev] [TripleO] devtest thoughts','Excerpts from James Slagle\'s message of 2014-01-30 07:28:01 -0800:\n> devtest, our TripleO setup, has been rapidly evolving. We\'ve added a\n> fair amount of configuration options for stuff like using actual\n> baremetal, and (soon) HA deployments by default. Also, the scripts\n> (which the docs are generated from) are being used for both CD and CI.\n> \n> This is all great progress.\n> \n> However, due to these changes,  I think that devtest no longer works\n> great as a tripleo developer setup. You haven\'t been able to complete\n> a setup following our docs for >1 week now. The patches are in review\n> to fix that, and they need to be properly reviewed and I\'m not saying\n> they should be rushed. Just that it\'s another aspect of the problem of\n> trying to use devtest for CI/CD and a dev setup.\n> \n\nI wonder, if we have a gate which runs through devtest entirely, would\nthat reduce the instances where we\'ve broken everybody? Seems like it\nwould, but the gate isn\'t going to read the docs, it is going to run the\nscript, so maybe it will still break sometimes.\n\nBTW I do think those patches should be first priority.\n\n> I think it might be time to have a developer setup vs. devtest, which\n> is more of a documented tripleo setup at this point.\n>\n\nWhat if we just focus on breaking devtest less often? Seems like that is\nachievable and then we don\'t diverge from CI.\n\n> In irc earlier this week (sorry if i misquoting the intent here), I\n> saw mention of getting setup easier by just using a seed to deploy an\n> overcloud.  I think that\'s a great idea.  We are all already probably\n> doing it :). Why not document that in some sort of fashion?\n>\n\n+1. I think a note at the end of devtest_seed which basically says \"If\nyou are not interested in testing HA baremetal, set these variables like\nso and skip to devtest_overcloud. Great idea actually, as thats what I\ndo often when I know I\'ll be tearing down my setup later.\n\n> There would be some initial trade offs, around folks not necessarily\n> understanding the full devtest process. But, you don\'t necessarily\n> need to understand all of that to hack on the upgrade story, or\n> tuskar, or ironic.\n> \n\nAgreed totally. The processes are similar enough that when the time\ncomes that a user needs to think about working on things which impact\nthe undercloud they can back up to seed and then do that.\n\n\n','<CAHV77z_UtR2BhFCqdesu1gWuAFd-y1gBjTZX=seh3=CxNphLwQ@mail.gmail.com>',NULL),('<1391111512.7860.10.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 14:51:52',-18000,'2014-01-30 19:51:52',NULL,'[openstack-dev] [savanna] Alembic migrations and absence of DROP\n column in sqlite','\nI was playing with alembic migration and discovered that\nop.drop_column() doesn\'t work with sqlite.  This is because sqlite\ndoesn\'t support dropping a column (broken imho, but that\'s another\ndiscussion).  Sqlite throws a syntax error.\n\nTo make this work with sqlite, you have to copy the table to a temporary\nexcluding the column(s) you don\'t want and delete the old one, followed\nby a rename of the new table.\n\nThe existing 002 migration uses op.drop_column(), so I\'m assuming it\'s\nbroken, too (I need to check what the migration test is doing).  I was\nworking on an 003.\n\nHow do we want to handle this?  Three good options I can think of:\n\n1) don\'t support migrations for sqlite (I think \"no\", but maybe)\n\n2) Extend alembic so that op.drop_column() does the right thing (more\nopen-source contributions for us, yay :) )\n\n3) Add our own wrapper in savanna so that we have a drop_column() method\nthat wraps copy/rename.\n\nIdeas, comments?\n\nBest,\n\nTrevor\n\n\n\n',NULL,NULL),('<1391112275.27339.27.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 15:04:35',-18000,'2014-01-30 20:04:35',NULL,'[openstack-dev] [savanna] Alembic migrations and absence of\n DROP column in sqlite','On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote:\n> I was playing with alembic migration and discovered that\n> op.drop_column() doesn\'t work with sqlite.  This is because sqlite\n> doesn\'t support dropping a column (broken imho, but that\'s another\n> discussion).  Sqlite throws a syntax error.\n> \n> To make this work with sqlite, you have to copy the table to a temporary\n> excluding the column(s) you don\'t want and delete the old one, followed\n> by a rename of the new table.\n> \n> The existing 002 migration uses op.drop_column(), so I\'m assuming it\'s\n> broken, too (I need to check what the migration test is doing).  I was\n> working on an 003.\n> \n> How do we want to handle this?  Three good options I can think of:\n> \n> 1) don\'t support migrations for sqlite (I think \"no\", but maybe)\n> \n> 2) Extend alembic so that op.drop_column() does the right thing (more\n> open-source contributions for us, yay :) )\n> \n> 3) Add our own wrapper in savanna so that we have a drop_column() method\n> that wraps copy/rename.\n> \n> Ideas, comments?\n\nMigrations should really not be run against SQLite at all -- only on the\ndatabases that would be used in production. I believe the general\ndirection of the contributor community is to be consistent around\ntesting of migrations and to not run migrations at all in unit tests\n(which use SQLite).\n\nBoris (cc\'d) may have some more to say on this topic.\n\nBest,\n-jay\n\n\n\n','<1391111512.7860.10.camel@tmckaylt.rdu.redhat.com>',NULL),('<1391118312-sup-5347@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 13:54:47',-28800,'2014-01-30 21:54:47',NULL,'[openstack-dev] [Heat] How to model resources in Heat','Excerpts from Mark Washenberger\'s message of 2014-01-30 12:41:40 -0800:\n> On Wed, Jan 29, 2014 at 5:03 PM, Zane Bitter <zbitter at redhat.com> wrote:\n> > (I\'m not touching the question of whether Heat should have a Glance Image\n> > resource at all, which I\'m deeply ambivalent about.)\n> >\n> \n> Maybe I\'m just missing the use case, but it seems like modeling anything\n> Glance-y in Heat doesn\'t quite make sense. If at all, the dependency would\n> run the other way (model heat-things in glance, just as we presently model\n> nova-things in glance). So I think we\'re in agreement.\n> \n\nI\'m pretty sure it is useful to model images in Heat.\n\nConsider this scenario:\n\n\nresources:\n  build_done_handle:\n    type: AWS::CloudFormation::WaitConditionHandle\n  build_done:\n    type: AWS::CloudFormation::WaitCondition\n    properties:\n      handle: {Ref: build_done_handle}\n  build_server:\n    type: OS::Nova::Server\n    properties:\n      image: build-server-image\n      userdata:\n        join [ \"\",\n          - \"#!/bin/bash\\n\"\n          - \"build_an_image\\n\"\n          - \"cfn-signal -s SUCCESS \"\n          - {Ref: build_done_handle}\n          - \"\\n\"]\n  built_image:\n    type: OS::Glance::Image\n    depends_on: build_done\n    properties:\n      fetch_url: join [ \"\", [\"http://\", {get_attribute: [ build_server, fixed_ip ]}, \"/image_path\"]]\n  actual_server:\n    type: OS::Nova::Server\n    properties:\n      image: {Ref: built_image}\n\n\nAnyway, seems rather useful. Maybe I\'m reaching.\n\n\n','<CAJyP2C-kMvNYa6GbBOdt9Fk+O1_xA3NTHoxFKkt-omtJ4OEwXA@mail.gmail.com>',NULL),('<1391149020-sup-9779@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 22:24:51',-28800,'2014-01-31 06:24:51',NULL,'[openstack-dev] [Heat] How to model resources in Heat','Excerpts from Zane Bitter\'s message of 2014-01-30 19:30:40 -0800:\n> On 30/01/14 16:54, Clint Byrum wrote:\n> > I\'m pretty sure it is useful to model images in Heat.\n> >\n> > Consider this scenario:\n> >\n> >\n> > resources:\n> >    build_done_handle:\n> >      type: AWS::CloudFormation::WaitConditionHandle\n> >    build_done:\n> >      type: AWS::CloudFormation::WaitCondition\n> >      properties:\n> >        handle: {Ref: build_done_handle}\n> >    build_server:\n> >      type: OS::Nova::Server\n> >      properties:\n> >        image: build-server-image\n> >        userdata:\n> >          join [ \"\",\n> >            - \"#!/bin/bash\\n\"\n> >            - \"build_an_image\\n\"\n> >            - \"cfn-signal -s SUCCESS \"\n> >            - {Ref: build_done_handle}\n> >            - \"\\n\"]\n> >    built_image:\n> >      type: OS::Glance::Image\n> >      depends_on: build_done\n> >      properties:\n> >        fetch_url: join [ \"\", [\"http://\", {get_attribute: [ build_server, fixed_ip ]}, \"/image_path\"]]\n> >    actual_server:\n> >      type: OS::Nova::Server\n> >      properties:\n> >        image: {Ref: built_image}\n> >\n> >\n> > Anyway, seems rather useful. Maybe I\'m reaching.\n> \n> Well, consider that when this build is complete you\'ll still have the \n> server you used to build the image still sitting around. Of course you \n> can delete the stack to remove it - and along with it will go the image \n> in Glance. Still seem useful?\n> \n\nNo, not as such. However I have also discussed with other users having\nan OS::Heat::TemporaryServer which is deleted after a wait condition is\nsignaled (resurrected on each update). This would be useful for hosting\nworkflow code as the workflow doesn\'t actually need to be running all\nthe time. It would also be useful for heat resources that want to run\ncode that needs to be contained into their own VM/network such as the\nport probe thing that came up a few weeks ago.\n\nGood idea? I don\'t know. But it is the next logical step my brain keeps\njumping to for things like this.\n\n> (I\'m conveniently ignoring the fact that you could have set \n> DeletionPolicy: Retain on the image to hack your way around this.)\n> \n> What you\'re looking for is a workflow service (I think it\'s called \n> Mistral this week?). A workflow service would be awesome, and Heat is \n> pretty awesome, but Heat is not a workflow service.\n> \n\nTotally agree. I think workflow and orchestration have an unusual\nrelationship though, because orchestration has its own workflow that\nusers will sometimes need to defer to. This is why we use wait\nconditions, right?\n\n> So yeah, Glance images in Heat might be kinda useful, but at best as a \n> temporary hack to fill in a gap because the Right Place to implement it \n> doesn\'t exist yet. That\'s why I feel ambivalent about it.\n\nI think you\'ve nudged me away from \"optimistic\" at least closer to\n\"ambivalent\" as well.\n\n\n','<52EB18E0.2050405@redhat.com>',NULL),('<1391177561.2255.4.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 09:12:41',-18000,'2014-01-31 14:12:41',NULL,'[openstack-dev] [savanna] Alembic migrations and absence of\n DROP column in sqlite','Okay,  I can accept that migrations shouldn\'t be supported on sqlite.\n\nHowever, if that\'s the case then we need to fix up savanna-db-manage so\nthat it checks the db connection info and throws a polite error to the\nuser for attempted migrations on unsupported platforms. For example:\n\n\"Database migrations are not supported for sqlite\"\n\nBecause, as a developer, when I see a sql error trace as the result of\nan operation I assume it\'s broken :)\n\nBest,\n\nTrevor\n\nOn Thu, 2014-01-30 at 15:04 -0500, Jay Pipes wrote:\n> On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote:\n> > I was playing with alembic migration and discovered that\n> > op.drop_column() doesn\'t work with sqlite.  This is because sqlite\n> > doesn\'t support dropping a column (broken imho, but that\'s another\n> > discussion).  Sqlite throws a syntax error.\n> > \n> > To make this work with sqlite, you have to copy the table to a temporary\n> > excluding the column(s) you don\'t want and delete the old one, followed\n> > by a rename of the new table.\n> > \n> > The existing 002 migration uses op.drop_column(), so I\'m assuming it\'s\n> > broken, too (I need to check what the migration test is doing).  I was\n> > working on an 003.\n> > \n> > How do we want to handle this?  Three good options I can think of:\n> > \n> > 1) don\'t support migrations for sqlite (I think \"no\", but maybe)\n> > \n> > 2) Extend alembic so that op.drop_column() does the right thing (more\n> > open-source contributions for us, yay :) )\n> > \n> > 3) Add our own wrapper in savanna so that we have a drop_column() method\n> > that wraps copy/rename.\n> > \n> > Ideas, comments?\n> \n> Migrations should really not be run against SQLite at all -- only on the\n> databases that would be used in production. I believe the general\n> direction of the contributor community is to be consistent around\n> testing of migrations and to not run migrations at all in unit tests\n> (which use SQLite).\n> \n> Boris (cc\'d) may have some more to say on this topic.\n> \n> Best,\n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1391112275.27339.27.camel@cranky>',NULL),('<1391178898.651626636@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 08:34:58',-21600,'2014-01-31 14:34:58',NULL,'[openstack-dev] [Solum] Deployment units and plans','Hi,\n\nIn this week\'s language pack working group meeting we briefly touched\nupon questions regarding creation of deployment units, their handling\nwith respect to plans, etc.\n\nI have created a etherpad page where I have put these and other questions.\n\nhttps://etherpad.openstack.org/p/RegardingLangPacks\n\nPlease feel free to add more questions and/or answers.\n\nThanks,\nDevdatta\n\n\n\n-----Original Message-----\nFrom: \"Krishna Raman\" <kraman at gmail.com>\nSent: Wednesday, January 29, 2014 1:00am\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Solum][Git] Meeting reminder & agenda\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHi,\n\nWe have a git working group meeting scheduled for tomorrow morning at 9am PST.\nPlease follow link for additional timezones:\nhttp://www.worldtimebuddy.com/?qm=1&lid=100,8,524901,2158177&h=100&date=2014-01-29&sln=17-18\n\nI currently have only 3 things on the agenda:\n	- solum_hacks branch work:\n		- test cases\n		- code organization\n		- patch submission process\n	- integration point with Solum API\n	- integration point with Solum Plan file\n	- integration with LP\n\nPlease let me know if you would like additional items added to the agenda.\n\nThanks\n?Krishna\n\n\n\n','<333A05C4-7453-4365-B752-F3C6778DB7A8@gmail.com>',NULL),('<1391185468-sup-5976@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 08:31:57',-28800,'2014-01-31 16:31:57',NULL,'[openstack-dev] [Heat] How to model resources in Heat','Excerpts from Hugh Brock\'s message of 2014-01-31 04:53:11 -0800:\n> > On Jan 31, 2014, at 1:30 AM, Clint Byrum <clint at fewbar.com> wrote:\n> > \n> > Excerpts from Zane Bitter\'s message of 2014-01-30 19:30:40 -0800:\n> >>> On 30/01/14 16:54, Clint Byrum wrote:\n> >>> I\'m pretty sure it is useful to model images in Heat.\n> >>> \n> >>> Consider this scenario:\n> >>> \n> >>> \n> >>> resources:\n> >>>   build_done_handle:\n> >>>     type: AWS::CloudFormation::WaitConditionHandle\n> >>>   build_done:\n> >>>     type: AWS::CloudFormation::WaitCondition\n> >>>     properties:\n> >>>       handle: {Ref: build_done_handle}\n> >>>   build_server:\n> >>>     type: OS::Nova::Server\n> >>>     properties:\n> >>>       image: build-server-image\n> >>>       userdata:\n> >>>         join [ \"\",\n> >>>           - \"#!/bin/bash\\n\"\n> >>>           - \"build_an_image\\n\"\n> >>>           - \"cfn-signal -s SUCCESS \"\n> >>>           - {Ref: build_done_handle}\n> >>>           - \"\\n\"]\n> >>>   built_image:\n> >>>     type: OS::Glance::Image\n> >>>     depends_on: build_done\n> >>>     properties:\n> >>>       fetch_url: join [ \"\", [\"http://\", {get_attribute: [ build_server, fixed_ip ]}, \"/image_path\"]]\n> >>>   actual_server:\n> >>>     type: OS::Nova::Server\n> >>>     properties:\n> >>>       image: {Ref: built_image}\n> >>> \n> >>> \n> >>> Anyway, seems rather useful. Maybe I\'m reaching.\n> >> \n> >> Well, consider that when this build is complete you\'ll still have the \n> >> server you used to build the image still sitting around. Of course you \n> >> can delete the stack to remove it - and along with it will go the image \n> >> in Glance. Still seem useful?\n> > \n> > No, not as such. However I have also discussed with other users having\n> > an OS::Heat::TemporaryServer which is deleted after a wait condition is\n> > signaled (resurrected on each update). This would be useful for hosting\n> > workflow code as the workflow doesn\'t actually need to be running all\n> > the time. It would also be useful for heat resources that want to run\n> > code that needs to be contained into their own VM/network such as the\n> > port probe thing that came up a few weeks ago.\n> > \n> > Good idea? I don\'t know. But it is the next logical step my brain keeps\n> > jumping to for things like this.\n> > \n> >> (I\'m conveniently ignoring the fact that you could have set \n> >> DeletionPolicy: Retain on the image to hack your way around this.)\n> >> \n> >> What you\'re looking for is a workflow service (I think it\'s called \n> >> Mistral this week?). A workflow service would be awesome, and Heat is \n> >> pretty awesome, but Heat is not a workflow service.\n> > \n> > Totally agree. I think workflow and orchestration have an unusual\n> > relationship though, because orchestration has its own workflow that\n> > users will sometimes need to defer to. This is why we use wait\n> > conditions, right?\n> > \n> >> So yeah, Glance images in Heat might be kinda useful, but at best as a \n> >> temporary hack to fill in a gap because the Right Place to implement it \n> >> doesn\'t exist yet. That\'s why I feel ambivalent about it.\n> > \n> > I think you\'ve nudged me away from \"optimistic\" at least closer to\n> > \"ambivalent\" as well.\n> \n> We (RH tripleo folks) were having a similar conversation around Heat and stack upgrades the other day. There is unquestionably a workflow involving stack updates when a user goes to upgrade their overcloud, and it\'s awkward trying to shoehorn it into Heat (Steve Dake agreed). Our first thought was \"Tuskar should do that,\" but our second thought was \"Whatever the workflow service is should do that, and Tuskar should maybe provide a shorthand API for it.\"\n> \n> I feel like we (tripleo) need to take a harder look at getting a working workflow thing available for our needs, soon...\n> \n\nI agree that is a thought that enters my mind as well.\n\nHowever, I don\'t know if we\'re so much shoe-horning the upgrade workflow\ninto Heat as we are making sure Heat\'s internal workflow is useful so\nthat users don\'t have to write their own workflow to make the expressed\nstack a reality.\n\nI\'ll be starting work on rolling updates for Heat soon. That will provide\nusers with a way to express that they\'d like parallelizable updates to\na certain group to be controlled by a certain waitcondition state. That\nfeels like workflow because we know the implementation is definitely a\nworkflow. However, to the user it is just declaring the rules, they\'re\nnot actually deciding how to do it.\n\nI would hope that having generic workflows inside heat would free users\nfrom drudgery, and they can write workflows when the flow is sufficiently\ncomplex.\n\n\n','<5E761945-D9B6-4DEA-998A-EA209C1A8F46@redhat.com>',NULL),('<1391222943.75494.YahooMailNeo@web125903.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-31 18:49:03',-28800,'2014-02-01 02:49:03',NULL,'[Openstack-docs] training manuals milestone','Operations guide rough draft is completed and published.\nWe are still working through associate and operations guide quiz questions. Migration to Moodle happening soon as well.\n\nStay tuned as we are about to attack the developer guide very soon. ?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140131/1adb373c/attachment.html>\n\n',NULL,NULL),('<1391228559.49800.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-01 12:22:39',28800,'2014-02-01 04:22:39',NULL,'[Openstack] openstack swift storage provisioning','hello all,\n\nplease somebody help me to know:\n\n\nin openstack swift,\nhow does a user come to know whether there is a free space available to store the data or there is a need to add more storage capacity?\n\n-------\nthanks?\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140201/3b9864c8/attachment.html>\n\n',NULL,NULL),('<1391256141.43383.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-01 20:02:21',28800,'2014-02-01 12:02:21',NULL,'[Openstack] openstack swift object put request','hi all,\n\nsomebody help me to understand the following lines of code of ObjectController.PUT() in swift.proxy.controllers.obj.py\n\ndef PUT(self, req):\n????????\"\"\"HTTP PUT request handler.\"\"\"\n-----------\n# do a HEAD request for container sync and checking object versions\n\nif \'x-timestamp\' in req.headers or \\\n????????????????(object_versions and not\n?????????????????req.environ.get(\'swift_versioned_copy\')):\n????????????hreq = Request.blank(req.path_info, headers={\'X-Newest\': \'True\'},\n?????????????????????????????????environ={\'REQUEST_METHOD\': \'HEAD\'})\n????????????hresp = self.GETorHEAD_base(\n????????????????hreq, _(\'Object\'), self.app.object_ring, partition,\n????????????????hreq.swift_entity_path)\n-----------\n\nin the following lines of code, self.GETorHEAD_base() create an HTTPConnection to object server for a HEAD request which is defined in ObjectController.HEAD() of swift.obj.server.py\n\nBut we are in process of putting object, object is not written till yet on the node, then what will it return to hresp?\n\nthanks \nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140201/ab93fe0f/attachment.html>\n\n',NULL,NULL),('<1391311290.42412.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 11:21:30',28800,'2014-02-02 03:21:30',NULL,'[Openstack] openstack swift object put request','please somebody reply.\n\npragya jain\n\n\n\nOn Saturday, 1 February 2014 5:32 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi all,\n>\n>\n>somebody help me to understand the following lines of code of ObjectController.PUT() in swift.proxy.controllers.obj.py\n>\n>\n>def PUT(self, req):\n>????????\"\"\"HTTP PUT request handler.\"\"\"\n>-----------\n># do a HEAD request for container sync and checking object versions\n>\n>if \'x-timestamp\' in req.headers or \\\n>????????????????(object_versions and not\n>?????????????????req.environ.get(\'swift_versioned_copy\')):\n>????????????hreq = Request.blank(req.path_info, headers={\'X-Newest\': \'True\'},\n>?????????????????????????????????environ={\'REQUEST_METHOD\': \'HEAD\'})\n>????????????hresp = self.GETorHEAD_base(\n>????????????????hreq, _(\'Object\'), self.app.object_ring, partition,\n>????????????????hreq.swift_entity_path)\n>-----------\n>\n>\n>in the following lines of code, self.GETorHEAD_base() create an HTTPConnection to object server for a HEAD request which is defined in ObjectController.HEAD() of swift.obj.server.py\n>\n>But we are in process of putting object, object is not written till yet on the node, then what will it return to hresp?\n>\n>\n>thanks \n>Pragya Jain\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140202/b4d501c1/attachment.html>\n\n','<1391256141.43383.YahooMailNeo@web193604.mail.sg3.yahoo.com>',NULL),('<1391320965.43338.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 14:02:45',28800,'2014-02-02 06:02:45',NULL,'[Openstack] storage virtualization','hi all\n\nmy query is:\n\nIs openstack swift virtualize the storage to store the data?\nAnd how does openstack swift implement it?\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140202/010782b0/attachment.html>\n\n',NULL,NULL),('<1391333824.69822.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 17:37:04',28800,'2014-02-02 09:37:04',NULL,'[Openstack] storage virtualization','I am not talking about cinder.\nMy question is:\nOpenstack swift provides storage as a service to the user so that user can store their data offline.\nwhen a user store some data on swift using Object PUT command, data is stored as an object at some storage node.\n1. What is this storage node - Is it a physical hard disk?\n2. to store the data, Is swift virtualize the physical storage or directly store the data on physical disk?\n3. Is there any need of storage virtualization in swift?\n\nThanks?\nPragya Jain\n\n\n\nOn Sunday, 2 February 2014 11:55 AM, Aryeh Friedman <aryeh.friedman at gmail.com> wrote:\n \nYou mean you need to access cinder or are you wondering what component handles storage (cinder then is the answer)\n>\n>\n>\n>\n>On Sun, Feb 2, 2014 at 1:02 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hi all\n>>\n>>\n>>my query is:\n>>\n>>\n>>Is openstack swift virtualize the storage to store the data?\n>>And how does openstack swift implement it?\n>>\n>>\n>>Pragya Jain\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>-- \n>\n>Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140202/293dfe30/attachment.html>\n\n','<CAGBxaX=WQsh-3kSD53iWPDqTiQe8dr5uFy1kC0fROjukBj6F7A@mail.gmail.com>',NULL),('<1391339559.20346.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 19:12:39',28800,'2014-02-02 11:12:39',NULL,'[Openstack] storage virtualization','thanks for reply Cedric\n\nwhat does swift do for adding more devices as storage node?\nhow does swift abstract storage from the devices?\nAnd how swift recognise whether there is free space on a particular storage node to store data?\n\n\n\nOn Sunday, 2 February 2014 4:23 PM, C?dric Lemarchand <c.lemarchand at yipikai.org> wrote:\n \nAs of my comprehension and the way you ask, swift didn\'t \"virtualize\" the storage, there are no layer between the swift stack and final storage. The back end are simple FS (ext4 or xfs, or else) on which data are stored (replicated x times/check summed ect ...). Of course the objects are not stored \"as is\", like on a simple file server.?\n>\n>\n>Cheers\n>\n>--\n>C?dric Lemarchand\n>\n>Le 2 f?vr. 2014 ? 10:37, pragya jain <prag_2648 at yahoo.co.in> a ?crit?:\n>\n>\n>I am not talking about cinder.\n>>My question is:\n>>Openstack swift provides storage as a service to the user so that user can store their data offline.\n>>when a user store some data on swift using Object PUT command, data is stored as an object at some storage node.\n>>1. What is this storage node - Is it a physical hard disk?\n>>2. to store the data, Is swift virtualize the physical storage or directly store the data on physical disk?\n>>3. Is there any need of storage virtualization in swift?\n>>\n>>\n>>Thanks?\n>>Pragya Jain\n>>\n>>\n>>\n>>On Sunday, 2 February 2014 11:55 AM, Aryeh Friedman <aryeh.friedman at gmail.com> wrote:\n>> \n>>You mean you need to access cinder or are you wondering what component handles storage (cinder then is the answer)\n>>>\n>>>\n>>>\n>>>\n>>>On Sun, Feb 2, 2014 at 1:02 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hi all\n>>>>\n>>>>\n>>>>my query is:\n>>>>\n>>>>\n>>>>Is openstack swift virtualize the storage to store the data?\n>>>>And how does openstack swift implement it?\n>>>>\n>>>>\n>>>>Pragya Jain\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>-- \n>>>\n>>>Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org\n>>>\n>>>\n>>>\n>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ????: openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140202/18d1a1c8/attachment.html>\n\n','<058B327C-CBDE-4A00-A447-5A48F5CB9EA4@yipikai.org>',NULL),('<1391345621.28887.YahooMailNeo@web163805.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-02 04:53:41',-28800,'2014-02-02 12:53:41',NULL,'[openstack-dev] [solum] Issues in running tests','Hi,\nI am facing some errors running tests in a fresh installation of solum\n\n$tox -e py27\n>\n>\n>....\n>\n>\n>gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w\n>\n>\n>In file included from src/lxml/lxml.etree.c:340:0:\n>\n>\n>/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes/etree_defs.h:9:31: fatal error: libxml/xmlversion.h: No such file or directory\n>\n>\n>compilation terminated.\n>\n>\n>error: command \'gcc\' failed with exit status 1\n>\n>\n>----------------------------------------\n\nThanks\nRajdeep\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140202/b1090518/attachment.html>\n\n',NULL,NULL),('<1391359600.46286.YahooMailNeo@web163806.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-02 08:46:40',-28800,'2014-02-02 16:46:40',NULL,'[openstack-dev] [solum] Issues in running tests','Thanks that worked\n\n\n\nOn Sunday, February 2, 2014 7:17 PM, Julien Vey <vey.julien at gmail.com> wrote:\n \nHi?Rajdeep,\n\nWe just updated the documentation?recently with some necessary packages to install :??libxml2-dev and libxslt-dev.\n\nYou just need to install those 2 packages.?\nIf you are on Ubuntu, see?http://stackoverflow.com/questions/6504810/how-to-install-lxml-on-ubuntu/6504860#6504860\n\nJulien\n\n\n\n2014-02-02 Rajdeep Dua <dua_rajdeep at yahoo.com>:\n\nHi,\n>I am facing some errors running tests in a fresh installation of solum\n>\n>\n>$tox -e py27\n>>\n>>\n>>....\n>>\n>>\n>>gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w\n>>\n>>\n>>In file included from src/lxml/lxml.etree.c:340:0:\n>>\n>>\n>>/home/hadoop/work/openstack/solum-2/solum/.tox/py27/build/lxml/src/lxml/includes/etree_defs.h:9:31: fatal error: libxml/xmlversion.h: No such file or directory\n>>\n>>\n>>compilation terminated.\n>>\n>>\n>>error: command \'gcc\' failed with exit status 1\n>>\n>>\n>>----------------------------------------\n>\n>\n>Thanks\n>Rajdeep\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140202/5cbcfcce/attachment.html>\n\n','<CAP4JdAHz9sknYfitON0jgbQFEXEssppOvP1i-z5PWd5zUYUEwg@mail.gmail.com>',NULL),('<1391369626.21537.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-02 14:33:46',-18000,'2014-02-02 19:33:46',NULL,'[openstack-dev] [nova] massive number of new errors in logs\n with oslo.messaging','On Sun, 2014-02-02 at 07:13 -0500, Sean Dague wrote:\n> Just noticed this at the end of a successful run:\n> \n> http://logs.openstack.org/15/63215/13/check/check-tempest-dsvm-full/2636cae/console.html#_2014-02-02_12_02_44_422\n> \n> It looks like the merge of oslo.messaging brings a huge amount of false\n> negative error messages in the logs. Would be good if we didn\'t ship\n> icehouse with this state of things.\n\nAgreed.\n\nAnd the error messages, which look like this:\n\nReturning exception Unexpected task state: expecting [u\'scheduling\',\nNone] but the actual state is deleting to caller\n\ndon\'t make sense -- at least in the English language.\n\nWhat does \"the actual state is deleting to caller\" mean?\n\nBest,\n-jay\n\n\n\n','<52EE3670.3040003@dague.net>',NULL),('<1391370272.21537.8.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 14:44:32',-18000,'2014-02-02 19:44:32',NULL,'[Openstack] openstack swift object put request','On Sun, 2014-02-02 at 11:21 +0800, pragya jain wrote:\n> please somebody reply.\n\nThis question belongs on the openstack-dev mailing list, and don\'t\nforget to use a [swift] topic in your ML post subject line.\n\nBest,\n-jay\n\n> pragya jain\n> \n> \n> On Saturday, 1 February 2014 5:32 PM, pragya jain\n> <prag_2648 at yahoo.co.in> wrote:\n> \n>         hi all,\n>         \n>         \n>         somebody help me to understand the following lines of code of\n>         ObjectController.PUT() in swift.proxy.controllers.obj.py\n>         \n>         \n>         def PUT(self, req):\n>                 \"\"\"HTTP PUT request handler.\"\"\"\n>         -----------\n>         # do a HEAD request for container sync and checking object\n>         versions\n>         \n>         if \'x-timestamp\' in req.headers or \\\n>                         (object_versions and not\n>                          req.environ.get(\'swift_versioned_copy\')):\n>                     hreq = Request.blank(req.path_info,\n>         headers={\'X-Newest\': \'True\'},\n>                                          environ={\'REQUEST_METHOD\':\n>         \'HEAD\'})\n>                     hresp = self.GETorHEAD_base(\n>                         hreq, _(\'Object\'), self.app.object_ring,\n>         partition,\n>                         hreq.swift_entity_path)\n>         -----------\n>         \n>         \n>         in the following lines of code, self.GETorHEAD_base() create\n>         an HTTPConnection to object server for a HEAD request which is\n>         defined in ObjectController.HEAD() of swift.obj.server.py\n>         \n>         But we are in process of putting object, object is not written\n>         till yet on the node, then what will it return to hresp?\n>         \n>         \n>         thanks \n>         Pragya Jain\n>         \n>         \n>         \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<1391311290.42412.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1391374945.3703.20.camel@lappy.neofreak.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-02 16:02:25',-18000,'2014-02-02 21:02:25',NULL,'[Openstack] port on openvswitch not tagged upon VM launch','Hi list,\n\ni have a nearly working neutron + openvswitch + VLAN setup but, i have a\nsmall problem however...\n\nI am running neutron-server on a node controller and\nneutron-openvswitch-agent and neutron-dhcp-agent running on a compute\nnode.\n\nOn the compute node, i have an initial bridge, with two physical\ninterfaces in bonding, with some VLANs trunked on the bond.\n\nOn the controller node, i created a network with --provider:network_type\nvlan and --provider:segmentation_id xxx (xxx being one of the VLAN\ntrunked on the bond inside my initial bridge). Then, i created a subnet\non that network.\n\nWhen i launch neutron-dhcp-agent on the compute node, everything seem\nfine : the namespace is being created, there is a port with tag 1 on the\nintegration bridge for the dnsmasq process and, i can ping the IP of the\ndnsmasq process from a device on the xxx vlan. I can also see the\nopenflow flows for vlan modification on both bridge (vlan xxx to vlan 1,\nvlan 1 to vlan xxx).\n\nHowever, my problem is that when i launch a VM using the network i\ncreated in neutron, a port is being created in the integration bridge\nbut, it is not tagged with vlan 1 so, the VM is unable to communicate on\nthe network. As soon as i tag the port with vlan 1, with a command\nlike : \n\novs-vsctl set Port tap1234-ab tag=1 \n\nthe VM is able to communicate on the network.\n\n\nSo, am i missing something obvious? Or maybe that i have something\nmisconfigured in my neutron setup?\n\n\nAny help would be greatly appreciated.\n\nRegards,\n\nTony\n\n\n\n',NULL,NULL),('<1391376831-sup-5711@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-02 13:39:35',-28800,'2014-02-02 21:39:35',NULL,'[openstack-dev] [TripleO] [Ironic] Roadmap towards heterogenous\n	hardware support','Excerpts from Jaromir Coufal\'s message of 2014-02-02 11:19:25 -0800:\n> On 2014/30/01 23:33, Devananda van der Veen wrote:\n> > I was responding based on \"Treat similar hardware configuration as\n> > equal\". When there is a very minor difference in hardware (eg, 1TB vs\n> > 1.1TB disks), enrolling them with the same spec (1TB disk) is sufficient\n> > to solve all these issues and mask the need for multiple flavors, and\n> > the hardware wouldn\'t need to be re-enrolled.\n> I disagree here, of course user can register HW as they wish, it\'s their \n> responsibility. But asking them to register nodes as equal (even if they \n> are close) is going to be mess and huge confusion for users. You would \n> actually ask user to enter non-real data - so that he can use our \n> deployment tool somehow. From my point of view, this is not right \n> approach and I would better see him entering correct information and us \n> working with it.\n> \n\nI totally understand the desire to have it all make sense to users. I\nwonder if the desire to have something working well in the next 30 days\nshould override the desire.\n\nMy thought is that early adopters are used to this sort of\nwork-around. \"Accept this bit of weirdness, and you get all this\nawesomeness\". In this case \"Register hardware with similar specs as\nidentical specs, and you will get automatic deployment over heterogeneous\nhardware.\"\n\nIf we keep the scope narrow enough, those users only have to wait a few\nmore months to be able to make their hardware registrations more accurate.\n\n\n','<52EE9A3D.7010909@redhat.com>',NULL),('<1391399833.19350968.1387339400553.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-17 23:03:20',-18000,'2013-12-18 04:03:20',NULL,'[Openstack-docs] Upgrading to Havana','Hi all, \nAm triaging for bug day, and have signed up to do the upgrade notes (perhaps not on bug day, but you know what I mean). However, er, where should they go? \n\nCurrently, I\'m only seeing the notes in the Ops manual, was there a consensus to put them somewhere else? \nA new Upgrading article for the Havana page? The Installation Guide is already too bulky (would think). \nOr have I missed them completely somewhere else? \n\nShould they also be pulled out of the Ops guide (since upgrading is SO version-specific)? \n\nthanks, Summer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20131217/dce2f65f/attachment.html>\n\n','<CAD0KtVFRd-4Y-xiR5RTCrzmf+vz40GWaOUb1TRb+1WhCrFGrEg@mail.gmail.com>',NULL),('<1391419626.50654.YahooMailNeo@web172401.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-03 09:27:06',0,'2014-02-03 09:27:06',NULL,'[Openstack] port on openvswitch not tagged upon VM launch','Hi,\n\nthe ovs-agent is responsible for tagging the port. It\'s strange\nthat it can tag the dhcp port ok but not the nova port. What VIF\ndriver are you using - libvirt_vif_driver in nova.conf?\n\nCheck the syslog - all the ovs-vsctl commands are logged there.\nLook for messages about this port. Are there any errors in the\novs-agent log?\n\nRe, Darragh.\n\n>i have a nearly working neutron + openvswitch + VLAN setup but, i have a\n>small problem however...\n>\n>I am running neutron-server on a node controller and\n>neutron-openvswitch-agent and neutron-dhcp-agent running on a compute\n>node.\n>\n>On the compute node, i have an initial bridge, with two physical\n>interfaces in bonding, with some VLANs trunked on the bond.\n>\n>On the controller node, i created a network with --provider:network_type\n>vlan and --provider:segmentation_id xxx (xxx being one of the VLAN\n>trunked on the bond inside my initial bridge). Then, i created a subnet\n>on that network.\n>\n>When i launch neutron-dhcp-agent on the compute node, everything seem\n>fine : the namespace is being created, there is a port with tag 1 on the\n>integration bridge for the dnsmasq process and, i can ping the IP of the\n>dnsmasq process from a device on the xxx vlan. I can also see the\n>openflow flows for vlan modification on both bridge (vlan xxx to vlan 1,\n>vlan 1 to vlan xxx).\n>\n>However, my problem is that when i launch a VM using the network i\n>created in neutron, a port is being created in the integration bridge\n>but, it is not tagged with vlan 1 so, the VM is unable to communicate on\n>the network. As soon as i tag the port with vlan 1, with a command\n>like : \n>\n>ovs-vsctl set Port tap1234-ab tag=1 \n>\n>the VM is able to communicate on the network.\n>\n>\n>So, am i missing something obvious? Or maybe that i have something\n>misconfigured in my neutron setup?\n>\n>\n>Any help would be greatly appreciated.\n>\n>Regards,\n>\n>Tony\n\n\n',NULL,NULL),('<1391440437.21537.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 10:13:57',-18000,'2014-02-03 15:13:57',NULL,'[openstack-dev] [glance][nova]improvement-of-accessing-to-glance','On Mon, 2014-02-03 at 10:03 +0100, Flavio Percoco wrote:\n> IMHO, the bit that should really be optimized is the selection of the\n> store nodes where the image should be downloaded from. That is,\n> selecting the nearest location from the image locations and this is\n> something that perhaps should happen in glance-api, not nova.\n\nI disagree. The reason is because glance-api does not know where nova\nis. Nova does.\n\nI continue to think that the best performance gains will come from\ngetting rid of glance-api entirely, putting the block-streaming bits\ninto a separate Python library, and having Nova and Cinder pull\nimage/volume bits directly from backend storage instead of going through\nthe glance middleman.\n\nBest,\n-jay\n\n\n\n','<20140203090336.GC23799@redhat.com>',NULL),('<1391446186.035930010@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 10:49:46',-21600,'2014-02-03 16:49:46',NULL,'[openstack-dev] [Solum] Lang-pack working group meeting\n	cancelled today due to freenode DOS, will be rescheduled','Which time zone?\n\nOn Wednesdays between 11.00am - noon (US Central time) there is git integration working group meeting.\n\n\n-----Original Message-----\nFrom: \"Clayton Coleman\" <ccoleman at redhat.com>\nSent: Monday, February 3, 2014 10:35am\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Solum] Lang-pack working group meeting cancelled today due to freenode DOS, will be rescheduled\n\nMaybe wednesday at noon?\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<432515094.10234483.1391445345746.JavaMail.root@redhat.com>',NULL),('<1391449144.21537.29.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 12:39:04',-18000,'2014-02-03 17:39:04',NULL,'[openstack-dev] [Solum] Solum database schema modification\n proposal','On Mon, 2014-02-03 at 16:22 +0000, Paul Montgomery wrote:\n> Solum community,\n> \n> I notice that we are using String(36) UUID values in the database\n> schema as primary key for many new tables that we are creating.  For\n> example:\n> https://review.openstack.org/#/c/68328/10/solum/objects/sqlalchemy/application.py\n> \n> Proposal: Add an int or bigint ID as the primary key, instead of UUID\n> (the UUID field remains if needed), to improve database efficiency.\n\n-1 for this particular case.\n\nUsing auto-incrementing primary keys can be beneficial in many use cases\n-- particularly when trying to create a \"hot spot\" on disk for tables\nwith very high write to read ratios, like logging-type tables. \n\nHowever, autoincrementing primary keys come with some baggage when used\nin large distributed database systems that UUIDs don\'t come with.\nNamely, if you run Solum in multiple deployment zones or cells, you will\nhave primary key collision if you try to aggregate those databases into,\nsay, a data warehouse. With UUID primary keys, you won\'t have that\ntrouble.\n\nIn addition, for InnoDB tables in MySQL (as well as PostgreSQL and MS\nSQL Server), the choice of primary key is critical, as it determines the\norder by which the clustered index-organized tables are written to disk.\nIf the data you are looking up is accessed by the primary key, it will\nbe faster to store the records on disk in that order. Since you are not\nadvocating exposing the autoincrementing primary key to the user, the\ndatabase query for a record would need to do one non-clustered index\nlookup into the index on UUID to find the autoincrementing primary key\nvalue of the record in question, and then retrieve the record from the\nclustered index on disk (or in the InnoDB buffer pool, which is also\nordered by primary key [1]). Two seek operations, versus only one if the\nUUID is used as a primary key.\n\nAgain, autoincrementing are useful in many scenarios. But in this\nparticular case, I don\'t believe there would be a whole lot of value.\n\nBest,\n-jay\n\n[1] Technically the InnoDB buffer pool contain unordered records within\neach 16KB page, and a small ordered PK to slot number catalog at the\ntail end of each data page, but the effect is the same.\n\n\n\n','<CF151E6B.166CA%paul.montgomery@rackspace.com>',NULL),('<1391449468.21537.31.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 12:44:28',-18000,'2014-02-03 17:44:28',NULL,'[openstack-dev] [glance][nova]improvement-of-accessing-to-glance','On Mon, 2014-02-03 at 17:04 +0100, Flavio Percoco wrote:\n> On 03/02/14 10:13 -0500, Jay Pipes wrote:\n> >On Mon, 2014-02-03 at 10:03 +0100, Flavio Percoco wrote:\n> >> IMHO, the bit that should really be optimized is the selection of the\n> >> store nodes where the image should be downloaded from. That is,\n> >> selecting the nearest location from the image locations and this is\n> >> something that perhaps should happen in glance-api, not nova.\n> >\n> >I disagree. The reason is because glance-api does not know where nova\n> >is. Nova does.\n> \n> Nova doesn\'t know where glance is either. More info is required in\n> order to finally do something smart here. Not sure what the best\n> approach is just yet but as mentioned in my previous email I think\n> focusing on the stores for now is the thing to do. (As you pointed out\n> bellow too).\n\nRight, which is why I am recommending to get rid of glance-api below...\n\n> >I continue to think that the best performance gains will come from\n> >getting rid of glance-api entirely, putting the block-streaming bits\n> >into a separate Python library, and having Nova and Cinder pull\n> >image/volume bits directly from backend storage instead of going through\n> >the glance middleman.\n> \n> This is exactly what we\'re doing by pulling glance.store into its own\n> library. I\'m working on this myself. We are not completely getting rid\n> of glance-api but we\'re working on not depending on it to get the\n> image data.\n\nCool. Have you pushed a patch for this I can see?\n\nThanks, Flavio!\n-jay\n\n\n\n','<20140203160446.GE23799@redhat.com>',NULL),('<1391449709-sup-8437@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 09:52:09',-28800,'2014-02-03 17:52:09',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates spec re-written.\n	RFC','So, I wrote the original rolling updates spec about a year ago, and the\ntime has come to get serious about implementation. I went through it and\nbasically rewrote the entire thing to reflect the knowledge I have\ngained from a year of working with Heat.\n\nAny and all comments are welcome. I intend to start implementation very\nsoon, as this is an important component of the HA story for TripleO:\n\nhttps://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates\n\n\n',NULL,NULL),('<1391454037.3703.30.camel@lappy.neofreak.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-03 14:00:37',-18000,'2014-02-03 19:00:37',NULL,'[Openstack] port on openvswitch not tagged upon VM launch','Hi,\n\nthanks for the info, it helped me going a bit further with this.\n\nI did not have anything configured regarding vif in my nova.conf file on\nmy compute node.\n\nSo i tried putting the following :\n\nlibvirt_vif_driver=nova.virt.libvirt.vif.LibvirtGenericVIFDriver\nlibvirt_ovs_bridge=br-int\nlibvirt_use_virtio_for_bridges=true\n\nin my nova.conf config file on my compute node but it did not help.\n\nSo i wanted to have a better look at the neutron logs but, they were\nfull of : \'iptables-restore: line 62 failed\\n\'\nmessages so, it was a bit hard to figure something out.\n\nSo i tried to disable the firewall driver, by changing :\n\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\nto :\n\nfirewall_driver = neutron.agent.firewall.NoopFirewallDriver\n\nin my ovs_neutron_plugin.ini config file and surprisingly, it started\nworking, the port is tagged automatically.\n\nThat brings me to my next question, why would the port be tagged\ncorrectly with firewall_driver set to\nneutron.agent.firewall.NoopFirewallDriver but not with\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n?!\n\n@Ageeleshwar Kandavelu\n\nI don\'t have physical interfaces on my integration bridge, just on my\nnormal (first) bridge (in my case br0).\n\n\nThank you so much!\n\nTony\n\nOn Mon, 2014-02-03 at 09:27 +0000, Darragh O\'Reilly wrote:\n> Hi,\n> \n> the ovs-agent is responsible for tagging the port. It\'s strange\n> that it can tag the dhcp port ok but not the nova port. What VIF\n> driver are you using - libvirt_vif_driver in nova.conf?\n> \n> Check the syslog - all the ovs-vsctl commands are logged there.\n> Look for messages about this port. Are there any errors in the\n> ovs-agent log?\n> \n> Re, Darragh.\n> \n> >i have a nearly working neutron + openvswitch + VLAN setup but, i have a\n> >small problem however...\n> >\n> >I am running neutron-server on a node controller and\n> >neutron-openvswitch-agent and neutron-dhcp-agent running on a compute\n> >node.\n> >\n> >On the compute node, i have an initial bridge, with two physical\n> >interfaces in bonding, with some VLANs trunked on the bond.\n> >\n> >On the controller node, i created a network with --provider:network_type\n> >vlan and --provider:segmentation_id xxx (xxx being one of the VLAN\n> >trunked on the bond inside my initial bridge). Then, i created a subnet\n> >on that network.\n> >\n> >When i launch neutron-dhcp-agent on the compute node, everything seem\n> >fine : the namespace is being created, there is a port with tag 1 on the\n> >integration bridge for the dnsmasq process and, i can ping the IP of the\n> >dnsmasq process from a device on the xxx vlan. I can also see the\n> >openflow flows for vlan modification on both bridge (vlan xxx to vlan 1,\n> >vlan 1 to vlan xxx).\n> >\n> >However, my problem is that when i launch a VM using the network i\n> >created in neutron, a port is being created in the integration bridge\n> >but, it is not tagged with vlan 1 so, the VM is unable to communicate on\n> >the network. As soon as i tag the port with vlan 1, with a command\n> >like : \n> >\n> >ovs-vsctl set Port tap1234-ab tag=1 \n> >\n> >the VM is able to communicate on the network.\n> >\n> >\n> >So, am i missing something obvious? Or maybe that i have something\n> >misconfigured in my neutron setup?\n> >\n> >\n> >Any help would be greatly appreciated.\n> >\n> >Regards,\n> >\n> >Tony\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<1391419626.50654.YahooMailNeo@web172401.mail.ir2.yahoo.com>',NULL),('<1391454868.21537.36.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 14:14:28',-18000,'2014-02-03 19:14:28',NULL,'[openstack-dev] [glance][nova]improvement-of-accessing-to-glance','On Mon, 2014-02-03 at 10:59 -0800, Mark Washenberger wrote:\n\n> On Mon, Feb 3, 2014 at 7:13 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Mon, 2014-02-03 at 10:03 +0100, Flavio Percoco wrote:\n>         > IMHO, the bit that should really be optimized is the\n>         selection of the\n>         > store nodes where the image should be downloaded from. That\n>         is,\n>         > selecting the nearest location from the image locations and\n>         this is\n>         > something that perhaps should happen in glance-api, not\n>         nova.\n>         \n>         \n>         I disagree. The reason is because glance-api does not know\n>         where nova\n>         is. Nova does.\n>         \n>         I continue to think that the best performance gains will come\n>         from\n>         getting rid of glance-api entirely, putting the\n>         block-streaming bits\n>         into a separate Python library, and having Nova and Cinder\n>         pull\n>         image/volume bits directly from backend storage instead of\n>         going through\n>         the glance middleman.\n> \n> \n> When you say get rid of glance-api, do you mean the glance server\n> project? or glance-api as opposed to glance-registry? \n\nI mean the latter.\n\n> If its the latter, I think we\'re basically in agreement. However,\n> there may be a little bit of a terminology distinction that is\n> important. Here is the plan that is currently underway:\n> \n> 1) Deprecate the registry deployment (done when v1 is deprecated)\n> 2) v2 glance api talks directly to the underlying database (done)\n> 3) Create a library in the images program that allows OpenStack\n> projects to share code for reading image data remotely and picking\n> optimal paths for bulk data transfer (In progress under the\n> \"glance.store\" title)\n> 4) v2 exposes locations that clients can directly access (partially\n> done, continues to need a lot of improvement)\n> 5) v2 still allows downloading images from the glance server as a\n> compatibility and lowest-common-denominator feature\n\nAll good.\n\n> In 4, some work is complete, and some more is planned, but we still\n> need some more planning and design to figure out how to support\n> directly downloading images in a secure and general way.\n\nSounds good to me :)\n\nBest,\n-jay\n\n\n\n\n','<CAJyP2C9qhQ9d7qyBJsBVk8xhkopu7ZXJSrA5LmNuMewGp5r6zw@mail.gmail.com>',NULL),('<1391456482-sup-7885@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 11:51:05',-28800,'2014-02-03 19:51:05',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates spec\n	re-written. RFC','Excerpts from Robert Collins\'s message of 2014-02-03 10:47:06 -0800:\n> Quick thoughts:\n> \n>  - I\'d like to be able to express a minimum service percentage: e.g. I\n> know I need 80% of my capacity available at anyone time, so an\n> additional constraint to the unit counts, is to stay below 20% down at\n> a time (and this implies that if 20% have failed, either stop or spin\n> up more nodes before continuing).\n> \n\nRight will add that.\n\nOne thing though, all failures lead to rollback. I put that in the\n\'Unresolved issues\' section. Continuing a group operation with any\nfailures is an entirely different change to Heat. We have a few choices,\nfrom a whole re-thinking of how we handle failures, to just a special\ntype of resource group that tolerates failure percentages.\n\n> The wait condition stuff seems to be conflating in the \'graceful\n> operations\' stuff we discussed briefly at the summit, which in my head\n> at least is an entirely different thing - it\'s per node rather than\n> per group. If done separately that might make each feature\n> substantially easier to reason about.\n\nAgreed. I think something more generic than an actual Heat wait condition\nwould make more sense. Perhaps even returning all of the active scheduler\ntasks which the update must wait on would make sense. Then in the\n\"graceful update\" version we can just make the dynamically created wait\nconditions depend on the update pattern, which would have the same effect.\n\nWith the \"maximum out of service\" addition, we\'ll also need to make sure\nthat upon the \"must wait for these\" things completing we evaluate state\nagain before letting the update proceed.\n\n\n','<CAJ3HoZ3jo7Ptxa8k=iLXmLMK4sHo4qYN57O0XpUXO1X5qMekoQ@mail.gmail.com>',NULL),('<1391464621-sup-4293@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 14:09:35',-28800,'2014-02-03 22:09:35',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates spec\n	re-written. RFC','Excerpts from Thomas Herve\'s message of 2014-02-03 12:46:05 -0800:\n> > So, I wrote the original rolling updates spec about a year ago, and the\n> > time has come to get serious about implementation. I went through it and\n> > basically rewrote the entire thing to reflect the knowledge I have\n> > gained from a year of working with Heat.\n> > \n> > Any and all comments are welcome. I intend to start implementation very\n> > soon, as this is an important component of the HA story for TripleO:\n> > \n> > https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates\n> \n> Hi Clint, thanks for pushing this.\n> \n> First, I don\'t think RollingUpdatePattern and CanaryUpdatePattern should be 2 different entities. The second just looks like a parametrization of the first (growth_factor=1?).\n\nPerhaps they can just be one. Until I find parameters which would need\nto mean something different, I\'ll just use UpdatePattern.\n\n> \n> I then feel that using (abusing?) depends_on for update pattern is a bit weird. Maybe I\'m influenced by the CFN design, but the separate UpdatePolicy attribute feels better (although I would probably use a property). I guess my main question is around the meaning of using the update pattern on a server instance. I think I see what you want to do for the group, where child_updating would return a number, but I have no idea what it means for a single resource. Could you detail the operation a bit more in the document?\n> \n\nI would be o-k with adding another keyword. The idea in abusing depends_on\nis that it changes the core language less. Properties is definitely out\nfor the reasons Christopher brought up, properties is really meant to\nbe for the resource\'s end target only.\n\nUpdatePolicy in cfn is a single string, and causes very generic rolling\nupdate behavior. I want this resource to be able to control multiple\ngroups as if they are one in some cases (Such as a case where a user\nhas migrated part of an app to a new type of server, but not all.. so\nthey will want to treat the entire aggregate as one rolling update).\n\nI\'m o-k with overloading it to allow resource references, but I\'d like\nto hear more people take issue with depends_on before I select that\ncourse.\n\nTo answer your question, using it with a server instance allows\nrolling updates across non-grouped resources. In the example the\nrolling_update_dbs does this.\n\n> It also seems that the interface you\'re creating (child_creating/child_updating) is fairly specific to your use case. For autoscaling we have a need for more generic notification system, it would be nice to find common grounds. Maybe we can invert the relationship? Add a \"notified_resources\" attribute, which would call hooks on the \"parent\" when actions are happening.\n> \n\nI\'m open to a different interface design. I don\'t really have a firm\ngrasp of the generic behavior you\'d like to model though. This is quite\nconcrete and would be entirely hidden from template authors, though not\nfrom resource plugin authors. Attributes sound like something where you\nwant the template authors to get involved in specifying, but maybe that\nwas just an overloaded term.\n\nSo perhaps we can replace this interface with the generic one when your\nuse case is more clear?\n\n\n','<966620715.789074.1391460365842.JavaMail.zimbra@enovance.com>',NULL),('<1391465434.9655.14.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-03 17:10:34',-18000,'2014-02-03 22:10:34',NULL,'[openstack-dev] [savanna] Specific job type for streaming\n mapreduce? (and someday pipes)','\nI was trying my best to avoid adding extra job types to support\nmapreduce variants like streaming or mapreduce with pipes, but it seems\nthat adding the types is the simplest solution.\n\nOn the API side, Savanna can live without a specific job type by\nexamining the data in the job record.  Presence/absence of certain\nthings, or null values, etc, can provide adequate indicators to what\nkind of mapreduce it is.  Maybe a little bit subtle.\n\nBut for the UI, it seems that explicit knowledge of what the job is\nmakes things easier and better for the user.  When a user creates a\nstreaming mapreduce job and the UI is aware of the type later on at job\nlaunch, the user can be prompted to provide the right configs (i.e., the\nstreaming mapper and reducer values).\n\nThe explicit job type also supports validation without having to add\nextra flags (which impacts the savanna client, and the JSON, etc). For\nexample, a streaming mapreduce job does not require any specified\nlibraries so the fact that it is meant to be a streaming job needs to be\nknown at job creation time.\n\nSo, to that end, I propose that we add a MapReduceStreaming job type,\nand probably at some point we will have MapReducePiped too. It\'s\npossible that we might have other job types in the future too as the\nfeature set grows.\n\nThere was an effort to make Savanna job types parallel Oozie action\ntypes, but in this case that\'s just not possible without introducing a\n\"subtype\" field in the job record, which leads to a database migration\nscript and savanna client changes.\n\nWhat do you think?\n\nBest,\n\nTrevor\n\n\n\n\n',NULL,NULL),('<1391528258.2423.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 15:37:38',0,'2014-02-04 15:37:38',NULL,'[openstack-dev] pep8 gating fails due to\n tools/config/check_uptodate.sh','On Mon, 2014-01-13 at 16:49 +0000, Sahid Ferdjaoui wrote:\n> Hello all,\n> \n> It looks 100% of the pep8 gate for nova is failing because of a bug reported, \n> we probably need to mark this as Critical.\n> \n>    https://bugs.launchpad.net/nova/+bug/1268614\n> \n> Ivan Melnikov has pushed a patchset waiting for review:\n>    https://review.openstack.org/#/c/66346/\n> \n> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==\n\nThis just came up on #openstack-infra ...\n\nIt\'s a general problem that is going to occur more frequently.\n\nNova now includes config options from keystoneclient and oslo.messaging\nin its sample config file.\n\nThat means that as soon as a new option is added to either library, then\ncheck_uptodate.sh will start failing.\n\nOne option discussed is to remove the sample config files from source\ncontrol and have the sample be generated at build/packaging time.\n\nSo long as we minimize the dependencies required to generate the sample\nfile, this should be manageable.\n\nMark.\n\n\n\n','<969701727.20846176.1389631791761.JavaMail.root@cloudwatt.com>',NULL),('<1391531765.2423.75.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 16:36:05',0,'2014-02-04 16:36:05',NULL,'[openstack-dev] pep8 gating fails due to\n tools/config/check_uptodate.sh','On Wed, 2014-02-05 at 01:19 +0900, Sean Dague wrote:\n> On 02/05/2014 12:37 AM, Mark McLoughlin wrote:\n> > On Mon, 2014-01-13 at 16:49 +0000, Sahid Ferdjaoui wrote:\n> >> Hello all,\n> >>\n> >> It looks 100% of the pep8 gate for nova is failing because of a bug reported, \n> >> we probably need to mark this as Critical.\n> >>\n> >>    https://bugs.launchpad.net/nova/+bug/1268614\n> >>\n> >> Ivan Melnikov has pushed a patchset waiting for review:\n> >>    https://review.openstack.org/#/c/66346/\n> >>\n> >> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRVJST1I6IEludm9jYXRpb25FcnJvcjogXFwnL2hvbWUvamVua2lucy93b3Jrc3BhY2UvZ2F0ZS1ub3ZhLXBlcDgvdG9vbHMvY29uZmlnL2NoZWNrX3VwdG9kYXRlLnNoXFwnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjQzMjAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTM4OTYzMTQzMzQ4OSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==\n> > \n> > This just came up on #openstack-infra ...\n> > \n> > It\'s a general problem that is going to occur more frequently.\n> > \n> > Nova now includes config options from keystoneclient and oslo.messaging\n> > in its sample config file.\n> > \n> > That means that as soon as a new option is added to either library, then\n> > check_uptodate.sh will start failing.\n> > \n> > One option discussed is to remove the sample config files from source\n> > control and have the sample be generated at build/packaging time.\n> > \n> > So long as we minimize the dependencies required to generate the sample\n> > file, this should be manageable.\n> \n> The one big drawback here is that today you can point people to a git\n> url, and they will then have a sample config file for Nova (or Tempest\n> or whatever you are pointing them at). If this is removed, then we\'ll\n> need / want some other way to make those samples easily available on the\n> web, not only at release time.\n\nI think that\'s best addressed by automatically publishing to somewhere\nother than git.openstack.org. AFAIR there\'s already been a bunch of work\ndone around automatically pulling config options into the docs.\n\n> On a related point, It\'s slightly bothered me that we\'re allow libraries\n> to define stanzas in our config files. It seems like a leaky abstraction\n\nIt is a little unusual, yes.\n\n> that\'s only going to get worse over time as we graduate more of oslo,\n> and the coupling gets even worse.\n\nWorse in what respect?\n\n> Has anyone considered if it\'s possible to stop doing that, and have the\n> libraries only provide an object model that takes args and instead leave\n> config declaration to the instantiation points for those objects?\n\nI think that would result in useless duplication (of those declarations)\nand leave us open to projects having different config file options for\nthe same things.\n\n> Because having a nova.conf file that\'s 30% options coming from\n> underlying libraries that are not really controlable in nova seems like\n> a recipe for a headache.\n\nWhy?\n\n> We already have a bunch of that issue today\n> with changing 3rd party logging libraries in oslo, that mostly means to\n> do that in nova we first just go and change the incubator, then sync the\n> changes back.\n\nThat\'s a different issue - if we had a properly abstracted logging API,\nwe could commit to future API compat and publish an oslo.logging\nlibrary.\n\nThe syncing pain you describe would go away, and the proper abstraction\nwould mean the things that Nova needs to control would be under Nova\'s\ncontrol.\n\n> I do realize this would be a rather substantial shift from current\n> approach, but current approach seems to be hitting a new complexity\n> point that we\'re only just starting to feel the pain on.\n\nThe issue at hand is that we\'ve discovered that checking an\nautogenerated file into git causes issues ... hardly the first time\nwe\'ve learned that lesson.\n\nMark.\n\n\n\n','<52F11301.5070305@dague.net>',NULL),('<1391533630.069618325@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 11:07:10',-21600,'2014-02-04 17:07:10',NULL,'[openstack-dev] [Solum] Lang-pack working group meeting\n	cancelled today due to freenode DOS, will be rescheduled','Sounds good to me.\n\n- Devdatta\n\n-----Original Message-----\nFrom: \"Clayton Coleman\" <ccoleman at redhat.com>\nSent: Monday, February 3, 2014 12:10pm\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Solum] Lang-pack working group meeting cancelled today due to freenode DOS, will be rescheduled\n\nGood point.  We can try immediately after the git inter workflow if folks prefer.  12pm US CST, 1pm EST.\n\n----- Original Message -----\n> Which time zone?\n> \n> On Wednesdays between 11.00am - noon (US Central time) there is git\n> integration working group meeting.\n> \n> \n> -----Original Message-----\n> From: \"Clayton Coleman\" <ccoleman at redhat.com>\n> Sent: Monday, February 3, 2014 10:35am\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: [openstack-dev] [Solum] Lang-pack working group meeting cancelled\n> today due to freenode DOS, will be rescheduled\n> \n> Maybe wednesday at noon?\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<294528672.10295809.1391451010692.JavaMail.root@redhat.com>',NULL),('<1391539633.5141.4.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 13:47:13',-18000,'2014-02-04 18:47:13',NULL,'[openstack-dev] [savanna] Specific job type for streaming\n mapreduce? (and someday pipes)','Thanks Andrew.\n\nMy author thought, which is in between, is to allow dotted types.\n\"MapReduce.streaming\" for example.\n\nThis gives you the subtype flavor but keeps all the APIs the same.\nWe just need a wrapper function to separate them when we compare types.\n\nBest,\n\nTrevor\n\nOn Mon, 2014-02-03 at 14:57 -0800, Andrew Lazarev wrote:\n> I see two points:\n> * having Savanna types mapped to Oozie action types is intuitive for\n> hadoop users and this is something we would like to keep\n> * it is hard to distinguish different kinds of one job type\n> \n> \n> Adding \'subtype\' field will solve both problems. Having it optional\n> will not break backward compatibility. Adding database migration\n> script is also pretty straightforward.\n> \n> \n> Summarizing, my vote is on \"subtype\" field.\n> \n> \n> Thanks,\n> Andrew.\n> \n> \n> On Mon, Feb 3, 2014 at 2:10 PM, Trevor McKay <tmckay at redhat.com>\n> wrote:\n>         \n>         I was trying my best to avoid adding extra job types to\n>         support\n>         mapreduce variants like streaming or mapreduce with pipes, but\n>         it seems\n>         that adding the types is the simplest solution.\n>         \n>         On the API side, Savanna can live without a specific job type\n>         by\n>         examining the data in the job record.  Presence/absence of\n>         certain\n>         things, or null values, etc, can provide adequate indicators\n>         to what\n>         kind of mapreduce it is.  Maybe a little bit subtle.\n>         \n>         But for the UI, it seems that explicit knowledge of what the\n>         job is\n>         makes things easier and better for the user.  When a user\n>         creates a\n>         streaming mapreduce job and the UI is aware of the type later\n>         on at job\n>         launch, the user can be prompted to provide the right configs\n>         (i.e., the\n>         streaming mapper and reducer values).\n>         \n>         The explicit job type also supports validation without having\n>         to add\n>         extra flags (which impacts the savanna client, and the JSON,\n>         etc). For\n>         example, a streaming mapreduce job does not require any\n>         specified\n>         libraries so the fact that it is meant to be a streaming job\n>         needs to be\n>         known at job creation time.\n>         \n>         So, to that end, I propose that we add a MapReduceStreaming\n>         job type,\n>         and probably at some point we will have MapReducePiped too.\n>         It\'s\n>         possible that we might have other job types in the future too\n>         as the\n>         feature set grows.\n>         \n>         There was an effort to make Savanna job types parallel Oozie\n>         action\n>         types, but in this case that\'s just not possible without\n>         introducing a\n>         \"subtype\" field in the job record, which leads to a database\n>         migration\n>         script and savanna client changes.\n>         \n>         What do you think?\n>         \n>         Best,\n>         \n>         Trevor\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CANzyysgV8DcO_O=ZC_TFvkGFX3Hfn7xittEzB0gQA4XFb=+Neg@mail.gmail.com>',NULL),('<1391547707.5141.7.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 16:01:47',-18000,'2014-02-04 21:01:47',NULL,'[openstack-dev] savann-ci,\n Re: [savanna] Alembic migrations and absence of DROP column in\n sqlite','This brings up an interesting problem:\n\nIn https://review.openstack.org/#/c/70420/ I\'ve added a migration that\nuses a drop column for an upgrade.\n\nBut savann-ci is apparently using a sqlite database to run.  So it can\'t\npossibly pass.\n\nWhat do we do here?  Shift savanna-ci tests to non sqlite?\n\nTrevor\n\nOn Sat, 2014-02-01 at 18:17 +0200, Roman Podoliaka wrote:\n> Hi all,\n> \n> My two cents.\n> \n> > 2) Extend alembic so that op.drop_column() does the right thing\n> We could, but should we?\n> \n> The only reason alembic doesn\'t support these operations for SQLite\n> yet is that SQLite lacks proper support of ALTER statement. For\n> sqlalchemy-migrate we\'ve been providing a work-around in the form of\n> recreating of a table and copying of all existing rows (which is a\n> hack, really).\n> \n> But to be able to recreate a table, we first must have its definition.\n> And we\'ve been relying on SQLAlchemy schema reflection facilities for\n> that. Unfortunately, this approach has a few drawbacks:\n> \n> 1) SQLAlchemy versions prior to 0.8.4 don\'t support reflection of\n> unique constraints, which means the recreated table won\'t have them;\n> \n> 2) special care must be taken in \'edge\' cases (e.g. when you want to\n> drop a BOOLEAN column, you must also drop the corresponding CHECK (col\n> in (0, 1)) constraint manually, or SQLite will raise an error when the\n> table is recreated without the column being dropped)\n> \n> 3) special care must be taken for \'custom\' type columns (it\'s got\n> better with SQLAlchemy 0.8.x, but e.g. in 0.7.x we had to override\n> definitions of reflected BIGINT columns manually for each\n> column.drop() call)\n> \n> 4) schema reflection can\'t be performed when alembic migrations are\n> run in \'offline\' mode (without connecting to a DB)\n> ...\n> (probably something else I\'ve forgotten)\n> \n> So it\'s totally doable, but, IMO, there is no real benefit in\n> supporting running of schema migrations for SQLite.\n> \n> > ...attempts to drop schema generation based on models in favor of migrations\n> \n> As long as we have a test that checks that the DB schema obtained by\n> running of migration scripts is equal to the one obtained by calling\n> metadata.create_all(), it\'s perfectly OK to use model definitions to\n> generate the initial DB schema for running of unit-tests as well as\n> for new installations of OpenStack (and this is actually faster than\n> running of migration scripts). ... and if we have strong objections\n> against doing metadata.create_all(), we can always use migration\n> scripts for both new installations and upgrades for all DB backends,\n> except SQLite.\n> \n> Thanks,\n> Roman\n> \n> On Sat, Feb 1, 2014 at 12:09 PM, Eugene Nikanorov\n> <enikanorov at mirantis.com> wrote:\n> > Boris,\n> >\n> > Sorry for the offtopic.\n> > Is switching to model-based schema generation is something decided? I see\n> > the opposite: attempts to drop schema generation based on models in favor of\n> > migrations.\n> > Can you point to some discussion threads?\n> >\n> > Thanks,\n> > Eugene.\n> >\n> >\n> >\n> > On Sat, Feb 1, 2014 at 2:19 AM, Boris Pavlovic <bpavlovic at mirantis.com>\n> > wrote:\n> >>\n> >> Jay,\n> >>\n> >> Yep we shouldn\'t use migrations for sqlite at all.\n> >>\n> >> The major issue that we have now is that we are not able to ensure that DB\n> >> schema created by migration & models are same (actually they are not same).\n> >>\n> >> So before dropping support of migrations for sqlite & switching to model\n> >> based created schema we should add tests that will check that model &\n> >> migrations are synced.\n> >> (we are working on this)\n> >>\n> >>\n> >>\n> >> Best regards,\n> >> Boris Pavlovic\n> >>\n> >>\n> >> On Fri, Jan 31, 2014 at 7:31 PM, Andrew Lazarev <alazarev at mirantis.com>\n> >> wrote:\n> >>>\n> >>> Trevor,\n> >>>\n> >>> Such check could be useful on alembic side too. Good opportunity for\n> >>> contribution.\n> >>>\n> >>> Andrew.\n> >>>\n> >>>\n> >>> On Fri, Jan 31, 2014 at 6:12 AM, Trevor McKay <tmckay at redhat.com> wrote:\n> >>>>\n> >>>> Okay,  I can accept that migrations shouldn\'t be supported on sqlite.\n> >>>>\n> >>>> However, if that\'s the case then we need to fix up savanna-db-manage so\n> >>>> that it checks the db connection info and throws a polite error to the\n> >>>> user for attempted migrations on unsupported platforms. For example:\n> >>>>\n> >>>> \"Database migrations are not supported for sqlite\"\n> >>>>\n> >>>> Because, as a developer, when I see a sql error trace as the result of\n> >>>> an operation I assume it\'s broken :)\n> >>>>\n> >>>> Best,\n> >>>>\n> >>>> Trevor\n> >>>>\n> >>>> On Thu, 2014-01-30 at 15:04 -0500, Jay Pipes wrote:\n> >>>> > On Thu, 2014-01-30 at 14:51 -0500, Trevor McKay wrote:\n> >>>> > > I was playing with alembic migration and discovered that\n> >>>> > > op.drop_column() doesn\'t work with sqlite.  This is because sqlite\n> >>>> > > doesn\'t support dropping a column (broken imho, but that\'s another\n> >>>> > > discussion).  Sqlite throws a syntax error.\n> >>>> > >\n> >>>> > > To make this work with sqlite, you have to copy the table to a\n> >>>> > > temporary\n> >>>> > > excluding the column(s) you don\'t want and delete the old one,\n> >>>> > > followed\n> >>>> > > by a rename of the new table.\n> >>>> > >\n> >>>> > > The existing 002 migration uses op.drop_column(), so I\'m assuming\n> >>>> > > it\'s\n> >>>> > > broken, too (I need to check what the migration test is doing).  I\n> >>>> > > was\n> >>>> > > working on an 003.\n> >>>> > >\n> >>>> > > How do we want to handle this?  Three good options I can think of:\n> >>>> > >\n> >>>> > > 1) don\'t support migrations for sqlite (I think \"no\", but maybe)\n> >>>> > >\n> >>>> > > 2) Extend alembic so that op.drop_column() does the right thing\n> >>>> > > (more\n> >>>> > > open-source contributions for us, yay :) )\n> >>>> > >\n> >>>> > > 3) Add our own wrapper in savanna so that we have a drop_column()\n> >>>> > > method\n> >>>> > > that wraps copy/rename.\n> >>>> > >\n> >>>> > > Ideas, comments?\n> >>>> >\n> >>>> > Migrations should really not be run against SQLite at all -- only on\n> >>>> > the\n> >>>> > databases that would be used in production. I believe the general\n> >>>> > direction of the contributor community is to be consistent around\n> >>>> > testing of migrations and to not run migrations at all in unit tests\n> >>>> > (which use SQLite).\n> >>>> >\n> >>>> > Boris (cc\'d) may have some more to say on this topic.\n> >>>> >\n> >>>> > Best,\n> >>>> > -jay\n> >>>> >\n> >>>> >\n> >>>> > _______________________________________________\n> >>>> > OpenStack-dev mailing list\n> >>>> > OpenStack-dev at lists.openstack.org\n> >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAKA_ueC=w9DPAkqdZaXiGUpxBm557yLNjGsui4E9DLScL7ErXQ@mail.gmail.com>',NULL),('<1391547954-sup-1514@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 13:06:25',-28800,'2014-02-04 21:06:25',NULL,'[openstack-dev] Ugly Hack to deal with multiple versions','Excerpts from Jesse Noller\'s message of 2014-02-04 11:55:57 -0800:\n> \n> On Feb 4, 2014, at 1:28 PM, Sean Dague <sean at dague.net> wrote:\n> \n> > On 02/05/2014 01:50 AM, Jesse Noller wrote:\n> >> \n> >> On Feb 4, 2014, at 10:31 AM, Sean Dague <sean at dague.net> wrote:\n> >> \n> >>> On 02/05/2014 01:09 AM, Dean Troyer wrote:\n> >>>> On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <sean at dague.net\n> >>>> <mailto:sean at dague.net>> wrote:\n> >>>> \n> >>>>   Can you be more specific about what goes wrong here? I\'m not entirely\n> >>>>   sure I understand why an old client of arbitrary age needs to be\n> >>>>   supported with new OpenStack. The contract is the API, not the client,\n> >>>>   and an old client that doesn\'t do version discovery is just a buggy\n> >>>>   client from what I\'m concerned. Time to release a new version.\n> >>>> \n> >>>> \n> >>>> Problem 1: API version discovery is not universally considered to be\n> >>>> part of the API and therefore is not defined by most services beyond\n> >>>> them responding to a \'/\' request with a 300 response and a list of\n> >>>> versions. No two of these responses look alike except where the source\n> >>>> was copied from an existing service.\n> >>>> \n> >>>> Problem 2: Identity is unique in that it is handed a deployment-defined\n> >>>> URL to authenticate and get endpoints for all other services.  Most of\n> >>>> these auth URLs have a version hard-coded in them because the client\n> >>>> didn\'t do version discovery or negotiation until recently.  This is what\n> >>>> we\'re talking about here, how to remove the version from this URL and\n> >>>> not break old clients.  We can\'t.  Not without doing nasty things like\n> >>>> detecting an old client and compensating for it server-side.  So we have\n> >>>> to work out a way for new clients to do discovery even when handed a URL\n> >>>> that has a version in it.\n> >>>> \n> >>>> I\'ve tested a couple of more generalized approaches, and the best\n> >>>> solution I have found so far is to simply special-case the known legacy\n> >>>> behaviour then drop in to the general discovery process. \n> >>>> \n> >>>>   I also wonder if this is an issue with version discovery implementation.\n> >>>>   It seems like if we think this is going to be affecting multiple\n> >>>>   services before doing an odd hack for keystone, we should actually\n> >>>>   figure out a pattern that works for all services, and figure out why\n> >>>>   this has only just become an issue. Most of the other services have done\n> >>>> \n> >>>> \n> >>>> The services that traditionally embed a version inside the URL followed\n> >>>> by a tenant ID or something get even deeper into parsing the URL to hack\n> >>>> the version.\n> >>>> \n> >>>>   dual APIs at some point over the last 2 years, and this didn\'t seem to\n> >>>>   trip them up too badly. What happened differently in keystone that made\n> >>>>   this an issue? And what can be learned about how we structure APIs going\n> >>>>   forward.\n> >>>> \n> >>>> \n> >>>> I think the difference is this is the first API we have actually tried\n> >>>> to deprecate and we don\'t have the option to hide it in an updated SC\n> >>>> endpoint.  The service catalog has hidden a lot of this pain for other\n> >>>> services because the clients generally can use whatever endpoint the SC\n> >>>> gives it.\n> >>>> \n> >>>> \n> >>>> a) Version discovery needs to be rationalized across the services.\n> >>>> We\'ve talked about this at summits before, and proposals have been\n> >>>> written.  And here we are.  We\'ll do it again in Atlanta, hopefully for\n> >>>> the last time.\n> >>>> \n> >>>> b) Define a common structured endpoint and let the client assemble the\n> >>>> components into the final URL.  If the service catalog had a base URL\n> >>>> for compute, and a list of versions, and the additional bits to be\n> >>>> appended the client could make an intelligent choice and assemble the\n> >>>> endpoint.  It isn\'t like the client doesn\'t already have to know how the\n> >>>> REST URLs are constructed.\n> >>>> \n> >>>> b-alt) Stop putting things like tenant IDs in the SC.  This has the same\n> >>>> issue as the auth URL in how to do this without instantly breaking the\n> >>>> existing clients.\n> >>> \n> >>> Ok, much clearer now to me (though I\'ll still claim jetlag for some bits\n> >>> not sinking in).\n> >>> \n> >>> I think a really important thing to keep in mind is any solution that\'s\n> >>> implemented client side, is something that all the other OpenStack SDKs\n> >>> are going to have to implement as well. So an ugly hack isn\'t just\n> >>> python-keystone... and be done. It\'s also just hoisted doing that ugly\n> >>> hack on the php / go sdk teams, jclouds, deltacloud, etc. Something they\n> >>> may not be aware is going to break them, or their users.\n> >> \n> >> Do we have official openstack PHP / go SDKs?\n> > \n> > Official is a strong word, but we do have stackforge teams active on it:\n> > * https://github.com/stackforge/openstack-sdk-php\n> > * https://github.com/stackforge/golang-client\n> > \n> > And I think we should should be mindful of their work to make OpenStack\n> > easily accessible from their language communities.\n> \n> \n> Oh for sure - but I was wondering because there?s also:\n> \n> jclouds (java): http://jclouds.apache.org/ \n> \n> php-opencloud (php): https://github.com/rackspace/php-opencloud \n> \n> fog (ruby): http://fog.io/\n> \n> libcloud (python):  http://libcloud.apache.org/\n> \n> gophercloud (go): https://github.com/rackspace/gophercloud\n> \n> openstack .net (.net): https://github.com/rackspace/openstack.net\n\nAnd goose\n\nhttps://launchpad.net/goose\n\n> \n> So finding a go client and php one one stackforge is surprising - wondering if we can combine efforts - on my end I have full time people staffing *just* the client-side SDKs across all of these. So yes - we are sensitive to API changes.\n> \n> Jesse\n\n\n','<3BE22F9B-88D1-430B-B6A3-C83183A3FCDF@rackspace.com>',NULL),('<1391558151.6903.33.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 18:55:51',-18000,'2014-02-04 23:55:51',NULL,'[openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit\n Jenkins plugin will not fulfill requirements of 3rd party testing','Sorry for cross-posting to both mailing lists, but there\'s lots of folks\nworking on setting up third-party testing platforms that are not members\nof the openstack-infra ML...\n\ntl;dr\n-----\n\nThe third party testing documentation [1] has requirements [2] that\ninclude the ability to trigger a recheck based on a gerrit comment.\n\nUnfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the\nability to trigger job runs based on a regex-filtered comment (only on\nthe existence of any new comment to the code review).\n\nTherefore, we either should:\n\na) Relax the requirement that the third party system trigger test\nre-runs when a comment including the word \"recheck\" appears in the\nGerrit event stream\n\nb) Modify the Jenkins Gerrit plugin to support regex filtering on the\ncomment text (in the same way that it currently supports regex filtering\non the project name)\n\nor\n\nc) Add documentation to the third party testing pages that explains how\nto use Zuul as a replacement for the Jenkins Gerrit plugin.\n\nI propose we do a) for the short term, and I\'ll work on c) long term.\nHowever, I\'m throwing this out there just in case there are some Java\nand Jenkins whizzes out there that could get b) done in a jiffy.\n\ndetails\n-------\n\nOK, so I\'ve been putting together documentation on how to set up an\nexternal Jenkins platform that is \"linked\" [4] with the upstream\nOpenStack CI system.\n\nRecently, I wrote an article detailing how the upstream CI system\nworked, including a lot of the gory details from the\nopenstack-infra/config project\'s files. [5]\n\nI\'ve been working on a follow-up article that goes through how to set up\na Jenkins system, and in writing that article, I created a source\nrepository [6] that contains scripts, instructions and Puppet modules\nthat set up a Jenkins system, the Jenkins Job Builder tool, and\ninstalls/configures the Jenkins Gerrit plugin [7].\n\nI planned to use the Jenkins Gerrit plugin as the mechanism that\ntriggers Jenkins jobs on the external system based on gerrit events\npublished by the OpenStack review.openstack.org Gerrit service. In\naddition to being mentioned in the third party documentation, Jenkins\nJob Builder has the ability to construct Jenkins jobs that are triggered\nby the Jenkins Gerrit plugin [8].\n\nUnforunately, I\'ve run into a bit of a snag.\n\nThe third party testing documentation has requirements that include the\nability to trigger a recheck based on a gerrit comment:\n\n<quote>\nSupport recheck to request re-running a test.\n * Support the following syntaxes recheck no bug and recheck bug ###.\n * Recheck means recheck everything. A single recheck comment should\nre-trigger all testing systems.\n</quote>\n\nThe documentation has a section on using the Gerrit Jenkins Trigger\nplugin [3] to accept notifications from the upstream OpenStack Gerrit\ninstance.\n\nBut unfortunately, the Jenkins Gerrit plugin does not support the\nability to trigger a re-run of a job given a regex match of the word\n\"recheck\". :(\n\nSo, we either need to a) change the requirements of third party testers,\nb) enhance the Jenkins Gerrit plugin with the missing functionality, or\nc) add documentation on how to set up Zuul as the triggering system\ninstead of the Jenkins Gerrit plugin.\n\nI\'m happy to work on c), but I think relaxing the restriction (a) is\nprobably needed short-term.\n\nBest,\n-jay\n\n[1] http://ci.openstack.org/third_party.html\n[2] http://ci.openstack.org/third_party.html#requirements\n[3]\nhttp://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way\n[4] By \"linked\" I mean it both reads from the OpenStack Gerrit system\nand writes (adds comments) to it\n[5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n[6] http://github.com/jaypipes/os-ext-testing\n[7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger\n[8]\nhttps://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121\n\n\n\n\n',NULL,NULL),('<1391558151.6903.33.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-04 18:55:51',-18000,'2014-02-04 23:55:51',NULL,'[OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit\n Jenkins plugin will not fulfill requirements of 3rd party testing','Sorry for cross-posting to both mailing lists, but there\'s lots of folks\nworking on setting up third-party testing platforms that are not members\nof the openstack-infra ML...\n\ntl;dr\n-----\n\nThe third party testing documentation [1] has requirements [2] that\ninclude the ability to trigger a recheck based on a gerrit comment.\n\nUnfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the\nability to trigger job runs based on a regex-filtered comment (only on\nthe existence of any new comment to the code review).\n\nTherefore, we either should:\n\na) Relax the requirement that the third party system trigger test\nre-runs when a comment including the word \"recheck\" appears in the\nGerrit event stream\n\nb) Modify the Jenkins Gerrit plugin to support regex filtering on the\ncomment text (in the same way that it currently supports regex filtering\non the project name)\n\nor\n\nc) Add documentation to the third party testing pages that explains how\nto use Zuul as a replacement for the Jenkins Gerrit plugin.\n\nI propose we do a) for the short term, and I\'ll work on c) long term.\nHowever, I\'m throwing this out there just in case there are some Java\nand Jenkins whizzes out there that could get b) done in a jiffy.\n\ndetails\n-------\n\nOK, so I\'ve been putting together documentation on how to set up an\nexternal Jenkins platform that is \"linked\" [4] with the upstream\nOpenStack CI system.\n\nRecently, I wrote an article detailing how the upstream CI system\nworked, including a lot of the gory details from the\nopenstack-infra/config project\'s files. [5]\n\nI\'ve been working on a follow-up article that goes through how to set up\na Jenkins system, and in writing that article, I created a source\nrepository [6] that contains scripts, instructions and Puppet modules\nthat set up a Jenkins system, the Jenkins Job Builder tool, and\ninstalls/configures the Jenkins Gerrit plugin [7].\n\nI planned to use the Jenkins Gerrit plugin as the mechanism that\ntriggers Jenkins jobs on the external system based on gerrit events\npublished by the OpenStack review.openstack.org Gerrit service. In\naddition to being mentioned in the third party documentation, Jenkins\nJob Builder has the ability to construct Jenkins jobs that are triggered\nby the Jenkins Gerrit plugin [8].\n\nUnforunately, I\'ve run into a bit of a snag.\n\nThe third party testing documentation has requirements that include the\nability to trigger a recheck based on a gerrit comment:\n\n<quote>\nSupport recheck to request re-running a test.\n * Support the following syntaxes recheck no bug and recheck bug ###.\n * Recheck means recheck everything. A single recheck comment should\nre-trigger all testing systems.\n</quote>\n\nThe documentation has a section on using the Gerrit Jenkins Trigger\nplugin [3] to accept notifications from the upstream OpenStack Gerrit\ninstance.\n\nBut unfortunately, the Jenkins Gerrit plugin does not support the\nability to trigger a re-run of a job given a regex match of the word\n\"recheck\". :(\n\nSo, we either need to a) change the requirements of third party testers,\nb) enhance the Jenkins Gerrit plugin with the missing functionality, or\nc) add documentation on how to set up Zuul as the triggering system\ninstead of the Jenkins Gerrit plugin.\n\nI\'m happy to work on c), but I think relaxing the restriction (a) is\nprobably needed short-term.\n\nBest,\n-jay\n\n[1] http://ci.openstack.org/third_party.html\n[2] http://ci.openstack.org/third_party.html#requirements\n[3]\nhttp://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way\n[4] By \"linked\" I mean it both reads from the OpenStack Gerrit system\nand writes (adds comments) to it\n[5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n[6] http://github.com/jaypipes/os-ext-testing\n[7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger\n[8]\nhttps://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121\n\n\n\n\n',NULL,NULL),('<1391597405.29477.YahooMailNeo@web140406.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-05 02:50:05',-28800,'2014-02-05 10:50:05',NULL,'[Openstack] Plaintext password in getCredential token','The current username/password authentication mechanism is not the best security practice. However, assuming there is a point to point secure channel, the risk of password exposure can be contained. In addition to that, one can always choose external authentication plugged with Keystone e.g., your own middleware in the pipeline or Kerberos ( not fully functional yet). Some hints are provided in keystone guideline:?\nhttp://docs.openstack.org/developer/keystone/external-auth.html\n\n\n\n\nOn Wednesday, February 5, 2014 12:25 PM, \"Clark, Robert Graham\" <robert.clark at hp.com> wrote:\n \nOn Wed Feb? 5 08:34:34 2014, Rob Crittenden wrote:\n> Emanuel Marzini wrote:\n>> Hi,\n>> I have a software that uses Openstack. When it do an action for the\n>> first time, it need to get a token from Openstack. How it\'s possible\n>> make a POST request like:\n>>\n>> \'{\"auth\":{\"passwordCredentials\":{\"username\": \"joeuser\", \"password\":\n>> \"secrete\"}}}\' -H \"Content-type: application/json\"\n>> http://localhost:35357/v2.0/tokens\n>>\n>> without pass the password in plaintext???\n>>\n>> It\'s possible use PKI, ssl and so on?\n>\n> The documentation on this is scant but you can start with something like\n> http://docs.openstack.org/developer/keystone/configuration.html\n>\n> You\'ll need to create new endpoints for the SSL provider and set\n> OS_SERVICE_ENDPOINT to the secure version.\n>\n> If you want to disable/remove the unsecure ports things get rather\n> interesting as you\'ll need to configure all the other services to use\n> this as well. I don\'t know how well or if that actually works everywhere.\n>\n> rob\n>\n\nYou might find some of the guidance from the OpenStack Security Guide \nuseful too: \nhttp://docs.openstack.org/security-guide/content/ch024_authentication.html\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140205/b5058c47/attachment.html>\n\n','<A0C170085C37664D93EE1604364858A1101DD37B@G4W3300.americas.hpqcorp.net>',NULL),('<1391600547.2357.25.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-05 11:42:27',0,'2014-02-05 11:42:27',NULL,'[OpenStack Foundation] The two types of interoperability','On Wed, 2014-02-05 at 12:21 +0100, Thierry Carrez wrote:\n> Hi everyone,\n> \n> As you all know, the DefCore effort is working on redefining \"core\" (and\n> associated permitted usage of the OpenStack trademark), with the end\n> goal of fostering interoperability.\n> \n> Interoperability is good, and everyone agrees we need it. However,\n> \"interoperability\" is a single word describing two very different\n> outcomes, and using that word until now prevented having a necessary\n> discussion on what type of interoperability we are actually after.\n> \n> There are two types of interoperability. I call the first one \"loose\n> interoperability\". The idea is to minimize the set of constraints, and\n> maximize the ecosystem able to call themselves \"openstack\" (or\n> \"interoperable\").\n> \n> I call the second one \"total interoperability\". The idea is to maximize\n> the set of constraints, and have less deployments be able to call\n> themselves \"openstack\" (but have that lucky few share more common traits).\n> \n> Loose interoperability enables differentiation and is business-friendly\n> (larger ecosystem). Total interoperability enables federation and is\n> end-user-friendly (easier to move workloads from one openstack to\n> another, as they share more).\n> \n> We can continue defining the process, but now we need to choose between\n> those two types of interoperability, as it affects the implementation\n> details (how we designate \"must-use\" parts of the code and determine\n> \"must-pass\" tests).\n> \n> I think it\'s more than time we look beyond the process and decide what\n> is our end goal here.\n\nVery nicely put, Thierry. I agree we need to be crystal clear on our\ninteroperability goals, otherwise arguing over the implementation\ndetails of our interoperability program is fairly futile.\n\nI tried and failed to express that idea here:\n\n  http://blogs.gnome.org/markmc/2013/10/30/openstack-core-and-interoperability/\n\n  I think the focus should be on immediate baby-steps towards\n  kick-starting this marketplace. One simple question ? if and when we\n  certify the first batch of interoperable clouds, would we rather have\n  a smaller number of big clouds included or a large number of smaller\n  clouds? In terms of resource capacity provided by this marketplace, I\n  guess it?s more-or-less the same thing.\n\n  Let?s assume we absolutely want (at least) a small number of the\n  bigger providers included in the program at launch. Let?s say ?small\n  number? equals ?Rackspace and HP?. And let?s assume both of these\n  providers are very keen to help get this program started. Isn?t the\n  obvious next baby-step to get representatives of those two providers\n  to figure out exactly what level of interoperability they already have\n  and also what improvements to that they can make in the short term?\n\n  If we had that report, we could next do a quick ?sniff test? comparing\n  this to many of the other OpenStack clouds out there to make sure we\n  haven?t just picked two clouds with an unusual set of compatible APIs.\n  Then the board could make a call on whether this represents a\n  reasonable starting point for the requirements of OpenStack clouds.\n\n  No, this isn?t perfect. But it would be a genuine step forward towards\n  being able to certify some clouds. We would have some data on\n  commonalities and have made a policy decision on what commonalities\n  are required. It would be a starting point.\n\n\nBasically, I\'d love to be able to look at a chart which plots\ninteroperability against the size of the interoperable\nmarketplace/ecosystem. And then we could have a rationale discussion\nabout whether we aim for higher interop, even if that means a tiny\ninteroperable marketplace, or a larger interoperable marketplace with a\ntiny level of interoperability.\n\nIt\'s a difficult trade-off, but it\'s *the* important decision for the\nboard to make. I\'d prefer to be making that decision with data rather\nthan in the abstract but, in the absence of data, I think the board\nshould be discussing it.\n\nTo put the question another way - which helps users more? The ability to\nwrite interoperable code which uses a large number of OpenStack APIs,\nbut which is only actually interoperable between a small number of\nOpenStack clouds? Or interoperability whereby you have a smaller set of\ninteroperable APIs, but code that uses only those APIs would be\ninteroperable with a much larger number of OpenStack clouds?\n\nMy instinct would be to start with the set of APIs which are already\ninteroperable between the highest profile OpenStack clouds and build a\ncampaign around enlarging the set of APIs every release without damaging\nthe size of the interoperable ecosystem.\n\nMark.\n\n\n\n','<52F21EB9.20704@openstack.org>',NULL),('<1391602178.2357.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 12:09:38',0,'2014-02-05 12:09:38',NULL,'[openstack-dev] [Openstack-docs] Conventions on naming','On Wed, 2014-02-05 at 11:52 +0100, Thierry Carrez wrote:\n> Steve Gordon wrote:\n> >> From: \"Anne Gentle\" <anne.gentle at rackspace.com>\n> >> Based on today\'s Technical Committee meeting and conversations with the\n> >> OpenStack board members, I need to change our Conventions for service names\n> >> at\n> >> https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names\n> >> .\n> >>\n> >> Previously we have indicated that Ceilometer could be named OpenStack\n> >> Telemetry and Heat could be named OpenStack Orchestration. That\'s not the\n> >> case, and we need to change those names.\n> >>\n> >> To quote the TC meeting, ceilometer and heat are \"other modules\" (second\n> >> sentence from 4.1 in\n> >> http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/)\n> >> distributed with the Core OpenStack Project.\n> >>\n> >> Here\'s what I intend to change the wiki page to:\n> >>  Here\'s the list of project and module names and their official names and\n> >> capitalization:\n> >>\n> >> Ceilometer module\n> >> Cinder: OpenStack Block Storage\n> >> Glance: OpenStack Image Service\n> >> Heat module\n> >> Horizon: OpenStack dashboard\n> >> Keystone: OpenStack Identity Service\n> >> Neutron: OpenStack Networking\n> >> Nova: OpenStack Compute\n> >> Swift: OpenStack Object Storage\n> \n> Small correction. The TC had not indicated that Ceilometer could be\n> named \"OpenStack Telemetry\" and Heat could be named \"OpenStack\n> Orchestration\". We formally asked[1] the board to allow (or disallow)\n> that naming (or more precisely, that use of the trademark).\n> \n> [1]\n> https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names\n> \n> We haven\'t got a formal and clear answer from the board on that request\n> yet. I suspect they are waiting for progress on DefCore before deciding.\n> \n> If you need an answer *now* (and I suspect you do), it might make sense\n> to ask foundation staff/lawyers about using those OpenStack names with\n> the current state of the bylaws and trademark usage rules, rather than\n> the hypothetical future state under discussion.\n\nBasically, yes - I think having the Foundation confirm that it\'s\nappropriate to use \"OpenStack Telemetry\" in the docs is the right thing.\n\nThere\'s an awful lot of confusion about the subject and, ultimately,\nit\'s the Foundation staff who are responsible for enforcing (and giving\nadvise to people on) the trademark usage rules. I\'ve cc-ed Jonathan so\nhe knows about this issue.\n\nBut FWIW, the TC\'s request is asking for Ceilometer and Heat to be\nallowed use their \"Telemetry\" and \"Orchestration\" names in *all* of the\ncircumstances where e.g. Nova is allowed use its \"Compute\" name.\n\nReading again this clause in the bylaws:\n\n  \"The other modules which are part of the OpenStack Project, but\n   not the Core OpenStack Project may not be identified using the\n   OpenStack trademark except when distributed with the Core OpenStack\n   Project.\"\n\nit could well be said that this case of naming conventions in the docs\nfor the entire OpenStack Project falls under the \"distributed with\" case\nand it is perfectly fine to refer to \"OpenStack Telemetry\" in the docs.\nI\'d really like to see the Foundation staff give their opinion on this,\nthough.\n\nThanks,\nMark.\n\n\n\n','<52F21803.2010302@openstack.org>',NULL),('<1391602460.2357.36.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-05 12:14:20',0,'2014-02-05 12:14:20',NULL,'[OpenStack Foundation] The two types of interoperability','On Wed, 2014-02-05 at 13:04 +0100, Thierry Carrez wrote:\n> Mark McLoughlin wrote:\n> > To put the question another way - which helps users more? The ability to\n> > write interoperable code which uses a large number of OpenStack APIs,\n> > but which is only actually interoperable between a small number of\n> > OpenStack clouds? Or interoperability whereby you have a smaller set of\n> > interoperable APIs, but code that uses only those APIs would be\n> > interoperable with a much larger number of OpenStack clouds?\n> \n> I like your way of framing the question.\n> \n> Personally I think going for loose interoperability is short-sighted.\n> Yes you\'ll have a lot of providers but you\'ll forever have a bad\n> experience moving workloads around.\n> \n> With total interoperability, you may have less providers at start, but\n> at least they provide a great experience moving workloads around. And as\n> more join them, it only gets better. Total interoperability is basically\n> the only way to potentially reach one day the nirvana of \"lots of\n> providers + great end user experience\".\n> \n> The trick is to bootstrap it. If you have 0 or 1 \"true openstack\" cloud\n> available at first, it\'s hard to get any benefit from that hypothetical\n> federation. Total interop requires a bit of a leap of faith.\n\nRight, it\'s about bootstrapping - I\'m all for total interoperability,\nbut feel it will need to be \"looser than total\" in order to bootstrap\nit.\n\n> So yet another way to frame that discussion (at board level) is: are you\n> more interested in convergence and federation (and beating Amazon all\n> together), or are you more interested in competing (and be a set of\n> individual loosely-coupled small competitors to Amazon).\n\nI\'d hope there would be consensus around convergence and, if so, I\'d\nlike to see a discussion about bootstrapping tactics.\n\nMark.\n\n\n\n','<52F228C2.5030302@openstack.org>',NULL),('<1391609474.5141.8.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 09:11:14',-18000,'2014-02-05 14:11:14',NULL,'[openstack-dev] [savanna] Specific job type for streaming\n mapreduce? (and someday pipes)','Okay,\n\n  Thanks. I\'ll make a draft CR that sets up Savanna for dotted names,\nand one that uses dotted names with streaming.\n\nBest,\n\nTrevor\n\nOn Wed, 2014-02-05 at 15:58 +0400, Sergey Lukjanov wrote:\n> I like the dot-separated name. There are several reasons for it:\n> \n> \n> * it\'ll not require changes in all Savanna subprojects;\n> * eventually we\'d like to use not only Oozie for EDP (for example, if\n> we\'ll support Twitter Storm) and this new tools could require\n> additional \'subtypes\'.\n> \n> \n> Thanks for catching this.\n> \n> \n> On Tue, Feb 4, 2014 at 10:47 PM, Trevor McKay <tmckay at redhat.com>\n> wrote:\n>         Thanks Andrew.\n>         \n>         My author thought, which is in between, is to allow dotted\n>         types.\n>         \"MapReduce.streaming\" for example.\n>         \n>         This gives you the subtype flavor but keeps all the APIs the\n>         same.\n>         We just need a wrapper function to separate them when we\n>         compare types.\n>         \n>         Best,\n>         \n>         Trevor\n>         \n>         On Mon, 2014-02-03 at 14:57 -0800, Andrew Lazarev wrote:\n>         > I see two points:\n>         > * having Savanna types mapped to Oozie action types is\n>         intuitive for\n>         > hadoop users and this is something we would like to keep\n>         > * it is hard to distinguish different kinds of one job type\n>         >\n>         >\n>         > Adding \'subtype\' field will solve both problems. Having it\n>         optional\n>         > will not break backward compatibility. Adding database\n>         migration\n>         > script is also pretty straightforward.\n>         >\n>         >\n>         > Summarizing, my vote is on \"subtype\" field.\n>         >\n>         >\n>         > Thanks,\n>         > Andrew.\n>         >\n>         >\n>         > On Mon, Feb 3, 2014 at 2:10 PM, Trevor McKay\n>         <tmckay at redhat.com>\n>         > wrote:\n>         >\n>         >         I was trying my best to avoid adding extra job types\n>         to\n>         >         support\n>         >         mapreduce variants like streaming or mapreduce with\n>         pipes, but\n>         >         it seems\n>         >         that adding the types is the simplest solution.\n>         >\n>         >         On the API side, Savanna can live without a specific\n>         job type\n>         >         by\n>         >         examining the data in the job record.\n>          Presence/absence of\n>         >         certain\n>         >         things, or null values, etc, can provide adequate\n>         indicators\n>         >         to what\n>         >         kind of mapreduce it is.  Maybe a little bit subtle.\n>         >\n>         >         But for the UI, it seems that explicit knowledge of\n>         what the\n>         >         job is\n>         >         makes things easier and better for the user.  When a\n>         user\n>         >         creates a\n>         >         streaming mapreduce job and the UI is aware of the\n>         type later\n>         >         on at job\n>         >         launch, the user can be prompted to provide the\n>         right configs\n>         >         (i.e., the\n>         >         streaming mapper and reducer values).\n>         >\n>         >         The explicit job type also supports validation\n>         without having\n>         >         to add\n>         >         extra flags (which impacts the savanna client, and\n>         the JSON,\n>         >         etc). For\n>         >         example, a streaming mapreduce job does not require\n>         any\n>         >         specified\n>         >         libraries so the fact that it is meant to be a\n>         streaming job\n>         >         needs to be\n>         >         known at job creation time.\n>         >\n>         >         So, to that end, I propose that we add a\n>         MapReduceStreaming\n>         >         job type,\n>         >         and probably at some point we will have\n>         MapReducePiped too.\n>         >         It\'s\n>         >         possible that we might have other job types in the\n>         future too\n>         >         as the\n>         >         feature set grows.\n>         >\n>         >         There was an effort to make Savanna job types\n>         parallel Oozie\n>         >         action\n>         >         types, but in this case that\'s just not possible\n>         without\n>         >         introducing a\n>         >         \"subtype\" field in the job record, which leads to a\n>         database\n>         >         migration\n>         >         script and savanna client changes.\n>         >\n>         >         What do you think?\n>         >\n>         >         Best,\n>         >\n>         >         Trevor\n>         >\n>         >\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Sincerely yours,\n> Sergey Lukjanov\n> Savanna Technical Lead\n> Mirantis Inc.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CA+GZd796p69omYkSzUvDugz8MFxnu=yR5mS_Rt-1TcE5P3NqqQ@mail.gmail.com>',NULL),('<1391617104-sup-9926@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 08:39:53',-28800,'2014-02-05 16:39:53',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates spec\n	re-written. RFC','Excerpts from Zane Bitter\'s message of 2014-02-04 16:14:09 -0800:\n> On 03/02/14 17:09, Clint Byrum wrote:\n> > Excerpts from Thomas Herve\'s message of 2014-02-03 12:46:05 -0800:\n> >>> So, I wrote the original rolling updates spec about a year ago, and the\n> >>> time has come to get serious about implementation. I went through it and\n> >>> basically rewrote the entire thing to reflect the knowledge I have\n> >>> gained from a year of working with Heat.\n> >>>\n> >>> Any and all comments are welcome. I intend to start implementation very\n> >>> soon, as this is an important component of the HA story for TripleO:\n> >>>\n> >>> https://wiki.openstack.org/wiki/Heat/Blueprints/RollingUpdates\n> >>\n> >> Hi Clint, thanks for pushing this.\n> >>\n> >> First, I don\'t think RollingUpdatePattern and CanaryUpdatePattern should be 2 different entities. The second just looks like a parametrization of the first (growth_factor=1?).\n> >\n> > Perhaps they can just be one. Until I find parameters which would need\n> > to mean something different, I\'ll just use UpdatePattern.\n> >\n> >>\n> >> I then feel that using (abusing?) depends_on for update pattern is a bit weird. Maybe I\'m influenced by the CFN design, but the separate UpdatePolicy attribute feels better (although I would probably use a property). I guess my main question is around the meaning of using the update pattern on a server instance. I think I see what you want to do for the group, where child_updating would return a number, but I have no idea what it means for a single resource. Could you detail the operation a bit more in the document?\n> >>\n> >\n> > I would be o-k with adding another keyword. The idea in abusing depends_on\n> > is that it changes the core language less. Properties is definitely out\n> > for the reasons Christopher brought up, properties is really meant to\n> > be for the resource\'s end target only.\n> \n> Agree, -1 for properties - those belong to the resource, and this data \n> belongs to Heat.\n> \n> > UpdatePolicy in cfn is a single string, and causes very generic rolling\n> \n> Huh?\n> \n> http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html\n> \n> Not only is it not just a single string (in fact, it looks a lot like \n> the properties you have defined), it\'s even got another layer of \n> indirection so you can define different types of update policy (rolling \n> vs. canary, anybody?). It\'s an extremely flexible syntax.\n> \n\nOops, I relied a little too much on my memory and not enough on docs for\nthat one. O-k, I will re-evaluate given actual knowledge of how it\nactually works. :-P\n\n> BTW, given that we already implemented this in autoscaling, it might be \n> helpful to talk more specifically about what we need to do in addition \n> in order to support the use cases you have in mind.\n> \n\nAs Robert mentioned in his mail, autoscaling groups won\'t allow us to\ninject individual credentials. With the ResourceGroup, we can make a\nnested stack with a random string generator so that is solved. Now the\nother piece we need is to be able to directly choose machines to take\nout of commission, which I think we may have a simple solution to but I\ndon\'t want to derail on that.\n\nThe one used in AutoScalingGroups is also limited to just one group,\nthus it can be done all inside the resource.\n\n> > update behavior. I want this resource to be able to control multiple\n> > groups as if they are one in some cases (Such as a case where a user\n> > has migrated part of an app to a new type of server, but not all.. so\n> > they will want to treat the entire aggregate as one rolling update).\n> >\n> > I\'m o-k with overloading it to allow resource references, but I\'d like\n> > to hear more people take issue with depends_on before I select that\n> > course.\n> \n> Resource references in general, and depends_on in particular, feel like \n> very much the wrong abstraction to me. This is a policy, not a resource.\n> \n> > To answer your question, using it with a server instance allows\n> > rolling updates across non-grouped resources. In the example the\n> > rolling_update_dbs does this.\n> \n> That\'s not a great example, because one DB server depends on the other, \n> forcing them into updating serially anyway.\n> \n\nYou\'re right, a better example is a set of (n) resource groups which\nserve the same service and thus we want to make sure we maintain the\nminimum service levels as a whole.\n\nIf it were an order of magnitude harder to do it this way, I\'d say\nsure let\'s just expand on the single-resource rolling update. But\nI think it won\'t be that much harder to achieve this and then the use\ncase is solved.\n\n> I have to say that even in general, this whole idea about applying \n> update policies to non-grouped resources doesn\'t make a whole lot of \n> sense to me. For non-grouped resources you control the resource \n> definitions individually - if you don\'t want them to update at a \n> particular time, you have the option of just not updating them.\n> \n\nIf I have to calculate all the deltas and feed Heat 10 templates, each\nwith one small delta, I\'m writing the same code as I\'m proposing for\nthis rolling update feature, but I\'m writing it outside of Heat. That\nseems counter-productive for all of the other Heat users who would find\nthis useful.\n\n> Where you _do_ need it is for scaling groups where every server is based \n> on the same launch config, so you need a way to control the members \n> individually - by batching up operations (done), adding delays (done) \n> or, even better, notifications and callbacks.\n> \n> So it seems like doing \'rolling\' updates for any random subset of \n> resources is effectively turning Heat into something of a poor-man\'s \n> workflow service, and IMHO that is probably a mistake.\n> \n> What we do need for all resources (not just scaling groups) is a way for \n> the user to say \"for this particular resource, notify me when it has \n> updated (but, if possible, before we have taken any destructive actions \n> on it), give me a chance to test it and accept or reject the update\". \n> For example, when you resize a server, give the user a chance to confirm \n> or reject the change at the VERIFY_RESIZE step (Trove requires this). Or \n> when you replace a server during an update, give the user a chance to \n> test the new server and either keep it (continue on and delete the old \n> one) or not (roll back). Or when you replace a server in a scaling \n> group, notify the load balancer _or some other thing_ (e.g. OpenShift \n> broker node) that a replacement has been created and wait for it to \n> switch over to the new one before deleting the old one. Or, of course, \n> when you update a server to some new config, give the user a chance to \n> test it out and make sure it works before continuing with the stack \n> update. All of these use cases can, I think, be solved with a single \n> feature.\n> \n\nYes, this is another thing that we will need for TripleO, as we\'ll want\nto be able to notify a compute node that it will be rebooted soon, and\nthen have it evacuate or live migrate everything off of itself, and then\ncall back to Heat \"ok reboot me\".\n\n> The open questions for me are:\n> 1) How do we notify the user that it\'s time to check on a resource? \n> (Marconi?)\n\nThat would be good, and I believe Dmitry from Savanna was looking at\nadding AMQP or Marconi to os-collect-config. We don\'t have to wait for\nthat though, for a first run we can just update the resource\'s metadata\nto drop a wait condition handle in a pre-selected key. Success would be\n\"go ahead and reboot me\", failure would be \"I am in an inconsistent state,\ndon\'t touch me.\"\n\n> 2) How does the user ack/nack? (You\'re suggesting reusing WaitCondition, \n> and that makes sense to me.)\n> 3) How do we break up the operations so the notification occurs at the \n> right time? (With difficulty, but it should be do-able.)\n> 4) How does the user indicate for which resources they want to be \n> notified? (Inside an update_policy? Another new directive at the \n> type/properties/depends_on/update_policy level?)\n\nI don\'t have a good answer for 3 and 4, but I feel like your ()\'s are\nsimilar to what I\'m thinking too.\n\n\n','<52F18251.2010903@redhat.com>',NULL),('<1391618372.6903.38.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:39:32',-18000,'2014-02-05 16:39:32',NULL,'[openstack-dev] [OpenStack-Infra] [cinder][neutron][nova][3rd\n party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd\n party testing','On Wed, 2014-02-05 at 15:50 +0400, Sergey Lukjanov wrote:\n> Hi Jay,\n> \n> it\'s really very easy to setup Zuul for it (we\'re using one for\n> Savanna CI).\n\nYes, I set up Zuul for AT&T\'s gate system, thx.\n\n> There are some useful links:\n> \n> * check pipeline as an example of zuul layout configuration\n> - https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L5\n> * zuul docs - http://ci.openstack.org/zuul/\n> * zuul config sample\n> - https://github.com/openstack-infra/zuul/blob/master/etc/zuul.conf-sample\n> \n> So, I think that it could be easy enough to setup Zuul for 3rd party\n> testing, but it\'ll be better to have some doc about it.\n\nYeah, I proposed in my email that I would do the documentation for using\nZuul as the trigger from Gerrit (see below). However, I didn\'t think I\'d\nget the docs done in a timely fashion and proposed relaxing the\nrequirement for \"recheck\" triggers until that documentation was complete\n(since most of the vendors I have spoken with have used the Jenkins\nGerrit plugin and not Zuul as their triggering agent)\n\nBest,\n-jay\n\n> \n> On Wed, Feb 5, 2014 at 3:55 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         Sorry for cross-posting to both mailing lists, but there\'s\n>         lots of folks\n>         working on setting up third-party testing platforms that are\n>         not members\n>         of the openstack-infra ML...\n>         \n>         tl;dr\n>         -----\n>         \n>         The third party testing documentation [1] has requirements [2]\n>         that\n>         include the ability to trigger a recheck based on a gerrit\n>         comment.\n>         \n>         Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not\n>         have the\n>         ability to trigger job runs based on a regex-filtered comment\n>         (only on\n>         the existence of any new comment to the code review).\n>         \n>         Therefore, we either should:\n>         \n>         a) Relax the requirement that the third party system trigger\n>         test\n>         re-runs when a comment including the word \"recheck\" appears in\n>         the\n>         Gerrit event stream\n>         \n>         b) Modify the Jenkins Gerrit plugin to support regex filtering\n>         on the\n>         comment text (in the same way that it currently supports regex\n>         filtering\n>         on the project name)\n>         \n>         or\n>         \n>         c) Add documentation to the third party testing pages that\n>         explains how\n>         to use Zuul as a replacement for the Jenkins Gerrit plugin.\n>         \n>         I propose we do a) for the short term, and I\'ll work on c)\n>         long term.\n>         However, I\'m throwing this out there just in case there are\n>         some Java\n>         and Jenkins whizzes out there that could get b) done in a\n>         jiffy.\n>         \n>         details\n>         -------\n>         \n>         OK, so I\'ve been putting together documentation on how to set\n>         up an\n>         external Jenkins platform that is \"linked\" [4] with the\n>         upstream\n>         OpenStack CI system.\n>         \n>         Recently, I wrote an article detailing how the upstream CI\n>         system\n>         worked, including a lot of the gory details from the\n>         openstack-infra/config project\'s files. [5]\n>         \n>         I\'ve been working on a follow-up article that goes through how\n>         to set up\n>         a Jenkins system, and in writing that article, I created a\n>         source\n>         repository [6] that contains scripts, instructions and Puppet\n>         modules\n>         that set up a Jenkins system, the Jenkins Job Builder tool,\n>         and\n>         installs/configures the Jenkins Gerrit plugin [7].\n>         \n>         I planned to use the Jenkins Gerrit plugin as the mechanism\n>         that\n>         triggers Jenkins jobs on the external system based on gerrit\n>         events\n>         published by the OpenStack review.openstack.org Gerrit\n>         service. In\n>         addition to being mentioned in the third party documentation,\n>         Jenkins\n>         Job Builder has the ability to construct Jenkins jobs that are\n>         triggered\n>         by the Jenkins Gerrit plugin [8].\n>         \n>         Unforunately, I\'ve run into a bit of a snag.\n>         \n>         The third party testing documentation has requirements that\n>         include the\n>         ability to trigger a recheck based on a gerrit comment:\n>         \n>         <quote>\n>         Support recheck to request re-running a test.\n>          * Support the following syntaxes recheck no bug and recheck\n>         bug ###.\n>          * Recheck means recheck everything. A single recheck comment\n>         should\n>         re-trigger all testing systems.\n>         </quote>\n>         \n>         The documentation has a section on using the Gerrit Jenkins\n>         Trigger\n>         plugin [3] to accept notifications from the upstream OpenStack\n>         Gerrit\n>         instance.\n>         \n>         But unfortunately, the Jenkins Gerrit plugin does not support\n>         the\n>         ability to trigger a re-run of a job given a regex match of\n>         the word\n>         \"recheck\". :(\n>         \n>         So, we either need to a) change the requirements of third\n>         party testers,\n>         b) enhance the Jenkins Gerrit plugin with the missing\n>         functionality, or\n>         c) add documentation on how to set up Zuul as the triggering\n>         system\n>         instead of the Jenkins Gerrit plugin.\n>         \n>         I\'m happy to work on c), but I think relaxing the restriction\n>         (a) is\n>         probably needed short-term.\n>         \n>         Best,\n>         -jay\n>         \n>         [1] http://ci.openstack.org/third_party.html\n>         [2] http://ci.openstack.org/third_party.html#requirements\n>         [3]\n>         http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way\n>         [4] By \"linked\" I mean it both reads from the OpenStack Gerrit\n>         system\n>         and writes (adds comments) to it\n>         [5]\n>         http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n>         [6] http://github.com/jaypipes/os-ext-testing\n>         [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger\n>         [8]\n>         https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-Infra mailing list\n>         OpenStack-Infra at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n> \n> \n> \n> -- \n> Sincerely yours,\n> Sergey Lukjanov\n> Savanna Technical Lead\n> Mirantis Inc.\n\n\n\n\n','<CA+GZd7_hb7iQtsxXR5DSoD0Aaa9jPfGmvyGmHgaaXzdjJYz_FQ@mail.gmail.com>',NULL),('<1391618372.6903.38.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-05 11:39:32',-18000,'2014-02-05 16:39:32',NULL,'[OpenStack-Infra] [cinder][neutron][nova][3rd party testing]\n Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing','On Wed, 2014-02-05 at 15:50 +0400, Sergey Lukjanov wrote:\n> Hi Jay,\n> \n> it\'s really very easy to setup Zuul for it (we\'re using one for\n> Savanna CI).\n\nYes, I set up Zuul for AT&T\'s gate system, thx.\n\n> There are some useful links:\n> \n> * check pipeline as an example of zuul layout configuration\n> - https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L5\n> * zuul docs - http://ci.openstack.org/zuul/\n> * zuul config sample\n> - https://github.com/openstack-infra/zuul/blob/master/etc/zuul.conf-sample\n> \n> So, I think that it could be easy enough to setup Zuul for 3rd party\n> testing, but it\'ll be better to have some doc about it.\n\nYeah, I proposed in my email that I would do the documentation for using\nZuul as the trigger from Gerrit (see below). However, I didn\'t think I\'d\nget the docs done in a timely fashion and proposed relaxing the\nrequirement for \"recheck\" triggers until that documentation was complete\n(since most of the vendors I have spoken with have used the Jenkins\nGerrit plugin and not Zuul as their triggering agent)\n\nBest,\n-jay\n\n> \n> On Wed, Feb 5, 2014 at 3:55 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         Sorry for cross-posting to both mailing lists, but there\'s\n>         lots of folks\n>         working on setting up third-party testing platforms that are\n>         not members\n>         of the openstack-infra ML...\n>         \n>         tl;dr\n>         -----\n>         \n>         The third party testing documentation [1] has requirements [2]\n>         that\n>         include the ability to trigger a recheck based on a gerrit\n>         comment.\n>         \n>         Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not\n>         have the\n>         ability to trigger job runs based on a regex-filtered comment\n>         (only on\n>         the existence of any new comment to the code review).\n>         \n>         Therefore, we either should:\n>         \n>         a) Relax the requirement that the third party system trigger\n>         test\n>         re-runs when a comment including the word \"recheck\" appears in\n>         the\n>         Gerrit event stream\n>         \n>         b) Modify the Jenkins Gerrit plugin to support regex filtering\n>         on the\n>         comment text (in the same way that it currently supports regex\n>         filtering\n>         on the project name)\n>         \n>         or\n>         \n>         c) Add documentation to the third party testing pages that\n>         explains how\n>         to use Zuul as a replacement for the Jenkins Gerrit plugin.\n>         \n>         I propose we do a) for the short term, and I\'ll work on c)\n>         long term.\n>         However, I\'m throwing this out there just in case there are\n>         some Java\n>         and Jenkins whizzes out there that could get b) done in a\n>         jiffy.\n>         \n>         details\n>         -------\n>         \n>         OK, so I\'ve been putting together documentation on how to set\n>         up an\n>         external Jenkins platform that is \"linked\" [4] with the\n>         upstream\n>         OpenStack CI system.\n>         \n>         Recently, I wrote an article detailing how the upstream CI\n>         system\n>         worked, including a lot of the gory details from the\n>         openstack-infra/config project\'s files. [5]\n>         \n>         I\'ve been working on a follow-up article that goes through how\n>         to set up\n>         a Jenkins system, and in writing that article, I created a\n>         source\n>         repository [6] that contains scripts, instructions and Puppet\n>         modules\n>         that set up a Jenkins system, the Jenkins Job Builder tool,\n>         and\n>         installs/configures the Jenkins Gerrit plugin [7].\n>         \n>         I planned to use the Jenkins Gerrit plugin as the mechanism\n>         that\n>         triggers Jenkins jobs on the external system based on gerrit\n>         events\n>         published by the OpenStack review.openstack.org Gerrit\n>         service. In\n>         addition to being mentioned in the third party documentation,\n>         Jenkins\n>         Job Builder has the ability to construct Jenkins jobs that are\n>         triggered\n>         by the Jenkins Gerrit plugin [8].\n>         \n>         Unforunately, I\'ve run into a bit of a snag.\n>         \n>         The third party testing documentation has requirements that\n>         include the\n>         ability to trigger a recheck based on a gerrit comment:\n>         \n>         <quote>\n>         Support recheck to request re-running a test.\n>          * Support the following syntaxes recheck no bug and recheck\n>         bug ###.\n>          * Recheck means recheck everything. A single recheck comment\n>         should\n>         re-trigger all testing systems.\n>         </quote>\n>         \n>         The documentation has a section on using the Gerrit Jenkins\n>         Trigger\n>         plugin [3] to accept notifications from the upstream OpenStack\n>         Gerrit\n>         instance.\n>         \n>         But unfortunately, the Jenkins Gerrit plugin does not support\n>         the\n>         ability to trigger a re-run of a job given a regex match of\n>         the word\n>         \"recheck\". :(\n>         \n>         So, we either need to a) change the requirements of third\n>         party testers,\n>         b) enhance the Jenkins Gerrit plugin with the missing\n>         functionality, or\n>         c) add documentation on how to set up Zuul as the triggering\n>         system\n>         instead of the Jenkins Gerrit plugin.\n>         \n>         I\'m happy to work on c), but I think relaxing the restriction\n>         (a) is\n>         probably needed short-term.\n>         \n>         Best,\n>         -jay\n>         \n>         [1] http://ci.openstack.org/third_party.html\n>         [2] http://ci.openstack.org/third_party.html#requirements\n>         [3]\n>         http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way\n>         [4] By \"linked\" I mean it both reads from the OpenStack Gerrit\n>         system\n>         and writes (adds comments) to it\n>         [5]\n>         http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n>         [6] http://github.com/jaypipes/os-ext-testing\n>         [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger\n>         [8]\n>         https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-Infra mailing list\n>         OpenStack-Infra at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n> \n> \n> \n> -- \n> Sincerely yours,\n> Sergey Lukjanov\n> Savanna Technical Lead\n> Mirantis Inc.\n\n\n\n\n','<CA+GZd7_hb7iQtsxXR5DSoD0Aaa9jPfGmvyGmHgaaXzdjJYz_FQ@mail.gmail.com>',NULL),('<1391618817.6903.40.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:46:57',-18000,'2014-02-05 16:46:57',NULL,'[openstack-dev] why do we put a license in every file?','On Wed, 2014-02-05 at 16:29 +0000, Greg Hill wrote:\n> I\'m new, so I\'m sure there\'s some history I\'m missing, but I find it bizarre that we have to put the same license into every single file of source code in our projects.\n\nMeh, probably just habit and copy/paste behavior.\n\n>   In my past experience, a single LICENSE file at the root-level of the project has been sufficient to declare the license chosen for a project.\n\nAgreed, and the git history is enough to figure out who worked on a\nparticular file. But, there\'s been many discussions about this topic\nover the years, and it\'s just not been a priority, frankly.\n\n> Github even has the capacity to choose a license and generate that file for you, it\'s neat.\n\nTrue, but we don\'t use GitHub :) We only only use it as a mirror for\nGerrit.\n\nBest,\n-jay\n\n\n\n','<823CB839-80F8-454E-834E-3C4F11FF0F5E@rackspace.com>',NULL),('<1391619362.2170.1.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:56:02',-18000,'2014-02-05 16:56:02',NULL,'[openstack-dev] savann-ci,\n Re: [savanna] Alembic migrations and absence of DROP column in\n sqlite','Hi Sergey,\n\n  Is there a bug or a blueprint for this?  I did a quick search but\ndidn\'t see one.\n\nThanks,\n\nTrevor\n\nOn Wed, 2014-02-05 at 16:06 +0400, Sergey Kolekonov wrote:\n> I\'m currently working on moving on the MySQL for savanna-ci\n> \n> \n> On Wed, Feb 5, 2014 at 3:53 PM, Sergey Lukjanov\n> <slukjanov at mirantis.com> wrote:\n>         Agreed, let\'s move on to the MySQL for savanna-ci to run\n>         integration tests against production-like DB.\n>         \n>         \n>         On Wed, Feb 5, 2014 at 1:54 AM, Andrew Lazarev\n>         <alazarev at mirantis.com> wrote:\n>                 Since sqlite is not in the list of \"databases that\n>                 would be used in production\", CI should use other DB\n>                 for testing.\n>                 \n>                 \n>                 Andrew.\n>                 \n>                 \n>                 On Tue, Feb 4, 2014 at 1:13 PM, Alexander Ignatov\n>                 <aignatov at mirantis.com> wrote:\n>                         Indeed. We should create a bug around that and\n>                         move our savanna-ci to mysql.\n>                         \n>                         Regards,\n>                         Alexander Ignatov\n>                         \n>                         \n>                         \n>                         On 05 Feb 2014, at 01:01, Trevor McKay\n>                         <tmckay at redhat.com> wrote:\n>                         \n>                         > This brings up an interesting problem:\n>                         >\n>                         > In https://review.openstack.org/#/c/70420/\n>                         I\'ve added a migration that\n>                         > uses a drop column for an upgrade.\n>                         >\n>                         > But savann-ci is apparently using a sqlite\n>                         database to run.  So it can\'t\n>                         > possibly pass.\n>                         >\n>                         > What do we do here?  Shift savanna-ci tests\n>                         to non sqlite?\n>                         >\n>                         > Trevor\n>                         >\n>                         > On Sat, 2014-02-01 at 18:17 +0200, Roman\n>                         Podoliaka wrote:\n>                         >> Hi all,\n>                         >>\n>                         >> My two cents.\n>                         >>\n>                         >>> 2) Extend alembic so that op.drop_column()\n>                         does the right thing\n>                         >> We could, but should we?\n>                         >>\n>                         >> The only reason alembic doesn\'t support\n>                         these operations for SQLite\n>                         >> yet is that SQLite lacks proper support of\n>                         ALTER statement. For\n>                         >> sqlalchemy-migrate we\'ve been providing a\n>                         work-around in the form of\n>                         >> recreating of a table and copying of all\n>                         existing rows (which is a\n>                         >> hack, really).\n>                         >>\n>                         >> But to be able to recreate a table, we\n>                         first must have its definition.\n>                         >> And we\'ve been relying on SQLAlchemy schema\n>                         reflection facilities for\n>                         >> that. Unfortunately, this approach has a\n>                         few drawbacks:\n>                         >>\n>                         >> 1) SQLAlchemy versions prior to 0.8.4 don\'t\n>                         support reflection of\n>                         >> unique constraints, which means the\n>                         recreated table won\'t have them;\n>                         >>\n>                         >> 2) special care must be taken in \'edge\'\n>                         cases (e.g. when you want to\n>                         >> drop a BOOLEAN column, you must also drop\n>                         the corresponding CHECK (col\n>                         >> in (0, 1)) constraint manually, or SQLite\n>                         will raise an error when the\n>                         >> table is recreated without the column being\n>                         dropped)\n>                         >>\n>                         >> 3) special care must be taken for \'custom\'\n>                         type columns (it\'s got\n>                         >> better with SQLAlchemy 0.8.x, but e.g. in\n>                         0.7.x we had to override\n>                         >> definitions of reflected BIGINT columns\n>                         manually for each\n>                         >> column.drop() call)\n>                         >>\n>                         >> 4) schema reflection can\'t be performed\n>                         when alembic migrations are\n>                         >> run in \'offline\' mode (without connecting\n>                         to a DB)\n>                         >> ...\n>                         >> (probably something else I\'ve forgotten)\n>                         >>\n>                         >> So it\'s totally doable, but, IMO, there is\n>                         no real benefit in\n>                         >> supporting running of schema migrations for\n>                         SQLite.\n>                         >>\n>                         >>> ...attempts to drop schema generation\n>                         based on models in favor of migrations\n>                         >>\n>                         >> As long as we have a test that checks that\n>                         the DB schema obtained by\n>                         >> running of migration scripts is equal to\n>                         the one obtained by calling\n>                         >> metadata.create_all(), it\'s perfectly OK to\n>                         use model definitions to\n>                         >> generate the initial DB schema for running\n>                         of unit-tests as well as\n>                         >> for new installations of OpenStack (and\n>                         this is actually faster than\n>                         >> running of migration scripts). ... and if\n>                         we have strong objections\n>                         >> against doing metadata.create_all(), we can\n>                         always use migration\n>                         >> scripts for both new installations and\n>                         upgrades for all DB backends,\n>                         >> except SQLite.\n>                         >>\n>                         >> Thanks,\n>                         >> Roman\n>                         >>\n>                         >> On Sat, Feb 1, 2014 at 12:09 PM, Eugene\n>                         Nikanorov\n>                         >> <enikanorov at mirantis.com> wrote:\n>                         >>> Boris,\n>                         >>>\n>                         >>> Sorry for the offtopic.\n>                         >>> Is switching to model-based schema\n>                         generation is something decided? I see\n>                         >>> the opposite: attempts to drop schema\n>                         generation based on models in favor of\n>                         >>> migrations.\n>                         >>> Can you point to some discussion threads?\n>                         >>>\n>                         >>> Thanks,\n>                         >>> Eugene.\n>                         >>>\n>                         >>>\n>                         >>>\n>                         >>> On Sat, Feb 1, 2014 at 2:19 AM, Boris\n>                         Pavlovic <bpavlovic at mirantis.com>\n>                         >>> wrote:\n>                         >>>>\n>                         >>>> Jay,\n>                         >>>>\n>                         >>>> Yep we shouldn\'t use migrations for\n>                         sqlite at all.\n>                         >>>>\n>                         >>>> The major issue that we have now is that\n>                         we are not able to ensure that DB\n>                         >>>> schema created by migration & models are\n>                         same (actually they are not same).\n>                         >>>>\n>                         >>>> So before dropping support of migrations\n>                         for sqlite & switching to model\n>                         >>>> based created schema we should add tests\n>                         that will check that model &\n>                         >>>> migrations are synced.\n>                         >>>> (we are working on this)\n>                         >>>>\n>                         >>>>\n>                         >>>>\n>                         >>>> Best regards,\n>                         >>>> Boris Pavlovic\n>                         >>>>\n>                         >>>>\n>                         >>>> On Fri, Jan 31, 2014 at 7:31 PM, Andrew\n>                         Lazarev <alazarev at mirantis.com>\n>                         >>>> wrote:\n>                         >>>>>\n>                         >>>>> Trevor,\n>                         >>>>>\n>                         >>>>> Such check could be useful on alembic\n>                         side too. Good opportunity for\n>                         >>>>> contribution.\n>                         >>>>>\n>                         >>>>> Andrew.\n>                         >>>>>\n>                         >>>>>\n>                         >>>>> On Fri, Jan 31, 2014 at 6:12 AM, Trevor\n>                         McKay <tmckay at redhat.com> wrote:\n>                         >>>>>>\n>                         >>>>>> Okay,  I can accept that migrations\n>                         shouldn\'t be supported on sqlite.\n>                         >>>>>>\n>                         >>>>>> However, if that\'s the case then we\n>                         need to fix up savanna-db-manage so\n>                         >>>>>> that it checks the db connection info\n>                         and throws a polite error to the\n>                         >>>>>> user for attempted migrations on\n>                         unsupported platforms. For example:\n>                         >>>>>>\n>                         >>>>>> \"Database migrations are not supported\n>                         for sqlite\"\n>                         >>>>>>\n>                         >>>>>> Because, as a developer, when I see a\n>                         sql error trace as the result of\n>                         >>>>>> an operation I assume it\'s broken :)\n>                         >>>>>>\n>                         >>>>>> Best,\n>                         >>>>>>\n>                         >>>>>> Trevor\n>                         >>>>>>\n>                         >>>>>> On Thu, 2014-01-30 at 15:04 -0500, Jay\n>                         Pipes wrote:\n>                         >>>>>>> On Thu, 2014-01-30 at 14:51 -0500,\n>                         Trevor McKay wrote:\n>                         >>>>>>>> I was playing with alembic migration\n>                         and discovered that\n>                         >>>>>>>> op.drop_column() doesn\'t work with\n>                         sqlite.  This is because sqlite\n>                         >>>>>>>> doesn\'t support dropping a column\n>                         (broken imho, but that\'s another\n>                         >>>>>>>> discussion).  Sqlite throws a syntax\n>                         error.\n>                         >>>>>>>>\n>                         >>>>>>>> To make this work with sqlite, you\n>                         have to copy the table to a\n>                         >>>>>>>> temporary\n>                         >>>>>>>> excluding the column(s) you don\'t\n>                         want and delete the old one,\n>                         >>>>>>>> followed\n>                         >>>>>>>> by a rename of the new table.\n>                         >>>>>>>>\n>                         >>>>>>>> The existing 002 migration uses\n>                         op.drop_column(), so I\'m assuming\n>                         >>>>>>>> it\'s\n>                         >>>>>>>> broken, too (I need to check what the\n>                         migration test is doing).  I\n>                         >>>>>>>> was\n>                         >>>>>>>> working on an 003.\n>                         >>>>>>>>\n>                         >>>>>>>> How do we want to handle this?  Three\n>                         good options I can think of:\n>                         >>>>>>>>\n>                         >>>>>>>> 1) don\'t support migrations for\n>                         sqlite (I think \"no\", but maybe)\n>                         >>>>>>>>\n>                         >>>>>>>> 2) Extend alembic so that\n>                         op.drop_column() does the right thing\n>                         >>>>>>>> (more\n>                         >>>>>>>> open-source contributions for us,\n>                         yay :) )\n>                         >>>>>>>>\n>                         >>>>>>>> 3) Add our own wrapper in savanna so\n>                         that we have a drop_column()\n>                         >>>>>>>> method\n>                         >>>>>>>> that wraps copy/rename.\n>                         >>>>>>>>\n>                         >>>>>>>> Ideas, comments?\n>                         >>>>>>>\n>                         >>>>>>> Migrations should really not be run\n>                         against SQLite at all -- only on\n>                         >>>>>>> the\n>                         >>>>>>> databases that would be used in\n>                         production. I believe the general\n>                         >>>>>>> direction of the contributor community\n>                         is to be consistent around\n>                         >>>>>>> testing of migrations and to not run\n>                         migrations at all in unit tests\n>                         >>>>>>> (which use SQLite).\n>                         >>>>>>>\n>                         >>>>>>> Boris (cc\'d) may have some more to say\n>                         on this topic.\n>                         >>>>>>>\n>                         >>>>>>> Best,\n>                         >>>>>>> -jay\n>                         >>>>>>>\n>                         >>>>>>>\n>                         >>>>>>>\n>                         _______________________________________________\n>                         >>>>>>> OpenStack-dev mailing list\n>                         >>>>>>> OpenStack-dev at lists.openstack.org\n>                         >>>>>>>\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >>>>>>\n>                         >>>>>>\n>                         >>>>>>\n>                         >>>>>>\n>                         _______________________________________________\n>                         >>>>>> OpenStack-dev mailing list\n>                         >>>>>> OpenStack-dev at lists.openstack.org\n>                         >>>>>>\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >>>>>\n>                         >>>>>\n>                         >>>>\n>                         >>>>\n>                         >>>>\n>                         _______________________________________________\n>                         >>>> OpenStack-dev mailing list\n>                         >>>> OpenStack-dev at lists.openstack.org\n>                         >>>>\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >>>>\n>                         >>>\n>                         >>>\n>                         >>>\n>                         _______________________________________________\n>                         >>> OpenStack-dev mailing list\n>                         >>> OpenStack-dev at lists.openstack.org\n>                         >>>\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >>>\n>                         >>\n>                         >>\n>                         _______________________________________________\n>                         >> OpenStack-dev mailing list\n>                         >> OpenStack-dev at lists.openstack.org\n>                         >>\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >\n>                         >\n>                         >\n>                         >\n>                         _______________________________________________\n>                         > OpenStack-dev mailing list\n>                         > OpenStack-dev at lists.openstack.org\n>                         >\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         \n>         -- \n>         Sincerely yours,\n>         Sergey Lukjanov\n>         Savanna Technical Lead\n>         Mirantis Inc.\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAMxWcsv+X02irdPtKYpWK+0K5cTZ5tpc5R_xZy3dsX3NqPW-eQ@mail.gmail.com>',NULL),('<1391619474-sup-2248@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 09:02:18',-28800,'2014-02-05 17:02:18',NULL,'[openstack-dev] [Heat] [TripleO] Rolling updates spec\n	re-written. RFC','Excerpts from Steven Dake\'s message of 2014-02-05 07:35:37 -0800:\n> On 02/04/2014 06:34 PM, Robert Collins wrote:\n> > On 5 February 2014 13:14, Zane Bitter <zbitter at redhat.com> wrote:\n> >\n> >\n> >> That\'s not a great example, because one DB server depends on the other,\n> >> forcing them into updating serially anyway.\n> >>\n> >> I have to say that even in general, this whole idea about applying update\n> >> policies to non-grouped resources doesn\'t make a whole lot of sense to me.\n> >> For non-grouped resources you control the resource definitions individually\n> >> - if you don\'t want them to update at a particular time, you have the option\n> >> of just not updating them.\n> > Well, I don\'t particularly like the idea of doing thousands of\n> > discrete heat stack-update calls, which would seem to be what you\'re\n> > proposing.\n> >\n> > On groups: autoscale groups are a problem for secure minded\n> > deployments because every server has identical resources (today) and\n> > we very much want discrete credentials per server - at least this is\n> > my understanding of the reason we\'re not using scaling groups in\n> > TripleO.\n> >\n> >> Where you _do_ need it is for scaling groups where every server is based on\n> >> the same launch config, so you need a way to control the members\n> >> individually - by batching up operations (done), adding delays (done) or,\n> >> even better, notifications and callbacks.\n> >>\n> >> So it seems like doing \'rolling\' updates for any random subset of resources\n> >> is effectively turning Heat into something of a poor-man\'s workflow service,\n> >> and IMHO that is probably a mistake.\n> > I mean to reply to the other thread, but here is just as good :) -\n> > heat as a way to describe the intended state, and heat takes care of\n> > transitions, is a brilliant model. It absolutely implies a bunch of\n> > workflows - the AWS update policy is probably the key example.\n> >\n> > Being able to gracefully, *automatically* work through a transition\n> > between two defined states, allowing the nodes in question to take\n> > care of their own needs along the way seems like a pretty core\n> > function to fit inside Heat itself. Its not at all the same as \'allow\n> > users to define abitrary workflows\'.\n> >\n> > -Rob\n> Rob,\n> \n> I\'m not precisely certain what your proposing, but I think we need to \n> take care not to turn the Heat DSL into a full-fledged programming \n> language.  IMO thousands of updates done through heat is a perfect way \n> for a third party service to do such things - eg control workflow.  \n> Clearly there is a workflow gap in OpenStack, and possibly that thing \n> doing the thousands of updates should be a workflow service, rather then \n> TripleO, but workflow is out of scope for Heat proper.  Such a workflow \n> service could potentially fit in the Orchestration program alongside \n> Heat and Autoscaling.  It is too bad there isn\'t a workflow service \n> already because we are getting alot of pressure to make Heat fill this \n> gap.  I personally believe filling this gap with heat would be a mistake \n> and the correct course of action would be for a workflow service to \n> emerge to fill this need (and depend on Heat for orchestration).\n> \n\nI don\'t think we want to make it more programmable. I think the opposite,\nwe want to relieve the template author of workflow by hiding the common\ncase work-flows behind an update pattern.\n\nTo provide some substance to that, if we were to make a workflow service\nthat does this, it would have to understand templating, and it would\nhave to understand heat\'s API. By the time we get done implementing\nthat, it would look a lot like the resource I\'ve suggested, surrounded\nby calls to heatclient and a heat template library.\n\n> I believe this may be what Zane is reacting to; I believe the Heat \n> community would like to avoid making the DSL more programmable because \n> then it is harder to use and support.  The parameters,resources,outputs \n> DSL objects are difficult enough for new folks to pick up and its only 3 \n> things to understand...\n\nI do agree that keeping this simple to understand from a template author\nperspective is extremely important.\n\n\n','<52F25A49.40204@redhat.com>',NULL),('<1391619950-sup-9247@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 09:09:36',-28800,'2014-02-05 17:09:36',NULL,'[openstack-dev] why do we put a license in every file?','Excerpts from Greg Hill\'s message of 2014-02-05 08:29:20 -0800:\n> I\'m new, so I\'m sure there\'s some history I\'m missing, but I find it bizarre that we have to put the same license into every single file of source code in our projects.  In my past experience, a single LICENSE file at the root-level of the project has been sufficient to declare the license chosen for a project.  Github even has the capacity to choose a license and generate that file for you, it\'s neat. \n> \n\nI am definitely not a lawyer, but this is what my reading has shown.\n\nIn legal terms, explicit trumps implicit. So being explicit about\nour license in each copyrightable file is a hedge against somebody\nforklifting the code into their own code base in a proprietary product\nand just removing the license. If the header were not there, they might\nhave a mitigating argument that they were not aware of the license. But\nby removing it, they\'ve actively subverted the license.\n\nIn reality, I think it is because Debian Developers like me whine when\nour program \'licensecheck\' says \"UNKNOWN\" for any files. ;)\n\n\n','<823CB839-80F8-454E-834E-3C4F11FF0F5E@rackspace.com>',NULL),('<1391620320.2357.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 17:12:00',0,'2014-02-05 17:12:00',NULL,'[openstack-dev] [PTL] Designating \"required use\" upstream code','On Wed, 2014-02-05 at 17:22 +0100, Thierry Carrez wrote:\n> (This email is mostly directed to PTLs for programs that include one\n> integrated project)\n> \n> The DefCore subcommittee from the OpenStack board of directors asked the\n> Technical Committee yesterday about which code sections in each\n> integrated project should be \"designated sections\" in the sense of [1]\n> (code you\'re actually needed to run or include to be allowed to use the\n> trademark). That determines where you can run alternate code (think:\n> substitute your own private hypervisor driver) and still be able to call\n> the result openstack.\n> \n> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition\n> \n> PTLs and their teams are obviously the best placed to define this, so it\n> seems like the process should be: PTLs propose designated sections to\n> the TC, which blesses them, combines them and forwards the result to the\n> DefCore committee. We could certainly leverage part of the governance\n> repo to make sure the lists are kept up to date.\n> \n> Comments, thoughts ?\n\nI think what would be useful to the board is if we could describe at a\nhigh level which parts of each project have a pluggable interface and\nwhether we encourage out-of-tree implementations of those pluggable\ninterfaces.\n\nThat\'s actually a pretty tedious thing to document properly - think\nabout e.g. whether we encourage out-of-tree WSGI middlewares.\n\nThere\'s a flip-side to this \"designated sections\" thing that bothers me\nafter talking it through with Michael Still - I think it\'s perfectly\nreasonable for vendors to e.g. backport fixes to their products without\nthat backport ever seeing the light of day upstream (say it was too\ninvasive for the stable branch).\n\nThis can\'t be a case of e.g. enforcing the sha1 sums of files. If we\nwant to go that route, let\'s just use the AGPL :)\n\nI don\'t have a big issue with the way the Foundation currently enforces\n\"you must use the code\" - anyone who signs a trademark agreement with\nthe Foundation agrees to \"include the entirety of\" Nova\'s code. That\'s\nvery vague, but I assume the Foundation can terminate the agreement if\nit thinks the other party is acting in bad faith.\n\nBasically, I\'m concerned about us swinging from a rather lax \"you must\ninclude our code\" rule to an overly strict \"you must make no downstream\nmodifications to our code\".\n\nMark.\n\n\n\n','<52F26550.2010101@openstack.org>',NULL),('<1391620429.2357.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 17:13:49',0,'2014-02-05 17:13:49',NULL,'[openstack-dev] why do we put a license in every file?','On Wed, 2014-02-05 at 16:29 +0000, Greg Hill wrote:\n> I\'m new, so I\'m sure there\'s some history I\'m missing, but I find it\n> bizarre that we have to put the same license into every single file of\n> source code in our projects.  In my past experience, a single LICENSE\n> file at the root-level of the project has been sufficient to declare\n> the license chosen for a project.  Github even has the capacity to\n> choose a license and generate that file for you, it\'s neat. \n\nTake a look at this thread on legal-discuss last month:\n\n  http://lists.openstack.org/pipermail/legal-discuss/2014-January/thread.html\n\nBut yeah, as others say - per-file license headers help make the license\nexplicit when it is copied to other projects.\n\nMark.\n\n\n\n','<823CB839-80F8-454E-834E-3C4F11FF0F5E@rackspace.com>',NULL),('<1391620955.02543545@emailsrvr.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-05 11:22:35',-21600,'2014-02-05 17:22:35',NULL,'[OpenStack Foundation] The two types of interoperability','\nI think \"the branding issue\" is inseparable from interop (unless I misunderstand what you mean by that).\n \nI think the initial phases of defcore make sense, in so much as the focus is on defining what is expected to be in commercial products and services to be called \"openstack\", and in starting with a modest definition and a reasonable set of tests (largely based on what already exists) so that progress can be made quickly.  To me these things are the critical next steps on the road to interop.\n \nAt the moment, there are zero tests being used as a gate for the use of the mark commercially*, so as long as X is >0 it\'s an infinite improvement IMHO, and one that can\'t come soon enough. Note that the tests are not the sum total of the requirements today for the commercial use of the mark, nor should they be in the future, but as an additive step they are most welcome and helpful.\n \nMark\n \n*To be clear, the use of the mark DOES currently require, contractually, that products/services pass tests... the tests just need to exist.  This is why I will throw a party when we can implement the first tests, however modest\n \n \n \n \nOn Wednesday, February 5, 2014 10:44am, \"Troy Toman\" <troy.toman at rackspace.com> said:\n\n\n\n> \n> \n> > On Feb 5, 2014, at 6:05 AM, \"Thierry Carrez\" <thierry at openstack.org>\n> wrote:\n> >\n> > Mark McLoughlin wrote:\n> >> To put the question another way - which helps users more? The ability to\n> >> write interoperable code which uses a large number of OpenStack APIs,\n> >> but which is only actually interoperable between a small number of\n> >> OpenStack clouds? Or interoperability whereby you have a smaller set of\n> >> interoperable APIs, but code that uses only those APIs would be\n> >> interoperable with a much larger number of OpenStack clouds?\n> >\n> > I like your way of framing the question.\n> >\n> > Personally I think going for loose interoperability is short-sighted.\n> > Yes you\'ll have a lot of providers but you\'ll forever have a bad\n> > experience moving workloads around.\n> \n> +1\n> \n> >\n> > With total interoperability, you may have less providers at start, but\n> > at least they provide a great experience moving workloads around. And as\n> > more join them, it only gets better. Total interoperability is basically\n> > the only way to potentially reach one day the nirvana of \"lots of\n> > providers + great end user experience\".\n> >\n> > The trick is to bootstrap it. If you have 0 or 1 \"true openstack\" cloud\n> > available at first, it\'s hard to get any benefit from that hypothetical\n> > federation. Total interop requires a bit of a leap of faith.\n> >\n> > So yet another way to frame that discussion (at board level) is: are you\n> > more interested in convergence and federation (and beating Amazon all\n> > together), or are you more interested in competing (and be a set of\n> > individual loosely-coupled small competitors to Amazon).\n> \n> I think this is the right conversation to have around the goal of\n> interoperability. I think it is important to note that it was decided to NOT focus\n> on interoperability in the initial phases of DefCore but to just try and solve the\n> branding issue. Based on the feedback, it feels like the most pressing issue\n> really is around interop and we should wade into that sooner rather than later\n> even if it is (or maybe because it is) messy.  As I said earlier, I also don\'t\n> think it is helpful to try and solve both with one label or brand.\n> \n> Given all that, I am very supportive of taking simpler first steps and \"learning\"\n> our way into this. I think it is more likely to not only yield progress sooner but\n> get us to the proper endpoint faster too. Making tangible progress on making\n> federation/convergence is critical for OpenStack in 2014 IMHO. Or, if we can\'t\n> line up on that goal, then let\'s be explicit and stop setting that expectation. I\n> really hope we can do the former. I\'m not sure what a loosely-coupled set of\n> clouds does to change the landscape.\n> >\n> > --\n> > Thierry Carrez (ttx)\n> >\n> > _______________________________________________\n> > Foundation mailing list\n> > Foundation at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140205/30d55932/attachment.html>\n\n','<7542D366-1F16-4A7F-8637-E7DAF97E868D@rackspace.com>',NULL),('<1391666382-sup-496@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 22:10:05',-28800,'2014-02-06 06:10:05',NULL,'[openstack-dev] [Nova] bp proposal: discovery of peer instances\n	through metadata service','Excerpts from Monty Taylor\'s message of 2014-02-05 14:57:33 -0800:\n> On 01/27/2014 11:02 AM, Day, Phil wrote:\n> >> -----Original Message-----\n> >> From: Clint Byrum [mailto:clint at fewbar.com]\n> >> Sent: 24 January 2014 21:09\n> >> To: openstack-dev\n> >> Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances\n> >> through metadata service\n> >>\n> >> Excerpts from Justin Santa Barbara\'s message of 2014-01-24 12:29:49 -0800:\n> >>> Clint Byrum <clint at fewbar.com> wrote:\n> >>>\n> >>>>\n> >>>> Heat has been working hard to be able to do per-instance limited\n> >>>> access in Keystone for a while. A trust might work just fine for what you\n> >> want.\n> >>>>\n> >>>\n> >>> I wasn\'t actually aware of the progress on trusts.  It would be\n> >>> helpful except (1) it is more work to have to create a separate trust\n> >>> (it is even more painful to do so with IAM) and (2) it doesn\'t look\n> >>> like we can yet lock-down these delegations as much as people would\n> >>> probably want.  I think IAM is the end-game in terms of the model that\n> >>> people actually want, and it ends up being incredibly complex.\n> >>> Delegation is very useful (particularly because clusters could\n> >>> auto-scale themselves), but I\'d love to get an easier solution for the\n> >>> peer discovery problem than where delegation ends up.\n> >>>\n> >>> Are you hesitant to just use Heat? This is exactly what it is supposed\n> >>>> to do.. make a bunch of API calls and expose the results to\n> >>>> instances for use in configuration.\n> >>>\n> >>>> If you\'re just hesitant to use a declarative templating language, I\n> >>>> totally understand. The auto-scaling minded people are also feeling\n> >>>> this way. You could join them in the quest to create an imperative\n> >>>> cluster-making API for Heat.\n> >>>>\n> >>>\n> >>> I don\'t want to _depend_ on Heat.  My hope is that we can just launch\n> >>> 3 instances with the Cassandra image, and get a Cassandra cluster.  It\n> >>> might be that we want Heat to auto-scale that cluster, Ceilometer to\n> >>> figure out when to scale it, Neutron to isolate it, etc but I think we\n> >>> can solve the basic discovery problem cleanly without tying in all the other\n> >> services.\n> >>>   Heat\'s value-add doesn\'t come from solving this problem!\n> >>>\n> >>\n> >> I suppose we disagree on this fundamental point then.\n> >>\n> >> Heat\'s value-add really does come from solving this exact problem. It\n> >> provides a layer above all of the other services to facilitate expression of\n> >> higher level concepts. Nova exposes a primitive API, where as Heat is meant\n> >> to have a more logical expression of the user\'s intentions. That includes\n> >> exposure of details of one resource to another (not just compute, swift\n> >> containers, load balancers, volumes, images, etc).\n> >>\n> >\n> > The main problem I see with using heat is that seems to depend on all instances having network access to the heat server, and I\'m not sure how that would work for Neutron VPN network.     This is already solved for the Metadata server because the Neturon proxy already provides secure access.\n> \n> That sounds like an integration issue we should fix. (regardless of \n> whether it makes Justin\'s life any better) If we can\'t use heat in some \n> situations because neutron doesn\'t know how to securely proxy to its \n> metadata service ... that\'s kinda yuck.\n> \n\nIndeed that is a known problem with Heat and one that has several\nsolutions. One simple solution is for Heat to simply update the nova\nuserdata, and for in-instance tools to just query ec2 metadata. The only\nobstacle to that is that ec2 metadata is visible to non-privileged users\non the box without extra restrictions being applied.\n\n\n','<52F2C1DD.4080203@inaugust.com>',NULL),('<1391667008-sup-6006@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 22:13:56',-28800,'2014-02-06 06:13:56',NULL,'[openstack-dev] [Nova] bp proposal: discovery of peer instances\n	through metadata service','Excerpts from Day, Phil\'s message of 2014-01-27 03:02:17 -0800:\n> > -----Original Message-----\n> > From: Clint Byrum [mailto:clint at fewbar.com]\n> > Sent: 24 January 2014 21:09\n> > To: openstack-dev\n> > Subject: Re: [openstack-dev] [Nova] bp proposal: discovery of peer instances\n> > through metadata service\n> > \n> > Excerpts from Justin Santa Barbara\'s message of 2014-01-24 12:29:49 -0800:\n> > > Clint Byrum <clint at fewbar.com> wrote:\n> > >\n> > > >\n> > > > Heat has been working hard to be able to do per-instance limited\n> > > > access in Keystone for a while. A trust might work just fine for what you\n> > want.\n> > > >\n> > >\n> > > I wasn\'t actually aware of the progress on trusts.  It would be\n> > > helpful except (1) it is more work to have to create a separate trust\n> > > (it is even more painful to do so with IAM) and (2) it doesn\'t look\n> > > like we can yet lock-down these delegations as much as people would\n> > > probably want.  I think IAM is the end-game in terms of the model that\n> > > people actually want, and it ends up being incredibly complex.\n> > > Delegation is very useful (particularly because clusters could\n> > > auto-scale themselves), but I\'d love to get an easier solution for the\n> > > peer discovery problem than where delegation ends up.\n> > >\n> > > Are you hesitant to just use Heat? This is exactly what it is supposed\n> > > > to do.. make a bunch of API calls and expose the results to\n> > > > instances for use in configuration.\n> > >\n> > > > If you\'re just hesitant to use a declarative templating language, I\n> > > > totally understand. The auto-scaling minded people are also feeling\n> > > > this way. You could join them in the quest to create an imperative\n> > > > cluster-making API for Heat.\n> > > >\n> > >\n> > > I don\'t want to _depend_ on Heat.  My hope is that we can just launch\n> > > 3 instances with the Cassandra image, and get a Cassandra cluster.  It\n> > > might be that we want Heat to auto-scale that cluster, Ceilometer to\n> > > figure out when to scale it, Neutron to isolate it, etc but I think we\n> > > can solve the basic discovery problem cleanly without tying in all the other\n> > services.\n> > >  Heat\'s value-add doesn\'t come from solving this problem!\n> > >\n> > \n> > I suppose we disagree on this fundamental point then.\n> > \n> > Heat\'s value-add really does come from solving this exact problem. It\n> > provides a layer above all of the other services to facilitate expression of\n> > higher level concepts. Nova exposes a primitive API, where as Heat is meant\n> > to have a more logical expression of the user\'s intentions. That includes\n> > exposure of details of one resource to another (not just compute, swift\n> > containers, load balancers, volumes, images, etc).\n> > \n> \n> The main problem I see with using heat is that seems to depend on all instances having network access to the heat server, and I\'m not sure how that would work for Neutron VPN network.     This is already solved for the Metadata server because the Neturon proxy already provides secure access.\n> \n\nThis is not actually true. For Justin\'s use case, only access to the\nec2 metadata is needed. When using Heat one can set the Userdata to\nwhatever one already has discovered before booting the server at boot\ntime. Heat uses its own Metadata server for ongoing updates, but in\nJustin\'s prescribed scenario, the machines discover each-other at boot-up\nonly anyway. So machine 0 sees no other machines. Machine 1 sees machine\n0. Machine 2 sees 0 and 1... etc.\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006F92EB2@G6W2490.americas.hpqcorp.net>',NULL),('<1391667314-sup-5818@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 22:16:51',-28800,'2014-02-06 06:16:51',NULL,'[openstack-dev] [Nova] bp proposal: discovery of peer instances\n	through metadata service','Excerpts from Murray, Paul (HP Cloud Services)\'s message of 2014-01-27 04:14:44 -0800:\n> Hi Justin,\n> \n> My though process is to go back to basics. To perform discovery there is no getting away from the fact that you have to start with a well-known address that your peers can access on the network. The second part is a service/protocol accessible at that address that can perform the discovery. So the questions are: what well-known addresses can I reach? And is that a suitable place to implement the service/protocol.\n> \n> The metadata service is different to the others in that it can be accessed without credentials (correct me if I\'m wrong), so it is the only possibility out of the openstack services if you do not want to have credentials on the peer instances. If that is not the case then the other services are options. All services require security groups and/or networks to be configured appropriately to access them.\n> \n> (Yes, the question \"can all instances access the same metadata service\" did really mean are they all local. Sorry for being unclear. But I think your answer is yes, they are, right?)\n> \n> Implementing the peer discovery in the instances themselves requires some kind of multicast or knowing a list of addresses to try. In both cases either the actual addresses or some name resolved through a naming service would do. Whatever is starting your instances does have access to at least nova, so it can find out if there are any running instances and what their addresses are. These could be used as the addresses they try first. These are the way that internet p2p services work and they work in the cloud.\n> \n\nThat\'s kind of my point about using Heat. You can use any higher level\ntool to achieve this by dropping the existing addresses into userdata\nand then using a gossip protocol to \"spread the word\" to existing nodes\nabout new ones.\n\n\n','<39E5672E03A1CB4B93936D1C4AA5E15D155375B6@G6W2484.americas.hpqcorp.net>',NULL),('<1391677718-sup-2507@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-06 01:19:19',-28800,'2014-02-06 09:19:19',NULL,'[openstack-dev] [heat] Sofware Config progress [for appliances]','Excerpts from Mike Spreitzer\'s message of 2014-02-05 22:17:50 -0800:\n> > From: Prasad Vellanki <prasad.vellanki at oneconvergence.com>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\" \n> > <openstack-dev at lists.openstack.org>, \n> > Date: 01/21/2014 02:16 AM\n> > Subject: Re: [openstack-dev] [heat] Sofware Config progress\n> > \n> > Steve & Clint\n> > \n> > That should work. We will look at implementing a resource that spins\n> > up a shortlived VM for bootstrapping a service VM and informing \n> > configuration server for further configuration. \n> > \n> > thanks\n> > prasadv\n> > \n> \n> > On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake <sdake at redhat.com> wrote:\n> > On 01/14/2014 09:27 PM, Clint Byrum wrote:\n> > Excerpts from Prasad Vellanki\'s message of 2014-01-14 18:41:46 -0800:\n> > Steve\n> > \n> > I did not mean to have custom solution at all. In fact that would be\n> > terrible.  I think Heat model of software config and deployment is \n> really\n> > good. That allows configurators such as Chef, Puppet, Salt or Ansible to \n> be\n> > plugged into it and all users need to write are modules for those.\n> > \n> > What I was  thinking is if there is a way to use software \n> config/deployment\n> >   to do initial configuration of the appliance by using agentless system\n> > such  as Ansible or Salt, thus requiring no cfminit. I am not sure this\n> > will work either, since it might require ssh keys to be installed for\n> > getting ssh to work without password prompting. But I do see that \n> ansible\n> > and salt support username/password option.\n> > If this would not work, I agree that the best option is to make them\n> > support cfminit...\n> > Ansible is not agent-less. It just makes use of an extremely flexible\n> > agent: sshd. :) AFAIK, salt does use an agent though maybe they\'ve added\n> > SSH support.\n> > \n> > Anyway, the point is, Heat\'s engine should not be reaching into your\n> > machines. It talks to API\'s, but that is about it.\n> > \n> > What you really want is just a VM that spins up and does the work for\n> > you and then goes away once it is done.\n> > Good thinking.  This model might work well without introducing the \n> > \"groan another daemon\" problems pointed out elsewhere in this thread\n> > that were snipped.  Then the \"modules\" could simply be heat \n> > templates available to the Heat engine to do the custom config setup.\n> > \n> > The custom config setup might still be a problem with the original \n> > constraints (not modifying images to inject SSH keys).\n> > \n> > That model wfm.\n> > \n> > Regards\n> > -steve\n> > \n> \n> (1) What destroys the short-lived VM if the heat engine crashes between \n> creating and destroying that short-lived VM?\n> \n\nThe heat-engine that takes over the stack. Same as the answer for what\nhappens when a stack is half-created and heat-engine dies.\n\n> (2) What if something goes wrong and the heat engine never gets the signal \n> it is waiting for?\n> \n\nTimeouts already cause failed state or rollback.\n\n> (3) This still has the problem that something needs to be configured \n> some(client-ish)where to support the client authorization solution \n> (usually username/password).\n>\n\nThe usual answer is \"that\'s cloud-init\'s job\" but we\'re discussing\nworking around not having cloud-init, so I suspect it has to be built\ninto the image (which, btw, is a really really bad idea). Another option\nis that these weird proprietary systems might reach out to an auth\nservice which the short-lived VM would also be able to contact given\nappropriate credentials for said auth service fed in via parameters.\n\n> (4) Given that everybody seems sanguine about solving the client \n> authorization problem, what is wrong with code in the heat engine opening \n> and using a connection to code in an appliance?  Steve, what do you mean \n> by \"reaching into your machines\" that is critically different from calling \n> their APIs?\n> \n\nWe can, and should, poke holes from heat-engine, out through a firewall,\nso it can connect to all of the endpoints. However, if we start letting\nit talk to all the managed machines, it becomes a really handy DoS tool\nand also spends a ton of time talking to things that we have no control\nover, thus taking up resources to an unknown degree.\n\nHeat-engine is precious, it has access to a database with a ton of really\nsensitive information. It is also expensive when heat-engine dies (until\nwe can make all tasks distributed) as it may force failure states. So\nI think we need to be very careful about what we let it do.\n\n> (5) Are we really talking about the same kind of software configuration \n> here?  Many appliances do not let you SSH into a bash shell and do \n> whatever you want; they provide only their own API or special command \n> language over a telnet/ssh sort of connection.  Is hot-software-config \n> intended to cover that?  Is this what the OneConvergence guys are \n> concerned with?\n> \n\nNo. We are suggesting a solution to their unique problem of having to\ntalk to said API/special command language/telnet/IP-over-avian-carrier.\nThe short-lived VM can just have a UserData section which does all of\nthis really.\n\n\n','<OF06F4E9E8.45EEB067-ON85257C77.0020CD48-85257C77.00229812@us.ibm.com>',NULL),('<1391698201.3703.33.camel@lappy.neofreak.org>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-06 09:50:01',-18000,'2014-02-06 14:50:01',NULL,'[Openstack] port on openvswitch not tagged upon VM launch','Hi list,\n\nin case it can be of any help to someone who stumble upon my post, i\nfinally was able to fix my problem.\n\nIt was an iptables problem that was preventing the neutron ovs agent to\ncomplete its configuration tasks on my compute node. Thus, the\niptables-restore error messages in the neutron agent log were\nmeaningful.\n\nIt was not clear, at first, to figure out how to find which piece of\niptables were disrupting but, i finally came up with an idea.\n\nIn the neutron ovs agent, in the\nfile /neutron/agent/linux/iptables_manager.py,\nat line 378, i did replace :\n\nargs = [\'%s-restore\' % (cmd,), \'-c\']\n\nby :\n\nargs = [\'tee\', \'/tmp/neutron_debug\']\n\nand then, i had a copy of the iptables rules that were supposed to be\napplied to my compute node by neutron ovs agent.\n\n>From there, i was able to identify the rules that were causing problems;\nrules with \"-m physdev\" in them.\n\nFinally, looks like i was missing CONFIG_NETFILTER_XT_MATCH_PHYSDEV in\nmy kernel.\n\nAdding support for it in my kernel and restarting the neutron ovs agent\nfinally fixed my problem!\n\nThanks to Ageeleshwar who gave me some tips on how to solve this.\n\nTony\n\nOn Mon, 2014-02-03 at 14:00 -0500, DeadManMoving wrote:\n> Hi,\n> \n> thanks for the info, it helped me going a bit further with this.\n> \n> I did not have anything configured regarding vif in my nova.conf file on\n> my compute node.\n> \n> So i tried putting the following :\n> \n> libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtGenericVIFDriver\n> libvirt_ovs_bridge=br-int\n> libvirt_use_virtio_for_bridges=true\n> \n> in my nova.conf config file on my compute node but it did not help.\n> \n> So i wanted to have a better look at the neutron logs but, they were\n> full of : \'iptables-restore: line 62 failed\\n\'\n> messages so, it was a bit hard to figure something out.\n> \n> So i tried to disable the firewall driver, by changing :\n> \n> firewall_driver =\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> \n> to :\n> \n> firewall_driver = neutron.agent.firewall.NoopFirewallDriver\n> \n> in my ovs_neutron_plugin.ini config file and surprisingly, it started\n> working, the port is tagged automatically.\n> \n> That brings me to my next question, why would the port be tagged\n> correctly with firewall_driver set to\n> neutron.agent.firewall.NoopFirewallDriver but not with\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> ?!\n> \n> @Ageeleshwar Kandavelu\n> \n> I don\'t have physical interfaces on my integration bridge, just on my\n> normal (first) bridge (in my case br0).\n> \n> \n> Thank you so much!\n> \n> Tony\n> \n> On Mon, 2014-02-03 at 09:27 +0000, Darragh O\'Reilly wrote:\n> > Hi,\n> > \n> > the ovs-agent is responsible for tagging the port. It\'s strange\n> > that it can tag the dhcp port ok but not the nova port. What VIF\n> > driver are you using - libvirt_vif_driver in nova.conf?\n> > \n> > Check the syslog - all the ovs-vsctl commands are logged there.\n> > Look for messages about this port. Are there any errors in the\n> > ovs-agent log?\n> > \n> > Re, Darragh.\n> > \n> > >i have a nearly working neutron + openvswitch + VLAN setup but, i have a\n> > >small problem however...\n> > >\n> > >I am running neutron-server on a node controller and\n> > >neutron-openvswitch-agent and neutron-dhcp-agent running on a compute\n> > >node.\n> > >\n> > >On the compute node, i have an initial bridge, with two physical\n> > >interfaces in bonding, with some VLANs trunked on the bond.\n> > >\n> > >On the controller node, i created a network with --provider:network_type\n> > >vlan and --provider:segmentation_id xxx (xxx being one of the VLAN\n> > >trunked on the bond inside my initial bridge). Then, i created a subnet\n> > >on that network.\n> > >\n> > >When i launch neutron-dhcp-agent on the compute node, everything seem\n> > >fine : the namespace is being created, there is a port with tag 1 on the\n> > >integration bridge for the dnsmasq process and, i can ping the IP of the\n> > >dnsmasq process from a device on the xxx vlan. I can also see the\n> > >openflow flows for vlan modification on both bridge (vlan xxx to vlan 1,\n> > >vlan 1 to vlan xxx).\n> > >\n> > >However, my problem is that when i launch a VM using the network i\n> > >created in neutron, a port is being created in the integration bridge\n> > >but, it is not tagged with vlan 1 so, the VM is unable to communicate on\n> > >the network. As soon as i tag the port with vlan 1, with a command\n> > >like : \n> > >\n> > >ovs-vsctl set Port tap1234-ab tag=1 \n> > >\n> > >the VM is able to communicate on the network.\n> > >\n> > >\n> > >So, am i missing something obvious? Or maybe that i have something\n> > >misconfigured in my neutron setup?\n> > >\n> > >\n> > >Any help would be greatly appreciated.\n> > >\n> > >Regards,\n> > >\n> > >Tony\n> > \n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<1391454037.3703.30.camel@lappy.neofreak.org>',NULL),('<1391719466-sup-4952@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-06 12:46:29',-28800,'2014-02-06 20:46:29',NULL,'[openstack-dev] Asynchrounous programming: replace eventlet\n	with asyncio','All due respect to Zane who created the scheduler. We simply could not\ndo what we do without it (and I think one of the first things I asked\nfor was parallel create ;).\n\nIMO it is the single most confusing thing in Heat whenever one has to\ndeal with it. If we could stick to a threading model instead, I would\nmuch prefer that.\n\nExcerpts from Joshua Harlow\'s message of 2014-02-06 10:22:24 -0800:\n> Has there been any investigation into heat.\n> \n> Heat has already used parts of the coroutine approach (for better or\n> worse).\n> \n> An example: \n> https://github.com/openstack/heat/blob/master/heat/engine/scheduler.py#L230\n> \n> \"\"\"\n>     Decorator for a task that needs to drive a subtask.\n> \n>     This is essentially a replacement for the Python 3-only \"yield from\"\n>     keyword (PEP 380), using the \"yield\" keyword that is supported in\n>     Python 2. For example::\n> \"\"\"....\n> \n> \n> I bet trollius would somewhat easily replace a big piece of that code.\n> \n> -Josh\n> \n> -----Original Message-----\n> From: victor stinner <victor.stinner at enovance.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Date: Thursday, February 6, 2014 at 1:55 AM\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] Asynchrounous programming: replace eventlet\n> with asyncio\n> \n> >Sean Dague wrote:\n> >> First, very cool!\n> >\n> >Thanks.\n> >\n> >> This is very promising work. It might be really interesting to figure\n> >> out if there was a smaller project inside of OpenStack that could be\n> >> test ported over to this (even as a stackforge project), and something\n> >> we could run in the gate.\n> >\n> >Oslo Messaging is a small project, but it\'s more a library. For a full\n> >daemon, my colleague Mehdi Abaakouk has a proof-on-concept for Ceilometer\n> >replacing eventlet with asyncio. Mehdi told me that he doesn\'t like to\n> >debug eventlet race conditions :-)\n> >\n> >> Our experience is the OpenStack CI system catches bugs in libraries and\n> >> underlying components that no one else catches, and definitely getting\n> >> something running workloads hard on this might be helpful in maturing\n> >> Trollius. Basically coevolve it with a piece of OpenStack to know that\n> >> it can actually work on OpenStack and be a viable path forward.\n> >\n> >Replacing eventlet with asyncio is a huge change. I don\'t want to force\n> >users to use it right now, nor to do the change in one huge commit. The\n> >change will be done step by step, and when possible, optional. For\n> >example, in Olso Messaging, you can choose the executor: eventlet or\n> >blocking (and I want to add asyncio).\n> >\n> >Victor\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CF19126F.558DC%harlowja@yahoo-inc.com>',NULL),('<1391783654.1569.5.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 09:34:14',-18000,'2014-02-07 14:34:14',NULL,'[openstack-dev] pep8 barfs on long URL','On Fri, 2014-02-07 at 14:25 +0000, Matthew Booth wrote:\n> I have a comment which references a long URL. The URL itself is longer\n> than 80 characters. Jenkins has flagged this as a pep8 failure, because\n> the line is longer than 80 characters.\n> \n> This is an instance where in the past I have always applied common sense\n> to the line length limit. You either have a long line or a broken URL.\n> As the long line is more usable in this instance, it\'s the lesser of 2\n> evils.\n> \n> Is there a mechanism to to coerce Jenkins to allow it? Failing that, is\n> there a mechanism to manually ignore a specific Jenkins failure? Failing\n> that, is there a project convention for broken URLs?\n\nHow about using a service like bit.ly to shorten the URL? Would that be\nacceptable?\n\nBest,\n-jay\n\n\n\n','<52F4ECBE.3070504@redhat.com>',NULL),('<1391783730.1569.6.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 09:35:30',-18000,'2014-02-07 14:35:30',NULL,'[openstack-dev] pep8 barfs on long URL','On Fri, 2014-02-07 at 14:25 +0000, Matthew Booth wrote:\n> I have a comment which references a long URL. The URL itself is longer\n> than 80 characters. Jenkins has flagged this as a pep8 failure, because\n> the line is longer than 80 characters.\n> \n> This is an instance where in the past I have always applied common sense\n> to the line length limit. You either have a long line or a broken URL.\n> As the long line is more usable in this instance, it\'s the lesser of 2\n> evils.\n> \n> Is there a mechanism to to coerce Jenkins to allow it? Failing that, is\n> there a mechanism to manually ignore a specific Jenkins failure? Failing\n> that, is there a project convention for broken URLs?\n\nYou can also put a comment:\n\n  # NO QA\n\nat the end of the URL line to indicate to pep8/flake8 to ignore the\nerror, IIRC.\n\nBest,\n-jay\n\n\n\n','<52F4ECBE.3070504@redhat.com>',NULL),('<1391784020.1569.8.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 09:40:20',-18000,'2014-02-07 14:40:20',NULL,'[openstack-dev] pep8 barfs on long URL','On Fri, 2014-02-07 at 15:36 +0100, Julien Danjou wrote:\n> On Fri, Feb 07 2014, Jay Pipes wrote:\n> \n> > On Fri, 2014-02-07 at 14:25 +0000, Matthew Booth wrote:\n> >> I have a comment which references a long URL. The URL itself is longer\n> >> than 80 characters. Jenkins has flagged this as a pep8 failure, because\n> >> the line is longer than 80 characters.\n> >> \n> >> This is an instance where in the past I have always applied common sense\n> >> to the line length limit. You either have a long line or a broken URL.\n> >> As the long line is more usable in this instance, it\'s the lesser of 2\n> >> evils.\n> >> \n> >> Is there a mechanism to to coerce Jenkins to allow it? Failing that, is\n> >> there a mechanism to manually ignore a specific Jenkins failure? Failing\n> >> that, is there a project convention for broken URLs?\n> >\n> > How about using a service like bit.ly to shorten the URL? Would that be\n> > acceptable?\n> \n> This would be ridiculous. :-/\n\n? Why would that be ridiculous? I\'m not talking about having pep8 use\nbit.ly. I\'m talking about Matthew just shortening the URL with bit.ly\nand putting the shortened URL in the comment.\n\n> Isn\'t #noqa working on such error?\n\nYes, as I mentioned in a follow up...\n\n-jay\n\n\n\n','<m21tzf2dmn.fsf@danjou.info>',NULL),('<1391789825.1569.21.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-07 11:17:05',-18000,'2014-02-07 16:17:05',NULL,'[OpenStack-Infra] External testing account','Hi Infra tream,\n\nI\'ve been working on a set of Puppet modules (and soon to be Ansible\nplaybooks) for deploying a 3rd party testing platform:\n\nhttps://github.com/jaypipes/os-ext-testing\n\nI\'m almost done with it, but I need to complete end-to-end testing of\neverything, and to do that, I need a testing account that can post\nreviews to the OpenStack Gerrit system.\n\nThat said, I don\'t want to clutter any OpenStack project\'s code reviews\nwith test comments. Is there a test project somewhere that is used for\nthis type of testing that I could use to test out the deployment modules\nfrom the repo above? Perhaps we can create a Gerrit project that is\nspecifically used for parties to test their external test platforms?\n\nHere is information about the testing account:\n\npublic SSH key: \n\n> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9 jpipes at uberbox\n\nusername:\n\njaypipes-testing\n\nemail:\n\njpipes at mirantis.com\n\nThanks much in advance, I\'m hoping these deployment modules will be\nhandy for all the vendors currently trying to set up external testing\nsystems that are liked with upstream.\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1391790923.2185.41.camel@recto>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 11:35:23',-18000,'2014-02-07 16:35:23',NULL,'[openstack-dev] oslo.config improvements','I\'ve been working on the code that generates our configuration docs. A\ncouple week ago, I rewrote most of it to address some major problems,\nmost notably its inability to distinguish same-named options in\ndifferent groups.\n\nI\'ve tried to reuse bits from the oslo-incubator code to generate sample\nconfig files, but it\'s been tricky. Failing that, I\'ve tried to write\nthe docs generator in a way where its code could be moved somewhere and\nreused by multiple projects.\n\nThe way the config file generator in oslo-incubator works right now has\nsome major problems, which I\'d like to address:\n\n1) Because of the way it iterates over modules, then over all options,\nit\'s considerably slower than it should be. The config file generator\ngroups by defining module, so it needs that info. The config docs\ngnerator doesn\'t do anything with the defining module right now, but I\nwouldn\'t rule out the possibility in the future.\n\n2) It locates options based on them being defined at the top level of a\nmodule (not in function or packed into some object), but it gets info by\nlooking at cfg.CONF, which require registration. This fails if an option\nis defined by only registered when some function is called. This happens\nright now with the ip_lib_force_root option in Neutron. Both the config\nfile generator and config docs generator currently crash on Neutron\nbecause of this.\n\n3) It\'s completely incapable of finding options that aren\'t defined or\nregistered until some function is called or some object is instantiated.\nI don\'t have a general solution to this, although I do have special-case\ncode that detects projects that use oslo.messaging and ensures those\noptions get registered.\n\nTo address these issues, I\'d like to get oslo.config to know about the\ndefining module for each option. It can get that using something like\nthis in Opt.__init__:\n\nfor frame in inspect.stack():\n    mod = inspect.getmodule(frame[0])\n    if mod == sys.modules[__name__]:\n        continue\n    self.module = mod.__name__\n        break\n\nWe\'d also have to modify __eq__ and __ne__, because it\'s valid for an\noption to be defined in two different modules as long as all its\nparameters are the same. Checking vars() equality would trip up on the\nmodule. (There\'s the further issue that the defining module is\nnon-deterministic in those cases.)\n\nThen I\'d like to get both the config file generator and the config docs\ngenerator using something like the OptionsCache class I wrote for the\nconfig docs generator:\n\nhttp://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/common.py#n88\n\nThis could be simpler and faster and avoid the crash mentioned above\nwith the module info attached to each option.\n\nIs any part of this feasible? Has anybody else worked on resolving these\ntypes of issues with the config file generator?\n\n--\nShaun\n\n\n\n\n',NULL,NULL),('<1391791495.2401.54.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-07 16:44:55',0,'2014-02-07 16:44:55',NULL,'[OpenStack Foundation] Jan 30 Board Meeting','Hey\n\nHere\'s my informal summary of our recent board meeting:\n\n  http://blogs.gnome.org/markmc/2014/02/07/jan-30-openstack-foundation-board-meeting/\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1391796323.1569.34.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-07 13:05:23',-18000,'2014-02-07 18:05:23',NULL,'[OpenStack-Infra] External testing account','On Fri, 2014-02-07 at 17:57 +0000, Octavian Ciuhandu wrote:\n> Hi Jay,\n> \n> Thanks for the great work, we?ve just been going through the process of setting up the Hyper-V CI and this would have helped a lot. I have also left a couple of comments on the git repo.\n\nThank you Octavian,\n\nI responded to your comment on the last patch. Basically, that patch\n(and the problem you highlight) was the reason I wrote this email :)\n\nI have hard-coded the openstack/cinder project in the layout.yaml file\nfor Zuul right now, but I am going to make this into either a Puppet\ntemplate or put the layout.yaml file in the examples/files/ directory\nlike the projects.yaml file...\n\nJust trying to figure out a way to make the os-ext-testing repo as easy\nas possible for folks to get the testing platform up and running,\nwithout any hardcoding of projects, but with some sensible defaults.\n\nBest,\n-jay\n\n> \n> Thanks,\n> \n> Octavian.\n> \n> \n> On 7 Feb 2014, at 18:17, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > Hi Infra tream,\n> > \n> > I\'ve been working on a set of Puppet modules (and soon to be Ansible\n> > playbooks) for deploying a 3rd party testing platform:\n> > \n> > https://github.com/jaypipes/os-ext-testing\n> > \n> > I\'m almost done with it, but I need to complete end-to-end testing of\n> > everything, and to do that, I need a testing account that can post\n> > reviews to the OpenStack Gerrit system.\n> > \n> > That said, I don\'t want to clutter any OpenStack project\'s code reviews\n> > with test comments. Is there a test project somewhere that is used for\n> > this type of testing that I could use to test out the deployment modules\n> > from the repo above? Perhaps we can create a Gerrit project that is\n> > specifically used for parties to test their external test platforms?\n> > \n> > Here is information about the testing account:\n> > \n> > public SSH key: \n> > \n> >> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9 jpipes at uberbox\n> > \n> > username:\n> > \n> > jaypipes-testing\n> > \n> > email:\n> > \n> > jpipes at mirantis.com\n> > \n> > Thanks much in advance, I\'m hoping these deployment modules will be\n> > handy for all the vendors currently trying to set up external testing\n> > systems that are liked with upstream.\n> > \n> > Best,\n> > -jay\n> > \n> > \n> > _______________________________________________\n> > OpenStack-Infra mailing list\n> > OpenStack-Infra at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> \n\n\n\n\n','<2495BBF2-C872-4071-88A2-1549CE7C9D26@cloudbasesolutions.com>',NULL),('<1391800516.1569.43.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-07 14:15:16',-18000,'2014-02-07 19:15:16',NULL,'[openstack-dev] [Tempest][Glance] Bogus Glance service and\n endpoint required for Tempest?','On Fri, 2014-02-07 at 12:01 -0700, Brian C Thornock wrote:\n> We are currently developing towards an OpenStack deployment of just\n> Keystone and Swift. Tempest would not run. We added a bogus Glance\n> entry to the service catalog with a corresponding bogus Glance\n> endpoint, and voila, Tempest ran and passed. Hmm.\n> \n> I am a newcomer to the OpenStack party, but this seemed odd because we\n> did not deploy Glance but just added bogus entries to the service and\n> endpoint lists. Magically, Tempest ran fine then. It clearly isn\'t\n> making queries or requests to Glance, as nothing was listening on port\n> 9292. Is it necessary then?\n\nNo, it should not be a requirement to run things like the Keystone and\nSwift API tests, so that\'s a bug -- feel free to file one.\n\nLikely can be fixed by identifying the piece of the Tempest module setup\nthat requires an image endpoint in the Keystone catalog and then making\nthat piece of code switchable by a config option.\n\nBest,\n-jay\n\n\n\n\n','<CAPatcVbtCeyeiUFqfDBTsOoOHfTYu=PUsTumQvTND9HF227iiA@mail.gmail.com>',NULL),('<1391848903.2675.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-08 16:41:43',28800,'2014-02-08 08:41:43',NULL,'[Openstack] horizon for swift','hello all,\n\nI had installed openstack swift on my laptop by creating a VM of Ubuntu 12.04 desktop using the link?http://docs.openstack.org/developer/swift/development_saio.html\n\nit provides a CLI for using swift.\nI want a dashboard so that I can access swift functionality by \'click& go\', not by writting the commands.\nfor this purpose, I want to install openstack horizon and integrate it with existing swift environment.\nWhat should I do for the same?\n\nPlease help in this regard\n\n-------\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140208/2db57c65/attachment.html>\n\n',NULL,NULL),('<1391883231.11383.1.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-08 13:13:51',-18000,'2014-02-08 18:13:51',NULL,'[OpenStack-Infra] External testing account','On Sat, 2014-02-08 at 10:40 +0000, Monty Taylor wrote:\n> We have a test repo, but also have a whole Dev gerrit ... Perhaps we should just make you a repo there?\n\nSure, whatever makes sense and is easiest for infra folks to do. I don\'t\nwant to be a bother, but also don\'t want to be posting test comments\ninto Cinder and Neutron code reviews ;)\n\nBest,\n-jay\n\n> On Feb 7, 2014 4:17 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> >\n> > Hi Infra tream, \n> >\n> > I\'ve been working on a set of Puppet modules (and soon to be Ansible \n> > playbooks) for deploying a 3rd party testing platform: \n> >\n> > https://github.com/jaypipes/os-ext-testing \n> >\n> > I\'m almost done with it, but I need to complete end-to-end testing of \n> > everything, and to do that, I need a testing account that can post \n> > reviews to the OpenStack Gerrit system. \n> >\n> > That said, I don\'t want to clutter any OpenStack project\'s code reviews \n> > with test comments. Is there a test project somewhere that is used for \n> > this type of testing that I could use to test out the deployment modules \n> > from the repo above? Perhaps we can create a Gerrit project that is \n> > specifically used for parties to test their external test platforms? \n> >\n> > Here is information about the testing account: \n> >\n> > public SSH key: \n> >\n> > > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9 jpipes at uberbox \n> >\n> > username: \n> >\n> > jaypipes-testing \n> >\n> > email: \n> >\n> > jpipes at mirantis.com \n> >\n> > Thanks much in advance, I\'m hoping these deployment modules will be \n> > handy for all the vendors currently trying to set up external testing \n> > systems that are liked with upstream. \n> >\n> > Best, \n> > -jay \n> >\n> >\n> > _______________________________________________ \n> > OpenStack-Infra mailing list \n> > OpenStack-Infra at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra \n> >\n\n\n\n\n','<E1WC5Kb-00061I-4p@scylla.inaugust.com>',NULL),('<1391919013.65978.YahooMailNeo@web163804.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-08 20:10:13',-28800,'2014-02-09 04:10:13',NULL,'[openstack-dev] [Neutron] Using Python-Neutronclient from\n	Python - docstrings needed?','Sean,\nWe have written a few docs for writing these samples\n\nhttp://python-api-guide.cfapps.io/content/neutron.html\n\n\nYou can find get the source here?https://github.com/rajdeepd/openstack-samples\n\nThanks\nRajdeep\n\n\n\nOn Sunday, February 9, 2014 12:57 AM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n \nHi,\n\nI was writing a small script yesterday to parse a list of IP blocks and\ncreate security groups and rules, by using python-neutronclient.\n\nTo be honest, it was very difficult - even though I have actually\nwritten extensions to Python-Neutronclient for the QoS API. \n\nFor those that are trying to use the client from inside their code,\nthey end up getting zero help as to how to actually call any of the\nfunctions, and what parameters they take. \n\n\n? ? >>> neutron = client.Client(\'2.0\', auth_url=os.environ[\'OS_AUTH_URL\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ?  tenant_id=os.environ[\'OS_TENANT_ID\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ?  username=os.environ[\'OS_USERNAME\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ?  password=os.environ[\'OS_PASSWORD\'])\n? ? >>> help(neutron)\n\n?  |? create_credential = <function with_params>\n?  |? \n?  |? create_firewall = <function with_params>\n?  |? \n?  |? create_firewall_policy = <function with_params>\n?  |? \n?  |? create_firewall_rule = <function with_params>\n?  |? \n?  |? create_floatingip = <function with_params>\n?  |? \n?  |? create_health_monitor = <function with_params>\n?  |? \n?  |? create_ikepolicy = <function with_params>\n?  |? \n?  |? create_ipsec_site_connection = <function with_params>\n?  |? \n?  |? create_ipsecpolicy = <function with_params>\n?  |? \n?  |? create_member = <function with_params>\n?  |? \n?  |? create_metering_label = <function with_params>\n\n\nSince there was nothing there, I decided to go check the source of\npython-neutronclient and see if there are any examples.\n\nhttps://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst\n\nIf you read closely enough, you\'ll find out that the function takes a\ndictionary, that looks very similar to the request/response examples\nlisted in the API documentation. So, I went over and checked it out.\n\nhttp://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html\n\nSo from there, I was able to remember enough that each of these\nfunctions takes a single argument, that is a dictionary, that mimics\nthe same structure that you see in the API documentation, so from there\nit was just some experimentation to get the structure right.\n\nHonestly it wasn\'t easy to remember all this stuff, since\nit had been a couple months since I had worked with\npython-neutronclient, and it had been from inside the library itself.\n\nThis was my first experience using it \"on the outside\" and it was pretty\ntough - so I\'m going to try and look into how we can improve the\ndocstrings for the client object, to make it a bit easier to figure out.\n\nThoughts?\n\n-- \nSean M. Collins\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/fe2e9989/attachment.html>\n\n','<20140208192001.GB40776@HQSML-1081034.cable.comcast.com>',NULL),('<1391986653-sup-1673@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-09 14:57:56',-28800,'2014-02-09 22:57:56',NULL,'[openstack-dev] [heat] Nominate Jason Dunsmore for heat-core','Curse you Randall for taking first post!\n\n+1\n\nExcerpts from Randall Burt\'s message of 2014-02-09 14:47:39 -0800:\n> Very +1\n> \n> -------- Original message --------\n> From: Steve Baker\n> Date:02/09/2014 4:41 PM (GMT-06:00)\n> To: OpenStack Development Mailing List\n> Subject: [openstack-dev] [heat] Nominate Jason Dunsmore for heat-core\n> \n> I would like to nominate Jason Dunsmore for heat-core.\n> \n> His reviews are valuable and prolific, his code contributions have\n> demonstrated a good knowledge of heat internals, and he has endured a\n> sound hazing to get multi-engine into heat.\n> \n> http://russellbryant.net/openstack-stats/heat-reviewers-60.txt\n> http://www.stackalytics.com/?release=icehouse&metric=commits&user_id=jasondunsmore\n> \n> Heat cores, please reply with your vote.\n> \n> cheers\n> \n\n\n','<wtoej1pxfngrkommyrexx8nt.1391986056166@email.android.com>',NULL),('<1391994302.11383.6.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-09 20:05:02',-18000,'2014-02-10 01:05:02',NULL,'[OpenStack-Infra] External testing account','On Mon, 2014-02-10 at 01:00 +0000, Jeremy Stanley wrote:\n> On 2014-02-07 11:17:05 -0500 (-0500), Jay Pipes wrote:\n> [...]\n> > That said, I don\'t want to clutter any OpenStack project\'s code reviews\n> > with test comments. Is there a test project somewhere that is used for\n> > this type of testing that I could use to test out the deployment modules\n> > from the repo above? Perhaps we can create a Gerrit project that is\n> > specifically used for parties to test their external test platforms?\n> \n> Yes, you can create and comment on changes in the\n> openstack-dev/sandbox repository on review.openstack.org all you\n> like. That\'s one of the reasons it exists.\n\nAwesomesauce. That\'s perfect :)\n\n> > Here is information about the testing account:\n> > \n> > public SSH key:\n> [...]\n> > username: jaypipes-testing\n> > email: jpipes at mirantis.com\n> [...]\n> \n> I\'ve created the account as requested. It can place VRFY votes in\n> the -1/+1 range on openstack-dev/sandbox for testing purposes.\n> \n> Note that the ACL to let the new \"Third-Party CI\" group vote\n> exclusively on openstack-dev/sandbox just merged, so if you run into\n> any trouble it\'s entirely possible I did something wrong... let me\n> know if so!\n\nWill do. Very much appreciated, sir!\n\nBest,\n-jay\n\n\n\n','<20140210010023.GS2347@yuggoth.org>',NULL),('<1391997549.11383.10.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-09 20:59:09',-18000,'2014-02-10 01:59:09',NULL,'[openstack-dev] [nova] Possible Hyper-V false CI failures','On Sun, 2014-02-09 at 18:17 -0700, Christopher Yeoh wrote:\n> Hi,\n> \n> \n> I think  the hyper-v CI system is sometimes failing with this message\n> incorrectly:\n> \n>   \"This change was unable to be automatically merged with the current\n> state of the repository. Please rebase your change and upload a new\n> patchset.\"\n> \n> \n> I only mention it because its the second time I\'ve seen it. An example\n> here:\n> \n> https://review.openstack.org/#/c/72197/\n> \n> \n> The changeset was made off a very fresh git update and there doesn\'t\n> appear to be any updates merged since then.  The last time this error\n> appeared for me the rebase had no conflicts and Jenkins did not have\n> any trouble testing the same patchset that the Hyper-V one failed to\n> merge.\n\nYeah, it may not be a rebase issue at all. The problem may be that the\nfailure-message setting on the Zuul pipeline that is being triggered or\nJenkins Gerrit trigger plugin is set to the above message, regardless of\nwhether the failure is indeed due to the failure of a rebase...\n\nOctavius, is it possible to pastebin your Zuul layout.yaml?\n\nBest,\n-jay\n\n\n\n\n\n\n','<CANCY3ef99QHa-1rEuVk+5KS6_yhdij2xoSomQ3Y-S0tTnpntEQ@mail.gmail.com>',NULL),('<1392009888.79343.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-09 21:24:48',-28800,'2014-02-10 05:24:48',NULL,'[openstack-dev] [Neutron] Using Python-Neutronclient from\n	Python - docstrings needed?','Yes, We would be interested in doing that.\nPlease let me know which is the right group/ team for this?\n\n\n\n\n\nOn Monday, February 10, 2014 10:34 AM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n \nDo you have plans to submit these back upstream? It would be a great first start, perhaps we could add these as examples underneath the JSON request/reponse in http://api.openstack.org/api-ref-networking.html\n\n\n\nSean M. Collins\n\n\n________________________________\n \nFrom: Rajdeep Dua [dua_rajdeep at yahoo.com]\nSent: Saturday, February 08, 2014 11:10 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?\n\n\nSean,\nWe have written a few docs for writing these samples\n\nhttp://python-api-guide.cfapps.io/content/neutron.html\n\n\nYou can find get the source here?https://github.com/rajdeepd/openstack-samples\n\nThanks\nRajdeep\n\n\n\nOn Sunday, February 9, 2014 12:57 AM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n\nHi,\n\nI was writing a small script yesterday to parse a list of IP blocks and\ncreate security groups and rules, by using python-neutronclient.\n\nTo be honest, it was very difficult - even though I have actually\nwritten extensions to Python-Neutronclient for the QoS API. \n\nFor those that are trying to use the client from inside their code,\nthey end up getting zero help as to how to actually call any of the\nfunctions, and what parameters they take. \n\n\n? ? >>> neutron = client.Client(\'2.0\', auth_url=os.environ[\'OS_AUTH_URL\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? tenant_id=os.environ[\'OS_TENANT_ID\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? username=os.environ[\'OS_USERNAME\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? password=os.environ[\'OS_PASSWORD\'])\n? ? >>> help(neutron)\n\n? |? create_credential = <function with_params>\n? |? \n? |? create_firewall = <function with_params>\n? |? \n? |? create_firewall_policy = <function with_params>\n? |? \n? |? create_firewall_rule = <function with_params>\n? |? \n? |? create_floatingip = <function with_params>\n? |? \n? |? create_health_monitor = <function with_params>\n? |? \n? |? create_ikepolicy = <function with_params>\n? |? \n? |? create_ipsec_site_connection = <function with_params>\n? |? \n? |? create_ipsecpolicy = <function with_params>\n? |? \n? |? create_member = <function with_params>\n? |? \n? |? create_metering_label = <function with_params>\n\n\nSince there was nothing there, I decided to go check the source of\npython-neutronclient and see if there are any examples.\n\nhttps://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst\n\nIf you read closely enough, you\'ll find out that the function takes a\ndictionary, that looks very similar to the request/response examples\nlisted in the API documentation. So, I went over and checked it out.\n\nhttp://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html\n\nSo from there, I was able to remember enough that each of these\nfunctions takes a single argument, that is a dictionary, that mimics\nthe same structure that you see in the API documentation, so from there\nit was just some experimentation to get the structure right.\n\nHonestly it wasn\'t easy to remember all this stuff, since\nit had been a couple months since I had worked with\npython-neutronclient, and it had been from inside the library itself.\n\nThis was my first experience using it \"on the outside\" and it was pretty\ntough - so I\'m going to try and look into how we can improve the\ndocstrings for the client object, to make it a bit easier to figure out.\n\nThoughts?\n\n-- \nSean M. Collins\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140209/7c9a217b/attachment.html>\n\n','<7EB180D009B1A6428D376906754127CB2E0EDBD8@PACDCEXMB22.cable.comcast.com>',NULL),('<1392010133.75731.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 13:28:53',28800,'2014-02-10 05:28:53',NULL,'[Openstack] horizon for swift','hi krish\n\nthe link suggested by you is for installing openstack grizlly.\nI had already installed openstack swift on my machine.\nAnd I wand a user interface to operate swift functionality.\nFor that purpose only, I want to integrate horizon with swift.\nPlease help in this regard.\n\nPragya Jain\n\n\n\nOn Saturday, 8 February 2014 7:14 PM, krish <das.srikrishna at gmail.com> wrote:\n \n>?What should I do for the same?\n>\n>Well, as you wrote \"I want to install openstack horizon\"\n>so go ahead and \"install horizon\"\n>\n>http://www.stackgeek.com/guides/gettingstarted.html\n>\n>\n>-- \n>\n>Have a Power-Up Day!\n>--\n>Krish\n>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140210/20f0bf24/attachment.html>\n\n','<CA+Vv_Q0KNu_32w2ae+g6OZj3X+LOR1N3es3BQcFZky1d9_LgiQ@mail.gmail.com>',NULL),('<1392013135.22954.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 14:18:55',28800,'2014-02-10 06:18:55',NULL,'[Openstack] horizon for swift','hi swapnil,\n\nthanks for reply.\n\nI had installed swift on a VM using the link?http://docs.openstack.org/developer/swift/development_saio.html\nIs there not something through which I can integrate horizon with existing swift environment?\n\nPragya Jain\n\n\n\nOn Monday, 10 February 2014 11:19 AM, Swapnil Kulkarni <swapnilkulkarni2608 at gmail.com> wrote:\n \nHi Pragya,\n>\n>\n>I use the following devstack localrc configuration in case I need to setup swift for development purpose with single replica. You may want to try, you will get the switft container UI on dashboard with it.\n>\n>\n>ENABLED_SERVICES+=,swift\n>SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5\n>SWIFT_REPLICAS=1\n>SWIFT_DATA_DIR=$DEST/data\n>\n>\n>\n>Best Regards,\n>Swapnil Kulkarni\n>irc : coolsvap\n>\n>\n>\n>\n>On Mon, Feb 10, 2014 at 10:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hi krish\n>>\n>>\n>>the link suggested by you is for installing openstack grizlly.\n>>I had already installed openstack swift on my machine.\n>>And I wand a user interface to operate swift functionality.\n>>For that purpose only, I want to integrate horizon with swift.\n>>Please help in this regard.\n>>\n>>\n>>Pragya Jain\n>>\n>>\n>>\n>>On Saturday, 8 February 2014 7:14 PM, krish <das.srikrishna at gmail.com> wrote:\n>> \n>>>?What should I do for the same?\n>>>\n>>>Well, as you wrote \"I want to install openstack horizon\"\n>>>so go ahead and \"install horizon\"\n>>>\n>>>http://www.stackgeek.com/guides/gettingstarted.html\n>>>\n>>>\n>>>-- \n>>>\n>>>Have a Power-Up Day!\n>>>--\n>>>Krish\n>>>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>>>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>>\n>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140210/8f906d76/attachment.html>\n\n','<CAN_H9NipJNbbPDvYxJtu+6YRX30MjkJDGWS2pM8EcOR8SiYOfQ@mail.gmail.com>',NULL),('<1392017142.70306.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 15:25:42',28800,'2014-02-10 07:25:42',NULL,'[Openstack] problem in downloading the object','hi all,\n\ni create an account in swift.\nstatus of account shows that there is a container and zero objects in the account.\nwhen I list the container, it shows an object in it.\nBut whenI am downloading the object, it shows object not found.\n\nBelow are the steps which I follow:\n----------\n\nroot at swift-VirtualBox:~# export ST_AUTH=http://127.0.0.1:8080/auth/v1.0\nroot at swift-VirtualBox:~# export ST_USER=prag2648:pragya\nroot at swift-VirtualBox:~# export ST_KEY=pj2648\nroot at swift-VirtualBox:~# swift stat\n?????? Account: AUTH_prag2648\n??? Containers: 1\n?????? Objects: 0\n???????? Bytes: 0\n?Accept-Ranges: bytes\n?? X-Timestamp: 1387439464.98256\n??? X-Trans-Id: tx07ace110079247cfa7e27-0052f8762d\n? Content-Type: text/plain; charset=utf-8\nroot at swift-VirtualBox:~# swift list\nminerals\nroot at swift-VirtualBox:~# swift list minerals\nhome/swift/Desktop/swift_installation_steps.docx\nroot at swift-VirtualBox:~# swift download minerals home/swift/Desktop/swift_installation_steps.docx\nObject \'minerals/home/swift/Desktop/swift_installation_steps.docx\' not found\n-----------\n\nPlease help me in finding where is the problem.\n\nThanks \n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140210/01c4d4fa/attachment.html>\n\n',NULL,NULL),('<1392017611.8223.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 15:33:31',28800,'2014-02-10 07:33:31',NULL,'[Openstack] problem in creating new account','hi all,\n\nI am analysing swift functionalities.\nI authenticate in swift cluster as a superuser \'prag2648\', get storage-url and auth-token\nThen, i create a new account in swift, But I can not access the new account.\n\nBelow is the steps which I follow:\n------------\n\nroot at swift-VirtualBox:~# curl -v -H \'X-Storage-User: prag2648:pragya\' -H \'X-Storage-Pass: pj2648\' http://127.0.0.1:8080/auth/v1.0\n* About to connect() to 127.0.0.1 port 8080 (#0)\n*?? Trying 127.0.0.1... connected\n> GET /auth/v1.0 HTTP/1.1\n> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3\n> Host: 127.0.0.1:8080\n> Accept: */*\n> X-Storage-User: prag2648:pragya\n> X-Storage-Pass: pj2648\n> \n< HTTP/1.1 200 OK\n< X-Storage-Url: http://127.0.0.1:8080/v1/AUTH_prag2648\n< X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n< Content-Type: text/html; charset=UTF-8\n< X-Storage-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n< Content-Length: 0\n< X-Trans-Id: tx56a6487da88240e0abd13-0052f8773b\n< Date: Mon, 10 Feb 2014 06:52:43 GMT\n< \n* Connection #0 to host 127.0.0.1 left intact\n* Closing connection #0\nroot at swift-VirtualBox:~# curl -i -H \'X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\' -X PUT http://127.0.0.1:8080/v1/AUTH_arunjain\nHTTP/1.1 201 Created\nContent-Length: 0\nContent-Type: text/html; charset=UTF-8\nX-Trans-Id: txf807061b920d44d2a8756-0052f87815\nDate: Mon, 10 Feb 2014 06:56:21 GMT\n-----------\n\nPlease help in this regard.\n\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140210/c4c15444/attachment.html>\n\n',NULL,NULL),('<1392018347.53765.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 15:45:47',28800,'2014-02-10 07:45:47',NULL,'[Openstack] how to use cloudberry Explorer and cyberduck user\n	interface for swift','hi all,\n\ncloudberry Explorer and cyberduck, both, provide user interface for accessing openstack swift. Both of them are windows or Mac OS compatible, not supported by linux.\nI installed swift on my windows machine by creating a VM of ubuntu desktop.\nNow I want to use these products (cloudberry Explorer or cyberduck) for a user interface for swift.\nI download and install both of them on my host machine (windows based) and i am unable to understand how to use these products to access swift.\n\nPlease somebody help me in this regard.\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140210/9549d3ff/attachment.html>\n\n',NULL,NULL),('<1392055616.11435.6.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 13:06:56',-18000,'2014-02-10 18:06:56',NULL,'[Openstack] [User-committee] Formulate application developer\n oriented questions for the user survey','Don\'t forget about operating system!\n\nWhat operating system do you use?\n\n1. Linux\n2. MacOSX\n3. Windows\n4. Emacs\n\n:)\n\n-jay\n\nOn Mon, 2014-02-10 at 17:40 +0000, Everett Toews wrote:\n> To summarize. If there?s no further feedback on these by EOD Feb. 11, I?ll propose them to the User Committee. \n> \n> On the About You page [1] we update the \"What best describes your involvement with OpenStack?\" section as follows\n> \n> [ ] OpenStack cloud service provider - provides public or hosted private cloud services for other organizations\n> [ ] Ecosystem vendor - provides software or solutions that enable others to build or run OpenStack clouds\n> [ ] Private cloud operator - runs an OpenStack private cloud for their own organization\n> [ ] Application developer - has API or dashboard credentials and deploys/maintains an application running on an OpenStack cloud\n> [ ] Application operator - has API or dashboard credentials and develops an application running on an OpenStack cloud\n> \n> The Q&A:\n> \n> 1. What toolkits do you use or plan on using to interact with the OpenStack API?\n>   1. deltacloud (HTTP API)\n>   2. fog (Ruby)\n>   3. jclouds (Java)\n>   4. openstack.net (C#)\n>   5. OpenStack clients (Python)\n>   6. php-opencloud (PHP)\n>   7. pkgcloud (Node.js)\n>   8. Other (please specify)\n>   9. None (wrote our own)\n> \n> 2. If you wrote your own code for interacting with the OpenStack API, what programming language did you write it in?\n>   1. C/C++\n>   2. C#\n>   3. Java\n>   4. Node.js\n>   5. Ruby\n>   6. Perl\n>   7. PHP\n>   8. Python\n>   9. Other (please specify)\n> \n> 3. If you wrote your own code for interacting with the OpenStack API, what wire format are you using?\n>   1. JSON\n>   2. XML\n> \n> 4. What development environment do you use or plan on using?\n>   1. Eclipse or Eclipse based IDE\n>   2. Intellij IDEA or IDEA based IDE\n>   3. Visual Studio\n>   4. Sublime\n>   5. Vim\n>   6. Other (please specify)\n> \n> 5. What tools are you using or plan on using to deploy/configure your application?\n>   1. Ansible\n>   2. Chef\n>   3. Cloud Foundry and/or BOSH\n>   4. Docker\n>   5. OpenStack Orchestration (Heat)\n>   6. Puppet\n>   7. SaltStack\n>   8. Other (please specify)\n> \n> 6. Share your thoughts with us on the state of applications on OpenStack. Here are some questions to consider:\n>   1. What do you struggle with when developing and deploying applications on OpenStack? \n>   2. What?s missing that would make your life easier?\n>   3. Why did you choose a particular tool?\n>   4. Why didn?t you choose a particular tool?\n> \n>   Free form answers.\n> \n> Everett\n> \n> [1] https://www.openstack.org/user-survey/OrgInfo\n> \n> \n> \n> On Feb 5, 2014, at 3:40 AM, Dave Neary <dneary at redhat.com> wrote:\n> \n> > -----BEGIN PGP SIGNED MESSAGE-----\n> > Hash: SHA1\n> > \n> > Hi,\n> > \n> > On 02/04/2014 08:37 PM, Sean Dague wrote:\n> >> It is really easy to ask lots of questions, however, every\n> >> additional question causes a drop of in percentage responders. So\n> >> every question should have a clear reason for being asked other\n> >> than general interest.\n> > \n> > Agreed. There\'s a bunch of stuff I\'d like to know, but which I don\'t\n> > think we should be asking users.\n> > \n> >> And on a lighter note... how did vim make the list but not emacs?\n> >> ;)\n> > \n> > Because it\'s better. Duh. ;-)\n> > \n> > Cheers,\n> > Dave.\n> > \n> > - -- \n> > Dave Neary - Community Action and Impact\n> > Open Source and Standards, Red Hat - http://community.redhat.com\n> > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13\n> > -----BEGIN PGP SIGNATURE-----\n> > Version: GnuPG v1\n> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n> > \n> > iQEcBAEBAgAGBQJS8gcKAAoJECd1qeknDCgg6skIAIWXZ0oapOO0Z5AWIRAELjjs\n> > hYWszPwY36bbqrC9G3ifSm4RgDXHIs1aioJf7apQtcm2WtiBrBC3OgSE8qzGz5jl\n> > QXKNJLAXOLWvlPPPAVQNRV6jdnV2Eka2DreaK6pqJyFZAbx4tavrGIYbgh++Bm+j\n> > 9zPrSZPk0niF/g3lcnt72yxhFS16MZX6Hjj0XN5YsR87mtlNc51qtT7g7hOVHrNe\n> > I7KwKbm5sOaPjGEp3jzR+pkhnKub0lTn37MQotq/muIei8khGu0BdbTx2acQ5Zd7\n> > v10mAhrjgxVGHaWc/BbYxiAiZ7sTojDwJlaE3xrmGMCNIKTZfTHjbBPacVQZjJE=\n> > =A7r2\n> > -----END PGP SIGNATURE-----\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<2847E0C5-5298-47A2-8FB5-EBF24D402BA5@rackspace.com>',NULL),('<1392056336.64.1363845882434.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-21 06:04:42',0,'2013-03-21 06:04:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #171','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/171/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson6401571474590586642.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.E6TEGSmVzV\n+ TMPDIR=/tmp/tmp.E6TEGSmVzV\n+ trap \'rm -rf /tmp/tmp.E6TEGSmVzV\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.12 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.38    RoleAPITests.test_get_default_role\n    0.28    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.761s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.E6TEGSmVzV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/171\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/171/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/171/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<781835484.54.1363759522636.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1392058744.033731662@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-10 12:59:04',-21600,'2014-02-10 18:59:04',NULL,'[openstack-dev] [Solum] Milestone 1 End to end scenario','Hi Roshan,\n\nGreat to see the big picture that we are targeting.\nSome minor comments/suggestions:\n\n1) It will be helpful to explicitly call out in the first step that the git repositories are not\n   hosted by Solum but are public repositories on github.com\n\n1) In step 3, what do you mean by \'automatic\' deployment? I would suggest we remove that word.\n\n2) It will help if we use two different terms to identify the end users of an application\n   and the developer of an application.\n\n   In the line \'Only authorized users .. access the service\', I think you mean \'only application\n   developers who are also registered with Solum will be able to access\n   the Solum API service\'. In its current form it is not clear whether \'users\' refer to\n   developers or application users and whether \'service\' refers to solum API or the running application.\n   Similarly in the last line the last word can be changed from \'user\' to \'API user\'.\n\nThanks,\nDevdatta\n\n\n-----Original Message-----\nFrom: \"Roshan Agrawal\" <roshan.agrawal at RACKSPACE.COM>\nSent: Monday, February 10, 2014 12:28pm\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [Solum] Milestone 1 End to end scenario\n\nIt is exciting to see we are getting close to delivering the first end to end use case for Solum !\n\nThough we have blueprints to track individual work items for Milestone 1, it is useful to have a view into exactly what end to end experience we will be delivering. I have made an attempt at documenting that, and linked to the Solum High Level Roadmap wiki:\n\nhttps://wiki.openstack.org/wiki/Solum/Milestone1\n\nThe goal is not to have a comprehensive listing of all features delivered in M1, but rather to summarize in a few lines the desired outcome from a user perspective.\n\nComments, suggestions welcome.\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<9C1B7917DE16F44D855E72328D666ED12323C92E@ORD1EXD03.RACKSPACE.CORP>',NULL),('<1392059062.11435.11.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-10 14:04:22',-18000,'2014-02-10 19:04:22',NULL,'[Openstack] [User-committee] Formulate application developer\n oriented questions for the user survey','On Mon, 2014-02-10 at 19:01 +0000, Everett Toews wrote:\n> On Feb 10, 2014, at 12:06 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > Don\'t forget about operating system!\n\n> Right. I considered this but the majority of the tools are already\n> cross-platform (C# and Visual Studio being the obvious exceptions).\n> \n> However, when it comes to testing, it?s so easy to disregard one OS or\n> another because you don?t spend all day in it. I think we should\n> include this to help inform our testing.\n> \n> > What operating system do you use?\n> > \n> > 1. Linux\n> > 2. MacOSX\n> > 3. Windows\n> > 4. Emacs\n\nLOL, I was actually just making a joke at Emacs users\' expense ;)\n\nApparently the joke wasn\'t very good!\n\nBest,\n-jay\n\n\n\n\n','<95EBC92A-1C4B-4051-93CE-8B9C77AA6FEF@rackspace.com>',NULL),('<1392064820.928418725@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-10 14:40:20',-21600,'2014-02-10 20:40:20',NULL,'[OpenStack-Infra] Questions about Nodepool integration','Hi,\n\nIn the Solum project we are looking at various options for running\na pool of worker nodes that will build images (deployment units (DUs) in Solum terms) from user code.\n\nFor code managing aspects, we are in the process of extending Zuul with a \'messaging\' trigger.\nOnce this trigger is received, we will kick off gearman workers to build the DUs -- at least\nthat is the high-level idea.\n\nIn this regards, I have following questions:\n\nI was told that nodepool is the system that manages such worker nodes for Zuul. I briefly looked at\nthe nodepool repository (https://github.com/openstack-infra/nodepool) but did not find\nany information about its integration points with Zuul and/or gearman. Where should I look to find this\ninformation? Is it possible to use a different node management system instead of nodepool with Zuul?\n\nThanks for the help.\n\nRegards,\n- Devdatta\n\n\n\n\n\n','<BB824EA959B82F43820FFEE5E6B00AA621B2F6@AMSPEX01CL01.citrite.net>',NULL),('<1392065783.11435.15.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-10 15:56:23',-18000,'2014-02-10 20:56:23',NULL,'[OpenStack-Infra] Questions about Nodepool integration','On Mon, 2014-02-10 at 14:40 -0600, devdatta kulkarni wrote:\n> Hi,\n> \n> In the Solum project we are looking at various options for running\n> a pool of worker nodes that will build images (deployment units (DUs) in Solum terms) from user code.\n> \n> For code managing aspects, we are in the process of extending Zuul with a \'messaging\' trigger.\n> Once this trigger is received, we will kick off gearman workers to build the DUs -- at least\n> that is the high-level idea.\n> \n> In this regards, I have following questions:\n> \n> I was told that nodepool is the system that manages such worker nodes for Zuul. I briefly looked at\n> the nodepool repository (https://github.com/openstack-infra/nodepool) but did not find\n> any information about its integration points with Zuul and/or gearman. Where should I look to find this\n> information? \n\nYou might want to read an article I wrote about the internals of the\nupstream CI system:\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n\nThere is a section [1] that covers Nodepool:\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/#Assignment_of_a_Node_to_Run_a_Job\n\nYou can see the configuration of Nodepool nodes by the upstream CI\nsystem in the openstack-infra/config project here:\n\nhttps://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/templates/nodepool/nodepool.yaml.erb\n\n> Is it possible to use a different node management system instead of nodepool with Zuul?\n\nProbably would be best to improve Nodepool if you find something lacking\nthere, rather than develop a new node management system...\n\nJust my suggestion.\n\nBest,\n-jay\n\n\n\n','<1392064820.928418725@apps.rackspace.com>',NULL),('<1392090500.22506.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 11:48:20',28800,'2014-02-11 03:48:20',NULL,'[Openstack] problem in creating new account','thanks for reply Jonathan Lu?\n\nI use curl command to create a new account\nthen i check?proxy-server.conf file\nBut it has no announcement for the new account.\n------------\ncurl -i -H \'X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\' -X PUT http://127.0.0.1:8080/v1/AUTH_arunjain\n\nHTTP/1.1 201 Created\nContent-Length: 0\nContent-Type: text/html; charset=UTF-8\nX-Trans-Id: txf807061b920d44d2a8756-0052f87815\nDate: Mon, 10 Feb 2014 06:56:21 GMT\n------------\n\nPragya Jain\n\n\n\nOn Monday, 10 February 2014 3:14 PM, Jonathan Lu <jojokururu at gmail.com> wrote:\n \nHi,\n>??? In TempAuth, the account should be announced in the\n      proxy-server.conf file.\n>??? Maybe you can check your config file whether the new account\n      is announced.\n>\n>Regards,\n>Jonathan Lu\n>\n>On 2014/2/10 15:33, pragya jain wrote:\n>\n>hi all,\n>>\n>>\n>>I am analysing swift functionalities.\n>>I authenticate in swift cluster as a superuser \'prag2648\', get storage-url and auth-token\n>>Then, i create a new account in swift, But I can not access the new account.\n>>\n>>\n>>Below is the steps which I follow:\n>>------------\n>>\n>>root at swift-VirtualBox:~# curl -v -H \'X-Storage-User: prag2648:pragya\' -H \'X-Storage-Pass: pj2648\' http://127.0.0.1:8080/auth/v1.0\n>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>*?? Trying 127.0.0.1... connected\n>>> GET /auth/v1.0 HTTP/1.1\n>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu)\n          libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23\n          librtmp/2.3\n>>> Host: 127.0.0.1:8080\n>>> Accept: */*\n>>> X-Storage-User: prag2648:pragya\n>>> X-Storage-Pass: pj2648\n>>> \n>>< HTTP/1.1 200 OK\n>>< X-Storage-Url: http://127.0.0.1:8080/v1/AUTH_prag2648\n>>< X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n>>< Content-Type: text/html; charset=UTF-8\n>>< X-Storage-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n>>< Content-Length: 0\n>>< X-Trans-Id: tx56a6487da88240e0abd13-0052f8773b\n>>< Date: Mon, 10 Feb 2014 06:52:43 GMT\n>>< \n>>* Connection #0 to host 127.0.0.1 left intact\n>>* Closing connection #0\n>>root at swift-VirtualBox:~# curl -i -H \'X-Auth-Token:\n          AUTH_tkdf211ecfa8924764b1348256885bbaf4\' -X PUT http://127.0.0.1:8080/v1/AUTH_arunjain\n>>HTTP/1.1 201 Created\n>>Content-Length: 0\n>>Content-Type: text/html; charset=UTF-8\n>>X-Trans-Id: txf807061b920d44d2a8756-0052f87815\n>>Date: Mon, 10 Feb 2014 06:56:21 GMT\n>>-----------\n>>\n>>\n>>Please help in this regard.\n>>\n>>\n>>Pragya jain\n>>\n>>\n>>\n>>_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to     : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/08c4c0f1/attachment.html>\n\n','<52F89F8B.30701@gmail.com>',NULL),('<1392091109.92505.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 11:58:29',28800,'2014-02-11 03:58:29',NULL,'[Openstack] horizon for swift','please somebody reply to my question\n\npragya jain\n\n\n\nOn Monday, 10 February 2014 11:48 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi swapnil,\n>\n>\n>thanks for reply.\n>\n>\n>I had installed swift on a VM using the link?http://docs.openstack.org/developer/swift/development_saio.html\n>Is there not something through which I can integrate horizon with existing swift environment?\n>\n>\n>Pragya Jain\n>\n>\n>\n>On Monday, 10 February 2014 11:19 AM, Swapnil Kulkarni <swapnilkulkarni2608 at gmail.com> wrote:\n> \n>Hi Pragya,\n>>\n>>\n>>I use the following devstack localrc configuration in case I need to setup swift for development purpose with single replica. You may want to try, you will get the switft container UI on dashboard with it.\n>>\n>>\n>>ENABLED_SERVICES+=,swift\n>>SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5\n>>SWIFT_REPLICAS=1\n>>SWIFT_DATA_DIR=$DEST/data\n>>\n>>\n>>\n>>Best Regards,\n>>Swapnil Kulkarni\n>>irc : coolsvap\n>>\n>>\n>>\n>>\n>>On Mon, Feb 10, 2014 at 10:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hi krish\n>>>\n>>>\n>>>the link suggested by you is for installing openstack grizlly.\n>>>I had already installed openstack swift on my machine.\n>>>And I wand a user interface to operate swift functionality.\n>>>For that purpose only, I want to integrate horizon with swift.\n>>>Please help in this regard.\n>>>\n>>>\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>>On Saturday, 8 February 2014 7:14 PM, krish <das.srikrishna at gmail.com> wrote:\n>>> \n>>>>?What should I do for the same?\n>>>>\n>>>>Well, as you wrote \"I want to install openstack horizon\"\n>>>>so go ahead and \"install horizon\"\n>>>>\n>>>>http://www.stackgeek.com/guides/gettingstarted.html\n>>>>\n>>>>\n>>>>-- \n>>>>\n>>>>Have a Power-Up Day!\n>>>>--\n>>>>Krish\n>>>>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>>>>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/988cf8a9/attachment.html>\n\n','<1392013135.22954.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1392091174.67098.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 11:59:34',28800,'2014-02-11 03:59:34',NULL,'[Openstack] how to use cloudberry Explorer and cyberduck user\n	interface for swift','please somebody reply to my question\n\npragya jain\n\n\n\nOn Monday, 10 February 2014 1:15 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi all,\n>\n>\n>cloudberry Explorer and cyberduck, both, provide user interface for accessing openstack swift. Both of them are windows or Mac OS compatible, not supported by linux.\n>I installed swift on my windows machine by creating a VM of ubuntu desktop.\n>Now I want to use these products (cloudberry Explorer or cyberduck) for a user interface for swift.\n>I download and install both of them on my host machine (windows based) and i am unable to understand how to use these products to access swift.\n>\n>\n>Please somebody help me in this regard.\n>\n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/0426cc5b/attachment.html>\n\n','<1392018347.53765.YahooMailNeo@web193603.mail.sg3.yahoo.com>',NULL),('<1392095014.67053.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 13:03:34',28800,'2014-02-11 05:03:34',NULL,'[Openstack] horizon for swift','Hello peter\n\nI want to integrate horizon with existing swift environment because\nexisting swift environment is providing CLI interfacefor operating swift.\nI want a Graphical user interface (GUI) for operating swift functionalities\n\n\n\n\n\nOn Tuesday, 11 February 2014 10:16 AM, Peter Portante <peter.a.portante at gmail.com> wrote:\n \nWhat is your goal for trying to integrate horizon with an existing\n>swift environment?\n>\n>On Mon, Feb 10, 2014 at 10:58 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>> please somebody reply to my question\n>>\n>> pragya jain\n>>\n>>\n>> On Monday, 10 February 2014 11:48 AM, pragya jain <prag_2648 at yahoo.co.in>\n>> wrote:\n>>\n>> hi swapnil,\n>>\n>> thanks for reply.\n>>\n>> I had installed swift on a VM using the link\n>> http://docs.openstack.org/developer/swift/development_saio.html\n>> Is there not something through which I can integrate horizon with existing\n>> swift environment?\n>>\n>> Pragya Jain\n>>\n>>\n>> On Monday, 10 February 2014 11:19 AM, Swapnil Kulkarni\n>> <swapnilkulkarni2608 at gmail.com> wrote:\n>>\n>> Hi Pragya,\n>>\n>> I use the following devstack localrc configuration in case I need to setup\n>> swift for development purpose with single replica. You may want to try, you\n>> will get the switft container UI on dashboard with it.\n>>\n>> ENABLED_SERVICES+=,swift\n>> SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5\n>> SWIFT_REPLICAS=1\n>> SWIFT_DATA_DIR=$DEST/data\n>>\n>> Best Regards,\n>> Swapnil Kulkarni\n>> irc : coolsvap\n>>\n>>\n>>\n>> On Mon, Feb 10, 2014 at 10:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>> hi krish\n>>\n>> the link suggested by you is for installing openstack grizlly.\n>> I had already installed openstack swift on my machine.\n>> And I wand a user interface to operate swift functionality.\n>> For that purpose only, I want to integrate horizon with swift.\n>> Please help in this regard.\n>>\n>> Pragya Jain\n>>\n>>\n>> On Saturday, 8 February 2014 7:14 PM, krish <das.srikrishna at gmail.com>\n>> wrote:\n>>\n>>> What should I do for the same?\n>>\n>> Well, as you wrote \"I want to install openstack horizon\"\n>> so go ahead and \"install horizon\"\n>>\n>> http://www.stackgeek.com/guides/gettingstarted.html\n>>\n>> --\n>> Have a Power-Up Day!\n>> --\n>> Krish\n>> I lives in a cave(facebook.com/toonheart) nd writes me games.\n>> Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ?  : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ?  : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/972dc94a/attachment.html>\n\n','<CAPzLFkVvc8L2ph6094a=7MhbpadAMYaw3+QiKD2owCNz5fsksA@mail.gmail.com>',NULL),('<1392095588.93336.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 13:13:08',28800,'2014-02-11 05:13:08',NULL,'[Openstack] problem in downloading the object','hi Kuo,\n\ncurl command are also giving the same result.\n\nBelow are the steps which I follow with output:\n-------------\n1. get account detail\nroot at swift-VirtualBox:~# curl -v -H\n\'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648 \n\n* About to connect() to 127.0.0.1 port\n8080 (#0) \n*   Trying 127.0.0.1... connected \n> GET /v1/AUTH_prag2648 HTTP/1.1 \n> User-Agent: curl/7.22.0\n(i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4\nlibidn/1.23 librtmp/2.3 \n> Host: 127.0.0.1:8080 \n> Accept: */* \n> X-Auth-Token:\nAUTH_tk5525a1165f6f40268df460e09b9ba64b \n> \n< HTTP/1.1 200 OK \n< Content-Length: 9 \n< Accept-Ranges: bytes \n< X-Timestamp: 1387439464.98376 \n< X-Account-Bytes-Used: 0 \n< X-Account-Container-Count: 1 \n< Content-Type: text/plain;\ncharset=utf-8 \n< X-Account-Object-Count: 0 \n< X-Trans-Id:\ntxd554a374c5b540529137d-0052f9a2d5 \n< Date: Tue, 11 Feb 2014 04:11:01\nGMT \n< \nminerals \n* Connection #0 to host 127.0.0.1 left\nintact \n* Closing connection #0 \n2. get container detail\nroot at swift-VirtualBox:~# \ncurl -X GET\n-i -H \'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/minerals \n\nHTTP/1.1 200 OK \nContent-Length: 49 \nX-Container-Object-Count: 1 \nAccept-Ranges: bytes \nX-Timestamp: 1387439465.02723 \nX-Container-Bytes-Used: 22572 \nContent-Type: text/plain;\ncharset=utf-8 \nX-Trans-Id:\ntxb2459f1c5d174f5e9eb30-0052f9a565 \nDate: Tue, 11 Feb 2014 04:21:57 GMT \nhome/swift/Desktop/swift_installation_steps.docx \n3. retrieve object\nroot at swift-VirtualBox:~# curl -X GET -i\n-H \'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/minerals/home/swift/Desktop/swift_installation_steps.docx \n\nHTTP/1.1 404 Not Found \nContent-Length: 70 \nContent-Type: text/html; charset=UTF-8 \nX-Trans-Id:\ntxe1abfb8ec917421488fa3-0052f9a5a3 \nDate: Tue, 11 Feb 2014 04:22:59 GMT \n<html><h1>Not\nFound</h1><p>The resource could not be\nfound.</p></html>root at swift-VirtualBox:~# \n------------\n\naccount detail shows object count = 0\ncontainer detail shows object count = 1\nretrieve object shows \'resource could not be\nfound\'\n\nI can\'t analyse where is the actual problem.\n\nPragya jain\n\n\n\n\n\n\nOn Monday, 10 February 2014 2:57 PM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n \nIt\'s woking on my box.?\n>Perhaps you can give a try with curl command.?\n>\n>\n>\n>2014-02-10 15:25 GMT+08:00 pragya jain <prag_2648 at yahoo.co.in>:\n>\n>hi all,\n>>\n>>\n>>i create an account in swift.\n>>status of account shows that there is a container and zero objects in the account.\n>>when I list the container, it shows an object in it.\n>>But whenI am downloading the object, it shows object not found.\n>>\n>>\n>>Below are the steps which I follow:\n>>----------\n>>\n>>root at swift-VirtualBox:~# export ST_AUTH=http://127.0.0.1:8080/auth/v1.0\n>>root at swift-VirtualBox:~# export ST_USER=prag2648:pragya\n>>root at swift-VirtualBox:~# export ST_KEY=pj2648\n>>root at swift-VirtualBox:~# swift stat\n>>?????? Account: AUTH_prag2648\n>>??? Containers: 1\n>>?????? Objects: 0\n>>???????? Bytes: 0\n>>?Accept-Ranges: bytes\n>>?? X-Timestamp: 1387439464.98256\n>>??? X-Trans-Id: tx07ace110079247cfa7e27-0052f8762d\n>>? Content-Type: text/plain; charset=utf-8\n>>root at swift-VirtualBox:~# swift list\n>>minerals\n>>root at swift-VirtualBox:~# swift list minerals\n>>home/swift/Desktop/swift_installation_steps.docx\n>>root at swift-VirtualBox:~# swift download minerals home/swift/Desktop/swift_installation_steps.docx\n>>Object\n \'minerals/home/swift/Desktop/swift_installation_steps.docx\' not found\n>>-----------\n>>\n>>\n>>Please help me in finding where is the problem.\n>>\n>>\n>>Thanks \n>>\n>>Pragya Jain\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/6cb7ae63/attachment.html>\n\n','<CA++_uhubxiBXV_iQ1zfnceRv0vH=PRQh7sYfp-uJdrHWeEMdSg@mail.gmail.com>',NULL),('<1392096075-sup-237@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-10 21:22:54',-28800,'2014-02-11 05:22:54',NULL,'[openstack-dev] [Heat] in-instance update hooks','Hi, so in the previous thread about rolling updates it became clear that\nhaving in-instance control over updates is a more fundamental idea than\nI had previously believed. During an update, Heat does things to servers\nthat may interrupt the server\'s purpose, and that may cause it to fail\nsubsequent things in the graph.\n\nSpecifically, in TripleO we have compute nodes that we are managing.\nBefore rebooting a machine, we want to have a chance to live-migrate\nworkloads if possible, or evacuate in the simpler case, before the node\nis rebooted. Also in the case of a Galera DB where we may even be running\ndegraded, we want to ensure that we have quorum before proceeding.\n\nI\'ve filed a blueprint for this functionality:\n\nhttps://blueprints.launchpad.net/heat/+spec/update-hooks\n\nI\'ve cobbled together a spec here, and I would very much welcome\nedits/comments/etc:\n\nhttps://etherpad.openstack.org/p/heat-update-hooks\n\n\n',NULL,NULL),('<1392099472.84931.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 14:17:52',28800,'2014-02-11 06:17:52',NULL,'[Openstack] horizon for swift','hello Adam,\n\nI can\'t understand the means of \'can install the integral front-end\'.\n\nI had seen swiftstack. It provides a very good interface and call it software defined storage.\nBut I want some interface other than swiftstack\n\nPragya Jain\n\n\n\nOn Tuesday, 11 February 2014 10:54 AM, Adam Lawson <alawson at aqorn.com> wrote:\n \nPerhaps you can look into proprietary solutions such as are available from outfits like SwiftStack which (I believe) come with a GUI.\n>\n>\n>A GUI for Swift would be interesting, especially for health checks, setting up and administering regions visually, weighted zones and high-level replication strategies but if you integrate Horizon, I think that becomes your only point of entry which isn\'t good. Perhaps you can install the integral front-end and do some kung-fu with Apache2.\n>\n>\n>\n>Adam Lawson\n>AQORN, Inc.\n>427 North Tatnall Street\n>Ste. 58461\n>Wilmington, Delaware 19801-2230\n>Toll-free: (888) 406-7620\n>\n>\n>\n>\n>On Mon, Feb 10, 2014 at 9:03 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>Hello peter\n>>\n>>I want to integrate horizon with existing swift environment because\n>>existing swift environment is providing CLI interfacefor operating swift.\n>>I want a Graphical user interface (GUI) for operating swift functionalities\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>On Tuesday, 11 February 2014 10:16 AM, Peter Portante <peter.a.portante at gmail.com> wrote:\n>> \n>>What is your goal for trying to integrate horizon with an existing\n>>>swift environment?\n>>>\n>>>On Mon, Feb 10, 2014 at 10:58 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>> please somebody reply to my question\n>>>>\n>>>> pragya jain\n>>>>\n>>>>\n>>>> On Monday, 10 February 2014 11:48 AM, pragya jain <prag_2648 at yahoo.co.in>\n>>>> wrote:\n>>>>\n>>>> hi swapnil,\n>>>>\n>>>> thanks for reply.\n>>>>\n>>>> I had installed swift on a VM using the link\n>>>> http://docs.openstack.org/developer/swift/development_saio.html\n>>>> Is there not something through which I can integrate horizon with existing\n>>>> swift environment?\n>>>>\n>>>> Pragya Jain\n>>>>\n>>>>\n>>>> On Monday, 10 February 2014 11:19 AM, Swapnil Kulkarni\n>>>> <swapnilkulkarni2608 at gmail.com> wrote:\n>>>>\n>>>> Hi Pragya,\n>>>>\n>>>> I use the following devstack localrc configuration in case I need to setup\n>>>> swift for development purpose with single replica. You may want to try, you\n>>>> will get the switft\n container UI on dashboard with it.\n>>>>\n>>>> ENABLED_SERVICES+=,swift\n>>>> SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5\n>>>> SWIFT_REPLICAS=1\n>>>> SWIFT_DATA_DIR=$DEST/data\n>>>>\n>>>> Best Regards,\n>>>> Swapnil Kulkarni\n>>>> irc : coolsvap\n>>>>\n>>>>\n>>>>\n>>>> On Mon, Feb 10, 2014 at 10:58 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>> hi krish\n>>>>\n>>>> the link suggested by you is for installing openstack grizlly.\n>>>> I had already installed openstack swift on my machine.\n>>>> And I wand a user interface to operate swift functionality.\n>>>> For that purpose only, I want to integrate horizon with swift.\n>>>> Please help in this regard.\n>>>>\n>>>> Pragya Jain\n>>>>\n>>>>\n>>>> On Saturday, 8 February 2014 7:14 PM, krish <das.srikrishna at gmail.com>\n>>>> wrote:\n>>>>\n>>>>> What should I do for the same?\n>>>>\n>>>> Well, as you wrote \"I want to install openstack horizon\"\n>>>> so go ahead and \"install horizon\"\n>>>>\n>>>> http://www.stackgeek.com/guides/gettingstarted.html\n>>>>\n>>>> --\n>>>> Have a Power-Up Day!\n>>>> --\n>>>> Krish\n>>>> I lives in a cave(facebook.com/toonheart) nd writes me games.\n>>>> Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>> _______________________________________________\n>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to? ?  : openstack at lists.openstack.org\n>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>> _______________________________________________\n>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to? ?  : openstack at lists.openstack.org\n>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/a2c44f82/attachment.html>\n\n','<CAJfWK4_yVPM=HT1iGJ7ptNKBjTeEy4H-domxM-EgLnvOJ_Vhkg@mail.gmail.com>',NULL),('<1392111904.3069.4.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 10:45:04',3600,'2014-02-11 09:45:04',NULL,'[openstack-dev] [Openstack-dev][All] tox 1.7.0 error while\n running tests','Hi. This seems to be related:\nhttps://bugs.launchpad.net/openstack-ci/+bug/1274135\nWe also encountered this.\n\nOn Tue, 2014-02-11 at 14:56 +0530, Swapnil Kulkarni wrote:\n> Hello,\n> \n> \n> I created a new devstack environment today and installed tox 1.7.0,\n> and getting error \"tox.ConfigError: ConfigError: substitution key\n> \'posargs\' not found\".\n> \n> \n> Details in [1].\n> \n> \n> Anybody encountered similar error before? Any workarounds/updates\n> needed?\n> \n> \n> [1] http://paste.openstack.org/show/64178/\n> \n> \n> \n> \n> Best Regards,\n> Swapnil Kulkarni\n> irc : coolsvap\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAN_H9NhQF+am0gJLTKnGhBhe39PxKeVoaDF0aXL93iuCX+sXjA@mail.gmail.com>',NULL),('<1392113720-sup-1036@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 02:38:17',-28800,'2014-02-11 10:38:17',NULL,'[openstack-dev] [Heat] in-instance update hooks','Excerpts from Thomas Spatzier\'s message of 2014-02-11 00:38:53 -0800:\n> Hi Clint,\n> \n> thanks for writing this down. This is a really interesting use case and\n> feature, also in relation to what was recently discussed on rolling\n> updates.\n> \n> I have a couple of thoughts and questions:\n> \n> 1) The overall idea seems clear to me but I have problems understanding the\n> detailed flow and relation to template definitions and metadata. E.g. in\n> addition to the examples you gave in the linked etherpad, where would the\n> script or whatever sit that handles the update etc.\n> \n\nAt the risk of sounding curt and unfeeling: I really don\'t care how your\nservers do their job or talk to heat.. as long as they use the API. :)\n\nHeat is an orchestration tool, and putting script code or explicit tool\ncallouts in templates is obscene to me. I understand other people are\nstuck with vanilla images, but I am not, so I have very little time to\nspend thinking about how that is done.\n\nIn TripleO, os-collect-config periodically polls the metadata and runs\nos-refresh-config when it changes. os-refresh-config just runs a bunch\nof scripts. The scripts use os-apply-config to interpret the metadata\nsection, either through mustache templates or like this:\n\nACTION=$(os-apply-config --key action.pending --key-default \'\' --type raw)\ncase $ACTION in\nrebuild)\ndelete)\n  migrate_to_something_else\n  ping_the_handle $(os-apply_config --key action.handle --type url)\n  ;;\n*)\n  ;;\nesac\n  \nWe just bake all of this into our images.\n\n> 2) I am not a big fan of CFN WaitConditions since they let too much\n> programming shine thru in a template. So I wonder whether this could be\n> made more transparent to the template writer. The underlying mechanism\n> could still be the same, but maybe we could make the template look cleaner.\n> For example, what Steve Baker is doing for software orchestration also uses\n> the underlying mechanisms but does not expose WaitConditions in templates.\n>\n\nYeah we could allocate the handle transparently without much difficulty.\nHowever, to be debuggable we\'d have to make it available as an attribute\nof the server if we don\'t have a resource directly queryable for it. Not\nsure if Steve has done that but it is pretty important to be able to\ncompare the handle URL you see in the stack to the one you see on the\nserver.\n\n> 3) Has the issue of how to express update policies on the rolling updates\n> thread been resolved? I followed that thread but seems like there has not\n> been a final decision. The reason I am bringing this up is because I think\n> this is related. You are suggesting to establish a new top-level section\n> \'action_hooks\' in a resource. Rendering this top-level in the resource is a\n> good thing IMO. However, since this is related to updates in a way (you\n> want to react to any kind of update event to the resource\'s state), I\n> wonder if those hooks could be attributes of an update policy. UpdatePolicy\n> in CFN is also a top-level section in a resource and they seem to provide a\n> default one like the following (I am writing this in snake case as we would\n> render it in HOT:\n> \n> resources:\n>   autoscaling_group1:\n>     type: AWS::AutoScaling::AutoScalingGroup\n>     properties:\n>       # the properties ...\n>     update_policy:\n>       auto_scaling_rolling_update:\n>         min_instances_in_server: 1\n>         max_batch_size: 1\n>         pause_time: PT12M5S\n> \n> (I took this from the CFN user guide).\n> I.e. an update policy already is a complex data structure, and we could\n> define additional types that include the resource hooks definitions you\n> need. ... I don\'t fully understand the connection between \'actions\' and\n> \'path\' in your etherpad example yet, so cannot define a concrete example,\n> but I hope you get what I wanted to express.\n> \n\nThis also works on stack-delete. Perhaps delete is just a special update\nthat replaces the template with \'\', but update_policy seems a bit off\nbase given this. The two features (rolling-updates and update-hooks)\nseem related, but I think only because they\'d both be more useful with\nthe other available.\n\n> 4) What kind of additional metadata for the update events are you thinking\n> about? For example, in case this is done in an update case with a batch\n> size of > 1 (i.e. you update multiple members in a cluster at a time) -\n> unless I put too much interpretation in here concerning the relation to\n> rolling updates - you would probably want to tell the server a black list\n> of servers to which it should not migrate workload, because they will be\n> taken down as well.\n> \n\nAgreed, for rolling updates we\'d need some additional clues. For just\ndoing explicit servers, we can think a little more statically and just\ndo a bit shift of the workloads (first server sends to last.. second to\nfirst.. etc).\n\n> \n> As I said, just a couple of thoughts, and maybe for some I am just\n> mis-understanding some details.\n> Anyway, I would be interested in your view.\n> \n\nYour thoughts are most appreciated!\n\n\n','<OFE651D237.97C9BBB3-ONC1257C7C.002D72BE-C1257C7C.002F8183@de.ibm.com>',NULL),('<1392114611.8525.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 18:30:11',28800,'2014-02-11 10:30:11',NULL,'[Openstack] problem in installing django-swiftbrowser','hello all,\n\nI am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n\nbelow are the steps which i follow:\n-----------------\n1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n\n\nCloning into \'django-swiftbrowser\'...\nremote: Reusing existing pack: 145, done.\nremote: Total 145 (delta 0), reused 0 (delta 0)\nReceiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\nResolving deltas: 100% (72/72), done.\n\n2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n\n\n3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\nTraceback (most recent call last):\n? File \"setup.py\", line 2, in <module>\n??? from setuptools import setup\nImportError: No module named setuptools\n------------\n\nBut I get the error.\nPlease help inresolving the error.\n\nThanks in advance \n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/f994c550/attachment.html>\n\n',NULL,NULL),('<1392117498.67210.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 19:18:18',28800,'2014-02-11 11:18:18',NULL,'[Openstack] how to use cloudberry Explorer and cyberduck user\n	interface for swift','?hi kuo,\n\nI use the link mentioned by you for connecting cyberduck interface with my existing swift environment.\n\nI follow the following steps:\nin my existing swift environment, I make some changes:\nRun the following commands as a root:\n1.?apt-get install ?y openssh-server\n2.?cd /etc/swift\n3.?openssl req -new -x509 -nodes -out cert.crt -keyout cert.key\n4. edit proxy-server.conf and add in [Default]\ncert_file= /etc/swift/cert.crt\n\nkey_file= /etc/swift/cert.key\n5.?defaults write ch.sudo.cyberduck cf.authentication.context/auth/v1.0\nand then restart all servers in swift\n\n6. run cyberduck interface\nadd values as shown in screenshot attached.\nbut it shows connection fails\n\nplease help me in identifying where is the problem\n\nPragya jain\n\n\n\nOn Tuesday, 11 February 2014 9:52 AM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n \nHope it help :?http://docs.openstack.org/grizzly/openstack-object-storage/admin/content/part-ii-configuring-cyberduck.html\n>\n>\n>\n>2014-02-11 11:59 GMT+08:00 pragya jain <prag_2648 at yahoo.co.in>:\n>\n>please somebody reply to my question\n>>\n>>\n>>pragya jain\n>>\n>>\n>>\n>>On Monday, 10 February 2014 1:15 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>> \n>>hi all,\n>>>\n>>>\n>>>cloudberry Explorer and cyberduck, both, provide user interface for accessing openstack swift. Both of them are windows or Mac OS compatible, not supported by linux.\n>>>I installed swift on my windows machine by creating a VM of ubuntu desktop.\n>>>Now I want to use these products (cloudberry Explorer or cyberduck) for a user interface for swift.\n>>>I download and install both of them on my host machine (windows based) and i am unable to understand how to use these products to access swift.\n>>>\n>>>\n>>>Please somebody help me in this regard.\n>>>\n>>>\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/0709ae65/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: cyberduck screenshot.pptx\nType: application/vnd.openxmlformats-officedocument.presentationml.presentation\nSize: 139684 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/0709ae65/attachment-0001.pptx>\n\n','<CA++_uhuQo3NYNj3Wgo3ULohru1H3wnRn59FU=D9J-W7Gx=Rgyw@mail.gmail.com>',NULL),('<1392117586.5149.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 19:19:46',28800,'2014-02-11 11:19:46',NULL,'[Openstack] problem in downloading the object','please somebody reply\n\n\n\nOn Tuesday, 11 February 2014 10:43 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi Kuo,\n>\n>curl command are also giving the same result.\n>\n>Below are the steps which I follow with output:\n>-------------\n>1. get account detail\n>root at swift-VirtualBox:~# curl -v -H\n\'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648 \n>\n>\n>* About to connect() to 127.0.0.1 port\n8080 (#0) \n>*   Trying 127.0.0.1... connected \n>> GET /v1/AUTH_prag2648 HTTP/1.1 \n>> User-Agent: curl/7.22.0\n(i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4\nlibidn/1.23 librtmp/2.3 \n>> Host: 127.0.0.1:8080 \n>> Accept: */* \n>> X-Auth-Token:\nAUTH_tk5525a1165f6f40268df460e09b9ba64b \n>> \n>< HTTP/1.1 200 OK \n>< Content-Length: 9 \n>< Accept-Ranges: bytes \n>< X-Timestamp: 1387439464.98376 \n>< X-Account-Bytes-Used: 0 \n>< X-Account-Container-Count: 1 \n>< Content-Type: text/plain;\ncharset=utf-8 \n>< X-Account-Object-Count: 0 \n>< X-Trans-Id:\ntxd554a374c5b540529137d-0052f9a2d5 \n>< Date: Tue, 11 Feb 2014 04:11:01\nGMT \n>< \n>minerals \n>* Connection #0 to host 127.0.0.1 left\nintact \n>* Closing connection #0 \n>2. get container detail\n>root at swift-VirtualBox:~# \ncurl -X GET\n-i -H \'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/minerals \n>\n>\n>HTTP/1.1 200 OK \n>Content-Length: 49 \n>X-Container-Object-Count: 1 \n>Accept-Ranges: bytes \n>X-Timestamp: 1387439465.02723 \n>X-Container-Bytes-Used: 22572 \n>Content-Type: text/plain;\ncharset=utf-8 \n>X-Trans-Id:\ntxb2459f1c5d174f5e9eb30-0052f9a565 \n>Date: Tue, 11 Feb 2014 04:21:57 GMT \n>home/swift/Desktop/swift_installation_steps.docx \n>3. retrieve object\n>root at swift-VirtualBox:~# curl -X GET -i\n-H \'X-Auth-Token: AUTH_tk5525a1165f6f40268df460e09b9ba64b\'\nhttp://127.0.0.1:8080/v1/AUTH_prag2648/minerals/home/swift/Desktop/swift_installation_steps.docx \n>\n>\n>HTTP/1.1 404 Not Found \n>Content-Length: 70 \n>Content-Type: text/html; charset=UTF-8 \n>X-Trans-Id:\ntxe1abfb8ec917421488fa3-0052f9a5a3 \n>Date: Tue, 11 Feb 2014 04:22:59 GMT \n><html><h1>Not\nFound</h1><p>The resource could not be\nfound.</p></html>root at swift-VirtualBox:~# \n>------------\n>\n>account detail shows object count = 0\n>container detail shows object count = 1\n>retrieve object shows \'resource could not be\nfound\'\n>\n>\n>I can\'t analyse where is the actual problem.\n>\n>\n>Pragya jain\n>\n>\n>\n>\n>\n>\n>\n>On Monday, 10 February 2014 2:57 PM, Kuo Hugo <tonytkdk at gmail.com> wrote:\n> \n>It\'s woking on my box.?\n>>Perhaps you can give a try with curl command.?\n>>\n>>\n>>\n>>2014-02-10 15:25 GMT+08:00 pragya jain <prag_2648 at yahoo.co.in>:\n>>\n>>hi all,\n>>>\n>>>\n>>>i create an account in swift.\n>>>status of account shows that there is a container and zero objects in the account.\n>>>when I list the container, it shows an object in it.\n>>>But whenI am downloading the object, it shows object not found.\n>>>\n>>>\n>>>Below are the steps which I follow:\n>>>----------\n>>>\n>>>root at swift-VirtualBox:~# export ST_AUTH=http://127.0.0.1:8080/auth/v1.0\n>>>root at swift-VirtualBox:~# export ST_USER=prag2648:pragya\n>>>root at swift-VirtualBox:~# export ST_KEY=pj2648\n>>>root at swift-VirtualBox:~# swift stat\n>>>?????? Account: AUTH_prag2648\n>>>??? Containers: 1\n>>>?????? Objects: 0\n>>>???????? Bytes: 0\n>>>?Accept-Ranges: bytes\n>>>?? X-Timestamp: 1387439464.98256\n>>>??? X-Trans-Id: tx07ace110079247cfa7e27-0052f8762d\n>>>? Content-Type: text/plain; charset=utf-8\n>>>root at swift-VirtualBox:~# swift list\n>>>minerals\n>>>root at swift-VirtualBox:~# swift list minerals\n>>>home/swift/Desktop/swift_installation_steps.docx\n>>>root at swift-VirtualBox:~# swift download minerals home/swift/Desktop/swift_installation_steps.docx\n>>>Object\n \'minerals/home/swift/Desktop/swift_installation_steps.docx\' not found\n>>>-----------\n>>>\n>>>\n>>>Please help me in finding where is the problem.\n>>>\n>>>\n>>>Thanks \n>>>\n>>>Pragya Jain\n>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to ? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/8b17523a/attachment.html>\n\n','<1392095588.93336.YahooMailNeo@web193605.mail.sg3.yahoo.com>',NULL),('<1392117629.2935.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 19:20:29',28800,'2014-02-11 11:20:29',NULL,'[Openstack] problem in creating new account','please somebody reply\n\n\n\nOn Tuesday, 11 February 2014 9:18 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nthanks for reply Jonathan Lu?\n>\n>\n>I use curl command to create a new account\n>then i check?proxy-server.conf file\n>But it has no announcement for the new account.\n>------------\n>curl -i -H \'X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\' -X PUT http://127.0.0.1:8080/v1/AUTH_arunjain\n>\n>HTTP/1.1 201 Created\n>Content-Length: 0\n>Content-Type: text/html; charset=UTF-8\n>X-Trans-Id: txf807061b920d44d2a8756-0052f87815\n>Date: Mon, 10 Feb 2014 06:56:21 GMT\n>------------\n>\n>\n>Pragya Jain\n>\n>\n>\n>On Monday, 10 February 2014 3:14 PM, Jonathan Lu <jojokururu at gmail.com> wrote:\n> \n>Hi,\n>>??? In TempAuth, the account should be announced in the\n      proxy-server.conf file.\n>>??? Maybe you can check your config file whether the new account\n      is announced.\n>>\n>>Regards,\n>>Jonathan Lu\n>>\n>>On 2014/2/10 15:33, pragya jain wrote:\n>>\n>>hi all,\n>>>\n>>>\n>>>I am analysing swift functionalities.\n>>>I authenticate in swift cluster as a superuser \'prag2648\', get storage-url and auth-token\n>>>Then, i create a new account in swift, But I can not access the new account.\n>>>\n>>>\n>>>Below is the steps which I follow:\n>>>------------\n>>>\n>>>root at swift-VirtualBox:~# curl -v -H \'X-Storage-User: prag2648:pragya\' -H \'X-Storage-Pass: pj2648\' http://127.0.0.1:8080/auth/v1.0\n>>>* About to connect() to 127.0.0.1 port 8080 (#0)\n>>>*?? Trying 127.0.0.1... connected\n>>>> GET /auth/v1.0 HTTP/1.1\n>>>> User-Agent: curl/7.22.0 (i686-pc-linux-gnu)\n          libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23\n          librtmp/2.3\n>>>> Host: 127.0.0.1:8080\n>>>> Accept: */*\n>>>> X-Storage-User: prag2648:pragya\n>>>> X-Storage-Pass: pj2648\n>>>> \n>>>< HTTP/1.1 200 OK\n>>>< X-Storage-Url: http://127.0.0.1:8080/v1/AUTH_prag2648\n>>>< X-Auth-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n>>>< Content-Type: text/html; charset=UTF-8\n>>>< X-Storage-Token: AUTH_tkdf211ecfa8924764b1348256885bbaf4\n>>>< Content-Length: 0\n>>>< X-Trans-Id: tx56a6487da88240e0abd13-0052f8773b\n>>>< Date: Mon, 10 Feb 2014 06:52:43 GMT\n>>>< \n>>>* Connection #0 to host 127.0.0.1 left intact\n>>>* Closing connection #0\n>>>root at swift-VirtualBox:~# curl -i -H \'X-Auth-Token:\n          AUTH_tkdf211ecfa8924764b1348256885bbaf4\' -X PUT http://127.0.0.1:8080/v1/AUTH_arunjain\n>>>HTTP/1.1 201 Created\n>>>Content-Length: 0\n>>>Content-Type: text/html; charset=UTF-8\n>>>X-Trans-Id: txf807061b920d44d2a8756-0052f87815\n>>>Date: Mon, 10 Feb 2014 06:56:21 GMT\n>>>-----------\n>>>\n>>>\n>>>Please help in this regard.\n>>>\n>>>\n>>>Pragya jain\n>>>\n>>>\n>>>\n>>>_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to     : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140211/d362dd6a/attachment.html>\n\n','<1392090500.22506.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1392135002-sup-5914@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 08:13:41',-28800,'2014-02-11 16:13:41',NULL,'[openstack-dev] [Heat] in-instance update hooks','Excerpts from Steven Dake\'s message of 2014-02-11 07:19:19 -0800:\n> On 02/10/2014 10:22 PM, Clint Byrum wrote:\n> > Hi, so in the previous thread about rolling updates it became clear that\n> > having in-instance control over updates is a more fundamental idea than\n> > I had previously believed. During an update, Heat does things to servers\n> > that may interrupt the server\'s purpose, and that may cause it to fail\n> > subsequent things in the graph.\n> >\n> > Specifically, in TripleO we have compute nodes that we are managing.\n> > Before rebooting a machine, we want to have a chance to live-migrate\n> > workloads if possible, or evacuate in the simpler case, before the node\n> > is rebooted. Also in the case of a Galera DB where we may even be running\n> > degraded, we want to ensure that we have quorum before proceeding.\n> >\n> > I\'ve filed a blueprint for this functionality:\n> >\n> > https://blueprints.launchpad.net/heat/+spec/update-hooks\n> >\n> > I\'ve cobbled together a spec here, and I would very much welcome\n> > edits/comments/etc:\n> >\n> > https://etherpad.openstack.org/p/heat-update-hooks\n> Clint,\n> \n> I read through your etherpad and think there is a relationship to a use \n> case for scaling.  It would be sweet if both these cases could use the \n> same model and tooling.  At the moment in an autoscaling group, when you \n> want to scale \"down\" there is no way to quiesce the node before killing \n> the VM.  It is the same problem you have with Galera, except your \n> scenario involves an update.\n> \n> I\'m not clear how the proposed design could be made to fit this \n> particular use case.  Do you see a way it can fill both roles so we \n> don\'t have two different ways to do essentially the same thing?\n> \n\nI see scaling down as an update to a nested stack which contains all of\nthe members of the scaling group.\n\nSo if we start focusing on scaling stacks, as Zane suggested in\nthe rolling updates thread, then the author of said stack would add\naction_hooks to the resources that are scaled.\n\n\n','<52FA3F77.8090007@redhat.com>',NULL),('<1392136737.65691397@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 11:38:57',-18000,'2014-02-11 16:38:57',NULL,'[openstack-dev] [Nova][Glance]supporting of v1 and v2 glance\n	APIs in Nova','> A few days ago, I met some problems when using \'createimage\' feature in\n> Nova, we found that using V1 of glanceclient has some problem with\n> processing of metadata, the version number and even the glance URIs are\n> both hardcoded in Nova.\n> \n> then, we found the bluepring[1] proposed, and the maillist[2] which talked\n> about the topic before, mainly focused on version autodiscovery by keystone\n> catalog and config option for nova. But we still need changes in Nova\n> because the incompatible behavior between v1 and v2, especially when\n> creating and uploading an image file. The review request[3] of the bp is\n> abandoned for now.\n> \n> So, what I want to confirm is, how could this situation be handled? I\n> mailed Eddie Sheffield, but got no answer, so bring it up here.\n> \n> [1]: https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api\n> [2]: http://markmail.org/message/uqrpufsmh4qp5pgy\n> [4]: https://review.openstack.org/#/c/38414/\n\nHi Lingxian,\n\nI\'m afraid I somehow didn\'t see the email you sent to me directly. We recently held the Glance Mini-summit and this work was discussed. Andrew Laski from the Nova team was also in attendance and provided some input from their perspective. Essentially we decided that while autodiscovery is desirable, we want to roll that functionality into a much-improved python-glanceclient which will present a version-agnostic programming api to users of the library. So the immediate plan is to go back to the approach outlined in the bp and merge prop you reference above. Then in the near future produce the new glanceclient followed by updating Nova to use the new library which will address the concerns of autodiscovery among other things.\n\nTimeline-wise, I\'ve been a bit covered up with some other work but will be getting back to this within a week. There were some concerns about the size of the patch so rather than unabandoning the existing one I will be trying to put up multiple, smaller patches.\n\nPlease let me know if you have any specific concerns or requirements so they can be addressed.\n\nEddie Sheffield\nRackspace Hosting, Inc.\neddie.sheffield at rackspace.com\n\n\n\n','<CALjNAZ2ynSBREGZzgBX2AXK+0-GxpLDpvWa489qhALqWRwF_Yw@mail.gmail.com>',NULL),('<1392139022-sup-1009@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 09:26:29',-28800,'2014-02-11 17:26:29',NULL,'[openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack','Excerpts from Andrey Danin\'s message of 2014-02-11 08:42:46 -0800:\n> Hi Openstackers,\n> \n> We are working on link aggregation support in Fuel. We wonder what are the\n> most desirable types of bonding now in datacenters. We had some issues (see\n> below) with OVS bond in LACP mode, and it turned out that standard Linux\n> bonding (attached to OVS bridges) was a better option in our setup.\n> \n> I want to hear your opinion, guys. What types of bonding do you think are\n> better now in terms of stability and performance, so that we can properly\n> support them for OpenStack installations.\n> \n> Also, we are wondering if there any plans to support bonding in TripleO,\n> and how you guys would like to see it be implemented? What is the general\n> approach for such complex network configurations for TripleO? We would love\n> to extract this piece from Fuel and make it fully independent, so that the\n> larger community can use it and we could work collaboratively on it. Right\n> now it is actually already granular and can be reused in other projects,\n> and implemented as a separated puppet module:\n> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network\n\nFor Nova baremetal and Ironic, they\'re going to feed MACs to Neutron which\nit would then serve DHCP for. I am not sure how that relates to bonding,\nand if the MAC would change for DHCP requests after bonding is configured,\nbut that would have to be addressed and tested.\n\nOtherwise, it would work largely the same way I think. Just configure the\nimage to read config parameters from the Heat metadata and subsequently\nconfigure bonding. It is even possible that the facter cfn plugin could\nbe made to work with a little bit of modification, perhaps allowing you\nto forklift the puppet modules into a diskimage-builder element:\n\nhttps://github.com/oppian/oppian-puppet-modules/blob/master/modules/cfn/lib/facter/cfn.rb\n\nI\'ve heard of no plans for supporting this configuration of servers,\nbut I see no reason it couldn\'t be added as an option if it was important\nto deployers.\n\n\n','<CA+vYeFpyV=9zFND-jD-uhg8+4RjwRJYqRKm--kP3tCfA-GhP4g@mail.gmail.com>',NULL),('<1392139894.11435.29.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-11 12:31:34',-18000,'2014-02-11 17:31:34',NULL,'[Openstack-operators] [Fwd: [openstack-dev] [Fuel][TripleO] NIC\n	bonding for OpenStack]','Forwarding to the operators list, since this topic is relevant here.\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Andrey Danin <adanin at mirantis.com>\nSubject: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack\nDate: Tue, 11 Feb 2014 20:42:46 +0400\nSize: 13310\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140211/ff2d17cc/attachment.mht>\n\n',NULL,NULL),('<1392141003-sup-2426@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 09:57:16',-28800,'2014-02-11 17:57:16',NULL,'[openstack-dev] [Heat] in-instance update hooks','Thanks Kevin, great summary.\n\nThis is beyond the scope of in-instance notification. I think this is\nmore like the generic notification API that Thomas Herve suggested in\nthe rolling updates thread. It can definitely use the same method for\nits implementation, and I think it is adjacent to, and not in front of\nor behind, the in-instance case.\n\nExcerpts from Fox, Kevin M\'s message of 2014-02-11 09:22:28 -0800:\n> Another scaling down/update use case:\n> Say I have a pool of ssh servers for users to use (compute cluster login nodes).\n> Autoscaling up is easy. Just launch a new node and add it to the load balancer.\n> \n> Scaling down/updating is harder. It should ideally:\n>  * Set the admin state on the load balancer for the node, ensuring no new connections go to the node.\n>  * Contact the node or the balancer and ensure all outstanding connections are complete. Wait for it. This could be a long long time.\n>  * Destroy or update the node\n> \n> Thanks,\n> Kevin\n> ________________________________________\n> From: Clint Byrum [clint at fewbar.com]\n> Sent: Tuesday, February 11, 2014 8:13 AM\n> To: openstack-dev\n> Subject: Re: [openstack-dev] [Heat] in-instance update hooks\n> \n> Excerpts from Steven Dake\'s message of 2014-02-11 07:19:19 -0800:\n> > On 02/10/2014 10:22 PM, Clint Byrum wrote:\n> > > Hi, so in the previous thread about rolling updates it became clear that\n> > > having in-instance control over updates is a more fundamental idea than\n> > > I had previously believed. During an update, Heat does things to servers\n> > > that may interrupt the server\'s purpose, and that may cause it to fail\n> > > subsequent things in the graph.\n> > >\n> > > Specifically, in TripleO we have compute nodes that we are managing.\n> > > Before rebooting a machine, we want to have a chance to live-migrate\n> > > workloads if possible, or evacuate in the simpler case, before the node\n> > > is rebooted. Also in the case of a Galera DB where we may even be running\n> > > degraded, we want to ensure that we have quorum before proceeding.\n> > >\n> > > I\'ve filed a blueprint for this functionality:\n> > >\n> > > https://blueprints.launchpad.net/heat/+spec/update-hooks\n> > >\n> > > I\'ve cobbled together a spec here, and I would very much welcome\n> > > edits/comments/etc:\n> > >\n> > > https://etherpad.openstack.org/p/heat-update-hooks\n> > Clint,\n> >\n> > I read through your etherpad and think there is a relationship to a use\n> > case for scaling.  It would be sweet if both these cases could use the\n> > same model and tooling.  At the moment in an autoscaling group, when you\n> > want to scale \"down\" there is no way to quiesce the node before killing\n> > the VM.  It is the same problem you have with Galera, except your\n> > scenario involves an update.\n> >\n> > I\'m not clear how the proposed design could be made to fit this\n> > particular use case.  Do you see a way it can fill both roles so we\n> > don\'t have two different ways to do essentially the same thing?\n> >\n> \n> I see scaling down as an update to a nested stack which contains all of\n> the members of the scaling group.\n> \n> So if we start focusing on scaling stacks, as Zane suggested in\n> the rolling updates thread, then the author of said stack would add\n> action_hooks to the resources that are scaled.\n> \n\n\n','<1A3C52DFCD06494D8528644858247BF00E4ACB@EX10MBOX03.pnnl.gov>',NULL),('<1392149489.767.93.camel@tykes-place.bardicgrove.org>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-11 12:11:29',-28800,'2014-02-11 20:11:29',NULL,'[OpenStack-Infra] Dedicated user for OpenDaylight integration','Greetings,\n\nI\'m the admin in charge of the OpenDaylight infrastructure and I\'m\ntrying to help the project get setup to do the third-party testing that\nis needed for the ML2 driver to be accepted into OpenStack.\n\nI\'m sending a note requesting a dedicated user with stream access be\nsetup as per your \"requesting a service account\" section of this:\nhttp://ci.openstack.org/third_party.html\n\nHere\'s the SSH pubkey that we would like to use:\n\n--[cut]--\n\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAztcqByxj\n+6H3Vb78ZZN8FTbritMUBssYGxNdjdbhYJk60hQq/D4adWf4RAf3F6FGKhWCZAqPMdHFyZNjHsWUJJZGs68B0fA/jnlU1CQTeD3cf2olgXYE8X/h1c1LW1iPYndFm8JSmz3b8FigIcMEekTxlQzLOtToWoUPiLkrG/esk1lUd2FUapEay03iId9cERSTBtiAGVzw5K5E5HYotzriQnugcOkTxQilbXNBbg+m1YshC7wFlGHpOQHTtG+BhznXtmlFRXQTcOiwtp5f9PJgIyzeOMNN45i/Dbl4lAQpTqf/OklMh4CSK+LaHlJ1MgaKfb5Qk3NXdGTsKhOGvQ== odl-openstack at opendaylight.org\n\n--[/cut]--\n\nIf possible, I would like to use the following username (if possible)\nodl-jenkins\n\nThe display name can be: OpenDaylight Jenkins\n\nThe email to use for the account should be\nodl-openstack at opendaylight.org as that will route to the appropriate\npeople.\n\nIf you have any questions please let me know!\n-Andy-\n\n-- \nAndrew J Grimberg\nSystems Administrator\nThe Linux Foundation\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140211/89e51868/attachment.pgp>\n\n',NULL,NULL),('<1392154680.2185.65.camel@recto>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-11 16:38:00',-18000,'2014-02-11 21:38:00',NULL,'[openstack-dev] oslo.config improvements','On Mon, 2014-02-10 at 10:50 -0500, Doug Hellmann wrote:\n>         \n>         2) It locates options based on them being defined at the top\n>         level of a\n>         module (not in function or packed into some object), but it\n>         gets info by\n>         looking at cfg.CONF, which require registration. This fails if\n>         an option\n>         is defined by only registered when some function is called.\n>         This happens\n>         right now with the ip_lib_force_root option in Neutron. Both\n>         the config\n>         file generator and config docs generator currently crash on\n>         Neutron\n>         because of this.\n> \n> \n> The option definition needs to be in a variable at the module top\n> level, even if the registration call happens at run time. Can you file\n> a bug against Neutron about that?\n\nThe option *is* currently defined at the module top level, though it\'s\nonly registered when a function is called. _guess_groups in generator.py\nraises an error, because it looks for all instantiated options in the\ncfg.CONF object, and it\'s not there.\n\n\n>         3) It\'s completely incapable of finding options that aren\'t\n>         defined or\n>         registered until some function is called or some object is\n>         instantiated.\n>         I don\'t have a general solution to this, although I do have\n>         special-case\n>         code that detects projects that use oslo.messaging and ensures\n>         those\n>         options get registered.\n> \n> \n> I did some work to address this under\n> https://blueprints.launchpad.net/oslo/+spec/improve-config-discovery-for-docs so that libraries can register entry points that declare configuration options. I think the only library using this feature so far is oslo.messaging, but the other oslo libraries will use it when they graduate from the incubator.\n\nOh, thanks. That\'s much cleaner than my workaround for oslo.messaging:\n\nhttps://review.openstack.org/#/c/68196/\n\n\n\n>         To address these issues, I\'d like to get oslo.config to know\n>         about the\n>         defining module for each option. It can get that using\n>         something like\n>         this in Opt.__init__:\n>         \n>         for frame in inspect.stack():\n>             mod = inspect.getmodule(frame[0])\n>             if mod == sys.modules[__name__]:\n>                 continue\n>             self.module = mod.__name__\n>                 break\n> \n> \n> I\'m not sure we want deployers to have to worry about where the option\n> is defined. How would you use the information in the documentation? I\n> guess we include it in the sample config output?\n\nI agree that deployers shouldn\'t have to care about the defining module.\nThe only reason I\'ve proposed it is that the entire architecture of the\nsample config generator is geared around poking into modules looking for\noptions, because it wants to group options by module. This one addition\nto Opt.__init__ would make things simpler and faster for the sample\nconfig generator.\n\nAs for the docs, I\'m not sure if we want that info in there or not. I\nwouldn\'t push hard for it if it\'s not already there. Whether we\'d bother\nwith it if it is available is something I\'d have to ask the rest of the\ndocs team.\n\n>         \n>         We\'d also have to modify __eq__ and __ne__, because it\'s valid\n>         for an\n>         option to be defined in two different modules as long as all\n>         its\n>         parameters are the same. Checking vars() equality would trip\n>         up on the\n>         module. (There\'s the further issue that the defining module is\n>         non-deterministic in those cases.)\n> \n> \n> It\'s valid for an option to be registered with the same definition\n> more than once, but having the definition live in more than one place\n> is just asking for maintenance trouble later. Do we actually have this\n> situation now?\n\nauth_strategy is defined in both neutron/common/config.py and\nneutron/agent/linux/interface.py. It would also be defined in\nneutron/agent/metadata/agent.py, except it\'s defined in a class variable\nand only registered by calling main().\n\n>  \n>         \n>         Then I\'d like to get both the config file generator and the\n>         config docs\n>         generator using something like the OptionsCache class I wrote\n>         for the\n>         config docs generator:\n>         \n>         http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/common.py#n88\n>         \n>         This could be simpler and faster and avoid the crash mentioned\n>         above\n>         with the module info attached to each option.\n> \n> \n> Having 2 programs that discover options in 2 ways is a bad thing, so\n> yes, let\'s combine them in oslo.config and let them share code.\n\nGreat. So I think there\'s three things we\'ll have to figure out:\n\n1) What\'s the best way to group things by module? The answer might just\nbe \"It\'s not really worth grouping things by module.\"\n\n2) Is it sufficient to just ask cfg.CONF for options, or do we need to\npoke around looking for unregistered options? If the latter, where do we\nput that poking around code?\n\n3) Where do we put the code that sanitizes the defaults? That\'s the\nother piece of the sample config generator I\'m using. It\'s a _private\nfunction right now, so I\'m a bit uneasy about using it. I don\'t know if\nthat belongs in oslo.config proper. It\'s only useful to these generator\nprograms.\n\n--\nShaun\n\n\n\n\n\n','<CADb+p3Q-4h1UgEEvW5iQpZNbWuTPHDCUivkii03_7GmEU3r+ZA@mail.gmail.com>',NULL),('<1392200682.6362.YahooMailNeo@web122605.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-12 02:24:42',-28800,'2014-02-12 10:24:42',NULL,'[Openstack] openstack havana cinder chooses wrong host to create\n	new volume','\n\n\nHi,\n\nI have a setup with Openstack Havana on ubuntu precise with multiple schedulers and volumes.\nroot at opstck10:~# cinder service-list\n+------------------+----------+------+---------+-------+----------------------------+\n|????? Binary????? |?? Host?? | Zone |? Status | State |???????? Updated_at???????? |\n+------------------+----------+------+---------+-------+----------------------------+\n| cinder-scheduler | opstck08 | nova | enabled |?? up? | 2014-02-12T10:08:28.000000 |\n| cinder-scheduler | opstck09 | nova | enabled |?? up? | 2014-02-12T10:08:29.000000 |\n| cinder-scheduler | opstck10 | nova | enabled |?? up? | 2014-02-12T10:08:28.000000 |\n|? cinder-volume?? | opstck01 | nova | enabled |? down | 2014-02-12T09:39:09.000000 |\n|? cinder-volume?? | opstck04 | nova | enabled |? down |\n 2014-02-12T09:39:09.000000 |\n|? cinder-volume?? | opstck05 | nova | enabled |? down | 2014-02-12T09:39:09.000000 |\n|? cinder-volume?? | opstck08 | nova | enabled |?? up? | 2014-02-12T10:08:28.000000 |\n|? cinder-volume?? | opstck09 | nova | enabled |?? up? | 2014-02-12T10:08:28.000000 |\n|? cinder-volume?? | opstck10 | nova | enabled |?? up? | 2014-02-12T10:08:28.000000 |\n+------------------+----------+------+---------+-------+----------------------------+\n\n\nWhen I am trying to create a new instance from a volume snapshot it keeps \nchoosing for the creation of the volume opstck01 on which cinder-volume is down.\nDid anyone encounter the same problem?\nThanks\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140212/ec3c2374/attachment.html>\n\n','<1392200591.44910.YahooMailNeo@web122604.mail.ne1.yahoo.com>',NULL),('<1392220399-sup-5406@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-12 08:04:39',-28800,'2014-02-12 16:04:39',NULL,'[openstack-dev] [Heat] [TripleO] in-instance update hooks','Excerpts from James Slagle\'s message of 2014-02-12 05:18:31 -0800:\n> On Tue, Feb 11, 2014 at 12:22 AM, Clint Byrum <clint at fewbar.com> wrote:\n> > Hi, so in the previous thread about rolling updates it became clear that\n> > having in-instance control over updates is a more fundamental idea than\n> > I had previously believed. During an update, Heat does things to servers\n> > that may interrupt the server\'s purpose, and that may cause it to fail\n> > subsequent things in the graph.\n> >\n> > Specifically, in TripleO we have compute nodes that we are managing.\n> > Before rebooting a machine, we want to have a chance to live-migrate\n> > workloads if possible, or evacuate in the simpler case, before the node\n> > is rebooted. Also in the case of a Galera DB where we may even be running\n> > degraded, we want to ensure that we have quorum before proceeding.\n> >\n> > I\'ve filed a blueprint for this functionality:\n> >\n> > https://blueprints.launchpad.net/heat/+spec/update-hooks\n> >\n> > I\'ve cobbled together a spec here, and I would very much welcome\n> > edits/comments/etc:\n> >\n> > https://etherpad.openstack.org/p/heat-update-hooks\n> \n> I like this approach.\n> \n> Could this work for the non-reboot required incremental update (via\n> rsync or whatever) idea that\'s been discussed as well? I think it\'d be\n> nice if we had a model that worked for both the rebuild case and\n> incremental case.\n> \n> What if there was an additional type for actions under action_hooks\n> called update or incremental (I\'m not sure if there is a term for this\n> in Heat today) in addition to the rebuild and delete action choices\n> that are already there.\n> \n> When the instance sees that this action type is pending, it can\n> perform the update, and then use the wait condition handle to indicate\n> to Heat that the update is complete vs. using the wait condition\n> handle to indicate to proceed with the rebuild.\n> \n> I suppose the instance might need some additional data (such as the\n> new Image Id) in order to perform the incremental update. Could this\n> be made available somehow in the metadata structure?\n> \n\nThanks for reading it James.\n\nWe\'ve talked about having an image ID in the Metadata that may or may not\nbe the same image ID that is in the server properties to signify that we\nwant the machine to update itself from said image. That would already be\ncovered by the general \"I\'m done configuring myself\" wait condition. In\nthis case, there is no pending Heat action to prevent when we\'re just\nupdating metadata, so I think we already handle this situation.\n\n\n','<CAHV77z8gNP8f=8341CRqr9Em3wP8ztKQD27gR48QQ7XbKoLFZw@mail.gmail.com>',NULL),('<1392227868.18081.YahooMailNeo@web122602.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-12 09:57:48',-28800,'2014-02-12 17:57:48',NULL,'[Openstack] openstack havana cinder chooses wrong host to\n	create new volume','Thanks for the answer John.\nThis is really tricky and I will try to explain why:\nYou were right. The snap volume itself was created from a volume on opstck01 when it was up.\nThis is the offending snap. Here is the proof:\nroot at opstck10:~# cinder snapshot-show 30093123-0da2-4864-b8e6-87e023e842a4\n+--------------------------------------------+--------------------------------------+\n|????????????????? Property????????????????? |??????????????? Value???????????????? |\n+--------------------------------------------+--------------------------------------+\n|???????????????? created_at???????????????? |????? 2014-02-12T13:20:41.000000????? |\n|??????????? display_description???????????? |????????????????????????????????????? |\n|??????????????? display_name??????????????? |????????? cirros-0.3.1-snap?????????? |\n|???????????????????? id???????????????????? | 30093123-0da2-4864-b8e6-87e023e842a4 |\n|????????????????? metadata????????????????? |????????????????? {}????????????????? |\n|? os-extended-snapshot-attributes:progress? |???????????????? 100%???????????????? |\n| os-extended-snapshot-attributes:project_id |?? 8c25ff44225f4e78ab3f526d99c1b7e1?? |\n|??????????????????? size??????????????????? |????????????????? 1?????????????????? |\n|?????????????????? status?????????????????? |????????????? available?????????????? |\n|???????????????? volume_id????????????????? | 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9 |\n+--------------------------------------------+--------------------------------------+\n\n\nroot at opstck10:~# cinder show 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9\n+--------------------------------+--------------------------------------+\n|??????????? Property??????????? |??????????????? Value???????????????? |\n+--------------------------------+--------------------------------------+\n|????????? attachments?????????? |????????????????? []????????????????? |\n|?????? availability_zone??????? |???????????????? nova???????????????? |\n|??????????? bootable??????????? |??????????????? false???????????????? |\n|?????????? created_at?????????? |????? 2014-02-11T15:33:58.000000????? |\n|????? display_description?????? |????????????????????????????????????? |\n|????????? display_name????????? |???????????? cirros-0.3.1???????????? |\n|?????????????? id?????????????? | 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9 |\n|??????????? metadata??????????? |?????? {u\'readonly\': u\'False\'}??????? |\n|???? os-vol-host-attr:host????? |??????????????opstck01?????????????? |\n| os-vol-mig-status-attr:migstat |???????????????? None???????????????? |\n| os-vol-mig-status-attr:name_id |???????????????? None???????????????? |\n|? os-vol-tenant-attr:tenant_id? |?? 8c25ff44225f4e78ab3f526d99c1b7e1?? |\n|????????????? size????????????? |????????????????? 1?????????????????? |\n|????????? snapshot_id?????????? |???????????????? None???????????????? |\n|????????? source_volid????????? |???????????????? None???????????????? |\n|???????????? status???????????? |????????????? available?????????????? |\n|????????? volume_type?????????? |???????????????? None???????????????? |\n+--------------------------------+--------------------------------------+\n\n\nAnd now follows the interesting part. I am using ceph as a backend for cinder and I have multiple cinder-volume agents for HA reasons. The volumes themselves are available. The agents can fall.? How can I overcome the limitation to create a volume on the same agent as the snap itself was created? \n\n\nThanks a lot,\nGabriel\n\n\n\n\n\nOn Wednesday, February 12, 2014 6:20 PM, John Griffith <john.griffith at solidfire.com> wrote:\n \nOn Wed, Feb 12, 2014 at 3:24 AM, Staicu Gabriel\n<gabriel_staicu at yahoo.com> wrote:\n>\n>\n> Hi,\n>\n> I have a setup with Openstack Havana on ubuntu precise with multiple\n> schedulers and volumes.\n> root at opstck10:~# cinder service-list\n> +------------------+----------+------+---------+-------+----------------------------+\n> |? ? ? Binary? ? ? |?  Host?  | Zone |? Status | State |? ? ? ?  Updated_at\n> |\n> +------------------+----------+------+---------+-------+----------------------------+\n> | cinder-scheduler | opstck08 | nova | enabled |?  up? |\n> 2014-02-12T10:08:28.000000 |\n> | cinder-scheduler | opstck09 | nova | enabled |?  up? |\n> 2014-02-12T10:08:29.000000 |\n> | cinder-scheduler | opstck10 | nova | enabled |?  up? |\n> 2014-02-12T10:08:28.000000 |\n> |? cinder-volume?  | opstck01 | nova | enabled |? down |\n> 2014-02-12T09:39:09.000000 |\n> |? cinder-volume?  | opstck04 | nova | enabled |? down |\n> 2014-02-12T09:39:09.000000 |\n> |? cinder-volume?  | opstck05 | nova | enabled |? down |\n> 2014-02-12T09:39:09.000000 |\n> |? cinder-volume?  | opstck08 | nova | enabled |?  up? |\n> 2014-02-12T10:08:28.000000 |\n> |? cinder-volume?  | opstck09 | nova | enabled |?  up? |\n> 2014-02-12T10:08:28.000000 |\n> |? cinder-volume?  | opstck10 | nova | enabled |?  up? |\n> 2014-02-12T10:08:28.000000 |\n> +------------------+----------+------+---------+-------+----------------------------+\n>\n> When I am trying to create a new instance from a volume snapshot it keeps\n> choosing for the creation of the volume opstck01 on which cinder-volume is\n> down.\n> Did anyone encounter the same problem?\n> Thanks\n>\n>\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to? ?  : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\nWhich node is the parent volume and snapshot on?? In the case of\ncreate from source-volume and create from snapshot these need to be\ncreated on the same node as the source or snapshot.? There\'s currently\na bug ([1]), where we don\'t check/enforce the type settings to make\nsure these match up.? That\'s in progress right now and will be\nbackported.\n\n[1]: https://bugs.launchpad.net/cinder/+bug/1276787\n\n\nThanks,\nJohn\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140212/d4847ed8/attachment.html>\n\n','<CA+qL3LWBYhA55XpkC5ELVqGz7HGUWS+Y3t6ApXuPXnpb=-GFZw@mail.gmail.com>',NULL),('<1392240351.40342801@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-12 15:25:51',-21600,'2014-02-12 21:25:51',NULL,'[openstack-dev] [Solum] Question about Zuul\'s role in Solum','Hi,\n\nI have been looking at Zuul for last few days and had a question\nabout its intended role within Solum.\n\nFrom what I understand, Zuul is a code gating system.\n\nI have been wondering if code gating is something we are considering as a feature\nto be provided in Solum? If yes, then Zuul is a perfect fit.\nBut if not, then we should discuss what benefits do we gain by using Zuul\nas an integral part of Solum.\n\nIt feels to me that right now we are treating Zuul as a conduit for triggering job(s)\nthat would do the following:\n- clone/download source\n- run tests\n- create a deployment unit (DU) if tests pass\n- upload DU to glance\n- trigger the DU deployment workflow\n\nIn the language-pack working group we have talked about being able to do\nCI on the submitted code and building the DUs only after tests pass. \nNow, there is a distinction between doing CI on merged code vs.\ndoing it before code is permanently merged to master/stable branches.\nThe latter is what a \'code gating\' system does, and Zuul is a perfect fit for this.\nFor the former though, using a code gating system is not be needed.\nWe can achieve the former with an API endpoint, a queue,\nand a mechanism to trigger job(s) that perform above mentioned steps.\n\nI guess it comes down to Solum\'s vision. If the vision includes supporting, among other things, code gating\nto ensure that Solum-managed code is never broken, then Zuul is a perfect fit.\nOf course, in that situation we would want to ensure that the gating functionality is pluggable\nso that operators can have a choice of whether to use Zuul or something else.\nBut if the vision is to be that part of an overall application lifecycle management flow which deals with\ncreation and scaling of DUs/plans/assemblies but not necessarily be a code gate, then we should re-evaluate Zuul\'s role\nas an integral part of Solum.\n\nThoughts?\n\nThanks,\nDevdatta\n\n\n\n\n',NULL,NULL),('<1392301998-sup-7308@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 06:37:55',-28800,'2014-02-13 14:37:55',NULL,'[openstack-dev] [Solum] Question about Zuul\'s role in Solum','Excerpts from Julien Vey\'s message of 2014-02-13 05:18:19 -0800:\n> Hi,\n> \n> I have some concerns about using Zuul in Solum\n> \n> I agree gating is a great feature but it is not useful for every project\n> and as Adrian said, not understood by everyone.\n> I think many Solum users, and PaaS users in general, are\n> single-project/single-build/simple git worklow and do not care about gating.\n> \n\nThe gate can be a noop. Easier to insert more gate tests when it matters\nthan it is to swap out technologies at that time.\n\n> I see 2 drawbacks with Zuul :\n> - Tenant Isolation : How do we allow access on zuul (and jenkins) for a\n> specific tenant in isolation to the others tenants using Solum.\n\nSame way Trove has a mysql database per tenant I presume.\n\n> - Build customization : One of the biggest advantage of Jenkins is its\n> ecosystem and the many build customization it offers. Using zuul will\n> prohibit this.\n\nNobody is saying you can\'t use Jenkins. People are saying use Zuul and\nget more than Jenkins. But go on and use Jenkins as well.\n\n> \n> About Gerrit, I think it is also a little too much. Many users have their\n> own reviewing system, Pull requests with github, bitbucket or stash, their\n> own instance of gerrit, or even a custom git workflow.\n> Gerrit would be a great feature for future versions of Solum. but only as\n> an optionnal one, we should not force people into it.\n\nAgreed on that.\n\n\n','<CAP4JdAGNi0Ey=1qLvN3suTdW43643cCN8XV9LAs2ALvLwokFdg@mail.gmail.com>',NULL),('<1392302975-sup-6608@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 07:01:05',-28800,'2014-02-13 15:01:05',NULL,'[openstack-dev] \"bad\" default values in conf files','Excerpts from David Kranz\'s message of 2014-02-13 06:38:52 -0800:\n> I was recently bitten by a case where some defaults in keystone.conf \n> were not appropriate for real deployment, and our puppet modules were \n> not providing better values \n> https://bugzilla.redhat.com/show_bug.cgi?id=1064061.\n\nJust taking a look at that issue, Keystone\'s PKI and revocation are\ncausing all kinds of issues with performance that are being tackled with\na bit of a redesign. I doubt we can find a cache timeout setting that\nwill work generically for everyone, but if we make detecting revocation\nscale, we won\'t have to.\n\nThe default probably is too low, but raising it too high will cause\nconcern with those who want revoked tokens to take effect immediately\nand are willing to scale the backend to get that result.\n\n> Since there are \n> hundreds (thousands?) of options across all the services. I am wondering \n> whether there are other similar issues lurking and if we have done what \n> we can to flush them out.\n> \n> Defaults in conf files seem to be one of the following:\n> \n> - Generic, appropriate for most situations\n> - Appropriate for devstack\n> - Appropriate for small, distro-based deployment\n> - Approprate for large deployment\n> \n> Upstream, I don\'t think there is a shared view of how defaults should be \n> chosen.\n> \n\nI don\'t know that we have been clear enough about this, but nobody has\never challenged the assertion we\'ve been making for a while in TripleO\nwhich is that OpenStack _must_ have production defaults. We don\'t make\nOpenStack for devstack.\n\nIn TripleO, we consider it a bug when we can\'t run with a default value\nthat isn\'t directly related to whatever makes that cloud unique. So\nthe virt driver: meh, that\'s a choice, but leaving file injection on is\nreally not appropriate for 99% of users in production. Also you\'ll see\nquite a few commits from me in the keystone SQL token driver trying to\nspeed it up because the old default token backend was KVS (in-memory),\nwhich was fast, but REALLY not useful in production. We found these\nthings by running defaults and noticing in a long running cloud where\nthe performance problems are, and we intend to keep doing that.\n\nSo perhaps we should encode this assertion in\nhttps://wiki.openstack.org/wiki/ReviewChecklist\n\n> Keeping bad defaults can have a huge impact on performance and when a \n> system falls over but the problems may not be visible until some time \n> after a system gets into real use. Have the folks creating our puppet \n> modules and install recommendations taken a close look at all the \n> options and determined\n> that the defaults are appropriate for deploying RHEL OSP in the \n> configurations we are recommending?\n>\n\nTripleO is the official \"deployment\" program. We are taking the approach\ndescribed above. We\'re standing up several smallish (<50 nodes) clouds\nwith the intention of testing the defaults on real hardware in the gate\nof OpenStack eventually.\n\n\n','<52FCD8FC.2010703@redhat.com>',NULL),('<1392304758.2163.26.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 10:19:18',-18000,'2014-02-13 15:19:18',NULL,'[openstack-dev] \"bad\" default values in conf files','On Thu, 2014-02-13 at 09:38 -0500, David Kranz wrote:\n> I was recently bitten by a case where some defaults in keystone.conf \n> were not appropriate for real deployment, and our puppet modules were \n> not providing better values \n> https://bugzilla.redhat.com/show_bug.cgi?id=1064061. Since there are \n> hundreds (thousands?) of options across all the services. I am wondering \n> whether there are other similar issues lurking and if we have done what \n> we can to flush them out.\n> \n> Defaults in conf files seem to be one of the following:\n> \n> - Generic, appropriate for most situations\n> - Appropriate for devstack\n> - Appropriate for small, distro-based deployment\n> - Approprate for large deployment\n> \n> Upstream, I don\'t think there is a shared view of how defaults should be \n> chosen.\n> \n> Keeping bad defaults can have a huge impact on performance and when a \n> system falls over but the problems may not be visible until some time \n> after a system gets into real use. Have the folks creating our puppet \n> modules and install recommendations taken a close look at all the \n> options and determined\n> that the defaults are appropriate for deploying RHEL OSP in the \n> configurations we are recommending?\n\nThis is a very common problem in the configuration management space,\nfrankly. One good example is the upstream mysql Chef cookbook keeping\nludicrously low InnoDB buffer pool, log and data file sizes. The\ndefaults from MySQL -- which were chosen, frankly, in the 1990s, are\nuseful for nothing more than a test environment, but unfortunately they\npropogate to far too many deployments with folks unaware of the serious\nside-effects on performance and scalability until it\'s too late [1].\n\nI think it\'s an excellent idea to do a review of the values in all of\nthe configuration files and do the following:\n\n* Identify settings that simply aren\'t appropriate for anything and make\nthe change to a better default.\n\n* Identify settings that need to scale with the size of the underlying\nVM or host capabilities, and provide patches to the configuration file\ncomments that clearly indicate a recommended scaling factor. Remember\nthat folks writing Puppet modules, Ansible scripts, Salt SLS files, and\nChef cookbooks look first to the configuration files to get an idea of\nhow to set the values.\n\nBest,\n-jay\n\n[1] The reason I say it\'s \"too late\" is because for some configuration\nvalue -- notably innodb_log_file_size and innodb_data_file_size -- it is\nnot possible to change the configuration values after data has been\nwritten to disk. You need to literally dump the contents of the DBs and\nreload the database after removing the files and restarting the DBs\nafter changing the configuration options in my.cnf. See this bug for\ndetails on this pain in the behind:\n\nhttps://tickets.opscode.com/browse/COOK-2100\n\n\n\n','<52FCD8FC.2010703@redhat.com>',NULL),('<1392314277.2163.28.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-13 12:57:57',-18000,'2014-02-13 17:57:57',NULL,'[OpenStack-Infra] Error with install_master','On Thu, 2014-02-13 at 11:11 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> I?m working on 3rd party test setup using your github blog.\n\nAh, cool. Good to get some feedback. I\'m still working on that repo,\nthough... having some issues getting the connectivity between master and\nslave set up right now...\n\n> I get this error when I run install_master.\n> \n> root at Freescale-CI:~# ./install_master.sh \n> \n> Using data repository: https://github.com/jaypipes/os-ext-testing-data\n> \n> Using upstream Gerrit user: freescale-ci\n> \n> Puppet::Parser::AST::Resource failed with error ArgumentError: Could\n> not find declared class os_ext_testing::master at line 88 on node\n> freescale-ci.ap.freescale.net\n\nYou just need to git pull the latest code from the os-ext-testing\nrepo...\n\nBest,\n-jay\n\n\n\n\n','<93750f47aa7e476b9918c6ac27e6540d@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1392315210.2163.33.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-13 13:13:30',-18000,'2014-02-13 18:13:30',NULL,'[OpenStack-Infra] 3rd Party Testing','On Thu, 2014-02-13 at 16:08 +1100, Joshua Hesketh wrote:\n> Hi Trinath,\n> \n> Have you read up on these documents?\n> \n> http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\n> http://ci.openstack.org/third_party.html\n> https://github.com/jaypipes/os-ext-testing\n\nThanks, Josh. Follow up article coming soon that goes over the\nos-ext-testing repo usage. I\'m still working on fixing issues with the\nJenkins slave setup.\n\nAlso, there is an example \"data repo\" here with instructions on the\nREADME.md:\n\nhttps://github.com/jaypipes/os-ext-testing-data\n\nBest,\n-jay\n\n\n\n\n','<52FC5358.4030605@rackspace.com>',NULL),('<1392323981.2163.35.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 15:39:41',-18000,'2014-02-13 20:39:41',NULL,'[openstack-dev] [cinder][neutron][nova][3rd party testing]\n Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing','On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:\n> Jay, \n> \n> Just an FYI. We have modified the Gerrit plugin it accept/match regex\n> to generate notifications of for \"receck no bug/bug ###\". It turned\n> out to be very simple fix and we (Arista Testing) is now triggering on\n> recheck comments as well.\n\nThanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere\nwhere other folks can use it?\n\nI\'ve got Zuul actually working pretty well in my os-ext-testing repo\nnow. Only problem remaining is with the Jenkins slave trigger (not\nrelated to Gerrit...)\n\nBest,\n-jay\n\n\n\n\n','<CANZPNQ4ZFJB_Eru7qqAaWu66BEbK7yKzJ0twDLHv+CdD3E-Gsg@mail.gmail.com>',NULL),('<1392323981.2163.35.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-13 15:39:41',-18000,'2014-02-13 20:39:41',NULL,'[OpenStack-Infra] [cinder][neutron][nova][3rd party testing]\n Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing','On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:\n> Jay, \n> \n> Just an FYI. We have modified the Gerrit plugin it accept/match regex\n> to generate notifications of for \"receck no bug/bug ###\". It turned\n> out to be very simple fix and we (Arista Testing) is now triggering on\n> recheck comments as well.\n\nThanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere\nwhere other folks can use it?\n\nI\'ve got Zuul actually working pretty well in my os-ext-testing repo\nnow. Only problem remaining is with the Jenkins slave trigger (not\nrelated to Gerrit...)\n\nBest,\n-jay\n\n\n\n\n','<CANZPNQ4ZFJB_Eru7qqAaWu66BEbK7yKzJ0twDLHv+CdD3E-Gsg@mail.gmail.com>',NULL),('<1392354034-sup-6763@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-13 21:13:17',-28800,'2014-02-14 05:13:17',NULL,'[Openstack-operators] [openstack-dev] [TripleO] consistency vs\n	packages in TripleO','Excerpts from matt\'s message of 2014-02-13 19:32:42 -0800:\n> For many people in enterprise git / pypi deployments are non starters.  We\n> use real package management systems with real signed packages for a bunch\n> of policy and architectural reasons.  So anyone who is under the mistaken\n> impression that pypi especially will be a usable deployment model in the\n> real world let me disabuse you of that notion right now.\n\nHi Matt. I totally understand where you are coming from. Trusting that\nyou\'re pulling the actual code you think you\'re pulling is important.\n\nHowever, consider some things:\n\n* pip now requires SSL with hostname verification, so there is a trust\n  loop now, albeit global PKI instead of distro-specific web of trust.\n\n* We clone git from https://git.openstack.org/. If you don\'t trust\n  that, you may not want to run OpenStack at all because that is what\n  developers are expected to use.\n\n* We use packages too. Lots of them. We just don\'t use them where they\n  complicate our goal of running and testing with upstream tools.\n\nYou may also have missed that we\'re aiming at distribution of images,\nnot packages, and one reason for that is that we want to be able to\nverify the image has not been tampered with between passing automated\ntests and deploying to production.\n\nWhile I\'m eager to hear your specific objections to this model, I hope\nthat we can agree, this is not your average hipster django dev pip\ninstall from github. ;)\n\n\n','<CAP_sDUEPthawjk3fBtUhLr3VpQUyWBkvqRuAD25UmwgpEwL+cg@mail.gmail.com>',NULL),('<1392385177.23460.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-02-14 13:39:37',0,'2014-02-14 13:39:37',NULL,'[openstack-tc] Missing next TC meeting','On Fri, 2014-02-14 at 14:09 +0100, Thierry Carrez wrote:\n> Members of the TC,\n> \n> I have an unexpected family event I need to attend on Tuesday, so I\n> won\'t be able to attend or chair our next TC meeting on February 18th.\n> \n> There are a few things that need to be discussed (progress on Defcore\n> subcommittee, Nova scorecard on integration requirements, Keystone\n> addition of the Kite project...) so unless we have a lot more absentees\n> I think it still makes sense to hold a meeting, as long as we have a\n> volunteer to chair it.\n> \n> Anyone interested ?\n\nSure, I\'m happy to chair.\n\nMark.\n\n\n\n\n','<52FE159C.3030303@openstack.org>',NULL),('<1392388746.2163.39.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-14 09:39:06',-18000,'2014-02-14 14:39:06',NULL,'[OpenStack-Infra] Error with install_master','On Fri, 2014-02-14 at 04:59 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> For third party setup, do we need to have master and slave setup?\n\nYes. The reason is because you cannot run devstack-based tests on the\nsame node that you are running your Jenkins master. Devstack interferes\nwith way too much stuff with regards to networking and makes it\nimpossible to run on something other than a separate slave node.\n\nNote that you don\'t need to have two separate physical machines. A VM or\nLXC container should work just fine.\n\nBest,\n-jay\n\n\n\n','<2452c7e146c3413b845cc6a98323c54c@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1392396324.2163.42.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 11:45:24',-18000,'2014-02-14 16:45:24',NULL,'[openstack-dev] [OpenStack-Infra] [cinder][neutron][nova][3rd\n party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd\n party testing','On Fri, 2014-02-14 at 08:54 +0900, Akihiro Motoki wrote:\n> Hi,\n> \n> I wrote a blog post about how to setup Zuul manually.\n> http://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.html\n> \n> It covers how to migrate from Gerrit Trigger plugin to Zuul and\n> some tips including a way to define vendor-specific recheck trigger\n> in addition to the setup procedure.\n> \n> Jay\'s puppet manifest is nice, but I hope the manual installation step\n> is also helpful to set up 3rd party testing.\n\nThanks Akihiro-san,\n\nI just put up the second article in the series that walks through\ninstallation of a Jenkins master, Zuul, and Jenkins Job Builder and\ntesting communication with upstream:\n\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n\nFeedback very much welcomed. Working on the slave setup article now...\n\nBest,\n-jay\n\n> On Fri, Feb 14, 2014 at 5:39 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:\n> >> Jay,\n> >>\n> >> Just an FYI. We have modified the Gerrit plugin it accept/match regex\n> >> to generate notifications of for \"receck no bug/bug ###\". It turned\n> >> out to be very simple fix and we (Arista Testing) is now triggering on\n> >> recheck comments as well.\n> >\n> > Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere\n> > where other folks can use it?\n> >\n> > I\'ve got Zuul actually working pretty well in my os-ext-testing repo\n> > now. Only problem remaining is with the Jenkins slave trigger (not\n> > related to Gerrit...)\n> >\n> > Best,\n> > -jay\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-Infra mailing list\n> > OpenStack-Infra at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n\n','<CALhU9tmH_9nZ7sRcbT=04q7FJCaUKRpc1UH2tRxw_8uLNcK_gA@mail.gmail.com>',NULL),('<1392396324.2163.42.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-14 11:45:24',-18000,'2014-02-14 16:45:24',NULL,'[OpenStack-Infra] [cinder][neutron][nova][3rd party testing]\n Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing','On Fri, 2014-02-14 at 08:54 +0900, Akihiro Motoki wrote:\n> Hi,\n> \n> I wrote a blog post about how to setup Zuul manually.\n> http://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.html\n> \n> It covers how to migrate from Gerrit Trigger plugin to Zuul and\n> some tips including a way to define vendor-specific recheck trigger\n> in addition to the setup procedure.\n> \n> Jay\'s puppet manifest is nice, but I hope the manual installation step\n> is also helpful to set up 3rd party testing.\n\nThanks Akihiro-san,\n\nI just put up the second article in the series that walks through\ninstallation of a Jenkins master, Zuul, and Jenkins Job Builder and\ntesting communication with upstream:\n\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n\nFeedback very much welcomed. Working on the slave setup article now...\n\nBest,\n-jay\n\n> On Fri, Feb 14, 2014 at 5:39 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:\n> >> Jay,\n> >>\n> >> Just an FYI. We have modified the Gerrit plugin it accept/match regex\n> >> to generate notifications of for \"receck no bug/bug ###\". It turned\n> >> out to be very simple fix and we (Arista Testing) is now triggering on\n> >> recheck comments as well.\n> >\n> > Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere\n> > where other folks can use it?\n> >\n> > I\'ve got Zuul actually working pretty well in my os-ext-testing repo\n> > now. Only problem remaining is with the Jenkins slave trigger (not\n> > related to Gerrit...)\n> >\n> > Best,\n> > -jay\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-Infra mailing list\n> > OpenStack-Infra at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n\n','<CALhU9tmH_9nZ7sRcbT=04q7FJCaUKRpc1UH2tRxw_8uLNcK_gA@mail.gmail.com>',NULL),('<1392403050-sup-5024@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 10:46:46',-28800,'2014-02-14 18:46:46',NULL,'[openstack-dev] [TripleO] consistency vs packages in TripleO','Excerpts from Robert Collins\'s message of 2014-02-13 13:27:20 -0800:\n> So progressing with the \'and folk that want to use packages can\' arc,\n> we\'re running into some friction.\n> \n> I\'ve copied -operators in on this because its very relevant IMO to operators :)\n> \n> So far:\n>  - some packages use different usernames\n>  - some put things in different places (and all of them use different\n> places to the bare metal ephemeral device layout which requires\n> /mnt/).\n>  - possibly more in future.\n> \n> Now, obviously its a \'small matter of code\' to deal with this, but the\n> impact on ops folk isn\'t so small. There are basically two routes that\n> I can see:\n> \n> # A\n>  - we have a reference layout - install from OpenStack git / pypi\n> releases; this is what we will gate on, and can document.\n>  - and then each distro (both flavor of Linux and also possibly things\n> like Fuel that distribution OpenStack) is different - install on X,\n> get some delta vs reference.\n>  -> we need multiple manuals describing how to operate and diagnose\n> issues in such a deployment, which is a matrix that overlays platform\n> differences the user selects like \'Fedora\' and \'Xen\'.\n> \n\nHaving read the responses, I\'m inclined to support A, with some\nadditional requirements:\n\n* Reference implementations are always derided as not realistic. I think\n  we need to think of a different term. I prefer to just say that this\n  is the upstream implementation. We very much expect that a cloud can\n  and should operate with this model unmodified. Packagers are doing so\n  to fit OpenStack into a greater support model, not because \"nobody\n  would ever want to run upstream.\" I think of how a large portion of\n  MySQL users tend to just run upstream\'s binaries. They don\'t call this\n  the reference binaries.\n\n* Documentation can be split into an architecture guide which should be\n  a single source of truth and document interfaces only, and an operations\n  guide, which will focus on the upstream operations story. Distros should\n  provide sub-sections for that story to document their differences.\n  They should not, however, be putting distro specific interfaces in the\n  architecture documentation, and we would reject such things until they\n  are known to work upstream.\n\n\n','<CAJ3HoZ1SRtRF_GQOjDVpjZDdNFjDCH4pBbs3HSbXiOPqgd5hhA@mail.gmail.com>',NULL),('<1392403979-sup-9804@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-14 10:53:09',-28800,'2014-02-14 18:53:09',NULL,'[Openstack-operators] [openstack-dev] [TripleO] consistency vs\n	packages in TripleO','Excerpts from Robert Collins\'s message of 2014-02-13 13:27:20 -0800:\n> So progressing with the \'and folk that want to use packages can\' arc,\n> we\'re running into some friction.\n> \n> I\'ve copied -operators in on this because its very relevant IMO to operators :)\n> \n> So far:\n>  - some packages use different usernames\n>  - some put things in different places (and all of them use different\n> places to the bare metal ephemeral device layout which requires\n> /mnt/).\n>  - possibly more in future.\n> \n> Now, obviously its a \'small matter of code\' to deal with this, but the\n> impact on ops folk isn\'t so small. There are basically two routes that\n> I can see:\n> \n> # A\n>  - we have a reference layout - install from OpenStack git / pypi\n> releases; this is what we will gate on, and can document.\n>  - and then each distro (both flavor of Linux and also possibly things\n> like Fuel that distribution OpenStack) is different - install on X,\n> get some delta vs reference.\n>  -> we need multiple manuals describing how to operate and diagnose\n> issues in such a deployment, which is a matrix that overlays platform\n> differences the user selects like \'Fedora\' and \'Xen\'.\n> \n\nHaving read the responses, I\'m inclined to support A, with some\nadditional requirements:\n\n* Reference implementations are always derided as not realistic. I think\n  we need to think of a different term. I prefer to just say that this\n  is the upstream implementation. We very much expect that a cloud can\n  and should operate with this model unmodified. Packagers are doing so\n  to fit OpenStack into a greater support model, not because \"nobody\n  would ever want to run upstream.\" I think of how a large portion of\n  MySQL users tend to just run upstream\'s binaries. They don\'t call this\n  the reference binaries.\n\n* Documentation can be split into an architecture guide which should be\n  a single source of truth and document interfaces only, and an operations\n  guide, which will focus on the upstream operations story. Distros should\n  provide sub-sections for that story to document their differences.\n  They should not, however, be putting distro specific interfaces in the\n  architecture documentation, and we would reject such things until they\n  are known to work upstream.\n\n\n','<CAJ3HoZ1SRtRF_GQOjDVpjZDdNFjDCH4pBbs3HSbXiOPqgd5hhA@mail.gmail.com>',NULL),('<1392406989-sup-3156@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 11:46:40',-28800,'2014-02-14 19:46:40',NULL,'[openstack-dev] \"bad\" default values in conf files','Excerpts from Jay Pipes\'s message of 2014-02-13 07:19:18 -0800:\n> * Identify settings that need to scale with the size of the underlying\n> VM or host capabilities, and provide patches to the configuration file\n> comments that clearly indicate a recommended scaling factor. Remember\n> that folks writing Puppet modules, Ansible scripts, Salt SLS files, and\n> Chef cookbooks look first to the configuration files to get an idea of\n> how to set the values.\n\nIndeed, and where possible make the setting a scaling factor rather than\nan actual number. It would make configs more portable if you could just\ndo this in mysql\'s config file:\n\ninnodb_buffer_pool_size=80%\n\nRather than having to read the manual to see that they recommend it be\n80% of system RAM.\n\n\n','<1392304758.2163.26.camel@cranky>',NULL),('<1392412799.24912.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 16:19:59',-18000,'2014-02-14 21:19:59',NULL,'[openstack-dev] \"bad\" default values in conf files','On Fri, 2014-02-14 at 11:30 -0800, Greg C wrote:\n> \n> On Thu, Feb 13, 2014 at 6:38 AM, David Kranz <dkranz at redhat.com>\n> wrote:\n>         \n>         Defaults in conf files seem to be one of the following:\n>         \n>         - Generic, appropriate for most situations\n>         - Appropriate for devstack\n>         - Appropriate for small, distro-based deployment\n>         - Approprate for large deployment\n> \n> \n>  In my experiences in creating OpenStack production systems, it\n> appears the answer is mostly \"Appropriate for devstack\".  I haven\'t\n> used devstack myself, only created production systems from Openstack\n> releases.  For practically every openstack component the message queue\n> config is missing\n\nActually, every OpenStack component has MQ configs in their conf files,\nand well documented:\n\nNova MQ configs:\n\nhttps://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L9-L187\n\nCinder:\n\nhttps://github.com/openstack/cinder/blob/master/etc/cinder/cinder.conf.sample#L610-L815\n\nKeystone:\n\nhttps://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L141-L163\n\nGlance:\n\nhttps://github.com/openstack/glance/blob/master/etc/glance-api.conf#L246-L283\n\nNeutron:\n\nhttps://github.com/openstack/neutron/blob/master/etc/neutron.conf#L105-L175\n\nCeilometer:\n\nhttps://github.com/openstack/ceilometer/blob/master/etc/ceilometer/ceilometer.conf.sample#L305-L475\n\n> , and every api-paste.ini needs a [filter:authtoken] section for\n> keystone.\n\nActually, every OpenStack project has this in their regular conf files:\n\nNova:\n\nhttps://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L2624\n\nCinder:\n\nhttps://github.com/openstack/cinder/blob/master/etc/cinder/cinder.conf.sample#L1879\n\nGlance:\n\nhttps://github.com/openstack/glance/blob/master/etc/glance-api.conf#L551\n\nNeutron:\n\nhttps://github.com/openstack/neutron/blob/master/etc/neutron.conf#L332\n\nCeilometer:\n\nhttps://github.com/openstack/ceilometer/blob/master/etc/ceilometer/ceilometer.conf.sample#L713\n\n> It appears to me that those things are somehow covered when using\n> devstack.  Besides having to be added, the pitfall this creates is\n> that documentation for releases will not point out that they need to\n> be added and configured, because somehow devstack doesn\'t require it.\n\nI\'m not sure why you think this. What configuration management system\nare you using to deploy OpenStack?\n\n> I use a VLAN model of networking as well, which as far as I can tell\n> devstack doesn\'t test/support, \n\nIncorrect. export NETWORK_MANAGER=VlanManager in your localrc.\n\n> so I have to chase down a bunch of other config items that are missing\n> and scarcely documented.  The whole thing is quite a chore.  I don\'t\n> know why those common keystone and message queue configs can\'t be in\n> there from the start.\n\nThey are.\n\nBest,\n-jay\n\n\n\n\n','<CAFLVWR3YrkXW743JiaRdrarmk79KJ4vM=j2xSf=fmAh+2VdkaA@mail.gmail.com>',NULL),('<1392413296.18667.YahooMailNeo@web122603.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-14 13:28:16',-28800,'2014-02-14 21:28:16',NULL,'[Openstack] standalone mysql','Hi,\n\nCan you give more information?\n- is mysql running?\n- can you connect to mysql from db host and from controller node?\n\n- who and what access rights are on keystone db?\n\n- is keystone service running?\n- content of the /var/log/keystone?\n- output of the \"keystone --debug user-list\"?\n\nRegards,\nGabriel\n\n\n\n\nOn Friday, February 14, 2014 10:15 PM, Xin Zhao <xzhao at bnl.gov> wrote:\n \nHello,\n\nI would like to use a mysql DB, from its own host, and have all \nopenstack daemons talk to it.? So I set up one mysql DB, dump and reload \nthe current running DB to it,? changed the sql \"connection\" setting in \nthe keystone config file to point to the new ip, restart keystone \nservice, but it doesn\'t seem to work. The commands like \"keystone \nuser-list\" hang and eventually times out.\n\nDo I miss something here?\n\nThanks,\nXin\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140214/b5e84bdf/attachment.html>\n\n','<52FE83BF.5040407@bnl.gov>',NULL),('<1392418037.24912.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 17:47:17',-18000,'2014-02-14 22:47:17',NULL,'[openstack-dev] [Solum] Question about Zuul\'s role in Solum','On Thu, 2014-02-13 at 00:05 +0000, Adrian Otto wrote:\n> If they want something more comprehensive, including a full set of open source best practices by default, such as entrance and exit gating, hosted code review and collaboration, It would be really nice to have a full Zuul+Nodepool+Jenkins+Gerrit setup with some integration points where they could potentially customize it.\n\nYou might be interested in a couple articles I recently wrote around\nthis very topic! :)\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n\nCheers,\n-jay\n\n\n\n','<FCB95477-180B-46B6-8DDD-EE2D8FCE7565@rackspace.com>',NULL),('<1392418295.24912.18.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 17:51:35',-18000,'2014-02-14 22:51:35',NULL,'[openstack-dev] [Solum] Question about Zuul\'s role in Solum','On Thu, 2014-02-13 at 14:18 +0100, Julien Vey wrote:\n> I agree gating is a great feature but it is not useful for every\n> project and as Adrian said, not understood by everyone.\n> I think many Solum users, and PaaS users in general, are\n> single-project/single-build/simple git worklow and do not care about\n> gating.\n\nThis is 100% correct.\n\n> I see 2 drawbacks with Zuul :\n> - Tenant Isolation : How do we allow access on zuul (and jenkins) for\n> a specific tenant in isolation to the others tenants using Solum.\n> - Build customization : One of the biggest advantage of Jenkins is its\n> ecosystem and the many build customization it offers. Using zuul will\n> prohibit this.\n\nNot sure I understand this part... Zuul works *with* Jenkins. It does\nnot replace it.\n\n> About Gerrit, I think it is also a little too much. Many users have\n> their own reviewing system, Pull requests with github, bitbucket or\n> stash, their own instance of gerrit, or even a custom git workflow.\n> Gerrit would be a great feature for future versions of Solum. but only\n> as an optionnal one, we should not force people into it.\n\nCompletely agreed. Frankly, both Gerrit and Jenkins are a giant pain in\nthe ass to install, maintain, and configure (hmm, which Java/Prolog\nprograms aren\'t, I wonder?).\n\nBasing Solum\'s *default* workflow on these tools would be a mistake IMO.\n\nBest,\n-jay\n\n\n\n\n','<CAP4JdAGNi0Ey=1qLvN3suTdW43643cCN8XV9LAs2ALvLwokFdg@mail.gmail.com>',NULL),('<1392422092.5487.9.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 15:54:52',-28800,'2014-02-14 23:54:52',NULL,'[openstack-dev] [Nova] bp proposal: filter based on the load\n averages of the host','On Fri, 2014-02-14 at 15:29 +0000, sahid wrote:\n> Greetings,\n> \n> I would like to add a new filter based on the load averages.\n> \n> This filter will use the command uptime and will provides an option to choice a\n> period between 1, 5, and 15 minutes and an option to choice the max load\n> average (a float between 0 and 1).\n> \n> Why:\n>   During a scheduling it could be useful to exclude a host that have a too\n> heavy load and the command uptime (available in all linux system) \n> can return a load average of the system in different periods.\n> \n> About the implementation:\n>   Currently \'all\' drivers (libvirt, xenapi, vmware) supports a method\n> get_host_uptime that returns the output of the command \'uptime\'. We have to add\n> in compute/stats.py a new method calculate_loadavg() that returns based on the\n> output of driver.get_host_uptime() from compute/ressource_tracker.py a well\n> formatted tuple of load averages for each periods. We also need to update\n> api/openstack/compute/contrib/hypervisors.py to take care of this new\n> field.\n> \n>   The implementation will be divided in several parts:\n>     * Add to host_manager the possibility to get the loads_averages\n>     * Implement the filter based on this new property\n>     * Implement the filter with a per-aggregate configuration\n> \n> The blueprint: https://blueprints.launchpad.net/nova/+spec/filter-based-uptime\n> \n> I will be happy to get any comments about this filter, perharps it is not implemented\n> yet because of something I didn\'t see or my thinking of the implementation is wrong.\n> \n> PS: I have checked metrics and cpu_resource but It does not get an averages of the\n> system load or perhaps I have not understand all.\n> \n> Thanks a lot,\n> s.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI think load average has more than CPU, you need consider like I/O\nusage, or even other metrics. Maybe you can have a look at the\nhttps://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling ?\n\nAlso IMHO the policy of \"exclude a host that have a too heavy load\" is\nnot so clean, would it be better to keep the usage as a scheduler\nweight?\n\nThanks\n--jyh\n\n\n\n','<872391819.22694973.1392391777025.JavaMail.root@cloudwatt.com>',NULL),('<1392423705.5487.17.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-14 16:21:45',-28800,'2014-02-15 00:21:45',NULL,'[openstack-dev] [nova] Should we limit the disk IO bandwidth in\n copy_image while creating new instance?','On Fri, 2014-02-14 at 10:22 +0100, Sylvain Bauza wrote:\n> Instead of limitating the consumed bandwidth by proposiong a\n> configuration flag (yet another one, and which default value to be\n> set ?), I would propose to only decrease the niceness of the process\n> itself, so that other processes would get first the I/O access.\n> That\'s not perfect I assume, but that\'s a quick workaround limitating\n> the frustration.\n> \n> \n> -Sylvain\n> \nDecrease goodness is good for a short term, Some small concerns are,\nwill that cause long launch time if the host is I/O intensive? And if\nlaunch time is billed also, then not fair for the new instance also.\n\nI think the ideal world is I/O QoS like through cgroup, take I/O\nbandwidth as a resource, and take the copy_image as an consumption of\nthe I/O bandwidth resource.\n\nThanks\n--jyh\n> \n> 2014-02-14 4:52 GMT+01:00 Wangpan <hzwangpan at corp.netease.com>:\n>         Currently nova doesn\'t limit the disk IO bandwidth in\n>         copy_image() method while creating a new instance, so the\n>         other instances on this host may be affected by this high disk\n>         IO consuming operation, and some time-sensitive business(e.g\n>         RDS instance with heartbeat) may be switched between master\n>         and slave.\n>          \n>         So can we use the `rsync --bwlimit=${bandwidth} src dst`\n>         command instead of `cp src dst` while copy_image in\n>         create_image() of libvirt driver, the remote image copy\n>         operation also can be limited by `rsync --bwlimit=\n>         ${bandwidth}` or `scp -l=${bandwidth}`, this parameter\n>         ${bandwidth} can be a new configuration in nova.conf which\n>         allow cloud admin to config it, it\'s default value is 0 which\n>         means no limitation, then the instances on this host will be\n>         not affected while a new instance with not cached image is\n>         creating.\n>          \n>         the example codes:\n>         nova/virt/libvit/utils.py:\n>         diff --git a/nova/virt/libvirt/utils.py\n>         b/nova/virt/libvirt/utils.py\n>         index e926d3d..5d7c935 100644\n>         --- a/nova/virt/libvirt/utils.py\n>         +++ b/nova/virt/libvirt/utils.py\n>         @@ -473,7 +473,10 @@ def copy_image(src, dest, host=None):\n>                  # sparse files.  I.E. holes will not be written to\n>         DEST,\n>                  # rather recreated efficiently.  In addition, since\n>                  # coreutils 8.11, holes can be read efficiently too.\n>         -        execute(\'cp\', src, dest)\n>         +        if CONF.mbps_in_copy_image > 0:\n>         +            execute(\'rsync\', \'--bwlimit=%s\' %\n>         CONF.mbps_in_copy_image * 1024, src, dest)\n>         +        else:\n>         +            execute(\'cp\', src, dest)\n>              else:\n>                  dest = \"%s:%s\" % (host, dest)\n>                  # Try rsync first as that can compress and create\n>         sparse dest files.\n>         @@ -484,11 +487,22 @@ def copy_image(src, dest, host=None):\n>                      # Do a relatively light weight test first, so\n>         that we\n>                      # can fall back to scp, without having run out of\n>         space\n>                      # on the destination for example.\n>         -            execute(\'rsync\', \'--sparse\', \'--compress\',\n>         \'--dry-run\', src, dest)\n>         +            if CONF.mbps_in_copy_image > 0:\n>         +                execute(\'rsync\', \'--sparse\', \'--compress\',\n>         \'--dry-run\',\n>         +                        \'--bwlimit=%s\' %\n>         CONF.mbps_in_copy_image * 1024, src, dest)\n>         +            else:\n>         +                execute(\'rsync\', \'--sparse\', \'--compress\',\n>         \'--dry-run\', src, dest)\n>                  except processutils.ProcessExecutionError:\n>         -            execute(\'scp\', src, dest)\n>         +            if CONF.mbps_in_copy_image > 0:\n>         +                execute(\'scp\', \'-l\', \'%s\' %\n>         CONF.mbps_in_copy_image * 1024 * 8, src, dest)\n>         +            else:\n>         +                execute(\'scp\', src, dest)\n>                  else:\n>         -            execute(\'rsync\', \'--sparse\', \'--compress\', src,\n>         dest)\n>         +            if CONF.mbps_in_copy_image > 0:\n>         +                execute(\'rsync\', \'--sparse\', \'--compress\',\n>         +                        \'--bwlimit=%s\' %\n>         CONF.mbps_in_copy_image * 1024, src, dest)\n>         +            else:\n>         +                execute(\'rsync\', \'--sparse\', \'--compress\',\n>         src, dest)\n>          \n>          \n>         2014-02-14\n>         \n>         ______________________________________________________________\n>         Wangpan\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CANWE-CmwxjKAcx04n3o1+fyEX3CQwchZ7_U35ZfMwyvknWR35A@mail.gmail.com>',NULL),('<1392427898.24912.31.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-14 20:31:38',-18000,'2014-02-15 01:31:38',NULL,'[OpenStack-Infra] Running devstack in a Jenkins job within an LXC\n	container','Hi Dean, Infra-team,\n\nI\'ve been trying to get full Tempest test runs on Jenkins slave nodes in\nan external testing system [1]\n\nThe slave nodes are running in LXC containers on my workstation, but I\nam getting odd errors about halfway through the execution of stack.sh\nduring the job run.\n\nHere is the console output from the Jenkins job in question [2]:\n\nhttp://paste.openstack.org/show/65632/\n\nAt the end you will note something about leaked file descriptors. I\'m\nnot sure if this is actually the cause of the failure of the job or not,\nand I\'m hoping you might have seen this before and have some ideas on\nworkarounds?\n\nAll the best, and thanks in advance for any thoughts,\n-jay\n\n[1]\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n[2] Job definition:\nhttps://github.com/jaypipes/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/sandbox.yaml#L14\n\n\n\n',NULL,NULL),('<1392431281.882175738@f406.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-15 06:28:01',14400,'2014-02-15 02:28:01',NULL,'[Openstack] best single node install tutorial',' I suggest take a look at this one, it\'s well organized:\n\nhttps://github.com/fornyx/OpenStack-Havana-Install-Guide/blob/master/OpenStack-Havana-Install-Guide.rst\n\n\n\n???????, 14 ??????? 2014, 14:12 -05:00 ?? Aryeh Friedman <aryeh.friedman at gmail.com>:\n>I am writing a set of tutorials on how to install open stack on VM\'s, which due to cloud foundation layer we are using can run on real hardware after the tutorial is complete (devstack, single node, multi-node and small deployed clouds).?? Since I am not the best at writing instructional guides I wonder if someone can point me to a good single node tutorial (for installing OpenStack -- not just DevStack -- on a single physical machine) so I can get some ideas on how to word stuff clearly.\n>\n>-- \n>Aryeh M. Friedman, Lead Developer,  http://www.PetiteCloud.org\n>_______________________________________________\n>Mailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to     :  openstack at lists.openstack.org\n>Unsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n-- \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140215/7591cddf/attachment.html>\n\n','<CAGBxaXm8BjtH4YdKErnvOZuvSuvi-=-jQnz7xOjAVox02GyXcA@mail.gmail.com>',NULL),('<1392465228.29.1387087416383.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:03:36',0,'2013-12-15 06:03:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-docs-grizzly #3','See <https://jenkins02.openstack.org/job/periodic-cinder-docs-grizzly/3/>\n\n------------------------------------------\n[...truncated 103 lines...]\nGenerating doc/source/api/cinder.api.xmlutil.rst\nGenerating doc/source/api/cinder.backup.api.rst\nGenerating doc/source/api/cinder.backup.manager.rst\nGenerating doc/source/api/cinder.backup.rpcapi.rst\nGenerating doc/source/api/cinder.backup.services.swift.rst\nGenerating doc/source/api/cinder.common.sqlalchemyutils.rst\nGenerating doc/source/api/cinder.compute.aggregate_states.rst\nGenerating doc/source/api/cinder.context.rst\nGenerating doc/source/api/cinder.db.api.rst\nGenerating doc/source/api/cinder.db.base.rst\nGenerating doc/source/api/cinder.db.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.api.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.001_cinder_init.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.002_quota_class.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.003_glance_metadata.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.004_volume_type_to_uuid.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.005_add_source_volume_column.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.006_snapshots_add_provider_location.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.007_add_volume_snapshot_fk.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.008_add_backup.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migrate_repo.versions.009_add_snapshot_metadata_table.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.migration.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.models.rst\nGenerating doc/source/api/cinder.db.sqlalchemy.session.rst\nGenerating doc/source/api/cinder.exception.rst\nGenerating doc/source/api/cinder.flags.rst\nGenerating doc/source/api/cinder.image.glance.rst\nGenerating doc/source/api/cinder.image.image_utils.rst\nGenerating doc/source/api/cinder.manager.rst\nGenerating doc/source/api/cinder.openstack.common.context.rst\nGenerating doc/source/api/cinder.openstack.common.exception.rst\nGenerating doc/source/api/cinder.openstack.common.excutils.rst\nGenerating doc/source/api/cinder.openstack.common.fileutils.rst\nGenerating doc/source/api/cinder.openstack.common.gettextutils.rst\nGenerating doc/source/api/cinder.openstack.common.importutils.rst\nGenerating doc/source/api/cinder.openstack.common.jsonutils.rst\nGenerating doc/source/api/cinder.openstack.common.local.rst\nGenerating doc/source/api/cinder.openstack.common.lockutils.rst\nGenerating doc/source/api/cinder.openstack.common.log.rst\nGenerating doc/source/api/cinder.openstack.common.network_utils.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.api.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/cinder.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/cinder.openstack.common.policy.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.filters.rst\nGenerating doc/source/api/cinder.openstack.common.rootwrap.wrapper.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.common.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.matchmaker_redis.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/cinder.openstack.common.rpc.service.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.availability_zone_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.capabilities_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.extra_specs_ops.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.filters.json_filter.rst\nGenerating doc/source/api/cinder.openstack.common.scheduler.weight.rst\nGenerating doc/source/api/cinder.openstack.common.setup.rst\nGenerating doc/source/api/cinder.openstack.common.strutils.rst\nGenerating doc/source/api/cinder.openstack.common.timeutils.rst\nGenerating doc/source/api/cinder.openstack.common.uuidutils.rst\nGenerating doc/source/api/cinder.openstack.common.version.rst\nGenerating doc/source/api/cinder.policy.rst\nGenerating doc/source/api/cinder.quota.rst\nGenerating doc/source/api/cinder.scheduler.chance.rst\nGenerating doc/source/api/cinder.scheduler.driver.rst\nGenerating doc/source/api/cinder.scheduler.filter_scheduler.rst\nGenerating doc/source/api/cinder.scheduler.filters.capacity_filter.rst\nGenerating doc/source/api/cinder.scheduler.filters.retry_filter.rst\nGenerating doc/source/api/cinder.scheduler.host_manager.rst\nGenerating doc/source/api/cinder.scheduler.manager.rst\nGenerating doc/source/api/cinder.scheduler.rpcapi.rst\nGenerating doc/source/api/cinder.scheduler.scheduler_options.rst\nGenerating doc/source/api/cinder.scheduler.simple.rst\nGenerating doc/source/api/cinder.scheduler.weights.capacity.rst\nGenerating doc/source/api/cinder.service.rst\nGenerating doc/source/api/cinder.test.rst\nGenerating doc/source/api/cinder.tests.api.common.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_admin_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_backups.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_extended_snapshot_attributes.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_hosts.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_services.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_types_manage.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_actions.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_host_attribute.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_image_metadata.rst\nGenerating doc/source/api/cinder.tests.api.contrib.test_volume_tenant_attribute.rst\nGenerating doc/source/api/cinder.tests.api.extensions.foxinsocks.rst\nGenerating doc/source/api/cinder.tests.api.fakes.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_auth.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_faults.rst\nGenerating doc/source/api/cinder.tests.api.middleware.test_sizelimit.rst\nGenerating doc/source/api/cinder.tests.api.openstack.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_common.rst\nGenerating doc/source/api/cinder.tests.api.test_extensions.rst\nGenerating doc/source/api/cinder.tests.api.test_router.rst\nGenerating doc/source/api/cinder.tests.api.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.api.test_xmlutil.rst\nGenerating doc/source/api/cinder.tests.api.v1.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volume_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v1.test_volumes.rst\nGenerating doc/source/api/cinder.tests.api.v2.stubs.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_limits.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshot_metadata.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_snapshots.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_types.rst\nGenerating doc/source/api/cinder.tests.api.v2.test_volumes.rst\nGenerating doc/source/api/cinder.tests.backup.fake_service.rst\nGenerating doc/source/api/cinder.tests.backup.fake_swift_client.rst\nGenerating doc/source/api/cinder.tests.db.fakes.rst\nGenerating doc/source/api/cinder.tests.declare_flags.rst\nGenerating doc/source/api/cinder.tests.fake_driver.rst\nGenerating doc/source/api/cinder.tests.fake_flags.rst\nGenerating doc/source/api/cinder.tests.fake_utils.rst\nGenerating doc/source/api/cinder.tests.glance.stubs.rst\nGenerating doc/source/api/cinder.tests.image.fake.rst\nGenerating doc/source/api/cinder.tests.image.test_glance.rst\nGenerating doc/source/api/cinder.tests.integrated.api.client.rst\nGenerating doc/source/api/cinder.tests.integrated.integrated_helpers.rst\nGenerating doc/source/api/cinder.tests.integrated.test_extensions.rst\nGenerating doc/source/api/cinder.tests.integrated.test_login.rst\nGenerating doc/source/api/cinder.tests.integrated.test_volumes.rst\nGenerating doc/source/api/cinder.tests.integrated.test_xml.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_a.rst\nGenerating doc/source/api/cinder.tests.monkey_patch_example.example_b.rst\nGenerating doc/source/api/cinder.tests.runtime_flags.rst\nGenerating doc/source/api/cinder.tests.scheduler.fakes.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_capacity_weigher.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_filter_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_filters.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_host_manager.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_rpcapi.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler.rst\nGenerating doc/source/api/cinder.tests.scheduler.test_scheduler_options.rst\nGenerating doc/source/api/cinder.tests.test_HpSanISCSIDriver.rst\nGenerating doc/source/api/cinder.tests.test_api.rst\nGenerating doc/source/api/cinder.tests.test_backup.rst\nGenerating doc/source/api/cinder.tests.test_backup_swift.rst\nGenerating doc/source/api/cinder.tests.test_context.rst\nGenerating doc/source/api/cinder.tests.test_coraid.rst\nGenerating doc/source/api/cinder.tests.test_drivers_compatibility.rst\nGenerating doc/source/api/cinder.tests.test_emc.rst\nGenerating doc/source/api/cinder.tests.test_exception.rst\nGenerating doc/source/api/cinder.tests.test_flags.rst\nGenerating doc/source/api/cinder.tests.test_glusterfs.rst\nGenerating doc/source/api/cinder.tests.test_hp3par.rst\nGenerating doc/source/api/cinder.tests.test_huawei.rst\nGenerating doc/source/api/cinder.tests.test_iscsi.rst\nGenerating doc/source/api/cinder.tests.test_migrations.rst\nGenerating doc/source/api/cinder.tests.test_misc.rst\nGenerating doc/source/api/cinder.tests.test_netapp.rst\nGenerating doc/source/api/cinder.tests.test_netapp_nfs.rst\nGenerating doc/source/api/cinder.tests.test_nexenta.rst\nGenerating doc/source/api/cinder.tests.test_nfs.rst\nGenerating doc/source/api/cinder.tests.test_policy.rst\nGenerating doc/source/api/cinder.tests.test_quota.rst\nGenerating doc/source/api/cinder.tests.test_rbd.rst\nGenerating doc/source/api/cinder.tests.test_scality.rst\nGenerating doc/source/api/cinder.tests.test_service.rst\nGenerating doc/source/api/cinder.tests.test_sheepdog.rst\nGenerating doc/source/api/cinder.tests.test_skip_examples.rst\nGenerating doc/source/api/cinder.tests.test_solidfire.rst\nGenerating doc/source/api/cinder.tests.test_storwize_svc.rst\nGenerating doc/source/api/cinder.tests.test_test.rst\nGenerating doc/source/api/cinder.tests.test_test_utils.rst\nGenerating doc/source/api/cinder.tests.test_utils.rst\nGenerating doc/source/api/cinder.tests.test_volume.rst\nGenerating doc/source/api/cinder.tests.test_volume_configuration.rst\nGenerating doc/source/api/cinder.tests.test_volume_glance_metadata.rst\nGenerating doc/source/api/cinder.tests.test_volume_rpcapi.rst\nGenerating doc/source/api/cinder.tests.test_volume_types.rst\nGenerating doc/source/api/cinder.tests.test_volume_types_extra_specs.rst\nGenerating doc/source/api/cinder.tests.test_volume_utils.rst\nGenerating doc/source/api/cinder.tests.test_windows.rst\nGenerating doc/source/api/cinder.tests.test_wsgi.rst\nGenerating doc/source/api/cinder.tests.test_xenapi_sm.rst\nGenerating doc/source/api/cinder.tests.test_xiv.rst\nGenerating doc/source/api/cinder.tests.test_zadara.rst\nGenerating doc/source/api/cinder.tests.utils.rst\nGenerating doc/source/api/cinder.tests.windows.basetestcase.rst\nGenerating doc/source/api/cinder.tests.windows.db_fakes.rst\nGenerating doc/source/api/cinder.tests.windows.mockproxy.rst\nGenerating doc/source/api/cinder.tests.windows.windowsutils.rst\nGenerating doc/source/api/cinder.utils.rst\nGenerating doc/source/api/cinder.version.rst\nGenerating doc/source/api/cinder.volume.api.rst\nGenerating doc/source/api/cinder.volume.configuration.rst\nGenerating doc/source/api/cinder.volume.driver.rst\nGenerating doc/source/api/cinder.volume.drivers.coraid.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_common.rst\nGenerating doc/source/api/cinder.volume.drivers.emc.emc_smis_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.glusterfs.rst\nGenerating doc/source/api/cinder.volume.drivers.huawei.huawei_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.lvm.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.api.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.netapp.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.jsonrpc.rst\nGenerating doc/source/api/cinder.volume.drivers.nexenta.volume.rst\nGenerating doc/source/api/cinder.volume.drivers.nfs.rst\nGenerating doc/source/api/cinder.volume.drivers.rbd.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_common.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_fc.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp.hp_3par_iscsi.rst\nGenerating doc/source/api/cinder.volume.drivers.san.hp_lefthand.rst\nGenerating doc/source/api/cinder.volume.drivers.san.san.rst\nGenerating doc/source/api/cinder.volume.drivers.san.solaris.rst\nGenerating doc/source/api/cinder.volume.drivers.scality.rst\nGenerating doc/source/api/cinder.volume.drivers.sheepdog.rst\nGenerating doc/source/api/cinder.volume.drivers.solidfire.rst\nGenerating doc/source/api/cinder.volume.drivers.storwize_svc.rst\nGenerating doc/source/api/cinder.volume.drivers.windows.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.lib.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.sm.rst\nGenerating doc/source/api/cinder.volume.drivers.xenapi.tools.rst\nGenerating doc/source/api/cinder.volume.drivers.xiv.rst\nGenerating doc/source/api/cinder.volume.drivers.zadara.rst\nGenerating doc/source/api/cinder.volume.iscsi.rst\nGenerating doc/source/api/cinder.volume.manager.rst\nGenerating doc/source/api/cinder.volume.rpcapi.rst\nGenerating doc/source/api/cinder.volume.utils.rst\nGenerating doc/source/api/cinder.volume.volume_types.rst\nGenerating doc/source/api/cinder.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-cinder-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-cinder-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise24\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-docs-grizzly/precise24/3\n[SCP] Copying console log.\n\n\n','<871782136.17.1387000979842.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1392501941-sup-8078@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 14:11:43',-28800,'2014-02-15 22:11:43',NULL,'[openstack-dev] [Openstack-operators] [TripleO] consistency vs\n	packages in TripleO','Excerpts from Dan Prince\'s message of 2014-02-15 06:05:30 -0800:\n> \n> ----- Original Message -----\n> > From: \"Robert Collins\" <robertc at robertcollins.net>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> > Cc: openstack-operators at lists.openstack.org\n> > Sent: Friday, February 14, 2014 11:12:12 PM\n> > Subject: Re: [Openstack-operators] [openstack-dev] [TripleO] consistency vs    packages in TripleO\n> > \n> > Currently we have two options for upgrading images. A) /mnt/state, B)\n> > a SAN + cinder. We haven\'t tested B), and I expect for many installs B\n> > won\'t be an option. /mnt/state is 100% technical, as no other options\n> > exist - none of the Linux distro \'read only root\' answers today answer\n> > the problem /mnt/state solves in a way compatible with Nova.\n> \n> I would argue that we haven\'t tried all of the read only root mechanism\n> either... at least to the point where we can definitely don\'t work. Sure\n> the data has to go somewhere... but it is how we present this to the\n> end user that is the point in this thread, no?\n> \n> All I\'m arguing for here is the ability to avoid doing this to our nova.conf file (what we do today in TripleO):\n> \n>  state_path=/mnt/state/var/lib/nova\n> \n> And instead simply use the Nova default (/var/lib/nova) and have some\n> other mechanism take care of the mapping for us (bind mounts, etc). In\n> the context of end user documentation I certainly think this has less\n> of an impact and is more pleasing to all.\n> \n\nCould I divert you a bit into explaining what other readonly root schemes\nexist? I\'ve not looked into them very much as none seemed \"simple\" to\nme when you consider that things like /var/lib/dpkg are intended to be\nreadonly parts of the image.\n\nI\'ll start by saying that I\'m very suspicious of any mechanism which tries\nto intermix writable data with readonly data. A TripleO user needs only\nlearn once that \"/mnt is preserved, everything else is not\". It is also\nextremely discoverable. So I am quite curious to hear what alternative\nwe could use that would make this simpler.\n\n\n','<1393195817.6754205.1392473130450.JavaMail.zimbra@redhat.com>',NULL),('<1392502357-sup-9185@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 14:25:39',-28800,'2014-02-15 22:25:39',NULL,'[openstack-dev] [TripleO] consistency vs packages in TripleO','Excerpts from James Slagle\'s message of 2014-02-15 13:02:36 -0800:\n> On Fri, Feb 14, 2014 at 11:12 PM, Robert Collins\n> <robertc at robertcollins.net> wrote:\n> > On 15 February 2014 08:42, Dan Prince <dprince at redhat.com> wrote:\n> >>\n> >\n> >> Option B is we make our job easy by strong arming everyone into the same defaults of our \"upstream\" choosing.\n> >\n> > Does Nova strong arm everyone into using kvm? Its the default. Or\n> > keystone into using the SQL token store - its the default?\n> >\n> > No - defaults are not strong arming. But the defaults are obviously\n> > defaults, and inherited by downstreams. And some defaults are larger\n> > than others -  we\'ve got well defined interfaces in OpenStack, which\n> > have the primary characteristic of \'learn once, apply everywhere\' -\n> > even though in principle you can replace them. At the low level REST\n> > and message-bus RPCs, at a level up Keystone and more recently Nova\n> > and Neutron have become that as we get higher order code like Heat and\n> > Savanna that depend on them. I hope none would replace Nova with\n> > Eucalyptus and then say they\'re running OpenStack - in the same way\n> > we\'re both defining defaults, *and* building interfaces. *That* is our\n> > job - making OpenStack *upstream* deployable, in the places, and on\n> > the platforms, with the options, that our users want.\n> >\n> > Further to that, upstream we\'re making choices with the thoughts of\n> > our *users* in mind - both cloud consumers and cloud operators. They\n> > are why we ask questions like \'is having every install have\n> > potentially different usernames for the nova service a good idea\'. The\n> > only answer so far has been \'because distros have chosen different\n> > usernames already and we need to suck it up\'. Thats not a particularly\n> > satisfying answer.\n> \n> It seems we\'re talking defaults now. I did not get that from the email\n> that started the discussion, it sounded like an \"either or\" to me.\n> \n> So, if we\'re talking defaults, let the upstream architecture be the\n> default. Let your #A be a choice. If someone wants to come along and\n> do #B, we let them, but I really don\'t think you\'d fine anyone :).\n> \n> We question and we challenge new implementations (just like we always\n> do and as you\'re doing here, which is good).  But at the end of day if\n> someone is saying they have a real documented need in order for them\n> to adopt OpenStack, and it makes sense for that option to be \"in tree\"\n> for OpenStack,  we empower them by having a flexible framework, and\n> hopefully our tools are good enough to handle what differences there\n> are. If not, we make them better.\n> \n> I\'m not sure I entirely get the comparisons to Nova you\'re making. Let\n> me take a shot though and try to further it along as I see it:\n> \n> Let the dib style element be the \"API\". What the implementation is,\n> whether a source install or a package install shouldn\'t affect the\n> interface. And there\'s no reason to \"coerce\" all the implementations\n> to be exactly the same.\n> \n> The Nova virt drivers (libvirt/kvm, libvirt/xen, xenapi, etc) are our\n> different install types today, source-install, package-install. Our\n> different install type implementations still conform to the framework,\n> our install scripts have to be in the right place, we make use of\n> install-packages, we use os-svc-*, we use os-*-config, etc. Just like\n> the python code for each Nova virt driver has requirements (the\n> correct base class inheritance, methods, etc).\n> \n> However, Nova makes no enforcement of how each driver is *actually*\n> implemented. It doesn\'t particularly care about what\'s happening in\n> each driver\'s power_on method.  It doesn\'t enforce that all\n> hypervisors kernel modules are called the same thing so that it\'s\n> easier to check if you loaded the right one. No one said that we can\'t\n> have a Nova baremetal driver b/c what if someone drops down to the\n> console to troubleshoot and they run \"virsh list\" and don\'t see\n> baremetal instances.  Coercing the implementation to be the same just\n> doesn\'t make sense to me, and I think where this comparison you\'re\n> making really breaks down.\n> \n> The abstracting away of the hypervisor differences happens in the virt\n> drivers. For TripleO\'s purposes, the abstracting away of the install\n> type particularities should happen by the install and setup code. Not\n> by trying to coerce things to look the same after the fact, which\n> sounds to me exactly like what Nova *doesn\'t* do and require.\n> \n> >> Take /mnt/state for example. This isn\'t the normal place for things to live. Why not use the read only root mechanism some distributions already have and work with that instead. Or perhaps have /mnt/state as a backup solution which can be used if a mechanism doesn\'t exist or is faulty?\n> >\n> > Currently we have two options for upgrading images. A) /mnt/state, B)\n> > a SAN + cinder. We haven\'t tested B), and I expect for many installs B\n> > won\'t be an option. /mnt/state is 100% technical, as no other options\n> > exist - none of the Linux distro \'read only root\' answers today answer\n> > the problem /mnt/state solves in a way compatible with Nova.\n> >\n> >> In the end I think option A is the way we have to go. Is it more work... maybe. But in the end users will like us for it. And there is always the case that by not reimplementing some of the tools and mechanisms which already exist in distros that this ends up being less work anyways. I do hope so...\n> >\n> > Certainly we\'re trying very hard to keep things we reimplement minimal\n> > and easily swap-outable (like o-r-c which I expect some deployments\n> > will want to replace with chef/puppet).\n> \n> As I said above, the swap-outable defaults is what I think is the real key here.\n> \n> We work hard to have a great upstream architecture, but we allow for\n> variation with opt-in and opt-out. It doesn\'t necessarily mean that\n> all variants have to be in the openstack TripleO git repos. But, where\n> there\'s a cross section of folks wanting a particular variant, and\n> there\'s people in the community volunteering to do the work and\n> support it, I think it makes sense to consider those variants on their\n> individual merits.\n> \n> /mnt/state is a great example of that. There was nothing consistent\n> across distros, so TripleO did it\'s own relatively straightforward\n> implementation that could be used on any distro. But, TripleO\n> shouldn\'t necessarily *enforce* that it\'s used. It doesn\'t have to be\n> an all-or-nothing  type approach IMO.\n> \n\nAll of the above is well said. I agree that there should not be\nenforcement. I think what Robert and I are concerned about is that the\nmore we have to divert attention away from the core architecture into\nmodularizing for alternatives, the less velocity we will have.\n\nIt is important to make sure we\'re empowering support organizations to\nwork today, and not making them retool everything too. The balancing\nact of \"success today\" versus \"healthy ecosystem\" is non-trivial, but\nwe should definitely make sure we\'re doing what is best for the greater\necosystem at all times. Having too much modularity will just encourage\ndifferentiation at a level that slows overall adoption due to market\nconfusion.\n\nTo contrast with earlier parts of our industry, commodity PC\'s didn\'t\nsucceed because Compaq\'s PC\'s were different from IBM\'s. They succeeded\nbecause they were nearly identical, but differentiated on price and\nquality. Users had less confusion, more things \"known\" about the product,\nand thus built more dependence on the platform. That sounds like exactly\nwhat we want with OpenStack.\n\n\n','<CAHV77z9H_KYoWP=i-BVX44k--z0YAVVjXbW-Visxstg_-Kmn+Q@mail.gmail.com>',NULL),('<1392504455-sup-9685@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 14:48:03',-28800,'2014-02-15 22:48:03',NULL,'[openstack-dev] [Murano] Need a new DSL for Murano','Excerpts from Alexander Tivelkov\'s message of 2014-02-14 18:17:10 -0800:\n> Hi folks,\n> \n> Murano matures, and we are getting more and more feedback from our early\n> adopters. The overall reception is very positive, but at the same time\n> there are some complaints as well. By now the most significant complaint is\n> is hard to write workflows for application deployment and maintenance.\n> \n> Current version of workflow definition markup really have some design\n> drawbacks which limit its potential adoption. They are caused by the fact\n> that it was never intended for use for Application Catalog use-cases.\n> \n\nJust curious, is there any reason you\'re not collaborating on Mistral\nfor this rather than both having a workflow engine?\n\n\n','<CAM6FM9RTyJgo5jnT=BgFhXQgkV9wYRMfMy0QMLgWBt4G-6SW-w@mail.gmail.com>',NULL),('<1392526651.24912.48.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 23:57:31',-18000,'2014-02-16 04:57:31',NULL,'[openstack-dev] [Solum] Question about Zuul\'s role in Solum','On Sat, 2014-02-15 at 17:20 +1300, Robert Collins wrote:\n> On 15 February 2014 14:34, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:\n> > I think a lot of projects don\'t bother to gate, because its far to much work to set up a workable system.\n> >\n> > I can think of several projects I\'ve worked on that would benefit from it but haven\'t because of time/cost of setting it up.\n> >\n> > If I could just say \"solum create project foo\" and get it, I\'m sure it would be much more used.\n> >\n> > The same has been said of Unit tests and CI in the past. \"We don\'t need it\". When you give someone a simple to use system though, they see its value pretty quickly.\n> >\n> > Yeah, gerrit and jenkins are a pain to setup. Thats one of the things that might make solum great. That it removes that pain.\n> \n> Gating is hard, so we should do more of it.\n> \n> +1 on gating by default, rather than being nothing more than a remote\n> git checkout - there are lots of those systems already, and being one\n> won\'t make solum stand out,.\n\nPersonally, I believe having Gerrit and Jenkins as the default will turn\nmore people off Solumn than attract them to it.\n\nJust because we in the OpenStack community love our gating workflow and\nthink it\'s all groovy does not mean that view is common, wanted, or\nunderstood by the vast majority of users of Heroku-like solutions.\n\nWho is the audience here? It is not experienced developers who already\nunderstand things like Gerrit and Jenkins. It\'s developers who just want\nto simplify the process of pushing code up to some system other than\nGithub or their workstation. Adding the awkwardness of Gerrit\'s code\nreview system -- and the associated pain of trying to understand how to\ndefine Jenkins jobs -- is something that I don\'t think the *default*\nSolum experience should invite.\n\nThe default experience should be a simple push code, run merge tests,\nand deploy into the deployment unit (whatever that is called in Solum\nnowadays). There should be well-documented ways to add commit hooks into\nthis workflow, but having a complex Gerrit and Jenkins gated workflow is\njust overkill for the default experience.\n\nBest,\n-jay\n\n\n\n','<CAJ3HoZ0FboqzJrjDnHBoKgf7CFcvWfGHeKhR+GRDOFoiPSy2tg@mail.gmail.com>',NULL),('<1392581899.24912.55.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-16 15:18:19',-18000,'2014-02-16 20:18:19',NULL,'[OpenStack-Infra] Running devstack in a Jenkins job within an\n LXC container','On Mon, 2014-02-17 at 08:16 +1300, Robert Collins wrote:\n> On 15 February 2014 14:43, Jeremy Stanley <fungi at yuggoth.org> wrote:\n> > On 2014-02-14 20:31:38 -0500 (-0500), Jay Pipes wrote:\n> > [...]\n> >> At the end you will note something about leaked file descriptors. I\'m\n> >> not sure if this is actually the cause of the failure of the job or not,\n> > [...]\n> >\n> > That\'s typical. Jenkins thinks it should warn you if your job\n> > creates any files outside the workspace since it assumes anything\n> > leaking out of that sandboxed area might be unintended. Pretty much\n> > all of DevStack operates outside the workspace, so it\'s just\n> > something we generally ignore in the output.\n> >\n> > Chances are something returned a nonzero, probably the apt-get\n> > install command. Note that open-iscsi failed to start, resulting in\n> > \"dpkg: error processing open-iscsi (--configure): subprocess\n> > installed post-installation script returned error exit status 1\". In\n> > cases like these, apt-get will continue to process the remaining\n> > packages but then return with a nonzero exit code once it\'s done.\n> \n> This may be of interest:\n> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855\n> \n> tl;dr - it\'s currently impossible to run a bunch of necessary commands\n> in a full lxc container - you need to expose non-namespaced things.\n\nThanks, Rob (and Chuck Short) for your links to LXC-related oddities. I\nwill read through those links and see if I can make progress. If not, no\nprobs, I\'ll just switch to a non-shared-kernel VM.\n\nBest,\n-jay\n\n\n\n','<CAJ3HoZ2HT2Tapuwjs-U1t-2bac6f1vAhfK-qG7DFP2hC2Ojd+w@mail.gmail.com>',NULL),('<1392614262.29597.25.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 15:17:42',36000,'2014-02-17 05:17:42',NULL,'[openstack-dev] Version Discovery Standardization','On Thu, 2014-02-13 at 19:35 -0700, Christopher Yeoh wrote:\n> On Thu, 13 Feb 2014 21:10:01 -0500\n> Sean Dague <sean at dague.net> wrote:\n> > On 02/13/2014 08:28 PM, Christopher Yeoh wrote:\n> > > On Thu, 13 Feb 2014 15:54:23 -0500\n> > > Sean Dague <sean at dague.net> wrote:\n> \n> > > \n> > > So one question I have around a global version is what happens when\n> > > we have the following situation:\n> > > \n> > > - Extension (not core) A is bumped to version 3, global version\n> > > bumped to 3.01\n> > > - Extension B (not core) is bumped to version 6, global version\n> > > bumped to 3.02\n> > > \n> > > but the deployer for $REASONS (perhaps stability/testing/whatever)\n> > > really wants to deploy with version 2 of A but version 6 of B. \n> > > \n> > > With versioning just on the extensions individually they\'re ok, but\n> > > I don\'t think there\'s any real sane way to get a global micro\n> > > version calculated for this scenario that makes sense to the end\n> > > user.\n> > \n> > So there remains a question about extensions vs. global version. I\n> > think a big piece of this is anything which is a \"core\" extension,\n> \n> So to reduce confusion I\'ve been trying to introduce the nomenclature of\n> everything is a plugin. And then some plugins are compulsory (eg\n> \"core\") and others are optional (\"extensions\")\n> \n> > stops getting listed as an extension and instead is part of properly\n> > core and using the global version.\n> > \n> > How extensions impact global version is I think an open question. But\n> > Nova OS API is actually really weird if you think about it relative to\n> > other cloud APIs (ec2, gce, softlayer). We\'ve defined it not as the\n> > Nova API, but as a small core compute API, and many dozens optional\n> > features, which every deployer makes decisions on what comes and goes.\n> > \n> > I agree we need to think through a few things. But I think that if we\n> > get to v3, only to have to do a ton more stuff for v4, and take 2 more\n> > years to get there, we\'re in a world of hurt. The current model of API\n> > revisions as giant big bangs isn\'t good for any one. A way to make an\n> > API be able to grow over time, in a backwards compatible way, and some\n> > mechanism to deprecate and remove a feature over time would be much\n> > more advantageous to our consumers.\n> > \n> \n> I agree we don\'t want to avoid another big bang version change for as\n> long as we can. Given that we have extensions (and I know that some\n> people really don\'t like that) however I\'d be a lot more comfortable \n> if this minor global version was only bumped when there were changes to\n> the core plugins or a plugin was added to the core (I don\'t think we\n> can ever remove them from core within a major version). There should be\n> a high bar on making any changes to core plugins (even though\n> they are backwards compatible).\n> \n> I\'m also fine with core plugins not appearing in the /v3/extensions\n> list. Its a simple enough change and agree that it will reduce\n> confusion over interoperability between openstack clouds. \n> \n> Chris\n\nCaveat: IANAND (I am not a nova dev) and i\'m not familiar with nova\'s\nplugins so i\'m working with a standard definition of a plugin and define\nfor the rest of this email that: \n- An extension is something that adds paths or features to the API. \n- A plugin is code that is loaded to do some work.\n\nTo my mind talking of plugins is confusing the API with the\nimplementation. The sum total of the core plugins is the interface that\na project has to implement to be compatible with nova and is defined as\nthe core API. This API is the thing that we are versioning and that\nshould be done globally and semantically. If plugins are allowed to\ndirectly define the API and some combination of plugins is loaded that\ndoes not provided the API specified by the version then the server is in\nerror advertising that it supports that API version. \n\nAn extension provides additional methods or data to the API (whether\nthis is loaded via plugin or always available). Being that extensions\nare not covered by the API definition then they should provide there own\nversion discovery information. This means that an extension can define\nan interface and that can co-exist with any version of the core API\n(though i can definitely see the use case for this extension requires at\nleast this version of the API). By definition anything in the core API\nis not an extension and should not be listed as such.\n\nVersion discovery could be done for extensions either as a part of GET /\nbut i think it makes sense for that to be part of the project specific\nAPI (eg GET /v3/extensions) as that information may need to change in\nfuture API versions. Also this is kind of outside the scope of what we\nare talking about here. For now all we need is a way of determining core\nAPI versions and then extension discovery is a subset of that. \n\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<20140213193525.59a43fd6@pingu>',NULL),('<1392616430.29597.42.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 15:53:50',36000,'2014-02-17 05:53:50',NULL,'[openstack-dev] Version Discovery Standardization','On Thu, 2014-02-13 at 08:45 -0600, Dean Troyer wrote:\n> FWIW, an early proposal to address this, as well as capability\n> discovery, still lives\n> at https://etherpad.openstack.org/p/api-version-discovery-proposal.\n>  I\'ve lost track of where this went, and even which design summit this\n> is from, but I\'ve been using it as a sanity check for the discovery\n> bits in OSC.\n\nYes, i\'ve seen that one. It\'s more client side how we should work with\nit though. If we can standardize the server side response then the\nclient side becomes much more reusable. \n\n> \n> On Thu, Feb 13, 2014 at 6:50 AM, Jamie Lennox <jamielennox at redhat.com>\n> wrote:\n>         6. GET \'/\' is unrestricted. GET \'/vX\' is often token\n>         restricted.\n>         \n>         Keystone allows access to /v2.0 and /v3 but most services give\n>         a HTTP Unauthorized. This is a real problem for discovery\n>         because we need to be able to evaluate the endpoints in the\n>         service catalog. I think we need to make these unauthorized.\n> \n> \n> I agree, however from a client discovery process point-of-view, you do\n> not necessarily have an endpoint until after you auth and get a\n> service catalog anyway.  For example, in the specific case of\n> OpenStackClient Help command output, the commands listed may depend on\n> the desired API version.  To get the endpoints to query for version\n> support still requires a service catalog so nothing really changes\n> there.\n\nYes, i had thought of that afterward and we can send the token to the\nendpoint. From a standards document though it\'d be better if we didn\'t\nhave to. \n\n> And this doesn\'t even touch on the SC endpoints that include things\n> like tenant/project id...\n\nYuk. Yes, a problem with this is that entries in the service catalog\nthat have a project id in them don\'t currently present version\ninformation at that endpoint. I\'d be interested in fixing this but as\nit\'s going to need to be backwards compatible with the current state\nit\'s not really a priority. \n\n>         Please have a look over the wiki page and how it addresses the\n>         above and fits into the existing schemes and reply with any\n>         comments or problems that you see. Is this going to mess with\n>         any pre-existing clients?\n> \n> \n> * id: Let\'s either make this a real semantic version so we can parse\n> and use the major.minor.patch components (and dump the \'v\') or make it\n> an identifier that matches the URL path component.  Right now \n\nDo we need patch on API versions? I was aiming for standards rather than\nimprovement here but i guess this is the right time to fix something\nlike this.\n\n> * updated: I think it would be a friendly gesture to update this for\n> unstable changes as the id is likely to not be updated mid-stream.\n>  During debugging I would want to be able to verify exactly which\n> implementation I was talking to anyway.\n\nSo i was thinking the way to do that would be to define two endpoints eg\na stable v3.2 and an unstable v3.3 that reference the same endpoint. \n\n> \n> There are two transitional things to also consider:\n> \n> \n> * We have to produce a discovery mechanism that takes in to account\n> the historical authentication URLs published by deployments that\n> include a version.  ayoung\'s Ml thread last week discussed this a bit,\n> we should document the approaches that we\'re testing and why they do\n> or do not work.\n\nRight and we need another talk about this, but let\'s leave this about\ndefining a standard that new projects should adhere to and slowly moving\nthe existing ones.  \n\n> * There are real-world deployments that do not configure\n> admin_endpoint and/or public_endpoint in keystone.conf.  Discovery is\n> really useless if the URL you are given is\n> https://localhost:5000/v2.0.  Do we need to talk about another\n> horrible horrible hack to deal with these or are these deployments\n> going to be left out in the cold?\n\nRight, this is more infuriating with keystone that uses admin_url which\nis not defined as either public or internal. Which URL should be present\non that discover page? \n\n>From the server side to counter this i very specifically put a clause in\nthe wiki page to say that discover links can be relative and i\'ll change\nthat now to SHOULD be relative. This way a link is just defined as\n\"/v2.0\" and you can use whatever host got you to that point. The only\nproblem i see here is what is the relative \"self\" link from GET /v2.0\nshould it just be { \"rel\": \"self\", \"href\": \"\" }, is \"href\" excluded or\nNone?\n\nThe client side is going to be ugly again and we should talk but it\'s\noutside scope for this. \n\n> dt\n> \n> \n> -- \n> \n> Dean Troyer\n> dtroyer at gmail.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAOJFoEscM8r837L1zxULVkB5rKSy22XbrD=Nv4V+0D8Gnp08kw@mail.gmail.com>',NULL),('<1392616554.28930.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-17 13:55:54',28800,'2014-02-17 05:55:54',NULL,'[Openstack] problem in installing django-swiftbrowser','please someody reply\n\n\n\nOn Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>\n>\n>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>\n>\n>below are the steps which i follow:\n>-----------------\n>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>\n>\n>\n>Cloning into \'django-swiftbrowser\'...\n>remote: Reusing existing pack: 145, done.\n>remote: Total 145 (delta\n 0), reused 0 (delta 0)\n>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>Resolving deltas: 100% (72/72), done.\n>\n>\n>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>\n>\n>\n>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>Traceback (most recent call last):\n>? File \"setup.py\", line 2, in <module>\n>??? from setuptools import setup\n>ImportError: No module named setuptools\n>------------\n>\n>\n>But I get the error.\n>Please help inresolving the error.\n>\n>\n>Thanks in advance \n>\n>Pragya Jain\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140217/495876b8/attachment.html>\n\n','<1392114611.8525.YahooMailNeo@web193601.mail.sg3.yahoo.com>',NULL),('<1392617362.29597.54.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 16:09:22',36000,'2014-02-17 06:09:22',NULL,'[openstack-dev] Version Discovery Standardization','On Thu, 2014-02-13 at 08:37 -0500, Sean Dague wrote:\n> On 02/13/2014 07:50 AM, Jamie Lennox wrote:\n> > Hi all,\n> > \n> > I am one of i think a number of efforts trying to make clients be interoperable between different versions of an API.\n> > \n> > What i would like to talk about specifically here are the inconsistencies in the version listing of the different servers when you query the root GET \'/\' and GET \'/vX\' address for versions. This is a badly formatted sampling of the policies out there: http://paste.openstack.org/show/64770/\n> > \n> > This is my draft of a common solution https://wiki.openstack.org/wiki/VersionDiscovery which has some changes for everyone, but I at least hope can be a guide for new services and a target for the existing\n> > \n> > There are a number of major inconsistencies that i hope to address:\n> > \n> > 1. The \'status\' of an API. \n> > \n> > Keystone uses the word \'stable\' to indicate a stable API, there are a number of services using \'CURRENT\' and i\'m not sure what \'SUPPORTED\' is supposed to mean here. In general I think \'stable\' makes the most sense and in many ways keystone has to be the leader here as it is the first contact. Any ideas how to convert existing APIs to this scheme? \n> \n> From that link, only Keystone is different. Glance, Cinder, Neutron,\n> Nova all use CURRENT. So while not ideal, I\'m not sure why we\'d change\n> the rest of the world to match keystone, vs. changing keystone to match\n> the rest of the world.\n> \n> Also realize changing version discovery itself is an API change, so my\n> feeling is this should be done in the smallest number of places possible.\n\nSo firstly i absolutely agree that version discovery is an API change.\nMore that that it is the only API that we cannot version so we are stuck\nwith whatever we choose indefinitely. \n\nThe reason i suggested \'stable\' is because keystone is the point of\ncontact here. Theoretically ever other service could add a new route\n(eg /info) which defined whatever scheme we choose, and have the service\ncatalog point to that and there should be no difference in the\nexperience. Keystone is different in that it is always called and\nprobably the only client even attempting to do discovery at the moment.\n\nHaving said that we have the opportunity thanks to point 3 to add new\nendpoints without the \'values\' key that can follow the other examples. \n\nWhat i would then like to know is what are the definitions and priority\nof the \'CURRENT\' scheme? \'EXPERIMENTAL\' is somewhat obvious but what is\nthe difference between \'CURRENT\' and \'SUPPORTED\'? We need to define a\nstrict definition of what is allowed here, what values are considered\nstable vs unstable, and what is the priority ordering. \n\n> > 2. HTTP Status\n> > \n> > Some services are 200, some 300. It also doesn\'t matter how many responses there are in this status. \n> \n> Ideally - 300 should be returned if there are multiple versions, and 200\n> otherwise.\n\nStrictly speaking probably. I thought the 300 made some sense as\nrequests to this page are sort of like a directory where you choose\nwhere to go next, even if there is only one choice. Probably we should\njust return 200 all the time as it was a successful operation and we\naren\'t redirecting automatically. \n\n> > 3. Keystone uses [\'versions\'][\'values\']\n> > \n> > Yep. Not sure why that is. Sorry, we should be able to have a copy under \'values\' and one in the root \'versions\' simultaneously for a while and then drop the \'values\' in some future release. \n> \n> Again, keystone seems to be the odd man out here.\n> \n> > 4. Glance does a version entry for each minor version. \n> > \n> > Seperate entries for v2.2, v2.1, v2.0. They all point to the same place so IMO this is unnecessary. \n> \n> Probably agreed, curious if any Glance folks know of w reason for it.\n> \n> > 5. Differences between entry in GET \'/\' and GET \'/vX\'\n> > \n> > There is often a log more information in GET \'/vX\' like media-type that is not present in the root. I\'m not sure if this was on purpose but i think it easier (and less lookups) to have this information consistent.\n> \n> Agreed, I expect it\'s historical following of nova that media-type is\n> not in the root. I think it\'s fixable.\n> \n> > 6. GET \'/\' is unrestricted. GET \'/vX\' is often token restricted. \n> > \n> > Keystone allows access to /v2.0 and /v3 but most services give a HTTP Unauthorized. This is a real problem for discovery because we need to be able to evaluate the endpoints in the service catalog. I think we need to make these unauthorized.\n> \n> Agreed, however due to the way the wsgi stacks work in these projects,\n> this might not be trivial. I\'d set that as a goal to address.\n\nYes, this is something that will need to be supported for a long time\nanyway. This guide is as much as anything a reference for new projects\nfor what the best behaviour is so whilst we may not be able to address\nit for existing projects new projects should try to follow best\npractice. \n\n> > Please have a look over the wiki page and how it addresses the above and fits into the existing schemes and reply with any comments or problems that you see. Is this going to mess with any pre-existing clients?\n> > \n> > Then is there somewhere we can do \'new project guidelines\' that we can link this from?\n> > \n> > \n> > Jamie\n> > \n> > \n> > PS. This is the script I used for the sampling if you want to test yourself: http://paste.openstack.org/show/65015/ it makes assumptions on URL structures and it won\'t pass code review.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<52FCCA9D.3070404@dague.net>',NULL),('<1392622568.29597.58.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 17:36:08',36000,'2014-02-17 07:36:08',NULL,'[openstack-dev] Version Discovery Standardization','On Mon, 2014-02-17 at 16:09 +1000, Jamie Lennox wrote:\n> On Thu, 2014-02-13 at 08:37 -0500, Sean Dague wrote:\n> > On 02/13/2014 07:50 AM, Jamie Lennox wrote:\n> > > Hi all,\n> > > \n> > > I am one of i think a number of efforts trying to make clients be interoperable between different versions of an API.\n> > > \n> > > What i would like to talk about specifically here are the inconsistencies in the version listing of the different servers when you query the root GET \'/\' and GET \'/vX\' address for versions. This is a badly formatted sampling of the policies out there: http://paste.openstack.org/show/64770/\n> > > \n> > > This is my draft of a common solution https://wiki.openstack.org/wiki/VersionDiscovery which has some changes for everyone, but I at least hope can be a guide for new services and a target for the existing\n> > > \n> > > There are a number of major inconsistencies that i hope to address:\n> > > \n> > > 1. The \'status\' of an API. \n> > > \n> > > Keystone uses the word \'stable\' to indicate a stable API, there are a number of services using \'CURRENT\' and i\'m not sure what \'SUPPORTED\' is supposed to mean here. In general I think \'stable\' makes the most sense and in many ways keystone has to be the leader here as it is the first contact. Any ideas how to convert existing APIs to this scheme? \n> > \n> > From that link, only Keystone is different. Glance, Cinder, Neutron,\n> > Nova all use CURRENT. So while not ideal, I\'m not sure why we\'d change\n> > the rest of the world to match keystone, vs. changing keystone to match\n> > the rest of the world.\n> > \n> > Also realize changing version discovery itself is an API change, so my\n> > feeling is this should be done in the smallest number of places possible.\n> \n> So firstly i absolutely agree that version discovery is an API change.\n> More that that it is the only API that we cannot version so we are stuck\n> with whatever we choose indefinitely. \n> \n> The reason i suggested \'stable\' is because keystone is the point of\n> contact here. Theoretically ever other service could add a new route\n> (eg /info) which defined whatever scheme we choose, and have the service\n> catalog point to that and there should be no difference in the\n> experience. Keystone is different in that it is always called and\n> probably the only client even attempting to do discovery at the moment.\n> \n> Having said that we have the opportunity thanks to point 3 to add new\n> endpoints without the \'values\' key that can follow the other examples. \n> \n> What i would then like to know is what are the definitions and priority\n> of the \'CURRENT\' scheme? \'EXPERIMENTAL\' is somewhat obvious but what is\n> the difference between \'CURRENT\' and \'SUPPORTED\'? We need to define a\n> strict definition of what is allowed here, what values are considered\n> stable vs unstable, and what is the priority ordering. \n> \n> > > 2. HTTP Status\n> > > \n> > > Some services are 200, some 300. It also doesn\'t matter how many responses there are in this status. \n> > \n> > Ideally - 300 should be returned if there are multiple versions, and 200\n> > otherwise.\n> \n> Strictly speaking probably. I thought the 300 made some sense as\n> requests to this page are sort of like a directory where you choose\n> where to go next, even if there is only one choice. Probably we should\n> just return 200 all the time as it was a successful operation and we\n> aren\'t redirecting automatically. \n> \n> > > 3. Keystone uses [\'versions\'][\'values\']\n> > > \n> > > Yep. Not sure why that is. Sorry, we should be able to have a copy under \'values\' and one in the root \'versions\' simultaneously for a while and then drop the \'values\' in some future release. \n> > \n> > Again, keystone seems to be the odd man out here.\n> > \n> > > 4. Glance does a version entry for each minor version. \n> > > \n> > > Seperate entries for v2.2, v2.1, v2.0. They all point to the same place so IMO this is unnecessary. \n> > \n> > Probably agreed, curious if any Glance folks know of w reason for it.\n> > \n> > > 5. Differences between entry in GET \'/\' and GET \'/vX\'\n> > > \n> > > There is often a log more information in GET \'/vX\' like media-type that is not present in the root. I\'m not sure if this was on purpose but i think it easier (and less lookups) to have this information consistent.\n> > \n> > Agreed, I expect it\'s historical following of nova that media-type is\n> > not in the root. I think it\'s fixable.\n> > \n> > > 6. GET \'/\' is unrestricted. GET \'/vX\' is often token restricted. \n> > > \n> > > Keystone allows access to /v2.0 and /v3 but most services give a HTTP Unauthorized. This is a real problem for discovery because we need to be able to evaluate the endpoints in the service catalog. I think we need to make these unauthorized.\n> > \n> > Agreed, however due to the way the wsgi stacks work in these projects,\n> > this might not be trivial. I\'d set that as a goal to address.\n> \n> Yes, this is something that will need to be supported for a long time\n> anyway. This guide is as much as anything a reference for new projects\n> for what the best behaviour is so whilst we may not be able to address\n> it for existing projects new projects should try to follow best\n> practice. \n> \n> > > Please have a look over the wiki page and how it addresses the above and fits into the existing schemes and reply with any comments or problems that you see. Is this going to mess with any pre-existing clients?\n> > > \n> > > Then is there somewhere we can do \'new project guidelines\' that we can link this from?\n> > > \n> > > \n> > > Jamie\n> > > \n> > > \n> > > PS. This is the script I used for the sampling if you want to test yourself: http://paste.openstack.org/show/65015/ it makes assumptions on URL structures and it won\'t pass code review.\n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nDocument updated to reflect all above points and those made by Dean. I\nhaven\'t added anything about revisions as that will be new to all\nservices and i\'m just looking to define the best and most common from\nwhat currently exists in a compatible way. \n\nPlease review. \n\nAlso is there somewhere i can link this to to make sure it is seen by\npeople creating a new project? \n\nJamie\n\n\n\n','<1392617362.29597.54.camel@dhcp-40-102.bne.redhat.com>',NULL),('<1392623627.269.YahooMailNeo@web142306.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-16 23:53:47',-28800,'2014-02-17 07:53:47',NULL,'[Openstack] Are multiple neutron plugins on a server supported?','Hi All,\n\n\nWhile setting up a neutron plugin (like ovswitch, mellanox etc), we \nneed to specify plugin name in /etc/neutron/neutron.conf (on the neutron server node) as follows:\ncore_plugin =neutron.plugins.mlnx.mlnx_plugin.MellanoxEswitchPlugin\nMy query is: \nIs there a way to specify and use multiple plugins at the same time?\n\nBackground: \nI would like to use two plugins at same time to make use of exclusive \nfeatures in NIC cards from 2 vendors. Both cards will be installed on \nsame compute node.\n\n?\nThanks,\nNishant\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140216/3549ade5/attachment.html>\n\n',NULL,NULL),('<1392632782.29113.YahooMailNeo@web142304.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-17 02:26:22',-28800,'2014-02-17 10:26:22',NULL,'[Openstack] Are multiple neutron plugins on a server supported?','Salvatore,\n\nThanks for your response. I will look at ML2.\n\nI guess such capability will require the option of passing \'Plugin Name\' to the first level API so that request can be forwarded to the right plugin. I will try to see whether ML2 works this way.\n?\nThanks,\nNishant\n\n\n\nOn Monday, February 17, 2014 2:16 PM, Salvatore Orlando <sorlando at nicira.com> wrote:\n \nHi Nishant,\n\nunfortunately Neutron at the moment supports only a single plugin for each service. This means you can only specify a single core_plugin.\nIf your goal is to support multiple backend technologies in your deployment, you should perhaps have a look at the ML2 where deployment of multiple drivers should be possible.\n\nSalvatore\n\n\n\nOn 17 February 2014 08:53, nishant kumar <nishantkumar_2k at yahoo.com> wrote:\n\nHi All,\n>\n>\n>While setting up a neutron plugin (like ovswitch, mellanox etc), we \nneed to specify plugin name in /etc/neutron/neutron.conf (on the neutron server node) as follows:\n>core_plugin =neutron.plugins.mlnx.mlnx_plugin.MellanoxEswitchPlugin\n>My query is: \n>Is there a way to specify and use multiple plugins at the same time?\n>\n>\n>Background: \n>I would like to use two plugins at same time to make use of exclusive \nfeatures in NIC cards from 2 vendors. Both cards will be installed on \nsame compute node.\n>\n>?\n>Thanks,\n>Nishant\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140217/b30de4c9/attachment.html>\n\n','<CAGR=i3iiZ1W=8h4kL2LgAK7KX4w=Mo02aQR=qe=bJG8tU_5MEg@mail.gmail.com>',NULL),('<1392642317.2793.2.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 13:05:19',0,'2014-02-17 13:05:19',NULL,'[openstack-dev] [infra] reverify/recheck','Was that not for \'reverify no bug\' ?\n\nGraham\n\nOn Mon, 2014-02-17 at 13:53 +0100, Sylvain Bauza wrote:\n> Hi Gary,\n> \n> \n> That\'s normal, this command has been removed since Dec\'13,\n> see http://lists.openstack.org/pipermail/openstack-dev/2013-December/021649.html\n> \n> \n> -Sylvain\n> \n> \n> 2014-02-17 13:00 GMT+01:00 Gary Kotton <gkotton at vmware.com>:\n>         Hi,\n>         It seems that the command \'reverify bug <number>\' is not\n>         working. Anyone else experienced this lately.\n>         Thanks\n>         Gary \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CANWE-Ck2eqvbmDOYJCq0GFDft7PN_LtVCgMRuhRg0oqwQBQPBA@mail.gmail.com>',NULL),('<1392650228.24912.56.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-17 10:17:08',-18000,'2014-02-17 15:17:08',NULL,'[OpenStack-Infra] Error with install_master','On Mon, 2014-02-17 at 12:35 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> From the blog,  the following lines suggest the configuration of\n> sanbox\n> \n> Set Your Vendor Name in the Test Jenkins Job\n> \n> Next, open up the file etc/jenkins_jobs/config/sandbox.yaml in your\n> data repository. Change the following line in it:\n> \n> echo \"Hello world, this is MyVendor\'s Testing System\"\n> \n> Change MyVendor to your organization?s name.\n> \n> But then , Will vary for other openstack projects like cinder, neutron\n> etc..\n\nNot sure I understand you... you need to change \"MyVendor\" to your\norganization\'s name, not the name of the project.\n\nBest,\n-jay\n\n\n\n\n','<25702d9bd77b445fb55e40659b553b11@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1392654167.99455.YahooMailNeo@web163806.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-17 08:22:47',-28800,'2014-02-17 16:22:47',NULL,'[Openstack] Keystone v3 APIs','Trying to get list of groups in a tenant using Keystone v3 APIs.\nIt is giving me an error - resource not found even where there are groups in that tenant. Any idea why this might be happening\n\nThanks\nRajdeep\n\nCode - Listing\n\nimport keystoneclient.v3.client as ksclient\nfrom credentials import get_credentials\n\ncredentials = get_credentials()\ntry:\n? ? keystone = ksclient.Client(**credentials)\n\n? ? groups_list = keystone.groups.list()\n...\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140217/fd16a7dd/attachment.html>\n\n',NULL,NULL),('<1392654582.24912.64.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-17 11:29:42',-18000,'2014-02-17 16:29:42',NULL,'[OpenStack-Infra] Error with install_master','On Mon, 2014-02-17 at 15:41 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay\n> \n> Okay, let me frame this way.\n> \n> The configuration is intended for sandbox project. for cinder project do I need to change it to cinder or leave it to sandbox as it is.\n\nAh, I see now what you are referring to.\n\nYou can do whatever you\'d like to the example Jenkins jobs configs I put\nin my example data repository. Copy them, delete them, change them,\nwhatever you want.\n\nIf, for example, you wanted to run the sandbox-dsvm-tempest-full job\nagainst cinder (instead of openstack-dev/sandbox project), you would\nchange the etc/jenkins_jobs/config/projects.yaml in your data repository\nfrom this:\n\n- project:\n    name: sandbox\n    github-org: openstack-dev\n    node: master\n\n    jobs:\n        - sandbox-noop-check-communication\n        - sandbox-dsvm-tempest-full:\n            node: devstack_slave\n\nto this:\n\n- project:\n    name: cinder\n    github-org: openstack\n    node: master\n\n    jobs:\n        - sandbox-dsvm-tempest-full:\n            node: devstack_slave\n\n(you can change the name of the sandbox-dsvm-tempest-full job to\nsomething else as well if you like).\n\nIn the etc/zuul/layout.yaml file, you would add the Cinder project  to\nthe projects section like this:\n\n- project:\n    name: cinder\n    github-org: openstack\n    node: master\n\n    jobs:\n        - sandbox-noop-check-communication\n        - sandbox-dsvm-tempest-full:\n            node: devstack_slave\n\nDue to the confusion around this, I think I might change the example\ndata repository and change sandbox.yaml to just tests.yaml, and remove\nthe sandbox- prefix from those job names (since they can clearly be run\nfor any project).\n\nI will update the latest article accordingly. Thanks for your patience,\nTrinath!\n\n-jay\n\n\n\n\n\n','<e2dd5936908847639e0c196a68256eb1@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1392681047.695814652@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 17:50:47',-21600,'2014-02-17 23:50:47',NULL,'[openstack-dev] [solum] Question about solum-minimal-cli BP','Hi Shaunak,\n\n-----Original Message-----\nFrom: \"Shaunak Kashyap\" <shaunak.kashyap at RACKSPACE.COM>\nSent: Monday, February 17, 2014 3:47pm\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: [openstack-dev] [solum] Question about solum-minimal-cli BP\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nHey folks,\n\nI was reading through https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation and have a question.\n\nIf I?m understanding ?app create? and ?assembly create? correctly, the user will have to run ?app create? first, followed by ?assembly create? to have a running application. Is this correct? \n\n>> Yes.\n\nIf so, what is the reason for ?app create? not automatically creating one assembly as well?\n\n>> One of the reasons \'app create\' and \'assembly create\' are distinct actions is\nto decouple creation of assemblies from creation/registration of a plan (which is represented by app create).\nThis allows supporting creation of multiple assemblies from the same registered plan.\n\n\nThanks,\n\nShaunak\n\n\n\n\n','<etPan.53028372.1befd79f.381c@MLC5VVFFT1>',NULL),('<1392735623.5474.0.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-18 10:00:23',-18000,'2014-02-18 15:00:23',NULL,'[openstack-dev] [QA] Service dependency decorators in tests','On Tue, 2014-02-18 at 14:33 +0000, Frittoli, Andrea (Cloud Services)\nwrote:\n> Hi all,\n> \n> Scenario tests feature service dependency decorators in tests ? so\n> that a test will run only if all required components are available.\n> \n> I think we should extend them to all tests, including the API ones.\n> For instance Nova image tests depend on Glance, cinder attach/detach\n> tests depend on Nova.\n> \n> If there is agreement on that I?d happy to start a bp to track the\n> test tagging effort.\n\n++\n\nBest,\n-jay\n\n\n\n\n','<A36B1DF8CF6E574F9E151E2766C8C36148987588@G9W0345.americas.hpqcorp.net>',NULL),('<1392736550.5474.1.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-18 10:15:50',-18000,'2014-02-18 15:15:50',NULL,'[Openstack-operators] [Fwd: Re: [Fwd: [openstack-dev]\n [Fuel][TripleO] NIC bonding for OpenStack]]','\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Vivek Singh Raghuwanshi <vivekraghuwanshi at gmail.com>\nSubject: Re: [Openstack-operators] [Fwd: [openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack]\nDate: Tue, 18 Feb 2014 12:32:09 +0530\nSize: 13955\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140218/af37ad59/attachment.mht>\n\n',NULL,NULL),('<1392757615.27429.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-02-18 21:06:55',0,'2014-02-18 21:06:55',NULL,'[openstack-tc] Missing next TC meeting','Hey Thierry,\n\nOn Fri, 2014-02-14 at 13:39 +0000, Mark McLoughlin wrote:\n> On Fri, 2014-02-14 at 14:09 +0100, Thierry Carrez wrote:\n> > Members of the TC,\n> > \n> > I have an unexpected family event I need to attend on Tuesday, so I\n> > won\'t be able to attend or chair our next TC meeting on February 18th.\n> > \n> > There are a few things that need to be discussed (progress on Defcore\n> > subcommittee, Nova scorecard on integration requirements, Keystone\n> > addition of the Kite project...) so unless we have a lot more absentees\n> > I think it still makes sense to hold a meeting, as long as we have a\n> > volunteer to chair it.\n> > \n> > Anyone interested ?\n> \n> Sure, I\'m happy to chair.\n\nFor your reading pleasure:\n\n  http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-02-18-20.01.html\n\nI guess there\'s a few action items in there for you:\n\n  - get us to consensus on DefCore feedback\n  - pare down the board/TC meeting ideas\n  - queue up KDS topic again for next week\n  - approve the minor governance changes\n  - perhaps clarify how much, if any, TC approval is required for a \n    program to add a new project\n  - come back! all is forgiven!\n  - find a good home for Russell\'s high horse\n\nCheers,\nMark.\n\n\n\n','<1392385177.23460.5.camel@sorcha>',NULL),('<1392760524.73943271@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-02-18 15:55:24',-21600,'2014-02-18 21:55:24',NULL,'[openstack-community] Pods Still Available for OpenStack Pavilions\n	at Interop/Cloud Connect and World Hosting Days','\nThank you for the enthusiastic response to these two events - both are sure to be well-attended and valuable to OpenStack exhibitors.\n \nInterop / Cloud Connect, Las Vegas, NV, April 1-3.  These two events have combined to one BIG one, with over 12,000 attendees expected.  A pod in the OpenStack Pavilion is $6K and includes almost everything (Internet, power, graphics) AND a spot on a 45 minute panel directly off the show floor.  There are just a few pods left..\n \nWorld Hosting Days, Rust, Germany, April 1-3.  This is the best event for service providers we\'ve seen.  A kiosk in the OpenStack community is 5K Euro, also including most support items.  If your firm targets service providers, you won\'t want to miss this event.\n \nPlease contact me at kathyc at openstack.org to participate!  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140218/0e9d6c18/attachment.html>\n\n',NULL,NULL),('<1392769176.24768.YahooMailNeo@web125901.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-18 16:19:36',-28800,'2014-02-19 00:19:36',NULL,'[Openstack-docs] Developer training guide sprint started','All are welcome to join the fun! The starting point is this design doc?https://docs.google.com/a/yahoo-inc.com/document/d/1QiZ_PJTIFwKOmHPYhtez0TTEXHUb1r21OV0-PoNN45U/edit#\n\nThe two week sprint is ending 03 March.?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140218/cc98a1b9/attachment.html>\n\n',NULL,NULL),('<1392785418.5474.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-18 23:50:18',-18000,'2014-02-19 04:50:18',NULL,'[openstack-dev] [third party testing] Article series on setting up\n an external CI system','Hi all,\n\nThere have been efforts recently by lots of folks, particularly in the\nNova, Neutron, and Cinder contributor communities, trying to set up a\nthird-party testing platform that can get notified by the upstream\nOpenStack CI system, run tests, and post votes on code reviews upstream.\n\nPartly in response to these efforts, and partly due to the\nrecently-announced Mirantis push to \"open source\" driver certification\nprocedures [1], I wrote a series of blog articles that describe both how\nthe upstream CI system works, as well as provide some instructions on\nsetting up an external CI system yourself in a (mostly) automated\nfashion.\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/\n\nI hope that folks find these articles useful. Feedback, criticism, and\nerror corrections are very much welcomed. Please do let me know, either\non the ML or on blog comments, if there are specific things or examples\nyou would like me to cover further.\n\nBest,\n-jay\n\n[1]\nhttp://www.mirantis.com/blog/openstack-will-open-source-vendor-certifications/\n\n\n\n\n',NULL,NULL),('<1392785418.5474.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-18 23:50:18',-18000,'2014-02-19 04:50:18',NULL,'[OpenStack-Infra] [third party testing] Article series on setting\n up an external CI system','Hi all,\n\nThere have been efforts recently by lots of folks, particularly in the\nNova, Neutron, and Cinder contributor communities, trying to set up a\nthird-party testing platform that can get notified by the upstream\nOpenStack CI system, run tests, and post votes on code reviews upstream.\n\nPartly in response to these efforts, and partly due to the\nrecently-announced Mirantis push to \"open source\" driver certification\nprocedures [1], I wrote a series of blog articles that describe both how\nthe upstream CI system works, as well as provide some instructions on\nsetting up an external CI system yourself in a (mostly) automated\nfashion.\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/\n\nI hope that folks find these articles useful. Feedback, criticism, and\nerror corrections are very much welcomed. Please do let me know, either\non the ML or on blog comments, if there are specific things or examples\nyou would like me to cover further.\n\nBest,\n-jay\n\n[1]\nhttp://www.mirantis.com/blog/openstack-will-open-source-vendor-certifications/\n\n\n\n\n',NULL,NULL),('<1392785797.4843.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 12:56:37',28800,'2014-02-19 04:56:37',NULL,'[openstack-dev] [oslo] Some questions about Rest API and log\n	messages translation','Hi,\n\n  Currently I am analyzing the blueprint of translated message id\ngeneration.[1]\n  Recently I just found that there is an implementation to generate both\nEnglish and translated log messages.\n  I think if English and translated log messages are provided, then we\ndon\'t need to generate a message id for log messages.\n\n  My question is about Rest API messages translation. If we will return\nboth English and translated Rest API message, then we don\'t need to\ngenerate a message id for Rest API message, either.\n\n  And currently message id generation blueprint is only for log message\nand translated Rest API message. If we provide both English and\ntranslated messages, then we don\'t need to generate any message id for\nmessages. Because we just need to read the English log and Rest API\nmessages.\n\n  Feel free to comment it.\n\nThanks,\n  Peng Wu\n\nRefer URL:\n[1] https://blueprints.launchpad.net/oslo/+spec/log-messages-id\n[2]\nhttps://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n\n\n\n\n',NULL,NULL),('<1392788359.73683.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-19 13:39:19',28800,'2014-02-19 05:39:19',NULL,'[Openstack] problem in installing django-swiftbrowser','\n\n\n\n\nOn Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n \nPlease consider installing the setuptools module.\n>\n>\n>The latest archive can be found here:\n>\n>\n>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>\n>\n>You can install it with these commands:\n>\n>\n>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>tar zxvf?setuptools-2.2.tar.gz\n>cd?setuptools-2.2\n>sudo python ./setup.py install\n>\n>\n>From:  pragya jain <prag_2648 at yahoo.co.in>\n>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>Date:  Sunday, February 16, 2014 9:55 PM\n>To:  pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>\n>\n>\n>please someody reply\n>\n>\n>\n>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello all,\n>>\n>>\n>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>\n>>\n>>below are the steps which i follow:\n>>-----------------\n>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>\n>>\n>>\n>>Cloning into \'django-swiftbrowser\'...\n>>remote: Reusing existing pack: 145, done.\n>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>Resolving deltas: 100% (72/72), done.\n>>\n>>\n>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>\n>>\n>>\n>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>Traceback (most recent call last):\n>>? File \"setup.py\", line 2, in <module>\n>>??? from setuptools import setup\n>>ImportError: No module named setuptools\n>>------------\n>>\n>>\n>>But I get the error.\n>>Please help inresolving the error.\n>>\n>>\n>>Thanks in advance \n>>\n>>Pragya Jain\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140219/c3a22b16/attachment.html>\n\n','<CF26E6C7.2700A%Lysander_David@symantec.com>',NULL),('<1392788889.30365.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-19 13:48:09',28800,'2014-02-19 05:48:09',NULL,'[Openstack] problem in installing django-swiftbrowser','thanks Lysander David for the reply. \n\nI again have some problem.\n\nI follow the following steps:\n1.? root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n\n\n2.? root at pragya-VirtualBox:~# cd django-swiftbrowser\n\n3.  \nroot at pragya-VirtualBox:~/django-swiftbrowser#\nwget --no-check-certificate\nhttps://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n-O setuptools-2.2.tar.gz \n\n4.?  \nroot at pragya-VirtualBox:~/django-swiftbrowser# tar zxvf setuptools-2.2.tar.gz \n5.  \nroot at pragya-VirtualBox:~/django-swiftbrowser# cd setuptools-2.2 \n\n6.?  \nroot at pragya-VirtualBox:~/django-swiftbrowser/setuptools-2.2#\nsudo python ./setup.py install \n7.?  \nroot at pragya-VirtualBox:~/django-swiftbrowser#\npython runtests.py \n\nand I got the following error :\n\nTraceback (most recent call last): \nFile \"runtests.py\", line 2,\nin <module> \nfrom django.conf import settings \nImportError: No module named\ndjango.conf \nPlease help to resolve it.\n\nThanks again \n\npragya Jain\n\n\n\n\n\nOn , pragya jain <prag_2648 at yahoo.co.in> wrote:\n \n\n>\n>\n>On Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n> \n>Please consider installing the setuptools module.\n>>\n>>\n>>The latest archive can be found here:\n>>\n>>\n>>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>>\n>>\n>>You can install it with these commands:\n>>\n>>\n>>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>>tar zxvf?setuptools-2.2.tar.gz\n>>cd?setuptools-2.2\n>>sudo python ./setup.py install\n>>\n>>\n>>From:  pragya jain <prag_2648 at yahoo.co.in>\n>>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>>Date:  Sunday, February 16, 2014 9:55 PM\n>>To:  pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>>\n>>\n>>\n>>please someody reply\n>>\n>>\n>>\n>>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hello all,\n>>>\n>>>\n>>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>>\n>>>\n>>>below are the steps which i follow:\n>>>-----------------\n>>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>\n>>>\n>>>\n>>>Cloning into \'django-swiftbrowser\'...\n>>>remote: Reusing existing pack: 145, done.\n>>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>>Resolving deltas: 100% (72/72), done.\n>>>\n>>>\n>>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>\n>>>\n>>>\n>>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>>Traceback (most recent call last):\n>>>? File \"setup.py\", line 2, in <module>\n>>>??? from setuptools import setup\n>>>ImportError: No module named setuptools\n>>>------------\n>>>\n>>>\n>>>But I get the error.\n>>>Please help inresolving the error.\n>>>\n>>>\n>>>Thanks in advance \n>>>\n>>>Pragya Jain\n>>>\n>>>_______________________________________________\n>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>Post to? ? : openstack at lists.openstack.org\n>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>\n>>>\n>>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140219/e3a6d501/attachment.html>\n\n','<1392788359.73683.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1392795334-sup-2354@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 07:48:47',0,'2014-02-19 07:48:47',NULL,'[openstack-dev] [Heat] [TripleO] Better handling of lists in Heat -\n	a proposal to add a map function','Since picking up Heat and trying to think about how to express clusters\nof things, I\'ve been troubled by how poorly the CFN language supports\nusing lists. There has always been the Fn::Select function for\ndereferencing arrays and maps, and recently we added a nice enhancement\nto HOT to allow referencing these directly in get_attr and get_param.\n\nHowever, this does not help us when we want to do something with all of\nthe members of a list.\n\nIn many applications I suspect the template authors will want to do what\nwe want to do now in TripleO. We have a list of identical servers and\nwe\'d like to fetch the same attribute from them all, join it with other\nattributes, and return that as a string.\n\nThe specific case is that we need to have all of the hosts in a cluster\nof machines addressable in /etc/hosts (please, Designate, save us,\neventually. ;). The way to do this if we had just explicit resources\nnamed NovaCompute0, NovaCompute1, would be:\n\n  str_join:\n    - \"\\n\"\n    - - str_join:\n        - \' \'\n        - get_attr:\n          - NovaCompute0\n          - networks.ctlplane.0\n        - get_attr:\n          - NovaCompute0\n          - name\n      - str_join:\n        - \' \'\n        - get_attr:\n          - NovaCompute1\n          - networks.ctplane.0\n        - get_attr:\n          - NovaCompute1\n          - name\n\nNow, what I\'d really like to do is this:\n\nmap:\n  - str_join:\n    - \"\\n\"\n    - - str_join:\n      - \' \'\n      - get_attr:\n        - \"$1\"\n        - networks.ctlplane.0\n      - get_attr:\n        - \"$1\"\n        - name\n  - - NovaCompute0\n    - NovaCompute1\n\nThis would be helpful for the instances of resource groups too, as we\ncan make sure they return a list. The above then becomes:\n\n\nmap:\n  - str_join:\n    - \"\\n\"\n    - - str_join:\n      - \' \'\n      - get_attr:\n        - \"$1\"\n        - networks.ctlplane.0\n      - get_attr:\n        - \"$1\"\n        - name\n  - get_attr:\n      - NovaComputeGroup\n      - member_resources\n\nThoughts on this idea? I will throw together an implementation soon but\nwanted to get this idea out there into the hive mind ASAP.\n\n\n',NULL,NULL),('<1392824531.6739.1.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-19 10:42:11',-18000,'2014-02-19 15:42:11',NULL,'[OpenStack-Infra] External Testing :: install-master.sh errors','On Wed, 2014-02-19 at 13:36 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n>  \n> \n> Its resolved,\n> \n> It?s a Capital letters issue with the node hostname.\n\nOK, good :)\n> \n>  But then, I have found the following.\n\n> Duplicate declaration: A2mod[proxy_http] is already declared in\n> file /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/master.pp at line 40; cannot redeclare at /root/config/modules/zuul/manifests/init.pp:242 on node freescale-openstack-ci.ap.freescale.net\n\nYup, it\'s a bug in upstream openstack-infra/config. I\'ve submitted a\npatch here:\n\nhttps://review.openstack.org/#/c/74443/\n\nFeel free to apply that patch to the /root/config source tree on your\nmaster node.\n\nBest,\n-jay\n\n\n\n\n','<00ae89fdf3574063b0f1c5387f272392@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1392827258.3641.11.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 10:27:38',-21600,'2014-02-19 16:27:38',NULL,'[openstack-dev] [Nova] status of quota class','On Wed, 2014-02-19 at 13:47 +0100, Mehdi Abaakouk wrote:\n> But \'quota_class\' is never set when a nova RequestContext is created.\n\nWhen I created quota classes, I envisioned the authentication component\nof the WSGI stack setting the quota_class on the RequestContext, but\nthere was no corresponding concept in Keystone.  We need some means of\nidentifying groups of tenants.\n\n> So my question, what is the plan to finish the \'quota class\' feature ? \n\nI currently have no plan to work on that, and I am not aware of any such\nwork.\n\n> Can I propose a blueprint for the next cycle to store the mapping between\n> project and a quota_class into nova itself, to finish this feature ? \n\nOf course; anyone can propose a blueprint.  Who will you have work on\nthe feature?\n\n> ie: add a new API endpoint to set a quota_class to a project, store that\n> into the db and change the quota engine to read the quota_class from the\n> db instead of the RequestContext.\n\nReading the quota class from the db sounds like a bad fit to me; this\nreally feels like something that should be stored in Keystone, since\nit\'s authentication-related data.  Additionally, if the attribute is in\nKeystone, other services may take advantage of it.  The original goal of\nquota classes was to make it easier to update the quotas of a given\ntenant based on some criteria, such as the service level they\'ve paid\nfor; if a customer upgrades (or downgrades) their service level, their\nquotas should change to match.  This could be done by manually updating\neach quota that affects them, but a single change to a single attribute\nmakes better sense.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<20140219124724.GA3523@sileht.net>',NULL),('<1392828698.7206.YahooMailNeo@web122602.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-19 08:51:38',-28800,'2014-02-19 16:51:38',NULL,'[Openstack] keystone with external authentication using apache2 on\n	havana/ubuntu1204','Hi,\n\nIs there someone who did the keystone to delegate authentication to apache on ubuntu/havana.\nI have read these documents but nothing is clear:\nhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/Configuring_the_Identity_Service_to_Run_in_HTTPD.html\nhttps://wiki.openstack.org/wiki/Talk:Keystone_in_HTTPD_on_RHEL6\nhttp://docs.openstack.org/developer/keystone/apache-httpd.html\n\nIt seams like everyone is telling half of the truth....:)\n\nIs there any other place where I could understand how you could do it on ubuntu?\n\nThanks a lot,\nGabriel\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140219/ffb2519a/attachment.html>\n\n',NULL,NULL),('<1392839719.2453.11.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-19 14:55:19',-18000,'2014-02-19 19:55:19',NULL,'[Openstack-operators] [openstack][nova] total region lockdown\n (very weird)','On Wed, 2014-02-19 at 15:52 -0300, Alejandro Comisario wrote:\n> Hi community, the weirdest thing happened to one of our openstack\n> regions, running more than 200 vms\n\n> This region is :\n> * openstack essex 2012.1.4\n> * ubuntu 12.04.2\n> * Linux DC4-r59-02vms 3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18\n> 17:39:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux\n> \n> On Saturday all 16 nodes increased suddenly with no reason the network\n> throughput at the exaclty same time and saturated themselves (peaking\n> at 500Mb/s), it was something that involved only that vlan/region.\n> \n> Something that was weird, is that graphics shows that lots of traffic\n> was getting out from the vms via the vnet interfaces and from the host\n> itself, but you see nothing inside the virtual machines, on the\n> contrary. (im attaching graphics of everything) \n> We see lots of packages discarded from the tor and aggregation of this\n> region, but we dont know what happened that caused this burst in\n> bandwidth.\n> \n> Here\'s the graphics of:\n> -----------------------\n> The view from the compute node, increasing drastically the bandwidth\n> usage, same happened to all 15 compute nodes.\n> http://oi58.tinypic.com/246261k.jpg\n> \n> \n> \n> The view of the vms traffic from the compute perspective, of every\n> vnet, in theory, increasing the traffic.\n> http://oi62.tinypic.com/2el9j0o.jpg\n> \n> \n> \n> The view from inside of the vms, totally decreasing the traffic\n> because of this kind of self saturation from every compute (this view\n> is of one compute)\n> http://oi59.tinypic.com/vh991l.jpg\n\nHi Alejandro,\n\nYou may want to check to see if software running in certain VMs was\ncompromised. It looks very much like a DDoS attack to me.\n\nIs there anything common to these instances?\n\ne-00002d88\ne-00003386\ne-00003387\ne-00002bec\n\nThose instances look like they were hacked and started executing\nsomething that kicked off a bunch of outbound net I/O.\n\nYou can tell that it is something inside those particular tenants\nbecause the outbound network I/O on the management plane eth0 was hardly\nanything (4.22 MB/s) vs. the tenant-facing data plane (bond0/vnet10) was\nshowing outbound I/O at 17-21 MB/s over the same time.\n\nI\'d run a virus or rootkit hunter on the instances above.\n\nBest,\n-jay\n\n\n\n\n','<CAMrG31xOxrM8is3K4sZkUkP1wQuzaS6FwCxadKXQ4K+j1o5PDQ@mail.gmail.com>',NULL),('<1392846655.2453.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 16:50:55',-18000,'2014-02-19 21:50:55',NULL,'[openstack-dev] [qa] Cleaning OpenStack resources','On Wed, 2014-02-19 at 16:15 -0500, David Kranz wrote:\n> I was looking at https://review.openstack.org/#/c/73274/1 which makes it \n> configurable whether a brute-force cleanup of resources is done after \n> success. This got my wondering how this should really be done. As admin, \n> there are some resources that can be cleaned and some that I don\'t  know \n> how. For example, as admin you can list all servers and delete them with \n> the --all-tenants flag. But for floating ips I don\'t see a way to list \n> all of them even as admin through the apis. Is there a way that an admin \n> can, through the api, locate all resources used by a particular tenant?\n\nUnfortunately, I don\'t think this is consistently possible between all\nthe services :(\n\n-jay\n\n\n\n','<53051EE0.8000706@redhat.com>',NULL),('<1392847371.2453.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 17:02:51',-18000,'2014-02-19 22:02:51',NULL,'[openstack-dev] [qa][neutron] API tests in the Neutron tree','On Wed, 2014-02-12 at 14:17 -0800, Maru Newby wrote:\n> On Feb 12, 2014, at 1:59 PM, Sean Dague <sean at dague.net> wrote:\n> \n> > On 02/12/2014 04:25 PM, Maru Newby wrote:\n> >> \n> >> On Feb 12, 2014, at 12:36 PM, Sean Dague <sean at dague.net> wrote:\n> >> \n> >>> On 02/12/2014 01:48 PM, Maru Newby wrote:\n> >>>> At the last 2 summits, I\'ve suggested that API tests could be maintained in the Neutron tree and reused by Tempest.  I\'ve finally submitted some patches that demonstrate this concept:\n> >>>> \n> >>>> https://review.openstack.org/#/c/72585/  (implements a unit test for the lifecycle of the network resource)\n> >>>> https://review.openstack.org/#/c/72588/  (runs the test with tempest rest clients)\n> >>>> \n> >>>> My hope is to make API test maintenance a responsibility of the Neutron team.  The API compatibility of each Neutron plugin has to be validated by Neutron tests anyway, and if the tests are structured as I am proposing, Tempest can reuse those efforts rather than duplicating them.\n> >>>> \n> >>>> I\'ve added this topic to this week\'s agenda, and I would really appreciate it interested parties would take a look at the patches in question to prepare themselves to participate in the discussion.\n> >>>> \n> >>>> \n> >>>> m.\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>> \n> >>> \n> >>> Realistically, having API tests duplicated in the Tempest tree is a\n> >>> feature, not a bug.\n> >>> \n> >>> tempest/api is there for double book keep accounting, and it has been\n> >>> really effective at preventing accidental breakage of our APIs (which\n> >>> used to happen all the time), so I don\'t think putting API testing in\n> >>> neutron obviates that.\n> >> \n> >> Given how limited our testing resources are, might it be worth considering whether \'double-entry accounting\' is actually the best way to preventing accidental breakage going forward?  Might reasonable alternatives exist, such as clearly separating api tests from other tests in the neutron tree and giving review oversight only to qualified individuals?\n> > \n> > Our direct experience is that if we don\'t do this, within 2 weeks some\n> > project will have landed API breaking changes. This approach actually\n> > takes a lot of review load off the core reviewers, so reverting to a\n> > model which puts more work back on the review team (given the current\n> > review load), isn\'t something I think we want.\n> \n> Just so I\'m clear, is there anything I could say that would change your mind?\n\nI\'d like to discuss this at tomorrow\'s IRC meeting, if possible. I think\nthat the model that Maru came up with (PoC code in the two patches\nreferenced above) are actually a pretty slick way of dealing with this\nissue, and along with the ongoing efforts to \"libify\" Tempest, I think\nthat we should head in this direction if possible.\n\nBest,\n-jay\n\n\n\n','<0094FD3B-E69D-4961-984D-D5E9BC24A650@redhat.com>',NULL),('<1392848279.2453.16.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-19 17:17:59',-18000,'2014-02-19 22:17:59',NULL,'[openstack-dev] [Neutron][LBaaS] Proposal for model change -\n Multiple services per floating IP','On Wed, 2014-02-12 at 16:11 -0800, Stephen Balukoff wrote:\n\n>       * This seems less ambiguous from a terminology perspective. The\n>         name \'VIP\' in other contexts means \'virtual IP address\', which\n>         is the same thing as a floating IP, which in other contexts is\n>         usually considered to be unique to a subset of devices that\n>         share the IP (or pass it between them). It doesn\'t necessarily\n>         have anything to do with layers 4 and above in the OSI model.\n>         However, if in the context of Neutron LBaaS, \"VIP\" has a\n>         \"protocol-port\" attribute, this means it\'s no longer just a\n>         floating IP:  It\'s a floating IP + TCP port (plus other\n>         attributes that make sense for a TCP service). This feels like\n>         Neutron LBaaS is trying to redefine what a \"virtual IP\" is,\n>         and is in any case going to be confusing for new comers\n>         expecting it to be one thing when it\'s actually another.\n\nThis is an excellent point, Stephen.\n\n-jay\n\n\n\n\n','<CAAGw+Zqu6E7RjuaW3dL0pw4tKZ1zBov1SbW-zjPfFPRHP70+=g@mail.gmail.com>',NULL),('<1392889102.63839.YahooMailNeo@web122601.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-20 01:38:22',-28800,'2014-02-20 09:38:22',NULL,'[Openstack] keystone with external authentication using apache2\n	on havana/ubuntu1204','Hi Dave,\n\nThanks a lot for you interest in helping me. I will try to answer your questions as good as I can:\nI am using havana release of the openstack. I am starting from default keystone authentication:\nThis is my /etc/keystone/keystone.conf:\n\n\n[DEFAULT]\nlog_file = keystone.log\nlog_dir = /var/log/keystone\n[sql]\nconnection = mysql://keystoneuser:keystonepass at 153.65.235.39/keystone\n[identity]\ndriver = keystone.identity.backends.sql.Identity\n[credential]\ndriver = keystone.credential.backends.sql.Credential\n[trust]\ndriver = keystone.trust.backends.sql.Trust\n[os_inherit]\n[catalog]\ndriver = keystone.catalog.backends.sql.Catalog\n[endpoint_filter]\n[token]\ndriver = keystone.token.backends.sql.Token\n[cache]\n[policy]\ndriver = keystone.policy.backends.sql.Policy\n[ec2]\ndriver = keystone.contrib.ec2.backends.kvs.Ec2\n[assignment]\n[oauth1]\n[ssl]\n[signing]\n[ldap]\n[auth]\n\n\nThen I am doing:\nservice keystone start\nsource openstackrc\n\nThe content of openstackrc:\nexport OS_TENANT_NAME=admin\nexport OS_USERNAME=admin\nexport OS_PASSWORD=admin\nexport SERVICE_TOKEN=ADMIN\nexport OS_AUTH_URL=\"http://10.65.235.39:5000/v2.0/\"\nexport SERVICE_ENDPOINT=\"http://10.65.235.39:35357/v2.0\"\n\n\nkeystone user-list\nroot at ubuntu1204:~# keystone user-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+------------+---------+-------------------+\n|??????????????? id??????????????? |??? name??? | enabled |?????? email?????? |\n+----------------------------------+------------+---------+-------------------+\n| 813a815b593f495c9a449f9c5c44625d |?? admin??? |?? True? | admin at example.com |\n| 7df8919856ec4072927d2523bceed5eb | ceilometer |?? True? | admin at example.com |\n| b6aae4b745484e3da6892b68a7e322f9 |?? cinder?? |?? True? | admin at example.com |\n| d08d5f5e515a4601b417a637cf690999 |??? demo??? |?? True? |? demo at example.com |\n| a3a5444d42b9462e8fcac9e3a10f2e60 |?? glance?? |?? True? | admin at example.com |\n| 1c1ab74a4a934273836f41999e2ac9fc |??? heat??? |?? True? | admin at example.com |\n| 823d9d20cbd8412887c3f6052eca720d |? neutron?? |?? True? | admin at example.com |\n| e58d30815fac48209bf56441e1d5bb76 |??? nova??? |?? True? | admin at example.com |\n+----------------------------------+------------+---------+-------------------+\n\n\n\n?keystone endpoint-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n|??????????????? id??????????????? |?? region? |???????????????? publicurl????????????????? |??????????????? internalurl???????????????? |????????????????? adminurl????????????????? |??????????? service_id??????????? |\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n| 05784027da8b4acb8489d0486faf9f61 |? myregion |? http://153.65.235.39:8773/services/cloud? |? http://153.65.235.39:8773/services/cloud? |? http://153.65.235.39:8773/services/admin? | 5bc96b5587aa4f12919f3a155b5713b0 |\n| 10a762a17a58478d8285c1ca6ed8344a |? myregion | http://153.65.235.39:8004/v1/$(tenant_id)s | http://153.65.235.39:8004/v1/$(tenant_id)s | http://153.65.235.39:8004/v1/$(tenant_id)s | 3308b160d21f4dac84b866063852a47a |\n| 23aff8a4b486423592ad877eb0eb29d2 |? myregion |?????? http://153.65.235.39:5000/v2.0?????? |?????? http://153.65.235.39:5000/v2.0?????? |????? http://153.65.235.39:35357/v2.0?????? | c5196b9c3d5446bdb63ee3b8f40d67f7 |\n| 8e0ecafcf86e42c28f6431e9cd6b330b |? myregion | http://153.65.235.39:8774/v2/$(tenant_id)s | http://153.65.235.39:8774/v2/$(tenant_id)s | http://153.65.235.39:8774/v2/$(tenant_id)s | 4d7a03c577304e3381a3d08ba74a70dc |\n| aaa01a27723d4d4abfe65496d03e811e |? myregion | http://153.65.235.39:8776/v1/$(tenant_id)s | http://153.65.235.39:8776/v1/$(tenant_id)s | http://153.65.235.39:8776/v1/$(tenant_id)s | aed8babcd157477b827c7a2ce89a641c |\n| aebb4602fae143ef86d62de0c0bc5ba8 | regionOne |???? http://153.65.235.39/keystone/main???? |??????????????????????????????????????????? |??? http://153.65.235.39/keystone/admin???? | c5196b9c3d5446bdb63ee3b8f40d67f7 |\n| c5169966464140c69fe8c244659ad932 |? myregion |???????? http://153.65.235.39:9696/???????? |???????? http://153.65.235.39:9696/???????? |???????? http://153.65.235.39:9696/???????? | a7a32598413a435687e9919c6add1647 |\n| d5b7a1f9f7bf417295f7b1e9e34f0a26 |? myregion |??????? http://153.65.235.39:8000/v1??????? |??????? http://153.65.235.39:8000/v1??????? |??????? http://153.65.235.39:8000/v1??????? | 43f4318c522646c2bdd44d6e9e09edfe |\n| ecc1cd7cbad8461281181a879286c2bf |? myregion |??????? http://153.65.235.39:9292/v2??????? |??????? http://153.65.235.39:9292/v2??????? |??????? http://153.65.235.39:9292/v2??????? | 6bd3e90b00a743cfa4a94050f87319aa |\n| fe815ceefd0544f2abd16c484cab1b27 |? myregion |???????? http://153.65.235.39:8777????????? |???????? http://153.65.235.39:8777????????? |???????? http://153.65.235.39:8777????????? | 4aa31f280a1e40888d45119c02149a01 |\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n\n\nkeystone service-list\n?keystone service-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+------------+----------------+----------------------------------+\n|??????????????? id??????????????? |??? name??? |????? type????? |?????????? description??????????? |\n+----------------------------------+------------+----------------+----------------------------------+\n| 4aa31f280a1e40888d45119c02149a01 | ceilometer |??? metering??? |??? openstack metering service??? |\n| aed8babcd157477b827c7a2ce89a641c |?? cinder?? |???? volume???? |???? openstack volume service???? |\n| 5bc96b5587aa4f12919f3a155b5713b0 |??? ec2???? |????? ec2?????? |?????????? ec2 service??????????? |\n| 6bd3e90b00a743cfa4a94050f87319aa |?? glance?? |???? image????? |???? openstack image service????? |\n| 3308b160d21f4dac84b866063852a47a |??? heat??? | orchestration? | openstack orchestration service? |\n| 43f4318c522646c2bdd44d6e9e09edfe |? heat-cfn? | cloudformation | openstack cloudformation service |\n| c5196b9c3d5446bdb63ee3b8f40d67f7 |? keystone? |??? identity??? |??? openstack identity service??? |\n| a7a32598413a435687e9919c6add1647 |? neutron?? |??? network???? |?? openstack networking service?? |\n| 4d7a03c577304e3381a3d08ba74a70dc |??? nova??? |??? compute???? |??? openstack compute service???? |\n+----------------------------------+------------+----------------+----------------------------------+\n\n\nSo this means that normal configuration works ok.\nNow I will try to configure http authentication and the steps that I am using are the following:\n1) service keystone stop\n2) create the file /etc/apache2/conf.d/wsgi-keystone.conf with the following content:\nListen 5000\n<VirtualHost *:5000>\nWSGIScriptAlias /keystone/main /var/www/cgi-bin/keystone/main\n</VirtualHost>\nListen 35357\n<VirtualHost *:35357>\nWSGIScriptAlias /keystone/admin /var/www/cgi-bin/keystone/admin\n</VirtualHost>\n\n\n3) Both /var/www/cgi-bin/keystone/main and /var/www/cgi-bin/keystone/admin have the following content:\n# Copyright 2013 OpenStack Foundation\n#\n#??? Licensed under the Apache License, Version 2.0 (the \"License\"); you may\n#??? not use this file except in compliance with the License. You may obtain\n#??? a copy of the License at\n#\n#???????? http://www.apache.org/licenses/LICENSE-2.0\n#\n#??? Unless required by applicable law or agreed to in writing, software\n#??? distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT\n#??? WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the\n#??? License for the specific language governing permissions and limitations\n#??? under the License.\n\nimport logging\nimport os\n\nfrom paste import deploy\n\nfrom keystone.openstack.common import gettextutils\n\n# NOTE(blk-u):\n# gettextutils.install() must run to set _ before importing any modules that\n# contain static translated strings.\ngettextutils.install(\'keystone\', lazy=True)\n\nfrom keystone.common import dependency\nfrom keystone.common import environment\nfrom keystone.common import sql\nfrom keystone import config\nfrom keystone.openstack.common import log\nfrom keystone import service\n\n\nCONF = config.CONF\n\nconfig.configure()\nsql.initialize()\nconfig.set_default_for_default_log_levels()\n\nCONF(project=\'keystone\')\nconfig.setup_logging()\n\nenvironment.use_stdlib()\nname = os.path.basename(__file__)\n\n\nif CONF.debug:\n??? CONF.log_opt_values(log.getLogger(CONF.prog), logging.DEBUG)\n\n\ndrivers = service.load_backends()\n\n# NOTE(ldbragst): \'application\' is required in this context by WSGI spec.\n# The following is a reference to Python Paste Deploy documentation\n# http://pythonpaste.org/deploy/\napplication = deploy.loadapp(\'config:%s\' % config.find_paste_config(),\n???????????????????????????? name=name)\n\ndependency.resolve_future_dependencies()\n?????????????????????????????????????????????????????????????? \n\n4) service apache2 restart\nroot at ubuntu1204:~# netstat -ntlp|grep 5000\ntcp??????? 0????? 0 0.0.0.0:5000??????????? 0.0.0.0:*?????????????? LISTEN????? 23078/apache2\nroot at ubuntu1204:~# netstat -ntlp|grep 35357\ntcp??????? 0????? 0 0.0.0.0:35357?????????? 0.0.0.0:*?????????????? LISTEN????? 23078/apache2\n\n\n5) source openstackrchttp with the following content:\nexport OS_TENANT_NAME=admin\nexport OS_USERNAME=admin\nexport OS_PASSWORD=admin\nexport SERVICE_TOKEN=ADMIN\nexport OS_AUTH_URL=\"http://10.65.235.39:5000/keystone/main\"\nexport SERVICE_ENDPOINT=\"http://10.65.235.39:35357/keystone/admin\"\n\n\n6) keystone user-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\nUnable to communicate with identity service: <!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator,\n?[no address given] and inform them of the time the error occurred,\nand anything you might have done that may have\ncaused the error.</p>\n<p>More information about this error may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.2.22 (Ubuntu) Server at 10.65.235.39 Port 35357</address>\n</body></html>\n. (HTTP 500)\n\n\n\nWhat is lacking? What else should be done? If we will find a solution we can write a very clear document with steps to configure keystone with http authentication on ubuntu with openstack havana.\n\n\nThanks a lot,\nGabriel\n\n\n\n\n\n\n\n\n\n\nOn Wednesday, February 19, 2014 6:54 PM, Dave Walker <email at daviey.com> wrote:\n \nHi Staicu,\n\nWhich release of Openstack are you using?\n? - The distro shouldn\'t really matter in this instance.\nWhat Auth method are you attempting to do through Apache?\n?  - Simple Auth, Kerberos?\nWhat are you using in your dispatcher file (wsgi / fcgi plumbing)?\nWhat behaviour are you seeing?\n? - Is REMOTE_USER environ being set?\n\n\nOn 19 February 2014 16:51, Staicu Gabriel <gabriel_staicu at yahoo.com> wrote:\n> Hi,\n>\n> Is there someone who did the keystone to delegate authentication to apache\n> on ubuntu/havana.\n> I have read these documents but nothing is clear:\n> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/Configuring_the_Identity_Service_to_Run_in_HTTPD.html\n> https://wiki.openstack.org/wiki/Talk:Keystone_in_HTTPD_on_RHEL6\n> http://docs.openstack.org/developer/keystone/apache-httpd.html\n>\n> It seams like everyone is telling half of the truth....:)\n>\n> Is there any other place where I could understand how you could do it on\n> ubuntu?\n>\n> Thanks a lot,\n> Gabriel\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to? ?  : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140220/cc64eba1/attachment.html>\n\n','<CACyjiAjFOSFrHymCK9NBXzODL48m5NMMTTp9Bg9_Zw+sTH0T7Q@mail.gmail.com>',NULL),('<1392896403.16704.19.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 12:40:03',3600,'2014-02-20 11:40:03',NULL,'[openstack-dev] [Horizon] [TripleO] [Tuskar] Thoughts on editing\n node profiles (aka flavors in Tuskar UI)','Hi.\n\nWhile implementing CRUD operations for node profiles in Tuskar (which\nare essentially Nova flavors renamed) I encountered editing of flavors\nand I have some doubts about it.\n\nEditing of nova flavors in Horizon is implemented as\ndeleting-then-creating with a _new_ flavor ID.\nFor us it essentially means that all links to flavor/profile (e.g. from\novercloud role) will become broken. We had the following proposals:\n- Update links automatically after editing by e.g. fetching all\novercloud roles and fixing flavor ID. Poses risk of race conditions with\nconcurrent editing of either node profiles or overcloud roles.\n  Even worse, are we sure that user really wants overcloud roles to be\nupdated?\n- The same as previous but with confirmation from user. Also risk of\nrace conditions.\n- Do not update links. User may be confused: operation called \"edit\"\nshould not delete anything, nor is it supposed to invalidate links. One\nof the ideas was to show also deleted flavors/profiles in a separate\ntable.\n- Implement clone operation instead of editing. Shows user a creation\nform with data prefilled from original profile. Original profile will\nstay and should be deleted manually. All links also have to be updated\nmanually.\n- Do not implement editing, only creating and deleting (that\'s what I\ndid for now in https://review.openstack.org/#/c/73576/ ).\n\nAny ideas on what to do?\n\nThanks in advance,\nDmitry Tantsur\n\n\n\n',NULL,NULL),('<1392905292.16704.20.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 15:08:12',3600,'2014-02-20 14:08:12',NULL,'[openstack-dev] [Horizon] [TripleO] [Tuskar] Thoughts on\n editing node profiles (aka flavors in Tuskar UI)','I think we still are going to multiple flavors for I, e.g.:\nhttps://review.openstack.org/#/c/74762/\nOn Thu, 2014-02-20 at 08:50 -0500, Jay Dobies wrote:\n> \n> On 02/20/2014 06:40 AM, Dmitry Tantsur wrote:\n> > Hi.\n> >\n> > While implementing CRUD operations for node profiles in Tuskar (which\n> > are essentially Nova flavors renamed) I encountered editing of flavors\n> > and I have some doubts about it.\n> >\n> > Editing of nova flavors in Horizon is implemented as\n> > deleting-then-creating with a _new_ flavor ID.\n> > For us it essentially means that all links to flavor/profile (e.g. from\n> > overcloud role) will become broken. We had the following proposals:\n> > - Update links automatically after editing by e.g. fetching all\n> > overcloud roles and fixing flavor ID. Poses risk of race conditions with\n> > concurrent editing of either node profiles or overcloud roles.\n> >    Even worse, are we sure that user really wants overcloud roles to be\n> > updated?\n> \n> This is a big question. Editing has always been a complicated concept in \n> Tuskar. How soon do you want the effects of the edit to be made live? \n> Should it only apply to future creations or should it be applied to \n> anything running off the old configuration? What\'s the policy on how to \n> apply that (canary v. the-other-one-i-cant-remember-the-name-for v. \n> something else)?\n> \n> > - The same as previous but with confirmation from user. Also risk of\n> > race conditions.\n> > - Do not update links. User may be confused: operation called \"edit\"\n> > should not delete anything, nor is it supposed to invalidate links. One\n> > of the ideas was to show also deleted flavors/profiles in a separate\n> > table.\n> > - Implement clone operation instead of editing. Shows user a creation\n> > form with data prefilled from original profile. Original profile will\n> > stay and should be deleted manually. All links also have to be updated\n> > manually.\n> > - Do not implement editing, only creating and deleting (that\'s what I\n> > did for now in https://review.openstack.org/#/c/73576/ ).\n> \n> I\'m +1 on not implementing editing. It\'s why we wanted to standardize on \n> a single flavor for Icehouse in the first place, the use cases around \n> editing or multiple flavors are very complicated.\n> \n> > Any ideas on what to do?\n> >\n> > Thanks in advance,\n> > Dmitry Tantsur\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5306083C.8010301@redhat.com>',NULL),('<1392930568.2453.18.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 16:09:28',-18000,'2014-02-20 21:09:28',NULL,'[openstack-dev] Monitoring IP Availability','On Thu, 2014-02-20 at 00:53 +0000, Vilobh Meshram wrote:\n> Hello OpenStack Dev,\n> \n> We wanted to have your input on how different companies/organizations,\n> using Openstack, are monitoring IP availability as this can be useful\n> to track the used IP?s and total number of IP?s.\n\nI presume you are talking about monitoring the number of available\npublic floating IP addresses? At AT&T, we just had a Nagios check that\nqueried the Nova or Neutron database to see if the number of available\npublic IP addresses went below a certain threshold.\n\nBest,\n-jay\n\n\n\n\n','<CF2A921E.158A%vilobhmm@yahoo-inc.com>',NULL),('<1392938223-sup-3037@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-20 23:46:53',0,'2014-02-20 23:46:53',NULL,'[Openstack] Galera + pt-archiver issues?','Excerpts from Matthew Mosesohn\'s message of 2014-02-20 16:03:44 +0000:\n> Hi Stackers,\n> \n> I\'m curious to find out if we have anyone already using pt-archiver to\n> purge Keystone tokens in MySQL + Galera in production under heavy load with\n> Galera in multi-master mode. I\'m referring to the tripleo script that uses\n> pt-archiver to clean up keystone tokens here:\n> https://github.com/openstack/tripleo-image-elements/blob/master/elements/keystone/cleanup-keystone-tokens.sh\n> \n> I have two questions:\n> Does this need to be run on every Galera host or just against one?\n> Second, does it have any major impact on production? What is the likelihood\n> of causing issues with API DB transactions while pt-archiver is purging\n> keystone tokens table?\n> \n\nIt just need to be run \"somewhere\".\n\nThe script does 500 row transactions, which should prevent long locks\nslowing down writes to the gaps between the ids and I think will lessen\nthe liklihood of any commit failures.\n\n\n','<CADRS-ycw9X_RNbeyfggv8uF4woOWVcKXy_VqZ0uwAKj0WR_e0A@mail.gmail.com>',NULL),('<1392961946.2496.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 00:52:26',-18000,'2014-02-21 05:52:26',NULL,'[openstack-dev] [Nova] v3 API in Icehouse','On Thu, 2014-02-20 at 08:22 -0500, Sean Dague wrote:\n> I agree that we shouldn\'t be rushing something that\'s not ready, but I\n> guess it raises kind of a meta issue.\n> \n> When we started this journey this was because v2 has a ton of warts, is\n> completely wonky on the code internals, which leads to plenty of bugs.\n> v3 was both a surface clean up, but it was also a massive internals\n> clean up. I think comparing servers.py:create is a good look at the\n> differences:\n> \n> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L768\n> - v2\n> \n> vs.\n> \n> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/plugins/v3/servers.py#L415\n> - v3\n> \n> v3 was small on user surface changes for a reason, because the idea was\n> that it would be a quick cut over, the migration pain would be minimal,\n> and v2 could be dropped relatively quickly (2 cycles).\n> \n> However.... if the new thinking is that v2 is going to be around for a\n> long time then I think it raises questions about this whole approach.\n> Because dual maintenance is bad. We see this today where stable/* trees\n> end up broken in CI for weeks because no one is working on it.\n> \n> We\'re also duplicating a lot of test and review energy in having 2 API\n> stacks. Even before v3 has come out of experimental it\'s consumed a huge\n> amount of review resource on both the Nova and Tempest sides to get it\n> to it\'s current state.\n> \n> So my feeling is that in order to get more energy and focus on the API,\n> we need some kind of game plan to get us to a single API version, with a\n> single data payload in L (or on the outside, M). If the decision is v2\n> must be in both those releases (and possibly beyond), then it seems like\n> asking other hard questions.\n> \n> * why do a v3 at all? instead do we figure out a way to be able to\n> evolve v2 in a backwards compatible way.\n> * if we aren\'t doing a v3, can we deprecate XML in v2 in Icehouse so\n> that working around all that code isn\'t a velocity inhibitor in the\n> cleanups required in v2? Because some of the crazy hacks that exist to\n> make XML structures work for the json in v2 is kind of special.\n> \n> This big bang approach to API development may just have run it\'s course,\n> and no longer be a useful development model. Which is good to find out.\n> Would have been nice to find out earlier... but not all lessons are easy\n> or cheap. :)\n\nAll excellent points, Sean.\n\nI would add that I personally would love to see all API extensions\nremoved from the API eventually. I\'d also love to see the use of JSON\nSchema and JSON-Home utilized across the API for discovery purposes.\n\nBest,\n-jay\n\n\n\n','<530601B1.6070502@dague.net>',NULL),('<1392989589.20724.51.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 13:33:09',0,'2014-02-21 13:33:09',NULL,'[openstack-dev] supported dependency versioning and testing','On Thu, 2014-02-20 at 10:31 -0800, Joe Gordon wrote:\n> Hi All,\n> \n> I discussion recently came up inside of nova about what it means\n> supported version for a dependency means.  in libvirt we gate on the\n> minimal version that we support but for all python dependencies we\n> gate on the highest version that passes our requirements. While we all\n> agree that having two different ways of choosing which version to test\n> (min and max) is bad, there are good arguments for doing both.\n> \n> testing most recent version:\n>     * We want to make sure we support the latest and greatest\n>     * Bug fixes\n>     * Quickly discover backwards incompatible changes so we can deal\n> with them as they arise instead of in batch\n> \n> Testing lowest version supported:\n>     * Make sure we don\'t land any code that breaks compatibility with\n> the lowest version we say we support\n\nGood summary.\n\n> A few questions and ideas on how to move forward.\n>     * How do other projects deal with this? This problem isn\'t unique\n> in OpenStack.\n>     * What are the issues with making one gate job use the latest\n> versions and one use the lowest supported versions?\n\nI think this would be very useful.\n\nObviously it would take some effort on someone\'s part to set this up\ninitially, but I don\'t immediately see it being much of an ongoing\nburden on developers.\n\n>     * Only test some things on every commit or every day (periodic\n> jobs)? But no one ever fixes those things when they break? who wants\n> to own them? distros? deployers?\n\nThe gate job above would most likely lead to us trying hard to maintain\nsupport for older.\n\nA periodic job would either go stale or we\'d keep it going simply by\ndropping support for older libraries. (Maybe that\'s ok)\n\n>     * Other solutions?\n>     * Does it make sense to gate on the lowest version of libvirt but\n> the highest version of python libs?\n\nWe might be unconsciously drawing a platform vs app line here - that\nlibvirt is part of the platform and the python library stack is part of\nour app - while still giving a nod to supporting the notion that the\npython library stack is part of the platform.\n\nPut it another way - we\'d be wary of dropping support for an older\nlibvirt (because it rules out support for a platform) but not so much\nwith dropping support for an older python library (because meh, it\'s not\n*really* part of the platform).\n\nOr another way, we give explicit guidance about what exact versions of\nlibvirt we support (i.e. test with specific distros and whatever\nversions of libvirt they have) and leave those versions newer than the\noldest version we explicitly support as a grey area. Similarly, we give\nexplicit guidance about the exact python library stack we support (i.e.\nwhat we test now in the gate) and leave the older versions as a grey\narea.\n\nPerhaps rather than focusing on making this absolutely black and white,\nwe should focus on better communicating what we actually focus our\ntesting on? (i.e. rather than making the grey areas black, improve the\nwhite areas)\n\nConcretely, for every commit merged, we could publish:\n\n  - the set of commits tested\n  - details of the jobs passed:\n      - the distro\n      - installed packages and versions\n      - output of pip freeze\n      - configuration used\n      - tests passed\n\nMeh, feeling like I\'m going off-topic a bit.\n\nMark.\n\n\n\n','<CAHXdxOeppCqLHqS=VR6T+1Nf=FN3gbj5KAL14Vv-u6oxuEm4OA@mail.gmail.com>',NULL),('<1393007376.2496.34.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 13:29:36',-18000,'2014-02-21 18:29:36',NULL,'[openstack-dev] [Neutron][LBaaS] Object Model discussion','On Thu, 2014-02-20 at 15:21 +0400, Eugene Nikanorov wrote:\n\n>         I agree with Samuel here.  I feel the logical model and other\n>         issues\n>         (implementation etc.) are mixed in the discussion.\n>  \n> A little bit. While ideally it\'s better to separate it, in my opinion\n> we need to have some \'fair bit\' of implementation details\n> in API in order to reduce code complexity (I\'ll try to explain it on\n> the meeting). Currently these \'implementation details\' are implied\n> because we deal with simplest configurations which maps 1:1 to a\n> backend.\n\nI disagree on this point. I believe that the more implementation details\nbleed into the API, the harder the API is to evolve and improve, and the\nless flexible the API becomes.\n\nI\'d personally love to see the next version of the LBaaS API be a\ncomplete breakaway from any implementation specifics and refocus itself\nto be a control plane API that is written from the perspective of the\n*user* of a load balancing service, not the perspective of developers of\nload balancer products.\n\nThe user of the OpenStack load balancer service would be able to call\nthe API in the following way (which represents more how the user thinks\nabout the problem domain):\n\nneutron balancer-type-list\n\n# Returns a list of balancer types (flavors) that might\n# look something like this perhaps (just an example off top of head):\n\n- simple:\n    capabilities:\n      topologies:\n        - single-node\n      algorithms:\n        - round-robin\n      protocols:\n        - http\n      max-members: 4\n- advanced:\n    capabilities:\n      topologies:\n        - single-node\n        - active-standby\n      algorithms:\n        - round-robin\n        - least-connections\n      protocols:\n        - http\n        - https\n      max-members: 100\n   \n# User would then create a new balancer from the type:\n\nneutron balancer-create --type=advanced --front=<ip> \\\n --back=<list_of_ips> --algorithm=\"least-connections\" \\\n --topology=\"active-standby\"\n\n# Neutron LBaaS goes off and does a few things, then perhaps\n# user would run:\n\nneutron balancer-show <balancer_id>\n\n# which might return the following:\n\nfront:\n  ip: <ip>\n  nodes:\n    - <uuid> <-- could be a hardware device ID or a VM ID\n      ip: <fixed_ip>\n      status: ACTIVE\n    - <uuid>\n      ip: <fixed_ip>\n      status: STANDBY\nback:\n  nodes:\n    - <uuid> <-- could be ID of an appliance or a VM ID\n      ip: <fixed_ip>\n      status: ONLINE\n    - <uuid>\n      ip: <fixed_ip>\n      status: ONLINE\n    - <uuid>\n      ip: <fixed_ip>\n      status: OFFLINE\n\nNo mention of pools, VIPs, or really much else other than a \"balancer\"\nand the balancer \"type\", which describes capabilities and restrictions\nfor a class of balancers. All implementation details are hidden behind\nthe API. How Neutron LBaaS stores the data behind the scenes should not\ninfluence the forward user-facing API.\n\nJust my two cents,\n-jay\n\n    \n\n\n\n\n','<CAJfiwOQtNtrya5f-sT-jTbt_5UdXghXPhexxEdoaBXXXvFyBGg@mail.gmail.com>',NULL),('<1393010244.2496.42.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 14:17:24',-18000,'2014-02-21 19:17:24',NULL,'[openstack-dev] [Neutron][LBaaS] Object Model discussion','On Fri, 2014-02-21 at 22:58 +0400, Eugene Nikanorov wrote:\n> Hi Jay,\n> \n> Just a quick response:\n> \n> The \'implementation detail in API\' that we all are arguing about is\n> some hint from the user about how logical configuration is mapped on\n> the backend(s), not much detail IMO. \n> \n> Your proposed model has that, because you create the balancer at once\n> and the driver can easily map submitted configuration to *some*\n> backend or even decide how to split it.\n> Things get more complicated when you need fine-grained control.\n\nCould you provide some examples -- even in the pseudo-CLI commands like\nI did below. It\'s really difficult to understand where the limits are\nwithout specific examples.\n\n> Looking at your proposal it reminds me Heat template for\n> loadbalancer. \n> It\'s fine, but we need to be able to operate on particular objects.\n\nI\'m not ruling out being able to add or remove nodes from a balancer, if\nthat\'s what you\'re getting at?\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwOQJLouzswH3Nw8avjbOSQTQRy4uUqtXd1uKwaOLozQ-Ew@mail.gmail.com>',NULL),('<1393011727.2496.44.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 14:42:07',-18000,'2014-02-21 19:42:07',NULL,'[openstack-dev] [Neutron][LBaaS] Feedback on SSL implementation','On Wed, 2014-02-19 at 22:01 -0800, Stephen Balukoff wrote:\n\n> Front-end versus back-end protocols:\n> It\'s actually really common for a HTTPS-enabled front-end to speak\n> HTTP to the back-end.  The assumption here is that the back-end\n> network is \"trusted\" and therefore we don\'t need to bother with the\n> (considerable) extra CPU overhead of encrypting the back-end traffic.\n> To be honest, if you\'re going to speak HTTPS on the front-end and the\n> back-end, then the only possible reason for even terminating SSL on\n> the load balancer is to insert the X-Fowarded-For header. In this\n> scenario, you lose almost all the benefit of doing SSL offloading at\n> all!\n\nThis is exactly correct.\n\n> If we make a policy decision right here not to allow front-end and\n> back-end protocol to mismatch, this will break a lot of topologies.\n\nYep.\n\nBest,\n-jay\n\n\n\n\n','<CAAGw+ZqrdMmGNXWun=mmw2o8A-UrE8Xu4irCR8Yw=H2boAU9Bg@mail.gmail.com>',NULL),('<1393026750.5487.21.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 15:52:30',-28800,'2014-02-21 23:52:30',NULL,'[openstack-dev] [nova] pci device hotplug','On Mon, 2014-02-17 at 06:43 +0000, Gouzongmei wrote:\n> Hello,\n> \n>  \n> \n> In current PCI passthrough implementation, a pci device is only\n> allowed to be assigned to a instance while the instance is being\n> created, it is not allowed to be assigned or removed from the instance\n> while the instance is running or stop. \n> \n> Besides, I noticed that the basic ability--remove a pci device from\n> the instance(not by delete the flavor) has never been implemented or\n> prompted by anyone.\n> \n> The current implementation:\n> \n> https://wiki.openstack.org/wiki/Pci_passthrough\n> \n>  \n> \n> I have tested the nic hotplug on my experimental environment, it?s\n> supported by the latest libvirt and qemu.\n> \n>  \n> \n> My problem is, why the pci device hotplug is not proposed in openstack\n> until now, and is there anyone planning to do the pci device hotplug?\n\nAgree that PCI hotplug is an important feature. The reason of no support\nyet is bandwidth. The folks working on PCI spend a lot of time on SR-IOV\nNIC discussion.\n\n--jyh\n\n\n\n\n','<9C68F34C9BE05144BF869F8143852E544D5F80F7@szxema506-mbx.china.huawei.com>',NULL),('<1393059596.93969.1390492754999.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 15:59:15',0,'2014-01-23 15:59:15',NULL,'[openstack-dev] [Keystone] bp proposal: quotas on users and\n projects per domain','Hi, \n\nAlthough it is true that projects and users don\'t consume a lot of resources, I think that there may be cases where setting quotas (possibly large) may be useful. \n\nFor instance, a cloud provider may wish to prevent domain administrators to mistakingly create an infinite number of users and/or projects, by calling APIs in a bugging loop. \n\nMoreover, if quotas can be disabled, I don\'t see any reason not to allow cloud operators to set quotas on users and/or projects if they wishes to do so for whatever marketing reason (e.g. charging more to allow more users or projects). \n\nRegards, \nFlorent Flament \n\n\n----- Original Message -----\n\nFrom: \"Dolph Mathews\" <dolph.mathews at gmail.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nSent: Thursday, January 23, 2014 3:09:51 PM \nSubject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain \n\n... why? It strikes me as a rather shallow business decision to limit the number of users or projects in a system, as neither are actually cost-consuming resources. \n\nOn Thu, Jan 23, 2014 at 6:43 AM, Matthieu Huin < matthieu.huin at enovance.com > wrote: \n\n\nHello, \n\nI\'d be interested in opinions and feedback on the following blueprint: https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas \n\nThe idea is to add a mechanism preventing the creation of users or projects once a quota per domain is met. I believe this could be interesting for cloud providers who delegate administrative rights under domains to their customers. \n\nI\'d like to hear the community\'s thoughts on this, especially in terms of viability. \n\nMany thanks, \n\nMatthieu Huin \n\nmhu at enovance.com \nhttp://www.enovance.com \neNovance SaS - 10 rue de la Victoire 75009 Paris - France \n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/dab8a1fa/attachment.html>\n\n','<CAC=h7gWax7w+Qnw_dDrg+KVN+VEhCWHxHnAM28vbJq_-dO7nPQ@mail.gmail.com>',NULL),('<1393114467-sup-2175@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-23 00:16:10',0,'2014-02-23 00:16:10',NULL,'[openstack-dev] [TripleO][Tuskar] Dealing with passwords in\n	Tuskar-API','Excerpts from Imre Farkas\'s message of 2014-02-20 15:24:17 +0000:\n> On 02/20/2014 03:57 PM, Tomas Sedovic wrote:\n> > On 20/02/14 15:41, Radomir Dopieralski wrote:\n> >> On 20/02/14 15:00, Tomas Sedovic wrote:\n> >>\n> >>> Are we even sure we need to store the passwords in the first place? All\n> >>> this encryption talk seems very premature to me.\n> >>\n> >> How are you going to redeploy without them?\n> >>\n> >\n> > What do you mean by redeploy?\n> >\n> > 1. Deploy a brand new overcloud, overwriting the old one\n> > 2. Updating the services in the existing overcloud (i.e. image updates)\n> > 3. Adding new machines to the existing overcloud\n> > 4. Autoscaling\n> > 5. Something else\n> > 6. All of the above\n> >\n> > I\'d guess each of these have different password workflow requirements.\n> \n> I am not sure if all these use cases have different password \n> requirement. If you check devtest, no matter whether you are creating or \n> just updating your overcloud, all the parameters have to be provided for \n> the heat template:\n> https://github.com/openstack/tripleo-incubator/blob/master/scripts/devtest_overcloud.sh#L125\n> \n> I would rather not require the user to enter 5/10/15 different passwords \n> every time Tuskar updates the stack. I think it\'s much better to \n> autogenerate the passwords for the first time, provide an option to \n> override them, then save and encrypt them in Tuskar. So +1 for designing \n> a proper system for storing the passwords.\n\nTuskar does not need to reinvent this.\n\nUse OS::Heat::RandomString in the templates.\n\nIf any of them need to be exposed to the user, use an output on the\ntemplate.\n\nIf they need to be regenerated, you can pass a \"salt\" parameter.\n\n\n','<53061E21.9000807@redhat.com>',NULL),('<1393128288-sup-1946@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-22 20:09:42',-28800,'2014-02-23 04:09:42',NULL,'[Openstack-operators] OpenStack Operators Gathering on March\n	3rd in San Jose','Tim, were you aware this will be going on at the exact same time as the\nTripleO summit, which is happening just down the road in Sunnyvale the\nsame week?\n\nI would like to see some mixing of these two groups. Perhaps we could have\nsome operators come over to the TripleO summit one day, or the other way\naround, as I think feedback from the operators on what we have working\nnow and what we\'re proposing going forward would be extremely helpful.\n\nExcerpts from Tim Bell\'s message of 2014-02-21 09:37:22 -0800:\n> We are organising an OpenStack operators mini-summit in the Bay Area on Monday March 3rd in order to gather input for key needs from an OpenStack operator for development effort in the Juno release.\n>  \n> There are a limited number of places available so early registration is recommended. A further session will be arranged around the Atlanta summit.\n>  \n> The details are at https://www.eventbrite.co.uk/e/openstack-march-2014-operators-gathering-tickets-10318369521\n>  \n> Note: There will be no \'presentations\' on what OpenStack is, or how people are using it in their companies, outside of free-ranging discussion on these requirements. This is not an \"operations best\n> practice\" discussion - the aim is purely on getting feedback on what is/isn\'t working and what needs to change.\n> \n> For further background, a few questions & answers...\n>  \n> What is an Operators\' mini-Summit?\n>  \n> This is an attempt to bring together OpenStack operators of various \n> sizes and use cases and gather targeted feedback for the Technical \n> committee, PTL\'s and dev teams.  The goals of the meeting are to \n> prioritize issues/requests from the representative group of \n> operators, attempt to produce a blueprint or two from the top of that \n> list and introduce it all back into the development cycle for Juno.\n>  \n> How was this event organized?\n> \n> The event was born out of discussion on the operators mailing list and has been \n> organized over the last couple of months by the user committee, Tom Fifield \n> (user community manager at the Foundation) and several volunteers from the OpenStack operator\n> community .  It\'s the first time we\'ve done something like this, and is as much an experiment on the \n> best way to build this process as it is an event \n> for the gathering of feedback itself.\n> \n> How many people are you expecting to attend?\n> \n> We have capacity for 75 attendees, and we are limiting attendees to those operating OpenStack clouds \n> (not building products for or around OpenStack).  The event wil be hosted at eBay headquarters. \n> Since it is the first one, the organizing group deliberately wanted to keep things \n> on the smaller side to make sure we enable productive discussions.  We really want the gathering of feedback \n> to be useful and actionable.  Hopefully we can create a repeatable mechanism that gives more \n> and more operators useful ways to influence OpenStack design and prioritization as it evolves.\n> \n> When will the next Operator\'s mini-Summit take place, and will it allow for more attendees?\n>  \n> The next gathering is planned to take place during the OpenStack Summit in May 2014. The exact\n> details and dates will be discussed during this event in March and shared shortly thereafter. \n> It\'s important we make this first event a success - and something we can build on - in size, \n> frequency and regional diversity.\n>  \n> Why is this called a summit?\n> \n> Because, like the Design summit, this meeting is focused on what is \n> built in the next version of OpenStack.  It just happens to be from an \n> operator\'s perspective.  It\'s more than a meet up and is not a \n> conference or tech talk in anyway - there won\'t be howto\'s and \n> presentations.  It\'s a chance for the people that regularly deploy \n> and run OpenStack to share what works, what doesn\'t, and how to make the product better for everyone.\n> \n> Why is this being held in March and not during the OpenStack Summit in May?\n> \n> The earlier we can provide input into the design process, the better, so we can influence\n> the sessions and conversations that will take place at the Atlanta Summit. We are planning\n> to meet again at that time, but want to provide feedback prior to the technical community gathering\n> in May. \n> \n> Where will you be sharing the outcomes, and how I can provide input if I\'m not able to attend?\n> \n> First, make sure you have filled out the user survey, which is a great opportunity to share your \n> feedback and completely confidential at your request. http://www.openstack.org/user-survey\n> We are referencing feedback from the survey in this session and again at the Atlanta Summit. \n> \n> We will be circulating more details of the way people can provide input remotely before the event along with publishing the notes afterwards for further comment.\n> \n> Tim, Ryan, JC, Tom, Sean, Matt and Subbu\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9A31CCB@CERNXCHG41.cern.ch>',NULL),('<1393180875.2496.52.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-23 13:41:15',-18000,'2014-02-23 18:41:15',NULL,'[openstack-dev] [nova][libvirt] Is there anything blocking the\n libvirt driver from implementing the host_maintenance_mode API?','On Sun, 2014-02-23 at 09:14 +0800, Jay Lau wrote:\n> So there is no need to implement libvirt driver for the\n> host_maintenance_mode API as host_maintenance_mode is mainly for\n> VMWare and XenServer, also we can use evacuate and os-services/disable\n> for libvirt host maintain, right?\n\nAt a minimum, can we please make the API consistent in regards to what\nwe call this operation (evacuation, \"host maintenance\", enable/disable,\netc).\n\nDeath to API extensions.\n\nBest,\n-another jay\n\n\n\n\n','<CAFyztAFB=ZgN+LcrOwEAq4dcpagm6PJMsD4Y_2n47JJiqKUEkg@mail.gmail.com>',NULL),('<139319138.2817764.1371540295841.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-18 03:24:55',-14400,'2013-06-18 07:24:55',NULL,'[openstack-qa] I need some information about the lab things','Sorry, wrong list.\n\n----- Original Message -----\nFrom: \"Attila Fazekas\" <afazekas at redhat.com>\nTo: \"Jaroslav Henner\" <jhenner at redhat.com>\nCc: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Tuesday, June 18, 2013 9:12:52 AM\nSubject: [openstack-qa] I need some information about the lab things\n\nHi Jaroslav,\n\n1. When will the memory arrive ? Did you get new promise ?\n\n2. Do we have an official statement about the available \"rack space\" ?\n\n3. The swich where the R200 machines connected has a (at least one) 10G free port ?\n\n4. Can you tell me tenant/private switch type number max. vlan/multicast and mac support ?\n\nBest Regards,\nAttila\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<1014934844.2812700.1371539572696.JavaMail.root@redhat.com>',NULL),('<1393195817.6754205.1392473130450.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-15 09:05:30',-18000,'2014-02-15 14:05:30',NULL,'[openstack-dev] [Openstack-operators] [TripleO] consistency\n	vs	packages in TripleO','\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: openstack-operators at lists.openstack.org\n> Sent: Friday, February 14, 2014 11:12:12 PM\n> Subject: Re: [Openstack-operators] [openstack-dev] [TripleO] consistency vs	packages in TripleO\n> \n> On 15 February 2014 08:42, Dan Prince <dprince at redhat.com> wrote:\n> >\n> \n> > Let me restate the options the way I see it:\n> >\n> > Option A is we do our job... by making it possible to install OpenStack\n> > using various distributions using a set of distro agnostic tools\n> > (TripleO).\n> \n> So our job is to be the upstream installer. If upstream said \'we only\n> support RHEL and Ubuntu, our job would arguably end there. And in\n> fact, we\'re being much more inclusive than many other parts of\n> upstream - Suse isn\'t supported upstream, nor is Ubuntu non-LTS, nor\n> Fedora.\n> \n> > Option B is we make our job easy by strong arming everyone into the same\n> > defaults of our \"upstream\" choosing.\n> \n> Does Nova strong arm everyone into using kvm? Its the default. Or\n> keystone into using the SQL token store - its the default?\n\n\nYour initial email didn\'t use the word default at all. You said \"we coerce the package into reference upstream shape as part of installing it\". That sounds like strong arming to me... and is what I\'m concerned with.\n\n> \n> No - defaults are not strong arming. But the defaults are obviously\n> defaults, and inherited by downstreams. And some defaults are larger\n> than others -  we\'ve got well defined interfaces in OpenStack, which\n> have the primary characteristic of \'learn once, apply everywhere\' -\n> even though in principle you can replace them. At the low level REST\n> and message-bus RPCs, at a level up Keystone and more recently Nova\n> and Neutron have become that as we get higher order code like Heat and\n> Savanna that depend on them. I hope none would replace Nova with\n> Eucalyptus and then say they\'re running OpenStack - in the same way\n> we\'re both defining defaults, *and* building interfaces. *That* is our\n> job - making OpenStack *upstream* deployable, in the places, and on\n> the platforms, with the options, that our users want.\n> \n> Further to that, upstream we\'re making choices with the thoughts of\n> our *users* in mind - both cloud consumers and cloud operators. They\n> are why we ask questions like \'is having every install have\n> potentially different usernames for the nova service a good idea\'. The\n> only answer so far has been \'because distros have chosen different\n> usernames already and we need to suck it up\'. Thats not a particularly\n> satisfying answer.\n> \n> > Does option B look appealing? Perhaps at first glance. By taking away the\n> > differences it seems like we are making everyone\'s lives easier by\n> > \"streamlining\" our depoyment codebase. There is this one rub though: it\n> > isn\'t what users expect.\n> \n> I don\'t know what users expect: There\'s an assumption stated in some\n> of the reponses that people which choose \'TripleO + Packages\' do that\n> for a reason. I think this is likely going to be wrong much of the\n> time. Why? Because upstream doesn\'t offer someone to ring when there\n> is a problem. So people will grab RDO, or Suse\'s offering, or\n> Rackspace Private Cloud, or HP Cloud OS, or\n> $distribution-of-openstack-of-choice : and I don\'t expect for most\n> people that \'and we used a nova deb package\' vs \'and we used a nova\n> pip package\' is going to be *why* they choose that vendor, so as a\n> result many people will get TripleO+Packages because their vendor\n> chose that for them. That places a responsibility on the vendors and\n> on us. The vendors need to understand the consequences of their\n> packages varying trivially from upstream - the\n> every-unix-is-a-little-different death of a thousand cuts problem -\n> and we need to help vendors understand the drivers that lead them to\n> need to build images via packages.\n> \n> > Take /mnt/state for example. This isn\'t the normal place for things to\n> > live. Why not use the read only root mechanism some distributions already\n> > have and work with that instead. Or perhaps have /mnt/state as a backup\n> > solution which can be used if a mechanism doesn\'t exist or is faulty?\n> \n> Currently we have two options for upgrading images. A) /mnt/state, B)\n> a SAN + cinder. We haven\'t tested B), and I expect for many installs B\n> won\'t be an option. /mnt/state is 100% technical, as no other options\n> exist - none of the Linux distro \'read only root\' answers today answer\n> the problem /mnt/state solves in a way compatible with Nova.\n\nI would argue that we haven\'t tried all of the read only root mechanism either... at least to the point where we can definitely don\'t work. Sure the data has to go somewhere... but it is how we present this to the end user that is the point in this thread, no?\n\nAll I\'m arguing for here is the ability to avoid doing this to our nova.conf file (what we do today in TripleO):\n\n state_path=/mnt/state/var/lib/nova\n\nAnd instead simply use the Nova default (/var/lib/nova) and have some other mechanism take care of the mapping for us (bind mounts, etc). In the context of end user documentation I certainly think this has less of an impact and is more pleasing to all.\n\n> \n> > In the end I think option A is the way we have to go. Is it more work...\n> > maybe. But in the end users will like us for it. And there is always the\n> > case that by not reimplementing some of the tools and mechanisms which\n> > already exist in distros that this ends up being less work anyways. I do\n> > hope so...\n> \n> Certainly we\'re trying very hard to keep things we reimplement minimal\n> and easily swap-outable (like o-r-c which I expect some deployments\n> will want to replace with chef/puppet).\n> \n> > As for the reference implementation part of A I do hope we choose it wisely\n> > and that as much as possible the distros take note of our choices.\n> \n> +1\n> \n> -Rob\n> \n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<CAJ3HoZ0xmYJft42a1SMRijhUMHauVCXBnzE8VEe3-=XLnY6jvA@mail.gmail.com>',NULL),('<1393195817.6754205.1392473130450.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-15 09:05:30',-18000,'2014-02-15 14:05:30',NULL,'[Openstack-operators] [openstack-dev] [TripleO] consistency\n	vs	packages in TripleO','\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Cc: openstack-operators at lists.openstack.org\n> Sent: Friday, February 14, 2014 11:12:12 PM\n> Subject: Re: [Openstack-operators] [openstack-dev] [TripleO] consistency vs	packages in TripleO\n> \n> On 15 February 2014 08:42, Dan Prince <dprince at redhat.com> wrote:\n> >\n> \n> > Let me restate the options the way I see it:\n> >\n> > Option A is we do our job... by making it possible to install OpenStack\n> > using various distributions using a set of distro agnostic tools\n> > (TripleO).\n> \n> So our job is to be the upstream installer. If upstream said \'we only\n> support RHEL and Ubuntu, our job would arguably end there. And in\n> fact, we\'re being much more inclusive than many other parts of\n> upstream - Suse isn\'t supported upstream, nor is Ubuntu non-LTS, nor\n> Fedora.\n> \n> > Option B is we make our job easy by strong arming everyone into the same\n> > defaults of our \"upstream\" choosing.\n> \n> Does Nova strong arm everyone into using kvm? Its the default. Or\n> keystone into using the SQL token store - its the default?\n\n\nYour initial email didn\'t use the word default at all. You said \"we coerce the package into reference upstream shape as part of installing it\". That sounds like strong arming to me... and is what I\'m concerned with.\n\n> \n> No - defaults are not strong arming. But the defaults are obviously\n> defaults, and inherited by downstreams. And some defaults are larger\n> than others -  we\'ve got well defined interfaces in OpenStack, which\n> have the primary characteristic of \'learn once, apply everywhere\' -\n> even though in principle you can replace them. At the low level REST\n> and message-bus RPCs, at a level up Keystone and more recently Nova\n> and Neutron have become that as we get higher order code like Heat and\n> Savanna that depend on them. I hope none would replace Nova with\n> Eucalyptus and then say they\'re running OpenStack - in the same way\n> we\'re both defining defaults, *and* building interfaces. *That* is our\n> job - making OpenStack *upstream* deployable, in the places, and on\n> the platforms, with the options, that our users want.\n> \n> Further to that, upstream we\'re making choices with the thoughts of\n> our *users* in mind - both cloud consumers and cloud operators. They\n> are why we ask questions like \'is having every install have\n> potentially different usernames for the nova service a good idea\'. The\n> only answer so far has been \'because distros have chosen different\n> usernames already and we need to suck it up\'. Thats not a particularly\n> satisfying answer.\n> \n> > Does option B look appealing? Perhaps at first glance. By taking away the\n> > differences it seems like we are making everyone\'s lives easier by\n> > \"streamlining\" our depoyment codebase. There is this one rub though: it\n> > isn\'t what users expect.\n> \n> I don\'t know what users expect: There\'s an assumption stated in some\n> of the reponses that people which choose \'TripleO + Packages\' do that\n> for a reason. I think this is likely going to be wrong much of the\n> time. Why? Because upstream doesn\'t offer someone to ring when there\n> is a problem. So people will grab RDO, or Suse\'s offering, or\n> Rackspace Private Cloud, or HP Cloud OS, or\n> $distribution-of-openstack-of-choice : and I don\'t expect for most\n> people that \'and we used a nova deb package\' vs \'and we used a nova\n> pip package\' is going to be *why* they choose that vendor, so as a\n> result many people will get TripleO+Packages because their vendor\n> chose that for them. That places a responsibility on the vendors and\n> on us. The vendors need to understand the consequences of their\n> packages varying trivially from upstream - the\n> every-unix-is-a-little-different death of a thousand cuts problem -\n> and we need to help vendors understand the drivers that lead them to\n> need to build images via packages.\n> \n> > Take /mnt/state for example. This isn\'t the normal place for things to\n> > live. Why not use the read only root mechanism some distributions already\n> > have and work with that instead. Or perhaps have /mnt/state as a backup\n> > solution which can be used if a mechanism doesn\'t exist or is faulty?\n> \n> Currently we have two options for upgrading images. A) /mnt/state, B)\n> a SAN + cinder. We haven\'t tested B), and I expect for many installs B\n> won\'t be an option. /mnt/state is 100% technical, as no other options\n> exist - none of the Linux distro \'read only root\' answers today answer\n> the problem /mnt/state solves in a way compatible with Nova.\n\nI would argue that we haven\'t tried all of the read only root mechanism either... at least to the point where we can definitely don\'t work. Sure the data has to go somewhere... but it is how we present this to the end user that is the point in this thread, no?\n\nAll I\'m arguing for here is the ability to avoid doing this to our nova.conf file (what we do today in TripleO):\n\n state_path=/mnt/state/var/lib/nova\n\nAnd instead simply use the Nova default (/var/lib/nova) and have some other mechanism take care of the mapping for us (bind mounts, etc). In the context of end user documentation I certainly think this has less of an impact and is more pleasing to all.\n\n> \n> > In the end I think option A is the way we have to go. Is it more work...\n> > maybe. But in the end users will like us for it. And there is always the\n> > case that by not reimplementing some of the tools and mechanisms which\n> > already exist in distros that this ends up being less work anyways. I do\n> > hope so...\n> \n> Certainly we\'re trying very hard to keep things we reimplement minimal\n> and easily swap-outable (like o-r-c which I expect some deployments\n> will want to replace with chef/puppet).\n> \n> > As for the reference implementation part of A I do hope we choose it wisely\n> > and that as much as possible the distros take note of our choices.\n> \n> +1\n> \n> -Rob\n> \n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<CAJ3HoZ0xmYJft42a1SMRijhUMHauVCXBnzE8VEe3-=XLnY6jvA@mail.gmail.com>',NULL),('<1393220971.9223.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-24 13:49:31',28800,'2014-02-24 05:49:31',NULL,'[Openstack] problem in installing django-swiftbrowser','hi Lysander David,\n\n\nthanks for the reply.\n\nI follow following steps:\n\n1.  \nroot at pragya-VirtualBox:~# wget\nhttps://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9\n-O Django-1.6.2.tar.gz \n\n\n2.  \nroot at pragya-VirtualBox:~# \ntar zxvf Django-1.6.2.tar.gz\n3.  \nroot at pragya-VirtualBox:~# \ncd\nDjango-1.6.2\n\n4.  \nroot at pragya-VirtualBox:~/Django-1.6.2#\nsudo python ./setup.py install\n5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n\nand get the following error:\n\nERROR 1:\npython: can\'t open file \'runtests.py\': [Errno 2] No such file or directory\n\n\n\n\nOn Wednesday, 19 February 2014 12:06 PM, Lysander David <Lysander_David at symantec.com> wrote:\n \nPlease install django.\n>\n>\n>wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz\n>tar zxvf Django-1.6.2.tar.gz\n>cd Django-1.6.2\n>sudo python ./setup.py install\n>\n>\n>From:  pragya jain <prag_2648 at yahoo.co.in>\n>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>Date:  Tuesday, February 18, 2014 9:48 PM\n>To:  \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>, Lysander David <Lysander_David at symantec.com>\n>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>\n>\n>\n>thanks Lysander David for the reply. \n>\n>I again have some problem.\n>\n>I follow the following steps:\n>1.? root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>\n>\n>\n>2.? root at pragya-VirtualBox:~# cd django-swiftbrowser\n>\n>3. \n>root at pragya-VirtualBox:~/django-swiftbrowser# wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O setuptools-2.2.tar.gz \n>\n>4.? \n>root at pragya-VirtualBox:~/django-swiftbrowser# tar zxvf setuptools-2.2.tar.gz \n>5. \n>root at pragya-VirtualBox:~/django-swiftbrowser# cd setuptools-2.2\n>\n>\n>6.? \n>root at pragya-VirtualBox:~/django-swiftbrowser/setuptools-2.2# sudo python ./setup.py install \n>7.? \n>root at pragya-VirtualBox:~/django-swiftbrowser# python runtests.py \n>\n>\n>and I got the following error :\n>\n>\n>Traceback (most recent call last): \n>File \"runtests.py\", line 2, in <module> \n>from django.conf import settings \n>ImportError: No module named django.conf \n>\n>\nPlease help to resolve it.\n>\n>Thanks again \n>\n>pragya Jain\n>\n>\n>\n>\n>\n>\n>On , pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>\n>>\n>>\n>>On Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>>\n>>Please consider installing the setuptools module.\n>>>\n>>>\n>>>The latest archive can be found here:\n>>>\n>>>\n>>>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>>>\n>>>\n>>>You can install it with these commands:\n>>>\n>>>\n>>>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>>>tar zxvf?setuptools-2.2.tar.gz\n>>>cd?setuptools-2.2\n>>>sudo python ./setup.py install\n>>>\n>>>\n>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>Date: Sunday, February 16, 2014 9:55 PM\n>>>To: pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>\n>>>\n>>>\n>>>please someody reply\n>>>\n>>>\n>>>\n>>>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello all,\n>>>>\n>>>>\n>>>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>>>\n>>>>\n>>>>below are the steps which i follow:\n>>>>-----------------\n>>>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>>\n>>>>\n>>>>\n>>>>Cloning into \'django-swiftbrowser\'...\n>>>>remote: Reusing existing pack: 145, done.\n>>>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>>>Resolving deltas: 100% (72/72), done.\n>>>>\n>>>>\n>>>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>>\n>>>>\n>>>>\n>>>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>>>Traceback (most recent call last):\n>>>>? File \"setup.py\", line 2, in <module>\n>>>>??? from setuptools import setup\n>>>>ImportError: No module named setuptools\n>>>>------------\n>>>>\n>>>>\n>>>>But I get the error.\n>>>>Please help inresolving the error.\n>>>>\n>>>>\n>>>>Thanks in advance \n>>>>\n>>>>Pragya Jain\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>\n>>\n>\n>\n\n6.?root at pragya-VirtualBox:~/Django-1.6.2# django-admin.py startproject myproj\n\n\n7. root at pragya-VirtualBox:~/Django-1.6.2# cd myproj\n\n8. root at pragya-VirtualBox:~/Django-1.6.2/myproj# cp ~/django-swiftbrowser/example/settings.py myproj/settings.py\n\n9. root at pragya-VirtualBox:~/Django-1.6.2/myproj# pico myproj/urls.py\n-------\nfrom django.conf.urls import patterns, include, url\n\nfrom django.contrib import admin\nadmin.autodiscover()\n\n#urlpatterns = patterns(\'\',\n??? # Examples:\n??? # url(r\'^$\', \'myproj.views.home\', name=\'home\'),\n??? # url(r\'^blog/\', include(\'blog.urls\')),\n\n?#?? url(r\'^admin/\', include(admin.site.urls)),\n#)\nimport swiftbrowser.urls\n\nurlpatterns = patterns(\'\',\n??? url(r\'^\', include(swiftbrowser.urls)),\n)\n--------------\n\n10. root at pragya-VirtualBox:~/Django-1.6.2/myproj# python manage.py collectstatic\n\nERROR 2:\n\nTraceback (most recent call last):\n? File \"manage.py\", line 10, in <module>\n??? execute_from_command_line(sys.argv)\n? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 399, in execute_from_command_line\n??? utility.execute()\n? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 392, in execute\n??? self.fetch_command(subcommand).run_from_argv(self.argv)\n? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 242, in run_from_argv\n??? self.execute(*args, **options.__dict__)\n? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 280, in execute\n??? translation.activate(\'en-us\')\n? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/__init__.py\", line 130, in activate\n??? return _trans.activate(language)\n? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 188, in activate\n??? _active.value = translation(language)\n? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 177, in translation\n??? default_translation = _fetch(settings.LANGUAGE_CODE)\n? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 159, in _fetch\n??? app = import_module(appname)\n? File \"/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py\", line 40, in import_module\n??? __import__(name)\nImportError: No module named swiftbrowser\n\n----------\n\nI am using the link https://github.com/cschwede/django-swiftbrowser\n\nplease help me to resolve these two errors.\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140224/9e86a772/attachment.html>\n\n','<CF298FC1.2709A%Lysander_David@symantec.com>',NULL),('<1393223874.2874.21.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 16:37:54',36000,'2014-02-24 06:37:54',NULL,'[openstack-dev] [python-openstacksdk] Sessions and keystoneclient','I promised Jesse after the openstack-sdk meeting that I would do a write\nup of the direction of keystoneclient\'s auth plugins and Sessions. Have\na look here: \n\nhttp://www.jamielennox.net/blog/2014/02/24/client-session-objects/\n\nI know that this is different to the way Dean was looking at using them\nin openstackclient however I think it works as a means of standardizing\nclients on a method that doesn\'t have them in charge of anything to do\nwith authentication or service discovery. \n\nIdeally from my point of view openstack-sdk would provide an abstraction\nlayers for the various client objects. Eg, how do we handle a v2 and v3\nconcept of a user, or an instance or anything else across clients. \n\nThe base object would maintain a single session object and create a\nnumber of clients which handle version independent interactions by\nredirecting the calls to the appropriate version dependent client (all\nconnected to the one session object and doing version discovery through\nit).\n\nI\'m still of the impression that the version dependent clients can live\nin the python-*client repositories but we can continue that discussion\nlater. \n\n\nJamie\n\n\n\n',NULL,NULL),('<1393225610.2496.67.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 02:06:50',-18000,'2014-02-24 07:06:50',NULL,'[openstack-dev] [nova] Future of the Nova API','On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote:\n> - Proposed way forward:\n>   - Release the V3 API in Juno with nova-network and tasks support\n>   - Feature freeze the V2 API when the V3 API is released\n>     - Set the timeline for deprecation of V2 so users have a lot\n>       of warning\n>     - Fallback for those who really don\'t want to move after\n>   deprecation is an API service which translates between V2 and V3\n>   requests, but removes the dual API support burden from Nova.\n\nAnd when do you think we can begin the process of deprecating the V3 API\nand removing API extensions and XML \"translation\" support?\n\nBest,\n-jay\n\n\n\n','<20140224172002.6ed77cc7@pingu>',NULL),('<1393229532.67120.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-24 16:12:12',28800,'2014-02-24 08:12:12',NULL,'[Openstack] how to run zenoss zenpack openstack swift','hi all\n\nI have a running openstack Swift environment.\nI want to monitor it using zenoss zenpack Openstack Swift.\n\nWhat should I do to install and run it?\n\npragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140224/0ed7b8c1/attachment.html>\n\n',NULL,NULL),('<1393235936.21862.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-24 17:58:56',28800,'2014-02-24 09:58:56',NULL,'[Openstack] problem in installing django-swiftbrowser','thanks Christian\n\nI follow the steps:\n\n1. root at pragya-VirtualBox:~# cd django-swiftbrowser\n2. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n\nbut get the error:\nhttp://paste.openstack.org/show/68941/\n\n\nplease help\n\nPragya jain\n\n\n\n\nOn Monday, 24 February 2014 2:28 PM, Christian Schwede <christian.schwede at enovance.com> wrote:\n \nHello Pragya,\n>\n>\n>> 5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>>\n>> and get the following error:\n>>\n>> ERROR 1:\n>> python: can\'t open file \'runtests.py\': [Errno 2] No such file or directory\n>\n>you\'re still in the Django-1.6.2 directory, you need to change to the\n>directoy django-swiftbrowser to run the tests for Swiftbrowser.\n>\n>Christian (django-swiftbrowser author)\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140224/9b417a68/attachment.html>\n\n','<530B09A8.5040502@enovance.com>',NULL),('<1393236359.905529241@f75.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-24 14:05:59',14400,'2014-02-24 10:05:59',NULL,'[Openstack] [OT] seeking for Openstack developers',' Hello,\n\nI am not sure if it\'s fine or not to send the jobs message here. I will say sorry if it has disturbed you.\n\nWe YY INC (more specially, the game department, in Zhuhai City, South China) has been seeking the openstack developers since we are developing and deploying the private cloud platform with openstack.\n\nThis is the company\'s profile: \n http://investors.yy.com/overview.cfm\n\nWe are looking for candidates with:\n*  a bachelor?s degree in computer science or a couple of years of relevant experience in software engineering\n*  knowledge of (and ideally experience with) Python\n*  good working knowledge of or experience with git\n*  experience with agile development (including TDD and code reviews)\n*  a desire to learn and hone your professional skills continuously\n*  good team-work/collaboration skills and the ability to deliver to tight deadlines and/or under pressure\n*  oral/written English or Chinese language skills\n\nIn addition to the above the candidate will ideally have:\n*  cloud computing (ideally Openstack)\n*  distributed software design\n*  messaging systems (ideally amqp based)\n*  SQL and NoSQL databases\n*  Linux system administration\nWe speak Chinese. But most of our members speak english well. So language is not a main problem.\n\nAnd the location Zhuhai is a very beautiful city close to the sea.\nhttp://en.wikipedia.org/wiki/Zhuhai\nIt\'s a livable city.\n\nIf you have any interest on this job please write me back.?\n\nThanks.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140224/ff23a01e/attachment.html>\n\n',NULL,NULL),('<1393258922.26205.4.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 11:22:02',-18000,'2014-02-24 16:22:02',NULL,'[openstack-dev] [Neutron]Do you think tanent_id should be\n verified','On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:\n> I think \'tenant_id\' should always be validated when creating neutron\n> resources, whether or not Neutron can handle the notifications from\n> Keystone when tenant is deleted.\n\n-1\n\nPersonally, I think this cross-service request is likely too expensive\nto do on every single request to Neutron. It\'s already expensive enough\nto use Keystone when not using PKI tokens, and adding another round trip\nto Keystone for this kind of thing is not appealing to me. The tenant is\nalready \"validated\" when it is used to get the authentication token used\nin requests to Neutron, so other than the scenarios where a tenant is\ndeleted in Keystone (which, with notifications in Keystone, there is now\na solution for), I don\'t see much value in the extra expense this would\ncause.\n\nBest,\n-jay\n\n\n\n\n','<CALjNAZ3FXgXVyfQ2Yu71b_zCHf8+9_4izqEnTwCmF1NVsEmcMQ@mail.gmail.com>',NULL),('<1393260521.26205.24.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 11:48:41',-18000,'2014-02-24 16:48:41',NULL,'[openstack-dev] [nova] Future of the Nova API','On Mon, 2014-02-24 at 20:22 +1030, Christopher Yeoh wrote:\n> On Mon, 24 Feb 2014 02:06:50 -0500\n> Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Mon, 2014-02-24 at 17:20 +1030, Christopher Yeoh wrote:\n> > > - Proposed way forward:\n> > >   - Release the V3 API in Juno with nova-network and tasks support\n> > >   - Feature freeze the V2 API when the V3 API is released\n> > >     - Set the timeline for deprecation of V2 so users have a lot\n> > >       of warning\n> > >     - Fallback for those who really don\'t want to move after\n> > >   deprecation is an API service which translates between V2 and V3\n> > >   requests, but removes the dual API support burden from Nova.\n> > \n> > And when do you think we can begin the process of deprecating the V3\n> > API and removing API extensions and XML \"translation\" support?\n> \n> So did you mean V2 API here? I don\'t understand why you think the V3\n> API would need deprecating any time soon.\n\nNo, I meant v3.\n\n> XML support has already been removed from the V3 API and I think the\n> patch to mark XML as deprecated for the V2 API and eventual removal in\n> Juno has already landed. So at least for part of the V2 API a one cycle\n> deprecation period has been seen as reasonable.\n\nOK, very sorry, I must have missed that announcement. I did not realize\nthat XML support had already been removed from v3.\n\n> When it comes to API extensions I think that is actually more a\n> question of policy than anything else. The actual implementation behind\n> the scenes of a plugin architecture makes a lot of sense whether we\n> have extensions or not. \n\nAn API extension is not a plugin. And I\'m not arguing against a plugin\narchitecture -- the difference is that a driver/plugin architecture\nenables a single public API to have difference backend implementations.\n\nPlease see my diatribe on that here:\n\nhttps://www.mail-archive.com/openstack-dev at lists.openstack.org/msg13660.html\n\n> It forces a good level of isolation between API\n> features and clarity of interaction where its needed - all of which\n> much is better from a maintenance point of view.\n\nSorry, I have to violently disagree with you on that one. The API\nextensions (in Nova, Neutron, Keystone, et al) have muddied the code\nimmeasurably and bled implementation into the public API -- something\nthat is antithetical to good public API design.\n\nDrivers and plugins belong in the implementation layer. Not in the\npublic API layer.\n\n> Now whether we have parts of the API which are optional or not is\n> really a policy decision as to whether we will force deployers to use\n> all of the plugins or a subset (eg currently the \"core\"). \n\nIt\'s not about \"forcing\" providers to support all of the public API.\nIt\'s about providing a single, well-documented, consistent HTTP REST API\nfor *consumers* of that API. Whether a provider chooses to, for example,\ndeploy with nova-network or Neutron, or Xen vs. KVM, or support block\nmigration for that matter *should have no effect on the public API*. The\nfact that those choices currently *do* effect the public API that is\nconsumed by the client is a major indication of the weakness of the API.\n\n> There is\n> the technical support for doing so in the V3 API (essentially what is\n> used to enforce the core of the API). And a major API version bump is\n> not required to change this. Perhaps this part falls in to the\n> DefCore discussions :-)\n\nI don\'t see how this discussion falls into the DefCore discussion.\n\nBest,\n-jay\n\n\n\n','<20140224202232.639113c4@pingu>',NULL),('<1393267316.5487.23.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 10:41:56',-28800,'2014-02-24 18:41:56',NULL,'[openstack-dev] [nova] Question about USB passthrough','On Mon, 2014-02-24 at 04:10 +0000, Liuji (Jeremy) wrote:\n> I have found a BP about USB device passthrough in\n> https://blueprints.launchpad.net/nova/+spec/host-usb-passthrough. \n> I have also read the latest nova code and make sure it doesn\'t support\n> USB passthrough by now.\n> \n> Are there any progress or plan for USB passthrough?\n\nI don\'t know anyone is working on USB passthrough.\n\n--jyh\n\n\n\n','<3353B972624C8B49AB43F74428B4701D5D0AAAE4@SZXEMA512-MBX.china.huawei.com>',NULL),('<1393274120.26205.64.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 15:35:20',-18000,'2014-02-24 20:35:20',NULL,'[openstack-dev] [Neutron][LBaaS] Object Model discussion','Thanks, Eugene! I\'ve given the API a bit of thought today and jotted\ndown some thoughts below.\n\nOn Fri, 2014-02-21 at 23:57 +0400, Eugene Nikanorov wrote:\n>         Could you provide some examples -- even in the pseudo-CLI\n>         commands like\n>         I did below. It\'s really difficult to understand where the\n>         limits are\n>         without specific examples.\n> You know, I always look at the API proposal from implementation\n> standpoint also, so here\'s what I see.\n> In the cli workflow that you described above, everything is fine,\n> because the driver know? how and where to deploy each object\n> that you provide in your command, because it\'s basically a batch.\n\nYes, that is true.\n\n> When we\'re talking about separate object? that form a loadbalancer -\n> vips, pools, members, it becomes not clear how to map them backends\n> and at which point.\n\nUnderstood, but I think we can make some headway here. Examples below.\n\n> So here\'s an example I usually give:\n> We have 2 VIPs (in fact, one address and 2 ports listening for http\n> and https, now we call them listeners), \n> both listeners pass request to a webapp server farm, and http listener\n> also passes requests to static image servers by processing incoming\n> request URIs by L7 rules.\n> So object topology is:\n> \n> \n>      Listener1 (addr:80)           Listener2(addr:443)\n>                |             \\                /\n>                |                 \\        /\n>                |                      X\n>                |                  /         \\\n>          pool1(webapp)             pool2(static imgs)\n> sorry for that stone age pic :)\n> \n> \n> The proposal that we discuss can create such object topology by the\n> following sequence of commands:\n> 1) create-vip --name VipName address=addr\n> returns vid_id\n> 2) create-listener --name listener1 --port 80 --protocol http --vip_id\n> vip_id\n> returns listener_id1\n> 3) create-listener --name listener2 --port 443 --protocol https\n> --sl-params params --vip_id vip_id\n> \n> returns listener_id2\n\n> 4) create-pool --name pool1 <members>\n> \n> returns pool_id1\n> 5) create-pool --name pool1 <members>\n> returns pool_id2\n> \n> 6) set-listener-pool listener_id1 pool_id1 --default\n> 7) set-listener-pool listener_id1 pool_id2 --l7policy policy\n> \n> 7) set-listener-pool listener_id2 pool_id1 --default\n\n> That\'s a generic workflow that allows you to create such config. The\n> question is at which point the backend is chosen.\n\n>From a user\'s perspective, they don\'t care about VIPs, listeners or\npools :) All the user cares about is:\n\n * being able to add or remove backend nodes that should be balanced\nacross\n * being able to set some policies about how traffic should be directed\n\nI do realize that AWS ELB\'s API uses the term \"listener\" in its API, but\nI\'m not convinced this is the best term. And I\'m not convinced that\nthere is a need for a \"pool\" resource at all.\n\nCould the above steps #1 through #6 be instead represented in the\nfollowing way?\n\n# Assume we\'ve created a load balancer with ID $BALANCER_ID using\n# Something like I showed in my original response:\n\nneutron balancer-create --type=advanced --front=<ip> \\\n --back=<list_of_ips> --algorithm=\"least-connections\" \\\n --topology=\"active-standby\"\n\nneutron balancer-configure $BALANCER_ID --front-protocol=http \\\n --front-port=80 --back-protocol=http --back-port=80\n\nneutron balancer-configure $BALANCER_ID --front-protocol=https \\\n --front-port=443 --back-protocol=https --back-port=443\n\nLikewise, we could configure the load balancer to send front-end HTTPS\ntraffic (terminated at the load balancer) to back-end HTTP services:\n\nneutron balancer-configure $BALANCER_ID --front-protocol=https \\\n --front-port=443 --back-protocol=http --back-port=80\n\nNo mention of listeners, VIPs, or pools at all.\n\nThe REST API for the balancer-update CLI command above might be\nsomething like this:\n\nPUT /balancers/{balancer_id}\n\nwith JSON body of request like so:\n\n{\n  \"front-port\": 443,\n  \"front-protocol\": \"https\",\n  \"back-port\": 80,\n  \"back-protocol\": \"http\"\n}\n\nAnd the code handling the above request would simply look to see if the\nload balancer had a \"routing entry\" for the front-end port and protocol\nof (443, https) and set the entry to route to back-end port and protocol\nof (80, http).\n\nFor the advanced L7 policy heuristics, it makes sense to me to use a\nsimilar strategy. For example (using a similar example from ELB):\n\nneutron l7-policy-create --type=\"ssl-negotiation\" \\\n --attr=ProtocolSSLv3=true \\\n --attr=ProtocolTLSv1.1=true \\\n --attr=DHE-RSA-AES256-SHA256=true \\\n --attr=Server-Defined-Cipher-Order=true\n\nPresume above returns an ID for the policy $L7_POLICY_ID. We could then\nassign that policy to operate on the front-end of the load balancer by\ndoing:\n\nneutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID --port=443\n\nThere\'s no need to specify --front-port of course, since the policy only\napplies to the front-end.\n\nThere is also no need to refer to a \"listener\" object, no need to call\nanything a VIP, nor any reason to use the term \"pool\" in the API.\n\nBest,\n-jay\n\n> In our current proposal backend is chosen and step (1) and all further\n> objects are implicitly go on the same backend as VipName.\n> \n> \n> The API allows the following addition:\n> 8) create-vip --name VipName2 address=addr2\n> 9) create-listener ... listener3 ...\n> 10) set-listener-pool listener_id3 pool_id1\n> \n> \n> E.g. from API stand point the commands above are valid. But that\n> particular ability (pool1 is shared by two different backends)\n> introduces lots of complexity in the implementation and API, and that\n> is what we would like to avoid at this point.\n> \n> \n> So the proposal makes step #10 forbidden: pool is already associated\n> with the listener on other backend, so we don\'t share it with\n> listeners on another one. \n> That kind of restriction introduces implicit knowledge about the\n> object-to-backend mapping into the API.\n> In my opinion it\'s not a big deal. Once we sort out those\n> complexities, we can allow that.\n> \n> \n> What do you think?\n> \n> \n> Thanks,\n> Eugene.\n> \n> \n> \n> \n> \n> \n>         \n>         > Looking at your proposal it reminds me Heat template for\n>         > loadbalancer.\n>         > It\'s fine, but we need to be able to operate on particular\n>         objects.\n>         \n>         \n>         I\'m not ruling out being able to add or remove nodes from a\n>         balancer, if\n>         that\'s what you\'re getting at?\n>         \n>         Best,\n>         -jay\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAJfiwORQqJvrxU3mPuAzU0Qhfu9L0LYO4hVYKxr3R5kPkGamOQ@mail.gmail.com>',NULL),('<1393284516.26205.66.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 18:28:36',-18000,'2014-02-24 23:28:36',NULL,'[openstack-dev] [nova] Future of the Nova API','On Mon, 2014-02-24 at 14:01 -0800, Morgan Fainberg wrote:\n> TL;DR, ?don?t break the contract?. If we are seriously making\n> incompatible changes (and we will be regardless of the direction) the\n> only reasonable option is a new major version.\n\n100% agreement.\n\nNote that when I asked Chris when we would tackle the issue of\nextensions, I was definitely looking at the next major version of the\nCompute API, not v3 or v2. Sorry if I muddied the conversation in that\nregard.\n\nBest,\n-jay\n\n\n\n\n','<etPan.530bc166.2443a858.378@nullptr>',NULL),('<1393284694.26205.68.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 18:31:34',-18000,'2014-02-24 23:31:34',NULL,'[openstack-dev] [nova] Future of the Nova API','On Mon, 2014-02-24 at 17:59 -0500, Sean Dague wrote:\n> So we do really need to be pragmatic here as well. Because our\n> experience with v3 so far has been doing a major version bump on Nova is\n> a minimum of 2 years, and that doesn\'t reach a completion point that\n> anyone\'s happy with to switch over.\n\nI don\'t see why version 4 need repeat the timeline of v3 development.\nI\'m not saying it isn\'t possible, just that one doesn\'t necessarily lead\nto the other.\n\nBest,\n-jay\n\n\n\n','<530BCEBB.9090409@dague.net>',NULL),('<1393285766.26205.78.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 18:49:26',-18000,'2014-02-24 23:49:26',NULL,'[openstack-dev] [nova] Future of the Nova API','On Tue, 2014-02-25 at 09:11 +1030, Christopher Yeoh wrote:\n> On Mon, 24 Feb 2014 11:48:41 -0500\n> Jay Pipes <jaypipes at gmail.com> wrote:\n> > It\'s not about \"forcing\" providers to support all of the public API.\n> > It\'s about providing a single, well-documented, consistent HTTP REST\n> > API for *consumers* of that API. Whether a provider chooses to, for\n> > example, deploy with nova-network or Neutron, or Xen vs. KVM, or\n> > support block migration for that matter *should have no effect on the\n> > public API*. The fact that those choices currently *do* effect the\n> > public API that is consumed by the client is a major indication of\n> > the weakness of the API.\n> \n> So for the nova-network/neutron issue its more a result of either\n> support for neutron was never implemented or new nova-network features\n> were added without corresponding neutron support. I agree its not a\n> good place to be in, but isn\'t really relevant to whether we have\n> extensions or not.\n\nOK, fair enough.\n\n> Similarly with a Xen vs KVM situation I don\'t think its an extension\n> related issue. In V2 we have features in *core* which are only supported\n> by some virt backends. It perhaps comes down to not being willing to\n> say either that we will force all virt backends to support all features\n> in the API or they don\'t get in the tree. Or alternatively be willing\n> to say no to any feature in the API which can not be currently\n> implemented in all virt backends. The former greatly increases the\n> barrier to getting a hypervisor included, the latter restricts Nova\n> development to the speed of the slowest developing and least\n> mature hypervisor supported.\n\nActually, the problem is not feature parity. The problem lies where two\ndrivers implement the same or similar functionality, but the public API\nfor a user to call the functionality is slightly different depending on\nwhich driver is used by the deployer.\n\nThere\'s nothing wrong at all (IMO) in having feature disparity amongst\ndrivers. However, problems arise when the public API does any of the\nfollowing:\n\n * exposes two ways of doing the same thing, depending on underlying\ndriver\n * exposes things in a way that is specific to one particular\nvendor/driver to the exclusion of others\n * exposes things that should not be exposed to the end-user or tenant,\nbut that belong in the realm of the deployer\n\nSee my original response on the ML about that for examples of all of the\nabove from the current Nova API(s).\n\nBest,\n-jay\n\n\n\n','<20140225091149.1dda1ea9@pingu>',NULL),('<1393288748.26205.85.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 19:39:08',-18000,'2014-02-25 00:39:08',NULL,'[openstack-dev] Incubation Request: Murano','On Mon, 2014-02-24 at 11:24 +0100, Thierry Carrez wrote:\n> Mark Washenberger wrote:\n> > Prior to this email, I was imagining that we would expand the Images\n> > program to go beyond storing just block device images, and into more\n> > structured items like whole Nova instance templates, Heat templates, and\n> > Murano packages. In this scheme, Glance would know everything there is\n> > to know about a resource--its type, format, location, size, and\n> > relationships to other resources--but it would not know or offer any\n> > links for how a resource is to be used.\n> \n> I\'m a bit uncomfortable as well. Part of our role at the Technical\n> Committee is to make sure additions do not overlap in scope and make\n> sense as a whole.\n> \n> Murano seems to cover two functions. The first one is publishing,\n> cataloging and discovering software stacks. The second one is to deploy\n> those software stacks and potentially manage their lifecycle.\n> \n> In the OpenStack \"integrated\" release we already have Glance as a\n> publication/catalog/discovery component and Heat as the workload\n> orchestration end. Georgy clearly identified those two facets, since the\n> incubation request lists those two programs as potential homes for Murano.\n> \n> The problem is, Orchestration doesn\'t care about the Catalog part of\n> Murano, and Glance doesn\'t care about the Orchestration part of Murano.\n> Murano spans the scope of two established programs. It\'s not different\n> enough to really warrant its own program, and it\'s too monolithic to fit\n> in our current landscape.\n> \n> I see two ways out: Murano can continue to live as a separate\n> application that lives on top of OpenStack and consumes various\n> OpenStack components. Or its functionality can be split and subsumed by\n> Glance and Heat, with Murano developers pushing it there. There seems to\n> be interest in both those programs to add features that Murano covers.\n\nThere is a third component: the UI pieces. This naturally would belong\nin the UX program.\n\n> The question is, could we replicate Murano\'s featureset completely in\n> those existing components ? Or is there anything Murano-unique that\n> wouldn\'t fit in existing projects ?\n\nOutside of its innovative UX form-construction component, the biggest\nthing that makes Murano unique (IMO) is its use of flow control\nconstructs in its DSL. If I\'m not mistaken, the Heat community has made\nit clear that they do not intend to introduce flow control constructs\ninto HOT, and so there would be this piece that would need to live\noutside of Heat, but still in the Orchestration program. So, I believe\nthat there is still a compelling reason for Murano to exist as a\nseparate project within the Orchestration program, with a mission to\nprovide a higher level DSL for deployment of complex application\ntopologies that includes flow control contructs.\n\nAnd then someone will ask \"well, isn\'t that partly what Solum is\ndesigned for?\". And we\'re back to a similar discussion ;)\n\nBest,\n-jay\n\n\n\n','<530B1DE3.9040004@openstack.org>',NULL),('<1393293179.51097.YahooMailNeo@web125902.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-24 17:52:59',-28800,'2014-02-25 01:52:59',NULL,'[Openstack-operators] OpenStack Operators Gathering on\n	March	3rd in San Jose','I have not been able to find a room for monday for the triple-O team. Maybe there could be some facilities sharing?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\n\nOn Saturday, February 22, 2014 8:19 PM, Clint Byrum <clint at fewbar.com> wrote:\n \nTim, were you aware this will be going on at the exact same time as the\nTripleO summit, which is happening just down the road in Sunnyvale the\nsame week?\n\nI would like to see some mixing of these two groups. Perhaps we could have\nsome operators come over to the TripleO summit one day, or the other way\naround, as I think feedback from the operators on what we have working\nnow and what we\'re proposing going forward would be extremely helpful.\n\n\nExcerpts from Tim Bell\'s message of 2014-02-21 09:37:22 -0800:\n> We are organising an OpenStack operators mini-summit in the Bay Area on Monday March 3rd in order to gather input for key needs from an OpenStack operator for development effort in the Juno release.\n>? \n> There are a limited number of places available so early registration is recommended. A further session will be arranged around the Atlanta summit.\n>? \n> The details are at https://www.eventbrite.co.uk/e/openstack-march-2014-operators-gathering-tickets-10318369521\n>? \n> Note: There will be no \'presentations\' on what OpenStack is, or how people are using it in their companies, outside of free-ranging discussion on these requirements. This is not an \"operations best\n> practice\" discussion - the aim is purely on getting feedback on what is/isn\'t working and what needs to change.\n> \n> For further background, a few questions & answers...\n>? \n> What is an Operators\' mini-Summit?\n>? \n> This is an attempt to bring together OpenStack operators of various \n> sizes and use cases and gather targeted feedback for the Technical \n> committee, PTL\'s and dev teams.? The goals of the meeting are to \n> prioritize issues/requests from the representative group of \n> operators, attempt to produce a blueprint or two from the top of that \n> list and introduce it all back into the development cycle for Juno.\n>? \n> How was this event organized?\n> \n> The event was born out of discussion on the operators mailing list and has been \n> organized over the last couple of months by the user committee, Tom Fifield \n> (user community manager at the Foundation) and several volunteers from the OpenStack operator\n> community .? It\'s the first time we\'ve done something like this, and is as much an experiment on the \n> best way to build this process as it is an event \n> for the gathering of feedback itself.\n> \n> How many people are you expecting to attend?\n> \n> We have capacity for 75 attendees, and we are limiting attendees to those operating OpenStack clouds \n> (not building products for or around OpenStack).? The event wil be hosted at eBay headquarters. \n> Since it is the first one, the organizing group deliberately wanted to keep things \n> on the smaller side to make sure we enable productive discussions.? We really want the gathering of feedback \n> to be useful and actionable.? Hopefully we can create a repeatable mechanism that gives more \n> and more operators useful ways to influence OpenStack design and prioritization as it evolves.\n> \n> When will the next Operator\'s mini-Summit take place, and will it allow for more attendees?\n>? \n> The next gathering is planned to take place during the OpenStack Summit in May 2014. The exact\n> details and dates will be discussed during this event in March and shared shortly thereafter. \n> It\'s important we make this first event a success - and something we can build on - in size, \n> frequency and regional diversity.\n>? \n> Why is this called a summit?\n> \n> Because, like the Design summit, this meeting is focused on what is \n> built in the next version of OpenStack.? It just happens to be from an \n> operator\'s perspective.? It\'s more than a meet up and is not a \n> conference or tech talk in anyway - there won\'t be howto\'s and \n> presentations.? It\'s a chance for the people that regularly deploy \n> and run OpenStack to share what works, what doesn\'t, and how to make the product better for everyone.\n> \n> Why is this being held in March and not during the OpenStack Summit in May?\n> \n> The earlier we can provide input into the design process, the better, so we can influence\n> the sessions and conversations that will take place at the Atlanta Summit. We are planning\n> to meet again at that time, but want to provide feedback prior to the technical community gathering\n> in May. \n> \n> Where will you be sharing the outcomes, and how I can provide input if I\'m not able to attend?\n> \n> First, make sure you have filled out the user survey, which is a great opportunity to share your \n> feedback and completely confidential at your request. http://www.openstack.org/user-survey\n> We are referencing feedback from the survey in this session and again at the Atlanta Summit. \n> \n> We will be circulating more details of the way people can provide input remotely before the event along with publishing the notes afterwards for further comment.\n> \n> Tim, Ryan, JC, Tom, Sean, Matt and Subbu\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140224/b16e4579/attachment.html>\n\n','<1393128288-sup-1946@fewbar.com>',NULL),('<1393300972.90331.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-25 12:02:52',28800,'2014-02-25 04:02:52',NULL,'[Openstack] problem in installing django-swiftbrowser','my only aim is to find a GUI for operating swift functionalities\n\nFor this purpose, I want to install and run django swiftbrowser\n\nI am following the steps mentioned ?at its github link?https://github.com/cschwede/django-swiftbrowser\n\nThanks\n\nPragya jain\n\n\n\nOn Tuesday, 25 February 2014 1:25 AM, Lysander David <Lysander_David at symantec.com> wrote:\n \nWhy do you believe you have to run\n>\n>\n>python runtests.py\n>\n>\n>?\n>\n>\n>Thanks,\n>Lysander\n>\n>\n>From:  pragya jain <prag_2648 at yahoo.co.in>\n>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>Date:  Sunday, February 23, 2014 9:49 PM\n>To:  Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>\n>\n>\n>hi Lysander David,\n>\n>\n>thanks for the reply.\n>\n>\n>I follow following steps:\n>\n>\n>1. \n>root at pragya-VirtualBox:~# wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz \n>\n>\n>\n>2. \n>root at pragya-VirtualBox:~# tar zxvf Django-1.6.2.tar.gz\n>3. \n>root at pragya-VirtualBox:~# cd Django-1.6.2\n>\n>\n>4. \n>root at pragya-VirtualBox:~/Django-1.6.2# sudo python ./setup.py install\n>5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>\n>and get the following error:\n>\n>\n>ERROR 1:\n>python: can\'t open file \'runtests.py\': [Errno 2] No such file or directory\n>\n>\n>\n>\n>On Wednesday, 19 February 2014 12:06 PM, Lysander David <Lysander_David at symantec.com> wrote:\n>\n>Please install django.\n>>\n>>\n>>wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz\n>>tar zxvf Django-1.6.2.tar.gz\n>>cd Django-1.6.2\n>>sudo python ./setup.py install\n>>\n>>\n>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>Date: Tuesday, February 18, 2014 9:48 PM\n>>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>, Lysander David <Lysander_David at symantec.com>\n>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>\n>>\n>>\n>>thanks Lysander David for the reply. \n>>\n>>I again have some problem.\n>>\n>>I follow the following steps:\n>>1.? root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>\n>>\n>>\n>>2.? root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>\n>>3. \n>>root at pragya-VirtualBox:~/django-swiftbrowser# wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O setuptools-2.2.tar.gz \n>>\n>>4.? \n>>root at pragya-VirtualBox:~/django-swiftbrowser# tar zxvf setuptools-2.2.tar.gz \n>>5. \n>>root at pragya-VirtualBox:~/django-swiftbrowser# cd setuptools-2.2\n>>\n>>\n>>6.? \n>>root at pragya-VirtualBox:~/django-swiftbrowser/setuptools-2.2# sudo python ./setup.py install \n>>7.? \n>>root at pragya-VirtualBox:~/django-swiftbrowser# python runtests.py \n>>\n>>\n>>and I got the following error :\n>>\n>>\n>>Traceback (most recent call last): \n>>File \"runtests.py\", line 2, in <module> \n>>from django.conf import settings \n>>ImportError: No module named django.conf \n>>\n>>\nPlease help to resolve it.\n>>\n>>Thanks again \n>>\n>>pragya Jain\n>>\n>>\n>>\n>>\n>>\n>>\n>>On , pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>\n>>>\n>>>\n>>>On Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>>>\n>>>Please consider installing the setuptools module.\n>>>>\n>>>>\n>>>>The latest archive can be found here:\n>>>>\n>>>>\n>>>>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>>>>\n>>>>\n>>>>You can install it with these commands:\n>>>>\n>>>>\n>>>>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>>>>tar zxvf?setuptools-2.2.tar.gz\n>>>>cd?setuptools-2.2\n>>>>sudo python ./setup.py install\n>>>>\n>>>>\n>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>Date: Sunday, February 16, 2014 9:55 PM\n>>>>To: pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>>\n>>>>\n>>>>\n>>>>please someody reply\n>>>>\n>>>>\n>>>>\n>>>>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>hello all,\n>>>>>\n>>>>>\n>>>>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>>>>\n>>>>>\n>>>>>below are the steps which i follow:\n>>>>>-----------------\n>>>>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>>>\n>>>>>\n>>>>>\n>>>>>Cloning into \'django-swiftbrowser\'...\n>>>>>remote: Reusing existing pack: 145, done.\n>>>>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>>>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>>>>Resolving deltas: 100% (72/72), done.\n>>>>>\n>>>>>\n>>>>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>>>\n>>>>>\n>>>>>\n>>>>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>>>>Traceback (most recent call last):\n>>>>>? File \"setup.py\", line 2, in <module>\n>>>>>??? from setuptools import setup\n>>>>>ImportError: No module named setuptools\n>>>>>------------\n>>>>>\n>>>>>\n>>>>>But I get the error.\n>>>>>Please help inresolving the error.\n>>>>>\n>>>>>\n>>>>>Thanks in advance \n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>_______________________________________________\n>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>Post to? ? : openstack at lists.openstack.org\n>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>\n>>\n>\n>\n>6.?root at pragya-VirtualBox:~/Django-1.6.2# django-admin.py startproject myproj\n>\n>\n>7. root at pragya-VirtualBox:~/Django-1.6.2# cd myproj\n>\n>8. root at pragya-VirtualBox:~/Django-1.6.2/myproj# cp ~/django-swiftbrowser/example/settings.py myproj/settings.py\n>\n>9. root at pragya-VirtualBox:~/Django-1.6.2/myproj# pico myproj/urls.py\n>-------\n>from django.conf.urls import patterns, include, url\n>\n>from django.contrib import admin\n>admin.autodiscover()\n>\n>#urlpatterns = patterns(\'\',\n>??? # Examples:\n>??? # url(r\'^$\', \'myproj.views.home\', name=\'home\'),\n>??? # url(r\'^blog/\', include(\'blog.urls\')),\n>\n>?#?? url(r\'^admin/\', include(admin.site.urls)),\n>#)\n>import swiftbrowser.urls\n>\n>urlpatterns = patterns(\'\',\n>??? url(r\'^\', include(swiftbrowser.urls)),\n>)\n>--------------\n>\n>10. root at pragya-VirtualBox:~/Django-1.6.2/myproj# python manage.py collectstatic\n>\n>ERROR 2:\n>\n>Traceback (most recent call last):\n>? File \"manage.py\", line 10, in <module>\n>??? execute_from_command_line(sys.argv)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 399, in execute_from_command_line\n>??? utility.execute()\n>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 392, in execute\n>??? self.fetch_command(subcommand).run_from_argv(self.argv)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 242, in run_from_argv\n>??? self.execute(*args, **options.__dict__)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 280, in execute\n>??? translation.activate(\'en-us\')\n>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/__init__.py\", line 130, in activate\n>??? return _trans.activate(language)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 188, in activate\n>??? _active.value = translation(language)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 177, in translation\n>??? default_translation = _fetch(settings.LANGUAGE_CODE)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 159, in _fetch\n>??? app = import_module(appname)\n>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py\", line 40, in import_module\n>??? __import__(name)\n>ImportError: No module named swiftbrowser\n>\n>----------\n>\n>I am using the link https://github.com/cschwede/django-swiftbrowser\n>\n>please help me to resolve these two errors.\n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140225/0191743f/attachment.html>\n\n','<CF30E374.27276%Lysander_David@symantec.com>',NULL),('<1393301423.37665.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-25 12:10:23',28800,'2014-02-25 04:10:23',NULL,'[Openstack] how to run zenoss zenpack openstack swift','please somebody reply.\n\nI have swift environment on an ubuntu 12.04 desktop VM.\n\nI searched the Internet. I found the script for installing and running zenoss zenpack openstack swift for ubuntu 64 bit server, but I don\'t find anything for ubuntu desktop\n\nPlease reply\n\nPragya Jain\n\n\n\nOn Monday, 24 February 2014 1:42 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi all\n>\n>I have a running openstack Swift environment.\n>I want to monitor it using zenoss zenpack Openstack Swift.\n>\n>What should I do to install and run it?\n>\n>pragya jain\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140225/58d3b685/attachment.html>\n\n','<1393229532.67120.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1393311496.58607.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-25 14:58:16',28800,'2014-02-25 06:58:16',NULL,'[Openstack] problem in configuring Graphite databases','hi all,\n\nI want to monitor my existing swift environment on Ubuntu 12.04 desktop VM.\n\nfor this purpose, I am trying to install and configure statsD + Graphite\nI am following the steps from the link https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps\n\nBut I get an error while configuring Graphite database.\n\nroot at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\nThe Error is:\nhttp://paste.openstack.org/show/69293/\n\nPlease help to resolve this problem\n\nThanks\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140225/5585f456/attachment.html>\n\n',NULL,NULL),('<1393316075.59656.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-25 16:14:35',28800,'2014-02-25 08:14:35',NULL,'[Openstack] problem in installing django-swiftbrowser','Hi Lysander,\n\nWhen I run?sudo python setup.py install under?django-swiftbrowser:\nroot at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n\nI get the following error:\nhttp://paste.openstack.org/show/68941/\n\nPragya Jain\n\n\n\nOn Tuesday, 25 February 2014 11:55 AM, Lysander David <Lysander_David at symantec.com> wrote:\n \nThis line indicates you ran?\n>\n>\n>Python runtests.py?\n>\n>\n>Under Django-1.6.2\n>\n>\n>5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>\n>\n>This link indicates you should run that command ?here:\n>\n>\n>django-swiftbrowser\n>Why do you believe you should run that command underDjango-1.6.2\n>\n>\n>?\n>\n>\n>Thanks,\n>Lysander\n>\n>\n>\n>\n>From:  pragya jain <prag_2648 at yahoo.co.in>\n>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>Date:  Monday, February 24, 2014 8:02 PM\n>To:  Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>\n>\n>\n>my only aim is to find a GUI for operating swift functionalities\n>\n>\n>For this purpose, I want to install and run django swiftbrowser\n>\n>\n>I am following the steps mentioned ?at its github link?https://github.com/cschwede/django-swiftbrowser\n>\n>\n>Thanks\n>\n>\n>Pragya jain\n>\n>\n>\n>On Tuesday, 25 February 2014 1:25 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>\n>Why do you believe you have to run\n>>\n>>\n>>python runtests.py\n>>\n>>\n>>?\n>>\n>>\n>>Thanks,\n>>Lysander\n>>\n>>\n>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>Date: Sunday, February 23, 2014 9:49 PM\n>>To: Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>\n>>\n>>\n>>hi Lysander David,\n>>\n>>\n>>thanks for the reply.\n>>\n>>\n>>I follow following steps:\n>>\n>>\n>>1. \n>>root at pragya-VirtualBox:~# wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz \n>>\n>>\n>>\n>>2. \n>>root at pragya-VirtualBox:~# tar zxvf Django-1.6.2.tar.gz\n>>3. \n>>root at pragya-VirtualBox:~# cd Django-1.6.2\n>>\n>>\n>>4. \n>>root at pragya-VirtualBox:~/Django-1.6.2# sudo python ./setup.py install\n>>5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>>\n>>and get the following error:\n>>\n>>\n>>ERROR 1:\n>>python: can\'t open file \'runtests.py\': [Errno 2] No such file or directory\n>>\n>>\n>>\n>>\n>>On Wednesday, 19 February 2014 12:06 PM, Lysander David <Lysander_David at symantec.com> wrote:\n>>\n>>Please install django.\n>>>\n>>>\n>>>wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz\n>>>tar zxvf Django-1.6.2.tar.gz\n>>>cd Django-1.6.2\n>>>sudo python ./setup.py install\n>>>\n>>>\n>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>Date: Tuesday, February 18, 2014 9:48 PM\n>>>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>, Lysander David <Lysander_David at symantec.com>\n>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>\n>>>\n>>>\n>>>thanks Lysander David for the reply. \n>>>\n>>>I again have some problem.\n>>>\n>>>I follow the following steps:\n>>>1.? root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>\n>>>\n>>>\n>>>2.? root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>\n>>>3. \n>>>root at pragya-VirtualBox:~/django-swiftbrowser# wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O setuptools-2.2.tar.gz \n>>>\n>>>4.? \n>>>root at pragya-VirtualBox:~/django-swiftbrowser# tar zxvf setuptools-2.2.tar.gz \n>>>5. \n>>>root at pragya-VirtualBox:~/django-swiftbrowser# cd setuptools-2.2\n>>>\n>>>\n>>>6.? \n>>>root at pragya-VirtualBox:~/django-swiftbrowser/setuptools-2.2# sudo python ./setup.py install \n>>>7.? \n>>>root at pragya-VirtualBox:~/django-swiftbrowser# python runtests.py \n>>>\n>>>\n>>>and I got the following error :\n>>>\n>>>\n>>>Traceback (most recent call last): \n>>>File \"runtests.py\", line 2, in <module> \n>>>from django.conf import settings \n>>>ImportError: No module named django.conf \n>>>\n>>>\nPlease help to resolve it.\n>>>\n>>>Thanks again \n>>>\n>>>pragya Jain\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On , pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>\n>>>>\n>>>>\n>>>>On Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>>>>\n>>>>Please consider installing the setuptools module.\n>>>>>\n>>>>>\n>>>>>The latest archive can be found here:\n>>>>>\n>>>>>\n>>>>>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>>>>>\n>>>>>\n>>>>>You can install it with these commands:\n>>>>>\n>>>>>\n>>>>>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>>>>>tar zxvf?setuptools-2.2.tar.gz\n>>>>>cd?setuptools-2.2\n>>>>>sudo python ./setup.py install\n>>>>>\n>>>>>\n>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>Date: Sunday, February 16, 2014 9:55 PM\n>>>>>To: pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>>>\n>>>>>\n>>>>>\n>>>>>please someody reply\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>\n>>>>>hello all,\n>>>>>>\n>>>>>>\n>>>>>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>>>>>\n>>>>>>\n>>>>>>below are the steps which i follow:\n>>>>>>-----------------\n>>>>>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Cloning into \'django-swiftbrowser\'...\n>>>>>>remote: Reusing existing pack: 145, done.\n>>>>>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>>>>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>>>>>Resolving deltas: 100% (72/72), done.\n>>>>>>\n>>>>>>\n>>>>>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>>>>>Traceback (most recent call last):\n>>>>>>? File \"setup.py\", line 2, in <module>\n>>>>>>??? from setuptools import setup\n>>>>>>ImportError: No module named setuptools\n>>>>>>------------\n>>>>>>\n>>>>>>\n>>>>>>But I get the error.\n>>>>>>Please help inresolving the error.\n>>>>>>\n>>>>>>\n>>>>>>Thanks in advance \n>>>>>>\n>>>>>>Pragya Jain\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>Post to? ? : openstack at lists.openstack.org\n>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>\n>>\n>>6.?root at pragya-VirtualBox:~/Django-1.6.2# django-admin.py startproject myproj\n>>\n>>\n>>7. root at pragya-VirtualBox:~/Django-1.6.2# cd myproj\n>>\n>>8. root at pragya-VirtualBox:~/Django-1.6.2/myproj# cp ~/django-swiftbrowser/example/settings.py myproj/settings.py\n>>\n>>9. root at pragya-VirtualBox:~/Django-1.6.2/myproj# pico myproj/urls.py\n>>-------\n>>from django.conf.urls import patterns, include, url\n>>\n>>from django.contrib import admin\n>>admin.autodiscover()\n>>\n>>#urlpatterns = patterns(\'\',\n>>??? # Examples:\n>>??? # url(r\'^$\', \'myproj.views.home\', name=\'home\'),\n>>??? # url(r\'^blog/\', include(\'blog.urls\')),\n>>\n>>?#?? url(r\'^admin/\', include(admin.site.urls)),\n>>#)\n>>import swiftbrowser.urls\n>>\n>>urlpatterns = patterns(\'\',\n>>??? url(r\'^\', include(swiftbrowser.urls)),\n>>)\n>>--------------\n>>\n>>10. root at pragya-VirtualBox:~/Django-1.6.2/myproj# python manage.py collectstatic\n>>\n>>ERROR 2:\n>>\n>>Traceback (most recent call last):\n>>? File \"manage.py\", line 10, in <module>\n>>??? execute_from_command_line(sys.argv)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 399, in execute_from_command_line\n>>??? utility.execute()\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 392, in execute\n>>??? self.fetch_command(subcommand).run_from_argv(self.argv)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 242, in run_from_argv\n>>??? self.execute(*args, **options.__dict__)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 280, in execute\n>>??? translation.activate(\'en-us\')\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/__init__.py\", line 130, in activate\n>>??? return _trans.activate(language)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 188, in activate\n>>??? _active.value = translation(language)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 177, in translation\n>>??? default_translation = _fetch(settings.LANGUAGE_CODE)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 159, in _fetch\n>>??? app = import_module(appname)\n>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py\", line 40, in import_module\n>>??? __import__(name)\n>>ImportError: No module named swiftbrowser\n>>\n>>----------\n>>\n>>I am using the link https://github.com/cschwede/django-swiftbrowser\n>>\n>>please help me to resolve these two errors.\n>>\n>>Pragya Jain\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140225/0ef766f5/attachment.html>\n\n','<CF317512.272C6%Lysander_David@symantec.com>',NULL),('<1393348640.5487.29.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 09:17:20',-28800,'2014-02-25 17:17:20',NULL,'[openstack-dev] [nova] Question about USB passthrough','On Tue, 2014-02-25 at 03:05 +0000, Liuji (Jeremy) wrote:\n> Now that USB devices are used so widely in private/hybrid cloud like\n> used as USB key, and there are no technical issues in libvirt/qemu.\n> I think it a valuable feature in openstack.\n\nUSB key is an interesting scenario. I assume the USB key is just for\nsome specific VM, wondering how the admin/user know which usb disk to\nwhich VM?\n\n--jyh\n\n\n\n','<3353B972624C8B49AB43F74428B4701D5D0ABC69@SZXEMA512-MBX.china.huawei.com>',NULL),('<1393348855.26205.120.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 12:20:55',-18000,'2014-02-25 17:20:55',NULL,'[openstack-dev] [third-party-ci] Proposing a regular\n workshop/meeting to help folks set up CI environments','Hi Stackers,\n\nI\'ve been contacted by a number of folks with questions about setting up\na third-party CI system, and while I\'m very happy to help anyone who\ncontacts me, I figured it would be a good idea to have a regular meeting\non Google Hangouts that would be used as a Q&A session or workshop for\nfolks struggling to set up their own environments.\n\nI think Google Hangouts are ideal because we can share our screens (yes,\neven on Linux systems) and get real-time feedback to the folks who have\nquestions.\n\nI propose we have the first weekly meeting this coming Monday, March\n3rd, at 10:00 EST (07:00 PST, 15:00 UTC).\n\nI created a Googe Hangout Event here:\n\nhttp://bit.ly/1cLVnkv\n\nFeel free to sign up for the event by selecting \"Yes\" in the \"Are you\ngoing?\" dropdown.\n\nIf Google Hangouts works well for this first week, we\'ll use it again.\n\nBest,\n-jay\n\n\n\n\n',NULL,NULL),('<1393348855.26205.120.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-25 12:20:55',-18000,'2014-02-25 17:20:55',NULL,'[OpenStack-Infra] [third-party-ci] Proposing a regular\n workshop/meeting to help folks set up CI environments','Hi Stackers,\n\nI\'ve been contacted by a number of folks with questions about setting up\na third-party CI system, and while I\'m very happy to help anyone who\ncontacts me, I figured it would be a good idea to have a regular meeting\non Google Hangouts that would be used as a Q&A session or workshop for\nfolks struggling to set up their own environments.\n\nI think Google Hangouts are ideal because we can share our screens (yes,\neven on Linux systems) and get real-time feedback to the folks who have\nquestions.\n\nI propose we have the first weekly meeting this coming Monday, March\n3rd, at 10:00 EST (07:00 PST, 15:00 UTC).\n\nI created a Googe Hangout Event here:\n\nhttp://bit.ly/1cLVnkv\n\nFeel free to sign up for the event by selecting \"Yes\" in the \"Are you\ngoing?\" dropdown.\n\nIf Google Hangouts works well for this first week, we\'ll use it again.\n\nBest,\n-jay\n\n\n\n\n',NULL,NULL),('<1393349601.5487.31.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 09:33:21',-28800,'2014-02-25 17:33:21',NULL,'[openstack-dev] [nova] Simulating many fake nova compute nodes\n for scheduler testing','On Tue, 2014-02-25 at 10:45 +0000, John Garbutt wrote:\n> \n> As a heads up, the overheads of DB calls turned out to dwarf any\n> algorithmic improvements I managed. There will clearly be some RPC\n> overhead, but it didn\'t stand out as much as the DB issue.\n> \n> The move to conductor work should certainly stop the scheduler making\n> those pesky DB calls to update the nova instance. And then,\n> improvements like no-db-scheduler and improvements to scheduling\n> algorithms should shine through much more.\n> \nAlthough DB access is sure the key for performance, but do we really\nwant to pursue conductor-based scheduler?\n\n--jyh\n\n\n\n','<CABib2_rXthbovbao35bRiwKPsDkgceKb7L9qT9ZHBOYyFTu2MA@mail.gmail.com>',NULL),('<1393356128.26205.129.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 14:22:08',-18000,'2014-02-25 19:22:08',NULL,'[openstack-dev] [third-party-testing] CHANGED TIME and VENUE:\n Workshop/Q&A session on third party testing will be on IRC now!','Hi again Stackers,\n\nAfter discussions with folks on the infrastructure team, I\'m making some\nchanges to the proposed workshop venue and time. As was rightly pointed\nout by Jim B and others, we want to encourage folks that are setting up\ntheir CI systems to use the standard communication tools to interact\nwith the OpenStack community. That standard tool is IRC, with meetings\non Freenode. In addition, Google Hangout is not a free/libre piece of\nsoftware, and we want to encourage free and open source contribution and\nparticipation.\n\nAlright, with that said, we will conduct the first 3rd party OpenStack\nCI workshop/Q&A session on Freenode IRC, #openstack-meeting on Monday,\nMarch 3rd, at 13:00 EST (18:00 UTC):\n\nhttps://wiki.openstack.org/wiki/Meetings#Third_Party_OpenStack_CI_Workshop_and_Q.26A_Meetings\n\nUnlike regular OpenStack team meetings on IRC, there will not be a set\nagenda. Instead, the IRC channel will be reserved for folks eager to get\nquestions about their CI installation answered and are looking for some\ndebugging assistance with Jenkins, Zuul, Nodepool et al.\n\nI look forward to seeing you there!\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1393356128.26205.129.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-25 14:22:08',-18000,'2014-02-25 19:22:08',NULL,'[OpenStack-Infra] [third-party-testing] CHANGED TIME and VENUE:\n Workshop/Q&A session on third party testing will be on IRC now!','Hi again Stackers,\n\nAfter discussions with folks on the infrastructure team, I\'m making some\nchanges to the proposed workshop venue and time. As was rightly pointed\nout by Jim B and others, we want to encourage folks that are setting up\ntheir CI systems to use the standard communication tools to interact\nwith the OpenStack community. That standard tool is IRC, with meetings\non Freenode. In addition, Google Hangout is not a free/libre piece of\nsoftware, and we want to encourage free and open source contribution and\nparticipation.\n\nAlright, with that said, we will conduct the first 3rd party OpenStack\nCI workshop/Q&A session on Freenode IRC, #openstack-meeting on Monday,\nMarch 3rd, at 13:00 EST (18:00 UTC):\n\nhttps://wiki.openstack.org/wiki/Meetings#Third_Party_OpenStack_CI_Workshop_and_Q.26A_Meetings\n\nUnlike regular OpenStack team meetings on IRC, there will not be a set\nagenda. Instead, the IRC channel will be reserved for folks eager to get\nquestions about their CI installation answered and are looking for some\ndebugging assistance with Jenkins, Zuul, Nodepool et al.\n\nI look forward to seeing you there!\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1393359860.26205.164.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 15:24:20',-18000,'2014-02-25 20:24:20',NULL,'[openstack-dev] [Neutron][LBaaS] Object Model discussion','On Mon, 2014-02-24 at 18:07 -0800, Stephen Balukoff wrote:\n> Hi y\'all,\n> \n> Jay, in the L7 example you give, it looks like you\'re setting SSL\n> parameters for a given load balancer front-end. \n\nCorrect. The example comes straight out of the same example in the ELB\nAPI documentation. The only difference being in my CLI commands, there\'s\nno mention of a listener, whereas in the ELB examples, there is (since\nthe ELB API can only configure this on the load balancer by adding or\nremoving listener objects to/from the load balancer object.\n\n> Do you have an example you can share where where certain traffic is\n> sent to one set of back-end nodes, and other traffic is sent to a\n> different set of back-end nodes based on the URL in the client\n> request? (I\'m trying to understand how this can work without the\n> concept of \'pools\'.)  \n\nGreat example. This is quite a common scenario -- consider serving\nrequests for static images or content from one set of nginx servers and\nnon-static content from another set of, say, Apache servers running\nTomcat or similar.\n\nOK, I\'ll try to work through my ongoing CLI suggestions for the\nfollowing scenario:\n\n* User has 3 Nova instances running nginx and serving static files.\nThese instances all have private IP addresses in subnet 192.168.1.0/24.\n* User has 3 Nova instances running Apache and tomcat and serving\ndynamic content. These instances all have private IP addresses in subnet\n192.168.2.0/24\n* User wants any traffic coming in to the balancer\'s front-end IP with a\nURI beginning with \"static.example.com\" to get directed to any of the\nnginx nodes\n* User wants any other traffic coming in to the balancer\'s front-end IP\nto get directed to any of the Apache nodes\n* User wants sticky session handling enabled ONLY for traffic going to\nthe Apache nodes\n\nHere is what some proposed CLI commands might look like in my\n\"user-centric flow of things\":\n\n# Assume we\'ve created a load balancer with ID $BALANCER_ID using\n# Something like I showed in my original response:\n                 \nneutron balancer-create --type=advanced --front=<ip> \\\n --back=<list_of_ips> --algorithm=\"least-connections\" \\\n --topology=\"active-standby\"\n\nNote that in the above call, <list_of_ips> includes **all of the Nova\ninstances that would be balanced across**, including all of the nginx\nand all of the Apache instances.\n\nNow, let\'s set up our static balancing. First, we\'d create a new L7\npolicy, just like the SSL negotiation one in the previous example:\n\nneutron l7-policy-create --type=\"uri-regex-matching\" \\\n --attr=URIRegex=\"static\\.example\\.com.*\"\n\nPresume above returns an ID for the policy $L7_POLICY_ID. We could then\nassign that policy to operate on the front-end of the load balancer and\nspreading load to the nginx nodes by doing:\n\nneutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \\\n --subnet-cidr=192.168.1.0/24\n\nWe could then indicate to the balancer that all other traffic should be\nsent to only the Apache nodes:\n\nneutron l7-policy-create --type=\"uri-regex-matching\" \\\n --attr=URIRegex=\"static\\.example\\.com.*\" \\\n --attr=\"RegexMatchReverse=true\"\n\nneutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \\\n --subnet-cidr=192.168.2.0/24\n\n> Also, what if the first group of nodes needs a different health check\n> run against it than the second group of nodes?\n\nneutron balancer-apply-healthcheck $BALANCER_ID $HEALTHCHECK_ID \\\n --subnet-cidr=192.168.1.0/24\n\nwhere $HEALTHCHECK_ID would be the ID of a simple healthcheck object.\n\nThe biggest advantage to this proposed API and CLI is that we are not\nintroducing any terminology into the Neutron LBaaS API that is not\nnecessary when existing terms in the main Neutron API already exist to\ndescribe such things. You will note that I do not use the term \"pool\"\nabove, since the concept of a subnet (and its associated CIDR) are\nalready well-established objects in the Neutron API and can serve the\nexact same purpose for Neutron LBaaS API.\n\n> As far as hiding implementation details from the user:  To a certain\n> degree I agree with this, and to a certain degree I do not: OpenStack\n> is a cloud OS fulfilling the needs of supplying IaaS. It is not a\n> PaaS. As such, the objects that users deal with largely are analogous\n> to physical pieces of hardware that make up a cluster, albeit these\n> are virtualized or conceptualized. Users can then use these conceptual\n> components of a cluster to build the (virtual) infrastructure they\n> need to support whatever application they want. These objects have\n> attributes and are expected to act in a certain way, which again, are\n> usually analogous to actual hardware.\n\nI disagree. A cloud API should strive to shield users of the cloud from\nhaving to understand underlying hardware APIs or object models.\n\n> If we were building a PaaS, the story would be a lot different--  but\n> what we are building is a cloud OS that provides Infrastructure (as a\n> service).\n\nI still think we need to simplify the APIs as much as we can, and remove\nthe underlying implementation (which includes the database schema and\nobject model) from being exposed to the user through the public API.\n\n> I think the concept of a \'load balancer\' or \'load balancer service\' is\n> one of these building blocks that has attributes and is expected to\n> act in a certain way. (Much the same way cinder provides \"block\n> devices\" or swift provides an \"object store.\") \n\nYes, but Swift doesn\'t expose the details of its ring topology and\nsharding algorithms to the users of the public object storage API -- and\nthey shouldn\'t expose this, as it leaks implementation out of the\ninterfaces.\n\n> And yes, while you can do away with a lot of the implementation\n> details and use a very simple model for the simplest use case, there\n> are a whole lot of load balancer use cases more complicated than that\n> which don\'t work with the current model (or even a small alteration to\n> the current model). If you don\'t allow for these more complicated use\n> cases, you end up with users stacking home-built software load\n> balancers behind the cloud OS load balancers in order to get the\n> features they actually need. (I understand this is a very common\n> topology with ELB, because ELB simply isn\'t capable of doing advanced\n> things, from the user\'s perspective.) In my opinion, we should be\n> looking well beyond what ELB can do. :P Ideally, almost all users\n> should not have to hack together their own load balancer because the\n> cloud OS load balancer can\'t do what they need it to do.\n\nTotaly agreement. I want a simple API that is flexible enough to meet\neven the most complex sets of heuristics. But, I also believe that the\npublic API should hide this complexity by default, not expose it.\n\nI think this discussion is a great one, and I thank you and Eugene for\nyour detailed feedback and comments.\n\nBest,\n-jay\n\n> I\'m all for having the simplest workflow possible for the basic user--\n> and using the principle of least surprise when assuming defaults so\n> that when they grow and their needs change, they won\'t often have to\n> completely rework the load balancer component in their cluster. But\n> the model we use should be sufficiently sophisticated to support\n> advanced workflows.\n> \n> \n> Also, from a cloud administrator\'s point of view, the cloud OS needs\n> to be aware of all the actual hardware components, virtual components,\n> and other logical constructs that make up the cloud in order to be\n> able to effectively maintain it. Again, almost all the details of this\n> should be hidden from the user. But these details must not be hidden\n> from the cloud administrator. This means implementation details will\n> be represented somehow, and will be visible to the cloud\n> administrator.\n> \n> \n> Yes, the focus needs to be on making the user\'s experience as simple\n> as possible. But we shouldn\'t sacrifice powerful capabilities for a\n> simpler experience. And if we ignore the needs of the cloud\n> administrator, then we end up with a cloud that is next to impossible\n> to practically administer.\n> \n> \n> Do y\'all disagree with this, and if so, could you please share your\n> reasoning?\n> \n> \n> \n> Thanks,\n> Stephen\n> \n> \n> \n> \n> \n> \n> On Mon, Feb 24, 2014 at 1:24 PM, Eugene Nikanorov\n> <enikanorov at mirantis.com> wrote:\n>         Hi Jay,\n>         \n>         \n>         Thanks for suggestions. I get the idea.\n>         I\'m not sure the essence of this API is much different then\n>         what we have now.\n>         1) We operate on parameters of loadbalancer rather then on\n>         vips/pools/listeners. No matter how we name them, the notions\n>         are there.\n>         2) I see two opposite preferences: one is that user doesn\'t\n>         care about \'loadbalancer\' in favor of pools/vips/listeners\n>         (\'pure logical API\')\n>         another is vice versa (yours). \n>         3) The approach of providing $BALANCER_ID to pretty much every\n>         call solves all my concerns, I like it.\n>         Basically that was my initial code proposal (it\'s not exactly\n>         the same, but it\'s very close).\n>         The idea of my proposal was to have that \'balancer\' resource\n>         plus being able to operate on vips/pools/etc.\n>         In this direction we could evolve from existing API to the API\n>         in your latest suggestion.\n>         \n>         \n>         Thanks,\n>         \n>         Eugene.\n>         \n>         \n>         On Tue, Feb 25, 2014 at 12:35 AM, Jay Pipes\n>         <jaypipes at gmail.com> wrote:\n>                 Thanks, Eugene! I\'ve given the API a bit of thought\n>                 today and jotted\n>                 down some thoughts below.\n>                 \n>                 On Fri, 2014-02-21 at 23:57 +0400, Eugene Nikanorov\n>                 wrote:\n>                 >         Could you provide some examples -- even in\n>                 the pseudo-CLI\n>                 >         commands like\n>                 >         I did below. It\'s really difficult to\n>                 understand where the\n>                 >         limits are\n>                 >         without specific examples.\n>                 > You know, I always look at the API proposal from\n>                 implementation\n>                 > standpoint also, so here\'s what I see.\n>                 > In the cli workflow that you described above,\n>                 everything is fine,\n>                 > because the driver know? how and where to deploy\n>                 each object\n>                 > that you provide in your command, because it\'s\n>                 basically a batch.\n>                 \n>                 \n>                 Yes, that is true.\n>                 \n>                 > When we\'re talking about separate object? that form\n>                 a loadbalancer -\n>                 > vips, pools, members, it becomes not clear how to\n>                 map them backends\n>                 > and at which point.\n>                 \n>                 \n>                 Understood, but I think we can make some headway here.\n>                 Examples below.\n>                 \n>                 > So here\'s an example I usually give:\n>                 > We have 2 VIPs (in fact, one address and 2 ports\n>                 listening for http\n>                 > and https, now we call them listeners),\n>                 > both listeners pass request to a webapp server farm,\n>                 and http listener\n>                 > also passes requests to static image servers by\n>                 processing incoming\n>                 > request URIs by L7 rules.\n>                 > So object topology is:\n>                 >\n>                 >\n>                 >      Listener1 (addr:80)\n>                 Listener2(addr:443)\n>                 >                |             \\                /\n>                 >                |                 \\        /\n>                 >                |                      X\n>                 >                |                  /         \\\n>                 >          pool1(webapp)             pool2(static\n>                 imgs)\n>                 > sorry for that stone age pic :)\n>                 >\n>                 >\n>                 > The proposal that we discuss can create such object\n>                 topology by the\n>                 > following sequence of commands:\n>                 > 1) create-vip --name VipName address=addr\n>                 > returns vid_id\n>                 > 2) create-listener --name listener1 --port 80\n>                 --protocol http --vip_id\n>                 > vip_id\n>                 > returns listener_id1\n>                 > 3) create-listener --name listener2 --port 443\n>                 --protocol https\n>                 > --sl-params params --vip_id vip_id\n>                 >\n>                 > returns listener_id2\n>                 \n>                 > 4) create-pool --name pool1 <members>\n>                 >\n>                 > returns pool_id1\n>                 > 5) create-pool --name pool1 <members>\n>                 > returns pool_id2\n>                 >\n>                 > 6) set-listener-pool listener_id1 pool_id1 --default\n>                 > 7) set-listener-pool listener_id1 pool_id2\n>                 --l7policy policy\n>                 >\n>                 > 7) set-listener-pool listener_id2 pool_id1 --default\n>                 \n>                 > That\'s a generic workflow that allows you to create\n>                 such config. The\n>                 > question is at which point the backend is chosen.\n>                 \n>                 \n>                 From a user\'s perspective, they don\'t care about VIPs,\n>                 listeners or\n>                 pools :) All the user cares about is:\n>                 \n>                  * being able to add or remove backend nodes that\n>                 should be balanced\n>                 across\n>                  * being able to set some policies about how traffic\n>                 should be directed\n>                 \n>                 I do realize that AWS ELB\'s API uses the term\n>                 \"listener\" in its API, but\n>                 I\'m not convinced this is the best term. And I\'m not\n>                 convinced that\n>                 there is a need for a \"pool\" resource at all.\n>                 \n>                 Could the above steps #1 through #6 be instead\n>                 represented in the\n>                 following way?\n>                 \n>                 # Assume we\'ve created a load balancer with ID\n>                 $BALANCER_ID using\n>                 # Something like I showed in my original response:\n>                 \n>                 neutron balancer-create --type=advanced --front=<ip> \\\n>                  --back=<list_of_ips> --algorithm=\"least-connections\"\n>                 \\\n>                  --topology=\"active-standby\"\n>                 \n>                 \n>                 neutron balancer-configure $BALANCER_ID\n>                 --front-protocol=http \\\n>                  --front-port=80 --back-protocol=http --back-port=80\n>                 \n>                 neutron balancer-configure $BALANCER_ID\n>                 --front-protocol=https \\\n>                  --front-port=443 --back-protocol=https\n>                 --back-port=443\n>                 \n>                 Likewise, we could configure the load balancer to send\n>                 front-end HTTPS\n>                 traffic (terminated at the load balancer) to back-end\n>                 HTTP services:\n>                 \n>                 neutron balancer-configure $BALANCER_ID\n>                 --front-protocol=https \\\n>                  --front-port=443 --back-protocol=http --back-port=80\n>                 \n>                 No mention of listeners, VIPs, or pools at all.\n>                 \n>                 The REST API for the balancer-update CLI command above\n>                 might be\n>                 something like this:\n>                 \n>                 PUT /balancers/{balancer_id}\n>                 \n>                 with JSON body of request like so:\n>                 \n>                 {\n>                   \"front-port\": 443,\n>                   \"front-protocol\": \"https\",\n>                   \"back-port\": 80,\n>                   \"back-protocol\": \"http\"\n>                 }\n>                 \n>                 And the code handling the above request would simply\n>                 look to see if the\n>                 load balancer had a \"routing entry\" for the front-end\n>                 port and protocol\n>                 of (443, https) and set the entry to route to back-end\n>                 port and protocol\n>                 of (80, http).\n>                 \n>                 For the advanced L7 policy heuristics, it makes sense\n>                 to me to use a\n>                 similar strategy. For example (using a similar example\n>                 from ELB):\n>                 \n>                 neutron l7-policy-create --type=\"ssl-negotiation\" \\\n>                  --attr=ProtocolSSLv3=true \\\n>                  --attr=ProtocolTLSv1.1=true \\\n>                  --attr=DHE-RSA-AES256-SHA256=true \\\n>                  --attr=Server-Defined-Cipher-Order=true\n>                 \n>                 Presume above returns an ID for the policy\n>                 $L7_POLICY_ID. We could then\n>                 assign that policy to operate on the front-end of the\n>                 load balancer by\n>                 doing:\n>                 \n>                 neutron balancer-apply-policy $BALANCER_ID\n>                 $L7_POLICY_ID --port=443\n>                 \n>                 There\'s no need to specify --front-port of course,\n>                 since the policy only\n>                 applies to the front-end.\n>                 \n>                 There is also no need to refer to a \"listener\" object,\n>                 no need to call\n>                 anything a VIP, nor any reason to use the term \"pool\"\n>                 in the API.\n>                 \n>                 Best,\n>                 -jay\n>                 \n>                 > In our current proposal backend is chosen and step\n>                 (1) and all further\n>                 > objects are implicitly go on the same backend as\n>                 VipName.\n>                 >\n>                 >\n>                 > The API allows the following addition:\n>                 > 8) create-vip --name VipName2 address=addr2\n>                 > 9) create-listener ... listener3 ...\n>                 > 10) set-listener-pool listener_id3 pool_id1\n>                 >\n>                 >\n>                 > E.g. from API stand point the commands above are\n>                 valid. But that\n>                 > particular ability (pool1 is shared by two different\n>                 backends)\n>                 > introduces lots of complexity in the implementation\n>                 and API, and that\n>                 > is what we would like to avoid at this point.\n>                 >\n>                 >\n>                 > So the proposal makes step #10 forbidden: pool is\n>                 already associated\n>                 > with the listener on other backend, so we don\'t\n>                 share it with\n>                 > listeners on another one.\n>                 > That kind of restriction introduces implicit\n>                 knowledge about the\n>                 > object-to-backend mapping into the API.\n>                 > In my opinion it\'s not a big deal. Once we sort out\n>                 those\n>                 > complexities, we can allow that.\n>                 >\n>                 >\n>                 > What do you think?\n>                 >\n>                 >\n>                 > Thanks,\n>                 > Eugene.\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >         > Looking at your proposal it reminds me\n>                 Heat template for\n>                 >         > loadbalancer.\n>                 >         > It\'s fine, but we need to be able to\n>                 operate on particular\n>                 >         objects.\n>                 >\n>                 >\n>                 >         I\'m not ruling out being able to add or\n>                 remove nodes from a\n>                 >         balancer, if\n>                 >         that\'s what you\'re getting at?\n>                 >\n>                 >         Best,\n>                 >         -jay\n>                 >\n>                 >\n>                 >\n>                 >\n>                 _______________________________________________\n>                 >         OpenStack-dev mailing list\n>                 >         OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 >\n>                 >\n>                 >\n>                 > _______________________________________________\n>                 > OpenStack-dev mailing list\n>                 > OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAAGw+ZoC++98GSq+kZ2v4cJX5+n8s1f302hLPuHnqG9jdej=ew@mail.gmail.com>',NULL),('<1393360727.26205.172.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 15:38:47',-18000,'2014-02-25 20:38:47',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote:\n> For purposes of supporting multiple backends for Identity (multiple\n> LDAP, mix of LDAP and SQL, federation, etc) Keystone is planning to\n> increase the maximum size of the USER_ID field from an upper limit of\n> 64 to an upper limit of 255. This change would not impact any\n> currently assigned USER_IDs (they would remain in the old simple UUID\n> format), however, new USER_IDs would be increased to include the IDP\n> identifier (e.g. USER_ID@@IDP_IDENTIFIER).\n\n-1\n\nI think a better solution would be to have a simple translation table\nonly in Keystone that would store this longer identifier (for folks\nusing federation and/or LDAP) along with the Keystone user UUID that is\nused in foreign key relations and other mapping tables through Keystone\nand other projects.\n\nThe only identifiers that would ever be communicated to any non-Keystone\nOpenStack endpoint would be the UUID user and tenant IDs.\n\n> There is the obvious concern that projects are utilizing (and storing)\n> the user_id in a field that cannot accommodate the increased upper\n> limit. Before this change is merged in, it is important for the\n> Keystone team to understand if there are any places that would be\n> overflowed by the increased size.\n\nI would go so far as to say the user_id and tenant_id fields should be\n*reduced* in size to a fixed 16-char BINARY or 32-char CHAR field for\nperformance reasons. Lengthening commonly-used and frequently-joined\nidentifier fields is not a good option, IMO.\n\nBest,\n-jay\n\n> The review that would implement this change in size\n> is https://review.openstack.org/#/c/74214 and is actively being worked\n> on/reviewed.\n> \n> \n> I have already spoken with the Nova team, and a single instance has\n> been identified that would require a migration (that will have a fix\n> proposed for the I3 timeline). \n> \n> \n> If there are any other known locations that would have issues with an\n> increased USER_ID size, or any concerns with this change to USER_ID\n> format, please respond so that the issues/concerns can be addressed.\n>  Again, the plan is not to change current USER_IDs but that new ones\n> could be up to 255 characters in length.\n> \n> \n> Cheers,\n> Morgan Fainberg\n> ?\n> Morgan Fainberg\n> Principal Software Engineer\n> Core Developer, Keystone\n> m at metacloud.com\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<etPan.530cf39b.2ca88611.378@nullptr>',NULL),('<1393369667.26205.173.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 18:07:47',-18000,'2014-02-25 23:07:47',NULL,'[openstack-dev] [OpenStack-Infra] [third-party-ci] Proposing a\n regular workshop/meeting to help folks set up CI environments','On Tue, 2014-02-25 at 20:02 -0300, Arx Cruz wrote:\n> Hello,\n> \n> Great Idea, I\'m very interested!\n> \n> I wasn\'t able to see the Google Hangout Event, is the url correct?\n\nHi Arx!\n\nWe changed from Google Hangout to using IRC. See here for more info:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-February/028124.html\n\nBest,\n-jay\n\n\n\n\n','<CALjhVmUF0JMKr8R_5PRqEiv2XM2z4OfhCV4YHdBHR3XWMbEPCg@mail.gmail.com>',NULL),('<1393369667.26205.173.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-25 18:07:47',-18000,'2014-02-25 23:07:47',NULL,'[OpenStack-Infra] [third-party-ci] Proposing a regular\n workshop/meeting to help folks set up CI environments','On Tue, 2014-02-25 at 20:02 -0300, Arx Cruz wrote:\n> Hello,\n> \n> Great Idea, I\'m very interested!\n> \n> I wasn\'t able to see the Google Hangout Event, is the url correct?\n\nHi Arx!\n\nWe changed from Google Hangout to using IRC. See here for more info:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-February/028124.html\n\nBest,\n-jay\n\n\n\n\n','<CALjhVmUF0JMKr8R_5PRqEiv2XM2z4OfhCV4YHdBHR3XWMbEPCg@mail.gmail.com>',NULL),('<1393370285.30866.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 17:18:05',-21600,'2014-02-25 23:18:05',NULL,'[openstack-dev] Hacking and PEP 257: Extra blank line at end of\n multi-line docstring','On Tue, 2014-02-25 at 00:56 +0000, Ziad Sawalha wrote:\n> Seeking some clarification on the OpenStack hacking guidelines for\n> multi-string docstrings. \n> \n> \n> Q: In OpenStack projects, is a blank line before the triple closing\n> quotes recommended (and therefore optional - this is what PEP-257\n> seems to suggest), required, or explicitly rejected (which could be\n> one way to interpret the hacking guidelines since they omit the blank\n> line).\n\n\nI lobbied to relax that restriction, because I happen to use Emacs, and\nknow that that limitation no longer exists with Emacs.  I submitted the\nchange that eliminated that language from nova\'s HACKING at the time?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<2E7FE045-A0F0-4FC6-B6EE-FED3598186E7@rackspace.com>',NULL),('<1393371965.26205.194.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 18:46:05',-18000,'2014-02-25 23:46:05',NULL,'[openstack-dev] [nova] Future of the Nova API','On Tue, 2014-02-25 at 09:26 -0500, Sean Dague wrote:\n> What I want out of Nova API at the end of the day:\n> \n> 1. a way to discover what the API is\n> \n> because this massively simplifies writing clients, SDKs, tests, and\n> documentation. All those pipelines are terribly manual, and have errors\n> in them because of it. Like has been said before you actually need to\n> read the Nova source code to figure out how to use parts of the API.\n\n++\n\nThe key here, IMO, is to have JSON-Schema documents returned in the same\nmanner as Glance\'s v2 API and Heroku\'s API does, with separate schema\ndocuments returned for each resource exposed in the API.\n\n> 2. stop being optional\n> \n> If we ever want interoperability between Nova implementations we need to\n> stop allowing the API to be optional. That means getting rid of\n> extensions. Content is either part of the Nova API, or it isn\'t in the\n> tree. Without this we\'ll never get an ecosystem around the API because\n> anything more complicated than basic server lifecycle is not guarunteed\n> to exist in an OpenStack implementation.\n> \n> Extensions thus far have largely just been used as a cheat to get around\n> API compatibility changes based on the theory that users could list\n> extensions to figure out what the API would look like. It\'s a bad\n> theory, and not even nova command line does this. So users will get\n> errors on nova cli with clouds because features aren\'t enabled, and the\n> user has no idea why their commands don\'t work. Because it\'s right there\n> in the nova help.\n\nNo surprise... 100% agreement from me on this.\n\n> 3. a solid validation surface\n> \n> We really need to be far more defensive on our API validation surface.\n> Right now bad data makes it far too far down the code stack. That\'s just\n> a recipe for security issues.\n\n++. WSME makes this kind of thing much more solid. What is/was the\nstatus of WSME/Pecan integration in Nova?\n\nBest,\n-jay\n\n\n\n','<530CA801.6080000@dague.net>',NULL),('<1393412333.26205.196.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 05:58:53',-18000,'2014-02-26 10:58:53',NULL,'[openstack-dev] [Mistral] Renaming action types','On Wed, 2014-02-26 at 14:38 +0700, Renat Akhmerov wrote:\n> Folks,\n> \n> I?m proposing to rename these two action types REST_API and\n> MISTRAL_REST_API to HTTP and MISTRAL_HTTP. Words ?REST? and ?API?\n> don?t look correct to me, if you look at\n> \n> \n> Services:\n>   Nova:\n>     type: REST_API\n>     parameters:\n>       baseUrl: {$.novaURL}\n>     actions:\n>       createVM:\n>         parameters:\n>           url: /servers/{$.vm_id}\n>           method: POST\n>    \n> There?s no information about ?REST? or ?API? here. It?s just a spec\n> how to form an HTTP request.\n\n+1 on HTTP and MISTRAL_HTTP.\n\nOn an unrelated note, would it be possible to use under_score_naming\ninstead of camelCase naming?\n\nBest,\n-jay\n\n\n\n\n','<03FC2583-79C1-40DA-ADDB-2E7D0233CE3E@mirantis.com>',NULL),('<1393418153.3082.6.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-26 07:35:53',-18000,'2014-02-26 12:35:53',NULL,'[openstack-dev] [Neutron][LBaaS] Object Model discussion','On Wed, 2014-02-26 at 16:11 +0400, Eugene Nikanorov wrote:\n\n> On Wed, Feb 26, 2014 at 12:24 AM, Jay Pipes <jaypipes at gmail.com>\n> wrote:\n\n>         neutron l7-policy-create --type=\"uri-regex-matching\" \\\n>          --attr=URIRegex=\"static\\.example\\.com.*\"\n>         \n>         Presume above returns an ID for the policy $L7_POLICY_ID. We\n>         could then\n>         \n>         assign that policy to operate on the front-end of the load\n>         balancer and\n>         spreading load to the nginx nodes by doing:\n>         \n>         neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \\\n>          --subnet-cidr=192.168.1.0/24\n>         \n>         We could then indicate to the balancer that all other traffic\n>         should be\n>         sent to only the Apache nodes:\n>         \n>         neutron l7-policy-create --type=\"uri-regex-matching\" \\\n>          --attr=URIRegex=\"static\\.example\\.com.*\" \\\n>          --attr=\"RegexMatchReverse=true\"\n>         \n>         neutron balancer-apply-policy $BALANCER_ID $L7_POLICY_ID \\\n>          --subnet-cidr=192.168.2.0/24\n> That\'s cheating! :)\n\n:)\n\n> Once you have both static and webapp servers on one subnet, you\'ll\n> have to introduce the notion of \'node groups\', \n> e.g. pools, and somehow refer them within single $BALANCER_ID.\n\nAgreed. In fact, I had a hangout with Stephen yesterday evening to chat\nabout just this thing.\n\nI admit that the notion of a named pool of instances would be necessary\nin these cases.\n\nThat said, what it all boils down to is generating a list of backend IP\naddresses. Whether we use a subnet_cidr or a named pool ID, all that is\nhappening is allowing the user to specify a group of nodes together.\n\nSo, I\'d love it if both options were possible (i.e. allow subnet_id,\nsubnet_cidr, pool_id and pool_name when specifying groups of nodes with\nbalancer-apply-policy) \n> \n> I think notions from world of load balancing are unavoidable in the\n> API and we should not try to get rid of them.\n>  \n>         The biggest advantage to this proposed API and CLI is that we\n>         are not\n>         introducing any terminology into the Neutron LBaaS API that is\n>         not\n>         necessary when existing terms in the main Neutron API already\n>         exist to\n>         describe such things. \n> But is there much point in this? We\'are introducing quite a lot even\n> within this proposal: loadbalancer, l7-policy, healthchecks, etc.\n\nFair point. Was just brainstorming :)\n> \n>         You will note that I do not use the term \"pool\"\n>         above, since the concept of a subnet (and its associated CIDR)\n>         are\n>         already well-established objects in the Neutron API and can\n>         serve the\n>         exact same purpose for Neutron LBaaS API.\n> The subnet is just not flexible enough. Not to say that some\n> implementations may not support having nodes on different subnets,\n> while may support L7 rules.\n\nAgreed. Would just like it to be an option instead of forcing the user\nto create a pool if they don\'t need to (i.e. the subnet would work just\nfine...)\n\n>         > As far as hiding implementation details from the user:  To a\n>         certain\n>         > degree I agree with this, and to a certain degree I do not:\n>         OpenStack\n>         > is a cloud OS fulfilling the needs of supplying IaaS. It is\n>         not a\n>         > PaaS. As such, the objects that users deal with largely are\n>         analogous\n>         > to physical pieces of hardware that make up a cluster,\n>         albeit these\n>         > are virtualized or conceptualized. Users can then use these\n>         conceptual\n>         > components of a cluster to build the (virtual)\n>         infrastructure they\n>         > need to support whatever application they want. These\n>         objects have\n>         > attributes and are expected to act in a certain way, which\n>         again, are\n>         > usually analogous to actual hardware.\n>         \n>         \n>         I disagree. A cloud API should strive to shield users of the\n>         cloud from\n>         having to understand underlying hardware APIs or object\n>         models.\n>  \n> I think Stephen\'s suggestion is not about underlying hardware API, but\n> about the set of building blocks.\n> Across all services, Libra/Atlas, ELB, LBaaS those blocks are the same\n> no matter how we name them.\n\nSure, understood. Just trying to brainstorm a bit on how to keep\nflexibility in the LBaaS API while also simplifying it as much as\npossible.\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwORwuv0qrmkGioqqcOZpBkXi5gosa=xLb5QYSEEcfg2zOQ@mail.gmail.com>',NULL),('<1393523544.2185.8.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 12:52:24',-18000,'2014-02-27 17:52:24',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Thu, 2014-02-27 at 16:13 +0000, Henry Nash wrote:\n> So a couple of things about this:\n> \n> \n> 1) Today (and also true for Grizzly and Havana), the user can chose\n> what LDAP attribute should be returned as the user or group ID.  So it\n> is NOT a safe assumption today (ignoring any support for\n> domain-specific LDAP support) that the format of a user or group ID is\n> a 32 char UUID.  Quite often, I would think, that email address would\n> be chosen by a cloud provider as the LDAP id field, by default we use\n> the CN.  Since we really don\'t want to ever change the user or group\n> ID we have given out from keystone for a particular entity, this means\n> we need to update nova (or anything else) that has made a 32 char\n> assumption.\n\nI don\'t believe this is correct. Keystone is the service that deals with\nauthentication. As such, Keystone should be the one and only one service\nthat should have any need whatsoever to need to understand a non-UUID\nvalue for a user ID. The only value that should ever be communicated\n*from* Keystone should be the UUID value of the user.\n\nIf the Keystone service uses LDAP or federation for alternative\nauthentication schemes, then Keystone should have a mapping table that\ntranslates those elongated and non-UUID identifiers values (email\naddresses, LDAP CNs, etc) into the UUID value that is then communicated\nto all other OpenStack services.\n\nBest,\n-jay\n\n> 2) In oder to support the ability for service providers to be able to\n> have the identity part of keystone be satisfied by a customer LDAP\n> (i.e. for a given domain, have a specific LDAP), then, as has been\n> stated, we need to subsequently, when handed an API call with just a\n> user or group ID, be able to \"route\" this call to the correct LDAP.\n>  Trying to keep true to the openstack design principles, we had\n> planned to encode a domain identifier into the user or group ID - i.e.\n> distribute the data to where it is needed, in ortherwords, the user\n> and group ID provide all the info we need to route the call to the\n> right place. Two implementations come to mind:\n> 2a) Simply concatenate the user/group ID with the domain_id, plus some\n> separator and make a composite public facing ID.  e.g.\n> \"user_entity_id@@UUID_of_domain\".  This would have a technical maximum\n> size of 64+2+64 (i.e. 130), although in reality since we control\n> domain_id and we know it is always 32 char UUID - in fact the max size\n> would be 98.  This has the problem of increasing the size of the\n> public facing field beyond the existing 64.  This is what we had\n> planned for IceHouse - and is currently in review.\n> 2b) Use a similar concatenation idea as 2a), but limit the total size\n> to the existing 64. Since we control domain_id, we could (internally\n> and not visibly to the outside world), create a domain_index, that was\n> used in place of domain_id in the publicly visible field, to minimize\n> the number of chars it requires.  So the public facing composite ID\n> might be something like <up to 54 chars of entity_id>@@<8 chars of\n> domain_index>.  There is a chance, of course, that  the 54 char\n> restriction might be problematic for LDAP users....but I doubt it.  We\n> would make that a restriction and if it really became a problem, we\n> could consider a field size increase at a later release\n> 3) The alternative to 2a and 2b is to have, as had been suggested, an\n> internal mapping table that maps external facing entity_ids to a\n> domain plus local entity ID.  The problem with this idea is that:\n> - This could become a very big table (you will essentially have an\n> entry for every user in every corporate LDAP that has accessed a given\n> openstack)\n> - Since most LDAPs are RO, we will never see deletes...so we won\'t\n> know when (without some kind of garbage collection) to cull entries\n> - It obviously does not solve 1) - since existing LDAP support can\n> break the 32 char limit - and so it isn\'t true that this mapping table\n> causes all public facing entity IDs to be simple 32 char UUIDs\n> \n> \n> From a delivery into IceHouse point of view any of the above are\n> possible, since the actual mapping used is relatively small part of\n> the patch.  I personally favor 2b), since it is simple, has \"less\n> moving parts\" and does not change any external facing requirements for\n> storage of user and group IDs (above and beyond what is true today).\n> \n> \n> Henry\n> On 27 Feb 2014, at 03:46, Adam Young <ayoung at redhat.com> wrote:\n> \n> > On 02/26/2014 08:25 AM, Dolph Mathews wrote:\n> > \n> > > \n> > > On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <jaypipes at gmail.com>\n> > > wrote:\n> > >         On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote:\n> > >         > For purposes of supporting multiple backends for\n> > >         Identity (multiple\n> > >         > LDAP, mix of LDAP and SQL, federation, etc) Keystone is\n> > >         planning to\n> > >         > increase the maximum size of the USER_ID field from an\n> > >         upper limit of\n> > >         > 64 to an upper limit of 255. This change would not\n> > >         impact any\n> > >         > currently assigned USER_IDs (they would remain in the\n> > >         old simple UUID\n> > >         > format), however, new USER_IDs would be increased to\n> > >         include the IDP\n> > >         > identifier (e.g. USER_ID@@IDP_IDENTIFIER).\n> > >         \n> > >         \n> > >         -1\n> > >         \n> > >         I think a better solution would be to have a simple\n> > >         translation table\n> > >         only in Keystone that would store this longer identifier\n> > >         (for folks\n> > >         using federation and/or LDAP) along with the Keystone user\n> > >         UUID that is\n> > >         used in foreign key relations and other mapping tables\n> > >         through Keystone\n> > >         and other projects.\n> > > \n> > > \n> > > Morgan and I talked this suggestion through last night and agreed\n> > > it\'s probably the best approach, and has the benefit of zero\n> > > impact on other services, which is something we\'re obviously\n> > > trying to avoid. I imagine it could be as simple as a user_id to\n> > > domain_id lookup table. All we really care about is \"given a\n> > > globally unique user ID, which identity backend is the user from?\"\n> > > \n> > > \n> > > On the downside, it would likely become bloated with unused\n> > > ephemeral user IDs, so we\'ll need enough metadata about the\n> > > mapping to implement a purging behavior down the line.\n> > UUIDs are 32 chars long.  Its really just uuid@@uuid that pushes us\n> > over the 64 character limit.  \n> > If we can shorten up the IDP_ID we can fit everything in 64 chars\n> > (which means only Nova needs to expand its column size)\n> > \n> > What if we enumerated IDPs by index, from 10000000 to 99999999 or\n> > something comparable, and then use the new domain_index (or prot\n> > domain id to not be a uuid).  Then the above scheme would work and\n> > no migration would be required.\n> > \n> > \n> > >  \n> > >         \n> > >         The only identifiers that would ever be communicated to\n> > >         any non-Keystone\n> > >         OpenStack endpoint would be the UUID user and tenant IDs.\n> > >         \n> > >         > There is the obvious concern that projects are utilizing\n> > >         (and storing)\n> > >         > the user_id in a field that cannot accommodate the\n> > >         increased upper\n> > >         > limit. Before this change is merged in, it is important\n> > >         for the\n> > >         > Keystone team to understand if there are any places that\n> > >         would be\n> > >         > overflowed by the increased size.\n> > >         \n> > >         \n> > >         I would go so far as to say the user_id and tenant_id\n> > >         fields should be\n> > >         *reduced* in size to a fixed 16-char BINARY or 32-char\n> > >         CHAR field for\n> > >         performance reasons. Lengthening commonly-used and\n> > >         frequently-joined\n> > >         identifier fields is not a good option, IMO.\n> > >         \n> > >         Best,\n> > >         -jay\n> > >         \n> > >         > The review that would implement this change in size\n> > >         > is https://review.openstack.org/#/c/74214 and is\n> > >         actively being worked\n> > >         > on/reviewed.\n> > >         >\n> > >         >\n> > >         > I have already spoken with the Nova team, and a single\n> > >         instance has\n> > >         > been identified that would require a migration (that\n> > >         will have a fix\n> > >         > proposed for the I3 timeline).\n> > >         >\n> > >         >\n> > >         > If there are any other known locations that would have\n> > >         issues with an\n> > >         > increased USER_ID size, or any concerns with this change\n> > >         to USER_ID\n> > >         > format, please respond so that the issues/concerns can\n> > >         be addressed.\n> > >         >  Again, the plan is not to change current USER_IDs but\n> > >         that new ones\n> > >         > could be up to 255 characters in length.\n> > >         >\n> > >         >\n> > >         > Cheers,\n> > >         > Morgan Fainberg\n> > >         > ?\n> > >         > Morgan Fainberg\n> > >         > Principal Software Engineer\n> > >         > Core Developer, Keystone\n> > >         > m at metacloud.com\n> > >         >\n> > >         >\n> > >         \n> > >         > _______________________________________________\n> > >         > OpenStack-dev mailing list\n> > >         > OpenStack-dev at lists.openstack.org\n> > >         >\n> > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >         \n> > >         \n> > >         \n> > >         _______________________________________________\n> > >         OpenStack-dev mailing list\n> > >         OpenStack-dev at lists.openstack.org\n> > >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<85B9E404-AF89-47D4-9E3E-6E27BEF8540F@linux.vnet.ibm.com>',NULL),('<1393523603.082622285@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-02-27 11:53:23',-21600,'2014-02-27 17:53:23',NULL,'[openstack-community] OpenStack events update: 1 pod left for\n	Interop, World Hosting Days kiosks still available','\nHi again,  There is 1 pod&panel spot left (of 10) for Cloud Connect Summit / Interop in Las Vegas and room for a few more kiosks at World Hosting Days at Europa Park, Germany. Both events are April 1-3. Please email me directly if interested at kathyc at openstack.org. Thank you!\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140227/78f520a5/attachment.html>\n\n',NULL,NULL),('<1393523994.2185.15.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-02-27 12:59:54',-18000,'2014-02-27 17:59:54',NULL,'[Openstack-operators] Configuration for Dell R820','On Wed, 2014-02-26 at 13:20 +0000, P??kk?nen Pekka wrote:\n> Hi,\n> \n> I am planning OpenStack configuration for a server rack with the\n> following spec:\n> \n> Dell PowerEdge R820: \n> \n> + 4 processors (Intel Xeon E5-4620), 8 cores/processor\n> + 512 GB RAM\n> + 8 HDD, 1 TB/disk\n> + 2*1Gb, 2*10Gb network cards\n> \n> How would it be reasonable to configure controller and compute nodes\n> in terms of vCPUs and memory?\n\nAre you talking about making virtual machines out of the above R820\nhardware nodes to serve as controllers? Or are you talking about\nactually using one or more full R820 nodes as controllers?\n\n> I am planning to use one controller due to shortage of public IP\n> addresses, and I am wondering how many compute nodes I should use?\n\nA shortage of public IP addresses should have no effect on your choice\nin number of controllers. That is what load balancers are for...\n\n> A use case of interest is execution of database instances in OpenStack\n> with a write heavy workload.\n\nNote that no OpenStack service except for Ceilometer has a write-heavy\nworkload (exception: Keystone\'s tokens table if you are using the SQL\nbackend for tokens -- not recommended, use memcache).\n\nI do not recommend putting Ceilometer\'s database on the same node as you\nuse for other databases for OpenStack services. I would personally\nrecommend using MySQL Galera or PostgreSQL for non-Ceilometer OpenStack\nservice databases, and using MongoDB or a well tuned standard MySQL\nmaster/slave setup for Ceilometer.\n\n> I was hinted in the ?Ask OpenStack?-service that 32 GB, 2  vCPUs per\n> virtual machine may be a good starting point.\n\nOur controllers at AT&T were 16GB 12-core machines with <1 TB of disk.\nBut, we did not put databases and message queues on the same machines as\ncontrollers. Our controllers were stateless so that we could expand API\nthroughput separately from database and message queue throughput.\n\nBest,\n-jay\n\n\n\n\n','<792997416F795F469B4A87A6FEC9F9761E3FC1E4@VTTMAIL3.ad.vtt.fi>',NULL),('<1393529679.5487.42.camel@yjiang5-linux1>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 11:34:39',-28800,'2014-02-27 19:34:39',NULL,'[openstack-dev] [Nova] why force_config_drive is a per comptue node\n	config','Greeting,\n	I have some questions on the force_config_drive configuration options\nand hope get some hints.\n	a) Why do we want this? Per my understanding, if the user want to use\nthe config drive, they need specify it in the nova boot. Or is it\nbecause possibly user have no idea of the cloudinit installation in the\nimage?\n\n	b) even if we want to force config drive, why it\'s a compute node\nconfig instead of cloud wise config? Compute-node config will have some\nmigration issue per my understanding.\n\n	Did I missed anything important?\n\nThanks\n--jyh\n\n\n\n',NULL,NULL),('<1393535792.2185.33.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 16:16:32',-18000,'2014-02-27 21:16:32',NULL,'[openstack-dev] [OpenStack-Infra] [third-party-ci] Proposing a\n regular workshop/meeting to help folks set up CI environments','On Wed, 2014-02-26 at 12:09 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> Rather than March 3rd \n> \n> Can you kindly make it on Feb 28th if possible.\n\nUnfortunately, Trinath, I can\'t make it tomorrow during that time. I can\ntry and be on IRC earlier in the day, though, to help you?\n\n> I\'m interested in attending the meeting. \n> \n> I have doubts to get clarified regarding setp, configuration and CI system.\n\nPlease let me know what your issues are and I\'ll try to answer you asap.\n\nBest,\n-jay\n\n\n\n','<445b93d992da4a9e9b2c79cc31bbd8e2@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1393535792.2185.33.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-27 16:16:32',-18000,'2014-02-27 21:16:32',NULL,'[OpenStack-Infra] [third-party-ci] Proposing a regular\n workshop/meeting to help folks set up CI environments','On Wed, 2014-02-26 at 12:09 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> Rather than March 3rd \n> \n> Can you kindly make it on Feb 28th if possible.\n\nUnfortunately, Trinath, I can\'t make it tomorrow during that time. I can\ntry and be on IRC earlier in the day, though, to help you?\n\n> I\'m interested in attending the meeting. \n> \n> I have doubts to get clarified regarding setp, configuration and CI system.\n\nPlease let me know what your issues are and I\'ll try to answer you asap.\n\nBest,\n-jay\n\n\n\n','<445b93d992da4a9e9b2c79cc31bbd8e2@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1393540661.2185.52.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 17:37:41',-18000,'2014-02-27 22:37:41',NULL,'[openstack-dev] [Neutron] Flavor Framework','On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:\n> Hi neutron folks,\n> \n> I know that there are patches on gerrit for VPN, FWaaS and L3 services\n> that are leveraging Provider Framework. \n> Recently we\'ve been discussing more comprehensive approach that will\n> allow user to choose service capabilities rather than vendor or\n> provider.\n> \n> I\'ve started creating design draft of Flavor Framework, please take a\n> look: \n> https://wiki.openstack.org/wiki/Neutron/FlavorFramework\n> \n> It also now looks clear to me that the code that introduces providers\n> for vpn, fwaas, l3 is really necessary to move forward to Flavors with\n> one exception: providers should not be exposed to public API.\n> While provider attribute could be visible to administrator (like\n> segmentation_id of network), it can\'t be specified on creation and\n> it\'s not available to a regular user.\n\nA few thoughts, Eugene, and thanks for putting together the wiki page\nwhere we can work on this important topic.\n\n1) I\'m not entirely sure that a provider attribute is even necessary to\nexpose in any API. What is important is for a scheduler to know which\ndrivers are capable of servicing a set of attributes that are grouped\ninto a \"flavor\".\n\n2) I would love to see the use of the term \"flavor\" banished from\nOpenStack APIs. Nova has moved from flavors to \"instance types\", which\nclearly describes what the thing is, without the odd connotations that\nthe word \"flavor\" has in different languages (not to mention the fact\nthat flavor is spelled flavour in non-American English).\n\nHow about using the term \"load balancer type\", \"VPN type\", and \"firewall\ntype\" instead?\n\n3) I don\'t believe the FlavorType (public or internal) attribute of the\nflavor is useful. We want to get away from having any vendor-specific\nattributes or objects in the APIs (yes, even if they are \"hidden\" from\nthe normal user). See point #1 for more about this. A scheduler should\nbe able to match a driver to a request simply by matching the set of\nrequired capabilities in the requested flavor (load balancer type) to\nthe set of capabilities advertised by the driver.\n\n4) A minor point... I think it would be fine to group the various\n\"types\" into a single database table behind the scenes (like you have in\nthe Object model section). However, I think it is useful to have the\npublic API expose a /$servie-types resource endpoint for each service\nitself, instead of a generic /types (or /flavors) endpoint. So, folks\nlooking to set up a load balancer would call GET /balancer-types, or\ncall neutron balancer-type-list, instead of calling\nGET /types?service=load-balancer or neutron flavor-list\n--service=load-balancer\n\n5) In the section on Scheduling, you write \"Scheduling is a process of\nchoosing provider and a backend for the resource\". As mentioned above, I\nthink this could be changed to something like this: \"Scheduling is a\nprocess of matching the set of requested capabilities -- the flavor\n(type) -- to the set of capabilities advertised by a driver for the\nresource\". That would put Neutron more in line with how Nova handles\nthis kind of thing.\n\nAnyway, just food for thought.\n\nBest,\n-jay\n\n\n> Looking forward to get your feedback.\n> \n> \n> Thanks,\n> Eugene.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAJfiwOSpAYocvnMVxROjxY7zH2tjMiT5=o9-NZ=dspYd-8EwAg@mail.gmail.com>',NULL),('<1393549516.2185.54.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 20:05:16',-18000,'2014-02-28 01:05:16',NULL,'[openstack-dev] [Neutron] Flavor Framework','On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:\n> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:\n> >> Hi neutron folks,\n> >>\n> >> I know that there are patches on gerrit for VPN, FWaaS and L3 services\n> >> that are leveraging Provider Framework.\n> >> Recently we\'ve been discussing more comprehensive approach that will\n> >> allow user to choose service capabilities rather than vendor or\n> >> provider.\n> >>\n> >> I\'ve started creating design draft of Flavor Framework, please take a\n> >> look:\n> >> https://wiki.openstack.org/wiki/Neutron/FlavorFramework\n> >>\n> >> It also now looks clear to me that the code that introduces providers\n> >> for vpn, fwaas, l3 is really necessary to move forward to Flavors with\n> >> one exception: providers should not be exposed to public API.\n> >> While provider attribute could be visible to administrator (like\n> >> segmentation_id of network), it can\'t be specified on creation and\n> >> it\'s not available to a regular user.\n> >\n> > A few thoughts, Eugene, and thanks for putting together the wiki page\n> > where we can work on this important topic.\n> >\n> > 1) I\'m not entirely sure that a provider attribute is even necessary to\n> > expose in any API. What is important is for a scheduler to know which\n> > drivers are capable of servicing a set of attributes that are grouped\n> > into a \"flavor\".\n> >\n> > 2) I would love to see the use of the term \"flavor\" banished from\n> > OpenStack APIs. Nova has moved from flavors to \"instance types\", which\n> > clearly describes what the thing is, without the odd connotations that\n> > the word \"flavor\" has in different languages (not to mention the fact\n> > that flavor is spelled flavour in non-American English).\n> \n> This isn\'t true, we moved towards preferring the term flavor.\n\nReally? When did this happen?\n\n> > How about using the term \"load balancer type\", \"VPN type\", and \"firewall\n> > type\" instead?\n> >\n> > 3) I don\'t believe the FlavorType (public or internal) attribute of the\n> > flavor is useful. We want to get away from having any vendor-specific\n> > attributes or objects in the APIs (yes, even if they are \"hidden\" from\n> > the normal user). See point #1 for more about this. A scheduler should\n> > be able to match a driver to a request simply by matching the set of\n> > required capabilities in the requested flavor (load balancer type) to\n> > the set of capabilities advertised by the driver.\n> >\n> > 4) A minor point... I think it would be fine to group the various\n> > \"types\" into a single database table behind the scenes (like you have in\n> > the Object model section). However, I think it is useful to have the\n> > public API expose a /$servie-types resource endpoint for each service\n> > itself, instead of a generic /types (or /flavors) endpoint. So, folks\n> > looking to set up a load balancer would call GET /balancer-types, or\n> > call neutron balancer-type-list, instead of calling\n> > GET /types?service=load-balancer or neutron flavor-list\n> > --service=load-balancer\n> >\n> > 5) In the section on Scheduling, you write \"Scheduling is a process of\n> > choosing provider and a backend for the resource\". As mentioned above, I\n> > think this could be changed to something like this: \"Scheduling is a\n> > process of matching the set of requested capabilities -- the flavor\n> > (type) -- to the set of capabilities advertised by a driver for the\n> > resource\". That would put Neutron more in line with how Nova handles\n> > this kind of thing.\n> >\n> > Anyway, just food for thought.\n> >\n> > Best,\n> > -jay\n> >\n> >\n> >> Looking forward to get your feedback.\n> >>\n> >>\n> >> Thanks,\n> >> Eugene.\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAHXdxOfvjW2hb621Zavb+y=y2C=H_vRFwvtgP16cidSR8eEP6A@mail.gmail.com>',NULL),('<1393550443.2185.60.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 20:20:43',-18000,'2014-02-28 01:20:43',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Thu, 2014-02-27 at 17:02 -0500, Adam Young wrote:\n> On 02/27/2014 12:52 PM, Jay Pipes wrote:\n> > On Thu, 2014-02-27 at 16:13 +0000, Henry Nash wrote:\n> >> So a couple of things about this:\n> >>\n> >>\n> >> 1) Today (and also true for Grizzly and Havana), the user can chose\n> >> what LDAP attribute should be returned as the user or group ID.  So it\n> >> is NOT a safe assumption today (ignoring any support for\n> >> domain-specific LDAP support) that the format of a user or group ID is\n> >> a 32 char UUID.  Quite often, I would think, that email address would\n> >> be chosen by a cloud provider as the LDAP id field, by default we use\n> >> the CN.  Since we really don\'t want to ever change the user or group\n> >> ID we have given out from keystone for a particular entity, this means\n> >> we need to update nova (or anything else) that has made a 32 char\n> >> assumption.\n> > I don\'t believe this is correct. Keystone is the service that deals with\n> > authentication. As such, Keystone should be the one and only one service\n> > that should have any need whatsoever to need to understand a non-UUID\n> > value for a user ID. The only value that should ever be communicated\n> > *from* Keystone should be the UUID value of the user.\n> \n> We never said it was a UUID, its only been that in the \"allocated by \n> Keystone\" cases thus far.\n\nEvery user record in Keystone should have an \"allocated by Keystone\"\nuser ID that is a UUID value. Why? Because every single other OpenStack\nservice uses UUID values for identifiers (not names), and Keystone\nshould be no different.\n\n> userids are blobs....well, character blocks, and are not expected to be \n> interprested by the end services, but also not confined to be 32 \n> characters long.\n\nI would argue that they absolutely *should* be confined to 32 characters\n(or technically, 16 bytes, which is the size of a UUID).\n\n> Most LDAP use cases do not allow us to write data back the Directory. \n> Federation has the same use cases. \n\nFrankly, I don\'t care :) Let\'s say Super-Duper Identity Driver has 100\ncharacter IDs natively. Does that mean that these IDs need be sent all\nover the OpenStack ecosystem? No. Have a translation table in Keystone\nand spread the UUID user ID throughout OpenStack.\n\n>  That means that we are going to end \n> up with a slew of ephemeral data in Keystone for no real value.\n\nNot sure why you think this is ephemeral data... What is ephemeral about\na non-UUID identifier from another auth system (federated or not) that\nis mapped to a Keystone user UUID? If you look at virtually every\nflexible authentication mechanism in virtually all web frameworks out\nthere, you will see something very similar, where there is a table that\nmaps external IDs to the IDs that are native to some platform.\n\nBest,\n-jay\n\n> >\n> > If the Keystone service uses LDAP or federation for alternative\n> > authentication schemes, then Keystone should have a mapping table that\n> > translates those elongated and non-UUID identifiers values (email\n> > addresses, LDAP CNs, etc) into the UUID value that is then communicated\n> > to all other OpenStack services.\n> The short of it is that we need to define a max userid length and stick \n> to it.   Thus far, we\'ve had 64 characters in Keystone, and I think we \n> can stick with that.  Nova needs to expand its view to 64 chars.\n> \n> The rest is Keystone internals to deal with.\n> \n> >\n> > Best,\n> > -jay\n> >\n> >> 2) In oder to support the ability for service providers to be able to\n> >> have the identity part of keystone be satisfied by a customer LDAP\n> >> (i.e. for a given domain, have a specific LDAP), then, as has been\n> >> stated, we need to subsequently, when handed an API call with just a\n> >> user or group ID, be able to \"route\" this call to the correct LDAP.\n> >>   Trying to keep true to the openstack design principles, we had\n> >> planned to encode a domain identifier into the user or group ID - i.e.\n> >> distribute the data to where it is needed, in ortherwords, the user\n> >> and group ID provide all the info we need to route the call to the\n> >> right place. Two implementations come to mind:\n> >> 2a) Simply concatenate the user/group ID with the domain_id, plus some\n> >> separator and make a composite public facing ID.  e.g.\n> >> \"user_entity_id@@UUID_of_domain\".  This would have a technical maximum\n> >> size of 64+2+64 (i.e. 130), although in reality since we control\n> >> domain_id and we know it is always 32 char UUID - in fact the max size\n> >> would be 98.  This has the problem of increasing the size of the\n> >> public facing field beyond the existing 64.  This is what we had\n> >> planned for IceHouse - and is currently in review.\n> >> 2b) Use a similar concatenation idea as 2a), but limit the total size\n> >> to the existing 64. Since we control domain_id, we could (internally\n> >> and not visibly to the outside world), create a domain_index, that was\n> >> used in place of domain_id in the publicly visible field, to minimize\n> >> the number of chars it requires.  So the public facing composite ID\n> >> might be something like <up to 54 chars of entity_id>@@<8 chars of\n> >> domain_index>.  There is a chance, of course, that  the 54 char\n> >> restriction might be problematic for LDAP users....but I doubt it.  We\n> >> would make that a restriction and if it really became a problem, we\n> >> could consider a field size increase at a later release\n> >> 3) The alternative to 2a and 2b is to have, as had been suggested, an\n> >> internal mapping table that maps external facing entity_ids to a\n> >> domain plus local entity ID.  The problem with this idea is that:\n> >> - This could become a very big table (you will essentially have an\n> >> entry for every user in every corporate LDAP that has accessed a given\n> >> openstack)\n> >> - Since most LDAPs are RO, we will never see deletes...so we won\'t\n> >> know when (without some kind of garbage collection) to cull entries\n> >> - It obviously does not solve 1) - since existing LDAP support can\n> >> break the 32 char limit - and so it isn\'t true that this mapping table\n> >> causes all public facing entity IDs to be simple 32 char UUIDs\n> >>\n> >>\n> >>  From a delivery into IceHouse point of view any of the above are\n> >> possible, since the actual mapping used is relatively small part of\n> >> the patch.  I personally favor 2b), since it is simple, has \"less\n> >> moving parts\" and does not change any external facing requirements for\n> >> storage of user and group IDs (above and beyond what is true today).\n> >>\n> >>\n> >> Henry\n> >> On 27 Feb 2014, at 03:46, Adam Young <ayoung at redhat.com> wrote:\n> >>\n> >>> On 02/26/2014 08:25 AM, Dolph Mathews wrote:\n> >>>\n> >>>> On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <jaypipes at gmail.com>\n> >>>> wrote:\n> >>>>          On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote:\n> >>>>          > For purposes of supporting multiple backends for\n> >>>>          Identity (multiple\n> >>>>          > LDAP, mix of LDAP and SQL, federation, etc) Keystone is\n> >>>>          planning to\n> >>>>          > increase the maximum size of the USER_ID field from an\n> >>>>          upper limit of\n> >>>>          > 64 to an upper limit of 255. This change would not\n> >>>>          impact any\n> >>>>          > currently assigned USER_IDs (they would remain in the\n> >>>>          old simple UUID\n> >>>>          > format), however, new USER_IDs would be increased to\n> >>>>          include the IDP\n> >>>>          > identifier (e.g. USER_ID@@IDP_IDENTIFIER).\n> >>>>          \n> >>>>          \n> >>>>          -1\n> >>>>          \n> >>>>          I think a better solution would be to have a simple\n> >>>>          translation table\n> >>>>          only in Keystone that would store this longer identifier\n> >>>>          (for folks\n> >>>>          using federation and/or LDAP) along with the Keystone user\n> >>>>          UUID that is\n> >>>>          used in foreign key relations and other mapping tables\n> >>>>          through Keystone\n> >>>>          and other projects.\n> >>>>\n> >>>>\n> >>>> Morgan and I talked this suggestion through last night and agreed\n> >>>> it\'s probably the best approach, and has the benefit of zero\n> >>>> impact on other services, which is something we\'re obviously\n> >>>> trying to avoid. I imagine it could be as simple as a user_id to\n> >>>> domain_id lookup table. All we really care about is \"given a\n> >>>> globally unique user ID, which identity backend is the user from?\"\n> >>>>\n> >>>>\n> >>>> On the downside, it would likely become bloated with unused\n> >>>> ephemeral user IDs, so we\'ll need enough metadata about the\n> >>>> mapping to implement a purging behavior down the line.\n> >>> UUIDs are 32 chars long.  Its really just uuid@@uuid that pushes us\n> >>> over the 64 character limit.\n> >>> If we can shorten up the IDP_ID we can fit everything in 64 chars\n> >>> (which means only Nova needs to expand its column size)\n> >>>\n> >>> What if we enumerated IDPs by index, from 10000000 to 99999999 or\n> >>> something comparable, and then use the new domain_index (or prot\n> >>> domain id to not be a uuid).  Then the above scheme would work and\n> >>> no migration would be required.\n> >>>\n> >>>\n> >>>>   \n> >>>>          \n> >>>>          The only identifiers that would ever be communicated to\n> >>>>          any non-Keystone\n> >>>>          OpenStack endpoint would be the UUID user and tenant IDs.\n> >>>>          \n> >>>>          > There is the obvious concern that projects are utilizing\n> >>>>          (and storing)\n> >>>>          > the user_id in a field that cannot accommodate the\n> >>>>          increased upper\n> >>>>          > limit. Before this change is merged in, it is important\n> >>>>          for the\n> >>>>          > Keystone team to understand if there are any places that\n> >>>>          would be\n> >>>>          > overflowed by the increased size.\n> >>>>          \n> >>>>          \n> >>>>          I would go so far as to say the user_id and tenant_id\n> >>>>          fields should be\n> >>>>          *reduced* in size to a fixed 16-char BINARY or 32-char\n> >>>>          CHAR field for\n> >>>>          performance reasons. Lengthening commonly-used and\n> >>>>          frequently-joined\n> >>>>          identifier fields is not a good option, IMO.\n> >>>>          \n> >>>>          Best,\n> >>>>          -jay\n> >>>>          \n> >>>>          > The review that would implement this change in size\n> >>>>          > is https://review.openstack.org/#/c/74214 and is\n> >>>>          actively being worked\n> >>>>          > on/reviewed.\n> >>>>          >\n> >>>>          >\n> >>>>          > I have already spoken with the Nova team, and a single\n> >>>>          instance has\n> >>>>          > been identified that would require a migration (that\n> >>>>          will have a fix\n> >>>>          > proposed for the I3 timeline).\n> >>>>          >\n> >>>>          >\n> >>>>          > If there are any other known locations that would have\n> >>>>          issues with an\n> >>>>          > increased USER_ID size, or any concerns with this change\n> >>>>          to USER_ID\n> >>>>          > format, please respond so that the issues/concerns can\n> >>>>          be addressed.\n> >>>>          >  Again, the plan is not to change current USER_IDs but\n> >>>>          that new ones\n> >>>>          > could be up to 255 characters in length.\n> >>>>          >\n> >>>>          >\n> >>>>          > Cheers,\n> >>>>          > Morgan Fainberg\n> >>>>          > ?\n> >>>>          > Morgan Fainberg\n> >>>>          > Principal Software Engineer\n> >>>>          > Core Developer, Keystone\n> >>>>          > m at metacloud.com\n> >>>>          >\n> >>>>          >\n> >>>>          \n> >>>>          > _______________________________________________\n> >>>>          > OpenStack-dev mailing list\n> >>>>          > OpenStack-dev at lists.openstack.org\n> >>>>          >\n> >>>>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>          \n> >>>>          \n> >>>>          \n> >>>>          _______________________________________________\n> >>>>          OpenStack-dev mailing list\n> >>>>          OpenStack-dev at lists.openstack.org\n> >>>>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<530FB5DF.9080703@redhat.com>',NULL),('<1393550564.2185.61.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 20:22:44',-18000,'2014-02-28 01:22:44',NULL,'[openstack-dev] [nova] Future of the Nova API','On Fri, 2014-02-28 at 00:30 +0100, Monty Taylor wrote:\n> Sorry for the top post. I was asked to look at this thread and toss in \n> my ?0.02 but I do not believe I could possibly read this whole thread - \n> I\'m too jet lagged. So...\n> \n> As a current large-scale production consumer of the API, I don\'t care at \n> all as long as python-novaclient keeps working at the Python Library API \n> level. I do  not care about the REST api specifics at all. I would \n> imagine that most Java folks only care that jclouds works. I would \n> imagine that most Ruby users would only care that fog works. Since \n> jclouds already supports a billion apis, I doubt supporting v2 and v3 \n> would be hard for them.\n> \n> AND\n> \n> As long as the v2/v3 switch is discoverable by the library and I don\'t, \n> as a consumer of the library, need to know about it - so that \n> python-novaclient will continue to support client operations on both \n> REST versions - I\'m fine with that - because I want to continue to be \n> able to operate the old Diablo-based HP cloud, the new trunk HP cloud, \n> the trunk Rackspace cloud and the TripleO cloud with the same scripts.\n> \n> That\'s what I want. I\'m sure other people want other things.\n\nThis is exactly what I want as well.\n\n-jay\n\n\n\n','<530FCA89.9090602@inaugust.com>',NULL),('<1393552451.2185.72.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 20:54:11',-18000,'2014-02-28 01:54:11',NULL,'[openstack-dev] [Neutron] Flavor Framework','On Thu, 2014-02-27 at 17:23 -0800, Joe Gordon wrote:\n> On Thu, Feb 27, 2014 at 5:05 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Thu, 2014-02-27 at 15:12 -0800, Joe Gordon wrote:\n> >> On Thu, Feb 27, 2014 at 2:37 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> >> > On Thu, 2014-02-27 at 02:11 +0400, Eugene Nikanorov wrote:\n> >> >> Hi neutron folks,\n> >> >>\n> >> >> I know that there are patches on gerrit for VPN, FWaaS and L3 services\n> >> >> that are leveraging Provider Framework.\n> >> >> Recently we\'ve been discussing more comprehensive approach that will\n> >> >> allow user to choose service capabilities rather than vendor or\n> >> >> provider.\n> >> >>\n> >> >> I\'ve started creating design draft of Flavor Framework, please take a\n> >> >> look:\n> >> >> https://wiki.openstack.org/wiki/Neutron/FlavorFramework\n> >> >>\n> >> >> It also now looks clear to me that the code that introduces providers\n> >> >> for vpn, fwaas, l3 is really necessary to move forward to Flavors with\n> >> >> one exception: providers should not be exposed to public API.\n> >> >> While provider attribute could be visible to administrator (like\n> >> >> segmentation_id of network), it can\'t be specified on creation and\n> >> >> it\'s not available to a regular user.\n> >> >\n> >> > A few thoughts, Eugene, and thanks for putting together the wiki page\n> >> > where we can work on this important topic.\n> >> >\n> >> > 1) I\'m not entirely sure that a provider attribute is even necessary to\n> >> > expose in any API. What is important is for a scheduler to know which\n> >> > drivers are capable of servicing a set of attributes that are grouped\n> >> > into a \"flavor\".\n> >> >\n> >> > 2) I would love to see the use of the term \"flavor\" banished from\n> >> > OpenStack APIs. Nova has moved from flavors to \"instance types\", which\n> >> > clearly describes what the thing is, without the odd connotations that\n> >> > the word \"flavor\" has in different languages (not to mention the fact\n> >> > that flavor is spelled flavour in non-American English).\n> >>\n> >> This isn\'t true, we moved towards preferring the term flavor.\n> >\n> > Really? When did this happen?\n> \n> https://blueprints.launchpad.net/nova/+spec/flavor-instance-type-dedup\n> \n> I wasn\'t aware of the decision to move to instance types. I could ask\n> you the same thing, \'really when did that happen\'\n\nI could have sworn there was a conversation (I remember John Garbutt\nspecifically bringing up the problem of non-American-English spelling of\nflavour) on openstack-dev, but I can\'t find it right now...\n\nOn your blueprint, you have:\n\n\"russellb: stick with our own terminology (flavor) except when\nspecifically doing EC2 handling IMO\" ~ 2013-3-4\n\nUnfortunately, nobody specified whether that was a design session, an ML\nconversation or some random quote from IRC, so it\'s not entirely clear\nwhere the decision came from or where the discussion was had. :)\n\nI do note, however, that the blueprint is still going on, with the\nlatest Abandoned patch some time last January. I\'ll also note that\ninstance_type is used all over the documentation, is used in places like\nHeat templating, and in general just makes a lot more sense. There\'s\nalso 401K results in Google for \"instance_type Nova API\" vs. 292K\nresults for \"flavor Nova API\". Just sayin.\n\nRegardless of this, I still vote to *not* use the term flavor in\nNeutron\'s API, but use the term \"type\" instead, and hopefully my other\npoints about Neutron types won\'t get lost in this side conversation ;)\n\nBest,\n-jay\n\n\n\n','<CAHXdxOddkyQNpw6OiuztmQ_y-19rFytfNPKqmX_aGm7y9_jCFw@mail.gmail.com>',NULL),('<1393555938.2185.100.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-27 21:52:18',-18000,'2014-02-28 02:52:18',NULL,'[openstack-dev] [Neutron][LBaaS] Enterprise Ready Features','On Wed, 2014-02-26 at 18:46 +0000, Brandon Logan wrote:\n> TL;DR: Are enterprise needed features (HA, scalability, resource\n> management, etc) on this project\'s roadmap.\n\nYes. Although, due to my disdain for the term \"enterprise\", I\'d point\nout that all of those features are things that most everyone wants, not\njust shops with stodgy, old, legacy IT departments -- I mean...\n\"enterprises\" ;)\n\n>  If so, how much of a priority is it?\n\nNot sure.\n\n> I\'ve been doing some research on Neutron LBaaS to determine the\n> viability and what needs to be done to allow for it to become an\n> enterprise ready solution. \n\nOut of curiosity, since you are at Rackspace, what about Atlas LB?\n\n>  Since I am fairly new to this project please forgive me, and also\n> correct me, if my understanding of some of these things is false.\n> I\'ve already spoken to Eugene about some of this, but I think it would\n> be nice to get everyone\'s opinion.  And since the object model\n> discussions are going on right now I believe this to be a good time to\n> bring it up.\n\nYa, no worries. I\'m new to the LBaaS discussions myself.\n\n> As of its current incarnation Neutron LBaaS does not seem to be HA,\n> scalable, and doesn\'t isolate resources for each load balancer.  I\n> know there is a blueprint for HA for the agent\n> (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-agent) and HA\n> for HaProxy\n> (https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy).\n> That is only for HaProxy, though, and sounds like it has to be\n> implemented at the driver level.\n\nRight. Different drivers will enable HA in different ways.\n\n> Is that the intended direction for implementing these goals, to\n> implement them at the driver level?\n\nI *believe* that is the intended direction, yes. The ongoing\nconversations about Neutron \"flavors\" as well as the conversation about\nthe future object model and API have really been about how to expose the\ncapabilities of different drivers -- and match those capabilities to\nrequested capabilities from the user -- without leaking any particular\ndriver\'s implementation specifics into the public API. I think the hope\nis that in the coming few months and during the summit, the community\nwill coalesce around a game plan for implementing \"flavors\" (or types,\nas I prefer to call them), and from that implementation, contributors\nwill be able to work on adding these features to drivers and expose this\nfunctionality in a generic fashion.\n\n>  I can definitely see why that is the way to do it because some\n> drivers may already implement these features, while others don\'t.  It\n> would be nice if there was a way to give those features to drivers\n> that do not have it out of the box.\n\nWell, on the HA and scaling front, one solution is to run multiple\ninstances of something like HA Proxy and have some healthcheck software\nthat would fail over operations from one load balancer instance to\nanother if a failure condition occurred. In fact, that is similar to\nwhat the Libra project does with its node pool manager [1].\n\n> Basically, I\'d like this project to have these enterprise level\n> features to that it can be adopted in an enterprise cloud.  It will\n> require a lot of work to achieve these goals, and I believe it should\n> be something that is a goal.\n\nI don\'t think you\'ll get any disagreement from anyone on that :)\nAlthough there has certainly been a fragmentation of effort on the LBaaS\nfront with Atlas, Libra and Neutron LBaaS, it seems that the community\nis now coming together a bit.\n\nBest,\n-jay\n\n[1] http://libra.readthedocs.org/en/latest/pool_mgm/index.html\n\n\n\n\n','<EEC3B46DA00EE748B4EC91A1E4938A187F8887A3@ORD1EXD03.RACKSPACE.CORP>',NULL),('<1393581775.92334.YahooMailNeo@web122605.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-28 02:02:55',-28800,'2014-02-28 10:02:55',NULL,'[Openstack] keystone with external authentication using apache2\n	on havana/ubuntu1204','Hi Dave,\n\nFinally I found a solution for the problem that I was asking help for.\nI opted for keystone authentication based on sql for openstack services and based on ldap for normal users. For tenants and roles I used sql with this configuration in /etc/keystone/keystone.conf.\n\n[assignment]\ndriver = keystone.assignment.backends.sql.Assignment\n\n\nI used a hybrid authentication created by Ionut Artarisi and that can be found here: https://github.com/SUSE-Cloud/keystone-hybrid-backend.\n\nThanks a lot,\nGabriel\n\n\n\n\nOn Thursday, February 20, 2014 10:38 AM, Staicu Gabriel <gabriel_staicu at yahoo.com> wrote:\n \nHi Dave,\n\nThanks a lot for you interest in helping me. I will try to answer your questions as good as I can:\nI am using havana release of the openstack. I am starting from default keystone authentication:\nThis is my /etc/keystone/keystone.conf:\n\n\n[DEFAULT]\nlog_file = keystone.log\nlog_dir = /var/log/keystone\n[sql]\nconnection =\n mysql://keystoneuser:keystonepass at 153.65.235.39/keystone\n[identity]\ndriver = keystone.identity.backends.sql.Identity\n[credential]\ndriver = keystone.credential.backends.sql.Credential\n[trust]\ndriver = keystone.trust.backends.sql.Trust\n[os_inherit]\n[catalog]\ndriver = keystone.catalog.backends.sql.Catalog\n[endpoint_filter]\n[token]\ndriver = keystone.token.backends.sql.Token\n[cache]\n[policy]\ndriver = keystone.policy.backends.sql.Policy\n[ec2]\ndriver = keystone.contrib.ec2.backends.kvs.Ec2\n[assignment]\n[oauth1]\n[ssl]\n[signing]\n[ldap]\n[auth]\n\n\nThen I am doing:\nservice keystone start\nsource openstackrc\n\nThe content of openstackrc:\nexport OS_TENANT_NAME=admin\nexport OS_USERNAME=admin\nexport OS_PASSWORD=admin\nexport SERVICE_TOKEN=ADMIN\nexport OS_AUTH_URL=\"http://10.65.235.39:5000/v2.0/\"\nexport SERVICE_ENDPOINT=\"http://10.65.235.39:35357/v2.0\"\n\n\nkeystone user-list\nroot at ubuntu1204:~# keystone user-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+------------+---------+-------------------+\n|??????????????? id??????????????? |??? name??? | enabled |?????? email?????? |\n+----------------------------------+------------+---------+-------------------+\n| 813a815b593f495c9a449f9c5c44625d |?? admin??? |?? True? | admin at example.com |\n| 7df8919856ec4072927d2523bceed5eb | ceilometer |?? True? | admin at example.com |\n| b6aae4b745484e3da6892b68a7e322f9 |??\n cinder?? |?? True? | admin at example.com |\n| d08d5f5e515a4601b417a637cf690999 |??? demo??? |?? True? |? demo at example.com |\n| a3a5444d42b9462e8fcac9e3a10f2e60 |?? glance?? |?? True? | admin at example.com |\n| 1c1ab74a4a934273836f41999e2ac9fc |??? heat??? |?? True? | admin at example.com |\n| 823d9d20cbd8412887c3f6052eca720d |? neutron?? |?? True? | admin at example.com |\n| e58d30815fac48209bf56441e1d5bb76 |??? nova??? |?? True? | admin at example.com |\n+----------------------------------+------------+---------+-------------------+\n\n\n\n?keystone endpoint-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n|??????????????? id???????????????\n |?? region? |???????????????? publicurl????????????????? |??????????????? internalurl???????????????? |????????????????? adminurl????????????????? |??????????? service_id???????????\n |\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n| 05784027da8b4acb8489d0486faf9f61 |? myregion |? http://153.65.235.39:8773/services/cloud? |? http://153.65.235.39:8773/services/cloud? |? http://153.65.235.39:8773/services/admin? | 5bc96b5587aa4f12919f3a155b5713b0 |\n| 10a762a17a58478d8285c1ca6ed8344a |? myregion | http://153.65.235.39:8004/v1/$(tenant_id)s | http://153.65.235.39:8004/v1/$(tenant_id)s | http://153.65.235.39:8004/v1/$(tenant_id)s | 3308b160d21f4dac84b866063852a47a |\n| 23aff8a4b486423592ad877eb0eb29d2 |? myregion |?????? http://153.65.235.39:5000/v2.0?????? |??????\n http://153.65.235.39:5000/v2.0?????? |????? http://153.65.235.39:35357/v2.0?????? | c5196b9c3d5446bdb63ee3b8f40d67f7 |\n| 8e0ecafcf86e42c28f6431e9cd6b330b |? myregion | http://153.65.235.39:8774/v2/$(tenant_id)s | http://153.65.235.39:8774/v2/$(tenant_id)s | http://153.65.235.39:8774/v2/$(tenant_id)s | 4d7a03c577304e3381a3d08ba74a70dc |\n| aaa01a27723d4d4abfe65496d03e811e |? myregion | http://153.65.235.39:8776/v1/$(tenant_id)s | http://153.65.235.39:8776/v1/$(tenant_id)s | http://153.65.235.39:8776/v1/$(tenant_id)s | aed8babcd157477b827c7a2ce89a641c |\n| aebb4602fae143ef86d62de0c0bc5ba8 | regionOne |???? http://153.65.235.39/keystone/main????\n |??????????????????????????????????????????? |??? http://153.65.235.39/keystone/admin???? | c5196b9c3d5446bdb63ee3b8f40d67f7 |\n| c5169966464140c69fe8c244659ad932 |? myregion |???????? http://153.65.235.39:9696/???????? |???????? http://153.65.235.39:9696/???????? |???????? http://153.65.235.39:9696/???????? | a7a32598413a435687e9919c6add1647 |\n| d5b7a1f9f7bf417295f7b1e9e34f0a26 |? myregion |???????\n http://153.65.235.39:8000/v1??????? |??????? http://153.65.235.39:8000/v1??????? |??????? http://153.65.235.39:8000/v1??????? | 43f4318c522646c2bdd44d6e9e09edfe |\n| ecc1cd7cbad8461281181a879286c2bf |? myregion |??????? http://153.65.235.39:9292/v2??????? |??????? http://153.65.235.39:9292/v2??????? |??????? http://153.65.235.39:9292/v2??????? | 6bd3e90b00a743cfa4a94050f87319aa |\n| fe815ceefd0544f2abd16c484cab1b27 |? myregion |???????? http://153.65.235.39:8777?????????\n |???????? http://153.65.235.39:8777????????? |???????? http://153.65.235.39:8777????????? | 4aa31f280a1e40888d45119c02149a01 |\n+----------------------------------+-----------+--------------------------------------------+--------------------------------------------+--------------------------------------------+----------------------------------+\n\n\nkeystone service-list\n?keystone service-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\n+----------------------------------+------------+----------------+----------------------------------+\n|??????????????? id??????????????? |??? name??? |????? type????? |?????????? description???????????\n |\n+----------------------------------+------------+----------------+----------------------------------+\n| 4aa31f280a1e40888d45119c02149a01 | ceilometer |??? metering??? |??? openstack metering service??? |\n| aed8babcd157477b827c7a2ce89a641c |?? cinder?? |???? volume???? |???? openstack volume service???? |\n| 5bc96b5587aa4f12919f3a155b5713b0 |??? ec2???? |????? ec2?????? |?????????? ec2 service??????????? |\n| 6bd3e90b00a743cfa4a94050f87319aa |?? glance?? |???? image????? |???? openstack image\n service????? |\n| 3308b160d21f4dac84b866063852a47a |??? heat??? | orchestration? | openstack orchestration service? |\n| 43f4318c522646c2bdd44d6e9e09edfe |? heat-cfn? | cloudformation | openstack cloudformation service |\n| c5196b9c3d5446bdb63ee3b8f40d67f7 |? keystone? |??? identity??? |??? openstack identity service??? |\n| a7a32598413a435687e9919c6add1647 |? neutron?? |??? network???? |?? openstack networking service?? |\n| 4d7a03c577304e3381a3d08ba74a70dc |??? nova??? |??? compute???? |??? openstack compute service????\n |\n+----------------------------------+------------+----------------+----------------------------------+\n\n\nSo this means that normal configuration works ok.\nNow I will try to configure http authentication and the steps that I am using are the following:\n1) service keystone stop\n2) create the file /etc/apache2/conf.d/wsgi-keystone.conf with the following content:\nListen 5000\n<VirtualHost *:5000>\nWSGIScriptAlias /keystone/main /var/www/cgi-bin/keystone/main\n</VirtualHost>\nListen 35357\n<VirtualHost\n *:35357>\nWSGIScriptAlias /keystone/admin /var/www/cgi-bin/keystone/admin\n</VirtualHost>\n\n\n3) Both /var/www/cgi-bin/keystone/main and /var/www/cgi-bin/keystone/admin have the following content:\n# Copyright 2013 OpenStack Foundation\n#\n#??? Licensed under the Apache License, Version 2.0 (the \"License\"); you may\n#??? not\n use this file except in compliance with the License. You may obtain\n#??? a copy of the License at\n#\n#???????? http://www.apache.org/licenses/LICENSE-2.0\n#\n#??? Unless required by applicable law or agreed to in writing, software\n#??? distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT\n#??? WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the\n#??? License for the specific language governing permissions and limitations\n#??? under the License.\n\nimport logging\nimport os\n\nfrom paste import deploy\n\nfrom keystone.openstack.common import gettextutils\n\n# NOTE(blk-u):\n# gettextutils.install() must run to set _ before importing any modules that\n# contain static translated strings.\ngettextutils.install(\'keystone\',\n lazy=True)\n\nfrom keystone.common import dependency\nfrom keystone.common import environment\nfrom keystone.common import sql\nfrom keystone import config\nfrom keystone.openstack.common import log\nfrom keystone import service\n\n\nCONF = config.CONF\n\nconfig.configure()\nsql.initialize()\nconfig.set_default_for_default_log_levels()\n\nCONF(project=\'keystone\')\nconfig.setup_logging()\n\nenvironment.use_stdlib()\nname = os.path.basename(__file__)\n\n\nif CONF.debug:\n???\n CONF.log_opt_values(log.getLogger(CONF.prog), logging.DEBUG)\n\n\ndrivers = service.load_backends()\n\n# NOTE(ldbragst): \'application\' is required in this context by WSGI spec.\n# The following is a reference to Python Paste Deploy documentation\n# http://pythonpaste.org/deploy/\napplication = deploy.loadapp(\'config:%s\' % config.find_paste_config(),\n????????????????????????????\n name=name)\n\ndependency.resolve_future_dependencies()\n?????????????????????????????????????????????????????????????? \n\n4) service apache2 restart\nroot at ubuntu1204:~# netstat -ntlp|grep 5000\ntcp???????\n 0????? 0 0.0.0.0:5000??????????? 0.0.0.0:*?????????????? LISTEN????? 23078/apache2\nroot at ubuntu1204:~# netstat -ntlp|grep 35357\ntcp??????? 0????? 0 0.0.0.0:35357?????????? 0.0.0.0:*?????????????? LISTEN????? 23078/apache2\n\n\n5) source openstackrchttp with the following content:\nexport OS_TENANT_NAME=admin\nexport OS_USERNAME=admin\nexport OS_PASSWORD=admin\nexport SERVICE_TOKEN=ADMIN\nexport OS_AUTH_URL=\"http://10.65.235.39:5000/keystone/main\"\nexport SERVICE_ENDPOINT=\"http://10.65.235.39:35357/keystone/admin\"\n\n\n6) keystone user-list\nWARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).\nUnable to communicate with identity service: <!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>500 Internal Server Error</title>\n</head><body>\n<h1>Internal Server Error</h1>\n<p>The server encountered an internal error or\nmisconfiguration and was unable to complete\nyour request.</p>\n<p>Please contact the server administrator,\n?[no address given] and inform them of the time the error occurred,\nand anything you might have done that may have\ncaused the error.</p>\n<p>More information about this error\n may be available\nin the server error log.</p>\n<hr>\n<address>Apache/2.2.22 (Ubuntu) Server at 10.65.235.39 Port 35357</address>\n</body></html>\n. (HTTP 500)\n\n\n\nWhat is lacking? What else should be done? If we will find a solution we can write a very clear document with steps to configure keystone with http authentication on ubuntu with openstack havana.\n\n\nThanks a lot,\nGabriel\n\n\n\n\n\n\n\n\n\n\nOn Wednesday, February 19, 2014 6:54 PM, Dave Walker <email at daviey.com> wrote:\n \nHi Staicu,\n\nWhich release of Openstack are you using?\n? - The distro shouldn\'t really matter in this instance.\nWhat Auth method are you attempting to do through Apache?\n?  - Simple Auth, Kerberos?\nWhat are you using in\n your dispatcher file (wsgi / fcgi plumbing)?\nWhat behaviour are you seeing?\n? - Is REMOTE_USER environ being set?\n\n\nOn 19 February 2014 16:51, Staicu Gabriel <gabriel_staicu at yahoo.com> wrote:\n> Hi,\n>\n> Is there someone who did the keystone to delegate authentication to apache\n> on ubuntu/havana.\n> I have read these documents but nothing is clear:\n> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/Configuring_the_Identity_Service_to_Run_in_HTTPD.html\n> https://wiki.openstack.org/wiki/Talk:Keystone_in_HTTPD_on_RHEL6\n> http://docs.openstack.org/developer/keystone/apache-httpd.html\n>\n> It seams like everyone is telling half of the truth....:)\n>\n> Is there any other place where I could understand how you could do it on\n> ubuntu?\n>\n> Thanks a lot,\n> Gabriel\n>\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to? ?  : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140228/92d2560b/attachment.html>\n\n','<1392889102.63839.YahooMailNeo@web122601.mail.ne1.yahoo.com>',NULL),('<1393582657.30506.YahooMailNeo@web122605.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-28 02:17:37',-28800,'2014-02-28 10:17:37',NULL,'[Openstack] openstack havana cinder chooses wrong host to\n	create new volume','\nHi John,\n\nI found a solution to the problem that I asked you help for and I consider that you do not need to look anymore at it.\nI will also comment to the bug that I logged (https://bugs.launchpad.net/cinder/+bug/1280367) but I think I could not close it myself.\n\nThe solution for HA cinder is the parameter <host> in /etc/cinder/cinder.conf on the machines that are running cinder-volume service.\n\nIf you set this parameter to the same string on all the hosts that are running cinder-volume service than all the hosts will be parent to any volume in the ceph cluster, so any host can create a volume from an already existing volume.\n\nProblem fixed....:) I will log a documentation bug to both ceph and openstack because of this parameter depends HA for cinder.\n\n\nThanks a lot,\nGabriel\n\n\n\n\n\nOn Wednesday, February 12, 2014 7:07 PM, John Griffith <john.griffith at solidfire.com> wrote:\n \nOn Wed, Feb 12, 2014 at 10:57 AM, Staicu Gabriel\n<gabriel_staicu at yahoo.com> wrote:\n> Thanks for the answer John.\n> This is really tricky and I will try to explain why:\n> You were right. The snap volume itself was created from a volume on opstck01\n> when it was up.\n> This is the offending snap. Here is the proof:\n> root at opstck10:~# cinder snapshot-show 30093123-0da2-4864-b8e6-87e023e842a4\n> +--------------------------------------------+--------------------------------------+\n> |? ? ? ? ? ? ? ? ? Property? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? Value\n> |\n> +--------------------------------------------+--------------------------------------+\n> |? ? ? ? ? ? ? ?  created_at? ? ? ? ? ? ? ?  |\n> 2014-02-12T13:20:41.000000? ? ? |\n> |? ? ? ? ? ? display_description? ? ? ? ? ?  |\n> |\n> |? ? ? ? ? ? ? ? display_name? ? ? ? ? ? ? ? |? ? ? ? ? cirros-0.3.1-snap\n> |\n> |? ? ? ? ? ? ? ? ? ?  id? ? ? ? ? ? ? ? ? ?  |\n> 30093123-0da2-4864-b8e6-87e023e842a4 |\n> |? ? ? ? ? ? ? ? ? metadata? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? {}\n> |\n> |? os-extended-snapshot-attributes:progress? |? ? ? ? ? ? ? ?  100%\n> |\n> | os-extended-snapshot-attributes:project_id |\n> 8c25ff44225f4e78ab3f526d99c1b7e1?  |\n> |? ? ? ? ? ? ? ? ? ? size? ? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? 1\n> |\n> |? ? ? ? ? ? ? ? ?  status? ? ? ? ? ? ? ? ?  |? ? ? ? ? ? ? available\n> |\n> |? ? ? ? ? ? ? ?  volume_id? ? ? ? ? ? ? ? ? |\n> 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9 |\n> +--------------------------------------------+--------------------------------------+\n>\n> root at opstck10:~# cinder show 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9\n> +--------------------------------+--------------------------------------+\n> |? ? ? ? ? ? Property? ? ? ? ? ? |? ? ? ? ? ? ? ? Value? ? ? ? ? ? ? ?  |\n> +--------------------------------+--------------------------------------+\n> |? ? ? ? ? attachments? ? ? ? ?  |? ? ? ? ? ? ? ? ? []? ? ? ? ? ? ? ? ? |\n> |? ? ?  availability_zone? ? ? ? |? ? ? ? ? ? ? ?  nova? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? ? bootable? ? ? ? ? ? |? ? ? ? ? ? ? ? false? ? ? ? ? ? ? ?  |\n> |? ? ? ? ?  created_at? ? ? ? ?  |? ? ? 2014-02-11T15:33:58.000000? ? ? |\n> |? ? ? display_description? ? ?  |? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |\n> |? ? ? ? ? display_name? ? ? ? ? |? ? ? ? ? ?  cirros-0.3.1? ? ? ? ? ?  |\n> |? ? ? ? ? ? ?  id? ? ? ? ? ? ?  | 2f5be8c9-941e-49cb-8eb8-f6def3ca8af9 |\n> |? ? ? ? ? ? metadata? ? ? ? ? ? |? ? ?  {u\'readonly\': u\'False\'}? ? ? ? |\n> |? ?  os-vol-host-attr:host? ? ? |? ? ? ? ? ? ?  opstck01? ? ? ? ? ? ?  |\n> | os-vol-mig-status-attr:migstat |? ? ? ? ? ? ? ?  None? ? ? ? ? ? ? ?  |\n> | os-vol-mig-status-attr:name_id |? ? ? ? ? ? ? ?  None? ? ? ? ? ? ? ?  |\n> |? os-vol-tenant-attr:tenant_id? |?  8c25ff44225f4e78ab3f526d99c1b7e1?  |\n> |? ? ? ? ? ? ? size? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? 1? ? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? snapshot_id? ? ? ? ?  |? ? ? ? ? ? ? ?  None? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? source_volid? ? ? ? ? |? ? ? ? ? ? ? ?  None? ? ? ? ? ? ? ?  |\n> |? ? ? ? ? ?  status? ? ? ? ? ?  |? ? ? ? ? ? ? available? ? ? ? ? ? ?  |\n> |? ? ? ? ? volume_type? ? ? ? ?  |? ? ? ? ? ? ? ?  None? ? ? ? ? ? ? ?  |\n> +--------------------------------+--------------------------------------+\n>\n> And now follows the interesting part. I am using ceph as a backend for\n> cinder and I have multiple cinder-volume agents for HA reasons. The volumes\n> themselves are available. The agents can fall.? How can I overcome the\n> limitation to create a volume on the same agent as the snap itself was\n> created?\n>\n> Thanks a lot,\n> Gabriel\n>\n>\n>\n> On Wednesday, February 12, 2014 6:20 PM, John Griffith\n> <john.griffith at solidfire.com> wrote:\n> On Wed, Feb 12, 2014 at 3:24 AM, Staicu Gabriel\n> <gabriel_staicu at yahoo.com> wrote:\n>>\n>>\n>> Hi,\n>>\n>> I have a setup with Openstack Havana on ubuntu precise with multiple\n>> schedulers and volumes.\n>> root at opstck10:~# cinder service-list\n>>\n>> +------------------+----------+------+---------+-------+----------------------------+\n>> |? ? ? Binary? ? ? |? Host? | Zone |? Status | State |? ? ? ? Updated_at\n>> |\n>>\n>> +------------------+----------+------+---------+-------+----------------------------+\n>> | cinder-scheduler | opstck08 | nova | enabled |? up? |\n>> 2014-02-12T10:08:28.000000 |\n>> | cinder-scheduler | opstck09 | nova | enabled |? up? |\n>> 2014-02-12T10:08:29.000000 |\n>> | cinder-scheduler | opstck10 | nova | enabled |? up? |\n>> 2014-02-12T10:08:28.000000 |\n>> |? cinder-volume? | opstck01 | nova | enabled |? down |\n>> 2014-02-12T09:39:09.000000 |\n>> |? cinder-volume? | opstck04 | nova | enabled |? down |\n>> 2014-02-12T09:39:09.000000 |\n>> |? cinder-volume? | opstck05 | nova | enabled |? down |\n>> 2014-02-12T09:39:09.000000 |\n>> |? cinder-volume? | opstck08 | nova | enabled |? up? |\n>> 2014-02-12T10:08:28.000000 |\n>> |? cinder-volume? | opstck09 | nova | enabled |? up? |\n>> 2014-02-12T10:08:28.000000 |\n>> |? cinder-volume? | opstck10 | nova | enabled |? up? |\n>> 2014-02-12T10:08:28.000000 |\n>>\n>> +------------------+----------+------+---------+-------+----------------------------+\n>>\n>> When I am trying to create a new instance from a volume snapshot it keeps\n>> choosing for the creation of the volume opstck01 on which cinder-volume is\n>> down.\n>> Did anyone encounter the same problem?\n>> Thanks\n>>\n>>\n>>\n>> _______________________________________________\n>> Mailing list:\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ? : openstack at lists.openstack.org\n>> Unsubscribe :\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>\n> Which node is the parent volume and snapshot on?? In the case of\n> create from source-volume and create from snapshot these need to be\n> created on the same node as the source or snapshot.? There\'s currently\n> a bug ([1]), where we don\'t check/enforce the type settings to make\n> sure these match up.? That\'s in progress right now and will be\n> backported.\n>\n> [1]: https://bugs.launchpad.net/cinder/+bug/1276787\n>\n>\n> Thanks,\n>\n> John\n>\n>\n>\nGlad we answered the question... sad that you\'ve hit another little\nproblem (bug) in how we do things here.\n\nSince you\'re HA we should be able to discern that the volume is\navailable via multiple hosts.? I\'ll have to look at that more closely,\nI believe this is might be a known issue.? We need to open a bug on\nthis and try and get it sorted out.\n\nWould you be willing/able to provide some details on how you did your\nHA config?? Maybe log a bug in launchpad with the details and I can\ntry to look at fixing things up here shortly?\n\n\nThanks,\nJohn\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140228/2e2e4cf2/attachment.html>\n\n','<CA+qL3LWTRAhxMvVM6C1YFVy=DhYYE5VJAERL1pkYOwiLroLNyg@mail.gmail.com>',NULL),('<1393584275.73682.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-28 18:44:35',28800,'2014-02-28 10:44:35',NULL,'[Openstack] problem in installing django-swiftbrowser',' \nhi Lysander\nThanks for the help.\n\nbrowser is showing login screen\n\nBut when I login with account:username and click login, It shows blank screen (screenshots attached)\n\n\nroot at pragya-VirtualBox:~/django-swiftbrowser/myproj#\npython manage.py runserver \n\n\nValidating models...\n\n0 errors found\nFebruary 28, 2014 - 11:21:24\nDjango version 1.6.2, using settings \'myproj.settings\'\nStarting development server at http://127.0.0.1:8000/\nQuit the server with CONTROL-C.\n[28/Feb/2014 11:36:58] \"POST /login/ HTTP/1.1\" 500 0\n\n\nWhy is it so?\nAnd, what should I do now?\n\nPlease help.\n\nPragya jain\n\n\n\n\nOn Thursday, 27 February 2014 2:26 AM, Lysander David <Lysander_David at symantec.com> wrote:\n \nPlease type these commands:\n>\n>\n>pip install django>=1.5\n>pip install python-swiftclient\n>python ./setup.py install\n>\n>\n>Thanks,\n>Lysander\n>\n>\n>\n>\n>\n>\n>From:  pragya jain <prag_2648 at yahoo.co.in>\n>Reply-To:  pragya jain <prag_2648 at yahoo.co.in>\n>Date:  Tuesday, February 25, 2014 12:14 AM\n>To:  Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>Subject:  Re: [Openstack] problem in installing django-swiftbrowser\n>\n>\n>\n>Hi Lysander,\n>\n>\n>When I run?sudo python setup.py install under?django-swiftbrowser:\n>root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>\n>I get the following error:\n>http://paste.openstack.org/show/68941/\n>\n>\n>Pragya Jain\n>\n>\n>\n>On Tuesday, 25 February 2014 11:55 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>\n>This line indicates you ran?\n>>\n>>\n>>Python runtests.py?\n>>\n>>\n>>Under Django-1.6.2\n>>\n>>\n>>5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>>\n>>\n>>This link indicates you should run that command ?here:\n>>\n>>\n>>django-swiftbrowser\n>>Why do you believe you should run that command underDjango-1.6.2\n>>\n>>\n>>?\n>>\n>>\n>>Thanks,\n>>Lysander\n>>\n>>\n>>\n>>\n>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>Date: Monday, February 24, 2014 8:02 PM\n>>To: Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>\n>>\n>>\n>>my only aim is to find a GUI for operating swift functionalities\n>>\n>>\n>>For this purpose, I want to install and run django swiftbrowser\n>>\n>>\n>>I am following the steps mentioned ?at its github link?https://github.com/cschwede/django-swiftbrowser\n>>\n>>\n>>Thanks\n>>\n>>\n>>Pragya jain\n>>\n>>\n>>\n>>On Tuesday, 25 February 2014 1:25 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>>\n>>Why do you believe you have to run\n>>>\n>>>\n>>>python runtests.py\n>>>\n>>>\n>>>?\n>>>\n>>>\n>>>Thanks,\n>>>Lysander\n>>>\n>>>\n>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>Date: Sunday, February 23, 2014 9:49 PM\n>>>To: Lysander David <Lysander_David at symantec.com>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>\n>>>\n>>>\n>>>hi Lysander David,\n>>>\n>>>\n>>>thanks for the reply.\n>>>\n>>>\n>>>I follow following steps:\n>>>\n>>>\n>>>1. \n>>>root at pragya-VirtualBox:~# wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz \n>>>\n>>>\n>>>\n>>>2. \n>>>root at pragya-VirtualBox:~# tar zxvf Django-1.6.2.tar.gz\n>>>3. \n>>>root at pragya-VirtualBox:~# cd Django-1.6.2\n>>>\n>>>\n>>>4. \n>>>root at pragya-VirtualBox:~/Django-1.6.2# sudo python ./setup.py install\n>>>5. root at pragya-VirtualBox:~/Django-1.6.2# python runtests.py\n>>>\n>>>and get the following error:\n>>>\n>>>\n>>>ERROR 1:\n>>>python: can\'t open file \'runtests.py\': [Errno 2] No such file or directory\n>>>\n>>>\n>>>\n>>>\n>>>On Wednesday, 19 February 2014 12:06 PM, Lysander David <Lysander_David at symantec.com> wrote:\n>>>\n>>>Please install django.\n>>>>\n>>>>\n>>>>wget https://pypi.python.org/packages/source/D/Django/Django-1.6.2.tar.gz#md5=45d974c623b3bfbf9976f3d808fe1ee9 -O Django-1.6.2.tar.gz\n>>>>tar zxvf Django-1.6.2.tar.gz\n>>>>cd Django-1.6.2\n>>>>sudo python ./setup.py install\n>>>>\n>>>>\n>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>Date: Tuesday, February 18, 2014 9:48 PM\n>>>>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>, Lysander David <Lysander_David at symantec.com>\n>>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>>\n>>>>\n>>>>\n>>>>thanks Lysander David for the reply. \n>>>>\n>>>>I again have some problem.\n>>>>\n>>>>I follow the following steps:\n>>>>1.? root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>>\n>>>>\n>>>>\n>>>>2.? root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>>\n>>>>3. \n>>>>root at pragya-VirtualBox:~/django-swiftbrowser# wget --no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O setuptools-2.2.tar.gz \n>>>>\n>>>>4.? \n>>>>root at pragya-VirtualBox:~/django-swiftbrowser# tar zxvf setuptools-2.2.tar.gz \n>>>>5. \n>>>>root at pragya-VirtualBox:~/django-swiftbrowser# cd setuptools-2.2\n>>>>\n>>>>\n>>>>6.? \n>>>>root at pragya-VirtualBox:~/django-swiftbrowser/setuptools-2.2# sudo python ./setup.py install \n>>>>7.? \n>>>>root at pragya-VirtualBox:~/django-swiftbrowser# python runtests.py \n>>>>\n>>>>\n>>>>and I got the following error :\n>>>>\n>>>>\n>>>>Traceback (most recent call last): \n>>>>File \"runtests.py\", line 2, in <module> \n>>>>from django.conf import settings \n>>>>ImportError: No module named django.conf \n>>>>\n>>>>\nPlease help to resolve it.\n>>>>\n>>>>Thanks again \n>>>>\n>>>>pragya Jain\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>On , pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>\n>>>>>\n>>>>>\n>>>>>On Monday, 17 February 2014 11:39 AM, Lysander David <Lysander_David at symantec.com> wrote:\n>>>>>\n>>>>>Please consider installing the setuptools module.\n>>>>>>\n>>>>>>\n>>>>>>The latest archive can be found here:\n>>>>>>\n>>>>>>\n>>>>>>https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6\n>>>>>>\n>>>>>>\n>>>>>>You can install it with these commands:\n>>>>>>\n>>>>>>\n>>>>>>wget --no-check-certificate?https://pypi.python.org/packages/source/s/setuptools/setuptools-2.2.tar.gz#md5=04a7664538957b832710653fd7d5b4e6 -O?setuptools-2.2.tar.gz\n>>>>>>tar zxvf?setuptools-2.2.tar.gz\n>>>>>>cd?setuptools-2.2\n>>>>>>sudo python ./setup.py install\n>>>>>>\n>>>>>>\n>>>>>>From: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>Reply-To: pragya jain <prag_2648 at yahoo.co.in>\n>>>>>>Date: Sunday, February 16, 2014 9:55 PM\n>>>>>>To: pragya jain <prag_2648 at yahoo.co.in>, \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\n>>>>>>Subject: Re: [Openstack] problem in installing django-swiftbrowser\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>please someody reply\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Friday, 14 February 2014 2:20 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>hello all,\n>>>>>>>\n>>>>>>>\n>>>>>>>I am installing django-swiftbrowser on a ubuntu desktop VM onmy system using the link https://github.com/cschwede/django-swiftbrowser\n>>>>>>>\n>>>>>>>\n>>>>>>>below are the steps which i follow:\n>>>>>>>-----------------\n>>>>>>>1. root at pragya-VirtualBox:~# git clone git://github.com/cschwede/django-swiftbrowser.git\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>Cloning into \'django-swiftbrowser\'...\n>>>>>>>remote: Reusing existing pack: 145, done.\n>>>>>>>remote: Total 145 (delta 0), reused 0 (delta 0)\n>>>>>>>Receiving objects: 100% (145/145), 261.34 KiB | 89 KiB/s, done.\n>>>>>>>Resolving deltas: 100% (72/72), done.\n>>>>>>>\n>>>>>>>\n>>>>>>>2. root at pragya-VirtualBox:~# cd django-swiftbrowser\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>3. root at pragya-VirtualBox:~/django-swiftbrowser# sudo python setup.py install\n>>>>>>>Traceback (most recent call last):\n>>>>>>>? File \"setup.py\", line 2, in <module>\n>>>>>>>??? from setuptools import setup\n>>>>>>>ImportError: No module named setuptools\n>>>>>>>------------\n>>>>>>>\n>>>>>>>\n>>>>>>>But I get the error.\n>>>>>>>Please help inresolving the error.\n>>>>>>>\n>>>>>>>\n>>>>>>>Thanks in advance \n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>_______________________________________________\n>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>Post to? ? : openstack at lists.openstack.org\n>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>\n>>>\n>>>6.?root at pragya-VirtualBox:~/Django-1.6.2# django-admin.py startproject myproj\n>>>\n>>>\n>>>7. root at pragya-VirtualBox:~/Django-1.6.2# cd myproj\n>>>\n>>>8. root at pragya-VirtualBox:~/Django-1.6.2/myproj# cp ~/django-swiftbrowser/example/settings.py myproj/settings.py\n>>>\n>>>9. root at pragya-VirtualBox:~/Django-1.6.2/myproj# pico myproj/urls.py\n>>>-------\n>>>from django.conf.urls import patterns, include, url\n>>>\n>>>from django.contrib import admin\n>>>admin.autodiscover()\n>>>\n>>>#urlpatterns = patterns(\'\',\n>>>??? # Examples:\n>>>??? # url(r\'^$\', \'myproj.views.home\', name=\'home\'),\n>>>??? # url(r\'^blog/\', include(\'blog.urls\')),\n>>>\n>>>?#?? url(r\'^admin/\', include(admin.site.urls)),\n>>>#)\n>>>import swiftbrowser.urls\n>>>\n>>>urlpatterns = patterns(\'\',\n>>>??? url(r\'^\', include(swiftbrowser.urls)),\n>>>)\n>>>--------------\n>>>\n>>>10. root at pragya-VirtualBox:~/Django-1.6.2/myproj# python manage.py collectstatic\n>>>\n>>>ERROR 2:\n>>>\n>>>Traceback (most recent call last):\n>>>? File \"manage.py\", line 10, in <module>\n>>>??? execute_from_command_line(sys.argv)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 399, in execute_from_command_line\n>>>??? utility.execute()\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py\", line 392, in execute\n>>>??? self.fetch_command(subcommand).run_from_argv(self.argv)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 242, in run_from_argv\n>>>??? self.execute(*args, **options.__dict__)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/core/management/base.py\", line 280, in execute\n>>>??? translation.activate(\'en-us\')\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/__init__.py\", line 130, in activate\n>>>??? return _trans.activate(language)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 188, in activate\n>>>??? _active.value = translation(language)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 177, in translation\n>>>??? default_translation = _fetch(settings.LANGUAGE_CODE)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/translation/trans_real.py\", line 159, in _fetch\n>>>??? app = import_module(appname)\n>>>? File \"/usr/local/lib/python2.7/dist-packages/django/utils/importlib.py\", line 40, in import_module\n>>>??? __import__(name)\n>>>ImportError: No module named swiftbrowser\n>>>\n>>>----------\n>>>\n>>>I am using the link https://github.com/cschwede/django-swiftbrowser\n>>>\n>>>please help me to resolve these two errors.\n>>>\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140228/7cd433ec/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot login.png\nType: image/png\nSize: 114084 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140228/7cd433ec/attachment-0002.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot afterLogin.png\nType: image/png\nSize: 100674 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140228/7cd433ec/attachment-0003.png>\n\n','<CF338FF5.27545%Lysander_David@symantec.com>',NULL),('<1393596991.4301.5.camel@mdickson-hp>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 14:16:33',0,'2014-02-28 14:16:33',NULL,'[openstack-dev] [nova][baremetal] Deprovision of bare-metal\n nodes','On Fri, 2014-02-28 at 00:04 -0800, Taurus Cheung wrote:\n> Hi,\n> \n>  \n> \n> I am working on deploying images to bare-metal machines using nova\n> bare-metal. After deployment, I would like to deprovision\n> (\"disconnect\") bare-metal nodes from OpenStack controller/compute, so\n> these bare-metal nodes can run standalone.\n> \n>  \n> \n> A typical scenario is that I have a workstation with OpenStack\n> controller and nova baremetal compute installed. During bare-metal\n> deployment, I plug the workstation into the network. After deployment,\n> I disconnect it from the network.\n> \n>  \n> \n> Is this use-case typical, possible and without side-effect?\n\nI\'ll be curious to see what other responses you get as I am fairly new\nto OpenStack and I find the current behaviour bugged.\n\nMy understanding when using the default pxe driver for deployment is\nthat it will always pxe boot.  The MBR and boot files aren\'t installed.\nSo once provisioning is complete the node must remain on the network for\nit to continue to boot.  As I understand it this behaviour is also the\ndefault in Ironic.\n\nI\'d love to understand why that is considered required behavior as I am\nfairly certain a number of enterprise users will not find that\nacceptable behavior.  Ideally the image should get customized with the\nboot files and an MBR written on install.  When there is no provisioning\nwork to do the default behaviour IMO should be to fall through to local\nbooting.  If that were the case your use case would work.\n\nEven better if the platform supports a one time boot option it could be\nset to use that when provisioning steps are run.\n\nIn any event thats my understanding. I\'d love someone else to correct or\nconfirm it.  And help me understand why thats the default.\n\nMike\n\n>  \n> \n> Regards,\n> \n> Taurus\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CBE5C364B282C543BD4030BDFFC1CB420186B67F7501@EXCH-CMS.hlit.local>',NULL),('<1393600194-sup-1684@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 07:14:22',-28800,'2014-02-28 15:14:22',NULL,'[openstack-dev] [Heat]Heat use as a standalone component for\n	Cloud Managment over multi IAAS','Excerpts from Alexander Tivelkov\'s message of 2014-02-28 03:52:52 -0800:\n> Hi Charles,\n> \n> If you are looking for the analogues of Juju in OpenStack, you probably may\n> take a look at Murano Project [1]. It is an application catalog backed with\n> a powerful workflow execution engine, which is built on top of Heat\'s\n> orchestration, but run\'s at a higher level. It has borrowed lots of idea\n> from Juju (or, more precisely, both took a lot from Amazon\'s OpsWorks\n> ideas).\n> Also, if you are looking to orchestrate on top of non-openstack clouds\n\nFYI, Juju existed long before OpsWorks.\n\nhttp://aws.amazon.com/about-aws/whats-new/2013/02/18/announcing-aws-opsworks/\n\nEven my last commit to Juju (the python version..) happened well before\nOpsWorks existed:\n\nhttp://bazaar.launchpad.net/~juju/juju/trunk/revision/599\n\nAnyway, Heat is intended to be able to manage things at a high level\ntoo, just with more of the guts exposed for tinkering. :)\n\n\n','<CAM6FM9TqpHu06CZk-gcYv76YC0+uDBCS2x5yqK36fOVtLUequQ@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1393604518.2943.11.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 11:21:58',-18000,'2014-02-28 16:21:58',NULL,'[openstack-dev] [nova] Future of the Nova API','On Fri, 2014-02-28 at 11:35 +0000, Day, Phil wrote:\n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 24 February 2014 23:49\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [nova] Future of the Nova API\n> > \n> > \n> > > Similarly with a Xen vs KVM situation I don\'t think its an extension\n> > > related issue. In V2 we have features in *core* which are only\n> > > supported by some virt backends. It perhaps comes down to not being\n> > > willing to say either that we will force all virt backends to support\n> > > all features in the API or they don\'t get in the tree. Or\n> > > alternatively be willing to say no to any feature in the API which can\n> > > not be currently implemented in all virt backends. The former greatly\n> > > increases the barrier to getting a hypervisor included, the latter\n> > > restricts Nova development to the speed of the slowest developing and\n> > > least mature hypervisor supported.\n> > \n> > Actually, the problem is not feature parity. The problem lies where two\n> > drivers implement the same or similar functionality, but the public API for a\n> > user to call the functionality is slightly different depending on which driver is\n> > used by the deployer.\n> > \n> > There\'s nothing wrong at all (IMO) in having feature disparity amongst\n> > drivers.\n> \n> I agree with the rest of your posy Jay,\n\nPhew. Good to know my posy is agreeable :)\n\n>  but I  think there are some feature parity issues - for example having rescue always return a generated admin password when only some (one ?) Hypervisor supports actually setting the password is an issue.\n\nNo disagreement from me there! I don\'t see that as an issue. Having an\noptional attribute in the response result is perfectly fine, as long as\nit is documented. There\'s a difference between that and having to issue\ndifferent API calls entirely to do the same or a similar action\ndepending on what the underlying hypervisor or driver implementation is.\nExamples of the latter include the how Nova supplies user and\nconfiguration data to instances, as well as things like migrate,\nlive-migrate, and evacuate all being different API calls or API\nextensions, when the operation is essentially the same...\n\nBest,\n-jay \n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F006FBCE3A@G6W2490.americas.hpqcorp.net>',NULL),('<1393622340.10697847.1405690934855.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-18 15:42:14',7200,'2014-07-18 13:42:14',NULL,'[openstack-dev] [Heat] Introducing Re-Heat','> \n> \n> Hello All,\n> \n> \n> \n> My name is Mika Ayenson and I have to privilege to intern at Johns Hopkins -\n> Applied Physics Lab. I?m really excited to release the latest proof of\n> concept ?Re-Heat? Re-Heat is a JHUAPL developed tool for OpenStack users to\n> help them quickly rebuild their OpenStack environments via OpenStack?s Heat\n> .\n> \n> \n> \n> Here is a link to the Re-Heat paper:\n> https://drive.google.com/open?id=0BzTq-ZB9F-b9b0ZXdy1PT2t3dk0&authuser=0\n> \n> Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat\n\nHi Mika,\n\nIt looks very similar to the flame project I\'ve been contributing recently: https://github.com/cloudwatt/flame\n\nIt\'s be interesting to see if we can join forces.\n\nCheers,\n\n--\nThomas\n\n\n','<6F3DFF211F253A478DB45ABD9DEAFF0134EDCA1345@aplesrepublic.dom1.jhuapl.edu>',NULL),('<1393626386.9963.3.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 17:26:26',-18000,'2014-02-28 22:26:26',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Fri, 2014-02-28 at 13:10 -0800, Mark Washenberger wrote:\n> \n> On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash\n> <henryn at linux.vnet.ibm.com> wrote:\n>         Hi Mark,\n>         \n>         \n>         So we would not modify any existing IDs, so no migration\n>         required.\n> \n> \n> Okay, I just want to be painfully clear--we\'re not proposing changing\n> any of the current restrictions on the user-id field. We will not:\n>   - require it to be a uuid\n>   - encode it as binary instead of char\n>   - shrink its size below the current 64 characters\n\nThe first would be required for the real solution. The second and third\nare performance improvements.\n\n> Any of those could require a migration for existing IDs depending on\n> how your identity driver functions.\n\nPersonally, I think to fix this issue permanently and properly,\nmigrations for database schemas of Glance and Nova would indeed need to\naccompany a proposed patch that restricts the Keystone external user ID\nto only a UUID value.\n\nI entirely disagree with allowing non-UUID values for the user ID value\nthat is exposed outside of Keystone. All other solutions (including the\nproposals to continue using the user_id fields with non-UUID values) are\njust hacks IMO.\n\nBest,\n-jay\n\n\n\n\n','<CAJyP2C9pPr_95b+Rku-eiFXvO+gtPbJ0gXDO7P9sN_0==XSj3A@mail.gmail.com>',NULL),('<1393632999-sup-9830@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-28 16:28:56',-28800,'2014-03-01 00:28:56',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n	maximum from 64 to 255','Excerpts from Jay Pipes\'s message of 2014-02-28 14:26:26 -0800:\n> On Fri, 2014-02-28 at 13:10 -0800, Mark Washenberger wrote:\n> > \n> > On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash\n> > <henryn at linux.vnet.ibm.com> wrote:\n> >         Hi Mark,\n> >         \n> >         \n> >         So we would not modify any existing IDs, so no migration\n> >         required.\n> > \n> > \n> > Okay, I just want to be painfully clear--we\'re not proposing changing\n> > any of the current restrictions on the user-id field. We will not:\n> >   - require it to be a uuid\n> >   - encode it as binary instead of char\n> >   - shrink its size below the current 64 characters\n> \n> The first would be required for the real solution. The second and third\n> are performance improvements.\n> \n> > Any of those could require a migration for existing IDs depending on\n> > how your identity driver functions.\n> \n> Personally, I think to fix this issue permanently and properly,\n> migrations for database schemas of Glance and Nova would indeed need to\n> accompany a proposed patch that restricts the Keystone external user ID\n> to only a UUID value.\n> \n> I entirely disagree with allowing non-UUID values for the user ID value\n> that is exposed outside of Keystone. All other solutions (including the\n> proposals to continue using the user_id fields with non-UUID values) are\n> just hacks IMO.\n\n+1. A Keystone record belongs to Keystone, and it should have a Keystone\nID. External records that are linked should be linked separately.\n\nIt may not be obvious to everyone, but MySQL uses B-trees for indexes.\nB-trees cannot have variable-length keys. So varchar(64) means 64-byte\nindex keys. If you aren\'t careful and let that column be stored as utf-8,\nthis actually means *192* byte index keys, because MySQL uses 3-byte\nutf-8 and thus a 64 \"character\" column could have 192 bytes. This does\nnot scale well as you are doing index scans and range lookups, not to\nmention just generally raising memory and I/O pressure on the server.\n\nWhat Jay is suggesting is that we actually be opinionated and store\nKeystone users with 16-byte binary UUID\'s, and only ever use the UUID (in\nthe 32-byte text notation where appropriate) when returning a keystone ID.\n\nThen only the initial authentication step where the user presents\nexternal identification requires access to anything larger, allowing\nall other Keystone operations to perform much better and keeping the\nkeystone database footprint smaller.\n\n\n','<1393626386.9963.3.camel@sleepy>',NULL),('<1393636524.282040698@f228.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-01 05:15:25',14400,'2014-03-01 01:15:25',NULL,'[Openstack] OpenStack Community Weekly Newsletter (Feb 14 – 28)',' Great stories and tricks. Thanks.\n\n--\nlooking for cloud developers: \nhttp://www.nsbeta.info/jobs\n\n\n\nFriday, February 28, 2014 4:44 PM -08:00 from Stefano Maffulli <stefano at openstack.org>:\n>Why\n        you should be reviewing more OpenStack code\n>Icehouse 3 is upon us, and as someone that is on a bunch of\n        core review teams, it means a steady drum beat of everyone\n        asking how do they get core reviewers to review their code. Sean\n        Dague explains quite well why you should be doing code reviews.\n>Trusted\n          Cloud computing with Intel TXT: The challenge\n>In today?s connected environments, attacks on compute\n        infrastructure are ubiquitous. Major players have been\n        compromised by hackers and malware, with damages inflicted both\n        to their reputation and their business. Protecting the\n        infrastructure from external and internal threats is an\n        important part of operating production grade cloud environments. Christian\n          Huebner introduces how OpenStack integrates with TXT.\n>Our\n          Cloud in Havana\n>Upgrading a nearly 50,000 core cloud from Grizzly to Havana can\n        be done with a series of steps, each of which can have short\n        periods of reduced functionality but with constant VM\n        availability.  Tim Bell tells us how CERN upgraded its OpenStack cloud.\n>Status\n          of the OpenStack port to Python 3\n>Python 3 has been around for about 5 years, and we have  excellent\n          reasons to make sure OpenStack runs well on it.\n        Unfortunately, this is not the case. In his article,  Cyril\n          Roelandt explains what works, what doesn?t, and what  you can do to help.\n>OpenStack\n          selected as mentoring organization for Google Summer of Code\n          2014\n>OpenStack has been selected to be a mentoring organization for\n        Google Summer of Code 2014. Thanks to the hard work of many\n        contributors we could  join\n          GSoC for the first time.\n>The road to Juno Summit ? Atlanta 2014\n>*  Redeem your invite code  NOW ! Check\n          your inbox and spam folder if you contributed code before\n          January 25 for your invitation.\n>*  Next batch of invites will be sent regularly after each\n          milestone until feature freeze.\n>*  It?s time to  vote for\n            presentations you wish to see in Atlanta .\n>*  Applying for Visa? Looking for accommodation in Atlanta?\n          Visit  http://openstack.org/summit\n>*  Applications for  Travel\n            Support Program. Apply by Mar 2 .\n>Tips ?n Tricks\n>*  By  Evgeniya\n            Shumakher :  Building\n            test environments with OpenStack\n>*  By  Christian\n            Hoge :  Deployment\n            to Upgrade: Puppet OpenStack Modules Are Your Friends\n>*  By  Victor\n            Stinner :  Use\n            the new asyncio module and Trollius in OpenStack\n>*  By  Guillaume : Running\n            an OpenGL application on a GPU-accelerated Nova Instance\n            (Part 2)\n>*  By  Lars Kellogg-Stedman : Multinode\n            OpenStack with Packstack\n>*  By  Oleg\n            Gelbukh:  Benchmarking\n            OpenStack at megascale: How we tested Mirantis OpenStack at\n            SoftLayer\n>*  By  Adam Young :  Using\n            Certmonger to Generate a selfsign Cert for CMS\n>*  By  Kevin\n            Jackson :  Inside\n            My Home Rackspace Private Cloud, OpenStack Lab, Part 2 and  Part\n            3\n>*  By  Jamie Lennox : Client\n            Session Objects\n>*  By  Jay Pipes :  Setting\n            Up an External OpenStack Testing System ? Part 2\n>*  By  Dimitar\n            Vlassarev : When is RAID Not Enough?\n>Reports from Previous Events\n>*  OpenStack\n            at the Chicago Mercantile Exchange Group: Chicago-land\n            Meetup\n>*  What?s\n            going on in India?\n>Upcoming Events\n>*  OpenStack India Meetup Mar 01, 2014 ?\n          Bangalore, India  Details\n>*  OpenStack India Meetup Mar 01, 2014 ?\n          Chennai, India  Details\n>*  Athens OpenStack User Group meeting Mar\n          05, 2014 ? Athens, Greece  Details\n>*  Eventually OpenStack for M&E Mar 17,\n          2014 ? Santa Monica, CA  Details\n>*  SFBay\n            OpenStack Hackathon #OSSFO Mar 20, 2014 ?  Details\n>*  Open Source Festival Mar 29, 2014 ?\n          University at Albany, NY  Details\n>*  Cloud Connect Summit at Interop Mar 31 ?\n          Apr 01, 2014 ? Las Vegas, Nevada  Details\n>*  World Hosting Days  Apr 01 ? 03, 2014 ?\n          Rust, Germany  Details\n>*  SFBay Meetup ? Beginner track Apr 03,\n          2014 ? Sunnyvale, CA  Details\n>*  SFBay\n            OpenStack Hackathon #OSSFO Apr 03, 2014 ?  Details\n>*  PyCon Apr 09 ? 17, 2014 ? Montreal, Canada  Details\n>*  SFBay\n            OpenStack Hackathon #OSSFO Apr 17, 2014 ? Sunnyvale,CA  Details\n>*  SFBay Meetup ? Beginner track May 01,\n          2014 ? Sunnyvale,CA  Details\n>Security Advisories\n>*  Missing\n            SSL certificate check in Python Swift client (CVE-2013-6396)\n>Popular OpenStack Videos of the Week\n>*  Outreach\n            Program for Women ? May-Aug 2014\n>*  Windows on OpenStack: Best Practices and\n            Pitfalls\n>Other News\n>*  Outreach\n            Program for Women ? May-Aug 2014 \n>*  GCE\n            API ? Available Now on OpenStack StackForge\n>*  OpenStack\n            Havana 2013.2.2 Hyper-V compute installer released!\n>*  python-heatclient\n            0.2.7 released \n>*  python-novaclient\n            2.16.0 released\n>*  A\n            beginners guide to understanding OpenStack\n>*  Open\n            Mic Spotlight: Derek Higgins\n>*  The\n            dilemma of open innovation\n>*  How\n            does Horizon Stack up versus other Cloud Computing UIs?\n>*  OpenStack Project Meeting:  Summary and  full\n            logs\n>Got Answers?\n>Ask OpenStack is the\n        go-to destination for OpenStack users. Interesting questions\n        waiting for answers:\n>*  How\n            do nova-cells really works?\n>*  what\n            filters spoofed traffic?\n>*  Can\n            quantum be run on child cells to create separate L2fabric in\n            each cell?\n>*  RDO:\n            Packstack (fedora) neutron local flat typedrives\n>*  Controlling\n            physical switch ports with Neutron?\n>*  VMware\n            vnc ports using VCDriver\n>*  How\n            to interpret actual and rss memory in diagnostic results?\n>*  Trying\n            to change user credentials using REST API but the response\n            is 404 not found?\n>*  Can?t\n            fetch the device UUID when deploying the baremetal node\n>*  Autoscaling\n            and load balancing with Heat\n>*  DHCP\n            problem: instances cannot obtain a specific IP\n>*  Is\n            it acceptable to adjust policy.json to allow non-root\n            Savanna access to cinder?\n>Latest Activity In Projects\n>Do you want to see at a glance the bugs filed and solved this\n        week? Latest patches submitted for review? Check out the\n        individual project pages on  OpenStack\n          Activity Board ? Insights .\n>*  Telemetry\n            (Ceilometer)\n>*  Block\n            Storage (Cinder)\n>*  Image\n            Service (Glance)\n>*  Orchestration\n            API (Heat)\n>*  Dashboard\n            (Horizon)\n>*  Bare\n            Metal Provisioning (Ironic)\n>*  Identity\n            (Keystone)\n>*  Manuals\n>*  Networking\n            (Neutron)\n>*  Compute\n            (Nova)\n>*  Hadoop\n            Cluster as a Service (Savanna)\n>*  Object\n            Storage (Swift)\n>*  Database\n            As A Service (Trove)\n>The weekly newsletter is a way for the community to learn\n          about all the various activities occurring on a weekly basis.\n          If you would like to add content to a weekly update or have an\n          idea about this newsletter, please leave a comment.\n>_______________________________________________\n>Mailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to     :  openstack at lists.openstack.org\n>Unsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140301/b8bb4a43/attachment.html>\n\n','<53112D62.1040402@openstack.org>',NULL),('<1393707107.15002.6.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-01 15:51:47',-18000,'2014-03-01 20:51:47',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Fri, 2014-02-28 at 15:25 -0800, Mark Washenberger wrote:\n> I believe we have some agreement here. Other openstack services should\n> be able to use a strongly typed identifier for users. I just think if\n> we want to go that route, we probably need to create a new field to\n> act as the proper user uuid, rather than repurposing the existing\n> field. It sounds like many existing LDAP deployments would break if we\n> repurpose the existing field.\n\nHi Mark,\n\nPlease see my earlier response on this thread. I am proposing putting\nexternal identifiers into a mapping table that would correlate a\nKeystone UUID user ID with external identifiers (of variable length). \n\nOnce authentication has occurred (with any auth backend including LDAP),\nKeystone would only communicate to the other OpenStack services the UUID\nuser ID from Keystone. This would indeed require a migration to each\nnon-Keystone service that stores the user IDs as-is from Keystone\ncurrently (such as Glance or Nova).\n\nOnce the migrations are run, then only UUID values would be stored, and\nfurther migrations could be run that would streamline the columns that\nstores these user IDs to a more efficient CHAR(32) or BINARY(16)\ninternal storage format.\n\nHope that clears things up.\n\nBest,\n-jay \n\n\n\n','<CAJyP2C9-TEGPSqxYp_X=L8Vj0F-tHi1EM=mjAg+0-FKkzYsgzA@mail.gmail.com>',NULL),('<1393721952-sup-7356@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-01 17:00:07',-28800,'2014-03-02 01:00:07',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n	maximum from 64 to 255','Excerpts from Robert Collins\'s message of 2014-03-01 14:26:57 -0800:\n> On 1 March 2014 13:28, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > +1. A Keystone record belongs to Keystone, and it should have a Keystone\n> > ID. External records that are linked should be linked separately.\n> >\n> > It may not be obvious to everyone, but MySQL uses B-trees for indexes.\n> > B-trees cannot have variable-length keys.\n> \n> Hmm, B-Trees and B+-Trees both can have variable length keys. I\'ll\n> accept an assertion that MySQL index B-trees cannot - but we should be\n> precise here, because its not a global limitation.\n> \n\nSorry, I misspoke, _InnoDB\'s_ b-tree\'s cannot have variable length keys.\n:-P\n\n\n','<CAJ3HoZ0ZaPtSzt=4nog=XoxyRxhXagJsMF5o0hhEE66ayUh9Qw@mail.gmail.com>',NULL),('<1393783311.48699.YahooMailNeo@web162306.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-02 10:01:51',-28800,'2014-03-02 18:01:51',NULL,'[openstack-dev] openstack java sdk','Which service of openstack do you want to connect to? The java bindings for neutron and its extensions? \n\n\n\n\nOn Friday, February 28, 2014 2:51 AM, rash g <rashg164 at gmail.com> wrote:\n  \nHello,\n? ? ? ? I am working on a project which uses openstack.I want to\nconnect my java code to openstack.For that I was thinking of using\nopenstack-java sdk.But I did not find any jar files for the same to\nimport in my java code.\n? ? ? ? Can anyone tell me where I can get jar files for openstack-java sdk?\n\nThanks,\nRashmi\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140302/05611c80/attachment.html>\n\n','<CAAsbHRwM+72zP2bBid8gELVi3nmktnEPjTdwnohj=BCA-GBePA@mail.gmail.com>',NULL),('<1393826123.19912.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 13:55:23',28800,'2014-03-03 05:55:23',NULL,'[Openstack] problem in configuring Graphite databases','please somebody reply and help me ?to resolve the problem\n\nPragya jain\n\n\n\nOn Friday, 28 February 2014 3:25 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi ketan\n>\n>I follow the following steps:\n>\n>1. root at swift-VirtualBox:~# pip install django-celery\n>\n>2. root at swift-VirtualBox:~# cd /opt/graphite/webapp/graphite/\n>\n>3. root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>\n>but I get the same error:\n>\n>Traceback (most recent call last):\n>? File \"manage.py\", line 2, in <module>\n>??? from django.core.management import execute_manager\n>ImportError: cannot import name execute_manager\n>\n>Please help to resolve\n it.\n>\n>Thanks \n>Pragya Jain\n>\n>\n>\n>\n>\n>\n>On Tuesday, 25 February 2014 4:39 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n> \n>Hi Pragya?\n>>\n>>\n>>Please try?\n>>\n>>\n>>pip install django-celeryand try to run sudo python manage.py syncdb\n>>\n>>\n>>\n>>\n>>On Tue, Feb 25, 2014 at 2:52 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>Thanks Ketan\n>>>\n>>>\n>>>I run the command you mentioned and then run:\n>>>\n>>>\n>>>root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>>>\n>>>\n>>>\n>>>but now it shows a different error:\n>>>\n>>>\n>>>Traceback (most recent call last):\n>>>? File \"manage.py\", line 2, in <module>\n>>>??? from django.core.management import execute_manager\n>>>ImportError: cannot import name execute_manager\n>>>\n>>>\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>>\n>>>On Tuesday, 25 February 2014 2:12 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n>>> \n>>>Hi Pragya?\n>>>>\n>>>>\n>>>>According to doc?https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps\n>>>>\n>>>>You installed django as per doc ( see third step ).?\n>>>>\n>>>>\n>>>>The problem is occurred due to old version of django. \n>>>>\n>>>>\n>>>>\n>>>>\n>>>>You can upgrade django version to latest one by following command.?\n>>>>\n>>>>\n>>>>?sudo apt-get install python-setuptools && ?sudo easy_install --upgrade django?\n>>>>\n>>>>\n>>>>\n>>>>Try it and let me know.?\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>On Tue, Feb 25, 2014 at 1:40 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>hello Ketan,\n>>>>>\n>>>>>\n>>>>>I am not using any django version\n>>>>>\n>>>>>\n>>>>>I had created an ubuntu 12.04 desktop VM and install and configure swift on it using the link?http://docs.openstack.org/developer/swift/development_saio.html\n>>>>>\n>>>>>\n>>>>>And now in order to monitor my swift cluster, I try to install and configure StatsD + Graphite.?\n>>>>>\n>>>>>\n>>>>>But I get the error mentioned earlier.\n>>>>>\n>>>>>\n>>>>>What should I do now?\n>>>>>\n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Tuesday, 25 February 2014 12:59 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n>>>>> \n>>>>>Hi Pragya?\n>>>>>>\n>>>>>>\n>>>>>>What\'s django version you are using ?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Tue, Feb 25, 2014 at 12:28 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>hi all,\n>>>>>>>\n>>>>>>>\n>>>>>>>I want to monitor my existing swift environment on Ubuntu 12.04 desktop VM.\n>>>>>>>\n>>>>>>>for this purpose, I am trying to install and configure statsD + Graphite\n>>>>>>>I am following the steps from the link https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps\n>>>>>>>\n>>>>>>>\n>>>>>>>But I get an error while configuring Graphite database.\n>>>>>>>\n>>>>>>>\n>>>>>>>root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>>>>>>>The Error is:\n>>>>>>>http://paste.openstack.org/show/69293/\n>>>>>>>\n>>>>>>>\n>>>>>>>Please help to resolve this problem\n>>>>>>>\n>>>>>>>\n>>>>>>>Thanks\n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>_______________________________________________\n>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/d0d99c68/attachment.html>\n\n','<1393581338.97419.YahooMailNeo@web193601.mail.sg3.yahoo.com>',NULL),('<1393830358.82807.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 15:05:58',28800,'2014-03-03 07:05:58',NULL,'[Openstack] problem in installing zenoss zenpack for openstack\n	swift to monitor my swift environment','Hello all,\n\nI have a running swift environment on Ubuntu 12.04 desktop VM.\n\nIn order to monitor it, I want to install zenoss zenpack for openstack swift.\nFor this purpose, first I try to install Zenoss core 4.2.4 on the VM\nI follow the following steps as root:\n1. wget --no-check-certificate https://github.com/zenoss/core-autodeploy/tarball/4.2.4 -O auto.tar.gz 2. tar xvf auto.tar.gz 3. cd zenoss-core-autodeploy-*\n4. ./core-autodeploy.sh\n\nbut I get the error:\n\n./core-autodeploy.sh: line 44: rpm: command not found\nUnable to determine version. I can\'t continue\n\nPlease help me to resolve this error.\nMy main purpose is to install and run zenoss zenpack for openstack swift to monitor my swift environment. \n\nPlease help regarding this\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/fb779762/attachment.html>\n\n',NULL,NULL),('<1393836389.44483.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 16:46:29',28800,'2014-03-03 08:46:29',NULL,'[Openstack] problem in configuring Graphite databases','hi ketan,\n\nI am using following commands:\n\n1. root at swift-VirtualBox:~# wget \"https://code.google.com/p/django-tagging/downloads/detail?name=django-tagging-0.3.1.tar.gz\" \n\n\n--2014-03-03 13:49:38--? https://code.google.com/p/django-tagging/downloads/detail?name=django-tagging-0.3.1.tar.gz\nResolving code.google.com (code.google.com)... 173.194.36.78, 173.194.36.72, 173.194.36.64, ...\nConnecting to code.google.com (code.google.com)|173.194.36.78|:443... connected.\nHTTP request sent, awaiting response... 200 OK\nLength: unspecified [text/html]\nSaving to: `detail?name=django-tagging-0.3.1.tar.gz.2\'\n\n??? [ <=>?????????????????????????????????? ] 10,256????? --.-K/s?? in 0.02s?? \n\n2014-03-03 13:49:40 (444 KB/s) - `detail?name=django-tagging-0.3.1.tar.gz.2\' saved [10256]\n\n2. root at swift-VirtualBox:~# tar xvf? django-tagging-0.3.1.tar.gz\n\n\ntar: django-tagging-0.3.1.tar.gz: Cannot open: No such file or directory\ntar: Error is not recoverable: exiting now\n\nBut i think that there is something wrong in the commands that i am using.\n\nCan you please help me.\n\npragya jain\n\n\n\n\nOn Monday, 3 March 2014 12:57 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n \nI would like to suggest you download django-tagging from?https://code.google.com/p/django-tagging/downloads/detail?name=django-tagging-0.3.1.tar.gz.?\n>\n>\n>untar it with tar xvf ?django-tagging-0.3.1.tar.gz\n>\n>\n>enter in the untar folder and install it with following commands\n>\n>./configure\n>make?\n>make install\n>\n>\n>after try that command.?\n>\n>\n>\n>On Mon, Mar 3, 2014 at 11:25 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>please somebody reply and help me ?to resolve the problem\n>>\n>>\n>>Pragya jain\n>>\n>>\n>>\n>>On Friday, 28 February 2014 3:25 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>> \n>>hi ketan\n>>>\n>>>I follow the following steps:\n>>>\n>>>1. root at swift-VirtualBox:~# pip install django-celery\n>>>\n>>>2. root at swift-VirtualBox:~# cd\n /opt/graphite/webapp/graphite/\n>>>\n>>>3. root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>>>\n>>>but I get the same error:\n>>>\n>>>Traceback (most recent call last):\n>>>? File \"manage.py\", line 2, in <module>\n>>>??? from django.core.management import execute_manager\n>>>ImportError: cannot import name execute_manager\n>>>\n>>>Please help to resolve\n it.\n>>>\n>>>Thanks \n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>On Tuesday, 25 February 2014 4:39 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n>>> \n>>>Hi Pragya?\n>>>>\n>>>>\n>>>>Please try?\n>>>>\n>>>>\n>>>>pip install django-celeryand try to run sudo python manage.py syncdb\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>On Tue, Feb 25, 2014 at 2:52 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>Thanks Ketan\n>>>>>\n>>>>>\n>>>>>I run the command you mentioned and then run:\n>>>>>\n>>>>>\n>>>>>root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>>>>>\n>>>>>\n>>>>>\n>>>>>but now it shows a different error:\n>>>>>\n>>>>>\n>>>>>Traceback (most recent call last):\n>>>>>? File \"manage.py\", line 2, in <module>\n>>>>>??? from django.core.management import execute_manager\n>>>>>ImportError: cannot import name execute_manager\n>>>>>\n>>>>>\n>>>>>Pragya Jain\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>On Tuesday, 25 February 2014 2:12 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n>>>>> \n>>>>>Hi Pragya?\n>>>>>>\n>>>>>>\n>>>>>>According to doc?https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps\n>>>>>>\n>>>>>>You installed django as per doc ( see third step ).?\n>>>>>>\n>>>>>>\n>>>>>>The problem is occurred due to old version of django. \n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>You can upgrade django version to latest one by following command.?\n>>>>>>\n>>>>>>\n>>>>>>?sudo apt-get install python-setuptools && ?sudo easy_install --upgrade django?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>Try it and let me know.?\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>On Tue, Feb 25, 2014 at 1:40 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>\n>>>>>>hello Ketan,\n>>>>>>>\n>>>>>>>\n>>>>>>>I am not using any django version\n>>>>>>>\n>>>>>>>\n>>>>>>>I had created an ubuntu 12.04 desktop VM and install and configure swift on it using the link?http://docs.openstack.org/developer/swift/development_saio.html\n>>>>>>>\n>>>>>>>\n>>>>>>>And now in order to monitor my swift cluster, I try to install and configure StatsD + Graphite.?\n>>>>>>>\n>>>>>>>\n>>>>>>>But I get the error mentioned earlier.\n>>>>>>>\n>>>>>>>\n>>>>>>>What should I do now?\n>>>>>>>\n>>>>>>>\n>>>>>>>Pragya Jain\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>On Tuesday, 25 February 2014 12:59 PM, Ketan Patel <kkpatel2025 at gmail.com> wrote:\n>>>>>>> \n>>>>>>>Hi Pragya?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>What\'s django version you are using ?\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>On Tue, Feb 25, 2014 at 12:28 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>>>>>\n>>>>>>>>hi all,\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>I want to monitor my existing swift environment on Ubuntu 12.04 desktop VM.\n>>>>>>>>>\n>>>>>>>>>for this purpose, I am trying to install and configure statsD + Graphite\n>>>>>>>>>I am following the steps from the link https://www.digitalocean.com/community/articles/installing-and-configuring-graphite-and-statsd-on-an-ubuntu-12-04-vps\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>But I get an error while configuring Graphite database.\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>root at swift-VirtualBox:/opt/graphite/webapp/graphite# sudo python manage.py syncdb\n>>>>>>>>>The Error is:\n>>>>>>>>>http://paste.openstack.org/show/69293/\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Please help to resolve this problem\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>>Thanks\n>>>>>>>>>\n>>>>>>>>>Pragya Jain\n>>>>>>>>>\n>>>>>>>>>_______________________________________________\n>>>>>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>>>\n>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>>\n>>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/a5cf72f9/attachment.html>\n\n','<CABJ37ACpQ9PAnT7JHQPeO5ezszsQCimnx0RbAG5J4DCdJNLHNg@mail.gmail.com>',NULL),('<1393837027.92245.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 16:57:07',28800,'2014-03-03 08:57:07',NULL,'[Openstack] problem in log in django swiftbrowser','hello all,\n\nI had installed django swiftbrowser using the link https://github.com/cschwede/django-swiftbrowser\nwhen I login in swifbrowser, I can\'t login and get the following response.\n\nroot at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver\nValidating models...\n\n0 errors found\nMarch 03, 2014 - 09:50:16\nDjango version 1.6.2, using settings \'myproj.settings\'\nStarting development server at http://127.0.0.1:8000/\nQuit the server with CONTROL-C.\n[03/Mar/2014 09:50:57] \"GET / HTTP/1.1\" 302 0\n[03/Mar/2014 09:50:57] \"GET /login/ HTTP/1.1\" 200 3799\n[03/Mar/2014 09:50:58] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 404 11\n[03/Mar/2014 09:50:58] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 404 11\n[03/Mar/2014 09:50:58] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 404 11\n[03/Mar/2014 09:50:58] \"GET /static/jquery.min.js HTTP/1.1\" 404 11\n[03/Mar/2014 09:50:58] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 404 11\n[03/Mar/2014 09:51:36] \"POST /login/ HTTP/1.1\" 500 0\n\nplease help to resolve the problem\n\npragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/2609f121/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot login.png\nType: image/png\nSize: 114084 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/2609f121/attachment.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot afterLogin.png\nType: image/png\nSize: 100674 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/2609f121/attachment-0001.png>\n\n',NULL,NULL),('<1393844582.42410.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 19:03:02',28800,'2014-03-03 11:03:02',NULL,'[Openstack] problem in log in django swiftbrowser','hi Christian,\n\nI did the following steps:\n1. root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py collectstatic\n\n\nOUTPUT:\nYou have requested to collect static files at the destination\nlocation as specified in your settings:\n\n??? /var/www/myproj/static\n\nThis will overwrite existing files!\nAre you sure you want to do this?\n\nType \'yes\' to continue, or \'no\' to cancel: yes\n\n0 static files copied to \'/var/www/myproj/static\', 9 unmodified.\n\n\n2. root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n\n\nOUTPUT:\nValidating models...\n\n0 errors found\nMarch 03, 2014 - 11:58:30\nDjango version 1.6.2, using settings \'myproj.settings\'\nStarting development server at http://127.0.0.1:8000/\nQuit the server with CONTROL-C.\n[03/Mar/2014 11:59:00] \"GET / HTTP/1.1\" 302 0\n[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n[03/Mar/2014 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n\n----\n\nPragya Jain\n\n\n\n\nOn Monday, 3 March 2014 4:00 PM, Christian Schwede <christian.schwede at enovance.com> wrote:\n \nHello Pragya,\n>\n>please collect the static files in step 5 from the Readme:\n>\n>> python manage.py collectstatic\n>\n>If you didn\'t changed ALLOWED_HOSTS and run swiftbrowser with Debug =\n>False (default) you also need to run the development server with the\n>--insecure option (step 6 in the Readme).\n>\n>> python manage.py runserver --insecure\n>\n>Christian\n>\n>\n>\n>Am 03.03.14 09:57, schrieb pragya jain:\n>> hello all,\n>> \n>> I had installed django swiftbrowser using the link\n>> https://github.com/cschwede/django-swiftbrowser\n>> when I login in swifbrowser, I can\'t login and get the following response.\n>> \n>> root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py\n>> runserver\n>> Validating models...\n>> \n>> 0 errors found\n>> March 03, 2014 - 09:50:16\n>> Django version 1.6.2, using settings \'myproj.settings\'\n>> Starting development server at http://127.0.0.1:8000/\n>> Quit the server with CONTROL-C.\n>> [03/Mar/2014 09:50:57] \"GET / HTTP/1.1\" 302 0\n>> [03/Mar/2014 09:50:57] \"GET /login/ HTTP/1.1\" 200 3799\n>> [03/Mar/2014 09:50:58] \"GET /static/bootstrap/css/bootstrap.min.css\n>> HTTP/1.1\" 404 11\n>> [03/Mar/2014 09:50:58] \"GET\n>> /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 404 11\n>> [03/Mar/2014 09:50:58] \"GET /static/bootstrap/js/bootstrap.min.js\n>> HTTP/1.1\" 404 11\n>> [03/Mar/2014 09:50:58] \"GET /static/jquery.min.js HTTP/1.1\" 404 11\n>> [03/Mar/2014 09:50:58] \"GET /static/bootstrap/js/bootstrap.min.js\n>> HTTP/1.1\" 404 11\n>> [03/Mar/2014 09:51:36] \"POST /login/ HTTP/1.1\" 500 0\n>> \n>> please help to resolve the problem\n>> \n>> pragya Jain\n>> \n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ?  : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>\n>\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/4dd10c15/attachment.html>\n\n','<531457E9.4050206@enovance.com>',NULL),('<1393858111.2742.0.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 09:48:31',-18000,'2014-03-03 14:48:31',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:\n> Having done some work with MySQL (specifically around similar data\n> sets) and discussing the changes with some former coworkers (MySQL\n> experts) I am inclined to believe the move from varchar  to binary\n> absolutely would increase performance like this.\n> \n> \n> However, I would like to get some real benchmarks around it and if it\n> really makes a difference we should get a smart \"UUID\" type into the\n> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this\n> conversation. Should be split off from the keystone one at hand - I\n> don\'t want valuable information / discussions to get lost.\n\nNo disagreement on either point. However, this should be done after the\nstandardization to a UUID user_id in Keystone, as a separate performance\nimprovement patch. Agree?\n\nBest,\n-jay\n\n\n\n\n','<CABEb+dRo-NCOQ5O3KTFvo0ce5CAuKNgwhGtEFb=ot3kcTeuMDA@mail.gmail.com>',NULL),('<1393862967.2742.12.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 11:09:27',-18000,'2014-03-03 16:09:27',NULL,'[openstack-dev] [OpenStack-Dev] [Cinder] Open Source and\n community working together','On Sat, 2014-03-01 at 16:30 -0700, John Griffith wrote:\n> Hey,\n> \n> I just wanted to send out a quick note on a topic that came up\n> recently.  Unfortunately the folks that I\'d like to read this most;\n> don\'t participate on the ML typically, but I\'d at least like to raise\n> some community awareness.\n> \n> We all know OpenStack is growing at a rapid pace and has a lot of\n> promise, so much so that there\'s an enormous field of vendors and OS\n> distributions that are focusing a lot of effort and marketing on the\n> project.\n> \n> Something that came up recently in the Cinder project is that one of\n> the backend device vendors wasn\'t happy with a feature that somebody\n> was working on and contributed a patch for.  Instead of providing a\n> meaningful review and suggesting alternatives to the patch they set up\n> meetings with other vendors leaving the active members of the\n> community out and picked things apart in their own format out of the\n> public view.  Nobody from the core Cinder team was involved in these\n> discussions or meetings (at least that I\'ve been made aware of).\n> \n> I don\'t want to go into detail about who, what, where etc at this\n> point.  I instead, I want to point out that in my opinion this is no\n> way to operate in an Open Source community.  Collaboration is one\n> thing, but ambushing other peoples work is entirely unacceptable in my\n> opinion.  OpenStack provides a plethora of ways to participate and\n> voice your opinion, whether it be this mailing list, the IRC channels\n> which are monitored daily and also host a published weekly meeting for\n> most projects.  Of course when in doubt you\'re welcome to send me an\n> email at any time with questions or concerns that you have about a\n> patch.  In any case however the proper way to address concerns about a\n> submitted patch is to provide a review for that patch.\n> \n> Everybody has a voice and the ability to participate, and the most\n> effective way to do that is by thorough, timely and constructive code\n> reviews.\n> \n> I\'d also like to point out that while a number of companies and\n> vendors have fancy taglines like \"The Leaders of OpenStack\", they\'re\n> not.  OpenStack is a community effort, as of right now there is no\n> company that leads or runs OpenStack.  If you have issues or concerns\n> on the development side you need to take those up with the development\n> community, not vendor xyz.\n\n+100\n\nAnd another +1 for use of the word plethora.\n\nI will point out -- not knowing who these actors were -- that sometimes\nit is tough for some folks to adapt to open community methodologies and\nopen discussions. Some people simply don\'t know any other way of\nresolving differences other than to work in private or develop what they\nconsider to be \"consensus\" between favored parties in order to drive\n\"change by bullying\". We must, as a community, both make it clear\n(through posts such as this) that this behavior is antithetical to how\nthe OpenStack community functions, and also provide these individuals\nwith as much assistance as possible in changing their long-practiced\nhabits. Some stick. Some carrot.\n\nBest,\n-jay\n\n\n\n\n','<CA+qL3LVnjw=QONO8seoQkByRsLsx81gXPDeqM9XEZCNzrL8=YA@mail.gmail.com>',NULL),('<1393863406.2742.18.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 11:16:46',-18000,'2014-03-03 16:16:46',NULL,'[openstack-dev] [Third Party CI] Reminder: Workshop/Q&A meeting on\n #openstack-meeting today at 13:00EST/18:00 UTC','Hi all,\n\nJust a friendly reminder we will have a workshop and Q&A meeting on\nFreeonde #openstack-meeting channel today at 18:00 UTC (13:00 EST) for\nfolks interested in setting up or debugging third party CI platforms.\n\nSee you there!\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1393863406.2742.18.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-03 11:16:46',-18000,'2014-03-03 16:16:46',NULL,'[OpenStack-Infra] [Third Party CI] Reminder: Workshop/Q&A meeting\n on #openstack-meeting today at 13:00EST/18:00 UTC','Hi all,\n\nJust a friendly reminder we will have a workshop and Q&A meeting on\nFreeonde #openstack-meeting channel today at 18:00 UTC (13:00 EST) for\nfolks interested in setting up or debugging third party CI platforms.\n\nSee you there!\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1393871956.25067.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-03 10:39:16',-28800,'2014-03-03 18:39:16',NULL,'[openstack-tc] Out for tomorrow\'s meeting','On Mon, 2014-03-03 at 08:47 -0800, Vishvananda Ishaya wrote:\n> Hello fellow tc members,\n> \n> We have an all-day in-person board meeting tomorrow, so I will miss\n> the TC meeting. I suspect the same will be true for monty and markmc\n> but I will let them verify.\n\nWhat we\'ve done before is join the IRC meeting while eating lunch during\nthe board meeting. That\'s what I was figuring on doing tomorrow.\n\nMark.\n\n\n\n','<4FE65CC3-0963-4BC7-9D8A-E54A67D0DFBF@gmail.com>',NULL),('<1393875146.11231.12.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 14:32:26',-18000,'2014-03-03 19:32:26',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:\n> On Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:\n> >> Having done some work with MySQL (specifically around similar data\n> >> sets) and discussing the changes with some former coworkers (MySQL\n> >> experts) I am inclined to believe the move from varchar  to binary\n> >> absolutely would increase performance like this.\n> >> \n> >> \n> >> However, I would like to get some real benchmarks around it and if it\n> >> really makes a difference we should get a smart \"UUID\" type into the\n> >> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this\n> >> conversation. Should be split off from the keystone one at hand - I\n> >> don\'t want valuable information / discussions to get lost.\n> > \n> > No disagreement on either point. However, this should be done after the\n> > standardization to a UUID user_id in Keystone, as a separate performance\n> > improvement patch. Agree?\n> > \n> > Best,\n> > -jay\n> \n> -1\n> \n> The expectation in other projects has been that project_ids and user_ids are opaque strings. I need to see more clear benefit to enforcing stricter typing on these, because I think it might break a lot of things.\n\nWhat does Nova lose here? The proposal is to have Keystone\'s user_id\nvalues be UUIDs all the time. There would be a migration or helper\nscript against Nova\'s database that would change all non-UUID user_id\nvalues to the Keystone UUID values.\n\nIf there\'s stuff in Nova that would break (which is doubtful,\nconsidering like you say, these are supposed to be \"opaque values\" and\nas such should not have any restrictions or validation on their value),\nthen that is code in Nova that should be fixed.\n\nHonestly, we shouldn\'t accept poor or loose code just because \"stuff\nmight break\".\n\n-jay\n\n\n\n','<09B2503B-3679-46C1-82F8-1D06718AADC6@gmail.com>',NULL),('<1393875835.11231.20.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 14:43:55',-18000,'2014-03-03 19:43:55',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n maximum from 64 to 255','On Mon, 2014-03-03 at 11:18 -0800, Mark Washenberger wrote:\n> \n> \n> \n> On Sat, Mar 1, 2014 at 12:51 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Fri, 2014-02-28 at 15:25 -0800, Mark Washenberger wrote:\n>         > I believe we have some agreement here. Other openstack\n>         services should\n>         > be able to use a strongly typed identifier for users. I just\n>         think if\n>         > we want to go that route, we probably need to create a new\n>         field to\n>         > act as the proper user uuid, rather than repurposing the\n>         existing\n>         > field. It sounds like many existing LDAP deployments would\n>         break if we\n>         > repurpose the existing field.\n>         \n>         \n>         Hi Mark,\n>         \n>         Please see my earlier response on this thread. I am proposing\n>         putting\n>         external identifiers into a mapping table that would correlate\n>         a\n>         Keystone UUID user ID with external identifiers (of variable\n>         length).\n> \n> \n> The thing you seem to be missing is that the current user-id attribute\n> is an \"external identifier\" depending on the identity backend you\'re\n> using today. For example in the LDAP driver it is the CN by default\n> (which is ridiculous for a large number of reasons, but let\'s leave\n> those aside.) So if you want to create a new, strongly typed internal\n> uuid identifier that makes the db performance scream, more power to\n> you. But it\'s going to have to be a new field.\n\nNo, it won\'t. The proposal is to create a new table that maps a UUID\nvalue to the external identifier value.\n\nThe migration would essentially do this pseudocode:\n\nrecs = get_identity_records()\nfor rec in recs:\n  if not is_like_uuid(rec.user_id):\n      external_id = rec.user_id\n      new_uuid = uuid.uuid4()\n      insert_into_external_ids(new_uuid, external_id)\n      rec.user_id = new_uuid\n      save_identity_record(rec)\n\nCascading updates on the user_id field to its child relations will take\ncare of the changes in user_id column in foriegn keys.\n\nA migration script in, say, Nova, would do something like:\n\nUPDATE instances SET owner_id = ext.user_id\nFROM instances JOIN keystone.external_id_mapping ext\nON instances.owner_id = ext.external_id;\n\nBest,\n-jay \n\n\n\n\n','<CAJyP2C8-cKFFPuFVF10VKiozvEGUtBc3hD7N4X-oPaGz3yB0EQ@mail.gmail.com>',NULL),('<1393876743.11231.26.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 14:59:03',-18000,'2014-03-03 19:59:03',NULL,'[openstack-dev] [Nova] Concrete Proposal for Keeping V2 API','-1 from me. Sounds like a way to avoid badly needed change and\ninnovation in the API. When, for example, would we be able to propose a\npatch that removed API extensions entirely?\n\nThe inconsistent naming, capitalization, numerous worthless or pointless\nAPI extensions, ability to do similar or identical things in different\nways, and the incorrect result/response codes makes the Nova API look\nimmature and clownish. I\'d love to see a competing proposal to this that\nlooks towards the future and a day when we can be proud of the Compute\nAPI as a real differentiator vs. the EC2 API. As it stands, the v2 REST\nAPI just makes OpenStack Compute look subpar at best, IMO.\n\nFeel free to accuse me of wanting my cake and eating it, too. I guess\nI\'m just both hungry and impatient.\n\nBest,\n-jay\n\nOn Mon, 2014-03-03 at 12:32 -0500, Russell Bryant wrote:\n> There has been quite a bit of discussion about the future of the v3 API\n> recently.  There has been growing support for the idea that we should\n> change course and focus on evolving the existing v2 API instead of\n> putting out a new major revision.  This message is a more complete\n> presentation of that proposal that concludes that we can do what we\n> really need to do with only the v2 API.\n> \n> Keeping only the v2 API requires some confidence that we can stick with\n> it for years to come.  We don\'t want to be revisiting this any time\n> soon.  This message addresses a bunch of different questions about how\n> things would work if we only had v2.\n> \n> 1) What about tasks?\n> \n> In some cases, the proposed integration of tasks is backwards\n> compatible.  A task ID will be added to a header.  The biggest point of\n> debate was if and how we would change the response for creating a\n> server.  For tasks in v2, we would not change the response by default.\n> The task ID would just be in a header.  However, if and when the client\n> starts exposing version support information, we can provide an\n> alternative/preferred response based on tasks.\n> \n> For example:\n> \n>    Accept: application/json;type=task\n> \n> 2) Versioning extensions\n> \n> One of the points being addressed in the v3 API was the ability to\n> version extensions.  In v2, we have historically required new API\n> extensions, even for changes that are backwards compatible.  We propose\n> the following:\n> \n>  - Add a version number to v2 API extensions\n>  - Allow backwards compatible changes to these API extensions,\n> accompanied by a version number increase\n>  - Add the option to advertise an extension as deprecated, which can be\n> used for all those extensions created only to advertise the availability\n> of new input parameters\n> \n> 3) Core versioning\n> \n> Another pain point in API maintenance has been having to create API\n> extensions for every small addition to the core API.  We propose that a\n> version number be exposed for the core API that exposes the revision of\n> the core API in use.  With that in place, backwards compatible changes\n> such as adding a new property to a resource would be allowed when\n> accompanied by a version number increase.\n> \n> With versioning of the core and API extensions, we will be able to cut\n> down significantly on the number of changes that require an API\n> extension without sacrificing the ability of a client to discover\n> whether the addition is present or not.\n> \n> 4) API Proxying\n> \n> We don\'t see proxying APIs as a problem.  It is the cost we pay for\n> choosing to split apart projects after they are released.  We don\'t\n> think it\'s fair to break users just because we have chosen to split\n> apart the backend implementation.\n> \n> Further, the APIs that are proxied are frozen while those in the other\n> projects are evolving.  We believe that as more features are available\n> only via the native APIs in Cinder, Glance, and Neutron, users will\n> naturally migrate over to the native APIs.\n> \n> Over time, we can ensure clients are able to query the API without the\n> need to proxy by adding new formats or extensions that don\'t return data\n> that needed to be proxied.\n> \n> 5) Capitalization and Naming Consistency\n> \n> Some of the changes in the v3 API included changes to capitalization and\n> naming for improved consistency.  If we stick with v2 only, we will not\n> be able to make any of these changes.  However, we believe that not\n> breaking any existing clients and not having to maintain a second API is\n> worth not making these changes, or supporting some indirection to\n> achieve this for newer clients if we decide it is important.\n> \n> 6) Response Code Consistency and Correctness\n> \n> The v2 API has many places where the response code returned for a given\n> operation is not strictly correct. For example a 200 is returned when a\n> 202 would be more appropriate. Correcting these issues should be\n> considered for improving the future use of the API, however there does\n> not seem to be any support for considering this a critical problem right\n> now. There are two approaches that can be taken to improve this in v2:\n> \n> Just fix them. Right now, we return some codes that imply we have dealt\n> with a request, when all we have done is queue it for processing (and\n> vice versa). In the future, we may change the backend in such a way that\n> a return code needs to change to continue to be accurate anyway. If we\n> just assume that return codes may change to properly reflect the action\n> that was taken, then we can correct existing errors and move on.\n> Accept them as wrong but not critically so. With this approach, we can\n> strive for correctness in the future without changing behavior of our\n> existing APIs. Nobody seems to complain about them right now, so\n> changing them seems to be little gain. If the client begins exposing a\n> version header (which we need for other things) then we could\n> alternately start returning accurate codes for those clients.\n> \n> The key point here is that we see a way forward with this in the v2 API\n> regardless of which path we choose.\n> \n> 7) Entrypoint based extensions\n> \n> The v3 effort included improvements to the infrastructure used to\n> implement the API, both for proper extensions and modular construction\n> of the core API.  We definitely want that for v2, and since these are\n> just internal implementation details, there is no reason why we can\'t\n> implement these improvements in the v2 API.  Note that with the addition\n> of versioning of extensions and the core, we should be adding fewer API\n> extensions and may be able to collapse some that we already have.\n> \n> 8) Input Validation\n> \n> Previously, much of our input validation happened at the database driver\n> layer for various reasons. This means that behavior of the API depends\n> on such user-invisible things as which RDBM is in use. Thus, our input\n> validation is already inconsistent across deployments. Further, the move\n> to objects as the communication mechanism between the API and the\n> backend means that more input validation is going on than we once had\n> anyway, and this is not something we can avoid unless we freeze the\n> backend anyway.\n> \n> Exposing a definition like jsonschema is something that we should do\n> anyway, and the process of doing so should allow us to define what was\n> previously undefined. Given the variance of the behavior depending on\n> the database used on the backend, getting something reasonably strict\n> should be roughly equivalent (user-wise) to working against a provider\n> that was using something other than MySQL.\n> \n> 9) v3 ... if not now, when?\n> \n> Not in the foreseeable future.  We don\'t see it happening unless some\n> group of people wanted to rebuild the API from scratch in such a way\n> that it doesn\'t look anything like the current API.  The new API would\n> have to be different and compelling enough that we\'d be willing to\n> maintain it along side the current API for several years.\n> \n> 10) Conclusion and Proposal\n> \n> The v3 API effort has produced a lot of excellent work.  However, the\n> majority opinion seems to be that we should avoid the cost of\n> maintaining two APIs if at all possible.  We should apply what has been\n> learned to the existing API where we can and focus on making v2\n> something that we can continue to maintain for years to come.\n> \n> We recognize and accept that it is a failure of Nova project leadership\n> that we did not come to this conclusion much sooner.  We hope to have\n> learned from the experience to help avoiding a situation like this\n> happening again in the future.\n> \n> Please provide your input on this proposal, even if it is just agreement\n> with this as the way forward.\n> \n> Thanks,\n> \n> Proposal authors / sponsors:\n> \n>     Russell Bryant\n>     Dan Smith\n>     John Garbutt\n>     Andrew Laski\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5314BC94.6040103@redhat.com>',NULL),('<1393876889.11231.27.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 15:01:29',-18000,'2014-03-03 20:01:29',NULL,'[openstack-dev] WARNING: ... This application has not enabled\n MySQL traditional mode,\n which means silent data corruption may occur - real issue?','On Mon, 2014-03-03 at 14:25 -0500, Sean Dague wrote:\n> So that definitely got lost in translation somewhere, and is about to\n> have us spam icehouse users with messages that make them think their\n> openstack cluster is going to burn to the ground. Is there proposed\n> reviews to set those defaults in projects up already?\n> \n> Remember - WARN is a level seen by administrators, and telling everyone\n> they have silent data corruption is not a good default.\n\n++. All that needs to happen is checking to see if the MySQL sql_mode is\nalready set at a traditional or stricter level before issuing the\nwarning message.\n\n-jay\n\n\n\n','<5314D738.8090403@dague.net>',NULL),('<1393877916.11231.28.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 15:18:36',-18000,'2014-03-03 20:18:36',NULL,'[openstack-dev] [OpenStack-Infra] [Third Party CI] Reminder:\n Workshop/Q&A meeting on #openstack-meeting today at 13:00EST/18:00 UTC','On Mon, 2014-03-03 at 16:53 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> I have the following doubts with my CI setup.\n> \n> Hope presenting them before the meeting might help me with some more guidance. \n> \n> [1] sandbox-dvsm-tempest-full runs all the test cases where few fail, causing the completed build to fail. \n>     How to restrict the testcases?\n>     Please find the errors.txt as an attachment to this email. This time VM (cirros) failed. \n> \n> [2] After the build is failed, still services like nova, swift are running. Does Jenkins using devstack unstack the stack.\n> \n> [3] For some tempest test cases, I get the message \"Neutron skipped\" but in the devstack logs, neutron is installed from git. Do I need to configure something more for neutron.\n> \n> [4] For services like Neutron, do we need to test cinder, nova, heat, swift etc.. too ??\n\nAll: For reference, we answered the above questions on an etherpad here:\n\nhttps://etherpad.openstack.org/p/third-party-ci-workshop\n\nWe will continue to add information to the above etherpad in the coming\nweeks.\n\nBest,\n-jay\n\n\n\n','<9e2e69b29e2647d8b882bfaa00ee9f19@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1393877916.11231.28.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-03 15:18:36',-18000,'2014-03-03 20:18:36',NULL,'[OpenStack-Infra] [Third Party CI] Reminder: Workshop/Q&A\n meeting on #openstack-meeting today at 13:00EST/18:00 UTC','On Mon, 2014-03-03 at 16:53 +0000, trinath.somanchi at freescale.com wrote:\n> Hi Jay-\n> \n> I have the following doubts with my CI setup.\n> \n> Hope presenting them before the meeting might help me with some more guidance. \n> \n> [1] sandbox-dvsm-tempest-full runs all the test cases where few fail, causing the completed build to fail. \n>     How to restrict the testcases?\n>     Please find the errors.txt as an attachment to this email. This time VM (cirros) failed. \n> \n> [2] After the build is failed, still services like nova, swift are running. Does Jenkins using devstack unstack the stack.\n> \n> [3] For some tempest test cases, I get the message \"Neutron skipped\" but in the devstack logs, neutron is installed from git. Do I need to configure something more for neutron.\n> \n> [4] For services like Neutron, do we need to test cinder, nova, heat, swift etc.. too ??\n\nAll: For reference, we answered the above questions on an etherpad here:\n\nhttps://etherpad.openstack.org/p/third-party-ci-workshop\n\nWe will continue to add information to the above etherpad in the coming\nweeks.\n\nBest,\n-jay\n\n\n\n','<9e2e69b29e2647d8b882bfaa00ee9f19@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1393878793.11231.32.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 15:33:13',-18000,'2014-03-03 20:33:13',NULL,'[openstack-dev] [Neutron] Flavor Framework','On Fri, 2014-02-28 at 10:19 +0400, Eugene Nikanorov wrote:\n>         \n>         1) I\'m not entirely sure that a provider attribute is even\n>         necessary to\n>         expose in any API. What is important is for a scheduler to\n>         know which\n>         drivers are capable of servicing a set of attributes that are\n>         grouped\n>         into a \"flavor\".\n> Well, provider becomes read-only attribute and for admin only (jsut to\n> see which driver actually handles the resources), not too much of API\n> visibility. \n\nI\'d very much prefer to keep the provider/driver name out of the public\nAPI entirely. I don\'t see how it is needed.\n\n>         2) I would love to see the use of the term \"flavor\" banished\n>         from\n>         OpenStack APIs. Nova has moved from flavors to \"instance\n>         types\", which\n>         clearly describes what the thing is, without the odd\n>         connotations that\n>         the word \"flavor\" has in different languages (not to mention\n>         the fact\n>         that flavor is spelled flavour in non-American English).\n>         \n>         How about using the term \"load balancer type\", \"VPN type\", and\n>         \"firewall\n>         type\" instead?\n> Oh... I don\'t have strong opinion on the name of the term.\n> \"Flavor\" was used several time in our discussions and is short.\n> \"*Instance* Type\" however seems also fine. Another option is probably\n> a \"Service Offering\".\n\nOK.\n\n>         3) I don\'t believe the FlavorType (public or internal)\n>         attribute of the\n>         flavor is useful. We want to get away from having any\n>         vendor-specific\n>         attributes or objects in the APIs (yes, even if they are\n>         \"hidden\" from\n>         the normal user). See point #1 for more about this. A\n>         scheduler should\n>         be able to match a driver to a request simply by matching the\n>         set of\n>         required capabilities in the requested flavor (load balancer\n>         type) to\n>         the set of capabilities advertised by the driver.\n> ServiceType you mean? If you\'re talking about ServiceType then it\n> mostly for the user to filter flavors (I\'m using short term for now)\n> by service type. Say, when user wants to create new loadbalancer,\n> horizon will show only flavors related to the lb.\n> That could be also solved by having different names live you suggested\n> above: \"Lb type\", \"VPN type\", etc. \n> On other hand that would be similar objects with different names -\n> does it make much sense?\n\nNo, I wasn\'t referring to ServiceType. I was referring to \"FlavorType\"\n-- public or internal -- in your diagram. I don\'t believe this is\nnecessary, frankly.\n\n> I\'m not sure what you think \'vendor-specific\' attributes are, I don\'t\n> remember to have plan of exposing any kind of vendor-related\n> parameters. The parameters that flavor represents are capabilities of\n> the service in terms that user care about: latency, throughput,\n> topology, technology, etc.\n\nYes, agreed. ++\n\n>         4) A minor point... I think it would be fine to group the\n>         various\n>         \"types\" into a single database table behind the scenes (like\n>         you have in\n>         the Object model section). However, I think it is useful to\n>         have the\n>         public API expose a /$servie-types resource endpoint for each\n>         service\n>         itself, instead of a generic /types (or /flavors) endpoint.\n>         So, folks\n>         looking to set up a load balancer would call\n>         GET /balancer-types, or\n>         call neutron balancer-type-list, instead of calling\n>         GET /types?service=load-balancer or neutron flavor-list\n>         --service=load-balancer\n> I\'m fine with this suggestion.\n>  \n>         \n>         5) In the section on Scheduling, you write \"Scheduling is a\n>         process of\n>         choosing provider and a backend for the resource\". As\n>         mentioned above, I\n>         think this could be changed to something like this:\n>         \"Scheduling is a\n>         process of matching the set of requested capabilities -- the\n>         flavor\n>         (type) -- to the set of capabilities advertised by a driver\n>         for the\n>         resource\". That would put Neutron more in line with how Nova\n>         handles\n>         this kind of thing.\n> I agree, I actually meant this and nova example is how I think it\n> should work.\n> But more important is what is the result of scheduling.\n> We discussed that yesterday with Mark and I think we got so the point\n> where we could not find agreement for now.\n> In my opinion the result of scheduling is binding resource to the\n> driver (at least)\n> So further calls to the resource go to the same driver because of that\n> binding.\n> That\'s pretty much the same how agent scheduling works.\n>  \n> By the way I\'m thinking about getting rid of \'provider\' term and using\n> \'driver\' instead. Currently \'provider\' is just a user-facing\n> representation of the driver. Once we introduce flavors/service\n> types/etc, we can use term \'driver\' for implementation means.\n\n++\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwOSVDB9so-C7mLGTpPXmdYnmdPKX9ear61p1=hkW=9S-FQ@mail.gmail.com>',NULL),('<1393879045.11231.35.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 15:37:25',-18000,'2014-03-03 20:37:25',NULL,'[openstack-dev] [Neutron] Flavor Framework','On Fri, 2014-02-28 at 01:31 -0800, Gary Duan wrote:\n> What are the parameters that will be part of flavor definition? As I\n> am thinking of it now, the parameter could be performance and capacity\n> related, for example, throughput, max. session number and so on; or\n> capability related, for example, HA, L7 switching.\n\nI would think the latter -- a capabilities-based descriptor of the\nservice offering.\n\n> Compared to # of CPU and memory size in Nova flavor, these parameters\n> don\'t seem to have exact definitions across different implementations.\n> Or, you think it is not something we need worry about. It\'s totally\n> operator\'s decision of how to rate different drivers?\n\nI would think it would be fairly easy to create some basic load balancer\ntypes, and then let deployers define other ones, similar to how Nova\'s\ndefault flavors work.\n\nBest,\n-jay\n\n\n\n\n','<CA+JXUoPEOk_+m6D8im-AMswQPqRQdxobuEE7B_0eU7+NPQQ8Nw@mail.gmail.com>',NULL),('<1393881486.1051.YahooMailNeo@web140401.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 13:18:06',-28800,'2014-03-03 21:18:06',NULL,'[Openstack] Seeking for Ideas about Trusted Cloud','Check the Trust token and OAuth token in Keystone ( although currently, OAuth Token support is minimal)\n\n...shohel\n\n\n\nOn Monday, March 3, 2014 7:09 PM, Lichao Yin <lichaoyin at gmail.com> wrote:\n \nHi stackers,\nOur group are doing research on OpenStack.\n\nOne of our scenario is like this:\nThere are two users on cloud: user A and user B.\nUser A has some resources like volumes or object storage on cloud. We\nhope these resource could belong to some certain user, not one tenant.\n\nUser A wants to verify user B and grant user B the access to user A\'s\nresource (maybe by token, but we hope this token is not bare token and\ncould only be used by user B).\n\nSo does anyone have idea about it or about what part of Keystone should\nwe modify?\n\nIf you have any idea, I would appreciate any feedback.\n\nThanks,\nLichao Yin\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140303/e69bc1ca/attachment.html>\n\n','<5314B30E.9080306@gmail.com>',NULL),('<1393883289.2746.11.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 16:48:09',-18000,'2014-03-03 21:48:09',NULL,'[openstack-dev] [Nova] Concrete Proposal for Keeping V2 API','On Mon, 2014-03-03 at 15:24 -0500, Russell Bryant wrote:\n> On 03/03/2014 02:59 PM, Jay Pipes wrote:\n> > -1 from me. Sounds like a way to avoid badly needed change and\n> > innovation in the API. When, for example, would we be able to propose a\n> > patch that removed API extensions entirely?\n> \n> v3 didn\'t address this at all, anyway.  I\'m not even sure there\'s\n> consensus on it.  In any case, I think it\'s tangential and only relevant\n> if we\'re starting with a new API.\n\nI guess I am saying that if the ostensibly \"limited\" changes and\nstandardization of Chris and others\' V3 API work has now been decided is\ntoo risky to use or of not enough value to users, then the chance that a\nbrand new API version seeing the light of day is pretty low. And that is\ndisappointing to me. Feel free to tell me I\'m nuts, though. I\'d happily\nexchange my skepticism for some healthy optimism.\n\n> > The inconsistent naming, capitalization, numerous worthless or pointless\n> > API extensions, ability to do similar or identical things in different\n> > ways, and the incorrect result/response codes makes the Nova API look\n> > immature and clownish. I\'d love to see a competing proposal to this that\n> > looks towards the future and a day when we can be proud of the Compute\n> > API as a real differentiator vs. the EC2 API. As it stands, the v2 REST\n> > API just makes OpenStack Compute look subpar at best, IMO.\n> \n> Much of what you discuss is addressed in the document.\n\nWell, it\'s discussed in the document... in as much to say \"we won\'t\nreally change any of these things...\"\n\n> I think the differentiation that you want comes from a new ground-up\n> API, and not what\'s being discussed here (v3, or further evolution of v2).\n\nYes, but my concern about this proposal is that it reinforces the status\nquo and in so doing, slows down the pace of innovation at the API level.\nAnd, a slow pace of API innovation in turn inhibits innovation at layers\nof the code beneath the API.\n\n> > Feel free to accuse me of wanting my cake and eating it, too. I guess\n> > I\'m just both hungry and impatient.\n> \n> Not that, exactly ... just ignoring some of the practicalities at hand,\n> I think.\n\nFair enough. :)\n\nBest,\n-jay\n\n\n\n','<5314E517.5010602@redhat.com>',NULL),('<1393886590-sup-779@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-03 14:44:53',-28800,'2014-03-03 22:44:53',NULL,'[OpenStack-Infra] [Tripleo][CI] check-tripleo outage','Excerpts from Jeremy Stanley\'s message of 2014-03-03 13:52:54 -0800:\n> On 2014-03-02 17:49:29 +1300 (+1300), Robert Collins wrote:\n> [...]\n> > That said, infra isn\'t spinning up nodes properly, but manual testing\n> > brings up nodes just fine with plenty of network speed, so we\'re not\n> > sure whats up.\n> \n> There were a couple problems... nova seemed very sure we were over\n> quota on just a handful of building nodes (I think that must have\n> been cleaned up since then), and nodepool couldn\'t ssh to the nodes\n> which did build (seems like Clint said the L3 agent wasn\'t running).\n> Anyway, seems running and mostly caught up now.\n\nFYI the machine failed again about 2 hours ago, and our NOC has now\ntaken the machine offline to replace the motherboard.\n\nHopefully once it is back up we can start landing patches to get HA\ngoing so this won\'t be an issue anymore. :)\n\n\n','<20140303215253.GC2347@yuggoth.org>',NULL),('<1393888641.2746.23.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 18:17:21',-18000,'2014-03-03 23:17:21',NULL,'[openstack-dev] [Nova] Concrete Proposal for Keeping V2 API','On Mon, 2014-03-03 at 17:56 -0500, Andrew Laski wrote:\n> On 03/03/14 at 04:48pm, Jay Pipes wrote:\n> >On Mon, 2014-03-03 at 15:24 -0500, Russell Bryant wrote:\n> >> On 03/03/2014 02:59 PM, Jay Pipes wrote:\n> >> > -1 from me. Sounds like a way to avoid badly needed change and\n> >> > innovation in the API. When, for example, would we be able to propose a\n> >> > patch that removed API extensions entirely?\n> >>\n> >> v3 didn\'t address this at all, anyway.  I\'m not even sure there\'s\n> >> consensus on it.  In any case, I think it\'s tangential and only relevant\n> >> if we\'re starting with a new API.\n> >\n> >I guess I am saying that if the ostensibly \"limited\" changes and\n> >standardization of Chris and others\' V3 API work has now been decided is\n> >too risky to use or of not enough value to users, then the chance that a\n> >brand new API version seeing the light of day is pretty low. And that is\n> >disappointing to me. Feel free to tell me I\'m nuts, though. I\'d happily\n> >exchange my skepticism for some healthy optimism.\n> \n> This isn\'t about the v3 API changes being too risky or not of value to\n> users.  What has been most concerning about the v3 API is the amount of\n> code it has introduced into the Nova tree and the amount of testing work\n> that has been required.  Doing this split once has been a pain but \n> overall has been manageable up to this point, IMO.  But at this point we \n> don\'t have any reasonable idea on when v2 can be removed, so it\'s \n> potentially with us for good.  And while v3 improves the story around \n> making API changes it doesn\'t address some of the things that caused us \n> to look at v3 in the first place.  So we\'re potentially setting \n> ourselves up to eventually hold three or more API versions in tree.  \n> Before going down that road we came up with a proposal that allows us to \n> move forward in much the same way as v3 but with a lower maintenance \n> burden.\n> \n> What I would like to see is answers for how v3 can address some of the \n> questions that are being asked of this proposal, such as removing API \n> extensions entirely.  Or how would we add entirely new concepts like \n> tasks?\n\nAny changes that we make to V2 will prolong its life. I think you will\nagree with this, yes?\n\nMy main point is a philosophical one: if we scrap the V3 effort and\ndecide to instead make changes to V2, then by nature, I think we will\ndelay the ability to make more significant changes to the API.\n\nI\'d like to work on a brand new (v4?) Compute API that dramatically\nchanges the way that compute operations are made. If we make changes to\nthe V2 API and extend its life, I don\'t have as much incentive to work\non a brand new API version, since I\'ve already seen that even minor\nchanges like those in the V3 API can\'t make it into mainline in 3\nrelease cycles. Like I said, it\'s philosophical. \n\n> Personally I love the changes that v3 provides, and want to see our API \n> evolve and mature in the direction it\'s heading.  But I also want it to \n> have real value.  Beyond a few renames and return code fixes what does \n> it do that we can\'t do with v2?  That\'s the question I\'m still asking \n> myself.\n> \n> \n> >\n> >> > The inconsistent naming, capitalization, numerous worthless or pointless\n> >> > API extensions, ability to do similar or identical things in different\n> >> > ways, and the incorrect result/response codes makes the Nova API look\n> >> > immature and clownish. I\'d love to see a competing proposal to this that\n> >> > looks towards the future and a day when we can be proud of the Compute\n> >> > API as a real differentiator vs. the EC2 API. As it stands, the v2 REST\n> >> > API just makes OpenStack Compute look subpar at best, IMO.\n> >>\n> >> Much of what you discuss is addressed in the document.\n> >\n> >Well, it\'s discussed in the document... in as much to say \"we won\'t\n> >really change any of these things...\"\n> >\n> >> I think the differentiation that you want comes from a new ground-up\n> >> API, and not what\'s being discussed here (v3, or further evolution of v2).\n> >\n> >Yes, but my concern about this proposal is that it reinforces the status\n> >quo and in so doing, slows down the pace of innovation at the API level.\n> >And, a slow pace of API innovation in turn inhibits innovation at layers\n> >of the code beneath the API.\n> \n> What innovation is being slowed down?  This proposal was put together to \n> compare against the current v3 effort and see if we can tease out these \n> things.  What can we do in v3 that we can\'t do in v2?\n\nSee above. It\'s about the statement that this proposal makes to those\ndevelopers who might have been considering contributing improvements to\nthe Compute API.\n\nBest,\n-jay\n\n> >> > Feel free to accuse me of wanting my cake and eating it, too. I guess\n> >> > I\'m just both hungry and impatient.\n> >>\n> >> Not that, exactly ... just ignoring some of the practicalities at hand,\n> >> I think.\n> >\n> >Fair enough. :)\n> >\n> >Best,\n> >-jay\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140303225610.GF3356@crypt>',NULL),('<1393888792.2746.24.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 18:19:52',-18000,'2014-03-03 23:19:52',NULL,'[openstack-dev] Proposal to move from Freenode to OFTC','On Mon, 2014-03-03 at 15:07 -0800, James E. Blair wrote:\n> Hi,\n> \n> Freenode has been having a rough time lately due to a series of DDoS\n> attacks which have been increasingly disruptive to collaboration.\n> Fortunately there\'s an alternative.\n> \n> OFTC <URL:http://www.oftc.net/> is a robust and established alternative\n> to Freenode.  It is a smaller network whose mission statement makes it a\n> less attractive target.  It\'s significantly more stable than Freenode\n> and has friendly and responsive operators.  The infrastructure team has\n> been exploring this area and we think OpenStack should move to using\n> OFTC.\n> \n> This would obviously be a big change, but we think that with the\n> following process, we can move fairly smoothly:\n> \n> 0) Establish channel and bot registrations on OFTC.  This has already\n> been done (for all the channels listed on the wiki and all the bots\n> managed via the infrastructure program).  That actually puts us ahead of\n> Freenode where we still haven\'t managed to register all the channels we\n> use.\n> \n> 1) Create an irc.openstack.org CNAME record that points to\n> chat.freenode.net.  Update instructions to suggest users configure their\n> clients to use that alias.\n> \n> 2) Set a date and time for a cutover, at least several weeks out.  Make\n> multiple announcements about the move on mailing lists, blogs, etc.\n> \n> 3) Set channel topics in OFTC to remind people that the move has not yet\n> occurred.\n> \n> Nearer to the cutover date:\n> \n> 4) Ask a few people (perhaps some core members of each team) to join\n> OFTC a few days early to be there to assist anyone who shows up there\n> and is confused.\n> \n> 5) On the cutover, change the CNAME and links to web clients in the\n> wiki.  The infrastructure team will switch IRC bots (including channel\n> logging) at the cutover time as well.  Send reminder announcements.\n> \n> 6) Ask those same people from #4 to stick around Freenode for a few\n> weeks after the cutover to assist anyone who shows up there and is\n> confused.\n> \n> 7) Set channel topics in Freenode to remind people that we have moved to\n> OFTC.\n> \n> If there aren\'t objections to this plan, I think we can propose a motion\n> to the TC with a date and move forward with it fairly soon.\n\nSounds like a well thought-out plan. ++\n\n-jay\n\n\n\n','<878usq3mpy.fsf@meyer.lemoncheese.net>',NULL),('<1393917724-sup-1115@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 23:25:33',-28800,'2014-03-04 07:25:33',NULL,'[openstack-dev] [all][keystone] Increase of USER_ID length\n	maximum from 64 to 255','Excerpts from Adam Young\'s message of 2014-03-03 23:06:58 -0800:\n> On 03/03/2014 02:32 PM, Jay Pipes wrote:\n> > On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:\n> >> On Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> >>\n> >>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:\n> >>>> Having done some work with MySQL (specifically around similar data\n> >>>> sets) and discussing the changes with some former coworkers (MySQL\n> >>>> experts) I am inclined to believe the move from varchar  to binary\n> >>>> absolutely would increase performance like this.\n> >>>>\n> >>>>\n> >>>> However, I would like to get some real benchmarks around it and if it\n> >>>> really makes a difference we should get a smart \"UUID\" type into the\n> >>>> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this\n> >>>> conversation. Should be split off from the keystone one at hand - I\n> >>>> don\'t want valuable information / discussions to get lost.\n> >>> No disagreement on either point. However, this should be done after the\n> >>> standardization to a UUID user_id in Keystone, as a separate performance\n> >>> improvement patch. Agree?\n> >>>\n> >>> Best,\n> >>> -jay\n> >> -1\n> >>\n> >> The expectation in other projects has been that project_ids and user_ids are opaque strings. I need to see more clear benefit to enforcing stricter typing on these, because I think it might break a lot of things.\n> > What does Nova lose here? The proposal is to have Keystone\'s user_id\n> > values be UUIDs all the time. There would be a migration or helper\n> > script against Nova\'s database that would change all non-UUID user_id\n> > values to the Keystone UUID values.\n> >\n> > If there\'s stuff in Nova that would break (which is doubtful,\n> > considering like you say, these are supposed to be \"opaque values\" and\n> > as such should not have any restrictions or validation on their value),\n> > then that is code in Nova that should be fixed.\n> >\n> > Honestly, we shouldn\'t accept poor or loose code just because \"stuff\n> > might break\".\n> Why do you think that UUIDs would be some sort of magic bullet?\n> \n> Thus far, we\'ve stated that IDs are opaque strings, and that they will \n> be URL safe.  Adding additional Database lokups on top of LDAP calls is \n> going to make LDAP code paths even more convoluted than they are now.  \n> I\'d like to avoid that. And I don\'t see the benefit.\n> \n\nEach row in each table throughout OpenStack that has to treat the user\nid from Keystone as an opaque ID must then store the keystone id as a 64\nbyte string. Being able to make it a 16 byte binary value means a\nsignificant saving at scale.\n\nIf you\'re using LDAP, you\'re only going to store that CN once per user,\nand only going to look it up when said user tries to log in. After that,\nthe uuid will be passed around.\n\n> \n> I\'d be interested in hearing why CN is a bad default choice for LDAP; we \n> have to use a very high up theRFE chain object class by default and \n> didn\'t have that many attributes to chose from.\n> \n\nCN is fine. External IDs of various shapes and sizes can be used. The\npoint is to make keystone get a little more opionated about its\' id\nstrings in order to make the rest of OpenStack more scalable.\n\n\n','<53157B92.6040008@redhat.com>',NULL),('<1393935064.12.1380610255167.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-01 06:50:54',0,'2013-10-01 06:50:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #32','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/32/>\n\n------------------------------------------\n[...truncated 12950 lines...]\n2013-10-01 06:50:14 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,swift3, ]]\n2013-10-01 06:50:14 + [[ swift3 == \\n\\o\\v\\a ]]\n2013-10-01 06:50:14 + [[ swift3 == \\c\\i\\n\\d\\e\\r ]]\n2013-10-01 06:50:14 + [[ swift3 == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-01 06:50:14 + [[ swift3 == \\g\\l\\a\\n\\c\\e ]]\n2013-10-01 06:50:14 + [[ swift3 == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-01 06:50:14 + [[ swift3 == \\s\\w\\i\\f\\t ]]\n2013-10-01 06:50:14 + [[ swift3 == s-* ]]\n2013-10-01 06:50:14 + return 1\n2013-10-01 06:50:14 + is_service_enabled zeromq\n2013-10-01 06:50:14 + services=zeromq\n2013-10-01 06:50:14 + for service in \'${services}\'\n2013-10-01 06:50:14 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,zeromq, ]]\n2013-10-01 06:50:14 + [[ zeromq == \\n\\o\\v\\a ]]\n2013-10-01 06:50:14 + [[ zeromq == \\c\\i\\n\\d\\e\\r ]]\n2013-10-01 06:50:14 + [[ zeromq == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-01 06:50:14 + [[ zeromq == \\g\\l\\a\\n\\c\\e ]]\n2013-10-01 06:50:14 + [[ zeromq == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-01 06:50:14 + [[ zeromq == \\s\\w\\i\\f\\t ]]\n2013-10-01 06:50:14 + [[ zeromq == s-* ]]\n2013-10-01 06:50:14 + return 1\n2013-10-01 06:50:14 + is_service_enabled n-api\n2013-10-01 06:50:14 + services=n-api\n2013-10-01 06:50:14 + for service in \'${services}\'\n2013-10-01 06:50:16 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,n-api, ]]\n2013-10-01 06:50:16 + return 0\n+ exec\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-10-01 06:50:16 + echo_summary \'Starting Nova API\'\n2013-10-01 06:50:16 + [[ -t 3 ]]\n2013-10-01 06:50:16 + echo -e Starting Nova API\n2013-10-01 06:50:16 + start_nova_api\n2013-10-01 06:50:16 + local service_port=8774\n2013-10-01 06:50:16 + is_service_enabled tls-proxy\n2013-10-01 06:50:16 + services=tls-proxy\n2013-10-01 06:50:16 + for service in \'${services}\'\n2013-10-01 06:50:16 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,tls-proxy, ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-10-01 06:50:16 + [[ tls-proxy == s-* ]]\n2013-10-01 06:50:16 + return 1\n2013-10-01 06:50:16 + screen_it n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + SCREEN_NAME=stack\n2013-10-01 06:50:16 + SERVICE_DIR=/opt/stack/new/status\n2013-10-01 06:50:16 Starting Nova API\n2013-10-01 06:50:16 ++ trueorfalse True False\n2013-10-01 06:50:16 ++ local default=True\n2013-10-01 06:50:16 ++ local testval=False\n2013-10-01 06:50:16 ++ [[ -z False ]]\n2013-10-01 06:50:16 ++ [[ 0 no false False FALSE =~ False ]]\n2013-10-01 06:50:16 ++ echo False\n2013-10-01 06:50:16 ++ return\n2013-10-01 06:50:16 + USE_SCREEN=False\n2013-10-01 06:50:16 + is_service_enabled n-api\n2013-10-01 06:50:16 + services=n-api\n2013-10-01 06:50:16 + for service in \'${services}\'\n2013-10-01 06:50:16 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,n-api, ]]\n2013-10-01 06:50:16 + return 0\n2013-10-01 06:50:16 + screen_rc n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + SCREEN_NAME=stack\n2013-10-01 06:50:16 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-01 06:50:16 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-01 06:50:16 + grep n-api /opt/stack/new/devstack/stack-screenrc\n2013-10-01 06:50:16 ++ echo -ne \'\\015\'\n2013-10-01 06:50:16 + NL=$\'\\r\'\n2013-10-01 06:50:16 + echo \'screen -t n-api bash\'\n2013-10-01 06:50:16 + echo \'stuff \"cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\n\"\'\n2013-10-01 06:50:16 + [[ False = \\T\\r\\u\\e ]]\n2013-10-01 06:50:16 + run_process n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + local service=n-api\n2013-10-01 06:50:16 + local \'command=cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + echo 20173\n2013-10-01 06:50:16 + _run_process n-api \'cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + echo \'Waiting for nova-api to start...\'\n2013-10-01 06:50:16 Waiting for nova-api to start...\n2013-10-01 06:50:16 + wait_for_service 60 http://127.0.0.1:8774\n2013-10-01 06:50:16 + local timeout=60\n2013-10-01 06:50:16 + local url=http://127.0.0.1:8774\n2013-10-01 06:50:16 + timeout 60 sh -c \'while ! http_proxy= https_proxy= curl -s http://127.0.0.1:8774 >/dev/null; do sleep 1; done\'\n2013-10-01 06:50:16 + local service=n-api\n2013-10-01 06:50:16 + local \'command=cd /opt/stack/new/nova && /opt/stack/new/nova/bin/nova-api\'\n2013-10-01 06:50:16 + exec\n2013-10-01 06:50:16 + exec\n2013-10-01 06:50:16 + is_service_enabled tls-proxy\n2013-10-01 06:50:16 + services=tls-proxy\n2013-10-01 06:50:16 + for service in \'${services}\'\n2013-10-01 06:50:16 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,tls-proxy, ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\q\\u\\a\\n\\t\\u\\m ]]\n2013-10-01 06:50:16 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-10-01 06:50:16 + [[ tls-proxy == s-* ]]\n2013-10-01 06:50:16 + return 1\n2013-10-01 06:50:16 + is_service_enabled q-svc\n2013-10-01 06:50:16 + services=q-svc\n2013-10-01 06:50:16 + for service in \'${services}\'\n2013-10-01 06:50:16 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,q-svc, ]]\n2013-10-01 06:50:16 + return 0\n2013-10-01 06:50:16 + echo_summary \'Starting Quantum\'\n2013-10-01 06:50:16 + [[ -t 3 ]]\n2013-10-01 06:50:16 + echo -e Starting Quantum\n2013-10-01 06:50:16 + start_quantum_service_and_check\n2013-10-01 06:50:16 + local cfg_file\n2013-10-01 06:50:16 + local \'CFG_FILE_OPTIONS=--config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:16 Starting Quantum\n2013-10-01 06:50:16 + screen_it q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:16 + SCREEN_NAME=stack\n2013-10-01 06:50:16 + SERVICE_DIR=/opt/stack/new/status\n2013-10-01 06:50:16 ++ trueorfalse True False\n2013-10-01 06:50:16 ++ local default=True\n2013-10-01 06:50:16 ++ local testval=False\n2013-10-01 06:50:16 ++ [[ -z False ]]\n2013-10-01 06:50:20 ++ [[ 0 no false False FALSE =~ False ]]\n2013-10-01 06:50:20 ++ echo False\n2013-10-01 06:50:20 ++ return\n2013-10-01 06:50:20 + USE_SCREEN=False\n2013-10-01 06:50:21 + is_service_enabled q-svc\n2013-10-01 06:50:21 + services=q-svc\n2013-10-01 06:50:21 + for service in \'${services}\'\n2013-10-01 06:50:21 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,q-svc, ]]\n2013-10-01 06:50:21 + return 0\n2013-10-01 06:50:21 + screen_rc q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:21 + SCREEN_NAME=stack\n2013-10-01 06:50:21 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-01 06:50:21 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-01 06:50:21 + grep q-svc /opt/stack/new/devstack/stack-screenrc\n2013-10-01 06:50:21 ++ echo -ne \'\\015\'\n2013-10-01 06:50:21 + NL=$\'\\r\'\n2013-10-01 06:50:21 + echo \'screen -t q-svc bash\'\n2013-10-01 06:50:21 + echo \'stuff \"cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\n\"\'\n2013-10-01 06:50:21 + [[ False = \\T\\r\\u\\e ]]\n2013-10-01 06:50:21 + run_process q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:21 + local service=q-svc\n2013-10-01 06:50:21 + local \'command=cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:21 + echo 20347\n2013-10-01 06:50:21 + _run_process q-svc \'cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:21 + echo \'Waiting for Quantum to start...\'\n2013-10-01 06:50:21 Waiting for Quantum to start...\n2013-10-01 06:50:21 + timeout 60 sh -c \'while ! http_proxy= wget -q -O- http://10.4.234.28:9696; do sleep 1; done\'\n2013-10-01 06:50:21 + local service=q-svc\n2013-10-01 06:50:21 + local \'command=cd /opt/stack/new/neutron && python /opt/stack/new/neutron/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini\'\n2013-10-01 06:50:21 + exec\n2013-10-01 06:50:21 + exec\n2013-10-01 06:50:21 {\"versions\": [{\"status\": \"CURRENT\", \"id\": \"v2.0\", \"links\": [{\"href\": \"http://10.4.234.28:9696/v2.0\", \"rel\": \"self\"}]}]}+ create_quantum_initial_network\n2013-10-01 06:50:21 ++ keystone tenant-list\n2013-10-01 06:50:21 ++ grep \' demo \'\n2013-10-01 06:50:21 ++ get_field 1\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 ++ \'[\' 1 -lt 0 \']\'\n2013-10-01 06:50:21 ++ field=\'$2\'\n2013-10-01 06:50:21 ++ echo \'| 7da1c77fba354503a78383bb9ebf3221 |        demo        |   True  |\'\n2013-10-01 06:50:21 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 + TENANT_ID=7da1c77fba354503a78383bb9ebf3221\n2013-10-01 06:50:21 + is_baremetal\n2013-10-01 06:50:21 + [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta =~ baremetal ]]\n2013-10-01 06:50:21 + return 1\n2013-10-01 06:50:21 ++ quantum net-create --tenant_id 7da1c77fba354503a78383bb9ebf3221 private\n2013-10-01 06:50:21 ++ grep \' id \'\n2013-10-01 06:50:21 ++ get_field 2\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 ++ \'[\' 2 -lt 0 \']\'\n2013-10-01 06:50:21 ++ field=\'$3\'\n2013-10-01 06:50:21 ++ echo \'| id                        | 3fac1717-b923-4d17-9e2f-9ada3f77cad5 |\'\n2013-10-01 06:50:21 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 + NET_ID=3fac1717-b923-4d17-9e2f-9ada3f77cad5\n2013-10-01 06:50:21 ++ grep \' id \'\n2013-10-01 06:50:21 ++ get_field 2\n2013-10-01 06:50:21 ++ quantum subnet-create --tenant_id 7da1c77fba354503a78383bb9ebf3221 --ip_version 4 --gateway 10.1.0.1 3fac1717-b923-4d17-9e2f-9ada3f77cad5 10.1.0.0/24\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 ++ \'[\' 2 -lt 0 \']\'\n2013-10-01 06:50:21 ++ field=\'$3\'\n2013-10-01 06:50:21 ++ echo \'| id               | c20f3380-8e6d-4f17-811c-eeb0ba721e31       |\'\n2013-10-01 06:50:21 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 + SUBNET_ID=c20f3380-8e6d-4f17-811c-eeb0ba721e31\n2013-10-01 06:50:21 + [[ True == \\T\\r\\u\\e ]]\n2013-10-01 06:50:21 + [[ True == \\T\\r\\u\\e ]]\n2013-10-01 06:50:21 ++ quantum router-create --tenant_id 7da1c77fba354503a78383bb9ebf3221 router1\n2013-10-01 06:50:21 ++ grep \' id \'\n2013-10-01 06:50:21 ++ get_field 2\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 ++ \'[\' 2 -lt 0 \']\'\n2013-10-01 06:50:21 ++ field=\'$3\'\n2013-10-01 06:50:21 ++ echo \'| id                    | 01baa76e-1210-42b6-b973-bfbc61772aa1 |\'\n2013-10-01 06:50:21 ++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n2013-10-01 06:50:21 ++ read data\n2013-10-01 06:50:21 + ROUTER_ID=01baa76e-1210-42b6-b973-bfbc61772aa1\n2013-10-01 06:50:21 + quantum router-interface-add 01baa76e-1210-42b6-b973-bfbc61772aa1 c20f3380-8e6d-4f17-811c-eeb0ba721e31\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-428525-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-428525.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-428525/32/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<702222305.5.1380434844959.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1393942389.8810.9.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 09:13:09',-18000,'2014-03-04 14:13:09',NULL,'[openstack-dev] [OpenStack-Dev] [Cinder] Open Source and\n community working together','On Tue, 2014-03-04 at 10:11 +0100, Luke Gorrie wrote:\n> On 3 March 2014 18:30, Thierry Carrez <thierry at openstack.org> wrote:\n>         My advice was therefore that you should not wait for that to\n>         happen to\n>         \n>         engage in cooperative behavior, because you don\'t want to be\n>         the first\n>         company to get singled out.\n> \n> \n> \"Cooperative behavior\" is vague.\n\nNot really, IMO.\n\n> Case in point: I have not successfully setup 3rd party CI for the ML2\n> driver that I\'ve developed on behalf of a vendor.\n\nPlease feel free to engage with myself and others on IRC if you have\nproblems. We had a first meeting on #openstack-meeting yesterday and\nhave started putting answers to questions about 3rd party CI here:\n\nhttps://etherpad.openstack.org/p/third-party-ci-workshop\n\nLet me know how we can help you!\n\n>  Does this make me one of your \"uncooperative vendors\"? \n\nOf course not. Now, if you were not seeking out any assistance from the\ncommunity and instead were talking to a few other companies about just\nreplacing all of the upstream continuous integration system with\nsomething you wrote yourself, yes, I would say that\'s being\nuncooperative. :)\n\n> Do I need to worry about being fired because somebody at OpenStack\n> decides to \"name and shame\" the company I\'m doing the work for and\n> make an example? (Is that what the \"deprecated neutron drivers list\"\n> will be used for?)\n\nNo. Not having success in setting up a required CI link does not make\nyou uncooperative. Simply reach out to others in the community for\nassistance if you need it.\n\n> If one project official says \"driver contributors have to comply with\n> X, Y, Z by Icehouse-2\" and then another project official says that\n> \"uncooperative contributors are going to be nailed to the wall\" then,\n> well, sucks to be contributors.\n\nI think you are over-analyzing this :)\n\nBest,\n-jay\n\n\n\n\n','<CAA2XHbfo7Gu5dJFfSEZbyWGefdmCwwjWU6i528hcDwbyctiRuw@mail.gmail.com>',NULL),('<1393949221.8810.25.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 11:07:01',-18000,'2014-03-04 16:07:01',NULL,'[openstack-dev] [3rd party testing] How to setup CI? Take #2','On Tue, 2014-03-04 at 16:31 +0100, Luke Gorrie wrote:\n> Option 1: Should I debug the CI implementation we developed and tested\n> back in December, which was not based on Tempest but rather on our\n> private integration test method that we used in the Havana cycle? The\n> debugging that is needed is more defensive programming in our\n> automated attempt to setup OpenStack for test -- so that if the\n> installation fails for some unexpected reason we don\'t vote based on\n> that.\n> \n> Option 2: Should I start over with a standard Tempest test insead? If\n> so, what\'s the best method to set it up (yours? Arista\'s? another?),\n> and how do I know when that method is sufficiently debugged that it\'s\n> time to start?\n\nAlthough I recognize you and your team have put in a substantial amount\nof time in debugging your custom setup, I would advise dropping the\ncustom CI setup and going with a method that specifically uses the\nupstream openstack-dev/devstack and openstack-infra/devstack-gate\nprojects. The reason is because these two projects are well supported by\nthe upstream Infrastructure team.\n\ndevstack will allow you to set up a complete OpenStack environment that\nmatches upstream -- with the exception of using the Tailf-NCS ML2 plugin\ninstead of the default plugin. devstack-gate will provide you the git\ncheckout plumbing that will populate the source directories for the\nOpenStack projects that devstack uses to build its OpenStack\nenvironment.\n\nI\'d recommend using my os-ext-testing repository (which is mostly just a\ncouple shell scripts and documentation that uses the upstream Puppet\nmodules to install and configure Jenkins, Zuul, Jenkins Job Builder,\nGearman, devstack-gate/nodepool scripts on a master and slave node).\n\n> I was on the 3rd party testing meeting last night (as \'lukego\') and\n> your recommendation for me was to hold off for a week or so and then\n> try your method after your next update. That sounds totally fine to me\n> in principle. However, this will mean that I don\'t have a mature test\n> procedure in place by March 14th, and I\'m concerned that there may be\n> bad consequences on this. This date was mentioned as a deadline in the\n> Neutron meeting last night, but I don\'t actually understand what the\n> consequence of non-compliance is for established drivers such as this\n> one.\n\nI\'m not going to step on Mark McClain\'s toes regarding policy for\ndrivers in the Neutron code tree; Mark, please chime in here.\n\nI mentioned waiting about a week because, after discussions with the\nupstream Infrastructure team yesterday, it became clear that putting a\nnodepool manager in place to spin up *single-use devstack slave nodes*\nfor running Tempest tests is going to be necessary.\n\nI had previously thought that it was possible to reset a Devstack\nenvironment to a clean state (thus being able to re-use the slave\nJenkins node for >1 test run). However, so much is changed on the slave\nnode during a Tempest run (and by devstack itself), that the only way to\ntruly ensure a clean test environment is to have a brand new devstack\nslave node created/launched for each test run. Nodepool is the piece of\nsoftware that manages a pool of these devstack slave nodes, and it will\ntake me about a week to complete a new article and testing on the\nos-ext-testing repository for integrating and installing nodepool\nproperly.\n\nBest,\n-jay\n\n\n\n\n','<CAA2XHbfRG2G2+o7M+Lqg3f23DYKVoAHhppacYP27i9gJoawy-Q@mail.gmail.com>',NULL),('<1393949682.14075.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-04 10:14:42',-21600,'2014-03-04 16:14:42',NULL,'[Openstack] nova image-list fails','On Tue, 2014-03-04 at 18:45 +0530, Mandar Khanolkar wrote:\n> I am getting failure while listing images in nova.\n[snip]\n>   File \"/usr/lib/python2.7/site-packages/novaclient/openstack/common/apiclient/base.py\", line 204, in <module>\n>     @six.add_metaclass(abc.ABCMeta)\n> AttributeError: \'module\' object has no attribute \'add_metaclass\'\n\nLooks like you have an old version of \"six\" installed.  The\n\"python-novaclient\" package wants a minimum of 1.5.2 for what\'s\ncurrently in git.  I recommend upgrading the \"six\" package to the\nlatest.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CABoY1tw5YXg2w_6aNfCjDPxd+rwettMkHMsDAL1iJNoRaS=6TQ@mail.gmail.com>',NULL),('<1393966858.14075.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 15:00:58',-21600,'2014-03-04 21:00:58',NULL,'[openstack-dev] [Nova] What is the currently accepted way to do\n plugins','On Tue, 2014-03-04 at 12:11 -0800, Dan Smith wrote:\n> Now, the actual concern is not related to any of that, but about whether\n> we\'re going to open this up as a new thing we support. In general, my\n> reaction to adding new APIs people expect to be stable is \"no\". However,\n> I understand why things like the resource reporting and even my events\n> mechanism are very useful for deployers to do some plumbing and\n> monitoring of their environment -- things that don\'t belong upstream anyway.\n> \n> So I\'m conflicted. I think that for these two cases, as long as we can\n> say that it\'s not a stable interface, I think it\'s probably okay.\n> However, things like we\'ve had in the past, where we provide a clear\n> plug point for something like \"Compute manager API class\" are clearly\n> off the table, IMHO.\n\nHow about using \'unstable\' as a component of the entrypoint group?\nE.g., \"nova.unstable.events\"?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53163363.2090604@danplanet.com>',NULL),('<1393969078-sup-9439@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 14:06:16',-28800,'2014-03-04 22:06:16',NULL,'[openstack-dev] [heat]Policy on upgades required config changes','Excerpts from Steven Hardy\'s message of 2014-03-04 09:39:21 -0800:\n> Hi all,\n> \n> As some of you know, I\'ve been working on the instance-users blueprint[1].\n> \n> This blueprint implementation requires three new items to be added to the\n> heat.conf, or some resources (those which create keystone users) will not\n> work:\n> \n> https://review.openstack.org/#/c/73978/\n> https://review.openstack.org/#/c/76035/\n> \n> So on upgrade, the deployer must create a keystone domain and domain-admin\n> user, add the details to heat.conf, as already been done in devstack[2].\n> \n> The changes requried for this to work have already landed in devstack, but\n> it was discussed to day and Clint suggested this may be unacceptable\n> upgrade behavior - I\'m not sure so looking for guidance/comments.\n> \n> My plan was/is:\n> - Make devstack work\n> - Talk to tripleo folks to assist in any transition (what prompted this\n>   discussion)\n> - Document the upgrade requirements in the Icehouse release notes so the\n>   wider community can upgrade from Havana.\n> - Try to give a heads-up to those maintaining downstream heat deployment\n>   tools (e.g stackforge/puppet-heat) that some tweaks will be required for\n>   Icehouse.\n> \n> However some have suggested there may be an openstack-wide policy which\n> requires peoples old config files to continue working indefinitely on\n> upgrade between versions - is this right?  If so where is it documented?\n> \n\nI don\'t think I said indefinitely, and I certainly did not mean\nindefinitely.\n\nWhat is required though, is that we be able to upgrade to the next\nrelease without requiring a new config setting.\n\nAlso as we scramble to deal with these things in TripleO (as all of our\nusers are now unable to spin up new images), it is clear that it is more\nthan just a setting. One must create domain users carefully and roll out\na new password.\n\nWhat I\'m suggesting is that we should instead _warn_ that the old\nbehavior is being used and will be deprecated.\n\nAt this point, out of urgency, we\'re landing fixes. But in the future,\nthis should be considered carefully.\n\n\n','<20140304173920.GA6967@t430slt.redhat.com>',NULL),('<1393973901.14075.9.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 16:58:21',-21600,'2014-03-04 22:58:21',NULL,'[openstack-dev] [Nova] What is the currently accepted way to do\n plugins','On Tue, 2014-03-04 at 17:31 -0400, Sandy Walsh wrote:\n> > How about using \'unstable\' as a component of the entrypoint group?\n> > E.g., \"nova.unstable.events\"?\n> \n> Wouldn\'t that defeat the \"point\" of entry points ... immutable\n> endpoints? What happens when an unstable event is deemed stable?\n\nActually, the idea here is that the API that those entrypoints are\nexpected to express is unstable; when the API stabilizes, you\'d remove\nthe \"unstable\" part, then *never* change the API again.  This is as\nopposed to thinking that the entrypoint itself is unstable?nova\nshouldn\'t care, it should just use it?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53164623.3080002@rackspace.com>',NULL),('<1393989618.815311598@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-04 21:20:18',-21600,'2014-03-05 03:20:18',NULL,'[openstack-dev] [solum] use of the plan for m1','I support this approach. \n\nCustomization of build and deploy lifecycle actions depends on\nthe ability to register different kinds of services for performing\nthese actions. I can imagine that operators would want to provide\nsuch services as part of their Solum install. Then, app developers\nwould be able to find about such services and refer to them in\ntheir application descriptor (may be a plan file, may be\nsomething else). However, for m1, I agree that we should go with\nthe view that build and deploy services are not externalized, but are\navailable as default services in Solum.\n\nAbout the proposed simpler descriptor -- the only question I have is about\nthe language-pack to use to build the app. Won\'t we need it in the\napplication descriptor? So I propose:\n\nartifacts:\n- name: My Python App\n   artifact_type: application.heroku\n   content: { href: http://github.com/some/project }\n   language-pack: <language-pack-id>\n\n- Devdatta\n\n\n-----Original Message-----\nFrom: \"Angus Salkeld\" <angus.salkeld at rackspace.com>\nSent: Tuesday, March 4, 2014 8:52pm\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [solum] use of the plan for m1\n\nHi all\n\nI just wanted to clarify our use of the camp plan file (esp. for m1).\n\nUp until now I have been under the impression that use the plan\nto describe the app lifecycle (build/test/deploy) and the contents\nof the app.\n\nAfter attempting to write code that converts plans like this into\nheat templates started to think that this is not a good idea as\nit is mixing two ideas from very different areas. It also makes\nthe resulting plan complex.\n\nI suggest we move from some of the plans suggested here:\nhttps://etherpad.openstack.org/p/solum-demystified\n\nto a very simple:\nartifacts:\n- name: My Python App\n   artifact_type: application.heroku\n   content: { href: http://github.com/some/project }\n\nFor m1 we can assume a lifecycle of build and deploy. After that\nwe can figure out how we would want to expose the lifecycle\nchoices/customization to the user.\n\nThoughts?\n\n-Angus\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140305025205.GA29754@rackspace.com>',NULL),('<1394010087.44844.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 17:01:27',28800,'2014-03-05 09:01:27',NULL,'[Openstack] swift recon query','hello all,\n\nI have some basic questions about swift recon. please query them.\n\n\nQ1: what should be the curl command for recon?\n\nI use the following commands:\n1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n\n\nHTTP/1.1 401 Unauthorized\nContent-Length: 131\nContent-Type: text/html; charset=UTF-8\nWww-Authenticate: Swift realm=\"async\"\nX-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\nDate: Wed, 05 Mar 2014 08:43:17 GMT\n\n<html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html> \n\n\n2.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n\n\nHTTP/1.1 401 Unauthorized\nContent-Length: 131\nContent-Type: text/html; charset=UTF-8\nWww-Authenticate: Swift realm=\"AUTH_prag2648\"\nX-Trans-Id: tx978f787ce01f446a9beeb-005316e424\nDate: Wed, 05 Mar 2014 08:45:24 GMT\n\n<html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html>\n\nQ2. Does \'swift-recon\' command not provide the status about \n\n?????????????????????? (i)????? /proc/meminfo, \n\n?????????????????????? (ii)???? currently mounted file systems\n?????????????????????? (iii)??? list of devices\n????? if \'swift-recon\' provides these informations, then what should be the command?\n\nQ3. It stands for what?\n??????????? low\n??????????? high\n??????????? avg\n??????????? total\n??????????? failed\n??????????? no_result\n??????????? reported\n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/b0ac6a7d/attachment.html>\n\n',NULL,NULL),('<1394015172.227776567@f425.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 14:26:12',14400,'2014-03-05 10:26:12',NULL,'[Openstack] unable to ping google.com','\nAnd when ping is unreachable, I always make a http request like:?curl --head google.com\n\nGood wish.\n\n--\nlooking for cloud developers: \nhttp://www.nsbeta.info/jobs\n\n\nWednesday, March  5, 2014 10:07 AM UTC from <yalla.gnan.kumar at accenture.com>:\n>Solved it? J . It seems that ping is firewalled for our local LAN.\n>?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/60e1d96d/attachment.html>\n\n','<67765C71374B974FBFD2AD05AF438EFF2BF71F@048-CH1MPN3-363.048d.mgd.msft.net>',NULL),('<1394027536.22944.2.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-05 08:52:16',-18000,'2014-03-05 13:52:16',NULL,'[openstack-dev] [Nova] Concrete Proposal for Keeping V2 API','On Wed, 2014-03-05 at 05:43 +0000, Kenichi Oomichi wrote:\n> > -----Original Message-----\n> > From: Dan Smith [mailto:dms at danplanet.com]\n> > Sent: Wednesday, March 05, 2014 9:09 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API\n> > \n> > > What I\'d like to do next is work through a new proposal that includes\n> > > keeping both v2 and v3, but with a new added focus of minimizing the\n> > > cost.  This should include a path away from the dual code bases and to\n> > > something like the \"v2.1\" proposal.\n> > \n> > I think that the most we can hope for is consensus on _something_. So,\n> > the thing that I\'m hoping would mostly satisfy the largest number of\n> > people is:\n> > \n> > - Leaving v2 and v3 as they are today in the tree, and with v3 still\n> >   marked experimental for the moment\n> > - We start on a v2 proxy to v3, with the first goal of fully\n> >   implementing the v2 API on top of v3, as judged by tempest\n> > - We define the criteria for removing the current v2 code and marking\n> >   the v3 code supported as:\n> >  - The v2 proxy passes tempest\n> >  - The v2 proxy has sign-off from some major deployers as something\n> >    they would be comfortable using in place of the existing v2 code\n> >  - The v2 proxy seems to us to be lower maintenance and otherwise\n> >    preferable to either keeping both, breaking all our users, deleting\n> >    v3 entirely, etc\n> \n> Thanks, Dan.\n> The above criteria is reasonable to me.\n> \n> Now Tempest does not check API responses in many cases.\n> For example, Tempest does not check what API attributes(\"flavor\", \"image\",\n> etc.) should be included in the response body of \"create a server\" API.\n> So we need to improve Tempest coverage from this viewpoint for verifying\n> any backward incompatibility does not happen on v2.1 API.\n> We started this improvement for Tempest and have proposed some patches\n> for it now.\n\nKenichi-san, you may also want to check out this ML post from David\nKranz:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-March/028920.html\n\nBest,\n-jay\n\n\n\n','<663E0F2C6F9EEA4AAD1DEEBD89158AAEF7B3EC@BPXM06GP.gisp.nec.co.jp>',NULL),('<1394028808.22944.4.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-05 09:13:28',-18000,'2014-03-05 14:13:28',NULL,'[OpenStack-Infra] Unable to connect to puppetdb server!','On Wed, 2014-03-05 at 17:10 +0530, Vinay Mahuli wrote:\n> Hi,\n> \n> From the link,  http://ci.openstack.org/puppet.html#id2, \n> \n> The command \"puppet apply\n> --modulepath=\'/opt/config/production/modules:/etc/puppet/modules\' -e\n> \'include openstack_project::puppetmaster\' \" doesn\'t work.\n\nYou do not need to run puppetmaster.\n\nAre you using the install_master.sh script from the os-ext-testing\nrepository? If not, I\'d recommend it. It runs scripts to install puppet,\nJenkins, Gearman, Jenkins Job Builder and other stuff you need.\n\nBest,\n-jay\n\n\n\n\n','<CAPXWXVjfTCmzg6QNaS+j9idK11H=kUjVXD7tJH6h9wrKOEKDow@mail.gmail.com>',NULL),('<1394037137.979532034@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-03-05 10:32:17',-21600,'2014-03-05 16:32:17',NULL,'[openstack-community] Industry Events:  Call for Papers update','\n\nHere are the Call for Papers submission deadlines for upcoming industry events.  Please help spread the OpenStack excitement by speaking at one or more of these events. \n\nIn addition if you are interested in speaking on behalf of OpenStack at [http://cloudwf.com/] Cloud World Forum in London on June 17, please let me know (kathyc at openstack.org).  We have a 20 minute theater session and additional panelist opportunity for an executive or manager with an enterprise IT focus.\n\nThank you.\n[https://www.usenix.org/conference/hotcloud14] HotCloud \'14, 6th USENIX Workshop on Hot Topics in Cloud Computing, event date June 17-18, Philadelphia.  [http:://www.usenix.org/conference/hotcloud14/call-for-papers] CFP open through March 6.\n[http://events.linuxfoundation.org/events/linuxcon-japan] LinuxCon/CloudOpen Japan, event date May 20-22 in Tokyo.  [http://events.linuxfoundation.org/events/linuxcon-japan/program/cfp] CFP open until March 14.\n[http://events.gigaom.com/structure-2014/] GigaOM Structure NA, event date is June 18-19 in San Francisco.  [http://events.gigaom.com/structure-2014/speakers/speaker-proposal/] CFP deadline is March 21.\n[http://www.gtec.ca/] GTEC 2014, event date October 27-30 in Ottawa.  [http://www.gtec.ca/conference/?_mc=EM_DB_LE_GTEC14_EM2B] CFP deadline is March 28.\n[http://texaslinuxfest.org/] Texas Linux Fest 2014, event date June 13-14, Austin.  [http://www.texaslinuxfest.org/content/call-papers] CFP deadline is April 5.\n[https://www.usenix.org/conference/lisa14] USENIX LISA \'14, 28th Large Installation Systems Administration Conference, event date November 9-14, Seattle.  [https://www.usenix.org/conference/lisa14/call-for-participation] CFP deadline is April 14. \n[http://events.linuxfoundation.org/events/linuxcon-north-america] LinuxCon/CloudOpen North America, event date is August 20-22 in Chicago.  [http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp] CFP deadline is May 2.\n[http://events.linuxfoundation.org/events/cloudopen-europe] LinuxCon/Cloud Open Europe, event date is October 13-15 in Dusseldorf.  [http://events.linuxfoundation.org/events/cloudopen-europe/program/cfp] CFP open until July 11.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140305/9fee5182/attachment.html>\n\n',NULL,NULL),('<1394046574.5887.1.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-05 14:09:34',-18000,'2014-03-05 19:09:34',NULL,'[OpenStack-Infra] Unable to connect to puppetdb server!','On Wed, 2014-03-05 at 23:19 +0530, Vinay Mahuli wrote:\n> My requirement is to set-up my own ci infra for a open source product\n> (This product sits on top of openstack).\n> The first thing which we did is to\n> go-through http://ci.openstack.org/running-your-own.html\n> The \"initial step\" in this link contains\n> http://ci.openstack.org/puppet.html#id2\n\nOK.\n\n> I have set-up 6 hosts(puppetmaster, review, jenkins-master,\n> jenkins-slave, zuul, puppetdashboard) in my infrastructure.\n> 1. Can you suggest me the right approach?\n\nThere are multiple right approaches. The one I took was to use the\nupstream openstack-infra/config puppet modules and bash scripts as much\nas possible, since those are what the infra team knows well and has\nexperience with.\n\n> 2. Can you give me some more info on using the install_master.sh\n> script from the os-ext-testing\n> repository?\n\nPlease see my blog articles here for information about this:\n\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/\n\nBest\n-jay\n\n\n\n','<CAPXWXVikvJHutc9LA8On7ifNXO_yahGxBELAPhCCw9QdTgXyvA@mail.gmail.com>',NULL),('<1394058960.772418001@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-03-05 16:36:00',-21600,'2014-03-05 22:36:00',NULL,'[openstack-community] 2 Pavilion pods available at Gartner IT\n	Infrastructure and Data Center Conference in Sydney','\nOpenStack and eight community members were successful at this conference in December in Las Vegas.  Each collected a smaller number of contacts than at a typical event, but much higher quality.  This Gartner conference attracts the perfect audience for us.\n \nWe\'re excited to be expanding our presence at Gartner events in a similar Pavilion with a theater, in Sydney, May 21-22.  Four community members are already committed. There are two spots left.  The cost is about 10,000 AUD (approx $9,000 US), and includes a pod, two 15-20 minute theater presentations/demos, logo/url on the web site, a 1-1 analyst meeting, a full conference pass, booth staff passes, and more.\n \nPlease reply to me, kathyc at openstack.org, if interested.  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140305/d7914edf/attachment.html>\n\n',NULL,NULL),('<1394086202.9658097.1398284609175.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 16:23:29',-14400,'2014-04-23 20:23:29',NULL,'[openstack-dev] [Horizon] Question regarding new panels and\n tests','> I have a question about adding new panels with respect to tests.\n> \n> I have a new panel (for the Sahara project, data processing) that lives (for\n> now at least) under the projects folder.  The plan is to have it activated\n> only by using the new \"enabled\" mechanism to define a new panel group, \"data\n> processing\", where it and several other panels will eventually show up.\n> \n> When I did this, it works fine for me when I run it, but running the tests\n> (tox -e py27) fails because my panel is not registered anywhere.  Is there a\n> config for the tests that I can tweak so that my panel can be registered for\n> the tests (tests/enabled or something like that?\n> \n> Thanks,\n> Chad\n> \n\nHiya - I haven\'t tested this, but one thing you could try. . . if you look at \nhorizon/openstack_dashboard/settings.py, there\'s a section that determines\nwhere the dashboard looks for plugins (https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L220)\n\n   # Load the pluggable dashboard settings\n   import openstack_dashboard.enabled\n   import openstack_dashboard.local.enabled\n   from openstack_dashboard.utils import settings\n\n   INSTALLED_APPS = list(INSTALLED_APPS) # Make sure it\'s mutable\n   settings.update_dashboards([\n       openstack_dashboard.enabled,\n       openstack_dashboard.local.enabled,\n   ], HORIZON_CONFIG, INSTALLED_APPS)\n\nIf you edit horizon/openstack_dashboard/settings.py to add a similar section,\nonly using, say, openstack_dashboard.test.local.enabled, you may be able to enable\nthe panels for the tests there.\n\nMainn\n\n\n\n\n','<42103950.9629236.1398281634596.JavaMail.zimbra@redhat.com>',NULL),('<1394089065.48338.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 14:57:45',28800,'2014-03-06 06:57:45',NULL,'[Openstack] swift recon query','please somebody answer my questions related to swift recon.\n\nThanks?\n\nPragya Jain\n\n\n\nOn Wednesday, 5 March 2014 2:31 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>\n>\n>I have some basic questions about swift recon. please query them.\n>\n>\n>\n>Q1: what should be the curl command for recon?\n>\n>\n>I use the following commands:\n>1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>\n>\n>\n>HTTP/1.1 401 Unauthorized\n>Content-Length: 131\n>Content-Type: text/html; charset=UTF-8\n>Www-Authenticate: Swift realm=\"async\"\n>X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n>Date: Wed, 05 Mar 2014 08:43:17 GMT\n>\n><html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html> \n>\n>\n>\n>2.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>\n>\n>\n>HTTP/1.1 401 Unauthorized\n>Content-Length: 131\n>Content-Type: text/html; charset=UTF-8\n>Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n>X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n>Date: Wed, 05 Mar 2014 08:45:24 GMT\n>\n><html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html>\n>\n>\n>Q2. Does \'swift-recon\' command not provide the status about \n>\n>?????????????????????? (i)????? /proc/meminfo, \n>\n>?????????????????????? (ii)???? currently mounted file systems\n>?????????????????????? (iii)??? list of devices\n>????? if \'swift-recon\' provides these informations, then what should be the command?\n>\n>\n>Q3. It stands for what?\n>??????????? low\n>??????????? high\n>??????????? avg\n>??????????? total\n>??????????? failed\n>??????????? no_result\n>??????????? reported\n>\n>\n>Pragya Jain\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/831022ab/attachment.html>\n\n','<1394010087.44844.YahooMailNeo@web193604.mail.sg3.yahoo.com>',NULL),('<1394089978.65625.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 15:12:58',28800,'2014-03-06 07:12:58',NULL,'[Openstack] problem in log in django swiftbrowser','hi Christian,\n\nPlease help to resolve the problem.\n\nThanks?\nPragya Jain\n\n\n\nOn Monday, 3 March 2014 4:33 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi Christian,\n>\n>\n>I did the following steps:\n>1. root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py collectstatic\n>\n>\n>\n>OUTPUT:\n>You have requested to collect static files at the destination\n>location as specified in your settings:\n>\n>??? /var/www/myproj/static\n>\n>This will overwrite existing files!\n>Are you sure you want to do this?\n>\n>Type \'yes\' to continue, or \'no\' to cancel: yes\n>\n>0 static files copied to \'/var/www/myproj/static\', 9 unmodified.\n>\n>\n>\n>2. root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n>\n>\n>\n>OUTPUT:\n>Validating models...\n>\n>0 errors found\n>March 03, 2014 - 11:58:30\n>Django version 1.6.2, using settings \'myproj.settings\'\n>Starting development server at http://127.0.0.1:8000/\n>Quit the server with CONTROL-C.\n>[03/Mar/2014 11:59:00] \"GET / HTTP/1.1\" 302 0\n>[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n>[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n>[03/Mar/2014\n 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n>\n>\n>----\n>\n>\n>Pragya Jain\n>\n>\n>\n>\n>On Monday, 3 March 2014 4:00 PM, Christian Schwede <christian.schwede at enovance.com> wrote:\n> \n>Hello Pragya,\n>>\n>>please collect the static files in step 5 from the Readme:\n>>\n>>> python manage.py collectstatic\n>>\n>>If you didn\'t changed ALLOWED_HOSTS and run swiftbrowser with Debug =\n>>False (default) you also need to run the development server with the\n>>--insecure option (step 6 in the Readme).\n>>\n>>>\n python manage.py runserver --insecure\n>>\n>>Christian\n>>\n>>\n>>\n>>Am 03.03.14 09:57, schrieb pragya jain:\n>>> hello all,\n>>> \n>>> I had installed django swiftbrowser using the link\n>>> https://github.com/cschwede/django-swiftbrowser\n>>> when I login in swifbrowser, I can\'t login and get the following response.\n>>> \n>>> root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py\n>>> runserver\n>>> Validating models...\n>>> \n>>> 0 errors found\n>>> March 03,\n 2014 - 09:50:16\n>>> Django version 1.6.2, using settings \'myproj.settings\'\n>>> Starting development server at http://127.0.0.1:8000/\n>>> Quit the server with CONTROL-C.\n>>> [03/Mar/2014 09:50:57] \"GET / HTTP/1.1\" 302 0\n>>> [03/Mar/2014 09:50:57] \"GET /login/ HTTP/1.1\" 200 3799\n>>> [03/Mar/2014 09:50:58] \"GET /static/bootstrap/css/bootstrap.min.css\n>>> HTTP/1.1\" 404 11\n>>> [03/Mar/2014 09:50:58] \"GET\n>>> /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 404 11\n>>> [03/Mar/2014 09:50:58] \"GET /static/bootstrap/js/bootstrap.min.js\n>>> HTTP/1.1\" 404 11\n>>> [03/Mar/2014 09:50:58] \"GET /static/jquery.min.js HTTP/1.1\" 404 11\n>>> [03/Mar/2014 09:50:58] \"GET\n /static/bootstrap/js/bootstrap.min.js\n>>> HTTP/1.1\" 404 11\n>>> [03/Mar/2014 09:51:36] \"POST /login/ HTTP/1.1\" 500 0\n>>> \n>>> please help to resolve the problem\n>>> \n>>> pragya Jain\n>>> \n>>> \n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to? ?  : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> \n>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to? ?  : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/5a4e3d42/attachment.html>\n\n','<1393844582.42410.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1394101505.69687.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 18:25:05',28800,'2014-03-06 10:25:05',NULL,'[Openstack] swift recon query','hi Gerry,\n\nI run following commands:\nroot at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/async\ncurl: (7) couldn\'t connect to host\nroot at swift-VirtualBox:~# swift-recon -a\n===============================================================================\n--> Starting reconnaissance on 4 hosts\n===============================================================================\n[2014-03-06 15:51:14] Checking async pendings\n[async_pending] - No hosts returned valid data.\n===============================================================================\n\n\nI can\'t understand where is the problem\n\nPlease help.\n\nThanks\n\nPragya jain\n\n\n\n\nOn Thursday, 6 March 2014 2:38 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> wrote:\n \nTry\n>?\n>curl? -i http://127.0.0.1:6000/recon/async\n>?\n>assuming 6000 is the port the object-server binds to.\n>?\n>Gerry,\n>?\n>From:pragya jain [mailto:prag_2648 at yahoo.co.in] \n>Sent: 06 March 2014 06:58\n>To: openstack at lists.openstack.org\n>Subject: Re: [Openstack] swift recon query\n>?\n>please somebody answer my questions related to swift recon.\n>?\n>Thanks?\n>?\n>Pragya Jain\n>?\n>On Wednesday, 5 March 2014 2:31 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>hello all,\n>>?\n>>I have some basic questions about swift recon. please query them.\n>>?\n>>Q1: what should be the curl command for recon?\n>>?\n>>I use the following commands:\n>>1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>>?\n>>HTTP/1.1 401 Unauthorized\n>>Content-Length: 131\n>>Content-Type: text/html; charset=UTF-8\n>>Www-Authenticate: Swift realm=\"async\"\n>>X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n>>Date: Wed, 05 Mar 2014 08:43:17 GMT\n>>\n>><html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html> \n>>?\n>>2.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>>?\n>>HTTP/1.1 401 Unauthorized\n>>Content-Length: 131\n>>Content-Type: text/html; charset=UTF-8\n>>Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n>>X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n>>Date: Wed, 05 Mar 2014 08:45:24 GMT\n>>\n>><html><h1>Unauthorized</h1><p>This server could not verify that you are authorized to access the document you requested.</p></html>\n>>?\n>>Q2. Does \'swift-recon\' command not provide the status about \n>>?????????????????????? (i)????? /proc/meminfo, \n>>?????????????????????? (ii)???? currently mounted file systems\n>>?????????????????????? (iii)??? list of devices\n>>????? if \'swift-recon\' provides these informations, then what should be the command?\n>>?\n>>Q3. It stands for what?\n>>??????????? low\n>>??????????? high\n>>??????????? avg\n>>??????????? total\n>>??????????? failed\n>>??????????? no_result\n>>??????????? reported\n>>?\n>>Pragya Jain\n>>?\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/7d4579c1/attachment.html>\n\n','<923E0D692F901442ACBA7199520F3D4625301F6E@G4W3226.americas.hpqcorp.net>',NULL),('<1394102193.62074.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 18:36:33',28800,'2014-03-06 10:36:33',NULL,'[Openstack] query about Statsd','hello all,\n\nI have some questions about?Statsd server for openstack swift\n\nQ1: ?Is swift-informant middleware necessary to be included in proxy-server.conf in order to provide metrics to StatsD server?\n\nQ2: what type of metrics does?swift-informant middleware?provide to StatsD server?\n\nQ3: ?What is StatsDlog? Is it a middleware or a daemon or something other? And, What type of metrics does it?provide to StatsD server?\n\nI had searched many documents, but I still have confusion about it.\nPlease somebody answer my questions.\n\nThanks?\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/815317d0/attachment.html>\n\n',NULL,NULL),('<1394120593.18754.25.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-06 07:43:13',-28800,'2014-03-06 15:43:13',NULL,'[openstack-tc] Missing next TC meeting','On Thu, 2014-03-06 at 14:04 +0100, Thierry Carrez wrote:\n> Members of the TC,\n> \n> I am taking a week off next week so I\'ll miss our next TC meeting on\n> March 11th.\n> \n> We have a significant backlog and need to complete the Juno graduation\n> reviews before March 28 (start of the PTL elections), so I think it\n> would be better if we didn\'t skip it.\n> \n> The tentative agenda lives at:\n> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee\n> \n> Anyone interested in chairing this one ?\n\nHappy to volunteer again, but if anyone else is keen to do it ... that\'s\ncool too.\n\nMark.\n\n\n\n','<53187277.8040906@openstack.org>',NULL),('<1394121804.3326.10.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 11:03:24',-18000,'2014-03-06 16:03:24',NULL,'[openstack-dev] [Neutron][LBaaS] Mini-summit Interest?','On Thu, 2014-03-06 at 15:32 +0000, Jorge Miramontes wrote:\n> I\'d like to gauge everyone\'s interest in a possible mini-summit for\n> Neturon LBaaS. If enough people are interested I\'d be happy to try and\n> set something up. The Designate team just had a productive mini-summit\n> in Austin, TX and it was nice to have face-to-face conversations with\n> people in the Openstack community. While most of us will meet in\n> Atlanta in May, I feel that a focused mini-summit will be more\n> productive since we won\'t have other Openstack distractions around us.\n> Let me know what you all think!\n\n++\n\n++\n\nI think a few weeks after the design summit would be a good time.\n\n-jay\n\n\n\n','<CF3DF11D.DC87%jorge.miramontes@rackspace.com>',NULL),('<1394123826.2300.6.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 11:37:06',-18000,'2014-03-06 16:37:06',NULL,'[openstack-dev] [Nova] Tox issues on a clean environment','I am having a very similar issue with horizon, just today. I cloned the\nrepo and started from scratch on master.\n\ntools/install_venv.py is trying to install cffi as a depdendency,\nultimately fails with \n\nImportError: cannot import name Feature\n\nThis is Fedora 19.  I know some folks on Fedora 20 who are not having\nthis issue.  I\'m guessing it\'s a version thing...\n\nTrevor\n\nOn Thu, 2014-03-06 at 08:14 -0800, Gary Kotton wrote:\n> Hi,\n> Anyone know how I cam solve the error below:\n> \n> \n>   Running setup.py install for jsonpatch\n>     /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown\n> distribution option: \'entry_poimts\'\n>       warnings.warn(msg)\n>     changing mode of build/scripts-2.7/jsondiff from 664 to 775\n>     changing mode of build/scripts-2.7/jsonpatch from 664 to 775\n>     \n>     changing mode of /home/gk-dev/nova/.tox/py27/bin/jsonpatch to 775\n>     changing mode of /home/gk-dev/nova/.tox/py27/bin/jsondiff to 775\n>   Found existing installation: distribute 0.6.24dev-r0\n>     Not uninstalling distribute at /usr/lib/python2.7/dist-packages,\n> outside environment /home/gk-dev/nova/.tox/py27\n>   Running setup.py install for setuptools\n>     \n>     Installing easy_install script to /home/gk-dev/nova/.tox/py27/bin\n>     Installing easy_install-2.7 script\n> to /home/gk-dev/nova/.tox/py27/bin\n>   Running setup.py install for mccabe\n>     \n>   Running setup.py install for cffi\n>     Traceback (most recent call last):\n>       File \"<string>\", line 1, in <module>\n>       File \"/home/gk-dev/nova/.tox/py27/build/cffi/setup.py\", line 94,\n> in <module>\n>         from setuptools import setup, Feature, Extension\n>     ImportError: cannot import name Feature\n>     Complete output from\n> command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c \"import\n> setuptools;__file__=\'/home/gk-dev/nova/.tox/py27/build/cffi/setup.py\';exec(compile(open(__file__).read().replace(\'\\r\\n\', \'\\n\'), __file__, \'exec\'))\" install --record /tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed --install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7:\n>     Traceback (most recent call last):\n> \n> \n>   File \"<string>\", line 1, in <module>\n> \n> \n>   File \"/home/gk-dev/nova/.tox/py27/build/cffi/setup.py\", line 94, in\n> <module>\n> \n> \n>     from setuptools import setup, Feature, Extension\n> \n> \n> ImportError: cannot import name Feature\n> \n> \n> ----------------------------------------\n> Cleaning up...\n> Command /home/gk-dev/nova/.tox/py27/bin/python2.7 -c \"import\n> setuptools;__file__=\'/home/gk-dev/nova/.tox/py27/build/cffi/setup.py\';exec(compile(open(__file__).read().replace(\'\\r\\n\', \'\\n\'), __file__, \'exec\'))\" install --record /tmp/pip-2sWKRK-record/install-record.txt --single-version-externally-managed --install-headers /home/gk-dev/nova/.tox/py27/include/site/python2.7 failed with error code 1 in /home/gk-dev/nova/.tox/py27/build/cffi\n> Traceback (most recent call last):\n>   File \".tox/py27/bin/pip\", line 9, in <module>\n>     load_entry_point(\'pip==1.5.4\', \'console_scripts\', \'pip\')()\n>   File\n> \"/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/__init__.py\", line 148, in main\n>     parser.print_help()\n>   File\n> \"/home/gk-dev/nova/.tox/py27/local/lib/python2.7/site-packages/pip/basecommand.py\", line 169, in main\n>     log_file_fp.write(text)\n> UnicodeDecodeError: \'ascii\' codec can\'t decode byte 0xe2 in position\n> 72: ordinal not in range(128)\n> \n> \n> ERROR: could not install deps [-r/home/gk-dev/nova/requirements.txt,\n> -r/home/gk-dev/nova/test-requirements.txt]\n> \n> \n> Thanks\n> Gary\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CF3E6B7F.4C68B%gkotton@vmware.com>',NULL),('<1394125145.2933.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 10:59:05',-21600,'2014-03-06 16:59:05',NULL,'[openstack-dev] [Nova] Tox issues on a clean environment','On Thu, 2014-03-06 at 08:14 -0800, Gary Kotton wrote:\n> File \"/home/gk-dev/nova/.tox/py27/build/cffi/setup.py\", line 94, in\n> <module>\n> \n> \n>     from setuptools import setup, Feature, Extension\n> \n> \n> ImportError: cannot import name Feature\n\nApparently, quite recently, a new version of setuptools was released\nthat eliminated the Feature class.  From what I understand, the class\nhas been deprecated for quite a while, but the removal still seems to\nhave taken some consumers by surprise; we discovered it when a package\nthat uses MarkupSafe failed tests with the same error today.  We may\nhave to consider a short-term pin to the version of setuptools (if\nthat\'s even possible) on projects that encounter the problem?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CF3E6B7F.4C68B%gkotton@vmware.com>',NULL),('<1394128191.3326.19.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 12:49:51',-18000,'2014-03-06 17:49:51',NULL,'[openstack-dev] [Neutron][LBaaS] Mini-summit Interest?','On Thu, 2014-03-06 at 21:34 +0400, Eugene Nikanorov wrote:\n> If this happens, it might make sense to keep it before, not after the\n> summit.\n> Basically, on the summit we need to come up with a plan/design/roadmap\n> that everyone agrees on and just present it to the core team.\n\nIt depends. If the LBaaS summit is *after* the design summit, it can be\nmore of a working meeting where we take advantage of the time together\nto make a lot of progress on goals established (and documented) at the\nsummit. If it is *before* the summit, it is more likely to be less\nproductive and more of a brainstorming type meeting, which is kind of\nwhat the design summit is for.\n\nJust my two cents,\n-jay\n\n\n\n\n','<CAJfiwOR_hF9fHZSR4URd6M60D_09QSKz7qDV7mKRhSrMV_dPpQ@mail.gmail.com>',NULL),('<1394136620.3326.30.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 15:10:20',-18000,'2014-03-06 20:10:20',NULL,'[openstack-dev] [qa][nova] Ownership and path to schema\n definitions','On Thu, 2014-03-06 at 13:55 +1030, Christopher Yeoh wrote:\n> On Tue, 04 Mar 2014 13:31:07 -0500\n> David Kranz <dkranz at redhat.com> wrote:\n> > I think it would be a good time to have at least an initial\n> > discussion about the requirements for theses schemas and where they\n> > will live. The next step in tempest around this is to replace the\n> > existing negative test files with auto-gen versions, and most of the\n> > work in doing that is to define the schemas.\n> > \n> > The tempest framework needs to know the http method, url part,\n> > expected error codes, and payload description. I believe only the\n> > last is covered by the current nova schema definitions, with the\n> > others being some kind of attribute or data associated with the\n> > method that is doing the validation. Ideally the information being\n> > used to do the validation could be auto-converted to a more general\n> > schema that could be used by tempest. I\'m interested in what folks\n> > have to say about this and especially from the folks who are core\n> > members of both nova and tempest. See below for one example (note\n> > that the tempest generator does not yet handle \"pattern\").\n> \n> So as you\'ve seen a lot of what is wanted for the tempest framework is\n> implicitly known already within the method context which is why its not\n> again explicitly stated in the schema. Not actually having thought\n> about it a lot, but I suspect the expected errors decorator is\n> something that would fit just as well in the validation framework\n> however. \n> \n> Some of the other stuff such as url part, descriptions etc, not so much\n> as it would be purely duplicate information that would get out of date.\n> However for documentation auto generation it is something that we do\n> also want to have available in an automated fashion.  I did a bit of\n> exploration early in Icehouse in generating this within the context of\n> api samples tests where we have access to this sort of stuff and I think\n> together we\'d have all the info we need, I\'m just not sure mashing them\n> together is the right way to do it.\n\nJSON-Home is a perfect complement to JSONSchema in this regard. You\nwould expose the object model that underpins the request payload\nvalidation using JSONSchema. And you would expose the REST API contract\n(things like what HTTP methods are allowed, what parameters are allowed\nfor a method, what content-types are accepted, etc) using JSON-Home.\n\nSee Marconi for an example of using JSON-Home for API discovery:\n\nhttps://github.com/openstack/marconi/blob/master/marconi/queues/transport/wsgi/v1_1/homedoc.py\n\nSee Glance for an example of JSONSchema for object model discovery:\n\nhttps://github.com/openstack/glance/blob/master/glance/api/v2/image_members.py#L264\n\nBest,\n-jay\n\n> And from the documentation point of view we need to have a bit of a\n> think about whether doc strings on methods should be the canonical way\n> we produce descriptional information about API methods. One hand its\n> appealing, on the other hand they tend to be not very useful or very\n> internals Nova focussed. But we could get much better at it.\n> \n> Short version - yea I think we want to get to the point where tempest\n> doesn\'t generate these manually. But I\'m not sure about how we\n> should do it.\n> \n> Chris\n> \n> > \n> >   -David\n> > \n> >  From nova:\n> > \n> > get_console_output = {\n> >      \'type\': \'object\',\n> >      \'properties\': {\n> >          \'get_console_output\': {\n> >              \'type\': \'object\',\n> >              \'properties\': {\n> >                  \'length\': {\n> >                      \'type\': [\'integer\', \'string\'],\n> >                      \'minimum\': 0,\n> >                      \'pattern\': \'^[0-9]+$\',\n> >                  },\n> >              },\n> >              \'additionalProperties\': False,\n> >          },\n> >      },\n> >      \'required\': [\'get_console_output\'],\n> >      \'additionalProperties\': False,\n> > }\n> > \n> >  From tempest:\n> > \n> > {\n> >      \"name\": \"get-console-output\",\n> >      \"http-method\": \"POST\",\n> >      \"url\": \"servers/%s/action\",\n> >      \"resources\": [\n> >          {\"name\":\"server\", \"expected_result\": 404}\n> >      ],\n> >      \"json-schema\": {\n> >          \"type\": \"object\",\n> >          \"properties\": {\n> >              \"os-getConsoleOutput\": {\n> >                  \"type\": \"object\",\n> >                  \"properties\": {\n> >                      \"length\": {\n> >                          \"type\": [\"integer\", \"string\"],\n> >                          \"minimum\": 0\n> >                      }\n> >                  }\n> >              }\n> >          },\n> >          \"additionalProperties\": false\n> >      }\n> > }\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140306135513.05046c62@pingu>',NULL),('<1394138397.97076.YahooMailNeo@web164606.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 12:39:57',-28800,'2014-03-06 20:39:57',NULL,'[Openstack] Need advice - changing DB schema (nova-network)','Hi folks,\n\nI am working on nova-network in Havana. I have a very unique use case where I need to add duplicate VLANs in nova-network. I am trying to add multiple networks in nova-network with same VLAN ID. The reason is as follows:\n\nThe cluster that I have has an L3 backplane. We have been given a limitation that, per rack, we have a few networks with unique VLAN tags, and the VLAN tags repeat in every rack. So now, when I add networks in nova-network, I need to add these networks in same VLAN.?\n\nnova-network currently has a unique constraint on (\"vlan\", \"deleted\"). So to allow for duplicate VLANs in ?the DB, I am removing that unique constraint. I am modifying the migrate scripts to make sure that UC doesn\'t apply again on db_sync. ?I am also modifying the unit tests to reverse their sense (make sure that duplicate VLANs are allowed)\n\nAfter making these changes, I have verified following scenarios:\n1. Add networks with duplicate VLANs\n2. Update networks with duplicate VLANs\n3. db_sync doesn\'t revert back the constraint.\n4. VM comes up properly and I can ping it.?\n\nSince this is a DB schema change, I am a bit skeptical about it, and hence, looking for expert advice.\n\n1. How risky is it to make DB schema change?\n2. I know that I have to look out for any new migration scripts that touch that UC/Index. Anything else that I need to worry about w.r.t migration scripts?\n3. Any more scenarios I should be testing?\n\nThank you in advance!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/50ac7218/attachment.html>\n\n',NULL,NULL),('<1394138819.47094.YahooMailNeo@web164604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 12:46:59',-28800,'2014-03-06 20:46:59',NULL,'[openstack-dev] Fw: Need advice - changing DB schema (nova-network)','Hi folks,\n\n\n\nI am working on nova-network in Havana. I have a very unique use case where I need to add duplicate VLANs in nova-network. I am trying to add multiple networks in nova-network with same VLAN ID. The reason is as follows:\n\nThe cluster that I have has an L3 backplane. We have been given a limitation that, per rack, we have a few networks with unique VLAN tags, and the VLAN tags repeat in every rack. So now, when I add networks in nova-network, I need to add these networks in same VLAN.?\n\n\nnova-network currently has a unique constraint on (\"vlan\", \"deleted\"). So to allow for duplicate VLANs in ?the DB, I am removing that unique constraint. I am modifying the migrate scripts to make sure that UC doesn\'t apply again on db_sync. ?I am also modifying the unit tests to reverse their sense (make sure that duplicate VLANs are allowed)\n\nAfter making these changes, I have verified following scenarios:\n1. Add networks with duplicate VLANs\n2. Update networks with duplicate VLANs\n3. db_sync doesn\'t revert back the constraint.\n4. VM comes up properly and I can ping it.?\n\nSince this is a DB schema change, I am a bit skeptical about it, and hence, looking for expert advice.\n\n1. How risky is it to make DB schema change?\n2. I know that I have to look out for any new migration scripts that touch that UC/Index. Anything else that I need to worry about w.r.t migration scripts?\n3. Any more scenarios I should be testing?\n\nThank you in advance!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/91e3b92e/attachment.html>\n\n','<1394138219.13962.YahooMailNeo@web164606.mail.gq1.yahoo.com>',NULL),('<1394139172.52287.YahooMailNeo@web164604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 12:52:52',-28800,'2014-03-06 20:52:52',NULL,'[openstack-dev] Need advice - changing DB schema (nova-network)','Hi folks,\n\n\n\nI am working on nova-network in Havana. I have a very unique use case where I need to add duplicate VLANs in nova-network. I am trying to add multiple networks in nova-network with same VLAN ID. The reason is as follows:\n\nThe cluster that I have has an L3 backplane. We have been given a limitation that, per rack, we have a few networks with unique VLAN tags, and the VLAN tags repeat in every rack. So now, when I add networks in nova-network, I need to add these networks in same VLAN.?\n\n\nnova-network currently has a unique constraint on (\"vlan\", \"deleted\"). So to allow for duplicate VLANs in ?the DB, I am removing that unique constraint. I am modifying the migrate scripts to make sure that UC doesn\'t apply again on db_sync. ?I am also modifying the unit tests to reverse their sense (make sure that duplicate VLANs are allowed)\n\nAfter making these changes, I have verified following scenarios:\n1. Add networks with duplicate VLANs\n2. Update networks with duplicate VLANs\n3. db_sync doesn\'t revert back the constraint.\n4. VM comes up properly and I can ping it.?\n\nSince this is a DB schema change, I am a bit skeptical about it, and hence, looking for expert advice.\n\n1. How risky is it to make DB schema change?\n2. I know that I have to look out for any new migration scripts that touch that UC/Index. Anything else that I need to worry about w.r.t migration scripts?\n3. Any more scenarios I should be testing?\n\nThank you in advance!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/8a161584/attachment.html>\n\n',NULL,NULL),('<1394141477.3326.42.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 16:31:17',-18000,'2014-03-06 21:31:17',NULL,'[openstack-dev] [Neutron][LBaaS] Mini-summit Interest?','On Thu, 2014-03-06 at 21:14 +0000, Youcef Laribi wrote:\n> +1\n> \n> I think if we can have it before the Juno summit, we can take\n> concrete, well thought-out proposals to the community at the summit.\n\nUnless something has changed starting at the Hong Kong design summit\n(which unfortunately I was not able to attend), the design summits have\nalways been a place to gather to *discuss* and *debate* proposed\nblueprints and design specs. It has never been about a gathering to\nrubber-stamp proposals that have already been hashed out in private\nsomewhere else.\n\nOr, am I missing something? Has this changed in the past year?\n\nBest,\n-jay\n\n\n\n\n','<C942B6A1FE0D6645B46FC505B7255A1FDCC0F1@AMSPEX01CL02.citrite.net>',NULL),('<1394166990.3326.45.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 23:36:30',-18000,'2014-03-07 04:36:30',NULL,'[openstack-dev] [Nova] API weekly meeting','On Fri, 2014-03-07 at 11:15 +1030, Christopher Yeoh wrote:\n> Hi,\n> \n> I\'d like to start a weekly IRC meeting for those interested in\n> discussing Nova API issues. I think it would be a useful forum for:\n> \n> - People to keep up with what work is going on the API and where its\n>   headed. \n> - Cloud providers, SDK maintainers and users of the REST API to provide\n>   feedback about the API and what they want out of it.\n> - Help coordinate the development work on the API (both v2 and v3)\n> \n> If you\'re interested in attending please respond and include what time\n> zone you\'re in so we can work out the best time to meet.\n\nVery much interested. I\'ll make room in my schedule to attend most any\ntime other than 2-6am EST (7-11UTC).\n\nBest,\n-jay\n\n\n\n','<20140307111556.65a37711@pingu>',NULL),('<1394167119.3326.47.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-06 23:38:39',-18000,'2014-03-07 04:38:39',NULL,'[openstack-dev] [Nova] FFE Request: Ephemeral RBD image support','On Thu, 2014-03-06 at 19:28 -0800, Josh Durgin wrote:\n> On 03/06/2014 05:37 PM, Andrew Woodward wrote:\n> > Matt,\n> >\n> > I\'d love to see this too, however I\'m not seasoned enough to even know\n> > much about how to start implementing that. I\'d love some direction,\n> > and maybe some support after you guys are done with the pending\n> > release.\n> \n> We\'re working on setting up CI with Ceph starting with Cinder.\n> Jay Pipes\' recent blog posts explaining this process are great:\n> \n> http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n\nThanks for the shout-out. Andrew, Josh, and anyone else, please feel\nfree to attend the weekly IRC meeting (#openstack-meeting) at 18:00UTC\non Mondays. We use the hour as a workshop and Q&A session to help those\nstruggling to set things up.\n\nBest,\n-jay\n\n\n\n','<53193CF1.2050200@inktank.com>',NULL),('<1394170368.13369.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 13:32:48',28800,'2014-03-07 05:32:48',NULL,'[Openstack] swift recon query','Hello Steve,\n\nMy questions about swift recon are:\n\nQ1: what should be the curl command for recon?\n\nQ2. what arguments should I use with \'swift-recon\' command to get the status about\n? ? ? ? ? ? ? ? ? ?(i)? ? ? /proc/meminfo,\n? ? ? ? ? ? ? ? ? ?(ii)? ? currently mounted file systems\n? ? ? ? ? ? ? ? ? ?(iii)? ? list of devices\n\n\nQ3. When I run swift-recon command, It respond in terms of?low: <> high: <> avg: <> total: <> failed: <> no_result: <>\nFor example,\n \nroot at swift-VirtualBox:~# swift-recon\naccount --auditor \n=============================================================================== \n--> Starting reconnaissance on 4\nhosts \n=============================================================================== \n[2014-02-12 15:05:20] Checking auditor\nstats \n[account_auditor_pass_completed] low:\n0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported:\n1 \n[account_audits_passed] - No hosts\nreturned valid data. \n[account_audits_failed] - No hosts\nreturned valid data. \n[account_audits_since] - No hosts\nreturned valid data. \n\n\nWhat is the meaning of following terms: low,?high,?avg,?total, failed,?no_result, and reported ?\n\nThanks\nPragya Jain\n\n\n\nOn Thursday, 6 March 2014 9:14 PM, Steve Mayer <smayer69 at me.com> wrote:\n \nThe \'-a\' argument to swift-recon is for looking at the async-pendings, \n>which will only be available if you\'ve set up the \n>/usr/bin/swift-recon-cron job on the object server nodes.\n>\n>Try running with the \'-d\' or \'-l\' arguments to see some actual \n>statistics.\n>\n>-- \n>Steve Mayer\n>smayer69 at me.com\n>\n>On 6 Mar 2014, at 2:31, Drudy, Gerry wrote:\n>\n>> Add the verbose option to swift-recon:\n>>\n>> swift-recon -av\n>>\n>> It will list all the object servers in the ring.? Each server listed \n>> should have the object-server\n process running.\n>>\n>> Gerry.\n>>\n>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>> Sent: 06 March 2014 10:25\n>> To: Drudy, Gerry; openstack at lists.openstack.org\n>> Subject: Re: [Openstack] swift recon query\n>>\n>> hi Gerry,\n>>\n>> I run following commands:\n>> root at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/async\n>> curl: (7) couldn\'t\n connect to host\n>> root at swift-VirtualBox:~# swift-recon -a\n>> ===============================================================================\n>> --> Starting reconnaissance on 4 hosts\n>> ===============================================================================\n>> [2014-03-06 15:51:14] Checking async pendings\n>> [async_pending] - No hosts returned valid data.\n>> ===============================================================================\n>> I can\'t understand where is the problem\n>>\n>> Please help.\n>>\n>> Thanks\n>> Pragya jain\n>>\n>> On Thursday, 6 March 2014 2:38 PM, \"Drudy, Gerry\"\n <Gerry.Drudy at hp.com> \n>> wrote:\n>> Try\n>>\n>> curl? -i http://127.0.0.1:6000/recon/async\n>>\n>> assuming 6000 is the port the object-server binds to.\n>>\n>> Gerry,\n>>\n>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>> Sent: 06 March 2014 06:58\n>> To: openstack at lists.openstack.org\n>> Subject: Re: [Openstack] swift recon query\n>>\n>> please somebody answer my questions related to swift recon.\n>>\n>> Thanks\n>>\n>> Pragya Jain\n>>\n>> On Wednesday, 5 March 2014 2:31 PM, pragya jain \n>> <prag_2648 at yahoo.co.in> wrote:\n>> hello all,\n>>\n>> I have some basic questions about swift recon. please query them.\n>>\n>> Q1: what should be the curl command for recon?\n>>\n>> I use the following commands:\n>> 1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>>\n>> HTTP/1.1 401 Unauthorized\n>> Content-Length: 131\n>> Content-Type: text/html; charset=UTF-8\n>> Www-Authenticate: Swift realm=\"async\"\n>> X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n>> Date: Wed, 05 Mar 2014 08:43:17 GMT\n>>\n>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>> are authorized to access the document you requested.</p></html>\n>>\n>> 2.? root at swift-VirtualBox:~# curl -i \n>> http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>>\n>> HTTP/1.1 401 Unauthorized\n>> Content-Length: 131\n>> Content-Type: text/html; charset=UTF-8\n>> Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n>> X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n>> Date: Wed, 05 Mar 2014 08:45:24 GMT\n>>\n>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>> are authorized to access the document you requested.</p></html>\n>>\n>> Q2. Does \'swift-recon\' command not provide the status about\n>>? ? ? ? ? ? ? ? ? ?  (i)? ? ? /proc/meminfo,\n>>? ? ? ? ? ? ? ? ?\n ?  (ii)? ?  currently mounted file systems\n>>? ? ? ? ? ? ? ? ? ?  (iii)? ? list of devices\n>>? ? if \'swift-recon\' provides these informations, then what should be \n>> the command?\n>>\n>> Q3. It stands for what?\n>>? ? ? ? ? low\n>>? ? ? ? ? high\n>>? ? ? ? ? avg\n>>? ? ? ? ? total\n>>? ? ? ? ? failed\n>>? ? ? ? ? no_result\n>>? ? ? ? ? reported\n>>\n>> Pragya Jain\n>>\n>>\n>>\n _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to? ?  : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140307/aaa5d856/attachment-0001.html>\n\n','<12C4262B-FC1E-4B88-8F6A-0C68CB50EB46@me.com>',NULL),('<1394209651.15413.6.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 16:27:31',0,'2014-03-07 16:27:31',NULL,'[Openstack] Designate + Postges error','Hi Nick,\n\nThis looks like a bug in our PowerDNS backend driver.\n\nI *think* this is the offending line:\n\n    https://github.com/stackforge/designate/blob/master/designate/backend/impl_powerdns/__init__.py#L449\n\nWe generally use MySQL, which must just cast it to a bool, while Postgres gives out about the type.\n\nOn Fri, 2014-03-07 at 18:00 +0200, Nick Maslov wrote:\nHi,\n\n\nI have installed Designate with Postgres backend. Database initialisation went fine, but when I try to add servers it freaks out like this:\n\n\n2014-03-07 15:57:00.478 3482 TRACE designate.api.middleware Backend: Unknown backend failure: ProgrammingError(\'(ProgrammingError) column \"auth\" is of type boolean but expression is of type integer\\nLINE 1: ...f8c573e02bc4b\\\', domains.name, \\\'NS\\\', \\\'ns1.example.org\\\', 1, 1 \\n\n\n\n\n\nFull stack trace is here - http://pastebin.com/Qi0JipGs\n\n\nIs anyone knows whats that?\n\n\nCheers,\nNM\n\n--\nNick Maslov\nSent with Airmail\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<etPan.5319ed12.6b8b4567.494a@mbp>',NULL),('<1394248889.859784890@f75.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-08 07:21:29',14400,'2014-03-08 03:21:29',NULL,'[Openstack] Companies Offering Paid Support?','\nHello,\n\nFor Swift setup I suggest Swiftstack, we once got the help from them, they are nice.\nFor more other companies you may take a look:\nhttp://www.openstack.org/foundation/companies/\n\n--\nlooking for cloud developers: \nhttp://www.nsbeta.info/jobs\n\n\nFriday, March  7, 2014 9:53 AM -08:00 from Adam Lawson <alawson at aqorn.com>:\n>Are there any companies offering subscription or incident-based OpenStack support for private clouds that aren\'t using a specific packaged distro such as Piston, CloudScaling, StackOps or Fuel?\n>\n>Just wondering if there are companies that will help someone get through a problem or assist them with a manual-installed special deployment like a standalone HA Swift cluster or some other config that doesn\'t necessarily fit into the default mold.\n>\n>Are there companies doing this? I have only found Rackspace and waiting for pricing/confirmation of their service. Just wondering if there is anyone else doing this?\n>\n>\n>Adam Lawson\n>AQORN, Inc.\n>427 North Tatnall Street\n>Ste. 58461\n>Wilmington, Delaware 19801-2230\n>Toll-free: (888) 406-7620\n>\n>_______________________________________________\n>Mailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to     :  openstack at lists.openstack.org\n>Unsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140308/f483a3a4/attachment.html>\n\n','<CAJfWK49R0GabsSvnPkdg+Jj=9BwEuOss-AW9+OiPX7pHriys6A@mail.gmail.com>',NULL),('<1394398076.3197.10.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-09 16:47:56',-14400,'2014-03-09 20:47:56',NULL,'[openstack-dev] [nova][db] Thoughts on making instances.uuid\n non-nullable?','Hi Matt, interesting questions/points. Some comments inline.\n\nOn Sun, 2014-03-09 at 15:20 -0500, Matt Riedemann wrote:\n> <snip>\n> I\'ve been working on this more and am running up against some issues, \n> part of this has to do with my lack of sqlalchemy know-how and \n> inexperience with writing DB migrations, so dumping some info/problems \n> here to see where people would like me to take this.\n> \n> My original thinking for doing a migration was to delete the instances \n> records where uuid == None and then move those to shadow_instances, then \n> make instances.uuid.nullable=False.  Some of the problems with this \n> approach are:\n> \n> 1. There are at least 5 other tables related to instances that need to \n> be handled for a delete: InstanceFault, InstanceMetadata, \n> InstanceSystemMetadata, InstanceInfoCache and \n> SecurityGroupInstanceAssociation. Also, these tables don\'t define their \n> instance_uuid column the same way, some have it nullable=False and \n> others don\'t.\n\nAll tables should define the instance uuid column in the same way, and\nmaking that consistent should best be done as part of the same\nmigration. The reasoning, of course, is that these columns represent\nidentical data (primary to child key relations), and therefore the\nschema of all the columns should be identical.\n\n> 2. I\'m not sure if I can use a session in the migration to make it a \n> transaction.\n\nYou can use a transaction around all statements, including DDL, in\nPostgreSQL. In MySQL, you can use a transaction only around DML\nstatements, but any DDL statement will cause a flush of all transactions\nbefore the DDL statement begins.\n\nI\'d recommend doing all of the necessary \"moves\" of records (between the\nshadow tables and regular tables) within a single transaction so that at\nleast there is some level of data consistency ensured for those\noperations. But, unfortunately, the DDL schema changes will not occur\nwithin a transaction unless you are using PostgreSQL and Alembic\nmigrations.\n\n> 3. This would make the instances and shadow_instances tables have \n> different schemas, i.e. instances.uuid would be nullable=False in \n> instances but nullable=True in shadow_instances.  Maybe this doesn\'t matter.\n\nNo, I don\'t think this matters much, to be honest. I\'m not entirely sure\nwhat the long-term purpose of the shadow tables are in Nova -- perhaps\nsomeone could clue me in to whether the plan is to keep them around?\n\n> The whole reason behind using shadow_instances (or any backup table I \n> guess) was so I could restore the records on DB downgrade.\n> \n> So the more I think about this, I\'m getting to the point of asking:\n> \n> 1. Do we even care about instances where uuid is None?  I\'d have to \n> think those wouldn\'t be working well in the current code with how \n> everything relies on uuid for foreign keys and tracking relationships to \n> volumes, images and networks across services.  \n\nAgreed. I don\'t personally think instance records with no UUID are\nuseful in Nova any more.\n\n> If the answer is \'no\' \n> then the migration is pretty simple, just delete the records where uuid \n> is None and be done with it.  You couldn\'t downgrade to get them back, \n> but in this case we\'re asserting that we don\'t want them back.\n\nThis is exactly what I would recommend.\n\n> 2. Have an alternative schema in the DB2 case. This would be handled in \n> the 216_havana migration when the instances table is defined and \n> created, we\'d just make the uuid column non-nullable in the DB2 case and \n> leave it nullable for all other engines.  Anyone moving to DB2 would \n> have to install from scratch anyway since there is no tooling to migrate \n> a MySQL DB to DB2, for example.  As it stands, the 216_havana migration \n> in my patch [1] already has a different schema for DB2 because of the \n> foreign keys it can\'t create due to this problem.\n\nNah, I don\'t think we want to keep a special schema just for DB2. That\'s\ntechnical debt that I don\'t think it worthwhile to keep around...\n\nBest,\n-jay\n\n> Anyway, looking for some thoughts on how to best handle this, or if \n> anyone has other ideas or good reasons why either approach couldn\'t be used.\n> \n> [1] https://review.openstack.org/#/c/69047/\n> \n\n\n\n\n','<531CCD01.205@linux.vnet.ibm.com>',NULL),('<1394411561627.9bd4c254@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-09 17:32:42',-25200,'2014-03-10 00:32:42',NULL,'[openstack-dev] [Neutron][IPv6][Security Group] BP: Support\n ICMP type filter by security group','Thanks all for your comments! Do you guys think we can have a summit session to discuss the next steps? I can prepare a spec if needed.\n\n\nThanks,\n\nXuhan\n?\nXu Han Peng (xuhanp)\n\nOn Sat, Mar 8, 2014 at 3:19 AM, Akihiro Motoki <amotoki at gmail.com> wrote:\n\n> Hi Robert,\n> Thanks for the clarification. I understand the motivation.\n> I think the problem can be split into two categories:\n> (a) user configurable rules vs infra enforced rule, and\n> (b) DHCP/RA service exists inside or outside of Neutron\n> Regarding (a), I believe DHCP or RA related rules is better to be handled\n> by the infra side because it is required to ensure DHCP/RA works well.\n> I don\'t think it is a good idea to delegate users to configure rule to\n> allow them.\n> It works as long as DHCP/RA service works inside OpenStack.\n> This is the main motivation of my previous question.\n> On the other hand, there is no way to cooperate with DHCP/RA\n> services outside of OpenStack at now. This blocks the usecase in your mind.\n> It is true that the current Neutron cannot works with dhcp server\n> outside of neutron.\n> I agree that adding a security group rule to allow RA is reasonable as\n> a workaround.\n> However, for a long time solution, it is better to explore a way to configure\n> infra-required rules.\n> Thanks,\n> Akihiro\n> On Sat, Mar 8, 2014 at 12:50 AM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> Hi Akihiro,\n>>\n>> In the case of IPv6 RA, its source IP is a Link Local Address from the\n>> router\'s RA advertising interface. This LLA address is automatically\n>> generated and not saved in the neutron port DB. We are exploring the idea\n>> of retrieving this LLA if a native openstack RA service is running on the\n>> subnet.\n>>\n>> Would SG be needed with a provider net in which the RA service is running\n>> external to openstack?\n>>\n>> In the case of IPv4 DHCP, the dhcp port is created by the dhcp service,\n>> and the dhcp server ip address is retrieved from this dhcp port. If the\n>> dhcp server is running outside of openstack, and if we\'d only allow dhcp\n>> packets from this server, how is it done now?\n>>\n>> thanks,\n>> Robert\n>>\n>> On 3/7/14 12:00 AM, \"Akihiro Motoki\" <amotoki at gmail.com> wrote:\n>>\n>>>I wonder why RA needs to be exposed by security group API.\n>>>Does a user need to configure security group to allow IPv6 RA? or\n>>>should it be allowed in infra side?\n>>>\n>>>In the current implementation DHCP packets are allowed by provider\n>>>rule (which is hardcoded in neutron code now).\n>>>I think the role of IPv6 RA is similar to DHCP in IPv4. If so, we\n>>>don\'t need to expose RA in security group API.\n>>>Am I missing something?\n>>>\n>>>Thanks,\n>>>Akihiro\n>>>\n>>>On Mon, Mar 3, 2014 at 10:39 PM, Xuhan Peng <pengxuhan at gmail.com> wrote:\n>>>> I created a new blueprint [1] which is triggered by the requirement to\n>>>>allow\n>>>> IPv6 Router Advertisement security group rule on compute node in my\n>>>>on-going\n>>>> code review [2].\n>>>>\n>>>> Currently, only security group rule direction, protocol, ethertype and\n>>>>port\n>>>> range are supported by neutron security group rule data structure. To\n>>>>allow\n>>>> Router Advertisement coming from network node or provider network to VM\n>>>>on\n>>>> compute node, we need to specify ICMP type to only allow RA from known\n>>>>hosts\n>>>> (network node dnsmasq binded IP or known provider gateway).\n>>>>\n>>>> To implement this and make the implementation extensible, maybe we can\n>>>>add\n>>>> an additional table name \"SecurityGroupRuleData\" with Key, Value and ID\n>>>>in\n>>>> it. For ICMP type RA filter, we can add key=\"icmp-type\" value=\"134\", and\n>>>> security group rule to the table. When other ICMP type filters are\n>>>>needed,\n>>>> similar records can be stored. This table can also be used for other\n>>>> firewall rule key values.\n>>>> API change is also needed.\n>>>>\n>>>> Please let me know your comments about this blueprint.\n>>>>\n>>>> [1]\n>>>>\n>>>>https://blueprints.launchpad.net/neutron/+spec/security-group-icmp-type-f\n>>>>ilter\n>>>> [2] https://review.openstack.org/#/c/72252/\n>>>>\n>>>> Thank you!\n>>>> Xuhan Peng\n>>>>\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>\n>>>\n>>>_______________________________________________\n>>>OpenStack-dev mailing list\n>>>OpenStack-dev at lists.openstack.org\n>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140309/9c39e8f9/attachment.html>\n\n','<CALhU9tm-XkLn9aesThmWpFU_HCCR+Z6bzm7ZVQmBswqAqzCHXw@mail.gmail.com>',NULL),('<1394415352.12365864.1395743524381.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 11:32:04',3600,'2014-03-25 10:32:04',NULL,'[openstack-dev] [Murano][Heat] MuranoPL questions?','\n> Hi Thomas,\n> \n> I think we went to the second loop of the discussion about generic language\n> concepts. Murano does not use a new language for the sole purpose of having\n> parameters, constraints and polymorphism. These are generic concepts which\n> are common for different languages, so keeping arguing about these generic\n> concepts is just like a holy war like Python vs. C. Keeping these arguments\n> is just like to say that we don\'t need Python as functions and parameters\n> already exists in C which is used under the hood in Python.\n> \n> Yes Murano DSL have some generic concepts similar to HOT. I think this is a\n> benefit as user will see the familiar syntax constructions and it will be a\n> lower threshold for him to start using Murano DSL.\n> \n> In a simplified view Murano uses DSL for application definition to solve\n> several particular problems:\n> a) control UI rendering of Application Catalog\n> b) control HOT template generation\n> \n> These aspects are not covered in HOT and probably should not be covered. I\n> don\'t like an idea of expressing HOT template generation in HOT as it sounds\n> like a creation another Lisp like language :-)\n\nI\'m not saying that HOT will cover all your needs. I think it will cover a really good portion. And I\'m saying that for the remaining part, you can use an existing language and not create a new one.\n\n> I don\'t think that your statement that most of the people in the community\n> are against new DSL is a right summary. There are some disagreements how it\n> should look like and what are the goals. You will be probably surprised but\n> we are not the first who use DSL for HOT templates generation. Here is an\n> e-mail thread right about Ruby based DSL used in IBM for the same purpose:\n> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html\n> \n> The term \"Orchestration\" is quite generic. Saying that orchestration should\n> be Heat job sounds like a well know Henry Ford\'s phrase \"You can have any\n> colour as long as it\'s black.\".\n\nThat worked okay for him :).\n\n> I think this is again a lack of understanding of the difference between\n> Orchestration program and Heat project. There are many aspects of\n> Orchestration and OpenStack has the Orchestration program for the projects\n> which are focused on some aspects of orchestration. Heat is one of the\n> project inside Orchestration program but it does not mean that Heat should\n> cover everything. That is why we discussed in this thread how workflows\n> aspects should be aligned and how they should be placed into this\n> Orchestration program.\n\nWell, today Heat is the one and only program in the Orchestration program. If and when you have orchestration needs not covered, we are there to make sure Heat is not the best place to handle them. The answer will probably not Heat forever, but we need good use cases to delegate those needs to another project.\n\n\n-- \nThomas\n\n\n','<CAG_6_okJ=FeZEC7GSjkZvjaa2M=VTXibbpd1HiiYGzrUONrroA@mail.gmail.com>',NULL),('<1394417913.3197.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-09 22:18:33',-14400,'2014-03-10 02:18:33',NULL,'[openstack-dev] [nova][db] Thoughts on making instances.uuid\n non-nullable?','On Mon, 2014-03-10 at 10:05 +0800, ChangBo Guo wrote:\n> \n> \n> \n> 2014-03-10 4:47 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:\n>         \n>         \n>         > 3. This would make the instances and shadow_instances tables\n>         have\n>         > different schemas, i.e. instances.uuid would be\n>         nullable=False in\n>         > instances but nullable=True in shadow_instances.  Maybe this\n>         doesn\'t matter.\n>         \n>         \n>         No, I don\'t think this matters much, to be honest. I\'m not\n>         entirely sure\n>         what the long-term purpose of the shadow tables are in Nova --\n>         perhaps\n>         someone could clue me in to whether the plan is to keep them\n>         around?\n>         \n>         \n> As I know the tables shadow_*  are used  by command \' nova-manage db\n> archive_deleted_rows\' , which moves  records with \"deleted=True\" to\n> table shadow_* . That means these tables are used by other  process,\n> So, I think we need other tables to store the old records in your\n> migration.\n\nYeah, that\'s what I understood the shadow tables were used for, I just\ndidn\'t know what the long-term future of these tables was... curious if\nthere\'s been any discussion about that.\n\nBest,\n-jay\n\n\n\n\n','<CANWmB0Wr9m9hiud-HhzartykHfRYo_x4WfzoOxbZD5GxU=Hs9g@mail.gmail.com>',NULL),('<1394436748.81447.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-10 15:32:28',28800,'2014-03-10 07:32:28',NULL,'[Openstack] query about Statsd','please somebody answer my questions so that I can come out the confusion.\n\nThanks?\nPragya Jain\n\n\n\nOn Thursday, 6 March 2014 4:06 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>\n>\n>I have some questions about?Statsd server for openstack swift\n>\n>\n>Q1: ?Is swift-informant middleware necessary to be included in proxy-server.conf in order to provide metrics to StatsD server?\n>\n>\n>Q2: what type of metrics does?swift-informant middleware?provide to StatsD server?\n>\n>\n>Q3: ?What is StatsDlog? Is it a middleware or a daemon or something other? And, What type of metrics does it?provide to StatsD server?\n>\n>\n>I had searched many documents, but I still have confusion about it.\n>Please somebody answer my questions.\n>\n>\n>Thanks?\n>Pragya jain\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to? ?  : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140310/4dc71d5b/attachment.html>\n\n','<1394102193.62074.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1394437958.83783.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-10 15:52:38',28800,'2014-03-10 07:52:38',NULL,'[Openstack] difference between metrics to statsd and metrics\n	provided by swift recon middleware','hello all,\naccording to the documents, statsd server collects the following metrics about account-auditor:\nMetric Name Description account-auditor.errors Count of audit runs (across all account databases) which caught an Exception. account-auditor.passes Count of individual account databases which passed audit. account-auditor.failures Count of individual account databases which failed audit. account-auditor.timing Timing data for individual account database audits.\nand, swift recon middleware provides following information about account-auditor: ? account_auditor_pass_completed ? account_audits_passed ? account_audits_failed ? account_audits_since\nplease somebody help me to understand what is the similarity and what is the difference between the metrics collected by statsd server and metrics provided by swift recon middleware.\nThanks?\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140310/2e9481aa/attachment.html>\n\n',NULL,NULL),('<1394467182.3197.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 11:59:42',-14400,'2014-03-10 15:59:42',NULL,'[openstack-dev] [3rd party testing] Q&A meeting today at 14:00 EST\n	/ 18:00 UTC','Hi Stackers,\n\nWe\'ll be having our second weekly Q&A/workshop session around third\nparty testing today at 14:00 EST / 18:00 UTC in #openstack-meeting on\nFreenode IRC. See you all there.\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1394467182.3197.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-10 11:59:42',-14400,'2014-03-10 15:59:42',NULL,'[OpenStack-Infra] [3rd party testing] Q&A meeting today at 14:00\n	EST / 18:00 UTC','Hi Stackers,\n\nWe\'ll be having our second weekly Q&A/workshop session around third\nparty testing today at 14:00 EST / 18:00 UTC in #openstack-meeting on\nFreenode IRC. See you all there.\n\nBest,\n-jay\n\n\n\n',NULL,NULL),('<1394473644-sup-9833@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 10:53:13',-25200,'2014-03-10 17:53:13',NULL,'[openstack-dev] [Heat] [Keystone] Where are the strings in the\n	keystone API\'s defined?','While looking into this bug:\n\nhttps://bugs.launchpad.net/heat/+bug/1290274\n\nI was trying to find out why the original developers felt that tenant_ids\nshould be a \'varchar(256)\'. In addition to moving from a regular varchar\ninto a text field, varchar(256) in MySQL will become a tinytext which\ncauses all sorts of performance issues, this just seems a _lot_ bigger\nthan anything I\'ve ever seen shown as a tenant/project id. I\'d expect at\nworst varchar(64). Also it is probably safe to store as varbinary since\nwe don\'t ever sort on it or store case-insensitive equivalents to it.\n\nSo I was wondering where users can go to find out what to expect in\nthat field. I dug through the API documentation for Keystone and I see\nnothing that really would constituate a format or even length. But maybe\nI\'m just not looking in the right place. Thanks!\n\n\n',NULL,NULL),('<1394479193.3197.20.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 15:19:53',-14400,'2014-03-10 19:19:53',NULL,'[openstack-dev] [nova] a question about instance snapshot','On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:\n> We have very strong interest in pursing this feature in the VMware\n> driver as well. I would like to see the revert instance feature\n> implemented at least.\n> \n> When I used to work in multi-discipline roles involving operations it\n> would be common for us to snapshot a vm, run through an upgrade\n> process, then revert if something did not upgrade smoothly. This\n> ability alone can be exceedingly valuable in long-lived virtual\n> machines.\n> \n> I also have some comments from parties interested in refactoring how\n> the VMware drivers handle snapshots but I\'m not certain how much that\n> plays into this \"live snapshot\" discussion.\n\nI think the reason that there isn\'t much interest in doing this kind of\nthing is because the worldview that VMs are pets is antithetical to the\nworldview that VMs are cattle, and Nova tends to favor the latter (where\nDRS/DPM on vSphere tends to favor the former).\n\nThere\'s nothing about your scenario above of being able to \"revert\" an\ninstance to a particular state that isn\'t possible with today\'s Nova.\nSnapshotting an instance, doing an upgrade of software on the instance,\nand then restoring from the snapshot if something went wrong (reverting)\nis already fully possible to do with the regular Nova snapshot and\nrestore operations. The only difference is that the \"live-snapshot\"\nstuff would include saving the memory view of a VM in addition to its\ndisk state. And that, at least in my opinion, is only needed when you\nare treating VMs like pets and not cattle.\n\nBest,\n-jay\n\n> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky) <bohai at huawei.com> wrote:\n> >> -----Original Message-----\n> >> From: Alex Xu [mailto:xuhj at linux.vnet.ibm.com]\n> >> Sent: Sunday, March 09, 2014 10:04 PM\n> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot\n> >>\n> >> Hi, Jeremy, the discussion at here\n> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html\n> >>\n> >\n> > I have a great interest in the topic too.\n> > I read the link you provided, and there is a little confusion for me.\n> > I agree with the security consideration in the discussion and memory snapshot can\'t be used for the cloning instance easily.\n> >\n> > But I think it\'s safe for the using for Instance revert.\n> > And revert the instance to a checkpoint is valuable for the user.\n> > Why we didn\'t use it for instance revert in the first step?\n> >\n> > Best regards to you.\n> > Ricky\n> >\n> >> Thanks\n> >> Alex\n> >> On 2014?03?07? 10:29, Liuji (Jeremy) wrote:\n> >> > Hi, all\n> >> >\n> >> > Current openstack seems not support to snapshot instance with memory and\n> >> dev states.\n> >> > I searched the blueprint and found two relational blueprint like below.\n> >> > But these blueprint failed to get in the branch.\n> >> >\n> >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots\n> >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms\n> >> >\n> >> > In the blueprint[1], there is a comment,\"\n> >> > We discussed this pretty extensively on the mailing list and in a design\n> >> summit session.\n> >> > The consensus is that this is not a feature we would like to have in nova.\n> >> --russellb \"\n> >> > But I can\'t find the discuss mail about it. I hope to know why we think so ?\n> >> > Without memory snapshot, we can\'t to provide the feature for user to revert\n> >> a instance to a checkpoint.\n> >> >\n> >> > Anyone who knows the history can help me or give me a hint how to find the\n> >> discuss mail?\n> >> >\n> >> > I am a newbie for openstack and I apologize if I am missing something very\n> >> obvious.\n> >> >\n> >> >\n> >> > Thanks,\n> >> > Jeremy Liu\n> >> >\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >> >\n> >> >\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n\n','<CAL+QrDrJmOZTmAegunP1C-9HnWQnoksrzX4FW5D_Ge993a59Zg@mail.gmail.com>',NULL),('<1394481383-sup-9435@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 12:57:09',-25200,'2014-03-10 19:57:09',NULL,'[openstack-dev] [Heat] [Keystone] Where are the strings in the\n	keystone API\'s defined?','Excerpts from Dolph Mathews\'s message of 2014-03-10 12:43:52 -0700:\n> For posterity, I assume this thread is related to:\n> \n> \n> http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html\n> \n> Anyway, keystone itself has issued 36-char tenant ID\'s in the past (diablo,\n> I believe, if not essex as well). Something like this:\n> \n>   $ python -c \"import uuid; s = str(uuid.uuid4()); print s; print len(s);\"\n>   1b54024b-7c62-494e-9a34-6138e04e3dc7\n>   36\n> \n> Migrations to essex also pulled in existing tenant ID\'s from other\n> pre-existing data sources. Most importantly, keystone is able to read\n> tenants from backends such as LDAP, and you\'re welcome to write your own\n> driver and return whatever data you want as an ID.\n> \n> From an API perspective, keystone assumes that tenant ID\'s are URL-safe and\n> globally unique, but does nothing to enforce either of those. Perhaps\n> that\'s somewhere keystone could start (emit a warning if that\'s not the\n> case?), before other services make stricter assumptions about the\n> constraints around tenant ID\'s.\n\nSo, are you saying varchar(256) may be _too small_ ?\n\n\n','<CAC=h7gVdDEaw_Kf8rryFOTXBh9xNBON3oayxNUao2nwp3i2c_Q@mail.gmail.com>',NULL),('<1394485104.3197.35.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 16:58:24',-14400,'2014-03-10 20:58:24',NULL,'[openstack-dev] [nova] a question about instance snapshot','On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:\n> While I understand the general argument about pets versus cattle. The\n> question is, would you be willing to poke a few holes in the strict\n> \"cattle\" abstraction for the sake of pragmatism. Few shops are going\n> to make the direct transition in one move. Poking a hole in the cattle\n> abstraction allowing them to keep a pet VM might be very valuable to\n> some shops making a migration.\n\nPoking holes in cattle aside, my experience with shops that prefer the\npets approach is that they are either:\n\n * Not managing their servers themselves at all and just relying on some\nIT operations organization to manage everything for them, including all\naspects of backing up their data as well as failing over and balancing\nservers, or,\n * Hiding behind rationales of \"needing to be secure\" or \"needing 100%\nuptime\" or \"needing no customer disruption\" in order to avoid any change\nto the status quo. This is because the incentives inside legacy IT\napplication development and IT operations groups are typically towards\nnot rocking the boat in order to satisfy unrealistic expectations and\noutdated interface agreements that are forced upon them by management\nchains that haven\'t crawled out of the waterfall project management funk\nof the 1980s.\n\nAdding pet-based features to Nova would, IMO, just perpetuate the above\nscenarios and incentives.\n\n> To be fair, the places where I\'ve heard interest are looking to \"walk\n> not run\" from a pets approach to a cattle approach. This conceit in\n> the abstraction might be valuable enough to them to spell the\n> difference between cautiously adopting and tacitly rejecting\n> OpenStack.\n> \n> That\'s how I would argue *for* the change anyhow, it\'s not an argument\n> based on ideology but on pragmatism.\n\nYeah, I understand your point, and I do see how it might lead some folks\ntowards OpenStack.\n\nBut then again, I wouldn\'t port a bunch of Prolog language constructs\nand quirks to Python just to lure Prolog and Erlang developers.\n\nIn the end, I know I\'m probably just over-zealous on this stuff, but I\njust can\'t help it :)\n\nBest,\n-jay\n\n> On Mon, Mar 10, 2014 at 3:19 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:\n> >> We have very strong interest in pursing this feature in the VMware\n> >> driver as well. I would like to see the revert instance feature\n> >> implemented at least.\n> >>\n> >> When I used to work in multi-discipline roles involving operations it\n> >> would be common for us to snapshot a vm, run through an upgrade\n> >> process, then revert if something did not upgrade smoothly. This\n> >> ability alone can be exceedingly valuable in long-lived virtual\n> >> machines.\n> >>\n> >> I also have some comments from parties interested in refactoring how\n> >> the VMware drivers handle snapshots but I\'m not certain how much that\n> >> plays into this \"live snapshot\" discussion.\n> >\n> > I think the reason that there isn\'t much interest in doing this kind of\n> > thing is because the worldview that VMs are pets is antithetical to the\n> > worldview that VMs are cattle, and Nova tends to favor the latter (where\n> > DRS/DPM on vSphere tends to favor the former).\n> >\n> > There\'s nothing about your scenario above of being able to \"revert\" an\n> > instance to a particular state that isn\'t possible with today\'s Nova.\n> > Snapshotting an instance, doing an upgrade of software on the instance,\n> > and then restoring from the snapshot if something went wrong (reverting)\n> > is already fully possible to do with the regular Nova snapshot and\n> > restore operations. The only difference is that the \"live-snapshot\"\n> > stuff would include saving the memory view of a VM in addition to its\n> > disk state. And that, at least in my opinion, is only needed when you\n> > are treating VMs like pets and not cattle.\n> >\n> > Best,\n> > -jay\n> >\n> >> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky) <bohai at huawei.com> wrote:\n> >> >> -----Original Message-----\n> >> >> From: Alex Xu [mailto:xuhj at linux.vnet.ibm.com]\n> >> >> Sent: Sunday, March 09, 2014 10:04 PM\n> >> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot\n> >> >>\n> >> >> Hi, Jeremy, the discussion at here\n> >> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html\n> >> >>\n> >> >\n> >> > I have a great interest in the topic too.\n> >> > I read the link you provided, and there is a little confusion for me.\n> >> > I agree with the security consideration in the discussion and memory snapshot can\'t be used for the cloning instance easily.\n> >> >\n> >> > But I think it\'s safe for the using for Instance revert.\n> >> > And revert the instance to a checkpoint is valuable for the user.\n> >> > Why we didn\'t use it for instance revert in the first step?\n> >> >\n> >> > Best regards to you.\n> >> > Ricky\n> >> >\n> >> >> Thanks\n> >> >> Alex\n> >> >> On 2014?03?07? 10:29, Liuji (Jeremy) wrote:\n> >> >> > Hi, all\n> >> >> >\n> >> >> > Current openstack seems not support to snapshot instance with memory and\n> >> >> dev states.\n> >> >> > I searched the blueprint and found two relational blueprint like below.\n> >> >> > But these blueprint failed to get in the branch.\n> >> >> >\n> >> >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots\n> >> >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms\n> >> >> >\n> >> >> > In the blueprint[1], there is a comment,\"\n> >> >> > We discussed this pretty extensively on the mailing list and in a design\n> >> >> summit session.\n> >> >> > The consensus is that this is not a feature we would like to have in nova.\n> >> >> --russellb \"\n> >> >> > But I can\'t find the discuss mail about it. I hope to know why we think so ?\n> >> >> > Without memory snapshot, we can\'t to provide the feature for user to revert\n> >> >> a instance to a checkpoint.\n> >> >> >\n> >> >> > Anyone who knows the history can help me or give me a hint how to find the\n> >> >> discuss mail?\n> >> >> >\n> >> >> > I am a newbie for openstack and I apologize if I am missing something very\n> >> >> obvious.\n> >> >> >\n> >> >> >\n> >> >> > Thanks,\n> >> >> > Jeremy Liu\n> >> >> >\n> >> >> >\n> >> >> > _______________________________________________\n> >> >> > OpenStack-dev mailing list\n> >> >> > OpenStack-dev at lists.openstack.org\n> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >\n> >> >> >\n> >> >> >\n> >> >>\n> >> >>\n> >> >> _______________________________________________\n> >> >> OpenStack-dev mailing list\n> >> >> OpenStack-dev at lists.openstack.org\n> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >>\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n\n','<CAL+QrDq-=0NVaxELfjBEO9oEmEKNTCCcyrqW1uBke1mu0kT9TQ@mail.gmail.com>',NULL),('<1394488733.3197.46.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 17:58:53',-14400,'2014-03-10 21:58:53',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n soft deletion (step by step)','On Tue, 2014-03-11 at 01:29 +0400, Boris Pavlovic wrote:\n> <snip>\n> To put in a nutshell most important issues:\n> 1) Extra complexity to each select query & extra column in each index\n> 2) Extra column in each Unique Constraint (worse performance)\n> 3) 2 Extra column in each table: (deleted, deleted_at)\n> 4) Common garbage collector is required\n\nNice summary of the problems related to soft deletion, Boris.\n\n> To resolve all these issues we should just remove soft deletion.\n> \n> One of approaches that I see is in step by step removing \"deleted\"\n> column from every table with probably code refactoring.  Actually we\n> have 3 different cases:\n> \n> 1) We don\'t use soft deleted records: \n> 1.1) Do .delete() instead of .soft_delete()\n> 1.2) Change query to avoid adding extra \"deleted == 0\" to each query\n> 1.3) Drop \"deleted\" and \"deleted_at\" columns\n> \n> 2) We use soft deleted records for internal stuff \"e.g. periodic\n> tasks\"\n> 2.1) Refactor code somehow: E.g. store all required data by periodic\n> task in some special table that has: (id, type, json_data) columns\n> 2.2) On delete add record to this table \n> 2.3-5) similar to 1.1, 1.2, 13\n> \n> 3) We use soft deleted records in API \n> 3.1) Deprecated API call if it is possible \n> 3.2) Make proxy call to ceilometer from API \n> 3.3) On .delete() store info about records in (ceilometer, or\n> somewhere else) \n> 3.4-6) similar to 1.1, 1.2, 1.3\n\nI would actually prefer this \"solution\", at least for server instances:\n\n1. Remove any contractual obligation in the API to allow servers with\nthe same \"name\" to exist, as long as only one of those servers is not\ndeleted. As I\'ve mentioned before, I think this is exceedingly silly to\nslow down the operation of Nova just to allow a user to create a server,\ndelete it, and immediately create a server with the same name.\n\n2. Make the unique constraint for the server name be on (project_id,\nname) and be done with it.\n\n3. Remove deleted and deleted_at from the instances table.\n\n4. Don\'t allow any delete() operation at all on the\nnova.objects.instance object at all.\n\n3. Hard delete records from the instances table on a periodic basis\nusing an external archiver that either just deletes the records in\ninstances that are in ERROR or TERMINATED vm_state (as is possible if\nceilometer is providing your bookkeeping) or move those records into an\narchival table (as would be necessary if you are not running Ceilometer\nand need some history of these things).\n\nFor other objects in the system, I think your solution #1 would work\nfine.\n\nBest,\n-jay\n\n\n\n\n','<CAD85om0Dje9XVZ0UHt_LDEfwgVR-t0h_8gYJ-qBLbQVApRHbog@mail.gmail.com>',NULL),('<1394489100-sup-9857@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 15:19:58',-25200,'2014-03-10 22:19:58',NULL,'[openstack-dev] [heat]Policy on upgades required config changes','Excerpts from Steven Hardy\'s message of 2014-03-05 04:24:51 -0800:\n> On Tue, Mar 04, 2014 at 02:06:16PM -0800, Clint Byrum wrote:\n> > Excerpts from Steven Hardy\'s message of 2014-03-04 09:39:21 -0800:\n> > > Hi all,\n> > > \n> > > As some of you know, I\'ve been working on the instance-users blueprint[1].\n> > > \n> > > This blueprint implementation requires three new items to be added to the\n> > > heat.conf, or some resources (those which create keystone users) will not\n> > > work:\n> > > \n> > > https://review.openstack.org/#/c/73978/\n> > > https://review.openstack.org/#/c/76035/\n> > > \n> > > So on upgrade, the deployer must create a keystone domain and domain-admin\n> > > user, add the details to heat.conf, as already been done in devstack[2].\n> > > \n> > > The changes requried for this to work have already landed in devstack, but\n> > > it was discussed to day and Clint suggested this may be unacceptable\n> > > upgrade behavior - I\'m not sure so looking for guidance/comments.\n> > > \n> > > My plan was/is:\n> > > - Make devstack work\n> > > - Talk to tripleo folks to assist in any transition (what prompted this\n> > >   discussion)\n> > > - Document the upgrade requirements in the Icehouse release notes so the\n> > >   wider community can upgrade from Havana.\n> > > - Try to give a heads-up to those maintaining downstream heat deployment\n> > >   tools (e.g stackforge/puppet-heat) that some tweaks will be required for\n> > >   Icehouse.\n> > > \n> > > However some have suggested there may be an openstack-wide policy which\n> > > requires peoples old config files to continue working indefinitely on\n> > > upgrade between versions - is this right?  If so where is it documented?\n> > > \n> > \n> > I don\'t think I said indefinitely, and I certainly did not mean\n> > indefinitely.\n> > \n> > What is required though, is that we be able to upgrade to the next\n> > release without requiring a new config setting.\n> \n> So log a warning for one cycle, then it\'s OK to expect the config after\n> that?\n> \n\nCorrect.\n\n> I\'m still unclear if there\'s an openstack-wide policy on this, as the whole\n> time-based release with release-notes (which all of openstack is structured\n> around and adheres to) seems to basically be an uncomfortable fit for folks\n> like tripleo who are trunk chasing and doing CI.\n>\n\nSo we\'re continuous delivery focused, but we are not special. HP Cloud\nand Rackspace both do this, and really anyone running a large cloud will\nmost likely do so with CD, as the value proposition is that you don\'t\nhave big scary upgrades, you just keep incrementally upgrading and\ngetting newer, better code. We can only do this if we have excellent\ntesting, which upstream already does and which the public clouds all\ndo privately as well of course.\n\nChanges like the one that was merged last week in Heat turn into\nstressful fire drills for those deployment teams.\n\n> > Also as we scramble to deal with these things in TripleO (as all of our\n> > users are now unable to spin up new images), it is clear that it is more\n> > than just a setting. One must create domain users carefully and roll out\n> > a new password.\n> \n> Such are the pitfalls of life at the bleeding edge ;)\n> \n\nThis is mildly annoying as a stance, as that\'s not how we\'ve been\noperating with all of the other services of OpenStack. We\'re not crazy\nfor wanting to deploy master and for wanting master to keep working. We\nare a _little_ crazy for wanting that without being in the gate.\n\n> Seriously though, apologies for the inconvenience - I have been asking for\n> feedback on these patches for at least a month, but clearly I should\'ve\n> asked harder.\n> \n\nMea culpa too, I did not realize what impact this would have until it\nwas too late.\n\n> As was discussed on IRC yesterday, I think some sort of (initially non-voting)\n> feedback from tripleo CI to heat gerrit is pretty much essential given that\n> you\'re so highly coupled to us or this will just keep happening.\n> \n\nTripleO will be in the gate some day (hopefully soon!) and then this\nwill be less of an issue as you\'d see failures early on, and could open\nbugs and get us to fix our issue sooner.\n\nHowever you\'d still need to provide the backward compatibility for a\nsingle cycle. Servers aren\'t upgraded instantly, and keystone may not be\nready for this v3/domain change until after users have fully rolled out\nIcehouse. Whether one is CD or stable release focused, one still needs a\nsimple solution to rolling out a massive update.\n\n> > What I\'m suggesting is that we should instead _warn_ that the old\n> > behavior is being used and will be deprecated.\n> > \n> > At this point, out of urgency, we\'re landing fixes. But in the future,\n> > this should be considered carefully.\n> \n> Ok, well I raised this bug:\n> \n> https://bugs.launchpad.net/heat/+bug/1287980\n> \n> So we can modify the stuff so that it falls back to the old behavior\n> gracefully and will solve the issue for folks on the time-based releases.\n> \n> Hopefully we can work towards the tripleo gate feedback so next time this\n> is less of a suprise for all of us ;)\n> \n\nYes, and hopefully it is also clear that we really do need to make things\nsimpler for upgraders, whether they upgrade at each commit, or at each\nstable release. :)\n\n\n','<20140305122450.GA20315@t430slt.redhat.com>',NULL),('<1394489757.3197.52.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 18:15:57',-14400,'2014-03-10 22:15:57',NULL,'[openstack-dev] [nova] a question about instance snapshot','On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote:\n> On 03/10/2014 02:58 PM, Jay Pipes wrote:\n> > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:\n> >> While I understand the general argument about pets versus cattle. The\n> >> question is, would you be willing to poke a few holes in the strict\n> >> \"cattle\" abstraction for the sake of pragmatism. Few shops are going\n> >> to make the direct transition in one move. Poking a hole in the cattle\n> >> abstraction allowing them to keep a pet VM might be very valuable to\n> >> some shops making a migration.\n> >\n> > Poking holes in cattle aside, my experience with shops that prefer the\n> > pets approach is that they are either:\n> >\n> >   * Not managing their servers themselves at all and just relying on some\n> > IT operations organization to manage everything for them, including all\n> > aspects of backing up their data as well as failing over and balancing\n> > servers, or,\n> >   * Hiding behind rationales of \"needing to be secure\" or \"needing 100%\n> > uptime\" or \"needing no customer disruption\" in order to avoid any change\n> > to the status quo. This is because the incentives inside legacy IT\n> > application development and IT operations groups are typically towards\n> > not rocking the boat in order to satisfy unrealistic expectations and\n> > outdated interface agreements that are forced upon them by management\n> > chains that haven\'t crawled out of the waterfall project management funk\n> > of the 1980s.\n> >\n> > Adding pet-based features to Nova would, IMO, just perpetuate the above\n> > scenarios and incentives.\n> \n> What about the cases where it\'s not a \"preference\" but rather just the \n> inertia of pre-existing systems and procedures?\n\nYou mean what I wrote in the second bullet point above?\n\n> If we can get them in the door with enough support for legacy stuff, \n> then they might be easier to convince to do things the \"cloud\" way in \n> the future.\n\nYes, fair point, and that\'s what Shawn was saying as well. Just noting\nthat in my experience, the second part of the above sentence just\ndoesn\'t happen. Once you bring them over and offer them the tools from\ntheir legacy environment, they aren\'t interested in changing. :)\n\n> If we stick with the hard-line cattle-only approach we run the risk of \n> alienating them completely since redoing everything at once is generally \n> not feasible.\n\nYes, I understand that. I\'m actually fine with including functionality\nlike memory snapshotting, but only if under no circumstances does it\nnegatively impact the service of compute to other tenants/users and will\nnot negatively impact the scaling factor of Nova either.\n\nI\'m just not as optimistic as you are that once legacy IT folks have\ntheir old tools, they will consider changing their habits. ;)\n\nBest,\n-jay\n\n\n\n','<531E342B.2040809@windriver.com>',NULL),('<1394504879.60.1381818815574.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-15 06:33:35',0,'2013-10-15 06:33:35',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #38','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/38/>\n\n\n\n','<1647630671.41.1381385294124.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1394517386.53677.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 13:56:26',28800,'2014-03-11 05:56:26',NULL,'[Openstack] query about Statsd','Thanks Anne for answering my queries.\n\nPragya Jain\n\n\n\nOn Monday, 10 March 2014 11:03 PM, Anne Gentle <anne at openstack.org> wrote:\n \nHave you referred to this document??\n>http://docs.openstack.org/grizzly/openstack-object-storage/admin/content/ch_introduction-to-openstack-object-storage-monitoring.html\n>\n>\n>\n>Answers below based on that circa-April-2013 document, might need updates.\n>\n>\n>\n>\n>On Thu, Mar 6, 2014 at 4:36 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello all,\n>>\n>>\n>>I have some questions about?Statsd server for openstack swift\n>>\n>>\n>>Q1: ?Is swift-informant middleware necessary to be included in proxy-server.conf in order to provide metrics to StatsD server?\n>>\n>>\n>\n>\n>yes, swift-informant sits in the proxy server?s pipeline and after each request to the proxy server, sends three metrics to a?StatsD?server\n>\n>?\n>Q2: what type of metrics does?swift-informant middleware?provide to StatsD server?\n>\n>\n>	* A counter increment for a metric like?obj.GET.200?or?cont.PUT.404.\n>	* Timing data for a metric like?acct.GET.200?or?obj.GET.200. [The README says the metrics will look likeduration.acct.GET.200, but I don?t see the ?duration? in the code. I?m not sure what Etsy?s server does, but our StatsD server turns timing metrics into 5 derivative metrics with new segments appended, so it probably works as coded. The first metric above would turn into?acct.GET.200.lower,?acct.GET.200.upper,?acct.GET.200.mean,acct.GET.200.upper_90, and?acct.GET.200.count]\n>	* A counter increase by the bytes transferred for a metric like?tfer.obj.PUT.201.\n>?\n>\n>>\n>>Q3: ?What is StatsDlog? Is it a middleware or a daemon or something other? And, What type of metrics does it?provide to StatsD server?\n>\n>\n>statsdlog can track events from all Object Storage daemons, not just proxy-server\n>\n>\n>?\n>\n>>\n>>I had searched many documents, but I still have confusion about it.\n>>Please somebody answer my questions.\n>>\n>>\n>>Thanks?\n>>Pragya jain\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/59e22c38/attachment.html>\n\n','<CAD0KtVHwLcGOWvoZcpqOEZdvS4-TgyGiwLuSmj89j-=6S_diug@mail.gmail.com>',NULL),('<1394518604.36654.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 14:16:44',28800,'2014-03-11 06:16:44',NULL,'[Openstack] swift recon query','Thanks Drudy Gerry for answering my queries.\n\nBut when I use curl command for recon, I get the following results:\n\nroot at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/mounted\ncurl: (7) couldn\'t connect to host\n\nI don\'t understand where is the problem. Please help.\n\nThanks\nPragya Jain\n\n\n\n\nOn Friday, 7 March 2014 3:51 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> wrote:\n \nComments inline.\n>?\n>From:pragya jain [mailto:prag_2648 at yahoo.co.in] \n>Sent: 07 March 2014 05:33\n>To: Steve Mayer; Drudy, Gerry\n>Cc: openstack at lists.openstack.org\n>Subject: Re: [Openstack] swift recon query\n>?\n>Hello Steve,\n>\n>\n>\n>My questions about swift recon are:\n>\n>Q1: what should be the curl command for recon?\n>\n>\n>For example, to get a list of mounted devices on an object server:\n>curl -i http://<an-object-server-ip>:6000/recon/mounted\n>\n>Q2. what arguments should I use with \'swift-recon\' command to get the status about\n>? ? ? ? ? ? ? ? ? ?(i)? ? ? /proc/meminfo,\n>I?m not sure you can get meminfo using the swift-recon command. But you can use curl to get meminfo from a node, the following is a request to an object server:\n>curl -i http://<an-object-server-ip>:6000/recon/mem\n>\n>? ? ? ? ? ? ? ? ? ?(ii)? ? currently mounted file systems\n>Use ?swift-recon ?d?\n>\n>? ? ? ? ? ? ? ? ? ?(iii)? ? list of devices\n>Same as ii.\n>\n>\n>\n>\n>Q3. When I run swift-recon command, It respond in terms of?low: <> high: <> avg: <> total: <> failed: <> no_result: <>\n>For example,\n>root at swift-VirtualBox:~# swift-recon account --auditor \n>=============================================================================== \n>--> Starting reconnaissance on 4 hosts \n>=============================================================================== \n>[2014-02-12 15:05:20] Checking auditor stats \n>[account_auditor_pass_completed] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 1 \n>[account_audits_passed] - No hosts returned valid data. \n>[account_audits_failed] - No hosts returned valid data. \n>[account_audits_since] - No hosts returned valid data. \n>?\n>?\n>What is the meaning of following terms: low,?high,?avg,?total, failed,?no_result, and reported ?\n>\n>\n>Typically the ?low? would indicate the value from a node with the lowest value. For example if you are looking at async pendings, each node will have a different async pending queue length. The low value indicates queue length for the node with the smallest queue length, while the high indicates the longest async pending queue length and avg is the average queue length for all nodes.? The total is the total number of async pending across all nodes.? I think reported typically means the number of nodes it has got a result from? I can?t give you a clear definition of failed and no_result!\n>?\n>\n>Thanks\n>Pragya Jain\n>?\n>On Thursday, 6 March 2014 9:14 PM, Steve Mayer <smayer69 at me.com> wrote:\n>The \'-a\' argument to swift-recon is for looking at the async-pendings, \n>>which will only be available if you\'ve set up the \n>>/usr/bin/swift-recon-cron job on the object server nodes.\n>>\n>>Try running with the \'-d\' or \'-l\' arguments to see some actual \n>>statistics.\n>>\n>>-- \n>>Steve Mayer\n>>smayer69 at me.com\n>>\n>>On 6 Mar 2014, at 2:31, Drudy, Gerry wrote:\n>>\n>>> Add the verbose option to swift-recon:\n>>>\n>>> swift-recon -av\n>>>\n>>> It will list all the object servers in the ring.? Each server listed \n>>> should have the object-server process running.\n>>>\n>>> Gerry.\n>>>\n>>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>>> Sent: 06 March 2014 10:25\n>>> To: Drudy, Gerry; openstack at lists.openstack.org\n>>> Subject: Re: [Openstack] swift recon query\n>>>\n>>> hi Gerry,\n>>>\n>>> I run following commands:\n>>> root at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/async\n>>> curl: (7) couldn\'t connect to host\n>>> root at swift-VirtualBox:~# swift-recon -a\n>>> ===============================================================================\n>>> --> Starting reconnaissance on 4 hosts\n>>> ===============================================================================\n>>> [2014-03-06 15:51:14] Checking async pendings\n>>> [async_pending] - No hosts returned valid data.\n>>> ===============================================================================\n>>> I can\'t understand where is the problem\n>>>\n>>> Please help.\n>>>\n>>> Thanks\n>>> Pragya jain\n>>>\n>>> On Thursday, 6 March 2014 2:38 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> \n>>> wrote:\n>>> Try\n>>>\n>>> curl? -i http://127.0.0.1:6000/recon/async\n>>>\n>>> assuming 6000 is the port the object-server binds to.\n>>>\n>>> Gerry,\n>>>\n>>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>>> Sent: 06 March 2014 06:58\n>>> To: openstack at lists.openstack.org\n>>> Subject: Re: [Openstack] swift recon query\n>>>\n>>> please somebody answer my questions related to swift recon.\n>>>\n>>> Thanks\n>>>\n>>> Pragya Jain\n>>>\n>>> On Wednesday, 5 March 2014 2:31 PM, pragya jain \n>>> <prag_2648 at yahoo.co.in> wrote:\n>>> hello all,\n>>>\n>>> I have some basic questions about swift recon. please query them.\n>>>\n>>> Q1: what should be the curl command for recon?\n>>>\n>>> I use the following commands:\n>>> 1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>>>\n>>> HTTP/1.1 401 Unauthorized\n>>> Content-Length: 131\n>>> Content-Type: text/html; charset=UTF-8\n>>> Www-Authenticate: Swift realm=\"async\"\n>>> X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n>>> Date: Wed, 05 Mar 2014 08:43:17 GMT\n>>>\n>>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>>> are authorized to access the document you requested.</p></html>\n>>>\n>>> 2.? root at swift-VirtualBox:~# curl -i \n>>> http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>>>\n>>> HTTP/1.1 401 Unauthorized\n>>> Content-Length: 131\n>>> Content-Type: text/html; charset=UTF-8\n>>> Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n>>> X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n>>> Date: Wed, 05 Mar 2014 08:45:24 GMT\n>>>\n>>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>>> are authorized to access the document you requested.</p></html>\n>>>\n>>> Q2. Does \'swift-recon\' command not provide the status about\n>>>? ? ? ? ? ? ? ? ? ? (i)? ? ? /proc/meminfo,\n>>>? ? ? ? ? ? ? ? ? ? (ii)? ? currently mounted file systems\n>>>? ? ? ? ? ? ? ? ? ? (iii)? ? list of devices\n>>>? ? if \'swift-recon\' provides these informations, then what should be \n>>> the command?\n>>>\n>>> Q3. It stands for what?\n>>>? ? ? ? ? low\n>>>? ? ? ? ? high\n>>>? ? ? ? ? avg\n>>>? ? ? ? ? total\n>>>? ? ? ? ? failed\n>>>? ? ? ? ? no_result\n>>>? ? ? ? ? reported\n>>>\n>>> Pragya Jain\n>>>\n>>>\n>>> _______________________________________________\n>>> Mailing list: \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to? ? : openstack at lists.openstack.org\n>>> Unsubscribe : \n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/2bd4576e/attachment.html>\n\n','<923E0D692F901442ACBA7199520F3D4625307289@G4W3226.americas.hpqcorp.net>',NULL),('<1394518716.92201.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 14:18:36',28800,'2014-03-11 06:18:36',NULL,'[Openstack] difference between metrics to statsd and metrics\n	provided by swift recon middleware','Please somebody answer my query.\n\nThanks?\nPragya Jain\n\n\n\nOn Monday, 10 March 2014 1:22 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>according to the documents, statsd server collects the following metrics about account-auditor:\n>Metric Name Description account-auditor.errors Count of audit runs (across all account databases) which caught an Exception. account-auditor.passes Count of individual account databases which passed audit. account-auditor.failures Count of individual account databases which failed audit. account-auditor.timing Timing data for individual account database audits.\n>and, swift recon middleware provides following information about account-auditor: ? account_auditor_pass_completed ? account_audits_passed ? account_audits_failed ? account_audits_since\n>please somebody help me to understand what is the similarity and what is the difference between the metrics collected by statsd server and metrics provided by swift recon middleware.\n>Thanks?\n>Pragya Jain\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/09da68a2/attachment.html>\n\n','<1394437958.83783.YahooMailNeo@web193606.mail.sg3.yahoo.com>',NULL),('<1394520291.87693.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 14:44:51',28800,'2014-03-11 06:44:51',NULL,'[Openstack] problem in log in django swiftbrowser','hello all,?\n\nI had installed django swiftbrowser on a VM of Ubuntu 12.04 desktop using the link?https://github.com/cschwede/django-swiftbrowser\n\nwhen i login by entering a username and password on login screen, it shows a blank screen.(screenshots attached)\n\nCLI gives following messages:\n\nroot at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n\n\nOUTPUT:\nValidating models...\n\n0 errors found\nMarch 03, 2014 - 11:58:30\nDjango version 1.6.2, using settings \'myproj.settings\'\nStarting development server at http://127.0.0.1:8000/\nQuit the server with CONTROL-C.\n[03/Mar/2014 11:59:00] \"GET / HTTP/1.1\" 302 0\n[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n[03/Mar/2014 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n\nI can\'t understand where is the problem.\n\nPlease somebody help me to resolve it.\n\nThanks?\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/c9e6ef6d/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot login.png\nType: image/png\nSize: 114084 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/c9e6ef6d/attachment-0002.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Screenshot afterLogin.png\nType: image/png\nSize: 100674 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/c9e6ef6d/attachment-0003.png>\n\n',NULL,NULL),('<1394531183.46489.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 17:46:23',28800,'2014-03-11 09:46:23',NULL,'[Openstack] swift recon query','Hi Gerry,\n\nObject server is using port 6010 rather than 6000\nI use the curl command\ncurl -i http://127.0.0.1:6010/recon/mounted\n\n\nNow it is working.\n\nVery thankful for your help.\n\nThanks again\nPragya jain\n\n\n\n\nOn Tuesday, 11 March 2014 2:59 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> wrote:\n \nIs the object-server running on the node and is it using port 6000 and does it have recon in the pipeline e.g.\n>?\n>grep pipeline /etc/swift/object-server.conf \n>[pipeline:main]\n>pipeline = recon name_check object-serve\n>?\n>Gerry\n>?\n>From:pragya jain [mailto:prag_2648 at yahoo.co.in] \n>Sent: 11 March 2014 06:17\n>To: Drudy, Gerry; Steve Mayer\n>Cc: openstack at lists.openstack.org\n>Subject: Re: [Openstack] swift recon query\n>?\n>Thanks Drudy Gerry for answering my queries.\n>\n>But when I use curl command for recon, I get the following results:\n>\n>root at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/mounted\n>curl: (7) couldn\'t connect to host\n>\n>I don\'t understand where is the problem. Please help.\n>\n>Thanks\n>Pragya Jain\n>?\n>On Friday, 7 March 2014 3:51 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> wrote:\n>Comments inline.\n>>?\n>>From:pragya jain [mailto:prag_2648 at yahoo.co.in] \n>>Sent: 07 March 2014 05:33\n>>To: Steve Mayer; Drudy, Gerry\n>>Cc: openstack at lists.openstack.org\n>>Subject: Re: [Openstack] swift recon query\n>>?\n>>Hello Steve,\n>>?\n>>My questions about swift recon are:\n>>\n>>Q1: what should be the curl command for recon?\n>>For example, to get a list of mounted devices on an object server:\n>>curl -i http://<an-object-server-ip>:6000/recon/mounted\n>>\n>>Q2. what arguments should I use with \'swift-recon\' command to get the status about\n>>? ? ? ? ? ? ? ? ? ?(i)? ? ? /proc/meminfo,\n>>I?m not sure you can get meminfo using the swift-recon command. But you can use curl to get meminfo from a node, the following is a request to an object server:\n>>curl -i http://<an-object-server-ip>:6000/recon/mem\n>>\n>>? ? ? ? ? ? ? ? ? ?(ii)? ? currently mounted file systems\n>>Use ?swift-recon ?d?\n>>\n>>? ? ? ? ? ? ? ? ? ?(iii)? ? list of devices\n>>Same as ii.\n>>\n>>\n>>\n>>Q3. When I run swift-recon command, It respond in terms of?low: <> high: <> avg: <> total: <> failed: <> no_result: <>\n>>For example,\n>>root at swift-VirtualBox:~# swift-recon account --auditor \n>>=============================================================================== \n>>--> Starting reconnaissance on 4 hosts \n>>=============================================================================== \n>>[2014-02-12 15:05:20] Checking auditor stats \n>>[account_auditor_pass_completed] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 1 \n>>[account_audits_passed] - No hosts returned valid data. \n>>[account_audits_failed] - No hosts returned valid data. \n>>[account_audits_since] - No hosts returned valid data. \n>>?\n>>?\n>>What is the meaning of following terms: low,?high,?avg,?total, failed,?no_result, and reported ?\n>>Typically the ?low? would indicate the value from a node with the lowest value. For example if you are looking at async pendings, each node will have a different async pending queue length. The low value indicates queue length for the node with the smallest queue length, while the high indicates the longest async pending queue length and avg is the average queue length for all nodes.? The total is the total number of async pending across all nodes.? I think reported typically means the number of nodes it has got a result from? I can?t give you a clear definition of failed and no_result!\n>>?\n>>\n>>Thanks\n>>Pragya Jain\n>>?\n>>On Thursday, 6 March 2014 9:14 PM, Steve Mayer <smayer69 at me.com> wrote:\n>>The \'-a\' argument to swift-recon is for looking at the async-pendings, \n>>>which will only be available if you\'ve set up the \n>>>/usr/bin/swift-recon-cron job on the object server nodes.\n>>>\n>>>Try running with the \'-d\' or \'-l\' arguments to see some actual \n>>>statistics.\n>>>\n>>>-- \n>>>Steve Mayer\n>>>smayer69 at me.com\n>>>\n>>>On 6 Mar 2014, at 2:31, Drudy, Gerry wrote:\n>>>\n>>>> Add the verbose option to swift-recon:\n>>>>\n>>>> swift-recon -av\n>>>>\n>>>> It will list all the object servers in the ring.? Each server listed \n>>>> should have the object-server process running.\n>>>>\n>>>> Gerry.\n>>>>\n>>>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>>>> Sent: 06 March 2014 10:25\n>>>> To: Drudy, Gerry; openstack at lists.openstack.org\n>>>> Subject: Re: [Openstack] swift recon query\n>>>>\n>>>> hi Gerry,\n>>>>\n>>>> I run following commands:\n>>>> root at swift-VirtualBox:~# curl -i http://127.0.0.1:6000/recon/async\n>>>> curl: (7) couldn\'t connect to host\n>>>> root at swift-VirtualBox:~# swift-recon -a\n>>>> ===============================================================================\n>>>> --> Starting reconnaissance on 4 hosts\n>>>> ===============================================================================\n>>>> [2014-03-06 15:51:14] Checking async pendings\n>>>> [async_pending] - No hosts returned valid data.\n>>>> ===============================================================================\n>>>> I can\'t understand where is the problem\n>>>>\n>>>> Please help.\n>>>>\n>>>> Thanks\n>>>> Pragya jain\n>>>>\n>>>> On Thursday, 6 March 2014 2:38 PM, \"Drudy, Gerry\" <Gerry.Drudy at hp.com> \n>>>> wrote:\n>>>> Try\n>>>>\n>>>> curl? -i http://127.0.0.1:6000/recon/async\n>>>>\n>>>> assuming 6000 is the port the object-server binds to.\n>>>>\n>>>> Gerry,\n>>>>\n>>>> From: pragya jain [mailto:prag_2648 at yahoo.co.in]\n>>>> Sent: 06 March 2014 06:58\n>>>> To: openstack at lists.openstack.org\n>>>> Subject: Re: [Openstack] swift recon query\n>>>>\n>>>> please somebody answer my questions related to swift recon.\n>>>>\n>>>> Thanks\n>>>>\n>>>> Pragya Jain\n>>>>\n>>>> On Wednesday, 5 March 2014 2:31 PM, pragya jain \n>>>> <prag_2648 at yahoo.co.in> wrote:\n>>>> hello all,\n>>>>\n>>>> I have some basic questions about swift recon. please query them.\n>>>>\n>>>> Q1: what should be the curl command for recon?\n>>>>\n>>>> I use the following commands:\n>>>> 1.? root at swift-VirtualBox:~# curl -i http://127.0.0.1:8080/recon/async\n>>>>\n>>>> HTTP/1.1 401 Unauthorized\n>>>> Content-Length: 131\n>>>> Content-Type: text/html; charset=UTF-8\n>>>> Www-Authenticate: Swift realm=\"async\"\n>>>> X-Trans-Id: txe8c8850fc0a74ae095faa-005316e3a5\n>>>> Date: Wed, 05 Mar 2014 08:43:17 GMT\n>>>>\n>>>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>>>> are authorized to access the document you requested.</p></html>\n>>>>\n>>>> 2.? root at swift-VirtualBox:~# curl -i \n>>>> http://127.0.0.1:8080/v1/AUTH_prag2648/recon/async\n>>>>\n>>>> HTTP/1.1 401 Unauthorized\n>>>> Content-Length: 131\n>>>> Content-Type: text/html; charset=UTF-8\n>>>> Www-Authenticate: Swift realm=\"AUTH_prag2648\"\n>>>> X-Trans-Id: tx978f787ce01f446a9beeb-005316e424\n>>>> Date: Wed, 05 Mar 2014 08:45:24 GMT\n>>>>\n>>>> <html><h1>Unauthorized</h1><p>This server could not verify that you \n>>>> are authorized to access the document you requested.</p></html>\n>>>>\n>>>> Q2. Does \'swift-recon\' command not provide the status about\n>>>>? ? ? ? ? ? ? ? ? ? (i)? ? ? /proc/meminfo,\n>>>>? ? ? ? ? ? ? ? ? ? (ii)? ? currently mounted file systems\n>>>>? ? ? ? ? ? ? ? ? ? (iii)? ? list of devices\n>>>>? ? if \'swift-recon\' provides these informations, then what should be \n>>>> the command?\n>>>>\n>>>> Q3. It stands for what?\n>>>>? ? ? ? ? low\n>>>>? ? ? ? ? high\n>>>>? ? ? ? ? avg\n>>>>? ? ? ? ? total\n>>>>? ? ? ? ? failed\n>>>>? ? ? ? ? no_result\n>>>>? ? ? ? ? reported\n>>>>\n>>>> Pragya Jain\n>>>>\n>>>>\n>>>> _______________________________________________\n>>>> Mailing list: \n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to? ? : openstack at lists.openstack.org\n>>>> Unsubscribe : \n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>?\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/bdcd2d58/attachment.html>\n\n','<923E0D692F901442ACBA7199520F3D462530B038@G4W3226.americas.hpqcorp.net>',NULL),('<1394531553.75438.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 17:52:33',28800,'2014-03-11 09:52:33',NULL,'[Openstack] problem in log in django swiftbrowser','hi krish?\n\nFrom where should I get the logs for the same?\n\nThanks?\nPragya Jain\n\n\n\nOn Tuesday, 11 March 2014 3:04 PM, krish <das.srikrishna at gmail.com> wrote:\n \nyou might want to pastebin your logs rather than attaching screenshots of blank page :)\n>\n>\n>\n>On Tue, Mar 11, 2014 at 12:14 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hello all,?\n>>\n>>\n>>I had installed django swiftbrowser on a VM of Ubuntu 12.04 desktop using the link?https://github.com/cschwede/django-swiftbrowser\n>>\n>>\n>>when i login by entering a username and password on login screen, it shows a blank screen.(screenshots attached)\n>>\n>>\n>>CLI gives following messages:\n>>\n>>\n>>root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n>>\n>>\n>>\n>>OUTPUT:\n>>Validating models...\n>>\n>>0 errors found\n>>March 03, 2014 - 11:58:30\n>>Django version 1.6.2, using settings \'myproj.settings\'\n>>Starting development server at http://127.0.0.1:8000/\n>>Quit the server with CONTROL-C.\n>>[03/Mar/2014\n 11:59:00] \"GET / HTTP/1.1\" 302 0\n>>[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n>>[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n>>[03/Mar/2014 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n>>\n>>\n>>I can\'t understand where is the problem.\n>>\n>>\n>>Please somebody help me to resolve it.\n>>\n>>\n>>Thanks?\n>>Pragya Jain\n>>\n>>\n>>\n>>\n>>_______________________________________________\n>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>Post to ? ? : openstack at lists.openstack.org\n>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>\n>>\n>\n>\n>\n>-- \n>\n>Have a Power-Up Day!\n>--\n>Krish\n>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/ad8ee506/attachment.html>\n\n','<CA+Vv_Q3GkUgpjBn_=S8NqndVfuYMNY0OMHKJZMCA1mO0r4OfXA@mail.gmail.com>',NULL),('<1394534677.35409.YahooMailNeo@web193602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-11 18:44:37',28800,'2014-03-11 10:44:37',NULL,'[Openstack] problem in log in django swiftbrowser','hi krish\n\nI am pasting the logs\n\nhttp://paste.openstack.org/show/73122/\n\nPlease help me understand where is the problem\n\nThanks \nPragya Jain\n\n\n\n\nOn Tuesday, 11 March 2014 3:28 PM, krish <das.srikrishna at gmail.com> wrote:\n \nRun an ls -ltr in ?/var/log/ ?or /var/log/swift\n>\n>\n>Check what corresponds to the same time as you try to login.\n>Try tailing those logs or use less to open them and read through. Figure out :)\n>May be you\'ll find the problem.\n>\n>\n>\n>On Tue, Mar 11, 2014 at 3:22 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>\n>hi krish?\n>>\n>>\n>>From where should I get the logs for the same?\n>>\n>>\n>>Thanks?\n>>Pragya Jain\n>>\n>>\n>>\n>>On Tuesday, 11 March 2014 3:04 PM, krish <das.srikrishna at gmail.com> wrote:\n>> \n>>you might want to pastebin your logs rather than attaching screenshots of blank page :)\n>>>\n>>>\n>>>\n>>>On Tue, Mar 11, 2014 at 12:14 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>\n>>>hello all,?\n>>>>\n>>>>\n>>>>I had installed django swiftbrowser on a VM of Ubuntu 12.04 desktop using the link?https://github.com/cschwede/django-swiftbrowser\n>>>>\n>>>>\n>>>>when i login by entering a username and password on login screen, it shows a blank screen.(screenshots attached)\n>>>>\n>>>>\n>>>>CLI gives following messages:\n>>>>\n>>>>\n>>>>root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n>>>>\n>>>>\n>>>>\n>>>>OUTPUT:\n>>>>Validating models...\n>>>>\n>>>>0 errors found\n>>>>March 03, 2014 - 11:58:30\n>>>>Django version 1.6.2, using settings \'myproj.settings\'\n>>>>Starting development server at http://127.0.0.1:8000/\n>>>>Quit the server with CONTROL-C.\n>>>>[03/Mar/2014\n 11:59:00] \"GET / HTTP/1.1\" 302 0\n>>>>[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n>>>>[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n>>>>[03/Mar/2014 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n>>>>\n>>>>\n>>>>I can\'t understand where is the problem.\n>>>>\n>>>>\n>>>>Please somebody help me to resolve it.\n>>>>\n>>>>\n>>>>Thanks?\n>>>>Pragya Jain\n>>>>\n>>>>\n>>>>\n>>>>\n>>>>_______________________________________________\n>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>\n>>>>\n>>>\n>>>\n>>>\n>>>-- \n>>>\n>>>Have a Power-Up Day!\n>>>--\n>>>Krish\n>>>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>>>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>>\n>>>\n>>>\n>>>\n>\n>\n>\n>-- \n>\n>Have a Power-Up Day!\n>--\n>Krish\n>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140311/2453118f/attachment.html>\n\n','<CA+Vv_Q15Uhku1UfMMbXrfTdGOzmtC7rUXyLFVE7oHKr92TvAPg@mail.gmail.com>',NULL),('<1394540350824-34845.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 05:19:11',-25200,'2014-03-11 12:19:11',NULL,'[openstack-dev] [Openstack][Nova][Docker] Devstack with docker\n	driver','Hello!,\n\ni can run docker containers and push it to docker io but i failed to push it\nfor local glance.and get the same error mentioned here.\nCould you please show some more light on  how you resolved it. i started\nsettingup openstack and docker using devstack. \nhere is my localrc \nFLOATING_RANGE=192.168.140.0/27\nFIXED_RANGE=10.11.12.0/24\nFIXED_NETWORK_SIZE=256\nFLAT_INTERFACE=eth1\nADMIN_PASSWORD=g\nMYSQL_PASSWORD=g\nRABBIT_PASSWORD=g\nSERVICE_PASSWORD=g\nSERVICE_TOKEN=g\nSCHEDULER=nova.scheduler.filter_scheduler.FilterScheduler\nVIRT_DRIVER=docker\nSCREEN_LOGDIR=$DEST/logs/screen\n---------------------------------------------------\nthe machine im testing is on vmware ubuntu 13.01 with two nics  assuming\neth0 connected to internet and eth1 to local network.\n---------------------------------------------------\n\n\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/Openstack-Nova-Docker-Devstack-with-docker-driver-tp28361p34845.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<877ga19tko.fsf@redhat.com>',NULL),('<1394557480-sup-6876@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 10:20:46',-25200,'2014-03-11 17:20:46',NULL,'[openstack-dev] [TripleO] os-cloud-config ssh access to cloud','Excerpts from Adam Young\'s message of 2014-03-11 07:50:58 -0700:\n> On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:\n> > For what it\'s worth in Sahara (former Savanna) we inject the second\n> > key by userdata. I.e. we add\n> > echo \"${public_key}\" >> ${user_home}/.ssh/authorized_keys\n> >\n> > to the other stuff we do in userdata.\n> >\n> > Dmitry\n> >\n> > 2014-03-10 17:10 GMT+04:00 Ji?? Str?nsk? <jistr at redhat.com>:\n> >> On 7.3.2014 14:50, Imre Farkas wrote:\n> >>> On 03/07/2014 10:30 AM, Ji?? Str?nsk? wrote:\n> >>>> Hi,\n> >>>>\n> >>>> there\'s one step in cloud initialization that is performed over SSH --\n> >>>> calling \"keystone-manage pki_setup\". Here\'s the relevant code in\n> >>>> keystone-init [1], here\'s a review for moving the functionality to\n> >>>> os-cloud-config [2].\n> \n> You really should not be doing this.  I should never have written \n> pki_setup:  it is a developers tool:  user a real CA and a real certificate.\n> \n\nThis alludes to your point, but also says that keystone-manage can be used:\n\nhttp://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki\n\nSeems that some time should be spent making this more clear if for some\nreason pki_setup is weak for production use cases. My brief analysis\nof the code says that the weakness is that the CA should generally be\nkept apart from the CSR\'s so that a compromise of a node does not lead\nto an attacker being able to generate their own keystone service. This\nseems like a low probability attack vector, as compromise of the keystone\nmachines also means write access to the token backend, and thus no need\nto generate ones\' own tokens (you can just steal all the existing tokens).\n\nI\'d like to see it called out in the section above though, so that\nusers can know what risk their accepting when they use what looks like a\nrecommended tool. Another thing would be to log copious warnings when\npki_setup is run that it is not for production usage. That should be\nsufficient to scare some diligent deployers into reading the docs closely\nand mitigating the risk.\n\nAnyway, shaking fist at users and devs in -dev for using tools in the\ndocumentation probably _isn\'t_ going to convince anyone to spend more\ntime setting up PKI tokens.\n\n\n','<531F22D2.3020301@redhat.com>',NULL),('<1394558533-sup-3088@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 10:24:23',-25200,'2014-03-11 17:24:23',NULL,'[openstack-dev] [TripleO] os-cloud-config ssh access to cloud','Excerpts from Ji?? Str?nsk?\'s message of 2014-03-10 06:10:46 -0700:\n> On 7.3.2014 14:50, Imre Farkas wrote:\n> > On 03/07/2014 10:30 AM, Ji?? Str?nsk? wrote:\n> >> Hi,\n> >>\n> >> there\'s one step in cloud initialization that is performed over SSH --\n> >> calling \"keystone-manage pki_setup\". Here\'s the relevant code in\n> >> keystone-init [1], here\'s a review for moving the functionality to\n> >> os-cloud-config [2].\n> >>\n> >> The consequence of this is that Tuskar will need passwordless ssh key to\n> >> access overcloud controller. I consider this suboptimal for two reasons:\n> >>\n> >> * It creates another security concern.\n> >>\n> >> * AFAIK nova is only capable of injecting one public SSH key into\n> >> authorized_keys on the deployed machine, which means we can either give\n> >> it Tuskar\'s public key and allow Tuskar to initialize overcloud, or we\n> >> can give it admin\'s custom public key and allow admin to ssh into\n> >> overcloud, but not both. (Please correct me if i\'m mistaken.) We could\n> >> probably work around this issue by having Tuskar do the user key\n> >> injection as part of os-cloud-config, but it\'s a bit clumsy.\n> >>\n> >>\n> >> This goes outside the scope of my current knowledge, i\'m hoping someone\n> >> knows the answer: Could pki_setup be run by combining powers of Heat and\n> >> os-config-refresh? (I presume there\'s some reason why we\'re not doing\n> >> this already.) I think it would help us a good bit if we could avoid\n> >> having to SSH from Tuskar to overcloud.\n> >\n> > Yeah, it came up a couple times on the list. The current solution is\n> > because if you have an HA setup, the nodes can\'t decide on its own,\n> > which one should run pki_setup.\n> > Robert described this topic and why it needs to be initialized\n> > externally during a weekly meeting in last December. Check the topic\n> > \'After heat stack-create init operations (lsmola)\':\n> > http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-12-17-19.02.log.html\n> \n> Thanks for the reply Imre. Yeah i vaguely remember that meeting :)\n> \n> I guess to do HA init we\'d need to pick one of the controllers and run \n> the init just there (set some parameter that would then be recognized by \n> os-refresh-config). I couldn\'t find if Heat can do something like this \n> on it\'s own, probably we\'d need to deploy one of the controller nodes \n> with different parameter set, which feels a bit weird.\n> \n> Hmm so unless someone comes up with something groundbreaking, we\'ll \n> probably keep doing what we\'re doing. Having the ability to inject \n> multiple keys to instances [1] would help us get rid of the Tuskar vs. \n> admin key issue i mentioned in the initial e-mail. We might try asking a \n> fellow Nova developer to help us out here.\n> \n\nI think the long term idea is to run a separate CA and use Barbican for\nkey distribution, as that is precisely what it is designed to do.\n\nFor now SSH\'ing in one time to bootstrap a cloud seems an acceptable\nrisk, and the scope of that SSH key can be ratcheted down to just running\npki_setup, which may be a good idea.\n\n\n','<531DB9D6.5080305@redhat.com>',NULL),('<1394560570-sup-9158@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 10:57:48',-25200,'2014-03-11 17:57:48',NULL,'[openstack-dev] [Trove] MySQL 5.6 disk-image-builder element','Excerpts from Lowery, Mathew\'s message of 2014-03-11 10:33:12 -0700:\n> My colleague, Ranjitha Vemula, just submitted a trove-integration patch\n> set to add a MySQL 5.6 disk-image-builder element. Two major hurdles were\n> faced with this patch set.\n\n<snip>\n\n> In my understanding, D.I.B. elements should be pretty dumb and the caller\n> should worry about composing them so this setup seems like the best\n> approach to me but it leaves ubuntu-mysql untouched. A point made by\n> hub_cap is that now ubuntu-mysql, similar to ubuntu-guest, would imply\n> \"things common to all MySQL images\" but as of right now, it is as it was\n> before: a MySQL 5.5 image. So there\'s that to discuss.\n\nYes and no. Yes you should allow users to compose their images by listing\nelements. However, you can compose your element from other elements as\nwell automatically by using The element-deps file in the root.\n\nI\'d suggest copying everything that is common to the two elements\ninto an ubuntu-mysql-common element, and having both ubuntu-mysql and\nubuntu-mysq-5.6 list ubuntu-mysql-common in element-deps.\n\n\n','<CF44B306.22945%mlowery@ebay.com>',NULL),('<1394565348.3197.54.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 15:15:48',-14400,'2014-03-11 19:15:48',NULL,'[openstack-dev] [nova] a question about instance snapshot','On Tue, 2014-03-11 at 06:35 +0000, Bohai (ricky) wrote:\n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: Tuesday, March 11, 2014 3:20 AM\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [nova] a question about instance snapshot\n> >\n> > On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:\n> > > We have very strong interest in pursing this feature in the VMware\n> > > driver as well. I would like to see the revert instance feature\n> > > implemented at least.\n> > >\n> > > When I used to work in multi-discipline roles involving operations it\n> > > would be common for us to snapshot a vm, run through an upgrade\n> > > process, then revert if something did not upgrade smoothly. This\n> > > ability alone can be exceedingly valuable in long-lived virtual\n> > > machines.\n> > >\n> > > I also have some comments from parties interested in refactoring how\n> > > the VMware drivers handle snapshots but I\'m not certain how much that\n> > > plays into this \"live snapshot\" discussion.\n> >\n> > I think the reason that there isn\'t much interest in doing this kind of thing is\n> > because the worldview that VMs are pets is antithetical to the worldview that\n> > VMs are cattle, and Nova tends to favor the latter (where DRS/DPM on\n> > vSphere tends to favor the former).\n> >\n> > There\'s nothing about your scenario above of being able to \"revert\" an instance\n> > to a particular state that isn\'t possible with today\'s Nova.\n> > Snapshotting an instance, doing an upgrade of software on the instance, and\n> > then restoring from the snapshot if something went wrong (reverting) is\n> > already fully possible to do with the regular Nova snapshot and restore\n> > operations. The only difference is that the \"live-snapshot\"\n> > stuff would include saving the memory view of a VM in addition to its disk state.\n> > And that, at least in my opinion, is only needed when you are treating VMs like\n> > pets and not cattle.\n> >\n> \n> Hi Jay,\n> \n> I read every words in your reply and respect what you said.\n> \n> But i can\'t agree with you that memory snapshot is a feature for pat not for cattle.\n> I think it\'s a feature whatever what do you look the instance as.\n> \n> The world doesn\'t care about what we look the instance as, in fact, currently almost all the\n> mainstream hypervisors have supported the memory snapshot.\n> If it\'s just a dispensable feature and no users need it, I can\'t understand why\n> the hypervisors provide it without exception.\n> \n> In the document \" OPENSTACK OPERATIONS GUIDE\" section \" Live snapshots\" has the\n> below words:\n> \" To ensure that important services have written their contents to disk (such as, databases),\n> we recommend you read the documentation for those applications to determine what commands\n> to issue to have them sync their contents to disk. If you are unsure how to do this,\n>  the safest approach is to simply stop these running services normally.\n> \"\n> This just pushes all the responsibility to guarantee the consistency of the instance to the end user.\n> It\'s absolutely not convenient and I doubt whether it\'s appropriate.\n\nHi Ricky,\n\nI guess we will just have to disagree about the relative usefulness of\nthis kind of thing for users of the cloud (and not users of traditional\nmanaged hosting) :) Like I said, if it does not affect the performance\nof other tenants\' instances, I\'m fine with adding the functionality in a\nway that is generic (not hypervisor-specific).\n\nBest,\n-jay\n\n\n\n','<98B730463BF8F84A885ABF3A8F6149516607A688@SZXEMA501-MBS.china.huawei.com>',NULL),('<1394568695.3197.58.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 16:11:35',-14400,'2014-03-11 20:11:35',NULL,'[openstack-dev] [Nova] FFE Request: Ephemeral RBD image support','On Tue, 2014-03-11 at 14:18 -0500, Matt Riedemann wrote:\n> \n> On 3/10/2014 11:20 AM, Dmitry Borodaenko wrote:\n> > On Fri, Mar 7, 2014 at 8:55 AM, Sean Dague <sean at dague.net> wrote:\n> >> On 03/07/2014 11:16 AM, Russell Bryant wrote:\n> >>> On 03/07/2014 04:19 AM, Daniel P. Berrange wrote:\n> >>>> On Thu, Mar 06, 2014 at 12:20:21AM -0800, Andrew Woodward wrote:\n> >>>>> I\'d Like to request A FFE for the remaining patches in the Ephemeral\n> >>>>> RBD image support chain\n> >>>>>\n> >>>>> https://review.openstack.org/#/c/59148/\n> >>>>> https://review.openstack.org/#/c/59149/\n> >>>>>\n> >>>>> are still open after their dependency\n> >>>>> https://review.openstack.org/#/c/33409/ was merged.\n> >>>>>\n> >>>>> These should be low risk as:\n> >>>>> 1. We have been testing with this code in place.\n> >>>>> 2. It\'s nearly all contained within the RBD driver.\n> >>>>>\n> >>>>> This is needed as it implements an essential functionality that has\n> >>>>> been missing in the RBD driver and this will become the second release\n> >>>>> it\'s been attempted to be merged into.\n> >>>>\n> >>>> Add me as a sponsor.\n> >>>\n> >>> OK, great.  That\'s two.\n> >>>\n> >>> We have a hard deadline of Tuesday to get these FFEs merged (regardless\n> >>> of gate status).\n> >>>\n> >>\n> >> As alt release manager, FFE approved based on Russell\'s approval.\n> >>\n> >> The merge deadline for Tuesday is the release meeting, not end of day.\n> >> If it\'s not merged by the release meeting, it\'s dead, no exceptions.\n> >\n> > Both commits were merged, thanks a lot to everyone who helped land\n> > this in Icehouse! Especially to Russel and Sean for approving the FFE,\n> > and to Daniel, Michael, and Vish for reviewing the patches!\n> >\n> \n> There was a bug reported today [1] that looks like a regression in this \n> new code, so we need people involved in this looking at it as soon as \n> possible because we have a proposed revert in case we need to yank it \n> out [2].\n> \n> [1] https://bugs.launchpad.net/nova/+bug/1291014\n> [2] \n> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1291014,n,z\n\nNote that I have identified the source of the problem and am pushing a\npatch shortly with unit tests.\n\nBest,\n-jay\n\n\n\n','<531F618B.8000702@linux.vnet.ibm.com>',NULL),('<1394579930-sup-5991@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 16:25:03',-25200,'2014-03-11 23:25:03',NULL,'[openstack-dev] [Glance] Need to revert \"Don\'t enable all stores by\n	default\"','Hi. I asked in #openstack-glance a few times today but got no response,\nso sorry for the list spam.\n\nhttps://review.openstack.org/#/c/79710/\n\nThis change introduces a backward incompatible change to defaults with\nHavana. If a user has chosen to configure swift, but did not add swift\nto the known_stores, then when that user upgrades Glance, Glance will\nfail to start because their swift configuration will be invalid.\n\nThis broke TripleO btw, which tries hard to use default configurations.\n\nAlso I am not really sure why this approach was taken. If a user has\nexplicitly put swift configuration options in their config file, why\nnot just load swift store? Oslo.config will help here in that you can\njust add all of the config options but not actually expect them to be\nset. It seems entirely backwards to just fail in this case.\n\n\n',NULL,NULL),('<1394581509-sup-1539@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 16:50:04',-25200,'2014-03-11 23:50:04',NULL,'[openstack-dev] UTF-8 required charset/encoding for openstack\n	database?','Excerpts from Ben Nemec\'s message of 2014-03-10 13:02:47 -0700:\n> On 2014-03-10 12:24, Chris Friesen wrote:\n> > Hi,\n> > \n> > I\'m using havana and recent we ran into an issue with heat related to\n> > character sets.\n> > \n> > In heat/db/sqlalchemy/api.py in user_creds_get() we call\n> > _decrypt() on an encrypted password stored in the database and then\n> > try to convert the result to unicode.  Today we hit a case where this\n> > errored out with the following message:\n> > \n> > UnicodeDecodeError: \'utf8\' codec can\'t decode byte 0xf2 in position 0:\n> > invalid continuation byte\n> > \n> > We\'re using postgres and currently all the databases are using\n> > SQL_ASCII as the charset.\n> > \n> > I see that in icehouse heat will complain if you\'re using mysql and\n> > not using UTF-8.  There doesn\'t seem to be any checks for other\n> > databases though.\n> > \n> > It looks like devstack creates most databases as UTF-8 but uses latin1\n> > for nova/nova_bm/nova_cell.  I assume this is because nova expects to\n> > migrate the db to UTF-8 later.  Given that those migrations specify a\n> > character set only for mysql, when using postgres should we explicitly\n> > default to UTF-8 for everything?\n> > \n> > Thanks,\n> > Chris\n> \n> We just had a discussion about this in #openstack-oslo too.  See the \n> discussion starting at 2014-03-10T16:32:26 \n> http://eavesdrop.openstack.org/irclogs/%23openstack-oslo/%23openstack-oslo.2014-03-10.log\n> \n> While it seems Heat does require utf8 (or at least matching character \n> sets) across all tables, I\'m not sure the current solution is good.  It \n> seems like we may want a migration to help with this for anyone who \n> might already have mismatched tables.  There\'s a lot of overlap between \n> that discussion and how to handle Postgres with this, I think.\n> \n> I don\'t have a definite answer for any of this yet but I think it is \n> something we need to figure out, so hopefully we can get some input from \n> people who know more about the encoding requirements of the Heat and \n> other projects\' databases.\n\nDoing a migration for this is haphazard. MySQL has _four_ places which\ngovern character set of any operation.\n\nserver charset\nclient charset\ndb charset\ntable charset\n\nThere are also per-column charsets but those basically trump all the\nothers.\n\nBut MySQL can\'t possibly know what you _meant_ when you were inserting\ndata. So, if you _assumed_ that the database was UTF-8, and inserted\nUTF-8 with all of those things accidentally set for latin1, then you\nwill have UTF-8 in your db, but MySQL will think it is latin1. So if you\nnow try to alter the table to UTF-8, all of your high-byte strings will\nbe double-encoded.\n\nIt unfortunately takes analysis to determine what the course of action\nis. That is why we added the check to Heat, so that it would complain\nvery early if your tables and/or server configuration were going to\ndisagree with the assumptions.\n\nIt would likely be best for there to be a more generally available\nsolution for stopping and complaining loudly when a badly configured\ndatabase is encountered.\n\n\n','<e7ab9d3ab19b6c4f7942fa2a25fa1c23@localhost>',NULL),('<1394585656.31705.0.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-03-12 00:54:16',0,'2014-03-12 00:54:16',NULL,'[OpenStack Foundation] March 4 board meeting','Hey\n\nHere\'s my informal summary of last week\'s all day, in-person board\nmeeting:\n\nhttp://blogs.gnome.org/markmc/2014/03/12/mar-4-openstack-foundation-board-meeting/\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1394587669.3197.74.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-11 21:27:49',-14400,'2014-03-12 01:27:49',NULL,'[Openstack-operators] [TripleO] Default logging configuration','On Wed, 2014-03-12 at 08:28 +1300, Robert Collins wrote:\n> Hi - I filed https://bugs.launchpad.net/tripleo/+bug/1290759 last\n> night after we found yet another CI issue that just cannot be debugged\n> with the default logging configuration and also chatting with some of\n> our public cloud folk who are experimenting with TripleO -- turns out\n> that we don\'t run the default logging configuration in public cloud\n> because it\'s not suitable for analysing and solving issues.\n> \n> I\'m seeking a copy of the actual configuration thats used, though it\n> sounds like its just \'debugging\' except for Neutron which was tooooo\n> verbose.\n> \n> However, I\'d like to do a poll - what do you, dear operators, do for logging.\n> \n> - Whats your default log level (upstream default, verbose, debug,\n> something special?)\n\nPretty much has to be DEBUG if you want to find anything useful,\nunfortunately.\n\n> - How do you handle log overload?\n>   - Do you overlog and prune on display (e.g. via logstash / kibana)\\\n>   - Do you increase logging only after a fault and hope it is reproducible?\n>   - Do you overlog and just deal with the volume?\n\nThis.\n\n>   - Do you not care about logs for fault analysis?\n> - What would you like to see most from upstream log defaults?\n\n1) Better and more consistent information in debug messages.\n\nSean Dague has an effort already underway to tackle this issue across\nprojects. Things like dumping the contents of message packets into a\ndebug log message are, IMO, useless and clutter even the debug-level\nlogs. The more clutter in the logs like that (and most of the\ninformation in the various WSGI and keystoneclient.middleware.auth_token\nmodules) makes it very difficult to identify more important things, like\nwhen certain important events in a task chain occur.\n\n2) More INFO level messages\n\nINFO level is underused IMO. INFO messages should generally be short(er\nthan debug messages), provide a codified message that indicates that a\ncondition was met or an event succeeded or failed (when the failure was\nexpected). We should be able to view a log with only INFO log level\nmessages and pretty clearly see the flow of a request through one or\nmore OpenStack endpoints. Unfortunately, today, there is little\nconsitency on where important \"checkpoint\" events log an INFO message.\n\n3) Better consistency about the PID or thread/greenlet identifiers.\n\nSome modules use a different format string than others to show the\nprocess id and/or greenlet id, which makes debugging thread-related\nissues cumbersome.\n\nBest,\n-jay\n\n> Right now, TripleO is in an awkward position - we\'re realising that\n> the defaults in OpenStack are not suitable for production use, but the\n> developer community believes the problem is *too much logging* vs *too\n> little* - so I\'m seeking to get more information, and find out what\n> other ops folk are doing, with the intent of\n> getting one (or perhaps more) basic profiles that meet operator needs\n> without everyone reinventing the wheel.\n> \n> -Rob\n> \n\n\n\n\n','<CAJ3HoZ2fj87RFKwxjdKLsvk3E3mu7TfrMa1X1jYRcSRUvuaxgw@mail.gmail.com>',NULL),('<1394593853.3197.75.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 23:10:53',-14400,'2014-03-12 03:10:53',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n soft deletion (step by step)','On Wed, 2014-03-12 at 01:47 +0000, Joshua Harlow wrote:\n> The question that I don\'t understand is why does this process have to be\n> involve the database to begin with?\n> \n> If you want to archive images per-say, on deletion just export it to a\n> \'backup tape\' (for example) and store enough of the metadata on that\n> \'tape\' to re-insert it if this is really desired and then delete it from\n> the database (or do the export... asynchronously). The same could be said\n> with VMs, although likely not all resources, aka networks/.../ make sense\n> to do this.\n> \n> So instead of deleted = 1, wait for cleaner, just save the resource (if\n> possible) + enough metadata on some other system (\'backup tape\', alternate\n> storage location, hdfs, ceph...) and leave it there unless it\'s really\n> needed. Making the database more complex (and all associated code) to\n> achieve this same goal seems like a hack that just needs to be addressed\n> with a better way to do archiving.\n> \n> In a cloudy world of course people would be able to recreate everything\n> they need on-demand so who needs undelete anyway ;-)\n\nGood points.\n\nAnother way to ask the question: does Amazon provide an undelete\nfunctionality?\n\nBest,\n-jay\n\n\n\n','<CF450835.592B3%harlowja@yahoo-inc.com>',NULL),('<1394596378.92411.YahooMailNeo@web193605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-12 11:52:58',28800,'2014-03-12 03:52:58',NULL,'[Openstack] problem in log in django swiftbrowser','please somebody reply.\n\n\n\nOn Tuesday, 11 March 2014 4:14 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhi krish\n>\n>I am pasting the logs\n>\n>http://paste.openstack.org/show/73122/\n>\n>Please help me understand where is the problem\n>\n>Thanks \n>Pragya Jain\n>\n>\n>\n>\n>On Tuesday, 11 March 2014 3:28 PM, krish <das.srikrishna at gmail.com> wrote:\n> \n>Run an ls -ltr in ?/var/log/ ?or /var/log/swift\n>>\n>>\n>>Check what corresponds to the same time as you try to login.\n>>Try tailing those logs or use less to open them and read through. Figure out :)\n>>May be you\'ll find the problem.\n>>\n>>\n>>\n>>On Tue, Mar 11, 2014 at 3:22 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>\n>>hi krish?\n>>>\n>>>\n>>>From where should I get the logs for the same?\n>>>\n>>>\n>>>Thanks?\n>>>Pragya Jain\n>>>\n>>>\n>>>\n>>>On Tuesday, 11 March 2014 3:04 PM, krish <das.srikrishna at gmail.com> wrote:\n>>> \n>>>you might want to pastebin your logs rather than attaching screenshots of blank page :)\n>>>>\n>>>>\n>>>>\n>>>>On Tue, Mar 11, 2014 at 12:14 PM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n>>>>\n>>>>hello all,?\n>>>>>\n>>>>>\n>>>>>I had installed django swiftbrowser on a VM of Ubuntu 12.04 desktop using the link?https://github.com/cschwede/django-swiftbrowser\n>>>>>\n>>>>>\n>>>>>when i login by entering a username and password on login screen, it shows a blank screen.(screenshots attached)\n>>>>>\n>>>>>\n>>>>>CLI gives following messages:\n>>>>>\n>>>>>\n>>>>>root at pragya-VirtualBox:~/django-swiftbrowser/myproj# python manage.py runserver --insecure\n>>>>>\n>>>>>\n>>>>>\n>>>>>OUTPUT:\n>>>>>Validating models...\n>>>>>\n>>>>>0 errors found\n>>>>>March 03, 2014 - 11:58:30\n>>>>>Django version 1.6.2, using settings \'myproj.settings\'\n>>>>>Starting development server at http://127.0.0.1:8000/\n>>>>>Quit the server with CONTROL-C.\n>>>>>[03/Mar/2014\n 11:59:00] \"GET / HTTP/1.1\" 302 0\n>>>>>[03/Mar/2014 11:59:01] \"GET /login/ HTTP/1.1\" 200 3799\n>>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1\" 200 106015\n>>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/css/bootstrap-responsive.min.css HTTP/1.1\" 200 16849\n>>>>>[03/Mar/2014 11:59:01] \"GET /static/jquery.min.js HTTP/1.1\" 200 93107\n>>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/js/bootstrap.min.js HTTP/1.1\" 200 28631\n>>>>>[03/Mar/2014 11:59:01] \"GET /static/bootstrap/img/glyphicons-halflings-white.png HTTP/1.1\" 200 8777\n>>>>>[03/Mar/2014 11:59:17] \"POST /login/ HTTP/1.1\" 500 0\n>>>>>\n>>>>>\n>>>>>I can\'t understand where is the problem.\n>>>>>\n>>>>>\n>>>>>Please somebody help me to resolve it.\n>>>>>\n>>>>>\n>>>>>Thanks?\n>>>>>Pragya Jain\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>>_______________________________________________\n>>>>>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>Post to ? ? : openstack at lists.openstack.org\n>>>>>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>\n>>>>\n>>>>\n>>>>-- \n>>>>\n>>>>Have a Power-Up Day!\n>>>>--\n>>>>Krish\n>>>>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>>>>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>\n>>-- \n>>\n>>Have a Power-Up Day!\n>>--\n>>Krish\n>>I lives in a cave(facebook.com/toonheart)?nd writes me games.\n>>Releasing \"Baka\" soon! - http://facebook.com/HungryBaka\n>>\n>>\n>>\n>>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140312/2372a8a5/attachment.html>\n\n','<1394534677.35409.YahooMailNeo@web193602.mail.sg3.yahoo.com>',NULL),('<1394606122723-34942.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 23:35:22',-25200,'2014-03-12 06:35:22',NULL,'[openstack-dev] [Openstack][Nova][Docker] Devstack with docker\n	driver','hello there,i setup using devstack ..below is my docker version output\n--------------------------------------------------------------------------------------------------\nredhat at test:~/devstack$ docker version\nClient version: 0.7.6\nGo version (client): go1.2\nGit commit (client): bc3b2ec\nServer version: 0.7.6\nGit commit (server): bc3b2ec\nGo version (server): go1.2\nLast stable version: 0.9.0, please update docker\n---------------------------------------------------------------------------------------------------\nI followed a guide from\n*http://damithakumarage.wordpress.com/2014/01/31/how-to-setup-openstack-havana-with-docker-driver/*\n\n---------------------------------------------------------------------------------------------------\nI tagged an image using \n\n$ docker tag urgensherpa/lamp6 192.168.140.193:5042/lamp6\nBelow is my \'docker push\' commad output.\n\nredhat at test:~/devstack$ docker push 192.168.140.193:5042/lamp6\n\nThe push refers to a repository [192.168.140.193:5042/lamp6] (len: 1)\nSending image list\nPushing repository 192.168.140.193:5042/lamp6 (1 tags)\n2014/03/11 13:22:03 HTTP code 500 while uploading metadata: invalid\ncharacter ?<\' looking for beginning of value\n------------------------------------------------------------------------------------------------------\nPlease let me know what i need to do thanks \n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/Openstack-Nova-Docker-Devstack-with-docker-driver-tp28361p34942.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<CABf-1jaZG_p3+f8GUhpvQ+H1DPYKod37nMagZPXhzf=hsgWvaQ@mail.gmail.com>',NULL),('<1394644206.3197.90.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 13:10:06',-14400,'2014-03-12 17:10:06',NULL,'[openstack-dev] [Glance] Need to revert \"Don\'t enable all\n stores by default\"','On Wed, 2014-03-12 at 07:18 -0400, Sean Dague wrote:\n> On 03/12/2014 06:38 AM, Flavio Percoco wrote:\n> > On 11/03/14 16:25 -0700, Clint Byrum wrote:\n> >> Hi. I asked in #openstack-glance a few times today but got no response,\n> >> so sorry for the list spam.\n> >>\n> >> https://review.openstack.org/#/c/79710/\n> >>\n> >> This change introduces a backward incompatible change to defaults with\n> >> Havana. If a user has chosen to configure swift, but did not add swift\n> >> to the known_stores, then when that user upgrades Glance, Glance will\n> >> fail to start because their swift configuration will be invalid.\n> >>\n> >> This broke TripleO btw, which tries hard to use default configurations.\n> > \n> > I don\'t think this change has to be reverted. We could add an upgrade\n> > path for this. We could enable a driver if its config options were set\n> > and warn the user about this change. Also, we could make sure we\n> > import all drivers and the config options are registered but that we\n> > don\'t try to enable them.\n> > \n> > Also, I don\'t expect (yeah, I know this is not always the case) users to\n> > blindly upgrade if they really care about their cloud deployment.\n> > Since this change will be part of the change log and the release\n> > notes, I expect the user to be aware of it.\n> \n> OpenStack\'s 2 largest public clouds don\'t wait for releases, so that\'s\n> not really a good answer.\n> \n> >>\n> >> Also I am not really sure why this approach was taken. If a user has\n> >> explicitly put swift configuration options in their config file, why\n> >> not just load swift store? Oslo.config will help here in that you can\n> >> just add all of the config options but not actually expect them to be\n> >> set. It seems entirely backwards to just fail in this case.\n> > \n> > This is exactly the problem. With the current approach, the user has\n> > not explicitly enabled the swift store. The user just put swift\n> > configs. With the current \'enable all and let it fail\' approach, it is\n> > really confusing for users to see all the failures and it\'s not nice to\n> > enable things by default for the user.\n> > \n> > Thanks for raising this issue, I didn\'t think about this corner\n> > case.\n> > Flavio\n> \n> In fairness, this wasn\'t a corner case. Grenade was blocking this change\n> for the whole cycle until a change was made in stable/havana devstack\n> that sneaked around it with https://review.openstack.org/#/c/75827/.  :)\n> \n> In addition, the commit in question for glance -\n> https://review.openstack.org/#/c/59150/ didn\'t have UpgradeImpact, which\n> is the signaling mechanism for these kinds of issues.\n> \n> I do think this is a real issue. OpenStack really is expected to be CD\n> upgradable, not just post release and post release notes. Commits in\n> OpenStack need to take that into account.\n> \n> A compatibility behavior should be put in place here.\n> \n> I do agree the current behavior isn\'t nice with gorpy error messages all\n> the time. However, a completely legitimate approach would be:\n> \n> If configuration for a storage back end existed, but the driver wasn\'t\n> explicitly set, load and configure that driver and throw a big\n> DEPRECATION WARNING in the logs that Glance will require explicit\n> loading of drivers in an upcoming release. That would let you move\n> forward, and provide some user signally.\n\nThat\'s pretty much what already happens. On startup, Glance will log a\nmessage about a particular store driver being disabled [1] because\nconfiguration settings were not set properly. [2]\n\nIIRC, on startup is the only place these messages occur (not, for\ninstance, every time somebody uploads an image), so I\'m not entirely\nsure what the big deal was.\n\nLong term, moving stores into entrypoints might be a cleaner solution,\nbut you will still need to validate configuration for those endpoints on\nstartup -- all endpoints give you is a cleaner method than \"set your new\nstore in the known_stores configuration option\".\n\nBest,\n-jay\n\n[1]\nhttps://github.com/openstack/glance/blob/master/glance/store/__init__.py#L180\n\n[2]\npor ejemplo:\nhttps://github.com/openstack/glance/blob/master/glance/store/filesystem.py#L179\nhttps://github.com/openstack/glance/blob/master/glance/store/swift.py#L655\n\n> That is definitely more effort, but as a community we\'ve decided to\n> support the CD method for OpenStack, which means we need to take account\n> of these kinds of cases.\n> \n> 	-Sean\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53204276.9010607@dague.net>',NULL),('<1394644531.3197.92.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 13:15:31',-14400,'2014-03-12 17:15:31',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n soft deletion (step by step)','On Wed, 2014-03-12 at 11:37 +0000, CARVER, PAUL wrote:\n> I have personally witnessed someone (honestly, not me) select \"Terminate Instance\" when they meant \"Reboot Instance\" and that mistake is way too easy. I\'m not sure if it was a brain mistake or mere slip of the mouse, but it\'s enough to make people really nervous in a production environment. If there\'s one thing you can count on about human beings, it\'s that they\'ll make mistakes sooner or later. Any system that assumes infallible human beings as a design criteria is making an invalid assumption.\n\nThat\'s why GUIs should have a dialog box that says \"Are you sure you\nwant to terminate this server?\".\n\nThere\'s prevention of common mistakes, and then there\'s going out of\nyour way to ensure that the cloud acts like a text editor with an\nunlimiited undo buffer.\n\nBest,\n-jay\n\n\n\n','<A81F249089B6C7479786834457908C600AC6F238@MISOUT7MSGUSR9N.ITServices.sbc.com>',NULL),('<1394645522.5931.0.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-12 13:32:02',-14400,'2014-03-12 17:32:02',NULL,'[OpenStack-Infra] JJB release?','On Wed, 2014-03-12 at 09:01 -0700, James E. Blair wrote:\n> Khai suggested it\'s time (or past time) for a JJB release.  Antoine\n> points out that before merging thread and pbr support might be a good\n> time for a release too.  I note that we just fixed python 2.6 support as\n> well.  So how about I tag:\n> \n> 6e72dc3781fcaed1526317c27762fba44cd8a43e\n> \n> as 0.7.0?\n\n++\n\n\n\n','<87a9cvflsy.fsf@meyer.lemoncheese.net>',NULL),('<1394645655.5931.2.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 13:34:15',-14400,'2014-03-12 17:34:15',NULL,'[openstack-dev] [Glance] Need to revert \"Don\'t enable all\n stores by default\"','On Wed, 2014-03-12 at 13:21 -0400, Sean Dague wrote:\n> On 03/12/2014 01:10 PM, Jay Pipes wrote:\n> > On Wed, 2014-03-12 at 07:18 -0400, Sean Dague wrote:\n> >> On 03/12/2014 06:38 AM, Flavio Percoco wrote:\n> >>> On 11/03/14 16:25 -0700, Clint Byrum wrote:\n> >>>> Hi. I asked in #openstack-glance a few times today but got no response,\n> >>>> so sorry for the list spam.\n> >>>>\n> >>>> https://review.openstack.org/#/c/79710/\n> >>>>\n> >>>> This change introduces a backward incompatible change to defaults with\n> >>>> Havana. If a user has chosen to configure swift, but did not add swift\n> >>>> to the known_stores, then when that user upgrades Glance, Glance will\n> >>>> fail to start because their swift configuration will be invalid.\n> >>>>\n> >>>> This broke TripleO btw, which tries hard to use default configurations.\n> >>>\n> >>> I don\'t think this change has to be reverted. We could add an upgrade\n> >>> path for this. We could enable a driver if its config options were set\n> >>> and warn the user about this change. Also, we could make sure we\n> >>> import all drivers and the config options are registered but that we\n> >>> don\'t try to enable them.\n> >>>\n> >>> Also, I don\'t expect (yeah, I know this is not always the case) users to\n> >>> blindly upgrade if they really care about their cloud deployment.\n> >>> Since this change will be part of the change log and the release\n> >>> notes, I expect the user to be aware of it.\n> >>\n> >> OpenStack\'s 2 largest public clouds don\'t wait for releases, so that\'s\n> >> not really a good answer.\n> >>\n> >>>>\n> >>>> Also I am not really sure why this approach was taken. If a user has\n> >>>> explicitly put swift configuration options in their config file, why\n> >>>> not just load swift store? Oslo.config will help here in that you can\n> >>>> just add all of the config options but not actually expect them to be\n> >>>> set. It seems entirely backwards to just fail in this case.\n> >>>\n> >>> This is exactly the problem. With the current approach, the user has\n> >>> not explicitly enabled the swift store. The user just put swift\n> >>> configs. With the current \'enable all and let it fail\' approach, it is\n> >>> really confusing for users to see all the failures and it\'s not nice to\n> >>> enable things by default for the user.\n> >>>\n> >>> Thanks for raising this issue, I didn\'t think about this corner\n> >>> case.\n> >>> Flavio\n> >>\n> >> In fairness, this wasn\'t a corner case. Grenade was blocking this change\n> >> for the whole cycle until a change was made in stable/havana devstack\n> >> that sneaked around it with https://review.openstack.org/#/c/75827/.  :)\n> >>\n> >> In addition, the commit in question for glance -\n> >> https://review.openstack.org/#/c/59150/ didn\'t have UpgradeImpact, which\n> >> is the signaling mechanism for these kinds of issues.\n> >>\n> >> I do think this is a real issue. OpenStack really is expected to be CD\n> >> upgradable, not just post release and post release notes. Commits in\n> >> OpenStack need to take that into account.\n> >>\n> >> A compatibility behavior should be put in place here.\n> >>\n> >> I do agree the current behavior isn\'t nice with gorpy error messages all\n> >> the time. However, a completely legitimate approach would be:\n> >>\n> >> If configuration for a storage back end existed, but the driver wasn\'t\n> >> explicitly set, load and configure that driver and throw a big\n> >> DEPRECATION WARNING in the logs that Glance will require explicit\n> >> loading of drivers in an upcoming release. That would let you move\n> >> forward, and provide some user signally.\n> > \n> > That\'s pretty much what already happens. On startup, Glance will log a\n> > message about a particular store driver being disabled [1] because\n> > configuration settings were not set properly. [2]\n> > \n> > IIRC, on startup is the only place these messages occur (not, for\n> > instance, every time somebody uploads an image), so I\'m not entirely\n> > sure what the big deal was.\n> > \n> > Long term, moving stores into entrypoints might be a cleaner solution,\n> > but you will still need to validate configuration for those endpoints on\n> > startup -- all endpoints give you is a cleaner method than \"set your new\n> > store in the known_stores configuration option\".\n> \n> The issue is this was a failure going from old defaults to new defaults,\n> which is why it was actually blocked by grenade for months.\n> \n> The difference is actually we should be working with the drivers that\n> were configured, and deprecate the fact that you can get away without\n> specifying them.\n> \n> Then you can roll forward gracefully, see a warning message on your\n> working new config, go handle the situation, and later when the\n> backwards compatible behavior is removed you are ok.\n\nI think you may have misunderstood me :) I was saying that I don\'t\nunderstand what the big deal was about log messages on startup around\nfailure to configure drivers properly. I didn\'t think that was something\nthat needed to be \"fixed\".\n\nBest,\n-jay\n\n\n\n','<532097A5.3050804@dague.net>',NULL),('<1394647116.5931.3.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 13:58:36',-14400,'2014-03-12 17:58:36',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n soft deletion (step by step)','On Wed, 2014-03-12 at 17:35 +0000, Tim Bell wrote:\n> And if the same mistake is done for a cinder volume or a trove database ?\n\nSnapshots and backups?\n\nBest,\n-jay\n\n> \n> > -----Original Message-----\n> > From: Joshua Harlow [mailto:harlowja at yahoo-inc.com]\n> > Sent: 12 March 2014 17:02\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Cc: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)\n> > \n> > Understandable,\n> > \n> > Humans will be humans after all.\n> > \n> > To me if openstsck is a cloud platform then coming along with it should be best practices that come with the usage of a cloud\n> > platform (treat your instances as ephemeral, use configuration management, save your stuff in source control...). I have been\n> > preaching similar stuff at y! and getting people into the right mindset around \"the cloud\" is IMHO more important than making\n> > openstack fit peoples non-cloudy mindset.\n> > \n> > Because once u teach a person to use the cloud right u don\'t need to have openstack compensate for them using it incorrectly.\n> > \n> > Sent from my really tiny device...\n> > \n> > > On Mar 12, 2014, at 4:45 AM, \"CARVER, PAUL\" <pc2929 at att.com> wrote:\n> > >\n> > > I have personally witnessed someone (honestly, not me) select \"Terminate Instance\" when they meant \"Reboot Instance\" and that\n> > mistake is way too easy. I\'m not sure if it was a brain mistake or mere slip of the mouse, but it\'s enough to make people really\n> > nervous in a production environment. If there\'s one thing you can count on about human beings, it\'s that they\'ll make mistakes\n> > sooner or later. Any system that assumes infallible human beings as a design criteria is making an invalid assumption.\n> > >\n> > > --\n> > > Paul Carver\n> > > VO: 732-545-7377\n> > > Cell: 908-803-1656\n> > > E: pcarver at att.com\n> > > Q Instant Message\n> > >\n> > >\n> > > -----Original Message-----\n> > > From: Tim Bell [mailto:Tim.Bell at cern.ch]\n> > > Sent: Tuesday, March 11, 2014 15:43\n> > > To: OpenStack Development Mailing List (not for usage questions)\n> > > Subject: Re: [openstack-dev] [all][db][performance] Proposal: Get rid\n> > > of soft deletion (step by step)\n> > >\n> > >\n> > > Typical cases are user error where someone accidentally deletes an item from a tenant. The image guys have a good structure\n> > where images become unavailable and are recoverable for a certain period of time. A regular periodic task cleans up deleted items\n> > after a configurable number of seconds to avoid constant database growth.\n> > >\n> > > My preference would be to follow this model universally (an archive table is a nice way to do it without disturbing production).\n> > >\n> > > Tim\n> > >\n> > >\n> > >>> On Tue, Mar 11, 2014, Mike Wilson <geekinutah at gmail.com> wrote:\n> > >>> Undeleting things is an important use case in my opinion. We do this\n> > >>> in our environment on a regular basis. In that light I\'m not sure\n> > >>> that it would be appropriate just to log the deletion and git rid of\n> > >>> the row. I would like to see it go to an archival table where it is easily restored.\n> > >>\n> > >> I\'m curious, what are you undeleting and why?\n> > >>\n> > >> JE\n> > >>\n> > >>\n> > >> _______________________________________________\n> > >> OpenStack-dev mailing list\n> > >> OpenStack-dev at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9A7DB17@CERNXCHG41.cern.ch>',NULL),('<1394655784-sup-9590@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-12 13:31:13',-25200,'2014-03-12 20:31:13',NULL,'[openstack-dev] [Ironic] Manual scheduling nodes in maintenance\n	mode','Excerpts from Chris Jones\'s message of 2014-03-12 13:07:21 -0700:\n> Hey\n> \n> I wanted to throw out an idea that came to me while I was working on\n> diagnosing some hardware issues in the Tripleo CD rack at the sprint last\n> week.\n> \n> Specifically, if a particular node has been dropped from automatic\n> scheduling by the operator, I think it would be super useful to be able to\n> still manually schedule the node. Examples might be that someone is\n> diagnosing a hardware issue and wants to boot an image that has all their\n> favourite diagnostic tools in it, or they might be booting an image they\n> use for updating firmwares, etc (frankly, just being able to boot a\n> generic, unmodified host OS on a node can be super useful if you\'re trying\n> to crash cart the machine for something hardware related).\n> \n> Any thoughts? :)\n> \n\n+1 from me, as I\'ve been in the exact same boat (perhaps the same piece\nof hardware even. ;)\n\nI imagine it as a nova scheduler hint that finds its way into Ironic\neventually.\n\n\n','<CAHWFm4drY2iCXh7L_1=NoU4adZhKa7vmY8bi=6DUsmTgaczCNw@mail.gmail.com>',NULL),('<1394716758.5431.158.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-13 09:19:18',-14400,'2014-03-13 13:19:18',NULL,'[Openstack-docs] Config reference news','On Wed, 2014-03-12 at 15:36 -0400, Steve Gordon wrote:\n> ----- Original Message -----\n> > Hi!\n> > \n> > This change is raising a big question: how do we handle duplication of\n> > tables. Tables now have an xml:id attribute, and multiple inclusions of\n> > tables make the build fail [0]. Here are a few solutions:\n> > \n> > 1) find a way to include tables multiple times in the config-ref book\n> > (docbook magic).\n> \n> There\'s no real magic possible here, each element in the DOM that has\n> an ID must have a *unique* ID. Including the tables twice results in\n> this not being the case.\n\nXInclude 1.1 has a way of handling this. But it\'s still just a working\ndraft, and I doubt our tools support it. (dcramer: ping)\n\n> > 2) include tables in pages where they are actually needed, and add a\n> > \"misc options\" page which includes all remaining tables.\n> > 3) create a page including all the tables, and xlink from other\n> pages.\n> \n> This is my preference for consistency and to benefit maintenance. At\n> the moment it\'s kind of difficult for the chapters that don\'t do this\n> to work out which tables are missing because the ones that are there\n> are spread around in the hierarchy. I would add that really it\'s a\n> subset of the chapters (particularly compute and block storage) that\n> aren\'t doing this already.\n\nI agree with this, because...\n\n[snip]\n\n> The script would then generate both the tables (as it does today) and\n> the top level files for the book itself that link the tables into the\n> hierarchy, potentially with a xi:include to a predictable location for\n> the overview for that group if one was written (we would place them\n> into this location) and an xi:fallback to a known small/null snippet\n> to catch cases where none exists (maybe even a call to action, know\n> about this section? help us write an overview!).\n\nI agree with this. As you generate the tables right now, you have to\nmake sure new tables are included, and watch out for deleted tables.\nWhen tables are added, it\'s sometimes hard to fit them into the ad-hoc\nnarrative. When tables are deleted, sometimes the file that included\nthem has to be deleted, and you have to follow the chain up of including\nfiles. It\'s really a pain. I\'d much rather auto-generate everything.\n\n--\nShaun\n\n\n\n\n','<367174418.34237075.1394652980721.JavaMail.zimbra@redhat.com>',NULL),('<1394730472.4781.63.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-13 17:07:52',0,'2014-03-13 17:07:52',NULL,'[openstack-tc] Draft bylaws changes from DefCore bylaws subcommittee','Hey\n\nI haven\'t been following this committee\'s progress and I can\'t speak to\nthe rationale here, but a draft set of bylaws changes are being\ndiscussed by the committee:\n\n  http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html\n\nThis part is obviously going to be something of interest to the TC:\n\n    (c) (i)  The Technical Committee shall have the authority to\n             determine the scope of the OpenStack Project subject to the\n             procedures described below. \n\n       (ii)  The Technical Committee shall propose a process or\n             procedure to determine the scope of the OpenStack Project.\n             The Board of Directors may propose modifications to such\n             process or procedure but such modifications must be\n             approved by the Technical Committee. After the Technical\n             Committee has approved the final process or procedure for\n             determining the scope of the OpenStack Project and the\n             Board of Directors has approved such process or procedure,\n             the Board of Directors shall set the date on which such\n             process or procedure becomes effective and the first such\n             date shall be defined as the OSP New Definition Date. \n             After the OSP New Definition Date, the Technical Committee\n             may propose modifications to such process and procedure.\n             The Board of Directors shall consider such modifications\n             and may approve or disapprove them. If the Board of\n             Directors approves such modifications, the modified process\n             and procedure shall become the method for determining the\n             scope of the OpenStack Project on the effective date set by\n             the Board of Directors.  The process or procedure shall be\n             described in reasonable detail in the minutes of the Board\n             of Directors which approved it. After such approval, the\n             Secretary shall post such description to the Foundation?s\n             website.\n\nJust on a call with the committee here and it seems the intent is to\nchange the process around OpenStack capabilities associated with the\ntrademark (i.e. what we now call \"Core\") as opposed to changing the\nprocess around adding new projects to the integrated release.\n\nHowever, right now I think we equate \"the OpenStack Project\" to the\nintegrated release, so the actual wording does suggest a change to the\nTC\'s authority.\n\nMark.\n\n\n\n',NULL,NULL),('<1394732811.1820244.1392293356978.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-02-13 07:09:16',-18000,'2014-02-13 12:09:16',NULL,'[Openstack-stable-maint] 2013.2.2 exception requests','Hi, see below.\n\n----- Original Message -----\n> Retrying the ssh connection with on all ssh exception may help.\n> \n> It is possible the ssh server causes this type of exception,\n> when the key or the ssh service being configured by cloud-init.\n> \n\nFirst, tests don\'t use cloud-init based images to start new nova instances. Cirros images use some similar, but another service to set instance up. See: http://bazaar.launchpad.net/~smoser/cirros/trunk/view/head:/src/sbin/cirros-ds\n\nThe fix in question is for neutron-metadata-agent, and it was not hit by any requests from the new instance created by tempest, meaning the instance either failed to run, or network connection was not properly established. Nova-api log shows that new nova instance state is polled for some time (~6 mins), but its port is always in DOWN state.\n\n> It also can hide a temporary network black hole issue.\n> \n\nThe instance is created at ~00:59:??, the test fails at ~01:06:??, so it\'s hardly temporary.\n\n> These are not scientifically proven things, but\n> https://review.openstack.org/#/c/73186/.\n> \n> NOTE: We are using the same ssh code to make connection,\n> in nova network jobs since long..\n> \n\nThis review catches another exception type (SSHException). Does it mean that if that would be our issue, we would see SSHException tracebacks in tempest log? There\'s no such thing there.\n\n> The other mentioned changes probably does not have impact to the stability,\n> they mainly improves the logging of the failures.\n> \n> The 9f756a081533b55f212221ea5de8ed968acea273 and the following patches\n>  might decrease the load on the l3 agent,\n> but it would be more difficult to backport.\n> \n> I do not remember anything else in tempest what may help to\n>  make the stable/havana neutron jobs more stable.\n> \n\nThere was also some bug in file injection to a new instance in gate that made ssh sessions fail. Something related to guestfs, but I don\'t know all the details. Adding Russel to Cc since he may have more info on this.\n\n> Best Regards,\n> Attila\n> \n> ----- Original Message -----\n> > From: \"Alan Pevec\" <apevec at gmail.com>\n> > To: \"Gary Kotton\" <gkotton at vmware.com>, \"Attila Fazekas\"\n> > <afazekas at redhat.com>, \"Joe Gordon\" <joe.gordon0 at gmail.com>,\n> > \"David Kranz\" <dkranz at redhat.com>, mtreinish at kortar.org, \"Sean Dague\"\n> > <sean at dague.net>\n> > Cc: \"openstack-stable-maint\" <openstack-stable-maint at lists.openstack.org>\n> > Sent: Wednesday, February 12, 2014 11:44:58 PM\n> > Subject: Re: [Openstack-stable-maint] 2013.2.2 exception requests\n> > \n> > Copying authors of tempest patches referenced below + few Tempest core\n> > members who might be interested.\n> > \n> > >> https://review.openstack.org/#/c/72754/\n> > > That\'s a good candidate for exception, and I see Neutron stable-maint\n> > > members already approved but it\'s failing *-isolated gate jobs.\n> > > I\'ll try throwing dice few more times, but could someone familiar have a\n> > > look?\n> > > What are those jobs doing?\n> > \n> > Ihar commented in the review: \" I suspect tempest lacks some of those\n> > ssh.py fixes from master:\n> > c3128c085c2635d82c4909d1be5d016df4978632\n> > ad7ef7d1bdd98045639ee4045144c8fe52853e76\n> > 31a91a605a25f578b51a7bed2df8fde5c5f49ffc\n> > I\'m not sure this would be enough to stabilize gate though.\"\n> > \n> > Gary, Attila, Joe - would you like to backport your patches to\n> > stable/havana Tempest?\n> > Do you agree they should improve gate stability and is there anything\n> > else to be backported to stabilize *-isolated gate jobs?\n> > \n> > \n> > Thanks,\n> > Alan\n> > \n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> \n\n\n','<346049280.6186057.1392283713563.JavaMail.zimbra@redhat.com>',NULL),('<1394738668-sup-2253@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 12:25:30',-25200,'2014-03-13 19:25:30',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n	soft deletion (step by step)','Excerpts from Jay Pipes\'s message of 2014-03-12 10:58:36 -0700:\n> On Wed, 2014-03-12 at 17:35 +0000, Tim Bell wrote:\n> > And if the same mistake is done for a cinder volume or a trove database ?\n> \n> Snapshots and backups?\n> \n\nand bears, oh my!\n\n+1, whether it is large data on a volume or saved state in the RAM of\na compute node, it isn\'t safe unless it is duplicated.\n\n\n','<1394647116.5931.3.camel@cranky>',NULL),('<1394738674.5931.29.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 15:24:34',-14400,'2014-03-13 19:24:34',NULL,'[openstack-dev] [sahara] team meeting minutes March 13 [savanna]','On Thu, 2014-03-13 at 23:13 +0400, Sergey Lukjanov wrote:\n> Thanks everyone who have joined Savanna meeting.\n\nYou mean Sahara? :P\n\n-jay\n\n\n\n','<CA+GZd7_ikc6tSf9mLRrP1E+0ey2acQLQQNxY_gzoM3iTn50LhQ@mail.gmail.com>',NULL),('<1394738807-sup-3001@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 12:30:03',-25200,'2014-03-13 19:30:03',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n	soft deletion (step by step)','Excerpts from Tim Bell\'s message of 2014-03-12 11:02:25 -0700:\n> \n> > \n> > If you want to archive images per-say, on deletion just export it to a \'backup tape\' (for example) and store enough of the metadata\n> > on that \'tape\' to re-insert it if this is really desired and then delete it from the database (or do the export... asynchronously). The\n> > same could be said with VMs, although likely not all resources, aka networks/.../ make sense to do this.\n> > \n> > So instead of deleted = 1, wait for cleaner, just save the resource (if\n> > possible) + enough metadata on some other system (\'backup tape\', alternate storage location, hdfs, ceph...) and leave it there unless\n> > it\'s really needed. Making the database more complex (and all associated code) to achieve this same goal seems like a hack that just\n> > needs to be addressed with a better way to do archiving.\n> > \n> > In a cloudy world of course people would be able to recreate everything they need on-demand so who needs undelete anyway ;-)\n> > \n> \n> I have no problem if there was an existing process integrated into all of the OpenStack components which would produce me an archive trail with meta data and a command to recover the object from that data.\n> \n> Currently, my understanding is that there is no such function and thus the proposal to remove the deleted column is premature.\n> \n\nThat seems like an unreasonable request of low level tools like Nova. End\nuser applications and infrastructure management should be responsible\nfor these things and will do a much better job of it, as you can work\nyour own business needs for reliability and recovery speed into an\napplication aware solution. If Nova does it, your cloud just has to\nprovide everybody with the same un-delete, which is probably overkill\nfor _many_ applications.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9A7DE8D@CERNXCHG41.cern.ch>',NULL),('<1394742179.5931.31.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 16:22:59',-14400,'2014-03-13 20:22:59',NULL,'[openstack-dev] [Neutron][LBaaS] Mini-summit Interest?','On Thu, 2014-03-13 at 20:06 +0000, Jorge Miramontes wrote:\n> Now that the thread has had enough time for people to reply it appears\n> that the majority of people that vocalized their opinion are in favor\n> of a mini-summit, preferably to occur in Atlanta days before the\n> Openstack summit. There are concerns however, most notably the concern\n> that the mini-summit is not 100% inclusive (this seems to imply that\n> other mini-summits are not 100% inclusive). Furthermore, there seems\n> to be a concern about timing. I am relatively new to Openstack\n> processes so I want to make sure I am following them. In this case,\n> does majority vote win? If so, I\'d like to further this discussion\n> into actually planning a mini-summit. Thoughts?\n\n\n\nI personally would not be able to attend a mini-summit days before the\nregular summit. I would, however, support a mini-summit about a month\nafter the regular summit, where the focus would be on implementing the\ndesigns that are discussed at the regular summit.\n\nBest,\n-jay\n\n\n\n','<CF476DEA.E300%jorge.miramontes@rackspace.com>',NULL),('<1394745126.28601.8.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 16:12:06',-18000,'2014-03-13 21:12:06',NULL,'[openstack-dev] Duplicate code for processing REST APIs','On Thu, 2014-03-13 at 16:03 -0500, Steven Kaufer wrote:\n> While investigating some REST API updates I\'ve discovered that there\n> is a lot of duplicated code across the various OpenStack components.\n> \n> For example, the paginate_query function exists in all these locations\n> and there are a few slight differences between most of them:\n> \n> https://github.com/openstack/ceilometer/blob/master/ceilometer/openstack/common/db/sqlalchemy/utils.py#L61\n> https://github.com/openstack/cinder/blob/master/cinder/openstack/common/db/sqlalchemy/utils.py#L37\n> https://github.com/openstack/glance/blob/master/glance/openstack/common/db/sqlalchemy/utils.py#L64\n> https://github.com/openstack/heat/blob/master/heat/openstack/common/db/sqlalchemy/utils.py#L62\n> https://github.com/openstack/keystone/blob/master/keystone/openstack/common/db/sqlalchemy/utils.py#L64\n> https://github.com/openstack/neutron/blob/master/neutron/openstack/common/db/sqlalchemy/utils.py#L61\n> https://github.com/openstack/nova/blob/master/nova/openstack/common/db/sqlalchemy/utils.py#L64\n> \n> Does anyone know if there is any work going on to move stuff like this\n> into oslo and then deprecate these functions?  \n\nUm, all of the referenced files are already in oslo; that\'s what the\nopenstack/common subtree contains.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<OFB4CF43AE.E31FBA25-ON87257C9A.00719853-86257C9A.0073A68C@us.ibm.com>',NULL),('<1394747936.2850.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-13 21:58:56',0,'2014-03-13 21:58:56',NULL,'[openstack-tc] Draft bylaws changes from DefCore bylaws\n	subcommittee','On Thu, 2014-03-13 at 17:07 +0000, Mark McLoughlin wrote:\n> Hey\n> \n> I haven\'t been following this committee\'s progress and I can\'t speak to\n> the rationale here, but a draft set of bylaws changes are being\n> discussed by the committee:\n> \n>   http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html\n> \n> This part is obviously going to be something of interest to the TC:\n> \n>     (c) (i)  The Technical Committee shall have the authority to\n>              determine the scope of the OpenStack Project subject to the\n>              procedures described below. \n> \n>        (ii)  The Technical Committee shall propose a process or\n>              procedure to determine the scope of the OpenStack Project.\n>              The Board of Directors may propose modifications to such\n>              process or procedure but such modifications must be\n>              approved by the Technical Committee. After the Technical\n>              Committee has approved the final process or procedure for\n>              determining the scope of the OpenStack Project and the\n>              Board of Directors has approved such process or procedure,\n>              the Board of Directors shall set the date on which such\n>              process or procedure becomes effective and the first such\n>              date shall be defined as the OSP New Definition Date. \n>              After the OSP New Definition Date, the Technical Committee\n>              may propose modifications to such process and procedure.\n>              The Board of Directors shall consider such modifications\n>              and may approve or disapprove them. If the Board of\n>              Directors approves such modifications, the modified process\n>              and procedure shall become the method for determining the\n>              scope of the OpenStack Project on the effective date set by\n>              the Board of Directors.  The process or procedure shall be\n>              described in reasonable detail in the minutes of the Board\n>              of Directors which approved it. After such approval, the\n>              Secretary shall post such description to the Foundation?s\n>              website.\n> \n> Just on a call with the committee here and it seems the intent is to\n> change the process around OpenStack capabilities associated with the\n> trademark (i.e. what we now call \"Core\") as opposed to changing the\n> process around adding new projects to the integrated release.\n> \n> However, right now I think we equate \"the OpenStack Project\" to the\n> integrated release, so the actual wording does suggest a change to the\n> TC\'s authority.\n\nI had to drop from that call early to pick up my daughter from daycare,\nbut Mark Radcliffe followed up later with:\n\n  \"I appreciate your comments at the Bylaws committee meeting.  We don\'t\n  want to have the TC misunderstand the reasons for the bylaws change or\n  their consequences. These changes are focused solely on determining\n  how and when the trademark can be used.  We want to ensure that the TC\n  has an active role in the decisions.  Consequently, we will shift back\n  to the use of \"core\" for these procedures being set up.   However, as\n  I noted,  a number of members of DefCore Committee have expressed a\n  desire to use a word other than \"core\" for this concept so we may see\n  an additional change in the name.\"\n\nMark.\n\n\n\n','<1394730472.4781.63.camel@sorcha>',NULL),('<1394750856.2850.35.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-03-13 22:47:36',0,'2014-03-13 22:47:36',NULL,'[openstack-tc] Draft bylaws changes from DefCore bylaws\n	subcommittee','On Thu, 2014-03-13 at 21:58 +0000, Mark McLoughlin wrote:\n> On Thu, 2014-03-13 at 17:07 +0000, Mark McLoughlin wrote:\n> > Hey\n> > \n> > I haven\'t been following this committee\'s progress and I can\'t speak to\n> > the rationale here, but a draft set of bylaws changes are being\n> > discussed by the committee:\n> > \n> >   http://lists.openstack.org/pipermail/defcore-committee/2014-March/000040.html\n> > \n> > This part is obviously going to be something of interest to the TC:\n> > \n> >     (c) (i)  The Technical Committee shall have the authority to\n> >              determine the scope of the OpenStack Project subject to the\n> >              procedures described below. \n> > \n> >        (ii)  The Technical Committee shall propose a process or\n> >              procedure to determine the scope of the OpenStack Project.\n> >              The Board of Directors may propose modifications to such\n> >              process or procedure but such modifications must be\n> >              approved by the Technical Committee. After the Technical\n> >              Committee has approved the final process or procedure for\n> >              determining the scope of the OpenStack Project and the\n> >              Board of Directors has approved such process or procedure,\n> >              the Board of Directors shall set the date on which such\n> >              process or procedure becomes effective and the first such\n> >              date shall be defined as the OSP New Definition Date. \n> >              After the OSP New Definition Date, the Technical Committee\n> >              may propose modifications to such process and procedure.\n> >              The Board of Directors shall consider such modifications\n> >              and may approve or disapprove them. If the Board of\n> >              Directors approves such modifications, the modified process\n> >              and procedure shall become the method for determining the\n> >              scope of the OpenStack Project on the effective date set by\n> >              the Board of Directors.  The process or procedure shall be\n> >              described in reasonable detail in the minutes of the Board\n> >              of Directors which approved it. After such approval, the\n> >              Secretary shall post such description to the Foundation?s\n> >              website.\n> > \n> > Just on a call with the committee here and it seems the intent is to\n> > change the process around OpenStack capabilities associated with the\n> > trademark (i.e. what we now call \"Core\") as opposed to changing the\n> > process around adding new projects to the integrated release.\n> > \n> > However, right now I think we equate \"the OpenStack Project\" to the\n> > integrated release, so the actual wording does suggest a change to the\n> > TC\'s authority.\n> \n> I had to drop from that call early to pick up my daughter from daycare,\n> but Mark Radcliffe followed up later with:\n> \n>   \"I appreciate your comments at the Bylaws committee meeting.  We don\'t\n>   want to have the TC misunderstand the reasons for the bylaws change or\n>   their consequences. These changes are focused solely on determining\n>   how and when the trademark can be used.  We want to ensure that the TC\n>   has an active role in the decisions.  Consequently, we will shift back\n>   to the use of \"core\" for these procedures being set up.   However, as\n>   I noted,  a number of members of DefCore Committee have expressed a\n>   desire to use a word other than \"core\" for this concept so we may see\n>   an additional change in the name.\"\n\nJust surfacing other stuff as I find it ... I haven\'t listened to all of\nthis, but:\n\n  http://www.youtube.com/watch?v=eGiRrpDGzGU&t=72m30s\n\nBasically quite a bit of angst from DefCore members about our response.\n\nIt sounds like our response is being interpreted as an inability on our\npart to come to any consensus, which is not my read at all of our\nconversation on this. The \"we are unlikely to reach a consensus\"\nstatement IMHO is about the length of time it would take to do this\nacross all projects, rather than the difficulty in coming to agreement\non it.\n\nMy own intent on this was simply \"what you\'re asking of us is hugely\ncomplex and we\'d rather focus our time and effort on helping solidifying\nthe API interop requirements rather than complex definitions of what\ncode is required to be run\".\n\nAnyone see this differently?\n\nHere\'s something else interesting:\n\n  https://etherpad.openstack.org/p/openstack-designated-sections\n\nIgnoring the snark in there, you can see the intent of designated\nsections here are that e.g. Nova is API, Conductor, Scheduler, Virt\nDriver and API extensions, and that only API and Conductor should be\nclassified as designated/required. The \"you must run API and Conductor\"\nrequirement would be a very high level, honor-based requirement rather\nthan the detailed line-of-code by line-of-code type requirement we\ninterpreted the request as.\n\nOk, I\'m done listening to Josh rant about the TC.\n\nMark.\n\n\n\n','<1394747936.2850.7.camel@sorcha>',NULL),('<1394807517.9447.9.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 14:31:59',0,'2014-03-14 14:31:59',NULL,'[openstack-dev] [neutron][Designate] A question about DNSaaS?','On Fri, 2014-03-14 at 08:44 +0000, Yuzhou (C) wrote:\n> Hi stackers,\n> \n>         Are there any plans about DNSaaS on the neutron roadmap?\n> \n>         As far as I known, Designate provides DNSaaS services for\n> OpenStack.\n> \n> Why DNSaaS is Independent service , not a network service like LBaas\n> or VPNaaS?\n> \n> Thanks,\n> \n> Zhou Yu\n\nI personally see DNSaaS as being outside the scope of Neutron. VPNaaS\nand LBaaS are, at their core, about moving bits from A -> B. DNSaaS is\ndifferent, as it plays no part in how bits are moved from A -> B.\n\nNeutron\'s 1 line intro is:\n\n\"Neutron is an OpenStack project to provide \"networking as a service\"\nbetween interface devices (e.g., vNICs) managed by other Openstack\nservices (e.g., nova).\"\n\nI\'m not sure I could squeeze authoritative DNS into that scope without\nchanging it :)\n\nThanks,\nKiall\n\n\n\n','<47498F109986134D9A5B42B82F405EBB7E2F0877@SZXEMA502-MBX.china.huawei.com>',NULL),('<1394811679.151414478@f254.i.mail.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-14 19:41:19',14400,'2014-03-14 15:41:19',NULL,'[Openstack] instance doesn\'t boot',' Hello,\nDoes nova console-log show anything?\n\nnova console-log command\n\nusage: nova console-log [--length <length>] <server>\n?????? ?\nGet console log output of a server. \n\n\nLooking for openstack and python developers. Please check: http://www.nsbeta.info/jobs\n\nFriday, March 14, 2014 3:45 PM +01:00 from cheniour ghassen <ghacheniour at gmail.com>:\n>Hi everyone,\n>I have been bloqued for hours now. I want to launch for the first time an instance in openstack havana? that i have configured. the instance is launched but when i connect to the vnc console. I see this error:\n>\n>booting from hard disk..\n>boot failed: not a bootable disk\n>booting from floppy..\n>boot failed: could not read the boot disk\n>\n>the log files show nothing. I really don\'t whre the problem is?\n>any help would be apperciated.\n>thanks.\n>sincerely,\n>Ghassen Cheniour.\n>_______________________________________________\n>Mailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to     :  openstack at lists.openstack.org\n>Unsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140314/97064ffd/attachment.html>\n\n','<CAE4v-KEtcdxgkWmxkXhnhCJN2X5PaERPSJdftjr3RSF9+6L7og@mail.gmail.com>',NULL),('<1394812511.5931.75.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 11:55:11',-14400,'2014-03-14 15:55:11',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n soft deletion (step by step)','On Fri, 2014-03-14 at 08:37 +0100, Radomir Dopieralski wrote:\n> Hello,\n> \n> I also think that this thread is going in the wrong direction, but I\n> don\'t think the direction Boris wants is the correct one either. Frankly\n> I\'m a little surprised that nobody mentioned another advantage that soft\n> delete gives us, the one that I think it was actually used for originally.\n> \n> You see, soft delete is an optimization. It\'s there to make the system\n> work faster as a whole, have less code and be simpler to maintain and debug.\n> \n> How does it do it, when, as clearly shown in the first post in this\n> thread, it makes the queries slower, requires additional indices in the\n> database and more logic in the queries?\n\nI feel it isn\'t an optimization if:\n\n* It slows down the code base\n* Makes the code harder to read and understand\n* Deliberately obscures the actions of removing and restoring resources\n* Encourages the idea that everything in the system is \"undoable\", like\nthe cloud is a Word doc.\n\n>  The answer is, by doing more\n> with those queries, by making you write less code, execute fewer queries\n> to the databases and avoid duplicating the same data in multiple places.\n\nFewer queries does not aklways make faster code, nor does it lead to\ninherently race-free code.\n\n> OpenStack is a big, distributed system of multiple databases that\n> sometimes rely on each other and cross-reference their records. It\'s not\n> uncommon to have some long-running operation started, that uses some\n> data, and then, in the middle of its execution, have that data deleted.\n> With soft delete, that\'s not a problem -- the operation can continue\n> safely and proceed as scheduled, with the data it was started with in\n> the first place -- it still has access to the deleted records as if\n> nothing happened.\n\nI believe a better solution would be to use Boris\' solution and\nimplement safeguards around the delete operation. For instance, not\nbeing able to delete an instance that has tasks still running against\nit. Either that, or implement true task abortion logic that can notify\ndistributed components about the need to stop a running task because\neither the user wants to delete a resource or simply cancel the\noperation they began.\n\n>  You simply won\'t be able to schedule another operation\n> like that with the same data, because it has been soft-deleted and won\'t\n> pass the validation at the beginning (or even won\'t appear in the UI or\n> CLI). This solves a lot of race conditions, error handling, additional\n> checks to make sure the record still exists, etc.\n\nSorry, I disagree here. Components that rely on the soft-delete behavior\nto get the resource data from the database should instead respond to a\nNotFound that gets raised by aborting their running task.\n\n> Without soft delete, you need to write custom code every time to handle\n> the case of a record being deleted mid-operation, including all the\n> possible combinations of which record and when.\n\nNot custom code. Explicit code paths for explicit actions.\n\n>  Or you need to copy all\n> the relevant data in advance over to whatever is executing that\n> operation. \n\nThis is already happening.\n\n> This cannot be abstracted away entirely (although tools like\n> TaskFlow help), as this is specific to the case you are handling. And\n> it\'s not easy to find all the places where you can have a race condition\n> like that -- especially when you are modifying existing code that has\n> been relying on soft delete before. You can have bugs undetected for\n> years, that only appear in production, on very large deployments, and\n> are impossible to reproduce reliably.\n> \n> There are more similar cases like that, including cascading deletes and\n> more advanced stuff, but I think this single case already shows that\n> the advantages of soft delete out-weight its disadvantages.\n\nI respectfully disagree :) I think the benefits of explicit code paths\nand increased performance of the database outweigh the costs of changing\nexisting code.\n\nBest,\n-jay\n\n> On 13/03/14 19:52, Boris Pavlovic wrote:\n> > Hi all, \n> > \n> > \n> > I would like to fix direction of this thread. Cause it is going in wrong\n> > direction. \n> > \n> > To assume:\n> > 1) Yes restoring already deleted recourses could be useful. \n> > 2) Current approach with soft deletion is broken by design and we should\n> > get rid of them. \n> > \n> > More about why I think that it is broken: \n> > 1) When you are restoring some resource you should restore N records\n> > from N tables (e.g. VM)\n> > 2) Restoring sometimes means not only restoring DB records. \n> > 3) Not all resources should be restorable (e.g. why I need to restore\n> > fixed_ip? or key-pairs?)\n> > \n> > \n> > So what we should think about is:\n> > 1) How to implement restoring functionally in common way (e.g. framework\n> > that will be in oslo) \n> > 2) Split of work of getting rid of soft deletion in steps (that I\n> > already mention):\n> > a) remove soft deletion from places where we are not using it\n> > b) replace internal code where we are using soft deletion to that framework \n> > c) replace API stuff using ceilometer (for logs) or this framework (for\n> > restorable stuff)\n> > \n> > \n> > To put in a nutshell: Restoring Delete resources / Delayed Deletion !=\n> > Soft deletion. \n> > \n> > \n> > Best regards,\n> > Boris Pavlovic \n> > \n> > \n> > \n> > On Thu, Mar 13, 2014 at 9:21 PM, Mike Wilson <geekinutah at gmail.com\n> > <mailto:geekinutah at gmail.com>> wrote:\n> > \n> >     For some guests we use the LVM imagebackend and there are times when\n> >     the guest is deleted on accident. Humans, being what they are, don\'t\n> >     back up their files and don\'t take care of important data, so it is\n> >     not uncommon to use lvrestore and \"undelete\" an instance so that\n> >     people can get their data. Of course, this is not always possible if\n> >     the data has been subsequently overwritten. But it is common enough\n> >     that I imagine most of our operators are familiar with how to do it.\n> >     So I guess my saying that we do it on a regular basis is not quite\n> >     accurate. Probably would be better to say that it is not uncommon to\n> >     do this, but definitely not a daily task or something of that ilk.\n> > \n> >     I have personally \"undeleted\" an instance a few times after\n> >     accidental deletion also. I can\'t remember the specifics, but I do\n> >     remember doing it :-).\n> > \n> >     -Mike\n> > \n> > \n> >     On Tue, Mar 11, 2014 at 12:46 PM, Johannes Erdfelt\n> >     <johannes at erdfelt.com <mailto:johannes at erdfelt.com>> wrote:\n> > \n> >         On Tue, Mar 11, 2014, Mike Wilson <geekinutah at gmail.com\n> >         <mailto:geekinutah at gmail.com>> wrote:\n> >         > Undeleting things is an important use case in my opinion. We\n> >         do this in our\n> >         > environment on a regular basis. In that light I\'m not sure\n> >         that it would be\n> >         > appropriate just to log the deletion and git rid of the row. I\n> >         would like\n> >         > to see it go to an archival table where it is easily restored.\n> > \n> >         I\'m curious, what are you undeleting and why?\n> > \n> >         JE\n> > \n> > \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         <mailto:OpenStack-dev at lists.openstack.org>\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> >     _______________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5322B1CA.7050602@sheep.art.pl>',NULL),('<1394828961.52982.YahooMailNeo@web172405.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 20:29:21',0,'2014-03-14 20:29:21',NULL,'[openstack-dev] [qa][neutron] neutron version in openstack/nova\n	neutron tests','I\'m looking at errors in the dhcp-agent using logstash and I see openstack/nova Jenkins jobs running today [1] that have an outdated neutron/openstack/common/lockutils.py. The message format used to be 1 line per lock/unlock eg:\n\nGot semaphore \"dhcp-agent\" for method \"subnet_delete_end\"... \n\nBut since review 47557 merged on 2014-01-13 [2] it should 3 lines per lock/unlock? like:\n\nGot semaphore \"dhcp-agent\" lock \nGot semaphore / lock \"sync_state\"\nSemaphore / lock released \"sync_state\"\n\nAnd these show in openstack/neutron jobs. I would have thought openstack/nova jobs would be using the latest or very recent neutron?\n\n[1] http://logs.openstack.org/25/75825/1/gate/gate-tempest-dsvm-neutron/71b9183/logs/screen-q-dhcp.txt.gz#_2014-03-14_00_23_35_716\n[2] https://review.openstack.org/#/c/47557/20/neutron/openstack/common/lockutils.py\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140314/5f2f57f2/attachment.html>\n\n',NULL,NULL),('<1394833589.27374.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 21:46:29',0,'2014-03-14 21:46:29',NULL,'[openstack-dev] [qa][neutron] neutron version in openstack/nova\n	neutron tests','\n\nah - forget it - it was stable/havana of course\n\n\nhttps://review.openstack.org/#/c/75825/\n\n\nOn Friday, 14 March 2014, 20:29, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n \nI\'m looking at errors in the dhcp-agent using logstash and I see openstack/nova Jenkins jobs running today [1] that have an outdated neutron/openstack/common/lockutils.py. The message format used to be 1 line per lock/unlock eg:\n>\n>Got semaphore \"dhcp-agent\" for method \"subnet_delete_end\"... \n>\n>But since review 47557 merged on 2014-01-13 [2] it should 3 lines per lock/unlock? like:\n>\n>Got semaphore \"dhcp-agent\" lock \n>Got semaphore / lock \"sync_state\"\n>Semaphore / lock released \"sync_state\"\n>\n>And these show in openstack/neutron jobs. I would have thought openstack/nova jobs would be using the latest or very recent neutron?\n>\n>[1]\n http://logs.openstack.org/25/75825/1/gate/gate-tempest-dsvm-neutron/71b9183/logs/screen-q-dhcp.txt.gz#_2014-03-14_00_23_35_716\n>[2] https://review.openstack.org/#/c/47557/20/neutron/openstack/common/lockutils.py\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140314/50e4a80b/attachment.html>\n\n','<1394828961.52982.YahooMailNeo@web172405.mail.ir2.yahoo.com>',NULL),('<1394895364-sup-3136@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-15 08:32:53',-25200,'2014-03-15 15:32:53',NULL,'[openstack-dev] [db][all] (Proposal) Restorable & Delayed\n	deletion of OS Resources','Excerpts from Joshua Harlow\'s message of 2014-03-13 16:16:50 -0700:\n> Seems ok to me, and likely a good start, although I\'m still not very comfortable with the effects of soft_deletion (unless its done by admins only), to me it complicates scheduling (can u schedule to something that has been soft_deleted, likely not). It also creates a  pool of resources that can\'t be used but can\'t be deleted either, that sounds a little bad and wastes companies $$ and it reinforces non-cloudly concepts. It also seems very complex, especially when your start connecting more and more resources together via heat or other system (the whole graph of resources now must be soft_deleted, wasting more $$, and how does one restore the graph of resources if some of them were also hard_deleted).\n> \n\nI think you stay clear of scheduling if you treat it as a stopped\nresource. It is costing you to be there, even if it isn\'t using the CPU\nand RAM, it is a form of reservation.\n\nThe pool of unusable resources must be built into the price for\nundeletable resources. How long to keep things around is a business\ndecision. I could see an evolution of the feature that includes undelete\nperiod in the flavor definition.\n\nThe fact that one would need to be able to undelete whole applications\nis just a missing feature. In the case of Heat, it would definitely get\ncomplicated if you went out of band and accidentally deleted things but\nit would be uncomplicated as long as you undeleted it before Heat tried\nto do an in-place operation like a Metadata change + waitcondition or a\nrebuild/resize.\n\nI think though, that we already have this feature for most things in the\nform of \"stop\" versus \"delete\". The way I would implement undelete is at\nthe policy level.\n\nDeny delete to users, and provide a cron-like functionality for\ndeleting. Let them decide how long they\'d like to keep things around for,\nand then let the cron-like thing do the actual deleting. I believe a few\nof these cron-as-a-service things already exist.\n\n\n','<CF478A4B.59709%harlowja@yahoo-inc.com>',NULL),('<1394945818-sup-5108@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-15 22:04:44',-25200,'2014-03-16 05:04:44',NULL,'[openstack-dev] [all][db][performance] Proposal: Get rid of\n	soft deletion (step by step)','Excerpts from Tim Bell\'s message of 2014-03-14 13:54:32 -0700:\n> \n> I think we need to split the scenarios and focus on the end user experience with the cloud \n> \n> .... a few come to my mind from the CERN experience (but this may not be all):\n> \n> 1. Accidental deletion of an object (including meta data)\n> 2. Multi-level consistency (such as between Cell API and child instances)\n> 3. Auditing\n> \n> CERN has the scenario 1 at a reasonable frequency. Ultimately, it is due to error by\n> --\n> A - the openstack administrators themselves\n> B - the delegated project administrators\n> C - users with a non-optimised scope for administrative action\n> D - users who make mistakes\n> \n> It seems that we should handle these as different cases\n> \n> 3 - make sure there is a log entry (ideally off the box) for all operations\n> 2 - up to the component implementers but with the aim to expire deleted entries as soon as reasonable consistency is achieved\n> 1[A-D] - how can we recover from operator/project admin/user error ?\n> \n> I understand that there are differing perspectives from cloud to server consolidation but my cloud users expect that if they create a one-off virtual desktop running Windows for software testing and install a set of software, I don\'t tell them it was accidentally deleted due to operator error (1A or 1B), you need to re-create it.\n> \n\n\nTotally agree with all of your points.\n\nI think you can achieve this level of protection simply by denying\ninteractive users the rights to delete individual things directly, and\nusing stop instead of delete. Then have something else (cron?) clean up\nstopped instances after a safety period has been reached.\n\nThis is an interesting counter to the opposite more fluid tactic which\nis to delete instances that have been up for too long, assuming that\nlong lived == wrong and costly.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9A84748@CERNXCHG41.cern.ch>',NULL),('<1394953540-sup-2384@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-16 00:06:58',-25200,'2014-03-16 07:06:58',NULL,'[openstack-dev] [TripleO] os-cloud-config ssh access to cloud','Excerpts from Adam Young\'s message of 2014-03-12 06:19:47 -0700:\n> On 03/11/2014 01:20 PM, Clint Byrum wrote:\n> > Excerpts from Adam Young\'s message of 2014-03-11 07:50:58 -0700:\n> >> On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:\n> >>> For what it\'s worth in Sahara (former Savanna) we inject the second\n> >>> key by userdata. I.e. we add\n> >>> echo \"${public_key}\" >> ${user_home}/.ssh/authorized_keys\n> >>>\n> >>> to the other stuff we do in userdata.\n> >>>\n> >>> Dmitry\n> >>>\n> >>> 2014-03-10 17:10 GMT+04:00 Ji?? Str?nsk? <jistr at redhat.com>:\n> >>>> On 7.3.2014 14:50, Imre Farkas wrote:\n> >>>>> On 03/07/2014 10:30 AM, Ji?? Str?nsk? wrote:\n> >>>>>> Hi,\n> >>>>>>\n> >>>>>> there\'s one step in cloud initialization that is performed over SSH --\n> >>>>>> calling \"keystone-manage pki_setup\". Here\'s the relevant code in\n> >>>>>> keystone-init [1], here\'s a review for moving the functionality to\n> >>>>>> os-cloud-config [2].\n> >> You really should not be doing this.  I should never have written\n> >> pki_setup:  it is a developers tool:  user a real CA and a real certificate.\n> >>\n> > This alludes to your point, but also says that keystone-manage can be used:\n> >\n> > http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki\n> Yep.  And we need to get a better story for certificate management.\n> >\n> > Seems that some time should be spent making this more clear if for some\n> > reason pki_setup is weak for production use cases. My brief analysis\n> > of the code says that the weakness is that the CA should generally be\n> > kept apart from the CSR\'s so that a compromise of a node does not lead\n> > to an attacker being able to generate their own keystone service. This\n> > seems like a low probability attack vector, as compromise of the keystone\n> > machines also means write access to the token backend, and thus no need\n> > to generate ones\' own tokens (you can just steal all the existing tokens).\n> \n> This is a pretty good explanation.  I would love to see it submitted as \n> part of the keystone configuration document above.\n> \n\nThanks!\n\nhttps://review.openstack.org/80819\n\n> >\n> > I\'d like to see it called out in the section above though, so that\n> > users can know what risk their accepting when they use what looks like a\n> > recommended tool. Another thing would be to log copious warnings when\n> > pki_setup is run that it is not for production usage. That should be\n> > sufficient to scare some diligent deployers into reading the docs closely\n> > and mitigating the risk.\n> Very good idea.\n> \n> >\n> > Anyway, shaking fist at users and devs in -dev for using tools in the\n> > documentation probably _isn\'t_ going to convince anyone to spend more\n> > time setting up PKI tokens.\n> \n> The only one I am shaking my fist at is myself...and maybe those that \n> browbeat me into writing the utility.\n> \n\nI recommend we aim for less fist shaking and beating of all kinds in\nOpenStack.\n\n\n','<53205EF3.9030003@redhat.com>',NULL),('<1394970654-sup-5713@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-16 05:05:19',-25200,'2014-03-16 12:05:19',NULL,'[openstack-dev] [Mistral] Actions design BP','Excerpts from Renat Akhmerov\'s message of 2014-03-13 01:55:46 -0700:\n> Joshua,\n> \n> Thanks for your interest and feedback.\n> \n> I believe you were able to deliver your message already, we definitely hear you. So no need to the same stuff again and again ;) As I promised before, we are now evaluating what?s been going on with TaskFlow for the last couple of months and preparing our questions/concerns/suggestions on using it within Mistral. But that?s not very easy and quick thing to do since there?s a bunch of details to take into account, especially given the fact that Mistral codebase has become much more solid and Mistral itself now has lots of requirements dictated by its use cases and roadmap vision. So patience would be really appreciated here.\n> \n> If you don?t mind I would prefer to discuss things like that in separate threads, not in threads devoted to daily project activities. So that we can split our conceptual discussions and current work that?s going on according to our plans. Otherwise we have a risk to make spaghetti out of our ML threads.\n> \n\n>From my perspective, as somebody who is considering Mistral for some\nimportant things, the fact that the taskflow people are not aligned with\nthe Mistral people tells me that Mistral is not what I thought it was:\ntaskflow for direct user consumption.\n\nSo, while it may be annoying to have your \"day to day project\nactivities\" questioned, it is pretty core to the discussion considering\nthat this suggests several things that diverge from taskflow\'s core\nmodel.\n\n\n','<5D3071E9-045B-4DE4-8212-3727EADA1819@mirantis.com>',NULL),('<1394972289.1001.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-16 08:18:09',-14400,'2014-03-16 12:18:09',NULL,'[openstack-dev] Hierarchicical Multitenancy Discussion','On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote:\n> Awesome, this is exactly what I was thinking. I think this is really\n> close to being usable on the nova side. First of all the\n> dot.sperated.form looks better imo, and I think my code should still\n> work that way as well. The other piece that is needed is mapping ids\n> to names for display purposes. I did something like this for a\n> prototype of names in dns caching that should work nicely. The\n> question simply becomes how do we expose those names. I?m thinking we\n> have to add an output field to the display of objects in the system\n> showing the fully qualified name.  We can then switch the display in\n> novaclient to show names instead of ids.  That way an admin listing\n> all the projects in orga would see the owner as orga.projb instead of\n> the id string.\n> \n> The other option would be to pass names instead of ids from keystone\n> and store those instead. That seems simpler at first glance, it is not\n> backwards compatible with the current model so it will be painful for\n> providers to switch.\n\n-1 for \"instead of\". \"in addition to\" would have been fine, IMO.\n\nBest,\n-jay\n\n\n\n\n','<13BE8AB6-176A-494A-BD5C-69C29FF482A9@gmail.com>',NULL),('<1395049041152-35366.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 02:37:21',-25200,'2014-03-17 09:37:21',NULL,'[openstack-dev] [Openstack] [TROVE] Manual Installation Again','Hi Mark,\nhave you some news about the right steps (Prepare Image) that are needed\nperform in order to launch a trove instance with a correctly configured\ntrove-guest agent?\n\nAs you, I have read all the trove-integration/script/redstack script to find\nthe right commands to perform a manual trove installatio, and I have\nrealized the gerrit review https://review.openstack.org/#/c/78608/.\nI would be happy if you could contribute to the review, particularly for the\n\"Prepare Image\" steps.\n\nThank you,\nGiuseppe\n\n\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/Openstack-TROVE-Manual-Installation-Again-tp34470p35366.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<53195330.80301@catalyst.net.nz>',NULL),('<1395077199-sup-9475@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 10:41:27',-25200,'2014-03-17 17:41:27',NULL,'[openstack-dev] [Mistral] Actions design BP','Excerpts from Renat Akhmerov\'s message of 2014-03-17 07:35:02 -0700:\n> \n> On 16 Mar 2014, at 19:05, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > From my perspective, as somebody who is considering Mistral for some\n> > important things, the fact that the taskflow people are not aligned with\n> > the Mistral people tells me that Mistral is not what I thought it was:\n> > taskflow for direct user consumption.\n> \n> Yes, it was just an initial idea we were trying to pursue. As we moved forward we understood it was too limited and had a lot of pitfalls. The reason is the key difference between library and service. Making something a service flips everything upside down in terms of requirements to this new system. The logical questions/implications are:\n> If that?s a service why should its REST API be Python oriented? Bindings - yes (it gives a certain convenience) but that?s a different story..\n> A whole set of questions related to how we distribute Python-written tasks (especially in multi tenant environment, e.g. as a cloud hosted service):\n> Dependencies\n> Sandboxing\n> Result serialisation\n> etc.\n> It becomes logical to be able to use it with non-python clients and external systems.\n> Orientation to long-lived processes(workflows). Synchronous execution model no longer works well, instead de facto asynchronous event-based architecture fits better. I know it may sound too generic, it?s a whole different topic..\n> It becomes logical to provide more high-level capabilities rather than a library does (e.g. Horizon Dashboard. It would not be much of use if the service was based on Python).\n> \n\nI assume Mistral is written in Python though, and so it should be using\nTaskflow for its own workflow. I understand though, that to run _user_\nworkflows you can\'t just expect them to upload python or always run\npython as Mistral wouldn\'t do much for them at that point.\n\nHowever, for the User<->Taskflow integration, I think Josh Harlow offered\na really reasonable suggestion to that, which is instead of inventing\na DSL (frankly, I\'m pretty frustrated with the Heat DSL\'s we have, so I\nmay be biased here), just embrace javascript or lua, which are designed\nto be embedded and executed in a less-than-trusted context.\n\nI think it would be a great story for users if Mistral worked like this:\n\n- Upload javascript expression of workflow, with external callouts for\n  complicated things.\n- Run code that uses Mistral API to poll-for or subscribe-to\n  notifications waiting for instructions from Mistral when it is\n  supposed to run said external callouts, and feeds back data.\n\n> I believe it?s not the full list.\n> \n> Despite of all this I?m not against of using TaskFlow in implementation, at least some pieces of it. My only call is: it should be really beneficial rather than bringing pain. So I?m ok if we keep aligning our capabilities, roadmaps, terminology and whatever else is needed. \n> \n> Btw, it would be really helpful if you could clarify what you meant ?some important things?. Asking because I still feel like we could have much more input from potential users. Any information is appreciated.\n> \n\n- Heat needs to move from being a single state machine (heat-engine owns\n  all of the running tasks for a stack in one engine at a time) to a\n  distributed state machine. Before we do that, we need to consider how\n  Heat expresses workflow. If Mistral were a distributed workflow\n  engine, it would make a lot of sense for Heat to make use of it for\n  this purpose.\n\n- TripleO deploys a number of things that need distributed workflow.\n  I think at this point the people involved with that are looking more\n  at lower level tools like RAFT and Concoord. But once the distributed\n  state machine is settled, there will be a need to express the\n  distributed workflow. I\'m disinclined to diverge from Taskflow, even\n  though I am quite inclined to embrace API\'s.\n\n> > So, while it may be annoying to have your \"day to day project\n> > activities\" questioned, it is pretty core to the discussion considering\n> > that this suggests several things that diverge from taskflow\'s core\n> > model.\n> \n> Np. I still keep finding things/rules in OpenStack that I?m not really aware of or didn?t get used to yet. If that?s not how it should be done in OS then it?s fine.\n\nI\'m sorry if the message was harsh, but I see this happening a lot.\n\nI don\'t think it is a rule. I think the principle here is to collaborate\non things that should be aligned. If Taskflow doesn\'t do what you need\nit to do, then I suggest _fixing that_ rather than writing a private\nimplementation. It will make life better for all users of taskflow and\nit will keep Mistral extremely simple, which will help with adoption by\noperators _and_ users.\n\n\n','<D70F808E-E677-49A3-A4DE-839E6A092C24@mirantis.com>',NULL),('<1395080894.1001.13.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 14:28:14',-14400,'2014-03-17 18:28:14',NULL,'[openstack-dev] Automatic version creation in PBR','On Mon, 2014-03-17 at 16:10 +1300, Robert Collins wrote:\n> Right now PBR\'s creation of versions for postversioning is problematic\n> - it generates versions that (if recognized by pip) would be treated\n> as releases, even when its a non-tagged commit.\n> \n> https://etherpad.openstack.org/p/pbr-postversion-semver\n> \n> The tl;dr is a proposal to generate dev marked versions of the lowest\n> possible higher tag that we would accept - which would be any of full\n> release or alpha/beta/rc\n> \n> A related but can be done separately change is to pick version strings\n> for alpha releases that are compatible with both PEP 440 and semver.\n> \n> Feedback solicited - if this is something contentious, we can make it\n> an opt-in feature, but it seems unambiguously better to the folk that\n> chatted through it on #openstack-infra, so ideally I\'d like to\n> transition any existing incompatible tags we have, and then land code\n> to make this the behaviour for post-versioned (the default - no\n> \'version\' key in setup.cfg) untagged commits.\n\nHi Rob, thanks for the heads up.\n\nA number of us use pbr for outside-of-OpenStack projects, and have\nrelied on it for things like proper package versioning using git tags.\n\nI\'m a little unclear what, if any, changes to my standard python sdist\nand upload actions I will need to take to publish releases of my\nprojects that use pbr.\n\nWould you mind easing my mind and letting me know if this is something\nthat is going to break things for me? I\'m no packaging expert, and rely\non things like pbr to do a lot of this magic for me :)\n\nAll the best,\n-jay\n\n\n\n','<CAJ3HoZ23oHLy-PG_dB7cxisRdTcEbofwCjTLDXS4s7YRKSU_+w@mail.gmail.com>',NULL),('<1395082456.1001.15.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 14:54:16',-14400,'2014-03-17 18:54:16',NULL,'[openstack-dev] [db][all] (Proposal) Restorable & Delayed\n deletion of OS Resources','On Sun, 2014-03-16 at 23:02 -0700, Allamaraju, Subbu wrote:\n> Hi Boris,\n> \n> I just read the other thread. As Jay asked in [1], have you considered precautions in the UI in stead? That should take care of mistakes with manual deletes.\n> \n> Thx\n> Subbu\n> \n> [1] http://lists.openstack.org/pipermail/openstack-dev/2014-March/029784.html\n\nAfter hearing from Tim Bell and others, I think that a two-pronged\napproach is most useful. First, the above-mentioned UI changes to\nprevent common mistakes, and second, using a consistent, standardized\nway of undoing certain operations (Boris\' proposal).\n\nBest,\n-jay\n\n\n\n','<3FE20463-B2E8-48FE-BAD0-56E2B80A8969@subbu.org>',NULL),('<1395084270.1001.22.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 15:24:30',-14400,'2014-03-17 19:24:30',NULL,'[openstack-dev] [Ceilometer] [QA] Slow Ceilometer resource_list\n CLI command','On Mon, 2014-03-17 at 14:55 -0400, Matthew Treinish wrote:\n> Hi everyone,\n> \n> So a little while ago we noticed that in all the gate runs one of the ceilometer\n> cli tests is consistently in the list of slowest tests. (and often the slowest)\n> This was a bit surprising given the nature of the cli tests we expect them to\n> execute very quickly.\n> \n> test_ceilometer_resource_list which just calls ceilometer resource_list from the\n> CLI once is taking >=2 min to respond. For example:\n> http://logs.openstack.org/68/80168/3/gate/gate-tempest-dsvm-postgres-full/07ab7f5/logs/tempest.txt.gz#_2014-03-17_17_08_25_003\n> (where it takes > 3min)\n\nYep. At AT&T, we had to disable calls to GET /resources without any\nfilters on it. The call would return hundreds of thousands of records,\nall being JSON-ified at the Ceilometer API endpoint, and the result\nwould take minutes to return. There was no default limit on the query,\nwhich meant every single records in the database was returned, and on\neven a semi-busy system, that meant horrendous performance.\n\nBesides the problem that the SQLAlchemy driver doesn\'t yet support\npagination [1], the main problem with the get_resources() call is the\nunderlying databases schema for the Sample model is wacky, and forces\nthe use of a dependent subquery in the WHERE clause [2] which completely\nkills performance of the query to get resources.\n\n[1]\nhttps://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L436\n[2]\nhttps://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L503\n\n> The cli tests are supposed to be quick read-only sanity checks of the cli\n> functionality and really shouldn\'t ever be on the list of slowest tests for a\n> gate run.\n\nOh, the test is readonly all-right. ;) It\'s just that it\'s reading\nhundreds of thousands of records.\n\n>  I think there was possibly a performance regression recently in\n> ceilometer because from I can tell this test used to normally take ~60 sec.\n> (which honestly is probably too slow for a cli test too) but it is currently\n> much slower than that.\n> \n> From logstash it seems there are still some cases when the resource list takes\n> as long to execute as it used to, but the majority of runs take a long time:\n> http://goo.gl/smJPB9\n> \n> In the short term I\'ve pushed out a patch that will remove this test from gate\n> runs: https://review.openstack.org/#/c/81036 But, I thought it would be good to\n> bring this up on the ML to try and figure out what changed or why this is so\n> slow.\n\nI agree with removing the test from the gate in the short term. Medium\nto long term, the root causes of the problem (that GET /resources has no\nsupport for pagination on the query, there is no default for limiting\nresults based on a since timestamp, and that the underlying database\nschema is non-optimal) should be addressed.\n\nBest,\n-jay\n\n\n\n','<20140317185540.GA30706@kortar.treinish>',NULL),('<1395084648-sup-992@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 12:31:17',-25200,'2014-03-17 19:31:17',NULL,'[openstack-dev] [Heat] Stack breakpoint','Ton, could you repost this as a new thread? It has very little to do\nwith the referenced thread.\n\nExcerpts from Ton Ngo\'s message of 2014-03-17 12:10:33 -0700:\n> I would like to revisit with more details an idea that was mentioned in the\n> last design summit and hopefully get some feedback.\n> \n> The scenario is troubleshooting a failed template.\n> Currently we can stop on the point of failure by disabling rollback:  this\n> works well for stack-create; stack-update requires some more work but\n> that\'s different thread.  In many cases however, the point of failure may\n> be too late or too hard to debug because the condition causing the failure\n> may not be obvious or may have been changed.  If we can pause the stack at\n> a point before the failure, then we can check whether the state of the\n> environment and the stack is what we expect.\n> The analogy with program debugging is breakpoint/step, so it may be useful\n> to introduce this same concept in a stack.\n> \n> The usage would be something like:\n> -Run stack-create (or stack-update once it can handle failure) with one or\n> more resource name specified as breakpoint\n> -As the engine traverses down the dependency graph, it would stop at the\n> breakpoint resource and all dependent resources.  Other resources with no\n> dependency will proceed to completion.\n> -After debugging, continue the stack by:\n>     -Stepping: remove current breakpoint, set breakpoint for next resource\n> (s) in dependency graph, resume stack-create (or stack-update)\n>     -Running to completion: remove current breakpoint, resume stack-create\n> (or stack-update)\n> \n> Some other possible uses for this breakpoint:\n> - While developing new template or resource type, bring up a stack to a\n> point before the new code is to be executed\n> - Introduce human process: pause the partial stack so the user can get the\n> stack info and perform some tasks before continuing\n> \n> Some issues to consider (with initial feedback from shardy):\n> - Granularity of stepping:  resource level or internal steps within a\n> resource\n> - How to specify breakpoints:  CLI argument or coded in template or both\n> - How to handle resources with timer, e.g. wait condition:  pause/resume\n> timer value\n> - New state for a resource:  PAUSED\n> \n> Thanks.\n> \n> Ton Ngo,\n> \n\n\n','<OF48DE272C.F7237C1C-ON88257C9E.00657003-88257C9E.006955A8@us.ibm.com>',NULL),('<1395084914-sup-3344@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-17 12:43:37',-25200,'2014-03-17 19:43:37',NULL,'[OpenStack-Infra] Announcing a new infrastructure project,\n	Vinz code review system.','Excerpts from Philip Schwartz\'s message of 2014-03-17 12:01:29 -0700:\n> \n> On 3/17/14, 12:59 PM, \"Thierry Carrez\" <thierry at openstack.org> wrote:\n> >Being fully aware of the irony, I\'ll play the devil\'s advocate:\n> >\n> >Could you detail why improving Gerrit is not an option ? At first glance\n> >its development seemed to be open enough, and it didn\'t appear\n> >fundamentally wrong (just needing a few incremental changes).\n> \n> Thierry,\n> \n> I am glad that you asked this question as it was the first thing that I\n> looked at. As most know, Gerrit is a monolithic Java application. For a\n> community of python developers (many of which know Java), it is not the\n> best code base to work with. It has a steep learning curve for new\n> developers to make changes to the software as a whole. This is the first\n> issue I see with modifying Gerrit directly.\n> \n\nI would have a hard time getting used to a brand new code base, even\nthough I do know python a while. I think this is a very small issue.\nJava is well known and there are likely many Java developers out there\ninvolved with OpenStack who are learning python for the first time too.\nThe point of Python in OpenStack is that we want to make sure operators\ncan approach the code of the bits they\'ll be operating. The pieces of\nour development infrastucture are quite a bit different.\n\n> The second is the project itself. Yes, it moves forward at a good pace,\n> but they take a majority of guidance from 2 open source projects (Android\n> and wikimedia). This tends to leave issues from smaller projects, or\n> parties, left in limbo or voted against as they do not align with the\n> goals they see fit along with not offering a recourse for discussion of\n> it. \n>\n\nAccording to ohloh.net:\n\nhttp://www.ohloh.net/p/android - 576 developers\nhttp://www.ohloh.net/p/mediawiki - 233 developers\nhttp://www.ohloh.net/p/openstack - 1556 developers\n\nSo I\'m not sure why we would consider ourselves \"small\" as a user of\nGerrit. IMO we should carry 3x more weight than Android as users. I\nsuspect that we are considered \"small\" because our contribution is\nsmall.\n\n> The third problem I see it is how the system is extended itself, this is\n> through triggers and plugins. They get the job done, but leave much wanted\n> in easy of adding to the system. The first issue I see is with triggers,\n> you either have to script or write an application to connect into Gerrit\n> and poll for triggers on a review. Second is with plugins being pure java\n> code with a strict format of plugins that requires a developer to have a\n> fully working Gerrit developer install along with a working knowledge of\n> the structure of the plugin API in order to build a new plugin. (Not\n> difficult, but time consuming for developers that have never worked with\n> the Gerrit code base).\n>\n\nIs it unreasonable to try and add a better system for extending and\nintegrating with Gerrit? I go back to the fact that the challenge for a\nPython team with a python plugin will only be slightly less, so I don\'t\nthink this is a really great argument for writing something from\nscratch.\n\n> I feel that our proposal of a complete replacement written in python and\n> using parts of oslo will lead to a cleaner and more maintainable tool for\n> OpenStack in the long run. Using Oslo and styling standards of the\n> OpenStack project will allow a much greater audience of developers to\n> extend the system which I feel in turn will lead to a much better tool.\n>\n\nStoryboard is not a good example of a reason to do this. Storyboard\nis coming from a place where there really isn\'t a tool that will meet\nthe needs of OpenStack\'s processes. Launchpad is already written in\nPython, but we are not going to fix/extend it because it is an extremely\nmonolithic code base and we\'re not really interested in rewriting it to\nbe lean.\n\nTo my mind, Gerrit is doing its job well, and we\'d just like to make\nsome incremental improvements.\n\n> Also starting a new tool like this at this time gives us one more large\n> opportunity. This is being able to share code and integrate with\n> Storyboard from an early stage while Storyboard is still in development.\n> Currently integration of launchpad and Gerrit are at a very minimal\n> amount. With the ongoing development of Storyboard we are in a unique\n> place to be able to share style guidelines and UI elements leading to a\n> set of tools that will have a much more cohesive feel.\n> \n\n\nPlease please, even if you go through, do not integrate tightly with\nStoryboard. Use the API it provides, drive the API development, and keep\nthem modular so that we can improve them at different paces.\n\n\n','<CF4CB012.4C1B%philip.schwartz@rackspace.com>',NULL),('<1395085957.1001.27.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 15:52:37',-14400,'2014-03-17 19:52:37',NULL,'[openstack-dev] [nova] question about e41fb84 \"fix\n anti-affinity race condition on boot\"','On Mon, 2014-03-17 at 12:39 -0700, Joe Gordon wrote:\n> On Mon, Mar 17, 2014 at 12:29 PM, Andrew Laski\n> <andrew.laski at rackspace.com> wrote:\n>         On 03/17/14 at 01:11pm, Chris Friesen wrote:\n>                 On 03/17/2014 11:59 AM, John Garbutt wrote:\n>                         On 17 March 2014 17:54, John Garbutt\n>                         <john at johngarbutt.com> wrote:\n>                 \n>                                 Given the scheduler split, writing\n>                                 that value into the nova db from\n>                                 the scheduler would be a step\n>                                 backwards, and it probably breaks lots\n>                                 of code that assumes the host is not\n>                                 set until much later.\n>                 \n>                 Why would that be a step backwards?  The scheduler has\n>                 picked a host for the instance, so it seems reasonable\n>                 to record that information in the instance itself as\n>                 early as possible (to be incorporated into other\n>                 decision-making) rather than have it be implicit in\n>                 the destination of the next RPC message.\n>                 \n>                 Now I could believe that we have code that assumes\n>                 that having \"instance.host\" set implies that it\'s\n>                 already running on that host, but that\'s a different\n>                 issue.\n>                 \n>                         I forgot to mention, I am starting to be a fan\n>                         of a two-phase commit\n>                         approach, which could deal with these kinds of\n>                         things in a more\n>                         explicit way, before starting the main boot\n>                         process.\n>                         \n>                         Its not as elegant as a database transaction,\n>                         but that doesn\'t seems\n>                         possible in the log run, but there could well\n>                         be something I am\n>                         missing here too.\n>                 \n>                 I\'m not an expert in this area, so I\'m curious why you\n>                 think that database transactions wouldn\'t be possible\n>                 in the long run.\n>         \n>         \n>         There has been some effort around splitting the scheduler out\n>         of Nova and into its own project.  So down the road the\n>         scheduler may not have direct access to the Nova db.\n> \n> \n> If we do pull out the nova scheduler it can have its own DB, so I\n> don\'t think this should be an issue.\n\nJust playing devil\'s advocate here, but even if Gantt had its own\ndatabase, would that necessarily mean that there would be only a single\ndatabase across the entire deployment? I\'m thinking specifically in the\ncase of cells, where presumably, scheduling requests would jump through\nmultiple layers of Gantt services, would a single database transaction\nreally be possible to effectively fence the entire scheduling request?\n\nBest,\n-jay\n\n\n\n\n','<CAHXdxOds-xB3zXzBCzA==digEmvvB7EH7YDdEHKskuPuBXfoDg@mail.gmail.com>',NULL),('<1395120851.1001.36.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 01:34:11',-14400,'2014-03-18 05:34:11',NULL,'[openstack-dev] Automatic version creation in PBR','On Tue, 2014-03-18 at 09:55 +1300, Robert Collins wrote:\n> On 18 March 2014 07:28, Jay Pipes <jaypipes at gmail.com> wrote:\n> > On Mon, 2014-03-17 at 16:10 +1300, Robert Collins wrote:\n> \n> > Hi Rob, thanks for the heads up.\n> >\n> > A number of us use pbr for outside-of-OpenStack projects, and have\n> > relied on it for things like proper package versioning using git tags.\n> \n> Yup!\n> \n> > I\'m a little unclear what, if any, changes to my standard python sdist\n> > and upload actions I will need to take to publish releases of my\n> > projects that use pbr.\n> \n> If you set \'version\' in setup.cfg, pbr\'s behaviour will not change at all.\n> \n> If you do not set \'version\' in setup.cfg then:\n>  - for tagged commits, pbr\'s behaviour will not change at all.\n>  - for untagged commits, pbr will change from\n> \'$last_tag_version.$commit_count.g$sha\' to\n> \'$next_highest_pre_release.dev$commit_count.g$sha\'\n> \n> The last point is incompatible if you were uploading untagged commits\n> to pypi. Of course, you shouldn\'t be doing that because they are\n> pre-release versions but not marked as such for pypi!\n\nOK, cool. Thanks for the info. I only upload tagged commits to PyPI, not\nuntagged ones.\n\nThanks!\n-jay\n\n\n\n','<CAJ3HoZ1vhqnMaMaw7GgFnt0uZd92cMVSS1tpmq6u1D9b1_QcfQ@mail.gmail.com>',NULL),('<1395162170.7089.5.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 13:02:50',-14400,'2014-03-18 17:02:50',NULL,'[openstack-dev] Offset support in REST API pagination','On Tue, 2014-03-18 at 11:31 -0500, Steven Kaufer wrote:\n> First, here is some background on this topic:\n>  http://www.gossamer-threads.com/lists/openstack/dev/2777\n> \n> Does anyone have any insight as to why offset is not supported in the\n> REST API calls that support pagination?   I realize that there are\n> tradeoffs when using a offset (vs. marker) but I believe that there is\n> value in supporting both.  For example, if you want to jump to the\n> n-th page of data without having to traverse all of the previous\n> pages.\n> \n> Is there a reason why the APIs do not support either a marker or an\n> offset (obviously not both) on the API request?  It appears that\n> sqlalchemy has offset support.\n> \n> Also, it seems that cinder at least looks for the offset parameter\n> (but ignores it).  Does this mean that it was supported at one time\n> but later the support was removed?\n>  https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L214\n> \n> Thanks for the information.\n\nHail to thee, stranger! Thou hast apparently not passed into the cave of\nmarker/offset before!\n\nI humbly direct you to buried mailing list treasures which shall\nenlighten you!\n\nThis lengthy thread shall show you how yours truly was defeated in\nwritten combat by the great Justin Santa Barbara, who doth exposed the\nperils of the offset:\n\nhttp://www.gossamer-threads.com/lists/openstack/dev/2803\n\nA most recent incantation of the marker/offset wars is giveth here:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-November/018861.html\n\nBest of days to you,\n-jay\n\n\n\n','<OF70E5773B.082C9CBB-ON87257C9F.00574636-86257C9F.005AC41F@us.ibm.com>',NULL),('<1395171006.7089.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-18 15:30:06',-14400,'2014-03-18 19:30:06',NULL,'[openstack-dev] Offset support in REST API pagination','On Tue, 2014-03-18 at 13:30 -0500, Steven Kaufer wrote:\n> Jay Pipes <jaypipes at gmail.com> wrote on 03/18/2014 12:02:50 PM:\n> \n> > From: Jay Pipes <jaypipes at gmail.com>\n> > To: openstack-dev at lists.openstack.org, \n> > Date: 03/18/2014 12:15 PM\n> > Subject: Re: [openstack-dev] Offset support in REST API pagination\n> > \n> > On Tue, 2014-03-18 at 11:31 -0500, Steven Kaufer wrote:\n> > > First, here is some background on this topic:\n> > >  http://www.gossamer-threads.com/lists/openstack/dev/2777\n> > > \n> > > Does anyone have any insight as to why offset is not supported in\n> the\n> > > REST API calls that support pagination?   I realize that there are\n> > > tradeoffs when using a offset (vs. marker) but I believe that\n> there is\n> > > value in supporting both.  For example, if you want to jump to the\n> > > n-th page of data without having to traverse all of the previous\n> > > pages.\n> > > \n> > > Is there a reason why the APIs do not support either a marker or\n> an\n> > > offset (obviously not both) on the API request?  It appears that\n> > > sqlalchemy has offset support.\n> > > \n> > > Also, it seems that cinder at least looks for the offset parameter\n> > > (but ignores it).  Does this mean that it was supported at one\n> time\n> > > but later the support was removed?\n> > >  https://github.com/openstack/cinder/blob/master/cinder/api/v2/\n> > volumes.py#L214\n> > > \n> > > Thanks for the information.\n> > \n> > Hail to thee, stranger! Thou hast apparently not passed into the\n> cave of\n> > marker/offset before!\n> > \n> > I humbly direct you to buried mailing list treasures which shall\n> > enlighten you!\n> > \n> > This lengthy thread shall show you how yours truly was defeated in\n> > written combat by the great Justin Santa Barbara, who doth exposed\n> the\n> > perils of the offset:\n> > \n> > http://www.gossamer-threads.com/lists/openstack/dev/2803\n> > \n> > A most recent incantation of the marker/offset wars is giveth here:\n> > \n> >\n> http://lists.openstack.org/pipermail/openstack-dev/2013-November/018861.html\n> > \n> > Best of days to you,\n> > -jay\n> \n> Jay:\n> \n> Thanks for the feedback and the history on this topic. \n\nNo probs. Thanks for indulging my Renaissance binge this morning.\n\n> I understand that the limit/marker\n> approach is superior when simply traversing all of the pages. However,\n> consider the\n> following:\n> \n> - User knows that there are 1000 items (VMs, volumes, images, really\n> doesn\'t matter)\n> - User knows that the item that they want is in roughly the middle of\n> the data set (assume\n> everything is sorted by display name)\n> - User cannot remember the exact name so a filter will not help and\n> changing the sort \n> direction will not help (since the item they want it is in the middle\n> of the dataset)\n> - User supplies an offset of 500 to jump into the middle of the data\n> set\n> - User then uses the marker approach to traverse the pages from this\n> point to find the\n> item that they want\n> \n> In this case the offset approach is not used to traverse pages so\n> there are no issues with\n> missing an item or seeing a duplicate.\n\nI guess I wonder how common that use case is, actually. I can\'t remember\never running into a user who asked for such a thing, but perhaps that\'s\njust me.\n\n> Why couldn\'t the APIs support either marker or offset on a given\n> request? \n\nI think for two reasons:\n\n1) Would be potentially quite confusing to the user\n2) We\'re lazy? :)\n\n> Also, to encourage\n> the use of marker instead of offset, the next/previous links on any\n> request with an offset\n> supplied should contain the appropriate marker key values -- this\n> should help discourage\n> simply increasing the offset when traversing the pages.\n\nWell, yes, this already happens today in the projects that support\npagination, AFAIK.\n\nBest,\n-jay\n\n> I realize that if only one solution had to be chosen, then\n> limit/marker would always win\n> this war. But why can\'t both be supported?\n> \n> Thanks,\n> \n> Steven Kaufer\n> \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OF9A08521F.726AA522-ON87257C9F.006331F0-86257C9F.0065A338@us.ibm.com>',NULL),('<1395213059-sup-4042@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 01:20:45',-25200,'2014-03-19 08:20:45',NULL,'[openstack-dev] UTF-8 required charset/encoding for openstack\n	database?','Excerpts from Doug Hellmann\'s message of 2014-03-18 15:08:36 -0700:\n> On Mon, Mar 10, 2014 at 4:02 PM, Ben Nemec <openstack at nemebean.com> wrote:\n> \n> > On 2014-03-10 12:24, Chris Friesen wrote:\n> >\n> >> Hi,\n> >>\n> >> I\'m using havana and recent we ran into an issue with heat related to\n> >> character sets.\n> >>\n> >> In heat/db/sqlalchemy/api.py in user_creds_get() we call\n> >> _decrypt() on an encrypted password stored in the database and then\n> >> try to convert the result to unicode.  Today we hit a case where this\n> >> errored out with the following message:\n> >>\n> >> UnicodeDecodeError: \'utf8\' codec can\'t decode byte 0xf2 in position 0:\n> >> invalid continuation byte\n> >>\n> >> We\'re using postgres and currently all the databases are using\n> >> SQL_ASCII as the charset.\n> >>\n> >> I see that in icehouse heat will complain if you\'re using mysql and\n> >> not using UTF-8.  There doesn\'t seem to be any checks for other\n> >> databases though.\n> >>\n> >> It looks like devstack creates most databases as UTF-8 but uses latin1\n> >> for nova/nova_bm/nova_cell.  I assume this is because nova expects to\n> >> migrate the db to UTF-8 later.  Given that those migrations specify a\n> >> character set only for mysql, when using postgres should we explicitly\n> >> default to UTF-8 for everything?\n> >>\n> >> Thanks,\n> >> Chris\n> >>\n> >\n> > We just had a discussion about this in #openstack-oslo too.  See the\n> > discussion starting at 2014-03-10T16:32:26 http://eavesdrop.openstack.\n> > org/irclogs/%23openstack-oslo/%23openstack-oslo.2014-03-10.log\n> >\n> > While it seems Heat does require utf8 (or at least matching character\n> > sets) across all tables, I\'m not sure the current solution is good.  It\n> > seems like we may want a migration to help with this for anyone who might\n> > already have mismatched tables.  There\'s a lot of overlap between that\n> > discussion and how to handle Postgres with this, I think.\n> >\n> > I don\'t have a definite answer for any of this yet but I think it is\n> > something we need to figure out, so hopefully we can get some input from\n> > people who know more about the encoding requirements of the Heat and other\n> > projects\' databases.\n> >\n> > -Ben\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> Based on the discussion from the project meeting today [1], the Glance\n> team is going to write a migration to fix the database as the other\n> projects have (we have not seen issues with corrupted data, so we believe\n> this to be safe). However, there is one snag. In a follow-up conversation\n> with Ben in #openstack-oslo, he pointed out that no migrations will run\n> until the encoding is correct, so we do need to make some changes to the db\n> code in oslo.\n> \n\n\nHi! Thanks for considering the plight of the users that have high-byte\ncharacters, but in reading the referenced IRC log, there was a lot of\n\"hoping for the best\" in the outcome.\n\nHowever, I think Glance in particular is likely to find the bugs in this\napproach, as users are more apt to name images with descriptive words\nthan networks, servers, and volumes.\n\nAnyway, if you do have latin1 tables that have utf-8 encoded data already\nin them, you can\'t just alter table. Let me explain the scenario with\na simple copy/paste:\n\nFirst, let\'s assume you\'ve done nothing really and the server is just\nset to latin1, but your client is utf-8:\n\nmysql> insert into t1 values (2, \'? ?\');\nQuery OK, 1 row affected, 1 warning (0.05 sec)\n\nThe warning there is that this is a latin1 table, and those are wide\nchars, so they got stripped:\n\nmysql> select * from t1;\n+----+---------+\n| id | data    |\n+----+---------+\n|  1 | no utf8 |\n|  2 | ? ?     |\n+----+---------+\n\nNow you may also have a situation where your client is defaulting to\nlatin1:\n\nmysql> insert into t1 values (3, \'? ?\');\nQuery OK, 1 row affected (0.05 sec)\n\nNote, zero warnings. What happened here?\n\nmysql> select * from t1;\n+----+---------+\n| id | data    |\n+----+---------+\n|  1 | no utf8 |\n|  2 | ? ?     |\n|  3 | ? ? |\n+----+---------+\n\nOH EXCELLENT! My data looks right. Let\'s ignore that mysql thinks it is\n6 chars, not 2, because we probably won\'t ever notice that.\n\nNow I fix my clients and they start using utf-8:\n\nmysql> set names \'utf8\';\nQuery OK, 0 rows affected (0.00 sec)\n\nmysql> select * from t1;\n+----+-----------------+\n| id | data            |\n+----+-----------------+\n|  1 | no utf8         |\n|  2 | ? ?             |\n|  3 | ??? ??? |\n+----+-----------------+\n3 rows in set (0.00 sec)\n\nDoh, what are those trademarked a\'s?\n\nThis is often where app writers give up, switch back to latin1, and\nthink they\'re fine because at least data is coming out the way it went\nin. But now you have utf-8 in a latin1 table. If you alter this:\n\nmysql> alter table t1 convert to character set \'utf8\';\nQuery OK, 3 rows affected (0.28 sec)\nRecords: 3  Duplicates: 0  Warnings: 0\n\nmysql> select * from t1;\n+----+-----------------+\n| id | data            |\n+----+-----------------+\n|  1 | no utf8         |\n|  2 | ? ?             |\n|  3 | ??? ??? |\n+----+-----------------+\n3 rows in set (0.01 sec)\n\nUGH! Oh wait, I\'m still latin1... switch client to utf8:\n\nmysql> select * from t1;\n+----+-----------------+\n| id | data            |\n+----+-----------------+\n|  1 | no utf8         |\n|  2 | ? ?             |\n|  3 | ??? ???         |\n+----+-----------------+\n3 rows in set (0.00 sec)\n\nDOH!\n\nThis is really frustrating. Also detecting that this situation is even\npresent is difficult because detecting UTF-8 can be problematic.\n\nWhat you have to do is create a new table that is utf-8, and then have a\nclient with two connections:\n\n1) latin1 to the server to select out records incorrectly encoded\n2) utf-8 to the server to insert correctly encoded utf-8 into new table.\n\nYou can probably do this, but I suggest testing it with high-byte UTF-8\nin the db before the migration runs to see if they\'re still displayed\ncorrectly.\n\n\n','<CADb+p3RAxHOTDqv7gsMaLh6Ojn6VU1TUKpYWpboXKHPZHGW7eA@mail.gmail.com>',NULL),('<1395230800.24583.46.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 12:06:40',0,'2014-03-19 12:06:40',NULL,'[openstack-dev] [Marconi] Why is marconi a queue implementation\n vs a provisioning API?','On Wed, 2014-03-19 at 10:17 +1300, Robert Collins wrote:\n> So this came up briefly at the tripleo sprint, and since I can\'t seem\n> to find a /why/ document\n> (https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers\n> and https://wiki.openstack.org/wiki/Marconi#Design don\'t supply this)\n\nI think we need a slight reset on this discussion. The way this email\nwas phrased gives a strong sense of \"Marconi is a dumb idea, it\'s going\nto take a lot to persuade me otherwise\".\n\nThat\'s not a great way to start a conversation, but it\'s easy to\nunderstand - a TC member sees a project on the cusp of graduating and,\nwhen they finally get a chance to look closely at it, a number of things\ndon\'t make much sense. \"Wait! Stop! WTF!\" is a natural reaction if you\nthink a bad decision is about to be made.\n\nWe\'ve all got to understand how pressurized a situation these graduation\nand incubation discussions are. Projects put an immense amount of work\ninto proving themselves worthy of being an integrated project, they get\nfairly short bursts of interaction with the TC, TC members aren\'t\nnecessarily able to do a huge amount of due diligence in advance and yet\nTC members are really, really keen to avoid either undermining a healthy\nproject around some cool new technology or undermining OpenStack by\nincluding an unhealthy project or sub-par technology.\n\nAnd then there\'s the time pressure where a decision has to be made by a\ncertain date and if that decision is \"not this time\", the six months\ndelay until the next chance for a positive decision can be really\ndraining on motivation and momentum when everybody had been so focused\non getting a positive decision this time around.\n\nWe really need cool heads here and, above all, to try our best to assume\ngood faith, intentions and ability on both sides.\n\n\nSome of the questions Robert asked are common questions and I know they\nwere discussed during the incubation review. However, the questions\npersist and it\'s really important that TC members (and the community at\nlarge) feel they can stand behind the answers to those questions. If I\'m\nchatting to someone and they ask me \"why does OpenStack need to\nimplement its own messaging broker?\", I need to have a good answer.\n\nHow about we do our best to put the implications for the graduation\ndecision aside for a bit and focus on collaboratively pulling together a\nFAQ that everyone can buy into? The \"raised questions and answers\"\nsection of the incubation review linked above is a good start, but I\nthink we can take this email as feedback that those questions and\nanswers need much improvement.\n\nThis could be a good pattern for all new projects - if the TC and the\nnew project can\'t work together to draft a solid FAQ like this, then\nit\'s not a good sign for the project.\n\nSee below for my attempt to summarize the questions and how we might go\nabout answering them. Is this a reasonable start?\n\nMark.\n\n\nWhy isn\'t Marconi simply an API for provisioning and managing AMQP, Kestrel,\nZeroMQ, etc. brokers and queues? Why is a new broker implementation needed?\n\n => I\'m not sure I can summarize the answer here - the need for a HTTP data\n    plane API, the need for multi-tenancy, etc.? Maybe a table listing the\n    required features and whether they\'re provided by these existing solutions.\n\n    Maybe there\'s also an element of \"we think we can do a better job\". If so,\n    the point probably worth addressing is \"OpenStack shouldn\'t attempt to write\n    a new database, or a new hypervisor, or a new SDN controller, or a new block\n    storage implementation ... so why should we write a implement a new message\n    broker? If this is just a bad analogy, explain why?\n\nImplementing a message queue using an SQL DB seems like a bad idea, why is\nMarconi doing that?\n\n => Perhaps explain why MongoDB is a good storage technology for this use case\n    and the SQLalchemy driver is just a toy.\n\nMarconi\'s default driver depends on MongoDB which is licensed under the AGPL.\nThis license is currently a no-go for some organizations, so what plans does\nMarconi have to implement another production-ready storage driver that supports\nall API features?\n\n => Discuss the Redis driver plans?\n\nIs Marconi designed to be suitable for use by OpenStack itself?\n\n => Discuss that it\'s not currently in scope and why not. In what way does the\n    OpenStack use case differ from the applications Marconi\'s current API\n    focused on?\n\nHow should a client subscribe to a queue?\n\n => Discuss that it\'s not by GET /messages but instead POST /claims?limit=N\n\n\n\n\n\n','<CAJ3HoZ0UvPaj0QmC-p4w4JTjWcwdirDqC0f9i0mGVNLVb38CpQ@mail.gmail.com>',NULL),('<1395237311.7089.13.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 09:55:11',-14400,'2014-03-19 13:55:11',NULL,'[openstack-dev] WSGI and Python paste','On Wed, 2014-03-19 at 14:25 +0100, victor stinner wrote:\n> Hi,\n> \n> According to the following table, paste is blocking many OpenStack servers to be ported to Python 3:\n> \n>    https://wiki.openstack.org/wiki/Python3#Core_OpenStack_projects\n> \n> The author of paste, Ian Bicking, gave me the commit permission to paste. I integrated patches from Debian and my colleague Cyril Roelandt, and I added even more patches. All these changes are just for the Python 3 syntax (import, except as, print, etc.). It looks like paste doesn\'t know anything about Python 3 and WSGI 1.0.1 (PEP 3333):\n> \n>     http://legacy.python.org/dev/peps/pep-3333/\n> \n> A function handling a web page must return bytes (b\'data\' in Python 3), whereas nativate string can be used in Python 2. It looks like paste is old (last release was 4 years ago, version 1.7.5.1 in 2010). Even the author of paste suggest to use something else like WebOb:\n> \n>    \"Paste has been under development for a while, and has lots of code in it. Too much code! The code is largely decoupled except for some core functions shared by many parts of the code. Those core functions are largely replaced in WebOb, and replaced with better implementations.\"\n> \n>    http://pythonpaste.org/future.html#introduction\n> \n> What is the plan for OpenStack? Should we use something else?\n\nAFAIK, we only use paste.deploy, and we use WebOb already (even though\nit has a host of issues itself...)\n\nBest,\n-jay\n\n\n\n','<23398191.10845270.1395235524850.JavaMail.zimbra@enovance.com>',NULL),('<1395241234.7089.17.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 11:00:34',-14400,'2014-03-19 15:00:34',NULL,'[openstack-dev] [Nova] First time contributing to some project','On Wed, 2014-03-19 at 17:33 +0530, Dharmit Shah wrote:\n> Hello Stackers,\n> \n> This is the first time I am mailing some dev mailing list and first\n> time I am trying to contribute on some open source project.\n\nWelcome, Dharmit, nice to have you in our community! :)\n\n> I am working on a low-hanging-fruit bug\n> (https://bugs.launchpad.net/nova/+bug/1261909). It\'s about removing\n> hba specific code from nova as cinder manages the volume part.\n> \n> The function in question is get_fc_hbas() in the\n> nova/virt/libvirt/utils.py file. This function is being referred by\n> get_fc_hbas_info() function in the same file and connect_volume()\n> function in nova/virt/libvirt/volume.py file. Issue is that the latter\n> is being used in a lot of other files across nova code.\n> \n> I think the same connect_volume() function is defined in\n> cinder/brick/initiator/connector.py file and has similar code as that\n> in nova/virt/libvirt/volume.py. Should I just nuke all the\n> get_fc_hbas(), get_fc_hbas_info() and connect_volume() definitions and\n> reference from the nova code?\n> \n> I am really confused about how I should proceed further on this. Can\n> someone please help me get started with this?\n\nHop on Freenode IRC, #openstack-nova channel, and have a chat with the\noriginal bug reporter Padraig Brady (pixelb on IRC) or John Garbutt\n(johnthetubaguy on IRC), who commented on the bug as well. I\'m sure\neither would be happy to provide more information to you.\n\nIf they aren\'t around, a number of other folks, including myself\n(jaypipes on IRC), are available to help as well.\n\nBest,\n-jay\n\n\n\n','<CADeFzXvdiO6WHFETV47DmUhfmxvBmPcsWUKxJP_ehNmE-Ju40w@mail.gmail.com>',NULL),('<1395253234-sup-4804@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-19 11:21:32',-25200,'2014-03-19 18:21:32',NULL,'[Openstack] [Barbican] Key Recovery / Availability','Excerpts from Clark, Robert Graham\'s message of 2014-03-19 07:41:35 -0700:\n> Has there been much discussion on how to ensure that keys are\n> recoverable in the event that Barbican has some sort of horrific\n> failure? \n> \n> I suppose a HA frontend, Redundant Keystore Databases and HA paired HSMs\n> would be the most obvious non-code-writing path but this feels pretty\n> clunky, I was wondering if it had been discussed yet? Possibly it should\n> be something for a design session?\n> \n\nSorry, what is clunky about backing up your data?\n\n\n','<A0C170085C37664D93EE1604364858A11024B39A@G9W0763.americas.hpqcorp.net>',NULL),('<1395254435-sup-5866@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 11:44:25',-25200,'2014-03-19 18:44:25',NULL,'[openstack-dev] [TripleO] Alternating meeting time for more TZ\n	friendliness','Excerpts from Sullivan, Jon Paul\'s message of 2014-03-19 09:26:44 -0700:\n> > From: James Slagle [mailto:james.slagle at gmail.com]\n> > Sent: 18 March 2014 19:58\n> > Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ\n> > friendliness\n> > \n> > Our current meeting time is Tuesdays at 19:00 UTC.  I think this works\n> > ok for most folks in and around North America.\n> > \n> > It was proposed during today\'s meeting to see if there is interest is an\n> > alternating meeting time every other week so that we can be a bit more\n> > friendly to those folks that currently can\'t attend.\n> > If that interests you, speak up :).\n> \n> Speaking up! :D\n> \n> > \n> > For reference, the current meeting schedules are at:\n> > https://wiki.openstack.org/wiki/Meetings\n>     \n> Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.\n> \n\nIf we were to have one at that time, we\'d need to move the other time as\nwell. One driver for moving it is that our participants on the Eastern\nside of Australia are already joining at 0600 their time, and will be\njoining at 0500 soon.\n\nIf I\'ve done my TZ math right, Tuesdays at 1400 UTC would be Wednesdays\nat 0100 for Sydney.\n\n\n','<A5492763B7A1E640AEB5E1C05208B1F2543D900E@G9W0752.americas.hpqcorp.net>',NULL),('<1395281537-sup-8378@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-19 19:14:53',-25200,'2014-03-20 02:14:53',NULL,'[openstack-dev] Updating libvirt in gate jobs','Excerpts from Joe Gordon\'s message of 2014-03-18 17:15:59 -0700:\n> On Tue, Mar 18, 2014 at 8:12 AM, Sean Dague <sean at dague.net> wrote:\n> \n> > On 03/18/2014 10:11 AM, Daniel P. Berrange wrote:\n> > > On Tue, Mar 18, 2014 at 07:50:15AM -0400, Davanum Srinivas wrote:\n> > >> Hi Team,\n> > >>\n> > >> We have 2 choices\n> > >>\n> > >> 1) Upgrade to libvirt 0.9.8+ (See [1] for details)\n> > >> 2) Enable UCA and upgrade to libvirt 1.2.2+ (see [2] for details)\n> > >>\n> > >> For #1, we received a patched deb from @SergeHallyn/@JamesPage and ran\n> > >> tests on it in review https://review.openstack.org/#/c/79816/\n> > >> For #2, @SergeHallyn/@JamesPage have updated UCA\n> > >> (\"precise-proposed/icehouse\") repo and we ran tests on it in review\n> > >> https://review.openstack.org/#/c/74889/\n> > >>\n> > >> For IceHouse, my recommendation is to request Ubuntu folks to push the\n> > >> patched 0.9.8+ version we validated to public repos, then we can can\n> > >> install/run gate jobs with that version. This is probably the smallest\n> > >> risk of the 2 choices.\n> > >\n> > > If we\'ve re-run the tests in that review enough times to be confident\n> > > we\'ve had a chance of exercising the race conditions, then using the\n> > > patched 0.9.8 seems like a no-brainer. We know the current version in\n> > > ubuntu repos is broken for us, so the sooner we address that the better.\n> >\n> \n> \n> ++\n> \n> >  >\n> > >> As soon as Juno begins, we can switch 1.2.2+ on UCA and request Ubuntu\n> > >> folks to push the verified version where we can use it.\n> >\n> \n> ++\n> \n> >  >\n> > > This basically re-raises the question of /what/ we should be testing in\n> > > the gate, which was discussed on this list a few weeks ago, and I\'m not\n> > > clear that there was a definite decision in that thread\n> > >\n> > >\n> > http://lists.openstack.org/pipermail/openstack-dev/2014-February/027734.html\n> > >\n> > > Testing the lowest vs highest is targetting two different scenarios\n> > >\n> > >   - Testing the lowest version demonstrates that OpenStack has not\n> > >     broken its own code by introducing use of a new feature.\n> > >\n> > >   - Testing the highest version demonstrates that OpenStack has not\n> > >     been broken by 3rd party code introducing a regression.\n> > >\n> > > I think it is in scope for openstack to be targetting both of these\n> > > scenarios. For anything in-between though, it is upto the downstream\n> > > vendors to test their precise combination of versions. Currently though\n> > > our testing policy for non-python bits is \"whatever version ubuntu\n> > ships\",\n> > > which may be neither the lowest or highest versions, just some arbitrary\n> > > version they wish to support. So this discussion is currently more of a\n> > > \'what ubuntu version should we test on\' kind of decision\n> >\n> > I think testing 2 versions of libvirt in the gate is adding a matrix\n> > dimension that we currently can\'t really support. We\'re just going to\n> > have to pick one per release and be fine with it (at least for icehouse).\n> >\n> > If people want other versions tested, please come in with 3rd party ci\n> > on it.\n> >\n> > We can revisit the big test matrix at summit about the combinations\n> > we\'re going to actually validate, because with the various limitations\n> > we\'ve got (concurrency limits, quota limits, upstream package limits,\n> > kinds of tests we want to run) we\'re going to have to make a bunch of\n> > compromises. Testing something new is going to require throwing existing\n> > stuff out of the test path.\n> >\n> \n> I think this is definitely worth revisiting at the summit, but I think we\n> should move Juno to Libvirt 1.2.2+ as soon as possible instead of gating on\n> a 2 year old release, and at the summit we can sort out what the full test\n> matrix can be.\n> \n\nWe\'ll get this for free just by moving to Ubuntu 14.04 (aka \"Trusty\"),\nwhich will release on April 17.\n\n> As a side note tripleo uses libvirt from Saucy (1.1.1) so moving to latest\n> libvirt would help support them.\n\nWe will move to trusty _ASAP_. Basically on April 17 we\'ll start testing\nit and when it passes CI we\'ll be on it.\n\n\n','<CAHXdxOcNEcnzg+MRfvdfPSxhbHMew7Fc5VWJjz+px9oe5DvLfA@mail.gmail.com>',NULL),('<1395305688.2952.31.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 08:54:48',0,'2014-03-20 08:54:48',NULL,'[openstack-dev] [Marconi] Why is marconi a queue implementation\n vs a provisioning API?','On Thu, 2014-03-20 at 01:28 +0000, Joshua Harlow wrote:\n> Proxying from yahoo\'s open source director (since he wasn\'t initially\n> subscribed to this list, afaik he now is) on his behalf.\n> \n> From Gil Yehuda (Yahoo?s Open Source director).\n> \n> I would urge you to avoid creating a dependency between Openstack code\n> and any AGPL project, including MongoDB. MongoDB is licensed in a very\n> strange manner that is prone to creating unintended licensing mistakes\n> (a lawyer?s dream). Indeed, MongoDB itself presents Apache licensed\n> drivers ? and thus technically, users of those drivers are not\n> impacted by the AGPL terms. MongoDB Inc. is in the unique position to\n> license their drivers this way (although they appear to violate the\n> AGPL license) since MongoDB is not going to sue themselves for their\n> own violation. However, others in the community create MongoDB drivers\n> are licensing those drivers under the Apache and MIT licenses ? which\n> does pose a problem.\n> \n> Why? The AGPL considers \'Corresponding Source\' to be defined as ?the\n> source code for shared libraries and dynamically linked subprograms\n> that the work is specifically designed to require, such as by intimate\n> data communication or control flow between those subprograms and other\n> parts of the work.\" Database drivers *are* work that is designed to\n> require by intimate data communication or control flow between those\n> subprograms and other parts of the work. So anyone using MongoDB with\n> any other driver now invites an unknown --  that one court case, one\n> judge, can read the license under its plain meaning and decide that\n> AGPL terms apply as stated. We have no way to know how far they apply\n> since this license has not been tested in court yet.\n> Despite all the FAQs MongoDB puts on their site indicating they don\'t\n> really mean to assert the license terms, normally when you provide a\n> license, you mean those terms. If they did not mean those terms, they\n> would not use this license. I hope they intended to do something good\n> (to get contributions back without impacting applications using their\n> database) but, even good intentions have unintended consequences.\n> Companies with deep enough pockets to be lawsuit targets, and\n> companies who want to be good open source citizens face the problem\n> that using MongoDB anywhere invites the future risk of legal\n> catastrophe. A simple development change in an open source project can\n> change the economics drastically. This is simply unsafe and unwise.\n> \n> OpenStack\'s ecosystem is fueled by the interests of many commercial\n> ventures who wish to cooperate in the open source manner, but then\n> leverage commercial opportunities they hope to create. I suggest that\n> using MongoDB anywhere in this project will result in a loss of\n> opportunity -- real or perceived, that would outweigh the benefits\n> MongoDB itself provides.\n> \n> tl;dr version: If you want to use MongoDB in your company, that\'s your\n> call. Please don\'t turn anyone who uses OpenStack components into a\n> unsuspecting MongoDB users. Instead, decouple the database from the\n> project. It\'s not worth the legal risk, nor the impact on the\n> \"Apache-ness\" of this project.\n\nThanks for that, Josh and Gil.\n\nRather than cross-posting, I think this MongoDB/AGPLv3 discussion should\ncontinue on the legal-discuss mailing list:\n\n  http://lists.openstack.org/pipermail/legal-discuss/2014-March/thread.html#174\n\nBear in mind that we (OpenStack, as a project and community) need to\njudge whether this is a credible concern or not. If some users said they\nwere only willing to deploy Apache licensed code in their organization,\nwe would dismiss that notion pretty quickly. Is this AGPLv3 concern\nsufficiently credible that OpenStack needs to take it into account when\nmaking important decisions? That\'s what I\'m hoping to get to in the\nlegal-discuss thread.\n\nMark.\n\n\n\n','<CF4F91B7.59FF3%harlowja@yahoo-inc.com>',NULL),('<1395306540.2952.37.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 09:09:00',0,'2014-03-20 09:09:00',NULL,'[openstack-dev] [Marconi] Why is marconi a queue implementation\n vs a provisioning API?','On Wed, 2014-03-19 at 12:37 -0700, Devananda van der Veen wrote:\n> Let me start by saying that I want there to be a constructive discussion\n> around all this. I\'ve done my best to keep my tone as non-snarky as I could\n> while still clearly stating my concerns. I\'ve also spent a few hours\n> reviewing the current code and docs. Hopefully this contribution will be\n> beneficial in helping the discussion along.\n\nThanks, I think it does.\n\n> For what it\'s worth, I don\'t have a clear understanding of why the Marconi\n> developer community chose to create a new queue rather than an abstraction\n> layer on top of existing queues. While my lack of understanding there isn\'t\n> a technical objection to the project, I hope they can address this in the\n> aforementioned FAQ.\n> \n> The reference storage implementation is MongoDB. AFAIK, no integrated\n> projects require an AGPL package to be installed, and from the discussions\n> I\'ve been part of, that would be a show-stopper if Marconi required\n> MongoDB. As I understand it, this is why sqlalchemy support was required\n> when Marconi was incubated. Saying \"Marconi also supports SQLA\" is\n> disingenuous because it is a second-class citizen, with incomplete API\n> support, is clearly not the recommended storage driver, and is going to be\n> unusuable at scale (I\'ll come back to this point in a bit).\n> \n> Let me ask this. Which back-end is tested in Marconi\'s CI? That is the\n> back-end that matters right now. If that\'s Mongo, I think there\'s a\n> problem. If it\'s SQLA, then I think Marconi should declare any features\n> which SQLA doesn\'t support to be optional extensions, make SQLA the\n> default, and clearly document how to deploy Marconi at scale with a SQLA\n> back-end.\n> \n> \n> Then there\'s the db-as-a-queue antipattern, and the problems that I have\n> seen result from this in the past... I\'m not the only one in the OpenStack\n> community with some experience scaling MySQL databases. Surely others have\n> their own experiences and opinions on whether a database (whether MySQL or\n> Mongo or Postgres or ...) can be used in such a way _at_scale_ and not fall\n> over from resource contention. I would hope that those members of the\n> community would chime into this discussion at some point. Perhaps they\'ll\n> even disagree with me!\n> \n> A quick look at the code around claim (which, it seems, will be the most\n> commonly requested action) shows why this is an antipattern.\n> \n> The MongoDB storage driver for claims requires _four_ queries just to get a\n> message, with a serious race condition (but at least it\'s documented in the\n> code) if multiple clients are claiming messages in the same queue at the\n> same time. For reference:\n> \n> https://github.com/openstack/marconi/blob/master/marconi/queues/storage/mongodb/claims.py#L119\n> \n> The SQLAlchemy storage driver is no better. It\'s issuing _five_ queries\n> just to claim a message (including a query to purge all expired claims\n> every time a new claim is created). The performance of this transaction\n> under high load is probably going to be bad...\n> \n> https://github.com/openstack/marconi/blob/master/marconi/queues/storage/sqlalchemy/claims.py#L83\n> \n> Lastly, it looks like the Marconi storage drivers assume the storage\n> back-end to be infinitely scalable. AFAICT, the mongo storage driver\n> supports mongo\'s native sharding -- which I\'m happy to see -- but the SQLA\n> driver does not appear to support anything equivalent for other back-ends,\n> eg. MySQL. This relegates any deployment using the SQLA backend to the\n> scale of \"only what one database instance can handle\". It\'s unsuitable for\n> any large-scale deployment. Folks who don\'t want to use Mongo are likely to\n> use MySQL and will be promptly bitten by Marconi\'s lack of scalability with\n> this back end.\n> \n> While there is a lot of room to improve the messaging around what/how/why,\n> and I think a FAQ will be very helpful, I don\'t think that Marconi should\n> graduate this cycle because:\n> (1) support for a non-AGPL-backend is a legal requirement [*] for Marconi\'s\n> graduation;\n> (2) deploying Marconi with sqla+mysql will result in an incomplete and\n> unscalable service.\n> \n> It\'s possible that I\'m wrong about the scalability of Marconi with sqla +\n> mysql. If anyone feels that this is going to perform blazingly fast on a\n> single mysql db backend, please publish a benchmark and I\'ll be very happy\n> to be proved wrong. To be meaningful, it must have a high concurrency of\n> clients creating and claiming messages with (num queues) << (num clients)\n> << (num messages), and all clients polling on a reasonably short interval,\n> based on what ever the recommended client-rate-limit is. I\'d like the test\n> to be repeated with both Mongo and SQLA back-ends on the same hardware for\n> comparison.\n\nMy guess (and it\'s just a guess) is that the Marconi developers almost\nwish their SQLA driver didn\'t exist after reading your email because of\nthe confusion it\'s causing. My understanding is that the SQLA driver is\nnot intended for production usage.\n\nIf Marconi just had a MongoDB driver, I think your points would boil\ndown to:\n\n  \"I don\'t have a clear understanding of why the Marconi developer\n   community chose to create a new queue rather than an abstraction\n   layer on top of existing queues\"\n\n  \"no integrated projects require an AGPL package to be installed, and\n   from the discussions I\'ve been part of, that would be a show-stopper\n   if Marconi required MongoDB\"\n\n  \"whether a database like Mongo can be used in such a way _at_scale_\n   and not fall over from resource contention. The MongoDB storage\n   driver for claims requires _four_ queries just to get a message, with\n   a serious race condition if multiple clients are claiming messages in\n   the same queue at the same time.\"\n\nI think the first two concerns have been expressed already, but the\nthird one is new. I\'ve put my attempt at drafting a FAQ here:\n\n  https://etherpad.openstack.org/p/draft-marconi-faq\n\nand added the scalability concern to it.\n\nThanks,\nMark.\n\n\n\n','<CAExZKEp+1AKOVPtxk47uRDBdAPPcR8fg4ULBVULWVdNdv=8LHg@mail.gmail.com>',NULL),('<1395311317.90.1365746699461.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-12 06:04:59',0,'2013-04-12 06:04:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #2','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/2/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-12 06:04:52    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:04:52,514 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-12 06:04:52,514 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:04:52,515 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,516 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,516 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-12 06:04:52,517 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-12 06:04:52,517 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-12 06:04:52  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-12 06:04:52,518 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:04:52    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:04:52,519 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,522 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.521921\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.521921\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52,522 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,523 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,523 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,524 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52,525 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.524804\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.524804\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52,526 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,527 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,527 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:04:52,528 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,528 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,529 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52,530 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.529730\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.529730\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52,531 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,531 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,532 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:04:52,532 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,533 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,534 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52,535 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.534295\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.534295\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52,536 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,536 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,537 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:04:52,537 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,538 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,539 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:04:52,540 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:04:52,541 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.540578\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:04:52.540578\', resource_metadata={}) from 0 transformer\n2013-04-12 06:04:52,542 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,542 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52,543 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:04:52,543 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:04:52,544 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:04:52    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.313s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.2\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a43.g50c2020\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==2.5.10\nlxml==3.1.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a298.g4861a3b\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.vkd2yK1NQe\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/2\n[SCP] Copying console log.\n\n\n','<41840940.76.1365660457868.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1395318963.2952.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 12:36:03',0,'2014-03-20 12:36:03',NULL,'[openstack-dev] [legal-discuss] [Marconi] Why is marconi a\n queue implementation vs a provisioning API?','On Thu, 2014-03-20 at 12:07 +0100, Thierry Carrez wrote:\n> Monty Taylor wrote:\n> > On 03/20/2014 01:30 AM, Radcliffe, Mark wrote:\n> >> The problem with AGPL is that the scope is very uncertain and the\n> >> determination of the  consequences are very fact intensive. I was the\n> >> chair of the User Committee in developing the GPLv3 and I am therefor\n> >> quite familiar with the legal issues.  The incorporation of AGPLv3\n> >> code Into OpenStack Project  is a significant decision and should not\n> >> be made without input from the Foundation. At a minimum, the\n> >> inclusion of APLv3 code means that the OpenStack Project is no longer\n> >> solely an Apache v2 licensed project because AGPLv3 code cannot be\n> >> licensed under Apache v. 2 License.  Moreover, the inclusion of such\n> >> code is inconsistent with the current CLA provisions.\n> >>\n> >> This code can be included but it is an important decision that should\n> >> be made carefully.\n> > \n> > I agree - but in this case, I think that we\'re not talking about\n> > including AGPL code in OpenStack as much as we are talking about using\n> > an Apache2 driver that would talk to a server that is AGPL ... if the\n> > deployer chooses to install the AGPL software. I don\'t think we\'re\n> > suggesting that downloading or installing openstack itself would involve\n> > downloading or installing AGPL code.\n> \n> Yes, the issue here is more... a large number of people want to stay\n> away from AGPL. Should the TC consider adding to the OpenStack\n> integrated release a component that requires AGPL software to be\n> installed alongside it ? It\'s not really a legal issue (hence me\n> stopping the legal-issues cross-posting).\n\nWe need to understand the reasons \"people want to stay away from the\nAGPL\". Those reasons appear to be legal reasons, and not necessarily\nwell founded. I think legal-discuss can help tease those out.\n\nI don\'t (yet) accept that there\'s a reasonable enough concern for the\nOpenStack project to pander to.\n\nI\'m no fan of the AGPL, but we need to be able to articulate any policy\ndecision we make here beyond \"some people don\'t like the AGPL\".\n\nFor example, if we felt the AGPL fears weren\'t particularly well founded\nthen we could make a policy decision that projects should have an\nabstraction that would allow those with AGPL fears add support for\nanother technology ... but that the project wouldn\'t be required to do\nso itself before graduating.\n\n> This was identified early on as a concern with Marconi and the SQLA\n> support was added to counter that concern. The question then becomes,\n> how usable this SQLA option actually is ? If it\'s sluggish, unusable in\n> production or if it doesn\'t fully support the proposed Marconi API, then\n> I think we still have that concern.\n\nI understood that a future Redis driver was what the Marconi team had in\nmind to address this concern and the SQLA driver wasn\'t intended for\nproduction use.\n\nMark.\n\n\n\n','<532ACBFF.5010109@openstack.org>',NULL),('<1395340869-sup-2917@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 11:56:55',-25200,'2014-03-20 18:56:55',NULL,'[openstack-dev] [Marconi] Why is marconi a queue implementation\n	vs a provisioning API?','Excerpts from Flavio Percoco\'s message of 2014-03-19 03:01:19 -0700:\n> FWIW, I think there\'s a value on having an sqlalchemy driver. It\'s\n> helpful for newcomers, it integrates perfectly with the gate and I\n> don\'t want to impose other folks what they should or shouldn\'t use in\n> production. Marconi may be providing a data API but it\'s still\n> non-opinionated and it wants to support other drivers - or at least provide\n> a nice way to implement them. Working on sqlalchemy instead of amqp (or\n> redis) was decided in the incubation meeting.\n> \n> But again, It\'s an optional driver that we\'re talking about here. As\n> of now, our recommended driver is mongodb\'s and as I already mentioned\n> in this email, we\'ll start working on an amqp\'s one, which will likely\n> become the recommended one. There\'s also support for redis.\n> \n> As already mentioned, we have plans to complete the redis driver and\n> write an amqp based one and let them both live in the code base.\n> Having support for different storage dirvers makes marconi\'s sharding\n> feature more valuable.\n> \n> \n\nJust to steer this back to technical development discussions a bit:\n\nI suggest the sqla driver be removed. It will never be useful as a queue\nbackend. It will confuse newcomers because they\'ll see the schema and\nthink that it will work and then use it, and then they find out that SQL\nis just not suitable for queueing about the time that they\'re taking a\nfire extinguisher to their rack.\n\n\"Just use Redis\" is pretty interesting as a counter to the concerns\nMongoDB\'s license situation. Redis, AFAIK, does not have many of the\nfeatures that make MongoDB attractive for backing a queue. The primary\none that I would cite is sharding. While MongoDB will manage sharding\nfor you, Redis works more like Memcached when you want to partition[1].\nThis is particularly problematic for an operational _storage_ product\nas that means if you want to offline a node, you are going to have to\nconsider what kind of partitioning Marconi has used, and how it will\naffect the availability and durability of the data.\n\nAll of this to say, if Marconi is going to be high scale, I agree that\nSQL can\'t be used, and even that MongoDB, on technical abilities alone,\nmakes some sense. But I think what might be simpler is if Marconi just\nshifted focus to make the API more like AMQP, and used AMQP on its\nbackend. This allows cloud operators to deploy what they\'re used to for\nOpenStack, and would still give users something they\'re comfortable with\n(an HTTP API) to consume it.\n\n[1] http://redis.io/topics/partitioning\n\n\n','<20140319100119.GE2305@redhat.com>',NULL),('<1395343095.22198.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 15:18:15',-14400,'2014-03-20 19:18:15',NULL,'[openstack-dev] [nova][PCI] one use case make the\n flavor/extra-info based solution to be right choice','On Thu, 2014-03-20 at 13:50 +0000, Robert Li (baoli) wrote:\n> Hi Yongli,\n> \n> I\'m very glad that you bring this up and relive our discussion on PCI\n> passthrough and its application on networking. The use case you brought up\n> is:\n> \n>            user wants a FASTER NIC from INTEL to join a virtual\n> networking. \n> \n> By FASTER, I guess that you mean that the user is allowed to select a\n> particular vNIC card. Therefore, the above statement can be translated\n> into the following requests for a PCI device:\n>         . Intel vNIC\n>         . 1G or 10G or ?\n>         . network to join\n> \n> First of all, I\'m not sure in a cloud environment, a user would care about\n> the vendor or card type.\n\nCorrect. Nor would/should a user of the cloud know what vendor or card\ntype is in use on a particular compute node. At most, all a user of the\ncloud would be able to select from is an instance type (flavor) that\nlisted some capability like \"high_io_networking\" or something like that,\nand the mapping of what \"high_io_networking\" meant on the back end of\nNova would need to be done by the operator (i.e. if the tag\n\"high_io_networking\" is on a flavor a user has asked to launch a server\nwith, then that tag should be translated into a set of capabilities that\nis passed to the scheduler and used to determine where the instance can\nbe scheduled by looking at which compute nodes support that set of\ncapabilities.\n\nThis is what I\'ve been babbling about with regards to \"leaking\nimplementation through the API\". What happens if, say, the operator\ndecides to use IBM cards (instead of or in addition to Intel ones)? If\nyou couple the implementation with the API, like the example above shows\n(\"user wants a FASTER NIC from INTEL\"), then you have to add more\ncomplexity to the front-end API that a user deals with, instead of just\nadding a capabilities mapping for new compute nodes that says\n\"high_io_networking\" tag can match to these new compute nodes with IBM\ncards.\n\nBest,\n-jay\n\n\n\n','<CF50530C.64A94%baoli@cisco.com>',NULL),('<1395343206.22198.8.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 15:20:06',-14400,'2014-03-20 19:20:06',NULL,'[openstack-dev] [qa] API schema location','On Thu, 2014-03-20 at 19:34 +1100, Christopher Yeoh wrote:\n> On Tue, 18 Mar 2014 19:52:27 +0100\n> \"Koderer, Marc\" <m.koderer at telekom.de> wrote:\n> \n> > > Am I missing something or are these schemas being added now just a\n> > > subset of what is being used for negative testing? Why can\'t we\n> > > either add the extra negative test info around the new test\n> > > validation patches and get the double benefit. Or have the negative\n> > > test schemas just extend these new schemas being added?\n> > \n> > Yes, the api_schema files should theoretically be a\n> > subsets of the negative test schemas.\n> > But I don\'t think that extending them will be possible:\n> > \n> > if you have a property definition like this:\n> > \n> >         \"properties\": {\n> >             \"minRam\": {  \"type\": \"integer\",}\n> > \n> > how can you extend it to:\n> > \n> >         \"properties\": {\n> >             \"minRam\": {\n> >                 \"type\": \"integer\",\n> >                 \"results\": {\n> >                     \"gen_none\": 400,\n> >                     \"gen_string\": 400\n> >                 }\n> > \n> > This is the reason why I am unsure how inheritance can solve\n> > something here.\n> \n> I think this is an example of how we can do some sharing of schema\n> definitions when there is sufficient commonality to justify it.\n\nJSON-Schema, for the record, actually does support extending the\ndefinition of the schema using the additionalProperties attribute on a\nschema object.\n\nBest,\n-jay\n\n\n\n','<20140320193438.053fd236@pingu>',NULL),('<1395350746-sup-9612@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-20 14:33:10',-25200,'2014-03-20 21:33:10',NULL,'[Openstack] Using OpenStack in a CI/CD runway','Excerpts from Daniel Ellison\'s message of 2014-03-20 12:10:52 -0700:\n> Hi all,\n> \n> I\'ve tried to look this up online but all I seem to get is information about continuous integration/distribution in the OpenStack project itself and not much of anything concerning using OpenStack as part of a CI/CD runway to production.\n> \n> Maybe the answers are obvious to those already involved in these things. Please forgive the ignorance that is surely about to ensue.\n> \n> One point I\'m stuck on (and several online resources mention this only in passing) is how to build a new image on the fly based on an existing image, adding a new version of code from the repository. There seems to be many ways to do this and for someone coming at this as a newbie it\'s very hard to figure out a good path. Is there a tool that can produce a new image from an existing one plus some extra stuff? And if so, can it be automated?\n> \n\nIn the TripleO project, we use this tool to automate building custom\nimages:\n\nhttps://git.openstack.org/cgit/openstack/diskimage-builder/tree/README.md\n\nIt downloads or bootstraps an existing image (Ubuntu, Fedora, RHEL,\nOpenSUSE, Debian), extracts it and chroots into the image, runs your\n\"elements\", and then saves the result as raw or qcow2.\n\n> Concerning the runway itself, do people use Jenkins (or its equivalent) to orchestrate the whole thing? Or can Heat handle it all on its own? Or maybe Puppet (or its equivalent) can do it all.\n>\n\nHeat would not be able to handle it, no. Jenkins is a fine choice, as you\ncan drive your image build/test based on commits to multiple git repos.\n\nPay close attention to the \'source-repositories\' element in\ndiskimage-builder, as you would likely use it to pull the specific\ncommit jenkins wants to test and then build an image for that.\n\n> As you can see, I\'m casting about for answers. I apologize if these questions are naive. This is an important project in my company; it will determine whether we go ahead with OpenStack or scrap it completely. I need to find a solution that incorporates OpenStack into a continuous integration/distribution system.\n>\n\nOne thing, I would suggest this cycle:\n\n* Commit to repo\n* Pull commit into new image\n* Run tests on new image\n* Deploy image\n\nThat last step is tricky.. you can do it various ways, either by nova\nrebuilding servers (involves downtime), or spinning up new ones. It kind\nof depends on how your application is made available.\n\n\n','<A0898DFB-4AC8-4F86-8A4C-3958C21F0102@syrinx.net>',NULL),('<1395353737.22198.17.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 18:15:37',-14400,'2014-03-20 22:15:37',NULL,'[openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer\n tempest testing in gate','On Fri, 2014-03-21 at 00:03 +0200, Alexei Kornienko wrote:\n> Hello,\n> \n> We\'ve done some profiling and results are quite interesting:\n> during 1,5 hour ceilometer inserted 59755 events (59755 calls to\n> record_metering_data)\n> this calls resulted in total 2591573 SQL queries.\n\nYes, this matches my own experience with Ceilo+MySQL. But do not assume\nthat there are 2591573/59755 or around 43 queries per record meter\nevent. That is misleading. In fact, the number of queries per record\nmeter event increases over time, as the number of retries climbs due to\ncontention between readers and writers.\n\n> And the most interesting part is that 291569 queries were ROLLBACK\n> queries.\n\nYep, I noted that as well. But, this is not unique to Ceilometer by any\nmeans. Just take a look at any database serving Nova, Cinder, Glance, or\nanything that uses the common SQLAlchemy code. You will see a huge\npercentage of entire number of queries taken up by ROLLBACK statements.\nThe problem in Ceilometer is just that the write:read ratio is much\nhigher than any of the other projects.\n\nI had a suspicion that the rollbacks have to do with the way that the\noslo.db retry logic works, but I never had a chance to investigate it\nfurther. Would be really interested to see similar stats against\nPostgreSQL and see if the rollback issue is isolated to MySQL (I suspect\nit is).\n\nBest,\n-jay\n\n> We do around 5 rollbacks to record a single event!\n> \n> I guess it means that MySQL backend is currently totally unusable in\n> production environment.\n> \n> Please find a full profiling graph attached.\n> \n> Regards,\n> \n> On 03/20/2014 10:31 PM, Sean Dague wrote:\n> \n> > On 03/20/2014 01:01 PM, David Kranz wrote:\n> > > On 03/20/2014 12:31 PM, Sean Dague wrote:\n> > > > On 03/20/2014 11:35 AM, David Kranz wrote:\n> > > > > On 03/20/2014 06:15 AM, Sean Dague wrote:\n> > > > > > On 03/20/2014 05:49 AM, Nadya Privalova wrote:\n> > > > > > > Hi all,\n> > > > > > > First of all, thanks for your suggestions!\n> > > > > > > \n> > > > > > > To summarize the discussions here:\n> > > > > > > 1. We are not going to install Mongo (because \"is\'s wrong\" ?)\n> > > > > > We are not going to install Mongo \"not from base distribution\", because\n> > > > > > we don\'t do that for things that aren\'t python. Our assumption is\n> > > > > > dependent services come from the base OS.\n> > > > > > \n> > > > > > That being said, being an integrated project means you have to be able\n> > > > > > to function, sanely, on an sqla backend, as that will always be part of\n> > > > > > your gate.\n> > > > > This is a claim I think needs a bit more scrutiny if by \"sanely\" you\n> > > > > mean \"performant\". It seems we have an integrated project that no one\n> > > > > would deploy using the sql db driver we have in the gate. Is any one\n> > > > > doing that?  Is having a scalable sql back end a goal of ceilometer?\n> > > > > \n> > > > > More generally, if there is functionality that is of great importance to\n> > > > > any cloud deployment (and we would not integrate it if we didn\'t think\n> > > > > it was) that cannot be deployed at scale using sqla, are we really going\n> > > > > to say it should not be a part of OpenStack because we refuse, for\n> > > > > whatever reason, to run it in our gate using a driver that would\n> > > > > actually be used? And if we do demand an sqla backend, how much time\n> > > > > should we spend trying to optimize it if no one will really use it?\n> > > > > Though the slow heat job is a little different because the slowness\n> > > > > comes directly from running real use cases, perhaps we should just set\n> > > > > up a \"slow ceilometer\" job if the sql version is too slow for its budget\n> > > > > in the main job.\n> > > > > \n> > > > > It seems like there is a similar thread, at least in part, about this\n> > > > > around marconi.\n> > > > We required a non mongo backend to graduate ceilometer. So I don\'t think\n> > > > it\'s too much to ask that it actually works.\n> > > > \n> > > > If the answer is that it will never work and it was a checkbox with no\n> > > > intent to make it work, then it should be deprecated and removed from\n> > > > the tree in Juno, with a big WARNING that you shouldn\'t ever use that\n> > > > backend. Like Nova now does with all the virt drivers that aren\'t tested\n> > > > upstream.\n> > > > \n> > > > Shipping in tree code that you don\'t want people to use is bad for\n> > > > users. Either commit to making it work, or deprecate it and remove it.\n> > > > \n> > > > I don\'t see this as the same issue as the slow heat job. Heat,\n> > > > architecturally, is going to be slow. It spins up real OSes and does\n> > > > real thinks to them. There is no way that\'s ever going to be fast, and\n> > > > the dedicated job was a recognition that to support this level of\n> > > > services in OpenStack we need to give them more breathing room.\n> > > Peace. I specifically noted that difference in my original comment. And\n> > > for that reason the heat slow job may not be temporary.\n> > > > Architecturally Ceilometer should not be this expensive. We\'ve got some\n> > > > data showing it to be aberrant from where we believe it should be. We\n> > > > should fix that.\n> > > There are plenty of cases where we have had code that passes gate tests\n> > > with acceptable performance but falls over in real deployment. I\'m just\n> > > saying that having a driver that works ok in the gate but does not work\n> > > for real deployments is of no more value that not having it at all.\n> > > Maybe less value.\n> > > How do you propose to solve the problem of getting more ceilometer tests\n> > > into the gate in the short-run? As a practical measure l don\'t see why\n> > > it is so bad to have a separate job until the complex issue of whether\n> > > it is possible to have a real-world performant sqla backend is resolved.\n> > > Or did I miss something and it has already been determined that sqla\n> > > could be used for large-scale deployments if we just fixed our code?\n> > I think right now the ball is back in the ceilometer court to do some\n> > performance profiling, and lets see what comes of that. I don\'t think\n> > we\'re getting more test before the release in any real way.\n> > \n> > > > Once we get a base OS in the gate that lets us direct install mongo from\n> > > > base packages, we can also do that. Or someone can 3rd party it today.\n> > > > Then we\'ll even have comparative results to understand the differences.\n> > > Yes. Do you know which base OS\'s are candidates for that?\n> > Ubuntu 14.04 will have a sufficient level of Mongo, so some time in the\n> > Juno cycle we should have it in the gate.\n> > \n> > 	-Sean\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<532B65A7.40808@gmail.com>',NULL),('<1395356035.22198.21.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 18:53:55',-14400,'2014-03-20 22:53:55',NULL,'[openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer\n tempest testing in gate','On Fri, 2014-03-21 at 00:32 +0200, Alexei Kornienko wrote:\n> On 03/21/2014 12:15 AM, Jay Pipes wrote:\n> > On Fri, 2014-03-21 at 00:03 +0200, Alexei Kornienko wrote:\n> >> Hello,\n> >>\n> >> We\'ve done some profiling and results are quite interesting:\n> >> during 1,5 hour ceilometer inserted 59755 events (59755 calls to\n> >> record_metering_data)\n> >> this calls resulted in total 2591573 SQL queries.\n> > Yes, this matches my own experience with Ceilo+MySQL. But do not assume\n> > that there are 2591573/59755 or around 43 queries per record meter\n> > event. That is misleading. In fact, the number of queries per record\n> > meter event increases over time, as the number of retries climbs due to\n> > contention between readers and writers.\n> >\n> >> And the most interesting part is that 291569 queries were ROLLBACK\n> >> queries.\n> > Yep, I noted that as well. But, this is not unique to Ceilometer by any\n> > means. Just take a look at any database serving Nova, Cinder, Glance, or\n> > anything that uses the common SQLAlchemy code. You will see a huge\n> > percentage of entire number of queries taken up by ROLLBACK statements.\n> > The problem in Ceilometer is just that the write:read ratio is much\n> > higher than any of the other projects.\n> >\n> > I had a suspicion that the rollbacks have to do with the way that the\n> > oslo.db retry logic works, but I never had a chance to investigate it\n> > further. Would be really interested to see similar stats against\n> > PostgreSQL and see if the rollback issue is isolated to MySQL (I suspect\n> > it is).\n> Rollbacks are caused not by retry logic but by create_or_update logic:\n> We first try to do INSERT in sub-transaction when it fails we rollback \n> this transaction and do update instead.\n\nNo, that isn\'t correct, AFAIK. We first do a SELECT into the table and\nthen if no result, try an insert:\n\nhttps://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L286-L292\n\nThe problem, IMO, is twofold. There does not need to be nested\ntransactional containers around these create_or_update lookups -- i.e.\nthe lookups can be done outside of the main transaction begin here:\n\nhttps://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L335\n\nSecondly, given the volume of inserts (that also generate selects), a\nsimple memcache lookup cache would be highly beneficial in cutting down\non writer/reader contention in MySQL.\n\nThese are things that can be done without changing the schema (which has\nother issues that can be looked at of course).\n\nBest,\n-jay\n\n> This is caused by poorly designed schema that requires such hacks.\n> Cause of this I suspect that we\'ll have similar results for PostgreSQL.\n> \n> Tomorrow we\'ll do the same tests with PostgreSQL and MongoDB to see if \n> there is any difference.\n> \n> >\n> > Best,\n> > -jay\n> >\n> >> We do around 5 rollbacks to record a single event!\n> >>\n> >> I guess it means that MySQL backend is currently totally unusable in\n> >> production environment.\n> >>\n> >> Please find a full profiling graph attached.\n> >>\n> >> Regards,\n> >>\n> >> On 03/20/2014 10:31 PM, Sean Dague wrote:\n> >>\n> >>> On 03/20/2014 01:01 PM, David Kranz wrote:\n> >>>> On 03/20/2014 12:31 PM, Sean Dague wrote:\n> >>>>> On 03/20/2014 11:35 AM, David Kranz wrote:\n> >>>>>> On 03/20/2014 06:15 AM, Sean Dague wrote:\n> >>>>>>> On 03/20/2014 05:49 AM, Nadya Privalova wrote:\n> >>>>>>>> Hi all,\n> >>>>>>>> First of all, thanks for your suggestions!\n> >>>>>>>>\n> >>>>>>>> To summarize the discussions here:\n> >>>>>>>> 1. We are not going to install Mongo (because \"is\'s wrong\" ?)\n> >>>>>>> We are not going to install Mongo \"not from base distribution\", because\n> >>>>>>> we don\'t do that for things that aren\'t python. Our assumption is\n> >>>>>>> dependent services come from the base OS.\n> >>>>>>>\n> >>>>>>> That being said, being an integrated project means you have to be able\n> >>>>>>> to function, sanely, on an sqla backend, as that will always be part of\n> >>>>>>> your gate.\n> >>>>>> This is a claim I think needs a bit more scrutiny if by \"sanely\" you\n> >>>>>> mean \"performant\". It seems we have an integrated project that no one\n> >>>>>> would deploy using the sql db driver we have in the gate. Is any one\n> >>>>>> doing that?  Is having a scalable sql back end a goal of ceilometer?\n> >>>>>>\n> >>>>>> More generally, if there is functionality that is of great importance to\n> >>>>>> any cloud deployment (and we would not integrate it if we didn\'t think\n> >>>>>> it was) that cannot be deployed at scale using sqla, are we really going\n> >>>>>> to say it should not be a part of OpenStack because we refuse, for\n> >>>>>> whatever reason, to run it in our gate using a driver that would\n> >>>>>> actually be used? And if we do demand an sqla backend, how much time\n> >>>>>> should we spend trying to optimize it if no one will really use it?\n> >>>>>> Though the slow heat job is a little different because the slowness\n> >>>>>> comes directly from running real use cases, perhaps we should just set\n> >>>>>> up a \"slow ceilometer\" job if the sql version is too slow for its budget\n> >>>>>> in the main job.\n> >>>>>>\n> >>>>>> It seems like there is a similar thread, at least in part, about this\n> >>>>>> around marconi.\n> >>>>> We required a non mongo backend to graduate ceilometer. So I don\'t think\n> >>>>> it\'s too much to ask that it actually works.\n> >>>>>\n> >>>>> If the answer is that it will never work and it was a checkbox with no\n> >>>>> intent to make it work, then it should be deprecated and removed from\n> >>>>> the tree in Juno, with a big WARNING that you shouldn\'t ever use that\n> >>>>> backend. Like Nova now does with all the virt drivers that aren\'t tested\n> >>>>> upstream.\n> >>>>>\n> >>>>> Shipping in tree code that you don\'t want people to use is bad for\n> >>>>> users. Either commit to making it work, or deprecate it and remove it.\n> >>>>>\n> >>>>> I don\'t see this as the same issue as the slow heat job. Heat,\n> >>>>> architecturally, is going to be slow. It spins up real OSes and does\n> >>>>> real thinks to them. There is no way that\'s ever going to be fast, and\n> >>>>> the dedicated job was a recognition that to support this level of\n> >>>>> services in OpenStack we need to give them more breathing room.\n> >>>> Peace. I specifically noted that difference in my original comment. And\n> >>>> for that reason the heat slow job may not be temporary.\n> >>>>> Architecturally Ceilometer should not be this expensive. We\'ve got some\n> >>>>> data showing it to be aberrant from where we believe it should be. We\n> >>>>> should fix that.\n> >>>> There are plenty of cases where we have had code that passes gate tests\n> >>>> with acceptable performance but falls over in real deployment. I\'m just\n> >>>> saying that having a driver that works ok in the gate but does not work\n> >>>> for real deployments is of no more value that not having it at all.\n> >>>> Maybe less value.\n> >>>> How do you propose to solve the problem of getting more ceilometer tests\n> >>>> into the gate in the short-run? As a practical measure l don\'t see why\n> >>>> it is so bad to have a separate job until the complex issue of whether\n> >>>> it is possible to have a real-world performant sqla backend is resolved.\n> >>>> Or did I miss something and it has already been determined that sqla\n> >>>> could be used for large-scale deployments if we just fixed our code?\n> >>> I think right now the ball is back in the ceilometer court to do some\n> >>> performance profiling, and lets see what comes of that. I don\'t think\n> >>> we\'re getting more test before the release in any real way.\n> >>>\n> >>>>> Once we get a base OS in the gate that lets us direct install mongo from\n> >>>>> base packages, we can also do that. Or someone can 3rd party it today.\n> >>>>> Then we\'ll even have comparative results to understand the differences.\n> >>>> Yes. Do you know which base OS\'s are candidates for that?\n> >>> Ubuntu 14.04 will have a sufficient level of Mongo, so some time in the\n> >>> Juno cycle we should have it in the gate.\n> >>>\n> >>> 	-Sean\n> >>>\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<532B6C9A.6070606@gmail.com>',NULL),('<1395357104.22198.26.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 19:11:44',-14400,'2014-03-20 23:11:44',NULL,'[openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer\n tempest testing in gate','On Fri, 2014-03-21 at 01:02 +0200, Alexei Kornienko wrote:\n> On 03/21/2014 12:53 AM, Jay Pipes wrote:\n> > On Fri, 2014-03-21 at 00:32 +0200, Alexei Kornienko wrote:\n> >> On 03/21/2014 12:15 AM, Jay Pipes wrote:\n> >>> On Fri, 2014-03-21 at 00:03 +0200, Alexei Kornienko wrote:\n> >>>> Hello,\n> >>>>\n> >>>> We\'ve done some profiling and results are quite interesting:\n> >>>> during 1,5 hour ceilometer inserted 59755 events (59755 calls to\n> >>>> record_metering_data)\n> >>>> this calls resulted in total 2591573 SQL queries.\n> >>> Yes, this matches my own experience with Ceilo+MySQL. But do not assume\n> >>> that there are 2591573/59755 or around 43 queries per record meter\n> >>> event. That is misleading. In fact, the number of queries per record\n> >>> meter event increases over time, as the number of retries climbs due to\n> >>> contention between readers and writers.\n> >>>\n> >>>> And the most interesting part is that 291569 queries were ROLLBACK\n> >>>> queries.\n> >>> Yep, I noted that as well. But, this is not unique to Ceilometer by any\n> >>> means. Just take a look at any database serving Nova, Cinder, Glance, or\n> >>> anything that uses the common SQLAlchemy code. You will see a huge\n> >>> percentage of entire number of queries taken up by ROLLBACK statements.\n> >>> The problem in Ceilometer is just that the write:read ratio is much\n> >>> higher than any of the other projects.\n> >>>\n> >>> I had a suspicion that the rollbacks have to do with the way that the\n> >>> oslo.db retry logic works, but I never had a chance to investigate it\n> >>> further. Would be really interested to see similar stats against\n> >>> PostgreSQL and see if the rollback issue is isolated to MySQL (I suspect\n> >>> it is).\n> >> Rollbacks are caused not by retry logic but by create_or_update logic:\n> >> We first try to do INSERT in sub-transaction when it fails we rollback\n> >> this transaction and do update instead.\n> > No, that isn\'t correct, AFAIK. We first do a SELECT into the table and\n> > then if no result, try an insert:\n> >\n> > https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L286-L292\n> >\n> > The problem, IMO, is twofold. There does not need to be nested\n> > transactional containers around these create_or_update lookups -- i.e.\n> > the lookups can be done outside of the main transaction begin here:\n> >\n> > https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/impl_sqlalchemy.py#L335\n> I\'m afraid you are wrong here:\n> \n> nested  =  session.connection().dialect.name  !=  \'sqlite\' # always True for MySQL\n> if  not  nested  and  session.query(model_class).get(str(_id)): # always False\n> \n> Short circuit is used and no select is ever performed in MySQL.\n\nDoh, true enough! /me wonders why this is written like so (only for\nsqlite...?)\n\n> > Secondly, given the volume of inserts (that also generate selects), a\n> > simple memcache lookup cache would be highly beneficial in cutting down\n> > on writer/reader contention in MySQL.\n> You are right but I\'m afraid that adding memcache will make deployment \n> more complicated.\n> >\n> > These are things that can be done without changing the schema (which has\n> > other issues that can be looked at of course).\n> >\n> > Best,\n> > -jay\n> >\n> >> This is caused by poorly designed schema that requires such hacks.\n> >> Cause of this I suspect that we\'ll have similar results for PostgreSQL.\n> >>\n> >> Tomorrow we\'ll do the same tests with PostgreSQL and MongoDB to see if\n> >> there is any difference.\n> >>\n> >>> Best,\n> >>> -jay\n> >>>\n> >>>> We do around 5 rollbacks to record a single event!\n> >>>>\n> >>>> I guess it means that MySQL backend is currently totally unusable in\n> >>>> production environment.\n> >>>>\n> >>>> Please find a full profiling graph attached.\n> >>>>\n> >>>> Regards,\n> >>>>\n> >>>> On 03/20/2014 10:31 PM, Sean Dague wrote:\n> >>>>\n> >>>>> On 03/20/2014 01:01 PM, David Kranz wrote:\n> >>>>>> On 03/20/2014 12:31 PM, Sean Dague wrote:\n> >>>>>>> On 03/20/2014 11:35 AM, David Kranz wrote:\n> >>>>>>>> On 03/20/2014 06:15 AM, Sean Dague wrote:\n> >>>>>>>>> On 03/20/2014 05:49 AM, Nadya Privalova wrote:\n> >>>>>>>>>> Hi all,\n> >>>>>>>>>> First of all, thanks for your suggestions!\n> >>>>>>>>>>\n> >>>>>>>>>> To summarize the discussions here:\n> >>>>>>>>>> 1. We are not going to install Mongo (because \"is\'s wrong\" ?)\n> >>>>>>>>> We are not going to install Mongo \"not from base distribution\", because\n> >>>>>>>>> we don\'t do that for things that aren\'t python. Our assumption is\n> >>>>>>>>> dependent services come from the base OS.\n> >>>>>>>>>\n> >>>>>>>>> That being said, being an integrated project means you have to be able\n> >>>>>>>>> to function, sanely, on an sqla backend, as that will always be part of\n> >>>>>>>>> your gate.\n> >>>>>>>> This is a claim I think needs a bit more scrutiny if by \"sanely\" you\n> >>>>>>>> mean \"performant\". It seems we have an integrated project that no one\n> >>>>>>>> would deploy using the sql db driver we have in the gate. Is any one\n> >>>>>>>> doing that?  Is having a scalable sql back end a goal of ceilometer?\n> >>>>>>>>\n> >>>>>>>> More generally, if there is functionality that is of great importance to\n> >>>>>>>> any cloud deployment (and we would not integrate it if we didn\'t think\n> >>>>>>>> it was) that cannot be deployed at scale using sqla, are we really going\n> >>>>>>>> to say it should not be a part of OpenStack because we refuse, for\n> >>>>>>>> whatever reason, to run it in our gate using a driver that would\n> >>>>>>>> actually be used? And if we do demand an sqla backend, how much time\n> >>>>>>>> should we spend trying to optimize it if no one will really use it?\n> >>>>>>>> Though the slow heat job is a little different because the slowness\n> >>>>>>>> comes directly from running real use cases, perhaps we should just set\n> >>>>>>>> up a \"slow ceilometer\" job if the sql version is too slow for its budget\n> >>>>>>>> in the main job.\n> >>>>>>>>\n> >>>>>>>> It seems like there is a similar thread, at least in part, about this\n> >>>>>>>> around marconi.\n> >>>>>>> We required a non mongo backend to graduate ceilometer. So I don\'t think\n> >>>>>>> it\'s too much to ask that it actually works.\n> >>>>>>>\n> >>>>>>> If the answer is that it will never work and it was a checkbox with no\n> >>>>>>> intent to make it work, then it should be deprecated and removed from\n> >>>>>>> the tree in Juno, with a big WARNING that you shouldn\'t ever use that\n> >>>>>>> backend. Like Nova now does with all the virt drivers that aren\'t tested\n> >>>>>>> upstream.\n> >>>>>>>\n> >>>>>>> Shipping in tree code that you don\'t want people to use is bad for\n> >>>>>>> users. Either commit to making it work, or deprecate it and remove it.\n> >>>>>>>\n> >>>>>>> I don\'t see this as the same issue as the slow heat job. Heat,\n> >>>>>>> architecturally, is going to be slow. It spins up real OSes and does\n> >>>>>>> real thinks to them. There is no way that\'s ever going to be fast, and\n> >>>>>>> the dedicated job was a recognition that to support this level of\n> >>>>>>> services in OpenStack we need to give them more breathing room.\n> >>>>>> Peace. I specifically noted that difference in my original comment. And\n> >>>>>> for that reason the heat slow job may not be temporary.\n> >>>>>>> Architecturally Ceilometer should not be this expensive. We\'ve got some\n> >>>>>>> data showing it to be aberrant from where we believe it should be. We\n> >>>>>>> should fix that.\n> >>>>>> There are plenty of cases where we have had code that passes gate tests\n> >>>>>> with acceptable performance but falls over in real deployment. I\'m just\n> >>>>>> saying that having a driver that works ok in the gate but does not work\n> >>>>>> for real deployments is of no more value that not having it at all.\n> >>>>>> Maybe less value.\n> >>>>>> How do you propose to solve the problem of getting more ceilometer tests\n> >>>>>> into the gate in the short-run? As a practical measure l don\'t see why\n> >>>>>> it is so bad to have a separate job until the complex issue of whether\n> >>>>>> it is possible to have a real-world performant sqla backend is resolved.\n> >>>>>> Or did I miss something and it has already been determined that sqla\n> >>>>>> could be used for large-scale deployments if we just fixed our code?\n> >>>>> I think right now the ball is back in the ceilometer court to do some\n> >>>>> performance profiling, and lets see what comes of that. I don\'t think\n> >>>>> we\'re getting more test before the release in any real way.\n> >>>>>\n> >>>>>>> Once we get a base OS in the gate that lets us direct install mongo from\n> >>>>>>> base packages, we can also do that. Or someone can 3rd party it today.\n> >>>>>>> Then we\'ll even have comparative results to understand the differences.\n> >>>>>> Yes. Do you know which base OS\'s are candidates for that?\n> >>>>> Ubuntu 14.04 will have a sufficient level of Mongo, so some time in the\n> >>>>> Juno cycle we should have it in the gate.\n> >>>>>\n> >>>>> 	-Sean\n> >>>>>\n> >>>>>\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<532B738D.6020702@gmail.com>',NULL),('<1395357517.22198.28.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 19:18:37',-14400,'2014-03-20 23:18:37',NULL,'[openstack-dev] [Marconi][TC] Withdraw graduation request','This is a very mature stance and well-written email. Thanks, Flavio and\nall of the Marconi team for having thick skin and responding to the\nvarious issues professionally.\n\nCheers,\n-jay\n\nOn Thu, 2014-03-20 at 23:59 +0100, Flavio Percoco wrote:\n> Greetings,\n> \n> I\'m sending this email on behalf of Marconi\'s team.\n> \n> As you already know, we submitted our graduation request a couple of\n> weeks ago and the meeting was held on Tuesday, March 18th. During the\n> meeting very important questions and issues were raised that made\n> us think and analyse our current situation and re-think about what\n> the best for OpenStack and Marconi would be in this very moment.\n> \n> After some considerations, we\'ve reached the conclusion that this is\n> probably not the right time for this project to graduate and that\n> it\'ll be fruitful for the project and the OpenStack community if we\n> take another development cycle before coming out from incubation. Here\n> are some things we took under consideration:\n> \n> 1. It\'s still not clear to the overall community what the goals of\n> the project are. It is not fair for Marconi as a project nor for\n> OpenStack as a community to move forward with this integration when\n> there are still open questions about the project goals.\n> \n> 2. Some critical issues came out of our attempt to have a gate job.\n> For the team, the project and the community this is a very critical\n> point. We\'ve managed to have the gate working but we\'re still not\n> happy with the results.\n> \n> 3. The drivers currently supported by the project don\'t cover some\n> important cases related to deploying it. One of them solves a\n> licensing issue but introduces a scale issue whereas the other one\n> solves the scale issue and introduces a licensing issue. Moreover,\n> these drivers have created quite a confusion with regards to what the\n> project goal\'s are too.\n> \n> 4. We\'ve seen the value - and believe in it - of OpenStack\'s\n> incubation period. During this period, the project has gained\n> maturity in its API, supported drivers and integration with the\n> overall community.\n> \n> 5. Several important questions were brought up in the recent ML\n> discussions. These questions take time, effort but also represent a\n> key point in the support, development and integration of the project\n> with the rest of OpenStack. We\'d like to dedicate to this questions\n> the time they deserve.\n> \n> 6. There are still some open questions in the OpenStack community\n> related to the graduation requirements and the required supported\n> technologies of integrated projects.\n> \n> Based on the aforementioned points, the team would like to withdraw\n> the graduation request and remain an incubated project for one\n> more development cycle.\n> \n> During the upcoming months, the team will focus on solving the issues\n> that arose as part of last Tuesday\'s meeting. If possible, we would\n> like to request a meeting where we can discuss with the TC - and\n> whoever wants to participate - a set of *most pressing issues* that\n> should be solved before requesting another graduation meeting. The\n> team will be focused on solving those issues and other issues down\n> that road.\n> \n> Although the team believes in the project\'s technical maturity, we think\n> this is what is best for OpenStack and the project itself\n> community-wise. The open questions are way too important for the team\n> and the community and they shouldn\'t be ignored nor rushed.\n> \n> I\'d also like to thank the team and the overall community. The team\n> for its hard work during the last cycle and the community for being there\n> and providing such important feedback in this process. We look forward\n> to see Marconi graduating from incubation.\n> \n> Bests,\n> Marconi\'s team.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140320225938.GB25109@redhat.com>',NULL),('<1395358134-sup-4792@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 16:30:14',-25200,'2014-03-20 23:30:14',NULL,'[openstack-dev] [Marconi][TC] Withdraw graduation request','Jay said it all. I look forward to Marconi\'s graduation day and I see\ngood things. :)\n\nExcerpts from Jay Pipes\'s message of 2014-03-20 16:18:37 -0700:\n> This is a very mature stance and well-written email. Thanks, Flavio and\n> all of the Marconi team for having thick skin and responding to the\n> various issues professionally.\n> \n> Cheers,\n> -jay\n> \n> On Thu, 2014-03-20 at 23:59 +0100, Flavio Percoco wrote:\n> > Greetings,\n> > \n> > I\'m sending this email on behalf of Marconi\'s team.\n> > \n> > As you already know, we submitted our graduation request a couple of\n> > weeks ago and the meeting was held on Tuesday, March 18th. During the\n> > meeting very important questions and issues were raised that made\n> > us think and analyse our current situation and re-think about what\n> > the best for OpenStack and Marconi would be in this very moment.\n> > \n> > After some considerations, we\'ve reached the conclusion that this is\n> > probably not the right time for this project to graduate and that\n> > it\'ll be fruitful for the project and the OpenStack community if we\n> > take another development cycle before coming out from incubation. Here\n> > are some things we took under consideration:\n> > \n> > 1. It\'s still not clear to the overall community what the goals of\n> > the project are. It is not fair for Marconi as a project nor for\n> > OpenStack as a community to move forward with this integration when\n> > there are still open questions about the project goals.\n> > \n> > 2. Some critical issues came out of our attempt to have a gate job.\n> > For the team, the project and the community this is a very critical\n> > point. We\'ve managed to have the gate working but we\'re still not\n> > happy with the results.\n> > \n> > 3. The drivers currently supported by the project don\'t cover some\n> > important cases related to deploying it. One of them solves a\n> > licensing issue but introduces a scale issue whereas the other one\n> > solves the scale issue and introduces a licensing issue. Moreover,\n> > these drivers have created quite a confusion with regards to what the\n> > project goal\'s are too.\n> > \n> > 4. We\'ve seen the value - and believe in it - of OpenStack\'s\n> > incubation period. During this period, the project has gained\n> > maturity in its API, supported drivers and integration with the\n> > overall community.\n> > \n> > 5. Several important questions were brought up in the recent ML\n> > discussions. These questions take time, effort but also represent a\n> > key point in the support, development and integration of the project\n> > with the rest of OpenStack. We\'d like to dedicate to this questions\n> > the time they deserve.\n> > \n> > 6. There are still some open questions in the OpenStack community\n> > related to the graduation requirements and the required supported\n> > technologies of integrated projects.\n> > \n> > Based on the aforementioned points, the team would like to withdraw\n> > the graduation request and remain an incubated project for one\n> > more development cycle.\n> > \n> > During the upcoming months, the team will focus on solving the issues\n> > that arose as part of last Tuesday\'s meeting. If possible, we would\n> > like to request a meeting where we can discuss with the TC - and\n> > whoever wants to participate - a set of *most pressing issues* that\n> > should be solved before requesting another graduation meeting. The\n> > team will be focused on solving those issues and other issues down\n> > that road.\n> > \n> > Although the team believes in the project\'s technical maturity, we think\n> > this is what is best for OpenStack and the project itself\n> > community-wise. The open questions are way too important for the team\n> > and the community and they shouldn\'t be ignored nor rushed.\n> > \n> > I\'d also like to thank the team and the overall community. The team\n> > for its hard work during the last cycle and the community for being there\n> > and providing such important feedback in this process. We look forward\n> > to see Marconi graduating from incubation.\n> > \n> > Bests,\n> > Marconi\'s team.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1395357517.22198.28.camel@cranky>',NULL),('<1395358323-sup-7828@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 17:06:37',-25200,'2014-03-21 00:06:37',NULL,'[openstack-dev] [Marconi] Why is marconi a queue implementation\n	vs a provisioning API?','Excerpts from Ozgur Akan\'s message of 2014-03-20 14:18:27 -0700:\n> Hi,\n> \n> Marconi manages its own sharding  (doesn\'t rely on mongoDB\'s own sharding)\n> in order to have more control on where data is stored. Sharding is done\n> based on project_id + queue_id and stored in a catalog. Since Marconi\n> manages it\'s own shards, it can use the same logic with any storage. If it\n> was redis, scaling wouldn\'t be any different than having mongoDB as\n> backend.\n> \n\nCool. Said catalog is duplicated globally then?\n\n> Marconi (with some work) can also offer different backends at the same time\n> to provide different performance / durability options to it\'s users. And\n> users here are not operators but actual customers/users that are using the\n> queuing service.\n>\n\nRight, sort of like with AMQP how you can ask for reliable delivery or\nnot?\n\n> MongoDB seems to be a good choice as a storage backend as it doesn\'t need\n> VRRP during failover which makes it much easier to deploy on top of\n> OpenStack compute at times when moving a VIP can\' t be done via VRRP. MySQL\n> for example would require a VIP in order to endure a failed master. monoDB\n> is relatively easier to manage (scale) when you have to migrate whole data\n> from one cluster to another.\n>\n\nUsing Galera, MySQL doesn\'t require a VIP approach either.\n\n> I don\'t think RDBM is a bad idea but might not be practical. Mysql without\n> sql interface can be fast;\n> https://blogs.oracle.com/mysqlinnodb/entry/mysql_5_7_3_deep\n> \n\nThe SQL isn\'t the only problem, and speed isn\'t the same as scalability\n(Fast: Ferrari, Scalable: Bullet Train). You also have MVCC. In InnoDB,\njust inserting, updating, and deleting millions of tiny rows in a\nconcurrent fashion will tie up threads and mutexes, and bog down InnoDB\nwith millions of tiny transactions.\n\nThe linked blog is dealing entirely with scaling excessive tiny reads,\nwhich is important, but not really the problem Marconi faces. There\'s no\npoint in discussing how to try and make MySQL or any other MVCC database\nwork well as a queue backend.\n\nIMO, Look at how QPID and RabbitMQ do durable messaging... that is\nthe model to copy. But that is why the original email was \"why isn\'t\nMarconi just provisioning brokers?\" because those brokers have already\nimplemented this and it seems wasteful to try and do it again.\n\n\n','<CAGhjxmPmYZVcuXbp-S0eWPm7USAYO8aO9CRYOvi+sBqJBugqxQ@mail.gmail.com>',NULL),('<1395448505.16070.YahooMailNeo@web163806.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-21 17:35:05',-25200,'2014-03-22 00:35:05',NULL,'[openstack-dev] [Neutron] Using Python-Neutronclient from\n	Python - docstrings needed?','Sean,\nIf you can point me to the project file in github which needs to be modified , i will include these docs\n\nThanks\nRajdeep\n\n\n\nOn Sunday, February 9, 2014 9:04 PM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n \nDo you have plans to submit these back upstream? It would be a great first start, perhaps we could add these as examples underneath the JSON request/reponse in http://api.openstack.org/api-ref-networking.html\n\n\n\nSean M. Collins\n\n\n________________________________\n \nFrom: Rajdeep Dua [dua_rajdeep at yahoo.com]\nSent: Saturday, February 08, 2014 11:10 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?\n\n\nSean,\nWe have written a few docs for writing these samples\n\nhttp://python-api-guide.cfapps.io/content/neutron.html\n\n\nYou can find get the source here?https://github.com/rajdeepd/openstack-samples\n\nThanks\nRajdeep\n\n\n\nOn Sunday, February 9, 2014 12:57 AM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n\nHi,\n\nI was writing a small script yesterday to parse a list of IP blocks and\ncreate security groups and rules, by using python-neutronclient.\n\nTo be honest, it was very difficult - even though I have actually\nwritten extensions to Python-Neutronclient for the QoS API. \n\nFor those that are trying to use the client from inside their code,\nthey end up getting zero help as to how to actually call any of the\nfunctions, and what parameters they take. \n\n\n? ? >>> neutron = client.Client(\'2.0\', auth_url=os.environ[\'OS_AUTH_URL\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? tenant_id=os.environ[\'OS_TENANT_ID\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? username=os.environ[\'OS_USERNAME\'],\n? ? ...? ? ? ? ? ? ? ? ? ? ? ? ? ? password=os.environ[\'OS_PASSWORD\'])\n? ? >>> help(neutron)\n\n? |? create_credential = <function with_params>\n? |? \n? |? create_firewall = <function with_params>\n? |? \n? |? create_firewall_policy = <function with_params>\n? |? \n? |? create_firewall_rule = <function with_params>\n? |? \n? |? create_floatingip = <function with_params>\n? |? \n? |? create_health_monitor = <function with_params>\n? |? \n? |? create_ikepolicy = <function with_params>\n? |? \n? |? create_ipsec_site_connection = <function with_params>\n? |? \n? |? create_ipsecpolicy = <function with_params>\n? |? \n? |? create_member = <function with_params>\n? |? \n? |? create_metering_label = <function with_params>\n\n\nSince there was nothing there, I decided to go check the source of\npython-neutronclient and see if there are any examples.\n\nhttps://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst\n\nIf you read closely enough, you\'ll find out that the function takes a\ndictionary, that looks very similar to the request/response examples\nlisted in the API documentation. So, I went over and checked it out.\n\nhttp://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html\n\nSo from there, I was able to remember enough that each of these\nfunctions takes a single argument, that is a dictionary, that mimics\nthe same structure that you see in the API documentation, so from there\nit was just some experimentation to get the structure right.\n\nHonestly it wasn\'t easy to remember all this stuff, since\nit had been a couple months since I had worked with\npython-neutronclient, and it had been from inside the library itself.\n\nThis was my first experience using it \"on the outside\" and it was pretty\ntough - so I\'m going to try and look into how we can improve the\ndocstrings for the client object, to make it a bit easier to figure out.\n\nThoughts?\n\n-- \nSean M. Collins\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140321/6fc203f8/attachment.html>\n\n','<7EB180D009B1A6428D376906754127CB2E0EDBD8@PACDCEXMB22.cable.comcast.com>',NULL),('<1395622414-sup-7439@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-23 17:57:22',-25200,'2014-03-24 00:57:22',NULL,'[openstack-dev] [TripleO] test environment requirements','Excerpts from Ben Nemec\'s message of 2014-03-21 09:38:00 -0700:\n> On 2014-03-21 10:57, Derek Higgins wrote:\n> > On 14/03/14 20:16, Ben Nemec wrote:\n> >> On 2014-03-13 11:12, James Slagle wrote:\n> >>> On Thu, Mar 13, 2014 at 2:51 AM, Robert Collins\n> >>> <robertc at robertcollins.net> wrote:\n> >>>> So we already have pretty high requirements - its basically a 16G\n> >>>> workstation as minimum.\n> >>>>\n> >>>> Specifically to test the full story:\n> >>>>  - a seed VM\n> >>>>  - an undercloud VM (bm deploy infra)\n> >>>>  - 1 overcloud control VM\n> >>>>  - 2 overcloud hypervisor VMs\n> >>>> ====\n> >>>>    5 VMs with 2+G RAM each.\n> >>>>\n> >>>> To test the overcloud alone against the seed we save 1 VM, to skip the\n> >>>> overcloud we save 3.\n> >>>>\n> >>>> However, as HA matures we\'re about to add 4 more VMs: we need a HA\n> >>>> control plane for both the under and overclouds:\n> >>>>  - a seed VM\n> >>>>  - 3 undercloud VMs (HA bm deploy infra)\n> >>>>  - 3 overcloud control VMs (HA)\n> >>>>  - 2 overcloud hypervisor VMs\n> >>>> ====\n> >>>>    9 VMs with 2+G RAM each == 18GB\n> >>>>\n> >>>> What should we do about this?\n> >>>>\n> >>>> A few thoughts to kick start discussion:\n> >>>>  - use Ironic to test across multiple machines (involves tunnelling\n> >>>> brbm across machines, fairly easy)\n> >>>>  - shrink the VM sizes (causes thrashing)\n> >>>>  - tell folk to toughen up and get bigger machines (ahahahahaha, no)\n> >>>>  - make the default configuration inline the hypervisors on the\n> >>>> overcloud with the control plane:\n> >>>>    - a seed VM\n> >>>>    - 3 undercloud VMs (HA bm deploy infra)\n> >>>>    - 3 overcloud all-in-one VMs (HA)\n> >>>>   ====\n> >>>>      7 VMs with 2+G RAM each == 14GB\n> >>>>\n> >>>>\n> >>>> I think its important that we exercise features like HA and live\n> >>>> migration regularly by developers, so I\'m quite keen to have a fairly\n> >>>> solid systematic answer that will let us catch things like bad\n> >>>> firewall rules on the control node preventing network tunnelling\n> >>>> etc... e.g. we benefit the more things are split out like scale\n> >>>> deployments are. OTOH testing the micro-cloud that folk may start with\n> >>>> is also a really good idea....\n> >>>\n> >>>\n> >>> The idea I was thinking was to make a testenv host available to\n> >>> tripleo atc\'s. Or, perhaps make it a bit more locked down and only\n> >>> available to a new group of tripleo folk, existing somewhere between\n> >>> the privileges of tripleo atc\'s and tripleo-cd-admins.  We could\n> >>> document how you use the cloud (Red Hat\'s or HP\'s) rack to start up a\n> >>> instance to run devtest on one of the compute hosts, request and lock\n> >>> yourself a testenv environment on one of the testenv hosts, etc.\n> >>> Basically, how our CI works. Although I think we\'d want different\n> >>> testenv hosts for development vs what runs the CI, and would need to\n> >>> make sure everything was locked down appropriately security-wise.\n> >>>\n> >>> Some other ideas:\n> >>>\n> >>> - Allow an option to get rid of the seed VM, or make it so that you\n> >>> can shut it down after the Undercloud is up. This only really gets rid\n> >>> of 1 VM though, so it doesn\'t buy you much nor solve any long term\n> >>> problem.\n> >>>\n> >>> - Make it easier to see how you\'d use virsh against any libvirt host\n> >>> you might have lying around.  We already have the setting exposed, but\n> >>> make it a bit more public and call it out more in the docs. I\'ve\n> >>> actually never tried it myself, but have been meaning to.\n> >>>\n> >>> - I\'m really reaching now, and this may be entirely unrealistic :),\n> >>> but....somehow use the fake baremetal driver and expose a mechanism to\n> >>> let the developer specify the already setup undercloud/overcloud\n> >>> environment ahead of time.\n> >>> For example:\n> >>> * Build your undercloud images with the vm element since you won\'t be\n> >>> PXE booting it\n> >>> * Upload your images to a public cloud, and boot instances for them.\n> >>> * Use this new mechanism when you run devtest (presumably running from\n> >>> another instance in the same cloud)  to say \"I\'m using the fake\n> >>> baremetal driver, and here are the  IP\'s of the undercloud instances\".\n> >>> * Repeat steps for the overcloud (e.g., configure undercloud to use\n> >>> fake baremetal driver, etc).\n> >>> * Maybe it\'s not the fake baremetal driver, and instead a new driver\n> >>> that is a noop for the pxe stuff, and the power_on implementation\n> >>> powers on the cloud instances.\n> >>> * Obviously if your aim is to test the pxe and disk deploy process\n> >>> itself, this wouldn\'t work for you.\n> >>> * Presumably said public cloud is OpenStack, so we\'ve also achieved\n> >>> another layer of \"On OpenStack\".\n> >>\n> >> I actually spent quite a while looking into something like this last\n> >> option when I first started on TripleO, because I had only one big\n> >> server locally and it was running my OpenStack installation.  I was\n> >> hoping to use it for my TripleO instances, and even went so far as to\n> >> add support for OpenStack to the virtual power driver in baremetal.  I\n> >> was never completely successful, but I did work through a number of\n> >> problems:\n> >>\n> >> 1. Neutron didn\'t like allowing the DHCP/PXE traffic to let my seed\n> >> serve to the undercloud.  I was able to get around this by using flat\n> >> networking with a local bridge on the OpenStack system, but I\'m not sure\n> >> if that\'s going to be possible on most public cloud providers.  There\n> >> may very well be a less invasive way to configure Neutron to allow that,\n> >> but I don\'t know how to do it.\n> >>\n> >> 2. Last time I checked, Nova doesn\'t support PXE booting instances so I\n> >> had to use iPXE images to do the booting.  This doesn\'t work since we\n> >> PXE boot every time an instance reboots and the iPXE image gets\n> >> overwritten by the image deploy, so the instance doesn\'t boot properly\n> >> after deployment.  This is where I stopped my investigation because I\n> >> didn\'t want to start hacking up my OpenStack installation to get around\n> >> the problem, but if we decided to go in this direction I don\'t think it\n> >> would be terribly difficult to get support for this into Nova.  I know\n> >> there have been proposed patches for it before, but I don\'t think there\n> >> was ever much push behind them because it isn\'t something most people\n> >> need to do.\n> >>\n> >> So if we can work through a couple of problems then in theory it should\n> >> be possible to use OpenStack instances for TripleO development, which\n> >> would let us do the cloudy thing and have someone else worry about the\n> >> hardware.  The idea certainly has some appeal to me.\n> > \n> > I\'m tempted to say If we could pull this off it would be great but I\'m\n> > worried it would differ too much from our target deployment method. We\n> > would be spreading ourselves too thin trying to support this for\n> > developers along with our traditional deployment method. Also if using\n> > it is adopted by too many people the only thing exercising our target\n> > deployment method would be CI. But I\'m interested in what other people\n> > think.\n> \n> To clarify my suggestion, I want to take James\'s idea a step further and\n> do the full PXE deploy to Nova instances.  So the only difference from\n> our workflow now would be that instead of configuring your VM\'s with\n> virsh, you would do it with Nova and Neutron.\n> \n\nSeems like this would be the most scalable long term plan. Would it be\nas easy as enabling PXE bios for instances and allowing users to set\nthe appropriate DHCP options for the tftp server on these ports?\n\n\n','<10eb325c19d743fcb2e966e028ea42cd@localhost>',NULL),('<1395622664-sup-4266@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-23 18:02:23',-25200,'2014-03-24 01:02:23',NULL,'[openstack-dev] [TripleO] test environment requirements','Excerpts from Dan Prince\'s message of 2014-03-21 09:25:42 -0700:\n> \n> ----- Original Message -----\n> > From: \"Robert Collins\" <robertc at robertcollins.net>\n> > To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> > Sent: Thursday, March 13, 2014 5:51:30 AM\n> > Subject: [openstack-dev] [TripleO] test environment requirements\n> > \n> > So we already have pretty high requirements - its basically a 16G\n> > workstation as minimum.\n> > \n> > Specifically to test the full story:\n> >  - a seed VM\n> >  - an undercloud VM (bm deploy infra)\n> >  - 1 overcloud control VM\n> >  - 2 overcloud hypervisor VMs\n> > ====\n> >    5 VMs with 2+G RAM each.\n> > \n> > To test the overcloud alone against the seed we save 1 VM, to skip the\n> > overcloud we save 3.\n> > \n> > However, as HA matures we\'re about to add 4 more VMs: we need a HA\n> > control plane for both the under and overclouds:\n> >  - a seed VM\n> >  - 3 undercloud VMs (HA bm deploy infra)\n> >  - 3 overcloud control VMs (HA)\n> >  - 2 overcloud hypervisor VMs\n> > ====\n> >    9 VMs with 2+G RAM each == 18GB\n> > \n> > What should we do about this?\n> > \n> > A few thoughts to kick start discussion:\n> >  - use Ironic to test across multiple machines (involves tunnelling\n> > brbm across machines, fairly easy)\n> >  - shrink the VM sizes (causes thrashing)\n> >  - tell folk to toughen up and get bigger machines (ahahahahaha, no)\n> >  - make the default configuration inline the hypervisors on the\n> > overcloud with the control plane:\n> >    - a seed VM\n> >    - 3 undercloud VMs (HA bm deploy infra)\n> >    - 3 overcloud all-in-one VMs (HA)\n> >   ====\n> >      7 VMs with 2+G RAM each == 14GB\n> > \n> > \n> > I think its important that we exercise features like HA and live\n> > migration regularly by developers, so I\'m quite keen to have a fairly\n> > solid systematic answer that will let us catch things like bad\n> > firewall rules on the control node preventing network tunnelling\n> > etc...\n> \n> I\'m all for supporting HA development and testing within devtest. I\'m *against* forcing it on all users as a default.\n> \n> I can imaging wanting to cut corners and have configurations flexible on both ends (undercloud and overcloud). I may for example deploy a single all-in-one undercloud when I\'m testing overcloud HA. Or vice versa.\n> \n> I think I\'m one of the few (if not the only) developer who uses almost exclusive baremetal (besides seed VM) when test/developing TripleO. Forcing users who want to do this to have 6-7 real machines is a bit much I think. Arguably wasteful even. By requiring more machines to run through devtest you actually make it harder for people to test it on real hardware which is usually harder to come by. Given deployment on real bare metal is sort of the point or TripleO I\'d very much like to see more developers using it rather than less.\n> \n> So by all means lets support HA... but lets do it in a way that is configurable (i.e. not forcing people to be wasters)\n> \n> Dan\n> \n\nI don\'t think anybody wants to force it on _users_. But a predominance\nof end users will require HA, and thus we need our developers to be able\nto develop with HA.\n\nThis is for the _benefit_ of developers. I imagine we\'ve all been in\nsituations where our dev environment is almost nothing like CI, and then\nwhen CI runs you find that you have missed huge problems.. and now to\ntest for those problems you either have to re-do your dev environment,\nor wait.. a lot.. for CI.\n\nI don\'t have any really clever answers to this problem. We\'re testing an\nend-to-end cloud deployment. If we can\'t run a small, accurate simulation\nof such an environment as developers, then we will end up going very slow.\nThe problem is that this small simulation is still massive compared\nto the usual development paradigm which involves at most two distinct\nvirtual machines.\n\n\n','<1467876968.4927391.1395419142607.JavaMail.zimbra@redhat.com>',NULL),('<1395622948-sup-7192@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-23 18:06:07',-25200,'2014-03-24 01:06:07',NULL,'[openstack-dev] [TripleO] test environment requirements','Excerpts from Robert Collins\'s message of 2014-03-13 02:51:30 -0700:\n> So we already have pretty high requirements - its basically a 16G\n> workstation as minimum.\n> \n> Specifically to test the full story:\n>  - a seed VM\n>  - an undercloud VM (bm deploy infra)\n>  - 1 overcloud control VM\n>  - 2 overcloud hypervisor VMs\n> ====\n>    5 VMs with 2+G RAM each.\n> \n> To test the overcloud alone against the seed we save 1 VM, to skip the\n> overcloud we save 3.\n> \n> However, as HA matures we\'re about to add 4 more VMs: we need a HA\n> control plane for both the under and overclouds:\n>  - a seed VM\n>  - 3 undercloud VMs (HA bm deploy infra)\n>  - 3 overcloud control VMs (HA)\n>  - 2 overcloud hypervisor VMs\n> ====\n>    9 VMs with 2+G RAM each == 18GB\n> \n\nIf we switch end-user-vm tests to cirros, and use a flavor that is really\nreally tiny, like 128M RAM, then I think we can downsize the development\nenvironment hypervisors from 2G to 1G. That at least drops us to 16G. If\nwe can also turn off the seed as soon as the undercloud boots, that\'s\nanother 2G saved. Finally if we can turn off 1 of the undercloud VMs\nand run degraded, that is another 2G saved.\n\nSmall potatoes I know, but it wouldn\'t be complicated to do any of these\nand it would also help test real scenarios we want to test (seed going\naway, undercloud node going away).\n\n\n','<CAJ3HoZ0YSnYviesuVXfeJi2qUH+0zj1-qDOz-Dvrp4eUXWsj9Q@mail.gmail.com>',NULL),('<1395677696-sup-8100@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-24 09:19:40',-25200,'2014-03-24 16:19:40',NULL,'[Openstack] [Heat] admin_user property implementation','Excerpts from Micha?l Van de Borne\'s message of 2014-03-24 09:00:59 -0700:\n> Hi there,\n> \n> 1. When an instance is booted from a Heat stack, the user for whom the \n> ssh public key is injected is, by default, \'ec2-user\'. Even if there is \n> a cloud-wide setting (instance_user in /etc/heat/heat.conf) that allows \n> to change this, it isn\'t a good solution, as all stack deployments will \n> then use that specific value (although various cloud images may require \n> various users). I would expect here that Heat runs its operations *on \n> behalf of the default user defined in the cloud-init configuration of \n> the instance*. I would be glad if there was a way to configure Heat that \n> way. Any idea??\n> \n\nI have to agree that we shouldn\'t be imposing a default user on people.\nI\'ve never understood why CloudFormation did that. The images do a\nfine job of selecting an appropriate username. I actually created the\nadmin_user setting because I found it a bit vulgar that Heat was putting\n\'ec2-user\' on all of the servers we were spinning up to run OpenStack\nitself. :) So we call ours \'heat-admin\' in TripleO.\n\nNote that in the fix for the bug below, it was realized that native\nHeat resources don\'t need to maintain compatibility with CloudFormation,\nso OS::Nova::Server will no longer create the \'ec2-user\' user:\n\nhttps://bugs.launchpad.net/heat/+bug/1257410\n\nAnd you will in fact be able to expect that your default configuration\nfor user will be left alone. Unfortunately that won\'t land until we\nun-freeze after the release.\n\n> 2. However, it seems there\'d be a workaround using the \"admin_user\" \n> property in the HOT file (documented here: \n> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-props). \n> Unfortunately, this parameter is not recognized by heat-api. Here\'s the \n> error:\n> \n> 2014-03-24 16:32:23.940 1128 DEBUG root [-] JSON response : \n> {\"explanation\": \"Unknown Property admin_user\", \"code\": 400, \"error\": \n> {\"message\": \"Unknown Property admin_user\", \"traceback\": \"  File \n> \\\"/usr/lib/python2.7/dist-packages/heat/common/wsgi.py\\\", line 661, in \n> __call__\\n    request, **action_args)\\n  File \n> \\\"/usr/lib/python2.7/dist-packages/heat/common/wsgi.py\\\", line 729, in \n> dispatch\\n    return method(*args, **kwargs)\\n  File \n> \\\"/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/util.py\\\", line \n> 31, in handle_stack_method\\n    return handler(controller, req, \n> **kwargs)\\n  File \n> \\\"/usr/lib/python2.7/dist-packages/heat/api/openstack/v1/stacks.py\\\", \n> line 317, in validate_template\\n    raise \n> exc.HTTPBadRequest(result[\'Error\'])\\n\", \"type\": \"HTTPBadRequest\"}, \n> \"title\": \"Bad Request\"} to_json \n> /usr/lib/python2.7/dist-packages/heat/common/wsgi.py:562\n> \n> \n> I\'m running OpenStack Havana on Ubuntu 12.04.\n> \n> root at penny:/var/log/heat# dpkg -l heat-api\n> ||/ Name Version                                               Description\n> +++-=====================================================-=======================\n> ii  heat-api 2013.2.2-0ubuntu1~cloud0                              \n> OpenStack orchestration service - ReST API\n> \n> \n> \n> any help appreciated. thank you.\n\nYou could also just configure your images to set up whatever user you\nwant and ignore Heat\'s suggestion.\n\n\n','<533056BB.2060906@cetic.be>',NULL),('<1395702802.86414.YahooMailNeo@web163601.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-24 16:13:22',-25200,'2014-03-24 23:13:22',NULL,'[openstack-dev] ML2 Type driver for supporting network overlays,\n	with more than 4K seg','Hello,\nI have a topology where my Openstack compute nodes are connected to the external switches. The fabric comprising of the switches support more than 4K segments. So, i should be able to create more than 4K networks in Openstack. But, the VLAN to be used for communication with the switches is assigned by the switches using 802.1QBG (VDP) protocol. This can be thought of as a network overlay. The VM\'s sends .1q frames to the switches and the switches associate it to the segment (VNI in case of VXLAN).\nMy question is:\n1. I cannot use a type driver of VLAN because of the 4K limitation. I cannot use a type driver of VXLAN or GRE because that may mean host based overlay. Is there an integrated type driver i can use like an \"external network\" for achieving the above?\n2. The Openstack module running in the compute should communicate with VDP module (lldpad) running there.\n\nIn the computes, i see that ovs_neutron_agent.py is the one programming the flows. Here, for the new type driver, should i add a special case to provision_local_vlan() for communicating with lldpad for retrieving the provider VLAN? If there was a type driver component running in each computes, i would have added another one for my purpose. Since, the ML2 architecture has its mechanism/type driver modules in the controller only, i can only make changes here.\n\nPlease let me know if there\'s already an implementation for my above requirements. If not, should i create a blue-print? \n\nThanks,\nPaddu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140324/fc4a231d/attachment.html>\n\n',NULL,NULL),('<1395743315.2374.6.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 06:28:35',-14400,'2014-03-25 10:28:35',NULL,'[openstack-dev] Multiple patches in one review','On Mon, 2014-03-24 at 10:49 -0400, Russell Bryant wrote:\n> Gerrit support for a patch series could certainly be better.\n\nThere has long been talking about gerrit getting \"topic review\"\nfunctionality, whereby you could e.g. approve a whole series of patches\nfrom a \"topic view\".\n\nSee:\n\n  https://code.google.com/p/gerrit/issues/detail?id=51\n  https://groups.google.com/d/msg/repo-discuss/5oRra_tLKMA/rxwU7pPAQE8J\n\nMy understanding is there\'s a fork of gerrit out there with this\nfunctionality that some projects are using successfully.\n\nMark.\n\n\n\n\n','<533045EA.9070602@redhat.com>',NULL),('<1395743779.2374.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 06:36:19',-14400,'2014-03-25 10:36:19',NULL,'[openstack-dev] OpenStack vs. SQLA 0.9','FYI, allowing 0.9 recently merged into openstack/requirements:\n\n  https://review.openstack.org/79817\n\nThis is a good example of how we should be linking gerrit and mailing\nlist discussions together more. I don\'t think the gerrit review was\nlinked in this thread nor was the mailing list discussion linked in the\ngerrit review.\n\nMark.\n\nOn Thu, 2014-03-13 at 22:45 -0700, Roman Podoliaka wrote:\n> Hi all,\n> \n> I think it\'s actually not that hard to fix the errors we have when\n> using SQLAlchemy 0.9.x releases.\n> \n> I uploaded two changes two Nova to fix unit tests:\n> - https://review.openstack.org/#/c/80431/ (this one should also fix\n> the Tempest test run error)\n> - https://review.openstack.org/#/c/80432/\n> \n> Thanks,\n> Roman\n> \n> On Thu, Mar 13, 2014 at 7:41 PM, Thomas Goirand <zigo at debian.org> wrote:\n> > On 03/14/2014 02:06 AM, Sean Dague wrote:\n> >> On 03/13/2014 12:31 PM, Thomas Goirand wrote:\n> >>> On 03/12/2014 07:07 PM, Sean Dague wrote:\n> >>>> Because of where we are in the freeze, I think this should wait until\n> >>>> Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which\n> >>>> I think is fine. I expect the rest of the issues can be addressed during\n> >>>> Juno 1.\n> >>>>\n> >>>>     -Sean\n> >>>\n> >>> Sean,\n> >>>\n> >>> No, it\'s not fine for me. I\'d like things to be fixed so we can move\n> >>> forward. Debian Sid has SQLA 0.9, and Jessie (the next Debian stable)\n> >>> will be released SQLA 0.9 and with Icehouse, not Juno.\n> >>\n> >> We\'re past freeze, and this requires deep changes in Nova DB to work. So\n> >> it\'s not going to happen. Nova provably does not work with SQLA 0.9, as\n> >> seen in Tempest tests.\n> >>\n> >>       -Sean\n> >\n> > I\'d be nice if we considered more the fact that OpenStack, at some\n> > point, gets deployed on top of distributions... :/\n> >\n> > Anyway, if we can\'t do it because of the freeze, then I will have to\n> > carry the patch in the Debian package. Never the less, someone will have\n> > to work and fix it. If you know how to help, it\'d be very nice if you\n> > proposed a patch, even if we don\'t accept it before Juno opens.\n> >\n> > Thomas Goirand (zigo)\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAKA_ueDPsjsvBbmDau=J+fdDSw2SRrJVyj1gA6YQy=O3XvG6xg@mail.gmail.com>',NULL),('<1395759854.3253.16.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 11:04:14',-14400,'2014-03-25 15:04:14',NULL,'[openstack-dev] [nova][PCI] one use case make the\n flavor/extra-info based solution to be right choice','On Tue, 2014-03-25 at 14:21 +0800, yongli he wrote:\n> ? 2014?03?21? 03:18, Jay Pipes ??:\n> > On Thu, 2014-03-20 at 13:50 +0000, Robert Li (baoli) wrote:\n> >> Hi Yongli,\n> >>\n> >> I\'m very glad that you bring this up and relive our discussion on PCI\n> >> passthrough and its application on networking. The use case you brought up\n> >> is:\n> >>\n> >>             user wants a FASTER NIC from INTEL to join a virtual\n> >> networking.\n> >>\n> >> By FASTER, I guess that you mean that the user is allowed to select a\n> >> particular vNIC card. Therefore, the above statement can be translated\n> >> into the following requests for a PCI device:\n> >>          . Intel vNIC\n> >>          . 1G or 10G or ?\n> >>          . network to join\n> >>\n> >> First of all, I\'m not sure in a cloud environment, a user would care about\n> >> the vendor or card type.\n> > Correct. Nor would/should a user of the cloud know what vendor or card\n> > type is in use on a particular compute node. At most, all a user of the\n> > cloud would be able to select from is an instance type (flavor) that\n> > listed some capability like \"high_io_networking\" or something like that,\n> > and the mapping of what \"high_io_networking\" meant on the back end of\n> > Nova would need to be done by the operator (i.e. if the tag\n> > \"high_io_networking\" is on a flavor a user has asked to launch a server\n> > with, then that tag should be translated into a set of capabilities that\n> > is passed to the scheduler and used to determine where the instance can\n> > be scheduled by looking at which compute nodes support that set of\n> > capabilities.\n> >\n> > This is what I\'ve been babbling about with regards to \"leaking\n> > implementation through the API\". What happens if, say, the operator\n> > decides to use IBM cards (instead of or in addition to Intel ones)? If\n> > you couple the implementation with the API, like the example above shows\n> > (\"user wants a FASTER NIC from INTEL\"), then you have to add more\n> > complexity to the front-end API that a user deals with, instead of just\n> > adding a capabilities mapping for new compute nodes that says\n> > \"high_io_networking\" tag can match to these new compute nodes with IBM\n> > cards.\n> Jay\n> \n> thank you, sorry for later reply\n> \n> in this use case, use might so not care about the vendor id/product id.\n> but for a specific image , the product\'s model(which related to the \n> vendor id/product id)\n> might cared by user. cause the image might could not support new device\n> which possibly use vendor_id and product id to eliminate the unsupported \n> device.\n> \n> anyway, even without the product/vendor id, the multiple extra tag still \n> needed.\n> and consideration this case, some accelerate card for encryption and \n> decryption/hash\n> there are many supported feature, and most likely different pci card \n> might support\n> different feature set,like : md5, DES,3DES, AES, RSA, SHA-x, IDEA, \n> RC4,5,6 ....\n> the way to select such a device is use it\'s feature set instead of one \n> or 2 of group, so\n> the extra information about a pci card is need, in a flexible way.\n\nHi Yongli,\n\nI\'m all for enabling users to take advantage of technology. I just will\npush to make sure that the public user-facing API hides things like\nvendor or product information as much as possible.\n\nBest,\n-jay\n\n\n\n','<53312066.5040808@intel.com>',NULL),('<1395763822-sup-8902@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-25 09:11:02',-25200,'2014-03-25 16:11:02',NULL,'[Openstack] Access VM console from a script','Excerpts from Nagaraj Mandya\'s message of 2014-03-25 08:58:14 -0700:\n> Hello,\n>   If I start a VM (on Havana), is there a way I can get into the console\n> through a script? Is the console accessible over telnet to a port or\n> something like that? Or is the only supported access through VNC? Thanks.\n\nnova console-log instance_id\n\nEnjoy. :)\n\n\n','<CAOh0v-UKF3Qi5xBox9XTZhwyfUJ-+xfuMEpo42pq-ijTXUkkdg@mail.gmail.com>',NULL),('<1395766204.3253.23.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 12:50:04',-14400,'2014-03-25 16:50:04',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials to\n Keystone','On Tue, 2014-03-25 at 12:23 +0000, Lucas Alvares Gomes wrote:\n> Hi,\n> \n> Right now Ironic is being responsible for storing the credentials for\n> the IPMI and SSH drivers (and potentially other drivers in the\n> future), I wonder if we should delegate this task to Keystone. The\n> Keystone V3 API now has a /credentials endpoint which would allow us\n> to specify arbitrary types (not only ec2 anymore) and use it as a\n> credential store[1].\n> \n> That would avoid further fragmentation of credentials being stored in\n> different places in OpenStack, and make the management of the\n> credentials easier (Think about a situation where many nodes share the\n> same IPMI username/password and we need to update it, if this is\n> stored in Keystone it only needs to be updated there once cause nodes\n> will only hold a reference to it)\n> \n> It also was pointed to me that setting a hard dependency on Keystone\n> V3 might significantly raises the bar for integration with existing\n> clouds*. So perhaps we should make it optional? In the same way we can\n> specify a username/password or key_filename for the ssh driver we\n> could have a reference to a credential in Keystone V3?\n\nI think the idea of using Keystone for keypair management in Nova is a\ngood one. There is already precedent in Nova for doing this kind of\nthing ... it\'s already been done for images, volumes, and network.\n\nOne problem with the Keystone v3 credentials API, though, is that it\ndoes not have support for unique names of keypairs per project, as that\nis how the Nova API /keypairs resource endpoint works.\n\n> What you guys think about the idea? What are the cloud\n> operators/sysadmins view on that?\n\nAs long as the functionality was enabled using the standard driver-based\nsetup (as was done for glance, nova, cinder, and neutron integration), I\ndon\'t see any issues for deployers. Of course, you\'d need a migration\nscript, but that\'s not a huge deal.\n\nBest,\n-jay\n\n\n\n\n','<CAB1EZBoMeKJme=4dTk2nffx0a9Jd4Xwc5jQsk3+1iH+nUM2zFw@mail.gmail.com>',NULL),('<1395769745.3253.24.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 13:49:05',-14400,'2014-03-25 17:49:05',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials to\n Keystone','On Tue, 2014-03-25 at 17:39 +0000, Miller, Mark M (EB SW Cloud - R&D -\nCorvallis) wrote:\n> Why not use Barbican? It stores credentials after encrypting them.\n\nNo reason not to add a Barbican driver as well.\n\nBest,\n-jay\n\n\n\n','<D6182642CE6D2D4FBFCDF99946E249883B4A84DA@G9W0343.americas.hpqcorp.net>',NULL),('<1395789600-sup-487@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 16:21:44',-25200,'2014-03-25 23:21:44',NULL,'[openstack-dev] [TripleO][reviews] We\'re falling behind','Excerpts from Robert Collins\'s message of 2014-03-25 13:17:29 -0700:\n> TripleO has just seen an influx of new contributors. \\o/. Flip side -\n> we\'re now slipping on reviews /o\\.\n> \n> In the meeting today we had basically two answers: more cores, and\n> more work by cores.\n> \n> We\'re slipping by 2 reviews a day, which given 16 cores is a small amount.\n> \n> I\'m going to propose some changes to core in the next couple of days -\n> I need to go and re-read a bunch of reviews first - but, right now we\n> don\'t have a hard lower bound on the number of reviews we request\n> cores commit to (on average).\n> \n> We\'re seeing 39/day from the 16 cores - which isn\'t enough as we\'re\n> falling behind. Thats 2.5 or so. So - I\'d like to ask all cores to\n> commit to doing 3 reviews a day, across all of tripleo (e.g. if your\n> favourite stuff is all reviewed, find two new things to review even if\n> outside comfort zone :)).\n> \n> And we always need more cores - so if you\'re not a core, this proposal\n> implies that we\'ll be asking that you a) demonstrate you can sustain 3\n> reviews a day on average as part of stepping up, and b) be willing to\n> commit to that.\n> \n> Obviously if we have enough cores we can lower the minimum commitment\n> - so I don\'t think this figure should be fixed in stone.\n> \n> And now - time for a loose vote - who (who is a tripleo core today)\n> supports / disagrees with this proposal - lets get some consensus\n> here.\n> \n> I\'m in favour, obviously :), though it is hard to put reviews ahead of\n> direct itch scratching, its the only way to scale the project.\n> \n\n+1\n\nFWIW I think we just haven\'t made reviews as much of a priority at the\nsame time that we got an influx of contribution.\n\nWe also started getting serious on CI, which I think has slowed the pace\nthrough the review machine, with the bonus that we break ourselves less\noften. :)\n\n> -Rob\n> \n\n\n','<CAJ3HoZ0URkDk=a4SVsF1CYLa8CvYzd8EJxa0dFPaND5Ubfef9w@mail.gmail.com>',NULL),('<1395804941-sup-7049@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 20:41:06',-25200,'2014-03-26 03:41:06',NULL,'[openstack-dev] [All][Keystone] Deprecation of the v2 API','Excerpts from Dolph Mathews\'s message of 2014-03-25 19:01:17 -0700:\n> On Tue, Mar 25, 2014 at 5:50 PM, Russell Bryant <rbryant at redhat.com> wrote:\n> \n> > We discussed the deprecation of the v2 keystone API in the cross-project\n> > meeting today [1].  This thread is to recap and bring that discussion to\n> > some consensus.\n> >\n> > The issue is that Keystone has marked the v2 API as deprecated in Icehouse:\n> >\n> >     https://blueprints.launchpad.net/keystone/+spec/deprecate-v2-api\n> >\n> > If you use the API, deployments will get this in their logs:\n> >\n> > WARNING keystone.openstack.common.versionutils [-] Deprecated: v2 API is\n> > deprecated as of Icehouse in favor of v3 API and may be removed in K.\n> >\n> > The deprecation status is reflected in the API for end users, as well.\n> > For example, from the CLI:\n> >\n> >   $ keystone discover\n> >   Keystone found at http://172.16.12.38:5000/v2.0\n> >     - supports version v2.0 (deprecated) here\n> > http://172.16.12.38:5000/v2.0/\n> >\n> > My proposal is that this deprecation be reverted.  Here\'s why:\n> >\n> > First, it seems there isn\'t a common use of \"deprecated\".  To me,\n> > marking something deprecated means that the deprecated feature:\n> >\n> >  - has been completely replaced by something else\n> >\n> \n> >  - end users / deployers should take action to migrate to the\n> >    new thing immediately.\n> >\n> \n> >  - The project has provided a documented migration path\n> \n> >  - the old thing will be removed at a specific date/release\n> >\n> \n> Agree on all points. Unfortunately, we have yet to succeed on the\n> documentation front:\n> \n> \n> https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition\n> \n> >\n> > The problem with the above is that most OpenStack projects do not\n> > support the v3 API yet.\n> >\n> > From talking to Dolph in the meeting, it sounds like the intention is:\n> >\n> >  - fully support v2, just don\'t add features\n> >\n> >  - signal to other projects that they should be migrating to v3\n> >\n> \n> Above all else, this was our primary goal: to raise awareness about our\n> path forward, and to identify the non-obvious stakeholders that we needed\n> to work with in order to drop support for v2. With today\'s discussion as\n> evidence, I think we\'ve succeeded in that regard :)\n> \n> >\n> > Given that intention, I believe the proper thing to do is to actually\n> > leave the API marked as fully supported / stable.  Keystone should be\n> > working with other OpenStack projects to migrate them to v3.  Once that\n> > is complete, deprecation can be re-visited.\n> >\n> \n> Happy to!\n> \n> Revert deprecation of the v2 API: https://review.openstack.org/#/c/82963/\n> \n> Although I\'d prefer to apply this patch directly to milestone-proposed, so\n> we can continue into Juno with the deprecation in master.\n> \n\nAs somebody maintaining a few master-chasing CD clouds, I\'d like to ask\nyou to please stop the squawking about deprecation until it has a definite\nreplacement and most if not all OpenStack core projects are using it.\n\n1 out of every 2 API calls on these clouds produces one of these errors\nin Keystone. That is just pointless. :-P\n\n\n','<CAC=h7gVRkyGAP_=XtcUQAy45JQ2d3bAf1gD9wJeqJFo76sNUjg@mail.gmail.com>',NULL),('<1395817600.18928.YahooMailNeo@web163805.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 00:06:40',-25200,'2014-03-26 07:06:40',NULL,'[openstack-dev] [Neutron] Using Python-Neutronclient from\n	Python - docstrings needed?','Thanks, will take a look\n\n\n\nOn Tuesday, March 25, 2014 11:33 PM, \"Collins, Sean\" <Sean_Collins2 at cable.comcast.com> wrote:\n \nOn Fri, Mar 21, 2014 at 08:35:05PM EDT, Rajdeep Dua wrote:\n> Sean,\n> If you can point me to the project file in github which needs to be modified , i will include these docs\n> \n> Thanks\n> Rajdeep\n\nI imagine inside the openstack-manuals git repo\n\nhttps://github.com/openstack/openstack-manuals\n\nPossibly inside the doc/user-guide tree.\n\nAlthough others may have better suggestions.\n\n\n-- \nSean M. Collins\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/3b249c7c/attachment.html>\n\n','<20140325180337.GH41777@HQSML-1081034>',NULL),('<1395838765.11657.40.camel@changyao-fedora>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-26 20:59:25',28800,'2014-03-26 12:59:25',NULL,'[Openstack] [Question] about test libvirt using OpenStack','Hi,\nI am developing a security driver of libvirt , I want to test the new \"security driver\" of libvirt \nusing OpenStack , I encounter some problem:\n\nI have known the back-end of OpenStack compute-node is libvirt (but they are independent modules) , I use \nDevStack to deploy the OpenStack . I notice that it automatically install \"All packages\" including \"libvirt\",\nso I decide to uninstall the \"libvirt packages\" ,then compile and install libvirt , but all after, \nwhen I use the OpenStack dashboard to create Instance , the Task state keep \"scheduling\" ,no forwarding.\n\nIs the problem in lacking proper libvirt configuration ?\nIs there other method to \"integrate\" libvirt to Openstack from src ? or How to deploy and test libvirt using OpenStack ?\n\nThanks\n\nH Changyao   \n\n\n\n',NULL,NULL),('<1395852135-sup-1055@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 09:51:33',-25200,'2014-03-26 16:51:33',NULL,'[openstack-dev] [TripleO] proxying SSL traffic for API requests','Excerpts from Chris Jones\'s message of 2014-03-26 06:58:59 -0700:\n> Hi\n> \n> We don\'t have a strong attachment to stunnel though, I quickly dropped it in front of our CI/CD undercloud and Rob wrote the element so we could repeat the deployment.\n> \n> In the fullness of time I would expect there to exist elements for several SSL terminators, but we shouldn\'t necessarily stick with stunnel because it happened to be the one I was most familiar with :)\n> \n> I would think that an httpd would be a good option to go with as the default, because I tend to think that we\'ll need an httpd running/managing the python code by default.\n> \n\nI actually think that it is important to separate SSL termination from\nthe app server. In addition to reasons of scale (SSL termination scales\nquite a bit differently than app serving), there is a security implication\nin having the private SSL keys on the same box that runs the app.\n\nSo if we use apache for running the python app servers, that is not a\nreason to also use apache for SSL. Quite the opposite I think.\n\nAs far as \"which is best\".. there are benefits and drawbacks for all of\nthem, and it is modular enough that we can just stick with stunnel and\nusers who find problems with it can switch it out without too much hassle.\n\n\n','<DDA205C4-48B9-4023-A3C4-689E0AD199FC@tenshu.net>',NULL),('<1395857225-sup-4792@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 11:10:04',-25200,'2014-03-26 18:10:04',NULL,'[openstack-dev] [all] sample config files should be ignored in\n	git...','This is an issue that affects all of our git repos. If you are using\noslo.config, you will likely also be using the sample config generator.\n\nHowever, for some reason we are all checking this generated file in.\nThis makes no sense, as we humans are not editting it, and it often\npicks up config files from other things like libraries (keystoneclient\nin particular). This has lead to breakage in the gate a few times for\nHeat, perhaps for others as well.\n\nI move that we all rm this file from our git trees, and start generating\nit as part of the install/dist process (I have no idea how to do\nthis..). This would require:\n\n- rm sample files and add them to .gitignore in all trees\n- Removing check_uptodate.sh from all trees/tox.ini\'s\n- Generating file during dist/install process.\n\nDoes anyone disagree?\n\n\n',NULL,NULL),('<1395859224.2646.17.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 14:40:24',-14400,'2014-03-26 18:40:24',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote:\n> Personally I view this as a bug. There is no reason why we shouldn?t\n> support arbitrary grouping of zones. I know there is at least one\n> problem with zones that overlap regarding displaying them properly:\n> \n> https://bugs.launchpad.net/nova/+bug/1277230\n> \n> There is probably a related issue that is causing the error you see\n> below. IMO both of these should be fixed. I also think adding a\n> compute node to two different aggregates with azs should be allowed.\n> \n> It also might be nice to support specifying multiple zones in the\n> launch command in these models. This would allow you to limit booting\n> to an intersection of two overlapping zones.\n> \n> A few examples where these ideas would be useful:\n> \n> 1. You have 3 racks of servers and half of the nodes from each rack\n> plugged into a different switch. You want to be able to specify to\n> spread across racks or switches via an AZ. In this model you could\n> have a zone for each switch and a zone for each rack.\n> \n> 2. A single cloud has 5 racks in one room in the datacenter and 5\n> racks in a second room. You?d like to give control to the user to\n> choose the room or choose the rack. In this model you would have one\n> zone for each room, and smaller zones for each rack.\n> \n> 3. You have a small 3 rack cloud and would like to ensure that your\n> production workloads don?t run on the same machines as your dev\n> workloads, but you also want to use zones spread workloads across the\n> three racks. Similarly to 1., you could split your racks in half via\n> dev and prod zones. Each one of these zones would overlap with a rack\n> zone.\n> \n> You can achieve similar results in these situations by making small\n> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1\n> switch2-rack2 switch2-rack3) but that removes the ability to decide to\n> launch something with less granularity. I.e. you can?t just specify\n> ?switch1\' or ?rack1\' or ?anywhere?\n> \n> I?d like to see all of the following work\n> nova boot ? (boot anywhere)\n> nova boot ?availability-zone switch1 ? (boot it switch1 zone)\n> nova boot ?availability-zone rack1 ? (boot in rack1 zone)\n> nova boot ?availability-zone switch1,rack1 ? (boot\n\nPersonally, I feel it is a mistake to continue to use the Amazon concept\nof an availability zone in OpenStack, as it brings with it the\nconnotation from AWS EC2 that each zone is an independent failure\ndomain. This characteristic of EC2 availability zones is not enforced in\nOpenStack Nova or Cinder, and therefore creates a false expectation for\nNova users.\n\nIn addition to the above problem with incongruent expectations, the\nother problem with Nova\'s use of the EC2 availability zone concept is\nthat availability zones are not hierarchical -- due to the fact that EC2\nAZs are independent failure domains. Not having the possibility of\nstructuring AZs hierarchically limits the ways in which Nova may be\ndeployed -- just see the cells API for the manifestation of this\nproblem.\n\nI would love it if the next version of the Nova and Cinder APIs would\ndrop the concept of an EC2 availability zone and introduce the concept\nof a generic region structure that can be infinitely hierarchical in\nnature. This would enable all of Vish\'s nova boot commands above in an\neven simpler fashion. For example:\n\nAssume a simple region hierarchy like so:\n\n              regionA\n              /      \\\n         regionB    regionC\n\n# User wants to boot in region B\nnova boot --region regionB\n# User wants to boot in either region B or region C\nnova boot --region regionA\n\nI think of the EC2 availability zone concept in the Nova and Cinder APIs\nas just another example of implementation leaking out of the API. The\nfact that EC2 availability zones are implemented as independent failure\ndomains and thus have a non-hierarchical structure has caused the Nova\nAPI to look and feel a certain way that locks the API into the\nimplementation of a non-OpenStack product.\n\nBest,\n-jay\n\n\n\n','<CC2944AB-FE7E-4951-ADC1-A8E848573437@gmail.com>',NULL),('<1395863724-sup-2766@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 13:08:01',-25200,'2014-03-26 20:08:01',NULL,'[openstack-dev] [all] sample config files should be ignored in\n	git...','Excerpts from Anne Gentle\'s message of 2014-03-26 11:49:29 -0700:\n> On Wed, Mar 26, 2014 at 1:10 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > This is an issue that affects all of our git repos. If you are using\n> > oslo.config, you will likely also be using the sample config generator.\n> >\n> > However, for some reason we are all checking this generated file in.\n> > This makes no sense, as we humans are not editting it, and it often\n> > picks up config files from other things like libraries (keystoneclient\n> > in particular). This has lead to breakage in the gate a few times for\n> > Heat, perhaps for others as well.\n> >\n> > I move that we all rm this file from our git trees, and start generating\n> > it as part of the install/dist process (I have no idea how to do\n> > this..). This would require:\n> >\n> > - rm sample files and add them to .gitignore in all trees\n> > - Removing check_uptodate.sh from all trees/tox.ini\'s\n> > - Generating file during dist/install process.\n> >\n> > Does anyone disagree?\n> >\n> \n> The documentation currently points to the latest copy of the generated\n> files when they\'re available. I\'d like to continue having those generated\n> and looked at by humans in reviews.\n> \n> I think if you asked non-devs, such as deployers, you\'d find wider uses.\n> Can you poll another group in addition to this mailing list?\n> \n\nThe way I see it, the generated sample config file is itself\ndocumentation. Perhaps that file should actually go where the docs go,\nrather than sitting in the git tree.\n\nWith other libraries causing changes anyway, we\'re not really reviewing\nevery change anyway, otherwise I wouldn\'t have sent this message. We\nweren\'t able to review what keystoneclient did before it broke our\ngate. Keystoneclient isn\'t going to review the matrix of dependent repos\nfor breakage there either.\n\nWe do review the code changes that lead to the relevant changes in our\nsamples, and that _should_ be enough. It works the same with all of\nour other code-born documentation (such as the Heat template guide). So\nI\'m comfortable saying that reviewers should be able to catch obvious\nthings that would break the sample configs from the code alone, in the\nsame way that reviewers would find such an error in other such generated\ndocumentation.\n\n\n','<CAD0KtVF0eFaqZbZzjCXWtoofDTa6XiF9W3SWWvpkN9vK8qgLHg@mail.gmail.com>',NULL),('<1395864490-sup-6165@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 13:09:52',-25200,'2014-03-26 20:09:52',NULL,'[openstack-dev] [all] sample config files should be ignored in\n	git...','Excerpts from Steven Hardy\'s message of 2014-03-26 11:27:58 -0700:\n> On Wed, Mar 26, 2014 at 11:10:04AM -0700, Clint Byrum wrote:\n> > This is an issue that affects all of our git repos. If you are using\n> > oslo.config, you will likely also be using the sample config generator.\n> > \n> > However, for some reason we are all checking this generated file in.\n> > This makes no sense, as we humans are not editting it, and it often\n> > picks up config files from other things like libraries (keystoneclient\n> > in particular). This has lead to breakage in the gate a few times for\n> > Heat, perhaps for others as well.\n> > \n> > I move that we all rm this file from our git trees, and start generating\n> > it as part of the install/dist process (I have no idea how to do\n> > this..). This would require:\n> > \n> > - rm sample files and add them to .gitignore in all trees\n> > - Removing check_uptodate.sh from all trees/tox.ini\'s\n> > - Generating file during dist/install process.\n> > \n> > Does anyone disagree?\n> \n> So this sounds like a great idea in theory, I\'d love to stop getting\n> surprise gate breakage every keystoneclient release becuause of minor\n> changes to keystone_authtoken.\n> \n> My main concern is we\'re replacing suprise breakage due to keystoneclient\n> with surprise breakage due to oslo.config, since that version is not\n> capped.\n> \n> E.g look at this review I just posted (too hastily) - generate_sample.sh\n> has done something crazy and generated a totally broken config:\n> \n> https://review.openstack.org/#/c/83151/\n> \n> I\'m not quite clear on why that\'s broken, but it does highlight one of the\n> problems with relying on autogeneration with no review.  I guess we\'ll get\n> to review the logs of the broken gate tests instead :\\\n> \n> I\'d love to hear ideas on how we can do this in an automated way which\n> won\'t be really unstable/unreliable.\n\nThis seems like a real bug, and one that would hopefully be handled\nthrough the normal bug fixing cycle that includes ensuring test\ncoverage. No?\n\n\n','<20140326182757.GA23993@t430slt.redhat.com>',NULL),('<1395866564-sup-6374@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-26 13:52:04',-25200,'2014-03-26 20:52:04',NULL,'[OpenStack-Infra] Using MySQL for unit tests in storyboard','Excerpts from jeblair\'s message of 2014-03-26 13:30:28 -0700:\n> Hi,\n> \n> I recently started looking into running the unit tests with MySQL.  I\n> pushed the start of a change here to do that:\n> \n> https://review.openstack.org/#/c/82872/\n> \n> In particular, that change implements something we\'ve wanted to do for a\n> long time elsewhere in OpenStack -- create a dedicated MySQL database\n> for each test so that tests can safely run in parallel.  However, that\n> has uncovered the following issues:\n> \n>  * The tests do not use alembic, except for the migration test. This\n>    could lead to variations in what the unit tests are testing against\n>    as compared to production.\n> \n>  * The model does not specify an engine for MySQL (this is a difference\n>    between the model and the alembic migrations). So when the unit tests\n>    are run on MySQL, they may end up on MyISAM (they do in the gate).\n> \n\nWhy MyISAM? The default has been InnoDB since MySQL 5.5.\n\n>  * The two errors that show up in the test results for my patch relate\n>    to how timestamps are stored differently between MySQL and SQLite.\n> \n\nIsn\'t this a bug in sqlalchemy? I\'d expect any data type that is a common\nname in the two databases (and thus the same in the model definition)\nto produce the same data in the python representation.\n\n>  * The errors that you can not see in the test report from Jenkins but\n>    would if you ran in an environment with InnoDB as the default engine\n>    for MySQL are several instances of foreign key constraint errors.\n> \n\nSide note: IMHO: Just drop the FK constraints if you want the app to\nbe scalable.  FK\'s just add extra reads for every write, when you could\nbe doing that verification / orphan clean up offline later on.\n\n> I think it is desirable to run the unit tests with MySQL largely because\n> I think we should be testing it in the way we intend to use it in\n> production.  Note especially the last point above -- our unit tests have\n> significant problems with MySQL.  That suggests one of two things to me:\n> either the tests aren\'t testing real behavior, or our system is actually\n> broken in production.  Neither one seems like a good situation.\n> \n\nWouldn\'t integration tests be the place to find production vs. code path\nissues? Tying unit tests to the creation of mysql databases introduces a\nreally big piece of machinery into the test fixture setup, which you\nwant to be fast and lean so developers can iterate on it while working.\n\n> My inclination would be to use MySQL for unit tests, use alembic to\n> create the schema, and fix the errors currently uncovered by this.\n> \n> It\'s not going to be a trivial change, but I think it\'s worth doing.\n> Before embarking on it, I\'d like to see if we can get consensus.  We can\n> talk about it here or possibly at the meeting tomorrow.\n> \n> Ruslan has commented in that review with the following:\n> \n> > But, I think that we should consider work done in major OpenStack\n> > projects. They don\'t use real MySQL to run unit-tests. Here is what\n> > the do (or plan to do):\n> >\n> > * Run unit-tests on SQLite. DB schema is created from SQLA metadata\n> > * Run DB migration tests on MySQL and Postgres\n> > * Run tests to compare SQLA metadata and DB migrations to make sure\n> >   that they\'re in sync. Here is WIP patch\n> >   https://review.openstack.org/#/c/\n> >\n> > I\'m not opposed to this direction, I just want to make sure we\'re\n> > aligned with the common practices in OpenStack\n> \n> (That last link doesn\'t seem to be correct.)\n> \n> That\'s a good point, but I personally find testing as close to\n> production as possible desirable -- MySQL and SQLite are not compatible\n> so we shouldn\'t pretend that they are.  If we prove this is a viable\n> strategy, then I think we should recommend OpenStack projects adopt it\n> as well.\n> \n\nI just wonder if SQLAlchemy is intended to \"smooth out\" the differences\nbetween the two in such a way where you can at least be confident that\nyour code is doing what you think it is.\n\n\n','<87ha6ksnx7.fsf@meyer.lemoncheese.net>',NULL),('<1395877549.2646.23.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 19:45:49',-14400,'2014-03-26 23:45:49',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote:\n> On Mar 26, 2014, at 11:40 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda Ishaya wrote:\n> >> Personally I view this as a bug. There is no reason why we shouldn?t\n> >> support arbitrary grouping of zones. I know there is at least one\n> >> problem with zones that overlap regarding displaying them properly:\n> >> \n> >> https://bugs.launchpad.net/nova/+bug/1277230\n> >> \n> >> There is probably a related issue that is causing the error you see\n> >> below. IMO both of these should be fixed. I also think adding a\n> >> compute node to two different aggregates with azs should be allowed.\n> >> \n> >> It also might be nice to support specifying multiple zones in the\n> >> launch command in these models. This would allow you to limit booting\n> >> to an intersection of two overlapping zones.\n> >> \n> >> A few examples where these ideas would be useful:\n> >> \n> >> 1. You have 3 racks of servers and half of the nodes from each rack\n> >> plugged into a different switch. You want to be able to specify to\n> >> spread across racks or switches via an AZ. In this model you could\n> >> have a zone for each switch and a zone for each rack.\n> >> \n> >> 2. A single cloud has 5 racks in one room in the datacenter and 5\n> >> racks in a second room. You?d like to give control to the user to\n> >> choose the room or choose the rack. In this model you would have one\n> >> zone for each room, and smaller zones for each rack.\n> >> \n> >> 3. You have a small 3 rack cloud and would like to ensure that your\n> >> production workloads don?t run on the same machines as your dev\n> >> workloads, but you also want to use zones spread workloads across the\n> >> three racks. Similarly to 1., you could split your racks in half via\n> >> dev and prod zones. Each one of these zones would overlap with a rack\n> >> zone.\n> >> \n> >> You can achieve similar results in these situations by making small\n> >> zones (switch1-rack1 switch1-rack2 switch1-rack3 switch2-rack1\n> >> switch2-rack2 switch2-rack3) but that removes the ability to decide to\n> >> launch something with less granularity. I.e. you can?t just specify\n> >> ?switch1\' or ?rack1\' or ?anywhere?\n> >> \n> >> I?d like to see all of the following work\n> >> nova boot ? (boot anywhere)\n> >> nova boot ?availability-zone switch1 ? (boot it switch1 zone)\n> >> nova boot ?availability-zone rack1 ? (boot in rack1 zone)\n> >> nova boot ?availability-zone switch1,rack1 ? (boot\n> > \n> > Personally, I feel it is a mistake to continue to use the Amazon concept\n> > of an availability zone in OpenStack, as it brings with it the\n> > connotation from AWS EC2 that each zone is an independent failure\n> > domain. This characteristic of EC2 availability zones is not enforced in\n> > OpenStack Nova or Cinder, and therefore creates a false expectation for\n> > Nova users.\n> > \n> > In addition to the above problem with incongruent expectations, the\n> > other problem with Nova\'s use of the EC2 availability zone concept is\n> > that availability zones are not hierarchical -- due to the fact that EC2\n> > AZs are independent failure domains. Not having the possibility of\n> > structuring AZs hierarchically limits the ways in which Nova may be\n> > deployed -- just see the cells API for the manifestation of this\n> > problem.\n> > \n> > I would love it if the next version of the Nova and Cinder APIs would\n> > drop the concept of an EC2 availability zone and introduce the concept\n> > of a generic region structure that can be infinitely hierarchical in\n> > nature. This would enable all of Vish\'s nova boot commands above in an\n> > even simpler fashion. For example:\n> > \n> > Assume a simple region hierarchy like so:\n> > \n> >              regionA\n> >              /      \\\n> >         regionB    regionC\n> > \n> > # User wants to boot in region B\n> > nova boot --region regionB\n> > # User wants to boot in either region B or region C\n> > nova boot --region regionA\n> \n> I think the overlapping zones allows for this and also enables additional use\n> cases as mentioned in my earlier email.\n\nYou are assuming that the region hierarchy I was describing had only a\nsingle root region. I didn\'t say that. I envision multiple root regions,\nwhich would enable compute nodes to reside in multiple regions.\n\n>  Hierarchical doesn?t work for the\n> rack/switch model. \n\nSure it does. Just not a single root hierarchy.\n\n> I?m definitely +1 on breaking from the amazon usage\n> of availability zones but I?m a bit leery to add another parameter to\n> the create request.\n\nIt wouldn\'t add another *required* parameter to the create request. The\nregion would default to whatever region the keystone endpoint that\nreturned the service catalog for the novaclient had as its default\nregion.\n\n>  It is also unfortunate that region already has a meaning\n> in the amazon world which will add confusion.\n\nOK. We could call it something else... though IIRC, trying to come up\nwith a name for this kind of thing is, well, kind of tough :)\n\n-jay\n\n\n\n','<87468B08-9E47-4980-ABA6-F6B933603A71@gmail.com>',NULL),('<1395882878.2646.25.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 21:14:38',-14400,'2014-03-27 01:14:38',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','On Thu, 2014-03-27 at 01:10 +0000, Joshua Harlow wrote:\n> Region graphs?\n> \n> Sounds like what u are describing sounds like a graph\n> (non-hierarchical) which has nodes that have defined attributes on\n> them.\n> \n> A region then would just be a set of connected nodes (which could be\n> connected via a parent<->child edge for example). \n> \n> Each node can also have attributes (allowing regions to also be\n> selected by common attributes). Seems like that might fit what is\n> wanted?\n\nPrecisely.\n\n-jay\n\n> \n> From: Jay Pipes <jaypipes at gmail.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage\n> questions)\" <openstack-dev at lists.openstack.org>\n> Date: Wednesday, March 26, 2014 at 4:45 PM\n> To: \"openstack-dev at lists.openstack.org\"\n> <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and\n> Host aggregates..\n> \n> \n> \n>         On Wed, 2014-03-26 at 13:33 -0700, Vishvananda Ishaya wrote:\n>                 On Mar 26, 2014, at 11:40 AM, Jay Pipes\n>                 <jaypipes at gmail.com> wrote:\n>                 \n>                 > On Wed, 2014-03-26 at 09:47 -0700, Vishvananda\n>                 Ishaya wrote:\n>                 >> Personally I view this as a bug. There is no reason\n>                 why we shouldn?t\n>                 >> support arbitrary grouping of zones. I know there\n>                 is at least one\n>                 >> problem with zones that overlap regarding\n>                 displaying them properly:\n>                 >> \n>                 >> https://bugs.launchpad.net/nova/+bug/1277230\n>                 >> \n>                 >> There is probably a related issue that is causing\n>                 the error you see\n>                 >> below. IMO both of these should be fixed. I also\n>                 think adding a\n>                 >> compute node to two different aggregates with azs\n>                 should be allowed.\n>                 >> \n>                 >> It also might be nice to support specifying\n>                 multiple zones in the\n>                 >> launch command in these models. This would allow\n>                 you to limit booting\n>                 >> to an intersection of two overlapping zones.\n>                 >> \n>                 >> A few examples where these ideas would be useful:\n>                 >> \n>                 >> 1. You have 3 racks of servers and half of the\n>                 nodes from each rack\n>                 >> plugged into a different switch. You want to be\n>                 able to specify to\n>                 >> spread across racks or switches via an AZ. In this\n>                 model you could\n>                 >> have a zone for each switch and a zone for each\n>                 rack.\n>                 >> \n>                 >> 2. A single cloud has 5 racks in one room in the\n>                 datacenter and 5\n>                 >> racks in a second room. You?d like to give control\n>                 to the user to\n>                 >> choose the room or choose the rack. In this model\n>                 you would have one\n>                 >> zone for each room, and smaller zones for each\n>                 rack.\n>                 >> \n>                 >> 3. You have a small 3 rack cloud and would like to\n>                 ensure that your\n>                 >> production workloads don?t run on the same machines\n>                 as your dev\n>                 >> workloads, but you also want to use zones spread\n>                 workloads across the\n>                 >> three racks. Similarly to 1., you could split your\n>                 racks in half via\n>                 >> dev and prod zones. Each one of these zones would\n>                 overlap with a rack\n>                 >> zone.\n>                 >> \n>                 >> You can achieve similar results in these situations\n>                 by making small\n>                 >> zones (switch1-rack1 switch1-rack2 switch1-rack3\n>                 switch2-rack1\n>                 >> switch2-rack2 switch2-rack3) but that removes the\n>                 ability to decide to\n>                 >> launch something with less granularity. I.e. you\n>                 can?t just specify\n>                 >> ?switch1\' or ?rack1\' or ?anywhere?\n>                 >> \n>                 >> I?d like to see all of the following work\n>                 >> nova boot ? (boot anywhere)\n>                 >> nova boot ?availability-zone switch1 ? (boot it\n>                 switch1 zone)\n>                 >> nova boot ?availability-zone rack1 ? (boot in rack1\n>                 zone)\n>                 >> nova boot ?availability-zone switch1,rack1 ? (boot\n>                 > \n>                 > Personally, I feel it is a mistake to continue to\n>                 use the Amazon concept\n>                 > of an availability zone in OpenStack, as it brings\n>                 with it the\n>                 > connotation from AWS EC2 that each zone is an\n>                 independent failure\n>                 > domain. This characteristic of EC2 availability\n>                 zones is not enforced in\n>                 > OpenStack Nova or Cinder, and therefore creates a\n>                 false expectation for\n>                 > Nova users.\n>                 > \n>                 > In addition to the above problem with incongruent\n>                 expectations, the\n>                 > other problem with Nova\'s use of the EC2\n>                 availability zone concept is\n>                 > that availability zones are not hierarchical -- due\n>                 to the fact that EC2\n>                 > AZs are independent failure domains. Not having the\n>                 possibility of\n>                 > structuring AZs hierarchically limits the ways in\n>                 which Nova may be\n>                 > deployed -- just see the cells API for the\n>                 manifestation of this\n>                 > problem.\n>                 > \n>                 > I would love it if the next version of the Nova and\n>                 Cinder APIs would\n>                 > drop the concept of an EC2 availability zone and\n>                 introduce the concept\n>                 > of a generic region structure that can be infinitely\n>                 hierarchical in\n>                 > nature. This would enable all of Vish\'s nova boot\n>                 commands above in an\n>                 > even simpler fashion. For example:\n>                 > \n>                 > Assume a simple region hierarchy like so:\n>                 > \n>                 >              regionA\n>                 >              /      \\\n>                 >         regionB    regionC\n>                 > \n>                 > # User wants to boot in region B\n>                 > nova boot --region regionB\n>                 > # User wants to boot in either region B or region C\n>                 > nova boot --region regionA\n>                 \n>                 I think the overlapping zones allows for this and also\n>                 enables additional use\n>                 cases as mentioned in my earlier email.\n>         \n>         \n>         You are assuming that the region hierarchy I was describing\n>         had only a\n>         single root region. I didn\'t say that. I envision multiple\n>         root regions,\n>         which would enable compute nodes to reside in multiple\n>         regions.\n>         \n>         \n>                   Hierarchical doesn?t work for the\n>                 rack/switch model. \n>         \n>         \n>         Sure it does. Just not a single root hierarchy.\n>         \n>         \n>                 I?m definitely +1 on breaking from the amazon usage\n>                 of availability zones but I?m a bit leery to add\n>                 another parameter to\n>                 the create request.\n>         \n>         \n>         It wouldn\'t add another *required* parameter to the create\n>         request. The\n>         region would default to whatever region the keystone endpoint\n>         that\n>         returned the service catalog for the novaclient had as its\n>         default\n>         region.\n>         \n>         \n>                   It is also unfortunate that region already has a\n>                 meaning\n>                 in the amazon world which will add confusion.\n>         \n>         \n>         OK. We could call it something else... though IIRC, trying to\n>         come up\n>         with a name for this kind of thing is, well, kind of tough :)\n>         \n>         \n>         -jay\n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n\n\n\n\n','<CF58C792.5A8D3%harlowja@yahoo-inc.com>',NULL),('<1395897903.23015.36.camel@localhost>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-27 18:25:03',46800,'2014-03-27 05:25:03',NULL,'[Openstack] Unable to access guests in DevStack on OpenStack\n	environment','\nHello!\n\nI would be very grateful if someone could please help me to\ntrouble-shoot a connectivity issue: I cannot ping or SSH into guests I\nhave created on top of DevStack.\n\nWhat might be a complicating factor is that I have the DevStack cluster\nrunning on guests that are running on top of a base OpenStack setup, but\nmost likely, I assume, I\'m just making a really silly mistake in my\nsetup somewhere. I just need to find it. Or maybe, there\'s just\nsomething odd about my setup that triggers some known issues?\n\nHere\'s what I\'m working with:\n\n     1. A base OpenStack install (Havana), using VLANs and a couple of\n        servers. One controller host and two compute hosts. This is my\n        base-cluster. It is not based on DevStack, but just an ordinary\n        OpenStack install.\n     2. I spin up three guest machines (\"nova boot...\"). From the\n        controller host of the base-cluster I can log into those guests\n        without problem (\"ip netns exec .... ssh ...\"). These three\n        guests are my midlevel-cluster. The controller has private IP\n        address 10.5.5.2, the compute hosts have 10.5.5.5 and 10.5.5.6.\n     3. I log into the midlevel-cluster hosts and download and install\n        DevStack (\"stable/havana\") on them. The stack.sh script runs\n        without error or problem.\n     4. After stack.sh has run, I can see that a private and public\n        network have been created for that DevStack installation. On the\n        controller I also set some security group rules, to allow ICMP\n        and SSH to any guest instances that should be created within\n        DevStack.\n     5. I now create a guest on that DevStack cluster (\"nova boot... \"\n        again). This is my toplevel-guest. I can see (\"nova list...\")\n        that the guest has booted and that an IP address has been\n        assigned, but no matter what I do, I cannot ping or login to\n        those toplevel-guests. I use the qrouter namespace to attempt\n        this (\"ip netns exec qrouter-....\"), but no luck.\n\nSome information, which might be useful for trouble shooting:\n\nOn the midlevel-cluster hosts, I use these localrc files to install\nDevStack (I\'m just looking for simple GRE networking). It\'s a multi-node\ninstall, so first, here is the localrc for the controller:\n\n        # Passwords and tokens\n        ADMIN_PASSWORD=password\n        MYSQL_PASSWORD=password\n        RABBIT_PASSWORD=password\n        SERVICE_PASSWORD=password\n        SERVICE_TOKEN=tokentoken\n        \n        # Logging, screen, devstack behavior\n        API_RATE_LIMIT=False\n        VERBOSE=True\n        DEBUG=True\n        LOGFILE=/home/ubuntu/tempest_run/workspace/stack.sh.log\n        USE_SCREEN=True\n        SCREEN_LOGDIR=/home/ubuntu/tempest_run/workspace\n        RECLONE=Yes\n        OFFLINE=False\n        LIBVIRT_TYPE=kvm\n        \n        # Services\n        disable_service n-net\n        disable_service n-cpu\n        enable_service q-svc\n        enable_service q-agt\n        enable_service q-l3\n        enable_service q-meta\n        enable_service q-lbaas\n        enable_service q-dhcp\n        enable_service tempest\n        enable_service neutron\n        \n        # Networking\n        ENABLE_TENANT_TUNNELS=True\n        Q_AGENT_EXTRA_AGENT_OPTS=(tunnel_type=gre)\n        Q_AGENT_EXTRA_OVS_OPTS=(tenant_network_type=gre)\n        Q_SRV_EXTRA_OPTS=(tenant_network_type=gre)\n        Q_USE_NAMESPACE=True\n        Q_USE_SECGROUP=True\n\nHere is the localrc for the compute hosts:\n\n        # Passwords and tokens\n        ADMIN_PASSWORD=password\n        MYSQL_PASSWORD=password\n        RABBIT_PASSWORD=password\n        SERVICE_PASSWORD=password\n        SERVICE_TOKEN=tokentoken\n        \n        # Logging, screen, devstack behavior\n        VERBOSE=True\n        DEBUG=True\n        LOGFILE=/home/ubuntu/tempest_run/workspace/stack.sh.log\n        USE_SCREEN=True\n        SCREEN_LOGDIR=/home/ubuntu/tempest_run/workspace\n        RECLONE=Yes\n        OFFLINE=False\n        LIBVIRT_TYPE=kvm\n        \n        # Controller connection\n        HOST_IP=10.5.5.5\n        SERVICE_HOST=10.5.5.2\n        MYSQL_HOST=10.5.5.2\n        RABBIT_HOST=10.5.5.2\n        Q_HOST=10.5.5.2\n        GLANCE_HOSTPORT=10.5.5.2:9292\n        \n        # Services\n        ENABLED_SERVICES=n-cpu,rabbit,neutron,q-agt\n        \n        # Networking\n        ENABLE_TENANT_TUNNELS=True\n        Q_AGENT_EXTRA_AGENT_OPTS=(tunnel_type=gre)\n        Q_AGENT_EXTRA_OVS_OPTS=(tenant_network_type=gre)\n        Q_USE_NAMESPACE=True\n        Q_USE_SECGROUP=True\n        \n\nAfter stack.sh has run to completion, I get the following on the\nDevStack controller:\n\n        $ ip netns qrouter-293c2395-3a05-4ad7-99e5-e5b1ebb80a35\n\n        $ neutron net-list\n        +--------------------------------------+---------+------------------------------------------------------+\n        | id                                   | name    | subnets                                              |\n        +--------------------------------------+---------+------------------------------------------------------+\n        | 789cb9ce-9f91-4d0b-9069-6eb5b808bdfc | public  | d206940f-5daf-464d-bf28-4dac527aba06 172.24.4.224/28 |\n        | c8f179ba-6675-49f3-92ba-6e58b38f59c1 | private | b2bc098b-2b87-46a5-bb5e-7a75d9520c17 10.0.0.0/24     |\n        +--------------------------------------+---------+------------------------------------------------------+\n        \nI create a guest instance (toplevel-guest), like so:\n\n        $ nova boot --image e09876f9-c755-48a8-ada7-c658f8736a9e --flavor 1 --key-name mykey foobar\n\nWith \"nova list\" I see:\n\n        $ nova list\n        +--------------------------------------+--------+--------+------------+-------------+---------------------+\n        | ID                                   | Name   | Status | Task State | Power State | Networks            |\n        +--------------------------------------+--------+--------+------------+-------------+---------------------+\n        | 8794d3fd-8596-4ddb-bf20-d823b9804f0d | foobar | ACTIVE | -          | Running     | public=172.24.4.227 |\n        +--------------------------------------+--------+--------+------------+-------------+---------------------+\n        \nThe following routers are known to neutron:\n\n        $ neutron router-list\n        +--------------------------------------+---------+-----------------------------------------------------------------------------+\n        | id                                   | name    | external_gateway_info                                                       |\n        +--------------------------------------+---------+-----------------------------------------------------------------------------+\n        | 293c2395-3a05-4ad7-99e5-e5b1ebb80a35 | router1 | {\"network_id\": \"789cb9ce-9f91-4d0b-9069-6eb5b808bdfc\", \"enable_snat\": true} |\n        +--------------------------------------+---------+-----------------------------------------------------------------------------+\n\nThe following ports are known to neutron:\n\n        $ neutron port-list\n        +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n        | id                                   | name | mac_address       | fixed_ips                                                                           |\n        +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n        | 22126185-ae99-42d0-8876-bef9a96ff5a1 |      | fa:16:3e:9d:be:fb | {\"subnet_id\": \"d206940f-5daf-464d-bf28-4dac527aba06\", \"ip_address\": \"172.24.4.227\"} |\n        | 8914b69b-b9f7-4555-bbcb-5af8ae0d340c |      | fa:16:3e:0d:fd:d2 | {\"subnet_id\": \"b2bc098b-2b87-46a5-bb5e-7a75d9520c17\", \"ip_address\": \"10.0.0.1\"}     |\n        | d5f45982-e7fa-49a7-a8b3-b3e7b93a227c |      | fa:16:3e:2a:6f:ff | {\"subnet_id\": \"d206940f-5daf-464d-bf28-4dac527aba06\", \"ip_address\": \"172.24.4.226\"} |\n        +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n\nI can ping the address 172.24.4.226 (presumably the router), but not the address of the guest (172.24.4.227).\n\n        $ ping 172.24.4.227\n        PING 172.24.4.227 (172.24.4.227) 56(84) bytes of data.\n        From 172.24.4.225 icmp_seq=1 Destination Host Unreachable\n        From 172.24.4.225 icmp_seq=2 Destination Host Unreachable\n        From 172.24.4.225 icmp_seq=3 Destination Host Unreachable\n\nEven if I use the qrouter namespace, it still doesn\'t work:\n\n        $ sudo ip netns exec qrouter-293c2395-3a05-4ad7-99e5-e5b1ebb80a35 ping 172.24.4.227\n        PING 172.24.4.227 (172.24.4.227) 56(84) bytes of data.\n        From 172.24.4.226 icmp_seq=1 Destination Host Unreachable\n        From 172.24.4.226 icmp_seq=2 Destination Host Unreachable\n        From 172.24.4.226 icmp_seq=3 Destination Host Unreachable\n        \nIn my desparation, I tried security groups in nova as well as neutron.\nThe nova rules were added like this\n\n        $ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0\n        $ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0\n\nThe neutron rules like this:\n\n        $ neutron security-group-rule-create --protocol tcp --port-range-min 22 \\\n                 --port-range-max 22 --direction ingress default\n        $ neutron security-group-rule-create --protocol icmp \\\n                 --direction ingress foogroup\n\nBut in both cases, no luck.\n\nI also tried bringing up the guest NIC on the private network. Still no\nluck.\n\n\nOn the DevStack controller host, the OVS config looks like this:\n\n        $ sudo ovs-vsctl show\n        2a2472f2-eebc-4214-8a57-bfc05a21ae26\n            Bridge br-int\n                Port br-int\n                    Interface br-int\n                        type: internal\n                Port \"qr-8914b69b-b9\"\n                    tag: 1\n                    Interface \"qr-8914b69b-b9\"\n                        type: internal\n                Port patch-tun\n                    Interface patch-tun\n                        type: patch\n                        options: {peer=patch-int}\n            Bridge br-tun\n                Port br-tun\n                    Interface br-tun\n                        type: internal\n                Port \"gre-10.5.5.5\"\n                    Interface \"gre-10.5.5.5\"\n                        type: gre\n                        options: {in_key=flow, local_ip=\"10.5.5.2\", out_key=flow, remote_ip=\"10.5.5.5\"}\n                Port patch-int\n                    Interface patch-int\n                        type: patch\n                        options: {peer=patch-tun}\n            Bridge br-ex\n                Port \"qg-d5f45982-e7\"\n                    Interface \"qg-d5f45982-e7\"\n                        type: internal\n                Port br-ex\n                    Interface br-ex\n                        type: internal\n            ovs_version: \"1.4.6\"\n\nOn the DevStack compute hosts, it\'s like this:\n\n        $ sudo ovs-vsctl show\n        9b280f62-130c-4c12-89ea-0bc2fa22156e\n            Bridge br-int\n                Port patch-tun\n                    Interface patch-tun\n                        type: patch\n                        options: {peer=patch-int}\n                Port br-int\n                    Interface br-int\n                        type: internal\n            Bridge br-tun\n                Port br-tun\n                    Interface br-tun\n                        type: internal\n                Port \"gre-10.5.5.2\"\n                    Interface \"gre-10.5.5.2\"\n                        type: gre\n                        options: {in_key=flow, local_ip=\"10.5.5.5\", out_key=flow, remote_ip=\"10.5.5.2\"}\n                Port patch-int\n                    Interface patch-int\n                        type: patch\n                        options: {peer=patch-tun}\n            ovs_version: \"1.4.6\"\n\n\nThe network interfaces on the DevStack controller are like this:\n\n        $ ifconfig -a\n        br-ex     Link encap:Ethernet  HWaddr 96:bf:ae:d5:a0:44  \n                  inet addr:172.24.4.225  Bcast:0.0.0.0  Mask:255.255.255.240\n                  inet6 addr: fe80::94bf:aeff:fed5:a044/64 Scope:Link\n                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n                  RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:6 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:468 (468.0 B)  TX bytes:468 (468.0 B)\n        \n        br-int    Link encap:Ethernet  HWaddr 62:28:61:90:0b:47  \n                  BROADCAST MULTICAST  MTU:1500  Metric:1\n                  RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:468 (468.0 B)  TX bytes:0 (0.0 B)\n        \n        br-tun    Link encap:Ethernet  HWaddr 0e:f3:a7:96:91:43  \n                  BROADCAST MULTICAST  MTU:1500  Metric:1\n                  RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n        \n        eth0      Link encap:Ethernet  HWaddr fa:16:3e:dc:7e:82  \n                  inet addr:10.5.5.2  Bcast:10.5.5.255  Mask:255.255.255.0\n                  inet6 addr: fe80::f816:3eff:fedc:7e82/64 Scope:Link\n                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n                  RX packets:438220 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:180410 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:1000 \n                  RX bytes:580740049 (580.7 MB)  TX bytes:14956005 (14.9 MB)\n        \n        lo        Link encap:Local Loopback  \n                  inet addr:127.0.0.1  Mask:255.0.0.0\n                  inet6 addr: ::1/128 Scope:Host\n                  UP LOOPBACK RUNNING  MTU:16436  Metric:1\n                  RX packets:84427 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:84427 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:51372553 (51.3 MB)  TX bytes:51372553 (51.3 MB)\n\nOn the compute hosts, they are like this:\n\n        $ ifconfig -a\n        br-int    Link encap:Ethernet  HWaddr c2:25:18:4b:8b:49  \n                  BROADCAST MULTICAST  MTU:1500  Metric:1\n                  RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n        \n        br-tun    Link encap:Ethernet  HWaddr 1e:27:74:ee:a1:45  \n                  BROADCAST MULTICAST  MTU:1500  Metric:1\n                  RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n        \n        eth0      Link encap:Ethernet  HWaddr fa:16:3e:07:fd:48  \n                  inet addr:10.5.5.5  Bcast:10.5.5.255  Mask:255.255.255.0\n                  inet6 addr: fe80::f816:3eff:fe07:fd48/64 Scope:Link\n                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n                  RX packets:309885 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:134774 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:1000 \n                  RX bytes:422666082 (422.6 MB)  TX bytes:10489797 (10.4 MB)\n        \n        lo        Link encap:Local Loopback  \n                  inet addr:127.0.0.1  Mask:255.0.0.0\n                  inet6 addr: ::1/128 Scope:Host\n                  UP LOOPBACK RUNNING  MTU:16436  Metric:1\n                  RX packets:159 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:159 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:10580 (10.5 KB)  TX bytes:10580 (10.5 KB)\n        \n        virbr0    Link encap:Ethernet  HWaddr 9a:21:30:f2:8a:3b  \n                  inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0\n                  UP BROADCAST MULTICAST  MTU:1500  Metric:1\n                  RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n\n\nIf anyone has any idea what I could possibly be doing wrong, I would be\nvery grateful for any explanation.\n\nThank you very much...\n\nJuergen\n\n\n\n\n',NULL,NULL),('<1395913763.23015.46.camel@localhost>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-27 22:49:23',46800,'2014-03-27 09:49:23',NULL,'[Openstack] Unable to access guests in DevStack on OpenStack\n environment','\nHello!\n\nThank you for your reply.\n\nOn Thu, 2014-03-27 at 19:44 +1300, Robert Collins wrote:\n> A few things to consider\n>  - you\'ll be running qemu I presume, not nested kvm? Thats very slow -\n> perhaps the VM hasn\'t booted. nova console-log will let you see that\n> and also potentially other failures at boot etc.\n\nGood idea with the console-log. I do run \'nested kvm\', but I confirmed\nnow that the instance has finished booting. So, that\'s not the issue.\n\nHowever, I noticed this output in the console. Notice how there is no IP\naddress listed for eth0 in the \'ifconfig\' output:\n\n        ...\n        failed 15/20: up 213.60. request failed\n        failed 16/20: up 215.66. request failed\n        failed 17/20: up 217.72. request failed\n        failed 18/20: up 219.78. request failed\n        failed 19/20: up 221.83. request failed\n        failed 20/20: up 223.88. request failed\n        failed to read iid from metadata. tried 20\n        no results found for mode=net. up 225.94. searched: nocloud configdrive ec2\n        failed to get instance-id of datasource\n        Starting dropbear sshd: generating rsa key... generating dsa key... OK\n        === network info ===\n        if-info: lo,up,127.0.0.1,8,::1\n        if-info: eth0,up,,8,fe80::f816:3eff:feea:465c\n        === datasource: None None ===\n        === cirros: current=0.3.1 uptime=227.17 ===\n        route: fscanf\n        === pinging gateway failed, debugging connection ===\n        ############ debug start ##############\n        ### /etc/init.d/sshd start\n        Starting dropbear sshd: OK\n        route: fscanf\n        ### ifconfig -a\n        eth0      Link encap:Ethernet  HWaddr FA:16:3E:EA:46:5C  \n                  inet6 addr: fe80::f816:3eff:feea:465c/64 Scope:Link\n                  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n                  RX packets:15 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:10 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:1000 \n                  RX bytes:1094 (1.0 KiB)  TX bytes:1520 (1.4 KiB)\n        \n        lo        Link encap:Local Loopback  \n                  inet addr:127.0.0.1  Mask:255.0.0.0\n                  inet6 addr: ::1/128 Scope:Host\n                  UP LOOPBACK RUNNING  MTU:16436  Metric:1\n                  RX packets:12 errors:0 dropped:0 overruns:0 frame:0\n                  TX packets:12 errors:0 dropped:0 overruns:0 carrier:0\n                  collisions:0 txqueuelen:0 \n                  RX bytes:1020 (1020.0 B)  TX bytes:1020 (1020.0 B)\n        \n        ### route -n\n        Kernel IP routing table\n        Destination     Gateway         Genmask         Flags Metric Ref    Use Iface\n        route: fscanf\n        ### cat /etc/resolv.conf\n        cat: can\'t open \'/etc/resolv.conf\': No such file or directory\n        ### gateway not found\n        /sbin/cirros-status: line 1: can\'t open /etc/resolv.conf: no such file\n        ### pinging nameservers\n        ### uname -a\n        Linux cirros 3.2.0-37-virtual #58-Ubuntu SMP Thu Jan 24 15:48:03 UTC 2013 x86_64 GNU/Linux\n        ### lsmod\n        Module                  Size  Used by    Not tainted\n        nls_iso8859_1          12713  0 \n        nls_cp437              16991  0 \n        vfat                   17585  0 \n        fat                    61512  1 vfat\n        isofs                  40257  0 \n        ip_tables              27473  0 \n        x_tables               29891  1 ip_tables\n        pcnet32                42119  0 \n        8139cp                 27409  0 \n        ne2k_pci               13691  0 \n        8390                   18856  1 ne2k_pci\n        e1000                 108589  0 \n        acpiphp                24231  0 \n        ### dmesg | tail\n        [    1.885580] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)\n        [    1.899859] pcnet32: pcnet32.c:v1.35 21.Apr.2008 tsbogend at alpha.franken.de\n        [    1.913241] ip_tables: (C) 2000-2006 Netfilter Core Team\n        [    1.984750] kjournald starting.  Commit interval 5 seconds\n        [    1.984761] EXT3-fs (vda): mounted filesystem with ordered data mode\n        [    2.067740] kjournald starting.  Commit interval 5 seconds\n        [    2.177773] EXT3-fs (vda): using internal journal\n        [    2.177779] EXT3-fs (vda): mounted filesystem with ordered data mode\n        [    3.569157] EXT3-fs (vda): using internal journal\n        [   15.280373] eth0: no IPv6 routers present\n        ### tail -n 25 /var/log/messages\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.073181] pnp 00:00: [io  0x0d00-0xffff window]\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.073183] pnp 00:00: [mem 0x000a0000-0x000bffff window]\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.073184] pnp 00:00: [mem 0xe0000000-0xfebfffff window]\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.073219] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)\n        ...\n        ...\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.074031] pnp 00:05: Plug and Play ACPI device, IDs PNP0501 (active)\n        Mar 27 03:25:14 cirros kern.debug kernel: [    1.074116] pnp 00:06: [io  0x02f8-0x02ff]\n        Mar 27 03:25:26 cirros kern.debug kernel: [   15.280373] eth0: no IPv6 routers present\n        Mar 27 03:28:57 cirros authpriv.info dropbear[291]: Running in background\n        ############ debug end   ##############\n          ____               ____  ____\n         / __/ __ ____ ____ / __ \\/ __/\n        / /__ / // __// __// /_/ /\\ \\ \n        \\___//_//_/  /_/   \\____/___/ \n           http://cirros-cloud.net\n        \n        \n        login as \'cirros\' user. default password: \'cubswin:)\'. use \'sudo\' for root.\n        cirros login: \n        \n\nSo, while the instance boots, it doesn\'t seem to think that it has any\nIP addresses at all. That\'s of course a problem. What could cause\nsomething like this?\n\n\n>  - you should see DHCP requests and responses in syslog on the control\n> node, if you don\'t the VM definitely hasn\'t come up.\n\nWell, I do see some DHCP requests, however, they are just log entries\nfor the controller node itself getting its own address via DHCP. But\nthis is what I saw in the controller node\'s syslog:\n\n        Mar 27 09:25:45 jaxkia-controller ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl -- --if-exists del-port tap4696f888-5e -- add-port br-int tap4696f888-5e -- set Interface tap4696f888-5e type=internal -- set Interface tap4696f888-5e external-ids:iface-id=4696f888-5e7f-4a47-b171-44b9dcf7a0e3 -- set Interface tap4696f888-5e external-ids:iface-status=active -- set Interface tap4696f888-5e external-ids:attached-mac=fa:16:3e:1a:50:b1\n        Mar 27 09:25:45 jaxkia-controller kernel: [ 6273.435010] device tap4696f888-5e entered promiscuous mode\n        Mar 27 09:25:47 jaxkia-controller ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=2 set Port tap4696f888-5e tag=1\n        Mar 27 09:25:47 jaxkia-controller dnsmasq[13621]: started, version 2.59 cachesize 150\n        Mar 27 09:25:47 jaxkia-controller dnsmasq[13621]: compile time options: IPv6 GNU-getopt DBus i18n DHCP TFTP conntrack IDN\n        Mar 27 09:25:47 jaxkia-controller dnsmasq[13621]: warning: no upstream servers configured\n        Mar 27 09:25:47 jaxkia-controller dnsmasq-dhcp[13621]: DHCP, static leases only on 10.0.0.0, lease time 1d\n        Mar 27 09:25:47 jaxkia-controller dnsmasq[13621]: cleared cache\n        Mar 27 09:25:47 jaxkia-controller dnsmasq-dhcp[13621]: read /opt/stack/data/neutron/dhcp/e88962a5-e60e-48ef-b74d-4ea656a4f246/host\n        Mar 27 09:25:47 jaxkia-controller dnsmasq-dhcp[13621]: read /opt/stack/data/neutron/dhcp/e88962a5-e60e-48ef-b74d-4ea656a4f246/opts\n        Mar 27 09:25:47 jaxkia-controller dnsmasq[13621]: cleared cache\n        Mar 27 09:25:47 jaxkia-controller dnsmasq-dhcp[13621]: read /opt/stack/data/neutron/dhcp/e88962a5-e60e-48ef-b74d-4ea656a4f246/host\n        Mar 27 09:25:47 jaxkia-controller dnsmasq-dhcp[13621]: read /opt/stack/data/neutron/dhcp/e88962a5-e60e-48ef-b74d-4ea656a4f246/opts\n        Mar 27 09:25:48 jaxkia-controller ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=2 set Port tap4696f888-5e tag=1\n        Mar 27 09:25:49 jaxkia-controller ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=2 set Port tap4696f888-5e tag=1\n        Mar 27 09:25:57 jaxkia-controller kernel: [ 6285.104023] tap4696f888-5e: no IPv6 routers present\n        Mar 27 09:26:10 jaxkia-controller dhclient: DHCPREQUEST of 10.5.5.6 on eth0 to 10.5.5.3 port 67\n        Mar 27 09:26:10 jaxkia-controller dhclient: DHCPACK of 10.5.5.6 from 10.5.5.3\n        Mar 27 09:26:10 jaxkia-controller dhclient: bound to 10.5.5.6 -- renewal in 53 seconds.\n        ...\n        \nThe 10.5.5.6 address is the controller node\'s address, so, that\'s\nsomething else. However, the first line in the above excerpt is for\novs-vsctl. It does something with the MAC address \"fa:16:3e:1a:50:b1\",\nwhich is exactly the address of the cirros top-level guest, which\ndoesn\'t seem to get an IP address. So, it want\'s to do something with\nit, but something doesn\'t seem to work out.\n\n\n>  - you should be able to ping the VM from the netns of the dhcp agent\n> (if dhcp is working then this is a good place to start)\n\nThe DHCP namespace exists, but pinging isn\'t possible. No surprise,\nconsidering that it doesn\'t get an IP address.\n\n\n>  - if dhcp isn\'t working, try using tcp dump on the compute nodes and\n> debug your overlay network (there are many blog posts on this)\n\nI guess that would be next.\n\n\n> That all said - its very odd that the vm got an ip on the *public*\n> network. I would have expected it to get an ip on the private network\n> and be exposed on the public one via a floating ip. the public network\n> probably has dhcp off (see neutron net-show and neutron subnet-show).\n> \n> At a guess - you booted the vm as admin, rather than the user account,\n> and you got the public network as the network for the VM. Try using\n> the demo user account, or make your own user.\n\nYes, you are right. I changed it now so that I create the VM as the demo\nuser. I promptly get an IP address assigned from the private network.\nWell, nova and neutron think the address is assigned, but as we saw from\nthe console-log, the guest never received that address...\n\nMaybe the above additional information is useful in determining where to\nlook next?\n\nAt any rate, I really appreciate you taking the time trying to help me.\n\nSincerely,\n\nJuergen\n\n\n\n> -Rob\n> \n> \n> On 27 March 2014 18:25, Juergen Brendel <juergen at brendel.com> wrote:\n> >\n> > Hello!\n> >\n> > I would be very grateful if someone could please help me to\n> > trouble-shoot a connectivity issue: I cannot ping or SSH into guests I\n> > have created on top of DevStack.\n> >\n> > What might be a complicating factor is that I have the DevStack cluster\n> > running on guests that are running on top of a base OpenStack setup, but\n> > most likely, I assume, I\'m just making a really silly mistake in my\n> > setup somewhere. I just need to find it. Or maybe, there\'s just\n> > something odd about my setup that triggers some known issues?\n> >\n> > Here\'s what I\'m working with:\n> >\n> >      1. A base OpenStack install (Havana), using VLANs and a couple of\n> >         servers. One controller host and two compute hosts. This is my\n> >         base-cluster. It is not based on DevStack, but just an ordinary\n> >         OpenStack install.\n> >      2. I spin up three guest machines (\"nova boot...\"). From the\n> >         controller host of the base-cluster I can log into those guests\n> >         without problem (\"ip netns exec .... ssh ...\"). These three\n> >         guests are my midlevel-cluster. The controller has private IP\n> >         address 10.5.5.2, the compute hosts have 10.5.5.5 and 10.5.5.6.\n> >      3. I log into the midlevel-cluster hosts and download and install\n> >         DevStack (\"stable/havana\") on them. The stack.sh script runs\n> >         without error or problem.\n> >      4. After stack.sh has run, I can see that a private and public\n> >         network have been created for that DevStack installation. On the\n> >         controller I also set some security group rules, to allow ICMP\n> >         and SSH to any guest instances that should be created within\n> >         DevStack.\n> >      5. I now create a guest on that DevStack cluster (\"nova boot... \"\n> >         again). This is my toplevel-guest. I can see (\"nova list...\")\n> >         that the guest has booted and that an IP address has been\n> >         assigned, but no matter what I do, I cannot ping or login to\n> >         those toplevel-guests. I use the qrouter namespace to attempt\n> >         this (\"ip netns exec qrouter-....\"), but no luck.\n> >\n> > Some information, which might be useful for trouble shooting:\n> >\n> > On the midlevel-cluster hosts, I use these localrc files to install\n> > DevStack (I\'m just looking for simple GRE networking). It\'s a multi-node\n> > install, so first, here is the localrc for the controller:\n> >\n> >         # Passwords and tokens\n> >         ADMIN_PASSWORD=password\n> >         MYSQL_PASSWORD=password\n> >         RABBIT_PASSWORD=password\n> >         SERVICE_PASSWORD=password\n> >         SERVICE_TOKEN=tokentoken\n> >\n> >         # Logging, screen, devstack behavior\n> >         API_RATE_LIMIT=False\n> >         VERBOSE=True\n> >         DEBUG=True\n> >         LOGFILE=/home/ubuntu/tempest_run/workspace/stack.sh.log\n> >         USE_SCREEN=True\n> >         SCREEN_LOGDIR=/home/ubuntu/tempest_run/workspace\n> >         RECLONE=Yes\n> >         OFFLINE=False\n> >         LIBVIRT_TYPE=kvm\n> >\n> >         # Services\n> >         disable_service n-net\n> >         disable_service n-cpu\n> >         enable_service q-svc\n> >         enable_service q-agt\n> >         enable_service q-l3\n> >         enable_service q-meta\n> >         enable_service q-lbaas\n> >         enable_service q-dhcp\n> >         enable_service tempest\n> >         enable_service neutron\n> >\n> >         # Networking\n> >         ENABLE_TENANT_TUNNELS=True\n> >         Q_AGENT_EXTRA_AGENT_OPTS=(tunnel_type=gre)\n> >         Q_AGENT_EXTRA_OVS_OPTS=(tenant_network_type=gre)\n> >         Q_SRV_EXTRA_OPTS=(tenant_network_type=gre)\n> >         Q_USE_NAMESPACE=True\n> >         Q_USE_SECGROUP=True\n> >\n> > Here is the localrc for the compute hosts:\n> >\n> >         # Passwords and tokens\n> >         ADMIN_PASSWORD=password\n> >         MYSQL_PASSWORD=password\n> >         RABBIT_PASSWORD=password\n> >         SERVICE_PASSWORD=password\n> >         SERVICE_TOKEN=tokentoken\n> >\n> >         # Logging, screen, devstack behavior\n> >         VERBOSE=True\n> >         DEBUG=True\n> >         LOGFILE=/home/ubuntu/tempest_run/workspace/stack.sh.log\n> >         USE_SCREEN=True\n> >         SCREEN_LOGDIR=/home/ubuntu/tempest_run/workspace\n> >         RECLONE=Yes\n> >         OFFLINE=False\n> >         LIBVIRT_TYPE=kvm\n> >\n> >         # Controller connection\n> >         HOST_IP=10.5.5.5\n> >         SERVICE_HOST=10.5.5.2\n> >         MYSQL_HOST=10.5.5.2\n> >         RABBIT_HOST=10.5.5.2\n> >         Q_HOST=10.5.5.2\n> >         GLANCE_HOSTPORT=10.5.5.2:9292\n> >\n> >         # Services\n> >         ENABLED_SERVICES=n-cpu,rabbit,neutron,q-agt\n> >\n> >         # Networking\n> >         ENABLE_TENANT_TUNNELS=True\n> >         Q_AGENT_EXTRA_AGENT_OPTS=(tunnel_type=gre)\n> >         Q_AGENT_EXTRA_OVS_OPTS=(tenant_network_type=gre)\n> >         Q_USE_NAMESPACE=True\n> >         Q_USE_SECGROUP=True\n> >\n> >\n> > After stack.sh has run to completion, I get the following on the\n> > DevStack controller:\n> >\n> >         $ ip netns qrouter-293c2395-3a05-4ad7-99e5-e5b1ebb80a35\n> >\n> >         $ neutron net-list\n> >         +--------------------------------------+---------+------------------------------------------------------+\n> >         | id                                   | name    | subnets                                              |\n> >         +--------------------------------------+---------+------------------------------------------------------+\n> >         | 789cb9ce-9f91-4d0b-9069-6eb5b808bdfc | public  | d206940f-5daf-464d-bf28-4dac527aba06 172.24.4.224/28 |\n> >         | c8f179ba-6675-49f3-92ba-6e58b38f59c1 | private | b2bc098b-2b87-46a5-bb5e-7a75d9520c17 10.0.0.0/24     |\n> >         +--------------------------------------+---------+------------------------------------------------------+\n> >\n> > I create a guest instance (toplevel-guest), like so:\n> >\n> >         $ nova boot --image e09876f9-c755-48a8-ada7-c658f8736a9e --flavor 1 --key-name mykey foobar\n> >\n> > With \"nova list\" I see:\n> >\n> >         $ nova list\n> >         +--------------------------------------+--------+--------+------------+-------------+---------------------+\n> >         | ID                                   | Name   | Status | Task State | Power State | Networks            |\n> >         +--------------------------------------+--------+--------+------------+-------------+---------------------+\n> >         | 8794d3fd-8596-4ddb-bf20-d823b9804f0d | foobar | ACTIVE | -          | Running     | public=172.24.4.227 |\n> >         +--------------------------------------+--------+--------+------------+-------------+---------------------+\n> >\n> > The following routers are known to neutron:\n> >\n> >         $ neutron router-list\n> >         +--------------------------------------+---------+-----------------------------------------------------------------------------+\n> >         | id                                   | name    | external_gateway_info                                                       |\n> >         +--------------------------------------+---------+-----------------------------------------------------------------------------+\n> >         | 293c2395-3a05-4ad7-99e5-e5b1ebb80a35 | router1 | {\"network_id\": \"789cb9ce-9f91-4d0b-9069-6eb5b808bdfc\", \"enable_snat\": true} |\n> >         +--------------------------------------+---------+-----------------------------------------------------------------------------+\n> >\n> > The following ports are known to neutron:\n> >\n> >         $ neutron port-list\n> >         +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n> >         | id                                   | name | mac_address       | fixed_ips                                                                           |\n> >         +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n> >         | 22126185-ae99-42d0-8876-bef9a96ff5a1 |      | fa:16:3e:9d:be:fb | {\"subnet_id\": \"d206940f-5daf-464d-bf28-4dac527aba06\", \"ip_address\": \"172.24.4.227\"} |\n> >         | 8914b69b-b9f7-4555-bbcb-5af8ae0d340c |      | fa:16:3e:0d:fd:d2 | {\"subnet_id\": \"b2bc098b-2b87-46a5-bb5e-7a75d9520c17\", \"ip_address\": \"10.0.0.1\"}     |\n> >         | d5f45982-e7fa-49a7-a8b3-b3e7b93a227c |      | fa:16:3e:2a:6f:ff | {\"subnet_id\": \"d206940f-5daf-464d-bf28-4dac527aba06\", \"ip_address\": \"172.24.4.226\"} |\n> >         +--------------------------------------+------+-------------------+-------------------------------------------------------------------------------------+\n> >\n> > I can ping the address 172.24.4.226 (presumably the router), but not the address of the guest (172.24.4.227).\n> >\n> >         $ ping 172.24.4.227\n> >         PING 172.24.4.227 (172.24.4.227) 56(84) bytes of data.\n> >         From 172.24.4.225 icmp_seq=1 Destination Host Unreachable\n> >         From 172.24.4.225 icmp_seq=2 Destination Host Unreachable\n> >         From 172.24.4.225 icmp_seq=3 Destination Host Unreachable\n> >\n> > Even if I use the qrouter namespace, it still doesn\'t work:\n> >\n> >         $ sudo ip netns exec qrouter-293c2395-3a05-4ad7-99e5-e5b1ebb80a35 ping 172.24.4.227\n> >         PING 172.24.4.227 (172.24.4.227) 56(84) bytes of data.\n> >         From 172.24.4.226 icmp_seq=1 Destination Host Unreachable\n> >         From 172.24.4.226 icmp_seq=2 Destination Host Unreachable\n> >         From 172.24.4.226 icmp_seq=3 Destination Host Unreachable\n> >\n> > In my desparation, I tried security groups in nova as well as neutron.\n> > The nova rules were added like this\n> >\n> >         $ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0\n> >         $ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0\n> >\n> > The neutron rules like this:\n> >\n> >         $ neutron security-group-rule-create --protocol tcp --port-range-min 22 \\\n> >                  --port-range-max 22 --direction ingress default\n> >         $ neutron security-group-rule-create --protocol icmp \\\n> >                  --direction ingress foogroup\n> >\n> > But in both cases, no luck.\n> >\n> > I also tried bringing up the guest NIC on the private network. Still no\n> > luck.\n> >\n> >\n> > On the DevStack controller host, the OVS config looks like this:\n> >\n> >         $ sudo ovs-vsctl show\n> >         2a2472f2-eebc-4214-8a57-bfc05a21ae26\n> >             Bridge br-int\n> >                 Port br-int\n> >                     Interface br-int\n> >                         type: internal\n> >                 Port \"qr-8914b69b-b9\"\n> >                     tag: 1\n> >                     Interface \"qr-8914b69b-b9\"\n> >                         type: internal\n> >                 Port patch-tun\n> >                     Interface patch-tun\n> >                         type: patch\n> >                         options: {peer=patch-int}\n> >             Bridge br-tun\n> >                 Port br-tun\n> >                     Interface br-tun\n> >                         type: internal\n> >                 Port \"gre-10.5.5.5\"\n> >                     Interface \"gre-10.5.5.5\"\n> >                         type: gre\n> >                         options: {in_key=flow, local_ip=\"10.5.5.2\", out_key=flow, remote_ip=\"10.5.5.5\"}\n> >                 Port patch-int\n> >                     Interface patch-int\n> >                         type: patch\n> >                         options: {peer=patch-tun}\n> >             Bridge br-ex\n> >                 Port \"qg-d5f45982-e7\"\n> >                     Interface \"qg-d5f45982-e7\"\n> >                         type: internal\n> >                 Port br-ex\n> >                     Interface br-ex\n> >                         type: internal\n> >             ovs_version: \"1.4.6\"\n> >\n> > On the DevStack compute hosts, it\'s like this:\n> >\n> >         $ sudo ovs-vsctl show\n> >         9b280f62-130c-4c12-89ea-0bc2fa22156e\n> >             Bridge br-int\n> >                 Port patch-tun\n> >                     Interface patch-tun\n> >                         type: patch\n> >                         options: {peer=patch-int}\n> >                 Port br-int\n> >                     Interface br-int\n> >                         type: internal\n> >             Bridge br-tun\n> >                 Port br-tun\n> >                     Interface br-tun\n> >                         type: internal\n> >                 Port \"gre-10.5.5.2\"\n> >                     Interface \"gre-10.5.5.2\"\n> >                         type: gre\n> >                         options: {in_key=flow, local_ip=\"10.5.5.5\", out_key=flow, remote_ip=\"10.5.5.2\"}\n> >                 Port patch-int\n> >                     Interface patch-int\n> >                         type: patch\n> >                         options: {peer=patch-tun}\n> >             ovs_version: \"1.4.6\"\n> >\n> >\n> > The network interfaces on the DevStack controller are like this:\n> >\n> >         $ ifconfig -a\n> >         br-ex     Link encap:Ethernet  HWaddr 96:bf:ae:d5:a0:44\n> >                   inet addr:172.24.4.225  Bcast:0.0.0.0  Mask:255.255.255.240\n> >                   inet6 addr: fe80::94bf:aeff:fed5:a044/64 Scope:Link\n> >                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:6 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:468 (468.0 B)  TX bytes:468 (468.0 B)\n> >\n> >         br-int    Link encap:Ethernet  HWaddr 62:28:61:90:0b:47\n> >                   BROADCAST MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:468 (468.0 B)  TX bytes:0 (0.0 B)\n> >\n> >         br-tun    Link encap:Ethernet  HWaddr 0e:f3:a7:96:91:43\n> >                   BROADCAST MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n> >\n> >         eth0      Link encap:Ethernet  HWaddr fa:16:3e:dc:7e:82\n> >                   inet addr:10.5.5.2  Bcast:10.5.5.255  Mask:255.255.255.0\n> >                   inet6 addr: fe80::f816:3eff:fedc:7e82/64 Scope:Link\n> >                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:438220 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:180410 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:1000\n> >                   RX bytes:580740049 (580.7 MB)  TX bytes:14956005 (14.9 MB)\n> >\n> >         lo        Link encap:Local Loopback\n> >                   inet addr:127.0.0.1  Mask:255.0.0.0\n> >                   inet6 addr: ::1/128 Scope:Host\n> >                   UP LOOPBACK RUNNING  MTU:16436  Metric:1\n> >                   RX packets:84427 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:84427 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:51372553 (51.3 MB)  TX bytes:51372553 (51.3 MB)\n> >\n> > On the compute hosts, they are like this:\n> >\n> >         $ ifconfig -a\n> >         br-int    Link encap:Ethernet  HWaddr c2:25:18:4b:8b:49\n> >                   BROADCAST MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n> >\n> >         br-tun    Link encap:Ethernet  HWaddr 1e:27:74:ee:a1:45\n> >                   BROADCAST MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n> >\n> >         eth0      Link encap:Ethernet  HWaddr fa:16:3e:07:fd:48\n> >                   inet addr:10.5.5.5  Bcast:10.5.5.255  Mask:255.255.255.0\n> >                   inet6 addr: fe80::f816:3eff:fe07:fd48/64 Scope:Link\n> >                   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:309885 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:134774 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:1000\n> >                   RX bytes:422666082 (422.6 MB)  TX bytes:10489797 (10.4 MB)\n> >\n> >         lo        Link encap:Local Loopback\n> >                   inet addr:127.0.0.1  Mask:255.0.0.0\n> >                   inet6 addr: ::1/128 Scope:Host\n> >                   UP LOOPBACK RUNNING  MTU:16436  Metric:1\n> >                   RX packets:159 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:159 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:10580 (10.5 KB)  TX bytes:10580 (10.5 KB)\n> >\n> >         virbr0    Link encap:Ethernet  HWaddr 9a:21:30:f2:8a:3b\n> >                   inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0\n> >                   UP BROADCAST MULTICAST  MTU:1500  Metric:1\n> >                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n> >                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n> >                   collisions:0 txqueuelen:0\n> >                   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n> >\n> >\n> > If anyone has any idea what I could possibly be doing wrong, I would be\n> > very grateful for any explanation.\n> >\n> > Thank you very much...\n> >\n> > Juergen\n> >\n> >\n> >\n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n\n\n\n\n','<CAJ3HoZ1FhHxPrvbeYB=LvZCv4Q0=Zqb_jJseOT-GCjLyFEqixA@mail.gmail.com>',NULL),('<1395916703.96348.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-27 18:38:23',28800,'2014-03-27 10:38:23',NULL,'[Openstack] Unable to connect to AMQP server','Hi all,\n\nI have installed openstack using RDO on fedora 19. Now, the system was unused for a few days. When i opened it today, the setup is not working. I mean I can access nova, glance, keystone etc. but I cant launch the instance. Whenever I tried to boot a VM, it gets stuck at build stage. So, I decided to restart nova-compute and scheduler processes (Has worked for me in past) and here is the output I am getting:\n\n2014-03-27 14:48:44.355 ERROR nova.openstack.common.rpc.impl_qpid [req-2d415e36-dd79-4971-838d-5f1b4e32e64c None None] Unable to connect to AMQP server: [Errno 111] ECONNREFUSED. Sleeping 1 seconds\n2014-03-27 14:48:45.372 ERROR nova.openstack.common.rpc.impl_qpid [req-2d415e36-dd79-4971-838d-5f1b4e32e64c None None] Unable to connect to AMQP server: [Errno 111] ECONNREFUSED. Sleeping 2 seconds\n2014-03-27 14:48:47.376 ERROR nova.openstack.common.rpc.impl_qpid [req-2d415e36-dd79-4971-838d-5f1b4e32e64c None None] Unable to connect to AMQP server: [Errno 111] ECONNREFUSED. Sleeping 4 seconds\n\nBoth the processes are giving the same error. Can you please help me solve the error? Plus, the machine might have been rebooted, if that info is useful.?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140327/a4b5db77/attachment.html>\n\n',NULL,NULL),('<1395929559.2321.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 10:12:39',-14400,'2014-03-27 14:12:39',NULL,'[openstack-dev] [depfreeze] [horizon] Exception request:\n python-keystoneclient>=0.7.0','On Thu, 2014-03-27 at 13:53 +0000, Julie Pichon wrote:\n> Hi,\n> \n> I would like to request a depfreeze exception to bump up the keystone\n> client requirement [1], in order to reenable the ability for users to\n> update their own password with Keystone v3 in Horizon in time for\n> Icehouse [2]. This capability is requested by end-users quite often but\n> had to be \"deactivated\" at the end of Havana due to some issues that are\n> now resolved, thanks to the latest keystone client release. Since this\n> is a library we control, hopefully this shouldn\'t cause too much trouble\n> for packagers.\n> \n> Thank you for your consideration.\n> \n> Julie\n> \n> \n> [1] https://review.openstack.org/#/c/83287/\n> [2] https://review.openstack.org/#/c/59918/\n\nIMHO, it\'s hard to imagine that Icehouse requiring a more recent version\nof keystoneclient being a problem or risk for anyone.\n\nMark.\n\n\n\n','<53342D54.7060801@redhat.com>',NULL),('<1395935328.3723.21.camel@lappy>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-28 01:48:48',36000,'2014-03-27 15:48:48',NULL,'[Openstack] [OSSA 2014-008] Routers can be cross plugged by other\n tenants (CVE-2014-0056)','OpenStack Security Advisory: 2014-008\nCVE: CVE-2014-0056\nDate: March 27, 2014\nTitle: Routers can be cross plugged by other tenants\nReporter: Aaron Rosen (VMWare)\nProducts: Neutron\nAffects: 2012.2 versions up to 2013.2.2\n\nDescription:\nAaron Rosen from VMWare reported a vulnerability where Neutron fails to\nperform proper authorization checks when creating ports. By choosing a\ndevice id of a router from a different tenant when creating a port, an\nauthenticated user can access the network of other tenants. This affects\ndeployments of Neutron using plugins relying on the l3-agent.\n\nIcehouse (development branch) fix: \nhttps://review.openstack.org/83391\n\n\nHavana fix: \nhttps://review.openstack.org/83393\n\n\nNotes: \nOne should perform and audit of the ports that are already attached to\nrouters after applying this patch and remove ports that a tenant may\nhave cross plugged.\n\nReferences:\nhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0056\nhttps://bugs.launchpad.net/bugs/1243327\n\n\n-- \nGrant Murphy\nOpenStack Vulnerability Management Team\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 230 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140328/dee815b8/attachment.pgp>\n\n',NULL,NULL),('<1395935328.3723.21.camel@lappy>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2014-03-28 01:48:48',36000,'2014-03-27 15:48:48',NULL,'[openstack-announce] [OSSA 2014-008] Routers can be cross plugged\n by other tenants (CVE-2014-0056)','OpenStack Security Advisory: 2014-008\nCVE: CVE-2014-0056\nDate: March 27, 2014\nTitle: Routers can be cross plugged by other tenants\nReporter: Aaron Rosen (VMWare)\nProducts: Neutron\nAffects: 2012.2 versions up to 2013.2.2\n\nDescription:\nAaron Rosen from VMWare reported a vulnerability where Neutron fails to\nperform proper authorization checks when creating ports. By choosing a\ndevice id of a router from a different tenant when creating a port, an\nauthenticated user can access the network of other tenants. This affects\ndeployments of Neutron using plugins relying on the l3-agent.\n\nIcehouse (development branch) fix: \nhttps://review.openstack.org/83391\n\n\nHavana fix: \nhttps://review.openstack.org/83393\n\n\nNotes: \nOne should perform and audit of the ports that are already attached to\nrouters after applying this patch and remove ports that a tenant may\nhave cross plugged.\n\nReferences:\nhttp://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0056\nhttps://bugs.launchpad.net/bugs/1243327\n\n\n-- \nGrant Murphy\nOpenStack Vulnerability Management Team\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 230 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20140328/dee815b8/attachment.pgp>\n\n',NULL,NULL),('<1395954703-sup-200@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 14:19:14',-25200,'2014-03-27 21:19:14',NULL,'[openstack-dev] [all] sample config files should be ignored in\n	git...','Excerpts from Sean Dague\'s message of 2014-03-27 13:11:57 -0700:\n> On 03/27/2014 02:54 PM, Joe Gordon wrote:\n> > \n> > \n> > \n> > On Thu, Mar 27, 2014 at 2:21 AM, Dirk M?ller <dirk at dmllr.de\n> > <mailto:dirk at dmllr.de>> wrote:\n> > \n> >     Hi,\n> > \n> >     >> When I was an operator, I regularly referred to the sample config\n> >     files\n> >     >> in the git repository.\n> > \n> >     The sample config files in git repository are tremendeously useful for\n> >     any operator and OpenStack Packager. Having them generateable with a\n> >     tox line is very cumbersome.\n> > \n> > \n> > Why is it cumbersome? We do the same thing.\n> \n> Because we\'ve already got a working tox environment. Which includes\n> knowing, in advance that you can\'t just pip install tox (as 1.7.x is\n> broken), and that you need to have postgresql and mysql and libffi dev\n> packages installed, and a C compiler.\n> \n> Start with a pristine Linux it is a lot manual steps you have to go\n> through to get a working config out of tox -e genconfig.\n> \n> So I think it\'s a fair concern that we did just move a burden back onto\n> users because we dug a hole by letting libraries declare arbitrary\n> required variables in our config files.\n> \n\nThis is pretty standard in the open source world. Git trees do not have\nall of the things that the user needs. Git trees have all the things\nthat the project provides.\n\nIf this were autotools we\'d have people run \'autoreconf\' and/or \'make\ndoc\'. That would likely involve installing autotools, and might also\nrequire some libraries to be present to build tools that are used to\ngenerate things.\n\nI would have a hard time supporting users who don\'t read the README\nbefore trying to make use of a git tree to use/install/configure a piece\nof software. As long as those steps are spelled out, and the releases\ncontain this generated file, I\'m +1 on removing it from git.\n\n\n','<5334860D.1080508@dague.net>',NULL),('<1395956026-sup-3453@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 14:39:08',-25200,'2014-03-27 21:39:08',NULL,'[openstack-dev] [TripleO] proxying SSL traffic for API requests','Excerpts from Nathan Kinder\'s message of 2014-03-27 13:25:02 -0700:\n> On 03/26/2014 09:51 AM, Clint Byrum wrote:\n> > Excerpts from Chris Jones\'s message of 2014-03-26 06:58:59 -0700:\n> >> Hi\n> >>\n> >> We don\'t have a strong attachment to stunnel though, I quickly dropped it in front of our CI/CD undercloud and Rob wrote the element so we could repeat the deployment.\n> >>\n> >> In the fullness of time I would expect there to exist elements for several SSL terminators, but we shouldn\'t necessarily stick with stunnel because it happened to be the one I was most familiar with :)\n> >>\n> >> I would think that an httpd would be a good option to go with as the default, because I tend to think that we\'ll need an httpd running/managing the python code by default.\n> >>\n> > \n> > I actually think that it is important to separate SSL termination from\n> > the app server. In addition to reasons of scale (SSL termination scales\n> > quite a bit differently than app serving), there is a security implication\n> > in having the private SSL keys on the same box that runs the app.\n> \n> There is also a security implication in having network traffic from the\n> SSL terminator to the application in the clear.  If the app is\n> compromised, one could just read all incoming traffic anyway since it is\n> not encrypted.\n> \n\nReading all incoming traffic is a given if the app is compromised in\nthe same way that one might compromise the secret keys. Terminator to\napp server encryption is only to prevent evil on your internal network.\nThat is contained to your own network and thus can be measured and\ncontrolled.\n\nHowever, you don\'t want an attacker who has compromised your app to be\nable to go off and setup their own version of your app using your private\nkey and some simple MITM techniques in a place where you cannot detect\nor control it at all.\n\nThat\'s not to say that terminator<->app encryption is not a good idea\ntoo. But that should be using a separate set of encryption keys to\nmitigate the impact of a compromise to, again, your own network.\n\n\n','<5334891E.1060707@redhat.com>',NULL),('<1395967797.2739.3.camel@changyao-fedora>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-28 08:49:57',28800,'2014-03-28 00:49:57',NULL,'[Openstack] [Question] about test libvirt using OpenStack','On ?, 2014-03-26 at 09:26 -0400, Davanum Srinivas wrote:\n> Hi.\n> \n> here\'s what i did.\n> \n> Step #1: before running devstack, do install the packages required\n> including libvirt-bin and python-libvirt\n> Step #2: stop libvirt service then run autogen.sh, make and make\n> install to replace the libvirt binaries\n> Step #3: fix configuration files of libvirt if necessary, start\n> libvirt bin and make sure everything is running\n> Step #4: now run devstack, when devstack finds that libvirt is already\n> present (from step #1), it will not over-write your compiled binaries\n> \n> Here\'s an example i used to build custom libvirt binaries and run them\n> as part of our gate jobs.\n> https://review.openstack.org/#/c/67564/24/functions.sh,unified\n> \n> -- dims\n\nThanks,it is helpful,OpenStack works well.\n\n> \n> On Wed, Mar 26, 2014 at 8:59 AM, H Changyao <changyaoh at gmail.com> wrote:\n> > Hi,\n> > I am developing a security driver of libvirt , I want to test the new \"security driver\" of libvirt\n> > using OpenStack , I encounter some problem:\n> >\n> > I have known the back-end of OpenStack compute-node is libvirt (but they are independent modules) , I use\n> > DevStack to deploy the OpenStack . I notice that it automatically install \"All packages\" including \"libvirt\",\n> > so I decide to uninstall the \"libvirt packages\" ,then compile and install libvirt , but all after,\n> > when I use the OpenStack dashboard to create Instance , the Task state keep \"scheduling\" ,no forwarding.\n> >\n> > Is the problem in lacking proper libvirt configuration ?\n> > Is there other method to \"integrate\" libvirt to Openstack from src ? or How to deploy and test libvirt using OpenStack ?\n> >\n> > Thanks\n> >\n> > H Changyao\n> >\n> >\n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n\n\n\n\n','<CANw6fcH0fOaB8+g+xbTTsSNqsQp4ywNT+moa-r8x4BBGo1rwgA@mail.gmail.com>',NULL),('<1395968382.53048.YahooMailNeo@web163602.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 17:59:42',-25200,'2014-03-28 00:59:42',NULL,'[openstack-dev] ML2 Type driver for supporting network overlays,\n	with more than 4K seg','Hi Mathieu,\nThanks for your reply.\nYes, \neven i think the type driver code for tunnels can remain the same since \nthe segment/tunnel allocation is not going to change. But some \ndistinction has to be given in the naming or by adding another tunnel \nparameter to signify a network overlay. \nFor tunnels \ntype, br-tun is created. For regular VLAN, br-ex/br-eth has the uplink \nalso as its member port. For this, I was thinking, it\'s easier if we \ndon\'t even create br-tun or VXLAN/GRE end-points since the compute nodes\n (data network in Openstack) is connected through the external fabric. We will just\n have the br-eth/r-ex and its port connecting to the fabric just like if the type was VLAN. If we had \nto do this, the changes has to be in? neutron agent code. \nIs this the right way to go or any\n suggestions?\n\nThanks,\nPaddu\n\n\n\n\nOn Wednesday, March 26, 2014 11:28 AM, Padmanabhan Krishnan <kprad1 at yahoo.com> wrote:\n \nHi Mathieu,\nThanks for your reply.\nYes, even i think the type driver code for tunnels can remain the same since the segment/tunnel allocation is not going to change. But some distinction has to be given in the naming or by adding another tunnel parameter to signify a network overlay. \nFor tunnels type, br-tun is created. For regular VLAN, br-ex/br-eth has the uplink also as its member port. For this, I was thinking, it\'s easier if we don\'t even create br-tun or VXLAN/GRE end-points since the compute nodes (data network in Openstack) is throug the external fabric. We will just have the br-eth/r-ex and its port connecting to the fabric. If we had to do this, the changes has to be in? neutron agent code. \nIs this the right way to go or any\n suggestions?\n\nThanks,\nPaddu\n\n\n\n\n\nOn Wednesday, March 26, 2014 1:53 AM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n \nHi,\n\nthanks for this very interesting use case!\nMay be you can still use VXLAN or GRE for tenant networks, to bypass\nthe 4k limit of vlans. then you would have to send packets to the vlan\ntagged interface, with the tag assigned by the VDP protocol, and this\ntraffic would be encapsulated inside the segment to be carried inside\nthe network fabric. Of course you will have to take care about\n MTU.\nThe only thing you have to consider is to be sure that the default\nroute between VXLan endpoints go through your vlan tagged interface.\n\n\n\nBest,\nMathieu\n\nOn Tue, Mar 25, 2014 at 12:13 AM, Padmanabhan Krishnan <kprad1 at yahoo.com> wrote:\n> Hello,\n> I have a topology where my Openstack compute nodes are connected to the\n> external switches. The fabric comprising of the switches support more than\n> 4K segments. So, i should be able to create more than 4K networks in\n> Openstack. But, the VLAN to be used for communication with the switches is\n> assigned by the switches using 802.1QBG (VDP) protocol. This can be thought\n> of as a network overlay. The VM\'s sends .1q frames to the switches and the\n> switches associate it to the segment (VNI in case of VXLAN).\n> My question is:\n> 1. I cannot use\n a type driver of VLAN because of the 4K limitation. I cannot\n> use a type driver of VXLAN or GRE because that may mean host based overlay.\n> Is there an integrated type driver i can use like an \"external network\" for\n> achieving the above?\n> 2. The Openstack module running in the compute should communicate with VDP\n> module (lldpad) running there.\n> In the computes, i see that ovs_neutron_agent.py is the one programming the\n> flows. Here, for the new type driver, should i add a special case to\n> provision_local_vlan() for communicating with lldpad for retrieving the\n> provider VLAN? If there was a type driver component running in each\n> computes, i would have added another one for my purpose. Since, the ML2\n> architecture has its mechanism/type driver modules in the controller only, i\n> can only make changes here.\n>\n> Please let me know if there\'s already an\n implementation for my above\n> requirements. If not, should i create a blue-print?\n>\n> Thanks,\n> Paddu\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140327/c2a0875b/attachment.html>\n\n','<1395858529.16135.YahooMailNeo@web163603.mail.gq1.yahoo.com>',NULL),('<1396016896.62700.YahooMailNeo@web133102.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 14:28:16',0,'2014-03-28 14:28:16',NULL,'[openstack-dev] [MagnetoDB] Best practices for uploading large\n	amounts of data','Bulk loading with sstableloader is blazingly fast (the price to pay is that\'s not portable of course).?\nAlso it\'s network efficient thanks to SSTable compression. If the network is not a limiting factor then LZ4 will be great.\n\n\n\n\nLe Vendredi 28 mars 2014 13h46, Aleksandr Chudnovets <achudnovets at mirantis.com> a ?crit :\n \nDmitriy Ukhlov wrote:\n\n> I guess if we a talking about cassandra batch loading the fastest way is to generate sstables locally and load it into Cassandra via JMX or sstableloader\n>http://www.datastax.com/dev/blog/bulk-loading\n>\n>\n\n?Good idea, Dmitriy. IMHO bulk load is back-end specific task. So using specialized tools seems good idea for me.\n\nRegards,\nAlexander Chudnovets\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140328/0416270c/attachment.html>\n\n','<CAG23v8BuD4eYmcO-TsNmGXKQY8ptcY6brJDQC0Sb1G7mnEPd7g@mail.gmail.com>',NULL),('<1396024217.2646.29.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 12:30:17',-14400,'2014-03-28 16:30:17',NULL,'[openstack-dev] [Nova] Not running for PTL','On Fri, 2014-03-28 at 09:57 -0400, Russell Bryant wrote:\n> Now that PTL nominations are open for the Juno cycle, it seems\n> appropriate that I should make my intentions clear.  I do not plan to\n> run for PTL this cycle.  Nova PTL is truly a full time job.  I\'m\n> planning to take a month off after the Icehouse release for personal\n> reasons so I feel it\'s best for the project to let someone else take\n> over this time.\n\nA well deserved bit of time off.\n\n> Nova has a strong group of leaders [1] that work together to make the\n> project work.  The nova-core team [2] works hard reviewing code to merge\n> thousands of patches a year without letting the code fall apart.  A\n> subset of nova-core, the nova-drivers [3] team, has gone above and\n> beyond during the Icehouse cycle to help review blueprints to set\n> direction for the project.  Additionally, we have others dedicated to\n> organizing sub-teams [4]. I\'m incredibly thankful for the dedication and\n> leadership of all of these people.\n> \n> Thank you all for the opportunity to serve as the Nova PTL for Havana\n> and Icehouse.  It is truly an honor to work with all of the people that\n> make OpenStack happen.\n\nThank *you*, Russell, for the effort you\'ve put into the PTL job. It is\ntruly a full time job, and you\'ve displayed patience and professionalism\nthroughout your time as PTL.\n\nBest,\n-jay\n\n\n\n','<53357FD3.9090803@redhat.com>',NULL),('<1396025658.097614147@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-03-28 11:54:18',-18000,'2014-03-28 16:54:18',NULL,'[openstack-community] Looking for 1 more volunteer for PyCon\n	OpenStack booth','\nWe had a cancellation, so one spot with a full conference pass is available.  We ask that you are a Python developer working on OpenStack, and can staff the booth for at least two 3.5 hour shifts over Thurs-Sat, April 10-12, to talk to potential new developers for and encourage participation in OpenStack.   Please reply to kathyc at openstack.org.\n \nReminder to all, we also will post OpenStack  jobs on our job board, on site.  Visit booth #310 to complete index cards of your companies\' open positions!  Thank you.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140328/ef4c4ff7/attachment.html>\n\n',NULL,NULL),('<1396034217.2646.37.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 15:16:57',-14400,'2014-03-28 19:16:57',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','On Fri, 2014-03-28 at 13:56 +0100, Belmiro Moreira wrote:\n> +1 for Phil comments.\n> I agree that VMs should spread between different default avzs if user\n> doesn\'t define one at boot time.\n> There is a blueprint for that feature that unfortunately didn\'t make\n> it for icehouse.\n> https://blueprints.launchpad.net/nova/+spec/schedule-set-availability-zones\n\nThat\'s not at all what I\'ve been talking about.\n\nI\'m talking about the concept of EC2 availability zones being improperly\napplied in Nova and leading to wrong expectations of the user. Thus, I\nam proposing to drop the concept of EC2 AZs in the next major API\nversion and instead have a general compute node container that may or\nmay not contain other generic containers of compute nodes.\n\nThe HostAggregate concept in Nova was a hack to begin with (it was\noriginally just XenServer-specific), and then was further hacked to\nallow tagging a host aggregate with an AZ -- ostensibly to expose\nsomething to the end user that could be used to direct scheduler hints.\n\nI\'m proposing getting rid of the host aggregate hack (or maybe evolving\nit?) as well as the availability zone concept and replacing them with a\nmore flexible generic container object that may be hierarchical in\nnature.\n\nBest,\n-jay\n\n\n\n\n\n\n','<CAPkQhnd-Dr8biqtjNh3tp=P9=x=Vj_nsOVyHtScCSTEWgSP0Ww@mail.gmail.com>',NULL),('<1396034951.2646.44.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 15:29:11',-14400,'2014-03-28 19:29:11',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and\n	Host	aggregates..','On Fri, 2014-03-28 at 11:01 +0000, Day, Phil wrote:\n> >> Personally, I feel it is a mistake to continue to use the Amazon concept\n> >> of an availability zone in OpenStack, as it brings with it the\n> >> connotation from AWS EC2 that each zone is an independent failure\n> >> domain. This characteristic of EC2 availability zones is not enforced in\n> >> OpenStack Nova or Cinder, and therefore creates a false expectation for\n> >> Nova users.\n> \n> >I think this is backwards training, personally. I think azs as separate failure\n> >domains were done like that for a reason by amazon, and make good sense. \n> >What we\'ve done is overload that with cells, aggregates etc which should \n> >have a better interface and are a different concept. Redefining well understood \n> >terms because they don\'t suite your current implementation is a slippery slope, \n> >and overloading terms that already have a meaning in the industry in just annoying.\n> \n> +1\n> I don\'t think there is anything wrong with identifying new use cases and working out how to cope with them:\n> \n>  - First we generalized Aggregates\n> - Then we mapped AZs onto aggregates as a special mutually exclusive group\n> - Now we\'re recognizing that maybe we need to make those changes to support AZs more generic so we can create additional groups of mutually exclusive aggregates\n> \n> That all feels like good evolution.\n\nI see your point, though I\'m not sure it was all that good.\n\n> But I don\'t see why that means we have to fit that in under the existing concept of AZs - why can\'t we keep AZs as they are and have a better thing called Zones that is just an OSAPI concept and is better that AZs ?\n\nPhil, that is exactly what I am proposing. For the next major version of\nthe Nova API, introducing a new generic container of compute resources.\n\n>  Arguments around not wanting to add new options to create server seem a bit weak to me \n\nWho has made that argument?\n\n> - for sure we don\'t want to add them in an uncontrolled way, but if we have a new, richer, concept we should be able to express that separately.\n\nWhich is what I\'ve proposed, no?\n\n> I\'m still not personally convinced by the need use cases of racks having orthogonal power failure domains and switch failure domains - that seems to me from a practical perspective that it becomes really hard to work out where to separate VMs so that they don\'t share a failure mode.    Every physical DC design I\'ve been involved with tries to get the different failure domains to align.   However if it the use case makes sense to someone then I\'m not against extending aggregates to support multiple mutually exclusive groups.\n\nMy point is that if we had a concept of a generic container of compute\nresources, then whether or not that container was an independent failure\ndomain or not would simply be an explicit trait of the container. As it\nstands now with availability zones, being an independent failure domain\nis an *implied* trait that isn\'t enforced by Nova, Neutron or Cinder.\n\nBest,\n-jay\n\n> \n> Phil\n>  \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F007006185@G6W2490.americas.hpqcorp.net>',NULL),('<1396036171.2646.54.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 15:49:31',-14400,'2014-03-28 19:49:31',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','On Fri, 2014-03-28 at 19:38 +0000, CARVER, PAUL wrote:\n> Jay Pipes wrote: \n> >I\'m proposing getting rid of the host aggregate hack (or maybe evolving\n> >it?) as well as the availability zone concept and replacing them with a\n> >more flexible generic container object that may be hierarchical in\n> >nature.\n> \n> Is the thing you\'re proposing to replace them with something that already\n> exists or a brand new thing you\'re proposing should be created?\n\nEither an evolution of the host aggregate concept (possibly renamed) or\na brand new concept.\n\n> We need some sort of construct that allows the tenant to be confident that\n> they aren\'t going to lose multiple VMs simultaneously due to a failure of\n> underlying hardware.\n\n? Tenants currently assume this is the case if they are using multiple\navailability zones, but there is nothing in Nova that actually prevents\nmultiple availability zones from sharing hardware.\n\nFrankly, this is an SLA thing, and should not be part of the API, IMO.\nIf a deployer wishes to advertise an SLA that says \"this container of\ncompute resources is a failure domain\", then they should be free to make\nthat SLA and even include it in a description of said generic container\nof compute resource, but there should be no *implicit* SLAs.\n\n>  The semantics of it need to be easily comprehensible\n> to the tenant, otherwise you\'ll get people thinking they\'re protected because\n> they built a redundant pair of VMs but sheer bad luck results in them losing\n> them both at the same time.\n\nUmm, that\'s possible today. There is an implicit trust right now in the\nAPI that availability zones are independent failure domains. And what I\nam telling you is that no such constraint exists in the implementation\nof Nova availability zones (exposed via host aggregate).\n\n> We\'re using availability zone for that currently and it seems to serve the\n> purpose in a way that\'s easy to explain to a tenant.\n\nIt may be easy to explain to a tenant -- simply because of its use in\nAWS. But that doesn\'t mean it\'s something that is real in practice.\nYou\'re furthering a false trust if you explain to tenants that an\navailability zone is an independent failure domain when it can easily\nNOT be an independent failure domain because of the exposure of\navailability zones through the host aggregate concept (which themselves\nmay overlap hardware and therefore spoil the promise of independent\nfailure domains).\n\nThus, we need a different concept than availability zone to expose to\nusers. Thus, my proposal.\n\nBest,\n-jay\n\n\n\n','<A81F249089B6C7479786834457908C600AC94A33@MISOUT7MSGUSR9N.ITServices.sbc.com>',NULL),('<1396036372.2646.57.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-28 15:52:52',-14400,'2014-03-28 19:52:52',NULL,'[openstack-dev] [Cinder]Persistance layer for cinder + taskflow','On Fri, 2014-03-28 at 18:16 +0000, Duncan Thomas wrote:\n> On 28 March 2014 14:38, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n> > An idea that might be good to do is to start off using SQLite as the\n> > taskflow persistence backend.\n> >\n> > Get that working using SQLite files (which should be fine as a persistence\n> > method for most usages) and then after this works there can be discussion\n> > around moving those tables to something like MySQL and the\n> > benefits/drawbacks of doing that.\n> >\n> > What do u think?\n> >\n> > Start small then grow seems to be a good approach.\n> \n> I\'d say at tables to the existing database first, it adds the smallest\n> number of new moving parts, then look at a new database if and only if\n> there seems to be evidence that one is needed. As a systems operator,\n> it is hard enough managing one db let alone N local dbs...\n\nMy suggestion would be to add a new CONF option\n(persistent_db_connection?) that would default to the value of\nCONF.db.connection). That way you default to using the same DB as the\nmain Cinder tables, but automagically provide the deployer with the\nability to handle the taskflow tables separately if they want.\n\nbest,\n-jay\n\n\n\n','<CAOyZ2aH8NxfNsjG4xv6iy1Jdr799qn9X4i+pg2Kim-PV8q3jWQ@mail.gmail.com>',NULL),('<1396144833.21371.100503373.701F2992@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-29 19:00:33',-25200,'2014-03-30 02:00:33',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Hi!\n\nAre there plans for a PGP keysigning party at the Juno Summit in\nAtlanta, similar to the one at the Icehouse summit in Hong Kong?\n\nInspired by the URL at\nhttps://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Icehouse_Summit\nI looked for \nhttps://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\nto discover that that wiki page does not yet exist and I do not have\npermission to create it.\n\n..m\n\n-- \nMark Atwood <me at mark.atwood.name>\n+1-206-604-2198\n\n\n',NULL,NULL),('<1396172695.2734.7.camel@sleepy>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-30 05:44:55',-14400,'2014-03-30 09:44:55',NULL,'[Openstack] project for contribution','On Sun, 2014-03-30 at 10:03 +0400, Andrew Chul wrote:\n> Hello, guys. I\'m Python developer and I guess that I can help\n> OpenStack to develop, but I don\'t know what project to choose. Can\n> anybody help me?\n\nWelcome to the OpenStack community, Andrew!\n\nAs you may have noticed, there\'s a large number of Python projects in\nthe OpenStack ecosystem. I\'m sure many of the projects would be happy to\nhave a new contributor.\n\nDepending on your experience level with Python and your areas of\ninterest, different projects would make more sense. Are you interested\nin computing (virtualization, resource scheduling, any particular\nhypervisor)? Perhaps networking-related areas, like software-defined\nnetworking, load balancing or VPN solutions? Maybe you are interested in\nstorage -- either block storage or object storage? What about\norchestration or metrics collection and analysis? There\'s Python\nprojects that cover all of the above topics and more. It\'s up to you to\nlet us know where your interests lie and then we can help direct you a\nbit.\n\nI would advise hopping onto IRC (Freenode, #openstack-dev channel) and\nchatting with folks there. Each project usually has its own channel\n(e.g. #openstack-nova) where the core contributors of the project hang\nout. Some of those folks can help you answer more specific questions you\nmight have and direct you to things like low-hanging-fruit tagged bugs\nthat might be an easy way for you to get started coding in OpenStack.\n\nAll the best,\n-jay\n\n\n\n','<CAF92aiX_O+KuTO+vyyRNDPTkmPcKuXU7Qx4zmkT=z6mri7r8CA@mail.gmail.com>',NULL),('<1396173707.2734.23.camel@sleepy>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-30 06:01:47',-14400,'2014-03-30 10:01:47',NULL,'[Openstack] [nova][cinder] Question about Nova cells and Global\n Cinder','On Fri, 2014-03-28 at 07:35 +0800, zhangleiqiang at gmail.com wrote:\n> Hi, stackers:\n> \n> I am confused about reading the original BP ([1]) and operation guide\n> of nova-cells, the question as follows:\n> \n> One aim of nova-cells is to allow additional scaling and (geographic)\n> distribution without complicated database or message queue clustering,\n\nI\'m not entirely sure I agree with the geographic distribution part, but\nyes, the idea of Nova cells is to partition a large (>220-250 compute\nnodes, not VMs) deployment of Nova into sub-deployments (cells) that\nhave their own database and message bus.\n\n>  and OpenStack Compute cells are designed to allow running the cloud\n> in a distributed fashion without having to use more complicated\n> technologies, or being invasive to existing nova installations.\n\nHmm, well, distributed is kind of a misgnomer here. All of OpenStack is\ndistributed. The main idea of cells is to scale beyond the theoretical\nlimitations of a \"typical\" database and message queue cluster, and yes,\nNova cells enables you to grow a Nova deployment without buying\nexpensive scale-up hardware to manage increased demand on underlying\ndatabase and message queue resources.\n\n> The typical use case for cells is a cloud with two independent sites\n> with a single API endpoint.\n\nIMO, that is actually not the typical use case for cells. The typical\nuse case (is there one?) is to grow a *single* site\'s number of compute\nnodes greater than the (estimated) scaling capacity of a typical\ndatabase and message queue cluster. \"typical\" and \"estimated\" are just\nthat: one deployer\'s notions of what is a standard database and message\nqueue setup and that deployer\'s experience attempting to push that\ndatabase and MQ setup to its limits.\n\n> However, take cinder into account, it will require Cinder act as a\n> shared service for the two sites?\n\nI don\'t think there is anything in the Cinder or Nova code that prevents\na Cinder service from being shared between two Nova cells -- or even\nNova availability zones (which is, IMO, what you are describing here as\n\"sites\"). This all would depend on what storage backend you are using in\nCinder, the amount of volume space that backend provides and can scale\nto, as well as the contract you are giving your tenants.\n\nThis last point is important. If you allow a tenant to detach a volume\nfrom a VM in one \"site\" and attach it to a VM in another site, then you\nwill need to either have the Cinder database and volume backend shared\nbetween the sites or you will need to have some replication technology\nthat would enable that.\n\nAlternately, you might decide that you are *not* allowing a tenant to do\nthat, but instead you will allow the tenant to *snapshot* the volume and\nlaunch a VM from that snapshot in a different site. This would require\nyou to either share the Glance registry database between those sites or\nreplicate that registry information from one site to another.\n\n> For two independent sites with existing cloud installations, in order\n> to *upgrade* to cells later, we must make sure the storage networks of\n> these sites connected to each other as early as building the two\n> sites?\n\nI don\'t know the answer to this question, unfortunately. I don\'t *think*\nthis is necessary to do from the beginning, but sure, it would be\nhelpful.\n\n> In order to provide shared service for two sites, we must use the\n> storage with geographic distribution? Among current Cinder backend\n> drivers, it seems there are only glusterfs and ceph?\n\nOr provide some replication technology external to Nova, yes.\n\n> Furthermore, I think Cinder need to  provide the \"site-affinity?\n> filter for this scenario, does it?\n\nYes, you would enable that filter for Cinder, but I am not entirely sure\nif Cinder understands the concept of Nova\'s cells, or whether the Nova\ncells code \"fudges\" the \"site\" to be the availability zone plus some\ncell identifier...\n\nBest,\n-jay\n\n\n\n\n','<2DC6A5A9-57BD-4C28-B986-33364B42BD65@gmail.com>',NULL),('<1396187195.27781.0.camel@sleepy>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-30 09:46:35',-14400,'2014-03-30 13:46:35',NULL,'[Openstack] project for contribution','On Sun, 2014-03-30 at 14:03 +0400, Andrew Chul wrote:\n> Hello, Jay,\n> thank you very much for detailed explanation. Well, primarily, I\'m web\n> developer and areas of my interests is in web and databases range (as\n> I understood, these are Horizon and Trove). But, since I want to take\n> part in Open Source development, I\'m ready to learn and become more\n> familiar with other areas, such as virtualisation and resource\n> scheduling.\n\nThe Horizon community sounds like it\'s right up your alley. Hop on to\n#openstack-horizon on Freenode and chat with folks there. They should be\nable to direct you to some starter tasks or bugs to get you going.\n\nAll the best,\n-jay \n\n\n\n','<CAF92aiVCuX9zd_kw8z8_g+Y=KK03eSujcHCPbxBtPmre3oP74A@mail.gmail.com>',NULL),('<1396192071-sup-7579@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-30 09:05:51',-25200,'2014-03-30 16:05:51',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Excerpts from Thomas Goirand\'s message of 2014-03-29 23:32:55 -0700:\n> On 03/30/2014 10:00 AM, Mark Atwood wrote:\n> > Hi!\n> > \n> > Are there plans for a PGP keysigning party at the Juno Summit in\n> > Atlanta, similar to the one at the Icehouse summit in Hong Kong?\n> > \n> > Inspired by the URL at\n> > https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Icehouse_Summit\n> > I looked for \n> > https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> > to discover that that wiki page does not yet exist and I do not have\n> > permission to create it.\n> > \n> > ..m\n> \n> If there\'s none, then we should do one.\n> \n> One thing about last key signing party, is that I didn\'t really like the\n> photocopy method. IMO, it\'d be much much nicer to use a file, posted\n> somewhere, containing all participant fingerprints. To check for that\n> file validity, together, we check for its sha256 sum (someone say it out\n> loud, while everyone is checking for its own copy). And everyone,\n> individually, checks for its own PGP fingerprint inside the file. Then\n> we just need to validate entries in this file (with matching ID documents).\n> \n> Otherwise, there\'s the question of the trustability of the photocopy\n> machine and such... Not that I don\'t trust Jimmy (I do...)! :)\n> \n\nIf we follow either of these methods:\n\nhttp://keysigning.org/methods/sassaman-efficient\nhttp://keysigning.org/methods/sassaman-projected\n\nThen everyone should bring their own copy of the file. Note that this\nimplies that one is using their own trusted equipment to do this or\nverifying painfully that nothing has been altered during that process.\n\nSo it is important that we socialize this and have people ready _before_\nthe summit, so they can print at home. The point is, users should still\n_print it themselves_ to avoid a mass compromise of the key signing\nprocess at the time of duplication/printing.\n\nNow, having somebody else print the lists is fine as long as you have key\nowners look at your copy and verify the fingerprint on your list. This is\n_extremely_ inefficient compared to the Sassaman Efficient protocol, but\nit works o-k for small groups, as the person can verify your list while\nyou\'re verifying their government ids, and you can do the same for them.\n\nI would suggest making these photocopies on an odd color of paper so\nthat key owners can know to ask for the list to verify it, rather than\nletting unknowing lazy signers get away with trusting the photocopy.\n\n> Plus having a text file with all fingerprints in it is more convenient:\n> you can just cut/past the whole fingerprint and do gpg --recv-keys at\n> once (and not just the key ID, which is unsafe because prone to\n> brute-force). That file can be posted anywhere, provided that we check\n> for its sha256 sum.\n> \n> I would happily organize this, if someone can find a *quite* room with\n> decent network. Who can take care of the place and time?\n> \n\nThere is zero network necessary for the party. In fact it is sort of\ndiscouraged, as having network would distract from the single-minded\nand very social purpose of the party. Or are you requesting a room to\ndo the list creation?\n\n> Of course, We will need need the fingerprints of every participant in\n> advance, so the wiki page would be useful as well. I therefore created\n> the wiki page:\n> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> \n\nThanks!!\n\n> Please add yourself. We\'ll see if I can make it to Atlanta, and organize\n> something later on.\n> \n\nDone. I\'m happy to pick up facilitation of this process if you can\'t\nmake it.\n\n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n\n\n','<5337BA97.8070109@debian.org>',NULL),('<1396254019.25306.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 09:20:19',3600,'2014-03-31 08:20:19',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','Hi Paul,\n\nthe OVSInterfaceDriver creates interfaces with type internal so agents like DHCP/L3 etc can put IP addresses on them. But I don\'t think type internal will work for instances. You could try subclassing and overriding so it does not do this:\n\n?https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150\n\nRegards,\nDarragh.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/78f29a79/attachment.html>\n\n',NULL,NULL),('<1396272370.18032.YahooMailNeo@web172403.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 14:26:10',3600,'2014-03-31 13:26:10',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','Hi Paul,\n\ntbh I\'m not exactly sure what you are trying to do overall. But from your script it seems to me that you are trying to create an OVS port so a libvirt instance outside of Nova control can use it. And you don\'t need the linux bridge for security group iptables.\n\nAFAIK the tap must be created first using the ip command. Then when \'ovs-vsctl add-port\' is called with the same name as the tap device for the port name, the tap device will be enslaved properly in the OVS bridge.\n\nhttps://github.com/openstack/nova/blob/304df046eaaad6d64ee16898b1eaa76918e98878/nova/virt/libvirt/vif.py#L420-L423\n\nRegards, Darragh.\n\nOn Monday, 31 March 2014, 12:36, Paul Michali (pcm) <pcm at cisco.com> wrote:\n \nHi Darragh, \n>\n>\n>Can you elaborate on what the ?set interface? arguments do in OVS? Just trying to understand why it is not desired, when plugging into this interface (note I have a management interface on the br-int and it works fine?this one, which is also on br-int, but needs to tie to the existing ?private? network that devstack sets up, does not work.\n>\n>\n>Regards,\n>\n>\n>PCM (Paul Michali)\n>\n>\n>MAIL ?..?. pcm at cisco.com\n>IRC ??..? pcm_ (irc.freenode.com)\n>TW ???... @pmichali\n>GPG Key ? 4525ECC253E31A83\n>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>\n>\n>\n>\n>On Mar 31, 2014, at 4:20 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com> wrote:\n>\n>Hi Paul,\n>>\n>>the OVSInterfaceDriver creates interfaces with type internal so agents like DHCP/L3 etc can put IP addresses on them. But I don\'t think type internal will work for instances. You could try subclassing and overriding so it does not do this:\n>>\n>>?https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150 \n>>\n>>\n>>Regards,\n>>Darragh.\n>>\n_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/ff890585/attachment.html>\n\n','<13EAB242-13D4-4F20-B8EF-54904D939E9E@cisco.com>',NULL),('<1396277209.15557.12.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 14:46:51',0,'2014-03-31 14:46:51',NULL,'[openstack-dev] [Designate] Atlanta Summit Design Session','Hi All,\n\nThe design summit this year has allowed \'Other Projects\' (ie non incubated projects) to book design sessions.\n\nIs there any interest in trying to get a session in Atlanta?\n\nIf people are interested I can do an application for Designate.\n\nCheers,\n\nGraham\n\n',NULL,NULL),('<1396283140.45488.YahooMailNeo@web172406.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 17:25:40',3600,'2014-03-31 16:25:40',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','\n\nok, good to hear you are making progress. From the variable names in the script - ifname=$IFNAME_ETH2,vlan=2 - it sounds like this is a Neutron provider network. If so, then it should be possible to bridge the VM to the link with with a simple Linux bridge, without the need for a Neutron port and OVS/br-int.\n\n\n\n','<05DE6916-605E-4893-867F-7F6ABEDCCFE4@cisco.com>',NULL),('<1396284938.5157.19.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-31 09:55:38',-25200,'2014-03-31 16:55:38',NULL,'[Openstack-operators] Atlanta Summit - More Ops? ;)','Good points, Jonathan. I\'ve added some comments inline...\n\nOn Mon, 2014-03-31 at 10:35 -0400, Jonathan Proulx wrote:\n> Some Monday morning pre-coffee thoughts\n> \n> On Sun, Mar 30, 2014 at 10:15 PM, Tom Fifield <tom at openstack.org> wrote:\n> \n> > So, my reading is we already have such governance established - but rather\n> > than being an individual, it is a committee - the user committee. We\'ll need\n> > to tweak it a bit I guess, but in fact it is already set up such that the TC\n> > _must_[1] listen to it ... for at least four hours per year ;)\n> \n> That\'s definitely a front runner in my mind, cheers to all the hard\n> work the existing committee have done around surveys, the expanded\n> operations track and everything else.\n> \n> I do think it\'s a bit confusingly named & that this stems from a\n> fundamental flaw in OpenStack community though, that there are two\n> parts of the community, \"Developers\" and \"Users\" and that \"User\" means\n> someone who deploys and maintains cloud infrastructure.\n> \n> As I see it there\'s (at least) three major community segments, from\n> smallest to largest:\n> \n> * Developer, who write the code\n> * Operators/Administrators/(pick your title), who build and maintain\n> production clouds\n> * Users who actually deploy applications on top of the cloud\n> \n> Obviously many individuals and organizations fall into multiple\n> categories and within \"Users\" as writ above there\'s a variety of\n> constituencies that could be broken out.\n\nI actually think it is important to segregate the Operators group from\nthe Administrators group, for one main reason. The activities that each\nperforms are fundamentally different.\n\nWhile it is true that for smaller installations, the individuals doing\noperator and admin work are the same people, the work that operators and\nadmins do is quite different.\n\nOperators spend time:\n\n * deploying and configuring hardware\n * configuring network switches and routing tables\n * installing and configuring OpenStack infrastructure services\n * performing upgrades\n * adding new compute nodes or cells to the deployment\n * running database schema migrations\n * fighting with whatever configuration management tool they use\n\nWhilst admins spend time:\n\n * managing quotas\n * tracking capacity\n * monitoring service availability\n * setting up host aggregates\n * creating new instance types\n * un-doing user\'s problematic actions\n * enabling or disabling services\n\nI believe that one of the problems that the OpenStack Compute API has is\nthat it lumps all users -- end users, admins, and operators -- together.\nThe same API that allows an end user to launch an instance exposes\nresource endpoints for an admin to create flavors and host aggregates\nand resource endpoints for an operator to add new compute nodes to the\ndeployment.\n\nIn other words, the API is unfocused and thus, IMO, less effective at\nimparting value to the targeted audience (because the audience is so\nwell, untargeted).\n\nI think it would be of value to begin segregating the APIs and the ways\nin which we communicate with each group. Users building cloud apps on an\nOpenStack API should be treated differently than the operator struggling\nto migrate a database schema between major releases of OpenStack.\n\nBest,\n-jay\n\n> In terms of Governance do the \"User Committee\" cover all that is not\n> dev?  That\'s really a huge amount of ground to cover and I do think\n> they\'ve done a great job of it, especially on the ops side as\n> evidenced by this discussion, and I can see they\'re reaching out more\n> to the end users as well or starting to.\n> \n> I\'d be interested to hear what those who\'ve been doing the job think\n> needs to be done to scale out and cover the whole constituency? More\n> member, more volunteer staff, sub-committees, distinct operators and\n> end user committees, or perhaps the existing structure is sufficient?\n> \n> > Thoughts? What would you see this group doing?\n> \n> I think the user surveys have been very valuable in seeing how\n> OpenStack is used in the wild, continuing that and refining the\n> questions so we can identify community priorities is a worthy goal and\n> an ongoing task that should definitely be continued.\n> \n> Facilitating the organization of summit tracks & possible inter-summit\n> ops gatherings is another I think we have broad agreement on as that\n> seems to be happening.\n> \n> Do we want to produce tangible best practices or example architectures\n> possibly by inviting in existing configuration management tools?  That\n> maybe a reach both in terms of our time availability and the interest\n> of the people who are doing that work now to come in under a new\n> umbrella.  If that, or something like that were our goal then a PTL\n> type structure would probably make more sense.\n> \n> -Jon\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<CABZB-sie=pMG_76sD-fqtexkfW=KzqjXgPK3EU4C56Eua5gB3w@mail.gmail.com>',NULL),('<1396287577.43673.YahooMailNeo@web163004.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 10:39:37',-25200,'2014-03-31 17:39:37',NULL,'[openstack-dev] [Neutron] Dynamic Routing Blueprint Updated','Hi team.\n\nThe dynamic routing blueprint has been updated to reflect the feedback \nreceived during L3 subteam meetings over the last few weeks. The \nblueprint is registered here: https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing, and the full specification is available here: \nhttps://docs.google.com/a/midokura.com/document/d/1wUcgL6ZTqB14DsiNvGaA1Ao2Try5i5E7_VAzcavzTbY/edit.\n\nSincerely,\nArtem Dmytrenko\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/5ca33969/attachment.html>\n\n',NULL,NULL),('<1396295459.859.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 12:50:59',-25200,'2014-03-31 19:50:59',NULL,'[openstack-dev] ML2 Type driver for supporting network overlays,\n	with more than 4K seg','Hi Mathieu,\nThanks for the link. Some similarities for sure. I see Nova libvirt being used. I had looked at libvirt earlier.\n\nFirstly, the libvirt support that Nova uses to communicate with LLDPAD doesn\'t have support for the latest 2.2 standard. The support is also only for the VEPA mode and not for VEB mode. It\'s also quite not clear as how the VLAN provided by VDP is used by libvirt to communicate it back to Openstack.\nThere\'s already an existing blueprint where i can add more details (https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support)\n\nEven for a single physical network, you need more parameters in the ini file. I was thinking of Host or Network Overlay with or w/o VDP for Tunnel mode. I will add more to the blueprint.\n\nThanks,\nPaddu\n\nOn Friday, March 28, 2014 8:42 AM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n \nHi,\n\n\nthe more I think about your use case, the more I think you should\ncreate a BP to have tenant network based on interfaces created with\nVDP protocol.\nI\'m not a VDP specialist, but if it creates some vlan back interfaces,\nyou might match those physical interfaces with the\nphysical_interface_mappings parameter in your ml2_conf.ini. Then you\ncould create flat networks backed on those interfaces.\nSR-IOv use cases also talk about using vif_type 802.1qbg :\nhttps://wiki.openstack.org/wiki/Nova-neutron-sriov\n\n\n\nMathieu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/090f10c1/attachment.html>\n\n','<CAAfiWQrujhmRWTfSGgmeq0UsxJCvD_sGN3dLRkgOS1zww+MT6A@mail.gmail.com>',NULL),('<1396301922-sup-8299@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 14:45:20',-25200,'2014-03-31 21:45:20',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Excerpts from Jeremy Stanley\'s message of 2014-03-31 13:03:28 -0700:\n> On 2014-03-31 10:55:06 +0200 (+0200), Thierry Carrez wrote:\n> > No miracle here... All slots are pretty full as expected. I think our\n> > best bet is still the 30-min morning break on Wednesday or Thursday at\n> > 10:30am.\n> \n> Would finding an available room for an hour sometime on Monday make\n> sense instead? Since we don\'t have design sessions that day, it\n> might make it easier to collect some majority of interested ATCs for\n> longer than we can cram into a 30-minute break. On the other hand it\n> will potentially conflict with some other operations and general\n> conference stuff, so we end up leaving out people who might be doing\n> those things instead...\n\nWould it be entirely out of line to take a portion of an infra-team\nsession to do this? A lot of keys can be signed in 30 minutes.\n\n* You will have the most important people in the WoT for OpenStack in\n  that room. This will ensure that the signing is extremely relevant.\n* The projection method will be available.\n* This seems relevant to OpenStack development infrastructure.\n\nIf not, then taking over a session room directly after any day of the\nevent has been the most successful strategy I\'ve seen at open source\nconferences. It needs to be relatively soon after everything ends so that\npeople can still get to their respective plans.\n\nIf we can\'t commandeer a session, I\'ll go down the path of contacting\nthe conference/summit organizers to see if that is possible.\n\n\n','<20140331200327.GI17131@yuggoth.org>',NULL),('<1396325294.2988.5.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 14:08:14',36000,'2014-04-01 04:08:14',NULL,'[openstack-dev] [Keystone] python-keystoneclient v3\n functionality','On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote:\n> Hi all,\n> \n> \n> I am sorry if this has been discussed before, the question is will we\n> support keystone v3 operation\n> in python-keystoneclient? I know most of the v3 functionality have\n> been implemented in python-openstackclient, but from the\n> python-openstackclient wiki says, it\'s primarily a wrapper of\n> python-*client, and provides unified interface to user. The end user\n> uses python-keystoneclient to manage\n> user, tenant, service before, if we don\'t intend to support v3\n> functionality in keystoneclient, then \n> it means we force end user to change from keystoneclient to\n> openstackclient, is this what we want to\n> do?\n> \n\nIt depends what you mean by python-keystoneclient. \n\nIf you mean the python library then yes it supports the V3 API already. \n\nIf you mean the keystone CLI that is currently bundled as part of the\npython-keystoneclient then yes that is deprecated in favour of\npython-openstackclient. \n\nWe will maintain the CLI application in keystoneclient however even for\nV2 API calls I recommend that you use the openstack CLI tool.\n\nJamie\n\n> \n> -- \n> Tang Yaguang\n> \n> \n> Canonical Ltd. | www.ubuntu.com | www.canonical.com\n> Mobile:  +86 152 1094 6968\n> gpg key: 0x187F664F\n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CA+GwYPdTAiJrH44Vdu_v=nMKmkY+Psokqe0yG0u+uZ3iDc+kBA@mail.gmail.com>',NULL),('<1396340846.89956.YahooMailNeo@web124705.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-01 01:27:26',-25200,'2014-04-01 08:27:26',NULL,'[Openstack] [Heat] Unable to get heat multicloud working','Hi\n\nCan anyone share the instructions or the heat config file to get heat working\nwith multiple external clouds ? I\'m not able to find any good documentation to get multicloud working and my\ntrials have failed till now. Although I\'m able to get it working for a single external cloud by following the\ninstructions mentioned here\n-http://docs.openstack.org/developer/heat/getting_started/standalone.html I enabled multi_cloud in heat.conf [auth_password]\n#\n# Options defined in heat.common.config\n# # Allow orchestration of multiple clouds. (boolean value)\nmulti_cloud=true # Allowed keystone endpoints for auth_uri when multi_cloud is\n# enabled. At least one endpoint needs to be specified. (list\n# value)\nallowed_auth_uris=[\'http://192.168.122.3:5000/v2.0\',\n\'http://192.168.122.4:5000/v2.0\'] Running heat CLI throws \'401 unauthorized\' error #heat --os-no-client-auth --heat-url http://192.168.122.171:8004/v1/f2b833cd5c754c3ab5095c45d1049ec1 --os-username\nadmin --os-password e4c65c1a86764776 --os-tenant-name admin --os-auth-url http://192.168.122.3:5000/v2.0 stack-list ERROR: 401 Unauthorized This server could not verify that you are authorized to access the document you\nrequested. Either you supplied the wrong credentials (e.g., bad password), or\nyour browser does not understand how to supply the credentials required. Header X-Auth-Url \"http://192.168.122.3:5000/v2.0\" not an allowed endpoint\n\n?\nRegards,\n\nPradipta Banerjee (bpradip at in.ibm.com)\n\nIBM Systems & Technology Labs,\n\nIndia.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140401/daf43969/attachment.html>\n\n','<1396333963.25027.YahooMailNeo@web124705.mail.ne1.yahoo.com>',NULL),('<1396351754.21.1387001163196.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-14 06:06:03',0,'2013-12-14 06:06:03',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-cinder-docs-havana #9','See <https://jenkins02.openstack.org/job/periodic-cinder-docs-havana/9/changes>\n\n\n\n','<693046549.7.1386915532300.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1396355401.5227.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 13:30:01',3600,'2014-04-01 12:30:01',NULL,'[openstack-dev] oslo.messaging 1.3.0 released','Hi\n\noslo.messaging 1.3.0 is now available on pypi and should be available in\nour mirror shortly.\n\nFull release notes are available here:\n\n  http://docs.openstack.org/developer/oslo.messaging/\n\nThe master branch will soon be open for Juno targeted development and\nwe\'ll publish 1.4.0aN beta releases from master before releasing 1.4.0\nfor the Juno release.\n\nA stable/icehouse branch will be created for important bugfixes that\nwill be released as 1.3.N.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1396362263.12156.1.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 14:24:28',0,'2014-04-01 14:24:28',NULL,'[openstack-dev] [Designate] Atlanta Summit Design Session','This has been applied for - the description is here:\nhttp://summit.openstack.org/cfp/details/196\n\nIt hasn\'t been reviewed yet, so if you see anything you would like to\nchange, let me know.\n\nGraham\n\nOn Mon, 2014-03-31 at 16:35 +0000, Betsy Luzader wrote:\n\n> Graham,\n> \n> I\'m definitely interested in a design session. Thanks for offering to put\n> in the application.\n> \n> FYI, most of us from Rackspace get in late morning on Monday and are\n> leaving early afternoon on Friday.\n> \n> Thanks again,\n> \n> Betsy\n> \n> On 3/31/14 9:46 AM, \"Hayes, Graham\" <graham.hayes at hp.com> wrote:\n> \n> >Hi All,\n> >\n> >The design summit this year has allowed \'Other Projects\' (ie non\n> >incubated projects) to book design sessions.\n> >\n> >Is there any interest in trying to get a session in Atlanta?\n> >\n> >If people are interested I can do an application for Designate.\n> >\n> >Cheers,\n> >\n> >Graham\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/1f10d87e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/1f10d87e/attachment.pgp>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/x-pkcs7-signature\nSize: 6961 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/1f10d87e/attachment.bin>\n\n','<CF5F02C2.60914%betsy.luzader@rackspace.com>',NULL),('<1396381719-sup-5101@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 12:52:05',-25200,'2014-04-01 19:52:05',NULL,'[openstack-dev] [marconi] [macaroni] Proposal: change name of\n	Marconi to Macaroni','Excerpts from Solly Ross\'s message of 2014-04-01 10:19:12 -0700:\n> Hello All,\n> \n> As OpenStack Marconi grows, I think it\'s time we addressed the question on everyone\'s mind:\n> why isn\'t the project called OpenStack Macaroni?\n> \n> There are several compelling reasons to change Marconi\'s name to Macaroni:\n> \n> 1. Macaroni, being tube-shaped, exemplify the concept of connecting various services such\n>    that messages (cheese sauce) can flow between them.  Remember, the internet is in fact\n>    a series of tubes.\n> \n> 2. Everyone reads the name as Macaroni the first time they see it, anyway.\n> \n> 3. Everyone knows what Macaroni are, while many people do not know who Marconi is.\n>    People unable to access Wikipedia in a timely manner will greatly benefit from\n>    the name change, since they will be able to instantly recognize what Marconi/Macaroni\n>    provides to the OpenStack project (see #1).\n> \n> 4. Only robots dislike Macaroni and Cheese.  Therefore, by holding a vote, we can\n>    identify who is, in fact, a robot, and summarily destroy them before they are\n>    able to orchestrate a SkyNet-inspired uprising.\n> \n> Therefore, in the name of clarity, hilarity, and the prevention of robot apocalypses,\n> I call for a vote to change the name of the OpenStack Marconi project\n> to OpenStack Macaroni.  The vote should probably be held after OpenStack Summit,\n> so that we can discuss the potential name change in a Summit session.\n> \n\nAs a flying spaghetti monsterist[1] I praise this move to exhalt pasta\nin OpenStack. Ramen.\n\n\n[1] http://en.wikipedia.org/wiki/Flying_Spaghetti_Monster\n\n\n','<311593061.5525897.1396372752621.JavaMail.zimbra@redhat.com>',NULL),('<1396460170205.b2097597@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 10:36:10',-25200,'2014-04-02 17:36:10',NULL,'[openstack-dev] [Tuskar][Horizon] Javascript linter','On my phone so I can\'t follow this up more now, but it looks like JSHint is already used.\n\n\nhttps://review.openstack.org/#/c/41087/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/e39009d5/attachment.html>\n\n','<812115887.3176478.1396430614532.JavaMail.zimbra@redhat.com>',NULL),('<1396462281.3019.32.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 13:11:21',-18000,'2014-04-02 18:11:21',NULL,'[openstack-dev] [All][Keystone] Deprecation of the v2 API','On Wed, 2014-04-02 at 17:08 +0000, Tim Bell wrote:\n> I?ve added the depreciation process to the section on meet the PTLs/TC\n> for the Atlanta Ops unconference\n> (https://etherpad.openstack.org/p/ATL-ops-unconference-RFC).\n> Currently, it is difficult to tell how much a particular feature is\n> being used and the impact of depreciation.\n\nExercising my penchant for precision: \"depreciation\" or \"deprecation\"?\nI hope that the openstack code base isn\'t depreciating, even if parts of\nit are being deprecated :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9AE4F96@CERNXCHG41.cern.ch>',NULL),('<1396471948009.7bd162af@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-02 13:52:28',-25200,'2014-04-02 20:52:28',NULL,'[Openstack] [Trove] Trove interface','Is there documentation? Can you share links?\n\n\nThanks!\n\nOn Wed, Apr 2, 2014 at 4:25 PM, Hopper, Justin <justin.hopper at hp.com>\nwrote:\n\n> Ali,\n> Please let us know what where you see opportunities for improvement with\n> Trove documentation.\n> Thanks,\n> Justin Hopper\n> Software Engineer - DBaaS\n> irc: juice | gpg: EA238CF3 | twt: @justinhopper\n> From:  Ali Nazemian <alinazemian at gmail.com>\n> Date:  Wednesday, April 2, 2014 at 9:37\n> To:  Akihiro Motoki <amotoki at gmail.com>\n> Cc:  openstack <openstack at lists.openstack.org>\n> Subject:  Re: [Openstack] Trove interface\n> Thank you very much but why the documentation for trove is so poor?\n> On Mon, Mar 31, 2014 at 5:50 PM, Akihiro Motoki <amotoki at gmail.com> wrote:\n>> Hi Ali,\n>> \n>> Horizon Icehouse release which is coming soon support Trove.\n>> If keystone has Trove endpoint, Trove support in Horizon will be\n>> enabled automatically.\n>> \n>> On Sun, Mar 30, 2014 at 5:35 AM, Ali Nazemian <alinazemian at gmail.com> wrote:\n>>> > Hi,\n>>> > I recently got familiar with trove, I want to know that is there any\n>>> > interface (web interface) available for using trove or just the trove\n>>> > command line is considered for this purpose?\n>>> > Regards.\n>>> >\n>>> > --\n>>> > A.Nazemian\n>>> >\n>>> > _______________________________________________\n>>> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> > Post to     : openstack at lists.openstack.org\n>>> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> >\n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> -- \n> A.Nazemian \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140402/0225c445/attachment.html>\n\n','<CF61BE7A.1070D%justin.hopper@hp.com>',NULL),('<1396476757-sup-4489@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 15:24:12',-25200,'2014-04-02 22:24:12',NULL,'[openstack-dev] [Heat] [Murano] [Solum] applications in the\n	cloud','Excerpts from Ruslan Kamaldinov\'s message of 2014-04-02 14:39:17 -0700:\n> This is a continuation of the \"MuranoPL questions\" thread.\n> \n> As a result of ongoing discussions, we figured out that definition of layers\n> which each project operates on and has responsibility for is not yet agreed\n> and discussed between projects and teams (Heat, Murano, Solum (in\n> alphabetical order)).\n> \n> Our suggestion and expectation from this working group is to have such\n> a definition of layers, agreement on it and an approach of reaching it.\n> \n> As a starting point, we suggest the following:\n> \n> There are three layers of responsibility:\n> 1. Resources of the cloud\n> 2. Applications of the cloud\n> 3. Layers specific for Murano and Solum (to be further discussed and\n>    clarified, for this discussion it\'s out of scope)\n> \n> Layer 1 is obviously covered by Heat.\n> \n> Most of the disagreement is around layer 2. Our suggestion is to figure out\n> the way where we can have common engine, DSL and approach to apps description.\n> For this we\'ll take HOT and TOSCA as a basis and will work on addition of\n> functionality missing from Murano and Solum point of view.\n> \n> We\'ll be happy if existing Heat team continue working on it, having the full\n> control of the project, provided that we agree on functionality missing there\n> from Murano and Solum point of view and addition of this functionality in a\n> systematic way.\n> \n> Let me outline the main concern in regards to HOT from Murano perspective.\n> Others concerns could be figured out later. The typical use case for Murano is\n> the following:\n> Application writer sets a requirement for her application to use RDBMS\n> assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able\n> to understand such requirements and be able to satisfy them by instantiating\n> instances with DB. End user should be able to control which particular type of\n> DB should be used. This is quite similar to abstract requirements described in\n> TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is\n> pretty well aligned with what HOT\\TOSCA can provide.\n> \n\nIMO that is too high level for Heat. Heat speaks to APIs. It has a few of\nits own that are low-level generic facilities, or high level left-over\'s\nfrom the early days that all have better native replacements.\n\nIf there is no API to get a PostgreSQL or MSSQL database, then there is\nno PostgreSQL or MSSQL database for Heat. What there may be is an API to\nget a server and configure it. And Providers can handle the abstraction.\nHowever,Heat isn\'t specifically going to ever know how one resource is\ngoing to depend on another. It is just going to obey your commands to\ncreate them and share configuration between them.\n\nMeanwhile, Trove is the place to drive database as a service features.\n\n> \n> Hopefully this functionality can be introduced into HOT. Solum and Murano will\n> leverage it by using some common API, and implementing layer 3 as thin as\n> possible.\n> \n\nI\'m not really sure what is missing from HOT that you need. With\nproviders you should be able to achieve anything you need around\nportability.\n\n\n','<CAPW-O+Gzs0YwR+tv6Rpr7MHSf5wL=TP6Bw-6J_okS2MT6p+11Q@mail.gmail.com>',NULL),('<1396542147.19248.10.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 09:22:27',-25200,'2014-04-03 16:22:27',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 15:02 +0000, Cazzolato, Sergio J wrote:\n> Hi All, \n> \n> I?d like to know your thoughts regarding Quota Management? I?ve been\n> contributing to this topic for icehouse and noticed some issues and\n> discussions around its implementation like code is duplicated, synch\n> problems with database, not having an homogeneous logic, etc? so I was\n> thinking that maybe a centralized implementation could be a solution\n> for this? As far as I know there was a discussion during the last\n> summit and the decision was to use Keystone for a Centralized Quota\n> Management solution but I don?t have the details on that discussion?\n> Also I was looking at Boson (https://wiki.openstack.org/wiki/Boson)\n> that seems to be a nice solution for this and also addresses the\n> scenario where Nova is deployed in a multi-cell manner and some other\n> interesting things.\n\nBoson does indeed look interesting, but who is working on it, if anyone\nat this point? I agree that having a centralized quota management system\nmakes sense, in order to make the handling of quotas and reservations\nconsistent across projects as well as to deal with global quota\nmanagement properly (i.e. quotas that span multiple cells/AZs)\n\nBest,\n-jay\n\n\n\n\n\n','<F576D72DA1DB704E976755DC5ADB05743FA06DC4@fmsmsx111.amr.corp.intel.com>',NULL),('<1396544505-sup-5408@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 10:04:55',-25200,'2014-04-03 17:04:55',NULL,'[openstack-dev] [heat] metadata for a HOT','Excerpts from Thomas Spatzier\'s message of 2014-04-03 08:36:20 -0700:\n> > From: Mike Spreitzer <mspreitz at us.ibm.com>\n> > To: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n> > <openstack-dev at lists.openstack.org>\n> > Date: 03/04/2014 07:10\n> > Subject: Re: [openstack-dev] [heat] metadata for a HOT\n> >\n> > Zane Bitter <zbitter at redhat.com> wrote on 04/02/2014 05:36:43 PM:\n> >\n> > > I think that if you\'re going to propose a new feature, you should at\n> > > least give us a clue who you think is going to use it and what for ;)\n> >\n> > I was not eager to do that yet because I have not found a fully\n> > satisfactory answer yet, at this point I am exploring options.  But\n> > the problem I am thinking about is how Heat might connect to a\n> > holistic scheduler (a scheduler that makes a joint decision about a\n> > bunch of resources of various types).  Such a scheduler needs input\n> > describing the things to be scheduled and the policies to apply in\n> > scheduling; the first half of that sounds a lot like a Heat\n> > template, so my thoughts go in that direction.  But the HOT language\n> > today (since https://review.openstack.org/#/c/83758/ was merged)\n> > does not have a place to put policy that is not specific to a\n> singleresource.\n> \n> I think you bring up a specific use case here, i.e. applying \"policies\" for\n> placement/scheduling when deploying a stack. This is just a thought, but I\n> wonder whether it would make more sense to then define a specific extension\n> to HOT instead of having a generic metadata section and stuffing everything\n> that does not fit into other places into metadata.\n> \n\nEver read about Larry \"no modes\" Tesler? Read up on his arguments\nagainst modes.\n\nI would much prefer any policies to be actual resources which the\nresources interact with, rather than template wide modes.\n\n> I mean, the use case Keith brought up are completely different (UI and user\n> related), and I understand both use cases. But is the idea to put just\n> everything into metadata, or would different classes of use cases justify\n> different section? The latter would enforce better documentation of\n> semantics. If everyhing goes into a metadata section, the contents also\n> need to be clearly specified. Otherwise, the resulting template won\'t be\n> portable. Ok, the standard HOT stuff will be portable, but not the\n> metadata, so no two users will be able to interpret it the same way.\n>\n\nWe had a fairly long debate about keywords and meta-information in HOT\nand I thought we came to the conclusion that it belongs in the API and\nnot in the template language.\n\n\n','<OF7BD6892D.E3819D26-ONC1257CAF.00552634-C1257CAF.0055B99C@de.ibm.com>',NULL),('<1396544702-sup-4815@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 10:10:30',-25200,'2014-04-03 17:10:30',NULL,'[openstack-dev] [heat] metadata for a HOT','Excerpts from Mike Spreitzer\'s message of 2014-04-02 22:10:21 -0700:\n> Zane Bitter <zbitter at redhat.com> wrote on 04/02/2014 05:36:43 PM:\n> \n> > I think that if you\'re going to propose a new feature, you should at \n> > least give us a clue who you think is going to use it and what for ;)\n> \n> I was not eager to do that yet because I have not found a fully \n> satisfactory answer yet, at this point I am exploring options.  But the \n> problem I am thinking about is how Heat might connect to a holistic \n> scheduler (a scheduler that makes a joint decision about a bunch of \n> resources of various types).  Such a scheduler needs input describing the \n> things to be scheduled and the policies to apply in scheduling; the first \n> half of that sounds a lot like a Heat template, so my thoughts go in that \n> direction.  But the HOT language today (since \n> https://review.openstack.org/#/c/83758/ was merged) does not have a place \n> to put policy that is not specific to a single resource.\n> \n\nThings that affect the stack as a whole really belong in the stack\nAPI. That would also put them in the OS::Heat::Stack resource, so the\ntemplate language already supports that.\n\nAs for policies which might affect a holistic scheduler, those can just\nbe resources as well. Just like deployments relate to servers, resources\ncan relate to any policies they need.\n\n> > IIRC this has been discussed in the past and the justifications for \n> > including it in the template (as opposed to allowing metadata to be \n> > attached in the ReST API, as other projects already do for many things) \n> > were not compelling.\n> \n> I see that Keith Bray mentioned \n> https://wiki.openstack.org/wiki/Heat/StackMetadata and \n> https://wiki.openstack.org/wiki/Heat/UI in another reply on this thread. \n> Are there additional places to look to find that discussion?\n> \n> I have also heard that there has been discussion of language extension \n> issues.  Is that a separate discussion and, if so, where can I read it?\n\nI would prefer that we focus on making HOT composable rather than\nextensible. If there is actually something missing from the root of the\nlanguage, then it should be in the language. Use cases should almost\nalways try to find a way to work as resources first, and then if that\nis unwieldy, look into language enhancements to factor things out.\n\nI think the way hot-software-config has taken shape is a prime example\nof this. We took the most common patterns and made a set of resources\nthat encapsulate them. But we didn\'t have to extend the language any. It\nis all done in resources. (Kudos to Steve Baker for getting it done btw,\nthis was _not_ a small amount of work).\n\n\n','<OF67F2250F.41C2FC9D-ON85257CAF.001B6476-85257CAF.001C69EA@us.ibm.com>',NULL),('<1396545201.11731.2.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 12:13:21',-18000,'2014-04-03 17:13:21',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 09:22 -0700, Jay Pipes wrote:\n> Boson does indeed look interesting, but who is working on it, if anyone\n> at this point? I agree that having a centralized quota management system\n> makes sense, in order to make the handling of quotas and reservations\n> consistent across projects as well as to deal with global quota\n> management properly (i.e. quotas that span multiple cells/AZs)\n\nAt present, no one is really working on Boson.  The CERN folks were\ninterested in it, but I wasn\'t able to free up the time I would have\nneeded to actually develop on it, partly because of lack of interest\nfrom the rest of the community at the time.  I\'d say that, currently,\nBoson is facing the chicken-and-egg problem?no one works on it because\nno one is working on it.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<1396542147.19248.10.camel@sleepy>',NULL),('<1396547657.31045.1.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 10:54:17',-25200,'2014-04-03 17:54:17',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 12:13 -0500, Kevin L. Mitchell wrote:\n> On Thu, 2014-04-03 at 09:22 -0700, Jay Pipes wrote:\n> > Boson does indeed look interesting, but who is working on it, if anyone\n> > at this point? I agree that having a centralized quota management system\n> > makes sense, in order to make the handling of quotas and reservations\n> > consistent across projects as well as to deal with global quota\n> > management properly (i.e. quotas that span multiple cells/AZs)\n> \n> At present, no one is really working on Boson.  The CERN folks were\n> interested in it, but I wasn\'t able to free up the time I would have\n> needed to actually develop on it, partly because of lack of interest\n> from the rest of the community at the time.  I\'d say that, currently,\n> Boson is facing the chicken-and-egg problem?no one works on it because\n> no one is working on it.\n\nI would personally be interested in picking up the work. Kevin, any\nissues with me moving the code on your GitHub repo into stackforge and\nlinking up the upstream CI harness?\n\nAll the best,\n-jay\n\n\n\n\n','<1396545201.11731.2.camel@einstein.kev>',NULL),('<1396548790.11731.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 13:13:10',-18000,'2014-04-03 18:13:10',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 10:54 -0700, Jay Pipes wrote:\n> On Thu, 2014-04-03 at 12:13 -0500, Kevin L. Mitchell wrote:\n> > On Thu, 2014-04-03 at 09:22 -0700, Jay Pipes wrote:\n> > > Boson does indeed look interesting, but who is working on it, if anyone\n> > > at this point? I agree that having a centralized quota management system\n> > > makes sense, in order to make the handling of quotas and reservations\n> > > consistent across projects as well as to deal with global quota\n> > > management properly (i.e. quotas that span multiple cells/AZs)\n> > \n> > At present, no one is really working on Boson.  The CERN folks were\n> > interested in it, but I wasn\'t able to free up the time I would have\n> > needed to actually develop on it, partly because of lack of interest\n> > from the rest of the community at the time.  I\'d say that, currently,\n> > Boson is facing the chicken-and-egg problem?no one works on it because\n> > no one is working on it.\n> \n> I would personally be interested in picking up the work. Kevin, any\n> issues with me moving the code on your GitHub repo into stackforge and\n> linking up the upstream CI harness?\n\nNone at all; please do so!  :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<1396547657.31045.1.camel@sleepy>',NULL),('<1396554090.11731.8.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 14:41:30',-18000,'2014-04-03 19:41:30',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 19:16 +0000, Cazzolato, Sergio J wrote:\n> Jay, thanks for taking ownership on this idea, we are really\n> interested to contribute to this, so what do you think are the next\n> steps to move on?\n\nPerhaps a summit session on quota management would be in order?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<F576D72DA1DB704E976755DC5ADB05743FA06F4D@fmsmsx111.amr.corp.intel.com>',NULL),('<1396563644.879.0.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 15:20:44',-25200,'2014-04-03 22:20:44',NULL,'[openstack-dev] Quota Management','On Thu, 2014-04-03 at 14:41 -0500, Kevin L. Mitchell wrote:\n> On Thu, 2014-04-03 at 19:16 +0000, Cazzolato, Sergio J wrote:\n> > Jay, thanks for taking ownership on this idea, we are really\n> > interested to contribute to this, so what do you think are the next\n> > steps to move on?\n> \n> Perhaps a summit session on quota management would be in order?\n\nDone:\n\nhttp://summit.openstack.org/cfp/details/221\n\nBest,\n-jay\n\n\n\n','<1396554090.11731.8.camel@einstein.kev>',NULL),('<1396564811-sup-4338@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 16:01:16',-25200,'2014-04-03 23:01:16',NULL,'[openstack-dev] [heat] metadata for a HOT','Excerpts from Mike Spreitzer\'s message of 2014-04-03 11:05:10 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 04/03/2014 01:10:30 PM:\n> \n> > Things that affect the stack as a whole really belong in the stack\n> > API. That would also put them in the OS::Heat::Stack resource, so the\n> > template language already supports that.\n> \n> The OS::Heat::Stack resource is one of several that create nested stacks;\n> we should be able to apply holistic scheduling to all stacks, regardless\n> of whether they are nest or which kind of nested stack they are.\n> Yes, if holistic scheduling were a feature in the Heat API then all kinds \n> of\n> resources that create nested stacks \"should\" expose that feature\n> (shout out to Trove, autoscaling groups, ...).\n> \n> > As for policies which might affect a holistic scheduler, those can just\n> > be resources as well. Just like deployments relate to servers, resources\n> > can relate to any policies they need.\n> \n> A holistic scheduler needs input that describes all the resources to be \n> scheduled as well as all the policies that apply.  Should a template \n> contain a resource whose input includes a copy of the rest of the \n> template?\n> \n\nAre you suggesting that a scheduler should try and parse the template\nitself? Or that the scheduler would take over scheduling which\nheat-engine takes the work? The whole question raises many more\nquestions, and I wonder if there\'s just something you haven\'t told us\nabout this use case. :-P\n\nA holistic scheduler is meant to relate things. Templates relate things\nnaturally, so doing it with resources seems obvious to me.\n\nSomething like OS::Scheduler::ResourceGroup which would inform the\nscheduler that a grouping is needed. And then the resources all are\npart of that group via their properties, something like \'resource_group:\n{get_resource: group1}\'. If there\'s a policy for that group that I want\napplied, that is a policy that would also refer to the group and inform\nthe scheduler that this group gets this policy.\n\nFor instances where the whole stack needs to be considered in a group,\nthis is where I suggest that all resources should just be added to the\ngroup. When we have proof that this approach works, we can talk about\nintroducing shorthand for it.\n\nWhat I don\'t want to see is a special template section which introduces\nunnecessary complexity before we have concrete evidence that the approach\nis viable.\n\n> > I would prefer that we focus on making HOT composable rather than\n> > extensible. If there is actually something missing from the root of the\n> > language, then it should be in the language. Use cases should almost\n> > always try to find a way to work as resources first, and then if that\n> > is unwieldy, look into language enhancements to factor things out.\n> \n> Yeah, I would too.  Like I said, I have no satisfactory solution yet. Here \n> is more of the problem.  I would like to follow an evolutionary path \n> starting from the instance groups that are in Nova today.  I think I can \n> outline such an evolution.  I am sure there will be debate about it.  I am \n> even more sure that it will take time to accomplish that evolution.  OTOH, \n> locally we have a holistic scheduler already working.  We want to be able \n> to start using it today.  What can we do in this interim, and how can we \n> arrange things to do progressive convergence so that the interim solution \n> evolves as Nova & scheduling evolve, so that there is no big switch at the \n> end to the end solution?\n\nBig switches are fine as long as they\'re simplifications. So if we make\nyou be explicit about the groupings today, but then you find that you\nhave many stacks where everything is in fact in one group, then you can\nmake a clear argument for a root level item to set a property on all\nresources which support it, which I think is the right way to go.\n\n\n','<OF366EBF79.EC8FB455-ON85257CAF.006237D6-85257CAF.006359B0@us.ibm.com>',NULL),('<1396568903.879.8.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 16:48:23',-25200,'2014-04-03 23:48:23',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','On Mon, 2014-03-31 at 17:11 +0800, Jay Lau wrote:\n> Hi,\n> \n> Currently with VMWare VCDriver, one nova compute can manage multiple\n> clusters/RPs, this caused cluster admin cannot do live migration\n> between clusters/PRs if those clusters/PRs managed by one nova compute\n> as the current live migration logic request at least two nova\n> computes.\n> \n> \n> A bug [1] was also filed to trace VMWare live migration issue.\n> \n> I\'m now trying the following solution to see if it is acceptable for a\n> fix, the fix wants enable live migration with one nova compute:\n> 1) When live migration check if host are same, check both host and\n> node for the VM instance.\n> 2) When nova scheduler select destination for live migration, the live\n> migration task should put (host, node) to attempted hosts.\n> 3) Nova scheduler needs to be enhanced to support ignored_nodes.\n> 4) nova compute need to be enhanced to check host and node when doing\n> live migration.\n\nWhat precisely is the point of \"live migrating\" an instance to the exact\nsame host as it is already on? The failure domain is the host, so moving\nthe instance from one \"cluster\" to another, but on the same host is kind\nof a silly use case IMO. \n\nBut... if this really is something that is considered useful, then it\nseems to me that it would be more useful to simply expand the definition\nof the \"compute node\" object within Nova to be generic enough that a\ncompute node could be a VCenter cluster/PR. That way there would be no\nneed to hack the scheduler to account for more than the host (compute\nnode internally in Nova)?\n\nIn the same way, a cell could be a \"compute node\" as well, and we\nwouldn\'t need separate hacks in the scheduler and elsewhere that treated\ncells differently than \"regular\" compute nodes.\n\nBest,\n-jay\n\n> I also uploaded a WIP patch [2] for you to review the idea of the fix\n> and hope can get some comments from you.\n> \n> \n> [1] https://bugs.launchpad.net/nova/+bug/1192192\n> [2] https://review.openstack.org/#/c/84085\n> \n> \n> -- \n> Thanks,\n> \n> \n> Jay\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAFyztAFTQ6ZjaGQRA=0zVjeLsk+f4EjjZPWde1vMYCDn4M6=5g@mail.gmail.com>',NULL),('<1396581590.2924.2.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 11:19:50',28800,'2014-04-04 03:19:50',NULL,'[openstack-dev] [oslo] Some Thoughts on Log Message ID Generation\n	Blueprint','Hi,\n\n  Recently I read the \"Separate translation domain for log messages\"\nblueprint[1], and I found that we can store both English Message Log and\nTranslated Message Log with some configurations.\n\n  I am an i18n Software Engineer, and we are thinking about \"Add message\nIDs for log messages\" blueprint[2]. My thought is that if we can store\nboth English Message Log and Translated Message Log, we can skip the\nneed of Log Message ID Generation.\n\n  I also commented the \"Add message IDs for log messages\" blueprint[2].\n\n  If the servers always store English Log Messages, maybe we don\'t need\nthe \"Add message IDs for log messages\" blueprint[2] any more.\n\n  Feel free to comment this proposal.\n\nThanks,\n  Peng Wu\n\nRefer URL:\n[1]\nhttps://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n[2] https://blueprints.launchpad.net/oslo/+spec/log-messages-id\n\n\n\n\n',NULL,NULL),('<1396586794.20953.4.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 21:46:34',-25200,'2014-04-04 04:46:34',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:\n> Thanks Jay and Chris for the comments!\n> \n> @Jay Pipes, I think that we still need to enable \"one nova compute\n> live migration\" as one nova compute can manage multiple clusters and\n> VMs can be migrated between those clusters managed by one nova\n> compute.\n\nWhy, though? That is what I am asking... seems to me like this is an\nanti-feature. What benefit does the user get from moving an instance\nfrom one VCenter cluster to another VCenter cluster if the two clusters\nare on the same physical machine?\n\nSecondly, why is it that a single nova-compute manages multiple VCenter\nclusters? This seems like a hack to me... perhaps someone who wrote the\ncode for this or knows the decision behind it could chime in here?\n\n>  For cell, IMHO, each \"cell\" can be treated as a small \"cloud\" but not\n> a \"compute\", each \"cell cloud\" should be able to handle VM operations\n> in the small cloud itself. Please correct me if I am wrong.\n\nYes, I agree with you that a cell is not a compute. Not sure if I said\notherwise in my previous response. Sorry if it was confusing! :)\n\nBest,\n-jay\n\n> @Chris, \"OS-EXT-SRV-ATTR:host\" is the host where nova compute is\n> running and \"OS-EXT-SRV-ATTR:hypervisor_hostname\" is the hypervisor\n> host where the VM is running. Live migration is now using \"host\" for\n> live migration. What I want to do is enable migration with one \"host\"\n> and the \"host\" managing multiple \"hyperviosrs\".\n> \n> \n> I\'m planning to draft a bp for review which depend on\n> https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory \n> \n> \n> Thanks!\n> \n> \n> \n> 2014-04-04 8:03 GMT+08:00 Chris Friesen <chris.friesen at windriver.com>:\n>         On 04/03/2014 05:48 PM, Jay Pipes wrote:\n>                 On Mon, 2014-03-31 at 17:11 +0800, Jay Lau wrote:\n>                         Hi,\n>                         \n>                         Currently with VMWare VCDriver, one nova\n>                         compute can manage multiple\n>                         clusters/RPs, this caused cluster admin cannot\n>                         do live migration\n>                         between clusters/PRs if those clusters/PRs\n>                         managed by one nova compute\n>                         as the current live migration logic request at\n>                         least two nova\n>                         computes.\n>                         \n>                         \n>                         A bug [1] was also filed to trace VMWare live\n>                         migration issue.\n>                         \n>                         I\'m now trying the following solution to see\n>                         if it is acceptable for a\n>                         fix, the fix wants enable live migration with\n>                         one nova compute:\n>                         1) When live migration check if host are same,\n>                         check both host and\n>                         node for the VM instance.\n>                         2) When nova scheduler select destination for\n>                         live migration, the live\n>                         migration task should put (host, node) to\n>                         attempted hosts.\n>                         3) Nova scheduler needs to be enhanced to\n>                         support ignored_nodes.\n>                         4) nova compute need to be enhanced to check\n>                         host and node when doing\n>                         live migration.\n>                 \n>                 What precisely is the point of \"live migrating\" an\n>                 instance to the exact\n>                 same host as it is already on? The failure domain is\n>                 the host, so moving\n>                 the instance from one \"cluster\" to another, but on the\n>                 same host is kind\n>                 of a silly use case IMO.\n>         \n>         \n>         Here is where precise definitions of \"compute node\",\n>         \"OS-EXT-SRV-ATTR:host\", and\n>         \"OS-EXT-SRV-ATTR:hypervisor_hostname\", and \"host\" as\n>         understood by novaclient would be nice.\n>         \n>         Currently the \"nova live-migration\" command takes a \"host\"\n>         argument. It\'s not clear which of the above this corresponds\n>         to.\n>         \n>         My understanding is that one nova-compute process can manage\n>         multiple VMWare physical hosts.  So it could make sense to\n>         support live migration between separate VMWare hosts even if\n>         they\'re managed by a single nova-compute process.\n>         \n>         Chris\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> -- \n> Thanks,\n> \n> \n> Jay\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAFyztAGmvokxkrzv1YvrB2V0akey-S4VJtJGF0_-jyQbfTsyxg@mail.gmail.com>',NULL),('<1396601466.27872.YahooMailNeo@web163602.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 01:51:06',-25200,'2014-04-04 08:51:06',NULL,'[openstack-dev] ML2 Type driver for supporting network overlays,\n	with more than 4K seg','The blueprint is updated with more information on the requirements and interaction with VDP\n\nhttps://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support\n\n\nOn Monday, March 31, 2014 12:50 PM, Padmanabhan Krishnan <kprad1 at yahoo.com> wrote:\n \nHi Mathieu,\nThanks for the link. Some similarities for sure. I see Nova libvirt being used. I had looked at libvirt earlier.\n\nFirstly, the libvirt support that Nova uses to communicate with LLDPAD doesn\'t have support for the latest 2.2 standard. The support is also only for the VEPA mode and not for VEB mode. It\'s also quite not clear as how the VLAN provided by VDP is used by libvirt to communicate it back to Openstack.\nThere\'s already an existing blueprint where i can add more details (https://blueprints.launchpad.net/neutron/+spec/netron-ml2-mechnism-driver-for-cisco-dfa-support)\n\nEven for a single physical network, you need more parameters in the ini file. I was thinking of Host or Network Overlay with or w/o VDP for Tunnel mode. I will add more to the blueprint.\n\nThanks,\nPaddu\n\nOn Friday, March 28, 2014 8:42 AM, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:\n \nHi,\n\n\nthe more I think about your use case, the more I think you should\ncreate a BP to have tenant network based on interfaces created with\nVDP protocol.\nI\'m not a VDP specialist, but if it creates some vlan back interfaces,\nyou might match those physical interfaces with the\nphysical_interface_mappings parameter in your ml2_conf.ini. Then you\ncould create flat networks backed on those interfaces.\nSR-IOv use cases also talk about using vif_type 802.1qbg :\nhttps://wiki.openstack.org/wiki/Nova-neutron-sriov\n\n\n\nMathieu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/5b580c4f/attachment.html>\n\n','<1396295459.859.YahooMailNeo@web163605.mail.gq1.yahoo.com>',NULL),('<1396630734-sup-2168@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 10:05:04',-25200,'2014-04-04 17:05:04',NULL,'[openstack-dev] [Heat] [Murano] [Solum] applications in the\n	cloud','Excerpts from Stan Lagun\'s message of 2014-04-04 02:54:05 -0700:\n> Hi Steve, Thomas\n> \n> I\'m glad the discussion is so constructive!\n> \n> If we add type interfaces to HOT this may do the job.\n> Applications in AppCatalog need to be portable across OpenStack clouds.\n> Thus if we use some globally-unique type naming system applications could\n> identify their dependencies in unambiguous way.\n> \n> We also would need to establish relations between between interfaces.\n> Suppose there is My::Something::Database interface and 7 compatible\n> materializations:\n> My::Something::TroveMySQL\n> My::Something::GaleraMySQL\n> My::Something::PostgreSQL\n> My::Something::OracleDB\n> My::Something::MariaDB\n> My::Something::MongoDB\n> My::Something::HBase\n> \n> There are apps that (say SQLAlchemy-based apps) are fine with any\n> relational DB. In that case all templates except for MongoDB and HBase\n> should be matched. There are apps that design to work with MySQL only. In\n> that case only TroveMySQL, GaleraMySQL and MariaDB should be matched. There\n> are application who uses PL/SQL and thus require OracleDB (there can be\n> several Oracle implementations as well). There are also applications\n> (Marconi and Ceilometer are good example) that can use both some SQL and\n> NoSQL databases. So conformance to Database interface is not enough and\n> some sort of interface hierarchy required.\n\nIMO that is not really true and trying to stick all these databases into\none \"SQL database\" interface is not a use case I\'m interested in\npursuing.\n\nFar more interesting is having each one be its own interface which apps\ncan assert that they support or not.\n\n> \n> Another thing that we need to consider is that even compatible\n> implementations may have different set of parameters. For example\n> clustered-HA PostgreSQL implementation may require additional parameters\n> besides those needed for plain single instance variant. Template that\n> consumes *any* PostgreSQL will not be aware of those additional parameters.\n> Thus they need to be dynamically added to environment\'s input parameters\n> and resource consumer to be patched to pass those parameters to actual\n> implementation\n> \n\nI think this is a middleware pipe-dream and the devil is in the details.\n\nJust give users the ability to be specific, and then generic patterns\nwill arise from those later on.\n\nI\'d rather see a focus on namespacing and relative composition, so that\nproviders of the same type that actually do use the same interface but\nare alternate implementations will be able to be consumed. So for instance\nthere is the non-Neutron LBaaS and the Neutron LBaaS, and both have their\nmerits for operators, but are basically identical from an application\nstandpoint. That seems a better guiding use case than different databases.\n\n\n','<CAOCoZiZQTr5nD8WkbxDT9s85cpkhQ1TMLFe1zaT6eRACaH8OQA@mail.gmail.com>',NULL),('<1396632318-sup-8513@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 10:29:36',-25200,'2014-04-04 17:29:36',NULL,'[openstack-dev] [Ironic][Agent]','Excerpts from Vladimir Kozhukalov\'s message of 2014-04-04 05:19:41 -0700:\n> Hello, everyone,\n> \n> I\'d like to involve more people to express their opinions about the way how\n> we are going to run Ironic-python-agent. I mean should we run it with root\n> privileges or not.\n> \n> From the very beginning agent is supposed to run under ramdisk OS and it is\n> intended to make disk partitioning, RAID configuring, firmware updates and\n> other stuff according to installing OS. Looks like we always will run agent\n> with root privileges. Right? There are no reasons to limit agent\n> permissions.\n> \n> On the other hand, it is easy to imagine a situation when you want to run\n> agent on every node of your cluster after installing OS. It could be useful\n> to keep hardware info consistent (for example, many hardware configurations\n> allow one to add hard drives in run time). It also could be useful for \"on\n> the fly\" firmware updates. It could be useful for \"on the fly\"\n> manipulations with lvm groups/volumes and so on.\n> \n> Frankly, I am not even sure that we need to run agent with root privileges\n> even in ramdisk OS, because, for example, there are some system default\n> limitations such as number of connections, number of open files, etc. which\n> are different for root and ordinary user and potentially can influence\n> agent behaviour. Besides, it is possible that some vulnerabilities will be\n> found in the future and they potentially could be used to compromise agent\n> and damage hardware configuration.\n> \n> Consequently, it is better to run agent under ordinary user even under\n> ramdisk OS and use rootwrap if agent needs to run commands with root\n> privileges. I know that rootwrap has some performance issues\n> http://lists.openstack.org/pipermail/openstack-dev/2014-March/029017.htmlbut\n> it is still pretty suitable for ironic agent use case.\n> \n\nMy opinion: If you are going to listen for connections, do so on a low\nport as root, but then drop privs immediately thereafter. Run things\nwith sudo, not rootwrap, as the flexibility will just become a burden\nif you ever do need to squeeze more performance out, and it won\'t be\nmuch of a boon to what are likely to be very straight forward commands.\n\nFinally, as others have said, this is for the deploy ramdisk only. For\nthe case where you want to do an on-the-fly firmware update, there are\na bazillion options to do remote execution. Ironic is for the case where\nyou don\'t have on-the-fly capabilities.\n\n\n','<CAFLqvG6PbiRg5mpbp_mFx6pkd5pqCz41DjBt90ewKuaR30bxaQ@mail.gmail.com>',NULL),('<1396633258-sup-5719@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 10:58:40',-25200,'2014-04-04 17:58:40',NULL,'[openstack-dev] [TripleO] [Heat] TripleO Heat Templates and\n	merge.py','Excerpts from Tomas Sedovic\'s message of 2014-04-04 08:47:46 -0700:\n> Hi All,\n> \n> I was wondering if the time has come to document what exactly are we\n> doing with tripleo-heat-templates and merge.py[1], figure out what needs\n> to happen to move away and raise the necessary blueprints on Heat and\n> TripleO side.\n> \n\nYes indeed, it is time.\n\n> (merge.py is a script we use to build the final TripleO Heat templates\n> from smaller chunks)\n> \n> There probably isn\'t an immediate need for us to drop merge.py, but its\n> existence either indicates deficiencies within Heat or our unfamiliarity\n> with some of Heat\'s features (possibly both).\n> \n> I worry that the longer we stay with merge.py the harder it will be to\n> move forward. We\'re still adding new features and fixing bugs in it (at\n> a slow pace but still).\n>\n\nMerge.py is where we\'ve amassed our debt. We\'ll pay it back by moving\nfeatures into Heat. A huge debt payment is coming in the form of\nsoftware config migration, which you mention at the bottom of this\nmessage.\n\n> Below is my understanding of the main marge.py functionality and a rough\n> plan of what I think might be a good direction to move to. It is almost\n> certainly incomplete -- please do poke holes in this. I\'m hoping we\'ll\n> get to a point where everyone\'s clear on what exactly merge.py does and\n> why. We can then document that and raise the appropriate blueprints.\n> \n> \n> ## merge.py features ##\n> \n> \n> 1. Merging parameters and resources\n> \n> Any uniquely-named parameters and resources from multiple templates are\n> put together into the final template.\n> \n> If a resource of the same name is in multiple templates, an error is\n> raised. Unless it\'s of a whitelisted type (nova server, launch\n> configuration, etc.) in which case they\'re all merged into a single\n> resource.\n> \n> For example: merge.py overcloud-source.yaml swift-source.yaml\n> \n> The final template has all the parameters from both. Moreover, these two\n> resources will be joined together:\n> \n> #### overcloud-source.yaml ####\n> \n>   notCompute0Config:\n>     Type: AWS::AutoScaling::LaunchConfiguration\n>     Properties:\n>       ImageId: \'0\'\n>       InstanceType: \'0\'\n>     Metadata:\n>       admin-password: {Ref: AdminPassword}\n>       admin-token: {Ref: AdminToken}\n>       bootstack:\n>         public_interface_ip:\n>           Ref: NeutronPublicInterfaceIP\n> \n> \n> #### swift-source.yaml ####\n> \n>   notCompute0Config:\n>     Type: AWS::AutoScaling::LaunchConfiguration\n>     Metadata:\n>       swift:\n>         devices:\n>           ...\n>         hash: {Ref: SwiftHashSuffix}\n>         service-password: {Ref: SwiftPassword}\n> \n> \n> The final template will contain:\n> \n>   notCompute0Config:\n>     Type: AWS::AutoScaling::LaunchConfiguration\n>     Properties:\n>       ImageId: \'0\'\n>       InstanceType: \'0\'\n>     Metadata:\n>       admin-password: {Ref: AdminPassword}\n>       admin-token: {Ref: AdminToken}\n>       bootstack:\n>         public_interface_ip:\n>           Ref: NeutronPublicInterfaceIP\n>       swift:\n>         devices:\n>           ...\n>         hash: {Ref: SwiftHashSuffix}\n>         service-password: {Ref: SwiftPassword}\n> \n> \n> We use this to keep the templates more manageable (instead of having one\n> huge file) and also to be able to pick the components we want: instead\n> of `undercloud-bm-source.yaml` we can pick `undercloud-vm-source` (which\n> uses the VirtualPowerManager driver) or `ironic-vm-source`.\n> \n\nThe merging of white-listed types is superseded entirely by\nOS::Heat::StructuredConfig and OS::Heat::StructuredDeployment. I would\nmove that we replace all uses of it with those, and deprecate the\nfeature.\n\n> \n> \n> 2. FileInclude\n> \n> If you have a pseudo resource with the type of `FileInclude`, we will\n> look at the specified Path and SubKey and put the resulting dictionary in:\n> \n> #### overcloud-source.yaml ####\n> \n>   NovaCompute0Config:\n>     Type: FileInclude\n>     Path: nova-compute-instance.yaml\n>     SubKey: Resources.NovaCompute0Config\n>     Parameters:\n>       NeutronNetworkType: \"gre\"\n>       NeutronEnableTunnelling: \"True\"\n> \n> \n> #### nova-compute-instance.yaml ####\n> \n>   NovaCompute0Config:\n>     Type: AWS::AutoScaling::LaunchConfiguration\n>     Properties:\n>       InstanceType: \'0\'\n>       ImageId: \'0\'\n>     Metadata:\n>       keystone:\n>         host: {Ref: KeystoneHost}\n>       neutron:\n>         host: {Ref: NeutronHost}\n>           tenant_network_type: {Ref: NeutronNetworkType}\n>           network_vlan_ranges: {Ref: NeutronNetworkVLANRanges}\n>           bridge_mappings: {Ref: NeutronBridgeMappings}\n>           enable_tunneling: {Ref: NeutronEnableTunnelling}\n>           physical_bridge: {Ref: NeutronPhysicalBridge}\n>           public_interface: {Ref: NeutronPublicInterface}\n>         service-password:\n>           Ref: NeutronPassword\n>       admin-password: {Ref: AdminPassword}\n> \n> The result:\n> \n>   NovaCompute0Config:\n>     Type: AWS::AutoScaling::LaunchConfiguration\n>     Properties:\n>       InstanceType: \'0\'\n>       ImageId: \'0\'\n>     Metadata:\n>       keystone:\n>         host: {Ref: KeystoneHost}\n>       neutron:\n>         host: {Ref: NeutronHost}\n>           tenant_network_type: \"gre\"\n>           network_vlan_ranges: {Ref: NeutronNetworkVLANRanges}\n>           bridge_mappings: {Ref: NeutronBridgeMappings}\n>           enable_tunneling: \"True\"\n>           physical_bridge: {Ref: NeutronPhysicalBridge}\n>           public_interface: {Ref: NeutronPublicInterface}\n>         service-password:\n>           Ref: NeutronPassword\n>       admin-password: {Ref: AdminPassword}\n> \n> Note the `NeutronNetworkType` and `NeutronEnableTunneling` parameter\n> substitution.\n> \n> This is useful when you want to pick only bits and pieces of an existing\n> template. In the example above, `nova-compute-instance.yaml` is a\n> standalone template you can launch on its own. But when launching the\n> overcloud, you don\'t want to merge nova-compute-instance wholesale. All\n> you want is the NovaCompute0Config resource plus a few others.\n> \n> I admit I\'m not entirely clear on how/why do we need this, though.\n> FileInclude is being used just for the overcloud nova compute resources\n> (server, config, waitcondition, etc.).\n> \n> The undercloud as well as the additional overcloud resources (swift,\n> block storage) seem get by without FileInclude.\n>\n\nThis feature was used so that we could keep nova-compute-instance.yaml\nas a whole, working template. I think this use case is also superseded\nby the new software config/deployment resources.\n\n> \n> 3. OpenStack::Role metadata key\n> \n> I\'m not sure what this does or why would we need it. The Ironic\n> templates used it but it was removed because they were broken.\n> \n> Right now it\'s used in `tuskar-source.yaml` and `undercloud-source.yaml`\n> only.\n> \n\nServers with the same role will be merged. It is also superseded by\nsoftware-config and can probably be removed when we\'re done with that\nmigration as wel.\n\n> \n> 4. OpenStack::ImageBuilder::Elements metadata key\n> \n> Again, this seems to receive custom handling by merge.py, but I\'m\n> unclear as to why.\n> \n\nThere was a time when I thought we\'d drive diskimage-builder using\ntemplates. The long term goal of this was to be able to validate the\nmetadata based on element content. We have not done any of this, and I\nthink the feature can just be removed entirely.\n\n> \n> 5. Scaling\n> \n> We can mark resources in a Heat template as scalable by giving them the\n> \'0\' suffix. We can then use the `--scale` parameter to make copies of these:\n> \n>   SwiftStorage0CompletionHandle:\n>     Type: AWS::CloudFormation::WaitConditionHandle\n> \n>   SwiftStorage0:\n>     Type: OS::Nova::Server\n>     Properties:\n>       image:\n>         {Ref: SwiftStorageImage}\n>       flavor: {Ref: OvercloudSwiftStorageFlavor}\n>       key_name: {Ref: KeyName}\n>     ...\n> \n> $ merge.py swift-storage-source.yaml --scale SwiftStorage=2\n> \n> result:\n> \n>   SwiftStorage0CompletionHandle:\n>     Type: AWS::CloudFormation::WaitConditionHandle\n> \n>   SwiftStorage0:\n>     Type: OS::Nova::Server\n>     Properties:\n>       image:\n>         {Ref: SwiftStorageImage}\n>       flavor: {Ref: OvercloudSwiftStorageFlavor}\n>       key_name: {Ref: KeyName}\n>     ...\n> \n>   SwiftStorage1CompletionHandle:\n>     Type: AWS::CloudFormation::WaitConditionHandle\n> \n>   SwiftStorage1:\n>     Type: OS::Nova::Server\n>     Properties:\n>       image:\n>         {Ref: SwiftStorageImage}\n>       flavor: {Ref: OvercloudSwiftStorageFlavor}\n>       key_name: {Ref: KeyName}\n>     ...\n> \n> This seems rather close to what OS::Heat::ResourceGroup[2] does. Can we\n> just switch to using that instead? I seem to remember reading something\n> about the order of deleted resources of being wrong for our purposes.\n> \n> Is that correct? What are the specifics?\n> \n\nWe have avoided using the heat resource grouping because there\'s no\nopportunity for invididual per-server metadata. We don\'t want to have\none user/password for the database for all servers, as it creates several\nproblems, the biggest one being if you change the password for that user\nthen you have to be sure all operational servers have that password.\n\nWith deployments and the random string generator, I think we can achieve\nthat use case, and make the username/password for each nested stack\navailable to the database/queue/etc for asserting their availability.\n\nWe need to do this not just because merge.py is duplicating functionality\nin Heat, but also because this will help us get to Heat managed rolling\nupdates.\n\nThere\'s also another problem with Heat\'s groups which is that there is\ncurrently no way to specify which server to scale down from. With the\nmerge.py method, we can at least generate a template that is too big,\nand then manually remove the resources we\'d like deleted.\n\n> \n> 6. Merge::Map helper function\n> \n> Returns the list of values from a dictionary given as a parameter.\n> \n> I\'m assuming this would be great to have, but isn\'t blocking us from\n> moving to native Heat templates.\n> \n> Clint sent a proposal of this to the Heat developers but it went largely\n> unanswered. Perhaps we could revisit it?\n\nI think unanswered is a silent +1, so we should just drive this into\nHOT.\n\n> \n> \n> 7-... Whatever I\'ve missed!\n> \n> (here\'s where you get to point out my vast ignorance)\n\n\nI think you captured all the items I care about.\n\nIdeally we\'d eliminate merge.py entirely. Realistically I think we\'ll\ndeprecate features one by one and maybe can expect to get rid of\nmerge.py in a release or two.\n\n> \n> \n> \n> ## a vision of a world without merge.py ##\n> \n> Seems to me provider resources ought be able to handle the composability\n> side of things (while still allowing us to use them as standalone\n> templates) and resource groups should handle the scaling.\n> \n\n> We could keep roughly the same structure: a separate template for each\n> OpenStack service (compute, block storage, object storage, ironic, nova\n> baremetal). We would then use Heat environments to treat each of these\n> templates as a custom resource (e.g. OS::TripleO::Nova,\n> OS::TripleO::Swift, etc.).\n> \n\nI\'ve never fully embraced providers for composition. Perhaps I\'ve missed\nthat as a key feature. An example of this would be helpful. I think if\nwe deprecated all of merge.py except the \"merge unique params and\nresources into one template\" part, we could probably just start using\nnested stacks for that and drop merge.py. However, I\'m not a huge fan of\nnested stacks as they are a bit clunky. Maybe providers would make that\nbetter?\n\nAnyway, I think I need to see how this would actually work before I can\nreally grasp it.\n\n> Our overcloud and undercloud templates would then reference all these\n> each wrapped in a ResourceGroup or a more sophisticated scaling mechanism.\n> \n> \n> \n> ## tangential but nice to have stuff ##\n> \n> * move to HOT\n>   - It\'s where any new syntax extensions will happen\n> \n> * move to Software Config\n>   - Clint has a WIP patch:\n>   - https://review.openstack.org/#/c/81666/\n> \n\nWhen 81666 is done and merged, the next step is to split out the config\nand deploy resources into individual services, and then finally we can\nswitch the syntax to HOT. I am nervous about doing it any faster than\nthat, as it has already taken quite a while for me to wrap my head\naround software configs and the effect it has on the overall deployment.\n\n> \n> What have I missed and what are your thoughts?\n\nI think you covered it nicely, well done.\n\n\n','<533ED422.5020707@redhat.com>',NULL),('<1396635807-sup-8484@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 11:34:35',-25200,'2014-04-04 18:34:35',NULL,'[openstack-dev] [TripleO] reviewer update march','Excerpts from Robert Collins\'s message of 2014-04-03 04:02:20 -0700:\n> Getting back in the swing of things...\n> \n> Hi,\n>     like most OpenStack projects we need to keep the core team up to\n> date: folk who are not regularly reviewing will lose context over\n> time, and new folk who have been reviewing regularly should be trusted\n> with -core responsibilities.\n> \n> In this months review:\n>  - Dan Prince for -core\n>  - Jordan O\'Mara for removal from -core\n>  - Jiri Tomasek for removal from -core\n>  - Jamomir Coufal for removal from -core\n> \n\n\n+1 for all changes.\n\n\n','<CAJ3HoZ3VznLinLajQLCvvGNSgPo9iWihGLkuBzhdJsdaM-7udQ@mail.gmail.com>',NULL),('<1396636582-sup-2371@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 11:46:17',-25200,'2014-04-04 18:46:17',NULL,'[openstack-dev] [heat] Problems with Heat software\n	configurations and KeystoneV2','Excerpts from Michael Elder\'s message of 2014-04-04 07:16:55 -0700:\n> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624\n> \n> I still have concerns though about the design approach of creating a new \n> project for every stack and new users for every resource. \n> \n> If I provision 1000 patterns a day with an average of 10 resources per \n> pattern, you\'re looking at 10,000 users per day. How can that scale? \n> \n\nIf that can\'t scale, then keystone is not viable at all. I like to think\nwe can scale keystone to the many millions of users level.\n\n> How can we ensure that all stale projects and users are cleaned up as \n> instances are destroy? When users choose to go through horizon or nova to \n> tear down instances, what cleans up the project & users associated with \n> that heat stack? \n> \n\nSo, they created these things via Heat, but have now left the dangling\nreferences in Heat, and expect things to work properly?\n\nIf they create it via Heat, they need to delete it via Heat.\n\n> Keystone defines the notion of tokens to support authentication, why \n> doesn\'t the design provision and store a token for the stack and its \n> equivalent management? \n> \n\nTokens are _authentication_, not _authorization_. For the latter, we\nneed to have a way to lock down access to an individual resource in\nHeat. This allows putting secrets in deployments and knowing that only\nthe instance which has been deployed to will have access to the secrets.\nI do see an optimization possible, which is to just create a user for the\nbox that is given access to any deployments on the box. That would make\nsense if users are going to create many many deployments per server. But\neven at 10 per server, having 10 users is simpler than trying to manage\nshared users and edit their authorization rules.\n\nNow, I actually think that OAUTH tokens _are_ intended to be authorization\nas well as authentication, so that is probably where the focus should\nbe long term. But really, you\'re talking about the same thing: a single\nkey lookup in keystone.\n\n\n','<OFD0ECF3D8.2A78E5C6-ON85257CB0.004E34F3-85257CB0.004E7403@us.ibm.com>',NULL),('<1396674144-sup-2483@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-04 22:09:03',-25200,'2014-04-05 05:09:03',NULL,'[openstack-dev] [heat] Problems with Heat software\n	configurations and KeystoneV2','Excerpts from Adam Young\'s message of 2014-04-04 18:48:40 -0700:\n> On 04/04/2014 02:46 PM, Clint Byrum wrote:\n> > Excerpts from Michael Elder\'s message of 2014-04-04 07:16:55 -0700:\n> >> Opened in Launchpad: https://bugs.launchpad.net/heat/+bug/1302624\n> >>\n> >> I still have concerns though about the design approach of creating a new\n> >> project for every stack and new users for every resource.\n> >>\n> >> If I provision 1000 patterns a day with an average of 10 resources per\n> >> pattern, you\'re looking at 10,000 users per day. How can that scale?\n> >>\n> > If that can\'t scale, then keystone is not viable at all. I like to think\n> > we can scale keystone to the many millions of users level.\n> >\n> >> How can we ensure that all stale projects and users are cleaned up as\n> >> instances are destroy? When users choose to go through horizon or nova to\n> >> tear down instances, what cleans up the project & users associated with\n> >> that heat stack?\n> >>\n> > So, they created these things via Heat, but have now left the dangling\n> > references in Heat, and expect things to work properly?\n> >\n> > If they create it via Heat, they need to delete it via Heat.\n> >\n> >> Keystone defines the notion of tokens to support authentication, why\n> >> doesn\'t the design provision and store a token for the stack and its\n> >> equivalent management?\n> >>\n> > Tokens are _authentication_, not _authorization_.\n> \n> Tokens are authorization, not authentication.  For Authentication you \n> should be using a real cryptographically secure authentication \n> mechanism:  either Kerberos or X509.\n> \n\nIndeed, I may have used the terms incorrectly.\n\nUnless I\'m mistaken, a token is valid wherever it is presented. It is\nsimply proving that you authenticated yourself to keystone and that you\nhave xyz roles.\n\nPerhaps the roles are \"authorization\". But those roles aren\'t scoped to\na token, they\'re scoped to a user, so it still remains that it serves\nas authentication for what you have and what you\'re authorized to do as\na whole user.\n\nThat is why I suggest OAUTH, because that is a scheme which offers\ntokens with limited scope. We kind of have the same thing with trusts,\nbut that also doesn\'t really offer the kind of isolation what we want,\nnor does it really offer advantages over user-per-deployment.\n\n\n','<533F60F8.6070206@redhat.com>',NULL),('<1396721465.9421.6.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-05 14:11:05',-14400,'2014-04-05 18:11:05',NULL,'[openstack-dev] Quota Management','On Fri, 2014-04-04 at 11:52 +0100, Julie Pichon wrote:\n> On 03/04/14 23:20, Jay Pipes wrote:\n> > On Thu, 2014-04-03 at 14:41 -0500, Kevin L. Mitchell wrote:\n> >> On Thu, 2014-04-03 at 19:16 +0000, Cazzolato, Sergio J wrote:\n> >>> Jay, thanks for taking ownership on this idea, we are really\n> >>> interested to contribute to this, so what do you think are the next\n> >>> steps to move on?\n> >>\n> >> Perhaps a summit session on quota management would be in order?\n> > \n> > Done:\n> > \n> > http://summit.openstack.org/cfp/details/221\n> \n> Thank you for proposing the session, I\'m hopeful having this in the new\n> cross-project track will have a positive impact on the discussion. I\'m\n> under the impression that this comes back regularly as a session topic\n> but keeps hitting barriers when it comes to actual implementation\n> (perhaps because important stakeholders were missing from the session\n> before).\n\nYes, agreed. Although I missed the HK summit, I remember previous\nsummits that had similar discussions around quota management and\nresource reservations.\n\n> I\'d like to bring up the cross-project discussion from last time this\n> was discussed in December [1] as a reference, since the same\n> questions/objections will likely come back again.\n\nAh, thx for the link, very helpful indeed.\n\n>  One of the main issues\n> was that this shouldn\'t live in Keystone, which could be resolved by\n> using Boson, but the rest shows a reluctance from the projects to\n> delegate quota management, and uncertainty around the use cases. Oslo\n> was also mentioned as a possible place to help with improving the\n> consistency.\n\nYeah, so my idea for this was to expand the current driver-based quota\nsystem in Nova to contain an externally-managed driver (Boson). That\nway, quota management would operate identically to network and volume\ncomponents, with a local option and an external option, depending on the\nselection of the driver (which would of course remain\nnova.quota.DbQuotaDriver by default). That way we can innovate on the\nBoson front with no impact on Nova. We\'d do something identical in\nCinder and Neutron, of course, and gradually (2, 3 cycles?) move the\ndefault driver from the DbQuotaDriver to BosonDriver... this seems like\nan easy way to make progress with little risk.\n\n> I\'d love a more consistent way to handle and manage quotas across\n> multiple projects as this would help Horizon too, for very similar\n> reasons than are mentioned here.\n\n++\n\nBest,\n-jay\n\n> Thanks,\n> \n> Julie\n> \n> [1]\n> http://eavesdrop.openstack.org/meetings/project/2013/project.2013-12-10-21.02.log.html\n> from 21:10\n> \n> > Best,\n> > -jay\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<533E8ED3.8050505@redhat.com>',NULL),('<1396729320.3044.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-05 16:22:00',-14400,'2014-04-05 20:22:00',NULL,'[Openstack-operators] Quota Templates','On Fri, 2014-04-04 at 20:39 -0500, Narayan Desai wrote:\n> This doesn\'t particularly hit our main quota issue. IMO templates\n> could easily be implemented with a script. Also, the more I think\n> about it, they probably should be implemented that way, since this\n> kind of policy often gets overly complex when you try to implement a\n> general solution, and the script solution is just fine for us.\n> \n> If you\'re interested in quotas, we have a completely different problem\n> with quotas that is a real showstopper for us. We have a really large\n> dynamic range in resource quantities for our different instance types.\n> (for example, we have 3 orders of magnitudes in the range of memory\n> configurations). This makes quotas pretty useless for us as they are\n> currently implemented, since you can\'t represent limits for these\n> different kinds of resources in the same quota.\n\nWhy can\'t you? The resource is the memory, CPU, and disk used, not the\ninstance type.\n\nHonestly, I think that this is a user-interface thing, not a quota\nmanagement thing. In other words, have the quota-management UI show some\ntranslation help-text. For the user, it would be something like \"you\nhave room for X m2.xlarge instances left\". For an admin it would be\nsomething like \"this quota allocation represents X m2.xlarge instances\".\n\n>  Something like per-instance-type quotas would at least allow us to\n> restrict users to a fixed number of instances of a given type,\n> bypassing the current quota mechanism.\n\nThe only problem with this is that what happens if an instance type\'s\nunderlying resource allocation changes? Quotas and reservations\ngenerally need to be on the actual resources that are consumed, not on\nan abstract representation of those resources like an instance type, due\nto the fact that the abstract representation can changes over time.\n\nMy idea about the UI above works nicely with the idea of changeable\ninstance types. The UI can do simple real-time calculations about what a\nquota allocation represents in terms of the actual resources used by an\ninstance type.\n\nBest,\n-jay\n\n\n\n','<CABweQmKdyPjF4LOVauVhwuMRY_wCx=BYhMb=3sYjd-EG5B4hwQ@mail.gmail.com>',NULL),('<1396729926.3044.9.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-05 16:32:06',-14400,'2014-04-05 20:32:06',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','On Fri, 2014-04-04 at 13:30 +0800, Jay Lau wrote:\n> \n> \n> \n> 2014-04-04 12:46 GMT+08:00 Jay Pipes <jaypipes at gmail.com>:\n>         On Fri, 2014-04-04 at 11:08 +0800, Jay Lau wrote:\n>         > Thanks Jay and Chris for the comments!\n>         >\n>         > @Jay Pipes, I think that we still need to enable \"one nova\n>         compute\n>         > live migration\" as one nova compute can manage multiple\n>         clusters and\n>         > VMs can be migrated between those clusters managed by one\n>         nova\n>         > compute.\n>         \n>         \n>         Why, though? That is what I am asking... seems to me like this\n>         is an\n>         anti-feature. What benefit does the user get from moving an\n>         instance\n>         from one VCenter cluster to another VCenter cluster if the two\n>         clusters\n>         are on the same physical machine?\n> @Jay Pipes, for VMWare, one physical machine (ESX server) can only\n> belong to one VCenter cluster, so we may have following scenarios.\n> \n> DC\n>  |\n> \n>  |---Cluster1\n>  |      |\n> \n>  |      |---host1\n>  |\n> \n>  |---Cluser2\n>         |\n> \n>         |---host2\n> \n> \n> Then when using VCDriver, I can use one nova compute manage both\n> Cluster1 and Cluster2, this caused me cannot migrate VM from host2 to\n> host1 ;-(\n> \n> \n> The bp was introduced by\n> https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service\n\nWell, it seems to me that the problem is the above blueprint and the\ncode it introduced. This is an anti-feature IMO, and probably the best\nsolution would be to remove the above code and go back to having a\nsingle nova-compute managing a single vCenter cluster, not multiple\nones.\n\n-jay\n\n\n\n\n','<CAFyztAF2+1hQkr+tuazigYtdx+MopZVRmDC8CHd0vkuhCi10Fg@mail.gmail.com>',NULL),('<1396734046.3044.19.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-05 17:40:46',-14400,'2014-04-05 21:40:46',NULL,'[Openstack-operators] Quota Templates','On Sat, 2014-04-05 at 14:56 -0600, Joe Topjian wrote:\n> Hi Jay,\n> \n>         The only problem with this is that what happens if an instance\n>         type\'s\n>         underlying resource allocation changes? Quotas and\n>         reservations\n>         generally need to be on the actual resources that are\n>         consumed, not on\n>         an abstract representation of those resources like an instance\n>         type, due\n>         to the fact that the abstract representation can changes over\n>         time.\n>         \n>         My idea about the UI above works nicely with the idea of\n>         changeable\n>         instance types. The UI can do simple real-time calculations\n>         about what a\n>         quota allocation represents in terms of the actual resources\n>         used by an\n>         instance type.\n> \n> \n> Yes, but there is nothing limiting a user to only a set amount of a\n> certain resource in a certain environment.\n> \n> Perhaps I am misunderstanding this discussion, but here is an example\n> scenario of how I see it:\n> \n> I have a small set of compute nodes that are configured in such a way\n> that make them \"special\" (SSD, GPU, etc). I can put those compute\n> nodes in a host aggregate and tie a series of flavors to that host\n> aggregate. \n> \n> But since there is only one quota that the user has, there is nothing\n> that is preventing a user from hogging a large majority of the those\n> \"special\" nodes. For example, if a user has a quota of 500 cpus and\n> 800gb of memory, and if the \"special\" nodes collectively only have\n> 1500 cpus and 2400gb of memory, the user could consume 1/3rd of the\n> special resources.\n> \n> However, if I was able to tie a separate quota to that host aggregate,\n> I could give the user a quota of 50 cpus and 80gb of memory alongside\n> his standard quota of 500/800 for the rest of the cloud.\n> \n> I greatly apologize if this scenario is *not* what Narayan was talking\n> about. In addition, this is not a feature that I\'m personally in\n> desperate need for, but would definitely implement it if it was\n> available -- much more than a quota template.\n\nYes, the above scenario indeed is an interesting use case. Part of the\nissue is that with the addition of the \"extra specs\" part of the\ninstance type, the instance type no longer represents just the dedicated\nresources that the a single instance of that type consumes, but also a\nfree-form set of \"capabilities\" that the instance has -- GPU, SSD, etc.\n\nThe trick really is going to be about quantifying what those free-form\nqualitative \"tags\" like GPU actually represent when it comes to the\nconsumption of resources in Nova. As it stands now, quota management has\nno real way of differentiating one CPU unit from another. I imagine that\none solution to this would be to attach a \"weighting factor\" to each\nfree-form instance type extra spec that would effectively multiply the\nactual resource that is consumed by the instance of that type by the\nfactor, thereby producing a quantifiable value.\n\nFor example, let\'s say you had these two instance types:\n\n m1.small\n  - 2GB memory\n  - 10GB disk\n  - 1 CPU\n\n g1.small\n  - 2GB memory\n  - 10GB disk\n  - 1 CPU\n  - extra_specs:\n    - gpu\n    - ssd\n\nAn admin might assign the \"gpu\" extra spec a weighting factor of\n\"cpu:1.5\" and the \"ssd\" extra spec a weighting factor of \"disk:10.0\".\nThis could be used by the quota management system to effectively give\nthe g1.small instance type the following adjusted resource allocation:\n\n - 2GB memory\n - 1.5 CPU\n - 100GB disk\n\nMake sense?\n\n-jay\n\n\n\n\n\n','<CA+y7hvjSCycs0K=wTit8HJ585dJpxrqHf5NN=cUQqVi_SQn0pQ@mail.gmail.com>',NULL),('<1396848019.2663.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 01:20:19',-14400,'2014-04-07 05:20:19',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','On Sun, 2014-04-06 at 06:59 +0000, Nandavar, Divakar Padiyar wrote:\n> >> Well, it seems to me that the problem is the above blueprint and the code it introduced. This is an anti-feature IMO, and probably the best solution would be to remove the above code and go back to having a single >> nova-compute managing a single vCenter cluster, not multiple ones.\n> \n> Problem is not introduced by managing multiple clusters from single nova-compute proxy node.  \n\nI strongly disagree.\n\n> Internally this proxy driver is still presenting the \"compute-node\" for each of the cluster its managing.\n\nIn what way?\n\n>  What we need to think about is applicability of the live migration use case when a \"cluster\" is modelled as a compute.   Since the \"cluster\" is modelled as a compute, it is assumed that a typical use case of live-move is taken care by the underlying \"cluster\" itself.       With this there are other use cases which are no-op today like host maintenance mode, live move, setting instance affinity etc.,     In order to resolve this I was thinking of \n> \"A way to expose operations on individual ESX Hosts like Putting host in maintenance mode,  live move, instance affinity etc., by introducing Parent - Child compute node concept.   Scheduling can be restricted to Parent compute node and Child compute node can be used for providing more drill down on compute and also enable additional compute operations\".    Any thoughts on this?\n\nThe fundamental problem is that hacks were put in place in order to make\nNova defer control to vCenter, when the design of Nova and vCenter are\nnot compatible, and we\'re paying the price for that right now.\n\nAll of the operations you describe above -- putting a host in\nmaintenance mode, live-migration of an instance, ensuring a new instance\nis launched near or not-near another instance -- depend on a fundamental\ndesign feature in Nova: that a nova-compute worker fully controls and\nmanages a host that provides a place to put server instances. We have\ninternal driver interfaces for the *hypervisor*, not for the *manager of\nhypervisors*, because, you know, that\'s what Nova does.\n\nThe problem with all of the vCenter stuff is that it is trying to say to\nNova \"don\'t worry, I got this\" but unfortunately, Nova wants and needs\nto manage these things, not surrender control to a different system that\nhandles orchestration and scheduling in its own unique way.\n\nIf a shop really wants to use vCenter for scheduling and orchestration\nof server instances, what exactly is the point of using OpenStack Nova\nto begin with? What exactly is the point of trying to use OpenStack Nova\nfor scheduling and host operations when you\'ve already shelled out US\n$6,000 for vCenter Server and a boatload more money for ESX licensing?\n\nSorry, I\'m just at a loss why Nova was changed to accomodate vCenter\ncluster and management concepts to begin with. I just don\'t understand\nthe use case here.\n\nBest,\n-jay\n\n\n\n\n\n\n\n','<D61466214F4BD04A899971B7EAF40FF5299B673B@G4W3297.americas.hpqcorp.net>',NULL),('<1396889579.2663.25.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-07 12:52:59',-14400,'2014-04-07 16:52:59',NULL,'[Openstack-operators] Quota Templates','Thanks for you response, Narayan, this is an interesting discussion. See\ncomments below inline.\n\nOn Mon, 2014-04-07 at 11:38 -0500, Narayan Desai wrote:\n> On Sat, Apr 5, 2014 at 3:22 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Fri, 2014-04-04 at 20:39 -0500, Narayan Desai wrote:\n>         >> If you\'re interested in quotas, we have a completely\n>         different problem\n>         > with quotas that is a real showstopper for us. We have a\n>         really large\n>         > dynamic range in resource quantities for our different\n>         instance types.\n>         > (for example, we have 3 orders of magnitudes in the range of\n>         memory\n>         > configurations). This makes quotas pretty useless for us as\n>         they are\n>         > currently implemented, since you can\'t represent limits for\n>         these\n>         > different kinds of resources in the same quota.\n>         \n>         \n>         Why can\'t you? The resource is the memory, CPU, and disk used,\n>         not the instance type.\n>         \n>         Honestly, I think that this is a user-interface thing, not a\n>         quota\n>         management thing. In other words, have the quota-management UI\n>         show some translation help-text. For the user, it would be\n>         something like \"you have room for X m2.xlarge instances left\".\n>         For an admin it would be something like \"this quota allocation\n>         represents X m2.xlarge instances\".\n> \n> \n> I think that this assumption is the reason that we have the quota\n> system that we do. A resource like 1GB of memory isn\'t comparable\n> across all kinds of resources. It is if you have a simple hardware\n> configuration with relatively uniform hardware configurations, but\n> heterogeneity causes this not to work.\n> \n> For example, 1GB of memory on a 24 GB system is way different than 1GB\n> of memory on a 2TB system.\n\nHow so? If you said that 1GB of some super-fast RAM is different than\n1GB of normal RAM, I would agree with you (and point you to the\ndiscussion of weighting factors in my full previous ML response). But I\ndon\'t see any difference between 1GB of memory on systems with different\noverall amounts of the same type of memory.\n\n>  The costs are different, the resource allocation considerations are\n> different, etc.\n\nNo, the costs are the same. The resource allocation considerations are\nonly different in that the things providing the resource (the hosts)\nhave different available amounts of RAM. But that\'s not what quotas are\nabout. That\'s what scheduling/placement is about. It\'s two different\nthings.\n\n>  A model that assumes uniformity means that you can\'t do anything\n> sensible when resource costs and considerations aren\'t uniform across\n> your system.\n\nA model that assumes uniformity of the basic resource types is essential\nhere. A single CPU unit is the same as any other CPU unit. A GB of RAM\nis the same as any other GB of RAM. With weighting factors for given\nextra specs, you can influence the overall resource used (see my full\nresponse for how weighting factors could be used). But if you don\'t have\nuniformity of the base resources, you have no foundation from which to\napply quota management.\n\n> While keying off of instance types isn\'t perfect, and certainly\n> doesn\'t give you the model that you\'d like, you can make things work\n> based on an implicit resource model when using instances that you\n> can\'t do through resource reductionism.\n\nTwo problems with using the instance type for the model, instead of the\nbase resource types that the instance type has (and the weighting\nfactors of its extra specs):\n\n1) Instance types can and do change over time. Unless you\'ve decomposed\nthe instance type into its base resource types, you don\'t have any way\nto adjust quotas properly that reflect the usage of the underlying\nresources.\n\n2) Quota setting based on instance types would require a human making\ndecisions about capacity based on that human\'s (often flawed)\nunderstanding of how many of that instance type can \"fit\" into their\ndeployment. Things that humans do are unreliable compared with an\nalgorithmic approach to quota determination.\n\nBest,\n-jay\n\n\n\n\n','<CABweQmKfDFQ3pWXKvt82xXMnBeO9zLEkC=AOq51_ArHL8OjFGg@mail.gmail.com>',NULL),('<1396895506.3163964.1386344240975.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 10:37:20',-18000,'2013-12-06 15:37:20',NULL,'[openstack-dev] [TripleO][Tuskar] Questions around Development\n	Process','Hey all,\n\nWe\'re starting to work on the UI for tuskar based on Jarda\'s wireframes, and as we\'re doing so, we\'re realizing that\nwe\'re not quite sure what development methodology is appropriate.  Some questions:\n\na) Because we\'re essentially doing a tear-down and re-build of the whole architecture (a lot of the concepts in tuskar\nwill simply disappear), it\'s difficult to do small incremental patches that support existing functionality.  Is it okay\nto have patches that break functionality?  Are there good alternatives?\n\nb) In the past, we allowed parallel development of the UI and API by having well-documented expectations of what the API\nwould provide.  We would then mock those calls in the UI, replacing them with real API calls as they became available.  Is\nthis acceptable?\n\nIf there are precedents for this kind of stuff, we\'d be more than happy to follow them!\n\nThanks,\nTzu-Mainn Chen\n\n\n','<1699828159.3135109.1386341994805.JavaMail.root@redhat.com>',NULL),('<1396903773.2663.34.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 16:49:33',-14400,'2014-04-07 20:49:33',NULL,'[openstack-dev] [Nova] Hosts within two Availability\n	Zones	:	possible or not ?','On Mon, 2014-04-07 at 16:48 +0000, Day, Phil wrote:\n> Hi Sylvain,\n> \n> There was a similar thread on this recently ? which might be worth\n> reviewing:\n> http://lists.openstack.org/pipermail/openstack-dev/2014-March/031006.html \n> \n> Some interesting use cases were posted, and a I don?t think a\n> conclusion was reached, which seems to suggest this might be a good\n> case for a session in Atlanta. \n> \n> Personally I?m not sure that selecting more than one AZ really makes a\n> lot of sense ? they are generally objects which are few in number and\n> large in scale, so if for example there are 3 AZs and you want to\n> create two servers in different AZs, does it really help if you can do\n> the sequence: \n> \n> -         Create a server in any AZ\n> -         Find the AZ the server is in\n> -         Create a new server in any of the two remaining AZs \n> \n> Rather than just picking two from the list to start with ?\n\nOr doing this in Heat, where orchestration belongs?\n\nBest,\n-jay\n\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F0070325AF@G5W2737.americas.hpqcorp.net>',NULL),('<1396933068.4631.0.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 12:57:48',28800,'2014-04-08 04:57:48',NULL,'[openstack-dev] [oslo] Some Thoughts on Log Message ID\n Generation Blueprint','Thanks for the comments.\nMaybe we could just search the English log. :-)\n\nBut I just find it is hard to meet all requirements of log message id,\nJust some thought that we can avoid the message id generation by using\nthe English log.\nFor debug purpose, we can just read the English log.\n\nRegards,\n  Peng Wu\n\nOn Mon, 2014-04-07 at 11:19 -0500, Ben Nemec wrote:\n> On 04/03/2014 10:19 PM, Peng Wu wrote:\n> > Hi,\n> >\n> >    Recently I read the \"Separate translation domain for log messages\"\n> > blueprint[1], and I found that we can store both English Message Log and\n> > Translated Message Log with some configurations.\n> >\n> >    I am an i18n Software Engineer, and we are thinking about \"Add message\n> > IDs for log messages\" blueprint[2]. My thought is that if we can store\n> > both English Message Log and Translated Message Log, we can skip the\n> > need of Log Message ID Generation.\n> >\n> >    I also commented the \"Add message IDs for log messages\" blueprint[2].\n> >\n> >    If the servers always store English Log Messages, maybe we don\'t need\n> > the \"Add message IDs for log messages\" blueprint[2] any more.\n> >\n> >    Feel free to comment this proposal.\n> >\n> > Thanks,\n> >    Peng Wu\n> >\n> > Refer URL:\n> > [1]\n> > https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> > [2] https://blueprints.launchpad.net/oslo/+spec/log-messages-id\n> \n> As I recall, there were more reasons for log message ids than just i18n \n> issues.  There\'s also the fact that an error message might change \n> significantly from one release to another, but if it\'s still addressing \n> the same issue then the message id could be left alone so searching for \n> it would still return relevant results, regardless of the release.\n> \n> That said, I don\'t know if anyone is actually working on the message id \n> blueprint so I\'m not sure how much it matters at this point. :-)\n> \n> -Ben\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5342CFFC.8050407@nemebean.com>',NULL),('<1396942130.9157.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 08:28:50',3600,'2014-04-08 07:28:50',NULL,'[openstack-dev] [oslo] use of the \"oslo\" namespace package','On Mon, 2014-04-07 at 15:24 -0400, Doug Hellmann wrote:\n> We can avoid adding to the problem by putting each new library in its\n> own package. We still want the Oslo name attached for libraries that\n> are really only meant to be used by OpenStack projects, and so we need\n> a naming convention. I\'m not entirely happy with the \"crammed\n> together\" approach for oslotest and oslosphinx. At one point Dims and\n> I talked about using a prefix \"oslo_\" instead of just \"oslo\", so we\n> would have \"oslo_db\", \"oslo_i18n\", etc. That\'s also a bit ugly,\n> though. Opinions?\n\nUggh :)\n\n> Given the number of problems we have now (I help about 1 dev per week\n> unbreak their system),\n\nI\'ve seen you do this - kudos on your patience.\n\n>  I think we should also consider renaming the\n> existing libraries to not use the namespace package. That isn\'t a\n> trivial change, since it will mean updating every consumer as well as\n> the packaging done by distros. If we do decide to move them, I will\n> need someone to help put together a migration plan. Does anyone want\n> to volunteer to work on that?\n\nOne thing to note for any migration plan on this - we should use a new\npip package name for the new version so people with e.g.\n\n   oslo.config>=1.2.0\n\ndon\'t automatically get updated to a version which has the code in a\ndifferent place. You should need to change to e.g.\n\n  osloconfig>=1.4.0\n\n> Before we make any changes, it would be good to know how bad this\n> problem still is. Do developers still see issues on clean systems, or\n> are all of the problems related to updating devstack boxes? Are people\n> figuring out how to fix or work around the situation on their own? Can\n> we make devstack more aggressive about deleting oslo libraries before\n> re-installing them? Are there other changes we can make that would be\n> less invasive?\n\nI don\'t have any great insight, but hope we can figure something out.\nIt\'s crazy to think that even though namespace packages appear to work\npretty well initially, it might end up being so unworkable we would need\nto switch.\n\nMark.\n\n\n\n','<CADb+p3QsCq+TuxKdkKYNVbDuxJo6XVeRkXwE5zmh8WeHy9+nTg@mail.gmail.com>',NULL),('<1396960570.71936.YahooMailNeo@web140104.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 05:36:10',-25200,'2014-04-08 12:36:10',NULL,'[openstack-dev] Get Keystone user details','For an user with role as \"Member\" , how to get the contents of \"extra\" column from user table in keystone DB using python keystone \nAPI. Also for a user? who is already logged in from horizon how can this column be extracted on Django side.\n\n\n\nThanks,\nNaveen.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/901bd471/attachment.html>\n\n','<mailman.26.1396960032.1225.openstack-dev@lists.openstack.org>',NULL),('<1396962931-sup-641@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 06:37:25',-25200,'2014-04-08 13:37:25',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','Excerpts from Day, Phil\'s message of 2014-04-08 03:03:41 -0700:\n> > -----Original Message-----\n> > From: Robert Collins [mailto:robertc at robertcollins.net]\n> > Sent: 07 April 2014 21:01\n> > To: OpenStack Development Mailing List\n> > Subject: [openstack-dev] [TripleO] config options, defaults, oh my!\n> > \n> > So one interesting thing from the influx of new reviews is lots of patches\n> > exposing all the various plumbing bits of OpenStack. This is good in some\n> > ways (yay, we can configure more stuff), but in some ways its kindof odd -\n> > like - its not clear when https://review.openstack.org/#/c/83122/ is needed.\n> > \n> > I\'m keen to expose things that are really needed, but i\'m not sure that /all/\n> > options are needed - what do folk think? \n> \n> I\'m very wary of trying to make the decision in TripleO of what should\n> and shouldn\'t be configurable in some other project.    For sure the\n> number of config options in Nova is a problem, and one that\'s been\n> discussed many times at summits.   However I think you could also make\n> the case/assumption for any service that the debate about having a config\n> option has already been held within that service as part of the review\n> that merged that option in the code - re-running the debate about whether\n> something should be configurable via TripleO feels like some sort of\n> policing function on configurability above and beyond what the experts in\n> that service have already considered, and that doesn\'t feel right to me.\n> \n> Right now TripleO has a very limited view of what can be configured,\n> based as I understand on primarily what\'s needed for its CI job.\n> As more folks who have real deployments start to look at using TripleO\n> its inevitable that they are going to want to enable the settings that\n> are important to them to be configured.  I can\'t imagine that anyone is\n> going to add a configuration value for the sake of it, so can\'t we start\n> with the perspective that we are slowly exposing the set of values that\n> do need to be configured ?\n> \n\n<snip>\n\n> > \n> > So my proposal here - what I\'d like to do as we add all these config options to\n> > TripleO is to take the care to identify which of A/B/C/D they are and code\n> > them appropriately, and if the option is one of 1b) or 2b) make sure there is a\n> > bug in the relevant project about the fact that we\'re having to override a\n> > default. If the option is really a case of 1a) I\'m not sure we want it\n> > configurable at all.\n> > \n> \n> I\'m not convinced that anyone is in a position to judge that there is a\n> single right answer - I know the values that are right for my deployments,\n> but I\'m not arrogant enough to say that they universally applicable.\n> You only have to see the  wide range of Openstack Deployments presented\n> at every summit to know that that there a lot of different use cases out\n> there.   My worry is that if we try to have that debate in the context of\n> a TripleO review, then we\'ll just spin between opinions rather than make\n> the rapid progress towards getting the needed degree of configurability.\n> So I would rule out 1a and 1b as options.    Again it feels like any\n> debate about this really belongs back in the projects that TripleO is\n> deploying rather than TripleO itself.\n> \n\nTo me, TripleO isn\'t just OpenStack CI on a large scale. And TripleO isn\'t\n\"here\'s a generic set of tools, go build a cloud.\" At least, not yet,\nlikely some day.\n\nTo me, TripleO is first _a_ deployment of OpenStack. Meaning, we can\nconsider our first milestone reached when we have produced a consumable,\nhigh scale deployment of OpenStack using OpenStack to operate it.\n\nContributions that do not push us toward that milestone have an impact\non it. At the very least they distract our reviewers, and at most, they\nactively delay that milestone by adding complexity resulting in slower\nvelocity toward it.\n\nI don\'t mean to say that they\'re not welcome, as I think they add\nan incredible amount of value; we end up with a virtuous circle as\nwe gather users and contribution that is not directly related to our\nimmediate goals.\n\nHowever, what I\'m suggesting is that generic universal configurability of\nall of the services isn\'t the immediate goal. Many of these configuration\nknobs, while eventually necessary to widen the usability of TripleO in\na similar fashion to the rest of the OpenStack, will delay even the most\nnarrow initial usability of TripleO.\n\n> I\'m also not a great fan of considering a change in the default value\n> (in either TripleO or the original project) as an alternative -whether\n> the original default was a good choice or not there is a high chance\n> that someone is relying on it - so any change in a default needs to go\n> through a deprication period so that folks have a chance to explicitly\n> configure to keep the setting if they need to.  That patterns reasonably\n> well established in most of the projects, and as folks are now starting\n> to use TripleO I think it needs to have the same discipline.   It\'s a\n> pain for sure, but it\'s the only way to keep stable systems for people\n> consuming from trunk.\n> \n\nSeeing as TripleO has not reached its initial milestone (described above)\nI don\'t think we\'re at the point of configuration rigor just yet. That\nis certainly a topic for the summit though, as if we decide to go down\nthat road, I think we need to join the integrated release.\n\n> If the root cause of the problem is that every change to exploit a\n> configurable feature of a deployed service needs an explicit matching\n> change in TripleO, maybe that\'s a degree of tight coupling that needs\n> to be addressed by having a more generic mechanism ?\n>\n\nI think Dan Prince laid out a nice path for how this could be done to\ngive users consuming TripleO directly a generic mechanism. That certainly\nwould be something that near term would be useful and doesn\'t seem like\nit would add too much complexity.\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F007034D75@G5W2737.americas.hpqcorp.net>',NULL),('<1396963517.6927.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 09:25:17',-14400,'2014-04-08 13:25:17',NULL,'[openstack-dev] [Nova] Hosts within two Availability Zones\n	:	possible or not ?','On Tue, 2014-04-08 at 10:49 +0000, Day, Phil wrote:\n> On a large cloud you?re protect against this to some extent if the\n> number of servers is >> number of instances in the quota.\n> \n> However it does feel that there are a couple of things missing to\n> really provide some better protection: \n> \n> -         A quota value on the maximum size of a server group\n> -         A policy setting so that the ability to use service-groups\n> can be controlled on a per project basis \n\nAlternately, we could just have the affinity filters serve as weighting\nfilters instead of returning NoValidHosts.\n\nThat way, a request containing an affinity hint would cause the\nscheduler to prefer placing the new VM near (or not-near) other\ninstances in the server group, but if no hosts exist that meet that\ncriteria, the filter simply finds a host with the most (or fewest, in\ncase of anti-affinity) instances that meet the affinity criteria.\n\nBest,\n-jay\n\n> From: Khanh-Toan Tran [mailto:khanh-toan.tran at cloudwatt.com] \n> Sent: 08 April 2014 11:32\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Nova] Hosts within two Availability\n> Zones : possible or not ?\n> \n> ?Abusive usage? : If user can request anti-affinity VMs, then why\n> doesn?t he uses that? This will result in user constantly requesting\n> all his VMs being in the same anti-affinity group. This makes\n> scheduler choose one physical host per VM. This will quickly flood the\n> infrastructure and mess up with the objective of admin (e.g.\n> Consolidation that regroup VM instead of spreading, spared hosts,\n> etc) ; at some time it will be reported back that there is no host\n> available, which appears as a bad experience for user. \n> \n>  \n> \n>  \n> \n> De : Ian Wells [mailto:ijw.ubuntu at cack.org.uk] \n> Envoy? : mardi 8 avril 2014 01:02\n> ? : OpenStack Development Mailing List (not for usage questions)\n> Objet : Re: [openstack-dev] [Nova] Hosts within two Availability\n> Zones : possible or not ?\n> \n> \n>  \n> \n> On 3 April 2014 08:21, Khanh-Toan Tran <khanh-toan.tran at cloudwatt.com>\n> wrote:\n> \n>         Otherwise we cannot provide redundancy to client except using\n>         Region which\n>         is dedicated infrastructure and networked separated and\n>         anti-affinity\n>         filter which IMO is not pragmatic as it has tendency of\n>         abusive usage.\n>         \n>         \n>  \n> \n> \n> I\'m sorry, could you explain what you mean here by \'abusive usage\'?\n> \n> \n> \n> -- \n> \n> \n> Ian.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F007035153@G5W2737.americas.hpqcorp.net>',NULL),('<1396965633.17203.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 22:00:33',28800,'2014-04-08 14:00:33',NULL,'[openstack-dev] [Heat] heat is not present in keystone service-list','Hi all,\n\nI have been trying to install heat with devstack. As shown here http://docs.openstack.org/developer/heat/getting_started/on_devstack.html?\n\nI added the IMAGE_URLS to the locarc file. Then I ran unstack.sh and then stack.sh. Now, when I run heat stack-list, I get the following error:\n\n? ? $ heat stack-list?\n? ? publicURL endpoint for orchestration not found\n\nI found that some people got this error because of wrong endpoint in keystone service-list, but in my output there is no heat!\n\n? ? $ keystone service-list\n? ? +----------------------------------+----------+-----------+---------------------------+\n? ? | ? ? ? ? ? ? ? ?id ? ? ? ? ? ? ? ?| ? name ? | ? ?type ? | ? ? ? ?description ? ? ? ?|\n? ? +----------------------------------+----------+-----------+---------------------------+\n? ? | 808b93d2008c48f69d42ae7555c27b6f | ?cinder ?| ? volume ?| ? Cinder Volume Service ? |\n? ? | f57c596db43443d7975d890d9f0f4941 | cinderv2 | ?volumev2 | ?Cinder Volume Service V2 |\n? ? | d8567205287a4072a489a89959801629 | ? ec2 ? ?| ? ?ec2 ? ?| ?EC2 Compatibility Layer ?|\n? ? | 9064dc9d626045179887186d0b3647d0 | ?glance ?| ? image ? | ? ?Glance Image Service ? |\n? ? | 70cf29f8ceed48d0a39ba7e29481636d | keystone | ?identity | Keystone Identity Service |\n? ? | b6cca1393f814637bbb8f95f658ff70a | ? nova ? | ?compute ?| ? ?Nova Compute Service ? |\n? ? | 0af6de1208a14d259006f86000d33f0d | ?novav3 ?| computev3 | ?Nova Compute Service V3 ?|\n? ? | b170b6b212ae4843b3a6987c546bc640 | ? ?s3 ? ?| ? ? s3 ? ?| ? ? ? ? ? ? S3 ? ? ? ? ? ?|\n? ? +----------------------------------+----------+-----------+---------------------------+\n\nPlease help me resolve this error.\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/6cc12ba6/attachment.html>\n\n',NULL,NULL),('<1396969452.6927.16.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 11:04:12',-14400,'2014-04-08 15:04:12',NULL,'[openstack-dev] [nova] Question about modifying instance\n attribute(such as cpu-QoS, disk-QoS ) without shutdown the instance','On Tue, 2014-04-08 at 08:30 +0000, Zhangleiqiang (Trump) wrote:\n> Hi, Stackers, \n> \n> 	For Amazon, after calling ModifyInstanceAttribute API , the instance must be stopped. \n> \n> 	In fact, the hypervisor can online-adjust these attribute. But amzon and openstack do not support it.\n> 	\n> 	So I want to know what are your advice about introducing the capability of online adjusting these instance attribute?\n\nWhat kind of attributes?\n\nBest,\n-jay\n\n\n\n','<3A6795EA1206904E94BEC8EF9DF109AE1D566B74@SZXEMA512-MBX.china.huawei.com>',NULL),('<1396969994.13332.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-04-08 16:13:14',3600,'2014-04-08 15:13:14',NULL,'[openstack-tc] Proposed modifications to the bylaws (for\n meeting today)','On Tue, 2014-04-08 at 11:21 +0200, Thierry Carrez wrote:\n> Hi!\n> \n> I just received from Mark Radcliffe the proposed changes to the bylaws,\n> which we\'ll discuss at the TC meeting later today.\n> \n> Please find attached:\n> * A document showing the diff between current (15) and proposed (18)\n> * A document showing the diff between early proposed changes (17) and\n> currently-proposed changes (18)\n> \n> Mark Radcliffe added as comments:\n> \n> The second set of changes reflects comments raised at the last meeting\n> of the committee, particularly by Mark McLoughlin on behalf of the\n> Technical Committee.\n\nJust to be nitpicky about this - I didn\'t make my comments to Mark as\n\"on behalf of the TC\". I joined that call as a board member, but pointed\nout something the TC could take issue with.\n\nMark.\n\n> Version 18 has not yet been approved by the committee.  These changes\n> are meant to reflect the need to move from a ?module? based method of\n> determining when the trademark can be used to a more flexible method\n> which can be agreed upon by the Technical Committee and the Board. As I\n> said to Mark and I think that he passed on to the Technical Committee,\n> the reasons for the DefCore and these revisions are as follows:\n> \n> > I appreciate your comments at the Bylaws committee meeting.\n> > We don?t want to have the TC misunderstand the reasons for the bylaws\n> > change or their consequences. These changes are focused solely on\n> > determining how and when the trademark can be used.  We want to\n> > ensure that the TC has an active role in the decisions.\n> > Consequently, we will shift back to the use of ?core? for these\n> > procedures being set up. However, as I noted,  a number of members of\n> > DefCore Committee have expressed a desire to use a word other than\n> > ?core? for this concept so we may see an additional change in the\n> > name .\n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n\n','<5343BF8B.9070006@openstack.org>',NULL),('<1396977425-sup-2840@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 10:25:14',-25200,'2014-04-08 17:25:14',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','Excerpts from Jay Dobies\'s message of 2014-04-08 06:40:07 -0700:\n> > I\'m very wary of trying to make the decision in TripleO of what should and shouldn\'t be configurable in some other project.    For sure the number of config options in Nova is a problem, and one that\'s been discussed many times at summits.   However I think you could also make the case/assumption for any service that the debate about having a config option has already been held within that service as part of the review that merged that option in the code - re-running the debate about whether something should be configurable via TripleO feels like some sort of policing function on configurability above and beyond what the experts in that service have already considered, and that doesn\'t feel right to me.\n> \n> My general feeling is that I agree with this sentiment. In my experience \n> on management tools, there\'s always someone who wants to turn the one \n> knob I forgot to expose. And that\'s been on significantly simpler \n> projects than OpenStack; the complexity and scale of the features means \n> there\'s potentially a ton of tweaking to be done.\n> \n> More generally, this starts to drift into the bigger question of what \n> TripleO is. The notion of defaults or limiting configuration exposure is \n> for prescriptive purposes. \"You can change X because we think it\'s going \n> to have a major impact.\" If we don\'t expose Y, it\'s because we\'re \n> driving the user to not want to change it.\n> \n> I\'ve always assumed TripleO is very low-level. Put another way, \n> non-prescriptive. It\'s not going to push an agenda that says you should \n> be doing things a certain way, but rather gives you more than enough \n> rope to hang yourself (just makes it easier).\n> \n\nAnd I\'ve always looked at TripleO as the opposite. It is a default\ndeployment of OpenStack. That is why we look at having to set a\nnon-default option as a bug. That is why we only currently offer one\nset of Heat templates.\n\nOf course I want to see it more widely configurable, as I understand that\nthere will be whole sections of the OpenStack interested user base that\nwon\'t want an ovs overlay network. There will be shops that simply refuse\nto use MySQL, or want to put swift proxies on their own nodes, etc. etc.\n\nBut if we can\'t all agree on a widely usable set of defaults, and deploy\nthat, then I think OpenStack, not just TripleO, is forever going to be a\nframework on which proprietary solutions are built, rather than a whole\nopen source platform.\n\n> The question of how to make things easier to grok for a new user lies in \n> a different area. Either documentation (basic v. advanced user guide \n> sort of thing) or potentially in the Tuskar GUI. More configuration \n> options means Tuskar\'s life is more difficult, but to me, that\'s where \n> we add in the notion of \"You almost definitely want to configure these \n> things, but if you\'re really insane you can look at this other set of \n> stuff to configure.\"\n> \n> So I think we need to have a way of specifying everything. And we need \n> to have that way not kill us in the process. I like the proposed idea of \n> an open-ended config area. It\'s us acknowledging that we\'re sitting on \n> top of a dozen other projects. Admittedly, I don\'t fully understand \n> Slagle\'s proposal, but the idea of pulling in samples from other \n> projects and not making us acknowledge every configuration option is \n> also appealing.\n> \n\nDespite our differing views on what TripleO is today, I agree with the\nneed for an open ended config section.\n\n\n','<5343FC37.1040604@redhat.com>',NULL),('<1396980178-sup-7600@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 11:05:40',-25200,'2014-04-08 18:05:40',NULL,'[openstack-dev] [Ironic][Agent]','Excerpts from Vladimir Kozhukalov\'s message of 2014-04-08 03:04:38 -0700:\n> Guys, thank you very much for your comments,\n> \n> I thought a lot about why we need to be so limited in IPA use cases. Now it\n> much clearer for me. Indeed, having some kind of agent running inside host\n> OS is not what many people want to see. And now I\'d rather agree with that.\n> \n> But there are still some questions which are difficult to answer for me.\n> 0) There are a plenty of old hardware which does not have IPMI/ILO at all.\n> How Ironic is supposed to power them off and on? Ssh? But Ironic is not\n> supposed to interact with host OS.\n\nI don\'t think Ironic should try and manage this at all. If you\'ve no\nonboard controller, there are external power switches with network API\'s\nwhich can be used to power things on and off at the source.\n\n\n','<CAFLqvG6Ni8X3qfzThG6p+Vco=PUC4jP=yR0Ltj52iouw59pciA@mail.gmail.com>',NULL),('<1396986465.688.104254229.2219CD9C@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 12:47:45',-25200,'2014-04-08 19:47:45',NULL,'[openstack-dev] [TripleO] reviewer update march [additional\n	cores]','On Tue, Apr 8, 2014, at 12:30 PM, Jay Dobies wrote:\n> On 04/07/2014 07:50 PM, Robert Collins wrote:\n> > tl;dr: 3 more core members to propose:\n> > bnemec\n> > greghaynes\n> > jdon\n> \n> I\'m comfortable with committing to at least 3 reviews a day and promise \n> to wield the awesome power of +2 responsibly. I appreciate being \n> nominated :)\n> \n\nI am also comfortable with performing at least 3 reviews daily and would\nonly \nuse my new found powers responsibly. Thanks!\n\n> >\n> > On 4 April 2014 08:55, Chris Jones <cmsj at tenshu.net> wrote:\n> >> Hi\n> >>\n> >> +1 for your proposed -core changes.\n> >>\n> >> Re your question about whether we should retroactively apply the 3-a-day\n> >> rule to the 3 month review stats, my suggestion would be a qualified no.\n> >>\n> >> I think we\'ve established an agile approach to the member list of -core, so\n> >> if there are a one or two people who we would have added to -core before the\n> >> goalposts moved, I\'d say look at their review quality. If they\'re showing\n> >> the right stuff, let\'s get them in and helping. If they don\'t feel our new\n> >> goalposts are achievable with their workload, they\'ll fall out again\n> >> naturally before long.\n> >\n> > So I\'ve actioned the prior vote.\n> >\n> > I said: \"Bnemec, jdob, greg etc - good stuff, I value your reviews\n> > already, but...\"\n> >\n> > So... looking at a few things - long period of reviews:\n> > 60 days:\n> > |        greghaynes       |     121    0  22  99   0   0    81.8% |\n> > 14 ( 11.6%)  |\n> > |          bnemec         |     116    0  38  78   0   0    67.2% |\n> > 10 (  8.6%)  |\n> > |           jdob          |      87    0  15  72   0   0    82.8% |\n> > 4 (  4.6%)  |\n> >\n> > 90 days:\n> >\n> > |          bnemec         |     145    0  40 105   0   0    72.4% |\n> > 17 ( 11.7%)  |\n> > |        greghaynes       |     142    0  23 119   0   0    83.8% |\n> > 22 ( 15.5%)  |\n> > |           jdob          |     106    0  17  89   0   0    84.0% |\n> > 7 (  6.6%)  |\n> >\n> > Ben\'s reviews are thorough, he reviews across all contributors, he\n> > shows good depth of knowledge and awareness across tripleo, and is\n> > sensitive to the pragmatic balance between \'right\' and \'good enough\'.\n> > I\'m delighted to support him for core now.\n> >\n> > Greg is very active, reviewing across all contributors with pretty\n> > good knowledge and awareness. I\'d like to see a little more contextual\n> > awareness though - theres a few (but not many) reviews where looking\n> > at how the big picture of things fitting together more would have been\n> > beneficial. *however*, I think that\'s a room-to-improve issue vs\n> > not-good-enough-for-core - to me it makes sense to propose him for\n> > core too.\n> >\n> > Jay\'s reviews are also very good and consistent, somewhere between\n> > Greg and Ben in terms of bigger-context awareness - so another\n> > definite +1 from me.\n> >\n> > -Rob\n> >\n> >\n> >\n> >\n\n\n','<53444E6E.1060002@redhat.com>',NULL),('<1396991891.96883.YahooMailNeo@web163603.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 14:18:11',-25200,'2014-04-08 21:18:11',NULL,'[openstack-dev] Launch VM fails on Compute when VXLAN ML2 type\n	driver is used','Hello,\nI have two Openstack nodes (controller & Compute and a Compute). VM\'s are getting launched fine on the node that also acts as the controller. But, the VM\'s that are scheduled on the compute node seems to go to error state. I am running Icehouse version and my ML2 type driver is VXLAN. I used devstack for my installation. If I use non-tunnel mode and change it to VLAN, I don\'t see this error and VM\'s are launched fine in compute nodes as well.\nMy nova.conf in compute does have the following: \n\nneutron_url =?http://192.28.10.149:9696\n\nneutron_admin_auth_url =?http://192.28.10.149:35357/v2.0\nOfcourse, the above IP addresses of controller are reachable from compute.\nThis is what I have in my ml2_conf.ini in my controller. \n\n[ml2] \n\ntenant_network_types = vxlan\ntype_drivers = vxlan\nmechanism_drivers = openvswitch\nI assume this file on compute is not needed.\nThe error I see on Nova screen is : \n2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d -8e77-24a45dc7f652] File \"/opt/stack/python-neutronclient/neutronclient/v2_0/c lient.py\", line 1315, in _pagination 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] res = self.get(path, params=params) 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1288, in get 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] headers=headers, params=params) 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1280, in retry_request 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] raise\n exceptions.ConnectionFailed(reason=_(\"Maximum attempts reached\")) 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652] ConnectionFailed: Connection to neutron failed: Maximum attempts reached 2014-04-06 10:49:45.906 TRACE nova.compute.manager [instance: efede8e5-6bdb-4c2d-8e77-24a45dc7f652]\nPls let me know if you need more information.\nMy localrc on Controller is (relevant ones that i thought):\nenable_service q-l3\nenable_service quantum\nQ_PLUGIN=ml2\nQ_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch\nQ_ML2_TENANT_NETWORK_TYPE=vxlan\nQ_ML2_PLUGIN_TYPE_DRIVERS=vxlan\nQ_PLUGIN_EXTRA_CONF_PATH=/home/user1/ML2/devstack\nENABLE_TENANT_VLANS=False\nPHYSICAL_NETWORK=physnet2\nOVS_PHYSICAL_BRIDGE=br-eth3\nENABLE_TENANT_TUNNELS=True\n\nlocalrc on compute is:\nQ_PLUGIN=ml2\nQ_ML2_TENANT_NETWORK_TYPE=vxlan\nENABLE_TENANT_TUNNELS=True\nThanks, \n\nPaddu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/eb6793ac/attachment.html>\n\n',NULL,NULL),('<1397011084.90546.YahooMailNeo@web160302.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-08 19:38:04',-25200,'2014-04-09 02:38:04',NULL,'[Openstack] Could not find Service or Region in Service Catalog.','Hi all,\nI\'m going through the install in the docs with Ubuntu 14.04 and Icehouse. I\'m up to section 7, and am about to create my networks but this happens:\n\n# neutron net-create ext-net --shared --router:external=True\nCould not find Service or Region in Service Catalog.\n\nverbose:\nhttp://pastebin.com/MFvc2JBD\n\n\nkeystone endpoint-list:\nhttp://pastebin.com/cyDruETH\n\n\n# grep auth_region /etc/neutron/metadata_agent.ini\nauth_region = regionOne\n\nseems the regionOne value is correct.\n\nany pointers would be greatly appreciated.\n\naugust\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140408/eb3bf258/attachment.html>\n\n',NULL,NULL),('<1397012234.4986.1.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 10:57:14',28800,'2014-04-09 02:57:14',NULL,'[openstack-dev] [oslo] Some Thoughts on Log Message ID\n Generation Blueprint','Thanks, I see. :-)\n\nOn Tue, 2014-04-08 at 10:23 -0500, Ben Nemec wrote:\n> On 04/07/2014 11:57 PM, Peng Wu wrote:\n> > Thanks for the comments.\n> > Maybe we could just search the English log. :-)\n> \n> Right, but the problem is that the English log is not guaranteed to \n> remain the same.  An (extremely contrived) example:\n> \n> Say we have a log message like \"Failed to not find entity: %s\"\n> \n> That\'s really confusing because of the double negative.  So we change it \n> to \"Found an unexpected entity: %s\".  It\'s highly unlikely that a search \n> for the changed message is going to also turn up a blog post or whatever \n> about the first message.\n> \n> Granted the example is contrived, but I\'ve seen just that sort of log \n> message rewording done in real changes too.\n> \n> Maybe the dual logging is enough for everyone, but I don\'t think it \n> addresses all of the reasons for wanting message ids so I don\'t think we \n> can just say we\'re not going to do message ids because of it.  It\'s \n> perfectly valid to say we\'re not going to do message ids because no one \n> wants them enough to actually implement them though. :-)\n> \n> >\n> > But I just find it is hard to meet all requirements of log message id,\n> > Just some thought that we can avoid the message id generation by using\n> > the English log.\n> > For debug purpose, we can just read the English log.\n> >\n> > Regards,\n> >    Peng Wu\n> >\n> > On Mon, 2014-04-07 at 11:19 -0500, Ben Nemec wrote:\n> >> On 04/03/2014 10:19 PM, Peng Wu wrote:\n> >>> Hi,\n> >>>\n> >>>     Recently I read the \"Separate translation domain for log messages\"\n> >>> blueprint[1], and I found that we can store both English Message Log and\n> >>> Translated Message Log with some configurations.\n> >>>\n> >>>     I am an i18n Software Engineer, and we are thinking about \"Add message\n> >>> IDs for log messages\" blueprint[2]. My thought is that if we can store\n> >>> both English Message Log and Translated Message Log, we can skip the\n> >>> need of Log Message ID Generation.\n> >>>\n> >>>     I also commented the \"Add message IDs for log messages\" blueprint[2].\n> >>>\n> >>>     If the servers always store English Log Messages, maybe we don\'t need\n> >>> the \"Add message IDs for log messages\" blueprint[2] any more.\n> >>>\n> >>>     Feel free to comment this proposal.\n> >>>\n> >>> Thanks,\n> >>>     Peng Wu\n> >>>\n> >>> Refer URL:\n> >>> [1]\n> >>> https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain\n> >>> [2] https://blueprints.launchpad.net/oslo/+spec/log-messages-id\n> >>\n> >> As I recall, there were more reasons for log message ids than just i18n\n> >> issues.  There\'s also the fact that an error message might change\n> >> significantly from one release to another, but if it\'s still addressing\n> >> the same issue then the message id could be left alone so searching for\n> >> it would still return relevant results, regardless of the release.\n> >>\n> >> That said, I don\'t know if anyone is actually working on the message id\n> >> blueprint so I\'m not sure how much it matters at this point. :-)\n> >>\n> >> -Ben\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53441486.4070001@nemebean.com>',NULL),('<1397022080.94020.YahooMailNeo@web160302.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-08 22:41:20',-25200,'2014-04-09 05:41:20',NULL,'[Openstack] [Solved] Re: Could not find Service or Region in\n	Service Catalog.','my mistake. I created the service with type \"neutron\" not \"network\"\n\nroot at controller:~# keystone service-list\n+----------------------------------+----------+----------+----------------------------+\n|??????????????? id??????????????? |?? name?? |?? type?? |??????? description???????? |\n+----------------------------------+----------+----------+----------------------------+\n| 135b6260f1674ca89f0969342ec0cc15 |? glance? |? image?? |? OpenStack Image Service?? |\n| 3330fba92cd8417d87ebcc8cbaaa2a7f | keystone | identity | OpenStack Identity Service |\n| 591bd10495dd4371afd543534336fd4a | neutron? | neutron? |??? OpenStack Networking??? |\n| f1118360a1cb40adbeb1c05ea098903a |?? nova?? | compute? |???? OpenStack Compute????? |\n+----------------------------------+----------+----------+----------------------------+?\n\n\nworks now\n\n\n>________________________________\n> From: August Simonelli <augustsimonelli at yahoo.com>\n>To: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n>Sent: Wednesday, April 9, 2014 12:38 PM\n>Subject: Could not find Service or Region in Service Catalog.\n> \n>\n>\n>Hi all,\n>I\'m going through the install in the docs with Ubuntu 14.04 and Icehouse. I\'m up to section 7, and am about to create my networks but this happens:\n>\n>\n># neutron net-create ext-net --shared --router:external=True\n>Could not find Service or Region in Service Catalog.\n>\n>\n>verbose:\n>http://pastebin.com/MFvc2JBD\n>\n>\n>\n>keystone endpoint-list:\n>http://pastebin.com/cyDruETH\n>\n>\n>\n># grep auth_region /etc/neutron/metadata_agent.ini\n>auth_region = regionOne\n>\n>\n>seems the regionOne value is correct.\n>\n>\n>any pointers would be greatly appreciated.\n>\n>\n>august\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140408/d2bcbb3c/attachment.html>\n\n','<1397011084.90546.YahooMailNeo@web160302.mail.bf1.yahoo.com>',NULL),('<1397039776.91195.YahooMailNeo@web140103.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 03:36:16',-25200,'2014-04-09 10:36:16',NULL,'[openstack-dev] Get Keystone user details','source openrc demo demo\nkeystone user-list\nYou are not authorized to perform the requested action, admin_required. (HTTP 403)\n\n\n\n\nOn Tuesday, April 8, 2014 6:06 PM, Naveen Kumar.S <naveen882 at yahoo.com> wrote:\n \nFor an user with role as \"Member\" , how to get the contents of \"extra\" column from user table in keystone DB using python keystone \nAPI. Also for a user? who is already logged in from horizon how can this column be extracted on Django side.\n\n\n\nThanks,\nNaveen.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/edd5fd5d/attachment.html>\n\n','<1396960570.71936.YahooMailNeo@web140104.mail.bf1.yahoo.com>',NULL),('<1397047996.2954.7.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 08:53:16',-14400,'2014-04-09 12:53:16',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','Hi Juan, thanks for your response. Comments inline.\n\nOn Mon, 2014-04-07 at 10:22 +0200, Juan Manuel Rey wrote:\n> Hi, \n> \n> I\'m fairly new to this list, actually this is my first email sent, and\n> to OpenStack in general, but I\'m not new at all to VMware so I\'ll try\n> to give you my point of view about possible use case here. \n> \n> Jay you are saying that by using Nova to manage ESXi hosts we don\'t\n> need vCenter because they basically overlap in their capabilities.\n\nActually, no, this is not my main point. My main point is that Nova\nshould not change its architecture to fit the needs of one particular\nhost management platform (vCenter).\n\nNova should, as much as possible, communicate with vCenter to perform\nsome operations -- in the same way that Nova communicates with KVM or\nXenServer to perform some operations. But Nova should not be\nre-architected (and I believe that is what has gone on here with the\ncode change to have one nova-compute worker talking to multiple vCenter\nclusters) just so that one particular host management scheduler/platform\n(vCenter) can have all of its features exposed to Nova.\n\n>  I agree with you to some extent, Nova may have similar capabilities\n> as vCenter Server but as you know OpenStack as a full cloud solution\n> adds a lot more features that vCenter lacks, like multitenancy just to\n> name one.\n\nSure, however, my point is that Nova shouldn\'t need to be re-architected\njust to adhere to one particular host management platform\'s concepts of\nan atomic provider of compute resources.\n\n> Also in any vSphere environment managing ESXi hosts individually, this\n> is without vCenter, is completely out of the question. vCenter is the\n> enabler of many vSphere features. And precisely that\'s is, IMHO, the\n> use case of using Nova to manage vCenter to manage vSphere. Without\n> vCenter we only have a bunch of hypervisors and none of the HA or DRS\n> (dynamic resource balancing) capabilities that a vSphere cluster\n> provides, this in my experience with vSphere users/customers is a no\n> go scenario.\n\nUnderstood. Still doesn\'t change my opinion though :)\n\nBest,\n-jay\n\n> I don\'t know why the decision to manage vCenter with Nova was made but\n> based on the above I understand the reasoning.\n> \n> \n> Best,\n> ---\n> Juan Manuel Rey\n> \n> @jreypo\n> \n> \n> On Mon, Apr 7, 2014 at 7:20 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n>         On Sun, 2014-04-06 at 06:59 +0000, Nandavar, Divakar Padiyar\n>         wrote:\n>         > >> Well, it seems to me that the problem is the above\n>         blueprint and the code it introduced. This is an anti-feature\n>         IMO, and probably the best solution would be to remove the\n>         above code and go back to having a single >> nova-compute\n>         managing a single vCenter cluster, not multiple ones.\n>         >\n>         > Problem is not introduced by managing multiple clusters from\n>         single nova-compute proxy node.\n>         \n>         \n>         I strongly disagree.\n>         \n>         > Internally this proxy driver is still presenting the\n>         \"compute-node\" for each of the cluster its managing.\n>         \n>         \n>         In what way?\n>         \n>         >  What we need to think about is applicability of the live\n>         migration use case when a \"cluster\" is modelled as a compute.\n>         Since the \"cluster\" is modelled as a compute, it is assumed\n>         that a typical use case of live-move is taken care by the\n>         underlying \"cluster\" itself.       With this there are other\n>         use cases which are no-op today like host maintenance mode,\n>         live move, setting instance affinity etc.,     In order to\n>         resolve this I was thinking of\n>         > \"A way to expose operations on individual ESX Hosts like\n>         Putting host in maintenance mode,  live move, instance\n>         affinity etc., by introducing Parent - Child compute node\n>         concept.   Scheduling can be restricted to Parent compute node\n>         and Child compute node can be used for providing more drill\n>         down on compute and also enable additional compute\n>         operations\".    Any thoughts on this?\n>         \n>         \n>         The fundamental problem is that hacks were put in place in\n>         order to make\n>         Nova defer control to vCenter, when the design of Nova and\n>         vCenter are\n>         not compatible, and we\'re paying the price for that right now.\n>         \n>         All of the operations you describe above -- putting a host in\n>         maintenance mode, live-migration of an instance, ensuring a\n>         new instance\n>         is launched near or not-near another instance -- depend on a\n>         fundamental\n>         design feature in Nova: that a nova-compute worker fully\n>         controls and\n>         manages a host that provides a place to put server instances.\n>         We have\n>         internal driver interfaces for the *hypervisor*, not for the\n>         *manager of\n>         hypervisors*, because, you know, that\'s what Nova does.\n>         \n>         The problem with all of the vCenter stuff is that it is trying\n>         to say to\n>         Nova \"don\'t worry, I got this\" but unfortunately, Nova wants\n>         and needs\n>         to manage these things, not surrender control to a different\n>         system that\n>         handles orchestration and scheduling in its own unique way.\n>         \n>         If a shop really wants to use vCenter for scheduling and\n>         orchestration\n>         of server instances, what exactly is the point of using\n>         OpenStack Nova\n>         to begin with? What exactly is the point of trying to use\n>         OpenStack Nova\n>         for scheduling and host operations when you\'ve already shelled\n>         out US\n>         $6,000 for vCenter Server and a boatload more money for ESX\n>         licensing?\n>         \n>         Sorry, I\'m just at a loss why Nova was changed to accomodate\n>         vCenter\n>         cluster and management concepts to begin with. I just don\'t\n>         understand\n>         the use case here.\n>         \n>         Best,\n>         -jay\n>         \n>         \n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAM5kVNp_+BqEa3gSarSZCyvxvWH8_4R3qb=QA=gg2QMH4DZUag@mail.gmail.com>',NULL),('<1397048702.2954.14.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 09:05:02',-14400,'2014-04-09 13:05:02',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','On Mon, 2014-04-07 at 15:47 +0100, Matthew Booth wrote:\n> On 07/04/14 06:20, Jay Pipes wrote:\n> > On Sun, 2014-04-06 at 06:59 +0000, Nandavar, Divakar Padiyar wrote:\n> >>>> Well, it seems to me that the problem is the above blueprint and the code it introduced. This is an anti-feature IMO, and probably the best solution would be to remove the above code and go back to having a single >> nova-compute managing a single vCenter cluster, not multiple ones.\n> >>\n> >> Problem is not introduced by managing multiple clusters from single nova-compute proxy node.  \n> > \n> > I strongly disagree.\n> > \n> >> Internally this proxy driver is still presenting the \"compute-node\" for each of the cluster its managing.\n> > \n> > In what way?\n> > \n> >>  What we need to think about is applicability of the live migration use case when a \"cluster\" is modelled as a compute.   Since the \"cluster\" is modelled as a compute, it is assumed that a typical use case of live-move is taken care by the underlying \"cluster\" itself.       With this there are other use cases which are no-op today like host maintenance mode, live move, setting instance affinity etc.,     In order to resolve this I was thinking of \n> >> \"A way to expose operations on individual ESX Hosts like Putting host in maintenance mode,  live move, instance affinity etc., by introducing Parent - Child compute node concept.   Scheduling can be restricted to Parent compute node and Child compute node can be used for providing more drill down on compute and also enable additional compute operations\".    Any thoughts on this?\n> > \n> > The fundamental problem is that hacks were put in place in order to make\n> > Nova defer control to vCenter, when the design of Nova and vCenter are\n> > not compatible, and we\'re paying the price for that right now.\n> > \n> > All of the operations you describe above -- putting a host in\n> > maintenance mode, live-migration of an instance, ensuring a new instance\n> > is launched near or not-near another instance -- depend on a fundamental\n> > design feature in Nova: that a nova-compute worker fully controls and\n> > manages a host that provides a place to put server instances. We have\n> > internal driver interfaces for the *hypervisor*, not for the *manager of\n> > hypervisors*, because, you know, that\'s what Nova does.\n> \n> I\'m going to take you to task here for use of the word \'fundamental\'.\n> What does Nova do? Apparently: \'OpenStack Nova provides a cloud\n> computing fabric controller, supporting a wide variety of virtualization\n> technologies, including KVM, Xen, LXC, VMware, and more. In addition to\n> its native API, it includes compatibility with the commonly encountered\n> Amazon EC2 and S3 APIs.\' There\'s nothing in there about the ratio of\n> Nova instances to hypervisors: that\'s an implementation detail. Now this\n> change may or may not sit well with design decisions which have been\n> made in the past, but the concept of managing multiple clusters from a\n> single Nova instance is certainly not fundamentally wrong. It may not be\n> pragmatic; it may require further changes to Nova which were not made,\n> but there is nothing about it which is fundamentally at odds with the\n> stated goals of the project.\n> \n> Why did I bother with that? I think it\'s in danger of being lost. Nova\n> has been around for a while now and it has a lot of code and a lot of\n> developers behind it. We need to remember, though, that\'s it\'s all for\n> nothing if nobody wants to use it. VMware is different, but not wrong.\n> Let\'s stay fresh.\n\nPlease see my previous email to Juan about this. I\'m not anti-VMWare.\nI\'m just opposed to changing an important part of the implementation of\nNova just so that certain vCenter operations can be supported.\n\n> > The problem with all of the vCenter stuff is that it is trying to say to\n> > Nova \"don\'t worry, I got this\" but unfortunately, Nova wants and needs\n> > to manage these things, not surrender control to a different system that\n> > handles orchestration and scheduling in its own unique way.\n> \n> Again, I\'ll flip that round. Nova *currently* manages these things, and\n> working efficiently with a platform which also does these things would\n> require rethinking some design above the driver level. It\'s not\n> something we want to do naively, which the VMware driver is suffering\n> from in this area. It may take time to get this right, but we shouldn\'t\n> write it off as fundamentally wrong. It\'s useful to users and not\n> fundamentally at odds with the project\'s goals.\n\nI\'m not writing off vCenter or its capabilities. I am arguing that the\nbar for modifying a fundamental design decision in Nova -- that of being\nhorizontally scalable by having a single nova-compute worker responsible\nfor managing a single provider of compute resources -- was WAY too low,\nand that this decision should be revisited in the future (and possibly\nas part of the vmware driver refactoring efforts currently underway by\nthe good folks at RH and VMWare).\n\n> > If a shop really wants to use vCenter for scheduling and orchestration\n> > of server instances, what exactly is the point of using OpenStack Nova\n> > to begin with? What exactly is the point of trying to use OpenStack Nova\n> > for scheduling and host operations when you\'ve already shelled out US\n> > $6,000 for vCenter Server and a boatload more money for ESX licensing?\n> \n> I confess I wondered this myself. However, I have now spoken to real\n> people who are spending real money doing exactly this. The drivers seem\n> to be:\n> \n> * The external API\n> * A heterogeneous cloud\n> \n> vSphere isn\'t really designed for the former and doesn\'t do it well. It\n> obviously doesn\'t help with the latter at all. For example, users want\n> to be able to give non-admin customers the ability to deploy across both\n> KVM and VMware.\n> \n> To my mind, a VMware cluster is an obvious deployment target. I think\n> it\'s reasonable for Nova to treat it like a single hypervisor, but with\n> non-uniform resources (which would require a change in, or at least an\n> addition to, the current data model).\n\nThat is a big and important change, and one that should not be taken\nlightly.\n\n>  Maybe something like extreme NUMA.\n> I don\'t think it makes sense for Nova to concern itself with migrating\n> VMs between hosts in a cluster. Putting a cluster into maintenance mode\n> would involve the whole cluster, but the vSphere administrator obviously\n> has other options.\n> \n> The fact that we can\'t migrate a VM between 2 clusters is clearly a bug.\n\nIs it?\n\n> Whether a single Nova should manage multiple clusters is an open\n> question, but it should be able to treat them as multiple targets. It\'s\n> not fundamentally wrong, though.\n> \n> Matt\n> \n\n\n\n\n','<5342BA87.3090902@redhat.com>',NULL),('<1397058163.22812.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 16:42:43',3600,'2014-04-09 15:42:43',NULL,'[openstack-dev] [olso][neutron] proxying oslo.messaging from\n management network into tenant network/VMs','Hi,\n\nOn Wed, 2014-04-09 at 17:33 +0900, Isaku Yamahata wrote:\n> Hello developers.\n> \n> \n> As discussed many times so far[1], there are many projects that needs\n> to propagate RPC messages into VMs running on OpenStack. Neutron in my case.\n> \n> My idea is to relay RPC messages from management network into tenant\n> network over file-like object. By file-like object, I mean virtio-serial,\n> unix domain socket, unix pipe and so on.\n> I\'ve wrote some code based on oslo.messaging[2][3] and a documentation\n> on use cases.[4][5]\n> Only file-like transport and proxying messages would be in oslo.messaging\n> and agent side code wouldn\'t be a part of oslo.messaging.\n> \n> \n> use cases:([5] for more figures)\n> file-like object: virtio-serial, unix domain socket, unix pipe\n> \n>   server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM\n>                       per VM\n> \n>   server <-> AMQP <-> agent in host <-unix socket/pipe->\n>              agent in tenant network <-> guest agent in VM\n> \n> \n> So far there are security concerns to forward oslo.messaging from management\n> network into tenant network. One approach is to allow only cast-RPC from\n> server to guest agent in VM so that guest agent in VM only receives messages\n> and can\'t send anything to servers. With unix pipe, it\'s write-only\n> for server, read-only for guest agent.\n> \n> \n> Thoughts? comments?\n\nNice work. This is a pretty gnarly topic, but I think you\'re doing a\ngood job thinking through a good solution here.\n\nThe advantage this has over Marconi is that it avoids relying on\nsomething which might not be commonplace in OpenStack deployments for a\nnumber of releases yet.\n\nUsing vmchannel/virtio-serial to talk to an oslo.messaging proxy server\n(with would have a configurable security policy) over a unix socket\noslo.messaging transport in order to allow limited bridging from the\ntenant network to management network ... definitely sounds like a\nreasonable proposal.\n\nLooking forward to your session at the summit! I also hope to look at\nyour patches before then.\n\nThanks,\nMark.\n\n\n\n> \n> \n> Details of Neutron NFV use case[6]:\n> Neutron services so far typically runs agents in host, the host agent\n> in host receives RPCs from neutron server, then it executes necessary\n> operations. Sometimes the agent in host issues RPC to neutron server\n> periodically.(e.g. status report etc)\n> It\'s desirable to make such services virtualized as Network Function\n> Virtualizaton(NFV), i.e. make those features run in VMs. So it\'s quite\n> natural approach to propagate those RPC message into agents into VMs.\n> \n> \n> [1] https://wiki.openstack.org/wiki/UnifiedGuestAgent\n> [2] https://review.openstack.org/#/c/77862/\n> [3] https://review.openstack.org/#/c/77863/\n> [4] https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server\n> [5] https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server\n> [6] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms\n\n\n\n\n','<20140409083349.GA31211@private.email.ne.jp>',NULL),('<1397058924.22812.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-04-09 16:55:24',3600,'2014-04-09 15:55:24',NULL,'[openstack-tc] Integrated, Core and the TC,\n a historical perspective (was: Revised Bylaws)','On Wed, 2014-04-09 at 12:01 +0200, Thierry Carrez wrote:\n> Evans, Eileen wrote:\n> > Mark, thanks very much for driving the discussion around the proposed changes to the Bylaws.\n> \n> Hi everyone,\n> \n> The meeting yesterday revealed some misunderstanding about what\n> prerogatives the Technical Committee (\"TC\") is attached to, and which\n> ones it isn\'t attached to. To understand our position, we have to give\n> some historical perspective.\n> \n> Before the Foundation was set up, the project was driven by a unique\n> board. It has had different names, ending with the Project Policy Board\n> (\"PPB\"). The PPB was responsible for determining what projects were part\n> of \"OpenStack\", being released together every 6 months. We called that\n> set of projects \"core\".\n> \n> When the Foundation was set up, we split the responsibilities of the PPB\n> into two entities. The TC would lead the technical aspects. The Board of\n> Directors (BoD) would lead everything else, especially where the name\n> \"OpenStack\" could be used (trademark usage).\n> \n> This created a grey area around \'core\'. It was two things: the projects\n> we decide, technically, to release together in an integrated fashion\n> every 6 months. But it was also the set of projects for which specific\n> trademark rules applied (right to call themselves OpenStack and/or\n> minimal set of projects you need to run to call your cloud \"OpenStack\").\n> One of those sets was clearly TC territory, the other was clearly BoD\n> territory, and yet we had the same name to describe both.\n> \n> The \"IncUp\" effort was created to bring clarity in that grey area. That\n> joint committee decided to create two concepts. On one side, the\n> \"integrated projects\" that make up the \"OpenStack release\" every 6\n> months. This is totally under the responsibility of the TC. On the other\n> side, the \"core\", a subset of those integrated projects over which the\n> BoD wants to assert specific trademark rules. This shall be completely\n> under the responsibility of the BoD.\n> \n> The benefit of that division is that it avoids one board to constantly\n> step on the toes of the other. The TC defines the \"integrated release\".\n> the BoD defines which subset of it is \"Core\".\n> \n> Now the issue is, the current bylaws do not exactly support that\n> language, so they need to be revised. The proposed changes try to\n> preserve the place of the TC in determining \"Core\", which I think fails\n> to reach the intended clarification target.\n> \n> The TC no longer needs to be involved in determining \"Core\", so there is\n> no need to preserve that in the bylaws. The TC can advise the BoD on the\n> technical side of DefCore, obviously, but in the end the BoD should\n> decide. The TC, however, still fully retains management \"of the\n> technical matters relating to the OpenStack Project\", and determines the\n> list of integrated projects, of which \"core\" is a subset. It might be\n> worth mentioning that.\n> \n> I think that matches what happened with IncUp and what is currently\n> happening around DefCore. The TC helps, but the process is driven and\n> final decisions are made at the DefCore subcommittee level. As long as\n> the \"integrated release\" contents are solely decided by the TC (and core\n> is a subset of that), I think we are fine.\n\nExcellent summary!\n\n> As a sidenote, it could be useful to clarify how integrated projects are\n> allowed to use the \"OpenStack\" name. We call the thing we release every\n> 6 months \"OpenStack\". It\'s made of a set of integrated projects (decided\n> by the TC), it sounds logical that those subprojects can call themselves\n> OpenStack X. Maybe that could be a specific provision of the trademark\n> rules rather than the bylaws though.\n\nYes, this is getting a little lost in the more important issue about\ndefining the \"what you need to include/implement in order to call your\ncloud an OpenStack cloud\".\n\nWe do not think that a project calling itself e.g. OpenStack\nOrchestration implies that it should be required to be included in a\nproduct that wants to use the OpenStack brand. These are orthogonal\nquestions.\n\nIndeed this is what the TC asked the Board of Directors to approve here:\n\n  https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names\n\nSo, Thierry makes a good point - this is a highly related issue which we\nshould be aiming to resolve here.\n\n> I hope this clarifies the concerns we have with the proposed bylaws\n> changes. I think they fail to bring the much-needed clarification around\n> \"core\" and TC and BoD responsibilities, and try to preserve a TC right\n> that we\'ve been hard at work abandoning.\n\nI too hope this helps clear up the confusion. Thanks Thierry.\n\nMark.\n\n\n\n','<53451A8A.2090908@openstack.org>',NULL),('<1397064265-sup-4516@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 10:31:11',-25200,'2014-04-09 17:31:11',NULL,'[openstack-dev] [olso][neutron] proxying oslo.messaging from\n	management network into tenant network/VMs','Excerpts from Isaku Yamahata\'s message of 2014-04-09 01:33:49 -0700:\n> Hello developers.\n> \n> \n> As discussed many times so far[1], there are many projects that needs\n> to propagate RPC messages into VMs running on OpenStack. Neutron in my case.\n> \n> My idea is to relay RPC messages from management network into tenant\n> network over file-like object. By file-like object, I mean virtio-serial,\n> unix domain socket, unix pipe and so on.\n> I\'ve wrote some code based on oslo.messaging[2][3] and a documentation\n> on use cases.[4][5]\n> Only file-like transport and proxying messages would be in oslo.messaging\n> and agent side code wouldn\'t be a part of oslo.messaging.\n> \n> \n> use cases:([5] for more figures)\n> file-like object: virtio-serial, unix domain socket, unix pipe\n> \n>   server <-> AMQP <-> agent in host <-virtio serial-> guest agent in VM\n>                       per VM\n> \n>   server <-> AMQP <-> agent in host <-unix socket/pipe->\n>              agent in tenant network <-> guest agent in VM\n> \n> \n> So far there are security concerns to forward oslo.messaging from management\n> network into tenant network. One approach is to allow only cast-RPC from\n> server to guest agent in VM so that guest agent in VM only receives messages\n> and can\'t send anything to servers. With unix pipe, it\'s write-only\n> for server, read-only for guest agent.\n> \n\nHi Isaku. I like that you are bringing some new energy into this\ndiscussion.\n\nWhat if we swapped your local socket out for a connection managed by\nsomething similar to the neutron metadata agent that forwards connections\nto the EC2 metadata service? I could see a scheme something like this:\n\n- guest boots, agent contacts link-local on port 80 with a REST request\n  for a communication channel to service XYZ.\n- metadata agent is allocated a port on the network of the agent and\n  proxies that port to the intended endpoint.\n- guest now communicates directly with that address, still nicely\n  confined to the private network without any sort of gateway, but with\n  an ability to talk to \"under the cloud\" services.\n\nI prefer a scheme that uses the network because it will be generically\nusable no matter the transport desired (marconi, amqp, 0mq, whatever)\nand is directly modeled in Neutron\'s terms, rather than requiring tight\ncoupling with Nova and the hypervisors.\n\n\n','<20140409083349.GA31211@private.email.ne.jp>',NULL),('<1397065148-sup-7318@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 10:49:20',-25200,'2014-04-09 17:49:20',NULL,'[openstack-dev] [OpenStack-Infra][Ceilometer][MagnetoDB] HBase\n	database in devstack','Excerpts from Ruslan Kamaldinov\'s message of 2014-04-09 10:24:48 -0700:\n> On Tue, Apr 8, 2014 at 8:42 PM, Sean Dague <sean at dague.net> wrote:\n> > I think it\'s important to understand what we mean by \"stable\" in the\n> > gate. It means that the end point is 99.9999% available. And that it\'s\n> > up or down status is largely under our control.\n> >\n> > Things that are not stable by this definition which we\'ve moved away\n> > from for the gate:\n> >  * github.com - one of the reasons for git.openstack.org\n> >  * pypi.python.org - one of the reasons for our own pypi mirror\n> >  * upstream distro mirrors (we use cloud specific mirrors, which even\n> > then do fail some times, more than we\'d like)\n> >\n> > Fedora.org is not stable by this measure either. Downloading an iso from\n> > fedora.org fails 5% of the time in the gate.\n> >\n> > I\'m sure the Hortonworks folks are good folks, but by our standards of\n> > reliability, no one stacks up. And an outage on their behalf means that\n> > any project which gates on it will be blocked from merging any code\n> > until it\'s addressed. If Ceilometer wants to take that risk in their\n> > check queue (and be potentially blocked) that might be one thing, and we\n> > could talk about that. But we definitely can\'t co-gate and block all of\n> > openstack because of a hortonworks outage (which will happen, especially\n> > if we download packages from them 600 - 1000 times a day).\n> \n> A natural solution for this would be a local to infra package mirror for\n> HBase, Ceilometer, Mongo and all the dependencies not present in upstream\n> Ubuntu. It seems straightforward from the technical point of view. It\'ll help\n> to keep the Gate invulnerable to any outages in 3-rd party mirrors. Of course,\n> someone has to signup to create scripts for that mirror and support it in the\n> future.\n> \n> But, other concerns were expressed in the past. Let me quote Jeremy Stanley\n> (from https://review.openstack.org/#/c/66884/):\n> > This will need to be maintained in Ubuntu (and backported to 12.04 in Ubuntu\n> > Cloud Archive or if necessary a PPA managed by the same package maintenance\n> > team taking care of it in later Ubuntu releases). We don\'t install test\n> > requirements system-wide on our long-running test slaves unless we can be\n> > assured of security support from the Linux distribution vendor.\n> \n> There is no easy workaround here. Traditionally this kind of software is\n> installed from vendor-supported mirrors and distributions. And they\'re the\n> ones who maintain and provide security updates from Hadoop/HBase packages.\n> In case of Ceilometer, I think that importance of having real tests on real\n> databases is more important than the requirement for the packages to have\n> security support from a Linux distribution.\n\nThis is a huge philosophical question for OpenStack in general. Do we\nwant to recommend things that we won\'t, ourselves, use in our\ninfrastructure?\n\nI think for the most part we\'ve taken a middle of the road approach\nwhere we make sure the default backends and drivers are things that\n_are_ supported in distros, and are things we\'re able to use. We also\nlet in the crazy-sauce backend drivers for those who are willing to run\n3rd-party testing for them.\n\nSo I think what is needed here is for MagnetoDB to have at least one\nbackend that _is_ supported in distro, and legally friendly to OpenStack\nusers. Unfortunately:\n\n* HBase - not in any distro I could find (removed from Debian actually)\n* Cassandra - not in any distro\n* MongoDB - let\'s not have that license discussion again\n\nNow, this is no simple matter. When I attempted to package Cassandra for\nUbuntu 3 years ago, there was zero interest upstream in supporting it\nwithout embedding certain java libraries. The attempts at extracting the\nembedded libraries resulted in failed tests, patches, and an endless\nseries of \"why are you doing this?\" type questions from upstream.\nBasically the support model of the distro isn\'t compatible with the\nsupport model of these databases.\n\nWhat I think would have to happen, would be infra would need to be\nwilling to reach out and have a direct relationship with upstream for\nCassandra and HBase, and we would need to be willing to ask OpenStack\nusers to do the same. Otherwise, I don\'t think MagnetoDB could ever be\nintegrated with either of them as the default driver.\n\n\n','<CAPW-O+G9G5zhNvjBg6_x=SbPK1fuSpnRHgaJw+HatYVAPgKTdw@mail.gmail.com>',NULL),('<1397065854-sup-5639@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-09 10:55:13',-25200,'2014-04-09 17:55:13',NULL,'[Openstack] Fuel + Glance with Ceph','Excerpts from Alexandre De Carvalho\'s message of 2014-04-09 09:22:06 -0700:\n> Hi,\n> \n> I use ceph to store images. But i don\'t know where these images are stored.\n> I searched in /var/lib/glance/images/, nothing. So I put this line :\n> filesystem_store_datadir\n> = /var/lib/glance/images/ in /etc/glance/glance-api.conf. And i restarted\n> the service, but still nothing in /var/lib/glance/images.\n\nfilesystem_* is an option for the filesystem backend.\n\n> \n> When i create an image, they are stored in / and not in /var/lib/glance and\n> i don\'t know why.\n> \n\nIf you are in fact using CEPH and you have a CEPH cluster setup with\n/etc/ceph/ceph.conf, note that the store is called \'rbd\' in glance, not\n\"CEPH\":\n\nhttps://git.openstack.org/cgit/openstack/glance/tree/glance/store/rbd.py\n\nThe files will be in CEPH, not local at all... that is the point of\nusing CEPH. :)\n\n\n','<CADei+uRmSdC9bjgD_fiBTzStHWEaXESWV+YX9YKsjdeHF69Aeg@mail.gmail.com>',NULL),('<1397069204-sup-7396@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 12:05:35',-25200,'2014-04-09 19:05:35',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','Excerpts from Duncan Thomas\'s message of 2014-04-09 11:11:06 -0700:\n> On 8 April 2014 18:25, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Jay Dobies\'s message of 2014-04-08 06:40:07 -0700:\n> \n> >> I\'ve always assumed TripleO is very low-level. Put another way,\n> >> non-prescriptive. It\'s not going to push an agenda that says you should\n> >> be doing things a certain way, but rather gives you more than enough\n> >> rope to hang yourself (just makes it easier).\n> >>\n> >\n> > And I\'ve always looked at TripleO as the opposite. It is a default\n> > deployment of OpenStack. That is why we look at having to set a\n> > non-default option as a bug. That is why we only currently offer one\n> > set of Heat templates.\n> >\n> > Of course I want to see it more widely configurable, as I understand that\n> > there will be whole sections of the OpenStack interested user base that\n> > won\'t want an ovs overlay network. There will be shops that simply refuse\n> > to use MySQL, or want to put swift proxies on their own nodes, etc. etc.\n> >\n> > But if we can\'t all agree on a widely usable set of defaults, and deploy\n> > that, then I think OpenStack, not just TripleO, is forever going to be a\n> > framework on which proprietary solutions are built, rather than a whole\n> > open source platform.\n> \n> I think this is dangerous thinking - the config you want depends so\n> hugely on your intended workload and available hardware that trying\n> any strong view of what an Openstack deployment should look like into\n> the deployment tool forever forces that deployment tool to be a minor,\n> niche product that *has* to be replaced by something more expressive\n> in order to be widely usable. The config you want for a primary hadoop\n> shop is totally different to what you\'d want for primary web-host shop\n> is somewhat different to what you\'d want for a public/generic cloud,\n> etc. Things like AZ support, neutron model, cinder back-end choice,\n> H/A model etc are dictated by scale and use-cases. If you only want\n> your config tool to deal with one deployment type, that tool becomes\n> pretty much irrelevant to the totality of the Openstack effort, and\n> should be replaced by something more layered/openminded.\n> \n\nI can certainly understand how one might mistake TripleO as \"a deployment\ntool\".\n\nIt is no such thing. OpenStack is the deployment suite, with the tools\nbeing Nova, Glance, Neutron, Heat, diskimage-builder, os-*-config, etc.\n\nTripleO is a _program_, in the sense of an effort to gather collaborative\nforces, to deploy OpenStack using these tools. So any concern that you\nhave that these tools will end up being niche tools will in fact affect\nall of OpenStack.\n\nThe \"niche\" that we\'re aiming at is the broadest base of users that\nOpenStack has. That would be the ones who we have driven the defaults\ntoward. If there is no group of users that can use the defaults, then\nour first deployment will not have a large uptake beyond OpenStack\'s\nCI itself.\n\nHowever, there is nothing about this first goal of deploying a default\nOpenStack cloud that prevents us from then widening its purpose for more\nand more sets of users.\n\n> This isn\'t to say we must boil the ocean right now and make everything\n> available, but rather that decisions should take the long view into\n> account.\n> \n\nI don\'t think any of us suggested sacrificing the long term view for the\nshort term milestone. What I said is that what we\'re aiming at now as\na _milestone_ is not a widely configurable cloud, but a default cloud.\nAnd things that are done to support widening the tools\' focus slow\nprogress toward the current milestone.\n\nI get a sense that people are feeling adversarial toward this focus,\nrather than collaborative, and that troubles me. It may be my fault,\nso I want to make it very clear that I _do_ welcome any and all\ncontribution. If people are willing to put in the time to get things\ndone in TripleO, then that is hugely valuable. I\'m only suggesting that\nif you have a choice in what to do next, I suggest that it be things\nthat get us closer to our current milestones.\n\nThanks everyone for your thoughts on this.\n\n\n','<CAOyZ2aFxJeCxmMTXeBTN27mbsePhpPrTHw7r8yVKL9k+2CLrSg@mail.gmail.com>',NULL),('<1397074201-sup-784@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 13:33:18',-25200,'2014-04-09 20:33:18',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','Excerpts from Alexis Lee\'s message of 2014-04-09 06:44:20 -0700:\n> Robert Collins said on Wed, Apr 09, 2014 at 01:58:59AM +1200:\n> > I like this - something like\n> > \n> > nova:\n> >   config:\n> >     - section: default\n> >       values:\n> >         - option: \'compute_manager\'\n> >           value: \'ironic.nova.compute.manager.ClusterComputeManager\'\n> >     - section: cells\n> >       values:\n> >         - option: \'driver\'\n> >           value: nova.cells.rpc_driver.CellsRPCDriver\n> > \n> > \n> > should be able to represent most? all (it can handle repeating items)\n> > oslo.config settings and render it easily:\n> > \n> > {{#config}}\n> > {{#comment}} repeats for each section {{/comment}}\n> > [{{section}}]\n> > {{#values}}\n> > {{option}}={{value}}\n> > {{/values}}\n> > {{/config}}\n> \n> Hello,\n> \n> I\'ve gone some distance down this road:\n>   https://review.openstack.org/#/c/83353/6/elements/nova/os-apply-config/etc/nova/log.conf\n>   https://review.openstack.org/#/c/83422/6/logstash-source.yaml\n> \n> I wouldn\'t call the result - encoding a complete config file into Heat\n> metadata - pretty. And this isn\'t completely genericised either.\n> \n\nI find your templates pretty easy to read. Mustache was chosen because it\nhas almost no logic, and thus is _extremely_ easy to follow and predict.\n\n> It\'d be much better if TripleO image elements focused on installing and\n> starting services and allowed system integrators to define the\n> configuration. In one place, in plain text files, the UNIX way. I\'ve\n> appended my proposal to Rob\'s etherpad here:\n>   https://etherpad.openstack.org/p/tripleo-config-passthrough\n> \n\nThis assumes that we don\'t want system integrators to contribute to\nTripleO, which is the opposite of how things are. We absolutely do,\nand in fact, that is part of the point of having a program around\nOpenStack deployment. Let\'s get system integrators into OpenStack\'s CI\nsystem and let\'s get a few of the most important scenarios into the gate\nof OpenStack.\n\nAs a system integrator, do you want to say to your customers that you\nstart with an unusable set of tools that the community tests individually,\nor do you want to say that you start with the deployment that the\ncommunity tests directly on every commit, and then enhance based on\nindividual customer need?\n\n> Soon-to-be outdated copy appended here:\n> --------------------------------------------------------------------------------\n> \n> Hi Rob, I have some serious concerns about the above approaches. For the\n> sake of argument, let\'s suppose we want to write a file that looks like\n> a Heat template. How would you write a Mustache template that handles\n> that level of nesting? Even if you accomplish that, how readable do you\n> think the metadata to fill out that template would look?\n> \n> I see the system integration process emerging like this:\n>     * Figure out what files you want + what you want in them\n>     * Slice and dice that into metadata\n>     * Write some fairly complicated templates to reconstitute the metadata\n>     * Get out more or less what you started with\n> \n> I\'d like to propose an alternative method where Heat and TripleO barely\n> touch the config. The system integrator writes an image element per\n> node-flavour, EG \"mycorp-compute-config\". If they choose, they could\n> write more (EG for specific hardware) limited only by their\n> devtest-equivalent\'s ability to allocate those. This element contains a\n> 99-os-apply-config directory, the templates from which overwrite any\n> templates from normal os-apply-config directories in other elements.\n> os-apply-config/install.d/99-install-config-templates will need to be\n> patched for this to be possible, but this is very little work in\n> comparison to the alternatives. I could also support simply an\n> os-apply-config.override directory, if a full numbered set of dirs seems\n> overkill, but in this case normal elements would have to be forbidden\n> from using it (and people being as they are, someone would). The\n> templates in that directory are 99% plain config files, laid out in a\n> single filesystem structure exactly as the system integrator wants them.\n> The only templated values which need to be supplied by Heat are those\n> which vary per-instance.\n>\n\nSo one reason I\'d rather see overrides done generically as heat\nparameters/metadata/etc. is that it may not be entirely clear when a\nuser needs to override from a default, and having to distribute a new\nimage to do that is not necessarily the best user experience, especially\nif one is \"tinkering\".\n\n> If we do this, tripleo-image-elements should focus on installing and\n> starting services. They should only include a minimal viable\n> configuration for demo purposes. This should greatly reduce the amount\n> of work required to produce a new element. Also the number of Heat\n> parameters used by any element (only per-instance would be necessary,\n> anything further is a convenience).\n>\n\nOpenStack is not for demo purposes, it is for production usage. There\nis no reason we cannot and should not build a deployment that can be\nused directly in the most common configuration, and then open that up to\nmore and more users through configuration options and topology options.\n\n> Some usecases where this approach is superior:\n>     * Files where order is important, EG squid.conf\n>     * Files which multiple elements want to touch, EG nova.conf\n>     * When the system integrator wants to add config unforeseen by the\n>       appropriate element or where using an element would be\n>       heavyweight. EG to configure the MOTD or add a global vimrc.\n>     * Easy to add hardware-specific configuration\n> \n> Final thoughts - the \"mycorp-compute-config\" element might need to do a\n> bit of chmod + chown\'ing as well as just providing 99-os-apply-config.\n> \n> If OpenStack wants to provide a complete off-the-shelf configured\n> solution, we could provide a system integrator element which expresses\n> OpenStack opinion on what that solution should look like. In fact we\n> could provide several, suitable to different scales.\n> \n\nThis is exactly what we\'re doing. We\'re just suggesting exposing\nvariations in the Heat templates, rather than in the elements. It is worth\nnoting that Heat has grown the ability to grab a local file and inject\nit into your template at runtime. I think it would actually make sense\nto have os-apply-config enhanced to be able to override whole template\nfiles based on something like this:\n\n    resources:\n      server1:\n        metadata:\n          template_overrides:\n            \"/etc/nova/nova.conf\":\n              get_file [ \"my_special_nova.conf.template\" ]\n\nIn that, we achieve what you want, but we can do so without rebuilding\nthe whole image.\n\n\n','<20140409134420.GI31786@hp.com>',NULL),('<1397079671.85659.YahooMailNeo@web160303.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-09 14:41:11',-25200,'2014-04-09 21:41:11',NULL,'[Openstack] [OpenStack] VirtualInterfaceCreateException: Virtual\n	Interface creation failed','Hi all,\n\nI\'m following the Icehouse+Ubuntu14.04 docs and ran into an issue. I\'m building the whole thing on virtualbox, btw.\nI\'ve made it through to networking section and create my demo-net and ext-net. I can ping my ext-net router IP from my external physical network so it all looks good.\nI loaded the cirros image and try to launch it as a tiny with:\n\nnova boot --flavor m1.tiny --image cirros031 train01 --nic net-id=c76f0659-7af2-4779-a4c9-2a5754c99f96\n\n\nAfter a while it goes into error state and the compute log shows:\n\"VirtualInterfaceCreateException: Virtual Interface creation failed\"\n\nfull output:?\nhttp://pastebin.com/J2xqYAUd\n\nI noticed a lot of the Icehouse build defaults to ml2 and corrected it so all neutron processes are loading ovs configs (ie?/etc/default/neutron-server sets?NEUTRON_PLUGIN_CONFIG=\"/etc/neutron/plugins/ml2/ml2_conf.ini\").\n\nAny help appreciated. I\'m not sure what i\'ve missed.\n\ncheers,\naugust\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140409/3ef3181e/attachment.html>\n\n',NULL,NULL),('<1397130893.401.2.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-10 12:54:53',3600,'2014-04-10 11:54:53',NULL,'[openstack-dev] [OSSG][OSSN] OpenSSL Heartbleed vulnerability\n can lead to OpenStack compromise','On Thu, 2014-04-10 at 00:23 -0700, Nathan Kinder wrote:\n> OpenSSL Heartbleed vulnerability can lead to OpenStack compromise\n> ---\n> \n> ### Summary ###\n> A vulnerability in OpenSSL can lead to leaking of confidential data\n> protected by SSL/TLS in an OpenStack deployment.\n> \n> ### Affected Services / Software ###\n> Grizzly, Havana, OpenSSL\n> \n> ### Discussion ###\n> A vulnerability in OpenSSL code-named Heartbleed was recently discovered\n> that allows remote attackers limited access to data in the memory of any\n> service using OpenSSL to provide encryption for network communications.\n> This can include key material used for SSL/TLS, which means that any\n> confidential data that has been sent over SSL/TLS may be compromised.\n> For full details, see the following website that describes this\n> vulnerability in detail:\n> \n>     http://heartbleed.com/\n> \n> While OpenStack software itself is not directly affected, any deployment\n> of OpenStack is very likely using OpenSSL to provide SSL/TLS\n> functionality.\n> \n> ### Recommended Actions ###\n> It is recommended that you immediately update OpenSSL software on the\n> systems you use to run OpenStack services.\n\nNot sure if you want to mention it in this OSSN or consider doing it\ntoo, but clients are vulnerable to attack too.\n\n>   In most cases, you will want\n> to upgrade to OpenSSL version 1.0.1g, though it is recommended that you\n> review the exact affected version details on the Heartbleed website\n> referenced above.\n> \n> After upgrading your OpenSSL software, you will need to restart any\n> services that use the OpenSSL libraries.  You can get a list of all\n> processes that have the old version of OpenSSL loaded by running the\n> following command:\n> \n>     lsof | grep ssl | grep DEL\n> \n> Any processes shown by the above command will need to be restarted, or\n> you can choose to restart your entire system if desired.  In an\n> OpenStack deployment, OpenSSL is commonly used to enable SSL/TLS\n> protection for OpenStack API endpoints, SSL terminators, databases,\n> message brokers, and Libvirt remote access.  In addition to the native\n> OpenStack services, some commonly used software that may need to be\n> restarted includes:\n> \n>   Apache HTTPD\n>   Libvirt\n>   MySQL\n>   Nginx\n>   PostgreSQL\n>   Pound\n>   Qpid\n>   RabbitMQ\n>   Stud\n> \n> It is also recommended that you treat your existing SSL/TLS keys as\n> compromised and generate new keys.  This includes keys used to enable\n> SSL/TLS protection for OpenStack API endpoints, databases, message\n> brokers, and libvirt remote access.\n\nMight be worth mentioning certificate revocation too.\n\n> In addition, any confidential data such as credentials that have been\n> sent over a SSL/TLS connection may have been compromised.  It is\n> recommended that cloud administrators change any passwords, tokens, or\n> other credentials that may have been communicated over SSL/TLS.\n> \n> ### Contacts / References ###\n> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0012\n> OpenStack Security ML : openstack-security at lists.openstack.org\n> OpenStack Security Group : https://launchpad.net/~openstack-ossg\n> Heartbleed Website: http://heartbleed.com/\n> CVE: CVE-2014-0160\n\nVery nicely done Nathan.\n\nNot really relevant to the OSSN, but perhaps people will find it\ninteresting, I posted some thoughts on the wider fallout of heartbleed\nthis morning:\n\n  http://blogs.gnome.org/markmc/2014/04/10/heartbleed/\n\nThanks,\nMark.\n\n\n\n','<534646E8.8000308@redhat.com>',NULL),('<1397132649.401.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-04-10 13:24:09',3600,'2014-04-10 12:24:09',NULL,'[openstack-tc] Coordination of cross-project design summit\n sessions','On Wed, 2014-04-09 at 13:44 -0400, Russell Bryant wrote:\n\n> Here\'s my thinking for how to approach this.  Please let me know in the\n> next day or so if you would like to assist with putting the\n> cross-project track agenda together.\n\nHappy to help ... and look, I replied to your mail in under 19 hours!\nHow\'s that for rapid turnaround!\n\n(sigh)\n\nMark.\n\n\n\n','<534586F8.9010701@redhat.com>',NULL),('<1397147481.2879783.1353067774911.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 07:09:34',-18000,'2012-11-16 12:09:34',NULL,'[openstack-dev] [nova][ceilometer] model\n	for	ceilo/nova	interaction going forward','\n\n> you\'ve hit the nail on the head there with that final question ...\n> \n> Would the nova project be happy to accept:\n> \n>  (a) the ceilo compute agent repackaged as nova-compute-metering\n> \n> and,\n> \n>  (b) the deployment of an additional daemon per compute node\n> \n> It would be great if we could get some response to the above from\n> the nova \"leadership\" (loosely defined).\n> \n> Just to muddy the waters further if I may, let me throw a further\n> option into the mix:\n> \n> 5. nova packages a consumable library layered over the hypervisor\n>    driver, that just exposes the diagnostics available from libvirt\n>    et al. The ceilo compute agent continues to exist under the ceilo\n>    umbrella, but talks to the hypervisor directly via this stable,\n>    versioned nova library.\n> \n>    + no remote calls required from ceilo-->nova-{api|compute}\n>    - needs an independent versioning scheme\n>    - still stuck in the \"implicit trust\" model?\n\n\nFYI this thread was discussed at the nova IRC meeting yesterday[1].\n\nTL;DR: provisional good vibes from the nova side on option #5,\n       ceilo to follow up with a fleshing out of the proposed API\n\nCheers,\nEoghan\n\n\n[1] http://eavesdrop.openstack.org/meetings/nova/2012/nova.2012-11-15-21.04.log.html\n    #topic ceilometer/nova interaction as discussed on the ML\n\n\n','<751001626.2372782.1352979082292.JavaMail.root@redhat.com>',NULL),('<1397147867-sup-3007@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-10 09:45:17',-25200,'2014-04-10 16:45:17',NULL,'[openstack-dev] [TripleO] config options, defaults, oh my!','Excerpts from Alexis Lee\'s message of 2014-04-10 02:35:32 -0700:\n> Clint Byrum said on Wed, Apr 09, 2014 at 12:05:35PM -0700:\n> > Excerpts from Duncan Thomas\'s message of 2014-04-09 11:11:06 -0700:\n> > > I think this is dangerous thinking - the config you want depends so\n> > > hugely on your intended workload and available hardware that trying\n> > > any strong view of what an Openstack deployment should look like into\n> > > the deployment tool forever forces that deployment tool to be a minor,\n> > > niche product that *has* to be replaced by something more expressive\n> > > in order to be widely usable. The config you want for a primary hadoop\n> > > shop is totally different to what you\'d want for primary web-host shop\n> > > is somewhat different to what you\'d want for a public/generic cloud,\n> > > etc. Things like AZ support, neutron model, cinder back-end choice,\n> > > H/A model etc are dictated by scale and use-cases. If you only want\n> > > your config tool to deal with one deployment type, that tool becomes\n> > > pretty much irrelevant to the totality of the Openstack effort, and\n> > > should be replaced by something more layered/openminded.\n> \n> +1 to Duncan. While I can understand the urge to get something simple\n> working first before tackling more complex usecases, it\'s pointless if\n> in doing so you make those usecases even tougher.\n> \n\nI\'m not sure I understand where that has actually happened. TripleO\'s\ntarget is massive clouds, because OpenStack is about massive clouds. As\nI said, this is not about a demo, it is about a real usable cloud.\n\n> > I can certainly understand how one might mistake TripleO as \"a\n> > deployment tool\". It is no such thing. OpenStack is the deployment\n> > suite, with the tools being Nova, Glance, Neutron, Heat,\n> > diskimage-builder, os-*-config, etc. TripleO is a _program_, in the\n> > sense of an effort to gather collaborative forces, to deploy OpenStack\n> > using these tools.\n> \n> Now you\'ve described it, you\'re right, I\'m not interested in TripleO or\n> TripleO milestones. I am interested in using os-*-config, Heat and\n> tripleo-image-elements to produce pure OpenStack deployments from 3 to\n> 3000 nodes, for varying workloads.\n> \n\nThat is precisely what TripleO wants as that first  milestone too. What\nis the difference between what I said we want (a default OpenStack\ndeployment) and what you just said (a \"pure\" OpenStack deployment)? At\nwhat point did anybody suggest to you that TripleO doesn\'t want a highly\nscalable deployment of OpenStack?\n\n> To achieve this end I need tools which offer complete control of the\n> system configuration. I\'m very happy to work with TripleO to enhance our\n> shared tools but if in pursuit of TripleO milestones those tools are\n> hobbled, it\'s a problem.\n> \n\nI\'m not sure why you wouldn\'t just put the configuration you need\nin the upstream TripleO as the default configuration. Even more, why\nwouldn\'t you put these configurations in as the defaults for upstream\nNova/Glance/Cinder/Neutron/etc?\n\n\n','<20140410093532.GN31786@hp.com>',NULL),('<1397161988-sup-2919@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-10 13:39:35',-25200,'2014-04-10 20:39:35',NULL,'[openstack-dev] [TripleO] tripleo-heat-templates migration to\n	software-config: please rebase on top','Hi! For the last 2 weeks I\'ve been trying to prepare and land a change\nin tripleo-heat-templates to migrate to using OS::Heat::StructuredConfig\nand OS::Heat::StructuredDeployment so we can start deprecating features\nof merge.py.\n\nHowever, this is quite a large refactoring, and it will be complicated\nto do in pieces, so there is just one patch:\n\nhttps://review.openstack.org/#/c/81666/\n\nBecause this is such a large refactoring, merging new changes in is\nextremely time consuming and tedious.\n\nSo, I am asking that if you plan on editting any of the yaml files in\ntripleo-heat-templates, that you rebase on top of that change, and\nplease help test the migration.\n\nHopefully we can get this working and merged soon. Thank you!\n\n\n',NULL,NULL),('<1397228856.3048.13.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-11 11:07:36',-14400,'2014-04-11 15:07:36',NULL,'[openstack-dev] [Neutron] Security Group logging','On Wed, 2014-04-09 at 00:02 +0100, Salvatore Orlando wrote:\n> Auditing has been discussed for the firewall extension.\n> However, it is reasonable to expect some form of auditing for security\n> group rules as well.\n> \n> \n> To the best of my knowledge there has never been an explicit decision\n> to not support logging.\n> However, my guess here is that we might be better off with an auditing\n> service plugin integrating with security group and firewall agents\n> rather than baking the logging feature in the security group\n> extension.\n> Please note that I\'m just thinking aloud here.\n\n+1. A notification event should be sent across the typical notifier\nmechanisms when a security group rule is changed or applied.\n\nBest,\n-jay\n\n\n\n\n','<CAGR=i3jZh1u6-GU=EJHQozJ-+ve6DS6ZD9Epi6L7OY8J2YyuRA@mail.gmail.com>',NULL),('<1397247288-sup-4846@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-11 13:17:27',-25200,'2014-04-11 20:17:27',NULL,'[openstack-dev] [TripleO] tripleo-heat-templates migration to\n	software-config: please rebase on top','Another massive change just landed in front of 81666.\n\nhttps://review.openstack.org/#/c/84197/\n\nSo let me make my statement below a bit more clear:\n\nPlease do not land changes until this is fixed and merged. Every time\nI have to merge in the new changes is a few hours to a whole day of\nwork. If we keep landing changes in front of it, we will never get this\nrefactor done, which stands in the way of HA, rolling updates, and\ndeprecation of merge.py.\n\nThanks!\n\nExcerpts from Clint Byrum\'s message of 2014-04-10 13:39:35 -0700:\n> Hi! For the last 2 weeks I\'ve been trying to prepare and land a change\n> in tripleo-heat-templates to migrate to using OS::Heat::StructuredConfig\n> and OS::Heat::StructuredDeployment so we can start deprecating features\n> of merge.py.\n> \n> However, this is quite a large refactoring, and it will be complicated\n> to do in pieces, so there is just one patch:\n> \n> https://review.openstack.org/#/c/81666/\n> \n> Because this is such a large refactoring, merging new changes in is\n> extremely time consuming and tedious.\n> \n> So, I am asking that if you plan on editting any of the yaml files in\n> tripleo-heat-templates, that you rebase on top of that change, and\n> please help test the migration.\n> \n> Hopefully we can get this working and merged soon. Thank you!\n\n\n','<1397161988-sup-2919@fewbar.com>',NULL),('<1397264347.29543.YahooMailNeo@web163604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-11 17:59:07',-25200,'2014-04-12 00:59:07',NULL,'[openstack-dev] [NOVA][Neutron][ML2][Tunnel] Error in nova-agent\n	when launching VM in compute for Tunnel cases','Hello,\nI have two Openstack nodes (controller & Compute and a Compute). VM\'s are getting launched fine on the node that also acts as the controller. But, the VM\'s that are scheduled on the compute node seems to go to \nerror state. I am running Icehouse Master version and my ML2 type driver is GRE (even VXLAN has the same error) . I used devstack for my installation. If I use non-tunnel mode and change it to VLAN, I don\'t see this error and VM\'s are launched fine in compute nodes as well.\nMy devstack configuration on controller/compute is:\n\nQ_PLUGIN=ml2\nQ_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch\nQ_ML2_PLUGIN_TYPE_DRIVERS=gre\nENABLE_TENANT_TUNNELS=True\nTENANT_TUNNEL_RANGE=32000:33000\n\nThe error i see in compute nova screen is:\n\n2014-04-11 09:38:57.042 ERROR nova.compute.manager [-] [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516] An error occurred while refreshing the network cache.\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516] Traceback (most recent call last):\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/compute/manager.py\", line 4871, in _heal_instance_info_cache\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? self._get_instance_nw_info(context, instance, use_slave=True)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/compute/manager.py\", line 1129, in _get_instance_nw_info\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? instance)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/network/api.py\", line 48, in wrapper\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? res = f(self, context, *args, **kwargs)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/network/neutronv2/api.py\", line 465, in get_instance_nw_info\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? port_ids)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/network/neutronv2/api.py\", line 474, in _get_instance_nw_info\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? port_ids)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/nova/nova/network/neutronv2/api.py\", line 1106, in _build_network_info_model\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? data = client.list_ports(**search_opts)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 108, in with_params\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? ret = self.function(instance, *args, **kwargs)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 310, in list_ports\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? **_params)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1302, in list\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? for r in self._pagination(collection, path, **params):\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1315, in _pagination\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? res = self.get(path, params=params)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1288, in get\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? headers=headers, params=params)\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]?? File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1280, in retry_request\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516]???? raise exceptions.ConnectionFailed(reason=_(\"Maximum attempts reached\"))\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516] ConnectionFailed: Connection to neutron failed: Maximum attempts reached\n2014-04-11 09:38:57.042 TRACE nova.compute.manager [instance: b12490cc-a237-47e1-b2df-fe69d4a5e516] \n\nI did check that the URL seems to be right. The IP address of controller is specified right and compute can ping the controller.\n\nAny tips/suggestions on what could be wrong?\n\n\nThanks,\nPaddu\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140411/6c0d90d7/attachment.html>\n\n',NULL,NULL),('<1397313577.3433.6.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-12 10:39:37',-14400,'2014-04-12 14:39:37',NULL,'[OpenStack-Infra] Third Party Testing!','On Sat, 2014-04-12 at 15:37 +0800, Longgeek wrote:\n> How to apply for third party testing account?\n\nHi :) Please see here for instructions:\n\nhttp://ci.openstack.org/third_party.html#requesting-a-service-account\n\nBest,\n-jay\n\n\n\n\n','<96ABFB70-2B75-4CAA-AB12-9B23F8673512@thstack.com>',NULL),('<1397418440.67938363@beta.apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-13 15:47:20',-14400,'2014-04-13 19:47:20',NULL,'[Openstack] Glance 500 errors','I\'m working on setting up Havana on CentOS 6.5, bare metal.\n\nEverything seems cool up to here:\nhttp://docs.openstack.org/havana/install-guide/install/yum/content/glance-verify.html\n\nbut when I tried to load the test image into glance:\nglance image-create --name=\"CirrOS 0.3.1\" --disk-format=qcow2 \\\n  --container-format=bare --is-public=true < cirros-0.3.1-x86_64-disk.img\nI get a 500 error:\nhttp://pastie.org/private/l9hzbuacftyt9ashgt7ang\n\nI poked around, and discovered that I also get the same 500 error when I do a \nglance image-list:\n[root at box images]# glance image-list\nRequest returned failure status.\nHTTPInternalServerError (HTTP 500)\n\nDoing a curl:\ncurl -i -X GET -H \'X-Auth-Token: blahblah\' -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' http://192.168.20.1:9292/v1/images/detail?sort_key=name&sort_dir=asc&limit=20\nreturns:\nHTTP/1.1 500 Internal Server Error\nContent-Type: text/plain\nContent-Length: 0\nDate: Sun, 13 Apr 2014 19:44:51 GMT\nConnection: close\n\nSo, I googled, and I followed all the advice I found.  My filesystem_store_datadir\nis set, I verified that there is a service tenant in keystone and a glance user\nwith admin credentials in keystone, the sql data is in both glance-api.conf and\nglance-registry.conf, and is correct.  I verified that the unix user glance can\nwrite to the image store directory, and that the mysql user glance can read/write\nto the database glance, as specified.  \n\nSo, I bumped up to debug output for both the registry and api, and this is what\nI\'ve got:\nDoing a glance image-list, registry log:\nhttp://pastie.org/private/cshdglpjxasmitl480ljq\nDoing a glance image-list, api log:\nhttp://pastie.org/private/wkceq0bdrunsvvm9qemdow\nDoing a glance image-create blahblahblah, registry log:\nhttp://pastie.org/private/xxetsfl0nopcaszvsiemw\nDoing a glance image-create blahblahblah, api log:\nhttp://pastie.org/private/jmsa5y30xn6xpay77weea\n\nI can provide more info if needed, but I\'m stumped at this point.  Any suggestions?\n\n\nWill Dunn\n\n\n\n\n',NULL,NULL),('<1397486638-sup-9202@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 07:45:49',-25200,'2014-04-14 14:45:49',NULL,'[openstack-dev] deliver the vm-level HA to improve the business\n	continuity with openstack','Excerpts from Russell Bryant\'s message of 2014-04-14 07:18:49 -0700:\n> On 04/14/2014 09:45 AM, Jiangying (Jenny) wrote:\n> > Pacemaker provides the high availability for openstack infrastructure.\n> > \n> > We\'d like to deliver the vm-level HA to improve the business continuity\n> > with openstack.\n> > \n> > Besides host failure, Our HA mechanism can detect and report host\n> > isolation, network partition as well as ha agent down.\n> > \n> > Ha agent is placed on every node of the system. The master agent is\n> > elected automatically on system startup and others will be regarded as\n> > the slave.\n> > \n> > For the host states detection, the ha agents communicates through the\n> > storage subsystem as well as over the management network. Multiple\n> > communication paths enable better assessment of the health of the host.\n> > On host failure, the master agent selects the candidate hosts and calls\n> > the slave ha agents. The slave ha agents talk to the nova compute to\n> > restart the virtual machine. The master agent reacts to ha agent down by\n> > reporting to the administrator. During the network partition or host\n> > isolation event, the HA mechanism will not interrupt the virtual\n> > machines and just keep them running.\n> > \n> > For the virtual machine detection, the ha agents relies on nova compute\n> > for the information about virtual machines.\n> > \n> > Please let me know your comments on this.\n> \n> In the past we\'ve pushed back on this pretty heavily because it isn\'t\n> really relevant for new cloud-style architectures.  The push on this\n> functionality from a lot of users is pretty insistent so I expect it to\n> be added at some point in some way, it\'s just a question of the most\n> appropriate way.\n> \n> What I would like to see is to *not* have this be in Nova.  I\'d like to\n> make sure Nova exposes all necessary information and actions through the\n> API to make implementing this possible.  However, I think the\n> functionality generally belongs as something outside of Nova.\n> \n> If it\'s something that lives outside of Nova, then we should discuss it\n> in terms of public APIs (whether that\'s Nova\'s API, or a combination of\n> Nova and Ceilometer, perhaps).\n> \n\nFor the most part we\'ve been trying to encourage projects that want to\ncontrol VMs to add such functionality to the Orchestration program, aka\n\"Heat\".\n\n\n','<534BEE49.3000109@redhat.com>',NULL),('<1397496054.3233.5.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 13:20:54',-14400,'2014-04-14 17:20:54',NULL,'[openstack-dev] deliver the vm-level HA to improve the business\n continuity with openstack','On Mon, 2014-04-14 at 07:45 -0700, Clint Byrum wrote:\n> Excerpts from Russell Bryant\'s message of 2014-04-14 07:18:49 -0700:\n> > On 04/14/2014 09:45 AM, Jiangying (Jenny) wrote:\n> > > Pacemaker provides the high availability for openstack infrastructure.\n> > > \n> > > We\'d like to deliver the vm-level HA to improve the business continuity\n> > > with openstack.\n> > > \n> > > Besides host failure, Our HA mechanism can detect and report host\n> > > isolation, network partition as well as ha agent down.\n> > > \n> > > Ha agent is placed on every node of the system. The master agent is\n> > > elected automatically on system startup and others will be regarded as\n> > > the slave.\n> > > \n> > > For the host states detection, the ha agents communicates through the\n> > > storage subsystem as well as over the management network. Multiple\n> > > communication paths enable better assessment of the health of the host.\n> > > On host failure, the master agent selects the candidate hosts and calls\n> > > the slave ha agents. The slave ha agents talk to the nova compute to\n> > > restart the virtual machine. The master agent reacts to ha agent down by\n> > > reporting to the administrator. During the network partition or host\n> > > isolation event, the HA mechanism will not interrupt the virtual\n> > > machines and just keep them running.\n> > > \n> > > For the virtual machine detection, the ha agents relies on nova compute\n> > > for the information about virtual machines.\n> > > \n> > > Please let me know your comments on this.\n> > \n> > In the past we\'ve pushed back on this pretty heavily because it isn\'t\n> > really relevant for new cloud-style architectures.  The push on this\n> > functionality from a lot of users is pretty insistent so I expect it to\n> > be added at some point in some way, it\'s just a question of the most\n> > appropriate way.\n> > \n> > What I would like to see is to *not* have this be in Nova.  I\'d like to\n> > make sure Nova exposes all necessary information and actions through the\n> > API to make implementing this possible.  However, I think the\n> > functionality generally belongs as something outside of Nova.\n> > \n> > If it\'s something that lives outside of Nova, then we should discuss it\n> > in terms of public APIs (whether that\'s Nova\'s API, or a combination of\n> > Nova and Ceilometer, perhaps).\n> > \n> \n> For the most part we\'ve been trying to encourage projects that want to\n> control VMs to add such functionality to the Orchestration program, aka\n> \"Heat\".\n\nYes, exactly.\n\n-jay\n\n\n\n','<1397486638-sup-9202@fewbar.com>',NULL),('<1397498702.3233.10.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 14:05:02',-14400,'2014-04-14 18:05:02',NULL,'[openstack-dev] deliver the vm-level HA to improve the business\n continuity with openstack','On Mon, 2014-04-14 at 10:56 -0700, Steven Dake wrote:\n> On 04/14/2014 10:46 AM, Tim Bell wrote:\n> > Can Heat control/monitor a VM which it has not created and restart it (potentially on a different hypervisor with live migration) ?\n> >\n> > Tim\n> Tim,\n> \n> No it sure can\'t.\n\nBut a 10-20 line shell script could, calling nova CLI commands.\n\nI think the point here is that we see pushes like this to treat VMs as\npets and we\'ve so far been able to successfully push back on these\n(anti)feature requests, pointing out that this kind of thing generally\nis antithetical to a utility cloud model and antithetical to the\nhorizontal scale-out architecture that cloud espouses (i.e. don\'t have a\nsingle point of failure that requires this kind of setup).\n\n/me waits for someone to use the word \"enterprise\".\n\n-jay\n\n\n\n','<534C2133.6080200@redhat.com>',NULL),('<1397519599.3233.15.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 19:53:19',-14400,'2014-04-14 23:53:19',NULL,'[openstack-dev] deliver the vm-level HA to improve the business\n continuity with openstack','On Mon, 2014-04-14 at 18:30 +0000, Tim Bell wrote:\n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 14 April 2014 20:05\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] deliver the vm-level HA to improve the business continuity with openstack\n> > \n> > On Mon, 2014-04-14 at 10:56 -0700, Steven Dake wrote:\n> > > On 04/14/2014 10:46 AM, Tim Bell wrote:\n> > > > Can Heat control/monitor a VM which it has not created and restart it (potentially on a different hypervisor with live migration) ?\n> > > >\n> > > > Tim\n> > > Tim,\n> > >\n> > > No it sure can\'t.\n> > \n> > But a 10-20 line shell script could, calling nova CLI commands.\n> > \n> > I think the point here is that we see pushes like this to treat VMs as pets and we\'ve so far been able to successfully push back on\n> > these (anti)feature requests, pointing out that this kind of thing generally is antithetical to a utility cloud model and antithetical to\n> > the horizontal scale-out architecture that cloud espouses (i.e. don\'t have a single point of failure that requires this kind of setup).\n> > \n> > /me waits for someone to use the word \"enterprise\".\n> > \n> \n> And it is a difficult balance to strike... providing the full v* feature set would have a massive cost. My user community is looking for an on-ramp to cloud. They agree it is the right way to go in the longer term but it has to be a journey, not a \'leap from the lion\'s head\' moment. This has a set of steps from their current service consolidation environment towards a full cloud model. I would find this discussion with my users much easier if we can offer basic VM restart/live migration along the way.\n\nUnderstood.\n\nFor the record, we should improve the (live) migration story in Nova\nregardless of any DRS-type feature requests. The migration story right\nnow is overly complicated for what it needs to be, IMO, and there\'s lots\nof room for simplification and improvement, both on the API and the\nimplementation level.\n\nBest,\n-jay\n\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E5D9B26C1D@CERNXCHG41.cern.ch>',NULL),('<1397520572.2932.4.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 10:09:32',36000,'2014-04-15 00:09:32',NULL,'[openstack-dev] [infra]Requesting consideration of httmock\n package for test-requirements in Juno','On Fri, 2014-04-11 at 13:29 +0000, Paul Michali (pcm) wrote:\n> See inline @PCM? \n> \n> \n> On Apr 9, 2014, at 5:56 PM, Jamie Lennox <jamielennox at redhat.com>\n> wrote:\n> \n> \n> > \n> > \n> > ----- Original Message -----\n> > > From: \"Paul Michali (pcm)\" <pcm at cisco.com>\n> > > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > > <openstack-dev at lists.openstack.org>\n> > > Sent: Wednesday, April 9, 2014 6:31:09 AM\n> > > Subject: Re: [openstack-dev] [infra]Requesting consideration of\n> > > httmock package for test-requirements in Juno\n> > > \n> > > On Apr 8, 2014, at 3:04 PM, Jamie Lennox < jamielennox at redhat.com\n> > > > wrote:\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > ----- Original Message -----\n> > > \n> > > \n> > > From: \"Paul Michali (pcm)\" < pcm at cisco.com >\n> > > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > > <\n> > > openstack-dev at lists.openstack.org >\n> > > Cc: jamielennox at gmail.com\n> > > Sent: Wednesday, April 9, 2014 12:09:58 AM\n> > > Subject: [openstack-dev] [infra]Requesting consideration of\n> > > httmock package\n> > > for test-requirements in Juno\n> > > \n> > > Reposting this, after discussing with Sean Dague?\n> > > \n> > > For background, I have developed a REST client lib to talk to a\n> > > H/W device\n> > > with REST server for VPNaaS in Neutron. To support unit testing of\n> > > this, I\n> > > created a UT module and a mock REST server module and used the\n> > > httmock\n> > > package. I found it easy to use, and was able to easily create a\n> > > sub-class\n> > > of my UT to run the same test cases with real H/W, instead of the\n> > > mock REST\n> > > server. See the original email below, for links of the UT and REST\n> > > mock to\n> > > see how I used it.\n> > > \n> > > \n> > > I created a bug under requirements, to propose adding httmock to\n> > > the\n> > > test-requirements. Sean mentioned that there is an existing mock\n> > > package,\n> > > called httpretty , which I found is used in keystone client UTs),\n> > > and should\n> > > petition to see if httmock should replace httpretty, since the two\n> > > appear to\n> > > overlap in functionality.\n> > > \n> > > I found this link, with a brief comparison of the two:\n> > > http://marekbrzoska.wordpress.com/2013/08/28/mocking-http-requests-in-python/\n> > > \n> > > So? I?m wondering if the community is interested in adopting this\n> > > package\n> > > (with the goal of deprecating the httpretty package). Otherwise, I\n> > > will work\n> > > on reworking the UT code I have to try to use httpretty.\n> > > \n> > > Would be interested in peoples? thoughts, especially those who\n> > > have worked\n> > > with httpretty.\n> > > \n> > > Thanks in advance!\n> > > \n> > > So I introduced HTTPretty into the requirements and did the work\n> > > around\n> > > keystoneclient and am well aware that it has a few warts.\n> > > \n> > > PCM: Great, I grabbed your name from keystone client logs and was\n> > > hoping you\n> > > had some knowledge of httpretty.\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > At the time we were going through the changeover from httplib to\n> > > requests and\n> > > httpretty gave a good way to change over the library and ensure\n> > > that we\n> > > hadn\'t actually changed the issued requests at all. If we had\n> > > already been\n> > > on requests i don\'t know if i\'d have made the same choice.\n> > > \n> > > In general I am in favour of mocking the response layer rather\n> > > than the\n> > > client layer - whether we do this with httpretty or httmock\n> > > doesn\'t bother\n> > > me that much. Honestly I don\'t think a global patch of the\n> > > requests Session\n> > > object is that much safer that a global patch of the socket\n> > > interface, if\n> > > anything requests is under development and so this interface is\n> > > less\n> > > defined.\n> > > \n> > > PCM: Not sure that httmock can be considered a global patch. It is\n> > > a context\n> > > lib that intercepts the call through various decorators where the\n> > > request\n> > > can be filtered/processed and if not, will fall through and call\n> > > the actual\n> > > library.\n> > > \n> > > So, with the context lib, you can define several handlers for the\n> > > request(s).\n> > > When the call is made, it will try each handler and if they all\n> > > return None,\n> > > will call the original function, otherwise they return the value\n> > > of the mock\n> > > routine. Here?s an example front he test cases I cerated:\n> > > \n> > > with httmock.HTTMock(csr_request.token, csr_request.put,\n> > > csr_request.normal_get):\n> > > keepalive_info = {\'interval\': 60, \'retry\': 4}\n> > > self.csr.configure_ike_keepalive (keepalive_info)\n> > > self.assertEqual(requests.codes.NO_CONTENT, self.csr.status)\n> > > content = self.csr.get_request (\'vpn-svc/ike/keepalive\')\n> > > self.assertEqual(requests.codes.OK, self.csr.status)\n> > > expected = {\'periodic\': False}\n> > > expected.update(keepalive_info)\n> > > self.assertDictContainsSubset(expected, content)\n> > > \n> > > The client code (red) does a POST with authentication info to get\n> > > token, does\n> > > a PUT with the setting, and then a GET to verify the value. The\n> > > mock module\n> > > has these methods created:\n> > > \n> > > @httmock.urlmatch ( netloc =r\'localhost\')\n> > > def token( url , request):\n> > > if \' auth /token-services\' in url.path:\n> > > return {\'status_code\': requests.codes.OK,\n> > > \'content\': {\'token-id\': \'dummy-token\'}}\n> > > \n> > > \n> > > @httmock.urlmatch ( netloc =r\'localhost\')\n> > > def normal_get( url , request):\n> > > if request.method != \'GET\':\n> > > return\n> > > if not request.headers.get(\'X- auth -token\', None):\n> > > return {\'status_code\': requests.codes.UNAUTHORIZED}\n> > > ?\n> > > if \'vpn-svc/ike/keepalive\' in url.path:\n> > > content = {u\'interval\': 60,\n> > > u\'retry\': 4,\n> > > u\'periodic\': True}\n> > > return httmock.response(requests.codes.OK, content=content)\n> > > \n> > > @httmock.urlmatch(netloc=r\'localhost\')\n> > > def put(url, request):\n> > > if request.method != \'PUT\':\n> > > return\n> > > if not request.headers.get(\'X-auth-token\', None):\n> > > return {\'status_code\': requests.codes.UNAUTHORIZED}\n> > > return {\'status_code\': requests.codes.NO_CONTENT}\n> > > \n> > > \n> > > Just a few notes?.\n> > > A) Could have created separate context lib for put vs get.\n> > > B) Could have a method for specific URI request matches (I do that\n> > > in some\n> > > places, in others I catch all requests).\n> > > C) Can filter the requests based on request type or URI.\n> > > D) Can catch all URLs or filter.\n> > > E) Additional decorators can be created for these handlers.\n> > > F) There is lots of flexibility with manipulating the response\n> > > data.\n> > > \n> > > For (C) I?ve done things like this:\n> > > \n> > > @filter_request([\'post\'], \'vpn-svc/site-to-site\')\n> > > @httmock.urlmatch(netloc=r\'localhost\')\n> > > def post_missing_ipsec_policy(url, request):\n> > > if not request.headers.get(\'X-auth-token\', None):\n> > > return {\'status_code\': requests.codes.UNAUTHORIZED}\n> > > return {\'status_code\': requests.codes.BAD_REQUEST}\n> > > \n> > > For (D), I have all my handlers set for localhost, and then I have\n> > > another\n> > > test module that creates a subclass of the test class, sets the\n> > > host to an\n> > > IP of a live system, and runs the same tests, only this time\n> > > against a live\n> > > router, instead the mock module. This saves a lot of coding and\n> > > allows me to\n> > > reuse the test code (and make sure it REALLY works with real\n> > > hardware, in my\n> > > case).\n> > > \n> > > For (E), I did this to simulate a timeout in a request and then\n> > > latter\n> > > success on retry:\n> > > \n> > > @filter_request ([\'get\'], \'global/host-name\')\n> > > @repeat(1)\n> > > @httmock.urlmatch ( netloc =r\'localhost\')\n> > > def expired_request( url , request):\n> > > \"\"\"Simulate access denied failure on first request for this\n> > > resource.\n> > > \n> > > Intent here is to simulate that the token has expired, by failing\n> > > the first request to the resource. Because of the repeat=1, this\n> > > will only be called once, and subsequent calls will not be handled\n> > > by this function, but instead will access the normal handler and\n> > > will pass. Currently configured for a GET request, but will work\n> > > with POST and PUT as well. For DELETE, would need to\n> > > filter_request on a\n> > > different resource (e.g. \'global/local-users\')\n> > > \"\"\"\n> > > \n> > > return {\'status_code\': requests.codes.UNAUTHORIZED}\n> > > \n> > > Ref:\n> > > https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/notest_cisco_csr_rest.py\n> > > Ref:\n> > > https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/cisco_csr_mock.py\n> > > \n> > \n> > The reason that i call this a global mock is that behind the context\n> > manager it is still patching the class method not an individual\n> > instance of a requests.Session object. see:\n> > https://github.com/patrys/httmock/blob/master/httmock.py#L142 \n> \n> \n> @PCM Good point. I forgot that it did that.\n> \n> \n> \n> > \n> > Everything you have specified is doable with httpretty.\n> > \n> > @httpretty.activate does the mocking of the library (socket rather\n> > than requests.Session) then you use \n> > \n> >    httpretty.register_uri(httpretty.GET, \n> >                           \'http://testurl/testpath\', \n> >                           body=json.dumps({\'hello\': \'world\'},\n> >                           status=200)\n> > \n> > You can do the same multiple queued responses, responses via callbck\n> > and everything else. Also the thing i find a use a lot that i don\'t\n> > see provided by httmock is things like: \n> > \n> >    self.assertEqual(httpretty.last_request().headers[\'X-Auth-Token\'],\n> >                     expected_token)\n> > \n> > In which you test that the request that you send is actually what\n> > you expect as well. \n> \n> \n> @PCM So this is testing that what was sent to the code under test is\n> what it sends out in the HTTP request? I?m not sure I see the\n> advantage in testing that. I usually just test that the response is\n> correct, given the request data I send to the code under test.\n> \n> \n>  \n> > \n> > Anyway there is a pretty long readme on the github page:\n> > https://github.com/gabrielfalcao/HTTPretty that explains these sort\n> > of features.\n> \n> \n> @PCM Thanks. I?ll take a look at this.\n> \n> \n> \n> > \n> > \n> > > What i would like to see though is this mocking transferred into\n> > > fixtures\n> > > like in https://review.openstack.org/#/c/77961/ and have the\n> > > actual choice\n> > > in mock library hidden behind those fixtures. Is this a pattern\n> > > that httmock\n> > > can handle? or something else again?\n> > > \n> > > PCM I see your point - it would be nice to be able to have the\n> > > flexibility to\n> > > swap the underlying mock libraries. Would have to think about it\n> > > more, to\n> > > see if a common fixture can be used for httpretty and httmock. I?m\n> > > not sure\n> > > if they are different enough (one monkey patching, one using\n> > > context lib)\n> > > that it would be possible (and I don?t have a strong understanding\n> > > of\n> > > httpretty yet).\n> > > \n> > > Would love to hear peoples? thoughts no this.\n> > \n> > Again, i\'m not that strongly in favour of HTTPretty over httmock\n> > (though missing last_request will be a problem).\n> \n> \n> @PCM I?ll take a look and see if I can change all my UTs to use\n> HTTPretty. I?ll be curious to see if it can handle all the cases I\n> use. In particular, I have two test modules, one which has test cases\n> that, by using a URL directed to the localhost, makes use of a mock\n> REST server, to exercise my client REST module.\n> \n> \n> I have a second test module, which has subclasses for the test classes\n> in the first module, only in setup, it specifies the URL of a ?real?\n> REST server. When I run this module, which is very small, it leverages\n> off all the test cases, but verifies with a real device, which is the\n> true proof that the REST client under test actually works.  Granted,\n> it wouldn?t be used during a UT TOX run, but it could be used with a\n> Tempest run.\n> \n> \n> From an httmock standpoint there is no change, as the handler methods\n> have filters to only catch requests to a URL directed to localhost.\n>  The ?live? test will end up falling through and making a REST request\n> to a real server.\n\nThis is the same as HTTPretty, if you don\'t catch the URL then it will\npass through as normal (IMO this is the wrong default for unit testing)\nso you should be able to do the same thing. \n\n> \n> Likewise, I have tests for checking timeouts, where I have the desired\n> call map to the mock, so the request fails, but other requests flow\n> through to the live server.\n> \n> \n> Any thoughts on how I would be able to do these things with HTTPretty?\n> \n\nI am not sure about timeout exceptions, as a last resort you can specify\na callback for a response and if you raised the appropriate exception\nthere it should filter up.\n\n> \n> \n> \n> > My point is just that the two libraries can both do the same job and\n> > i\'m wondering what the advantage of the new one is.\n> \n> \n> @PCM One thing is that I think the context manager technique of\n> handling the mocking is (subjectively) a really clean way to do\n> things. The other is this duality of calls passing through to a real\n> (non-mock) server without altering the test cases.\n> \n> \n> \n> \n> \n> > \n> > As mentioned i would really like to see this moved into fixtures -\n> > httpretty will allow that somewhat, i don\'t see that httmock will,\n> \n> \n> @PCM My guess is that probably either method could be wrapped by a\n> fixture, but I?m also guessing that they are different enough such\n> that it may be very hard to come up with a fixture to accommodate\n> both.\n> \n> \n> \n> > and if i had the time i think i would just rewrite a library like\n> > this making use of the tools we already have like mock, fixtures,\n> > and testresources. (My other thought is to just subclass a\n> > requests.Session object with an overridden request method -rather\n> > than a global patch- and allow that to be passed into clients but i\n> > don\'t think they all support that).\n> \n> \n> @PCM I?ll try to see if I can adapt my UTs to use HTTPretty and think\n> a little bit on how a test fixture could be used.\n\nI actually had a play the other day to see just how hard it would be to\ndo my own requests mocking library that provided the kind of interfaces\ni was looking for. Answer is quite easy:\nhttps://github.com/jamielennox/requests-mock\n\nI\'m not sure i want to get into maintaining a library like that but\nmaybe we could get the httmock to expand there scope a little and\nprovide some hooks that would adapt to the fixture pattern more easily. \n\n\nJamie \n\n\n\n> Regards,\n> \n> \n> PCM (Paul Michali)\n> \n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pcm_ (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> \n> \n> > \n> > \n> > Jamie \n> > \n> > \n> > \n> > > \n> > > PCM (Paul Michali)\n> > > \n> > > MAIL ?..?. pcm at cisco.com\n> > > IRC ??..? pcm_ ( irc.freenode.com )\n> > > TW ???... @pmichali\n> > > GPG Key ? 4525ECC253E31A83\n> > > Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > Jamie\n> > > \n> > > \n> > > \n> > > \n> > > PCM (Paul Michali)\n> > > \n> > > MAIL ?..?. pcm at cisco.com\n> > > IRC ??..? pcm_ ( irc.freenode.com )\n> > > TW ???... @pmichali\n> > > GPG Key ? 4525ECC253E31A83\n> > > Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> > > \n> > > \n> > > \n> > > On Apr 4, 2014, at 10:44 AM, Paul Michali (pcm) < pcm at cisco.com >\n> > > wrote:\n> > > \n> > > \n> > > \n> > > \n> > > I?d like to get this added to the test-requirements for Neutron.\n> > > It is a very\n> > > flexible HTTP mock module that works with the Requests package. It\n> > > is a\n> > > decorator that wraps the Request?s send() method and allows easy\n> > > mocking of\n> > > responses, etc (w/o using a web server).\n> > > \n> > > The bug is: https://bugs.launchpad.net/neutron/+bug/1282855\n> > > \n> > > Initially I had requested both httmock and newer requests, but was\n> > > requested\n> > > to separate them, so this is to target httmock as it is more\n> > > important (to\n> > > me :) to get approval,\n> > > \n> > > \n> > > The review request is: https://review.openstack.org/#/c/75296/\n> > > \n> > > An example of code that would use this:\n> > > \n> > > https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/notest_cisco_csr_rest.py\n> > > https://github.com/openstack/neutron/blob/master/neutron/tests/unit/services/vpn/device_drivers/cisco_csr_mock.py\n> > > \n> > > Looking forward to hearing whether or not we can include this\n> > > package into\n> > > Juno.\n> > > \n> > > Thanks in advance!\n> > > \n> > > \n> > > PCM (Paul Michali)\n> > > \n> > > MAIL ?..?. pcm at cisco.com\n> > > IRC ??..? pcm_ ( irc.freenode.com )\n> > > TW ???... @pmichali\n> > > GPG Key ? 4525ECC253E31A83\n> > > Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<93CB986A-A643-48AC-BDDD-295221F5CB5E@cisco.com>',NULL),('<1397525091-sup-1157@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 18:30:59',-25200,'2014-04-15 01:30:59',NULL,'[openstack-dev] [tripleo] Default paths in os-*-config projects','Excerpts from Ben Nemec\'s message of 2014-04-14 15:41:23 -0700:\n> Right now the os-*-config projects default to looking for their files in \n> /opt/stack, with an override env var provided for other locations.  For \n> packaging purposes it would be nice if they defaulted to a more \n> FHS-compliant location like /var/lib.  For devtest we could either \n> override the env var or simply install the appropriate files to /var/lib.\n> \n> This was discussed briefly in IRC and everyone seemed to be onboard with \n> the change, but Robert wanted to run it by the list before we make any \n> changes.  If anyone objects to changing the default, please reply here. \n>   I\'ll take silence as agreement with the move. :-)\n> \n\n+1 from me for doing FHS compliance. :)\n\n/var/lib is not actually FHS compliant as it is for \"Variable state\ninformation\". os-collect-config does have such things, and does use\n/var/lib. But os-refresh-config reads executables and os-apply-config\nreads templates, neither of which will ever be \"variable state\ninformation\".\n\n/usr/share would be the right place, as it is \"Architecture independent\ndata\". I suppose if somebody wants to compile a C program as an o-r-c\nscript we could rethink that, but I\'d just suggest they drop it in a bin\ndir and exec it from a one line shell script in the /usr/share.\n\nSo anyway, I suggest:\n\n/usr/share/os-apply-config/templates\n/usr/share/os-refresh-config/scripts\n\nWith the usual hierarchy underneath.\n\nWe\'ll need to continue to support the non-FHS paths for at least a few\nreleases as well.\n\n\n','<534C6413.2030105@nemebean.com>',NULL),('<1397564289.3233.38.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 08:18:09',-14400,'2014-04-15 12:18:09',NULL,'[openstack-dev] TC Candidacy','Hi Stackers,\n\nI\'ve known OpenStack since it was a baby, and I\'ve watched it grow to\nthe teenager it is today -- pimples and all. I hope to help guide it\nalong its way to adulthood by serving on the Technical Committee.\n\nBesides developing on a number of core and ecosystem OpenStack projects,\nI\'ve also spent a couple years on the deployment and operator side of\nthe coin, which I think gives me a well-balanced perspective on some of\nthe hardships that go hand in hand with configuring, upgrading and\nscaling a highly distributed piece of software.\n\nI think it\'s pretty well-known that I live and breathe a utility cloud\nworld-view (all hail Cow29118281!). But hopefully it\'s also known that\nI\'m open to other viewpoints, welcome discussion on ideological\nincongruence, and try to treat all folks with respect and dignity.\n\nOn the TC, I would be a strong voice for:\n\n * Newcomers to the developer and operator community -- I\'d like to help\nfoster mentoring opportunities in the community and spread knowledge in\na viral way\n\n * Simplicity and consistency in our public REST APIs -- The APIs are\nour public face, and when they are overly complex, inconsistent, or just\ndon\'t make sense, we turn possible newcomers away from OpenStack. We\nshould do everything we can to break down any barriers to entry to our\nwonderful community and fantastic set of projects\n\nThanks for reading!\n\n-jay\n\n\n\n',NULL,NULL),('<1397569380.3233.55.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 09:43:00',-14400,'2014-04-15 13:43:00',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','Hi again, Divakar, sorry for the delayed response!\n\nOn Wed, 2014-04-09 at 14:52 +0000, Nandavar, Divakar Padiyar wrote:\n> Hi Jay, Managing multiple clusters using the \"Compute Proxy\" is not new\n> right? Prior to this \"nova baremetal\" driver has used this model\n> already.\n\nYes, unfortunately. However, nova-baremetal has moved to the Ironic\nproject, which has its own scheduler that is built to deal with the\nproblem of having a single compute manager responsible for >1 set of\ncompute resources.\n\n> Also this \"Proxy Compute\" model gives flexibility to deploy as many\n> computes required based on the requirement. For example, one can\n> setup one proxy compute node to manage a set of clusters and another\n> proxy compute to manage a separate set of clusters or launch compute\n> node for each of the clusters.\n\nIt actually reduces the flexibility of Nova in two main ways:\n\n1) It breaks the horizontal scale-out model that exists when a single\nnova-compute is responsible for a wholly-separate group of compute\nresources. Under the proxy compute model, if the proxy compute goes\ndown, the whole cluster goes down.\n\n2) It surrenders control of the VMs to an external system and in doing\nso, must constantly poll this external system in order to know the state\nof the externally-controlled resources. We do this already at the\nhypervisor driver level. The source of truth for VM state is the\nhypervisor, and nova-compute must periodically query the hypervisor for\nlive data about the VMs running on the hypervisor. The Nova scheduler\nqueries nova-compute workers for information about the VMs running on\nthe host it controls. For the proxy-compute model, the Nova scheduler\nqueries proxy-computes, which then must query some externally-controlled\nmanagement platform, and then aggregate this data back up to the Nova\nscheduler (a job that the Nova scheduler is designed to do, not the\nnova-compute worker). This additional layer of complexity does not allow\ngreater flexibility -- it instead limits the flexibility of Nova, since\nit changes the definition and responsibility of two of its major\ncomponents: nova-compute and nova-scheduler.\n\nBest,\n-jay\n\n\n\n\n','<D61466214F4BD04A899971B7EAF40FF5299C2DC1@G9W0750.americas.hpqcorp.net>',NULL),('<1397571967.2373.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 07:26:07',-25200,'2014-04-15 14:26:07',NULL,'[openstack-dev] [oslo] starting regular meetings','On Mon, 2014-04-14 at 14:53 -0400, Doug Hellmann wrote:\n> Balancing Europe and Pacific TZs is going to be a challenge. I can\'t\n> go at 1800 or 1900, myself, and those are pushing a little late in\n> Europe anyway.\n> \n> How about 1600?\n> http://www.timeanddate.com/worldclock/converted.html?iso=20140414T16&p1=0&p2=2133&p3=195&p4=224\n> \n> We would need to move to another room, but that\'s not a big deal.\n\nWorks for me.\n\nThanks,\nMark.\n\n\n\n\n','<CADb+p3Ss_6NrPvJGL3n5pq8aMpp1S9bUtQLn7gcbUGe24FqrAg@mail.gmail.com>',NULL),('<1397588808-sup-2468@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 12:44:48',-25200,'2014-04-15 19:44:48',NULL,'[openstack-dev] [tripleo] /bin/bash vs. /bin/sh','Excerpts from Ben Nemec\'s message of 2014-04-14 09:26:17 -0700:\n> tldr: I propose we use bash explicitly for all diskimage-builder scripts \n> (at least for the short-term - see details below).\n> \n> This is something that was raised on my linting changes to enable set -o \n> pipefail.  That is a bash-ism, so it could break in the \n> diskimage-builder scripts that are run using /bin/sh.  Two possible \n> fixes for that: switch to /bin/bash, or don\'t use -o pipefail\n>\n\nWhat about this:\n\nif ! [ \"$SHEBANG\" = \"#!/bin/bash\" ] ; then\n  report_warning Non bash shebang, skipping script lint\nfi\n\n> But I think this raises a bigger question - does diskimage-builder \n> require bash?  If so, I think we should just add a rule to enforce that \n> /bin/bash is the shell used for everything.  I know we have a bunch of \n> bash-isms in the code already, so at least in the short-term I think \n> this is probably the way to go, so we can get the benefits of things \n> like -o pipefail and lose the ambiguity we have right now.  For \n> reference, a quick grep of the diskimage-builder source shows we have \n> 150 scripts using bash explicitly and only 24 that are plain sh, so \n> making the code truly shell-agnostic is likely to be a significant \n> amount of work.\n\nYes, diskimage-builder is bash, not posix shell. We\'re not masochists.\n;)\n\n> \n> In the long run it might be nice to have cross-shell compatibility, but \n> if we\'re going to do that I think we need a couple of things: 1) Someone \n> to do the work (I don\'t have a particular need to run dib in not-bash, \n> so I\'m not signing up for that :-) 2) Testing in other shells - \n> obviously just changing /bin/bash to /bin/sh doesn\'t mean we actually \n> support anything but bash.  We really need to be gating on other shells \n> if we\'re going to make a significant effort to support them.  It\'s not \n> good to ask reviewers to try to catch every bash-ism proposed in a \n> change.  This also relates to some of the unit testing work that is \n> going on right now too - if we had better unit test coverage of the \n> scripts we would be able to do this more easily.\n>\n\nI suggest that diskimage-builder\'s included elements should be /bin/bash\nonly. When we have an element linting tool, non bash shebangs should be\nwarnings we should enforce \"no warnings\". For t-i-e, we can strive for\nno warnings, but that would be a stretch goal and may involve refining\nthe warnings.\n\n\n','<534C0C29.8010005@nemebean.com>',NULL),('<1397591147-sup-3369@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 12:46:12',-25200,'2014-04-15 19:46:12',NULL,'[openstack-dev] [tripleo] /bin/bash vs. /bin/sh','Excerpts from Ghe Rivero\'s message of 2014-04-15 04:31:19 -0700:\n> +1 to use bash as the default shell. So far, all major distros use bash\n> as the default one (except Debian which uses dash).\n> An about rewriting the code in Python, I agree that shell is complicated\n> for large programs, but writing anything command oriented in other than\n> shell is a nightmare. But there are some parts that can benefit from that.\n> \n\nSide note, Ubuntu uses dash as /bin/sh.\n\n\n','<534D1887.1070700@gmail.com>',NULL),('<1397595941-sup-4677@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 14:17:21',-25200,'2014-04-15 21:17:21',NULL,'[openstack-dev] [heat] computed package names?','Excerpts from Zane Bitter\'s message of 2014-04-15 13:32:30 -0700:\n> On 15/04/14 15:57, Mike Spreitzer wrote:\n> > Zane Bitter <zbitter at redhat.com> wrote on 04/15/2014 03:29:03 PM:\n> >\n> >  > On 15/04/14 14:31, Mike Spreitzer wrote:\n> >  > > It appears that in Fedora 19 and 20 the Wordpress examples need to\n> >  > > install different packages than in every other release (see my\n> > debugging\n> >  > > in https://review.openstack.org/#/c/87065/).  I just got a complaint\n> >  > > from Heat validation that I can\'t do this:\n> >  > >\n> >  > >          \"AWS::CloudFormation::Init\" : {\n> >  > >            \"config\" : {\n> >  > >              \"packages\" : {\n> >  > >                \"yum\" : {\n> >  > > { \"Fn::FindInMap\" : [ \"Pkgset2Pkgs\", { \"Fn::FindInMap\" : [\n> >  > > \"Distro2Pkgset\", { \"Ref\" : \"LinuxDistribution\" }, \"db\" ] },\n> > \"client\" ] }\n> >  > > : [],\n> >  > > { \"Fn::FindInMap\" : [ \"Pkgset2Pkgs\", { \"Fn::FindInMap\" : [\n> >  > > \"Distro2Pkgset\", { \"Ref\" : \"LinuxDistribution\" }, \"db\" ] },\n> > \"server\" ] }\n> >  > > : [],\n> >  > >\n> >  >\n> >  > .. in\n> >  > JSON a property name cannot be an object ...\n> >\n> > Ah, right.  So what would be the simplest way to enable this use case?\n> >   Perhaps a generalization of AWS::CloudFormation::Init that allows the\n> > package names to be objects (that evaluate to strings, of course)?\n> >   Maybe allow, e.g., \"yum\" to be associated with not a map but rather a\n> > list of pairs (2-element lists)?\n> \n> Yes, that _kind_ of thing. But I don\'t see much point in having an \n> AWS::CloudFormation::Init section that isn\'t compatible with \n> CloudFormation\'s definition of it. We already have some native \n> in-instance tools (e.g. os-apply-config) that can probably handle this \n> better.\n> \n\nos-apply-config wouldn\'t really be what you want. It is specifically\nonly intended for translating communication values into configuration.\nPackage installation is not handled.\n\nWe don\'t have a native declarative post-boot package installation\ntool that can be expressed this way. If you must do vanilla images +\ncustomization, I think cfn-init is generally fine. This particular case,\nhowever, shows a place where they abused the mapping json type pretty\nbadly. I think it would make sense to have a native OS::Heat::Init\nsection that takes the package name as a value or something.\n\n> FWIW, in the short term I\'m not aware of any issue with installing \n> mariadb in Fedora 17/18, provided that mysql is not installed first. And \n> in fact they\'re both EOL anyway, so we should probably migrate all the \n> templates to Fedora 20 and mariadb.\n\n+1 for that.\n\n\n','<534D975E.4000007@redhat.com>',NULL),('<1397600057-sup-4232@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 15:19:35',-25200,'2014-04-15 22:19:35',NULL,'[openstack-dev] [heat] computed package names?','Excerpts from Mike Spreitzer\'s message of 2014-04-15 14:59:50 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 04/15/2014 05:17:21 PM:\n> \n> > Excerpts from Zane Bitter\'s message of 2014-04-15 13:32:30 -0700:\n> \n> > > Yes, that _kind_ of thing. But I don\'t see much point in having an \n> > > AWS::CloudFormation::Init section that isn\'t compatible with \n> > > CloudFormation\'s definition of it. We already have some native \n> > > in-instance tools (e.g. os-apply-config) that can probably handle this \n> \n> > > better.\n> > > \n> > \n> > os-apply-config wouldn\'t really be what you want. It is specifically\n> > only intended for translating communication values into configuration.\n> > Package installation is not handled.\n> > \n> > We don\'t have a native declarative post-boot package installation\n> > tool that can be expressed this way. If you must do vanilla images +\n> > customization, I think cfn-init is generally fine. This particular case,\n> > however, shows a place where they abused the mapping json type pretty\n> > badly. I think it would make sense to have a native OS::Heat::Init\n> > section that takes the package name as a value or something.\n> > \n> > > FWIW, in the short term I\'m not aware of any issue with installing \n> > > mariadb in Fedora 17/18, provided that mysql is not installed first. \n> And \n> > > in fact they\'re both EOL anyway, so we should probably migrate all the \n> \n> > > templates to Fedora 20 and mariadb.\n> > \n> > +1 for that.\n> \n> I count 22 templates in heat-templates that are written to support Fedora, \n> Ubuntu, and RHEL; is MariaDB available in those?  I do not see it in \n> Ubuntu 12.10, for example.\n> \n\nNo, MariaDB might be in Ubuntu 14.04.. haven\'t checked, but mysql is\nstill the recommended one.\n\n> Those templates support ubuntu 10.  Just 10!  It will probably be easiest \n> to add Ubuntu 12 (as in 12.04 LTS) and 14 (as in 14.04 LTS).\n> \n\nUbuntu 10.04 has just 1 year of support left. Time to start migrating!\n:)\n\n> Yes, I can see how OS::Heat::Init makes sense.  But is this just the first \n> thing on a long list?  Would it be better to have a static intrinsic that \n> is like Python\'s dict(iterable of iterable)->dictionary function?\n> \n\nYes I don\'t know what the python thing you\'re referring to is.\n\nYes, it is the first in the list of things we\'d change while creating\na native format. Though another option is to just adopt external tools\nlike puppet/chef/salt to do this. We creates os-*-config in TripleO so\nwe didn\'t have to pick a religion and so that we could do \"the unix way\"\nand make tools that only do one thing. However, for template examples,\nit might be a little easier to accept one religion, er, tool, in one\ntemplate, and another tool in a different template.\n\n\n','<OF0C664210.F022386A-ON85257CBB.007845AD-85257CBB.0078D5E8@us.ibm.com>',NULL),('<1397615619.4935.3.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 22:33:39',-14400,'2014-04-16 02:33:39',NULL,'[openstack-dev] deliver the vm-level HA to improve the business\n continuity with openstack','On Tue, 2014-04-15 at 12:01 +0100, Duncan Thomas wrote:\n> On 14 April 2014 19:51, James Penick <penick at yahoo-inc.com> wrote:\n> > We drive the ?VM=Cattle? message pretty hard. Part of onboarding a\n> > property to our cloud, and allowing them to serve traffic from VMs is\n> > explaining the transient nature of VMs. I broadcast the message that all\n> > compute resources die, and if your day/week/month is ruined because of a\n> > single compute instance going away, then you?re doing something Very\n> > Wrong. :)\n> \n> While I agree with the message, if cloud provider A has VM restarts\n> every hour, and B has restarts every 6 months, all other things being\n> equal I\'m going to go with B.\n\nPretty sure James wasn\'t saying that he restarts VMs every hour. The\nidea is that applications that run on a utility cloud should be\nresilient and take into account failure as an expected part of\noperating.\n\n> Restarts are a pain point for most\n> systems, requiring data resynchronisation etc, so looking to minimise\n> them is a good aim as long as it doesn\'t conflict much with other\n> concerns...\n\nI\'m actually not entirely sure what restarts and data resync have to do\nwith vm-level HA? What am I missing here?\n\nBest,\njay\n\n\n\n','<CAOyZ2aGE6b20Min8bhTxPWm1bEgwBUh1kCi8vR-SEL1DWKJHPw@mail.gmail.com>',NULL),('<1397618519-sup-2694@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 20:32:57',-25200,'2014-04-16 03:32:57',NULL,'[openstack-dev] [tripleo] Default paths in os-*-config projects','Excerpts from Steve Baker\'s message of 2014-04-15 16:30:32 -0700:\n> On 15/04/14 13:30, Clint Byrum wrote:\n> > Excerpts from Ben Nemec\'s message of 2014-04-14 15:41:23 -0700:\n> >> Right now the os-*-config projects default to looking for their files in \n> >> /opt/stack, with an override env var provided for other locations.  For \n> >> packaging purposes it would be nice if they defaulted to a more \n> >> FHS-compliant location like /var/lib.  For devtest we could either \n> >> override the env var or simply install the appropriate files to /var/lib.\n> >>\n> >> This was discussed briefly in IRC and everyone seemed to be onboard with \n> >> the change, but Robert wanted to run it by the list before we make any \n> >> changes.  If anyone objects to changing the default, please reply here. \n> >>   I\'ll take silence as agreement with the move. :-)\n> >>\n> > +1 from me for doing FHS compliance. :)\n> >\n> > /var/lib is not actually FHS compliant as it is for \"Variable state\n> > information\". os-collect-config does have such things, and does use\n> > /var/lib. But os-refresh-config reads executables and os-apply-config\n> > reads templates, neither of which will ever be \"variable state\n> > information\".\n> >\n> > /usr/share would be the right place, as it is \"Architecture independent\n> > data\". I suppose if somebody wants to compile a C program as an o-r-c\n> > script we could rethink that, but I\'d just suggest they drop it in a bin\n> > dir and exec it from a one line shell script in the /usr/share.\n> >\n> > So anyway, I suggest:\n> >\n> > /usr/share/os-apply-config/templates\n> > /usr/share/os-refresh-config/scripts\n> >\n> > With the usual hierarchy underneath.\n> +1, but might I suggest the orc location be:\n> /usr/libexec/os-refresh-config/*.d\n> \n\nGood catch. I had not read the latest draft of FHS 3.0, and indeed\nlibexec is included. Seems daft to base on 2.3 if 3.0 is likely to be\nreleased this summer.\n\n> > We\'ll need to continue to support the non-FHS paths for at least a few\n> > releases as well.\n> >\n> Instead of supporting both paths, how about the orc and oac elements set\n> OS_REFRESH_CONFIG_BASE_DIR and OS_CONFIG_APPLIER_TEMPLATES to\n> /opt/stack/... until tripleo is ready to switch? With some prep changes\n> it should be possible to make the flag-day change to require only\n> changing the value of these env vars in tripleo-image-templates.\n> \n\nI\'m not worried about TripleO. I\'m worried about all the other users who\nmay be relying on the old defaults. I think the proper way to handle it\nis something like this:\n\nif os.path.exists(old_templates_dir):\n    logger.warn(\"%s is deprecated. Please use %s\" % (old_templates_dir, new_templates_dir))\n    templates_dir = merge_dirs(old_templates_dir, new_templates_dir)\n\nWe may be an 0.x release, but I think this is straight forward enough\nto support being gentle with any users we don\'t know about.\n\n\n','<534DC118.9070205@redhat.com>',NULL),('<1397653688.5518.YahooMailAndroidMobile@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-16 06:08:08',-25200,'2014-04-16 13:08:08',NULL,'[Openstack] Question about my company info in stackalytics','how do you update the json? using gerrit or there is some other process.\n\nSent from Yahoo Mail on Android\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140416/be73446f/attachment.html>\n\n','<380a3f54b0b047669ca827131af41b81@BN1PR07MB022.namprd07.prod.outlook.com>',NULL),('<1397653893.3039.2.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 09:11:33',-14400,'2014-04-16 13:11:33',NULL,'[openstack-dev] [nova] unit tests method','On Wed, 2014-04-16 at 14:55 +0800, Chen CH Ji wrote:\n> Hi \n>                 There are 3 types of unit test existing now (stub, mox\n> and mock)\n>                 Several code reviewers suggest to use mock instead of\n> using the other 2 and I am following it, but I want to know where can\n> I find the suggestion and guide line?\n\nHi Kevin!\n\nSo, there are only two unit testing methods -- mock and mox. stubs are\npart of the mox-style way of doing things.\n\nMy general rules of thumb when doing reviews in Nova are these:\n\n1) For new unit tests, use mock\n2) Don\'t mix mock and mox in a single test method\n3) When modifying existing unit tests, unless rewriting the test method\nalmost entirely, stick with whatever is used already (mock or mox)\n\nBest,\n-jay\n\n\n\n','<OFAFD92DE5.88D04505-ON48257CBC.0025DD19-48257CBC.0026616D@cn.ibm.com>',NULL),('<1397669914.7126.0.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 13:38:34',-14400,'2014-04-16 17:38:34',NULL,'[openstack-dev] [nova] unit tests method','On Wed, 2014-04-16 at 11:05 -0500, Ben Nemec wrote:\n> On 04/16/2014 08:11 AM, Jay Pipes wrote:\n> > On Wed, 2014-04-16 at 14:55 +0800, Chen CH Ji wrote:\n> >> Hi\n> >>                  There are 3 types of unit test existing now (stub, mox\n> >> and mock)\n> >>                  Several code reviewers suggest to use mock instead of\n> >> using the other 2 and I am following it, but I want to know where can\n> >> I find the suggestion and guide line?\n> >\n> > Hi Kevin!\n> >\n> > So, there are only two unit testing methods -- mock and mox. stubs are\n> > part of the mox-style way of doing things.\n> >\n> > My general rules of thumb when doing reviews in Nova are these:\n> >\n> > 1) For new unit tests, use mock\n> > 2) Don\'t mix mock and mox in a single test method\n> > 3) When modifying existing unit tests, unless rewriting the test method\n> > almost entirely, stick with whatever is used already (mock or mox)\n> >\n> > Best,\n> > -jay\n> \n> These points are also documented here: \n> https://wiki.openstack.org/wiki/ReviewChecklist (see point 4 under the \n> Common Review Checklist)\n\nOooh, thx Ben. I wasn\'t aware of that link. Some great information in\nthere.\n\nBest,\n-jay\n\n\n\n','<534EAA4E.2090507@nemebean.com>',NULL),('<1397682045.7898.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-16 21:00:47',0,'2014-04-16 21:00:47',NULL,'[Openstack-operators]  [Upgrades] Interoperability Matrix','Hi guys,\n\nI would like to open a discussion related to OpenStack upgrades ( I mean\nmoving from one version to another, for example Havana to Icehouse).\n\nAs you probably know, this is a big issue, since there is no silver\nbullet to do it. For that reason, I am thinking  in an option to provide\nmore input prior to do an upgrade.\n\nThe idea is to generate an interoperability matrix, where devops can see\nif an specific commit works with all the available OpenStack versions,\ndistinguishing among the different components. For example, you could\nsee if  the Nova X commit is or not backward compatible with the\nGrizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...\n\nDo you think this matrix would be useful in the upgrade tasks? \n\nThanks!\n\nBest Regards,\nPablo Andres Fuente\n\n',NULL,NULL),('<1397688316-sup-6035@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 15:51:40',-25200,'2014-04-16 22:51:40',NULL,'[openstack-dev] [heat] computed package names?','Excerpts from Zane Bitter\'s message of 2014-04-16 08:39:56 -0700:\n> On 16/04/14 05:53, Thomas Spatzier wrote:\n> > IMO, it would be desirable to not have things like yum or apt appear in the\n> > template explicitly. For many packages it seems like at least the top level\n> > package names (not including distro specific versioning strings) are equal\n> > across distros so when specified in a template it should be possible for a\n> > software deployment hook (which can be distro specific) to figure out how\n> > to install the package.\n> \n> I think this thread demonstrates the opposite: package names can be \n> different even among closely-related distributions (Fedora vs. RHEL) - \n> or even versions of the same distribution (Fedora 17 vs. 18). And while \n> Ubuntu is derived from Debian (and thus most apt packages are likely to \n> share package names), there\'s no reason whatsoever to expect e.g. \n> OpenSUSE to have the same package names as Fedora, despite both being \n> based on RPM.\n> \n> Brian Aker once suggested to me a scheme based on the path to the thing \n> you want installed: e.g. you request /usr/bin/httpd and the agent uses \n> \"yum provides\" or the apt equivalent to install the appropriate package. \n> That\'s an idea that might work better, although paths are by no means \n> standardised across distros either.\n\nUnfortunately that won\'t work for Ubuntu/Debian because they have\n/usr/bin/apache2. :-P\n\nWith diskimage-builder, we\'ve just been building a map of package names\nfor each distro and using a script called \'install-package\' to pull\nin packages using a single code base. We\'ve also considered using\nbindep:\n\nhttps://github.com/stackforge/bindep\n\nBut I\'m not sure it will be generally consumable enough for this\npurpose.\n\n> \n> In any event, though, my impression is that we are trying to get out of \n> the cfn-init business as much as possible and leave the task to some \n> combination of custom images, software config and configuration \n> management. Hopefully someone will correct me if that impression is \n> inaccurate...\n>\n\nRight, I think that is probably the way to go long term. One large hole\nthat leaves is post-boot updates, because OS::Heat::CloudConfig will\nonly be actioned on first boot. But perhaps the right answer there is to\nmove to a more powerful software management tool to support that case.\n\n\n','<534EA44C.7020404@redhat.com>',NULL),('<1397746133.11936.10.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-17 14:48:56',0,'2014-04-17 14:48:56',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Running this against a particular commit or a version tag\n(Grizzly/Havanna/Icehouse) will be the same, since a particular version\ntag it is also a commit. So, it could be good if the generated matrix\nfor a particular version tag is stored, for easy access and checking.\n\nRegarding the implementation, the idea is to use devstack to deploy all\nthe OpenStack projects in a specific version, except the project that\nyou want to check (e.g. all projects at Havanna, Nova at Icehouse).\nThen, over that deploy, to run a particular subset of Tempest tests, and\nuse the output to build the matrix.         \n\nPablo.\n\nOn Wed, 2014-04-16 at 23:16 -0300, gustavo panizzo wrote:\n> On 04/16/2014 06:00 PM, Fuente, Pablo A wrote:\n> > Hi guys,\n> > \n> > I would like to open a discussion related to OpenStack upgrades ( I mean\n> > moving from one version to another, for example Havana to Icehouse).\n> > \n> > As you probably know, this is a big issue, since there is no silver\n> > bullet to do it. For that reason, I am thinking  in an option to provide\n> > more input prior to do an upgrade.\n> > \n> > The idea is to generate an interoperability matrix, where devops can see\n> > if an specific commit works with all the available OpenStack versions,\n> > distinguishing among the different components. For example, you could\n> > see if  the Nova X commit is or not backward compatible with the\n> > Grizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...\n> > \n> > Do you think this matrix would be useful in the upgrade tasks? \n> \n> i think if you do it for each commit will be more useful for clouds that\n> follow trunk that ones that upgrade each release.\n> \n> if i\'m going to upgrade from havana to icehouse i won\'t look at each\n> commit, just the final result, like\n> \'i can/can\'t use Havana\'s nova with Icehouse\'s keystone\' that data could\n> be extracted from that big matrix (lot of commits btw each release for\n> each component)\n> \n> \n> it sounds extremely useful for people thinking on moving it\'s cloud to a\n> CD model :)\n> \n> \n> how will you generate that matrix? adding tags to commits or running\n> fine-grained tempest-like tests?\n> \n> \n\n\n','<534F3980.6080907@zumbi.com.ar>',NULL),('<1397753319.52222.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-18 00:48:39',28800,'2014-04-17 16:48:39',NULL,'[openstack-dev] [devstack] Error in running rabbit-mq server','Hi all,\n\nI am trying to setup OpenStack on Ubuntu 12.04 using devstack. Here is the error I am getting:\n\nSetting up rabbitmq-server (2.7.1-0ubuntu4) ...\nStarting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_{log, _err}\nrabbitmq-server.\ninvoke-rc.d: initscript rabbitmq-server, action \"start\" failed.\ndpkg: error processing rabbitmq-server (--configure):\n?subprocess installed post-installation script returned error exit status 1\nNo apport report written because MaxReports is reached already\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Errors were encountered while processing:\n?rabbitmq-server\nE: Sub-process /usr/bin/dpkg returned an error code (1)\n++ err_trap\n++ local r=100\n++ set +o xtrace\nstack.sh failed\n\nI checked the file /var/log/rabbitmq/startup_err and it just says the rabbitmq start failed, no other information. Can you please help me resolve the issue?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/7a6e4d29/attachment.html>\n\n',NULL,NULL),('<1397759085-sup-4372@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-17 11:27:28',-25200,'2014-04-17 18:27:28',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Excerpts from Fuente, Pablo A\'s message of 2014-04-16 14:00:47 -0700:\n> Hi guys,\n> \n> I would like to open a discussion related to OpenStack upgrades ( I mean\n> moving from one version to another, for example Havana to Icehouse).\n> \n> As you probably know, this is a big issue, since there is no silver\n> bullet to do it. For that reason, I am thinking  in an option to provide\n> more input prior to do an upgrade.\n> \n> The idea is to generate an interoperability matrix, where devops can see\n> if an specific commit works with all the available OpenStack versions,\n> distinguishing among the different components. For example, you could\n> see if  the Nova X commit is or not backward compatible with the\n> Grizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...\n> \n> Do you think this matrix would be useful in the upgrade tasks? \n> \n\nThe gate currently has \"grenade\", which attempts to upgrade a working\nstable release to the each commit. If this does not pass, it does not\nmerge.\n\nhttps://wiki.openstack.org/wiki/Grenade\n\nSo this interoperability matrix is actually already maintained, as _every_\ncommit should be able to upgrade from the previous stable release.\n\nFailures when attempting to do so are bugs in two things: the thing that\nbreaks on upgrade, and grenade.\n\n\n','<1397682045.7898.5.camel@localhost>',NULL),('<1397759671152-38542.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-17 11:34:31',-25200,'2014-04-17 18:34:31',NULL,'[openstack-dev] [Neutron][LBaas] \"Single call\" API discussion','hello Stephen,\n\n\nI am interested in LBaaS and want to know if we post the weekly meeting\'s\nchat transcripts online?\nor may be update an etherpad?\n\n\nCan you please share the links?\n\nthanks,\nSriD\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<CAAGw+Zqccw5--mOmymPm6XqO120PwOfyRPJrWtRORY0XnVmXqg@mail.gmail.com>',NULL),('<1397760085170-38543.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-17 11:41:25',-25200,'2014-04-17 18:41:25',NULL,'[openstack-dev] [Neutron][LBaas] \"Single call\" API discussion','hello Stephen,\n\n\nI am interested in LBaaS and want to know if we post the weekly meeting\'s\nchat transcripts online?\nor may be update an etherpad?\n\n\nCan you please share the links?\n\nthanks,\nSriD\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38543.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<CAAGw+Zqccw5--mOmymPm6XqO120PwOfyRPJrWtRORY0XnVmXqg@mail.gmail.com>',NULL),('<1397809210.37745.YahooMailNeo@web194604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-18 16:20:10',28800,'2014-04-18 08:20:10',NULL,'[Openstack] [devstack] Error in running rabbit-mq server','\n\nHi all,\n\n\n\nI am trying to setup OpenStack on Ubuntu 12.04 using devstack. Here is the error I am getting:\n\nSetting up rabbitmq-server (2.7.1-0ubuntu4) ...\nStarting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_{log, _err}\nrabbitmq-server.\ninvoke-rc.d: initscript rabbitmq-server, action \"start\" failed.\ndpkg: error processing rabbitmq-server (--configure):\n?subprocess installed post-installation script returned error exit status 1\nNo apport report written because MaxReports is reached already\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Errors were encountered while processing:\n?rabbitmq-server\nE: Sub-process /usr/bin/dpkg returned an error code (1)\n++ err_trap\n++ local r=100\n++ set +o xtrace\nstack.sh failed\n\nI am able to run raabit-mq explicitly, but it\'s not working with script. I checked the file /var/log/rabbitmq/startup_err and it just says the rabbitmq start failed, no other information. Can you please help me resolve the issue?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140418/aca55c4b/attachment.html>\n\n','<1397753319.52222.YahooMailNeo@web194602.mail.sg3.yahoo.com>',NULL),('<1397811238.50077.YahooMailNeo@web194603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-18 16:53:58',28800,'2014-04-18 08:53:58',NULL,'[Openstack] [devstack] Error in running rabbit-mq server','Hi,\n\nYes, I can run it manually. It\'s just not working with DevStack script!\n\n\nThanks,?\n~Peeyush Gupta\nOn Friday, 18 April 2014 2:22 PM, \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> wrote:\n \nHi-\n?\nCan you manually start/stop rabbitmq server. Check that once. \n?\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com| extn: 4048\n?\nFrom:Peeyush Gupta [mailto:gpeeyush at ymail.com] \nSent: Friday, April 18, 2014 1:50 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] [devstack] Error in running rabbit-mq server\n?\n?\nHi all,\n?\nI am trying to setup OpenStack on Ubuntu 12.04 using devstack. Here is the error I am getting:\n?\nSetting up rabbitmq-server (2.7.1-0ubuntu4) ...\nStarting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_{log, _err}\nrabbitmq-server.\ninvoke-rc.d: initscript rabbitmq-server, action \"start\" failed.\ndpkg: error processing rabbitmq-server (--configure):\n?subprocess installed post-installation script returned error exit status 1\nNo apport report written because MaxReports is reached already\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Errors were encountered while processing:\n?rabbitmq-server\nE: Sub-process /usr/bin/dpkg returned an error code (1)\n++ err_trap\n++ local r=100\n++ set +o xtrace\nstack.sh failed\n?\nI am able to run raabit-mq explicitly, but it\'s not working with script. I checked the file /var/log/rabbitmq/startup_err and it just says the rabbitmq start failed, no other information. Can you please help me resolve the issue?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140418/0bb0a535/attachment.html>\n\n','<f02c758deb844682ad6d36c79410c63a@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1397813618.72461.YahooMailNeo@web194606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-18 17:33:38',28800,'2014-04-18 09:33:38',NULL,'[Openstack] [devstack] Error in running rabbit-mq server','No, I actually tried unstack.sh only. I am gonna try with clean.sh and will get back to you.\n?\nThanks,\n~Peeyush Gupta\nOn Friday, 18 April 2014 2:54 PM, \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> wrote:\n \nHave you run clean.sh in devstack ?\n?\nIt cleans the complete devstack environment and makes it a fresh one. \n?\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com| extn: 4048\n?\nFrom:Peeyush Gupta [mailto:gpeeyush at ymail.com] \nSent: Friday, April 18, 2014 2:50 PM\nTo: Somanchi Trinath-B39208\nSubject: Re: [Openstack] [devstack] Error in running rabbit-mq server\n?\nTried it already! I even re-cloned the devstack repo. Looks like the only way now is to reinstall Ubuntu!?\n?\n~Peeyush Gupta\nOn Friday, 18 April 2014 2:35 PM, \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> wrote:\nCan u unstack.sh and clean.sh the devstack env and again run stack.sh. This can solve the issue\n?\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n?\nFrom:Peeyush Gupta [mailto:gpeeyush at ymail.com] \nSent: Friday, April 18, 2014 2:24 PM\nTo: Somanchi Trinath-B39208; openstack at lists.openstack.org\nSubject: Re: [Openstack] [devstack] Error in running rabbit-mq server\n?\nHi,\n?\nYes, I can run it manually. It\'s just not working with DevStack script!\n?\n?\nThanks,?\n~Peeyush Gupta\nOn Friday, 18 April 2014 2:22 PM, \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> wrote:\nHi-\n?\nCan you manually start/stop rabbitmq server. Check that once. \n?\n--\nTrinath Somanchi - B39208\ntrinath.somanchi at freescale.com | extn: 4048\n?\nFrom:Peeyush Gupta [mailto:gpeeyush at ymail.com] \nSent: Friday, April 18, 2014 1:50 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] [devstack] Error in running rabbit-mq server\n?\n?\nHi all,\n?\nI am trying to setup OpenStack on Ubuntu 12.04 using devstack. Here is the error I am getting:\n?\nSetting up rabbitmq-server (2.7.1-0ubuntu4) ...\nStarting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_{log, _err}\nrabbitmq-server.\ninvoke-rc.d: initscript rabbitmq-server, action \"start\" failed.\ndpkg: error processing rabbitmq-server (--configure):\n?subprocess installed post-installation script returned error exit status 1\nNo apport report written because MaxReports is reached already\n? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Errors were encountered while processing:\n?rabbitmq-server\nE: Sub-process /usr/bin/dpkg returned an error code (1)\n++ err_trap\n++ local r=100\n++ set +o xtrace\nstack.sh failed\n?\nI am able to run raabit-mq explicitly, but it\'s not working with script. I checked the file /var/log/rabbitmq/startup_err and it just says the rabbitmq start failed, no other information. Can you please help me resolve the issue?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140418/d1bc93ca/attachment.html>\n\n','<98d6a2ab6a2045e59321658a44d513a6@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1397845057-sup-6647@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-18 11:38:06',-25200,'2014-04-18 18:38:06',NULL,'[openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario\n	question','Excerpts from Stephen Balukoff\'s message of 2014-04-18 10:36:11 -0700:\n> Dang.  I was hoping this wasn\'t the case.  (I personally think it\'s a\n> little silly not to trust your service provider to secure a network when\n> they have root access to all the machines powering your cloud... but I\n> digress.)\n> \n\nNo one person or even group of people on the operator\'s network will have\nfull access to everything. Security is best when it comes in layers. Area\n51 doesn\'t just have a guard shack and then you drive right into the\nhangars with the UFO\'s and alien autopsies. There are sensors, mobile\nguards, secondary checkpoints, locks on the outer doors, and locks on\nthe inner doors. And perhaps most importantly, the MP who approves your\nentry into the first gate, does not even have access to the next one.\n\nYour SSL terminator is a gate. What happens once an attacker (whoever\nthat may be, your disgruntled sysadmin, or rogue hackers) is behind that\ngate _may_ be important.\n\n> Part of the reason I was hoping this wasn\'t the case, isn\'t just because it\n> consumes a lot more CPU on the load balancers, but because now we\n> potentially have to manage client certificates and CA certificates (for\n> authenticating from the proxy to back-end app servers). And we also have to\n> decide whether we allow the proxy to use a different client cert / CA per\n> pool, or per member.\n> \n> Yes, I realize one could potentially use no client cert or CA (ie.\n> encryption but no auth)...  but that actually provides almost no extra\n> security over the unencrypted case:  If you can sniff the traffic between\n> proxy and back-end server, it\'s not much more of a stretch to assume you\n> can figure out how to be a man-in-the-middle.\n>\n\nA passive attack where the MITM does not have to witness the initial\nhandshake or decrypt/reencrypt to sniff things is quite a bit easier to\npull off and would be harder to detect. So \"almost no extra security\"\nis not really accurate. But this is just one point of data for risk\nassessment.\n\n> Do any of you have a use case where some back-end members require SSL\n> authentication from the proxy and some don\'t? (Again, deciding whether\n> client cert / CA usage should attach to a \"pool\" or to a \"member.\")\n> \n> It\'s a bit of a rabbit hole, eh.\n>\n\nSecurity turns into an endless rat hole when you just look at it as a\nproduct, such as \"A secure load balancer.\"\n\nIf, however, you consider that it is really just a process of risk\nassessment and mitigation, then you can find a sweet spot that works\nin your business model. \"How much does it cost to mitigate the risk\nof unencrypted backend traffic from the load balancer?  What is the\npotential loss if the traffic is sniffed? How likely is it that it will\nbe sniffed?\" .. Those are ongoing questions that need to be asked and\nthen reevaluated, but they don\'t have a fruitless stream of what-if\'s\nthat have to be baked in like the product discussion. It\'s just part of\nyour process, and processes go on until they aren\'t needed anymore.\n\nIMO a large part of operating a cloud is decoupling the ability to setup\na system from the ability to enable your business with a system. So\nif you can communicate the risks of doing without backend encryption,\nand charge the users appropriately when they choose that the risk is\nworth the added cost, then I think it is worth it to automate the setup\nof CA\'s and client certs and put that behind an API. Luckily, you will\nlikely find many in the OpenStack community who can turn that into a\nbusiness opportunity and will help.\n\n\n','<CAAGw+ZoQmmjjCq2Wune6H-hUCC+4A=qC8r=Od6tx=fANBKgjJA@mail.gmail.com>',NULL),('<1397891980.59744.YahooMailNeo@web172402.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-19 08:19:40',3600,'2014-04-19 07:19:40',NULL,'[Openstack] Ask for suggestions','Hi Hao,\n\nI think you should start doing Neutron reviews [1]. With devstack, it is easy to download, run and try to break the patchsets. When doing reviews you will no doubt spot other bugs that you can take on to fix yourself. There are reviews for blueprints too [2]. \n\n\nRe, Darragh.\n\n\n[1] https://review.openstack.org/#/q/status:open+project:openstack/neutron,n,z\n[2] https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140419/0c236291/attachment.html>\n\n',NULL,NULL),('<1397999151.4303.18.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-20 09:05:51',-14400,'2014-04-20 13:05:51',NULL,'[openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support\n tags for os resources?','On Sun, 2014-04-20 at 08:35 +0000, Huangtianhua wrote:\n> Hi all: \n> \n> Currently, the EC2 API of OpenStack only has tags support (metadata)\n> for instances. And there has already a blueprint about to add support\n> for volumes and volume snapshots using ?metadata?. \n> \n> There are a lot of resources such as\n> image/subnet/securityGroup/networkInterface(port) are supported add\n> tags for AWS. \n> \n> I think we should support tags for these resources. There may be no\n> property ?metadata\" for these resources, so we should to add\n> ?metadata? to support the resource tags, the change related API.\n\nHi Tianhua,\n\nIn OpenStack, generally, the choice was made to use maps of key/value\npairs instead of lists of strings (tags) to annotate objects exposed in\nthe REST APIs. OpenStack REST APIs inconsistently call these maps of\nkey/value pairs:\n\n * \"properties\" (Glance, Cinder Image, Volume respectively)\n * \"extra_specs\" (Nova InstanceType)\n * \"metadata\" (Nova Instance, Aggregate and InstanceGroup, Neutron)\n * \"metadetails\" (Nova Aggregate and InstanceGroup)\n * \"system_metadata\" (Nova Instance -- differs from \"normal\" metadata in\nthat the key/value pairs are \'owned\' by Nova, not a user...) \n\nPersonally, I think tags are a cleaner way of annotating objects when\nthe annotation is coming from a normal user. Tags represent by far the\nmost common way for REST APIs to enable user-facing annotation of\nobjects in a way that is easy to search on. I\'d love to see support for\ntags added to any searchable/queryable object in all of the OpenStack\nAPIs.\n\nI\'d also like to see cleanup of the aforementioned inconsistencies in\nhow maps of key/value pairs are both implemented and named throughout\nthe OpenStack APIs. Specifically, I\'d like to see this implemented in\nthe next major version of the Compute API:\n\n * Removal of the \"metadetails\" term\n * All key/value pairs can only be changed by users with elevated\nprivileged system-controlled (normal users should use tags)\n * Call all these key/value pair combinations \"properties\" --\ntechnically, \"metadata\" is \"data about data\", like the size of an\ninteger. These key/value pairs are just data, not data about data.\n * Identify key/value pairs that are relied on by all of Nova to be a\nspecific key and value combination, and make these things actual real\nattributes on some object model -- since that is a much greater guard\nfor the schema of an object and enables greater performance by allowing\nboth type safety of the underlying data and removes the need to search\nby both a key and a value.\n\nBest,\n-jay\n\n\n\n\n','<E07566D89ECB9F43A509FE8A276ADDED3FFBDE39@SZXEMA510-MBX.china.huawei.com>',NULL),('<1398086735.13315.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-21 13:25:34',0,'2014-04-21 13:25:34',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Hi,\n\nYou are right regarding grenade, but there is a subtle difference with\nthe interoperability matrix.\nMeanwhile grenade does the upgrade and ensures it is working,  the\nmatrix checks that different components versions work well (or not)\ntogether, hoping that this information helps in the upgrade decisions\n(for example, upgrades orders). \nIn other words, Grenade moves the entire ?cloud? from one version to\nanother (all the components in the same version) and the matrix tests an\nspecific component version against the rest of the cloud in another\nversion.\nActually, I am considering to build this matrix without performing any\nupgrade.\n\nThen, do you think this matrix could be helpful?\n\nThank you very much for your answer!\nRegards,\nPablo\n \nOn Thu, 2014-04-17 at 11:27 -0700, Clint Byrum wrote:\n> Excerpts from Fuente, Pablo A\'s message of 2014-04-16 14:00:47 -0700:\n> > Hi guys,\n> > \n> > I would like to open a discussion related to OpenStack upgrades ( I mean\n> > moving from one version to another, for example Havana to Icehouse).\n> > \n> > As you probably know, this is a big issue, since there is no silver\n> > bullet to do it. For that reason, I am thinking  in an option to provide\n> > more input prior to do an upgrade.\n> > \n> > The idea is to generate an interoperability matrix, where devops can see\n> > if an specific commit works with all the available OpenStack versions,\n> > distinguishing among the different components. For example, you could\n> > see if  the Nova X commit is or not backward compatible with the\n> > Grizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...\n> > \n> > Do you think this matrix would be useful in the upgrade tasks? \n> > \n> \n> The gate currently has \"grenade\", which attempts to upgrade a working\n> stable release to the each commit. If this does not pass, it does not\n> merge.\n> \n> https://wiki.openstack.org/wiki/Grenade\n> \n> So this interoperability matrix is actually already maintained, as _every_\n> commit should be able to upgrade from the previous stable release.\n> \n> Failures when attempting to do so are bugs in two things: the thing that\n> breaks on upgrade, and grenade.\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<1397759085-sup-4372@fewbar.com>',NULL),('<1398111713.4303.34.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-21 16:21:53',-14400,'2014-04-21 20:21:53',NULL,'[openstack-dev] 答复:  [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?','On Mon, 2014-04-21 at 13:15 -0700, Vijay B wrote:\n> Hi Tianhua, Jay,\n> \n> \n> A blueprint has already been submitted in this regard:\n> \n> \n> https://docs.google.com/document/d/1ZqW7qeyHTm9AQt28GUdfv46ui9mz09UQNvjXiewOAys/edit#\n> \n> \n> \n> We\'ve been working to implement a generic tagging framework where tags\n> are a first class resource and other resources can be associated with\n> tags. Our first implementation focuses on neutron. For us at Ebay,\n> this forms an important foundational framework to support\n> flexible/customizable VPC architectures. A detailed design with\n> extension/db/other changes has been drawn up and will be submitted for\n> review to the group in the near future. Please do add your\n> thoughts/reviews to it.\n\nHi Vijay,\n\nPlease see my first comment on the above document. Tags are single\nstrings, not key/value pairs.\n\nIMO, tags are also a **user-controlled** annotation of an object. What\nyou are describing in that proposal seems more to be\n**system-controlled** annotation of objects using key/value\nproperties...\n\nBest,\n-jay\n\n> \n> On Mon, Apr 21, 2014 at 12:46 PM, Jay Pipes <jaypipes at gmail.com>\n> wrote:\n>         Absolutely. Feel free.\n>         \n>         \n>         On Mon, Apr 21, 2014 at 4:48 AM, Huangtianhua\n>         <huangtianhua at huawei.com> wrote:\n>                 I plan to register a blueprints in nova for record\n>                 this. Can I?\n>                 \n>                 \n>                 -----????-----\n>                 ???: Jay Pipes [mailto:jaypipes at gmail.com]\n>                 ????: 2014?4?20? 21:06\n>                 ???: openstack-dev at lists.openstack.org\n>                 ??: Re: [openstack-dev]\n>                 [Nova][Neutron][Cinder][Heat]Should we support tags\n>                 for os resources?\n>                 \n>                 On Sun, 2014-04-20 at 08:35 +0000, Huangtianhua wrote:\n>                 > Hi all:\n>                 >\n>                 > Currently, the EC2 API of OpenStack only has tags\n>                 support (metadata)\n>                 > for instances. And there has already a blueprint\n>                 about to add support\n>                 > for volumes and volume snapshots using ?metadata?.\n>                 >\n>                 > There are a lot of resources such as\n>                 > image/subnet/securityGroup/networkInterface(port)\n>                 are supported add\n>                 > tags for AWS.\n>                 >\n>                 > I think we should support tags for these resources.\n>                 There may be no\n>                 > property ?metadata\" for these resources, so we\n>                 should to add\n>                 > ?metadata? to support the resource tags, the change\n>                 related API.\n>                 \n>                 Hi Tianhua,\n>                 \n>                 In OpenStack, generally, the choice was made to use\n>                 maps of key/value pairs instead of lists of strings\n>                 (tags) to annotate objects exposed in the REST APIs.\n>                 OpenStack REST APIs inconsistently call these maps of\n>                 key/value pairs:\n>                 \n>                  * \"properties\" (Glance, Cinder Image, Volume\n>                 respectively)\n>                  * \"extra_specs\" (Nova InstanceType)\n>                  * \"metadata\" (Nova Instance, Aggregate and\n>                 InstanceGroup, Neutron)\n>                  * \"metadetails\" (Nova Aggregate and InstanceGroup)\n>                  * \"system_metadata\" (Nova Instance -- differs from\n>                 \"normal\" metadata in that the key/value pairs are\n>                 \'owned\' by Nova, not a user...)\n>                 \n>                 Personally, I think tags are a cleaner way of\n>                 annotating objects when the annotation is coming from\n>                 a normal user. Tags represent by far the most common\n>                 way for REST APIs to enable user-facing annotation of\n>                 objects in a way that is easy to search on. I\'d love\n>                 to see support for tags added to any\n>                 searchable/queryable object in all of the OpenStack\n>                 APIs.\n>                 \n>                 I\'d also like to see cleanup of the aforementioned\n>                 inconsistencies in how maps of key/value pairs are\n>                 both implemented and named throughout the OpenStack\n>                 APIs. Specifically, I\'d like to see this implemented\n>                 in the next major version of the Compute API:\n>                 \n>                  * Removal of the \"metadetails\" term\n>                  * All key/value pairs can only be changed by users\n>                 with elevated privileged system-controlled (normal\n>                 users should use tags)\n>                  * Call all these key/value pair combinations\n>                 \"properties\" -- technically, \"metadata\" is \"data about\n>                 data\", like the size of an integer. These key/value\n>                 pairs are just data, not data about data.\n>                  * Identify key/value pairs that are relied on by all\n>                 of Nova to be a specific key and value combination,\n>                 and make these things actual real attributes on some\n>                 object model -- since that is a much greater guard for\n>                 the schema of an object and enables greater\n>                 performance by allowing both type safety of the\n>                 underlying data and removes the need to search by both\n>                 a key and a value.\n>                 \n>                 Best,\n>                 -jay\n>                 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAOCo3T0Xn=dmLeOf5LMPN4D66da7THE9vNcj-j1cAETxf+eeww@mail.gmail.com>',NULL),('<1398113922.4303.36.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-21 16:58:42',-14400,'2014-04-21 20:58:42',NULL,'[openstack-dev] [Fuel] Migrate to Postrgresql 9','On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote:\n> We use postgresql 8 on master node right now. At some point we will\n> have to migrate to 9th version. And database migration can became\n> painful part of master node upgrade at that point.\n> \n> At the moment part of our developers use psql9 in their environments\n> and see no issues. Should we enforce upgrade before 5.0 release?\n\n++\n\n-jay\n\n\n\n\n','<CAEg2Y8MjM71aw28amCDdBRZ1vRMtSOOe05UzPyQs_dXnBDNTeQ@mail.gmail.com>',NULL),('<1398115328-sup-4405@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-21 14:25:06',-25200,'2014-04-21 21:25:06',NULL,'[openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario\n	question','Excerpts from Eichberger, German\'s message of 2014-04-21 11:51:05 -0700:\n> Hi,\n> \n> Despite there are some good use cases for the re-encryption I think it?s out of scope for a Load Balancer. We can defer that functionality to the VPN ? as long as we have a mechanism to insert a LoadBalancer as a VPN node we should get all kind of encryption infrastructure ?for free?.\n> \n> I like the Unix philosophy of little programs doing one task very well and can be chained. So in our case we might want to chain a firewall to a load balancer to a VPN to get the functionality we want.\n> \n\nI think that only makes things simpler in an IPv6+IPSec situation (which,\nbtw, would be fantastic and should be something we all drive OpenStack\ntoward). But if you have to add something like OpenVPN to the load\nbalancer service nodes, I\'m not sure you\'re saving any complexity by\nusing VPN vs. something like stunnel.\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C30B91E@G1W3651.americas.hpqcorp.net>',NULL),('<1398135527.3428.20.camel@MacbookPro>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 02:58:47',0,'2014-04-22 02:58:47',NULL,'[openstack-dev] [Neutron][LBaas] \"Single call\" API discussion','Hello Eugene!\n\nAre you talking about seeing the code in a simplified approach for a\nsingle create call using the current API objects, or one that uses\nobjects created based on the proposal?\n\nI was experimenting over the weekend on getting a single create call in\nthe current API model.  I was able to implement it pretty easy but did\nrun into some issues.  Now, since this was just a quick test, and to\nsave time I did not implement it the correct way, only a way in which it\naccepted a single create call and did everything else the usual way.  If\nit were actually a blueprint and up for a merge I would have done it the\nproper way (and with everyone else\'s input).  If you want to see that\ncode let me know, its just on a branch of a fork.  Nothing really much\nto see though, implemented in the easiest way possible.  For what its\nworth though, it did speed up the creation of an actual load balancer by\n75% on average.\n\nThe current way to define an extension\'s resources and objects is using\na dictionary that defines the resource, object expected for POSTs and\nPUTs, and plugin methods to be implemented.  This dictionary is passed\nto the neutron API controller that does validation, defaulting, and\nchecks if an attribute of an object is required and if it can be changed\non posts and puts.  This currently does not support defaults for 2nd\nlevel nested dictionary objects, and doesn\'t support validation,\ndefaulting, or required attributes for any nesting level after the\n2nd.  \n\nThis can easily be added in obviously (smells like recursion will come\nin handy), but it should be noted that just the resource and API object\nschema definitions for what we need for a single create call are not\nsupported right now.\n\nMaybe there\'s some way to allow the extensions to define their own\nvalidation for their own resources and objects.  That\'s probably another\ntopic for another day, though.\n\nOn Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote:\n>                 > 3. Could you describe the most complicated use case\n>                 > that your single-call API supports? Again, please be\n>                 > very specific here.\n>                 Same data can be derived from the link above.\n>                 \n>                 \n>         \n>         \n>         Ok, I\'m actually not seeing and complicated examples, but I\'m\n>         guessing that any attributes at the top of the page could be\n>         expanded on according the the syntax described.\n>         \n>         \n>         Hmmm...  one of the draw-backs I see with a \"one-call\"\n>         approach is you\'ve got to have really good syntax checking for\n>         everything right from the start, or (if you plan to handle\n>         primitives one at a time) a really solid roll-back strategy if\n>         anything fails or has problems, cleaning up any primitives\n>         that might already have been created before the whole call\n>         completes.\n>         \n>         \n>         The alternative is to not do this with primitives... but then\n>         I don\'t see how that\'s possible either. (And certainly not\n>         easy to write tests for:  The great thing about small\n>         primitives is their methods tend to be easier to unit test.)\n>  \n> These are the good arguments! That\'s why I\'d like to actually see the\n> code (even simplified approach will could work as a first step), i\n> thing it could do a lot of things clearer.\n> \n> \n> Thanks,\n> Eugene.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOQGYeX1-YZfBXv6m4kZx-bQYcuMrZzcckDm2PxU9FyhLg@mail.gmail.com>',NULL),('<1398145281.63308.YahooMailNeo@web193601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-22 13:41:21',28800,'2014-04-22 05:41:21',NULL,'[Openstack] information provided by swift-recon command for object\n	updater','hello all,\n\nI have a basic question about the object and container updater information given by recon middleware.\n\nAS we run swift-recon command for object updater, it gives following results:\n\nroot at swift-Virtualbox:~# swift-recon object --updater\n====================================================================================\n--> Starting reconnaissance on 4 hosts\n====================================================================================\n[2014-03-05 10:49:20] checking updater times\n[updater_last_sweep] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 4\n====================================================================================\n\nmy question is:\n?\nWhat does \"updater_last_sweep\" mean?\nWhat information does this attribute provide for object updater	?\n\nThanks \n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140422/d8ab7c02/attachment.html>\n\n',NULL,NULL),('<1398146277.39114.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-22 13:57:57',28800,'2014-04-22 05:57:57',NULL,'[Openstack] information provided by swift-recon command for object\n	expirer','hello all,\n\nI have a basic question about the object expirer information given by recon middleware.\n\nAS we run swift-recon command for object?expirer, it gives following results:\n\nroot at swift-Virtualbox:~# swift-recon object --expirer\n====================================================================================\n--> Starting reconnaissance on 4 hosts\n====================================================================================\n[2014-03-05 10:49:20] checking on?expirers\n[object_expiration_pass] low: 0, high: 0, avg: 0.0, total: 0, Failed: 75.0%, no_result: 3, reported: 1\n[expired_last_pass] low: 1, high: 1, avg: 1.0, total: 1, Failed: 75.0%, no_result: 3, reported: 1\n\n====================================================================================\n\nmy question is:\n?\nWhat do \"object_expiration_pass\" and \"expired_last_pass\" mean?\nWhat information do these attributes provide for object expirer	?\n\nThanks \n\nPragya Jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140422/6ea0a503/attachment.html>\n\n',NULL,NULL),('<1398147680.7909.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 07:21:20',3600,'2014-04-22 06:21:20',NULL,'[openstack-dev] [oslo] nominating Victor Stinner for the Oslo\n core reviewers team','On Mon, 2014-04-21 at 12:39 -0400, Doug Hellmann wrote:\n> I propose that we add Victor Stinner (haypo on freenode) to the Oslo\n> core reviewers team.\n> \n> Victor is a Python core contributor, and works on the development team\n> at eNovance. He created trollius, a port of Python 3\'s tulip/asyncio\n> module to Python 2, at least in part to enable a driver for\n> oslo.messaging. He has been quite active with Python 3 porting work in\n> Oslo and some other projects, and organized a sprint to work on the\n> port at PyCon last week. The patches he has written for the python 3\n> work have all covered backwards-compatibility so that the code\n> continues to work as before under python 2.\n> \n> Given his background, skills, and interest, I think he would be a good\n> addition to the team.\n\nSounds good to me!\n\nMark.\n\n\n\n','<CADb+p3Tc5HisAgAnP=Tdi7hw-nnMMJ2q42Ba2XvW-p3axUQ4Yg@mail.gmail.com>',NULL),('<1398154228-sup-94@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 01:12:12',-25200,'2014-04-22 08:12:12',NULL,'[openstack-dev] [Nova Baremetal] disk-image builder tool error','Excerpts from Jander lu\'s message of 2014-04-22 00:54:18 -0700:\n> Hi,\n> \n> I am following this wiki page(https://wiki.openstack.org/wiki/Baremetal ),\n\nThat web page is out of date. Will try to fix it in the next 48 hours.\n\n> by using devstack to set up a nova baremetal provision environment, but met\n> one problems as below:\n> \n> when I use disk-image builder(\n> https://github.com/openstack/diskimage-builder.git) command to build a\n> image, there is no output file and the error message seems confused to me,I\n> don\'t know what I should do next,  below is the output of the console.\n> \n> stack at helpme:~/diskimage-builder$ bin/disk-image-create -u base -o my-image\n> Building elements: base  base\n> Expanded element dependencies to: base\n> Building in /tmp/image.LB2Dc8vH\n> dib-run-parts Mon Apr 21 19:05:11 EDT 2014 Running\n> /tmp/image.LB2Dc8vH/hooks/root.d/01-ccache\n> dib-run-parts Mon Apr 21 19:05:11 EDT 2014 01-ccache completed\n> ----------------------- PROFILING -----------------------\n> \n> Target: root.d\n> \n> Script                                     Seconds\n> ---------------------------------------  ----------\n> \n> 01-ccache                                     0.042\n> \n> --------------------- END PROFILING ---------------------\n> Please include at least one distribution root element.\n\nYou need to specify \'debian\', \'fedora\', \'opensuse\' or \'ubuntu\' at the\nvery least.\n\n\n','<CANsZ8bj24C9WP7jR02LhVf51sBefKjL+sUVrmDS2TUWv8mE8tA@mail.gmail.com>',NULL),('<1398181201.3945.3.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 15:40:04',0,'2014-04-22 15:40:04',NULL,'[openstack-dev] [nova][qa][all] Home of rendered specs','Hi,\n\nI would second that - if there was a way stackforge projects could use\nit, that would be great.\n\nGraham\n\nOn Tue, 2014-04-22 at 18:52 +0400, Mike Scherbakov wrote:\n> Hi folks,\n> \n> would it be any possible to have same benefit for stackforge-hosted\n> projects..?\n> \n> \n> Thank you,\n> \n> \n> \n> On Fri, Mar 28, 2014 at 6:02 PM, Anne Gentle <anne at openstack.org>\n> wrote:\n> \n>         \n>         \n>         \n>         \n>         \n>         On Thu, Mar 27, 2014 at 6:25 PM, Joe Gordon\n>         <joe.gordon0 at gmail.com> wrote:\n>         \n>                 Hi All,\n>                 \n>                 \n>                 Now that nova and qa are beginning to use specs repos\n>                 [0][1]. Instead of being forced to read raw RST or\n>                 relying on github [3],  we want a domain where we can\n>                 publish the fully rendered sphinxdocs based specs\n>                 (rendered with oslosphinx of course). So how about:\n>                 \n>                 \n>                   specs.openstack.org/$project\n>                 \n>                 \n>                 specs instead of docs because docs.openstack.org\n>                 should only contain what is actually implemented so\n>                 keeping specs in another subdomain is an attempt to\n>                 avoid confusion as we don\'t expect every approved\n>                 blueprint to get implemented.\n>                 \n>                 \n>                 \n>                 \n>         \n>         \n>         Thanks for this, Joe and all!\n>         \n>         \n>         Anne\n>          \n>                 \n>                 Best,\n>                 Joe\n>                 \n>                 \n>                 \n>                 \n>                 [0] http://git.openstack.org/cgit/openstack/nova-specs/\n>                 [1] http://git.openstack.org/cgit/openstack/qa-specs/\n>                 [3] https://github.com/openstack/nova-specs/blob/master/specs/template.rst\n>                 \n>                 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>         \n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> \n> \n> \n> -- \n> \n> Mike Scherbakov\n> #mihgen\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/08a23778/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/08a23778/attachment.pgp>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/x-pkcs7-signature\nSize: 6961 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/08a23778/attachment.bin>\n\n','<CAKYN3rMXC3nhGwaRZ0ssbNHZweHOaQppckHByW19F87wm2gZxg@mail.gmail.com>',NULL),('<1398186481.19014.4.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-22 13:08:01',-14400,'2014-04-22 17:08:01',NULL,'[OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger\n startup','On Tue, 2014-04-22 at 16:49 +0000, Dane Leblanc (leblancd) wrote:\n> I?m trying to get zuul running on a 3rd party  test setup, but the\n> merge does not seem to be happening. I suspect that I?m just not\n> configuring the zuul merger correctly, or I?m missing some basic\n> startup step.\n> \n> In my setup, it?s a single node on which I?m trying to run zuul,\n> Jenkins, gearman, etc. (everything co-located).  I?m using the\n> ?IndependentPipelineManager? since this is for (not yet approved) code\n> reviews.  The zuul debug logs show that jobs are being submitted to\n> merger, but those jobs are never submitted to Jenkins.\n\nWhat is in /var/log/zuul/zuul-merger.log? Could you pastebin it?\n\n> The nc (netcat) utility shows that merger has messages in its queue,\n> but there?s no worker for merger: \n> \n> neutronpluginsci:/var/log/zuul$ echo status | nc -q 3 localhost 4730\n> \n> build:neutron   0       0       2\n> merger:merge    53      0       0         < = = = No worker\n> zuul:get_running_jobs   0       0       1\n> set_description:172.24.4.1      0       0       1\n> build:neutron_sandbox   0       0       2\n> stop:172.24.4.1 0       0       1\n> zuul:enqueue    0       0       1\n> zuul:promote    0       0       1 \n> \n> Some beginner questions:\n<snip>\n> (Likewise, should I be using ?git_user_name=zuul? here, or the git\n> user for our 3rd party gerrit account?\n\nYour 3rd party gerrit account.\n\n> (2)  Given that I?m using IndependentPipelineManager, is there a way I\n> can bypass the merger process?\n\nNo.\n\n> (3)  Is the merger/merge process automatically started by zuul or\n> gearman, and if so, how to debug its startup?\n\nNo, you need to start it with something like:\n\n sudo service zuul-merger start\n\nBest,\n-jay\n\n\n\n\n','<F35109456E81D64BB8A14D8A318FE7F52D2C66A3@xmb-aln-x06.cisco.com>',NULL),('<1398189071-sup-7471@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 10:52:53',-25200,'2014-04-22 17:52:53',NULL,'[openstack-dev] [Ironic] Supporting preserve_ephemeral in\n	rebuild()','Excerpts from David Shrewsbury\'s message of 2014-04-22 10:16:42 -0700:\n> Hi,\n> \n> I\'m working on implementing rebuild() in the nova.virt.ironic driver so\n> that we can support the --preserve-ephemeral option. I have a design\n> question and would love some feedback on it.\n> \n> The way to trigger a deploy is to set the provision state to ACTIVE.\n> However, for a rebuild, we cannot currently use this, since the API will\n> return an error saying that the target state and the current provision\n> state are the same, and return an error.\n> \n> I can think of a couple of ways around this:\n> \n> (1) If target and current provision state are ACTIVE, go ahead and allow\n> the (re)deploy.\n> \n> (2) Add a new provision state that would set the instance to a sort of\n> temporary limbo state, expecting to be redeployed at some point by setting\n> target to ACTIVE (as normal).\n\nI\'m not familiar with Ironic\'s internals, but I think rebuild is a\nspecial state, since it involves a pretty violent change to the box\n(overwriting the disks) that is definitely not the same as being in an\nACTIVE state where the user might expect it would be working.\n\n\n','<CAB91eg5TxUnFA479aq9dw2PzgMin4_SexyKVCHSxUBkbNnxBGg@mail.gmail.com>',NULL),('<1398191877-sup-3333@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 11:39:02',-25200,'2014-04-22 18:39:02',NULL,'[openstack-dev] Proposing Thomas Spatzier for heat-core','Excerpts from Zane Bitter\'s message of 2014-04-22 11:21:40 -0700:\n> I\'d like to propose that we add Thomas Spatzier to the heat-core team.\n> \n> Thomas has been involved in and consistently contributing to the Heat \n> community for around a year, since the time of the Havana design summit. \n> His code reviews are of extremely high quality IMO, and he has been \n> reviewing at a rate consistent with a member of the core team[1].\n> \n> One thing worth addressing is that Thomas has only recently started \n> expanding the focus of his reviews from HOT-related changes out into the \n> rest of the code base. I don\'t see this as an obstacle - nobody is \n> familiar with *all* of the code, and we trust core reviewers to know \n> when we are qualified to give +2 and when we should limit ourselves to \n> +1 - and as far as I know nobody else is bothered either. However, if \n> you have strong feelings on this subject nobody will take it personally \n> if you speak up :)\n> \n> Heat Core team members, please vote on this thread. A quick reminder of \n> your options[2]:\n> +1  - five of these are sufficient for acceptance\n>   0  - abstention is always an option\n> -1  - this acts as a veto\n> \n\n+1!\n\n\n','<5356B334.4090308@redhat.com>',NULL),('<1398193115.18419.12.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 18:58:35',0,'2014-04-22 18:58:35',NULL,'[openstack-dev]  [Climate] Query leases by project_id/domain_id','Hi\n	I\'m trying to tackle this bug\n(https://bugs.launchpad.net/climate/+bug/1304435). The options that I\'m\nconsidering are:\n\n	1 - Add the project_id query parameter to the leases API\n	2 - Use the X_PROJECT_ID header\n\n	I prefer the first option, but I would like to know if there is a\ngeneral OpenStack approach for implementing this. BTW, I\'m planning to\napply the same criteria for making queries for Domains.\n\nPablo.\n\n',NULL,NULL),('<1398204642.19014.7.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 18:10:42',-14400,'2014-04-22 22:10:42',NULL,'[openstack-dev] [keystone] Catalog Backend in Deployments\n (Templated, SQL, etc)','On Tue, 2014-04-22 at 12:38 -0700, Morgan Fainberg wrote:\n> During the weekly Keystone meeting, the topic of improving the Catalog\n> was brought up. This topic is in the context of preparing for the\n> design summit session on the Service Catalog. There are currently\n> limitations in the templated catalog that do not exist in the SQL\n> backed catalog. In an effort to provide the best support for the\n> catalog going forward, the Keystone team would like to get feedback on\n> the use of the various catalog backends.  \n> \n> \n> What we are looking for:\n>      1. In your OpenStack deployments, which catalog backend are you\n>         using?\n\ntemplated.\n\n>      1. Which Keystone API version are you using?\n\n2\n\nBest,\n-jay\n\np.s. You probably want to ask this on the openstack-operators list.\n\n\n\n','<etPan.5356c56c.327b23c6.279e@nullptr>',NULL),('<1398204682.19014.8.camel@cranky>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-22 18:11:22',-14400,'2014-04-22 22:11:22',NULL,'[Openstack-operators] [keystone] Catalog Backend in Deployments\n (Templated, SQL, etc) [x-posted from dev-list]','Ignore my comment about posting to the operators list :)\n\nOn Tue, 2014-04-22 at 12:39 -0700, Morgan Fainberg wrote:\n> During the weekly Keystone meeting, the topic of improving the Catalog\n> was brought up. This topic is in the context of preparing for the\n> design summit session on the Service Catalog. There are currently\n> limitations in the templated catalog that do not exist in the SQL\n> backed catalog. In an effort to provide the best support for the\n> catalog going forward, the Keystone team would like to get feedback on\n> the use of the various catalog backends.  \n> \n> \n> What we are looking for:\n>      1. In your OpenStack deployments, which catalog backend are you\n>         using?\n>      2. Which Keystone API version are you using?\n> This information will help us to prioritize updates to the catalog\n> over the next development cycle (Juno) as well as identify if any\n> changes need to be back-ported. In the long term, there is a desire to\n> target new features and functionality for the Service Catalog to the\n> SQL (and for testing KVS) backends, limiting enhancements and new\n> development done on the templated catalog backend.\n> \n> \n> Please feel free to respond via the survey below or via email to the\n>  mailing list.\n> \n> \n> Keystone Catalog Backend Usage\n> Survey: https://www.surveymonkey.com/s/3DL7FTY\n> \n> ?\n> Morgan Fainberg\n> Principal Software Engineer\n> Core Developer, Keystone\n> m at metacloud.com\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<etPan.5356c5a4.66334873.279e@nullptr>',NULL),('<1398205295.19014.11.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-22 18:21:35',-14400,'2014-04-22 22:21:35',NULL,'[OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger\n startup','On Tue, 2014-04-22 at 20:05 +0000, Dane Leblanc (leblancd) wrote:\n> Jay:\n> \n> Thanks for your help! I manually started the zuul-merger service, and things are progressing further, but with merge errors.\n> \n> I\'m not seeing a /var/log/zuul/zuul-merger.log, but I\'m don\'t have the merger logging set up correctly in the zuul.conf. The zuul documentation suggests:\n> \n> [merger]\n> log_config=/etc/zuul/logging.yaml\n> \n> Do you know where I might find a sample logging.yaml?  (There\'s a logging.conf in the zuul repo, but that doesn\'t have anything that\'s zuul-merger specific).\n\nHmm, actually no, I\'m not familiar with a logging.yaml file.\n\nSo, I checked out the upstream puppet module installation and I see this\nin their zuul.conf [1]:\n\nlog_config=/etc/zuul/merger-logging.conf\n\nYou can see the merger-logging.conf file here:\n\nhttps://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/merger-logging.conf\n\nI\'d just go ahead and copy that to /etc/zuul/merger-logging.conf\n\nBest,\n-jay\n\n[1]\nhttps://git.openstack.org/cgit/openstack-infra/config/tree/modules/zuul/templates/zuul.conf.erb\n\n\n\n\n\n','<F35109456E81D64BB8A14D8A318FE7F52D2C6C61@xmb-aln-x06.cisco.com>',NULL),('<1398208887.19014.26.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 19:21:27',-14400,'2014-04-22 23:21:27',NULL,'[openstack-dev] [Nova][blueprint] Accelerate the booting\n process of a number of vms via VMThunder','Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline.\n\nOn Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote:\n> I actually support the idea Huiba has proposed, and I am thinking of\n> how to optimize the large data transfer(for example, 100G in a short\n> time) as well. \n> I registered two blueprints in nova-specs, one is for an image upload\n> plug-in to upload the image to\n> glance(https://review.openstack.org/#/c/84671/), the other is a data\n> transfer plug-in(https://review.openstack.org/#/c/87207/) for data\n> migration among nova nodes. I would like to see other transfer\n> protocols, like FTP, bitTorrent, p2p, etc, implemented for data\n> transfer in OpenStack besides HTTP. \n> \n> Data transfer may have many use cases. I summarize them into two\n> catalogs. Please feel free to comment on it. \n> 1. The machines are located in one network, e.g. one domain, one\n> cluster, etc. The characteristic is the machines can access each other\n> directly via the IP addresses(VPN is beyond consideration). In this\n> case, data can be transferred via iSCSI, NFS, and definitive zero-copy\n> as Zhiyan mentioned. \n> 2. The machines are located in different networks, e.g. two data\n> centers, two firewalls, etc. The characteristic is the machines can\n> not access each other directly via the IP addresses(VPN is beyond\n> consideration). The machines are isolated, so they can not be\n> connected with iSCSI, NFS, etc. In this case, data have to go via the\n> protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy\n> can work for this case. Zhiyan, please help me with this doubt. \n> \n> I guess for data transfer, including image downloading, image\n> uploading, live migration, etc, OpenStack needs to taken into account\n> the above two catalogs for data transfer.\n\nFor live migration, we use shared storage so I don\'t think it\'s quite\nthe same as getting/putting image bits from/to arbitrary locations.\n\n>  It is hard to say that one protocol is better than another, and one\n> approach prevails another(BitTorrent is very cool, but if there is\n> only one source and only one target, it would not be that faster than\n> a direct FTP). The key is the use\n> case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/).\n\nRight, a good solution would allow for some flexibility via multiple\ntransfer drivers.\n\n> Jay Pipes has suggested we figure out a blueprint for a separate\n> library dedicated to the data(byte) transfer, which may be put in oslo\n> and used by any projects in need (Hoping Jay can come in:-)). Huiba,\n> Zhiyan, everyone else, do you think we come up with a blueprint about\n> the data transfer in oslo can work?\n\nYes, so I believe the most appropriate solution is to create a library\n-- in oslo or a standalone library like taskflow -- that would offer a\nsimple byte streaming library that could be used by nova.image to expose\na neat and clean task-based API.\n\nRight now, there is a bunch of random image transfer code spread\nthroughout nova.image and in each of the virt drivers there seems to be\ndifferent re-implementations of similar functionality. I propose we\nclean all that up and have nova.image expose an API so that a virt\ndriver could do something like this:\n\nfrom nova.image import api as image_api\n\n...\n\ntask = image_api.copy(from_path_or_uri, to_path_or_uri)\n# do some other work\ncopy_task_result = task.wait()\n\nWithin nova.image.api.copy(), we would use the aforementioned transfer\nlibrary to move the image bits from the source to the destination using\nthe most appropriate method.\n\nBest,\n-jay\n\n\n\n','<OF1CBCB2A7.B0078981-ON48257CC2.000D5691-48257CC2.00107E49@cn.ibm.com>',NULL),('<1398210053.19014.28.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 19:40:53',-14400,'2014-04-22 23:40:53',NULL,'[openstack-dev] 答复:  答复: [Nova][Neutron][Cinder][Heat]Should we support tags for os resources?','On Tue, 2014-04-22 at 02:02 +0000, Huangtianhua wrote:\n> Thanks very much.\n> \n>  \n> \n> I have register the blueprints for nova.  \n> \n> https://blueprints.launchpad.net/nova/+spec/add-tags-for-os-resources\n> \n>  \n> \n> The simple plan is:\n> \n> 1.      Add the tags api (create tags/delete tags/describe tags) for\n> v3 api\n> \n> 2.      Change the implement for instance from ?metadata? to ?tags?\n> \n>  \n> \n> Your suggestions?\n\nHi again,\n\nThe Nova blueprint process has changed. We now use a Gerrit repository\nto submit, review, and approve blueprint specifications. Please see here\nfor information on how to submit a spec for the proposed blueprint:\n\nhttps://wiki.openstack.org/wiki/Blueprints#Nova\n\nThank you!\n-jay\n\n\n\n\n','<E07566D89ECB9F43A509FE8A276ADDED3FFBF627@SZXEMA510-MBX.china.huawei.com>',NULL),('<1398210222.19014.31.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 19:43:42',-14400,'2014-04-22 23:43:42',NULL,'[openstack-dev] [Nova][Neutron][Cinder][Heat]Should we support\n tags for os resources?','On Tue, 2014-04-22 at 13:14 +0200, Thomas Spatzier wrote:\n> <snip>\n> >  * Identify key/value pairs that are relied on by all of Nova to be a\n> > specific key and value combination, and make these things actual real\n> > attributes on some object model -- since that is a much greater guard\n> > for the schema of an object and enables greater performance by allowing\n> > both type safety of the underlying data and removes the need to search\n> > by both a key and a value.\n> \n> Makes a lot of sense to me. So are you suggesting to have a set of\n> well-defined property names per resource but still store them in the\n> properties name-value map? Or would you rather make those part of the\n> resource schema?\n\nI\'d rather have the common ones in the resource schema itself, since\nthat is, IMHO, better practice for enforcing consistency and type\nsafety.\n\n> BTW, here is a use case in the context of which we have been thinking about\n> that topic: we opened a BP for allowing constraint based selection of\n> images for Heat templates, i.e. instead of saying something like (using\n> pseudo template language)\n> \n> \"image ID must be in [fedora-19-x86_64, fedora-20-x86_64]\"\n> \n> say something like\n> \n> \"architecture must be x86_64, distro must be fedora, version must be\n> between 19 and 20\"\n> \n> (see also [1]).\n> \n> This of course would require the existence of well-defined properties in\n> glance so an image selection query in Heat can work.\n\nZactly :)\n\n> As long as properties are \"just\" custom properties, we would require a lot\n> of discipline from every to maintain properties correctly.\n\nYep, and you\'d need to keep in sync with the code in Nova that currently\nmaintains these properties. :)\n\nBest,\n-jay\n\n>  And the\n> implementation in Heat could be kind of tolerant, i.e. give it a try, and\n> if the query fails just fail the stack creation. But if this is likely to\n> happen in 90% of all environments, the usefulness is questionable.\n> \n> Here is a link to the BP I mentioned:\n> [1]\n> https://blueprints.launchpad.net/heat/+spec/constraint-based-flavors-and-images\n> \n> Regards,\n> Thomas\n> \n> >\n> > Best,\n> > -jay\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OF4BC75B9A.5233D351-ONC1257CC2.003C2E5B-C1257CC2.003DB52B@de.ibm.com>',NULL),('<1398211474.19014.32.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 20:04:34',-14400,'2014-04-23 00:04:34',NULL,'[openstack-dev] [nova] nova-specs and python-novaclient','On Tue, 2014-04-22 at 17:00 -0700, Joe Gordon wrote:\n> Hi All,\n> \n> \n> Several folks have submitted python-novaclient blueprints to nova\n> specs for the Juno Release [0][1], but since python-novaclient isn\'t\n> part of the integrated release this doesn\'t really make sense.\n> Furthermore the template we have has sections that make no sense for\n> the client (such as \'REST API impact\'). \n> \n> \n> So how should we handle python-novaclient blueprints? Keep them in\n> nova-specs in a separate directory? Separate repo?\n> \n> \n> I think generalize the nova-specs repo from a repo for blueprints for\n> just nova to a repo for all \'compute program\' blueprints. Right now\n> that would just cover nova and python-novaclient, but may include\n> other repositories in the future.\n\n+1\n\n-jay\n\n\n\n\n','<CAHXdxOe-HcqsPkiOq=eGQ_jRFn0Yx1Zx2dLvBFmxk5sRDhW60w@mail.gmail.com>',NULL),('<1398230607.19014.47.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 01:23:27',-14400,'2014-04-23 05:23:27',NULL,'[openstack-dev] [Openstack] [Nova] BP about usb-passthrough RE:\n Change in openstack/nova-specs[master]: Support specify USB controller for\n USB-passthrough','On Wed, 2014-04-23 at 02:01 +0000, Yuanjing (D) wrote:\n> Hi\n> \n> I have proposed three BPs about usb-passthrough.\n> 1. Usb-passthrough is the core function I want to provide which is in https://review.openstack.org/#/c/86404/.\n> 2. The function of specify usb controller for usb-passthrough is for refine the use of Usb-passthrough, which is \n> in https://review.openstack.org/#/c/88337/. \n> 3. The function of specify usb controller is the prerequisite of specify usb controller for usb-passthrough which is \n> in https://review.openstack.org/#/c/88334.\n> \n> The backgrounds are:\n> I want to make a detailed explanation about why I suggest to provide this function.\n>  \n> We provide VDI(Virtual Desktop) and server virtualization solutions for customers, our customers have strong requirements for using USB devices.\n>  \n> The typical use cases and our solutions are described as below:\n> \n> 1.In VDI solution, customers want to use local USB printers or USB scanners with TC(Thin-Client), because remote desktop protocol like ICA have already support USB-redirection, \n> so customers only need to attach USB device to TC, the protocol can map USB device to VM.\n> \n> 2. In virtualization solution, when starting or restarting some business-critical applications, a connected USB-KEY is needed for authentication, \n> some applications even need a daily authentication by USB-KEY. we suggest the following solutions:\n> (1) Using physical \'USB-HUB\' box and technology of USB-redirection over TCP/IP. Customers need to buy USB-HUB and install software in guest os, the software helps\n> redirecting USB device to VM.\n> \n> (2) Using USB-Passthrough and USB hot-plug functions provided by our virtualization software. The end users(normally application or system administrators) \n> insert USB devices to host that containing the VM, then  can see USB device list in portal and choose USB device to attach.\n> \n> This solution has advantages that\n> 1. It doesn\'t need additional physical devices \n> \n> 2. It doesn\'t need a special server to run spice client for USB-Redirection \n> \n> 3. Business-critical applications commonly need stable and long-standing USB-KEY to attach, USB-Passthrough maybe more stable than USB-Redirection over TCP/IP or remote desktop protocol.\n\nHi Jing, thx for your above email.\n\nI think of cloud computing as providing a way for users to *not* have to\nmanage hardware -- they are free to work with virtual servers and then\nthrow them away when not needed or get a new one quickly if something\nbad happens.\n\nI\'m afraid I don\'t see any relation to what I think of as \"cloud\" in the\nsecond use case you list above. I don\'t think having a system\nadministrator running around to a physical machine in a datacenter and\nplugging in a USB key is a \"cloudy\" activity.\n\nFor the first use case, however, where the user inserts a USB device on\nthe thin client and USB redirection allows the VM to read/write to the\nUSB device on the thin client, I certainly see a good use case there.\n\nHowever, I am uncertain which of your blueprints deals exclusively with\nthe first use case. Could you advise on that?\n\nBest,\n-jay\n\n\n\n','<80E359A9D2090541A5872B6665C8E3262D573235@SZXEMA503-MBX.china.huawei.com>',NULL),('<1398234359.21631.71.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 07:25:59',3600,'2014-04-23 06:25:59',NULL,'[openstack-dev] [Oslo] [Ironic] Can we change\n rpc_thread_pool_size default value?','On Tue, 2014-04-22 at 15:54 -0700, Devananda van der Veen wrote:\n> Hi!\n> \n> When a project is using oslo.messaging, how can we change our default\n> rpc_thread_pool_size?\n> \n> -----------------------\n> Background\n> \n> Ironic has hit a bug where a flood of API requests can deplete the RPC\n> worker pool on the other end and cause things to break in very bad ways.\n> Apparently, nova-conductor hit something similar a while back too. There\'ve\n> been a few long discussions on IRC about it, tracked partially here:\n>   https://bugs.launchpad.net/ironic/+bug/1308680\n> \n> tldr; a way we can fix this is to set the rpc_thread_pool_size very small\n> (eg, 4) and keep our conductor.worker_pool size near its current value (eg,\n> 64). I\'d like these to be the default option values, rather than require\n> every user to change the rpc_thread_pool_size in their local ironic.conf\n> file.\n> \n> We\'re also about to switch from the RPC module in oslo-incubator to using\n> the oslo.messaging library.\n> \n> Why are these related? Because it looks impossible for us to change the\n> default for this option from within Ironic, because the option is\n> registered when EventletExecutor is instantaited (rather than loaded).\n> \n> https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/impl_eventlet.py#L76\n\nIt may have been possible for Ironic to set its own default before\noslo.messaging, but it wouldn\'t have been recommended because there\'s no\nexplicit API for doing so.\n\nWith oslo.messaging, we have a set_transport_defaults() which shows how\nwe\'d approach adding this capability.\n\nThe question comes down to whether this really is a situation where we\nneed per-application defaults or just that the current defaults are\nscrewed up. If the latter, I\'d much rather just change the defaults.\n\nMark.\n\n\n\n','<CAExZKErCUQbsePA7Zok6E6MWce=h9TBykn6LqC4keRF82dTdag@mail.gmail.com>',NULL),('<1398238152.5644.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-23 15:29:12',28800,'2014-04-23 07:29:12',NULL,'[Openstack] information provided by swift-recon command for\n	object expirer','please somebody reply to my questions\n\nPragya Jain\nOn Tuesday, 22 April 2014 11:27 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>\n>\n>I have a basic question about the object expirer information given by recon middleware.\n>\n>\n>AS we run swift-recon command for object?expirer, it gives following results:\n>\n>\n>root at swift-Virtualbox:~# swift-recon object --expirer\n>====================================================================================\n>--> Starting reconnaissance on 4 hosts\n>====================================================================================\n>[2014-03-05 10:49:20] checking on?expirers\n>[object_expiration_pass] low: 0, high: 0, avg: 0.0, total: 0, Failed: 75.0%, no_result: 3, reported: 1\n>[expired_last_pass] low: 1, high: 1, avg: 1.0, total: 1, Failed: 75.0%, no_result: 3, reported: 1\n>\n>====================================================================================\n>\n>\n>my question is:\n>?\n>What do \"object_expiration_pass\" and \"expired_last_pass\" mean?\n>What information do these attributes provide for object expirer	?\n>\n>\n>Thanks \n>\n>Pragya Jain\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140423/05165373/attachment.html>\n\n','<1398146277.39114.YahooMailNeo@web193604.mail.sg3.yahoo.com>',NULL),('<1398238175.5938.YahooMailNeo@web193606.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-23 15:29:35',28800,'2014-04-23 07:29:35',NULL,'[Openstack] information provided by swift-recon command for\n	object updater','please somebody reply to my questions\n\nPragya Jain\nOn Tuesday, 22 April 2014 11:11 AM, pragya jain <prag_2648 at yahoo.co.in> wrote:\n \nhello all,\n>\n>\n>I have a basic question about the object and container updater information given by recon middleware.\n>\n>\n>AS we run swift-recon command for object updater, it gives following results:\n>\n>\n>root at swift-Virtualbox:~# swift-recon object --updater\n>====================================================================================\n>--> Starting reconnaissance on 4 hosts\n>====================================================================================\n>[2014-03-05 10:49:20] checking updater times\n>[updater_last_sweep] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 4\n>====================================================================================\n>\n>\n>my question is:\n>?\n>What does \"updater_last_sweep\" mean?\n>What information does this attribute provide for object updater	?\n>\n>\n>Thanks \n>\n>Pragya Jain\n>\n>\n>\n>\n>\n>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140423/71f75749/attachment.html>\n\n','<1398145281.63308.YahooMailNeo@web193601.mail.sg3.yahoo.com>',NULL),('<1398265349.19014.50.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 11:02:29',-14400,'2014-04-23 15:02:29',NULL,'[openstack-dev] [Nova][blueprint] Accelerate the booting\n process of a number of vms via VMThunder','On Wed, 2014-04-23 at 13:56 +0800, lihuiba wrote:\n> >For live migration, we use shared storage so I don\'t think it\'s quite\n> >the same as getting/putting image bits from/to arbitrary locations.\n> With a good zero-copy transfer lib, live migration support can be \n> extended to non-shared storage, or cross-datacenter. It\'s a kind of\n> value.\n\nHmm, I totally see the value of doing this. Not sure that there could be\nthe same kinds of \"liveness\" guarantees with non-shared-storage, but I\nam certainly happy to see a proof of concept in this area! :)\n\n> >task = image_api.copy(from_path_or_uri, to_path_or_uri)\n> ># do some other work\n> >copy_task_result = task.wait()\n> +1  looks cool!\n> how about zero-copying?\n\nIt would be an implementation detail within nova.image.api.copy()\nfunction (and the aforementioned \"image bits mover library\") :)\n\nThe key here is to leak as little implementation detail out of the\nnova.image.api module\n\nBest,\n-jay\n\n> At 2014-04-23 07:21:27,\"Jay Pipes\" <jaypipes at gmail.com> wrote:\n> >Hi Vincent, Zhi, Huiba, sorry for delayed response. See comments inline.\n> >\n> >On Tue, 2014-04-22 at 10:59 +0800, Sheng Bo Hou wrote:\n> >> I actually support the idea Huiba has proposed, and I am thinking of\n> >> how to optimize the large data transfer(for example, 100G in a short\n> >> time) as well. \n> >> I registered two blueprints in nova-specs, one is for an image upload\n> >> plug-in to upload the image to\n> >> glance(https://review.openstack.org/#/c/84671/), the other is a data\n> >> transfer plug-in(https://review.openstack.org/#/c/87207/) for data\n> >> migration among nova nodes. I would like to see other transfer\n> >> protocols, like FTP, bitTorrent, p2p, etc, implemented for data\n> >> transfer in OpenStack besides HTTP. \n> >> \n> >> Data transfer may have many use cases. I summarize them into two\n> >> catalogs. Please feel free to comment on it. \n> >> 1. The machines are located in one network, e.g. one domain, one\n> >> cluster, etc. The characteristic is the machines can access each other\n> >> directly via the IP addresses(VPN is beyond consideration). In this\n> >> case, data can be transferred via iSCSI, NFS, and definitive zero-copy\n> >> as Zhiyan mentioned. \n> >> 2. The machines are located in different networks, e.g. two data\n> >> centers, two firewalls, etc. The characteristic is the machines can\n> >> not access each other directly via the IP addresses(VPN is beyond\n> >> consideration). The machines are isolated, so they can not be\n> >> connected with iSCSI, NFS, etc. In this case, data have to go via the\n> >> protocols, like HTTP, FTP, p2p, etc. I am not sure whether zero-copy\n> >> can work for this case. Zhiyan, please help me with this doubt. \n> >> \n> >> I guess for data transfer, including image downloading, image\n> >> uploading, live migration, etc, OpenStack needs to taken into account\n> >> the above two catalogs for data transfer.\n> >\n> >For live migration, we use shared storage so I don\'t think it\'s quite\n> >the same as getting/putting image bits from/to arbitrary locations.\n> >\n> >>  It is hard to say that one protocol is better than another, and one\n> >> approach prevails another(BitTorrent is very cool, but if there is\n> >> only one source and only one target, it would not be that faster than\n> >> a direct FTP). The key is the use\n> >> case(FYI:http://amigotechnotes.wordpress.com/2013/12/23/file-transmission-with-different-sharing-solution-on-nas/).\n> >\n> >Right, a good solution would allow for some flexibility via multiple\n> >transfer drivers.\n> >\n> >> Jay Pipes has suggested we figure out a blueprint for a separate\n> >> library dedicated to the data(byte) transfer, which may be put in oslo\n> >> and used by any projects in need (Hoping Jay can come in:-)). Huiba,\n> >> Zhiyan, everyone else, do you think we come up with a blueprint about\n> >> the data transfer in oslo can work?\n> >\n> >Yes, so I believe the most appropriate solution is to create a library\n> >-- in oslo or a standalone library like taskflow -- that would offer a\n> >simple byte streaming library that could be used by nova.image to expose\n> >a neat and clean task-based API.\n> >\n> >Right now, there is a bunch of random image transfer code spread\n> >throughout nova.image and in each of the virt drivers there seems to be\n> >different re-implementations of similar functionality. I propose we\n> >clean all that up and have nova.image expose an API so that a virt\n> >driver could do something like this:\n> >\n> >from nova.image import api as image_api\n> >\n> >...\n> >\n> >task = image_api.copy(from_path_or_uri, to_path_or_uri)\n> ># do some other work\n> >copy_task_result = task.wait()\n> >\n> >Within nova.image.api.copy(), we would use the aforementioned transfer\n> >library to move the image bits from the source to the destination using\n> >the most appropriate method.\n> >\n> >Best,\n> >-jay\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<19ef7b3c.81c9.1458d2893ea.Coremail.magazine.lihuiba@163.com>',NULL),('<1398266387.19014.51.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 11:19:47',-14400,'2014-04-23 15:19:47',NULL,'[openstack-dev] [Neutron] Flavor(?) Framework','On Wed, 2014-04-23 at 19:05 +0400, Eugene Nikanorov wrote:\n> Hi neutrons,\n> \n> \n> A quick question of the ^^^\n> I heard from many of you that a term \'flavor\' is undesirable, but so\n> far there were no suggestions for the notion that we are going to\n> introduce.\n> So please, suggest you name for the resource.\n> Names that I\'ve been thinking of:\n>  - Capability group\n>  - Service Offering\n\nLoad balancer type\nVPN type\nFirewall type\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwOQZgR3fw-Yz_a59UAFbrPPKuTSNf2+7uT_7AE3n5uMbxw@mail.gmail.com>',NULL),('<1398266953.19014.53.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 11:29:13',-14400,'2014-04-23 15:29:13',NULL,'[openstack-dev] [Neutron] Flavor(?) Framework','On Wed, 2014-04-23 at 19:24 +0400, Eugene Nikanorov wrote:\n> Thanks, that can be an option.\n\n> Just wondering, can we find a single name?\n\nservice type? :)\n\nOh, I guess that\'s taken. Well, we could always rename the existing\nservice type to \"service class\" or \"service family\".\n\nBest,\n-jay\n\n\n\n\n','<CAJfiwOTTTvQx+F5WadiA2TpUK4Y6JiFDp7d7GjDSZ4unzONpBg@mail.gmail.com>',NULL),('<1398275793.19014.54.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 13:56:33',-14400,'2014-04-23 17:56:33',NULL,'[openstack-dev] [Ceilometer] Performance tests of\n ceilometer-collector and ceilometer-api with different backends','On Wed, 2014-04-23 at 17:32 +0000, Tim Bell wrote:\n> \n> There are a number of problem reports on ceilometer performance and\n> some promising blueprints to address them. I\'d suggest we re-run the\n> performance test when those are in place. Having reference performance\n> tests such as this are helpful to pick up cases where there are\n> regression or scalability problems such as you raise (and production\n> users see them also)\n\n++, and also need the SQL driver tested as well.\n\nBest,\njay\n\n\n\n\n','<DFB5CF4D-9AA7-4DC2-B7E7-FA64937EB6DE@cern.ch>',NULL),('<1398282102.2848.2.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 15:41:42',-14400,'2014-04-23 19:41:42',NULL,'[openstack-dev] [nova] [qa] EC2 status and call for assistance','On Wed, 2014-04-23 at 11:47 -0700, Randy Bias wrote:\n> Sean,\n> \n> We have a bunch of tempest tests we?re ready to push back that\n> increase coverage for the EC2 tests.  Also, rather than deprecating\n> the EC2 pieces, which are in use by ~35% of the community, I?d like to\n> recommend we move them into Stackforge as we did with the GCE APIs.\n> That way these can become optional components installed by those who\n> want to use them.  The other advantage is that they can be iterated on\n> out of band.  I would still like to see them all in the CI system\n> however.\n\n+1 on all points.\n\n-jay\n\n\n\n\n','<E15E2017-5017-41E3-B30D-CEBC76FB91C8@cloudscaling.com>',NULL),('<1398282974.2848.12.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 15:56:14',-14400,'2014-04-23 19:56:14',NULL,'[openstack-dev] [Globalization] REST API sorting by status\n severity vs. alphabetical status key','Hi Steven, thx for the detailed email. Some comments inline...\n\nOn Wed, 2014-04-23 at 13:59 -0500, Steven Kaufer wrote:\n> I am trying to address the following use case:\n> \n> - Assume that the REST APIs support returning data based on a\n> user-defined sort key (assuming that this get approved:\n>  https://review.openstack.org/#/c/84451/)\n> - UI contains a table showing items (servers, volumes, etc.) and their\n> status (as a sortable column) and uses pagination to get only a page\n> of data\n> - UI is translated into a non-English language\n> - User wants to sort the table by status\n> \n> In this case, the sorting by status is done against the English key\n> values in the database (active, error, etc.).  The UI will then\n> translate the status values into the user\'s locale and (from the\n> user\'s perspective) the data will not be in sorted order -- thus\n> confusing and frustrating the user.  Note that UI cannot do the sort\n> client-side since pagination is used so it the client only has a\n> sub-set of the total data.\n\nIndeed, this is a problem.\n\n> I have prototyped a \"sort by case\" solution that would allow status to\n> be sorted by severity.  In SQL the \"case\" statement can be used to map\n> a string to an int and then sort the rows based on the int value (ie,\n> error=0, building=1, active=2, etc.).  Using this approach, sorting by\n> status would result in an enum-like sort (based on severity) instead\n> of an alphabetical sort based on the English key values.  This\n> solution allows enum-like data to be sorted in a consistent way across\n> all locales -- the solution is generic and can be applied to any\n> column where the values are a known set.\n> \n> The case processing would need to be done in the common paginate_query\n> function:\n>  https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L62\n> \n> This type of sort would not be the default behavior for a status\n> column (or any enum-like column) and the caller would need to specify\n> a unique sort direction key for it (ie, \'asc_case\' or \'desc_case\').\n>  In theory, this type of sorting support could also be globally\n> enabled/disabled by a deployer (default would be disabled) to further\n> reduce impact.\n> \n> Lastly, I have some performance data and sorting the status by case\n> (vs. alphabetical) has a minimal impact on performance.\n> \n> Before I create a proposal for juno I wanted to get some early\n> feedback on the high-level approach.  Please reply with feedback on\n> this solution.\n\nSo, I feel that the above solution (while innovative certainly! :) ) is\nnot actually addressing the underlying source of the problem here, and\nthat is that statuses are stored in the database as English-language\nstrings instead of integer code values in a lookup table.\n\nBy addressing the underlying source of the problem -- by changing the\ninstances.{vm,task,power}_state columns to an integer value and using a\nlookup table in the cases when translation from code to display is\nneeded -- we both solve the problem of i18n sorting and increase the\ndatabase performance, since queries on these state columns will use an\nindex on a datatype with a much slimmer width.\n\nBest,\n-jay\n\n\n\n','<OFF6B7E28A.1C9704CB-ON87257CC3.0066F9CD-86257CC3.00684D39@us.ibm.com>',NULL),('<1398286203.2848.19.camel@cranky>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-23 16:50:03',-14400,'2014-04-23 20:50:03',NULL,'[OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger\n startup','On Wed, 2014-04-23 at 20:40 +0000, Dane Leblanc (leblancd) wrote:\n> Jay:\n> \n> Thanks, your merger-logging.conf file helped me get further... the Jenkins jobs are now being called after the merge.\n\nAwesome news :)\n\n> For the Jenkins job script... Is there a way to run DevStack and tell it to clone one project (openstack/neutron, in my case) from the local merged repo, but to clone all other projects from the usual github?  Is there a localrc setting (e.g. NEUTRON_BRANCH) which can be used for this?\n\nYup, there is. There are environment variables (ZUUL_REF, ZUUL_PROJECT,\nZUUL_BRANCH, etc) that are passed by Gerrit to Zuul and may be used by\nscripts to set up your environment.\n\nUnless there\'s a *really* good reason not to, I would advise using the\nupstream devstack-gate setup scripts to construct your environment.\nThese scripts understand the ZUUL_XXX variables and call devstack\'s\nstack.sh script and set up all the plumbing for you to point the\nZuul-controlled Git repositories to either the SHA1 of the commit being\ntested, or the HEAD of the master branches of other projects.\n\nYou can control the devstack-gate scripts with a dizzying array of\nenvironment variables as well.\n\nI\'d recommend giving these articles a read. They will walk you through\ndevstack-gate and their integration with Zuul.\n\nhttp://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system/\nhttp://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/\n\nYou can always find me on IRC #openstack-nova or #openstack-neutron. I\'m\nhappy to help you.\n\nBest,\n-jay\n\n> Thanks again,\n> Dane\n> \n> -----Original Message-----\n> From: Jay Pipes [mailto:jaypipes at gmail.com] \n> Sent: Tuesday, April 22, 2014 6:22 PM\n> To: Dane Leblanc (leblancd)\n> Cc: openstack-infra at lists.openstack.org\n> Subject: Re: [OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger startup\n> \n> On Tue, 2014-04-22 at 20:05 +0000, Dane Leblanc (leblancd) wrote:\n> > Jay:\n> > \n> > Thanks for your help! I manually started the zuul-merger service, and things are progressing further, but with merge errors.\n> > \n> > I\'m not seeing a /var/log/zuul/zuul-merger.log, but I\'m don\'t have the merger logging set up correctly in the zuul.conf. The zuul documentation suggests:\n> > \n> > [merger]\n> > log_config=/etc/zuul/logging.yaml\n> > \n> > Do you know where I might find a sample logging.yaml?  (There\'s a logging.conf in the zuul repo, but that doesn\'t have anything that\'s zuul-merger specific).\n> \n> Hmm, actually no, I\'m not familiar with a logging.yaml file.\n> \n> So, I checked out the upstream puppet module installation and I see this in their zuul.conf [1]:\n> \n> log_config=/etc/zuul/merger-logging.conf\n> \n> You can see the merger-logging.conf file here:\n> \n> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/merger-logging.conf\n> \n> I\'d just go ahead and copy that to /etc/zuul/merger-logging.conf\n> \n> Best,\n> -jay\n> \n> [1]\n> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/zuul/templates/zuul.conf.erb\n> \n> \n> \n\n\n\n\n','<F35109456E81D64BB8A14D8A318FE7F52D2C8375@xmb-aln-x06.cisco.com>',NULL),('<1398291586.2706.8.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 17:19:46',-18000,'2014-04-23 22:19:46',NULL,'[openstack-dev] [Globalization] REST API sorting by status\n severity vs. alphabetical status key','On Wed, 2014-04-23 at 15:29 -0500, Steven Kaufer wrote:\n> Thanks for the reply.  I agree that changing the datamodel would be\n> the ideal solution.  But, to be honest, the scope of that change\n> frightens me.\n> \n> How would you recommend that a change like this would be handled (in\n> addition to the DB migration work)?  We obviously cannot break\n> existing codepaths that assume that the existing English key values\n> would be returned from the DB.\n> \n> Is there an existing layer that would perform the mapping between the\n> enum values in the DB and the String keys?\n\nTheoretically, at least, all the status values should be using and\ncomparing against constants; see, for instance,\nnova/compute/vm_states.py.  Those could be converted to integers, with a\ntranslation table specified in the database migration.  The scary thing,\nthough, is just how long that migration will end up taking?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<OF0F7F739B.735AAD9B-ON87257CC3.006FB79E-86257CC3.00708E68@us.ibm.com>',NULL),('<1398292082.2848.22.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 18:28:02',-14400,'2014-04-23 22:28:02',NULL,'[openstack-dev] [Globalization] REST API sorting by status\n severity vs. alphabetical status key','On Wed, 2014-04-23 at 17:19 -0500, Kevin L. Mitchell wrote:\n> On Wed, 2014-04-23 at 15:29 -0500, Steven Kaufer wrote:\n> > Thanks for the reply.  I agree that changing the datamodel would be\n> > the ideal solution.  But, to be honest, the scope of that change\n> > frightens me.\n> > \n> > How would you recommend that a change like this would be handled (in\n> > addition to the DB migration work)?  We obviously cannot break\n> > existing codepaths that assume that the existing English key values\n> > would be returned from the DB.\n> > \n> > Is there an existing layer that would perform the mapping between the\n> > enum values in the DB and the String keys?\n> \n> Theoretically, at least, all the status values should be using and\n> comparing against constants; see, for instance,\n> nova/compute/vm_states.py.  Those could be converted to integers, with a\n> translation table specified in the database migration.  The scary thing,\n> though, is just how long that migration will end up taking\n\nWorth it, IMO :)\n\nThere\'s also a possibility of adding support for the status codes, but\nkeeping the string columns in the database, and then using the nova\nobject versioning to \"migrate\" the object schema over time to the point\nwhere the migration is a simple DROP COLUMN.\n\nBest,\n-jay\n\n\n\n\n','<1398291586.2706.8.camel@einstein.kev>',NULL),('<1398292426.2706.11.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 17:33:46',-18000,'2014-04-23 22:33:46',NULL,'[openstack-dev] [Globalization] REST API sorting by status\n severity vs. alphabetical status key','On Wed, 2014-04-23 at 18:28 -0400, Jay Pipes wrote:\n> Worth it, IMO :)\n\nyeah, we\'re talking about thousands and thousands of rows that have to\nbe updated before the API can be restarted?\n\n> There\'s also a possibility of adding support for the status codes, but\n> keeping the string columns in the database, and then using the nova\n> object versioning to \"migrate\" the object schema over time to the point\n> where the migration is a simple DROP COLUMN.\n\nI like that idea better, TBH, but we\'re probably talking about a\nlong-time deprecation here, like on the order of a couple of releases;\nthat would give plenty of time for the majority of the records to be\nrevisited and make the final migration run for a lot shorter time.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<1398292082.2848.22.camel@cranky>',NULL),('<1398298147.2426.25.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 19:09:07',-18000,'2014-04-24 00:09:07',NULL,'[openstack-dev] [cinder] proposal of definitions/processes for\n	cinder-spec','All,\n\nI have gotten questions from our driver developers asking for details\nregarding the move to using cinder-specs for proposing Blueprints.  I\nbrought this topic up in today\'s Cinder Weekly Meeting, but the meeting\nwas lightly attended so we decided to move the discussion here.\n\nI am going to put this note in the form of \'question\' and proposed\nanswer based on the brief discussion we had today.  Note that the\nanswers here are based on the assumption that we want to keep Cinder\'s\nuse of \'specs\' as close to Nova\'s as possible.  I used the following\nmailing list thread as a starting point for some of these answers:\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-April/032796.html\n\nQ: When is a spec approved?\nA:  When it receives a +2 from the PTL and at least one other Core\nreviewer.\n\nQ: How long are specs valid for?\nA: For the duration of the release cycle.  Any specs that are not\napproved during that period of type will need to be resubmitted for the\nsubsequent release.\n\nQ: What will the spec template look like?\nA: This is one of the points I would like to discuss.  The Nova template\ncurrently looks like this:\nhttps://github.com/openstack/nova-specs/blob/master/specs/template.rst\nDo we want to follow the same template.  In the interest of staying in\nsync with Nova\'s implementation I would say yes, but does this meet our\nneeds?  Are there other/different fields we want to consider to help for\ninstances where the Blueprint is for a new driver or change to a driver?\nI think we might need, for instance, a \'Drivers Impacted\' field.\n\nQ: Will driver developers have to use the same template for functions in\ntheir drivers?\nA: Also a point I would like to discuss.  Developers had asked if a more\nlimited template would be used for changes going into the developer\'s\ndriver.  At first I thought maybe a different template for Blueprints\nagainst a driver might be appropriate, but after looking more closely at\nNova\'s template perhaps that is not necessary.  I would lean towards\nkeeping one template, but maybe not requiring all fields depending on\nwhat our final template ends up looking like.  \n\nQ: Where do specs for python-cinderclient go?\nA: Looks like Nova has added a python-novaclient directory.  I don\'t\nthink we would need a separate python-cinderclient-specs repository but\ndon\'t have a strong opinion on this point.\n\nI am sure this is not an exhaustive list of questions/answers at this\npoint in time but I wanted to start the discussion so we could help move\nthis process forward.  I look forward to your feedback.\n\n-Jay Bryant\njsbryant at electronicjungle.net\nFreenode:  jungleboyj\n\n\n\n\n\n',NULL,NULL),('<1398337253.28789.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 12:00:53',3600,'2014-04-24 11:00:53',NULL,'[openstack-dev] [Oslo] [Ironic] Can we change\n rpc_thread_pool_size default value?','On Wed, 2014-04-23 at 07:25 +0100, Mark McLoughlin wrote:\n> On Tue, 2014-04-22 at 15:54 -0700, Devananda van der Veen wrote:\n> > Hi!\n> > \n> > When a project is using oslo.messaging, how can we change our default\n> > rpc_thread_pool_size?\n> > \n> > -----------------------\n> > Background\n> > \n> > Ironic has hit a bug where a flood of API requests can deplete the RPC\n> > worker pool on the other end and cause things to break in very bad ways.\n> > Apparently, nova-conductor hit something similar a while back too. There\'ve\n> > been a few long discussions on IRC about it, tracked partially here:\n> >   https://bugs.launchpad.net/ironic/+bug/1308680\n> > \n> > tldr; a way we can fix this is to set the rpc_thread_pool_size very small\n> > (eg, 4) and keep our conductor.worker_pool size near its current value (eg,\n> > 64). I\'d like these to be the default option values, rather than require\n> > every user to change the rpc_thread_pool_size in their local ironic.conf\n> > file.\n> > \n> > We\'re also about to switch from the RPC module in oslo-incubator to using\n> > the oslo.messaging library.\n> > \n> > Why are these related? Because it looks impossible for us to change the\n> > default for this option from within Ironic, because the option is\n> > registered when EventletExecutor is instantaited (rather than loaded).\n> > \n> > https://github.com/openstack/oslo.messaging/blob/master/oslo/messaging/_executors/impl_eventlet.py#L76\n> \n> It may have been possible for Ironic to set its own default before\n> oslo.messaging, but it wouldn\'t have been recommended because there\'s no\n> explicit API for doing so.\n> \n> With oslo.messaging, we have a set_transport_defaults() which shows how\n> we\'d approach adding this capability.\n> \n> The question comes down to whether this really is a situation where we\n> need per-application defaults or just that the current defaults are\n> screwed up. If the latter, I\'d much rather just change the defaults.\n\nHistory is always useful :)\n\nSoren added the threadpool with a default size of 1024:\n\n  https://code.launchpad.net/~soren/nova/rpc-threadpool/+merge/49896\n\nJohannes changed it back to 64:\n\n  https://review.openstack.org/6792\n\nMark.\n\n\n\n','<1398234359.21631.71.camel@sorcha>',NULL),('<1398347023.5459.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 13:43:44',0,'2014-04-24 13:43:44',NULL,'[openstack-dev] [Climate] nominating Pablo Andres Fuente for\n the Climate core reviewers team','Thanks, it\'s an honor! \n\nOn Thu, 2014-04-24 at 13:20 +0000, Sanchez, Cristian A wrote:\n> Congratulations Pablo!\n> \n> From: Sylvain Bauza <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>>\n> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n> Date: jueves, 24 de abril de 2014 10:16\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n> Subject: Re: [openstack-dev] [Climate] nominating Pablo Andres Fuente for the Climate core reviewers team\n> \n> Welcome Pablo !\n> \n> \n> 2014-04-24 15:06 GMT+02:00 Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>:\n> Well, as 3/4 core team members are okay with it, I\'ll do this)\n> \n> \n> On Thu, Apr 24, 2014 at 2:14 PM, Sylvain Bauza <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>> wrote:\n> http://russellbryant.net/openstack-stats/climate-reviewers-90.txt\n> \n> As per the stats, +1 to this.\n> \n> \n> 2014-04-24 12:10 GMT+02:00 Dina Belova <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>:\n> I propose to add Pablo Andreas Fuente (pafuent on the IRC) to Climate core team.\n> \n> He\'s Python contributor from Intel, and he took great part in Climate development including  design suggestions and great ideas. He has been quite active during the Icehouse and given his skills, interest and background I suppose it\'ll be great to add him to the team.\n> \n> \n> Best regards,\n> \n> Dina Belova\n> \n> Software Engineer\n> \n> Mirantis Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> --\n> \n> Best regards,\n> \n> Dina Belova\n> \n> Software Engineer\n> \n> Mirantis Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CF7E95D9.D572%cristian.a.sanchez@intel.com>',NULL),('<1398351786-sup-2594@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 08:53:40',-25200,'2014-04-24 15:53:40',NULL,'[openstack-dev] [Heat] Design summit preparation - Next steps\n	for Heat Software Orchestration','Excerpts from Thomas Spatzier\'s message of 2014-04-22 09:42:14 -0700:\n> \n> Hi all,\n> \n> following up on Zane\'s request from end of last week, I wanted to kick off\n> some discussion on the ML around a design summit session proposal titled \"\n> Next steps for Heat Software Orchestration\". I guess there will be things\n> that can be sorted out this way and others that can be refined so we can\n> have a productive session in Atlanta. I am basically copying the complete\n> contents of the session proposal below so we can iterate on various points.\n> If it turns out that we need to split off threads, we can do that at a\n> later point.\n> \n> The session proposal itself is here:\n> http://summit.openstack.org/cfp/details/306\n> \n> And here are the details:\n> \n> With the Icehouse release, Heat includes implementation for software\n> orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean\n> separation of any kind of software configuration from compute instances and\n> thus enables a great new set of features. The implementation for software\n> orchestration in Icehouse has probably been the major chunk of work to\n> achieve a first end-to-end flow for software configuration thru scripts,\n> Chef or Puppet, but there is more work to be done to enable Heat for more\n> software orchestration use cases beyond the current support.\n> Below are a couple of use cases, and more importantly, thoughts on design\n> options of how those use cases can be addressed.\n> \n> #1 Enable software components for full lifecycle:\n> With the current design, \"software components\" defined thru SoftwareConfig\n> resources allow for only one config (e.g. one script) to be specified.\n> Typically, however, a software component has a lifecycle that is hard to\n> express in a single script. For example, software must be installed\n> (created), there should be support for suspend/resume handling, and it\n> should be possible to allow for deletion-logic. This is also in line with\n> the general Heat resource lifecycle.\n> By means of the optional \'actions\' property of SoftwareConfig it is\n> possible today to specify at which lifecycle action of a SoftwareDeployment\n> resource the single config hook shall be executed at runtime. However, for\n> modeling complete handling of a software component, this would require a\n> number of separate SoftwareConfig and SoftwareDeployment resources to be\n> defined which makes a template more verbose than it would have to be.\n> As an optimization, SoftwareConfig could allow for providing several hooks\n> to address all default lifecycle operations that would then be triggered\n> thru the respective lifecycle actions of a SoftwareDeployment resource.\n> Resulting SoftwareConfig definitions could then look like the one outlined\n> below. I think this would fit nicely into the overall Heat resource model\n> for actions beyond stack-create (suspend, resume, delete). Furthermore,\n> this will also enable a closer alignment and straight-forward mapping to\n> the TOSCA Simple Profile YAML work done at OASIS and the heat-translator\n> StackForge project.\n> \n> So in a short, stripped-down version, SoftwareConfigs could look like\n> \n> my_sw_config:\n>   type: OS::Heat::SoftwareConfig\n>   properties:\n>     create_config: # the hook for software install\n>     suspend_config: # hook for suspend action\n>     resume_config: # hook for resume action\n>     delete_config: # hook for delete action\n>\n\nFirst off, modeling more actions is definitely on the near-term need\nlist for TripleO. We need to model rebuild and replace as an action too,\nso that we can evacuate/migrate work loads off of compute nodes.\n\nI think you can prototype action handling already with StructuredConfig,\nwhich allows you to define your own structure underneath config:.\nSo you\'d just simply do this:\n\nmy_sw_config:\n  type: OS::Heat::StructuredConfig\n  properties:\n    config:\n      create_config: |\n        #!/bin/bash\n        execute_stuff\n      delete_config: |\n        #!/bin/bash\n        execute_delete_stuff\n\nThen your in-instance tools would simply write these as executables and\nrun them when the action dictates. Suspend and resume aren\'t currently\nexposed, but I think that would be a fairly trivial patch to enable.\n\nNote that IMO we should _not_ encourage users to embed executables in\ntemplates. In addition to muddying the waters between orchestration\nand configuration management, it is also a very poor model for long\nterm source code control. You lose things like renames and per-file\ncommit history. I think users will be much better served by other tools\nbundling software together with a template, and I\'ve always figured that\nsomething like Murano or Solum would do that. So that you\'d instead have\na template like this:\n\n\nmy_sw_config:\n  type: OS::Heat::StructuredConfig\n  properties:\n    config:\n      create_config: {get_file: create_hook.sh}\n      delete_config: {get_file: delete_hook.sh}\n\nAnd if you\'re image-based, then you\'d instead just bundle the image\ncreation definition and not even need to include instructions on code\ninjection in your template.\n\n> When such a SoftwareConfig gets associated to a server via\n> SoftwareDeployment, the SoftwareDeployment resource lifecycle\n> implementation could trigger the respective hooks defined in SoftwareConfig\n> (if a hook is not defined, a no-op is performed). This way, all config\n> related to one piece of software is nicely defined in one place.\n> \n\nI don\'t believe \"nicely defined in one place\" is the right way to say\nthis. I would call it an unmanageable chunk of yaml.\n\nOne point, there is no \"no-op\". Heat\'s software config has an interface,\nand in-instance tools do the work.  I want to make sure we always stay\ntrue to that. I don\'t want Heat to assume anything about what happens\ninside instances. Heat exposes configs, and optionally waits for a\nsignal. Nothing more.\n\n> \n> #2 Enable add-hoc actions on software components:\n> Apart from basic resource lifecycle hooks, it would be desirable to allow\n> for invocation of add-hoc actions on software. Examples would be the ad-hoc\n> creation of DB backups, application of patches, or creation of users for an\n> application. Such hooks (implemented as scripts, Chef recipes or Puppet\n> facts) could be defined in the same way as basic lifecycle hooks. They\n> could be triggered by doing property updates on the respective\n> SoftwareDeployment resources (just a thought and to be discussed during\n> design sessions).\n> I think this item could help bridging over to some discussions raised by\n> the Murano team recently (my interpretation: being able to trigger actions\n> from workflows). It would add a small feature on top of the current\n> software orchestration in Heat and keep definitions in one place. And it\n> would allow triggering by something or somebody else (e.g. a workflow)\n> probably using existing APIs.\n> \n\nI\'m a bit skeptical about anything to add to Heat that doesn\'t actually\nchange the end-goal as expressed by the user. What I mean is, backups\ncould certainly mean defining new volumes or swift containers and telling\nservers to put data in them, but it isn\'t clear that it doesn\'t also\njust mean copying all your data to a backup server already defined.\n\nThe distinction is that if we are careful to always defer to workflow\nwhen workflow is required, then both cases have very clear points where\nyou change the workflow (the part that copies the data) or where you\nchange the orchestration (the part that manages the resources). And in\nboth cases, you always trigger the workflow to start a backup, not the\norchestration.\n\nSo, I\'m interested to see where this goes, but I would like to make sure\nthat Heat stays out of the workflow business and instead continues to\nprovide clear integration points for workflow.\n\n> \n> #3 address known limitations of Heat software orchestration\n> As of today, there already are a couple of know limitations or points where\n> we have seen the need for additional discussion and design work. Below is a\n> collection of such issues.\n> Maybe some are already being worked on; others need more discussion.\n> \n> #3.1 software deployment should run just once:\n> A bug has been raised because with today\'s implementation it can happen\n> that SoftwareDeployments get executed multiple times. There has been some\n> discussion around this issue but no final conclusion. An average user will\n> however assume that his automation gets run only or exactly once. When\n> using existing scripts, it would be an additional burden to require\n> rewrites to cope with multiple invocations. Therefore, we should have a\n> generic solution to the problem so that users do not have to deal with this\n> complex problem.\n> \n\nThis is entirely solvable by in-instance tools. Heat doesn\'t need to do\nanything to support this. And if we spend time on it, we\'ll just get in\nthe way half the time. I mean, do we really need an API to avoid flag\nfiles?\n\n[ -e /var/lib/mystuff/already.ran ] && exit 0\n# code here\ntouch /var/lib/mystuff/already.ran\n\nFor more sophisticated idempotency, I suggest using one of the more\nsophisticated tools, such as puppet, chef, salt, cfengine.. etc.\n\nHowever, If Heat allows a user to say \"run this once\" we have now\ntaken responsibility for lifecycle management and we have to ask\n\"once per what?\". Once per filesystem lifecycle? Once per instance ID\nlifecycle? Once per whole stack lifecycle?\n\n> #3.2 dependency on heat-cfn-api:\n> Some parts of current signaling still depend on the heat-cfn-api. While\n> work seems underway to completely move to Heat native signaling, some\n> cleanup to make sure this is used throughout the code.\n> \n\nAFAIK this is done.\n\n> #3.3 connectivity of instances to heat engine API:\n> The current metadata and signaling framework has certain dependencies on\n> connectivity from VMs to the Heat engine API. With some network setups, and\n> in some customer environments we hit limitations of access from VMs to the\n> management server. What can be done to enable additional network setups?\n> \n\nI think our friends in Marconi, Sahara and Trove will be interested in\nthis discussion. I have some ideas, but no time to drive them, and that\nis a bit out of scope for this email.\n\n> #3.4 number of created keystone users for deployments:\n> It has been pointed out that a large number of keystone users get created\n> for deployment and concerns have been raised that this could be a problem\n> for large deployments.\n>\n\nKeystone doesn\'t currently have a way to down-scope a token. So if you\nwant to limit an instance to queries for a single resource in a template,\nyou currently need a user. I think the answer may be OAUTH, but frankly,\nthis just means lots of OAUTH tokens instead of lots of users. I\'m not\nsure that actually buys us any performance.\n\n> #3.5 support of server groups:\n> How can a clean model look like where software configs get deployed on\n> server groups instead of single servers. What is the recommended modeling\n> and semantics?\n> \n\nMy thinking on this is that we need to make sure autoscaling groups are\nresource groups, and that we can individually address the members of the\ngroup, as well as the group as a whole.\n\n> #3.6 handling of stack updates for software config:\n> Stack updates are not cleanly supported with the initial software\n> orchestration implementation. #1 above could address this issue, but do we\n> have to do something in addition?\n> \n\nSorry I\'m not sure I follow. Updates work fine today. What isn\'t clean\nabout them?\n\n> #3.7 stack-abandon and stack-adopt for software-config:\n> Issues have been found for stack-abandon and stack-adopt with software\n> configs that need to be addressed. Can this be handled by additional hooks\n> as lined out under #1?\n> \n\nAs defined, abandon and adopt are supposed to be \"hands-off\" operations.\nThey\'re for mucking with Heat\'s internal model when it is inconsistent\nwith reality. So I\'m not sure we want to add _anything_ to the template\nlanguage that acknowledges they even exist, or they\'ll be denied their\nsuper powers that allow them to operate in the shadows.\n\n\n','<OF1BBC757F.B8A5636D-ONC1257CC2.0058B4CD-C1257CC2.005BC22B@de.ibm.com>',NULL),('<1398354237.7363.4.camel@cranky>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-24 11:43:57',-14400,'2014-04-24 15:43:57',NULL,'[Openstack] br-tun and br-int bridges in Neutron OVS','On Thu, 2014-04-24 at 11:19 -0400, HS wrote:\n> Hi,\n> \n> When OVS plugin is used with GRE option in Neutron, I see that each\n> compute node has br-tun and br-int bridges created.\n> \n> I\'m trying to understand why we need the additional br-tun bridge\n> here.  Can\'t we create tunneling ports in br-int bridge, and have\n> br-int relay traffic between VM ports and tunneling ports directly?\n> Why do we have to introduce another br-tun bridge in between?\n\nIt has to do with a OVS limitation in applying iptables rules directly\non VIF ports.\n\nSee Darragh\'s article here:\n\nhttp://techbackground.blogspot.com/2013/05/debugging-quantum-dhcp-and-open-vswitch.html\n\nand the Limitations section at the end of this document:\n\nhttp://openvswitch.org/openstack/documentation/\n\nSpecifically:\n\nOVS is not compatible with iptables + ebtables rules that are applied\ndirectly on VIF ports.  Thus, the existing implementations of Nova\nsecurity groups and spoof-prevention aren?t compatible.\n\nBest,\n-jay\n\n\n\n\n','<CAAJNysJcTVynJL3+M88O_KG4Pv6kQo9Hkoj0hgTcwyvLXEn69w@mail.gmail.com>',NULL),('<1398357686.64412662@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-04-24 11:41:26',-18000,'2014-04-24 16:41:26',NULL,'[openstack-community] OpenStack Speaking Opportunities Available at\n	Industry Events','\nThese excellent vendor-neutral OpenStack speaking opportunities are available.  Please contact me at kathyc at openstack.org if interested.  The SDN Conference in June is especially pressing.  Thank you.\n\n[http://www.whitehallmedia.co.uk/sdn/] Software Defined Networking, June 17, London.  There are 1-2 sessions available.  This is the 2nd annual conference. Martin Gerhard Loschwitz spoke at the inaugural event in Dec. 2013. See the event summary video on the home page for an interview with Martin and a visual of the audience size. The intended attendees are SDN, OpenFlow and network virtualization decision makers and influencers.  Session suggestions: share insights on the pressing issues in SDN, or better yet ? how you are deploying the technology yourself.\n[http://softwaredefined-enterprise.com/] Software Defined Enterprise World Forum, Sept 10-11, London.  Up to 3 sessions are available for OpenStack topics.  The audience will be 350+ heads of IT, CIO, Data Centre managers and engineers from enterprise companies and Telcos in the UK, Europe the US. From decision makers to those involved with the nitty gritty details of SDx.  Up to 3 sessions are available for OpenStack topics. They are especially looking for interactive sessions and offer these formats:\nhands-on workshops\nfireside chats\nQ&A\ninnovation jams\nExample topics:\n \nGetting to grips with SDN in the enterprise: Where in the SDN journey is your organisation?\nWeighing up the benefits of Software Defined Networks: Reducing CAPEX and OPEX through SDN\nWhat are the requirements to enable Software Defined Networks?\nData Centre Architectures of the future: Moving towards new models\n[https://www.usenix.org/conference/lisa14] USENIX LISA, Seattle, Nov 9-14 (week after Paris Summit).  Audience is 1,100 Large Installation System Admins.  A daytime breakout or evening BoF session is available for a sysadmin or operator responsible for a medium-large OpenStack production cloud in an Enterprise.  This was a fantastic event in 2013; OpenStack is increasing participation this year.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140424/6a66cc54/attachment.html>\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1398376094-sup-4066@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 16:29:56',-25200,'2014-04-24 23:29:56',NULL,'[openstack-dev] [Heat][Summit] Input wanted - real world heat\n	spec','Excerpts from Zane Bitter\'s message of 2014-04-24 14:23:38 -0700:\n> On 23/04/14 20:45, Robert Collins wrote:\n> > Hi, we\'ve got this summit session planned -\n> > http://summit.openstack.org/cfp/details/428 which is really about\n> > https://etherpad.openstack.org/p/heat-workflow-vs-convergence\n> >\n> > We\'d love feedback and questions - this is a significant amount of\n> > work, but work I (and many others based on responses so far) believe\n> > it is needed to really take Heat to users and ops teams.\n> >\n> > Right now we\'re looking for both high and low level design and input.\n> >\n> > If you\'re an operator/user/developer of/with/around heat - please take\n> > a couple of minutes to look - feedback inline in the etherpad, or here\n> > on the list - whatever suits you.\n> >\n> > The basic idea is:\n> >   - no changes needed to the heat template language etc\n> \n> +1 for this part, definitely :)\n> \n> >   - take a holistic view and fix the system\'s emergent properties by\n> > using a different baseline architecture within it\n> >   - ???\n> >   - profit!\n> \n> Thanks for writing this up Rob. This is certainly a more ambitious scale \n> of application to deploy than we ever envisioned in the early days of \n> Heat ;) But I firmly believe that what is good for TripleO will be great \n> for the rest of our users too. All of the observed issues mentioned are \n> things we definitely want to address.\n> \n> I have a few questions about the specific architecture being proposed. \n> It\'s not clear to me what you mean by \"call-stack style\" in referring to \n> the current paradigm. Maybe you could elaborate on how the current style \n> and the \"convergence style\" differ.\n> \n> Specifically, I am not clear on whether \'convergence\' means:\n>   (a) Heat continues to respect the dependency graph but does not stop \n> after one traversal, instead repeatedly processing it until (and even \n> after) the stack is complete; or\n>   (b) Heat ignores the dependency graph and just throws everything \n> against the wall, repeating until it has all stuck.\n> \n\nI think (c). We still have the graph driving \"what to do next\" so that\nthe things are more likely to stick. Also we don\'t want to do 10,000\ninstance creations if the database they need isn\'t going to come\navailable.\n\nBut we decouple \"I need to do something\" from \"The user asked for\nsomething\" by allowing the convergence engine to act on notifications\nfrom the observer engine. In addition to allowing more automated actions,\nit should allow us to use finer grained locking because no individual\ntask will need to depend on the whole graph or stack. If an operator\ncomes along and changes templates or parameters, we can still complete\nour outdated action. Eventually convergence will arrive at a state which\nmatches the desired stack.\n\n> I also have doubts about the principle \"Users should only need to \n> intervene with a stack when there is no right action that Heat can take \n> to deliver the current template+parameters\". That sounds good in theory, \n> but in practice it\'s very hard to know when there is a right action Heat \n> can take and when there isn\'t. e.g. There are innumerable ways to create \n> a template that can _never_ actually converge, and I don\'t believe \n> there\'s a general way we can detect that, only the hard way: one error \n> type at a time, for every single resource type. Offering users a way to \n> control how and when that happens allows them to make the best decisions \n> for their particular circumstances - and hopefully a future WFaaS like \n> Mistral will make it easy to set up continuous monitoring for those who \n> require it. (Not incidentally, it also gives cloud operators an \n> opportunity to charge their users in proportion to their actual \n> requirements.)\n> \n\nThere are some obvious times where there _is_ a clear automated answer\nthat does not require me to defer to a user\'s special workflow. 503 or\n429 (I know, not ratified yet) status codes mean I should retry after\nmaybe backing off a bit. If I get an ERROR state on a nova VM, I should\nretry a few times before giving up.\n\nThe point isn\'t that we have all the answers, it is that there are\nplenty of places where where we do have good answers that will serve\nmost users well.\n\n> > This can be constrasted with many other existing attempts to design\n> > solutions which relied on keeping the basic internals of heat as-is\n> > and just tweaking things - an approach we don\'t believe will work -\n> > the issues arise from the current architecture, not the quality of the\n> > code (which is fine).\n> \n> Some of the ideas that have been proposed in the past:\n> \n> - Moving execution of operations on individual resources to a \n> distributed execution system using taskflow. (This should address the \n> scalability issue.)\n\nThis is a superset of that. The same work that was going to be required\nthere, will be required for this. We can\'t be loading the whole stack\njust to do a single operation on a single resource.\n\n> - Updating the stored template in real time during stack updates - this \n> is happening in Juno btw. (This will solve the problem of inability to \n> ever recover from an update failure. In theory, it would also make it \n> possible to interrupt a running update and make changes.)\n\nThis obsoletes that. We don\'t need to keep track if we adopt a convergence\nmodel. The template that the user has asked for, is the template we\nconverge on. The diff between that and reality dictates the changes we\nneed to make. Wherever we\'re at with the convergence step that was last\ntriggered can just be cancelled by the new one.\n\nDeletes are handled by comparing what we have versus what the template\nsays we should have. The observer engine would never let go of a nova\ninstance until it has both been removed by a template update, _AND_\nit has actually gone away. So there\'s no need to keep the old template\naround, just the old record of what we are responsible for.\n\n> - Implementing a \'stack converge\' operation that the user can trigger to \n> compare the actual state of the stack with the model and bring it back \n> into spec.\n> \n\nThis command would simply kick off a refresh of the convergence engine.\n\n> It would be interesting to see some analysis on exactly how these \n> existing attempts fall down in trying to fulfil the goals, as well as \n> the specific points at which the proposed implementation differs.\n>\n\nThe massively coarse grained lock is a huge problem on update. Consider\na situation where 10,000 servers are managed via rolling updates in a\nsingle stack. 5,000 are doing \"roleA\" and 5,000 are doing \"roleB\". Say I\nupdate the image for roleA, and that will take 3 hours before it rolls\nthe whole thing out. I now have a 3 hour window where I cannot change\n_ANYTHING_ in the parameters for the servers doing roleB.\n\nAlso by loading the whole stack we\'ve allowed resources to bleed into\nother resource. Currently to read Metadata for a single item that\nentails _a lot_ of queries to the database because we end up having to\nload the entire stack. We can\'t continue that as stacks grow in size.\n\n> Depending on the answers to the above questions, this proposal could be \n> anything between a modest reworking of those existing ideas and a \n> complete re-imagining of the entire concept of Heat. I\'d very much like \n> to find out where along that spectrum it lies :)\n>\n\nI think the concept stays the same. Users define their end goal, and we\npush toward it. The states and actions even stay largely the same. This is\nmerely a change in the way Heat itself operates to hopefully be more\nscalable and more robust.\n\n> BTW, it appears that the schedule you\'re suggesting involves assigning a \n> bunch of people unfamiliar with the current code base and having them \n> complete a ground-up rearchitecting of the whole engine, all within the \n> Juno development cycle (about 3.5 months). This is simply not consistent \n> with reality as I have observed it up to this point.\n> \n\nThat\'s life. We\'ll get what we can done and if it does not land for Juno,\nso be it. We can\'t get it done without starting somewhere. We\'d be quite\nenthused to have other Heat developers working on it, and I think the\nnewcomers we\'re bringing on would also be able to make a positive impact\nin other parts of Heat as they come up to speed as well.\n\n\n','<535980DA.3060704@redhat.com>',NULL),('<1398379760.17349.3.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-24 17:49:20',-18000,'2014-04-24 22:49:20',NULL,'[openstack-dev] [cinder] proposal of definitions/processes for\n cinder-spec','On Thu, 2014-04-24 at 15:11 -0700, Walter A. Boring IV wrote:\n> On 04/23/2014 05:09 PM, Jay S. Bryant wrote:\n> > All,\n> >\n> > I have gotten questions from our driver developers asking for details\n> > regarding the move to using cinder-specs for proposing Blueprints.  I\n> > brought this topic up in today\'s Cinder Weekly Meeting, but the meeting\n> > was lightly attended so we decided to move the discussion here.\n> >\n> > I am going to put this note in the form of \'question\' and proposed\n> > answer based on the brief discussion we had today.  Note that the\n> > answers here are based on the assumption that we want to keep Cinder\'s\n> > use of \'specs\' as close to Nova\'s as possible.  I used the following\n> > mailing list thread as a starting point for some of these answers:\n> > http://lists.openstack.org/pipermail/openstack-dev/2014-April/032796.html\n> >\n> > Q: When is a spec approved?\n> > A:  When it receives a +2 from the PTL and at least one other Core\n> > reviewer.\n> >\n> > Q: How long are specs valid for?\n> > A: For the duration of the release cycle.  Any specs that are not\n> > approved during that period of type will need to be resubmitted for the\n> > subsequent release.\n> >\n> > Q: What will the spec template look like?\n> > A: This is one of the points I would like to discuss.  The Nova template\n> > currently looks like this:\n> > https://github.com/openstack/nova-specs/blob/master/specs/template.rst\n> > Do we want to follow the same template.  In the interest of staying in\n> > sync with Nova\'s implementation I would say yes, but does this meet our\n> > needs?  Are there other/different fields we want to consider to help for\n> > instances where the Blueprint is for a new driver or change to a driver?\n> > I think we might need, for instance, a \'Drivers Impacted\' field.\n> I think for starters, we should use the same template until we find\n> it doesn\'t fit our needs.   I just filed my first nova-spec bp\n> and rather liked the template and think it would be nice to have this\n> for Cinder....  cinder-spec.\n\nGood to know Walter.  I haven\'t been through the process yet.  Glad to\nknow you felt good about it.  That is helpful to know\n\n> \n> \n> >\n> > Q: Will driver developers have to use the same template for functions in\n> > their drivers?\n> > A: Also a point I would like to discuss.  Developers had asked if a more\n> > limited template would be used for changes going into the developer\'s\n> > driver.  At first I thought maybe a different template for Blueprints\n> > against a driver might be appropriate, but after looking more closely at\n> > Nova\'s template perhaps that is not necessary.  I would lean towards\n> > keeping one template, but maybe not requiring all fields depending on\n> > what our final template ends up looking like.\n> for now I vote for using the same template.\n\nThe more I think about it, I agree.\n\n> >\n> > Q: Where do specs for python-cinderclient go?\n> > A: Looks like Nova has added a python-novaclient directory.  I don\'t\n> > think we would need a separate python-cinderclient-specs repository but\n> > don\'t have a strong opinion on this point.\n> >\n> > I am sure this is not an exhaustive list of questions/answers at this\n> > point in time but I wanted to start the discussion so we could help move\n> > this process forward.  I look forward to your feedback.\n> >\n> > -Jay Bryant\n> > jsbryant at electronicjungle.net\n> > Freenode:  jungleboyj\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > .\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53598C06.7040502@hp.com>',NULL),('<1398390752-sup-7110@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-24 18:53:43',-25200,'2014-04-25 01:53:43',NULL,'[Openstack-operators] [Openstack] [Heat] Template with dynamic\n	instance count?','Not sure where \"count\" and \"resource_id\" came from.\n\nYou want one of these:\n\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::ResourceGroup\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::InstanceGroup\nhttp://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::AutoScaling::AutoScalingGroup\n\nExcerpts from Adam Lawson\'s message of 2014-04-24 17:03:38 -0700:\n> Does Heat support HOT templates where the user can enter the number of\n> instances to launch with a specific configuration? I would think so but\n> besides not finding anything other than count: <val>, and the fact that the\n> resource_id parameter needs to be unique seems to suggest this approach\n> isn\'t how to go about it.\n> \n> Thoughts?\n> .\n> \n> *Adam Lawson*\n> AQORN, Inc.\n> 427 North Tatnall Street\n> Ste. 58461\n> Wilmington, Delaware 19801-2230\n> Toll-free: (844) 4-AQORN-NOW\n> Direct: +1 (302) 268-6914\n\n\n','<CAJfWK4_o+uwOiS7=EobLjfWoFwVAjr-GoRKK4n4y8pT+kPEUtA@mail.gmail.com>',NULL),('<1398403388.6188577.1353516999954.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 11:56:39',-18000,'2012-11-21 16:56:39',NULL,'[openstack-dev] [nova] versioning scheme for\n	consumable	libraries','\n\n> > It isn\'t an API in the sense that the library would be used to\n> > communicate with nova. It would be something nova uses, like\n> > anyjson, gevent, or libvirt.\n> \n> My understanding of option 5 is that the library would be use by\n> ceilometer to access Nova, not the other way around ?\n\nWell there would be at least two different usages I think:\n\n1. nova-compute uses it \'internally\' in the same way as it currently\n   uses the hypervisor driver, say to extract diagnostics for the\n   os-server-diagnostics API extension.\n\n2. ceilo-compute-agent uses it \'externally\' to get visibility to\n   hypervisor stats, in sense of option #5.\n\nCheers,\nEoghan\n\n\n','<50AD035C.3020902@openstack.org>',NULL),('<1398441671.6608.5.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 12:01:11',-14400,'2014-04-25 16:01:11',NULL,'[openstack-dev] [Neutron] Flavor(?) Framework','On Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote:\n> Hi,\n> \n> I have a same question from Mark. Why is \"flavor\" not desired?\n> My first vote is \"flavor\" first, and then \"type\".\n\nSome reasons:\n\nFirst, flavor, in English, can and often is spelled differently\ndepending on where you live in the world (flavor vs. flavour).\n\nSecond, type is the appropriate term for what this is describing, and\ndoesn\'t have connotations of taste, which flavor does.\n\nI could also mention that the term \"flavor\" is a vestige of the\nRackspace Cloud API and, IMO, should be killed off in place of the more\ncommon and better understood \"instance type\" which is used by the EC2\nAPI.\n\n> There is similar cases in other OpenStack projects.\n> Nova uses \"flavor\" and Cinder uses \"(volume) type\" for similar cases.\n> Both cases are similar to our use cases and I think it is better to\n> use\n> either of them to avoid more confusion from naming for usesr and\n> operators.\n> \n> Cinder volume_type detail is available at [1]. In Cinder volume_type,\n> we can define multiple \"volume_type\" for one driver. \n> (more precisely, \"volume_type\" is associated to one \"backend\n> defintion\"\n> and we can define multiple \"backend definition\" for one backend\n> driver\").\n> \n> In addition, I prefer to managing flavor/type through API and\n> decoupling\n> flavor/type definition from provider definitions in configuration\n> files\n> as Cinder and Nova do.\n\nYes, I don\'t believe there\'s any disagreement on that particular point.\nThis effort is all about trying to provide a more comfortable and\nreasonable way for classification of these advanced services to be\ncontrolled by the user.\n\nBest,\n-jay\n\n> [1]\n> http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html\n> \n> Thanks,\n> Akihiro\n> \n> (2014/04/24 0:05), Eugene Nikanorov wrote:\n> \n> > Hi neutrons, \n> > \n> > \n> > A quick question of the ^^^\n> > I heard from many of you that a term \'flavor\' is undesirable, but so\n> > far there were no suggestions for the notion that we are going to\n> > introduce.\n> > So please, suggest you name for the resource.\n> > Names that I\'ve been thinking of:\n> >  - Capability group\n> >  - Service Offering\n> > \n> > \n> > Thoughts?\n> > \n> > \n> > Thanks,\n> > Eugene.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<36528E0B47035D4C90C91D29DA3B973DF24E38@BPXM02GP.gisp.nec.co.jp>',NULL),('<1398446739.3743.6.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-25 17:25:41',0,'2014-04-25 17:25:41',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Clint,\n	Did you have the chance to see my email?\nPablo.\n\nOn Mon, 2014-04-21 at 13:25 +0000, Fuente, Pablo A wrote:\n> Hi,\n> \n> You are right regarding grenade, but there is a subtle difference with\n> the interoperability matrix.\n> Meanwhile grenade does the upgrade and ensures it is working,  the\n> matrix checks that different components versions work well (or not)\n> together, hoping that this information helps in the upgrade decisions\n> (for example, upgrades orders). \n> In other words, Grenade moves the entire ?cloud? from one version to\n> another (all the components in the same version) and the matrix tests an\n> specific component version against the rest of the cloud in another\n> version.\n> Actually, I am considering to build this matrix without performing any\n> upgrade.\n> \n> Then, do you think this matrix could be helpful?\n> \n> Thank you very much for your answer!\n> Regards,\n> Pablo\n>  \n> On Thu, 2014-04-17 at 11:27 -0700, Clint Byrum wrote:\n> > Excerpts from Fuente, Pablo A\'s message of 2014-04-16 14:00:47 -0700:\n> > > Hi guys,\n> > > \n> > > I would like to open a discussion related to OpenStack upgrades ( I mean\n> > > moving from one version to another, for example Havana to Icehouse).\n> > > \n> > > As you probably know, this is a big issue, since there is no silver\n> > > bullet to do it. For that reason, I am thinking  in an option to provide\n> > > more input prior to do an upgrade.\n> > > \n> > > The idea is to generate an interoperability matrix, where devops can see\n> > > if an specific commit works with all the available OpenStack versions,\n> > > distinguishing among the different components. For example, you could\n> > > see if  the Nova X commit is or not backward compatible with the\n> > > Grizzly/Havana/Icehouse versions of Keystone/Neutron/Cinder/...\n> > > \n> > > Do you think this matrix would be useful in the upgrade tasks? \n> > > \n> > \n> > The gate currently has \"grenade\", which attempts to upgrade a working\n> > stable release to the each commit. If this does not pass, it does not\n> > merge.\n> > \n> > https://wiki.openstack.org/wiki/Grenade\n> > \n> > So this interoperability matrix is actually already maintained, as _every_\n> > commit should be able to upgrade from the previous stable release.\n> > \n> > Failures when attempting to do so are bugs in two things: the thing that\n> > breaks on upgrade, and grenade.\n> > \n> > _______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<1398086735.13315.0.camel@localhost>',NULL),('<1398447443-sup-2441@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 10:44:49',-25200,'2014-04-25 17:44:49',NULL,'[openstack-dev] [Trove][Heat] Use cases required for Trove','Excerpts from Zane Bitter\'s message of 2014-04-25 10:05:31 -0700:\n> On 25/04/14 08:30, Denis Makogon wrote:\n> >   Hello Trove/Heat community.\n> >\n> > I\'d like to start thread related to required use cases (from Trove\n> > perspective). To support (completely) Heat in Trove, it neeeds to\n> > support required operations like:\n> >\n> >\n> >  1.\n> >\n> >     Resize operations:\n> >\n> >     - resize a volume (to bigger size);\n> \n> This is kind of messy, because it involves operations (i.e. association \n> with an instance) that are, in theory, expressed independently of the \n> Volume itself in the template. It should be do-able though.\n> \n> >     - consistent resize of instance flavor.\n> \n> Server resize is implemented already in Heat. I believe what is missing \n> is a hook to allow Trove to confirm (or not) the resize. Heat always \n> confirms at the moment.\n> \n> http://junodesignsummit.sched.org/event/d422b859492cd1dbcb9763c8b7245f23\n> \n\nRight, this is similar to the rebuild case that TripleO needs. I believe\nsoftware deployments has laid a nice framework down for this, and I\'m\nworking right now on a POC for rebuild that will quite easily translate\ninto resize as well.\n\n> >  2.\n> >\n> >     Migration operation (from host to host).\n> \n> It\'s not clear to me how this would fit into Heat\'s declarative model \n> (since it\'s an action, rather than a thing or a relationship between \n> things). Given that this is presumably an admin-type operation, maybe it \n> is OK for this to continue to be done with the Nova client.\n> \n\nAssuming you mean nova migration, which is an administrative action\nin Nova, I agree with Zane, except that I wouldn\'t say maybe, but\n\"most likely\".\n\nHowever, the statement is a bit vague, so you could mean _trove_ host\nto _trove_ host. As in, migrating a whole database and then a VIP to\nanother database.\n\nI think there is a role for Heat to play there, as you would change your\ndesired end-goal to have two servers, and even use Heat to communicate\nthe details how the migration path to the new one, and then change the\ngoal again to just have the new server, with the VIP moved.\n\n> >  3.\n> >\n> >     Security group/rules operations:\n> >\n> >         - add new rules to already existing group;\n> >\n> >         - swap existing rules to a new ones.\n> \n> This appears to be implemented already (for Neutron security groups), \n> though the implementation looks a bit suspect to me:\n> \n> https://github.com/openstack/heat/blob/master/heat/engine/resources/neutron/security_group.py#L237\n> \n> >  4.\n> >\n> >     Designate (DNSaaS) resource provisioning.\n> \n> +1! If someone wanted to write this we would be more than happy to see \n> it in /contrib right now, and moving to the main tree as soon as \n> Designate is accepted for incubation.\n> \n\nAgreed. DNS all the things.\n\n\n','<535A95DB.1040802@redhat.com>',NULL),('<1398447609.6608.14.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 13:40:09',-14400,'2014-04-25 17:40:09',NULL,'[openstack-dev] [Neutron] Flavor(?) Framework','On Fri, 2014-04-25 at 13:32 -0400, Mohammad Banikazemi wrote:\n> As I understand the proposed flavor framework, the intention is to\n> provide a mechanism for specifying different \"flavors\" of a given\n> service \"type\"  as they  are already defined. So using the term \"type\"\n> may be confusing. Here we want to specify possibly different set of\n> capabilities within a given defined service type.\n\nHi Mohammed,\n\nYes, the trouble in Neutron is the existing service type usage... I\nproposed to rename that to service family or service class in a previous\nemail, and use a type for each service class, so:\n\nload balancer type\nfirewall type\nVPN type\n\nI\'d also recommend simplifying the API and CLI by removing the\nimplementation-focused \"provider type\" stuff eventually, as well, since\na service type framework would essentially make that no longer needed --\nat least on the public API side of things.\n\nBest,\n-jay\n\n> Inactive hide details for Jay Pipes ---04/25/2014 12:09:43 PM---On\n> Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote: > Hi,Jay Pipes\n> ---04/25/2014 12:09:43 PM---On Fri, 2014-04-25 at 13:41 +0000, Akihiro\n> Motoki wrote: > Hi,\n> \n> From: Jay Pipes <jaypipes at gmail.com>\n> To: openstack-dev at lists.openstack.org, \n> Date: 04/25/2014 12:09 PM\n> Subject: Re: [openstack-dev] [Neutron] Flavor(?) Framework\n> \n> \n> \n> ______________________________________________________________________\n> \n> \n> \n> On Fri, 2014-04-25 at 13:41 +0000, Akihiro Motoki wrote:\n> > Hi,\n> > \n> > I have a same question from Mark. Why is \"flavor\" not desired?\n> > My first vote is \"flavor\" first, and then \"type\".\n> \n> Some reasons:\n> \n> First, flavor, in English, can and often is spelled differently\n> depending on where you live in the world (flavor vs. flavour).\n> \n> Second, type is the appropriate term for what this is describing, and\n> doesn\'t have connotations of taste, which flavor does.\n> \n> I could also mention that the term \"flavor\" is a vestige of the\n> Rackspace Cloud API and, IMO, should be killed off in place of the\n> more\n> common and better understood \"instance type\" which is used by the EC2\n> API.\n> \n> > There is similar cases in other OpenStack projects.\n> > Nova uses \"flavor\" and Cinder uses \"(volume) type\" for similar\n> cases.\n> > Both cases are similar to our use cases and I think it is better to\n> > use\n> > either of them to avoid more confusion from naming for usesr and\n> > operators.\n> > \n> > Cinder volume_type detail is available at [1]. In Cinder\n> volume_type,\n> > we can define multiple \"volume_type\" for one driver. \n> > (more precisely, \"volume_type\" is associated to one \"backend\n> > defintion\"\n> > and we can define multiple \"backend definition\" for one backend\n> > driver\").\n> > \n> > In addition, I prefer to managing flavor/type through API and\n> > decoupling\n> > flavor/type definition from provider definitions in configuration\n> > files\n> > as Cinder and Nova do.\n> \n> Yes, I don\'t believe there\'s any disagreement on that particular\n> point.\n> This effort is all about trying to provide a more comfortable and\n> reasonable way for classification of these advanced services to be\n> controlled by the user.\n> \n> Best,\n> -jay\n> \n> > [1]\n> >\n> http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html\n> > \n> > Thanks,\n> > Akihiro\n> > \n> > (2014/04/24 0:05), Eugene Nikanorov wrote:\n> > \n> > > Hi neutrons, \n> > > \n> > > \n> > > A quick question of the ^^^\n> > > I heard from many of you that a term \'flavor\' is undesirable, but\n> so\n> > > far there were no suggestions for the notion that we are going to\n> > > introduce.\n> > > So please, suggest you name for the resource.\n> > > Names that I\'ve been thinking of:\n> > >  - Capability group\n> > >  - Service Offering\n> > > \n> > > \n> > > Thoughts?\n> > > \n> > > \n> > > Thanks,\n> > > Eugene.\n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OFC16ECEE1.8CA54B8B-ON85257CC5.005E5400-85257CC5.00605C96@us.ibm.com>',NULL),('<1398448195-sup-8887@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 11:08:32',-25200,'2014-04-25 18:08:32',NULL,'[openstack-dev] [TripleO] HAProxy and Keystone setup (in\n	Overcloud)','Excerpts from Jan Provazn?k\'s message of 2014-04-25 06:30:31 -0700:\n> Hello,\n> one of missing bits for running multiple control nodes in Overcloud is \n> setting up endpoints in Keystone to point to HAProxy which will listen \n> on a virtual IP and not-standard ports.\n> \n> HAProxy ports are defined in heat template, e.g.:\n> \n>      haproxy:\n>        nodes:\n>        - name: control1\n>          ip: 192.0.2.5\n>        - name: control2\n>          ip: 192.0.2.6\n>        services:\n>        - name: glance_api_cluster\n>          proxy_ip: 192.0.2.254 (=virtual ip)\n>          proxy_port: 9293\n>          port:9292\n> \n> \n> means that Glance\'s Keystone endpoint should be set to:\n> http://192.0.2.254:9293/\n> \n> ATM Keystone setup is done from devtest_overcloud.sh when Overcloud \n> stack creation successfully completes. I wonder what of the following \n> options how to set up endpoints in HA mode, is preferred by community?:\n> 1) leave it in post-stack-create phase and extend init-keystone script. \n> But then how to deal with list of not-standard ports (proxy_port in \n> example above):\n>    1a) consider these not-standard ports as static and just hardcode \n> them (similar to what we do with SSL ports already). But ports would be \n> hardcoded on 2 places (heat template and this script). If a user changes \n> them in heat template, he has to change them in init-keystone script too.\n>    2b) init-keystone script would fetch list of ports from heat stack \n> description (if it\'s possible?)\n> \n> Long-term plan seems to be rewrite Keystone setup into os-cloud-config:\n> https://blueprints.launchpad.net/tripleo/+spec/tripleo-keystone-cloud-config\n> So alternative to extending init-keystone script would be implement it \n> as part of the blueprint, anyway the concept of keeping Keystone setup \n> in post-stack-create phase remains.\n> \n\nWe may want to consider making use of Heat outputs for this.\n\nRather than assuming hard coding, create an output on the overcloud\ntemplate that is something like \'keystone_endpoint\'. It would look\nsomething like this:\n\nOutputs:\n  keystone_endpoint:\n    Fn::Join:\n      - \'\'\n      - - \"http://\"\n        - {Fn::GetAtt: [ haproxy_node, first_ip ]} # fn select and yada\n        - \":\"\n        - {Ref: KeystoneEndpointPort} # thats a parameter\n        - \"/v2.0\"\n\n\nThese are then made available via heatclient as stack.outputs in\n\'stack-show\'.\n\nThat way as we evolve new stacks that have different ways of controlling\nthe endpoints (LBaaS anybody?) we won\'t have to change os-cloud-config\nfor each one.\n\n> \n> 2) do Keystone setup from inside Overcloud:\n> Extend keystone element, steps done in init-keystone script would be \n> done in keystone\'s os-refresh-config script. This script would have to \n> be called only on one of nodes in cluster and only once (though we \n> already do similar check for other services - mysql/rabbitmq, so I don\'t \n> think this is a problem). Then this script can easily get list of \n> haproxy ports from heat metadata. This looks like more attractive option \n> to me - it eliminates an extra post-create config step.\n\nThings that can be done from outside the cloud, should be done from\noutside the cloud. This helps encourage the separation of concerns and\nalso makes it simpler to reason about which code is driving the cloud\nversus code that is creating the cloud.\n\n> \n> Related to Keystone setup is also the plan around keys/cert setup \n> described here:\n> http://lists.openstack.org/pipermail/openstack-dev/2014-March/031045.html\n> But I think this plan would remain same no matter which of the options \n> above would be used.\n> \n> \n> What do you think?\n> \n> Jan\n> \n\n\n','<535A6377.7080909@redhat.com>',NULL),('<1398460540.6608.50.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 17:15:40',-14400,'2014-04-25 21:15:40',NULL,'[openstack-dev] [nova] Proposal: remove the server groups feature','Hi Stackers,\n\nWhen recently digging in to the new server group v3 API extension\nintroduced in Icehouse, I was struck with a bit of cognitive dissonance\nthat I can\'t seem to shake. While I understand and support the idea\nbehind the feature (affinity and anti-affinity scheduling hints), I\ncan\'t help but feel the implementation is half-baked and results in a\nvery awkward user experience.\n\nThe use case here is very simple: \n\nAlice wants to launch an instance and make sure that the instance does\nnot land on a compute host that contains other instances of that type.\n\nThe current user experience is that the user creates a \"server group\"\nlike so:\n\nnova server-group-create $GROUP_NAME --policy=anti-affinity\n\nand then, when the user wishes to launch an instance and make sure it\ndoesn\'t land on a host with another of that instance type, the user does\nthe following:\n\nnova boot --group $GROUP_UUID ...\n\nThere are myriad problems with the above user experience and\nimplementation. Let me explain them.\n\n1. The user isn\'t creating a \"server group\" when they issue a nova\nserver-group-create call. They are creating a policy and calling it a\ngroup. Cognitive dissonance results from this mismatch.\n\n2. There\'s no way to add an existing server to this \"group\". What this\nmeans is that the user needs to effectively have pre-considered their\nenvironment and policy before ever launching a VM. To realize why this\nis a problem, consider the following:\n\n - User creates three VMs that consume high I/O utilization\n - User then wants to launch three more VMs of the same kind and make\nsure they don\'t end up on the same hosts as the others\n\nNo can do, since the first three VMs weren\'t started using a --group\nscheduler hint.\n\n3. There\'s no way to remove members from the group\n\n4. There\'s no way to manually add members to the server group\n\n5. The act of telling the scheduler to place instances near or away from\nsome other instances has been hidden behind the server group API, which\nmeans that users doing a nova help boot will see a --group option that\ndoesn\'t make much sense, as it doesn\'t describe the scheduling policy\nactivity.\n\nProposal\n--------\n\nI propose to scrap the server groups API entirely and replace it with a\nsimpler way to accomplish the same basic thing.\n\nCreate two new options to nova boot:\n\n --near-tag <TAG>\nand\n --not-near-tag <TAG>\n\nThe first would tell the scheduler to place the new VM near other VMs\nhaving a particular \"tag\". The latter would tell the scheduler to place\nthe new VM *not* near other VMs with a particular tag.\n\nWhat is a \"tag\"? Well, currently, since the Compute API doesn\'t have a\nconcept of a single string tag, the tag could be a key=value pair that\nwould be matched against the server extra properties.\n\nOnce a real user-controlled simple string tags system is added to the\nCompute API, a \"tag\" would be just that, a simple string that may be\nattached or detached from some object (in this case, a server object).\n\nHow does this solve all the issues highlighted above? In order, it\nsolves the issues like so:\n\n1. There\'s no need to have any \"server group\" object any more. Servers\nhave a set of tags (key/value pairs in v2/v3 API) that may be used to\nidentify a type of server. The activity of launching an instance would\nnow have options for the user to indicate their affinity preference,\nwhich removes the cognitive dissonance that happens due to the user\nneeding to know what a server group is (a policy, not a group).\n\n2. Since there is no more need to maintain a separate server group\nobject, if a user launched 3 instances and then wanted to make sure that\n3 new instances don\'t end up on the same hosts, all the user needs to do\nis tag the existing instances with a tag, and issue a call to:\n\n nova boot --not-near-tag $TAG ...\n\nand the affinity policy is applied properly.\n\n3. Removal of members of the \"server group\" is no longer an issue.\nSimply untag a server to remove it from the set of servers you wish to\nuse in applying some affinity policy\n\n4. Likewise, since there\'s no server group object, in order to relate an\nexisting server to another is to simply place a tag on the server.\n\n5. The act of applying affinity policies is now directly related to the\nact of launching instances, which is where it should be.\n\nI\'ll type up a real blueprint spec for this, but wanted to throw the\nidea out there, since it\'s something that struck me recently when I\ntried to explain the new server groups feature.\n\nThoughts and feedback welcome,\n-jay\n\n\n\n',NULL,NULL),('<1398464918.6608.68.camel@cranky>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-25 18:28:38',-14400,'2014-04-25 22:28:38',NULL,'[openstack-dev] [nova] Proposal: remove the server groups\n feature','On Fri, 2014-04-25 at 22:00 +0000, Day, Phil wrote:\n> Hi Jay,\n> \n> I\'m going to disagree with you on this one, because:\n\nNo worries, Phil, I expected some dissention and I completely appreciate\nyour feedback and perspective :)\n\n> i) This is a feature that was discussed in at least one if not two Design Summits and went through a long review period, it wasn\'t one of those changes that merged in 24 hours before people could take a good look at it.\n\nCompletely understood. That still doesn\'t mean we can\'t propose to get\nrid of it early instead of letting it sit around when an alternate\nimplementation would be better for the user of OpenStack.\n\n>   Whatever you feel about the implementation,  it is now in the API and we should assume that people have started coding against it.\n\nSure, maybe. AFAIK, it\'s only in the v2 API, though, not in the v3 API\n(sorry, I made a mistake about that in my original email). Is there a\nreason it wasn\'t added to the v3 API?\n\n>   I don\'t think it gives any credibility to Openstack as a platform if we yank features back out just after they\'ve landed.\n\nPerhaps not, though I think we have less credibility if we don\'t\nrecognize when a feature isn\'t implemented with users in mind and leave\nit in the code base to the detriment and confusion of users. We\nabsolutely must, IMO, as a community, be able to say \"this isn\'t right\"\nand have a path for changing or removing something.\n\nIf that path is deprecation vs outright removal, so be it, I\'d be cool\nwith that. I\'d just like to nip this anti-feature in the bud early so\nthat it doesn\'t become the next \"feature\" like file-injection to persist\nin Nova well after its time has come and passed.\n\n> ii) Sever Group - It\'s a way of defining a group of servers, and the initial thing (only thing right now) you can define for such a group is the affinity or anti-affinity for scheduling.\n\nWe already had ways of defining groups of servers. This new \"feature\"\ndoesn\'t actually define a group of servers. It defines a policy, which\nis not particularly useful, as it\'s something that is better specified\nat the time of launching.\n\n>   Maybe in time we\'ll add other group properties or operations - like \"delete all the servers in a group\" (I know some QA folks that would love to have that feature).\n\nWe already have the ability to define a group of servers using key=value\ntags. Deleting all servers in a group is a three-line bash script that\nloops over the results of a nova list command and calls nova delete.\nTrust me, I\'ve done group deletes in this way many times.\n\n>   I don\'t see why it shouldn\'t be possible to have a server group that doesn\'t have a scheduling policy associated to it.\n\nI don\'t think the grouping of servers should have *anything* to do with\nscheduling :) That\'s the point of my proposal. Servers can and should be\ngrouped using simple tags or key=value pair tags.\n\nThe grouping of servers together doesn\'t have anything of substance to\ndo with scheduling policies.\n\n>    I don\'t see any  Cognitive dissonance here - I think your just assuming that the only reason for being able to group servers is for scheduling.\n\nAgain, I don\'t think scheduling and grouping of servers has anything to\ndo with each other, thus my proposal to remove the relationship between\ngroups of servers and scheduling policies, which is what the existing\nserver group API and implementation does.\n\n> iii) If the issue is that you can\'t add or remove servers from a group, then why don\'t we add those operations to the API (you could add a server to a group providing doing so  doesn\'t break any policy that might be associated with the group). \n\nWe already have this ability today, thus my proposal to get rid of\nserver groups.\n\n>   Seems like a useful addition to me.\n\nIt\'s an addition that isn\'t needed, as we already have this today.\n\n> iv) Since the user created the group, and chose a name for it that is presumably meaningful, then I don\'t understand why you think \"--group XXX\" isn\'t going to be meaningful to that same user ?\n\nSee point above about removing the unnecessary relationship between\ngrouping of servers and scheduling policies.\n\n> So I think there are a bunch of API operations missing, but I don\'t see any advantage in throwing away what\'s now in place and  replacing it with a tag mechanism that basically says \"everything with this tag is in a sort of group\".\n\nWe already have the tag group mechanism in place, that\'s kind of what\nI\'ve been saying...\n\n> PS: Congrats on the TC election\n\nCheers, appreciated. Looking forward to healthy debates and buying you a\nfew beers at the summit :)\n\nbest,\n-jay\n\n> \n> > -----Original Message-----\n> > From: Jay Pipes [mailto:jaypipes at gmail.com]\n> > Sent: 25 April 2014 22:16\n> > To: OpenStack Development Mailing List\n> > Subject: [openstack-dev] [nova] Proposal: remove the server groups feature\n> > \n> > Hi Stackers,\n> > \n> > When recently digging in to the new server group v3 API extension\n> > introduced in Icehouse, I was struck with a bit of cognitive dissonance that I\n> > can\'t seem to shake. While I understand and support the idea behind the\n> > feature (affinity and anti-affinity scheduling hints), I can\'t help but feel the\n> > implementation is half-baked and results in a very awkward user experience.\n> > \n> > The use case here is very simple:\n> > \n> > Alice wants to launch an instance and make sure that the instance does not\n> > land on a compute host that contains other instances of that type.\n> > \n> > The current user experience is that the user creates a \"server group\"\n> > like so:\n> > \n> > nova server-group-create $GROUP_NAME --policy=anti-affinity\n> > \n> > and then, when the user wishes to launch an instance and make sure it\n> > doesn\'t land on a host with another of that instance type, the user does the\n> > following:\n> > \n> > nova boot --group $GROUP_UUID ...\n> > \n> > There are myriad problems with the above user experience and\n> > implementation. Let me explain them.\n> > \n> > 1. The user isn\'t creating a \"server group\" when they issue a nova server-\n> > group-create call. They are creating a policy and calling it a group. Cognitive\n> > dissonance results from this mismatch.\n> > \n> > 2. There\'s no way to add an existing server to this \"group\". What this means\n> > is that the user needs to effectively have pre-considered their environment\n> > and policy before ever launching a VM. To realize why this is a problem,\n> > consider the following:\n> > \n> >  - User creates three VMs that consume high I/O utilization\n> >  - User then wants to launch three more VMs of the same kind and make\n> > sure they don\'t end up on the same hosts as the others\n> > \n> > No can do, since the first three VMs weren\'t started using a --group\n> > scheduler hint.\n> > \n> > 3. There\'s no way to remove members from the group\n> > \n> > 4. There\'s no way to manually add members to the server group\n> > \n> > 5. The act of telling the scheduler to place instances near or away from some\n> > other instances has been hidden behind the server group API, which means\n> > that users doing a nova help boot will see a --group option that doesn\'t make\n> > much sense, as it doesn\'t describe the scheduling policy activity.\n> > \n> > Proposal\n> > --------\n> > \n> > I propose to scrap the server groups API entirely and replace it with a simpler\n> > way to accomplish the same basic thing.\n> > \n> > Create two new options to nova boot:\n> > \n> >  --near-tag <TAG>\n> > and\n> >  --not-near-tag <TAG>\n> > \n> > The first would tell the scheduler to place the new VM near other VMs\n> > having a particular \"tag\". The latter would tell the scheduler to place the new\n> > VM *not* near other VMs with a particular tag.\n> > \n> > What is a \"tag\"? Well, currently, since the Compute API doesn\'t have a\n> > concept of a single string tag, the tag could be a key=value pair that would be\n> > matched against the server extra properties.\n> > \n> > Once a real user-controlled simple string tags system is added to the\n> > Compute API, a \"tag\" would be just that, a simple string that may be attached\n> > or detached from some object (in this case, a server object).\n> > \n> > How does this solve all the issues highlighted above? In order, it solves the\n> > issues like so:\n> > \n> > 1. There\'s no need to have any \"server group\" object any more. Servers have\n> > a set of tags (key/value pairs in v2/v3 API) that may be used to identify a type\n> > of server. The activity of launching an instance would now have options for\n> > the user to indicate their affinity preference, which removes the cognitive\n> > dissonance that happens due to the user needing to know what a server\n> > group is (a policy, not a group).\n> > \n> > 2. Since there is no more need to maintain a separate server group object, if\n> > a user launched 3 instances and then wanted to make sure that\n> > 3 new instances don\'t end up on the same hosts, all the user needs to do is\n> > tag the existing instances with a tag, and issue a call to:\n> > \n> >  nova boot --not-near-tag $TAG ...\n> > \n> > and the affinity policy is applied properly.\n> > \n> > 3. Removal of members of the \"server group\" is no longer an issue.\n> > Simply untag a server to remove it from the set of servers you wish to use in\n> > applying some affinity policy\n> > \n> > 4. Likewise, since there\'s no server group object, in order to relate an existing\n> > server to another is to simply place a tag on the server.\n> > \n> > 5. The act of applying affinity policies is now directly related to the act of\n> > launching instances, which is where it should be.\n> > \n> > I\'ll type up a real blueprint spec for this, but wanted to throw the idea out\n> > there, since it\'s something that struck me recently when I tried to explain the\n> > new server groups feature.\n> > \n> > Thoughts and feedback welcome,\n> > -jay\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F007072EC4@G5W2737.americas.hpqcorp.net>',NULL),('<1398554442.17349.16.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-26 18:20:42',-18000,'2014-04-26 23:20:42',NULL,'[openstack-dev] [cinder][globalization] Need input on how to\n	proceed .','All,\n\nI am looking for feedback on how to complete implementation of i18n\nsupport for Cinder.  I need to open a new BluePrint for Juno as soon as\nthe cinder-specs process is available.  In the mean time I would like to\nstart working on this and need feedback on the scope I should undertake\nwith this.\n\nFirst, the majority of the code for i18n support went in with Icehouse.\nThere is just a small change that is needed to actually enable Lazy\nTranslation again.  I want to get this enabled as soon as possible to\nget plenty of runtime on the code for Icehouse.\n\nThe second change is to add an explicit export for \'_\' to all of our\nfiles to be consistent with other projects. [1]  This is also the safer\nway to implement i18n.  My plan is to integrate the change as part of\nthe i18n work.  Unfortunately this will touch many of the files in\nCinder.\n\nGiven that fact, this brings me to the item I need feedback upon.  It\nappears that Nova is moving forward with the plan to remove translation\nof debug messages as there was a recent patch submitted to enable a\ncheck for translated DEBUG messages.  Given that fact, would it be an\nappropriate time, while adding the explicit import of \'_\' to also remove\ntranslation of debug messages.  It is going to make the commit for\nenabling Lazy Translation much bigger, but it would also take out\nseveral work items that need to be addressed at once.  I am willing to\nundertake the effort if I have support for the changes.\n\nPlease let me know your thoughts.\n\nThanks!2]\nJay\n(jungleboyj on freenode)\n\n[1] https://bugs.launchpad.net/cinder/+bug/1306275\n\n\n\n',NULL,NULL),('<1398557044-sup-1878@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-26 17:05:41',-25200,'2014-04-27 00:05:41',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Just a friendly reminder to add yourself to this list if you are\ninterested in participating in the key signing in Atlanta:\n\nhttps://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n\nNow that we have more visibility about schedules, I think we should try\nto find a time slot. Does anybody have an idea already? If not I think\nwe should just pick a break time period and get it done.\n\nExcerpts from Thomas Goirand\'s message of 2014-03-29 23:32:55 -0700:\n> On 03/30/2014 10:00 AM, Mark Atwood wrote:\n> > Hi!\n> > \n> > Are there plans for a PGP keysigning party at the Juno Summit in\n> > Atlanta, similar to the one at the Icehouse summit in Hong Kong?\n> > \n> > Inspired by the URL at\n> > https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Icehouse_Summit\n> > I looked for \n> > https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> > to discover that that wiki page does not yet exist and I do not have\n> > permission to create it.\n> > \n> > ..m\n> \n> If there\'s none, then we should do one.\n> \n> One thing about last key signing party, is that I didn\'t really like the\n> photocopy method. IMO, it\'d be much much nicer to use a file, posted\n> somewhere, containing all participant fingerprints. To check for that\n> file validity, together, we check for its sha256 sum (someone say it out\n> loud, while everyone is checking for its own copy). And everyone,\n> individually, checks for its own PGP fingerprint inside the file. Then\n> we just need to validate entries in this file (with matching ID documents).\n> \n> Otherwise, there\'s the question of the trustability of the photocopy\n> machine and such... Not that I don\'t trust Jimmy (I do...)! :)\n> \n> Plus having a text file with all fingerprints in it is more convenient:\n> you can just cut/past the whole fingerprint and do gpg --recv-keys at\n> once (and not just the key ID, which is unsafe because prone to\n> brute-force). That file can be posted anywhere, provided that we check\n> for its sha256 sum.\n> \n> I would happily organize this, if someone can find a *quite* room with\n> decent network. Who can take care of the place and time?\n> \n> Of course, We will need need the fingerprints of every participant in\n> advance, so the wiki page would be useful as well. I therefore created\n> the wiki page:\n> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> \n> Please add yourself. We\'ll see if I can make it to Atlanta, and organize\n> something later on.\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n\n\n','<5337BA97.8070109@debian.org>',NULL),('<1398653447.2608.38.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 02:50:47',0,'2014-04-28 02:50:47',NULL,'[openstack-dev]  [Neutron][LBaaS] API and Object Model Direction','I\'m making a new thread continuing from\n\n[openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal\n\nI think this warrants its own thread since the discussion doesn\'t\npertain directly to Stephen\'s proposal.\n\nEugene,\nWhat I think what Stephen is trying to say is that in the previous IRC\nmeeting it was explicitly said that the object model would follow the\nAPI decision.  Meaning, an API that was decided on would then in turn\nhave its own object model.  Object model diagrams were also requested\nwith each API proposal.\n\nThis most recent meeting happened and a reversal happend.  Now you\'re\nsaying the current object model will just be changed somewhat and an API\nthat is decided on will have to work with that object model.  If that is\nthe case then 1) there was some wasted work by people, 2) this same\nthing can and probably will happen with the API wasting even more time.\n\nAlso, you made a comment basically implying that until people actually\ncontribute code, they\'re opinion doesn\'t matter.  That\'s a great way to\nalienate people and lose out on valuable insight from people who may\nhave a lot of experience.  Also, I think many of us newbies have\ncontributed in other ways than code.  Sure, there\'s no metric to measure\nthese contributions but they should count for something.  Anyway, that\ncomment is probably insight into what the reason is for this new\ndirection.\n\nIn the end, if people feel like their opinion doesn\'t matter and\nanything they do is just a waste a time, most people won\'t even bother.\nI will participate in the neutron-specs blueprints.  I actually do like\nthat it is a place to actually make decisions, though it is tough to\nactually get anything in a good format. \n\nI\'m not sure if all of this is a misunderstanding.  I just think it\nshould be known of our perception of what has taken place and what is\ntaking place.  If our perception is way off then I think the reality of\nthe situation should be made more clear.\n\nThanks,\nBrandon\n\n','<CAJfiwOSrUKKRn+vHxLOE2nwF0vOR4k1nMeHnRDBkMiLJF5PqRQ@mail.gmail.com>',NULL),('<1398656605.9371.9.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 13:43:25',36000,'2014-04-28 03:43:25',NULL,'[openstack-dev] [Keystone] keystoneclient and project-less v3\n tokens','On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:\n> Hello,\n> \n> I am trying to make sure that a user can\'t do anything useful with an \n> unscoped token, and got to the following code in \n> keystoneclient.middleware.auth_token:\n> \n>          if _token_is_v2(token_info) and not auth_ref.project_id:\n>              raise InvalidUserToken(\'Unable to determine tenancy.\')\n> \n> This check is performed on every request, and successfully forbids any \n> request authenticated by a project-less token.  But only for v2 tokens!\n> \n> In case service is using v3 of Keystone api, the request successfully \n> passes auth_token middleware filter, and it becomes the task of each \n> specific service to handle unscopedness of passed token.\n> \n> While Nova seem to be handling this well (basing on several tests I \n> made), I was able to fetch a list of available images from Glance using \n> a token of projectless user.\n> \n> Is this a desired behavior of keystoneclient?\n> Why do we check existence of project_id only for v2 tokens?\n> \n> Thanks,\n> Roman\n\nHmm, that is fairly old code. Submitted before v3 tokens were even on\nthe scene it looks like. \n\nAs an educated guess here i expect that it\'s because a v3 token can be\nscoped to multiple things. It can be scoped to a project, a domain or a\nservice - or not at all (which would be the same thing as scoping it to\nthe keystone service). \n\nThe more correct way to do this would be to enforce the need for a\nproject scope on the service that requires the project scope. Not all\nservices or all actions will need a project scope and there is no reason\nto prevent them access to the service if a project scope is unneeded.\n\nOn the other hand whilst that is a good justification for leaving things\nas they are i\'m guessing the _reason_ that it is enforced in v2 and some\nscope is not enforced in v3 is mostly an accident.\n\n\nJamie\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<5350084F.4040205@indigitus.ch>',NULL),('<1398674803.10632689.1416254944651.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 15:09:04',-18000,'2014-11-17 20:09:04',NULL,'[openstack-dev] [NFV][Telco] Meeting time and agenda (incl.\n proposal for future alternate time)','Hi all,\n\nThe OpenStack Telco Working Group (formerly NFV subteam) will be meeting for the first time post-summit this Wednesday @ 1400 UTC [1] in #openstack-meeting-alt on Freenode [2]. I have started to draft the agenda here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease add additional items that you would like to discuss during the meeting.  If you received this email directly via BCC then you put your name down on the sign up sheet passed around at the recent telco working group ops summit session [3]. Please sign up to the openstack-operators list [4] and filter emails for the [Telco] tag in the subject to receive further updates from this group.\n\nPlease also note that the group Wiki page has been moved to to reflect the naming and scope discussed at the summit with further edits still to be done:\n\n    https://wiki.openstack.org/wiki/TelcoWorkingGroup\n\nFinally, I would like to propose that we replace the Thursday 1600 UTC alternate time with Wednesday 2200 UTC [5] in future to provide a more divergent option for those attending from other time zones. Please let me know of any objections, we will also discuss this in the meeting.\n\nThanks,\n\nSteve\n\n[1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Group&iso=20141119T14&ah=1\n[2] https://wiki.openstack.org/wiki/IRC\n[3] https://etherpad.openstack.org/p/kilo-summit-ops-telco\n[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n[5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Group+%28alternate%29&iso=20141117T22&ah=1\n\n\n','<579073123.10613112.1416253273279.JavaMail.zimbra@redhat.com>',NULL),('<1398674803.10632689.1416254944651.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-17 15:09:04',-18000,'2014-11-17 20:09:04',NULL,'[Openstack-operators] [NFV][Telco] Meeting time and agenda (incl.\n proposal for future alternate time)','Hi all,\n\nThe OpenStack Telco Working Group (formerly NFV subteam) will be meeting for the first time post-summit this Wednesday @ 1400 UTC [1] in #openstack-meeting-alt on Freenode [2]. I have started to draft the agenda here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease add additional items that you would like to discuss during the meeting.  If you received this email directly via BCC then you put your name down on the sign up sheet passed around at the recent telco working group ops summit session [3]. Please sign up to the openstack-operators list [4] and filter emails for the [Telco] tag in the subject to receive further updates from this group.\n\nPlease also note that the group Wiki page has been moved to to reflect the naming and scope discussed at the summit with further edits still to be done:\n\n    https://wiki.openstack.org/wiki/TelcoWorkingGroup\n\nFinally, I would like to propose that we replace the Thursday 1600 UTC alternate time with Wednesday 2200 UTC [5] in future to provide a more divergent option for those attending from other time zones. Please let me know of any objections, we will also discuss this in the meeting.\n\nThanks,\n\nSteve\n\n[1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Group&iso=20141119T14&ah=1\n[2] https://wiki.openstack.org/wiki/IRC\n[3] https://etherpad.openstack.org/p/kilo-summit-ops-telco\n[4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n[5] http://www.timeanddate.com/worldclock/fixedtime.html?msg=Telco+Working+Group+%28alternate%29&iso=20141117T22&ah=1\n\n\n','<579073123.10613112.1416253273279.JavaMail.zimbra@redhat.com>',NULL),('<1398693951.2957.14.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 10:05:51',-14400,'2014-04-28 14:05:51',NULL,'[openstack-dev] [Globalization] REST API sorting by status\n severity vs. alphabetical status key','On Wed, 2014-04-23 at 22:07 -0500, Steven Kaufer wrote:\n> > yeah, we\'re talking about thousands and thousands of rows that have\n> to\n> > be updated before the API can be restarted?\n> > \n> > > There\'s also a possibility of adding support for the status codes,\n> but\n> > > keeping the string columns in the database, and then using the\n> nova\n> > > object versioning to \"migrate\" the object schema over time to the\n> point\n> > > where the migration is a simple DROP COLUMN.\n> > \n> > I like that idea better, TBH, but we\'re probably talking about a\n> > long-time deprecation here, like on the order of a couple of\n> releases;\n> > that would give plenty of time for the majority of the records to be\n> > revisited and make the final migration run for a lot shorter time.\n> > -- \n> \n> Thanks for the discussion.\n\nNo prob, sorry for the delayed response...\n\n> So how would this new flow work?\n> In Juno would there be an additional status_int column that would be\n> populated and (eventually) replace the existing status (as string)\n> column?\n\nThat would be the cleanest way, yes.\n\n> How would the object versioning populate the new column for the\n> existing records?\n\nWithin the nova.objects.instance.Instance object itself, we can put a\nsmall check-and-transform function in the object to do the translation\nin-line.\n\n> Any examples or details that would help explain how this could work\n> would be appreciated.\n\nProbably worth putting a blueprint up about it. I can work with you on\nit, if you\'d like, though it will likely be after the summit until I\nhave time to work on it.\n\n> Lastly, is there agreement that this is an issue that needs to be\n> addressed? Note that this seems to be a pervasive problem, I\'ve\n> investigated the status column in cinder and nova but I suspect that\n> the same issue exists in other components.\n\nYes, the same issue unfortunately exists in lots of the other\ncomponents, and they don\'t have the benefit of the nova objects work in\nthem, which makes it a lot more of a nuisance to migrate the database\nschema. Though, personally I\'m not entirely sure going through the\neffort of doing a long-time in-object translation is worth it. A change\nto the database schema, even on tens of millions of records wouldn\'t\ntake more than a couple minutes. But it all depends on the operator\'s\ntolerance for downtime, since the instances table would certainly be\nlocked for the duration of the migration.\n\nBest,\n-jay\n\n> Thanks,\n> Steven Kaufer\n> \n> \n> > Kevin L. Mitchell <kevin.mitchell at rackspace.com>\n> > Rackspace\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OF99B6A0AB.17EDE3E3-ON87257CC4.000ECEBD-86257CC4.00111FBD@us.ibm.com>',NULL),('<1398696287.2957.20.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 10:44:47',-14400,'2014-04-28 14:44:47',NULL,'[openstack-dev] [nova][service group]improve host state\n detection','cc\'ing Intel and Ericsson engineers who are interested in a similar\nplan...\n\nOn Mon, 2014-04-28 at 15:33 +0100, John Garbutt wrote:\n> On 28 April 2014 13:30, Jiangying (Jenny) <jenny.jiangying at huawei.com> wrote:\n> > Nova now can detect host unreachable. But it fails to make out host\n> > isolation, host dead and nova compute service down. When host unreachable is\n> > reported, users have to find out the exact state by himself and then take\n> > the appropriate measure to recover. Therefore we?d like to improve the host\n> > detection for nova.\n> >\n> > Currently the service group API factors out the host detection and makes it\n> > a set of abstract internal APIs with a pluggable backend implementation. The\n> > backend we designed is as follows:\n> >\n> > A detection central agent is introduced. When a member joins into the\n> > service group, the member host starts to send network heartbeat to the\n> > central agent and writes timestamp in shared storage periodically. When the\n> > central agent stops receiving the network heartbeats from a member, it pings\n> > the member and checks the storage heartbeat before declaring the host to\n> > have failed.\n> >\n> > ----------------------------------------------------------------------------------------------------------------\n> >\n> > network heartbeat|network ping|storage heartbeat| state          | reason\n> >\n> > ------------------------|-----------------|------------------------|---------------------------|------------------------------------------\n> >\n> >         OK       |      -     |        -        | Running             | -\n> >\n> >       Not OK     |   Not OK   |     Not OK      | Dead               |\n> > hardware failure/abnormal host shut down\n> >\n> >       Not OK     |     OK     |     Not OK      | Service unreachable|\n> > service process crashed\n> >\n> >       Not OK     |   Not OK   |       OK        | Isolated           |\n> > network unreachable\n> >\n> > ----------------------------------------------------------------------------------------------------------------\n> >\n> > Based on the state recognition table, nova can discern the exact host state\n> > and assign the reasons.\n> >\n> > Thoughts?\n> \n> I don\'t think Nova should try to include functionality that\n> re-implements other good monitoring tools (Nagios, etc)\n\nAgreed.\n\n> Having said that, having a new service group API that uses information\n> from external tools to decide if a host is dead or not, and describes\n> why, is maybe worth considering.\n\nAlso agreed.\n\nFYI, related blueprint from Ericsson: \n\nhttps://review.openstack.org/#/c/87978/\n\nI am -1 on the above blueprint not because I don\'t see the value in\nhaving nic state play a part in service group management, but because I\ndon\'t see a reason to have the resource tracker (which manages resource\nusage, not state) or scheduler implement agent state checks.\n\nBest,\n-jay\n\n\n\n','<CABib2_oRB-JSt-B3zwJdiO_m7OrjZa67pcUmCsoD8T8zb63ctw@mail.gmail.com>',NULL),('<1398698141.3661.33.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-28 15:15:43',0,'2014-04-28 15:15:43',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Robert,\n\nAs far as I understood,  Grenade checks and does upgrades.  Instead, the\nproposed matrix does not perform any upgrades, it just checks that\ndifferent services versions work well together.\nConsidering that, do you think that the matrix is useful? \n\nPlease let me know if I am not fully understanding Grenade. \n\nBest Regards,\nPablo\n\nOn Sat, 2014-04-26 at 14:29 +1200, Robert Collins wrote:\n> Don\'t confuse current capabilities with goals :-) grenade certainly\n> intends to test per service upgrades where that is supported. Eg Nova\n> with only the conductor upgraded.\n> \n> On 21 Apr 2014 23:27, \"Fuente, Pablo A\" <pablo.a.fuente at intel.com>\n> wrote:\n>         Hi,\n>         \n>         You are right regarding grenade, but there is a subtle\n>         difference with\n>         the interoperability matrix.\n>         Meanwhile grenade does the upgrade and ensures it is working,\n>          the\n>         matrix checks that different components versions work well (or\n>         not)\n>         together, hoping that this information helps in the upgrade\n>         decisions\n>         (for example, upgrades orders).\n>         In other words, Grenade moves the entire ?cloud? from one\n>         version to\n>         another (all the components in the same version) and the\n>         matrix tests an\n>         specific component version against the rest of the cloud in\n>         another\n>         version.\n>         Actually, I am considering to build this matrix without\n>         performing any\n>         upgrade.\n>         \n>         Then, do you think this matrix could be helpful?\n>         \n>         Thank you very much for your answer!\n>         Regards,\n>         Pablo\n>         \n>         On Thu, 2014-04-17 at 11:27 -0700, Clint Byrum wrote:\n>         > Excerpts from Fuente, Pablo A\'s message of 2014-04-16\n>         14:00:47 -0700:\n>         > > Hi guys,\n>         > >\n>         > > I would like to open a discussion related to OpenStack\n>         upgrades ( I mean\n>         > > moving from one version to another, for example Havana to\n>         Icehouse).\n>         > >\n>         > > As you probably know, this is a big issue, since there is\n>         no silver\n>         > > bullet to do it. For that reason, I am thinking  in an\n>         option to provide\n>         > > more input prior to do an upgrade.\n>         > >\n>         > > The idea is to generate an interoperability matrix, where\n>         devops can see\n>         > > if an specific commit works with all the available\n>         OpenStack versions,\n>         > > distinguishing among the different components. For\n>         example, you could\n>         > > see if  the Nova X commit is or not backward compatible\n>         with the\n>         > > Grizzly/Havana/Icehouse versions of\n>         Keystone/Neutron/Cinder/...\n>         > >\n>         > > Do you think this matrix would be useful in the upgrade\n>         tasks?\n>         > >\n>         >\n>         > The gate currently has \"grenade\", which attempts to upgrade\n>         a working\n>         > stable release to the each commit. If this does not pass, it\n>         does not\n>         > merge.\n>         >\n>         > https://wiki.openstack.org/wiki/Grenade\n>         >\n>         > So this interoperability matrix is actually already\n>         maintained, as _every_\n>         > commit should be able to upgrade from the previous stable\n>         release.\n>         >\n>         > Failures when attempting to do so are bugs in two things:\n>         the thing that\n>         > breaks on upgrade, and grenade.\n>         >\n>         > _______________________________________________\n>         > OpenStack-operators mailing list\n>         > OpenStack-operators at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         \n>         _______________________________________________\n>         OpenStack-operators mailing list\n>         OpenStack-operators at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<CAJ3HoZ2foa9Zo=A08LJbMDWmJHVF36VKP0XB6kX9+wvixs_mXg@mail.gmail.com>',NULL),('<1398700998.17349.23.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 11:03:18',-18000,'2014-04-28 16:03:18',NULL,'[openstack-dev] [cinder][globalization] Need input on how to\n proceed .','Duncan,\n\nThanks for the response.  Have some additional thoughts, in-line, below:\n\n\nOn Mon, 2014-04-28 at 12:15 +0100, Duncan Thomas wrote:\n> Two separate patches, or even two chains of separate patches, will\n> make reviewing and more importantly (hopefully temporary) backouts\n> easier. It will also reduce the number of merge conflicts, which are\n> still likely to be substantial.\n\nTrue, I suppose we need to keep in mind the fact that we might want to\nmake this be easy to back-out in the future.  Hopefully it isn\'t an\nissue this time around though.\n\n> There\'s no benefit at all to all of this being done in one patch, and\n> substantial costs. Doing the conversion by sections seems like the way\n> forward.\n\nSo, let me propose a different process here.  Handling the i18n and\nremoval of debug separately instead.  First, propose one patch that will\nadd the explicit import of \'_\' to all files.  There will be a lot of\nfiles touched, but they all will be 1 liners.  Then make the patch for\nthe re-enablement of lazy tanslation a second patch that is dependent\nupon the first patch.\n\nThen handle removal of _() from DEBUG logs as a separate issue once the\none above has merged.  For that change do it in multiple patches divided\nby section.  Make the sections be the top level directories under\ncinder/ ?  Does that sound like a reasonable plan?\n\n> \n> Doing both around the same time (maybe as dependant patches) seems reasonable\n> \n\nAs I think about it, I don\'t know that the debug translation removal\nneeds to be dependent, but we could work it out that way if you feel\nthat is important.\n\nLet me know what you think.\n\nThanks!\n\n> On 27 April 2014 00:20, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:\n> > All,\n> >\n> > I am looking for feedback on how to complete implementation of i18n\n> > support for Cinder.  I need to open a new BluePrint for Juno as soon as\n> > the cinder-specs process is available.  In the mean time I would like to\n> > start working on this and need feedback on the scope I should undertake\n> > with this.\n> >\n> > First, the majority of the code for i18n support went in with Icehouse.\n> > There is just a small change that is needed to actually enable Lazy\n> > Translation again.  I want to get this enabled as soon as possible to\n> > get plenty of runtime on the code for Icehouse.\n> >\n> > The second change is to add an explicit export for \'_\' to all of our\n> > files to be consistent with other projects. [1]  This is also the safer\n> > way to implement i18n.  My plan is to integrate the change as part of\n> > the i18n work.  Unfortunately this will touch many of the files in\n> > Cinder.\n> >\n> > Given that fact, this brings me to the item I need feedback upon.  It\n> > appears that Nova is moving forward with the plan to remove translation\n> > of debug messages as there was a recent patch submitted to enable a\n> > check for translated DEBUG messages.  Given that fact, would it be an\n> > appropriate time, while adding the explicit import of \'_\' to also remove\n> > translation of debug messages.  It is going to make the commit for\n> > enabling Lazy Translation much bigger, but it would also take out\n> > several work items that need to be addressed at once.  I am willing to\n> > undertake the effort if I have support for the changes.\n> >\n> > Please let me know your thoughts.\n> >\n> > Thanks!2]\n> > Jay\n> > (jungleboyj on freenode)\n> >\n> > [1] https://bugs.launchpad.net/cinder/+bug/1306275\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n\n','<CAOyZ2aE0d0Mpa+ahGZLbo99Pt4erhf2Yvz+H3eWNApfXiKfyPw@mail.gmail.com>',NULL),('<1398704152.3661.34.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 16:55:54',0,'2014-04-28 16:55:54',NULL,'[openstack-dev] [Climate] nominating Pablo Andres Fuente for\n the Climate core reviewers team','No problem.\nThanks\n\nOn Fri, 2014-04-25 at 11:13 +0400, Nikolay Starodubtsev wrote:\n> Congrats, Pablo! I was out of office and have no internet and couldn\'t\n> give you +1 :(\n> \n>                                   \n> \n> Nikolay Starodubtsev\n> \n> \n> Software Engineer\n> \n> Mirantis Inc.\n> \n> \n> \n> Skype: dark_harlequine1\n> \n> \n> \n> \n> \n> 2014-04-24 17:43 GMT+04:00 Fuente, Pablo A <pablo.a.fuente at intel.com>:\n>         Thanks, it\'s an honor!\n>         \n>         On Thu, 2014-04-24 at 13:20 +0000, Sanchez, Cristian A wrote:\n>         > Congratulations Pablo!\n>         >\n>         > From: Sylvain Bauza\n>         <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>>\n>         > Reply-To: \"OpenStack Development Mailing List (not for usage\n>         questions)\"\n>         <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n>         > Date: jueves, 24 de abril de 2014 10:16\n>         > To: \"OpenStack Development Mailing List (not for usage\n>         questions)\"\n>         <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n>         > Subject: Re: [openstack-dev] [Climate] nominating Pablo\n>         Andres Fuente for the Climate core reviewers team\n>         >\n>         > Welcome Pablo !\n>         >\n>         >\n>         > 2014-04-24 15:06 GMT+02:00 Dina Belova\n>         <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>:\n>         > Well, as 3/4 core team members are okay with it, I\'ll do\n>         this)\n>         >\n>         >\n>         > On Thu, Apr 24, 2014 at 2:14 PM, Sylvain Bauza\n>         <sylvain.bauza at gmail.com<mailto:sylvain.bauza at gmail.com>>\n>         wrote:\n>         >\n>         http://russellbryant.net/openstack-stats/climate-reviewers-90.txt\n>         >\n>         > As per the stats, +1 to this.\n>         >\n>         >\n>         > 2014-04-24 12:10 GMT+02:00 Dina Belova\n>         <dbelova at mirantis.com<mailto:dbelova at mirantis.com>>:\n>         > I propose to add Pablo Andreas Fuente (pafuent on the IRC)\n>         to Climate core team.\n>         >\n>         > He\'s Python contributor from Intel, and he took great part\n>         in Climate development including  design suggestions and great\n>         ideas. He has been quite active during the Icehouse and given\n>         his skills, interest and background I suppose it\'ll be great\n>         to add him to the team.\n>         >\n>         >\n>         > Best regards,\n>         >\n>         > Dina Belova\n>         >\n>         > Software Engineer\n>         >\n>         > Mirantis Inc.\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         >\n>         OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         >\n>         OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         >\n>         > --\n>         >\n>         > Best regards,\n>         >\n>         > Dina Belova\n>         >\n>         > Software Engineer\n>         >\n>         > Mirantis Inc.\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         >\n>         OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAa8YgB-t0_eKzqaTKBUH59jyCVe9TT5i3px0qGGzu6qAfAdCQ@mail.gmail.com>',NULL),('<1398704247.3661.36.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 16:57:29',0,'2014-04-28 16:57:29',NULL,'[openstack-dev] [Climate] Query leases by project_id/domain_id','Any comments on this?\n\nOn Tue, 2014-04-22 at 18:58 +0000, Fuente, Pablo A wrote:\n> Hi\n> 	I\'m trying to tackle this bug\n> (https://bugs.launchpad.net/climate/+bug/1304435). The options that I\'m\n> considering are:\n> \n> 	1 - Add the project_id query parameter to the leases API\n> 	2 - Use the X_PROJECT_ID header\n> \n> 	I prefer the first option, but I would like to know if there is a\n> general OpenStack approach for implementing this. BTW, I\'m planning to\n> apply the same criteria for making queries for Domains.\n> \n> Pablo.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1398193115.18419.12.camel@localhost>',NULL),('<1398706856-sup-4149@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 10:51:51',-25200,'2014-04-28 17:51:51',NULL,'[openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains\n	by name - policy and API issues?','So in the process of making Heat deploy itself, I\'ve run into a bit of a\ndeadlock.\n\nhttps://bugs.launchpad.net/tripleo/+bug/1287453\nhttps://bugs.launchpad.net/heat/+bug/1313003\n\nCurrently, we deploy OpenStack like this:\n\n* First we generate usernames/passwords for all service accounts\n* Next we deploy Keystone and Heat (and.. the rest of OpenStack)\n  - In this process, we feed in the usernames and passwords we\n    generated.\n* Then when everything is \"deployed\", we initialize Keystone with the\n  generated usernames and passwords via the keystone API.\n* Now we test to make sure what we deployed works.\n\nHowever, in order to create isolated users for narrow access to Heat\nfrom inside instances, Heat needs a domain to put these narrowly scoped\nusers in. Heat has a handy script for creating this domain and an admin\ninside the domain which is needed to create the lesser users. So that\nnaturally fits into our initialization of keystone.\n\nThe problem is that because of bug 1313003, Heat can only use a domain\nID to specify this domain. We haven\'t created that domain yet at stack\ncreation time though, so we would have to add another step before\ntesting/using the cloud:\n\n* Update stack with ID of heat stack user domain.\n\nSteven Hardy has indicated that it was problematic to make use of names\ninstead of id\'s for domains, and that to me signals a problem with the\nAPI and/or policy model in Keystone around domains.\n\nEverything else in TripleO makes use of names except this, so I think\nwe need to solve this. This isn\'t just a TripleO or Heat problem though,\nanybody using domains will run into the same trouble Steven hit, and\nthat is not something we should ignore.\n\nCan somebody more familiar with domains explain what would be needed to\nbe able to have Heat able to lookup domains by name and use them like\nmost other things in OpenStack, where we can use names or IDs\ninterchangeably?\n\nThanks!\n\n\n',NULL,NULL),('<1398713868-sup-4796@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 12:48:37',-25200,'2014-04-28 19:48:37',NULL,'[openstack-dev] [Heat] [Keystone] [TripleO] Making use of\n	domains by name - policy and API issues?','Excerpts from Dolph Mathews\'s message of 2014-04-28 12:28:41 -0700:\n> On Mon, Apr 28, 2014 at 12:51 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > So in the process of making Heat deploy itself, I\'ve run into a bit of a\n> > deadlock.\n> >\n> > https://bugs.launchpad.net/tripleo/+bug/1287453\n> > https://bugs.launchpad.net/heat/+bug/1313003\n> >\n> > Currently, we deploy OpenStack like this:\n> >\n> > * First we generate usernames/passwords for all service accounts\n> > * Next we deploy Keystone and Heat (and.. the rest of OpenStack)\n> >   - In this process, we feed in the usernames and passwords we\n> >     generated.\n> > * Then when everything is \"deployed\", we initialize Keystone with the\n> >   generated usernames and passwords via the keystone API.\n> > * Now we test to make sure what we deployed works.\n> >\n> > However, in order to create isolated users for narrow access to Heat\n> > from inside instances, Heat needs a domain to put these narrowly scoped\n> > users in. Heat has a handy script for creating this domain and an admin\n> > inside the domain which is needed to create the lesser users. So that\n> > naturally fits into our initialization of keystone.\n> >\n> > The problem is that because of bug 1313003, Heat can only use a domain\n> > ID to specify this domain.\n> \n> \n> I agree with Stephen\'s assessment in bug 1313003:\n> \n>   https://bugs.launchpad.net/heat/+bug/1313003/comments/1\n> \n> It\'s ultimately a user experience issue (it\'d require two config options to\n> properly express two different concepts). This issue isn\'t unique to heat,\n> though.\n> \n> As Stephen points out, \"it\'s a set-once deployer option (not a user-facing\n> one)\" - the IDs are intended exactly for this purpose. They\'re immutable,\n> unambiguous identifiers. They\'re not particularly user-friendly, but as\n> Stephen points out, they don\'t need to be. They just need to be reliable.\n> \n\nIn this instance, I, the deployer, am a Heat and Keystone user. So that\nis not a valid reason to dismiss this overly complicated user experience.\nIf it is hard for me in TripleO, and hard for Steven in Heat, then it\nwill be hard for everybody else who wants to consume keystone domains\nvia the API.\n\nCould you contrast domains with the way that we can use names for every\nother keystone component? Notice:\n\nhttps://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/heat/os-config-applier/etc/heat/heat.conf#n522\n\nIf it has to be a different config option, that is fine, as long as\nthey\'re not both required. But this is the only place that we\'ve run\ninto where we have to put an ID in the configuration for a service,\nrather than a name.\n\nAlso, names are unambiguous. I requested that name specifically so I\ncould use it for this purpose. If they\'re not unique enough to use for\nlookups, then I would love to hear an explanation as to why they cannot\nbe made unique, at least in some context.\n\n\n','<CAC=h7gVCdHXWLVup5A-9YA=ydapTwfngSw9r7TVrYtweza3a1g@mail.gmail.com>',NULL),('<1398716535.3661.41.camel@localhost>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-28 20:22:18',0,'2014-04-28 20:22:18',NULL,'[Openstack-operators] [Upgrades] Interoperability Matrix','Gustavo,\n	The idea is to use devstack to deploy all the OpenStack\nprojects/services in a specific version, except the project/service that\nyou want to check (e.g. all projects at Havanna, Nova at Icehouse).\nThen, over that deploy, to run a particular subset of Tempest tests, and\nuse that output to build the matrix.\n\nPablo.\n\nOn Mon, 2014-04-28 at 12:27 -0300, gustavo panizzo wrote:\n> --\n> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n> \n> sent from mobile\n> \n> On April 28, 2014 12:15:43 PM GMT-03:00, \"Fuente, Pablo A\" <pablo.a.fuente at intel.com> wrote:\n> >Robert,\n> >\n> >As far as I understood,  Grenade checks and does upgrades.  Instead,\n> >the\n> >proposed matrix does not perform any upgrades, it just checks that\n> >different services versions work well together.\n> \n> how do you plan to check that?\n> \n> \n\n\n','<3be407bb-cab8-45be-a511-ab2c85d49a05@email.android.com>',NULL),('<1398723517.92815.YahooMailNeo@web163003.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 15:18:37',-25200,'2014-04-28 22:18:37',NULL,'[openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal','Good afternoon Neutron developers!\n\nThere has been a discussion about dynamic routing in Neutron for the past few weeks in the L3 subteam weekly meetings. I\'ve submitted a review request of the blueprint documenting the proposal of this feature: https://review.openstack.org/#/c/90833/. If you have any feedback or suggestions for improvement, I would love to hear your comments and include your thoughts in the document.\n\nThank you.\n\nSincerely,\nArtem Dmytrenko\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140428/4de8abc6/attachment.html>\n\n',NULL,NULL),('<1398779317.13298.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 14:48:37',3600,'2014-04-29 13:48:37',NULL,'[openstack-dev] [nova] Timestamp formats in the REST API','Hey\n\nIn this patch:\n\n  https://review.openstack.org/83681\n\nby Ghanshyam Mann, we encountered an unusual situation where a timestamp\nin the returned XML looked like this:\n\n  2014-04-08 09:00:14.399708+00:00\n\nWhat appeared to be unusual was that the timestamp had both sub-second\ntime resolution and timezone information. It was felt that this wasn\'t a\nvalid timestamp format and then some debate about how to \'fix\' it:\n\n  https://review.openstack.org/87563\n\nAnyway, this lead me down a bit of a rabbit hole, so I\'m going to\nattempt to document some findings.\n\nFirstly, some definitions:\n\n  - Python\'s datetime module talk about datetime objects being \'naive\' \n    or \'aware\'\n\n        https://docs.python.org/2.7/library/datetime.html\n\n       \"A datetime object d is aware if d.tzinfo is not None and\n        d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None,\n        or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns\n        None, d is naive.\"\n\n    (Most people will have encountered this already, but I\'m including \n    it for completeness)\n\n  - The ISO8601 time and date format specifies timestamps like this:\n\n        2014-04-29T11:37:00Z\n\n    with many variations. One distinguishing aspect of the ISO8601 \n    format is the \'T\' separating date and time. RFC3339 is very closely\n    related and serves as easily accessible documentation of the format:\n\n       http://www.ietf.org/rfc/rfc3339.txt\n\n  - The Python iso8601 library allows parsing this time format, but \n    also allows subtle variations that don\'t conform to the standard \n    like omitting the \'T\' separator:\n\n      >>> import iso8601\n      >>> iso8601.parse_date(\'2014-04-29 11:37:00Z\')\n      datetime.datetime(2014, 4, 29, 11, 37, tzinfo=<iso8601.iso8601.Utc object at 0x214b050>)\n\n    Presumably this is for the pragmatic reason that when you stringify \n    a datetime object, the resulting string uses \' \' as a separator:\n\n      >>> import datetime\n      >>> str(datetime.datetime(2014, 4, 29, 11, 37))\n      \'2014-04-29 11:37:00\'\n\nAnd now some observations on what\'s going on in Nova:\n\n  - We don\'t store timezone information in the database, but all our \n    timestamps are relative to UTC nonetheless.\n\n  - The objects code automatically adds the UTC to naive datetime \n    objects:\n\n        if value.utcoffset() is None:\n            value = value.replace(tzinfo=iso8601.iso8601.Utc())\n\n    so code that is ported to objects may now be using aware datetime \n    objects where they were previously using naive objects.\n\n  - Whether we store sub-second resolution timestamps in the database \n    appears to be database specific. In my quick tests, we store that \n    information in sqlite but not MySQL.\n\n  - However, timestamps added by SQLAlchemy when you do e.g. save() do \n    include sub-second information, so some DB API calls may return \n    sub-second timestamps even when that information isn\'t stored in \n    the database.\n\nIn our REST APIs, you\'ll essentially see one of three time formats. I\'m\ncalling them \'isotime\', \'strtime\' and \'xmltime\':\n\n  - \'isotime\' - this is the result from timeutils.isotime(). It \n    includes timezone information (i.e. a \'Z\' prefix) but not \n    microseconds. You\'ll see this in places where we stringify the \n    datetime objects in the API layer using isotime() before passing \n    them to the JSON/XML serializers.\n\n  - \'strtime\' - this is the result from timeutils.strtime(). It doesn\'t \n    include timezone information but does include decimal seconds. This \n    is what jsonutils.dumps() uses when we\'re serializing API responses \n\n  - \'xmltime\' or \'str(datetime)\' format - this is just what you get \n    when you stringify a datetime using str(). If the datetime is tz \n    aware or includes non-zero microseconds, then that information will \n    be included in the result. This is a significant different versus \n    the other two formats where it is clear whether tz and microsecond \n    information is included in the string.\n\nbut there are some caveats:\n\n  - I don\'t know how significant it is these days, but timestamps will \n    be serialized to strtime format when going over RPC, but won\'t be \n    de-serialized on the remote end. This could lead to a situation \n    where the API layer tries and stringify a strtime formatted string\n    using timeutils.isotime(). (see below for a description of those \n    formats)\n\n  - In at least one place - e.g. the \'updated\' timestamp for v2\n    extensions - we hardcode the timestamp as strings in the code and \n    don\'t currently use one of the formats above.\n\n\nMy conclusions from all that:\n\n  1) This sucks\n\n  2) At the very least, we should be clear in our API samples tests \n     which of the three formats we expect - we should only change the \n     format used in a given part of the API after considering any \n     compatibility considerations\n\n  3) We should unify on a single format in the v3 API - IMHO, we should \n     be explicit about use of the UTC timezone and we should avoid \n     including microseconds unless there\'s a clear use case. In other \n     words, we should use the \'isotime\' format.\n\n  4) The \'xmltime\' format is just a dumb historical mistake and since \n     XML support is now firmly out of favor, let\'s not waste time \n     improving the timestamp situation in XML.\n\n  5) We should at least consider moving to a single format in the v2 \n     (JSON) API. IMHO, moving from strtime to isotime for fields like \n     created_at and updated_at would be highly unlikely to cause any \n     real issues for API users.\n\n(Following up this email with some patches that I\'ll link to, but I want\nto link to this email from the patches themselves)\n\nMark.\n\n\n\n',NULL,NULL),('<1398779733.13298.44.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 14:55:33',3600,'2014-04-29 13:55:33',NULL,'[openstack-dev] [nova] Timestamp formats in the REST API','On Tue, 2014-04-29 at 14:48 +0100, Mark McLoughlin wrote:\n\n> My conclusions from all that:\n> \n>   1) This sucks\n> \n>   2) At the very least, we should be clear in our API samples tests \n>      which of the three formats we expect - we should only change the \n>      format used in a given part of the API after considering any \n>      compatibility considerations\n> \n>   3) We should unify on a single format in the v3 API - IMHO, we should \n>      be explicit about use of the UTC timezone and we should avoid \n>      including microseconds unless there\'s a clear use case. In other \n>      words, we should use the \'isotime\' format.\n> \n>   4) The \'xmltime\' format is just a dumb historical mistake and since \n>      XML support is now firmly out of favor, let\'s not waste time \n>      improving the timestamp situation in XML.\n> \n>   5) We should at least consider moving to a single format in the v2 \n>      (JSON) API. IMHO, moving from strtime to isotime for fields like \n>      created_at and updated_at would be highly unlikely to cause any \n>      real issues for API users.\n> \n> (Following up this email with some patches that I\'ll link to, but I want\n> to link to this email from the patches themselves)\n\nSee here:\n\n  https://review.openstack.org/#/q/project:openstack/nova+topic:timestamp-format,n,z\n\nMark.\n\n\n\n','<1398779317.13298.42.camel@sorcha>',NULL),('<1398786367-sup-2118@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 09:16:53',-25200,'2014-04-29 16:16:53',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Excerpts from Thomas Goirand\'s message of 2014-04-29 07:32:59 -0700:\n> On 04/29/2014 06:42 AM, Jeremy Stanley wrote:\n> > On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote:\n> >> Just a friendly reminder to add yourself to this list if you are\n> >> interested in participating in the key signing in Atlanta:\n> >>\n> >> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> > [...]\n> > \n> > It has a sign-up cutoff of two weeks ago, so I assume that was\n> > merely a placeholder. Which begs the question how late is too late\n> > for participants to be able to comfortably print out their copies\n> > (assuming we do http://keysigning.org/methods/sassaman-efficient\n> > this time)? Should lock down the page Wednesday May 7th? Sooner?\n> > \n> > Keep in mind that this week (April 27 through May 3) is supposed to\n> > be a vacation week for the project, so people may not be around to\n> > add themselves until Monday May 5th ;)\n> \n> Is there a date a place already schedule for the key signing party?\n\nActually since we have the summit schedule now, we should start looking\nfor a time and place.\n\nI think Wednesday would be the ideal day, as it has the most overlap\nwith the conference and is at least adjacent to if not within most\ndesign tracks.\n\nThere are basically two questions:\n\na) How much time do we need?\nb) Where can we find a room where we can isolate ourselves?\n\ntl;dr -- (a) 20 minutes min. (b) A meeting room or a design summit room.\n\nSetup time is less than 5 minutes if we all bring paper printouts. Given\nthat, more time will increase the number of identities that we are all\nable to verify. So I suggest we ensure that everyone understands the\nprocess and brings their print outs on the day-of. If we can do that, I\nthink we can get quite a few ID\'s verified and keys signed in just 20\nminutes. Given a 30 minute break, I suggest we schedule the event for 5\nminutes after the start of the break.\n\nAs far as a location, if there are private meeting rooms of a large\nenough size that would be ideal. If we can\'t get one of those, then\nperhaps we should target lunch time instead, and use a design summit\nroom (since they\'ll be mostly empty for the lunch break).\n\nI don\'t know who to contact to schedule a meeting room. Anybody?\n\n\n','<535FB81B.6080705@debian.org>',NULL),('<1398788304-sup-9919@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 09:19:50',-25200,'2014-04-29 16:19:50',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Break time is extremely busy in the developers lounge. We can have\nothers in the room, but we need enough of a space for everyone to stand\nin two lines and rotate and be uninterrupted.\n\nExcerpts from Davanum Srinivas\'s message of 2014-04-29 09:07:12 -0700:\n> How about 10:30 AM Break on Wednesday at the Developers Lounge (Do we\n> have one this time?)\n> \n> -- dims\n> \n> On Tue, Apr 29, 2014 at 10:32 AM, Thomas Goirand <zigo at debian.org> wrote:\n> > On 04/29/2014 06:42 AM, Jeremy Stanley wrote:\n> >> On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote:\n> >>> Just a friendly reminder to add yourself to this list if you are\n> >>> interested in participating in the key signing in Atlanta:\n> >>>\n> >>> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> >> [...]\n> >>\n> >> It has a sign-up cutoff of two weeks ago, so I assume that was\n> >> merely a placeholder. Which begs the question how late is too late\n> >> for participants to be able to comfortably print out their copies\n> >> (assuming we do http://keysigning.org/methods/sassaman-efficient\n> >> this time)? Should lock down the page Wednesday May 7th? Sooner?\n> >>\n> >> Keep in mind that this week (April 27 through May 3) is supposed to\n> >> be a vacation week for the project, so people may not be around to\n> >> add themselves until Monday May 5th ;)\n> >\n> > Is there a date a place already schedule for the key signing party?\n> >\n> > Thomas\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CANw6fcF0SD1UprjXK9nbjciyS8kznV985T2sZ-vEJtE1yH1CTA@mail.gmail.com>',NULL),('<1398794577.13477.111789749.5D0818E1@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 11:02:57',-25200,'2014-04-29 18:02:57',NULL,'[openstack-dev] [tripleo] Location of Monitoring Checks','> > Hi all,\n> >\n> > I have a patch in flight at the moment [0] to install check_mk server and compliment the already merged installation of check_mk agent [1] so my thoughts are now turning to how we would recommend adding new service checks.\n> >\n> > The concept behind check_mk makes this really simple to do.  You just place a script that outputs \"<status_code> <check_name> <performance_data> <message>\" into the agent\'s \"local\" directory (/usr/lib/check_mk_agent/local on Ubuntu for example) and it will be picked up the next time an inventory of the system is run.\n> >\n> > There are two ways that we can recommend doing this:\n> >\n> > 1) We ask users to update the check_mk_agent T-I-E every time they wish to add a new check\n> > 2) We ask users to distribute checks from their own T-I-E into the correct location\n> >\n> > In my opinion, requiring an update to check_mk_agent for every new check is the wrong way of doing this as it means that all systems get all checks regardless of function.  Far more preferable would be option 2, however I\'m open to other ideas, especially if they mean that organisations using this don\'t have to go through the review process if they have checks they wish to keep \"behind the firewall\" for IP/Licensing reasons.\n> \n> Agreed.  Option 2 sounds like the only way to go here.  Adding \n> instructions on how and where to add a check to the README file and \n> maybe having a sample check element that users can look at for reference \n> should be sufficient, I would think.\n> \n\n++ This is a common pattern in many of the elements. Additionally, It\nmight be worth exporting a variable in check_mk\'s environment.d for\nother elements to use as the agent local directory if this path isnt\nentirely consistent across distros.\n\n> >\n> > Thanks in advance for any help people can give on this,\n> >\n> > Matt\n> >\n> > [0] https://review.openstack.org/#/c/87226/\n> > [1] https://review.openstack.org/#/c/81485/\n> >\n\n\n','<535FC4C4.4000004@nemebean.com>',NULL),('<1398811564-sup-3170@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-29 15:48:47',-25200,'2014-04-29 22:48:47',NULL,'[openstack-dev] [Neutron] SSL VPN Implemenatation','Excerpts from Nachi Ueno\'s message of 2014-04-29 10:58:53 -0700:\n> Hi Kyle\n> \n> 2014-04-29 10:52 GMT-07:00 Kyle Mestery <mestery at noironetworks.com>:\n> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno <nachi at ntti3.com> wrote:\n> >> Hi Zang\n> >>\n> >> Thank you for your contribution on this!\n> >> The private key management is what I want to discuss in the summit.\n> >>\n> > Has the idea of using Barbican been discussed before? There are many\n> > reasons why using Barbican for this may be better than developing key\n> > management ourselves.\n> \n> No, however I\'m +1 for using Barbican. Let\'s discuss this in\n> certificate management topic in advanced service session.\n> \n\nJust a suggestion: Don\'t defer that until the summit. Sounds like you\'ve\nalready got some consensus, so you don\'t need the summit just to rubber\nstamp it. I suggest discussing as much as you can right now on the mailing\nlist, and using the time at the summit to resolve any complicated issues\nincluding any \"a or b\" things that need crowd-sourced idea making. You\ncan also use the summit time to communicate your requirements to the\nBarbican developers.\n\nPoint is: just because you\'ll have face time, doesn\'t mean you should\nuse it for what can be done via the mailing list.\n\n\n','<CABJepwg3b2Mdcvnv5uOYjjNLn7fcyBovksR0bX99RtgXyR0giA@mail.gmail.com>',NULL),('<1398871838.22694.3.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 15:30:41',0,'2014-04-30 15:30:41',NULL,'[openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion\n about Cross-Project Integration of DNS at Summit','Yep - I know I\'ll join in :)\n\nThanks,\nKiall\n\nOn Tue, 2014-04-29 at 14:09 -0600, Carl Baldwin wrote:\n> The design summit discussion topic I submitted [1] for my DNS\n> blueprints [2][3][4] and this one [5] just missed the cut for the\n> design session schedule.  It stung a little to be turned down but I\n> totally understand the time and resource constraints that drove the\n> decision.\n> \n> I feel this is an important subject to discuss because the end result\n> will be a better cloud user experience overall.  The design summit\n> could be a great time to bring together interested parties from\n> Neutron, Nova, and Designate to discuss the integration that I propose\n> in these blueprints.\n> \n> DNS for IPv6 in Neutron is also something I would like to discuss.\n> Mostly, I\'d like to get a good sense for where this is at currently\n> with the current Neutron dns implementation (dnsmasq) and how it will\n> fit in.\n> \n> I\'ve created an etherpad to help us coordinate [6].  If you are\n> interested, please go there and help me flesh it out.\n> \n> Carl Baldwin\n> Neutron L3 Subteam\n> \n> [1] http://summit.openstack.org/cfp/details/403\n> [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution\n> [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution\n> [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution\n> [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem\n> [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CALiLy7rn1ooOShGn0oA0TR4P8h44b9deXr8dJmftEcihuxVEbw@mail.gmail.com>',NULL),('<1398873054.4527.9.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 15:50:59',0,'2014-04-30 15:50:59',NULL,'[openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion\n about Cross-Project Integration of DNS at Summit','Yup - me too.\n\nGraham\n\nOn Wed, 2014-04-30 at 15:30 +0000, Mac Innes, Kiall wrote:\n\n\nYep - I know I\'ll join in :)\n\nThanks,\nKiall\n\nOn Tue, 2014-04-29 at 14:09 -0600, Carl Baldwin wrote:\n> The design summit discussion topic I submitted [1] for my DNS\n> blueprints [2][3][4] and this one [5] just missed the cut for the\n> design session schedule.  It stung a little to be turned down but I\n> totally understand the time and resource constraints that drove the\n> decision.\n>\n> I feel this is an important subject to discuss because the end result\n> will be a better cloud user experience overall.  The design summit\n> could be a great time to bring together interested parties from\n> Neutron, Nova, and Designate to discuss the integration that I propose\n> in these blueprints.\n>\n> DNS for IPv6 in Neutron is also something I would like to discuss.\n> Mostly, I\'d like to get a good sense for where this is at currently\n> with the current Neutron dns implementation (dnsmasq) and how it will\n> fit in.\n>\n> I\'ve created an etherpad to help us coordinate [6].  If you are\n> interested, please go there and help me flesh it out.\n>\n> Carl Baldwin\n> Neutron L3 Subteam\n>\n> [1] http://summit.openstack.org/cfp/details/403\n> [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution\n> [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution\n> [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution\n> [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem\n> [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1398871838.22694.3.camel@kiall-desktop>',NULL),('<1398873336.2724.29.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-30 10:55:36',-18000,'2014-04-30 15:55:36',NULL,'[OpenStack-Infra] Urgent: Problem with Gerrit JS?','I\'m trying to review https://review.openstack.org/#/c/44715/8 and when I\ngo to look at the nova/tests/db/test_db_api.py by clicking on that link\nunder \"File Path\" in the review table, I get an \"Unresponsive script\"\nwarning from my browser; clicking on the \"Continue\" option in the\nwarning pop-up does not help.  I\'ve also tried the \"Side-by-Side\" and\n\"Unified\" links from that table, even the \"All Side-by-Side\" and \"All\nUnified\" links.  The same problem also occurs if I try to get there by\nclicking the \"next\" link while looking at the commit message.  I have\ntried restarting my browser, but the same thing still happens.  I\'m also\nhaving the issue trying to look at the same file in patch set 7, which I\nhad previously reviewed.\n\nThis is happening with Firefox 28.0 running on a Fedora 19 x86_64\nsystem.\n\nThe script that\'s being referenced is:\n\n        https://review.openstack.org/gerrit_ui/89B6B1C2255AB537598BF6FC8F36BB0D.cache.html:164\n\nMy \"Change View\" setting is \"Server Default (Old Screen)\".\n\nAny ideas?  The change is a +14-12, and I can\'t seem to look at the file\nin *any* patch set on this review anymore.\n\nFurther investigation shows that the same problem occurs with the same\nfile in https://review.openstack.org/#/c/44714 and\nhttps://review.openstack.org/#/c/44716/ so it seems to be a problem\nspecific to the test_db_api.py file itself.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1398875687.2724.31.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-30 11:34:47',-18000,'2014-04-30 16:34:47',NULL,'[OpenStack-Infra] Urgent: Problem with Gerrit JS?','On Wed, 2014-04-30 at 12:14 -0400, Anita Kuno wrote:\n> Are you able to file a bug with this information? It will help us track\n> progress on this easier than an email thread. If you reply with a link I\n> will confirm the bug.\n\nSure, I just wasn\'t sure where to file the bug :)  Best filed at\nhttps://launchpad.net/openstack-ci ?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53612149.6020109@anteaya.info>',NULL),('<1398876884.2724.37.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-30 11:54:44',-18000,'2014-04-30 16:54:44',NULL,'[OpenStack-Infra] Urgent: Problem with Gerrit JS?','On Wed, 2014-04-30 at 12:47 -0400, Anita Kuno wrote:\n> On 04/30/2014 12:34 PM, Kevin L. Mitchell wrote:\n> > On Wed, 2014-04-30 at 12:14 -0400, Anita Kuno wrote:\n> >> Are you able to file a bug with this information? It will help us track\n> >> progress on this easier than an email thread. If you reply with a link I\n> >> will confirm the bug.\n> > \n> > Sure, I just wasn\'t sure where to file the bug :)  Best filed at\n> > https://launchpad.net/openstack-ci ?\n> > \n> Well Khai thinks this might belong upstream. Why not file it at\n> openstack-ci and if this is upstream we can mark the bug invalid and\n> make a recommendation or file it ourselves.\n> \n> Would that work for you, Kevin?\n\nJust wanted to confirm I had selected the correct local tracker.\nAnyway, reported as:\n\n        https://bugs.launchpad.net/openstack-ci/+bug/1314713\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<5361291E.5010500@anteaya.info>',NULL),('<1398894850.7356.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 22:54:10',3600,'2014-04-30 21:54:10',NULL,'[openstack-dev] [nova] Timestamp formats in the REST API','On Tue, 2014-04-29 at 10:39 -0400, Doug Hellmann wrote:\n> On Tue, Apr 29, 2014 at 9:48 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > Hey\n> >\n> > In this patch:\n> >\n> >   https://review.openstack.org/83681\n> >\n> > by Ghanshyam Mann, we encountered an unusual situation where a timestamp\n> > in the returned XML looked like this:\n> >\n> >   2014-04-08 09:00:14.399708+00:00\n> >\n> > What appeared to be unusual was that the timestamp had both sub-second\n> > time resolution and timezone information. It was felt that this wasn\'t a\n> > valid timestamp format and then some debate about how to \'fix\' it:\n> >\n> >   https://review.openstack.org/87563\n> >\n> > Anyway, this lead me down a bit of a rabbit hole, so I\'m going to\n> > attempt to document some findings.\n> >\n> > Firstly, some definitions:\n> >\n> >   - Python\'s datetime module talk about datetime objects being \'naive\'\n> >     or \'aware\'\n> >\n> >         https://docs.python.org/2.7/library/datetime.html\n> >\n> >        \"A datetime object d is aware if d.tzinfo is not None and\n> >         d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None,\n> >         or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns\n> >         None, d is naive.\"\n> >\n> >     (Most people will have encountered this already, but I\'m including\n> >     it for completeness)\n> >\n> >   - The ISO8601 time and date format specifies timestamps like this:\n> >\n> >         2014-04-29T11:37:00Z\n> >\n> >     with many variations. One distinguishing aspect of the ISO8601\n> >     format is the \'T\' separating date and time. RFC3339 is very closely\n> >     related and serves as easily accessible documentation of the format:\n> >\n> >        http://www.ietf.org/rfc/rfc3339.txt\n> >\n> >   - The Python iso8601 library allows parsing this time format, but\n> >     also allows subtle variations that don\'t conform to the standard\n> >     like omitting the \'T\' separator:\n> >\n> >       >>> import iso8601\n> >       >>> iso8601.parse_date(\'2014-04-29 11:37:00Z\')\n> >       datetime.datetime(2014, 4, 29, 11, 37, tzinfo=<iso8601.iso8601.Utc object at 0x214b050>)\n> >\n> >     Presumably this is for the pragmatic reason that when you stringify\n> >     a datetime object, the resulting string uses \' \' as a separator:\n> >\n> >       >>> import datetime\n> >       >>> str(datetime.datetime(2014, 4, 29, 11, 37))\n> >       \'2014-04-29 11:37:00\'\n> >\n> > And now some observations on what\'s going on in Nova:\n> >\n> >   - We don\'t store timezone information in the database, but all our\n> >     timestamps are relative to UTC nonetheless.\n> >\n> >   - The objects code automatically adds the UTC to naive datetime\n> >     objects:\n> >\n> >         if value.utcoffset() is None:\n> >             value = value.replace(tzinfo=iso8601.iso8601.Utc())\n> >\n> >     so code that is ported to objects may now be using aware datetime\n> >     objects where they were previously using naive objects.\n> >\n> >   - Whether we store sub-second resolution timestamps in the database\n> >     appears to be database specific. In my quick tests, we store that\n> >     information in sqlite but not MySQL.\n> >\n> >   - However, timestamps added by SQLAlchemy when you do e.g. save() do\n> >     include sub-second information, so some DB API calls may return\n> >     sub-second timestamps even when that information isn\'t stored in\n> >     the database.\n> >\n> > In our REST APIs, you\'ll essentially see one of three time formats. I\'m\n> > calling them \'isotime\', \'strtime\' and \'xmltime\':\n> >\n> >   - \'isotime\' - this is the result from timeutils.isotime(). It\n> >     includes timezone information (i.e. a \'Z\' prefix) but not\n> >     microseconds. You\'ll see this in places where we stringify the\n> >     datetime objects in the API layer using isotime() before passing\n> >     them to the JSON/XML serializers.\n> >\n> >   - \'strtime\' - this is the result from timeutils.strtime(). It doesn\'t\n> >     include timezone information but does include decimal seconds. This\n> >     is what jsonutils.dumps() uses when we\'re serializing API responses\n> >\n> >   - \'xmltime\' or \'str(datetime)\' format - this is just what you get\n> >     when you stringify a datetime using str(). If the datetime is tz\n> >     aware or includes non-zero microseconds, then that information will\n> >     be included in the result. This is a significant different versus\n> >     the other two formats where it is clear whether tz and microsecond\n> >     information is included in the string.\n> >\n> > but there are some caveats:\n> >\n> >   - I don\'t know how significant it is these days, but timestamps will\n> >     be serialized to strtime format when going over RPC, but won\'t be\n> >     de-serialized on the remote end. This could lead to a situation\n> >     where the API layer tries and stringify a strtime formatted string\n> >     using timeutils.isotime(). (see below for a description of those\n> >     formats)\n> >\n> >   - In at least one place - e.g. the \'updated\' timestamp for v2\n> >     extensions - we hardcode the timestamp as strings in the code and\n> >     don\'t currently use one of the formats above.\n> >\n> >\n> > My conclusions from all that:\n> >\n> >   1) This sucks\n> >\n> >   2) At the very least, we should be clear in our API samples tests\n> >      which of the three formats we expect - we should only change the\n> >      format used in a given part of the API after considering any\n> >      compatibility considerations\n> >\n> >   3) We should unify on a single format in the v3 API - IMHO, we should\n> >      be explicit about use of the UTC timezone and we should avoid\n> >      including microseconds unless there\'s a clear use case. In other\n> >      words, we should use the \'isotime\' format.\n> \n> This seems like a situation where we should try take the needs of all\n> projects into account, so we converge on a consistent timestamp format\n> across APIs. For example, ceilometer\'s database schema was updated to\n> support sub-second timestamps to differentiate between events coming\n> in very close together\n> (https://bugs.launchpad.net/ceilometer/+bug/1215676). I don\'t know if\n> Marconi uses timestamps in their API, but if so that\'s another case\n> where I would expect the caller to want sub-second precision, at least\n> sometimes.\n\nYeah, it\'s probably easiest for everyone if we just favor\nisotime(subsecond=True) as the preferred format in all public APIs\nrather than just doing it for those cases we see a real need for it.\n\nThat said, there\'s a bunch of stuff involved to do that even just for\nNova:\n\n  - whether it would be reasonable to change the format used in the v2 \n    API - i.e. how likely would such a change break existing clients. \n    IMO, probably too much risk for too little reward to justify it.\n\n  - for the v3 API, either converting jsonutils.dumps() to use \n    isotime(subsecond=True) rather than strtime() or ensuring that all \n    timestamps are serialized with isotime(subsecond=True) before \n    calling dumps()\n\n  - for the v3 API, adding subsecond=True to existing uses of isotime()\n\n  - avoiding having any of this cause incompatible changes in the RPC \n    APIs which also use dumps()\n\n  - ensuring sub-second time information is actually saved in the DB\n\nThanks,\nMark.\n\n\n\n','<CADb+p3TXLNUX6aV1aGKfy+s7_80uv9TOXVe3D_aw1H-xwYrohw@mail.gmail.com>',NULL),('<1398900863-sup-8135@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-30 16:34:44',-25200,'2014-04-30 23:34:44',NULL,'[openstack-dev] PGP keysigning party for Juno summit in Atlanta?','Excerpts from Jeremy Stanley\'s message of 2014-04-30 15:47:21 -0700:\n> On 2014-04-29 18:01:44 +0000 (+0000), Jeremy Stanley wrote:\n> [...]\n> > I\'ll check with the team handling venue logistics right now and\n> > update this thread with options. I\'m also inquiring about the\n> > availability of a projector if we get one of the non-design-session\n> > breakout rooms, and I can bring a digital micro/macroscope which\n> > ought to do a fair job of showing everyone\'s photo IDs through it if\n> > so (which would enable us to use The \'Sassman-Projected\' Method and\n> > significantly increase our throughput via parallelization).\n> \n> I was able to confirm a dedicated location (room 405, just one floor\n> up from the design summit sessions) Wednesday 10:30-11:00am with a\n> projector and seating for 50. We\'re getting close to that many on\n> the sign-up sheet already... chances are we\'ll be able to put each\n> ID up on the projector for 15-20 seconds, taking buffer time into\n> account at the beginning for walking to the room and reading the\n> master list checksum aloud. I\'ve asked the organizers to list this\n> as \"OpenStack Web of Trust: Key Signing\" and have updated\n> https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit\n> accordingly.\n\nFantastic.\n\n\n','<20140430224720.GO11154@yuggoth.org>',NULL),('<1398949145.3990.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 12:59:09',0,'2014-05-01 12:59:09',NULL,'[openstack-dev] [climate] Friday Meeting','+1\nI can\'t attend to the metting too, I will be at the marriage of a\nfriend. BTW, I will like to tell you guys, that for us (Argentina\nfolks), today and tomorrow are days off.\n\nOn Thu, 2014-05-01 at 00:11 +0400, Dina Belova wrote:\n> +1\n> \n> \n> On Wed, Apr 30, 2014 at 11:41 PM, Sylvain Bauza\n> <sylvain.bauza at gmail.com> wrote:\n>         Hi Dina,\n>         \n>         \n>         I forgot yesterday to mention it was my last day at Bull, so\n>         the end of week was off-work until Monday.\n>         As a corollar, I won\'t be able to attend Friday meeting.\n>         \n>         \n>         Let\'s cancel this meeting and raise topics in mailing-list if\n>         needed.\n>         \n>         \n>         -Sylvain\n>         \n>         \n>         2014-04-30 19:17 GMT+02:00 Dina Belova <dbelova at mirantis.com>:\n>                 Folks, o/\n>                 \n>                 \n>                 I finally got my dates for the US trip, and I have to\n>                 say, that I won\'t be able to attend our closest Friday\n>                 meeting as I\'ll be flying at this moment)\n>                 \n>                 \n>                 Sylvain, will you be able to hold the meeting?\n>                 \n>                 \n>                 Best regards,\n>                 \n>                 Dina Belova\n>                 \n>                 Software Engineer\n>                 \n>                 Mirantis Inc.\n>                 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Best regards,\n> \n> Dina Belova\n> \n> Software Engineer\n> \n> Mirantis Inc.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CACsCO2zPmoadHPTymchdfBGfhR+eX0-kog0ERjebayriiQzVcQ@mail.gmail.com>',NULL),('<1398952252.3990.39.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 13:50:56',0,'2014-05-01 13:50:56',NULL,'[openstack-dev] [climate] Client and REST API versioning','Hi,\n	We recently implemented our V2 REST API, and at this moment we are\ntrying to get working our python client against this new version. For\nthis reason, we start a discussion about how the client will choose/set\nthe REST API version to use. BTW, we are not deprecating our V1 REST\nAPI, so we need that our client still support it.\nThis are our discussions:\n\n1 - Should the URL stored in Keystone service catalog have the version?\n	In this case, our client will get the REST API URL from Keystone, parse\nit, select the correct version of the client code and then start\nperforming requests. But if we choose this path, if a user of the client\ndecides to use the V1 REST API version using\n--os-reservation-api-version, the client should strip the version of the\nURL and then append the version that the user wants. The thing here is\nthat we are storing a version on a URL that we could not use in some\ncases. In other words the version on the URL could be override.\n\n2 - Should Climate store only one URL in Keystone catalog without\nversion?\n	Here, the client, will know the default version to use, appending that\nversion to the service catalog version. When the client user request\nanother version, the client simply append that version to the end. The\ncons of this option, is that if someone plan to use the REST API without\nour client needs to know about how we handle the version. Here we can\nprovide /versions in order to tell how we are handling/naming versions.\n\n3 - Should Climate store all the REST API URLs with the version at the\nend and using versions in service types? e.g reservation and\nreservationV2\n	Here the client will get the version that needs querying the service\ntype by version. Seems that some projects do this, but for me seems that\nthis option is similar to 2, with the con that when Climate deprecate\nV1, the only service type will be reservationV2, which sounds weird for\nme.\n\nWe would like to get your feedback about this points (or new ones) in\norder to get this implemented in the right way.\n\nPablo.\nP.S. I hope that all the options in this email reflect correctly what we\ndiscussed at Climate. If not, please add/clarify/remove what you want.\n\n',NULL,NULL),('<1398952793.2809.7.camel@tvardeman-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 13:59:53',0,'2014-05-01 13:59:53',NULL,'[openstack-dev] [Neutron][LBaaS] RackSpace API review\n (multi-call)','Vijay,\n\nComments in-line, hope I can clear some of this up for you :)\n\n-Trevor\n\nOn Thu, 2014-05-01 at 13:16 +0000, Vijay Venkatachalam wrote:\n> I am expecting to be more active on community on the LBaaS front. \n> \n> May be reviewing and picking-up a few items to  work as well.\n> \n> I had a look at the proposal. Seeing Single & Multi-Call approach for each workflow \n> makes it easy to understand. \n> \n> Thanks for the clear documentation, it is welcoming to review :-). I was not allowed to comment on WorkFlow doc, can you enable comments?\n> \n> The single-call approach essentially creates the global pool/VIP. Once VIP/Pool is created using single call, are they reusable in multi-call?\n> For example: Can a pool created for HTTP endpoint/loadbalancer be used in HTTPS endpoint LB where termination occurs as well?\n\nFrom what I remember discussing with my team (being a developer under\nJorge\'s umbrella) There is a 1-M relationship between load balancer and\npool.  Also, the protocol is specified on the Load Balancer, not the\npool, meaning you could expose TCP traffic via one Load Balancer to a\npool, and HTTP traffic via another Load Balancer to that same pool.\nThis is easily modified such \n\n> \n> Also, would it be useful to include PUT as a single call? I see PUT only for POOL not for LB.\n> A user who started with single-call  POST, might like to continue to use the same approach for PUT/update as well.\n\nOn the fifth page of the document found here:\nhttps://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit\nThere is a PUT detailed for a Load Balancer.  There should be support\nfor PUT on any parent object assuming the fields one would update are\nnot read-only.\n\n> \n> Thanks,\n> Vijay V.\n> \n> -----Original Message-----\n> From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM] \n> Sent: Thursday, May 1, 2014 3:57 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process\n> \n> Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as you initials so I got confused. :)\n> \n> Cheers,\n> --Jorge\n> \n> \n> \n> \n> On 4/30/14 5:17 PM, \"Jorge Miramontes\" <jorge.miramontes at RACKSPACE.COM>\n> wrote:\n> \n> >Hey everyone,\n> >\n> >I agree that we need to be preparing for the summit. Using Google docs \n> >mixed with Openstack wiki works for me right now. I need to become more \n> >familiar the gerrit process and I agree with Samuel that it is not \n> >conducive to \"large\" design discussions. That being said I\'d like to \n> >add my thoughts on how I think we can most effectively get stuff done.\n> >\n> >As everyone knows there are many new players from across the industry \n> >that have an interest in Neutron LBaaS. Companies I currently see \n> >involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix, \n> >eBay/Paypal and Rackspace. We also have individuals involved as well. I \n> >echo Kyle\'s sentiment on the passion everyone is bringing to the project!\n> >Coming into this project a few months ago I saw that a few things \n> >needed to be done. Most notably, I realized that gathering everyone\'s \n> >expectations on what they wanted Neutron LBaaS to be was going to be \n> >crucial. Hence, I created the requirements document. Written \n> >requirements are important within a single organization. They are even \n> >more important when multiple organizations are working together because \n> >everyone is spread out across the world and every organization has a \n> >different development process. Again, my goal with the requirements \n> >document is to make sure that everyone\'s voice in the community is \n> >taken into consideration. The benefit I\'ve seen from this document is \n> >that we ask \"Why?\" to each other, iterate on the document and in the \n> >end have a clear understanding of everyone\'s motives. We also learn \n> >from each other by doing this which is one of the great benefits of open source.\n> >\n> >Now that we have a set of requirements the next question to ask is, \n> >\"How doe we prioritize requirements so that we can start designing and \n> >implementing them\"? If this project were a completely new piece of \n> >software I would argue that we iterate on individual features based on \n> >anecdotal information. In essence I would argue an agile approach.\n> >However, most of the companies involved have been operating LBaaS for a \n> >while now. Rackspace, for example, has been operating LBaaS for the \n> >better part of 4 years. We have a clear understanding of what features \n> >our customers want and how to operate at scale. I believe other \n> >operators of LBaaS have the same understanding of their customers and \n> >their operational needs. I guess my main point is that, collectively, \n> >we have data to back up which requirements we should be working on. \n> >That doesn\'t mean we preclude requirements based on anecdotal \n> >information (i.e. \"Our customers are saying they want new shiny feature \n> >X\"). At the end of the day I want to prioritize the community\'s \n> >requirements based on factual data and anecdotal information.\n> >\n> >Assuming requirements are prioritized (which as of today we have a \n> >pretty good idea of these priorities) the next step is to design before \n> >laying down any actual code. I agree with Samuel that pushing the cart \n> >before the horse is a bad idea in this case (and it usually is the case \n> >in software development), especially since we have a pretty clear idea \n> >on what we need to be designing for. I understand that the current code \n> >base has been worked on by many individuals and the work done thus far \n> >is the reason why so many new faces are getting involved. However, we \n> >now have a completely updated set of requirements that the community \n> >has put together and trying to fit the requirements to existing code \n> >may or may not work. In my experience, I would argue that 99% of the \n> >time duct-taping existing code to fit in new requirements results in \n> >buggy software. That being said, I usually don\'t like to rebuild a \n> >project from scratch. If I can I try to refactor as much as possible \n> >first. However, in this case we have a particular set of requirements \n> >that changes the game. Particularly, operator requirements have not been given the attention they deserve.\n> >\n> >I think of Openstack as being cloud software that is meant to operate \n> >at scale and have the necessary operator tools to do so. Otherwise, why \n> >do we have so many companies interested in Openstack if you can\'t \n> >operate a cloud that scales? In the case of LBaaS, user/feature \n> >requirements and operator requirements are not necessarily mutually \n> >exclusive. How you design the system in regards to one set of \n> >requirements affects the design of the system in regards to the other \n> >set of requirements. SSL termination, for example, affects the ability \n> >to scale since it is CPU intensive. As an operator, I need to know how \n> >to provision load balancer instances efficiently so that I\'m not having \n> >to order new hardware more than I have to. With this in mind, I am \n> >assuming that most of us are vendor-agnostic and want to cooperate in \n> >developing an open source driver while letting vendors create their own \n> >drivers. If this is not the case then perhaps a lot of the debates we \n> >have been having are moot since we can separate efforts depending on \n> >what driver we want to work on. The only item of Neutron LBaaS that we \n> >need to have consensus on then is the API (web app, database, messaging \n> >system, etc.). Keep in mind that the API implies what feature/user \n> >requirements are satisfied, but no so much for operator requirements. I \n> >think this is one reason why we have been working on API proposals. \n> >Samuel, thank you for the time you spent on your proposal as we know how much time and effort it takes.\n> >\n> >Because several of us have been spending large amounts of time on API \n> >proposals, and because we can safely assume that most operational \n> >requirements are abstracted into the driver layer I say we continue the \n> >conversation around the different proposals since this is the area we \n> >definitely need consensus on. So far there are three \n> >proposals--Stephen\'s, Rackspace\'s and Eugene\'s. To date, we honestly \n> >haven\'t had an actual discussion on the pros and cons of each proposal. \n> >To give structure to this we here at Rackspace have been going to great \n> >lengths to make sure we have enough tangible documentation in order to \n> >clearly convey our thoughts. We also went to great lengths to satisfy \n> >the user/feature requirements in our API. Here is what we have done:\n> >\n> >- An API specification located here ==> \n> >https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bT\n> >mWy\n> >X\n> >e-zo/edit\n> >- Single API call workflows & multiple API call workflows of each of \n> >the use cases (#1 through #9 for now) from \n> >https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-\n> >mXu\n> >S\n> >INis/edit#heading=h.48fieovwttzg. Our workflows are located here ==>\n> >https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0\n> >- A lightweight proof of concept that is in the works so that people \n> >that need to actually send requests to an API to believe in it can do \n> >so. We will send an update in a few days when this POC is complete.\n> >\n> >In order to fairly compare proposals I think it would be nice if each \n> >proposal give workflows on how their API will operate. This is isn\'t \n> >necessary but I think it will definitely give structure in any \n> >discussions we have when comparing. If others have thoughts on how to \n> >compare the proposals on equal footing then by all means speak up.\n> >\n> >Once we come to a consensus on the API then we can figure out how to \n> >make iterative changes in order to get the API to the consensus state. \n> >That is a separate conversation in my mind. First we need to agree on a \n> >spec without the confines of looking at current implementation.\n> >\n> >\n> >Cheers,\n> >--Jorge\n> >\n> >\n> >P.S. Sorry for the delay in responding to the ML. Just reading them \n> >takes several hours.\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<26B082831A2B1A4783604AB89B9B2C080DF80E98@SINPEX01CL03.citrite.net>',NULL),('<1398961222.2809.36.camel@tvardeman-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 16:20:22',0,'2014-05-01 16:20:22',NULL,'[openstack-dev] [Neutron][LBaaS] Updated Use Cases Assessment and\n Questions','Hello,\n\nI\'ve been going through the 40+ use cases, and I couldn\'t help but\nnotice some additions that are either unclear or not descriptive.\n\nFor ease of reference, I\'ll link the document: \nhttps://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit#\n\nI took a look at most of them in a high-level thought process to use for\nevaluation in feasibility for the Rackspace API proposal, and began\ndocumenting them for purpose of comparison.  However, I\'ve run into some\nissues understanding and/or evaluating them.\n\nOne section of the use-cases come to mind specifically.  Numbers 31\nthrough 39 are not very descriptive.  Many of these don\'t seem like\nuse-cases as much as they seem like feature requests.  Ideally there\nwould be more information, or an example of a problem to solve including\nthe use-case, similar to many of the others.\n\nOn that same note, there are some use-cases I simply don\'t understand,\nbe-it my own naivety, or wording in the use-case.\n\nUse-Case 10:  I assumed this was referring to the source-IP that\naccesses the Load Balancer.  As far as I know the X-Forwarded-For header\nincludes this.  To satisfy this use-case, was there some expectation to\nretrieve this information through an API request?  Also, with the\ntrusted-proxy evaluation, is that being handled by the pool member, or\nwas this in reference to an \"access list\" so-to-speak defined on the\nload balancer?\n\nUse-Case 20:  I do not believe much of this is handled within the LBaaS\nAPI, but with a different service that provides auto-scaling\nfunctionality.  Especially the \"on-the-fly\" updating of properties.\nThis also becomes incredibly difficult when considering TCP session\npersistence when the possible pool member could be removed at any\nautomated time.\n\nUse-Case 25:  I think this one is referring to the functionality of a\n\"draining\" status for a pool member; the pool member will not receive\nany new connections, and will not force any active connection closed.\nIs that the right way to understand that use-case?\n\nUse-Case 26:  Is this functionally wanting something like an \"error\npage\" to come up during the maintenance window?  Also, to accept only\nconnections from a specific set of IPs only during the maintenance\nwindow, one would manually have to create an access list for the load\nbalancer during the time for testing, and then either modify or remove\nit after maintenance is complete.  Does this sound like an accurate\nunderstanding/solution?\n\nUse-Case 37:  I\'m not entirely sure what this one would mean.  I know I\nincluded it in the section that sounded more like features, but I was\nstill curious what this one referred to.  Does this have to do with the\ndesire for auto-scaling?  When a pool member gains a certain threshold\nof connections another pool member is created or chosen to handle the\nnext connection(s) as they come?\n\nPlease feel free to correct me anywhere I\'ve blundered here, and if my\nproposed \"solution\" is inaccurate or not easily understood, I\'d be more\nthan happy to explain in further detail.  Thanks for any help you can\noffer!\n\n-Trevor Vardeman\n\n',NULL,NULL),('<1398962640.2809.48.camel@tvardeman-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 16:44:01',0,'2014-05-01 16:44:01',NULL,'[openstack-dev] [Neutron][LBaaS] RackSpace API review\n (multi-call)','Vijay, I\'m following suit: Replies in line :D\n\nOn Thu, 2014-05-01 at 16:11 +0000, Vijay Venkatachalam wrote:\n> Thanks Trevor. Replies inline!\n> \n> > -----Original Message-----\n> > From: Trevor Vardeman [mailto:trevor.vardeman at RACKSPACE.COM]\n> > Sent: Thursday, May 1, 2014 7:30 PM\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [Neutron][LBaaS] RackSpace API review (multi-\n> > call)\n> > \n> > Vijay,\n> > \n> > Comments in-line, hope I can clear some of this up for you :)\n> > \n> > -Trevor\n> > \n> > On Thu, 2014-05-01 at 13:16 +0000, Vijay Venkatachalam wrote:\n> > > I am expecting to be more active on community on the LBaaS front.\n> > >\n> > > May be reviewing and picking-up a few items to  work as well.\n> > >\n> > > I had a look at the proposal. Seeing Single & Multi-Call approach for\n> > > each workflow makes it easy to understand.\n> > >\n> > > Thanks for the clear documentation, it is welcoming to review :-). I was not\n> > allowed to comment on WorkFlow doc, can you enable comments?\n> > >\n> > > The single-call approach essentially creates the global pool/VIP. Once\n> > VIP/Pool is created using single call, are they reusable in multi-call?\n> > > For example: Can a pool created for HTTP endpoint/loadbalancer be used\n> > in HTTPS endpoint LB where termination occurs as well?\n> > \n> > From what I remember discussing with my team (being a developer under\n> > Jorge\'s umbrella) There is a 1-M relationship between load balancer and\n> > pool.  Also, the protocol is specified on the Load Balancer, not the pool,\n> > meaning you could expose TCP traffic via one Load Balancer to a pool, and\n> > HTTP traffic via another Load Balancer to that same pool.\n> > This is easily modified such\n> > \n> \n> Ok. Thanks! Should there be a separate use case for covering this (If it is not already present)?\n\nThis is already reflected in at least one use-case.  I\'ve been\ndocumenting the \"solutions\" so to speak to many of the use cases with\nregards to the Rackspace API proposal, if you\'d like to see some of\nthose examples (keep in mind they are a WIP) I\'ll provide a link to them\nfor you:  https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0\n\n> \n> > >\n> > > Also, would it be useful to include PUT as a single call? I see PUT only for\n> > POOL not for LB.\n> > > A user who started with single-call  POST, might like to continue to use the\n> > same approach for PUT/update as well.\n> > \n> > On the fifth page of the document found here:\n> > https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZ\n> > DULjG9bTmWyXe-zo/edit\n> > There is a PUT detailed for a Load Balancer.  There should be support for PUT\n> > on any parent object assuming the fields one would update are not read-\n> > only.\n> > \n> \n> My mistake, didn\'t explain properly.\n> I see PUT of loadbalancer containing only loadbalancer properties. \n> I was wondering if it makes sense for PUT of LOADBALANCER to contain \n> pool+members also. Similar to the POST payload.\n\nFor this API proposal, we wanted to enforce the updating of properties\nas single requests to the resource, where the POST context includes\ncreations/attachments of resources to one another.  To update a pool/its\nmembers you would use the \"/pools\" or \"/pools/{pool_id}/members\"\nendpoints accordingly.  Also a POST to\n\"/loadbalancers/{loadbalancer_id}/pools\" will create/attach a pool to\nthe Load Balancer, however PUT would not be supported at this endpoint.\n\n> \n> Also, will delete of loadbalancer  DELETE the pool/vip, if they are no more \n> referenced by another loadbalancer.\n> \n> Or, they have to be cleaned up separately?\n\nFollowing the concept of the \"Neutron port\" in essence \"detaching\"\nrather than removing the references has us leaving the extra pieces\nintact but disconnected from a Load Balancer.  One would delete the Load\nBalancer, and still be able to retrieve the VIP or Pool from their\nroot-resource references.  This would allow someone the ability to\ndelete a specific Load Balancer, and then create an entirely new one\nwhile referencing the original pool and VIP.\n\n> \n> > >\n> > > Thanks,\n> > > Vijay V.\n> > >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<26B082831A2B1A4783604AB89B9B2C080DF80FB4@SINPEX01CL03.citrite.net>',NULL),('<1398965011-sup-5919@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 10:31:04',-25200,'2014-05-01 17:31:04',NULL,'[openstack-dev] [Neutron] SSL VPN Implemenatation','I think you\'d do something like this (Note that I don\'t know off the top\nof my head the barbican CLI or openvpn cli switches... just\npseudo-code):\n\noconf=$(mktemp -d /tmp/openvpnconfig.XXXXXX)\nmount -o tmpfs $oconf size=1M\nbarbican get my-secret-openvpn-conf > $oconf/foo.conf\nopenvpn --config-dir $oconf foo --daemonize\numount $oconf\nrmdir $oconf\n\nExcerpts from Nachi Ueno\'s message of 2014-05-01 10:15:26 -0700:\n> Hi Robert\n> \n> Thank you for your suggestion.\n> so your suggestion is let OpenVPN process download key to memory\n> directly from Babican?\n> \n> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham <robert.clark at hp.com>:\n> > Excuse me interrupting but couldn\'t you treat the key as largely\n> > ephemeral, pull it down from Barbican, start the OpenVPN process and\n> > then purge the key?  It would of course still be resident in the memory\n> > of the OpenVPN process but should otherwise be protected against\n> > filesystem disk-residency issues.\n> >\n> >\n> >> -----Original Message-----\n> >> From: Nachi Ueno [mailto:nachi at ntti3.com]\n> >> Sent: 01 May 2014 17:36\n> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation\n> >>\n> >> Hi Jarret\n> >>\n> >> IMO, Zang point is the issue saving plain private key in the\n> > filesystem for\n> >> OpenVPN.\n> >> Isn\'t this same even if we use Barbican?\n> >>\n> >>\n> >>\n> >>\n> >>\n> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim <jarret.raim at rackspace.com>:\n> >> > Zang mentioned that part of the issue is that the private key has to\n> >> > be stored in the OpenVPN config file. If the config files are\n> >> > generated and can be stored, then storing the whole config file in\n> >> > Barbican protects the private key (and any other settings) without\n> >> > having to try to deliver the key to the OpenVPN endpoint in some\n> > non-\n> >> standard way.\n> >> >\n> >> >\n> >> > Jarret\n> >> >\n> >> > On 4/30/14, 6:08 PM, \"Nachi Ueno\" <nachi at ntti3.com> wrote:\n> >> >\n> >> >>> Jarret\n> >> >>\n> >> >>Thanks!\n> >> >>Currently, the config will be generated on demand by the agent.\n> >> >>What\'s merit storing entire config in the Barbican?\n> >> >>\n> >> >>> Kyle\n> >> >>Thanks!\n> >> >>\n> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery\n> >> <mestery at noironetworks.com>:\n> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno <nachi at ntti3.com>\n> >> wrote:\n> >> >>>> Hi Clint\n> >> >>>>\n> >> >>>> Thank you for your suggestion. Your point get taken :)\n> >> >>>>\n> >> >>>>> Kyle\n> >> >>>> This is also a same discussion for LBaaS Can we discuss this in\n> >> >>>> advanced service meeting?\n> >> >>>>\n> >> >>> Yes! I think we should definitely discuss this in the advanced\n> >> >>> services meeting today. I\'ve added it to the agenda [1].\n> >> >>>\n> >> >>> Thanks,\n> >> >>> Kyle\n> >> >>>\n> >> >>> [1]\n> >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f\n> >> or_\n> >> >>>next\n> >> >>>_meeting\n> >> >>>\n> >> >>>>> Zang\n> >> >>>> Could you join the discussion?\n> >> >>>>\n> >> >>>>\n> >> >>>>\n> >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum <clint at fewbar.com>:\n> >> >>>>> Excerpts from Nachi Ueno\'s message of 2014-04-29 10:58:53 -0700:\n> >> >>>>>> Hi Kyle\n> >> >>>>>>\n> >> >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery\n> >> <mestery at noironetworks.com>:\n> >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno\n> >> <nachi at ntti3.com>\n> >> >>>>>>wrote:\n> >> >>>>>> >> Hi Zang\n> >> >>>>>> >>\n> >> >>>>>> >> Thank you for your contribution on this!\n> >> >>>>>> >> The private key management is what I want to discuss in the\n> >> >>>>>>summit.\n> >> >>>>>> >>\n> >> >>>>>> > Has the idea of using Barbican been discussed before? There\n> > are\n> >> >>>>>>many\n> >> >>>>>> > reasons why using Barbican for this may be better than\n> >> >>>>>> > developing\n> >> >>>>>>key\n> >> >>>>>> > management ourselves.\n> >> >>>>>>\n> >> >>>>>> No, however I\'m +1 for using Barbican. Let\'s discuss this in\n> >> >>>>>> certificate management topic in advanced service session.\n> >> >>>>>>\n> >> >>>>>\n> >> >>>>> Just a suggestion: Don\'t defer that until the summit. Sounds\n> > like\n> >> >>>>>you\'ve  already got some consensus, so you don\'t need the summit\n> >> >>>>>just to rubber  stamp it. I suggest discussing as much as you can\n> >> >>>>>right now on the mailing  list, and using the time at the summit\n> > to\n> >> >>>>>resolve any complicated issues  including any \"a or b\" things\n> > that\n> >> >>>>>need crowd-sourced idea making. You  can also use the summit time\n> >> >>>>>to communicate your requirements to the  Barbican developers.\n> >> >>>>>\n> >> >>>>> Point is: just because you\'ll have face time, doesn\'t mean you\n> >> >>>>> should use it for what can be done via the mailing list.\n> >> >>>>>\n> >> >>>>> _______________________________________________\n> >> >>>>> OpenStack-dev mailing list\n> >> >>>>> OpenStack-dev at lists.openstack.org\n> >> >>>>>\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >>>>\n> >> >>>> _______________________________________________\n> >> >>>> OpenStack-dev mailing list\n> >> >>>> OpenStack-dev at lists.openstack.org\n> >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >>>\n> >> >>> _______________________________________________\n> >> >>> OpenStack-dev mailing list\n> >> >>> OpenStack-dev at lists.openstack.org\n> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >>\n> >> >>_______________________________________________\n> >> >>OpenStack-dev mailing list\n> >> >>OpenStack-dev at lists.openstack.org\n> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n\n\n','<CABJepwia0og74ndrmrGKPPfz0freTs+6iVx01d+hiGevhjodzA@mail.gmail.com>',NULL),('<1398970678.426.1367129133130.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:05:33',0,'2013-04-28 06:05:33',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python27-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-cinder-python27-stable-grizzly/18/>\n\n\n\n','<2144240297.366.1367042667696.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1398971247.2761.0.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 15:07:27',-14400,'2014-05-01 19:07:27',NULL,'[openstack-dev] [nova] Proposal: remove the server groups\n feature','On Thu, 2014-05-01 at 20:49 +0800, Jay Lau wrote:\n> Jay Pipes and all, I\'m planning to merge this topic to\n> http://junodesignsummit.sched.org/event/77801877aa42b595f14ae8b020cd1999 after some discussion in this week\'s Gantt IRC meeting, hope it is OK.\n\nI\'ll be there :)\n\nThanks!\n-jay\n\n> \n> \n> 2014-05-01 19:56 GMT+08:00 Day, Phil <philip.day at hp.com>:\n>         > >\n>         > > In the original API there was a way to remove members from\n>         the group.\n>         > > This didn\'t make it into the code that was submitted.\n>         >\n>         > Well, it didn\'t make it in because it was broken. If you add\n>         an instance to a\n>         > group after it\'s running, a migration may need to take place\n>         in order to keep\n>         > the semantics of the group. That means that for a while the\n>         policy will be\n>         > being violated, and if we can\'t migrate the instance\n>         somewhere to satisfy the\n>         > policy then we need to either drop it back out, or be in\n>         violation. Either some\n>         > additional states (such as being queued for inclusion in a\n>         group, etc) may be\n>         > required, or some additional footnotes on what it means to\n>         be in a group\n>         > might have to be made.\n>         >\n>         > It was for the above reasons, IIRC, that we decided to leave\n>         that bit out since\n>         > the semantics and consequences clearly hadn\'t been fully\n>         thought-out.\n>         > Obviously they can be addressed, but I fear the result will\n>         be ... ugly. I think\n>         > there\'s a definite possibility that leaving out those\n>         dynamic functions will look\n>         > more desirable than an actual implementation.\n>         >\n>         \n>         If we look at a server group as a general contained or\n>         servers, that may have an attribute that expresses scheduling\n>         policy, then it doesn\'t seem to ugly to restrict the\n>         conditions on which an add is allowed to only those that don\'t\n>         break the (optional) policy.    Wouldn\'t even have to go to\n>         the scheduler to work this out.\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> -- \n> Thanks,\n> \n> \n> Jay\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAFyztAHtgNT69RWP8T49jWF9Cv05UqPSFD7uciu6+XGdvn_i2A@mail.gmail.com>',NULL),('<1398971351.2724.46.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 14:09:11',-18000,'2014-05-01 19:09:11',NULL,'[openstack-dev] [infra][neutron]SystemExit() vs sys.exit()?','On Thu, 2014-05-01 at 18:41 +0000, Paul Michali (pcm) wrote:\n> So, I tried to reproduce, but I actually see the same results with\n> both of these. However, they both show the issue I was hitting,\n> namely, I got no information on where the failure was located:\n\nSo, this is pretty much by design.  A SystemExit extends BaseException,\nrather than Exception.  The tests will catch Exception, but not\ntypically BaseException, as you generally want things like ^C to work\n(raises a different BaseException).  So, your tests that might possibly\ntrigger a SystemExit (or sys.exit()) that you don\'t want to actually\nexit from must either explicitly catch the SystemExit or?assuming the\ncode uses sys.exit()?must mock sys.exit() to inhibit the normal exit\nbehavior.\n\n(Also, because SystemExit is the exception that is usually raised for a\nnormal exit condition, the traceback would not typically be printed, as\nthat could confuse users; no one expects a successfully executed script\nto print a traceback, after all :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<DBE940EE-C5A0-4090-9419-3B36B934CFA9@cisco.com>',NULL),('<1398971420-sup-1564@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 12:22:21',-25200,'2014-05-01 19:22:21',NULL,'[openstack-dev] [Neutron] SSL VPN Implemenatation','Excerpts from Nachi Ueno\'s message of 2014-05-01 12:04:23 -0700:\n> Ah I got it now!\n> so even if we get stolen HDD, we can keep password safe.\n> \n> However, I\'m still not sure why this is more secure..\n> anyway, the ID/PW to access barbican will be written in neutron.conf, right?\n> \n\nYes. However, you can surround the secret in policies. You\'ll have an\naudit trail of when and where it was accessed, and you can even restrict\naccess, so that out of band you have to open up access with barbican.\n\nSo while the server may have access, that access is now audited and\nlimited by policy, instead of just being dependent on the security\nmeasures you can take to protect a file.\n\n> Furthermore,  ID/PW for mysql will be written in conf file..\n> so if we can\'t trust unix file system protection, there is no security\n> in OpenStack.\n\nThe ID/PW for mysql only grants you access to mysql for as long as that\nid/pw are enabled for access. However, the encryption keys for OpenVPN\nwill grant any passive listener access for as long as they keep any\nsniffed traffic. They\'ll also grant an attacker the ability to MITM\ntraffic between peers.\n\nSo when an encryption key has been accessed, from where, etc, is quite\na bit more crucial than knowing when a username/password combo have\nbeen accessed.\n\nProducing a trustworthy audit log for access to /etc/neutron/neutron.conf\nis a lot harder than producing an audit log for a REST API.\n\nSo it isn\'t so much that file system permissions aren\'t enough, it is\nthat file system observability is expensive.\n\nNote that at some point there was a POC to have a FUSE driver backed by\nBarbican called \'Postern\' I think. That would make these discussions a\nlot simpler. :)\n\n> \n> 2014-05-01 10:31 GMT-07:00 Clint Byrum <clint at fewbar.com>:\n> > I think you\'d do something like this (Note that I don\'t know off the top\n> > of my head the barbican CLI or openvpn cli switches... just\n> > pseudo-code):\n> >\n> > oconf=$(mktemp -d /tmp/openvpnconfig.XXXXXX)\n> > mount -o tmpfs $oconf size=1M\n> > barbican get my-secret-openvpn-conf > $oconf/foo.conf\n> > openvpn --config-dir $oconf foo --daemonize\n> > umount $oconf\n> > rmdir $oconf\n> >\n> > Excerpts from Nachi Ueno\'s message of 2014-05-01 10:15:26 -0700:\n> >> Hi Robert\n> >>\n> >> Thank you for your suggestion.\n> >> so your suggestion is let OpenVPN process download key to memory\n> >> directly from Babican?\n> >>\n> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham <robert.clark at hp.com>:\n> >> > Excuse me interrupting but couldn\'t you treat the key as largely\n> >> > ephemeral, pull it down from Barbican, start the OpenVPN process and\n> >> > then purge the key?  It would of course still be resident in the memory\n> >> > of the OpenVPN process but should otherwise be protected against\n> >> > filesystem disk-residency issues.\n> >> >\n> >> >\n> >> >> -----Original Message-----\n> >> >> From: Nachi Ueno [mailto:nachi at ntti3.com]\n> >> >> Sent: 01 May 2014 17:36\n> >> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation\n> >> >>\n> >> >> Hi Jarret\n> >> >>\n> >> >> IMO, Zang point is the issue saving plain private key in the\n> >> > filesystem for\n> >> >> OpenVPN.\n> >> >> Isn\'t this same even if we use Barbican?\n> >> >>\n> >> >>\n> >> >>\n> >> >>\n> >> >>\n> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim <jarret.raim at rackspace.com>:\n> >> >> > Zang mentioned that part of the issue is that the private key has to\n> >> >> > be stored in the OpenVPN config file. If the config files are\n> >> >> > generated and can be stored, then storing the whole config file in\n> >> >> > Barbican protects the private key (and any other settings) without\n> >> >> > having to try to deliver the key to the OpenVPN endpoint in some\n> >> > non-\n> >> >> standard way.\n> >> >> >\n> >> >> >\n> >> >> > Jarret\n> >> >> >\n> >> >> > On 4/30/14, 6:08 PM, \"Nachi Ueno\" <nachi at ntti3.com> wrote:\n> >> >> >\n> >> >> >>> Jarret\n> >> >> >>\n> >> >> >>Thanks!\n> >> >> >>Currently, the config will be generated on demand by the agent.\n> >> >> >>What\'s merit storing entire config in the Barbican?\n> >> >> >>\n> >> >> >>> Kyle\n> >> >> >>Thanks!\n> >> >> >>\n> >> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery\n> >> >> <mestery at noironetworks.com>:\n> >> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno <nachi at ntti3.com>\n> >> >> wrote:\n> >> >> >>>> Hi Clint\n> >> >> >>>>\n> >> >> >>>> Thank you for your suggestion. Your point get taken :)\n> >> >> >>>>\n> >> >> >>>>> Kyle\n> >> >> >>>> This is also a same discussion for LBaaS Can we discuss this in\n> >> >> >>>> advanced service meeting?\n> >> >> >>>>\n> >> >> >>> Yes! I think we should definitely discuss this in the advanced\n> >> >> >>> services meeting today. I\'ve added it to the agenda [1].\n> >> >> >>>\n> >> >> >>> Thanks,\n> >> >> >>> Kyle\n> >> >> >>>\n> >> >> >>> [1]\n> >> >> >>>https://wiki.openstack.org/wiki/Meetings/AdvancedServices#Agenda_f\n> >> >> or_\n> >> >> >>>next\n> >> >> >>>_meeting\n> >> >> >>>\n> >> >> >>>>> Zang\n> >> >> >>>> Could you join the discussion?\n> >> >> >>>>\n> >> >> >>>>\n> >> >> >>>>\n> >> >> >>>> 2014-04-29 15:48 GMT-07:00 Clint Byrum <clint at fewbar.com>:\n> >> >> >>>>> Excerpts from Nachi Ueno\'s message of 2014-04-29 10:58:53 -0700:\n> >> >> >>>>>> Hi Kyle\n> >> >> >>>>>>\n> >> >> >>>>>> 2014-04-29 10:52 GMT-07:00 Kyle Mestery\n> >> >> <mestery at noironetworks.com>:\n> >> >> >>>>>> > On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno\n> >> >> <nachi at ntti3.com>\n> >> >> >>>>>>wrote:\n> >> >> >>>>>> >> Hi Zang\n> >> >> >>>>>> >>\n> >> >> >>>>>> >> Thank you for your contribution on this!\n> >> >> >>>>>> >> The private key management is what I want to discuss in the\n> >> >> >>>>>>summit.\n> >> >> >>>>>> >>\n> >> >> >>>>>> > Has the idea of using Barbican been discussed before? There\n> >> > are\n> >> >> >>>>>>many\n> >> >> >>>>>> > reasons why using Barbican for this may be better than\n> >> >> >>>>>> > developing\n> >> >> >>>>>>key\n> >> >> >>>>>> > management ourselves.\n> >> >> >>>>>>\n> >> >> >>>>>> No, however I\'m +1 for using Barbican. Let\'s discuss this in\n> >> >> >>>>>> certificate management topic in advanced service session.\n> >> >> >>>>>>\n> >> >> >>>>>\n> >> >> >>>>> Just a suggestion: Don\'t defer that until the summit. Sounds\n> >> > like\n> >> >> >>>>>you\'ve  already got some consensus, so you don\'t need the summit\n> >> >> >>>>>just to rubber  stamp it. I suggest discussing as much as you can\n> >> >> >>>>>right now on the mailing  list, and using the time at the summit\n> >> > to\n> >> >> >>>>>resolve any complicated issues  including any \"a or b\" things\n> >> > that\n> >> >> >>>>>need crowd-sourced idea making. You  can also use the summit time\n> >> >> >>>>>to communicate your requirements to the  Barbican developers.\n> >> >> >>>>>\n> >> >> >>>>> Point is: just because you\'ll have face time, doesn\'t mean you\n> >> >> >>>>> should use it for what can be done via the mailing list.\n> >> >> >>>>>\n> >> >> >>>>> _______________________________________________\n> >> >> >>>>> OpenStack-dev mailing list\n> >> >> >>>>> OpenStack-dev at lists.openstack.org\n> >> >> >>>>>\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >>>>\n> >> >> >>>> _______________________________________________\n> >> >> >>>> OpenStack-dev mailing list\n> >> >> >>>> OpenStack-dev at lists.openstack.org\n> >> >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >>>\n> >> >> >>> _______________________________________________\n> >> >> >>> OpenStack-dev mailing list\n> >> >> >>> OpenStack-dev at lists.openstack.org\n> >> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >>\n> >> >> >>_______________________________________________\n> >> >> >>OpenStack-dev mailing list\n> >> >> >>OpenStack-dev at lists.openstack.org\n> >> >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >\n> >> >> > _______________________________________________\n> >> >> > OpenStack-dev mailing list\n> >> >> > OpenStack-dev at lists.openstack.org\n> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >> >\n> >> >>\n> >> >> _______________________________________________\n> >> >> OpenStack-dev mailing list\n> >> >> OpenStack-dev at lists.openstack.org\n> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >>\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CABJepwi6-uysWCvqFOH7hDnMQ+6bR+msromYvys+Gw0WwvmWjA@mail.gmail.com>',NULL),('<1398976918.17592.9.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 20:41:58',0,'2014-05-01 20:41:58',NULL,'[openstack-dev] [Neutron][LBaaS] Thoughts on current process','Hi Eugene,\n\nOn Fri, 2014-05-02 at 00:10 +0400, Eugene Nikanorov wrote:\n> Hi,\n> \n> \n> On Thu, May 1, 2014 at 10:46 PM, Jorge Miramontes\n> <jorge.miramontes at rackspace.com> wrote:\n>         Hey Eugene,\n>         \n>         \n>         I think there is a misunderstanding on what iterative\n>         development means to you and me and I want to make sure we are\n>         on the same page. First of all, I\'ll try not to use the term\n>         \"duct-taping\" even though it\'s a widely used term in the\n>         industry. \n> I\'m not against the term itself. \n> It was applied several times to existing code base, apparently without\n> ANY real code analysis.\n> That\'s especially clearly seen because all API proposals so far are\n> focusing on managing the same set of lb primitives.\n> Yes, the proposals introduce some new primitives; yes some attributes\n> and relationships differ from what is in the code. \n> But nothing was proposed so far that would require to completely throw\n> away existing code, not a single requirement.\nJust to make it clear, no one said the existing code base was duct taped\ntogether.  What happened was that you pushed that object model\nimprovements blueprint into the neutron-specs the same time that Stephen\nsent out his API proposal.  This made it seem like that no discussion or\nanalysis of the existing object model was going to take place and verify\nthat the existing object model would work with either of the API\nproposals.  So we were saying that duct-taping the API on top of the\nexistng object model was not a good idea if the existing object model\ndid not fit well.  This would result in more duct-taping and so forth.\nI\'m sure we\'ve all been in a maintenance nightmare where the code is\nduct-taped together and one minor change causes major issues.\n\nWe wanted a discussion to happen on whether the existing object model\nwould work with both API proposals.  That blueprint being pushed to\ngerrit the same time as Stephen mailing out his proposal made it seem\nlike this was not going to happen.  No one ever said the existing code\nwas duct-taped together, and I am sorry you got that impression.\n\nThanks,\nBrandon\n\n\n\n\n\n','<CAJfiwOQL7OeMEOjGQdH5iz2tsOd53zNbeN8nmXPiTP7Azxid5w@mail.gmail.com>',NULL),('<1398977556.12524.8.camel@tvardeman-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-01 20:52:36',0,'2014-05-01 20:52:36',NULL,'[openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction','Hello,\n\nAfter going back through the use-cases to double check some of my\nunderstanding, I realized I didn\'t quite understand the ones I had\nalready answered.  I\'ll use a specific use-case as an example of my\nmisunderstanding here, and hopefully the clarification can be easily\nadapted to the rest of the use-cases that are similar.\n\nUse Case 13:  A project-user has an HTTPS application in which some of\nthe back-end servers serving this application are in the same subnet,\nand others are across the internet, accessible via VPN. He wants this\nHTTPS application to be available to web clients via a single IP\naddress.\n\nIn this use-case, is the Load Balancer going to act as a node in the\nVPN?  What I mean here, is the Load Balancer supposed to establish a\nconnection to this VPN for the client, and simulate itself as a computer\non the VPN?  If this is not the case, wouldn\'t the VPN have a subnet ID,\nand simply be added to a pool during its creation?  If the latter is\naccurate, would this not just be a basic HTTPS Load Balancer creation?\nAfter looking through the VPNaaS API, you would provide a subnet ID to\nthe create VPN service request, and it establishes a VPN on said subnet.\nCouldn\'t this be provided to the Load Balancer pool as its subnet?\n\nForgive me for requiring so much distinction here, but what may be clear\nto the creator of this use-case, it has left me confused.  This same\ntype of clarity would be very helpful across many of the other\nVPN-related use-cases.  Thanks again!\n\n-Trevor\n\n',NULL,NULL),('<1399041167.3416.5.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-02 10:32:47',-14400,'2014-05-02 14:32:47',NULL,'[openstack-dev] Monitoring as a Service','On Thu, 2014-05-01 at 17:17 -0400, Alexandre Viau wrote:\n> Hello Everyone!\n> \n> My name is Alexandre Viau from Savoir-Faire Linux.\n> \n> We have submited a Monitoring as a Service blueprint and need feedback.\n> \n> Problem to solve: Ceilometer\'s purpose is to track and *measure/meter* usage information collected from OpenStack components (originally for billing). While Ceilometer is usefull for the cloud operators and infrastructure metering, it is not a *monitoring* solution for the tenants and their services/applications running in the cloud because it does not allow for service/application-level monitoring and it ignores detailed and precise guest system metrics.\n> \n> Proposed solution: We would like to add Monitoring as a Service to Openstack\n> \n> Just like Rackspace\'s Cloud monitoring, the new monitoring service - lets call it OpenStackMonitor for now -  would let users/tenants keep track of their ressources on the cloud and receive instant notifications when they require attention.\n> \n> This RESTful API would enable users to create multiple monitors with predefined checks, such as PING, CPU usage, HTTPS and SMTP or custom checks performed by a Monitoring Agent on the instance they want to monitor.\n> \n> Predefined checks such as CPU and disk usage could be polled from Ceilometer. Other predefined checks would be performed by the new monitoring service itself. Checks such as PING could be flagged to be performed from multiple sites.\n> \n> Custom checks would be performed by an optional Monitoring Agent. Their results would be polled by the monitoring service and stored in Ceilometer.\n> \n> If you wish to collaborate, feel free to contact me at alexandre.viau at savoirfairelinux.com\n> The blueprint is available here: https://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-service\n\nHi Alexandre,\n\nThe openstack-ci project is for the upstream continuous integration\nproject, not ceilometer. I think you meant, perhaps, to create the\nblueprint in the ceilometer project, which would be here:\n\nhttp://blueprints.launchpad.net/ceilometer\n\nBest,\n-jay\n\n\n\n','<101839964.342932.1398979032532.JavaMail.root@mail>',NULL),('<1399043596.20241154.1383688682476.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-05 16:58:02',-18000,'2013-11-05 21:58:02',NULL,'[openstack-dev] A Tool for Making OpenStack Log Reading a Bit Easier','Hello All,\nThe other day, I was reading through a debug-level OpenStack log, and came to the realization that reading OpenStack debug-level logs was difficult, to say the least -- they can be very busy, and it is hard to quickly filter out relevant information.  Thus, I wrote a little Perl script to make reading dense debug-level logs a bit easier: https://github.com/DirectXMan12/os_log_prettifier.  I figured that I\'d share it with other people.  Basically, the script highlights certain key details using color and bolding (via ANSI control codes), and can filter lines based on subject (in the form of \'x.y.z\') or message type, using regular expressions.  I hope people find it useful!\n\nBest Regards,\nSolly Ross\n\n\n','<1149957553.20223657.1383688381674.JavaMail.root@redhat.com>',NULL),('<1399059653.3416.14.camel@sleepy>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-05-02 15:40:53',-14400,'2014-05-02 19:40:53',NULL,'[Openstack-operators] [RFC] Logging Guidelines','On Wed, 2014-04-30 at 17:04 -0400, matt wrote:\n> Basically I love the blueprints thrust.\n> \n> I\'d love to see a real spec for how to construct a proper openstack\n> logging event, and how to place those events into the message queue\n> for consumption.  Something that\'s more engineering spec then proverb.\n\nA log message is not the same as an RPC API message or a notification\nevent that gets sent out to a message queue. The inconsistency and\nsloppiness of the former is what Sean\'s blueprint addresses. The latter,\nIMO, has been very much standardized, and in the last couple releases,\nversioned, in order to provide rolling upgrade capabilities and provide\nstructure to the format and payload of RPC API messages.\n\n> That being said, a couple of things I\'d like to see that I didn\'t see\n> in there just yet.  ( mind you i may have missed it, i am human after\n> all )\n> \n> 1.  Standardized Metadata \n> \n> Being able to parse a log for content with a known metadata structure\n> would be very helpful for folks planning on consuming logs in adaptive\n> orchestration scenarios.\n\nSure, this is certainly a good goal. What do you propose are some\nconcreate changes that we could make here?\n\n> 2.  Message Service Etiquette\n> \n> I think the \'logged events need to make sense\' starts to get into the\n> idea of a common logging etiquette.  But there\'s the logical aspect\n> beyond the aesthetic.  I assume we\'ll probably want to force rate\n> limiting of logging should something start getting noisy.  I feel like\n> that\'s something that should be done before hitting the message bus\n> and creating noise there.\n\nNot entirely sure what you\'re referring to here as \"the message bus\".\nAre you referring to something like rsyslog or syslog-ng and centralized\nlog file collection?\n\nRegarding rate limiting of log messages, that\'s something that is\ntypically configured in configuration management/deployment systems via\nstandard Python log config and oftentimes depends on the underlying log\nservice configuration (i.e. syslog config)\n\n>   Specifically I am thinking of the repetition of messages being\n> condensed on the app side before being pushed to the bus.\n\nThere\'s certainly lots of room for improvement in getting rid of\nworthless debug-level message bloat, but I think Sean\'s proposal of a\nDEBUG2 level gets to the heart of this problem. Thoughts?\n\nBest,\n-jay\n\n> This of course calls into question should this ettiquette be different\n> for a WARN versus an ERROR?\n> \n> \n> 3.  Audit Log Handling\n\n> This is probably outside scope.  Feel free to declare it so.  But once\n> we start talking audit logs we need to discuss what can and cannot be\n> done to an event before it gets signed ( yeah that would need to be\n> discussed too ) and handed off to the audit log pipeline ( that\n> doesn\'t exist yet ).\n> \n> \n> -Matt\n> \n> \n> \n> On Wed, Apr 30, 2014 at 4:39 PM, Sean Dague <sean at dague.net> wrote:\n>         I\'m trying to work up some drafts of logging guidelines that\n>         we can get\n>         agreement on and hopefully get all openstack projects to\n>         implement over\n>         time. In advance of the Juno summit I\'d like to get feedback\n>         on drafts\n>         via the nova-specs process.\n>         \n>         The draft review is here -\n>         https://review.openstack.org/#/c/91446/\n>         \n>         Anyone is welcome to log into gerrit and provide feedback on\n>         what\'s\n>         there, including general comments on areas we should address\n>         which\n>         aren\'t there. I\'ll try to blend the feedback I get this week\n>         for at\n>         least one, if not 2 follow up drafts prior to summit.\n>         \n>         There is not a specific summit session for this, however if\n>         we\'ve got a\n>         good working doc before the summit I was hoping we could bang\n>         out any\n>         sticky parts ad-hoc while there.\n>         \n>                 -Sean\n>         \n>         --\n>         Sean Dague\n>         http://dague.net\n>         \n>         \n>         _______________________________________________\n>         OpenStack-operators mailing list\n>         OpenStack-operators at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         \n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<CAP_sDUHAg0WqW-Oy_dGijZspYjtQeRZshU1uXuTKRJoH=dxvug@mail.gmail.com>',NULL),('<1399070113.14238.2.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-02 17:35:13',-18000,'2014-05-02 22:35:13',NULL,'[openstack-dev] [Cinder] About store faults info for volumes','On Wed, 2014-04-30 at 10:20 -0700, Mike Perez wrote:\n> On 06:49 Wed 30 Apr     , Zhangleiqiang (Trump) wrote:\n> > Hi stackers:\n> > \n> > 	I found when a instance status become \"error\", I will see the detailed fault info at times when I \"show\" the detail of Instance.  And it is very convenient for me to find the failed reason. Indeed, there is a \"nova.instance_faults\" which stores the fault info.\n> > 	\n> > 	Maybe it is helpful for users if Cinder also introduces the similar mechanism. Any advice?\n> > \n> > \n> > ----------\n> > zhangleiqiang (Trump)\n> > \n> > Best Regards\n> \n> There are some discussions that started a couple of weeks ago about using sub\n> states like Nova to know more clearly what happened when a volume is in an\n> \'error\' state. Unfortunately I\'m not sure if that\'ll be in a formal session at\n> the summit, but it\'ll definitely be discussed while we have the team together.\n> Maybe John Griffith can comment since he\'s approving the sessions.\n> \n\nI hope there is a plan to discuss this.  I have in my meeting notes from\nthe 4/16 Cinder meeting that there is going to be a summit session.\n\nIf that is forgotten we should at least plan to have an informal\ndiscussion about it at some point.  I\'ll by a round of drinks if\nnecessary.  :-)\n\nJay\nFreenode:  JungleboyJ\n\n\n\n','<20140430172027.GA29903@gmail.com>',NULL),('<1399070402.14238.5.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-02 17:40:02',-18000,'2014-05-02 22:40:02',NULL,'[openstack-dev] [cinder][globalization] Need input on how to\n proceed .','Thanks for the input Duncan.\n\nThe removal of the debug logs is really a separate issue.  I was just\nhoping to reduce the number of patches that would touch a large number\nof files.  As we are thinking through this though, it really is a\nseparate change so it is best to do separate patches.\n\nOn a related note, we shouldn\'t be taking changes that have debug\nmessages translated if we are moving forward with removing translation\nof debug messages.\n\nJay\n\nOn Thu, 2014-05-01 at 16:41 +0100, Duncan Thomas wrote:\n> That sounds like a sensible way forward, yes.\n> \n> If the dependency is not need, then great, makes review and merge even easier.\n> \n> Thanks\n> \n> On 28 April 2014 17:03, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:\n> > Duncan,\n> >\n> > Thanks for the response.  Have some additional thoughts, in-line, below:\n> >\n> >\n> > On Mon, 2014-04-28 at 12:15 +0100, Duncan Thomas wrote:\n> >> Two separate patches, or even two chains of separate patches, will\n> >> make reviewing and more importantly (hopefully temporary) backouts\n> >> easier. It will also reduce the number of merge conflicts, which are\n> >> still likely to be substantial.\n> >\n> > True, I suppose we need to keep in mind the fact that we might want to\n> > make this be easy to back-out in the future.  Hopefully it isn\'t an\n> > issue this time around though.\n> >\n> >> There\'s no benefit at all to all of this being done in one patch, and\n> >> substantial costs. Doing the conversion by sections seems like the way\n> >> forward.\n> >\n> > So, let me propose a different process here.  Handling the i18n and\n> > removal of debug separately instead.  First, propose one patch that will\n> > add the explicit import of \'_\' to all files.  There will be a lot of\n> > files touched, but they all will be 1 liners.  Then make the patch for\n> > the re-enablement of lazy tanslation a second patch that is dependent\n> > upon the first patch.\n> >\n> > Then handle removal of _() from DEBUG logs as a separate issue once the\n> > one above has merged.  For that change do it in multiple patches divided\n> > by section.  Make the sections be the top level directories under\n> > cinder/ ?  Does that sound like a reasonable plan?\n> >\n> >>\n> >> Doing both around the same time (maybe as dependant patches) seems reasonable\n> >>\n> >\n> > As I think about it, I don\'t know that the debug translation removal\n> > needs to be dependent, but we could work it out that way if you feel\n> > that is important.\n> >\n> > Let me know what you think.\n> >\n> > Thanks!\n> >\n> >> On 27 April 2014 00:20, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:\n> >> > All,\n> >> >\n> >> > I am looking for feedback on how to complete implementation of i18n\n> >> > support for Cinder.  I need to open a new BluePrint for Juno as soon as\n> >> > the cinder-specs process is available.  In the mean time I would like to\n> >> > start working on this and need feedback on the scope I should undertake\n> >> > with this.\n> >> >\n> >> > First, the majority of the code for i18n support went in with Icehouse.\n> >> > There is just a small change that is needed to actually enable Lazy\n> >> > Translation again.  I want to get this enabled as soon as possible to\n> >> > get plenty of runtime on the code for Icehouse.\n> >> >\n> >> > The second change is to add an explicit export for \'_\' to all of our\n> >> > files to be consistent with other projects. [1]  This is also the safer\n> >> > way to implement i18n.  My plan is to integrate the change as part of\n> >> > the i18n work.  Unfortunately this will touch many of the files in\n> >> > Cinder.\n> >> >\n> >> > Given that fact, this brings me to the item I need feedback upon.  It\n> >> > appears that Nova is moving forward with the plan to remove translation\n> >> > of debug messages as there was a recent patch submitted to enable a\n> >> > check for translated DEBUG messages.  Given that fact, would it be an\n> >> > appropriate time, while adding the explicit import of \'_\' to also remove\n> >> > translation of debug messages.  It is going to make the commit for\n> >> > enabling Lazy Translation much bigger, but it would also take out\n> >> > several work items that need to be addressed at once.  I am willing to\n> >> > undertake the effort if I have support for the changes.\n> >> >\n> >> > Please let me know your thoughts.\n> >> >\n> >> > Thanks!2]\n> >> > Jay\n> >> > (jungleboyj on freenode)\n> >> >\n> >> > [1] https://bugs.launchpad.net/cinder/+bug/1306275\n> >> >\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >>\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n\n','<CAOyZ2aEy0-AZSoSHN+9D1ARuomyGSqQfA+yq0m0r2Z6xqU23VA@mail.gmail.com>',NULL),('<1399121582.24585.10.camel@verso>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-05-03 07:53:02',-18000,'2014-05-03 12:53:02',NULL,'[Openstack-docs] Switch to itstool for docs translation?','Hi all,\n\nI\'ve been working on switching the docs translation infrastructure over\nto itstool. This affects openstack-manuals, operations-guide, and\napi-site. The current tools are based on xml2po, but they don\'t call\nxml2po directly. Instead, they import xml2po and mess around with its\ninternals to get some custom behavior.\n\nitstool is designed to handle custom behavior with rules from the W3C\nInternationalization Tag Set (ITS). You can see the ITS I put together\nso far here:\n\nhttps://review.openstack.org/#/c/91869/3/os_doc_tools/resources/openstack.its,unified\n\nUsing ITS also allows us to do local ITS attributes to override the\nbehavior for specific elements. See a simple example here:\n\nhttps://review.openstack.org/#/c/91872/1/api-quick-start/src/docbkx/api-quick-start-intro.xml,unified\n\nMost messages in the PO files will be the same. The one big difference\nwill be in how placeholders are done when there\'s a block-level element\ninside a block-level element (a practice I discourage anyway).\n\nBlueprint and some patches:\n\nhttps://blueprints.launchpad.net/openstack-manuals/+spec/itstool-for-docs\nhttps://review.openstack.org/#/q/topic:bp/itstool-for-docs,n,z\n\nI\'d like to get input from translators, as well as any other docs folks\nwho\'ve worked on this. Most of the document translations are incomplete\nanyway, but it would nevertheless be best to do this at the beginning of\na release cycle.\n\n--\nShaun\n\n\n\n\n',NULL,NULL),('<1399243060.2444.6.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-04 22:37:38',0,'2014-05-04 22:37:38',NULL,'[openstack-dev] Regarding Barbican and deletes [from RE:\n [Neutron][LBaaS]User Stories and sruvey]','Hello John,\n\nIs there anyway (or any plans to) allow a user to register a secret as\nbeing used by another service so that barbican will disallow deleting\n(or make it so that its harder to delete, and make the user aware its\nbeing used by what services)?\n\nThanks,\nBrandon Logan\n\nOn Sun, 2014-05-04 at 21:24 +0000, John Wood wrote:\n> Hello Stephen, \n> \n> \n> I just wanted to comment that Barbican supports four roles per this\n> wiki [1], and only one of them (the admin role) can delete secrets.\n> That might reduce the chance that someone will delete secrets out from\n> under your workflows.\n> \n> \n> [1]\n> = https://github.com/cloudkeep/barbican/wiki/Role-Based-Access-Control\n> \n> \n> Thanks,\n> John\n> \n> \n> \n> ______________________________________________________________________\n> From: Stephen Balukoff [sbalukoff at bluebox.net]\n> Sent: Friday, May 02, 2014 9:26 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey\n> \n> \n> \n> Hi Carlos! \n> \n> \n> Comments in-line:\n> \n> \n> On Thu, May 1, 2014 at 7:24 PM, Carlos Garza\n> <carlos.garza at rackspace.com> wrote:\n>              Balukoff I\'m liking your API spec so far but can you\n>         elaborate on what this loadbalancer object you refer to is. on\n>         page You declare its immutable and refer to it like an actual\n>         primitive object yet I don\'t  \n>         see a schema for it. I see loadbalancer_id in the vip request\n>         that reference. The top part of the doc declares a\n>         loadbalancer is is the first object created according to the\n>         definition in the glossary.\n>         https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer where it is defined as the root Object that is first created or can be fully populated but in you API proposal it looks like the vip object is the created top level primitive with flavor attribute is apart of a VIP. Are you intending to rename what we call a loadbalancer to a VIP? Could you provide a work flow of a created loadbalancer. It looks good either way.\n> \n> \n> I interpret the part of the definition saying:\n> \n> \n>  \"An object that represent a logical load balancer that may have\n> multiple resources such as Vips, Pools, Members, etc. Loadbalancer is\n> a root object in the meaning described above. \"\n> \n> \n> ...to mean that a load balancer is a container for all of the above\n> primitives (VIPS, Listeners, Pools, Members, etc.) This is analogous\n> to a physical device, though it doesn\'t necessarily need to be a\n> physical device (it could be a process on the neutron controller, or\n> it could be a whole grouping of physical devices that work together to\n> serve a singular purpose). I included it in my API document as a\n> \"placeholder\" of sorts to signify how the User API we\'re defining\n> might interface with an Operator / Management API we have yet to\n> define. Mostly, I was trying to capture the idea that different VIPs\n> might have different \"flavors\" defined by the operator that\n> essentially constitute different load balancing products that the\n> operator makes available to the user, as well as the idea that VIPs\n> probably exist in logical groupings within the load balancing\n> infrastructure somehow. For certain kinds of users, colocation or\n> apolocation of VIPs within these groupings of load balancing\n> infrastructure is important.  (See use cases 11 and 12 in the use\n> cases document for a couple examples we see with some regularity.)\n> \n> \n> The API I\'ve proposed includes no notion of how to create a \'load\n> balancer\' in this sense because this is primarily an operator concern,\n> and we\'ve yet to have an in-depth discussion of the nitty-gritty\n> details of operator concerns. Rather, my API assumes that \"somehow\n> load balancers exist\" and takes it from there.\n> \n> \n> In any case, we can remove the notion of this kind of \'load balancer\'\n> from my API proposal for evaluation (since it doesn\'t really affect\n> much for the user), and potentially add something like it back in\n> later when we start to talk more in-depth about operator concerns.\n>  \n>         Is it cool if we rename ca_certificate_id to client_ca or\n>         client_ca_certificate to make it clear the purpose of the CA\n>         is to snub clients. Later on if we need to do encryption to\n>         back end pool members that have x509s signed by their own CA\n>         we can then use a parameter like reencryption_ca_certificate.\n> \n> \n> Yep! I\'m all for names that make concepts more obvious and/or remove\n> confusion from the conversation. :)\n>  \n>         Consider the following cases.\n>         \n>         \n>         The user wants SSL_ID based persistence on an HTTPS\n>         LoadBalancer where the loadbalancer does not know the key or\n>         cert but has access to the unencrypted RFC5246: 7.4.1.2\n>         uncrypted Session ID\n>         to identify persistence to the back end HTTPS pool member?\n>         \n>         \n>         On the pool side of the loadbalaancer can a loadbalancer still\n>         encrypt if no ca_certificate_id or client_certificate_id is\n>         present? How would they signal to the api that they extend to\n>         encrypt with out host name validation or even vert validation\n>         at all. Not sure why they would want to other then they don\'t\n>         feel the need to pay for certs on their backend nodes or worse\n>         yes pay for a signing cert.\n> \n> \n> No. If the load balancer didn\'t decrypt the SSL session with the web\n> client on the front-end, then it makes no sense to try to re-encrypt\n> on the back end. Futher, it also makes no sense for the load balancer\n> to attempt verification of the back-end members\' server certificates.\n> \n> \n> So, if you\'re asking whether those attributes only make sense when\n> decrypting the SSL session on the front end the answer is: yes.  For\n> all intents and purposes, not decrypting on the front end means that\n> the session is essentially treated like a raw TCP session to the back\n> end, with the slight difference that the load balancer can see the\n> Session ID in order to do session persistence properly.\n> \n> \n> Note that my API proposal doesn\'t yet include a flag to indicate\n> whether the load balancer should attempt decryption / re-encryption.\n> Part of this is because I wasn\'t aware of this form of session\n> persistence and therefore thought a non-decrypted HTTPS configuration\n> would look identical to a raw TCP configuration...  However, even\n> without this flag the notion of whether to decrypt can be determined\n> implicitly like so:\n>       * If the listener protocol is HTTPS and there is no\n>         default_server_certificate_id, then the load balancer should\n>         treat the connection like a TCP session and not attempt to\n>         decrypt, re-encrypt or verify client or server certificates\n>         anywhere.\n>       * If the above point is true, and the session persistence\n>         attribute on the pool is set to \'SSL_SESSION_ID\', then the\n>         load balancer should try to use the RFC5246: 7.4.1.2 uncrypted\n>         Session ID information for persistence.\n> If people think it\'s still worthwhile to have the flag (so users can\n> easily toggle on and off decryption on the listener), it would be\n> trivial to add this attribute to the Listener object.  What do y\'all\n> think?\n>  \n>         The user feels secure on their network and wants SSL\n>         termination at the loadbalancer so the loadbalancer has the\n>         Cert and Key and extends to use plain old HTTP to the pool\n>         members with some headers injected. What would the protocol on\n>         the listener be \"HTTPS\" and would placing a CERT and KEY imply\n>         deception should happen.\n> \n> \n> Yes, the protocol on the listener would be HTTPS still. I\'m not sure\n> what you mean by \"placing a CERT and KEY\". Are you talking about\n> within the HTTP headers?\n>  \n>         Also I\'ve been burned in an earlier project when I started\n>         noticing some CA\'s were using ECDSA certs instead of RSA?\n>         should we take non RSA x509s into account as well? Right now\n>         it looks like the API assumes everything is RSA.\n> \n> \n> Yeah, the API does assume everything is RSA right now. I\'ve never been\n> handed ECDSA certs before-- can they be converted? In any case, if we\n> want to natively support different certificate types, this can be done\n> by adding a \'certificate_type\' attribute to the TLS_Certificate\n> object, and presumably some detection logic when the user uploads a\n> new cert.\n> \n> \n> Oh! One other thing: I\'ve had a little bit of time to get an overview\n> of barbican. From what I can tell, their main purpose is to provide a\n> \"secure\" storage engine for storing any kind of sensitive information\n> (not just RSA private keys or what have you).  I\'m all for using this\n> to store private keys instead of inventing our own system here, as I\n> think they\'ll be able to do a better job in general of maintaining the\n> security of the secrets they store since that\'s the whole purpose of\n> the project. (I think it\'s still fine for us to store public\n> certificates sans their private keys ourselves since that\'s... well,\n> public information.)\n> \n> \n> Note that using barbican this way does introduce a couple other\n> failure scenarios that we\'ll need to worry about:  Specifically,\n> because the user is capable of deleting or changing private key data\n> outside of the workflow or knowledge of the LBaaS API, this means that\n> we can run into scenarios where the user wants to push a change, but\n> the private key data might be unavailable. This can break all kinds of\n> stuff, (especially around automated tasks having to do with\n> orchestration and auto-scaling). So... we need to carefully consider\n> how to handle this failure scenario if we\'re going to use Barbican.\n> \n> \n> Thanks,\n> Stephen\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<49F5BF8205841548AB38409969C7AB3F9CCD7D53@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1399305640-sup-281@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 09:28:58',-25200,'2014-05-05 16:28:58',NULL,'[openstack-dev] [Nova][Heat] Custom Nova Flavor creation\n	through Heat (pt.2)','Excerpts from Solly Ross\'s message of 2014-05-05 08:23:41 -0700:\n> Just to expand a bit on this, flavors are supposed to be the lowest level of granularity,\n> and the general idea is to round to the nearest flavor (so if you have a VM that requires\n> 3GB of RAM, go with a 4GB flavor).  Hence, in my mind, it doesn\'t make any sense to create\n> flavors on the fly; you should have enough flavors to suit your needs, but I can\'t really\n> think of a situation where you\'d need so much granularity that you\'d need to create new\n> flavors on the fly (assuming, of course, that you planned ahead and created enough flavors\n> that you don\'t have VMs that are extremely over-allocated).\n\nI agree with the conclusion you\'re arguing for, but it is a bit more\ncomplex than that. Flavor defines at least three things, and possibly 4:\nRAM, root disk, and vcpu, with an optional ephemeral disk. Because of\nthat, the matrix of possibilities can get extremely large.\n\nConsider if you segment RAM as 1GB, 4GB, 8GB, 16GB, vcpu as 1, 2, 4,\n8, and root disk as 10G, 50G, 100G, 1T. Your matrix is now 4?, 64\nflavors. If you\'ve never heard of \"the paradox of choice\", consumers\nare slowed down by having too many choices. So less flavors will not\nonly make your resource consumption easier to optimize, it will help\nnew users move forward with more certainty.\n\nBut the reality is, nobody needs an 8 CPU, 1T, 1GB flavor. Likewise,\nnobody needs a 1 CPU 16GB 10G server. Both are missing the mark with\nthe common workloads. And a lot are filled in by higher level services\nlike Trove, LBaaS, Swift, etc.\n\nSo realistically, having 20-30 flavors, with groupings around the\ncombinations users demand, is a known pattern that seems to work well.\nIf a user has a workload that is poorly served by any of these, it\nprobably makes the most sense for them to over-buy and demand a better\nsized flavor from the provider. Dynamically allocating flavors is just\ngoing to complicate things for everybody.\n\nThat said, if Nova supports it, Heat should too.\n\n\n','<1922824035.921249.1399303421251.JavaMail.zimbra@redhat.com>',NULL),('<1399307550-sup-1682@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 09:38:32',-25200,'2014-05-05 16:38:32',NULL,'[openstack-dev] Monitoring as a Service','Excerpts from John Dickinson\'s message of 2014-05-04 12:37:55 -0700:\n> One of the advantages of the program concept within OpenStack is that separate code projects with complementary goals can be managed under the same program without needing to be the same codebase. The most obvious example across every program are the \"server\" and \"client\" projects under most programs.\n> \n> This may be something that can be used here, if it doesn\'t make sense to extend the ceilometer codebase itself.\n> \n\nTotally agree. Programs can also just do targetted work in projects that\nare also managed by another program. For instance, in the Deployment\nprogram, we drive features into all of the other projects that make it\npossible to deploy OpenStack with itself.\n\nHaving an API to define monitoring would be a fantastically useful thing\nfor that effort btw.\n\nBut I digress, I thin John is spot on here. The Telemetry program would\nbe the place to manage the service. However, I think it makes sense for\nit to at least start out as separate from Ceilometer for one reason:\nCeilometer is focused on measuring the infrastructure itself. What is\nneeded is a thing for monitoring the workloads from the user POV.\n\nThey may share data model, and even API, but I imagine the backend\nmight be quite different, since the ceilometer agents are trusted as\nbeing \"under\" the cloud and have access to RPC, but the users would be\nconstrained to REST API.\n\nSo sort of like Trove is eventually going to converge on using Heat, so\nshould a monitoring as a service project eventually converge on riding\non Ceilometer as much as possible. That said, if there\'s something\nworking now, I say bring it into the fold and iterate as needed.\n\n\n','<A58D6AAB-0E29-47F6-8AD2-D7F50262D55D@not.mn>',NULL),('<1399309145-sup-7236@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 10:04:21',-25200,'2014-05-05 17:04:21',NULL,'[openstack-dev] [infra] elements vs. openstack-infra puppet for\n	CI \"infra\" nodes','Excerpts from Dan Prince\'s message of 2014-05-05 05:51:52 -0700:\n> I originally sent this to TripleO but perhaps [infra] would have been a better choice.\n> \n> The short version is I\'d like to run a lightweight (unofficial) mirror for Fedora in infra:\n> \n>  https://review.openstack.org/#/c/90875/\n> \n> And then in the TripleO CI racks we can run local Squid caches using something like this:\n> \n>  https://review.openstack.org/#/c/91161/\n> \n> We have to do something because we see quite a bit of job failures related to unstable mirrors. If using local Squid caches doesn\'t work out then perhaps we will have to run local mirrors in each TripleO CI rack but I would like to avoid that if possible as it is more resource heavy. Especially because we\'ll need to do the same things in each rack for Fedora and Ubuntu (both of which run in each TripleO CI test rack).\n> \n> Dan\n> \n> ----- Forwarded Message -----\n> From: \"Dan Prince\" <dprince at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, April 29, 2014 4:10:30 PM\n> Subject: [openstack-dev] [TripleO] elements vs. openstack-infra puppet for    CI \"infra\" nodes\n> \n> A bit of background TripleO CI background:\n> \n>  At this point we\'ve got two public CI overcloud which we can use to run TripleO check jobs for CI. Things are evolving nicely and we\'ve recently been putting some effort into making things run faster by adding local distro and Pypi mirrors. Etc. This is good in that it should help us improve both the stability of test results and runtimes.\n> \n> ----\n> \n> This brings up the question of how we are going to manage our TripleO overcloud CI resources for things like: distro mirrors, caches, test environment brokers, etc\n> \n> 1) Do we use and or create openstack-infra/config modules for everything we need and manage it via the normal OpenStack infrastructure way using Puppet etc.?\n> \n> 2) Or, do we take the TripleO oriented approach and use image elements and Heat templates to manage things?\n> \n> Which of these two options do we prefer given that we eventually want TripleO to be gating? And who is responsible for maintaining them (TripleO CD Admins or OpenStack Infra)?\n> \n\nThe way I see things going, infra has a job to do _today_ and they should\nchoose the tools they want for doing that job.\n\nTripleO is trying to make OpenStack deploy itself, and hopefully in\nso doing, also make managing workloads easier on OpenStack. If we are\noperating any workload, it would make a lot of sense for us to use the\nsame tools we are suggesting OpenStack operators consider using.\n\nSo it really comes down to who is operating the mirrors. If we\'re doing\nit, we should be doing it with the tools we\'ve built for that specific\npurpose. If we expect infra to do it, then they should decide what works\nbest for them.\n\nEither way, I completely agree that we shouldn\'t be doing anymore one-off\ncowboy mirrors, which is what we\'ve been doing.\n\n\n','<1276815382.1496022.1399294312362.JavaMail.zimbra@redhat.com>',NULL),('<1399309923-sup-3069@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 10:16:07',-25200,'2014-05-05 17:16:07',NULL,'[openstack-dev] [Nova][Heat] Custom Nova Flavor creation\n	through Heat (pt.2)','Excerpts from Solly Ross\'s message of 2014-05-05 10:01:12 -0700:\n> If you actually have 64 flavors, though, and it\'s overwhelming\n> your users, it would be pretty trivial to implement a \"flavor\n> recommender\" where you input your requirements and it pops out\n> the nearest flavor.  That being said, I do think you\'re right\n> that you can probably mitigate flavor explosion by trimming out\n> the outlier flavors.  20-30 flavors is still a bit much, but with\n> some clever naming, the burden of choosing a flavor can be lessened.\n> \n> Additionally, if this is all for the purpose of orchestration,\n> we have a computer dealing with choosing the correct flavor,\n> and if your computer has a problem dealing with a choice between 64\n> (or even 512) different flavors, perhaps it\'s time to upgrade :-P.\n> \n\nWhen starting with nothing, users are pretty much going to have to\nguess. They\'ll have 64 things to choose from. The computer only gets\ninvolved when you have data.\n\nA piece of software which takes measurements of resource constraints\nof your application, and understands how to then choose a flavor is not\nexactly simple. One also needs business rules, as sometimes you may want\nto accept being resource constrained in exchange for reducing cost.\n\nThough it would be a pretty cool feature if one could simply run an agent\non their vm and it would be able to identify the flavor that would be\nmost efficient. :)\n\n\n','<1971645675.1033150.1399309272940.JavaMail.zimbra@redhat.com>',NULL),('<1399310493-sup-2048@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-05-05 10:26:11',-25200,'2014-05-05 17:26:11',NULL,'[Openstack-operators] A Hypervisor supporting containers','\n<fixed top post quoting for clarity sake>\n\nExcerpts from matt\'s message of 2014-05-02 00:11:24 -0700:\n> On Fri, May 2, 2014 at 3:06 AM, Aaron Rosen <aaronorosen at gmail.com> wrote:\n> \n> > <snip>\n> > you know, i\'ve never worked anywhere that didn\'t roll their own distro.\n> > <snip>\n> \n> git clone nova\n> git clone  https://github.com/stackforge/nova-docker nova/nova/virt/docker\n> \n> </snip>\n> \n> in the real world.  this doesn\'t happen ever.\n> \n\nWhich is it though. Are orgs rolling their own distros, implying gathering\nsource directly and packaging it together, or are they refusing to gather\nsource and package it together, as you\'ve said doesn\'t happen ever?\n\nAnyway, it sounds to me like containers are as alive in Icehouse as they\nwere in Havana, we\'ve just done some examination and posted a public\nhealth report explaining how risky it might be to rely on them to carry\nyour organization.\n\n\n','<CAP_sDUGWkJFZmceWQm3JYKCR4-rM-un7EsQZZHystRTETyzRDQ@mail.gmail.com>',NULL),('<1399311210-sup-5794@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-05-05 10:47:02',-25200,'2014-05-05 17:47:02',NULL,'[Openstack-operators] A Hypervisor supporting containers','Excerpts from Brad Knowles\'s message of 2014-05-02 10:30:47 -0700:\n> On May 2, 2014, at 11:27 AM, matt <matt at nycresistor.com> wrote:\n> \n> > most operators do not attend summits.\n> \n> For people who do work at companies that would qualify as \"operators\", the only people who ever will attend summits or conferences are sales and marketing types.  Real rubber-meets-the-road operations people won\'t attend, unless they\'ve been invited to speak.\n> \n> At most, companies may potentially allow their employees to attend one conference or summit per year (i.e., allow them to take PTO to attend on their own dollar), and lots of things are likely to rank higher on their list of priorities than squandering that once-a-year opportunity on a summit.\n> \n> \n> The only people who are likely to ever attend a conference or a summit are people who could generate sales by being there and operating the booth, or if they\'re new enough to the space and their company is desperate enough to send one person somewhere for a week to become the in-house \"expert\" on the subject.\n> \n> \n> At least, that\'s the pattern I\'ve seen repeated over and over again for the past 25+ years.\n> \n\nThis is the free-rider problem of Open Source in a nutshell. It cuts\nboth ways, it just isn\'t obvious how it hurts the free rider org.\n\nIf your org is small enough where one individual travelling to the\nsummit and being hyper focused on it for a week is too expensive, then\nyou\'re unfortunately getting left behind by the economy of scale that\ndrives OpenStack.\n\nYou\'ll spend far more resources trying to adapt your business to OpenStack\nthan you would have spent sending that employee to the summit to safe\nguard your use cases in sessions and to help shape the future in your\nfavor.\n\nI\'ve been in orgs both large and small, and I\'ve convinced both sizes\nto send me to open source events where I can glean information, make\nconnections, and influence development. Travel is cheap compared to having\nto work around bugs that the developers don\'t even know are important to\nanybody.\n\nThis is not unique to OpenStack, or even Open Source. All shared\ninfrastructure gets dominated by those who can afford to be present in\nits governance.\n\n\n','<A67F3DFF-9F4B-4011-BEA0-69DD7919F4D0@shub-internet.org>',NULL),('<1399313511-sup-201@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 11:13:20',-25200,'2014-05-05 18:13:20',NULL,'[openstack-dev] [TripleO] HAProxy and Keystone setup (in\n	Overcloud)','Excerpts from Jan Provaznik\'s message of 2014-05-05 01:10:56 -0700:\n> On 04/28/2014 10:05 PM, Jay Dobies wrote:\n> >> We may want to consider making use of Heat outputs for this.\n> >\n> > This was my first thought as well. stack-show returns a JSON document\n> > that would be easy enough to parse through instead of having it in two\n> > places.\n> >\n> >> Rather than assuming hard coding, create an output on the overcloud\n> >> template that is something like \'keystone_endpoint\'. It would look\n> >> something like this:\n> >>\n> >> Outputs:\n> >>    keystone_endpoint:\n> >>      Fn::Join:\n> >>        - \'\'\n> >>        - - \"http://\"\n> >>          - {Fn::GetAtt: [ haproxy_node, first_ip ]} # fn select and yada\n> >>          - \":\"\n> >>          - {Ref: KeystoneEndpointPort} # thats a parameter\n> >>          - \"/v2.0\"\n> >>\n> >>\n> >> These are then made available via heatclient as stack.outputs in\n> >> \'stack-show\'.\n> >>\n> >> That way as we evolve new stacks that have different ways of controlling\n> >> the endpoints (LBaaS anybody?) we won\'t have to change os-cloud-config\n> >> for each one.\n> >>\n> \n> The output endpoint list would be quite long, it would have to contain \n> full list of all possible services (even if a service is not included in \n> an image) + SSL URI for each port.\n> \n> It might be better to get haproxy ports from template params (which \n> should be available as stack.params) and define only virtual IP in \n> stack.ouputs, then build endpoint URI in os-cloud-config. I\'m not sure \n> if we would have to change os-cloud-config for LBaaS or not. My first \n> thought was that VIP and port are only bits which should vary, so \n> resulting URI should be same in both cases.\n> \n\n+1\n\n\n','<53674790.1070305@redhat.com>',NULL),('<1399316007-sup-9714@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-05 11:56:14',-25200,'2014-05-05 18:56:14',NULL,'[openstack-dev] [TripleO][Tuskar] Feedback on init-keystone spec','Excerpts from Ji?? Str?nsk?\'s message of 2014-05-05 01:54:11 -0700:\n> On 30.4.2014 09:02, Steve Kowalik wrote:\n> > Hi,\n> >\n> >     I\'m looking at moving init-keystone from tripleo-incubator to\n> > os-cloud-config, and I\'ve drafted a spec at\n> > https://etherpad.openstack.org/p/tripleo-init-keystone-os-cloud-config .\n> >\n> >     Feedback welcome.\n> >\n> > Cheers,\n> >\n> \n> Hi Steve,\n> \n> that looks good :) Just to clarify -- should the long-term plan for \n> Keystone PKI initialization still be to generate the key+certs on \n> undercloud and push it to overcloud via Heat? (Likewise for \n> seed->undercloud.)\n\nLong term I\'d like to see us generate keys locally and have Barbican\nstore the keys. It is still not quite far enough on the incubation path\nto be something we rely on directly, but we should consider that a very\ntemporary situation.\n\nShort term we\'ll have to push things around via Heat. That behooves us\nto ensure SSL is working for metadata fetching btw. I\'ve not checked on\nthat in a very long time, and I\'m not sure any of our CI enables it.\n\n\n','<536751B3.307@redhat.com>',NULL),('<1399317073.44583172@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-05-05 14:11:13',-18000,'2014-05-05 19:11:13',NULL,'[openstack-community] Upcoming Industry Event Call for\n	Presentations Deadlines','\n\n \nHere are the upcoming Call of Presentations deadlines for industry events.  The hotlinks take you to the CFP information and submission pages.  Thank you for representing OpenStack at these conferences.\n[Cloud Connect China](http://www.cloudconnectevent.cn/index_en.php).  due by May 9.  Event is September 16-18 in Shanghai, China.\n[Interop & Cloud Connect New York. ](http://www.interop.com/newyork/conference/call-for-speakers.php)Due May 16.  Event is in New York City, NY September 29-October 3.\n[FrOSCon](http://www.froscon.de/en/home/). [CFP](http://www.froscon.de/en/home/) deadline is May 23.  Event is August 23-24 in St. Augustin, Germany.\n[CloudSec](http://www.cloudsec.co/uat/speakers) in Taiwan.  Submissions due May 30.  Event is August 12.\n[Japan Open Source Conference](https://www.ospn.jp/osc2014-shimane/).  See website in Japanese - it is not translating well.  Event is August 23 in Shimane, Japan.\n[Cloud Expo West](http://www.cloudcomputingexpo.com/general/papers2014west.htm), [Internet of Things Expo](http://www.thingsexpo.com/general/papers2014west.htm), and [DevOps Summit @ Cloud Expo](http://devopssummit.sys-con.com/general/papers2014west.htm) (co-located events).  All 3 CFPs open through June 15.  Events are November 4-6 in Santa Clara, CA.\nFossetcon.  [CFP](http://fossetcon.org/2014/) open until June 15.  Event is September 13-15 in Orlando.\nDEVIEW 2014 (DEveloper\'s VIEW). [CFP submissions](http://deview.kr/2014/callForSpeakers_en.nhn) due by June 30.  Event is September 29-30 in Seoul, South Korea.\nCloudOpen and LinuxCon Europe.  [Submit ](http://events.linuxfoundation.org/events/cloudopen-europe/program/cfp)by July 11.  Event is October 13-15 in Dusseldorf, Germany.\n[Ubucon.DE](http://ubucon.de).  CFP deadline is July 31; go to site, click on Call for Papers.  Event is October 17-19 in Katlenburg, Germany.\nSoftware Defined Enterprise World Forum.  [CFP ](http://softwaredefined-enterprise.com/interested-in-speaking/)available now, no deadline listed.  Event is September 10-14 in London, England.\nFSOSS.  [CFP](http://fsoss.senecac.on.ca/2014/presentation-proposal-form) is open now, no deadline listed.  Event is October 23-24 in Toronto, Canada.\n \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140505/fbd06144/attachment.html>\n\n',NULL,NULL),('<1399359974.2032.YahooMailNeo@web163803.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-06 00:06:14',-25200,'2014-05-06 07:06:14',NULL,'[Openstack] Openstack access with Java SDKs','Has it been tested against multiple hypervisors/ SDN backends?\nOn Tuesday, May 6, 2014 10:18 AM, Shital Patil <shital.patil at gslab.com> wrote:\n \njclouds is good and stable SDK for openstack \nyou can also look for openstack4j\n\n\n\n\nOn Tue, May 6, 2014 at 8:23 AM, Vikas Kokare <vikaskokare at gmail.com> wrote:\n\nI am looking for a standard, seamless way to access OpenStack APIs , most likely using the Java SDKs that are summarized at \n>https://wiki.openstack.org/wiki/SDKs#Software_Development_Kits\n>\n>There are various distributions of Openstack available today. \nIs this possible using these SDK\'s to write an application that works seamlessly across distributions?\n>\n>If the answer to the above is yes, then how does one evaluate the pros/cons of these SDK\'s?\n>\n>-Vikas\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140506/fd95284f/attachment.html>\n\n','<CADdv+152iTJ1vTFjkFuJDjEZ-U0KZGCU2YKdB9-H+OVDfn8qWQ@mail.gmail.com>',NULL),('<1399379981.11439.YahooMailNeo@web163801.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-06 05:39:41',-25200,'2014-05-06 12:39:41',NULL,'[Openstack] Openstack access with Java SDKs','Does jcloud cover Networking - Neutron and Storage - Cinder? from docs i saw only compute APIs.\n\nOn Tuesday, May 6, 2014 10:18 AM, Shital Patil <shital.patil at gslab.com> wrote:\n \njclouds is good and stable SDK for openstack \nyou can also look for openstack4j\n\n\n\n\nOn Tue, May 6, 2014 at 8:23 AM, Vikas Kokare <vikaskokare at gmail.com> wrote:\n\nI am looking for a standard, seamless way to access OpenStack APIs , most likely using the Java SDKs that are summarized at \n>https://wiki.openstack.org/wiki/SDKs#Software_Development_Kits\n>\n>There are various distributions of Openstack available today. \nIs this possible using these SDK\'s to write an application that works seamlessly across distributions?\n>\n>If the answer to the above is yes, then how does one evaluate the pros/cons of these SDK\'s?\n>\n>-Vikas\n>_______________________________________________\n>Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>Post to ? ? : openstack at lists.openstack.org\n>Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n>\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ?  : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140506/27732cc8/attachment.html>\n\n','<CADdv+152iTJ1vTFjkFuJDjEZ-U0KZGCU2YKdB9-H+OVDfn8qWQ@mail.gmail.com>',NULL),('<1399390968.20654267.1401897990858.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 12:06:30',-14400,'2014-06-04 16:06:30',NULL,'[openstack-dev] [Horizon] [UX] Design for Alarming and\n	Alarm	Management','\nHi Liz,\n\nLooks great!\n\nSome thoughts on the wireframe doc:\n\n* The description of form:\n\n    \"If CPU Utilization exceeds 80%, send alarm.\" \n  \n  misses the time-window aspect of the alarm definition.\n\n  Whereas the boilerplate default descriptions generated by\n  ceilometer itself:\n\n    \"cpu_util > 70.0 during 3 x 600s\"\n\n  captures this important info.\n\n* The metric names, e.g. \"CPU Utilization\", are not an exact\n  match for the meter names used by ceilometer, e.g. \"cpu_util\".\n\n* Non-admin users can create alarms in ceilometer:\n\n  \"This is where admins can come in and\n   define and edit any alarms they want\n   the environment to use.\"\n\n  (though these alarms will only have visibility onto the stats\n   that would be accessible to the user on behalf of whom the\n   alarm is being evaluated)\n\n* There\'s no concept currently of alarm severity.\n\n* \"Should users be able to enable/dis-able alarms.\"\n\n  Yes, the API allows for disabled (i.e. non-evaluated) alarms.\n\n* \"Should users be able to own/assign alarms?\"\n\n  Only admin users can create an alarm on behalf of another\n  user/tenant.\n\n* \"Should users be able to acknowledge, close alarms?\"\n\n  No, we have no concept of ACKing an alarm.\n\n* \"Admins can also see a full list of all Alarms that have\n   taken place in the past.\"\n\n  In ceilometer terminology, we refer to this as alarm history\n  or alarm change events.\n\n* \"CPU Utilization exceeded 80%.\"\n\n  Again good to capture the duration in that description of the\n  event.\n\n* \"Within the Overview section, there should be a new tab that allows the\n   user to click and view all Alarms that have occurred in their environment.\"\n\n  Not sure really what \"environment\" means here. Non-admin tenants only\n  have visibility to their own alarm, whereas admins have visibility to\n  all alarms.\n\n* \"This list would keep the latest  alarms.\"\n\n  Presumably this would be based on querying the alarm-history API,\n  as opposed to an assumption that Horizon is consuming the actual\n  alarm notifications?\n\nCheers,\nEoghan\n\n----- Original Message -----\n> Hi All,\n> \n> I?ve recently put together a set of wireframes[1] around Alarm Management\n> that would support the following blueprint:\n> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page\n> \n> If you have a chance it would be great to hear any feedback that folks have\n> on this direction moving forward with Alarms.\n> \n> Best,\n> Liz\n> \n> [1]\n> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<E9F1085F-336B-4472-AA45-387B68149078@redhat.com>',NULL),('<1399392832.3749.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 16:13:52',0,'2014-05-06 16:13:52',NULL,'[openstack-dev] [Climate] Query leases by project_id/domain_id','Any comments on this?\n\nOn Mon, 2014-04-28 at 16:57 +0000, Fuente, Pablo A wrote:\n> Any comments on this?\n> \n> On Tue, 2014-04-22 at 18:58 +0000, Fuente, Pablo A wrote:\n> > Hi\n> > 	I\'m trying to tackle this bug\n> > (https://bugs.launchpad.net/climate/+bug/1304435). The options that I\'m\n> > considering are:\n> > \n> > 	1 - Add the project_id query parameter to the leases API\n> > 	2 - Use the X_PROJECT_ID header\n> > \n> > 	I prefer the first option, but I would like to know if there is a\n> > general OpenStack approach for implementing this. BTW, I\'m planning to\n> > apply the same criteria for making queries for Domains.\n> > \n> > Pablo.\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1398704247.3661.36.camel@localhost>',NULL),('<1399392975-sup-3178@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 09:25:22',-25200,'2014-05-06 16:25:22',NULL,'[openstack-dev] Monitoring as a Service','Excerpts from Sandy Walsh\'s message of 2014-05-06 07:02:05 -0700:\n> On 5/6/2014 10:04 AM, Thierry Carrez wrote:\n> > John Dickinson wrote:\n> >> One of the advantages of the program concept within OpenStack is that separate code projects with complementary goals can be managed under the same program without needing to be the same codebase. The most obvious example across every program are the \"server\" and \"client\" projects under most programs.\n> >>\n> >> This may be something that can be used here, if it doesn\'t make sense to extend the ceilometer codebase itself.\n> > +1\n> >\n> > Being under the Telemetry umbrella lets you make the right technical\n> > decision between same or separate codebase, as both would be supported\n> > by the organizational structure.\n> >\n> > It also would likely give you an initial set of contributors interested\n> > in the same end goals. So at this point I\'d focus on engaging with the\n> > Telemetry program folks and see if they would be interested in that\n> > capability (inside or outside of the Ceilometer code base).\n> \n> This is interesting.\n> \n> I\'d be curious to know more what \"managed\" means in this situation? Is\n> the core project expected to allocate time in the IRC meeting to the\n> concerns of these adjacent projects? What if the core project doesn\'t\n> agree with the direction or deems there\'s too much overlap? Does the\n> core team instantly have sway over the adjacent project?\n> \n\nYes, the core team instantly has sway. It is not to be taken lightly.\n\nWe absorbed Tuskar into the Deployment program, and our PTL, Robert\nCollins, was able to get involved with the design of Tuskar early and\nconvince them to stay more aligned with other OpenStack projects. So\nthe benefit is now Tuskar can focus on the thing that they _do_ need\nto do that are unique.  Likewise, their core team was given core status\nin the deployment program, and was able to influence the pieces of the\nDeployment program that they needed to work better.\n\nThis has created a nice cycle of contribution where many aspects of the\nDeployment program\'s projects have been improved as a result. Had Tuskar\ndecided to just stay out of the Deployment program, they might have\nreimplemented many of the things we had already done, and thus would\nbe less adoptable by users and they would receive less contribution as\na whole.\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A474BC4D@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1399397524.4957.19.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 17:32:08',0,'2014-05-06 17:32:08',NULL,'[openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion\n about Cross-Project Integration of DNS at Summit','Hi,\n\nThe only issue I would see with the pod is that not all of us are ATCs,\nso we may or may not have access to that area (I am open to correction\non that point - in fact I hope someone does ;) )\n\nI could see it fitting in with our design session, but maybe if we meet\non the Monday to do some initial hashing out as well, I think that would\nbe good.\n\nI am around for the morning, and later on in the afternoon on Monday, if\nthat suits.\n\nGraham\n\nOn Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:\n\n> I have just updated my etherpad [1] with some proposed times.  Not\n> knowing much about the venue, I could only propose the \"pod area\" as a\n> the location.\n> \n> I also updated the designate session etherpad [2] per your suggestion.\n>  If there is time during the Designate sessions to include this in the\n> discussion then that may work out well.\n> \n> Thanks,\n> Carl\n> \n> [1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate\n> [2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession\n> \n> On Tue, May 6, 2014 at 8:58 AM, Joe Mcbride <jmcbride at rackspace.com> wrote:\n> >\n> > On 4/29/14, 3:09 PM, \"Carl Baldwin\" <carl at ecbaldwin.net> wrote:\n> >\n> >>I feel this is an important subject to discuss because the end result\n> >>will be a better cloud user experience overall.  The design summit\n> >>could be a great time to bring together interested parties from\n> >>Neutron, Nova, and Designate to discuss the integration that I propose\n> >>in these blueprints.\n> >\n> > Do you have a time/location planned for these discussions? If not, we may\n> > have some time in one of the Designate sessions.  The priorities and\n> > details for our design session will be pulled from\n> > https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are\n> > interested in joining us, can you add your proposed blueprints in the\n> > format noted there?\n> >\n> > Thanks,\n> > joe\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/fe7d2455/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/fe7d2455/attachment.pgp>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/x-pkcs7-signature\nSize: 6961 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/fe7d2455/attachment.bin>\n\n','<CALiLy7rU6UQYB5RPRW8yao4Puru2WzNQx_zK7FroptBMz7An9w@mail.gmail.com>',NULL),('<1399417559-sup-9938@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 16:07:16',-25200,'2014-05-06 23:07:16',NULL,'[openstack-dev] [tripleo] Decreasing resource usage in tripleo\n	CI','+1 to the plans.\n\nWe\'ve recently freed up a few more boxes for the HP region, and we\'ll\nbe rolling those out as we migrate from saucy to trusty for the rest of\nthe cloud. But we should do all of the things below anyway.\n\nExcerpts from Derek Higgins\'s message of 2014-05-06 15:34:41 -0700:\n> Hi,\n> \n>    I mentioned this at the tripleo meeting today and to get opinions out\n> there I\'d like to bring it up here,\n> \n> In tripleo we are currently very tight on resources to run our CI jobs\n> and I\'d like to scale back temporarily until we have either more\n> capacity or reorganize things a bit, to more efficiently use what we\n> have. Basically I\'d like to see us do 3 things\n> \n> 1. Get rid of check-tripleo-seed-precise job\n>    This is currently a subset of both check-tripleo-undercloud-precise\n> and check-tripleo-overcloud-precise so is basically using up resources\n> with no extra gain, if we put plans in place to deploy the\n> undercloud/overcloud on a persistent seed we can add it back again.\n> \n> 2. Move the check-tripleo-ironic-undercloud-precise into the\n> experimental-tripleo queue, this test is non voting and currently\n> doesn\'t work, when its fixed we can put it back into the check-tripleo\n> queue and delete the check-tripleo-ironic-seed-precise job, as it should\n> be a subset of the ironic undercloud job (similar to the seed job\n> mentioned in point 1)\n> \n> 3. Get back onto 8G nodepool instances, we moved to 16G instances a\n> while back to work around a problem,\n>  I\'ve a patch up that should allow us to get back to 8G nodes\n> https://review.openstack.org/#/c/91545/\n> \n> Any objections or alternate ideas?\n> \n> thanks,\n> Derek.\n> \n\n\n','<53696381.8020309@redhat.com>',NULL),('<1399437916.101.1383979026217.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-09 06:37:05',0,'2013-11-09 06:37:05',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #44','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/44/>\n\n------------------------------------------\n[...truncated 21408 lines...]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_None_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_None_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_non_number_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_non_number_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_size_smaller_than_original_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_with_size_smaller_than_original_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_extend_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometer_meter_list\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometer_meter_list ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometer_resource_list\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometer_resource_list ... ok\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometermeter_alarm_list\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometermeter_alarm_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          100.906\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   90.169\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  74.041\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                58.428\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    53.203\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       52.151\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      50.592\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     47.640\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             45.505\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_delete_active_server[gate]                                 41.789\n\n----------------------------------------------------------------------\nRan 1495 tests in 1671.725s\n\nOK (skipped=76)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-640256-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-640256.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-640256/44/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1965165658.98.1383892253736.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1399455321.4957.23.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 09:35:25',0,'2014-05-07 09:35:25',NULL,'[openstack-dev] [Juno-Summit] availability of the project\n \"project pod\" rooms on Monday May 12th?','Hi Thierry -\n\nI had a question about Program pods access. Do people need to be ATCs to get into the area with the pods?\n\nI ask, as not all members of the Designate group would be ATCs...\n\nThanks,\n\nGraham\n\nOn Tue, 2014-05-06 at 21:53 +0200, Thierry Carrez wrote:\n\n\nCarl Baldwin wrote:\n> Is there a map, a list, or some other official reference?  I may like\n> to use a pod for a cross-project discussion about DNS between Nova,\n> Neutron, and Designate.  Not a big deal but it might be nice to know\n> more about what we\'re looking for when we get there.\n\nThere will be a designated pod for each of the official programs at:\nhttps://wiki.openstack.org/wiki/Programs\n\nSome programs share a pod. There will be a map at the center of the\nspace, as well as signage up to help find the relevant pod.\n\nFor a cross-project discussion you\'d have to pick a pod where to have\nit. In your case I\'d recommend the Neutron pod since Nova shares its pod\nwith Glance and there is no Designate pod.\n\nCheers,\n\n\n\n\n','<53693D9E.5080501@openstack.org>',NULL),('<1399477240.86018.YahooMailNeo@web172604.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 16:40:40',3600,'2014-05-07 15:40:40',NULL,'[openstack-dev] Openstack CloudTrail equivalent','Hi\n\nI am new to OpenStack and sorry for the trivial question. I would like to know if there is any project / module equivalent to or similar to AWS cloudTrail.Any pointers would be helpful.\n\nThank you\nMagesh\n\n\n\n',NULL,NULL),('<1399478592.13135.YahooMailNeo@web172603.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-07 17:03:12',3600,'2014-05-07 16:03:12',NULL,'[Openstack] CloudTrail equivalent for OpenStack','Hi\n\nI am new to OpenStack and sorry for the trivial question. I would like to know if there is any project / module equivalent to or similar to AWS cloudTrail.Any pointers would be helpful.\n\nThank you\nMagesh\n\n\n\n',NULL,NULL),('<1399490702-sup-3889@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 12:29:04',-25200,'2014-05-07 19:29:04',NULL,'[openstack-dev] [Heat] [Keystone] [TripleO] Making use of\n	domains by name - policy and API issues?','Excerpts from Robert Collins\'s message of 2014-04-28 23:25:02 -0700:\n> On 29 April 2014 12:27, Dolph Mathews <dolph.mathews at gmail.com> wrote:\n> >\n> \n> > Sure: domain names are unambiguous but user mutable, whereas Heat\'s approach\n> > to using admin tenant \"name\" is at risk to both mutability and ambiguity (in\n> > a multi-domain deployment).\n> \n> Isn\'t domainname/user unambiguous and unique? mutability is really not\n> keystones choice.\n> \n> If keystone won\'t accept domainname/user then that will force us to\n> either do two stack-updates for a single deploy (ugly) or write\n> patches to heat (and neutron where the callback-to-nova support has\n> the same issue) to manually try a lookup and work around this.\n> \n> Since its trivial to write such a thunk, what benefit is there to your\n> users - e.g. TripleO/heat/nova not have it in keystone itself?\n\nSo it sounds like we can drive a change into Keystone. The short version\nis something like this:\n\nAnywhere that accepts a domain ID, should also be able to accept a\ndomain name.  Anywhere that accepts a user ID, should also be able to\naccept a domain name and user name.\n\nThis sounds like it has several facets and so is spec-worthy. Anyone\ndisagree?\n\n\n','<CAJ3HoZ2pdRfajJ5qXMwaTRE5sZTJFm_X-f1QGCyn7sh4s0Bx3w@mail.gmail.com>',NULL),('<1399569558.3071.14.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 17:19:18',0,'2014-05-08 17:19:18',NULL,'[openstack-dev] [Neutron][LBaaS] API proposal review thoughts','Hi Eugene,\nComments in-line.\n\nOn Thu, 2014-05-08 at 17:01 +0400, Eugene Nikanorov wrote:\n> Hi Adam,\n> \n> \n> My comments inline:\n>         1. We shouldn\'t be looking at the current model and deciding\n>         which object is the root object, or what object to rename as a\n>         \"loadbalancer\"... That\'s totally backwards! *We don\'t define\n>         which object is named the \"loadbalancer\" by looking for the\n>         root object -- we define which object is the root by looking\n>         for the object named \"loadbalancer\".* I had hoped that was\n>         clear from the JSON examples in our API proposal, but I think\n>         maybe there was too much focus on the object model chart,\n>         where this isn\'t nearly as clearly communicated.\n>         \n>         \n>         2. As I believe I have also said before, if I\'m using \"<X> as\n>         a Service\" then I expect to get back an object of type \"<X>\".\n>         I would be very frustrated/confused if, as a user, LBaaS\n>         returned me an object of type \"VIP\" when I POST a Create for\n>         my new load balancer. On this last point, I feel like I\'ve\n>         said this enough times that I\'m beating a dead horse...\n>         \n>         \n> I think we definitely should be looking at existing API/BBG proposal\n> for the root object.\n> The question about whether we need additional \'Loadbalancer\' resource\n> or not is not a question about terminology, so (2) is not a valid\n> argument.\n> \n> \n> What really matters in answering the question about \'loadbalancer\'\n> resource is do we need multiple L2 ports per single loadbalancer. If\n> we do - that could be a justification to add it. Right now the common\n> perception is that this is not needed and hence, \'loadbalancer\' is not\n> required in the API or obj model.\nLet me know if I am misunderstanding this,and please explain it\nfurther. \nA single neutron port can have many fixed ips on many subnets.  Since\nthis is the case you\'re saying that there is no need for the API to\ndefine multiple VIPs since a single neutron port can represent all the\nIPs that all the VIPs require?\n> \n> \n> Thanks,\n> Eugene.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOTt++vFpNz78JQZSpZAMwTC-KY0KKRt=ORa39Vnc_o1xg@mail.gmail.com>',NULL),('<1399621115.27156679.1385415684124.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-25 13:41:24',-28800,'2013-11-25 21:41:24',NULL,'[openstack-dev] [nova] Should the server create API return\n	404	errors?','+1 on this sentiment.\n\n>From the perspective of the client, I typically imagine a web browser. A 404 means that a \"thing was not found\" and this **implies** that I might specify a different \"thing\" so that I do *not* get a 404. But in many of the circumstances the 404 root cause is a server-side misconfiguration or some other fault I\'ll need to grab a different access mechanism to get at. That\'s decidedly *not* something I can do anything about from my hypothetical \"web browser\".\n\n# Shawn Hartsock\n\n\n----- Original Message -----\n> From: \"Matt Riedemann\" <mriedem at linux.vnet.ibm.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, November 25, 2013 3:57:40 PM\n> Subject: [openstack-dev] [nova] Should the server create API return 404	errors?\n> \n> Aaron Rosen is working a patch [1] to handle a NetworkNotFound exception\n> in the server create API.  For the V2 API this will return a 400 error.\n>   For the V3 API this will return a 404 because of a V3-specific patch\n> [2].  The API docs list 404 as a valid response code, but is it\n> intuitive for a POST request like this?\n> \n> To muddy the waters more, ImageNotFound, FlavorNotFound and\n> KeypairNotFound are translated to 400 errors in both the V2 and V3 APIs.\n> \n> So why should the network-specific NotFound exceptions be a 404 but the\n> others aren\'t?\n> \n>  From a programmatic perspective, I should validate that my request\n> parameters are valid before calling the API in order to avoid a 404.\n>  From a user\'s perspective, a 404 seems strange - does it mean that the\n> server I\'m trying to create isn\'t found?  No, that\'s counter-intuitive.\n> \n> Ultimately I think we should be consistent, so if 404 is OK, then I\n> think the V3 API should make ImageNotFound, FlavorNotFound and\n> KeypairNotFound return a 404 also.\n> \n> Thoughts?\n> \n> [1]\n> https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/54202/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=04c6373178135ef5df18bd52ef74d80327b65d29029be1131297dd2fb48cae1e\n> [2]\n> https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/41863/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=65c546e11e8ed9c82993d55d2316d3c981a5e7eed461cb98d04d26aa7a89ddcb\n> \n> --\n> \n> Thanks,\n> \n> Matt Riedemann\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=2c79105a20f5ca91f32b0b2b82cd7d82a7b3c277480831371724b1674c9a3363\n> \n\n\n','<5293B9C4.8090501@linux.vnet.ibm.com>',NULL),('<1399635067.25.1372313615065.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-27 06:13:35',0,'2013-06-27 06:13:35',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #269','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/269/>\n\n\n\n','<252962399.22.1372227191345.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1399637360.1167.118.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-05-09 13:09:20',3600,'2014-05-09 12:09:20',NULL,'[openstack-tc] Reading material for CLA session','Hey\n\nI\'m almost done drafting - with Richard Fontan\'s help - a wiki page\ndescribing what the CLA is and why we have it, the issues we see with it\nand why we should consider changing to the DCO:\n\n  https://wiki.openstack.org/wiki/OpenStackAndItsCLA\n\nThis clearly isn\'t just a matter for the TC and I plan to circulate this\nmore widely after next week. However, I do think the leadership and\nconsensus of the TC is required to even begin making a case for change.\nUnless we - as a group - perceive an issue with contributor friction in\nparticular, then it\'s likely quite pointless pursuing this further.\n\nAnyway, I hope some of you will get a chance to read through this and\ncome along to the session on Tuesday at 14.50:\n\n  http://junodesignsummit.sched.org/event/bf582e043302263432fb50d34c96d98c\n\nAlso, please do send me questions for the FAQ.\n\nMark.\n\n\n\n',NULL,NULL),('<1399637438.1167.120.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-05-09 13:10:38',3600,'2014-05-09 12:10:38',NULL,'[openstack-tc] Reading material for CLA session','On Fri, 2014-05-09 at 13:09 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> I\'m almost done drafting - with Richard Fontan\'s \n\nRichard Fontan*a* obviously :(\n\n/me struggling to get the hang of this Kinesis keyboard\n\nMark.\n\n\n\n','<1399637360.1167.118.camel@sorcha>',NULL),('<1399644787.4957.31.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-09 14:13:09',0,'2014-05-09 14:13:09',NULL,'[openstack-dev] [Designate] Design Summit Etherpads','Hi All,\n\nHere are the 2 etherpads for the Designate Design sessions next week:\n\n\n  *   Tuesday 12:05-12:45\n  *   https://etherpad.openstack.org/p/juno-design-summit-designate-session-1\n  *   Room B305\n  *   http://sched.co/1eJqs6h\n  *   Tusday 14:50 - 18:10\n  *   https://etherpad.openstack.org/p/juno-design-summit-designate-session-2\n  *   Room B308\n  *   http://sched.co/1kczUAK\n\n\nLooking forward to seeing you there!\n\nGraham\n\n',NULL,NULL),('<1399645044.4957.35.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-09 14:17:25',0,'2014-05-09 14:17:25',NULL,'[openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion\n about Cross-Project Integration of DNS at Summit','Hi,\n\nIt looks like us \'none ATC\' folk will have access to the project pods - so should we nail down a time on Monday?\n\nIt looks like the 16:30 onwards is the most popular choice - will we say 16:30 on Monday in the Neutron pod?\n\nThanks,\n\nGraham\n\nOn Tue, 2014-05-06 at 17:45 +0000, Veiga, Anthony wrote:\nHi,\n\nThe only issue I would see with the pod is that not all of us are ATCs, so we may or may not have access to that area (I am open to correction on that point - in fact I hope someone does ;) )\n\n\nI?ll second this.  I have an interest in attending and assisting here, but I don?t have ATC status yet (though I?m an active contributor technically, just not via code.)\n\n\n\n\nI could see it fitting in with our design session, but maybe if we meet on the Monday to do some initial hashing out as well, I think that would be good.\n\nI am around for the morning, and later on in the afternoon on Monday, if that suits.\n\nGraham\n\nOn Tue, 2014-05-06 at 11:21 -0600, Carl Baldwin wrote:\n\n\nI have just updated my etherpad [1] with some proposed times.  Not\nknowing much about the venue, I could only propose the \"pod area\" as a\nthe location.\n\nI also updated the designate session etherpad [2] per your suggestion.\n If there is time during the Designate sessions to include this in the\ndiscussion then that may work out well.\n\nThanks,\nCarl\n\n[1] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate\n[2] https://etherpad.openstack.org/p/DesignateAtlantaDesignSession\n\nOn Tue, May 6, 2014 at 8:58 AM, Joe Mcbride <jmcbride at rackspace.com<mailto:jmcbride at rackspace.com>> wrote:\n>> On 4/29/14, 3:09 PM, \"Carl Baldwin\" <carl at ecbaldwin.net<mailto:carl at ecbaldwin.net>> wrote:>>>I feel this is an important subject to discuss because the end result>>will be a better cloud user experience overall.  The design summit>>could be a great time to bring together interested parties from>>Neutron, Nova, and Designate to discuss the integration that I propose>>in these blueprints.>> Do you have a time/location planned for these discussions? If not, we may> have some time in one of the Designate sessions.  The priorities and> details for our design session will be pulled from> https://etherpad.openstack.org/p/DesignateAtlantaDesignSession. If you are> interested in joining us, can you add your proposed blueprints in the> format noted there?>> Thanks,> joe>>> _______________________________________________> OpenStack-dev mailing list> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CF8E97C3.E40A%anthony_veiga@cable.comcast.com>',NULL),('<1399649165.1167.138.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-05-09 16:26:05',3600,'2014-05-09 15:26:05',NULL,'[openstack-tc] Reading material for CLA session','On Fri, 2014-05-09 at 11:22 -0400, James E. Blair wrote:\n> Mark McLoughlin <markmc at redhat.com> writes:\n> \n> > Hey\n> >\n> > I\'m almost done drafting - with Richard Fontan\'s help - a wiki page\n> > describing what the CLA is and why we have it, the issues we see with it\n> > and why we should consider changing to the DCO:\n> >\n> >   https://wiki.openstack.org/wiki/OpenStackAndItsCLA\n> >\n> > This clearly isn\'t just a matter for the TC and I plan to circulate this\n> > more widely after next week. However, I do think the leadership and\n> > consensus of the TC is required to even begin making a case for change.\n> > Unless we - as a group - perceive an issue with contributor friction in\n> > particular, then it\'s likely quite pointless pursuing this further.\n> >\n> > Anyway, I hope some of you will get a chance to read through this and\n> > come along to the session on Tuesday at 14.50:\n> >\n> >   http://junodesignsummit.sched.org/event/bf582e043302263432fb50d34c96d98c\n> >\n> > Also, please do send me questions for the FAQ.\n> \n> An excellent piece, thank you so much.\n> \n> In my experience at FOSDEM and at PyCon, I noted serious skepticism from\n> people I spoke with about the \"legitimacy\" of OpenStack as an actual\n> Open Source project.  In essence, there is a perception that it is a\n> corporate project and contributions from individual or unaffiliated\n> developers are not welcome.  I think we strive very hard to make sure\n> that everyone is welcome, but the bureaucracy of the individual\n> membership requirement and the CLA in particular are actions that say\n> otherwise to many developers.  If I were not so employed, I would count\n> myself among them.\n> \n> The CLA is an \"image problem\" for our project, and in addition to all of\n> the intangibles associated with that, it may adversely impact the\n> recruiting of new developers.\n> \n> I do think that this aspect is important; I leave it to you to consider\n> whether you would like to add it to the document.  And once again, a\n> thousand thanks for writing that.\n\nNicely put. Please do add it as a sub-section, perhaps between the\n\"contributor friction\" and \"organizational cost\" sections?\n\nThanks,\nMark.\n\n\n\n','<87bnv7t1rg.fsf@shiprock.lan>',NULL),('<1399650002.3352.14.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-09 15:40:02',0,'2014-05-09 15:40:02',NULL,'[openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer','Yes, Rackspace has users that have multiple IPv4 and IPv6 VIPs on a\nsingle load balancer.  However, I don\'t think it is a matter of it being\nneeded.  It\'s a matter of having an API that makes sense to a user.\nJust because the API has multiple VIPs doesn\'t mean every VIP needs its\nown port.  In fact creating a port is an implementation detail (you know\nthat phrase that everyone throws out to stonewall any discussions?).\nThe user doesn\'t care how many neutron ports are set up underneath, they\nonly care about the VIPs.   \n\nAlso, the load balancer wouldn\'t just be a container, the load balancer\nwould have flavor, affinity, and other metadata on it.  Plus, a user\nwill expect to get a load balancer back.  Since this object can only be\ndescribed as a load balancer, the name of it shouldn\'t be up for debate.\n\nThe API is meant to be a generic language that can be translated into a\nworking load balancer and should be driver agnostic.  We believe this is\nthe most generic and flexible API structure.  Each driver will be able\nto translate this into what makes sense for that product.\n\nOn a side note, if this is too disruptive for the current LBaaS then why\ncouldn\'t this go into Neutron V3?  I thought that was the plan all along\nanyway with redesigning the API.\n\nThanks,\nBrandon  \n\nOn Fri, 2014-05-09 at 14:30 +0400, Eugene Nikanorov wrote:\n> Hi folks,\n> \n> \n> I\'m pulling this question out of another discussion:\n> \n> \n> Is there a need to have multiple VIPs (e.g. multiple L2 ports/IP\n> addresses) per logical loadbalancer?\n> If so, we need the description of such cases to evaluate them.\n> \n> \n> Thanks,\n> Eugene.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOQQtV_hb7qbMACjx1+EC-3FbFON1_o6XWWNP7694aahEQ@mail.gmail.com>',NULL),('<1399650453.2275.131.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-05-09 11:47:33',-14400,'2014-05-09 15:47:33',NULL,'[Openstack-docs] [Openstack-i18n] Switch to itstool for docs\n	translation?','On Sun, 2014-05-04 at 13:33 +0200, Andreas Jaeger wrote:\n> On 05/03/2014 02:53 PM, Shaun McCance wrote:\n> > Hi all,\n> >\n> > I\'ve been working on switching the docs translation infrastructure over\n> > to itstool. This affects openstack-manuals, operations-guide, and\n> > api-site. The current tools are based on xml2po, but they don\'t call\n> > xml2po directly. Instead, they import xml2po and mess around with its\n> > internals to get some custom behavior.\n> >\n> > itstool is designed to handle custom behavior with rules from the W3C\n> > Internationalization Tag Set (ITS). You can see the ITS I put together\n> > so far here:\n> >\n> > https://review.openstack.org/#/c/91869/3/os_doc_tools/resources/openstack.its,unified\n> >\n> > Using ITS also allows us to do local ITS attributes to override the\n> > behavior for specific elements. See a simple example here:\n> >\n> > https://review.openstack.org/#/c/91872/1/api-quick-start/src/docbkx/api-quick-start-intro.xml,unified\n> >\n> > Most messages in the PO files will be the same. The one big difference\n> > will be in how placeholders are done when there\'s a block-level element\n> > inside a block-level element (a practice I discourage anyway).\n> \n> Could you give an example, please?\n\nIn the user-guide, in section_dashboard_manage_images.xml, there\'s an\nitemizedlist inside a para. An itemizedlist is a block-level element, so\nit starts one or more new PO messages. The message for the para gets a\nplaceholder element so translators know it\'s there, and can move it\naround if necessary.\n\nWith xml2po, it looks like this:\n\n#: doc/user-guide/section_dashboard_manage_images.xml:179(para)\nmsgid \"\"\n\"In the Update Image dialog box, you can perform the following \"\n\"actions: <placeholder-1/>\"\nmsgstr \"\"\n\nWith itstool, it looks like this:\n\n#. (itstool) path: step/para\n#: doc/user-guide/section_dashboard_manage_images.xml:179\nmsgid \"\"\n\"In the Update Image dialog box, you can perform the following \"\n\"actions: <_:itemizedlist-1/>\"\nmsgstr \"\"\n\nitstool puts all its special elements in a namespace using the _ prefix.\n(It gets mapped to an internal namespace URI during processing.) This\nhelps prevent conflicts, and it allows the local name of the placeholder\nelement to reflect what kind of thing gets put there, which is helpful.\n\n> > I\'d like to get input from translators, as well as any other docs folks\n> > who\'ve worked on this. Most of the document translations are incomplete\n> > anyway, but it would nevertheless be best to do this at the beginning of\n> > a release cycle.\n> \n> I assume that we can convert the existing translated files in such a way \n> that we do not loose translations? How to do this properly? Download \n> current files from transifex, convert into new format, upload converted \n> files - and then continue translating? Or will it be enough to upload \n> the pot file and let transfix do the translation?\n\nAny translations where the source string is the same will just continue\nto work. That\'s the way PO works. I looked into migrating obvious things\nlike the placeholder difference. There are very few translations though.\nI could maybe fix up 20-30 across all translations of all books. There\nisn\'t anything else to migrate.\n\n> Did you test a conversation of locale files and reconstructed translated \n> manuals? Is this just working with the updated tools or are additional \n> steps needed?\n\nYes. My patch includes also using itstool for generating the DocBook\nfrom the PO files. I tested it. It works.\n\n> I think we need to ensure with the infra team that itstools are \n> installed on our machines.\n\nThat\'s the big question I haven\'t been able to answer yet. Preferably at\nleast version 2.0.1.\n\n> I see that some patches are dependent on each other and we need to do \n> certain steps in a specific order. Is this something you can write down \n> as plan, please?\n\nI did write this:\n\nhttps://wiki.openstack.org/wiki/Documentation/Translation#ItsTool_Conversion\n\nIt has steps that need to be done (roughly) in order.\n\n--\nShaun\n\n\n\n\n','<53662589.2090504@suse.com>',NULL),('<1399762141.3363.15.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-10 22:49:01',0,'2014-05-10 22:49:01',NULL,'[openstack-dev] [Neutron][LBaaS] API proposal review thoughts','Hi Sam,\nI do not have access to those statistics.  Though, I can say that with\nour current networking infrastructure customers that have multiple IPv4\nor multiple IPv6 VIPs are in the minority. However, we have received\nfeature requests on allowing VIPs on our two main networks (public and\nprivate).  This is mainly because of us not charging for bandwidth on\nthe private network provided the client resides in the same datacenter\nas the load balancer (otherwise, its not accessible by the client.)\n\nHaving said that, I still would argue that the main reason for having a\nload balancer to many vips to many listeners is for user expectations. A\nuser expects to configure a load balancer, send that configuration to\nour service, and then return the details of that fully configured load\nbalancer back to the user.  Is your argument either 1) A user does not\nexpect LBaaS to accept and return load balancers or 2) Even if a user\nexpects this, its not that important of a detail?\n\nThanks,\nBrandon\n\nOn Fri, 2014-05-09 at 20:37 +0000, Samuel Bercovici wrote:\n> It boils down to two aspects:\n> \n> 1.      How common is it for tenant to care about affinity or have\n> more than a single VIP used in a way that adding an additional\n> (mandatory) construct makes sense for them to handle?\n> \n> For example if 99% of users do not care about affinity or will only\n> use a single VIP (with multiple listeners). In this case does adding\n> an additional object that tenants need to know about makes sense?\n> \n> 2.      Scheduling this so that it can be handled efficiently by\n> different vendors and SLAs. We can elaborate on this F2F next week.\n> \n>  \n> \n> Can providers share their statistics to assist to understand how\n> common are those use cases?\n> \n>  \n> \n> Regards,\n> \n>                 -Sam.\n> \n>  \n> \n>  \n> \n>  \n> \n> From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n> Sent: Friday, May 09, 2014 9:26 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] API proposal review\n> thoughts\n> \n>  \n> \n> Hi Eugene,\n> \n>  \n> \n> \n> This assumes that \'VIP\' is an entity that can contain both an IPv4\n> address and an IPv6 address. This is how it is in the API proposal and\n> corresponding object model that I suggested, but it is a slight\n> re-definition of the term \"virtual IP\" as it\'s used in the rest of the\n> industry. (And again, we\'re not yet in agreement that \'VIP\' should\n> actually contain two ip addresses like this.)\n> \n> \n>  \n> \n> \n> In my mind, the main reasons I would like to see the container object\n> are:\n> \n> \n>  \n> \n> \n>       * It solves the colocation / apolcation (or affinity /\n>         anti-affinity) problem for VIPs in a way that is much more\n>         intuitive to understand and less confusing for users than\n>         either the \"hints\" included in my API, or something based off\n>         the nova blueprint for doing the same for virtual\n>         servers/containers. (Full disclosure: There probably would\n>         still be a need for some anti-affinity logic at the logical\n>         load balancer level as well, though at this point it would be\n>         an operator concern only and expressed to the user in the\n>         \"flavor\" of the logical load balancer object, and probably be\n>         associated with different billing strategies. \"The user wants\n>         a dedicated physical load balancer? Then he should create one\n>         with this flavor, and note that it costs this much more...\")\n>       * From my experience, users are already familiar with the\n>         concept of what a logical load balancer actually is (ie.\n>         something that resembles a physical or virtual appliance from\n>         their perspective). So this probably fits into their view of\n>         the world better.\n>       * It makes sense for \"Load Balancer as a Service\" to hand out\n>         logical load balancer objects. I think this will aid in a more\n>         intuitive understanding of the service for users who otherwise\n>         don\'t want to be concerned with operations.\n>       * This opens up the option for private cloud operators /\n>         providers to bill based on number of physical load balancers\n>         used (if the \"logical load balancer\" happens to coincide with\n>         physical load balancer appliances in their implementation) in\n>         a way that is going to be seen as \"more fair\" and \"more\n>         predictable\" to the user because the user has more control\n>         over it. And it seems to me this is accomplished without\n>         producing any undue burden on public cloud providers, those\n>         who don\'t bill this way, or those for whom the \"logical load\n>         balancer\" doesn\'t coincide with physical load balancer\n>         appliances.\n>       * Attaching a \"flavor\" attribute to a logical load balancer\n>         seems like a better idea than attaching it to the VIP. What if\n>         the user wants to change the flavor on which their VIP is\n>         deployed (ie. without changing IP addresses)? What if they\n>         want to do this for several VIPs at once? I can definitely see\n>         this happening in our customer base through the lifecycle of\n>         many of our customers\' applications.\n>       * Having flavors associated with load balancers and not VIPs\n>         also allows for operators to provide a lot more differing\n>         product offerings to the user in a way that is simple for the\n>         user to understand. For example:\n>               * \"Flavor A\" is the cheap load balancer option, deployed\n>                 on a \"shared\" platform used by many tenants that has\n>                 fewer guarantees around performance and costs X.\n>               * \"Flavor B\" is guaranteed to be deployed on \"vendor Q\'s\n>                 Super Special Product (tm)\" but to keep down costs,\n>                 may be shared with other tenants, though not among a\n>                 single tenant\'s \"load balancers\" unless the tenant\n>                 uses the same load balancer id when deploying their\n>                 VIPs (ie. user has control of affinity among their own\n>                 VIPs, but no control over whether affinity happens\n>                 with other tenants). It may experience variable\n>                 performance as a result, but has higher guarantees\n>                 than the above and costs a little more.\n>               * \"Flavor C\" is guaranteed to be deployed on \"vendor P\'s\n>                 Even Better Super Special Product (tm)\" and is also\n>                 guaranteed not to be shared among tenants. This is\n>                 essentially the \"dedicated load balancer\" option that\n>                 gets you the best guaranteed performance, but costs a\n>                 lot more than the above.\n>               * ...and so on.\n>       * A logical load balancer object is a great demarcation\n>         point  between operator concerns and user concerns. It seems\n>         likely that there will be an operator API created, and this\n>         will need to interface with the user API at some well-defined\n>         interface. (If you like, I can provide a couple specific\n>         operator concerns which are much more easily accomplished\n>         without disrupting the user experience using the demarc at the\n>         \'load balancer\' instead of at the \'VIP\'.)\n>  \n> \n> \n> So what are the main arguments against having this container object?\n> In answering this question, please keep in mind:\n> \n> \n>  \n> \n> \n>       * If you say \"implementation details,\" please just go ahead and\n>         be more specific because that\'s what I\'m going to ask you to\n>         do anyway. If \"implementation details\" is the concern, please\n>         follow this with a hypothetical or concrete example as to what\n>         kinds of implementations this object would invalidate simply\n>         by existing in the model, or what restrictions this object\n>         introduces.\n>       * If you say \"I don\'t see a need\" then you\'re really just asking\n>         people to come up with a use case that is more easily solved\n>         using the logical load balancer object rather than the VIP\n>         without the load balancer. I hope my reasons above address\n>         this, but I\'m happy to be more specific if you\'d like: Please\n>         point out how my examples above are not convincing reasons for\n>         having this object, and I will be more specific.\n>  \n> \n> \n> Thanks,\n> \n> \n> Stephen\n> \n> \n>  \n> \n> \n>  \n> \n> On Fri, May 9, 2014 at 1:36 AM, Eugene Nikanorov\n> <enikanorov at mirantis.com> wrote:\n> \n> Hi Brandon\n> \n>  \n> \n>         Let me know if I am misunderstanding this,and please explain\n>         it\n>         \n>         \n>         further.\n>         A single neutron port can have many fixed ips on many\n>         subnets.  Since\n>         this is the case you\'re saying that there is no need for the\n>         API to\n>         define multiple VIPs since a single neutron port can represent\n>         all the\n>         IPs that all the VIPs require?\n>         \n> Right, if you want to to have both ipv4 and ipv6 addresses on the VIP\n> then it\'s possible with single neutron port.\n> \n> \n> So multiple VIPs for this case are not needed.\n> \n> \n>  \n> \n> \n> Eugene.\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n>  \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807 \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F36E8145F2571242A675F56CF60964560E60DF1F@ILMB1.corp.radware.com>',NULL),('<1399762892.3363.25.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-10 23:01:32',0,'2014-05-10 23:01:32',NULL,'[openstack-dev] [Neutron][LBaaS] Multiple VIPs per loadbalancer','Hi Eugene,\n\nSince this debate has come and gone before, I\'d like to thank you for\nhaving the patience to still be debating with us about it.  It\'s\nrequiring a lot of patience for everyone on both sides of the argument.\nA debate like this can be healthy though.\n\nI, too, have not heard clear and concise reasons why the core team\nmembers would not like a logical load balancer object, or a load\nbalancer object that maps to many vips, which in turn maps to many\nlisteners.  I\'ve been to every LBaaS meeting for months now I think, and\nI just remember that you and others have said the core team members\nobject to it, but not any clear reasons.  Would it be possible for you\nto point us to an IRC chat log or a ML thread that does discuss that?\n\nA lot of operators have come into this project lately and most (if not\nall) would prefer an API construct like the one BBG and Rackspace have\nagreed on.  This reason alone should be enough to revisit the topic with\nthe core team members so we operators can fully understand their\nobjections.  I believe operators should play a large role in Openstack\nand their opinions and reasons why should be heard.\n\nThanks,\nBrandon Logan\n\nOn Sat, 2014-05-10 at 10:52 +0400, Eugene Nikanorov wrote:\n> Hi Carlos,\n> \n> \n>         \n>         On May 9, 2014, at 3:36 PM, Eugene Nikanorov\n>         <enikanorov at mirantis.com>\n>          wrote:\n>         \n>         > Also we\'ve heard objection to this approach several times\n>         > from other core team members (this discussion has been going\n>         > for more than half a year now), so I would suggest to move\n>         > forward with single L2 port approach.\n>         \n>             Objections to multiple ports per loadbalancer or\n>         objections to the Loadbalancer object itself?\n>         \n>         \n>             If its the latter then you may have a valid argument by\n>         authority but its impossible to verify because these \"core\n>         team members\" are remaining silent through out all these\n>         discussions. We can\'t  be dissuaded due to FUD(Fear,\n>         Uncertainty and Doub)t  that these silent core team members\n>         will suddenly reject this discussion in the future. We aren\'t\n>         going to put our users at risk due to FUD.\n> I think you had a chance to hear this argument yourself (from several\n> different core members: Mark McClain, Salvatore Orlando, Kyle Mestery)\n> on those meetings we had in past 2 months.\n> I was advocating \'loadbalancer\' (in it\'s extended version) once too,\n> receiving negative opinions as well.\n> In general this approach puts too much of control of a backend to\n> user\'s hands and this goes in opposite direction than neutron project.\n> \n> \n> If it\'s just about the name of the root object - VIP suits this role\n> too, so I\'m fine with that. I also find VIP/Listeners model a bit more\n> clearer per definitions in our glossary.\n> \n> \n> Thanks,\n> Eugene.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOTfftq7p574WUUCd435L3kn-A7-B6eM9MQPiowfD=SnUQ@mail.gmail.com>',NULL),('<1399763373.3363.32.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-10 23:09:33',0,'2014-05-10 23:09:33',NULL,'[openstack-dev] [Neutron][LBaaS] API proposal review thoughts','On Sat, 2014-05-10 at 09:50 -0700, Stephen Balukoff wrote:\n\n> \n> Correct me if I\'m wrong, but wasn\'t \"the existing API is confusing and\n> difficult to use\" one of the major complaints with it (as voiced in\n> the IRC meeting, say on April 10th in IRC, starting around... I\n> dunno... 14:13 GMT)?  If that\'s the case, then the user experience\n> seems like an important concern, and possibly trumps some vaguely\n> defined \"project direction\" which apparently doesn\'t take this into\n> account if it\'s vetoing an approach which is more easily done /\n> understood by the user.\n\n+1 Stephen\n\nThis is what the API we are proposing accomplishes.  It is not\nconfusing.  Does having a root object of VIP work? Yes, but anything can\nbe made to work.  It\'s more about what makes sense.  To me going with an\nAPI similar to the existing one does not address this issue at all.\nAlso, what happened to a totally brand new API and object model in\nneutron V3?  I thought that was still on the table, and its the perfect\ntime to create a new load balancer API, backwards compatibility is not\nexpected.\n\nI\'d also like to ask why it seems to not matter at all if most (if not\nall) operators like an API proposal?\n\nThanks,\nBrandon Logan\n\n\n','<CAAGw+ZrVtoWtfG-Fr1NimZKGgYkL62UZpT_Y_fHWmeeNaPQgrg@mail.gmail.com>',NULL),('<1399796389583.64827@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-11 08:19:50',0,'2014-05-11 08:19:50',NULL,'[Openstack] [openstack][neutron] boot a VM with IPv6 address','Hi,\n\n\nWe have setup openstack and running services on IPv6 network. We are able to provision instance with IPv4 address.\n\n\nAny pointers to provision (nova boot) instance with IPv6 address?\n\n\nRegards,\n\nNagaraju B\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140511/d4a0cd8d/attachment.html>\n\n',NULL,NULL),('<1399796428116.22256@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-11 08:20:28',0,'2014-05-11 08:20:28',NULL,'[Openstack] [openstack][neutron] boot a VM with IPv6 address','?Hi,\n\n\nWe have setup openstack and running services on IPv6 network. We are able to provision instance with IPv4 address.\n\n\nAny pointers to provision (nova boot) instance with IPv6 address?\n\n\nRegards,\n\nNagaraju B\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140511/92ea781d/attachment.html>\n\n','<1399796389583.64827@persistent.co.in>',NULL),('<1399818365.15250.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-11 10:26:05',-14400,'2014-05-11 14:26:05',NULL,'[openstack-dev] [all] custom gerrit dashboard - per project\n review inbox zero','On Fri, 2014-05-09 at 08:20 -0400, Sean Dague wrote:\n> Based on some of my blog posts on gerrit queries, I\'ve built and gotten\n> integrated a custom inbox zero dashboard which is per project in gerrit.\n> \n> ex:\n> https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard\n> \n> (replace openstack/nova with the project of your choice).\n> \n> This provides 3 sections.\n> \n> = Needs Final +2 =\n> \n> This is code that has an existing +2, no negative code review feedback,\n> and positive jenkins score. So it\'s mergable if you provide the final +2.\n> \n> (Gerrit Query: status:open NOT label:Code-Review>=0,self\n> label:Verified>=1,jenkins NOT label:Code-Review<=-1 label:Code-Review>=2\n> NOT label:Workflow<=-1 limit:50 )\n> \n> = No negative feedback =\n> \n> Changes that have no negative code review feedback, and positive jenkins\n> score.\n> \n> (Gerrit Query: status:open NOT label:Code-Review>=0,self\n> label:Verified>=1,jenkins NOT label:Code-Review<=-1 NOT\n> label:Workflow<=-1 limit:50 )\n> \n> = Wayward changes =\n> \n> Changes that have no code review feedback at all (no one has looked at\n> it), a positive jenkins score, and are older than 2 days.\n> \n> (Gerrit Query: status:open label:Verified>=1,jenkins NOT\n> label:Workflow<=-1 NOT label:Code-Review<=2 age:2d)\n> \n> \n> In all cases it filters out patches that you\'ve commented on in the most\n> recently revision. So as you vote on these things they will disappear\n> from your list.\n> \n> Hopefully people will find this dashboard also useful.\n\nNicely done. Any reason you\'ve included the stable branches - i.e. not\nrestricted it to branch:master ?\n\nThanks,\nMark.\n\n\n\n','<536CC81A.2060101@dague.net>',NULL),('<1399846112.36.1372659916304.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-01 06:25:16',0,'2013-07-01 06:25:16',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #273','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/273/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:55171\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:55171/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (28321) wsgi starting up on http://127.0.0.1:55171/\n\nnova.osapi_compute.wsgi.server: INFO: (28321) accepted (\'127.0.0.1\', 40447)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/Jul/2013 06:20:08] \"GET /v2 HTTP/1.1\" 204 216 0.001051\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-635aa11c-70e1-4ce2-90e7-099ff837d847</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (28321) accepted (\'127.0.0.1\', 40448)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8b5a850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8b5a850>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:55171/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-07-01 06:20:08 28321 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:55171/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/Jul/2013 06:20:08] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.240246\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 3c774ae7565d4f2b8b31a2e273ef32f2 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:34123\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:34123/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (28321) wsgi starting up on http://127.0.0.1:34123/\n\nnova.osapi_compute.wsgi.server: INFO: (28321) accepted (\'127.0.0.1\', 52970)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/Jul/2013 06:20:09] \"GET /v2 HTTP/1.1\" 204 216 0.000751\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-23ff510c-8dbf-4915-a444-380bf5bc89a6</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (28321) accepted (\'127.0.0.1\', 52971)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7386850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x7386850>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:34123/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     name)\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-07-01 06:20:09 28321 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:34123/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [01/Jul/2013 06:20:09] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.275969\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.46\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.2\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.htJFPQ8NCt\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/273\n[SCP] Copying console log.\n\n\n','<976727918.33.1372573314055.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1399928892.1993.0.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-12 21:08:12',0,'2014-05-12 21:08:12',NULL,'[openstack-dev] [Neutron][LBaaS] Meetup?','Outside the room where most of the Neutron meetings have been.  B103 I\nbelieve.\n\nOn Mon, 2014-05-12 at 20:52 +0000, Samuel Bercovici wrote:\n> During our brief meeting today, we tentatively scheduled to meet today\n> at 5:30 PM. \n> Is this still on?\n> Where should we meet?\n> \n> Regards, \n>              -Sam.\n> \n> On May 12, 2014, at 1:10 PM, \"Adam Harwell\"\n> <adam.harwell at RACKSPACE.COM> wrote:\n> \n> \n> > Some of us are at a table towards the back by the B3b door (and a\n> > large restrooms sign).\n> > \n> > On May 12, 2014 12:24 PM, Adam Harwell <adam.harwell at RACKSPACE.COM>\n> > wrote:\n> > \n> > Yeah, I guess we\'ll try to catch people after this session (lunch\n> > officially starts at 12:45 apparently).\n> > \n> > On May 12, 2014 11:48 AM, Eugene Nikanorov <enikanorov at mirantis.com>\n> > wrote:\n> > \n> > I\'m going to attend the next nw session @b103, we can meet in\n> > between. Im in b103 too.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0C26B053-CE28-4E93-BAA8-5345680D8DD9@Radware.com>',NULL),('<1399989476.61661.YahooMailNeo@web171601.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-13 14:57:56',3600,'2014-05-13 13:57:56',NULL,'[Openstack] instances stuck in \"powering on\"','\n\nOn Monday, 12 May 2014, 19:19:42, Dimitri Maziuk <dmaziuk at bmrb.wisc.edu> wrote:\n>> TRACE nova.openstack.common.rpc.amqp\n>> task run WARNING nova.openstack.common.loopingcall [-] outlasted interval by 50.018454 sec\n>> ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager._sync_power_states: Timeout while waiting on RPC response - topic: \"conductor\", RPC method: \"object_class_action\" info: \"<unknown>\"\n>\n>-- completely unhelpful since I\'m getting tons of them during normal\n>operation, too.\n\n\nI would try increase number of conductor processes. By default it\'s just one process and it\'s probably unable to handle all the communication with you database.\n\n\nRadek.\n\n\n\n','<53710E7D.6010509@bmrb.wisc.edu>',NULL),('<1399995502.75063.YahooMailNeo@web142806.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-13 08:38:22',-25200,'2014-05-13 15:38:22',NULL,'[openstack-dev] running VM manually using openstack','Hey Sonia,\n?Do the backing file and instance directory exist??\"-drive file=/opt/stack/data/nova/instances/3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852/disk\" implies that both that directory exists and the instance image is contained within it.?\n-James\n\nOn Tuesday, May 13, 2014 6:22 AM, sonia verma <soniaverma9727 at gmail.com> wrote:\n \nHI \n\nI have install openstack using devstack.I\'m using multinode setup with one controller node and one compute node.I\'m able to launch VM from openstack dashboard onto the controller node.\nAt the controller node when i do ps -ef | grep nova,the following appears.. \n\n?ps -ef | grep nova\nroot?????? 799?? 798? 0 11:48 pts/22?? 00:00:00 sg libvirtd /usr/local/bin/nova-compute --config-file /etc/nova/nova.conf\nshiv?????? 801?? 799? 0 11:48 pts/22?? 00:00:55 /usr/bin/python /usr/local/bin/nova-compute --config-file /etc/nova/nova.conf\nshiv????? 1233? 1232? 1 11:48 pts/23?? 00:03:45 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf\nshiv????? 1457? 1233? 0 11:48 pts/23?? 00:00:45 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf\nshiv????? 1458? 1233? 0 11:48 pts/23?? 00:00:45 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf\nshiv????? 1459? 1233? 0 11:48 pts/23?? 00:00:45 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf\nshiv????? 1460? 1233? 0 11:48 pts/23?? 00:00:45 /usr/bin/python /usr/local/bin/nova-conductor --config-file /etc/nova/nova.conf\nshiv????? 1578? 1577? 0 11:48 pts/24?? 00:00:09 /usr/bin/python /usr/local/bin/nova-cert --config-file /etc/nova/nova.conf\nshiv????? 1880? 1879? 0 11:48 pts/25?? 00:00:10 /usr/bin/python /usr/local/bin/nova-scheduler --config-file /etc/nova/nova.conf\nshiv????? 2221? 2219? 0 11:48 pts/26?? 00:00:05 /usr/bin/python /usr/local/bin/nova-novncproxy --config-file /etc/nova/nova.conf --web /opt/stack/noVNC\nshiv????? 2431? 2429? 0 11:48 pts/27?? 00:00:00 /usr/bin/python /usr/local/bin/nova-xvpvncproxy --config-file /etc/nova/nova.conf\nshiv????? 2670? 2669? 0 11:48 pts/28?? 00:00:09 /usr/bin/python /usr/local/bin/nova-consoleauth --config-file /etc/nova/nova.conf\nshiv????? 2897? 2895? 0 11:48 pts/29?? 00:00:00 /usr/bin/python /usr/local/bin/nova-objectstore --config-file /etc/nova/nova.conf\n122????? 13484???? 1 19 15:43 ???????? 00:00:02 /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-00000003 -uuid cec324c7-2398-49b8-844b-08c6cca7fff3 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.2,serial=44454c4c-5600-1039-804c-c7c04f595831,uuid=cec324c7-2398-49b8-844b-08c6cca7fff3 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000003.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet -no-shutdown -drive file=/opt/stack/data/nova/instances/cec324c7-2398-49b8-844b-08c6cca7fff3/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive\n file=/opt/stack/data/nova/instances/cec324c7-2398-49b8-844b-08c6cca7fff3/disk.config,if=none,media=cdrom,id=drive-ide0-1-1,readonly=on,format=raw,cache=none -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=19,id=hostnet0,vhost=on,vhostfd=20 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:9b:09:3b,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/cec324c7-2398-49b8-844b-08c6cca7fff3/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -vnc 127.0.0.1:1 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5\nshiv???? 14867 20602? 0 15:43 pts/7??? 00:00:00 grep --color=auto nova\nshiv???? 31444 31443? 1 11:47 pts/16?? 00:03:45 /usr/bin/python /usr/local/bin/nova-api\nshiv???? 31469 31444? 0 11:47 pts/16?? 00:00:00 /usr/bin/python /usr/local/bin/nova-api\nshiv???? 31470 31444? 0 11:47 pts/16?? 00:00:00 /usr/bin/python /usr/local/bin/nova-api\nshiv???? 31471 31444? 0 11:47 pts/16?? 00:00:00 /usr/bin/python /usr/local/bin/nova-api\n\nI see the VM instance booted using KVM utility on to the controller node.\nHowever when i try to launch VM manually using the similar command but changing the instances id and name as above..\n\nsudo /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-00000002 -uuid 3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2014.2,serial=44454c4c-4400-1034-8042-c7c04f313032,uuid=3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000002.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-hpet -no-shutdown -drive file=/opt/stack/data/nova/instances/3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/stack/data/nova/instances/3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852/disk.config,if=none,media=cdrom,id=drive-ide0-1-1,readonly=on,format=raw,cache=none\n -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:1f:6e:47,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/opt/stack/data/nova/instances/3765ec4d-48d0-4f0b-9f7d-2f73ee3a3852/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -vnc 0.0.0.0:1 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \n\nI\'m getting below error..\n\nchardev: opening backend \"file\" failed: No such file or directory\n\nPlease help regarding this.\n\nThanks..\nSonia\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140513/69ffa4de/attachment.html>\n\n','<CAJ7Vayh4NFqV9pefto8pVPqThjiV76vo8-azQ-hM=qszfKY=Nw@mail.gmail.com>',NULL),('<13AAD1AE4DD9D4498B86A805BDE9903B024805A1@DB3PRD0302MB116.eurprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-04 10:29:48',0,'2011-11-04 10:29:48',NULL,'[Openstack-operators] Problems trying to run euca-upload-bundle','Hi all\n\nI\'m testing out Openstack for the first time, so please excuse my ignorance - this is a rather large and confusing beast.\n\nI\'m using Devstack running a laptop as outlined here:\n\nhttp://devstack.org/guides/single-machine.html#\n\nEverything is in the default config state.\n\nDevstack installed with no problems and I can login the Horizon and view instances as well as launch them.\n\nI\'m now trying to do a bit more. One of the things we want to do with Openstack is to run Windows instances so I\'ve created a Windows image as per this URL:\n\nhttp://docs.openstack.org/cactus/openstack-compute/admin/content/creating-a-windows-image.html\n\nIn order to even get euca-tools running, I had to go through the process of creating a set of user credentials via:\n\nhttp://wiki.openstack.org/RunningNova#Setting_up_your_user\n\nThis allowed me to run the euca-create-image command. However, when I try to upload the image, I get a connection refused error. It would seem that something is either not running or that something is not configured correctly. I have listed the error from this at the bottom of this mail.\n\nIt would seem that Image management is done by Glance. Glance seems to be running and I can see output from Horizon, but I cannot seem to get any meaningful output from the glance command line tool. ( eg: \"Exception: Unexpected response: 400\" ). I am confused.\n\nThere are some references to \"glancerc\" which I can\'t find any trace of in my documents. There is a rather confusing mailing list topic here which I tried to create a glancerc from, but I continue to get errors. The topic I refer to is: https://lists.launchpad.net/openstack/msg04613.html\n\nI\'m afraid that Googling for this has nor produced any helpful direction so I\'m now hoping for your expert knowledge :)\n\nWhat I would really like is to see some meaningful documentation on how glance and eucatools knit together. Am I missing something obvious here? The available documents seem to be extremely sparse. Any help would be greatly appreciated.\n\nOutput from euca-upload-bundle:\n\nstack at stack:~/stack_zip$ euca-upload-bundle -b windows_2008_32bit -m /tmp/windows_2008_32bit.img.manifest.xml\nChecking bucket: windows_2008_32bit\nTraceback (most recent call last):\n  File \"/usr/bin/euca-upload-bundle\", line 262, in <module>\n    main()\n  File \"/usr/bin/euca-upload-bundle\", line 240, in main\n    bucket_instance = ensure_bucket(conn, bucket, canned_acl)\n  File \"/usr/bin/euca-upload-bundle\", line 95, in ensure_bucket\n    bucket_instance = connection.get_bucket(bucket)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 275, in get_bucket\n    rs = bucket.get_all_keys(headers, maxkeys=0)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/bucket.py\", line 204, in get_all_keys\n    headers=headers, query_args=s)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 342, in make_request\n    data, host, auth_path, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 461, in make_request\n    return self._mexe(method, path, data, headers, host, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 439, in _mexe\n    raise e\nsocket.error: [Errno 111] Connection refused\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111104/03af0629/attachment.html>\n\n',NULL,NULL),('<13AAD1AE4DD9D4498B86A805BDE9903B0248081A@DB3PRD0302MB116.eurprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-04 10:59:09',0,'2011-11-04 10:59:09',NULL,'[Openstack-operators] Problems trying to run euca-upload-bundle','I top post because I prefer it - if you\'d rather I bottom post, please let me know.\n\nFurther to my initial mail, I think that there is a config problem somewhere.\n\nI wondered if I needed to do everything via an Admin user so I created an admin user as per:\n\nhttp://cssoss.wordpress.com/2011/04/27/openstack-beginners-guide-for-ubuntu-11-04-installation-and-configuration/\n\nRunning a basic eucalyptus check gives an error as listed below.\n\nI am wondering if I should re-install and NOT use Devstack? My problem is that Devstack automated everything and I don\'t know where the logs might be if something went wrong. Everything seems fine when I use the Horizon interface however so I\'m puzzled.\n\nroot at stack:/home/novaadmin/creds# euca-describe-availability-zones verbose\nWarning: failed to parse error message from AWS: <unknown>:1:0: syntax error\nEC2ResponseError: 400 Bad Request\n400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n\n\n\n\n________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] on behalf of Stephen Tan [stephen.tan at certivox.com]\nSent: 04 November 2011 10:29\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Problems trying to run euca-upload-bundle\n\nHi all\n\nI\'m testing out Openstack for the first time, so please excuse my ignorance - this is a rather large and confusing beast.\n\nI\'m using Devstack running a laptop as outlined here:\n\nhttp://devstack.org/guides/single-machine.html#\n\nEverything is in the default config state.\n\nDevstack installed with no problems and I can login the Horizon and view instances as well as launch them.\n\nI\'m now trying to do a bit more. One of the things we want to do with Openstack is to run Windows instances so I\'ve created a Windows image as per this URL:\n\nhttp://docs.openstack.org/cactus/openstack-compute/admin/content/creating-a-windows-image.html\n\nIn order to even get euca-tools running, I had to go through the process of creating a set of user credentials via:\n\nhttp://wiki.openstack.org/RunningNova#Setting_up_your_user\n\nThis allowed me to run the euca-create-image command. However, when I try to upload the image, I get a connection refused error. It would seem that something is either not running or that something is not configured correctly. I have listed the error from this at the bottom of this mail.\n\nIt would seem that Image management is done by Glance. Glance seems to be running and I can see output from Horizon, but I cannot seem to get any meaningful output from the glance command line tool. ( eg: \"Exception: Unexpected response: 400\" ). I am confused.\n\nThere are some references to \"glancerc\" which I can\'t find any trace of in my documents. There is a rather confusing mailing list topic here which I tried to create a glancerc from, but I continue to get errors. The topic I refer to is: https://lists.launchpad.net/openstack/msg04613.html\n\nI\'m afraid that Googling for this has nor produced any helpful direction so I\'m now hoping for your expert knowledge :)\n\nWhat I would really like is to see some meaningful documentation on how glance and eucatools knit together. Am I missing something obvious here? The available documents seem to be extremely sparse. Any help would be greatly appreciated.\n\nOutput from euca-upload-bundle:\n\nstack at stack:~/stack_zip$ euca-upload-bundle -b windows_2008_32bit -m /tmp/windows_2008_32bit.img.manifest.xml\nChecking bucket: windows_2008_32bit\nTraceback (most recent call last):\n  File \"/usr/bin/euca-upload-bundle\", line 262, in <module>\n    main()\n  File \"/usr/bin/euca-upload-bundle\", line 240, in main\n    bucket_instance = ensure_bucket(conn, bucket, canned_acl)\n  File \"/usr/bin/euca-upload-bundle\", line 95, in ensure_bucket\n    bucket_instance = connection.get_bucket(bucket)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 275, in get_bucket\n    rs = bucket.get_all_keys(headers, maxkeys=0)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/bucket.py\", line 204, in get_all_keys\n    headers=headers, query_args=s)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 342, in make_request\n    data, host, auth_path, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 461, in make_request\n    return self._mexe(method, path, data, headers, host, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 439, in _mexe\n    raise e\nsocket.error: [Errno 111] Connection refused\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111104/adafee97/attachment-0001.html>\n\n','<13AAD1AE4DD9D4498B86A805BDE9903B024805A1@DB3PRD0302MB116.eurprd03.prod.outlook.com>',NULL),('<13AAD1AE4DD9D4498B86A805BDE9903B024876C9@DB3PRD0302MB116.eurprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-07 10:30:21',0,'2011-11-07 10:30:21',NULL,'[Openstack-operators] Problems trying to run euca-upload-bundle','\nAfter running through the Devstack docs and scripts installed with Devstack, I have discovered that the nova-manage command is broken!\n\nThe other post this week appears to echo my experience.\n\n\"Error getting virtual servers up and running\"  by Alex Chen. He too appears to be suffering.\n\nStephen\n\n\n________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] on behalf of Stephen Tan [stephen.tan at certivox.com]\nSent: 04 November 2011 10:59\nTo: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Problems trying to run euca-upload-bundle\n\nI top post because I prefer it - if you\'d rather I bottom post, please let me know.\n\nFurther to my initial mail, I think that there is a config problem somewhere.\n\nI wondered if I needed to do everything via an Admin user so I created an admin user as per:\n\nhttp://cssoss.wordpress.com/2011/04/27/openstack-beginners-guide-for-ubuntu-11-04-installation-and-configuration/\n\nRunning a basic eucalyptus check gives an error as listed below.\n\nI am wondering if I should re-install and NOT use Devstack? My problem is that Devstack automated everything and I don\'t know where the logs might be if something went wrong. Everything seems fine when I use the Horizon interface however so I\'m puzzled.\n\nroot at stack:/home/novaadmin/creds# euca-describe-availability-zones verbose\nWarning: failed to parse error message from AWS: <unknown>:1:0: syntax error\nEC2ResponseError: 400 Bad Request\n400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n\n\n\n\n________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] on behalf of Stephen Tan [stephen.tan at certivox.com]\nSent: 04 November 2011 10:29\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Problems trying to run euca-upload-bundle\n\nHi all\n\nI\'m testing out Openstack for the first time, so please excuse my ignorance - this is a rather large and confusing beast.\n\nI\'m using Devstack running a laptop as outlined here:\n\nhttp://devstack.org/guides/single-machine.html#\n\nEverything is in the default config state.\n\nDevstack installed with no problems and I can login the Horizon and view instances as well as launch them.\n\nI\'m now trying to do a bit more. One of the things we want to do with Openstack is to run Windows instances so I\'ve created a Windows image as per this URL:\n\nhttp://docs.openstack.org/cactus/openstack-compute/admin/content/creating-a-windows-image.html\n\nIn order to even get euca-tools running, I had to go through the process of creating a set of user credentials via:\n\nhttp://wiki.openstack.org/RunningNova#Setting_up_your_user\n\nThis allowed me to run the euca-create-image command. However, when I try to upload the image, I get a connection refused error. It would seem that something is either not running or that something is not configured correctly. I have listed the error from this at the bottom of this mail.\n\nIt would seem that Image management is done by Glance. Glance seems to be running and I can see output from Horizon, but I cannot seem to get any meaningful output from the glance command line tool. ( eg: \"Exception: Unexpected response: 400\" ). I am confused.\n\nThere are some references to \"glancerc\" which I can\'t find any trace of in my documents. There is a rather confusing mailing list topic here which I tried to create a glancerc from, but I continue to get errors. The topic I refer to is: https://lists.launchpad.net/openstack/msg04613.html\n\nI\'m afraid that Googling for this has nor produced any helpful direction so I\'m now hoping for your expert knowledge :)\n\nWhat I would really like is to see some meaningful documentation on how glance and eucatools knit together. Am I missing something obvious here? The available documents seem to be extremely sparse. Any help would be greatly appreciated.\n\nOutput from euca-upload-bundle:\n\nstack at stack:~/stack_zip$ euca-upload-bundle -b windows_2008_32bit -m /tmp/windows_2008_32bit.img.manifest.xml\nChecking bucket: windows_2008_32bit\nTraceback (most recent call last):\n  File \"/usr/bin/euca-upload-bundle\", line 262, in <module>\n    main()\n  File \"/usr/bin/euca-upload-bundle\", line 240, in main\n    bucket_instance = ensure_bucket(conn, bucket, canned_acl)\n  File \"/usr/bin/euca-upload-bundle\", line 95, in ensure_bucket\n    bucket_instance = connection.get_bucket(bucket)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 275, in get_bucket\n    rs = bucket.get_all_keys(headers, maxkeys=0)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/bucket.py\", line 204, in get_all_keys\n    headers=headers, query_args=s)\n  File \"/usr/lib/pymodules/python2.7/boto/s3/connection.py\", line 342, in make_request\n    data, host, auth_path, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 461, in make_request\n    return self._mexe(method, path, data, headers, host, sender)\n  File \"/usr/lib/pymodules/python2.7/boto/connection.py\", line 439, in _mexe\n    raise e\nsocket.error: [Errno 111] Connection refused\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111107/dc9dd389/attachment-0001.html>\n\n','<13AAD1AE4DD9D4498B86A805BDE9903B0248081A@DB3PRD0302MB116.eurprd03.prod.outlook.com>',NULL),('<13B1D1A3-9423-4E6C-90CA-600F8CE904E0@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-19 17:53:30',7200,'2013-08-19 15:53:30',NULL,'[Openstack] SSH permissions (was: Re: Error during live\n	migration)','quick question, how do you migrate the instance ? and does it belong to the tenant?\n\n\nLe 19 ao?t 2013 ? 15:36, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n\n> The VM looks to be there:\n> \n> du -h instances/\n> 4,0K	instances/keys\n> 1,9G	instances/_base\n> 0	instances/locks\n> 310M	instances/edca1460-9c97-475e-997b-3266b235e797\n> 260M	instances/0fe59b28-04a3-41bb-9926-b7d139a70548\n> 323M	instances/aeda1c56-72ba-40a7-9857-01a622540505\n> 7,0M	instances/f4af662d-ae55-4346-82cf-a997192706b5\n> 264M	instances/483f98e3-8ef5-43e2-8c3a-def55abdabcd\n> 268M	instances/eeb81e32-32ce-49fa-8249-afc572f26233\n> 268M	instances/c0224f0d-d7e8-4621-8c1a-af68740a3267\n> 188M	instances/72ec37a3-b209-4729-b628-005fdcea5a3c\n> 12M	instances/2c7c123b-456a-4c70-a991-80efee541324\n> 11M	instances/c9e1c5ed-a108-4196-bfbc-24495e2e71bd\n> 6,5M	instances/96d8f2de-a72d-40b5-b083-1f5e511f91ce\n> 531M	instances/1b35a4a6-e158-48d3-a804-44b05ec171d0\n> 529M	instances/1a2b6146-6ef0-4d76-a603-e4715b4dfb62\n> 514M	instances/f6cb9f81-9281-419f-9e20-adaa6a07cea3\n> 2,7G	instances/75e479cf-37a4-4511-b2a5-d4f3027702d4_resize\n> 2,4G	instances/75e479cf-37a4-4511-b2a5-d4f3027702d4\n> 11G	instances/\n> \n> \n> It\'s still running, no Error messagem from dashboard (it is showing Status: Resize/Migrate - Task: Resizing or Migrating - Power State: Running). The logs are not showing that permission error anymore. Should I wait to see if it will migrate or returns another error status? One thing is true, the machine is really slow now :P\n> \n> Regards.\n> \n> Guilherme.\n> \n> \n> 2013/8/19 Razique Mahroua <razique.mahroua at gmail.com>\n> Looks like the file doesn\'t exist.\n> Can you spawn a new instance and try to migrate it again?\n> thanks\n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 19 ao?t 2013 ? 13:41, Guilherme Russi <luisguilherme.cr at gmail.com> a ?crit :\n> \n>> Hello Peter,\n>> \n>>  Thank you for your help too :)\n>>  I\'ve changed the permission and now I\'m getting another error when I try to migrate:\n>> \n>> cat /var/log/nova/nova-compute.log | grep -E ERROR\n>> 2013-08-19 08:17:19.990 12667 ERROR nova.manager [-] Error during ComputeManager._run_image_cache_manager_pass: Unexpected error while running command.\n>> 2013-08-19 08:23:40.309 12667 ERROR nova.network.quantumv2 [-] _get_auth_token() failed\n>> 2013-08-19 08:24:27.013 12667 ERROR nova.virt.libvirt.driver [-] Getting disk size of instance-000000bc: [Errno 2] No such file or directory: \'/var/lib/nova/instances/75e479cf-37a4-4511-b2a5-d4f3027702d4/disk\'\n>> \n>> \n>> cat /var/log/nova/nova-compute.log | grep -E TRACE\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Traceback (most recent call last):\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/manager.py\", line 241, in periodic_tasks\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     task(self, context)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 4020, in _run_image_cache_manager_pass\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self.driver.manage_image_cache(context, filtered_instances)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3401, in manage_image_cache\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self.image_cache_manager.verify_base_images(context, all_instances)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagecache.py\", line 588, in verify_base_images\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     self._handle_base_image(img, base_file)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagecache.py\", line 553, in _handle_base_image\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     virtutils.chown(base_file, os.getuid())\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py\", line 449, in chown\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     execute(\'chown\', owner, path, run_as_root=True)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py\", line 47, in execute\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     return utils.execute(*args, **kwargs)\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager   File \"/usr/lib/python2.7/dist-packages/nova/utils.py\", line 239, in execute\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager     cmd=\' \'.join(cmd))\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager ProcessExecutionError: Unexpected error while running command.\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Command: sudo nova-rootwrap /etc/nova/rootwrap.conf chown 123 /var/lib/nova/instances/_base/b0d90eb60f048f6de16c3efbc0eb4c16cbac77a6\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Exit code: 1\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Stdout: \'\'\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager Stderr: \'Traceback (most recent call last):\\n  File \"/usr/bin/nova-rootwrap\", line 108, in <module>\\n    os.getlogin(), pwd.getpwuid(os.getuid())[0],\\nOSError: [Errno 22] Invalid argument\\n\'\n>> 2013-08-19 08:17:19.990 12667 TRACE nova.manager \n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2 Traceback (most recent call last):\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2   File \"/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py\", line 40, in _get_auth_token\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2     httpclient.authenticate()\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2   File \"/usr/lib/python2.7/dist-packages/quantumclient/client.py\", line 198, in authenticate\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2     raise exceptions.Unauthorized(message=body)\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2 Unauthorized: Request Timeout\n>> 2013-08-19 08:23:40.309 12667 TRACE nova.network.quantumv2\n>> \n>> Any ideas?\n>> \n>> Regards.\n>> \n>> Guilherme.\n>> \n>> \n>> 2013/8/19 Peter Funk <pf at artcom-gmbh.de>\n>> Guilherme Russi wrote 16.08.2013 um 09:53:\n>> >  Here is my directory configs:\n>> >\n>> > drwxrwxrwx  2 nova nova     76 Ago 15 14:54 .ssh\n>> >\n>> > I made chmod a+xwr at the folder at all computers, I made it because I\n>> > couldn\'t find the reason I was no allowed to migrate, can it be like that?\n>> \n>> For SSH to work the permissions of $HOME/.ssh should look like this:\n>>   drwx------  2 nova nova     76 Ago 15 14:54 .ssh\n>> \n>> Use:\n>>   chmod -R go-rwx .ssh\n>> \n>> Regards, Peter Funk\n>> --\n>> Peter Funk, home: ?Oldenburger Str.86, D-27777 Ganderkesee\n>> mobile:+49-179-640-8878 phone:+49-421-20419-0 <http://www.artcom-gmbh.de/>\n>> office: ArtCom GmbH, ?Haferwende 2, D-28357 Bremen, Germany\n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> _______________________________________________\n>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130819/f7f730a8/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 535 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130819/f7f730a8/attachment.pgp>\n\n','<CAKz5Ux8qHuNjN12zCYT-XpVJ-Pnbxv6F=YvgtOs=ovqPk=zr1Q@mail.gmail.com>',NULL),('<13BE8AB6-176A-494A-BD5C-69C29FF482A9@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 13:43:02',-25200,'2014-03-14 20:43:02',NULL,'[openstack-dev] Hierarchicical Multitenancy Discussion','Awesome, this is exactly what I was thinking. I think this is really close to being usable on the nova side. First of all the dot.sperated.form looks better imo, and I think my code should still work that way as well. The other piece that is needed is mapping ids to names for display purposes. I did something like this for a prototype of names in dns caching that should work nicely. The question simply becomes how do we expose those names. I?m thinking we have to add an output field to the display of objects in the system showing the fully qualified name.  We can then switch the display in novaclient to show names instead of ids.  That way an admin listing all the projects in orga would see the owner as orga.projb instead of the id string.\n\nThe other option would be to pass names instead of ids from keystone and store those instead. That seems simpler at first glance, it is not backwards compatible with the current model so it will be painful for providers to switch.\n\nVish\n\nOn Mar 14, 2014, at 12:06 PM, Telles Nobrega <tellesnobrega at gmail.com> wrote:\n\n> Vish, I tried making the repo a little better.\n> Here it is:\n> https://github.com/tellesnobrega/nova/tree/multitenancy\n> https://github.com/tellesnobrega/keystone/tree/hierarchical_projects\n> https://github.com/tellesnobrega/devstack/tree/multitenancy\n> https://github.com/tellesnobrega/python-keystoneclient/tree/multitenancy\n> \n> Hope to hear from you soon.\n> \n> \n> \n> On Fri, Mar 7, 2014 at 3:22 PM, Raildo Mascena <raildom at gmail.com> wrote:\n> Hello, \n> \n> First, I realized that there was no meeting today, was there a problem, or change in schedule? \n> \n> I would like to know if anyone has tested/Reviewed on the prototype that we implemented Telles and I, what did you think? I would like to know if there is any other functionality that can help. \n> \n> Thank you in advance.\n> \n> \n> 2014-02-26 1:14 GMT-03:00 Adam Young <ayoung at redhat.com>:\n> On 02/20/2014 05:18 PM, Vishvananda Ishaya wrote:\n>> \n>> On Feb 19, 2014, at 5:58 PM, Adam Young <ayoung at redhat.com> wrote:\n>> \n>>> On 02/18/2014 02:28 PM, Vishvananda Ishaya wrote:\n>>>> \n>>>> On Feb 18, 2014, at 11:04 AM, Adam Young <ayoung at redhat.com> wrote:\n>>>> \n>>>>> On 02/18/2014 12:53 PM, Telles Nobrega wrote:\n>>>>>> Hello everyone,\n>>>>>> \n>>>>>> Me and Raildo were responsible to implement Hierarchical Projects in Keystone.\n>>>>>> \n>>>>>> Here is our first prototype: https://github.com/tellesnobrega/keystone_hierarchical_projects\n>>>>>> \n>>>>>> We want to have it tested with Vishy\'s implementation this week.\n>>>>>> \n>>>>>> Here is a  guide on how to test the implementation:\n>>>>>> \n>>>>>> 1. Start a devstack using the keystone code;\n>>>>>> 2. Create a new project using the following body:\n>>>>>>     {\n>>>>>>     \"project\": {\n>>>>>>         \"description\": \"test_project\",\n>>>>>>         \"domain_id\": \"default\",\n>>>>>>         \"parent_project_id\": \"$parent_project_id\",\n>>>>>>         \"enabled\": true,\n>>>>>>         \"name\": \"test_project\"\n>>>>>>     }\n>>>>>> }\n>>>>>> \n>>>>>> 3. Give an user a role in the project;\n>>>>>> 4. Get a token for \"test_project\" and check that the hierarchy is there like the following:\n>>>>>>     {\n>>>>>>     \"token\": {\n>>>>>>         \"methods\": [\n>>>>>>             \"password\"\n>>>>>>         ],\n>>>>>>         \"roles\": [\n>>>>>>             {\n>>>>>>                 \"id\": \"c60f0d7461354749ae8ac8bace3e35c5\",\n>>>>>>                 \"name\": \"admin\"\n>>>>>>             }\n>>>>>>         ],\n>>>>>>         \"expires_at\": \"2014-02-18T15:52:03.499433Z\",\n>>>>>>         \"project\": {\n>>>>>>             \"hierarchical_ids\": \"openstack.8a4ebcf44ebc47e0b98d3d5780c1f71a.de2a7135b01344cd82a02117c005ce47\",\n>>>>> \n>>>>> These should be names, not Ids.  There is going to be a need to move projecst around inside the hierarchy, and the ID stays the same.  Lets get this right up front.\n>>>> \n>>>> Can you give more detail here? I can see arguments for both ways of doing this but continuing to use ids for ownership is an easier choice. Here is my thinking:\n>>>> \n>>>> 1. all of the projects use ids for ownership currently so it is a smaller change\n>>> That does not change.  It is the hierarchy that is labeled by name.\n>> \n>> The issue is that we are storing the hierarchy of ownership in nova. We can either store the hierarchy by id or by name. Note that we are not adding a new field for this hierarchy but using the existing ownership field (which is called project_id in nova). My point is that if we use ids, then this field would be backwards compatible. If we decide to use name instead (which has some advantages for display purposes), then we would need some kind of db sync migration which modifies all of the fields from id -> name.\n>>> \n>>>> 2. renaming a project in keystone would not invalidate the ownership hierarchy (Note that moving a project around would invalidate the hierarchy in both cases)\n>>>> \n>>> Renaming would not change anything. \n>>> \n>>> I would say the rule should be this:  Ids are basically uuids, and are immutable.  Names a mutable.  Each project has a parent Id.  A project can either be referenced directly by ID, oir hierarchically by name.  In addition, you can navigate to a project by traversing the set of ids, but you need to know where you are going.  THus the array \n>>> \n>>> [\'abcd1234\',fedd3213\',\'3e3e3e3e\'] would be a way to find a project, but the project ID for the lead node would still be just \'3e3e3e3e?.\n>> \n>> As I mention above, all of this makes sense inside of keystone, but doesn?t address the problem of how we are storing the hierarchy on the nova side. The owner field in nova can be:\n>> \n>> 1) abcd1234.fedd3213.3e3e3e3e\n>> \n>> or it can be:\n>> \n>> 2) orga.proja.suba\n> \n> Owner should be separate from project.  But that is an aside.  I think you are mixing two ideas together.  Lets sit down at the summit to clear this up, but the Ids should not be hierarchical, the names should, and if you mess with that, it is going to be, well, a mess....\n> \n> We have a lot going on getting ready for Icehouse 3, and I don\'t want to be rushed on this, as we will have to live with it for a long time.  Nova is not the only consumer of projects, and we need to make something that works across the board.\n> \n> \n>> \n>> To explicitly state the tradeoffs\n>> \n>> 1 is backwards compatible +\n> We are actually doing something like this for domain users:  userid@@domainid  where both are UUIDs (or possible userid comes out of ldap) but the hierarchy there is only two level.  It is necessary there because one part is assigned by keysotne (domain id) and one part by LDAP or the remote IdP.\n>> 1 doesn?t need to be updated if a project is renamed +\n> But it does need to be redone of the project gets moved in the hierarchy, and we have a pre-existing feature request for that.\n> \n>> 1 is not user friendly (need to map ids to names to display to the user) -\n> You need to walk the tree to generate the \"good\" name.  But that can also be used to navigate.  Path names like URLs are unsurprising.  Hieriarch IDs are not.\n>> \n>> both need to be updated if a project is moved in the hierarchy\n> Notif the project only knows its local name.\n> \n> Owner can continue to be the short id.  You onlky need to map to translate for readability.  Its like SQL:  use a view to denormalize.\n>> \n>> Vish\n>> \n>>> \n>>> \n>>>> OTOTH the advantage of names is it makes displaying the ownership much easier on the service side.\n>>>> \n>>>> Vish\n>>>> \n>>>>> \n>>>>>>             \"hierarchy\": \"test1\",\n>>>>>>             \"domain\": {\n>>>>>>                 \"id\": \"default\",\n>>>>>>                 \"name\": \"Default\"\n>>>>>>             },\n>>>>>>             \"id\": \"de2a7135b01344cd82a02117c005ce47\",\n>>>>>>             \"name\": \"test1\"\n>>>>>>         },\n>>>>>>         \"extras\": {},\n>>>>>>         \"user\": {\n>>>>>>             \"domain\": {\n>>>>>>                 \"id\": \"default\",\n>>>>>>                 \"name\": \"Default\"\n>>>>>>             },\n>>>>>>             \"id\": \"895864161f1e4beaae42d9392ec105c8\",\n>>>>>>             \"name\": \"admin\"\n>>>>>>         },\n>>>>>>         \"issued_at\": \"2014-02-18T14:52:03.499478Z\"\n>>>>>>     }\n>>>>>> }\n>>>>>> \n>>>>>> Openstack is the root project of the tree, it can be seen also when getting a token for the admin project or other default project in Devstack.\n>>>>>> \n>>>>>> Hope to hear your feedbacks soon.\n>>>>>> \n>>>>>> Thanks\n>>>>>> \n>>>>>> \n>>>>>> On Mon, Feb 17, 2014 at 6:09 AM, Vinod Kumar Boppanna <vinod.kumar.boppanna at cern.ch> wrote:\n>>>>>> Dear Vish,\n>>>>>> \n>>>>>> I will change the concept of parsing roles upto leaf node to parsing the roles to the top upto the level 1. But i have small doubt and i want to confirm with you before doing this change.\n>>>>>> \n>>>>>> If there are lets say 10 levels in the hierarchy and the user is getting authenticated at level 9. Should i check the roles starting from level 9 upto level 1. Ofcourse, the difference here is (compared to what i put in the wiki page) that, only roles at each level (if different) needs to be added to scope and no need of adding the project name and role individually. Is this ok, considering the fact that the more deeper in the hierarchy the user is getting authenticated, the more time needed to parse upto the level 1.\n>>>>>> \n>>>>>> I will wait for your response and then modify the POC accordingly.\n>>>>>> \n>>>>>> Thanks & Regards,\n>>>>>> Vinod Kumar Boppanna\n>>>>>> ________________________________________\n>>>>>> From: openstack-dev-request at lists.openstack.org [openstack-dev-request at lists.openstack.org]\n>>>>>> Sent: 16 February 2014 22:21\n>>>>>> To: openstack-dev at lists.openstack.org\n>>>>>> Subject: OpenStack-dev Digest, Vol 22, Issue 45\n>>>>>> \n>>>>>> Send OpenStack-dev mailing list submissions to\n>>>>>>         openstack-dev at lists.openstack.org\n>>>>>> \n>>>>>> To subscribe or unsubscribe via the World Wide Web, visit\n>>>>>>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> or, via email, send a message with subject or body \'help\' to\n>>>>>>         openstack-dev-request at lists.openstack.org\n>>>>>> \n>>>>>> You can reach the person managing the list at\n>>>>>>         openstack-dev-owner at lists.openstack.org\n>>>>>> \n>>>>>> When replying, please edit your Subject line so it is more specific\n>>>>>> than \"Re: Contents of OpenStack-dev digest...\"\n>>>>>> \n>>>>>> \n>>>>>> Today\'s Topics:\n>>>>>> \n>>>>>>    1. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold\n>>>>>>       migration (Gary Kotton)\n>>>>>>    2. [Neutron]Do you think tanent_id should be verified (Dong Liu)\n>>>>>>    3. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold\n>>>>>>       migration (Jay Lau)\n>>>>>>    4. [neutron][policy] Using network services with network\n>>>>>>       policies (Mohammad Banikazemi)\n>>>>>>    5. Re: [Nova][VMWare] VMwareVCDriver related to resize/cold\n>>>>>>       migration (Jay Lau)\n>>>>>>    6. Re: [keystone] role of Domain in VPC definition (Harshad Nakil)\n>>>>>>    7. Re: VPC Proposal (Harshad Nakil)\n>>>>>>    8. Re: VPC Proposal (Allamaraju, Subbu)\n>>>>>>    9. Re: VPC Proposal (Harshad Nakil)\n>>>>>>   10. Re: VPC Proposal (Martin, JC)\n>>>>>>   11. Re: [keystone] role of Domain in VPC definition\n>>>>>>       (Allamaraju, Subbu)\n>>>>>>   12. Re: [keystone] role of Domain in VPC definition (Harshad Nakil)\n>>>>>>   13. Re: [keystone] role of Domain in VPC definition\n>>>>>>       (Allamaraju, Subbu)\n>>>>>>   14. Re: [OpenStack-Infra] [TripleO] promoting devtest_seed and\n>>>>>>       devtest_undercloud to voting, + experimental queue for\n>>>>>>       nova/neutron etc. (Robert Collins)\n>>>>>>   15. Re: [OpenStack-Infra] [TripleO] promoting devtest_seed and\n>>>>>>       devtest_undercloud to voting, + experimental queue for\n>>>>>>       nova/neutron etc. (Robert Collins)\n>>>>>>   16. Re: [keystone] role of Domain in VPC definition (Ravi Chunduru)\n>>>>>>   17. Re: VPC Proposal (Ravi Chunduru)\n>>>>>>   18. Re: OpenStack-dev Digest, Vol 22, Issue 39 (Vishvananda Ishaya)\n>>>>>>   19. Re: heat run_tests.sh fails with one huge line    of      output\n>>>>>>       (Mike Spreitzer)\n>>>>>> \n>>>>>> \n>>>>>> ----------------------------------------------------------------------\n>>>>>> \n>>>>>> Message: 1\n>>>>>> Date: Sun, 16 Feb 2014 05:40:05 -0800\n>>>>>> From: Gary Kotton <gkotton at vmware.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to\n>>>>>>         resize/cold migration\n>>>>>> Message-ID: <CF268BE4.465C7%gkotton at vmware.com>\n>>>>>> Content-Type: text/plain; charset=\"us-ascii\"\n>>>>>> \n>>>>>> Hi,\n>>>>>> There are two issues here.\n>>>>>> The first is a bug fix that is in review:\n>>>>>> - https://review.openstack.org/#/c/69209/ (this is where they have the same configuration)\n>>>>>> The second is WIP:\n>>>>>> - https://review.openstack.org/#/c/69262/ (we need to restore)\n>>>>>> Thanks\n>>>>>> Gary\n>>>>>> \n>>>>>> From: Jay Lau <jay.lau.513 at gmail.com<mailto:jay.lau.513 at gmail.com>>\n>>>>>> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n>>>>>> Date: Sunday, February 16, 2014 6:39 AM\n>>>>>> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n>>>>>> Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to resize/cold migration\n>>>>>> \n>>>>>> Hey,\n>>>>>> \n>>>>>> I have one question related with OpenStack vmwareapi.VMwareVCDriver resize/cold migration.\n>>>>>> \n>>>>>> The following is my configuration:\n>>>>>> \n>>>>>>  DC\n>>>>>>     |\n>>>>>>     |----Cluster1\n>>>>>>     |          |\n>>>>>>     |          |----9.111.249.56\n>>>>>>     |\n>>>>>>     |----Cluster2\n>>>>>>                |\n>>>>>>                |----9.111.249.49\n>>>>>> \n>>>>>> Scenario 1:\n>>>>>> I started two nova computes manage the two clusters:\n>>>>>> 1) nova-compute1.conf\n>>>>>> cluster_name=Cluster1\n>>>>>> \n>>>>>> 2) nova-compute2.conf\n>>>>>> cluster_name=Cluster2\n>>>>>> \n>>>>>> 3) Start up two nova computes on host1 and host2 separately\n>>>>>> 4) Create one VM instance and the VM instance was booted on Cluster2 node  9.111.249.49\n>>>>>> | OS-EXT-SRV-ATTR:host                 | host2 |\n>>>>>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | domain-c16(Cluster2)                                                                 |\n>>>>>> 5) Cold migrate the VM instance\n>>>>>> 6) After migration finished, the VM goes to VERIFY_RESIZE status, and \"nova show\" indicates that the VM now located on host1:Cluster1\n>>>>>> | OS-EXT-SRV-ATTR:host                 | host1 |\n>>>>>> | OS-EXT-SRV-ATTR:hypervisor_hostname  | domain-c12(Cluster1)                                                                 |\n>>>>>> 7) But from vSphere client, it indicates the the VM was still running on Cluster2\n>>>>>> 8) Try to confirm the resize, confirm will be failed. The root cause is that nova compute on host2 has no knowledge of domain-c12(Cluster1)\n>>>>>> \n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2810, in do_confirm_resize\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp     migration=migration)\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2836, in _confirm_resize\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp     network_info)\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 420, in confirm_migration\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp     _vmops = self._get_vmops_for_compute_node(instance[\'node\'])\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 523, in _get_vmops_for_compute_node\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp     resource = self._get_resource_for_node(nodename)\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 515, in _get_resource_for_node\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp     raise exception.NotFound(msg)\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp NotFound: NV-3AB798A The resource domain-c12(Cluster1) does not exist\n>>>>>> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> \n>>>>>> \n>>>>>> Scenario 2:\n>>>>>> \n>>>>>> 1) Started two nova computes manage the two clusters, but the two computes have same nova conf.\n>>>>>> 1) nova-compute1.conf\n>>>>>> cluster_name=Cluster1\n>>>>>> cluster_name=Cluster2\n>>>>>> \n>>>>>> 2) nova-compute2.conf\n>>>>>> cluster_name=Cluster1\n>>>>>> cluster_name=Cluster2\n>>>>>> \n>>>>>> 3) Then create and resize/cold migrate a VM, it can always succeed.\n>>>>>> \n>>>>>> \n>>>>>> Questions:\n>>>>>> For multi-cluster management, does vmware require all nova compute have same cluster configuration to make sure resize/cold migration can succeed?\n>>>>>> \n>>>>>> --\n>>>>>> Thanks,\n>>>>>> \n>>>>>> Jay\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/0b71a846/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 2\n>>>>>> Date: Sun, 16 Feb 2014 22:52:01 +0800\n>>>>>> From: Dong Liu <willowd878 at gmail.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: [openstack-dev] [Neutron]Do you think tanent_id should be\n>>>>>>         verified\n>>>>>> Message-ID: <26565D39-5372-48A5-8299-34DDE6C3394D at gmail.com>\n>>>>>> Content-Type: text/plain; charset=us-ascii\n>>>>>> \n>>>>>> Hi stackers:\n>>>>>> \n>>>>>> I found that when creating network subnet and other resources, the attribute tenant_id\n>>>>>> can be set by admin tenant. But we did not verify that if the tanent_id is real in keystone.\n>>>>>> \n>>>>>> I know that we could use neutron without keystone, but do you think tenant_id should\n>>>>>> be verified when we using neutron with keystone.\n>>>>>> \n>>>>>> thanks\n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 3\n>>>>>> Date: Sun, 16 Feb 2014 23:01:17 +0800\n>>>>>> From: Jay Lau <jay.lau.513 at gmail.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to\n>>>>>>         resize/cold migration\n>>>>>> Message-ID:\n>>>>>>         <CAFyztAFqTUqTZzzW6BkH6-9_kye9ZGm8yhZe3hMUoW1xFfQM7A at mail.gmail.com>\n>>>>>> Content-Type: text/plain; charset=\"iso-8859-1\"\n>>>>>> \n>>>>>> Thanks Gary, clear now. ;-)\n>>>>>> \n>>>>>> \n>>>>>> 2014-02-16 21:40 GMT+08:00 Gary Kotton <gkotton at vmware.com>:\n>>>>>> \n>>>>>> > Hi,\n>>>>>> > There are two issues here.\n>>>>>> > The first is a bug fix that is in review:\n>>>>>> > - https://review.openstack.org/#/c/69209/ (this is where they have the\n>>>>>> > same configuration)\n>>>>>> > The second is WIP:\n>>>>>> > - https://review.openstack.org/#/c/69262/ (we need to restore)\n>>>>>> > Thanks\n>>>>>> > Gary\n>>>>>> >\n>>>>>> > From: Jay Lau <jay.lau.513 at gmail.com>\n>>>>>> > Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" <\n>>>>>> > openstack-dev at lists.openstack.org>\n>>>>>> > Date: Sunday, February 16, 2014 6:39 AM\n>>>>>> > To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>\n>>>>>> > Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to\n>>>>>> > resize/cold migration\n>>>>>> >\n>>>>>> > Hey,\n>>>>>> >\n>>>>>> > I have one question related with OpenStack vmwareapi.VMwareVCDriver\n>>>>>> > resize/cold migration.\n>>>>>> >\n>>>>>> > The following is my configuration:\n>>>>>> >\n>>>>>> >  DC\n>>>>>> >     |\n>>>>>> >     |----Cluster1\n>>>>>> >     |          |\n>>>>>> >     |          |----9.111.249.56\n>>>>>> >     |\n>>>>>> >     |----Cluster2\n>>>>>> >                |\n>>>>>> >                |----9.111.249.49\n>>>>>> >\n>>>>>> > *Scenario 1:*\n>>>>>> > I started two nova computes manage the two clusters:\n>>>>>> > 1) nova-compute1.conf\n>>>>>> > cluster_name=Cluster1\n>>>>>> >\n>>>>>> > 2) nova-compute2.conf\n>>>>>> > cluster_name=Cluster2\n>>>>>> >\n>>>>>> > 3) Start up two nova computes on host1 and host2 separately\n>>>>>> > 4) Create one VM instance and the VM instance was booted on Cluster2 node\n>>>>>> > 9.111.249.49\n>>>>>> > | OS-EXT-SRV-ATTR:host                 | host2 |\n>>>>>> > | OS-EXT-SRV-ATTR:hypervisor_hostname  |\n>>>>>> > domain-c16(Cluster2)                                     |\n>>>>>> > 5) Cold migrate the VM instance\n>>>>>> > 6) After migration finished, the VM goes to VERIFY_RESIZE status, and\n>>>>>> > \"nova show\" indicates that the VM now located on host1:Cluster1\n>>>>>> > | OS-EXT-SRV-ATTR:host                 | host1 |\n>>>>>> > | OS-EXT-SRV-ATTR:hypervisor_hostname  |\n>>>>>> > domain-c12(Cluster1)                                     |\n>>>>>> > 7) But from vSphere client, it indicates the the VM was still running on\n>>>>>> > Cluster2\n>>>>>> > 8) Try to confirm the resize, confirm will be failed. The root cause is\n>>>>>> > that nova compute on host2 has no knowledge of domain-c12(Cluster1)\n>>>>>> >\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> > \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2810, in\n>>>>>> > do_confirm_resize\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > migration=migration)\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> > \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2836, in\n>>>>>> > _confirm_resize\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > network_info)\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> > \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 420,\n>>>>>> > in confirm_migration\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > _vmops = self._get_vmops_for_compute_node(instance[\'node\'])\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> > \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 523,\n>>>>>> > in _get_vmops_for_compute_node\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > resource = self._get_resource_for_node(nodename)\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> > \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 515,\n>>>>>> > in _get_resource_for_node\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > raise exception.NotFound(msg)\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> > NotFound: NV-3AB798A The resource domain-c12(Cluster1) does not exist\n>>>>>> > 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >\n>>>>>> >\n>>>>>> > *Scenario 2:*\n>>>>>> >\n>>>>>> > 1) Started two nova computes manage the two clusters, but the two computes\n>>>>>> > have same nova conf.\n>>>>>> > 1) nova-compute1.conf\n>>>>>> > cluster_name=Cluster1\n>>>>>> > cluster_name=Cluster2\n>>>>>> >\n>>>>>> > 2) nova-compute2.conf\n>>>>>> > cluster_name=Cluster1\n>>>>>> > cluster_name=Cluster2\n>>>>>> >\n>>>>>> > 3) Then create and resize/cold migrate a VM, it can always succeed.\n>>>>>> >\n>>>>>> >\n>>>>>> > *Questions:*\n>>>>>> > For multi-cluster management, does vmware require all nova compute have\n>>>>>> > same cluster configuration to make sure resize/cold migration can succeed?\n>>>>>> >\n>>>>>> > --\n>>>>>> > Thanks,\n>>>>>> >\n>>>>>> > Jay\n>>>>>> >\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >\n>>>>>> >\n>>>>>> \n>>>>>> \n>>>>>> --\n>>>>>> Thanks,\n>>>>>> \n>>>>>> Jay\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/a5a2ed40/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 4\n>>>>>> Date: Sun, 16 Feb 2014 10:27:41 -0500\n>>>>>> From: Mohammad Banikazemi <mb at us.ibm.com>\n>>>>>> To: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: [openstack-dev] [neutron][policy] Using network services with\n>>>>>>         network policies\n>>>>>> Message-ID:\n>>>>>>         <OF456914EA.334156E1-ON85257C81.0051DB09-85257C81.0054EF2C at us.ibm.com>\n>>>>>> Content-Type: text/plain; charset=\"us-ascii\"\n>>>>>> \n>>>>>> \n>>>>>> During the last IRC call we started talking about network services and how\n>>>>>> they can be integrated into the group Policy framework.\n>>>>>> \n>>>>>> In particular, with the \"redirect\" action we need to think how we can\n>>>>>> specify the network services we want to redirect the traffic to/from. There\n>>>>>> has been a substantial work in the area of service chaining and service\n>>>>>> insertion and in the last summit \"advanced service\" in VMs were discussed.\n>>>>>> I think the first step for us is to find out the status of those efforts\n>>>>>> and then see how we can use them. Here are a few questions that come to\n>>>>>> mind.\n>>>>>> 1- What is the status of service chaining, service insertion and advanced\n>>>>>> services work?\n>>>>>> 2- How could we use a service chain? Would simply referring to it in the\n>>>>>> action be enough? Are there considerations wrt creating a service chain\n>>>>>> and/or a service VM for use with the Group Policy framework that need to be\n>>>>>> taken into account?\n>>>>>> \n>>>>>> Let\'s start the discussion on the ML before taking it to the next call.\n>>>>>> \n>>>>>> Thanks,\n>>>>>> \n>>>>>> Mohammad\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/efff7427/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 5\n>>>>>> Date: Sun, 16 Feb 2014 23:29:49 +0800\n>>>>>> From: Jay Lau <jay.lau.513 at gmail.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to\n>>>>>>         resize/cold migration\n>>>>>> Message-ID:\n>>>>>>         <CAFyztAFCc1NH5nz00Dii3dhL3AN8RjPLb3D65aFMRGfyQiJGKA at mail.gmail.com>\n>>>>>> Content-Type: text/plain; charset=\"iso-8859-1\"\n>>>>>> \n>>>>>> Hi Gary,\n>>>>>> \n>>>>>> One more question, when using VCDriver, I can use it in the following two\n>>>>>> ways:\n>>>>>> 1) start up many nova computes and those nova computes manage same vcenter\n>>>>>> clusters.\n>>>>>> 2) start up many nova computes and those nova computes manage different\n>>>>>> vcenter clusters.\n>>>>>> \n>>>>>> Do we have some best practice for above two scenarios or else can you\n>>>>>> please provide some best practise for VCDriver? I did not get much info\n>>>>>> from admin guide.\n>>>>>> \n>>>>>> Thanks,\n>>>>>> \n>>>>>> Jay\n>>>>>> \n>>>>>> \n>>>>>> 2014-02-16 23:01 GMT+08:00 Jay Lau <jay.lau.513 at gmail.com>:\n>>>>>> \n>>>>>> > Thanks Gary, clear now. ;-)\n>>>>>> >\n>>>>>> >\n>>>>>> > 2014-02-16 21:40 GMT+08:00 Gary Kotton <gkotton at vmware.com>:\n>>>>>> >\n>>>>>> >> Hi,\n>>>>>> >> There are two issues here.\n>>>>>> >> The first is a bug fix that is in review:\n>>>>>> >> - https://review.openstack.org/#/c/69209/ (this is where they have the\n>>>>>> >> same configuration)\n>>>>>> >> The second is WIP:\n>>>>>> >> - https://review.openstack.org/#/c/69262/ (we need to restore)\n>>>>>> >> Thanks\n>>>>>> >> Gary\n>>>>>> >>\n>>>>>> >> From: Jay Lau <jay.lau.513 at gmail.com>\n>>>>>> >> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>> >> <openstack-dev at lists.openstack.org>\n>>>>>> >> Date: Sunday, February 16, 2014 6:39 AM\n>>>>>> >> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org\n>>>>>> >> >\n>>>>>> >> Subject: [openstack-dev] [Nova][VMWare] VMwareVCDriver related to\n>>>>>> >> resize/cold migration\n>>>>>> >>\n>>>>>> >> Hey,\n>>>>>> >>\n>>>>>> >> I have one question related with OpenStack vmwareapi.VMwareVCDriver\n>>>>>> >> resize/cold migration.\n>>>>>> >>\n>>>>>> >> The following is my configuration:\n>>>>>> >>\n>>>>>> >>  DC\n>>>>>> >>     |\n>>>>>> >>     |----Cluster1\n>>>>>> >>     |          |\n>>>>>> >>     |          |----9.111.249.56\n>>>>>> >>     |\n>>>>>> >>     |----Cluster2\n>>>>>> >>                |\n>>>>>> >>                |----9.111.249.49\n>>>>>> >>\n>>>>>> >> *Scenario 1:*\n>>>>>> >> I started two nova computes manage the two clusters:\n>>>>>> >> 1) nova-compute1.conf\n>>>>>> >> cluster_name=Cluster1\n>>>>>> >>\n>>>>>> >> 2) nova-compute2.conf\n>>>>>> >> cluster_name=Cluster2\n>>>>>> >>\n>>>>>> >> 3) Start up two nova computes on host1 and host2 separately\n>>>>>> >> 4) Create one VM instance and the VM instance was booted on Cluster2\n>>>>>> >> node  9.111.249.49\n>>>>>> >> | OS-EXT-SRV-ATTR:host                 | host2 |\n>>>>>> >> | OS-EXT-SRV-ATTR:hypervisor_hostname  |\n>>>>>> >> domain-c16(Cluster2)                                     |\n>>>>>> >> 5) Cold migrate the VM instance\n>>>>>> >> 6) After migration finished, the VM goes to VERIFY_RESIZE status, and\n>>>>>> >> \"nova show\" indicates that the VM now located on host1:Cluster1\n>>>>>> >> | OS-EXT-SRV-ATTR:host                 | host1 |\n>>>>>> >> | OS-EXT-SRV-ATTR:hypervisor_hostname  |\n>>>>>> >> domain-c12(Cluster1)                                     |\n>>>>>> >> 7) But from vSphere client, it indicates the the VM was still running on\n>>>>>> >> Cluster2\n>>>>>> >> 8) Try to confirm the resize, confirm will be failed. The root cause is\n>>>>>> >> that nova compute on host2 has no knowledge of domain-c12(Cluster1)\n>>>>>> >>\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> >> \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2810, in\n>>>>>> >> do_confirm_resize\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> migration=migration)\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> >> \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 2836, in\n>>>>>> >> _confirm_resize\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> network_info)\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> >> \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 420,\n>>>>>> >> in confirm_migration\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> _vmops = self._get_vmops_for_compute_node(instance[\'node\'])\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> >> \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 523,\n>>>>>> >> in _get_vmops_for_compute_node\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> resource = self._get_resource_for_node(nodename)\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp   File\n>>>>>> >> \"/usr/lib/python2.6/site-packages/nova/virt/vmwareapi/driver.py\", line 515,\n>>>>>> >> in _get_resource_for_node\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> raise exception.NotFound(msg)\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >> NotFound: NV-3AB798A The resource domain-c12(Cluster1) does not exist\n>>>>>> >> 2014-02-16 07:10:17.166 12720 TRACE nova.openstack.common.rpc.amqp\n>>>>>> >>\n>>>>>> >>\n>>>>>> >> *Scenario 2:*\n>>>>>> >>\n>>>>>> >> 1) Started two nova computes manage the two clusters, but the two\n>>>>>> >> computes have same nova conf.\n>>>>>> >> 1) nova-compute1.conf\n>>>>>> >> cluster_name=Cluster1\n>>>>>> >> cluster_name=Cluster2\n>>>>>> >>\n>>>>>> >> 2) nova-compute2.conf\n>>>>>> >> cluster_name=Cluster1\n>>>>>> >> cluster_name=Cluster2\n>>>>>> >>\n>>>>>> >> 3) Then create and resize/cold migrate a VM, it can always succeed.\n>>>>>> >>\n>>>>>> >>\n>>>>>> >> *Questions:*\n>>>>>> >> For multi-cluster management, does vmware require all nova compute have\n>>>>>> >> same cluster configuration to make sure resize/cold migration can succeed?\n>>>>>> >>\n>>>>>> >> --\n>>>>>> >> Thanks,\n>>>>>> >>\n>>>>>> >> Jay\n>>>>>> >>\n>>>>>> >> _______________________________________________\n>>>>>> >> OpenStack-dev mailing list\n>>>>>> >> OpenStack-dev at lists.openstack.org\n>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >>\n>>>>>> >>\n>>>>>> >\n>>>>>> >\n>>>>>> > --\n>>>>>> > Thanks,\n>>>>>> >\n>>>>>> > Jay\n>>>>>> >\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> --\n>>>>>> Thanks,\n>>>>>> \n>>>>>> Jay\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/e7da9e73/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 6\n>>>>>> Date: Sun, 16 Feb 2014 08:01:14 -0800\n>>>>>> From: Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC\n>>>>>>         definition\n>>>>>> Message-ID: <-4426752061342328447 at unknownmsgid>\n>>>>>> Content-Type: text/plain; charset=\"iso-8859-1\"\n>>>>>> \n>>>>>> Yes, [1] can be done without [2] and [3].\n>>>>>> As you are well aware [2] is now merged with group policy discussions.\n>>>>>> IMHO all or nothing approach will not get us anywhere.\n>>>>>> By the time we line up all our ducks in row. New features/ideas/blueprints\n>>>>>> will keep Emerging.\n>>>>>> \n>>>>>> Regards\n>>>>>> -Harshad\n>>>>>> \n>>>>>> \n>>>>>> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>>>>> \n>>>>>> It seems this work item is made of several blueprints, some of which are\n>>>>>> not yet approved. This is true at least for the Neutron blueprint regarding\n>>>>>> policy extensions.\n>>>>>> \n>>>>>> Since I first looked at this spec I\'ve been wondering why nova has been\n>>>>>> selected as an endpoint for network operations rather than Neutron, but\n>>>>>> this probably a design/implementation details whereas JC here is looking at\n>>>>>> the general approach.\n>>>>>> \n>>>>>> Nevertheless, my only point here is that is seems that features like this\n>>>>>> need an \"all-or-none\" approval.\n>>>>>> For instance, could the VPC feature be considered functional if blueprint\n>>>>>> [1] is implemented, but not [2] and [3]?\n>>>>>> \n>>>>>> Salvatore\n>>>>>> \n>>>>>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n>>>>>> [2]\n>>>>>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>>>>>> [3]\n>>>>>> https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy\n>>>>>> \n>>>>>> \n>>>>>> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com> wrote:\n>>>>>> \n>>>>>> > Ravi,\n>>>>>> >\n>>>>>> > It seems that the following Blueprint\n>>>>>> > https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n>>>>>> >\n>>>>>> > has been approved.\n>>>>>> >\n>>>>>> > However, I cannot find a discussion with regard to the merit of using\n>>>>>> > project vs. domain, or other mechanism for the implementation.\n>>>>>> >\n>>>>>> > I have an issue with this approach as it prevents tenants within the same\n>>>>>> > domain sharing the same VPC to have projects.\n>>>>>> >\n>>>>>> > As an example, if you are a large organization on AWS, it is likely that\n>>>>>> > you have a large VPC that will be shred by multiple projects. With this\n>>>>>> > proposal, we loose that capability, unless I missed something.\n>>>>>> >\n>>>>>> > JC\n>>>>>> >\n>>>>>> > On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:\n>>>>>> >\n>>>>>> > > Hi,\n>>>>>> > >   We had some internal discussions on role of Domain and VPCs. I would\n>>>>>> > like to expand and understand community thinking of Keystone domain and\n>>>>>> > VPCs.\n>>>>>> > >\n>>>>>> > > Is VPC equivalent to Keystone Domain?\n>>>>>> > >\n>>>>>> > > If so, as a public cloud provider - I create a Keystone domain and give\n>>>>>> > it to an organization which wants a virtual private cloud.\n>>>>>> > >\n>>>>>> > > Now the question is if that organization wants to have  departments wise\n>>>>>> > allocation of resources it is becoming difficult to visualize with existing\n>>>>>> > v3 keystone constructs.\n>>>>>> > >\n>>>>>> > > Currently, it looks like each department of an organization cannot have\n>>>>>> > their own resource management with in the organization VPC ( LDAP based\n>>>>>> > user management, network management or dedicating computes etc.,) For us,\n>>>>>> > Openstack Project does not match the requirements of a department of an\n>>>>>> > organization.\n>>>>>> > >\n>>>>>> > > I hope you guessed what we wanted - Domain must have VPCs and VPC to\n>>>>>> > have projects.\n>>>>>> > >\n>>>>>> > > I would like to know how community see the VPC model in Openstack.\n>>>>>> > >\n>>>>>> > > Thanks,\n>>>>>> > > -Ravi.\n>>>>>> > >\n>>>>>> > >\n>>>>>> > > _______________________________________________\n>>>>>> > > OpenStack-dev mailing list\n>>>>>> > > OpenStack-dev at lists.openstack.org\n>>>>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >\n>>>>>> >\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >\n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> OpenStack-dev mailing list\n>>>>>> OpenStack-dev at lists.openstack.org\n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/9258cf27/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 7\n>>>>>> Date: Sun, 16 Feb 2014 08:47:19 -0800\n>>>>>> From: Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] VPC Proposal\n>>>>>> Message-ID:\n>>>>>>         <CAL7PBMchfaSkX8amUAEe8X_fs9OM6ZLGJx_fNB2SUCJWPaGNFA at mail.gmail.com>\n>>>>>> Content-Type: text/plain; charset=\"iso-8859-1\"\n>>>>>> \n>>>>>> Comments Inline\n>>>>>> \n>>>>>> Regards\n>>>>>> -Harshad\n>>>>>> \n>>>>>> \n>>>>>> On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu <subbu at subbu.org> wrote:\n>>>>>> \n>>>>>> > Harshad,\n>>>>>> >\n>>>>>> > Curious to know if there is a broad interest in an AWS compatible API in\n>>>>>> > the community?\n>>>>>> \n>>>>>> \n>>>>>> We started looking at this as some our customers/partners were interested\n>>>>>> in get AWS API compatibility. We have this blueprint and code review\n>>>>>> pending for long time now. We will know based on this thread wether the\n>>>>>> community is interested. But I assumed that community was interested as the\n>>>>>> blueprint was approved and code review has no -1(s) for long time now.\n>>>>>> \n>>>>>> \n>>>>>> > To clarify, a clear incremental path from an AWS compatible API to an\n>>>>>> > OpenStack model is not clear.\n>>>>>> >\n>>>>>> \n>>>>>> In my mind AWS compatible API does not need new openstack model. As more\n>>>>>> discussion happen on JC\'s proposal and implementation becomes clear we will\n>>>>>> know how incremental is the path. But at high level there two major\n>>>>>> differences\n>>>>>> 1. New first class object will be introduced which effect all components\n>>>>>> 2. more than one project can be supported within VPC.\n>>>>>> But it does not change AWS API(s). So even in JC(s) model if you want AWS\n>>>>>> API then we will have to keep VPC to project mapping 1:1, since the API\n>>>>>> will not take both VPC ID and project ID.\n>>>>>> \n>>>>>> As more users want to migrate from AWS or IaaS providers who want compete\n>>>>>> with AWS should be interested in this compatibility.\n>>>>>> \n>>>>>> There also seems to be terminology issue here Whats is definition of \"VPC\"\n>>>>>> if we assume what AWS implements is \"VPC\"\n>>>>>> then what JC is proposing \"VOS\" or \"VDC\" (virtual openstack or virtual DC)\n>>>>>> as all or most of current openstack features are available to user in  this\n>>>>>> new Abstraction. I actually like this new abstraction.\n>>>>>> \n>>>>>> \n>>>>>> > Subbu\n>>>>>> >\n>>>>>> > On Feb 15, 2014, at 10:04 PM, Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> > wrote:\n>>>>>> >\n>>>>>> > >\n>>>>>> > > I agree with problem as defined by you and will require more fundamental\n>>>>>> > changes.\n>>>>>> > > Meanwhile many users will benefit from AWS VPC api compatibility.\n>>>>>> >\n>>>>>> >\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >\n>>>>>> -------------- next part --------------\n>>>>>> An HTML attachment was scrubbed...\n>>>>>> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140216/5f655f01/attachment-0001.html>\n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 8\n>>>>>> Date: Sun, 16 Feb 2014 09:04:36 -0800\n>>>>>> From: \"Allamaraju, Subbu\" <subbu at subbu.org>\n>>>>>> To: Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> Cc: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] VPC Proposal\n>>>>>> Message-ID: <641D4BA6-DFB2-4D3E-8D67-48F711ADC1B5 at subbu.org>\n>>>>>> Content-Type: text/plain; charset=iso-8859-1\n>>>>>> \n>>>>>> Harshad,\n>>>>>> \n>>>>>> Thanks for clarifying.\n>>>>>> \n>>>>>> > We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now.\n>>>>>> \n>>>>>> Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not.\n>>>>>> \n>>>>>> > To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear.\n>>>>>> >\n>>>>>> > In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC\'s proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences\n>>>>>> > 1. New first class object will be introduced which effect all components\n>>>>>> > 2. more than one project can be supported within VPC.\n>>>>>> > But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID.\n>>>>>> >\n>>>>>> > As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility.\n>>>>>> \n>>>>>> IMHO that\'s a tough sell. Though an AWS compatible API does not need an OpenStack abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself!\n>>>>>> \n>>>>>> Subbu\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 9\n>>>>>> Date: Sun, 16 Feb 2014 09:12:54 -0800\n>>>>>> From: Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> To: \"Allamaraju, Subbu\" <subbu at subbu.org>\n>>>>>> Cc: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] VPC Proposal\n>>>>>> Message-ID: <516707826958554641 at unknownmsgid>\n>>>>>> Content-Type: text/plain; charset=ISO-8859-1\n>>>>>> \n>>>>>> IMHO I don\'t see two implementations. Since right now we have only\n>>>>>> one. As a community if we decide to add new abstractions then we will\n>>>>>> have to change software in every component where the new abstraction\n>>>>>> makes difference. That\'s normal software development process.\n>>>>>> Regards\n>>>>>> -Harshad\n>>>>>> \n>>>>>> \n>>>>>> > On Feb 16, 2014, at 9:03 AM, \"Allamaraju, Subbu\" <subbu at subbu.org> wrote:\n>>>>>> >\n>>>>>> > Harshad,\n>>>>>> >\n>>>>>> > Thanks for clarifying.\n>>>>>> >\n>>>>>> >> We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now.\n>>>>>> >\n>>>>>> > Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not.\n>>>>>> >\n>>>>>> >> To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear.\n>>>>>> >>\n>>>>>> >> In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC\'s proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences\n>>>>>> >> 1. New first class object will be introduced which effect all components\n>>>>>> >> 2. more than one project can be supported within VPC.\n>>>>>> >> But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID.\n>>>>>> >>\n>>>>>> >> As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility.\n>>>>>> >\n>>>>>> > IMHO that\'s a tough sell. Though an AWS compatible API does not need an OpenStack                             abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself!\n>>>>>> >\n>>>>>> > Subbu\n>>>>>> >\n>>>>>> >\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 10\n>>>>>> Date: Sun, 16 Feb 2014 09:25:02 -0800\n>>>>>> From: \"Martin, JC\" <jch.martin at gmail.com>\n>>>>>> To: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] VPC Proposal\n>>>>>> Message-ID: <B1A58385-DC10-48EF-AA8E-90176F576A40 at gmail.com>\n>>>>>> Content-Type: text/plain; charset=us-ascii\n>>>>>> \n>>>>>> Harshad,\n>>>>>> \n>>>>>> I tried to find some discussion around this blueprint.\n>>>>>> Could you provide us with some notes or threads  ?\n>>>>>> \n>>>>>> Also, about the code review you mention. which one are you talking about :\n>>>>>> https://review.openstack.org/#/c/40071/\n>>>>>> https://review.openstack.org/#/c/49470/\n>>>>>> https://review.openstack.org/#/c/53171\n>>>>>> \n>>>>>> because they are all abandoned.\n>>>>>> \n>>>>>> Could you point me to the code, and update the BP because it seems that the links are not correct.\n>>>>>> \n>>>>>> Thanks,\n>>>>>> \n>>>>>> JC\n>>>>>> On Feb 16, 2014, at 9:04 AM, \"Allamaraju, Subbu\" <subbu at subbu.org> wrote:\n>>>>>> \n>>>>>> > Harshad,\n>>>>>> >\n>>>>>> > Thanks for clarifying.\n>>>>>> >\n>>>>>> >> We started looking at this as some our customers/partners were interested in get AWS API compatibility. We have this blueprint and code review pending for long time now. We will know based on this thread wether the community is interested. But I assumed that community was interested as the blueprint was approved and code review has no -1(s) for long time now.\n>>>>>> >\n>>>>>> > Makes sense. I would leave it to others on this list to chime in if there is sufficient interest or not.\n>>>>>> >\n>>>>>> >> To clarify, a clear incremental path from an AWS compatible API to an OpenStack model is not clear.\n>>>>>> >>\n>>>>>> >> In my mind AWS compatible API does not need new openstack model. As more discussion happen on JC\'s proposal and implementation becomes clear we will know how incremental is the path. But at high level there two major differences\n>>>>>> >> 1. New first class object will be introduced which effect all components\n>>>>>> >> 2. more than one project can be supported within VPC.\n>>>>>> >> But it does not change AWS API(s). So even in JC(s) model if you want AWS API then we will have to keep VPC to project mapping 1:1, since the API will not take both VPC ID and project ID.\n>>>>>> >>\n>>>>>> >> As more users want to migrate from AWS or IaaS providers who want compete with AWS should be interested in this compatibility.\n>>>>>> >\n>>>>>> > IMHO that\'s a tough sell. Though an AWS compatible API does not need an OpenStack                             abstraction, we would end up with two independent ways of doing similar things. That would OpenStack repeating itself!\n>>>>>> >\n>>>>>> > Subbu\n>>>>>> >\n>>>>>> >\n>>>>>> >\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 11\n>>>>>> Date: Sun, 16 Feb 2014 09:49:17 -0800\n>>>>>> From: \"Allamaraju, Subbu\" <subbu at subbu.org>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC\n>>>>>>         definition\n>>>>>> Message-ID: <1756EFC4-ABAF-4377-B44A-219F34C3ABFA at subbu.org>\n>>>>>> Content-Type: text/plain; charset=iso-8859-1\n>>>>>> \n>>>>>> Harshad,\n>>>>>> \n>>>>>> But the key question that Ravi brought up remains though. A project is a very small                             administrative container to manage policies and resources for VPCs. We\'ve been experimenting with VPCs on OpenStack (with some mods) at work for nearly a year, and came across cases where hundreds/thousands of apps in equal number of projects needing to share resources and policies, and project to VPC mapping did not cut.\n>>>>>> \n>>>>>> I was wondering if there was prior discussion around the mapping of AWS VPC model to OpenStack concepts like projects and domains. Thanks for any pointers.\n>>>>>> \n>>>>>> Subbu\n>>>>>> \n>>>>>> On Feb 16, 2014, at 8:01 AM, Harshad Nakil <hnakil at contrailsystems.com> wrote:\n>>>>>> \n>>>>>> > Yes, [1] can be done without [2] and [3].\n>>>>>> > As you are well aware [2] is now merged with group policy discussions.\n>>>>>> > IMHO all or nothing approach will not get us anywhere.\n>>>>>> > By the time we line up all our ducks in row. New features/ideas/blueprints will keep Emerging.\n>>>>>> >\n>>>>>> > Regards\n>>>>>> > -Harshad\n>>>>>> >\n>>>>>> >\n>>>>>> > On Feb 16, 2014, at 2:30 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>>>>> >\n>>>>>> >> It seems this work item is made of several blueprints, some of which are not yet approved. This is true at least for the Neutron blueprint regarding policy extensions.\n>>>>>> >>\n>>>>>> >> Since I first looked at this spec I\'ve been wondering why nova has been selected as an endpoint for network operations rather than Neutron, but this probably a design/implementation details whereas JC here is looking at the general approach.\n>>>>>> >>\n>>>>>> >> Nevertheless, my only point here is that is seems that features like this need an \"all-or-none\" approval.\n>>>>>> >> For instance, could the VPC feature be considered functional if blueprint [1] is                             implemented, but not [2] and [3]?\n>>>>>> >>\n>>>>>> >> Salvatore\n>>>>>> >>\n>>>>>> >> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n>>>>>> >> [2] https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>>>>>> >> [3] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy\n>>>>>> >>\n>>>>>> >>\n>>>>>> >> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com> wrote:\n>>>>>> >> Ravi,\n>>>>>> >>\n>>>>>> >> It seems that the following Blueprint\n>>>>>> >> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n>>>>>> >>\n>>>>>> >> has been approved.\n>>>>>> >>\n>>>>>> >> However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation.\n>>>>>> >>\n>>>>>> >> I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects.\n>>>>>> >>\n>>>>>> >> As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something.\n>>>>>> >>\n>>>>>> >> JC\n>>>>>> >>\n>>>>>> >> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:\n>>>>>> >>\n>>>>>> >> > Hi,\n>>>>>> >> >   We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs.\n>>>>>> >> >\n>>>>>> >> > Is VPC equivalent to Keystone Domain?\n>>>>>> >> >\n>>>>>> >> > If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud.\n>>>>>> >> >\n>>>>>> >> > Now the question is if that organization wants to have  departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs.\n>>>>>> >> >\n>>>>>> >> > Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization.\n>>>>>> >> >\n>>>>>> >> > I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects.\n>>>>>> >> >\n>>>>>> >> > I would like to know how community see the VPC model in Openstack.\n>>>>>> >> >\n>>>>>> >> > Thanks,\n>>>>>> >> > -Ravi.\n>>>>>> >> >\n>>>>>> >> >\n>>>>>> >> > _______________________________________________\n>>>>>> >> > OpenStack-dev mailing list\n>>>>>> >> > OpenStack-dev at lists.openstack.org\n>>>>>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >>\n>>>>>> >>\n>>>>>> >> _______________________________________________\n>>>>>> >> OpenStack-dev mailing list\n>>>>>> >> OpenStack-dev at lists.openstack.org\n>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >>\n>>>>>> >> _______________________________________________\n>>>>>> >> OpenStack-dev mailing list\n>>>>>> >> OpenStack-dev at lists.openstack.org\n>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 12\n>>>>>> Date: Sun, 16 Feb 2014 10:15:11 -0800\n>>>>>> From: Harshad Nakil <hnakil at contrailsystems.com>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC\n>>>>>>         definition\n>>>>>> Message-ID: <4920517322402852354 at unknownmsgid>\n>>>>>> Content-Type: text/plain; charset=ISO-8859-1\n>>>>>> \n>>>>>> As said I am not disagreeing with you or Ravi or JC. I also agree that\n>>>>>> Openstack VPC implementation will benefit from these proposals.\n>>>>>> What I am saying is it is not required AWS VPC API compatibility at\n>>>>>> this point.  Which is what our blueprint is all about. We are not\n>>>>>> defining THE \"VPC\".\n>>>>>> Let me ask you what changes in AWS API when you go to other model?\n>>>>>> The argument is you want multiple projects in VPC. That\'s great. But I\n>>>>>> don\'t understand how I would specify it if my code was written to use\n>>>>>> AWS API.\n>>>>>> The argument you want multiple external networks per VPC I don\'t know\n>>>>>> how to specify using AWS API\n>>>>>> So list goes on.\n>>>>>> \n>>>>>> May be I am missing something. If you don\'t want AWS compatibility\n>>>>>> then that\'s different issue all together. And should be discussed as\n>>>>>> such.\n>>>>>> \n>>>>>> Regards\n>>>>>> -Harshad\n>>>>>> \n>>>>>> \n>>>>>> > On Feb 16, 2014, at 9:51 AM, \"Allamaraju, Subbu\" <subbu at subbu.org> wrote:\n>>>>>> >\n>>>>>> > Harshad,\n>>>>>> >\n>>>>>> > But the key question that Ravi brought up remains though. A project is a very small administrative container to manage policies and resources for VPCs. We\'ve been experimenting with VPCs on OpenStack (with some mods) at work for nearly a year, and came across cases where hundreds/thousands of apps in equal number of projects needing to share resources and policies, and project to VPC mapping did not cut.\n>>>>>> >\n>>>>>> > I was wondering if there was prior discussion around the mapping of AWS VPC model to OpenStack concepts like projects and domains. Thanks for any pointers.\n>>>>>> >\n>>>>>> > Subbu\n>>>>>> >\n>>>>>> >> On Feb 16, 2014, at 8:01 AM, Harshad Nakil <hnakil at contrailsystems.com> wrote:\n>>>>>> >>\n>>>>>> >> Yes, [1] can be done without [2] and [3].\n>>>>>> >> As you are well aware [2] is now merged with group policy discussions.\n>>>>>> >> IMHO all or nothing approach will not get us anywhere.\n>>>>>> >> By the time we line up all our ducks in row. New features/ideas/blueprints will keep Emerging.\n>>>>>> >>\n>>>>>> >> Regards\n>>>>>> >> -Harshad\n>>>>>> >>\n>>>>>> >>\n>>>>>> >>> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n>>>>>> >>>\n>>>>>> >>> It seems this work item is made of several blueprints, some of which are not yet approved. This is true at least for the Neutron blueprint regarding policy extensions.\n>>>>>> >>>\n>>>>>> >>> Since I first looked at this spec I\'ve been wondering why nova has been selected as an endpoint for network operations rather than Neutron, but this probably a design/implementation details whereas JC here is looking at the general approach.\n>>>>>> >>>\n>>>>>> >>> Nevertheless, my only point here is that is seems that features like this need an \"all-or-none\" approval.\n>>>>>> >>> For instance, could the VPC feature be considered functional if blueprint [1] is implemented, but not [2] and [3]?\n>>>>>> >>>\n>>>>>> >>> Salvatore\n>>>>>> >>>\n>>>>>> >>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n>>>>>> >>> [2] https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>>>>>> >>> [3] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy\n>>>>>> >>>\n>>>>>> >>>\n>>>>>> >>> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com> wrote:\n>>>>>> >>> Ravi,\n>>>>>> >>>\n>>>>>> >>> It seems that the following Blueprint\n>>>>>> >>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n>>>>>> >>>\n>>>>>> >>> has been approved.\n>>>>>> >>>\n>>>>>> >>> However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation.\n>>>>>> >>>\n>>>>>> >>> I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects.\n>>>>>> >>>\n>>>>>> >>> As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something.\n>>>>>> >>>\n>>>>>> >>> JC\n>>>>>> >>>\n>>>>>> >>>> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:\n>>>>>> >>>>\n>>>>>> >>>> Hi,\n>>>>>> >>>>  We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs.\n>>>>>> >>>>\n>>>>>> >>>> Is VPC equivalent to Keystone Domain?\n>>>>>> >>>>\n>>>>>> >>>> If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud.\n>>>>>> >>>>\n>>>>>> >>>> Now the question is if that organization wants to have  departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs.\n>>>>>> >>>>\n>>>>>> >>>> Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization.\n>>>>>> >>>>\n>>>>>> >>>> I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects.\n>>>>>> >>>>\n>>>>>> >>>> I would like to know how community see the VPC model in Openstack.\n>>>>>> >>>>\n>>>>>> >>>> Thanks,\n>>>>>> >>>> -Ravi.\n>>>>>> >>>>\n>>>>>> >>>>\n>>>>>> >>>> _______________________________________________\n>>>>>> >>>> OpenStack-dev mailing list\n>>>>>> >>>> OpenStack-dev at lists.openstack.org\n>>>>>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >>>\n>>>>>> >>>\n>>>>>> >>> _______________________________________________\n>>>>>> >>> OpenStack-dev mailing list\n>>>>>> >>> OpenStack-dev at lists.openstack.org\n>>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >>>\n>>>>>> >>> _______________________________________________\n>>>>>> >>> OpenStack-dev mailing list\n>>>>>> >>> OpenStack-dev at lists.openstack.org\n>>>>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >> _______________________________________________\n>>>>>> >> OpenStack-dev mailing list\n>>>>>> >> OpenStack-dev at lists.openstack.org\n>>>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> >\n>>>>>> >\n>>>>>> > _______________________________________________\n>>>>>> > OpenStack-dev mailing list\n>>>>>> > OpenStack-dev at lists.openstack.org\n>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 13\n>>>>>> Date: Sun, 16 Feb 2014 10:31:42 -0800\n>>>>>> From: \"Allamaraju, Subbu\" <subbu at subbu.org>\n>>>>>> To: \"OpenStack Development Mailing List (not for usage questions)\"\n>>>>>>         <openstack-dev at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [keystone] role of Domain in VPC\n>>>>>>         definition\n>>>>>> Message-ID: <7CD9E46E-FC0A-431B-836F-9BD02B0E417A at subbu.org>\n>>>>>> Content-Type: text/plain; charset=us-ascii\n>>>>>> \n>>>>>> Harshad,\n>>>>>> \n>>>>>> This is great. At least there is consensus on what it is and what it is not. I would leave it to others to discuss merits of a an AWS compat VPC API for Icehouse.\n>>>>>> \n>>>>>> Perhaps this is a good topic to discuss at the Juno design summit.\n>>>>>> \n>>>>>> Subbu\n>>>>>> \n>>>>>> On Feb 16, 2014, at 10:15 AM, Harshad Nakil <hnakil at contrailsystems.com> wrote:\n>>>>>> \n>>>>>> > As said I am not disagreeing with you or Ravi or JC. I also agree that\n>>>>>> > Openstack VPC implementation will benefit from these proposals.\n>>>>>> > What I am saying is it is not required AWS VPC API compatibility at\n>>>>>> > this point.  Which is what our blueprint is all about. We are not\n>>>>>> > defining THE \"VPC\".\n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> ------------------------------\n>>>>>> \n>>>>>> Message: 14\n>>>>>> Date: Mon, 17 Feb 2014 08:20:09 +1300\n>>>>>> From: Robert Collins <robertc at robertcollins.net>\n>>>>>> To: Sean Dague <sean at dague.net>\n>>>>>> Cc: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n>>>>>>         <openstack-dev at lists.openstack.org>,\n>>>>>>         \"<openstack-infra at lists.openstack.org>\"\n>>>>>>         <openstack-infra at lists.openstack.org>\n>>>>>> Subject: Re: [openstack-dev] [OpenStack-Infra] [TripleO] promoting\n>>>>>>         devtest_seed and devtest_undercloud to voting, + experimental queue\n>>>>>>         for nova/neutron etc.\n>>>>>> Message-ID:\n>>>>>>         <CAJ3HoZ1LC1WqayW3o3RaPxfLC0G-Lb9zxHKftPDW=t8wnubCtQ at mail.gmail.com>\n>>>>>> Content-Type: text/plain; charset=ISO-8859-1\n>>>>>> \n>>>>>> On 15 February 2014 09:58, Sean Dague <sean at dague.net> wrote:\n>>>>>> \n>>>>>> >> Lastly, I\'m going to propose a merge to infra/config to put our\n>>>>>> >> undercloud story (which exercises the seed\'s ability to deploy via\n>>>>>> >> heat with bare metal) as a check experimental job on our dependencies\n>>>>>> >> (keystone, glance, nova, neutron) - if thats ok with those projects?\n>>>>>> >>\n>>>>>> >> -Rob\n>>>>>> >>\n>>>>>> >\n>>>>>> > My biggest conce','<CADbqdAwvX3u5LuHGrfXNNFz5DMTa4hE7-kCMYRJwrRRNFr=LtQ@mail.gmail.com>',NULL),('<13c14128eee.2789.e49cc2a09fd803f460c484b5ff914b54@suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-07 09:13:47',3600,'2013-01-07 08:13:47',NULL,'[openstack-dev] upgrading WebOb across all projects','Am 3. Januar 2013 19:34:46 schrieb Doug Hellmann <doug.hellmann at dreamhost.com>:\n> Sure; I\'m not sure why my grep didn\'t find that use.\n\nHi Doug,\n\nI did most of those and I\'ll have a look at the other OpenStack \ncomponents soon. We run all testsuites against openSUSE:Factory \npackages, which are always the latest and greatest. However, no issues \nwith a newer WebOb popped up so far. So either the coverage isnt\'t \nsufficient or its working already ;-)\n\n>\n> Doug\n>\n> On Thu, Jan 3, 2013 at 12:30 PM, Brian Waldon <bcwaldon at gmail.com> wrote:\n>\n> > Webob is being used in Glance as well. There have been some patches to\n> > prepare the code for webob 1.2.1, but we\'re still depending on 1.0.8. Would\n> > you mind taking a look?\n> >\n> >\n> > On Jan 3, 2013, at 8:32 AM, Doug Hellmann wrote:\n> >\n> > The ceilometer team is using Pecan [1] for our next-generation API\n> > framework. Pecan depends on a newer WebOb than is used by the other\n> > OpenStack components, so I spent this morning reviewing the differences in\n> > WebOb between 1.0.8 and 1.2.3 (the latest stable release) [2] and what\n> > impact those changes might have on nova, cinder, keystone, and oslo (the 4\n> > projects where I found WebOb being used -- please let me know if I missed\n> > one).\n> >\n> > Most of the changes appear to be bug fixes and changes that either have a\n> > backwards-compatible alias, are deprecations that were reversed later, or\n> > should not have an impact on us because we were not using the changed area\n> > of the code directly. The only thing I found to be questionable is the\n> > change to Request.path_info and Request.script_name. Those properties are\n> > now unicode objects instead of str objects, as WebOb is trying to provide\n> > better Python 3 support. I found a few uses of those variables in\n> > comparisons and concatenation with str objects, but the casting should work\n> > automatically as long as the path can be encoded in the default encoding,\n> > which should be the case as the paths to our API use only ASCII characters.\n> > All of the unit tests pass when I run them locally.\n> >\n> > I have submitted patches against the 4 projects to update the version\n> > number in tools/pip-requires, without any other code changes:\n> >\n> > Oslo: https://review.openstack.org/#/c/18885/\n> > Nova: https://review.openstack.org/#/c/18886/\n> > Keystone: https://review.openstack.org/#/c/18887/\n> > Cinder: https://review.openstack.org/#/c/18888/\n> >\n> > If anyone else has done similar analysis in the past and come to a\n> > different conclusion about whether it is safe to upgrade, please let me\n> > know.\n> >\n> > Doug\n> >\n> > [1] Pecan: http://pecan.readthedocs.org/en/latest/\n> > [2] The full release notes for WebOb:\n> > http://docs.webob.org/en/latest/news.html\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n--\nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n\n\n\n\n','<CADb+p3Tvs18-WiMyOdEnrQd1djRoN_-Ztx+kFjSrW1KyUhh49A@mail.gmail.com>',NULL),('<13c1c132.4623.14b4d58c6ce.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-03 10:50:38',28800,'2015-02-03 02:50:38',NULL,'[openstack-dev] [trove]how to enable trove in dashboard?','Sorry, i find it.....\n\n\n--\n\nBest\n    Li Tianqing\n\nAt 2015-02-03 10:48:06, \"Li Tianqing\" <jazeltq at 163.com> wrote:\n\nHello,\n   I first install devstack, then install trove from source code. After seraching on the net, i do not find how to enable trove in dashboard...\n  Can someone help to point out how to?\n\n\n\n\n--\n\nBest\n    Li Tianqing\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/90b60297/attachment.html>\n\n','<3af824e.44ef.14b4d567452.Coremail.jazeltq@163.com>',NULL),('<13C7079A0C984948BA11BA6708F6C46A@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 14:00:40',-14400,'2012-09-25 18:00:40',NULL,'[openstack-dev] Quantum + ZeroMQ (with a sprinkling of Nova) in\n	Folsom','On Tuesday, September 25, 2012 at 13:08 PM, Dan Wendlandt wrote:\n> To be clear, this is just when using zmq? rabbit and qpid are working\n> as expected with dhcp, correct?\n\n\nDan, I presume that all the Rabbit code is working, since the Quantum team has been testing with it.\n\nThe previous patches have been to put together a best effort to get all RPC functionality in Quantum working wih ZeroMQ, but with the DHCP Agent as a lower priority. It seems now that the DHCP agent won\'t work at all with ZeroMQ in Folsom. I\'m completely okay with this.\n\nHowever, right now, none of the ZeroMQ code will work (in Quantum), given that the receiver daemon exists in Nova and the message format has changed.\n\nThe three options I see here are:\n* Leave zeromq broken in Quantum - polling agents should still work.\n* Introduce the changes in Nova\n* Break the rpc-zmq-receiver out of Nova into a new project/location, introduce message versioning in a backport-fix, and retroactively depreciate nova-rpc-zmq-receiver. (This is kind of a solution to #1)\n\nI admit the last is least risky and lowest-friction. Much of this has to be done anyway, but not necessarily in this order. I find it ugly, but not untenable.\n\nRegards,\nEric Windisch \n\n\n\n','<90EC6177FC214FAE962A981C8F66B09A@cloudscaling.com>',NULL),('<13C9D29C-5C3B-47BE-9BBF-C2A197CAD091@imaginary.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-08-01 18:25:24',-18000,'2012-08-01 23:25:24',NULL,'[OpenStack Foundation] Nomination Process Updates','It\'s not about Ben or me or anyone else questioning the integrity of any individual person.\n\nIt\'s about the perception of how OpenStack governance is handled. If all independent board seats are held by corporate sponsors, the integrity of OpenStack governance will constantly be in question.\n\nAnd the reality is that no matter how well intentioned you are, your employer DOES exert influence over you and can leverage your individual membership to gain undue influence over OpenStack.\n\n-George\n\nOn Aug 1, 2012, at 6:21 PM, Matt Joyce <matt at nycresistor.com> wrote:\n\n> On Wed, Aug 1, 2012 at 4:14 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>> On Wed, 2012-08-01 at 16:02 -0700, Benjamin Black wrote:\n>>> The question there is not whether _you_, or any other specific person,\n>>> can be trusted to act independently of their employer.  The question\n>>> is whether permitting member company employees to hold individual\n>>> seats _in general_ will serve the community and the project over the\n>>> long-term.  In this I take a pretty liberal view of the democratic\n>>> process: I am much more trusting of the electorate and much less\n>>> trusting of the candidates.\n>> \n>> Trust the electorate to figure out which of the candidates can act\n>> independently of their employer, then.\n>> \n> \n> That flies in the face of numbers really.\n> \n> Rackspace and HP are showing 700 users who are now members of\n> openstack community.\n> \n> Their development numbers don\'t really reflect anywhere near that\n> level of participation in openstack.\n> \n> We know for a fact that rack promoted the idea of general employees\n> joining the foundation.  They had no incentive to do so otherwise.  We\n> now have a flood of people who are a part of the foundation solely\n> because of incentives created by rackspace.  I am not saying this is\n> in any way rackspaces fault.  But the reality is it introduces a bias\n> in which there are now members in the foundation who do not have\n> openstack\'s success are their foremost concern.  Not only that there\n> is arguably a significant percentage of the overall membership that is\n> not involved in any meaningful way with the community.\n> \n> =/\n> \n> That\'s not a good thing.\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n--\nGeorge Reese (george.reese at imaginary.com)\nt: @GeorgeReese               m: +1(207)956-0217               Skype: nspollution\ncal: http://tungle.me/GeorgeReese   \n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20120801/bc41e433/attachment-0001.html>\n\n','<CAP_sDUH=q7TqAq92GD2wLOnfYn57N2YJRHKKkvvHPWZZiofyhg@mail.gmail.com>',NULL),('<13D33D15-BA9A-4EE5-91CD-8B58250F0083@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-22 09:12:34',-28800,'2014-12-22 17:12:34',NULL,'[openstack-dev] [nova] Setting MTU size for tap device','It makes sense to add it to me. Libvirt sets the mtu from the bridge when it creates the tap device, but if you are creating it manually you might need to set it to something else.\n\nVish\n\nOn Dec 17, 2014, at 10:29 PM, Ryu Ishimoto <ryu at midokura.com> wrote:\n\n> Hi All,\n> \n> I noticed that in linux_net.py, the method to create a tap interface[1] does not let you set the MTU size.  In other places, I see calls made to set the MTU of the device [2].\n> \n> I\'m wondering if there is any technical reasons to why we can\'t also set the MTU size when creating tap interfaces for general cases.  In certain overlay solutions, this would come in handy.  If there isn\'t any, I would love to submit a patch to accomplish this.\n> \n> Thanks in advance!\n> \n> Ryu\n> \n> [1] https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L1374\n> [2] https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L1309\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141222/4d69ebc8/attachment.html>\n\n','<CAF=qiCOya4wTnVCV_E-=6ML-R0b8g5C2j9-7h35LQLsk5Hxknw@mail.gmail.com>',NULL),('<13d39a0fcc4.2789.e49cc2a09fd803f460c484b5ff914b54@suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-05 09:18:05',3600,'2013-03-05 08:18:05',NULL,'[openstack-dev] Adding write capability in oslo-config','Am 4. M?rz 2013 21:34:03 schrieb Mark McLoughlin <markmc at redhat.com>:\n> Hi Thomas,\n>\n> On Tue, 2013-03-05 at 01:29 +0800, Thomas Goirand wrote:\n> > Hi,\n> >\n> > As much as I can see, the only thing which oslo-config does is *reading*\n> > the config files for an openstack project.\n>\n> A nitpick perhaps, but oslo-config\'s niche is reading config values from\n> the combination of the command line and config files. If you want simply\n> want to use a config files, it doesn\'t have a huge amount to offer.\n>\n> > It doesn\'t seems that it is possible to use the same API to actually\n> > write values.\n> >\n> > As I do the Debian packaging, I would be happy to use oslo-config to be\n> > able to read / write values in the different configuration files of\n> > Openstack. I need to do that, for example to read, then set the\n> > sql_connection DSN string in each package, as Openstack is integrated\n> > with dbconfig-common in Debian.\n> >\n> > The problem is that oslo-config doesn\'t currently provides a command\n> > line tool. Though it would be really trivial to do:\n> > oslo-config-get /etc/keystone/keystone.conf \\\n> > 	DEFAULT admin_token\n> >\n> > so that I could use that from my debian/*.config scripts.\n> >\n> > But then I would also need in a debian/*.postinst script:\n> > oslo-config-set /etc/keystone/keystone.conf \\\n> > 	DEFAULT admin_token <password>\n> >\n> > which isn\'t currently implemented at all in oslo-config. oslo-config\n> > currently can only *read* .ini files, it can\'t actually *write*\n> > directives in them.\n> >\n> > While I currently need the above in my Debian packaging, I am quite sure\n> > that it would be helpful for anyone willing to write automation tools to\n> > deploy Openstack, so I am convinced it would be helpful for others to\n> > add write functions in oslo-config.\n> >\n> > Would anyone who worked on oslo-config have some time to write this?\n>\n> Definitely planned, but it didn\'t get done in time for Grizzly:\n>\n>   https://blueprints.launchpad.net/oslo/+spec/oslo-config-cli\n>\n> In Fedora, we use this:\n>\n>   https://github.com/fedora-openstack/openstack-utils/blob/master/utils/openstack-config\n\nIt may be worth mentioning that we use this in openSUSE too.\n\n>\n> but that doesn\'t handle multi-str options.\n\nAnd it doesn\'t put new config values at the correct place when they \nwhere previously commented out, but at the end of a section instead. \nThis particularly annoying for large (nova.conf) files. Both are \n(fixable) shortcommings of iniparse.\n\n>\n> > Also, reading the code, it seems that the parser doesn\'t even implement\n> > sections, which surprised me. Is this something planned? Or is it\n> > specified that there will never be any 2 of the same directive in\n> > different sections of a given configuration file?\n>\n> We definitely support sections (aka \'groups\'), see e.g.\n>\n>   https://github.com/openstack/oslo-config/blob/59b6720/tests/test_cfg.py#L1043\n>\n> Cheers,\n> Mark.\n>\n>\n\nSetting useful defaults at package installation time is a common \ndistributor\'s task, so I see some value in having (potentially one) \nofficial tool for that.\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n--\nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n\n\n\n\n','<1362429243.5909.168.camel@sorcha>',NULL),('<13d43e49723.2789.e49cc2a09fd803f460c484b5ff914b54@suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 09:08:10',3600,'2013-03-07 08:08:10',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n	versioning and naming','Am 5. M?rz 2013 15:02:15 schrieb Mark McLoughlin <markmc at redhat.com>:\n> Hey,\n>\n> The thread on naming of namespace packages[1] and the discussion about\n> PEP426 on distutils-sig[2] have lead me to these conclusion:\n>\n>   - Naming the package oslo.config is a better choice than oslo-config.\n>     I don\'t think there\'s necessarily a standard for naming these\n>     things but it seems more likely that period-separated will become\n>     more common than hyphen-separated (i.e. zope.interface vs\n>     oslo-config)\n>\n>   - The date based 2013.1 version is likely to be disallowed by PEP426\n>     when it is ratified and we\'ll end up making the date based version\n>     a \"private version\" but 0.2013.1 would be the version on PyPI. Uggh.\n>\n>   - I\'m coming around to the idea of using semantic versioning (i.e.\n>     x.y.z) and increasing the major number when removing any deprecated\n>     APIs. That certainly is the trend expressed in PEP426 and on\n>     distutils-sig. I\'d be far more reluctant to actually remove\n>     deprecated APIs, though, so this would change our policy from\n>     \"remove APIs after a year of deprecation\" to \"very rarely making\n>     any incompatible changes to our APIs\"\n>\n>   - With semantic versioning, I figure we\'d increase the micro number\n>     when we do release from the stable branch and increase the minor\n>     number with every coordinated OpenStack release.\n>\n> In practical terms, I\'m proposing doing:\n>\n>  -package = \'oslo-config\'\n>  -version = \'2013.1\'\n>  +package = \'oslo.config\'\n>  +version = \'1.1.0\'\n>\n> in oslo-config\'s setup.py\n>\n> I know this is painful for packagers. In Fedora, I\'ll have to set an\n> \"epoch\" which packagers always hate doing.\nLucky SUSE guys where too lazy to submit it to openSUSE already, so we \ncan avoid that. Thus I\'d say its ok for us.\n\n> In Debian, it\'ll probably\n> mean the package name changing to python-oslo.config.\n>\n> However, this is why we didn\'t publish directly to PyPI - we wanted the\n> opportunity to catch issues like this. So, I\'m thinking we should just\n> go for it ASAP.\n>\n> Thoughts?\n>\nBetter now than never.\n\n> Thanks,\n> Mark.\n>\n> [1] - \n> http://lists.openstack.org/pipermail/openstack-dev/2013-February/thread.html#6078\n> [2] - \n> http://mail.python.org/pipermail/distutils-sig/2013-March/thread.html#20054\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n--\nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n\n\n\n\n','<1362492135.5909.332.camel@sorcha>',NULL),('<13d43ef70e2.2789.e49cc2a09fd803f460c484b5ff914b54@suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 09:20:02',3600,'2013-03-07 08:20:02',NULL,'[openstack-dev] RFC: last minute changes to Oslo library\n	versioning and naming','Am 5. M?rz 2013 19:05:18 schrieb Thomas Goirand <zigo at debian.org>:\n> On 03/05/2013 10:02 PM, Mark McLoughlin wrote:\n> > In practical terms, I\'m proposing doing:\n> >\n> >  -package = \'oslo-config\'\n> >  -version = \'2013.1\'\n> >  +package = \'oslo.config\'\n> >  +version = \'1.1.0\'\n> >\n> > in oslo-config\'s setup.py\n>\n> I\'m sorry, I will have to be the bad guy complaining and ranting here. I\n> hate to do so, but I have to explain what the consequences can be, since\n> it doesn\'t seem to be understood or known.\n>\n> As I wrote on IRC, we can talk for a century about repainting the shed,\n> this wont make things work better. This is only added work for no real\n> benefits.\n>\n> On the Debian packaging side of things, I will to:\n>\n> - wait until python-oslo-config gets in, since it\'s still in the FTP\n> masters NEW queue with lots of other Openstack packages:\n> http://ftp-master.debian.org/new.html\n>\n> I will not consider asking the FTP masters to remove the package from\n> the NEW queue, as I don\'t want to miss my turn, waiting time is\n> currently already too high (it takes between 1 or 2 months currently, to\n> have a new package accepted).\n>\n> Then when it\'s in debian experimental, I have 2 alternatives:\n>\n\nSorry for only replying here and while I acknowledge that this isn\'t \nparticularly easy to do, this process seriously deserves fixing. To add \nsome (unfair) comparison, within the openSUSE project, response times \nlonger than a day are already considered long.\n\n> 1# Once it\'s in, upload the \"fixed name\" version, and wait (another 1\n> month?), add a Break: python-oslo-config and a Replaces:\n> python-oslo-config in debian/control, which I will have to carry for the\n> next millennium otherwise, someone might complain that I\'m not providing\n> a correct upgrade path in SID to SID upgrades.\n>\n> - Fix all dependencies in all Grizzly packages (they all have already,\n> hard-coded in build-depends: and depends:, a dependency to\n> python-oslo-config).\n>\n> - When done, ask for removal of python-oslo.config.\n>\n> - Pray that there wont be a time where python-oslo-config *AND*\n> python-oslo.config will be required at the same time (this can happen if\n> not all package updates are available at the same time, and that some\n> are lagging waiting for FTP masters approval).\n>\n> Now, imagine that if Wheezy was out, and Grizzly uploaded to SID, then\n> I\'d have to manage a transition with the release team, just because \"it\n> looks better\". Lucky, I will not have to do such thing, as none of\n> Grizzly is uploaded yet.\n>\n> Or:\n>\n> 2# Keep python-oslo-config, and simply add a Provides:\n> python-oslo.config for the rare cases where I forgot, and add\n> pydist-override, and that\'s it. Unfortunately, this also means doing\n> something different from Ubuntu, which I am always trying to avoid if\n> possible (in the hope that we can, in some vague future, have a tiny\n> hope of doing the packaging work together... :P).\n>\n> If I was a lazy man, and didn\'t want to bother FTP masters, release\n> team, and so on, I could choose #2, and keep python-oslo-config as the\n> \"main\" package name, so your efforts will be wasted.\n>\n> I\'m also wondering who you are trying to please here. Because you\n> clearly chatted about the name of the distributions package name, saying\n> that we could call it python-oslo.config. Well, the distribution guy is\n> telling you: don\'t change what\'s right now, it\'s fine and not broken, so\n> don\'t try to fix anything! :)\n>\n> Don\'t get me wrong, I do agree with the theory that oslo.config \"looks\n> nicer\" than oslo-config. But why do we have to care so much? Seriously,\n> don\'t we have something more important to do??? How many distro already\n> picked-up the dash instead of the proposed dot, and thought this\n> packaging part was already done? How many human hours are you proposing\n> to waste here, in unnecessary added work, just because \"it looks nicer\"?\n> You even wrote: \"I don\'t think there\'s necessarily a standard for naming\n> these things\", so why bother?\n>\n> As for the version numbering, that\'s going to be an ugly added epoch in\n> the visioning, which doesn\'t show in the file names. Eg, the package\n> version will have to be 1:1.1.0-1. While I hate these, it\'s unavoidable,\n> and we have already so many of them in the Openstack packages. I\'ve lost\n> any kind of hope a long time ago for upstream authors to have consistent\n> (eg: always increasing) version numbers anyway, and it\'s not such a big\n> deal.\n>\n> Again like I wrote on IRC, I\'ve expressed my opinion, feel free to\n> ignore it if you like, and go ahead with the rename. Distributions\n> should adapt to upstream changes anyway. But if you do, please remember\n> that we, downstream distribution maintainers, have to deal with such\n> painful changes. I strongly feel that we should try to keep such kind of\n> last minute changes *before* a freeze, as this is typically what should\n> *not* be granted a freeze exception, IMO.\n>\n> Thomas\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n--\nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n\n\n\n\n','<513633DE.3080401@debian.org>',NULL),('<13E50DE9-4568-44DF-A659-E4B86B0EDB5C@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 19:49:28',-25200,'2014-07-04 02:49:28',NULL,'[Openstack] Help increasing MTU','1500 is too big with gre if you try to lower the 9000 by 4k it may work just a suggestion. I have seen several issues with the 1500 between instances performance is crappy a lot of frags \n\nInviato da iPhone (?)\n\n> Il giorno Jul 3, 2014, alle ore 19:13, Clint Dilks <clintd at waikato.ac.nz> ha scritto:\n> \n> Hi,\n> \n> I have a three node Icehouse Cluster running on CentOS 6.5 ( using RDO yum repostories but not installed via packstack ).  We are using GRE Tunnels, so experience the issues where some packets are truncated because they exceed the 1500 mtu size.\n> \n> From what I have read most people are reducing the size of the guests MTU to work around the issue.  We thought another another approach would increasing the MTU size available.\n> \n> So for the appropriate ports we have set the MTU to 9000 on the switch.\n> \n> If we change the MTU on all nodes to 9000, then all pre-existing instance appear to work as expected (both before and after rebooting one or all nodes).  But launching a new instance is always stuck at scheduling.  Nothing is being recorded in /var/log/nova/scheduler.log on the controller.\n> \n> If we revert all nodes back to MTU 1500 all starts working again.\n> \n> Does anyone have suggestions as to what I am missing ?\n> \n> !DSPAM:1,53b60f8b127921259016594!\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,53b60f8b127921259016594!\n\n\n','<CACdTQcXBLbOcu4W42RwNX4i7f6uw7QimzgChuHx0P4RPXXaKpw@mail.gmail.com>',NULL),('<13EAB242-13D4-4F20-B8EF-54904D939E9E@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 11:36:36',0,'2014-03-31 11:36:36',NULL,'[openstack-dev] [Neutron] Problem plugging I/F into Neutron...','Hi Darragh,\n\nCan you elaborate on what the ?set interface? arguments do in OVS? Just trying to understand why it is not desired, when plugging into this interface (note I have a management interface on the br-int and it works fine?this one, which is also on br-int, but needs to tie to the existing ?private? network that devstack sets up, does not work.\n\nRegards,\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pcm_ (irc.freenode.com<http://irc.freenode.com>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn Mar 31, 2014, at 4:20 AM, Darragh O\'Reilly <dara2002-openstack at yahoo.com<mailto:dara2002-openstack at yahoo.com>> wrote:\n\nHi Paul,\n\nthe OVSInterfaceDriver creates interfaces with type internal so agents like DHCP/L3 etc can put IP addresses on them. But I don\'t think type internal will work for instances. You could try subclassing and overriding so it does not do this:\n\n https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150\n\nRegards,\nDarragh.\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/d48ab59b/attachment.html>\n\n','<1396254019.25306.YahooMailNeo@web172402.mail.ir2.yahoo.com>',NULL),('<13EE10A1-5DD9-49B6-82D5-A6FA59C9ADDB@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-10 16:01:17',-14400,'2014-10-10 20:01:17',NULL,'[openstack-dev] [Nova][oslo] how to sync oslo.concurrency to\n	nova?','\nOn Oct 10, 2014, at 12:36 PM, Chen CH Ji <jichenjc at cn.ibm.com> wrote:\n\n> Thanks a lot for the info, \n> \n> So, my understanding is I need to wait for its released then someone need to change the code in \n> projects (e.g. nova) to switch from its original method (nova/openstack/common/) to oslo.concurrency \n> just like we did for oslo.utils and other components nowadays?\n> \n\nYes, that?s correct.\n\nDoug\n\n> \n> thanks \n> \n> Best Regards! \n> \n> Kevin (Chen) Ji ? ?\n> \n> Engineer, zVM Development, CSTL\n> Notes: Chen CH Ji/China/IBM at IBMCN   Internet: jichenjc at cn.ibm.com\n> Phone: +86-10-82454158\n> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC \n> \n> <graycol.gif>Ben Nemec ---10/10/2014 09:59:16 PM--------BEGIN PGP SIGNED MESSAGE----- Hash: SHA1\n> \n> From:	Ben Nemec <openstack at nemebean.com>\n> To:	\"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Date:	10/10/2014 09:59 PM\n> Subject:	Re: [openstack-dev] [Nova][oslo] how to sync oslo.concurrency to nova?\n> \n> \n> \n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA1\n> \n> On 10/10/2014 05:05 AM, Ihar Hrachyshka wrote:\n> > On 10/10/14 10:32, Chen CH Ji wrote:\n> >> There used to method in oslo-incubator like \n> >> https://wiki.openstack.org/wiki/Oslo#Syncing_Code_from_Incubator \n> >> or \'_https://review.openstack.org/#/c/78429/_ \' we can use\n> > \n> >> however, I was told to submit patch to oslo.concurrency instead\n> >> of oslo-incubator, so what\'s the method can be used now ? Thanks\n> >> a lot\n> > \n> > With oslo.concurrency, you don\'t copy-paste code, you just reuse it\n> > as any other third-party library. So if your project is not yet\n> > using the library, just port it to it first, and once a new version\n> > of oslo.concurrency is released, you will get your change magically\n> > applied.\n> \n> At this point oslo.concurrency hasn\'t been released yet so it won\'t be\n> possible to switch any projects to use it.  I think we\'re on track for\n> a first release early next week and once that has happened this will\n> be possible.\n> \n> Note that we do have a stable branch of the incubator code that can be\n> used for important changes in projects that haven\'t yet ported to use\n> new libs, but when possible we\'d rather just make the changes in the lib.\n> \n> - -Ben\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG v1\n> \n> iQEcBAEBAgAGBQJUN+bgAAoJEDehGd0Fy7uqjhMIANBPX4sTbVSnewoquF3Ih29z\n> Adxq6KpDymonhpnJuOqM1gKYsd/oyqa6q92WTt9F9c8XwALB1x9IzgUBRRixhts5\n> p4fDzNTMGJzlT9slnGjyNVD0i3AJ1UuO5+mZADDk3jXqqERmbeCo+BgYqJr7q08r\n> MmkPuo0EAZtWrY1+Isl1Eg3lz7P2DFC9kEmY8iUj5wObiqINU7L5MNCzCi7V+c8g\n> uxacoCSXcyTR7nnXcs9cPywthBTLOOqkY1IzEYk38vbnQSmvqKbbovqVB0ZCTueF\n> 8g/WO2+jOhETsyFGY7d3HuOQDxJSx/JeXlpPfriOsxdcrDtmP3YMEgh2kpK0e7k=\n> =Puy/\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141010/8dc80ff5/attachment.html>\n\n','<OF1D51965A.77B229B0-ON48257D6D.005AC170-48257D6D.005B92F8@cn.ibm.com>',NULL),('<13F4F7A1-D4EC-4D14-A163-D477A4FD9BA6@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 10:57:17',-18000,'2014-11-19 15:57:17',NULL,'[openstack-dev] Quota management and enforcement across projects','\nOn Nov 19, 2014, at 9:51 AM, Sylvain Bauza <sbauza at redhat.com> wrote:\n\n> \n> Le 19/11/2014 15:06, Doug Hellmann a ?crit :\n>> On Nov 19, 2014, at 8:33 AM, Sylvain Bauza <sbauza at redhat.com> wrote:\n>> \n>>> Le 18/11/2014 20:05, Doug Hellmann a ?crit :\n>>>> On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:\n>>>> \n>>>>> On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:\n>>>>>> I?ve spent a bit of time thinking about the resource ownership issue.\n>>>>>> The challenge there is we don?t currently have any libraries that\n>>>>>> define tables in the schema of an application. I think that?s a good\n>>>>>> pattern to maintain, since it avoids introducing a lot of tricky\n>>>>>> issues like how to manage migrations for the library, how to ensure\n>>>>>> they are run by the application, etc. The fact that this common quota\n>>>>>> thing needs to store some data in a schema that it controls says to me\n>>>>>> that it is really an app and not a library. Making the quota manager\n>>>>>> an app solves the API definition issue, too, since we can describe a\n>>>>>> generic way to configure quotas and other applications can then use\n>>>>>> that API to define specific rules using the quota manager?s API.\n>>>>>> \n>>>>>> I don?t know if we need a new application or if it would make sense\n>>>>>> to, as with policy, add quota management features to keystone. A\n>>>>>> single well-defined app has some appeal, but there?s also a certain\n>>>>>> amount of extra ramp-up time needed to go that route that we wouldn?t\n>>>>>> need if we added the features directly to keystone.\n>>>>> I\'ll also point out that it was largely because of the storage needs\n>>>>> that I chose to propose Boson[1] as a separate app, rather than as a\n>>>>> library.  Further, the dimensions over which quota-covered resources\n>>>>> needed to be tracked seemed to me to be complicated enough that it would\n>>>>> be better to define a new app and make it support that one domain well,\n>>>>> which is why I didn\'t propose it as something to add to Keystone.\n>>>>> Consider: nova has quotas that are applied by user, other quotas that\n>>>>> are applied by tenant, and even some quotas on what could be considered\n>>>>> sub-resources?a limit on the number of security group rules per security\n>>>>> group, for instance.\n>>>>> \n>>>>> My current feeling is that, if we can figure out a way to make the quota\n>>>>> problem into an acceptable library, that will work; it would probably\n>>>>> have to maintain its own database separate from the client app and have\n>>>>> features for automatically managing the schema, since we couldn\'t\n>>>>> necessarily rely on the client app to invoke the proper juju there.  If,\n>>>>> on the other hand, that ends up failing, then the best route is probably\n>>>>> to begin by developing a separate app, like Boson, as a PoC; then, after\n>>>>> we have some idea of just how difficult it is to actually solve the\n>>>>> problem, we can evaluate whether it makes sense to actually fold it into\n>>>>> a service like Keystone, or whether it should stand on its own.\n>>>>> \n>>>>> (Personally, I think Boson should be created and should stand on its\n>>>>> own, but I also envision using it for purposes outside of OpenStack?)\n>>>> Thanks for mentioning Boson again. I?m embarrassed that I completely forgot about the fact that you mentioned this at the summit.\n>>>> \n>>>> I?ll have to look at the proposal more closely before I comment in any detail, but I take it as a good sign that we?re coming back around to the idea of solving this with an app instead of a library.\n>>> I assume I\'m really late in the thread so I can just sit and give +1 to this direction : IMHO, quotas need to managed thanks to a CRUD interface which implies to get an app, as it sounds unreasonable to extend each consumer app API.\n>>> \n>>> That said, back to Blazar, I just would like to emphasize that Blazar is not trying to address the quota enforcement level, but rather provide a centralized endpoint for managing reservations.\n>>> Consequently, Blazar can also be considered as a consumer of this quota system, whatever it\'s in a library or on a separate REST API.\n>>> \n>>> Last thing, I don\'t think that a quota application necessarly means that quotas enforcement should be managed thanks to external calls to this app. I can rather see an external system able to set for each project a local view of what should be enforced locally. If operators don\'t want to deploy that quota management project, it\'s up to them to address the hetergenous setups for each project.\n>> I?m not sure what this means. You want the new service to be optional? How would apps written against the service find and manage quota data if the service isn?t there?\n> \n> My bad. Let me rephrase it. I\'m seeing this service as providing added value for managing quotas by ensuring consistency across all projects. But as I said, I\'m also thinking that the quota enforcement has still to be done at the customer project level.\n\nOh, yes, that is true. I envision the API for the new service having a call that means ?try to consume X units of a given quota? and that it would return information about whether that can be done. The apps would have to define what quotas they care about, and make the appropriate calls.\n\n> \n> So, I can imagine a client (or a Facade if you prefer) providing quota resources to the customer app which could be either fetched (thru some caching) from the service, or directly taken from the existing quota DB.\n\nI?m not sure we want both solutions. We need to consider a migration path, but for simplicity?s sake if we?re going to create a new quota service we should just use that and not also have a separate built-in implementation.\n\n> \n> In order to do that, I could imagine those steps :\n> #1 : customer app makes use of oslo.quota for managing its own quota resources\n> #2 : the external app provides a client able to either query the app or make use of oslo.quota for looking inside\n> #43 : the customer app changes its current usage of oslo.quota to the external app client\n> \n> \n> Let me know if you need futher details.\n> -Sylvain\n> \n>> Doug\n>> \n>>> My 2 cts (too),\n>>> -Sylvain\n>>> \n>>>> Doug\n>>>> \n>>>>> Just my $.02?\n>>>>> \n>>>>> [1] https://wiki.openstack.org/wiki/Boson\n>>>>> -- \n>>>>> Kevin L. Mitchell <kevin.mitchell at rackspace.com>\n>>>>> Rackspace\n>>>>> \n>>>>> \n>>>>> _______________________________________________\n>>>>> OpenStack-dev mailing list\n>>>>> OpenStack-dev at lists.openstack.org\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<546CAE82.3080904@redhat.com>',NULL),('<13FD8B6D-9ACD-496E-8339-064457EFB997@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-01-10 16:48:54',3600,'2013-01-10 15:48:54',NULL,'[Openstack-docs] newbie stacker developer?','Yah that would be awesome :)\nI don\'t know how the different languages are managed by Horizon (ie - which files) but it\'s definitely a good idea :)\nAs for the workflow/ teams, specifics,  I don\'t really know if there is something to know.\nI CCed our team that could help me on that one.\n \n\nRazique Mahroua - Nuage & Co\nrazique.mahroua at gmail.com\nTel : +33 9 72 37 94 15\n\n\n\nLe 10 janv. 2013 ? 16:46, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> a ?crit :\n\n> Before I forgot to tell you about my disposal for improving the translation of Horizon to Spanish (es). do you think?\n> \n> \n> 2013/1/10 JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com>\n> Excellent guide! ;)\n> \n> \n> 2013/1/10 Razique Mahroua <razique.mahroua at gmail.com>\n> Anytime man :)\n> Enjoy, don\'t hesitate to ask in case you have any question. In case you want to learn Python quickly, that website is good : \n> learnpythonthehardway.org\n> \n> \n> Razique Mahroua - Nuage & Co\n> razique.mahroua at gmail.com\n> Tel : +33 9 72 37 94 15\n> \n> <NUAGECO-LOGO-Fblan_petit.jpg>\n> \n> Le 10 janv. 2013 ? 16:03, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> a ?crit :\n> \n>> Nice! I know some friends who use sublime text2 :)\n>> \n>> Thanks for your attention, Razique!\n>> \n>> 2013/1/10 Razique Mahroua <razique.mahroua at gmail.com>\n>> Ok,\n>> you can then install VMWare or VirtualBox, set up an OpenStack AIO lab on it for testing your dev.\n>> For the development env, you can check that link \n>> http://stackoverflow.com/questions/81584/what-ide-to-use-for-python\n>> \n>> and pick one. I like sublime text2. It\'s not really an IDE, but it\'s cool for developping. As for the workflow, refer to that link : \n>> http://wiki.openstack.org/GerritWorkflow\n>> \n>> Let me know if you have any other questions, or feel free to browse the wiki\n>> \n>> Regards,\n>> Razique Mahroua - Nuage & Co\n>> razique.mahroua at gmail.com\n>> Tel : +33 9 72 37 94 15\n>> \n>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>> \n>> Le 10 janv. 2013 ? 15:45, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> a ?crit :\n>> \n>>> Currently I\'m working over win7 or 8 ;)\n>>> \n>>> 2013/1/10 Razique Mahroua <razique.mahroua at gmail.com>\n>>> Hi man\n>>> on which environment are you working ? (I mean your working station)\n>>> \n>>> Razique Mahroua - Nuage & Co\n>>> razique.mahroua at gmail.com\n>>> Tel : +33 9 72 37 94 15\n>>> \n>>> <NUAGECO-LOGO-Fblan_petit.jpg>\n>>> \n>>> Le 10 janv. 2013 ? 14:22, JuanFra Rodriguez Cardoso <juanfra.rodriguez.cardoso at gmail.com> a ?crit :\n>>> \n>>>> Hi Razique:\n>>>> \n>>>> As a newbie stacker, I\'d like to start debugging/contributing OpenStack code myself.\n>>>> What do you suggest as dev tools? I read some guys are using Eclipse + PyDev... I\'d be interested in knowing what are your preferences?\n>>>> \n>>>> Thanks!\n>>>> \n>>>> Regards,\n>>>> JuanFra.\n>>> \n>>> \n>> \n>> \n> \n> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130110/8bef1a89/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20130110/8bef1a89/attachment-0001.jpg>\n\n','<CAGXO4kxbFrGJXSh4WmSYCUUBsCnn1bfDBfBVVV+KS+b-JPnseg@mail.gmail.com>',NULL),('<1400009299.2095273.1389727945323.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-14 14:32:25',-18000,'2014-01-14 19:32:25',NULL,'[Openstack] Seeking clarification of \'auth_uri\' configuration\n key','----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: openstack at lists.openstack.org\n> Sent: Tuesday, January 14, 2014 2:12:47 PM\n> Subject: [Openstack] Seeking clarification of \'auth_uri\' configuration key\n> \n> Hi,\n> \n> When authenticating via Keystone, most services seem to require configuring\n> the \'auth_uri\' key to prevent the following warning:\n> \n> WARNING keystoneclient.middleware.auth_token [-] Configuring auth_uri to\n> point to the public identity endpoint is required; clients may not be able\n> to authenticate against an admin endpoint\n> \n> I found several permutations of this key in the installation guide and seek\n> clarification on the following items:\n> \n> 1) Should this key contain \'http://controller:5000\' or \'\n> http://controller:5000/v2.0\'?\n> \n> 2) Should this key reside in the general configuration file (e.g.,\n> nova.conf) or the paste configuration file (e.g., api-paste.ini)?\n> \n> Thanks,\n> Matt\n\n...and to pile on, another aspect I don\'t think we got around to clarifying in the documentation - if auth_uri is set is setting of the various bits that define it still required, e.g. [1]:\n\nauth_host = controller\nauth_port = 35357\nauth_protocol = http\nauth_uri = http://controller:5000/v2.0\n\n(Yes I noticed that auth_port contradicts auth_uri, but that\'s the way it currently is in the guide :/)\n\nThanks,\n\nSteve\n\n[1] http://docs.openstack.org/trunk/install-guide/install/apt/content/nova-controller.html\n\n\n','<CABA+jQoearmu61Nj2UETT_wiMt8gMaKGEKosDmpwart4h+FX_g@mail.gmail.com>',NULL),('<1400257512.23237.118225041.2757AB48@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-16 09:25:12',-25200,'2014-05-16 16:25:12',NULL,'[openstack-dev] [TripleO] Haproxy configuration options','On Fri, May 16, 2014, at 02:52 AM, Jan Provazn?k wrote:\n> On 05/12/2014 10:35 AM, Dmitriy Shulyak wrote:\n> > Adding haproxy (or keepalived with lvs for load balancing) will\n> > require binding haproxy and openstack services on different sockets.\n> > Afaik there is 3 approaches that tripleo could go with.\n> >\n> > Consider configuration with 2 controllers:\n> >\n> > haproxy: nodes: -   name: controller0 ip: 192.0.2.20 -   name:\n> > controller1 ip: 192.0.2.21\n> >\n> > 1. Binding haproxy on virtual ip and standard ports\n> >\n> > haproxy: services: -   name: horizon proxy_ip: 192.0.2.22 (virtual\n> > ip) port: 80 proxy_port: 80 -   name: neutron proxy_ip: 192.0.2.22\n> > (virtual ip) proxy_port: 9696 port: 9696\n> >\n> > Pros: - No additional modifications in elements is required\n> \n> Actually openstack services elements have to be updated to bind to local\n> address only.\n\nAnother big issue with this set up is dealing with changes to interfaces\non the box. We would have to detect when a new interface is added, and\nhave the app-specific logic to make the application aware of the new\ninterface (typically just editing the app\'s config file isn\'t enough for\nthis). Note that this is not an issue when an app binds to 0.0.0.0.\n\n> \n> > HA-Proxy version 1.4.24 2013/06/17 What was the reason this approach\n> >  was dropped?\n> \n> IIRC the major reason was that having 2 services on same port (but\n> different interface) would be too confusing for anyone who is not aware\n> of this fact.\n> \n> >\n> > 2. Haproxy listening on standard ports, services on non-standard\n> >\n> > haproxy: services: -   name: horizon proxy_ip: 192.0.2.22 (virtual\n> > ip) port: 8080 proxy_port: 80 -   name: neutron proxy_ip: 192.0.2.22\n> >  (virtual ip) proxy_port: 9696 port: 9797\n> >\n> > Pros: - No changes will be required to init-keystone part of\n> > workflow - Proxied services will be accessible on accustomed ports\n> \n> Bear in mind that we already use not-standard SSL ports for public\n> endpoints. Also extra work will be required for setting up stunnels\n> (element openstack-ssl).\n> \n> > - No changes to configs where services ports need to be hardcoded,\n> > for example in nova.conf https://review.openstack.org/#/c/92550/\n> >\n> > Cons: - Config files should be changed to add possibility of ports\n> > configuration\n> \n> Another cons is also updating selinux and firewall rules for each node.\n> \n\nAlso Iptables rules. On the plus side, these ports should *really* be\nconfigurable anyway.\n\n> >\n> > 3. haproxy on non-standard ports, with services on standard\n> >\n> > haproxy: services: -   name: horizon proxy_ip: 192.0.2.22 (virtual\n> > ip) port: 8080 proxy_port: 80 -   name: neutron proxy_ip: 192.0.2.22\n> >  (virtual ip) proxy_port: 9797 port: 9696\n> >\n> > Notice that i changed only port for neutron, main endpoint for\n> > horizon should listen on default http or https ports.\n> >\n> \n> Agree that having 2 service ports switched in other way than other is \n> sub-optimal.\n\n+1 on this solution being the least preferred - we shouldn\'t be pushing\nthe extra configuration work onto our clients.\n\n> \n> > Basicly it is opposite to 2 approach. I would prefer to go with 2,\n> > cause it requires only minor refactoring.\n> >\n> > Thoughts?\n> >\n> \n> Options 2 and 3 seem quite equal based on pros vs cons. Maybe we should \n> reconsider option 1?\n> \n> Jan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5375DFF4.5080504@redhat.com>',NULL),('<1400324098.9453.YahooMailNeo@web171602.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-17 11:54:58',3600,'2014-05-17 10:54:58',NULL,'[Openstack] Is there any way to get the user\'s activities?','\nOn Saturday, 17 May 2014, 4:57:58, LIU Yulong <yeuleon at qq.com> wrote:\n>\n>Is there any way to get the user\'s activities?\n\n\nThere is something what is called Keystone Event Notifications.\nA notification is sent when a resource is? created/updated/deleted.\nCheckout this file keystone/doc/source/event_notifications.rst from \nkeystone source code. \nMaybe this is what you looking for?\n\n\n- Radoslaw Smigielski\n\n\n','<tencent_47C5E243057BFBE617618566@qq.com>',NULL),('<1400430651-sup-2513@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-18 09:50:15',-25200,'2014-05-18 16:50:15',NULL,'[Openstack] Why are OpenStack installs *so* hard to get fully\n	functional?','Excerpts from James Burnash - NOAA Affiliate\'s message of 2014-05-13 07:32:54 -0700:\n> Greetings All.\n> \n> First  - some context:\n> \n> I\'ve been doing enterprise Unix / Linux administration for 20+ years, and I\n> like to think that I\'m reasonably competent at installing and administering\n> complex service stacks. So I\'m not new to this area of endeavor.\n> \n\nI think one problem is that it isn\'t just a complex service stack. It\nis many complex service stacks, loosely coupled by keystone. Each one\nis a challenge to get set up, provision onto hardware, initialize with\ndata, etc.\n\nhttp://docs.openstack.org/training-guides/content/module001-ch004-openstack-architecture.html\n\nIt is also being driven by orgs that intend to deploy it at a really\nlarge scale, so new deployers with small to medium scale may find that\ntheir voices are getting lost. That is something that concerns me as\nwell, though I\'d hope some orgs will spring up (whether corporate or\nmore coalition based) that will champion the needs of these users.\n\n> What I\'ve found, however, is that, quite simply - the instructions just\n> don\'t work to ultimately produce a fully functional OpenStack platform,\n> even using the \"official \"documentation.\n>\n\nWe have a project to deploy OpenStack using itself, which will provide an\noption that will at least lead to a situation where you are more familiar\nwith OpenStack itself while you get it deployed. It also should help\nthe project as a whole become more familiar with the challenges that it\npresents to deployers.\n\nhttps://wiki.openstack.org/wiki/TripleO\n\nTripleO is for \"OpenStack on OpenStack\".\n\nWe are capable of deploying a real production ready deployment today,\nbut we are still not HA, and ongoing maintenance is brittle due to\nissues with Heat. That is what we hope to solve in Juno.\n\n> Quick Prototype installation - assorted failures\n> on \"regular\"\n> <https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html>\n> redhat.com:\n> (http<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html>\n> s://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platfo<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html><https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html>\n> rm/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html<https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/part-Deploying_OS_using_PackStack.html>\n> )\n> \n> Deploying it with Foreman:\n> (http://openstack.redhat.com/Deploying_RDO_using_Foreman#Foreman_with_RDO)\n> ...\n> \n> The closest I\'ve come to something that works is going step by step through\n> this at docs.openstack:\n> http://docs.openstack.org/havana/config-reference/content/config_overview.html\n> \n> My environment is:\n> Dell r710 servers (at least 12GB RAM, 20GB disk)\n\nHow many?\n\n> CentOS 6.5\n> Dual 1/10 NICs in each server (for private and public IP\'s)\n> \n> I\'m interested to hear from other people on this list that are encountering\n> the same problem - namely that the cook book instructions aren\'t working\n> for us - and maybe we can help each other.\n> \n\nThe best way to address the issues with documentation is to report bugs\nin the manuals project:\n\nhttps://bugs.launchpad.net/openstack-manuals/+filebug\n\n\n','<CAPOck0z4EnUkY9=rJiMJOvkTnfusJU6jehX9m_JgSvTmAc3Hww@mail.gmail.com>',NULL),('<1400513563797.50781@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-19 15:32:43',0,'2014-05-19 15:32:43',NULL,'[openstack-dev] JUNO BP review and Approvals','Hi Kyle\n\nThanks a lot for the comment and BP review.\n\nCan you also kindly comment on the proposed deadlines for Code Review/merge. \n\nAlso I feel, Adding these important dates in the openstack wiki page might help the new developers to schedule their work for the milestones. \n\nThanks alot for the review.\n\n-\nTrinath\n\n\n\n________________________________________\nFrom: Kyle Mestery <mestery at noironetworks.com>\nSent: Monday, May 19, 2014 8:06 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] JUNO BP review and Approvals\n\nOn Mon, May 19, 2014 at 7:00 AM, trinath.somanchi at freescale.com\n<trinath.somanchi at freescale.com> wrote:\n> Hi Stackers-\n>\n>\n>\n> Since, the Juno summit is completed, when can we have the JUNO Blueprints\n> reviews and approvals getting started.\n>\n>\n>\n> Kindly help me the J-1 deadlines for Blueprint approval and Code merge.\n>\n>\n>\n> Thanks in advance\n>\nHi Trinath:\n\nThis process is ongoing already. For Neutron specifically, I spoke\nabout this in the opening session and it was documented on the\netherpad here [1]. The Neutron devs are actively reviewing BPs now.\n\nThanks!\nKyle\n\n[1] https://etherpad.openstack.org/p/juno-neutron-policies\n\n> --\n>\n> Trinath Somanchi - B39208\n>\n> trinath.somanchi at freescale.com | extn: 4048\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi0FYTcH1esnD3wTPvDCvTHQUM2rknFOrKCGViRmd6zFBA@mail.gmail.com>',NULL),('<1400516978-sup-1073@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-19 09:35:56',-25200,'2014-05-19 16:35:56',NULL,'[openstack-dev] [HEAT] Discussion: How to list nested stack\n	resources.','Excerpts from Tim Schnell\'s message of 2014-05-19 08:26:22 -0700:\n> Hi Nilakhya,\n> \n> As Randall mentioned we did discuss this exact issue at the summit. I was\n> planning on putting a blueprint together today to continue the discussion.\n> The Stack Preview call is already doing the necessary recursion to gather\n> the resources so we discussed being able to pass a stack id to the preview\n> endpoint to get all of the resources.\n> \n> However, after thinking about it some more, I agree with Randall that\n> maybe this should be an extra query parameter passed to the resource-list\n> call. I\'Ll have the blueprint up later today, unless you have already\n> started on it.\n\n+1 to a flag, and anything else that makes nested stacks less weird.\n\n\n','<CF9F89BC.14168%tim.schnell@rackspace.com>',NULL),('<1400517480.866380@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-05-19 11:38:00',-18000,'2014-05-19 16:38:00',NULL,'[openstack-community] Open Cloud Day @ OSCON: Call for Papers now\n	open','\nOpen Cloud Day is Monday, July 21, 9am-5pm.  It\'s part of OSCON in Portland, OR. OpenStack, Red Hat, Chef and Citrix are sponsors.  The Call for Papers (aka Presentations) is now open.  Each speaking slot is 30 minutes.  Please submit requests at http://www.oscon.com/oscon2014/public/cfp/337. \n \nWe would especially appreciate case studies.  FYI, the OSCON audience is primarily enterprise open source developers and DevOps.  They appreciate real life operational experiences.\n \nAll Stackers can attend for no charge using passcode OPENSTACKEHO at [registration](https://en.oreilly.com/oscon2014/public/register). This offers entry for OpenCloud Day, the OpenStack 4th birthday party (July 22, 7pm) as well as other OSCON sponsored sessions and parties July 22-24.   Or, use OPENSTACK25 for a 25% discount on any other OSCON pass.\n \nWe hope to see you there!  Thank you.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140519/b43f4d43/attachment.html>\n\n',NULL,NULL),('<1400543893.17914.3.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-19 19:58:13',-14400,'2014-05-19 23:58:13',NULL,'[openstack-dev] [Keystone] ARBAC Resources','These are the ARBAC documents that came up in our meeting with Shawn\nMcKinney at Summit: \n\n1. OpenStack RBAC proposal slide deck\nhttp://people.redhat.com/jlennox/OpenStackRbacProposal2014.pdf\n\n2. ANSI RBAC (INCITS 359-2004) Specification document: \nhttp://profsandhu.com/journals/tissec/ANSI+INCITS+359-2004.pdf\n\n3. ARBAC02 Model:\nhttp://profsandhu.com/journals/tissec/p113-oh.pdf\n\n4. Development of a standard LDAP Schema for RBAC: \nhttp://daasi.de/wp-content/uploads/2013/11/Development.of_.RBAC_.schema.v31.pdf\n\n5. Java One 2013 - RBAC talk - Oracle San Francisco (first half of\npresentation goes over RBAC misconceptions):\nhttps://oracleus.activeevents.com/2013/connect/fileDownload/session/CD39984569B4EFA3C08EC9A3F3A8C185/CON2381_McKinney.pptx\n\n6. The Z Notation: a reference manual (INCITS 359 specs written in Z):\nhttp://spivey.oriel.ox.ac.uk/mike/zrm/\n\n\nAnd the Fortress APIs that implement it: \n\n1. RBAC functional model:\n\na. Administrative Commands for RBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/AdminMgr.html\n\nb. Policy Review Commands for RBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/ReviewMgr.html\n\nc. System Commands (Policy Enforcement) for RBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/AccessMgr.html\n\n\n2. ARBAC functional model:\n\na. Administrative Commands for ARBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/DelAdminMgr.html\n\nb. Policy Review Commands for ARBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/DelReviewMgr.html\n\nc. System Commands for ARBAC:\nhttp://www.jts.us/iamfortress/javadocs/api/us/jts/fortress/DelAccessMgr.html\n\n\n\n\n\n',NULL,NULL),('<1400552906.3211.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 02:28:27',0,'2014-05-20 02:28:27',NULL,'[openstack-dev] [Neutron][LBaaS] Updated Object Model?','In the API meeting at the summit, Mark McClain mentioned that the\nexisting API should be supported, but deprecated so as not to interrupt\nthose using the existing API.  To me, that sounds like the object model\ncan change but there needs to be some kind of adapter/translation layer\nthat modifies any existing current API calls to the new object model.\n\nSo currently there is this blueprint spec that Eugene submitted:\n\nhttps://review.openstack.org/#/c/89903/3/specs/juno/lbaas-api-and-objmodel-improvement.rst\n\nThat is implementing the object model with VIP as root object.  I\nsuppose this needs to be changed to have the changed we agreed on at the\nsummit.  Also, this blueprint should also cover the layer in which to\nthe existing API calls get mapped to this object model.\n\nMy question is to anyone who knows for certain: should this blueprint\njust be changed to reflect the new object model agreed on at the summit\nor should a new blueprint spec be created?  If it should just be changed\nshould it wait until Eugene gets back from vacation since he\'s the one\nwho created this blueprint spec?\n\nAfter that, then the API change blueprint spec should be created that\nadds the /loadbalancers resource and other changes.  \n\nIf anyone else can add anything please do.  If I said anything wrong\nplease correct me, and if anyone can answer my question above please do.\n\nThanks,\nBrandon Logan\n\nOn Mon, 2014-05-19 at 17:06 -0400, Susanne Balle wrote:\n> Great summit!! fantastic to meeting you all in person. \n> \n> \n> We now have agreement on the Object model. How do we turn that into\n> blueprints and also how do we start making progress on the rest of the\n> items we agree upon at the summit?\n> \n> \n> Susanne\n> \n> \n> On Fri, May 16, 2014 at 2:07 AM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Yeah that?s a good point.  Thanks!\n>         \n>         \n>         From: Eugene Nikanorov <enikanorov at mirantis.com>\n>         Reply-To: \"openstack-dev at lists.openstack.org\"\n>         <openstack-dev at lists.openstack.org>\n>         \n>         Date: Thursday, May 15, 2014 at 10:38 PM\n>         \n>         To: \"openstack-dev at lists.openstack.org\"\n>         <openstack-dev at lists.openstack.org>\n>         Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated Object\n>         Model?\n>         \n>         \n>         \n>         Brandon, \n>         \n>         \n>         It\'s allowed right now just per API. It\'s up to a backend to\n>         decide the status of a node in case some monitors find it\n>         dead.\n>         \n>         \n>         Thanks,\n>         Eugene.\n>         \n>         \n>         \n>         \n>         On Fri, May 16, 2014 at 4:41 AM, Brandon Logan\n>         <brandon.logan at rackspace.com> wrote:\n>                 I have concerns about multiple health monitors on the\n>                 same pool.  Is this always going to be the same type\n>                 of health monitor?  There?s also ambiguity in the case\n>                 where one health monitor fails and another doesn?t.\n>                  Is it an AND or OR that determines whether the member\n>                 is down or not?\n>                 \n>                 \n>                 Thanks,\n>                 Brandon Logan\n>                 \n>                 \n>                 From: Eugene Nikanorov <enikanorov at mirantis.com>\n>                 Reply-To: \"openstack-dev at lists.openstack.org\"\n>                 <openstack-dev at lists.openstack.org>\n>                 Date: Thursday, May 15, 2014 at 9:55 AM\n>                 To: \"openstack-dev at lists.openstack.org\"\n>                 <openstack-dev at lists.openstack.org> \n>                 \n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Updated\n>                 Object Model?\n>                 \n>                 \n>                 \n>                 Vijay, \n>                 \n>                 \n>                 Pools-monitors are still many to many, if it\'s not so\n>                 on the picture - we\'ll fix that.\n>                 I brought this up as an example of how we dealt with\n>                 m:n via API.\n>                 \n>                 \n>                 Thanks,\n>                 Eugene.\n>                 \n>                 \n>                 On Thu, May 15, 2014 at 6:43 PM, Vijay Venkatachalam\n>                 <Vijay.Venkatachalam at citrix.com> wrote:\n>                         Thanks for the clarification. Eugene.\n>                         \n>                          \n>                         \n>                         A tangential point since you brought healthmon\n>                         and pool.\n>                         \n>                          \n>                         \n>                         There will be an additional entity called\n>                         ?PoolMonitorAssociation? which results in a\n>                         many to many relationship between pool and\n>                         monitors. Right?\n>                         \n>                          \n>                         \n>                         Now, the model is indicating a pool can have\n>                         only one monitor. So a minor correction is\n>                         required to indicate the many to many\n>                         relationship via PoolMonitorAssociation. \n>                         \n>                          \n>                         \n>                         Thanks,\n>                         \n>                         Vijay V.\n>                         \n>                          \n>                         \n>                          \n>                         \n>                         From: Eugene Nikanorov\n>                         [mailto:enikanorov at mirantis.com] \n>                         Sent: Thursday, May 15, 2014 7:36 PM\n>                         \n>                         \n>                         To: OpenStack Development Mailing List (not\n>                         for usage questions)\n>                         Subject: Re: [openstack-dev] [Neutron][LBaaS]\n>                         Updated Object Model?\n>                          \n>                         \n>                         Hi Vijay,\n>                         \n>                                 \n>                                  \n>                                 \n>                                 \n>                                 When you say API is not available, it\n>                                 means this should not be considered\n>                                 like a resource/entity. Correct?\n>                                 \n>                                  \n>                                 \n>                                 But then, there would be API like a\n>                                 bind API, that accepts loadbalancer_id\n>                                 & listener_id,  which creates this\n>                                 object.\n>                                 \n>                                 And also, there would be an API that\n>                                 will be used to list the listeners of\n>                                 a LoadBalancer.\n>                                 \n>                                  \n>                                 \n>                                 Right?\n>                                 \n>                                 \n>                         Right, that\'s the same as health monitors and\n>                         pools work right now: there are separate REST\n>                         action to associate healthmon to a pool\n>                         \n>                         \n>                          \n>                         \n>                         \n>                          \n>                         \n>                         \n>                         Thanks,\n>                         \n>                         \n>                         Eugene.\n>                         \n>                         \n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+zx9Ce=j2eW4-ZNT3UZ+eCEF-PgnbM50303L2sSXKWO0Q@mail.gmail.com>',NULL),('<1400619860-sup-9135@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 14:12:27',-25200,'2014-05-20 21:12:27',NULL,'[openstack-dev] [Heat] [Docker] Resource','Excerpts from Andrew Plunk\'s message of 2014-05-20 13:49:58 -0700:\n> No Problem.\n> \n> As the Docker resource in Heat currently works, it will require Docker running on a customer\'s vm to listen over a network socket. With software config you could allow Docker to listen on the instance\'s local unix socket, and communicate with Docker via Heat\'s in instance software config agents.\n> \n\nThis would effectively make Docker another case of \"syntactic sugar\",\nmuch like OS::SoftwareConfig::Chef would be.\n\nShort term I think this will get Docker onto Heat users\' instances\nquicker.\n\nHowever I do think that the limitations of this approach are pretty\nlarge, such as how to model the network in such a way where we could\nattach a floating IP to a container running in a VM. There\'s a lot of\nextra plumbing that gets shrugged off to user-managed hosts that seems\nlike a generic nesting interface that would be useful for things like\nTripleO too where we want to nest a VM inside the deployment cloud.\n\nAnyway, the local socket is the way to go. The less we teach Heat\'s\nengine to reach out to non-OpenStack API\'s, the more we can keep it\nisolated from hostile entities.\n\n\n','<CFA129DA.11773%andrew.plunk@rackspace.com>',NULL),('<1400625818-sup-5636@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-20 15:45:35',-25200,'2014-05-20 22:45:35',NULL,'[Openstack] HEAT and MySQL 5.6','Excerpts from Clint Dilks\'s message of 2014-05-20 14:30:40 -0700:\n> Hi,\n> \n> I seem to be hitting a known issue with HEAT MySQL 5.6 and UTF8\n> \n> ERROR: (OperationalError) (1071, \'Specified key was too long; max key\n> length is 767 bytes\') \'CREATE INDEX ix_software_config_tenant ON\n> software_config (tenant)\' ()\n> \n> So based off https://bugs.launchpad.net/heat/+bug/1316646 I have made the\n> following modifications to the heat database.\n> \n> mysql> alter table software_config modify column tenant varchar(64) NOT\n> NULL;\n> \n> mysql> CREATE INDEX ix_software_config_tenant ON software_config (tenant);\n> \n> Is reducing the size of the tenant column likely to cause issues later?\n\nNo, in researching the issue, I found that all of these columns should be\nvarchar(64). I seem to have lost track of the patches though. We should\ndefinitely fix this in juno, since MySQL 5.6 is starting to arrive in\nthe distros.\n\n\n','<CACdTQcVgXPrXObkNHEsRGmxGn2O7=nCzw8e4jmJ1FH-uXyuHQA@mail.gmail.com>',NULL),('<1400628442.2177.20.camel@MacbookPro-UbuntuGnome>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 23:27:23',0,'2014-05-20 23:27:23',NULL,'[openstack-dev] [Neutron][LBaaS] Neutron LBaaS \"operator scale\"\n service --- Next steps and goals.','Hi Susanne,\n\nOne comment in line.\n\nOn Tue, 2014-05-20 at 19:12 -0400, Susanne Balle wrote:\n> We have had some discussions around how to move forward with the LBaaS\n> service in OpenStack.  I am trying to summarize the key points below.\n> \n> \n> Feel free to chime in if I misrepresented anything or if you\n> disagree :-)\n> \n>  \n> \n> For simplicity in the rest of the email and so I can differentiate\n> between all the LBaaS?s e.g. Neutron LBaaS, etc? I will name the new\n> OpenStack LBaaS project (that we discussed at the summit): Octavia in\n> the rest of this email. Note that this doesn?t mean we have agree on\n> this name.\n> \n>  \n> \n> Goal:\n> \n> We all want to create a best in class ?operator scale? Octavia LBaaS\n> service to our customers.\n> \n> Following requirements need to be considered (these are already listed\n> in some of the etherpads we have worked on)\n> \n> ?         Provides scalability, failover, config management, and\n> provisioning.\n> \n> ?         Architecture need to be pluggable so we can offer support\n> for HAProxy, Nginx, LVS, etc.\n> \n>  \n> \n> Some disagreements exist around the scope of the new project:\n> \n>  \n> \n> Some of the participating companies including HP are interested in a\n> best in class standalone Octavia load-balancer service that is part of\n> OpenStack and with the ?label?\n> OpenStack. http://www.openstack.org/software/\n> \n> ?         The Octavia LBaaS project needs to work well with OpenStack\n> or this effort is not worth doing. HP believes that this should be the\n> primary focus.\n> \n> ?         In this case the end goal would be to have a clean interface\n> between Neutron and the standalone Octavia LBaaS project and have the\n> Octavia LBaaS project become an incubated and eventual graduated\n> OpenStack project.\n> \n> o   We would start out as a driver to Neutron.\n> \n> o   This project would deprecate Neutron LBaaS long term since part of\n> the Neutron LBaaS would move over to the Octavia LBaaS project.\n> \n> o   This project would continue to support both vendor drivers and new\n> software drivers e.g. ha-proxy, etc.\n> \n> ?         Dougwig created the following diagram which gives a good\n> overview of my thinking: http://imgur.com/cJ63ts3 where Octavia is\n> represented by ?New Driver Interface? and down. The whole picture\n> shows how we could move from the old to the new driver interface\n> \n>  \n> \n> Other participating companies want to create a best in class\n> standalone load-balancer service outside of OpenStack and only create\n> a driver to integrate with Openstack Neutron LBaaS.  \n> \n> ?         The Octavia LBaaS driver would be part of Neutron LBaaS tree\n> whereas the Octavia LBaaS implementation would reside outside\n> OpenStack e.g. Stackforge or github, etc.\n\nI don\'t think they want Octavia LBaaS to be in stackforge, just the\nHA/scalable provider implementation (HaProxy, Nginx, LVS, etc).  So the\nAPI would still be the frontend of the Octavia LBaaS (which would be an\nOpenStack project), but the API would call a driver (that still needs to\nbe created as well) that was written to talk to this HA/scalable\nprovider implementation.  The actual code for this HA/scalable provider\nwould exist in stackforge, much like a vendor (radware, netscaler, etc)\nwould not put their code in the Octavia LBaaS\'s tree.\n\nJust thought I\'d clear that up so we can get other people\'s thoughts on\nthis.\n> \n>  \n> \n> The main issue/confusion is that some of us (HP LBaaS team) do not\n> think of projects in StackForge as OpenStack branded. HP developed\n>  Libra LBaaS which is open sourced in StackForge and when we tried to\n> get it into OpenStack we met resistance.\n> \n>  \n> \n> One person suggested the idea of designing the Octavia LBaaS service\n> totally independent of Neutron or any other service that calls. This\n> might makes sense for a general LBaaS service but given that we are in\n> the context of OpenStack this to me just makes the whole testing and\n> developing a nightmare to maintain and not necessary. Again IMHO we\n> are developing and delivering Octavia in the context of OpenStack so\n> the Octavia LBaaS  should just be super good at dealing with the\n> OpenStack env. The architecture can still be designed to be pluggable\n> but my experiences tell me that we will have to make decision and\n> trade-offs and at that point we need to remember that we are doing\n> this in the context of OpenStack and not in the general context.\n> \n>  \n> \n> How do we think we can do it?\n> \n>  \n> \n> We have some agreement around the following approach:\n> \n>  \n> \n> ?         To start developing the driver/Octavia implementation in\n> StackForge which should allow us to increase the velocity of our\n> development using the OpenStack CI/CD tooling (incl. jenkins) to\n> ensure that we test any change. This will allow us to ensure that\n> changes to Neutron do not break our driver/implementation as well as\n> the other way around.\n> \n> o   We would use Gerrit for blueprints so we have documented reviews\n> and comments archived somewhere.\n> \n> o   Contribute patches regularly into the Neutron LBaaS tree:\n> \n> ?  Kyle has volunteered himself and one more core team members to\n> review and help move a larger patch into Neutron tree when needed. It\n> was also suggested that we could do milestones of smaller patches to\n> be merged into Neutron LbaaS. The latter approach was preferred by\n> most participants.\n> \n>  \n> \n> The main goal behind this approach is to make sure we increase\n> velocity while still maintaining a good code/design quality. The\n> OpenStack tooling has shown to work for large distributed virtual\n> teams so let\'s take advantage of it.\n> \n> Carefully planning the various transitions.\n> \n>  \n> \n> Regards Susanne\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+x12gNVzmQeS+aqi-POJYN=uSn58S8jEmB6OCmXN+eseg@mail.gmail.com>',NULL),('<1400673788495.20593@freescale.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-05-21 11:51:31',0,'2014-05-21 11:51:31',NULL,'[OpenStack-Infra] Zuul unable to parse projects','Hi-\n\n\nWith Zuul version, 2.0.0.155, I\'m facing a problem with layout.yaml\n\n\nThe projects section is as follows in layout.yaml.\n\nprojects:\n  - name: openstack-dev/sandbox\n    check:\n      - TEST-SANDBOX\n\nbut when the gerrit event arrives, zuul log shows the following warning.\n\n2014-05-21 17:31:34,566 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found?\n\nkindly help me resolve the issue.\n\nThanks in advance.\n\n-\nTrinath\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140521/b6a560f5/attachment.html>\n\n',NULL,NULL),('<1400683707.26118.3.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 10:48:27',-14400,'2014-05-21 14:48:27',NULL,'[openstack-dev] [sahara] Nominate Trevor McKay for sahara-core','Thank you all,\n\n  I have been away from a computer for a few days post Summit :)\n\nI appreciate your vote of confidence, and I look forward to continued\nwork on Sahara.  Here\'s to more Big Data processing on Openstack!\n\nBest regards,\n\nTrevor\n\nOn Mon, 2014-05-19 at 10:13 -0400, Sergey Lukjanov wrote:\n> Trevor, congrats!\n> \n> welcome to the sahara-core.\n> \n> On Thu, May 15, 2014 at 11:41 AM, Matthew Farrellee <matt at redhat.com> wrote:\n> > On 05/12/2014 05:31 PM, Sergey Lukjanov wrote:\n> >>\n> >> Hey folks,\n> >>\n> >> I\'d like to nominate Trevor McKay (tmckay) for sahara-core.\n> >>\n> >> He is among the top reviewers of Sahara subprojects. Trevor is working\n> >> on Sahara full time since summer 2013 and is very familiar with\n> >> current codebase. His code contributions and reviews have demonstrated\n> >> a good knowledge of Sahara internals. Trevor has a valuable knowledge\n> >> of EDP part and Hadoop itself. He\'s working on both bugs and new\n> >> features implementation.\n> >>\n> >> Some links:\n> >>\n> >> http://stackalytics.com/report/contribution/sahara-group/30\n> >> http://stackalytics.com/report/contribution/sahara-group/90\n> >> http://stackalytics.com/report/contribution/sahara-group/180\n> >>\n> >> https://review.openstack.org/#/q/owner:tmckay+sahara+AND+-status:abandoned,n,z\n> >> https://launchpad.net/~tmckay\n> >>\n> >> Sahara cores, please, reply with +1/0/-1 votes.\n> >>\n> >> Thanks.\n> >>\n> >\n> > +1\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n\n\n\n\n','<CA+GZd7-hUkddig6LGTK99rTM+7GobYaU6-2BCQwmNoeXyzHS0Q@mail.gmail.com>',NULL),('<1400690439981.6942@freescale.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-05-21 16:40:40',0,'2014-05-21 16:40:40',NULL,'[OpenStack-Infra] Zuul unable to parse projects','Hi James-\n\nInitially Zuul used to work as intended. \n\nBut in my CI setup, certain options like, \'footer-message\', \'merge-failure-message\' etc..are not supported though they are mentioned in the ZUUL documentation.\nAlso, I haven\'t found zuul-merger in /usr/local/bin/ .\n\nSo i have updated ZUUL code base existing in /opt to the latest code base from git.openstack.org. \n\nI have install Zuul with \'python setup.py install\'\n\nWhen I recofigured Zuul with layout.xml, I found the issue that, though openstack-dev/sandbox is present in projects its not recognised. \n\nWhen I printed the self.layout.projects variable from zuul/scheduler.py, I see blank {}.\n\nWith this new version, does layout.yaml and zuul.conf formats changed?\n\n-\nTrinath\n\n\n\n\n________________________________________\nFrom: Jerry Zhao <xyzjerry at gmail.com>\nSent: Wednesday, May 21, 2014 9:42 PM\nTo: James E. Blair\nCc: Somanchi Trinath-B39208; openstack-infra\nSubject: Re: [OpenStack-Infra] Zuul unable to parse projects\n\nAccording to my own experience, also check if there are any zombie Zuul processes. If there are, restart won\'t take effect. Kill them manually first.\n\n\n\n> On May 21, 2014, at 6:58 AM, jeblair at openstack.org (James E. Blair) wrote:\n>\n> \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> writes:\n>\n>> Hi-\n>>\n>>\n>> With Zuul version, 2.0.0.155, I\'m facing a problem with layout.yaml\n>>\n>>\n>> The projects section is as follows in layout.yaml.\n>>\n>> projects:\n>>  - name: openstack-dev/sandbox\n>>    check:\n>>      - TEST-SANDBOX\n>>\n>> but when the gerrit event arrives, zuul log shows the following warning.\n>>\n>> 2014-05-21 17:31:34,566 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found?\n>\n> I don\'t see anything wrong with that.  Are you sure that Zuul was\n> restarted after changing the config file?  It only reloads the config\n> file after changes if it\'s told to (either with a signal or by\n> restarting).\n>\n> If it still doesn\'t work, would you attach the full layout.yaml as well\n> as the debug output from starting it beginning with \"Configured Pipeline\n> Manager check\".\n>\n> -Jim\n>\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n','<CA86E904-EC50-4742-B220-F87A114E1293@gmail.com>',NULL),('<1400695886.1455040.1375345282262.JavaMail.hzguanqiang@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-01 16:21:18',28800,'2013-08-01 08:21:18',NULL,'[openstack-dev] Is there any document about how to make a lxc image\n	using diskimage-builder?','Hi Steve,\nI found it\'s hard to understand how to make a image from README on github address https://github.com/stackforge/diskimage-builder . Is there any other document about how to make a lxc image using diskimage-builder step by step?\n\nThanks\n		\n--------------\nBest regards!\nGuanQiang\n2013-08-01\n\n\n\n',NULL,NULL),('<1400703064.973813030@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-05-21 15:11:04',-18000,'2014-05-21 20:11:04',NULL,'[openstack-community] Free passes to EuroPython for OpenStack table\n	staffers','\n\n \nThe OpenStack Foundation is pleased to sponsor [EuroPython 2014](https://ep2014.europython.eu/en/), July 21-27, 2014 at the Berlin Congress Center, Germany.  We were jammin\' at North America\'s PyCon in April and expect crowds in Europe as well.  We ask the community, especially OpenStack contributors, to help support this event.\n \nOur silver sponsorship includes a table in the F/OSS area.  We have 5 full conference passes to offer to 5 volunteers who can staff the OpenStack table in shifts covering\nSetup: Sunday, July 20, 1 hour between 16:00-20:00\nExpo Open:  Mon-Fri, July 21-25, 09:00-18:00 (attend sessions between breaks)\nPacking up: Fri, July 25, at 18:00\nPlease send an email to kathyc at openstack.org if you can help inspire the EuroPython attendees to use and contribute to OpenStack.\n \nWe also encourage you to give Lightning Talks (5 minute duration). Register your talk at the venue near the registration desk.\n \nThank you, as always, for your support!\n\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140521/9415bda7/attachment.html>\n\n',NULL,NULL),('<1400719961-sup-9862@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 17:59:03',-25200,'2014-05-22 00:59:03',NULL,'[openstack-dev] Concerns about the ballooning size of keystone\n	tokens','Excerpts from John Dickinson\'s message of 2014-05-21 17:23:02 -0700:\n> \n> On May 21, 2014, at 4:26 PM, Adam Young <ayoung at redhat.com> wrote:\n> \n> > On 05/21/2014 03:36 PM, Kurt Griffiths wrote:\n> >> Good to know, thanks for clarifying. One thing I?m still fuzzy on, however, is why we want to deprecate use of UUID tokens in the first place? I?m just trying to understand the history here...\n> > Because they are wasteful, and because they are the chattiest part of OpenStack.  I can go into it in nauseating detail if you really want, including the plans for future enhancements and the weaknesses of bearer tokens.\n> > \n> > \n> > A token is nothing more than a snap shot of the data you get from Keystone distributed.  It is stored in Memcached and in the Horizon session uses the hash of it for a key.\n> > \n> > You can do the same thing.  Once you know the token has been transferred once to a service, assuming that service has caching on, you can pass the hash of the key instead of the whole thing.  \n> \n> So this would mean that a Swift client would auth against Keystone to get the PKI token, send that to Swift, and then get back from Swift a \"short\" token that can be used for subsequent requests? It\'s an interesting idea to consider, but it is a new sort of protocol for clients to implement.\n> \n\nDoesn\'t this mean that Swift would have to store the token it first\nreceived, so that it can verify that the hash matches the token and to\nextract the session information contained within?\n\nIt seems like the keystone auth middleware should be able to help with\nthis quite a bit, and I think it already does, but a pointer to the\ndocumentation on how to make use of it would help close the loop here.\n\n> > \n> > Actually, you can do that up front, as auth_token middleware will just default to an online lookup. However, we are planning on moving to ephemeral tokens (not saved in the database) and an online lookup won\'t be possible with those.  The people that manage Keystone will be happy with that, and forcing an online lookup will make them sad.\n> \n> An \"online lookup\" is one that calls the Keystone service to validate a token? Which implies that by disabling online lookup there is enough info in the token to validate it without any call to Keystone?\n> \n\nYes, PKI tokens can be validated by the service without phoning back\nhome to Keystone. However, currently the service must still ask Keystone\nfor a list of revoked tokens periodically. In the near future that will\nmorph into a list of token revocation events, which should make the\nbackend simpler for Keystone to implement. I assume the middleware will\nalso do most of the heavy lifting there too.\n\n> I understand how it\'s advantageous to offload token validation away from Keystone itself (helps with scaling), but the current \"solution\" here seems to be pushing a lot of pain to consumers and deployers of data APIs (eg Marconi and Swift and others).\n> \n\nI tend to agree, though if the middleware implements the caching/hashing\nthat Adam describes, then it may only be a few changes to the way that\nis configured.\n\n> > \n> > Hash is MD5 up through what is released in Icehouse.  The next version of auth_token middleware will support a configurable algorithm.  The default should be updated to sha256 in the near future.\n> \n> If a service (like Horizon) is hashing the token and using that as a session key, then why does it matter what the auth_token middleware supports? Isn\'t the hashing handled in the service itself? I\'m thinking in the context of how we would implement this idea in Swift (exploring possibilities, not committing to a patch).\n> \n\nThe impression I got is that Horizon is a special case, and that most\nservices would just use the keystone auth middleware directly.\n\n\n','<FF0F5E29-7198-494B-BAFA-9D9F56F57E49@not.mn>',NULL),('<1400738796909.81576@freescale.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-05-22 05:54:56',0,'2014-05-22 05:54:56',NULL,'[OpenStack-Infra] Zuul unable to parse projects','Hi James -\n\nPlease find the Zuul debug.log below.\n\nopenstack-dev/sandbox is not recognized from layout.yaml\n\n\n2014-05-22 11:23:16,472 INFO gear.Client.unknown: Waiting for connection to internal Gearman server\n2014-05-22 11:23:16,473 INFO gear.Connection.unknown: Disconnected from 127.0.0.1 port 4730\n2014-05-22 11:23:16,474 INFO gear.Connection.unknown: Connected to 127.0.0.1 port 4730\n2014-05-22 11:23:16,474 INFO gear.Client.unknown: Waiting for gearman function set to settle\n2014-05-22 11:23:16,477 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02f50 command: status>\n2014-05-22 11:23:17,483 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02f90 command: status>\n2014-05-22 11:23:18,490 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02e50 command: status>\n2014-05-22 11:23:19,497 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02e90 command: status>\n2014-05-22 11:23:20,506 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02ed0 command: status>\n2014-05-22 11:23:21,515 INFO gear.Client.unknown: Received admin data <gear.AdminRequest 0x1e02f90 command: status>\n2014-05-22 11:23:21,519 INFO gear.Client.unknown: Gearman function set has settled\n2014-05-22 11:23:21,519 INFO gear.Client.unknown: Done waiting for Gearman server\n2014-05-22 11:23:21,521 DEBUG zuul.MergeClient: Connecting to gearman at 127.0.0.1:4730\n2014-05-22 11:23:21,522 DEBUG zuul.MergeClient: Waiting for gearman\n2014-05-22 11:23:21,523 INFO gear.Connection.unknown: Disconnected from 127.0.0.1 port 4730\n2014-05-22 11:23:21,524 INFO gear.Connection.unknown: Connected to 127.0.0.1 port 4730\n2014-05-22 11:23:21,540 INFO zuul.Server: Starting scheduler\n2014-05-22 11:23:21,541 DEBUG zuul.Scheduler: Statsd disabled because python statsd package not found\n2014-05-22 11:23:21,541 DEBUG zuul.Scheduler: Prepare to reconfigure\n2014-05-22 11:23:21,542 DEBUG zuul.Scheduler: Waiting for reconfiguration\n2014-05-22 11:23:21,542 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:23:21,543 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:23:21,544 DEBUG zuul.Scheduler: Fetching management event\n2014-05-22 11:23:21,544 DEBUG zuul.Scheduler: Processing management event <zuul.scheduler.ReconfigureEvent object at 0x1e5bc90>\n2014-05-22 11:23:21,544 DEBUG zuul.Scheduler: Performing reconfiguration\n2014-05-22 11:23:21,572 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:24:33,713 INFO zuul.Gerrit: Updating information for 94358,1\n2014-05-22 11:24:55,992 DEBUG zuul.Gerrit: Change <Change 0x1fab290 94358,1> status: NEW\n2014-05-22 11:24:55,993 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/requirements master 94358,1 Verified:1>\n2014-05-22 11:24:55,994 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:24:55,994 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:24:55,994 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/requirements master 94358,1 Verified:1>\n2014-05-22 11:24:55,995 WARNING zuul.Scheduler: Project openstack/requirements not found\n2014-05-22 11:24:55,995 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:24:55,996 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/requirements master 94358,1 Verified:1>\n2014-05-22 11:24:55,996 INFO zuul.Gerrit: Updating information for 94358,1\n2014-05-22 11:24:57,489 DEBUG zuul.Gerrit: Change <Change 0x1fab290 94358,1> status: NEW\n2014-05-22 11:24:57,490 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/requirements master 94358,1>\n2014-05-22 11:24:57,491 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:24:57,491 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:24:57,491 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/requirements master 94358,1>\n2014-05-22 11:24:57,491 WARNING zuul.Scheduler: Project openstack/requirements not found\n2014-05-22 11:24:57,491 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:24:57,491 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/requirements master 94358,1>\n2014-05-22 11:24:57,492 INFO zuul.Gerrit: Updating information for 92041,1\n2014-05-22 11:24:59,009 DEBUG zuul.Gerrit: Change <Change 0x1fab590 92041,1> status: NEW\n2014-05-22 11:24:59,010 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 92041,1 Code-Review:1>\n2014-05-22 11:24:59,011 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 92041,1 Code-Review:1>\n2014-05-22 11:24:59,011 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:24:59,012 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:24:59,013 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 92041,1 Code-Review:1>\n2014-05-22 11:24:59,013 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:24:59,014 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:24:59,014 INFO zuul.Gerrit: Updating information for 90193,3\n2014-05-22 11:25:00,871 DEBUG zuul.Gerrit: Change <Change 0x1f76cd0 90193,3> status: NEW\n2014-05-22 11:25:00,872 INFO zuul.Gerrit: Updating information for 90192,3\n2014-05-22 11:25:03,101 DEBUG zuul.Gerrit: Change <Change 0x1fabcd0 90192,3> status: NEW\n2014-05-22 11:25:03,102 INFO zuul.Gerrit: Updating information for 90191,3\n2014-05-22 11:25:05,685 DEBUG zuul.Gerrit: Change <Change 0x1fb4e50 90191,3> status: NEW\n2014-05-22 11:25:05,685 INFO zuul.Gerrit: Updating information for 90157,3\n2014-05-22 11:25:13,199 DEBUG zuul.Gerrit: Change <Change 0x1fb41d0 90157,3> status: NEW\n2014-05-22 11:25:13,199 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90193,3 Verified:1>\n2014-05-22 11:25:13,199 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90193,3 Verified:1>\n2014-05-22 11:25:13,200 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:25:13,200 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:25:13,200 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90193,3 Verified:1>\n2014-05-22 11:25:13,201 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:25:13,201 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:25:13,200 INFO zuul.Gerrit: Updating information for 90158,2\n2014-05-22 11:25:15,612 DEBUG zuul.Gerrit: Change <Change 0x1faba90 90158,2> status: NEW\n2014-05-22 11:25:15,613 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90158,2 Code-Review:-1>\n2014-05-22 11:25:15,613 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:25:15,613 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:25:15,613 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90158,2 Code-Review:-1>\n2014-05-22 11:25:15,613 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:25:15,613 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:25:15,614 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90158,2 Code-Review:-1>\n2014-05-22 11:25:15,614 INFO zuul.Gerrit: Updating information for 90158,2\n2014-05-22 11:25:17,065 DEBUG zuul.Gerrit: Change <Change 0x1faba90 90158,2> status: NEW\n2014-05-22 11:25:17,065 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90158,2>\n2014-05-22 11:25:17,066 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:25:17,066 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:25:17,067 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90158,2>\n2014-05-22 11:25:17,067 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:25:17,068 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:25:17,068 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90158,2>\n2014-05-22 11:25:17,068 INFO zuul.Gerrit: Updating information for 94011,13\n2014-05-22 11:25:20,951 DEBUG zuul.Gerrit: Change <Change 0x1fb4750 94011,13> status: NEW\n2014-05-22 11:25:20,952 INFO zuul.Gerrit: Updating information for 94010,13\n2014-05-22 11:25:24,392 DEBUG zuul.Gerrit: Change <Change 0x7fc9500ff490 94010,13> status: NEW\n2014-05-22 11:25:24,392 INFO zuul.Gerrit: Updating information for 94012,13\n2014-05-22 11:25:28,167 DEBUG zuul.Gerrit: Change <Change 0x7fc9500ffc10 94012,13> status: NEW\n2014-05-22 11:25:28,168 INFO zuul.Gerrit: Updating information for 94047,14\n2014-05-22 11:25:33,118 DEBUG zuul.Gerrit: Change <Change 0x7fc9500ff450 94047,14> status: NEW\n2014-05-22 11:25:33,118 INFO zuul.Gerrit: Updating information for 94049,14\n2014-05-22 11:25:37,938 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a3750 94049,14> status: NEW\n2014-05-22 11:25:37,938 INFO zuul.Gerrit: Updating information for 94058,12\n2014-05-22 11:25:41,255 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a3e90 94058,12> status: NEW\n2014-05-22 11:25:41,255 INFO zuul.Gerrit: Updating information for 94208,12\n2014-05-22 11:25:43,867 DEBUG zuul.Gerrit: Change <Change 0x7fc9504a8490 94208,12> status: NEW\n2014-05-22 11:25:43,867 INFO zuul.Gerrit: Updating information for 94296,10\n2014-05-22 11:25:46,048 DEBUG zuul.Gerrit: Change <Change 0x7fc9504a89d0 94296,10> status: NEW\n2014-05-22 11:25:46,049 INFO zuul.Gerrit: Updating information for 94402,9\n2014-05-22 11:25:48,367 DEBUG zuul.Gerrit: Change <Change 0x7fc9504a8dd0 94402,9> status: NEW\n2014-05-22 11:25:48,367 INFO zuul.Gerrit: Updating information for 94487,6\n2014-05-22 11:25:51,630 DEBUG zuul.Gerrit: Change <Change 0x7fc9504a8910 94487,6> status: NEW\n2014-05-22 11:25:51,630 INFO zuul.Gerrit: Updating information for 94488,6\n2014-05-22 11:25:54,869 DEBUG zuul.Gerrit: Change <Change 0x7fc950678450 94488,6> status: NEW\n2014-05-22 11:25:54,869 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 94011,13 Code-Review:2>\n2014-05-22 11:25:54,869 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 94011,13 Code-Review:2>\n2014-05-22 11:25:54,869 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:25:54,870 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:25:54,870 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 94011,13 Code-Review:2>\n2014-05-22 11:25:54,870 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:25:54,871 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:25:54,870 INFO zuul.Gerrit: Updating information for 94461,6\n2014-05-22 11:25:56,804 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a36d0 94461,6> status: NEW\n2014-05-22 11:25:56,805 INFO zuul.Gerrit: Updating information for 94304,4\n2014-05-22 11:25:58,906 DEBUG zuul.Gerrit: Change <Change 0x7fc950678190 94304,4> status: NEW\n2014-05-22 11:25:58,907 INFO zuul.Gerrit: Updating information for 94057,11\n2014-05-22 11:26:01,411 DEBUG zuul.Gerrit: Change <Change 0x7fc9504a8bd0 94057,11> status: NEW\n2014-05-22 11:26:01,412 INFO zuul.Gerrit: Updating information for 94461,5\n2014-05-22 11:26:04,334 DEBUG zuul.Gerrit: Change <Change 0x7fc950678ed0 94461,5> status: NEW\n2014-05-22 11:26:04,335 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent patchset-created openstack/taskflow master 94461,6>\n2014-05-22 11:26:04,336 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:26:04,336 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:26:04,337 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent patchset-created openstack/taskflow master 94461,6>\n2014-05-22 11:26:04,337 WARNING zuul.Scheduler: Project openstack/taskflow not found\n2014-05-22 11:26:04,338 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:26:04,338 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent patchset-created openstack/taskflow master 94461,6>\n2014-05-22 11:26:04,339 INFO zuul.Gerrit: Updating information for 94255,13\n2014-05-22 11:26:06,664 DEBUG zuul.Gerrit: Change <Change 0x7fc9500ff810 94255,13> status: NEW\n2014-05-22 11:26:06,664 INFO zuul.Gerrit: Updating information for 94217,16\n2014-05-22 11:26:09,202 DEBUG zuul.Gerrit: Change <Change 0x7fc950678dd0 94217,16> status: NEW\n2014-05-22 11:26:09,202 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/heat master 94255,13>\n2014-05-22 11:26:09,202 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:26:09,202 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:26:09,203 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/heat master 94255,13>\n2014-05-22 11:26:09,203 WARNING zuul.Scheduler: Project openstack/heat not found\n2014-05-22 11:26:09,203 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:26:09,202 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/heat master 94255,13>\n2014-05-22 11:26:09,203 INFO zuul.Gerrit: Updating information for 94461,6\n2014-05-22 11:26:10,538 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a36d0 94461,6> status: NEW\n2014-05-22 11:26:10,539 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/taskflow master 94461,6>\n2014-05-22 11:26:10,539 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/taskflow master 94461,6>\n2014-05-22 11:26:10,540 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:26:10,540 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:26:10,541 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/taskflow master 94461,6>\n2014-05-22 11:26:10,541 WARNING zuul.Scheduler: Project openstack/taskflow not found\n2014-05-22 11:26:10,541 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:26:10,542 INFO zuul.Gerrit: Updating information for 90157,3\n2014-05-22 11:26:12,476 DEBUG zuul.Gerrit: Change <Change 0x1fb41d0 90157,3> status: NEW\n2014-05-22 11:26:12,477 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90157,3 Verified:1>\n2014-05-22 11:26:12,478 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:26:12,478 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:26:12,479 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90157,3 Verified:1>\n2014-05-22 11:26:12,479 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:26:12,480 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:26:12,480 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90157,3 Verified:1>\n2014-05-22 11:26:14,550 INFO zuul.Gerrit: Updating information for 90993,6\n2014-05-22 11:26:15,814 DEBUG zuul.Gerrit: Change <Change 0x1fb4f10 90993,6> status: NEW\n2014-05-22 11:26:15,815 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/tripleo-image-elements master 90993,6>\n2014-05-22 11:26:15,816 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/tripleo-image-elements master 90993,6>\n2014-05-22 11:26:15,816 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:26:15,817 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:26:15,817 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/tripleo-image-elements master 90993,6>\n2014-05-22 11:26:15,818 WARNING zuul.Scheduler: Project openstack/tripleo-image-elements not found\n2014-05-22 11:26:15,818 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:04,004 INFO zuul.Gerrit: Updating information for 90192,3\n2014-05-22 11:27:05,155 DEBUG zuul.Gerrit: Change <Change 0x1fabcd0 90192,3> status: NEW\n2014-05-22 11:27:05,155 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90192,3 Verified:1>\n2014-05-22 11:27:05,156 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90192,3 Verified:1>\n2014-05-22 11:27:05,156 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:05,157 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:05,158 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90192,3 Verified:1>\n2014-05-22 11:27:05,158 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:27:05,159 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:18,073 INFO zuul.Gerrit: Updating information for 94515,2\n2014-05-22 11:27:19,553 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a3fd0 94515,2> status: SUBMITTED\n2014-05-22 11:27:19,554 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/openstack-manuals master 94515,2 Verified:2>\n2014-05-22 11:27:19,555 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/openstack-manuals master 94515,2 Verified:2>\n2014-05-22 11:27:19,555 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:19,556 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:19,557 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/openstack-manuals master 94515,2 Verified:2>\n2014-05-22 11:27:19,557 WARNING zuul.Scheduler: Project openstack/openstack-manuals not found\n2014-05-22 11:27:19,558 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:19,556 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent ref-updated openstack/openstack-manuals>\n2014-05-22 11:27:19,558 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent ref-updated openstack/openstack-manuals>\n2014-05-22 11:27:19,559 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:19,560 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:19,560 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent ref-updated openstack/openstack-manuals>\n2014-05-22 11:27:19,560 WARNING zuul.Scheduler: Project openstack/openstack-manuals not found\n2014-05-22 11:27:19,561 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:19,559 INFO zuul.Gerrit: Updating information for 94515,2\n2014-05-22 11:27:21,378 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a3fd0 94515,2> status: MERGED\n2014-05-22 11:27:21,378 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent change-merged openstack/openstack-manuals master 94515,2>\n2014-05-22 11:27:21,379 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent change-merged openstack/openstack-manuals master 94515,2>\n2014-05-22 11:27:21,380 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:21,380 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:21,381 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent change-merged openstack/openstack-manuals master 94515,2>\n2014-05-22 11:27:21,381 WARNING zuul.Scheduler: Project openstack/openstack-manuals not found\n2014-05-22 11:27:21,381 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:44,514 INFO zuul.Gerrit: Updating information for 94701,5\n2014-05-22 11:27:45,665 DEBUG zuul.Gerrit: Change <Change 0x1fb4d50 94701,5> status: NEW\n2014-05-22 11:27:45,667 INFO zuul.Gerrit: Updating information for 93928,2\n2014-05-22 11:27:47,130 DEBUG zuul.Gerrit: Change <Change 0x7fc9507fbf50 93928,2> status: MERGED\n2014-05-22 11:27:47,131 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent patchset-created stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:47,131 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:47,131 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:47,132 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent patchset-created stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:47,132 WARNING zuul.Scheduler: Project stackforge/stackalytics not found\n2014-05-22 11:27:47,132 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:47,133 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent patchset-created stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:48,383 INFO zuul.Gerrit: Updating information for 94701,5\n2014-05-22 11:27:49,593 DEBUG zuul.Gerrit: Change <Change 0x1fb4d50 94701,5> status: NEW\n2014-05-22 11:27:49,594 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:49,594 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:49,595 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:49,595 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:49,596 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added stackforge/stackalytics master 94701,5>\n2014-05-22 11:27:49,596 WARNING zuul.Scheduler: Project stackforge/stackalytics not found\n2014-05-22 11:27:49,597 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:27:53,663 INFO zuul.Gerrit: Updating information for 90191,3\n2014-05-22 11:27:55,572 DEBUG zuul.Gerrit: Change <Change 0x1fb4e50 90191,3> status: NEW\n2014-05-22 11:27:55,573 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 90191,3 Verified:1>\n2014-05-22 11:27:55,573 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 90191,3 Verified:1>\n2014-05-22 11:27:55,574 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:27:55,574 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:27:55,575 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 90191,3 Verified:1>\n2014-05-22 11:27:55,575 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:27:55,576 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:28:21,521 DEBUG zuul.Gearman: Looking for lost builds\n2014-05-22 11:28:27,737 INFO zuul.Gerrit: Updating information for 94325,5\n2014-05-22 11:28:30,706 DEBUG zuul.Gerrit: Change <Change 0x7fc950678410 94325,5> status: NEW\n2014-05-22 11:28:30,707 INFO zuul.Gerrit: Updating information for 93828,3\n2014-05-22 11:28:36,026 DEBUG zuul.Gerrit: Change <Change 0x7fc95006d3d0 93828,3> status: MERGED\n2014-05-22 11:28:36,026 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/ceilometer master 94325,5>\n2014-05-22 11:28:36,026 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/ceilometer master 94325,5>\n2014-05-22 11:28:36,027 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:28:36,027 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:28:36,027 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/ceilometer master 94325,5>\n2014-05-22 11:28:36,027 WARNING zuul.Scheduler: Project openstack/ceilometer not found\n2014-05-22 11:28:36,028 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:06,260 INFO zuul.Gerrit: Updating information for 94058,12\n2014-05-22 11:29:15,895 DEBUG zuul.Gerrit: Change <Change 0x7fc9502a3e90 94058,12> status: NEW\n2014-05-22 11:29:15,896 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 94058,12 Verified:1>\n2014-05-22 11:29:15,896 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 94058,12 Verified:1>\n2014-05-22 11:29:15,896 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:15,896 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:15,897 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 94058,12 Verified:1>\n2014-05-22 11:29:15,897 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:29:15,897 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:15,897 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:17,095 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:17,096 INFO zuul.Gerrit: Updating information for 91888,1\n2014-05-22 11:29:18,607 DEBUG zuul.Gerrit: Change <Change 0x7fc950880710 91888,1> status: MERGED\n2014-05-22 11:29:18,607 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent patchset-created openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:18,608 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent patchset-created openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:18,608 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:18,609 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:18,610 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent patchset-created openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:18,610 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:18,611 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:18,609 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:20,057 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:20,058 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:20,059 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:20,060 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:20,060 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:20,060 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:20,061 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:20,060 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:20,062 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:21,577 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:21,577 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:21,578 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:21,578 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:21,579 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:21,580 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:21,580 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:21,581 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:21,579 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:23,049 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:23,050 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:-1>\n2014-05-22 11:29:23,051 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:-1>\n2014-05-22 11:29:23,051 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:23,055 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:23,055 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:-1>\n2014-05-22 11:29:23,056 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:23,056 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:23,055 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:24,509 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:24,510 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:1>\n2014-05-22 11:29:24,510 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:1>\n2014-05-22 11:29:24,511 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:24,512 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:24,512 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack-dev/sandbox master 94773,1 Verified:1>\n2014-05-22 11:29:24,513 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:24,514 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:24,511 INFO zuul.Gerrit: Updating information for 94773,1\n2014-05-22 11:29:25,972 DEBUG zuul.Gerrit: Change <Change 0x7fc950678350 94773,1> status: NEW\n2014-05-22 11:29:25,972 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:25,973 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:25,973 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:25,975 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:25,975 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack-dev/sandbox master 94773,1>\n2014-05-22 11:29:25,976 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found\n2014-05-22 11:29:25,977 DEBUG zuul.Scheduler: Run handler sleeping\n2014-05-22 11:29:25,974 INFO zuul.Gerrit: Updating information for 88416,3\n2014-05-22 11:29:27,991 DEBUG zuul.Gerrit: Change <Change 0x7fc950880950 88416,3> status: NEW\n2014-05-22 11:29:27,991 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent comment-added openstack/nova master 88416,3 Code-Review:2>\n2014-05-22 11:29:27,992 DEBUG zuul.Scheduler: Done adding trigger event: <TriggerEvent comment-added openstack/nova master 88416,3 Code-Review:2>\n2014-05-22 11:29:27,992 DEBUG zuul.Scheduler: Run handler awake\n2014-05-22 11:29:27,992 DEBUG zuul.Scheduler: Fetching trigger event\n2014-05-22 11:29:27,992 DEBUG zuul.Scheduler: Processing trigger event <TriggerEvent comment-added openstack/nova master 88416,3 Code-Review:2>\n2014-05-22 11:29:27,993 WARNING zuul.Scheduler: Project openstack/nova not found\n2014-05-22 11:29:27,993 DEBUG zuul.Scheduler: Run handler sleeping\n\n\nthe layout.yaml is as below.\n\n----------------------------------------------- start of layout.yaml file -------------------------------\n\nincludes:\n  - python-file: openstack_functions.py\n\npipelines:\n  - name: check\n    description: Newly uploaded patchsets enter this pipeline to receive an initial +/-1 Verified vote from Jenkins.\n    merge-failure-message: Build unsuccessful.\n    success-message: Build passed :)\n    footer-message: CI Contact: b39208 at freescale.com.\n    footer-message: Leave a comment with \'recheck freescale\' to cause a recheck.\n    failure-message: Build unsuccessful.\n    failuter-message: For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n    manager: IndependentPipelineManager\n    precedence: low\n    trigger:\n      gerrit:\n        - event: patchset-created\n        - event: change-restored\n        - event: comment-added\n          comment_filter: (?i)^\\s*recheck(( (?:bug|lp)[\\s#:]*(\\d+))|( no bug))\\s*$\n        - event: comment-added\n          comment_filter: (?i)^\\s*recheck freescale\\s*$\n    merge:\n      gerrit:\n        verified: 0\n    success:\n      gerrit:\n        verified: 0\n    failure:\n      gerrit:\n        verified:\n\nprojects:\n  - name: openstack-dev/sandbox\n    check:\n      - TEST-SANDBOX\n\n\n----------------------------------------------- end of layout.yaml file -------------------------------\n\nKindly help me resolve the issue.\n\n-\nTrinath\n\n________________________________________\nFrom: corvus at inaugust.com <corvus at inaugust.com> on behalf of James E. Blair <jeblair at openstack.org>\nSent: Wednesday, May 21, 2014 7:28 PM\nTo: Somanchi Trinath-B39208\nCc: openstack-infra\nSubject: Re: [OpenStack-Infra] Zuul unable to parse projects\n\n\"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> writes:\n\n> Hi-\n>\n>\n> With Zuul version, 2.0.0.155, I\'m facing a problem with layout.yaml\n>\n>\n> The projects section is as follows in layout.yaml.\n>\n> projects:\n>   - name: openstack-dev/sandbox\n>     check:\n>       - TEST-SANDBOX\n>\n> but when the gerrit event arrives, zuul log shows the following warning.\n>\n> 2014-05-21 17:31:34,566 WARNING zuul.Scheduler: Project openstack-dev/sandbox not found?\n\nI don\'t see anything wrong with that.  Are you sure that Zuul was\nrestarted after changing the config file?  It only reloads the config\nfile after changes if it\'s told to (either with a signal or by\nrestarting).\n\nIf it still doesn\'t work, would you attach the full layout.yaml as well\nas the debug output from starting it beginning with \"Configured Pipeline\nManager check\".\n\n-Jim\n\n','<87ha4ji678.fsf@meyer.lemoncheese.net>',NULL),('<1400741367-sup-7769@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 23:52:14',-25200,'2014-05-22 06:52:14',NULL,'[openstack-dev] [infra] Gerrit downtime on May 23 for project\n	renames','Excerpts from Tom Fifield\'s message of 2014-05-21 21:39:22 -0700:\n> On 22/05/14 11:06, Kyle Mestery wrote:\n> > On Wed, May 21, 2014 at 5:06 PM, Tom Fifield <tom at openstack.org> wrote:\n> >> On 22/05/14 05:48, James E. Blair wrote:\n> >>>\n> >>> Tom Fifield <tom at openstack.org> writes:\n> >>>\n> >>>> May I ask, will the old names have some kind of redirect to the new\n> >>>> names?\n> >>>\n> >>>\n> >>> Of course you may ask!  And it\'s a great question!  But sadly the answer\n> >>> is \"no\".  Unfortunately, Gerrit\'s support for renaming projects is not\n> >>> very good (which is why we need to take downtime to do it).\n> >>>\n> >>> I\'m personally quite fond of stable URLs.  However, these started as an\n> >>> \"experiment\" so we were bound to get some things wrong (and will\n> >>> probably continue to do so) and it\'s better to try to fix them early.\n> >>\n> >>\n> >> This is a really poor outcome.\n> >>\n> >> Can we delay the migration until we have some time to think about the\n> >> communication strategy?\n> >>\n> >> At the least, I\'d suggest a delay for renaming neutron-specs until until\n> >> after the peak of the Juno blueprint work is done. Say in ~3 weeks time.\n> >>\n> > I tend to agree with James that we should do this early and take the\n> > bullet on renaming now. The process for adding new Neutron specs is\n> > outlined here [1], and this will be updated once the repository is\n> > renamed. In addition, I\'m working on adding/updating some Neutron wiki\n> > pages around the Neutron development process, and the specs repo will\n> > be highlighted there once that\'s done. It would be good to have the\n> > renaming done before then.\n> \n> ... and how would you propose we communicate this to the users we\'ve \n> been asking to do blueprint review specifically during this early \n> period? We can\'t exactly send them an email saying \"sorry, the link we \n> mentioned earlier is now wrong\" :)\n> \n> What would you gain from doing it this week instead of later in the month?\n> \n> We\'re really trying to engage users to help out with the spec review \n> process, but it seems they weren\'t taken into account at all when \n> planning this change. Seems like a bad precedent to set for our first \n> \"experiment\".\n\nYou didn\'t also ask them to subscribe to the users and/or operators\nmailing lists? I would think at least one of those two lists would be\nquite important for users to stay in the loop about the effort.\n\nAny large scale movement will be limited in scale by the scale of its\nmass communication.\n\n\n','<537D7F7A.7020600@openstack.org>',NULL),('<1400757220.24631.2.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 13:13:40',7200,'2014-05-22 11:13:40',NULL,'[openstack-dev] [Ironic] handling drivers that will not be\n third-party tested','On Thu, 2014-05-22 at 09:48 +0100, Lucas Alvares Gomes wrote:\n> On Thu, May 22, 2014 at 1:03 AM, Devananda van der Veen\n> <devananda.vdv at gmail.com> wrote:\n> > I\'d like to bring up the topic of drivers which, for one reason or another,\n> > are probably never going to have third party CI testing.\n> >\n> > Take for example the iBoot driver proposed here:\n> >   https://review.openstack.org/50977\n> >\n> > I would like to encourage this type of driver as it enables individual\n> > contributors, who may be using off-the-shelf or home-built systems, to\n> > benefit from Ironic\'s ability to provision hardware, even if that hardware\n> > does not have IPMI or another enterprise-grade out-of-band management\n> > interface. However, I also don\'t expect the author to provide a full\n> > third-party CI environment, and as such, we should not claim the same level\n> > of test coverage and consistency as we would like to have with drivers in\n> > the gate.\n> \n> +1\nBut we\'ll still expect unit tests that work via mocking their 3rd party\nlibrary (for example), right?\n\n> \n> >\n> > As it is, Ironic already supports out-of-tree drivers. A python module that\n> > registers itself with the appropriate entrypoint will be made available if\n> > the ironic-conductor service is configured to load that driver. For what\n> > it\'s worth, I recall Nova going through a very similar discussion over the\n> > last few cycles...\n> >\n> > So, why not just put the driver in a separate library on github or\n> > stackforge?\n> \n> I would like to have this drivers within the Ironic tree under a\n> separated directory (e.g /drivers/staging/, not exactly same but kinda\n> like what linux has in their tree[1]). The advatanges of having it in\n> the main ironic tree is because it makes it easier to other people\n> access the drivers, easy to detect and fix changes in the Ironic code\n> that would affect the driver, share code with the other drivers, add\n> unittests and provide a common place for development.\nI do agree, that having these drivers in-tree would make major changes\nmuch easier for us (see also above about unit tests).\n\n> \n> We can create some rules for people who are thinking about submitting\n> their driver under the staging directory, it should _not_ be a place\n> where you just throw the code and forget it, we would need to agree\n> that the person submitting the code will also babysit it, we also\n> could use the same process for all the other drivers wich wants to be\n> in the Ironic tree to be accepted which is going through ironic-specs.\n+1\n\n> \n> Thoughts?\n> \n> [1] http://lwn.net/Articles/285599/\n> \n> Cheers,\n> Lucas\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAB1EZBpxqVvbtGsFQJOoZUvdQzQ-ypMNvfveeDZ08d1sj-kCAg@mail.gmail.com>',NULL),('<1400777839.3181.120445945.4EFDA951@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 09:57:19',-25200,'2014-05-22 16:57:19',NULL,'[openstack-dev] [TripleO] Haproxy configuration options','On Thu, May 22, 2014, at 08:51 AM, Miller, Mark M (EB SW Cloud - R&D -\nCorvallis) wrote:\n> \n> HAProxy SSL termination is not a viable option when HAProxy is used to\n> proxy traffic between servers. If HAProxy terminates the SSL it will then\n> proxy the traffic unencrypted to any other server across a network.\n> However, since SSL termination and SSL re-encryption are now features of\n> the current HAProxy development releases, I would vote to add these\n> features in addition to stunnel.\n\nRelevant ML thread from a few months ago:\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-March/031229.html\n\n> \n> Mark \n> ________________________________________\n> From: Dmitriy Shulyak [dshulyak at mirantis.com]\n> Sent: Thursday, May 22, 2014 8:35 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [TripleO] Haproxy configuration options\n> \n> Created spec https://review.openstack.org/#/c/94907/\n> \n> I think it is WIP still, but would be nice to hear some comments/opinions\n> \n> \n> On Thu, May 22, 2014 at 1:59 AM, Robert Collins\n> <robertc at robertcollins.net<mailto:robertc at robertcollins.net>> wrote:\n> On 18 May 2014 08:17, Miller, Mark M (EB SW Cloud - R&D - Corvallis)\n> <mark.m.miller at hp.com<mailto:mark.m.miller at hp.com>> wrote:\n> > We are considering the following connection chain:\n> >\n> >                -> HAProxy   ->   stunnel         ->    OS services bound to 127.0.0.1\n> >                      Virtual IP         server IP               localhost 127.0.0.1\n> >                      secure              SSL terminate     unsecure\n> \n> Interestingly, and separately, HAProxy can do SSL termination now, so\n> we might want to consider just using HAProxy for that.\n\nThis would be a nice next step, but in the long term I can see users\nwanting SSL termination and load balancing separated due to:\nA) Different scaling requirements\nB) Access control to machines with SSL certs\n\n> \n> > In this chain none of the ports need to changed. One of the major issues I have come across is the hard coding of the Keystone ports in the OpenStack service\'s configuration files. With the above connection scheme none of the ports need to change.\n> \n> But we do need to have HAProxy not wildcard bind, as Greg points out,\n> and to make OS services bind to 127.0.0.1 as Jan pointed out.\n> \n> I suspect we need to put this through the specs process (which ops\n> teams are starting to watch) to ensure we get enough input.\n> \n> I\'d love to see:\n>  - SSL by default\n>  - A setup we can document in the ops guide / HA openstack install\n> guide - e.g we don\'t need to be doing it a third different way (or we\n> can update the existing docs if what we converge on is better).\n>  - Only SSL enabled endpoints accessible from outside the machine (so\n> python processes bound to localhost as a security feature).\n\n+1\n\n> \n> Eventually we may need to scale traffic beyond one HAProxy, at which\n> point we\'ll need to bring something altogether more sophisticated in -\n> lets design that when we need it.\n> Sooner than that we\'re likely going to need to scale load beyond one\n> control plane server at which point the HAProxy VIP either needs to be\n> distributed (so active-active load receiving) or we need to go\n> user -> haproxy (VIP) -> SSL endpoint (on any control plane node) ->\n> localhost bound service.\n\nPutting SSL termination behind HAProxy seems odd. Typically your load\nbalancer wants to be able to grok the traffic sent though it which is\nnot possible in this setup. For an environment where sending unencrypted\ntraffic across the internal work is not allowed I agree with Mark\'s\nsuggestion of re-encrypting for internal traffic, but IMO it should\nstill pass through the load balancer unencrypted. Basically:\nUser -> External SSL Terminate -> LB -> SSL encrypt -> control plane\n\nThis is a bit overkill given our current state, but I think for now its\nimportant we terminate external SSL earlier on: See ML thread linked\nabove for reasoning.\n\n> \n> HTH,\n> Rob\n\nThanks,\nGreg\n\n\n','<D6182642CE6D2D4FBFCDF99946E2498843DA3137@G4W3299.americas.hpqcorp.net>',NULL),('<1400778019.7301.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 17:00:20',0,'2014-05-22 17:00:20',NULL,'[openstack-dev] [Neutron] reservation of fixed ip','Hi,\n	I\'m part of a project that aims to manage Reservations on OpenStack.\nMaybe this could be implemented on it. The name of the project is Blazar\n(ex Climate). Currently we have two reservation plugins: one for\nphysical host reservations and other for virtual instances reservation.\nWe are planning to implement some new plugins: volume reservation and\nneutron resource reservation. For the later we are still analyzing which\nresources reserve, but from this email seems that fixed IP should be one\nof them. Of course we already have implemented all the things needed to\nhandle reservations in our core code: reservation life cycle, leases\nstates (under review), notifications (using oslo), pluging mechanism for\nnew resource reservations, DB schema with alembic migrations, REST API\n(with Pecan), etc. And yes, should be easy to try Blazar using our\nDevstack integration.\n	If you need more information about the project please visit our wiki\n[1] or send me an email.\n\nPablo.\n\n[1] https://wiki.openstack.org/wiki/Climate\n\nOn Wed, 2014-05-21 at 23:51 +0100, Salvatore Orlando wrote:\n> In principle there is nothing that should prevent us from implementing\n> an IP reservation mechanism.\n> \n> \n> As with anything, the first thing to check is literature or \"related\n> work\"! If any other IaaS system is implementing such a mechanism, is\n> it exposed through the API somehow?\n> Also this feature is likely to be provided by IPAM systems. If yes,\n> what constructs do they use?\n> I do not have the answers to this questions, but I\'ll try to document\n> myself; if you have them - please post them here.\n> \n> \n> This new feature would probably be baked into neutron\'s IPAM logic.\n> When allocating an IP, first check from within the IP reservation\n> pool, and then if it\'s not found check from standard allocation pools\n> (this has non negligible impact on availability ranges management, but\n> these are implementation details).\n> Aspects to consider, requirement-wise, are:\n> 1) Should reservations also be classified by \"qualification\" of the\n> port? For instance, is it important to specify that an IP should be\n> used for the gateway port rather than for a floating IP port?\n> 2) Are reservations something that an admin could specify on a\n> tenant-basis (hence an admin API extension), or an implicit mechanism\n> that can be tuned using configuration variables (for instance create\n> an IP reservation a for gateway port for a given tenant when a router\n> gateway is set).\n> \n> \n> I apologise if these questions are dumb. I\'m just trying to frame this\n> discussion into something which could then possibly lead to submitting\n> a specification.\n> \n> \n> Salvatore\n> \n> \n> On 21 May 2014 21:37, Collins, Sean <Sean_Collins2 at cable.comcast.com>\n> wrote:\n>         (Edited the subject since a lot of people filter based on the\n>         subject\n>         line)\n>         \n>         I would also be interested in reserved IPs - since we do not\n>         deploy the\n>         layer 3 agent and use the provider networking extension and a\n>         hardware\n>         router.\n>         \n>         On Wed, May 21, 2014 at 03:46:53PM EDT, S?awek Kap?o?ski\n>         wrote:\n>         > Hello,\n>         >\n>         > Ok, I found that now there is probably no such feature to\n>         reserve fixed\n>         > ip for tenant. So I was thinking about add such feature to\n>         neutron. I\n>         > mean that it should have new table with reserved ips in\n>         neutron\n>         > database and neutron will check this table every time when\n>         new port\n>         > will be created (or updated) and IP should be associated\n>         with this\n>         > port. If user has got reserved IP it should be then used for\n>         new port,\n>         > if IP is reserver by other tenant - it shouldn\'t be used.\n>         > What You are thinking about such possibility? Is it possible\n>         to add it\n>         > in some future release of neutron?\n>         >\n>         > --\n>         > Best regards\n>         > S?awek Kap?o?ski\n>         > slawek at kaplonski.pl\n>         >\n>         >\n>         > Dnia Mon, 19 May 2014 20:07:43 +0200\n>         > S?awek Kap?o?ski <slawek at kaplonski.pl> napisa?:\n>         >\n>         > > Hello,\n>         > >\n>         > > I\'m using openstack with neutron and ML2 plugin. Is there\n>         any way to\n>         > > reserve fixed IP from shared external network for one\n>         tenant? I know\n>         > > that there is possibility to create port with IP and later\n>         connect VM\n>         > > to this port. This solution is almost ok for me but\n>         problem is when\n>         > > user delete this instance - then port is also deleted and\n>         it is not\n>         > > reserved still for the same user and tenant. So maybe\n>         there is any\n>         > > solution to reserve it \"permanent\"?\n>         > > I know also about floating IPs but I don\'t use L3 agents\n>         so this is\n>         > > probably not for me :)\n>         > >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         --\n>         Sean M. Collins\n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAGR=i3ib=3uJqmqvqTY_nNp=+dLWRzAomwWSZvy8rp+gzmZDug@mail.gmail.com>',NULL),('<1400778722.34615616@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-05-22 12:12:02',-18000,'2014-05-22 17:12:02',NULL,'[openstack-community] Interop / Cloud Connect Summit New York CFP\n	Extended to tomorrow','\nPlease take advantage of the deadline extension to get your proposals in to speak at this [conference](http://www.interop.com), Oct 1-3.  NYC is home to thousands of enterprises, many of which will attend this event. OpenStack is a sponsor.\n \nYou can submit for the Cloud Connect Summit or Interop. Attendees will be able to go to both conferences with a single pass.\n \nInterop tracks are:\nThe Business of IT\nSDN\nInfrastructure\nApplications\nCollaboration\nMobility\nRisk Management & Security\n[Submit your proposals](http://www.interop.com/newyork/conference/call-for-speakers.php) no later than tomorrow.  Thank you.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140522/e7e36a62/attachment.html>\n\n',NULL,NULL),('<1400797199-sup-3348@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 15:24:05',-25200,'2014-05-22 22:24:05',NULL,'[openstack-dev] [TripleO] CI needs YOU','Ahoy there, TripleO interested parties. In the last few months, we\'ve\ngotten a relatively robust, though not nearly complete, CI system for\nTripleO. It is a bit unorthodox, as we have a strong desire to ensure\nPXE booting works, and that requires us running in our own cloud.\n\nWe have this working, in two regions of TripleO deployed clouds which\nwe manage ourselves. We\'ve had quite a few issues, mostly hardware\nrelated, and some related to the fact that TripleO doesn\'t have HA yet,\nso our CI clouds go down whenever our controllers go down.\n\nAnyway, Derek Higgins, Dan Prince, Robert Collins, and myself, have been\ndoing most of the heavy lifting on this. As a result, CI is not up and\nworking all that often. It needs more operational support.\n\nSo, I would encourage anyone interested in TripleO development to start\nworking with us to maintain these two cloud regions (hopefully more\nregions will come up soon) so that we can keep CI flowing and expand\ncoverage to include even more of TripleO.\n\nThank you!\n\n\n',NULL,NULL),('<1400821829.38290.YahooMailNeo@web192605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-23 13:10:29',28800,'2014-05-23 05:10:29',NULL,'[Openstack] Stacked authentication with AD,LDAP','Hi,\n????I have a query here regarding stacked authentication support with AD,LDAP.\nPlease let me know will this already there or available in juno\n?\nBest Regards,\nSrinduva\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140523/6d3a340c/attachment.html>\n\n',NULL,NULL),('<1400858024.8441.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 15:13:46',0,'2014-05-23 15:13:46',NULL,'[openstack-dev]  [Climate] Today\'s weekly meeting','Hi all,\n	We will have the meeting today?\nPablo.\n\n\n',NULL,NULL),('<1400864483-sup-6066@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 10:01:41',-25200,'2014-05-23 17:01:41',NULL,'[openstack-dev] [TripleO] CI needs YOU','I forgot to include a link explaining our cloud:\n\nhttps://wiki.openstack.org/wiki/TripleO/TripleOCloud\n\nThanks!\n\nExcerpts from Clint Byrum\'s message of 2014-05-22 15:24:05 -0700:\n> Ahoy there, TripleO interested parties. In the last few months, we\'ve\n> gotten a relatively robust, though not nearly complete, CI system for\n> TripleO. It is a bit unorthodox, as we have a strong desire to ensure\n> PXE booting works, and that requires us running in our own cloud.\n> \n> We have this working, in two regions of TripleO deployed clouds which\n> we manage ourselves. We\'ve had quite a few issues, mostly hardware\n> related, and some related to the fact that TripleO doesn\'t have HA yet,\n> so our CI clouds go down whenever our controllers go down.\n> \n> Anyway, Derek Higgins, Dan Prince, Robert Collins, and myself, have been\n> doing most of the heavy lifting on this. As a result, CI is not up and\n> working all that often. It needs more operational support.\n> \n> So, I would encourage anyone interested in TripleO development to start\n> working with us to maintain these two cloud regions (hopefully more\n> regions will come up soon) so that we can keep CI flowing and expand\n> coverage to include even more of TripleO.\n> \n> Thank you!\n\n\n','<1400797199-sup-3348@fewbar.com>',NULL),('<1400864977.6908.24.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 17:09:38',0,'2014-05-23 17:09:38',NULL,'[openstack-dev] Election Stats and Review Discussion','Hi,\n\nI previously spend 7 years involved in a group that drove voter\nengagement in a large organisation that faced similar issues.\n\nWe learnt a few things in that time.\n\n     1. Easy access to information is key.\n             1. Don\'t assume people will read the mailing lists - there\n                is a huge amount of activity, and threads about\n                candidates does get pushed down fairly quickly\n             2. Have a central page with all the candidates, and their\n                manifestos / information\n             3. Facilitate an easy way to initiate a conversation - a\n                \'Q&A\' section where people can ask questions, and have\n                candidate easily reply really drive voter engagements\n     2. Clear timelines really help\n             1. An email at the opening of nominations with what people\n                need to do to be nominated.\n             2. Also have in that email the dates for close of\n                nominations, start of campaigning (if applicable), and\n                date of the vote\n             3. Small things help - a calender invite that reminds\n                voters the day before the vote ends can really drive up\n                votes\n\nOn the campaigning - we found that putting too many restrictions on\ncampaigns can be harmful. Something like what you suggested usually\nworks - as long as it is not too prescriptive.\n\nYou will always have a drop off for \'regional candidates\' (eg TC) vs\n\'local candidates\' (eg PTL), as there is people who will vote for the\nareas close to their heart (i.e. the project / program that they work on\nday to day) - it is an issue all electoral oversight bodies struggle\nwith.\n\nJust my 2c, would love to talk this out more as the discussion\nprogresses.\n\nGraham\n\nOn Fri, 2014-05-23 at 10:45 -0400, Anita Kuno wrote:\n> One of the things that OpenStack does really well is review our process\n> for various activities. I don\'t believe we have had a discussion in the\n> past reviewing our electoral process and I think it would be good to\n> have this discussion.\n> \n> There are two issues that I feel need to be addressed:\n> Item One: the health of our voter engagement for the tc election\n> Item Two: messaging around campaigning\n> others may feel additional issues need some airtime, if you can think of\n> other issues affection our election process for ptl and/or tc elections,\n> do add your item to the list.\n> \n> Item One:\n>     the health of our voter engagement for the tc election\n> \n> Going by voter turnout, the health of individual programs as reflected\n> in the ptl voter turnout statistics is sound (43.5% voter turnout or\n> better) however the health of the voter turnout for the tc election\n> process could tolerate some scrutiny.\n> \n> For the April 2014 tc election the voter turnout was 29.7%. We have had\n> a total of three tc elections in the history of OpenStack and our voter\n> turnout percentage is dropping.\n> First TC Election, March 2013: 33.6% voter turnout\n> Second TC Election, October 2013: 30.9% voter turnout\n> Third TC Election, April 2014: 29.7% voter turnout\n> \n> Now our actual votes cast are increasing, but the size of the electorate\n> is increasing faster, with proportionally fewer ATCs voting\n> March 2013: 208 votes cast, 619 authorized voters\n> October 2013: 342 votes cast, 1106 authorized voters\n> April 2014: 448 votes cast, 1510 authorized voters\n> \n> I would like for there to be a discussion around voter engagement in the\n> tc election.\n> \n> Item Two:\n>     messaging around campaigning\n> \n> Right now we have no messaging around election campaigning and I think\n> we should have some.\n> \n> Specifically I feel we should state that the TC requires candidates and\n> their backers to campaign in the spirit of the OpenStack ideals\n> (Openness, Transparency, Commonality, Integration, Quality...)  as\n> stated in the TC mission statement[footnote] while refraining from\n> sending unsolicited email and also refraining from holding privately\n> sponsored campaign events. Campaigning is expected to be done in the\n> open with public access to links and content available to all.\n> \n> I welcome your participation in this discussion.\n> \n> Thank you,\n> Anita.\n> anteaya\n> \n> [footnote] The  Technical Committee (\"TC\") is tasked with providing the\n> technical  leadership for OpenStack as a whole (all official programs,\n> as defined  below). It enforces OpenStack ideals (Openness,\n> Transparency,  Commonality, Integration, Quality...), decides on issues\n> affecting  multiple programs, forms an ultimate appeals board for\n> technical  decisions, and generally has oversight over all the OpenStack\n> project.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<537F5EF0.9080000@anteaya.info>',NULL),('<1400952296.32582.0.camel@graham-desk-13-10>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-24 17:24:24',0,'2014-05-24 17:24:24',NULL,'[openstack-dev] Designate Incubation Request','\nHi all,\n\nDesignate would like to apply for incubation status in OpenStack.\n\nOur application is here: \nhttps://wiki.openstack.org/wiki/Designate/Incubation_Application \n\nAs part of our application we would like to apply for a new program. Our\napplication for the program is here:\n\nhttps://wiki.openstack.org/wiki/Designate/Program_Application \n\nDesignate is a DNS as a Service project, providing both end users,\ndevelopers, and administrators with an easy to use REST API to manage\ntheir DNS Zones and Records.\n\nThanks,\n\nGraham\n\n\n',NULL,NULL),('<1400952296.32582.0.camel@graham-desk-13-10>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-05-24 17:24:24',0,'2014-05-24 17:24:24',NULL,'[openstack-tc] Designate Incubation Request','\nHi all,\n\nDesignate would like to apply for incubation status in OpenStack.\n\nOur application is here: \nhttps://wiki.openstack.org/wiki/Designate/Incubation_Application \n\nAs part of our application we would like to apply for a new program. Our\napplication for the program is here:\n\nhttps://wiki.openstack.org/wiki/Designate/Program_Application \n\nDesignate is a DNS as a Service project, providing both end users,\ndevelopers, and administrators with an easy to use REST API to manage\ntheir DNS Zones and Records.\n\nThanks,\n\nGraham\n\n\n',NULL,NULL),('<1401080202-sup-2935@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-26 05:20:39',0,'2014-05-26 05:20:39',NULL,'[openstack-dev] [TripleO] Haproxy configuration options','Excerpts from Robert Collins\'s message of 2014-05-25 23:12:26 +0000:\n> On 23 May 2014 04:57, Gregory Haynes <greg at greghaynes.net> wrote:\n> >>\n> >> Eventually we may need to scale traffic beyond one HAProxy, at which\n> >> point we\'ll need to bring something altogether more sophisticated in -\n> >> lets design that when we need it.\n> >> Sooner than that we\'re likely going to need to scale load beyond one\n> >> control plane server at which point the HAProxy VIP either needs to be\n> >> distributed (so active-active load receiving) or we need to go\n> >> user -> haproxy (VIP) -> SSL endpoint (on any control plane node) ->\n> >> localhost bound service.\n> >\n> > Putting SSL termination behind HAProxy seems odd. Typically your load\n> > balancer wants to be able to grok the traffic sent though it which is\n> \n> Not really :). There is a sophistication curve - yes, but generally\n> load balancers don\'t need to understand the traffic *except* when the\n> application servers they are sending to have locality of reference\n> performance benefits from clustered requests. (e.g. all requests from\n> user A on server Z will hit a local cache of user metadata as long as\n> they are within 5 seconds). Other than that, load balancers care about\n> modelling server load to decide where to send traffic).\n> \n> SSL is a particularly interesting thing because you know that all\n> requests from that connection are from one user - its end to end\n> whereas HTTP can be multiplexed by intermediaries. This means that\n> while you don\'t know that \'all user A\'s requests\' are on the one\n> socket, you do know that all requests on that socket are from user A.\n> \n> So for our stock - and thus probably most common - API clients we have\n> the following characteristics:\n>  - single threaded clients\n>  - one socket (rather than N)\n> \n> Combine these with SSL and clearly whatever efficiency we *can* get\n> from locality of reference, we will get just by taking SSL and\n> backending it to one backend. That backend might itself be haproxy\n> managing local load across local processes but there is no reason to\n> expose the protocol earlier.\n\nThis is a good point and I agree that performance-wise there is not an\nissue here.\n\n> \n> > not possible in this setup. For an environment where sending unencrypted\n> > traffic across the internal work is not allowed I agree with Mark\'s\n> > suggestion of re-encrypting for internal traffic, but IMO it should\n> > still pass through the load balancer unencrypted. Basically:\n> > User -> External SSL Terminate -> LB -> SSL encrypt -> control plane\n> \n> I think this is wasted CPU cycles given the characteristics of the\n> APIs we\'re balancing. We have four protocols that need VIP usage AIUI:\n> \n\nOne other, separate issue with letting external SSL pass through to your\nbackends has to do with secutity: Your app servers (or in our case\ncontrol nodes) generally have a larger attack surface and are more\ndistributed than your load balancers (or an SSL endpoint placed infront\nof them). Additionally, compromise of an external-facing SSL cert is far\nworse than an internal-only SSL cert which could be made backend-server\nspecific.\n\nI agree that re-encryption is not useful with our current setup, though:\nIt would occur on a control node which removes the security benefits (I\nstill wanted to make sure this point is made :)).\n\nTL;DR - +1 on the \'User -> haproxy -> ssl endpoint -> app\' design.\n\nThanks,\nGreg\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<CAJ3HoZ0y05d8Q6=N4GLT9P-uYtBovs-2hf9+F0cV5913XXYxuQ@mail.gmail.com>',NULL),('<1401087348.15536.1.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-26 08:55:48',7200,'2014-05-26 06:55:48',NULL,'[openstack-dev] [Ironic] [TripleO] virtual-ironic job now\n voting!','Great news! Even being non-voting, it already helped me 2-3 times to\nspot a subtle error in a patch.\n\nOn Fri, 2014-05-23 at 18:56 -0700, Devananda van der Veen wrote:\n> Just a quick heads up to everyone -- the tempest-dsvm-virtual-ironic\n> job is now fully voting in both check and gate queues for Ironic. It\'s\n> also now symmetrically voting on diskimage-builder, since that tool is\n> responsible for building the deploy ramdisk used by this test.\n> \n> \n> Background: We discussed this prior to the summit, and agreed to\n> continue watching the stability of the job through the summit week.\n> It\'s been reliable for over a month now, and I\'ve seen it catch\n> several real issues, both in Ironic and in other projects, and all the\n> core reviewers I spoke lately have been eager to enable voting on this\n> test. So, it\'s done!\n> \n> \n> Cheers,\n> Devananda\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEpzzgy-s4EjWNLdRtP6OLqsWF7xQQk+K-j-7Uu5C5w-qA@mail.gmail.com>',NULL),('<1401097419249.20195@freescale.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-05-26 09:31:46',0,'2014-05-26 09:31:46',NULL,'[OpenStack-Infra] Zuul-Merger error - Help Required','Hi-\n\n\nWith Zuul-Merger, for certain patches, I get the following error,\n\n\n2014-05-26 14:34:08,987 DEBUG zuul.Merger: Merging for change 84072,7.\n2014-05-26 14:34:08,987 DEBUG zuul.Merger: Processing refspec refs/changes/72/84072/7 for project openstack/neutron / master ref Zb61a061c0055435599c02aa7fc2476ba\n2014-05-26 14:34:08,990 DEBUG zuul.Merger: Unable to find commit for ref master/Zb61a061c0055435599c02aa7fc2476ba\n2014-05-26 14:34:08,990 DEBUG zuul.Merger: No base commit found for (u\'openstack/neutron\', u\'master\')\n2014-05-26 14:34:08,991 DEBUG zuul.Repo: Resetting repository /var/lib/zuul/git/openstack/neutron\n2014-05-26 14:34:08,992 DEBUG zuul.Repo: Updating repository /var/lib/zuul/git/openstack/neutron\n2014-05-26 14:34:53,378 DEBUG zuul.Repo: Checking out 362e0bd0c545e1f27b2d79fe708430161c7aec2e\n2014-05-26 14:36:39,155 DEBUG zuul.Repo: Merging refs/changes/72/84072/7 with args [\'-s\', \'resolve\', \'FETCH_HEAD\']\n2014-05-26 14:36:39,184 DEBUG zuul.Merger: Unable to merge {u\'oldrev\': None, u\'newrev\': None, u\'refspec\': u\'refs/changes/72/84072/7\', u\'merge_mode\': 2, u\'number\': u\'84072\', u\'project\': u\'openstack/neutron\', u\'url\': u\'ssh://freescale-ci at review.openstack.org:29418/openstack/neutron\', u\'branch\': u\'master\', u\'patchset\': u\'7\', u\'ref\': u\'Zb61a061c0055435599c02aa7fc2476ba\'}\nTraceback (most recent call last):\n  File \"/usr/local/lib/python2.7/dist-packages/zuul/merger/merger.py\", line 214, in _mergeChange\n    commit = repo.merge(item[\'refspec\'], \'resolve\')\n  File \"/usr/local/lib/python2.7/dist-packages/zuul/merger/merger.py\", line 118, in merge\n    repo.git.merge(*args)\n  File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 227, in <lambda>\n    return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)\n  File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 456, in _call_process\n    return self.execute(call, **_kwargs)\n  File \"/usr/local/lib/python2.7/dist-packages/git/cmd.py\", line 377, in execute\n    raise GitCommandError(command, status, stderr_value)\nGitCommandError: \'git merge -s resolve FETCH_HEAD\' returned exit status 128:\n*** Please tell me who you are.\n\nRun\n\n  git config --global user.email \"you at example.com\"\n  git config --global user.name \"Your Name\"\n\nto set your account\'s default identity.\nOmit --global to set the identity only in this repository.\n\nfatal: empty ident  <zuul at freescale-openstack-ci.(none)> not allowed\n\n?\nCertain patches go a smooth way.\n\nDo I need to configure Zuul with some other parameters?\n\nWith this error, Zuul reports to gerrit with \"Merge Failed\" error.\n\nKindly help me resolve the issue.\n\n-\nTrinath\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140526/52f1ea52/attachment.html>\n\n',NULL,NULL),('<1401207799465.73006@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 16:23:19',0,'2014-05-27 16:23:19',NULL,'[openstack-dev] [neutron] BPs for Juno-1','Hi Kyle\n\nKindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too for Juno1.\n\nI have been mailing the reviewer to kindly make some to to review the BP spec.\n\nI have code too in place for review along with working CI.\n\nThe Code for review : https://review.openstack.org/#/c/78092/\n\nKindly please do the needful.\n\n--\nTrinath Somanchi.\n\n________________________________________\nFrom: Kyle Mestery <mestery at noironetworks.com>\nSent: Tuesday, May 27, 2014 7:44 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: [openstack-dev] [neutron] BPs for Juno-1\n\nHi Neutron developers:\n\nI\'ve spent some time cleaning up the BPs for Juno-1, and they are\ndocumented at the link below [1]. There are a large number of BPs\ncurrently under review right now in neutron-specs. If we land some of\nthose specs this week, it\'s possible some of these could make it into\nJuno-1, pending review cycles and such. But I just wanted to highlight\nthat I removed a large number of BPs from targeting Juno-1 now which\ndid not have specifications linked to them nor specifications which\nwere actively under review in neutron-specs.\n\nAlso, a gentle reminder that the process for submitting specifications\nto Neutron is documented here [2].\n\nThanks, and please reach out to me if you have any questions!\n\nKyle\n\n[1] https://launchpad.net/neutron/+milestone/juno-1\n[2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<CADEmHi2Vv7TBouXy2MhsUAvdCseXMDwBc9V1hwrN632Z-C+JDQ@mail.gmail.com>',NULL),('<1401209481385.4891@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 16:51:21',0,'2014-05-27 16:51:21',NULL,'[openstack-dev] [neutron] BPs for Juno-1','Hi-\n\nSure!. Will change the topic and update you.\n\nThanks a lot for the reply and review.\n\nYour review helps me a lot to proceed further with code.\n\nThanking you ..\n\n-\nTrinath Somanchi\n________________________________________\nFrom: Edgar Magana Perdomo (eperdomo) <eperdomo at cisco.com>\nSent: Tuesday, May 27, 2014 10:18 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nMy only comment is that the name of the topic should be:\n\nbp/fsl-sdn-os-mech-driver\n\n\nInstead of:\nbp/https\n\n\nI guss we can pass this..\n\nEdgar\n\nOn 5/27/14, 9:23 AM, \"trinath.somanchi at freescale.com\"\n<trinath.somanchi at freescale.com> wrote:\n\n>Hi Kyle\n>\n>Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too\n>for Juno1.\n>\n>I have been mailing the reviewer to kindly make some to to review the BP\n>spec.\n>\n>I have code too in place for review along with working CI.\n>\n>The Code for review : https://review.openstack.org/#/c/78092/\n>\n>Kindly please do the needful.\n>\n>--\n>Trinath Somanchi.\n>\n>________________________________________\n>From: Kyle Mestery <mestery at noironetworks.com>\n>Sent: Tuesday, May 27, 2014 7:44 PM\n>To: OpenStack Development Mailing List (not for usage questions)\n>Subject: [openstack-dev] [neutron] BPs for Juno-1\n>\n>Hi Neutron developers:\n>\n>I\'ve spent some time cleaning up the BPs for Juno-1, and they are\n>documented at the link below [1]. There are a large number of BPs\n>currently under review right now in neutron-specs. If we land some of\n>those specs this week, it\'s possible some of these could make it into\n>Juno-1, pending review cycles and such. But I just wanted to highlight\n>that I removed a large number of BPs from targeting Juno-1 now which\n>did not have specifications linked to them nor specifications which\n>were actively under review in neutron-specs.\n>\n>Also, a gentle reminder that the process for submitting specifications\n>to Neutron is documented here [2].\n>\n>Thanks, and please reach out to me if you have any questions!\n>\n>Kyle\n>\n>[1] https://launchpad.net/neutron/+milestone/juno-1\n>[2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFAA0F9D.153A7%eperdomo@cisco.com>',NULL),('<1401210210542.45271@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 17:03:30',0,'2014-05-27 17:03:30',NULL,'[openstack-dev] [neutron] BPs for Juno-1','Hi-\n\n\nThanks a lot Salvatore.\n\n\nI\'m looking into that issue. I\'m troubleshooting the same.\n\n\nWill update this mail chain when its accessible for review.\n\n\nThanks a lot for the review Salvatore.\n\n\n--\n\nTrinath\n\n\n________________________________\nFrom: Salvatore Orlando <sorlando at nicira.com>\nSent: Tuesday, May 27, 2014 10:29 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nToo late.\n\nI just approved the specification.\nI don\'t think there is any need for reverting the blueprint and just updating the topic in the patch.\n\nPlease have a look at Freescale CI - logs are not accessible at the moment.\n\nSalvatore\n\n\nOn 27 May 2014 18:51, trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>> wrote:\nHi-\n\nSure!. Will change the topic and update you.\n\nThanks a lot for the reply and review.\n\nYour review helps me a lot to proceed further with code.\n\nThanking you ..\n\n-\nTrinath Somanchi\n________________________________________\nFrom: Edgar Magana Perdomo (eperdomo) <eperdomo at cisco.com<mailto:eperdomo at cisco.com>>\nSent: Tuesday, May 27, 2014 10:18 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nMy only comment is that the name of the topic should be:\n\nbp/fsl-sdn-os-mech-driver\n\n\nInstead of:\nbp/https\n\n\nI guss we can pass this..\n\nEdgar\n\nOn 5/27/14, 9:23 AM, \"trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>\"\n<trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>> wrote:\n\n>Hi Kyle\n>\n>Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too\n>for Juno1.\n>\n>I have been mailing the reviewer to kindly make some to to review the BP\n>spec.\n>\n>I have code too in place for review along with working CI.\n>\n>The Code for review : https://review.openstack.org/#/c/78092/\n>\n>Kindly please do the needful.\n>\n>--\n>Trinath Somanchi.\n>\n>________________________________________\n>From: Kyle Mestery <mestery at noironetworks.com<mailto:mestery at noironetworks.com>>\n>Sent: Tuesday, May 27, 2014 7:44 PM\n>To: OpenStack Development Mailing List (not for usage questions)\n>Subject: [openstack-dev] [neutron] BPs for Juno-1\n>\n>Hi Neutron developers:\n>\n>I\'ve spent some time cleaning up the BPs for Juno-1, and they are\n>documented at the link below [1]. There are a large number of BPs\n>currently under review right now in neutron-specs. If we land some of\n>those specs this week, it\'s possible some of these could make it into\n>Juno-1, pending review cycles and such. But I just wanted to highlight\n>that I removed a large number of BPs from targeting Juno-1 now which\n>did not have specifications linked to them nor specifications which\n>were actively under review in neutron-specs.\n>\n>Also, a gentle reminder that the process for submitting specifications\n>to Neutron is documented here [2].\n>\n>Thanks, and please reach out to me if you have any questions!\n>\n>Kyle\n>\n>[1] https://launchpad.net/neutron/+milestone/juno-1\n>[2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/80a8ce35/attachment.html>\n\n','<CAGR=i3iNRwjMj3GneLeEoauEb37yJyxbh1_NPcxz2etimX_JkA@mail.gmail.com>',NULL),('<1401216139493.73984@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 18:42:20',0,'2014-05-27 18:42:20',NULL,'[openstack-dev] [neutron] BPs for Juno-1','\nHi-\n\nSure Anita. I have been attending meeting for ML2 at #openstack-meeting-alt.\n\nWill also, attend the below mentioned meetings ..\n\nThanking you.\n\n-\nTrinaths\n________________________________________\nFrom: Anita Kuno <anteaya at anteaya.info>\nSent: Tuesday, May 27, 2014 10:45 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nOn 05/27/2014 01:03 PM, trinath.somanchi at freescale.com wrote:\n> Hi-\n>\n>\n> Thanks a lot Salvatore.\n>\n>\n> I\'m looking into that issue. I\'m troubleshooting the same.\n>\n>\n> Will update this mail chain when its accessible for review.\n>\n>\n> Thanks a lot for the review Salvatore.\n>\n>\n> --\n>\n> Trinath\nHave you considered starting an irc client, navigating to freenode and\njoining the #openstack-dev and #openstack-neutron channels? It would\nincrease the rate at which you learn how to amend your code to get it\nmerged. It also would help as you troubleshoot your CI system.\n\nGive it some thought,\nAnita.\n>\n>\n> ________________________________\n> From: Salvatore Orlando <sorlando at nicira.com>\n> Sent: Tuesday, May 27, 2014 10:29 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1\n>\n> Too late.\n>\n> I just approved the specification.\n> I don\'t think there is any need for reverting the blueprint and just updating the topic in the patch.\n>\n> Please have a look at Freescale CI - logs are not accessible at the moment.\n>\n> Salvatore\n>\n>\n> On 27 May 2014 18:51, trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com> <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>> wrote:\n> Hi-\n>\n> Sure!. Will change the topic and update you.\n>\n> Thanks a lot for the reply and review.\n>\n> Your review helps me a lot to proceed further with code.\n>\n> Thanking you ..\n>\n> -\n> Trinath Somanchi\n> ________________________________________\n> From: Edgar Magana Perdomo (eperdomo) <eperdomo at cisco.com<mailto:eperdomo at cisco.com>>\n> Sent: Tuesday, May 27, 2014 10:18 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1\n>\n> My only comment is that the name of the topic should be:\n>\n> bp/fsl-sdn-os-mech-driver\n>\n>\n> Instead of:\n> bp/https\n>\n>\n> I guss we can pass this..\n>\n> Edgar\n>\n> On 5/27/14, 9:23 AM, \"trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>\"\n> <trinath.somanchi at freescale.com<mailto:trinath.somanchi at freescale.com>> wrote:\n>\n>> Hi Kyle\n>>\n>> Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too\n>> for Juno1.\n>>\n>> I have been mailing the reviewer to kindly make some to to review the BP\n>> spec.\n>>\n>> I have code too in place for review along with working CI.\n>>\n>> The Code for review : https://review.openstack.org/#/c/78092/\n>>\n>> Kindly please do the needful.\n>>\n>> --\n>> Trinath Somanchi.\n>>\n>> ________________________________________\n>> From: Kyle Mestery <mestery at noironetworks.com<mailto:mestery at noironetworks.com>>\n>> Sent: Tuesday, May 27, 2014 7:44 PM\n>> To: OpenStack Development Mailing List (not for usage questions)\n>> Subject: [openstack-dev] [neutron] BPs for Juno-1\n>>\n>> Hi Neutron developers:\n>>\n>> I\'ve spent some time cleaning up the BPs for Juno-1, and they are\n>> documented at the link below [1]. There are a large number of BPs\n>> currently under review right now in neutron-specs. If we land some of\n>> those specs this week, it\'s possible some of these could make it into\n>> Juno-1, pending review cycles and such. But I just wanted to highlight\n>> that I removed a large number of BPs from targeting Juno-1 now which\n>> did not have specifications linked to them nor specifications which\n>> were actively under review in neutron-specs.\n>>\n>> Also, a gentle reminder that the process for submitting specifications\n>> to Neutron is documented here [2].\n>>\n>> Thanks, and please reach out to me if you have any questions!\n>>\n>> Kyle\n>>\n>> [1] https://launchpad.net/neutron/+milestone/juno-1\n>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5384C827.2070401@anteaya.info>',NULL),('<1401216356686.32747@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 18:45:57',0,'2014-05-27 18:45:57',NULL,'[openstack-dev] [neutron] BPs for Juno-1','Hi Kyle-\n\nThe BP Spec approved.\n\nhttps://review.openstack.org/#/c/88190/\n\nKindly consider my BP spec for Juno-1.\n\nThanking all the code reviewers for their time to review my ML2 MD Spec and making me to improve the spec.\n\n-\nTrinaths\n\n________________________________________\nFrom: Kyle Mestery <mestery at noironetworks.com>\nSent: Tuesday, May 27, 2014 10:46 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nOn Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav <vinayyadhav at gmail.com> wrote:\n> Hi,\n>\n> I have been working on the port mirroring blueprint and i was asked to\n> submit a neutron spec related to this\n> I have drafter the spec and ready to commit it to the\n> \'git://git.openstack.org/openstack/neutron-specs\' repository for\n> review. Since the blueprint for this was old i was asked to submit the spec\n> for review. should i also bring the old blueprint to life\n> by linking it the spec that i will commit.\n>\nYou can file a BP in launchpad. We\'re using those to track progress\nagainst milestones for release management reasons. Please see the\ninstructions here [1]. Once the BP is filed in neutron-specs, reviewed\nand approved, we can track it to milestones. But at this point, this\nwon\'t make it to Juno-1, given that\'s 2 weeks away.\n\nThanks,\nKyle\n\n[1] https://wiki.openstack.org/wiki/Blueprints#Neutron\n\n> We are calling the new spec Tap-as-a-Service\n>\n> Cheers,\n>\n> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*\'\\r\')^89&&main(++i);}\n>\n>\n> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery <mestery at noironetworks.com>\n> wrote:\n>>\n>> Hi Neutron developers:\n>>\n>> I\'ve spent some time cleaning up the BPs for Juno-1, and they are\n>> documented at the link below [1]. There are a large number of BPs\n>> currently under review right now in neutron-specs. If we land some of\n>> those specs this week, it\'s possible some of these could make it into\n>> Juno-1, pending review cycles and such. But I just wanted to highlight\n>> that I removed a large number of BPs from targeting Juno-1 now which\n>> did not have specifications linked to them nor specifications which\n>> were actively under review in neutron-specs.\n>>\n>> Also, a gentle reminder that the process for submitting specifications\n>> to Neutron is documented here [2].\n>>\n>> Thanks, and please reach out to me if you have any questions!\n>>\n>> Kyle\n>>\n>> [1] https://launchpad.net/neutron/+milestone/juno-1\n>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<CADEmHi0hqqY_m4OfTh6EAPzjPc8CELf2yDEx-7xeqSpDo7G2zg@mail.gmail.com>',NULL),('<1401217102075.69720@freescale.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 18:58:22',0,'2014-05-27 18:58:22',NULL,'[openstack-dev] [neutron] BPs for Juno-1','Hi Kyle-\n\nI\'m working the issues with our FTP server which is hosting the CI testing logs.\n\nWill update the status of the Server in this Email chain.\n\n-\nTrinath\n\n\n________________________________________\nFrom: Kyle Mestery <mestery at noironetworks.com>\nSent: Wednesday, May 28, 2014 12:24 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] BPs for Juno-1\n\nI\'ve marked it as Juno-1 for now, but as Salvatore indicated, there\nare some issues with third party testing which need to be addressed\nbefore this can be merged. It would be a good idea to attend the IRC\nmeeting Anita pointed out as well.\n\nThanks,\nKyle\n\nOn Tue, May 27, 2014 at 1:45 PM, trinath.somanchi at freescale.com\n<trinath.somanchi at freescale.com> wrote:\n> Hi Kyle-\n>\n> The BP Spec approved.\n>\n> https://review.openstack.org/#/c/88190/\n>\n> Kindly consider my BP spec for Juno-1.\n>\n> Thanking all the code reviewers for their time to review my ML2 MD Spec and making me to improve the spec.\n>\n> -\n> Trinaths\n>\n> ________________________________________\n> From: Kyle Mestery <mestery at noironetworks.com>\n> Sent: Tuesday, May 27, 2014 10:46 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1\n>\n> On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav <vinayyadhav at gmail.com> wrote:\n>> Hi,\n>>\n>> I have been working on the port mirroring blueprint and i was asked to\n>> submit a neutron spec related to this\n>> I have drafter the spec and ready to commit it to the\n>> \'git://git.openstack.org/openstack/neutron-specs\' repository for\n>> review. Since the blueprint for this was old i was asked to submit the spec\n>> for review. should i also bring the old blueprint to life\n>> by linking it the spec that i will commit.\n>>\n> You can file a BP in launchpad. We\'re using those to track progress\n> against milestones for release management reasons. Please see the\n> instructions here [1]. Once the BP is filed in neutron-specs, reviewed\n> and approved, we can track it to milestones. But at this point, this\n> won\'t make it to Juno-1, given that\'s 2 weeks away.\n>\n> Thanks,\n> Kyle\n>\n> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>\n>> We are calling the new spec Tap-as-a-Service\n>>\n>> Cheers,\n>>\n>> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*\'\\r\')^89&&main(++i);}\n>>\n>>\n>> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery <mestery at noironetworks.com>\n>> wrote:\n>>>\n>>> Hi Neutron developers:\n>>>\n>>> I\'ve spent some time cleaning up the BPs for Juno-1, and they are\n>>> documented at the link below [1]. There are a large number of BPs\n>>> currently under review right now in neutron-specs. If we land some of\n>>> those specs this week, it\'s possible some of these could make it into\n>>> Juno-1, pending review cycles and such. But I just wanted to highlight\n>>> that I removed a large number of BPs from targeting Juno-1 now which\n>>> did not have specifications linked to them nor specifications which\n>>> were actively under review in neutron-specs.\n>>>\n>>> Also, a gentle reminder that the process for submitting specifications\n>>> to Neutron is documented here [2].\n>>>\n>>> Thanks, and please reach out to me if you have any questions!\n>>>\n>>> Kyle\n>>>\n>>> [1] https://launchpad.net/neutron/+milestone/juno-1\n>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi1xwn9rmsZeTtnpAbspjCCecakGtPMZWFKogRSfE1wAKQ@mail.gmail.com>',NULL),('<1401219127.3508.21.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 19:32:07',0,'2014-05-27 19:32:07',NULL,'[openstack-dev] [Neutron][LBaaS] Unanswered questions in object\n model refactor blueprint','Referencing this blueprint:\nhttps://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst\n\nAnyone who has suggestions to possible issues or can answer some of\nthese questions please respond.\n\n\n1. LoadBalancer to Listener relationship M:N vs 1:N\nThe main reason we went with the M:N was so IPv6 could use the same\nlistener as IPv4.  However this can be accomplished by the user just\ncreating a second listener and pool with the same configuration.  This\nwill end up being a bad user experience when the listener and pool\nconfiguration starts getting complex (adding in TLS, health monitors,\nSNI, etc). A good reason to not do the M:N is because the logic on might\nget complex when dealing with status.  I\'d like to get people\'s opinions\non this on whether we should do M:N or just 1:N.  Another option, is to\njust implement 1:N right now and later implement the M:N in another\nblueprint if it is decided that the user experience suffers greatly.\n\nMy opinion: I like the idea of leaving it to another blueprint to\nimplement.  However, we would need to watch out for any major\narchitecture changes in the time itis not implemented that could make\nthis more difficult than what it needs to be.\n\n2. Pool to Health Monitor relationship 1:N vs 1:1\nCurrently, I believe this is 1:N however it was suggested to deprecate\nthis in favor of 1:1 by Susanne and Kyle agreed.  Are there any\nobjections to channging to 1:1?\n\nMy opinion: I\'m for 1:1 as long as there aren\'t any major reasons why\nthere needs to be 1:N.\n\n3. Does the Pool object need a status field now that it is a pure\nlogical object?\n\nMy opinion: I don\'t think it needs the status field.  I think the\nLoadBalancer object may be the only thing that needs a status, other\nthan the pool members for health monitoring.  I might be corrected on\nthis though.\n\n\n','<D115164D7987674C94CA87CD65704AC30DAEA829@ILMB1.corp.radware.com>',NULL),('<1401260552.15165.27.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 08:02:32',3600,'2014-05-28 07:02:32',NULL,'[openstack-dev] [Nova] status of quota class','On Wed, 2014-02-19 at 10:27 -0600, Kevin L. Mitchell wrote:\n> On Wed, 2014-02-19 at 13:47 +0100, Mehdi Abaakouk wrote:\n> > But \'quota_class\' is never set when a nova RequestContext is created.\n> \n> When I created quota classes, I envisioned the authentication component\n> of the WSGI stack setting the quota_class on the RequestContext, but\n> there was no corresponding concept in Keystone.  We need some means of\n> identifying groups of tenants.\n> \n> > So my question, what is the plan to finish the \'quota class\' feature ? \n> \n> I currently have no plan to work on that, and I am not aware of any such\n> work.\n\nJust for reference, we discussed the fact that this code was unused two\nyears ago:\n\n  https://lists.launchpad.net/openstack/msg12200.html\n\nand I see Joe has now completed the process of removing it again:\n\n  https://review.openstack.org/75535\n  https://review.openstack.org/91480\n  https://review.openstack.org/91699\n  https://review.openstack.org/91700\n\nMark.\n\n\n\n','<1392827258.3641.11.camel@einstein.kev>',NULL),('<1401268518.21396.22.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 09:15:20',0,'2014-05-28 09:15:20',NULL,'[openstack-dev] Designate Incubation Request','On Tue, 2014-05-27 at 17:42 -0700, Joe Gordon wrote:\n\n\n> On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham <graham.hayes at hp.com>\n> wrote:\n> \n> * You mention nova\'s dns capabilities as not being adequate one of the\n> incubation requirements is:\n\n>   Project should not inadvertently duplicate functionality present in other\n>   OpenStack projects. If they do, they should have a clear plan and timeframe\n>   to prevent long-term scope duplication\n\n>     So what is the plan for this?\n\nOur current belief is that the DNS functionality in nova sees little to\nno use, with replacement functionality (Designate) incubated, I would\npersonally like to see it deprecated and removed.\n\nAdditionally, as the functionality is driver based, we can likely\nimplement a driver that forwards requests to Designate during the\ndeprecation period.\n\n> * Can you expand on why this doesn\'t make sense in neutron when things\n> like LBaaS do.\n\nLBaaS (and VPNaaS, FWaaS etc) certainly feel like a good fit inside\nNeutron. Their core functionality revolves around \"physically\"\ntransporting or otherwise inspecting bits moving from one place to\nanother and their primary interfaces are Neutron ports, leading to a\ndesire for tight integration.\n\nDesignate, and authoritative DNS in general, is closer to a phone book.\nWe have no involvement in the transportation of bits, and behave much\ncloser to a specialized database than any traditional networking gear.\n\n> * Your application doesn\'t cover all the items raised in the\n> incubation requirements list. For example the QA requirement of\n> Project must have a basic devstack-gate job set up which as far as I\n> can tell isn\'t really there, although there appears to be a devstack\n> based job run as third party which in at least once case didn\'t run on\n> a merged patch (https://review.openstack.org/#/c/91115/)\n> \nThe application is based on the request template, which for better or\nworse doesn\'t map directly to the the governance document :)\n\nIf there are other requirements beyond the devstack-gate one you\nmentioned, please ask and we\'ll respond as best we can!\n\nYou\'re correct that we do not yet have a DevStack gate running directly\nin the CI system, and that we do have a 3rd party Jenkins running\nDevStack with Designate and some basic functional tests against our\nrepositories.\n\nThe 3rd party jobs were originally set up before DevStack supported\nplugins (or at least, before we knew it did!), and were based on a fork\nof DevStack which made using the official CI system difficult.\n\nAfter DevStack gained plugin support, we converted our fork to a plugin,\nand looked into getting the official CI system to run DevStack jobs with\nour DevStack plugin. This again proved difficult, so the status quo was\nleft in place. We\'re looking forward to being able to merge our plugin\ninto DevStack so we can shutdown the 3rd party tests :)\n\nRe the DevStack jobs not running on a merged patch, after the recent\nGerrit updates, the devstack job was failing for period of time due to\nthe change in how gerrit accepts reviews from 3rd party systems. This\nwas fixed recently, and all patches are again running through these\njobs.\n\nPlease keep the questions coming :)\n\nThanks,\nKiall\n\n','<CAHXdxOfUJR3iPEw+YVsFEo0DaF5xKW51CbUHjLVohzD+7o-wrg@mail.gmail.com>',NULL),('<1401282137.5716.6.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 15:02:17',7200,'2014-05-28 13:02:17',NULL,'[openstack-dev] [Ironic] Random thoughts on asynchronous API spec','Hi Ironic folks, hi Devananda!\n\nI\'d like to share with you my thoughts on asynchronous API, which is\nspec https://review.openstack.org/#/c/94923\nFirst I was planned this as comments to the review, but it proved to be\nmuch larger, so I post it for discussion on ML.\n\nHere is list of different consideration, I\'d like to take into account\nwhen prototyping async support, some are reflected in spec already, some\nare from my and other\'s comments:\n\n1. \"Executability\"\nWe need to make sure that request can be theoretically executed,\nwhich includes:\na) Validating request body\nb) For each of entities (e.g. nodes) touched, check that they are\navailable\n   at the moment (at least exist).\n   This is arguable, as checking for entity existence requires going to\nDB.\n\n2. Appropriate state\nFor each entity in question, ensure that it\'s either in a proper state\nor\nmoving to a proper state.\nIt would help avoid users e.g. setting deploy twice on the same node\nIt will still require some kind of NodeInAWrongStateError, but we won\'t\nnecessary need a client retry on this one.\n\nAllowing the entity to be _moving_ to appropriate state gives us a\nproblem:\nImagine OP1 was running and OP2 got scheduled, hoping that OP1 will come\nto desired state. What if OP1 fails? What if conductor, doing OP1\ncrashes?\nThat\'s why we may want to approve only operations on entities that do\nnot\nundergo state changes. What do you think?\n\nSimilar problem with checking node state.\nImagine we schedule OP2 while we had OP1 - regular checking node state.\nOP1 discovers that node is actually absent and puts it to maintenance\nstate.\nWhat to do with OP2?\na) Obvious answer is to fail it\nb) Can we make client wait for the results of periodic check?\n   That is, wait for OP1 _before scheduling_ OP2?\n\nAnyway, this point requires some state framework, that knows about\nstates,\ntransitions, actions and their compatibility with each other.\n\n3. Status feedback\nPeople would like to know, how things are going with their task.\nWhat they know is that their request was scheduled. Options:\na) Poll: return some REQUEST_ID and expect users to poll some endpoint.\n   Pros:\n   - Should be easy to implement\n   Cons:\n   - Requires persistent storage for tasks. Does AMQP allow to do this\nkinds\n     of queries? If not, we\'ll need to duplicate tasks in DB.\n   - Increased load on API instances and DB\nb) Callback: take endpoint, call it once task is done/fails.\n   Pros:\n   - Less load on both client and server\n   - Answer exactly when it\'s ready\n   Cons:\n   - Will not work for cli and similar\n   - If conductor crashes, there will be no callback.\n\nSeems like we\'d want both (a) and (b) to comply with current needs.\n\nIf we have a state framework from (2), we can also add notifications to\nit.\n\n4. Debugging consideration\na) This is an open question: how to debug, if we have a lot of requests\n   and something went wrong?\nb) One more thing to consider: how to make command like `node-show`\naware of\n   scheduled transitioning, so that people don\'t try operations that are\n   doomed to failure.\n\n5. Performance considerations\na) With async approach, users will be able to schedule nearly unlimited\n   number of tasks, thus essentially blocking work of Ironic, without\nany\n   signs of the problem (at least for some time).\n   I think there are 2 common answers to this problem:\n   - Request throttling: disallow user to make too many requests in some\n     amount of time. Send them 503 with Retry-After header set.\n   - Queue management: watch queue length, deny new requests if it\'s too\nlarge.\n   This means actually getting back error 503 and will require retrying\nagain!\n   At least it will be exceptional case, and won\'t affect Tempest run...\nb) State framework from (2), if invented, can become a bottleneck as\nwell.\n   Especially with polling approach.\n\n6. Usability considerations\na) People will be unaware, when and whether their request is going to be\n   finished. As there will be tempted to retry, we may get flooded by\n   duplicates. I would suggest at least make it possible to request\ncanceling\n   any task (which will be possible only if it is not started yet,\nobviously).\nb) We should try to avoid scheduling contradictive requests.\nc) Can we somehow detect duplicated requests and ignore them?\n   E.g. we won\'t want user to make 2-3-4 reboots in a row just because\nthe user\n   was not patient enough.\n\n------\n\nPossible takeaways from this letter:\n- We\'ll need at least throttling to avoid DoS\n- We\'ll still need handling of 503 error, though it should not happen\nunder\n  normal conditions\n- Think about state framework that unifies all this complex logic with\nfeatures:\n  * Track entities, their states and actions on entities\n  * Check whether new action is compatible with states of entities it\ntouches\n    and with other ongoing and scheduled actions on these entities.\n  * Handle notifications for finished and failed actions by providing\nboth\n    pull and push approaches.\n  * Track whether started action is still executed, perform error\nnotification,\n    if not.\n  * HA and high performance\n- Think about policies for corner cases\n- Think, how we can make a user aware of what is going on with both\nrequest\n  and entity that some requests may touch. Also consider canceling\nrequests.\n\nPlease let me know, what you think.\n\nDmitry.\n\n\n\n',NULL,NULL),('<1401300658.5980.11.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 18:10:58',0,'2014-05-28 18:10:58',NULL,'[openstack-dev] [Neutron][LBaaS] Unanswered questions in object\n model refactor blueprint','Hi Stephen\n\nOn Tue, 2014-05-27 at 19:42 -0700, Stephen Balukoff wrote:\n> Hi y\'all!\n> \n> \n> On Tue, May 27, 2014 at 12:32 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Referencing this blueprint:\n>         https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst\n>         \n>         Anyone who has suggestions to possible issues or can answer\n>         some of\n>         these questions please respond.\n>         \n>         \n>         1. LoadBalancer to Listener relationship M:N vs 1:N\n>         The main reason we went with the M:N was so IPv6 could use the\n>         same\n>         listener as IPv4.  However this can be accomplished by the\n>         user just\n>         creating a second listener and pool with the same\n>         configuration.  This\n>         will end up being a bad user experience when the listener and\n>         pool\n>         configuration starts getting complex (adding in TLS, health\n>         monitors,\n>         SNI, etc). A good reason to not do the M:N is because the\n>         logic on might\n>         get complex when dealing with status.  I\'d like to get\n>         people\'s opinions\n>         on this on whether we should do M:N or just 1:N.  Another\n>         option, is to\n>         just implement 1:N right now and later implement the M:N in\n>         another\n>         blueprint if it is decided that the user experience suffers\n>         greatly.\n>         \n>         My opinion: I like the idea of leaving it to another blueprint\n>         to\n>         implement.  However, we would need to watch out for any major\n>         architecture changes in the time itis not implemented that\n>         could make\n>         this more difficult than what it needs to be.\n> \n> \n> Is there such a thing as a \'possibly planned but not implemented\n> design\' to serve as a placeholder when considering other in-parallel\n> blueprints and designs which could potentially conflict with the\n> ability to implement an anticipated design like this?  (I\'m guessing\n> \"no.\" I really wish we had a better design tracking tool than\n> blueprint.)\nI know I have seen blueprints that are much like a container for many\nother blueprints that are all intended to solve the container\'s goal.\nIt\'s much like an epic in scrum.  I wonder if we should make something\nlike that for the object model refactor since it is now in 2 blueprints\nand possibly more with this.\n> \n> \n> Anyway, I don\'t have a problem with implementing 1:N right now. But, I\n> do want to point out: The one and only common case I\'ve seen where\n> listener re-use actually makes a lot of sense (IPv4 and IPv6 for same\n> listener) could be alleviated by adding separate ipv4 and ipv6\n> attributes to the loadbalancer object. I believe this was shot down\n> when people were still calling it a VIP for philosophical reasons. Are\n> people more open to this idea now that we\'re calling the object a\n> \'load balancer\'?  ;)\n> \n\nI\'m not sure about this. It can lead down a rabbit hole of being able to\nadd multiple IPv4 and/or IPv6 addresses on the same LB.  Which is kind\nof weird to me that we woudln\'t allow that, not a big deal though.  What\nI am strongly opposed to, though, is if we do intend on implementing N:M\nthen it would probably make sense to deprecate the IPv6 address since\nthat can now be solved by sharing listeners.  Implementing something\njust to deprecate it I\'m not a big fan of, but sometimes it can be\nnecessary.  In this case I\'d rather just say we are only ever going to\ndo 1:N and add the IPv6 address attribute to the load balancer, or we\nare definitely going to do the N:M and not add it at all.\n\n> Does anyone have any other use cases where listener re-use makes\n> sense?\n\nIt really only ever makes sense, even with IPv4 and IPv6, as a mechanism\nto prevent a user from having to duplicate their listener and pools\nconfiguration.  If two load balancers are sharing a listener, its really\nup to the driver/backend on where the load balancers and vips are\nlocated.\n\n>  \n>         \n>         2. Pool to Health Monitor relationship 1:N vs 1:1\n>         Currently, I believe this is 1:N however it was suggested to\n>         deprecate\n>         this in favor of 1:1 by Susanne and Kyle agreed.  Are there\n>         any\n>         objections to channging to 1:1?\n>         \n>         My opinion: I\'m for 1:1 as long as there aren\'t any major\n>         reasons why\n>         there needs to be 1:N.\n>         \n> \n> \n> Yep, totally on-board with 1:1 for pool and health monitor.\n>  \n>         3. Does the Pool object need a status field now that it is a\n>         pure\n>         logical object?\n>         \n>         My opinion: I don\'t think it needs the status field.  I think\n>         the\n>         LoadBalancer object may be the only thing that needs a status,\n>         other\n>         than the pool members for health monitoring.  I might be\n>         corrected on\n>         this though.\n> \n> \n> So, I think it does make sense when using L7 rules. And it\'s\n> specifically like this:\n> \n> \n> A pool is \'UP\' if at least one non-backup member is \'UP\' and \'DOWN\'\n> otherwise. This can be an important monitoring point if, for example,\n> operations wants to be informed if the \'api pool\' is down while the\n> \'web frontend\' pool is still up, in some meaningful way (ie. other\n> than having to sort through a potential barrage of member down\n> notifications to see wether any members of a given pool are still up.)\n> Also, given that member status might be more than just \'UP\' and\n> \'DOWN\' (eg. \"PROVISIONING\" or \"DRAINING\" might also be valid status\n> types for certain kinds of back-ends.) It\'s harder for an operator to\n> know whether a given pool is \'UP\' or \'DOWN\' without some kind of\n> indication.\n> \n> \n> Also note that the larger the pool, the less meaningful individual\n> members\' statuses are: If you\'ve got 1000 servers in a pool, it\'s\n> probably OK if 3-4 of them are \'down\' at any given time.\n> \n> \n> Having said this, if someone asks for the status of a pool, I\'d be OK\n> if the response was simply an array of statuses of each member in the\n> pool, plus one \'summary\' status (ie. as described above) and it\'s left\n> to the user to do with that data whatever makes sense for their\n> application. This would allow one to see, for example, that a pool\n> with no members is by definition \'DOWN\'.\n> \n\nThis would be a good feature to add later for sure.  Until that feature\nis actually enabled then would it make sense for pool to not have a\nstatus field?  Then again, that\'d be deprecating something to only add\nit back in later.\n\n> \n> Are we going to allow a pool to be set administratively down? (ex. for\n> maintenance on one pool of servers powering a listener, while other\n> pools remain online and available.) In this case, having a response\n> that says the pool is \'ADMIN_DOWN\' probably also makes sense.\n>  \n> Doug:  What do you think of the idea of having both IPv4 and IPv6\n> attributes on a \'load balancer\' object? One doesn\'t need to have a\n> single appliance serving both types of addresses for the listener, but\n> there\'s certainly a chance (albeit small) to hit an async scenario if\n> they\'re not.\n> \n> \n> Vijay:  I think the plan here was to come up with an use an entirely\n> different DB schema than the legacy Neutron LBaaS, and then retro-fit\n> backward compatibility with the old user API once the new LBaaS\n> service is functional. I don\'t think anyone here is suggesting we try\n> to make the old schema work for the new API.\n> \n\nThanks,\nBrandon Logan\n\n\n\n','<CAAGw+Zp2a6V+8Y90asHKm21R0qyE+0JeHeUQ7S8qrLQNiezFNw@mail.gmail.com>',NULL),('<1401301325.5716.9.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 20:22:05',7200,'2014-05-28 18:22:05',NULL,'[openstack-dev] [Ironic] Random thoughts on asynchronous API\n spec','On Wed, 2014-05-28 at 11:08 -0700, Devananda van der Veen wrote:\n> While I appreciate the many ideas being discussed here (some of which\n> we\'ve explored previously and agreed to continue exploring), there is\n> a fundamental difference vs. what I propose in that spec. I believe\n> that what I\'m proposing will be achievable without any significant\n> visible changes in the API -- no new API end points or resources, and\n> the client interaction will be nearly the same.\nI am just afraid we\'ll start to get complains like \"I ran a request and\nit disappeared to nowhere, what should I do?\" Are we ready to handle\nthis kinds of things (happened because of queue overloaded, user too\nimpatient, some validation failed etc)? I may be misunderstanding, but\nit looks to me like we\'ll simply drop requests we can\'t fulfill. That\nmay be frustrating for a user.\n\n>  A few status codes may be different in certain circumstances -- but\n> it will not require a new major version of the REST API. And it solves\n> a scalability and stability problem that folks are encountering today.\n> (It seems my spec didn\'t describe those problems well enough -- I\'m\n> updating it now.)\nWould be great!\n\n> \n> \n> Cheers,\n> Devananda\n> \n> \n> \n> \n> On Wed, May 28, 2014 at 10:14 AM, Maksym Lobur <mlobur at mirantis.com>\n> wrote:\n>         BTW a very similar discussion is going in Neutron community\n>         right now, please find a thread under the [openstack-dev]\n>         [Neutron] Introducing task oriented workflows label.\n>         \n>         Best regards,\n>         Max Lobur,\n>         Python Developer, Mirantis, Inc.\n>         \n>         \n>         Mobile: +38 (093) 665 14 28\n>         Skype: max_lobur\n>         \n>         \n>         38, Lenina ave. Kharkov, Ukraine\n>         www.mirantis.com\n>         www.mirantis.ru\n>         \n>         \n>         \n>         On Wed, May 28, 2014 at 6:56 PM, Maksym Lobur\n>         <mlobur at mirantis.com> wrote:\n>                 Hi All,\n>                 \n>                 \n>                 You\'ve raised a good discussion, something similar\n>                 already was started back in february. Could someone\n>                 please find the long etherpad with discussion between\n>                 Deva and Lifeless, as I recall most of the points\n>                 mentioned above have a good comments there.\n>                 \n>                 \n>                 Up to this point I have the only idea how to elegantly\n>                 address these problems. This is a tasks concept and\n>                 probably a scheduler service, which not necessarily\n>                 should be separate from the API at the moment (Finally\n>                 we already have a hash ring on the api side which is a\n>                 kind of scheduler right?) It was already proposed\n>                 earlier, but I would like to try to fit all these\n>                 issues into this concept.\n>                  \n>                         1. \"Executability\"\n>                         We need to make sure that request can be\n>                         theoretically executed,\n>                         which includes:\n>                         a) Validating request body\n>                  \n>                 We cannot validate everything on the API side, relying\n>                 on the fact that DB state is actual is not a good\n>                 idea, especially under heavy load. \n>                 \n>                 \n>                 In tasks concept we could assume that all the requests\n>                 are executable, and do not perform any validation in\n>                 the API thread at all. Instead of this the API will\n>                 just create a task and return it\'s ID to the user.\n>                 Task scheduler may perform some minor validations\n>                 before the task is queued or started for convenience,\n>                 but they should be duplicated inside task body because\n>                 there is an arbitrary time between queuing up and\n>                 start ((c)lifeless). I assume the scheduler will have\n>                 it\'s own thread or even process. The user will need to\n>                 poke received ID to know the current state of his\n>                 submission.\n>                  \n>                         b) For each of entities (e.g. nodes) touched,\n>                         check that they are\n>                         available\n>                            at the moment (at least exist).\n>                            This is arguable, as checking for entity\n>                         existence requires going to\n>                         DB.\n>                  \n>                 Same here, DB round trip is a potential block,\n>                 therefore this will be done inside task (after it\'s\n>                 queued and started) and will not affect the API. The\n>                 user will just observe the task state by poking the\n>                 API (or using callback as an option).\n>                 \n>                 \n>                         2. Appropriate state\n>                         For each entity in question, ensure that it\'s\n>                         either in a proper state\n>                         or\n>                         moving to a proper state.\n>                         It would help avoid users e.g. setting deploy\n>                         twice on the same node\n>                         It will still require some kind of\n>                         NodeInAWrongStateError, but we won\'t\n>                         necessary need a client retry on this one.\n>                         Allowing the entity to be _moving_ to\n>                         appropriate state gives us a\n>                         problem:\n>                         Imagine OP1 was running and OP2 got scheduled,\n>                         hoping that OP1 will come\n>                         to desired state. What if OP1 fails? What if\n>                         conductor, doing OP1\n>                         crashes?\n>                  \n>                 Let\'s say OP1 and OP2 are two separate tasks. Each one\n>                 have the initial state validation inside it\'s body.\n>                 Once OP2 gets its turn it will perform validation and\n>                 fail, which looks reasonable to me.\n>                  \n>                         Similar problem with checking node state.\n>                         Imagine we schedule OP2 while we had OP1 -\n>                         regular checking node state.\n>                         OP1 discovers that node is actually absent and\n>                         puts it to maintenance\n>                         state.\n>                         What to do with OP2?\n>                  \n>                 The task will fail once it get it\'s turn.\n>                  \n>                         b) Can we make client wait for the results of\n>                         periodic check?\n>                            That is, wait for OP1 _before scheduling_\n>                         OP2?\n>                 \n>                 \n>                 We will just schedule the task and the user will\n>                 observe its progress, once OP1 is finished and OP2\n>                 started - he will see a fail.\n>                  \n>                         3. Status feedback\n>                         People would like to know, how things are\n>                         going with their task.\n>                         What they know is that their request was\n>                         scheduled. Options:\n>                         a) Poll: return some REQUEST_ID and expect\n>                         users to poll some endpoint.\n>                            Pros:\n>                            - Should be easy to implement\n>                            Cons:\n>                            - Requires persistent storage for tasks.\n>                         Does AMQP allow to do this\n>                         kinds\n>                              of queries? If not, we\'ll need to\n>                         duplicate tasks in DB.\n>                            - Increased load on API instances and DB\n>                  \n>                 Exactly described the tasks concept :)\n>                  \n>                         b) Callback: take endpoint, call it once task\n>                         is done/fails.\n>                            Pros:\n>                            - Less load on both client and server\n>                            - Answer exactly when it\'s ready\n>                            Cons:\n>                            - Will not work for cli and similar\n>                            - If conductor crashes, there will be no\n>                         callback.\n>                 \n>                 \n>                 Add to Cons:\n>                 - Callback is not reliable since it may get lost. \n>                 We should have an ability to poke anyway, though I see\n>                 a great benefit from implementing a callbacks - to\n>                 decrease API load.\n>                  \n>                         4. Debugging consideration\n>                         a) This is an open question: how to debug, if\n>                         we have a lot of requests\n>                            and something went wrong?\n>                 \n>                 \n>                 We will be able to see the queue state (btw what about\n>                 security here, should the user be able to see all the\n>                 tasks, or just his ones, or all but others with hidden\n>                 details).\n>                  \n>                         b) One more thing to consider: how to make\n>                         command like `node-show`\n>                         aware of\n>                            scheduled transitioning, so that people\n>                         don\'t try operations that are\n>                            doomed to failure.\n>                 \n>                 \n>                 node-show will always show current state of the node,\n>                 though we may check if there are any tasks queued or\n>                 going, which will change the state. If any - add a\n>                 notification to the response.\n>                  \n>                         5. Performance considerations\n>                         a) With async approach, users will be able to\n>                         schedule nearly unlimited\n>                            number of tasks, thus essentially blocking\n>                         work of Ironic, without\n>                         any\n>                            signs of the problem (at least for some\n>                         time).\n>                            I think there are 2 common answers to this\n>                         problem:\n>                            - Request throttling: disallow user to make\n>                         too many requests in some\n>                              amount of time. Send them 503 with\n>                         Retry-After header set.\n>                 \n>                 \n>                 Can this be achieved by some web-server settings?\n>                 Looks like a typical problem.\n>                  \n>                            - Queue management: watch queue length,\n>                         deny new requests if it\'s too\n>                         large.\n>                 \n>                 \n>                 Yes, I really like the limited queue size idea. Please\n>                 see my comments in the spec.\n>                 Also, if we have a tasks and the queue, we could merge\n>                 similar tasks\n>                 \n>                  \n>                         b) State framework from (2), if invented, can\n>                         become a bottleneck as\n>                         well.\n>                            Especially with polling approach.\n>                 \n>                 \n>                 True. \n>                 If we have tasks, all the node actions will be done\n>                 through them. We can synchronise node state with DB\n>                 only during the task, and remove periodic syncs.\n>                 Off-course someone may go and turn off the node, in\n>                 this case the Ironic will lie about the node state\n>                 until some task is executed on this node, which may be\n>                 suitable behaviour. Otherwise rare periodic syncs may\n>                 work as well.\n>                  \n>                         6. Usability considerations\n>                         a) People will be unaware, when and whether\n>                         their request is going to be\n>                            finished. As there will be tempted to\n>                         retry, we may get flooded by\n>                            duplicates. I would suggest at least make\n>                         it possible to request\n>                         canceling\n>                            any task (which will be possible only if it\n>                         is not started yet,\n>                         obviously).\n>                 \n>                 \n>                 Since we will have a limited number of kinds of tasks,\n>                 we could calculate some estimates basing on previous\n>                 similar tasks. Looks like an improvement for a distant\n>                 future. In the end I wouldn\'t want Ironic to perform\n>                 estimates like windows\'s copy-paste dialog :)\n>                 \n>                 \n>                 Tasks may be easily interrupted while they are in a\n>                 queue. But if it\'s already started - there\'s a\n>                 separate\n>                 dicsussion https://blueprints.launchpad.net/ironic/+spec/make-tasks-interruptible (I\'m going to port this bp to the specs repo in some time)\n>                  \n>                         b) We should try to avoid scheduling\n>                         contradictive requests.\n>                 \n>                 \n>                 A task scheduler responsibility: this is basically a\n>                 state check before task is scheduled, and it should be\n>                 done one more time once the task is started, as\n>                 mentioned above.\n>                  \n>                         c) Can we somehow detect duplicated requests\n>                         and ignore them?\n>                            E.g. we won\'t want user to make 2-3-4\n>                         reboots in a row just because\n>                         the user\n>                            was not patient enough.\n>                 \n>                 \n>                 Queue similar tasks. All the users will be pointed to\n>                 the similar task resource, or maybe to a different\n>                 resources which tied to the same conductor action. \n>                  \n>                         Best regards,\n>                         Max Lobur,\n>                         Python Developer, Mirantis, Inc.\n>                         Mobile: +38 (093) 665 14 28\n>                         Skype: max_lobur\n>                         38, Lenina ave. Kharkov, Ukraine\n>                         www.mirantis.com\n>                         www.mirantis.ru\n>                         \n>                         \n>                         On Wed, May 28, 2014 at 5:10 PM, Lucas Alvares\n>                         Gomes <lucasagomes at gmail.com> wrote:\n>                         On Wed, May 28, 2014 at 2:02 PM, Dmitry\n>                         Tantsur <dtantsur at redhat.com> wrote:\n>                         > Hi Ironic folks, hi Devananda!\n>                         >\n>                         > I\'d like to share with you my thoughts on\n>                         asynchronous API, which is\n>                         > spec https://review.openstack.org/#/c/94923\n>                         > First I was planned this as comments to the\n>                         review, but it proved to be\n>                         > much larger, so I post it for discussion on\n>                         ML.\n>                         >\n>                         > Here is list of different consideration, I\'d\n>                         like to take into account\n>                         > when prototyping async support, some are\n>                         reflected in spec already, some\n>                         > are from my and other\'s comments:\n>                         >\n>                         > 1. \"Executability\"\n>                         > We need to make sure that request can be\n>                         theoretically executed,\n>                         > which includes:\n>                         > a) Validating request body\n>                         > b) For each of entities (e.g. nodes)\n>                         touched, check that they are\n>                         > available\n>                         >    at the moment (at least exist).\n>                         >    This is arguable, as checking for entity\n>                         existence requires going to\n>                         > DB.\n>                         \n>                         >\n>                         \n>                         > 2. Appropriate state\n>                         > For each entity in question, ensure that\n>                         it\'s either in a proper state\n>                         > or\n>                         > moving to a proper state.\n>                         > It would help avoid users e.g. setting\n>                         deploy twice on the same node\n>                         > It will still require some kind of\n>                         NodeInAWrongStateError, but we won\'t\n>                         > necessary need a client retry on this one.\n>                         >\n>                         > Allowing the entity to be _moving_ to\n>                         appropriate state gives us a\n>                         > problem:\n>                         > Imagine OP1 was running and OP2 got\n>                         scheduled, hoping that OP1 will come\n>                         > to desired state. What if OP1 fails? What if\n>                         conductor, doing OP1\n>                         > crashes?\n>                         > That\'s why we may want to approve only\n>                         operations on entities that do\n>                         > not\n>                         > undergo state changes. What do you think?\n>                         >\n>                         > Similar problem with checking node state.\n>                         > Imagine we schedule OP2 while we had OP1 -\n>                         regular checking node state.\n>                         > OP1 discovers that node is actually absent\n>                         and puts it to maintenance\n>                         > state.\n>                         > What to do with OP2?\n>                         > a) Obvious answer is to fail it\n>                         > b) Can we make client wait for the results\n>                         of periodic check?\n>                         >    That is, wait for OP1 _before scheduling_\n>                         OP2?\n>                         >\n>                         > Anyway, this point requires some state\n>                         framework, that knows about\n>                         > states,\n>                         > transitions, actions and their compatibility\n>                         with each other.\n>                         For {power, provision} state changes should we\n>                         queue the requests? We\n>                         may want to only accept 1 request to change\n>                         the state per time, if a\n>                         second request comes when there\'s another\n>                         state change mid-operation\n>                         we may just return 409 (Conflict) to indicate\n>                         that a state change is\n>                         already in progress. This is similar of what\n>                         we have today but instead\n>                         of checking the node lock and states on the\n>                         conductor side the API\n>                         service could do it, since it\'s on the DB.\n>                         >\n>                         > 3. Status feedback\n>                         > People would like to know, how things are\n>                         going with their task.\n>                         > What they know is that their request was\n>                         scheduled. Options:\n>                         > a) Poll: return some REQUEST_ID and expect\n>                         users to poll some endpoint.\n>                         >    Pros:\n>                         >    - Should be easy to implement\n>                         >    Cons:\n>                         >    - Requires persistent storage for tasks.\n>                         Does AMQP allow to do this\n>                         > kinds\n>                         >      of queries? If not, we\'ll need to\n>                         duplicate tasks in DB.\n>                         >    - Increased load on API instances and DB\n>                         > b) Callback: take endpoint, call it once\n>                         task is done/fails.\n>                         >    Pros:\n>                         >    - Less load on both client and server\n>                         >    - Answer exactly when it\'s ready\n>                         >    Cons:\n>                         >    - Will not work for cli and similar\n>                         >    - If conductor crashes, there will be no\n>                         callback.\n>                         >\n>                         > Seems like we\'d want both (a) and (b) to\n>                         comply with current needs.\n>                         +1, we could allow pooling by default (like\n>                         checking\n>                         nodes/<uuid>/states to know the current and\n>                         target state of the node)\n>                         but we may also want to include a callback\n>                         parameter that users could\n>                         use to input a URL that the conductor will\n>                         call out as soon as the\n>                         operation is finished. So if the callback URl\n>                         exists, the conductor\n>                         will submit a POST request to that URL with\n>                         some data structure\n>                         identifying the operation and the current\n>                         state.\n>                         >\n>                         > If we have a state framework from (2), we\n>                         can also add notifications to\n>                         > it.\n>                         >\n>                         > 4. Debugging consideration\n>                         > a) This is an open question: how to debug,\n>                         if we have a lot of requests\n>                         >    and something went wrong?\n>                         > b) One more thing to consider: how to make\n>                         command like `node-show`\n>                         > aware of\n>                         >    scheduled transitioning, so that people\n>                         don\'t try operations that are\n>                         >    doomed to failure.\n>                         >\n>                         > 5. Performance considerations\n>                         > a) With async approach, users will be able\n>                         to schedule nearly unlimited\n>                         >    number of tasks, thus essentially\n>                         blocking work of Ironic, without\n>                         > any\n>                         >    signs of the problem (at least for some\n>                         time).\n>                         >    I think there are 2 common answers to\n>                         this problem:\n>                         >    - Request throttling: disallow user to\n>                         make too many requests in some\n>                         >      amount of time. Send them 503 with\n>                         Retry-After header set.\n>                         >    - Queue management: watch queue length,\n>                         deny new requests if it\'s too\n>                         > large.\n>                         >    This means actually getting back error\n>                         503 and will require retrying\n>                         > again!\n>                         >    At least it will be exceptional case, and\n>                         won\'t affect Tempest run...\n>                         > b) State framework from (2), if invented,\n>                         can become a bottleneck as\n>                         > well.\n>                         >    Especially with polling approach.\n>                         >\n>                         > 6. Usability considerations\n>                         > a) People will be unaware, when and whether\n>                         their request is going to be\n>                         >    finished. As there will be tempted to\n>                         retry, we may get flooded by\n>                         >    duplicates. I would suggest at least make\n>                         it possible to request\n>                         > canceling\n>                         >    any task (which will be possible only if\n>                         it is not started yet,\n>                         > obviously).\n>                         > b) We should try to avoid scheduling\n>                         contradictive requests.\n>                         > c) Can we somehow detect duplicated requests\n>                         and ignore them?\n>                         >    E.g. we won\'t want user to make 2-3-4\n>                         reboots in a row just because\n>                         > the user\n>                         >    was not patient enough.\n>                         >\n>                         > ------\n>                         >\n>                         > Possible takeaways from this letter:\n>                         > - We\'ll need at least throttling to avoid\n>                         DoS\n>                         > - We\'ll still need handling of 503 error,\n>                         though it should not happen\n>                         > under\n>                         >   normal conditions\n>                         > - Think about state framework that unifies\n>                         all this complex logic with\n>                         > features:\n>                         >   * Track entities, their states and actions\n>                         on entities\n>                         >   * Check whether new action is compatible\n>                         with states of entities it\n>                         > touches\n>                         >     and with other ongoing and scheduled\n>                         actions on these entities.\n>                         >   * Handle notifications for finished and\n>                         failed actions by providing\n>                         > both\n>                         >     pull and push approaches.\n>                         >   * Track whether started action is still\n>                         executed, perform error\n>                         > notification,\n>                         >     if not.\n>                         >   * HA and high performance\n>                         > - Think about policies for corner cases\n>                         > - Think, how we can make a user aware of\n>                         what is going on with both\n>                         > request\n>                         >   and entity that some requests may touch.\n>                         Also consider canceling\n>                         > requests.\n>                         >\n>                         > Please let me know, what you think.\n>                         >\n>                         > Dmitry.\n>                         >\n>                         >\n>                         >\n>                         _______________________________________________\n>                         > OpenStack-dev mailing list\n>                         > OpenStack-dev at lists.openstack.org\n>                         >\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         + 1\n>                 \n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEp65XopfKE9nt4TQWmScp5MjPFdaW2gCgYMxc=zNiR2aQ@mail.gmail.com>',NULL),('<1401303683.5980.22.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 19:01:23',0,'2014-05-28 19:01:23',NULL,'[openstack-dev] [Neutron][LBaaS] Unanswered questions in object\n model refactor blueprint','Hi Vijay,\n\nOn Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:\n> Hi Brandon,\n> \n> \n> The current reviews of the schema itself are absolutely valid and\n> necessary, and must go on. However, the place of implementation of\n> this schema needs to be clarified. Rather than make any changes\n> whatsoever to the existing neutron db schema for LBaaS, this new db\n> schema outlined needs to be implemented for a separate LBaaS core\n> service.\n> \nAre you suggesting a separate lbaas database from the neutron database?\nIf not, then I could use some clarification. If so, I\'d advocate against\nthat right now because there\'s just too many things that would need to\nbe changed.  Later, when LBaaS becomes its own service then yeah that\nwill need to happen.\n> \n> What we should be providing in neutron is a switch (a global conf)\n> that can be set to instruct neutron to do one of two things:\n> \n> \n> 1. Use the existing neutron LBaaS API, with the backend being the\n> existing neutron LBaaS db schema. This is the status quo.\n> 2. Use the existing neutron LBaaS API, with the backend being the new\n> LBaaS service. This will invoke calls not to neutron\'s current LBaaS\n> code at all, rather, it will call into a new set of proxy \"backend\"\n> code in neutron that will translate the older LBaaS API calls into the\n> newer REST calls serviced by the new LBaaS service, which will write\n> down these details accordingly in its new db schema. As long as the\n> request and response objects to legacy neutron LBaaS calls are\n> preserved as is, there should be no issues. Writing unit tests should\n> also be comparatively more straightforward, and old functional tests\n> can be retained, and newer ones will not clash with legacy code.\n> Legacy code itself will work, having not been touched at all. The\n> blueprint for the db schema that you have referenced\n> (https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst) should be implemented for this new LBaaS service, post reviews.\n> \nI think the point of this blueprint is to get the API and object model\nless confusing for the Neutron LBaaS service plugin.  I think it\'s too\nearly to create an LBaaS service because we have not yet cleaned up the\ntight integration points between Neutron LBaaS and LBaaS.  Creating a\nnew service would require only API interactions between Neutron and this\nLBaaS service, which currently is not possible due to these tight\nintegration points.  \n\n> \n> The third option would be to turn off neutron LBaaS API, and use the\n> new LBaaS core service directly, but for this we can simply disable\n> neutron lbaas, and don\'t need a config parameter in neutron.\n> \n> \n> Implementing this db schema within neutron instead will be not just\n> complicated, but a huge effort that will go waste in future once the\n> new LBaaS service is implemented. Also, migration will unnecessarily\n> retain the same steps needed to go from legacy neutron LBaaS to the\n> new core LBaaS service in this approach (twice, in succession) in case\n> for any reason the version goes from legacy neutron LBaaS -> new\n> neutron LBaaS -> new LBaaS core service.\nI totally agree that this is technical debt, but I believe it is the\nbest option we have right now since LBaaS needs to live in the Neutron\ncode and process because of the tight integration points.  Since this\nobject model refactor has been slated for Juno, and these tight\nintegration points may or may not be cleaned up by Juno, staying within\nNeutron seems to be the best option right now.\n> \n> \n> Going forward, the legacy neutron LBaaS API can be deprecated, and the\n> new API that directly contacts the new LBaaS core service can be used.\n> \n> \n> We have discussed the above architecture previously, but outside of\n> the ML, and a draft of the blueprint for this new LBaaS core service\n> is underway, and is a collation of all the discussions among a large\n> number of LBaaS engineers including yourself during the summit - I\n> will be posting it for review within a couple of days, as planned.\n> \n> \n> \n> \n> Regards,\n> Vijay\n> \n> \n> On Tue, May 27, 2014 at 12:32 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Referencing this blueprint:\n>         https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst\n>         \n>         Anyone who has suggestions to possible issues or can answer\n>         some of\n>         these questions please respond.\n>         \n>         \n>         1. LoadBalancer to Listener relationship M:N vs 1:N\n>         The main reason we went with the M:N was so IPv6 could use the\n>         same\n>         listener as IPv4.  However this can be accomplished by the\n>         user just\n>         creating a second listener and pool with the same\n>         configuration.  This\n>         will end up being a bad user experience when the listener and\n>         pool\n>         configuration starts getting complex (adding in TLS, health\n>         monitors,\n>         SNI, etc). A good reason to not do the M:N is because the\n>         logic on might\n>         get complex when dealing with status.  I\'d like to get\n>         people\'s opinions\n>         on this on whether we should do M:N or just 1:N.  Another\n>         option, is to\n>         just implement 1:N right now and later implement the M:N in\n>         another\n>         blueprint if it is decided that the user experience suffers\n>         greatly.\n>         \n>         My opinion: I like the idea of leaving it to another blueprint\n>         to\n>         implement.  However, we would need to watch out for any major\n>         architecture changes in the time itis not implemented that\n>         could make\n>         this more difficult than what it needs to be.\n>         \n>         2. Pool to Health Monitor relationship 1:N vs 1:1\n>         Currently, I believe this is 1:N however it was suggested to\n>         deprecate\n>         this in favor of 1:1 by Susanne and Kyle agreed.  Are there\n>         any\n>         objections to channging to 1:1?\n>         \n>         My opinion: I\'m for 1:1 as long as there aren\'t any major\n>         reasons why\n>         there needs to be 1:N.\n>         \n>         3. Does the Pool object need a status field now that it is a\n>         pure\n>         logical object?\n>         \n>         My opinion: I don\'t think it needs the status field.  I think\n>         the\n>         LoadBalancer object may be the only thing that needs a status,\n>         other\n>         than the pool members for health monitoring.  I might be\n>         corrected on\n>         this though.\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAOCo3T0QzZdWMbjiRFx1aqRoptfpN6hAC9FE-pS_EMEmOmjjUQ@mail.gmail.com>',NULL),('<1401336097.3354.18.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 04:01:37',0,'2014-05-29 04:01:37',NULL,'[openstack-dev] [Neutron][LBaaS] Unanswered questions in object\n model refactor blueprint','Hi Vijay,\n\nOn Wed, 2014-05-28 at 15:18 -0700, Vijay B wrote:\n> Hi Brandon!\n> \n> \n> Please see inline..\n> \n> \n> \n> \n> \n> \n> On Wed, May 28, 2014 at 12:01 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Hi Vijay,\n>         \n>         On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:\n>         > Hi Brandon,\n>         >\n>         >\n>         > The current reviews of the schema itself are absolutely\n>         valid and\n>         > necessary, and must go on. However, the place of\n>         implementation of\n>         > this schema needs to be clarified. Rather than make any\n>         changes\n>         > whatsoever to the existing neutron db schema for LBaaS, this\n>         new db\n>         > schema outlined needs to be implemented for a separate LBaaS\n>         core\n>         > service.\n>         >\n>         \n>         Are you suggesting a separate lbaas database from the neutron\n>         database?\n>         If not, then I could use some clarification. If so, I\'d\n>         advocate against\n>         that right now because there\'s just too many things that would\n>         need to\n>         be changed.  Later, when LBaaS becomes its own service then\n>         yeah that\n>         will need to happen.\n> \n> \n> v> Ok, so as I understand it, in this scheme, there is no new schema\n> or db, there will be a new set of tables resident in neutron_db schema\n> itself, alongside legacy lbaas tables. Let\'s consider a rough view of\n> the implementation.\n\nYes that is how I understand it as well.\n\n> \n> Layer 1 - We\'ll have a new lbaas v3.0 api in neutron, with the current\n> lbaas service plugin having to support it in addition to the legacy\n> lbaas extensions that it already supports. We\'ll need to put in new\n> code anyway that will process the v3.0 lbaas api no matter what our\n> approach is.\n> Layer 2 - Management code that will take care of updating the db with\n> entities in pending_create, then invoking the right provider driver,\n> choosing/scheduling the plugin drivers or the agent drivers, invoking\n> them, getting the results, and updating the db.\n> Layer 3 - The drivers themselves (either plugin drivers (like the\n> HAProxy namespace driver/Netscaler) or plugin drivers + agent\n> drivers).\n\nThat is the gist of it as I understand it.\n\n> \n> \n> While having the new tables sit alongside the legacy tables is one way\n> to implement the changes, I don\'t see how this approach leads to a\n> lesser amount of changes overall. Layer 2 above will be the major\n> place where changes can be complicated. Also, it will be confusing to\n> have two sets of lbaas tables in the same schema.\n\nI agree, with the goal being LBaaS becoming its own service later, it is\ndefinitely more changes to do it this way.  This way was just the\nprocess agreed on at the Summit because it was less disruptive and\neasier to accomplish with the expectation that LBaaS still will still\nreside in Neutron in Juno.  Some time after Juno is when it was decided\nto be spun out, which is when I suppose we would actually create the\nLBaaS service you\'re talking about.  Those details weren\'t discussed\nthough, so I could just be interpreting it my own way.\n\n> \n> \n> I don\'t want a separate lbaas database under neutron, and neither do I\n> want it within neutron. I\'m not suggesting that we create a db schema\n> alone, I\'m saying we must build it with the new LBaaS service (just\n> like neutron itself when it got created). If we don\'t do this now,\n> we\'ll end up reimplementing the logic implemented in neutron for the\n> new lbaas v3.0 API all over again for the new core LBaaS service. We\'d\n> rather do it in the new one in one effort.\n\nI believe everyone would rather not do the same thing twice but to meet\nthe needs of Neutron and LBaaS it was agreed that this would be the way\nto do it.  At least that is my understanding, someone please correct me\nif I\'m wrong.\n\n> \n> \n> \n> I could be missing some constraints that drive taking the former\n> approach - please help me understand those - I don\'t want to be\n> discounting any one approach without thorough consideration. Right\n> now, it looks to me like this approach is being taken only to\n> accommodate the HAProxy namespace driver. Really that is the only\n> driver which seems to be very intertwined with neutron in the way it\n> uses namespaces.\n\nNo, I don\'t think its even considering the namespace driver.  In my very\nlimited time at looking at that code I didn\'t think the namespaces were\na dependency on Neutron, but I may have missed the dependency there.  My\nunderstanding of one of the tight integration points was some drivers\nactually querying/updating the neutron database.  That is obviously\nsomething that needs to be fixed though.  \n\n> \n> \n> \n> \n>         >\n>         > What we should be providing in neutron is a switch (a global\n>         conf)\n>         > that can be set to instruct neutron to do one of two things:\n>         >\n>         >\n>         > 1. Use the existing neutron LBaaS API, with the backend\n>         being the\n>         > existing neutron LBaaS db schema. This is the status quo.\n>         > 2. Use the existing neutron LBaaS API, with the backend\n>         being the new\n>         > LBaaS service. This will invoke calls not to neutron\'s\n>         current LBaaS\n>         > code at all, rather, it will call into a new set of proxy\n>         \"backend\"\n>         > code in neutron that will translate the older LBaaS API\n>         calls into the\n>         > newer REST calls serviced by the new LBaaS service, which\n>         will write\n>         > down these details accordingly in its new db schema. As long\n>         as the\n>         > request and response objects to legacy neutron LBaaS calls\n>         are\n>         > preserved as is, there should be no issues. Writing unit\n>         tests should\n>         > also be comparatively more straightforward, and old\n>         functional tests\n>         > can be retained, and newer ones will not clash with legacy\n>         code.\n>         > Legacy code itself will work, having not been touched at\n>         all. The\n>         > blueprint for the db schema that you have referenced\n>         >\n>         (https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst) should be implemented for this new LBaaS service, post reviews.\n>         >\n>         \n>         I think the point of this blueprint is to get the API and\n>         object model\n>         less confusing for the Neutron LBaaS service plugin.  I think\n>         it\'s too\n>         early to create an LBaaS service because we have not yet\n>         cleaned up the\n>         tight integration points between Neutron LBaaS and LBaaS.\n>          Creating a\n>         new service would require only API interactions between\n>         Neutron and this\n>         LBaaS service, which currently is not possible due to these\n>         tight\n>         integration points.\n> \n> \n> v> The tight integration points between LBaaS and neutron that I see\n> are:\n> \n> \n> 1. The usage of namespaces.\nI\'m not so sure about this one, but I could be wrong because I haven\'t\nlooked at that code in depth.\n> 2.  L2 and L3 plumbing within the namespaces and tracking them in the\n> neutron and lbaas tables,\n> 3. Plugin driver and agent driver scheduling framework/mechanism for\n> LB drivers.\n> 4. The way drivers directly update the neutron db, which I think makes\n> for a lack of clear functional demarcation.\n> \n> \n> Regardless of how we use the new API and db model, will namespaces be\n> used? If they still need to be supported, the tight integration isn\'t\n> going to go anywhere.\n\nFor an operator level HaProxy driver I don\'t think namespaces will be\nused, but that hasn\'t been fleshed out yet.  However, if anything comes\nup that is a tight integration point with Neutron those will be need to\nbe fixed because the end goal is to have LBaaS as its own service.\n\n> \n> \n> This is why I think it will be best to keep the legacy drivers within\n> neutron, and not give an option to newer deployments to use that\n> concurrently with the new lbaas core service. The changes will be\n> lesser this way because we won\'t touch legacy code.\n> \n> \n> \n> While I fully understand that we\'re trying to change the way we look\n> at the lbaas deployments, and the db object model is an effort towards\n> that, we need to ensure that the execution is kept elegant as well.\n> For drivers for lb solutions like f5 or Netscaler, these pain points\n> can be done away with because they do their own network provisioning\n> and we keep track of them only to clean up (especially for virtual\n> appliance solutions).\n> \n> \n> It will however mean that we\'ll have the additional task of\n> implementing the new core service before we can use the new db object\n> model. I say we should just go for that effort and make it happen.\n\nYeah that is another problem of going that route if it would ready by\nJuno.  I\'m not sure.\n\n> \n> \n> \n> \n> \n>         \n>         >\n>         > The third option would be to turn off neutron LBaaS API, and\n>         use the\n>         > new LBaaS core service directly, but for this we can simply\n>         disable\n>         > neutron lbaas, and don\'t need a config parameter in neutron.\n>         >\n>         >\n>         > Implementing this db schema within neutron instead will be\n>         not just\n>         > complicated, but a huge effort that will go waste in future\n>         once the\n>         > new LBaaS service is implemented. Also, migration will\n>         unnecessarily\n>         > retain the same steps needed to go from legacy neutron LBaaS\n>         to the\n>         > new core LBaaS service in this approach (twice, in\n>         succession) in case\n>         > for any reason the version goes from legacy neutron LBaaS ->\n>         new\n>         > neutron LBaaS -> new LBaaS core service.\n>         \n>         I totally agree that this is technical debt, but I believe it\n>         is the\n>         best option we have right now since LBaaS needs to live in the\n>         Neutron\n>         code and process because of the tight integration points.\n>          Since this\n>         object model refactor has been slated for Juno, and these\n>         tight\n>         integration points may or may not be cleaned up by Juno,\n>         staying within\n>         Neutron seems to be the best option right now.\n> \n> \n> v> As I described above, I think the tight integration points are best\n> kept in legacy code and not carried over to the new implementation.\n> The cleanest way to do it would be to clearly demarcate neutron\n> related operations (L2/L3) from LBaaS. But I am keen to get your views\n> on what the difficult integration points are so that I get a better\n> understanding of the motivations behind keeping the new tables in\n> neutron.\n\nKyle and Mark will be providing a list of those integration points soon.\nListing those and fixing those is another thing we agreed on at the\nsummit with the goal of this becoming its own service.\n\nWill you be at the meeting tomorrow in IRC? I\'d like to talk to you more\nabout this so we both can fully understand what we both mean.  I know I\nam not explaining myself very well and I\'m probably misunderstanding\nwhat you are saying as well.  I\'m interested in anything that gets this\nprocess done easier and faster.  I agree with the approach for the LBaaS\nstandalone service, but I think going that route right now would go\nagainst what we agreed on at the Summit.  I hope to catch you in IRC\ntomorrow.\n\nThanks,\nBrandon\n\n> \n> \n> \n> \n> Regards,\n> Vijay\n> \n> \n> \n> \n>         >\n>         >\n>         > Going forward, the legacy neutron LBaaS API can be\n>         deprecated, and the\n>         > new API that directly contacts the new LBaaS core service\n>         can be used.\n>         >\n>         >\n>         > We have discussed the above architecture previously, but\n>         outside of\n>         > the ML, and a draft of the blueprint for this new LBaaS core\n>         service\n>         > is underway, and is a collation of all the discussions among\n>         a large\n>         > number of LBaaS engineers including yourself during the\n>         summit - I\n>         > will be posting it for review within a couple of days, as\n>         planned.\n>         >\n>         >\n>         >\n>         >\n>         > Regards,\n>         > Vijay\n>         >\n>         >\n>         > On Tue, May 27, 2014 at 12:32 PM, Brandon Logan\n>         > <brandon.logan at rackspace.com> wrote:\n>         >         Referencing this blueprint:\n>         >\n>         https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst\n>         >\n>         >         Anyone who has suggestions to possible issues or can\n>         answer\n>         >         some of\n>         >         these questions please respond.\n>         >\n>         >\n>         >         1. LoadBalancer to Listener relationship M:N vs 1:N\n>         >         The main reason we went with the M:N was so IPv6\n>         could use the\n>         >         same\n>         >         listener as IPv4.  However this can be accomplished\n>         by the\n>         >         user just\n>         >         creating a second listener and pool with the same\n>         >         configuration.  This\n>         >         will end up being a bad user experience when the\n>         listener and\n>         >         pool\n>         >         configuration starts getting complex (adding in TLS,\n>         health\n>         >         monitors,\n>         >         SNI, etc). A good reason to not do the M:N is\n>         because the\n>         >         logic on might\n>         >         get complex when dealing with status.  I\'d like to\n>         get\n>         >         people\'s opinions\n>         >         on this on whether we should do M:N or just 1:N.\n>          Another\n>         >         option, is to\n>         >         just implement 1:N right now and later implement the\n>         M:N in\n>         >         another\n>         >         blueprint if it is decided that the user experience\n>         suffers\n>         >         greatly.\n>         >\n>         >         My opinion: I like the idea of leaving it to another\n>         blueprint\n>         >         to\n>         >         implement.  However, we would need to watch out for\n>         any major\n>         >         architecture changes in the time itis not\n>         implemented that\n>         >         could make\n>         >         this more difficult than what it needs to be.\n>         >\n>         >         2. Pool to Health Monitor relationship 1:N vs 1:1\n>         >         Currently, I believe this is 1:N however it was\n>         suggested to\n>         >         deprecate\n>         >         this in favor of 1:1 by Susanne and Kyle agreed.\n>          Are there\n>         >         any\n>         >         objections to channging to 1:1?\n>         >\n>         >         My opinion: I\'m for 1:1 as long as there aren\'t any\n>         major\n>         >         reasons why\n>         >         there needs to be 1:N.\n>         >\n>         >         3. Does the Pool object need a status field now that\n>         it is a\n>         >         pure\n>         >         logical object?\n>         >\n>         >         My opinion: I don\'t think it needs the status\n>         field.  I think\n>         >         the\n>         >         LoadBalancer object may be the only thing that needs\n>         a status,\n>         >         other\n>         >         than the pool members for health monitoring.  I\n>         might be\n>         >         corrected on\n>         >         this though.\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAOCo3T1aZ3fxicNqHpJgUsyA2G9CNw9QYb+-oxymsN++YBV+BA@mail.gmail.com>',NULL),('<1401341267.51049.YahooMailNeo@web192604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-29 13:27:47',28800,'2014-05-29 05:27:47',NULL,'[Openstack] Stacked authentication with AD,LDAP','Hi,\n????Can someone please let me know when will this be available or plans in this regard..\n?\nRegards,\nsrinduva \n\n\nOn Friday, 23 May 2014 10:40 AM, srindu vai <srinduvai at yahoo.com> wrote:\n  \n\n\nHi,\n????I have a query here regarding stacked authentication support with AD,LDAP.\nPlease let me know will this already there or available in juno\n?\nBest Regards,\nSrinduva\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140529/d0cbec99/attachment.html>\n\n','<1400821829.38290.YahooMailNeo@web192605.mail.sg3.yahoo.com>',NULL),('<1401371063.7990.9.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 13:44:25',0,'2014-05-29 13:44:25',NULL,'[openstack-dev] Designate Incubation Request','On Thu, 2014-05-29 at 11:26 +0200, Thierry Carrez wrote:\n> Back to the topic, the tension here is because DNS is seen as a\n> \"network\" thing and therefore it sounds like it makes sense under\n> \"Networking\". But \"programs\" are not categories or themes. They are\n> teams aligned on a mission statement. If the teams are different\n> (Neutron and Designate) then it doesn\'t make sense to artificially\n> merge\n> them just because you think of \"networking\" as a theme. If the teams\n> converge, yes it makes sense. If they don\'t, we should just create a\n> new\n> program. They are cheap and should reflect how we work, not the other\n> way around.\n\n+1\n\nThis is exactly how I feel about programs, and couldn\'t have said it\nbetter myself :)\n\nThanks Thierry!\n\nKiall\n\n','<5386FD33.2010403@openstack.org>',NULL),('<1401371164.7990.10.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 13:46:05',0,'2014-05-29 13:46:05',NULL,'[openstack-dev] Designate Incubation Request','On Thu, 2014-05-29 at 08:00 +0930, Michael Davies wrote:\n> On Thu, May 29, 2014 at 4:22 AM, Sean Dague <sean at dague.net> wrote:\n> > I would agree this doesn\'t make sense in Neutron.\n> >\n> > I do wonder if it makes sense in the Network program. I\'m getting\n> > suspicious of the programs for projects model if every new project\n> > incubating in seems to need a new program. Which isn\'t really a\n> > reflection on designate, but possibly on our program structure.\n> \n> I also agree here - DNS isn\'t a program by itself in my opinion, it\n> should be in a group of  other \"Network Application Services\".\n\nI disagree - but Thierry put it better than I could have ever said at\n[1], so I\'ll just refer to his email :)\n\nThanks,\nKiall\n\n[1]:\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-May/036213.html\n\n','<CAPKtezyR5c9UtS08NwbJWsGis0SHEYMvnCfpC76MOb2mUTp8tg@mail.gmail.com>',NULL),('<1401371678.2135.13.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 09:54:38',-14400,'2014-05-29 13:54:38',NULL,'[openstack-dev] [sahara] summit wrap-up: backward compat','Catching up...\n\nOn Thu, 2014-05-29 at 15:59 +0400, Alexander Ignatov wrote:\n> On 28 May 2014, at 17:14, Sergey Lukjanov <slukjanov at mirantis.com> wrote:\n> > 1. How should we handle addition of new functionality to the API,\n> > should we bump minor version and just add new endpoints?\n> \n> Agree with most of folks. No new versions on adding new endpoints. \n> Semantic changes require new major version of rest api.\n\n+1 this and previous comments.  I don\'t think we\'ll generate too many\nsemantic changes (but I could be wrong :) )\n\nI agree with Mike that we should have simple version numbers, v1, v2, v3\n\n> > 2. For which period of time should we keep deprecated API and client for it?\n> \n> One release cycle for deprecation period.\n\n+1.  If we give folks N cycles, they will always wait until the Nth\ncycle to move away.  Might as well be 1.\n\n> \n> > 3. How to publish all images and/or keep stability of building images\n> > for plugins?\n> > \n> \n> We should keep all images for all plugins (non-deprecated as Matt mentioned) \n> for each release. In addition we could keep  at least one image which could be \n> downloaded and used with master branch of Sahara. Plugin vendors could keep \n> its own set of images and we can reflect it in the docs.\n\nI agree with keeping all images grouped with a release for all supported\nplugins in that release.\n\nAre we suggesting here that there are 2 places to find images, one in\nthe Sahara releases and a second in a vendor repo listed in the docs?\n\n> Regards,\n> Alexander Ignatov\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CF0174FB-4840-4955-B71A-7A92B9B84118@mirantis.com>',NULL),('<1401371983.2135.15.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 09:59:43',-14400,'2014-05-29 13:59:43',NULL,'[openstack-dev] [sahara] summit wrap-up: subprojects','below, sahara-extra\n\nOn Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov wrote:\n> Hey folks,\n> \n> it\'s a small wrap-up for the topic \"Sahara subprojects releasing and\n> versioning\" that was discussed partially on summit and requires some\n> more discussions. You can find details in [0].\n> \n> > common\n> \n> We\'ll include only one tarball for sahara to the release launchpad\n> pages. All other links will be provided in docs.\n> \n> > sahara-dashboard\n> \n> The merging to Horizon process is now in progress. We\'ve decided that\n> j1 is the deadline for merging main code parts and during the j2 all\n> the code should be merged into Horizon, so, if in time of j2 we\'ll\n> have some work on merging sahara-dashboard to Horizon not done we\'ll\n> need to fallback to the separated sahara-dashboard repo release for\n> Juno cycle and continue merging the code into the Horizon to be able\n> to completely kill sahara-dashboard repo in K release.\n> \n> Where we should keep our UI integration tests?\n> \n> > sahara-image-elements\n> \n> We\'re agreed that some common parts should be merged into the\n> diskimage-builder repo (like java support, ssh, etc.). The main issue\n> of keeping -image-elements separated is how to release them and\n> provide mapping sahara version - elements version. You can find\n> different options in etherpad [0], I\'ll write here about the option\n> that I think will work best for us.\n> \n> So, the idea is that sahara-image-elements is a bunch of scripts and\n> tools for building images for Sahara. It\'s high coupled with plugins\'s\n> code in Sahara, so, we need to align them good. Current default\n> decision is to keep aligned versioning like 2014.1 and etc. It\'ll be\n> discussed on the weekly irc team meeting May 29.\n> \n> > sahara-extra\n> \n> Keep it as is, no need to stop releasing, because we\'re not publishing\n> anything to pypi. No real need for tags.\n\nEven if we keep the repo for now, I think we could simplify a little\nbit.  The edp-examples could be moved to the Sahara repo.  Some of those\nexamples we use in the integration tests anyway -- why have them\nduplicated?\n\n> \n> \n> > open questions\n> \n> If you have any objections for this model, please, share your thoughts\n> before June 3 due to the Juno-1 (June 12) to have enough time to apply\n> selected approach.\n> \n> [0] https://etherpad.openstack.org/p/juno-summit-sahara-relmngmt-backward\n> \n> Thanks.\n> \n\n\n\n\n','<CA+GZd7-LWawnjXZ_uZR4XiEWYxSYktufQCNUR5SxAk29a3MjxA@mail.gmail.com>',NULL),('<1401406197-sup-2763@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 05:22:07',19800,'2014-05-29 23:52:07',NULL,'[openstack-dev] [Heat] Short term scaling strategies for large Heat\n	stacks','Hello!\n\nI am writing to get some brainstorming started on how we might mitigate\nsome of the issues we\'ve seen while deploying large stacks on Heat. I am\nsending this to the dev list because it may involve landing fixes rather\nthan just using different strategies. The problems outlined here are\nwell known and reported as bugs or feature requests, but there may be\nmore that we can do.\n\nFirst off, we\'ve pushed Heat quite a bit further than it ever was able\nto go before. This is due to the fantastic work done across the Heat\ndevelopment community to respond to issues we\'ve reported. We are really\nexcited to get started on the effort to move Heat toward a convergence\nmodel, but it is quite clearly a medium-term strategy. What we are\nlooking for is a short term bridge to get us through the near-term\nproblems while code lands to fix things in the mid-term.\n\nWe have a desire to deploy a fairly wide stack of servers. OpenStack\'s\nsimplest architecture has a few \"controllers\" which keep state and need\nto be HA, and then lots of compute nodes.\n\nWhat we\'ve seen is that while deploying a cluster with a single controller\nand \"n\" compute nodes, the probability of stack failure goes up as n\ngoes up. So we want to mitigate the impact and enable a deployer to\nmanage a cluster like this with Heat.\n\nWe have also seen that the single thread that must manage an action will\ntake quite a lot of CPU power to process a large stack, which makes\noperations on a large stack take a long time and thus increases the\nimpact of any changes that must be made.\n\nStrategies:\n\nAbandon + Adopt\n===============\n\nIn this strategy, a failure will be responded to by abandoning the stack\nin Heat, leaving the successful resources in place. Then the resulting\nabandon serialization will be editted to match reality, and the stack\nadopted. This suffers from a bug where in-instance users created inside\nthe stack, while still valid, will not be given access to the metadata.\nfix the bugs in abandon/adopt to make sure this works.\n\nPros: * Exists today\n\nCons: * Bugs must be fixed\n      * Manual process is undefined and requires engineering effort to\n        recover.\n\nMultiple Stacks\n===============\n\nWe could break the stack up between controllers, and compute nodes. The\ncontroller will be less likely to fail because it will probably be 3 nodes\nfor a reasonably sized cloud. The compute nodes would then live in their\nown stack of (n) nodes. We could further break that up into chunks of\ncompute nodes, which would further mitigate failure. If a small chunk of\ncompute nodes fails, we can just migrate off of them. One challenge here\nis that compute nodes need to know about all of the other compute nodes\nto support live migration. We would have to do a second stack update after\ncreation to share data between all of these stacks to make this work.\n\nPros: * Exists today\n\nCons: * Complicates host awareness\n      * Still vulnerable to stack failure (just reduces probability and\n        impact).\n\nManual State Manipulation\n=========================\n\nWe could create tools for administrators to go into the Heat database\nand \"fix\" the stack. This is basically the same approach as\nabandon/adopt, but it is lighter weight and works around the issue of\nlosing track of in-instance users.\n\nPros: * Light weight\n      * Possible today\n\nCons: * Violates API layers\n      * Requires out of band access to Heat data store.\n      * Will not survive database schema changes\n\nupdate-failure-recovery\n=======================\n\nThis is a blueprint I believe Zane is working on to land in Juno. It will\nallow us to retry a failed create or update action. Combined with the\nseparate controller/compute node strategy, this may be our best option,\nbut it is unclear whether that code will be available soon or not. The\nchunking is definitely required, because with 500 compute nodes, if\nnode #250 fails, the remaining 249 nodes that are IN_PROGRESS will be\ncancelled, which makes the impact of a transient failure quite extreme.\nAlso without chunking, we\'ll suffer from some of the performance\nproblems we\'ve seen where a single engine process will have to do all of\nthe work to bring up a stack.\n\nPros: * Uses blessed strategy\n\nCons: * Implementation is not complete\n      * Still suffers from heavy impact of failure\n      * Requires chunking to be feasible\n\n\nAnyway, these are the strategies I have available today. Does anyone\nelse have some ideas to help us make use of the current Heat to deploy\nlarge stacks? Thanks!\n\n\n',NULL,NULL),('<1401412081-sup-5716@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 06:39:18',19800,'2014-05-30 01:09:18',NULL,'[openstack-dev] [Heat] Short term scaling strategies for large\n	Heat stacks','Excerpts from Mike Spreitzer\'s message of 2014-05-30 05:42:43 +0530:\n> Clint Byrum <clint at fewbar.com> wrote on 05/29/2014 07:52:07 PM:\n> \n> > I am writing to get some brainstorming started on how we might mitigate\n> > some of the issues we\'ve seen while deploying large stacks on Heat. I am\n> > sending this to the dev list because it may involve landing fixes rather\n> > than just using different strategies. The problems outlined here are\n> > well known and reported as bugs or feature requests, but there may be\n> > more that we can do.\n> > \n> > ...\n> > \n> > Strategies:\n> > \n> > ...\n> > \n> > update-failure-recovery\n> > =======================\n> > \n> > This is a blueprint I believe Zane is working on to land in Juno. It \n> will\n> > allow us to retry a failed create or update action. Combined with the\n> > separate controller/compute node strategy, this may be our best option,\n> > but it is unclear whether that code will be available soon or not. The\n> > chunking is definitely required, because with 500 compute nodes, if\n> > node #250 fails, the remaining 249 nodes that are IN_PROGRESS will be\n> > cancelled, which makes the impact of a transient failure quite extreme.\n> > Also without chunking, we\'ll suffer from some of the performance\n> > problems we\'ve seen where a single engine process will have to do all of\n> > the work to bring up a stack.\n> > \n> > Pros: * Uses blessed strategy\n> > \n> > Cons: * Implementation is not complete\n> >       * Still suffers from heavy impact of failure\n> >       * Requires chunking to be feasible\n> \n> I like this one.  As I remarked in the convergence discussion, I think the \n> first step there is a DB schema change to separate desired and observed \n> state.  Once that is done, failure on one resource need not wedge a stack; \n> non-dependent resources (like the peer compute nodes) can still be \n> created.\n\nIt\'s not just the observed state that you need in the database to resume.\n\nYou also need the parameters and template snippet that has been\nsuccessfully applied.\n\n\n','<OFCC6E1F3A.ECDDE994-ON85257CE8.00009529-85257CE8.00012A4C@us.ibm.com>',NULL),('<1401418916.5086.3.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-29 22:01:56',-18000,'2014-05-30 03:01:56',NULL,'[openstack-dev] Commit the cinder Driver','Mardan,\n\nNote, you will also need to follow the new Cinder Specs process for Juno\nBluePrints.  You can find details here: [1]\n\nJay\n\n[1]\nhttp://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-05-28-16.00.log.html#l-437\n\nOn Wed, 2014-05-07 at 18:48 +0530, Swapnil Kulkarni wrote:\n> Missed some of the additional links which might be helpful/important\n> for you.\n> \n> \n> [1] https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver\n> [2] https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer\n> \n> \n> \n> \n> \n> \n> On Wed, May 7, 2014 at 11:38 AM, Swapnil Kulkarni <coolsvap at gmail.com>\n> wrote:\n>         Hi Mardan,\n>         \n>         \n>         \n>         \n>         Thanks!\n>         \n>         \n>         For the Cloudbyte ElastiStor I can see couple of (duplicate)\n>         blueprints filed [1] [2].  You should probably assign one of\n>         them to you and update  with details till we get cinder-spec\n>         available for blueprint review process.\n>         \n>         \n>         For details about commit process please refer [3].\n>         \n>         \n>         For any issues with commit process, feel free to ask questions\n>         at #openstack-cinder @ freenode.net \n>         \n>         \n>         Also, you should try to attend Cinder meetings [4] to update\n>         the team about your progress on commits and for any updates\n>         you should be having related to new driver submissions.\n>         \n>         \n>         \n>         \n>         [1] https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver\n>         [2] https://blueprints.launchpad.net/cinder/+spec/cloudbyte-elastistor-iscsi-driver-cinder\n>         [3] https://wiki.openstack.org/wiki/Gerrit_Workflow\n>         [4] https://wiki.openstack.org/wiki/CinderMeetings\n>         \n>         \n>         \n>         Best Regards,\n>         Swapnil Kulkarni\n>         irc : coolsvap\n>         coolsvap at gmail.com\n>         +91-87960 10622(c)\n>         http://in.linkedin.com/in/coolsvap\n>         \n>         \"It\'s better to SHARE\"\n>         \n>         \n>         \n>         On Wed, May 7, 2014 at 11:24 AM, Mardan Raghuwanshi\n>         <mardan.singh at cloudbyte.com> wrote:\n>         \n>                 Hi All,\n>                 \n>                 \n>                 I developed Cinder driver for CloudByte\'s ElastiStor,\n>                 now I want to check in this code into master.\n>                 \n>                 I don\'t have more idea about git and OpenStack commit\n>                 process, can you guys please guide me to commit the\n>                 code into master branch.\n>                 \n>                 \n>                 \n>                 Thanks,\n>                 \n>                 Mardan\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAKO+H+K-JUDCp6Wd4U9hFewCnKKDhenURJsL8-tD=SwzhK1Jqw@mail.gmail.com>',NULL),('<1401453925-sup-3211@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 18:18:35',19800,'2014-05-30 12:48:35',NULL,'[openstack-dev] [TripleO] [Ironic] [Heat] [Nova] Mid-cycle\n	collaborative meetup','Excerpts from Jaromir Coufal\'s message of 2014-05-30 17:16:21 +0530:\n> Hi Devananda,\n> \n> it is interesting. I think that we can invite Nova as well and join our \n> efforts at one place. It will be like a tiny (more focused) summit but \n> it sounds that all projects can benefit a lot from it. What do you think?\n> \n> [added Nova tag to the subject]\n> \n> Nova folks, what do you think? Would you like to join our mid-cycle \n> meeting and have TripleO & Ironic & Heat & Nova teams together at one place?\n> \n> More details about place, dates and attendees are here:\n> https://etherpad.openstack.org/p/juno-midcycle-meetup\n\nMy personal opinion is that it needs to remain focused. Having two\ngroups together is good. Having three will increase the logistical\nissues and add pressure to those who straddle all three. Having four\nwill just make it a mini-summit with everyones\' heads spinning. We want\nto get real work done at these events, they\'re not nearly as social.\n\nI like the idea of it just being TripleO and Heat, but I\'m biased, since\nI\'m a core reviewer on TripleO... and Heat. :)\n\nI also like the idea of Ironic devs strategically placing themselves\nbetween every Nova core reviewer and the nearest source of caffeine,\nwith a nice smile on their face and a \"hey, would you like to review my\npatch?\".\n\n\n','<53886F8D.7070106@redhat.com>',NULL),('<1401463534.3981.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 15:25:34',0,'2014-05-30 15:25:34',NULL,'[openstack-dev] [Neutron][LBaaS] dealing with M:N\n relashionships for Pools and Listeners','Hi Sam and Stephen,\n\nOn Thu, 2014-05-29 at 21:10 -0700, Stephen Balukoff wrote:\n> Hi Sam,\n> \n> \n> Here are my thoughts on this:\n> \n> \n> On Thu, May 29, 2014 at 12:32 PM, Samuel Bercovici\n> <SamuelB at radware.com> wrote:\n>         Before solving everything, I would like first to itemize the\n>         things we should solve/consider.\n>         \n>         So pleas focus first on what is it that we need to pay\n>         attention for and less on how to solve such issues.\n>         \n>          \n>         \n>         Follows the list of items:\n>         \n>         ?        Provisioning status/state\n>         \n>         o  Should it only be on the loadblancer?\n>         \n>         \n> That makes sense to me, unless we\'re also using this field to indicate\n> a pending change from an update as well. Pending changes here should\n> be reflected in the listener state.\nI agree with this as well.\n> \n> \n>  \n>         o  Do we need a more granular status per logical child object?\n>         \n>         \n> \n> \n> Than what? I\'m not sure I understand what you\'re saying here. Can you\n> give a couple examples?\n>  \n>         o  Update process\n>         \n>         ? What happens when a logical child object is modified?\n>         \n>         \n> Any affected parent objects should show a \'PENDING_UPDATE\' status or\n> something similar until the change is pushed to them. \n>  \n>         ? Where can a user check the success of the update?\n>         \n>         \n> \n> \n> Depending on the object... either the status of the child object\n> itself or all of its affected parent(s). Since we\'re allowing reusing\n> of the pool object, when getting the status of a pool, maybe it makes\n> sense to produce a list showing the status of all the pool\'s members,\n> as well as the update status of all the listeners using the pool?\n\nThis is confusing to me.  Will there be a separate provisioning status\nfield on the loadbalancer and just a generic status on the child\nobjects?  I get the idea of a pool having a status the reflects the\nstate of all of its members.  Is that what you mean by status of a child\nobject?\n\n>  \n>         ?        Operation status/state ? this refers to information\n>         returning from the load balancing back end / driver\n>         \n>         o  How is member status that failed health monitor reflected,\n>         on which LBaaS object and how can a user understand the\n>         failure?\n>         \n>         \n> Assuming you\'re not talking about an alert which would be generated by\n> a back-end load balancer and get routed to some notification system...\n> I think you should be able to get the status of a member by just\n> checking the member status directly (ie.  GET /members/[UUID]) or, if\n> people like my suggestion above, by checking the status of the pool to\n> which the member belongs (ie. GET /pools/[UUID]).\n>  \n> \n>         ?        Administrator state management \n>         \n>         o  How is a change in admin_state on member, pool, listener\n>         get managed\n>         \n>         \n> I\'m thinking that disabling members, pools, and listeners should\n> propagate to all parent objects. (For example, disabling a member\n> should propagate to all affected pools and listeners, which\n> essentially pulls the member out of rotation for all load balancers\n> but otherwise leaves listeners and pools up and running. This is\n> probably what the user is trying to accomplish by disabling the\n> member.)\n\nAre you saying in this case if a member is disabled and all members are\ndisabled then the parent\'s pool status is disabled which would then in\nturn disable the listener?\n\n> \n> I do not think it makes sense to propagate to all child objects. For\n> example, disabling a listener should not disable all the pools it\n> references.\n> \n> And by \'propagate\' here I mean that config changes are pushed to all\n> affected listeners and load balancers-- not that we actually update\n> all parents to be \'ADMIN_STATUS_DOWN\' or something. Does this make\n> sense to you?\n\nPropogating to child objects would be bad with shared listeners and\npools.\n\n>  \n>         o  Do we expect a change in the operation state to reflect\n>         this?\n>         \n>         \n> Yes.\n>  \n>         ?        Statistics consumption\n>         \n>         \n> I actually started another thread on this to get some operator and\n> user requirements here, but so far nobody has replied.  FWIW, I\'m\n> leaning toward having a RESTful interface for statistics that\'s\n> separate from the main configuration interface tree and has implied\n> context depending on how it\'s used.\n> \n> \n> For example, if you want to see the stats for a particular member of a\n> particular pool of a particular listener on a particular load\n> balancer, you\'d GET something like the following:\n> \n> \n> GET /stats/loadbalancer/LB_UUID/listener/LB_UUID/pool/POOL_UUID/member/MEMBER_UUID\n> \n> \n> ...which would give you just the stats for that member in that\n> context.\n> \n> I think we might also want to support getting overall stats for a\n> single logical object. So for example:\n> \n> GET /stats/member/MEMBER_UUID\n> \n> \n> ...would get you total stats for that member, regardless of which\n> pool, listener, or loadbalancer it happens to reside in.\n> \n> \n> But... all of this really depends on what users are going to be\n> interested in and operators want to provide. What\'s the point of going\n> to the trouble of collecting very specific-context stats if the user\n> only cares about aggregate stats?\n\nI know from just a billing standpoint all we care about is just the\nloadbalancer stats since a loadbalancer will only have one vip (assuming\nwe don\'t do the IPv4 and IPv6).  Those stats would be incoming and\noutgoing bandwidth, connections (total and concurrent), and obviously\nuptime which will most likely be available through the DB.\n\nWe do expose other stats to customers and I am sure our Ops needs other\nstats as well.  I\'ll try to get a full list and respond to your other\nemail about stats.\n\nI\'m not sure how much we would need stats on each individual pool\nmember, or even the pool.  It is possible our Ops need it though.\nHowever, other operators may need that.\n\n>  \n>         o  From which object will the user ?poll? to get statistics\n>         for the different sub objects in the model (ex: load\n>         balancer)? \n>         \n>         \n>         o  How can statistics from a shared logical object be obtained\n>         in context of the load balancer (ex: pool statistics for a\n>         specific listener in a specific load balancer)?\nThats why I think we put only the stats on the loadbalancer resource\n(i.e. /loadbalancers/LB_UUID/stats) and that shows the stats for all of\nits children entities if we decide to show that.  Alternatively, we\nallow the child resource through the load balancer resource\n(i.e. /loadbalancers/LB_UUID/listeners/LISTENER_UUID/stats)\n>         \n>         \n>         ?        Deletion of shared objects\n>         \n>         o  Do we support deletion of shared objects that will cascade\n>         delete?\n\nI\'m not a big fan of cascading deletes on behalf of a customer.  I think\nthe customer should detach a child object from all of its parents and\nthen and only then are they able to delete that object.\n\n>         \n>         \n> \n> \n> Thanks,\n> Stephen \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZoQibsBPTYisY7hxKSEoyBJTkxGF4cy6vYYtV=+YT=cLw@mail.gmail.com>',NULL),('<1401491415.27279.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 23:10:15',0,'2014-05-30 23:10:15',NULL,'[openstack-dev] [Neutron][LBaaS] Unanswered questions in object\n model refactor blueprint','Stephen,\n\nWere you still planning on doing the second blueprint that will\nimplement the new API calls?\n\nThanks,\nBrandon\n\nOn Thu, 2014-05-29 at 22:36 -0700, Bo Lin wrote:\n> Hi Brandon and Stephen,\n> Really thanks for your responses and i got to know it.\n> \n> \n> Thanks!\n> ---Bo\n> \n> ______________________________________________________________________\n> From: \"Brandon Logan\" <brandon.logan at RACKSPACE.COM>\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Sent: Friday, May 30, 2014 1:17:57 PM\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in\n> object model refactor blueprint\n> \n> \n> Hi Bo,\n> Sorry, I forgot to respond but yes what Stephen said lol :)\n> \n> ______________________________________________________________________\n> From: Stephen Balukoff [sbalukoff at bluebox.net]\n> Sent: Thursday, May 29, 2014 10:42 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in\n> object model refactor blueprint\n> \n> \n> \n> \n> Hi Bo--\n> \n> \n> Haproxy is able to have IPv4 front-ends with IPv6 back-ends (and visa\n> versa) because it actually initiates a separate TCP connection between\n> the front end client and the back-end server. The front-end thinks\n> haproxy is the server, and the back-end thinks haproxy is the client.\n> In practice, therefore, its totally possible to have an IPv6 front-end\n> and IPv4 back-end with haproxy (for both http and generic TCP service\n> types).\n> \n> \n> I think this is similarly true for vendor appliances that are capable\n> of doing IPv6, and are also initiating new TCP connections from the\n> appliance to the back-end.\n> \n> \n> Obviously, the above won\'t work if your load balancer implementation\n> is doing something \"transparent\" on the network layer like LVM load\n> balancing.\n> \n> \n> Stephen\n> \n> \n> \n> \n> On Wed, May 28, 2014 at 9:14 PM, Bo Lin <linb at vmware.com> wrote:\n>         Hi Brandon,\n>         \n>         I have one question. If we support LoadBalancer to Listener\n>         relationship M:N, then one listener with IPV4 service members\n>         backend may be shared by a loadbalancer instance with IPV6\n>         forntend. Does it mean we also need to provide IPV6 - IPV4\n>         port forwarding functions in LBaaS services products? Does\n>         iptables or most LBaaS services products such as haproxy or so\n>         on provide such function? Or I am just wrong in some technique\n>         details on these LBaaS products.\n>         \n>         \n>         Thanks!\n>         \n>         ______________________________________________________________\n>         From: \"Vijay B\" <os.vbvs at gmail.com>\n>         \n>         To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         \n>         Sent: Thursday, May 29, 2014 6:18:42 AM\n>         \n>         Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered\n>         questions in object model refactor blueprint\n>         \n>         \n>         Hi Brandon!\n>         \n>         \n>         Please see inline..\n>         \n>         \n>         \n>         \n>         \n>         \n>         \n>         On Wed, May 28, 2014 at 12:01 PM, Brandon Logan\n>         <brandon.logan at rackspace.com> wrote:\n>                 Hi Vijay,\n>                 \n>                 On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:\n>                 > Hi Brandon,\n>                 >\n>                 >\n>                 > The current reviews of the schema itself are\n>                 absolutely valid and\n>                 > necessary, and must go on. However, the place of\n>                 implementation of\n>                 > this schema needs to be clarified. Rather than make\n>                 any changes\n>                 > whatsoever to the existing neutron db schema for\n>                 LBaaS, this new db\n>                 > schema outlined needs to be implemented for a\n>                 separate LBaaS core\n>                 > service.\n>                 >\n>                 \n>                 Are you suggesting a separate lbaas database from the\n>                 neutron database?\n>                 If not, then I could use some clarification. If so,\n>                 I\'d advocate against\n>                 that right now because there\'s just too many things\n>                 that would need to\n>                 be changed.  Later, when LBaaS becomes its own service\n>                 then yeah that\n>                 will need to happen.\n>         \n>         \n>         v> Ok, so as I understand it, in this scheme, there is no new\n>         schema or db, there will be a new set of tables resident in\n>         neutron_db schema itself, alongside legacy lbaas tables. Let\'s\n>         consider a rough view of the implementation.\n>         \n>         \n>         Layer 1 - We\'ll have a new lbaas v3.0 api in neutron, with the\n>         current lbaas service plugin having to support it in addition\n>         to the legacy lbaas extensions that it already supports. We\'ll\n>         need to put in new code anyway that will process the v3.0\n>         lbaas api no matter what our approach is.\n>         Layer 2 - Management code that will take care of updating the\n>         db with entities in pending_create, then invoking the right\n>         provider driver, choosing/scheduling the plugin drivers or the\n>         agent drivers, invoking them, getting the results, and\n>         updating the db.\n>         Layer 3 - The drivers themselves (either plugin drivers (like\n>         the HAProxy namespace driver/Netscaler) or plugin drivers +\n>         agent drivers).\n>         \n>         \n>         While having the new tables sit alongside the legacy tables is\n>         one way to implement the changes, I don\'t see how this\n>         approach leads to a lesser amount of changes overall. Layer 2\n>         above will be the major place where changes can be\n>         complicated. Also, it will be confusing to have two sets of\n>         lbaas tables in the same schema.\n>         \n>         \n>         I don\'t want a separate lbaas database under neutron, and\n>         neither do I want it within neutron. I\'m not suggesting that\n>         we create a db schema alone, I\'m saying we must build it with\n>         the new LBaaS service (just like neutron itself when it got\n>         created). If we don\'t do this now, we\'ll end up reimplementing\n>         the logic implemented in neutron for the new lbaas v3.0 API\n>         all over again for the new core LBaaS service. We\'d rather do\n>         it in the new one in one effort.\n>         \n>         \n>         \n>         I could be missing some constraints that drive taking the\n>         former approach - please help me understand those - I don\'t\n>         want to be discounting any one approach without thorough\n>         consideration. Right now, it looks to me like this approach is\n>         being taken only to accommodate the HAProxy namespace driver.\n>         Really that is the only driver which seems to be very\n>         intertwined with neutron in the way it uses namespaces.\n>         \n>         \n>         \n>         \n>                 >\n>                 > What we should be providing in neutron is a switch\n>                 (a global conf)\n>                 > that can be set to instruct neutron to do one of two\n>                 things:\n>                 >\n>                 >\n>                 > 1. Use the existing neutron LBaaS API, with the\n>                 backend being the\n>                 > existing neutron LBaaS db schema. This is the status\n>                 quo.\n>                 > 2. Use the existing neutron LBaaS API, with the\n>                 backend being the new\n>                 > LBaaS service. This will invoke calls not to\n>                 neutron\'s current LBaaS\n>                 > code at all, rather, it will call into a new set of\n>                 proxy \"backend\"\n>                 > code in neutron that will translate the older LBaaS\n>                 API calls into the\n>                 > newer REST calls serviced by the new LBaaS service,\n>                 which will write\n>                 > down these details accordingly in its new db schema.\n>                 As long as the\n>                 > request and response objects to legacy neutron LBaaS\n>                 calls are\n>                 > preserved as is, there should be no issues. Writing\n>                 unit tests should\n>                 > also be comparatively more straightforward, and old\n>                 functional tests\n>                 > can be retained, and newer ones will not clash with\n>                 legacy code.\n>                 > Legacy code itself will work, having not been\n>                 touched at all. The\n>                 > blueprint for the db schema that you have referenced\n>                 >\n>                 (https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst) should be implemented for this new LBaaS service, post reviews.\n>                 >\n>                 \n>                 I think the point of this blueprint is to get the API\n>                 and object model\n>                 less confusing for the Neutron LBaaS service plugin.\n>                  I think it\'s too\n>                 early to create an LBaaS service because we have not\n>                 yet cleaned up the\n>                 tight integration points between Neutron LBaaS and\n>                 LBaaS.  Creating a\n>                 new service would require only API interactions\n>                 between Neutron and this\n>                 LBaaS service, which currently is not possible due to\n>                 these tight\n>                 integration points.\n>         \n>         \n>         v> The tight integration points between LBaaS and neutron that\n>         I see are:\n>         \n>         \n>         1. The usage of namespaces.\n>         2.  L2 and L3 plumbing within the namespaces and tracking them\n>         in the neutron and lbaas tables,\n>         3. Plugin driver and agent driver scheduling\n>         framework/mechanism for LB drivers.\n>         4. The way drivers directly update the neutron db, which I\n>         think makes for a lack of clear functional demarcation.\n>         \n>         \n>         Regardless of how we use the new API and db model, will\n>         namespaces be used? If they still need to be supported, the\n>         tight integration isn\'t going to go anywhere. \n>         \n>         \n>         This is why I think it will be best to keep the legacy drivers\n>         within neutron, and not give an option to newer deployments to\n>         use that concurrently with the new lbaas core service. The\n>         changes will be lesser this way because we won\'t touch legacy\n>         code.\n>         \n>         \n>         \n>         While I fully understand that we\'re trying to change the way\n>         we look at the lbaas deployments, and the db object model is\n>         an effort towards that, we need to ensure that the execution\n>         is kept elegant as well. For drivers for lb solutions like f5\n>         or Netscaler, these pain points can be done away with because\n>         they do their own network provisioning and we keep track of\n>         them only to clean up (especially for virtual appliance\n>         solutions).\n>         \n>         \n>         It will however mean that we\'ll have the additional task of\n>         implementing the new core service before we can use the new db\n>         object model. I say we should just go for that effort and make\n>         it happen.\n>         \n>         \n>         \n>         \n>         \n>                 \n>                 >\n>                 > The third option would be to turn off neutron LBaaS\n>                 API, and use the\n>                 > new LBaaS core service directly, but for this we can\n>                 simply disable\n>                 > neutron lbaas, and don\'t need a config parameter in\n>                 neutron.\n>                 >\n>                 >\n>                 > Implementing this db schema within neutron instead\n>                 will be not just\n>                 > complicated, but a huge effort that will go waste in\n>                 future once the\n>                 > new LBaaS service is implemented. Also, migration\n>                 will unnecessarily\n>                 > retain the same steps needed to go from legacy\n>                 neutron LBaaS to the\n>                 > new core LBaaS service in this approach (twice, in\n>                 succession) in case\n>                 > for any reason the version goes from legacy neutron\n>                 LBaaS -> new\n>                 > neutron LBaaS -> new LBaaS core service.\n>                 \n>                 I totally agree that this is technical debt, but I\n>                 believe it is the\n>                 best option we have right now since LBaaS needs to\n>                 live in the Neutron\n>                 code and process because of the tight integration\n>                 points.  Since this\n>                 object model refactor has been slated for Juno, and\n>                 these tight\n>                 integration points may or may not be cleaned up by\n>                 Juno, staying within\n>                 Neutron seems to be the best option right now.\n>         \n>         \n>         v> As I described above, I think the tight integration points\n>         are best kept in legacy code and not carried over to the new\n>         implementation. The cleanest way to do it would be to clearly\n>         demarcate neutron related operations (L2/L3) from LBaaS. But I\n>         am keen to get your views on what the difficult integration\n>         points are so that I get a better understanding of the\n>         motivations behind keeping the new tables in neutron.\n>         \n>         \n>         \n>         \n>         Regards,\n>         Vijay\n>         \n>         \n>         \n>         \n>                 >\n>                 >\n>                 > Going forward, the legacy neutron LBaaS API can be\n>                 deprecated, and the\n>                 > new API that directly contacts the new LBaaS core\n>                 service can be used.\n>                 >\n>                 >\n>                 > We have discussed the above architecture previously,\n>                 but outside of\n>                 > the ML, and a draft of the blueprint for this new\n>                 LBaaS core service\n>                 > is underway, and is a collation of all the\n>                 discussions among a large\n>                 > number of LBaaS engineers including yourself during\n>                 the summit - I\n>                 > will be posting it for review within a couple of\n>                 days, as planned.\n>                 >\n>                 >\n>                 >\n>                 >\n>                 > Regards,\n>                 > Vijay\n>                 >\n>                 >\n>                 > On Tue, May 27, 2014 at 12:32 PM, Brandon Logan\n>                 > <brandon.logan at rackspace.com> wrote:\n>                 >         Referencing this blueprint:\n>                 >\n>                 https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst\n>                 >\n>                 >         Anyone who has suggestions to possible\n>                 issues or can answer\n>                 >         some of\n>                 >         these questions please respond.\n>                 >\n>                 >\n>                 >         1. LoadBalancer to Listener relationship M:N\n>                 vs 1:N\n>                 >         The main reason we went with the M:N was so\n>                 IPv6 could use the\n>                 >         same\n>                 >         listener as IPv4.  However this can be\n>                 accomplished by the\n>                 >         user just\n>                 >         creating a second listener and pool with the\n>                 same\n>                 >         configuration.  This\n>                 >         will end up being a bad user experience when\n>                 the listener and\n>                 >         pool\n>                 >         configuration starts getting complex (adding\n>                 in TLS, health\n>                 >         monitors,\n>                 >         SNI, etc). A good reason to not do the M:N\n>                 is because the\n>                 >         logic on might\n>                 >         get complex when dealing with status.  I\'d\n>                 like to get\n>                 >         people\'s opinions\n>                 >         on this on whether we should do M:N or just\n>                 1:N.  Another\n>                 >         option, is to\n>                 >         just implement 1:N right now and later\n>                 implement the M:N in\n>                 >         another\n>                 >         blueprint if it is decided that the user\n>                 experience suffers\n>                 >         greatly.\n>                 >\n>                 >         My opinion: I like the idea of leaving it to\n>                 another blueprint\n>                 >         to\n>                 >         implement.  However, we would need to watch\n>                 out for any major\n>                 >         architecture changes in the time itis not\n>                 implemented that\n>                 >         could make\n>                 >         this more difficult than what it needs to\n>                 be.\n>                 >\n>                 >         2. Pool to Health Monitor relationship 1:N\n>                 vs 1:1\n>                 >         Currently, I believe this is 1:N however it\n>                 was suggested to\n>                 >         deprecate\n>                 >         this in favor of 1:1 by Susanne and Kyle\n>                 agreed.  Are there\n>                 >         any\n>                 >         objections to channging to 1:1?\n>                 >\n>                 >         My opinion: I\'m for 1:1 as long as there\n>                 aren\'t any major\n>                 >         reasons why\n>                 >         there needs to be 1:N.\n>                 >\n>                 >         3. Does the Pool object need a status field\n>                 now that it is a\n>                 >         pure\n>                 >         logical object?\n>                 >\n>                 >         My opinion: I don\'t think it needs the\n>                 status field.  I think\n>                 >         the\n>                 >         LoadBalancer object may be the only thing\n>                 that needs a status,\n>                 >         other\n>                 >         than the pool members for health\n>                 monitoring.  I might be\n>                 >         corrected on\n>                 >         this though.\n>                 >\n>                 >\n>                 _______________________________________________\n>                 >         OpenStack-dev mailing list\n>                 >         OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 >\n>                 >\n>                 > _______________________________________________\n>                 > OpenStack-dev mailing list\n>                 > OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         \n>         https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=DYApm8uTUC2lxp%2B0qmdN9UhsdAxGdWaIHf5dr1N1tJE%3D%0A&s=ec3a8e21156d1b946db652fac0dab2e2268340aea37bd8c30adbf52fe2f3e8de\n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=SPXsODyQQDMdWpsIy6DIIIQT2Ao%2FZRwloVLU6nM0qzw%3D%0A&s=4e8589eef4ccff3b179e9ff7822030cc792a654c8221b4544877949dd949d3e4\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<58882140.51155389.1401428197452.JavaMail.root@vmware.com>',NULL),('<1401539769.1818.16.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-31 20:36:09',28800,'2014-05-31 12:36:09',NULL,'[Openstack] Is there any in-guest agent need to be installed	on\n	OpenStack Instances?','On Sat May 31 2014 07:21:15 PM HKT, hossein zabolzadeh <zabolzadeh at gmail.com> wrote:\n\n> Hi,\n> As the topic implied, in order to have better control over the instances,\n> is there any agent software, that need to be installed on the openstack\n> virtual machines?\n> If so, what is the project name?!\n\nHi,\n\nIf you use KVM as hypervisor, there\'s no need to\ninstall any agent (while you do with Xen). However,\nyou do need cloud-init to have your instance fetch\nthings like you ssh public key from the metadata\nserver. This part has really become a standard, so\nnothing Openstack specific here.\n\nIf you want to use a simple easily hackable script,\nto build an image, I would suggest the\nopenstack-debian-images available from Debian Sid,\nTesting and Wheezy backports (disclaimer: I\'m the\nauthor od this...).\n\nCheers,\n\nthomas\n\n\n\n','<CAMadfcxsLPgyh1H-gtfx01QEgXkgPqQpF5dt8HTzvT-5ezHYtg@mail.gmail.com>',NULL),('<1401543927-sup-7850@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-31 14:47:46',3600,'2014-05-31 13:47:46',NULL,'[Openstack] Network node\'s security','Be permissive on br-ex to allow VM traffic to flow out to the internet.\nOtherwise be protective of the host address that the machine listens to.\n\nExcerpts from walterxj\'s message of 2014-05-31 13:46:24 +0100:\n> \n> \n> \n> \n> \n> \n> hi all:  The network node(s) is the only node(s) that expose to the internet,so it\'s security setting is more important,So I think it needs to be protect by iptables or firewall etc.  On the other hand,network nodes control all the vm instances\' network traffic,I have no ideas how to setting it\'s iptables rules.Is there any advices or examples to set the network node\'s iptables?\n> \n> \n> Walter Xu\n\n\n','<2014053120461680000610@gmail.com>',NULL),('<1401653391.3349.16.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-01 20:09:52',0,'2014-06-01 20:09:52',NULL,'[openstack-dev] Your suggestions in the BP','Hi Eugene and Sam,\n\nOn Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote:\n> Hi Sam,\n> \n>         Eugene, please comment on the migration process bellow.\n>         \n>         I think that closing down the \"status\" handling should be done\n>         in phase 1.\n> I don\'t mind. If you\'re talking about provisioning status then such\n> status (if we\'re still going to maintain it per each kind of object)\n> goes to various associations: loadbalancer-listener, or\n> loadbalancer-listener-pool, etc. \n> Not a big deal of course, it was just my initial intent to limit phase\n> #1 as much as possible.\n\nI was hoping to limit it as well to keep it focused on just the\nrefactoring portion.  I didn\'t want the scope to include all new\nfeatures and changes under the sun.  It also makes reviewing much\nsimpler.\n\n> \n> \n>         Missing to do so, will create tests and other depending\n>         workflows that assume the \"current\" status field, which will\n>         add  a technology debt to this new code.\n> I\'d say it would depend on the strategy options you\'re suggestion\n> below.\n> As far as bw compatibility is concerned (if it\'s concerned at all), we\n> have to support existing status field, so that would not be any\n> additional debt.\n>  \n>         \n>         Migration and co-existence:\n>         I think that it would be better to have the new object model\n>         and API done in a way that does not \"break\" existing code, and\n>         then switch the \"old\" api to redirect to the \"new\" api.\n> Basically this means creating another lbaas plugin, that expose\n> existing lbaas api extension.\n> I\'m not sure how this can be done considering the difference between\n> new proposed api and existing api.\n>  \n>         This might be done in one of the two ways bellow:\n>         1. Rename all objects in the \"new\" api so you have a clear\n>         demarcation point. This might be sufficient.\n> I\'m not sure how this could be done, can you explain?\n> I actually would consider changing the prefix to /v3/ to not to deal\n> with any renamings, that would require some minor refactoring on\n> extension framework side.\nHis suggestion in the BP was to rename pool, healthmonitor, and member\nto group, healthcheck, and node respectively.  Since loadbalancer and\nlistener are already new those don\'t have to be renamed.  This way the\nold object models and db tables remain intact and the old API can still\nfunction as before.\n>  \n>         2. Copy the existing LBaaS \"extension\" and create a\n>         \"new-lbaas\" extension with new object names, then create a\n>         \"new old lbaas\" extension that has the \"old API\" but redirect\n>         to the \"new API\"\n> I also don\'t fully understand this, please explain.\nI need more clarification on this as well.  Sounds like you\'re saying to\ncreate a lbaas extension v2 with the new object names.  Then copy the\nexisting lbaas extension and change it to redirect to the v2 extension.\nIf that is the case, why create a \"new old lbaas\" and just change the\n\"old lbaas\" extension?\n> \n> \n>         \n>         Doing 2, can allow \"co-existence\" of old code with old drivers\n>         until new code with new drivers can take its place.\n> New extension + new plugin, is that what you are suggesting? To me it\n> would be the cleanest and the most simple way to execute the\n> transition, but... i\'m not sure it was a consensus on design session.\n\nI agree this would be the cleanest but I was under the impression this\nwas not an accepted way to go.  I\'d honestly prefer a v2 extension and\nv2 plugin.  This would require different names for the object model and\ndb tables since you don\'t want the old api and new api sharing the same\ntables.  We can either append v2 to the names or rename them entirely.\nSam suggested group for pool, healthcheck for healthmonitor, and node\nfor member.  I\'d prefer nodepool for pool myself.  \n\nEither way, I need to know if we can go with this route or not.  I\'ve\nstarted on writing the code a bit but relationship conversations has\nstalled that some.  I think if we can go with this route it will make\nthe code much more clear.\n\nThanks,\nBrandon\n\n>  \n> \n> \n> Thanks,\n> Eugene.\n> \n> \n>         \n>         Regards,\n>                 -Sam.\n>         \n>         \n>         \n>         \n>         -----Original Message-----\n>         From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n>         Sent: Friday, May 30, 2014 6:38 PM\n>         To: Samuel Bercovici\n>         Subject: Your suggestions in the BP\n>         \n>         Hi Sam!\n>         \n>         Thanks for the suggestions.  I don\'t think the different\n>         statuses should be addressed in the blueprint.  I think it\n>         would be better left to have its own focus in its own\n>         blueprint.  I feel the same way about the subnet_id.  I think\n>         if this blueprint focuses just on the object model change and\n>         the migration to it, it would be better.\n>         \n>         As for having a v2 version of all the table or entirely new\n>         tables.  Are you suggesting just keeping the old API going to\n>         the old object models and database tables?  Also, if say I\n>         renamed the pool object to nodepool (I prefer that over\n>         group), then are you also suggesting the new API will have\n>         a /nodepools resource along with the object model NodePool and\n>         database table nodepool?  I\'m intrigued by this idea, but\n>         wasn\'t totally clear on what you were suggesting.\n>         \n>         Thanks,\n>         Brandon\n>         \n>         \n> \n> \n\n\n','<CAJfiwOTZdC2SdebGV=zeCv+Ce35K8F425Z52Eda8j6EPGq1MpA@mail.gmail.com>',NULL),('<1401716767.1567.6.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-02 15:46:07',7200,'2014-06-02 13:46:07',NULL,'[openstack-dev] [Ironic] Proposal for shared review dashboard','Hi folks,\n\nInspired by great work by Sean Dague [1], I have created a review\ndashboard for Ironic projects. Main ideas:\n\nOrdering:\n0. Viewer\'s own patches, that have any kind of negative feedback\n1. Specs\n2. Changes w/o negative feedback, with +2 already\n3. Changes that did not have any feedback for 5 days\n4. Changes without negative feedback (no more than 50)\n5. Other changes (no more than 20)\n\nShows only verified patches, except for 0 and 5.\nNever shows WIP patches.\n\nI\'ll be thankful for any tips on how to include prioritization from\nLaunchpad bugs.\n\nShort link: http://goo.gl/hqRrRw\nLong link: [2]\n\nSource code (will create PR after discussion on today\'s meeting): \nhttps://github.com/Divius/gerrit-dash-creator\nTo generate a link, use:\n$ ./gerrit-dash-creator dashboards/ironic.dash\n\nDmitry.\n\n[1] https://github.com/Divius/gerrit-dash-creator\n[2] https://review.openstack.org/#/dashboard/?foreach=%28project%\n3Aopenstack%2Fironic+OR+project%3Aopenstack%2Fpython-ironicclient+OR\n+project%3Aopenstack%2Fironic-python-agent+OR+project%3Aopenstack%\n2Fironic-specs%29+status%3Aopen+NOT+label%3AWorkflow%3C%3D-1+NOT+label%\n3ACode-Review%3C%3D-2+NOT+label%3AWorkflow%3E%3D1&title=Ironic+Inbox&My\n+Patches+Requiring+Attention=owner%3Aself+%28label%3AVerified-1%\n252cjenkins+OR+label%3ACode-Review-1%29&Ironic+Specs=NOT+owner%3Aself\n+project%3Aopenstack%2Fironic-specs&Needs+Approval=label%3AVerified%3E%\n3D1%252cjenkins+NOT+owner%3Aself+label%3ACode-Review%3E%3D2+NOT+label%\n3ACode-Review-1&5+Days+Without+Feedback=label%3AVerified%3E%3D1%\n252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Fironic-specs+NOT\n+label%3ACode-Review%3C%3D2+age%3A5d&No+Negative+Feedback=label%\n3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%\n2Fironic-specs+NOT+label%3ACode-Review%3C%3D-1+NOT+label%3ACode-Review%\n3E%3D2+limit%3A50&Other=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%\n3Aself+NOT+project%3Aopenstack%2Fironic-specs+label%3ACode-Review-1\n+limit%3A20\n\n\n\n\n',NULL,NULL),('<1401748370.17985.22.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-03 00:32:50',7200,'2014-06-02 22:32:50',NULL,'[OpenStack-Infra] moving Activity Board fully under openstack-ci','On Mon, 2014-06-02 at 14:31 -0700, Stefano Maffulli wrote:\n> Hello folks\n> \n> I wanted to get your thoughts on the idea to move the whole Bitergia\n> grimoire engine, scripts, database, etc to the openstack common\n> infrastructure. I\'m sure everybody will want this so the question is\n> more about resources as in people willing to help Bitergia get their\n> machinery puppetized the \"OpenStack-CI way\".\n> \n> At the moment the various spiders and scripts run on a machine on\n> Bitergia\'s end and they drop the results of the elaboration (json, html,\n> css files and sql dumps) on activity.openstack.org/dash/.\n> \n> While this setup is convenient and has been working so far, I think\n> we\'ve outgrown it. One of the areas that we want to do more with is the\n> datawarehouse built by Bitergia, enable it to serve other purposes too\n> and allow more collaboration from the community. For example, once the\n> tools are all out in one place, interested parties could build some sort\n> of service on top of your datawarehouse to export the data about the\n> affiliation. Others could build tools to \'fix\' such affiliation, pulling\n> the various mailmap files used by gitdm and stackalytics.\n> \n> The question for OpenStack-CI is then: in the next weeks/months, is\n> there going to be someone free, from the CI team or someone willing to\n> join it (Dan?), to help Bitergia\'s team get their tools on our\n> infrastructure?\n\nThanks for the introduction of the issue, Stefano.\n\nJust to clarify a bit the needs to move all the Grimoire machinery to a\nvm under openstack-ci, the software is split in three main parts:\n\n* MetricsGrimoire tools, which mine repositories (git, Launchpad, etc.),\nand store the data into a MySQL database (well, in fact, one schema per\nkind of repository).\n\n* The MySQL database itself.\n\n* The vizGrimoire tools, that run the analysis, produce JSON files, and\nthe HTML/CSS/JavaScript files needed to serve the dashboard. All of this\nis for now static, which means that you only need to serve those files\nvia HTTP, and you\'re done: no live queries to the database once the JSON\nfiles are produced.\n\nRight now, we produce the JSON files once a day. That means that\nMetricsGrimoire is first run once a day (the tools know how to get\nincremental information from repositories), data is updated in the\ndatabase, and then vizGrimoire analysis is run. All of this is\ncontrolled by automator, the tool that is configured with the list of\nrepos to analyze, the analysis to run, etc.\n\nMetricsGrimoire tools are written in Python. There are some Python\ndependencies beyond Python 2.7, but I guess all of them are\nstraightforward from pypy.\n\nThe MySQL is a plain MySQL. It would be great having it in SSD, because\nthat speeds up queries a lot. But probably it will work with regular\ndisks.\n\nMost of vizGrimoire is also Python, but there is still some R code\n(we\'re currently moving towards a pure-Python implementation). Python\nand R dependencies are easy too (from pypy or CRAN).\n\nWe\'re usually deploying on Debian or Ubuntu, but we have some experience\nwith other Linux-based OSs too.\n\nWe could do the whole deployment, if you can provide us with a\nDebian/Ubuntu vm, including proper documentation to reproduce it if\nneeded.\n\nPlease, let us know which kind of other details you may need.\n\n	Jesus.\n\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<538CED3C.9060203@openstack.org>',NULL),('<1401755029-sup-7813@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-02 17:28:10',-25200,'2014-06-03 00:28:10',NULL,'[openstack-dev] [Heat] Short term scaling strategies for large\n	Heat stacks','Excerpts from Steve Baker\'s message of 2014-06-02 14:37:25 -0700:\n> On 31/05/14 07:01, Zane Bitter wrote:\n> > On 29/05/14 19:52, Clint Byrum wrote:\n> >\n> >> update-failure-recovery\n> >> =======================\n> >>\n> >> This is a blueprint I believe Zane is working on to land in Juno. It\n> >> will\n> >> allow us to retry a failed create or update action. Combined with the\n> >> separate controller/compute node strategy, this may be our best option,\n> >> but it is unclear whether that code will be available soon or not. The\n> >> chunking is definitely required, because with 500 compute nodes, if\n> >> node #250 fails, the remaining 249 nodes that are IN_PROGRESS will be\n> >> cancelled, which makes the impact of a transient failure quite extreme.\n> >> Also without chunking, we\'ll suffer from some of the performance\n> >> problems we\'ve seen where a single engine process will have to do all of\n> >> the work to bring up a stack.\n> >>\n> >> Pros: * Uses blessed strategy\n> >>\n> >> Cons: * Implementation is not complete\n> >>       * Still suffers from heavy impact of failure\n> >>       * Requires chunking to be feasible\n> >\n> > I\'ve already started working on this and I\'m expecting to have this\n> > ready some time between the j-1 and j-2 milestones.\n> >\n> > I think these two strategies combined could probably get you a long\n> > way in the short term, though obviously they are not a replacement for\n> > the convergence strategy in the long term.\n> >\n> >\n> > BTW You missed off another strategy that we have discussed in the\n> > past, and which I think Steve Baker might(?) be working on: retrying\n> > failed calls at the client level.\n> >\n> As part of the client-plugins blueprint I\'m planning on implementing\n> retry policies on API calls. So when currently we call:\n> self.nova().servers.create(**kwargs)\n> \n> This will soon be:\n> self.client().servers.create(**kwargs)\n> \n> And with a retry policy (assuming the default unique-ish server name is\n> used):\n> self.client_plugin().call_with_retry_policy(\'cleanup_yr_mess_and_try_again\',\n> self.client().servers.create, **kwargs)\n> \n> This should be suitable for handling transient errors on API calls such\n> as 500s, response timeouts or token expiration. It shouldn\'t be used for\n> resources which later come up in an ERROR state; convergence or\n> update-failure-recovery would be better for that.\n> \n\nSteve this is fantastic work and sorely needed. Thank you for working on\nit.\n\nUnfortunately, ERROR state machines is the majority of our problem. IPMI\nand PXE can be unreliable in some environments, and sometimes machines\nare broken in subtle ways. Also, the odd bug in Neutron, Nova, or Ironic\nwill cause this.\n\nConvergence is not available to us for the short term, and really\nupdate-failure-recovery is some time off too, so we need more solutions\nunfortunately.\n\n\n','<538CEE95.7050409@redhat.com>',NULL),('<1401759713.3.1379225299523.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-15 06:08:19',0,'2013-09-15 06:08:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-grizzly #27','See <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 29 lines...]\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.j6J3aMiiIi\n+ TMPDIR=/tmp/tmp.j6J3aMiiIi\n+ trap \'rm -rf /tmp/tmp.j6J3aMiiIi\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' nova == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\njenkins.periodic.nova.python27.stable.grizzly.27\n+ tox -epy27\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires>\npy27 inst: <https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/dist/nova-jenkins.periodic.nova.python27.stable.grizzly.27.zip>\npy27 runtests: commands[0] | python tools/patch_tox_venv.py\npy27 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.j6J3aMiiIi/tmpMrZMZI\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.j6J3aMiiIi/tmpxfhpx0\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.j6J3aMiiIi/tmpHoI6sf\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.j6J3aMiiIi/tmp_Fjwzr\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\ntags: worker-2\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group dsiaw\n0.42363s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\nCreate Security Group sdeae\n0.34806s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress dsiaw\n0.86661s None GET /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual]  text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/test_api.py\",> line 582, in test_authorize_revoke_security_group_foreign_group\n    group.authorize(src_group=other_group)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group puue\n0.62255s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress puue\n0.75492s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/test_api.py\",> line 419, in test_authorize_revoke_security_group_cidr\n    group.authorize(\'tcp\', 80, 81, \'0.0.0.0/0\')\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group tptunrr\n0.52730s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress tptunrr\n0.80980s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.7.3 Linux/3.2.0-52-virtual] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/nova/tests/test_api.py\",> line 521, in test_authorize_revoke_security_group_cidr_v6\n    group.authorize(\'tcp\', 80, 81, \'::/0\')\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11310 tests in 247.183s\nFAILED (id=0, failures=5, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python27.stable.grizzly.27\nnumpy==1.7.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.11\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py27/bin/subunit-1to2\n+ .tox/py27/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.j6J3aMiiIi\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise39/27\n[SCP] Copying console log.\n\n\n','<18771395.60.1379052781994.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1401809056.3668.72.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-03 11:24:16',-14400,'2014-06-03 15:24:16',NULL,'[openstack-dev] [sahara] summit wrap-up: Future of EDP','Hi folks,\n\n  Here is a summary of priorities from Summit and some action items for\nhigh the high priority issues.  The link to the pad is here:\n\nhttps://etherpad.openstack.org/p/juno-summit-sahara-edp\n\n  We really did not have any leftover questions from summit, but we need\ninvestigation and development work in several areas.  Please respond with any \ncomments/questions, and feel free to work on action items :)\n\nHigh priority\n    Fix hive support\n    minimal EDP for spark via spark plugin (may be possible w Oozie)\n    Design pluggable job model and investigate Spark / Storm integration\n\nMedium priority\n    Error reporting improvements\n\nLow priority\n    Raw Oozie workflows\n    coordinated jobs\n    preparation tags for workflows\n    files and archives tags (need clear use cases)\n    streamline copying of job binaries from swift to hdfs (dscp)\n\nAction items for high priority issues:\n    Hive:\n        We need to flesh out existing blueprints:\n            https://blueprints.launchpad.net/sahara/+spec/hive-vanilla2-support\n            https://blueprints.launchpad.net/sahara/+spec/hive-integration-tests\n        Additional blueprint needed for swift support in Hive\n        Hive is not fully implemented in HDP plugin\n\n    Investigate Spark job execution via Oozie\n        Underway.  Produce a blueprint after initial investigation.\n\n    Design a pluggable job model\n        We need to review current EDP and think about how operations can be\n        abstracted.  For instance, what are the essential operations on a job,\n        and where has the Oozie implementation leaked knowledge into the EDP code?\n\n        Can we develop an abstraction that maps to other models in a believable way?\n           storm, spark, scalding, others\n\n        How will the UI deal with a pluggable job model assuming we have one?\n\n    \n	\n\n\n\n\n\n\n',NULL,NULL),('<1401815169.19795.3.camel@verso>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-03 12:06:09',-18000,'2014-06-03 17:06:09',NULL,'[Openstack-docs] [Openstack-i18n] Switch to itstool for docs\n translation?','On Fri, 2014-05-09 at 18:04 +0200, Andreas Jaeger wrote:\n> On 05/09/2014 05:57 PM, Andreas Jaeger wrote:\n> > On 05/09/2014 05:47 PM, Shaun McCance wrote:\n> >> [...]\n> >\n> >>> I think we need to ensure with the infra team that itstools are\n> >>> installed on our machines.\n> >>\n> >> That\'s the big question I haven\'t been able to answer yet. Preferably at\n> >> least version 2.0.1.\n> >\n> > Just talked briefly with the infra team and checked our setup:\n> >\n> > What is in Ubuntu Precise? I assume the package is not installed but if\n> > it\'s available, we can add rules to the gate machines to have it\n> > installed...\n> \n> Shaun,\n> \n> this is in precise: http://packages.ubuntu.com/precise/itstool\n> \n> This is a python package, isn\'t it? Get 2.0.1 on pypi.python.org and we \n> can install it from there...\n\nitstool 2.0.2 is now on pypi as a source package. It\'s one executable\npure python script, plus some data files. I\'m almost positive the pip\ninstall will work everywhere, but if somebody could test on non-Linux\nsystems, that would be great.\n\n--\nShaun\n\n\n\n\n','<536CFC99.2040205@suse.com>',NULL),('<1401817632.8269.10.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-03 19:47:12',7200,'2014-06-03 17:47:12',NULL,'[openstack-dev] [Ironic] Review dashboard update','Hi everyone!\n\nIt\'s hard to stop polishing things, and today I got an updated review\ndashboard. It\'s sources are merged to Sean Dague\'s repository [1], so I\nexpect this to be the final version. Thank you everyone for numerous\ncomments and suggestions, especially Ruby Loo.\n\nHere is nice link to it: http://perm.ly/ironic-review-dashboard\n\nMajor changes since previous edition:\n- \"My Patches Requiring Attention\" section - all your patches that are\neither WIP or have any -1.\n- \"Needs Reverify\" - approved changes that failed Jenkins verification\n- Added last section with changes that either WIP or got -1 from Jenkins\n(all other sections do not include these).\n- Specs section show also WIP specs\n\nI know someone requesting dashboard with IPA subproject highlighted - I\ncan do such things on case-by-case base - ping me on IRC.\n\nHope this will be helpful :)\n\nDmitry.\n\n[1] https://github.com/sdague/gerrit-dash-creator\n\n\n\n',NULL,NULL),('<1401825669.3276.25.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-03 20:01:09',0,'2014-06-03 20:01:09',NULL,'[openstack-dev]  [Neutron] Implementing new LBaaS API','This is an LBaaS topic bud I\'d like to get some Neutron Core members to\ngive their opinions on this matter so I\'ve just directed this to Neutron\nproper.\n\nThe design for the new API and object model for LBaaS needs to be locked\ndown before the hackathon in a couple of weeks and there are some\nquestions that need answered.  This is pretty urgent to come on to a\ndecision on and to get a clear strategy defined so we can actually do\nreal code during the hackathon instead of wasting some of that valuable\ntime discussing this.\n\n\nImplementation must be backwards compatible\n\nThere are 2 ways that have come up on how to do this:\n\n1) New API and object model are created in the same extension and plugin\nas the old.  Any API requests structured for the old API will be\ntranslated/adapted to the into the new object model.\nPROS:\n-Only one extension and plugin\n-Mostly true backwards compatibility\n-Do not have to rename unchanged resources and models\nCONS:\n-May end up being confusing to an end-user.\n-Separation of old api and new api is less clear\n-Deprecating and removing old api and object model will take a bit more\nwork\n-This is basically API versioning the wrong way\n\n2) A new extension and plugin are created for the new API and object\nmodel.  Each API would live side by side.  New API would need to have\ndifferent names for resources and object models from Old API resources\nand object models.\nPROS:\n-Clean demarcation point between old and new\n-No translation layer needed\n-Do not need to modify existing API and object model, no new bugs\n-Drivers do not need to be immediately modified\n-Easy to deprecate and remove old API and object model later\nCONS:\n-Separate extensions and object model will be confusing to end-users\n-Code reuse by copy paste since old extension and plugin will be\ndeprecated and removed.\n-This is basically API versioning the wrong way\n\nNow if #2 is chosen to be feasible and acceptable then there are a\nnumber of ways to actually do that.  I won\'t bring those up until a\nclear decision is made on which strategy above is the most acceptable.\n\nThanks,\nBrandon\n\n\n\n\n\n\n\n','<2B7FB137-D0E7-4267-A400-0E63DB656EDB@lab.ntt.co.jp>',NULL),('<1401827977.3570.7.camel@virtbox>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-03 20:39:39',0,'2014-06-03 20:39:39',NULL,'[OpenStack-Infra] moving Activity Board fully under openstack-ci','Stef,\n\nOn Mon, 2014-06-02 at 14:31 -0700, Stefano Maffulli wrote:\n> ...\n> The question for OpenStack-CI is then: in the next weeks/months, is\n> there going to be someone free, from the CI team or someone willing to\n> join it (Dan?), to help Bitergia\'s team get their tools on our\n> infrastructure?\n\nMy impression from the recent \"Replace Launchpad OpenID authentication\"\ndesign summit session (see https://etherpad.openstack.org/p/juno-openid)\nwas that infra would prefer that the Foundation create new blueprints to\ntrack and respond to these kinds of requests for resources / integration\nwork.\n\nSpeaking for myself at least, I\'m neither an expert in the \"OpenStack-CI\nway\", nor the *grimoire toolset.  I would love to help any way I can,\nbut leading the effort is probably not for me to do.\n\nDan\n\n','<538CED3C.9060203@openstack.org>',NULL),('<1401841032.55453.YahooMailNeo@web125904.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-03 17:17:12',-25200,'2014-06-04 00:17:12',NULL,'[Openstack-docs] Training Guides becoming a project in its own\n	right?','We are starting to hit some questions that I do not have ready answers to.?\n	* where to store the data: Tom and I were initially thinking stackforge before incubation. move under the openstack repo org after incubation as training-guides. fungi and jeblair are questioning a stackforge project publishing to docs.openstack.org rather than just openstack-manuals. I do not have a great answer other than I believe Anne is good with that for now. If the docs PTL and team is okay with this, do I need to ask the TC as well?\n	* where to house the project: I would like it to stay under the documentation program. Any other ideas?\n\nFind here the all the incubation plan Q&A using the latest TC requirements\nhttps://wiki.openstack.org/wiki/Training-guides#Incubation_Plan\n\n?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\nOn Thursday, May 29, 2014 6:14 PM, Tom Fifield <tom at openstack.org> wrote:\n \n\n\nOn 30/05/14 01:40, Anne Gentle wrote:\n>\n>\n>\n> On Wed, May 28, 2014 at 9:56 PM, Tom Fifield <tom at openstack.org\n> <mailto:tom at openstack.org>> wrote:\n>\n>? ?  Hi,\n>\n>? ?  Sean Roberts, Stefano and I just had a very fruitful discussion\n>? ?  regarding the training manuals project.\n>\n>\n> Thanks you all for discussing.\n>\n>\n>? ?  We think that it\'s time to allow the the training guides to become a\n>? ?  free-standing project of its own accord, and start attracting\n>? ?  significantly more people around it.\n>\n>\n>? ?  This will make it easier for contributors who just want to work on\n>? ?  training to find the project, see lists of bugs and tasks relevant\n>? ?  to them*, and also provide a clearer pathway toward becoming\n>? ?  contributors, and eventually core reviewers.\n>\n>? ?  It will also enable the training guides project to have its own\n>? ?  policies, and allow the repository to be used for investigation of\n>? ?  training infrastructure, such as the recent forays into moodle for\n>? ?  example.\n>\n>? ?  However, with every change such as this, there are drawbacks, and so\n>? ?  we feel it\'s important to discuss these as well - and most\n>? ?  importantly get your input.\n>\n>? ?  For example, while we can continue to re-use tools and content, this\n>? ?  would mean a different review queue and repository - which could\n>? ?  frustrate if you are working across both projects.\n>\n>\n> I hope the intention is to continue to use inclusion of known tested\n> content from the various other OpenStack repos as needed.\n\nYup, that\'s the case.\n\n>\n>? ?  What are your thoughts?\n>\n>\n> Sounds great to me. Thanks all!\n> Anne\n>\n>\n>\n>? ?  Regards,\n>\n>\n>\n>? ?  Tom\n>\n>\n>? ?  * as opposed to the 400 odd in the openstack-manuals tracker!\n>\n>? ?  _________________________________________________\n>? ?  Openstack-docs mailing list\n>? ? Openstack-docs at lists.__openstack.org\n>? ?  <mailto:Openstack-docs at lists.openstack.org>\n\n>? ? http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-docs\n>? ?  <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs>\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140603/38b8efae/attachment-0001.html>\n\n','<5387DB7A.5070502@openstack.org>',NULL),('<1401863694-sup-3319@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-03 23:36:24',-25200,'2014-06-04 06:36:24',NULL,'[openstack-dev] [ironic bare metal installation issue]','Excerpts from ??\'s message of 2014-06-03 21:23:25 -0700:\n> Hi, All :\n>         I\'ve deployed my ironic following this link:\n> http://ma.ttwagner.com/bare-metal-deploys-with-devstack-and-ironic/ , all\n> steps is completed.\n>         Now one of my node-show provision_state is active. But why is this\n> node still in installation state as follow ?\n>          [image: ???? 1]\n\n\nIronic has done all that it can for the machine. That is the kernel\nand ramdisk from the image, and Ironic has no real way to check that\nthis deploy succeeds. It is on the same level as checking to see if your\nVM actually boots after kvm has been spawned.\n\n\n','<CALAMvO9Bct98CzjzvJ=DZpaMLyVpmQYQSHZK4iEU6fDe2=W=TQ@mail.gmail.com>',NULL),('<1401865588-sup-6482@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 00:09:39',-25200,'2014-06-04 07:09:39',NULL,'[openstack-dev] [Spam]  [heat] Resource action API','Excerpts from yang zhang\'s message of 2014-06-04 00:01:41 -0700:\n> \n> \n> \n> \n> \n> \n> Hi all,   Now heat only supports suspending/resuming a whole stack, all the resources of the stack will be suspended/resumed,but sometime we just want to suspend or resume only a part of resources in the stack, so I think adding resource-action API for heat isnecessary. this API will be helpful to solve 2 problems:    - If we want to suspend/resume the resources of the stack, you need to get the phy_id first and then call the API of other services, and this won\'t update the statusof the resource in heat, which often cause some unexpected problem.    - this API could offer a turn on/off function for some native resources, e.g., we can turn on/off the autoscalinggroup or a single policy with the API, this is like the suspend/resume services feature[1] in AWS.   I registered a bp for it, and you are welcome for discussing it.        https://blueprints.launchpad.net/heat/+spec/resource-action-api\n> [1]  http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html\n> Regards!Zhang Yang\n\nHi zhang. I\'d rather we model the intended states of each resource, and\nensure that Heat can assert them. Actions are tricky things to model.\n\nSo if you want your nova server to be stopped, how about\n\nresources:\n  server1:\n    type: OS::Nova::Server\n    properties:\n      flavor: superbig\n      image: TheBestOS\n      state: STOPPED\n\nWe don\'t really need to model \"actions\" then, just the API\'s we have\navailable.\n\n\n','<BAY182-W822CB6A0F0E21701E9748884220@phx.gbl>',NULL),('<1401870529-sup-2379@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 01:29:37',-25200,'2014-06-04 08:29:37',NULL,'[openstack-dev] [Spam] Re:  [Spam] [heat] Resource action API','Excerpts from yang zhang\'s message of 2014-06-04 01:14:37 -0700:\n> \n> > From: clint at fewbar.com\n> > To: openstack-dev at lists.openstack.org\n> > Date: Wed, 4 Jun 2014 00:09:39 -0700\n> > Subject: Re: [openstack-dev] [Spam]  [heat] Resource action API\n> > \n> > Excerpts from yang zhang\'s message of 2014-06-04 00:01:41 -0700:\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > \n> > > Hi all,   Now heat only supports suspending/resuming a whole stack, all the resources of the stack will be suspended/resumed,but sometime we just want to suspend or resume only a part of resources in the stack, so I think adding resource-action API for heat isnecessary. this API will be helpful to solve 2 problems:    - If we want to suspend/resume the resources of the stack, you need to get the phy_id first and then call the API of other services, and this won\'t update the statusof the resource in heat, which often cause some unexpected problem.    - this API could offer a turn on/off function for some native resources, e.g., we can turn on/off the autoscalinggroup or a single policy with the API, this is like the suspend/resume services feature[1] in AWS.   I registered a bp for it, and you are welcome for discussing it.        https://blueprints.launchpad.net/heat/+spec/resource-action-api\n> > > [1]  http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html\n> > > Regards!Zhang Yang\n> > \n> > Hi zhang. I\'d rather we model the intended states of each resource, and\n> > ensure that Heat can assert them. Actions are tricky things to model.\n> > \n> > So if you want your nova server to be stopped, how about\n> > \n> > resources:\n> >   server1:\n> >     type: OS::Nova::Server\n> >     properties:\n> >       flavor: superbig\n> >       image: TheBestOS\n> >       state: STOPPED> > We don\'t really need to model \"actions\" then, just the API\'s we have\n> > available.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> At first, I want to do it like this, using a resource parameter, but this need to update the stack  in order to suspend the Resource, It means we can\'t stop another resource when a resource is stopping, but it seems not a big deal, stopping resource usually is soon, compare to API,  using resource parameter is easy to implement as the result of mature code of stack-update, we could finish it in a short period. \n> Does anyone else have good ideas?\n> \n\nIt\'s a bit far off, but the eventual goal of the convergence effort is\nto make it so you _can_ update two things concurrently, since updates\nwill just be recording intended state in the db, not waiting for all of\nthat to complete.\n\n\n','<BAY182-W85165DBCB083C9DDCED2F284220@phx.gbl>',NULL),('<1401881781.18462.2.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 13:36:21',7200,'2014-06-04 11:36:21',NULL,'[openstack-dev] [ironic workflow question]','Hi!\n\nWorkflow is not entirely documented by now AFAIK. After PXE boots deploy\nkernel and ramdisk, it exposes hard drive via iSCSI and notifies Ironic.\nAfter that Ironic partitions the disk, copies an image and reboots node\nwith final kernel and ramdisk.\n\nOn Wed, 2014-06-04 at 19:20 +0800, ?? wrote:\n> Hi, All:\n> \n>         I searched a lot about how ironic automatically install image\n> on bare metal. But there seems to be no clear workflow out there.\n> \n>         What I know is, in traditional PXE, a bare metal pull image\n> from PXE server using tftp. In tftp root, there is a ks.conf which\n> tells tftp which image to kick start.\n> \n>         But in ironic there is no ks.conf pointed in tftp. How do bare\n> metal know which image to install ? Is there any clear workflow where\n> I can read ?\n> \n>         \n> \n> \n> Best Regards?\n> Chao Yan\n> --------------\n> My twitter?Andy Yan @yanchao727\n> My Weibo?http://weibo.com/herewearenow\n> --------------\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CALAMvO-ZmdL9SbAhqqLZKRadyDPEzxjb2i49H3SMc6O2LxsVZA@mail.gmail.com>',NULL),('<1401886843.18462.7.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 15:00:43',7200,'2014-06-04 13:00:43',NULL,'[openstack-dev] [ironic workflow question]','On Wed, 2014-06-04 at 20:29 +0800, ?? wrote:\n> Hi,\n> \n> Thank you very much for your reply !\n> \n> But there are still some questions for me. Now I\'ve come to the step\n> where ironic partitions the disk as you replied.\n> \n> Then, how does ironic copies an image ? I know the image comes from\n> glance. But how to know image is really available when reboot? \nI don\'t quite understand your question, what do you mean by \"available\"?\nAnyway, before deploying Ironic downloads image from Glance, caches it\nand just copies to a mounted iSCSI partition (using dd or so).\n\n> \n> And, what are the differences between final kernel (ramdisk) and\n> original kernel (ramdisk) ? \nWe have 2 sets of kernel+ramdisk:\n1. Deploy k+r: these are used only for deploy process itself to provide\niSCSI volume and call back to Ironic. There\'s ongoing effort to create\nsmarted ramdisk, called Ironic Python Agent, but it\'s WIP.\n2. Your k+r as stated in Glance metadata for an image - they will be\nused for booting after deployment.\n\n> \n> Best Regards?\n> Chao Yan\n> --------------\n> My twitter?Andy Yan @yanchao727\n> My Weibo?http://weibo.com/herewearenow\n> --------------\n> \n> \n> \n> 2014-06-04 19:36 GMT+08:00 Dmitry Tantsur <dtantsur at redhat.com>:\n>         Hi!\n>         \n>         Workflow is not entirely documented by now AFAIK. After PXE\n>         boots deploy\n>         kernel and ramdisk, it exposes hard drive via iSCSI and\n>         notifies Ironic.\n>         After that Ironic partitions the disk, copies an image and\n>         reboots node\n>         with final kernel and ramdisk.\n>         \n>         On Wed, 2014-06-04 at 19:20 +0800, ?? wrote:\n>         > Hi, All:\n>         >\n>         >         I searched a lot about how ironic automatically\n>         install image\n>         > on bare metal. But there seems to be no clear workflow out\n>         there.\n>         >\n>         >         What I know is, in traditional PXE, a bare metal\n>         pull image\n>         > from PXE server using tftp. In tftp root, there is a ks.conf\n>         which\n>         > tells tftp which image to kick start.\n>         >\n>         >         But in ironic there is no ks.conf pointed in tftp.\n>         How do bare\n>         > metal know which image to install ? Is there any clear\n>         workflow where\n>         > I can read ?\n>         >\n>         >\n>         >\n>         >\n>         > Best Regards?\n>         > Chao Yan\n>         > --------------\n>         > My twitter?Andy Yan @yanchao727\n>         > My Weibo?http://weibo.com/herewearenow\n>         > --------------\n>         >\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CALAMvO9gjzPFDNkM71MSVUZ6+t0KuK4V3aCUTnWWeUN2v3pr8Q@mail.gmail.com>',NULL),('<1401888426.18462.10.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 15:27:06',7200,'2014-06-04 13:27:06',NULL,'[openstack-dev] [ironic workflow question]','On Wed, 2014-06-04 at 21:18 +0800, ?? wrote:\n> Thank you !\n> \n> I noticed the two sets of k+r in tftp configuration of ironic.\n> \n> Should the two sets be the same k+r ?\nDeploy images are created for you by DevStack/whatever. If you do it by\nhand, you may use diskimage-builder. Currently they are stored in flavor\nmetadata, will be stored in node metadata later.\n\nAnd than you have \"production\" images that are whatever you want to\ndeploy and they are stored in Glance metadata for the instance image.\n\nTFTP configuration should be created automatically, I doubt you should\nchange it anyway.\n\n> \n> The first set is defined in the ironic node definition. \n> \n> How do we define the second set correctly ? \n> \n> Best Regards?\n> Chao Yan\n> --------------\n> My twitter?Andy Yan @yanchao727\n> My Weibo?http://weibo.com/herewearenow\n> --------------\n> \n> \n> \n> 2014-06-04 21:00 GMT+08:00 Dmitry Tantsur <dtantsur at redhat.com>:\n>         On Wed, 2014-06-04 at 20:29 +0800, ?? wrote:\n>         > Hi,\n>         >\n>         > Thank you very much for your reply !\n>         >\n>         > But there are still some questions for me. Now I\'ve come to\n>         the step\n>         > where ironic partitions the disk as you replied.\n>         >\n>         > Then, how does ironic copies an image ? I know the image\n>         comes from\n>         > glance. But how to know image is really available when\n>         reboot?\n>         \n>         I don\'t quite understand your question, what do you mean by\n>         \"available\"?\n>         Anyway, before deploying Ironic downloads image from Glance,\n>         caches it\n>         and just copies to a mounted iSCSI partition (using dd or so).\n>         \n>         >\n>         > And, what are the differences between final kernel (ramdisk)\n>         and\n>         > original kernel (ramdisk) ?\n>         \n>         We have 2 sets of kernel+ramdisk:\n>         1. Deploy k+r: these are used only for deploy process itself\n>         to provide\n>         iSCSI volume and call back to Ironic. There\'s ongoing effort\n>         to create\n>         smarted ramdisk, called Ironic Python Agent, but it\'s WIP.\n>         2. Your k+r as stated in Glance metadata for an image - they\n>         will be\n>         used for booting after deployment.\n>         \n>         >\n>         > Best Regards?\n>         > Chao Yan\n>         > --------------\n>         > My twitter?Andy Yan @yanchao727\n>         > My Weibo?http://weibo.com/herewearenow\n>         > --------------\n>         >\n>         >\n>         >\n>         > 2014-06-04 19:36 GMT+08:00 Dmitry Tantsur\n>         <dtantsur at redhat.com>:\n>         >         Hi!\n>         >\n>         >         Workflow is not entirely documented by now AFAIK.\n>         After PXE\n>         >         boots deploy\n>         >         kernel and ramdisk, it exposes hard drive via iSCSI\n>         and\n>         >         notifies Ironic.\n>         >         After that Ironic partitions the disk, copies an\n>         image and\n>         >         reboots node\n>         >         with final kernel and ramdisk.\n>         >\n>         >         On Wed, 2014-06-04 at 19:20 +0800, ?? wrote:\n>         >         > Hi, All:\n>         >         >\n>         >         >         I searched a lot about how ironic\n>         automatically\n>         >         install image\n>         >         > on bare metal. But there seems to be no clear\n>         workflow out\n>         >         there.\n>         >         >\n>         >         >         What I know is, in traditional PXE, a bare\n>         metal\n>         >         pull image\n>         >         > from PXE server using tftp. In tftp root, there is\n>         a ks.conf\n>         >         which\n>         >         > tells tftp which image to kick start.\n>         >         >\n>         >         >         But in ironic there is no ks.conf pointed\n>         in tftp.\n>         >         How do bare\n>         >         > metal know which image to install ? Is there any\n>         clear\n>         >         workflow where\n>         >         > I can read ?\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         >         > Best Regards?\n>         >         > Chao Yan\n>         >         > --------------\n>         >         > My twitter?Andy Yan @yanchao727\n>         >         > My Weibo?http://weibo.com/herewearenow\n>         >         > --------------\n>         >         >\n>         >\n>         >         > _______________________________________________\n>         >         > OpenStack-dev mailing list\n>         >         > OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CALAMvO-mt0P8LE6HZgCzRNnqp7Z1O6pZLbWMOTET1mZnCP+oog@mail.gmail.com>',NULL),('<1401890780.18462.16.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 16:06:20',7200,'2014-06-04 14:06:20',NULL,'[openstack-dev] [ironic workflow question]','On Wed, 2014-06-04 at 21:51 +0800, ?? wrote:\n> Yes, but when you assign a \"production\" image to an ironic bare metal\n> node. You should provide ramdisk_id and kernel_id. \nWhat do you mean by \"assign\" here? Could you quote some documentation?\nInstance image is \"assigned\" using --image argument to `nova boot`, k&r\nare fetched from it\'s metadata.\n\nDeploy k&r are currently taken from flavor provided by --flavor argument\n(this will change eventually).\nIf you\'re using e.g. DevStack, you don\'t even touch deploy k&r, they\'re\nbound to flavor \"baremetal\".\n\nPlease see quick start guide for hints on this:\nhttp://docs.openstack.org/developer/ironic/dev/dev-quickstart.html\n\n> \n> Should the ramdisk_id and kernel_id be the same as deploy images (aka\n> the first set of k+r) ?\n> \n> You didn\'t answer me if the two sets of r + k should be the same ? \n> \n> \n> Best Regards?\n> Chao Yan\n> --------------\n> My twitter?Andy Yan @yanchao727\n> My Weibo?http://weibo.com/herewearenow\n> --------------\n> \n> \n> \n> 2014-06-04 21:27 GMT+08:00 Dmitry Tantsur <dtantsur at redhat.com>:\n>         On Wed, 2014-06-04 at 21:18 +0800, ?? wrote:\n>         > Thank you !\n>         >\n>         > I noticed the two sets of k+r in tftp configuration of\n>         ironic.\n>         >\n>         > Should the two sets be the same k+r ?\n>         \n>         Deploy images are created for you by DevStack/whatever. If you\n>         do it by\n>         hand, you may use diskimage-builder. Currently they are stored\n>         in flavor\n>         metadata, will be stored in node metadata later.\n>         \n>         And than you have \"production\" images that are whatever you\n>         want to\n>         deploy and they are stored in Glance metadata for the instance\n>         image.\n>         \n>         TFTP configuration should be created automatically, I doubt\n>         you should\n>         change it anyway.\n>         \n>         >\n>         > The first set is defined in the ironic node definition.\n>         >\n>         > How do we define the second set correctly ?\n>         >\n>         > Best Regards?\n>         > Chao Yan\n>         > --------------\n>         > My twitter?Andy Yan @yanchao727\n>         > My Weibo?http://weibo.com/herewearenow\n>         > --------------\n>         >\n>         >\n>         >\n>         > 2014-06-04 21:00 GMT+08:00 Dmitry Tantsur\n>         <dtantsur at redhat.com>:\n>         >         On Wed, 2014-06-04 at 20:29 +0800, ?? wrote:\n>         >         > Hi,\n>         >         >\n>         >         > Thank you very much for your reply !\n>         >         >\n>         >         > But there are still some questions for me. Now\n>         I\'ve come to\n>         >         the step\n>         >         > where ironic partitions the disk as you replied.\n>         >         >\n>         >         > Then, how does ironic copies an image ? I know the\n>         image\n>         >         comes from\n>         >         > glance. But how to know image is really available\n>         when\n>         >         reboot?\n>         >\n>         >         I don\'t quite understand your question, what do you\n>         mean by\n>         >         \"available\"?\n>         >         Anyway, before deploying Ironic downloads image from\n>         Glance,\n>         >         caches it\n>         >         and just copies to a mounted iSCSI partition (using\n>         dd or so).\n>         >\n>         >         >\n>         >         > And, what are the differences between final kernel\n>         (ramdisk)\n>         >         and\n>         >         > original kernel (ramdisk) ?\n>         >\n>         >         We have 2 sets of kernel+ramdisk:\n>         >         1. Deploy k+r: these are used only for deploy\n>         process itself\n>         >         to provide\n>         >         iSCSI volume and call back to Ironic. There\'s\n>         ongoing effort\n>         >         to create\n>         >         smarted ramdisk, called Ironic Python Agent, but\n>         it\'s WIP.\n>         >         2. Your k+r as stated in Glance metadata for an\n>         image - they\n>         >         will be\n>         >         used for booting after deployment.\n>         >\n>         >         >\n>         >         > Best Regards?\n>         >         > Chao Yan\n>         >         > --------------\n>         >         > My twitter?Andy Yan @yanchao727\n>         >         > My Weibo?http://weibo.com/herewearenow\n>         >         > --------------\n>         >         >\n>         >         >\n>         >         >\n>         >         > 2014-06-04 19:36 GMT+08:00 Dmitry Tantsur\n>         >         <dtantsur at redhat.com>:\n>         >         >         Hi!\n>         >         >\n>         >         >         Workflow is not entirely documented by now\n>         AFAIK.\n>         >         After PXE\n>         >         >         boots deploy\n>         >         >         kernel and ramdisk, it exposes hard drive\n>         via iSCSI\n>         >         and\n>         >         >         notifies Ironic.\n>         >         >         After that Ironic partitions the disk,\n>         copies an\n>         >         image and\n>         >         >         reboots node\n>         >         >         with final kernel and ramdisk.\n>         >         >\n>         >         >         On Wed, 2014-06-04 at 19:20 +0800, ??\n>         wrote:\n>         >         >         > Hi, All:\n>         >         >         >\n>         >         >         >         I searched a lot about how\n>         ironic\n>         >         automatically\n>         >         >         install image\n>         >         >         > on bare metal. But there seems to be no\n>         clear\n>         >         workflow out\n>         >         >         there.\n>         >         >         >\n>         >         >         >         What I know is, in traditional\n>         PXE, a bare\n>         >         metal\n>         >         >         pull image\n>         >         >         > from PXE server using tftp. In tftp\n>         root, there is\n>         >         a ks.conf\n>         >         >         which\n>         >         >         > tells tftp which image to kick start.\n>         >         >         >\n>         >         >         >         But in ironic there is no\n>         ks.conf pointed\n>         >         in tftp.\n>         >         >         How do bare\n>         >         >         > metal know which image to install ? Is\n>         there any\n>         >         clear\n>         >         >         workflow where\n>         >         >         > I can read ?\n>         >         >         >\n>         >         >         >\n>         >         >         >\n>         >         >         >\n>         >         >         > Best Regards?\n>         >         >         > Chao Yan\n>         >         >         > --------------\n>         >         >         > My twitter?Andy Yan @yanchao727\n>         >         >         > My Weibo?http://weibo.com/herewearenow\n>         >         >         > --------------\n>         >         >         >\n>         >         >\n>         >         >         >\n>         _______________________________________________\n>         >         >         > OpenStack-dev mailing list\n>         >         >         > OpenStack-dev at lists.openstack.org\n>         >         >         >\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         _______________________________________________\n>         >         >         OpenStack-dev mailing list\n>         >         >         OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >         >\n>         >         >\n>         >         > _______________________________________________\n>         >         > OpenStack-dev mailing list\n>         >         > OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CALAMvO9beTQZ4PROAbq+SrXk=+RxGa5Eece4mm74qa4P+g51OA@mail.gmail.com>',NULL),('<1401902257.3955.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 17:17:37',0,'2014-06-04 17:17:37',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Thanks for your feedback Kyle.  I will be at that meeting on Monday.\n\nThanks,\nBrandon\n\nOn Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n> On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n> > This is an LBaaS topic bud I\'d like to get some Neutron Core members to\n> > give their opinions on this matter so I\'ve just directed this to Neutron\n> > proper.\n> >\n> > The design for the new API and object model for LBaaS needs to be locked\n> > down before the hackathon in a couple of weeks and there are some\n> > questions that need answered.  This is pretty urgent to come on to a\n> > decision on and to get a clear strategy defined so we can actually do\n> > real code during the hackathon instead of wasting some of that valuable\n> > time discussing this.\n> >\n> >\n> > Implementation must be backwards compatible\n> >\n> > There are 2 ways that have come up on how to do this:\n> >\n> > 1) New API and object model are created in the same extension and plugin\n> > as the old.  Any API requests structured for the old API will be\n> > translated/adapted to the into the new object model.\n> > PROS:\n> > -Only one extension and plugin\n> > -Mostly true backwards compatibility\n> > -Do not have to rename unchanged resources and models\n> > CONS:\n> > -May end up being confusing to an end-user.\n> > -Separation of old api and new api is less clear\n> > -Deprecating and removing old api and object model will take a bit more\n> > work\n> > -This is basically API versioning the wrong way\n> >\n> > 2) A new extension and plugin are created for the new API and object\n> > model.  Each API would live side by side.  New API would need to have\n> > different names for resources and object models from Old API resources\n> > and object models.\n> > PROS:\n> > -Clean demarcation point between old and new\n> > -No translation layer needed\n> > -Do not need to modify existing API and object model, no new bugs\n> > -Drivers do not need to be immediately modified\n> > -Easy to deprecate and remove old API and object model later\n> > CONS:\n> > -Separate extensions and object model will be confusing to end-users\n> > -Code reuse by copy paste since old extension and plugin will be\n> > deprecated and removed.\n> > -This is basically API versioning the wrong way\n> >\n> > Now if #2 is chosen to be feasible and acceptable then there are a\n> > number of ways to actually do that.  I won\'t bring those up until a\n> > clear decision is made on which strategy above is the most acceptable.\n> >\n> Thanks for sending this out Brandon. I\'m in favor of option #2 above,\n> especially considering the long-term plans to remove LBaaS from\n> Neutron. That approach will help the eventual end goal there. I am\n> also curious on what others think, and to this end, I\'ve added this as\n> an agenda item for the team meeting next Monday. Brandon, it would be\n> great to get you there for the part of the meeting where we\'ll discuss\n> this.\n> \n> Thanks!\n> Kyle\n> \n> > Thanks,\n> > Brandon\n> >\n> >\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi25uDisytyEaH-_B+c0PKjy+Qe9k4o0fpSAjYThvfjkLg@mail.gmail.com>',NULL),('<1401917272.3236.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 21:27:52',0,'2014-06-04 21:27:52',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Hi Andres,\nI\'ve assumed (and we know how assumptions work) that the deprecation\nwould take place in Juno and after a cyle or two it would totally be\nremoved from the code.  Even if #1 is the way to go, the old /vips\nresource would be deprecated in favor of /loadbalancers and /listeners.\n\nI agree #2 is cleaner, but I don\'t want to start on an implementation\n(though I kind of already have) that will fail to be merged in because\nof the strategy.  The strategies are pretty different so one needs to be\ndecided on.\n\nAs for where LBaaS is intended to end up, I don\'t want to speak for\nKyle, so this is my understanding; It will end up outside of the Neutron\ncode base but Neutron and LBaaS and other services will all fall under a\nNetworking (or Network) program.  That is my understanding and I could\nbe totally wrong.\n\nThanks,\nBrandon\n\nOn Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:\n> Hi Brandon, hi Kyle!\n> I\'m a bit confused about the deprecation (btw, thanks for sending this Brandon!), as I (wrongly) assumed #1 would be the chosen path for the new API implementation. I understand the proposal and #2 sounds actually cleaner. \n> \n> Just out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from Neutron?\n> \n> (Nit question, I must clarify)\n> \n> Thank you!\n> Andres\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \n> Sent: Wednesday, June 04, 2014 2:18 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n> \n> Thanks for your feedback Kyle.  I will be at that meeting on Monday.\n> \n> Thanks,\n> Brandon\n> \n> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan \n> > <brandon.logan at rackspace.com> wrote:\n> > > This is an LBaaS topic bud I\'d like to get some Neutron Core members \n> > > to give their opinions on this matter so I\'ve just directed this to \n> > > Neutron proper.\n> > >\n> > > The design for the new API and object model for LBaaS needs to be \n> > > locked down before the hackathon in a couple of weeks and there are \n> > > some questions that need answered.  This is pretty urgent to come on \n> > > to a decision on and to get a clear strategy defined so we can \n> > > actually do real code during the hackathon instead of wasting some \n> > > of that valuable time discussing this.\n> > >\n> > >\n> > > Implementation must be backwards compatible\n> > >\n> > > There are 2 ways that have come up on how to do this:\n> > >\n> > > 1) New API and object model are created in the same extension and \n> > > plugin as the old.  Any API requests structured for the old API will \n> > > be translated/adapted to the into the new object model.\n> > > PROS:\n> > > -Only one extension and plugin\n> > > -Mostly true backwards compatibility -Do not have to rename \n> > > unchanged resources and models\n> > > CONS:\n> > > -May end up being confusing to an end-user.\n> > > -Separation of old api and new api is less clear -Deprecating and \n> > > removing old api and object model will take a bit more work -This is \n> > > basically API versioning the wrong way\n> > >\n> > > 2) A new extension and plugin are created for the new API and object \n> > > model.  Each API would live side by side.  New API would need to \n> > > have different names for resources and object models from Old API \n> > > resources and object models.\n> > > PROS:\n> > > -Clean demarcation point between old and new -No translation layer \n> > > needed -Do not need to modify existing API and object model, no new \n> > > bugs -Drivers do not need to be immediately modified -Easy to \n> > > deprecate and remove old API and object model later\n> > > CONS:\n> > > -Separate extensions and object model will be confusing to end-users \n> > > -Code reuse by copy paste since old extension and plugin will be \n> > > deprecated and removed.\n> > > -This is basically API versioning the wrong way\n> > >\n> > > Now if #2 is chosen to be feasible and acceptable then there are a \n> > > number of ways to actually do that.  I won\'t bring those up until a \n> > > clear decision is made on which strategy above is the most acceptable.\n> > >\n> > Thanks for sending this out Brandon. I\'m in favor of option #2 above, \n> > especially considering the long-term plans to remove LBaaS from \n> > Neutron. That approach will help the eventual end goal there. I am \n> > also curious on what others think, and to this end, I\'ve added this as \n> > an agenda item for the team meeting next Monday. Brandon, it would be \n> > great to get you there for the part of the meeting where we\'ll discuss \n> > this.\n> > \n> > Thanks!\n> > Kyle\n> > \n> > > Thanks,\n> > > Brandon\n> > >\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0AC7A1AE4CF0F441BFB83181010D122F299FF45F@fmsmsx115.amr.corp.intel.com>',NULL),('<1401917475.24832.52.camel@tykes-place.bardicgrove.org>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-04 14:31:15',-25200,'2014-06-04 21:31:15',NULL,'[OpenStack-Infra] Update to OpenDaylight Jenkins user','I received a request from one of my OpenDaylight / OpenStack devs (Kyle\nMestery) informing me that we\'re being asked to update the display name\nof our CI system (currently it\'s \'OpenDaylight Jenkins\').\n\nWhen I had originally requested a stream access [1] account I had\nprovided just a preferred username (odl-jenkins), email address\n(odl-openstack at opendaylight.org) & SSH pubkey.\n\nUnfortunately my local records were not clear and I couldn\'t remember\nwhat exactly I had done and forgot that a user hadn\'t been created\ndirectly in LaunchPad and so I went and did that and I\'ve also attached\nthe same email address. Of course, logging in to Gerrit using that\naccount won\'t allow me to configure that account to have the uid of\nodl-jenkins. Could I get some help to merge the two gerrit accounts that\nnow exist?\n\nThe first one is identified as a full name of \'OpenDaylight Jenkins\',\nemail address: odl-openstack at opendaylight.org and has an SSH pubkey of\n\'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAztcqByxj\n+6H3Vb78ZZN8FTbritMUBssYGxNdjdbhYJk60hQq/D4adWf4RAf3F6FGKhWCZAqPMdHFyZNjHsWUJJZGs68B0fA/jnlU1CQTeD3cf2olgXYE8X/h1c1LW1iPYndFm8JSmz3b8FigIcMEekTxlQzLOtToWoUPiLkrG/esk1lUd2FUapEay03iId9cERSTBtiAGVzw5K5E5HYotzriQnugcOkTxQilbXNBbg+m1YshC7wFlGHpOQHTtG+BhznXtmlFRXQTcOiwtp5f9PJgIyzeOMNN45i/Dbl4lAQpTqf/OklMh4CSK+LaHlJ1MgaKfb5Qk3NXdGTsKhOGvQ== odl-jenkins at opendaylight.org\'\n\nThis account is in the \'Voting Third-Party CI\' group. As there is no\nLaunchPad ID attached to it I can\'t get in to modify the display / full\nname.\n\nThe newly created account is account_id 11779\n\nWith a Full Name of \'OpenDaylight CI\' (what I\'ve been asked to change\nthe display name to), email address of odl-openstack at opendaylight.org,\nsame SSH pubkey. This account has a launchpad identity associated with\nit.\n\nIf I could get the accounts merged that would be helpful so that I can\nmanage the display name as requested.\n\n[1]\nhttp://lists.openstack.org/pipermail/openstack-infra/2014-February/000803.html\n\nThanks,\n-Andy-\n\n-- \nAndrew J Grimberg\nSystems Administrator\nThe Linux Foundation\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140604/206f025e/attachment.pgp>\n\n',NULL,NULL),('<1401925044-sup-7929@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 17:05:10',-25200,'2014-06-05 00:05:10',NULL,'[openstack-dev] [Heat]Heat template parameters encryption','Excerpts from Zane Bitter\'s message of 2014-06-04 16:19:05 -0700:\n> On 04/06/14 15:58, Vijendar Komalla wrote:\n> > Hi Devs,\n> > I have submitted an WIP review (https://review.openstack.org/#/c/97900/)\n> > for Heat parameters encryption blueprint\n> > https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters\n> > This quick and dirty implementation encrypts all the parameters on on\n> > Stack \'store\' and decrypts on on Stack \'load\'.\n> > Following are couple of improvements I am thinking about;\n> > 1. Instead of encrypting individual parameters, on Stack \'store\' encrypt\n> > all the parameters together as a dictionary  [something like\n> > crypt.encrypt(json.dumps(param_dictionary))]\n> \n> Yeah, definitely don\'t encrypt them individually.\n> \n> > 2. Just encrypt parameters that were marked as \'hidden\', instead of\n> > encrypting all parameters\n> >\n> > I would like to hear your feedback/suggestions.\n> \n> Just as a heads-up, we will soon need to store the properties of \n> resources too, at which point parameters become the least of our \n> problems. (In fact, in theory we wouldn\'t even need to store \n> parameters... and probably by the time convergence is completely \n> implemented, we won\'t.) Which is to say that there\'s almost certainly no \n> point in discriminating between hidden and non-hidden parameters.\n> \n> I\'ll refrain from commenting on whether the extra security this affords \n> is worth the giant pain it causes in debugging, except to say that IMO \n> there should be a config option to disable the feature (and if it\'s \n> enabled by default, it should probably be disabled by default in e.g. \n> devstack).\n\nStoring secrets seems like a job for Barbican. That handles the giant\npain problem because in devstack you can just tell Barbican to have an\nopen read policy.\n\nI\'d rather see good hooks for Barbican than blanket encryption. I\'ve\nworked with a few things like this and they are despised and worked\naround universally because of the reason Zane has expressed concern about:\ndebugging gets ridiculous.\n\nHow about this:\n\nparameters:\n  secrets:\n    type: sensitive\nresources:\n  sensitive_deployment:\n    type: OS::Heat::StructuredDeployment\n    properties:\n      config: weverConfig\n      server: myserver\n      input_values:\n        secret_handle: { get_param: secrets }\n\nThe sensitive type would, on the client side, store the value in Barbican,\nnever in Heat. Instead it would just pass in a handle which the user\ncan then build policy around. Obviously this implies the user would set\nup Barbican\'s in-instance tools to access the secrets value. But the\nidea is, let Heat worry about being high performing and introspectable,\nand then let Barbican worry about sensitive things.\n\n\n','<538FA969.30105@redhat.com>',NULL),('<1401927900-sup-4730@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 17:30:45',-25200,'2014-06-05 00:30:45',NULL,'[openstack-dev] [Heat]Heat template parameters encryption','Excerpts from Randall Burt\'s message of 2014-06-04 17:17:07 -0700:\n> On Jun 4, 2014, at 7:05 PM, Clint Byrum <clint at fewbar.com>\n>  wrote:\n> \n> > Excerpts from Zane Bitter\'s message of 2014-06-04 16:19:05 -0700:\n> >> On 04/06/14 15:58, Vijendar Komalla wrote:\n> >>> Hi Devs,\n> >>> I have submitted an WIP review (https://review.openstack.org/#/c/97900/)\n> >>> for Heat parameters encryption blueprint\n> >>> https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters\n> >>> This quick and dirty implementation encrypts all the parameters on on\n> >>> Stack \'store\' and decrypts on on Stack \'load\'.\n> >>> Following are couple of improvements I am thinking about;\n> >>> 1. Instead of encrypting individual parameters, on Stack \'store\' encrypt\n> >>> all the parameters together as a dictionary  [something like\n> >>> crypt.encrypt(json.dumps(param_dictionary))]\n> >> \n> >> Yeah, definitely don\'t encrypt them individually.\n> >> \n> >>> 2. Just encrypt parameters that were marked as \'hidden\', instead of\n> >>> encrypting all parameters\n> >>> \n> >>> I would like to hear your feedback/suggestions.\n> >> \n> >> Just as a heads-up, we will soon need to store the properties of \n> >> resources too, at which point parameters become the least of our \n> >> problems. (In fact, in theory we wouldn\'t even need to store \n> >> parameters... and probably by the time convergence is completely \n> >> implemented, we won\'t.) Which is to say that there\'s almost certainly no \n> >> point in discriminating between hidden and non-hidden parameters.\n> >> \n> >> I\'ll refrain from commenting on whether the extra security this affords \n> >> is worth the giant pain it causes in debugging, except to say that IMO \n> >> there should be a config option to disable the feature (and if it\'s \n> >> enabled by default, it should probably be disabled by default in e.g. \n> >> devstack).\n> > \n> > Storing secrets seems like a job for Barbican. That handles the giant\n> > pain problem because in devstack you can just tell Barbican to have an\n> > open read policy.\n> > \n> > I\'d rather see good hooks for Barbican than blanket encryption. I\'ve\n> > worked with a few things like this and they are despised and worked\n> > around universally because of the reason Zane has expressed concern about:\n> > debugging gets ridiculous.\n> > \n> > How about this:\n> > \n> > parameters:\n> >  secrets:\n> >    type: sensitive\n> > resources:\n> >  sensitive_deployment:\n> >    type: OS::Heat::StructuredDeployment\n> >    properties:\n> >      config: weverConfig\n> >      server: myserver\n> >      input_values:\n> >        secret_handle: { get_param: secrets }\n> > \n> > The sensitive type would, on the client side, store the value in Barbican,\n> > never in Heat. Instead it would just pass in a handle which the user\n> > can then build policy around. Obviously this implies the user would set\n> > up Barbican\'s in-instance tools to access the secrets value. But the\n> > idea is, let Heat worry about being high performing and introspectable,\n> > and then let Barbican worry about sensitive things.\n> \n> While certainly ideal, it doesn\'t solve the current problem since we can\'t yet guarantee Barbican will even be available in a given release of OpenStack. In the meantime, Heat continues to store sensitive user information unencrypted in its database. Once Barbican is integrated, I\'d be all for changing this implementation, but until then, we do need an interim solution. Sure, debugging is a pain and as developers we can certainly grumble, but leaking sensitive user information because we were too fussed to protect data at rest seems worse IMO. Additionally, the solution as described sounds like we\'re imposing a pretty awkward process on a user to save ourselves from having to decrypt some data in the cases where we can\'t access the stack information directly from the API or via debugging running Heat code (where the data isn\'t encrypted anymore).\n> \n\nI have made that exact, reasoned argument before, and then later seen\ngiant swathes of code with things like\n\nif CONF.dont_encrypt:\n  ...\n\nThe next thing that happens is one by one the production deployments\neventually end up with dont_encrypt because they can\'t debug anything\nand they\'ve all had a multi-hour downtime event while they dealt with\nthe encrypted database on several levels.\n\nI\'m not coddling developers. I\'m coddling operators.\n\nIt\'s a different story if you only encrypt the sensitive \"leaf\" data,\nlike passwords, credit card numbers, or personally identifying data. The\noperator can still have some clue what is going on if they can see the\nnon-sensitive data.\n\nThe design I suggested above isn\'t really that awkward and will\nbe infinitely easier to understand for an operator than encrypting\neverything.\n\n\n','<EBBB4425-FB94-4C03-AAA5-6B0B88DDC1F1@rackspace.com>',NULL),('<1401943907-sup-3481@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 21:52:53',-25200,'2014-06-05 04:52:53',NULL,'[openstack-dev] [ironic workflow question]','Excerpts from ??\'s message of 2014-06-04 20:34:01 -0700:\n> BTW, If I run \"sudo ./bin/disk-image-create -a amd64 ubuntu deploy-ironic\n> -o /tmp/deploy-ramdisk-ubuntu\",\n> What is the username/password for image deploy-ramdisk-ubuntu ?\n\nThere isn\'t one. You can write an element if you want to include a\nbackdoor user. Otherwise, just use nova\'s SSH keypair capability when\nyou deploy your image onto boxes.\n\n\n','<CALAMvO_xAZXrVzj30a+FqDgZNf=hTsE1ya5=y9e8bhRQ-hf8Eg@mail.gmail.com>',NULL),('<1401958741.11167.7.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 09:59:01',3600,'2014-06-05 08:59:01',NULL,'[openstack-dev] [horizon][infra] Plan for the splitting of\n Horizon into two repositories','On Thu, 2014-05-29 at 15:29 -0400, Anita Kuno wrote:\n> On 05/28/2014 08:54 AM, Radomir Dopieralski wrote:\n> > Hello,\n> > \n> > we plan to finally do the split in this cycle, and I started some\n> > preparations for that. I also started to prepare a detailed plan for the\n> > whole operation, as it seems to be a rather big endeavor.\n> > \n> > You can view and amend the plan at the etherpad at:\n> > https://etherpad.openstack.org/p/horizon-split-plan\n> > \n> > It\'s still a little vague, but I plan to gradually get it more detailed.\n> > All the points are up for discussion, if anybody has any good ideas or\n> > suggestions, or can help in any way, please don\'t hesitate to add to\n> > this document.\n> > \n> > We still don\'t have any dates or anything -- I suppose we will work that\n> > out soonish.\n> > \n> > Oh, and great thanks to all the people who have helped me so far with\n> > it, I wouldn\'t even dream about trying such a thing without you. Also\n> > thanks in advance to anybody who plans to help!\n> > \n> I\'d like to confirm that we are all aware that this patch creates 16 new\n> repos under the administration of horizon-ptl and horizon-core:\n> https://review.openstack.org/#/c/95716/\n> \n> If I\'m late to the party and the only one that this is news to, that is\n> fine. Sixteen additional repos seems like a lot of additional reviews\n> will be needed.\n\nOne slightly odd thing about this is that these repos are managed by\nhorizon-core, so presumably part of the Horizon program, but yet the\nrepos are under the stackforge/ namespace.\n\nMark.\n\n\n\n','<53878AAA.1050209@anteaya.info>',NULL),('<1401963939-sup-6555@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 03:31:03',-25200,'2014-06-05 10:31:03',NULL,'[openstack-dev] [Heat]Heat template parameters encryption','Excerpts from Steven Hardy\'s message of 2014-06-05 02:23:40 -0700:\n> On Thu, Jun 05, 2014 at 12:17:07AM +0000, Randall Burt wrote:\n> > On Jun 4, 2014, at 7:05 PM, Clint Byrum <clint at fewbar.com>\n> >  wrote:\n> > \n> > > Excerpts from Zane Bitter\'s message of 2014-06-04 16:19:05 -0700:\n> > >> On 04/06/14 15:58, Vijendar Komalla wrote:\n> > >>> Hi Devs,\n> > >>> I have submitted an WIP review (https://review.openstack.org/#/c/97900/)\n> > >>> for Heat parameters encryption blueprint\n> > >>> https://blueprints.launchpad.net/heat/+spec/encrypt-hidden-parameters\n> > >>> This quick and dirty implementation encrypts all the parameters on on\n> > >>> Stack \'store\' and decrypts on on Stack \'load\'.\n> > >>> Following are couple of improvements I am thinking about;\n> > >>> 1. Instead of encrypting individual parameters, on Stack \'store\' encrypt\n> > >>> all the parameters together as a dictionary  [something like\n> > >>> crypt.encrypt(json.dumps(param_dictionary))]\n> > >> \n> > >> Yeah, definitely don\'t encrypt them individually.\n> > >> \n> > >>> 2. Just encrypt parameters that were marked as \'hidden\', instead of\n> > >>> encrypting all parameters\n> > >>> \n> > >>> I would like to hear your feedback/suggestions.\n> > >> \n> > >> Just as a heads-up, we will soon need to store the properties of \n> > >> resources too, at which point parameters become the least of our \n> > >> problems. (In fact, in theory we wouldn\'t even need to store \n> > >> parameters... and probably by the time convergence is completely \n> > >> implemented, we won\'t.) Which is to say that there\'s almost certainly no \n> > >> point in discriminating between hidden and non-hidden parameters.\n> > >> \n> > >> I\'ll refrain from commenting on whether the extra security this affords \n> > >> is worth the giant pain it causes in debugging, except to say that IMO \n> > >> there should be a config option to disable the feature (and if it\'s \n> > >> enabled by default, it should probably be disabled by default in e.g. \n> > >> devstack).\n> > > \n> > > Storing secrets seems like a job for Barbican. That handles the giant\n> > > pain problem because in devstack you can just tell Barbican to have an\n> > > open read policy.\n> > > \n> > > I\'d rather see good hooks for Barbican than blanket encryption. I\'ve\n> > > worked with a few things like this and they are despised and worked\n> > > around universally because of the reason Zane has expressed concern about:\n> > > debugging gets ridiculous.\n> > > \n> > > How about this:\n> > > \n> > > parameters:\n> > >  secrets:\n> > >    type: sensitive\n> > > resources:\n> > >  sensitive_deployment:\n> > >    type: OS::Heat::StructuredDeployment\n> > >    properties:\n> > >      config: weverConfig\n> > >      server: myserver\n> > >      input_values:\n> > >        secret_handle: { get_param: secrets }\n> > > \n> > > The sensitive type would, on the client side, store the value in Barbican,\n> > > never in Heat. Instead it would just pass in a handle which the user\n> > > can then build policy around. Obviously this implies the user would set\n> > > up Barbican\'s in-instance tools to access the secrets value. But the\n> > > idea is, let Heat worry about being high performing and introspectable,\n> > > and then let Barbican worry about sensitive things.\n> > \n> > While certainly ideal, it doesn\'t solve the current problem since we can\'t yet guarantee Barbican will even be available in a given release of OpenStack. In the meantime, Heat continues to store sensitive user information unencrypted in its database. Once Barbican is integrated, I\'d be all for changing this implementation, but until then, we do need an interim solution. Sure, debugging is a pain and as developers we can certainly grumble, but leaking sensitive user information because we were too fussed to protect data at rest seems worse IMO. Additionally, the solution as described sounds like we\'re imposing a pretty awkward process on a user to save ourselves from having to decrypt some data in the cases where we can\'t access the stack information directly from the API or via debugging running Heat code (where the data isn\'t encrypted anymore).\n> \n> Under what circumstances are we \"leaking sensitive user information\"?\n> \n> Are you just trying to mitigate a potential attack vector, in the event of\n> a bug which leaks data from the DB?  If so, is the user-data encrypted in\n> the nova DB?\n> \n> It seems to me that this will only be a worthwhile exercise if the\n> sensitive stuff is encrypted everywhere, and many/most use-cases I can\n> think of which require sensitive data involve that data ending up in nova\n> user|meta-data?\n\nI tend to agree Steve. The strategy to move things into a system with\nstrong policy controls like Barbican will mitigate these risks, as even\ncompromise of the given secret access information may not yield access\nto the actual secrets. Basically, let\'s help facilitate end-to-end\nencryption and access control, not just mitigate one attack vector\nbecause the end-to-end one is hard.\n\nUntil then, our DBs will have sensitive information, and such is life.\n\n(Of course, this also reminds me that I think we should probably add a\none-time-pad type of access method that we can use to prevent compromise\nof our credentials when accessed in an insecure manner such as downloading\nthem via the EC2 metadata service. :)\n\n\n','<20140605092339.GA6105@t430slt.redhat.com>',NULL),('<1401970160.11167.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 13:09:20',3600,'2014-06-05 12:09:20',NULL,'[openstack-dev] [horizon][infra] Plan for the splitting of\n Horizon into two repositories','On Thu, 2014-06-05 at 11:19 +0200, Radomir Dopieralski wrote:\n> On 06/05/2014 10:59 AM, Mark McLoughlin wrote:\n> \n> >> If I\'m late to the party and the only one that this is news to, that is\n> >> fine. Sixteen additional repos seems like a lot of additional reviews\n> >> will be needed.\n> > \n> > One slightly odd thing about this is that these repos are managed by\n> > horizon-core, so presumably part of the Horizon program, but yet the\n> > repos are under the stackforge/ namespace.\n> \n> What would you propose instead?\n> Keeping them in repositories external to OpenStack, on github or\n> bitbucket sounds wrong.\n> Getting them under openstack/ doesn\'t sound good either, as the\n> projects they are packaging are not related to OpenStack.\n> \n> Have them be managed by someone else? Who?\n\nIf they\'re to be part of the Horizon program, I\'d say they should be\nunder openstack/. If not, perhaps create a new team to manage them.\n\nMark.\n\n\n\n\n','<5390363B.5010100@sheep.art.pl>',NULL),('<1401981141.28844.11.camel@tykes-place.bardicgrove.org>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-05 08:12:21',-25200,'2014-06-05 15:12:21',NULL,'[OpenStack-Infra] Update to OpenDaylight Jenkins user','On Wed, 2014-06-04 at 17:39 -0400, Anita Kuno wrote:\n> Hi Andy:\n> \n> I had talked to Kyle earlier. You aren\'t being asked to do anything.\n> \n> We are working through a naming standardization process and I just was\n> informing Kyle the name would be changing.\n> \n> From OpenDaylight Jenkins to OpenDaylight CI.\n> \n> We have over 55 automated Gerrit accounts and the use of OpenStack,\n> test, testing, Jenkins, Tempest and user (which occurs in some account\n> names) is confusing to devs. We are removing those and using CI for\n> voting accounts and Bot for accounts which never will vote.\n> \n> Thanks for the quick response and sorry for the confusion.\n\nAnita,\n\nThanks for letting me know.\n\n-Andy-\n\n-- \nAndrew J Grimberg\nSystems Administrator\nThe Linux Foundation\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140605/41f15a58/attachment.pgp>\n\n','<538F91FA.103@anteaya.info>',NULL),('<1401982073.2095.34.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-05 11:27:53',-14400,'2014-06-05 15:27:53',NULL,'[openstack-dev] [sahara] Etherpad for discussion of spark EDP\n implementation','Hi folks,\n\n  We\'ve just started an investigation of spark EDP for Sahara. Please\nvisit the etherpad and share your insights.  Spark experts especially\nwelcome!\n\nhttps://etherpad.openstack.org/p/sahara_spark_edp\n\n\n  There are some design/roadmap decisions we need to make -- how are we\ngoing to do this, in what timeframe, with what steps?  Do we employ a\nshort term solution and replace long term with something more\nsupportable, etc.\n\nBest,\n\nTrevor\n\n\n\n',NULL,NULL),('<1402040978.11167.12.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 08:49:38',3600,'2014-06-06 07:49:38',NULL,'[openstack-dev] [Glance][TC] Glance Functional API and\n Cross-project API Consistency','On Fri, 2014-05-30 at 18:22 +0000, Hemanth Makkapati wrote:\n> Hello All,\n> I\'m writing to notify you of the approach the Glance community has\n> decided to take for doing functional API.  Also, I\'m writing to\n> solicit your feedback on this approach in the light of cross-project\n> API consistency.\n> \n> At the Atlanta Summit, the Glance team has discussed introducing\n> functional API in Glance so as to be able to expose operations/actions\n> that do not naturally fit into the CRUD-style. A few approaches are\n> proposed and discussed here. We have all converged on the approach to\n> include \'action\' and action type in the URL. For instance,\n> \'POST /images/{image_id}/actions/{action_type}\'.\n> \n> However, this is different from the way Nova does actions. Nova\n> includes action type in the payload. For instance,\n> \'POST /servers/{server_id}/action {\"type\": \"<action_type>\", ...}\'. At\n> this point, we hit a cross-project API consistency issue mentioned\n> here (under the heading \'How to act on resource - cloud perform on\n> resources\'). Though we are differing from the way Nova does actions\n> and hence another source of cross-project API inconsistency , we have\n> a few reasons to believe that Glance\'s way is helpful in certain ways.\n> \n> The reasons are as following:\n> 1. Discoverability of operations.  It\'ll be easier to expose permitted\n> actions through schemas a json home document living\n> at /images/{image_id}/actions/.\n> 2. More conducive for rate-limiting. It\'ll be easier to rate-limit\n> actions in different ways if the action type is available in the URL.\n> 3. Makes more sense for functional actions that don\'t require a\n> request body (e.g., image deactivation).\n> \n> At this point we are curious to see if the API conventions group\n> believes this is a valid and reasonable approach.\n\nIt\'s obviously preferable if new APIs follow conventions established by\nexisting APIs, but I think you\'ve laid out pretty compelling rationale\nfor not following Nova\'s lead on this.\n\nThe question is whether Nova should plan on adopting this approach in a\nfuture version of its API?\n\nMark.\n\n\n\n\n','<2231A7091763C146998962CD0745FB150C4D38F1@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1402041625.11167.17.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 09:00:25',3600,'2014-06-06 08:00:25',NULL,'[openstack-dev] [Glance] [TC] Program Mission Statement and the\n Catalog','On Wed, 2014-06-04 at 18:03 -0700, Mark Washenberger wrote:\n> Hi folks,\n> \n> \n> I\'d like to propose the Images program to adopt a mission statement\n> [1] and then change it to reflect our new aspirations of acting as a\n> Catalog that works with artifacts beyond just disk images [2]. \n> \n> \n> Since the Glance mini summit early this year, momentum has been\n> building significantly behind catalog effort and I think its time we\n> recognize it officially, to ensure further growth can proceed and to\n> clarify the interactions the Glance Catalog will have with other\n> OpenStack projects.\n> \n> \n> Please see the linked openstack/governance changes, and provide your\n> feedback either in this thread, on the changes themselves, or in the\n> next TC meeting when we get a chance to discuss.\n> \n> \n> Thanks to Georgy Okrokvertskhov for coming up with the new mission\n> statement.\n\nJust quoting the proposal here to make the idea slightly more\naccessible, perhaps triggering some discussion here:\n\n  https://review.openstack.org/98002\n\n  Artifact Repository Service:\n    codename: Glance\n    mission:\n      To provide services to store, browse, share, distribute, and manage\n      artifacts consumable by OpenStack services in a unified manner. An artifact\n      is any strongly-typed, versioned collection of document and bulk,\n      unstructured data and is immutable once the artifact is published in the\n      repository.\n\nThanks,\nMark.\n\n\n\n\n','<CAJyP2C-gVTVeJzsMBJ6bezhnPGuPmApTrM3TCdjikReMHo1AJw@mail.gmail.com>',NULL),('<1402066629.11167.23.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 15:57:09',3600,'2014-06-06 14:57:09',NULL,'[openstack-dev] [oslo] Mehdi Abaakouk added to oslo.messaging-core','Mehdi has been making great contributions and reviews on oslo.messaging\nfor months now, so I\'ve added him to oslo.messaging-core.\n\nThank you for all your hard work Mehdi!\n\nMark.\n\n\n\n',NULL,NULL),('<1402070076.6301.11.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 11:54:36',-14400,'2014-06-06 15:54:36',NULL,'[openstack-dev] [Sahara] Spark plugin: EDP and Spark jobs','Thanks Daniele,\n\n  This is a good summary (also pasted more or less on the etherpad).\n\n> There is also a third possibility of bypassing the job-server problem\n> and call directly Spark commands on the master node of the cluster.\n\n  I am starting to play around with this idea as a simple\nproof-of-concept. I think it can be done along with some refactoring in\nthe Sahara job manager.\n\n  I think the refactoring is viable and can give us something where the\ndetails of \"run, status, kill\" can be hidden behind another common\ninterface.  If this proves to be viable, we can pursue more capable\nspark job models next.\n\nWe shall see!  Learn by doing.  I should have a CR in a few days.\n\nBest,\n\nTrevor\n\nOn Fri, 2014-06-06 at 10:54 +0200, Daniele Venzano wrote:\n> Dear all,\n> \n> A short while ago the Spark plugin for Sahara was merged, opening up the\n> possibility of deploying Spark clusters with one click from OpenStack.\n> Since Spark is quite different from Hadoop, we need to take a number of\n> decisions on how to proceed implementing important features, like, in\n> particular, EDP. Spark does not have a built-in job-server and EDP needs\n> a way to have a very generic and high level interface to submit, check\n> the basic status and kill a job.\n> \n> In summary, this is our understanding of the current situation:\n> 1. a quick hack is to use Oozie for application submission (this mimics\n> what Cloudera did by the end of last year, when preparing to announce\n> the integration of Spark in CDH)\n> 2. an alternative is to use a spark job-server, which should replace Oozie\n> (there is a repo on github from ooyala that implements an instance of a\n> job-server)\n> \n> Here\'s our view on the points above:\n> 1. clearly, the first approach is an \"ugly\" hack, that creates\n> dependencies with Oozie. Oozie requires mapreduce, and uses tiny\n> map-only jobs to submit part of a larger workflow. Besides dependencies,\n> this is a bazooka to kill a fly, as we\'re not addressing spark\n> application workflows right now\n> 2. the spark job-server idea is more clean, but the current project from\n> Ooyala supports an old version of spark. Spark 1.0.0 (which we have\n> already tested in Sahara and that we will commit soon) offers some new\n> methods to submit and package applications, that can drastically\n> simplify the \"job-server\"\n> \n> As a consequence, the doubt is: do we contribute to that project, create\n> a new one, or contribute directly to spark?\n> \n> A few more points:\n> - assuming we have a working prototype of 2), we need to modify the\n> Sahara setup such that it deploys, in addition to the usual suspects\n> (master and slaves) one more service, the spark job-server\n> \n> There is also a third possibility of bypassing the job-server problem\n> and call directly Spark commands on the master node of the cluster.\n\n\n\n> One last observation: currently, spark in standalone mode (that we use\n> in the plugin) does not support other schedulers than FIFO, when\n> multiple spark applications/jobs are submitted to the cluster. Hence,\n> the spark job-server could be a good place to integrate a better job\n> scheduler.\n> \n> Trevor McKay opened a pad here:\n> https://etherpad.openstack.org/p/sahara_spark_edp\n> \n> to gather ideas and feedback. This email is based on the very\n> preliminary discussion that happened yesterday via IRC, email and the\n> above-mentioned etherpad and has the objective of starting a public\n> discussion on how to proceed.\n> \n\n\n\n\n','<539181D4.7080404@brownhat.org>',NULL),('<1402070344.6301.14.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 11:59:04',-14400,'2014-06-06 15:59:04',NULL,'[openstack-dev] [sahara] Re: Spark plugin: EDP and Spark jobs','(resend with proper subject markers)\n\nThanks Daniele,\n\n  This is a good summary (also pasted more or less on the etherpad).\n\n> There is also a third possibility of bypassing the job-server problem\n> and call directly Spark commands on the master node of the cluster.\n\n  I am starting to play around with this idea as a simple\nproof-of-concept. I think it can be done along with some refactoring in\nthe Sahara job manager.\n\n  I think the refactoring is viable and can give us something where the\ndetails of \"run, status, kill\" can be hidden behind another common\ninterface.  If this proves to be viable, we can pursue more capable\nspark job models next.\n\nWe shall see!  Learn by doing.  I should have a CR in a few days.\n\nBest,\n\nTrevor\n\nOn Fri, 2014-06-06 at 10:54 +0200, Daniele Venzano wrote:\n> Dear all,\n> \n> A short while ago the Spark plugin for Sahara was merged, opening up\nthe\n> possibility of deploying Spark clusters with one click from OpenStack.\n> Since Spark is quite different from Hadoop, we need to take a number\nof\n> decisions on how to proceed implementing important features, like, in\n> particular, EDP. Spark does not have a built-in job-server and EDP\nneeds\n> a way to have a very generic and high level interface to submit, check\n> the basic status and kill a job.\n> \n> In summary, this is our understanding of the current situation:\n> 1. a quick hack is to use Oozie for application submission (this\nmimics\n> what Cloudera did by the end of last year, when preparing to announce\n> the integration of Spark in CDH)\n> 2. an alternative is to use a spark job-server, which should replace\nOozie\n> (there is a repo on github from ooyala that implements an instance of\na\n> job-server)\n> \n> Here\'s our view on the points above:\n> 1. clearly, the first approach is an \"ugly\" hack, that creates\n> dependencies with Oozie. Oozie requires mapreduce, and uses tiny\n> map-only jobs to submit part of a larger workflow. Besides\ndependencies,\n> this is a bazooka to kill a fly, as we\'re not addressing spark\n> application workflows right now\n> 2. the spark job-server idea is more clean, but the current project\nfrom\n> Ooyala supports an old version of spark. Spark 1.0.0 (which we have\n> already tested in Sahara and that we will commit soon) offers some new\n> methods to submit and package applications, that can drastically\n> simplify the \"job-server\"\n> \n> As a consequence, the doubt is: do we contribute to that project,\ncreate\n> a new one, or contribute directly to spark?\n> \n> A few more points:\n> - assuming we have a working prototype of 2), we need to modify the\n> Sahara setup such that it deploys, in addition to the usual suspects\n> (master and slaves) one more service, the spark job-server\n> \n> There is also a third possibility of bypassing the job-server problem\n> and call directly Spark commands on the master node of the cluster.\n\n\n\n> One last observation: currently, spark in standalone mode (that we use\n> in the plugin) does not support other schedulers than FIFO, when\n> multiple spark applications/jobs are submitted to the cluster. Hence,\n> the spark job-server could be a good place to integrate a better job\n> scheduler.\n> \n> Trevor McKay opened a pad here:\n> https://etherpad.openstack.org/p/sahara_spark_edp\n> \n> to gather ideas and feedback. This email is based on the very\n> preliminary discussion that happened yesterday via IRC, email and the\n> above-mentioned etherpad and has the objective of starting a public\n> discussion on how to proceed.\n> \n\n\n\n\n',NULL,NULL),('<1402070806.20544.2.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 16:06:49',0,'2014-06-06 16:06:49',NULL,'[openstack-dev] Designate Incubation Request','Several of the TC requested we have an openstack-infra managed DevStack\ngate enabled before they would cast their vote - I\'m happy to say, we\'ve\ngot it :)\n\nWith the merge of [1], Designate now has voting devstack /\nrequirements / docs jobs. An example of the DevStack run is at [2].\n\n\"Vote Designate\" @ [3] :)\n\nThanks,\nKiall\n\n[1]: https://review.openstack.org/#/c/98439/\n[2]: https://review.openstack.org/#/c/98442/\n[3]: https://review.openstack.org/#/c/97609/\n\nOn Sat, 2014-05-24 at 17:24 +0000, Hayes, Graham wrote:\n> Hi all,\n> \n> Designate would like to apply for incubation status in OpenStack.\n> \n> Our application is here: \n> https://wiki.openstack.org/wiki/Designate/Incubation_Application \n> \n> As part of our application we would like to apply for a new program. Our\n> application for the program is here:\n> \n> https://wiki.openstack.org/wiki/Designate/Program_Application \n> \n> Designate is a DNS as a Service project, providing both end users,\n> developers, and administrators with an easy to use REST API to manage\n> their DNS Zones and Records.\n> \n> Thanks,\n> \n> Graham\n\n\n','<1400952296.32582.0.camel@graham-desk-13-10>',NULL),('<1402070806.20544.2.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-06 16:06:49',0,'2014-06-06 16:06:49',NULL,'[openstack-tc] [openstack-dev] Designate Incubation Request','Several of the TC requested we have an openstack-infra managed DevStack\ngate enabled before they would cast their vote - I\'m happy to say, we\'ve\ngot it :)\n\nWith the merge of [1], Designate now has voting devstack /\nrequirements / docs jobs. An example of the DevStack run is at [2].\n\n\"Vote Designate\" @ [3] :)\n\nThanks,\nKiall\n\n[1]: https://review.openstack.org/#/c/98439/\n[2]: https://review.openstack.org/#/c/98442/\n[3]: https://review.openstack.org/#/c/97609/\n\nOn Sat, 2014-05-24 at 17:24 +0000, Hayes, Graham wrote:\n> Hi all,\n> \n> Designate would like to apply for incubation status in OpenStack.\n> \n> Our application is here: \n> https://wiki.openstack.org/wiki/Designate/Incubation_Application \n> \n> As part of our application we would like to apply for a new program. Our\n> application for the program is here:\n> \n> https://wiki.openstack.org/wiki/Designate/Program_Application \n> \n> Designate is a DNS as a Service project, providing both end users,\n> developers, and administrators with an easy to use REST API to manage\n> their DNS Zones and Records.\n> \n> Thanks,\n> \n> Graham\n\n\n','<1400952296.32582.0.camel@graham-desk-13-10>',NULL),('<140207aeebc.2789.fb4ef8b51dc28805abb8e2ebe8705905@suse.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-27 16:16:24',7200,'2013-07-27 14:16:24',NULL,'[openstack-dev] Python 3','Am 24. Juli 2013 18:00:30 schrieb Monty Taylor <mordred at inaugust.com>:\n>\n>\n> On 07/23/2013 03:02 PM, Brian Curtin wrote:\n> > On Jul 23, 2013, at 3:51 PM, Eric Windisch <eric at cloudscaling.com\n> > <mailto:eric at cloudscaling.com>>\n> >  wrote:\n> > >>\n> >>\n> >>\n> >> On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton <logan at bacoosta.com\n> >> <mailto:logan at bacoosta.com>> wrote:\n> >>\n> >>     I\'m sure this has been asked before, but what exactly is the plan\n> >>     for Python 3 support?\n> >>\n> >>     Is the plan to support 2 and 3 at the same time? I was looking\n> >>     around for a blue print or something but I can\'t seem to find\n> >>     anything.\n> >>\n> >>\n> >> I suppose a wiki page is due.  This was discussed at the last summit:\n> >> https://etherpad.openstack.org/havana-python3\n> >>\n> >> The plan is to support Python 2.6+ for the 2..x series and Python\n> >> 3.3+. This effort has begun for libraries (oslo) and clients. Work is\n> >> appreciated on the primary projects, but will ultimately become\n> >> stalled if the library work is not first completed.\n>\n> I\'d like to add that at some point in the future it is our desire to\n> drop support for 2.6, as supporting 2.7 and 3.3+ is way easier than also\n> supporting 2.6. At the moment, I believe our main factor on that is the\n> current version of RHEL. Fingers crossed for a new one soon... :)\n\nNot to forget SLES ;-)\n\n>\n> We are also just finishing up getting 3.3 enabled build slaves in the CI\n> gate, so as projects get 3.3 compliant, we should be able to start\n> testing that.\n>\n> > FWIW, I came across https://wiki.openstack.org/wiki/Python3Deps and\n> > updated \"routes\", which currently works with 3.3. One small step, for free!\n> > I\'m a newcomer to this list, but I\'m a CPython core contributor and am\n> > working in Developer Relations at Rackspace, so supporting Python 3 is\n> > right up my alley.\n>\n> Excellent! Welcome, glad to have you.\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n\n','<51EFFA1E.8060001@inaugust.com>',NULL),('<1402082585.11167.45.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-06 20:23:05',3600,'2014-06-06 19:23:05',NULL,'[openstack-dev] use of the word certified','On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n> The issue I have with the word certify is that it requires someone or a\n> group of someones to attest to something. The thing attested to is only\n> as credible as the someone or the group of someones doing the attesting.\n> We have no process, nor do I feel we want to have a process for\n> evaluating the reliability of the somones or groups of someones doing\n> the attesting.\n> \n> I think that having testing in place in line with other programs testing\n> of patches (third party ci) in cinder should be sufficient to address\n> the underlying concern, namely reliability of opensource hooks to\n> proprietary code and/or hardware. I would like the use of the word\n> \"certificate\" and all its roots to no longer be used in OpenStack\n> programs with regard to testing. This won\'t happen until we get some\n> discussion and agreement on this, which I would like to have.\n\nThanks for bringing this up Anita. I agree that \"certified driver\" or\nsimilar would suggest something other than I think we mean.\n\nAnd, for whatever its worth, the topic did come up at a Foundation board\nmeeting and some board members expressed similar concerns, although I\nguess that was more precisely about the prospect of the Foundation\ncalling drivers \"certified\".\n\nMark.\n\n\n\n','<5391FA6A.1000400@anteaya.info>',NULL),('<1402082585.11167.45.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-06 20:23:05',3600,'2014-06-06 19:23:05',NULL,'[openstack-tc] [openstack-dev] use of the word certified','On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n> The issue I have with the word certify is that it requires someone or a\n> group of someones to attest to something. The thing attested to is only\n> as credible as the someone or the group of someones doing the attesting.\n> We have no process, nor do I feel we want to have a process for\n> evaluating the reliability of the somones or groups of someones doing\n> the attesting.\n> \n> I think that having testing in place in line with other programs testing\n> of patches (third party ci) in cinder should be sufficient to address\n> the underlying concern, namely reliability of opensource hooks to\n> proprietary code and/or hardware. I would like the use of the word\n> \"certificate\" and all its roots to no longer be used in OpenStack\n> programs with regard to testing. This won\'t happen until we get some\n> discussion and agreement on this, which I would like to have.\n\nThanks for bringing this up Anita. I agree that \"certified driver\" or\nsimilar would suggest something other than I think we mean.\n\nAnd, for whatever its worth, the topic did come up at a Foundation board\nmeeting and some board members expressed similar concerns, although I\nguess that was more precisely about the prospect of the Foundation\ncalling drivers \"certified\".\n\nMark.\n\n\n\n','<5391FA6A.1000400@anteaya.info>',NULL),('<1402134383-sup-2073@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-07 02:49:14',-25200,'2014-06-07 09:49:14',NULL,'[openstack-dev] [Nova] Mid cycle meetup','Excerpts from Devananda van der Veen\'s message of 2014-06-06 12:04:08 -0700:\n> I have just announced the Ironic mid-cycle in Beaverton, co-located\n> with Nova. That\'s the \"main one\" for Ironic.\n> \n> However, there are many folks working on both TripleO and Ironic, so I\n> wouldn\'t be surprised if there is a (small?) group at the TripleO\n> sprint hacking on Ironic, even if there\'s nothing official, and even\n> if the dates overlap (which I really hope they don\'t). I\'m going to\n> try to attend the TripleO sprint if at all possible, as that project\n> remains one of the largest users of Ironic that I\'m aware of.\n> \n\nYes, we desperately need expertise as our intention is to push forward\non scale testing, and we\'ll need experts on Ironic\'s internals to push\noptimizations where they\'re needed. I hope that the Ironic team is\nlarge enough that there can be some at the Nova sprint, and some at the\nTripleO sprint if they happen to be concurrent.\n\nI believe we would like for the TripleO sprint to be a bit later in the\ncycle though, and I\'m seeing dates proposed that would reflect that.\n\n\n','<CAExZKEqjV+Y18Bi6D7LhwZ5r88V_DOFoynGmq0vuJNcnQ=0D3A@mail.gmail.com>',NULL),('<1402215007.11167.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-08 09:10:07',3600,'2014-06-08 08:10:07',NULL,'[openstack-dev] [openstack-tc]  use of the word certified','Hi John,\n\nOn Fri, 2014-06-06 at 13:59 -0600, John Griffith wrote:\n\n> On Fri, Jun 6, 2014 at 1:55 PM, John Griffith <john.griffith at solidfire.com> wrote:\n\n>         On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>                 On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n>                 > The issue I have with the word certify is that it\n>                 requires someone or a\n>                 > group of someones to attest to something. The thing\n>                 attested to is only\n>                 > as credible as the someone or the group of someones\n>                 doing the attesting.\n>                 > We have no process, nor do I feel we want to have a\n>                 process for\n>                 > evaluating the reliability of the somones or groups\n>                 of someones doing\n>                 > the attesting.\n>                 >\n>                 > I think that having testing in place in line with\n>                 other programs testing\n>                 > of patches (third party ci) in cinder should be\n>                 sufficient to address\n>                 > the underlying concern, namely reliability of\n>                 opensource hooks to\n>                 > proprietary code and/or hardware. I would like the\n>                 use of the word\n>                 > \"certificate\" and all its roots to no longer be used\n>                 in OpenStack\n>                 > programs with regard to testing. This won\'t happen\n>                 until we get some\n>                 > discussion and agreement on this, which I would like\n>                 to have.\n>                 \n>                 \n>                 Thanks for bringing this up Anita. I agree that\n>                 \"certified driver\" or\n>                 similar would suggest something other than I think we\n>                 mean.\n>          \n>         ?Can you expand on the above comment?  In other words a bit\n>         more about what \"you\" mean.  I think from the perspective of a\n>         number of people that participate in Cinder the intent is in\n>         fact to say.  Maybe it would help clear some things up for\n>         folks that don\'t see why this has become a debatable issue.\n\nFair question. I didn\'t elaborate initially because I thought Anita\ncovered it pretty well.\n\n>         By running CI tests successfully that it is in fact a ?way of\n>         certifying that our device and driver is in fact \'certified\'\n>         to function appropriately and provide the same level of API\n>         and behavioral compatability as the default components as\n>         demonstrated by running CI tests on each submitted patch.\n\nMy view is that \"certification\" is an attestation that someone can take\nthe certified combination of a driver and whatever vendor product it is\nassociated with, and the combination will be fit for purpose in any of\nthe configurations that it supports.\n\nTo achieve anything close to that, we\'d need to be explicit about what\ndistros, deployment tools, OpenStack configurations and vendor\nconfigurations must be supported. And it would be fairly strange for us\nto do that considering the way OpenStack just ships tarballs currently\nrather than a fully deployable thing.\n\nAlso AIUI \"certification\" implies some level of warranty or guarantee,\nwhich goes against the pretty clear language \"WITHOUT WARRANTIES OR\nCONDITIONS OF ANY KIND\" in our license :)\n\nBasically, I think there\'s a world of difference between what\'s expected\nof a certification body and what a technical community like ours should\nIMHO be undertaking in terms of providing information about how\nfunctional and maintained drivers are.\n\n(To be clear, I love any that we\'re trying to surface information about\nhow well maintained and tested drivers are)\n\n>         Personally I believe part of the contesting of the phrases and\n>         terms is partly due to the fact that a number of organizations\n>         have their own \"certification\" programs and tests.  I think\n>         that\'s great, and they in fact provide some form of\n>         \"certification\" that a device works in their environment and\n>         to their expectations.  \n\nAlso fair, and I should be careful to be clear about my Red Hat bias on\nthis. I am speaking here with my \"upstream hat\" on - i.e. thinking about\nwhat\'s good for the project, not necessarily Red Hat - but I\'m\ndefinitely influenced about the meaning of \"certification\" by knowing a\nlittle about Red Hat\'s product certification program.\n\n>         Doing this from a general OpenStack integration perspective\n>         doesn\'t seem all that different to me.  For the record, my\n>         initial response to this was that I didn\'t have too much\n>         preference on what it was called (verification, certification\n>         etc etc), however there seems to be a large number of people\n>         (not product vendors for what it\'s worth) that feel\n>         differently.\n>         \n\n\n>	On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>                 And, for whatever its worth, the topic did come up at\n>                 a Foundation board\n>                 meeting and some board members expressed similar\n>                 concerns, although I\n>                 guess that was more precisely about the prospect of\n>                 the Foundation\n>                 calling drivers \"certified\".\n>                 \n\n\n> ?By the way, has anybody thought about this in an OpenStack general\n> context.  I mean, are we saying that we don\'t offer any sort of\n> certification or verification that the various OpenStack components or\n> services actually work? \n\nRight, we don\'t. Do you have examples in mind of open-source projects\nwhich do?\n\n> I realize there are significantly different levels of certification\n> and that\'s an important distinction as well in my opinion.\n\nAnother distinction is whether certification provided by the project vs\nprovided by the Foundation. In the case of Cinder[1], I think you\'ve\nmade it reasonably clear the certification body is \"the Cinder team\" but\nI think many people would expect any certification to be provided by the\nFoundation and carry with it right to use e.g. an \"OpenStack certified\"\ntrademark. In other words, that something carrying the name\n\"certification\" would imply a level of formality and that it would come\nfrom a legal entity.\n\nNow, to be clear - I think Cinder (or the project more generally)\nprobably can do this without any endorsement of the Foundation so long\nas it doesn\'t get into trademark or legal risk territory, it\'s just that\nI think we shouldn\'t be taking it on.\n\nMark.\n\n[1] - https://wiki.openstack.org/wiki/Cinder/certified-drivers\n\n\n\n','<CA+qL3LW7p9FYWXzpKi80rJEXi9O_i1SOf78Srz6xZTY1GrGi=w@mail.gmail.com>',NULL),('<1402215007.11167.76.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-08 09:10:07',3600,'2014-06-08 08:10:07',NULL,'[openstack-tc] [openstack-dev] use of the word certified','Hi John,\n\nOn Fri, 2014-06-06 at 13:59 -0600, John Griffith wrote:\n\n> On Fri, Jun 6, 2014 at 1:55 PM, John Griffith <john.griffith at solidfire.com> wrote:\n\n>         On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>                 On Fri, 2014-06-06 at 13:29 -0400, Anita Kuno wrote:\n>                 > The issue I have with the word certify is that it\n>                 requires someone or a\n>                 > group of someones to attest to something. The thing\n>                 attested to is only\n>                 > as credible as the someone or the group of someones\n>                 doing the attesting.\n>                 > We have no process, nor do I feel we want to have a\n>                 process for\n>                 > evaluating the reliability of the somones or groups\n>                 of someones doing\n>                 > the attesting.\n>                 >\n>                 > I think that having testing in place in line with\n>                 other programs testing\n>                 > of patches (third party ci) in cinder should be\n>                 sufficient to address\n>                 > the underlying concern, namely reliability of\n>                 opensource hooks to\n>                 > proprietary code and/or hardware. I would like the\n>                 use of the word\n>                 > \"certificate\" and all its roots to no longer be used\n>                 in OpenStack\n>                 > programs with regard to testing. This won\'t happen\n>                 until we get some\n>                 > discussion and agreement on this, which I would like\n>                 to have.\n>                 \n>                 \n>                 Thanks for bringing this up Anita. I agree that\n>                 \"certified driver\" or\n>                 similar would suggest something other than I think we\n>                 mean.\n>          \n>         ?Can you expand on the above comment?  In other words a bit\n>         more about what \"you\" mean.  I think from the perspective of a\n>         number of people that participate in Cinder the intent is in\n>         fact to say.  Maybe it would help clear some things up for\n>         folks that don\'t see why this has become a debatable issue.\n\nFair question. I didn\'t elaborate initially because I thought Anita\ncovered it pretty well.\n\n>         By running CI tests successfully that it is in fact a ?way of\n>         certifying that our device and driver is in fact \'certified\'\n>         to function appropriately and provide the same level of API\n>         and behavioral compatability as the default components as\n>         demonstrated by running CI tests on each submitted patch.\n\nMy view is that \"certification\" is an attestation that someone can take\nthe certified combination of a driver and whatever vendor product it is\nassociated with, and the combination will be fit for purpose in any of\nthe configurations that it supports.\n\nTo achieve anything close to that, we\'d need to be explicit about what\ndistros, deployment tools, OpenStack configurations and vendor\nconfigurations must be supported. And it would be fairly strange for us\nto do that considering the way OpenStack just ships tarballs currently\nrather than a fully deployable thing.\n\nAlso AIUI \"certification\" implies some level of warranty or guarantee,\nwhich goes against the pretty clear language \"WITHOUT WARRANTIES OR\nCONDITIONS OF ANY KIND\" in our license :)\n\nBasically, I think there\'s a world of difference between what\'s expected\nof a certification body and what a technical community like ours should\nIMHO be undertaking in terms of providing information about how\nfunctional and maintained drivers are.\n\n(To be clear, I love any that we\'re trying to surface information about\nhow well maintained and tested drivers are)\n\n>         Personally I believe part of the contesting of the phrases and\n>         terms is partly due to the fact that a number of organizations\n>         have their own \"certification\" programs and tests.  I think\n>         that\'s great, and they in fact provide some form of\n>         \"certification\" that a device works in their environment and\n>         to their expectations.  \n\nAlso fair, and I should be careful to be clear about my Red Hat bias on\nthis. I am speaking here with my \"upstream hat\" on - i.e. thinking about\nwhat\'s good for the project, not necessarily Red Hat - but I\'m\ndefinitely influenced about the meaning of \"certification\" by knowing a\nlittle about Red Hat\'s product certification program.\n\n>         Doing this from a general OpenStack integration perspective\n>         doesn\'t seem all that different to me.  For the record, my\n>         initial response to this was that I didn\'t have too much\n>         preference on what it was called (verification, certification\n>         etc etc), however there seems to be a large number of people\n>         (not product vendors for what it\'s worth) that feel\n>         differently.\n>         \n\n\n>	On Fri, Jun 6, 2014 at 1:23 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n>                 And, for whatever its worth, the topic did come up at\n>                 a Foundation board\n>                 meeting and some board members expressed similar\n>                 concerns, although I\n>                 guess that was more precisely about the prospect of\n>                 the Foundation\n>                 calling drivers \"certified\".\n>                 \n\n\n> ?By the way, has anybody thought about this in an OpenStack general\n> context.  I mean, are we saying that we don\'t offer any sort of\n> certification or verification that the various OpenStack components or\n> services actually work? \n\nRight, we don\'t. Do you have examples in mind of open-source projects\nwhich do?\n\n> I realize there are significantly different levels of certification\n> and that\'s an important distinction as well in my opinion.\n\nAnother distinction is whether certification provided by the project vs\nprovided by the Foundation. In the case of Cinder[1], I think you\'ve\nmade it reasonably clear the certification body is \"the Cinder team\" but\nI think many people would expect any certification to be provided by the\nFoundation and carry with it right to use e.g. an \"OpenStack certified\"\ntrademark. In other words, that something carrying the name\n\"certification\" would imply a level of formality and that it would come\nfrom a legal entity.\n\nNow, to be clear - I think Cinder (or the project more generally)\nprobably can do this without any endorsement of the Foundation so long\nas it doesn\'t get into trademark or legal risk territory, it\'s just that\nI think we shouldn\'t be taking it on.\n\nMark.\n\n[1] - https://wiki.openstack.org/wiki/Cinder/certified-drivers\n\n\n\n','<CA+qL3LW7p9FYWXzpKi80rJEXi9O_i1SOf78Srz6xZTY1GrGi=w@mail.gmail.com>',NULL),('<1402268014.3378.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-08 22:53:34',0,'2014-06-08 22:53:34',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n Integration Ideas','I think that would defeat a big purpose for barbican; a user only has to\nstore their secret in one central location for reuse with many services.\n\nThanks,\nBrandon\n\nOn Sun, 2014-06-08 at 09:05 +0400, Eugene Nikanorov wrote:\n> >  If a user makes a change to a secret\n> Can we just disable that by making LBaaS a separate user so it would\n> store secrets under LBaaS \'fake\' tenant id?\n> \n> \n> Eugene.\n> \n> \n> On Sun, Jun 8, 2014 at 7:29 AM, Jain, Vivek <VIVEKJAIN at ebay.com>\n> wrote:\n>         +1 for #2.\n>         \n>         In addition, I think it would be nice if barbican maintains\n>         versioned data\n>         on updates. Which means consumer of barbican APIs can request\n>         for data\n>         from older version if needed. This can address concerns\n>         expressed by\n>         German. For example if certificates were updated on barbican\n>         but somehow\n>         update is not compatible with load balancer device, then lbaas\n>         API user\n>         gets an option to fall back to older working certificate. That\n>         will avoid\n>         downtime of lbaas managed applications.\n>         \n>         Thanks,\n>         Vivek\n>         \n>         On 6/6/14, 3:52 PM, \"Eichberger, German\"\n>         <german.eichberger at hp.com> wrote:\n>         \n>         >Jorge + John,\n>         >\n>         >I am most concerned with a user changing his secret in\n>         barbican and then\n>         >the LB trying to update and causing downtime. Some users like\n>         to control\n>         >when the downtime occurs.\n>         >\n>         >For #1 it was suggested that once the event is delivered it\n>         would be up\n>         >to a user to enable an \"auto-update flag\".\n>         >\n>         >In the case of #2 I am a bit worried about error cases: e.g.\n>         uploading\n>         >the certificates succeeds but registering the loadbalancer(s)\n>         fails. So\n>         >using the barbican system for those warnings might not as\n>         fool proof as\n>         >we are hoping.\n>         >\n>         >One thing I like about #2 over #1 is that it pushes a lot of\n>         the\n>         >information to Barbican. I think a user would expect when he\n>         uploads a\n>         >new certificate to Barbican that the system warns him right\n>         away about\n>         >load balancers using the old cert. With #1 he might get an\n>         e-mails from\n>         >LBaaS telling him things changed (and we helpfully updated\n>         all affected\n>         >load balancers) -- which isn\'t as immediate as #2.\n>         >\n>         >If we implement an \"auto-update flag\" for #1 we can have\n>         both. User\'s who\n>         >like #2 juts hit the flag. Then the discussion changes to\n>         what we should\n>         >implement first and I agree with Jorge + John that this\n>         should likely be\n>         >#2.\n>         >\n>         >German\n>         >\n>         >-----Original Message-----\n>         >From: Jorge Miramontes\n>         [mailto:jorge.miramontes at RACKSPACE.COM]\n>         >Sent: Friday, June 06, 2014 3:05 PM\n>         >To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican\n>         Neutron LBaaS\n>         >Integration Ideas\n>         >\n>         >Hey John,\n>         >\n>         >Correct, I was envisioning that the Barbican request would\n>         not be\n>         >affected, but rather, the GUI operator or API user could use\n>         the\n>         >registration information to do so should they want to do so.\n>         >\n>         >Cheers,\n>         >--Jorge\n>         >\n>         >\n>         >\n>         >\n>         >On 6/6/14 4:53 PM, \"John Wood\" <john.wood at RACKSPACE.COM>\n>         wrote:\n>         >\n>         >>Hello Jorge,\n>         >>\n>         >>Just noting that for option #2, it seems to me that the\n>         registration\n>         >>feature in Barbican would not be required for the first\n>         version of this\n>         >>integration effort, but we should create a blueprint for it\n>         nonetheless.\n>         >>\n>         >>As for your question about services not\n>         registering/unregistering, I\n>         >>don\'t see an issue as long as the presence or absence of\n>         registered\n>         >>services on a Container/Secret does not **block** actions\n>         from\n>         >>happening, but rather is information that can be used to\n>         warn clients\n>         >>through their processes. For example, Barbican would still\n>         delete a\n>         >>Container/Secret even if it had registered services.\n>         >>\n>         >>Does that all make sense though?\n>         >>\n>         >>Thanks,\n>         >>John\n>         >>\n>         >>________________________________________\n>         >>From: Youcef Laribi [Youcef.Laribi at citrix.com]\n>         >>Sent: Friday, June 06, 2014 2:47 PM\n>         >>To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         >>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican\n>         Neutron LBaaS\n>         >>Integration Ideas\n>         >>\n>         >>+1 for option 2.\n>         >>\n>         >>In addition as an additional safeguard, the LBaaS service\n>         could check\n>         >>with Barbican when failing to use an existing secret to see\n>         if the\n>         >>secret has changed (lazy detection).\n>         >>\n>         >>Youcef\n>         >>\n>         >>-----Original Message-----\n>         >>From: Jorge Miramontes\n>         [mailto:jorge.miramontes at RACKSPACE.COM]\n>         >>Sent: Friday, June 06, 2014 12:16 PM\n>         >>To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         >>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron\n>         LBaaS\n>         >>Integration Ideas\n>         >>\n>         >>Hey everyone,\n>         >>\n>         >>Per our IRC discussion yesterday I\'d like to continue the\n>         discussion on\n>         >>how Barbican and Neutron LBaaS will interact. There are\n>         currently two\n>         >>ideas in play and both will work. If you have another idea\n>         please free\n>         >>to add it so that we may evaluate all the options relative\n>         to each other.\n>         >>Here are the two current ideas:\n>         >>\n>         >>1. Create an eventing system for Barbican that Neutron LBaaS\n>         (and other\n>         >>services) consumes to identify when to update/delete updated\n>         secrets\n>         >>from Barbican. For those that aren\'t up to date with the\n>         Neutron LBaaS\n>         >>API Revision, the project/tenant/user provides a secret\n>         (container?) id\n>         >>when enabling SSL/TLS functionality.\n>         >>\n>         >>* Example: If a user makes a change to a secret/container in\n>         Barbican\n>         >>then Neutron LBaaS will see an event and take the\n>         appropriate action.\n>         >>\n>         >>PROS:\n>         >> - Barbican is going to create an eventing system regardless\n>         so it will\n>         >>be supported.\n>         >> - Decisions are made on behalf of the user which lessens\n>         the amount of\n>         >>calls the user has to make.\n>         >>\n>         >>CONS:\n>         >> - An eventing framework can become complex especially since\n>         we need to\n>         >>ensure delivery of an event.\n>         >> - Implementing an eventing system will take more time than\n>         option #2?I\n>         >>think.\n>         >>\n>         >>2. Push orchestration decisions to API users. This idea\n>         comes with two\n>         >>assumptions. The first assumption is that most providers\'\n>         customers use\n>         >>the cloud via a GUI, which in turn can handle any\n>         orchestration\n>         >>decisions that need to be made. The second assumption is\n>         that power API\n>         >>users are savvy and can handle their decisions as well.\n>         Using this\n>         >>method requires services, such as LBaaS, to \"register\" in\n>         the form of\n>         >>metadata to a barbican container.\n>         >>\n>         >>* Example: If a user makes a change to a secret the GUI can\n>         see which\n>         >>services are registered and opt to warn the user of\n>         consequences. Power\n>         >>users can look at the registered services and make decisions\n>         how they\n>         >>see fit.\n>         >>\n>         >>PROS:\n>         >> - Very simple to implement. The only code needed to make\n>         this a\n>         >>reality is at the control plane (API) level.\n>         >> - This option is more loosely coupled that option #1.\n>         >>\n>         >>CONS:\n>         >> - Potential for services to not register/unregister. What\n>         happens in\n>         >>this case?\n>         >> - Pushes complexity of decision making on to GUI engineers\n>         and power\n>         >>API users.\n>         >>\n>         >>\n>         >>I would like to get a consensus on which option to move\n>         forward with\n>         >>ASAP since the hackathon is coming up and delivering\n>         Barbican to\n>         >>Neutron LBaaS integration is essential to exposing SSL/TLS\n>         >>functionality, which almost everyone has stated is a #1/#2\n>         priority.\n>         >>\n>         >>I\'ll start the decision making process by advocating for\n>         option #2. My\n>         >>reason for choosing option #2 has to deal mostly with the\n>         simplicity of\n>         >>implementing such a mechanism. Simplicity also means we can\n>         implement\n>         >>the necessary code and get it approved much faster which\n>         seems to be a\n>         >>concern for everyone. What option does everyone else want to\n>         move\n>         >>forward with?\n>         >>\n>         >>\n>         >>\n>         >>Cheers,\n>         >>--Jorge\n>         >>\n>         >>\n>         >>_______________________________________________\n>         >>OpenStack-dev mailing list\n>         >>OpenStack-dev at lists.openstack.org\n>         >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >>\n>         >>_______________________________________________\n>         >>OpenStack-dev mailing list\n>         >>OpenStack-dev at lists.openstack.org\n>         >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >>\n>         >>_______________________________________________\n>         >>OpenStack-dev mailing list\n>         >>OpenStack-dev at lists.openstack.org\n>         >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >_______________________________________________\n>         >OpenStack-dev mailing list\n>         >OpenStack-dev at lists.openstack.org\n>         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >_______________________________________________\n>         >OpenStack-dev mailing list\n>         >OpenStack-dev at lists.openstack.org\n>         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOTGn6nbHRLz2w8PGp7DqTAO13bug+ot7_iCg3Oy1LScrg@mail.gmail.com>',NULL),('<1402269280-sup-8729@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-08 16:22:40',-25200,'2014-06-08 23:22:40',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Eichberger, German\'s message of 2014-06-06 15:52:54 -0700:\n> Jorge + John,\n> \n> I am most concerned with a user changing his secret in barbican and then the LB trying to update and causing downtime. Some users like to control when the downtime occurs.\n> \n\nCouldn\'t you allow a user to have multiple credentials, the way basically\nevery key based user access system works (for an example see SSH). Users\nchanging their credentials would create new ones, reference them in the\nappropriate consuming service, and dereference old ones when they are\nbelieved to be out of service.\n\nI see both specified options as overly complicated attempts to work\naround what would be solved gracefully with a many-to-one relationship\nof keys to users.\n\n> For #1 it was suggested that once the event is delivered it would be up to a user to enable an \"auto-update flag\".\n> \n> In the case of #2 I am a bit worried about error cases: e.g. uploading the certificates succeeds but registering the loadbalancer(s) fails. So using the barbican system for those warnings might not as fool proof as we are hoping. \n> \n> One thing I like about #2 over #1 is that it pushes a lot of the information to Barbican. I think a user would expect when he uploads a new certificate to Barbican that the system warns him right away about load balancers using the old cert. With #1 he might get an e-mails from LBaaS telling him things changed (and we helpfully updated all affected load balancers) -- which isn\'t as immediate as #2. \n> \n> If we implement an \"auto-update flag\" for #1 we can have both. User\'s who like #2 juts hit the flag. Then the discussion changes to what we should implement first and I agree with Jorge + John that this should likely be #2.\n\nIMO you\'re doing way too much and tending toward tight coupling which\nwill make the system brittle.\n\nIf you want to give the user orchestration, there is Heat. A template will\nmanage the sort of things that you want, such as automatic replacement\nand dereferencing/deleting of older credentials. But not if your service\ndoesn\'t support having n+1 active credentials at one time.\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C3700D2@G2W2441.americas.hpqcorp.net>',NULL),('<1402297892.511.17.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-09 09:11:32',7200,'2014-06-09 07:11:32',NULL,'[OpenStack-Infra] moving Activity Board fully under openstack-ci','On Sun, 2014-06-08 at 13:32 -0400, Monty Taylor wrote:\n> On 06/02/2014 06:32 PM, Jesus M. Gonzalez-Barahona wrote:\n> > On Mon, 2014-06-02 at 14:31 -0700, Stefano Maffulli wrote:\n> >> Hello folks\n> >>\n> >> I wanted to get your thoughts on the idea to move the whole Bitergia\n> >> grimoire engine, scripts, database, etc to the openstack common\n> >> infrastructure. I\'m sure everybody will want this so the question is\n> >> more about resources as in people willing to help Bitergia get their\n> >> machinery puppetized the \"OpenStack-CI way\".\n> >>\n> >> At the moment the various spiders and scripts run on a machine on\n> >> Bitergia\'s end and they drop the results of the elaboration (json, html,\n> >> css files and sql dumps) on activity.openstack.org/dash/.\n> >>\n> >> While this setup is convenient and has been working so far, I think\n> >> we\'ve outgrown it. One of the areas that we want to do more with is the\n> >> datawarehouse built by Bitergia, enable it to serve other purposes too\n> >> and allow more collaboration from the community. For example, once the\n> >> tools are all out in one place, interested parties could build some sort\n> >> of service on top of your datawarehouse to export the data about the\n> >> affiliation. Others could build tools to \'fix\' such affiliation, pulling\n> >> the various mailmap files used by gitdm and stackalytics.\n> >>\n> >> The question for OpenStack-CI is then: in the next weeks/months, is\n> >> there going to be someone free, from the CI team or someone willing to\n> >> join it (Dan?), to help Bitergia\'s team get their tools on our\n> >> infrastructure?\n> > \n> > Thanks for the introduction of the issue, Stefano.\n> > \n> > Just to clarify a bit the needs to move all the Grimoire machinery to a\n> > vm under openstack-ci, the software is split in three main parts:\n> \n> Awesome.\n> \n> > * MetricsGrimoire tools, which mine repositories (git, Launchpad, etc.),\n> > and store the data into a MySQL database (well, in fact, one schema per\n> > kind of repository).\n> >\n> > * The MySQL database itself.\n> > \n> > * The vizGrimoire tools, that run the analysis, produce JSON files, and\n> > the HTML/CSS/JavaScript files needed to serve the dashboard. All of this\n> > is for now static, which means that you only need to serve those files\n> > via HTTP, and you\'re done: no live queries to the database once the JSON\n> > files are produced.\n> > \n> > Right now, we produce the JSON files once a day. That means that\n> > MetricsGrimoire is first run once a day (the tools know how to get\n> > incremental information from repositories), data is updated in the\n> > database, and then vizGrimoire analysis is run. All of this is\n> > controlled by automator, the tool that is configured with the list of\n> > repos to analyze, the analysis to run, etc.\n> > \n> > MetricsGrimoire tools are written in Python. There are some Python\n> > dependencies beyond Python 2.7, but I guess all of them are\n> > straightforward from pypy.\n> \n> Where are these stored/installed from? Is it \"pip install\n> MetricsGrimoire\"? Is it in a git repo? Does this git repo want to move\n> into openstack tooling or does it want to stay where it is and have\n> openstack-infra consume releases?\n\nThose are different tools in git repos. Providing them via pip could be\na part of the process, anyway: that\'s something we have in the roadmap\nfor a while. Right now, openstack-infra would consume the repositories.\n\nMore info about MetricsGrimoire, and its repos:\n\nhttp://metricsgrimoire.github.io\n\n> > The MySQL is a plain MySQL. It would be great having it in SSD, because\n> > that speeds up queries a lot. But probably it will work with regular\n> > disks.\n> \n> We use cloud-based databases from Rackspace\'s Trove service. I have no\n> idea what sort of disk is behind it - but MySQL databases are no problem.\n\nok. It\'s mainly a matter of performance, I guess Trove would be ok.\n\n> > Most of vizGrimoire is also Python, but there is still some R code\n> > (we\'re currently moving towards a pure-Python implementation). Python\n> > and R dependencies are easy too (from pypy or CRAN).\n> \n> Same questions as above on MetricsGrimoire. Do you have docs anywhere on\n> installing these two things?\n\nFor MetricsGrimoire, it is very close to \"just standard Python install\".\nBut vizGrimoire is another story. Right now, it is a moving target, so\nprobably the best thing would be that we install it, and document the\nprocedure in detail for you. In the process, we could automate some\nsteps that are not automated yet.\n\nIn any case, some more info about vizGrimoire:\n\nhttp://vizgrimoire.github.io\n\nI guess the closer thing we have to a install doc is:\n\nhttps://github.com/MetricsGrimoire/Automator/wiki/Install\n\n(Automator is the script that runs all the party)\n\n> > We\'re usually deploying on Debian or Ubuntu, but we have some experience\n> > with other Linux-based OSs too.\n> \n> Great. All of our services run on Ubuntu Precise right now. We\'ll be\n> starting to think about an upgrade to trusty.\n> \n> > We could do the whole deployment, if you can provide us with a\n> > Debian/Ubuntu vm, including proper documentation to reproduce it if\n> > needed.\n> \n> All of our deployments are done in a fully automated manner driven from\n> our puppet repo: https://git.openstack.org/cgit/openstack-infra/config.\n> However - we\'d be more than happy for you to write the puppet! (and\n> happy to help with pointers)\n> \n> I just wrote the puppet to run stackalytics in Infra:\n> \n> https://review.openstack.org/98656\n> \n> It\'s probably a great place to start in terms of looking at puppetizing\n> activity board. If someone can write up something similar to:\n> \n> https://wiki.openstack.org/wiki/Stackalytics/HowToRun\n> \n> I\'ll be more likely to do what I did today which is wake up on a Sunday\n> and lazily write some puppet while watching Rafael Nadal win his ninth\n> French Open. :)\n\n;-)\n\nThanks for the pointers, Monty. Therefore, I assume that the first thing\nto do is to have a detailed installation information and/or Puppet\nconfig files. We\'re not that familiar with Puppet, so maybe the best\nthing for us would be to start writing the detailed docs, and after that\nstarting with the Puppet thing... Right?\n\nSaludos,\n\n	Jesus.\n\n> > Please, let us know which kind of other details you may need.\n> > \n> > 	Jesus.\n> > \n> > \n> \n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<53949E3E.9050204@inaugust.com>',NULL),('<1402298153.511.20.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-09 09:15:53',7200,'2014-06-09 07:15:53',NULL,'[OpenStack-Infra] moving Activity Board fully under openstack-ci','On Tue, 2014-06-03 at 20:39 +0000, Stangel, Dan wrote:\n> Stef,\n> \n> On Mon, 2014-06-02 at 14:31 -0700, Stefano Maffulli wrote:\n> > ...\n> > The question for OpenStack-CI is then: in the next weeks/months, is\n> > there going to be someone free, from the CI team or someone willing to\n> > join it (Dan?), to help Bitergia\'s team get their tools on our\n> > infrastructure?\n> \n> My impression from the recent \"Replace Launchpad OpenID authentication\"\n> design summit session (see https://etherpad.openstack.org/p/juno-openid)\n> was that infra would prefer that the Foundation create new blueprints to\n> track and respond to these kinds of requests for resources / integration\n> work.\n> \n> Speaking for myself at least, I\'m neither an expert in the \"OpenStack-CI\n> way\", nor the *grimoire toolset.  I would love to help any way I can,\n> but leading the effort is probably not for me to do.\n> \n> Dan\n\nOooops. I had missed this message. Sorry. Thanks for your offer of help.\n\nThen, do you all think it would better we write that blueprint, or we\njust go on through email, as we started in this thread with Monty\nTaylor?\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<1401827977.3570.7.camel@virtbox>',NULL),('<1402327701.5395d295a0c24@www.imp.polymtl.ca>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-09 11:28:21',-14400,'2014-06-09 15:28:21',NULL,'[Openstack] sending HttpFailureAlarm- connection failed.','Many thanks Steve!\nThe problem is solved. I guess installing heat-api-cloudwatch is missing in the\ninstallation guide. Well, there were some more issues with the guide that\nthankfully is fixed in the Icehouse installation guide. I hope this one also\nwill be added some where in the guides.\n\nThanks again for your help,\nParisa\n\nSelon Steven Hardy <shardy at redhat.com>:\n\n> On Thu, Jun 05, 2014 at 04:25:02PM -0400, Parisa wrote:\n> > Hi,\n> > I have installed Heat on Havana and want to test the HA template:\n> >\n>\nhttps://github.com/openstack/heat-templates/blob/master/cfn/F17/WordPress_Single_Instance_With_HA.template\n> >\n> >\n> > The stack is created successfully. When I kill httpd service inside the VM,\n> > it reboots successfully. The problem is that it is supposed to escalate and\n> > reboot the whole stack after 3 failures but it is not. I checked the\n> > cfn-push-stats.log file and it seems that the notification cannot be sent\n> to\n> > the server.\n> > The heat_watch_server_url=http://192.168.0.11:8003 is defined in heat.conf\n> > file but the port 8003 is not open on the server. I couldn\'t find anything\n> > about creating an endpoint etc in the documents.\n> >\n> > Can anybody help what is missing/wrong?\n>\n> The most likely reason is one of:\n> - heat-api-cloudwatch is not running on the machine referenced by\n>   heat_watch_server_url\n> - There is a firewall preventing access to tcp/8003 on the machine\n>   referenced by heat_watch_server_url\n>\n> My debug steps would be:\n> 1. Log on to 192.168.0.11, ps ax | grep heat-api-cloudwatch\n> 2. netstat -taupen | grep 8003 - check the API service is listening on 8003\n> 3. Log on to a VM launched by nova/heat, install nmap, nmap 192.168.0.11\n>\n> In step 3 you should see tcp/8003 open, if you don\'t then either\n> heat_watch_server_url is specifying the wrong IP or there is a firewall\n> preventing access.\n>\n> Hope that helps\n>\n> Steve\n>\n\n\n\n\n\n','<20140609131452.GA28614@t430slt.redhat.com>',NULL),('<1402344125.22935.4.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 20:02:08',0,'2014-06-09 20:02:08',NULL,'[openstack-dev] [openstack-tc]  Designate Incubation Request','On Mon, 2014-06-09 at 07:25 -0400, Sean Dague wrote:\n> On 06/06/2014 12:06 PM, Mac Innes, Kiall wrote:\n> > Several of the TC requested we have an openstack-infra managed DevStack\n> > gate enabled before they would cast their vote - I\'m happy to say, we\'ve\n> > got it :)\n> > \n> > With the merge of [1], Designate now has voting devstack /\n> > requirements / docs jobs. An example of the DevStack run is at [2].\n> > \n> > \"Vote Designate\" @ [3] :)\n> > \n> > Thanks,\n> > Kiall\n> > \n> > [1]: https://review.openstack.org/#/c/98439/\n> > [2]: https://review.openstack.org/#/c/98442/\n> > [3]: https://review.openstack.org/#/c/97609/\n> \n> I\'m seeing in [2] api logs that something was run (at least 1 API\n> request was processed), but it\'s hard to see where that is in the\n> console logs. Pointers?\n> \n> 	-Sean\n> \n\nHey Sean,\n\nYes - on Saturday, after sending this email on Friday, I noticed the\nexercises were not running - devstack-gate has them disabled by default.\n\nWe landed a patch to the job this morning to allow us to run them, and\nhave a series of patches in the check/gate queues to enable the\nexercises for all patches. An example of the output is at [1] - this\nwill be enabled for all patches once [2] lands.\n\nThanks,\nKiall\n\n[1]:\nhttp://logs.openstack.org/88/98788/6/check/gate-designate-devstack-dsvm/98b5704/console.html\n[2]: https://review.openstack.org/#/c/98788/\n\n\n\n','<539599B9.5040407@dague.net>',NULL),('<1402344125.22935.4.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-09 20:02:08',0,'2014-06-09 20:02:08',NULL,'[openstack-tc] [openstack-dev] Designate Incubation Request','On Mon, 2014-06-09 at 07:25 -0400, Sean Dague wrote:\n> On 06/06/2014 12:06 PM, Mac Innes, Kiall wrote:\n> > Several of the TC requested we have an openstack-infra managed DevStack\n> > gate enabled before they would cast their vote - I\'m happy to say, we\'ve\n> > got it :)\n> > \n> > With the merge of [1], Designate now has voting devstack /\n> > requirements / docs jobs. An example of the DevStack run is at [2].\n> > \n> > \"Vote Designate\" @ [3] :)\n> > \n> > Thanks,\n> > Kiall\n> > \n> > [1]: https://review.openstack.org/#/c/98439/\n> > [2]: https://review.openstack.org/#/c/98442/\n> > [3]: https://review.openstack.org/#/c/97609/\n> \n> I\'m seeing in [2] api logs that something was run (at least 1 API\n> request was processed), but it\'s hard to see where that is in the\n> console logs. Pointers?\n> \n> 	-Sean\n> \n\nHey Sean,\n\nYes - on Saturday, after sending this email on Friday, I noticed the\nexercises were not running - devstack-gate has them disabled by default.\n\nWe landed a patch to the job this morning to allow us to run them, and\nhave a series of patches in the check/gate queues to enable the\nexercises for all patches. An example of the output is at [1] - this\nwill be enabled for all patches once [2] lands.\n\nThanks,\nKiall\n\n[1]:\nhttp://logs.openstack.org/88/98788/6/check/gate-designate-devstack-dsvm/98b5704/console.html\n[2]: https://review.openstack.org/#/c/98788/\n\n\n\n','<539599B9.5040407@dague.net>',NULL),('<1402357199-sup-7586@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 16:42:28',-25200,'2014-06-09 23:42:28',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Douglas Mendizabal\'s message of 2014-06-09 16:08:02 -0700:\n> Hi all,\n> \n> I?m strongly in favor of having immutable TLS-typed containers, and very\n> much opposed to storing every revision of changes done to a container.  I\n> think that storing versioned containers would add too much complexity to\n> Barbican, where immutable containers would work well.\n> \n\nAgree completely. Create a new one for new values. Keep the old ones\nwhile they\'re still active.\n\n> \n> I?m still not sold on the idea of registering services with Barbican, even\n> though (or maybe especially because) Barbican would not be using this data\n> for anything.  I understand the problem that we?re trying to solve by\n> associating different resources across projects, but I don?t feel like\n> Barbican is the right place to do this.\n> \n\nAgreed also, this is simply not Barbican or Neutron\'s role. Be a REST\nAPI for secrets and networking, not all dancing all singing nannies that\nprevent any possibly dangerous behavior with said API\'s.\n\n> It seems we?re leaning towards option #2, but I would argue that\n> orchestration of services is outside the scope of Barbican?s role as a\n> secret-store.  I think this is a problem that may need to be solved at a\n> higher level.  Maybe an openstack-wide registry of dependend entities\n> across services?\n\nAn optional openstack-wide registry of depended entities is called\n\"Heat\".\n\n\n','<CFBBA569.15BF8%douglas.mendizabal@rackspace.com>',NULL),('<1402388410-sup-6493@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 01:25:11',-25200,'2014-06-10 08:25:11',NULL,'[openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle\n	collaborative meetup','Excerpts from Jaromir Coufal\'s message of 2014-06-08 16:44:58 -0700:\n> Hi,\n> \n> it looks that there is no more activity on the survey for mid-cycle \n> dates so I went forward to evaluate it.\n> \n> I created a table view into the etherpad [0] and results are following:\n> * option1 (Jul 28 - Aug 1): 27 attendees - collides with Nova/Ironic\n> * option2 (Jul 21-25)     : 27 attendees\n> * option3 (Jul 25-29)     : 17 attendees - collides with Nova/Ironic\n> * option4 (Aug 11-15)     : 13 attendees\n> \n> I think that we can remove options 3 and 4 from the consideration, \n> because there is lot of people who can\'t make it. So we have option1 and \n> option2 left. Since Robert and Devananda (PTLs on the projects) can\'t \n> make option1, which also conflicts with Nova/Ironic meetup, I think it \n> is pretty straightforward.\n> \n> Based on the survey the winning date for the mid-cycle meetup is \n> option2: July 21th - 25th.\n> \n> Does anybody have very strong reason why we shouldn\'t fix the date for \n> option2 and proceed forward with the organization for the meetup?\n> \n\nJuly 21-25 is also the shortest notice. I will not be able to attend\nas plans have already been made for the summer and I\'ve already been\ntravelling quite a bit recently, after all we were all just at the summit\na few weeks ago.\n\nI question the reasoning that being close to FF is a bad thing, and\nsuggest adding much later dates. But I understand since the chosen dates\nare so close, there is a need to make a decision immediately.\n\nAlternatively, I suggest that we split Heat out of this, and aim at\nlater dates in August.\n\n\n','<5394F57A.8010205@redhat.com>',NULL),('<1402388780-sup-4438@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 01:27:00',-25200,'2014-06-10 08:27:00',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Vijay Venkatachalam\'s message of 2014-06-09 21:48:43 -0700:\n> \n> My vote is for option #2 (without the registration). It is simpler to start with this approach. How is delete handled though?\n> \n> Ex. What is the expectation when user attempts to delete a certificate/container which is referred by an entity like LBaaS listener?\n> \n> \n> 1.       Will there be validation in Barbican to prevent this? *OR*\n> \n> 2.       LBaaS listener will have a dangling reference/pointer to certificate?\n> \n\nDangling reference. To avoid that, one should update all references\nbefore deleting.\n\n\n','<26B082831A2B1A4783604AB89B9B2C080E02CF58@SINPEX01CL03.citrite.net>',NULL),('<1402389234.11167.123.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 09:33:54',3600,'2014-06-10 08:33:54',NULL,'[openstack-dev] use of the word certified','On Mon, 2014-06-09 at 20:14 -0400, Doug Hellmann wrote:\n> On Mon, Jun 9, 2014 at 6:11 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> >\n> >\n> >> Based on the discussion I\'d like to propose these options:\n> >> 1. Cinder-certified driver - This is an attempt to move the \"certification\"\n> >> to the project level.\n> >> 2. CI-tested driver - This is probably the most accurate, at least for what\n> >> we\'re trying to achieve for Juno: Continuous Integration of Vendor-specific\n> >> Drivers.\n> >\n> > Hi Ramy,\n> >\n> > Thanks for these constructive suggestions.\n> >\n> > The second option is certainly a very direct and specific reflection of\n> > what is actually involved in getting the Cinder project\'s imprimatur.\n> \n> I do like \"tested.\"\n> \n> I\'d like to understand what the foundation is planning for\n> \"certification\" as well, to know how big of an issue this really is.\n> Even if they aren\'t going to certify drivers, I have heard discussions\n> around training and possibly other areas so I would hate for us to\n> introduce confusion by having different uses of that term in similar\n> contexts. Mark, do you know who is working on that within the board or\n> foundation?\n\nhttp://blogs.gnome.org/markmc/2014/05/17/may-11-openstack-foundation-board-meeting/\n\nBoris Renski raised the possibility of the Foundation attaching the\ntrademark to a verified, certified or tested status for drivers. It\nwasn\'t discussed at length because board members hadn\'t been briefed in\nadvance, but I think it\'s safe to say there was a knee-jerk negative\nreaction from a number of members. This is in the context of the\nDriverLog report:\n\n  http://stackalytics.com/report/driverlog\n  http://www.mirantis.com/blog/cloud-drivers-openstack-driverlog-part-1-solving-driver-problem/\n  http://www.mirantis.com/blog/openstack-will-open-source-vendor-certifications/\n\nAIUI the \"CI tested\" phrase was chosen in DriverLog to avoid the\ncontroversial area Boris describes in the last link above. I think that\nmakes sense. Claiming this CI testing replaces more traditional\ncertification programs is a sure way to bog potentially useful\ncollaboration down in vendor politics.\n\nAvoiding dragging the project into those sort of politics is something\nI\'m really keen on, and why I think the word \"certification\" is best\navoided so we can focus on what we\'re actually trying to achieve.\n\nMark.\n\n\n\n','<CADb+p3Q3115ihFHGVG_F0C6_D8oOvd4Cms0ucxn3g_-T_nE5vw@mail.gmail.com>',NULL),('<1402390111.11167.130.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 09:48:31',3600,'2014-06-10 08:48:31',NULL,'[openstack-dev] [marconi] Reconsidering the unified API model','On Mon, 2014-06-09 at 19:31 +0000, Kurt Griffiths wrote:\n> Lately we have been talking about writing drivers for traditional\n> message brokers that will not be able to support the message feeds\n> part of the API. I?ve started to think that having a huge part of the\n> API that may or may not ?work?, depending on how Marconi is deployed,\n> is not a good story for users, esp. in light of the push to make\n> different clouds more interoperable.\n\nPerhaps the first point to get super clear on is why drivers for\ntraditional message brokers are needed. What problems would such drivers\naddress? Who would the drivers help? Would the Marconi team recommend\nusing any of those drivers for a production queuing service? Would the\nsubset of Marconi\'s API which is implementable by these drivers really\nbe useful for application developers?\n\nI\'d like to understand that in more detail because I worry the Marconi\nteam is being pushed into adding these drivers without truly believing\nthey will be useful. And if that would not be a sane context to make a\nserious architectural change.\n\nOTOH if there are real, valid use cases for these drivers, then\nunderstanding those would inform the architecture decision.\n\nMark.\n\n\n\n','<CFBB542C.23720%kurt.griffiths@rackspace.com>',NULL),('<1402409223.11167.133.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 15:07:03',3600,'2014-06-10 14:07:03',NULL,'[openstack-dev] use of the word certified','On Tue, 2014-06-10 at 14:06 +0100, Duncan Thomas wrote:\n> On 10 June 2014 09:33, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > Avoiding dragging the project into those sort of politics is something\n> > I\'m really keen on, and why I think the word \"certification\" is best\n> > avoided so we can focus on what we\'re actually trying to achieve.\n> \n> Avoiding those sorts of politics - \'XXX says it is a certified config,\n> it doesn\'t work, cinder is junk\' - is why I\'d rather the cinder core\n> team had a certification program, at least we\'ve some control then and\n> *other* people can\'t impose their idea of certification on us. I think\n> politics happens, whether you will it or not, so a far more sensible\n> stance is to play it out in advance.\n\nExposing which configurations are actively \"tested\" is a perfectly sane\nthing to do. I don\'t see why you think calling this \"certification\" is\nnecessary to achieve your goals. I don\'t know what you mean be \"others\nimposing their idea of certification\".\n\nMark.\n\n\n\n\n','<CAOyZ2aHMpzCKwe=X-MBpAkwr8oTy3XEDsUdhhQgPxaqVdUtmWQ@mail.gmail.com>',NULL),('<1402417817.2927.4.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 11:30:17',-18000,'2014-06-10 16:30:17',NULL,'[openstack-dev] [requirements] Odd behavior from requirements checks','I\'ve been seeing failures from the requirements gating check on changes\nproposed by the requirements bot.  It\'s actually complaining that the\nproposed changes don\'t match what\'s in global-requirements.txt, even\nthough they are textually identical.  An example is here:\n\n        http://logs.openstack.org/68/96268/6/check/gate-python-novaclient-requirements/ea3cdf2/console.html\n\nAnyone have any insights into this?  I\'ve seen the same thing happening\non nova.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1402419201.11167.176.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 17:53:21',3600,'2014-06-10 16:53:21',NULL,'[openstack-dev] use of the word certified','On Tue, 2014-06-10 at 16:09 +0100, Duncan Thomas wrote:\n> On 10 June 2014 15:07, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > Exposing which configurations are actively \"tested\" is a perfectly sane\n> > thing to do. I don\'t see why you think calling this \"certification\" is\n> > necessary to achieve your goals.\n> \n> What is certification except a formal way of saying \'we tested it\'? At\n> least when you test it enough to have some degree of confidence in\n> your testing.\n> \n> That\'s *exactly* what certification means.\n\nI disagree. I think the word has substantially more connotations than\nsimply \"this has been tested\".\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-June/036963.html\n\n> > I don\'t know what you mean be \"others\n> > imposing their idea of certification\".\n> \n> I mean that if some company or vendor starts claiming \'Product X is\n> certified for use with cinder\',\n\nOn what basis would any vendor claim such certification?\n\n>  that is bad for the cinder core team,\n> since we didn\'t define what got tested or to what degree.\n\nThat sounds like you mean \"Storage technology X is certified for use\nwith Vendor Y OpenStack?\".\n\ni.e. that Vendor Y has certified the driver for use with their version\nif OpenStack but the Cinder team has no influence over what that means\nin practice?\n\n> Whether we like it or not, when something doesn\'t work in cinder, it\n> is rare for people to blame the storage vendor in their complaints.\n> \'Cinder is broken\' is what we hear (and I\'ve heard it, even though\n> what they meant is \'my storage vendor hasn\'t tested or updated their\n> driver in two releases\', that isn\'t what they /said/).\n\nPresumably people are complaining about that driver not working with\nsome specific downstream version of OpenStack, right? Not e.g.\nstable/icehouse devstack or something?\n\ni.e. even aside from the driver, we\'re already talking about something\nwe as an upstream project don\'t control the quality of.\n\n> Since cinder,\n> and therefore cinder-core, is going to get the blame, I feel we should\n> try to maintain some degree of control over the claims.\n\nI\'m starting to see where you\'re coming from, but I fear this\n\"certification\" thing will make it even worse.\n\nRight now you can easily shrug off any responsibility for the quality of\na third party driver or an untested in-tree driver. Sure, some people\nmay have unreasonable expectations about such things, but you can\'t stop\npeople being idiots. You can better communicate expectations, though,\nand that\'s excellent.\n\nBut as soon as you \"certify\" that driver cinder-core takes on a\nresponsibility that I would think is unreasonable even if the driver was\ntested. \"But you said it\'s certified!\"\n\nIs cinder-core really ready to take on responsibility for every issue\nusers see with \"certified\" drivers and downstream OpenStack products?\n\n> If we run our own minimal certification program, which is what we\'ve\n> started doing (started with a script which did a test run and tried to\n> require vendors to run it, that didn\'t work out well so we\'re now\n> requiring CI integration instead), then we at least have the option of\n> saying \'You\'re running an non-certified product, go talk to your\n> vendor\' when dealing with the cases we have no control over. Vendors\n> that don\'t follow the CI & cert requirements eventually get their\n> driver removed, that simple.\n\nWhat about issues with a \"certified\" driver? Don\'t talk to the vendor,\ntalk to us instead?\n\nIf it\'s an out-of-tree driver then we say \"talk to your vendor\". \n\nIf it\'s an in-tree driver, those actively maintaining the driver provide\n\"best effort community support\" like anything else.\n\nIf it\'s an in-tree driver and isn\'t being actively maintained, and \"best\neffort community support\" isn\'t being provided, then we need a way to\ncommunicate that unmaintained status. The level of testing it receives\nis what we currently see as the most important aspect, but it\'s not the\nonly aspect.\n\nIf the user is actually using a distro or other downstream product\nrather than pure upstream, it\'s completely normal for upstream to say\n\"talk to your distro maintainers or product vendor\".\n\nUpstream projects can only provide limited support for even motivated\nand clueful users, particularly when those users are actually using\ndownstream variants of the project. It certainly makes sense to clarify\nthat, but a \"certification\" program will actually raise the expectations\nusers have about the level of support upstream will provide.\n\nMark.\n\n\n\n','<CAOyZ2aF3he6pOUKxc-tmjz_cMDhUNb5rYEGhLE-apch2obzT3g@mail.gmail.com>',NULL),('<1402429125.701.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 19:38:45',0,'2014-06-10 19:38:45',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Any core neutron people have a chance to give their opinions on this\nyet?\n\nThanks,\nBrandon\n\nOn Thu, 2014-06-05 at 15:28 +0000, Buraschi, Andres wrote:\n> Thanks, Kyle. Great.\n> \n> -----Original Message-----\n> From: Kyle Mestery [mailto:mestery at noironetworks.com] \n> Sent: Thursday, June 05, 2014 11:27 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n> \n> On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan <brandon.logan at rackspace.com> wrote:\n> > Hi Andres,\n> > I\'ve assumed (and we know how assumptions work) that the deprecation \n> > would take place in Juno and after a cyle or two it would totally be \n> > removed from the code.  Even if #1 is the way to go, the old /vips \n> > resource would be deprecated in favor of /loadbalancers and /listeners.\n> >\n> > I agree #2 is cleaner, but I don\'t want to start on an implementation \n> > (though I kind of already have) that will fail to be merged in because \n> > of the strategy.  The strategies are pretty different so one needs to \n> > be decided on.\n> >\n> > As for where LBaaS is intended to end up, I don\'t want to speak for \n> > Kyle, so this is my understanding; It will end up outside of the \n> > Neutron code base but Neutron and LBaaS and other services will all \n> > fall under a Networking (or Network) program.  That is my \n> > understanding and I could be totally wrong.\n> >\n> That\'s my understanding as well, I think Brandon worded it perfectly.\n> \n> > Thanks,\n> > Brandon\n> >\n> > On Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:\n> >> Hi Brandon, hi Kyle!\n> >> I\'m a bit confused about the deprecation (btw, thanks for sending this Brandon!), as I (wrongly) assumed #1 would be the chosen path for the new API implementation. I understand the proposal and #2 sounds actually cleaner.\n> >>\n> >> Just out of curiosity, Kyle, where is LBaaS functionality intended to end up, if long-term plans are to remove it from Neutron?\n> >>\n> >> (Nit question, I must clarify)\n> >>\n> >> Thank you!\n> >> Andres\n> >>\n> >> -----Original Message-----\n> >> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n> >> Sent: Wednesday, June 04, 2014 2:18 PM\n> >> To: openstack-dev at lists.openstack.org\n> >> Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API\n> >>\n> >> Thanks for your feedback Kyle.  I will be at that meeting on Monday.\n> >>\n> >> Thanks,\n> >> Brandon\n> >>\n> >> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n> >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan \n> >> > <brandon.logan at rackspace.com> wrote:\n> >> > > This is an LBaaS topic bud I\'d like to get some Neutron Core \n> >> > > members to give their opinions on this matter so I\'ve just \n> >> > > directed this to Neutron proper.\n> >> > >\n> >> > > The design for the new API and object model for LBaaS needs to be \n> >> > > locked down before the hackathon in a couple of weeks and there \n> >> > > are some questions that need answered.  This is pretty urgent to \n> >> > > come on to a decision on and to get a clear strategy defined so \n> >> > > we can actually do real code during the hackathon instead of \n> >> > > wasting some of that valuable time discussing this.\n> >> > >\n> >> > >\n> >> > > Implementation must be backwards compatible\n> >> > >\n> >> > > There are 2 ways that have come up on how to do this:\n> >> > >\n> >> > > 1) New API and object model are created in the same extension and \n> >> > > plugin as the old.  Any API requests structured for the old API \n> >> > > will be translated/adapted to the into the new object model.\n> >> > > PROS:\n> >> > > -Only one extension and plugin\n> >> > > -Mostly true backwards compatibility -Do not have to rename \n> >> > > unchanged resources and models\n> >> > > CONS:\n> >> > > -May end up being confusing to an end-user.\n> >> > > -Separation of old api and new api is less clear -Deprecating and \n> >> > > removing old api and object model will take a bit more work -This \n> >> > > is basically API versioning the wrong way\n> >> > >\n> >> > > 2) A new extension and plugin are created for the new API and \n> >> > > object model.  Each API would live side by side.  New API would \n> >> > > need to have different names for resources and object models from \n> >> > > Old API resources and object models.\n> >> > > PROS:\n> >> > > -Clean demarcation point between old and new -No translation \n> >> > > layer needed -Do not need to modify existing API and object \n> >> > > model, no new bugs -Drivers do not need to be immediately \n> >> > > modified -Easy to deprecate and remove old API and object model \n> >> > > later\n> >> > > CONS:\n> >> > > -Separate extensions and object model will be confusing to \n> >> > > end-users -Code reuse by copy paste since old extension and \n> >> > > plugin will be deprecated and removed.\n> >> > > -This is basically API versioning the wrong way\n> >> > >\n> >> > > Now if #2 is chosen to be feasible and acceptable then there are \n> >> > > a number of ways to actually do that.  I won\'t bring those up \n> >> > > until a clear decision is made on which strategy above is the most acceptable.\n> >> > >\n> >> > Thanks for sending this out Brandon. I\'m in favor of option #2 \n> >> > above, especially considering the long-term plans to remove LBaaS \n> >> > from Neutron. That approach will help the eventual end goal there. \n> >> > I am also curious on what others think, and to this end, I\'ve added \n> >> > this as an agenda item for the team meeting next Monday. Brandon, \n> >> > it would be great to get you there for the part of the meeting \n> >> > where we\'ll discuss this.\n> >> >\n> >> > Thanks!\n> >> > Kyle\n> >> >\n> >> > > Thanks,\n> >> > > Brandon\n> >> > >\n> >> > >\n> >> > >\n> >> > >\n> >> > >\n> >> > >\n> >> > > _______________________________________________\n> >> > > OpenStack-dev mailing list\n> >> > > OpenStack-dev at lists.openstack.org \n> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0AC7A1AE4CF0F441BFB83181010D122F299FFA02@fmsmsx115.amr.corp.intel.com>',NULL),('<1402433956.9491.9.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 21:59:16',3600,'2014-06-10 20:59:16',NULL,'[openstack-dev] [marconi] Reconsidering the unified API model','On Tue, 2014-06-10 at 17:33 +0000, Janczuk, Tomasz wrote:\n> From my perspective the key promise of Marconi is to provide a\n> *multi-tenant*, *HTTP* based queuing system. Think an OpenStack equivalent\n> of SQS or Azure Storage Queues.\n> \n> As far as I know there are no off-the-shelve message brokers out these\n> that fit that bill.\n> \n> Note that when I say ?multi-tenant? I don?t mean just having multi-tenancy\n> concept reflected in the APIs. The key aspect of the multi-tenancy is\n> security hardening against a variety of attacks absent in single-tenant\n> broker deployments. For example, an authenticated DOS attack.\n\nNicely described.\n\nNow why is there a desire to implement these requirements using\ntraditional message brokers?\n\nAnd what Marconi API semantics are impossible to implement using\ntraditional message brokers?\n\nEither those semantics are fundamental requirements for this API, or the\nrequirement to have support for traditional message brokers is the\nfundamental requirement. We can\'t have it both ways.\n\nMy suspicion is the API semantics are seen by the Marconi team as the\nfundamental requirement, and the support for message brokers is very\nmuch a secondary concern. If that\'s the case, perhaps just label those\ndrivers as \"experimental and not recommended\" and allow them to return a\n501 Not Implemented? Yes, it sucks for portability, but all you\'re doing\nis creating space for experimenting with backing Marconi with a message\nbroker ... not actually recommending it for deployment.\n\nMark.\n\n\n\n','<CFBC8E8B.238D%tomasz.janczuk@hp.com>',NULL),('<1402434206.9491.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 22:03:26',3600,'2014-06-10 21:03:26',NULL,'[openstack-dev] [marconi] Reconsidering the unified API model','On Tue, 2014-06-10 at 21:59 +0100, Mark McLoughlin wrote:\n> On Tue, 2014-06-10 at 17:33 +0000, Janczuk, Tomasz wrote:\n> > From my perspective the key promise of Marconi is to provide a\n> > *multi-tenant*, *HTTP* based queuing system. Think an OpenStack equivalent\n> > of SQS or Azure Storage Queues.\n> > \n> > As far as I know there are no off-the-shelve message brokers out these\n> > that fit that bill.\n> > \n> > Note that when I say ?multi-tenant? I don?t mean just having multi-tenancy\n> > concept reflected in the APIs. The key aspect of the multi-tenancy is\n> > security hardening against a variety of attacks absent in single-tenant\n> > broker deployments. For example, an authenticated DOS attack.\n> \n> Nicely described.\n> \n> Now why is there a desire to implement these requirements using\n> traditional message brokers?\n> \n> And what Marconi API semantics are impossible to implement using\n> traditional message brokers?\n\nAh, my apologies. This question answered most excellently here:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-June/037177.html\n\nMark.\n\n> Either those semantics are fundamental requirements for this API, or the\n> requirement to have support for traditional message brokers is the\n> fundamental requirement. We can\'t have it both ways.\n> \n> My suspicion is the API semantics are seen by the Marconi team as the\n> fundamental requirement, and the support for message brokers is very\n> much a secondary concern. If that\'s the case, perhaps just label those\n> drivers as \"experimental and not recommended\" and allow them to return a\n> 501 Not Implemented? Yes, it sucks for portability, but all you\'re doing\n> is creating space for experimenting with backing Marconi with a message\n> broker ... not actually recommending it for deployment.\n> \n> Mark.\n\n\n\n\n','<1402433956.9491.9.camel@sorcha>',NULL),('<1402435157.9491.19.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 22:19:17',3600,'2014-06-10 21:19:17',NULL,'[openstack-dev] [oslo] versioning and releases','On Tue, 2014-06-10 at 12:24 -0400, Doug Hellmann wrote:\n> As part of the push to release code from the oslo incubator in\n> stand-alone libraries, we have had several different discussions about\n> versioning and release schedules. This is an attempt to collect all of\n> the decisions we have made in those discussions and to lay out the\n> rationale for the approach we are taking. I don\'t expect any of this\n> to be a surprise, since we\'ve talked about it, but I haven\'t actually\n> written it all down in one place before so some of you might not have\n> seen all of the points. Please let me know if you see any issues with\n> the proposal or have questions. If everyone agrees that this makes\n> sense, I\'ll put it in the wiki.\n\nNice work Doug, this is looking great.\n\n> Background:\n> \n> We have two types of oslo libraries. Libraries like oslo.config and\n> oslo.messaging were created by extracting incubated code, updating the\n> public API, and packaging it. Libraries like cliff and taskflow were\n> created as standalone packages from the beginning, and later adopted\n> by the oslo team to manage their development and maintenance.\n> \n> Incubated libraries have been released at the end of a release cycle,\n> as with the rest of the integrated packages. Adopted libraries have\n> historically been released \"as needed\" during their development. We\n> would like to synchronize these so that all oslo libraries are\n> officially released with the rest of the software created by OpenStack\n> developers.\n> \n> The first release of oslo.config was 1.1.0, as part of the grizzly\n> release. The first release of oslo.messaging was 1.2.0, as part of the\n> havana release. oslo.config was also updated to 1.2.0 during havana.\n> All current adopted libraries have release numbers less than 1.0.0.\n> \n> In the past, alpha releases of oslo libraries have been distributed as\n> tarballs on an openstack server, with official releases going to PyPI.\n> Applications that required the alpha release specified the tarball in\n> their requirements list, followed by a version specifier. This allowed\n> us to prepare alpha releases, without worrying that their release\n> would break continuous-deployment systems by making new library\n> releases available to pip. This approach still made it difficult for\n> an application developer to rely on new features of an oslo library,\n> until an alpha version was produced.\n> \n> When the PyPI mirror was introduced in our CI system, relying on\n> tarballs not available on the mirror conflicted with our desire to\n> have the gate system install *only* from the package mirror. As we are\n> now installing only from the mirror, we need to publish our alpha\n> releases in a format that will work with the mirror.\n> \n> We already gate OpenStack applications and oslo libraries using\n> integration tests using the normal devstack-gate jobs. During Icehouse\n> we had a couple of oslo library releases that broke unit tests of\n> applications after the library was released. We plan to address that\n> with separate gating jobs during juno. In addition to that gating, we\n> need to support developers who want to use new features of oslo\n> libraries before official releases are available.\n> \n> A Version Numbering Scheme:\n> \n> At the Juno summit, Josh proposed that we use semantic versioning\n> (SemVer) for oslo libraries [1]. Part of that proposal also included\n> ideas for allowing breaking backwards compatibility at some release\n> boundaries, and I am explicitly *not* addressing\n> backwards-incompatible changes beyond saying that we do not expect to\n> have any during Juno. We do need to solve the problem of breaking API\n> compatibility, but I want to take one step at a time. The first step\n> is choosing a rational release versioning scheme.\n> \n> SemVer is widely used and gives us relatively clear guidelines about\n> choosing new version numbers. It supports alpha releases, which are\n> going to be key to meeting some of our other requirements. I propose\n> that we adopt pbr\'s modified SemVer [2] for new releases, beginning\n> with Juno.\n> \n> The versions for existing libraries oslo.config and oslo.messaging\n> will be incremented from their Icehouse versions but updating the\n> minor number (1.x.0) at the end of the Juno cycle.\n> \n> All adopted libraries using numbers less than 1.0 will be released as\n> 1.0.0 at the end of the Juno cycle, based on the fact that we expect\n> deployers to use them in production.\n\nPerhaps not directly related to this proposal, but IMHO OpenStack should\nnot depend on any semver-versioned libraries which are still on 0.x.\n\ni.e. we should not depend on API unstable projects (because of the pain\nit imposes on everyone), particularly ones that are likely to feel\nempowered to break their API at will because of their version number :)\n\n> Releases during Juno should *all* be marked as alphas of the\n> anticipated upcoming SemVer-based release number (1.0.0.0aN or\n> 1.2.0.0aN or whatever).\n\nWhy not simply 1.2.0aN btw?\n\n>  The new CI system can create packages as\n> Python wheels and publish them to the appropriate servers, which means\n> projects will no longer need to refer explicitly to pre-release\n> tarballs.\n\nThe details are a bit more nuanced here - pip won\'t install alpha\nlibraries unless you explicitly request them with a command line flag to\ninstall any alphas available or you explicitly require the alpha\nversion.\n\nThe wheels aspect is that pip <= 1.3 didn\'t support this, but also\ndidn\'t support wheels ... so we publish alphas only as wheels to ensure\nthat older pips don\'t see them.\n\n> Releases after Juno will follow a similar pattern, incrementing the\n> minor number and using alpha releases within the development cycle.\n> \n> [1] https://etherpad.openstack.org/p/juno-oslo-semantic-versioning\n> [2] http://docs.openstack.org/developer/pbr/semver.html\n> \n> Frequent Alpha Releases:\n> \n> While we can run gate jobs using the master branch of oslo libraries,\n> developers will have to take extra steps to run unit tests this way\n> locally. To reduce this process overhead, while still ensuring that\n> developers use current versions of the code, we should produce alpha\n> releases of libraries during the release cycle fairly frequently. I\n> suggest that we start with a weekly check-up during the oslo team\n> meetings, and that we tag releases early on Mondays when deemed\n> necessary.\n> \n> Patch Releases:\n> \n> Updates to existing library releases can be made from stable branches.\n> Checking out stable/icehouse of oslo.config for example would allow a\n> release 1.3.1. We don\'t have a formal policy about whether we will\n> create patch releases, or whether applications are better off using\n> the latest release of the library. Do we need one?\n\nI\'m not sure we need one, but if we did I\'d expect them to be aligned\nwith stable releases.\n\nRight now, I think they\'d just be as-needed - if there\'s enough\nbackported to the stable branch to warrant a release, we just cut one.\n\n> We do not typically use upper bounds on the requirements\n> specifications for oslo libraries, so new releases may automatically\n> be adopted by continuous-deployment systems building packages for\n> stable branches of OpenStack applications. Although we have been\n> careful about API compatibility in the past, there is a chance that a\n> new release could break an older application. Applications could add\n> an upper bound using SemVer numbering if they choose, although that\n> may prevent them from seeing bug fixes.\n\nI think applications should only add an upper bound on the major number\nso they don\'t see API breakage e.g.\n\n  oslo.config>=1.2.0,<2\n\nIf applications have an upper bound on the minor number, that indicates\na lack of confidence in our ability to add new features without breaking\nthe API.\n\n> Unit test gate jobs:\n> \n> We have a blueprint for Juno to add cross-project unit test gating for\n> applications and oslo libraries [3]. This will allow us to verify that\n> tests for applications do not break when oslo libraries change, but\n> also that those tests do not make assumptions about oslo library\n> implementation details.\n> \n> Depending on how the job is implemented, we may be able to reuse the\n> tools to let developers run the same tests locally. More thought is\n> needed here; stay tuned.\n> \n> [3] https://blueprints.launchpad.net/oslo/+spec/enhance-cross-test-gate-job\n\nVery cool stuff!\n\nMark.\n\n\n\n','<CADb+p3Sv-7E0Z1=vLAYndPjWTkRXCSexiuhYy8u6pkR0Vjrhnw@mail.gmail.com>',NULL),('<1402440278.2685.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 22:44:37',0,'2014-06-10 22:44:37',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Well we got a few opinions, but not enough understanding of the two\noptions to make an informed decision.  It was requested that the core\nreviewers respond to this thread with their opinions.\n\nThanks,\nBrandon\n\nOn Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:\n> Yep, I\'d like to know here, too--  as knowing the answer to this\n> unblocks implementation work for us.\n> \n> \n> On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Any core neutron people have a chance to give their opinions\n>         on this\n>         yet?\n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Thu, 2014-06-05 at 15:28 +0000, Buraschi, Andres wrote:\n>         > Thanks, Kyle. Great.\n>         >\n>         > -----Original Message-----\n>         > From: Kyle Mestery [mailto:mestery at noironetworks.com]\n>         > Sent: Thursday, June 05, 2014 11:27 AM\n>         > To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         > Subject: Re: [openstack-dev] [Neutron] Implementing new\n>         LBaaS API\n>         >\n>         > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan\n>         <brandon.logan at rackspace.com> wrote:\n>         > > Hi Andres,\n>         > > I\'ve assumed (and we know how assumptions work) that the\n>         deprecation\n>         > > would take place in Juno and after a cyle or two it would\n>         totally be\n>         > > removed from the code.  Even if #1 is the way to go, the\n>         old /vips\n>         > > resource would be deprecated in favor of /loadbalancers\n>         and /listeners.\n>         > >\n>         > > I agree #2 is cleaner, but I don\'t want to start on an\n>         implementation\n>         > > (though I kind of already have) that will fail to be\n>         merged in because\n>         > > of the strategy.  The strategies are pretty different so\n>         one needs to\n>         > > be decided on.\n>         > >\n>         > > As for where LBaaS is intended to end up, I don\'t want to\n>         speak for\n>         > > Kyle, so this is my understanding; It will end up outside\n>         of the\n>         > > Neutron code base but Neutron and LBaaS and other services\n>         will all\n>         > > fall under a Networking (or Network) program.  That is my\n>         > > understanding and I could be totally wrong.\n>         > >\n>         > That\'s my understanding as well, I think Brandon worded it\n>         perfectly.\n>         >\n>         > > Thanks,\n>         > > Brandon\n>         > >\n>         > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:\n>         > >> Hi Brandon, hi Kyle!\n>         > >> I\'m a bit confused about the deprecation (btw, thanks for\n>         sending this Brandon!), as I (wrongly) assumed #1 would be the\n>         chosen path for the new API implementation. I understand the\n>         proposal and #2 sounds actually cleaner.\n>         > >>\n>         > >> Just out of curiosity, Kyle, where is LBaaS functionality\n>         intended to end up, if long-term plans are to remove it from\n>         Neutron?\n>         > >>\n>         > >> (Nit question, I must clarify)\n>         > >>\n>         > >> Thank you!\n>         > >> Andres\n>         > >>\n>         > >> -----Original Message-----\n>         > >> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n>         > >> Sent: Wednesday, June 04, 2014 2:18 PM\n>         > >> To: openstack-dev at lists.openstack.org\n>         > >> Subject: Re: [openstack-dev] [Neutron] Implementing new\n>         LBaaS API\n>         > >>\n>         > >> Thanks for your feedback Kyle.  I will be at that meeting\n>         on Monday.\n>         > >>\n>         > >> Thanks,\n>         > >> Brandon\n>         > >>\n>         > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:\n>         > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan\n>         > >> > <brandon.logan at rackspace.com> wrote:\n>         > >> > > This is an LBaaS topic bud I\'d like to get some\n>         Neutron Core\n>         > >> > > members to give their opinions on this matter so I\'ve\n>         just\n>         > >> > > directed this to Neutron proper.\n>         > >> > >\n>         > >> > > The design for the new API and object model for LBaaS\n>         needs to be\n>         > >> > > locked down before the hackathon in a couple of weeks\n>         and there\n>         > >> > > are some questions that need answered.  This is\n>         pretty urgent to\n>         > >> > > come on to a decision on and to get a clear strategy\n>         defined so\n>         > >> > > we can actually do real code during the hackathon\n>         instead of\n>         > >> > > wasting some of that valuable time discussing this.\n>         > >> > >\n>         > >> > >\n>         > >> > > Implementation must be backwards compatible\n>         > >> > >\n>         > >> > > There are 2 ways that have come up on how to do this:\n>         > >> > >\n>         > >> > > 1) New API and object model are created in the same\n>         extension and\n>         > >> > > plugin as the old.  Any API requests structured for\n>         the old API\n>         > >> > > will be translated/adapted to the into the new object\n>         model.\n>         > >> > > PROS:\n>         > >> > > -Only one extension and plugin\n>         > >> > > -Mostly true backwards compatibility -Do not have to\n>         rename\n>         > >> > > unchanged resources and models\n>         > >> > > CONS:\n>         > >> > > -May end up being confusing to an end-user.\n>         > >> > > -Separation of old api and new api is less clear\n>         -Deprecating and\n>         > >> > > removing old api and object model will take a bit\n>         more work -This\n>         > >> > > is basically API versioning the wrong way\n>         > >> > >\n>         > >> > > 2) A new extension and plugin are created for the new\n>         API and\n>         > >> > > object model.  Each API would live side by side.  New\n>         API would\n>         > >> > > need to have different names for resources and object\n>         models from\n>         > >> > > Old API resources and object models.\n>         > >> > > PROS:\n>         > >> > > -Clean demarcation point between old and new -No\n>         translation\n>         > >> > > layer needed -Do not need to modify existing API and\n>         object\n>         > >> > > model, no new bugs -Drivers do not need to be\n>         immediately\n>         > >> > > modified -Easy to deprecate and remove old API and\n>         object model\n>         > >> > > later\n>         > >> > > CONS:\n>         > >> > > -Separate extensions and object model will be\n>         confusing to\n>         > >> > > end-users -Code reuse by copy paste since old\n>         extension and\n>         > >> > > plugin will be deprecated and removed.\n>         > >> > > -This is basically API versioning the wrong way\n>         > >> > >\n>         > >> > > Now if #2 is chosen to be feasible and acceptable\n>         then there are\n>         > >> > > a number of ways to actually do that.  I won\'t bring\n>         those up\n>         > >> > > until a clear decision is made on which strategy\n>         above is the most acceptable.\n>         > >> > >\n>         > >> > Thanks for sending this out Brandon. I\'m in favor of\n>         option #2\n>         > >> > above, especially considering the long-term plans to\n>         remove LBaaS\n>         > >> > from Neutron. That approach will help the eventual end\n>         goal there.\n>         > >> > I am also curious on what others think, and to this\n>         end, I\'ve added\n>         > >> > this as an agenda item for the team meeting next\n>         Monday. Brandon,\n>         > >> > it would be great to get you there for the part of the\n>         meeting\n>         > >> > where we\'ll discuss this.\n>         > >> >\n>         > >> > Thanks!\n>         > >> > Kyle\n>         > >> >\n>         > >> > > Thanks,\n>         > >> > > Brandon\n>         > >> > >\n>         > >> > >\n>         > >> > >\n>         > >> > >\n>         > >> > >\n>         > >> > >\n>         > >> > > _______________________________________________\n>         > >> > > OpenStack-dev mailing list\n>         > >> > > OpenStack-dev at lists.openstack.org\n>         > >> > >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         > >> >\n>         > >> > _______________________________________________\n>         > >> > OpenStack-dev mailing list\n>         > >> > OpenStack-dev at lists.openstack.org\n>         > >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         > >>\n>         > >> _______________________________________________\n>         > >> OpenStack-dev mailing list\n>         > >> OpenStack-dev at lists.openstack.org\n>         > >>\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         > >>\n>         > >> _______________________________________________\n>         > >> OpenStack-dev mailing list\n>         > >> OpenStack-dev at lists.openstack.org\n>         > >>\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         > >\n>         > > _______________________________________________\n>         > > OpenStack-dev mailing list\n>         > > OpenStack-dev at lists.openstack.org\n>         > >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZpZHkOZBJF3So3Y2Sc7d1WkhsjwstYXDj_V2hxDS9d0HA@mail.gmail.com>',NULL),('<1402456074.1787.15.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 13:07:54',36000,'2014-06-11 03:07:54',NULL,'[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading\n clients from a CONF object','Among the problems cause by the inconsistencies in the clients is that\nall the options that are required to create a client need to go into the\nconfig file of the service. This is a pain to configure from the server\nside and can result in missing options as servers fail to keep up.\n\nWith the session object standardizing many of these options there is the\nintention to make the session be loadable directly from a CONF object. A\nspec has been proposed to this for nova-specs[1] to outline the problem\nand the approach in more detail. \n\nThe TL;DR version is that I intend to collapse all the options to load a\nclient down such that each client will have one ini section that looks\nvaguely like: \n\n        [cinder]\n        cafile = \'/path/to/cas\'\n        certfile = \'path/to/cert\'\n        timeout = 5\n        auth_name = v2password\n        username = \'user\'\n        password = \'pass\'\n        \nThis list of options is then managed from keystoneclient, thus servers\nwill automatically have access to new transport options, authentication\nmechanisms and security fixes as they become available.\n\nThe point of this email is to make people aware of this effort and that\nif accepted into nova-specs the same pattern will eventually make it to\nyour service (as clients get updated and manpower allows). \n\nThe review containing the config option names is still open[2] so if you\nwish to comment on particulars, please take a look.\n\nPlease leave a comment on the reviews or reply to this email with\nconcerns or questions. \n\nThanks \n\nJamie\n\n[1] https://review.openstack.org/#/c/98955/\n[2] https://review.openstack.org/#/c/95015/\n\n\n\n',NULL,NULL),('<1402459452.59499.YahooMailNeo@web125903.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-10 21:04:12',-25200,'2014-06-11 04:04:12',NULL,'[Openstack-docs] need sarob added to gerrit acls','for?openstack-training-guides-core,?openstack-training-guides-ptl\n?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140610/38732fd4/attachment.html>\n\n',NULL,NULL),('<1402511122.12636.17.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 14:25:22',-14400,'2014-06-11 18:25:22',NULL,'[openstack-dev] [TripleO] ongoing resize issues','A few months back several of us were consistently hitting file system\nresize issues. After making a slight change to diskimage-builder to fix\n[1] things seem to have gotten better... but I still hear people\noccasionally mentioning issues.\n\nOn the ext4 mailing list it appears there are still some ongoing issues\nwith the resize2fs code. A recent thread indicates a new fuzzer may help\nfind some of these cases [2]. Perhaps this is good news given that we\nrely heavily on this code when resizing root partitions. This is a\nnormal cloudy sort of thing (cloud-init does this!) but our parameters\nin TripleO are most likely off the beaten path so perhaps we hit issues\nmore often.\n\nIf you find these sorts of issues please report them. Also, when I\'ve\nhit resize issues in the past I\'ve found that it is usually reproducible\nif I retry it using the same disk image (file system layout).\n\n[1] https://bugs.launchpad.net/diskimage-builder/+bug/1280709\n[2] http://marc.info/?l=linux-ext4&m=140134096120976&w=2\n\n\n\n',NULL,NULL),('<1402513734-sup-1084@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 12:14:09',-25200,'2014-06-11 19:14:09',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Adam Harwell\'s message of 2014-06-10 12:04:41 -0700:\n> So, it looks like any sort of validation on Deletes in Barbican is going\n> to be a no-go. I\'d like to propose a third option, which might be the\n> safest route to take for LBaaS while still providing some of the\n> convenience of using Barbican as a central certificate store. Here is a\n> diagram of the interaction sequence to create a loadbalancer:\n> http://bit.ly/1pgAC7G\n> \n> Summary: Pass the Barbican \"TLS Container ID\" to the LBaaS create call,\n> get the container from Barbican, and store a \"shadow-copy\" of the\n> container again in Barbican, this time on the LBaaS service account.\n> The secret will now be duplicated (it still exists on the original tenant,\n> but also exists on the LBaaS tenant), but we\'re not talking about a huge\n> amount of data here -- just a few kilobytes. With this approach, we retain\n> most of the advantages we wanted to get from using Barbican -- we don\'t\n> need to worry about taking secret data through the LBaaS API (we still\n> just take a barbicanID from the user), and the user can still use a single\n> barbicanID (the original one they created -- the copies are invisible to\n> them) when passing their TLS info to other services. We gain the\n> additional advantage that it no longer matters what happens to the\n> original TLS container -- it could be deleted and it would not impact our\n> service.\n> \n> What do you guys think of that option?\n\nA user hands LBaaS an ID, and then deletes it, and expects that LBaaS\ncan continue working indefinitely? How is that user\'s reckless action\nLBaaS\'s problem?\n\nDo one thing: Be a good load balancer. Let users orchestrate your APIs\naccording to their use case and tools.\n\n\n','<CFBCBCFD.82D9%adam.harwell@rackspace.com>',NULL),('<1402517324.13813.42.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 21:08:44',3600,'2014-06-11 20:08:44',NULL,'[openstack-dev] [oslo][messaging] Further improvements and\n refactoring','Hi,\n\nOn Tue, 2014-06-10 at 15:47 +0400, Dina Belova wrote:\n> Dims,\n> \n> \n> No problem with creating the specs, we just want to understand if the\n> community is OK with our suggestions in general :)\n> If so, I\'ll create the appropriate specs and we\'ll discuss them :)\n\nPersonally, I find it difficult to understand the proposals as currently\ndescribed and how they address the performance problems you say you see.\n\nThe specs process should help flesh out your ideas so they are more\nunderstandable. On the other hand, it\'s pretty difficult to have an\nabstract conversation about code re-factoring. So, some combination of\nproof-of-concept patches and specs will probably work best.\n\nMark.\n\n\n\n\n','<CACsCO2waW7+=CTWaKGk+BeiHPHwgROBNr_J6AyTRAc-5NhBxyA@mail.gmail.com>',NULL),('<1402517896.13813.43.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 21:18:16',3600,'2014-06-11 20:18:16',NULL,'[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading\n clients from a CONF object','On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote:\n> On 11/06/14 15:07, Jamie Lennox wrote:\n> > Among the problems cause by the inconsistencies in the clients is that\n> > all the options that are required to create a client need to go into the\n> > config file of the service. This is a pain to configure from the server\n> > side and can result in missing options as servers fail to keep up.\n> >\n> > With the session object standardizing many of these options there is the\n> > intention to make the session be loadable directly from a CONF object. A\n> > spec has been proposed to this for nova-specs[1] to outline the problem\n> > and the approach in more detail. \n> >\n> > The TL;DR version is that I intend to collapse all the options to load a\n> > client down such that each client will have one ini section that looks\n> > vaguely like: \n> >\n> >         [cinder]\n> >         cafile = \'/path/to/cas\'\n> >         certfile = \'path/to/cert\'\n> >         timeout = 5\n> >         auth_name = v2password\n> >         username = \'user\'\n> >         password = \'pass\'\n> >         \n> > This list of options is then managed from keystoneclient, thus servers\n> > will automatically have access to new transport options, authentication\n> > mechanisms and security fixes as they become available.\n> >\n> > The point of this email is to make people aware of this effort and that\n> > if accepted into nova-specs the same pattern will eventually make it to\n> > your service (as clients get updated and manpower allows). \n> >\n> > The review containing the config option names is still open[2] so if you\n> > wish to comment on particulars, please take a look.\n> >\n> > Please leave a comment on the reviews or reply to this email with\n> > concerns or questions. \n> >\n> > Thanks \n> >\n> > Jamie\n> >\n> > [1] https://review.openstack.org/#/c/98955/\n> > [2] https://review.openstack.org/#/c/95015/\n> Heat already needs to have configuration options for every client, and\n> we\'ve gone with the following pattern:\n> http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612\n> \n> Do you have any objection to aligning with what we already have?,\n> specifically:\n> [clients_<clientname>]\n> ca_file=...\n> cert_file=...\n> key_file=...\n\nSounds like there\'s a good case for an Oslo API for creating client\nobjects from configuration.\n\nMark.\n\n\n\n','<5397E1B2.40308@redhat.com>',NULL),('<1402524100-sup-4403@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 22:17:17',0,'2014-06-11 22:17:17',NULL,'[openstack-dev] [TripleO] pacemaker management tools','> The issue is that distributions supported in TripleO provide different \n> tools for managing Pacemaker. Ubuntu/Debian provides crmsh, Fedora/RHEL \n> provides pcs, OpenSuse provides both. I didn\'t find packages for all our \n> distros for any of the tools. Also if there is a third-party repo \n> providing packages for various distros, adding dependency on an \n> untrusted third-party repo might be a problem for some users.\n> \n> Although it\'s a little bit annoying, I think we will end up with \n> managing commands for both config tools, a resource creation sample:\n> \n> if $USE_PCS;then\n>    crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params \n> ip=192.168.122.120 cidr_netmask=32 op monitor interval=30s\n> else\n>    pcs resource create ClusterIP IPaddr2 ip=192.168.0.120 cidr_netmask=32\n> fi\n\nThis seems like a reasonable solution if we can ensure that we have CI\nfor both branches of the installation. This is a big issue with our\ncurrent mariadb/percona installation and it sounds like were heading\ndown the same path here.\n\nIf we can make USE_PCS directly dependent on the installed distro that\nwould be sufficient (CI for each distro would take care of the different\nbranches) but this gets a bit more complicated if you want to split crm\nand pcs out into different elements (like in mariadb vs percona)...\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<53983D77.6030608@redhat.com>',NULL),('<1402527184.7218.5.camel@kiall-laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 22:53:06',0,'2014-06-11 22:53:06',NULL,'[openstack-dev] Designate Incubation Request (Approved)','On Sat, 2014-05-24 at 17:24 +0000, Hayes, Graham wrote:\n> Hi all,\n> \n> Designate would like to apply for incubation status in OpenStack.\n> \n> Our application is here: \n> https://wiki.openstack.org/wiki/Designate/Incubation_Application \n> \n> As part of our application we would like to apply for a new program. Our\n> application for the program is here:\n> \n> https://wiki.openstack.org/wiki/Designate/Program_Application \n> \n> Designate is a DNS as a Service project, providing both end users,\n> developers, and administrators with an easy to use REST API to manage\n> their DNS Zones and Records.\n> \n> Thanks,\n> \n> Graham\n\nWith the +2/+A on [1] - Designate is now officially incubated :)\n\nThanks to everyone for the support, especially everyone who has joined\nthe project over the last year or so!\n\nThanks,\nKiall\n\n[1]: https://review.openstack.org/#/c/97609/\n\n','<1400952296.32582.0.camel@graham-desk-13-10>',NULL),('<1402527184.7218.5.camel@kiall-laptop>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-11 22:53:06',0,'2014-06-11 22:53:06',NULL,'[openstack-tc] [openstack-dev] Designate Incubation Request\n	(Approved)','On Sat, 2014-05-24 at 17:24 +0000, Hayes, Graham wrote:\n> Hi all,\n> \n> Designate would like to apply for incubation status in OpenStack.\n> \n> Our application is here: \n> https://wiki.openstack.org/wiki/Designate/Incubation_Application \n> \n> As part of our application we would like to apply for a new program. Our\n> application for the program is here:\n> \n> https://wiki.openstack.org/wiki/Designate/Program_Application \n> \n> Designate is a DNS as a Service project, providing both end users,\n> developers, and administrators with an easy to use REST API to manage\n> their DNS Zones and Records.\n> \n> Thanks,\n> \n> Graham\n\nWith the +2/+A on [1] - Designate is now officially incubated :)\n\nThanks to everyone for the support, especially everyone who has joined\nthe project over the last year or so!\n\nThanks,\nKiall\n\n[1]: https://review.openstack.org/#/c/97609/\n\n','<1400952296.32582.0.camel@graham-desk-13-10>',NULL),('<1402528317.22858.54.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-12 01:11:57',7200,'2014-06-11 23:11:57',NULL,'[OpenStack-Infra] moving Activity Board fully under openstack-ci','On Mon, 2014-06-09 at 09:31 -0700, Monty Taylor wrote:\n> On 06/09/2014 12:11 AM, Jesus M. Gonzalez-Barahona wrote:\n> > On Sun, 2014-06-08 at 13:32 -0400, Monty Taylor wrote:\n> >> On 06/02/2014 06:32 PM, Jesus M. Gonzalez-Barahona wrote:\n> >>> On Mon, 2014-06-02 at 14:31 -0700, Stefano Maffulli wrote:\n> >>>> Hello folks\n> >>>>\n> >>>> I wanted to get your thoughts on the idea to move the whole Bitergia\n> >>>> grimoire engine, scripts, database, etc to the openstack common\n> >>>> infrastructure. I\'m sure everybody will want this so the question is\n> >>>> more about resources as in people willing to help Bitergia get their\n> >>>> machinery puppetized the \"OpenStack-CI way\".\n> >>>>\n> >>>> At the moment the various spiders and scripts run on a machine on\n> >>>> Bitergia\'s end and they drop the results of the elaboration (json, html,\n> >>>> css files and sql dumps) on activity.openstack.org/dash/.\n> >>>>\n> >>>> While this setup is convenient and has been working so far, I think\n> >>>> we\'ve outgrown it. One of the areas that we want to do more with is the\n> >>>> datawarehouse built by Bitergia, enable it to serve other purposes too\n> >>>> and allow more collaboration from the community. For example, once the\n> >>>> tools are all out in one place, interested parties could build some sort\n> >>>> of service on top of your datawarehouse to export the data about the\n> >>>> affiliation. Others could build tools to \'fix\' such affiliation, pulling\n> >>>> the various mailmap files used by gitdm and stackalytics.\n> >>>>\n> >>>> The question for OpenStack-CI is then: in the next weeks/months, is\n> >>>> there going to be someone free, from the CI team or someone willing to\n> >>>> join it (Dan?), to help Bitergia\'s team get their tools on our\n> >>>> infrastructure?\n> >>>\n> >>> Thanks for the introduction of the issue, Stefano.\n> >>>\n> >>> Just to clarify a bit the needs to move all the Grimoire machinery to a\n> >>> vm under openstack-ci, the software is split in three main parts:\n> >>\n> >> Awesome.\n> >>\n> >>> * MetricsGrimoire tools, which mine repositories (git, Launchpad, etc.),\n> >>> and store the data into a MySQL database (well, in fact, one schema per\n> >>> kind of repository).\n> >>>\n> >>> * The MySQL database itself.\n> >>>\n> >>> * The vizGrimoire tools, that run the analysis, produce JSON files, and\n> >>> the HTML/CSS/JavaScript files needed to serve the dashboard. All of this\n> >>> is for now static, which means that you only need to serve those files\n> >>> via HTTP, and you\'re done: no live queries to the database once the JSON\n> >>> files are produced.\n> >>>\n> >>> Right now, we produce the JSON files once a day. That means that\n> >>> MetricsGrimoire is first run once a day (the tools know how to get\n> >>> incremental information from repositories), data is updated in the\n> >>> database, and then vizGrimoire analysis is run. All of this is\n> >>> controlled by automator, the tool that is configured with the list of\n> >>> repos to analyze, the analysis to run, etc.\n> >>>\n> >>> MetricsGrimoire tools are written in Python. There are some Python\n> >>> dependencies beyond Python 2.7, but I guess all of them are\n> >>> straightforward from pypy.\n> >>\n> >> Where are these stored/installed from? Is it \"pip install\n> >> MetricsGrimoire\"? Is it in a git repo? Does this git repo want to move\n> >> into openstack tooling or does it want to stay where it is and have\n> >> openstack-infra consume releases?\n> > \n> > Those are different tools in git repos. Providing them via pip could be\n> > a part of the process, anyway: that\'s something we have in the roadmap\n> > for a while. Right now, openstack-infra would consume the repositories.\n> \n> git repos is fine - we install several things directly from git - just\n> was curious. I\'m assuming based on this email so far that you want to\n> keep your git repos in github?\n> \n> > More info about MetricsGrimoire, and its repos:\n> > \n> > http://metricsgrimoire.github.io\n> \n> Sweet. Thanks.\n> \n> >>> The MySQL is a plain MySQL. It would be great having it in SSD, because\n> >>> that speeds up queries a lot. But probably it will work with regular\n> >>> disks.\n> >>\n> >> We use cloud-based databases from Rackspace\'s Trove service. I have no\n> >> idea what sort of disk is behind it - but MySQL databases are no problem.\n> > \n> > ok. It\'s mainly a matter of performance, I guess Trove would be ok.\n> > \n> >>> Most of vizGrimoire is also Python, but there is still some R code\n> >>> (we\'re currently moving towards a pure-Python implementation). Python\n> >>> and R dependencies are easy too (from pypy or CRAN).\n> >>\n> >> Same questions as above on MetricsGrimoire. Do you have docs anywhere on\n> >> installing these two things?\n> > \n> > For MetricsGrimoire, it is very close to \"just standard Python install\".\n> > But vizGrimoire is another story. Right now, it is a moving target, so\n> > probably the best thing would be that we install it, and document the\n> > procedure in detail for you. In the process, we could automate some\n> > steps that are not automated yet.\n> \n> Let\'s work through your script below and the puppet first. There\'s not\n> much value in having you install something on a server because then we\n> don\'t know anything about running it in the future, and if there is a\n> major failure and we have to rebuild, we won\'t be confident that our\n> automation can do the job. You have the code running currently and\n> publishing to activity - so I don\'t think there is an urgency in getting\n> the code running elsewhere- the real benefit is in getting it tied in to\n> normal process for us so we can run it together.\n> \n> > In any case, some more info about vizGrimoire:\n> > \n> > http://vizgrimoire.github.io\n> > \n> > I guess the closer thing we have to a install doc is:\n> > \n> > https://github.com/MetricsGrimoire/Automator/wiki/Install\n> \n> Sweet. Putting it on my reading list.\n> \n> > (Automator is the script that runs all the party)\n> > \n> >>> We\'re usually deploying on Debian or Ubuntu, but we have some experience\n> >>> with other Linux-based OSs too.\n> >>\n> >> Great. All of our services run on Ubuntu Precise right now. We\'ll be\n> >> starting to think about an upgrade to trusty.\n> >>\n> >>> We could do the whole deployment, if you can provide us with a\n> >>> Debian/Ubuntu vm, including proper documentation to reproduce it if\n> >>> needed.\n> >>\n> >> All of our deployments are done in a fully automated manner driven from\n> >> our puppet repo: https://git.openstack.org/cgit/openstack-infra/config.\n> >> However - we\'d be more than happy for you to write the puppet! (and\n> >> happy to help with pointers)\n> >>\n> >> I just wrote the puppet to run stackalytics in Infra:\n> >>\n> >> https://review.openstack.org/98656\n> >>\n> >> It\'s probably a great place to start in terms of looking at puppetizing\n> >> activity board. If someone can write up something similar to:\n> >>\n> >> https://wiki.openstack.org/wiki/Stackalytics/HowToRun\n> >>\n> >> I\'ll be more likely to do what I did today which is wake up on a Sunday\n> >> and lazily write some puppet while watching Rafael Nadal win his ninth\n> >> French Open. :)\n> > \n> > ;-)\n> > \n> > Thanks for the pointers, Monty. Therefore, I assume that the first thing\n> > to do is to have a detailed installation information and/or Puppet\n> > config files. We\'re not that familiar with Puppet, so maybe the best\n> > thing for us would be to start writing the detailed docs, and after that\n> > starting with the Puppet thing... Right?\n> \n> Oh - you\'ll know puppet for sure by the time we get done with you. :)\n> \n> Seriously though - more than happy to help drive the puppet side of\n> things if you have detailed instructions on how to install. I want you\n> to learn and be involved in that - but I also don\'t want you to be\n> totally blocked on the concept.\n> \n\nThanks a lot, Monty,\n\n>From this discussion, I guess the first step is on our side, and it\nwould be producing detailed instructions on how we install the\nmachinery, so that those can be a first step for the puppetization,\nright?\n\nWe\'re going to schedule this asap. I\'ll let you know when exactly, so\nthat we can start with the real game.\n\nSaludos,\n\n	Jesus.\n\n-- \n-- \nBitergia: http://bitergia.com http://blog.bitergia.com\n\n\n\n','<5395E17F.8090901@inaugust.com>',NULL),('<1402530457.28076.13.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 09:47:37',36000,'2014-06-11 23:47:37',NULL,'[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading\n clients from a CONF object','On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote:\n> On 12/06/14 08:18, Mark McLoughlin wrote:\n> > On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote:\n> >> On 11/06/14 15:07, Jamie Lennox wrote:\n> >>> Among the problems cause by the inconsistencies in the clients is that\n> >>> all the options that are required to create a client need to go into the\n> >>> config file of the service. This is a pain to configure from the server\n> >>> side and can result in missing options as servers fail to keep up.\n> >>>\n> >>> With the session object standardizing many of these options there is the\n> >>> intention to make the session be loadable directly from a CONF object. A\n> >>> spec has been proposed to this for nova-specs[1] to outline the problem\n> >>> and the approach in more detail. \n> >>>\n> >>> The TL;DR version is that I intend to collapse all the options to load a\n> >>> client down such that each client will have one ini section that looks\n> >>> vaguely like: \n> >>>\n> >>>         [cinder]\n> >>>         cafile = \'/path/to/cas\'\n> >>>         certfile = \'path/to/cert\'\n> >>>         timeout = 5\n> >>>         auth_name = v2password\n> >>>         username = \'user\'\n> >>>         password = \'pass\'\n> >>>         \n> >>> This list of options is then managed from keystoneclient, thus servers\n> >>> will automatically have access to new transport options, authentication\n> >>> mechanisms and security fixes as they become available.\n> >>>\n> >>> The point of this email is to make people aware of this effort and that\n> >>> if accepted into nova-specs the same pattern will eventually make it to\n> >>> your service (as clients get updated and manpower allows). \n> >>>\n> >>> The review containing the config option names is still open[2] so if you\n> >>> wish to comment on particulars, please take a look.\n> >>>\n> >>> Please leave a comment on the reviews or reply to this email with\n> >>> concerns or questions. \n> >>>\n> >>> Thanks \n> >>>\n> >>> Jamie\n> >>>\n> >>> [1] https://review.openstack.org/#/c/98955/\n> >>> [2] https://review.openstack.org/#/c/95015/\n> >> Heat already needs to have configuration options for every client, and\n> >> we\'ve gone with the following pattern:\n> >> http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612\n> >>\n> >> Do you have any objection to aligning with what we already have?,\n> >> specifically:\n> >> [clients_<clientname>]\n> >> ca_file=...\n> >> cert_file=...\n> >> key_file=...\n\nNo, i can use those options - i went with the former because that\'s what\nis used by auth_token middleware and i assumed everyone would be\nfamiliar with them. I don\'t think it matters what is used so long as\nit\'s consistent.\n\nRegarding the [clients_<clientname>] that header name would be passed as\na parameter so services can still do what they like there. \n\n> > Sounds like there\'s a good case for an Oslo API for creating client\n> > objects from configuration.\n> >\n> Yes it does. Although depending on the use-case, the combination of\n> config options and arguments will be different.\n> \n> An Oslo API to solve the problem of every client requiring special\n> snowflake creation code[1][2] would be very useful.\n\nSo i have another review[3] that is attempting to standardize other\ncommon components of the client and how they relate to session. This\nobject would be created by the client though so i\'m not yet sure how we\nwould go about using this to do common config options. It might be as\nsimple as creating the common client **kwargs from the config and then\nhaving the services initialize the clients with them. \n\nAt least there is potential there if all clients take those some common\nset of variables. There are always going to be some options that are\nunique to a client that will have to be handled manually though.\n\n> [1]\n> https://review.openstack.org/#/c/97981/5/heat/engine/clients/os/cinder.py\n> [2]\n> https://review.openstack.org/#/c/97980/5/heat/engine/clients/os/neutron.py\n\n[3] https://review.openstack.org/#/c/86237/\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<5398C679.4030104@redhat.com>',NULL),('<1402531344.28076.24.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 10:02:24',36000,'2014-06-12 00:02:24',NULL,'[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading\n clients from a CONF object','On Wed, 2014-06-11 at 04:43 +0000, Angus Salkeld wrote:\n> On 11/06/14 13:10, Jamie Lennox wrote:\n> > Among the problems cause by the inconsistencies in the clients is that\n> > all the options that are required to create a client need to go into the\n> > config file of the service. This is a pain to configure from the server\n> > side and can result in missing options as servers fail to keep up.\n> > \n> > With the session object standardizing many of these options there is the\n> > intention to make the session be loadable directly from a CONF object. A\n> > spec has been proposed to this for nova-specs[1] to outline the problem\n> > and the approach in more detail. \n> > \n> > The TL;DR version is that I intend to collapse all the options to load a\n> > client down such that each client will have one ini section that looks\n> > vaguely like: \n> > \n> >         [cinder]\n> >         cafile = \'/path/to/cas\'\n> >         certfile = \'path/to/cert\'\n> >         timeout = 5\n> >         auth_name = v2password\n> >         username = \'user\'\n> >         password = \'pass\'\n> >         \n> > This list of options is then managed from keystoneclient, thus servers\n> > will automatically have access to new transport options, authentication\n> > mechanisms and security fixes as they become available.\n> > \n> > The point of this email is to make people aware of this effort and that\n> > if accepted into nova-specs the same pattern will eventually make it to\n> > your service (as clients get updated and manpower allows). \n> > \n> > The review containing the config option names is still open[2] so if you\n> > wish to comment on particulars, please take a look.\n> > \n> > Please leave a comment on the reviews or reply to this email with\n> > concerns or questions. \n> \n> Nice, we have this bug too in Solum: https://bugs.launchpad.net/solum/+bug/1292334\n> \n> It is partly about the duplication in code needed to get a client.\n> The other part of the bug is the config options (which you are dealing with).\n> \n> The other thing to think about is other services want a connection based on\n> user token (plus the cafile stuff above) like in solum/heat.\n> \n> It would be nice to be able to create a connection based on a context and a config.\n> \n> You might also want to look at Steve Baker\'s monster patch series:\n> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/client-plugins,n,z\n> \n> This stuff should really be in the clients.\n> \n> -Angus\n\nIndeed, so this is part of the reason for the separation of session and\nauth plugin. Session will often want to be client dependent (though\nthere\'s no reason not to share) and simply loaded from conf, but auth\nmay need to be from conf or user based.\n\nMy current thought is that i pass down an auth plugin out of auth_token\nmiddleware so that starting a client with user credentials would look\nsomething like: \n\n    sess = session.Session.from_config_options(CONF, \'cinder\')\n    sess.auth = env[\'keystone.user_auth_plugin\']\n    \n    cinder = cinderclient.v1.client.Client(sess) \n\nThat auth plugin would be fairly simple so you could easily construct it\nfrom the context or from the headers created by auth_token (i don\'t know\nhow common the context object is between services to do it that way). \n\n> > \n> > Thanks \n> > \n> > Jamie\n> > \n> > [1] https://review.openstack.org/#/c/98955/\n> > [2] https://review.openstack.org/#/c/95015/\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<B8CF6F6CCA9E6749ACCD473169B95B721AC78ED8@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1402532321-sup-2323@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 17:19:59',-25200,'2014-06-12 00:19:59',NULL,'[openstack-dev] [marconi] Reconsidering the unified API model','Excerpts from Janczuk, Tomasz\'s message of 2014-06-11 10:05:54 -0700:\n> On 6/11/14, 2:43 AM, \"Gordon Sim\" <gsim at redhat.com> wrote:\n> \n> >On 06/10/2014 09:57 PM, Janczuk, Tomasz wrote:\n> >> Using processes to isolate tenants is certainly possible. There is a\n> >>range\n> >> of isolation mechanisms that can be used, from VM level isolation\n> >> (basically a separate deployment of the broker per-tenant), to process\n> >> level isolation, to sub-process isolation. The higher the density the\n> >> lower the overall marginal cost of adding a tenant to the system, and\n> >> overall cost of operating it. From the cost perspective it is therefore\n> >> desired to provide sub-process multi-tenancy mechanism; at the same time\n> >> this is the most challenging approach.\n> >\n> >Where does the increased cost for process level isolation come from? Is\n> >it simply the extra process required (implying an eventual limit for a\n> >given VM)?\n> >\n> >With sub-process isolation you have to consider the fairness of\n> >scheduling between operations for different tenants, i.e. potentially\n> >limiting the processing done on behalf of any given tenant in a given\n> >period. You would also need to limit the memory used on behalf of any\n> >given tenant. Wouldn\'t you end up reinventing much of what the operating\n> >system does?\n> >\n> \n> Process level isolation is more costly than sub-process level isolation\n> primarily due to larger memory consumption. For example, CGI has worse\n> cost characteristics than FastCGI when scaled out. But the example closer\n> to Marconi?s use case is database systems: I can?t put my finger on a\n> single one that would isolate queries executed by its users using\n> processes. \n\nThere\'s at least one, and it is fairly popular:\n\nhttp://www.postgresql.org/docs/9.3/static/tutorial-arch.html\n\n\"The PostgreSQL server can handle multiple concurrent connections from\nclients. To achieve this it starts (\"forks\") a new process for each\nconnection. From that point on, the client and the new server process\ncommunicate without intervention by the original postgres process.\"\n\n\n','<CFBDD791.24E7%tomasz.janczuk@hp.com>',NULL),('<1402558926-sup-8267@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 00:51:59',-25200,'2014-06-12 07:51:59',NULL,'[openstack-dev] [Heat]Heat template parameters encryption','I tend to agree with you Keith, securing Heat is Heat\'s problem.\nSecuring Nova is nova\'s problem. And I too would expect that those with\nadmin access to Heat, would not have admin access to Nova. That is why\nwe split these things up with API\'s.\n\nI still prefer that users encrypt secrets on the client side, and store\nsaid secrets in Barbican, passing only a temporary handle into templates\nfor consumption.\n\nBut until we have that, just encrypting hidden parameters would be simple\nto do and I wouldn\'t even mind it being on by default in devstack because\nonly a small percentage of parameters are \"hidden\". My initial\nreluctance to the plan was in encrypting everything, as that makes\nverifying things a lot harder. But just encrypting the passwords.. I\nthink that\'s a decent plan.\n\nA couple of ideas:\n\n* Provide a utility to change the key (must update the entire database).\n* Allow multiple decryption keys (to enable tool above to work\n  slowly).\n\nExcerpts from Keith Bray\'s message of 2014-06-11 22:29:13 -0700:\n> \n> On 6/11/14 2:43 AM, \"Steven Hardy\" <shardy at redhat.com> wrote:\n> \n> >>IMO, when a template author marks a parameter as hidden/secret, it seems\n> >>incorrect to store that information in plain text.\n> >\n> >Well I\'d still question why we\'re doing this, as my previous questions\n> >have\n> >not been answered:\n> >- AFAIK nova user-data is not encrypted, so surely you\'re just shifting\n> >the\n> >  attack vector from one DB to another in nearly all cases?\n> \n> Having one system (e.g. Nova) not as secure as it could be isn\'t a reason\n> to not secure another system as best we can. For every attack vector you\n> close, you have another one to chase. I\'m concerned that the merit of the\n> feature is being debated, so let me see if I can address that:\n> \n> We want to use Heat to launch customer facing stacks.  In a UI, we would\n> prompt customers for Template inputs, including for example: Desired\n> Wordpress Admin Password, Desired MySQL password, etc. The UI then makes\n> an API call to Heat to orchestrate instantiation of the stack.  With Heat\n> as it is today, these customer specified credentials (as template\n> parameters) would be stored in Heat\'s database in plain text. As a Heat\n> Service Administrator, I do not need nor do I want the customer\'s\n> Wordpress application password to be accessible to me.  The application\n> belongs to the customer, not to the infrastructure provider.  Sure, I\n> could blow the customer\'s entire instance away as the service provider.\n> But, if I get fired or leave the company, I could no longer can blow away\n> their instance... If I leave the company, however, I could have taken a\n> copy of the Heat DB with me, or had looked that info up in the Heat DB\n> before my exit, and I could then externally attack the customer\'s\n> Wordpress instance.  It makes no sense for us to store user specified\n> creds unencrypted unless we are administering the customer\'s Wordpress\n> instance for them, which we are not.  We are administering the\n> infrastructure only.  I realize the encryption key could also be stolen,\n> but in a \"production\" system the encryption key access gets locked down to\n> a VERY small set of folks and not all the people that administer Heat\n> (that\'s part of good security practices and makes auditing of a leaked\n> encryption key much easier).\n>   \n> >- Is there any known way for heat to \"leak sensitive user data\", other\n> >than\n> >  a cloud operator with admin access to the DB stealing it?  Surely cloud\n> >  operators can trivially access all your resources anyway, including\n> >  instances and the nova DB/API so they have this data anyway.\n> \n> Encrypting the data in the DB also helps in case if a leak of arbitrary DB\n> data does surface in Heat.  We are not aware of any issues with Heat today\n> that could leak that data... But, we never know what vulnerabilities will\n> be introduced or discovered in the future.\n> \n> \n> At Rackspace, individual cloud operators can not trivially access all\n> customer cloud resources.  When operating a large cloud at scale, service\n> administrator\'s operations and capabilities are limited to the systems\n> they work on.  While I could impersonate a user via Heat and do lot\'s of\n> bad things across many of their resources, each of the other systems\n> (Nova, Databases, Auth, etc.) audit the who is doing what on behave of\n> what customer, so I can\'t do something malicious to a customer\'s Nova\n> instance without the Auth System Administrators ensuring that HR knows I\n> would be the person to blame.  Similarly, a Nova system administrator\n> can\'t delete a customer\'s Heat stack without our Heat administrators\n> knowing who is to blame.  We have checks and balances across our systems\n> and purposefully segment our possible attack vectors.\n> \n> Leaving sensitive customer data unencrypted at rest provides many more\n> options for that data to get in the wrong hands or be taken outside the\n> company.  It is quick and easy to do a MySQL dump if the DB linux system\n> is compromised, which has nothing to do with Heat having a vulnerability.\n> \n> Our ask is to provide an optional way for the service operator to allow\n> template authors to choose what data is sensitive, and if the data is\n> marked sensitive, it gets encrypted by the Heat system as opposed to\n> storing in plain txt.\n> \n> I hope this helps.  Vijendar, feel free to take some of this write-up and\n> include it in a gerit review of the feature blueprint.\n> \n> Thanks,\n> -Keith\n> \n\n\n','<CFBDFAD0.2D29D%keith.bray@rackspace.com>',NULL),('<1402579335.13813.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 14:22:15',3600,'2014-06-12 13:22:15',NULL,'[openstack-dev] [oslo] versioning and releases','On Thu, 2014-06-12 at 12:09 +0200, Thierry Carrez wrote:\n> Doug Hellmann wrote:\n> > On Tue, Jun 10, 2014 at 5:19 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> >> On Tue, 2014-06-10 at 12:24 -0400, Doug Hellmann wrote:\n> >> [...]\n> >>> Background:\n> >>>\n> >>> We have two types of oslo libraries. Libraries like oslo.config and\n> >>> oslo.messaging were created by extracting incubated code, updating the\n> >>> public API, and packaging it. Libraries like cliff and taskflow were\n> >>> created as standalone packages from the beginning, and later adopted\n> >>> by the oslo team to manage their development and maintenance.\n> >>>\n> >>> Incubated libraries have been released at the end of a release cycle,\n> >>> as with the rest of the integrated packages. Adopted libraries have\n> >>> historically been released \"as needed\" during their development. We\n> >>> would like to synchronize these so that all oslo libraries are\n> >>> officially released with the rest of the software created by OpenStack\n> >>> developers.\n> \n> Could you outline the benefits of syncing with the integrated release ?\n\nSure!\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2012-November/003345.html\n\n:)\n\n> Personally I see a few drawbacks to this approach:\n> \n> We dump the new version on consumers usually around RC time, which is\n> generally a bad time to push a new version of a	dependency and detect\n> potential breakage. Consumers just seem to get the new version at the\n> worst possible time.\n> \n> It also prevents from spreading the work all over the cycle. For example\n> it may have been more successful to have the oslo.messaging new release\n> by milestone-1 to make sure it\'s adopted by projects in milestone-2 or\n> milestone-3... rather than have it ready by milestone-3 and expect all\n> projects to use it by consuming alphas during the cycle.\n> \n> Now if *all* projects were continuously consuming alpha versions, most\n> of those drawbacks would go away.\n\nYes, that\'s the plan. Those issues are acknowledged and we\'re reasonably\nconfident the alpha versions plan will address them.\n\n> >>> [...]\n> >>> Patch Releases:\n> >>>\n> >>> Updates to existing library releases can be made from stable branches.\n> >>> Checking out stable/icehouse of oslo.config for example would allow a\n> >>> release 1.3.1. We don\'t have a formal policy about whether we will\n> >>> create patch releases, or whether applications are better off using\n> >>> the latest release of the library. Do we need one?\n> >>\n> >> I\'m not sure we need one, but if we did I\'d expect them to be aligned\n> >> with stable releases.\n> >>\n> >> Right now, I think they\'d just be as-needed - if there\'s enough\n> >> backported to the stable branch to warrant a release, we just cut one.\n> > \n> > That\'s pretty much what I thought, too. We shouldn\'t need to worry\n> > about alphas for patch releases, since we won\'t add features.\n> \n> Yes, I think we can be pretty flexible about it. But to come back to my\n> above remark... should it be stable/icehouse or stable/1.3 ?\n\nIt\'s a branch for bugfix releases of the icehouse version of the\nlibrary, so I think stable/icehouse makes sense.\n\nMark.\n\n\n\n','<53997C57.8040400@openstack.org>',NULL),('<1402593778-sup-3857@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 10:28:35',-25200,'2014-06-12 17:28:35',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n	in the gate','Excerpts from Matt Riedemann\'s message of 2014-06-12 08:15:46 -0700:\n> \n> On 6/12/2014 9:38 AM, Mike Bayer wrote:\n> >\n> > On 6/12/14, 8:26 AM, Julien Danjou wrote:\n> >> On Thu, Jun 12 2014, Sean Dague wrote:\n> >>\n> >>> That\'s not cacthable in unit or functional tests?\n> >> Not in an accurate manner, no.\n> >>\n> >>> Keeping jobs alive based on the theory that they might one day be useful\n> >>> is something we just don\'t have the liberty to do any more. We\'ve not\n> >>> seen an idle node in zuul in 2 days... and we\'re only at j-1. j-3 will\n> >>> be at least +50% of this load.\n> >> Sure, I\'m not saying we don\'t have a problem. I\'m just saying it\'s not a\n> >> good solution to fix that problem IMHO.\n> >\n> > Just my 2c without having a full understanding of all of OpenStack\'s CI\n> > environment, Postgresql is definitely different enough that MySQL\n> > \"strict mode\" could still allow issues to slip through quite easily, and\n> > also as far as capacity issues, this might be longer term but I\'m hoping\n> > to get database-related tests to be lots faster if we can move to a\n> > model that spends much less time creating databases and schemas.\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> Is there some organization out there that uses PostgreSQL in production \n> that could stand up 3rd party CI with it?\n> \n> I know that at least for the DB2 support we\'re adding across the \n> projects we\'re doing 3rd party CI for that. Granted it\'s a proprietary \n> DB unlike PG but if we\'re talking about spending resources on testing \n> for something that\'s not widely used, but there is a niche set of users \n> that rely on it, we could/should move that to 3rd party CI.\n> \n> I\'d much rather see us spend our test resources on getting multi-node \n> testing running in the gate so we can test migrations in Nova.\n> \n\nI think this is really the answer. To paraphrase the wise and well\nexperienced engineer, Beyonc?:\n\n\"If you like it then you shoulda put CI on it.\"\n\nThe project will succumb to a tragedy of the commons if it bends over\nbackwards for every deployment variation available. But 3rd parties who\ncare can always contribute resources and (if they play nice...) votes.\n\nI think there are a tiny number of things that will cause corner case\nbugs that could creep in, but as Sean says, we haven\'t actually seen\nthese.\n\n\n','<5399C422.1010505@linux.vnet.ibm.com>',NULL),('<1402612279.2523.143.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 15:31:19',-25200,'2014-06-12 22:31:19',NULL,'[openstack-dev] [containers][nova][cinder] Cinder support in\n containers and unprivileged container-in-container','On Thu, 2014-06-12 at 21:57 +0000, Adrian Otto wrote:\n> Containers Team,\n> \n> The nova-docker developers are currently discussing options for\n> implementation for supporting mounting of Cinder volumes in\n> containers, and creation of unprivileged containers-in-containters.\n> Both of these currently require CAP_SYS_ADMIN[1] which is problematic\n> because if granted within a container, can lead to an escape from the\n> container back into the host.\n\nWhy would you mount it from within the container?  CAP_SYS_ADMIN is a\nper process property, so you use nsenter to execute the mount in the\nrequired mount namespace with CAP_SYS_ADMIN from outside of the\ncontainer (i.e. the host).  I assume this requires changes to cinder so\nit executes a mount rather than presenting a mountable device node, but\nit\'s the same type of change we have to do for mounts which have no\nnode, like bind mounts.\n\nJames\n\n\n\n\n','<94898B9A-0035-46B4-8E2F-6DA3E72A92B2@rackspace.com>',NULL),('<1402615650.28076.29.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 09:27:30',36000,'2014-06-12 23:27:30',NULL,'[openstack-dev] [nova][cinder][ceilometer][glance][all] Loading\n clients from a CONF object','On Wed, 2014-06-11 at 19:52 -0400, Sean Dague wrote:\n> On 06/11/2014 07:47 PM, Jamie Lennox wrote:\n> > On Thu, 2014-06-12 at 09:13 +1200, Steve Baker wrote:\n> >> On 12/06/14 08:18, Mark McLoughlin wrote:\n> >>> On Wed, 2014-06-11 at 16:57 +1200, Steve Baker wrote:\n> >>>> On 11/06/14 15:07, Jamie Lennox wrote:\n> >>>>> Among the problems cause by the inconsistencies in the clients is that\n> >>>>> all the options that are required to create a client need to go into the\n> >>>>> config file of the service. This is a pain to configure from the server\n> >>>>> side and can result in missing options as servers fail to keep up.\n> >>>>>\n> >>>>> With the session object standardizing many of these options there is the\n> >>>>> intention to make the session be loadable directly from a CONF object. A\n> >>>>> spec has been proposed to this for nova-specs[1] to outline the problem\n> >>>>> and the approach in more detail. \n> >>>>>\n> >>>>> The TL;DR version is that I intend to collapse all the options to load a\n> >>>>> client down such that each client will have one ini section that looks\n> >>>>> vaguely like: \n> >>>>>\n> >>>>>         [cinder]\n> >>>>>         cafile = \'/path/to/cas\'\n> >>>>>         certfile = \'path/to/cert\'\n> >>>>>         timeout = 5\n> >>>>>         auth_name = v2password\n> >>>>>         username = \'user\'\n> >>>>>         password = \'pass\'\n> >>>>>         \n> >>>>> This list of options is then managed from keystoneclient, thus servers\n> >>>>> will automatically have access to new transport options, authentication\n> >>>>> mechanisms and security fixes as they become available.\n> >>>>>\n> >>>>> The point of this email is to make people aware of this effort and that\n> >>>>> if accepted into nova-specs the same pattern will eventually make it to\n> >>>>> your service (as clients get updated and manpower allows). \n> >>>>>\n> >>>>> The review containing the config option names is still open[2] so if you\n> >>>>> wish to comment on particulars, please take a look.\n> >>>>>\n> >>>>> Please leave a comment on the reviews or reply to this email with\n> >>>>> concerns or questions. \n> >>>>>\n> >>>>> Thanks \n> >>>>>\n> >>>>> Jamie\n> >>>>>\n> >>>>> [1] https://review.openstack.org/#/c/98955/\n> >>>>> [2] https://review.openstack.org/#/c/95015/\n> >>>> Heat already needs to have configuration options for every client, and\n> >>>> we\'ve gone with the following pattern:\n> >>>> http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/heat.conf.sample#n612\n> >>>>\n> >>>> Do you have any objection to aligning with what we already have?,\n> >>>> specifically:\n> >>>> [clients_<clientname>]\n> >>>> ca_file=...\n> >>>> cert_file=...\n> >>>> key_file=...\n> > \n> > No, i can use those options - i went with the former because that\'s what\n> > is used by auth_token middleware and i assumed everyone would be\n> > familiar with them. I don\'t think it matters what is used so long as\n> > it\'s consistent.\n> > \n> > Regarding the [clients_<clientname>] that header name would be passed as\n> > a parameter so services can still do what they like there. \n> \n> Honestly, I really like\n> \n> [nova]\n> \n> better than\n> \n> [clients_nova]\n\nThis won\'t be controlled by keystoneclient - i\'ll let the services fight\nthat out amongst themselves, but the rest of this thread suggests just\n[nova] \n\n> And as we\'re going to have to live with this for a while, I\'d rather use\n> the more clear version of this in keystone instead of the Heat stanzas.\n\nAnyone else have an opinion on this? \n\nThere\'s always the possibility that i can maintain a deprecated ca_file\nfor cafile etc in keystoneclient, however this will mean that every\nservice will get this deprecation so i\'ve been trying to avoid that. \n\nThere is a mechanism there to allow the individual services to create\nthe correct deprecations so it\'s just a matter of figuring out what we\nwant the \'correct\' name to be. \n\n \n> 	-Sean\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<5398EBAC.3000006@dague.net>',NULL),('<1402620230.77983.YahooMailNeo@web125905.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-12 17:43:50',-25200,'2014-06-13 00:43:50',NULL,'[Openstack-docs] [Training-Guides] updates','	* Starting this week the team will start using spec before blueprints process here?https://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint\n\n	* The training-guides content has moved to https://github.com/openstack/training-guides\n	* Training-guides has a launchpad project as well?https://launchpad.net/openstack-training-guides\n	* There are now (5) sub-projects to focus on specific work?https://wiki.openstack.org/wiki/Training-guides#stable_sub-project\n	* Starting this week, we will no longer be using trello?https://trello.com/b/XaRTBVGq/openstack-training\n	* We have a few new training contributors joining us from Comcast. You likely will see them asking questions. I can not count Shilla as new as she has been helping out for 6 months now. :)\n	* We will continue to use the openstack-docs ML and the #openstack-docs channel\n	* We are going to start using an IRC bouncer ZNC to keep our core-reviewers in the know\n	* The wiki is all updated and shiny?https://wiki.openstack.org/wiki/Training-guides\n?\n\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140612/9ea91043/attachment.html>\n\n',NULL,NULL),('<1402621437.30544.YahooMailNeo@web125902.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-12 18:03:57',-25200,'2014-06-13 01:03:57',NULL,'[Openstack-docs] [training-guides] need a bug fix','i can triage it?https://bugs.launchpad.net/openstack-training-guides/+bug/1329567\nbut not enough time tonight to fix. Takers?\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140612/3f2d2d3d/attachment-0001.html>\n\n',NULL,NULL),('<1402625439.31306.28.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 22:10:39',-14400,'2014-06-13 02:10:39',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n in the gate','On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:\n> We\'re definitely deep into capacity issues, so it\'s going to be time to\n> start making tougher decisions about things we decide aren\'t different\n> enough to bother testing on every commit.\n\nIn order to save resources why not combine some of the jobs in different\nways. So for example instead of:\n\n check-tempest-dsvm-full\n check-tempest-dsvm-postgres-full\n\nCouldn\'t we just drop the postgres-full job and run one of the Neutron\njobs w/ postgres instead? Or something similar, so long as at least one\nof the jobs which runs most of Tempest is using PostgreSQL I think we\'d\nbe mostly fine. Not shooting for 100% coverage for everything with our\nlimited resource pool is fine, lets just do the best we can.\n\nDitto for gate jobs (not check).\n\n\n> \n> Previously we\'ve been testing Postgresql in the gate because it has a\n> stricter interpretation of SQL than MySQL. And when we didn\'t test\n> Postgresql it regressed. I know, I chased it for about 4 weeks in grizzly.\n> \n> However Monty brought up a good point at Summit, that MySQL has a strict\n> mode. That should actually enforce the same strictness.\n> \n> My proposal is that we land this change to devstack -\n> https://review.openstack.org/#/c/97442/ and backport it to past devstack\n> branches.\n> \n> Then we drop the pg jobs, as the differences between the 2 configs\n> should then be very minimal. All the *actual* failures we\'ve seen\n> between the 2 were completely about this strict SQL mode interpretation.\n\n\nI suppose I would like to see us keep it in the mix. Running SmokeStack\nfor almost 3 years I found many an issue dealing w/ PostgreSQL. I ran it\nconcurrently with many of the other jobs and I too had limited resources\n(much less that what we have in infra today).\n\nWould MySQL strict SQL mode catch stuff like this (old bugs, but still\nvalid for this topic I think):\n\n https://bugs.launchpad.net/nova/+bug/948066\n\n https://bugs.launchpad.net/nova/+bug/1003756\n\n\nHaving support for and testing against at least 2 databases helps keep\nour SQL queries and migrations cleaner... and is generally a good\npractice given we have abstractions which are meant to support this sort\nof thing anyway (so by all means let us test them!).\n\nAlso, Having compacted the Nova migrations 3 times now I found many\nissues by testing on multiple databases (MySQL and PostgreSQL). I\'m\nquite certain our migrations would be worse off if we just tested\nagainst the single database.\n\nThat said I\'m all for the focus being on realistic use cases.  If nobody\nis using PostgreSQL in production (or has interest in doing so) then\nperhaps considering it as a drop candidate is a good idea. If we go this\nroute though I gotta say it puts some of our abstractions on the\n\"chopping block\" in my opinion. SQLAlchemy, python-migrate, and the like\naren\'t free in terms of CPU cycles and if all we really need is the one\ndatabase then perhaps we really should consider going with some straight\nup inline SQL code instead.\n\nDan\n\n\n> \n> 	-Sean\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<539997CE.5050101@dague.net>',NULL),('<1402625894.32306.1.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 22:18:14',-14400,'2014-06-13 02:18:14',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n in the gate','On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote:\n> \n> On Jun 12, 2014 8:37 AM, \"Sean Dague\" <sean at dague.net> wrote:\n> >\n> > On 06/12/2014 10:38 AM, Mike Bayer wrote:\n> > >\n> > > On 6/12/14, 8:26 AM, Julien Danjou wrote:\n> > >> On Thu, Jun 12 2014, Sean Dague wrote:\n> > >>\n> > >>> That\'s not cacthable in unit or functional tests?\n> > >> Not in an accurate manner, no.\n> > >>\n> > >>> Keeping jobs alive based on the theory that they might one day\n> be useful\n> > >>> is something we just don\'t have the liberty to do any more.\n> We\'ve not\n> > >>> seen an idle node in zuul in 2 days... and we\'re only at j-1.\n> j-3 will\n> > >>> be at least +50% of this load.\n> > >> Sure, I\'m not saying we don\'t have a problem. I\'m just saying\n> it\'s not a\n> > >> good solution to fix that problem IMHO.\n> > >\n> > > Just my 2c without having a full understanding of all of\n> OpenStack\'s CI\n> > > environment, Postgresql is definitely different enough that MySQL\n> > > \"strict mode\" could still allow issues to slip through quite\n> easily, and\n> > > also as far as capacity issues, this might be longer term but I\'m\n> hoping\n> > > to get database-related tests to be lots faster if we can move to\n> a\n> > > model that spends much less time creating databases and schemas.\n> >\n> > This is what I mean by functional testing. If we were directly\n> hitting a\n> > real database on a set of in tree project tests, I think you could\n> > discover issues like this. Neutron was headed down that path.\n> >\n> > But if we\'re talking about a devstack / tempest run, it\'s not really\n> > applicable.\n> >\n> > If someone can point me to a case where we\'ve actually found this\n> kind\n> > of bug with tempest / devstack, that would be great. I\'ve just\n> *never*\n> > seen it. I was the one that did most of the fixing for pg support in\n> > Nova, and have helped other projects as well, so I\'m relatively\n> familiar\n> > with the kinds of fails we can discover. The ones that Julien\n> pointed\n> > really aren\'t likely to be exposed in our current system.\n> >\n> > Which is why I think we\'re mostly just burning cycles on the\n> existing\n> > approach for no gain.\n> \n> Given all the points made above, I think dropping PostgreSQL is the\n> right choice; if only we had infinite cloud that would be another\n> story.\n> \n> What about converting one of our existing jobs (grenade partial ncpu,\n> large ops, regular grenade, tempest with nova network etc.) Into a\n> PostgreSQL only job? We could get some level of PostgreSQL testing\n> without any additional jobs, although this is  tradeoff obviously.\n\nI\'d be fine with this tradeoff if it allows us to keep PostgreSQL in the\nmix.\n\n\n> \n> >\n> >         -Sean\n> >\n> > --\n> > Sean Dague\n> > http://dague.net\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAHXdxOdR7zKxf2pAhJHEX4NxKBVBRD83DiMPNj+tbMfFGs-P3Q@mail.gmail.com>',NULL),('<1402626282.28076.50.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 12:24:42',36000,'2014-06-13 02:24:42',NULL,'[openstack-dev] Message level security plans. [barbican]','On Thu, 2014-06-12 at 23:22 +0000, Tiwari, Arvind wrote:\n> Thanks Nathan for your response.  \n> \n> Still not very convinced for two separate service.\n> \n> Keystone authentication is not a mandatory requirement for Barbican, as per design it can work without Keystone authentication. Rest (temporary session key generation, long-term keys ...) are feature gap which can be easily developed in barbican. \n> \n> If Barbican has to store long term keys on behalf of Kite users than IMO it is good to merge these two services. We can develop separate plug-in to achieve KDC (or Kite plug-in). One can have two separate barbican deployments one of KDC another for KMS (or may be only one with enhanced barbican API). \n> \n> Thoughts?\n\nI think you\'re looking at the wrong part of the stack here. Barbican is\na user facing component, kite is looking at securing messages between\nservices that are sent over a message bus. They will need to be deployed\nand configured in a completely different manner. The users in this case\nare host machines.\n\nI don\'t think that session key generation is a \'gap\' in barbican\'s\nfeatures, I think it\'s very correctly outside of scope. Key generation\nsuch as this is done in a very specific format for a very specific use\ncase, and includes a lot of metadata that has no application outside of\nkite.\n\nKite or a KDC plugin, would still need to manage a whole lot of state\naround services and which services can talk to which other services.\nThis is very much outside barbican\'s scope. \n\nThe only thing that is really common between the two projects is safely\nstoring encrypted keys, and even then a fundamental purpose of barbican\nis being able to retrieve the keys, which kite should never do. So we\nwould then need to start putting things into barbican to mark these keys\nas special...\n\nThis was discussed at the summit (you were in that room) that when\nappropriate we should look at having an option for kite to use barbican\nfor it\'s long term key storage and look to extract the secure key\nstorage component from barbican (or kite) into a library that can be\nshared between the two components if feasible.\n\nIn summary, yes they both store keys but the plugin you suggest will end\nup with the same API surface area as barbican itself, involve a lot of\nservice management that is way outside of barbican\'s scope, will need to\nscale for a different reason, will need to be discovered by a different\nclass of user and have different requirements on \'privacy\' on keys.\n\nWhy would we want to deal with all that if you would still need another\nbarbican deployment?\n\n\nJamie\n\n> Arvind\n> \n> \n> -----Original Message-----\n> From: Nathan Kinder [mailto:nkinder at redhat.com] \n> Sent: Thursday, June 12, 2014 4:41 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] Message level security plans. [barbican]\n> \n> \n> \n> On 06/12/2014 03:16 PM, Tiwari, Arvind wrote:\n> > Some thoughts out of the context of this email thread.\n> > \n> > As per my understanding of Kite, it is a subset of Barbican or there might be minor gaps. If that is the true statement then what is the point of having a services with duplicate feature set? Why not port all the Kite feature to Barbican and use Barbican for message level security needs?\n> \n> That\'s not a true statement.  This was also something that was discussed at the Atlanta Summit in the Kite session with the Barbican development team, and agreement was reached that they are different use-cases and feature sets that should remain separate.\n> \n> To (over) simplify, Barbican allows OpenStack users (or services) identified by Keystone tokens to archive and later retrieve keys.  In contrast, Kite is generating and issuing temporary session keys to communicating parties that are using the message queue in the underlying OpenStack infrastructure.  These parties are not identified by Keystone.\n>  These session keys are also not archived by a service.  Kite generates them, issues them in the form of a ticket, and forgets them immediately.\n>  You never want to be able to retrieve a key after a ticket is issued.\n> In addition, the key generation is not purely random as I\'ve outlined in my blog post (see the details around how HKDF is used if you\'re interested).\n> \n> There are areas for integration between Kite and Barbican.  The most obvious would be to utilize Baribican to store the long-term keys used to authenticate the communicating party.\n> \n> Thanks,\n> -NGK\n> \n> > \n> > Thoughts?\n> > \n> > Arvind\n> > \n> > -----Original Message-----\n> > From: Nathan Kinder [mailto:nkinder at redhat.com]\n> > Sent: Thursday, June 12, 2014 3:32 PM\n> > To: openstack-dev at lists.openstack.org\n> > Cc: Jamie Lennox\n> > Subject: Re: [openstack-dev] Message level security plans.\n> > \n> > Hi Tim,\n> > \n> > Jamie Lennox (cc\'d) has been the main developer working on Kite.  I\'m \n> > sure he would appreciate you getting involved in reviews [1] and any \n> > other development help you\'re willing to contribute.  Patches have \n> > slowly been landing in the kite repo. [2]\n> > \n> > For others not familiar with Kite, there is the blueprint mentioned elsewhere in this thread as well as this write-up of mine:\n> > \n> >   https://blog-nkinder.rhcloud.com/?p=62\n> > \n> > Thanks,\n> > -NGK\n> > \n> > [1] \n> > https://review.openstack.org/#/q/status:open+project:stackforge/kite,n\n> > ,z [2] https://github.com/stackforge/kite\n> > \n> > \n> > On 06/12/2014 08:08 AM, Kelsey, Timothy Joh wrote:\n> >> Hello OpenStack folks,\n> >>\n> >> First please allow me to introduce myself, my name is Tim Kelsey and I\'m a security developer working at HP. I am very interested in projects like Kite and the work that\'s being undertaken to introduce message level security into OpenStack and would love to help out on that front. In an effort to ascertain the current state of development it would be great to hear from the people who are involved in this and find out what\'s being worked on or planned in blueprints.\n> >>\n> >> Many Thanks,\n> >>\n> >> --\n> >> Tim Kelsey\n> >> Cloud Security Engineer\n> >> HP Helion\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<0EF5F110A32BED44A0C6438BB5C35B390A99552C@G4W3210.americas.hpqcorp.net>',NULL),('<1402626505.28076.52.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 12:28:25',36000,'2014-06-13 02:28:25',NULL,'[openstack-dev] [Openstack-security] [Barbican][OSSG][Keystone]\n Mid-Cycle Meetup','On Thu, 2014-06-12 at 16:29 -0700, Valerie Anne Fenwick wrote:\n> Hi FOlks\n> \n> I haven\'t seen anymore on this. Is this happening?  If so, are there more\n> details? (location, agenda, etc).  Thanks!\n\nDetails: http://dolphm.com/openstack-keystone-hackathon-for-juno/ \n\nI think the agenda will be pushing forward and follow up from things\ndecided at the summit and generally getting things done (so nothing\nformal). \n\n> Valerie\n> \n> On 05/23/14 06:26 AM, Adam Young wrote:\n> > The Keystone team  is going to be making sure the  code that needs to be in by J2 is\n> > in.  That means the API changes.\n> >\n> > I\'ll be there.\n> >\n> >\n> > On 05/23/2014 03:09 AM, Clark, Robert Graham wrote:\n> >> I?d like to attend all the Barbican stuff and I?m sure there?ll be some interesting\n> >> Keystone things too.\n> >>\n> >> I think it?s likely we?d do more parallel ?OSSG? stuff on the Keystone days though\n> >>\n> >> I?m free on these dates.\n> >>\n> >> From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>\n> >> Date: Friday, 23 May 2014 02:14\n> >> To: Jarret Raim <jarret.raim at RACKSPACE.COM<mailto:jarret.raim at RACKSPACE.COM>>\n> >> Cc:\n> >> \"openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>\" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>,\n> >> OpenStack List\n> >> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\n> >> Subject: Re: [Openstack-security] [Barbican][OSSG][Keystone] Mid-Cycle Meetup\n> >>\n> >> I plan on attending.\n> >> -bryan\n> >>\n> >>\n> >> On Thu, May 22, 2014 at 10:48 AM, Jarret Raim\n> >> <jarret.raim at rackspace.com<mailto:jarret.raim at rackspace.com>> wrote:\n> >> All,\n> >>\n> >> There was some interest at the Summit in semi-combining the mid-cycle meet\n> >> ups for Barbican, Keystone and the OSSG as there is some overlap in team\n> >> members and interest areas. The current dates being considered are:\n> >>\n> >> Mon, July 7 - Barbican\n> >> Tue, July 8 - Barbican\n> >> Wed, July 9 - Barbican / Keystone\n> >> Thu, July 10 - Keystone\n> >> Fri, July 11 - Keystone\n> >>\n> >> Assuming these dates work for for everyone, we\'ll fit some OSSG work in\n> >> during whatever days make the most sense. The current plan is to have the\n> >> meet up in San Antonio at the new Geekdom location, which is downtown.\n> >> This should make travel a bit easier for everyone as people won\'t need\n> >> cars are there are plenty of hotels and restaurants within walking / short\n> >> cab distance.\n> >>\n> >> I wanted to try to get a quick head count from the Barbican and OSSG folks\n> >> (I think Dolph already has one for Keystone). I\'d also like to know if you\n> >> are a Barbican person interested in going to the Keystone sessions or vice\n> >> versa.\n> >>\n> >> Once we get a rough head count estimate, Dolph and I can work on getting\n> >> everything booked.\n> >>\n> >>\n> >>\n> >>\n> >>\n> >> Thanks,\n> >>\n> >> --\n> >> Jarret Raim\n> >> @jarretraim\n> >>\n> >>\n> >>\n> >> _______________________________________________\n> >> Openstack-security mailing list\n> >> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security\n> >>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<539A37F5.6030006@oracle.com>',NULL),('<1402627668404.b5fe40b5@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-12 19:47:49',-25200,'2014-06-13 02:47:49',NULL,'[openstack-dev] masking X-Auth-Token in debug output - proposed\n consistency','Sorry to interrupt this discussion.\n\n\n\n\nSean,?\n\n\n\n\nSince I\'m working the neutron client code change, by looking at your code change to nova client, looks like only X-Auth-Token is taken care of in http_log_req. There is also password in header and token id in response. Any particular reason that they are not being taken care of?\n\n\n\n\nThanks,?\n\nXu Han\n?\nSent from Mailbox for iPhone\n\nOn Fri, Jun 13, 2014 at 8:47 AM, Gordon Chung <chungg at ca.ibm.com> wrote:\n\n>> I\'m hoping we can just ACK this approach, and get folks to start moving\n>> patches through the clients to clean this all up.\n> just an fyi, in pyCADF, we obfuscate tokens similar to how credit cards \n> are handled: by capturing a percentage of leading and trailing characters \n> and substituting the middle ie. \"4724 xxxxxxxx 8478\". whatever we decide \n> here, i\'m all for having a consistent way of masking and minimising tokens \n> in OpenStack.\n> cheers,\n> gordon chung\n> openstack, ibm software standards\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140612/7383f51c/attachment.html>\n\n','<OF861CF0E4.C2A98BF0-ON85257CF5.00690318-85257CF6.00044645@ca.ibm.com>',NULL),('<1402640198.13813.112.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 07:16:38',3600,'2014-06-13 06:16:38',NULL,'[openstack-dev] mysql/mysql-python license \"contamination\" into\n openstack?','On Thu, 2014-06-12 at 12:13 -0600, Chris Friesen wrote:\n> Hi,\n> \n> I\'m looking for the community viewpoint on whether there is any chance \n> of license contamination between mysql and nova.  I realize that lawyers \n> would need to be involved for a proper ruling, but I\'m curious about the \n> view of the developers on the list.\n> \n> Suppose someone creates a modified openstack and wishes to sell it to \n> others.  They want to keep their changes private.  They also want to use \n> the mysql database.\n> \n> The concern is this:\n> \n> nova is apache licensed\n> sqlalchemy is MIT licensed\n> mysql-python (aka mysqldb1) is GPLv2 licensed\n> mysql is GPLv2 licensed\n> \n> \n> \n> The concern is that since nova/sqlalchemy/mysql-python are all \n> essentially linked together, an argument could be made that the work as \n> a whole is a derivative work of mysql-python, and thus all the source \n> code must be made available to anyone using the binary.\n> \n> Does this argument have any merit?\n> \n> Has anyone tested any of the mysql DBAPIs with more permissive licenses?\n\nThanks for bringing this up. I\'ve forwarded the question to the\nlegal-discuss mailing list:\n\nhttp://lists.openstack.org/pipermail/legal-discuss/2014-June/000291.html\n\nThe general question of using GPL libraries is covered by:\n\nhttps://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_library_dependencies\n\nBut I\'m not sure whether the specific question of mysql-python\'s license\nhas come up before.\n\nMark.\n\n\n\n','<5399EDB1.6040503@windriver.com>',NULL),('<1402641380.13813.116.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 07:36:20',3600,'2014-06-13 06:36:20',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n in the gate','On Thu, 2014-06-12 at 22:10 -0400, Dan Prince wrote:\n> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:\n> > We\'re definitely deep into capacity issues, so it\'s going to be time to\n> > start making tougher decisions about things we decide aren\'t different\n> > enough to bother testing on every commit.\n> \n> In order to save resources why not combine some of the jobs in different\n> ways. So for example instead of:\n> \n>  check-tempest-dsvm-full\n>  check-tempest-dsvm-postgres-full\n> \n> Couldn\'t we just drop the postgres-full job and run one of the Neutron\n> jobs w/ postgres instead? Or something similar, so long as at least one\n> of the jobs which runs most of Tempest is using PostgreSQL I think we\'d\n> be mostly fine. Not shooting for 100% coverage for everything with our\n> limited resource pool is fine, lets just do the best we can.\n> \n> Ditto for gate jobs (not check).\n\nI think that\'s what Clark was suggesting in:\n\nhttps://etherpad.openstack.org/p/juno-test-maxtrices\n\n> > Previously we\'ve been testing Postgresql in the gate because it has a\n> > stricter interpretation of SQL than MySQL. And when we didn\'t test\n> > Postgresql it regressed. I know, I chased it for about 4 weeks in grizzly.\n> > \n> > However Monty brought up a good point at Summit, that MySQL has a strict\n> > mode. That should actually enforce the same strictness.\n> > \n> > My proposal is that we land this change to devstack -\n> > https://review.openstack.org/#/c/97442/ and backport it to past devstack\n> > branches.\n> > \n> > Then we drop the pg jobs, as the differences between the 2 configs\n> > should then be very minimal. All the *actual* failures we\'ve seen\n> > between the 2 were completely about this strict SQL mode interpretation.\n> \n> \n> I suppose I would like to see us keep it in the mix. Running SmokeStack\n> for almost 3 years I found many an issue dealing w/ PostgreSQL. I ran it\n> concurrently with many of the other jobs and I too had limited resources\n> (much less that what we have in infra today).\n> \n> Would MySQL strict SQL mode catch stuff like this (old bugs, but still\n> valid for this topic I think):\n> \n>  https://bugs.launchpad.net/nova/+bug/948066\n> \n>  https://bugs.launchpad.net/nova/+bug/1003756\n> \n> \n> Having support for and testing against at least 2 databases helps keep\n> our SQL queries and migrations cleaner... and is generally a good\n> practice given we have abstractions which are meant to support this sort\n> of thing anyway (so by all means let us test them!).\n> \n> Also, Having compacted the Nova migrations 3 times now I found many\n> issues by testing on multiple databases (MySQL and PostgreSQL). I\'m\n> quite certain our migrations would be worse off if we just tested\n> against the single database.\n\nCertainly sounds like this testing is far beyond the \"might one day be\nuseful\" level Sean talks about.\n\nMark.\n\n\n\n','<1402625439.31306.28.camel@dovetail.localdomain>',NULL),('<1402661605.17291.4.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 13:13:25',3600,'2014-06-13 12:13:25',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n in the gate','On Fri, 2014-06-13 at 07:31 -0400, Sean Dague wrote:\n> On 06/13/2014 02:36 AM, Mark McLoughlin wrote:\n> > On Thu, 2014-06-12 at 22:10 -0400, Dan Prince wrote:\n> >> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:\n> >>> We\'re definitely deep into capacity issues, so it\'s going to be time to\n> >>> start making tougher decisions about things we decide aren\'t different\n> >>> enough to bother testing on every commit.\n> >>\n> >> In order to save resources why not combine some of the jobs in different\n> >> ways. So for example instead of:\n> >>\n> >>  check-tempest-dsvm-full\n> >>  check-tempest-dsvm-postgres-full\n> >>\n> >> Couldn\'t we just drop the postgres-full job and run one of the Neutron\n> >> jobs w/ postgres instead? Or something similar, so long as at least one\n> >> of the jobs which runs most of Tempest is using PostgreSQL I think we\'d\n> >> be mostly fine. Not shooting for 100% coverage for everything with our\n> >> limited resource pool is fine, lets just do the best we can.\n> >>\n> >> Ditto for gate jobs (not check).\n> > \n> > I think that\'s what Clark was suggesting in:\n> > \n> > https://etherpad.openstack.org/p/juno-test-maxtrices\n> > \n> >>> Previously we\'ve been testing Postgresql in the gate because it has a\n> >>> stricter interpretation of SQL than MySQL. And when we didn\'t test\n> >>> Postgresql it regressed. I know, I chased it for about 4 weeks in grizzly.\n> >>>\n> >>> However Monty brought up a good point at Summit, that MySQL has a strict\n> >>> mode. That should actually enforce the same strictness.\n> >>>\n> >>> My proposal is that we land this change to devstack -\n> >>> https://review.openstack.org/#/c/97442/ and backport it to past devstack\n> >>> branches.\n> >>>\n> >>> Then we drop the pg jobs, as the differences between the 2 configs\n> >>> should then be very minimal. All the *actual* failures we\'ve seen\n> >>> between the 2 were completely about this strict SQL mode interpretation.\n> >>\n> >>\n> >> I suppose I would like to see us keep it in the mix. Running SmokeStack\n> >> for almost 3 years I found many an issue dealing w/ PostgreSQL. I ran it\n> >> concurrently with many of the other jobs and I too had limited resources\n> >> (much less that what we have in infra today).\n> >>\n> >> Would MySQL strict SQL mode catch stuff like this (old bugs, but still\n> >> valid for this topic I think):\n> >>\n> >>  https://bugs.launchpad.net/nova/+bug/948066\n> >>\n> >>  https://bugs.launchpad.net/nova/+bug/1003756\n> >>\n> >>\n> >> Having support for and testing against at least 2 databases helps keep\n> >> our SQL queries and migrations cleaner... and is generally a good\n> >> practice given we have abstractions which are meant to support this sort\n> >> of thing anyway (so by all means let us test them!).\n> >>\n> >> Also, Having compacted the Nova migrations 3 times now I found many\n> >> issues by testing on multiple databases (MySQL and PostgreSQL). I\'m\n> >> quite certain our migrations would be worse off if we just tested\n> >> against the single database.\n> > \n> > Certainly sounds like this testing is far beyond the \"might one day be\n> > useful\" level Sean talks about.\n> \n> The migration compaction is a good point. And I\'m happy to see there\n> were some bugs exposed as well.\n> \n> Here is where I remain stuck....\n> \n> We are now at a failure rate in which it\'s 3 days (minimum) to land a\n> fix that decreases our failure rate at all.\n> \n> The way we are currently solving this is by effectively building \"manual\n> zuul\" and taking smart humans in coordination to end run around our\n> system. We\'ve merged 18 fixes so far -\n> https://etherpad.openstack.org/p/gatetriage-june2014 this way. Merging a\n> fix this way is at least an order of magnitude more expensive on people\n> time because of the analysis and coordination we need to go through to\n> make sure these things are the right things to jump the queue.\n> \n> That effort, over 8 days, has gotten us down to *only* a 24hr merge\n> delay. And there are no more smoking guns. What\'s left is a ton of\n> subtle things. I\'ve got ~ 30 patches outstanding right now (a bunch are\n> things to clarify what\'s going on in the build runs especially in the\n> fail scenarios). Every single one of them has been failed by Jenkins at\n> least once. Almost every one was failed by a different unique issue.\n> \n> So I\'d say at best we\'re 25% of the way towards solving this. That being\n> said, because of the deep queues, people are just recheck grinding (or\n> hitting the jackpot and landing something through that then fails a lot\n> after landing). That leads to bugs like this:\n> \n> https://bugs.launchpad.net/heat/+bug/1306029\n> \n> Which was seen early in the patch - https://review.openstack.org/#/c/97569/\n> \n> Then kind of destroyed us completely for a day -\n> http://status.openstack.org/elastic-recheck/ (it\'s the top graph).\n> \n> And, predictably, a week into a long gate queue everyone is now grumpy.\n> The sniping between projects, and within projects in assigning blame\n> starts to spike at about day 4 of these events. Everyone assumes someone\n> else is to blame for these things.\n> \n> So there is real community impact when we get to these states.\n> \n> ....\n> \n> So, I\'m kind of burnt out trying to figure out how to get us out of\n> this. As I do take it personally when we as a project can\'t merge code.\n> As that\'s a terrible state to be in.\n> \n> Pleading to get more people to dive in, is mostly not helping.\n> \n> So my only thinking at this point is we prune back our test jobs to the\n> point that they are a small enough number of configurations that the\n> fixed number of people actually trying to debug this, actually can.\n> \n> If there are other ideas, that\'s great.\n> \n> But \'you aren\'t allowed to do less\' isn\'t really sustainable. That just\n> leads to people giving up on helping.\n\nTotally understand, and agree with the severity of the situation.\n\nRetreating is one thing, but let\'s not label the job as useless in the\nprocess. We can disable the job because of capacity issues even if we\nfeel its coverage is as important as the day we added the job.\n\nHow about explicitly priority ordering the jobs such that when we\nretreat the lowest priority job is dropped first, but is also the first\none to be added back (assuming its pass rate is sufficiently high) when\nwe feel we have capacity again?\n\nDebating the priority order of the jobs, brainstorming ways of mixing\nconfigurations in the jobs to get the best coverage, etc. would then be\nsomething we\'d do with cool heads in calmer times rather than when the\ngate is on fire.\n\nMark.\n\n\n\n','<539AE0F6.1030909@dague.net>',NULL),('<1402681883.3407.7.camel@virtbox>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 17:51:24',0,'2014-06-13 17:51:24',NULL,'[openstack-dev] [metrics] How to group activity in git/gerrit\n repositories','Hi Stef,\n\nOn Thu, 2014-06-12 at 17:07 -0700, Stefano Maffulli wrote:\n> we\'re working on a quarterly report of activities in all our git and\n> gerrit repositories to understand the dynamics of contributions across\n> different dimensions. This report will be similar to what Bitergia\n> produced at release time.\n> \n> I\'d like to discuss more widely the format of how to meaningfully group\n> the information presented. One basic need is to have a top level view\n> and then drill down based on the release status of each project. A\n> suggested classification would be based on the programs.yaml file:\n> \n> - OpenStack Software (top level overview):\n>    - integrated\n>    - incubated\n>    - clients\n>    - other:\n>        devstack\n>        deployment\n>        common libraries\n> - OpenStack Quality Assurance\n> - OpenStack Documentation\n> - OpenStack Infrastructure\n> - OpenStack Release management\n> \n> It seems easy but based on that grouping, integrated and incubated git\n> repositories are easy to spot in programs.yaml (they have\n> integrated-since attribute).\n> \n> Let\'s have the Sahara program as an example:\n> \n>   projects:\n>     - repo: openstack/sahara\n>       incubated-since: icehouse\n>       integrated-since: juno\n>     - repo: openstack/python-saharaclient\n>     - repo: openstack/sahara-dashboard\n>     - repo: openstack/sahara-extra\n>     - repo: openstack/sahara-image-elements\n>     - repo: openstack/sahara-specs\n> \n> So, for the OpenStack Software part:\n> * openstack/sahara is integrated in juno and incubated since icehouse.\n> * Then clients: python-saharaclient is easy to spot. Is it standard and\n> accepted practice that all client projects are called\n> python-$PROGRAM-NAMEclient?\n> * And what about the rest of the sahara-* projects: where would they go?\n> with openstack/sahara? or somewhere else, in others? devstack?\n> common-libraries?\n> \n> Other repositories for which I have no clear classification:\n> \n>     - repo: openstack/swift-bench\n>     - repo: openstack/django_openstack_auth\n>     - repo: openstack/tuskar-ui\n>     - repo: openstack/heat-cfntools\n>     - repo: openstack/heat-specs\n>     - repo: openstack/heat-templates\n>     - repo: openstack-dev/heat-cfnclient\n>     - repo: openstack/trove-integration\n>     - repo: openstack/ironic-python-agent\n>     - repo: stackforge/kite\n> \n> Any suggestions on how you would like to see these classified: with\n> together with the integrated/incubated \'parent\' program (sahara with\n> sahara-dashboard, sahara-extra etc  or separately under \'other\'? Or\n> they\'re all different and we need to look at them one by one?\n> \n> Let me know what you think (tomorrow office hour, 11am PDT, is a good\n> time to chat about this).\n\nYou can also refer to the example of Stackalytics, who have created\ntheir own hierarchy and groupings for metrics reporting:\nhttps://github.com/stackforge/stackalytics/blob/master/etc/default_data.json\n\nI have found this grouping to be pretty logical and useful.\n\nFor my own internal metrics, I also rely on the programs.yaml file\norganization, and / or the \"Programs\" wiki page\nhttps://wiki.openstack.org/wiki/Programs where they differ.\n\nFurther, I group all the \"other\" projects that do not clearly fit into a\nseparate \"bucket\" grouping, until they either disappear or become\nincorporated into other groupings.\n\nDan\n\n','<539A40C1.6010202@openstack.org>',NULL),('<1402687865-sup-5108@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 12:31:37',-25200,'2014-06-13 19:31:37',NULL,'[openstack-dev] Fwd: Fwd: Debian people don\'t like bash8 as a\n	project name (Bug#748383: ITP: bash8 -- bash script style\n	guide checker)','Excerpts from Thomas Goirand\'s message of 2014-06-13 03:04:07 -0700:\n> On 06/13/2014 06:53 AM, Morgan Fainberg wrote:\n> > Hi Thomas,\n> > \n> > I felt a couple sentences here were reasonable to add (more than ?don?t\n> > care? from before). \n> > \n> > I understand your concerns here, and I totally get what you?re driving\n> > at, but in the packaging world wouldn?t this make sense to call it\n> > \"python-bash8\"?\n> \n> Yes, this is what will happen.\n> \n> > Now the binary, I can agree (for reasons outlined)\n> > should probably not be named ?bash8?, but the name of the ?command?\n> > could be separate from the packaging / project name.\n> \n> If upstream chooses /usr/bin/bash8, I\'ll have to follow. I don\'t want to\n> carry patches which I\'d have to maintain.\n> \n> > Beyond a relatively minor change to the resulting ?binary? name [sure\n> > bash-tidy, or whatever we come up with], is there something more that\n> > really is awful (rather than just silly) about the naming?\n> \n> Renaming python-bash8 into something else is not possible, because the\n> Debian standard is to use, as Debian name, what is used for the import.\n> So if we have \"import xyz\", then the package will be python-xyz.\n> \n\nFor python _libraries_ yes.\n\nBut for a utility which happens to import that library, naming the\npackage after what upstream calls it is a de facto standard.\n\n\n','<539ACC97.1080009@debian.org>',NULL),('<1402689906-sup-7021@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 20:06:20',0,'2014-06-13 20:06:20',NULL,'[openstack-dev] And the prize for proposing change #100000 goes\n	to ...','Excerpts from Monty Taylor\'s message of 2014-06-13 19:32:39 +0000:\n> Greg Haynes\n> \n> Let the race for change 1000000 commence.\n> \n\nWoooo!\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<539B51D7.3070701@inaugust.com>',NULL);
INSERT INTO `messages` VALUES ('<1402697045.2224.92.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 15:04:05',-25200,'2014-06-13 22:04:05',NULL,'[openstack-dev] [containers][nova][cinder] Cinder support in\n containers and unprivileged container-in-container','On Fri, 2014-06-13 at 09:09 +0100, Daniel P. Berrange wrote:\n> On Thu, Jun 12, 2014 at 09:57:41PM +0000, Adrian Otto wrote:\n> > Containers Team,\n> > \n> > The nova-docker developers are currently discussing options for\n> > implementation for supporting mounting of Cinder volumes in\n> > containers, and creation of unprivileged containers-in-containters.\n> > Both of these currently require CAP_SYS_ADMIN[1] which is problematic\n> > because if granted within a container, can lead to an escape from the\n> > container back into the host.\n> \n> NB it is fine for a container to have CAP_SYS_ADMIN if user namespaces\n> are enabled and the root user remapped.\n\nNot if you want a truly secure container, but this is more of a\njudgement call as to how secure the container should be.  CAP_SYS_ADMIN\nis a nasty sinkhole of miscellaneous privielges which makes it a pretty\ndangerous capability for an ordinary user.  You have to be really\ncareful because there\'s lots of ways an ordinary user with CAP_SYS_ADMIN\ncan actually become root.  What we did for OpenVZ was break\nCAP_SYS_ADMIN up into more granular capabilities and put guards on the\ndangerous ones, but even just mount can be problematic: you have to\nforbid suid executables etc and you have to beware of fuzzing the\nfilesystem.\n\nJames\n\n> Also, we should remember that mounting filesystems is not the only use\n> case for exposing block devices to containers. Some applications will\n> happily use raw block devices directly without needing to format and\n> mount any filesystem on them (eg databases).\n> \n> Regards,\n> Daniel\n\n\n\n\n\n','<20140613080927.GA18645@redhat.com>',NULL),('<1402697562.2224.100.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 15:12:42',-25200,'2014-06-13 22:12:42',NULL,'[openstack-dev] [containers][nova][cinder] Cinder support in\n containers and unprivileged container-in-container','On Fri, 2014-06-13 at 17:55 -0400, Eric Windisch wrote:\n> >\n> >\n> > Why would you mount it from within the container?  CAP_SYS_ADMIN is a\n> > per process property, so you use nsenter to execute the mount in the\n> > required mount namespace with CAP_SYS_ADMIN from outside of the\n> > container (i.e. the host).  I assume this requires changes to cinder so\n> > it executes a mount rather than presenting a mountable device node, but\n> > it\'s the same type of change we have to do for mounts which have no\n> > node, like bind mounts.\n> >\n> \n> It\'s a matter of API adherence. You\'re right, however, another option for\n> this etherpad is, \"extend the API\". We could add an extension to OpenStack\n> that allows the host to initiate a mount inside an instance.  That isn\'t\n> much different than the existing suggestion of a container-level API for\n> speaking back to the host to initiate a mount, other than this suggestion\n> being at the orchestration layer, rather than at the host-level.\n\nOK, but this argument is effectively saying hypervisors can\'t do this,\nso our API doesn\'t allow it ... it\'s true but a bit useless.  Containers\nhave all sorts of great capabilities that hypervisors don\'t.  The number\none great one from a security point of view is being able to reach into\nthe container from the host and do or configure things that the\ncontainer itself is prevented from doing.\n\nThis allows you to set up a completely secure babysat environment where\nany dangerous action by the container gets referred up to the host to\nperform.\n\n> In part, this discussion and the exercise of writing this etherpad is to\n> explore alternatives to \"this isn\'t a valid use-case\".  At a high-level,\n> the alternatives seem to be to have an API the containers can use speak\n> back to the host to initiate mounts or finding some configuration of the\n> kernel (possibly with new features) that would provide a long-term solution.\n> \n> I\'m not fond of an API based solution because it means baking in\n> expectations of a specific containers-service API such as the Docker API,\n> or of a specific orchestration API such as the OpenStack Compute API. It\n> might, however, be a good short-term option.\n\nThis is saying we (the container implementations) all do this in\ndifferent ways, which is true, but there\'s no reason we couldn\'t all\nagree on a granular way of doing it we could then translate to an\nOpenStack API ... we just need the action performed; I don\'t think any\nof us has a great attachment to *how* the action is performed.  I think\nthe recently announced libcontainers effort will help us here because it\nactually has a mount API ... we could \n\n> Daniel also brings up an interesting point about user namespaces, although\n> I\'m somewhat worried about that approach given that we can exploit the host\n> with crafty filesystems. It had been considered that we could provide\n> configurations that only allow FUSE. Granted, there might be some\n> possibility of implementing a solution that would limit containers to\n> mounting specific types of filesystems, such as only allowing FUSE mounts.\n\nI replied in the other thread, but I think CAP_SYS_ADMIN is too\ndangerous for a really secure container.\n\nJames\n\n\n\n\n','<CAG6uxc_oLpZcTdbkFfK5wnJ0UTTDeJXh7tCxKjiy+Z2sz+mROw@mail.gmail.com>',NULL),('<1402855754-sup-431@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-15 11:26:05',-25200,'2014-06-15 18:26:05',NULL,'[openstack-dev] [heat] How to avoid property revalidation?','Excerpts from Steven Hardy\'s message of 2014-06-15 02:40:14 -0700:\n> Hi all,\n> \n> So, I stumbled accross an issue while fixing up some tests, which is that\n> AFAICS since Icehouse we continually revalidate every property every time\n> they are accessed:\n> \n> https://github.com/openstack/heat/blob/stable/havana/heat/engine/properties.py#L716\n> \n> This means that, for example, we revalidate every property every time an\n> event is created:\n> \n> https://github.com/openstack/heat/blob/stable/havana/heat/engine/event.py#L44\n> \n> And obviously also every time the property is accessed in the code\n> implementing whatever action we\'re handling, and potentially also before\n> the action (e.g the explicit validate before create/update).\n> \n> This repeated revalidation seems like it could get very expensive - for\n> example there are several resources (Instance/Server resources in\n> particular) which validate against glance via a custom constraint, so we\'re\n> probably doing at least 6 calls to glance validating the image every\n> create.  My suspicion is this is one of the reasons for the performance\n> regression observed in bug #1324102.\n> \n> I\'ve been experimenting with some code which implements local caching of\n> the validated properties, but according to the tests this introduces some\n> problems where the cached value doesn\'t always match what is expected,\n> still investigating why but I guess it\'s updates where we need to\n> re-resolve what is cached during the update.\n> \n> Does anyone (and in particular Zane and Thomas who I know have deep\n> experience in this area) have any ideas on what strategy we might employ to\n> reduce this revalidation overhead?\n\ntl;dr: I think we should only validate structure in validate, and leave\nruntime validation to preview.\n\nI\'ve been wondering about what we want to achieve with validation\nrecently. It seems to me that the goal is to assist template authors\nin finding obvious issues in structure and content before they cause a\nruntime failure. But the error messages are so unhelpful we basically\nget this:\n\nhttp://cdn.memegenerator.net/instances/500x/50964597.jpg\n\nWhat holds us back from improving that is the complexity of doing\nruntime validation.\n\nTo me, runtime is more of a \'preview\' problem than a validate problem. A\ntemplate that validates once should continue to validate on any version\nthat supports the template format. But a preview will actually want to\nmeasure runtime things and use parameters, and thus is where runtime\nconcerns belong.\n\nI wonder if we could move validation out of any runtime context, and\nremove any attempts to validate runtime things like image names/ids and\nsuch. That would allow us to remove any but pre-action validation calls.\n\n\n','<20140615094013.GA5718@t430slt.redhat.com>',NULL),('<1402857034-sup-7967@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-15 11:33:05',-25200,'2014-06-15 18:33:05',NULL,'[openstack-dev] [nova] Distributed locking','Excerpts from Matthew Booth\'s message of 2014-06-13 01:40:30 -0700:\n> On 12/06/14 21:38, Joshua Harlow wrote:\n> > So just a few thoughts before going to far down this path,\n> > \n> > Can we make sure we really really understand the use-case where we think\n> > this is needed. I think it\'s fine that this use-case exists, but I just\n> > want to make it very clear to others why its needed and why distributing\n> > locking is the only *correct* way.\n> \n> An example use of this would be side-loading an image from another\n> node\'s image cache rather than fetching it from glance, which would have\n> very significant performance benefits in the VMware driver, and possibly\n> other places. The copier must take a read lock on the image to prevent\n> the owner from ageing it during the copy. Holding a read lock would also\n> assure the copier that the image it is copying is complete.\n\nReally? Usually in the unix-inspired world we just open a file and it\nstays around until we close it.\n\n\n','<539AB8FE.2090809@redhat.com>',NULL),('<1402866865-sup-4982@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-15 14:14:49',-25200,'2014-06-15 21:14:49',NULL,'[openstack-dev] [Neutron] Starting contributing to project','Excerpts from S?awek Kap?o?ski\'s message of 2014-06-15 13:10:56 -0700:\n> Hello,\n> \n> I want to start contributing to neutron project. I found bug which I\n> want to try fix: https://bugs.launchpad.net/neutron/+bug/1204956 and I\n> have question about \"workflow\" in such case. Should I clone neutron\n> reposiotory from branch master and do changes based on master branch or\n> maybe should I do my changes starting from any other branch? What\n> should I do next when I will for example do patch for such bug?\n> Thanks in advance for any help and explanation about that\n> \n\nThis should explain everything you need to know:\n\nhttps://wiki.openstack.org/wiki/Gerrit_Workflow\n\n\n','<20140615221056.06b079d0@laptop>',NULL),('<1402870998.3179.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-15 22:23:18',0,'2014-06-15 22:23:18',NULL,'[openstack-dev] [Neutron] Implementing new LBaaS API','Thank you Salvatore for your feedback.\n\nComments in-line.\n\nOn Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:\n> Regarding the two approaches outlines in the top post, I found out\n> that the bullet \"This is API versioning done the wrong way\" appears in\n> both approaches.\n> Is this a mistake or intentional?\n\nNo it was intentional.  In my opinion they are both the wrong way.  It\nwould be best to be able to do a version at the resource layer but we\ncan\'t since lbaas is a part of Neutron and its versions is directly tied\nto Neutron\'s.  Another possibility is to have the resource look like:\n\nhttp(s)://neutron.endpoint/v2/lbaas/v2\n\nThis looks very odd to me though and sets a bad precedent.  That is just\nmy opinion though.  So I wouldn\'t call this the right way either.  Thus,\nI do not know of a \"right\" way to do this other than choosing the right\n\"alternative\" way.\n\n> \n> \n> From what I gather, the most reasonable approach appears to be\n> starting with a clean slate, which means having a new API living side\n> by side with the old one.\n> I think the naming collision issues should probably be solved using\n> distinct namespaces for the two API (the old one has /v2/lbaas as a\n> URI prefix I think, I have hardly any idea about what namespace the\n> new one should have)\n> \n\nI\'m in agreement with you as well. The old one has /v2/lb as the prefix.\nI figured the new one could be /v2/lbaas which I think works out well.\n\nAnother thing to consider that I did not think about in my original\nmessage is that a whole new load balancing agent will have to be created\nas well since its code is written with the pool being the root object.\nSo that should be taken into consideration.  So to be perfectly clear,\nstarting with a clean slate would involve the following:\n\n1. New loadbalancer extension\n2. New loadbalancer plugin\n3. New lbaas_agentscheduler extension\n4. New agent_scheduler plugin.\n\nAlso, I don\'t believe doing this would allow the two to be deployed at\nthe same time.  I believe the setup.cfg file would have to be modified\nto point to the new plugins.  I could be wrong about that though.\n\n> \n> Finally, about deprecation - I see it\'s been agreed to deprecate the\n> current API in Juno.\n> I think this is not the right way of doing things. The limits of the\n> current API are pretty much universally agreed; on the other hand, it\n> is generally not advisable to deprecate an old API in favour of the\n> new one at the first iteration such API is published. My preferred\n> strategy would be to introduce the new API as experimental in the Juno\n> release, so that in can be evaluated, apply any feedback and consider\n> for promoting in K - and contextually deprecate the old API.\n> \n> \n> As there is quite a radical change between the old and the new model,\n> keeping the old API indefinitely is a maintenance burden we probably\n> can\'t afford, and I would therefore propose complete removal one\n> release cycle after deprecation. Also - since it seems to me that\n> there is also consensus regarding having load balancing move away into\n> a separate project so that it would not be tied anymore to the\n> networking program, the old API is pretty much just dead weight.\n> \n> Salvatore\n\nGood idea on that.  I\'ll bring this up with everyone at the hackathon\nthis week if it is not already on the table.\n\nThanks again for your feedback.\n\nBrandon\n> \n> \n> On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com> wrote:\n>         I spoke to Mark McClain about this yesterday, I\'ll see if I\n>         can get\n>         him to join the LBaaS team meeting tomorrow so between he and\n>         I we can\n>         close on this with the LBaaS team.\n>         \n>         On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle\n>         <sleipnir012 at gmail.com> wrote:\n>         > Do we know who has an opinion? If so maybe we can reach out\n>         to them directly\n>         > and ask them to comment.\n>         >\n>         >\n>         > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan\n>         <brandon.logan at rackspace.com>\n>         > wrote:\n>         >>\n>         >> Well we got a few opinions, but not enough understanding of\n>         the two\n>         >> options to make an informed decision.  It was requested\n>         that the core\n>         >> reviewers respond to this thread with their opinions.\n>         >>\n>         >> Thanks,\n>         >> Brandon\n>         >>\n>         >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:\n>         >> > Yep, I\'d like to know here, too--  as knowing the answer\n>         to this\n>         >> > unblocks implementation work for us.\n>         >> >\n>         >> >\n>         >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan\n>         >> > <brandon.logan at rackspace.com> wrote:\n>         >> >         Any core neutron people have a chance to give\n>         their opinions\n>         >> >         on this\n>         >> >         yet?\n>         >> >\n>         >> >         Thanks,\n>         >> >         Brandon\n>         >> >\n>         >> >         On Thu, 2014-06-05 at 15:28 +0000, Buraschi,\n>         Andres wrote:\n>         >> >         > Thanks, Kyle. Great.\n>         >> >         >\n>         >> >         > -----Original Message-----\n>         >> >         > From: Kyle Mestery\n>         [mailto:mestery at noironetworks.com]\n>         >> >         > Sent: Thursday, June 05, 2014 11:27 AM\n>         >> >         > To: OpenStack Development Mailing List (not for\n>         usage\n>         >> >         questions)\n>         >> >         > Subject: Re: [openstack-dev] [Neutron]\n>         Implementing new\n>         >> >         LBaaS API\n>         >> >         >\n>         >> >         > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan\n>         >> >         <brandon.logan at rackspace.com> wrote:\n>         >> >         > > Hi Andres,\n>         >> >         > > I\'ve assumed (and we know how assumptions\n>         work) that the\n>         >> >         deprecation\n>         >> >         > > would take place in Juno and after a cyle or\n>         two it would\n>         >> >         totally be\n>         >> >         > > removed from the code.  Even if #1 is the way\n>         to go, the\n>         >> >         old /vips\n>         >> >         > > resource would be deprecated in favor\n>         of /loadbalancers\n>         >> >         and /listeners.\n>         >> >         > >\n>         >> >         > > I agree #2 is cleaner, but I don\'t want to\n>         start on an\n>         >> >         implementation\n>         >> >         > > (though I kind of already have) that will\n>         fail to be\n>         >> >         merged in because\n>         >> >         > > of the strategy.  The strategies are pretty\n>         different so\n>         >> >         one needs to\n>         >> >         > > be decided on.\n>         >> >         > >\n>         >> >         > > As for where LBaaS is intended to end up, I\n>         don\'t want to\n>         >> >         speak for\n>         >> >         > > Kyle, so this is my understanding; It will\n>         end up outside\n>         >> >         of the\n>         >> >         > > Neutron code base but Neutron and LBaaS and\n>         other services\n>         >> >         will all\n>         >> >         > > fall under a Networking (or Network)\n>         program.  That is my\n>         >> >         > > understanding and I could be totally wrong.\n>         >> >         > >\n>         >> >         > That\'s my understanding as well, I think\n>         Brandon worded it\n>         >> >         perfectly.\n>         >> >         >\n>         >> >         > > Thanks,\n>         >> >         > > Brandon\n>         >> >         > >\n>         >> >         > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi,\n>         Andres wrote:\n>         >> >         > >> Hi Brandon, hi Kyle!\n>         >> >         > >> I\'m a bit confused about the deprecation\n>         (btw, thanks for\n>         >> >         sending this Brandon!), as I (wrongly) assumed #1\n>         would be the\n>         >> >         chosen path for the new API implementation. I\n>         understand the\n>         >> >         proposal and #2 sounds actually cleaner.\n>         >> >         > >>\n>         >> >         > >> Just out of curiosity, Kyle, where is LBaaS\n>         functionality\n>         >> >         intended to end up, if long-term plans are to\n>         remove it from\n>         >> >         Neutron?\n>         >> >         > >>\n>         >> >         > >> (Nit question, I must clarify)\n>         >> >         > >>\n>         >> >         > >> Thank you!\n>         >> >         > >> Andres\n>         >> >         > >>\n>         >> >         > >> -----Original Message-----\n>         >> >         > >> From: Brandon Logan\n>         [mailto:brandon.logan at RACKSPACE.COM]\n>         >> >         > >> Sent: Wednesday, June 04, 2014 2:18 PM\n>         >> >         > >> To: openstack-dev at lists.openstack.org\n>         >> >         > >> Subject: Re: [openstack-dev] [Neutron]\n>         Implementing new\n>         >> >         LBaaS API\n>         >> >         > >>\n>         >> >         > >> Thanks for your feedback Kyle.  I will be at\n>         that meeting\n>         >> >         on Monday.\n>         >> >         > >>\n>         >> >         > >> Thanks,\n>         >> >         > >> Brandon\n>         >> >         > >>\n>         >> >         > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle\n>         Mestery wrote:\n>         >> >         > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon\n>         Logan\n>         >> >         > >> > <brandon.logan at rackspace.com> wrote:\n>         >> >         > >> > > This is an LBaaS topic bud I\'d like to\n>         get some\n>         >> >         Neutron Core\n>         >> >         > >> > > members to give their opinions on this\n>         matter so I\'ve\n>         >> >         just\n>         >> >         > >> > > directed this to Neutron proper.\n>         >> >         > >> > >\n>         >> >         > >> > > The design for the new API and object\n>         model for LBaaS\n>         >> >         needs to be\n>         >> >         > >> > > locked down before the hackathon in a\n>         couple of weeks\n>         >> >         and there\n>         >> >         > >> > > are some questions that need answered.\n>          This is\n>         >> >         pretty urgent to\n>         >> >         > >> > > come on to a decision on and to get a\n>         clear strategy\n>         >> >         defined so\n>         >> >         > >> > > we can actually do real code during the\n>         hackathon\n>         >> >         instead of\n>         >> >         > >> > > wasting some of that valuable time\n>         discussing this.\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > > Implementation must be backwards\n>         compatible\n>         >> >         > >> > >\n>         >> >         > >> > > There are 2 ways that have come up on\n>         how to do this:\n>         >> >         > >> > >\n>         >> >         > >> > > 1) New API and object model are created\n>         in the same\n>         >> >         extension and\n>         >> >         > >> > > plugin as the old.  Any API requests\n>         structured for\n>         >> >         the old API\n>         >> >         > >> > > will be translated/adapted to the into\n>         the new object\n>         >> >         model.\n>         >> >         > >> > > PROS:\n>         >> >         > >> > > -Only one extension and plugin\n>         >> >         > >> > > -Mostly true backwards compatibility -Do\n>         not have to\n>         >> >         rename\n>         >> >         > >> > > unchanged resources and models\n>         >> >         > >> > > CONS:\n>         >> >         > >> > > -May end up being confusing to an\n>         end-user.\n>         >> >         > >> > > -Separation of old api and new api is\n>         less clear\n>         >> >         -Deprecating and\n>         >> >         > >> > > removing old api and object model will\n>         take a bit\n>         >> >         more work -This\n>         >> >         > >> > > is basically API versioning the wrong\n>         way\n>         >> >         > >> > >\n>         >> >         > >> > > 2) A new extension and plugin are\n>         created for the new\n>         >> >         API and\n>         >> >         > >> > > object model.  Each API would live side\n>         by side.  New\n>         >> >         API would\n>         >> >         > >> > > need to have different names for\n>         resources and object\n>         >> >         models from\n>         >> >         > >> > > Old API resources and object models.\n>         >> >         > >> > > PROS:\n>         >> >         > >> > > -Clean demarcation point between old and\n>         new -No\n>         >> >         translation\n>         >> >         > >> > > layer needed -Do not need to modify\n>         existing API and\n>         >> >         object\n>         >> >         > >> > > model, no new bugs -Drivers do not need\n>         to be\n>         >> >         immediately\n>         >> >         > >> > > modified -Easy to deprecate and remove\n>         old API and\n>         >> >         object model\n>         >> >         > >> > > later\n>         >> >         > >> > > CONS:\n>         >> >         > >> > > -Separate extensions and object model\n>         will be\n>         >> >         confusing to\n>         >> >         > >> > > end-users -Code reuse by copy paste\n>         since old\n>         >> >         extension and\n>         >> >         > >> > > plugin will be deprecated and removed.\n>         >> >         > >> > > -This is basically API versioning the\n>         wrong way\n>         >> >         > >> > >\n>         >> >         > >> > > Now if #2 is chosen to be feasible and\n>         acceptable\n>         >> >         then there are\n>         >> >         > >> > > a number of ways to actually do that.  I\n>         won\'t bring\n>         >> >         those up\n>         >> >         > >> > > until a clear decision is made on which\n>         strategy\n>         >> >         above is the most acceptable.\n>         >> >         > >> > >\n>         >> >         > >> > Thanks for sending this out Brandon. I\'m\n>         in favor of\n>         >> >         option #2\n>         >> >         > >> > above, especially considering the\n>         long-term plans to\n>         >> >         remove LBaaS\n>         >> >         > >> > from Neutron. That approach will help the\n>         eventual end\n>         >> >         goal there.\n>         >> >         > >> > I am also curious on what others think,\n>         and to this\n>         >> >         end, I\'ve added\n>         >> >         > >> > this as an agenda item for the team\n>         meeting next\n>         >> >         Monday. Brandon,\n>         >> >         > >> > it would be great to get you there for the\n>         part of the\n>         >> >         meeting\n>         >> >         > >> > where we\'ll discuss this.\n>         >> >         > >> >\n>         >> >         > >> > Thanks!\n>         >> >         > >> > Kyle\n>         >> >         > >> >\n>         >> >         > >> > > Thanks,\n>         >> >         > >> > > Brandon\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         >> >         > >> > >\n>         _______________________________________________\n>         >> >         > >> > > OpenStack-dev mailing list\n>         >> >         > >> > > OpenStack-dev at lists.openstack.org\n>         >> >         > >> > >\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         > >> >\n>         >> >         > >> >\n>         _______________________________________________\n>         >> >         > >> > OpenStack-dev mailing list\n>         >> >         > >> > OpenStack-dev at lists.openstack.org\n>         >> >         > >> >\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         > >>\n>         >> >         > >>\n>         _______________________________________________\n>         >> >         > >> OpenStack-dev mailing list\n>         >> >         > >> OpenStack-dev at lists.openstack.org\n>         >> >         > >>\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         > >>\n>         >> >         > >>\n>         _______________________________________________\n>         >> >         > >> OpenStack-dev mailing list\n>         >> >         > >> OpenStack-dev at lists.openstack.org\n>         >> >         > >>\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         > >\n>         >> >         > >\n>         _______________________________________________\n>         >> >         > > OpenStack-dev mailing list\n>         >> >         > > OpenStack-dev at lists.openstack.org\n>         >> >         > >\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         >\n>         >> >         > _______________________________________________\n>         >> >         > OpenStack-dev mailing list\n>         >> >         > OpenStack-dev at lists.openstack.org\n>         >> >         >\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >         >\n>         >> >         > _______________________________________________\n>         >> >         > OpenStack-dev mailing list\n>         >> >         > OpenStack-dev at lists.openstack.org\n>         >> >         >\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >\n>         >> >         _______________________________________________\n>         >> >         OpenStack-dev mailing list\n>         >> >         OpenStack-dev at lists.openstack.org\n>         >> >\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >> >\n>         >> >\n>         >> >\n>         >> >\n>         >> >\n>         >> > --\n>         >> > Stephen Balukoff\n>         >> > Blue Box Group, LLC\n>         >> > (800)613-4305 x807\n>         >> > _______________________________________________\n>         >> > OpenStack-dev mailing list\n>         >> > OpenStack-dev at lists.openstack.org\n>         >> >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >>\n>         >> _______________________________________________\n>         >> OpenStack-dev mailing list\n>         >> OpenStack-dev at lists.openstack.org\n>         >>\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAGR=i3iBVg6rVyDhJTzhHDwDRYFKmWdc1WJoYPrD0=k8GBF_WA@mail.gmail.com>',NULL),('<1402885939.17042.0.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-15 22:32:19',-14400,'2014-06-16 02:32:19',NULL,'[openstack-dev] [Nova] Nominating Ken\'ichi Ohmichi for nova-core','On Sat, 2014-06-14 at 08:40 +1000, Michael Still wrote:\n> Greetings,\n> \n> I would like to nominate Ken\'ichi Ohmichi for the nova-core team.\n> \n> Ken\'ichi has been involved with nova for a long time now.  His reviews\n> on API changes are excellent, and he\'s been part of the team that has\n> driven the new API work we\'ve seen in recent cycles forward. Ken\'ichi\n> has also been reviewing other parts of the code base, and I think his\n> reviews are detailed and helpful.\n> \n> Please respond with +1s or any concerns.\n\n+1\n\n> \n> References:\n> \n>   https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:open,n,z\n> \n>   https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z\n> \n>   http://www.stackalytics.com/?module=nova-group&user_id=oomichi\n> \n> As a reminder, we use the voting process outlined at\n> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our\n> core team.\n> \n> Thanks,\n> Michael\n> \n\n\n\n\n','<CAEd1pt5YqF6ULc5tG4__bqjct8g3fiqevdxgHtjW1EqNksRqOg@mail.gmail.com>',NULL),('<1402926096.23788.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 14:41:36',3600,'2014-06-16 13:41:36',NULL,'[openstack-dev] An alternative approach to enforcing \"expected\n election behaviour\"','On Mon, 2014-06-16 at 10:56 +0100, Daniel P. Berrange wrote:\n> On Mon, Jun 16, 2014 at 05:04:51AM -0400, Eoghan Glynn wrote:\n> > How about we rely instead on the values and attributes that\n> > actually make our community strong?\n> > \n> > Specifically: maturity, honesty, and a self-correcting nature.\n> > \n> > How about we simply require that each candidate for a TC or PTL\n> > election gives a simple undertaking in their self-nomination mail,\n> > along the lines of:\n> > \n> > \"I undertake to respect the election process, as required by\n> > the community code of conduct.\n> > \n> > I also undertake not to engage in campaign practices that the\n> > community has considered objectionable in the past, including\n> > but not limited to, unsolicited mail shots and private campaign\n> > events.\n> > \n> > If my behavior during this election period does not live up to\n> > those standards, please feel free to call me out on it on this\n> > mailing list and/or withhold your vote.\"\n> \n> I like this proposal because it focuses on the carrot rather than\n> the stick, which is ultimately better for community cohesiveness\n> IMHO.\n\nI like it too. A slight tweak of that would be to require candidates to\nsign the pledge publicly via an online form. We could invite the\ncommunity as a whole to sign it too in order to have candidates\'\nsupporters covered.\n\n>  It is already part of our community ethos that we can call\n> people out to publically debate / stand up & justify any & all\n> issues affecting the project whether they be related to the code,\n> architecture, or non-technical issues such as electioneering\n> behaviour.\n> \n> > We then rely on:\n> > \n> >   (a) the self-policing nature of an honest, open community\n> > \n> > and:\n> > \n> >   (b) the maturity and sound judgement within that community\n> >       giving us the ability to quickly spot and disregard any\n> >       frivolous reports of mis-behavior\n> > \n> > So no need for heavy-weight inquisitions, no need to interrupt the\n> > election process, no need for handing out of stiff penalties such\n> > as termination of membership.\n> \n> Before jumping headlong for a big stick to whack people with, I think\n> I\'d expect to see examples of problems we\'ve actually faced (as opposed\n> to vague hypotheticals), and a clear illustration that a self-policing\n> approach to the community interaction failed to address them. I\'ve not\n> personally seen/experianced any problems that are so severe that they\'d\n> suggest we need the ability to kick someone out of the community for\n> sending email !\n\nIndeed. This discussion is happening in a vacuum for many people who do\nnot know the details of the private emails and private campaign events\nwhich happened in the previous cycle.\n\nThe only one I know of first hand was a private email where the\nrecipients quickly responded saying the email was out of line and the\noriginal sender apologized profusely. People can make mistakes in good\nfaith and if we can deal with it quickly and maturely as a community,\nall the better.\n\nIn this example, the sender\'s apology could have bee followed up with\n\"look, here\'s our code of conduct; sign it now, respect it in the\nfuture, and let that be the end of the matter\".\n\nMark.\n\n\n\n','<20140616095622.GB5803@redhat.com>',NULL),('<1402936718-sup-6432@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 09:51:51',-25200,'2014-06-16 16:51:51',NULL,'[openstack-dev] [TripleO] Backwards compatibility policy for\n	our projects','Excerpts from Tomas Sedovic\'s message of 2014-06-16 09:19:40 -0700:\n> All,\n> \n> After having proposed some changes[1][2] to tripleo-heat-templates[3],\n> reviewers suggested adding a deprecation period for the merge.py script.\n> \n> While TripleO is an official OpenStack program, none of the projects\n> under its umbrella (including tripleo-heat-templates) have gone through\n> incubation and integration nor have they been shipped with Icehouse.\n> \n> So there is no implicit compatibility guarantee and I have not found\n> anything about maintaining backwards compatibility neither on the\n> TripleO wiki page[4], tripleo-heat-template\'s readme[5] or\n> tripleo-incubator\'s readme[6].\n> \n> The Release Management wiki page[7] suggests that we follow Semantic\n> Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes.\n> According to that wiki, we are using a stronger guarantee where we do\n> promise to bump the minor version on incompatible changes -- but this\n> again suggests that we do not promise to maintain backwards\n> compatibility -- just that we document whenever we break it.\n> \n\nI think there are no guarantees, and no promises. I also think that we\'ve\nkept tripleo_heat_merge pretty narrow in surface area since making it\ninto a module, so I\'m not concerned that it will be incredibly difficult\nto keep those features alive for a while.\n\n> According to Robert, there are now downstreams that have shipped things\n> (with the implication that they don\'t expect things to change without a\n> deprecation period) so there\'s clearly a disconnect here.\n> \n\nI think it is more of a \"we will cause them extra work\" thing. If we\ncan make a best effort and deprecate for a few releases (as in, a few\nreleases of t-h-t, not OpenStack), they\'ll likely appreciate that. If\nwe can\'t do it without a lot of effort, we shouldn\'t bother.\n\n> If we do promise backwards compatibility, we should document it\n> somewhere and if we don\'t we should probably make that more visible,\n> too, so people know what to expect.\n> \n> I prefer the latter, because it will make the merge.py cleanup easier\n> and every published bit of information I could find suggests that\'s our\n> current stance anyway.\n> \n\nThis is more about good will than promising. If it is easy enough to\njust keep the code around and have it complain to us if we accidentally\nresurrect a feature, that should be enough. We could even introduce a\nswitch to the CLI like --strict that we can run in our gate and that\nwon\'t allow us to keep using deprecated features.\n\nSo I\'d like to see us deprecate not because we have to, but because we\ncan do it with only a small amount of effort.\n\n\n','<539F191C.5000605@redhat.com>',NULL),('<1402937541-sup-1478@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 09:58:19',-25200,'2014-06-16 16:58:19',NULL,'[openstack-dev] [TripleO] Backwards compatibility policy for\n	our projects','Excerpts from Duncan Thomas\'s message of 2014-06-16 09:41:49 -0700:\n> On 16 June 2014 17:30, Jason Rist <jrist at redhat.com> wrote:\n> > I\'m going to have to agree with Tomas here.  There doesn\'t seem to be\n> > any reasonable expectation of backwards compatibility for the reasons\n> > he outlined, despite some downstream releases that may be impacted.\n> \n> \n> Backward compatibility is a hard habit to get into, and easy to put\n> off. If you\'re not making any guarantees now, when are you going to\n> start making them? How much breakage can users expect? Without wanting\n> to look entirely like a troll, should TripleO be dropped as an\n> official until it can start making such guarantees? I think every\n> other official OpenStack project has a stable API policy of some kind,\n> even if they don\'t entirely match...\n> \n\nI actually agree with the sentiment of your statement, which is \"backward\ncompatibility matters.\"\n\nHowever, there is one thing that is inaccurate in your statements:\n\nTripleO is not a \"project\", it is a \"program\". These tools are products\nof that program\'s mission which is to deploy OpenStack using itself as\nmuch as possible. Where there are holes, we fill them with existing\ntools or we write minimal tools such as the tripleo_heat_merge Heat\ntemplate pre-processor.\n\nThis particular tool is marked for death as soon as Heat grows the\nappropriate capabilities to allow that. This tool never wants to\nbe integrated into the release. So it is a little hard to justify\nbending over backwards for BC. But I don\'t think that is what anybody\nis requesting.\n\nWe\'re not looking for this tool to remain super agile and grow, thus\nmaking any existing code and interfaces a burden. So I think it is pretty\neasy to just start marking features as deprecated and raising deprecation\nwarnings when they\'re used.\n\n\n','<CAOyZ2aG31Sk9y1NgzUR8wO7-s+hGFR0JZU2rF9Oo8RcN2gm+YQ@mail.gmail.com>',NULL),('<1402940367.10092.10.camel@kiall-desktop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 17:39:29',0,'2014-06-16 17:39:29',NULL,'[openstack-dev] Gate proposal - drop Postgresql configurations\n in the gate','On Thu, 2014-06-12 at 11:36 -0400, Sean Dague wrote:\n> If someone can point me to a case where we\'ve actually found this kind\n> of bug with tempest / devstack, that would be great. I\'ve just *never*\n> seen it. I was the one that did most of the fixing for pg support in\n> Nova, and have helped other projects as well, so I\'m relatively\n> familiar\n> with the kinds of fails we can discover. The ones that Julien pointed\n> really aren\'t likely to be exposed in our current system.\n> \n> Which is why I think we\'re mostly just burning cycles on the existing\n> approach for no gain.\n> \n>         -Sean\n\nI don\'t have links handy - but Designate has hit a couple of bugs that\nprevented our database migrations from succeeding on PostgreSQL - Maybe\na new re-usable test slave type for exercising database migrations +\ndatabase interface code against? These would be much quicker to run than\na full devstack/tempest gate..\n\nThanks,\nKiall\n\n','<5399C909.4050603@dague.net>',NULL),('<1402940688-sup-9609@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 10:49:30',-25200,'2014-06-16 17:49:30',NULL,'[openstack-dev] revert hacking to 0.8 series','Excerpts from Sean Dague\'s message of 2014-06-16 05:15:54 -0700:\n> Hacking 0.9 series was released pretty late for Juno. The entire check\n> queue was flooded this morning with requirements proposals failing pep8\n> because of it (so at 6am EST we were waiting 1.5 hrs for a check node).\n> \n> The previous soft policy with pep8 updates was that we set a pep8\n> version basically release week, and changes stopped being done for style\n> after first milestone.\n> \n> I think in the spirit of that we should revert the hacking requirements\n> update back to the 0.8 series for Juno. We\'re past milestone 1, so\n> shouldn\'t be working on style only fixes at this point.\n> \n> Proposed review here - https://review.openstack.org/#/c/100231/\n> \n> I also think in future hacking major releases need to happen within one\n> week of release, or not at all for that series.\n> \n\n+1. Hacking is supposed to help us avoid redundant nit-picking in\nreviews. If it places any large burden on developers, whether by merge\nconflicting or backing up CI, it is a failure IMO.\n\n\n','<539EDFFA.4000300@dague.net>',NULL),('<1402941038-sup-1972@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 11:15:01',-25200,'2014-06-16 18:15:01',NULL,'[openstack-dev] [TripleO] Backwards compatibility policy for\n	our projects','Excerpts from Duncan Thomas\'s message of 2014-06-16 10:46:12 -0700:\n> Hi Clint\n> \n> This looks like a special pleading here - all OpenStack projects (or\n> \'program\' if you prefer - I\'m honestly not seeing a difference) have\n> bits that they\'ve written quickly and would rather not have to\n> maintain, but in order to allow people to make use of them downstream\n> have to do that work. Ask the cinder team about how much I try to stay\n> on top of any back-compat issues.\n> \n\nI don\'t just prefer program. It is an entirely different thing:\n\nhttps://wiki.openstack.org/wiki/Programs\n\nhttps://wiki.openstack.org/wiki/Governance/NewProjects\n\n> If TripleO is not ready to take up that burden, then IMO it shouldn\'t\n> be an official project. If the bits that make it up are too immature\n> to actually be maintained with reasonable guarantees that they won\'t\n> just pull the rug out from any consumers, then their use needs to be\n> re-thought. Currently, tripleO enjoys huge benefits from its official\n> status, but isn\'t delivering to that standard. No other project has a\n> hope of coming in as an official deployment tool while tripleO holds\n> that niche. Despite this, tripleO is barely usable, and doesn\'t seem\n> to be maturing towards taking up the responsibilities that other\n> projects have had forced upon them. If it isn\'t ready for that, should\n> it go back to incubation and give some other team or technology a fair\n> chance to step up to the plate?\n> \n\nTripleO _isn\'t_ an official project. It is a program to make OpenStack\ndeploy itself. This is the same as the infra program, which has a\nmission to support development. We\'re not calling for Zuul to be\nintegrated into the release, we are just expecting it to keep supporting\nthe goals of the infra program and OpenStack in general.\n\nWhat is the \"official deployment tool\" you mention? There isn\'t one.\nThe tool we\'ve been debating is something that enables OpenStack to\nbe deployed using its own component, Heat, but that is sort of like\noslo-incubator.. it is driving a proof of concept for inclusion into an\nofficial project.\n\nIronic was spun out very early on because it was clear there was a need\nfor an integrated project to manage baremetal. This is an example where\npieces used for TripleO have been pushed into the integrated release.\n\nHowever, Heat already exists, and that is where the responsibility lies\nto orchestrate applications. We are driving quite a bit into Heat right\nnow, with a massive refactor of the core to be more resilient to the\ntypes of challenges a datacenter environment will present. The features\nwe get from the tripleo_heat_merge pre-processor that is in question\nwill be the next thing to go into Heat. Expecting us to commit resources\nto both of those efforts doesn\'t make much sense. The program is driving\nits mission, and the tools will be incubated and integrated when that\nmakes sense.\n\nMeanwhile, it turns out OpenStack _is not_ currently able to deploy\nitself. Users have to bolt things on, whether it is our tools, or\nsalt/puppet/chef/ansible artifacts, users cannot use just what is in\nOpenStack to deploy OpenStack. But we need to be able to test from one\nend to the other while we get things landed in OpenStack.. and so, we\nuse the pre-release model while we get to a releasable thing.\n\n> I don\'t want to look like I\'m specifically beating on tripleO here,\n> but it is the first openstack component I\'ve worked with that seems to\n> have this little concern for downstream users *and* no apparent plans\n> to fix it.\n> \n\nWhich component specifically are you referring to? Our plan, nay,\nour mission, is to fix it by pushing the necessary features into the\nrelevant projects.\n\nAlso, we actually take on a _higher_ burden of backward compatibility with\nsome of our tools that we do want to release. They\'re not integrated, and\nwe intend to keep them working with all releases of OpenStack because we\nintend to keep their interfaces stable for as long as those interfaces\nare relevant. diskimage-builder, os-apply-config, os-collect-config,\nos-refresh-config, are all stable, and don\'t need to be integrated into\nthe OpenStack release because they\'re not even OpenStack specific.\n\n> That\'s without going into all of the other difficulties myself and\n> fellow developers have had trying to get involved with tripleO, which\n> I\'ll go into at some other point.\n> \n\nI would be quite interested in any feedback you can give us on how\nhard it might be to join the effort. It is a large effort, and I know\nnew contributors can often get lost in a sea of possibilities if we,\nthe long time contributors, aren\'t careful to get them bootstrapped.\n\n> It is possible there are other places with similar problems, but this\n> is the first I\'ve run into - I\'ll call out any others I run into,\n> since I think it is important, and discussing it publicly keeps\n> everyone honest. If I\'ve got the wrong expectations, I\'d at least like\n> to have the correction on record.\n\nI do think that there is a misunderstanding that TripleO is some kind\nof tool. It is not. It is a program that spans all of OpenStack. We will\nbe producing the tuskar UI to tie together the OpenStack specific items\nfor a more user friendly experience. However, AFAICT, everything else\nis either intended to be small, stable tools that are forever backward\ncompatible, or independently useful components of OpenStack itself.\n\n\n','<CAOyZ2aGhbRJtgo0nZWXqXoVAHoYpzTUQMmB99iuHvabE+9kCNg@mail.gmail.com>',NULL),('<1402948509-sup-3641@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 12:56:24',-25200,'2014-06-16 19:56:24',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Doug Wiegley\'s message of 2014-06-10 14:41:29 -0700:\n> Of what use is a database that randomly delete rows?  That is, in effect, what you?re allowing.\n> \n> The secrets are only useful when paired with a service.  And unless I?m mistaken, there?s no undo.  So you?re letting users shoot themselves in the foot, for what reason, exactly?  How do you expect openstack to rely on a data store that is fundamentally random at the whim of users?  Every single service that uses Barbican will now have to hack in a defense mechanism of some kind, because they can?t trust that the secret they rely on will still be there later.  Which defeats the purpose of this mission statement:  \"Barbican is a ReST API designed for the secure storage, provisioning and management of secrets.?\n> \n> (And I don?t think anyone is suggesting that blind refcounts are the answer.  At least, I hope not.)\n> \n> Anyway, I hear this has already been decided, so, so be it.  Sounds like we?ll hack around it.\n> \n\n\nDoug, nobody is calling Barbican \"a database\". It is a place to store\nsecrets.\n\nThe idea is to loosely couple things, and if you need more assurances,\nuse something like Heat to manage the relationships.\n\n\n','<CFBCD576.284C%dougw@a10networks.com>',NULL),('<1402949606.23788.15.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 21:13:26',3600,'2014-06-16 20:13:26',NULL,'[openstack-dev] [oslo][messaging] messaging vs. messagingv2','Hi Ihar,\n\nOn Mon, 2014-06-16 at 15:28 +0200, Ihar Hrachyshka wrote:\n> Hi all,\n> \n> I\'m currently pushing Neutron to oslo.messaging, and while at it, a\n> question popped up.\n> \n> So in oslo-rpc, we have the following notification drivers available:\n> neutron.openstack.common.notifier.log_notifier\n> neutron.openstack.common.notifier.no_op_notifier\n> neutron.openstack.common.notifier.rpc_notifier2\n> neutron.openstack.common.notifier.rpc_notifier\n> neutron.openstack.common.notifier.test_notifier\n> \n> And in oslo.messaging, we have:\n> oslo.messaging.notify._impl_log:LogDriver\n> oslo.messaging.notify._impl_noop:NoOpDriver\n> oslo.messaging.notify._impl_messaging:MessagingV2Driver\n> oslo.messaging.notify._impl_messaging:MessagingDriver\n> oslo.messaging.notify._impl_test:TestDriver\n> \n> My understanding is that they map to each other as in [1].\n> \n> So atm Neutron uses rpc_notifier from oslo-rpc, so I\'m going to\n> replace it with MessagingDriver. So far so good.\n\nSo far so good, indeed.\n\n> But then I\'ve checked docstrings for MessagingDriver and\n> MessagingV2Driver [2], and the following looks suspicious to me. For\n> MessagingDriver, it\'s said:\n> \n> \"This driver should only be used in cases where there are existing\n> consumers deployed which do not support the 2.0 message format.\"\n> \n> This sounds like MessagingDriver is somehow obsolete, and we want to\n> use MessagingV2Driver unless forced to. But I don\'t get what those\n> consumers are. Are these other projects that interact with us via\n> messaging bus?\n> \n> Another weird thing is that it seems that no other project is actually\n> using MessagingV2Driver (at least those that I\'ve checked). Is it even\n> running in wild?\n\nThe idea is that deployments should move over to the v2 on-the-wire\nformat, but we\'ve never made any great efforts for that to happen.\n\nPart of the issue here is that notifications are consumed by codebases\noutside of OpenStack and, so, changing the default to v2 would likely\nunnecessarily disrupt some people.\n\nThe reason no-one has pushed very hard on a firm deprecation plan for\nthe v1 format is that the v2 format doesn\'t yet offer a huge amount of\nadvantages. Right now it just adds a \'2.0\' version number to the format.\nWhen we gain the ability to sign notification messages, this will only\nbe available via the v2 format and that will encourage more focus on\nswitching over fully.\n\nMark.\n\n\n\n','<539EF0E1.7010903@redhat.com>',NULL),('<1402949782.23788.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 21:16:22',3600,'2014-06-16 20:16:22',NULL,'[openstack-dev] [Nova] Nominating Ken\'ichi Ohmichi for nova-core','On Sat, 2014-06-14 at 08:40 +1000, Michael Still wrote:\n> Greetings,\n> \n> I would like to nominate Ken\'ichi Ohmichi for the nova-core team.\n> \n> Ken\'ichi has been involved with nova for a long time now.  His reviews\n> on API changes are excellent, and he\'s been part of the team that has\n> driven the new API work we\'ve seen in recent cycles forward. Ken\'ichi\n> has also been reviewing other parts of the code base, and I think his\n> reviews are detailed and helpful.\n\n+1, great to see Ken\'ichi join the team\n\nMark.\n\n\n\n','<CAEd1pt5YqF6ULc5tG4__bqjct8g3fiqevdxgHtjW1EqNksRqOg@mail.gmail.com>',NULL),('<1402952005-sup-568@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 14:06:42',-25200,'2014-06-16 21:06:42',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Doug Wiegley\'s message of 2014-06-16 13:22:26 -0700:\n> > nobody is calling Barbican \"a database\". It is a place to store\n> \n> ? did you at least feel a heavy sense of irony as you typed those two\n> statements?  ?It?s not a database, it just stores things!?  :-)\n> \n\nNot at all, though I understand that, clipped as so, it may look a bit\nironic.\n\nI was using shorthand of \"database\" to mean a general purpose database. I\nshould have qualified it to avoid any confusion. It is a narrow purpose\nstorage service with strong access controls. We can call that a database\nif you like, but I think it has one very tiny role, and that is to audit\nand control access to secrets.\n\n> The real irony here is that in this rather firm stand of keeping the user\n> in control of their secrets, you are actually making the user LESS in\n> control of their secrets.  Copies of secrets will have to be made, whether\n> stored under another tenant, or shadow copied somewhere.  And the user\n> will have no way to delete them, or even know that they exist.\n> \n\nWhy would you need to make copies outside of the in-RAM copy that is\nkept while the service runs? You\'re trying to do too much instead of\noperating in a nice loosely coupled fashion.\n\n> The force flag would eliminate the common mistake cases enough that I?d\n> wager lbaas and most others would cease to worry, not duplicate, and just\n> reference barbican id?s and nothing else.  (Not including backends that\n> will already make a copy of the secret, but things like servicevm will not\n> need to dup it.)  The earlier assertion that we have to deal with the\n> missing secrets case even with a force flag is, I think, false, because\n> once the common errors have been eliminated, the potential window of\n> accidental pain is reduced to those that really ask for it.\n\nThe accidental pain thing makes no sense to me. I\'m a user and I take\nresponsibility for my data. If I don\'t want to have that responsibility,\nI will use less privileged users and delegate the higher amount of\nprivilege to a system that does manage those relationships for me.\n\nDo we have mandatory file locking in Unix? No we don\'t. Why? Because some\nusers want the power to remove files _no matter what_. We build in the\nexpectation that things may disappear no matter what you do to prevent\nit. I think your LBaaS should be written with the same assumption. It\nwill be more resilient and useful to more people if they do not have to\nplay complicated games to remove a secret.\n\nAnyway, nobody has answered this. What user would indiscriminately delete\ntheir own data and expect that things depending on that data will continue\nto work indefinitely?\n\n\n','<CFC4AC1F.2DC5%dougw@a10networks.com>',NULL),('<1402952203-sup-7838@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 21:04:19',0,'2014-06-16 21:04:19',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','Excerpts from Jan Provazn?k\'s message of 2014-06-16 20:28:29 +0000:\n> Hi,\n> MariaDB is now included in Fedora repositories, this makes it easier to \n> install and more stable option for Fedora installations. Currently \n> MariaDB can be used by including mariadb (use mariadb.org pkgs) or \n> mariadb-rdo (use redhat RDO pkgs) element when building an image. What \n> do you think about using MariaDB as default option for Fedora when \n> running devtest scripts?\n\nId like to give this a try. This does start to change us from being a\ndeployment of openstck to being a deployment per distro but IMO thats a\nreasonable position.\n\nId also like to propose that if we decide against doing this then these\nelements should not live in tripleo-image-elements.\n\nCheers,\nGreg\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<539F536D.1090708@redhat.com>',NULL),('<1402953119-sup-6559@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 14:14:50',-25200,'2014-06-16 21:14:50',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','Excerpts from Gregory Haynes\'s message of 2014-06-16 14:04:19 -0700:\n> Excerpts from Jan Provazn?k\'s message of 2014-06-16 20:28:29 +0000:\n> > Hi,\n> > MariaDB is now included in Fedora repositories, this makes it easier to \n> > install and more stable option for Fedora installations. Currently \n> > MariaDB can be used by including mariadb (use mariadb.org pkgs) or \n> > mariadb-rdo (use redhat RDO pkgs) element when building an image. What \n> > do you think about using MariaDB as default option for Fedora when \n> > running devtest scripts?\n\n(first, I believe Jan means that MariaDB _Galera_ is now in Fedora)\n\n> \n> Id like to give this a try. This does start to change us from being a\n> deployment of openstck to being a deployment per distro but IMO thats a\n> reasonable position.\n> \n> Id also like to propose that if we decide against doing this then these\n> elements should not live in tripleo-image-elements.\n\nI\'m not so sure I agree. We have lio and tgt because lio is on RHEL but\neverywhere else is still using tgt IIRC.\n\nHowever, I also am not so sure that it is actually a good idea for people\nto ship on MariaDB since it is not in the gate. As it diverges from MySQL\n(starting in earnest with 10.x), there will undoubtedly be subtle issues\nthat arise. So I\'d say having MariaDB get tested along with Fedora will\nactually improve those users\' test coverage, which is a good thing.\n\n\n','<1402952203-sup-7838@greghaynes0>',NULL),('<1402954273-sup-4582@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 21:49:25',0,'2014-06-16 21:49:25',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','> > Id also like to propose that if we decide against doing this then these\n> > elements should not live in tripleo-image-elements.\n> \n> I\'m not so sure I agree. We have lio and tgt because lio is on RHEL but\n> everywhere else is still using tgt IIRC.\n\nLooks like we do have a cinder-tgt and a cinder-lio which we dont\nactually use anywhere, so you are correct. The mariadb-galera /\npercona-cluster elements are much more complex and active though, and\nseem very likely to have issues with forgetting to or incorrectly\nporting changes between them. It might also be a moot point if we end up\nmaking it a default. :)\n\n> \n> However, I also am not so sure that it is actually a good idea for people\n> to ship on MariaDB since it is not in the gate. As it diverges from MySQL\n> (starting in earnest with 10.x), there will undoubtedly be subtle issues\n> that arise. So I\'d say having MariaDB get tested along with Fedora will\n> actually improve those users\' test coverage, which is a good thing.\n> \n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<1402953119-sup-6559@fewbar.com>',NULL),('<1402960222.84422.YahooMailNeo@web125901.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-16 16:10:22',-25200,'2014-06-16 23:10:22',NULL,'[Openstack-docs] [training-guides]','	* Wiki has updated actions from the meetings\n\n	* I will continue to do this bit of extra work for a few meeting cycles, rather than just expect team leads to review the eavesdrop meeting pages.\n\n	* I tweaked the wiki page slightly to make it more readable\n	* Let get those bugs and specs rolling in\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140616/3e86736e/attachment.html>\n\n',NULL,NULL),('<1402961301-sup-1336@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 16:54:17',-25200,'2014-06-16 23:54:17',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Doug Wiegley\'s message of 2014-06-16 16:10:51 -0700:\n> Hi Clint,\n> \n> Comments below.\n> \n> On 6/16/14, 3:06 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> >Excerpts from Doug Wiegley\'s message of 2014-06-16 13:22:26 -0700:\n> >> > nobody is calling Barbican \"a database\". It is a place to store\n> >> \n> >> ? did you at least feel a heavy sense of irony as you typed those two\n> >> statements?  ?It?s not a database, it just stores things!?  :-)\n> >> \n> >\n> >Not at all, though I understand that, clipped as so, it may look a bit\n> >ironic.\n> >\n> >I was using shorthand of \"database\" to mean a general purpose database. I\n> >should have qualified it to avoid any confusion. It is a narrow purpose\n> >storage service with strong access controls. We can call that a database\n> >if you like, but I think it has one very tiny role, and that is to audit\n> >and control access to secrets.\n> >\n> >> The real irony here is that in this rather firm stand of keeping the\n> >>user\n> >> in control of their secrets, you are actually making the user LESS in\n> >> control of their secrets.  Copies of secrets will have to be made,\n> >>whether\n> >> stored under another tenant, or shadow copied somewhere.  And the user\n> >> will have no way to delete them, or even know that they exist.\n> >> \n> >\n> >Why would you need to make copies outside of the in-RAM copy that is\n> >kept while the service runs? You\'re trying to do too much instead of\n> >operating in a nice loosely coupled fashion.\n> \n> I?ll come back to this.\n> \n> >\n> >> The force flag would eliminate the common mistake cases enough that I?d\n> >> wager lbaas and most others would cease to worry, not duplicate, and\n> >>just\n> >> reference barbican id?s and nothing else.  (Not including backends that\n> >> will already make a copy of the secret, but things like servicevm will\n> >>not\n> >> need to dup it.)  The earlier assertion that we have to deal with the\n> >> missing secrets case even with a force flag is, I think, false, because\n> >> once the common errors have been eliminated, the potential window of\n> >> accidental pain is reduced to those that really ask for it.\n> >\n> >The accidental pain thing makes no sense to me. I\'m a user and I take\n> >responsibility for my data. If I don\'t want to have that responsibility,\n> >I will use less privileged users and delegate the higher amount of\n> >privilege to a system that does manage those relationships for me.\n> >\n> >Do we have mandatory file locking in Unix? No we don\'t. Why? Because some\n> >users want the power to remove files _no matter what_. We build in the\n> >expectation that things may disappear no matter what you do to prevent\n> >it. I think your LBaaS should be written with the same assumption. It\n> >will be more resilient and useful to more people if they do not have to\n> >play complicated games to remove a secret.\n> \n> There is literally no amount of resilience that can recover an HTTPS\n> service that has no SSL private key.  It?s just down.  Worse, it?s not\n> down when the user takes the action; it?s down at some indeterminate point\n> in the future (e.g. when it reboots next, or when the LB has to move two a\n> different servicevm.)  We could sub in a self-signed cert in that case,\n> though that?s as bad as down in many contexts.\n> \n\nThis is way too much focus on problems that are not LBaaS\'s. Help users\nmake keys for all other services, both inside the cloud and in the\nuser\'s machines, more reliable.. don\'t just magically make them reliable\nfor LBaaS.\n\n> I could be pedantic and point out that NFS files in use can?t be deleted,\n> but that?s not relevant to your point.  :-)\n> \n\nOn the remote system, correct. On the home system, they can be rm\'d\nright out from under the nfsd and there\'s nothing it can do about it.\n\nAnd that\'s just my point. NFS is a distributed system, and thus will\ntry to take care of the distributed system, but the lower level thing,\nthe host, is unencumbered by the service.\n\nI\'m suggesting that LBaaS and Barbican are both low level services,\nand thus should not be doing anything at a higher level.\n\n> >\n> >Anyway, nobody has answered this. What user would indiscriminately delete\n> >their own data and expect that things depending on that data will continue\n> >to work indefinitely?\n> \n> Maybe there are multiple admins and a miscommunication?  Memory lapse?\n> What kind of customer base do you have that doesn?t make those kinds of\n> mistakes *all the time*?  You?re assuming a perfect user with a perfect\n> memory; accidents happen.  Now pair that with a wildcard cert used by 1000\n> sites, and you?ve just one-clicked your way into *an extremely bad day*.\n> And you won?t even know it, until your pager starts to go off at some\n> later date.\n> \n\nThis is the same reason we don\'t login to systems as root and just do\nwhatever, right? We make admins funnel changes through a structured system\nthat can be reviewed, tracked, and collaborated on. But we still have\nroot.. and we still need it for zomg wtf times when the tooling fails.\n\nHow about you give users the rights to create keys and load balancers,\nbut not to delete? Make them gain higher privileges to delete, but use\nthat same privilege escalation automatically when you\'re using automation.\nI understand this is similar to the force flag, but it is also an optional\nthing that users won\'t be forced to use.\n\nThis maintains the simple distributed nature, gives users a \"safe\" way\nto use if they want, but doesn\'t force all users to work in the way you\nexpect them to and doesn\'t add a lot of extra plumbing to the system.\n\n> Neutron doesn?t let you delete objects in use, e.g.  Lots of other\n> examples in the API.  I?m not saying don?t let them cut their own foot\n> off, if that?s their choice (the unix delete example.)  But don?t make it\n> easy, just because ?they?d all just use force all the time anyway.?\n> \n\nNeutron owns all of those objects. They\'re all inside Neutron because\ntheir physical counterparts are literally tightly coupled with copper\nand fiber. That is not actually desired, it is a constraint of the\nsystem.\n\n> >Why would you need to make copies outside of the in-RAM copy that is\n> >kept while the service runs? You\'re trying to do too much instead of\n> >operating in a nice loosely coupled fashion.\n> \n> Back to this ? what you describe is what we *want* to do, but you have a\n> pile of operators and admins that aren?t comfortable with having a single\n> click, somewhere not related to the service, quietly setting a time bomb\n> for a later service failure/downtime.  Giving the user a way to easily\n> discover how much of their foot they?re about to blow off, before doing\n> it, is what we?re asking for.  And without it, I expect that workarounds\n> of all varieties will proliferate up and down the stack.\n\nThat\'s a noble goal, but not one for low level services to advance. You\nhave described the main use case for orchestration: Tie together services\nand machines in a way that is understandable and entirely under the\ncontrol of users.\n\n> \n> Force flag, soft deletes, resource tracking, even just displaying who?s\n> using what for a visual cue; there are any number of ways to make this\n> less dangerous without pushing it onto every consumer of your service.\n> \n\nThey\'re also ways to make the system more complex and brittle.\n\nLook, I\'m talking a lot and not showing up with code, so I\'m squelching\nmyself. The point is that this is a distributed system, and should be\nbuilt one service at a time. Services that do too much are going to be\noverly complex. I am happy to assist anybody in becoming a Heat user\nwho agrees with me and thinks that something like Heat should be the\nway users safely consume cross-project relationships.\n\n\n','<CFC4CF4C.2E08%dougw@a10networks.com>',NULL),('<1402965951-sup-5989@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 17:47:21',-25200,'2014-06-17 00:47:21',NULL,'[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS\n	Integration Ideas','Excerpts from Carlos Garza\'s message of 2014-06-16 16:25:10 -0700:\n> \n> On Jun 16, 2014, at 4:06 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Doug Wiegley\'s message of 2014-06-16 13:22:26 -0700:\n> >>> nobody is calling Barbican \"a database\". It is a place to store\n> >> \n> >> ? did you at least feel a heavy sense of irony as you typed those two\n> >> statements?  ?It?s not a database, it just stores things!?  :-)\n> >> \n> > \n> > Not at all, though I understand that, clipped as so, it may look a bit\n> > ironic.\n> > \n> > I was using shorthand of \"database\" to mean a general purpose database. I\n> > should have qualified it to avoid any confusion. It is a narrow purpose\n> > storage service with strong access controls. We can call that a database\n> > if you like, but I think it has one very tiny role, and that is to audit\n> > and control access to secrets.\n> > \n> >> The real irony here is that in this rather firm stand of keeping the user\n> >> in control of their secrets, you are actually making the user LESS in\n> >> control of their secrets.  Copies of secrets will have to be made, whether\n> >> stored under another tenant, or shadow copied somewhere.  And the user\n> >> will have no way to delete them, or even know that they exist.\n> >> \n> > \n> > Why would you need to make copies outside of the in-RAM copy that is\n> > kept while the service runs? You\'re trying to do too much instead of\n> > operating in a nice loosely coupled fashion.\n> \n>     Because the service may be restarted?\n> \n> > \n> >> The force flag would eliminate the common mistake cases enough that I?d\n> >> wager lbaas and most others would cease to worry, not duplicate, and just\n> >> reference barbican id?s and nothing else.  (Not including backends that\n> >> will already make a copy of the secret, but things like servicevm will not\n> >> need to dup it.)  The earlier assertion that we have to deal with the\n> >> missing secrets case even with a force flag is, I think, false, because\n> >> once the common errors have been eliminated, the potential window of\n> >> accidental pain is reduced to those that really ask for it.\n> > \n> > The accidental pain thing makes no sense to me. I\'m a user and I take\n> > responsibility for my data. If I don\'t want to have that responsibility,\n> > I will use less privileged users and delegate the higher amount of\n> > privilege to a system that does manage those relationships for me.\n> > \n> > Do we have mandatory file locking in Unix? No we don\'t. Why? Because some\n> > users want the power to remove files _no matter what_. We build in the\n> > expectation that things may disappear no matter what you do to prevent\n> > it. I think your LBaaS should be written with the same assumption. It\n> > will be more resilient and useful to more people if they do not have to\n> > play complicated games to remove a secret.\n> > \n> > Anyway, nobody has answered this. What user would indiscriminately delete\n> > their own data and expect that things depending on that data will continue\n> > to work indefinitely?\n> \n>     Users that are expecting barbican operations to only occur during the initial loadbalancer provisioning. IE users that don\'t realize their LBconfigs don\'t natively store the private keys and would be be retrieving keys on the fly during every migration,HA spin up, service restart(from power failure) etc. But I agree we shouldn\'t do force flag locking as the barbican team has already dismissed the possibility of adding policy enforcement on behalf of other services. Shadow copying(into a lbaas owned account on barbican) was just so that our lbaas backend can access the keys outside of the users control if need be. :|\n> \n\nI\'m not sure what that means, but perhaps this is a nice use case for\ntrusts, which would let the user hand LBaaS a revokable secret that\ngives LBaaS rights to impersonate the user for a specific keystone role.\n\n\n','<77CE29DF-9AFF-4F62-9A62-A7350D26FA39@rackspace.com>',NULL),('<1402983029.487.YahooMailNeo@web193604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-17 13:30:29',28800,'2014-06-17 05:30:29',NULL,'[Openstack] want to contribute studied architecture of swift','Hello all!\n\nI had studied the architecture of swift from its source code available at Github.\nAnd, I want to contribute that with swift community.\n\nCan I contribute it?\n\nRegards?\nPragya jain\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140617/35cc13ea/attachment.html>\n\n',NULL,NULL),('<1403015303.3132.5.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-17 14:28:24',0,'2014-06-17 14:28:24',NULL,'[openstack-dev] [Manila] GenericDriver cinder volume error\n during manila create','On Mon, 2014-06-16 at 23:06 +0530, Deepak Shetty wrote:\n> I am trying devstack on F20 setup with Manila sources.\n\n> When i am trying to do\n> manila create --name cinder_vol_share_using_nfs2 --share-network-id\n> 36ec5a17-cef6-44a8-a518-457a6f36faa0 NFS 2 \n\n> I see the below error in c-vol due to which even tho\' my service VM is\n> started, manila create errors out as cinder volume is not getting\n> exported as iSCSI\n\n> 2014-06-16 16:39:36.151 INFO cinder.volume.flows.manager.create_volume\n> [req-15d0b435-f6ce-41cd-ae4a-3851b07cf774\n> 1a7816e5f0144c539192360cdc9672d5 b65a066f32df4aca80fa9a\n> 6d5c795095] Volume 8bfd424d-9877-4c20-a9d1-058c06b9bdda: being created\n> as raw with specification: {\'status\': u\'creating\', \'volume_size\': 2,\n> \'volume_name\': u\'volume-8bfd\n> 424d-9877-4c20-a9d1-058c06b9bdda\'}\n> 2014-06-16 16:39:36.151 DEBUG cinder.openstack.common.processutils\n> [req-15d0b435-f6ce-41cd-ae4a-3851b07cf774\n> 1a7816e5f0144c539192360cdc9672d5 b65a066f32df4aca80fa9a6d5c\n> 795095] Running cmd (subprocess): sudo\n> cinder-rootwrap /etc/cinder/rootwrap.conf lvcreate -n\n> volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda stack-volumes -L 2g from\n> (pid=4\n> 623)\n> execute /opt/stack/cinder/cinder/openstack/common/processutils.py:142\n> 2014-06-16 16:39:36.828 INFO cinder.volume.flows.manager.create_volume\n> [req-15d0b435-f6ce-41cd-ae4a-3851b07cf774\n> 1a7816e5f0144c539192360cdc9672d5 b65a066f32df4aca80fa9a\n> 6d5c795095] Volume volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> (8bfd424d-9877-4c20-a9d1-058c06b9bdda): created successfully\n> 2014-06-16 16:39:38.404 WARNING cinder.context [-] Arguments dropped\n> when creating context: {\'user\': u\'d9bb59a6a2394483902b382a991ffea2\',\n> \'tenant\': u\'b65a066f32df4aca80\n> fa9a6d5c795095\', \'user_identity\': u\'d9bb59a6a2394483902b382a991ffea2\n> b65a066f32df4aca80fa9a6d5c795095 - - -\'}\n> 2014-06-16 16:39:38.426 DEBUG cinder.volume.manager\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> Volume \n> 8bfd424d-9877-4c20-a9d1-058c06b9bdda: creating export from (pid=4623)\n> initialize_connection /opt/stack/cinder/cinder/volume/manager.py:781\n> 2014-06-16 16:39:38.428 INFO cinder.brick.iscsi.iscsi\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> Creat\n> ing iscsi_target for: volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> 2014-06-16 16:39:38.440 DEBUG cinder.brick.iscsi.iscsi\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> Crea\n> ted volume\n> path /opt/stack/data/cinder/volumes/volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda,\n> content: \n> <target\n> iqn.2010-10.org.openstack:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda>\n> backing-store /dev/stack-volumes/volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> lld iscsi\n> IncomingUser kZQ6rqqT7W6KGQvMZ7Lr k4qcE3G9g5z7mDWh2woe\n> </target>\n> from (pid=4623)\n> create_iscsi_target /opt/stack/cinder/cinder/brick/iscsi/iscsi.py:183\n> 2014-06-16 16:39:38.440 DEBUG cinder.openstack.common.processutils\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c\n> 795095] Running cmd (subprocess): sudo\n> cinder-rootwrap /etc/cinder/rootwrap.conf tgt-admin --update\n> iqn.2010-10.org.openstack:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdd\n> a from (pid=4623)\n> execute /opt/stack/cinder/cinder/openstack/common/processutils.py:142\n> 2014-06-16 16:39:38.981 DEBUG cinder.openstack.common.processutils\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c\n> 795095] Result was 107 from (pid=4623)\n> execute /opt/stack/cinder/cinder/openstack/common/processutils.py:167\n> 2014-06-16 16:39:38.981 WARNING cinder.brick.iscsi.iscsi\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095] Fa\n> iled to create iscsi target for volume\n> id:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda: Unexpected error while\n> running command.\n> Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf tgt-admin\n> --update\n> iqn.2010-10.org.openstack:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> Exit code: 107\n> Stdout: \'Command:\\n\\ttgtadm -C 0 --lld iscsi --op new --mode target\n> --tid 1 -T\n> iqn.2010-10.org.openstack:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> \\nexited with code: 107.\\n\'\n> Stderr: \'tgtadm: failed to send request hdr to tgt daemon, Transport\n> endpoint is not connected\\ntgtadm: failed to send request hdr to tgt\n> daemon, Transport endpoint is not connected\\ntgtadm: failed to send\n> request hdr to tgt daemon, Transport endpoint is not connected\n> \\ntgtadm: failed to send request hdr to tgt daemon, Transport endpoint\n> is not connected\\n\'\n> 2014-06-16 16:39:38.982 ERROR oslo.messaging.rpc.dispatcher\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> Exception during message handling: Failed to create iscsi target for\n> volume volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda.\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher Traceback\n> (most recent call last):\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 134, in _dispatch_and_reply\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher\n> incoming.message))\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 177, in _dispatch\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher return\n> self._do_dispatch(endpoint, method, ctxt, args)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 123, in _do_dispatch\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher result =\n> getattr(endpoint, method)(ctxt, **new_args)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/opt/stack/cinder/cinder/volume/manager.py\", line 783, in\n> initialize_connection\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher volume)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/opt/stack/cinder/cinder/volume/drivers/lvm.py\", line 524, in\n> create_export\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher return\n> self._create_export(context, volume)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/opt/stack/cinder/cinder/volume/drivers/lvm.py\", line 533, in\n> _create_export\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher data =\n> self.target_helper.create_export(context, volume, volume_path)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/opt/stack/cinder/cinder/volume/iscsi.py\", line 53, in create_export\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher chap_auth)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher File\n> \"/opt/stack/cinder/cinder/brick/iscsi/iscsi.py\", line 219, in\n> create_iscsi_target\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher raise\n> exception.ISCSITargetCreateFailed(volume_id=vol_id)\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher\n> ISCSITargetCreateFailed: Failed to create iscsi target for volume\n> volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda.\n> 2014-06-16 16:39:38.982 TRACE oslo.messaging.rpc.dispatcher \n> 2014-06-16 16:39:39.031 ERROR oslo.messaging._drivers.common\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> Returning exception Failed to create iscsi target for volume\n> volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda. to caller\n> 2014-06-16 16:39:39.031 ERROR oslo.messaging._drivers.common\n> [req-083cd582-1b4d-4e7c-a70c-2c6282d8d799\n> d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095]\n> [\'Traceback (most recent call last):\\n\', \' File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 134, in _dispatch_and_reply\\n incoming.message))\\n\', \' File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 177, in _dispatch\\n return self._do_dispatch(endpoint, method,\n> ctxt, args)\\n\', \' File\n> \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\",\n> line 123, in _do_dispatch\\n result = getattr(endpoint, method)(ctxt,\n> **new_args)\\n\', \' File \"/opt/stack/cinder/cinder/volume/manager.py\",\n> line 783, in initialize_connection\\n volume)\\n\', \' File\n> \"/opt/stack/cinder/cinder/volume/drivers/lvm.py\", line 524, in\n> create_export\\n return self._create_export(context, volume)\\n\', \' File\n> \"/opt/stack/cinder/cinder/volume/drivers/lvm.py\", line 533, in\n> _create_export\\n data = self.target_helper.create_export(context,\n> volume, volume_path)\\n\', \' File\n> \"/opt/stack/cinder/cinder/volume/iscsi.py\", line 53, in create_export\n> \\n chap_auth)\\n\', \' File\n> \"/opt/stack/cinder/cinder/brick/iscsi/iscsi.py\", line 219, in\n> create_iscsi_target\\n raise\n> exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\',\n> \'ISCSITargetCreateFailed: Failed to create iscsi target for volume\n> volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda.\\n\']\n> 2014-06-16 16:39:40.167 WARNING cinder.context [-] Arguments dropped\n> when creating context: {\'user\': u\'d9bb59a6a2394483902b382a991ffea2\',\n> \'tenant\': u\'b65a066f32df4aca80fa9a6d5c795095\', \'user_identity\':\n> u\'d9bb59a6a2394483902b382a991ffea2 b65a066f32df4aca80fa9a6d5c795095 -\n> - -\'}\n\n> Some debug info..\n> [stack at devstack-large-vm ~]$ [admin] manila list --all-tenants\n> +--------------------------------------+-----------------------------+------+-------------+--------+-----------------+\n> |                  ID                  |             Name            |\n> Size | Share Proto | Status | Export location |\n> +--------------------------------------+-----------------------------+------+-------------+--------+-----------------+\n> | b35518d0-20a7-4768-ba44-8f6a5b03807a |  cinder_vol_share_using_nfs |\n> 2   |     NFS     | error  |       None      |\n> | fb78748b-1031-4e4f-86ae-6427a3ee8c97 | cinder_vol_share_using_nfs2 |\n> 2   |     NFS     | error  |       None      |\n> +--------------------------------------+-----------------------------+------+-------------+--------+-----------------+\n\n> I get the same error when trying to do the cinder-rootwrap cmd that\n> otherwise is done by c-vol\n> \n> +--------------------------------------+-----------------------------+------+-------------+--------+-----------------+\n> [stack at devstack-large-vm ~]$ [admin] sudo\n> cinder-rootwrap /etc/cinder/rootwrap.conf tgt-admin --update\n> iqn.2010-10.org.openstack:volume-8bfd424d-9877-4c20-a9d1-058c06b9bdda\n> tgtadm: failed to send request hdr to tgt daemon, Transport endpoint\n> is not connected\n> tgtadm: failed to send request hdr to tgt daemon, Transport endpoint\n> is not connected\n> tgtadm: failed to send request hdr to tgt daemon, Transport endpoint\n> is not connected\n> \n> [stack at devstack-large-vm ~]$ [admin] cinder list --all-tenants\n> +--------------------------------------+-----------+---------------------------------------------------+------+-------------+----------+-------------+\n> |                  ID                  |   Status  |\n> Display Name                   | Size | Volume Type | Bootable |\n> Attached to |\n> +--------------------------------------+-----------+---------------------------------------------------+------+-------------+----------+-------------+\n> | 8bfd424d-9877-4c20-a9d1-058c06b9bdda | available |\n> manila-share-b35518d0-20a7-4768-ba44-8f6a5b03807a |  2   |     None\n> |  false   |             |\n> | af9e8c90-d2fb-4c57-884b-7234400b16cd | available |\n> manila-share-fb78748b-1031-4e4f-86ae-6427a3ee8c97 |  2   |     None\n> |  false   |             |\n> +--------------------------------------+-----------+---------------------------------------------------+------+-------------+----------+-------------+\n> \n> \n> iscsi and iscsid.service both are running in my system\n> \n> [stack at devstack-large-vm ~]$ [admin] sudo systemctl status\n> iscsi.service \n> iscsi.service - Login and scanning of iSCSI devices\n>    Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled)\n>    Active: inactive (dead)\n>            start condition failed at Mon 2014-06-16 16:01:22 UTC; 1h\n> 33min ago\n>            none of the trigger conditions were met\n>      Docs: man:iscsid(8)\n>            man:iscsiadm(8)\n> \n> Jun 16 16:01:22 devstack-large-vm.localdomain systemd[1]: Started\n> Login and scanning of iSCSI devices.\n> [stack at devstack-large-vm ~]$ [admin] sudo systemctl status\n> iscsid.service \n> iscsid.service - Open-iSCSI\n>    Loaded: loaded (/usr/lib/systemd/system/iscsid.service; disabled)\n>    Active: active (running) since Mon 2014-06-16 17:26:50 UTC; 8min\n> ago\n>      Docs: man:iscsid(8)\n>            man:iscsiadm(8)\n>   Process: 20236 ExecStart=/usr/sbin/iscsid (code=exited,\n> status=0/SUCCESS)\n>  Main PID: 20239 (iscsid)\n>    CGroup: /system.slice/iscsid.service\n>            ??20238 /usr/sbin/iscsid\n>            ??20239 /usr/sbin/iscsid\n> \n> \n> Any hints are appreciated\n\nFrom the info you\'ve posted here it sounds like the problem is with\ncinder rather than manila. Are you able to create cinder volumes and\nnova instances and attach them outside of manila? If not, then you need\nto fix that before trying manila w/ the generic driver. If those things\nare working, then we would want to look into what manila is doing wrong.\n\n\n> thanx,\n> deepak\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAOXiiM=SOUFU181RN8RQCeR-iYX66anUTjxvhywBiK-UajGezQ@mail.gmail.com>',NULL),('<1403019930.3132.11.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-17 15:45:31',0,'2014-06-17 15:45:31',NULL,'[openstack-dev] [Manila] Welcome Xing Yang to the Manila core team!','The Manila core team welcomes Xing Yang! She has been a very active\nreviewer and has been consistently involved with the project.\n\nXing, thank you for all your effort and keep up the great work!\n\n-Ben Swartzlander\n\n\n',NULL,NULL),('<1403025100-sup-987@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-17 10:18:57',-25200,'2014-06-17 17:18:57',NULL,'[openstack-dev] [nova] Distributed locking','Excerpts from Matthew Booth\'s message of 2014-06-17 01:36:11 -0700:\n> On 17/06/14 00:28, Joshua Harlow wrote:\n> > So this is a reader/write lock then?\n> > \n> > I have seen https://github.com/python-zk/kazoo/pull/141 come up in the\n> > kazoo (zookeeper python library) but there was a lack of a maintainer for\n> > that \'recipe\', perhaps if we really find this needed we can help get that\n> > pull request \'sponsored\' so that it can be used for this purpose?\n> > \n> > \n> > As far as resiliency, the thing I was thinking about was how correct do u\n> > want this lock to be?\n> > \n> > If u say go with memcached and a locking mechanism using it this will not\n> > be correct but it might work good enough under normal usage. So that?s why\n> > I was wondering about what level of correctness do you want and what do\n> > you want to happen if a server that is maintaining the lock record dies.\n> > In memcaches case this will literally be 1 server, even if sharding is\n> > being used, since a key hashes to one server. So if that one server goes\n> > down (or a network split happens) then it is possible for two entities to\n> > believe they own the same lock (and if the network split recovers this\n> > gets even weirder); so that?s what I was wondering about when mentioning\n> > resiliency and how much incorrectness you are willing to tolerate.\n> \n> From my POV, the most important things are:\n> \n> * 2 nodes must never believe they hold the same lock\n> * A node must eventually get the lock\n> \n\nIf these are musts, then memcache is a no-go for locking. memcached is\nlikely to delete anything it is storing in its RAM, at any time. Also\nif you have several memcache servers, a momentary network blip could\nlead to acquiring the lock erroneously.\n\nThe only thing it is useful for is coalescing, where a broken lock just\nmeans wasted resources, erroneous errors, etc. If consistency is needed,\nthen you need a consistent backend.\n\n\n','<539FFDFB.7080908@redhat.com>',NULL),('<1403025626-sup-1805@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-17 10:21:57',-25200,'2014-06-17 17:21:57',NULL,'[openstack-dev] [TripleO] Backwards compatibility policy for\n	our projects','Excerpts from Tomas Sedovic\'s message of 2014-06-17 04:56:24 -0700:\n> On 16/06/14 18:51, Clint Byrum wrote:\n> > Excerpts from Tomas Sedovic\'s message of 2014-06-16 09:19:40 -0700:\n> >> All,\n> >>\n> >> After having proposed some changes[1][2] to tripleo-heat-templates[3],\n> >> reviewers suggested adding a deprecation period for the merge.py script.\n> >>\n> >> While TripleO is an official OpenStack program, none of the projects\n> >> under its umbrella (including tripleo-heat-templates) have gone through\n> >> incubation and integration nor have they been shipped with Icehouse.\n> >>\n> >> So there is no implicit compatibility guarantee and I have not found\n> >> anything about maintaining backwards compatibility neither on the\n> >> TripleO wiki page[4], tripleo-heat-template\'s readme[5] or\n> >> tripleo-incubator\'s readme[6].\n> >>\n> >> The Release Management wiki page[7] suggests that we follow Semantic\n> >> Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes.\n> >> According to that wiki, we are using a stronger guarantee where we do\n> >> promise to bump the minor version on incompatible changes -- but this\n> >> again suggests that we do not promise to maintain backwards\n> >> compatibility -- just that we document whenever we break it.\n> >>\n> > \n> > I think there are no guarantees, and no promises. I also think that we\'ve\n> > kept tripleo_heat_merge pretty narrow in surface area since making it\n> > into a module, so I\'m not concerned that it will be incredibly difficult\n> > to keep those features alive for a while.\n> > \n> >> According to Robert, there are now downstreams that have shipped things\n> >> (with the implication that they don\'t expect things to change without a\n> >> deprecation period) so there\'s clearly a disconnect here.\n> >>\n> > \n> > I think it is more of a \"we will cause them extra work\" thing. If we\n> > can make a best effort and deprecate for a few releases (as in, a few\n> > releases of t-h-t, not OpenStack), they\'ll likely appreciate that. If\n> > we can\'t do it without a lot of effort, we shouldn\'t bother.\n> \n> Oh. I did assume we were talking about OpenStack releases, not t-h-t,\n> sorry. I have nothing against making a new tht release that deprecates\n> the features we\'re no longer using and dropping them for good in a later\n> release.\n> \n> What do you suggest would be a reasonable waiting period? Say a month or\n> so? I think it would be good if we could remove all the deprecated stuff\n> before we start porting our templates to HOT.\n> \n> > \n> >> If we do promise backwards compatibility, we should document it\n> >> somewhere and if we don\'t we should probably make that more visible,\n> >> too, so people know what to expect.\n> >>\n> >> I prefer the latter, because it will make the merge.py cleanup easier\n> >> and every published bit of information I could find suggests that\'s our\n> >> current stance anyway.\n> >>\n> > \n> > This is more about good will than promising. If it is easy enough to\n> > just keep the code around and have it complain to us if we accidentally\n> > resurrect a feature, that should be enough. We could even introduce a\n> > switch to the CLI like --strict that we can run in our gate and that\n> > won\'t allow us to keep using deprecated features.\n> > \n> > So I\'d like to see us deprecate not because we have to, but because we\n> > can do it with only a small amount of effort.\n> \n> Right, that\'s fair enough. I\'ve thought about adding a strict switch,\n> too, but I\'d like to start removing code from merge.py, not adding more :-).\n> \n\nLet\'s just leave the capability forever. We\'re not adding things to\nmerge.py or taking it in any new directions. Keeping the code does not\ncost us anything. Some day merge.py won\'t be used, and then it will be\nlike we deleted the whole thing.\n\n\n','<53A02CE8.4060508@redhat.com>',NULL),('<1403045317.16521.YahooMailNeo@web125902.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-17 15:48:37',-25200,'2014-06-17 22:48:37',NULL,'[Openstack-docs] time to close out the original blueprint','I\'d like to change the implementation status to implemented for blueprint?https://blueprints.launchpad.net/openstack-manuals/+spec/training-manuals\nIf someone was to stumble upon this blueprint now that there is another launchpad project for training-guides it would be a bit confusing.\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140617/1a219cfe/attachment.html>\n\n',NULL,NULL),('<1403055140.10289.7.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-17 21:32:20',-14400,'2014-06-18 01:32:20',NULL,'[OpenStack-Infra] Status of check-tempest-dsvm-f20 job','On Tue, 2014-06-17 at 17:05 -0400, Sean Dague wrote:\n> On 06/17/2014 04:16 PM, Ian Wienand wrote:\n> > Hi,\n> > \n> > I added an item to today\'s meeting but we didn\'t get to it.\n> > \n> > I\'d like to bring up the disablement of the F20 based job, disabled in\n> > [1] with some discussion in [2].\n> > \n> > It\'s unclear to me why there are insufficient Fedora nodes.  Is the\n> > problem that Fedora is booting too slowly compared to other\n> > distributions?  Is there some other Fedora specific issue we can work\n> > on?\n> > \n> > Demoting to experimental essentially means stopping the job and\n> > letting it regress; when the job was experimental before I was\n> > triggering the run for each devstack change (to attempt to maintain\n> > stability) but this also triggers about 4 other experimental jobs,\n> > making the load issues even worse.\n> > \n> > What needs to happen before we can get this job promoted again?\n> > \n> > Thanks\n> \n> It was demoted yesterday when devstack and devstack-gate changes were\n> stacking up in check waiting on an f20 node to be allocated for a\n> non-voting job.\n> \n> When we it off devstack changes had been waiting 5 hrs in check, with no\n> f20 node allocated. One of those was a critical fix for gate issues\n> which we just manually gate promoted.\n> \n> Because this is the way this degrades when we are using all our quota,\n> I\'m really wary of adding these back until we discuss the expectations\n> here (possibly in Germany). Because devstack ends up often being a knob\n> we can adjust to dig ourselves out of a gate backup, making it get extra\n> delay when we are at load, is something I don\'t think serves us well.\n> \n> If nodepool (conceptually) filled the longest outstanding requests with\n> higher priority, I\'d be uber happy. This would also help with more fully\n> using our capacity, because the mix of nodes that we need any given hour\n> kind of changes. But as jeblair said, this is non trivial to implement.\n> Ensuring a minimum number of nodes (where that might be 1 or 2) for each\n> class would have helped this particular situation. We actually had 0\n> nodes in use or ready of the type at the time.\n\nWould this fix (or something similar) help nodepool to allocate things\nmore efficiently?\n\nhttps://review.openstack.org/#/c/88223/\n\nWe\'ve seen similar behavior in the TripleO pipeline when the queue gets\nfull.\n\n> \n> So I\'m in the \'prefer not\' camp for devstack right now.\n> \n> 	-Sean\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n\n\n','<53A0AD81.1090201@dague.net>',NULL),('<1403071093.23788.22.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 06:58:13',3600,'2014-06-18 05:58:13',NULL,'[openstack-dev] [glance] Unifying configuration file','Hey\n\nOn Tue, 2014-06-17 at 17:43 +0200, Julien Danjou wrote:\n> On Tue, Jun 17 2014, Arnaud Legendre wrote:\n> \n> > @ZhiYan: I don\'t like the idea of removing the sample configuration file(s)\n> > from the git repository. Many people do not want to have to checkout the\n> > entire codebase and tox every time they have to verify a variable name in a\n> > configuration file. I know many people who were really frustrated where they\n> > realized that the sample config file was gone from the Nova repo.\n> > However, I agree with the fact that it would be better if the sample was\n> > 100% accurate: so the way I would love to see this working is to generate\n> > the sample file every time there is a config change (this being totally\n> > automated (maybe at the gate level...)).\n> \n> You\'re a bit late on this. :)\n> So what I did these last months (year?) in several project, is to check\n> at gate time the configuration file that is automatically generated\n> against what\'s in the patches.\n> That turned out to be a real problem because sometimes some options\n> changes from the eternal module we rely on (e.g. keystone authtoken or\n> oslo.messaging). In the end many projects (like Nova) disabled this\n> check altogether, and therefore removed the generated configuration file\n> From the git repository.\n\nFor those that casually want to refer to the sample config, what would\nhelp if there was Jenkins jobs to publish the generated sample config\nfile somewhere.\n\nFor people installing the software, it would probably be nice if pbr\nadded \'python setup.py sample_config\' or something.\n\n> > @Julien: I would be interested to understand the value that you see of\n> > having only one config file? At this point, I don\'t see why managing one\n> > file is more complicated than managing several files especially when they\n> > are organized by categories. Also, scrolling through the registry settings\n> > every time I want to modify an api setting seem to add some overhead.\n> \n> Because there\'s no way to automatically generate several configuration\n> files with each its own set of options using oslo.config.\n\nI think that\'s a failing of oslo.config, though. Glance\'s layout of\nconfig files is useful and intuitive.\n\n> Glance is (one of?) the last project in OpenStack to manually write its\n> sample configuration file, which are not up to date obviously.\n\nNeutron too, but not split out per-service. I don\'t find Neutron\'s\nconfig file layout as intuitive.\n\n> So really this is mainly about following what every other projects did\n> the last year(s).\n\nThere\'s a balance here between what makes technical sense and what helps\nusers. If Glance has support for generating a unified config file while\nalso manually maintaining the split configs, I think that\'s a fine\ncompromise.\n\nMark.\n\n\n\n','<m2lhsvr179.fsf@danjou.info>',NULL),('<1403090390.6960.7.camel@fsdell1407.fi.f-secure.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-18 11:19:50',0,'2014-06-18 11:19:50',NULL,'[Openstack] ldap/AD Integration on Icehouse','Hi,\n\nI was trying to integrate our test Icehouse openstack environment into the AD (Active Directory) in order to pilot user management through the AD. I\'ve read official documentations regarding the topic :\n\nhttp://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html\nhttps://wiki.openstack.org/wiki/HowtoIntegrateKeystonewithAD#Configuration_on_Keystone\nhttp://openstack.redhat.com/Keystone_integration_with_IDM\n\nAll the above docs only explain just the keystone part. But, there is no doc how exactly the AD side should be configured.\n\nAnyway, I\'ve managed to come to a point where having the following error in keystone.log :\n\n2014-06-18 10:56:35.024 1706 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:271\n2014-06-18 10:56:35.063 1706 DEBUG keystone.common.wsgi [-] arg_dict: {} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181\n2014-06-18 10:56:35.065 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.066 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.069 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.076 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(sAMAccountName=nova)(objectClass=Person)), attrs=[\'userPassword\', \'userAccountControl\', \'sAMAccountName\', \'mail\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.079 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.081 1706 DEBUG keystone.notifications [-] CADF Event: {\'typeURI\': \'http://schemas.dmtf.org/cloud/audit/1.0/event\', \'initiator\': {\'typeURI\': \'service/security/account/user\', \'host\': {\'agent\': \'python-requests/1.1.0 CPython/2.6.6 Linux/2.6.32-431.17.1.el6.x86_64\', \'address\': \'1.x.x.x\'}, \'id\': \'openstack:3b761d61-1f9c-463c-adc4-cf83a8873aaa\', \'name\': \'nova\'}, \'target\': {\'typeURI\': \'service/security/account/user\', \'id\': \'openstack:b588a4a4-4537-4a3c-a56e-68d7518bbf69\'}, \'observer\': {\'typeURI\': \'service/security\', \'id\': \'openstack:35c9ba06-17b0-482f-b86a-c7407b698fe2\'}, \'eventType\': \'activity\', \'eventTime\': \'2014-06-18T10:56:35.080881+0000\', \'action\': \'authenticate\', \'outcome\': \'pending\', \'id\': \'openstack:d4b86103-3dc9-4577-a9c4-74fc2cc4152c\'} _send_audit_notification /usr/lib/python2.6/site-packages/keystone/notifications.py:289\n2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'qpid = oslo.messaging._drivers.impl_qpid:QpidDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'zmq = oslo.messaging._drivers.impl_zmq:ZmqDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'kombu = oslo.messaging._drivers.impl_rabbit:RabbitDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.137 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'rabbit = oslo.messaging._drivers.impl_rabbit:RabbitDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.194 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'fake = oslo.messaging._drivers.impl_fake:FakeDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'log = oslo.messaging.notify._impl_log:LogDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'messagingv2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'noop = oslo.messaging.notify._impl_noop:NoOpDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'routing = oslo.messaging.notify._impl_routing:RoutingDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'test = oslo.messaging.notify._impl_test:TestDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'messaging = oslo.messaging.notify._impl_messaging:MessagingDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'cinder.openstack.common.notifier.no_op_notifier = oslo.messaging.notify._impl_noop:NoOpDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'cinder.openstack.common.notifier.log_notifier = oslo.messaging.notify._impl_log:LogDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'cinder.openstack.common.notifier.test_notifier = oslo.messaging.notify._impl_test:TestDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'cinder.openstack.common.notifier.rpc_notifier2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'cinder.openstack.common.notifier.rpc_notifier = oslo.messaging.notify._impl_messaging:MessagingDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'nova.openstack.common.notifier.no_op_notifier = oslo.messaging.notify._impl_noop:NoOpDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'nova.openstack.common.notifier.test_notifier = oslo.messaging.notify._impl_test:TestDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'nova.openstack.common.notifier.rpc_notifier = oslo.messaging.notify._impl_messaging:MessagingDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.198 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'nova.openstack.common.notifier.log_notifier = oslo.messaging.notify._impl_log:LogDriver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.198 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse(\'nova.openstack.common.notifier.rpc_notifier2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver\') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156\n2014-06-18 10:56:35.199 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.200 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.200 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.205 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectClass=Person)), attrs=[\'mail\', \'userPassword\', \'userAccountControl\', \'sAMAccountName\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.207 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.208 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.209 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.210 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.215 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectclass=Person)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.218 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.218 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.219 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.220 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=nova,OU=services,OU=Projects,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.224 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.226 1706 DEBUG keystone.notifications [-] CADF Event: {\'typeURI\': \'http://schemas.dmtf.org/cloud/audit/1.0/event\', \'initiator\': {\'typeURI\': \'service/security/account/user\', \'host\': {\'agent\': \'python-requests/1.1.0 CPython/2.6.6 Linux/2.6.32-431.17.1.el6.x86_64\', \'address\': \'1.x.x.x\'}, \'id\': \'openstack:3b761d61-1f9c-463c-adc4-cf83a8873aaa\', \'name\': \'nova\'}, \'target\': {\'typeURI\': \'service/security/account/user\', \'id\': \'openstack:12c5c400-0a51-4477-baf4-b95c91ba60ad\'}, \'observer\': {\'typeURI\': \'service/security\', \'id\': \'openstack:d12b322f-9c1a-493f-ac0d-6727d37cff39\'}, \'eventType\': \'activity\', \'eventTime\': \'2014-06-18T10:56:35.225896+0000\', \'action\': \'authenticate\', \'outcome\': \'success\', \'id\': \'openstack:aa435cf2-6fd2-4cce-a40e-53753cab55bf\'} _send_audit_notification /usr/lib/python2.6/site-packages/keystone/notifications.py:289\n2014-06-18 10:56:35.227 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.228 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.229 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.234 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=[\'description\', \'extensionName\', \'businessCategory\', \'ou\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.237 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.237 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.238 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.238 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.243 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=[\'ou\', \'description\', \'businessCategory\', \'extensionName\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.246 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.246 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.247 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.247 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.251 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=[\'ou\', \'description\', \'businessCategory\', \'extensionName\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.254 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.254 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.255 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.256 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.261 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=[\'ou\', \'description\', \'businessCategory\', \'extensionName\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.263 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.264 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.265 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.266 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.270 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectclass=organizationalUnit)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.273 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.273 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.274 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.274 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.278 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=services,OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=1, query=(objectClass=organizationalRole), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.281 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.282 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.283 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.284 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.289 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectClass=Person)), attrs=[\'mail\', \'userPassword\', \'userAccountControl\', \'sAMAccountName\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.291 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.292 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.292 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.293 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.297 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectclass=Person)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.300 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.300 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.302 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.303 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:35.307 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=ou=UserGroups,dc=test,dc=local, scope=2, query=(&(&(objectClass=groupOfNames)(member=CN=nova,OU=services,OU=Projects,OU=iaas,OU=Other,DC=test,DC=local))(objectClass=groupOfNames)), attrs=[\'description\', \'ou\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:35.310 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:35.336 1706 DEBUG keystone.openstack.common.db.sqlalchemy.session [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER _mysql_check_effective_sql_mode /usr/lib/python2.6/site-packages/keystone/openstack/common/db/sqlalchemy/session.py:562\n2014-06-18 10:56:35.384 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491\n2014-06-18 10:56:35.385 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False\ntls_cacertfile=None\ntls_cacertdir=None\ntls_req_cert=2\ntls_avail=1\n__init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501\n2014-06-18 10:56:35.386 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561\n2014-06-18 10:56:36.391 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Roles,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=services)(objectClass=organizationalRole)), attrs=[\'cn\'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592\n2014-06-18 10:56:36.393 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565\n2014-06-18 10:56:36.471 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] \"POST /v2.0/tokens HTTP/1.1\" 200 8938 1.447416\n2014-06-18 10:56:36.520 1706 DEBUG keystone.middleware.core [-] RBAC: auth_context: {\'project_id\': u\'services\', \'user_id\': u\'nova\', \'roles\': [u\'services\']} process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:281\n2014-06-18 10:56:36.523 1706 DEBUG keystone.common.wsgi [-] arg_dict: {\'token_id\': u\'4dd244aee826e0ea0f1a27e7a9d42885\'} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181\n2014-06-18 10:56:36.525 1706 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:validate_token(token_id=4dd244aee826e0ea0f1a27e7a9d42885) _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:54\n2014-06-18 10:56:36.526 1706 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:59\n2014-06-18 10:56:36.527 1706 DEBUG keystone.policy.backends.rules [-] enforce identity:validate_token: {\'project_id\': u\'services\', \'user_id\': u\'nova\', \'roles\': [u\'services\']} enforce /usr/lib/python2.6/site-packages/keystone/policy/backends/rules.py:101\n2014-06-18 10:56:36.536 1706 DEBUG keystone.openstack.common.policy [-] Rule identity:validate_token will be now enforced enforce /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:258\n2014-06-18 10:56:36.537 1706 DEBUG keystone.openstack.common.fileutils [-] Reloading cached file /etc/keystone/policy.json read_cached_file /usr/lib/python2.6/site-packages/keystone/openstack/common/fileutils.py:63\n2014-06-18 10:56:36.545 1706 DEBUG keystone.openstack.common.policy [-] Rules successfully reloaded load_rules /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:212\n2014-06-18 10:56:36.546 1706 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action, identity:validate_token.\n2014-06-18 10:56:36.548 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] \"GET /v2.0/tokens/4dd244aee826e0ea0f1a27e7a9d42885 HTTP/1.1\" 403 277 0.037631\n2014-06-18 10:56:36.560 1706 DEBUG keystone.middleware.core [-] RBAC: auth_context: {\'project_id\': u\'services\', \'user_id\': u\'nova\', \'roles\': [u\'services\']} process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:281\n2014-06-18 10:56:36.563 1706 DEBUG keystone.common.wsgi [-] arg_dict: {\'token_id\': u\'4dd244aee826e0ea0f1a27e7a9d42885\'} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181\n2014-06-18 10:56:36.563 1706 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:validate_token(token_id=4dd244aee826e0ea0f1a27e7a9d42885) _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:54\n2014-06-18 10:56:36.564 1706 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:59\n2014-06-18 10:56:36.564 1706 DEBUG keystone.policy.backends.rules [-] enforce identity:validate_token: {\'project_id\': u\'services\', \'user_id\': u\'nova\', \'roles\': [u\'services\']} enforce /usr/lib/python2.6/site-packages/keystone/policy/backends/rules.py:101\n2014-06-18 10:56:36.565 1706 DEBUG keystone.openstack.common.policy [-] Rule identity:validate_token will be now enforced enforce /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:258\n2014-06-18 10:56:36.565 1706 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action, identity:validate_token.\n2014-06-18 10:56:36.566 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] \"GET /v2.0/tokens/4dd244aee826e0ea0f1a27e7a9d42885 HTTP/1.1\" 403 277 0.014182\n\nThus, not letting me in on the WebUI.\n\nMy keystone.conf ldap configuration is :\n\ndriver = keystone.identity.backends.ldap.Identity\n\n[ldap]\nquery_scope = sub\nurl = ldap://1.x.x.x\nuser = CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local\npassword = XXXXX\nsuffix = dc=test,dc=local\nuse_dumb_member = True\ndumb_member = CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local\n\nuser_tree_dn = OU=iaas,OU=Other,DC=test,DC=local\n#user_objectclass = organizationalPerson\nuser_objectclass = Person\nuser_id_attribute = cn\nuser_name_attribute = sAMAccountName\nuser_mail_attribute = mail\nuser_enabled_attribute = userAccountControl\nuser_enabled_mask = 2\nuser_enabled_default = 512\nuser_attribute_ignore = password,tenant_id,tenants\nuser_allow_create = True\nuser_allow_update = True\nuser_allow_delete = True\n\ntenant_tree_dn = OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local\ntenant_objectclass = organizationalUnit\ntenant_id_attribute = ou\ntenant_member_attribute = member\ntenant_name_attribute = ou\ntenant_desc_attribute = description\ntenant_enabled_attribute = extensionName\ntenant_attribute_ignore = description,businessCategory,extensionName\ntenant_allow_create = True\ntenant_allow_update = True\ntenant_allow_delete = True\n\nrole_tree_dn = OU=Roles,OU=iaas,OU=Other,DC=test,DC=local\n#role_tree_dn = CN=admin,OU=Services,OU=Roles,OU=iaas,OU=Other,DC=test,DC=local\nrole_objectclass = organizationalRole\nrole_id_attribute = cn\nrole_name_attribute = cn\nrole_member_attribute = roleOccupant\nrole_allow_create = True\nrole_allow_update = True\nrole_allow_delete = True\n\n\nAny pointers ?\n\n\nTarkan\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140618/f08665b6/attachment.html>\n\n',NULL,NULL),('<1403106374.3371.3.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 16:46:14',3600,'2014-06-18 15:46:14',NULL,'[openstack-dev] [glance] Unifying configuration file','On Wed, 2014-06-18 at 09:29 -0400, Doug Hellmann wrote:\n> On Wed, Jun 18, 2014 at 1:58 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > Hey\n> >\n> > On Tue, 2014-06-17 at 17:43 +0200, Julien Danjou wrote:\n> >> On Tue, Jun 17 2014, Arnaud Legendre wrote:\n> >> > @Julien: I would be interested to understand the value that you see of\n> >> > having only one config file? At this point, I don\'t see why managing one\n> >> > file is more complicated than managing several files especially when they\n> >> > are organized by categories. Also, scrolling through the registry settings\n> >> > every time I want to modify an api setting seem to add some overhead.\n> >>\n> >> Because there\'s no way to automatically generate several configuration\n> >> files with each its own set of options using oslo.config.\n> >\n> > I think that\'s a failing of oslo.config, though. Glance\'s layout of\n> > config files is useful and intuitive.\n> \n> The config generator lets you specify the modules, libraries, and\n> files to be used to generate a config file. It even has a way to\n> specify which files to ignore. So I think we have everything we need\n> in the config generator, but we need to run it more than once, with\n> different inputs, to generate multiple files.\n\nYep, except the magic way we troll through the code, loading modules,\nintrospecting what config options were registered, etc. will likely make\nthis a frustrating experience to get right.\n\nI took a little time to hack up a much more simple and explicit approach\nto config file generation and posted a draft here:\n\n  https://review.openstack.org/100946\n\nThe docstring at the top of the file explains the approach:\n\n  https://review.openstack.org/#/c/100946/1/oslo/config/generator.py\n\nThanks,\nMark.\n\n\n\n','<CADb+p3ReddPfR1D5DfU+fJRJ1x-M9PC2_23BM4GPW=52F3fWnw@mail.gmail.com>',NULL),('<1403126773-sup-8574@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-18 14:30:33',-25200,'2014-06-18 21:30:33',NULL,'[Openstack-operators] minimum scale openstack','Excerpts from Alex Leonhardt\'s message of 2014-06-18 13:51:41 -0700:\n> hi guys,\n> \n> am looking for some resource which parts of the system are required to be\n> HA - I naturally would do  :\n> \n> - DB\n> - Rabbit\n> - Controller node/s\n> \n> we dont use glance and swift too much and wont really as I\'d use it as a\n> private / internal cloud - what other services would you consider needing\n> HA and if so, is it possible to run Active/Active with the DB and Rabbit at\n> least ?\n> \n\nActive/Active DB would need to be done using a sync replication system\nlike MySQL cluster or Galera. These both recommend more than 2 nodes.\nAlso there are likely issues with the way OpenStack handles conflicting\ncommits to the database, so Active/Active may not even be possible\nwithout a lot of testing.\n\nRabbitMQ can be run in Active/Active w/ mirrored queues.\n\nBoth of the above would require some kind of STONITH mechanism to be\nsure that split-brain doesn\'t corrupt your data.\n\nAll of the OpenStack controller services should be O-K except two that\nI know of:\n\n* Ceilometer\'s collector must be Active/Passive\n* Neutron L3 agent needs to be Active/Passive unless patches have landed\n  to change that\n\n\n','<CACSH3Mvb85VQZPRi5dB8xWu4aY6=9x1fmjFb97mFAWgiwc72ow@mail.gmail.com>',NULL),('<1403136778-sup-2898@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-18 17:19:09',-25200,'2014-06-19 00:19:09',NULL,'[openstack-dev] [nova] A modest proposal to reduce reviewer load','Excerpts from Duncan Thomas\'s message of 2014-06-17 03:56:10 -0700:\n> A far more effective way to reduce the load of trivial review issues\n> on core reviewers is for none-core reviewers to get in there first,\n> spot the problems and add a -1 - the trivial issues are then hopefully\n> fixed up before a core reviewer even looks at the patch.\n> \n> The fundamental problem with review is that there are more people\n> submitting than doing regular reviews. If you want the review queue to\n> shrink, do five reviews for every one you submit. A -1 from a\n> none-core (followed by a +1 when all the issues are fixed) is far,\n> far, far more useful in general than a +1 on a new patch.\n> \n\nPerhaps we should incentivize having a good \"reviews to patches\" ratio\nsomehow. There are probably quite a few people who are not ever going to\nbe core reviewers, but who don\'t mind doing a few reviews per day.\n\nI can think of a few ways, but one way is to make that a real statistic\n(brace yourselves for the warnings of \"gaming the system\") and then give\nthe top 10 non-core reviews to patches ratios a shout out each release.\n\n\n','<CAOyZ2aGLEE54TCVSk+mcu1bH845LaHB2tiCZ=tfWW3kAMqo2Fw@mail.gmail.com>',NULL),('<1403163145.3371.38.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 08:32:25',3600,'2014-06-19 07:32:25',NULL,'[openstack-dev] [nova] A modest proposal to reduce reviewer load','Hi Armando,\n\nOn Tue, 2014-06-17 at 14:51 +0200, Armando M. wrote:\n> I wonder what the turnaround of trivial patches actually is, I bet you\n> it\'s very very small, and as Daniel said, the human burden is rather\n> minimal (I would be more concerned about slowing them down in the\n> gate, but I digress).\n\n> \n> I think that introducing a two-tier level for patch approval can only\n> mitigate the problem, but I wonder if we\'d need to go a lot further,\n> and rather figure out a way to borrow concepts from queueing theory so\n> that they can be applied in the context of Gerrit. For instance\n> Little\'s law [1] says:\n> \n> \"The long-term average number of customers (in this context reviews)\n> in a stable system L is equal to the long-term average effective\n> arrival rate, ?, multiplied by the average time a customer spends in\n> the system, W; or expressed algebraically: L = ?W.\"\n> \n> L can be used to determine the number of core reviewers that a project\n> will need at any given time, in order to meet a certain arrival rate\n> and average time spent in the queue. If the number of core reviewers\n> is a lot less than L then that core team is understaffed and will need\n> to increase.\n> \n> If we figured out how to model and measure Gerrit as a queuing system,\n> then we could improve its performance a lot more effectively; for\n> instance, this idea of privileging trivial patches over longer patches\n> has roots in a popular scheduling policy [3] for  M/G/1 queues, but\n> that does not really help aging of \'longer service time\' patches and\n> does not have a preemption mechanism built-in to avoid starvation. \n> \n> Just a crazy opinion...\n> Armando\n> \n> [1] - http://en.wikipedia.org/wiki/Little\'s_law\n> [2] - http://en.wikipedia.org/wiki/Shortest_job_first\n> [3] - http://en.wikipedia.org/wiki/M/G/1_queue\n\nThis isn\'t crazy at all. We do have a problem that surely could be\nstudied and solved/improved by applying queueing theory or lessons from\nfields like lean manufacturing. Right now, we\'re simply applying our\nintuition and the little I\'ve read about these sorts of problems is that\nyour intuition can easily take you down the wrong path.\n\nThere\'s a bunch of things that occur just glancing through those\narticles:\n\n  - Do we have an unstable system? Would it be useful to have arrival \n    and exit rate metrics to help highlight this? Over what time period \n    would those rates need to be averaged to be useful? Daily, weekly, \n    monthly, an entire release cycle?\n\n  - What are we trying to optimize for? The length of time in the \n    queue? The number of patches waiting in the queue? The response \n    time to a new patch revision?\n\n  - We have a single queue, with a bunch of service nodes with a wide \n    variance between their service rates, very little in the way of\n    scheduling policy, a huge rate of service nodes sending jobs back \n    for rework, a cost associated with maintaining a job while it sits \n    in the queue, the tendency for some jobs to disrupt many other jobs \n    with merge conflicts ... not simple.\n\n  - Is there any sort of natural limit in our queue size that makes the \n    system stable - e.g. do people naturally just stop submitting\n    patches at some point?\n\nMy intuition on all of this lately is that we need some way to model and\nexperiment with this queue, and I think we could make some interesting\nprogress if we could turn it into a queueing network rather than a\nsingle, extremely complex queue.\n\nSay we had a front-end for gerrit which tracked which queue a patch is\nin, we could experiment with things like:\n\n  - a triage queue, with non-cores signed up as triagers looking for \n    obvious mistakes and choosing the next queue for a patch to enter \n    into\n\n  - queues having a small number of cores signed up as owners - e.g. \n    high priority bugfix, API, scheduler, object conversion, libvirt\n    driver, vmware driver, etc.\n\n  - we\'d allow for a large number of queues so that cores could aim for \n    an \"inbox zero\" approach on individual queues, something that would \n    probably help keep cores motivated.\n\n  - we could apply different scheduling policies to each of the \n    different queues - i.e. explicit guidance for cores about which \n    patches they should pick off the queue next.\n\n  - we could track metrics on individual queues as well as the whole \n    network, identifying bottlenecks and properly recognizing which \n    reviewers are doing a small number of difficult reviews versus \n    those doing a high number of trivial reviews.\n\n  - we could require some queues to feed into a final approval queue \n    where some people are responsible for giving an approved patch a \n    final sanity check - i.e. there would be a class of reviewer with \n    good instincts who quickly churn through already-reviewed patches \n    looking for the kind of mistakes people tend to mistake when \n    they\'re down in the weeds.\n\n  - explicit queues for large, cross-cutting changes like coding style \n    changes. Perhaps we could stop servicing these queues at certain\n    points in the cycles, or reduce the rate at which they are \n    serviced.\n\n  - we could include specs and client patches in the same network so \n    that they prioritized in the same way.\n\nLots of ideas, none of it is trivial ... but perhaps it\'ll spark\nsomeone\'s interest :)\n\nMark.\n\n\n\n','<CAK+RQeaKh+9V5i0T6bQxniQeTavDHNAwatZD+xga2FX09GgZ2g@mail.gmail.com>',NULL),('<1403180164.3371.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 13:16:04',3600,'2014-06-19 12:16:04',NULL,'[openstack-dev] [oslo] Paris mid-cycle sprint','Hey\n\nI had been thinking of going to the Paris sprint:\n\n  https://wiki.openstack.org/wiki/Sprints/ParisJuno2014\n\nBut it only just occurred to me that we could have enough Oslo\ncontributors in Europe to make it worthwhile for us to use the\nopportunity to get some Oslo stuff done together.\n\nFor example, Victor (Stinner), Mehdi, Flavio, Victor (Sergeyev), Roman,\nor others ...  perhaps some or all of you would be up for it? Julien\nwill be there too, but will want to focus on Ceilometer I assume.\n\nI\'ll add myself to the wiki ... feel free to do so too.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1403180573.3371.78.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 13:22:53',3600,'2014-06-19 12:22:53',NULL,'[openstack-dev] [nova] A modest proposal to reduce reviewer load','On Thu, 2014-06-19 at 09:34 +0100, Matthew Booth wrote:\n> On 19/06/14 08:32, Mark McLoughlin wrote:\n> > Hi Armando,\n> > \n> > On Tue, 2014-06-17 at 14:51 +0200, Armando M. wrote:\n> >> I wonder what the turnaround of trivial patches actually is, I bet you\n> >> it\'s very very small, and as Daniel said, the human burden is rather\n> >> minimal (I would be more concerned about slowing them down in the\n> >> gate, but I digress).\n> > \n> >>\n> >> I think that introducing a two-tier level for patch approval can only\n> >> mitigate the problem, but I wonder if we\'d need to go a lot further,\n> >> and rather figure out a way to borrow concepts from queueing theory so\n> >> that they can be applied in the context of Gerrit. For instance\n> >> Little\'s law [1] says:\n> >>\n> >> \"The long-term average number of customers (in this context reviews)\n> >> in a stable system L is equal to the long-term average effective\n> >> arrival rate, ?, multiplied by the average time a customer spends in\n> >> the system, W; or expressed algebraically: L = ?W.\"\n> >>\n> >> L can be used to determine the number of core reviewers that a project\n> >> will need at any given time, in order to meet a certain arrival rate\n> >> and average time spent in the queue. If the number of core reviewers\n> >> is a lot less than L then that core team is understaffed and will need\n> >> to increase.\n> >>\n> >> If we figured out how to model and measure Gerrit as a queuing system,\n> >> then we could improve its performance a lot more effectively; for\n> >> instance, this idea of privileging trivial patches over longer patches\n> >> has roots in a popular scheduling policy [3] for  M/G/1 queues, but\n> >> that does not really help aging of \'longer service time\' patches and\n> >> does not have a preemption mechanism built-in to avoid starvation. \n> >>\n> >> Just a crazy opinion...\n> >> Armando\n> >>\n> >> [1] - http://en.wikipedia.org/wiki/Little\'s_law\n> >> [2] - http://en.wikipedia.org/wiki/Shortest_job_first\n> >> [3] - http://en.wikipedia.org/wiki/M/G/1_queue\n> > \n> > This isn\'t crazy at all. We do have a problem that surely could be\n> > studied and solved/improved by applying queueing theory or lessons from\n> > fields like lean manufacturing. Right now, we\'re simply applying our\n> > intuition and the little I\'ve read about these sorts of problems is that\n> > your intuition can easily take you down the wrong path.\n> > \n> > There\'s a bunch of things that occur just glancing through those\n> > articles:\n> > \n> >   - Do we have an unstable system? Would it be useful to have arrival \n> >     and exit rate metrics to help highlight this? Over what time period \n> >     would those rates need to be averaged to be useful? Daily, weekly, \n> >     monthly, an entire release cycle?\n> > \n> >   - What are we trying to optimize for? The length of time in the \n> >     queue? The number of patches waiting in the queue? The response \n> >     time to a new patch revision?\n> > \n> >   - We have a single queue, with a bunch of service nodes with a wide \n> >     variance between their service rates, very little in the way of\n> >     scheduling policy, a huge rate of service nodes sending jobs back \n> >     for rework, a cost associated with maintaining a job while it sits \n> >     in the queue, the tendency for some jobs to disrupt many other jobs \n> >     with merge conflicts ... not simple.\n> > \n> >   - Is there any sort of natural limit in our queue size that makes the \n> >     system stable - e.g. do people naturally just stop submitting\n> >     patches at some point?\n> > \n> > My intuition on all of this lately is that we need some way to model and\n> > experiment with this queue, and I think we could make some interesting\n> > progress if we could turn it into a queueing network rather than a\n> > single, extremely complex queue.\n> > \n> > Say we had a front-end for gerrit which tracked which queue a patch is\n> > in, we could experiment with things like:\n> > \n> >   - a triage queue, with non-cores signed up as triagers looking for \n> >     obvious mistakes and choosing the next queue for a patch to enter \n> >     into\n> > \n> >   - queues having a small number of cores signed up as owners - e.g. \n> >     high priority bugfix, API, scheduler, object conversion, libvirt\n> >     driver, vmware driver, etc.\n> > \n> >   - we\'d allow for a large number of queues so that cores could aim for \n> >     an \"inbox zero\" approach on individual queues, something that would \n> >     probably help keep cores motivated.\n> > \n> >   - we could apply different scheduling policies to each of the \n> >     different queues - i.e. explicit guidance for cores about which \n> >     patches they should pick off the queue next.\n> > \n> >   - we could track metrics on individual queues as well as the whole \n> >     network, identifying bottlenecks and properly recognizing which \n> >     reviewers are doing a small number of difficult reviews versus \n> >     those doing a high number of trivial reviews.\n> > \n> >   - we could require some queues to feed into a final approval queue \n> >     where some people are responsible for giving an approved patch a \n> >     final sanity check - i.e. there would be a class of reviewer with \n> >     good instincts who quickly churn through already-reviewed patches \n> >     looking for the kind of mistakes people tend to mistake when \n> >     they\'re down in the weeds.\n> > \n> >   - explicit queues for large, cross-cutting changes like coding style \n> >     changes. Perhaps we could stop servicing these queues at certain\n> >     points in the cycles, or reduce the rate at which they are \n> >     serviced.\n> > \n> >   - we could include specs and client patches in the same network so \n> >     that they prioritized in the same way.\n> > \n> > Lots of ideas, none of it is trivial ... but perhaps it\'ll spark\n> > someone\'s interest :)\n> \n> This is all good stuff, but by the sounds of it experimenting in gerrit\n> isn\'t likely to be simple.\n\nRight, which is why I said \"a front-end for gerrit\" ... this would sit\nin front of gerrit, at least to begin with.\n\n> Remember, though, that the relevant metric is code quality, not review\n> rate.\n\nNot sure what conclusion you\'re driving towards there - obviously that\'s\ntrue, but ... ignore review rate? measure code quality how?\n\nMark.\n\n\n\n','<53A2A097.3090309@redhat.com>',NULL),('<1403185146.3371.80.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 14:39:06',3600,'2014-06-19 13:39:06',NULL,'[openstack-dev] [devstack] [zmq] [oslo.messaging] Running\n devstack with zeromq','On Thu, 2014-06-19 at 14:29 +0200, Mehdi Abaakouk wrote:\n> Hi,\n> \n> Le 2014-06-19 00:30, Ben Nemec a ?crit :\n> > On 06/18/2014 05:45 AM, Elena Ezhova wrote:\n> > \n> >> So I wonder whether it is something the community is interested in \n> >> and, if\n> >> yes, are there any recommendations concerning possible implementation?\n> > \n> > I can\'t speak to the specific implementation, but if we\'re going to \n> > keep\n> > the zmq driver in oslo.messaging then IMHO it should be usable with\n> > devstack, so +1 to making that work.\n> \n> Currently the zmq driver have a really bad test coverage, the driver is \n> \'I think\' broken since a while.\n> \n> Bugs like [1] or [2] let me think that nobody can use it currently.\n> \n> [1] https://bugs.launchpad.net/oslo.messaging/+bug/1301723\n> [2] https://bugs.launchpad.net/oslo.messaging/+bug/1330460\n> \n> Also, an oslo.messaging rule is \"a driver must not force to use a \n> eventloop library\",\n> but this one heavily use eventlet. So only the eventlet executor can \n> works with it, not the\n> blocking one or any future executor.\n> \n> I guess if someone is interested in, the first step is to fix the zmq \n> driver, remove eventlet stuffs and write unit tests for it,\n> before trying integration, and raise bugs that should be catch by \n> unit/functionnal testing.\n> \n> If nobody is interested in zmq, perhaps we should just \n> drop/deprecated/mark_as_broken it.\n\nYes, I agree with all of that. Unless the situation improves rapidly, I\nthink we should mark it as deprecated in Juno and plan to remove it in\nK. That might seem like an overly rapid deprecation cycle, but it is\ncurrently broken and unusable in Icehouse ... so no-one can be using it\nin Icehouse.\n\nMark.\n\n\n\n','<2ad460cf4e4ef56f950e5702d37111bf@sileht.net>',NULL),('<1403196452.3723.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 16:47:33',0,'2014-06-19 16:47:33',NULL,'[openstack-dev]  [Blazar] June 20 Weekly meeting','Tomorrow is a holiday in Argentina, so I won\'t be able to attend to the\nmeeting.\n\nPablo.\n\n',NULL,NULL),('<1403202804-sup-9361@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 11:37:34',-25200,'2014-06-19 18:37:34',NULL,'[openstack-dev] [OSSG] Best tool for simple security gate checks','A large majority of the failures I\'ve seen OSSG report have been privilege\nescalation in each service.. Trusts not scoping down properly, quotas\nnot being applied, or cross-project/tenant boundaries not being honored.\n\nI don\'t think we\'ve had many (if any) SQL or shell injection attacks or\nbuffer overflows or anything like that. We\'re all pretty well trained to\nspot these issues and python makes you have to try pretty hard to\nimplement some of them.\n\nI say this to suggest that perhaps the appropriate thing to put in the\ngate is better coverage of cross-tenant scenarios and policy enforcement.\n\nExcerpts from Travis McPeak\'s message of 2014-06-19 11:21:24 -0700:\n> Hi all,\n> \n> In the OpenStack Security Group (OSSG) we?ve been kicking around the idea\n> of getting some simple non-blocking security-related gate tests going.\n> These tests would be designed to be simple and automated checks for\n> low-hanging fruit such as the use of ?Shell=True?.  The main goal is to\n> have these be as noiseless as possible (a low rate of false positives).\n> The hope is that if these are useful and unobtrusive enough, when they\n> actually do fail, people will take note.\n> \n> We will start off small, with maybe one simple gate test, and expand later\n> if it proves to be useful.  We plan to test heavily internally, and then\n> start requesting integration into projects later.\n> \n> My question is: what is the best tool for the job?  I have heard Pylint\n> and Hacking mentioned.  Are there any others?\n> \n> Thanks,\n>   -Travis\n> \n> \n> \n> \n> On 6/19/14, 5:00 AM, \"openstack-dev-request at lists.openstack.org\"\n> <openstack-dev-request at lists.openstack.org> wrote:\n> \n> >Send OpenStack-dev mailing list submissions to\n> >       openstack-dev at lists.openstack.org\n> >\n> >To subscribe or unsubscribe via the World Wide Web, visit\n> >       http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >or, via email, send a message with subject or body \'help\' to\n> >       openstack-dev-request at lists.openstack.org\n> >\n> >You can reach the person managing the list at\n> >       openstack-dev-owner at lists.openstack.org\n> >\n> >When replying, please edit your Subject line so it is more specific\n> >than \"Re: Contents of OpenStack-dev digest...\"\n> >\n> >\n> >Today\'s Topics:\n> >\n> >   1. [nova][libvirt] Block migrations and Cinder volumes\n> >      (Rafi Khardalian)\n> >   2. Re: [neutron]Performance of security group (henry hly)\n> >   3. Re: [Neutron][ML2] Modular L2 agent architecture (henry hly)\n> >   4. Re: [heat] agenda for OpenStack Heat meeting 2014-06-18 20:00\n> >      UTC - corrections to meeting minutes (Mike Spreitzer)\n> >   5. Re: [Neutron][LBaaS] TLS support RST document    on      Gerrit\n> >      (Samuel Bercovici)\n> >   6. [DevStack] fails in lxc running ubuntu trusty amd64\n> >      (Mike Spreitzer)\n> >   7. Re: [neutron]Performance of security group (?douard Thuleau)\n> >   8. Re: [nova] A modest proposal to reduce reviewer load\n> >      (Mark McLoughlin)\n> >   9. Re: [DevStack] fails in lxc running ubuntu trusty        amd64\n> >      (J?r?me Gallard)\n> >  10. Re: [Horizon] Quick Survey: Horizon Mid-Cycle Meetup\n> >      (Matthias Runge)\n> >  11. Re: [nova] A modest proposal to reduce reviewer load\n> >      (Matthew Booth)\n> >  12. Re: [nova][libvirt] Block migrations and Cinder volumes\n> >      (Daniel P. Berrange)\n> >  13. Re: [TripleO] Backwards compatibility policy for our projects\n> >      (Giulio Fidente)\n> >  14. Re: [nova][libvirt] Block migrations and Cinder  volumes\n> >      (Ronen Kat)\n> >  15. Re: [Nova] Nominating Ken\'ichi Ohmichi for nova-core\n> >      (AMIT PRAKASH PANDEY)\n> >  16. [nova] Nova API meeting (Kenichi Oomichi)\n> >  17. Re: [Neutron][ML2] Modular L2 agent architecture (Zang MingJie)\n> >  18. Re: [qa] Clarification of policy for qa-specs around adding\n> >      new tests (Kenichi Oomichi)\n> >  19 Re: [DevStack] fails in lxc running ubuntu trusty amd64\n> >      (Sean Dague)\n> >  20. Re: [FUEL] Zabbix in MOS meeting notes (Swann Croiset)\n> >  21. Re: [Neutron][L3] Team Meeting Thursday at 1500 UTC\n> >      (Paul Michali (pcm))\n> >  22. Re: [TripleO] Backwards compatibility policy for our projects\n> >      (Duncan Thomas)\n> >  23. Re: [FUEL] Zabbix in MOS meeting notes (Alexander Kislitsy)\n> >  24. Help in writing new neutron plugin (shiva m)\n> >  25. Re: [nova][libvirt] Block migrations and Cinder  volumes\n> >      (Duncan Thomas)\n> >  26. [oslo] oslo.utils and oslo.local Davanum Srinivas)\n> >\n> >\n> >---------------------------------------------------------------------\n> >\n> >Message: 1\n> >Date: Wed, 18 Jun 2014 23:09:33 -0700\n> >From: Rafi Khardalia <rafi at metacloud.com>\n> >To: OpenStack Development Mailing List\n> >       <openstack-dev at lists.opestack.org>\n> >Subject: [openstack-dev] [nova][libvirt] Block migrations and Cinde\n> >       volumes\n> >Message-ID:\n> >       <CAH9GqTzjxh1Zktj-0HDHgcWhKoOOmGQsYnrx_gdLDpeTRmAng at mail.gmail.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >I am concerned about hw block migration functions when Cinder volumes are\n> >attached to an instance being migrted.  We noticed some unexpected\n> >behavior recently, whereby attached generic NFSbased volumes would become\n> >entirely unsparse over the course of a migration.  After spending some\n> >time\n> >reviewing the code paths in Nova, I\'m more concerned that this was\n> >actually\n> >a minor symtom of a much more significant issue.\n> >\n> >For those unfamiliar, NFS-based volumes are siply RAW files residing on\n> >an\n> >NFS mount.  From Libvirt\'s perspective, these volume look no different\n> >than root or ephemeral disks.  We are currently not filtering out volums\n> >whatsoever when making the request into Libvirt to perform the migration.\n> > Libvir simply receives an additional flag (VIR_MIGRATE_NON_SHARED_INC)\n> >when a block migration is requested, which applied to the entire migration\n> >process, not differentiated on a per-disk basis.  Numerous guards within\n> >Nova to prevent a block based migration from being allowed if the instance\n> >disks exist on the destination; yet volumes remain attached and within the\n> >defined XML during a block migration.\n> >\n> >Unless Libvirt has a lot more logic around this thanI am lead to believe,\n> >this seems like a recipe for corruption.  It seems as though thi would\n> >also impact any type of volume attached to an instance (iSCSI, RBD, etc.)\n> >NFS just happens to be what we were testing.  If I am wrong and someone\n> >can\n> >correct my understanding, I would really appreciate it.  Otherwise, I\'m\n> >surprised we haven\'t had more reports of isues when block migrations are\n> >used in conjunction with any attached volumes.\n> >\n> >I hav ideas on how we can address the issue if we can reach some\n> >consensus\n> >that theissue is valid, but we\'ll discuss those when if/when we get to\n> >that point.\n> >\n> >Regards,\n> >Rafi\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140618/4\n> >f4b7709/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 2\n> >Date: Thu, 19 Jun 2014 14:25:34 +0800\n> >From: henry hly <henry4hly at gmail.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [neutron]Performance of security group\n> >Message-ID:\n> >       <CAFHmYs_UGkTj2YifXs_pe85XRa3JAf9GraE0cdw-cVY5_M3uBg at mail.gmail.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >we have done some tests, but have different result: the performance is\n> >nearly the same for empty and 5k rules in iptable, but huge gap between\n> >enable/disable iptable hook on linux bridge\n> >\n> >\n> >On Thu, Jun 19, 2014 at 11:21 AM, shihanzhan <ayshihanzhang at 126.com>\n> >wrote:\n> >\n> >> Now I have not get accurate test data, but I  can confirm the following\n> >> points?\n> >> 1. In compute node, the iptable\'s chain of a VM is liner, iptable filter\n> >> it one by one, if a VM in default security group and this default\n> >>security\n> >> group have many members, but ipset chain is set, the time ipset filter\n> >>one\n> >> and many member is not much difference.\n> >> 2. when the iptable rule is very large, the probability of  failure\n> >>that  iptable-save\n> >> save the iptable rule  is very large.\n> >>\n> >>\n> >>\n> >>\n> >>\n> >> At 2014-06-19 10:55:56, \"Kevin Benton\" <blak111 at gmail.com> wrote:\n> >>\n> >> This sounds like a good idea to handle some of the performance issues\n> >> until the ovs firewall can be implemented down the the line.\n> >> Do you have any performance comparisons?\n> >> On Jun 18, 2014 7:46 PM, \"shihanzhang\" <ayshihanzhang at 126.com> wrote:\n> >>\n> >>> Hello all,\n> >>>\n> >>> Now in neutron, it use iptable implementing security group, but the\n> >>> performance of this  implementation is very poor, there is a bug:\n> >>> https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this\n> >>>problem.\n> >>> In his test, with default security groups(which has remote security\n> >>> group), beyond 250-300 VMs, there were around 6k Iptable rules on evry\n> >>> compute node, although his patch can reduce the prcessing time, but it\n> >>> don\'t solve this problem fundamentally. I have commit a BP to solve\n> >>>this\n> >>> problem:\n> >>> https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security\n> >>> <https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,>\n> >>> There are other people interested in this it?\n> >>>\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >-------------- next part --------------\n> >An HTML attachment as scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/0\n> >113cebf/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 3\n> >Date: Thu, 19 Jun 2014 14:44:47 +0800\n> >From: henry hly <henry4hly at gmail.com>\n> >To: \"OpenStack Develoment Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [Neutron][ML2] Modular L2 agent\n> >       architecture\n> >Message-ID:\n> >       <CAFHmYs8ekniMLOPLXznNn-S7EiJrvyuh3Va8fJqfe7+xK6cRPA at mail.gmail.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >OVS agent manipulate not only ovs flow table, but also linux stack, which\n> >is not so easily replaced by pure openflow controller today.\n> >fastpath-slowpath separation sounds good, but really a nightmare for high\n> >concurrent connection application if we set L4 flow into OVS (in our\n> >testing, vswitchd daemon always stop working in this case).\n> >\n> >Someday when OVS can do all the L2-L4 rules in the kernel without\n> >bothering\n> >userspace classifier, pure OF controller can replace agent based solution\n> >then. OVS hooking to netfilter conntrack may come this year, but not\n> >enough\n> >yet.\n> >\n> >\n> >On Wed, Jun 18, 2014 at 12:56 AM, ArmandoM. <armamig at gmail.com> wrote:\n> >\n> >> just a provocative thought: If we used the ovsdb connection instead, do\n> >>we\n> >> really need an L2 agent :P?\n> >>\n> >>\n> >> On 17 June 2014 18:38, Kyle Mestery <mestery at noironetworks.com> wrote:\n> >>\n> >>> Another area of improvement for the agent would be to move away from\n> >>> executing CLIs for port commands and instead use OVSDB. Terry Wilson\n> >>> and I talked about this, and re-writing ovs_lib to use an OVSDB\n> >>> connection instead of the CLI methods would b a huge improvement\n> >>> here. I\'m not sure if Terry was going to move forward with this, but\n> >>> I\'d be in favor of this for Juno if he or someone else wants to move\n> >>> in this direction.\n> >>>\n> >>> Thanks,\n> >>> Kyle\n> >>>\n> >>> On Tue, Jun 17, 2014 at 11:24 AM, Salvatore Orlando\n> >>><sorlando at nicira.com>\n> >>> wrote:\n> >>> > We\'ve started doing this in a slightly more reasonable way for\n> >>>icehouse.\n> >>> > What we\'ve done is:\n> >>> > - remove unnecessary notification from the server\n> >>> > - process all port-related events, either trigger via RPC or via\n> >>> monitor in\n> >>> > one place\n> >>> >\n> >>> > Obviously there is always a lot of room for improvement, and I agree\n> >>> > something along the lines of what Zang suggests would be more\n> >>> maintainable\n> >>> > and ensure faster event processing as well as making it easier to\n> >>>have\n> >>> some\n> >>> > form of reliability on event processing.\n> >>> >\n> >>> > I was considering doing something for the ovs-agent again in Juno,\n> >>>but\n> >>> since\n> >>> > we\'ve moving towards a unified agent, I think any new \"big\" ticket\n> >>> should\n> >>> > address this effort.\n> >>> >\n> >>> > Salvatore\n> >>> >\n> >>> >\n> >>> > On 17 June 2014 13:31, Zang MingJie <zealot0630 at gmail.com> wrote:\n> >>> >>\n> >>> >> Hi:\n> >>> >>\n> >>> >> Awesome! Currently we are suffering lots of bugs in ovs-agnt, also\n> >>> >> intent to rebuild a more stable flexible agent.\n> >>> >>\n> >>> >> Taking the experience of ovs-agent bugs, I think the concurrency\n> >>> >> problem is also a very important problem, the agent gets lots of\n> >>>event\n> >>> >> from different greenlets, th rpc, the ovs monitor or the main loop.\n> >>> >> I\'d suggest to serialize all evet to a queue, then process events\n> >>>in\n> >>> >> a dedicated thread. The thread check the events one by one orered,\n> >>> >> and resolve what has been changed, then apply the corresponding\n> >>> >> changes. If there is any error occurred in the thread, discard the\n> >>> >> current processing event, do a fresh start event, which reset\n> >>> >> everything, then apply the correct settings.\n> >>> >>\n> >>> >> The threading model is so important and may prevent tons of bugs in\n> >>> >> the future development, we should describe it clearly in the\n> >>> >> architecture\n> >>> >>\n> >>> >>\n> >>> >> On Wed, Jun 11, 2014 at 4:19 AM, Mohammad Banikazemi <mb at us.ibm.com>\n> >>> >> wrote:\n> >>> >> > Following the discussions in the ML2 subgroup weekly meetings, I\n> >>>have\n> >>> >> > added\n> >>> >> > more information on the etherpad [1] describing the proposed\n> >>> >> > architecture\n> >>> >> > for modular L2 agents. I have also posted some code fragments at\n> >>>[2]\n> >>> >> > sketching the implementation of the proposed architecture. Please\n> >>> have a\n> >>> >> > look when you get a chance and let us know if you have any\n> >>>comments.\n> >>> >> >\n> >>> >> > [1] https://etherpad.openstack.org/p/modular-l2-agent-outline\n> >>> >> > [2] https://review.openstack.org/#/c/99187/\n> >>> >> >\n> >>> >> >\n> >>> >> > _______________________________________________\n> >>> >> > OpenStack-dev mailing list\n> >>> >> > OpenStack-dev at lists.openstack.org\n> >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> >> >\n> >>> >>\n> >>> >> _______________________________________________\n> >>> >> OpenStack-dev mailing list\n> >>> >> OpenStack-dev at lists.openstack.org\n> >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> >\n> >>> >\n> >>> >\n> >>> > _______________________________________________\n> >>> > OpenStack-dev mailing list\n> >>> > OpenStack-dev at lists.openstack.org\n> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> >\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-de at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/opentack-dev\n> >>\n> >>\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/2\n> >696588d/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 4\n> >Date: Thu, 19 Jun 2014 02:55:39 -0400\n> >From: Mike Spreitzer <mspreitz at us.ibm.com>\n> >To: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [heat] agenda for OpenStack Heat meeting\n> >       2014-06-18 20:00 UTC - corrections to meeting minutes\n> >Message-ID:\n> >       <OF74E36329.3927CB5F-ON85257CFC.0025709E-85257CFC.00260DCC at us.ibm.com>\n> >Content-Type: text/plain; charset=\"us-ascii\"\n> >\n> >Mike Spreitzer/Watson/IBM at IBMUS wrote on 06/18/2014 05:00:57 PM:\n> >...\n> >>\n> >http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-06-18-20.00.ht\n> >ml\n> >\n> >\n> >I found two goofups so far.  One is that the following was not recorded\n> >in\n> >the official outline (#agreed only really works for chairs):\n> >\n> >20:10:12 <zaneb> #agreed heat-slow job will remain non-voting until\n> >current issues are fixed\n> >\n> >The other concerns the dates for the mid-cycle meet-up in August.  The\n> >agreement was on Monday--Wednesday, which are the 18th through the 20th.\n> >I\n> >incorrectly reorded that as\n> >\n> >20:35:47 <mspreitz> #agreed have the second meetup, Aug 19--21\n> >\n> >when in fact the correct statement is\n> >\n> >20:35:47 <mspreitz> #agreed have the second meetup, Aug 18--20\n> >\n> >Regards,\n> >Mike\n> >-------------- next part -------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.orgpipermail/openstack-dev/attachments/20140619/6\n> >ce90077/attachment-0001.htm>\n> >\n> >------------------------------\n> >\n> >Message: 5\n> >Date: Thu, 19 Jun 2014 07:03:00 +0000\n> >From: Samuel Bercovici <SamuelB at Radware.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <oenstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document\n> >       on      Gerrit\n> >Message-ID:\n> >       <F36E8145F2571242A675F56CF60964560F0BAB8B at ILMB1.corp.radware.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >Hi Stephen,\n> >\n> >The difference is whether the user get to specify hostnames or whether\n> >this get concluded from the certificate.\n> I agree, that it might be more friendly if we have an immutable hostname\n> >field that get cached in lbaas but being read from the certificate and\n> >not mnaged by the end user.\n> >\n> >-Sam.\n> >\n> >\n> >\n> >From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]\n> >Sent: Thursday, June 19, 2014 1:44 AM\n> >To: OpenStack Development Mailing List (not for usage questions)\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on\n> >Gerrit\n> >\n> >So... what I\'m hearing her is that we might want to support both a\n> >\'hostname\' and \'order\' attribute. Though exact behavior from vendor to\n> >vendor when there is name overlap is not likey to be consistent.\n> >\n> >Note that while we have seen that corner case, it is unsual... so I\'m\n> >not against having slightly different behaviorwhen there\'s name overlap\n> >from vendor to vendor.\n> >\n> >Stephen\n> >\n> >On Wed, Jun 18, 2014 at 2:15 PM, Samul Bercovici\n> ><SamuelB at radware.com<mailto:SamuelB at radware.com>> wrote:\n> >Hi Stephen,\n> \n> >Radware Alteon extract the hostname information and the alt\n> >subjectAltName frm the certificate information.\n> >It then do:\n> >\n> >1.      Find if there is exact match wit the name in the https handshake\n> >and the ones extracted from the certificate, if there are more than a\n> >single match, the st one in the order will be used\n> >\n> >2.      If no match was found than try to use the regexp hostname to\n> >match, if you have multiple matches, the 1st one will e used\n> >\n> >3.      If no match was found than try to use subjectAltName to match. If\n> >you have multiple matches, the 1st one will be used\n> >\n> >4.      If no match than use default certificate\n> >\n> >-Sam.\n> >\n> >\n> >\n> >\n> >From: Stephen Balukoff\n> >[mailto:sbaluoff at bluebox.net<mailto:sbalukoff at bluebox.net>]\n> >Sent: Thursday, June 19, 2014 12:03 AM\n> >\n> >To: OpenStack Development Mailing List (not fr usage questions)\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RT document on\n> >Gerrit\n> >\n> >Hi Evg,\n> >\n> >I do not think stunnel supports an \"ordered list\" without hostnames.\n> >Since we\'re talking about making the reference implementation use stunnel\n> >for TLS termination, then this seems like it\'s imortant to support its\n> >behavioral model.\n> >\n> >It is possible to extract hostnames fom the CN and x509v3 Subject\n> >Alternative Names in the certs, but, as has been discussed previously,\n> >these can overlap, an\'s not always reliable to rely on this data from\n> >the certs themselves. So, while I have nt having an ordered\n> >certificate list, stunnel won\'t use the order hetunnel will\n> >likely have unexpected behavior if hostnames are duplicated.\n> >\n> >Would  for Radware to simply order the (unique) hostnames\n> >alphabetically, and put any wildcard certificates at the end of the list?\n> >\n> >Also, while I\'m loathe to ask for details on a proprietary system: How\n> >does Radware do SNI *without* hostnames? Isn\'t that entirely the point of\n> >SNI? Client sends a hostname, and server responds with the certificate\n> >that applies to that hostname?\n> >\n> >Thanks,\n> >Stephen\n> >\n> >On Wed, Jun 18, 2014 at 8:00 AM, Evgeny Fedoruk\n> ><EvgenyF at radware.com<mailto:EvgenyF at radware.com>> wrote:\n> >Hi Stephen,\n> >Regarding your comment related to SNI list management and behavior in the\n> >RST document:\n> >\n> >I understand the need to explicitly specify specific certificates for\n> >specific hostnames.\n> >However we need to deliver lowest common denominator for this feature\n> >which every vendor is able to support\n> >In this case, specifying hostname for certificate will not be supported\n> >by Radware.\n> >The original proposal with ordered certificates list may be the lowest\n> >common denominator for all vendors and we should find out if this is the\n> >case.\n> >If not, managing a simple none-ordered list will probably be the lowest\n> >common denominator.\n> >\n> >With the proposed flavors framework considered, extra SNI management\n> >capabilities may be represented for providers\n> >but meanwhile we should agree on proposal that can be implemented by all\n> >vendors.\n> >What are your thought on this?\n> >\n> >Regarding the SNIPolicy, I agree and will change the document accordingly.\n> >\n> >Thanks,\n> >Evg\n> >\n> >\n> >\n> >\n> >\n> >-----Original Message-----\n> >From: Evgeny Fedoruk\n> >Sent: Sunday, June 15, 2014 1:55 PM\n> >To: OpenStack Development Mailing List (not for usage questions)\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on\n> >Gerrit\n> >\n> >Hi All,\n> >\n> >The document was updated and ready for next review round.\n> >Main things that were changed:\n> >1. Comments were addressed\n> >2. No back-end re-encryption supported\n> >3. Intermediate certificates chain supported\n> >        *Opened question: Should chain be stored in same TLS container of\n> >the certificate?\n> >\n> >Please review\n> >Regards,\n> >Evgeny\n> >\n> >\n> >-----Original Message-----\n> >From: Douglas Mendizabal\n> >[mailto:douglas.mendizabal at RACKSPACE.COM<mailto:douglas.mendizabal at RACKSPA\n> >CE.COM>]\n> >Sent: Wednesday, June 11, 2014 10:22 PM\n> >To: OpenStack Development Mailing List (not for usage questions)\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST document on\n> >Gerrit\n> >\n> >Hi Doug,\n> >\n> >\n> >Barbican does guarantee the integrity and availability of the secret,\n> >unless the owner of the secret deletes it from Barbican.  We?re not\n> >encouraging that you store a shadow-copy of the secret either.  This was\n> >proposed by the LBaaS team as a possible workaround for your use case.\n> >Our recommendation was that there are two options for dealing with\n> >Secrets being deleted from under you:\n> >\n> >If you want to control the lifecycle of the secret so that you can\n> >prevent the user from deleting the secret, then the secret should be\n> >owned by LBaaS, not by the user.  You can achieve this by asking the user\n> >to upload the secret via LBaaS api, and then use Barbican on the back end\n> >to store the secret under the LBaaS tenant.\n> >\n> >If you want the user to own and manage their secret in Barbican, then you\n> >have to deal with the situation where the user deletes a secret and it is\n> >no longer available to LBaaS.  This is a situation you would have to deal\n> >with even with a reference-counting and force-deleting Barbican, so I\n> >don?t think you really gain anything from all the complexity you?re\n> >proposing to add to Barbican.\n> >\n> >-Douglas M.\n> >\n> >\n> >\n> >On 6/11/14, 12:57 PM, \"Doug Wiegley\"\n> ><dougw at a10networks.com<mailto:dougw at a10networks.com>> wrote:\n> >\n> >>There are other fundamental things about secrets, like relying on their\n> >>presence, and not encouraging a proliferation of a dozen\n> >>mini-secret-stores everywhere to get around that fact, which makes it\n> >>less secret.  Have you considered a ?force? delete flag, required if\n> >>some service is using the secret, sort of ?rm? vs ?rm -f?, to avoid the\n> >>obvious foot-shooting use cases, but still allowing the user to nuke it\n> >>if necessary?\n> >>\n> >>Thanks,\n> >>Doug\n> >>\n> >>\n> >>On 6/11/14, 11:43 AM, \"Clark, Robert Graham\"\n> >><robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:\n> >>\n> >>>Users have to be able to delete their secrets from Barbican, it\'s a\n> >>>fundamental key-management requirement.\n> >>>\n> >>>> -----Original Message-----\n> >>>> From: Eichberger, German\n> >>>> Sent: 11 June 2014 17:43\n> >>>> To: OpenStack Development Mailing List (not for usage questions)\n> >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST\n> >>>> document on Gerrit\n> >>>>\n> >>>> Sorry, I am late to the party. Holding the shadow copy in the\n> >>>> backend\n> >>>is a\n> >>>> fine solution.\n> >>>>\n> >>>> Also, if containers are immutable can they be deleted at all? Can we\n> >>>make a\n> >>>> requirement that a user can\'t delete a container in Barbican?\n> >>>>\n> >>>> German\n> >>>>\n> >>>> -----Original Message-----\n> >>>> From: Eichberger, German\n> >>>> Sent: Wednesday, June 11, 2014 9:32 AM\n> >>>> To: OpenStack Development Mailing List (not for usage questions)\n> >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST\n> >>>> document on Gerrit\n> >>>>\n> >>>> Hi,\n> >>>>\n> >>>> I think the previous solution is easier for a user to understand.\n> >>>> The referenced container got tampered/deleted we throw an error -\n> >>>> but keep existing load balancers intact.\n> >>>>\n> >>>> With the shadow container we get additional complexity and the user\n> >>>might\n> >>>> be confused where the values are coming from.\n> >>>>\n> >>>> German\n> >>>>\n> >>>> -----Original Message-----\n> >>>> From: Carlos Garza\n> >>>>[mailto:carlos.garza at rackspace.com<mailto:carlos.garza at rackspace.com>]\n> >>>> Sent: Tuesday, June 10, 2014 12:18 PM\n> >>>> To: OpenStack Development Mailing List (not for usage questions)\n> >>>> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST\n> >>>> document on Gerrit\n> >>>>\n> >>>> See adams message re: Re: [openstack-dev] [Neutron][LBaaS] Barbican\n> >>>> Neutron LBaaS Integration Ideas.\n> >>>> He\'s advocating keeping a shadow copy of the private key that is\n> >>>> owned\n> >>>by\n> >>>> the LBaaS service so that incase a key is tampered with during an LB\n> >>>update\n> >>>> migration etc we can still check with the shadow backup and compare\n> >>>> it\n> >>>to\n> >>>> the user owned TLS container in case its not their it can be used.\n> >>>>\n> >>>> On Jun 10, 2014, at 12:47 PM, Samuel Bercovici\n> >>>><SamuelB at Radware.com<mailto:SamuelB at Radware.com>>\n> >>>>  wrote:\n> >>>>\n> >>>> > To elaborate on the case where containers get deleted while LBaaS\n> >>>still\n> >>>> references it.\n> >>>> > We think that the following approach will do:\n> >>>> > *         The end user can delete a container and leave a \"dangling\"\n> >>>> reference in LBaaS.\n> >>>> > *         It would be nice to allow adding meta data on the\n> >>>container so that\n> >>>> the user will be aware which listeners use this container. This is\n> >>>optional. It\n> >>>> can also be optional for LBaaS to implement adding the listeners ID\n> >>>> automatically into this metadata just for information.\n> >>>> > *         In LBaaS, if an update happens which requires to pull the\n> >>>container\n> >>>> from Barbican and if the ID references a non-existing container, the\n> >>>update\n> >>>> will fail and will indicate that the reference certificate does not\n> >>>exists any\n> >>>> more. This validation could be implemented on the LBaaS API itself\n> >>>> as\n> >>>well\n> >>>> as also by the driver who will actually need the container.\n> >>>> >\n> >>>> > Regards,\n> >>>> >                 -Sam.\n> >>>> >\n> >>>> >\n> >>>> > From: Evgeny Fedoruk\n> >>>> > Sent: Tuesday, June 10, 2014 2:13 PM\n> >>>> > To: OpenStack Development Mailing List (not for usage questions)\n> >>>> > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS support RST\n> >>>document\n> >>>> > on Gerrit\n> >>>> >\n> >>>> > Hi All,\n> >>>> >\n> >>>> > Carlos, Vivek, German, thanks for reviewing the RST doc.\n> >>>> > There are some issues I want to pinpoint final decision on them\n> >>>here, in\n> >>>> ML, before writing it down in the doc.\n> >>>> > Other issues will be commented on the document itself.\n> >>>> >\n> >>>> > 1.       Support/No support in JUNO\n> >>>> > Referring to summit\'s etherpad\n> >>>> https://etherpad.openstack.org/p/neutron-lbaas-ssl-l7,\n> >>>> > a.       SNI certificates list was decided to be supported. Was\n> >>>decision made\n> >>>> not to support it?\n> >>>> > Single certificate with multiple domains can only partly address\n> >>>> > the need for SNI, still, different applications on back-end will\n> >>>> > need\n> >>>different\n> >>>> certificates.\n> >>>> > b.      Back-end re-encryption was decided to be supported. Was\n> >>>decision\n> >>>> made not to support it?\n> >>>> > c.       With front-end client authentication and back-end server\n> >>>> authentication not supported,\n> >>>> > Should certificate chains be supported?\n> >>>> > 2.       Barbican TLS containers\n> >>>> > a.       TLS containers are immutable.\n> >>>> > b.      TLS container is allowed to be deleted, always.\n> >>>> >                                                                i.\n> >>>Even when it is used by LBaaS VIP\n> >>>> listener (or other service).\n> >>>> >                                                              ii.\n> >>>Meta data on TLS container will\n> >>>> help tenant to understand that container is in use by LBaaS\n> >>>service/VIP\n> >>>> listener\n> >>>> >                                                             iii.\n> >>>If every VIP listener will \"register\"\n> >>>> itself in meta-data while retrieving container, how that\n> >>>\"registration\" will be\n> >>>> removed when VIP listener stops using the certificate?\n> >>>> >\n> >>>> > Please comment on these points and review the document on gerrit\n> >>>> > (https://review.openstack.org/#/c/98640)\n> >>>> > I will update the document with decisions on above topics.\n> >>>> >\n> >>>> > Thank you!\n> >>>> > Evgeny\n> >>>> >\n> >>>> >\n> >>>> > From: Evgeny Fedoruk\n> >>>> > Sent: Monday, June 09, 2014 2:54 PM\n> >>>> > To: OpenStack Development Mailing List (not for usage questions)\n> >>>> > Subject: [openstack-dev] [Neutron][LBaaS] TLS support RST document\n> >>>on\n> >>>> > Gerrit\n> >>>> >\n> >>>> > Hi All,\n> >>>> >\n> >>>> > A Spec. RST  document for LBaaS TLS support was added to Gerrit\n> >>>> > for review\n> >>>> > https://review.openstack.org/#/c/98640\n> >>>> >\n> >>>> > You are welcome to start commenting it for any open discussions.\n> >>>> > I tried to address each aspect being discussed, please add\n> >>>> > comments\n> >>>> about missing things.\n> >>>> >\n> >>>> > Thanks,\n> >>>> > Evgeny\n> >>>> >\n> >>>> > _______________________________________________\n> >>>> > OpenStack-dev mailing list\n> >>>> >\n> >>>>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.\n> >>>>org>\n> >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>>\n> >>>>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.\n> >>>>org>\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>>\n> >>>>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.\n> >>>>org>\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>>\n> >>>>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.\n> >>>>org>\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.or\n> >>g>\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org\n> >>\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org\n> >>\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> >--\n> >Stephen Balukoff\n> >Blue Box Group, LLC\n> >(800)613-4305 x807<tel:%28800%29613-4305%20x807>\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org\n> >>\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> >--\n> >Stephen Balukoff\n> >Blue Box Group, LLC\n> >(800)613-4305 x807\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/d\n> >ed36643/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 6\n> >Date: Thu, 19 Jun 2014 03:03:19 -0400\n> >From: Mike Spreitzer <mspreitz at us.ibm.com>\n> >To: \"OpenStack Development Mailing List\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: [openstack-dev] [DevStack] fails in lxc running ubuntu trusty\n> >       amd64\n> >Message-ID:\n> >       <OFA53642E6.436B1766-ON85257CFC.00262582-85257CFC.0026C147 at us.ibm.com>\n> >Content-Type: text/plain; charset=\"us-ascii\"\n> >\n> >In my linux containers running Ubuntu 14.04 64-bit, DevStack fails\n> >because\n> >it can not install the package named tgt.  The problem is that the\n> >install\n> >script invokes the tgt service\'s start operation, which launches the\n> >daemon (tgtd), and the launch fails with troubles with RDMA.  Has anybody\n> >tried such a thing?  Any fixes, workarounds?  Any ideas?\n> >\n> >Thanks,\n> >Mike\n> >\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/c\n> >ffb3b09/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 7\n> >Date: Thu, 19 Jun 2014 09:11:12 +0200\n> >From: ?douard Thuleau <thuleau at gmail.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [neutron]Performance of security group\n> >Message-ID:\n> >       <CAKRF=eciO6YVdGmkZgOPZuC9C+j_a_dL9EVSuyg0NmKfDaf+jA at mail.gmail.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >Do you though about nftables that will replace {ip,ip6,arp,eb}tables?\n> >It also based on the rule set mechanism.\n> >The issue in that proposition, it\'s only stable since the begin of the\n> >year\n> >and on Linux kernel 3.13.\n> >But there lot of pros I don\'t list here (leverage iptables limitation,\n> >efficient update rule, rule set, standardization of netfilter\n> >commands...).\n> >\n> >?douard.\n> >\n> >\n> >On Thu, Jun 19, 2014 at 8:25 AM, henry hly <henry4hly at gmail.com> wrote:\n> >\n> >> we have done some tests, but have different result: the performance is\n> >> nearly the same for empty and 5k rules in iptable, but huge gap between\n> >> enable/disable iptable hook on linux bridge\n> >>\n> >>\n> >> On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang <ayshihanzhang at 126.com>\n> >> wrote:\n> >>\n> >>> Now I have not get accurate test data, but I  can confirm the following\n> >>> points?\n> >>> 1. In compute node, the iptable\'s chain of a VM is liner, iptable\n> >>>filter\n> >>> it one by one, if a VM in default security group and this default\n> >>>security\n> >>> group have many members, but ipset chain is set, the time ipset filter\n> >>>one\n> >>> and many member is not much difference.\n> >>> 2. when the iptable rule is very large, the probability of  failure\n> >>>that  iptable-save\n> >>> save the iptable rule  is very large.\n> >>>\n> >>>\n> >>>\n> >>>\n> >>>\n> >>> At 2014-06-19 10:55:56, \"Kevin Benton\" <blak111 at gmail.com> wrote:\n> >>>\n> >>> This sounds like a good idea to handle some of the performance issues\n> >>> until the ovs firewall can be implemented down the the line.\n> >>> Do you have any performance comparisons?\n> >>> On Jun 18, 2014 7:46 PM, \"shihanzhang\" <ayshihanzhang at 126.com> wrote:\n> >>>\n> >>>> Hello all,\n> >>>>\n> >>>> Now in neutron, it use iptable implementing security group, but the\n> >>>> performance of this  implementation is very poor, there is a bug:\n> >>>> https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this\n> >>>> problem. In his test, with default security groups(which has remote\n> >>>> security group), beyond 250-300 VMs, there were around 6k Iptable\n> >>>>rules on\n> >>>> evry compute node, although his patch can reduce the processing time,\n> >>>>but\n> >>>> it don\'t solve this problem fundamentally. I have commit a BP to solve\n> >>>> this problem:\n> >>>> https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security\n> >>>>\n> >>>><https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,>\n> >>>> There are other people interested in this it?\n> >>>>\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/a\n> >f7685ae/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 8\n> >Date: Thu, 19 Jun 2014 08:32:25 +0100\n> >From: Mark McLoughlin <markmc at redhat.com>\n> >To: openstack-dev at lists.openstack.org\n> >Subject: Re: [openstack-dev] [nova] A modest proposal to reduce\n> >       reviewer load\n> >Message-ID: <1403163145.3371.38.camel at sorcha>\n> >Content-Type: text/plain; charset=\"UTF-8\"\n> >\n> >Hi Armando,\n> >\n> >On Tue, 2014-06-17 at 14:51 +0200, Armando M. wrote:\n> >> I wonder what the turnaround of trivial patches actually is, I bet you\n> >> it\'s very very small, and as Daniel said, the human burden is rather\n> >> minimal (I would be more concerned about slowing them down in the\n> >> gate, but I digress).\n> >\n> >>\n> >> I think that introducing a two-tier level for patch approval can only\n> >> mitigate the problem, but I wonder if we\'d need to go a lot further,\n> >> and rather figure out a way to borrow concepts from queueing theory so\n> >> that they can be applied in the context of Gerrit. For instance\n> >> Little\'s law [1] says:\n> >>\n> >> \"The long-term average number of customers (in this context reviews)\n> >> in a stable system L is equal to the long-term average effective\n> >> arrival rate, ?, multiplied by the average time a customer spends in\n> >> the system, W; or expressed algebraically: L = ?W.\"\n> >>\n> >> L can be used to determine the number of core reviewers that a project\n> >> will need at any given time, in order to meet a certain arrival rate\n> >> and average time spent in the queue. If the number of core reviewers\n> >> is a lot less than L then that core team is understaffed and will need\n> >> to increase.\n> >>\n> >> If we figured out how to model and measure Gerrit as a queuing system,\n> >> then we could improve its performance a lot more effectively; for\n> >> instance, this idea of privileging trivial patches over longer patches\n> >> has roots in a popular scheduling policy [3] for  M/G/1 queues, but\n> >> that does not really help aging of \'longer service time\' patches and\n> >> does not have a preemption mechanism built-in to avoid starvation.\n> >>\n> >> Just a crazy opinion...\n> >> Armando\n> >>\n> >> [1] - http://en.wikipedia.org/wiki/Little\'s_law\n> >> [2] - http://en.wikipedia.org/wiki/Shortest_job_first\n> >> [3] - http://en.wikipedia.org/wiki/M/G/1_queue\n> >\n> >This isn\'t crazy at all. We do have a problem that surely could be\n> >studied and solved/improved by applying queueing theory or lessons from\n> >fields like lean manufacturing. Right now, we\'re simply applying our\n> >intuition and the little I\'ve read about these sorts of problems is that\n> >your intuition can easily take you down the wrong path.\n> >\n> >There\'s a bunch of things that occur just glancing through those\n> >articles:\n> >\n> >  - Do we have an unstable system? Would it be useful to have arrival\n> >    and exit rate metrics to help highlight this? Over what time period\n> >    would those rates need to be averaged to be useful? Daily, weekly,\n> >    monthly, an entire release cycle?\n> >\n> >  - What are we trying to optimize for? The length of time in the\n> >    queue? The number of patches waiting in the queue? The response\n> >    time to a new patch revision?\n> >\n> >  - We have a single queue, with a bunch of service nodes with a wide\n> >    variance between their service rates, very little in the way of\n> >    scheduling policy, a huge rate of service nodes sending jobs back\n> >    for rework, a cost associated with maintaining a job while it sits\n> >    in the queue, the tendency for some jobs to disrupt many other jobs\n> >    with merge conflicts ... not simple.\n> >\n> >  - Is there any sort of natural limit in our queue size that makes the\n> >    system stable - e.g. do people naturally just stop submitting\n> >    patches at some point?\n> >\n> >My intuition on all of this lately is that we need some way to model and\n> >experiment with this queue, and I think we could make some interesting\n> >progress if we could turn it into a queueing network rather than a\n> >single, extremely complex queue.\n> >\n> >Say we had a front-end for gerrit which tracked which queue a patch is\n> >in, we could experiment with things like:\n> >\n> >  - a triage queue, with non-cores signed up as triagers looking for\n> >    obvious mistakes and choosing the next queue for a patch to enter\n> >    into\n> >\n> >  - queues having a small number of cores signed up as owners - e.g.\n> >    high priority bugfix, API, scheduler, object conversion, libvirt\n> >    driver, vmware driver, etc.\n> >\n> >  - we\'d allow for a large number of queues so that cores could aim for\n> >    an \"inbox zero\" approach on individual queues, something that would\n> >    probably help keep cores motivated.\n> >\n> >  - we could apply different scheduling policies to each of the\n> >    different queues - i.e. explicit guidance for cores about which\n> >    patches they should pick off the queue next.\n> >\n> >  - we could track metrics on individual queues as well as the whole\n> >    network, identifying bottlenecks and properly recognizing which\n> >    reviewers are doing a small number of difficult reviews versus\n> >    those doing a high number of trivial reviews.\n> >\n> >  - we could require some queues to feed into a final approval queue\n> >    where some people are responsible for giving an approved patch a\n> >    final sanity check - i.e. there would be a class of reviewer with\n> >    good instincts who quickly churn through already-reviewed patches\n> >    looking for the kind of mistakes people tend to mistake when\n> >    they\'re down in the weeds.\n> >\n> >  - explicit queues for large, cross-cutting changes like coding style\n> >    changes. Perhaps we could stop servicing these queues at certain\n> >    points in the cycles, or reduce the rate at which they are\n> >    serviced.\n> >\n> >  - we could include specs and client patches in the same network so\n> >    that they prioritized in the same way.\n> >\n> >Lots of ideas, none of it is trivial ... but perhaps it\'ll spark\n> >someone\'s interest :)\n> >\n> >Mark.\n> >\n> >\n> >\n> >\n> >------------------------------\n> >\n> >Message: 9\n> >Date: Thu, 19 Jun 2014 09:55:10 +0200\n> >From: J?r?me Gallard <gallard.jerome at gmail.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [DevStack] fails in lxc running ubuntu\n> >       trusty  amd64\n> >Message-ID:\n> >       <CALkfQzDGe1hbWxjTeNiFkNtRvCrFsFCEnRWZ6sp+HKrjhXQwxg at mail.gmail.com>\n> >Content-Type: text/plain; charset=\"utf-8\"\n> >\n> >Hi Mike,\n> >\n> >We worked with Devstack and LXC and got the same issue (\n> >https://blueprints.launchpad.net/devstack/+spec/lxc-computes ).\n> >\n> >The issue seems to be linked with namespace:\n> >https://www.mail-archive.com/openstack-infra at lists.openstack.org/msg00839.\n> >html\n> >https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855\n> >\n> >Hope it helps,\n> >J?r?me\n> >\n> >\n> >\n> >2014-06-19 9:03 GMT+02:00 Mike Spreitzer <mspreitz at us.ibm.com>:\n> >\n> >> In my linux containers running Ubuntu 14.04 64-bit, DevStack fails\n> >>because\n> >> it can not install the package named tgt.  The problem is that the\n> >>install\n> >> script invokes the tgt service\'s start operation, which launches the\n> >>daemon\n> >> (tgtd), and the launch fails with troubles with RDMA.  Has anybody tried\n> >> such a thing?  Any fixes, workarounds?  Any ideas?\n> >>\n> >> Thanks,\n> >> Mike\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/3\n> >e13cd1c/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 10\n> >Date: Thu, 19 Jun 2014 09:58:15 +0200\n> >From: Matthias Runge <mrunge at redhat.com>\n> >To: openstack-dev at lists.openstack.org\n> >Subject: Re: [openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle\n> >       Meetup\n> >Message-ID: <20140619075815.GE3896 at turing.berg.ol>\n> >Content-Type: text/plain; charset=us-ascii\n> >\n> >On Wed, Jun 18, 2014 at 10:55:59AM +0200, Jaromir Coufal wrote:\n> >> My quick questions are:\n> >> * Who would be interested (and able) to get to the meeting?\n> >> * What topics do we want to discuss?\n> >>\n> >> https://etherpad.openstack.org/p/horizon-juno-meetup\n> >>\n> >Thanks for bringing this up!\n> >\n> >Do we really have items to discuss, where it needs a meeting in person?\n> >\n> >Matthias\n> >--\n> >Matthias Runge <mrunge at redhat.com>\n> >\n> >\n> >\n> >------------------------------\n> >\n> >Message: 11\n> >Date: Thu, 19 Jun 2014 09:34:31 +0100\n> >From: Matthew Booth <mbooth at redhat.com>\n> >To: openstack-dev at lists.openstack.org\n> >Subject: Re: [openstack-dev] [nova] A modest proposal to reduce\n> >       reviewer load\n> >Message-ID: <53A2A097.3090309 at redhat.com>\n> >Content-Type: text/plain; charset=UTF-8\n> >\n> >On 19/06/14 08:32, Mark McLoughlin wrote:\n> >> Hi Armando,\n> >>\n> >> On Tue, 2014-06-17 at 14:51 +0200, Armando M. wrote:\n> >>> I wonder what the turnaround of trivial patches actually is, I bet you\n> >>> it\'s very very small, and as Daniel said, the human burden is rather\n> >>> minimal (I would be more concerned about slowing them down in the\n> >>> gate, but I digress).\n> >>\n> >>>\n> >>> I think that introducing a two-tier level for patch approval can only\n> >>> mitigate the problem, but I wonder if we\'d need to go a lot further,\n> >>> and rather figure out a way to borrow concepts from queueing theory so\n> >>> that they can be applied in the context of Gerrit. For instance\n> >>> Little\'s law [1] says:\n> >>>\n> >>> \"The long-term average number of customers (in this context reviews)\n> >>> in a stable system L is equal to the long-term average effective\n> >>> arrival rate, ?, multiplied by the average time a customer spends in\n> >>> the system, W; or expressed algebraically: L = ?W.\"\n> >>>\n> >>> L can be used to determine the number of core reviewers that a project\n> >>> will need at any given time, in order to meet a certain arrival rate\n> >>> and average time spent in the queue. If the number of core reviewers\n> >>> is a lot less than L then that core team is understaffed and will need\n> >>> to increase.\n> >>>\n> >>> If we figured out how to model and measure Gerrit as a queuing system,\n> >>> then we could improve its performance a lot more effectively; for\n> >>> instance, this idea of privileging trivial patches over longer patches\n> >>> has roots in a popular scheduling policy [3] for  M/G/1 queues, but\n> >>> that does not really help aging of \'longer service time\' patches and\n> >>> does not have a preemption mechanism built-in to avoid starvation.\n> >>>\n> >>> Just a crazy opinion...\n> >>> Armando\n> >>>\n> >>> [1] - http://en.wikipedia.org/wiki/Little\'s_law\n> >>> [2] - http://en.wikipedia.org/wiki/Shortest_job_first\n> >>> [3] - http://en.wikipedia.org/wiki/M/G/1_queue\n> >>\n> >> This isn\'t crazy at all. We do have a problem that surely could be\n> >> studied and solved/improved by applying queueing theory or lessons from\n> >> fields like lean manufacturing. Right now, we\'re simply applying our\n> >> intuition and the little I\'ve read about these sorts of problems is that\n> >> your intuition can easily take you down the wrong path.\n> >>\n> >> There\'s a bunch of things that occur just glancing through those\n> >> articles:\n> >>\n> >>   - Do we have an unstable system? Would it be useful to have arrival\n> >>     and exit rate metrics to help highlight this? Over what time period\n> >>     would those rates need to be averaged to be useful? Daily, weekly,\n> >>     monthly, an entire release cycle?\n> >>\n> >>   - What are we trying to optimize for? The length of time in the\n> >>     queue? The number of patches waiting in the queue? The response\n> >>     time to a new patch revision?\n> >>\n> >>   - We have a single queue, with a bunch of service nodes with a wide\n> >>     variance between their service rates, very little in the way of\n> >>     scheduling policy, a huge rate of service nodes sending jobs back\n> >>     for rework, a cost associated with maintaining a job while it sits\n> >>     in the queue, the tendency for some jobs to disrupt many other jobs\n> >>     with merge conflicts ... not simple.\n> >>\n> >>   - Is there any sort of natural limit in our queue size that makes the\n> >>     system stable - e.g. do people naturally just stop submitting\n> >>     patches at some point?\n> >>\n> >> My intuition on all of this lately is that we need some way to model and\n> >> experiment with this queue, and I think we could make some interesting\n> >> progress if we could turn it into a queueing network rather than a\n> >> single, extremely complex queue.\n> >>\n> >> Say we had a front-end for gerrit which tracked which queue a patch is\n> >> in, we could experiment with things like:\n> >>\n> >>   - a triage queue, with non-cores signed up as triagers looking for\n> >>     obvious mistakes and choosing the next queue for a patch to enter\n> >>     into\n> >>\n> >>   - queues having a small number of cores signed up as owners - e.g.\n> >>     high priority bugfix, API, scheduler, object conversion, libvirt\n> >>     driver, vmware driver, etc.\n> >>\n> >>   - we\'d allow for a large number of queues so that cores could aim for\n> >>     an \"inbox zero\" approach on individual queues, something that would\n> >>     probably help keep cores motivated.\n> >>\n> >>   - we could apply different scheduling policies to each of the\n> >>     different queues - i.e. explicit guidance for cores about which\n> >>     patches they should pick off the queue next.\n> >>\n> >>   - we could track metrics on individual queues as well as the whole\n> >>     network, identifying bottlenecks and properly recognizing which\n> >>     reviewers are doing a small number of difficult reviews versus\n> >>     those doing a high number of trivial reviews.\n> >>\n> >>   - we could require some queues to feed into a final approval queue\n> >>     where some people are responsible for giving an approved patch a\n> >>     final sanity check - i.e. there would be a class of reviewer with\n> >>     good instincts who quickly churn through already-reviewed patches\n> >>     looking for the kind of mistakes people tend to mistake when\n> >>     they\'re down in the weeds.\n> >>\n> >>   - explicit queues for large, cross-cutting changes like coding style\n> >>     changes. Perhaps we could stop servicing these queues at certain\n> >>     points in the cycles, or reduce the rate at which they are\n> >>     serviced.\n> >>\n> >>   - we could include specs and client patches in the same network so\n> >>     that they prioritized in the same way.\n> >>\n> >> Lots of ideas, none of it is trivial ... but perhaps it\'ll spark\n> >> someone\'s interest :)\n> >\n> >This is all good stuff, but by the sounds of it experimenting in gerrit\n> >isn\'t likely to be simple.\n> >\n> >Remember, though, that the relevant metric is code quality, not review\n> >rate.\n> >\n> >Matt\n> >--\n> >Matthew Booth\n> >Red Hat Engineering, Virtualisation Team\n> >\n> >Phone: +442070094448 (UK)\n> >GPG ID:  D33C3490\n> >GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490\n> >\n> >\n> >\n> >------------------------------\n> >\n> >Message: 12\n> >Date: Thu, 19 Jun 2014 09:38:26 +0100\n> >From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [nova][libvirt] Block migrations and\n> >       Cinder volumes\n> >Message-ID: <20140619083826.GA6545 at redhat.com>\n> >Content-Type: text/plain; charset=utf-8\n> >\n> >On Wed, Jun 18, 2014 at 11:09:33PM -0700, Rafi Khardalian wrote:\n> >> I am concerned about how block migration functions when Cinder volumes\n> >>are\n> >> attached to an instance being migrated.  We noticed some unexpected\n> >> behavior recently, whereby attached generic NFS-based volumes would\n> >>become\n> >> entirely unsparse over the course of a migration.  After spending some\n> >>time\n> >> reviewing the code paths in Nova, I\'m more concerned that this was\n> >>actually\n> >> a minor symptom of a much more significant issue.\n> >>\n> >> For those unfamiliar, NFS-based volumes are simply RAW files residing\n> >>on an\n> >> NFS mount.  From Libvirt\'s perspective, these volumes look no different\n> >> than root or ephemeral disks.  We are currently not filtering out\n> >>volumes\n> >> whatsoever when making the request into Libvirt to perform the\n> >>migration.\n> >>  Libvirt simply receives an additional flag (VIR_MIGRATE_NON_SHARED_INC)\n> >> when a block migration is requested, which applied to the entire\n> >>migration\n> >> process, not differentiated on a per-disk basis.  Numerous guards within\n> >> Nova to prevent a block based migration from being allowed if the\n> >>instance\n> >> disks exist on the destination; yet volumes remain attached and within\n> >>the\n> >> defined XML during a block migration.\n> >>\n> >> Unless Libvirt has a lot more logic around this than I am lead to\n> >>believe,\n> >> this seems like a recipe for corruption.  It seems as though this would\n> >> also impact any type of volume attached to an instance (iSCSI, RBD,\n> >>etc.),\n> >> NFS just happens to be what we were testing.  If I am wrong and someone\n> >>can\n> >> correct my understanding, I would really appreciate it.  Otherwise, I\'m\n> >> surprised we haven\'t had more reports of issues when block migrations\n> >>are\n> >> used in conjunction with any attached volumes.\n> >\n> >Libvirt/QEMU has no special logic. When told to block-migrate, it will do\n> >so for *all* disks attached to the VM in read-write-exclusive mode. It\n> >will\n> >only skip those marked read-only or read-write-shared mode. Even that\n> >distinction is somewhat dubious and so not reliably what you would want.\n> >\n> >It seems like we should just disallow block migrate when any cinder\n> >volumes\n> >are attached to the VM, since there is never any valid use case for doing\n> >block migrate from a cinder volume to itself.\n> >\n> >Regards,\n> >Daniel\n> >--\n> >|: http://berrange.com      -o-\n> >http://www.flickr.com/photos/dberrange/ :|\n> >|: http://libvirt.org              -o-\n> >http://virt-manager.org :|\n> >|: http://autobuild.org       -o-\n> >http://search.cpan.org/~danberr/ :|\n> >|: http://entangle-photo.org       -o-\n> >http://live.gnome.org/gtk-vnc :|\n> >\n> >\n> >\n> >------------------------------\n> >\n> >Message: 13\n> >Date: Thu, 19 Jun 2014 11:01:19 +0200\n> >From: Giulio Fidente <gfidente at redhat.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [TripleO] Backwards compatibility policy\n> >       for our projects\n> >Message-ID: <53A2A6DF.5010606 at redhat.com>\n> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed\n> >\n> >On 06/16/2014 10:06 PM, James Slagle wrote:\n> >> On Mon, Jun 16, 2014 at 12:19 PM, Tomas Sedovic <tsedovic at redhat.com>\n> >>wrote:\n> >\n> >>> If we do promise backwards compatibility, we should document it\n> >>> somewhere and if we don\'t we should probably make that more visible,\n> >>> too, so people know what to expect.\n> >>>\n> >>> I prefer the latter, because it will make the merge.py cleanup easier\n> >>> and every published bit of information I could find suggests that\'s our\n> >>> current stance anyway.\n> >\n> >> Much of this is the reason why I pushed for the stable branches that\n> >> we cut for icehouse. I\'m not sure what \"downstreams that have shipped\n> >> things\" are being referred to, but perhaps those needs could be served\n> >> by the stable/icehouse branches that exist today?  I know at least for\n> >> the RDO downstream, the packages are being built off of releases done\n> >> from the stable branches. So, honestly, I\'m not that concerned about\n> >> your proposed changes to rip stuff out without any deprecation from\n> >> that point of view :).\n> >\n> >+1 on relying on the branches\n> >\n> >I personally don\'t see the backward compatibility much of an issue in\n> >TripleO (but I may miss some pieces though) ... more below\n> >\n> >> That being said, just because TripleO has taken the stance that\n> >> backwards compatibility is not guaranteed, I agree with some of the\n> >> other sentiments in this thread: that we should at least try if there\n> >> are easy things we can do.\n> >\n> > From a the 10.000 feet view, I can imagine people relying on a stable\n> >API for services like Cinder but I don\'t see how that applies to TripleO\n> >\n> >Why should one try to install an older version of OpenStack using some\n> >\'recent\' version TripleO?\n> >\n> >The only scenario which comes up to my mind is the \'upgrade\' process\n> >where undercloud and overcloud could get \'out of sync\', yet this seems\n> >to have a pretty limited scope.\n> >\n> >A genuine question from a \'wannabe\' TripleO contributor, do you see\n> >others? many others?\n> >--\n> >Giulio Fidente\n> >GPG KEY: 08D733BA\n> >\n> >\n> >\n> >------------------------------\n> >\n> >Message: 14\n> >Date: Thu, 19 Jun 2014 13:06:41 +0300\n> >From: Ronen Kat <RONENKAT at il.ibm.com>\n> >To: \"OpenStack Development Mailing List \\(not for usage questions\\)\"\n> >       <openstack-dev at lists.openstack.org>\n> >Subject: Re: [openstack-dev] [nova][libvirt] Block migrations and\n> >       Cinder  volumes\n> >Message-ID:\n> >       <OFF787EA7D.FFEEE06B-ONC2257CFC.00370FAE-C2257CFC.00378B6E at il.ibm.com>\n> >Content-Type: text/plain; charset=\"us-ascii\"\n> >\n> >The use-case for block migration in Libvirt/QEMU is to allow migration\n> >between two different back-ends.\n> >This is basically a host based volume migration, ESXi has a similar\n> >functionality (storage vMotion), but probably not enabled with OpenStack.\n> >Btw, if the Cinder volume driver can migrate the volume by itself, the\n> >Libvirt/QEMU is not called upon, but if it can\'t (different vendor boxes\n> >don\'t talk to each other), then Cinder asks Nova to help move the data...\n> >\n> >If you are missing this host based process you are basically have a \"data\n> >lock-in\" on a specific back-end - the use case could be storage\n> >evacuation, or just moving the data to a different box.\n> >\n> >Ronen,\n> >\n> >\n> >\n> >From:   \"Daniel P. Berrange\" <berrange at redhat.com>\n> >To:     \"OpenStack Development Mailing List (not for usage questions)\"\n> ><openstack-dev at lists.openstack.org>,\n> >Date:   19/06/2014 11:42 AM\n> >Subject:        Re: [openstack-dev] [nova][libvirt] Block migrations and\n> >Cinder volumes\n> >\n> >\n> >\n> >On Wed, Jun 18, 2014 at 11:09:33PM -0700, Rafi Khardalian wrote:\n> >> I am concerned about how block migration functions when Cinder volumes\n> >are\n> >> attached to an instance being migrated.  We noticed some unexpected\n> >> behavior recently, whereby attached generic NFS-based volumes would\n> >become\n> >> entirely unsparse over the course of a migration.  After spending some\n> >time\n> >> reviewing the code paths in Nova, I\'m more concerned that this was\n> >actually\n> >> a minor symptom of a much more significant issue.\n> >>\n> >> For those unfamiliar, NFS-based volumes are simply RAW files residing\n> >>on\n> >an\n> >> NFS mount.  From Libvirt\'s perspective, these volumes look no different\n> >> than root or ephemeral disks.  We are currently not filtering out\n> >volumes\n> >> whatsoever when making the request into Libvirt to perform the\n> >migration.\n> >>  Libvirt simply receives an additional flag (VIR_MIGRATE_NON_SHARED_INC)\n> >> when a block migration is requested, which applied to the entire\n> >migration\n> >> process, not differentiated on a per-disk basis.  Numerous guards within\n> >> Nova to prevent a block based migration from being allowed if the\n> >instance\n> >> disks exist on the destination; yet volumes remain attached and within\n> >the\n> >> defined XML during a block migration.\n> >>\n> >> Unless Libvirt has a lot more logic around this than I am lead to\n> >believe,\n> >> this seems like a recipe for corruption.  It seems as though this would\n> >> also impact any type of volume attached to an instance (iSCSI, RBD,\n> >etc.),\n> >> NFS just happens to be what we were testing.  If I am wrong and someone\n> >can\n> >> correct my understanding, I would really appreciate it.  Otherwise, I\'m\n> >> surprised we haven\'t had more reports of issues when block migrations\n> >are\n> >> used in conjunction with any attached volumes.\n> >\n> >Libvirt/QEMU has no special logic. When told to block-migrate, it will do\n> >so for *all* disks attached to the VM in read-write-exclusive mode. It\n> >will\n> >only skip those marked read-only or read-write-shared mode. Even that\n> >distinction is somewhat dubious and so not reliably what you would want.\n> >\n> >It seems like we should just disallow block migrate when any cinder\n> >volumes\n> >are attached to the VM, since there is never any valid use case for doing\n> >block migrate from a cinder volume to itself.\n> >\n> >Regards,\n> >Daniel\n> >--\n> >|: http://berrange.com      -o-\n> >http://www.flickr.com/photos/dberrange/\n> >:|\n> >|: http://libvirt.org              -o-\n> >http://virt-manager.org\n> >:|\n> >|: http://autobuild.org       -o-\n> >http://search.cpan.org/~danberr/\n> >:|\n> >|: http://entangle-photo.org       -o-\n> >http://live.gnome.org/gtk-vnc\n> >:|\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >-------------- next part --------------\n> >An HTML attachment was scrubbed...\n> >URL:\n> ><http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/8\n> >041b725/attachment-0001.html>\n> >\n> >------------------------------\n> >\n> >Message: 15\n> >Date: Thu, 19 Jun 2014 15:40:37 +0530\n> >From: AMIT PRAKASH PANDEY <amitpp23 at gmail.com>\n> >To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >       <openstack-dev at lists.o','<CFC8760C.40EB%travis_mcpeak@symantec.com>',NULL),('<1403204815.05322575@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-06-19 14:06:55',-18000,'2014-06-19 19:06:55',NULL,'[openstack-community] 2 passes left for OpenStack volunteers for\n	EuroPython','\nInterested in attending EuroPython in Berlin, July 21-27?  OpenStack has a table there.  Red Hat has kindly offered several volunteers, but we\'d love to extend the last two opportunities to other community members.  If you\'re available to talk to developers about using and contributing to OpenStack, and attend sessions and parties, please let me know.  The registration deadline is coming up soon.  Thank you!\n \nPS - you\'ll receive an OOO message from me, but I\'ll be checking email occasionally while on holiday.  \n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140619/6d3e7f30/attachment.html>\n\n',NULL,NULL),('<1403212533-sup-8874@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 14:17:09',-25200,'2014-06-19 21:17:09',NULL,'[openstack-dev] [Heat] fine grained quotas','I was made aware of the following blueprint today:\n\nhttp://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat\nhttp://review.openstack.org/#/c/96696/14\n\nBefore this goes much further.. I want to suggest that this work be\ncancelled, even though the code looks excellent. The reason those limits\nare in the config file is that these are not billable items and they\nhave a _tiny_ footprint in comparison to the physical resources they\nwill allocate in Nova/Cinder/Neutron/etc.\n\nIMO we don\'t need fine grained quotas in Heat because everything the\nuser will create with these templates will cost them and have its own\nquota system. The limits (which I added) are entirely to prevent a DoS\nof the engine.\n\n\n',NULL,NULL),('<1403217080-sup-5160@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 15:33:02',-25200,'2014-06-19 22:33:02',NULL,'[openstack-dev] [Heat] fine grained quotas','Excerpts from Randall Burt\'s message of 2014-06-19 15:21:14 -0700:\n> On Jun 19, 2014, at 4:17 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > I was made aware of the following blueprint today:\n> > \n> > http://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat\n> > http://review.openstack.org/#/c/96696/14\n> > \n> > Before this goes much further.. I want to suggest that this work be\n> > cancelled, even though the code looks excellent. The reason those limits\n> > are in the config file is that these are not billable items and they\n> > have a _tiny_ footprint in comparison to the physical resources they\n> > will allocate in Nova/Cinder/Neutron/etc.\n> > \n> > IMO we don\'t need fine grained quotas in Heat because everything the\n> > user will create with these templates will cost them and have its own\n> > quota system. The limits (which I added) are entirely to prevent a DoS\n> > of the engine.\n> \n> What\'s more, I don\'t think this is something we should expose via\n> API other than to perhaps query what those quota values are. It is\n> possible that some provider would want to bill on number of stacks, etc\n> (I personally agree with Clint here), it seems that is something that\n> could/should be handled external to Heat itself.\n\nFar be it from any of us to dictate a single business model. However, Heat\nis a tool which encourages consumption of billable resources by making\nit easier to tie them together. This is why FedEx gives away envelopes\nand will come pick up your packages for free.\n\n\n','<0B721217-9698-40D6-BE7C-41C503494EF1@rackspace.com>',NULL),('<1403237853.4182.30.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 04:17:20',0,'2014-06-20 04:17:20',NULL,'[openstack-dev]  [Neutron][LBaaS] Great Mid-cycle Sprint','Greetings all,\nI\'d like to thank everyone who attended the LBaaS mid-cyle sprint for\ntaking the time and effort to make the trip to San Antonio.  This was a\nvery productive sprint in all forms: direction, consensus, blueprints,\ndocumentation, and of course code.  It was just great to be able to get\nso much done and have a clearer idea on the direction this project is\nheaded.\n\nI\'d like to especially thank Kyle Mestery and Mark Mcclain for taking\nthe time out of their busy schedules to direct, teach, and giving us\nhelp where and when we needed.  The fact that they managed to have the\npatience for three full days of this is just amazing.  Actually, them\nhaving the patience over the last few months and still willing to help\nis just short of miraculous.  Thanks again guys, you are great!\n\nI look forward to continuing to work with everyone on this and other\nprojects.  We\'ve got a lot to do but we\'ll be able to accomplish\neverything we want if we continue to work together.  Thanks again to all\ninvolved!\n\nBrandon\n\n\n','<CAAGw+ZoWnPZJ_r6VASzQg4DX06uP8JWTUn6+vMsqQW+C5Fd9jA@mail.gmail.com>',NULL),('<1403245782.14669.5.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 07:29:42',3600,'2014-06-20 06:29:42',NULL,'[openstack-dev] [Octavia] PTL and core team members','On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:\n> Dolph,\n> \n> \n> I appreciate the suggestion. In the mean time how does the review\n> process work without core developers to approve gerrit submissions?\n\nIf you\'re just getting started, have a small number (possibly just 1 to\nbegin with) of developers collaborate closely, with the minimum possible\nprocess and then use that list of developers as your core review team\nwhen you gradually start adopting some process. Aim to get from zero to\nbootstrapped with that core team in a small number of weeks at most.\n\nMinimum possible process could mean a git repo anywhere that those\ninitial developers have direct push access to. You could use stackforge\nfrom the beginning and the developers just approve their own changes,\nbut that\'s a bit annoying.\n\nMark.\n\n\n\n\n','<CAM=UhHvdz_r8QDNYCoMxkWWcHz0g15yTzS3doEMYmsfZwo1ZYQ@mail.gmail.com>',NULL),('<1403253835.25854.YahooMailNeo@web193603.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-20 16:43:55',28800,'2014-06-20 08:43:55',NULL,'[Openstack] want to contribute studied architecture of swift','Hi?Trinath,\n\nAs mentioned in the link suggested by you, I create launchpad account and join Openstack Foundation.\nNow what should I do to contribute the findings?\n\nRegards?\nPragya jain\n\n\n\n\nOn Tuesday, 17 June 2014 11:10 AM, \"trinath.somanchi at freescale.com\" <trinath.somanchi at freescale.com> wrote:\n \n\n>\n>\n>The answer is YES.\n>?\n>Look to the openstack guidelines for code contribution at https://wiki.openstack.org/wiki/How_To_Contribute\n>?\n>?\n>?\n>--\n>Trinath Somanchi - B39208\n>trinath.somanchi at freescale.com| extn: 4048\n>?\n>From:pragya jain [mailto:prag_2648 at yahoo.co.in] \n>Sent: Tuesday, June 17, 2014 11:00 AM\n>To: openstack at lists.openstack.org\n>Subject: [Openstack] want to contribute studied architecture of swift\n>?\n>Hello all!\n>?\n>I had studied the architecture of swift from its source code available at Github.\n>And, I want to contribute that with swift community.\n>?\n>Can I contribute it?\n>?\n>Regards?\n>Pragya jain\n>\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140620/aa604be8/attachment.html>\n\n','<2702776c5cfc4dd5b3bfb0a8b7f7084a@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1403268033.14669.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 13:40:33',3600,'2014-06-20 12:40:33',NULL,'[openstack-dev] [Oslo] Translating log and exception messages in\n	Oslo libraries','Hi\n\nI\'m not sure we\'ve ever discussed this before, but I had previously\nfigured that we shouldn\'t translate log and exception messages in\noslo.messaging.\n\nMy thinking is:\n\n  - it seems like an odd thing for a library to do, I don\'t know of \n    examples of other libraries doing this .. but I haven\'t gone\n    looking\n\n  - it involves a dependency on oslo.i18n\n\n  - more than just marking strings for translation and using \n    gettextutils, you also need to set up the infrastructure for pushing\n    the .pot files to transifex, pulling the .po files from .transifex \n    and installing the .mo files at install time\n\nI don\'t feel terribly strongly about this except that unless someone is\nwilling to see this through and do the transifex and install-time work,\nwe shouldn\'t be doing the use-oslo.i18n and mark-strings-for-translation\nwork.\n\nMark.\n\n\n\n',NULL,NULL),('<1403276161-sup-5409@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 08:00:39',-25200,'2014-06-20 15:00:39',NULL,'[openstack-dev] 答复: [Heat] fine grained quotas','I started to type the same response as Duncan last night, and I do have\nthe same concern.\n\nThe fine grained quotas in nova, for instance, can be used to measure\npotential use of the whole system _exactly_. You can give a bit more\nto one tenant while you\'re building out your infrastructure for more\ntenants to come on board at the lower quotas and know that the one more\ndemanding tenant will still be happy.\n\nBut how much RAM does it cost to have 1000 stacks creating all at\nonce? How much CPU does it cost? Those are not really 1:1 correlated,\nand so I also question whether one can really use these quotas to do\nsuch fine grained planning.\n\nExcerpts from Duncan Thomas\'s message of 2014-06-20 05:12:44 -0700:\n> There\'s a maintenance and testing cost to the added complexity, and as\n> far as I can tell, no solid use-case. Under what circumstance would a\n> cloud provider want different limits for different tenants? What\n> concrete problem does it solve?\n> \n> On 20 June 2014 04:35, Huangtianhua <huangtianhua at huawei.com> wrote:\n> > Hi, Clint,\n> >\n> > Thank you for your comments on my BP and code!\n> >\n> > The BP I proposed is all about putting dynamic, admin-configurable limitations\n> > on stack number per tenant and stack complexity. Therefore, you can consider my BP as\n> > an extension to your config file-based limitation mechanism. If the admin does not want to\n> > configure fined-grained, tenant-specific limits, the values in config become the defalut\n> > values of those limits.\n> >\n> > And just like only an Admin can config the limit items in the config file, the limit update\n> > and delete APIs I proposed are also Admin-only. Therefore, users can not set those values by\n> > themselves to break the anti-DoS capability you mentioned.\n> >\n> > The reason I want to introduce the APIs and the dynamic configurable capability to those\n> > limits mainly lies in that, since various tenants have various underlying resource quota,\n> > and even various template/stack complexity requirements, I think a global, static-configured\n> > limitation mechanism could be refined to echo user requirements better.\n> >\n> > Your idea?\n> >\n> > By the way, I do think that, the DoS problem is interesting in Heat. Can we have more discussion on that?\n> >\n> > Thanks again!\n> >\n> > -----????-----\n> > ???: Clint Byrum [mailto:clint at fewbar.com]\n> > ????: 2014?6?20? 6:33\n> > ???: openstack-dev\n> > ??: Re: [openstack-dev] [Heat] fine grained quotas\n> >\n> > Excerpts from Randall Burt\'s message of 2014-06-19 15:21:14 -0700:\n> >> On Jun 19, 2014, at 4:17 PM, Clint Byrum <clint at fewbar.com> wrote:\n> >>\n> >> > I was made aware of the following blueprint today:\n> >> >\n> >> > http://blueprints.launchpad.net/heat/+spec/add-quota-api-for-heat\n> >> > http://review.openstack.org/#/c/96696/14\n> >> >\n> >> > Before this goes much further.. I want to suggest that this work be\n> >> > cancelled, even though the code looks excellent. The reason those\n> >> > limits are in the config file is that these are not billable items\n> >> > and they have a _tiny_ footprint in comparison to the physical\n> >> > resources they will allocate in Nova/Cinder/Neutron/etc.\n> >> >\n> >> > IMO we don\'t need fine grained quotas in Heat because everything the\n> >> > user will create with these templates will cost them and have its\n> >> > own quota system. The limits (which I added) are entirely to prevent\n> >> > a DoS of the engine.\n> >>\n> >> What\'s more, I don\'t think this is something we should expose via API\n> >> other than to perhaps query what those quota values are. It is\n> >> possible that some provider would want to bill on number of stacks,\n> >> etc (I personally agree with Clint here), it seems that is something\n> >> that could/should be handled external to Heat itself.\n> >\n> > Far be it from any of us to dictate a single business model. However, Heat is a tool which encourages consumption of billable resources by making it easier to tie them together. This is why FedEx gives away envelopes and will come pick up your packages for free.\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAOyZ2aFuFc_sLOUz5Rru6sU0ca615_hF56-eHi42EnYSAutu1w@mail.gmail.com>',NULL),('<1403290164.1577.11.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 14:49:24',-14400,'2014-06-20 18:49:24',NULL,'[openstack-dev] [TripleO] CI status update for this week','Not a great week for TripleO CI. We had 3 different failures related to:\n\n Nova [1]: we were using a deprecated config option\n Heat [2]: missing heat data obtained from the Heat CFN API\n Neutron [3]: a broken GRE overlay network setup\n\nThe TripleO check jobs look to be running stable again today so if your\npatch had failures from earlier this week then recheck away (perhaps\nreferencing one of these bugs if appropriate). The queue is fairly empty\nright now...\n\nThanks for all the help in tracking these down and getting things fixed.\n\n[1] https://bugs.launchpad.net/tripleo/+bug/1292105\n[2] https://bugs.launchpad.net/heat/+bug/1331720\n[3] https://bugs.launchpad.net/tripleo/+bug/1292105\n\n\n\n\n',NULL,NULL),('<1403300144-sup-5916@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 14:39:25',-25200,'2014-06-20 21:39:25',NULL,'[openstack-dev] [TripleO] CI status update for this week','Excerpts from Charles Crouch\'s message of 2014-06-20 13:51:49 -0700:\n> \n> ----- Original Message -----\n> > Not a great week for TripleO CI. We had 3 different failures related to:\n> > \n> >  Nova [1]: we were using a deprecated config option\n> >  Heat [2]: missing heat data obtained from the Heat CFN API\n> >  Neutron [3]: a broken GRE overlay network setup\n> \n> The last two are bugs, but is there anything tripleo can do about avoiding the first one in the future?:\n> e.g. reviewing a list of deprecated options and seeing when they will be removed.\n> \n> do the integrated projects have a protocol for when an option is deprecated and at what point it can be removed?\n> e.g. if I make something deprecated in icehouse I can remove it in juno, but if I\n> make something deprecated at the start of juno I can\'t remove it at the end of juno?\n> \n\nWas this being logged as deprecated for a while? I think we probably\nshould aspire to fail CI if something starts printing out deprecation\nwarnings. We have a few more sprinkled here and there that I see in logs;\nthose are just ticking time bombs.\n\n\n','<2134326502.37860561.1403297509925.JavaMail.zimbra@redhat.com>',NULL),('<1403310310.8321.4.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 20:25:10',-14400,'2014-06-21 00:25:10',NULL,'[openstack-dev] [TripleO] CI status update for this week','On Fri, 2014-06-20 at 16:51 -0400, Charles Crouch wrote:\n> \n> ----- Original Message -----\n> > Not a great week for TripleO CI. We had 3 different failures related to:\n> > \n> >  Nova [1]: we were using a deprecated config option\n> >  Heat [2]: missing heat data obtained from the Heat CFN API\n> >  Neutron [3]: a broken GRE overlay network setup\n> \n> The last two are bugs, but is there anything tripleo can do about avoiding the first one in the future?:\n\nYes. Reviewing and monitoring our log files would have been helpful\nhere. Nova did nothing wrong... we were just plain using an old option\nwhich was deprecated in Icehouse.\n\nWith TripleO\'s upstream focus we need to maintain a balancing act and\ntry to avoid using new option names until a release has been made. I\nthink once the release is made however (Icehouse in this case) we should\nimmediately move to drop all deprecated options and use the new\nversions. If we follow a process like this we should be safe guarded\nfrom this sort of failure in the future.\n\nDan\n\n> e.g. reviewing a list of deprecated options and seeing when they will be removed.\n> \n> do the integrated projects have a protocol for when an option is deprecated and at what point it can be removed?\n> e.g. if I make something deprecated in icehouse I can remove it in juno, but if I\n> make something deprecated at the start of juno I can\'t remove it at the end of juno?\n> \n> > \n> > The TripleO check jobs look to be running stable again today so if your\n> > patch had failures from earlier this week then recheck away (perhaps\n> > referencing one of these bugs if appropriate). The queue is fairly empty\n> > right now...\n> > \n> > Thanks for all the help in tracking these down and getting things fixed.\n> > \n> > [1] https://bugs.launchpad.net/tripleo/+bug/1292105\n> \n> I think [1] was meant to be\n> https://bugs.launchpad.net/tripleo/+bug/1330735\n> \n> > [2] https://bugs.launchpad.net/heat/+bug/1331720\n> > [3] https://bugs.launchpad.net/tripleo/+bug/1292105\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<2134326502.37860561.1403297509925.JavaMail.zimbra@redhat.com>',NULL),('<1403313504-sup-8027@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 18:26:50',-25200,'2014-06-21 01:26:50',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Sean Dague\'s message of 2014-06-20 11:07:39 -0700:\n> After seeing a bunch of code changes to enforce new hacking rules, I\'d\n> like to propose dropping some of the rules we have. The overall patch\n> series is here -\n> https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z\n> \n> H402 - 1 line doc strings should end in punctuation. The real statement\n> is this should be a summary sentence. A sentence is not just a set of\n> words that end in a period. Squirel fast bob. It\'s something deeper.\n> This rule thus isn\'t really semantically useful, especially when you are\n> talking about at 69 character maximum (79 - 4 space indent - 6 quote\n> characters).\n\nYes. I despise this one.\n\n> \n> H803 - First line of a commit message must *not* end in a period. This\n> was mostly a response to an unreasonable core reviewer that was -1ing\n> people for not having periods. I think any core reviewer that -1s for\n> this either way should be thrown off the island, or at least made fun\n> of, a lot. Again, the clarity of a commit message is not made or lost by\n> the lack or existence of a period at the end of the first line.\n> \n\nPerhaps we can make a bot that writes disparaging remarks on any -1\'s\nthat mention \"period\" in the line after the short commit message. :)\n\n> H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty,\n> our tree. This biggest issue here is it\'s built in a world where there\n> was only 1 viable python version, 2.7. Python\'s stdlib is actually\n> pretty dynamic and grows over time. As we embrace more python 3, and as\n> distros start to make python3 be front and center, what does this even\n> mean? The current enforcement can\'t pass on both python2 and python3 at\n> the same time in many cases because of that.\n> \n\nI think we should find a way to make this work. Like it or not, this\nwill garner -1\'s by people for stylistic reasons and I\'d rather it be\nthe bots than the humans do it.\n\nThe algorithm is something like this pseudo python:\n\nfor block in import_blocks:\n    if is_this_set_in_a_known_lib_collection(block):\n        continue\n    if is_this_set_entirely_local(block):\n        continue\n    if is_this_set_entirely_installed_libs(block):\n        continue\n    raise AnError(block)\n\nAnd just make the python2 and python3 stdlibs both be a match. Basically\nI\'m saying, let\'s just be more forgiving but keep the check so we can\navoid most of the \"-1 please group libs and stdlibs separately\" patches.\n\n\n','<53A4786B.1010502@dague.net>',NULL),('<1403360261-sup-9904@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-21 07:36:29',-25200,'2014-06-21 14:36:29',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Sean Dague\'s message of 2014-06-21 05:08:01 -0700:\n> On 06/20/2014 09:26 PM, Clint Byrum wrote:\n> > Excerpts from Sean Dague\'s message of 2014-06-20 11:07:39 -0700:\n> >>\n> >> H803 - First line of a commit message must *not* end in a period. This\n> >> was mostly a response to an unreasonable core reviewer that was -1ing\n> >> people for not having periods. I think any core reviewer that -1s for\n> >> this either way should be thrown off the island, or at least made fun\n> >> of, a lot. Again, the clarity of a commit message is not made or lost by\n> >> the lack or existence of a period at the end of the first line.\n> >>\n> > \n> > Perhaps we can make a bot that writes disparaging remarks on any -1\'s\n> > that mention \"period\" in the line after the short commit message. :)\n> > \n\n[For the reader: read the comments below, and then come back to this]\n\nNote that I\'m not at all unaware of the irony I created by making the\nstatement above and then the statements below. I feel like I\'m a Fox\nNews reporter being called out on the daily show actually. ;)\n\n> >> H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty,\n> >> our tree. This biggest issue here is it\'s built in a world where there\n> >> was only 1 viable python version, 2.7. Python\'s stdlib is actually\n> >> pretty dynamic and grows over time. As we embrace more python 3, and as\n> >> distros start to make python3 be front and center, what does this even\n> >> mean? The current enforcement can\'t pass on both python2 and python3 at\n> >> the same time in many cases because of that.\n> >>\n> > \n> > I think we should find a way to make this work. Like it or not, this\n> > will garner -1\'s by people for stylistic reasons and I\'d rather it be\n> > the bots than the humans do it.\n> > \n> > The algorithm is something like this pseudo python:\n> > \n> > for block in import_blocks:\n> >     if is_this_set_in_a_known_lib_collection(block):\n> >         continue\n> >     if is_this_set_entirely_local(block):\n> >         continue\n> >     if is_this_set_entirely_installed_libs(block):\n> >         continue\n> >     raise AnError(block)\n> > \n> > And just make the python2 and python3 stdlibs both be a match. Basically\n> > I\'m saying, let\'s just be more forgiving but keep the check so we can\n> > avoid most of the \"-1 please group libs and stdlibs separately\" patches.\n> \n> You can avoid that by yelling at reviewers if that\'s the *only* feedback\n> they are giving.\n> \n\nI totally agree we can do that.\n\n> Pedantic reviewers that are reviewing for this kind of thing only should\n> be scorned. I realistically like the idea markmc came up with -\n> https://twitter.com/markmc_/status/480073387600269312\n>\n\nI also agree it is really fun to think about shaming those annoying\nactions. It is also not fun _at all_ to be publicly shamed. In fact I\'d\nsay it is at least an order of magnitude less fun. There is an old saying,\n\"praise in public, punish in private.\" It is one reason the -1 comments I\ngive always include praise for whatever is right for new contributors. Not\neveryone is a grizzled veteran.\n\nIt is far more interesting to me to solve the grouping problem in a\nway that works for us long term (python 2 and 3) than it is to develop\na culture that builds any of its core activities on negative emotional\nfeedback.\n\nThat\'s not to say we can\'t say \"hey you\'re doing it wrong.\" I mean to say\nthat direct feedback like that belongs in private IRC messages or email,\nnot in public \"everyone can see that\" reviews. Give people a chance to\nsave face. Meanwhile, the less we have to have one on one negative\nfeedback, the easier the job of reviewers is.\n\nThe last thing we want to do is have more reasons for people to NOT do\nreviews.\n\n> I no longer buy the theory that something like this is saving time. What\n> it\'s actually doing is training a new generation of reviewers that the\n> right thing to do it review for nits. That\'s not actually what we want,\n> we want people reviewing for how this could go wrong.\n> \n\nI\'m not sure how hacking is training reviewers. I feel like hacking is\ntraining developers. Reviewers don\'t even need to look at it until the\npep8 tox job passes.\n\n> It\'s really instructive to realize that we\'ve definitely gone beyond\n> shared culture with what\'s in hacking. Look at how much of it is turned\n> off in projects. It\'s pretty high. If this project is going to remain\n> useful at all it really needs to prune back to what\'s actually shared\n> culture.\n>\n\nI think having things turned off at the project level is o-k. The more\nstrict a project\'s automated style rules, the less they have to quibble\nand train new reviewers on the fact that \"we don\'t do that here.\"\n\nHowever, I don\'t think rules being turned off is evidence that rules\nare unhelpful. It most likely means that those rules didn\'t exist when\nthe code base was created and they turned them off because of incubation\nor a new set of rules arrived and they didn\'t have time to land the new\npatches. That is a per-project choice and should remain so, but I don\'t\nthink that choice means that those rules wouldn\'t have a long term\npositive effect of stopping style -1 noise from overwhelming the review\nsignal. We simply cannot measure the effect each rule has since they\nstop things from passing on the developer machine.\n\nAnyway, I agree with you that we should be doing what we can to foster\npositive energy into OpenStack. I think we just have different ideas on\nhow that happens.\n\n\n','<53A575A1.9070104@dague.net>',NULL),('<1403422769.14669.35.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-22 08:39:29',3600,'2014-06-22 07:39:29',NULL,'[openstack-dev] [hacking] rules for removal','On Sat, 2014-06-21 at 07:36 -0700, Clint Byrum wrote:\n> Excerpts from Sean Dague\'s message of 2014-06-21 05:08:01 -0700:\n\n> > Pedantic reviewers that are reviewing for this kind of thing only should\n> > be scorned. I realistically like the idea markmc came up with -\n> > https://twitter.com/markmc_/status/480073387600269312\n> >\n> \n> I also agree it is really fun to think about shaming those annoying\n> actions. It is also not fun _at all_ to be publicly shamed. In fact I\'d\n> say it is at least an order of magnitude less fun. There is an old saying,\n> \"praise in public, punish in private.\" It is one reason the -1 comments I\n> give always include praise for whatever is right for new contributors. Not\n> everyone is a grizzled veteran.\n> \n> It is far more interesting to me to solve the grouping problem in a\n> way that works for us long term (python 2 and 3) than it is to develop\n> a culture that builds any of its core activities on negative emotional\n> feedback.\n> \n> That\'s not to say we can\'t say \"hey you\'re doing it wrong.\" I mean to say\n> that direct feedback like that belongs in private IRC messages or email,\n> not in public \"everyone can see that\" reviews. Give people a chance to\n> save face. Meanwhile, the less we have to have one on one negative\n> feedback, the easier the job of reviewers is.\n> \n> The last thing we want to do is have more reasons for people to NOT do\n> reviews.\n\nYou\'re right that something like I suggested could easily lead to more\nnegative energy in the project, not less.\n\nWhat I had in mind was that we could laugh at ourselves about this.\nAssuming that the reviewers called out would be fully on-board and\nwilling to laugh along at being the most pedantic nerd of the week.\n\nYeah, that\'s probably wishful thinking. Maybe it could be anonymous.\nMaybe instead it could be a weekly mailing list discussion so that we\ncould all discuss as a community whether that kind of feedback on a\nreview is appropriate.\n\nThe main point is that this is something worth addressing as a wider\ncommunity rather than in individual reviews with a limited audience. And\nthat doing it with a bit of humor might help take the sting out of it.\n\nMark.\n\n\n\n','<1403360261-sup-9904@fewbar.com>',NULL),('<1403462334.1770.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-22 18:38:17',0,'2014-06-22 18:38:17',NULL,'[openstack-dev] [Octavia] PTL and core team members','I\'m thinking we are going to need more than 2 on the core team at first\nbut it is hard to tell exactly how many people will be contributing code\nat first.  I know we\'ve got a lot of interested parties and the\npossibility that some 10+ people are actively contributing.  Of course,\nthese things can only be predicted and will be unknown until it is\nactually known.\n\nAlso, we really need to have a good plan of action.  Once we get a\nconsensus on the design we should start breaking the implementation up\ninto umbrella blueprint specs (or epic blueprint specs) with each one\ndetailing the bigger picture and breaking up the bigger picture into\nsmaller tasks/stories that can be accomplished.  Then people can start\nchoosing which they would like to implement.  Sounds good in theory, but\nactually executing it will be the tough part.\n\nThanks,\nBrandon\n\nOn Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote:\n> On 20/06/14 07:29 +0100, Mark McLoughlin wrote:\n> >On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:\n> >> Dolph,\n> >>\n> >>\n> >> I appreciate the suggestion. In the mean time how does the review\n> >> process work without core developers to approve gerrit submissions?\n> >\n> >If you\'re just getting started, have a small number (possibly just 1 to\n> >begin with) of developers collaborate closely, with the minimum possible\n> >process and then use that list of developers as your core review team\n> >when you gradually start adopting some process. Aim to get from zero to\n> >bootstrapped with that core team in a small number of weeks at most.\n> >\n> >Minimum possible process could mean a git repo anywhere that those\n> >initial developers have direct push access to. You could use stackforge\n> >from the beginning and the developers just approve their own changes,\n> >but that\'s a bit annoying.\n> \n> +1 this is how we did it in Marconi (except for the repo with push\n> access). At the beginning, we kept a core team of 2 developers despite\n> there being at least 4 ppl working on the project. This allowed the\n> team to have better discussions on what got in the repo and what not.\n> \n> One benefit of using stackforge is that you get a great CI system to\n> test your project with but the development will slow down for sure. We\n> started on stackforge right away, then had a 2 days hackathon on a\n> github fork which was not a good idea because we had to submit al\n> those patches for review after the hackathon. :(\n> \n> Flavio\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20140622114253.GD8498@redhat.com>',NULL),('<1403542468.3377.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 16:54:24',0,'2014-06-23 16:54:24',NULL,'[openstack-dev] Should TLS settings for listener be set through\n separate API/model?','Vijay,\nI think the separate entity is still going to happen.  I don\'t think it\nhas remvoed.  Or that is may just be my assumption.\n\nThanks,\nBrandon\n\nOn Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:\n> Hi:\n> \n>  \n> In the ?LBaaS TLS termination capability specification? proposal \n>  \n> https://review.openstack.org/#/c/98640/\n>  \n> TLS settings like default certificate container id and SNI cert list are part of the listener properties. \n>  \n> I think it is better to have this as a separate entity so that the listener properties are clean and is not ?corrupted? with TLS settings.\n>  \n> I liked the original SSL proposal better where TLS settings was a separate entity.\n>  \n> It is just 2 properties now but in future the TLS settings would grow and if we are going to introduce a TLS profile/params/settings entity later, it is better to do it now (albeit with min properties).\n>  \n> Thanks,\n> Vijay V.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<26B082831A2B1A4783604AB89B9B2C080E0376B8@SINPEX01CL03.citrite.net>',NULL),('<1403543973-sup-3740@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 10:26:31',-25200,'2014-06-23 17:26:31',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Mark McLoughlin\'s message of 2014-06-22 00:39:29 -0700:\n> The main point is that this is something worth addressing as a wider\n> community rather than in individual reviews with a limited audience. And\n> that doing it with a bit of humor might help take the sting out of it.\n> \n\nYes, a private message saying \"Hey fellow earthling, do we really care\nwhether httplib is grouped with os or eventlet?\" is a productive thing\nindeed! However, turning that into something that we can all publicly\nlaugh about requires some real skill, and trust between us all. Given\nour digital communication mediums, it is not likely we can do it all\nthat regularly. I think at best we could gather them all into a couple\nof keynote slides with the authors\' blessings (oh please, somebody do\nthis!)\n\nHowever, if we can all look inward and just do it with self deprecation\nI\'m all for it.\n\nThe main point I am making is that the less grey areas we have, the less\nof this we ever have to worry about. It is worth it, to me, to look into\nkeeping this rule alive so that we never ever have to discuss import\ngrouping.\n\n(BTW, how many release cycles does one have to deprecate themselves\nbefore they remove themselves?)\n\n\n','<1403422769.14669.35.camel@sorcha>',NULL),('<1403544458-sup-4986@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 10:28:42',-25200,'2014-06-23 17:28:42',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Christopher Yeoh\'s message of 2014-06-22 18:46:59 -0700:\n> On Mon, Jun 23, 2014 at 4:43 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On 06/22/2014 09:41 AM, Amrith Kumar wrote:\n> >\n> >> In addition to making changes to the hacking rules, why don\'t we mandate\n> >> also\n> >> that perceived problems in the commit message shall not be an acceptable\n> >> reason to -1 a change.\n> >>\n> >> Would this improve the situation?\n> >>\n> >\n> > I actually *do* think a very poor commit message for a substantial patch\n> > deserves a -1. The git commit message is our history for the patch, and it\n> > is important in its own right. Now, nits like a single misspelled word or\n> > the commit summary being 60 characters instead of 50 are not what I\'m\n> > talking about, of course.\n> >\n> > I\'m speaking only about when a commit message blatantly disregards the\n> > best practices of commit message writing [1] and doesn\'t offer anything of\n> > value to the reviewer.\n> >\n> >\n> +1.\n> \n> Minor typos and grammatical errors I don\'t  care about (but will put in\n> suggested fixes if the patch needs to be updated anyway). However, commit\n> messages are very important for future debugging. One or two line vague\n> commit messages can make life a lot harder for others in the future when\n> writing a short description is not what I\'d consider an excessive burden.\n> And there should be no assumption that the person reading the commit\n> message will have easy access to the bug database.\n> \n\nWe\'ve had this discussion already, but just remember that not everybody\nreading those commit messages will be a native English speaker. The more\nincorrect the grammar and punctuation is, the more confusing it will be\nto somebody who is already struggling with those concepts.\n\n\n','<CANCY3edvr7PQE6_yBUWn3ku=n9gg7yJEedt73UR8PprhFvRsjg@mail.gmail.com>',NULL),('<1403551376.29185.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 19:22:56',0,'2014-06-23 19:22:56',NULL,'[openstack-dev]  [blazar] Blazar Nova renaming patches','I finished the Blazar-Nova renaming. The only thing left is to update\noslo with the new name, but I\'ll do that when the rename patches land to\nmaster. So, cores please give your blessing to this patches:\nhttps://review.openstack.org/98496, https://review.openstack.org/100914,\nhttps://review.openstack.org/101953\n\nPablo.\n\n',NULL,NULL),('<1403557408.29185.6.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 21:03:27',0,'2014-06-23 21:03:27',NULL,'[openstack-dev]  [blazar] trust_id critical bug','Blazar cores,\n	Please check https://review.openstack.org/#/c/102004/\n	It fixes https://launchpad.net/bugs/1333413\n	I found the bug using our tempest test suite ;) (I\'m trying to get that\ntempest suite as a gate job)\n\nThanks.\n\nPablo.\n\n',NULL,NULL),('<1403557813.3419.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 21:10:05',0,'2014-06-23 21:10:05',NULL,'[openstack-dev] Should TLS settings for listener be set through\n separate API/model?','Okay so we\'ve talked a bit about this in IRC and now I\'m sending this\nout as an update.  Here are the options with pros and cons that have\ncome from that discussion.\n\n1) default_certificate_id is an attribute of the Listener object.\n\nPros:\n-No extra entity needed\n\nCons:\n-May bloat Listener object when more attributes are needed for only TLS\ntermination.  Sounds like TLS version and cipher selection will be\nneeded attributes in the future.\n\n\n2) A separate TLS Entity is created that is referenced by the Listener\nobject.  This entity at first may only contain a certificate_id that\nreferences barbican.  Name and description can be allowed as well.\n\nPros:\n-TLS domain specific attributes contained in its own entity\n-Future attributes would just be added to this entity and not bloat the\nListener object.\n\nCons:\n-It\'s another entity\n\nIn IRC we (sbalukoff, myself) seemed to agree option 2 is right way to\ngo.  Anyone agree or disagree?\n\nThanks,\nBrandon\n\nOn Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:\n> The separate entity makes sense for certificates participating in an\n> SNI configuration, but probably not so much for the \'default\'\n> certificate used when TLS is being terminated.\n> \n> \n> Vijay: You\'re also right that other TLS-related attributes will\n> probably get added to the Listener object. This probably makes sense\n> if they apply to the Listener object as a whole. (This includes things\n> like TLS version and cipher selection.)\n> \n> \n> I don\'t see much of a point in creating a separate object to contain\n> these fields, since it would have a 1:1 relationship with the\n> Listener. It\'s true that for non-TLS-terminated Listeners, these\n> fields wouldn\'t be used, but isn\'t that already the case in many other\n> objects (not just in the Neutron LBaaS sub project)?\n> \n> \n> Thanks,\n> Stephen\n> \n> \n> \n> \n> \n> \n> On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Vijay,\n>         I think the separate entity is still going to happen.  I don\'t\n>         think it\n>         has remvoed.  Or that is may just be my assumption.\n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:\n>         > Hi:\n>         >\n>         >\n>         > In the ?LBaaS TLS termination capability specification?\n>         proposal\n>         >\n>         > https://review.openstack.org/#/c/98640/\n>         >\n>         > TLS settings like default certificate container id and SNI\n>         cert list are part of the listener properties.\n>         >\n>         > I think it is better to have this as a separate entity so\n>         that the listener properties are clean and is not ?corrupted?\n>         with TLS settings.\n>         >\n>         > I liked the original SSL proposal better where TLS settings\n>         was a separate entity.\n>         >\n>         > It is just 2 properties now but in future the TLS settings\n>         would grow and if we are going to introduce a TLS\n>         profile/params/settings entity later, it is better to do it\n>         now (albeit with min properties).\n>         >\n>         > Thanks,\n>         > Vijay V.\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+Zre4VwGac8FsHRqjziqBZ+hhjtGgaxoAG7ES9wY0T3=1A@mail.gmail.com>',NULL),('<1403563134.3419.8.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 22:38:47',0,'2014-06-23 22:38:47',NULL,'[openstack-dev] [Neutron][LBaaS] Should TLS settings for\n listener be set through separate API/model?','Whoops, [Neutron][LBaaS] got taken out of the subject line here.\nPutting it back in.\n\nOn Mon, 2014-06-23 at 21:10 +0000, Brandon Logan wrote:\n> Okay so we\'ve talked a bit about this in IRC and now I\'m sending this\n> out as an update.  Here are the options with pros and cons that have\n> come from that discussion.\n> \n> 1) default_certificate_id is an attribute of the Listener object.\n> \n> Pros:\n> -No extra entity needed\n> \n> Cons:\n> -May bloat Listener object when more attributes are needed for only TLS\n> termination.  Sounds like TLS version and cipher selection will be\n> needed attributes in the future.\n> \n> \n> 2) A separate TLS Entity is created that is referenced by the Listener\n> object.  This entity at first may only contain a certificate_id that\n> references barbican.  Name and description can be allowed as well.\n> \n> Pros:\n> -TLS domain specific attributes contained in its own entity\n> -Future attributes would just be added to this entity and not bloat the\n> Listener object.\n> \n> Cons:\n> -It\'s another entity\n> \n> In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to\n> go.  Anyone agree or disagree?\n> \n> Thanks,\n> Brandon\n> \n> On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:\n> > The separate entity makes sense for certificates participating in an\n> > SNI configuration, but probably not so much for the \'default\'\n> > certificate used when TLS is being terminated.\n> > \n> > \n> > Vijay: You\'re also right that other TLS-related attributes will\n> > probably get added to the Listener object. This probably makes sense\n> > if they apply to the Listener object as a whole. (This includes things\n> > like TLS version and cipher selection.)\n> > \n> > \n> > I don\'t see much of a point in creating a separate object to contain\n> > these fields, since it would have a 1:1 relationship with the\n> > Listener. It\'s true that for non-TLS-terminated Listeners, these\n> > fields wouldn\'t be used, but isn\'t that already the case in many other\n> > objects (not just in the Neutron LBaaS sub project)?\n> > \n> > \n> > Thanks,\n> > Stephen\n> > \n> > \n> > \n> > \n> > \n> > \n> > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan\n> > <brandon.logan at rackspace.com> wrote:\n> >         Vijay,\n> >         I think the separate entity is still going to happen.  I don\'t\n> >         think it\n> >         has remvoed.  Or that is may just be my assumption.\n> >         \n> >         Thanks,\n> >         Brandon\n> >         \n> >         On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:\n> >         > Hi:\n> >         >\n> >         >\n> >         > In the ?LBaaS TLS termination capability specification?\n> >         proposal\n> >         >\n> >         > https://review.openstack.org/#/c/98640/\n> >         >\n> >         > TLS settings like default certificate container id and SNI\n> >         cert list are part of the listener properties.\n> >         >\n> >         > I think it is better to have this as a separate entity so\n> >         that the listener properties are clean and is not ?corrupted?\n> >         with TLS settings.\n> >         >\n> >         > I liked the original SSL proposal better where TLS settings\n> >         was a separate entity.\n> >         >\n> >         > It is just 2 properties now but in future the TLS settings\n> >         would grow and if we are going to introduce a TLS\n> >         profile/params/settings entity later, it is better to do it\n> >         now (albeit with min properties).\n> >         >\n> >         > Thanks,\n> >         > Vijay V.\n> >         \n> >         > _______________________________________________\n> >         > OpenStack-dev mailing list\n> >         > OpenStack-dev at lists.openstack.org\n> >         >\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > -- \n> > Stephen Balukoff \n> > Blue Box Group, LLC \n> > (800)613-4305 x807\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1403557813.3419.7.camel@localhost>',NULL),('<1403565802-sup-9419@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 16:25:28',-25200,'2014-06-23 23:25:28',NULL,'[openstack-dev] [Ceilometer] [Heat] Ceilometer aware people,\n	please advise us on processing notifications..','Hello! I would like to turn your attention to this specification draft\nthat I\'ve written:\n\nhttps://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst\n\nAngus has suggested that perhaps Ceilometer is a better place to handle\nthis. Can you please comment on the review, or can we have a brief\nmailing list discussion about how best to filter notifications?\n\nBasically in Heat when a user boots an instance, we would like to act as\nsoon as it is active, and not have to poll the nova API to know when\nthat is. Angus has suggested that perhaps we can just tell ceilometer to\nhit Heat with a web hook when that happens.\n\nThanks!\n\n\n',NULL,NULL),('<1403566335-sup-7092@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-23 16:36:26',-25200,'2014-06-23 23:36:26',NULL,'[Openstack-operators] [openstack][openstack-operators] Mysql\n	5.5 to 5.6','Excerpts from Belmiro Moreira\'s message of 2014-06-23 03:21:14 -0700:\n> Hi,\n> all our OpenStack databases are running on mysql 5.5.30 and we plan upgrade\n> to 5.6.17 soon.\n> Should we expect any issue moving to 5.6?\n\nHeat has one known bug regarding MySQL 5.6:\n\nhttps://bugs.launchpad.net/heat/+bug/1316646\n\nThere are patches up and that is a good candidate for backport to\nicehouse.\n\n> I believe in gate 5.6 is still not used. Please correct me if I\'m wrong.\n> \n\nCorrect. The gate likely won\'t test 5.6 unless either operators demand\nit, or a distro ships 5.6.\n\n> Profiling we see some performance decrease using 5.6 (we believe it\'s\n> related with the cache) but\n\nThat is surprising as 5.6 has some impressive optimizer improvements\nand a few minor improvements to InnoDB. I\'m not aware of any changes to\n\"the cache\".\n\n\n','<CAPkQhncjZTddLCAZJGy7oCussY6zkCNRHg8Y_q1SaXcZyKLPHw@mail.gmail.com>',NULL),('<1403573277.2.1376632895855.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-16 06:01:35',0,'2013-08-16 06:01:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #4','See <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/4/>\n\n------------------------------------------\n[...truncated 187 lines...]\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.h5Ilk60TdJ/easy_install-EaWhPo/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.h5Ilk60TdJ/easy_install-EaWhPo/d2to1-0.2.10/egg-dist-tmp-pZwg6Y\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-glanceclient/d2to1-0.2.10-py2.6.egg>\n    [pbr] Processing SOURCES.txt\n    warning: LocalManifestMaker: standard file \'-c\' not found\n    [pbr] In git context, generating filelist from git\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.6.10 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 14))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-novaclient/pbr-0.5.21-py2.6.egg>\n    [pbr] Processing SOURCES.txt\n    warning: LocalManifestMaker: standard file \'-c\' not found\n    [pbr] In git context, generating filelist from git\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-keystoneclient>=0.2.3 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 15))\n  Running setup.py egg_info for package python-keystoneclient\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.21-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading https://pypi.python.org/simple/d2to1/\n    Best match: d2to1 0.2.10\n    Downloading https://pypi.python.org/packages/source/d/d2to1/d2to1-0.2.10.tar.gz#md5=be97f5330bae3206e1555b58dae23848\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.h5Ilk60TdJ/easy_install-_Elm6_/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.h5Ilk60TdJ/easy_install-_Elm6_/d2to1-0.2.10/egg-dist-tmp-_12PNL\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    [pbr] Processing SOURCES.txt\n    warning: LocalManifestMaker: standard file \'-c\' not found\n    [pbr] In git context, generating filelist from git\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 16))\n  Running setup.py egg_info for package python-swiftclient\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/pbr-0.5.21-py2.6.egg>\n    Searching for d2to1\n    Reading https://pypi.python.org/simple/d2to1/\n    Best match: d2to1 0.2.10\n    Downloading https://pypi.python.org/packages/source/d/d2to1/d2to1-0.2.10.tar.gz#md5=be97f5330bae3206e1555b58dae23848\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.h5Ilk60TdJ/easy_install-9eFrlY/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.h5Ilk60TdJ/easy_install-9eFrlY/d2to1-0.2.10/egg-dist-tmp-vorHPF\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    [pbr] Processing SOURCES.txt\n    warning: LocalManifestMaker: standard file \'-c\' not found\n    [pbr] In git context, generating filelist from git\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking lxml (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 17))\n  Running setup.py egg_info for package lxml\n    /usr/lib64/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'bugtrack_url\'\n      warnings.warn(msg)\n    Building lxml version 3.2.3.\n    Building without Cython.\n    Using build configuration of libxslt 1.1.26\n    Building against libxml2/libxslt in the following directory: /usr/lib64\n    warning: no previously-included files found matching \'*.py\'\n    warning: no files found matching \'*.txt\' under directory \'src/lxml/tests\'\nDownloading/unpacking requests>=1.1 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 18))\n  Running setup.py egg_info for package requests\nDownloading/unpacking extras (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 19))\n  Downloading extras-0.0.3.tar.gz\n  Running setup.py egg_info for package extras\nDownloading/unpacking wsme>=0.5b1 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 20))\n  Running setup.py egg_info for package wsme\n    \n    Installed <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/build/wsme/d2to1-0.2.10-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*.ini\' under directory \'tests\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pyyaml (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 21))\n  Running setup.py egg_info for package pyyaml\nDownloading/unpacking oslo.config>=1.1.0 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 22))\n  Running setup.py egg_info for package oslo.config\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking happybase>=0.4 (from -r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires> (line 23))\n  Running setup.py egg_info for package happybase\nDownloading/unpacking Cheetah>=2.4.4 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package Cheetah\n    warning: no files found matching \'examples\'\n    warning: no files found matching \'docs\'\n    warning: no files found matching \'bin\'\n    warning: no files found matching \'*\' under directory \'docs\'\n    warning: no files found matching \'*\' under directory \'examples\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'docs\'\nDownloading/unpacking amqplib>=0.6.1 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package amqplib\nDownloading/unpacking boto (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package boto\n    warning: no files found matching \'boto/mturk/test/*.doctest\'\n    warning: no files found matching \'boto/mturk/test/.gitignore\'\nDownloading/unpacking routes>=1.12.3 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package routes\n    warning: no previously-included files matching \'.DS_Store\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgignore\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgtags\' found anywhere in distribution\nDownloading/unpacking greenlet>=0.3.1 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package greenlet\nDownloading/unpacking PasteDeploy>=1.5.0 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Downloading PasteDeploy-1.5.0.tar.gz\n  Running setup.py egg_info for package PasteDeploy\nDownloading/unpacking paste (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package paste\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build/_sources\'\nDownloading/unpacking netaddr>=0.7.6 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Could not find a version that satisfies the requirement netaddr>=0.7.6 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11)) (from versions: 0.7.1, 0.6.3, 0.6.2, 0.7.3, 0.7.3, 0.5, 0.6, 0.4, 0.6.4, 0.7.2, 0.6.1, 0.7.2, 0.5.1, 0.6.1, 0.6, 0.6.4, 0.5.2, 0.3.1, 0.7.1, 0.6.3, 0.5, 0.6.2, 0.3.1, 0.7, 0.7, 0.5.1, 0.4, 0.5.2, 0.7.4, 0.7.4, 0.7.3, 0.7.3, 0.7.2, 0.7.2, 0.7.1, 0.7.1, 0.7, 0.7, 0.6.4, 0.6.4, 0.6.3, 0.6.3, 0.6.2, 0.6.2, 0.6.1, 0.6.1, 0.6, 0.6, 0.5.2, 0.5.2, 0.5.1, 0.5.1, 0.5, 0.5, 0.4, 0.4, 0.3.1, 0.3.1, 0.3, 0.3, 0.2, 0.1)\nCleaning up...\nNo distributions matching the version for netaddr>=0.7.6 (from nova==2013.1->-r <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\nStoring complete log in <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/tmp/pseudo-home/.pip/pip.log>\n\nERROR: could not install deps [-r<https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.h5Ilk60TdJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/centos6-5/4\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1403599755412.41070@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-24 08:42:56',0,'2014-06-24 08:42:56',NULL,'[Openstack] How can I enable operation for non-admin user','\nHi Li,\n\nAs fas as I know to migrate an instance you\'ll need admin priviliges.\nBut if you want to allow this operation for normal user then might try editing /etc/nova/policy.json file and give privileges.\n\nFile: /etc/nova/policy.json\nchange \"compute_extension:admin_actions:migrate\": \"rule:admin_api\" to\n\"compute_extension:admin_actions:migrate\": \"rule:admin_or_owner\"\n\n\nRegards,\nSushma\n\n\n\n________________________________\nFrom: Li, Chen <chen.li at intel.com>\nSent: Tuesday, June 24, 2014 1:44 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] How can I enable operation for non-admin user\n\nHi list,\n\nI\'m working under CentOS + icehouse.\n\nWhile, I have an non-admin user \"demo\", and I can work under this this user with basic operations.\nEverything works well.\n\nBut, I also hope this user can do some admin operations, such as migrate and so on, because currently when I run command:\nnova migrate ${my_instance}\nI get output:\nERROR: Policy doesn\'t allow compute_extension:admin_actions:migrate to be performed. (HTTP 403) (Request-ID: req-698ad5b5-f1fe-48fc-b81f-a765020bf89f)\n\nAnyone can help me ?\n\nThanks.\n-chen\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140624/e114ed91/attachment.html>\n\n','<988E98D31B01E44893AF6E48ED9DEFD401B3FC13@SHSMSX101.ccr.corp.intel.com>',NULL),('<1403603355.3652.14.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 10:49:15',3600,'2014-06-24 09:49:15',NULL,'[openstack-dev] [hacking] community consensus and removing rules','On Mon, 2014-06-23 at 19:55 -0700, Joe Gordon wrote:\n\n>       * Add a new directory, contrib, for local rules that multiple\n>         projects use but are not generally considered acceptable to be\n>         enabled by default. This way we can reduce the amount of cut\n>         and pasted code (thank you to Ben Nemec for this idea).\n\nAll sounds good to me, apart from a pet peeve on \'contrib\' directories.\n\nWhat does \'contrib\' mean? \'contributed\'? What exactly *isn\'t*\ncontributed? Often it has connotations of \'contributed by outsiders\'.\n\nIt also often has connotations of \'bucket for crap\', \'unmaintained and\nuntested\', YMMV, etc. etc.\n\nOften the name is just chosen out of laziness - \"I can\'t think of a good\nname for this, and projects often have a contrib directory with random\nstuff in it, so that works\".\n\nLet\'s be precise - these are optional rules, right? How about calling\nthe directory \'optional\'?\n\nSay no to contrib directories! :-P\n\nThanks,\nMark.\n\n\n\n\n','<CAHXdxOdLYKEhjmv7NieurYS45-V3XqXGYLCowxmN=B7xw_RFZw@mail.gmail.com>',NULL),('<1403619130.3930.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 14:12:09',0,'2014-06-24 14:12:09',NULL,'[openstack-dev] [blazar] Blazar client V2 REST API support and\n Horizon integration','Blazar cores,\n	I managed to get our client working against our V2 REST API and I\nimplemented the first bits of our Blazar Dashboard for Horizon. In order\nto continue working on the last, I need this patches on master. I\nsuggest this order:\n	https://review.openstack.org/#/c/99389/ (V2 REST API)\n	https://review.openstack.org/#/c/93047/ (V2 REST API)\n	https://review.openstack.org/#/c/91455/ (V2 REST API)\n	https://review.openstack.org/#/c/100661/ (Blazar Dashboard)\n	https://review.openstack.org/#/c/100662/ (Blazar Dashboard)\n\n	Please take into account that the three V2 REST API patches must be\nmerged in order to get all working without failures.\n\nThanks.\nPablo.\n\n',NULL,NULL),('<1403619897.30.1372486459213.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-29 06:14:19',0,'2013-06-29 06:14:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #80','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/80/>\n\n------------------------------------------\n[...truncated 1162 lines...]\n    test_image_set_data                                          OK    0.00\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_respawn\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 166, in test_respawn\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib64/python2.6/unittest.py\", line 324, in failUnless\n    if not expr: raise self.failureException, msg\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.91 secs:\n    26.67    TestScrubber.test_scrubber_app\n    20.99    TestScrubber.test_delayed_delete\n    15.55    TestRootApi.test_version_configurations\n    15.22    TestGlanceControl.test_reload\n    14.47    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 1101 tests in 630.662s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.45\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.80\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.17\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.5\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.He8ZEuKsRQ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/80\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/80/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1403628480-sup-3081@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 09:51:43',-25200,'2014-06-24 16:51:43',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Monty Taylor\'s message of 2014-06-24 06:48:06 -0700:\n> On 06/22/2014 02:49 PM, Duncan Thomas wrote:\n> > On 22 June 2014 14:41, Amrith Kumar <amrith at tesora.com> wrote:\n> >> In addition to making changes to the hacking rules, why don\'t we mandate also\n> >> that perceived problems in the commit message shall not be an acceptable\n> >> reason to -1 a change.\n> > \n> > -1.\n> > \n> > There are some /really/ bad commit messages out there, and some of us\n> > try to use the commit messages to usefully sort through the changes\n> > (i.e. I often -1 in cinder a change only affects one driver and that\n> > isn\'t clear from the summary).\n> > \n> > If the perceived problem is grammatical, I\'m a bit more on board with\n> > it not a reason to rev a patch, but core reviewers can +2/A over the\n> > top of a -1 anyway...\n> \n> 100% agree. Spelling and grammar are rude to review on - especially\n> since we have (and want) a LOT of non-native English speakers. It\'s not\n> our job to teach people better grammar. Heck - we have people from\n> different English backgrounds with differing disagreements on what good\n> grammar _IS_\n> \n\nWe shouldn\'t quibble over _anything_ grammatical in a commit message. If\nthere is a disagreement about it, the comments should be ignored. There\nare definitely a few grammar rules that are loose and those should be\nlargely ignored.\n\nHowever, we should correct grammar when there is a clear solution, as\nthose same people who do not speak English as their first language are\nlikely to be confused by poor grammar.\n\nWe\'re not doing it to teach grammar. We\'re doing it to ensure readability.\n\n\n','<53A98196.2090101@inaugust.com>',NULL),('<1403634225.4184.10.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 18:23:31',0,'2014-06-24 18:23:31',NULL,'[openstack-dev]   [Neutron][LBaaS] Which entities need status','I think we missed this discussion at the meet-up but I\'d like to bring\nit up here.  To me having a status on all entities doesn\'t make much\nsense, and justing having a status on a load balancer (which would be a\nprovisioning status) and a status on a member (which would be an\noperational status) are what makes sense because:\n\n1) If an entity exists without a link to a load balancer it is purely\njust a database entry, so it would always be ACTIVE, but not really\nactive in a technical sense.\n\n2) If some of these entities become shareable then how does the status\nreflect that the entity failed to create on one load balancer but was\nsuccessfully created on another.  That logic could get overly complex.\n\nI think the best thing to do is to have the load balancer status reflect\nthe provisioning status of all of its children.  So if a health monitor\nis updated then the load balancer that health monitor is linked to would\nhave its status changed to PENDING_UPDATE.  Conversely, if a load\nbalancer or any entities linked to it are changed and the load\nbalancer\'s status is in a non-ACTIVE state then that update should not\nbe allowed.\n\nThoughts?\n\nThanks,\nBrandon\n\n\n\n','<4AEC9B284F662E4DBF9A2E74579CC758A8B6F23D@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1403637378.4184.20.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 19:16:04',0,'2014-06-24 19:16:04',NULL,'[openstack-dev] [Neutron][LBaaS] Which entities need status','On Tue, 2014-06-24 at 18:53 +0000, Doug Wiegley wrote:\n> Hi Brandon,\n> \n> I think just one status is overloading too much onto the LB object (which\n> is perhaps something that a UI should do for a user, but not something an\n> API should be doing.)\n\nThat is a good point and perhaps its another discussion to just have\nsome way to show the status an entity has for each load balancer, which\nis what mark suggested for the member status at the meet-up.\n\n> \n> > 1) If an entity exists without a link to a load balancer it is purely\n> > just a database entry, so it would always be ACTIVE, but not really\n> > active in a technical sense.\n> \n> Depends on the driver.  I don?t think this is a decision for lbaas proper.\n\nDriver is linked to the flavor or provider.  Flavor or provider will/is\nlinked to load balancer.  We won\'t be able get a driver to send anything\nto if there isn\'t a load balancer.  Without a driver it is a decision\nfor lbaas proper.  I\'d be fine with setting the status of these\n\"orphaned\" entities to just ACTIVE but I\'m just worried about the status\nmanagement in the future.\n\n> \n> \n> > 2) If some of these entities become shareable then how does the status\n> > reflect that the entity failed to create on one load balancer but was\n> > successfully created on another.  That logic could get overly complex.\n> \n> That?s a status on the join link, not the object, and I could argue\n> multiple ways in which that should be one way or another based on the\n> backend, which to me, again implies driver question (backend could queue\n> for later, or error immediately, or let things run degraded, or?)\n\nYeah that is definitely an argument.  I\'m just trying to keep in mind\nthe complexities that could arise from decisions made now.  Perhaps it\nis the wrong way to look at it to some, but I don\'t think thinking about\nthe future is a bad thing and should never be done.\n\n> \n> Thanks,\n> Doug\n> \n> \n> \n> \n> On 6/24/14, 11:23 AM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM> wrote:\n> \n> >I think we missed this discussion at the meet-up but I\'d like to bring\n> >it up here.  To me having a status on all entities doesn\'t make much\n> >sense, and justing having a status on a load balancer (which would be a\n> >provisioning status) and a status on a member (which would be an\n> >operational status) are what makes sense because:\n> >\n> >1) If an entity exists without a link to a load balancer it is purely\n> >just a database entry, so it would always be ACTIVE, but not really\n> >active in a technical sense.\n> >\n> >2) If some of these entities become shareable then how does the status\n> >reflect that the entity failed to create on one load balancer but was\n> >successfully created on another.  That logic could get overly complex.\n> >\n> >I think the best thing to do is to have the load balancer status reflect\n> >the provisioning status of all of its children.  So if a health monitor\n> >is updated then the load balancer that health monitor is linked to would\n> >have its status changed to PENDING_UPDATE.  Conversely, if a load\n> >balancer or any entities linked to it are changed and the load\n> >balancer\'s status is in a non-ACTIVE state then that update should not\n> >be allowed.\n> >\n> >Thoughts?\n> >\n> >Thanks,\n> >Brandon\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFCF14A3.364A%dougw@a10networks.com>',NULL),('<1403638263.4184.24.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 19:30:49',0,'2014-06-24 19:30:49',NULL,'[openstack-dev] [Neutron][LBaaS] Which entities need status','Eugene,\nThanks for the feedback.  I have a feeling thats where we will end up\ngoing anyway so perhaps status on all entities for now is the proper way\nto build into that.  I just want my objections to be heard.\n\nThanks,\nBrandon \n\nOn Tue, 2014-06-24 at 23:10 +0400, Eugene Nikanorov wrote:\n> Hi lbaas folks,\n> \n> \n> IMO a status is really an important part of the API.\n> In some old email threads Sam has proposed the solution for lbaas\n> objects: we need to have several attributes that independently\n> represent different types of statuses:\n> - admin_state_up\n> - operational status\n> - provisioning state\n> \n> \n> Not every status need to be on every object. \n> Pure-DB objects (like pool) should not have provisioning state and\n> operational status, instead, an association object should have them. I\n> think that resolves both questions (1) and (2).\n> If some object is shareable, then we\'ll have association object\n> anyway, and that\'s where provisioning status and operationl status can\n> reside. For sure it\'s not very simple, but this is the right way to do\n> it.\n> \n> \n> Also I\'d like to emphasize that statuses are really an API thing, not\n> a driver thing, so they must be used similarly across all drivers.\n> \n> \n> Thanks,\n> Eugene.\n> \n> \n> On Tue, Jun 24, 2014 at 10:53 PM, Doug Wiegley <dougw at a10networks.com>\n> wrote:\n>         Hi Brandon,\n>         \n>         I think just one status is overloading too much onto the LB\n>         object (which\n>         is perhaps something that a UI should do for a user, but not\n>         something an\n>         API should be doing.)\n>         \n>         > 1) If an entity exists without a link to a load balancer it\n>         is purely\n>         > just a database entry, so it would always be ACTIVE, but not\n>         really\n>         > active in a technical sense.\n>         \n>         \n>         Depends on the driver.  I don?t think this is a decision for\n>         lbaas proper.\n>         \n>         \n>         > 2) If some of these entities become shareable then how does\n>         the status\n>         > reflect that the entity failed to create on one load\n>         balancer but was\n>         > successfully created on another.  That logic could get\n>         overly complex.\n>         \n>         \n>         That?s a status on the join link, not the object, and I could\n>         argue\n>         multiple ways in which that should be one way or another based\n>         on the\n>         backend, which to me, again implies driver question (backend\n>         could queue\n>         for later, or error immediately, or let things run degraded,\n>         or?)\n>         \n>         Thanks,\n>         Doug\n>         \n>         \n>         \n>         \n>         On 6/24/14, 11:23 AM, \"Brandon Logan\"\n>         <brandon.logan at RACKSPACE.COM> wrote:\n>         \n>         >I think we missed this discussion at the meet-up but I\'d like\n>         to bring\n>         >it up here.  To me having a status on all entities doesn\'t\n>         make much\n>         >sense, and justing having a status on a load balancer (which\n>         would be a\n>         >provisioning status) and a status on a member (which would be\n>         an\n>         >operational status) are what makes sense because:\n>         >\n>         >1) If an entity exists without a link to a load balancer it\n>         is purely\n>         >just a database entry, so it would always be ACTIVE, but not\n>         really\n>         >active in a technical sense.\n>         >\n>         >2) If some of these entities become shareable then how does\n>         the status\n>         >reflect that the entity failed to create on one load balancer\n>         but was\n>         >successfully created on another.  That logic could get overly\n>         complex.\n>         >\n>         >I think the best thing to do is to have the load balancer\n>         status reflect\n>         >the provisioning status of all of its children.  So if a\n>         health monitor\n>         >is updated then the load balancer that health monitor is\n>         linked to would\n>         >have its status changed to PENDING_UPDATE.  Conversely, if a\n>         load\n>         >balancer or any entities linked to it are changed and the\n>         load\n>         >balancer\'s status is in a non-ACTIVE state then that update\n>         should not\n>         >be allowed.\n>         >\n>         >Thoughts?\n>         >\n>         >Thanks,\n>         >Brandon\n>         >\n>         >\n>         >_______________________________________________\n>         >OpenStack-dev mailing list\n>         >OpenStack-dev at lists.openstack.org\n>         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOS+tjcb8NJB4BeStbvYu=c=JMB1xvodc6oHYhufU490WA@mail.gmail.com>',NULL),('<1403639392.3652.26.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 20:49:52',3600,'2014-06-24 19:49:52',NULL,'[openstack-dev] [hacking] rules for removal','On Tue, 2014-06-24 at 09:51 -0700, Clint Byrum wrote:\n> Excerpts from Monty Taylor\'s message of 2014-06-24 06:48:06 -0700:\n> > On 06/22/2014 02:49 PM, Duncan Thomas wrote:\n> > > On 22 June 2014 14:41, Amrith Kumar <amrith at tesora.com> wrote:\n> > >> In addition to making changes to the hacking rules, why don\'t we mandate also\n> > >> that perceived problems in the commit message shall not be an acceptable\n> > >> reason to -1 a change.\n> > > \n> > > -1.\n> > > \n> > > There are some /really/ bad commit messages out there, and some of us\n> > > try to use the commit messages to usefully sort through the changes\n> > > (i.e. I often -1 in cinder a change only affects one driver and that\n> > > isn\'t clear from the summary).\n> > > \n> > > If the perceived problem is grammatical, I\'m a bit more on board with\n> > > it not a reason to rev a patch, but core reviewers can +2/A over the\n> > > top of a -1 anyway...\n> > \n> > 100% agree. Spelling and grammar are rude to review on - especially\n> > since we have (and want) a LOT of non-native English speakers. It\'s not\n> > our job to teach people better grammar. Heck - we have people from\n> > different English backgrounds with differing disagreements on what good\n> > grammar _IS_\n> > \n> \n> We shouldn\'t quibble over _anything_ grammatical in a commit message. If\n> there is a disagreement about it, the comments should be ignored. There\n> are definitely a few grammar rules that are loose and those should be\n> largely ignored.\n> \n> However, we should correct grammar when there is a clear solution, as\n> those same people who do not speak English as their first language are\n> likely to be confused by poor grammar.\n> \n> We\'re not doing it to teach grammar. We\'re doing it to ensure readability.\n\nThe importance of clear English varies with context, but commit messages\nare a place where we should try hard to just let it go, particularly\nwith those who do not speak English as their first language.\n\nCommit messages stick around forever and it\'s important that they are\nuseful, but they will be read by a small number of people who are going\nto be in a position to spend a small amount of time getting over\nwhatever dissonance is caused by a typo or imperfect grammar.\n\nI think specs are pretty similar and don\'t warrant much additional\ngrammar nitpicking. Sure, they\'re longer pieces of text and slightly\nmore people will rely on them for information, but they\'re not intended\nto be complete documentation.\n\nWhere grammar is so poor that readers would be easily misled in\nimportant ways, then sure that should be fixed. But there comes a point\nwhen we\'re no longer working to avoid confusion and instead just being\npendants. Taking issue[1] with this:\n\n  \"whatever scaling mechanism Heat and we end up going with.\"\n\nbecause it has a \"dangling preposition\" is an example of going way\nbeyond the point of productive pedantry IMHO :-)\n\nMark.\n\n[1] - https://review.openstack.org/#/c/97939/5/specs/juno/remove-mergepy.rst\n\n\n\n','<1403628480-sup-3081@fewbar.com>',NULL),('<1403642766-sup-2884@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 13:56:04',-25200,'2014-06-24 20:56:04',NULL,'[openstack-dev] [hacking] rules for removal','Excerpts from Mark McLoughlin\'s message of 2014-06-24 12:49:52 -0700:\n> On Tue, 2014-06-24 at 09:51 -0700, Clint Byrum wrote:\n> > Excerpts from Monty Taylor\'s message of 2014-06-24 06:48:06 -0700:\n> > > On 06/22/2014 02:49 PM, Duncan Thomas wrote:\n> > > > On 22 June 2014 14:41, Amrith Kumar <amrith at tesora.com> wrote:\n> > > >> In addition to making changes to the hacking rules, why don\'t we mandate also\n> > > >> that perceived problems in the commit message shall not be an acceptable\n> > > >> reason to -1 a change.\n> > > > \n> > > > -1.\n> > > > \n> > > > There are some /really/ bad commit messages out there, and some of us\n> > > > try to use the commit messages to usefully sort through the changes\n> > > > (i.e. I often -1 in cinder a change only affects one driver and that\n> > > > isn\'t clear from the summary).\n> > > > \n> > > > If the perceived problem is grammatical, I\'m a bit more on board with\n> > > > it not a reason to rev a patch, but core reviewers can +2/A over the\n> > > > top of a -1 anyway...\n> > > \n> > > 100% agree. Spelling and grammar are rude to review on - especially\n> > > since we have (and want) a LOT of non-native English speakers. It\'s not\n> > > our job to teach people better grammar. Heck - we have people from\n> > > different English backgrounds with differing disagreements on what good\n> > > grammar _IS_\n> > > \n> > \n> > We shouldn\'t quibble over _anything_ grammatical in a commit message. If\n> > there is a disagreement about it, the comments should be ignored. There\n> > are definitely a few grammar rules that are loose and those should be\n> > largely ignored.\n> > \n> > However, we should correct grammar when there is a clear solution, as\n> > those same people who do not speak English as their first language are\n> > likely to be confused by poor grammar.\n> > \n> > We\'re not doing it to teach grammar. We\'re doing it to ensure readability.\n> \n> The importance of clear English varies with context, but commit messages\n> are a place where we should try hard to just let it go, particularly\n> with those who do not speak English as their first language.\n> \n> Commit messages stick around forever and it\'s important that they are\n> useful, but they will be read by a small number of people who are going\n> to be in a position to spend a small amount of time getting over\n> whatever dissonance is caused by a typo or imperfect grammar.\n>\n\nThe times that one is reading git messages are often the most stressful\nsuch as when a regression has occurred in production.\n\nGiven that, I believe it is entirely worth it to me that the commit\nmessages on my patches are accurate and understandable. I embrace all\nfeedback which leads to them being more clear. I will of course stand\nback from grammar correcting and not block patches if there are many\nwho disagree.\n\n> I think specs are pretty similar and don\'t warrant much additional\n> grammar nitpicking. Sure, they\'re longer pieces of text and slightly\n> more people will rely on them for information, but they\'re not intended\n> to be complete documentation.\n>\n\nDisagree. I will only state this one more time as I think everyone knows\nhow I feel: if we are going to grow beyond the english-as-a-first-language\nworld we simply cannot assume that those reading specs will be native\nspeakers. Good spelling and grammar helps us grow. Bad spelling and\ngrammar holds us back.\n\n> Where grammar is so poor that readers would be easily misled in\n> important ways, then sure that should be fixed. But there comes a point\n> when we\'re no longer working to avoid confusion and instead just being\n> pendants. Taking issue[1] with this:\n> \n>   \"whatever scaling mechanism Heat and we end up going with.\"\n> \n> because it has a \"dangling preposition\" is an example of going way\n> beyond the point of productive pedantry IMHO :-)\n\nI actually agree that it would not at all be a reason to block a patch.\nHowever, there is some ambiguity in that sentence that may not be clear\nto a native speaker. It is not 100% clear if we are going with Heat,\nor with the scaling mechanism. That is the only reason for the dangling\npreposition debate. However, there is a debate, and thus I would _never_\nblock a patch based on this rule. It was feedback.. just as sometimes\nthere is feedback in commit messages that isn\'t taken and doesn\'t lead\nto a -1.\n\n\n','<1403639392.3652.26.camel@sorcha>',NULL),('<1403645204.3652.37.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 22:26:44',3600,'2014-06-24 21:26:44',NULL,'[openstack-dev] [hacking] rules for removal','On Tue, 2014-06-24 at 13:56 -0700, Clint Byrum wrote:\n> Excerpts from Mark McLoughlin\'s message of 2014-06-24 12:49:52 -0700:\n> > On Tue, 2014-06-24 at 09:51 -0700, Clint Byrum wrote:\n> > > Excerpts from Monty Taylor\'s message of 2014-06-24 06:48:06 -0700:\n> > > > On 06/22/2014 02:49 PM, Duncan Thomas wrote:\n> > > > > On 22 June 2014 14:41, Amrith Kumar <amrith at tesora.com> wrote:\n> > > > >> In addition to making changes to the hacking rules, why don\'t we mandate also\n> > > > >> that perceived problems in the commit message shall not be an acceptable\n> > > > >> reason to -1 a change.\n> > > > > \n> > > > > -1.\n> > > > > \n> > > > > There are some /really/ bad commit messages out there, and some of us\n> > > > > try to use the commit messages to usefully sort through the changes\n> > > > > (i.e. I often -1 in cinder a change only affects one driver and that\n> > > > > isn\'t clear from the summary).\n> > > > > \n> > > > > If the perceived problem is grammatical, I\'m a bit more on board with\n> > > > > it not a reason to rev a patch, but core reviewers can +2/A over the\n> > > > > top of a -1 anyway...\n> > > > \n> > > > 100% agree. Spelling and grammar are rude to review on - especially\n> > > > since we have (and want) a LOT of non-native English speakers. It\'s not\n> > > > our job to teach people better grammar. Heck - we have people from\n> > > > different English backgrounds with differing disagreements on what good\n> > > > grammar _IS_\n> > > > \n> > > \n> > > We shouldn\'t quibble over _anything_ grammatical in a commit message. If\n> > > there is a disagreement about it, the comments should be ignored. There\n> > > are definitely a few grammar rules that are loose and those should be\n> > > largely ignored.\n> > > \n> > > However, we should correct grammar when there is a clear solution, as\n> > > those same people who do not speak English as their first language are\n> > > likely to be confused by poor grammar.\n> > > \n> > > We\'re not doing it to teach grammar. We\'re doing it to ensure readability.\n> > \n> > The importance of clear English varies with context, but commit messages\n> > are a place where we should try hard to just let it go, particularly\n> > with those who do not speak English as their first language.\n> > \n> > Commit messages stick around forever and it\'s important that they are\n> > useful, but they will be read by a small number of people who are going\n> > to be in a position to spend a small amount of time getting over\n> > whatever dissonance is caused by a typo or imperfect grammar.\n> >\n> \n> The times that one is reading git messages are often the most stressful\n> such as when a regression has occurred in production.\n> \n> Given that, I believe it is entirely worth it to me that the commit\n> messages on my patches are accurate and understandable. I embrace all\n> feedback which leads to them being more clear. I will of course stand\n> back from grammar correcting and not block patches if there are many\n> who disagree.\n> \n> > I think specs are pretty similar and don\'t warrant much additional\n> > grammar nitpicking. Sure, they\'re longer pieces of text and slightly\n> > more people will rely on them for information, but they\'re not intended\n> > to be complete documentation.\n> >\n> \n> Disagree. I will only state this one more time as I think everyone knows\n> how I feel: if we are going to grow beyond the english-as-a-first-language\n> world we simply cannot assume that those reading specs will be native\n> speakers. Good spelling and grammar helps us grow. Bad spelling and\n> grammar holds us back.\n\nThere\'s two sides to this coin - concern about alienating\nnon-english-as-a-first-language speakers who feel undervalued because\ntheir language is nitpicked to death and concern about alienating\nenglish-as-a-first-language speakers who struggle to understand unclear\nor incorrect language.\n\nObviously there\'s a balance to be struck there and different people will\njudge that differently, but I\'m personally far more concerned about the\nformer rather than the latter case.\n\nI expect many beyond the english-as-a-first-language world are pretty\nused to dealing with imperfect language but aren\'t so delighted with\nbeing constantly reminded that their use language is imperfect.\n\n> > Where grammar is so poor that readers would be easily misled in\n> > important ways, then sure that should be fixed. But there comes a point\n> > when we\'re no longer working to avoid confusion and instead just being\n> > pendants. Taking issue[1] with this:\n> > \n> >   \"whatever scaling mechanism Heat and we end up going with.\"\n> > \n> > because it has a \"dangling preposition\" is an example of going way\n> > beyond the point of productive pedantry IMHO :-)\n> \n> I actually agree that it would not at all be a reason to block a patch.\n> However, there is some ambiguity in that sentence that may not be clear\n> to a native speaker. It is not 100% clear if we are going with Heat,\n> or with the scaling mechanism. That is the only reason for the dangling\n> preposition debate.\n\nI\'d wager you\'d seriously struggle to find anyone who would interpret\nthat sentence as \"we are going with Heat\", even if they were\nnon-english-as-a-first-language speakers who had never heard of\nOpenStack or Heat or scaling mechanisms.\n\nYou\'ll find plenty who would stumble over the sentence and need to\nre-read it, but we making design spec reading a completely frictionless\nexperience is hardly a priority.\n\n> However, there is a debate, and thus I would _never_\n> block a patch based on this rule. It was feedback.. just as sometimes\n> there is feedback in commit messages that isn\'t taken and doesn\'t lead\n> to a -1.\n\nAbsolutely, and I try and be clear about that with e.g. \"not a -1\" or\n\"if you\'re rebasing anyway, perhaps fix this\".\n\nMaybe a convention for such comments would be a good thing? We often do\n\'nitpick\' or \'femtonit\', but they are often still things people are\n-1ing on.\n\nMark.\n\n\n\n','<1403642766-sup-2884@fewbar.com>',NULL),('<1403646969.3652.58.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-06-24 22:56:09',3600,'2014-06-24 21:56:09',NULL,'[OpenStack Foundation] Understanding DefCore','On Sun, 2014-06-22 at 22:19 -0700, Joe Gordon wrote:\n> Hi all,\n> \n> \n> In trying to wrap my head around DefCore, I read the DefCore\n> committe\'s mission as documented on the committee\'s wiki page[0]. The\n> mission is to \"define \'OpenStack Core\' as chartered by the by-laws and\n> guided by Governance/CoreDefinition.\'  While the bylaws don\'t have any\n> reference to \"OpenStack Core\" they do define a term called \"Core\n> OpenStack Project\"[1]. Is this what the DefCore Comittee is refering\n> to when talking about \"OpenStack Core?\"\n\nYes, it is. The crucial bit is:\n\n  \"The Core OpenStack Project means the software modules which are part \n   of an integrated release and for which an OpenStack trademark may be\n   used. The other modules which are part of the OpenStack Project, but\n   not the Core OpenStack Project may not be identified using the\n   OpenStack trademark except when distributed with the Core OpenStack\n   Project.\"\n\nThe aspect of this I think everyone is agreed on is that \"The Core\nOpenStack Project\" is a subset of the integrated release. And that \"The\nCore OpenStack Project\" has something to do with the OpenStack\ntrademark.\n\nThere are two interpretations of this AFAICT:\n\n  1) Only the core modules can be called OpenStack Foo and OpenStack Bar\n\n  2) Only the core modules can be required in some way for commercial \n     products which license the OpenStack trademark in some way\n\nThe DefCore effort is about clarifying (2) \"by defining 1) capabilities,\n2) code and 3) must-pass tests for all OpenStack products. This\ndefinition [..] drives interoperability by creating the minimum\nstandards for products labeled \"OpenStack.\"\n\n>  If so, the bylaws already clearly state the process to change what\n> software modules make up the \"Core OpenStack Project.\" The Technical\n> Committee(TC) proposes a change to what is in the \"Core OpenStack\n> Project\" and the Board of Directors has the sole authrity to approve\n> or reject the TC\'s recommendation [2].\n\nUnder interpretation (1) above, that means the TC can ask the board for\ne.g. Heat to be called OpenStack Orchestration:\n\nhttp://git.openstack.org/cgit/openstack/governance/tree/resolutions/20131106-ceilometer-and-heat-official-names.rst\n\nUnder interpretation (2) above, the TC would be recommending that Heat\nshould in some way be required for OpenStack products.\n\n>  This mismatch between DefCore\'s mission and the bylaws has already\n> been identified by the DefCore committee itself [3]. So if the current\n> mission statement doesn\'t align with the bylaws then what is the\n> DefCore committe\'s current mission statement?\n\nIt\'s part of the DefCore committee\'s mission to help get the bylaws\nconfusion clarified AIUI.\n\nAFAICT the assumption is that the language should be clarified such that\ninterpretation (2) is clear.\n\n> The \'Core Definition\' document[5] mentions DefCore will help\n> \"determine how commercial implementations of OpenStack can be granted\n> use of the trademark,\" and the committee \"may suggest changes to the\n> by-laws to clarify the definition of core.\" So presumably DefCore is\n> not about defining \"Core OpenStack Project,\" but rather about revising\n> the trademark policy as defined in Appendix 8 of the bylaws [6].\n\nIt\'s about changing how \"Core OpenStack Project\" is defined such that it\nis no longer \"a set of modules which is a subset of the integrated\nrelease\" but instead \"a set of API tests and required sections of code\".\n\nThat involves both coming up with the process for managing that (in that\nit wouldn\'t begin simply with the TC nominating some modules for Core)\nand proposing the bylaws changes to reflect the process.\n\nThat raises the question of what happens if DefCore-recommended bylaws\nchanges can\'t be passed. What interpretation of the current bylaws\nallows the commercial trademark requirements process to evolve in this\nway?\n\n>  This interpretation alligns with the special clause on ammendments in\n> the bylaws \"the Board of Directors may by majority vote, amend the\n> Trademark Policy prior to January 31, 2013 to establish testing and\n> certification requirements for the use of the trademarks owned by the\n> Foundation in connection with the use of the Core OpenStack\n> Project.\"[7]  What is the progress on drafting a revision to the\n> trademark policy? Is there a preliminary draft on the proposed change?\n> Seeing this would help me wrap my better understand DefCore.\n\nGood question, I don\'t know if the Foundation is working on drafting a\nnew trademark policy.\n\nAIUI the Foundation staff is responsible for the details of the\ntrademark policy and it has changed somewhat since the bylaws were\ndrafted. I think it was only included in the bylaws for informational\npurposes and doesn\'t require a vote of the Individual Members. Then\nagain, section 9.2(a) suggests voting is required to change any of the\nappendices.\n\nThanks,\nMark.\n\n> [0] https://wiki.openstack.org/wiki/Governance/DefCoreCommittee \n> [1] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/\n> Sections 4.1.b\n> [2] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/\n> Sections 4.13.b\n> [3] https://etherpad.openstack.org/p/DefCoreBylawsIPE \n> [5] https://wiki.openstack.org/wiki/Governance/CoreDefinition\n> [6] http://www.openstack.org/brand/openstack-trademark-policy/\n> [7] http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/\n> Sections 9.2.d\n\n\n\n\n','<CAHXdxOffLzQc_Mb0oy7vo1Dyd1Q0whV+N8knLkzEjgcK6Vzsaw@mail.gmail.com>',NULL),('<1403647742.10734.22.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-24 17:09:02',-18000,'2014-06-24 22:09:02',NULL,'[openstack-dev] [hacking] rules for removal','On Tue, 2014-06-24 at 22:26 +0100, Mark McLoughlin wrote:\n> There\'s two sides to this coin - concern about alienating\n> non-english-as-a-first-language speakers who feel undervalued because\n> their language is nitpicked to death and concern about alienating\n> english-as-a-first-language speakers who struggle to understand unclear\n> or incorrect language.\n\nActually, I think there\'s a third case which is the one people seem to\nbe worried about here: non-English-as-a-first-language speakers who are\ntrying to read English written by other non-English-as-a-first-language\nspeakers.\n\n> Obviously there\'s a balance to be struck there and different people will\n> judge that differently, but I\'m personally far more concerned about the\n> former rather than the latter case.\n\nSo, my personal experience is that, as long as you express your\ncorrections kindly, most non-English-as-a-first-language speakers are\nreceptive and appreciative of corrections.  They should be\n*corrections*, though: \"Actually, I think you meant \'?\'; that would be\nclearer.\"  Further, unless there are egregious problems, I always try to\nexpress my language suggestions as \"femtonits\", meaning that I don\'t\ndown-vote a patch for those issues (unless perhaps there are a *lot* of\nthem).  The only time I don\'t suggest corrections is when I really can\'t\nunderstand what was meant, in which case I try to ask questions to help\nclarify the meaning?\n\n> Absolutely, and I try and be clear about that with e.g. \"not a -1\" or\n> \"if you\'re rebasing anyway, perhaps fix this\".\n> \n> Maybe a convention for such comments would be a good thing? We often do\n> \'nitpick\' or \'femtonit\', but they are often still things people are\n> -1ing on.\n\nPerhaps we should \"formalize\" the terminology, maybe by documenting that\n\"femtonit\" should mean this in something like the review checklist?  We\ncould pair that with a glossary of terms that could be referred to by\nthe \"your first patch\" bot and mentioned in the Gerrit workflow page.\nThat way, reviewers are using a consistent terminology?\"femtonit\" is\nhardly standard English, after all; it\'s a specialty term we\'ve invented\n?and developers have guidance on what it means and what they should do\nin response to it.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<1403645204.3652.37.camel@sorcha>',NULL),('<1403667959.5574.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-25 03:45:45',0,'2014-06-25 03:45:45',NULL,'[openstack-dev] [Neutron][LBaaS] Which entities need status','Alright y\'all have convinced me for now.  How the status is show on\nshared entities is still yet to be determined.  However, we don\'t have\nany shared entities (unless we really want health monitors shareable\nright now) at this point so the status won\'t get complicated for this\nfirst iteration. \n\nThanks,\nBrandon\n\nOn Wed, 2014-06-25 at 01:10 +0000, Doug Wiegley wrote:\n> Hi Stephen,\n> \n> \n> > Ultimately, as we will have several objects which have many-to-many\n> relationships with other objects, the \'status\' of an object that is\n> shared between what will ultimately be two separate physical entities\n> on the back-end should be represented by a dictionary, and any\n> \'reduction\' of this on behalf of the user should happen within the UI.\n> It does make things more complex to deal with in certain kinds of\n> failure scenarios, but we don\'t help ourselves at all by trying to\n> hide, say, when a member of a pool referenced by one listener is \'UP\'\n> and the same member of the same pool referenced by a different\n> listener is \'DOWN\'.  :/\n> \n> \n> For M:N, that?s actually an additional status field that rightly\n> belongs as another column in the join table, if at all (allow me to\n> queue up all of my normal M:N objections here in this case, I?m just\n> talking normal db representation.)  The bare object itself still has\n> status of its own.\n> \n> \n> Doug\n> \n> \n> \n> \n> \n> \n> From: Stephen Balukoff <sbalukoff at bluebox.net>\n> Reply-To: \"OpenStack Development Mailing List (not for usage\n> questions)\" <openstack-dev at lists.openstack.org>\n> Date: Tuesday, June 24, 2014 at 6:02 PM\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] Which entities need\n> status\n> \n> \n> \n> Ultimately, as we will have several objects which have many-to-many\n> relationships with other objects, the \'status\' of an object that is\n> shared between what will ultimately be two separate physical entities\n> on the back-end should be represented by a dictionary, and any\n> \'reduction\' of this on behalf of the user should happen within the UI.\n> It does make things more complex to deal with in certain kinds of\n> failure scenarios, but we don\'t help ourselves at all by trying to\n> hide, say, when a member of a pool referenced by one listener is \'UP\'\n> and the same member of the same pool referenced by a different\n> listener is \'DOWN\'.  :/ \n> \n> \n> Granted, our version 1 implementation of these objects is going to be\n> simplified, but it doesn\'t hurt to think about where we\'re headed with\n> this API and object model.\n> \n> \n> I think it would be worthwhile for someone to produce a status matrix\n> showing which kinds of status are available for each object type, and\n> what the possible values of those statuses are, and what they mean.\n> Given the question of what \'status\' means is very complicated indeed,\n> I think this is the only way we\'re going to actually make forward\n> progress in this discussion.\n> \n> \n> Stephen\n> \n> \n> \n> \n> On Tue, Jun 24, 2014 at 4:02 PM, Dustin Lundquist\n> <dustin at null-ptr.net> wrote:\n>         I think there is significant value in having status on the\n>         listener object even in the case of HAProxy. While HAProxy can\n>         support multiple listeners in a single process, there is no\n>         reason it needs to be deployed that way. Additionally in the\n>         case of updating a configuration with an additional listener,\n>         the other listeners and the load balancer object are not in an\n>         unavailable or down state before the configuration is applied,\n>         only the new listener object is down or building. In the case\n>         of the HAProxy namespace driver, one could map the namespace\n>         creation and HAProxy process to the load balancer object\n>         status, but each listener can have its own status based on the\n>         availability of members in its pools. \n>         \n>         \n>         For the initial version of our new object model we be\n>         pragmatic and minimize complexity and change, we can preform a\n>         reduction across all listeners to generate an overall load\n>         balancer status.\n>         \n>         \n>         \n>         \n>         -Dustin\n>         \n>         \n>         On Tue, Jun 24, 2014 at 3:15 PM, Vijay B <os.vbvs at gmail.com>\n>         wrote:\n>                 Hi Brandon, Eugene, Doug, \n>                 \n>                 \n>                 During the hackathon, I remember that we had briefly\n>                 discussed how listeners would manifest themselves on\n>                 the LB VM/device, and it turned out that for some\n>                 backends like HAProxy it simply meant creating a\n>                 frontend entry in the cfg file whereas on other\n>                 solutions it could mean spawning a process/equivalent.\n>                 So we must have status fields to track the state of\n>                 any such entities that are actually created. In the\n>                 listener case, an ACTIVE state would mean that the\n>                 appropriate backend processes have been created or\n>                 that the required config file entries have been made.\n>                 \n>                 \n>                 I like the idea of having relational objects and\n>                 setting the status on them, and in our case we can use\n>                 the status fields (pool/healthmonitor/listener) in\n>                 each table to denote the state of the relationship\n>                 (configuration/association on backend) to another\n>                 object like LoadBalancer. So I think the status fields\n>                 should stay.\n>                 \n>                 \n>                 In this scenario, some entities\' status could be\n>                 updated in lbaas proper, and some in the driver\n>                 implementation. I don\'t have a strict preference as to\n>                 which among lbaas proper or the driver layer announces\n>                 the status since we discussed on the IRC that we\'d\n>                 have helper functions in the driver to do these\n>                 updates.\n>                 \n>                 \n>                 \n>                 \n>                 Regards,\n>                 Vijay\n>                 \n>                 \n>                 On Tue, Jun 24, 2014 at 12:16 PM, Brandon Logan\n>                 <brandon.logan at rackspace.com> wrote:\n>                         On Tue, 2014-06-24 at 18:53 +0000, Doug\n>                         Wiegley wrote:\n>                         > Hi Brandon,\n>                         >\n>                         > I think just one status is overloading too\n>                         much onto the LB object (which\n>                         > is perhaps something that a UI should do for\n>                         a user, but not something an\n>                         > API should be doing.)\n>                         \n>                         \n>                         That is a good point and perhaps its another\n>                         discussion to just have\n>                         some way to show the status an entity has for\n>                         each load balancer, which\n>                         is what mark suggested for the member status\n>                         at the meet-up.\n>                         \n>                         >\n>                         > > 1) If an entity exists without a link to a\n>                         load balancer it is purely\n>                         > > just a database entry, so it would always\n>                         be ACTIVE, but not really\n>                         > > active in a technical sense.\n>                         >\n>                         > Depends on the driver.  I don?t think this\n>                         is a decision for lbaas proper.\n>                         \n>                         \n>                         Driver is linked to the flavor or provider.\n>                          Flavor or provider will/is\n>                         linked to load balancer.  We won\'t be able get\n>                         a driver to send anything\n>                         to if there isn\'t a load balancer.  Without a\n>                         driver it is a decision\n>                         for lbaas proper.  I\'d be fine with setting\n>                         the status of these\n>                         \"orphaned\" entities to just ACTIVE but I\'m\n>                         just worried about the status\n>                         management in the future.\n>                         \n>                         >\n>                         >\n>                         > > 2) If some of these entities become\n>                         shareable then how does the status\n>                         > > reflect that the entity failed to create\n>                         on one load balancer but was\n>                         > > successfully created on another.  That\n>                         logic could get overly complex.\n>                         >\n>                         > That?s a status on the join link, not the\n>                         object, and I could argue\n>                         > multiple ways in which that should be one\n>                         way or another based on the\n>                         > backend, which to me, again implies driver\n>                         question (backend could queue\n>                         > for later, or error immediately, or let\n>                         things run degraded, or?)\n>                         \n>                         \n>                         Yeah that is definitely an argument.  I\'m just\n>                         trying to keep in mind\n>                         the complexities that could arise from\n>                         decisions made now.  Perhaps it\n>                         is the wrong way to look at it to some, but I\n>                         don\'t think thinking about\n>                         the future is a bad thing and should never be\n>                         done.\n>                         \n>                         >\n>                         > Thanks,\n>                         > Doug\n>                         >\n>                         >\n>                         >\n>                         >\n>                         > On 6/24/14, 11:23 AM, \"Brandon Logan\"\n>                         <brandon.logan at RACKSPACE.COM> wrote:\n>                         >\n>                         > >I think we missed this discussion at the\n>                         meet-up but I\'d like to bring\n>                         > >it up here.  To me having a status on all\n>                         entities doesn\'t make much\n>                         > >sense, and justing having a status on a\n>                         load balancer (which would be a\n>                         > >provisioning status) and a status on a\n>                         member (which would be an\n>                         > >operational status) are what makes sense\n>                         because:\n>                         > >\n>                         > >1) If an entity exists without a link to a\n>                         load balancer it is purely\n>                         > >just a database entry, so it would always\n>                         be ACTIVE, but not really\n>                         > >active in a technical sense.\n>                         > >\n>                         > >2) If some of these entities become\n>                         shareable then how does the status\n>                         > >reflect that the entity failed to create on\n>                         one load balancer but was\n>                         > >successfully created on another.  That\n>                         logic could get overly complex.\n>                         > >\n>                         > >I think the best thing to do is to have the\n>                         load balancer status reflect\n>                         > >the provisioning status of all of its\n>                         children.  So if a health monitor\n>                         > >is updated then the load balancer that\n>                         health monitor is linked to would\n>                         > >have its status changed to PENDING_UPDATE.\n>                          Conversely, if a load\n>                         > >balancer or any entities linked to it are\n>                         changed and the load\n>                         > >balancer\'s status is in a non-ACTIVE state\n>                         then that update should not\n>                         > >be allowed.\n>                         > >\n>                         > >Thoughts?\n>                         > >\n>                         > >Thanks,\n>                         > >Brandon\n>                         > >\n>                         > >\n>                         >\n>                         >_______________________________________________\n>                         > >OpenStack-dev mailing list\n>                         > >OpenStack-dev at lists.openstack.org\n>                         >\n>                         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         >\n>                         >\n>                         >\n>                         _______________________________________________\n>                         > OpenStack-dev mailing list\n>                         > OpenStack-dev at lists.openstack.org\n>                         >\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFCF6F40.36B6%dougw@a10networks.com>',NULL),('<1403717459.6457.45.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 01:30:59',28800,'2014-06-25 17:30:59',NULL,'[openstack-dev] [Barbican] Barebones CA','I think the plan is to create a Dogtag instance so that integration\ntests can be run whenever code is checked in (both with and without a\nDogtag backend).\n\nDogtag isn\'t that difficult to deploy, but being a Java app, it does\nbring in a set of dependencies that developers may not want to deal with\nfor basic/ devstack testing.\n\nSo, I agree that a simple OpenSSL CA may be useful at least initially as\na \'dev\' plugin.\n\nAde\n\nOn Wed, 2014-06-25 at 16:31 +0000, Jarret Raim wrote:\n> Rob,\n> \n> RedHat is working on a backend for Dogtag, which should be capable of\n> doing something like that. That\'s still a bit hard to deploy, so it would\n> make sense to extend the \'dev\' plugin to include those features.\n> \n> \n> Jarret\n> \n> \n> On 6/24/14, 4:04 PM, \"Clark, Robert Graham\" <robert.clark at hp.com> wrote:\n> \n> >Yeah pretty much.\n> >\n> >That?s something I?d be interested to work on, if work isn?t ongoing\n> >already.\n> >\n> >-Rob\n> >\n> >\n> >\n> >\n> >\n> >On 24/06/2014 18:57, \"John Wood\" <john.wood at RACKSPACE.COM> wrote:\n> >\n> >>Hello Robert,\n> >>\n> >>I would actually hope we have a self-contained certificate plugin\n> >>implementation that runs \'out of the box\' to enable certificate\n> >>generation orders to be evaluated and demo-ed on local boxes.\n> >>\n> >>Is this what you were thinking though?\n> >>\n> >>Thanks,\n> >>John\n> >>\n> >>\n> >>\n> >>________________________________________\n> >>From: Clark, Robert Graham [robert.clark at hp.com]\n> >>Sent: Tuesday, June 24, 2014 10:36 AM\n> >>To: OpenStack List\n> >>Subject: [openstack-dev] [Barbican] Barebones CA\n> >>\n> >>Hi all,\n> >>\n> >>I?m sure this has been discussed somewhere and I?ve just missed it.\n> >>\n> >>Is there any value in creating a basic ?CA? and plugin to satisfy\n> >>tests/integration in Barbican? I?m thinking something that probably\n> >>performs OpenSSL certificate operations itself, ugly but perhaps useful\n> >>for some things?\n> >>\n> >>-Rob\n> >>\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CFD0636B.10A2A%jarret.raim@rackspace.com>',NULL),('<1403726428.21932.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-25 20:00:12',0,'2014-06-25 20:00:12',NULL,'[openstack-dev] [Neutron][LBaaS] Should TLS settings for\n listener be set through separate API/model?','Hi Stephen, \n\nThe <entity><entity>associations table name is consistent with the rest\nof neutron\'s table names, as is not breaking the table name words up by\nan underscore.  I think this stems from the sqlalchemy models getting\nthe table name for free because of inheriting from a base model that\nderives the table name based on the model\'s class name.\n\nHowever, with markmcclain\'s blessing the new loadbalancing tables will\nbe prefixed with lbaas_, but the model names will be LoadBalancer,\nListener, etc.\n\nI would agree though that since sni will not be a separate table then\nthat will be a bit odd to have an association table\'s name implying a\njoin of a table that doesn\'t exist.\n\nThanks,\nBrandon\n\nOn Wed, 2014-06-25 at 09:55 -0700, Stephen Balukoff wrote:\n> What\'s the point of putting off a potential name change to the actual\n> code (where you\'re going to see more friction because names in the\n> code do not match names in the spec, and this becomes a point where\n> confusion can happen). I understand the idea that code may not exactly\n> match the spec, but when it\'s obvious that it should, why use the\n> wrong name in the spec?\n> \n> \n> Isn\'t it more confusing when the API does not match database object\n> names when it\'s clear the API is specifically meant to manipulate\n> those database objects?\n> \n> \n> Is that naming convention actually documented anywhere? And why are\n> you calling it a \'listenersniassociations\'? There is no \"SNI\" object\n> in the database. (IMO, this is a terrible name that needs to be\n> re-read three times just to pick out where the word breaks should be!\n> As written it looks like \"Listeners NI Associations\" what the heck is\n> an \'NI\'?)\n> \n> \n> They say that there are two hard problems in Computer Science:\n> * Cache invalidation\n> * Naming things\n> * Off-by-one errors\n> \n> \n> And far be it from me to pick nits about a name (OK, I guess it\'s\n> isn\'t that far fetched for me to pick nits. :P ), but it\'s hard for me\n> to imagine a worse name than \'listenersniassocaitions\' being\n> considered. :P\n> \n> \n> Stephen\n> \n> \n> \n> \n> On Wed, Jun 25, 2014 at 2:05 AM, Evgeny Fedoruk <EvgenyF at radware.com>\n> wrote:\n>         Hi folks\n>         \n>          \n>         \n>         Regarding names, there are two types of them: new API\n>         attributes for REST call,  and new column name and table name\n>         for the database.\n>         \n>         When creating listener, 2 new attributes will be added to the\n>         REST call API: \n>         \n>         1.      default_tls_container_id - Barbican TLS container uuid\n>         \n>         2.      sni_container_ids (I removed the ?_list? part to make\n>         it shorter) ? ordered list of Barbican TLS container uuids\n>         \n>         For the database, these will be translated to:\n>         \n>         1.      default_tls_container_id- new column for listeners\n>         table\n>         \n>         2.      listenersniassociations (changed it from\n>         vipsniassociations which is a mistake) ? new associations\n>         table, holding: id(generated), listener_id, TLS_container_id,\n>         and position(for ordering)\n>         \n>         This kind of a name comes to comply current neutron?s table\n>         name convention, like pollmonitorassociation or\n>         providerresourceassociation\n>         \n>          \n>         \n>         I think names may always be an issue for the actual code\n>         review, the document is just a functional specification\n>         \n>         Since new objects model code is not landed yet, naming\n>         conventions may be changed while implementing this spec.\n>         \n>         I will commit the document with all comments addressed and\n>         mentioned above names.\n>         \n>         Please review it and give your feedback, I think we are close\n>         to complete this one ) \n>         \n>          \n>         \n>         Thanks,\n>         \n>         Evg\n>         \n>          \n>         \n>          \n>         \n>          \n>         \n>         From: Vijay Venkatachalam\n>         [mailto:Vijay.Venkatachalam at citrix.com] \n>         Sent: Wednesday, June 25, 2014 8:34 AM\n>         \n>         \n>         To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS\n>         settings for listener be set through separate API/model?\n>          \n>         \n>         Thanks for the details Evg!\n>         \n>          \n>         \n>         I understand there was no TLS settings API originally planned.\n>         \n>          \n>         \n>         From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n>         Sent: Wednesday, June 25, 2014 5:46 AM\n>         To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS\n>         settings for listener be set through separate API/model?\n>         \n>         \n>          \n>         \n>         Evgeny--\n>         \n>          \n>         \n>         \n>         Two minor nits:\n>         \n>         \n>          \n>         \n>         \n>         * Your spec lists the new SNI related settings \'sni_list\' (and\n>         it contains more than just IDs, so calling it\n>         \'sni_container_ids_list\' is misleading). Please be precise in\n>         the terms you use, and don\'t switch them mid discussion. :)\n>         \n>         \n>         * Also, I personally really hate long table names when they\'re\n>         unnecessary. \"vipsniassociations\" isn\'t mentioned in your spec\n>         anywhere, and frankly, is a lot worse than \"sni_list.\" I\n>         personally prefer \"SNIPolicies\", but I\'m also OK with a short\n>         name like \"sni_list\".\n>         \n>         \n>          \n>         \n>         \n>         Otherwise I agree with you on all points.\n>         \n>         \n>          \n>         \n>         \n>         Stephen\n>         \n>         \n>          \n>         \n>         \n>          \n>         \n>         \n>          \n>         \n>         \n>          \n>         \n>         On Tue, Jun 24, 2014 at 3:26 AM, Evgeny Fedoruk\n>         <EvgenyF at radware.com> wrote:\n>         \n>                 Vijay, there is no intension for a new TLS settings\n>                 API.\n>                 \n>                 Creation of a listener with TLS offloading will be\n>                 one-step.\n>                 \n>                  \n>                 \n>                 When tenant creates listener with TERMINATED-HTTPS\n>                 protocol he must supply default_tls_container_id for\n>                 offloading.\n>                 \n>                 Not supplying default TLS container id for offloading\n>                 for TERMINATED-HTTPS listener will raise an error.\n>                 \n>                 SNI list may or may not be supplied by the tenant.\n>                 Default value for SNI certificates list is an empty\n>                 list.\n>                 \n>                  \n>                 \n>                 So listener resource will have another two attributes:\n>                 default_tls_container_id and sni_container_ids_list.\n>                 These are relevant for TERMINATED-HTTPS protocol\n>                 listeners only. In other cases its default value are\n>                 ?None? and empty list.\n>                 \n>                 In schema, Default_tls_container_id will be added to\n>                 listener object as another column.\n>                 \n>                 Sni_container_ids_list wil be managed by new table\n>                 ?vipsniassociations? which has listener_id,\n>                 container_id, and position (for ordering) columns\n>                 \n>                  \n>                 \n>                 Does it make sense?\n>                 \n>                  \n>                 \n>                 Thanks,\n>                 \n>                 Evg\n>                 \n>                  \n>                 \n>                  \n>                 \n>                  \n>                 \n>                  \n>                 \n>                 From: Vijay Venkatachalam\n>                 [mailto:Vijay.Venkatachalam at citrix.com] \n>                 Sent: Tuesday, June 24, 2014 12:31 PM\n>                 \n>                 \n>                 To: OpenStack Development Mailing List (not for usage\n>                 questions)\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                 \n>                  \n>                 \n>                  \n>                 \n>                 To clarify, the request is for a new TLS settings API\n>                 with ?default_tls_container_id? & ?sni_list?.  \n>                 \n>                                \n>                 \n>                 If there is a new API, then we would have an object\n>                 model reflecting this as a separate entity.\n>                 \n>                  \n>                 \n>                 The tenant would do the following\n>                 \n>                  \n>                 \n>                 1.      Create a listener with TERMINATED_HTTPS\n>                 \n>                 2.      Set the TLS settings for the listener\n>                 using /v2.0/listener/<listenerid>/tlssettings  (if at\n>                 all we are having some default values this can be\n>                 reflected here)\n>                 \n>                  \n>                 \n>                 The only good thing is the separation of the TLS\n>                 settings out of the listener API.\n>                 \n>                  \n>                 \n>                 But, I can see 2 downsides\n>                 \n>                 1.      The loadbalancer creation is a 2 step\n>                 procedure\n>                 \n>                 2.      We cannot enforce certificate attachment as\n>                 part of the create of listener.\n>                 \n>                  \n>                 \n>                 If the new API itself has ?-1?s then I am perfectly OK\n>                 with the current object model with\n>                 default_tls_container_id in listener table.\n>                 \n>                  \n>                 \n>                 Thanks,\n>                 \n>                 Vijay V.\n>                 \n>                  \n>                 \n>                  \n>                 \n>                 From: Evgeny Fedoruk [mailto:EvgenyF at Radware.com] \n>                 Sent: Tuesday, June 24, 2014 2:19 PM\n>                 To: OpenStack Development Mailing List (not for usage\n>                 questions)\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                 \n>                  \n>                 \n>                 Vipsniassociations table:Line 147 in last patch of the\n>                 document\n>                 \n>                  \n>                 \n>                 From: Vijay Venkatachalam\n>                 [mailto:Vijay.Venkatachalam at citrix.com] \n>                 Sent: Tuesday, June 24, 2014 10:17 AM\n>                 To: OpenStack Development Mailing List (not for usage\n>                 questions)\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                 \n>                  \n>                 \n>                  \n>                 \n>                 >>SNI list is managed by separate entity\n>                 \n>                 What is this entity?\n>                 \n>                  \n>                 \n>                 From: Evgeny Fedoruk [mailto:EvgenyF at Radware.com] \n>                 Sent: Tuesday, June 24, 2014 12:25 PM\n>                 To: OpenStack Development Mailing List (not for usage\n>                 questions)\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                 \n>                  \n>                 \n>                 +1 for option 1. SNI list is managed by separate\n>                 entity, default TLS container is part of a listener\n>                 object. It will have None value when listener does not\n>                 offloads TLS.\n>                 \n>                 Managing another entity for 1:0-1 relationship just\n>                 for future use seems not right to me. Breaking TLS\n>                 settings apart from listener can be done when needed,\n>                 if needed.\n>                 \n>                  \n>                 \n>                 Thanks,\n>                 \n>                 Evg\n>                 \n>                  \n>                 \n>                  \n>                 \n>                 From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n>                 Sent: Tuesday, June 24, 2014 4:26 AM\n>                 To: OpenStack Development Mailing List (not for usage\n>                 questions)\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                  \n>                 \n>                 Ok, so we\'ve got opinions on both sides of the\n>                 argument here. I\'m actually pretty ambivalent about\n>                 it. Do others have strong opinions on this?\n>                 \n>                 \n>                  \n>                 \n>                 On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley\n>                 <dougw at a10networks.com> wrote:\n>                 \n>                 Put me down for being in favor of option 1.\n>                 \n>                 \n>                  \n>                 \n>                 \n>                 A single attribute in a 1:1 relationship?  Putting\n>                 that in a new table sounds like premature optimization\n>                 to me; design the database change for the future\n>                 feature when you can see the spec for it.\n>                 \n>                 \n>                  \n>                 \n>                 \n>                 Thanks,\n>                 \n>                 \n>                 Doug\n>                 \n>                 \n>                  \n>                 \n>                 \n>                  \n>                 \n>                 \n>                 From:Stephen Balukoff <sbalukoff at bluebox.net>\n>                 Reply-To: \"OpenStack Development Mailing List (not for\n>                 usage questions)\" <openstack-dev at lists.openstack.org>\n>                 Date: Monday, June 23, 2014 at 5:25 PM\n>                 To: \"OpenStack Development Mailing List (not for usage\n>                 questions)\" <openstack-dev at lists.openstack.org>\n>                 Subject: Re: [openstack-dev] [Neutron][LBaaS] Should\n>                 TLS settings for listener be set through separate\n>                 API/model?\n>                 \n>                 \n>                  \n>                 \n>                 \n>                 Also to add to pros for 2:\n>                 \n>                  \n>                 \n>                 \n>                 * Keeping the TLS stuff contained to its own objects\n>                 means we can have separate development resources on\n>                 each and not worry as much about overlapping domains.\n>                 (TLS-related knowledge and knowledge of dealing with\n>                 TCP / UDP listeners are separate knowledge domains. Or\n>                 at least, the former is a more specialized subset of\n>                 the latter.)\n>                 \n>                 \n>                  \n>                 \n>                 \n>                 Note that what we\'re proposing means there\'s\n>                 essentially a 1:0-1 relationship between Listener and\n>                 this new yet-to-be-named object. (0 in case the\n>                 Listener is not terminating TLS.)\n>                 \n>                 \n>                  \n>                 \n>                 \n>                 Stephen\n>                 \n>                 \n>                  \n>                 \n>                 On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan\n>                 <brandon.logan at rackspace.com> wrote:\n>                 \n>                 Whoops, [Neutron][LBaaS] got taken out of the subject\n>                 line here.\n>                 Putting it back in.\n>                 \n>                 \n>                 On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan\n>                 wrote:\n>                 > Okay so we\'ve talked a bit about this in IRC and now\n>                 I\'m sending this\n>                 > out as an update.  Here are the options with pros\n>                 and cons that have\n>                 > come from that discussion.\n>                 >\n>                 > 1) default_certificate_id is an attribute of the\n>                 Listener object.\n>                 >\n>                 > Pros:\n>                 > -No extra entity needed\n>                 >\n>                 > Cons:\n>                 > -May bloat Listener object when more attributes are\n>                 needed for only TLS\n>                 > termination.  Sounds like TLS version and cipher\n>                 selection will be\n>                 > needed attributes in the future.\n>                 >\n>                 >\n>                 > 2) A separate TLS Entity is created that is\n>                 referenced by the Listener\n>                 > object.  This entity at first may only contain a\n>                 certificate_id that\n>                 > references barbican.  Name and description can be\n>                 allowed as well.\n>                 >\n>                 > Pros:\n>                 > -TLS domain specific attributes contained in its own\n>                 entity\n>                 > -Future attributes would just be added to this\n>                 entity and not bloat the\n>                 > Listener object.\n>                 >\n>                 > Cons:\n>                 > -It\'s another entity\n>                 >\n>                 > In IRC we (sbalukoff, myself) seemed to agree option\n>                 2 is right way to\n>                 > go.  Anyone agree or disagree?\n>                 >\n>                 > Thanks,\n>                 > Brandon\n>                 >\n>                 > On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff\n>                 wrote:\n>                 > > The separate entity makes sense for certificates\n>                 participating in an\n>                 > > SNI configuration, but probably not so much for\n>                 the \'default\'\n>                 > > certificate used when TLS is being terminated.\n>                 > >\n>                 > >\n>                 > > Vijay: You\'re also right that other TLS-related\n>                 attributes will\n>                 > > probably get added to the Listener object. This\n>                 probably makes sense\n>                 > > if they apply to the Listener object as a whole.\n>                 (This includes things\n>                 > > like TLS version and cipher selection.)\n>                 > >\n>                 > >\n>                 > > I don\'t see much of a point in creating a separate\n>                 object to contain\n>                 > > these fields, since it would have a 1:1\n>                 relationship with the\n>                 > > Listener. It\'s true that for non-TLS-terminated\n>                 Listeners, these\n>                 > > fields wouldn\'t be used, but isn\'t that already\n>                 the case in many other\n>                 > > objects (not just in the Neutron LBaaS sub\n>                 project)?\n>                 > >\n>                 > >\n>                 > > Thanks,\n>                 > > Stephen\n>                 > >\n>                 > >\n>                 > >\n>                 > >\n>                 > >\n>                 > >\n>                 > > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan\n>                 > > <brandon.logan at rackspace.com> wrote:\n>                 > >         Vijay,\n>                 > >         I think the separate entity is still going\n>                 to happen.  I don\'t\n>                 > >         think it\n>                 > >         has remvoed.  Or that is may just be my\n>                 assumption.\n>                 > >\n>                 > >         Thanks,\n>                 > >         Brandon\n>                 > >\n>                 > >         On Mon, 2014-06-23 at 15:59 +0000, Vijay\n>                 Venkatachalam wrote:\n>                 > >         > Hi:\n>                 > >         >\n>                 > >         >\n>                 > >         > In the ?LBaaS TLS termination capability\n>                 specification?\n>                 > >         proposal\n>                 > >         >\n>                 > >         > https://review.openstack.org/#/c/98640/\n>                 > >         >\n>                 > >         > TLS settings like default certificate\n>                 container id and SNI\n>                 > >         cert list are part of the listener\n>                 properties.\n>                 > >         >\n>                 > >         > I think it is better to have this as a\n>                 separate entity so\n>                 > >         that the listener properties are clean and\n>                 is not ?corrupted?\n>                 > >         with TLS settings.\n>                 > >         >\n>                 > >         > I liked the original SSL proposal better\n>                 where TLS settings\n>                 > >         was a separate entity.\n>                 > >         >\n>                 > >         > It is just 2 properties now but in\n>                 future the TLS settings\n>                 > >         would grow and if we are going to\n>                 introduce a TLS\n>                 > >         profile/params/settings entity later, it\n>                 is better to do it\n>                 > >         now (albeit with min properties).\n>                 > >         >\n>                 > >         > Thanks,\n>                 > >         > Vijay V.\n>                 > >\n>                 > >         >\n>                 _______________________________________________\n>                 > >         > OpenStack-dev mailing list\n>                 > >         > OpenStack-dev at lists.openstack.org\n>                 > >         >\n>                 > >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 > >\n>                 > >\n>                 _______________________________________________\n>                 > >         OpenStack-dev mailing list\n>                 > >         OpenStack-dev at lists.openstack.org\n>                 > >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 > >\n>                 > >\n>                 > >\n>                 > >\n>                 > > --\n>                 > > Stephen Balukoff\n>                 > > Blue Box Group, LLC\n>                 > > (800)613-4305 x807\n>                 > > _______________________________________________\n>                 > > OpenStack-dev mailing list\n>                 > > OpenStack-dev at lists.openstack.org\n>                 > >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 >\n>                 > _______________________________________________\n>                 > OpenStack-dev mailing list\n>                 > OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>                 \n>                 \n>                  \n>                 \n>                 \n>                 -- \n>                 Stephen Balukoff \n>                 Blue Box Group, LLC \n>                 (800)613-4305 x807 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>                 \n>                 \n>                  \n>                 \n>                 \n>                 -- \n>                 Stephen Balukoff \n>                 Blue Box Group, LLC \n>                 (800)613-4305 x807 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>          \n>         \n>         \n>         -- \n>         Stephen Balukoff \n>         Blue Box Group, LLC \n>         (800)613-4305 x807 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZrDZAYjBxBum2eq+y=_Es45H0H-stKN-v7dHx=BPBm1cg@mail.gmail.com>',NULL),('<1403727734.99165.YahooMailNeo@web125905.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-25 13:22:14',-25200,'2014-06-25 20:22:14',NULL,'[Openstack-docs] doc-specs repo?','Having many sub-directories follows the docs layout because of the different repos. If we go that way then we would need to treat each project directory separate with their own release directories like?\n/doc-spec/training-guides/juno\n\nThe drawback will be that this makes finding approved specs difficult. The other projects are using the single /specs directory with a flat naming scheme like ml2-dell-afc-mech-driver.rst.\n\nFor specs that overlay projects like install-guides and training-guides, it will be confusing which, what, where. Because of this I vote for this structure\n\ndoc-spec -\n	specs -\n		juno - (all docs program juno cycle RST reside here)\n	tests -\n	doc -\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\nOn Wednesday, June 25, 2014 12:59 PM, Andreas Jaeger <aj at suse.com> wrote:\n \n\n\nOn 06/25/2014 04:56 PM, Anne Gentle wrote:\n> Hi all, \n> I wanted to hear more from the teams about a need for a doc-specs repo.\n> The training team has started to bring specs into their repo. I\'m happy\n> to get this started for the Documentation program but wanted to get some\n> input. \n> \n> I\'d like to have an openstack/doc-spec repo set up with different\n> directories for each area of the documentation. Some projects have\n> designated by release as well, though since only our install guide and\n> config guides are \"released\" I think we could just have:\n> /api\n> /training\n> /user\n> /appdev\n> juno/ops (this is where install and config specs would live)\n> /security\n\nSome of this is not really clear. Why not just use the repository names\nlike:\napi-site\noperations-guide\nmanuals (or openstack-manuals)\ndoc-tools (or openstack-doc-tools)\nsecurity\ntraining-guides ?\n\nI\'m fine with giving it a try for a release cycle,\nAndreas\n-- \nAndreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n? SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n?  GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n? ? GPG fingerprint = 93A3 365E CE47 B889 DF7F? FED1 389A 563C C272 A126\n\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140625/362a2f69/attachment.html>\n\n','<53AB2937.5020507@suse.com>',NULL),('<1403728387.44565.YahooMailNeo@web125901.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-25 13:33:07',-25200,'2014-06-25 20:33:07',NULL,'[Openstack-docs] docs-specs repository','As a parallel thread to Anne\'s doc-specs repo, I propose that we start with the neutron spec template.rst and skeleton.rst found here?https://github.com/openstack/neutron-specs/tree/master/specs. We would remove the REST API impact, security, notifications, and performance impact sections. I would modify the Data Model Impact to doc/common docs Impact.\n\nOnce we figure out the naming bits from the other thread and the template highlights here, then an Infra patch to create the repo would be the next step.\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\nOn Monday, June 23, 2014 10:11 PM, Sean Roberts <seanrob at yahoo-inc.com> wrote:\n \n\n\nThe training-guides team has been seriously looking at using specs as a blueprint development step. After discussing the topic with Anne, we thought discussing having a program wide spec repo was a good idea.?\nSo I propose the documentation program use the repo Openstack/docs-spec. We would still create a wiki page as the starting point. The design would follow an RST template, so important bits of information do not get missed.?\nHere are the steps the training guides project are considering. We were planning just a repo sub-directory, but that would change with the above plan.?\nCreate a Blueprint\n	1. The blueprint is created here?https://blueprints.launchpad.net/openstack-training-guides/+addspec, only the name, title, and summary need to be filled out\n	2. Submit a spec RST patch based on the template?https://github.com/openstack/training-guides/blob/master/specs/template.rst\n	3. Gerrit reviews are the debate and refinement\n	4. Final RST patch either is rejected or approved\n	5. If the RST patch is approved, then it gets merged, the blueprint is approved, and the RST details are manually updated into the blueprint\n	6. The blueprint can only be approved for current release\n	7. Blueprints not approved or not implemented during a release cycle need the RST patch be resubmitted for the next cycle\n~sean\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140625/96f637f5/attachment-0001.html>\n\n','<D43988AC-DBE9-452E-9228-AAE4CC39C4F4@yahoo-inc.com>',NULL),('<1403765596.30333.15.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 16:53:16',36000,'2014-06-26 06:53:16',NULL,'[openstack-dev] Creating new python-<new_project_name>client','On Wed, 2014-06-25 at 22:42 -0500, Dean Troyer wrote:\n> On Wed, Jun 25, 2014 at 10:18 PM, Aaron Rosen <aaronorosen at gmail.com>\n> wrote:\n>         I\'m looking at creating a new python-<new_project_name>client\n>         and I was wondering if there was any on going effort to share\n>         code between the clients or not? I\'ve looked at the code in\n>         python-novaclient and python-neutronclient and both of them\n>         seem to have their own homegrown HTTPClient and keystone\n>         integration. Figured I\'d ping the mailing list here before I\n>         go on and make my own homegrown HTTPClient as well. \n> \n> \n> For things in the library level of a client please consider using\n> keystoneclient\'s fairly new session layer as the basis of your HTTP\n> layer.  That will also give you access to the new style auth plugins,\n> assuming you want to do Keystone auth with this client.\n> \n> \n> I\'m not sure if Jamie has any examples of using this without leaning\n> on the backward-compatibility bits that the existing clients need.\n> \n> \n> The Python SDK is being built on a similar Session layer (without the\n> backeard compat bits).\n> \n> \n> dt \n\nI\'d love to suggest following in the footsteps of the SDK, but it\'s just\na little early for that. \n\nToday the best thing i think would be to use the session from\nkeystoneclient, and copy and paste the adapter:\nhttps://review.openstack.org/#/c/86237/ which is approved but not in a\nrelease yet. A client object takes a session and kwargs and creates an\nadapter with them.\n\nThen reuse the managers from\nhttps://github.com/openstack/oslo-incubator/blob/master/openstack/common/apiclient/base.py\nI\'m personally not a fan, but most of the other clients use this layout\nand I assume you\'re more interested in getting things done in a standard\nway than arguing over client design (If you are interested in that the\nSDK project could always use a hand). Pass the adapter to the managers. \n\nDon\'t write a CLI, you can extend OSC to handle your new service. There\nare no docs for it (that i\'m aware of) but the included services all use\nthe plugin interface so you can copy from one of those. \n\nI don\'t have a pure example of these things, but if any of the above is\nunclear feel free to find me on IRC and i\'ll step you through it.\n\nJamie\n\n> \n> \n> -- \n> \n> Dean Troyer\n> dtroyer at gmail.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<CAOJFoEsD0tW5e=enzVJqJp6KiysNd9dKdXCUSUD9O63JDD4_0g@mail.gmail.com>',NULL),('<1403808843-sup-1392@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 12:20:30',-25200,'2014-06-26 19:20:30',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','Excerpts from Macdonald-Wallace, Matthew\'s message of 2014-06-26 04:13:31 -0700:\n> Hi all,\n> \n> I\'ve been working more and more with TripleO recently and whilst it does seem to solve a number of problems well, I have found a couple of idiosyncrasies that I feel would be easy to address.\n> \n> My primary concern lies in the fact that os-refresh-config does not run on every boot/reboot of a system.  Surely a reboot *is* a configuration change and therefore we should ensure that the box has come up in the expected state with the correct config?\n> \n> This is easily fixed through the addition of an \"@reboot\" entry in /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run as a service.\n> \n> My secondary concern is that through not running os-refresh-config on a regular basis by default (i.e. every 15 minutes or something in the same style as chef/cfengine/puppet), we leave ourselves exposed to someone trying to make a \"quick fix\" to a production node and taking that node offline the next time it reboots because the config was still left as broken owing to a lack of updates to HEAT (I\'m thinking a \"quick change\" to allow root access via SSH during a major incident that is then left unchanged for months because no-one updated HEAT).\n> \n> There are a number of options to fix this including Modifying os-collect-config to auto-run os-refresh-config on a regular basis or setting os-refresh-config to be its own service running via upstart or similar that triggers every 15 minutes\n> \n> I\'m sure there are other solutions to these problems, however I know from experience that claiming this is solved through \"education of users\" or (more severely!) via HR is not a sensible approach to take as by the time you realise that your configuration has been changed for the last 24 hours it\'s often too late!\n> \n\nSo I see two problems highlighted above. \n\n1) We don\'t re-assert ephemeral state set by o-r-c scripts. You\'re right,\nand we\'ve been talking about it for a while. The right thing to do is\nhave os-collect-config re-run its command on boot. I don\'t think a cron\njob is the right way to go, we should just have a file in /var/run that\nis placed there only on a successful run of the command. If that file\ndoes not exist, then we run the command.\n\nI\'ve just opened this bug in response:\n\nhttps://bugs.launchpad.net/os-collect-config/+bug/1334804\n\n2) We don\'t re-assert any state on a regular basis.\n\nSo one reason we haven\'t focused on this, is that we have a stretch goal\nof running with a readonly root partition. It\'s gotten lost in a lot of\nthe craziness of \"just get it working\", but with rebuilds blowing away\nroot now, leading to anything not on the state drive (/mnt currently),\nthere\'s a good chance that this will work relatively well.\n\nNow, since people get root, they can always override the readonly root\nand make changes. <golem>we hates thiss!</golem>.\n\nI\'m open to ideas, however, os-refresh-config is definitely not the\nplace to solve this. It is intended as a non-resident command to be\ncalled when it is time to assert state. os-collect-config is intended\nto gather configurations, and expose them to a command that it runs,\nand thus should be the mechanism by which os-refresh-config is run.\n\nI\'d like to keep this conversation separate from one in which we discuss\nmore mechanisms to make os-refresh-config robust. There are a bunch of\nthings we can do, but I think we should focus just on \"how do we\nre-assert state?\".\n\nBecause we\'re able to say right now that it is only for running when\nconfig changes, we can wave our hands and say it\'s ok that we restart\neverything on every run. As Jan alluded to, that won\'t work so well if\nwe run it every 20 minutes.\n\nSo, I wonder if we can introduce a config version into\nos-collect-config.\n\nBasically os-collect-config would keep a version along with its cache.\nWhenever a new version is detected, os-collect-config would set a value\nin the environment that informs the command \"this is a new version of\nconfig\". From that, scripts can do things like this:\n\nif [ -n \"$OS_CONFIG_NEW_VERSION\" ] ; then\n  service X restart\nelse\n  if !service X status ; then service X start\nfi\n\nThis would lay the groundwork for future abilities to compare old/new so\nwe can take shortcuts by diffing the two config versions. For instance\nif we look at old vs. new and we don\'t see any of the keys we care about\nchanged, we can skip restarting.\n\n\n','<FBC20477CD65A74893BA83CBF9F4AD9203194479@G5W2733.americas.hpqcorp.net>',NULL),('<1403812438-sup-5046@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 12:55:37',-25200,'2014-06-26 19:55:37',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','Excerpts from Chris Jones\'s message of 2014-06-26 12:37:55 -0700:\n> On 26 Jun 2014, at 20:20, Clint Byrum <clint at fewbar.com> wrote:\n> > we should just have a file in /var/run that\n> \n> > Whenever a new version is detected, os-collect-config would set a value\n> > in the environment that informs the command \"this is a new version of\n> \n> I like the idea of exposing the fact that a new config version has arrived, to o-r-c scripts, but...\n> \n> >  if !service X status ; then service X start\n> \n> ... I always worry when I see suggestions to have periodic state-assertion tasks take care of starting services that are not running, but in this case I will try to calm my nerves with the knowledge that service(1) is almost certainly talking to a modern init which is perfectly capable of supervising daemons :D\n\nLet\'s not focus on the else, but the primary condition which is \"If we\nchanged, restart\". The point is, if we didn\'t change, try not to be\ndisruptive.\n\n\n','<DA8A91F4-B13B-4F97-BE5F-97137359E682@tenshu.net>',NULL),('<1403813560.3652.77.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 21:12:40',3600,'2014-06-26 20:12:40',NULL,'[openstack-dev] [all] oslo.messaging 1.4.0.0a1 released','The Oslo team is pleased to announce the release of oslo.messaging\n1.4.0.0a1, the first pre-release in the 1.4.0 series for oslo.messaging\nduring the Juno cycle:\n\n  https://pypi.python.org/pypi/oslo.messaging/1.4.0.0a1\n\noslo.messaging provides an API which supports RPC and notifications over\na number of different messaging transports.\n\nFull details of the 1.4.0.0a1 release is available here:\n\n  http://docs.openstack.org/developer/oslo.messaging/#a1\n\nPlease report problems using the oslo.messaging bug tracker\nhttps://bugs.launchpad.net/oslo.messaging\n\nThanks to all those who contributed to the release!\n\nMark.\n\n\n\n',NULL,NULL),('<1403818503.32278.2.camel@graham-HP-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 21:35:06',0,'2014-06-26 21:35:06',NULL,'[openstack-dev] [infra] Gerrit downtime on Saturday, June 28,\n 2014','Hi,\n\nWe (designate) have 2 other repos that need to be moved as well\n\nstackforge/python-designateclient -> openstack/python-designateclient\nstackforge/designate-specs -> openstack/designate-specs\n\n- Graham\n\n\nOn Thu, 2014-06-26 at 09:33 -0700, James E. Blair wrote:\n\n\nHi,\n\nOn Saturday, June 28 at 15:00 UTC Gerrit will be unavailable for about\n15 minutes while we rename some projects.  Existing reviews, project\nwatches, etc, should all be carried over.  The current list of projects\nthat we will rename is:\n\nstackforge/designate -> openstack/designate\nopenstack-dev/bash8 -> openstack-dev/bashate\nstackforge/murano-repository -> stackforge-attic/murano-repository\nstackforge/murano-metadataclient -> stackforge-attic/murano-metadataclient\nstackforge/murano-common -> stackforge-attic/murano-common\nstackforge/murano-conductor -> stackforge-attic/murano-conductor\nstackforge/murano-tests -> stackforge-attic/murano-tests\n\nThis list is subject to change.\n\n-Jim\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<87d2dv4om2.fsf@meyer.lemoncheese.net>',NULL),('<1403878384.3785.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-27 14:13:04',0,'2014-06-27 14:13:04',NULL,'[openstack-dev]   [Blazar] June 27 Weekly meeting','I have an All Hands this noon, so I could attend only to the first half of Blazar meeting.\n\nPablo.\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n',NULL,NULL),('<1403884673-sup-4267@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-27 09:00:40',-25200,'2014-06-27 16:00:40',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','Excerpts from Macdonald-Wallace, Matthew\'s message of 2014-06-27 00:14:49 -0700:\n> Hi Clint,\n> \n> > -----Original Message-----\n> > From: Clint Byrum [mailto:clint at fewbar.com]\n> > Sent: 26 June 2014 20:21\n> > To: openstack-dev\n> > Subject: Re: [openstack-dev] [TripleO] os-refresh-config run frequency\n> >\n> \n> > So I see two problems highlighted above.\n> > \n> > 1) We don\'t re-assert ephemeral state set by o-r-c scripts. You\'re right, and\n> > we\'ve been talking about it for a while. The right thing to do is have os-collect-\n> > config re-run its command on boot. I don\'t think a cron job is the right way to\n> > go, we should just have a file in /var/run that is placed there only on a successful\n> > run of the command. If that file does not exist, then we run the command.\n> > \n> > I\'ve just opened this bug in response:\n> > \n> > https://bugs.launchpad.net/os-collect-config/+bug/1334804\n> \n> \n> Cool, I\'m more than happy for this to be done elsewhere, I\'m glad that people are in agreement with me on the concept and that work has already started on this.\n> \n> I\'ll add some notes to the bug if needed later on today.\n> \n> > 2) We don\'t re-assert any state on a regular basis.\n> > \n> > So one reason we haven\'t focused on this, is that we have a stretch goal of\n> > running with a readonly root partition. It\'s gotten lost in a lot of the craziness of\n> > \"just get it working\", but with rebuilds blowing away root now, leading to\n> > anything not on the state drive (/mnt currently), there\'s a good chance that this\n> > will work relatively well.\n> > \n> > Now, since people get root, they can always override the readonly root and\n> > make changes. <golem>we hates thiss!</golem>.\n> > \n> > I\'m open to ideas, however, os-refresh-config is definitely not the place to solve\n> > this. It is intended as a non-resident command to be called when it is time to\n> > assert state. os-collect-config is intended to gather configurations, and expose\n> > them to a command that it runs, and thus should be the mechanism by which os-\n> > refresh-config is run.\n> > \n> > I\'d like to keep this conversation separate from one in which we discuss more\n> > mechanisms to make os-refresh-config robust. There are a bunch of things we\n> > can do, but I think we should focus just on \"how do we re-assert state?\".\n> \n> OK, that\'s fair enough.\n> \n> > Because we\'re able to say right now that it is only for running when config\n> > changes, we can wave our hands and say it\'s ok that we restart everything on\n> > every run. As Jan alluded to, that won\'t work so well if we run it every 20\n> > minutes.\n> \n> Agreed, and chatting with Jan and a couple of others yesterday we came to the conclusion that whatever we do here it will require \"tweaking\" of a number of elements to safely restart services.\n> \n> > So, I wonder if we can introduce a config version into os-collect-config.\n> > \n> > Basically os-collect-config would keep a version along with its cache.\n> > Whenever a new version is detected, os-collect-config would set a value in the\n> > environment that informs the command \"this is a new version of config\". From\n> > that, scripts can do things like this:\n> > \n> > if [ -n \"$OS_CONFIG_NEW_VERSION\" ] ; then\n> >   service X restart\n> > else\n> >   if !service X status ; then service X start fi\n> > \n> > This would lay the groundwork for future abilities to compare old/new so we\n> > can take shortcuts by diffing the two config versions. For instance if we look at\n> > old vs. new and we don\'t see any of the keys we care about changed, we can\n> > skip restarting.\n> \n> I like this approach - does this require a new spec? If so, I\'ll start an etherpad to collect thoughts on it before writing it up for approval.\n\nI think this should be a tripleo spec. If you\'re volunteering write it,\nhooray \\o/. It will require several work items. Off the top of my head:\n\n- Add version awareness to os-collect-config\n- Add version awareness to all os-refresh-config scripts that do\n  disruptive things.\n- Add periodic command run to os-collect-config\n\nLet\'s call it \'re-assert-system-state\'. Sound good?\n\n\n','<FBC20477CD65A74893BA83CBF9F4AD9203195924@G5W2733.americas.hpqcorp.net>',NULL),('<1403899776-sup-7031@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-27 13:13:18',-25200,'2014-06-27 20:13:18',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','Excerpts from James Slagle\'s message of 2014-06-27 12:59:36 -0700:\n> Things are a bit confusing right now, especially with what\'s been\n> proposed.  Let me try and clarify (even if just for my own sake).\n> \n> Currently the choices offered are:\n> \n> 1. mysql percona with the percona tarball\n\nPercona Xtradb Cluster, not \"mysql percona\"\n\n> 2. mariadb galera with mariadb.org packages\n> 3. mariadb galera with rdo packages\n> \n> And, we\'re proposing to add\n> \n> 4. mysql percona with percona packages: https://review.openstack.org/#/c/90134\n> 5. mariadb galera with fedora packages https://review.openstack.org/#/c/102815/\n> \n> 4 replaces 1, but only for Ubuntu/Debian, it doesn\'t work on Fedora/RH\n> 5 replaces 3 (neither of which work on Ubuntu/Debian, obviously)\n> \n> Do we still need 1? Fedora/RH + percona tarball.  I personally don\'t think so.\n> \n> Do we still need 2? Fedora/RH or Ubuntu/Debian with galera packages\n> from maraidb.org. For the Fedora/RH case, I doubt it, people will just\n> use 5.\n> \n> 3 will be gone (replaced by 5).\n> \n> So, yes, I\'d like to see 5 as the default for Fedora/RH and 4 as the\n> default for Ubuntu/Debian, and both those tested in CI. And get rid of\n> (or deprecate) 1-3.\n>\n\nI\'m actually more confused now than before I read this. The use of\nnumbers is just making my head spin.\n\nIt can be stated this way I think:\n\nOn RPM systems, use MariaDB Galera packages.\n    If packages are in the distro, use distro packages. If packages are\n    not in the distro, use RDO packages.\n\nOn DEB systems, use Percona XtraDB Cluster packages.\n    If packages are in the distro, use distro packages. If packages are\n    not in the distro, use upstream packages.\n\nIf anything doesn\'t match those principles, it is a bug.\n\n> On Thu, Jun 26, 2014 at 5:30 PM, Giulio Fidente <gfidente at redhat.com> wrote:\n> > On 06/26/2014 11:11 AM, Jan Provaznik wrote:\n> >>\n> >> On 06/25/2014 06:58 PM, Giulio Fidente wrote:\n> >>>\n> >>> On 06/16/2014 11:14 PM, Clint Byrum wrote:\n> >>>>\n> >>>> Excerpts from Gregory Haynes\'s message of 2014-06-16 14:04:19 -0700:\n> >>>>>\n> >>>>> Excerpts from Jan Provazn?k\'s message of 2014-06-16 20:28:29 +0000:\n> >>>>>>\n> >>>>>> Hi,\n> >>>>>> MariaDB is now included in Fedora repositories, this makes it\n> >>>>>> easier to\n> >>>>>> install and more stable option for Fedora installations. Currently\n> >>>>>> MariaDB can be used by including mariadb (use mariadb.org pkgs) or\n> >>>>>> mariadb-rdo (use redhat RDO pkgs) element when building an image. What\n> >>>>>> do you think about using MariaDB as default option for Fedora when\n> >>>>>> running devtest scripts?\n> >>>>\n> >>>>\n> >>>> (first, I believe Jan means that MariaDB _Galera_ is now in Fedora)\n> >>>\n> >>>\n> >>> I think so too.\n> >>>\n> >>>>> Id like to give this a try. This does start to change us from being a\n> >>>>> deployment of openstck to being a deployment per distro but IMO thats a\n> >>>>> reasonable position.\n> >>>>>\n> >>>>> Id also like to propose that if we decide against doing this then these\n> >>>>> elements should not live in tripleo-image-elements.\n> >>>>\n> >>>>\n> >>>> I\'m not so sure I agree. We have lio and tgt because lio is on RHEL but\n> >>>> everywhere else is still using tgt IIRC.\n> >>>>\n> >>>> However, I also am not so sure that it is actually a good idea for\n> >>>> people\n> >>>> to ship on MariaDB since it is not in the gate. As it diverges from\n> >>>> MySQL\n> >>>> (starting in earnest with 10.x), there will undoubtedly be subtle issues\n> >>>> that arise. So I\'d say having MariaDB get tested along with Fedora will\n> >>>> actually improve those users\' test coverage, which is a good thing.\n> >>>\n> >>>\n> >>> I am favourable to the idea of switching to mariadb for fedora based\n> >>> distros.\n> >>>\n> >>> Currently the default mysql element seems to be switching [1], yet for\n> >>> ubuntu/debian only, from the percona provided binary tarball of mysql to\n> >>> the percona provided packaged version of mysql.\n> >>>\n> >>> In theory we could further update it to use percona provided packages of\n> >>> mysql on fedora too but I\'m not sure there is much interest in using\n> >>> that combination where people gets mariadb and galera from the official\n> >>> repos.\n> >>>\n> >>\n> >> IIRC fedora packages for percona xtradb cluster are not provided (unless\n> >> something has changed recently).\n> >\n> >\n> > I see, so on fedora it will be definitely easier and safer to just use the\n> > mariadb/galera packages provided in the official repo ... and this further\n> > reinforces my idea that it is the best option to use that by default for\n> > fedora\n> >\n> >\n> > --\n> > Giulio Fidente\n> > GPG KEY: 08D733BA\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHV77z_JO3n4HX8auToGOF1crEe0-az3=M7vs8MSorXr0BY4Hw@mail.gmail.com>',NULL),('<1403990133.4457.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-28 22:15:33',3600,'2014-06-28 21:15:33',NULL,'[openstack-dev] [all] oslo.messaging 1.4.0.0a1 released','On Fri, 2014-06-27 at 13:28 +0000, Paul Michali (pcm) wrote:\n> Mark,\n> \n> When would we be able to get a release of Oslo with 102909 fix in?\n> It?s preventing Jenkins passing for some commits in Neutron.\n\nI\'ve just pushed 1.4.0.0a2 with the following changes:\n\n 244a902 Fix the notifier example\n a7f01d9 Fix slow notification listener tests\n da2abaa Fix formatting of TransportURL.parse() docs\n 13fc9f2 Fix info method of ListenerSetupMixin\n 0cfafac encoding error in file\n 0102aa9 Replace usage of str() with six.text_type\n\nMark.\n\n\n\n','<2536AE97-ED4B-4568-A30A-97AC593662DA@cisco.com>',NULL),('<1403992154.4457.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-28 22:49:14',3600,'2014-06-28 21:49:14',NULL,'[openstack-dev] \'retry\' option','On Fri, 2014-06-27 at 17:02 +0100, Gordon Sim wrote:\n> A question about the new \'retry\' option. The doc says:\n> \n>      By default, cast() and call() will block until the\n>      message is successfully sent.\n> \n> What does \'successfully sent\' mean here?\n\nUnclear, ambiguous, probably driver dependent etc.\n\nThe \'blocking\' we\'re talking about here is establishing a connection\nwith the broker. If the connection has been lost, then cast() will block\nuntil the connection has been re-established and the message \'sent\'.\n\n>  Does it mean \'written to the wire\' or \'accepted by the broker\'?\n> \n> For the impl_qpid.py driver, each send is synchronous, so it means \n> accepted by the broker[1].\n> \n> What does the impl_rabbit.py driver do? Does it just mean \'written to \n> the wire\', or is it using RabbitMQ confirmations to get notified when \n> the broker accepts it (standard 0-9-1 has no way of doing this).\n\nI don\'t know, but it would be nice if someone did take the time to\nfigure it out and document it :)\n\nSeriously, some docs around the subtle ways that the drivers differ from\none another would be helpful ... particularly if it exposed incorrect\nassumptions API users are currently making.\n\n> If the intention is to block until accepted by the broker that has \n> obvious performance implications. On the other hand if it means block \n> until written to the wire, what is the advantage of that? Was that a \n> deliberate feature or perhaps just an accident of implementation?\n> \n> The use case for the new parameter, as described in the git commit, \n> seems to be motivated by wanting to avoid the blocking when sending \n> notifications. I can certainly understand that desire.\n> \n> However, notifications and casts feel like inherently asynchronous \n> things to me, and perhaps having/needing the synchronous behaviour is \n> the real issue?\n\nIt\'s not so much about sync vs async, but a failure mode. By default, if\nwe lose our connection with the broker, we wait until we can\nre-establish it rather than throwing exceptions (requiring the API\ncaller to have its own retry logic) or quietly dropping the message.\n\nThe use case for ceilometer is to allow its RPCPublisher to have a\npublishing policy - block until the samples have been sent, queue (in an\nin-memory, fixed-length queue) if we don\'t have a connection to the\nbroker, or drop it if we don\'t have a connection to the broker.\n\n  https://review.openstack.org/77845\n\nI do understand the ambiguity around what message delivery guarantees\nare implicit in cast() isn\'t ideal, but that\'s not what adding this\n\'retry\' parameter was about.\n\n>  Calls by contrast, are inherently synchronous, but at \n> present the retry controls only the sending of the request. If the \n> server fails, the call may timeout regardless of the value of \'retry\'.\n> \n> Just in passing, I\'d suggest that renaming the new parameter \n> max_reconnects, would make it\'s current behaviour and values clearer. \n> The name \'retry\' sounds like a yes/no type value, and retry=0 v. retry=1 \n> is the reverse of what I would intuitively expect.\n\nSounds reasonable. Would you like to submit a patch? Quick turnaround is\nimportant, because if Ceilometer starts using this retry parameter\nbefore we rename it, I\'m not sure it\'ll be worth the hassle.\n\nThanks,\nMark.\n\n\n\n','<53AD9587.9050101@redhat.com>',NULL),('<140403913.69.1382335893869.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-21 06:11:33',0,'2013-10-21 06:11:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #41','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/41/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4221a90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4221a90>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x43b3250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x43b3250>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-98f64849-ff31-4893-ac1e-f63822373ca9\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2013-10-20T06:10:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'20\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'20\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2013-10-22T06:10:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:10:59+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:10:59-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:10:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5749210>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1db96d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 71.53 secs:\n    14.82    TestScrubber.test_delayed_delete\n    14.72    TestGlanceControl.test_bouncing\n    14.18    TestGlanceControl.test_reload\n    14.02    TestGlanceControl.test_respawn\n    13.79    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 604.338s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-41\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.7\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.fmKbIEhFk8\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/41\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/41/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-11/41\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1404048833.4457.103.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-06-29 14:33:53',3600,'2014-06-29 13:33:53',NULL,'[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore','Hi Jonathan,\n\nOn Wed, 2014-06-25 at 11:10 -0500, Jonathan Bryce wrote:\n> Rather than going line-by-line through several of the previous\n> messages in the thread, I wanted to clarify the existing framework\n> that governs OpenStack trademark usage, which I think may address a\n> few of the comments. It can be a complicated issue because there are\n> several documents that are involved and they impact different areas of\n> trademark usage. Fair warning: this email is really long. = )\n\nThanks for doing this. I think it\'s fair to say that many of us are\ngrowing weary of debating the nuances of this stuff, but it\'s clear that\nconfusion (including my own confusion) persists. Your email really helps\nIMHO.\n\n> 1) The Bylaws - The Bylaws of the OpenStack Foundation\n> (http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/)\n> with Appendices are the overall governing documents for the\n> Foundation. They define the Project, the Membership, delegate\n> authority to the Technical Committee, the Board of Directors, and in\n> Section 7.3 point to the Trademark Policy\n> (http://www.openstack.org/brand/openstack-trademark-policy/) as the\n> governing document of trademark usage.\n> \n> The Bylaws also contain what has ended up being a much debated\n> sentence of varied interpretation in Section 4.1(b). I?m going to\n> deviate from just recounting solidly established fact for a minute to\n> explain how I have historically viewed 4.1(b) in the context of\n> overall trademark usage, the history of some of the terms used, and\n> the drafting of the Bylaws.\n> \n> The context of Section 4.1 is \"General Powers.\" This section is meant\n> to define at the very highest level, the overall breakdown of\n> responsibility in the Foundation.\n> \n> Section 4.1(a) contains a pretty standard corporate line stating that\n> the affairs of the Foundation are overseen by its Board of Directors:\n> \"The business and affairs of the Foundation shall be managed by or\n> under the direction of a Board of Directors, who may exercise all of\n> the powers of the Foundation except as otherwise provided by these\n> Bylaws.\"\n> \n> Section 4.1(b) designates the Technical Committee as being responsible\n> for \"The management of the technical matters relating to the OpenStack\n> Project.?? \n> It also defines the term \"OpenStack Project\" to include work produced\n> by the technical community and governed by the Technical Committee,\n> including \"a \'Core OpenStack Project,\' library projects, gating\n> projects and supporting projects.?\n> \n> In the very early days of OpenStack, July of 2010, there were only 2\n> projects: Compute and Object Storage. Within the first 6 months, other\n> projects got off the ground and we created the initial rudimentary\n> incubation process. The Project Policy Board was the governance body\n> at the time, and we created a delineation between software that was an\n> established part of OpenStack (called ?core? projects) and software\n> that was getting started and may become an established part later\n> (called ?incubated? projects). All of this software was intended to be\n> used to build a public or private cloud. It was all ?cloud software.\"\n> \n> It?s hard to picture this now with our current level of development\n> activity, but at the time, there were only a few dozen total\n> contributors across all of OpenStack, and the systems for managing the\n> development process were MUCH more basic. As the number of developers\n> and contributions grew rapidly and we begin to commit more effort to\n> automated testing and CI, the community started to develop software\n> that made the continued growth and improved quality possible. This\n> software enhanced the development process of building OpenStack, but\n> was not ?cloud software? in the sense that it was never meant to be\n> distributed as OpenStack to build a public or private cloud. These\n> were the library, gating and supporting projects. These were being\n> formally recognized by the technical governance right around the time\n> that we were forming the Foundation and drafting the Bylaws in 2012.\n> \n> In writing the Bylaws, the defined term ?OpenStack Project? refers to\n> the whole body of governed OpenStack software. The defined term ?Core\n> OpenStack Project? refers to the specific pieces that were the\n> original two components plus the later components that had gone\n> through the incubation and core graduation process. The existing core\n> projects at the time of drafting are listed at the end of 4.1(b)\n> \"Block Storage, Compute, Dashboard, Identity Service, Image Service,\n> Networking, and Object Storage.? No changes to the set of core\n> projects have been made since that time.\n> \n> At the time of drafting the Bylaws, we included a process for\n> modifying what comprised the ?Core OpenStack Project,? which can be\n> seen in section 4.13(b): \"The Technical Committee shall have the\n> authority to determine the modules for addition, combination, split or\n> deletion from the OpenStack Project except for modules of the Core\n> OpenStack Project (as defined in Section 4.1(b) above) which shall be\n> managed as provided below. For modules of the Core OpenStack Project,\n> the Technical Committee may recommend to the Board of Directors the\n> modules for addition, combination, split or deletion from the Core\n> OpenStack Project. Except as provided below, the Board of Directors\n> shall consider only those additions, combinations, splits or deletions\n> that are recommended by the Technical Committee, but shall have the\n> sole authority to approve or reject such additions, combinations,\n> splits and deletions from the Core OpenStack Project.?\n> \n> Basically, the TC is responsible for the scope of the overall\n> \"OpenStack Project,\" but for any changes to the ?Core OpenStack\n> Project,? the Board of Directors must also approve the recommended\n> change from the Technical Committee.\n\nAnd I guess one way of looking at how that has evolved since is that we\n(the TC, at least) now see the \"Integrated OpenStack Project\" as being\nthe \"cloud software\" which has passed through our integration process.\nIt is the subset of the OpenStack Project which is intended to be used\nto provide public and private cloud services.\n\nThis is a pretty straightforward clarification of TC powers - the TC\ndetermines the scope of the OpenStack Project and is responsible for the\nincubation process. Whether a project is \"cloud software\" is pretty much\na question of fact, not a policy decision. So, we needed a term to\ndescribe \"cloud software\" projects which we\'ve included in the OpenStack\nProject and graduated from the incubation process, but which have not\nyet been through a process by which the Board of Directors included it\nin the \"Core OpenStack Project\". We now call that \"Integrated\".\n\nIt does beg the question, what exactly then is the purpose of this \"Core\nOpenStack Project\" idea. I\'ve always felt it was strictly related to\nsome trademark concepts, and strictly a Board of Directors matter since\ntrademark policy decisions are also a Board matter.\n\n(You raise an interesting point on that, though - the Trademark Policy\nisn\'t something the Board can change of its own accord, so their powers\nare in relation to the trademark license agreements which the Foundation\nstaff take much of the responsibility for)\n\n> This brings us back to Section 4.1(b). This section gives explicit\n> permission to refer to the components of the ?Core OpenStack Project\"\n> with OpenStack trademarks: \"The Core OpenStack Project means the\n> software modules which are part of an integrated release and for which\n> an OpenStack trademark may be used.? The next sentence is the hotly\n> debated one: \"The other modules which are part of the OpenStack\n> Project, but not the Core OpenStack Project may not be identified\n> using the OpenStack trademark except when distributed with the Core\n> OpenStack Project.\"\n> \n> The intent of Section 4.1 is not to define the totality of allowed\n> trademark usage. The Bylaws are explicit in Section 7.3 that the\n> referenced Trademark Policy is the governing document for overall\n> trademark usage. The intent of this section was to provide a\n> distinction between the OpenStack community-developed software that is\n> developed and made available to build OpenStack clouds, and the\n> OpenStack community-developed software that is developed for other\n> purposes (e.g. testing, CI). If you take a project like Jenkins Job\n> Builder (JJB), for instance, it is developed within the OpenStack\n> Infra program. However, if you were to take only JJB, and create a\n> service that took YAML files and configured Jenkins machines, that is\n> very different from creating an ?OpenStack Cloud.? It would be\n> confusing to the market to launch that service and say ?I?m running\n> OpenStack,? so the intent of this portion of 4.1(b) was to draw a line\n> between the community-developed, TC-governed projects that are used to\n> build an instance of ?OpenStack? and the projects that are not.\n> \n> The controversial aspect comes in when you start talking about the\n> modules that are intended to be used to be cloud services but that are\n> not part of core (e.g. Heat). In my reading, these projects fall under\n> the except clause from the sentence above: \"except when distributed\n> with the Core OpenStack Project.? While Heat may not be a part of the\n> Core OpenStack Project because it has not gone through the process in\n> 4.13(b), it is distributed as part of the integrated release with the\n> entirety of the Core OpenStack Project. In my mind, it creates a very\n> odd mismatch for the community to work for six months on the code, do\n> an integrated release of OpenStack software, and for some pieces of\n> that development effort to not actually be ?OpenStack.? By my\n> recollection, this is the exact scenario for which we added the\n> ?except? to the sentence in question during drafting the Bylaws. So we\n> could talk about all of the components of the OpenStack integrated\n> release as being part of OpenStack. I?ve yet to hear a sensible\n> alternate explanation for the purpose or meaning of the exception in\n> that sentence.\n\nSo, your summary of the \"except\" clause is basically that it allows what\nwe now call the \"Integrated OpenStack Project\" to be described as\nOpenStack. That all modules in the integrated release can be described\nas OpenStack because they are distributed together.\n\n> So then, you may ask, what is the difference between Core and\n> Integrated when it comes to the trademark guidelines. We?ll get to\n> that in just a moment. Let?s look at the other documents of the\n> trademark framework.\n> \n> 2) The Trademark Policy - The Trademark Policy is the primary\n> governing document for OpenStack mark usage. The policy has not\n> changed since the Foundation was created, and would require a high-bar\n> amendment process as defined in Section 9.2(d). This high bar was put\n> in place because we saw the OpenStack trademark as a community asset\n> in non-commercial contexts.\n> \n> The policy describes and sets out explicitly the right of the\n> community to use the marks for community, non-commercial,\n> community-building purposes. It also prohibits commercial,\n> attention-getting, and branding usage of OpenStack marks without a\n> license from the Foundation. The OpenStack Foundation has the power to\n> grant and revoke the commercial-use licenses and to specify\n> eligibility requirements for those licenses. It lays out several of\n> the licensing programs that existed at the time of drafting but also\n> states \"Other licensing programs may be available for a specific use.\n> Please contact us at logo at openstack.org for obtaining the applicable\n> OpenStack Trademark License.? That leads us to the third piece of the\n> framework...\n\nThis is a hugely important distinction and one that I\'d forgotten about.\nThe DefCore process is not about changing the Trademark Policy as\ndefined it in the bylaws, it is about evolving and clarifying the\nrequirements for some of our Trademark Licenses.\n\n> 3) Commercial Use Trademark Licenses - There are several commercial\n> use licensing programs that the Foundation administers. These can be\n> seen in the side navigation on the Trademark Policy page. These\n> licenses allow commercial entities to incorporate OpenStack marks into\n> their product marketing?for instance Acme Cloud Solution Powered by\n> OpenStack or Acme Training for OpenStack.\n\nIn terms of publicly visible trademark license programs that are\nrelevant to the DefCore process, I guess the requirements for use of the\n\"OpenStack Powered\" logo is the relevant license? And I see that license\nisn\'t just about the logo, but also permission to including the\nOpenStack Word Mark and \"Powered\" in their product name, e.g. Acme Cloud\nSolution Powered by OpenStack, as you describe.\n\nHowever, see plenty of OpenStack products in the market place who use\nthe Word Mark in different ways:\n\n  http://www.openstack.org/marketplace/distros/\n\n    HP Helion OpenStack?\n    Red Hat Enterprise Linux OpenStack Platform\n    Ubuntu OpenStack \n    Metacloud OpenStack\n    Mirantis OpenStack\n    etc.\n\nHave each of these companies obtained a different Word Mark license\nagreement (i.e. something other than the \"OpenStack Powered\" license)\nfrom the Foundation? Do those licenses essentially have the same\nrequirements as the \"OpenStack Powered\" license, except they allow\nslightly different usage of the Word Mark?\n\nClarifying exactly which trademark licenses DefCore is relevant to turns\nout to be pretty important. If you look at e.g.\n\n  https://wiki.openstack.org/wiki/Governance/DefCoreCommittee\n    creating the minimum standards for products labeled \"OpenStack.\"\n\n  https://wiki.openstack.org/wiki/Governance/CoreDefinition\n    Implementations that are Core can use OpenStack trademark \n    (OpenStack?) \n\nyou\'d be forgiven in thinking that this is a much broader thing than\nsimply the \"OpenStack Powered\" licenses, and the only place I\'ve seen\nthis made more clear is here:\n\n  http://www.slideshare.net/rhirschfeld/what-is-openstack-defcore-altanta-conference/13\n    \"OpenStack Powered\"\n\n> When licensing a trademark, it is important from a legal perspective\n> to have some quality control around the usage so we can still claim\n> and defend the trademark. It?s also important to ensure that there is\n> clarity in the market. Each of the commercial-use licenses have a set\n> of requirements to provide this quality control. For instance, for the\n> OpenStack Powered agreement, your product needs to run OpenStack,\n> including at least the Compute and Object Storage components, it must\n> be running a relatively recent release, it must expose the OpenStack\n> APIs, you must be clear about which OpenStack components and versions\n> are included, and you must pass tests that validate its compatibility.\n> \n> Back to the earlier question about the difference between Core and\n> Integrated. Once the Foundation was established and these processes\n> and governance bodies had gotten settled in, the intent was to replace\n> the specific enumeration of two projects (Compute and Object Storage)\n> in these licenses with a reference to the Core OpenStack Project.\n> Then, the Core OpenStack Project would become the common set of\n> required software and APIs that commercial products must incorporate\n> to be able to license OpenStack marks. It would be the baseline for\n> compatibility and interoperability. So while the OpenStack release may\n> contain any number of projects, they may not all be required to be\n> present in every commercial implementation and distribution of\n> OpenStack and licensed the OpenStack trademark. A change like this is\n> part of the Foundation-administered license, rather than an amendment\n> to the Bylaws or Trademark Policy.\n\nThe way DefCore has evolved, the Bylaws concept of the \"Core OpenStack\nProject\" becomes pretty much irrelevant - if its only purpose was to be\nreferenced in the trademark licenses and we no longer plan to reference\nit in the trademark licenses, then it no longer has a purpose?\n\nInstead, we now have the concept of \"designated sections\", and the TC\nand PTLs are being asked to help DefCore figure out what code should be\n\"designated\". So far, we\'ve come up with this attempt at guidelines:\n\n  http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20140402-defcore-designated-sections-guidelines.rst\n\nwhich, in retrospect, are still fairly ambiguous and confusing. The\nquestion of which code should be designated is not simply a technical\nquestion, it is a policy question. And it is not yet clear what values\nare driving the desired policy outcome.\n\nThe main question around policy and values is the \"project design\nexplicitly intended this section to be replaceable\" part. Projects may\nhave a \"driver\" or \"plugin\" layer and you could argue that this layer is\nintended to make the code underneath it \"replaceable\", but we may have\nseveral upstream drivers or plugins. Is the intended outcome of DefCore\nthat the \"OpenStack Powered\" trademark license allows proprietary\ndrivers or plugins, only open-source drivers or plugins, or only\nupstream drivers or plugins?\n\nIf the intent is for \"non-designated sections\" of code to be replaceable\nby proprietary implementations under the \"OpenStack Powered\" trademark\nlicense, then the TC and PTLs are being asked \"which sections of code\nshould the trademark license allow proprietary alternatives?\". That\nseems like a bizarrely loaded and charged trademark policy question,\nrather than a purely technical question.\n\n> The testing was also a carryover from pre-Foundation days when it was\n> being worked on by the Project Policy Board. The licenses still\n> contain a reference to a test suite approved by the Technical\n> Committee. This test suite has yet to be implemented, however, once in\n> place, it can fit into the existing license agreements.\n> \n> \n> \n> From my understanding, DefCore is hoping to clarify the debated areas\n> in Bylaws through some amendments,\n\nPersonally I\'m not paying too much attention to the Bylaws aspect of\nthis right now since it seems the least pressing - DefCore plans to make\nprogress on the other aspects without any Bylaws changes.\n\n>  provide the missing testing that?s already mentioned in the license\n> agreements,\n\nThis is the part which seems the furthest along. It is also the part\nwhich is most important to driving improved interoperability.\n\n> and come up with an aggregation of which code across integrated\n> projects is required to be included in a commercial product, replacing\n> the current enumeration of two projects.\n\nThis part still seems the most controversial and is now somewhat stalled\nbecause the hugely charged policy question has been punted to the TC and\nPTLs.\n\n>  Getting into the details of that process is beyond the scope of what\n> I was hoping to touch on in this email (it?s arguably too long\n> already). I know there?s going to be a dedicated TC/DefCore meeting\n> next week that will hopefully clarify the purpose and path forward\n> even more.\n\nYes, I think the meeting is necessary and is going to be useful. Your\nmail provides really useful framing for that discussion.\n\nThanks,\nMark.\n\n\n\n','<5D25E114-E069-41E0-A041-221C3DC374AD@openstack.org>',NULL),('<1404048856.4457.105.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-06-29 14:34:16',3600,'2014-06-29 13:34:16',NULL,'[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore','On Wed, 2014-06-25 at 13:57 -0500, Mark Collier wrote:\n> Great summary Jonathan.  \n> \n> TL;DR if you read to the end I mention Ceph!\n> \n> Here are the key points which relate to the debate at hand.  \n> \n> 1)  The TM policy itself simply requires companies to get a license\n> for commercial use, but does not dictate what the contents of those\n> licenses should be. The requirements inside of those license\n> agreements can be updated as needed by the Foundation.  \n> \n> 2)  The current product requirements in those agreements are\n> essentially ?include entirety of Nova & Swift from a recent release\n> and pass some FITs tests approved by the TC when available.\"  This is\n> outdated and insufficient given how fast the project has expanded, but\n> it is the status quo. Any improvement on this status quo is progress\n> in my book, fwiw.\n\nYep, agree.\n\n> 3)  The real question is:  what should those technical requirements be\n> to call your product ?OpenStack? (i.e. to get a license)?\n\nWe should be careful of our language around this - nobody gets to call\ntheir product \"OpenStack\". This is about the technical requirements for\nproducts to use the \"OpenStack Powered\" logo, call their product \"Acme\nCloud Software Powered by OpenStack\" or similar, or (I assume this bit -\nsee my question to Jonathan) call their product \"Acme OpenStack\".\n\n> In particular, how should the code inclusion requirements evolve?\n\nYes, this is certainly the big question.\n\nThe way we\'ve structured OpenStack governance, we have made the Board of\nDirectors ultimately responsible for this important policy question. The\nDefCore committee, the Foundation staff, the TC, PTLs, etc. cannot make\nthis decision unless the board chooses to delegate the decision, which\nit hasn\'t done AFAICT.\n\nThis wasn\'t my preferred structure, but the most easily understood\nrationale for it is that the Foundation Board is the body best suited to\nmaking the difficult tradeoffs required to grow the commercial ecosystem\naround OpenStack.\n \n> If we can come to a consensus on an answer to that question,\n\nTo be clear - consensus is not required. The Board can choose to proceed\nto instruct the Foundation staff how the trademark licenses should be\nupdated without any wider community consensus.\n\n(I should say AIUI - I\'m happy for someone to explain how that isn\'t the\ncase if my understanding is wrong)\n\n>  we (the foundation staff) can work with our trademark counsel to\n> update the agreements. That won?t be a lengthy process, as the product\n> requirements are all in one section of the agreements.\n> \n> The trick is coming to a consensus on what those requirements should\n> be.  Amending the Bylaws to clear up the admittedly confusing language\n> is a nice thing to pursue for the sake of clarity, but I think it?s a\n> red herring for the more pressing matter.\n\nYep, agree. Jonathan\'s clarification about the Trademark Policy and\nindividual trademark license agreements makes that clear.\n\n> Defcore was formed to come up with that answer, in an open community\n> involved way, in conjunction with the TC and PTLs and any other\n> stakeholders.  I don?t want to try to summarize the current state of\n> Defcore in this email, but in general the direction is to express the\n> requirements in terms of capabilities as well as tests, rather than\n> projects per se, with code requirements that are likely to be less\n> than 100% within each particular project.  \n\nA simple example of this shows how the meat of these questions are\npolicy decisions around growing the commercial ecosystem rather than\ntechnical ones. Cinder has a volume driver layer and quite a number of\ndrivers are part of the OpenStack Project and included in the Integrated\nRelease.\n\nThe intent of \"designated sections\" seems to be to avoid placing any\nrestrictions on vendors of \"OpenStack Powered\" products around what\nvolume driver code they use or ship. The code could be pristine drivers\nfrom upstream, heavily patched versions of upstream drivers, open-source\nbut not upstream drivers, or completely proprietary drivers.\n\nCinder\'s scheduler, and various parts of cinder\'s scheduler, is also\nextremely pluggable. If we said that the scheduler is a \"designated\nsection\" but the scheduler filters are not designated, we\'re saying that\nproprietary filters should be allowed under the \"OpenStack powered\"\ntrademark license. Under what basis would the TCs or PTLs make that\njudgment call, given that it\'s a question of what is best for growing\nthe commercial ecosystem?\n\n> The question that is raised when we consider going below 100% of a\n> particular project, is do you eventually consider 0%, as long as the\n> APIs are implemented?  Let?s say, hypothetically, your product or\n> cloud service exposes the Swift API but uses an alternative back end,\n> say Ceph for example.  Is that still ?OpenStack??  Let?s face it,\n> that?s the question on a lot of people?s minds.  The Defcore committee\n> has approached these questions holistically by starting with\n> documenting criteria for making such weighty decisions.\n\nI think the criteria for deciding which API capabilities are required\nhas been well documented and looks to be giving a very reasonable\noutcome. However, the process for deciding \"designated sections\" looks\nincreasingly backwards to me.\n\nIn the case of Swift, the conclusion so far seems to be that certain\nSwift APIs could be considered required capabilities, but *only if* the\nTC decides that 0% of Swift\'s code is designated.\n\n  https://etherpad.openstack.org/p/DefCoreLighthouse.F2F\n\n  Picking designated sections for Swift > we are in a position to choose\n  0 or 100 without any intermdiate.\n\n  DefCore agrees that the TC is the deciding body for designated\n  sections.\n\n  Official position, DefCore asks TC to resolve Swift D.S. question.\n\n  ACTION > Rob to take to TC that if Swift has any designated sections\n  then the DefCore committee will likely recommending omitting the\n  \"object-*\" capabilities from core.\n\ni.e. that DefCore sees that it is impossible for the \"OpenStack Powered\"\ntrademark license to require the use of any Swift code, and that if the\nTC thinks any code should be required then DefCore will recommend that\nno APIs are required, effectively resulting in no code being required\nanyway.\n\nThe starting assumption that \"the TC is the deciding body for designated\nsections\" just seems (and has always seemed) wrong to me, particularly\nif it results in the Board removing capabilities from the \"required\ncapabilities\" list because the Board disagrees with the TC\'s opinion\nthat the code for those APIs should be required.\n\nThanks,\nMark.\n\n\n\n','<58BA1758-CF0C-4E81-9ECD-CC5668FED000@openstack.org>',NULL),('<1404051589.4457.128.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-06-29 15:19:49',3600,'2014-06-29 14:19:49',NULL,'[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore','On Sun, 2014-06-29 at 14:34 +0100, Mark McLoughlin wrote:\n> On Wed, 2014-06-25 at 13:57 -0500, Mark Collier wrote:\n\n> > The question that is raised when we consider going below 100% of a\n> > particular project, is do you eventually consider 0%, as long as the\n> > APIs are implemented?  Let?s say, hypothetically, your product or\n> > cloud service exposes the Swift API but uses an alternative back end,\n> > say Ceph for example.  Is that still ?OpenStack??  Let?s face it,\n> > that?s the question on a lot of people?s minds.  The Defcore committee\n> > has approached these questions holistically by starting with\n> > documenting criteria for making such weighty decisions.\n> \n> I think the criteria for deciding which API capabilities are required\n> has been well documented and looks to be giving a very reasonable\n> outcome. However, the process for deciding \"designated sections\" looks\n> increasingly backwards to me.\n\nA fair question would be \"what do you think is a not-backwards process\nfor answering the question of what code should be required under the\nOpenStack Powered trademark license?\"\n\nGiven that the board is the deciding body for that question, but they/we\nare looking for the widest possible consultation on it, how about:\n\n  * The Board comes up with a very rough strawman set of \"required \n    code\" based on its very rough understanding of the technical\n    architecture and the current commercial ecosystem. It could be the \n    Defcore committee delegated to draft this strawman and the \n    \"required code\" could still be called \"designated sections\"\n\n  * The wider community (including the TC and PTLs) is asked to give its\n    input in the form of questions - i.e. \"what are we missing?\"\n\n  * The Board openly answers those questions (perhaps DefCore triages\n    and answers the straightforward ones) and those answers effectively \n    determine the final \"required code\" policy.\n\n> In the case of Swift, the conclusion so far seems to be that certain\n> Swift APIs could be considered required capabilities, but *only if* the\n> TC decides that 0% of Swift\'s code is designated.\n> \n>   https://etherpad.openstack.org/p/DefCoreLighthouse.F2F\n> \n>   Picking designated sections for Swift > we are in a position to choose\n>   0 or 100 without any intermdiate.\n> \n>   DefCore agrees that the TC is the deciding body for designated\n>   sections.\n> \n>   Official position, DefCore asks TC to resolve Swift D.S. question.\n> \n>   ACTION > Rob to take to TC that if Swift has any designated sections\n>   then the DefCore committee will likely recommending omitting the\n>   \"object-*\" capabilities from core.\n> \n> i.e. that DefCore sees that it is impossible for the \"OpenStack Powered\"\n> trademark license to require the use of any Swift code, and that if the\n> TC thinks any code should be required then DefCore will recommend that\n> no APIs are required, effectively resulting in no code being required\n> anyway.\n\nIn the case of Swift, the strawman from the Board (or DefCore) might be:\n\n  The following capabilities should be required of OpenStack clouds:\n\n    objectstore-container\n    objectstore-container-quota\n    objectstore-container-acl\n    objectstore-acct-services\n    objectstore-container-staticweb\n\n  However, there are several commercial OpenStack products which \n  provide a faithful implementation of these capabilities without using \n  any of Swift\'s code. Given the way Swift is designed, we do not think \n  these products could be required to use a subset of Swift\'s code \n  without forcing them to choose between using all of Swift\'s code or \n  losing their license to use the \"OpenStack Powered\" trademark. We \n  feel many of these products are high-quality, valued parts of the \n  OpenStack ecosystem and deserve to be able to describe themselves as \n  \"OpenStack Powered\". For that reason, we feel that the trademark\n  license agreement should not require the use of any Swift code but we \n  will review this situation each release as Swift evolves to be more \n  pluggable.\n\nThe wider community would be invited to ask whether certain technical\ndetails had been considered (e.g. \"have you considered requiring xyz\npart of Swift\'s API layer, since it\'s possible to plug any other object\nstorage system behind that?\").\n\n> The starting assumption that \"the TC is the deciding body for designated\n> sections\" just seems (and has always seemed) wrong to me, particularly\n> if it results in the Board removing capabilities from the \"required\n> capabilities\" list because the Board disagrees with the TC\'s opinion\n> that the code for those APIs should be required.\n\nWhat I\'m suggesting above as a process more accurately reflects the TC\nand PTLs involvement here. There is a default position (e.g. no Swift\ncode can be required) based on an (incomplete?) technical understanding\nand a (hopefully) pretty complete understanding of the commercial\necosystem. The TC and PTLs are effectively being asked to provide some\ntechnical oversight to make sure important technical details aren\'t\nbeing missed. It\'s important that the wider community is invited to\nparticipate in that technical oversight, since the TC and PTLs may not\neven be the most motivated to provide thoughtful assistance on this.\n\nMark.\n\n\n\n','<1404048856.4457.105.camel@sorcha>',NULL),('<1404154901-sup-4723@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 12:02:09',-25200,'2014-06-30 19:02:09',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','Excerpts from Michael Kerrin\'s message of 2014-06-30 02:16:07 -0700:\n> I am trying to finish off https://review.openstack.org/#/c/90134 - percona xtradb \n> cluster for debian based system.\n> \n> I have read into this thread that I can error out on Redhat systems when trying to \n> install percona and tell them to use mariadb instead, percona isn\'t support here. Is \n> this correct?\n> \n\nProbably. But if CI for Fedora breaks as a result you\'ll need a solution\nfirst.\n\n\n','<3821239.CPmfzI0oTD@michael-hp-z400-workstation>',NULL),('<1404157224.60086.YahooMailNeo@web142802.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-30 12:40:24',-25200,'2014-06-30 19:40:24',NULL,'[Openstack-operators] [nova][baremetal] Is it proper to deploy\n	hybrid KVM + baremetal instances under a single OpenStack controller','Right now we keep our VM and BM clusters separate, however in the not-too-distant future i\'m looking at combining the two. I don\'t think you\'ll have any issues combining them.\n\n\n-James\n\n?\n:)=\n\n\nOn Sunday, June 29, 2014 11:44 PM, Taurus Cheung <Taurus.Cheung at harmonicinc.com> wrote:\n \n\n\nHi,\n?\nIn my datacenter, I have some application use case that requires both VM and baremetal instances. So I have setup KVM compute nodes and baremetal compute nodes under a single OpenStack controller. As a result, by using a single Heat template, with corresponding nova flavor for instances, I can have a single Heat stack that is mix of KVM VM and baremetal instances.\n?\nI would like to verify whether it is a proper use case to deploy hybrid KVM + baremetal instances under a single OpenStack controller? Any example setup that is similar with what I am doing? Thanks.\n?\nRegards,\nTaurus\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140630/559f189e/attachment.html>\n\n','<0D1B0C62A4A3BC4181D065E1AB698BAC2B60D7416E@EXCH-CMS.hlit.local>',NULL),('<1404163048.15218.10.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 22:17:28',3600,'2014-06-30 21:17:28',NULL,'[openstack-dev] [OpenStack-Dev] OSLO messaging update and\n icehouse config files','On Mon, 2014-06-30 at 12:04 -0600, John Griffith wrote:\n> Hey Everyone,\n> \n> \n> So I sent a note out yesterday asking about config changes brought in\n> to Icehouse due to the OSLO Messaging update that went out over the\n> week-end here.  My initial email prior to realizing the update that\n> caused the problem was OSLO Messaging update here [1].\n\n(Periodic reminder that Oslo is not an acronym)\n\n> In the meantime I tried updating the cinder.conf sample in Cinder\'s\n> stable Icehouse branch, but noticed that py26 doesn\'t seem to pick up\n> the changes when running the oslo conf generation tools against\n> oslo.messaging.  I haven\'t spent any time digging into this yet, was\n> hoping that perhaps somebody from the OSLO team or somewhere else\n> maybe had some insight as to what\'s going on here.\n> \n> \n> Here\'s the patch I submitted that shows the failure on py26 and\n> success on py27 [2].  I\'ll get around to this eventually if nobody\n> else knows anything off the top of their head.\n> \n> \n> Thanks,\n> John\n> \n> \n> [1]: http://lists.openstack.org/pipermail/openstack-dev/2014-June/038926.html\n> [2]: https://review.openstack.org/#/c/103426/\n\nOk, that new cinder.conf.sample is showing changes caused by these\noslo.messaging changes:\n\n  https://review.openstack.org/101583\n  https://review.openstack.org/99291\n\nBoth of those changes were first released in 1.4.0.0a1 which is an alpha\nversion targeting Juno and are not available in the 1.3.0 Icehouse\nversion - i.e. 1.4.0.0a1 should not be used with stable/icehouse Cinder.\n\nIt seems 1.3.0 *is* being used:\n\n  http://logs.openstack.org/26/103426/1/check/gate-cinder-python26/5c6c1dd/console.html\n\n    2014-06-29 19:17:50.154 | oslo.messaging==1.3.0\n\nand the output is just confusing:\n\n  2014-06-29 19:17:49.900 | --- /tmp/cinder.UtGHjm/cinder.conf.sample	2014-06-29 19:17:50.270071741 +0000\n  2014-06-29 19:17:49.900 | +++ etc/cinder/cinder.conf.sample	2014-06-29 19:10:48.396072037 +0000\n\n  ...\n\n  2014-06-29 19:17:49.903 | +[matchmaker_redis]\n  2014-06-29 19:17:49.903 | +\n\ni.e. it\'s showing that the file you proposed was generated with\n1.4.0.0a1 and the file generated during the test job was generated with\n1.3.0. Which is what I\'d expect - the update you proposed is not\nappropriate for stable/icehouse.\n\nSo why is the py27 job passing?\n\n  http://logs.openstack.org/26/103426/1/check/gate-cinder-python27/7844c61/console.html\n\n  2014-06-29 19:21:12.875 | oslo.messaging==1.4.0.0a2\n\nThat\'s the problem right there - 1.4.0.0a2 should not be getting\ninstalled on the stable/icehouse branch. I\'m not sure why it is. Someone\non #openstack-infra could probably help figure it out.\n\nThanks,\nMark.\n\n\n\n\n','<CA+qL3LW6PUCs=X7TCgdwRWh2nASOO3bb-xxJA11ktxkKY=TwJg@mail.gmail.com>',NULL),('<1404163707.15218.16.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 22:28:27',3600,'2014-06-30 21:28:27',NULL,'[openstack-dev] [infra][oslo][neutron] Need help getting\n oslo.messaging 1.4.0.0a2 in global requirements','On Mon, 2014-06-30 at 16:52 +0000, Paul Michali (pcm) wrote:\n> I have out for review 103536 to add this version to global\n> requirements, so that Neutron has an oslo fix (review 102909) for\n> encoding failure, which affects some gate runs. This review for global\n> requirements is failing requirements check\n> (http://logs.openstack.org/36/103536/1/check/check-requirements-integration-dsvm/6d9581c/console.html#_2014-06-30_12_34_56_921). I did a recheck bug 1334898, but see the same error, with the release not found, even though it is in PyPI. Infra folks say this is a known issue with pushing out pre-releases.\n> \n> \n> Do we have a work-around?\n> Any proposed solution to try?\n\nThat makes two oslo alpha releases which are failing\nopenstack/requirements checks:\n\n  https://review.openstack.org/103256\n  https://review.openstack.org/103536\n\nand an issue with the py27 stable/icehouse test jobs seemingly pulling\nin oslo.messaging 1.4.0.0a2:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-June/039021.html\n\nand these comments on IRC:\n\n  http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2014-06-30.log\n\n  2014-06-30T15:27:33  <pcm__> hi. Need help with getting latest oslo.messaging release added to global requirements. Can someone advise on the issues I see.\n  2014-06-30T15:28:06  <mordred> pcm__: there are issues adding oslo pre-releases to the mirror right now - we\'re working on a solution ... so you\'re not alone at least :)\n  2014-06-30T15:29:02  <pcm__> mordred: Jenkins failed saying that it could not find the release, but it is available.\n  2014-06-30T15:29:31  <bknudson> pcm__: mordred: is the fix to remove the check for --no-use-wheel in the check-requirements-integration-dsvm ?\n  2014-06-30T15:29:55  <mordred> bknudson: nope. it\'s to completely change our mirroring infrastructure :)\n\nPresumably there\'s more information somewhere on what solution infra are\nworking on, but that\'s all I got ...\n\nWe knew this pre-release-with-wheels stuff was going to be a little\nrocky, so this isn\'t surprising. Hopefully it\'ll get sorted out soon.\n\nMark.\n\n\n\n\n','<049AE599-108F-44F9-A22B-02CACC136D36@cisco.com>',NULL),('<1404164159-sup-6444@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 14:37:30',-25200,'2014-06-30 21:37:30',NULL,'[openstack-dev] [all][specs] Please stop doing specs for any\n	changes in projects','Excerpts from Boris Pavlovic\'s message of 2014-06-30 14:11:08 -0700:\n> Hi all,\n> \n> Specs are interesting idea, that may be really useful, when you need to\n> discuss large topics:\n> 1) work on API\n> 2) Large refactoring\n> 3) Large features\n> 4) Performance, scale, ha, security issues that requires big changes\n> \n> And I really dislike idea of adding spec for every patch. Especially when\n> changes (features) are small, don\'t affect too much, and they are optional.\n> It really kills OpenStack. And will drastically slow down process of\n> contribution and reduce amount of contributors.\n\nWho says there needs to be a spec for every patch?\n\nI agree with your items above. Any other change is likely just fixing a\nbug.\n\n\n','<CAD85om1FBH1B9EeWOwJhTeS+urzn8-pfDAq3GyLtLgAuqouCUg@mail.gmail.com>',NULL),('<1404165040.15218.21.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-30 22:50:40',3600,'2014-06-30 21:50:40',NULL,'[openstack-dev] [OpenStack-Dev] OSLO messaging update and\n icehouse config files','On Mon, 2014-06-30 at 15:35 -0600, John Griffith wrote:\n> \n> \n> \n> \n> On Mon, Jun 30, 2014 at 3:17 PM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Mon, 2014-06-30 at 12:04 -0600, John Griffith wrote:\n>         > Hey Everyone,\n>         >\n>         >\n>         > So I sent a note out yesterday asking about config changes\n>         brought in\n>         > to Icehouse due to the OSLO Messaging update that went out\n>         over the\n>         > week-end here.  My initial email prior to realizing the\n>         update that\n>         > caused the problem was OSLO Messaging update here [1].\n>         \n>         \n>         (Periodic reminder that Oslo is not an acronym)\n>         \n>         > In the meantime I tried updating the cinder.conf sample in\n>         Cinder\'s\n>         > stable Icehouse branch, but noticed that py26 doesn\'t seem\n>         to pick up\n>         > the changes when running the oslo conf generation tools\n>         against\n>         > oslo.messaging.  I haven\'t spent any time digging into this\n>         yet, was\n>         > hoping that perhaps somebody from the OSLO team or somewhere\n>         else\n>         > maybe had some insight as to what\'s going on here.\n>         >\n>         >\n>         > Here\'s the patch I submitted that shows the failure on py26\n>         and\n>         > success on py27 [2].  I\'ll get around to this eventually if\n>         nobody\n>         > else knows anything off the top of their head.\n>         >\n>         >\n>         > Thanks,\n>         > John\n>         >\n>         >\n>         > [1]:\n>         http://lists.openstack.org/pipermail/openstack-dev/2014-June/038926.html\n>         > [2]: https://review.openstack.org/#/c/103426/\n>         \n>         \n>         Ok, that new cinder.conf.sample is showing changes caused by\n>         these\n>         oslo.messaging changes:\n>         \n>           https://review.openstack.org/101583\n>           https://review.openstack.org/99291\n>         \n>         Both of those changes were first released in 1.4.0.0a1 which\n>         is an alpha\n>         version targeting Juno and are not available in the 1.3.0\n>         Icehouse\n>         version - i.e. 1.4.0.0a1 should not be used with\n>         stable/icehouse Cinder.\n>         \n>         It seems 1.3.0 *is* being used:\n>         \n>         \n>         http://logs.openstack.org/26/103426/1/check/gate-cinder-python26/5c6c1dd/console.html\n>         \n>             2014-06-29 19:17:50.154 | oslo.messaging==1.3.0\n>         \n>         and the output is just confusing:\n>         \n>           2014-06-29 19:17:49.900 |\n>         --- /tmp/cinder.UtGHjm/cinder.conf.sample   2014-06-29\n>         19:17:50.270071741 +0000\n>           2014-06-29 19:17:49.900 | +++ etc/cinder/cinder.conf.sample\n>         2014-06-29 19:10:48.396072037 +0000\n>         \n>           ...\n>         \n>           2014-06-29 19:17:49.903 | +[matchmaker_redis]\n>           2014-06-29 19:17:49.903 | +\n>         \n>         i.e. it\'s showing that the file you proposed was generated\n>         with\n>         1.4.0.0a1 and the file generated during the test job was\n>         generated with\n>         1.3.0. Which is what I\'d expect - the update you proposed is\n>         not\n>         appropriate for stable/icehouse.\n>         \n>         So why is the py27 job passing?\n>         \n>         \n>         http://logs.openstack.org/26/103426/1/check/gate-cinder-python27/7844c61/console.html\n>         \n>           2014-06-29 19:21:12.875 | oslo.messaging==1.4.0.0a2\n>         \n>         That\'s the problem right there - 1.4.0.0a2 should not be\n>         getting\n>         installed on the stable/icehouse branch. I\'m not sure why it\n>         is. Someone\n>         on #openstack-infra could probably help figure it out.\n>         \n>         Thanks,\n>         Mark.\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> ?Thanks Mark... so the problem is Oslo messaging in requirements is >=\n> in stable/icehouse [1](please note I used Oslo not OSLO).\n> \n> \n> [1]:\n> https://github.com/openstack/requirements/blob/stable/icehouse/global-requirements.txt#L49\n> \n> \n> Thanks for pointing me in the right direction.\n\nAh, yes! This is the problem:\n\n  oslo.messaging>=1.3.0a9\n\nThis essentially allows *any* alpha release of oslo.messaging to be\nused. We should change stable/icehouse to simply be:\n\n  oslo.messaging>=1.3.0\n\nI\'m happy to do that tomorrow, but I suspect you\'ll get there first\n\nThanks,\nMark.\n\n\n\n\n','<CA+qL3LVB6BMyvONh_-bY1o_kLUJ1N_b8EB20VmKZXuK0inuH4g@mail.gmail.com>',NULL),('<1404173686.42923.YahooMailNeo@web125902.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-06-30 17:14:46',-25200,'2014-07-01 00:14:46',NULL,'[Openstack-docs] doc-specs repo?','We created these steps for creating a spec/blueprint\nhttps://wiki.openstack.org/wiki/Training-guides#Create_a_Blueprint\n\nWith the addition of the why to blueprint verse bug above, it still looks good.\n?\n\n\nSean Roberts\nInfrastructure Strategy, Yahoo\nseanrob at yahoo-inc.com\n(925) 980-4729\n\n\nOn Monday, June 30, 2014 4:17 PM, Anne Gentle <anne at openstack.org> wrote:\n \n\n\n\n\n\n\n\nOn Mon, Jun 30, 2014 at 4:53 PM, Andreas Jaeger <aj at suse.com> wrote:\n\nOn 06/30/2014 11:45 PM, Anne Gentle wrote:\n>> Hi again all,\n>>\n>> Thanks to Andreas we have the correct voting access list for the\n>> docs-specs repo: https://review.openstack.org/#/c/103115/\n>>\n>> I wanted to be sure we all understand when you do a spec. This is\n>> especially important for docs-specs where you might be better off\n>> spending time revising an actual patch rather than continuously revising\n>> a spec. A spec can be used for:\n>> - adding a large portion to an existing deliverable to ensure buy-in\n>> from the core doc team\n>> - adding an entirely new deliverable to the docs project\n>> - any work that requires both content and tooling changes, such as the\n>> addition of the API reference site, for sure that work needed a blueprint\n>> - any large reorganization of a deliverable or set of deliverables\n>> - automation work that will need to be designed prior to proposing a patch\n>> - work that should definitely be discussed at a summit\n>>\n>> Use bugs for:\n>> - known content issues, even if you have to do multiple patches in order\n>> to close the bug\n>> - additions of content that is just plain missing\n>> - known errors in the document\n>>\n>> I want to ensure we balance out the need for up-front approval with\n>> \"just write it already\" -- it\'s a balancing act and we all should start\n>> from a point of agreement on these guidelines.\n>>\n>> Feel free to ask for clarity -\n>\n>\n>Are there any special rules for approving a blueprint?\n>\n\nI looked through the other team\'s guidelines, and it\'s the usual two +2 votes from -core. I did see that for Oslo, for example, the PTL sent a note to the mailing list saying \"if you don\'t -1 this spec by this day I\'ll just approve it myself\" so I think that\'s approach is fine for docs-specs.?\n?\n\n>we have a few blueprints already active for Juno. Should those now moved\n>to the new repo (once it life)?\n>\n\nWe\'ll always have blueprints in Launchpad, and if those already have wiki pages and are approved, I don\'t need to see them in the docs-specs repo.?\n\nThese three blueprints I believe still need discussion and specification:\n*?https://blueprints.launchpad.net/openstack-manuals/+spec/python-client-docs-for-app-devs?I requested more discussion on exactly what work should be done.\n\n\n*?https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site?I plan to write a spec this once we get a web design plan laid out in more detail.\n\n\n*?https://blueprints.launchpad.net/openstack-manuals/+spec/heat-templates?We\'ve discussed a lot on the ML but it doesn\'t have a linked wiki page and could use further description and decisions.\n\n\nThe \"improve-ha-guide\" and \"redocument-xen\" blueprints don\'t have clear owners, but would likely need a spec before proceeding.\n\nSean has some training blueprints he wants to propose, and hopefully the guidelines will help.\n\nThat\'s a run-through of the blueprints marked higher than Low. For ones marked low, I\'ll take a closer look tomorrow.\nGood questions -?\nAnne\n?\n\n>Andreas\n>--\n>?Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>? SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>? ?GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>? ? GPG fingerprint = 93A3 365E CE47 B889 DF7F ?FED1 389A 563C C272 A126\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140630/007d52d8/attachment.html>\n\n','<CAD0KtVH9VT8VM4X2ZMT6t0W8F4nRT+ykp_qbB+yGezohLu2CQQ@mail.gmail.com>',NULL),('<1404210014.0.1381471544045.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-11 06:05:43',0,'2013-10-11 06:05:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #27','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 4910 lines...]\n    raise Exception()\nException\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-11T06:05:37.884576\', resource_metadata={}) from 0 transformer\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-11 06:05:37    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-11T06:05:37.888103\', resource_metadata={}) from 0 transformer\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-11 06:05:37    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-11T06:05:37.893798\', resource_metadata={}) from 0 transformer\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-11 06:05:37    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-11T06:05:37.899745\', resource_metadata={}) from 0 transformer\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-10-11 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-11 06:05:37    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-11T06:05:37.907040\', resource_metadata={}) from 0 transformer\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-11 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 41, in test_keystone_middleware_conf\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nceilometer.storage: DEBUG: looking for \'mongodb\' driver in \'ceilometer.storage\'\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'sqlite = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'postgresql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'log = ceilometer.storage.impl_log:LogStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mongodb = ceilometer.storage.impl_mongodb:MongoDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mysql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'test = ceilometer.storage.impl_test:TestDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'hbase = ceilometer.storage.impl_hbase:HBaseStorage\')\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.JEqKY5QvfV/keystone-signing-sF_qPV as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 51, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 42, in test_keystone_middleware_conf\n    self.assertEqual(api_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.JEqKY5QvfV/keystone-signing-lqnUfa as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 52, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\n2013-10-11 06:05:22     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-11 06:05:22     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-11 06:05:22  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-11 06:05:22  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-11 06:05:22     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.JEqKY5QvfV/keystone-signing-gwcHDR as cache directory for signing certificate\n2013-10-11 06:05:22     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.JEqKY5QvfV/keystone-signing-gwcHDR as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 22.134s\n\nFAILED (SKIP=290, errors=4)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/bin/nosetests> --no-path-adjustment\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.7.1\nMako==0.9.0\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b5\nWebOb==1.2.3\nWebTest==2.0.9\nWerkzeug==0.9.4\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\nboto==2.14.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.27\ncffi==0.7.2\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.7\ndecorator==3.4.0\ndnspython==1.11.1\ndocutils==0.9.1\necdsa==0.9\neventlet==0.14.0\nextras==0.0.3\nglance==2013.1\ngreenlet==0.4.1\nhappybase==0.6\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlogutils==0.3.3\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.1\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.2.1\nparamiko==1.12.0\npasslib==1.6.1\npbr==0.5.21\npecan==0.4.2\nprettytable==0.7.2\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycparser==2.10\npycrypto==2.6\npymongo==2.6.2\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-spidermonkey==0.0.10\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplegeneric==0.8.1\nsimplejson==3.3.1\nsingledispatch==3.4.0.2\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\nswift==1.9.1\nthrift==0.9.1\nunittest2==0.5.1\nwaitress==0.8.7\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.JEqKY5QvfV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/centos6-8/27\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1404292987.4340.7.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-07-02 10:23:07',3600,'2014-07-02 09:23:07',NULL,'[OpenStack Foundation] [OpenStack-DefCore] Understanding DefCore','On Tue, 2014-07-01 at 11:30 -0500, Mark Collier wrote:\n> > On Jun 29, 2014, at 8:34 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> > \n> > On Wed, 2014-06-25 at 13:57 -0500, Mark Collier wrote:\n> >> Great summary Jonathan.  \n> >> \n> >> TL;DR if you read to the end I mention Ceph!\n> >> \n> >> Here are the key points which relate to the debate at hand.  \n> >> \n> >> 1)  The TM policy itself simply requires companies to get a license\n> >> for commercial use, but does not dictate what the contents of those\n> >> licenses should be. The requirements inside of those license\n> >> agreements can be updated as needed by the Foundation.  \n> >> \n> >> 2)  The current product requirements in those agreements are\n> >> essentially ?include entirety of Nova & Swift from a recent release\n> >> and pass some FITs tests approved by the TC when available.\"  This is\n> >> outdated and insufficient given how fast the project has expanded, but\n> >> it is the status quo. Any improvement on this status quo is progress\n> >> in my book, fwiw.\n> > \n> > Yep, agree.\n> > \n> >> 3)  The real question is:  what should those technical requirements be\n> >> to call your product ?OpenStack? (i.e. to get a license)?\n> > \n> > We should be careful of our language around this - nobody gets to call\n> > their product \"OpenStack\". This is about the technical requirements for\n> > products to use the \"OpenStack Powered\" logo, call their product \"Acme\n> > Cloud Software Powered by OpenStack\" or similar, or (I assume this bit -\n> > see my question to Jonathan) call their product \"Acme OpenStack?.\n> \n> \n> Great point, no product can be called simply ?OpenStack?.  OpenStack\n> (that which we produce every 6 months as a community) is, in fact,\n> ?OpenStack?. :)  What is possible, with a signed license, is to use\n> the word ?OpenStack? as _part of_ your product name, when meeting all\n> of the requirements, in a particular manner.\n> \n> To directly address the word mark usage examples in product names,\n> Jonathan did give one example (ACME Cloud Powered by OpenStack).\n> However, in the case of Distributions, we have been granting the right\n> to use it in combination with the company?s brand such as ?Piston\n> OpenStack? or ?Red Hat OpenStack? or ?Mirantis OpenStack?.  Each of\n> those examples are of products from companies who?ve signed a TM\n> license with the foundation.  \n\nI liked Jonathan\'s further clarifications at yesterday\'s TC meetings:\n\n  http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-07-01-20.02.log.html#l-193\n\n  20:25:56 <jbryce> the license agreement in question is called\n    OpenStack Powered and is intended for use with products and services\n    that are built using OpenStack software. for instance a public cloud\n    ?FooTron Compute Powered By OpenStack?, an appliance ?FooTron\n    Appliance Powered by OpenStack, a distribution ?FooTron OpenStack?\n  20:26:38 <jbryce> all of those difference products would be held to\n    the same standard. in other words, they would all be required to\n    expose the same capabilities (testable over the APIs) and include\n    the same actual community-developed software bits (designated\n    sections)\n\nThat\'s super clear. Currently, both the use of \"FooTron Cloud Powered by\nOpenStack\" and \"FooTron OpenStack\" would have the same technical\nrequirements around API compatibility and community-developed software\nbits.\n\nWhat might be good for the board to consider is having different\nrequirements for these two types of trademark usages.\n\nHow about if the trademark programs were structured like this:\n\n  FooTron OpenStack - passes API tests, includes all code from the \n    integrated release\n\n  FooTron Cloud Powered by OpenStack - passes API tests, includes a \n    subset of the integrated release called \'designated sections\'\n\n  FooTron Cloud, OpenStack API Compatible - passes API tests, may not \n    include any code from the integrated release\n\ni.e. why shouldn\'t we have a trademark program that applies only to\nthose commercial products which includes the entire integrated release?\n\nMark.\n\n\n\n','<45116FF0-932A-4224-BB01-D6044D5B8A21@openstack.org>',NULL),('<1404300670.10233.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 04:31:10',-25200,'2014-07-02 11:31:10',NULL,'[openstack-dev] CI setup related request (devstack-gate)','all,\ni need to make some changes in my 3rd party CI system. specifically,?\ni need to override devstack-gate-vm.sh for the mysql path - i can do this by setting SKIP_DEVSTACK_GATE_PROJECT in my examples.yaml file, although this means i will need to manually update the devstack-gate directory\nhowever i also need to do this in the tempest directory.\n(i need to overwrite the python-subunit and testtools versions in requirements.txt and test-requirments.txt files)\n\n\nthe problem is the scripts are set up to do a clean install for every run.?\ngit does a hard reset, checkout and clean (functions.sh)\n\nam working on writing my own version of setup_project for some specific projects.\n\ncan this be better handled by allowing for specific projects to be merged instead of overwritten while setting up the workspace?\n\nthanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/04dc91c0/attachment.html>\n\n',NULL,NULL),('<1404317510.3511.18.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 16:11:22',0,'2014-07-02 16:11:22',NULL,'[openstack-dev] [Neutron][LBaaS] Analyzing the critical path','Hi Sam,\nI\'ll comment on what I know in-line.\n\nOn Wed, 2014-07-02 at 15:29 +0000, Samuel Bercovici wrote:\n> To reiterate the Juno release plan from:\n> https://wiki.openstack.org/wiki/Juno_Release_Schedule\n> \n> Feature freeze is at: 21st August.\n> \n>  \n> \n> I am listing tasks which we should consider to be done for Juno and\n> who should handle them.\n> \n>  \n> \n> The following might be considered as critical path to get anything for\n> Juno:\n> \n> 1.      LBaaS Plugin, API, DB ? when is a code commit expected?\nThe extension, plugin, and DB code are all implemented for the most\npart.  Right now we are working on the \"db\" unit tests.  The \"plugin\"\ntests have been converted from the old version.  The reason I am using\nquotes is because the old plugin unit tests actually tested the\nextension, and the old db unit tests actually tested the plugin (though\nI can digress into a rant about how its not really unit tests, but I\nwon\'t bog this down).  So I\'m probably jsut going to rename the modules.\n\nAfter that is done I\'ll probably put this up on gerrit as a WIP because\nthere still things left to be included that others are working on such\nas shim layers, agent tree refactor, namespace_driver refactor.\n> \n> 2.      CLI\n\nCraig Tracey has been working on this.  From what I understand he is\nclose to completion.\n\n> \n> 3.      LBaaS Driver Interfaces ? done -\n> https://review.openstack.org/#/c/100690/\n> \n> 4.      Connecting the Plugin calls to the drive ? I have not seen any\n> reference to this. I think we should use the ?provider? capabilities\n> until ?flavor? gets implemented. Is this addressed by item 1 above or\n> does it required an additional task?\n\nYes that is what is being done in #1.\n\n> \n> 5.      HA proxy reference implementation ? when is a code commit\n> expected?\n\nI believe Dustin Lundquist was/is working on this.  I\'ll let him give an\nupdate.\n\n> \n> 6.      Tempest Tests\n\nMiguel Lavalle was working on this.\n\n> \n>  \n> \n> Additional ?Core? features\n> \n> 1.      Horizon UI\n\nThis one should be discussed more.  I think we talked about that this\ncan wait because the v1 API should remain unchanged and so Horizon can\nuse that at first until a change is made.\n\n> \n> 2.      Quota update/fix\n\nIf by this you mean quota for loadbalancers, listeners, pools, members,\nhealth monitors, then this will be done in the refactor.\n\n> \n> 3.      API Compatibility\n\nIf by this you mean the new API and old API requests and responses work\nsimultaneously then that will be done in the refactor.\n\n> \n> a.      Connecting the ?OLD API Plugin calls to ?old/new? drivers. Is\n> this still planned?\n\nThe old API plugin will not be calling the new driver interface.  There\nmay be a shim layer that turns the new object model into the old one and\npasses it to the drivers that do not follow the new driver interface.\n\n> \n> 4.      Driver Compatibility\n\nMentioned this above.\n\n> \n> a.      Connecting the Plugin calls to ?old? drivers. Is this still\n> planned?\n\nTouched on it above, but there may be a shim layer that does this\ntranslation.  I also think if the old API and new API can live side by\nside this shim layer may not be needed.  That needs to be a different\ndiscussion though.\n\n> \n>  \n> \n\nEverything below does indeed depend on the refactor so I haven\'t been as\ninvolved as I should be in those discussions.  I\'ll let those who are\ninvolved give updates.\n\n> In addition/parallel\n> \n> 1.      TLS  ? \n> \n> a.      BP is approved. \n> \n> b.     WIP code was committed and waiting for the code of the basic\n> API/model to be available for start of review. \n> \n> c.      HA Proxy reference implementation\n> \n> d.     CLI\n> \n> e.     Horizon Support\n> \n> f.       Tempest Tests\n> \n> 2.      L7 context switching\n> \n> a.      BP in review\n> \n> b.     WIP code in progress and waiting for the code of the basic\n> API/model to be available for initial commit\n> \n> c.      HA Proxy reference implementation\n> \n> d.     CLI\n> \n> e.     Horizon Support\n> \n> f.       Tempest Tests\n> \n>  \n> \n> Anything else?\n> \n>  \n> \n>  \n> \n> Regards,\n> \n>                 -Sam.\n> \n>  \n> \n> \n\n\n','<F36E8145F2571242A675F56CF60964560F8B5CBB@ILMB1.corp.radware.com>',NULL),('<1404322207-sup-5652@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 10:33:57',-25200,'2014-07-02 17:33:57',NULL,'[openstack-dev] [all][specs] Please stop doing specs for any\n	changes in projects','Excerpts from Dolph Mathews\'s message of 2014-07-01 10:02:13 -0700:\n> The argument has been made in the past that small features will require\n> correspondingly small specs. If there\'s a counter-argument to this example\n> (a \"small\" feature requiring a relatively large amount of spec effort), I\'d\n> love to have links to both the spec and the resulting implementation so we\n> can discuss exactly why the spec was an unnecessary additional effort.\n> \n\nIndeed. The line to be drawn isn\'t around the size, IMO, but around\ncommunication.  Nobody has the bandwidth to watch all of the git\nlogs. Nobody has the bandwidth to poll all of the developers what has\nchanged in the interfaces available. So the line for me is whether or\nnot users and operators will need to know something is under way and\nmay want to comment _before_ a change to an interface is made.\n\n\n','<CAC=h7gVce1+w0fkJHX-QvUFhAvt-_R_GEzoJoZTVBjJmZoQ9=Q@mail.gmail.com>',NULL),('<1404323117-sup-5558@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 10:54:49',-25200,'2014-07-02 17:54:49',NULL,'[openstack-dev] [heat] health maintenance in autoscaling groups','Excerpts from Qiming Teng\'s message of 2014-07-02 00:02:14 -0700:\n> Just some random thoughts below ...\n> \n> On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:\n> > In AWS, an autoscaling group includes health maintenance functionality --- \n> > both an ability to detect basic forms of failures and an ability to react \n> > properly to failures detected by itself or by a load balancer.  What is \n> > the thinking about how to get this functionality in OpenStack?  Since \n> \n> We are prototyping a solution to this problem at IBM Research - China\n> lab.  The idea is to leverage oslo.messaging and ceilometer events for\n> instance (possibly other resource such as port, securitygroup ...)\n> failure detection and handling.\n> \n\nHm.. perhaps you should be contributing some reviews here as you may\nhave some real insight:\n\nhttps://review.openstack.org/#/c/100012/\n\nThis sounds a lot like what we\'re working on for continuous convergence.\n\n> > OpenStack\'s OS::Heat::AutoScalingGroup has a more general member type, \n> > what is the thinking about what failure detection means (and how it would \n> > be accomplished, communicated)?\n> \n> When most OpenStack services are making use of oslo.notify, in theory, a\n> service should be able to send/receive events related to resource\n> status.  In our current prototype, at least host failure (detected in\n> Nova and reported with a patch), VM failure (detected by nova), and some\n> lifecycle events of other resources can be detected and then collected\n> by Ceilometer.  There is certainly a possibility to listen to the\n> message queue directly from Heat, but we only implemented the Ceilometer\n> centric approach.\n> \n> > \n> > I have not found design discussion of this; have I missed something?\n> > \n> > I suppose the natural answer for OpenStack would be centered around \n> > webhooks.  An OpenStack scaling group (OS SG = OS::Heat::AutoScalingGroup \n> > or AWS::AutoScaling::AutoScalingGroup or OS::Heat::ResourceGroup or \n> > OS::Heat::InstanceGroup) could generate a webhook per member, with the \n> > meaning of the webhook being that the member has been detected as dead and \n> > should be deleted and removed from the group --- and a replacement member \n> > created if needed to respect the group\'s minimum size.  \n> \n> Well, I would suggest we generalize this into a event messaging or\n> signaling solution, instead of just \'webhooks\'.  The reason is that\n> webhooks as it is implemented today is not carrying a payload of useful\n> information -- I\'m referring to the alarms in Ceilometer.\n> \n> There are other cases as well.  A member failure could be caused by a \n> temporary communication problem, which means it may show up quickly when\n> a replacement member is already being created.  It may mean that we have\n> to respond to an \'online\' event in addition to an \'offline\' event?\n> \n\nThe ideas behind convergence help a lot here. Skew happens in distributed\nsystems, so we expect it constantly. In the extra-capacity situation\nabove, we would just deal with it by scaling back down. There are also\nsituations where we might accidentally create two physical resources\nbecause we got a 500 from the API but it was after the resource was\nbeing created. This is the same problem, and has the same answer: pick\none and scale down (and if this is a critical server like a database,\nwe\'ll need lifecycle callbacks that will prevent suddenly killing a node\nthat would cost you uptime or recovery time).\n\n> > When the member is \n> > a Compute instance and Ceilometer exists, the OS SG could define a \n> > Ceilometer alarm for each member (by including these alarms in the \n> > template generated for the nested stack that is the SG), programmed to hit \n> > the member\'s deletion webhook when death is detected (I imagine there are \n> > a few ways to write a Ceilometer condition that detects instance death). \n> \n> Yes.  Compute instance failure can be detected with a Ceilometer plugin.\n> In our prototype, we developed a Dispatcher plugin that can handle\n> events like \'compute.instance.delete.end\', \'compute.instance.create.end\'\n> after they have been processed based on a event_definitions.yaml file.\n> There could be other ways, I think.\n> \n> The problem here today is about the recovery of SG member.  If it is a\n> compute instance, we can \'reboot\', \'rebuild\', \'evacuate\', \'migrate\' it,\n> just to name a few options.  The most brutal way to do this is like what\n> HARestarter is doing today -- delete followed by a create.\n> \n\nRight, so lifecycle callbacks are useful here, as we can expose an\ninterface for delaying and even cancelling a lifecycle event.\n\n\n','<20140702070213.GB13806@localhost>',NULL),('<1404335313.3402.20.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 21:08:35',0,'2014-07-02 21:08:35',NULL,'[openstack-dev]  [blazar] py26 and py27 jobs failing','Blazar cores,\n	Please review https://review.openstack.org/99389. We need this merged\nASAP in order to get a +1 from Jenkins in our py26 and py27 jobs. Pecan\nnew version returns a 204 instead 200 in one case (when the API returns\nand empty dictionary) and one test case is failing for this reason. This\npatch solve the bug as a side effect, because it returns the versions\ninstead of an empty dictionary.\n\nPablo.\n\n',NULL,NULL),('<1404342019.14784.11.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-02 22:59:50',0,'2014-07-02 22:59:50',NULL,'[openstack-dev] [Neutron][LBaaS] Agenda for weekly IRC meeting','Some things I can think of for the agenda:\n\nNew API\n- Are shim layers really needed for Juno?\n  - If the old API and new API will coexist independently, why is a\n    shim layer needed?\n	- Has the caveat that the pools resource can exist\n	  independently in both APIs.  This can be accomplished by\n	  renaming new API pools to something different or by doing a\n          shim for the pool resource.\n- Should the agent refactoring be included in the main object\n  object model refactor?  The plugin might be able to just call the\n  namespace driver directly, with some modification.\n- Status of entities that only exist in the database and not in\n  a backend (i.e. they are not linked to an existing load balancer)\n\nOn Wed, 2014-07-02 at 20:19 +0000, Jorge Miramontes wrote:\n> Hey LBaaS folks!\n> \n> \n> Please send me any agenda items you would like discussed tomorrow so I\n> can organize the meeting. And as usual, please update the weekly\n> standup etherpad. Everything should be organized on the main wiki page\n> now ==> https://wiki.openstack.org/wiki/Neutron/LBaaS :)\n> \n> \n> Cheers,\n> --Jorge\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFD9D2D9.138DE%jorge.miramontes@rackspace.com>',NULL),('<1404401278.2723.59.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-03 16:27:58',3600,'2014-07-03 15:27:58',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Hey\n\nThis is an attempt to summarize a really useful discussion that Victor,\nFlavio and I have been having today. At the bottom are some background\nlinks - basically what I have open in my browser right now thinking\nthrough all of this.\n\nWe\'re attempting to take baby-steps towards moving completely from\neventlet to asyncio/trollius. The thinking is for Ceilometer to be the\nfirst victim.\n\nCeilometer\'s code is run in response to various I/O events like REST API\nrequests, RPC calls, notifications received, etc. We eventually want the\nasyncio event loop to be what schedules Ceilometer\'s code in response to\nthese events. Right now, it is eventlet doing that.\n\nNow, because we\'re using eventlet, the code that is run in response to\nthese events looks like synchronous code that makes a bunch of\nsynchronous calls. For example, the code might do some_sync_op() and\nthat will cause a context switch to a different greenthread (within the\nsame native thread) where we might handle another I/O event (like a REST\nAPI request) while we\'re waiting for some_sync_op() to return:\n\n  def foo(self):\n      result = some_sync_op()  # this may yield to another greenlet\n      return do_stuff(result)\n\nEventlet\'s infamous monkey patching is what make this magic happen.\n\nWhen we switch to asyncio\'s event loop, all of this code needs to be\nported to asyncio\'s explicitly asynchronous approach. We might do:\n\n  @asyncio.coroutine\n  def foo(self):\n      result = yield from some_async_op(...)\n      return do_stuff(result)\n\nor:\n\n  @asyncio.coroutine\n  def foo(self):\n      fut = Future()\n      some_async_op(callback=fut.set_result)\n      ...\n      result = yield from fut\n      return do_stuff(result)\n\nPorting from eventlet\'s implicit async approach to asyncio\'s explicit\nasync API will be seriously time consuming and we need to be able to do\nit piece-by-piece.\n\nThe question then becomes what do we need to do in order to port a\nsingle oslo.messaging RPC endpoint method in Ceilometer to asyncio\'s\nexplicit async approach?\n\nThe plan is:\n\n  - we stick with eventlet; everything gets monkey patched as normal\n\n  - we register the greenio event loop with asyncio - this means that \n    e.g. when you schedule an asyncio coroutine, greenio runs it in a \n    greenlet using eventlet\'s event loop\n\n  - oslo.messaging will need a new variant of eventlet executor which \n    knows how to dispatch an asyncio coroutine. For example:\n\n        while True:\n            incoming = self.listener.poll()\n            method = dispatcher.get_endpoint_method(incoming)\n            if asyncio.iscoroutinefunc(method):\n                result = method()\n                self._greenpool.spawn_n(incoming.reply, result)\n            else:\n                self._greenpool.spawn_n(method)\n\n    it\'s important that even with a coroutine endpoint method, we send \n    the reply in a greenthread so that the dispatch greenthread doesn\'t\n    get blocked if the incoming.reply() call causes a greenlet context\n    switch\n\n  - when all of ceilometer has been ported over to asyncio coroutines, \n    we can stop monkey patching, stop using greenio and switch to the \n    asyncio event loop\n\n  - when we make this change, we\'ll want a completely native asyncio \n    oslo.messaging executor. Unless the oslo.messaging drivers support \n    asyncio themselves, that executor will probably need a separate\n    native thread to poll for messages and send replies.\n\nIf you\'re confused, that\'s normal. We had to take several breaks to get\neven this far because our brains kept getting fried.\n\nHTH,\nMark.\n\nVictor\'s excellent docs on asyncio and trollius:\n\n  https://docs.python.org/3/library/asyncio.html\n  http://trollius.readthedocs.org/\n\nVictor\'s proposed asyncio executor:\n\n  https://review.openstack.org/70948\n\nThe case for adopting asyncio in OpenStack:\n\n  https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio\n\nA previous email I wrote about an asyncio executor:\n\n http://lists.openstack.org/pipermail/openstack-dev/2013-June/009934.html\n\nThe mock-up of an asyncio executor I wrote:\n\n  https://github.com/markmc/oslo-incubator/blob/8509b8b/openstack/common/messaging/_executors/impl_tulip.py\n\nMy blog post on async I/O and Python:\n\n  http://blogs.gnome.org/markmc/2013/06/04/async-io-and-python/\n\ngreenio - greelets support for asyncio:\n\n  https://github.com/1st1/greenio/\n\n\n\n',NULL,NULL),('<1404401353.3372.6.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-03 15:28:42',0,'2014-07-03 15:28:42',NULL,'[openstack-dev] [Neutron][LBaaS] Status of entities that do not\n exist in a driver backend','With the new API and object model refactor there have been some issues\narising dealing with the status of entities.  The main issue is that\nListener, Pool, Member, and Health Monitor can exist independent of a\nLoad Balancer.  The Load Balancer is the entity that will contain the\ninformation about which driver to use (through provider or flavor).  If\na Listener, Pool, Member, or Health Monitor is created without a link to\na Load Balancer, then what status does it have?  At this point it only\nexists in the database and is really just waiting to be provisioned by a\ndriver/backend.\n\nSome possibilities discussed:\nA new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name\nEntities just remain in PENDING_CREATE until provisioned by a driver\nEntities just remain in ACTIVE until provisioned by a driver\n\nOpinions and suggestions?\n\n','<1404342019.14784.11.camel@localhost>',NULL),('<1404403062.2723.64.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-03 16:57:42',3600,'2014-07-03 15:57:42',NULL,'[OpenStack-Infra] Current options for getting Zanata going','On Wed, 2014-07-02 at 19:15 -0700, Monty Taylor wrote:\n> On 07/02/2014 07:07 PM, Ying Chun Guo wrote:\n> > Hello, Elizabeth\n> > \n> > I could try to be infrastructure meeting.\n> > When is the next infrastructure meeting?\n> > \n> > Now we cannot create new projects in Transifex.\n> > See: https://bugs.launchpad.net/openstack-i18n/+bug/608725/comments/6\n> \n> O noes!\n> \n> > It\'s a big issue for us.\n> > Transifex supporting team is helping, but the response time is not that\n> > quick.\n> > \n> > We do need to have another candidate to take place Transifex.\n> > \n> > I notice the key issue with Zanata is the JBoss version and license.\n> > How about we use a Redhat donated enterprise version ?\n> \n> Ok. So - we don\'t want enterprise licenses for infra things.\n> \n> HOWEVER\n> \n> If it\'s a temporary thing, and I mean one with a commitment, like a real\n> commitment (I might want Brian Stevens to chime in) to get the\n> non-enterprise stuff working sensibly - then I could be convinced.\n> \n> I\'ve included Mark McLoughlin here, because he knows everything ... Mark?\n\nYu Shao is Director of the Red Hat engineering group responsible for\nZanata and he can give his take on the future of Zanata on Wilfly.\n\nI guess it\'s a question of how long getting it to run on Wildfly is\nlikely to take - if it\'s likely to be done in a couple of weeks, it\'s\nprobably not worth the transitional step of running it on EAP with a Red\nHat provided EAP license.\n\nMark.\n\n\n\n','<53B4BCA8.8030608@inaugust.com>',NULL),('<1404409392-sup-5487@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-03 10:45:45',-25200,'2014-07-03 17:45:45',NULL,'[Openstack] Nova test case failures','Excerpts from Green, Paul\'s message of 2014-07-03 09:51:52 -0700:\n> I just ran the Icehouse Nova self-tests under Devstack under VirtualBox, and found that 75 of them failed. Is there a list anywhere of the known failing tests, or should all of them have passed? Or am I doing something dumb?\n> \n> I\'m using Ubuntu Trusty (14.04) and the current copy of devstack.\n> \n> I started the tests as follows:\n>                 cd devstack\n>      ./stack.sh\n>      cd /opt/stack/nova\n>      ./run_tests.sh -V\n\nNote that \'tox\' is the way the gate runs tests, so you might try that.\nBut I\'m not a nova person, so maybe run_tests.sh still has magic for\ndevelopers.\n\nAFAIK, these are the unit tests, so you don\'t need to \'./stack.sh\' to\nget those to pass.. you just need to git clone nova, pip install tox,\nand run \'tox\' in the root of the git tree. That should produce working\nnova unit tests.\n\nAlso, if you\'re going to be doing development (which is what those\nparticular tests are usually used for) you may want to post to\nopenstack-dev. If you want functional/integration tests, you probably\nwant to run the tempest tests (/opt/stack/tempest) and not the nova\ntests.\n\n\n','<08B00C0F32FC924592309F565EAF5FAA934280F0@EXHQ1.corp.stratus.com>',NULL),('<1404417312.4834.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-03 19:55:14',0,'2014-07-03 19:55:14',NULL,'[openstack-dev] [blazar] py26 and py27 jobs failing','Yes I know that, but we need the big patch in order to get our V2 REST\nAPI working, so I asked to review this patch instead of submitting a new\none.\n\nOn Wed, 2014-07-02 at 17:24 -0400, Ryan Petrello wrote:\n> That\'s a pretty notable review to accommodate the pecan change.  In the\n> meantime, wouldn\'t something like this would get the py26 and py27 tests\n> passing?\n> \n> index 9aced3f..4051fad 100644\n> --- a/climate/tests/api/test_root.py\n> +++ b/climate/tests/api/test_root.py\n> @@ -22,8 +22,7 @@ class TestRoot(api.APITest):\n>          response = self.get_json(\'/\',\n>                                   expect_errors=True,\n>                                   path_prefix=\'\')\n> -        self.assertEqual(response.status_int, 200)\n> -        self.assertEqual(response.content_type, \"text/html\")\n> +        self.assertEqual(response.status_int, 204)\n>          self.assertEqual(response.body, \'\')\n> \n> On 07/02/14 09:08:35 PM, Fuente, Pablo A wrote:\n> > Blazar cores,\n> > 	Please review https://review.openstack.org/99389. We need this merged\n> > ASAP in order to get a +1 from Jenkins in our py26 and py27 jobs. Pecan\n> > new version returns a 204 instead 200 in one case (when the API returns\n> > and empty dictionary) and one test case is failing for this reason. This\n> > patch solve the bug as a side effect, because it returns the versions\n> > instead of an empty dictionary.\n> > \n> > Pablo.\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20140702212455.GB519@ryans-mbp>',NULL),('<1404485651.2880.40.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-04 15:54:11',3600,'2014-07-04 14:54:11',NULL,'[openstack-dev] [oslo][all] autosync incubator to projects','On Fri, 2014-07-04 at 15:31 +0200, Ihar Hrachyshka wrote:\n> Hi all,\n> at the moment we have several bot jobs that sync contents to affected\n> projects:\n> \n> - translations are copied from transifex;\n> - requirements are copied from global requirements repo.\n> \n> We have another source of common code - oslo-incubator, though we\n> still rely on people manually copying the new code from there to\n> affected projects. This results in old, buggy, and sometimes\n> completely different versions of the same code in all projects.\n> \n> I wonder why don\'t we set another bot to sync code from incubator? In\n> that way, we would:\n> - reduce work to do for developers [I hope everyone knows how boring\n> it is to fill in commit message with all commits synchronized and\n> create sync requests for > 10 projects at once];\n> - make sure all projects use (almost) the same code;\n> - ensure projects are notified in advance in case API changed in one\n> of the modules that resulted in failures in gate;\n> - our LOC statistics will be a bit more fair ;) (currently, the one\n> who syncs a large piece of code from incubator to a project, gets all\n> the LOC credit at e.g. stackalytics.com).\n> \n> The changes will still be gated, so any failures and incompatibilities\n> will be caught. I even don\'t expect most of sync requests to fail at\n> all, meaning it will be just a matter of two +2\'s from cores.\n> \n> I know that Oslo team works hard to graduate lots of modules from\n> incubator to separate libraries with stable API. Still, I guess we\'ll\n> live with incubator at least another cycle or two.\n> \n> What are your thoughts on that?\n\nJust repeating what I said on IRC ...\n\nThe point of oslo-incubator is that it\'s a place where APIs can be\ncleaned up so that they are ready for graduation. Code living in\noslo-incubator for a long time with unchanging APIs is not the idea. An\nautomated sync job would IMHO discourage API cleanup work. I\'d expect\npeople would start adding lots of ugly backwards API compat hacks with\ntheir API cleanups just to stop people complaining about failing\nauto-syncs. That would be the opposite of what we\'re trying to achieve.\n\nMark.\n\n\n\n','<53B6AC9D.6010107@redhat.com>',NULL),('<1404509268.5284.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-04 21:27:22',0,'2014-07-04 21:27:22',NULL,'[openstack-dev] [Neutron][LBaaS] Status of entities that do not\n exist in a driver backend','Hi German,\n\nThat actually brings up another thing that needs to be done.  There is\nno DELETED state.  When an entity is deleted, it is deleted from the\ndatabase.  I\'d prefer a DELETED state so that should be another feature\nwe implement afterwards.\n\nThanks,\nBrandon\n\nOn Thu, 2014-07-03 at 23:02 +0000, Eichberger, German wrote:\n> Hi Jorge,\n> \n> +1 for QUEUED and DETACHED\n> \n> I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes...\n> \n> German\n> \n> -----Original Message-----\n> From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM] \n> Sent: Thursday, July 03, 2014 11:59 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend\n> \n> +1 to QUEUED status.\n> \n> For entities that have the concept of being attached/detached why not have a \'DETACHED\' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to \'ACTIVE\' or any of the other provisioning statuses such as \'ERROR\', \'PENDING_UPDATE\', etc. Lastly, it wouldn\'t make much sense to have a \'DELETED\' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404\'s for the resource.\n> \n> Cheers,\n> --Jorge\n> \n> \n> \n> \n> On 7/3/14 10:39 AM, \"Phillip Toohill\" <phillip.toohill at RACKSPACE.COM>\n> wrote:\n> \n> >If the objects remain in \'PENDING_CREATE\' until provisioned it would \n> >seem that the process got stuck in that status and may be in a bad \n> >state from user perspective. I like the idea of QUEUED or similar to \n> >reference that the object has been accepted but not provisioned.\n> >\n> >Phil\n> >\n> >On 7/3/14 10:28 AM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM> wrote:\n> >\n> >>With the new API and object model refactor there have been some issues \n> >>arising dealing with the status of entities.  The main issue is that \n> >>Listener, Pool, Member, and Health Monitor can exist independent of a \n> >>Load Balancer.  The Load Balancer is the entity that will contain the \n> >>information about which driver to use (through provider or flavor).  \n> >>If a Listener, Pool, Member, or Health Monitor is created without a \n> >>link to a Load Balancer, then what status does it have?  At this point \n> >>it only exists in the database and is really just waiting to be \n> >>provisioned by a driver/backend.\n> >>\n> >>Some possibilities discussed:\n> >>A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name \n> >>Entities just remain in PENDING_CREATE until provisioned by a driver \n> >>Entities just remain in ACTIVE until provisioned by a driver\n> >>\n> >>Opinions and suggestions?\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C38A5B7@G2W2441.americas.hpqcorp.net>',NULL),('<1404531979.1813.3.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-05 11:46:19',28800,'2014-07-05 03:46:19',NULL,'[Openstack] Can\'t boot from reattached rbd volume','> > ? 2014?7?3??4:52?Daniel Snider <Daniel.Snider at hypert.com> ???\n> > \n> > Hi,\n> > \n> > I detached my root volume from my instance (which is in an rbd store)\n> > so I could extend it with cinder, then I reattached it. When I go to\n> > start the instance it\'s like nova has forgotten or doesn\'t know the\n> > volume is in an rbd store and NOT at\n> > \"/var/lib/nova/instances/d1338984-4402-4af4-819e-64f312c5149b/disk\".\n> > I\'d really like to boot this instance rather than creating a new one.\n> > Can I make nova use the rbd volume correctly?\n\nHi,\n\nNova in Icehouse (and in Havana) doesn\'t have the\nfeature. If you use the Ubuntu packages, it wont\nwork. However, I have added the 5 needed patches in\nthe Debian packages. You may try them. Note that I\nalso maintain some (non-official) Ubuntu packages.\n\nCheers,\n\nThomas\n\n\n\n','<A947F709-518C-4D7B-8520-10380ED3D526@gmail.com>',NULL),('<1404545896.27590208.1407595789274.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 10:49:49',-14400,'2014-08-09 14:49:49',NULL,'[openstack-dev] [qa][ceilometer] swapping the roles of mongodb\n and sqlalchemy for ceilometer in Tempest','\n\n> +2 from me,\n> \n> More mongodb adoption (as stated) when it\'s questionable legally doesn\'t seem\n> like a good long term strategy (I know it will/does impact yahoo adopting or\n> using ceilometer...). Is this another one of those tactical changes that we\n> keep on making that ends up being yet another piece of technical debt that\n> someone will have to cleanup :-/\n> \n> If we thought a little more about this strategically maybe we would end up in\n> a better place short term *and* long term??\n\nHi Joshua,\n\nSince we currently do support mongodb as an *optional* storage driver,\nand some distros do recommend its usage, then surely we should test this\ndriver fully in the upstream gate to support those users who take that\noption?\n\n(i.e. those users who accept MongoDB Inc\'s assurances[1] in regard to\nlicensing of the client-side driver)\n\nCheers,\nEohgan\n\n[1] http://www.mongodb.org/about/licensing/\n\n\n','<4913F378-0CAE-4E25-A63C-75064044F87C@yahoo-inc.com>',NULL),('<1404656398.10857998.1349878289081.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-10 10:11:29',-14400,'2012-10-10 14:11:29',NULL,'[openstack-dev] [keystone] on-behalf-of proxy identities for\n applications running in-instance','\n\n> On 10/10/2012 06:26 AM, Eoghan Glynn wrote:\n> > Folks,\n> >\n> > One to think about in advance of any keystone roadmap discussions\n> > at the summit ...\n> >\n> > As we build out the infrastructure, it\'s likely there will be more\n> > and more cases where applications running on instances will need\n> > to access openstack services securely (for example to use a\n> > notification, or queueing, or metrics service).\n> \n> So this was along the lines of what I discussed with the Heat team.\n> When\n> heat runs, it is going to run as a specific user, and, more\n> importantly, in a constrained project (tenant).\n> I could see using the project as the analogue for the end-point, and\n> then the \"constrained user\" is a user with a constrained role within\n> a\n> project.\n> \n> I could see a setup where, for High Availability (HA),  there is a\n> project for the set of resources assigned to the HA grouping.  Then,\n> a worker user account has limited abilities within that project:\n> migrate VM from one machine to another.  In addition, that same worker user\n> account is granted some minimal role inside the project that owns the\n> virtual machine.  Lets call that user account WORKER and the real\n> person originator REAL.    REAL then would create a pre-auth  for WORKER.\n> If some action needs to be done by WORKER as REAL,  WORKER makes a call\n> to Keystone to get a token associated with the pre-auth.\n\nThanks for the response Adam,\n\nSo the piece I\'m missing is how the capabilities of WORKER can be\nconstrained to be a small subset of REAL\'s capabilities, without\nlots of admin intervention.\n\nIn the example above, if we want WORKER to be allowed to do live\nmigration, but not any other admin actions, then we\'d need to\nextend nova\'s policy.json file changing:\n\n  \"compute_extension:admin_actions:migrateLive\": [[\"rule:admin_api\"]]\n\nto something like:\n\n  \"compute_extension:admin_actions:migrateLive\": [[\"rule:admin_api\"],\n                                                  [\"role:WORKER_ROLE\"]],\n\n(excuse the possibly wrong syntax there) and then role that change out\nacross the fleet of nova-api hosts. Unless we pre-annotate the policy.json\nwith lots of fine-grained roles, one per action or small group of related\nactions.\n\nAlso I\'m not sure how we could recover the original identity (REAL) from\nthe on-behalf-of proxy (WORKER).\n\nCheers,\nEoghan\n\n> >\n> > It would be great if keystone provided support for provisioning\n> > some form of proxy identity to instances that would allow the apps\n> > running in-instance to make API calls on behalf of the instance\n> > owner, within some constraints (on the services that may be invoked\n> > on).\n> >\n> > Similar, basically, to the flexibility that AWS IAM roles provide\n> > currently.\n> >\n> > I don\'t know if this is even feasible within the current set of\n> > keystone capabilities and the fairly static policy.json setup.\n> > However, if it is do-able, it might be a good feature to discuss\n> > for future roadmap consideration.\n> >\n> > Cheers,\n> > Eoghan\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<50756C18.2060209@redhat.com>',NULL),('<1404693687-sup-1000@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-06 17:43:51',-25200,'2014-07-07 00:43:51',NULL,'[Openstack] Horizon and radosgw with nginx','Excerpts from Sergey Motovilovets\'s message of 2014-07-06 09:29:11 -0700:\n> Hello everyone.\n> \n> I\'m running Horizon with nginx and radosgw with tengine (nginx fork with an\n> option to disable fastcgi request buffering).\n> The thing is that when I upload files using swift console client directly\n> to a node hosting radosgw, everything works like a charm, but Horizon\n> doesn\'t let me upload files with a size more 64K, and it\'s not\n> about client_max_body_size in nginx. Horizon gets first 64K of the file,\n> then freezes until \"Connection reset by peer\" happens (inactivity timeout\n> on radosgw node I suppose).\n\nThis is just a guess, but does tengine support 100 Continue? A fairly\nrecent forum post suggests that nginx doesn\'t:\n\nhttp://forum.nginx.org/read.php?2,241130,241139\n\nMy understanding was that radosgw uses 100 Continue for large uploads.\n\nSo you may need to ensure that you have a proxy that can handle such\nthings.\n\n\n','<CAMgiA5kwA57bF5U1+Zyt6qrDL8N+Vb-NSVKH-A_nohZd-GsxMg@mail.gmail.com>',NULL),('<140470407.27321382.1384143618911.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-10 20:20:18',-28800,'2013-11-11 04:20:18',NULL,'[Openstack] Memory utilization meter from ceilometer for libvert','Hey all, \n\nIn an archived conversation (http://www.mail-archive.com/openstack at lists.launchpad.net/msg24776.html), I see that memory utilization meter for libvert was not available in ceilometer and plans were to support it after a fix is available in a new release of libvert. Does anyone know if this fix is already available in libvert and whether ceilometer now supports memory utilization meter? I didn\'t see any bug for the same as well.\n\nThanks,\nPiyush\n\n\n','<2044319233.27266069.1384142788826.JavaMail.root@vmware.com>',NULL),('<1404742936.902315631@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-07-07 09:22:16',-18000,'2014-07-07 14:22:16',NULL,'[openstack-community] 50% discount on passes to Cloud Connect China\n	in Shanghai, September 16-18','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140707/eb359b49/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.png\nType: image/png\nSize: 193688 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140707/eb359b49/attachment-0001.png>\n\n',NULL,NULL),('<1404756833.2880.120.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 19:13:53',3600,'2014-07-07 18:13:53',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','On Sun, 2014-07-06 at 09:28 -0400, Eoghan Glynn wrote:\n> \n> > This is an attempt to summarize a really useful discussion that Victor,\n> > Flavio and I have been having today. At the bottom are some background\n> > links - basically what I have open in my browser right now thinking\n> > through all of this.\n> \n> Thanks for the detailed summary, it puts a more flesh on the bones\n> than a brief conversation on the fringes of the Paris mid-cycle.\n> \n> Just a few clarifications and suggestions inline to add into the\n> mix.\n> \n> > We\'re attempting to take baby-steps towards moving completely from\n> > eventlet to asyncio/trollius. The thinking is for Ceilometer to be the\n> > first victim.\n> \n> First beneficiary, I hope :)\n>  \n> > Ceilometer\'s code is run in response to various I/O events like REST API\n> > requests, RPC calls, notifications received, etc. We eventually want the\n> > asyncio event loop to be what schedules Ceilometer\'s code in response to\n> > these events. Right now, it is eventlet doing that.\n> \n> Yes.\n> \n> And there is one other class of stimulus, also related to eventlet,\n> that is very important for triggering the execution of ceilometer\n> logic. That would be the timed tasks that drive polling of:\n> \n>  * REST APIs provided by other openstack services \n>  * the local hypervisor running on each compute node\n>  * the SNMP daemons running at host-level etc.\n> \n> and also trigger periodic alarm evaluation.\n> \n> IIUC these tasks are all mediated via the oslo threadgroup\'s\n> usage of eventlet.greenpool[1]. Would this logic also be replaced\n> as part of this effort?\n\nAs part of the broader \"switch from eventlet to asyncio\" effort, yes\nabsolutely.\n\nAt the core of any event loop is code to do select() (or equivalents)\nwaiting for file descriptors to become readable or writable, or timers\nto expire. We want to switch from the eventlet event loop to the asyncio\nevent loop.\n\nThe ThreadGroup abstraction from oslo-incubator is an interface to the\neventlet event loop. When you do:\n\n  self.tg.add_timer(interval, self._evaluate_assigned_alarms)\n\nYou\'re saying \"run evaluate_assigned_alarms() every $interval seconds,\nusing select() to sleep between executions\".\n\nWhen you do:\n\n  self.tg.add_thread(self.start_udp)\n\nyou\'re saying \"run some code which will either run to completion or set\nwait for fd or timer events using select()\".\n\nThe asyncio versions of those will be:\n\n  event_loop.call_later(delay, callback)\n  event_loop.call_soon(callback)\n\nwhere the supplied callbacks will be asyncio \'coroutines\' which rather\nthan doing:\n\n  def foo(...):\n      buf = read(fd)\n\nand rely on eventlet\'s monkey patch to cause us to enter the event\nloop\'s select() when the read() blocks, we instead do:\n\n  @asyncio.coroutine\n  def foo(...):\n      buf = yield from read(fd)\n\nwhich shows exactly where we might yield to the event loop.\n\nThe challenge is that porting code like the foo() function above is\npretty invasive and we can\'t simply port an entire service at once. So,\nwe need to be able to support a service using both eventlet-reliant code\nand asyncio coroutines.\n\nIn your example of the openstack.common.threadgroup API - we would\ninitially need to add support for scheduling asyncio coroutine callback\narguments as eventlet greenthreads in add_timer() and add_thread(), and\nlater we would port threadgroup itself to rely completely on asyncio.\n\n> > Now, because we\'re using eventlet, the code that is run in response to\n> > these events looks like synchronous code that makes a bunch of\n> > synchronous calls. For example, the code might do some_sync_op() and\n> > that will cause a context switch to a different greenthread (within the\n> > same native thread) where we might handle another I/O event (like a REST\n> > API request)\n> \n> Just to make the point that most of the agents in the ceilometer\n> zoo tend to react to just a single type of stimulus, as opposed\n> to a mix of dispatching from both message bus and the REST API.\n> \n> So to classify, we\'d have:\n> \n>  * compute-agent: timer tasks for polling\n>  * central-agent: timer tasks for polling\n>  * notification-agent: dispatch of \"external\" notifications from\n>    the message bus\n>  * collector: dispatch of \"internal\" metering messages from the\n>    message bus\n>  * api-service: dispatch of REST API calls\n>  * alarm-evaluator: timer tasks for alarm evaluation\n>  * alarm-notifier: dispatch of \"internal\" alarm notifications\n> \n> IIRC, the only case where there\'s a significant mix of trigger\n> styles is the partitioned alarm evaluator, where assignments of\n> alarm subsets for evaluation is driven over RPC, whereas the\n> actual thresholding is triggered by a timer.\n\nCool, that\'s helpful. I think the key thing is deciding which stimulus\n(and hence agent) we should start with.\n\n> > Porting from eventlet\'s implicit async approach to asyncio\'s explicit\n> > async API will be seriously time consuming and we need to be able to do\n> > it piece-by-piece.\n> \n> Yes, I agree, a step-wise approach is the key here.\n> \n> So I\'d love to have some sense of the time horizon for this\n> effort. It clearly feels like a multi-cycle effort, so the main\n> question in my mind right now is whether we should be targeting\n> the first deliverables for juno-3?\n> \n> That would provide a proof-point in advance of the K* summit,\n> where I presume the task would be get wider buy-in for the idea.\n> \n> If it makes sense to go ahead and aim the first baby steps for\n> juno-3, then we\'d need to have a ceilometer-spec detailing these\n> changes. This would need to be proposed by say EoW and then\n> landed before the spec acceptance deadline for juno (~July 21st).\n> \n> We could use this spec proposal to dig into the perceived benefits\n> of this effort:\n> \n>  * the obvious win around getting rid of the eventlet black-magic\n>  * plus possibly other benefits such as code clarity and ease of\n>    maintenance\n> \n> and OTOH get a heads-up on the risks:\n> \n>  * possible immaturity in the new framework?\n>  * overhead involved in contributors getting to grips with the\n>    new coroutine model\n\nMy sense is that until someone does a prototype with a single callback\nfunction (for whichever stimulus), we really don\'t have much of an idea\nwhat\'s involved.\n\n> > The question then becomes what do we need to do in order to port a\n> > single oslo.messaging RPC endpoint method in Ceilometer to asyncio\'s\n> > explicit async approach?\n> \n> One approach would be to select one well-defined area of ceilometer\n> as an initial test-bed for these ideas.\n> \n> And one potential candidate for that would be the partitioned alarm\n> evaluator, which uses:\n> \n>  1. fan-out RPC for the heartbeats underpinning master-slave\n>     coordination\n>  2. RPC calls for alarm allocations and assignments\n> \n> I spoke to Cyril Roelandt at the mid-cycle, who is interested in:\n> \n>  * replacing #1 with the tooz distributed co-ordination library[2]\n>  * and also possibly replacing #2 with taskflow\n> \n> The benefit of using taskflow for \"sticky\" task assignments isn\'t\n> 100% clear, so it may actually make better sense to just use tooz\n> for the leadership election, and the new asyncio model for #2.\n> \n> Starting there would have the advantage of being out on the side\n> of the main ceilometer pipeline.\n> \n> However, if we do decide to go ahead with taskflow, then we could\n> fine another good starting point for asyncio as an alternative.\n\nNo opinion from me on where to start, really. I\'d expect the ability to\nuse the underlying libraries called from the callback in a sane way with\nasyncio would be a significant factor.\n\n> >   - when all of ceilometer has been ported over to asyncio coroutines,\n> >     we can stop monkey patching, stop using greenio and switch to the\n> >     asyncio event loop\n> \n> ... kick back and light a cigar! :)\n\nIndeed :)\n\nThanks,\nMark.\n\n> [1] https://github.com/openstack/oslo-incubator/blob/master/openstack/common/threadgroup.py#L72\n> [2] https://github.com/stackforge/tooz\n> [3] https://wiki.openstack.org/wiki/TaskFlow\n\n\n\n\n','<1486168947.5969307.1404653327264.JavaMail.zimbra@redhat.com>',NULL),('<1404757118.2880.124.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 19:18:38',3600,'2014-07-07 18:18:38',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','On Mon, 2014-07-07 at 15:53 +0100, Gordon Sim wrote:\n> On 07/07/2014 03:12 PM, Victor Stinner wrote:\n> > The first step is to patch endpoints to add @trollius.coroutine to the methods,\n> > and add yield From(...) on asynchronous tasks.\n> \n> What are the \'endpoints\' here? Are these internal to the oslo.messaging \n> library, or external to it?\n\nThe callback functions we dispatch to are called \'endpoint methods\' -\ne.g. they are methods on the \'endpoints\' objects passed to\nget_rpc_server().\n\n> > Later we may modify Oslo Messaging to be able to call an RPC method\n> > asynchronously, a method which would return a Trollius coroutine or task\n> > directly. The problem is that Oslo Messaging currently hides \"implementation\"\n> > details like eventlet.\n> \n> I guess my question is how effectively does it hide it? If the answer to \n> the above is that this change can be contained within the oslo.messaging \n> implementation itself, then that would suggest its hidden reasonably well.\n> \n> If, as I first understood (perhaps wrongly) it required changes to every \n> use of the oslo.messaging API, then it wouldn\'t really be hidden.\n> \n> > Returning a Trollius object means that Oslo Messaging\n> > will use explicitly Trollius. I\'m not sure that OpenStack is ready for that\n> > today.\n> \n> The oslo.messaging API could evolve/expand to include explicitly \n> asynchronous methods that did not directly expose Trollius.\n\nI\'d expect us to add e.g.\n\n  @asyncio.coroutine\n  def call_async(self, ctxt, method, **kwargs):\n      ...\n\nto RPCClient. Perhaps we\'d need to add an AsyncRPCClient in a separate\nmodule and only add the method there - I don\'t have a good sense of it\nyet.\n\nHowever, the key thing is that I don\'t anticipate us needing to change\nthe current API in a backwards incompatible way.\n\nMark.\n\n\n\n','<53BAB461.9080306@redhat.com>',NULL),('<1404757505.2769.26.camel@graham-work-laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 18:25:15',0,'2014-07-07 18:25:15',NULL,'[openstack-dev] [Designate] Mid-cycle meetup July 2014','Hi,\n\nApologies for the short notice on this, but it took us a while to finalise the details!\n\nWe are planing on having our mid-cycle meet for Juno in the HP Seattle office from the 28th to the 29th of July.\n\nDetails for the meet up are here: https://wiki.openstack.org/wiki/Designate/MidCycleJuly2014 and as things change I will be updating that page.\n\nIf you are interested in attending (in person, or remotely) please email  me (graham.hayes at hp.com<mailto:graham.hayes at hp.com>) with subject \"Designate July 2014 Mid Cycle\"\n\nThere is limited spaces, for both in person, and remote attendees, so this may fill up fast!\n\nThanks,\n\nGraham\n\n--\nGraham Hayes\nSoftware Engineer\nDNS as a Service\nHP Helion Cloud - Platform Services\n\nGPG Key: 7D28E972\n\ngraham.hayes at hp.com<mailto:graham.hayes at hp.com>\nM +353 87 377 8315\nP +353 1 524 2175\n\n[HP]<http://www.hp.com/>\n\n\n\n\n',NULL,NULL),('<1404757579.2880.129.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 19:26:19',3600,'2014-07-07 18:26:19',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','On Mon, 2014-07-07 at 18:11 +0000, Angus Salkeld wrote:\n> On 03/07/14 05:30, Mark McLoughlin wrote:\n> > Hey\n> > \n> > This is an attempt to summarize a really useful discussion that Victor,\n> > Flavio and I have been having today. At the bottom are some background\n> > links - basically what I have open in my browser right now thinking\n> > through all of this.\n> > \n> > We\'re attempting to take baby-steps towards moving completely from\n> > eventlet to asyncio/trollius. The thinking is for Ceilometer to be the\n> > first victim.\n> \n> Has this been widely agreed on? It seems to me like we are mixing two\n> issues:\n> 1) we need to move to py3\n> 2) some people want to move from eventlet (I am not convinced that the\n>    volume of code changes warrants the end goal - and review load)\n> \n> To achieve \"1)\" in a lower risk change, shouldn\'t we rather run eventlet\n> on top of asyncio? - i.e. not require widespread code changes.\n> \n> So we can maintain the main loop API but move to py3. I am not sure on\n> the feasibility, but seems to me like a more contained change.\n\nRight - it\'s important that we see these orthogonal questions,\nparticularly now that it appears eventlet is likely to be available for\nPython 3 soon.\n\nFor example, if it was generally agreed that we all want to end up on\nPython 3 with asyncio in the long term, you could imagine deploying\n(picking random examples) Glance with Python 3 and eventlet, but\nCeilometer with Python 2 and asyncio/trollius.\n\nHowever, I don\'t have a good handle on how your suggestion of switching\nto the asyncio event loop without widespread code changes would work?\n\nMark.\n\n\n\n','<B8CF6F6CCA9E6749ACCD473169B95B721ACA912E@ORD1EXD01.RACKSPACE.CORP>',NULL),('<1404758767-sup-9996@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 11:52:56',-25200,'2014-07-07 18:52:56',NULL,'[openstack-dev] [Heat] [Marconi] Heat and concurrent signal\n	processing needs some deep thought','I just noticed this review:\n\nhttps://review.openstack.org/#/c/90325/\n\nAnd gave it some real thought. This will likely break any large scale\nusage of signals, and I think breaks the user expectations. Nobody expects\nto get a failure for a signal. It is one of those things that you fire and\nforget. \"I\'m done, deal with it.\" If we start returning errors, or 409\'s\nor 503\'s, I don\'t think users are writing their in-instance initialization\ntooling to retry. I think we need to accept it and reliably deliver it.\n\nDoes anybody have any good ideas for how to go forward with this? I\'d\nmuch rather borrow a solution from some other project than try to invent\nsomething for Heat.\n\nI\'ve added Marconi as I suspect there has already been some thought put\ninto how a user-facing set of tools would send messages.\n\n\n',NULL,NULL),('<1404767458-sup-2594@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 14:23:34',-25200,'2014-07-07 21:23:34',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Excerpts from Joshua Harlow\'s message of 2014-07-07 10:41:34 -0700:\n> So I\'ve been thinking how to respond to this email, and here goes (shields\n> up!),\n> \n> First things first; thanks mark and victor for the detailed plan and\n> making it visible to all. It\'s very nicely put together and the amount of\n> thought put into it is great to see. I always welcome an effort to move\n> toward a new structured & explicit programming model (which asyncio\n> clearly helps make possible and strongly encourages/requires).\n> \n\nI too appreciate the level of detail in the proposal. I think I\nunderstand where it wants to go.\n\n> So now to some questions that I\'ve been thinking about how to\n> address/raise/ask (if any of these appear as FUD, they were not meant to\n> be):\n> \n> * Why focus on a replacement low level execution model integration instead\n> of higher level workflow library or service (taskflow, mistral... other)\n> integration?\n> \n> Since pretty much all of openstack is focused around workflows that get\n> triggered by some API activated by some user/entity having a new execution\n> model (asyncio) IMHO doesn\'t seem to be shifting the needle in the\n> direction that improves the scalability, robustness and crash-tolerance of\n> those workflows (and the associated projects those workflows are currently\n> defined & reside in). I *mostly* understand why we want to move to asyncio\n> (py3, getting rid of eventlet, better performance? new awesomeness...) but\n> it doesn\'t feel that important to actually accomplish seeing the big holes\n> that openstack has right now with scalability, robustness... Let\'s imagine\n> a different view on this; if all openstack projects declaratively define\n> the workflows there APIs trigger (nova is working on task APIs, cinder is\n> getting there to...), and in the future when the projects are *only*\n> responsible for composing those workflows and handling the API inputs &\n> responses then the need for asyncio or other technology can move out from\n> the individual projects and into something else (possibly something that\n> is being built & used as we speak). With this kind of approach the\n> execution model can be an internal implementation detail of the workflow\n> \'engine/processor\' (it will also be responsible for fault-tolerant, robust\n> and scalable execution). If this seems reasonable, then why not focus on\n> integrating said thing into openstack and move the projects to a model\n> that is independent of eventlet, asyncio (or the next greatest thing)\n> instead? This seems to push the needle in the right direction and IMHO\n> (and hopefully others opinions) has a much bigger potential to improve the\n> various projects than just switching to a new underlying execution model.\n> \n> * Was the heat (asyncio-like) execution model[1] examined and learned from\n> before considering moving to asyncio?\n> \n> I will try not to put words into the heat developers mouths (I can\'t do it\n> justice anyway, hopefully they can chime in here) but I believe that heat\n> has a system that is very similar to asyncio and coroutines right now and\n> they are actively moving to a different model due to problems in part due\n> to using that coroutine model in heat. So if they are moving somewhat away\n> from that model (to a more declaratively workflow model that can be\n> interrupted and converged upon [2]) why would it be beneficial for other\n> projects to move toward the model they are moving away from (instead of\n> repeating the issues the heat team had with coroutines, ex, visibility\n> into stack/coroutine state, scale limitations, interruptibility...)?\n> \n\nI\'d like to hear Zane\'s opinions as he developed the rather light weight\ncode that we use. It has been quite a learning curve for me but I do\nunderstand how to use the task scheduler we have in Heat now.\n\nHeat\'s model is similar to asyncio, but is entirely limited in scope. I\nthink it has stayed relatively manageable because it is really only used\nfor a few explicit tasks where a high degree of concurrency makes a lot\nof sense. We are not using it for I/O concurrency (eventlet still does\nthat) but rather for request concurrency. So we tell nova to boot 100\nservers with 100 coroutines that have 100 other coroutines to block\nfurther execution until those servers are active. We are by no means\nusing it as a general purpose concurrency programming model.\n\nThat said, as somebody working on the specification to move toward a\nmore taskflow-like (perhaps even entirely taskflow-based) model in Heat,\nI think that is the way to go. The fact that we already have an event\nloop that doesn\'t need to be explicit except at the very lowest levels\nmakes me want to keep that model. And we clearly need help with how to\ndefine workflows, which something like taskflow will do nicely.\n\n>   \n>   * A side-question, how do asyncio and/or trollius support debugging, do\n> they support tracing individual co-routines? What about introspecting the\n> state a coroutine has associated with it? Eventlet at least has\n> http://eventlet.net/doc/modules/debug.html (which is better than nothing);\n> does an equivalent exist?\n> \n\nI second that question. My twisted experience has left me very\nsuspicious of coroutines and debugging.\n\n> * What\'s the current thinking on avoiding the chaos (code-change-wise and\n> brain-power-wise) that will come from a change to asyncio?\n> \n> This is the part that I really wonder about. Since asyncio isn\'t just a\n> drop-in replacement for eventlet (which hid the async part under its\n> *black magic*), I very much wonder how the community will respond to this\n> kind of mindset change (along with its new *black magic*). Will the\n> TC/foundation offer training, tutorials... on the change that this brings?\n> Should the community even care? If we say just focus on workflows & let\n> the workflow \'engine/processor\' do the dirty work; then I believe the\n> community really doesn\'t need to care (and rightfully so) about how their\n> workflows get executed (either by taskflow, mistral, pigeons...). I\n> believe this seems like a fair assumption to make; it could even be\n> reinforced (I am not an expert here) with the defcore[4] work that seems\n> to be standardizing the integration tests that verify those workflows (and\n> associated APIs) act as expected in the various commercial implementations.\n> \n\nAngus summed that up nicely in his sub-thread about just sticking with\neventlet. I\'m concerned as well.\n\n> * Is the larger python community ready for this?\n> \n> Seeing other responses for supporting libraries that aren\'t asyncio\n> compatible it doesn\'t inspire confidence that this path is ready to be\n> headed down. Partially this is due to the fact that its a completely new\n> programming model and alot of underlying libraries will be forced to\n> change to accommodate this (sqlalchemy, others listed in [5]...). Do\n> others feel it\'s appropriate to start this at this time, or does it feel\n> premature? Of course we have to start somewhere but I start to wonder if\n> effort is better spent elsewhere (see above). Along a related question,\n> seeing that openstack needs to support py2.x and py3.x will this mean that\n> trollius will be required to be used in 3.x (as it is the least common\n> denominator, not new syntax like \'yield from\' that won\'t exist in 2.x).\n> Does this mean that libraries that will now be required to change will be\n> required to use trollius (the pulsar[6] framework seemed to mesh these two\n> nicely); is this understood by those authors? Is this the direction we\n> want to go down (if we stay focused on ensuring py3.x compatible, then why\n> not just jump to py3.x in the first place)?\n> \n\nI haven\'t seen any language fully embrace coroutine based systems, but\nI\'m not looking very closely at other languages lately.\n\nPython may be a pioneer in this area, I\'m not sure. But what I see is\nthe opposite: light weight coordinated threading systems seem to be\nquite popular, and I think not just a little bit because they are easier\nto debug.\n\n\n','<CFE0292E.66B04%harlowja@yahoo-inc.com>',NULL),('<1404770873-sup-7399@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 15:13:05',-25200,'2014-07-07 22:13:05',NULL,'[openstack-dev] [Heat] Upwards-compatibility for HOT','Excerpts from Zane Bitter\'s message of 2014-07-07 14:25:50 -0700:\n> With the Icehouse release we announced that there would be no further \n> backwards-incompatible changes to HOT without a revision bump. However, \n> I notice that we\'ve already made an upward-incompatible change in Juno:\n> \n> https://review.openstack.org/#/c/102718/\n> \n> So a user will be able to create a valid template for a Juno (or later) \n> version of Heat with the version\n> \n>    heat_template_version: 2013-05-23\n> \n> but the same template may break on an Icehouse installation of Heat with \n> the \"stable\" HOT parser. IMO this is almost equally as bad as breaking \n> backwards compatibility, since a user moving between clouds will \n> generally have no idea whether they are going forward or backward in \n> version terms.\n\nSounds like a bug in Juno that we need to fix. I agree, this is a new\ntemplate version.\n\n> \n> (Note: AWS don\'t use the version field this way, because there is only \n> one AWS and therefore in theory they don\'t have this problem. This \n> implies that we might need a more sophisticated versioning system.)\n> \n\nA good manual with a \"this was introduced in version X\" and \"this was\nchanged in version Y\" would, IMO be enough, to help users not go crazy\nand help us know whether something is a bug or not. We can probably\nachieve this entirely in the in-code template guide.\n\n> I\'d like to propose a policy that we bump the revision of HOT whenever \n> we make a change from the previous stable version, and that we declare \n> the new version stable at the end of each release cycle. Maybe we can \n> post-date it to indicate the policy more clearly. (I\'d also like to \n> propose that the Juno version drops cfn-style function support.)\n\nAgreed. I\'m also curious if we\'re going to reject a template with\nversion 2013-05-23 that includes list_join. If we don\'t reject it, we\nprobably need to look at how to show the user warnings about\nversion/feature skew.\n\n\n','<53BB105E.2070000@redhat.com>',NULL),('<1404808393.7506.12.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 09:33:13',3600,'2014-07-08 08:33:13',NULL,'[openstack-dev] Policy around Requirements Adds (was: New class\n of requirements for Stackforge projects)','On Mon, 2014-07-07 at 16:46 -0400, Sean Dague wrote:\n> This thread was unfortunately hidden under a project specific tag (I\n> have thus stripped all the tags).\n> \n> The crux of the argument here is the following:\n> \n> Is a stackforge project project able to propose additions to\n> global-requirements.txt that aren\'t used by any projects in OpenStack.\n> \n> I believe the answer is firmly *no*.\n> \n> global-requirements.txt provides a way for us to have a single point of\n> vetting for requirements for OpenStack. It lets us assess licensing,\n> maturity, current state of packaging, python3 support, all in one place.\n> And it lets us enforce that integration of OpenStack projects all run\n> under a well understood set of requirements.\n\nAllowing Stackforge projects use this as their base set of dependencies,\nwhile still taking additional dependencies makes sense to me. I don\'t\nreally understand this GTFO stance.\n\nSolum wants to depend on mistralclient - that seems like a perfectly\nreasonable thing to want to do. And they also appear to not want to\nstray any further from the base set of dependencies shared by OpenStack\nprojects - that also seems like a good thing.\n\nNow, perhaps the mechanics are tricky, and perhaps we don\'t want to\nenable Stackforge projects do stuff like pin to a different version of\nSQLalchemy, and perhaps this proposal isn\'t the ideal solution, and\nperhaps infra/others don\'t want to spend a lot of energy on something\nspecifically for Stackforge projects ... but I don\'t see something\nfundamentally wrong with what they want to do.\n\nMark.\n\n\n\n','<53BB0713.60704@dague.net>',NULL),('<1404816843.15592.1.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 11:54:03',3600,'2014-07-08 10:54:03',NULL,'[openstack-dev] Policy around Requirements Adds','On Tue, 2014-07-08 at 06:26 -0400, Sean Dague wrote:\n> On 07/08/2014 04:33 AM, Mark McLoughlin wrote:\n> > On Mon, 2014-07-07 at 16:46 -0400, Sean Dague wrote:\n> >> This thread was unfortunately hidden under a project specific tag (I\n> >> have thus stripped all the tags).\n> >>\n> >> The crux of the argument here is the following:\n> >>\n> >> Is a stackforge project project able to propose additions to\n> >> global-requirements.txt that aren\'t used by any projects in OpenStack.\n> >>\n> >> I believe the answer is firmly *no*.\n> >>\n> >> global-requirements.txt provides a way for us to have a single point of\n> >> vetting for requirements for OpenStack. It lets us assess licensing,\n> >> maturity, current state of packaging, python3 support, all in one place.\n> >> And it lets us enforce that integration of OpenStack projects all run\n> >> under a well understood set of requirements.\n> > \n> > Allowing Stackforge projects use this as their base set of dependencies,\n> > while still taking additional dependencies makes sense to me. I don\'t\n> > really understand this GTFO stance.\n> > \n> > Solum wants to depend on mistralclient - that seems like a perfectly\n> > reasonable thing to want to do. And they also appear to not want to\n> > stray any further from the base set of dependencies shared by OpenStack\n> > projects - that also seems like a good thing.\n> > \n> > Now, perhaps the mechanics are tricky, and perhaps we don\'t want to\n> > enable Stackforge projects do stuff like pin to a different version of\n> > SQLalchemy, and perhaps this proposal isn\'t the ideal solution, and\n> > perhaps infra/others don\'t want to spend a lot of energy on something\n> > specifically for Stackforge projects ... but I don\'t see something\n> > fundamentally wrong with what they want to do.\n> \n> Once it\'s in global requirements, any OpenStack project can include it\n> in their requirements. Modifying that file for only stackforge projects\n> is what I\'m against.\n> \n> If the solum team would like to write up a partial sync mechanism,\n> that\'s fine. It just needs to not be impacting the enforcement mechanism\n> we actually need for OpenStack projects.\n\nTotally agree. Solum taking a dependency on mistralclient shouldn\'t e.g.\nallow glance to take a dependency on mistralclient.\n\nMark.\n\n\n\n','<53BBC76B.5080203@dague.net>',NULL),('<1404839723-sup-3353@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 11:43:01',-25200,'2014-07-08 18:43:01',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Excerpts from Victor Stinner\'s message of 2014-07-08 05:47:36 -0700:\n> Hi Joshua,\n> \n> You asked a lot of questions. I will try to answer.\n> \n> Le lundi 7 juillet 2014, 17:41:34 Joshua Harlow a ?crit :\n> > * Why focus on a replacement low level execution model integration instead\n> > of higher level workflow library or service (taskflow, mistral... other)\n> > integration?\n> \n> I don\'t know tasklow, I cannot answer to this question.\n> \n> How do you write such code using taskflow?\n> \n>   @asyncio.coroutine\n>   def foo(self):\n>       result = yield from some_async_op(...)\n>       return do_stuff(result)\n> \n\nVictor, this is a low level piece of code, which highlights the problem\nthat taskflow\'s higher level structure is meant to address. In writing\nOpenStack, we want to accomplish tasks based on a number of events. Users,\nerrors, etc. We don\'t explicitly want to run coroutines, we want to\nattach volumes, spawn vms, and store files.\n\nSee this:\n\nhttp://docs.openstack.org/developer/taskflow/examples.html\n\nThe result is consumed in the next task in the flow. Meanwhile we get\na clear definition of work-flow and very clear methods for resumption,\nretry, etc. So the expression is not as tightly bound as the code above,\nbut that is the point, because we want to break things up into tasks\nwhich are clearly defined and then be able to resume each one\nindividually.\n\nSo what I think Josh is getting at, is that we could add asyncio support\ninto taskflow as an abstraction for tasks that want to be non-blocking,\nand then we can focus on refactoring the code around high level work-flow\nexpression rather than low level asyncio and coroutines.\n\n> > * Was the heat (asyncio-like) execution model[1] examined and learned from\n> > before considering moving to asyncio?\n> \n> I looked at Heat coroutines, but it has a design very different from asyncio.\n> \n> In short, asyncio uses an event loop running somewhere in the background, \n> whereas Heat explicitly schedules the execution of some tasks (with \n> \"TaskRunner\"), blocks until it gets the result and then stop completly its \n> \"event loop\". It\'s possible to implement that with asyncio, there is for \n> example a run_until_complete() method stopping the event loop when a future is \n> done. But asyncio event loop is designed to run \"forever\", so various projects \n> can run tasks \"at the same time\", not only a very specific section of the code \n> to run a set of tasks.\n> \n> asyncio is not only designed to schedule callbacks, it\'s also designed to \n> manager file descriptors (especially sockets). It can also spawn and manager \n> subprocessses. This is not supported by Heat scheduler.\n> \n> IMO Heat scheduler is too specific, it cannot be used widely in OpenStack.\n> \n\nThis is sort of backwards to what Josh was suggesting. Heat can\'t continue\nwith the current approach, which is coroutine based, because we need the\nthe execution stack to not be in RAM on a single engine. We are going\nto achieve even more concurrency than we have now through an even higher\nlevel of task abstraction as part of the move to a convergence model. We\nwill likely use task-flow to express these tasks so that they are more\nresumable and generally resilient to failure.\n\n> > Along a related question,\n> > seeing that openstack needs to support py2.x and py3.x will this mean that\n> > trollius will be required to be used in 3.x (as it is the least common\n> > denominator, not new syntax like \'yield from\' that won\'t exist in 2.x).\n> > Does this mean that libraries that will now be required to change will be\n> > required to use trollius (the pulsar[6] framework seemed to mesh these two\n> > nicely); is this understood by those authors?\n> \n> It *is* possible to write code working on asyncio and trollius:\n> http://trollius.readthedocs.org/#write-code-working-on-trollius-and-tulip\n> \n> They are different options for that. They are already projects supporting \n> asyncio and trollius.\n> \n> > Is this the direction we\n> > want to go down (if we stay focused on ensuring py3.x compatible, then why\n> > not just jump to py3.x in the first place)?\n> \n> FYI OpenStack does not support Python 3 right now. I\'m working on porting \n> OpenStack to Python 3, we made huge progress, but it\'s not done yet.\n> \n> Anyway, the new RHEL 7 release doesn\'t provide Python 3.3 in the default \n> system, you have to enable the SCL repository (which provides Python 3.3). And \n> Python 2.7 or even 2.6 is still used in production.\n> \n> I would also prefer to use directly \"yield from\" and \"just\" drop Python 2 \n> support. But dropping Python 2 support is not going to happen before at least \n> 2 years.\n> \n\nLong term porting is important, however, we have immediate needs for\nimprovements in resilience and scalability. We cannot hang _any_ of that\non Python 3.\n\n\n','<14658388.RJX01snU8Q@smithers>',NULL),('<1404856694.15592.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 22:58:14',3600,'2014-07-08 21:58:14',NULL,'[openstack-dev] [all] oslo.messaging 1.4.0.0a3 released','The Oslo team is pleased to announce the release of oslo.messaging\n1.4.0.0a3, another pre-release in the 1.4.0 series for oslo.messaging\nduring the Juno cycle:\n\n  https://pypi.python.org/pypi/oslo.messaging/1.4.0.0a3\n\noslo.messaging provides an API which supports RPC and notifications over\na number of different messaging transports.\n\nFull details of the 1.4.0.0a3 release is available here:\n\n  http://docs.openstack.org/developer/oslo.messaging/#a3\n\nPlease report problems using the oslo.messaging bug tracker:\n\n  https://bugs.launchpad.net/oslo.messaging\n\nThanks to all those who contributed to the release!\n\nMark.\n\n\n\n',NULL,NULL),('<1404917881.3404.6.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 09:58:01',-18000,'2014-07-09 14:58:01',NULL,'[openstack-dev] [nova] Limits API and project-user-quotas','On Fri, 2014-07-04 at 23:06 +0000, Day, Phil wrote:\n> Working on the server groups quotas I hit an issue with the limits API\n> which I wanted to get feedback on.\n> \n> Currently this always shows just the project level quotas and usage,\n> which can be confusing if there is a lower user specific quota.  For\n> example:\n[snip]\n> The quota API itself allows a user to get either the project level\n> quota or any per-user quota within that project ? which does make all\n> of the information available even if it is a tad odd that the default\n> (no user specified) is to see the overall quota rather than the one\n> that apples to the user making the  request.   They can?t however via\n> the quotas API find out project level usage.\n> \n> Thoughts on what the correct model is here ?\n\nMy thinking is that the limits API should only show rate limit\ninformation; you should have to go to the quotas API to get information\nabout quotas.  I really dislike the fact that we have two different\nsources for the same information, and the feature drift that\'s occurred\nhere is an excellent argument for my stance :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F00715803A@G6W2490.americas.hpqcorp.net>',NULL),('<1404918730-sup-361@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 08:39:33',-25200,'2014-07-09 15:39:33',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Excerpts from Yuriy Taraday\'s message of 2014-07-09 03:36:00 -0700:\n> On Tue, Jul 8, 2014 at 11:31 PM, Joshua Harlow <harlowja at yahoo-inc.com>\n> wrote:\n> \n> > I think clints response was likely better than what I can write here, but\n> > I\'ll add-on a few things,\n> >\n> >\n> > >How do you write such code using taskflow?\n> > >\n> > >  @asyncio.coroutine\n> > >  def foo(self):\n> > >      result = yield from some_async_op(...)\n> > >      return do_stuff(result)\n> >\n> > The idea (at a very high level) is that users don\'t write this;\n> >\n> > What users do write is a workflow, maybe the following (pseudocode):\n> >\n> > # Define the pieces of your workflow.\n> >\n> > TaskA():\n> >   def execute():\n> >       # Do whatever some_async_op did here.\n> >\n> >   def revert():\n> >       # If execute had any side-effects undo them here.\n> >\n> > TaskFoo():\n> >    ...\n> >\n> > # Compose them together\n> >\n> > flow = linear_flow.Flow(\"my-stuff\").add(TaskA(\"my-task-a\"),\n> > TaskFoo(\"my-foo\"))\n> >\n> \n> I wouldn\'t consider this composition very user-friendly.\n> \n\nI find it extremely user friendly when I consider that it gives you\nclear lines of delineation between \"the way it should work\" and \"what\nto do when it breaks.\"\n\n> > # Submit the workflow to an engine, let the engine do the work to execute\n> > it (and transfer any state between tasks as needed).\n> >\n> > The idea here is that when things like this are declaratively specified\n> > the only thing that matters is that the engine respects that declaration;\n> > not whether it uses asyncio, eventlet, pigeons, threads, remote\n> > workers[1]. It also adds some things that are not (imho) possible with\n> > co-routines (in part since they are at such a low level) like stopping the\n> > engine after \'my-task-a\' runs and shutting off the software, upgrading it,\n> > restarting it and then picking back up at \'my-foo\'.\n> >\n> \n> It\'s absolutely possible with coroutines and might provide even clearer\n> view of what\'s going on. Like this:\n> \n> @asyncio.coroutine\n> def my_workflow(ctx, ...):\n>     project = yield from ctx.run_task(create_project())\n>     # Hey, we don\'t want to be linear. How about parallel tasks?\n>     volume, network = yield from asyncio.gather(\n>         ctx.run_task(create_volume(project)),\n>         ctx.run_task(create_network(project)),\n>     )\n>     # We can put anything here - why not branch a bit?\n>     if create_one_vm:\n>         yield from ctx.run_task(create_vm(project, network))\n>     else:\n>         # Or even loops - why not?\n>         for i in range(network.num_ips()):\n>             yield from ctx.run_task(create_vm(project, network))\n> \n\nSorry but the code above is nothing like the code that Josh shared. When\ncreate_network(project) fails, how do we revert its side effects? If we\nwant to resume this flow after reboot, how does that work?\n\nI understand that there is a desire to write everything in beautiful\npython yields, try\'s, finally\'s, and excepts. But the reality is that\npython\'s stack is lost the moment the process segfaults, power goes out\non that PDU, or the admin rolls out a new kernel.\n\nWe\'re not saying \"asyncio vs. taskflow\". I\'ve seen that mistake twice\nalready in this thread. Josh and I are suggesting that if there is a\nmovement to think about coroutines, there should also be some time spent\nthinking at a high level: \"how do we resume tasks, revert side effects,\nand control flow?\"\n\nIf we embed taskflow deep in the code, we get those things, and we can\ntreat tasks as coroutines and let taskflow\'s event loop be asyncio just\nthe same. If we embed asyncio deep into the code, we don\'t get any of\nthe high level functions and we get just as much code churn.\n\n> There\'s no limit to coroutine usage. The only problem is the library that\n> would bind everything together.\n> In my example run_task will have to be really smart, keeping track of all\n> started tasks, results of all finished ones, skipping all tasks that have\n> already been done (and substituting already generated results).\n> But all of this is doable. And I find this way of declaring workflows way\n> more understandable than whatever would it look like with Flow.add\'s\n> \n\nThe way the flow is declared is important, as it leads to more isolated\ncode. The single place where the flow is declared in Josh\'s example means\nthat the flow can be imported, the state deserialized and inspected,\nand resumed by any piece of code: an API call, a daemon start up, an\nadmin command, etc.\n\nI may be wrong, but it appears to me that the context that you built in\nyour code example is hard, maybe impossible, to resume after a process\nrestart unless _every_ task is entirely idempotent and thus can just be\nrepeated over and over.\n\n\n','<CABocrW7+kcFNQNVEK4B9ckToxQVPk6XZ+BcqM5o1uZU5=MS6Yw@mail.gmail.com>',NULL),('<1404921059-sup-3132@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 08:52:27',-25200,'2014-07-09 15:52:27',NULL,'[openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and\n	Alexis Lee to core review team','Hello!\n\nI\'ve been looking at the statistics, and doing a bit of review of the\nreviewers, and I think we have an opportunity to expand the core reviewer\nteam in TripleO. We absolutely need the help, and I think these two\nindividuals are well positioned to do that.\n\nI would like to draw your attention to this page:\n\nhttp://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt\n\nSpecifically these two lines:\n\n+-------------------+---------------------------------------+----------------+\n|      Reviewer     | Reviews   -2  -1  +1  +2  +A    +/- % | Disagreements* |\n+-------------------+---------------------------------------+----------------+\n|  jonpaul-sullivan |     188    0  43 145   0   0    77.1% |   28 ( 14.9%)  |\n|       lxsli       |     186    0  23 163   0   0    87.6% |   27 ( 14.5%)  |\n\nNote that they are right at the level we expect, 3 per work day. And\nI\'ve looked through their reviews and code contributions: it is clear\nthat they understand what we\'re trying to do in TripleO, and how it all\nworks. I am a little dismayed at the slightly high disagreement rate,\nbut looking through the disagreements, most of them were jp and lxsli\nbeing more demanding of submitters, so I am less dismayed.\n\nSo, I propose that we add jonpaul-sullivan and lxsli to the TripleO core\nreviewer team.\n\n\n',NULL,NULL),('<1404928687.13275.3.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 13:58:07',-14400,'2014-07-09 17:58:07',NULL,'[openstack-dev] [Sahara] Error config?','Hi,\n\n  I believe if you look in the sahara log output you may see more\nmessages about this.  There should be some indicator of what the\nvalidation error was.\n\nTrevor\n\nOn Wed, 2014-07-09 at 23:44 +0700, Dat Tran wrote:\n> Thank matt,\n> \n> \n> It\'s worked. Can i ask you a question, please?\n> \n> \n> When i create file ng_master_template_create.json\n> and ng_worker_template_create.json. Then, I run:\n> http $SAHARA_URL/node-group-templates X-Auth-Token:$AUTH_TOKEN <\n> ng_master_template_create.json\n> \n> \n> Message:\n> \n> HTTP/1.1 500 INTERNAL SERVER ERROR\n> Content-Length: 111\n> Content-Type: application/json\n> Date: Wed, 09 Jul 2014 16:14:09 GMT\n> {\n>     \"error_code\": 500, \n>     \"error_message\": \"Error occurred during validation\", \n>     \"error_name\": \"INTERNAL_SERVER_ERROR\"\n> }\n> \n> \n> Thank you very very much!\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CALN3ZiV9EL6cOMSmz7XG4hF3RrPEYpx2SVqZ_XHe2dosJt-O4A@mail.gmail.com>',NULL),('<1404947311-sup-876@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 16:09:51',-25200,'2014-07-09 23:09:51',NULL,'[openstack-dev] [Heat] stevedore plugins (and wait conditions)','Excerpts from Randall Burt\'s message of 2014-07-09 15:33:26 -0700:\n> On Jul 9, 2014, at 4:38 PM, Zane Bitter <zbitter at redhat.com>\n>  wrote:\n> > On 08/07/14 17:17, Steven Hardy wrote:\n> > \n> >> Regarding forcing deployers to make a one-time decision, I have a question\n> >> re cost (money and performance) of the Swift approach vs just hitting the\n> >> Heat API\n> >> \n> >> - If folks use the Swift resource and it stores data associated with the\n> >>   signal in Swift, does that incurr cost to the user in a public cloud\n> >>   scenario?\n> > \n> > Good question. I believe the way WaitConditions work in AWS is that it sets up a pre-signed URL in a bucket owned by CloudFormation. If we went with that approach we would probably want some sort of quota, I imagine.\n> \n> Just to clarify, you suggest that the swift-based signal mechanism use containers that Heat owns rather than ones owned by the user?\n> \n\n+1, don\'t hide it.\n\n> > The other approach is to set up a new container, owned by the user, every time. In that case, a provider selecting this implementation would need to make it clear to customers if they would be billed for a WaitCondition resource. I\'d prefer to avoid this scenario though (regardless of the plug-point).\n> \n> Why? If we won\'t let the user choose, then why wouldn\'t we let the provider make this choice? I don\'t think its wise of us to make decisions based on what a theoretical operator may theoretically do. If the same theoretical provider were to also charge users to create a trust, would we then be concerned about that implementation as well? What if said provider decides charges the user per resource in a stack regardless of what they are? Having Heat own the container(s) as suggested above doesn\'t preclude that operator from charging the stack owner for those either.\n>\n\nThis is a nice use case for preview. A user should be able to preview a\nstack and know what will be consumed. Wait conditions will show a swift\ncontainer if preview is worth anything.\n\n\n','<307938FE-685D-4FEF-AF8D-EE9D0AB1AEC8@rackspace.com>',NULL),('<1404962880.30297.2.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 22:28:00',-18000,'2014-07-10 03:28:00',NULL,'[openstack-dev] Log / error message format best practices &\n standards','Boden,\n\nThanks for bringing this up:\n\nOn Thu, 2014-06-26 at 12:14 -0400, boden wrote:\n> We were recently having a discussion over here in trove regarding a \n> standardized format to use for log and error messages - obviously \n> consistency is ideal (within and across projects). As this discussion \n> involves the broader dev community, bringing this topic to the list for \n> feedback...\n> \n> \n> I\'m aware of the logging standards wiki[1], however this page does not \n> describe in depth a standardized format to use for log / error messages.\n> \n> In particular w/r/t program values in messages:\n> \n> (a) For in-line program values, I\'ve seen both single quoted and \n> unquoted formatting used. e.g.\n> single quote: LOG.info(\"The ID \'%s\' is not invalid.\" % (resource.id))\n\n+1  This isn\'t one I have been policing a lot in my reviews, but think\nthis is a good practice.\n\n> unquoted: LOG.info(\"The ID %s is not valid.\" % (resource.id))\n> \n> (b) For program values appended to the message, I\'ve seen various \n> formats used. e.g.\n> LOG.info(\"This path is invalid: %s\" % (obj.path))\n\n+1 This is one I have been enforcing in Cinder reviews.\n\nIf I had documentation to point to for such things I think it would be\ngood to reference in the reviews.\n\n> LOG.info(\"This path is invalid %s\" % (obj.path))\n> LOG.info(\"This path is invalid - %s\" % (obj.path))\n> \n> \n>  From a consistency perspective, it seems we should consider \n> standardizing a best practice for such formatting.\n> \n> For in-line values (#a above) I find single quotes the most consumable \n> as they are a clear indication the value came from code and moreover \n> provide a clear set of delimiters around the value. However to date \n> unquoted appears to be the most widely used.\n> \n> For appended values (#b above) I find a delimiter such as \':\' most \n> consumable as it provides a clear boundary between the message and \n> value. Using \':\' seems fairly common today, but you\'ll find other \n> formatting throughout the code.\n> \n> If we wanted to squash this topic the high level steps are (approximately):\n> - Determine and document message format.\n> - Ensure the format is part of the dev process (coding + review).\n> - Cross team work to address existing messages not following the format.\n> \n> \n> Thoughts / comments?\n> \n> \n> [1] https://wiki.openstack.org/wiki/LoggingStandards\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53AC46E8.2080207@linux.vnet.ibm.com>',NULL),('<1404997423.81966.YahooMailNeo@web194604.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-10 21:03:43',28800,'2014-07-10 13:03:43',NULL,'[Openstack] [Ironic][]Not able to run two instances using baremetal\n	with devstack','Hi all,\n\nI am trying to run instances using baremetal. To do the setup with openstack, I followed this guide:?http://docs.openstack.org/developer/ironic/dev/dev-quickstart.html#deploying-ironic-with-devstack\n\nNow, the setup is done, but I am only able to run one instance. As soon as I try to run another instance it goes in BUILD status, and \"another\" node in ironic node-list shows it\'s deploying. But after few moments, the instance goes into Error state. Any idea what\'s going wrong here??\n\nI am running devstack on a VM on ubuntu 12.04.\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140710/ab9bb176/attachment.html>\n\n',NULL,NULL),('<1404999062.16467.12.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 09:31:02',-14400,'2014-07-10 13:31:02',NULL,'[openstack-dev] [Ironic] handling drivers that will not be\n third-party tested','On Wed, 2014-05-21 at 17:03 -0700, Devananda van der Veen wrote:\n> I\'d like to bring up the topic of drivers which, for one reason or\n> another, are probably never going to have third party CI testing.\n> \n> \n> Take for example the iBoot driver proposed here:\n>   https://review.openstack.org/50977\n> \n> \n> I would like to encourage this type of driver as it enables individual\n> contributors, who may be using off-the-shelf or home-built systems, to\n> benefit from Ironic\'s ability to provision hardware, even if that\n> hardware does not have IPMI or another enterprise-grade out-of-band\n> management interface.\n>  However, I also don\'t expect the author to provide a full third-party\n> CI environment, and as such, we should not claim the same level of\n> test coverage and consistency as we would like to have with drivers in\n> the gate. \n> \n> \n> As it is, Ironic already supports out-of-tree drivers. A python module\n> that registers itself with the appropriate entrypoint will be made\n> available if the ironic-conductor service is configured to load that\n> driver. For what it\'s worth, I recall Nova going through a very\n> similar discussion over the last few cycles... \n> \n> \n> So, why not just put the driver in a separate library on github or\n> stackforge?\n\nSo a few months have gone by since this was initially brought up. I\'ve\nbeen consistently rebasing the iboot driver patch along to deal with API\nchanges (breakages). The Ironic power driver API, as small as it is, has\nnot proven to be stable yet. As such I\'m even more convinced these sorts\nof drivers benefit from living in-tree where unit tests give us some\nlevel of coverage to guard against internal Ironic API breakage.\n\nSo... why not merge this driver as-is? It already exists in Nova.\nFurthermore I feel like it is a bit arbitrary to hold up this driver\nwhen we already have other 3rd party drivers in the Ironic tree\n(seamicro for example) where there is no 3rd party CI.\n\nThe comments on this list seemed to support having these drivers live\nin-tree regardless of 3rd party CI.\n\nDan\n\n> \n> \n> \n> \n> -Devananda\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEq2VngAC+cp22VH8e1e55FxmcvD1NfgDGjmM+6aVRBbVg@mail.gmail.com>',NULL),('<1405005574-sup-3503@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 08:24:09',-25200,'2014-07-10 15:24:09',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Excerpts from Victor Stinner\'s message of 2014-07-10 05:57:38 -0700:\n> Le jeudi 10 juillet 2014, 14:48:04 Yuriy Taraday a ?crit :\n> > I\'m not suggesting that taskflow is useless and asyncio is better (apple vs\n> > oranges). I\'m saying that using coroutines (asyncio) can improve ways we\n> > can use taskflow and provide clearer method of developing these flows.\n> > This was mostly response to the \"this is impossible with coroutines\". I say\n> > it is possible and it can even be better.\n> \n> It would be nice to modify taskflow to support trollius coroutines. Coroutines \n> supports asynchronous operations and has a better syntax than callbacks.\n> \n\nYou mean like this:\n\nhttps://review.openstack.org/#/c/90881/1/taskflow/engines/action_engine/executor.py\n\nAbandoned, but I think Josh is looking at it. :)\n\n> For Mark\'s spec, add a new greenio executor to Oslo Messaging: I don\'t see the \n> direct link to taskflow. taskflow can use Oslo Messaging to call RPC, but I \n> don\'t see how to use taskflow internally to read a socket (driver), wait for \n> the completion of the callback and then send back the result to the socket \n> (driver).\n> \n\nSo oslo and the other low level bits are going to need to be modified\nto support coroutines. That is definitely something that will make them\nmore generally useful anyway. I don\'t think Josh or I meant to get in\nthe way of that.\n\nHowever, having this available is a step toward removing eventlet and\ndoing the painful work to switch to asyncio. Josh\'s original email was\nin essence a reminder that we should consider a layer on top of asyncio\nand eventlet alike, so that the large scale code changes only happen\nonce.\n\n> I see trollius as a low-level tool to handle simple asynchronous operations, \n> whereas taskflow is more high level to chain correctly more complex operations.\n> \n\n_yes_\n\n> trollius and taskflow must not be exclusive options, they should cooperate, as \n> we plan to support trollius coroutines in Oslo Messaging.\n> \n\nIn fact they are emphatically not exclusive. However, considering the\norder of adoption should produce a little less chaos for the project.\n> \n\n\n','<2161985.X7gsafRJo0@smithers>',NULL),('<1405005576.2040.5.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 08:19:36',-25200,'2014-07-10 15:19:36',NULL,'[openstack-dev] [Containers] Nova virt driver requirements','On Thu, 2014-07-10 at 14:47 +0100, Daniel P. Berrange wrote:\n> On Thu, Jul 10, 2014 at 05:36:59PM +0400, Dmitry Guryanov wrote:\n> > I have a question about mounts - in OpenVZ project each container has its own \n> > filesystem in an image file. So to start a container we mount this filesystem \n> > in host OS (because all containers share the same linux kernel). Is it a \n> > security problem from the Openstack\'s developers vision?\n> > \n> > \n> > I have this question, because libvirt\'s driver uses libguestfs to copy some \n> > files into guest filesystem instead of simple mount on host. Mounting with \n> > libguestfs is slower, then mount on host, so there should be strong reasons, \n> > why libvirt driver does it.\n> \n> We consider mounting untrusted filesystems on the host kernel to be\n> an unacceptable security risk. A user can craft a malicious filesystem\n> that expliots bugs in the kernel filesystem drivers. This is particularly\n> bad if you allow the kernel to probe for filesystem type since Linux\n> has many many many filesystem drivers most of which are likely not\n> audited enough to be considered safe against malicious data. Even the\n> mainstream ext4 driver had a crasher bug present for many years\n> \n>   https://lwn.net/Articles/538898/\n>   http://libguestfs.org/guestfs.3.html#security-of-mounting-filesystems\n\nActually, there\'s a hidden assumption here that makes this statement not\nnecessarily correct for containers.  You\'re assuming the container has\nto have raw access to the device it\'s mounting.  For hypervisors, this\nis true, but it doesn\'t have to be for containers because the mount\noperation is separate from raw read and write so we can allow or deny\nthem granularly.\n\nConsider the old use case, where the container root is actually a\nsubdirectory of the host filesystem which gets bind mounted.  The\ncontainer has no possibility of altering the underlying block device\nthere.  For block roots, which we also do, at least in the VPS world,\nthey\'re mostly initialised by the hosting provider and the VPS\nenvironment doesn\'t actually get to read or write directly to them\n(there\'s often a block on this).  Of course, they *can* be set up so the\nVPS has raw access and I believe some are, but it\'s a choice not a\nrequirement.\n\nJames\n\n\n\n\n','<20140710134710.GI23577@redhat.com>',NULL),('<1405010810.27662.58.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 17:46:50',3600,'2014-07-10 16:46:50',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','On Thu, 2014-07-03 at 16:27 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> This is an attempt to summarize a really useful discussion that Victor,\n> Flavio and I have been having today. At the bottom are some background\n> links - basically what I have open in my browser right now thinking\n> through all of this.\n> \n> We\'re attempting to take baby-steps towards moving completely from\n> eventlet to asyncio/trollius. The thinking is for Ceilometer to be the\n> first victim.\n\nI got a little behind on this thread, but maybe it\'d be helpful to\nsummarize some things from this good discussion:\n\n   - \"Where/when was this decided?!?\"\n\n     Victor is working on prototyping how an OpenStack service would\n     move to using asyncio. Whether a move to asyncio across the board\n     makes sense - and what exactly it would look like - hasn\'t been\n     *decided*. The idea is merely being explored at this point.\n\n   - \"Is moving to asyncio really a priority compared to other things?\"\n\n     I think Victor has made a good case on \"what\'s wrong with \n     eventlet?\"[1] and, personally, I\'m excited about the prospect of \n     the Python community more generally converging on asyncio. \n     Understanding what OpenStack would need in order move to asyncio \n     will help the asyncio effort more generally.\n\n     Figuring through some of this stuff is a priority for Victor and\n     others, but no-one is saying it\'s an immediate priority for the \n     whole project.\n\n   - Moving from an implicitly async to an explicitly async programming\n     has enormous implications and we need to figure out what it means\n     for libraries like SQLalchemy and abstraction layers like ORMs. \n\n     I think that\'s well understood - the topic of this thread is \n     merely how to make a small addition to oslo.messaging (the ability \n     to dispatch asyncio co-routines on eventlet) so that we can move on\n     to figuring out the next piece of puzzle.\n\n   - Some people are clearly skeptical about whether asyncio is the \n     right thing for Python generally, whether it\'s the right thing for \n     OpenStack, whatever. Personally, I\'m optimistic but I don\'t find \n     the conversation all that interesting right now - I want to see \n     how the prototype efforts work out before making a call about \n     whether it\'s feasible and useful.\n\n   - Taskflow vs asyncio - good discussion, plenty to figure out. \n     They\'re mostly orthogonal concerns IMHO but *maybe* we decide\n     adopting both makes sense and that both should be adopted together.\n     I\'d like to see more concrete examples showing taskflow vs asyncio\n     vs taskflow/asyncio to understand better.\n\nSo, tl;dr is that lots of work remains to even begin to understand how\nexactly asyncio could be adopted and whether that makes sense. The\nthread raises some interesting viewpoints, but I don\'t think it moves\nour understanding along all that much. The initial mail was simply about\nunlocking one very small piece of the puzzle.\n\nMark.\n\n[1] - http://techs.enovance.com/6562/asyncio-openstack-python3\n\n\n\n','<1404401278.2723.59.camel@sorcha>',NULL),('<1405011280.27662.66.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 17:54:40',3600,'2014-07-10 16:54:40',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','On Mon, 2014-07-07 at 12:48 +0200, Nikola ?ipanov wrote:\n\n> When I read all of this stuff and got my head around it (took some time\n> :) ), a glaring drawback of such an approach, and as I mentioned on the\n> spec proposing it [1] is that we would not really doing asyncio, we\n> would just be pretending we are by using a subset of it\'s APIs, and\n> having all of the really important stuff for overall design of the code\n> (code that needs to do IO in the callbacks for example) and ultimately -\n> performance, completely unavailable to us when porting.\n> \n> So in Mark\'s example above:\n> \n>   @asyncio.coroutine\n>   def foo(self):\n>     result = yield from some_async_op(...)\n>     return do_stuff(result)\n> \n> A developer would not need to do anything that asyncio requires like\n> make sure that some_async_op() registers a callback with the eventloop\n> (using for example event_loop.add_reader/writer methods) you could just\n> simply make it use a \'greened\' call and things would continue working\n> happily.\n\nYes, Victor and I noticed this problem and wondered whether there was a\nway to e.g. turn-off the monkey-patching at runtime in a single\ngreenthread, or even just make any attempt to context switch raise an\nexception.\n\ni.e. a way to run foo() coroutine above in a greenthread such that\ncontext switching is disallowed, or logged, or whatever while the\nfunction is running. The only way context switching would be allowed to\nhappen would be if the coroutine yielded.\n\n>  I have a feeling this will in turn have a lot of people writing\n> code that they don\'t understand, and as library writers - we are not\n> doing an excellent job at that point.\n> \n> Now porting an OpenStack project to another IO library with completely\n> different design is a huge job and there is unlikely a single \'right\'\n> way to do it, so treat this as a discussion starter, that will hopefully\n> give us a better understanding of the problem we are trying to tackle.\n> \n> So I hacked up together a small POC of a different approach. In short -\n> we actually use a real asyncio selector eventloop in a separate thread,\n> and dispatch stuff to it when we figure out that our callback is in fact\n> a coroutine. More will be clear form the code so:\n> \n> (Warning - hacky code ahead): [2]\n> \n> I will probably be updating it - but if you just clone the repo, all the\n> history is there. I wrote it without the oslo.messaging abstractions\n> like listener and dispatcher, but it is relatively easy to see which\n> bits of code would go in those.\n> \n> Several things worth noting as you read the above. First one is that we\n> do not monkeypatch until we have fired of the asyncio thread (Victor\n> correctly noticed this would be a problem in a comment on [1]). This may\n> seem hacky (and it is) but if decide to go further down this road - we\n> would probably not be \'greening the world\' but rather importing patched\n> non-ported modules when we need to dispatch to them. This may sound like\n> a big deal, and it is, but it is critical to actually running ported\n> code in a real asyncio evenloop. I have not yet tested this further, but\n> from briefly reading eventlet code - it seems like ti should work.\n> \n> Another interesting problem is (as I have briefly mentioned in [1]) -\n> what happens when we need to synchronize between eventlet-run and\n> asyncio-run callbacks while we are in the process of porting. I don\'t\n> have a good answer to that yet, but it is worth noting that the proposed\n> approach doesn\'t either, and this is a thing we should have some idea\n> about before going in with a knife.\n> \n> Now for some marketing :) - I can see several advantages of such an\n> approach, the obvious one being as stated, that we are in fact doing\n> asyncio, so we are all in. Also as you can see [2] the implementation is\n> far from magical - it\'s (surprisingly?) simple, and requires no other\n> additional dependencies apart from trollius itself (granted greenio is\n> not too complex either). I am sure that we would hit some other problems\n> that were not clear from this basic POC (it was done in ~3 hours on a\n> bus), but it seems to me that those problems will likely need to be\n> solved anyhow if we are to port Ceilometer (or any other project) to\n> asyncio, we will just hit them sooner this way.\n> \n> It was a fun approach to ponder anyway - so I am looking forward to\n> comments and thoughts.\n\nIt\'s an interesting idea and I\'d certainly welcome a more detailed\nanalysis of what the approach would mean for a service like Ceilometer.\n\nMy instinct is that adding an additional native thread where there is\nonly one native thread now will lead to tricky concurrency issues and a\nmore significant change of behavior than with the greenio approach. The\nreason I like the greenio idea is that it allows us to make the\nprogramming model changes without very significantly changing what\nhappens at runtime - the behavior, order of execution, concurrency\nconcerns, etc. shouldn\'t be all that different.\n\nMark.\n\n\n\n','<53BA7B1B.7070802@redhat.com>',NULL),('<1405011997.27662.69.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 18:06:37',3600,'2014-07-10 17:06:37',NULL,'[openstack-dev] [all] oslo.messaging 1.4.0.0a3 released','On Wed, 2014-07-09 at 03:53 +0000, Paul Michali (pcm) wrote:\n> Mark,\n> \n> \n> What is the status of adding the newer oslo.messaging releases to\n> global requirements? I had tried to get 1.4.0.0a2 added to\n> requirements (https://review.openstack.org/#/c/103536/), but it was\n> failing Jenkins. Wondering how we get that version (or newer) into\n> global requirements (some issue with pre-releases?).\n\nYeah, I don\'t know what the latest status is with this beyond\n\"bandersnatch\":\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-July/039089.html\n  https://review.openstack.org/#/q/project:openstack-infra/config+topic:bandersnatch,n,z\n  https://review.openstack.org/103256\n\nMark.\n\n> \n> \n> Thanks,\n> \n> PCM (Paul Michali)\n> \n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pcm_ (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> \n> \n> \n> On Jul 8, 2014, at 4:58 PM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > The Oslo team is pleased to announce the release of oslo.messaging\n> > 1.4.0.0a3, another pre-release in the 1.4.0 series for\n> > oslo.messaging\n> > during the Juno cycle:\n> > \n> >  https://pypi.python.org/pypi/oslo.messaging/1.4.0.0a3\n> > \n> > oslo.messaging provides an API which supports RPC and notifications\n> > over\n> > a number of different messaging transports.\n> > \n> > Full details of the 1.4.0.0a3 release is available here:\n> > \n> >  http://docs.openstack.org/developer/oslo.messaging/#a3\n> > \n> > Please report problems using the oslo.messaging bug tracker:\n> > \n> >  https://bugs.launchpad.net/oslo.messaging\n> > \n> > Thanks to all those who contributed to the release!\n> > \n> > Mark.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<18819088-0CF6-4DFA-BB10-373373D3024E@cisco.com>',NULL),('<1405012757.27662.72.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 18:19:17',3600,'2014-07-10 17:19:17',NULL,'[openstack-dev] [all] Treating notifications as a contract','On Thu, 2014-07-10 at 04:48 -0400, Eoghan Glynn wrote:\n> TL;DR: do we need to stabilize notifications behind a versioned\n>        and discoverable contract?\n> \n> Folks,\n> \n> One of the issues that has been raised in the recent discussions with\n> the QA team about branchless Tempest relates to some legacy defects\n> in the OpenStack notification system.\n\nGot links to specifics? I thought the consensus was that there was a\ncontract here which we need to maintain, so I\'d be curious where that\nbroke down.\n\nVersioning and ability to newer contract versions would be good too, but\nin the absence of such things we should maintain backwards compat.\n\nMark.\n\n\n\n','<501911230.8848131.1404982125650.JavaMail.zimbra@redhat.com>',NULL),('<1405022326-sup-6834@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 20:04:04',0,'2014-07-10 20:04:04',NULL,'[openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and\n	Alexis Lee to core review team','Excerpts from Clint Byrum\'s message of 2014-07-09 15:52:27 +0000:\n> Hello!\n> \n> I\'ve been looking at the statistics, and doing a bit of review of the\n> reviewers, and I think we have an opportunity to expand the core reviewer\n> team in TripleO. We absolutely need the help, and I think these two\n> individuals are well positioned to do that.\n> \n> I would like to draw your attention to this page:\n> \n> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt\n> \n> Specifically these two lines:\n> \n> +-------------------+---------------------------------------+----------------+\n> |      Reviewer     | Reviews   -2  -1  +1  +2  +A    +/- % | Disagreements* |\n> +-------------------+---------------------------------------+----------------+\n> |  jonpaul-sullivan |     188    0  43 145   0   0    77.1% |   28 ( 14.9%)  |\n> |       lxsli       |     186    0  23 163   0   0    87.6% |   27 ( 14.5%)  |\n> \n> Note that they are right at the level we expect, 3 per work day. And\n> I\'ve looked through their reviews and code contributions: it is clear\n> that they understand what we\'re trying to do in TripleO, and how it all\n> works. I am a little dismayed at the slightly high disagreement rate,\n> but looking through the disagreements, most of them were jp and lxsli\n> being more demanding of submitters, so I am less dismayed.\n> \n> So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core\n> reviewer team.\n> \n\n+1 to both additions.\n\nCongrats!\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<1404921059-sup-3132@fewbar.com>',NULL),('<1405023476-sup-8372@greghaynes0>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 20:19:39',0,'2014-07-10 20:19:39',NULL,'[openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node\n	Management - Juno','Excerpts from Jaromir Coufal\'s message of 2014-07-09 07:51:56 +0000:\n> Hey folks,\n> \n> after few rounds of reviews and feedbacks, I am sending wireframes, \n> which are ready for implementation in Juno:\n> \n> http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf\n> \n> Let me know in case of any questions.\n> \n\nLooks awesome!\n\nI may be way off base here (not super familiar with Tuskar) but what\nabout bulk importing of nodes? This is basically the only way devtest\nmakes use of nodes nowdays, so it might be nice to allow people to use\nthe same data file in both places (nodes.json blob).\n\n-Greg\n\n-- \nGregory Haynes\ngreg at greghaynes.net\n\n\n','<53BCF49C.9010701@redhat.com>',NULL),('<1405057795.27662.77.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-11 06:49:55',3600,'2014-07-11 05:49:55',NULL,'[openstack-dev] [all] oslo.config 1.4.0.0a2 released','The Oslo team is pleased to announce the release of oslo.config\n1.4.0.0a2, another pre-release in the 1.4.0 series for oslo.config\nduring the Juno cycle:\n\n  https://pypi.python.org/pypi/oslo.config/1.4.0.0a2\n\noslo.config provides an API which supports parsing command line\narguments and .ini style configuration files.\n\nFull details of the 1.4.0.0a2 release is available here:\n\n  http://docs.openstack.org/developer/oslo.config/#a2\n\nPlease report problems using the oslo bug tracker:\n\n  https://bugs.launchpad.net/oslo\n\nThanks to all those who contributed to the release!\n\nMark.\n\n\n\n',NULL,NULL),('<1405093961-sup-6102@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-11 09:04:53',-25200,'2014-07-11 16:04:53',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Excerpts from Yuriy Taraday\'s message of 2014-07-11 03:08:14 -0700:\n> On Thu, Jul 10, 2014 at 11:51 PM, Josh Harlow <harlowja at outlook.com> wrote:\n> > 2. Introspection, I hope this one is more obvious. When the coroutine\n> > call-graph is the workflow there is no easy way to examine it before it\n> > executes (and change parts of it for example before it executes). This is a\n> > nice feature imho when it\'s declaratively and explicitly defined, you get\n> > the ability to do this. This part is key to handling upgrades that\n> > typically happen (for example the a workflow with the 5th task was upgraded\n> > to a newer version, we need to stop the service, shut it off, do the code\n> > upgrade, restart the service and change 5th task from v1 to v1.1).\n> >\n> \n> I don\'t really understand why would one want to examine or change workflow\n> before running. Shouldn\'t workflow provide just enough info about which\n> tasks should be run in what order?\n> In case with coroutines when you do your upgrade and rerun workflow, it\'ll\n> just skip all steps that has already been run and run your new version of\n> 5th task.\n> \n\nI\'m kind of with you on this one. Changing the workflow feels like self\nmodifying code.\n\n> 3. Dataflow: tasks in taskflow can not just declare workflow dependencies\n> > but also dataflow dependencies (this is how tasks transfer things from one\n> > to another). I suppose the dataflow dependency would mirror to coroutine\n> > variables & arguments (except the variables/arguments would need to be\n> > persisted somewhere so that it can be passed back in on failure of the\n> > service running that coroutine). How is that possible without an\n> > abstraction over those variables/arguments (a coroutine can\'t store these\n> > things in local variables since those will be lost)?It would seem like this\n> > would need to recreate the persistence & storage layer[5] that taskflow\n> > already uses for this purpose to accomplish this.\n> >\n> \n> You don\'t need to persist local variables. You just need to persist results\n> of all tasks (and you have to do it if you want to support workflow\n> interruption and restart). All dataflow dependencies are declared in the\n> coroutine in plain Python which is what developers are used to.\n> \n\nThat is actually the problem that using declarative systems avoids.\n\n\n    @asyncio.couroutine\n    def add_ports(ctx, server_def):\n        port, volume = yield from asyncio.gather(ctx.run_task(create_port(server_def)),\n                                                 ctx.run_task(create_volume(server_def))\n        if server_def.wants_drbd:\n            setup_drbd(volume, server_def)\n\n        yield from ctx.run_task(boot_server(volume_az, server_def))\n\n\nNow we have a side effect which is not in a task. If booting fails, and\nwe want to revert, we won\'t revert the drbd. This is easy to miss\nbecause we\'re just using plain old python, and heck it already even has\na test case.\n\nI see this type of thing a lot.. we\'re not arguing about capabilities,\nbut about psychological differences. There are pros and cons to both\napproaches.\n\n\n','<CABocrW76N7oduOhnk7U3vg_JT6q6C_EdaR9aR59QiUfGPT+wNw@mail.gmail.com>',NULL),('<1405107183797.81259@fusionio.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-11 19:33:35',0,'2014-07-11 19:33:35',NULL,'[OpenStack-Infra] Gerrit System account','Good afternoon,\n\n\n    Based on the new rules for Cinder testing, I need to setup a CI system for Fusion-io.\n\n\n    I would like to request a Gerrit System Account for our CI system.  The information I believe is necessary for this request is\n\n    1) SSH Key = Attached\n\n    2) Preferred Username = fusionio-ci\n\n    3) Human Readable display name = Fusion-io Inc.\n\n    4) unique contact e-mail = openstack-cinder-iocontrol at fusionio.com\n\n\n    Please let me know if I am missing anything.\n\n\nThanks,\n\nEd\n\n\n--\nEdward (Ed) Balduf\nPrinciple Scale Architect\nFusion-io\nMobile: 303-618-0690\nebalduf at fusionio.com\n\nVCP 4 & 5: #72980\nNTAP: NCDA, NCIE\n\n\nThis e-mail (and any attachments) is confidential and may be privileged.  Any unauthorized use, copying, disclosure or dissemination of this communication is prohibited.  If you are not the intended recipient,  please notify the sender immediately and delete all copies of the message and its attachments.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140711/e7741e71/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: id_rsa.pub\nType: application/vnd.ms-publisher\nSize: 395 bytes\nDesc: id_rsa.pub\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140711/e7741e71/attachment.bin>\n\n',NULL,NULL),('<1405115573.31115.41.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-11 16:52:53',-18000,'2014-07-11 21:52:53',NULL,'[OpenStack-Infra] Auto-expire turned off?','I just ran across a nova patch[1] that was pushed up in April and had\nits last activity on April 23rd (at least until I commented), yet it was\nstill open.  Did we turn off auto-expire of patches?  I don\'t recall\nseeing a discussion of it, but perhaps I just missed it?\n\n[1] https://review.openstack.org/#/c/89487/\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1405117203.31115.43.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-07-11 17:20:03',-18000,'2014-07-11 22:20:03',NULL,'[OpenStack-Infra] Auto-expire turned off?','On Fri, 2014-07-11 at 15:17 -0700, Morgan Fainberg wrote:\n> If I recall, this was in fact deliberately turned off. Since core\n> reviewers can now both set WIP and abandon/restore patches, the\n> auto-cleanup is not required (if the patch isn\'t relevant it can be\n> abandoned, but it won\'t automatically disappear). \n\nOK, I probably missed that in the big thread about the Gerrit update,\nthen.  I asked because I found a bunch of nova reviews that have been\nopened for several months; I may bring it up on the dev list to see if\nanyone else is bothered by the accumulated clutter :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAGnj6avbyv6nf76EPZDGV1Uye2OhRumZY-zG6cqKx1CmrZY55A@mail.gmail.com>',NULL),('<1405117832.31115.53.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-11 17:30:32',-18000,'2014-07-11 22:30:32',NULL,'[openstack-dev] [nova][all] Old review expiration','I decided to do some Nova reviews today, and I decided to do it by\npulling up the list of all of them and start from the end.  What I\'ve\nfound is a *lot* of reviews that have been idle for several months.\nI\'ve even found one or two that were approved, but weren\'t merged due to\ndepending on an outdated patch, and I found others that had several +1s\nbut no -1s or +2s.  There are 2 or 3 pages of these old reviews hanging\nat the end of the list, and it made me ask about the auto-expiration we\nused to have?I missed it in the Gerrit upgrade thread, but it turns out\nthat, since core reviewers can now abandon/restore patches, the\nauto-expiration has been turned off.\n\nGiven that we have so many old reviews hanging around on nova (and\nprobably other projects), should we consider setting something like that\nback up?  With nova, at least, the vast majority of them can\'t possibly\nmerge because they\'re so old, so we need to at least have something to\nremind the developer that they need to rebase?and if they\'ve forgotten\nthe review or don\'t care about it anymore, we should either have it\ntaken over or get the review abandoned.\n\nThe other concern I have is the several reviews that no core dev looked\nat in an entire month, but I have no solutions to suggest there,\nunfortunately :(\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1405289289.8068.141197985.4CD10BC3@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-13 15:08:09',-25200,'2014-07-13 22:08:09',NULL,'[openstack-dev] [TripleO] pypi-mirror is now unsupported - what\n do we do now?','\n\nOn Sun, Jul 13, 2014, at 02:36 PM, James Polley wrote:\n\n\nWe\'re also thinking about how we continue to offer the\npre-built wheels\n\nfor each of our build platforms. For infra, what I\'m thinking\nis:\n\n\n\nOn each mirror slave (We have one for each OS combo we use), do\n\nsomething similar to:\n\n\n\npip wheel -r global-requirements.txt\n\nrsync $wheelhouse [1]pypi.openstack.org/$(lsb_release)\n\n\n\nThis may require keeping pypi-mirror and using an option to\nonly do\n\nwheel building so that we can get the directory publication\nsplit. Ok. I\n\ngot bored and wrote that:\n\n\n\n[2]https://review.openstack.org/106638\n\n\n\nSo if we land that, you can do;\n\n\n\npip wheel -r global-requirements.txt\n\nrun-mirror --wheels-only --wheelhouse=wheelhouse\n--wheeldest=mirror\n\nrsync -avz mirror pypi.openstack.org:/srv/mirror\n\n\n\nIf we went the devpi route, we could do;\n\n\n\npip wheel -r global-requirements.txt\n\nfor pkg in $wheelhouse; do\n\n  devpi upload $pkg\n\ndone\n\n\n\nAnd put that into a cron.\n\n\nObviously \"keeping pypi-mirror\" would require the least amount\nof change to how we suggest developers set up their systems.\n\nI think the devpi option seems fairly reasonable too. It looks\nlike it\'s easier (and faster, and less bandwidth-consuming)\nthan setting up bandersnatch or apt-mirror, which we currently\nsuggest people consider. It doesn\'t look any more heavyweight\nthan having a squid proxy for caching, which we currently\nsuggest as a bare minimum.\n\nFor an individual dev testing their own setup, I think we need\na slightly different approach from the infra approach listed\nabove though. I\'m assuming that it\'s possible to probe the\npackage index to determine if a wheel is available for a\nparticular version of a package yet. If that\'s the case, we\nshould be able to tweak tools like os-svc-install to notice\nwhen no wheel is available, and build and upload the wheel.\n\nI think this should give us a good balance between making sure\nthat each build (except the first) uses wheels to save time,\nstill gets the latest packages (since the last time the system\nwas online at least), and the user doesn\'t need to remember to\nmanually update the wheels when they\'re online.\n\n\n\nThis gave me an idea:\n\nThere was talk about pip being able to use a wheel cache\n(wheelhouse). Can we bind-mount an arch-specific wheelhouse\nfrom the hypervisor into our chroots as we build? This would\nlet people get most of the wheel speedup while doing almost no\nspecifal configuration.\n\n\n\n-Greg\n\nReferences\n\n1. http://pypi.openstack.org/$(lsb_release)\n2. https://review.openstack.org/106638\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140713/890940c0/attachment.html>\n\n','<CAPtRfUGYvrdd3ZkkWDkEqn1aNLA4yF9gnxTSUMd13CnnOM8E8w@mail.gmail.com>',NULL),('<1405303082.19790.1.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-07-14 01:58:07',0,'2014-07-14 01:58:07',NULL,'[Openstack-stable-maint] Stable check of openstack/keystone\n failed','On Fri, 2014-07-11 at 08:53 +0200, Alan Pevec wrote:\n> Hi Dolph and Jamie,\n> \n> > - periodic-keystone-python27-havana http://logs.openstack.org/periodic-stable/periodic-keystone-python27-havana/7db0b28 : FAILURE in 13m 09s\n> \n> \"Plugin loading from config objects\" was merged to keystoneclient\n> master which adds stevedore dependency not present in Havana Keystone\n> test-requirements.\n> Havana global-requirements has stevedore>=0.10 is that enough or we\n> need to bump Havana global to 0.14 ?\n> \n> Cheers,\n> Alan\n\nAlan, \n\nI went back through the stevedore changelog\n(http://stevedore.readthedocs.org/en/latest/history.html ) and ran the\ntests i have (not all committed) and as far as i can tell the 0.10\nversion will work just fine. \n\nOut of interest though how do we manage this? I can\'t submit to\nkeystoneclient master a version that is not in the global requirements.\n\n\nJamie\n\n\n\n','<CAGi==UXYUC3k+N+8bO1czoXJfgqP5T=pEL0uUPhLHoxUgtGb5g@mail.gmail.com>',NULL),('<1405341437.8599.1.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 14:37:17',7200,'2014-07-14 12:37:17',NULL,'[openstack-dev] [Ironic] Nominating Jim Rollenhagen to\n ironic-core','+1, much awaited!\n\nOn Fri, 2014-07-11 at 15:50 -0700, Devananda van der Veen wrote:\n> Hi all!\n> \n> \n> It\'s time to grow the team :)\n> \n> \n> Jim (jroll) started working with Ironic at the last mid-cycle, when\n> \"teeth\" became ironic-python-agent. In the time since then, he\'s\n> jumped into Ironic to help improve the project as a whole. In the last\n> few months, in both reviews and discussions on IRC, I have seen him\n> consistently demonstrate a solid grasp of Ironic\'s architecture and\n> its role within OpenStack, contribute meaningfully to design\n> discussions, and help many other contributors. I think he will be a\n> great addition to the core review team.\n> \n> \n> Below are his review stats for Ironic, as calculated by the\n> openstack-infra/reviewstats project with local modification to remove\n> ironic-python-agent, so we can see his activity in the main project.\n> \n> \n> Cheers,\n> Devananda\n> \n> \n> +--------------------------+---------------------------------------+----------------+\n> |         Reviewer         | Reviews   -2  -1  +1  +2  +A    +/- % |\n> Disagreements* |\n> +--------------------------+---------------------------------------+----------------+\n> \n> \n> 30\n> |      jimrollenhagen      |      29    0   8  21   0   0    72.4% |\n>    5 ( 17.2%)  |\n> \n> \n> 60\n> |      jimrollenhagen      |      76    0  16  60   0   0    78.9% |\n> 13 ( 17.1%)  |\n> \n> \n> 90\n> |      jimrollenhagen      |     106    0  27  79   0   0    74.5% |\n> 25 ( 23.6%)  |\n> \n> \n> 180\n> |      jimrollenhagen      |     157    0  41 116   0   0    73.9% |\n> 35 ( 22.3%)  |\n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEocr91GdtaapA_JcuAAg4KntTJxKyzUg=6i0LLX7HMwMw@mail.gmail.com>',NULL),('<1405341507.8599.2.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 14:38:27',7200,'2014-07-14 12:38:27',NULL,'[openstack-dev] [Ironic] Nominating David Shrewsbury to\n ironic-core','+1 \n\nOn Fri, 2014-07-11 at 15:50 -0700, Devananda van der Veen wrote:\n> Hi all!\n> \n> \n> While David (Shrews) only began working on Ironic in earnest four\n> months ago, he has been working on some of the tougher problems with\n> our Tempest coverage and the Nova<->Ironic interactions. He\'s also\n> become quite active in reviews and discussions on IRC, and\n> demonstrated a good understanding of the challenges facing Ironic\n> today. I believe he\'ll also make a great addition to the core team.\n> \n> \n> Below are his stats for the last 90 days.\n> \n> \n> Cheers,\n> Devananda\n> \n> \n> +--------------------------+---------------------------------------+----------------+\n> |         Reviewer         | Reviews   -2  -1  +1  +2  +A    +/- % |\n> Disagreements* |\n> +--------------------------+---------------------------------------+----------------+\n> \n> \n> 30\n> |         dshrews          |      47    0  11  36   0   0    76.6% |\n>    7 ( 14.9%)  |\n> \n> \n> \n> 60\n> |         dshrews          |      91    0  14  77   0   0    84.6% |\n> 15 ( 16.5%)  |\n> \n> \n> 90\n> |         dshrews          |     121    0  21 100   0   0    82.6% |\n> 16 ( 13.2%)  |\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEoqVp5U4Cs6NGMU=D7mtwjDYF8iVLH1jmcBc1NatOctnQ@mail.gmail.com>',NULL),('<1405346214.2395.3.camel@dabdike.int.hansenpartnership.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 06:56:54',-25200,'2014-07-14 13:56:54',NULL,'[openstack-dev] [Containers][Nova] Containers Team Mid-Cycle\n Meetup to join Nova Meetup','On Fri, 2014-07-11 at 22:31 +0000, Adrian Otto wrote:\n> CORRECTION: This event happens July 28-31. Sorry for any confusion!\n> Corrected Announcement:\n\nI\'m afraid all the Parallels guys (including me) will be in Moscow on\nthese dates for an already booked company meet up.\n\nJames\n\n\n\n\n','<A04351BC-2F3C-44B9-85C6-A5BB705A17B0@rackspace.com>',NULL),('<1405353677.4644.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 11:01:17',-18000,'2014-07-14 16:01:17',NULL,'[openstack-dev] [nova][all] Old review expiration','On Sat, 2014-07-12 at 12:46 -0400, Jay Pipes wrote:\n> > Given that we have so many old reviews hanging around on nova (and\n> > probably other projects), should we consider setting something like that\n> > back up?  With nova, at least, the vast majority of them can\'t possibly\n> > merge because they\'re so old, so we need to at least have something to\n> > remind the developer that they need to rebase?and if they\'ve forgotten\n> > the review or don\'t care about it anymore, we should either have it\n> > taken over or get the review abandoned.\n> \n> I didn\'t like the impersonal nature of the auto-expire thing, frankly. I \n> prefer the current situation where deliberate action is needed, even if \n> that means a little more work for the core review team.\n\nHmmm?I can see that, but it seems like there\'s very little deliberate\naction going on here :)  It\'s possible that reviewers are just not aware\nyet that auto-expire doesn\'t exist anymore and deliberate action is\nnecessary?\n\n> > The other concern I have is the several reviews that no core dev looked\n> > at in an entire month, but I have no solutions to suggest there,\n> > unfortunately :(\n> \n> Patches of your own or patches of other folks?\n\nPatches of other folks.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53C16649.6070407@gmail.com>',NULL),('<1405402005.70768.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 13:26:45',28800,'2014-07-15 05:26:45',NULL,'[openstack-dev] [Tuskar] Not able to set up the stack','Hi,\n\nI have been trying to set up TripleO. To do that, i first installed\nironic with devstack. So, I have three baremetal node. Then I went\non to install tuskar and tuskar-ui using their respective installation\nguides i.e.?https://github.com/openstack/tuskar/blob/master/doc/source/INSTALL.rst\nand?http://tuskar-ui.readthedocs.org/en/latest/install.html.\n\nNow, I am running tuskar-ui, I get the error as : The stack (overcloud) could\nnot be found.\n\nAny ideas about how to resolve this?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/b01b595e/attachment.html>\n\n',NULL,NULL),('<1405406858.4182.8.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 07:47:38',3600,'2014-07-15 06:47:38',NULL,'[openstack-dev] [all] Treating notifications as a contract','On Fri, 2014-07-11 at 10:04 +0100, Chris Dent wrote:\n> On Fri, 11 Jul 2014, Lucas Alvares Gomes wrote:\n> \n> > The data format that Ironic will send was part of the spec proposed\n> > and could have been reviewed. I think there\'s still time to change it\n> > tho, if you have a better format talk to Haomeng which is the guys\n> > responsible for that work in Ironic and see if he can change it (We\n> > can put up a following patch to fix the spec with the new format as\n> > well) . But we need to do this ASAP because we want to get it landed\n> > in Ironic soon.\n> \n> It was only after doing the work that I realized how it might be an\n> example for the sake of this discussion. As the architecure of\n> Ceilometer currently exist there still needs to be some measure of\n> custom code, even if the notifications are as I described them.\n> \n> However, if we want to take this opportunity to move some of the\n> smarts from Ceilomer into the Ironic code then the paste that I created\n> might be a guide to make it possible:\n> \n>     http://paste.openstack.org/show/86071/\n\nSo you\'re proposing that all payloads should contain something like:\n\n        \'events\': [\n            # one or more dicts with something like\n            {\n                # some kind of identifier for the type of event\n                \'class\': \'hardware.ipmi.temperature\',\n                \'type\': \'#thing that indicates threshold, discrete, cumulative\',\n                \'id\': \'DIMM GH VR Temp (0x3b)\',\n                \'value\': \'26\',\n                \'unit\': \'C\',\n                \'extra\': {\n                    ...\n                }\n             }\n\ni.e. a class, type, id, value, unit and a space to put additional metadata.\n\nOn the subject of \"notifications as a contract\", calling the additional\nmetadata field \'extra\' suggests to me that there are no stability\npromises being made about those fields. Was that intentional?\n\n> However on that however, if there\'s some chance that a large change could\n> happen, it might be better to wait, I don\'t know.\n\nUnlikely that a larger change will be made in Juno - take small window\nof opportunity to rationalize Ironic\'s payload IMHO.\n\nMark.\n\n\n\n\n\n','<alpine.OSX.2.00.1407111001280.86373@crank.home>',NULL),('<1405408510.4182.18.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 08:15:10',3600,'2014-07-15 07:15:10',NULL,'[openstack-dev] [all] Treating notifications as a contract','On Thu, 2014-07-10 at 16:21 -0400, Eoghan Glynn wrote:\n> > > One of the issues that has been raised in the recent discussions with\n> > > the QA team about branchless Tempest relates to some legacy defects\n> > > in the OpenStack notification system.\n> > \n> > Got links to specifics? I thought the consensus was that there was a\n> > contract here which we need to maintain, so I\'d be curious where that\n> > broke down.\n> \n> Well I could go digging in the LP fossil-record for specific bugs, but\n> it\'s late, so for now I\'ll simply appeal to anecdata and tribal memory\n> of ceilometer being broken by notification changes on the nova side.  \n> \n> > Versioning and ability to newer contract versions would be good too, but\n> > in the absence of such things we should maintain backwards compat.\n> \n> Yes, I think that was the aspiration, but not always backed up by practice\n> in reality.\n\nThe reason I ask about specifics is to figure out which is more\nimportant - versioned payloads, or automated testing of payload format.\n\ni.e. have we been accidentally or purposefully changing the format? If\nthe latter, would the change have warranted a new incompatible version\nof the payload format?\n\nMark.\n\n\n\n','<1154130905.9238263.1405023709216.JavaMail.zimbra@redhat.com>',NULL),('<1405415289.4182.33.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 10:08:09',3600,'2014-07-15 09:08:09',NULL,'[openstack-dev] REST API access to configuration options','On Tue, 2014-07-15 at 08:54 +0100, Henry Nash wrote:\n> HI\n> \n> As the number of configuration options increases and OpenStack\n> installations become more complex, the chances of incorrect\n> configuration increases. There is no better way of enabling cloud\n> providers to be able to check the configuration state of an OpenStack\n> service than providing a direct REST API that allows the current\n> running values to be inspected. Having an API to provide this\n> information becomes increasingly important for dev/ops style\n> operation.\n> \n> As part of Keystone we are considering adding such an ability (see:\n> https://review.openstack.org/#/c/106558/).  However, since this is the\n> sort of thing that might be relevant to and/or affect other projects,\n> I wanted to get views from the wider dev audience.  \n> \n> Any such change obviously has to take security in mind - and as the\n> spec says, just like when we log config options, any options marked as\n> secret will be obfuscated.  In addition, the API will be protected by\n> the normal policy mechanism and is likely in most installations to be\n> left as \"admin required\".  And of course, since it is an extension, if\n> a particular installation does not want to use it, they don\'t need to\n> load it.\n> \n> Do people think this is a good idea?  Useful in other projects?\n> Concerned about the risks?\n\nI would have thought operators would be comfortable gleaning this\ninformation from the log files?\n\nAlso, this is going to tell you how the API service you connected to was\nconfigured. Where there are multiple API servers, what about the others?\nHow do operators verify all of the API servers behind a load balancer\nwith this?\n\nAnd in the case of something like Nova, what about the many other nodes\nbehind the API server?\n\nMark.\n\n\n\n','<D7333FA5-581B-46A6-B833-446F0228EC06@linux.vnet.ibm.com>',NULL),('<1405428679.4182.68.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-07-15 13:51:19',3600,'2014-07-15 12:51:19',NULL,'[openstack-tc] [OpenStack-TC] Block Storage abstractions in\n Cinder','Hi John,\n\nTop-posting because I don\'t really have specific answers to any of your\nquestions, but I thought I\'d try and summarize how I\'d go about thinking\nit through ...\n\nWhat Cinder provides from a user perspective:\n\n  - volumes\n  - attaching or booting from volumes via Nova\n  - snapshots\n  - backups\n  - different storage tiers - i.e. volume types, qos specs\n  - quotas/limits\n\nIf the backing storage technology could sanely be used to provide those\nfeatures then, conceptually at least, a Cinder driver for that\ntechnology makes some sense.\n\n(An example of not sane IMO would be a storage driver that creates\nvolumes that can only be attached to VMs running on a single compute\nnode and users of the Nova API would need to jump through hopes to deal\nwith this restriction)\n\nI don\'t have a problem with vendors wanting to add drivers for their\ntechnologies. I don\'t like to see us assume that this is purely about\nmarketing. I\'d rather assume good faith on the part of contributing\nvendors - they see value for real-life users in the combination of\nOpenStack and their technology, and they\'re trying to bring that value\nto as many people as possible. As much of an open-source advocate as I\nam, I also wouldn\'t differentiate between drivers for proprietary or\nopen-source technologies.\n\nI also don\'t like to assume that contributions to drivers only come from\nvendors. That may be mostly true, but if we can build mini, productive,\nhealthy communities around only a handful of drivers then it will be\nworth our while to be careful with our language by calling them driver\ncontributors, developers, maintainers, etc.\n\nHaving drivers in-tree is not so much about \"quality\" as it is about\nenabling and encouraging collaboration between everyone interested in\nworking on the driver, but also those working on the driver and those\nworking on the core of the project. For example, if a driver was low\nquality but keeping it in-tree was going to enable that collaboration,\nthen I\'d be more in favor of marking it as \"experimental\" or\n\"incomplete\" or similar rather than kicking it out of the tree.\n\nNow, the specific situation you describe sounds pretty crappy - a\nproposal to include a whole bunch of infrastructure in a driver that\ncould be useful to other drivers. That rather than figure out how to\nevolve the core of Cinder to support the scheduling requirements of that\nstorage architecture, the driver developers chose to build their own\nstuff. We absolutely do not need to encourage that, but the flip-side is\nthat we also need to be open to those driver developers evolving the\ncore to support that use case.\n\nWhat I really see (and dig) across the board is this - where once, when\nour review queues were under control, we would have given a giant big\nhug to anyone wanting to contribute to a driver, we are now massively\nover-burdened with contributions of varying quality and our ability to\nnurture each contributor (and empathize with their goals) has almost\nvanished.\n\nThat\'s totally understandable, but IMO we should be clear-headed about\nwhat we want to achieve in discussions like this - getting these pesky,\nclueless, leaching vendors to bugger off somewhere else or evolving our\ncommunity and processes to cope with, and nurture, the massive interest\nwe\'re seeing.\n\nHTH,\nMark.\n\nOn Mon, 2014-07-14 at 10:03 -0600, John Griffith wrote:\n> Hello TC Members,\n> \n> \n> Some of you have maybe heard my opinions and position on the so called\n> \"Software Defined Storage\" trend in Cinder.  For those that aren\'t\n> familiar here\'s the summary:\n> \n> \n> Basicly the first proposal from EMC came several months back where\n> they submitted a \"Driver\" that was an abstraction layer for multiple\n> EMC and non-EMC storage devices [1].  The goal being to provide a\n> Cinder Volume-Driver that implements an entire new abstraction and\n> scheduling layer for heterogenous devices that are connected behind an\n> EMC VIPR node.  The first problem I had with this was patch-set 1 was\n> 28924 line code dump of a \"driver\".  The second problem was the fact\n> that it duplicates scheduler, API abstraction etc.\n> \n> \n> My bigger concern is that every vendor and now some other Open Source\n> groups are also seeing this as a great marketing tool and potential\n> for driving some new sales in their company.  There have been\n> additional proposals for similar abstractions in the Juno cycle (and\n> notification from at least 2 other vendors that they\'ll be submitting\n> something similar).  For those that support a \"software based storage\n> on top of commodity servers or JBODS\" it seems reasonable/good to have\n> a Cinder driver.  The problem is you can\'t have just that piece of\n> their product, you get all or nothing.\n> \n> \n> The concept itself (and the implementation) in some of these is pretty\n> cool and I see real value in them.  What I don\'t see as beneficial\n> however is them being in the Cinder Source code.  I don\'t think that\n> support and overhead of maintaining entire duplications of the Cinder\n> services is necessarily a great idea.  To be honest, I\'ve spent the\n> last year trying to figure out a reasonable way to have ZERO 3\'rd\n> party drivers in Cinder, and still provide some way of providing\n> quality.\n> \n> \n> Anyway, I\'d like to get some feedback from the TC on all of this.\n>  Whether it be an official agenda item for an upcoming meeting, or at\n> the very least feedback to this email.  In my opinion this is very\n> much a TC item and is exactly the sort of thing that the TC should be\n> interested in.  I can certainly make decisions on my own based on\n> feedback from the rest of the Cinder community and my own personal\n> view, however I believe this has a broader impact. \n> \n> \n> Most of these products also extend at some point to direct\n> integrations as Object Stores, Image Repositories, Manilla Share\n> Plugins and direct integrations in to Nova.  I think it\'s something\n> that needs to be well thought out and the long terms impacts on the\n> OpenStack projects should be considered.\n> \n> \n> Thanks,\n> John\n> \n> \n> \n> \n> [1]: https://review.openstack.org/#/c/74158/\n> \n> \n> Additional/Similar proposals:\n> https://review.openstack.org/#/c/106742/\n> \n> https://review.openstack.org/#/c/101688/\n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n\n\n','<CA+qL3LX3DZ9S1uXQtobz-=v7F-zjgWGQWr7HBOER9ONc_B6d_w@mail.gmail.com>',NULL),('<1405428831.82326.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 20:53:51',28800,'2014-07-15 12:53:51',NULL,'[openstack-dev] [TripleO] devtest error in netwrok','Hi all,\n\nI have been trying to set up tripleO on a ubuntu 12.04 virtual machine.\nNow i am following this guide:?http://docs.openstack.org/developer/tripleo-incubator/devtest.html\n\nNow, when I run devtest_testenv.sh command, I get the following error:\n\nerror: internal error Network is already in use by interface eth0\n\nAny idea how to resolve this?\n?\nThanks,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/83464231/attachment.html>\n\n',NULL,NULL),('<1405434304.4182.82.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 15:25:04',3600,'2014-07-15 14:25:04',NULL,'[openstack-dev] REST API access to configuration options','On Tue, 2014-07-15 at 13:00 +0100, Henry Nash wrote:\n> Mark,\n> \n> \n> Thanks for your comments (as well as remarks on the WIP code-review).\n> \n> \n> So clearly gathering and analysing log files is an alternative\n> approach, perhaps not as immediate as an API call.  In general, I\n> believe that the more capability we provide via easy-to-consume APIs\n> (with appropriate permissions) the more effective (and innovative)\n> ways of management of OpenStack we will achieve (easier to build\n> automated management systems).\n\nI\'m skeptical - like Joe says, this is a general problem and management\ntooling will have generic ways of tackling this without using a REST\nAPI.\n\n>   In terms of multi API servers, obviously each server would respond\n> to the API with the values it has set, so operators could check any or\n> all of the servers....and this actually becomes more important as\n> people distribute config files around to the various servers (since\n> more chance of something getting out of sync).\n\nThe fact that it only deals with API servers, and that you need to\nbypass the load balancer in order to iterate over all API servers, makes\nthis of very limited use IMHO.\n\nThanks,\nMark.\n\n\n\n\n','<A0C90B0E-ECB0-4C51-BA7C-F4826CA906C8@linux.vnet.ibm.com>',NULL),('<1405448866-sup-810@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 18:29:24',0,'2014-07-15 18:29:24',NULL,'[openstack-dev] [Ironic] [Horizon] [UX] Wireframes for Node\n	Management - Juno','Excerpts from Jaromir Coufal\'s message of 2014-07-15 07:15:12 +0000:\n> On 2014/10/07 22:19, Gregory Haynes wrote:\n> > Excerpts from Jaromir Coufal\'s message of 2014-07-09 07:51:56 +0000:\n> >> Hey folks,\n> >>\n> >> after few rounds of reviews and feedbacks, I am sending wireframes,\n> >> which are ready for implementation in Juno:\n> >>\n> >> http://people.redhat.com/~jcoufal/openstack/juno/2014-07-09_nodes-ui_juno.pdf\n> >>\n> >> Let me know in case of any questions.\n> >>\n> >\n> > Looks awesome!\n> >\n> > I may be way off base here (not super familiar with Tuskar) but what\n> > about bulk importing of nodes? This is basically the only way devtest\n> > makes use of nodes nowdays, so it might be nice to allow people to use\n> > the same data file in both places (nodes.json blob).\n> >\n> > -Greg\n> \n> Hi Greg,\n> \n> thanks a lot for the feedback. We planned to provide a bulk import of \n> nodes as well. First we need to provide the basic functionality. I hope \n> we also manage to add import function in Juno but it depends on how the \n> progress of implementation goes. The challenge here is that I am not \n> aware of any standardized way for the data structure of the imported \n> file (do you have any suggestions here?).\n> \n> \n\nWe currently accept a nodes.json blob in the following format:\n\n[{\n    \"pm_password\": \"foo\",\n    \"mac\": [\"78:e7:d1:24:99:a5\"],\n    \"pm_addr\": \"10.22.51.66\",\n    \"pm_type\": \"pxe_ipmitool\",\n    \"memory\": 98304,\n    \"disk\": 1600,\n    \"arch\": \"amd64\",\n    \"cpu\": 24,\n    \"pm_user\": \"Administrator\"\n},\n...\n]\n\nSo this might be a good starting point?\n\n-Greg\n\n\n','<53C4D500.9050405@redhat.com>',NULL),('<1405464732.110.1356134807488.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-22 00:06:47',0,'2012-12-22 00:06:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #82','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/82/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.96 secs:\n    2.85    Kc11TestCase.test_admin_requires_adminness\n    2.36    KcEssex3TestCase.test_admin_requires_adminness\n    2.15    KcMasterTestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 59.006s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.td0O7pwtRB\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/82\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/82/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1962425561.88.1356048529231.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1405479457.18871.9.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 21:57:37',-18000,'2014-07-16 02:57:37',NULL,'[openstack-dev] [all][specs] Please stop doing specs for any\n changes in projects','John,\n\nSo you have said a few times that the specs are a learning process.\nWhat do you feel with have learned thus far using specs?  I think you\nhad the hope that it would help organize targeting blueprints and not\nmissing things for a release.  Do you feel that is working?\n\nI would like to hear more about how you feel this is working.\n\nPersonally, initially, having specs made sense given that they are a\nbetter way to spark discussion around a design change.  They were\nworking well early in the release for that purpose.\n\nNow, however, they have become a point of confusion.  There is the\nquestion of \"when is just a BP sufficient\" versus when is neither\nrequired.\n\nI think this is part of the learning process.  Just worth having\ndiscussion so we know for the next round what is needed when.\n\nJay\n\nOn Sun, 2014-07-13 at 16:31 -0600, John Griffith wrote:\n> \n> \n> \n> \n> On Sun, Jul 13, 2014 at 8:01 AM, Dolph Mathews\n> <dolph.mathews at gmail.com> wrote:\n>         \n>         On Wed, Jul 9, 2014 at 1:54 PM, Jay Bryant\n>         <jsbryant at electronicjungle.net> wrote:\n>                 I had been under the impression that all BPs we going\n>                 to require a spec.  I, however,  was made are in\n>                 today\'s cinder meeting that we are only requiring\n>                 specs for changes that change the user\'s interaction\n>                 with the system or are a large change that touches the\n>                 broader cinder code base.\n>                 \n>         That\'s generally where we use blueprints in Keystone, anyway.\n>         If the change has no impact on end users, deployers or other\n>         projects, then it doesn\'t need a spec/blueprint. For example,\n>         a refactor only affects developers of Keystone, so I\'d argue\n>         that blueprints are unnecessary.\n>         \n>         \n>         \n>         The premise of a \"large change that touches the broader ...\n>         code base\" requiring a blueprint is flawed though - we don\'t\n>         want to review large changes anyway ;)\n> \n> \n> ?Just have to say I really like this last point... also even though\n> I\'m the one who made that statement the problem with it is that it\'s\n> rather subjective.  \n> \n> \n> My position is and continues to be that specs are a learning process,\n> we\'re hammering it out and these conversations on the ML are helpful.?\n>                 This seemsto make sense to me.  The user\'s commit\n>                 message and unit tests should show the thought of the\n>                 changes impact. \n>                 \n>                 Jay\n>                 \n>                 On Jul 9, 2014 7:57 AM, \"Dugger, Donald D\"\n>                 <donald.d.dugger at intel.com> wrote:\n>                         Much as I dislike the overhead and the extra\n>                         latency involved (now you need to have a\n>                         review cycle for the spec plus the review\n>                         cycle for the patch itself) I agreed with the\n>                         `small features require small specs?.  The\n>                         problem is that even a small change can have a\n>                         big impact.  Forcing people to create a spec\n>                         even for small features means that it?s very\n>                         clear that the implications of the feature\n>                         have been thought about and addressed.\n>                         \n>                          \n>                         \n>                         Note that there is a similar issue with bugs.\n>                          I would expect that a patch to fix a bug\n>                         would have to have a corresponding bug report.\n>                         Just accepting patches with no known\n>                         justification seems like the wrong way to go.\n>                         \n>                          \n>                         \n>                         --\n>                         \n>                         Don Dugger\n>                         \n>                         \"Censeo Toto nos in Kansa esse decisse.\" - D.\n>                         Gale\n>                         \n>                         Ph: 303/443-3786\n>                         \n>                          \n>                         \n>                         From: Dolph Mathews\n>                         [mailto:dolph.mathews at gmail.com] \n>                         Sent: Tuesday, July 1, 2014 11:02 AM\n>                         To: OpenStack Development Mailing List (not\n>                         for usage questions)\n>                         Subject: Re: [openstack-dev] [all][specs]\n>                         Please stop doing specs for any changes in\n>                         projects\n>                         \n>                          \n>                         \n>                         The argument has been made in the past that\n>                         small features will require correspondingly\n>                         small specs. If there\'s a counter-argument to\n>                         this example (a \"small\" feature requiring a\n>                         relatively large amount of spec effort), I\'d\n>                         love to have links to both the spec and the\n>                         resulting implementation so we can discuss\n>                         exactly why the spec was an unnecessary\n>                         additional effort.\n>                         \n>                         On Tue, Jul 1, 2014 at 10:30 AM, Jason\n>                         Dunsmore <jason.dunsmore at rackspace.com> wrote:\n>                         \n>                                 On Mon, Jun 30 2014, Joshua Harlow\n>                                 wrote:\n>                                 \n>                                 > There is a balance here that needs\n>                                 to be worked out and I\'ve seen\n>                                 > specs start to turn into\n>                                 requirements for every single patch\n>                                 (even if\n>                                 > the patch is pretty small). I hope\n>                                 we can rework the \'balance in the\n>                                 > force\' to avoid being so strict that\n>                                 every little thing requires a\n>                                 > spec. This will not end well for us\n>                                 as a community.\n>                                 >\n>                                 > How have others thought the spec\n>                                 process has worked out so far? To\n>                                 > much overhead, to little??\n>                                 >\n>                                 > I personally am of the opinion that\n>                                 specs should be used for large\n>                                 > topics (defining large is of course\n>                                 arbitrary); and I hope we find the\n>                                 > right balance to avoid scaring\n>                                 everyone away from working with\n>                                 > openstack. Maybe all of this is part\n>                                 of openstack maturing, I\'m not\n>                                 > sure, but it\'d be great if we could\n>                                 have some guidelines around when\n>                                 > is a spec needed and when isn\'t it\n>                                 and take it into consideration when\n>                                 > requesting a spec that the person\n>                                 you have requested may get\n>                                 > frustrated and just leave the\n>                                 community (and we must not have this\n>                                 > happen) if you ask for it without\n>                                 explaining why and how clearly.\n>                                 \n>                                 +1 I think specs are too much overhead\n>                                 for small features.  A set of\n>                                 guidelines about when specs are needed\n>                                 would be sufficient.  Leave the\n>                                 option about when to submit a design\n>                                 vs. when to submit code to the\n>                                 contributor.\n>                                 \n>                                 Jason\n>                                 \n>                                 \n>                                 _______________________________________________\n>                                 OpenStack-dev mailing list\n>                                 OpenStack-dev at lists.openstack.org\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                                 \n>                                 \n>                          \n>                         \n>                         \n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                         \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n\n\n\n\n','<CA+qL3LWa1nGPo_qd1bwCUkrETYap6pg06pPYchtx4qWdTRJTdA@mail.gmail.com>',NULL),('<1405523299.4182.143.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 16:08:19',3600,'2014-07-16 15:08:19',NULL,'[openstack-dev] [nova] fair standards for all hypervisor drivers','On Wed, 2014-07-16 at 16:15 +0200, Sean Dague wrote:\n..\n> Based on these experiences, libvirt version differences seem to be as\n> substantial as major hypervisor differences. There is a proposal here -\n> https://review.openstack.org/#/c/103923/ to hold newer versions of\n> libvirt to the same standard we hold xen, vmware, hyperv, docker,\n> ironic, etc.\n\nThat\'s a bit of a mis-characterization - in terms of functional test\ncoverage, the libvirt driver is the bar that all the other drivers\nstruggle to meet.\n\nAnd I doubt any of us pay too close attention to the feature coverage\nthat the 3rd party CI test jobs have.\n\n> I\'m somewhat concerned that the -2 pile on in this review is a double\n> standard of libvirt features, and features exploiting really new\n> upstream features. I feel like a lot of the language being used here\n> about the burden of doing this testing is exactly the same as was\n> presented by the docker team before their driver was removed, which was\n> ignored by the Nova team at the time.\n\nPersonally, I wasn\'t very comfortable with the docker driver move. It\ncertainly gave an outward impression that we\'re an unfriendly community.\nThe mitigating factor was that a lot of friendly, collaborative,\ncoaching work went on in the background for months. Expectations were\ncommunicated well in advance.\n\nKicking the docker driver out of the tree has resulted in an uptick in\nthe amount of work happening on it, but I suspect most people involved\nhave a bad taste in their mouths. I guess there\'s incentives at play\nwhich mean they\'ll continue plugging away at it, but those incentives\naren\'t always at play.\n\n> It was the concern by the freebsd\n> team, which was also ignored and they were told to go land libvirt\n> patches instead.\n> \n> I\'m ok with us as a project changing our mind and deciding that the test\n> bar needs to be taken down a notch or two because it\'s too burdensome to\n> contributors and vendors, but if we are doing that, we need to do it for\n> everyone. A lot of other organizations have put a ton of time and energy\n> into this, and are carrying a maintenance cost of running these systems\n> to get results back in a timely basis.\n\nI don\'t agree that we need to apply the same rules equally to everyone.\n\nAt least part of the reasoning behind the emphasis on 3rd party CI\ntesting was that projects (Neutron in particular) were being overwhelmed\nby contributions to drivers from developers who never contributed in any\nway to the core. The corollary of that is the contributors who do\ncontribute to the core should be given a bit more leeway in return.\n\nThere\'s a natural building of trust and element of human relationships\nhere. As a reviewer, you learn to trust contributors with a good track\nrecord and perhaps prioritize contributions from them.\n\n> As we seem deadlocked in the review, I think the mailing list is\n> probably a better place for this.\n> \n> If we want to reduce the standards for libvirt we should reconsider\n> what\'s being asked of 3rd party CI teams, and things like the docker\n> driver, as well as the A, B, C driver classification. Because clearly\n> libvirt 1.2.5+ isn\'t actually class A supported.\n\nNo, there are features or code paths of the libvirt 1.2.5+ driver that\naren\'t as well tested as the \"class A\" designation implies. And we have\na proposal to make sure these aren\'t used by default:\n\n  https://review.openstack.org/107119\n\ni.e. to stray off the \"class A\" path, an operator has to opt into it by\nchanging a configuration option that explains they will be enabling code\npaths which aren\'t yet tested upstream.\n\nThese features have value to some people now, they don\'t risk regressing\nthe \"class A\" driver and there\'s a clear path to them being elevated to\n\"class A\" in time. We should value these contributions and nurture these\ncontributors.\n\nAppending some of my comments from the review below. The tl;dr is that I\nthink we\'re losing sight of the importance of welcoming and nurturing\ncontributors, and valuing whatever contributions they can make. That\nterrifies me. \n\nMark.\n\n---\n\nCompared to other open source projects, we have done an awesome job in\nOpenStack of having good functional test coverage. Arguably, given the\ncomplexity of the system, we couldn\'t have got this far without it. I\ncan take zero credit for any of it.\n\nHowever, not everything is tested now, nor is the tests we have\nfoolproof. When you consider the number of configuration options we\nhave, the supported distros, the ranges of library versions we claim to\nsupport, etc., etc. I don\'t think we can ever get to an \"everything is\ntested\" point.\n\nIn the absence of that, I think we should aim to be more clear what *is*\ntested. The config option I suggest does that, which is a big part of\nits merit IMHO.\n\nWe\'ve had some success with the \"be nasty enough to driver contributors\nand they\'ll do what we want\" approach so far, but IMHO that was an\nexceptional approach for an exceptional situation - drivers that were\ncompletely broken, and driver developers who didn\'t contribute to the\ncore project or, worse, didn\'t maintain their drivers adequately.\n\nNot every contributor can be bullied like this. And even where it\nsucceeds, I don\'t much love the perception it gives the project.\n\nIn this case, the effect I could imagine us having would be that rather\nthan us successfully bullying someone into setting up \"latest libvirt\nCI\", we drive development of features requiring newer libvirt into a\nseparate tree.\n\nThere would even be a perfectly defensible rationale for doing this -\n\"we\'re building features that can\'t go upstream until a newer libvirt\nshows up there\". If these are NFV features, there\'d likely be a bunch of\ndownstreams that ship it. And then when the newer libvirt shows up, all\nthe features requiring it get proposed together as fully-baked patch\nsets? No thank you.\n\nThe desire to have the best possible test coverage is great. The desire\nto document our policies around this stuff is great. But let\'s not\nforget that we\'re talking about contributors that need to be nurtured\nand contributions that should be valued.\n\n\n\n','<53C6890C.70807@dague.net>',NULL),('<1405529451.30395.11.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 12:50:51',-14400,'2014-07-16 16:50:51',NULL,'[openstack-dev] [TripleO] Cinder coverage','Hi TripleO!\n\nIt would appear that we have no coverage in devtest which ensures that\nCinder consistently works in the overcloud. As such the TripleO Cinder\nelements are often broken (as of today I can\'t fully use lio or tgt w/\nupstream TripleO elements).\n\nHow do people feel about swapping out our single \'nova boot\' command to\nboot from a volume. Something like this:\n\n https://review.openstack.org/#/c/107437\n\nThere is a bit of tradeoff here in that the conversion will take a bit\nof time (qemu-img has to run). Also our boot code path won\'t be exactly\nthe same as booting from an image.\n\nLong term we want to run Tempest but due to resource constraints we\ncan\'t do that today. Until then this sort of deep systems test (running\na command that exercises more code) might serve us well and give us the\nCinder coverage we need.\n\nThoughts?\n\nI would also like to split the test configurations so that we use\ncinder-lio for some (cinder-tgt is our existing default in devtest).\n\nDan\n\n\n\n',NULL,NULL),('<1405533501.30395.29.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 13:58:21',-14400,'2014-07-16 17:58:21',NULL,'[openstack-dev] [TripleO] os-net-config','Hi TripleO!\n\nI wanted to get the word out on progress with a new os-net-config tool\nfor TripleO. The spec (not yet approved) lives here:\n\nhttps://review.openstack.org/#/c/97859/\n\nWe\'ve also got a working implementation here:\n\nhttps://github.com/dprince/os-net-config\n\nYou can see WIP example of how it wires in here (more work to do on this\nto fully support parity):\n\nhttps://review.openstack.org/#/c/104054/1/elements/network-utils/bin/ensure-bridge,cm\n\nThe end goal is that we will be able to more flexibly control our host\nlevel network settings in TripleO. Once it is fully integrated\nos-net-config would provide a mechanism to drive more flexible\nconfigurations (multiple bridges, bonding, etc.) via Heat metadata.\n\nWe are already in dire need of this sort of thing today because we can\'t\nsuccessfully deploy our CI overclouds without making manual changes to\nour images (this is because we need 2 bridges and our heat templates\nonly support 1).\n\nDan\n\n\n\n',NULL,NULL),('<1405543185-sup-2491@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 13:43:45',-25200,'2014-07-16 20:43:45',NULL,'[openstack-dev] [heat] health maintenance in autoscaling groups','Excerpts from Mike Spreitzer\'s message of 2014-07-16 10:50:42 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 07/02/2014 01:54:49 PM:\n> \n> > Excerpts from Qiming Teng\'s message of 2014-07-02 00:02:14 -0700:\n> > > Just some random thoughts below ...\n> > > \n> > > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:\n> > > > In AWS, an autoscaling group includes health maintenance \n> > functionality --- \n> > > > both an ability to detect basic forms of failures and an abilityto \n> react \n> > > > properly to failures detected by itself or by a load balancer.  What \n> is \n> > > > the thinking about how to get this functionality in OpenStack? Since \n> \n> > > \n> > > We are prototyping a solution to this problem at IBM Research - China\n> > > lab.  The idea is to leverage oslo.messaging and ceilometer events for\n> > > instance (possibly other resource such as port, securitygroup ...)\n> > > failure detection and handling.\n> > > \n> > \n> > Hm.. perhaps you should be contributing some reviews here as you may\n> > have some real insight:\n> > \n> > https://review.openstack.org/#/c/100012/\n> > \n> > This sounds a lot like what we\'re working on for continuous convergence.\n> \n> I noticed that health checking in AWS goes beyond convergence.  In AWS an \n> ELB can be configured with a URL to ping, for application-level health \n> checking.  And an ASG can simply be *told* the health of a member by a \n> user\'s own external health system.  I think we should have analogous \n> functionality in OpenStack.  Does that make sense to you?  If so, do you \n> have any opinion on the right way to integrate, so that we do not have \n> three completely independent health maintenance systems?\n\nThe check url is already a part of Neutron LBaaS IIRC. What may not be\na part is notifications for when all members are reporting down (which\nmight be something to trigger scale-up).\n\nIf we don\'t have push checks in our auto scaling implementation then we\ndon\'t have a proper auto scaling implementation.\n\n\n','<OFAAA8ACCE.57D4574D-ON85257D17.0061C309-85257D17.00620656@us.ibm.com>',NULL),('<1405546861-sup-7673@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-16 14:42:49',-25200,'2014-07-16 21:42:49',NULL,'[openstack-dev] [TripleO] Cinder coverage','Excerpts from Dan Prince\'s message of 2014-07-16 09:50:51 -0700:\n> Hi TripleO!\n> \n> It would appear that we have no coverage in devtest which ensures that\n> Cinder consistently works in the overcloud. As such the TripleO Cinder\n> elements are often broken (as of today I can\'t fully use lio or tgt w/\n> upstream TripleO elements).\n> \n> How do people feel about swapping out our single \'nova boot\' command to\n> boot from a volume. Something like this:\n> \n>  https://review.openstack.org/#/c/107437\n> \n> There is a bit of tradeoff here in that the conversion will take a bit\n> of time (qemu-img has to run). Also our boot code path won\'t be exactly\n> the same as booting from an image.\n> \n> Long term we want to run Tempest but due to resource constraints we\n> can\'t do that today. Until then this sort of deep systems test (running\n> a command that exercises more code) might serve us well and give us the\n> Cinder coverage we need.\n> \n> Thoughts?\n> \n\nTempest is a stretch goal. Given our long test times, until we get them\ndown, I don\'t know if we can even flirt with tempest other than the most\nbasic smoke tests.\n\nSo yes, I like the idea of having our one smoke test be as wide as\npossible.\n\nLater on we can add Heat coverage by putting said smoke test into a\nHeat template.\n\n\n','<1405529451.30395.11.camel@dovetail.localdomain>',NULL),('<1405582714752.65243@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-17 07:32:05',0,'2014-07-17 07:32:05',NULL,'[Openstack] unable to start openstack service :\n openstack-nova-api','\nHi Dhanesh,\n\n\nopenstack-nova-api and openstack-nova-metadata-api both run on the same port so you are getting \"Address already in use\" error.\n\nTry stopping \"openstack-nova-metadata-api\" service and run \"openstack-nova-api\".\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: dhanesh1212121212 <dhanesh1212 at gmail.com>\nSent: Thursday, July 17, 2014 12:19 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] unable to start openstack service : openstack-nova-api\n\nHi Team,\n\n\nIn compute node iam not able to start \"openstack-nova-api\".\n\nIts showing error:\n\n2014-07-17 12:03:07.908 3313 ERROR nova.wsgi [-] Could not bind to 0.0.0.0:8775<http://0.0.0.0:8775>\n2014-07-17 12:03:07.910 3313 CRITICAL nova [-] error: [Errno 98] Address already in use\n\n\n\nrest all services are showing status running.\n\n\n[root at compute3 nova]# /etc/init.d/openstack-nova-api status\nopenstack-nova-api dead but pid file exists\n\n\n[root at compute3 nova]# /etc/init.d/openstack-nova-metadata-api status\nopenstack-nova-metadata-api (pid  3222) is running...\n[root at compute3 nova]# /etc/init.d/openstack-nova-network status\nopenstack-nova-network (pid  3247) is running...\n[root at compute3 nova]# /etc/init.d/openstack-nova-compute status\nopenstack-nova-compute (pid  3495) is running...\n\n\nWill it effect the setup?\n\nY is it not starting?\n\n\nRegards,\nDhanesh M\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140717/d7f89e72/attachment.html>\n\n','<CAA0wu4cFJqTttSX5tS=SpQgLz58qE27pchS16iKOWvm0Khfw4A@mail.gmail.com>',NULL),('<1405599188.4182.226.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 13:13:08',3600,'2014-07-17 12:13:08',NULL,'[openstack-dev] [nova] fair standards for all hypervisor drivers','On Thu, 2014-07-17 at 09:58 +0100, Daniel P. Berrange wrote:\n> On Thu, Jul 17, 2014 at 08:46:12AM +1000, Michael Still wrote:\n> > Top posting to the original email because I want this to stand out...\n> > \n> > I\'ve added this to the agenda for the nova mid cycle meetup, I think\n> > most of the contributors to this thread will be there. So, if we can\n> > nail this down here then that\'s great, but if we think we\'d be more\n> > productive in person chatting about this then we have that option too.\n> \n> FYI, I\'m afraid I won\'t be at the mid-cycle meetup since it clashed with\n> my being on holiday. So I\'d really prefer if we keep the discussion on\n> this mailing list where everyone has a chance to participate.\n\nSame here. Pre-arranged vacation, otherwise I\'d have been there.\n\nMark.\n\n\n\n','<20140717085848.GC17498@redhat.com>',NULL),('<1405614595-sup-1450@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 09:32:04',-25200,'2014-07-17 16:32:04',NULL,'[openstack-dev] [nova] fair standards for all hypervisor drivers','Excerpts from Chris Friesen\'s message of 2014-07-16 11:38:44 -0700:\n> On 07/16/2014 11:59 AM, Monty Taylor wrote:\n> > On 07/16/2014 07:27 PM, Vishvananda Ishaya wrote:\n> \n> >> This is a really good point. As someone who has to deal with packaging\n> >> issues constantly, it is odd to me that libvirt is one of the few places\n> >> where we depend on upstream packaging. We constantly pull in new python\n> >> dependencies from pypi that are not packaged in ubuntu. If we had to\n> >> wait for packaging before merging the whole system would grind to a halt.\n> >>\n> >> I think we should be updating our libvirt version more frequently vy\n> >> installing from source or our own ppa instead of waiting for the ubuntu\n> >> team to package it.\n> >\n> > Shrinking in terror from what I\'m about to say ... but I actually agree\n> > with this, There are SEVERAL logistical issues we\'d need to sort, not\n> > the least of which involve the actual mechanics of us doing that and\n> > properly gating,etc. But I think that, like the python depends where we\n> > tell distros what version we _need_ rather than using what version they\n> > have, libvirt, qemu, ovs and maybe one or two other things are areas in\n> > which we may want or need to have a strongish opinion.\n> >\n> > I\'ll bring this up in the room tomorrow at the Infra/QA meetup, and will\n> > probably be flayed alive for it - but maybe I can put forward a\n> > straw-man proposal on how this might work.\n> \n> How would this work...would you have them uninstall the distro-provided \n> libvirt/qemu and replace them with newer ones?  (In which case what \n> happens if the version desired by OpenStack has bugs in features that \n> OpenStack doesn\'t use, but that some other software that the user wants \n> to run does use?)\n> \n> Or would you have OpenStack versions of them installed in parallel in an \n> alternate location?\n\nYes. See: docker, lxc, chroot. (Listed in descending hipsterness order).\n\n\n','<53C6C6B4.3060600@windriver.com>',NULL),('<1405615088-sup-6947@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 09:45:30',-25200,'2014-07-17 16:45:30',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','Excerpts from Michael Kerrin\'s message of 2014-07-17 07:54:26 -0700:\n> On Thursday 26 June 2014 12:20:30 Clint Byrum wrote:\n> > Excerpts from Macdonald-Wallace, Matthew\'s message of 2014-06-26 04:13:31 \n> -0700:\n> > > Hi all,\n> > > \n> > > I\'ve been working more and more with TripleO recently and whilst it does\n> > > seem to solve a number of problems well, I have found a couple of\n> > > idiosyncrasies that I feel would be easy to address.\n> > > \n> > > My primary concern lies in the fact that os-refresh-config does not run on\n> > > every boot/reboot of a system.  Surely a reboot *is* a configuration\n> > > change and therefore we should ensure that the box has come up in the\n> > > expected state with the correct config?\n> > > \n> > > This is easily fixed through the addition of an \"@reboot\" entry in\n> > > /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c to run\n> > > as a service.\n> > > \n> > > My secondary concern is that through not running os-refresh-config on a\n> > > regular basis by default (i.e. every 15 minutes or something in the same\n> > > style as chef/cfengine/puppet), we leave ourselves exposed to someone\n> > > trying to make a \"quick fix\" to a production node and taking that node\n> > > offline the next time it reboots because the config was still left as\n> > > broken owing to a lack of updates to HEAT (I\'m thinking a \"quick change\"\n> > > to allow root access via SSH during a major incident that is then left\n> > > unchanged for months because no-one updated HEAT).\n> > > \n> > > There are a number of options to fix this including Modifying\n> > > os-collect-config to auto-run os-refresh-config on a regular basis or\n> > > setting os-refresh-config to be its own service running via upstart or\n> > > similar that triggers every 15 minutes\n> > > \n> > > I\'m sure there are other solutions to these problems, however I know from\n> > > experience that claiming this is solved through \"education of users\" or\n> > > (more severely!) via HR is not a sensible approach to take as by the time\n> > > you realise that your configuration has been changed for the last 24\n> > > hours it\'s often too late!\n> > So I see two problems highlighted above.\n> > \n> > 1) We don\'t re-assert ephemeral state set by o-r-c scripts. You\'re right,\n> > and we\'ve been talking about it for a while. The right thing to do is\n> > have os-collect-config re-run its command on boot. I don\'t think a cron\n> > job is the right way to go, we should just have a file in /var/run that\n> > is placed there only on a successful run of the command. If that file\n> > does not exist, then we run the command.\n> > \n> > I\'ve just opened this bug in response:\n> > \n> > https://bugs.launchpad.net/os-collect-config/+bug/1334804\n> > \n> \n> I have been looking into bug #1334804 and I have a review up to resolve it. I \n> want to highlight something.\n> \n> Currently on a reboot we start all services via upstart (on debian anyways) \n> and there have been quite a lot of issues around this - missing upstart \n> scripts and timing issues. I don\'t know the issues on fedora.\n> \n> So with a fix to #1334804, on a reboot upstart will start all the services \n> first (with potentially out-of-date configuration), then o-c-c will start o-r-\n> c and will now configure all services and restart them or start them if \n> upstart isn\'t configured properly.\n> \n> I would like to turn off all boot scripts for services we configure and leave \n> all this to o-r-c. I think this will simplify things and put us in control of \n> starting services. I believe that it will also narrow the gap between fedora \n> and debian or debian and debian so what works on one should work on the other \n> and make it easier for developers.\n\nAgreed, and that is actually really simple. I hate to steal your thunder,\nbut this is the patch:\n\nhttps://review.openstack.org/107772\n\n> \n> Having the ability to service nova-api stop|start|restart is very handy but \n> this will be a manually thing and I intend to leave that there.\n> \n> What do people think and how best do I push this forward. I feel that this \n> leads into the the re-assert-system-state spec but mainly I think this is a \n> bug and doesn\'t require a spec.\n> \n> I will be at the tripleo mid-cycle meetup next and willing to discuss this \n> with anyone interested in this and put together the necessary bits to make \n> this happen.\n\nAs I said, it is simple. :) I suggest testing the patch above and adding\nanything I missed to it.\n\nSystemd based systems will likely need something different. I\'m still\nburying my head int he sand and not learning systemd, but perhaps a\nfollow-up patch from somebody who understands it can make those systems\ndo the same thing.\n\n\n','<2583336.z3NAMjXaq9@michael-hp-z400-workstation>',NULL),('<1405634410.5087.10.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 22:00:13',0,'2014-07-17 22:00:13',NULL,'[openstack-dev] [heat]Heat Db Model updates','On Thu, 2014-07-17 at 08:51 -0400, Ryan Brown wrote:\n> On 07/17/2014 03:33 AM, Steven Hardy wrote:\n> > On Thu, Jul 17, 2014 at 12:31:05AM -0400, Zane Bitter wrote:\n> >> On 16/07/14 23:48, Manickam, Kanagaraj wrote:\n> >>> SNIP\n> >>> *Resource*\n> >>>\n> >>> Status & action should be enum of predefined status\n> >>\n> >> +1\n> >>\n> >>> Rsrc_metadata - make full name resource_metadata\n> >>\n> >> -0. I don\'t see any benefit here.\n> >\n> > Agreed\n> \n> \n> I\'d actually be in favor of the change from rsrc->resource, I feel like \n> rsrc is a pretty opaque abbreviation.\n> \nIt really has nothing to do with resource, when I added this field \nI wanted to call it \"metadata\", but it conflicts with an internal\nattribute in sqla. So I had to change it somehow.\n\nAre we planning data migrations for these changes?\n\n-Angus\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/5bc8a8b0/attachment.pgp>\n\n','<53C7C6BD.5050308@redhat.com>',NULL),('<1405635562-sup-1005@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-17 15:24:12',-25200,'2014-07-17 22:24:12',NULL,'[openstack-dev] [heat]Heat Db Model updates','Excerpts from Manickam, Kanagaraj\'s message of 2014-07-16 20:48:04 -0700:\n> Event\n> Why uuid and id both used?\n\nThe event uuid is the user-facing ID. However, we need to return events\nto the user in insertion order. So we use an auto-increment primary key,\nand order by that in \'heat event-list stack_name\'.\n\nWe don\'t want to expose that integer to the user though, because knowing\nthe rate at which these integers increase would reveal a lot about the\ngoings on inside Heat.\n\n> Resource_action is being used in both event and resource table, so it should be moved to common table\n\nIf we\'re joining to resource already o-k, but it is worth noting that\nthere is a desire to not use a SQL table for event storage. Maintaining\nthose events on a large, busy stack will be expensive. The simpler\nsolution is to just write batches of event files into swift.\n\n\n','<D829F158B90303479A71BCAA89E1E7602339DC7C@G9W0723.americas.hpqcorp.net>',NULL),('<1405702289-sup-6669@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-18 09:56:32',-25200,'2014-07-18 16:56:32',NULL,'[openstack-dev] [heat] health maintenance in autoscaling groups','Excerpts from Mike Spreitzer\'s message of 2014-07-18 09:12:21 -0700:\n> Thomas Herve <thomas.herve at enovance.com> wrote on 07/17/2014 02:06:13 AM:\n> \n> > There are 4 resources related to neutron load balancing. \n> > OS::Neutron::LoadBalancer is probably the least useful and the one \n> > you can *not* use, as it\'s only there for compatibility with \n> > AWS::AutoScaling::AutoScalingGroup. OS::Neutron::HealthMonitor does \n> > the health checking part, although maybe not in the way you want it.\n> \n> OK, let\'s work with these.  My current view is this: supposing the \n> Convergence work delivers monitoring of health according to a member\'s \n> status in its service and reacts accordingly, the gaps (compared to AWS \n> functionality) are the abilities to (1) get member health from \n> \"application level pings\" (e.g., URL polling) and (2) accept member health \n> declarations from an external system, with consistent reaction to health \n> information from all sources.\n> \n\nConvergence will not deliver monitoring, though I understand how one\nmight have that misunderstanding. Convergence will check with the API\nthat controls a physical resource to determine what Heat should consider\nits status to be for the purpose of ongoing orchestration.\n\n> Source (1) is what an OS::Neutron::HealthMonitor specifies, and an \n> OS::Neutron::Pool is the thing that takes such a spec.  So we could \n> complete the (1) part if there were a way to tell a scaling group to poll \n> the member health information developed by an OS::Neutron::Pool.  Does \n> that look like the right approach?\n> \n> For (2), this would amount to having an API that an external system (with \n> proper authorization) can use to declare member health.  In the grand and \n> glorious future when scaling groups have true APIs rather than being Heat \n> hacks, such a thing would be part of those APIs.  In the immediate future \n> we could simply add this to the Heat API.  Such an operation would take \n> somethings like a stack name or UUID, the name or UUID of a resource that \n> is a scaling group, and the member name or UUID of the Resource whose \n> health is being declared, and \"health_status=unhealthy\".  Does that look \n> about right?\n> \n\nIsn\'t (2) covered already by the cloudwatch API in Heat? I am going to\nclaim ignorance of it a bit, as I\'ve never used it, but it seems like\nthe same thing.\n\n\n','<OFF3EA8931.5695B526-ON85257D19.005758EC-85257D19.0059058C@us.ibm.com>',NULL),('<1405709646-sup-6001@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-18 11:55:21',-25200,'2014-07-18 18:55:21',NULL,'[openstack-dev] [heat] health maintenance in autoscaling groups','Excerpts from Mike Spreitzer\'s message of 2014-07-18 10:38:32 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 07/18/2014 12:56:32 PM:\n> \n> > Excerpts from Mike Spreitzer\'s message of 2014-07-18 09:12:21 -0700:\n> > > ...\n> > > OK, let\'s work with these.  My current view is this: supposing the \n> > > Convergence work delivers monitoring of health according to a member\'s \n> \n> > > status in its service and reacts accordingly, the gaps (compared to \n> AWS \n> > > functionality) are the abilities to (1) get member health from \n> > > \"application level pings\" (e.g., URL polling) and (2) accept member \n> health \n> > > declarations from an external system, with consistent reaction to \n> health \n> > > information from all sources.\n> > > \n> > \n> > Convergence will not deliver monitoring, though I understand how one\n> > might have that misunderstanding. Convergence will check with the API\n> > that controls a physical resource to determine what Heat should consider\n> > its status to be for the purpose of ongoing orchestration.\n> \n> If I understand correctly, your point is that healing is not automatic. \n> Since a scaling group is a nested stack, the observing part of Convergence \n> will automatically note in the DB when the physical resource behind a \n> scaling group member (in its role as a stack resource) is deleted.  And \n> when convergence engine gets around to acting on that Resource, the \n> backing physical resource will be automatically re-created.  But there is \n> nothing that automatically links the notice of divergence to the \n> converging action.  Have I got that right?\n> \n\nYes you have it right. I just wanted to be clear, that is not\n\"monitoring\".\n\n\n','<OF10C2BA75.8D0BCB29-ON85257D19.005F41AE-85257D19.0060EA50@us.ibm.com>',NULL),('<1405875176.96705.YahooMailNeo@web163606.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 09:52:56',-25200,'2014-07-20 16:52:56',NULL,'[openstack-dev] Zuul trigger not starting Jenkins jobs','all,\nNeed some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option..\nwhen i post a patch on the sandbox project, i see a review indicating my system is starting \'check\' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master.\n\ntia!\ndaya\n-------------------------------------\noutput from review.openstack.org -\n\n\n IBM Neutron Testing  Jul 14 3:33 PM \nPatch Set 1:\nStarting check jobs. http://127.0.0.1/zuul/status\n\noutput log from Zuul debug-\nPaste #86642 | LodgeIt!\n\n? \n? ? ? ? ? \nPaste #86642 | LodgeIt!\ndebug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1\n2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change <Change 0x7f0f4e5d64d0 106722,1> status: NEW\n2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\n(configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs)\n\nThe Jenkins master connection to Gearman is showing status as ok.?\n\ngearman status command output -\n\nstatus\nbuild:noop-check-communication:master ? 0 ? ? ? 0 ? ? ? 2\nbuild:dsvm-tempest-full 0 ? ? ? 0 ? ? ? 2\nbuild:dsvm-tempest-full:devstack_slave ?0 ? ? ? 0 ? ? ? 2\nmerger:merge ? ?0 ? ? ? 0 ? ? ? 1\nbuild:ibm-dsvm-tempest-full ? ? 0 ? ? ? 0 ? ? ? 2\nzuul:get_running_jobs ? 0 ? ? ? 0 ? ? ? 1\nset_description:9.126.153.171 ? 0 ? ? ? 0 ? ? ? 1\nbuild:ibm-dsvm-tempest-full:devstack_slave ? ? ?0 ? ? ? 0 ? ? ? 2\nstop:9.126.153.171 ? ? ?0 ? ? ? 0 ? ? ? 1\nzuul:promote ? ?0 ? ? ? 0 ? ? ? 1\nbuild:noop-check-communication ?0 ? ? ? 0 ? ? ? 2\nzuul:enqueue ? ?0 ? ? ? 0 ? ? ? 1\nmerger:update ? 0 ? ? ? 0 ? ? ? 1\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140720/13d4a522/attachment.html>\n\n',NULL,NULL),('<1405882287.27001.15.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 14:51:27',-14400,'2014-07-20 18:51:27',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote:\n> On Thursday 26 June 2014 12:20:30 Clint Byrum wrote:\n> \n> > Excerpts from Macdonald-Wallace, Matthew\'s message of 2014-06-26\n> 04:13:31 -0700:\n> \n> > > Hi all,\n> \n> > > \n> \n> > > I\'ve been working more and more with TripleO recently and whilst\n> it does\n> \n> > > seem to solve a number of problems well, I have found a couple of\n> \n> > > idiosyncrasies that I feel would be easy to address.\n> \n> > > \n> \n> > > My primary concern lies in the fact that os-refresh-config does\n> not run on\n> \n> > > every boot/reboot of a system. Surely a reboot *is* a\n> configuration\n> \n> > > change and therefore we should ensure that the box has come up in\n> the\n> \n> > > expected state with the correct config?\n> \n> > > \n> \n> > > This is easily fixed through the addition of an \"@reboot\" entry in\n> \n> > > /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c\n> to run\n> \n> > > as a service.\n> \n> > > \n> \n> > > My secondary concern is that through not running os-refresh-config\n> on a\n> \n> > > regular basis by default (i.e. every 15 minutes or something in\n> the same\n> \n> > > style as chef/cfengine/puppet), we leave ourselves exposed to\n> someone\n> \n> > > trying to make a \"quick fix\" to a production node and taking that\n> node\n> \n> > > offline the next time it reboots because the config was still left\n> as\n> \n> > > broken owing to a lack of updates to HEAT (I\'m thinking a \"quick\n> change\"\n> \n> > > to allow root access via SSH during a major incident that is then\n> left\n> \n> > > unchanged for months because no-one updated HEAT).\n> \n> > > \n> \n> > > There are a number of options to fix this including Modifying\n> \n> > > os-collect-config to auto-run os-refresh-config on a regular basis\n> or\n> \n> > > setting os-refresh-config to be its own service running via\n> upstart or\n> \n> > > similar that triggers every 15 minutes\n> \n> > > \n> \n> > > I\'m sure there are other solutions to these problems, however I\n> know from\n> \n> > > experience that claiming this is solved through \"education of\n> users\" or\n> \n> > > (more severely!) via HR is not a sensible approach to take as by\n> the time\n> \n> > > you realise that your configuration has been changed for the last\n> 24\n> \n> > > hours it\'s often too late!\n> \n> > So I see two problems highlighted above.\n> \n> > \n> \n> > 1) We don\'t re-assert ephemeral state set by o-r-c scripts. You\'re\n> right,\n> \n> > and we\'ve been talking about it for a while. The right thing to do\n> is\n> \n> > have os-collect-config re-run its command on boot. I don\'t think a\n> cron\n> \n> > job is the right way to go, we should just have a file in /var/run\n> that\n> \n> > is placed there only on a successful run of the command. If that\n> file\n> \n> > does not exist, then we run the command.\n> \n> > \n> \n> > I\'ve just opened this bug in response:\n> \n> > \n> \n> > https://bugs.launchpad.net/os-collect-config/+bug/1334804\n> \n> > \n> \n>  \n> \n> I have been looking into bug #1334804 and I have a review up to\n> resolve it. I want to highlight something.\n> \n>  \n> \n> Currently on a reboot we start all services via upstart (on debian\n> anyways) and there have been quite a lot of issues around this -\n> missing upstart scripts and timing issues. I don\'t know the issues on\n> fedora.\n> \n>  \n> \n> So with a fix to #1334804, on a reboot upstart will start all the\n> services first (with potentially out-of-date configuration), then\n> o-c-c will start o-r-c and will now configure all services and restart\n> them or start them if upstart isn\'t configured properly.\n> \n>  \n> \n> I would like to turn off all boot scripts for services we configure\n> and leave all this to o-r-c. I think this will simplify things and put\n> us in control of starting services. I believe that it will also narrow\n> the gap between fedora and debian or debian and debian so what works\n> on one should work on the other and make it easier for developers.\n\nI\'m not sold on this approach. At the very least I think we want to make\nthis optional because not all deployments may want to have o-r-c be the\ncentral service starting agent. So I\'m opposed to this being our (only!)\ndefault...\n\nThe job of o-r-c in this regard is to assert state... which to me means\nmaking sure that a service is configured correctly (config files, set to\nstart on boot, and initially started). Requiring o-r-c to be the service\nstarting agent (always) is beyond the scope of the o-r-c tool.\n\nIf people want to use it in that mode I think having an *option* to do\nthis is fine. I don\'t think it should be required though. Furthermore I\ndon\'t think we should get into the habit of writing our elements in such\na matter that things no longer start on boot without o-r-c in the mix.\n\nI do think we can solve these problems. But taking a hardwired\nprescriptive approach is not good here...\n\n> \n>  \n> \n> Having the ability to service nova-api stop|start|restart is very\n> handy but this will be a manually thing and I intend to leave that\n> there.\n> \n>  \n> \n> What do people think and how best do I push this forward. I feel that\n> this leads into the the re-assert-system-state spec but mainly I think\n> this is a bug and doesn\'t require a spec.\n> \n>  \n> \n> I will be at the tripleo mid-cycle meetup next and willing to discuss\n> this with anyone interested in this and put together the necessary\n> bits to make this happen.\n> \n>  \n> \n> Michael\n> \n>  \n> \n>  \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<2583336.z3NAMjXaq9@michael-hp-z400-workstation>',NULL),('<1405888521.7072.8.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 15:35:21',-18000,'2014-07-20 20:35:21',NULL,'[openstack-dev] [all][specs] Please stop doing specs for any\n changes in projects','Thanks Duncan and also Dolph, I should have made the question\nbroader.  :-)\n\nOn Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:\n> On 16 July 2014 03:57, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:\n> > John,\n> >\n> > So you have said a few times that the specs are a learning process.\n> > What do you feel with have learned thus far using specs?\n> \n> I\'m not John, but I\'m going to answer as if you\'d addressed the question wider:\n> - Specs can definitely help flesh out ideas and are much better than\n> blueprints as a way of tracking concerns, questions, etc\n> \n\nI feel I have better knowledge of what is being worked thanks to the\nspecs.  This may partially be because I was also involved from the\nsummit on for the first time.  They definitely are better for fleshing\nout ideas and discussing concerns.\n\n> - We as a community are rather shy about making decisions as\n> individuals, even low risk ones like \'Does this seem to require a\n> spec\' - if there doesn\'t seem to be value in a spec, don\'t do one\n> unless somebody asks for one\n\nAgreed.  I think we all need to be less shy about making decisions and\nvoicing them.  At least in Cinder.  :-)\n\n> \n> - Not all questions can be answered at spec time, sometimes you need\n> to go bash out some code to see what works, then circle again\n> \n> - Careful planning reduces velocity. No significant evidence either\n> way as to whether it improves quality, but my gut feeling is that it\n> does. We need to figure out what tradeoffs on either scale we\'re happy\n> to make, and perhaps that answer is different based on the area of\n> code being touched and the date (e.g. a change that doesn\'t affect\n> external APIs in J-1 might need less careful planning than a change in\n> J-3. API changes or additions need more discussion and eyes on than\n> none-API changes)\n\nI think, through this development cycle we are starting to narrow down\nwhat really needs a spec.  I think it would be good to perhaps have a\nLessons Learned session at the K summit on the specs and try to better\ndefine expectations for use in the future.  I feel it has slowed, or at\nleast focused development.  That has been good.\n\n> \n> - Specs are terrible for tracking work items, but no worse than blueprints\n> \nAgreed.\n> - Multiple people might choose to work on the same blueprint in\n> parallel - this is going to happen, isn\'t necessarily rude and the\n> correct solution to competing patches is entirely subjective\n\n\n\n\n','<CAOyZ2aG-vQ4xPQKMZkWSdTGbMVtvUN3ymE8o_Wr4Zt6RTxjGHg@mail.gmail.com>',NULL),('<1405888633.7072.9.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 15:37:13',-18000,'2014-07-20 20:37:13',NULL,'[openstack-dev] [infra] \"recheck no bug\" and comment','I agree that there are cases where a bug is overkill and it would be\nnice to add a note showing I did put some thought into doing the recheck\nno bug.  Just my two cents.\n\nOn Wed, 2014-07-16 at 17:07 +0100, Derek Higgins wrote:\n> On 16/07/14 14:48, Steve Martinelli wrote:\n> > What are the benefits of doing this over looking at the existing\n> > rechecks, and if not there opening a bug and rechecking the new bug?\n> \n> I agree we should be using a bug number (or open one when needed), the\n> example in the original email should have included a bug number but now\n> that the topic has come up\n> \n> I think this would serve as a good way to provide a little explanation\n> as to why somebody has not provided a bug number e.g.\n> \n> recheck no bug\n>    zuul was restarted\n> \n> Derek\n> \n> > \n> > \n> > Regards,\n> > \n> > *Steve Martinelli*\n> > Software Developer - Openstack\n> > Keystone Core Member\n> > ------------------------------------------------------------------------\n> > *Phone:*1-905-413-2851*\n> > E-mail:*_stevemar at ca.ibm.com_ <mailto:stevemar at ca.ibm.com> 	\n> > 8200 Warden Ave\n> > Markham, ON L6G 1C7\n> > Canada\n> > \n> > \n> > \n> > \n> > \n> > \n> > From:        Alexis Lee <alexisl at hp.com>\n> > To:        \"OpenStack Development Mailing List (not for usage\n> > questions)\" <openstack-dev at lists.openstack.org>,\n> > Date:        07/16/2014 09:19 AM\n> > Subject:        [openstack-dev]  [infra] \"recheck no bug\" and comment\n> > ------------------------------------------------------------------------\n> > \n> > \n> > \n> > Hello,\n> > \n> > What do you think about allowing some text after the words \"recheck no\n> > bug\"? EG to include a snippet from the log showing the failure has been\n> > at least briefly investigated before attempting a recheck. EG:\n> > \n> >  recheck no bug\n> > \n> >  Compute node failed to spawn:\n> > \n> >    2014-07-15 12:18:09.936 | 3f1e7f32-812e-48c8-a83c-2615c4451fa6 |\n> >      overcloud-NovaCompute0-zahdxwar7zlh | ERROR  | - | NOSTATE | |\n> > \n> > \n> > Alexis\n> > -- \n> > Nova Engineer, HP Cloud.  AKA lealexis, lxsli.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53C6A34E.6060103@redhat.com>',NULL),('<1405898831.7072.11.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 18:27:11',-18000,'2014-07-20 23:27:11',NULL,'[openstack-dev] [cinder] gettextutils enable_lazy not working','Mike,\n\nThanks for pointing this out.  I thought I had gotten all of these and\nthis supports the need for the hacking check I will work on.\n\nWe also hit errors like this on our internal CI due to a bad merge.\n\nAnyway, I am on top of this.  Will fix asap.\n\nJay\n\nOn Sun, 2014-07-20 at 15:49 -0700, Mike Perez wrote:\n> Recent change to how we use gettextutils [1] seem to not import _\n> anymore. According to the commit, enable_lazy() is suppose to\n> *replace* gettextutils.install(), but I can\'t see where in the code\n> that happens or see it actually working.\n> \n> I have reported a bug [2] that cinder-manage and cinder-rtstool [3] no\n> longer work as a result. Using gettextutils.install() seems to resolve\n> the issue or explicitly import _. Can someone who is familiar with\n> this module please enlighten me how this is suppose to work?\n> \n> [1] - https://review.openstack.org/#/c/105561/4\n> [2] - https://bugs.launchpad.net/cinder/+bug/1345789\n> [3] - https://bugs.launchpad.net/cinder/+bug/1345789/comments/4\n> \n> --\n> Mike Perez\n\n\n\n\n','<CAHcn5b3aG5NfKYCmTDsK9wn1j5776+AVyYZ17TC=FroQiyPCJQ@mail.gmail.com>',NULL),('<1405902200.5908.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 17:23:20',-25200,'2014-07-21 00:23:20',NULL,'[openstack-dev] [third-party] Zuul trigger not starting Jenkins jobs','\n\nall,\nNeed some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option..\nwhen i post a patch on the sandbox project, i see a review indicating my system is starting \'check\' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master.\n\ntia!\ndaya\n-------------------------------------\noutput from review.openstack.org -\n\n\n IBM Neutron Testing  Jul 14 3:33 PM \nPatch Set 1:\nStarting check jobs. http://127.0.0.1/zuul/status\n\noutput log from Zuul debug-\nPaste #86642 | LodgeIt!\n\n? \n? ? ? ? ? \nPaste #86642 | LodgeIt!\ndebug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1\n2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change <Change 0x7f0f4e5d64d0 106722,1> status: NEW\n2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\n(configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs)\n\nThe Jenkins master connection to Gearman is showing status as ok.?\n\ngearman status command output -\n\nstatus\nbuild:noop-check-communication:master ? 0 ? ? ? 0 ? ? ? 2\nbuild:dsvm-tempest-full 0 ? ? ? 0 ? ? ? 2\nbuild:dsvm-tempest-full:devstack_slave ?0 ? ? ? 0 ? ? ? 2\nmerger:merge ? ?0 ? ? ? 0 ? ? ? 1\nbuild:ibm-dsvm-tempest-full ? ? 0 ? ? ? 0 ? ? ? 2\nzuul:get_running_jobs ? 0 ? ? ? 0 ? ? ? 1\nset_description:9.126.153.171 ? 0 ? ? ? 0 ? ? ? 1\nbuild:ibm-dsvm-tempest-full:devstack_slave ? ? ?0 ? ? ? 0 ? ? ? 2\nstop:9.126.153.171 ? ? ?0 ? ? ? 0 ? ? ? 1\nzuul:promote ? ?0 ? ? ? 0 ? ? ? 1\nbuild:noop-check-communication ?0 ? ? ? 0 ? ? ? 2\nzuul:enqueue ? ?0 ? ? ? 0 ? ? ? 1\nmerger:update ? 0 ? ? ? 0 ? ? ? 1\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140720/5b124383/attachment.html>\n\n','<1405875176.96705.YahooMailNeo@web163606.mail.gq1.yahoo.com>',NULL),('<1405903476-sup-6304@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 17:58:08',-25200,'2014-07-21 00:58:08',NULL,'[openstack-dev] [TripleO] os-refresh-config run frequency','Excerpts from Dan Prince\'s message of 2014-07-20 11:51:27 -0700:\n> On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote:\n> > On Thursday 26 June 2014 12:20:30 Clint Byrum wrote:\n> > \n> > > Excerpts from Macdonald-Wallace, Matthew\'s message of 2014-06-26\n> > 04:13:31 -0700:\n> > \n> > > > Hi all,\n> > \n> > > > \n> > \n> > > > I\'ve been working more and more with TripleO recently and whilst\n> > it does\n> > \n> > > > seem to solve a number of problems well, I have found a couple of\n> > \n> > > > idiosyncrasies that I feel would be easy to address.\n> > \n> > > > \n> > \n> > > > My primary concern lies in the fact that os-refresh-config does\n> > not run on\n> > \n> > > > every boot/reboot of a system. Surely a reboot *is* a\n> > configuration\n> > \n> > > > change and therefore we should ensure that the box has come up in\n> > the\n> > \n> > > > expected state with the correct config?\n> > \n> > > > \n> > \n> > > > This is easily fixed through the addition of an \"@reboot\" entry in\n> > \n> > > > /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c\n> > to run\n> > \n> > > > as a service.\n> > \n> > > > \n> > \n> > > > My secondary concern is that through not running os-refresh-config\n> > on a\n> > \n> > > > regular basis by default (i.e. every 15 minutes or something in\n> > the same\n> > \n> > > > style as chef/cfengine/puppet), we leave ourselves exposed to\n> > someone\n> > \n> > > > trying to make a \"quick fix\" to a production node and taking that\n> > node\n> > \n> > > > offline the next time it reboots because the config was still left\n> > as\n> > \n> > > > broken owing to a lack of updates to HEAT (I\'m thinking a \"quick\n> > change\"\n> > \n> > > > to allow root access via SSH during a major incident that is then\n> > left\n> > \n> > > > unchanged for months because no-one updated HEAT).\n> > \n> > > > \n> > \n> > > > There are a number of options to fix this including Modifying\n> > \n> > > > os-collect-config to auto-run os-refresh-config on a regular basis\n> > or\n> > \n> > > > setting os-refresh-config to be its own service running via\n> > upstart or\n> > \n> > > > similar that triggers every 15 minutes\n> > \n> > > > \n> > \n> > > > I\'m sure there are other solutions to these problems, however I\n> > know from\n> > \n> > > > experience that claiming this is solved through \"education of\n> > users\" or\n> > \n> > > > (more severely!) via HR is not a sensible approach to take as by\n> > the time\n> > \n> > > > you realise that your configuration has been changed for the last\n> > 24\n> > \n> > > > hours it\'s often too late!\n> > \n> > > So I see two problems highlighted above.\n> > \n> > > \n> > \n> > > 1) We don\'t re-assert ephemeral state set by o-r-c scripts. You\'re\n> > right,\n> > \n> > > and we\'ve been talking about it for a while. The right thing to do\n> > is\n> > \n> > > have os-collect-config re-run its command on boot. I don\'t think a\n> > cron\n> > \n> > > job is the right way to go, we should just have a file in /var/run\n> > that\n> > \n> > > is placed there only on a successful run of the command. If that\n> > file\n> > \n> > > does not exist, then we run the command.\n> > \n> > > \n> > \n> > > I\'ve just opened this bug in response:\n> > \n> > > \n> > \n> > > https://bugs.launchpad.net/os-collect-config/+bug/1334804\n> > \n> > > \n> > \n> >  \n> > \n> > I have been looking into bug #1334804 and I have a review up to\n> > resolve it. I want to highlight something.\n> > \n> >  \n> > \n> > Currently on a reboot we start all services via upstart (on debian\n> > anyways) and there have been quite a lot of issues around this -\n> > missing upstart scripts and timing issues. I don\'t know the issues on\n> > fedora.\n> > \n> >  \n> > \n> > So with a fix to #1334804, on a reboot upstart will start all the\n> > services first (with potentially out-of-date configuration), then\n> > o-c-c will start o-r-c and will now configure all services and restart\n> > them or start them if upstart isn\'t configured properly.\n> > \n> >  \n> > \n> > I would like to turn off all boot scripts for services we configure\n> > and leave all this to o-r-c. I think this will simplify things and put\n> > us in control of starting services. I believe that it will also narrow\n> > the gap between fedora and debian or debian and debian so what works\n> > on one should work on the other and make it easier for developers.\n> \n> I\'m not sold on this approach. At the very least I think we want to make\n> this optional because not all deployments may want to have o-r-c be the\n> central service starting agent. So I\'m opposed to this being our (only!)\n> default...\n> \n\nI felt this way too. However, I\'m open to it because I am worried that\nit is a bit idealistic without much justification for being so.\n\nWe know o-r-c will be there, and really must be there. We\'re already\nsaying it needs to run to assert ephemeral state, and one thing ephemeral\nis \"things started\".\n\nNow, we can, and maybe even should, take a hard line long term that\no-r-c does not do this. That it stores everything in system level\nconfigs that are started in the normal system boot. I _want_ this to\nbe the case. But thus far, we\'ve failed to assert that and things have\noccasionally been very broken on reboot. Short of forcing a reboot in\nevery CI run, we\'re going to have trouble detecting this.\n\nSo, I think we have two options:\n\n1) O-r-c doing the asserting, with which we can more or less predict\nthat subsequent boots will work in the same manner as the first boot.\n\n2) Reboot in CI.\n\nI would vote for 2, as it probably won\'t add much time and will test\nsystem start up.\n\n> The job of o-r-c in this regard is to assert state... which to me means\n> making sure that a service is configured correctly (config files, set to\n> start on boot, and initially started). Requiring o-r-c to be the service\n> starting agent (always) is beyond the scope of the o-r-c tool.\n> \n> If people want to use it in that mode I think having an *option* to do\n> this is fine. I don\'t think it should be required though. Furthermore I\n> don\'t think we should get into the habit of writing our elements in such\n> a matter that things no longer start on boot without o-r-c in the mix.\n> \n\nI don\'t think We need an option. Options are for real incompatible\ndifferences of operation, like \"I want to run in ultra-secure mode and\nthat breaks stuff that I don\'t care about so I turn those things off\"\nor \"I want to use packages because my business and support model is\nbuilt around it.\"  Those are real, legitimate differences which we _do_\nneed options for.\n\nWe need to clearly state a design principle, and we need to ensure that\nour CI tests the mechanism by which we do these things.\n\n> I do think we can solve these problems. But taking a hardwired\n> prescriptive approach is not good here...\n> \n\nIt\'s just one option, and not the best one. I am quite confident that you\nall will figure out how to test reboots and do that. And then we\'ll all\nfeel better about trusting the system to start services on a cold boot.\n\n\n','<1405882287.27001.15.camel@dovetail.localdomain>',NULL),('<1405910159.7072.13.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-20 21:35:59',-18000,'2014-07-21 02:35:59',NULL,'[openstack-dev] [cinder][nova] cinder querying nova-api','Abbass,\n\nThere has been discussion around this in the past.\n\nAs it would be a significant feature you should open a spec for it.  Do\na \'git clone https://github.com/openstack/cinder-specs.\n\nThere are directions in there for actually submitting the spec.\n\nThanks!\nJay\n\nOn Fri, 2014-07-18 at 09:01 +0200, Abbass MAROUNI wrote:\n> Thanks Thomas,\n> \n> By cinder spec. you mean a cinder blueprint ?\n> Where I can submit such a proposition ?\n> \n> Thanks,\n> \n> On 07/17/2014 05:20 PM, openstack-dev-request at lists.openstack.org wrote:\n> > You\'re far from the only person trying to achieve that result, there\'s\n> > plenty of interest in it, and a few approaches being suggested.\n> >\n> > I can\'t see a current cinder spec open for this, so it might be worth\n> > you starting one, you\'re more likely to get detailed feedback about\n> > the pitfalls there.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53C8C663.2030909@virtualscale.fr>',NULL),('<1405923196.50080.YahooMailNeo@web194601.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 14:13:16',28800,'2014-07-21 06:13:16',NULL,'[openstack-dev] [Tripleo][Heat] Heat is not able to create swift\n	cloud server','Hi all,\n\nI have been trying to set up tripleo using instack with RDO.\nNow, when deploying overcloud, the script is failing consistently\nwith CREATE_FAILED error:\n\n+ heat stack-create -f overcloud.yaml -P AdminToken=efe958561450ba61d7ef8249d29b0be1ba95dc11 -P AdminPassword=2b919f2ac7790ca1053ac58bc4621ca0967a0cba -P CinderPassword=e7d61883a573a3dffc65a5fb958c94686baac848 -P GlancePassword=cb896d6392e08241d504f3a0a2b489fc6f2612dd -P HeatPassword=7a3138ef58365bb666cb30c8377447b74e75a0ef -P NeutronPassword=4480ec8f2e004be4b06d14e1e228d882e18b3c2c -P NovaPassword=e4a34b6caeeb7dbc497fb1c557a396c422b4d103 -P NeutronPublicInterface=eth0 -P SwiftPassword=ed3761a03959e0d636b8d6fc826103734069f9dc -P SwiftHashSuffix=1a26593813bb7d6b38418db747b4243d4f1b5a56 -P NovaComputeLibvirtType=qemu -P \'GlanceLogFile=\'\\\'\'\'\\\'\'\' -P NeutronDnsmasqOptions=dhcp-option-force=26,1400 overcloud\n+--------------------------------------+------------+--------------------+----------------------+\n| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | stack_name | stack_status ? ? ? | creation_time ? ? ? ?|\n+--------------------------------------+------------+--------------------+----------------------+\n| 737ada9f-aa45-45b6-a42b-c0a496d2407e | overcloud ?| CREATE_IN_PROGRESS | 2014-07-21T06:02:22Z |\n+--------------------------------------+------------+--------------------+----------------------+\n+ tripleo wait_for_stack_ready 220 10 overcloud\nCommand output matched \'CREATE_FAILED\'. Exiting...\n\nHere is the heat log:\n\n\n2014-07-18 06:51:11.884 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:12.921 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:16.058 30750 ERROR heat.engine.resource [-] CREATE : Server \"SwiftStorage0\" [07e42c3d-0f1b-4bb9-b980-ffbb74ac770d] Stack \"overcloud\" [0ca028e7-682b-41ef-8af0-b2eb67bee272]\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource Traceback (most recent call last):\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resource.py\", line 420, in _do_action\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource while not check(handle_data):\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 545, in check_create_complete\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource return self._check_active(server)\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 561, in _check_active\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource raise exc\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource Error: Creation of server overcloud-SwiftStorage0-qdjqbif6peva failed.\n2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource\n2014-07-18 06:51:16.255 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:16.939 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:17.368 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:17.638 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:18.158 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:18.613 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:19.113 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:19.765 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-07-18 06:51:20.247 30750 WARNING heat.engine.service [-] Stack create failed, status FAILED\n\nHow can I resolve this?\n\n?Thanks,\nPeeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140721/5c18672b/attachment.html>\n\n',NULL,NULL),('<1405937616.90315.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 03:13:36',-25200,'2014-07-21 10:13:36',NULL,'[openstack-dev] [third-party] Zuul trigger not starting Jenkins\n	jobs','hi steve,\nthanks a lot for following up! i\'m based out of india, so there\'s not much overlap in timezones. i\'ll unicast you for next steps. wanted to post the info you asked for in this thread.\nthe 2 files are here -?Paste #87382 | LodgeIt!\n? \n? ? ? ? ? \nPaste #87382 | LodgeIt!\nexamples.yaml -\n-------------------------------------------------------- - job-template: name: \'noop-check-communication\' node: \'{node}\' builders: - shell: | #!/bin/bash -xe echo \"Hello world, this is the {vendor} Testing System\" - job-tem...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\ni just have some customizations to devstack-gate script, but the overall framework more or less intact as cloned from?https://raw.github.com/jaypipes/os-ext-testing/master/puppet/install_master.sh. not using nodepools currently, just 1 master and 1 slave node.\n\nthanks!\n\n\n\n________________________________\n From: Steven Weston <sweston at Brocade.com>\nTo: daya kamath <daya_k at yahoo.com>; OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \nSent: Monday, July 21, 2014 1:53 PM\nSubject: Re: [openstack-dev] [third-party] Zuul trigger not starting Jenkins jobs\n \n\n\nOn 7/20/14, 5:25 PM, daya kamath wrote:\n\n\n>\n>all,\n>Need some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option..\n>when i post a patch on the sandbox project, i see a review indicating my system is starting \'check\' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master.\n>\n>\n>tia!\n>daya\n>-------------------------------------\n>output from review.openstack.org -\n>\n>\n> IBM Neutron Testing \n> Jul 14 3:33 PM \n>Patch Set 1:\n>Starting check jobs. http://127.0.0.1/zuul/status\n>\n>\n>output log from Zuul debug-\n>Paste #86642 | LodgeIt!\n>\n>? \n>? ? ? ? ? \n>Paste #86642 | LodgeIt!\n>debug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1 2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change <Change 0x7f0f4e5d64d0 106722,1> status: NEW 2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: <TriggerEvent... \n>\n> \n>View on paste.openstack.org Preview by Yahoo \n>\n> \n>? \n>\n>\n>(configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs)\n>\n>\n>The Jenkins master connection to Gearman is showing status as ok.?\n>\n>\n>gearman status command output -\n>\n>\n>status\n>build:noop-check-communication:master ? 0 ? ? ? 0 ? ? ? 2\n>build:dsvm-tempest-full 0 ? ? ? 0 ? ? ? 2\n>build:dsvm-tempest-full:devstack_slave ?0 ? ? ? 0 ? ? ? 2\n>merger:merge ? ?0 ? ? ? 0 ? ? ? 1\n>build:ibm-dsvm-tempest-full ? ? 0 ? ? ? 0 ? ? ? 2\n>zuul:get_running_jobs ? 0 ? ? ? 0 ? ? ? 1\n>set_description:9.126.153.171 ? 0 ? ? ? 0 ? ? ? 1\n>build:ibm-dsvm-tempest-full:devstack_slave ? ? ?0 ? ? ? 0 ? ? ? 2\n>stop:9.126.153.171 ? ? ?0 ? ? ? 0 ? ? ? 1\n>zuul:promote ? ?0 ? ? ? 0 ? ? ? 1\n>build:noop-check-communication ?0 ? ? ? 0 ? ? ? 2\n>zuul:enqueue ? ?0 ? ? ? 0 ? ? ? 1\n>merger:update ? 0 ? ? ? 0 ? ? ? 1\n>\n>\n>\n>\n>\n>\nHi Daya,\n\nI did ping you back in IRC last week; however you, unfortunately had\n    already signed off.? I have tried to ping you several times since,\n    but every time I have checked you have not been online.\n\nIn my experience, this issue has been caused by a mismatch in the\n    jobs configured in the Zuul pipelines and those configured in\n    Jenkins.? Can you post your Jenkins jobs builder files (your\n    projects.yaml file and the yaml file which you defined the\n    ibm-dsvm-dempest-full job in?? Also, please post your zuul.conf file\n    and your layout.yaml files as well.\n\nPlease feel free to follow up with me at sweston at brocade.com.? I will be happy to continue our discussion over email.\n\nThanks,\nSteve Weston\nOpenStack Software Engineer\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140721/b411ac9b/attachment.html>\n\n','<EDD8E64855FBDA45ACDFE02112E795B7069D0C8AF5@HQ1-EXCH03.corp.brocade.com>',NULL),('<1405954950.15158.143980777.775AB00A@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 11:02:30',-14400,'2014-07-21 15:02:30',NULL,'[openstack-dev] [all][specs] Please stop doing specs for any\n changes in projects','\n\nOn Sun, Jul 20, 2014, at 04:35 PM, Jay S. Bryant wrote:\n> Thanks Duncan and also Dolph, I should have made the question\n> broader.  :-)\n> \n> On Wed, 2014-07-16 at 13:22 +0100, Duncan Thomas wrote:\n> > On 16 July 2014 03:57, Jay S. Bryant <jsbryant at electronicjungle.net> wrote:\n> > > John,\n> > >\n> > > So you have said a few times that the specs are a learning process.\n> > > What do you feel with have learned thus far using specs?\n> > \n> > I\'m not John, but I\'m going to answer as if you\'d addressed the question wider:\n> > - Specs can definitely help flesh out ideas and are much better than\n> > blueprints as a way of tracking concerns, questions, etc\n> > \n> \n> I feel I have better knowledge of what is being worked thanks to the\n> specs.  This may partially be because I was also involved from the\n> summit on for the first time.  They definitely are better for fleshing\n> out ideas and discussing concerns.\n> \n> > - We as a community are rather shy about making decisions as\n> > individuals, even low risk ones like \'Does this seem to require a\n> > spec\' - if there doesn\'t seem to be value in a spec, don\'t do one\n> > unless somebody asks for one\n> \n> Agreed.  I think we all need to be less shy about making decisions and\n> voicing them.  At least in Cinder.  :-)\n> \n> > \n> > - Not all questions can be answered at spec time, sometimes you need\n> > to go bash out some code to see what works, then circle again\n> > \n> > - Careful planning reduces velocity. No significant evidence either\n> > way as to whether it improves quality, but my gut feeling is that it\n> > does. We need to figure out what tradeoffs on either scale we\'re happy\n> > to make, and perhaps that answer is different based on the area of\n> > code being touched and the date (e.g. a change that doesn\'t affect\n> > external APIs in J-1 might need less careful planning than a change in\n> > J-3. API changes or additions need more discussion and eyes on than\n> > none-API changes)\n> \n> I think, through this development cycle we are starting to narrow down\n> what really needs a spec.  I think it would be good to perhaps have a\n> Lessons Learned session at the K summit on the specs and try to better\n> define expectations for use in the future.  I feel it has slowed, or at\n> least focused development.  That has been good.\n\nWe should make that a cross-project session, so we can learn from what\nthe other projects did, too.\n\nDoug\n\n> \n> > \n> > - Specs are terrible for tracking work items, but no worse than blueprints\n> > \n> Agreed.\n> > - Multiple people might choose to work on the same blueprint in\n> > parallel - this is going to happen, isn\'t necessarily rude and the\n> > correct solution to competing patches is entirely subjective\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1405888521.7072.8.camel@bluejungle.ibm.com>',NULL),('<1405957982.8270.1.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 10:53:02',-18000,'2014-07-21 15:53:02',NULL,'[openstack-dev] [Cinder] Integrated with iSCSI target Question','Johnson,\n\nI am not sure what you mean by \'attach volume manually\'.  Do you mean\nwhen you do a \'nova volume-attach\'?  If so, then, yes, the process will\nuse the appropriate iscsi_helper and iscsi_ip_address to configure the\nattachment.\n\nDoes that answer your question?\n\nJay\n\nOn Mon, 2014-07-21 at 12:23 +0000, Johnson Cheng wrote:\n> Dear Thomas,\n> \n> Thanks for your reply.\n> So when I attach volume manually, will iSCSI LUN be automatically setup via cinder.conf (iscsi_helper and iscsi_ip_address)?\n> \n> \n> Regards,\n> Johnson\n> \n> -----Original Message-----\n> From: Duncan Thomas [mailto:duncan.thomas at gmail.com] \n> Sent: Monday, July 21, 2014 6:16 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target Question\n> \n> The iSCSI lun won\'t be set up until you try to attach the volume\n> \n> On 17 July 2014 12:44, Johnson Cheng <Johnson.Cheng at qsantechnology.com> wrote:\n> > Dear All,\n> >\n> >\n> >\n> > I installed iSCSI target at my controller node (IP: 192.168.106.20),\n> >\n> > #>iscsitarget open-iscsi iscsitarget-dkms\n> >\n> >\n> >\n> > then modify my cinder.conf at controller node as below,\n> >\n> > [DEFAULT]\n> >\n> > rootwrap_config = /etc/cinder/rootwrap.conf\n> >\n> > api_paste_confg = /etc/cinder/api-paste.ini\n> >\n> > #iscsi_helper = tgtadm\n> >\n> > iscsi_helper = ietadm\n> >\n> > volume_name_template = volume-%s\n> >\n> > volume_group = cinder-volumes\n> >\n> > verbose = True\n> >\n> > auth_strategy = keystone\n> >\n> > #state_path = /var/lib/cinder\n> >\n> > #lock_path = /var/lock/cinder\n> >\n> > #volumes_dir = /var/lib/cinder/volumes\n> >\n> > iscsi_ip_address=192.168.106.20\n> >\n> >\n> >\n> > rpc_backend = cinder.openstack.common.rpc.impl_kombu\n> >\n> > rabbit_host = controller\n> >\n> > rabbit_port = 5672\n> >\n> > rabbit_userid = guest\n> >\n> > rabbit_password = demo\n> >\n> >\n> >\n> > glance_host = controller\n> >\n> >\n> >\n> > enabled_backends=lvmdriver-1,lvmdriver-2\n> >\n> > [lvmdriver-1]\n> >\n> > volume_group=cinder-volumes-1\n> >\n> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n> >\n> > volume_backend_name=LVM_iSCSI\n> >\n> > [lvmdriver-2]\n> >\n> > volume_group=cinder-volumes-2\n> >\n> > volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver\n> >\n> > volume_backend_name=LVM_iSCSI_b\n> >\n> > [database]\n> >\n> > connection = mysql://cinder:demo at controller/cinder\n> >\n> >\n> >\n> > [keystone_authtoken]\n> >\n> > auth_uri = http://controller:5000\n> >\n> > auth_host = controller\n> >\n> > auth_port = 35357\n> >\n> > auth_protocol = http\n> >\n> > admin_tenant_name = service\n> >\n> > admin_user = cinder\n> >\n> > admin_password = demo\n> >\n> >\n> >\n> > Now I use the following command to create a cinder volume, and it can \n> > be created successfully.\n> >\n> > #> cinder create --volume-type lvm_controller --display-name vol 1\n> >\n> >\n> >\n> > Unfortunately it seems not attach to a iSCSI LUN automatically because \n> > I can not discover it from iSCSI initiator,\n> >\n> > #> iscsiadm -m discovery -t st -p 192.168.106.20\n> >\n> >\n> >\n> > Do I miss something?\n> >\n> >\n> >\n> >\n> >\n> > Regards,\n> >\n> > Johnson\n> >\n> >\n> >\n> >\n> >\n> > From: Manickam, Kanagaraj [mailto:kanagaraj.manickam at hp.com]\n> > Sent: Thursday, July 17, 2014 1:19 PM\n> >\n> >\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [Cinder] Integrated with iSCSI target \n> > Question\n> >\n> >\n> >\n> > I think, It should be on the cinder node which is usually deployed on \n> > the controller node\n> >\n> >\n> >\n> > From: Johnson Cheng [mailto:Johnson.Cheng at QsanTechnology.com]\n> > Sent: Thursday, July 17, 2014 10:38 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: [openstack-dev] [Cinder] Integrated with iSCSI target \n> > Question\n> >\n> >\n> >\n> > Dear All,\n> >\n> >\n> >\n> > I have three nodes, a controller node and two compute nodes(volume node).\n> >\n> > The default value for iscsi_helper in cinder.conf is ?tgtadm?, I will \n> > change to ?ietadm? to integrate with iSCSI target.\n> >\n> > Unfortunately I am not sure that iscsitarget should be installed at \n> > controller node or compute node?\n> >\n> > Have any reference?\n> >\n> >\n> >\n> >\n> >\n> > Regards,\n> >\n> > Johnson\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> \n> --\n> Duncan Thomas\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<00eee5bae23a4ba7a9cbd85588c99f2c@HKNPR01MB241.apcprd01.prod.exchangelabs.com>',NULL),('<1405958576.2878.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 11:02:56',-18000,'2014-07-21 16:02:56',NULL,'[openstack-dev] [Nova] [Spec freeze exception] Online Schema\n Changes','On Mon, 2014-07-21 at 10:55 +0100, John Garbutt wrote:\n> On 19 July 2014 03:53, Johannes Erdfelt <johannes at erdfelt.com> wrote:\n> > I\'m requestion a spec freeze exception for online schema changes.\n> >\n> > https://review.openstack.org/102545\n> >\n> > This work is being done to try to minimize the downtime as part of\n> > upgrades. Database migrations have historically been a source of long\n> > periods of downtime. The spec is an attempt to start optimizing this\n> > part by allowing deployers to perform most schema changes online, while\n> > Nova is running.\n> \n> Improving upgrades is high priority, and I feel it will help reduce\n> the amount of downtime required when performing database migrations.\n> \n> So I am happy to sponsor this.\n\nI will also sponsor this for an exception.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CABib2_q5TwVhKqPbh_kAqqusx2WaL=h+6rmFb6rLnbBV544=kA@mail.gmail.com>',NULL),('<1405965378-sup-2125@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 11:03:30',-25200,'2014-07-21 18:03:30',NULL,'[openstack-dev] [gate] The gate: a failure analysis','Thanks Matthew for the analysis.\n\nI think you missed something though.\n\nRight now the frustration is that unrelated intermittent bugs stop your\npresumably good change from getting in.\n\nWithout gating, the result would be that even more bugs, many of them not\nintermittent at all, would get in. Right now, the one random developer\nwho has to hunt down the rechecks and do them is inconvenienced. But\nwithout a gate, _every single_ developer will be inconvenienced until\nthe fix is merged.\n\nThe false negative rate is _way_ too high. Nobody would disagree there.\nHowever, adding more false negatives and allowing more people to ignore\nthe ones we already have, seems like it would have the opposite effect:\nNow instead of annoying the people who hit the random intermittent bugs,\nwe\'ll be annoying _everybody_ as they hit the non-intermittent ones.\n\nExcerpts from Matthew Booth\'s message of 2014-07-21 03:38:07 -0700:\n> On Friday evening I had a dependent series of 5 changes all with\n> approval waiting to be merged. These were all refactor changes in the\n> VMware driver. The changes were:\n> \n> * VMware: DatastorePath join() and __eq__()\n> https://review.openstack.org/#/c/103949/\n> \n> * VMware: use datastore classes get_allowed_datastores/_sub_folder\n> https://review.openstack.org/#/c/103950/\n> \n> * VMware: use datastore classes in file_move/delete/exists, mkdir\n> https://review.openstack.org/#/c/103951/\n> \n> * VMware: Trivial indentation cleanups in vmops\n> https://review.openstack.org/#/c/104149/\n> \n> * VMware: Convert vmops to use instance as an object\n> https://review.openstack.org/#/c/104144/\n> \n> The last change merged this morning.\n> \n> In order to merge these changes, over the weekend I manually submitted:\n> \n> * 35 rechecks due to false negatives, an average of 7 per change\n> * 19 resubmissions after a change passed, but its dependency did not\n> \n> Other interesting numbers:\n> \n> * 16 unique bugs\n> * An 87% false negative rate\n> * 0 bugs found in the change under test\n> \n> Because we don\'t fail fast, that is an average of at least 7.3 hours in\n> the gate. Much more in fact, because some runs fail on the second pass,\n> not the first. Because we don\'t resubmit automatically, that is only if\n> a developer is actively monitoring the process continuously, and\n> resubmits immediately on failure. In practise this is much longer,\n> because sometimes we have to sleep.\n> \n> All of the above numbers are counted from the change receiving an\n> approval +2 until final merging. There were far more failures than this\n> during the approval process.\n> \n> Why do we test individual changes in the gate? The purpose is to find\n> errors *in the change under test*. By the above numbers, it has failed\n> to achieve this at least 16 times previously.\n> \n> Probability of finding a bug in the change under test: Small\n> Cost of testing:                                       High\n> Opportunity cost of slowing development:               High\n> \n> and for comparison:\n> \n> Cost of reverting rare false positives:                Small\n> \n> The current process expends a lot of resources, and does not achieve its\n> goal of finding bugs *in the changes under test*. In addition to using a\n> lot of technical resources, it also prevents good change from making its\n> way into the project and, not unimportantly, saps the will to live of\n> its victims. The cost of the process is overwhelmingly greater than its\n> benefits. The gate process as it stands is a significant net negative to\n> the project.\n> \n> Does this mean that it is worthless to run these tests? Absolutely not!\n> These tests are vital to highlight a severe quality deficiency in\n> OpenStack. Not addressing this is, imho, an existential risk to the\n> project. However, the current approach is to pick contributors from the\n> community at random and hold them personally responsible for project\n> bugs selected at random. Not only has this approach failed, it is\n> impractical, unreasonable, and poisonous to the community at large. It\n> is also unrelated to the purpose of gate testing, which is to find bugs\n> *in the changes under test*.\n> \n> I would like to make the radical proposal that we stop gating on CI\n> failures. We will continue to run them on every change, but only after\n> the change has been successfully merged.\n> \n> Benefits:\n> * Without rechecks, the gate will use 8 times fewer resources.\n> * Log analysis is still available to indicate the emergence of races.\n> * Fixes can be merged quicker.\n> * Vastly less developer time spent monitoring gate failures.\n> \n> Costs:\n> * A rare class of merge bug will make it into master.\n> \n> Note that the benefits above will also offset the cost of resolving this\n> rare class of merge bug.\n> \n> Of course, we still have the problem of finding resources to monitor and\n> fix CI failures. An additional benefit of not gating on CI will be that\n> we can no longer pretend that picking developers for project-affecting\n> bugs by lottery is likely to achieve results. As a project we need to\n> understand the importance of CI failures. We need a proper negotiation\n> with contributors to staff a team dedicated to the problem. We can then\n> use the review process to ensure that the right people have an incentive\n> to prioritise bug fixes.\n> \n> Matt\n\n\n','<53CCED8F.5040001@redhat.com>',NULL),('<1405966968-sup-3032@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-21 11:24:47',-25200,'2014-07-21 18:24:47',NULL,'[Openstack] [TripleO]Overcloud won\'t use nova command like\n	\"nova list\"','Not sure what is in stackrc, but if you used tripleo\'s \'devtest\', it\nproduces a \'tripleorc\' which can be sourced, but you still also need to\nchoose between overcloud and undercloud. So:\n\n. $TRIPLEO_ROOT/tripleorc\n. $TRIPLEO_ROOT/overcloudrc\n\nShould work.\n\nExcerpts from ??\'s message of 2014-07-21 02:09:08 -0700:\n> Hi, Everyone :\n>         I\'ve got the same issue when deployed overcloud and undercloud\n> using TripleO, I can use \"nova list\" and the other nova command :\n> https://bugs.launchpad.net/tripleo/+bug/1290488\n> Is there any way to solve this?\n> \n> root at overcloud-notcompute0-zdcmpw47hksu:~# . ~/stackrc\n> root at overcloud-notcompute0-zdcmpw47hksu:~# nova list\n> ERROR: Invalid OpenStack Nova credentials.\n> root at overcloud-notcompute0-zdcmpw47hksu:~#\n> \n> *Best Regards?*\n> \n> \n> *Chao Yan--------------**My twitter?Andy Yan @yanchao727\n> <https://twitter.com/yanchao727>*\n> \n> \n> *My Weibo?http://weibo.com/herewearenow\n> <http://weibo.com/herewearenow>--------------*\n\n\n','<CALAMvO-U8GeN70fHRcMx5nQjEx3f=caVQhYBECBevD+WJnmWEA@mail.gmail.com>',NULL),('<1405967304-sup-5691@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 11:29:47',-25200,'2014-07-21 18:29:47',NULL,'[openstack-dev] [Tripleo][Heat] Heat is not able to create\n	swift cloud server','Excerpts from Peeyush Gupta\'s message of 2014-07-20 23:13:16 -0700:\n> Hi all,\n> \n> I have been trying to set up tripleo using instack with RDO.\n> Now, when deploying overcloud, the script is failing consistently\n> with CREATE_FAILED error:\n> \n> + heat stack-create -f overcloud.yaml -P AdminToken=efe958561450ba61d7ef8249d29b0be1ba95dc11 -P AdminPassword=2b919f2ac7790ca1053ac58bc4621ca0967a0cba -P CinderPassword=e7d61883a573a3dffc65a5fb958c94686baac848 -P GlancePassword=cb896d6392e08241d504f3a0a2b489fc6f2612dd -P HeatPassword=7a3138ef58365bb666cb30c8377447b74e75a0ef -P NeutronPassword=4480ec8f2e004be4b06d14e1e228d882e18b3c2c -P NovaPassword=e4a34b6caeeb7dbc497fb1c557a396c422b4d103 -P NeutronPublicInterface=eth0 -P SwiftPassword=ed3761a03959e0d636b8d6fc826103734069f9dc -P SwiftHashSuffix=1a26593813bb7d6b38418db747b4243d4f1b5a56 -P NovaComputeLibvirtType=qemu -P \'GlanceLogFile=\'\\\'\'\'\\\'\'\' -P NeutronDnsmasqOptions=dhcp-option-force=26,1400 overcloud\n> +--------------------------------------+------------+--------------------+----------------------+\n> | id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | stack_name | stack_status ? ? ? | creation_time ? ? ? ?|\n> +--------------------------------------+------------+--------------------+----------------------+\n> | 737ada9f-aa45-45b6-a42b-c0a496d2407e | overcloud ?| CREATE_IN_PROGRESS | 2014-07-21T06:02:22Z |\n> +--------------------------------------+------------+--------------------+----------------------+\n> + tripleo wait_for_stack_ready 220 10 overcloud\n> Command output matched \'CREATE_FAILED\'. Exiting...\n> \n> Here is the heat log:\n> \n> \n> 2014-07-18 06:51:11.884 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:12.921 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:16.058 30750 ERROR heat.engine.resource [-] CREATE : Server \"SwiftStorage0\" [07e42c3d-0f1b-4bb9-b980-ffbb74ac770d] Stack \"overcloud\" [0ca028e7-682b-41ef-8af0-b2eb67bee272]\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource Traceback (most recent call last):\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resource.py\", line 420, in _do_action\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource while not check(handle_data):\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 545, in check_create_complete\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource return self._check_active(server)\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 561, in _check_active\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource raise exc\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource Error: Creation of server overcloud-SwiftStorage0-qdjqbif6peva failed.\n> 2014-07-18 06:51:16.058 30750 TRACE heat.engine.resource\n> 2014-07-18 06:51:16.255 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:16.939 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:17.368 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:17.638 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:18.158 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:18.613 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:19.113 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:19.765 30750 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n> 2014-07-18 06:51:20.247 30750 WARNING heat.engine.service [-] Stack create failed, status FAILED\n> \n> How can I resolve this?\n\nHeat is just responding to Nova. You need to look at nova and find out\nwhy that server failed. \'nova show overcloud-SwiftStorage0-qdjqbif6peva\'\nshould work.\n\n\n','<1405923196.50080.YahooMailNeo@web194601.mail.sg3.yahoo.com>',NULL),('<1405978928.3452.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 21:42:04',0,'2014-07-21 21:42:04',NULL,'[openstack-dev] [Neutron][LBaaS] Update on specs we needed approved','In reference to these 3 specs:\n\nTLS Termination - https://review.openstack.org/#/c/98640/\nL7 Switching - https://review.openstack.org/#/c/99709/\nImplementing TLS in reference Impl -\nhttps://review.openstack.org/#/c/100931/\n\nKyle has +2\'ed all three and once Mark Mcclain +2\'s them then one of\nthem will +A them.\n\nThanks again Kyle and Mark!\n\n\n\n','<CAL3VkVwGY=uVrKbU8HJcT_pTqEJ+qG2WoiR+NA7n2adAnGg4OA@mail.gmail.com>',NULL),('<1405981679.22196.144143109.1280DE0D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 18:27:59',-14400,'2014-07-21 22:27:59',NULL,'[openstack-dev] pbr 0.10.0 released','The Oslo team is pleased to announce the release of pbr 0.10.0, the\nlatest version of our setuptools wrapper for packaging python code.\n\n0.10.0 includes:\n\n* Remove all 2.7 filtering\n* Stop filtering out argparse\n* Remove mirror testing from the integration script\n\n(Those first 2 changes are related to the argparse issue we have seen\nrecently under python 2.6. https://bugs.launchpad.net/pbr/+bug/1346357)\n\nPlease report any issues using the bug tracker:\nhttps://bugs.launchpad.net/pbr\n\nDoug\n\n\n',NULL,NULL),('<1406040184.3427.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 14:43:04',0,'2014-07-22 14:43:04',NULL,'[openstack-dev] [Neutron][LBaaS] TLS capability - certificates\n data persistency','I agree with Sam.  We\'re under a strict timeline here and the simpler\nthe code the faster it will be implemented and reviewed.  Is there any\nstrong reason why this caching can\'t wait until K if it decided it is\nreally needed?\n\nThanks,\nBrandon\n\nOn Tue, 2014-07-22 at 11:01 +0000, Samuel Bercovici wrote:\n> Stephen,\n> \n>  \n> \n> This will increase the complexity of the code since it will add\n> managing the cache lifecycle in tandem with the barbican back end and\n> the fact that containers may be shared by multiple listeners.\n> \n> At this stage, I think that it serves us all to keep the code at this\n> stage as small and simple as possible.\n> \n>  \n> \n> Let?s judge if presenting this information on the fly (ex: in the Web\n> UI) becomes a performance issue and if it does, we can fix it then.\n> \n>  \n> \n> -Sam.\n> \n>  \n> \n>  \n> \n> From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n> Sent: Tuesday, July 22, 2014 3:43 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability -\n> certificates data persistency\n> \n>  \n> \n> Evgeny--\n> \n>  \n> \n> \n> The only reason I see for storing certificate information in Neutron\n> (and not private key information-- just the certificate) is to aid in\n> presenting UI information to the user. Especially GUI users don\'t care\n> about a certificate\'s UUID, they care about which hostnames it\'s valid\n> for. Yes, this can be loaded on the fly whenever public certificate\n> information is accessed, but the perception was that it would be a\n> significant performance increase to cache it.\n> \n> \n>  \n> \n> \n> Stephen\n> \n> \n>  \n> \n> On Sun, Jul 20, 2014 at 4:32 AM, Evgeny Fedoruk <EvgenyF at radware.com>\n> wrote:\n> \n> Hi folks,\n> \n>  \n> \n> In a current version of TLS capabilities RST certificate\n> SubjectCommonName and SubjectAltName information is cached in a\n> database.\n> \n> This may be not necessary and here is why:\n> \n>  \n> \n> 1.       TLS containers are immutable, meaning once a container was\n> associated to a listener and was validated, it?s not necessary to\n> validate the container anymore.\n> This is relevant for both, default container and containers used for\n> SNI.\n> \n> 2.       LBaaS front-end API can check if TLS containers ids were\n> changed for a listener as part of an update operation. Validation of\n> containers will be done for\n> new containers only. This is stated in ?Performance Impact? section of\n> the RST, excepting the last statement that proposes persistency for\n> SCN and SAN.\n> \n> 3.       Any interaction with Barbican API for getting containers data\n> will be performed via a common module API only. This module?s API is\n> mentioned in\n> ?SNI certificates list management? section of the RST.\n> \n> 4.       In case when driver really needs to extract certificate\n> information prior to the back-end system provisioning, it will do it\n> via the common module API.\n> \n> 5.       Back-end provisioning system may cache any certificate data,\n> except private key, in case of a specific need of the vendor.\n> \n>  \n> \n> IMO, There is no real need to store certificates data in Neutron\n> database and manage its life cycle. \n> \n> Does anyone sees a reason why caching certificates? data in Neutron\n> database is critical?\n> \n>  \n> \n> Thank you,\n> \n> Evg\n> \n>  \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n>  \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807 \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F36E8145F2571242A675F56CF60964560FAF0EAE@ILMB1.corp.radware.com>',NULL),('<1406056583.28836.144513453.49A5770D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 15:16:23',-14400,'2014-07-22 19:16:23',NULL,'[openstack-dev] Add a hacking check to not use \"Python Source\n Code Encodings\" (PEP0263)','\n\nOn Tue, Jul 22, 2014, at 08:41 AM, Ihar Hrachyshka wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> On 21/07/14 17:11, Doug Hellmann wrote:\n> > \n> > On Jul 21, 2014, at 4:45 AM, Christian Berendt\n> > <berendt at b1-systems.de> wrote:\n> > \n> >> Hello.\n> >> \n> >> There are some files using the Python source code encodings as\n> >> the first line. That\'s normally not necessary and I want propose\n> >> to introduce a hacking check to check for the absence of the\n> >> source code encodings.\n> > \n> > We need to be testing with Unicode inputs. Will the hacking check\n> > still support that case?\n> \n> I suspect it just means that we won\'t be able to use Unicode\n> codepoints in the code, while we still may specify those characters as\n> escape sequences, as in:\n> \n> >>> \"\\N{GREEK CAPITAL LETTER DELTA}\"  # Using the character name\n> \'\\u0394\'\n> >>> \"\\u0394\"                          # Using a 16-bit hex value\n> \'\\u0394\'\n> >>> \"\\U00000394\"                      # Using a 32-bit hex value\n> \'\\u0394\'\n> \n> (shamelessly copied from https://docs.python.org/3/howto/unicode.html)\n\nAnd what is the benefit of doing that? I assume there\'s some reason for\nsuggesting this change, but I don\'t understand it. Is there a tool\nbreaking on unicode characters now that I haven\'t heard about, maybe?\n\nDoug\n\n> \n> > \n> > Doug\n> > \n> >> \n> >> Best, Christian.\n> >> \n> >> -- Christian Berendt Cloud Computing Solution Architect Mail:\n> >> berendt at b1-systems.de\n> >> \n> >> B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg /\n> >> http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz:\n> >> Vohburg / AG: Ingolstadt,HRB 3537\n> >> \n> >> _______________________________________________ OpenStack-dev\n> >> mailing list OpenStack-dev at lists.openstack.org \n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >> \n> > \n> > _______________________________________________ OpenStack-dev\n> > mailing list OpenStack-dev at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n> \n> iQEcBAEBCgAGBQJTzlv6AAoJEC5aWaUY1u57xK4H/iaHyoE2+0gz5sZHhbMHBXm3\n> 8Dti0ZOB2D4XEOhaxhXguuaDQQdzYHc3LOj09uzO+7qjgKQa5X7SExYDg7Tz6VaC\n> lqgv5mnLZNgt2iNNK0PFGwzYV/n12w513DCuTAxROPKrZuaoMwAZFfqkcf6YGTDg\n> tH16qU8nr/1SFZYVE7w/flDRI5gS04yZavIHwuMEzWN5fXebR5TxDe/JRwFNMocI\n> jMwSZKY73TBzGlp8ND9bee0Wzv/IbUzjIi/R+FZAhgwK53Dc/jxUGJ9V+aKEox8d\n> JdF7yvquOhBQRwuARt9O6IRvN3AG2oT+lcheSA/KAkOZ+1v1oRjNDqkn2Y9KNRk=\n> =jGEy\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53CE5BFA.3010305@redhat.com>',NULL),('<1406057068.30628.144516305.72FE0D20@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-22 15:24:28',-14400,'2014-07-22 19:24:28',NULL,'[openstack-dev] [oslo] oslo.serialization and oslo.concurrency\n graduation call for help','\n\nOn Tue, Jul 22, 2014, at 06:38 AM, Yuriy Taraday wrote:\n> Hello, Ben.\n> \n> On Mon, Jul 21, 2014 at 7:23 PM, Ben Nemec <openstack at nemebean.com>\n> wrote:\n> \n> > Hi all,\n> >\n> > The oslo.serialization and oslo.concurrency graduation specs are both\n> > approved, but unfortunately I haven\'t made as much progress on them as I\n> > would like.  The serialization repo has been created and has enough acks\n> > to continue the process, and concurrency still needs to be started.\n> >\n> > Also unfortunately, I am unlikely to make progress on either over the\n> > next two weeks due to the tripleo meetup and vacation.  As discussed in\n> > the Oslo meeting last week\n> > (\n> > http://eavesdrop.openstack.org/meetings/oslo/2014/oslo.2014-07-18-16.00.log.html\n> > )\n> > we would like to continue work on them during that time, so Doug asked\n> > me to look for volunteers to pick up the work and run with it.\n> >\n> > The current status and next steps for oslo.serialization can be found in\n> > the bp:\n> > https://blueprints.launchpad.net/oslo/+spec/graduate-oslo-serialization\n> >\n> > As mentioned, oslo.concurrency isn\'t started and has a few more pending\n> > tasks, which are enumerated in the spec:\n> >\n> > http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/graduate-oslo-concurrency.rst\n> >\n> > Any help would be appreciated.  I\'m happy to pick this back up in a\n> > couple of weeks, but if someone could shepherd it along in the meantime\n> > that would be great!\n> >\n> \n> I would be happy to work on graduating oslo.concurrency as well as\n> improving it after that. I like fiddling with OS\'s, threads and races :)\n> I can also help to finish work on oslo.serialization (it looks like some\n> steps are already finished there).\n> \n> What would be needed to start working on that? I haven\'t been following\n> development of processes within Oslo. So I would need someone to answer\n> questions as they arise.\n\nThe basic process is described in\nhttps://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary, although there\nare usually differences for each library as we have to do things like\ntighten up the API. We can help with those parts after we have the new\nrepository, which is one of the more time-consuming aspects of the\ngraduation process, so if you were able to work on that it would be a\nhuge help.\n\nThanks,\nDoug\n\n> \n> -- \n> \n> Kind regards, Yuriy.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CABocrW4H3AR+o7Za9NcMUC=FLh6HmGPs_aK9XwiZV8TrWt-v8A@mail.gmail.com>',NULL),('<1406138918.3480.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 18:08:34',0,'2014-07-23 18:08:34',NULL,'[openstack-dev] FW: [Neutron][LBaaS] TLS capability - work\n division','@Evgeny: Did you intend on adding another patchset in the reviews I\'ve\nbeen working on? If so I don\'t really see any changes, so if they\'re are\nsome changes you needed in there let me know.\n\n@Doug: I think if the drivers see the TERMINATED_HTTPS protocol then\nthey can throw an exception.  I don\'t think a driver interface change is\nneeded.\n\nThanks,\nBrandon\n\n\nOn Wed, 2014-07-23 at 17:02 +0000, Doug Wiegley wrote:\n> Do we want any driver interface changes for this?  At one level, with the\n> current interface, conforming drivers could just reference\n> listener.sni_containers, with no changes.  But, do we want something in\n> place so that the API can return an unsupported error for non-TLS v2\n> drivers?  Or must all v2 drivers support TLS?\n> \n> doug\n> \n> \n> \n> On 7/23/14, 10:54 AM, \"Evgeny Fedoruk\" <EvgenyF at Radware.com> wrote:\n> \n> >My code is here:\n> >https://review.openstack.org/#/c/109035/1\n> >\n> >\n> >\n> >-----Original Message-----\n> >From: Evgeny Fedoruk\n> >Sent: Wednesday, July 23, 2014 6:54 PM\n> >To: OpenStack Development Mailing List (not for usage questions)\n> >Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - work\n> >division\n> >\n> >Hi Carlos,\n> >\n> >As I understand you are working on common module for Barbican\n> >interactions.\n> >I will commit my code later today and I will appreciate if you and\n> >anybody else  who is interested will review this change.\n> >There is one specific spot for the common Barbican interactions module\n> >API integration.\n> >After the IRC meeting tomorrow, we can discuss the work items and decide\n> >who is interested/available to do them.\n> >Does it make sense?\n> >\n> >Thanks,\n> >Evg\n> >\n> >-----Original Message-----\n> >From: Carlos Garza [mailto:carlos.garza at rackspace.com]\n> >Sent: Wednesday, July 23, 2014 6:15 PM\n> >To: OpenStack Development Mailing List (not for usage questions)\n> >Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - work\n> >division\n> >\n> >    Do you have any idea as to how we can split up the work?\n> >\n> >On Jul 23, 2014, at 6:01 AM, Evgeny Fedoruk <EvgenyF at Radware.com>\n> > wrote:\n> >\n> >> Hi,\n> >> \n> >> I\'m working on TLS integration with loadbalancer v2 extension and db.\n> >> Basing on Brandon\'s  patches https://review.openstack.org/#/c/105609 ,\n> >>https://review.openstack.org/#/c/105331/  ,\n> >>https://review.openstack.org/#/c/105610/\n> >> I will abandon previous 2 patches for TLS which are\n> >>https://review.openstack.org/#/c/74031/ and\n> >>https://review.openstack.org/#/c/102837/\n> >> Managing to submit my change later today. It will include lbaas\n> >>extension v2 modification, lbaas db v2 modifications, alembic migration\n> >>for schema changes and new tests in unit testing for lbaas db v2.\n> >> \n> >> Thanks,\n> >> Evg\n> >> \n> >> -----Original Message-----\n> >> From: Carlos Garza [mailto:carlos.garza at rackspace.com]\n> >> Sent: Wednesday, July 23, 2014 3:54 AM\n> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - work division\n> >> \n> >> 	Since it looks like the TLS blueprint was approved I\'\'m sure were all\n> >>eager to start coded so how should we divide up work on the source code.\n> >>I have Pull requests in pyopenssl\n> >>\"https://github.com/pyca/pyopenssl/pull/143\". and a few one liners in\n> >>pica/cryptography to expose the needed low-level that I\'m hoping will be\n> >>added pretty soon to that PR 143 test\'s can pass. Incase it doesn\'t we\n> >>will fall back to using the pyasn1_modules as it already also has a\n> >>means to fetch what we want at a lower level.\n> >> I\'m just hoping that we can split the work up so that we can\n> >>collaborate together on this with out over serializing the work were\n> >>people become dependent on waiting for some one else to complete their\n> >>work or worse one person ending up doing all the work.\n> >> \n> >>                 \n> >>       Carlos D. Garza _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFF5464E.5708%dougw@a10networks.com>',NULL),('<1406170983.3220.7.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-07-24 13:03:03',36000,'2014-07-24 03:03:03',NULL,'[Openstack-stable-maint] Trove stable checks broken','On Fri, 2014-07-18 at 11:55 +0200, Ihar Hrachyshka wrote:\n> On 11/06/14 14:28, Ihar Hrachyshka wrote:\n> > Hi all,\n> > \n> > it seems trove gate checks are broken. Specifically, the following \n> > tasks are doomed to fail on stable/* for the project:\n> > \n> > gate-trove-tox-checkniceness gate-trove-tox-checksynta \n> > gate-trove-tox-checkdeletions \n> > gate-trove-tox-doc-publish-checkbuild\n> > \n> > All probably coming from openstack-doc-gate defined in [1].\n> > \n> > F.e. see [2].\n> > \n> > Failures are due to those tox environments introduced in master\n> > only, so stable branches should not run those checks.\n> > \n> > I\'m not very proficient in those templates, so I\'d like someone\n> > with more expertise there to update templates not to run those\n> > checks on trove stable/*.\n> \n> Any updates on that? Situation hasn\'t improved in a month. I wonder\n> whether Trove team even considers their stable branches as something\n> worth attention.\n> \n> Adding Nikhil to the thread.\n\nI had a review up i had thought would fix this which sat unloved for\nweeks, and then i see that my patch to stable is suddenly passing. So\ni\'m not sure what happened but it\'s passing again. \n\n\n> > \n> > Cheers, /Ihar\n> > \n> > [1]: \n> > https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml\n> >\n> > \n> [2]: https://review.openstack.org/#/c/98902/\n> > \n> > _______________________________________________ \n> > Openstack-stable-maint mailing list \n> > Openstack-stable-maint at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> >\n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n\n\n\n','<53C8EF2F.6090300@redhat.com>',NULL),('<1406179964.31596.129.camel@haakon3.risingtidesystems.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 22:32:44',-25200,'2014-07-24 05:32:44',NULL,'[openstack-dev] vhost-scsi support in Nova','Hi Nova folks,\n\nPlease let me address some of the outstanding technical points that have\nbeen raised recently within the following spec [1] for supporting vhost-scsi\n[2] within Nova.\n\nMike and Daniel have been going back and forth on various details, so I\nthought it might be helpful to open the discussion to a wider audience.\n\nFirst, some background.  I\'m the target (LIO) subsystem maintainer for the\nupstream Linux kernel, and have been one of the primary contributors in that\ncommunity for a number of years.  This includes the target-core subsystem,\nthe backend drivers that communicate with kernel storage subsystems, and a\nnumber of frontend fabric protocol drivers.\n\nvhost-scsi is one of those frontend fabric protocol drivers that has been\nincluded upstream, that myself and others have contributed to and improved\nover the past three years.  Given this experience and commitment to\nsupporting upstream code, I\'d like to address some of the specific points\nwrt vhost-scsi here.\n\n*) vhost-scsi doesn\'t support migration\n\nSince it\'s initial merge in QEMU v1.5, vhost-scsi has a migration blocker\nset.  This is primarily due to requiring some external orchestration in\norder to setup the necessary vhost-scsi endpoints on the migration\ndestination to match what\'s running on the migration source.\n\nHere are a couple of points that Stefan detailed some time ago about what\'s\ninvolved for properly supporting live migration with vhost-scsi:\n\n(1) vhost-scsi needs to tell QEMU when it dirties memory pages, either by\nDMAing to guest memory buffers or by modifying the virtio vring (which also\nlives in guest memory).  This should be straightforward since the\ninfrastructure is already present in vhost (it\'s called the \"log\") and used\nby drivers/vhost/net.c.\n\n(2) The harder part is seamless target handover to the destination host.\nvhost-scsi needs to serialize any SCSI target state from the source machine\nand load it on the destination machine.  We could be in the middle of\nemulating a SCSI command.\n\nAn obvious solution is to only support active-passive or active-active HA\nsetups where tcm already knows how to fail over.  This typically requires\nshared storage and maybe some communication for the clustering mechanism.\nThere are more sophisticated approaches, so this straightforward one is just\nan example.\n\nThat said, we do intended to support live migration for vhost-scsi using\niSCSI/iSER/FC shared storage.\n\n*) vhost-scsi doesn\'t support qcow2\n\nGiven all other cinder drivers do not use QEMU qcow2 to access storage\nblocks, with the exception of the Netapp and Gluster driver, this argument\nis not particularly relevant here.\n\nHowever, this doesn\'t mean that vhost-scsi (and target-core itself) cannot\nsupport qcow2 images.  There is currently an effort to add a userspace\nbackend driver for the upstream target (tcm_core_user [3]), that will allow\nfor supporting various disk formats in userspace.\n\nThe important part for vhost-scsi is that regardless of what type of target\nbackend driver is put behind the fabric LUNs (raw block devices using\nIBLOCK, qcow2 images using target_core_user, etc) the changes required in\nNova and libvirt to support vhost-scsi remain the same.  They do not change\nbased on the backend driver.\n\n*) vhost-scsi is not intended for production\n\nvhost-scsi has been included the upstream kernel since the v3.6 release, and\nincluded in QEMU since v1.5.  vhost-scsi runs unmodified out of the box on a\nnumber of popular distributions including Fedora, Ubuntu, and OpenSuse.  It\nalso works as a QEMU boot device with Seabios, and even with the Windows\nvirtio-scsi mini-port driver.\n\nThere is at least one vendor who has already posted libvirt patches to\nsupport vhost-scsi, so vhost-scsi is already being pushed beyond a debugging\nand development tool.\n\nFor instance, here are a few specific use cases where vhost-scsi is\ncurrently the only option for virtio-scsi guests:\n\n  - Low (sub 100 usec) latencies for AIO reads/writes with small iodepth\n    workloads\n  - 1M+ small block IOPs workloads at low CPU utilization with large\n    iopdeth workloads.\n  - End-to-end data integrity using T10 protection information (DIF)\n\nSo vhost-scsi can/will support essential features like live migration,\nqcow2, and the virtio-scsi data plane effort should not block existing\nalternatives already in upstream.\n\nWith that, we\'d like to see Nova officially support vhost-scsi because of\nits wide availability in the Linux ecosystem, and the considerable\nperformance, efficiency, and end-to-end data-integrity benefits that it\nalready brings to the table.\n\nWe are committed to addressing the short and long-term items for this\ndriver, and making it a success in Openstack Nova.\n\nThank you,\n\n--nab\n\n[1] https://review.openstack.org/#/c/103797/5/specs/juno/virtio-scsi-settings.rst\n[2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/vhost/scsi.c\n[3] http://www.spinics.net/lists/target-devel/msg07339.html\n\n\n\n',NULL,NULL),('<1406220049.2878.47.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 11:40:49',-18000,'2014-07-24 16:40:49',NULL,'[openstack-dev] [Nova] Question about thread safe of key-pair\n and securtiy rules quota','On Thu, 2014-07-24 at 14:04 +0800, Chen CH Ji wrote:\n> According to bug [1], there are some possibilities that concurrent\n> operations on keypair/security rules can exceed quota\n> Found that we have 3 kinds of resources in quotas.py:\n>  ReservableResource/AbsoluteResource/CountableResource\n> \n> curious about CountableResource because it\'s can\'t be thread safe due\n> to its logic:\n> \n> count = QUOTAS.count(context, \'security_group_rules\', id)\n> try:\n>             projected = count + len(vals)\n>             QUOTAS.limit_check(context,\n> security_group_rules=projected)\n> \n> was it designed by purpose to be different to ReservableResource? If\n> set it to ReservableResource just like RAM/CPU, what kind of side\n> effect it might lead to ?\n> \n> Also, is it possible to consider a solution like \'hold a write lock in\n> db layer, check the count of resource and raise exception if it exceed\n> quota\'? \n\nFirst, some background: the difference between a ReservableResource and\na CountableResource comes down to the method used to count the in-use\nresources.  For ReservableResource, the count is based on the number of\ndatabase objects matching the process ID, whereas with\nCountableResource, a counting function has to be specified; otherwise,\nthe classes are identical and designed to be used identically?indeed,\nCountableResource extends ReservableResource and only overrides the\nconstructor.  The only two CountableResource quota objects declared in\nNova are security_group_rules, where the counting function counts the\nrules per group; and key_pairs, where the counting function counts the\nkey pairs per user.\n\nNow, the code you paste in your email is the wrong code to use with a\nReservableResource or CountableResource; indeed, the limit_check()\ndocstring indicates that it\'s for those quotas for which there is no\nusage synchronization function?meaning an AbsoluteResource.  For\nReservableResource or CountableResource, the code should be using the\nreserve() method.  The reserve() method performs its checks safely, and\ncreates a reservation to prevent cross-process allocation that would\nresult in quota exceeded.  The downside is that reserve() must create a\nreservation that must later be committed or rolled back, which is\nprobably why that code is using the limit_check() inappropriately.\n\nIt may be worthwhile to add some sanity-checking to limit_check() and\nreserve() that ensure that they only work with the correct resource\ntype(s), in order to prevent this sort of problem from occurring in the\nfuture.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<OFE38F5EC1.54BA53C7-ON48257D1F.00203F32-48257D1F.0021B31C@cn.ibm.com>',NULL),('<1406240126.3094.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 22:15:31',0,'2014-07-24 22:15:31',NULL,'[openstack-dev] Thoughts on the patch test failure rate and\n moving forward','On Wed, 2014-07-23 at 14:39 -0700, James E. Blair wrote:\n> OpenStack has a substantial CI system that is core to its development\n> process.  The goals of the system are to facilitate merging good code,\n> prevent regressions, and ensure that there is at least one configuration\n> of upstream OpenStack that we know works as a whole.  The \"project\n> gating\" technique that we use is effective at preventing many kinds of\n> regressions from landing, however more subtle, non-deterministic bugs\n> can still get through, and these are the bugs that are currently\n> plaguing developers with seemingly random test failures.\n> \n> Most of these bugs are not failures of the test system; they are real\n> bugs.  Many of them have even been in OpenStack for a long time, but are\n> only becoming visible now due to improvements in our tests.  That\'s not\n> much help to developers whose patches are being hit with negative test\n> results from unrelated failures.  We need to find a way to address the\n> non-deterministic bugs that are lurking in OpenStack without making it\n> easier for new bugs to creep in.\n> \n> The CI system and project infrastructure are not static.  They have\n> evolved with the project to get to where they are today, and the\n> challenge now is to continue to evolve them to address the problems\n> we\'re seeing now.  The QA and Infrastructure teams recently hosted a\n> sprint where we discussed some of these issues in depth.  This post from\n> Sean Dague goes into a bit of the background: [1].  The rest of this\n> email outlines the medium and long-term changes we would like to make to\n> address these problems.\n> \n> [1] https://dague.net/2014/07/22/openstack-failures/\n> \n> ==Things we\'re already doing==\n> \n> The elastic-recheck tool[2] is used to identify \"random\" failures in\n> test runs.  It tries to match failures to known bugs using signatures\n> created from log messages.  It helps developers prioritize bugs by how\n> frequently they manifest as test failures.  It also collects information\n> on unclassified errors -- we can see how many (and which) test runs\n> failed for an unknown reason and our overall progress on finding\n> fingerprints for random failures.\n> \n> [2] http://status.openstack.org/elastic-recheck/\n> \n> We added a feature to Zuul that lets us manually \"promote\" changes to\n> the top of the Gate pipeline.  When the QA team identifies a change that\n> fixes a bug that is affecting overall gate stability, we can move that\n> change to the top of the queue so that it may merge more quickly.\n> \n> We added the clean check facility in reaction to the January gate break\n> down. While it does mean that any individual patch might see more tests\n> run on it, it\'s now largely kept the gate queue at a countable number of\n> hours, instead of regularly growing to more than a work day in\n> length. It also means that a developer can Approve a code merge before\n> tests have returned, and not ruin it for everyone else if there turned\n> out to be a bug that the tests could catch.\n> \n> ==Future changes==\n> \n> ===Communication===\n> We used to be better at communicating about the CI system.  As it and\n> the project grew, we incrementally added to our institutional knowledge,\n> but we haven\'t been good about maintaining that information in a form\n> that new or existing contributors can consume to understand what\'s going\n> on and why.\n> \n> We have started on a major effort in that direction that we call the\n> \"infra-manual\" project -- it\'s designed to be a comprehensive \"user\n> manual\" for the project infrastructure, including the CI process.  Even\n> before that project is complete, we will write a document that\n> summarizes the CI system and ensure it is included in new developer\n> documentation and linked to from test results.\n> \n> There are also a number of ways for people to get involved in the CI\n> system, whether focused on Infrastructure or QA, but it is not always\n> clear how to do so.  We will improve our documentation to highlight how\n> to contribute.\n> \n> ===Fixing Faster===\n> \n> We introduce bugs to OpenStack at some constant rate, which piles up\n> over time. Our systems currently treat all changes as equally risky and\n> important to the health of the system, which makes landing code changes\n> to fix key bugs slow when we\'re at a high reset rate. We\'ve got a manual\n> process of promoting changes today to get around this, but that\'s\n> actually quite costly in people time, and takes getting all the right\n> people together at once to promote changes. You can see a number of the\n> changes we promoted during the gate storm in June [3], and it was no\n> small number of fixes to get us back to a reasonably passing gate. We\n> think that optimizing this system will help us land fixes to critical\n> bugs faster.\n> \n> [3] https://etherpad.openstack.org/p/gatetriage-june2014\n> \n> The basic idea is to use the data from elastic recheck to identify that\n> a patch is fixing a critical gate related bug. When one of these is\n> found in the queues it will be given higher priority, including bubbling\n> up to the top of the gate queue automatically. The manual promote\n> process should no longer be needed, and instead bugs fixing elastic\n> recheck tracked issues will be promoted automatically.\n> \n> At the same time we\'ll also promote review on critical gate bugs through\n> making them visible in a number of different channels (like on elastic\n> recheck pages, review day, and in the gerrit dashboards). The idea here\n> again is to make the reviews that fix key bugs pop to the top of\n> everyone\'s views.\n> \n> ===Testing more tactically===\n> \n> One of the challenges that exists today is that we\'ve got basically 2\n> levels of testing in most of OpenStack: unit tests, and running a whole\n> OpenStack cloud. Over time we\'ve focused on adding more and more\n> configurations and tests to the latter, but as we\'ve seen, when things\n> fail in a whole OpenStack cloud, getting to the root cause is often\n> quite hard. So hard in fact that most people throw up their hands and\n> just run \'recheck\'. If a test run fails, and no one looks at why, does\n> it provide any value?\n> \n> We need to get to a balance where we are testing that OpenStack works as\n> a whole in some configuration, but as we\'ve seen, even our best and\n> brightest can\'t seem to make OpenStack reliably boot a compute that has\n> working networking 100% the time if we happen to be running more than 1\n> API request at once.\n> \n> Getting there is a multi party process:\n> \n>   * Reduce the gating configurations down to some gold standard\n>     configuration(s). This will be a small number of configurations that\n>     we all agree that everything will gate on. This means things like\n>     postgresql, cells, different environments will all get dropped from\n>     the gate as we know it.\n> \n>   * Put the burden for a bunch of these tests back on the projects as\n>     \"functional\" tests. Basically a custom devstack environment that a\n>     project can create with a set of services that they minimally need\n>     to do their job. These functional tests will live in the project\n>     tree, not in Tempest, so can be atomically landed as part of the\n>     project normal development process.\n\nWe do this in Solum and I really like it. It\'s nice for the same\nreviewers to see the functional tests and the code the implements a\nfeature.\n\nOne downside is we have had failures due to tempest reworking their\nclient code. This hasn\'t happened for a while, but it would be good\nfor tempest to recognize that people are using tempest as a library\nand will maintain API.\n\n-Angus\n\n> \n>   * For all non gold standard configurations, we\'ll dedicate a part of\n>     our infrastructure to running them in a continuous background loop,\n>     as well as making these configs available as experimental jobs. The\n>     idea here is that we\'ll actually be able to provide more\n>     configurations that are operating in a more traditional CI (post\n>     merge) context. People that are interested in keeping these bits\n>     functional can monitor those jobs and help with fixes when needed.\n>     The experimental jobs mean that if developers are concerned about\n>     the effect of a particular change on one of these configs, it\'s easy\n>     to request a pre-merge test run.  In the near term we might imagine\n>     this would allow for things like ceph, mongodb, docker, and possibly\n>     very new libvirt to be validated in some way upstream.\n> \n>   * Provide some kind of easy to view dashboards of these jobs, as well\n>     as a policy that if some job is failing for > some period of time,\n>     it\'s removed from the system. We want to provide whatever feedback\n>     we can to engaged parties, but people do need to realize that\n>     engagement is key. The biggest part of putting tests into OpenStack\n>     isn\'t landing the tests, but dealing with their failures.\n> \n>   * Encourage projects to specifically land interface tests in other\n>     projects when they depend on certain behavior.\n> \n> Let\'s imagine an example of how this works in the real world.\n> \n>   * The heat-slow job is deleted.\n> \n>   * The heat team creates a specific functional job which tests some of\n>     their deeper function in Heat, all the tests live in Heat, and\n>     because of these the tests can include white/grey box testing of the\n>     DB and queues while things are progressing.\n> \n>   * Nova lands a change which neither Tempest or our configs exercise,\n>     but breaks Heat.\n> \n>   * The Heat project can now decide if it\'s more important to keep the\n>     test in place (preventing them from landing code), or to skip it to\n>     get back to work.\n> \n>   * The Heat team then works on the right fix for Nova, or communicates\n>     with the Nova team on the issue at hand. The fix to Nova *also*\n>     should include tests which locks down that interface so that Nova\n>     won\'t break them again in the future (the ironic team did this with\n>     their test_ironic_contract patch). These tests could be unit tests,\n>     if they are testable that way, or functional tests in the Nova tree.\n> \n>   * The Heat team then is back in business.\n> \n> This approach brings more control of when a project is blocked back into\n> their own project. Tempest remains a final integration test to ensure\n> that basics of the whole stack work together, but each project has a\n> vertical testing stack which is specific to them as well.\n> \n> ==Final thoughts==\n> \n> The current rate of test failures and subsequent rechecks is not\n> sustainable in the long term.  It\'s not good for contributors,\n> reveiewers, or the overall project quality.  While these bugs do need to\n> be addressed, it\'s unlikely that the current process will cause that to\n> happen.  Instead, we want to push more substantial testing into the\n> projects themselves with functional and interface testing, and depend\n> less on devstack-gate integration tests to catch all bugs.  This should\n> help us catch bugs closer to the source and in an environment where\n> debugging is easier.  We also want to reduce the scope of devstack gate\n> tests to a gold standard while running tests of other configurations in\n> a traditional CI process so that people interested in those\n> configurations can focus on ensuring they work.\n> \n> Thanks,\n> \n> Jim and Sean\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140724/0dad1a12/attachment.pgp>\n\n','<87zjfzrbz0.fsf@shiprock.lan>',NULL),('<1406248056.3186.1.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 10:27:36',36000,'2014-07-25 00:27:36',NULL,'[openstack-dev] [Keystone] Removed admin role from admin\n user/tenant, can\'t add back','On Thu, 2014-07-24 at 22:44 +0000, Pendergrass, Eric wrote:\n> In an effort to test ceilometer roles I removed the admin role from\n> the admin tenant and user.  Now I can?t add it back since I don?t have\n> a user/tenant combo with the admin role:\n> \n>  \n> \n> keystone user-role-add --role e4252b63c308470b8cb7f77c37d27632 --user\n> 8c678720fb5b4e3bb18dee222d7d7933 --tenant\n> 9229d9ffed3d4fe2aa00d7575acd7ada\n> \n> You are not authorized to perform the requested action: admin_required\n> (Disable debug mode to suppress these details.) (HTTP 403)\n> \n>  \n> \n> Is there a way to do this in the mysql database if I know the\n> user/tenant/role IDs?  Or, is there another way with keystone client?\n\nYou could do it via the database, creating the role is simple enough to\nfollow via the other examples in the role table. Then follow the other\nexamples in the assignment table to assign the role to a user to\nassociate user with role on project.\n\nThe easier way would be to use the admin_token you can define in\nkeystone.conf and you should have the permissions required to recreate\neverything via the CLI. \n\nJamie \n\n> \n> Thanks,\n> \n> Eric\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<C6171E2331108F4EBD0E92AB5A04CD877049059F@G4W3220.americas.hpqcorp.net>',NULL),('<1406262989.7919.7.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 23:36:29',-18000,'2014-07-25 04:36:29',NULL,'[openstack-dev] Mentor program?','Josh,\n\nI agree that the mailing list is a hard place to provide such guidance\nand direction.  I find mailing lists intimidating.  Had taken me some\ntime to be comfortable submitting here.\n\nAfter my response to this note the other day I was pinged internally via\nour messaging client asking for some mentoring.  They seemed more\ncomfortable introducing themselves that way and talking.  I hate to\nsuggest an IRC channel for this, as IRC drives me nuts, also doesn\'t\nseem the best fit.  Maybe instead a wiki page with IRC names of people\nthat are willing to be individually contacted with requests for\nguidance.  I could be listed as a contact for Cinder or i18n as well as\na general process contact.  You for taskflow, etc.\n\nI guess a way to communicate what we feel we can help with and provide\nthat as a resource for those who may need help in those areas.  Also, on\nthe same wiki maybe try to cull together some of the \'getting started\ninfo.  \n\nWhat do you think?\n\nJay\n\nOn Wed, 2014-07-23 at 15:42 -0700, Joshua Harlow wrote:\n> Awesome,\n> \n> \n> When I start to see emails on ML that say anyone need any help for\n> XYZ ... (which is great btw) it makes me feel like there should be a\n> more appropriate avenue for those inspirational folks looking to get\n> involved (a ML isn\'t really the best place for this kind of guidance\n> and directing). \n> \n> \n> And in general mentoring will help all involved if we all do more of\n> it :-)\n> \n> \n> Let me know if any thing is needed that I can possible help with to\n> get more of it going.\n> \n> \n> -Josh\n> \n> On Jul 23, 2014, at 2:44 PM, Jay Bryant\n> <jsbryant at electronicjungle.net> wrote:\n> \n> > Great question Josh!\n> > \n> > Have been doing a lot of mentoring within IBM for OpenStack and have\n> > now been asked to formalize some of that work.  Not surprised there\n> > is an external need as well.\n> > \n> > Anne and Stefano.  Let me know if the kids anything I can do to\n> > help.\n> > \n> > Jay\n> > \n> > Hi all,\n> > \n> > I was reading over a IMHO insightful hacker news thread last night:\n> > \n> > https://news.ycombinator.com/item?id=8068547\n> > \n> > Labeled/titled: \'I made a patch for Mozilla, and you can do it too\'\n> > \n> > It made me wonder what kind of mentoring support are we as a\n> > community offering to newbies (a random google search for \'openstack\n> > mentoring\' shows mentors for GSoC, mentors for interns, outreach for\n> > women... but no mention of mentors as a way for everyone to get\n> > involved)?\n> > \n> > Looking at the comments in that hacker news thread, the article\n> > itself it seems like mentoring is stressed over and over as the way\n> > to get involved.\n> > \n> > Has there been ongoing efforts to establish such a program (I know\n> > there is training work that has been worked on, but that\'s not\n> > exactly the same).\n> > \n> > Thoughts, comments...?\n> > \n> > -Josh\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n\n\n\n\n','<BLU436-SMTP517E318A7B6B8FAD603240D8FF0@phx.gbl>',NULL),('<1406276313.1057.125.camel@haakon3.risingtidesystems.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 01:18:33',-25200,'2014-07-25 08:18:33',NULL,'[openstack-dev] vhost-scsi support in Nova','On Thu, 2014-07-24 at 11:06 +0100, Daniel P. Berrange wrote:\n> On Wed, Jul 23, 2014 at 10:32:44PM -0700, Nicholas A. Bellinger wrote:\n> > *) vhost-scsi doesn\'t support migration\n> > \n> > Since it\'s initial merge in QEMU v1.5, vhost-scsi has a migration blocker\n> > set.  This is primarily due to requiring some external orchestration in\n> > order to setup the necessary vhost-scsi endpoints on the migration\n> > destination to match what\'s running on the migration source.\n> > \n> > Here are a couple of points that Stefan detailed some time ago about what\'s\n> > involved for properly supporting live migration with vhost-scsi:\n> > \n> > (1) vhost-scsi needs to tell QEMU when it dirties memory pages, either by\n> > DMAing to guest memory buffers or by modifying the virtio vring (which also\n> > lives in guest memory).  This should be straightforward since the\n> > infrastructure is already present in vhost (it\'s called the \"log\") and used\n> > by drivers/vhost/net.c.\n> > \n> > (2) The harder part is seamless target handover to the destination host.\n> > vhost-scsi needs to serialize any SCSI target state from the source machine\n> > and load it on the destination machine.  We could be in the middle of\n> > emulating a SCSI command.\n> > \n> > An obvious solution is to only support active-passive or active-active HA\n> > setups where tcm already knows how to fail over.  This typically requires\n> > shared storage and maybe some communication for the clustering mechanism.\n> > There are more sophisticated approaches, so this straightforward one is just\n> > an example.\n> > \n> > That said, we do intended to support live migration for vhost-scsi using\n> > iSCSI/iSER/FC shared storage.\n> > \n> > *) vhost-scsi doesn\'t support qcow2\n> > \n> > Given all other cinder drivers do not use QEMU qcow2 to access storage\n> > blocks, with the exception of the Netapp and Gluster driver, this argument\n> > is not particularly relevant here.\n> > \n> > However, this doesn\'t mean that vhost-scsi (and target-core itself) cannot\n> > support qcow2 images.  There is currently an effort to add a userspace\n> > backend driver for the upstream target (tcm_core_user [3]), that will allow\n> > for supporting various disk formats in userspace.\n> > \n> > The important part for vhost-scsi is that regardless of what type of target\n> > backend driver is put behind the fabric LUNs (raw block devices using\n> > IBLOCK, qcow2 images using target_core_user, etc) the changes required in\n> > Nova and libvirt to support vhost-scsi remain the same.  They do not change\n> > based on the backend driver.\n> > \n> > *) vhost-scsi is not intended for production\n> > \n> > vhost-scsi has been included the upstream kernel since the v3.6 release, and\n> > included in QEMU since v1.5.  vhost-scsi runs unmodified out of the box on a\n> > number of popular distributions including Fedora, Ubuntu, and OpenSuse.  It\n> > also works as a QEMU boot device with Seabios, and even with the Windows\n> > virtio-scsi mini-port driver.\n> > \n> > There is at least one vendor who has already posted libvirt patches to\n> > support vhost-scsi, so vhost-scsi is already being pushed beyond a debugging\n> > and development tool.\n> > \n> > For instance, here are a few specific use cases where vhost-scsi is\n> > currently the only option for virtio-scsi guests:\n> > \n> >   - Low (sub 100 usec) latencies for AIO reads/writes with small iodepth\n> >     workloads\n> >   - 1M+ small block IOPs workloads at low CPU utilization with large\n> >     iopdeth workloads.\n> >   - End-to-end data integrity using T10 protection information (DIF)\n> \n> IIUC, there is also missing support for block jobs like drive-mirror\n> which is needed by Nova.\n> \n\nThis limitation can be considered an acceptable trade-off in initial\nsupport by some users, given the already considerable performance +\nefficiency gains that vhost logic provides to KVM/virtio guests.\n\nOthers would like to utilize virtio-scsi to access features like SPC-3\nPersistent Reservations, ALUA Explicit/Implicit Multipath, and\nEXTENDED_COPY offload provided by the LIO target subsystem.\n\nNote these three SCSI features are enabled (by default) on all LIO\ntarget fabric LUNs, starting with v3.12 kernel code.\n\n> From a functionality POV migration & drive-mirror support are the two\n> core roadblocks to including vhost-scsi in Nova (as well as libvirt\n> support for it of course). Realistically it doesn\'t sound like these\n> are likely to be solved soon enough to give us confidence in taking\n> this for the Juno release cycle.\n> \n\nThe spec is for initial support of vhost-scsi controller endpoints\nduring Juno, and as mentioned earlier by Vish, should be considered a\nexperimental feature given caveats you\'ve highlighted above.\n\nWe also understand that code will ultimately have to pass Nova + libvirt\nupstream review in order to be merged, and that the approval of any\nvhost-scsi spec now is not a guarantee the feature will actually make it\ninto any official Juno release.\n\nThanks,\n\n--nab\n\n\n\n','<20140724100656.GD23477@redhat.com>',NULL),('<1406276350.1057.126.camel@haakon3.risingtidesystems.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 01:19:10',-25200,'2014-07-25 08:19:10',NULL,'[openstack-dev] vhost-scsi support in Nova','On Thu, 2014-07-24 at 11:06 +0100, Daniel P. Berrange wrote:\n> On Wed, Jul 23, 2014 at 10:32:44PM -0700, Nicholas A. Bellinger wrote:\n> > *) vhost-scsi doesn\'t support migration\n> > \n> > Since it\'s initial merge in QEMU v1.5, vhost-scsi has a migration blocker\n> > set.  This is primarily due to requiring some external orchestration in\n> > order to setup the necessary vhost-scsi endpoints on the migration\n> > destination to match what\'s running on the migration source.\n> > \n> > Here are a couple of points that Stefan detailed some time ago about what\'s\n> > involved for properly supporting live migration with vhost-scsi:\n> > \n> > (1) vhost-scsi needs to tell QEMU when it dirties memory pages, either by\n> > DMAing to guest memory buffers or by modifying the virtio vring (which also\n> > lives in guest memory).  This should be straightforward since the\n> > infrastructure is already present in vhost (it\'s called the \"log\") and used\n> > by drivers/vhost/net.c.\n> > \n> > (2) The harder part is seamless target handover to the destination host.\n> > vhost-scsi needs to serialize any SCSI target state from the source machine\n> > and load it on the destination machine.  We could be in the middle of\n> > emulating a SCSI command.\n> > \n> > An obvious solution is to only support active-passive or active-active HA\n> > setups where tcm already knows how to fail over.  This typically requires\n> > shared storage and maybe some communication for the clustering mechanism.\n> > There are more sophisticated approaches, so this straightforward one is just\n> > an example.\n> > \n> > That said, we do intended to support live migration for vhost-scsi using\n> > iSCSI/iSER/FC shared storage.\n> > \n> > *) vhost-scsi doesn\'t support qcow2\n> > \n> > Given all other cinder drivers do not use QEMU qcow2 to access storage\n> > blocks, with the exception of the Netapp and Gluster driver, this argument\n> > is not particularly relevant here.\n> > \n> > However, this doesn\'t mean that vhost-scsi (and target-core itself) cannot\n> > support qcow2 images.  There is currently an effort to add a userspace\n> > backend driver for the upstream target (tcm_core_user [3]), that will allow\n> > for supporting various disk formats in userspace.\n> > \n> > The important part for vhost-scsi is that regardless of what type of target\n> > backend driver is put behind the fabric LUNs (raw block devices using\n> > IBLOCK, qcow2 images using target_core_user, etc) the changes required in\n> > Nova and libvirt to support vhost-scsi remain the same.  They do not change\n> > based on the backend driver.\n> > \n> > *) vhost-scsi is not intended for production\n> > \n> > vhost-scsi has been included the upstream kernel since the v3.6 release, and\n> > included in QEMU since v1.5.  vhost-scsi runs unmodified out of the box on a\n> > number of popular distributions including Fedora, Ubuntu, and OpenSuse.  It\n> > also works as a QEMU boot device with Seabios, and even with the Windows\n> > virtio-scsi mini-port driver.\n> > \n> > There is at least one vendor who has already posted libvirt patches to\n> > support vhost-scsi, so vhost-scsi is already being pushed beyond a debugging\n> > and development tool.\n> > \n> > For instance, here are a few specific use cases where vhost-scsi is\n> > currently the only option for virtio-scsi guests:\n> > \n> >   - Low (sub 100 usec) latencies for AIO reads/writes with small iodepth\n> >     workloads\n> >   - 1M+ small block IOPs workloads at low CPU utilization with large\n> >     iopdeth workloads.\n> >   - End-to-end data integrity using T10 protection information (DIF)\n> \n> IIUC, there is also missing support for block jobs like drive-mirror\n> which is needed by Nova.\n> \n\nThis limitation can be considered an acceptable trade-off in initial\nsupport by some users, given the already considerable performance +\nefficiency gains that vhost logic provides to KVM/virtio guests.\n\nOthers would like to utilize virtio-scsi to access features like SPC-3\nPersistent Reservations, ALUA Explicit/Implicit Multipath, and\nEXTENDED_COPY offload provided by the LIO target subsystem.\n\nNote these three SCSI features are enabled (by default) on all LIO\ntarget fabric LUNs, starting with v3.12 kernel code.\n\n> From a functionality POV migration & drive-mirror support are the two\n> core roadblocks to including vhost-scsi in Nova (as well as libvirt\n> support for it of course). Realistically it doesn\'t sound like these\n> are likely to be solved soon enough to give us confidence in taking\n> this for the Juno release cycle.\n> \n\nThe spec is for initial support of vhost-scsi controller endpoints\nduring Juno, and as mentioned earlier by Vish, should be considered a\nexperimental feature given caveats you\'ve highlighted above.\n\nWe also understand that code will ultimately have to pass Nova + libvirt\nupstream review in order to be merged, and that the approval of any\nvhost-scsi spec now is not a guarantee the feature will actually make it\ninto any official Juno release.\n\nThanks,\n\n--nab\n\n\n\n\n','<20140724100656.GD23477@redhat.com>',NULL),('<1406281625.4814.73.camel@haakon3.risingtidesystems.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 02:47:05',-25200,'2014-07-25 09:47:05',NULL,'[openstack-dev] [nova] vhost-scsi support in Nova','Hey Stefan,\n\nOn Thu, 2014-07-24 at 21:50 +0100, Stefan Hajnoczi wrote:\n> On Thu, Jul 24, 2014 at 7:45 PM, Vishvananda Ishaya\n> <vishvananda at gmail.com> wrote:\n> > As I understand this work, vhost-scsi provides massive perf improvements\n> > over virtio, which makes it seem like a very valuable addition. I?m ok\n> > with telling customers that it means that migration and snapshotting are\n> > not supported as long as the feature is protected by a flavor type or\n> > image metadata (i.e. not on by default). I know plenty of customers that\n> > would gladly trade some of the friendly management features for better\n> > i/o performance.\n> >\n> > Therefore I think it is acceptable to take it with some documentation that\n> > it is experimental. Maybe I?m unique but I deal with people pushing for\n> > better performance all the time.\n> \n> Work to make userspace virtio-scsi scale well on multicore hosts has\n> begun.  I\'m not sure there will be a large IOPS scalability difference\n> between the two going forward.  I have CCed Fam Zheng who is doing\n> this.\n\nThe latency and efficiency gains with existing vhost-scsi vs.\nvirtio-scsi (minus data-plane) are pretty significant, even when a\nsingle queue per virtio controller is used.\n\nNote the sub 100 usec latencies we\'ve observed with fio random 4k\niodepth=1 workloads are with vhost exposing guest I/O buffer memory as a\nzero-copy direct data placement sink for remote RDMA WRITEs. \n\nAlso, average I/O Latency is especially low when the guest is capable of\nutilizing a blk-mq based virtio guest driver.  For the best possible\nresults in KVM guest, virtio-scsi will want to be utilize the upcoming\nscsi-mq support in Linux, that will greatly benefit both QEMU data-plane\nand vhost-scsi type approaches of SCSI target I/O submission.\n\n> \n> In virtio-blk vs vhost-blk a clear performance difference was never\n> observed.  At the end of the day, the difference is whether a kernel\n> thread or a userspace thread submits the aio request.  virtio-blk\n> efforts remain focussed on userspace where ease of migration,\n> management, and lower security risks are favorable.\n> \n\nAll valid points, no disagreement here.\n\n> I guess virtio-scsi will play out the same way, which is why I stopped\n> working on vhost-scsi.  If others want to do the work to integrate\n> vhost-scsi (aka tcm_vhost), that\'s great.  Just don\'t expect that\n> performance will make the effort worthwhile.  The real difference\n> between the two is that the in-kernel target is a powerful and\n> configurable SCSI target, whereas the userspace QEMU target is\n> focussed on emulating SCSI commands without all the configuration\n> goodies.\n\nUnderstood.\n\nAs mentioned, we\'d like the Nova folks to consider vhost-scsi support as\na experimental feature for the Juno release of Openstack, given the\nknown caveats.\n\nThanks for your comments!\n\n--nab\n\n\n\n','<CAJSP0QWBDGQ_wJEK5Zf2FXXaPqzKbx5uAYgQJYW_f_NTpKKftA@mail.gmail.com>',NULL),('<1406298124.2702.61.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-07-25 15:22:04',3600,'2014-07-25 14:22:04',NULL,'[openstack-tc] May miss the next two meetings','I\'m about to head off on two weeks vacation. I might be silly enough to\njoin the late-night TC meetings, but I doubt it :)\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1406304349-sup-995@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 09:39:06',-25200,'2014-07-25 16:39:06',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','Excerpts from John Griffith\'s message of 2014-07-25 06:59:38 -0700:\n> On Fri, Jul 25, 2014 at 7:38 AM, Kerrin, Michael <michael.kerrin at hp.com>\n> wrote:\n> \n> > Coming back to this.\n> >\n> > I have updated the review https://review.openstack.org/#/c/90134/ so that\n> > it passing CI for ubuntu (obviously failing on fedora) and I am happy with\n> > it. In order to close this off my plan is to getting feedback on the mysql\n> > element in this review. Any changes that people request in the next few\n> > days I will make and test via the CI and internally. Next I will rename\n> > mysql -> percona and restore the old mysql in this review. At which point\n> > the percona code will not be tested via CI so I don\'t want to make any more\n> > changes at that point so I hope it will get approved. So this review will\n> > move to adding a percona element.\n> >\n> > Then following the mariadb integration I would like to get this\n> > https://review.openstack.org/#/c/109415/ change to tripleo-incubator\n> > through that will include the new percona element in ubuntu images. So in\n> > the CI fedora will us mariadb and ubuntu will use percona.\n> >\n> > Looking forward to any feedback,\n> >\n> > Michael\n> >\n> >\n> > On 09 July 2014 14:44:15, Sullivan, Jon Paul wrote:\n> >\n> >> -----Original Message-----\n> >>> From: Giulio Fidente [mailto:gfidente at redhat.com]\n> >>> Sent: 04 July 2014 14:37\n> >>> To: OpenStack Development Mailing List (not for usage questions)\n> >>> Subject: Re: [openstack-dev] [TripleO] Use MariaDB by default on Fedora\n> >>>\n> >>> On 07/01/2014 05:47 PM, Michael Kerrin wrote:\n> >>>\n> >>>> I propose making mysql an abstract element and user must choose either\n> >>>> percona or mariadb-rpm element.CI must be setup correctly\n> >>>>\n> >>>\n> >>> +1\n> >>>\n> >>> seems a cleaner and more sustainable approach\n> >>>\n> >>\n> >> There was some concern from lifeless around recreating package-style\n> >> dependencies in dib with element-provides/element-deps, in particular a\n> >> suggestion that meta-elements are not desirable[1] (I hope I am\n> >> paraphrasing you correctly Rob).\n> >>\n> >> That said, this is exactly the reason that element-provides was brought\n> >> in, so that the definition of the image could have \"mysql\" as an element,\n> >> but that the DIB_*_EXTRA_ARGS variable would provide the correct one, which\n> >> would then list itself as providing mysql.\n> >>\n> >> This would not prevent the sharing of common code through a\n> >> differently-named element, such as mysql-common.\n> >>\n> >>\n> >> [1] see comments on April 10th in https://review.openstack.org/#/c/85776/\n> >>\n> >>  --\n> >>> Giulio Fidente\n> >>> GPG KEY: 08D733BA\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>\n> >> Thanks,\n> >> Jon-Paul Sullivan ? Cloud Services - @hpcloud\n> >>\n> >> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park,\n> >> Galway.\n> >> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John\n> >> Rogerson\'s Quay, Dublin 2.\n> >> Registered Number: 361933\n> >>\n> >> The contents of this message and any attachments to it are confidential\n> >> and may be legally privileged. If you have received this message in error\n> >> you should delete it from your system immediately and advise the sender.\n> >>\n> >> To any recipient of this message within HP, unless otherwise stated, you\n> >> should consider this message and attachments as \"HP CONFIDENTIAL\".\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> ?So this all sounds like an interesting mess.  I\'m not even really sure I\n> follow all that\'s going on in the database area with the exception of the\n> design which it seems is something that takes no account for testing or\n> commonality across platforms (pretty bad IMO) but I don\'t have any insight\n> there so I\'ll butt out.\n> \n> The LIO versus Tgt thing however is a bit troubling.  Is there a reason\n> that TripleO decided to do the exact opposite of what the defaults are in\n> the rest of OpenStack here?  Also any reason why if there was a valid\n> justification for this it didn\'t seem like it might be worthwhile to work\n> with the rest of the OpenStack community and share what they considered to\n> be the better solution here?\n> \n\nJohn, please be specific when you say \"the defaults are in the rest of\nOpenStack\". We have a stated goal to deploy _with the defaults_. The\ndefault iscsi_helper is tgtadmin. We deploy with that unless another is\nselected. As you see below, nothing is asserted there unless a value is\nset:\n\nhttps://git.openstack.org/cgit/openstack/tripleo-image-elements/tree/elements/cinder/os-apply-config/etc/cinder/cinder.conf#n41\n\nAnd the default in the Heat templates that will set that value matches\ncinder\'s current default:\n\nhttps://git.openstack.org/cgit/openstack/tripleo-heat-templates/tree/overcloud-source.yaml#n21\n\nhttp://git.openstack.org/cgit/openstack/cinder/tree/etc/cinder/cinder.conf.sample#n1017\n\nLIO is used on RHEL, because RHEL doesn\'t offer TGT. So what is \"the LIO\nversus Tgt thing?\n\n> Sorry, I just haven\'t swallowed the TripleO pill.  We seem to have taken\n> the problem of \"how to make it easier to install OpenStack\" and turned it\n> into as complex and difficult a thing as possible.  Hey... it\'s hard to\n> deploy and manage a cloud; have two!  By the way, we did everything\n> differently here than anywhere else so everything you thought you knew,\n> still need it but won\'t help you here.. best of luck to you.\n\nHaving two clouds, one for deployment, and one (or \"n\") for tenants,\nisn\'t a core part of the design, it is a workaround for the scheduler\nproblems we saw early on. As I understand it, those have been solved\nand there is a desire to have a single-cloud TripleO soon.\n\nHowever, some see it as a feature, since direct access to the hardware\ncontrol plane is a sensitive thing, and having an entirely separate\nkeystone for that is attractive _to some_.\n\nThe problem of how to make it _easier_ is not the stated goal of TripleO.\n\n>From https://wiki.openstack.org/wiki/TripleO:\n\n\"TripleO is a program aimed at installing, upgrading and operating\nOpenStack clouds using OpenStack\'s own cloud facilities as the foundations\n- building on nova, neutron and heat to automate fleet management at\ndatacentre scale (and scaling down to as few as 2 machines).\"\n\nNobody expects datacenter scale to be easy. We do, however, have a\nreasonable expectation that OpenStack can be used to deploy large,\ncomplex applications. If it cannot, OpenStack is in trouble.\n\nThe bits where we use tools that aren\'t traditional is also not the\npoint of TripleO. We are being tool agnostic so as to not alienate any\none community from OpenStack as a whole.\n\nI personally fought against more options in TripleO early on, and that was\na mistake. It has become clear to me that having packages as an option has\nenabled our friends at RedHat to participate in the virtuous circle and\nimprove OpenStack as a whole for deploying large applications while they\nwork on the TripleO deployment story. They can do this without having to\n\"swallow the TripleO pill\". There are multiple pills, and they\'ve opted\nout of a few of them and cut a few in half. If they can do it, I think\nanybody can. But nobody is trying to recruit you.. I just want to make\nit clear that we\'ve learned our lesson (I think) and are quite amenable\nto alternatives, *if* they are presented in a consumable fashion.\n\n\n','<CA+qL3LWfxtZgxhmVYCcDB8gYyL3_2DiGLre1FawD+Ufyw6__fw@mail.gmail.com>',NULL),('<1406311198566.98181@tesora.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-07-25 18:00:29',0,'2014-07-25 18:00:29',NULL,'[Openstack-docs] How to tell Oxygen to use rackbook.rng?','Anne, I opened the section_cinder-controller file (without using the validation button) and I seem to get the same error as you do -- see attached screenshot, laurels_error_msg.png.\n\nIt looks like Oxygen wants to use a the docbookxi.rng file located in this dir on my system:\n\nC:\\Program Files (x86)\\Oxygen XML Author 16\\frameworks\\docbook\\5.0\\rng\n\nSo maybe replace the contents of that docbookxi.rng with the contents of the rackbook.rng file, so Oxygen uses whatever we have in rackbook.rng?\n\n\n________________________________\nFrom: annegentle at justwriteclick.com <annegentle at justwriteclick.com> on behalf of Anne Gentle <anne at openstack.org>\nSent: Friday, July 25, 2014 8:52 AM\nTo: Andreas Jaeger\nCc: Laurel Michaels; openstack-docs at lists.openstack.org\nSubject: Re: [Openstack-docs] How to tell Oxygen to use rackbook.rng?\n\n\n\n\nOn Fri, Jul 25, 2014 at 1:37 AM, Andreas Jaeger <aj at suse.com<mailto:aj at suse.com>> wrote:\nOn 07/24/2014 11:43 PM, Anne Gentle wrote:\n> Hi all,\n> I\'ve been trying to help Laurel with the problem for a while now. The\n> root need here is that we can all use a common .ent file for entity\n> references like &mdash; -- which is a great goal -- without having to\n> add any references in headers (since we\'ve standardized nicely on\n> headers that don\'t refer to an RNG file).\n>\n> In my environment, I\'ve never had to reference the RNG file at all. When\n> I use Oxygen on my Mac to refer to the rackbook.rng that\'s maintained in\n> the doc tools repo, validation errors occur.\n>\n> One of my working theories is that the latest change to rackbook.rng for\n> the tooling actually broke authoring for\n> some. https://review.openstack.org/#/c/104085/\n\n\nThis patch to openstack-doc-tools is the same as we always had setup\nrackbook.rng inside openstack-doc-tools - my previous import just forgot\nto make this local change. This change is essential for working of the\ntoolchain. This was essential our last \".1\" urgent release where\neverything was broken without it.\n\nto check your theory:\nThe rackbook.rng comes from clouddocs-maven-plugin, could you point it\nlocally there? Does that help?\n\nOn my machine, if I do what Laurel\'s doing, by validating with a button in the toolbar, I see errors.\n\nIf I just open a file, and look at any validation errors, I see that it\'s point to a local rackbook.rng file. See attached.\n\nSo I think she shouldn\'t validate the way she is, and there\'s something we have to set up with Oxygen to use the rackbook.rng file locally. I\'ll keep digging into Oxygen\'s help files for more.\n\nLaurel, see the attached screenshot and try to get a shot of your system so we can compare. I got it by clicking on the \"known\" validation \'error\' for an xml:id that doesn\'t exist in the file itself but is in the larger book. Try opening\ndoc/install-guide/section_cinder-controller.xml</Users/annegentle/src/openstack-manuals/doc/install-guide/section_cinder-controller.xml>\n and let us know what you see.\n\n\nAndreas\n--\n Andreas Jaeger aj@{suse.com<http://suse.com>,opensuse.org<http://opensuse.org>} Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140725/a73b975e/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: laurels_error_msg.png\nType: image/png\nSize: 19744 bytes\nDesc: laurels_error_msg.png\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140725/a73b975e/attachment-0001.png>\n\n','<CAD0KtVEHyBZMCnmjUVGiDP0BOYkmFZKHnnbW148cw7m9rtQrOw@mail.gmail.com>',NULL),('<1406314104-sup-7254@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 11:50:50',-25200,'2014-07-25 18:50:50',NULL,'[openstack-dev] [heat]Heat Db Model updates','Excerpts from Zane Bitter\'s message of 2014-07-24 12:09:39 -0700:\n> On 17/07/14 07:51, Ryan Brown wrote:\n> > On 07/17/2014 03:33 AM, Steven Hardy wrote:\n> >> On Thu, Jul 17, 2014 at 12:31:05AM -0400, Zane Bitter wrote:\n> >>> On 16/07/14 23:48, Manickam, Kanagaraj wrote:\n> >>>> SNIP\n> >>>> *Resource*\n> >>>>\n> >>>> Status & action should be enum of predefined status\n> >>>\n> >>> +1\n> >>>\n> >>>> Rsrc_metadata - make full name resource_metadata\n> >>>\n> >>> -0. I don\'t see any benefit here.\n> >>\n> >> Agreed\n> >\n> >\n> > I\'d actually be in favor of the change from rsrc->resource, I feel like\n> > rsrc is a pretty opaque abbreviation.\n> \n> I\'d just like to remind everyone that these changes are not free. \n> Database migrations are a pain to manage, and every new one slows down \n> our unit tests.\n> \n> We now support multiple heat-engines connected to the same database and \n> people want to upgrade their installations, so that means we have to be \n> able to handle different versions talking to the same database. Unless \n> somebody has a bright idea I haven\'t thought of, I assume that means \n> carrying code to handle both versions for 6 months before actually being \n> able to implement the migration. Or are we saying that you have to \n> completely shut down all instances of Heat to do an upgrade?\n> \n> The name of the \"nova_instance\" column is so egregiously misleading that \n> it\'s probably worth the pain. Using an enumeration for the states will \n> save a lot of space in the database (though it would be a much more \n> obvious win if we were querying on those columns). Changing a random \n> prefix that was added to avoid a namespace conflict to a slightly \n> different random prefix is well below the cost-benefit line IMO.\n\nIn past lives managing apps like Heat, We\'ve always kept supporting the\nprevious schema in new code versions. So the process is:\n\n* Upgrade all code\n* Restart all services\n* Upgrade database schema\n* Wait a bit for reverts\n* Remove backward compatibility\n\nNow this was always in more of a continuous delivery environment, so\nthere was not more than a few weeks of waiting for reverts. In OpenStack\nwe\'d have a single release to wait.\n\nWe\'re not special though, doesn\'t Nova have some sort of object versioning\ncode that helps them manage the versions of each type of data for this\nvery purpose?\n\n\n','<53D159F3.1020904@redhat.com>',NULL),('<1406324329.7539.145764153.6B66F15A@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-25 14:38:49',-25200,'2014-07-25 21:38:49',NULL,'[openstack-dev] [ALL] Removing the tox==1.6.1 pin','Hello,\n\nThe recent release of tox 1.7.2 has fixed the {posargs} interpolation\nissues we had with newer tox which forced us to be pinned to tox==1.6.1.\nBefore we can remove the pin and start telling people to use latest tox\nwe need to address a new default behavior in tox.\n\nNew tox sets a random PYTHONHASHSEED value by default. Arguably this is\na good thing as it forces you to write code that handles unknown hash\nseeds, but unfortunately many projects\' unittests don\'t currently deal\nwith this very well. A work around is to hard set a PYTHONHASHSEED of 0\nin tox.ini files. I have begun to propose these changes to the projects\nthat I have tested and found to not handle random seeds. It would be\ngreat if we could get these reviewed and merged so that infra can update\nthe version of tox used on our side.\n\nI probably won\'t be able to test every single project and propose fixes\nwith backports to stable branches for everything. It would be a massive\nhelp if individual projects tested and proposed fixes as necessary too\n(these changes will need to be backported to stable branches). You can\ntest by running `tox -epy27` in your project with tox version 1.7.2. If\nthat fails add PYTHONHASHSEED=0 as in\nhttps://review.openstack.org/#/c/109700/ and rerun `tox -epy27` to\nconfirm that succeeds.\n\nThis will get us over the immediate hump of the tox upgrade, but we\nshould also start work to make our tests run with random hashes. This\nshouldn\'t be too hard to do as it will be a self gating change once\ninfra is able to update the version of tox used in the gate. Most of the\nissues appear related to dict entry ordering. I have gone ahead and\ncreated https://bugs.launchpad.net/cinder/+bug/1348818 to track this\nwork.\n\nThank you,\nClark\n\n\n',NULL,NULL),('<1406422308.13791.11.camel@graham-work-laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-27 00:51:48',0,'2014-07-27 00:51:48',NULL,'[openstack-dev] [tc][rally][qa] Application for a new OpenStack\n Program: Performance and Scalability','On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote:\n> On 07/22/2014 11:58 AM, David Kranz wrote:\n> > On 07/22/2014 10:44 AM, Sean Dague wrote:\n> >> Honestly, I\'m really not sure I see this as a different program, but is\n> >> really something that should be folded into the QA program. I feel like\n> >> a top level effort like this is going to lead to a lot of duplication in\n> >> the data analysis that\'s currently going on, as well as functionality\n> >> for better load driver UX.\n> >>\n> >> 	-Sean\n> > +1\n> > It will also lead to pointless discussions/arguments about which\n> > activities are part of \"QA\" and which are part of\n> > \"Performance and Scalability Testing\".\n\nI think that those discussions will still take place, it will just be on\na per repository basis, instead of a per program one.\n\n[snip]\n\n> \n> Right, 100% agreed. Rally would remain with it\'s own repo + review team,\n> just like grenade.\n> \n> 	-Sean\n> \n\nIs the concept of a separate review team not the point of a program?\n\nIn the the thread from Designate\'s Incubation request Thierry said [1]:\n\n> \"Programs\" just let us bless goals and teams and let them organize \n> code however they want, with contribution to any code repo under that\n> umbrella being considered \"official\" and ATC-status-granting.\n        \nI do think that this is something that needs to be clarified by the TC -\nRally could not get a PTL if they were part of the QA project, but every\ntime we get a program request, the same discussion happens.\n\nI think that mission statements can be edited to fit new programs as\nthey occur, and that it is more important to let teams that have been\nworking closely together to stay as a distinct group.\n\nGraham\n\n1 -\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-May/036213.html\n\n','<53CE8ECB.4010200@dague.net>',NULL),('<1406512926806.cab3c0bc@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-27 19:02:07',-25200,'2014-07-28 02:02:07',NULL,'[openstack-dev] [Neutron] [Spec freeze exception] Support\n Stateful and Stateless DHCPv6 by dnsmasq','Thanks Kyle and everyone for supporting this! Will try the best to make the code ready for Juno-3.\n\n\nXu Han?\n?\nSent from Mailbox for iPhone\n\nOn Fri, Jul 25, 2014 at 11:06 PM, Kyle Mestery <mestery at mestery.com>\nwrote:\n\n> On Thu, Jul 24, 2014 at 8:46 PM, CARVER, PAUL <pc2929 at att.com> wrote:\n>> Collins, Sean wrote:\n>>\n>>> On Wed, Jul 23, 2014 at 12:06:06AM EDT, Xu Han Peng wrote:\n>>>> I would like to request one Juno Spec freeze exception for \"Support Stateful\n>>>> and Stateless DHCPv6 by dnsmasq\" BP.\n>>>>\n>>>> The spec is under review:\n>>>> https://review.openstack.org/#/c/102411/\n>>>>\n>>>> Code change for this BP is submitted as well for a while:\n>>>> https://review.openstack.org/#/c/106299/\n>>\n>>>I\'d like to +1 this request, if this work landed in Juno, this would\n>>>mean Neutron would have 100% support for all IPv6 subnet attribute\n>>>settings, since slaac support landed in J-2.\n>>\n>> +1 on this from me too. It\'s getting more and more difficult to keep\n>> claiming OpenStack will have IPv6 \"any day now\" and not having it\n>> in Juno will hurt credibility a lot.\n>>\n>> IPv4 address space is basically gone. AT&T has a fair amount of it\n>> but even we\'re feeling the pinch. A lot of companies have it worse.\n>> NAT is a mediocre stop-gap at best.\n>> We\'ve been running IPv6 in production for well over a year.\n>>\n>> Our pre-OpenStack environments support IPv6 where needed\n>> even though we have a lot of IPv4 running where we aren\'t feeling\n>> immediate pressure. We\'re having to turn internal applications away\n>> from our OpenStack based cloud because they require IPv6 and we\n>> can\'t provide it.\n>>\n>> We\'re actively searching for workarounds but none of them are\n>> attractive.\n>>\n> I\'ve given a spec exception to this, and targeted this work at Juno-3\n> as medium priority. Given that at the start of Juno we agreed to get\n> to IPV6 parity in Juno, this one falls into the community work area\n> for exceptions.\n> Thanks,\n> Kyle\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140727/348c5206/attachment.html>\n\n','<CAL3VkVxXqkOqd1TkgnfRPRndqv9KADd0AGf-MzTip7kU+BrLwg@mail.gmail.com>',NULL),('<1406525403.4697.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-28 05:30:04',0,'2014-07-28 05:30:04',NULL,'[openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing,\n partial results','Hey Miguel!\n\nThanks for doing this.  I\'ll look into the pool issue ASAP and get back\nto you.\n\nThanks,\nBrandon\n\nOn Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote:\n> Hi,\n> \n> \n> I spent a few hours deploying LBaaS V2 to my devstack instance and\n> tested it with the Tempest api test developed a couple of week ago\n> during the Neutron code sprint. This is a list of the findings so far:\n> \n> \n> 1) POST operations on loadbalancers, healthmonitors and listeners work\n> fine\n> \n> \n> 2) POST operations on pools don\'t work. The api throws a 500 with the\n> following message: \"NeutronError\": \"Request Failed: internal server\n> error while processing your request.\". The error can be reproduced\n> with the following operation:\n> \n> \n> POST /lbaas/pools \n> {\"pool\": {\"name\": \"miguelito\", \"protocol\": \"HTTP\", \"lb_algorithm\":\n> \"ROUND_ROBIN\", \"healthmonitor_id\":\n> \"98311c52-9ba5-4d1c-beb7-a8200edf3c40\"}}\n> \n> The Neutron server log shows the following error:\n> \n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Matched POST /lbaas/pools\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:100\n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Route path:\n> \'/lbaas/pools\', defaults: {\'action\': u\'create\', \'controller\': <wsgify\n> at 139916894481360 wrapping <function resource at 0x7f40f0d158c0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:102\n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Match dict: {\'action\':\n> u\'create\', \'controller\': <wsgify at 139916894481360 wrapping <function\n> resource at 0x7f40f0d158c0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103\n> 2014-07-26 21:26:03.051 25731 DEBUG neutron.api.v2.base\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] Request body:\n> {u\'pool\': {u\'lb_algorithm\': u\'ROUND_ROBIN\', u\'healthmonitor_id\':\n> u\'98311c52-9ba5-4d1c-beb7-a8200edf3c40\', u\'protocol\': u\'HTTP\',\n> u\'name\': u\'miguelito\'}}\n> prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:573\n> 2014-07-26 21:26:03.060 25731 ERROR neutron.api.v2.resource\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] create failed\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource Traceback\n> (most recent call last):\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/resource.py\", line 87, in resource\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     result\n> = method(request=request, **args)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/base.py\", line 447, in create\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     obj =\n> obj_creator(request.context, **kwargs)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/services/loadbalancer/plugin.py\", line\n> 575, in create_pool\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource\n> context, pool)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 615, in create_pool2014-07-26 21:26:03.060 25731 TRACE\n> neutron.api.v2.resource     pool_db = PoolV2(**pool)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"<string>\", line 4, in __init__\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/state.py\", line 200,\n> in _initialize_instance\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     return\n> manager.original_init(*mixed[1:], **kwargs)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/usr/lib/python2.7/dist-packages/sqlalchemy/ext/declarative/base.py\",\n> line 424, in _declarative_constructor\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     (k,\n> cls_.__name__))\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource TypeError:\n> \'lb_method\' is an invalid keyword argument for PoolV2\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource \n> 2014-07-26 21:26:03.062 25731 INFO neutron.wsgi\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] 72.191.21.124 - -\n> [26/Jul/2014 21:26:03] \"POST /v2.0/lbaas/pools HTTP/1.1\" 500 320\n> 0.015718\n> \n> \n> \n> 3)  GET /lbaas/loadbalancers,\n> GET /lbaas/loadbalancers/<loadbalancerid>,\n> PUT/lbaas/loadbalancers/<loadbalancerid> work fine\n> \n> \n> 4) DELETE /lbaas/loadbalancers/<loadbalancerid> work fine if it is not\n> preceded by an UPDATE. If the DELETE is preceded by an UPDATE, the api\n> throws a 500 with the following message: \"NeutronError\": { \"message\":\n> \"Invalid state PENDING_UPDATE of loadbalancer resource\n> 99d7e756-f042-4941-bab6-e77c7edc72a1\", \"type\": \"StateInvalid\",\n> \"detail\": \"\". The error can be reproduced with the following sequence\n> of operations:\n> \n> \n> POST /lbaas/loadbalancers\n> {\"loadbalancer\": {\"name\": \"miguelito\", \"vip_subnet_id\":\n> \"390a0f6c-b4a6-4ad0-83be-ad41832c88c6\"}}\n> \n> \n> UPDATE /lbaas/loadbalancers/<loadbalancerid>\n> {\"loadbalancer\": {\"name\": \"nuevo_miguelito\"}}\n> \n> \n> DELETE /lbaas/loadbalancers/<loadbalancerid>\n> \n> \n> The Neutron server log file shows the following error:\n> \n> 2014-07-27 23:40:42.071 25731 DEBUG keystonemiddleware.auth_token\n> [req-6e8401da-17eb-4dce-a15d-ded3b8a6e1cc ] Received request from\n> user: b870371464704e14b618609d78920ba6 with project_id :\n> f45c42127f5044e694067b2ac361d3ca and roles:\n> _member_,anotherrole,heat_stack_owner,Member\n> _build_user_headers /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:732\n> 2014-07-27 23:40:42.072 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Matched\n> DELETE /lbaas/loadbalancers/99d7e756-f042-4941-bab6-e77c7edc72a1\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:100\n> 2014-07-27 23:40:42.072 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Route path:\n> \'/lbaas/loadbalancers/:(id)\', defaults: {\'action\': u\'delete\',\n> \'controller\': <wsgify at 139916894449488 wrapping <function resource\n> at 0x7f40f0d156e0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:102\n> 2014-07-27 23:40:42.073 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Match dict: {\'action\':\n> u\'delete\', \'controller\': <wsgify at 139916894449488 wrapping <function\n> resource at 0x7f40f0d156e0>>, \'id\':\n> u\'99d7e756-f042-4941-bab6-e77c7edc72a1\'}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103\n> 2014-07-27 23:40:42.082 25731 ERROR neutron.api.v2.resource\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec None] delete failed\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource Traceback\n> (most recent call last):\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/resource.py\", line 87, in resource\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource     result\n> = method(request=request, **args)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/base.py\", line 475, in delete\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> obj_deleter(request.context, id, **kwargs)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/services/loadbalancer/plugin.py\", line\n> 478, in delete_loadbalancer\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> constants.PENDING_DELETE)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 422, in test_and_set_status\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> self.assert_modification_allowed(model_db)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 417, in assert_modification_allowed\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource     raise\n> loadbalancerv2.StateInvalid(id=id, state=status)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> StateInvalid: Invalid state PENDING_UPDATE of loadbalancer resource\n> 99d7e756-f042-4941-bab6-e77c7edc72a1\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> 2014-07-27 23:40:42.084 25731 INFO neutron.wsgi\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec None] 72.191.21.124 - -\n> [27/Jul/2014 23:40:42]\n> \"DELETE /v2.0/lbaas/loadbalancers/99d7e756-f042-4941-bab6-e77c7edc72a1\n> HTTP/1.1\" 500 394 0.015702\n> \n> \n> Over the next few days I will report api testing results for\n> healthmonitors and listeners. I will also test pools and memebers as\n> soon as the problems with pools POST reported above is fixed\n> \n> \n> Cheers\n> \n> \n> Miguel\n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAEzGLDiFw9B0nwwrqLFFHdRZ=WWh7P4vu0FRtS1L=MPsVtL81w@mail.gmail.com>',NULL),('<1406526577.4697.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-28 05:49:38',0,'2014-07-28 05:49:38',NULL,'[openstack-dev] [Neutron][LBaaS][Tempest] LBaaS V2 testing,\n partial results','Hey Miguel,\n\nI just tried to reproduce what you got but couldn\'t.  Have you pulled\ndown code recently?  I believe new code hit on Friday that probably\nfixed the issue you encountered.\n\nLet me know.\n\nThanks,\nBrandon\n\nOn Sun, 2014-07-27 at 19:24 -0500, Miguel Lavalle wrote:\n> Hi,\n> \n> \n> I spent a few hours deploying LBaaS V2 to my devstack instance and\n> tested it with the Tempest api test developed a couple of week ago\n> during the Neutron code sprint. This is a list of the findings so far:\n> \n> \n> 1) POST operations on loadbalancers, healthmonitors and listeners work\n> fine\n> \n> \n> 2) POST operations on pools don\'t work. The api throws a 500 with the\n> following message: \"NeutronError\": \"Request Failed: internal server\n> error while processing your request.\". The error can be reproduced\n> with the following operation:\n> \n> \n> POST /lbaas/pools \n> {\"pool\": {\"name\": \"miguelito\", \"protocol\": \"HTTP\", \"lb_algorithm\":\n> \"ROUND_ROBIN\", \"healthmonitor_id\":\n> \"98311c52-9ba5-4d1c-beb7-a8200edf3c40\"}}\n> \n> The Neutron server log shows the following error:\n> \n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Matched POST /lbaas/pools\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:100\n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Route path:\n> \'/lbaas/pools\', defaults: {\'action\': u\'create\', \'controller\': <wsgify\n> at 139916894481360 wrapping <function resource at 0x7f40f0d158c0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:102\n> 2014-07-26 21:26:03.050 25731 DEBUG routes.middleware\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b ] Match dict: {\'action\':\n> u\'create\', \'controller\': <wsgify at 139916894481360 wrapping <function\n> resource at 0x7f40f0d158c0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103\n> 2014-07-26 21:26:03.051 25731 DEBUG neutron.api.v2.base\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] Request body:\n> {u\'pool\': {u\'lb_algorithm\': u\'ROUND_ROBIN\', u\'healthmonitor_id\':\n> u\'98311c52-9ba5-4d1c-beb7-a8200edf3c40\', u\'protocol\': u\'HTTP\',\n> u\'name\': u\'miguelito\'}}\n> prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:573\n> 2014-07-26 21:26:03.060 25731 ERROR neutron.api.v2.resource\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] create failed\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource Traceback\n> (most recent call last):\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/resource.py\", line 87, in resource\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     result\n> = method(request=request, **args)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/base.py\", line 447, in create\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     obj =\n> obj_creator(request.context, **kwargs)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/services/loadbalancer/plugin.py\", line\n> 575, in create_pool\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource\n> context, pool)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 615, in create_pool2014-07-26 21:26:03.060 25731 TRACE\n> neutron.api.v2.resource     pool_db = PoolV2(**pool)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"<string>\", line 4, in __init__\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/state.py\", line 200,\n> in _initialize_instance\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     return\n> manager.original_init(*mixed[1:], **kwargs)\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource   File\n> \"/usr/lib/python2.7/dist-packages/sqlalchemy/ext/declarative/base.py\",\n> line 424, in _declarative_constructor\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource     (k,\n> cls_.__name__))\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource TypeError:\n> \'lb_method\' is an invalid keyword argument for PoolV2\n> 2014-07-26 21:26:03.060 25731 TRACE neutron.api.v2.resource \n> 2014-07-26 21:26:03.062 25731 INFO neutron.wsgi\n> [req-cc23dc5b-7679-407b-a02e-bde6536ecc0b None] 72.191.21.124 - -\n> [26/Jul/2014 21:26:03] \"POST /v2.0/lbaas/pools HTTP/1.1\" 500 320\n> 0.015718\n> \n> \n> \n> 3)  GET /lbaas/loadbalancers,\n> GET /lbaas/loadbalancers/<loadbalancerid>,\n> PUT/lbaas/loadbalancers/<loadbalancerid> work fine\n> \n> \n> 4) DELETE /lbaas/loadbalancers/<loadbalancerid> work fine if it is not\n> preceded by an UPDATE. If the DELETE is preceded by an UPDATE, the api\n> throws a 500 with the following message: \"NeutronError\": { \"message\":\n> \"Invalid state PENDING_UPDATE of loadbalancer resource\n> 99d7e756-f042-4941-bab6-e77c7edc72a1\", \"type\": \"StateInvalid\",\n> \"detail\": \"\". The error can be reproduced with the following sequence\n> of operations:\n> \n> \n> POST /lbaas/loadbalancers\n> {\"loadbalancer\": {\"name\": \"miguelito\", \"vip_subnet_id\":\n> \"390a0f6c-b4a6-4ad0-83be-ad41832c88c6\"}}\n> \n> \n> UPDATE /lbaas/loadbalancers/<loadbalancerid>\n> {\"loadbalancer\": {\"name\": \"nuevo_miguelito\"}}\n> \n> \n> DELETE /lbaas/loadbalancers/<loadbalancerid>\n> \n> \n> The Neutron server log file shows the following error:\n> \n> 2014-07-27 23:40:42.071 25731 DEBUG keystonemiddleware.auth_token\n> [req-6e8401da-17eb-4dce-a15d-ded3b8a6e1cc ] Received request from\n> user: b870371464704e14b618609d78920ba6 with project_id :\n> f45c42127f5044e694067b2ac361d3ca and roles:\n> _member_,anotherrole,heat_stack_owner,Member\n> _build_user_headers /usr/local/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:732\n> 2014-07-27 23:40:42.072 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Matched\n> DELETE /lbaas/loadbalancers/99d7e756-f042-4941-bab6-e77c7edc72a1\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:100\n> 2014-07-27 23:40:42.072 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Route path:\n> \'/lbaas/loadbalancers/:(id)\', defaults: {\'action\': u\'delete\',\n> \'controller\': <wsgify at 139916894449488 wrapping <function resource\n> at 0x7f40f0d156e0>>}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:102\n> 2014-07-27 23:40:42.073 25731 DEBUG routes.middleware\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec ] Match dict: {\'action\':\n> u\'delete\', \'controller\': <wsgify at 139916894449488 wrapping <function\n> resource at 0x7f40f0d156e0>>, \'id\':\n> u\'99d7e756-f042-4941-bab6-e77c7edc72a1\'}\n> __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103\n> 2014-07-27 23:40:42.082 25731 ERROR neutron.api.v2.resource\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec None] delete failed\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource Traceback\n> (most recent call last):\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/resource.py\", line 87, in resource\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource     result\n> = method(request=request, **args)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/api/v2/base.py\", line 475, in delete\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> obj_deleter(request.context, id, **kwargs)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/services/loadbalancer/plugin.py\", line\n> 478, in delete_loadbalancer\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> constants.PENDING_DELETE)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 422, in test_and_set_status\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> self.assert_modification_allowed(model_db)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource   File\n> \"/opt/stack/neutron/neutron/db/loadbalancer/loadbalancer_dbv2.py\",\n> line 417, in assert_modification_allowed\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource     raise\n> loadbalancerv2.StateInvalid(id=id, state=status)\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> StateInvalid: Invalid state PENDING_UPDATE of loadbalancer resource\n> 99d7e756-f042-4941-bab6-e77c7edc72a1\n> 2014-07-27 23:40:42.082 25731 TRACE neutron.api.v2.resource\n> 2014-07-27 23:40:42.084 25731 INFO neutron.wsgi\n> [req-18843bc2-498a-4ee2-8a35-1b265983feec None] 72.191.21.124 - -\n> [27/Jul/2014 23:40:42]\n> \"DELETE /v2.0/lbaas/loadbalancers/99d7e756-f042-4941-bab6-e77c7edc72a1\n> HTTP/1.1\" 500 394 0.015702\n> \n> \n> Over the next few days I will report api testing results for\n> healthmonitors and listeners. I will also test pools and memebers as\n> soon as the problems with pools POST reported above is fixed\n> \n> \n> Cheers\n> \n> \n> Miguel\n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAEzGLDiFw9B0nwwrqLFFHdRZ=WWh7P4vu0FRtS1L=MPsVtL81w@mail.gmail.com>',NULL),('<1406529727.4697.41.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-28 06:42:07',0,'2014-07-28 06:42:07',NULL,'[openstack-dev] [Neutron][LBaaS] Status and Expectations for Juno','There is going to be a mad rush to get many things into Neutron for Juno\nhere in the last few weeks.  Neutron is overly saturated with code\nreviews.  So I\'d like to list out some of the things LBaaS had planned\nfor Juno, what the status each of those are, and my thoughts on the\nfeasibility of actually getting it into Juno.  I\'m just trying to have\nrealistic expectations.  Please share any items I missed and any\nthoughts you have.  Kyle, if you have anything to add, I\'d really love\nto hear that.  Even if its just agreeing.\n\n1. Code for LBaaS V2 API with reference implementation\n\nThis is the most important piece and it should definitely get in.  The\nproblem is that there is a TON of code for it which will likely push\nother things we really want out of Juno.  This is the top priority, and\nI\'m sure everyone will agree.  Kyle, since the entire code review chain\nis up, with reference implementation, do you think you and other core\nreviewers can take a good look at it?\n\n2. CLI for LBaaS V2 API\n\nCraig Tracey has been working on this and I believe he is on track to\nget this in Juno.  Let me know if you feel otherwise Craig.\n\n3. Docs for LBaaS V2 API\n\nMin, I see you got the docs accepted into api-sites: \n\nhttps://review.openstack.org/#/c/106434/\n\nThat\'s great! I do have some concerns, though, because I see some\ndiscrepancies with that and the google doc we have that has been updated\nto be exactly (or nearly) of what the API expects.  Google doc is here:\n\nhttps://docs.google.com/document/d/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GNTOCTHcvbkA\n\nMin, if we could get the api-sites updated for Juno that would be great.\nOh and send us a link to the review so we can all look it over :).\nThanks!\n\n\n4. Tempest tests for LBaaS V2 API\n\nMiguel is currently working on these.  Miguel do you expect these to be\ndone in time?\n\n5. Shim layers for V2 API to V1 drivers\n\nThis one I don\'t see landing in Juno.  I just think there is too much\ncode going in for LBaaS that has a higher priority for this to make it\nin.  Plus, it really hasn\'t been worked on in a while.  This is just my\nopinion, though.  Hopefully, we won\'t need this for Kilo.\n\n6. Horizon - LBaaS V2 API\n\nThis I do not see happening for Juno.  It could happen but I don\'t know\nof anyone who has even talked about doing this.  I\'m reluctantly okay\nwith it not making it into Juno because V2 API will kind of be in a beta\nstate in my opinion since there won\'t be very much driver support,\nespecially without a shim layer.  I suggest this goes in Kilo. I know\nsome won\'t like this though (I\'m looking at you doug).\n\n7. Devstack for LBaaS V2 API\n\nThe only changes devstack would need for this piece is to just change\nthe config.  However, I have not worked on this piece myself and didn\'t\nthink of it as a high priority for Juno.  If someone has or wants to\ntackle that, please let us know.  Otherwise, move it to Kilo.\n\n8. HAProxy Agent driver\n\nSince we decided to go with a simpler agentless driver that only runs on\nthe API node and is not scalable at all, the agent driver part still\nneeds to be completed.  I definitely don\'t see this going into Juno\nbecause other higher priorities should get in first.  I suggest this\ngets in Kilo.\n\n8. TLS for LBaaS V2 API\n\nEvgeny is doing this one. I think this is a top priority for us and we\nall want this in Juno.  It depends on #1 getting in as well.  If #1\ndoesn\'t get in, we have bigger issues.  I am hopeful that this will get\nin for Juno, as I think it should be our #2 priority Neutron LBaaS.\n\n9. Docs, CLI, Tempest tests, and Devstack for TLS\n\nEvgeny, are these being worked on in tandem?\nDevstack is definitely going to require some other changes for use of\nhaproxy 1.5.\n\n10. L7 for LBaaS V2 API\n\nThis is the 3rd priority for Neutron LBaaS in my opinion.  I am not\ncertain that this will get in Juno.  Can we get updates on this?\n\n\nI think that about covers it.  Sorry for the long email.  \n\nThanks,\nBrandon\n\n\n\n','<D115164D7987674C94CA87CD65704AC30EF3BB91@ILMB1.corp.radware.com>',NULL),('<1406567141-sup-8803@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-28 10:07:39',-25200,'2014-07-28 17:07:39',NULL,'[openstack-dev] [heat] Stack update and raw_template backup','Excerpts from Zane Bitter\'s message of 2014-07-28 07:25:24 -0700:\n> On 26/07/14 00:04, Anant Patil wrote:\n> > When the stack is updated, a diff of updated template and current\n> > template can be stored to optimize database.  And perhaps Heat should\n> > have an API to retrieve this history of templates for inspection etc.\n> > when the stack admin needs it.\n> \n> If there\'s a demand for that feature we could implement it, but it \n> doesn\'t easily fall out of the current implementation any more.\n\nWe are never going to do it even 1/10th as well as git. In fact we won\'t\neven do it 1/0th as well as CVS.\n\n\n','<53D65D54.30606@redhat.com>',NULL),('<1406576788.6240.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-28 19:46:28',0,'2014-07-28 19:46:28',NULL,'[openstack-dev] [Neutron][LBaaS] Status and Expectations for\n Juno','That was essentially the point of my email.  To get across that not\neverything we want to go in Juno will make it in and because of this V2\nwill not be in the state that many users will be able to use.  Also, to\nget people\'s opinions on what they think is high priority.\n\nOn Mon, 2014-07-28 at 18:11 +0000, Doug Wiegley wrote:\n> I don?t think the lbaas roadmap has changed (including octavia), just the\n> delivery timeline.  Nor am I debating making the ref driver simpler (I?m\n> on record as supporting that decision, and still do.)  And if that was the\n> only wart, I?m sure we?d all ignore it and plow forward.  But it?s not,\n> and add all the things that are likely to miss together, and I think we?d\n> be doing the community a disservice by pushing v2 too soon.  Which means\n> our moratorium on v1 is likely premature.\n> \n> Unless Brandon gives up sleeping altogether; then I?m sure we?ll make it.\n> \n> Anyway, all this is my long-winded way of agreeing that some things will\n> likely need to be pushed to K, it happens, and let?s just be realistic\n> about what that means for our end users.\n> \n> Doug\n> \n> \n> \n> On 7/28/14, 9:34 AM, \"Jorge Miramontes\" <jorge.miramontes at RACKSPACE.COM>\n> wrote:\n> \n> >Hey Doug,\n> >\n> >In terms of taking a step backward from a user perspective I\'m fine with\n> >making v1 the default. I think there was always the notion of supporting\n> >what v1 currently offers by making a config change. Thus, Horizon should\n> >still have all the support it had in Icehouse. I am a little worried about\n> >the delivery of items we said we wanted to deliver however. The reason we\n> >are focusing on the current items is that Octavia is also part of the\n> >picture, albeit, behind the scenes right now. Thus, the argument that the\n> >new reference driver is less capable is actually a means to getting\n> >Octavia out. Eventually, we were hoping to get Octavia as the reference\n> >implementation which, from the user\'s perspective, will be much better\n> >since you can actually run it at operator scale. To be realistic, the v2\n> >implementation is a WIP and focusing on the control plane first seems to\n> >make the most sense. Having a complete end-to-end v2 implementation is\n> >large in scope and I don\'t think anyone expected it to be a full-fledged\n> >product by Juno, but we are getting closer!\n> >\n> >\n> >Cheers,\n> >--Jorge\n> >\n> >\n> >\n> >\n> >On 7/28/14 8:02 AM, \"Doug Wiegley\" <dougw at a10networks.com> wrote:\n> >\n> >>Hi Brandon,\n> >>\n> >>Thanks for bringing this up. If you?re going to call me out by name, I\n> >>guess I have to respond to the Horizon thing.  Yes, I don?t like it, from\n> >>a user perspective.  We promise a bunch of new features, new drivers? and\n> >>none of them are visible.  Or the horizon support does land, and suddenly\n> >>the user goes from a provider list of 5 to 2.  Sucks if you were using\n> >>one\n> >>of the others.  Anyway, back to a project status.  To summarize, listed\n> >>by\n> >>feature, priority, status:\n> >>\n> >>LBaaS V2 API,   high, reviews in gerrit\n> >>Ref driver,     high, removed agent, review in gerrit\n> >>CLI V2,         high, not yet in review\n> >>Devstack,       high, not started\n> >>+TLS,           medium, lots done in parallel\n> >>+L7,            medium, not started\n> >>Shim V1 -> V2,  low, minimally complete\n> >>Horizon V2,     low, not started\n> >>ref agent,      low, not started\n> >>Drivers,        low, one vendor driver in review, several in progress\n> >>\n> >>And with a review submission freeze of August 21st.  Let?s work\n> >>backwards:\n> >>\n> >>Dependent stuff will need at least two weeks to respond to the final\n> >>changes and submit.  That?d be:\n> >>\n> >>Devstack,       high, not started\n> >>+TLS,           medium, lots done in parallel\n> >>+L7,            medium, not started\n> >>Shim V1 -> V2,  low, minimally complete\n> >>Horizon V2,     low, not started\n> >>ref agent,      low, not started\n> >>Drivers,        low, one vendor driver in review, several in progress\n> >>\n> >>? I?m not including TLS, since it?s work has been very parallel so far,\n> >>even though logically it should be there.  But that would mean the\n> >>following should be ?done? and merged by August 7th:\n> >>\n> >>LBaaS V2 API,   high, reviews in gerrit\n> >>Ref driver,     high, removed agent, review in gerrit\n> >>CLI V2,         high, not yet in review\n> >>\n> >>? that?s a week and a half, for a big pile of new code.  At the current\n> >>change velocity, I have my doubts.  And if that slips, the rest starts to\n> >>look very very hazy.  Backing up, and focusing on the user, here?s lbaas\n> >>v1:\n> >>\n> >>\n> >>\n> >>\n> >>- Current object model, basic http lb\n> >>- Ref driver with agent, +3 vendors (with +3 more backends not submitting\n> >>drivers because of v2)\n> >>- UI\n> >>\n> >>? what we initially planned for Juno:\n> >>\n> >>- Shiny new object model (base for some new features)\n> >>- TLS termination/offload\n> >>- L7 routing\n> >>- Ref driver with agent, support old drivers, support new drivers\n> >>- UI, new and improved\n> >>\n> >>? what we?re now thinking of shipping:\n> >>\n> >>- Shiny new object model (base for some new features)\n> >>- TLS termination/offload\n> >>- Ref driver no agent, between 0-2 vendor drivers\n> >>- No UI\n> >>\n> >>So people get one new feature, a reference backend that is even less\n> >>production ready, no UI, and fewer providers. That seems like a step\n> >>backwards from a user perspective (at least from the non-huge operator\n> >>with a custom UI and custom driver perspective), not forward. And that\n> >>implies we need to rethink two decisions:\n> >>\n> >>- Having the V2 lbaas stuff be the default service extension/plugin\n> >>- Not supporting or reviewing new v1 drivers\n> >>\n> >>I think that we either need to deliver a more complete feature set, or\n> >>admit this thing needs to be experimental/not the default, and give a\n> >>little more attention to giving support to the default.\n> >>\n> >>Thanks,\n> >>doug\n> >>\n> >>\n> >>\n> >>\n> >>\n> >>On 7/28/14, 12:42 AM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM>\n> >>wrote:\n> >>\n> >>>There is going to be a mad rush to get many things into Neutron for Juno\n> >>>here in the last few weeks.  Neutron is overly saturated with code\n> >>>reviews.  So I\'d like to list out some of the things LBaaS had planned\n> >>>for Juno, what the status each of those are, and my thoughts on the\n> >>>feasibility of actually getting it into Juno.  I\'m just trying to have\n> >>>realistic expectations.  Please share any items I missed and any\n> >>>thoughts you have.  Kyle, if you have anything to add, I\'d really love\n> >>>to hear that.  Even if its just agreeing.\n> >>>\n> >>>1. Code for LBaaS V2 API with reference implementation\n> >>>\n> >>>This is the most important piece and it should definitely get in.  The\n> >>>problem is that there is a TON of code for it which will likely push\n> >>>other things we really want out of Juno.  This is the top priority, and\n> >>>I\'m sure everyone will agree.  Kyle, since the entire code review chain\n> >>>is up, with reference implementation, do you think you and other core\n> >>>reviewers can take a good look at it?\n> >>>\n> >>>2. CLI for LBaaS V2 API\n> >>>\n> >>>Craig Tracey has been working on this and I believe he is on track to\n> >>>get this in Juno.  Let me know if you feel otherwise Craig.\n> >>>\n> >>>3. Docs for LBaaS V2 API\n> >>>\n> >>>Min, I see you got the docs accepted into api-sites:\n> >>>\n> >>>https://review.openstack.org/#/c/106434/\n> >>>\n> >>>That\'s great! I do have some concerns, though, because I see some\n> >>>discrepancies with that and the google doc we have that has been updated\n> >>>to be exactly (or nearly) of what the API expects.  Google doc is here:\n> >>>\n> >>>https://docs.google.com/document/d/160hjgBYN8IzZPe6aPyNl7Y2C4ZeQIQ4GNTOC\n> >>>T\n> >>>H\n> >>>cvbkA\n> >>>\n> >>>Min, if we could get the api-sites updated for Juno that would be great.\n> >>>Oh and send us a link to the review so we can all look it over :).\n> >>>Thanks!\n> >>>\n> >>>\n> >>>4. Tempest tests for LBaaS V2 API\n> >>>\n> >>>Miguel is currently working on these.  Miguel do you expect these to be\n> >>>done in time?\n> >>>\n> >>>5. Shim layers for V2 API to V1 drivers\n> >>>\n> >>>This one I don\'t see landing in Juno.  I just think there is too much\n> >>>code going in for LBaaS that has a higher priority for this to make it\n> >>>in.  Plus, it really hasn\'t been worked on in a while.  This is just my\n> >>>opinion, though.  Hopefully, we won\'t need this for Kilo.\n> >>>\n> >>>6. Horizon - LBaaS V2 API\n> >>>\n> >>>This I do not see happening for Juno.  It could happen but I don\'t know\n> >>>of anyone who has even talked about doing this.  I\'m reluctantly okay\n> >>>with it not making it into Juno because V2 API will kind of be in a beta\n> >>>state in my opinion since there won\'t be very much driver support,\n> >>>especially without a shim layer.  I suggest this goes in Kilo. I know\n> >>>some won\'t like this though (I\'m looking at you doug).\n> >>>\n> >>>7. Devstack for LBaaS V2 API\n> >>>\n> >>>The only changes devstack would need for this piece is to just change\n> >>>the config.  However, I have not worked on this piece myself and didn\'t\n> >>>think of it as a high priority for Juno.  If someone has or wants to\n> >>>tackle that, please let us know.  Otherwise, move it to Kilo.\n> >>>\n> >>>8. HAProxy Agent driver\n> >>>\n> >>>Since we decided to go with a simpler agentless driver that only runs on\n> >>>the API node and is not scalable at all, the agent driver part still\n> >>>needs to be completed.  I definitely don\'t see this going into Juno\n> >>>because other higher priorities should get in first.  I suggest this\n> >>>gets in Kilo.\n> >>>\n> >>>8. TLS for LBaaS V2 API\n> >>>\n> >>>Evgeny is doing this one. I think this is a top priority for us and we\n> >>>all want this in Juno.  It depends on #1 getting in as well.  If #1\n> >>>doesn\'t get in, we have bigger issues.  I am hopeful that this will get\n> >>>in for Juno, as I think it should be our #2 priority Neutron LBaaS.\n> >>>\n> >>>9. Docs, CLI, Tempest tests, and Devstack for TLS\n> >>>\n> >>>Evgeny, are these being worked on in tandem?\n> >>>Devstack is definitely going to require some other changes for use of\n> >>>haproxy 1.5.\n> >>>\n> >>>10. L7 for LBaaS V2 API\n> >>>\n> >>>This is the 3rd priority for Neutron LBaaS in my opinion.  I am not\n> >>>certain that this will get in Juno.  Can we get updates on this?\n> >>>\n> >>>\n> >>>I think that about covers it.  Sorry for the long email.\n> >>>\n> >>>Thanks,\n> >>>Brandon\n> >>>\n> >>>\n> >>>_______________________________________________\n> >>>OpenStack-dev mailing list\n> >>>OpenStack-dev at lists.openstack.org\n> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFFBDF2E.5C0D%dougw@a10networks.com>',NULL),('<1406609327-sup-4742@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-29 00:34:18',-25200,'2014-07-29 07:34:18',NULL,'[Openstack] [Spam] Is there any way to migrate vm\'s information\n	from one Openstack environment to another','This isn\'t really how clouds are meant to operate. Servers are cattle,\nnot pets. Thus, you need a recipe for rebuilding your servers and\nharvesting them when you\'re done with them.\n\nTo be more clear, You need to automate the creation of working machines\nand migration of data. You should not concern yourself with moving the\nactual machine from one cloud to another.. this is a recipe for failure\nand will cost quite a bit to scale.\n\nExcerpts from tpiper\'s message of 2014-07-28 21:19:27 -0700:\n> Hi all,\n> i have a mission to migrate vm from an old Openstack environment to a\n> new some days ago, then i export the information of vm from\n> database(nova?neutron?cinder..). After that i just went to copy the\n> vm\'s disk and the xml format config file of libvirt.\n> \n> in my mind it\'s will be much easy through a function which can pack the\n> vm\'s informations and files and finally just export as one record(such\n> as one json message).\n> \n> use the record i can migrate the vm like what vmware would do: i can\n> quickly see it and boot it soon when i import the record to the new\n> environment.\n> \n> thx for any help!\n> \n\n\n','<53D720CF.6040908@gmail.com>',NULL),('<1406670726-sup-2848@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-29 14:53:58',-25200,'2014-07-29 21:53:58',NULL,'[openstack-dev] [heat] Saving the original raw template in the\n	DB','\nExcerpts from Ton Ngo\'s message of 2014-07-29 13:53:12 -0700:\n> \n> Hi everyone,\n>     The raw template saved in the DB used to be the original template that\n> a user submits.  With the recent fix for stack update, it now reflects the\n> template that is actually deployed, so it may be different from the\n> original template because some resources may fail to deploy.  I would like\n> to solicit some feedback on saving the original template in the DB\n> separately from the deployed template.  I can think of two use cases for\n> retrieving the original template:\n>    Debugging:  running stack-update using the same template after fixing\n>    environmental problems.  The CLI and API can be extended to allow\n>    reusing the original template without having to provide it again.\n>    Convergence or retry:  some initial resource deployment may fail\n>    intermittently, but the user can retry later.\n> \n\nI believe this use case is far better handled via vcs. We need the\ntemplate to parse the current state of the stack. The user will have\ntheir intended template and can have their intended parameter values\nall included in a VCS.\n\n>      Are there other potential use cases?    The cost would be an extra\n> copy of the template in the raw template table for each stack if there is\n> failure, and a new column in the stack table to hold the id.  We can argue\n> that the user should have the original template to resubmit, but it seems\n> useful and convenient to save it in the DB.\n> Ton Ngo,\n> \n\nAdditional cost is the additional complexity of code to manage the data.\n\n\n','<OF5322E3DC.BB04F2D7-ON88257D24.0066766D-88257D24.0072B955@us.ibm.com>',NULL),('<1406680735.3654.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 00:38:56',0,'2014-07-30 00:38:56',NULL,'[openstack-dev] [Neutron] Managing change in gerrit which\n depends on multiple other changes in review','Hi Evgeny and Doug,\n\nSo the thing to keep in mind is that Gerrit determines a new review by\nthe change-id in the commit message.  It then determines patch sets by\nthe commit hashes.  This is my understanding of it at least.  A commit\'s\nhash gets changed on many actions such as cherry-picks, rebases, and\ncommit --amend.\n\nWith this in mind, this means that you can verify if your changes will\nnot cause an update to the ancestor changes in a gerrit dependency\nchain.  Before you do a git review just look at your git log and commit\nhashes and see if the hash for each of those commits are the same as the\nlatest patch sets in gerrit.\n\nMy workflow is this:\nIf I just need to rebase the change, I just hit the rebase button in\ngerrit on my change only.  This will cause the commit to have a new\nhash, thus a new patch set.\n\nIf I need to make a change then just doing the normal git checkout from\nthe gerrit change page, and git commit --amend works fine, because I am\nonly touching that commit.\n\nIf I need to make a change AND rebase there are two ways to do this:\n1. Hit Rebase Button on the gerrit change page then git checkout, make\nchange, git commit --amend, git review.\n- The problem with this is that it creates two patch sets.\n2. git checkout the gerrit change that your gerrit change is dependent\non.  Then cherry-pick your gerrit change on top of that.  This is\nessentially a rebase, and now you can make changes to the code, commit\n--amend and git review.  Gerrit will only see this commit hash changed\nonce, so only one patch set.\n\nOne other thing to keep in mind is since your change is dependent on\nothers you have to rely on your change\'s dependents to be rebased with\nmaster.  You shouldn\'t do a rebase against master until the change you\nare dependent on has been merged.  So the only time you should rebase is\nwhen gerrit shows the OUTDATED message on your dependency.\n\nHope that helps explain my methodology, which is still a work in\nprogress.  However, I think this is a decent methodology when dealing\nwith a massive dependency chain like this.\n\nThanks,\nBrandon\n\n\nOn Tue, 2014-07-29 at 16:05 +0000, Doug Wiegley wrote:\n> Hi Evgeny,\n> \n> \n> I?m not sure I?m doing it in the most efficient way, so I?d love to\n> hear pointers, but what I?ve been doing:\n> \n> \n> First, to setup the dependent commit, the command is ?git review ?d?.\n> I?ve been using this\n> guide: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Create_a_dependency\n> \n> \n> Second, when the dependent review changes, there is a ?rebase? button\n> on gerrit that?ll get things back in sync automatically.\n> \n> \n> Third, if you need to change your code after rebasing from gerrit,\n> this is the only sequence I?ve tried that doesn?t result in something\n> weird (rebasing overwrites the dependent commits, silently, so I?m\n> clearly doing something wrong):\n>      1. Re-clone vanilla neutron\n>      2. Cd into new clone, setup for gerrit review\n>      3. Redo dependent commit setup\n>      4. Create your topic branch\n>      5. Cherry-pick your commit from gerrit into your new topic branch\n>      6. Use \"git log -n5 --decorate --pretty=oneline?, and verify that\n>         your dependency commit hashes match what?s in gerrit.\n>      7. Git review\n> \n> \n> Thanks,\n> doug\n> \n> \n> \n> \n> From: Evgeny Fedoruk <EvgenyF at Radware.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage\n> questions)\" <openstack-dev at lists.openstack.org>\n> Date: Tuesday, July 29, 2014 at 7:12 AM\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: [openstack-dev] [Neutron] Managing change in gerrit which\n> depends on multiple other changes in review\n> \n> \n> \n> Hi folks,\n> \n>  \n> \n> I?m working on a change for neutron LBaaS service.\n> \n> Since there is a massive work done for LBaaS these days, my change\n> depends on other changes being reviewed in parallel in gerrit.\n> \n> I don?t have a big git knowledge and I?m failing in figuring out the\n> right procedure that should be followed for managing such a\n> multi-dependent patch.\n> \n> So, I sending my question to you guys, in hope to find the right way\n> to manage such patches in gerrit.\n> \n>  \n> \n> Here is the situation:\n> \n> There are 4 patches on review in gerrit\n> \n> 1.      A ? No dependencies\n> \n> 2.      B ? Depends on A\n> \n> 3.      C ? Depends on A\n> \n> 4.      D ? No dependencies\n> \n>  \n> \n>  \n> \n> My change, let?s call it ?X?, is already on review in gerrit.\n> \n> It should depend on all four other changes, A, B, C and D.\n> \n>  \n> \n> I tried to two ways of managing those dependencies, 1) by doing a\n> cherry-pick for each one of them, and 2) by doing git review and git\n> rebase for each one of them.\n> \n> It does not work for me well, my change commit message is replaced by\n> other changes? commit messages and when I commit my patch, it commit?s\n> other changes patches too.\n> \n>  \n> \n> So, my question is: \n> \n> Is this scenario supported by gerrit system?\n> \n> If it does ? what is the right procedure to follow in order to manage\n> those dependencies\n> \n> and how to rebase my change when some of dependencies was commited\n> with a new patch to keep the dependencies up-to-date?\n> \n>  \n> \n>  \n> \n> Thank you!\n> \n> Evg\n> \n>  \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CFFD1323.5D2C%dougw@a10networks.com>',NULL),('<1406690586.6162.1.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 03:23:08',0,'2014-07-30 03:23:08',NULL,'[openstack-dev] [Manila] Incubation request','On Tue, 2014-07-29 at 13:38 +0200, Thierry Carrez wrote:\n> Swartzlander, Ben a ?crit :\n> > Manila has come a long way since we proposed it for incubation last autumn. Below are the formal requests.\n> > \n> > https://wiki.openstack.org/wiki/Manila/Incubation_Application\n> > https://wiki.openstack.org/wiki/Manila/Program_Application\n> > \n> > Anyone have anything to add before I forward these to the TC?\n> \n> When ready, propose a governance change a bit like this one:\n> \n> https://github.com/openstack/governance/commit/52d9b4cf2f3ba9d0b757e16dc040a1c174e1d27e\n\nThierry, does the governance change process replace the process of\nsending an email to the openstack-tc ML?\n\n-Ben\n\n\n','<53D787A6.2020602@openstack.org>',NULL),('<1406722871.3055.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 12:21:14',0,'2014-07-30 12:21:14',NULL,'[openstack-dev] [heat] Uniform style of README file for contrib\n resources','On Wed, 2014-07-30 at 13:41 +0400, Sergey Kraynev wrote:\n> Hello guys.\n> \n> \n> In the last time I meet again change related with changing content of\n> README for Docker resource.\n> \n> \n> \n> https://review.openstack.org/#/c/110541/\n\nI can ditch mine, just making a change after helping someone\non IRC through it.\n\n> \n> https://review.openstack.org/#/c/101144/\n> \n> \n> \n> Both changes try to improve current description.\n> I looked on other README files in contrib directories and met that all\n> instructions try to explain \n> information which is available here [1].\n> This and some other points pushed me on the follow ideas:\n> \n> \n> - Should we provide some commands like in docker\'s README which will\n> add required path to plugin_dirs ?\n\nIMO no, it is really simple and this just makes it look harder than it\nis.\n\n> \n> \n> - Should we have several specific interpretations of [1] or will be\n> better to add reference on existing guide and\n> mention that some \"really specific\" notes?\n> \n> \n> - Should we leave empty sections? (For example, [2])\n> \n> \n> - Should we add README for barbican resources?\n> \n> \n> - How about one uniform template for README files?\n\ncan\'t we just have one contrib/README (at least for the installing\npart)?\n\n> I think that the right way to have list of allowed sections for README\n> with fixed names.\n> In my opinion it helps other developers and users with using all\n> contrib resources, because they will know what find\n> in each section.\n> \n> \n> I suggest to use follow structure (Note: if section is empty you just\n> should not use this section):\n> \n> \n> # Title with name of resource or for what this resource will be used\n>      (After this title you should provide description of resource)\n> ## Resources     <- constant name. This section will  be used if\n> plugin directory contains more then one resource (F.e. rackspase\n> resources)\n> # Installation       <- constant name. What we should do for using\n> this plugin. (Possible will be enough to add link [1] instead sections\n> below)\n> ## Changes in configuration      <- constant name. Which files and How\n> we should change them. (Possible will  be enough to add link [1])\n> ## Restarting services             <- constant name. Names of\n> services, which should be restarted.\n> # Examples                              <- constant name. Section for\n> providing template examples (not full template, just definition of\n> contrib resource)\n> # Known issues                      <- constant name. All related\n> issues.\n> # How it works                         <- constant name. If you want\n> to tell some mechanism about this resource.\n> # Notes                                <- constant name. Section for\n> information, which can not be classified for sections above.\n>  \n> I understand, that it\'s just README files, but I still think that it\'s\n> enough important for discussion. Hope on your thoughts.\n> \n\nyeah, they are inconsistent.\n\n-Angus\n\n> \n> \n> \n> [1] https://wiki.openstack.org/wiki/Heat/Plugins#Installation_and_Configuration\n> [2] https://github.com/openstack/heat/tree/master/contrib/rackspace\n> \n> \n> Regards,\n> Sergey.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/bcc4fda6/attachment.pgp>\n\n','<CAAbQNR=s=aYCjtQCGBKkDBjwRfWCy_vaYw+cm1qKqPchW=DOQQ@mail.gmail.com>',NULL),('<1406737583-sup-1869@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 09:33:07',-25200,'2014-07-30 16:33:07',NULL,'[openstack-dev] [neutron] Cross-server locking for neutron\n	server','Please do not re-invent locking.. the way we reinvented locking in Heat.\n;)\n\nThere are well known distributed coordination services such as Zookeeper\nand etcd, and there is an abstraction for them already called tooz:\n\nhttps://git.openstack.org/cgit/stackforge/tooz/\n\nExcerpts from Elena Ezhova\'s message of 2014-07-30 09:09:27 -0700:\n> Hello everyone!\n> \n> Some recent change requests ([1], [2]) show that there is a number of\n> issues with locking db resources in Neutron.\n> \n> One of them is initialization of drivers which can be performed\n> simultaneously by several neutron servers. In this case locking is\n> essential for avoiding conflicts which is now mostly done via using\n> SQLAlchemy\'s\n> with_lockmode() method, which emits SELECT..FOR UPDATE resulting in rows\n> being locked within a transaction. As it has been already stated by Mike\n> Bayer [3], this statement is not supported by Galera and, what?s more, by\n> Postgresql for which a lock doesn?t work in case when a table is empty.\n> \n> That is why there is a need for an easy solution that would allow\n> cross-server locking and would work for every backend. First thing that\n> comes into mind is to create a table which would contain all locks acquired\n> by various pieces of code. Each time a code, that wishes to access a table\n> that needs locking, would have to perform the following steps:\n> \n> 1. Check whether a lock is already acquired by using SELECT lock_name FROM\n> cross_server_locks table.\n> \n> 2. If SELECT returned None, acquire a lock by inserting it into the\n> cross_server_locks table.\n> \n>    In other case wait and then try again until a timeout is reached.\n> \n> 3. After a code has executed it should release the lock by deleting the\n> corresponding entry from the cross_server_locks table.\n> \n> The locking process can be implemented by decorating a function that\n> performs a transaction by a special function, or as a context manager.\n> \n> Thus, I wanted to ask the community whether this approach deserves\n> consideration and, if yes, it would be necessary to decide on the format of\n> an entry in cross_server_locks table: how a lock_name should be formed,\n> whether to support different locking modes, etc.\n> \n> \n> [1] https://review.openstack.org/#/c/101982/\n> \n> [2] https://review.openstack.org/#/c/107350/\n> \n> [3]\n> https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#Pessimistic_Locking_-_SELECT_FOR_UPDATE\n\n\n','<CAFZxAhjHe1J0d43rcS8P6Uirj-pUF3e36OwZ6m-a3ZMnu0+_aA@mail.gmail.com>',NULL),('<1406739207-sup-1542@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 10:02:52',-25200,'2014-07-30 17:02:52',NULL,'[openstack-dev] [neutron] Cross-server locking for neutron\n	server','Excerpts from Doug Wiegley\'s message of 2014-07-30 09:48:17 -0700:\n> > I\'d have to look at the Neutron code, but I suspect that a simple\n> > strategy of issuing the UPDATE SQL statement with a WHERE condition that\n> \n> I?m assuming the locking is for serializing code, whereas for what you\n> describe above, is there some reason we wouldn?t just use a transaction?\n> \n\nI believe the code in question is doing something like this:\n\n1) Check DB for initialized \"SDN controller driver\"\n2) Not initialized -> initialize the SDN controller via its API\n3) Record in DB that it is initialized\n\nStep (2) above needs serialization, not (3).\n\nCompare and update will end up working like a distributed lock anyway,\nbecause the db model will have to be changed to have an \"initializing\"\nstate, and then if initializing fails, you\'ll have to have a timeout.. and\nstealing for stuck processes.\n\nSometimes a distributed lock is actually a simpler solution.\n\nTooz will need work, no doubt. Perhaps if we call it \'oslo.locking\' it\nwill make more sense. Anyway, my point stands: trust the experts, avoid\nreinventing locking. And if you don\'t like tooz, extract the locking\ncode from Heat and turn it into an oslo.locking library or something.\n\n\n','<CFFE6FB0.63C9%dougw@a10networks.com>',NULL),('<1406740306-sup-2369@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 10:17:46',-25200,'2014-07-30 17:17:46',NULL,'[openstack-dev] [heat] [Solum] Stack update and raw_template\n	backup','Excerpts from Anant Patil\'s message of 2014-07-29 23:21:05 -0700:\n> On 28-Jul-14 22:37, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-07-28 07:25:24 -0700:\n> >> On 26/07/14 00:04, Anant Patil wrote:\n> >>> When the stack is updated, a diff of updated template and current\n> >>> template can be stored to optimize database.  And perhaps Heat should\n> >>> have an API to retrieve this history of templates for inspection etc.\n> >>> when the stack admin needs it.\n> >>\n> >> If there\'s a demand for that feature we could implement it, but it \n> >> doesn\'t easily fall out of the current implementation any more.\n> > \n> > We are never going to do it even 1/10th as well as git. In fact we won\'t\n> > even do it 1/0th as well as CVS.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> Zane,\n> I am working the defect you had filed, which would clean up backup stack\n> along with the resources, templates and other data.\n> \n> However, I simply don\'t want to delete the templates for the same reason\n> as we don\'t hard-delete the stack. Anyone who deploys a stack and\n> updates it over time would want to view the the updates in the templates\n> for debugging or auditing reasons. It is not fair to assume that every\n> user has a VCS with him to store the templates. It is kind of\n> inconvenience for me to not have the ability to view my updates in\n> templates.\n> \n\nSounds like a \"nice to have\" feature. I\'d suggest you propose it as a\nblueprint and spec. I will personally be against us spending time and\nadding complexity for such a feature when it is so much better served\nby VCS.\n\nAnd I would also suggest that we _can_ assume that users have VCS. When\nis the last time you encountered a developer or ops professional that\ndid not use at least some kind of VCS? For me, it was 2003, and it took\napproximately 20 minutes to implement.\n\nAnd if we want that \"as a service\", I believe Solum is working on\ndoing that.\n\n\n','<53D88ED1.6050704@hp.com>',NULL),('<1406740781-sup-1594@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-30 10:20:57',-25200,'2014-07-30 17:20:57',NULL,'[Openstack] [diskimage-builder] How can I build my own\n	undercloud or overcloud image ?','Excerpts from ??\'s message of 2014-07-29 22:24:01 -0700:\n> I think the underlcloud.qcow2 is different.\n> Because\n> http://fedorapeople.org/~slagle/slagle-tripleo-images-fedora-i2/undercloud.qcow2\n> can be used directly by libvert.\n> However in devtest, undercloud.qcow2 is uploaded to heat.\n> \n\nImages are uploaded to glance, not Heat.\n\nOnly the seed is ever directly used via libvirt in the devtest.sh\nsequence.\n\nCheck out tripleo-incubator, especially the devtest* scripts.\n\n\n','<CALAMvO8Gy5AegL8wQWQisVXpRj03A2RLN0=wuAfCkL1N++PDzA@mail.gmail.com>',NULL),('<1406740974.22329.1.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 12:22:54',-18000,'2014-07-30 17:22:54',NULL,'[openstack-dev] [nova] stable branches & failure to handle\n review backlog','On Wed, 2014-07-30 at 09:01 +0200, Flavio Percoco wrote:\n> As a stable-maint, I\'m always hesitant to review patches I\'ve no\n> understanding on, hence I end up just checking how big is the patch,\n> whether it adds/removes new configuration options etc but, the real\n> review has to be done by someone with good understanding of the change.\n> \n> Something I\'ve done in the past is adding the folks that had approved\n> the patch on master to the stable/maint review. They should know that\n> code already, which means it shouldn\'t take them long to review it. All\n> the sanity checks should\'ve been done already.\n> \n> With all that said, I\'d be happy to give *-core approval permissions on\n> stable branches, but I still think we need a dedicated team that has a\n> final (or at least relevant) word on the patches.\n\nMaybe what we need to do is give *-core permission to +2 the patches,\nbut only stable/maint team has *approval* permission.  Then, the cores\ncan review the code, and stable/maint only has to verify applicability\nto the stable branch?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53D8982D.4070105@redhat.com>',NULL),('<1406754033-sup-9024@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 14:01:38',-25200,'2014-07-30 21:01:38',NULL,'[openstack-dev] [neutron] Cross-server locking for neutron\n	server','Excerpts from Jay Pipes\'s message of 2014-07-30 13:53:38 -0700:\n> On 07/30/2014 12:21 PM, Kevin Benton wrote:\n> > Maybe I misunderstood your approach then.\n> >\n> > I though you were suggesting where a node performs an \"UPDATE record\n> > WHERE record = last_state_node_saw\" query and then checks the number of\n> > affected rows. That\'s optimistic locking by every definition I\'ve heard\n> > of it. It matches the following statement from the wiki article you\n> > linked to as well:\n> >\n> > \"The latter situation (optimistic locking) is only appropriate when\n> > there is less chance of someone needing to access the record while it is\n> > locked; otherwise it cannot be certain that the update will succeed\n> > because the attempt to update the record will fail if another user\n> > updates the record first.\"\n> >\n> > Did I misinterpret how your approach works?\n> \n> The record is never \"locked\" in my approach, why is why I don\'t like to \n> think of it as optimistic locking. It\'s more like \"optimistic read and \n> update with retry if certain conditions continue to be met...\" :)\n> \n> To be very precise, the record is never locked explicitly -- either \n> through the use of SELECT FOR UPDATE or some explicit file or \n> distributed lock. InnoDB won\'t even hold a lock on anything, as it will \n> simply add a new version to the row using its MGCC (sometimes called \n> MVCC) methods.\n> \n> The technique I am showing in the patch relies on the behaviour of the \n> SQL UPDATE statement with a WHERE clause that contains certain columns \n> and values from the original view of the record. The behaviour of the \n> UPDATE statement will be a NOOP when some other thread has updated the \n> record in between the time that the first thread read the record, and \n> the time the first thread attempted to update the record. The caller of \n> UPDATE can detect this NOOP by checking the number of affected rows, and \n> retry the UPDATE if certain conditions remain kosher...\n> \n> So, there\'s actually no locks taken in the entire process, which is why \n> I object to the term optimistic locking :) I think where the confusion \n> has been is that the initial SELECT and the following UPDATE statements \n> are *not* done in the context of a single SQL transaction...\n> \n\nThis is all true at a low level Jay. But if you\'re serializing something\noutside the DB by using the \"doing it\" versus \"done it\" state, it still\nacts like a lock.\n\n\n','<53D95B52.8070806@gmail.com>',NULL),('<1406754958.3145.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 21:16:01',0,'2014-07-30 21:16:01',NULL,'[openstack-dev] [heat] Uniform style of README file for contrib\n resources','On Wed, 2014-07-30 at 17:05 +0400, Sergey Kraynev wrote:\n> On 30 July 2014 16:21, Angus Salkeld <angus.salkeld at rackspace.com>\n> wrote:\n>         On Wed, 2014-07-30 at 13:41 +0400, Sergey Kraynev wrote:\n>         > Hello guys.\n>         >\n>         >\n>         > In the last time I meet again change related with changing\n>         content of\n>         > README for Docker resource.\n>         >\n>         >\n>         >\n>         > https://review.openstack.org/#/c/110541/\n>         \n>         \n>         I can ditch mine, just making a change after helping someone\n>         on IRC through it.\n> \n> \n> I don\'t mind about your change. It remembered me about current\n> situation with README files.\n> \n> \n>  \n>         \n>         >\n>         > https://review.openstack.org/#/c/101144/\n>         >\n>         >\n>         >\n>         > Both changes try to improve current description.\n>         > I looked on other README files in contrib directories and\n>         met that all\n>         > instructions try to explain\n>         > information which is available here [1].\n>         > This and some other points pushed me on the follow ideas:\n>         >\n>         >\n>         > - Should we provide some commands like in docker\'s README\n>         which will\n>         > add required path to plugin_dirs ?\n>         \n>         \n>         IMO no, it is really simple and this just makes it look harder\n>         than it\n>         is.\n>         \n>         >\n>         >\n>         > - Should we have several specific interpretations of [1] or\n>         will be\n>         > better to add reference on existing guide and\n>         > mention that some \"really specific\" notes?\n>         >\n>         >\n>         > - Should we leave empty sections? (For example, [2])\n>         >\n>         >\n>         > - Should we add README for barbican resources?\n>         >\n>         >\n>         > - How about one uniform template for README files?\n>         \n>         \n>         can\'t we just have one contrib/README (at least for the\n>         installing\n>         part)?\n> \n> \n> \n> \n> I wanted to suggest this way, but what about some specific keys \n> (keystone plugin require additional change in heat.conf).\n> And I correct understood that you offer to leave other information\n> (not installation) in own README files?\n\nYes, that seems fine to me. Just stop replicating the install\ninstructions.\n\n-A\n\n>  \n>         \n>         > I think that the right way to have list of allowed sections\n>         for README\n>         > with fixed names.\n>         > In my opinion it helps other developers and users with using\n>         all\n>         > contrib resources, because they will know what find\n>         > in each section.\n>         >\n>         >\n>         > I suggest to use follow structure (Note: if section is empty\n>         you just\n>         > should not use this section):\n>         >\n>         >\n>         > # Title with name of resource or for what this resource will\n>         be used\n>         >      (After this title you should provide description of\n>         resource)\n>         > ## Resources     <- constant name. This section will  be\n>         used if\n>         > plugin directory contains more then one resource (F.e.\n>         rackspase\n>         > resources)\n>         > # Installation       <- constant name. What we should do for\n>         using\n>         > this plugin. (Possible will be enough to add link [1]\n>         instead sections\n>         > below)\n>         > ## Changes in configuration      <- constant name. Which\n>         files and How\n>         > we should change them. (Possible will  be enough to add link\n>         [1])\n>         > ## Restarting services             <- constant name. Names\n>         of\n>         > services, which should be restarted.\n>         > # Examples                              <- constant name.\n>         Section for\n>         > providing template examples (not full template, just\n>         definition of\n>         > contrib resource)\n>         > # Known issues                      <- constant name. All\n>         related\n>         > issues.\n>         > # How it works                         <- constant name. If\n>         you want\n>         > to tell some mechanism about this resource.\n>         > # Notes                                <- constant name.\n>         Section for\n>         > information, which can not be classified for sections above.\n>         >\n>         > I understand, that it\'s just README files, but I still think\n>         that it\'s\n>         > enough important for discussion. Hope on your thoughts.\n>         >\n>         \n>         \n>         yeah, they are inconsistent.\n>         \n>         -Angus\n>         \n>         >\n>         >\n>         >\n>         > [1]\n>         https://wiki.openstack.org/wiki/Heat/Plugins#Installation_and_Configuration\n>         > [2]\n>         https://github.com/openstack/heat/tree/master/contrib/rackspace\n>         >\n>         >\n>         > Regards,\n>         > Sergey.\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140730/be633ad9/attachment.pgp>\n\n','<CAAbQNRmsfURS=EJOZwrAWSkM--LS_NiQxPuL5FGtFTW5vOQzbQ@mail.gmail.com>',NULL),('<1406757130.31988.YahooMailNeo@web142801.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-30 14:52:10',-25200,'2014-07-30 21:52:10',NULL,'[Openstack-operators] Several openstack nova daemons refuse\n	to	start after a reboot','Can you paste the line you have for this headless user in /etc/sudoers?\n\nmake sure you have something like:\n\n$userALL NOPASSWD: /usr/bin/nova-rootwrap\n\n\nwhere $user is the name of the headless user you\'ve created to execute this process.\n\n-James\n\n\n?\n\n:)=\n\n\nOn Wednesday, July 30, 2014 12:16 PM, Abel Lopez <alopgeek at gmail.com> wrote:\n \n\n\nCouple of things I?d check, first make sure /etc/sudoers has the ?#includedir /etc/sudoers.d??\nIt must have the #, that?s not a comment, that?s what the directive looks like.\n\nSecondly, parse the file with visudo to make sure it?s syntactically correct, both the /etc/sudoers and any file that may be in /etc/sudoers.d/\nYour nova user?s shell is fine, mine is /bin/false,?\n\n\nOn Jul 30, 2014, at 12:04 PM, Jeff Silverman <jeff at sweetlabs.com> wrote:\n\nI had several openstack daemons running properly after going through the set up process. ?I decided to reboot the machine (because it\'s going to reboot sooner or later and I wanted to find out what would go wrong before we pressed the system into production). ?Several of the daemons don\'t start properly. ?In all cases, there is an error message in the log files of the form:\n>\n>\n>2014-07-30 10:56:57.349 878 CRITICAL nova [-] ProcessExecutionError: Unexpected error while running command.\n>Command: sudo nova-nn /etc/nova/rootwrap.conf iptables-save -c\n>Exit code: 1\n>Stdout: \'\'\n>Stderr: \'sudo: no tty present and no askpass program specified\\n\'\n>\n>\n>\n>I have googled the error message and I find several items of advice, all of which I have taken and none of which have resolved my issue:\n>\n>\n>	* Remove the defaults requiretty from the /etc/sudoers file. ?I have done both?#Defaults requiretty?and?Defaults !requiretty? and tried again.? No joy.\n>	* I added the following line to nova.conf:\n>root_helper=sudo nova-rootwrap\n>no joy, there, either.\n>	* Interestingly enough, if I give the command sudo?nova-rootwrap?/etc/nova/rootwrap.conf?iptables-save?-c \n>from the command line as user root, then it works.\n>	* I notice that user nova is in/etc/passwdwith shell/bin/nologin. ?I assume that that\'s there for a reason, so I am reluctant to change it.\n>	* If I give the command\n>sudo nova-nn whoami\n>I get:\n>sudo: nova-nn: command not found\n>	* \n>\n>\n>\n>I am open to additional suggestions. ?I am running on Centos 6.5\n>\n>\n>\n>-- \n>\n>Jeff Silverman\n>Systems Engineer\n>(253) 459-2318 (c)\n>\n>\n_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140730/91cf27f6/attachment.html>\n\n','<1CB08A1B-171D-4724-83CD-9999FCFBE87E@gmail.com>',NULL),('<1406757350.25525.YahooMailNeo@web142801.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-30 14:55:50',-25200,'2014-07-30 21:55:50',NULL,'[Openstack-operators] Several openstack nova daemons refuse\n	to	start after a reboot','Also, these docs should help you out:?https://wiki.openstack.org/wiki/Rootwrap\n\n?\n:)=\nOn , James Penick <james_r_penick at yahoo.com> wrote:\n \n\n\nCan you paste the line you have for this headless user in /etc/sudoers?\n\nmake sure you have something like:\n\n$userALL NOPASSWD: /usr/bin/nova-rootwrap\n\n\nwhere $user is the name of the headless user you\'ve created to execute this process.\n\n-James\n\n\n?\n\n:)=\n\n\nOn Wednesday, July 30, 2014 12:16 PM, Abel Lopez <alopgeek at gmail.com> wrote:\n \n\n\nCouple of things I?d check, first make sure /etc/sudoers has the ?#includedir /etc/sudoers.d??\nIt must have the #, that?s not a comment, that?s what the directive looks like.\n\nSecondly, parse the file with visudo to make sure it?s syntactically correct, both the /etc/sudoers and any file that may be in /etc/sudoers.d/\nYour nova user?s shell is fine, mine is /bin/false,?\n\n\nOn Jul 30, 2014, at 12:04 PM, Jeff Silverman <jeff at sweetlabs.com> wrote:\n\nI had several openstack daemons running properly after going through the set up process. ?I decided to reboot the machine (because it\'s going to reboot sooner or later and I wanted to find out what would go wrong before we pressed the system into production). ?Several of the daemons don\'t start properly. ?In all cases, there is an error message in the log files of the form:\n>\n>\n>2014-07-30 10:56:57.349 878 CRITICAL nova [-] ProcessExecutionError: Unexpected error while running command.\n>Command: sudo nova-nn /etc/nova/rootwrap.conf iptables-save -c\n>Exit code: 1\n>Stdout: \'\'\n>Stderr: \'sudo: no tty present and no askpass program specified\\n\'\n>\n>\n>\n>I have googled the error message and I find several items of advice, all of which I have taken and none of which have resolved my issue:\n>\n>\n>	* Remove the defaults requiretty from the /etc/sudoers file. ?I have done both?#Defaults requiretty?and?Defaults !requiretty? and tried again.? No joy.\n>	* I added the following line to nova.conf:\n>root_helper=sudo nova-rootwrap\n>no joy, there, either.\n>	* Interestingly enough, if I give the command sudo?nova-rootwrap?/etc/nova/rootwrap.conf?iptables-save?-c \n>from the command line as user root, then it works.\n>	* I notice that user nova is in/etc/passwdwith shell/bin/nologin. ?I assume that that\'s there for a reason, so I am reluctant to change it.\n>	* If I give the command\n>sudo nova-nn whoami\n>I get:\n>sudo: nova-nn: command not found\n>	* \n>\n>\n>\n>I am open to additional suggestions. ?I am running on Centos 6.5\n>\n>\n>\n>-- \n>\n>Jeff Silverman\n>Systems Engineer\n>(253) 459-2318 (c)\n>\n>\n_______________________________________________\n>OpenStack-operators mailing list\n>OpenStack-operators at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140730/937d5ecd/attachment.html>\n\n','<1406757130.31988.YahooMailNeo@web142801.mail.bf1.yahoo.com>',NULL),('<1406758116.22329.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 17:08:36',-18000,'2014-07-30 22:08:36',NULL,'[openstack-dev] [Nova] Nominating Jay Pipes for nova-core','On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote:\n> I would like to nominate Jay Pipes for the nova-core team.\n\n+1\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAEd1pt4RQzL2EvU0enuXMeS6+tRxtBihi6AGSwdKH9XnAJAUNQ@mail.gmail.com>',NULL),('<1406759656.1166955.147472414.16DF44FC@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 15:34:16',-25200,'2014-07-30 22:34:16',NULL,'[openstack-dev] [nova] so what do i do about libvirt-python if\n i\'m on precise?','On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:\n> On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:\n> > While forcing people to move to a newer version of libvirt is\n> > doable on most environments, do we want to do that now? What is\n> > the benefit of doing so?\n> [...]\n> \n> The only dog I have in this fight is that using the split-out\n> libvirt-python on PyPI means we finally get to run Nova unit tests\n> in virtualenvs which aren\'t built with system-site-packages enabled.\n> It\'s been a long-running headache which I\'d like to see eradicated\n> everywhere we can. I understand though if we have to go about it\n> more slowly, I\'m just excited to see it finally within our grasp.\n> -- \n> Jeremy Stanley\n>\nWe aren\'t quite forcing people to move to newer versions. Only those\ninstalling nova test-requirements need newer libvirt. This does not\ninclude people using eg devstack. I think it is reasonable to expect\npeople testing tip of nova master to have a reasonably newish test bed\nto test it (its not like the Infra team moves at a really fast pace :)\n).\n\nAvoiding system site packages in virtualenvs is a huge win particularly\nfor consistency of test results. It avoids pollution of site packages\nthat can happen differently across test machines. This particular type\nof inconsistency has been the cause of the previously mentioned\nheadaches.\n\nClark\n\n\n','<20140730222330.GD1251@yuggoth.org>',NULL),('<1406790012.3713340.1400600577883.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-20 11:42:57',-14400,'2014-05-20 15:42:57',NULL,'[openstack-dev] [TripleO] Post-summit next steps','\n\n----- Original Message -----\n> Hi Rob,\n> Could you please point me where the spec repo is?\n\nAll the spec repos are under the standard git location:\n\nhttp://git.openstack.org/cgit/openstack/\n\ne.g.\nhttp://git.openstack.org/cgit/openstack/tripleo-specs/\n\n> Thanks\n> \n> --Cristian\n> \n> On 19/05/14 22:46, \"Robert Collins\" <robertc at robertcollins.net> wrote:\n> \n> >Hey everyone, it was great to see many of you at the summit - if you\n> >were there and we didn\'t get time to say hello, then hopefully in\n> >Paris we can do that ;)\n> >\n> >I\'d like everyone that ran a TripleO session to make sure the outcomes\n> >of the session are captured into a spec in the specs repo - getting\n> >design review from anyone that did not make it to the summit is\n> >important before we cruise ahead. Please ping me if you don\'t get\n> >prompt, effective review there - we should have very low latency for\n> >specs reviews :).\n> >\n> >Other than that, take a few days, get your breath back, and then onward\n> >to Juno.\n> >\n> >-Rob\n> >\n> >--\n> >Robert Collins <rbtcollins at hp.com>\n> >Distinguished Technologist\n> >HP Converged Cloud\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CFA0FA1C.1B18%cristian.a.sanchez@intel.com>',NULL),('<1406801796.25071.2.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-31 12:16:36',7200,'2014-07-31 10:16:36',NULL,'[openstack-dev] [all] How to get testr to failfast','Hi!\n\nOn Thu, 2014-07-31 at 10:45 +0100, Chris Dent wrote:\n> One of the things I like to be able to do when in the middle of making\n> changes is sometimes run all the tests to make sure I haven\'t accidentally\n> caused some unexpected damage in the neighborhood. If I have I don\'t\n> want the tests to all run, I\'d like to exit on first failure.\n\nThis makes even more sense, if you _know_ that you\'ve broken a lot of\nthings and want to deal with it case-by-case. At least for me it\'s more\nconvenient, I believe many will prefer getting all the errors at once.\n\n>  This\n> is a common feature in lots of testrunners but I can\'t seem to find\n> a way to make it happen when testr is integrated with setuptools.\n> \n> Any one know a way?\n> \n> There\'s this:\n>    https://bugs.launchpad.net/testrepository/+bug/1211926\n> \n> But it is not clear how or where to effectively pass the right argument,\n> either from the command line or in tox.ini.\n> \n> Even if you don\'t know a way, I\'d like to hear from other people who\n> would like it to be possible. It\'s one of several testing habits I\n> have from previous worlds that I\'m missing and doing a bit of\n> commiseration would be a nice load off.\n\nIt would be my 2nd wanted feature in our test system (after getting\nreasonable error message (at least not binary) in case of import\nerrors :)\n\n> \n> Thanks.\n> \n\n\n\n\n','<alpine.OSX.2.11.1407311032270.7848@seed>',NULL),('<1406803657.25071.4.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-31 12:47:37',7200,'2014-07-31 10:47:37',NULL,'[openstack-dev] help','Hi!\n\nThis list is not for usage question, it\'s for OpenStack developers. The\nbest way to get a quick help should be using\nhttps://ask.openstack.org/en/questions/ or joining #openstack on\nFreenode and asking there.\n\nGood luck!\n\nOn Thu, 2014-07-31 at 15:59 +0530, shailendra acharya wrote:\n> hello folks,\n>           this is shailendra acharya. i m trying to install openstack\n> icehouse in centos6.5. but i got stuck and tried almost every link\n> which was suggested to me by google. i have last hope to u. \n> when i come to create user using keystone cmd as written in openstack\n> installation manual\n>    keystone user-create --name=admin --pass=ADMIN_PASS\n> --email=ADMIN_EMAIL\n> \n>  \n> i replaced email and pass but when i press enter it shows \n> invalid credential error  plz do dsomething asap\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CADBejZPLVOjW=_8b2MmE9zQ+2-LU9Q0C6+zgLbZTEL95XcdJwQ@mail.gmail.com>',NULL),('<1406804154.23285.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-31 10:55:57',0,'2014-07-31 10:55:57',NULL,'[openstack-dev] [tc][rally][qa] Application for a new OpenStack\n Program: Performance and Scalability','On Sun, 2014-07-27 at 07:57 -0700, Sean Dague wrote:\n> On 07/26/2014 05:51 PM, Hayes, Graham wrote:\n> > On Tue, 2014-07-22 at 12:18 -0400, Sean Dague wrote:\n> >> On 07/22/2014 11:58 AM, David Kranz wrote:\n> >>> On 07/22/2014 10:44 AM, Sean Dague wrote:\n> >>>> Honestly, I\'m really not sure I see this as a different program, but is\n> >>>> really something that should be folded into the QA program. I feel like\n> >>>> a top level effort like this is going to lead to a lot of duplication in\n> >>>> the data analysis that\'s currently going on, as well as functionality\n> >>>> for better load driver UX.\n> >>>>\n> >>>> 	-Sean\n> >>> +1\n> >>> It will also lead to pointless discussions/arguments about which\n> >>> activities are part of \"QA\" and which are part of\n> >>> \"Performance and Scalability Testing\".\n> > \n> > I think that those discussions will still take place, it will just be on\n> > a per repository basis, instead of a per program one.\n> > \n> > [snip]\n> > \n> >>\n> >> Right, 100% agreed. Rally would remain with it\'s own repo + review team,\n> >> just like grenade.\n> >>\n> >> 	-Sean\n> >>\n> > \n> > Is the concept of a separate review team not the point of a program?\n> > \n> > In the the thread from Designate\'s Incubation request Thierry said [1]:\n> > \n> >> \"Programs\" just let us bless goals and teams and let them organize \n> >> code however they want, with contribution to any code repo under that\n> >> umbrella being considered \"official\" and ATC-status-granting.\n> >         \n> > I do think that this is something that needs to be clarified by the TC -\n> > Rally could not get a PTL if they were part of the QA project, but every\n> > time we get a program request, the same discussion happens.\n> > \n> > I think that mission statements can be edited to fit new programs as\n> > they occur, and that it is more important to let teams that have been\n> > working closely together to stay as a distinct group.\n> \n> My big concern here is that many of the things that these efforts have\n> been doing are things we actually want much closer to the base. For\n> instance, metrics on Tempest runs.\n> \n> When Rally was first created it had it\'s own load generator. It took a\n> ton of effort to keep the team from duplicating that and instead just\n> use some subset of Tempest. Then when measuring showed up, we actually\n> said that is something that would be great in Tempest, so whoever ran\n> it, be it for Testing, Monitoring, or Performance gathering, would have\n> access to that data. But the Rally team went off in a corner and did it\n> otherwise. That\'s caused the QA team to have to go and redo this work\n> from scratch with subunit2sql, in a way that can be consumed by multiple\n> efforts.\n> \n> So I\'m generally -1 to this being a separate effort on the basis that so\n> far the team has decided to stay in their own sandbox instead of\n> participating actively where many of us thing the functions should be\n> added. I also think this isn\'t like Designate, because this isn\'t\n> intended to be part of the integrated release.\n\nFrom reading Boris\'s email it seems like rally will provide a horizon\npanel and api to back it (for the operator to kick of performance runs\nand view stats). So this does seem like something that would be a\npart of the integrated release (if I am reading things correctly).\n\nIs the QA program happy to extend their scope to include that?\nQA could become \"Quality Assurance of upstream code and running\nOpenStack installations\". If not we need to find some other program\nfor rally.\n\n-Angus\n\n> \n> Of course you could decide to slice up the universe in a completely\n> different way, but we have toolchains today, which I think the focus\n> should be on participating there.\n> \n> 	-Sean\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140731/d2d04287/attachment.pgp>\n\n','<53D51372.3060003@dague.net>',NULL),('<1406864425.6805.3.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-08-01 03:40:25',0,'2014-08-01 03:40:25',NULL,'[openstack-tc] Manila incubation request','I wanted to call the attention of the TC to our incubation request:\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/041387.html\n\nthanks!\n-Ben Swartzlander\n\n\n\n\n\n',NULL,NULL),('<1406956180.5859.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-02 05:09:40',0,'2014-08-02 05:09:40',NULL,'[openstack-dev] [neutron] API confusion','Hi Mike,\n\nSo that looks like those docs are for the v2 LBaaS API.  The CLI changes\nfor v2 are not in yet, and the v2 API implementation code is in review\nright now.\n\nI am a bit worried that I do not see the v1 docs anymore because v1 will\nstill remain until its deprecated. In fact, I\'m pretty sure v2 will not\nbe used very much in Juno because it will not have very much driver\nsupport.  So this i something we will have to fix.\n\nThanks for bring this up!\n\n-Brandon \n\nOn Fri, 2014-08-01 at 13:46 -0400, Mike Spreitzer wrote:\n> http://developer.openstack.org/api-ref-networking-v2.htmland\n> http://docs.openstack.org/api/openstack-network/2.0/content/GET_listMembers__v2.0_pools__pool_id__members_lbaas_ext_ops_member.htmlsay that to list LB pool members, the URL to GET is /v2.0/pools/{pool_id}/members \n> \n> When I use the CLI (`neutron -v lb-member-list`) I see a GET\n> on /v2.0/lb/members.json \n> \n> What\'s going on here? \n> \n> Thanks,\n> Mike\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<OFB4D0B5DE.500C117C-ON85257D27.006139B8-85257D27.0061A3D3@us.ibm.com>',NULL),('<1406956571.92676.YahooMailNeo@web163603.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-01 22:16:11',-25200,'2014-08-02 05:16:11',NULL,'[OpenStack-Infra] IBM Neutron Testing CI Account','Hi Anita,\nI\'ve been having some issues with Zuul mergers in the CI setup. I have discussed some of these on the IRC channel, and currently investigating the same. The puppet installs for zuul have not gone thru properly for me, I saw issues related to permissions in the zuul ssh and git directories and fixed these for the sandbox project, but i continue seeing the same for the neutron project, even though i have updated these manually. I am looking into the issue right now, and request the community to ignore the reviews from the IBM Neutron CI system. please note that, since the CI setup is now working on sandbox, I have to continue investigating in a project context.\n\nthanks for your patience,\ndaya kamath\n\nFrom:Anita Kuno <anteaya at anteaya.info>\nTo:IBM SDN-VE Testing/Watson/IBM at IBMUS, \"openstack-infra at lists.openstack.org\" <openstack-infra at lists.openstack.org>\nDate:08/01/2014 06:22 PM\nSubject:reporting merge conflicts on patches tested by IBM Neutron Testing CI Account\n\n\n\nhttps://review.openstack.org/#/c/111113/7\n\nHello:\n\nCurrently your CI account is reporting merge conflicts on patches.\nPlease investigate this situation. At least one of our core contributors\nis of the belief this is inappropriate behaviour. Please do share your\nopinion as I would like to know what your position is on this matter.\n\nOn an unrelated note, the name of your system will be changing in\naccordance with our new account policy:\nhttp://ci.openstack.org/third_party.html#requesting-a-service-account\n\nPlease stay inform of third party ci expectations by attending the third\nparty meeting on a regular basis:\nhttps://wiki.openstack.org/wiki/Meetings/ThirdParty\n\nThank you,\nAnita.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140801/11e96254/attachment.html>\n\n',NULL,NULL),('<1407008121.11480.0.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-02 15:35:21',-14400,'2014-08-02 19:35:21',NULL,'[openstack-dev] [Nova] Nominating Jay Pipes for nova-core','On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote:\n> Greetings,\n> \n> I would like to nominate Jay Pipes for the nova-core team.\n> \n> Jay has been involved with nova for a long time now.  He\'s previously\n> been a nova core, as well as a glance core (and PTL). He\'s been around\n> so long that there are probably other types of core status I have\n> missed.\n> \n> Please respond with +1s or any concerns.\n\n+1\n\n> \n> References:\n> \n>   https://review.openstack.org/#/q/owner:%22jay+pipes%22+status:open,n,z\n> \n>   https://review.openstack.org/#/q/reviewer:%22jay+pipes%22,n,z\n> \n>   http://stackalytics.com/?module=nova-group&user_id=jaypipes\n> \n> As a reminder, we use the voting process outlined at\n> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our\n> core team.\n> \n> Thanks,\n> Michael\n> \n\n\n\n\n','<CAEd1pt4RQzL2EvU0enuXMeS6+tRxtBihi6AGSwdKH9XnAJAUNQ@mail.gmail.com>',NULL),('<1407165472-sup-1158@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-04 08:19:43',-25200,'2014-08-04 15:19:43',NULL,'[openstack-dev] [TripleO] a small experiment with Ansible in\n	TripleO','I\'ve been fiddling on github. This repo is unfortunately named the same\nbut is not the same ancestry as yours. Anyway, the branch \'fiddling\' has\na working Heat inventory plugin which should give you a hostvar of\n\'heat_metadata\' per host in the given stack.\n\nhttps://github.com/SpamapS/tripleo-ansible/blob/fiddling/plugins/inventory/heat.py\n\nNote that in the root there is a \'heat-ansible-inventory.conf\' that is\nan example config (works w/ devstack) to query a heat stack and turn it\ninto an ansible inventory. That uses oslo.config so all of the usual\npatterns for loading configs in openstack should apply.\n\nExcerpts from Allison Randal\'s message of 2014-08-01 09:07:44 -0700:\n> A few of us have been independently experimenting with Ansible as a\n> backend for TripleO, and have just decided to try experimenting\n> together. I\'ve chatted with Robert, and he says that TripleO was always\n> intended to have pluggable backends (CM layer), and just never had\n> anyone interested in working on them. (I see it now, even in the early\n> docs and talks, I guess I just couldn\'t see the forest for the trees.)\n> So, the work is in line with the overall goals of the TripleO project.\n> \n> We\'re starting with a tiny scope, focused only on updating a running\n> TripleO deployment, so our first work is in:\n> \n> - Create an Ansible Dynamic Inventory plugin to extract metadata from Heat\n> - Improve/extend the Ansible nova_compute Cloud Module (or create a new\n> one), for Nova rebuild\n> - Develop a minimal handoff from Heat to Ansible, particularly focused\n> on the interactions between os-collect-config and Ansible\n> \n> We\'re merging our work in this repo, until we figure out where it should\n> live:\n> \n> https://github.com/allisonrandal/tripleo-ansible\n> \n> We\'ve set ourselves one week as the first sanity-check to see whether\n> this idea is going anywhere, and we may scrap it all at that point. But,\n> it seems best to be totally transparent about the idea from the start,\n> so no-one is surprised later.\n> \n> Cheers,\n> Allison\n> \n\n\n','<53DBBB50.9070508@lohutok.net>',NULL),('<1407175124.3693679.149018409.633F99C1@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-04 10:58:44',-25200,'2014-08-04 17:58:44',NULL,'[Openstack] [OpenStack] How to get the logging output in unit\n tests with tox?','On Mon, Aug 4, 2014, at 08:28 AM, Markus Zoeller wrote:\n> The bug 1301830 describes the need for additional debug logging.\n> When I run the unit tests with\n>     tox -epy26\n>     HostFiltersTestCase.test_availability_zone_filter_different\n> I don\'t see any logging output.\n> \n> How do I get the ouput of the logging?\n> \n> Regards,\n> Markus Zoeller\n> \n> \n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\nNote questions like this should probably go to the openstack-dev list.\nYou may get a quicker response there.\n\nThe answer to the question depends on what project is being tested.\nLooking at the bug it appears to be Nova. Nova uses subunit to record\nits test logs. You will find the subunit logs in\n.testrepository/$TESTIDNUMBER. These files should contain the logs you\nare looking for.\n\nClark\n\n\n','<OFCA041D6F.6B8C575E-ONC1257D2A.0054DDAB-C1257D2A.0055026D@de.ibm.com>',NULL),('<1407177638.13834.24.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-04 14:40:38',-14400,'2014-08-04 18:40:38',NULL,'[openstack-dev] [Tripleo] photos of whiteboards?','On Sun, 2014-08-03 at 07:59 +1200, Robert Collins wrote:\n> We had a few whiteboard photos taken during the sprint, but I can\'t\n> find where they were posted :/\n> \n> Right now I\'m looking for the one with the list of priority CI jobs,\n\nI don\'t have the photo. But it looks like someone wrote them down on the\netherpad here (see line 95):\n\nhttps://etherpad.openstack.org/p/juno-midcycle-meetup\n\n> \n> -Rob\n> \n\n\n\n\n','<CAJ3HoZ1-G8j=DfZzV1F_-bfxjM8rKP4w3MFpMEGygOiLOXTZZw@mail.gmail.com>',NULL),('<1407191760.93977343@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-08-04 17:36:00',-18000,'2014-08-04 22:36:00',NULL,'[openstack-community] Participation in OpenStack Pavilion at\n	Gartner Data Center Conference','\nWe are pleased to offer our community companies a pod in the OpenStack Ecosystem Pavilion at the [ Gartner Data Center Conference ]( http://www.gartner.com/technology/summits/na/data-center/ ), December 2-5, 2014, in Las Vegas. Eight companies joined us at the 2013 event, and were very happy with the quality of leads and conversations.  All expo hall attendees must purchase conference passes so the audience is all high quality enterprise decision makers and influencers.  Gartner analysts will also visit our booth during a scheduled time.\n \nPlease respond by August 15 if you are interested and can commit to participation at $15,000 to $18,000 US each (depending on number of confirmed companies).  We hope to be able to add an additional promotional opportunity this year to drive awareness and traffic.\n \nHere are quotes from last year\'s participants:\n \n\"The lead quality was very high. We had great conversations.\"\n \n\"We also had [our own] booth on the expo floor and felt that the additional booth presence was very advantageous to driving traffic. The OpenStack Pavilion met with our expectations on conversations and qualified leads.\"\n \n\"I worked that show and it was the BEST quality of traffic we\'ve seen from any event. Of the 20 or so \"A\" leads we collected, we\'ve had 5 that I know of that have continued conversations. Highly recommended. Definite ROI on this one.\"\n \nThank you.\n-- \nRegards, \n\nKathy Cacciatore\nOpenStack Industry Event Planner\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140804/ea66da57/attachment.html>\n\n',NULL,NULL),('<1407201298.6517.7.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 01:15:00',0,'2014-08-05 01:15:00',NULL,'[openstack-dev] [git-review] Supporting development in local\n branches','On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote:\n> Hello, git-review users!\n> \n> \n> I\'d like to gather feedback on a feature I want to implement that\n> might turn out useful for you.\n> \n> \n> I like using Git for development. It allows me to keep track of\n> current development process, it remembers everything I ever did with\n> the code (and more).\n> I also really like using Gerrit for code review. It provides clean\n> interfaces, forces clean histories (who needs to know that I changed\n> one line of code in 3am on Monday?) and allows productive\n> collaboration.\n> What I really hate is having to throw away my (local, precious for me)\n> history for all change requests because I need to upload a change to\n> Gerrit.\n\nI just create a short-term branch to record this.\n\n> \n> \n> That\'s why I want to propose making git-review to support the workflow\n> that will make me happy. Imagine you could do smth like this:\n> \n> \n> 0. create new local branch;\n> \n> \n> master: M--....\n>          \\\n> feature:  *\n> \n> \n> 1. start hacking, doing small local meaningful (to you) commits;\n> \n> \n> master: M--....\n>          \\\n> feature:  A-B-...-C\n> \n> \n> 2. since hacking takes tremendous amount of time (you\'re doing a Cool\n> Feature (tm), nothing less) you need to update some code from master,\n> so you\'re just merging master in to your branch (i.e. using Git as\n> you\'d use it normally);\n> \n> master: M--....-N-O-...\n>          \\    \\    \\\n> feature:  A-B-...-C-D-...\n> \n> \n> 3. and now you get the first version that deserves to be seen by\n> community, so you run \'git review\', it asks you for desired commit\n> message, and <poof, magic-magic> all changes from your branch is\n> uploaded to Gerrit as _one_ change request;\n> \n> master: M--....-N-O-...\n>          \\    \\    \\----E* <= uploaded\n> feature:  A-B-...-C-D-...-E\n> \n> \n> 4. you repeat steps 1 and 2 as much as you like;\n> 5. and all consecutive calls to \'git review\' will show you last commit\n> message you used for upload and use it to upload new state of your\n> local branch to Gerrit, as one change request.\n> \n> \n> Note that during this process git-review will never run rebase or\n> merge operations. All such operations are done by user in local branch\n> instead.\n> \n> \n> Now, to the dirty implementations details.\n> \n> \n> - Since suggested feature changes default behavior of git-review,\n> it\'ll have to be explicitly turned on in config\n> (review.shadow_branches? review.local_branches?). It should also be\n> implicitly disabled on master branch (or whatever is in .gitreview\n> config).\n> - Last uploaded commit for branch <branch-name> will be kept in\n> refs/review-branches/<branch-name>.\n> - For every call of \'git review\' it will find latest commit in\n> gerrit/master (or remote and branch from .gitreview), create a new one\n> that will have that commit as its parent and a tree of current commit\n> from local branch as its tree.\n> - While creating new commit, it\'ll open an editor to fix commit\n> message for that new commit taking it\'s initial contents from\n> refs/review-branches/<branch-name> if it exists.\n> - Creating this new commit might involve generating a temporary bare\n> repo (maybe even with shared objects dir) to prevent changes to\n> current index and HEAD while using bare \'git commit\' to do most of the\n> work instead of loads of plumbing commands.\n> \n> \n> Note that such approach won\'t work for uploading multiple change\n> request without some complex tweaks, but I imagine later we can\n> improve it and support uploading several interdependent change\n> requests from several local branches. We can resolve dependencies\n> between them by tracking latest merges (if branch myfeature-a has been\n> merged to myfeature-b then change request from myfeature-b will depend\n> on change request from myfeature-a):\n> \n> master:    M--....-N-O-...\n>             \\    \\    \\---------E*\n> myfeature-a: A-B-...-C-D-...-E   \\\n>                       \\       \\   J* <= uploaded\n> myfeature-b:           F-...-G-I-J\n> \n> \n> This improvement would be implemented later if needed.\n> \n> \n> I hope such feature seams to be useful not just for me and I\'m looking\n> forward to some comments on it.\n\nHi Yuriy,\n\nI like my local history matching what is up for review and\ndon\'t value the interim messy commits (I make a short term branch to\nsave the history so I can go back to it - if I mess up a merge).\n\nTho\' others might love this idea.\n\n-Angus\n\n> \n> \n> -- \n> \n> Kind regards, Yuriy.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/7476526d/attachment.pgp>\n\n','<CABocrW50HggQKreKsppkQ7ZuPYfMW3+YTGc-014VAKDtAho6Uw@mail.gmail.com>',NULL),('<1407217428.95563.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 13:43:48',28800,'2014-08-05 05:43:48',NULL,'[openstack-dev] [Heat][TripleO] Heat can\'t retrieve stack list','Hi all,\n\nI have been trying to set up tripleo using instack.\nWhen I try to deploy overcloud, I get a heat related?\nerror. Here it is:\n\n[stack at localhost ~]$ heat stack-list\nERROR: Timeout while waiting on RPC response - topic: \"engine\", RPC method: \"list_stacks\" info: \"<unknown>\"\n\nNow, heat-engine is running:\n\n\n[stack at localhost ~]$ ps ax | grep heat-engine\n15765 pts/0 ? ?S+ ? ? 0:00 grep --color=auto heat-engine\n25671 ? ? ? ? ?Ss ? ? 0:27 /usr/bin/python /usr/bin/heat-engine --logfile /var/log/heat/engine.log\n\nHere is the heat-engine log:\n\n2014-08-04 07:57:26.321 25671 ERROR heat.engine.resource [-] CREATE : Server \"SwiftStorage0\" [b78e4c74-f446-4941-8402-56cf46401013] Stack \"overcloud\" [9bdc71f5-ce31-4a9c-8d72-3adda0a2c66e]\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource Traceback (most recent call last):\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? File \"/usr/lib/python2.7/site-packages/heat/engine/resource.py\", line 420, in _do_action\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? ? while not check(handle_data):\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 545, in check_create_complete\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? ? return self._check_active(server)\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? File \"/usr/lib/python2.7/site-packages/heat/engine/resources/server.py\", line 561, in _check_active\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource ? ? raise exc\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource Error: Creation of server overcloud-SwiftStorage0-fnl43ebtcsom failed.\n2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource?\n2014-08-04 07:57:27.152 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:27.494 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:27.998 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:28.312 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:28.799 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:29.452 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:30.106 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:30.516 25671 WARNING heat.common.keystoneclient [-] stack_user_domain ID not set in heat.conf falling back to using default\n2014-08-04 07:57:31.499 25671 WARNING heat.engine.service [-] Stack create failed, status FAILED\n\nAny idea how to figure this error out?\n?\nThanks,\nPeeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/35254c92/attachment-0001.html>\n\n',NULL,NULL),('<1407217494.6595.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 05:44:54',0,'2014-08-05 05:44:54',NULL,'[openstack-dev] [Neutron][LBaaS][Tempest] LBaaS API Tempest\n testing status update','Hey Miguel,\nI was able to reproduce the issue here and luckily it was an error in\nthe driver.  So that means I don\'t need to update the plugin.  I fixed\nthe issue in the driver, and pushed the change up.  Everything should be\nworking now.\n\nThanks,\nBrandon\n\nOn Sun, 2014-08-03 at 20:42 -0500, Miguel Lavalle wrote:\n> Hi,\n> \n> \n> Today I have confirmed with a Tempest api test script that all the\n> operations for loadbalancers, listeners, healthmonitors and pools for\n> the new LBaaS v2.0 work correctly. \n> \n> \n> As for members, POST, PUT and GET operations also work correctly. The\n> only exception is the DELETE operation. The test script failed with\n> it. I will investigate the cause tomorrow\n> \n> \n> Cheers\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAEzGLDgoXk6Y4VBi4phV7daTYZDFJYAf7weQP1r1tH6NHwHHoQ@mail.gmail.com>',NULL),('<1407252460.3853.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 15:27:10',0,'2014-08-05 15:27:10',NULL,'[openstack-dev] [Neutron][LBaaS] \"status\" in entities','\nHello Vijay!\n\nWell this is a hold over from v1, but the status is a provisioning\nstatus.  So yes, when something is deployed successfully it should be\nACTIVE.  The exception to this is the member status, in that it\'s status\ncan be INACTIVE if a health check fails.  Now this will probably cause\nedge cases when health checks and updates are happening to the same\nmember.  It\'s been talked about before, but we need to really have two\ntypes of status fields, provisioning and operational.  IMHO, that should\nbe something we try to get into K.\n\nThanks,\nBrandon\n\nOn Tue, 2014-08-05 at 09:28 +0000, Vijay Venkatachalam wrote:\n> Hi:\n> \n>                I think we had some discussions around ?status?\n> attribute earlier, I don?t recollect the conclusion.\n> \n> Does it reflect the deployment status?\n> \n>                Meaning, if the status of an entity is ACTIVE, the user\n> has to infer that the entity is deployed successfully in the\n> backend/loadbalancer.\n> \n> Thanks,\n> \n> Vijay V.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<26B082831A2B1A4783604AB89B9B2C080E09E593@SINPEX01CL03.citrite.net>',NULL),('<1407254751.3853.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 16:05:22',0,'2014-08-05 16:05:22',NULL,'[openstack-dev] [Neutron][LBaaS] \"status\" in entities','Isn\'t that what admin_state_up is for?\n\nBut yes we do need a deeper discussion on this and many other things.\n\nOn Tue, 2014-08-05 at 15:42 +0000, Eichberger, German wrote:\n> There was also talk about a third administrative status like ON/OFF...\n> \n> We really need a deeper status discussion - likely high bandwith to work all of that out.\n> \n> German\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \n> Sent: Tuesday, August 05, 2014 8:27 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Neutron][LBaaS] \"status\" in entities\n> \n> \n> Hello Vijay!\n> \n> Well this is a hold over from v1, but the status is a provisioning status.  So yes, when something is deployed successfully it should be ACTIVE.  The exception to this is the member status, in that it\'s status can be INACTIVE if a health check fails.  Now this will probably cause edge cases when health checks and updates are happening to the same member.  It\'s been talked about before, but we need to really have two types of status fields, provisioning and operational.  IMHO, that should be something we try to get into K.\n> \n> Thanks,\n> Brandon\n> \n> On Tue, 2014-08-05 at 09:28 +0000, Vijay Venkatachalam wrote:\n> > Hi:\n> > \n> >                I think we had some discussions around ?status?\n> > attribute earlier, I don?t recollect the conclusion.\n> > \n> > Does it reflect the deployment status?\n> > \n> >                Meaning, if the status of an entity is ACTIVE, the user \n> > has to infer that the entity is deployed successfully in the \n> > backend/loadbalancer.\n> > \n> > Thanks,\n> > \n> > Vijay V.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C3AE79D@G1W3651.americas.hpqcorp.net>',NULL),('<1407271387.3455.1.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 20:43:01',0,'2014-08-05 20:43:01',NULL,'[openstack-dev] [Manila] File-storage for Manila service image','On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote:\n> Hello everyone,\n> \n> \n> Currently used image for Manila is located in\n> dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit for traffic,\n> see https://www.dropbox.com/help/4204\n> \n> \n> Due to generation of excessive traffic, public links were banned and\n> image could not be downloaded with error code 509, now it is unbanned,\n> until another excess reached.\n> \n> \n> Traffic limit should not threat possibility to use project, so we need\n> find stable file storage with permanent public links and without\n> traffic limit.\n> \n> \n> Does anyone have any suggestions for more suitable file storage to\n> use?\n\nLet\'s try creating a github repo and sharing it there. For hopefully\nobvious reasons, let\'s NOT put this into the manila repos directly --\nlet\'s keep it separate.\n\n\n> -- \n> Kind Regards\n> Valeriy Ponomaryov\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPnpNOVkQ27vHYDHZiWOSVBCrZ6FEZ-f=3y=9kXQcOOHjinGxg@mail.gmail.com>',NULL),('<1407273103.3455.4.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 21:11:36',0,'2014-08-05 21:11:36',NULL,'[openstack-dev] [Manila] File-storage for Manila service image','On Tue, 2014-08-05 at 23:50 +0300, Valeriy Ponomaryov wrote:\n> Github has file size limit in 100 Mb, see\n> https://help.github.com/articles/what-is-my-disk-quota\n> \n> \n> Our current image is about 300 Mb.\n\nDo you think we could upload the file to launchpad somehow? I\'ve seen LP\nhosting various downloadable files. If that fails maybe the\nopenstack-infra team has a place for blobs.\n\nWorst case we will just host in on S3 and pay for it out of our pockets.\n\n\n> On Tue, Aug 5, 2014 at 11:43 PM, Swartzlander, Ben\n> <Ben.Swartzlander at netapp.com> wrote:\n>         On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote:\n>         > Hello everyone,\n>         >\n>         >\n>         > Currently used image for Manila is located in\n>         > dropbox: ubuntu_1204_nfs_cifs.qcow2 and dropbox has limit\n>         for traffic,\n>         > see https://www.dropbox.com/help/4204\n>         >\n>         >\n>         > Due to generation of excessive traffic, public links were\n>         banned and\n>         > image could not be downloaded with error code 509, now it is\n>         unbanned,\n>         > until another excess reached.\n>         >\n>         >\n>         > Traffic limit should not threat possibility to use project,\n>         so we need\n>         > find stable file storage with permanent public links and\n>         without\n>         > traffic limit.\n>         >\n>         >\n>         > Does anyone have any suggestions for more suitable file\n>         storage to\n>         > use?\n>         \n>         \n>         Let\'s try creating a github repo and sharing it there. For\n>         hopefully\n>         obvious reasons, let\'s NOT put this into the manila repos\n>         directly --\n>         let\'s keep it separate.\n>         \n>         \n>         > --\n>         > Kind Regards\n>         > Valeriy Ponomaryov\n>         >\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Kind Regards\n> Valeriy Ponomaryov\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPnpNOV9qb+v+HJSLAEnAZzT7iZN8+oyxkCD1r8vDJ7ff9kj0w@mail.gmail.com>',NULL),('<1407273943.53e14bd7b10fe@www.imp.polymtl.ca>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-05 17:25:43',-14400,'2014-08-05 21:25:43',NULL,'[Openstack] Heat-IceHouse, stack creation fails','\nHi,\nI am trying Heat - IceHouse but I cannot even create a tiny VM as explained in\nthe documents\n(http://docs.openstack.org/icehouse/install-guide/install/apt/content/heat-verify.html).\nIn Heat-engine log file, I saw that \"stack-user-domain\" ID is not set in the\nheat.conf file. So I modified heat.conf and added admin ID (the one defined\nwhen Keystone was installed and configured) and its name and password for\nstack_user_domain, stack_domain_admin, and stack_domain_admin_password,\nrespectively. But still stack creation fails and I see in the logs that\n\"ClientException: The server has either erred or is incapable of performing the\nrequested operation\".\n\nWhat should be set in heat.conf as stack-user-domain and other corresponding\nvariables? should I create a new domain for Heat and how?\n\nMany thanks,\nParisa\n\n\n',NULL,NULL),('<1407276160.77899.149531685.78AF2AF7@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 15:02:40',-25200,'2014-08-05 22:02:40',NULL,'[openstack-dev] [All] Gate bugs in the real world','Hello,\n\nAn interesting thing happened today. The Infra team noticed that\nnodepool was unable to delete a significant number of nodes from the \ntwo public clouds we use to test OpenStack. Upon further investigation\nit was determined that we were hitting\nhttps://bugs.launchpad.net/python-neutronclient/+bug/1297309 and \nhttps://bugs.launchpad.net/neutron/+bug/1211915.\n\nBoth of these bugs were found via our gate testing. One was tracked by\nelastic-recheck and the other has logstash queries. I bring this up\nbecause it illustrates there there is massive value in identifying,\ntriaging, and fixing these bugs before they also become a problem for\noperators and end users. This isn\'t just about fixing the gate, it is\nabout\nmaking OpenStack better for everyone.\n\nThank you for your time and do let us know in #openstack-infra or on\nthis thread if you are interested in helping with the current set of\ngate failures. We would love more volunteers.\n\nClark\n\n\n',NULL,NULL),('<1407283479.108844.149561037.285E0C1D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 17:04:39',-25200,'2014-08-06 00:04:39',NULL,'[openstack-dev] [All] Switching default test node to Trusty for all\n projects and upgrading tox to version 1.7.2','Hello,\n\nOn August 20th the Infra team will be switching the default test node\nfrom Ubuntu Precise to Ubuntu Trusty. This means that `tox -epy27`, `tox\n-ecover`, `tox -epep8`, `tox -evenv -- python setup.py build_sphinx`\nwill run on Trusty build nodes intead of Precise nodes. This will not\naffect python 2.6 or 3.3 tests as they will remain on Centos6 and\nPrecise as that is where those python versions are available.\n\nMany projects have made the the switch to Trusty already and it has been\npainless for the most part. The only things we have run into so far are\napache 2.2 vs apache 2.4 differences and Solum had rabbitmq problems in\ntheir functional test on Trusty (this test will not move to Trusty as\npart of this). If your project has not already made the transition to\nTrusty you can make sure you are prepared by running `tox -epy27`, `tox\n-epep8`, and `tox -evenv -- python setup.py build_sphinx`. I have been\ntrying to do this for as many projects as I can but only have so much\ntime :) your help is appreciated.\n\nWe will also be upgrading tox on our test slaves to tox 1.7.2. We have\npinned to version 1.6.1 for a long time because 1.7.0 broke\ncompatibility with many of our tox.ini files. That problem has since\nbeen fixed but another minor issue has cropped up in 1.7.0. Details are\nat\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/041283.html.\nTL;DR is if your tests cannot handle a random python hashseed value you\nwill need to fix your tests or merge a change like\nhttps://review.openstack.org/#/c/109700/ to your project. Again, I have\ndone my best to poke at this for as many projects as I can but there are\nso many of them. Your help is appreciated with this as well.\n\nUpgrading tox is important so that we can stop relying on a specific\nversion of tox that developers need to know to install. It will also\nallow us to move our py33 testing to py34 on Trusty which gives python3\ntesting a long term home.\n\nIf you have any questions let me know. Thanks again,\nClark\n\n\n',NULL,NULL),('<1407286292.72662.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-05 17:51:32',-25200,'2014-08-06 00:51:32',NULL,'[OpenStack-Infra] [tempest] tempest requirements error for\n	oslo.i18n>=0.1.0','all,\ni\'m seeing continuous errors when the gate script starts running tempest test, for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n >= 0.1.0\ninterestingly, when i ran the same job on sandbox, it worked fine.\n\nany pointers?\n\nhere\'s the error log -?Paste #90811 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests\n22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve\n22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest\n22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on paste.openstack.org Preview by Yahoo  \n? \nhere\'s my pip list output -?Paste #90812 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90812 | LodgeIt!\nalembic (0.6.5)\namqp (1.3.3)\nanyjson (0.3.3)\nargparse (1.2.1)\nastroid (1.1.0)\nBabel (1.3)\nbackports.ssl-match-hostname (3.4.0.2)\nBeautifulSoup (3.2.1)\nbeautifulsoup4 (4.3.2)\nboto (2.27.0)\nbzr (2.6.0)\nceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\nTIA for your help!\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140805/ab229ffb/attachment.html>\n\n',NULL,NULL),('<1407296887.12183.YahooMailNeo@web163606.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 20:48:07',-25200,'2014-08-06 03:48:07',NULL,'[openstack-dev] [infra][Neutron] tempest requirements errors while\n	fetching oslo.i18n>=0.1.0','all,\ni\'m seeing continuous errors when the gate script starts running tempest tests for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n >= 0.1.0. this is not happening one-shot, continuously, so i dont think there\'s intermittent connectivity issues.\ninterestingly, when i ran the same job on sandbox, it worked fine.\n\nany pointers?\n\nhere\'s the error log -?Paste #90811 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests\n22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve\n22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest\n22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on paste.openstack.org Preview by Yahoo  \n? \n?\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on?paste.openstack.org Preview by Yahoo  \n? \nhere\'s my pip list output -?Paste #90812 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90812 | LodgeIt!\nalembic (0.6.5) amqp (1.3.3) anyjson (0.3.3) argparse (1.2.1) astroid (1.1.0) Babel (1.3) backports.ssl-match-hostname (3.4.0.2) BeautifulSoup (3.2.1) beautifulsoup4 (4.3.2) boto (2.27.0) bzr (2.6.0) ceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)...  \nView on?paste.openstack.org Preview by Yahoo  \n? \n\nTIA for your help!?\nalso, sorry if you get multiple copies of the message, i got a membership disabled message when i sent it out earlier, and trying again..\n\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/90ab3635/attachment.html>\n\n',NULL,NULL),('<1407296887.12183.YahooMailNeo@web163606.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-05 20:48:07',-25200,'2014-08-06 03:48:07',NULL,'[OpenStack-Infra] [infra][Neutron] tempest requirements errors\n	while fetching oslo.i18n>=0.1.0','all,\ni\'m seeing continuous errors when the gate script starts running tempest tests for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n >= 0.1.0. this is not happening one-shot, continuously, so i dont think there\'s intermittent connectivity issues.\ninterestingly, when i ran the same job on sandbox, it worked fine.\n\nany pointers?\n\nhere\'s the error log -?Paste #90811 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests\n22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve\n22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest\n22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on paste.openstack.org Preview by Yahoo  \n? \n?\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on?paste.openstack.org Preview by Yahoo  \n? \nhere\'s my pip list output -?Paste #90812 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90812 | LodgeIt!\nalembic (0.6.5) amqp (1.3.3) anyjson (0.3.3) argparse (1.2.1) astroid (1.1.0) Babel (1.3) backports.ssl-match-hostname (3.4.0.2) BeautifulSoup (3.2.1) beautifulsoup4 (4.3.2) boto (2.27.0) bzr (2.6.0) ceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)...  \nView on?paste.openstack.org Preview by Yahoo  \n? \n\nTIA for your help!?\nalso, sorry if you get multiple copies of the message, i got a membership disabled message when i sent it out earlier, and trying again..\n\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140805/90ab3635/attachment-0001.html>\n\n',NULL,NULL),('<1407341259251.56947@jvf.cc>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-06 16:04:53',0,'2014-08-06 16:04:53',NULL,'[openstack-dev] [Ironic] Proposal for slight change in our\n	spec	process','Similarly, I appreciated this idea when we discussed it at the mid-cycle and doing so here.\n\n+1\n\n-Jay Faulkner\n\n________________________________________\nFrom: Lucas Alvares Gomes <lucasagomes at gmail.com>\nSent: Wednesday, August 06, 2014 2:34 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Ironic] Proposal for slight change in our spec    process\n\nAlready agreed with the idea at the midcycle, but just making it public: +1\n\nOn Tue, Aug 5, 2014 at 8:54 PM, Roman Prykhodchenko\n<rprikhodchenko at mirantis.com> wrote:\n> Hi!\n>\n> I think this is a nice idea indeed. Do you plan to use this process starting\n> from Juno or as soon as possible?\n\nIt will start in Kilo\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAB1EZBp7GtagaA3FRBZ+PLb+WwPVrfiWSFAGKBumRoYWr+Op=g@mail.gmail.com>',NULL),('<1407380295.4076.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 02:58:16',0,'2014-08-07 02:58:16',NULL,'[openstack-dev] [Octavia] Weekly meetings resuming + agenda','When is the plan to move the meeting to IRC?\n\nOn Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote:\n> Action items from today\'s Octavia meeting:\n> \n> \n> 1. We\'re going to hold off for a couple days on merging the\n> constitution and preliminary road map to give people (and in\n> particular Ebay) a chance to review and comment.\n> 2. Stephen is going to try to get Octavia v0.5 design docs into gerrit\n> review by the end of the week, or early next week at the latest.\n> \n> 3. If those with specific networking concerns could codify this and/or\n> figure out a way to write these down and share with the list, that\n> would be great. This is going to be important to ensure that our\n> \"operator-grade load balancer\" solution can actually meet the needs of\n> the operators developing it.\n> \n> Thanks,\n> \n> Stephen\n> \n> \n> \n> \n> \n> \n> \n> \n> On Tue, Aug 5, 2014 at 2:34 PM, Stephen Balukoff\n> <sbalukoff at bluebox.net> wrote:\n>         Hello!\n>         \n>         \n>         We plan on resuming weekly meetings to discuss things related\n>         to the Octavia project starting tomorrow: August 6th at\n>         13:00PDT (20:00UTC). In order to facilitate high-bandwidth\n>         discussion as we bootstrap the project, we have decided to\n>         hold these meetings via webex, with the plan to eventually\n>         transition to IRC. Please contact me directly if you would\n>         like to get in on the webex.\n>         \n>         \n>         Tomorrow\'s meeting agenda is currently as follows:\n>         \n>         \n>         * Discuss Octavia constitution and project direction documents\n>         currently under gerrit review:\n>         https://review.openstack.org/#/c/110563/\n>         \n>         \n>         \n>         * Discuss reviews of design proposals currently under gerrit\n>         review:\n>         https://review.openstack.org/#/c/111440/\n>         https://review.openstack.org/#/c/111445/\n>         \n>         \n>         * Discuss operator network topology requirements based on data\n>         currently being collected by HP, Rackspace and Blue Box.\n>         (Other operators are certainly welcome to collect and share\n>         their data as well! I\'m looking at you, Ebay. ;) )\n>         \n>         \n>         Please feel free to respond with additional agenda items!\n>         \n>         \n>         Stephen\n>         \n>         \n>         -- \n>         Stephen Balukoff \n>         Blue Box Group, LLC \n>         (800)613-4305 x807\n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZoVfE07qNUdTBUAFgq3es1A+rcrL632R6qBw+p6hr4YkA@mail.gmail.com>',NULL),('<1407412605.2521.3.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 13:56:45',7200,'2014-08-07 11:56:45',NULL,'[openstack-dev] [Ironic] Exceptional approval request for Cisco\n Driver Blueprint','Hi!\n\nDidn\'t read the spec thoroughly, but I\'m concerned by it\'s huge scope.\nIt\'s actually several specs squashed into one (not too detailed). My\nvote is splitting it into a chain of specs (at least 3: power driver,\ndiscovery, other configurations) and seek exception separately.\nActually, I\'m +1 on making exception for power driver, but -0 on the\nothers, until I see a separate spec for them.\n\nDmitry.\n\nOn Thu, 2014-08-07 at 09:30 +0530, GopiKrishna Saripuri wrote:\n> Hi,\n> \n> \n> I\'ve submitted Ironic Cisco driver blueprint post proposal freeze\n> date. This driver is critical for Cisco and few customers to test as\n> part of their private cloud expansion. The driver implementation is\n> ready along with unit-tests. Will submit the code for review once\n> blueprint is accepted. \n> \n> \n> The Blueprint review link: https://review.openstack.org/#/c/110217/\n> \n> \n> Please let me know If its possible to include this in Juno release.\n> \n> \n> \n> Regards\n> GopiKrishna S\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAOfpd087FvqECsgeJSS8GLsxw+jfMtUVFySbdSF16XQbfWO12A@mail.gmail.com>',NULL),('<1407412679.3451.12.camel@fancy.Bigpond>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 11:58:32',0,'2014-08-07 11:58:32',NULL,'[openstack-dev] Which program for Rally','On Wed, 2014-08-06 at 15:48 -0600, John Griffith wrote:\n> I have to agree with Duncan here.  I also don\'t know if I fully\n> understand the limit in options.  Stress test seems like it\n> could/should be different (again overlap isn\'t a horrible thing) and I\n> don\'t see it as siphoning off resources so not sure of the issue.\n>  We\'ve become quite wrapped up in projects, programs and the like\n> lately and it seems to hinder forward progress more than anything\n> else.\nh\n> \n> I\'m also not convinced that Tempest is where all things belong, in\n> fact I\'ve been thinking more and more that a good bit of what Tempest\n> does today should fall more on the responsibility of the projects\n> themselves.  For example functional testing of features etc, ideally\n> I\'d love to have more of that fall on the projects and their\n> respective teams.  That might even be something as simple to start as\n> saying \"if you contribute a new feature, you have to also provide a\n> link to a contribution to the Tempest test-suite that checks it\".\n>  Sort of like we do for unit tests, cross-project tracking is\n> difficult of course, but it\'s a start.  The other idea is maybe\n> functional test harnesses live in their respective projects.\n> \n\nCouldn\'t we reduce the scope of tempest (and rally) : make tempest the\nAPI verification and rally the secenario/performance tester? Make each\ntool do less, but better. My point being to split the projects by\nfunctionality so there is less need to share code and stomp on each\nother\'s toes.\n\n> \n> \n> Honestly I think who better to write tests for a project than the\n> folks building and contributing to the project.  At some point IMO the\n> QA team isn\'t going to scale.  I wonder if maybe we should be thinking\n> about proposals for delineating responsibility and goals in terms of\n> functional testing?\n> \n\nThis is planned, I believe.\n\n-Angus\n\n> \n> \n> \n> \n> \n> On Wed, Aug 6, 2014 at 12:25 PM, Duncan Thomas\n> <duncan.thomas at gmail.com> wrote:\n>         I\'m not following here - you complain about rally being\n>         monolithic,\n>         then suggest that parts of it should be baked into tempest - a\n>         tool\n>         that is already huge and difficult to get into. I\'d rather see\n>         tools\n>         that do one thing well and some overlap than one tool to rule\n>         them\n>         all.\n\n+1\n\n>         \n>         On 6 August 2014 14:44, Sean Dague <sean at dague.net> wrote:\n>         > On 08/06/2014 09:11 AM, Russell Bryant wrote:\n>         >> On 08/06/2014 06:30 AM, Thierry Carrez wrote:\n>         >>> Hi everyone,\n>         >>>\n>         >>> At the TC meeting yesterday we discussed Rally program\n>         request and\n>         >>> incubation request. We quickly dismissed the incubation\n>         request, as\n>         >>> Rally appears to be able to live happily on top of\n>         OpenStack and would\n>         >>> benefit from having a release cycle decoupled from the\n>         OpenStack\n>         >>> \"integrated release\".\n>         >>>\n>         >>> That leaves the question of the program. OpenStack\n>         programs are created\n>         >>> by the Technical Committee, to bless existing efforts and\n>         teams that are\n>         >>> considered *essential* to the production of the\n>         \"OpenStack\" integrated\n>         >>> release and the completion of the OpenStack project\n>         mission. There are 3\n>         >>> ways to look at Rally and official programs at this point:\n>         >>>\n>         >>> 1. Rally as an essential QA tool\n>         >>> Performance testing (and especially performance regression\n>         testing) is\n>         >>> an essential QA function, and a feature that Rally\n>         provides. If the QA\n>         >>> team is happy to use Rally to fill that function, then\n>         Rally can\n>         >>> obviously be adopted by the (already-existing) QA program.\n>         That said,\n>         >>> that would put Rally under the authority of the QA PTL,\n>         and that raises\n>         >>> a few questions due to the current architecture of Rally,\n>         which is more\n>         >>> product-oriented. There needs to be further discussion\n>         between the QA\n>         >>> core team and the Rally team to see how that could work\n>         and if that\n>         >>> option would be acceptable for both sides.\n>         >>>\n>         >>> 2. Rally as an essential operator tool\n>         >>> Regular benchmarking of OpenStack deployments is a best\n>         practice for\n>         >>> cloud operators, and a feature that Rally provides. With a\n>         bit of a\n>         >>> stretch, we could consider that benchmarking is essential\n>         to the\n>         >>> completion of the OpenStack project mission. That program\n>         could one day\n>         >>> evolve to include more such \"operations best practices\"\n>         tools. In\n>         >>> addition to the slight stretch already mentioned, one\n>         concern here is\n>         >>> that we still want to have performance testing in QA\n>         (which is clearly\n>         >>> essential to the production of \"OpenStack\"). Letting Rally\n>         primarily be\n>         >>> an operational tool might make that outcome more\n>         difficult.\n>         >>>\n>         >>> 3. Let Rally be a product on top of OpenStack\n>         >>> The last option is to not have Rally in any program, and\n>         not consider it\n>         >>> *essential* to the production of the \"OpenStack\"\n>         integrated release or\n>         >>> the completion of the OpenStack project mission. Rally can\n>         happily exist\n>         >>> as an operator tool on top of OpenStack. It is built as a\n>         monolithic\n>         >>> product: that approach works very well for external\n>         complementary\n>         >>> solutions... Also be more integrated in OpenStack or part\n>         of the\n>         >>> OpenStack programs might come at a cost (slicing some\n>         functionality out\n>         >>> of rally to make it more a framework and less a product)\n>         that might not\n>         >>> be what its authors want.\n>         >>>\n>         >>> Let\'s explore each option to see which ones are viable,\n>         and the pros and\n>         >>> cons of each.\n>         >>\n>         >> My feeling right now is that Rally is trying to accomplish\n>         too much at\n>         >> the start (both #1 and #2).  I would rather see the project\n>         focus on\n>         >> doing one of them as best as it can before increasing\n>         scope.\n>         >>\n>         >> It\'s my opinion that #1 is the most important thing that\n>         Rally can be\n>         >> doing to help ensure the success of OpenStack, so I\'d like\n>         to explore\n>         >> the \"Rally as a QA tool\" in more detail to start with.\n>         >\n>         > I want to clarify some things. I don\'t think that rally in\n>         it\'s current\n>         > form belongs in any OpenStack project. It\'s a giant\n>         monolythic tool,\n>         > which is apparently a design point. That\'s the wrong design\n>         point for an\n>         > OpenStack project.\n>         >\n>         > For instance:\n>         >\n>         >\n>         https://github.com/stackforge/rally/tree/master/rally/benchmark/scenarios should\n>         > all be tests in Tempest (and actually today mostly are via\n>         API tests).\n>         > There is an existing stress framework in Tempest which does\n>         the\n>         > repetitive looping that rally does on these already. This\n>         fact has been\n>         > brought up before.\n>         >\n>         >\n>         https://github.com/stackforge/rally/tree/master/rally/verification/verifiers\n>         > - should be baked back into Tempest (at least on the results\n>         side,\n>         > though diving in there now it looks largely duplicative from\n>         existing\n>         > subunit to html code).\n>         >\n>         >\n>         https://github.com/stackforge/rally/blob/master/rally/db/api.py - is\n>         > largely (not entirely) what we\'d like from a long term\n>         trending piece\n>         > that subunit2sql is working on. Again this was just all\n>         thrown into the\n>         > Rally db instead of thinking about how to split it off.\n>         Also, notable\n>         > here is there are some fundamental testr bugs (like worker\n>         > misallocation) which mean the data is massively dirty today.\n>         It would be\n>         > good for people to actually work on fixing those things.\n>         >\n>         > The parts that should stay outside of Tempest are the setup\n>         tool\n>         > (separation of concerns is that Tempest is the load runner,\n>         not the\n>         > setup environment) and any of the SLA portions.\n>         >\n>         > I think rally brings forward a good point about making\n>         Tempest easier to\n>         > run. But I think that shouldn\'t be done outside Tempest.\n>         Making the test\n>         > tool easier to use should be done in the tool itself. If\n>         that means\n>         > adding a tempest cmd or such, so be it. Note this was a\n>         topic for\n>         > discussion at last summit:\n>         > https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#QA\n>         >\n>         >> From the TC meeting, it seems that the QA group (via\n>         sdague, at least)\n>         >> has provided some feedback to Rally over the last several\n>         months.  I\n>         >> would really like to see an analysis and write-up from the\n>         QA group on\n>         >> the current state of Rally and how it may (or may not) be\n>         able to serve\n>         >> the performance QA needs.\n>         >\n>         > Something that we need to figure out is given where we are\n>         in the\n>         > release cycle do we want to ask the QA team to go off and do\n>         Rally deep\n>         > dive now to try to pull it apart into the parts that make\n>         sense for\n>         > other programs to take in. There are always trade offs.\n>         >\n>         > Like the fact that right now the rally team is proposing\n>         gate jobs which\n>         > have some overlap to the existing largeops jobs. Did they\n>         start a\n>         > conversation about it? Nope. They just went off to do their\n>         thing\n>         > instead. https://review.openstack.org/#/c/112251/\n>         >\n>         > So now we\'re going to run 2 jobs that do very similar\n>         things, with\n>         > different teams adjusting the test loads. Which I think is\n>         basically\n>         > madness.\n>         >\n>         >         -Sean\n>         >\n>         > --\n>         > Sean Dague\n>         > http://dague.net\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         \n>         --\n>         Duncan Thomas\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/c0d3ff1e/attachment.pgp>\n\n','<CA+qL3LWK5vHzc_HiFZXnDu+q4W-B1+pNVsxPsjNW+fv+dehViA@mail.gmail.com>',NULL),('<1407413864.2521.8.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 14:17:44',7200,'2014-08-07 12:17:44',NULL,'[openstack-dev] [Ironic] Proposal for slight change in our spec\n process','Hi!\n\nOn Tue, 2014-08-05 at 12:33 -0700, Devananda van der Veen wrote:\n> Hi all!\n> \n> \n> The following idea came out of last week\'s midcycle for how to improve\n> our spec process and tracking on launchpad. I think most of us liked\n> it, but of course, not everyone was there, so I\'ll attempt to write\n> out what I recall.\n> \n> \n> This would apply to new specs proposed for Kilo (since the new spec\n> proposal deadline has already passed for Juno).\n> \n> \n> \n> \n> First, create a blueprint in launchpad and populate it with your\n> spec\'s heading. Then, propose a spec with just the heading (containing\n> a link to the BP), Problem Description, and first paragraph outlining\n> your Proposed change. \n> \n> \n> This will be given an initial, high-level review to determine whether\n> it is in scope and in alignment with project direction, which will be\n> reflected on the review comments, and, if affirmed, by setting the\n> blueprint\'s \"Direction\" field to \"Approved\".\n\nHow will we formally track it in Gerrit? By having several +1\'s by spec\ncores? Or will it be done by you (I guess only you can update\n\"Direction\" in LP)?\n\n> \n> \n> At this point, if affirmed, you should proceed with filling out the\n> entire spec, and the remainder of the process will continue as it was\n> during Juno. Once the spec is approved, update launchpad to set the\n> specification URL to the spec\'s location on\n> https://specs.openstack.org/openstack/ironic-specs/ and a member of\n> the team (probably me) will update the release target, priority, and\n> status.\n> \n> \n> \n> \n> I believe this provides two benefits. First, it should give quicker\n> initial feedback to proposer if their change is going to be in/out of\n> scope, which can save considerable time if the proposal is out of\n> scope. Second, it allows us to track well-aligned specs on Launchpad\n> before they are completely approved. We observed that several specs\n> were approved at nearly the same time as the code was approved. Due to\n> the way we were using LP this cycle, it meant that LP did not reflect\n> the project\'s direction in advance of landing code, which is not what\n> we intended. This may have been confusing, and I think this will help\n> next cycle. FWIW, several other projects have observed a similar\n> problem with spec<->launchpad interaction, and are adopting similar\n> practices for Kilo.\n> \n> \n> \n> \n> Comments/discussion welcome!\n\nI\'m +1 to the idea, just some concerns about the implementation:\n1. We don\'t have any \"pre-approved\" state in Gerrit - need agreement on\nwhen to continue (see above)\n2. We\'ll need to speed up spec reviews, because we\'re adding one more\nblocker on the way to the code being merged :) Maybe it\'s no longer a\nproblem actually, we\'re doing it faster now.\n\n> \n> \n> \n> -Deva\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAExZKEpn-A12xiK38B-YvvNDN14n+XCsYE=EVcej8qxCfcSeRw@mail.gmail.com>',NULL),('<1407425261.16668.2.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 10:27:41',-18000,'2014-08-07 15:27:41',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:\n> A (the?) solution is to register_opts() in foo before importing any\n> modules which might also use oslo.config.\n\nActually, I disagree.  The real problem here is the definition of\nbar_func().  The default value of the parameter \"arg\" will likely always\nbe the default value of foo_opt, rather than the configured value,\nbecause \"CONF.foo_opt\" will be evaluated at module load time.  The way\nbar_func() should be defined would be:\n\n        def bar_func(arg=None):\n            if not arg:\n                arg = CONF.foo_opt\n            ?\n\nThat ensures that arg will be the configured value, and should also\nsolve the import conflict.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E35FC4.8060400@redhat.com>',NULL),('<1407427918.16668.6.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 11:11:58',-18000,'2014-08-07 16:11:58',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 10:55 -0500, Matt Riedemann wrote:\n> \n> On 8/7/2014 10:27 AM, Kevin L. Mitchell wrote:\n> > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:\n> >> A (the?) solution is to register_opts() in foo before importing any\n> >> modules which might also use oslo.config.\n> >\n> > Actually, I disagree.  The real problem here is the definition of\n> > bar_func().  The default value of the parameter \"arg\" will likely always\n> > be the default value of foo_opt, rather than the configured value,\n> > because \"CONF.foo_opt\" will be evaluated at module load time.  The way\n> > bar_func() should be defined would be:\n> >\n> >          def bar_func(arg=None):\n> >              if not arg:\n> >                  arg = CONF.foo_opt\n> >              ?\n> >\n> > That ensures that arg will be the configured value, and should also\n> > solve the import conflict.\n> >\n> \n> Surely you mean:\n> \n> if arg is not None:\n> \n> right?! I\'m pretty sure there is a hacking check for that now too...\n\nNo, I meant \"if not arg\", which would be true if arg is None?or 0, or\nempty string, or False.  If those alternate false values are potential\nvalues of arg, then clearly an \"if arg is None\" would be the correct\nincantation.  However, an \"if arg is not None\" would never be\nappropriate for this logic :)  (And the hacking check is against \"if arg\n== None\" or \"if arg != None\"?)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E3A18B.1080806@linux.vnet.ibm.com>',NULL),('<1407429593.16668.10.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 11:39:53',-18000,'2014-08-07 16:39:53',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 17:27 +0100, Matthew Booth wrote:\n> On 07/08/14 16:27, Kevin L. Mitchell wrote:\n> > On Thu, 2014-08-07 at 12:15 +0100, Matthew Booth wrote:\n> >> A (the?) solution is to register_opts() in foo before importing any\n> >> modules which might also use oslo.config.\n> > \n> > Actually, I disagree.  The real problem here is the definition of\n> > bar_func().  The default value of the parameter \"arg\" will likely always\n> > be the default value of foo_opt, rather than the configured value,\n> > because \"CONF.foo_opt\" will be evaluated at module load time.  The way\n> > bar_func() should be defined would be:\n> > \n> >         def bar_func(arg=None):\n> >             if not arg:\n> >                 arg = CONF.foo_opt\n> >             ?\n> > \n> > That ensures that arg will be the configured value, and should also\n> > solve the import conflict.\n> \n> That\'s different behaviour, because you can no longer pass arg=None. The\n> fix isn\'t to change the behaviour of the code.\n\nWell, the point is that the code as written is incorrect.  And if \'None\'\nis an input you want to allow, then use an incantation like:\n\n        _unset = object()\n        \n        def bar_func(arg=_unset):\n            if arg is _unset:\n                arg = CONF.foo_opt\n            ?\n\nIn any case, the operative point is that CONF.<attribute> must always be\nevaluated inside run-time code, never at module load time.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E3A90E.4090305@redhat.com>',NULL),('<1407433817.16668.13.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 12:50:17',-18000,'2014-08-07 17:50:17',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 17:44 +0100, Matthew Booth wrote:\n> These are tricky, case-by-case workarounds to a general problem which\n> can be solved by simply calling register_opts() in a place where it\'s\n> guaranteed to be safe. \n\nNo, THE CODE IS WRONG.  It is evaluating a configuration value at\n_module load time_ rather than at run time.  It is wrong for the same\nreason that \"def foo(arg={})\" is wrong.  If you fix the time at which\nevaluation occurs, importing is no longer a problem.\n\n> Is there any reason not to call register_opts()\n> before importing other modules?\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E3ACE9.6030206@redhat.com>',NULL),('<1407434095.16668.18.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 12:54:55',-18000,'2014-08-07 17:54:55',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote:\n> > In any case, the operative point is that CONF.<attribute> must\n> always be\n> > evaluated inside run-time code, never at module load time.\n> \n> ...unless you call register_opts() safely, which is what I\'m\n> proposing.\n\nNo, calling register_opts() at a different point only fixes the import\nissue you originally complained about; it does not fix the problem that\nthe configuration option is evaluated at the wrong time.  The example\ncode you included in your original email evaluates the configuration\noption at module load time, BEFORE the configuration has been loaded,\nwhich means that the argument default will be the default of the\nconfiguration option, rather than the configured value of the\nconfiguration option.  Configuration options must be evaluated at\nRUN-TIME, after configuration is loaded; they must not be evaluated at\nLOAD-TIME, which is what your original code does.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E3AD4E.6000208@redhat.com>',NULL),('<1407434522.16668.23.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 13:02:02',-18000,'2014-08-07 18:02:02',NULL,'[openstack-dev] [nova][oslo] oslo.config and import chains','On Thu, 2014-08-07 at 17:41 +0100, Matthew Booth wrote:\n> ... or arg is an object which defines __nonzero__(), or defines\n> __getattr__() and then explodes because of the unexpected lookup of a\n> __nonzero__ attribute. Or it\'s False (no quotes when printed by the\n> debugger), but has a unicode type and therefore evaluates to True[1].\n\nIf you\'re passing such exotic objects as parameters that could\npotentially be drawn from configuration instead, maybe that code needs\nto be refactored a bit :)\n\n> However, if you want to compare a value with None and write \'foo is\n> None\' it will always do exactly what you expect, regardless what you\n> pass to it. I think it\'s also nicer to the reviewer and the\n> maintainer,\n> who then don\'t need to go looking for context to check if anything\n> invalid might be passed in.\n\nIn the vast majority of cases, however, we use a value that evaluates to\nFalse to indicate \"use the default\", where \"default\" may be drawn from\nconfiguration.  Yes, there are cases where we must treat, say, 0 as\ndistinct from None, but when we don\'t need to, we should keep the code\nas simple as possible.  After all, I doubt anyone would seriously\nsuggest that we must always use something like the \"_unset\" sentinel,\neven when None has no special meaning?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<53E3AC22.7080804@redhat.com>',NULL),('<1407434786031.46041@jvf.cc>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 18:03:34',0,'2014-08-07 18:03:34',NULL,'[openstack-dev] [Ironic] Exceptional approval request for Cisco\n Driver Blueprint','Hey,\n\nI agree with Dmitry that this spec has a huge scope. If you resubmitted one with only the power interface, that could be considered for an exception.\n\nA few specific reasons:\n\n1) Auto-enrollment -- should probably be held off at the moment\n - This is something that was talked about extensively at mid-cycle meetup and will be a topic of much debate in Ironic for Kilo. Whatever comes out of that debate, if it ends up being considered within scope, would be what your spec would want to integrate with.\n - I\'d suggest you come in IRC, say hello, and work with us as we go into kilo figuring out if auto-enrollment belongs in Ironic and if so, how your hardware could integrate with that system.\n\n2) Power driver\n - If you split this out into another spec and resubmitted, it\'d be at least a small enough scope to be considered.  Just as a note though; Ironic has very specific priorities for Juno, the top of which is getting graduated. This means some new features have fallen aside in favor of graduation requirements.\n\nThanks,\nJay\n________________________________________\nFrom: Dmitry Tantsur <dtantsur at redhat.com>\nSent: Thursday, August 07, 2014 4:56 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Ironic] Exceptional approval request for Cisco Driver Blueprint\n\nHi!\n\nDidn\'t read the spec thoroughly, but I\'m concerned by it\'s huge scope.\nIt\'s actually several specs squashed into one (not too detailed). My\nvote is splitting it into a chain of specs (at least 3: power driver,\ndiscovery, other configurations) and seek exception separately.\nActually, I\'m +1 on making exception for power driver, but -0 on the\nothers, until I see a separate spec for them.\n\nDmitry.\n\nOn Thu, 2014-08-07 at 09:30 +0530, GopiKrishna Saripuri wrote:\n> Hi,\n>\n>\n> I\'ve submitted Ironic Cisco driver blueprint post proposal freeze\n> date. This driver is critical for Cisco and few customers to test as\n> part of their private cloud expansion. The driver implementation is\n> ready along with unit-tests. Will submit the code for review once\n> blueprint is accepted.\n>\n>\n> The Blueprint review link: https://review.openstack.org/#/c/110217/\n>\n>\n> Please let me know If its possible to include this in Juno release.\n>\n>\n>\n> Regards\n> GopiKrishna S\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1407412605.2521.3.camel@dhcp130-200.brq.redhat.com>',NULL),('<1407438786.3885.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 19:12:26',0,'2014-08-07 19:12:26',NULL,'[openstack-dev] [Octavia] Weekly meetings resuming + agenda','It\'s just my own preference.  Others like webex/hangouts because it can\nbe easier to talk about topics than in IRC, but with this many people\nand the latency delays, it can become quite cumbersome.  Plus, it makes\nit easier for meeting notes.  I\'ll deal with it while the majority\nreally prefer it.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-07 at 01:28 -0700, Stephen Balukoff wrote:\n> Hi Brandon,\n> \n> \n> I don\'t think we\'ve set a specific date to make the transition to IRC\n> meetings. Is there a particular urgency about this that we should be\n> aware of?\n> \n> \n> Stephen\n> \n> \n> On Wed, Aug 6, 2014 at 7:58 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         When is the plan to move the meeting to IRC?\n>         \n>         On Wed, 2014-08-06 at 15:30 -0700, Stephen Balukoff wrote:\n>         > Action items from today\'s Octavia meeting:\n>         >\n>         >\n>         > 1. We\'re going to hold off for a couple days on merging the\n>         > constitution and preliminary road map to give people (and in\n>         > particular Ebay) a chance to review and comment.\n>         > 2. Stephen is going to try to get Octavia v0.5 design docs\n>         into gerrit\n>         > review by the end of the week, or early next week at the\n>         latest.\n>         >\n>         > 3. If those with specific networking concerns could codify\n>         this and/or\n>         > figure out a way to write these down and share with the\n>         list, that\n>         > would be great. This is going to be important to ensure that\n>         our\n>         > \"operator-grade load balancer\" solution can actually meet\n>         the needs of\n>         > the operators developing it.\n>         >\n>         > Thanks,\n>         >\n>         > Stephen\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > On Tue, Aug 5, 2014 at 2:34 PM, Stephen Balukoff\n>         > <sbalukoff at bluebox.net> wrote:\n>         >         Hello!\n>         >\n>         >\n>         >         We plan on resuming weekly meetings to discuss\n>         things related\n>         >         to the Octavia project starting tomorrow: August 6th\n>         at\n>         >         13:00PDT (20:00UTC). In order to facilitate\n>         high-bandwidth\n>         >         discussion as we bootstrap the project, we have\n>         decided to\n>         >         hold these meetings via webex, with the plan to\n>         eventually\n>         >         transition to IRC. Please contact me directly if you\n>         would\n>         >         like to get in on the webex.\n>         >\n>         >\n>         >         Tomorrow\'s meeting agenda is currently as follows:\n>         >\n>         >\n>         >         * Discuss Octavia constitution and project direction\n>         documents\n>         >         currently under gerrit review:\n>         >         https://review.openstack.org/#/c/110563/\n>         >\n>         >\n>         >\n>         >         * Discuss reviews of design proposals currently\n>         under gerrit\n>         >         review:\n>         >         https://review.openstack.org/#/c/111440/\n>         >         https://review.openstack.org/#/c/111445/\n>         >\n>         >\n>         >         * Discuss operator network topology requirements\n>         based on data\n>         >         currently being collected by HP, Rackspace and Blue\n>         Box.\n>         >         (Other operators are certainly welcome to collect\n>         and share\n>         >         their data as well! I\'m looking at you, Ebay. ;) )\n>         >\n>         >\n>         >         Please feel free to respond with additional agenda\n>         items!\n>         >\n>         >\n>         >         Stephen\n>         >\n>         >\n>         >         --\n>         >         Stephen Balukoff\n>         >         Blue Box Group, LLC\n>         >         (800)613-4305 x807\n>         >\n>         >\n>         >\n>         >\n>         > --\n>         > Stephen Balukoff\n>         > Blue Box Group, LLC\n>         > (800)613-4305 x807\n>         \n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZpzNr9zrBJ5FFAKD4GBSZJCAtchA=tsz_RLg3D7Pf-W2g@mail.gmail.com>',NULL),('<1407440816.3885.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 19:46:15',0,'2014-08-07 19:46:15',NULL,'[openstack-dev] [Octavia] Weekly meetings resuming + agenda','Those are definitely other big reasons, and probably the reason it is\nplanned to move to IRC in the future, no matter what.  I was just\nwondering how soon, if soon at all.\n\nOn Thu, 2014-08-07 at 12:35 -0700, Stefano Maffulli wrote:\n> On Thu 07 Aug 2014 12:12:26 PM PDT, Brandon Logan wrote:\n> > It\'s just my own preference.  Others like webex/hangouts because it can\n> > be easier to talk about topics than in IRC, but with this many people\n> > and the latency delays, it can become quite cumbersome.  Plus, it makes\n> > it easier for meeting notes.  I\'ll deal with it while the majority\n> > really prefer it.\n> \n> Most of all, if you\'re interested in including people whose primary \n> language is not English, IRC (or text-based communication) is a lot \n> more accessible than voice.\n> \n> Also, skimming through written logs from IRC is a lot easier/faster \n> than listening to audio recordings for those that couldn\'t join in real \n> time.\n> \n> /stef\n\n\n','<53E3D519.8090608@openstack.org>',NULL),('<1407451732858.6990@jvf.cc>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 22:48:53',0,'2014-08-07 22:48:53',NULL,'[openstack-dev] [Ironic] [Infra] Devstack and Testing for\n	ironic-python-agent``','Hi all,\n\n\nAt the recent Ironic mid-cycle meetup, we got the first version of the ironic-python-agent (IPA) driver merged. There are a few reviews we need merged (and their dependencies) across a few other projects in order to begin testing it automatically. We would like to eventually gate IPA and Ironic with tempest testing similar to what the pxe driver does today.\n\n\nFor IPA to work in devstack (openstack-dev/devstack repo):\n\n - https://review.openstack.org/#/c/112095 Adds swift temp URL support to Devstack\n\n - https://review.openstack.org/#/c/108457 Adds IPA support to Devstack\n\n\n\nDocs on running IPA in devstack (openstack/ironic repo):\n\n - https://review.openstack.org/#/c/112136/\n\n\n\nFor IPA to work in the devstack-gate environment (openstack-infra/config & openstack-infra/devstack-gate repos):\n\n - https://review.openstack.org/#/c/112143 Add IPA support to devstack-gate\n\n - https://review.openstack.org/#/c/112134 Consolidate and rename Ironic jobs\n\n - https://review.openstack.org/#/c/112693 Add check job for IPA + tempest\n\n\nOnce these are all merged, we\'ll have IPA testing via a nonvoting check job, using the IPA-CoreOS deploy ramdisk, in both the ironic and ironic-python-agent projects. This will be promoted to voting once proven stable.\n\n\nHowever, this is only one of many possible IPA deploy ramdisk images. We\'re currently publishing a CoreOS ramdisk, but we also have an effort to create a ramdisk with diskimage-builder (https://review.openstack.org/#/c/110487/) , as well as plans for an ISO image (for use with things like iLo). As we gain additional images, we\'d like to run those images through the same suite of tests prior to publishing them, so that images which would break IPA\'s gate wouldn\'t get published. The final state testing matrix should look something like this, with check and gate jobs in each project covering the variations unique to that project, and one representative test in consuming project\'s test pipelines.\n\n\nIPA:\n\n - tempest runs against Ironic+agent_ssh with CoreOS ramdisk\n\n - tempest runs against Ironic+agent_ssh with DIB ramdisk\n\n - (other IPA tests)\n\n\n\nIPA would then, as a post job, generate and publish the images, as we currently do with IPA-CoreOS ( http://tarballs.openstack.org/ironic-python-agent/coreos/ipa-coreos.tar.gz ). Because IPA would gate on tempest tests against each image, we\'d avoid ever publishing a bad deploy ramdisk.\n\n\nIronic:\n\n - tempest runs against Ironic+agent_ssh with most suitable ramdisk (due to significantly decreased ram requirements, this will likely be an image created by DIB once it exists)\n\n - tempest runs against Ironic+pxe_ssh\n\n - (what ever else Ironic runs)\n\n\n\nNova and other integrated projects will continue to run a single job, using Ironic with its default deploy driver (currently pxe_ssh).\n\n\n\n\n\nUsing this testing matrix, we\'ll ensure that there is coverage of each cross-project dependency, without bloating each project\'s test matrix unnecessarily. If, for instance, a change in Nova passes the Ironic pxe_ssh job and lands, but then breaks the agent_ssh job and thus blocks Ironic\'s gate, this would indicate a layering violation between Ironic and its deploy drivers (from Nova\'s perspective, nothing should change between those drivers). Similarly, if IPA tests failed against the CoreOS image (due to Ironic OR Nova change), but the DIB image passed in both Ironic and Nova tests, then it\'s almost certainly an *IPA* bug.\n\n\nThanks so much for your time, and for the Openstack Ironic community being welcoming to us as we have worked towards this alternate deploy driver and work towards improving it even further as Kilo opens.\n\n\n--\n\nJay Faulkner\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/bacf56cc/attachment.html>\n\n',NULL,NULL),('<1407504855-sup-8935@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-08 06:37:21',-25200,'2014-08-08 13:37:21',NULL,'[Openstack] Wordpress template','You\'ll find documentation for the OS::Nova::Server resource here:\n\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server\n\nSo you\'ll need to add this to the properties section:\n\n    properties:\n      networks:\n        - { network: public }\n        - { network: private }\n\nExcerpts from yalla.gnan.kumar\'s message of 2014-08-08 06:01:48 -0700:\n> Hi All,\n> \n> Please let me know if anybody knows how to troubleshoot this issue.\n> \n> \n> Thanks\n> Kumar\n> \n> From: Gnan Kumar, Yalla\n> Sent: Friday, August 08, 2014 10:46 AM\n> To: openstack at lists.openstack.org\n> Subject: Wordpress template\n> \n> Hi All,\n> \n> I am trying to launch an instance with wordpress application from the heat  template downloaded from\n> https://raw.github.com/openstack/heat-templates/master/cfn/F17/WordPress_Composed_Instances.template\n> \n> But the following error is being shown:\n> \n> Error: Resource CREATE failed: BadRequest: Multiple possible networks found, use a Network ID to be more specific.\n> \n> I have created two networks . One is public for floating point IP and other is private. How to specify the network ID\n> in the above  template ?\n> \n> \n> \n> \n> Thanks\n> Kumar\n> \n\n\n','<67765C71374B974FBFD2AD05AF438EFF0BDEAF34@048-CH1MPN3-361.048d.mgd.msft.net>',NULL),('<1407528917.53e52fd54f55a@www.imp.polymtl.ca>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-08 16:15:17',-14400,'2014-08-08 20:15:17',NULL,'[Openstack] Heat-IceHouse, stack creation fails','Hi Steve,\nThanks for your help. I tried either files but in both cases I get the same \nerror. I copy the output below. It seems that the OS variables are exported\nproperly. Any help is appreciated.\nHere is the output after executing the suggested script:\n\n#./heat-keystone-setup-domain\nINFO (connectionpool:258) Starting new HTTP connection (1): controller\nINFO (heat-keystone-setup-domain:71) Creating domain heat\nINFO (connectionpool:258) Starting new HTTP connection (1): controller\nTraceback (most recent call last):\n  File \"./heat-keystone-setup-domain\", line 112, in <module>\n    main()\n  File \"./heat-keystone-setup-domain\", line 74, in main\n    description=HEAT_DOMAIN_DESCRIPTION)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/utils.py\", line 318, in\ninner\n    return func(*args, **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/v3/domains.py\", line 43,\nin create\n    **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 66, in\nfunc\n    return f(*args, **new_kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 314, in\ncreate\n    self.key)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 142, in\n_create\n    return self._post(url, body, response_key, return_raw)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 155, in\n_post\n    resp, body = self.client.post(url, body=body)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n596, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n582, in _cs_request\n    return self.request(url, method, **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n564, in request\n    resp = super(HTTPClient, self).request(url, method, **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/baseclient.py\", line 21,\nin request\n    return self.session.request(url, method, **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/utils.py\", line 318, in\ninner\n    return func(*args, **kwargs)\n  File \"/usr/lib/python2.7/dist-packages/keystoneclient/session.py\", line 251,\nin request\n    raise exceptions.from_response(resp, method, url)\nkeystoneclient.apiclient.exceptions.Forbidden: You are not authorized to perform\nthe requested action, identity:create_domain. (HTTP 403)\n\nThanks,\nParisa\n>On 06/08/14 14:32, Anne Gentle wrote:\n>>\n>>\n>>\n>> On Tue, Aug 5, 2014 at 9:13 PM, Steve Baker <sbaker [at] redhat\n>> <mailto:sbaker [at] redhat>> wrote:\n>>\n>> On 06/08/14 09:25, Parisa Heidari wrote:\n>>> Hi,\n>>> I am trying Heat - IceHouse but I cannot even create a tiny VM as explained\nin\n>>> the documents\n>>>\n(http://docs.openstack.org/icehouse/install-guide/install/apt/content/heat-verify.html).\n>>> In Heat-engine log file, I saw that \"stack-user-domain\" ID is not set in the\n>>> heat.conf file. So I modified heat.conf and added admin ID (the one defined\n>>> when Keystone was installed and configured) and its name and password for\n>>> stack_user_domain, stack_domain_admin, and stack_domain_admin_password,\n>>> respectively. But still stack creation fails and I see in the logs that\n>>> \"ClientException: The server has either erred or is incapable of performing\nthe\n>>> requested operation\".\n>>>\n>>> What should be set in heat.conf as stack-user-domain and other corresponding\n>>> variables? should I create a new domain for Heat and how?\n>>>\n>>> Many thanks,\n>>> Parisa\n>>>\n>> It looks like you need to run the heat-keystone-setup-domain\n>> script and copy the resulting snippet into heat.conf\n>>\n>>\n>>\n>> Hi Steve,\n>> Should that script be part of the install docs? Currently it just\n>> says to Create the heat_stack_user role.\n>>\n>> I can log a doc bug, just want to be clear what it is that\'s missing.\n>>\n>We do have https://bugs.launchpad.net/heat/+bug/1326483 for the missing\nman page.\n>\n>For the doc bug, the heat installation instructions need to describe\n>when and how to run heat-keystone-setup-domain[1]\n>but actually for the icehouse release of heat the script is\n>create_heat_domain[2]\n\n>Having said all that, if the heat domain is not configured there is\n>fallback code which reverts to the Havana behaviour of requiring the\n>stack launching user be an admin, and _that_ may be the cause of\n>Parisa\'s error above.\n\n>[1]\n>http://git.openstack.org/cgit/openstack/heat/tree/bin/heat-keystone-setup-domain\n>[2]\n>http://git.openstack.org/cgit/openstack/heat/tree/tools/create_heat_domain?h=stable/icehouse\n\n\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1407619774.8175.16.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-09 21:29:27',0,'2014-08-09 21:29:27',NULL,'[openstack-dev]  [Neutron][LBaaS] Improvements to current reviews','So I\'ve done some work on improving the code on the current pending\nreviews.  And would like to get peoples\' opinions on whether I should\nadd antoher patch set to those reviews, or add the changes as as another\nreview dependent on the pending ones.\n\nTo be clear, no matter what the first review in the chain will not\nchange:\nhttps://review.openstack.org/#/c/105331/\n\nHowever, if adding another patch set is preferrable then plugin and db\nimplementation review would get another patch set and then obviously\nanything depending on that.\n\nhttps://review.openstack.org/#/c/105609/\n\nMy opinion is that I\'d like to get both of these in as a new patch set.\nReason being that the reviews don\'t have any +2\'s and there is\nuncertainty because of the GBP discussion.  So, I don\'t think it\'d be a\nmajor issue if a new patch set was created.  Speak up if you think\notherwise.  I\'d like to get as many people\'s thoughts as possible.\n\nThe changes are:\n\n1) Added data models, which are just plain python object mimicking the\nsql alchemy models, but don\'t have the overhead or dynamic nature of\nbeing sql alchemy models.  These data models are now returned by the\ndatabase methods, instead of the sql alchemy objects.  Also, I moved the\ndefinition of the sql alchemy models into its own module.  I\'ve been\nwanting to do this but since I thought I was running out of time I left\nit for later.\n\nThese shouldn\'t cause many merge/rebase conflicts, but it probably cause\na few because the sql alchemy models were moved to a different module.\n\n\n2) The LoadBalancerPluginv2 no longer inherits from the\nLoadBalancerPluginDbv2.  The database is now a composite attribute of\nthe plugin (i.e. plugin.db.get_loadbalancer()).  This cleans up the code\na bit and removes the necessity for _delete_db_entity methods that the\ndrivers needed because now they can actually call the database methods.\nAlso, this makes testing more clear, though I have not added any tests\nfor this because the previous tests are sufficient for now.  Adding the\nappropriate tests would add 1k or 2k lines most likely.\n\nThis will likely cause more conflicts because the _db_delete_entity\nmethods have been removed.  However, the new driver interface/mixins\ndefined a db_method for all drivers to use, so if that is being used\nthere shouldn\'t be any problems.\n\nThanks,\nBrandon\n\n\n\n\n\n','<D0082273.790D%dougw@a10networks.com>',NULL),('<1407735502.53e856ce361c2@www.imp.polymtl.ca>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-11 01:38:22',-14400,'2014-08-11 05:38:22',NULL,'[Openstack] Heat-IceHouse, stack creation fails','I run it as \'root\'.\n\n>You need to be an admin to run this script.\n\n>On Fri, Aug 08, 2014 at 04:15:17PM -0400, Parisa Heidari wrote:\n>> Hi Steve,\n>> Thanks for your help. I tried either files but in both cases I get the same\n>> error. I copy the output below. It seems that the OS variables are exported\n>> properly. Any help is appreciated.\n>> Here is the output after executing the suggested script:\n>>\n>> #./heat-keystone-setup-domain\n>> INFO (connectionpool:258) Starting new HTTP connection (1): controller\n>> INFO (heat-keystone-setup-domain:71) Creating domain heat\n>> INFO (connectionpool:258) Starting new HTTP connection (1): controller\n>> Traceback (most recent call last):\n>>   File \"./heat-keystone-setup-domain\", line 112, in <module>\n>>     main()\n>>   File \"./heat-keystone-setup-domain\", line 74, in main\n>>     description=HEAT_DOMAIN_DESCRIPTION)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/utils.py\", line 318,\nin\n>> inner\n>>     return func(*args, **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/v3/domains.py\", line\n43,\n>> in create\n>>     **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 66, in\n>> func\n>>     return f(*args, **new_kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 314,\nin\n>> create\n>>     self.key)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 142,\nin\n>> _create\n>>     return self._post(url, body, response_key, return_raw)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/base.py\", line 155,\nin\n>> _post\n>>     resp, body = self.client.post(url, body=body)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n>> 596, in post\n>>     return self._cs_request(url, \'POST\', **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n>> 582, in _cs_request\n>>     return self.request(url, method, **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/httpclient.py\", line\n>> 564, in request\n>>     resp = super(HTTPClient, self).request(url, method, **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/baseclient.py\", line\n21,\n>> in request\n>>     return self.session.request(url, method, **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/utils.py\", line 318,\nin\n>> inner\n>>     return func(*args, **kwargs)\n>>   File \"/usr/lib/python2.7/dist-packages/keystoneclient/session.py\", line\n251,\n>> in request\n>>     raise exceptions.from_response(resp, method, url)\n>> keystoneclient.apiclient.exceptions.Forbidden: You are not authorized to\nperform\n>> the requested action, identity:create_domain. (HTTP 403)\n>>\n>> Thanks,\n>> Parisa\n>> >On 06/08/14 14:32, Anne Gentle wrote:\n>> >>\n>> >>\n>> >>\n>> >> On Tue, Aug 5, 2014 at 9:13 PM, Steve Baker <sbaker [at] redhat\n>> >> <mailto:sbaker [at] redhat>> wrote:\n>> >>\n>> >> On 06/08/14 09:25, Parisa Heidari wrote:\n>> >>> Hi,\n>> >>> I am trying Heat - IceHouse but I cannot even create a tiny VM as\nexplained\n>> in\n>> >>> the documents\n>> >>>\n>>\n(http://docs.openstack.org/icehouse/install-guide/install/apt/content/heat-verify.html).\n>> >>> In Heat-engine log file, I saw that \"stack-user-domain\" ID is not set in\nthe\n>> >>> heat.conf file. So I modified heat.conf and added admin ID (the one\ndefined\n>> >>> when Keystone was installed and configured) and its name and password for\n>> >>> stack_user_domain, stack_domain_admin, and stack_domain_admin_password,\n>> >>> respectively. But still stack creation fails and I see in the logs that\n>> >>> \"ClientException: The server has either erred or is incapable of\nperforming\n>> the\n>> >>> requested operation\".\n>> >>>\n>> >>> What should be set in heat.conf as stack-user-domain and other\ncorresponding\n>> >>> variables? should I create a new domain for Heat and how?\n>> >>>\n>> >>> Many thanks,\n>> >>> Parisa\n>> >>>\n>> >> It looks like you need to run the heat-keystone-setup-domain\n>> >> script and copy the resulting snippet into heat.conf\n>> >>\n>> >>\n>> >>\n>> >> Hi Steve,\n>> >> Should that script be part of the install docs? Currently it just\n>> >> says to Create the heat_stack_user role.\n>> >>\n>> >> I can log a doc bug, just want to be clear what it is that\'s missing.\n>> >>\n>> >We do have https://bugs.launchpad.net/heat/+bug/1326483 for the missing\n>> man page.\n>> >\n>> >For the doc bug, the heat installation instructions need to describe\n>> >when and how to run heat-keystone-setup-domain[1]\n>> >but actually for the icehouse release of heat the script is\n>> >create_heat_domain[2]\n>>\n>> >Having said all that, if the heat domain is not configured there is\n>> >fallback code which reverts to the Havana behaviour of requiring the\n>> >stack launching user be an admin, and _that_ may be the cause of\n>> >Parisa\'s error above.\n>>\n>> >[1]\n>>\n>http://git.openstack.org/cgit/openstack/heat/tree/bin/heat-keystone-setup-domain\n>> >[2]\n>>\n>http://git.openstack.org/cgit/openstack/heat/tree/tools/create_heat_domain?h=stable/icehouse\n>>\n>>\n\n\n\n','<1407528917.53e52fd54f55a@www.imp.polymtl.ca>',NULL),('<1407736696692.19341@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-11 05:51:50',0,'2014-08-11 05:51:50',NULL,'[Openstack] Error: Unable to retrieve instance list.','Hi Giles,\n\n\nI am not sure about the issue, but can you please check if the database is up. Also can you paste the error in nova logs?\n\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: Giles Cornelius Gomes <Giles.Cornelius at novotel-bd.com>\nSent: Sunday, August 10, 2014 3:42 PM\nTo: <openstack at lists.openstack.org>\nSubject: [Openstack] Error: Unable to retrieve instance list.\n\nHello,\n\n\"Error: Unable to retrieve instance list\"  is showing while I was trying to launch an instance. Please let me know the reason and remedy.\n\nBest regards,\n\nGiles Cornelius Gomes\nDatabase Administrator (Billing)\nNovoTel Limited\nHouse: Ga-30/G, Pragati Sarani\nShahjadpur, Gulshan-2\nDhaka-1212, Bangladesh\n\nTel: +880-2-8899657; Ext: 212\nFax: +880-2-8899654\nWeb: www.novotel-bd.com<http://www.novotel-bd.com/>\n[Description: Description: Description: Description: cid:image001.jpg at 01CB113F.29C354B0]\nDisclaimer:\n\nThis e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this e-mail or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful.\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140811/e6c01b90/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.jpg\nType: image/jpeg\nSize: 2710 bytes\nDesc: image001.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140811/e6c01b90/attachment.jpg>\n\n','<AD41092FC432674AA9A94C71EA538FDA07D71346F3@Email.novotel-bd.com>',NULL),('<1407740363.2813.48.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 07:59:23',3600,'2014-08-11 06:59:23',NULL,'[openstack-dev] [nova] fair standards for all hypervisor drivers','On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote:\n> On 08/07/2014 08:06 PM, Michael Still wrote:\n> > It seems to me that the tension here is that there are groups who\n> > would really like to use features in newer libvirts that we don\'t CI\n> > on in the gate. Is it naive to think that a possible solution here is\n> > to do the following:\n> > \n> >  - revert the libvirt version_cap flag\n> \n> I don\'t feel strongly either way on this.  It seemed useful at the time\n> for being able to decouple upgrading libvirt and enabling features that\n> come with that.\n\nRight, I suggested the flag as a more deliberate way of avoiding the\nissue that was previously seen in the gate with live snapshots. I still\nthink it\'s a pretty elegant and useful little feature, and don\'t think\nwe need to use it as proxy battle over testing requirements for new\nlibvirt features.\n\nMark.\n\n\n\n','<53E4CB55.7010100@redhat.com>',NULL),('<1407752346.49008.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-11 18:19:06',28800,'2014-08-11 10:19:06',NULL,'[Openstack] [TripleO] Adding a new node to instack RDO setup','Hi all,\n\nI have successfully set up tripleo using instack RDO in a virtual\nmachine environment. My undercloud and overcloud all are in VMs.\nNow, I need to add a new physical baremetal node to the setup. I?\nhave the mac address of the node to be added. I registered the node\nand in the openstack deployment tab I tried to add 1 free node as?\ncompute node. But as I click deploy, I get the following error:\n\n\"HTTPResponse insatnce has no attribute \'headers\' \"\n\nAny ideas on how to resolve this error?\n?\nRegards,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140811/f1a7eb85/attachment.html>\n\n',NULL,NULL),('<1407767535-sup-5697@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 07:46:23',-25200,'2014-08-11 14:46:23',NULL,'[openstack-dev] [TripleO][heat] a small experiment with Ansible\n	in TripleO','Excerpts from Steve Baker\'s message of 2014-08-10 15:33:26 -0700:\n> On 02/08/14 04:07, Allison Randal wrote:\n> > A few of us have been independently experimenting with Ansible as a\n> > backend for TripleO, and have just decided to try experimenting\n> > together. I\'ve chatted with Robert, and he says that TripleO was always\n> > intended to have pluggable backends (CM layer), and just never had\n> > anyone interested in working on them. (I see it now, even in the early\n> > docs and talks, I guess I just couldn\'t see the forest for the trees.)\n> > So, the work is in line with the overall goals of the TripleO project.\n> >\n> > We\'re starting with a tiny scope, focused only on updating a running\n> > TripleO deployment, so our first work is in:\n> >\n> > - Create an Ansible Dynamic Inventory plugin to extract metadata from Heat\n> > - Improve/extend the Ansible nova_compute Cloud Module (or create a new\n> > one), for Nova rebuild\n> > - Develop a minimal handoff from Heat to Ansible, particularly focused\n> > on the interactions between os-collect-config and Ansible\n> >\n> > We\'re merging our work in this repo, until we figure out where it should\n> > live:\n> >\n> > https://github.com/allisonrandal/tripleo-ansible\n> >\n> > We\'ve set ourselves one week as the first sanity-check to see whether\n> > this idea is going anywhere, and we may scrap it all at that point. But,\n> > it seems best to be totally transparent about the idea from the start,\n> > so no-one is surprised later.\n> >\n> Having pluggable backends for configuration seems like a good idea, and\n> Ansible is a great choice for the first alternative backend.\n> \n\nTripleO is intended to be loosely coupled for many components, not just\nin-instance configuration.\n\n> However what this repo seems to be doing at the moment is bypassing heat\n> to do a stack update, and I can only assume there is an eventual goal to\n> not use heat at all for stack orchestration too.\n>\n>\n> Granted, until blueprint update-failure-recovery lands[1] then doing a\n> stack-update is about as much fun as russian roulette. But this effort\n> is tactical rather than strategic, especially given TripleO\'s mission\n> statement.\n> \n\nWe intend to stay modular. Ansible won\'t replace Heat from end to end.\n\nRight now we\'re stuck with an update that just doesn\'t work. It isn\'t\njust about update-failure-recovery, which is coming along nicely, but\nit is also about the lack of signals to control rebuild, poor support\nfor addressing machines as groups, and unacceptable performance in\nlarge stacks.\n\nWe remain committed to driving these things into Heat, which will allow\nus to address these things the way a large scale operation will need to.\n\nBut until we can land those things in Heat, we need something more\nflexible like Ansible to go around Heat and do things in the exact\norder we need them done. Ansible doesn\'t have a REST API, which is a\nnon-starter for modern automation, but the need to control workflow is\ngreater than the need to have a REST API at this point.\n\n> If I were to use Ansible for TripleO configuration I would start with\n> something like the following:\n> * Install an ansible software-config hook onto the image to be triggered\n> by os-refresh-config[2][3]\n> * Incrementally replace StructuredConfig resources in\n> tripleo-heat-templates with SoftwareConfig resources that include the\n> ansible playbooks via get_file\n> * The above can start in a fork of tripleo-heat-templates, but can\n> eventually be structured using resource providers so that the deployer\n> chooses what configuration backend to use by selecting the environment\n> file that contains the appropriate config resources\n> \n> Now you have a cloud orchestrated by heat and configured by Ansible. If\n> it is still deemed necessary to do an out-of-band update to the stack\n> then you\'re in a much better position to do an ansible push, since you\n> can use the same playbook files that heat used to bring up the stack.\n> \n\nThat would be a good plan if we wanted to fix issues with os-*-config,\nbut that is the opposite of reality. We are working around Heat\norchestration issues with Ansible.\n\n\n','<53E7F336.9090308@redhat.com>',NULL),('<1407770933-sup-8674@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 11:20:50',-25200,'2014-08-11 18:20:50',NULL,'[openstack-dev] [TripleO][heat] a small experiment with Ansible\n	in TripleO','Excerpts from Zane Bitter\'s message of 2014-08-11 08:16:56 -0700:\n> On 11/08/14 10:46, Clint Byrum wrote:\n> > Right now we\'re stuck with an update that just doesn\'t work. It isn\'t\n> > just about update-failure-recovery, which is coming along nicely, but\n> > it is also about the lack of signals to control rebuild, poor support\n> > for addressing machines as groups, and unacceptable performance in\n> > large stacks.\n> \n> Are there blueprints/bugs filed for all of these issues?\n> \n\nConvergnce addresses the poor performance for large stacks in general.\nWe also have this:\n\nhttps://bugs.launchpad.net/heat/+bug/1306743\n\nWhich shows how slow metadata access can get. I have worked on patches\nbut haven\'t been able to complete them. We made big strides but we are\nat a point where 40 nodes polling Heat every 30s is too much for one CPU\nto handle. When we scaled Heat out onto more CPUs on one box by forking\nwe ran into eventlet issues. We also ran into issues because even with\nmany processes we can only use one to resolve templates for a single\nstack during update, which was also excessively slow.\n\nWe haven\'t been able to come back around to those yet, but you can see\nwhere this has turned into a bit of a rat hole of optimization.\n\naction-aware-sw-config is sort of what we want for rebuild. We\ncollaborated with the trove devs on how to also address it for resize\na while back but I have lost track of that work as it has taken a back\nseat to more pressing issues.\n\nAddressing groups is a general problem that I\'ve had a hard time\narticulating in the past. Tomas Sedovic has done a good job with this\nTripleO spec, but I don\'t know that we\'ve asked for an explicit change\nin a bug or spec in Heat just yet:\n\nhttps://review.openstack.org/#/c/97939/\n\nThere are a number of other issues noted in that spec which are already\naddressed in Heat, but require refactoring in TripleO\'s templates and\ntools, and that work continues.\n\nThe point remains: we need something that works now, and doing an\nalternate implementation for updates is actually faster than addressing\nall of these issues.\n\n\n','<53E8DE68.3080005@redhat.com>',NULL),('<1407772439.4092.12.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 15:52:45',0,'2014-08-11 15:52:45',NULL,'[openstack-dev] [Neutron][LBaaS] Continuing on \"Calling driver\n interface on every API request\"','Yeah what I meant was the only solution I could come up with so that the\ndriver gets passed every call is to have the every entity have a\nprovider.  I do believe this is a bit cumbersome for a user, and extra\nvalidation would be needed to verify that two entities linked together\ncannot have different providers, but that would be pretty easy.  In my\nopinion, it\'d be a bit weird to have them all have a provider.  However,\nthere are some pros to it such as:\n\n1) Driver always gets the create, update, and delete calls.\n2) If drivers support a varying range of values for certain entity\nattributes, that validation can be caught immediately if thats something\npeople wanted.\n3) Will remove the necessity of a DEFERRED status for some drivers\n(This also brings up a CON, in that some drivers may use DEFERRED and\nsome may not, which leads to an inconsistent UX).\n4) Status management in some drivers will become a bit easier.\n\nStill I don\'t think it is something that should be done because having\nthe user give a provider for every entity is a bit cumbersome.  Though\nif enough people want this then a larger discussion about it should\nprobably happen.\n\nThanks,\nBrandon\n\nOn Mon, 2014-08-11 at 13:57 +0000, Samuel Bercovici wrote:\n> Hi,\n> \n>  \n> \n> Validations such as ?timeout > delay? should be performed on the API\n> level before it reaches the driver.\n> \n>  \n> \n> For a configuration tree (lb, listeners, pools, etc.), there should be\n> one provider. \n> \n> Having provider defined in multiple places does not make sense.\n> \n>  \n> \n>  \n> \n> -San.\n> \n>  \n> \n>  \n> \n> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com] \n> Sent: Monday, August 11, 2014 2:43 PM\n> To: OpenStack Development Mailing List\n> (openstack-dev at lists.openstack.org)\n> Subject: [openstack-dev] [Neutron][LBaaS] Continuing on \"Calling\n> driver interface on every API request\"\n> \n> \n>  \n> \n> Hi:\n> \n>  \n> \n> Continuing from last week?s LBaaS meeting?\n> \n>  \n> \n> Currently an entity cannot be sent to driver unless it is linked to\n> loadbalancer because loadbalancer is the root object and driver\n> information is only available with loadbalancer. \n> \n>  \n> \n> The request to the driver is delayed because of which error\n> propagation becomes tricky.\n> \n>  \n> \n> Let?s say a monitor was configured with timeout > delay there would be\n> no error then.\n> \n> When a listener is configured there will be a monitor\n> creation/deployment error like ?timeout configured greater than\n> delay?.\n> \n>  \n> \n> Unless the error is very clearly crafted the user won?t be able to\n> understand the error.\n> \n>  \n> \n> I am half-heartedly OK with current approach. \n> \n>  \n> \n> But, I would prefer Brandon?s Solution ? make provider an attribute in\n> each of the entities to get rid of this problem. \n> \n>  \n> \n> What do others think?\n> \n>  \n> \n> Thanks,\n> \n> Vijay V.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F36E8145F2571242A675F56CF609645611A1E098@ILMB1.corp.radware.com>',NULL),('<1407778960.8629.9.camel@graham-desk-13-10>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 17:41:08',0,'2014-08-11 17:41:08',NULL,'[openstack-dev] [designate] [neutron] designate and neutron\n integration','kazuhiro MIYASHITA,\n\nAs designate progresses with server pools, we aim to have support for a\n\'private\' dns server, that could run within a neutron network - is that\nthe level of integration you were referring to?\n\nThat is, for the time being, a long term goal, and not covered by Carl\'s\nKilo blueprint.\n\nWe talked with both people from both Neutron and Nova in Atlanta, and\nworked out the first steps for designate / neutron integration (auto\nprovisioning of records)\n\nFor that level of integration, we are assuming that a neutron router\nwill be involved in DNS queries within a network.\n\nLong term I would prefer to see a \'private pool\' connecting directly to\nthe Network2 (like any other service VM (LBaaS etc)) and have dnsmasq\npass on only records hosted by that \'private pool\' to designate.\n\nThis is all yet to be fleshed out, so I am open to suggestions. It\nrequires that we complete server pools, and that work is only just\nstarting (it was the main focus of our mid-cycle 2 weeks ago).\n\nGraham\n\nOn Mon, 2014-08-11 at 11:02 -0600, Carl Baldwin wrote:\n> kazuhiro MIYASHITA,\n> \n> I have done a lot of thinking about this.  I have a blueprint on hold\n> until Kilo for Neutron/Designate integration [1].\n> \n> However, my blueprint doesn\'t quite address what you are going after\n> here.  An assumption that I have made is that Designate is an external\n> or internet facing service so a Neutron router needs to be in the\n> datapath to carry requests from dnsmasq to an external network.  The\n> advantage of this is that it is how Neutron works today so there is no\n> new development needed.\n> \n> Could you elaborate on the advantages of connecting dnsmasq directly\n> to the external network where Designate will be available?\n> \n> Carl\n> \n> [1] https://review.openstack.org/#/c/88624/\n> \n> On Mon, Aug 11, 2014 at 7:51 AM, Miyashita, Kazuhiro\n> <miyakz at jp.fujitsu.com> wrote:\n> > Hi,\n> >\n> > I want to ask about neutron and designate integration.\n> > I think dnsmasq fowards DNS request from instance to designate is better.\n> >\n> >                            +------------------------+\n> >                            |DNS server(designate)   |\n> >                            +------------------------+\n> >                                 |\n> > -----------------+--------------+------ Network1\n> >                  |\n> >               +--------+\n> >               |dnsmasq |\n> >               +--------+\n> >                 |\n> > -+--------------+---------------------- Network2\n> >  |\n> > +---------+\n> > |instance |\n> > +---------+\n> >\n> > Because it\'s simpler than virtual router connects Network1 and Network2.\n> > If router connects network, instance should know where DNS server is. it is complicated.\n> > dnsmasq returns its ip address as dns server in DHCP replay by ordinary, so,\n> > I think good dnsmasq becomes like a gateway to designate.\n> >\n> > But, I can\'t connect dnsmasq to Network1. because of today\'s neutron design.\n> >\n> > Question:\n> >   Does designate design team have a plan such as above integration?\n> >   or other integration design?\n> >\n> > *1: Network1 and Network2 are deployed by neutron.\n> > *2: neutron deploys dnsmasq as a dhcp server.\n> >     dnsmasq can forward DNS request.\n> >\n> > Thanks,\n> >\n> > kazuhiro MIYASHITA\n> >\n> >\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CALiLy7o1pRMy1e6KvZM__B5bEohaeU5YY=puim2f9jbneh_JuQ@mail.gmail.com>',NULL),('<1407782891-sup-6055@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 11:49:42',-25200,'2014-08-11 18:49:42',NULL,'[openstack-dev] [TripleO][heat] a small experiment with Ansible\n	in TripleO','Excerpts from Steven Hardy\'s message of 2014-08-11 11:40:07 -0700:\n> On Mon, Aug 11, 2014 at 11:20:50AM -0700, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-08-11 08:16:56 -0700:\n> > > On 11/08/14 10:46, Clint Byrum wrote:\n> > > > Right now we\'re stuck with an update that just doesn\'t work. It isn\'t\n> > > > just about update-failure-recovery, which is coming along nicely, but\n> > > > it is also about the lack of signals to control rebuild, poor support\n> > > > for addressing machines as groups, and unacceptable performance in\n> > > > large stacks.\n> > > \n> > > Are there blueprints/bugs filed for all of these issues?\n> > > \n> > \n> > Convergnce addresses the poor performance for large stacks in general.\n> > We also have this:\n> > \n> > https://bugs.launchpad.net/heat/+bug/1306743\n> > \n> > Which shows how slow metadata access can get. I have worked on patches\n> > but haven\'t been able to complete them. We made big strides but we are\n> > at a point where 40 nodes polling Heat every 30s is too much for one CPU\n> > to handle. When we scaled Heat out onto more CPUs on one box by forking\n> > we ran into eventlet issues. We also ran into issues because even with\n> > many processes we can only use one to resolve templates for a single\n> > stack during update, which was also excessively slow.\n> \n> Related to this, and a discussion we had recently at the TripleO meetup is\n> this spec I raised today:\n> \n> https://review.openstack.org/#/c/113296/\n> \n> It\'s following up on the idea that we could potentially address (or at\n> least mitigate, pending the fully convergence-ified heat) some of these\n> scalability concerns, if TripleO moves from the one-giant-template model\n> to a more modular nested-stack/provider model (e.g what Tomas has been\n> working on)\n> \n> I\'ve not got into enough detail on that yet to be sure if it\'s acheivable\n> for Juno, but it seems initially to be complex-but-doable.\n> \n> I\'d welcome feedback on that idea and how it may fit in with the more\n> granular convergence-engine model.\n> \n> Can you link to the eventlet/forking issues bug please?  I thought since\n> bug #1321303 was fixed that multiple engines and multiple workers should\n> work OK, and obviously that being true is a precondition to expending\n> significant effort on the nested stack decoupling plan above.\n> \n\nThat was the issue. So we fixed that bug, but we never un-reverted\nthe patch that forks enough engines to use up all the CPU\'s on a box\nby default. That would likely help a lot with metadata access speed\n(we could manually do it in TripleO but we tend to push defaults. :)\n\n\n','<20140811184006.GB14352@t430slt.redhat.com>',NULL),('<1407785041.17107.25.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 15:24:01',-14400,'2014-08-11 19:24:01',NULL,'[openstack-dev] [TripleO] reverting the HOT migration? //\n dealing with lockstep changes','On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote:\n> Hi, so shortly after the HOT migration landed, we hit\n> https://bugs.launchpad.net/tripleo/+bug/1354305 which is that on even\n> quite recently deployed clouds, the migrated templates were just too\n> new. A partial revert (of just the list_join bit) fixes that, but a\n> deeper problem emerged which is that stack-update to get from a\n> non-HOT to HOT template appears broken\n> (https://bugs.launchpad.net/heat/+bug/1354962).\n> \n> I think we need to revert the HOT migration today, as forcing a\n> scorched earth recreation of a cloud is not a great answer for folk\n> that have deployed versions - its a backwards compat issue.\n> \n> Its true that our release as of icehouse isn\'t  really useable, so we\n> could try to wiggle our way past this one, but I think as the first\n> real test of our new backwards compat policy, that that would be a\n> mistake.\n\nHmmm. We blocked a good bit of changes to get these HOT templates in so\nI hate to see us revert them. Also, It isn\'t clear to me how much work\nit would be to fully support the non-HOT to HOT templates upgrade path.\nHow much work is this? And is that something we really want to spend\ntime on instead of all the other things?\n\nWhy not just create a branch of the old templates that works on the\nexisting underclouds? Users would then need to use these templates as a\none-time upgrade step to be able to upgrade to a heat HOT capable\nundercloud first.\n\nWith regards to the seed...\n\nWould a tool that allowed us to migrate the stateful data from an old\nseed to a new seed be a better use of time here? A re-seeder might be a\nuseful tool to future proof upgrade paths that rely on the software\nversions in the seed (Heat etc.) that aren\'t easily up-gradable.\nPackages would help here too, but not everyone uses them...\n\nDan\n\n> \n> What we need to be able to land it again, is some way whereby an\n> existing cloud can upgrade their undercloud (via stack-update against\n> the old heat deployed in the seed [today, old heat in the undercloud\n> itself in future]) and then once that is deployed subsequent templates\n> can use the new features. We\'re likely to run into such lockstep\n> changes in future, so we also need to be able to recognise them in\n> review / design, and call them out so we can fix them early rather\n> than deep down the pike.\n> \n> -Rob\n> \n\n\n\n\n','<CAJ3HoZ0AcTQJdpMzKbtuaiv_75DnCf=cYKaT1n3O8oO7y9KpaQ@mail.gmail.com>',NULL),('<1407789280.4092.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 20:33:26',0,'2014-08-11 20:33:26',NULL,'[openstack-dev] [Neutron][LBaaS] Continuing on \"Calling driver\n interface on every API request\"','Hi Eugene,\nAn example of the HM issue (and really this can happen with any entity)\nis if the driver the API sends the configuration to does not actually\nsupport the value of an attribute.\n\nFor example: Provider A support PING health monitor type, Provider B\ndoes not.  API allows the PING health monitor type to go through.  Once\na load balancer has been linked with that health monitor and the\nLoadBalancer chose to use Provider B, that entire configuration is then\nsent to the driver.  The driver errors out not on the LoadBalancer\ncreate, but on the health monitor create.\n\nI think that\'s the issue.\n\nThanks,\nBrandon\n\nOn Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:\n> Hi folks,\n> \n> \n> That actually going in opposite direction to what flavor framework is\n> trying to do (and for dispatching it\'s doing the same as providers).\n> REST call dispatching should really go via the root object.\n> \n> \n> I don\'t quite get the issue with health monitors. If HM is incorrectly\n> configured prior to association with a pool - API layer should handle\n> that.\n> I don\'t think driver implementations should be different at\n> constraints to HM parameters.\n> \n> \n> So I\'m -1 on adding provider (or flavor) to each entity. After all, it\n> looks just like data denormalization which actually will affect lots\n> of API aspects in negative way.\n> \n> \n> Thanks,\n> Eugene.\n> \n> \n> \n> \n> On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam\n> <Vijay.Venkatachalam at citrix.com> wrote:\n>         \n>         Yes, the point was to say \"the plugin need not restrict and\n>         let driver decide what to do with the API\".\n>         \n>         Even if the call was made to driver instantaneously, I\n>         understand, the driver might decide to ignore\n>         first and schedule later. But, if the call is present, there\n>         is scope for validation.\n>         Also, the driver might be scheduling an async-api to backend,\n>         in which case  deployment error\n>         cannot be shown to the user instantaneously.\n>         \n>         W.r.t. identifying a provider/driver, how would it be to make\n>         tenant the default \"root\" object?\n>         \"tenantid\" is already associated with each of these entities,\n>         so no additional pain.\n>         For the tenant who wants to override let him specify provider\n>         in each of the entities.\n>         If you think of this in terms of the UI, let\'s say if the\n>         loadbalancer configuration is exposed\n>         as a single wizard (which has loadbalancer, listener, pool,\n>         monitor properties) then provider\n>          is chosen only once.\n>         \n>         Curious question, is flavour framework expected to address\n>         this problem?\n>         \n>         Thanks,\n>         Vijay V.\n>         \n>         -----Original Message-----\n>         From: Doug Wiegley [mailto:dougw at a10networks.com]\n>         \n>         Sent: 11 August 2014 22:02\n>         To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on\n>         \"Calling driver interface on every API request\"\n>         \n>         Hi Sam,\n>         \n>         Very true.  I think that Vijay?s objection is that we are\n>         currently imposing a logical structure on the driver, when it\n>         should be a driver decision.  Certainly, it goes both ways.\n>         \n>         And I also agree that the mechanism for returning multiple\n>         errors, and the ability to specify whether those errors are\n>         fatal or not, individually, is currently weak.\n>         \n>         Doug\n>         \n>         \n>         On 8/11/14, 10:21 AM, \"Samuel Bercovici\" <SamuelB at Radware.com>\n>         wrote:\n>         \n>         >Hi Doug,\n>         >\n>         >In some implementations Driver !== Device. I think this is\n>         also true\n>         >for HA Proxy.\n>         >This might mean that there is a difference between creating a\n>         logical\n>         >object and when there is enough information to actually\n>         schedule/place\n>         >this into a device.\n>         >The ability to express such errors (detecting an error on a\n>         logical\n>         >object after it was created but when it actually get\n>         scheduled) should\n>         >be discussed and addressed anyway.\n>         >\n>         >-Sam.\n>         >\n>         >\n>         >-----Original Message-----\n>         >From: Doug Wiegley [mailto:dougw at a10networks.com]\n>         >Sent: Monday, August 11, 2014 6:55 PM\n>         >To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         >Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on\n>         \"Calling\n>         >driver interface on every API request\"\n>         >\n>         >Hi all,\n>         >\n>         >> Validations such as ?timeout > delay? should be performed\n>         on the API\n>         >>level before it reaches the driver.\n>         >For a configuration tree (lb, listeners, pools, etc.), there\n>         should be\n>         >one provider.\n>         >\n>         >You?re right, but I think the point of Vijay?s example was to\n>         highlight\n>         >the combo error problem with populating all of the driver\n>         objects at\n>         >once (in short, the driver interface isn?t well suited to\n>         that model.)\n>         >That his one example can be covered by API validators is\n>         irrelevant.\n>         >Consider a backend that does not support APP_COOKIE?s, or\n>         >HTTPS_TERMINATED (but has multiple listeners) instead.\n>          Should the\n>         >entire load balancer create fail, or should it offer degraded\n>         service?\n>         >Do all drivers have to implement a transaction rollback;\n>         wait, the\n>         >interface makes that very hard.  That?s his point.  The\n>         driver is no\n>         >longer just glue code between interfaces; it?s now a\n>         mini-object error handler.\n>         >\n>         >\n>         >> Having provider defined in multiple places does not make\n>         sense.\n>         >\n>         >Channeling Brandon, who can yell if I get this wrong, the\n>         point is not\n>         >to have a potentially different provider on each object.\n>          It?s to allow\n>         >a provider to be assigned when the first object in the tree\n>         is created,\n>         >so that future related objects will always get routed to the\n>         same provider.\n>         >Not knowing which provider should get all the objects is why\n>         we have to\n>         >wait until we see a LoadBalancer object.\n>         >\n>         >\n>         >All of this sort of edge case nonsense is because we (the\n>         royal we, the\n>         >community), wanted all load balancer objects to be ?root?\n>         objects, even\n>         >though only one of them is an actual root today, to support\n>         >many-to-many relationships among all of them, at some future\n>         date,\n>         >without an interface change.  If my bias is showing that I?m\n>         not a fan\n>         >of adding this complexity for that, I?m not surprised.\n>         >\n>         >Thanks,\n>         >doug\n>         >\n>         >\n>         >On 8/11/14, 7:57 AM, \"Samuel Bercovici\" <SamuelB at Radware.com>\n>         wrote:\n>         >\n>         >>Hi,\n>         >>\n>         >>Validations such as ?timeout > delay? should be performed on\n>         the API\n>         >>level before it reaches the driver.\n>         >>\n>         >>For a configuration tree (lb, listeners, pools, etc.), there\n>         should be\n>         >>one provider.\n>         >>\n>         >>Having provider defined in multiple places does not make\n>         sense.\n>         >>\n>         >>\n>         >>-San.\n>         >>\n>         >>\n>         >>From: Vijay Venkatachalam\n>         [mailto:Vijay.Venkatachalam at citrix.com]\n>         >>\n>         >>Sent: Monday, August 11, 2014 2:43 PM\n>         >>To: OpenStack Development Mailing List\n>         >>(openstack-dev at lists.openstack.org)\n>         >>Subject: [openstack-dev] [Neutron][LBaaS] Continuing on\n>         \"Calling\n>         >>driver interface on every API request\"\n>         >>\n>         >>\n>         >>\n>         >>Hi:\n>         >>\n>         >>Continuing from last week?s LBaaS meeting?\n>         >>\n>         >>Currently an entity cannot be sent to driver unless it is\n>         linked to\n>         >>loadbalancer because loadbalancer is the root object and\n>         driver\n>         >>information is only available with loadbalancer.\n>         >>\n>         >>\n>         >>The request to the driver is delayed because of which error\n>         >>propagation becomes tricky.\n>         >>\n>         >>Let?s say a monitor was configured with timeout > delay\n>         there would be\n>         >>no error then.\n>         >>When a listener is configured there will be a monitor\n>         >>creation/deployment error like ?timeout configured greater\n>         than delay?.\n>         >>\n>         >>Unless the error is very clearly crafted the user won?t be\n>         able to\n>         >>understand the error.\n>         >>\n>         >>I am half-heartedly OK with current approach.\n>         >>\n>         >>\n>         >>But, I would prefer Brandon?s Solution ? make provider an\n>         attribute in\n>         >>each of the entities to get rid of this problem.\n>         >>\n>         >>\n>         >>What do others think?\n>         >>\n>         >>Thanks,\n>         >>Vijay V.\n>         >>\n>         >\n>         >\n>         >_______________________________________________\n>         >OpenStack-dev mailing list\n>         >OpenStack-dev at lists.openstack.org\n>         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >_______________________________________________\n>         >OpenStack-dev mailing list\n>         >OpenStack-dev at lists.openstack.org\n>         >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJfiwOQPU3WzMK_PCxag6_wufNME4G7XY74kcOiDd3kY7GRFcA@mail.gmail.com>',NULL),('<1407794611-sup-4888@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 15:16:35',-25200,'2014-08-11 22:16:35',NULL,'[openstack-dev] [TripleO][heat] a small experiment with Ansible\n	in TripleO','Excerpts from Zane Bitter\'s message of 2014-08-11 13:35:44 -0700:\n> On 11/08/14 14:49, Clint Byrum wrote:\n> > Excerpts from Steven Hardy\'s message of 2014-08-11 11:40:07 -0700:\n> >> On Mon, Aug 11, 2014 at 11:20:50AM -0700, Clint Byrum wrote:\n> >>> Excerpts from Zane Bitter\'s message of 2014-08-11 08:16:56 -0700:\n> >>>> On 11/08/14 10:46, Clint Byrum wrote:\n> >>>>> Right now we\'re stuck with an update that just doesn\'t work. It isn\'t\n> >>>>> just about update-failure-recovery, which is coming along nicely, but\n> >>>>> it is also about the lack of signals to control rebuild, poor support\n> >>>>> for addressing machines as groups, and unacceptable performance in\n> >>>>> large stacks.\n> >>>>\n> >>>> Are there blueprints/bugs filed for all of these issues?\n> >>>>\n> >>>\n> >>> Convergnce addresses the poor performance for large stacks in general.\n> >>> We also have this:\n> >>>\n> >>> https://bugs.launchpad.net/heat/+bug/1306743\n> >>>\n> >>> Which shows how slow metadata access can get. I have worked on patches\n> >>> but haven\'t been able to complete them. We made big strides but we are\n> >>> at a point where 40 nodes polling Heat every 30s is too much for one CPU\n> \n> This sounds like the same figure I heard at the design summit; did the \n> DB call optimisation work that Steve Baker did immediately after that \n> not have any effect?\n> \n\nSteve\'s work got us to 40. From 7.\n\n> >>> to handle. When we scaled Heat out onto more CPUs on one box by forking\n> >>> we ran into eventlet issues. We also ran into issues because even with\n> >>> many processes we can only use one to resolve templates for a single\n> >>> stack during update, which was also excessively slow.\n> >>\n> >> Related to this, and a discussion we had recently at the TripleO meetup is\n> >> this spec I raised today:\n> >>\n> >> https://review.openstack.org/#/c/113296/\n> >>\n> >> It\'s following up on the idea that we could potentially address (or at\n> >> least mitigate, pending the fully convergence-ified heat) some of these\n> >> scalability concerns, if TripleO moves from the one-giant-template model\n> >> to a more modular nested-stack/provider model (e.g what Tomas has been\n> >> working on)\n> >>\n> >> I\'ve not got into enough detail on that yet to be sure if it\'s acheivable\n> >> for Juno, but it seems initially to be complex-but-doable.\n> >>\n> >> I\'d welcome feedback on that idea and how it may fit in with the more\n> >> granular convergence-engine model.\n> >>\n> >> Can you link to the eventlet/forking issues bug please?  I thought since\n> >> bug #1321303 was fixed that multiple engines and multiple workers should\n> >> work OK, and obviously that being true is a precondition to expending\n> >> significant effort on the nested stack decoupling plan above.\n> >>\n> >\n> > That was the issue. So we fixed that bug, but we never un-reverted\n> > the patch that forks enough engines to use up all the CPU\'s on a box\n> > by default. That would likely help a lot with metadata access speed\n> > (we could manually do it in TripleO but we tend to push defaults. :)\n> \n> Right, and we decided we wouldn\'t because it\'s wrong to do that to \n> people by default. In some cases the optimal running configuration for \n> TripleO will differ from the friendliest out-of-the-box configuration \n> for Heat users in general, and in those cases - of which this is one - \n> TripleO will need to specify the configuration.\n> \n\nWhether or not the default should be to fork 1 process per CPU is a\ndebate for another time. The point is, we can safely use the forking in\nHeat now to perhaps improve performance of metadata polling.\n\nChasing that, and other optimizations, has not led us to a place where\nwe can get to, say, 100 real nodes _today_. We\'re chasing another way to\nget to the scale and capability we need _today_, in much the same way\nwe did with merge.py. We\'ll find the way to get it done more elegantly\nas time permits.\n\n\n','<53E92920.1060900@redhat.com>',NULL),('<1407799786.1425.26.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 18:29:46',-18000,'2014-08-11 23:29:46',NULL,'[openstack-dev] [all] The future of the integrated release','John,\n\nI spent the drive to the Minneapolis Airport thinking about this chain\nof e-mails.  Hope these thoughts help ...\n\nOn Thu, 2014-08-07 at 07:55 -0600, John Griffith wrote:\n> \n> \n> \n> \n> On Thu, Aug 7, 2014 at 7:33 AM, Anne Gentle <anne at openstack.org>\n> wrote:\n>         \n>         \n>         \n>         On Thu, Aug 7, 2014 at 8:20 AM, Russell Bryant\n>         <rbryant at redhat.com> wrote:\n>                 On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the\n>                 difference is\n>                 slot selection would just be Nova drivers. I\n>                 > think there is an assumption in the old system that\n>                 everyone in Nova\n>                 > core wants to prioritize the blueprints. I think\n>                 there are a bunch of\n>                 > folks in Nova core that are happy having signaling\n>                 from Nova drivers on\n>                 > high priority things to review. (I know I\'m in that\n>                 camp.)\n>                 >\n>                 > Lacking that we all have picking algorithms to hack\n>                 away at the 500 open\n>                 > reviews. Which basically means it\'s a giant random\n>                 queue.\n>                 >\n>                 > Having a few blueprints that *everyone* is looking\n>                 at also has the\n>                 > advantage that the context for the bits in question\n>                 will tend to be\n>                 > loaded into multiple people\'s heads at the same\n>                 time, so is something\n>                 > that\'s discussable.\n>                 >\n>                 > Will it fix the issue, not sure, but it\'s an idea.\n>                 \n>                 \n>                 OK, got it.  So, success critically depends on\n>                 nova-core being willing\n>                 to take review direction and priority setting from\n>                 nova-drivers.  That\n>                 sort of assumption is part of why I think agile\n>                 processes typically\n>                 don\'t work in open source.  We don\'t have the ability\n>                 to direct people\n>                 with consistent and reliable results.\n>                 \n>                 I\'m afraid if people doing the review are not directly\n>                 involved in at\n>                 least ACKing the selection and commiting to review\n>                 something, putting\n>                 stuff in slots seems futile.\n>                 \n>         \n>         \n>         My original thinking was I\'d set aside a \"meeting time\" to\n>         review specs especially for doc issues and API designs. What I\n>         found quickly was that the 400+ queue in one project alone was\n>         not only daunting but felt like I wasn\'t going to make a dent\n>         as a single person, try as I may.\n>         \n>         \n>         I did my best but would appreciate any change in process to\n>         help with prioritization. I\'m pretty sure it will help someone\n>         like me, looking at cross-project queues of specs, to know\n>         what to review first, second, third, and what to circle back\n>         on. \n>          \n>                 --\n>                 Russell Bryant\n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> ?Seems everybody that\'s been around a while has noticed \"issues\" this\n> release and have talked about it, thanks Thierry for putting it\n> together so well and kicking off the ML thread here.\n> \n> \n> I\'d agree with everything that you stated, I\'ve also floated the idea\n> this past week with a few members of the Core Cinder team to have an\n> \"every other\" release for new drivers submissions in Cinder (I\'m\n> expecting this to be a HUGELY popular proposal [note sarcastic\n> tone]).  \n> \n> \n> There are three things that have just crushed productivity and\n> motivation in Cinder this release (IMO):\n> 1. Overwhelming number of drivers (tactical contributions)\n\nI totally agree with this statement.  We have so many large patches to\nreview that it is daunting.  I wish I had a good solution for dealing\nwith this issue.  I don\'t think quick reviews and just trying to get\nthem through is the right answer.  Perhaps a coordinated effort for some\nportion of our code sprint days to knock things down?  Split up the work\nand then work together to push some through?\n\n\n> 2. Overwhelming amount of churn, literally hundreds of little changes\n> to modify docstrings, comments etc but no real improvements to code\n\nI can understand the frustration here, but do we want to discourage\npeople from doing this.  If they are submitting fixes, they are looking\nat the code.  They are bound to also find some bugs in code as well.  I\njust think it is dangerous to say that those changes have no real\nimprovement to the code.  That is just my feeling.  OpenStack, unlike\nother projects I have been on, is very much like an open book.  Anyone\ncan read it and people often do.  I don\'t want Cinder to look like a\npoorly written book.\n\n> 3. A new sense of pride in hitting the -1 button on reviews.  A large\n> number of reviews these days seem to be -1 due to punctuation or\n> misspelling in comments and docstrings.  There\'s also a lot of \"my way\n> of writing this method is better because it\'s *clever*\" taking place.\n> \nWell, with regards to the misspellings, see my comment above.  I don\'t\nthink people are taking pride in hitting -1 over it.  They are seeing\nissues, don\'t want to be submitting a bunch of clean-up patches and so\nare noting that they think something needs to be fixed.\n\nI agree the -1 needs to be used with care here.  Is it one typo or 20?\nAre there a bunch of +1\'s and/or +2\'s on the review.  If so, shouldn\'t\nbe -1\'ing at that point.  If people are throwing themselves in front of\nthe train, perhaps we need more education for the crew.\n\nDuncan noted that perhaps his code clean-up weeks could help with this.\nI hate to admit I don\'t fully understand how to use the process yet.  I\nhope we can talk about that as well as this whole subject at the code\nsprint.\n\nAlso, I was surprised in one of your subsequent notes that you were\nfrustrated with the addition of Hacking checks.  I had been working on\nthose given that I thought it was part of the solution to all the -1\'s.\nCatch some of the issues that are easily caught and also catch us up\nwith other project\'s Hacking checks.\n> \n> In Cinder\'s case I don\'t think new features is a problem, in fact we\n> can\'t seem to get new features worked on and released because of all\n> the other distractions.  That being said doing a maintenance or\n> hardening only type of release is for sure good with me.\n> \nHonestly, I haven\'t been able to get to the new feature stuff because I\nam distracted by the little clean-up patches, but because the new\nfeatures are so big and painful I have been bad about forcing myself to\nget through them.  I wonder how may are guilty of this?  :-)\n> \n> Anyway, I\'ve had some plans to talk about how we might fix some of\n> this in Cinder at next week\'s sprint.  If there\'s a broader community\n> effort along these lines that\'s even better.\n> \nIs this problem unique to Cinder?  I don\'t hear others talking about\nthis much.  If this is unique to Cinder, why?  Maybe we need to start\nwith that question to find a solution.\n\n> Thanks,\n> John\n>     ?\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CA+qL3LWBeLZ-=d=+=gC2qcXYGA3BMsUxAczHBJ5iJ3YQKb1=rA@mail.gmail.com>',NULL),('<1407813817.17330.YahooMailNeo@web163603.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 20:23:37',-25200,'2014-08-12 03:23:37',NULL,'[openstack-dev] devstack build failures','all,\nis anyone seeing these failures in devstack -\n\ncreate_keystone_accounts\n2014-08-11 02:47:47.906 | ++ get_or_create_project admin\n2014-08-11 02:47:47.908 | +++ openstack project show admin -f value -c id\n2014-08-11 02:47:48.825 | +++ openstack project create admin -f value -c id\n2014-08-11 02:47:49.581 | ERROR: cliff.app \'module\' object has no attribute \'get_trace_id_headers\'\n\nbasically, all cli commands are failing with the above error code.?\nthis is the cliff pkg i have -?cliff (1.6.1.19.g632fdd8)\nand the call itself seems to be from osprofiler -?osprofiler (0.1.1)\n\ni\'m running the gate scripts on my CI setup. i had disabled a few projects (swift, trove, sahara) intermittently, but i was getting successful runs afterwards, these errors seem to have been triggered by some upstream change.\n\nthanks!\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140811/629b8160/attachment.html>\n\n',NULL,NULL),('<1407828228.26856.101.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 08:23:48',3600,'2014-08-12 07:23:48',NULL,'[openstack-dev] [nova] fair standards for all hypervisor drivers','On Mon, 2014-08-11 at 15:25 -0700, Joe Gordon wrote:\n> \n> \n> \n> On Sun, Aug 10, 2014 at 11:59 PM, Mark McLoughlin <markmc at redhat.com>\n> wrote:\n>         On Fri, 2014-08-08 at 09:06 -0400, Russell Bryant wrote:\n>         > On 08/07/2014 08:06 PM, Michael Still wrote:\n>         > > It seems to me that the tension here is that there are\n>         groups who\n>         > > would really like to use features in newer libvirts that\n>         we don\'t CI\n>         > > on in the gate. Is it naive to think that a possible\n>         solution here is\n>         > > to do the following:\n>         > >\n>         > >  - revert the libvirt version_cap flag\n>         >\n>         > I don\'t feel strongly either way on this.  It seemed useful\n>         at the time\n>         > for being able to decouple upgrading libvirt and enabling\n>         features that\n>         > come with that.\n>         \n>         \n>         Right, I suggested the flag as a more deliberate way of\n>         avoiding the\n>         issue that was previously seen in the gate with live\n>         snapshots. I still\n>         think it\'s a pretty elegant and useful little feature, and\n>         don\'t think\n>         we need to use it as proxy battle over testing requirements\n>         for new\n>         libvirt features.\n> \n> \n> Mark,\n> \n> \n> I am not sure if I follow.  The gate issue with live snapshots has\n> been worked around by turning it off [0], so presumably this patch is\n> forward facing.  I fail to see how this patch is needed to help the\n> gate in the future.\n\nOn the live snapshot issue specifically, we disabled it by requiring\n1.3.0 for the feature. With the version cap set to 1.2.2, we won\'t\nautomatically enable this code path again if we update to 1.3.0. No\nquestion that\'s a bit of a mess, though.\n\nThe point was a more general one - we learned from the live snapshot\nissue that having a libvirt upgrade immediately enable new code paths\nwas a bad idea. The patch is a simple, elegant way of avoiding that.\n\n>  Wouldn\'t it just delay the issues until we change the version_cap?\n\nYes, that\'s the idea. Rather than having to scramble when the new\ndevstack-gate image shows up, we\'d be able to work on any issues in the\ncontext of a patch series to bump the version_cap.\n\n> The issue I see with the libvirt version_cap [1] is best captured in\n> its commit message: \"The end user can override the limit if they wish\n> to opt-in to use of untested features via the \'version_cap\' setting in\n> the \'libvirt\' group.\" This goes against the very direction nova has\n> been moving in for some time now. We have been moving away from\n> merging untested (re: no integration testing) features.  This patch\n> changes the very direction the project is going in over testing\n> without so much as a discussion. While I think it may be time that we\n> revisited this discussion, the discussion needs to happen before any\n> patches are merged.\n\nYou put it well - some apparently see us moving towards a zero-tolerance\npolicy of not having any code which isn\'t functionally tested in the\ngate. That obviously is not the case right now.\n\nThe sentiment is great, but any zero-tolerance policy is dangerous. I\'m\nvery much in favor of discussing this further. We should have some\nprinciples and goals around this, but rather than argue this in the\nabstract we should be open to discussing the tradeoffs involved with\nindividual patches.\n\n> I am less concerned about the contents of this patch, and more\n> concerned with how such a big de facto change in nova policy (we\n> accept untested code sometimes) without any discussion or consensus.\n> In your comment on the revert [2], you say the \'whether not-CI-tested\n> features should be allowed to be merged\' debate is \'clearly\n> unresolved.\' How did you get to that conclusion? This was never\n> brought up in the mid-cycles as a unresolved topic to be discussed. In\n> our specs template we say \"Is this untestable in gate given current\n> limitations (specific hardware / software configurations available)?\n> If so, are there mitigation plans (3rd party testing, gate\n> enhancements, etc)\" [3].  We have been blocking untested features for\n> some time now.\n\nAsking \"is this tested\" in a spec template makes a tonne of sense.\nRequiring some thought to be put into mitigation where a feature is\nuntestable in the gate makes sense. Requiring that the code is tested\nwhere possible makes sense. It\'s a zero-tolerance \"get your code\nfunctionally tested or GTFO\" policy that I\'m concerned about.\n\n> I am further perplexed by what Daniel Berrange, the patch author,\n> meant when he commented [2] \"Regardless of the outcome of the testing\n> discussion we believe this is a useful feature to have.\" Who is \'we\'?\n> Because I don\'t see how that can be nova-core or even nova-specs-core,\n> especially considering how many members of those groups are +2 on the\n> revert. So if \'we\' is neither of those groups then who is \'we\'?\n\nThat\'s for Dan to answer, but I think you\'re either nitpicking or have a\nvery serious concern.\n\nIf nitpicking, Dan could just be using the \"Royal \'We\'\" :) Or he could\njust mean the nova-core reviewers who +2ed the patch.\n\nOn the more serious front, I\'m conscious that Dan, Russell and I all\nwork for Red Hat and maybe you\'re really asking whether \"we\" means \"Red\nHat\" - i.e. some sort of corporate agenda. Absolutely not. The debate\nkicked off here:\n\n  https://review.openstack.org/103923\n\nI think it\'s pretty clear everyone is coming at this with good-faith,\ngenuine personal opinions and concerns.\n\nMark.\n\n\n\n','<CAHXdxOctjgqn9Ftcy+_FUci-9eywDWVtjpvZp3zCCtrZMeGtZg@mail.gmail.com>',NULL),('<1407855404.26856.196.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 15:56:44',3600,'2014-08-12 14:56:44',NULL,'[openstack-dev] [nova] Retrospective veto revert policy','Hey\n\n(Terrible name for a policy, I know)\n\n>From the version_cap saga here:\n\n  https://review.openstack.org/110754\n\nI think we need a better understanding of how to approach situations\nlike this.\n\nHere\'s my attempt at documenting what I think we\'re expecting the\nprocedure to be:\n\n  https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy\n\nIf it sounds reasonably sane, I can propose its addition to the\n\"Development policies\" doc.\n\nMark.\n\n\n\n',NULL,NULL),('<1407877792.26856.222.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 22:09:52',3600,'2014-08-12 21:09:52',NULL,'[openstack-dev] [nova] so what do i do about libvirt-python if\n i\'m on precise?','On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:\n> On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:\n> > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:\n> > > While forcing people to move to a newer version of libvirt is\n> > > doable on most environments, do we want to do that now? What is\n> > > the benefit of doing so?\n> > [...]\n> > \n> > The only dog I have in this fight is that using the split-out\n> > libvirt-python on PyPI means we finally get to run Nova unit tests\n> > in virtualenvs which aren\'t built with system-site-packages enabled.\n> > It\'s been a long-running headache which I\'d like to see eradicated\n> > everywhere we can. I understand though if we have to go about it\n> > more slowly, I\'m just excited to see it finally within our grasp.\n> > -- \n> > Jeremy Stanley\n> >\n> We aren\'t quite forcing people to move to newer versions. Only those\n> installing nova test-requirements need newer libvirt.\n\nYeah, I\'m a bit confused about the problem here. Is it that people want\nto satisfy test-requirements through packages rather than using a\nvirtualenv?\n\n(i.e. if people just use virtualenvs for unit tests, there\'s no problem\nright?)\n\nIf so, is it possible/easy to create new, alternate packages of the\nlibvirt python bindings (from PyPI) on their own separately from the\nlibvirt.so and libvirtd packages?\n\nMark.\n\n\n\n','<1406759656.1166955.147472414.16DF44FC@webmail.messagingengine.com>',NULL),('<1407877992.26856.223.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 22:13:12',3600,'2014-08-12 21:13:12',NULL,'[openstack-dev] [Nova] Nominating Jay Pipes for nova-core','On Wed, 2014-07-30 at 14:02 -0700, Michael Still wrote:\n> Greetings,\n> \n> I would like to nominate Jay Pipes for the nova-core team.\n> \n> Jay has been involved with nova for a long time now.  He\'s previously\n> been a nova core, as well as a glance core (and PTL). He\'s been around\n> so long that there are probably other types of core status I have\n> missed.\n> \n> Please respond with +1s or any concerns.\n\nWas away, but +1 for the record. Would have been happy to see this some\ntime ago.\n\nMark.\n\n\n\n','<CAEd1pt4RQzL2EvU0enuXMeS6+tRxtBihi6AGSwdKH9XnAJAUNQ@mail.gmail.com>',NULL),('<1407903071034.98224@nebula.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-08-13 04:11:11',0,'2014-08-13 04:11:11',NULL,'[User-committee] OpenStack End User Working Group','As more OpenStack-powered clouds become available, there are a growing number of \"end users\" of OpenStack clouds that have no direct visibility into the implementation of the OpenStack services that they are using.  These \"end users\" are often employees of organizations that have OpenStack clouds or application developers that are using public clouds powered by OpenStack.   Tim Bell and I have been discussing the best way to give a voice to this growing community of stakeholders within the broader OpenStack community, and have agreed to form a working group to work with the Foundation, User Committee, and OpenStack Board, to coordinate activities that give this small but growing community a larger voice within the overall OpenStack ecosystem.\n\nWe have set up a meetingburner event for Thursday at 5 pm PT at http://openstack.enterthemeeting.com/m/BY7MH7X4\n[http://enterthemeeting.com/media/meeting/images/fb-mb-logo.jpg]<http://openstack.enterthemeeting.com/m/BY7MH7X4>\n\nOpenStack Meeting\nFollowing the July board meeting, we\'ll bring together parties interested in kicking off an end user working group under the OpenStack user committee. High level agenda: 1. Discuss \"end user\" vs \" app developer\" 2. Discuss current activities Foundation is planning including app developer input session 3. Discuss how to communicate this and engage the larger community\nRead more...<http://openstack.enterthemeeting.com/m/BY7MH7X4>\n\n\n?Agenda:\n\n  1.  Chris Kemp: Overview of working group, including how key stakeholders, including \"OpenStack developers,\" \"OpenStack operators,\" \"OpenStack end users,\" and \"OpenStack app developers\" relate to this working group, the User Committee, and the overall OpenStack community.\n  2.  Lauren Sell: Discuss current activities Foundation is planning including app developer input session.\n  3.  Tom Ford: Discuss how to communicate this to the larger OpenStack community\n  4.  Community. Collect feedback, ideas and volunteers interested in helping out from the members of the User Committee.\n\nPlease sign up if you are interested in learning more about (or participating in!) this working group. ?\n\nChris\n\nCo-founder, OpenStack, Nebula\nchris at kemp.com\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20140813/ed9bbd35/attachment.html>\n\n',NULL,NULL),('<1407929942.26856.271.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 12:39:02',3600,'2014-08-13 11:39:02',NULL,'[openstack-dev] [all] The future of the integrated release','On Tue, 2014-08-05 at 18:03 +0200, Thierry Carrez wrote:\n> Hi everyone,\n> \n> With the incredible growth of OpenStack, our development community is\n> facing complex challenges. How we handle those might determine the\n> ultimate success or failure of OpenStack.\n> \n> With this cycle we hit new limits in our processes, tools and cultural\n> setup. This resulted in new limiting factors on our overall velocity,\n> which is frustrating for developers. This resulted in the burnout of key\n> firefighting resources. This resulted in tension between people who try\n> to get specific work done and people who try to keep a handle on the big\n> picture.\n\nAlways fun catching up on threads like this after being away ... :)\n\nI think the thread has revolved around three distinct areas:\n\n  1) The per-project review backlog, its implications for per-project \n     velocity, and ideas for new workflows or tooling\n\n  2) Cross-project scaling issues that get worse as we add more \n     integrated projects\n\n  3) The factors that go into deciding whether a project belongs in the \n     integrated release - including the appropriateness of its scope,\n     the soundness of its architecture and how \"production ready\" it is.\n\nThe first is important - hugely important - but I don\'t think it has any\nbearing on the makeup, scope or contents of the integrated release, but\ncertainly will have a huge bearing on the success of the release and the\nproject more generally.\n\nThe third strikes me as a part of the natural evolution around how we\nthink about the integrated release. I don\'t think there\'s any particular\ncrisis or massive urgency here. As the TC considers proposals to\nintegrate (or de-integrate) projects, we\'ll continue to work through\nthis. These debates are contentious enough that we should avoid adding\nunnecessary drama to them by conflating the issues with more pressing,\nurgent issues.\n\nI think the second area is where we should focus. We\'re concerned that\nwe\'re hitting a breaking point with some cross-project issues - like\nrelease management, the gate, a high level of non-deterministic test\nfailures, insufficient cross-project collaboration on technical debt\n(e.g. via Oslo), difficulty in reaching consensus on new cross-project\ninitiatives (Sean gave the examples of Group Based Policy and Rally) -\nsuch that drastic measures are required. Like maybe we should not accept\nany new integrated projects in this cycle while we work through those\nissues.\n\nDigging deeper into that means itemizing these cross-project scaling\nissues, figuring out which of them need drastic intervention, discussing\nwhat the intervention might be and the realistic overall effects of\nthose interventions.\n\nAFAICT, the closest we\'ve come in the thread to that level of detail is\nSean\'s email here:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-August/042277.html\n\nMark.\n\n\n\n','<53E10061.8030603@openstack.org>',NULL),('<1407932031.26856.300.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 13:13:51',3600,'2014-08-13 12:13:51',NULL,'[openstack-dev] [all] The future of the integrated release','On Thu, 2014-08-07 at 09:30 -0400, Sean Dague wrote:\n\n> While I definitely think re-balancing our quality responsibilities back\n> into the projects will provide an overall better release, I think it\'s\n> going to take a long time before it lightens our load to the point where\n> we get more breathing room again.\n\nI\'d love to hear more about this re-balancing idea. It sounds like we\nhave some concrete ideas here and we\'re saying they\'re not relevant to\nthis thread because they won\'t be an immediate solution?\n\n> This isn\'t just QA issues, it\'s a coordination issue on overall\n> consistency across projects. Something that worked fine at 5 integrated\n> projects, got strained at 9, and I think is completely untenable at 15.\n\nI can certainly relate to that from experience with Oslo.\n\nBut if you take a concrete example - as more new projects emerge, it\nbecame harder to get them all using oslo.messaging and using it\nconsistent ways. That\'s become a lot better with Doug\'s idea of Oslo\nproject delegates.\n\nBut if we had not added those projects to the release, the only reason\nthat the problem would be more manageable is that the use of\noslo.messaging would effectively become a requirement for integration.\nSo, projects requesting integration have to take cross-project\nresponsibilities more seriously for fear their application would be\ndenied.\n\nThat\'s a very sad conclusion. Our only tool for encouraging people to\ntake this cross-project issue is being accepted into the release and,\nonce achieved, the cross-project responsibilities aren\'t taken so\nseriously?\n\nI don\'t think it\'s so bleak as that - given the proper support,\ndirection and tracking I think we\'re seeing in Oslo how projects will\nplay their part in getting to cross-project consistency.\n\n> I think one of the big issues with a large number of projects is that\n> implications of implementation of one project impact others, but people\n> don\'t always realize. Locally correct decisions for each project may not\n> be globally correct for OpenStack. The GBP discussion, the Rally\n> discussion, all are flavors of this.\n\nI think we need two things here - good examples of how these\ncross-project initiatives can succeed so people can learn from them, and\nfor the initiatives themselves to be patiently lead by those whose goal\nis a cross-project solution.\n\nIt\'s hard work, absolutely no doubt. The point again, though, is that it\nis possible to do this type of work in such a way that once a small\nnumber of projects adopt the approach, most of the others will follow\nquite naturally.\n\nIf I was trying to get a consistent cross-project approach in a\nparticular area, the least of my concerns would be whether Ironic,\nMarconi, Barbican or Designate would be willing to fall in line behind a\ncross-project consensus.\n\n> People are frustrated in infra load, for instance. It\'s probably worth\n> noting that the \'config\' repo currently has more commits landed than any\n> other project in OpenStack besides \'nova\' in this release. It has 30%\n> the core team size as Nova (http://stackalytics.com/?metric=commits).\n\nYes, infra is an extremely busy project. I\'m not sure I\'d compare\ninfra/config commits to Nova commits in order to illustrate that,\nthough.\n\nInfra is a massive endeavor, it\'s as critical a part of the project as\nany project in the integrated release, and like other \"strategic\nefforts\" struggles to attract contributors from as diverse a number of\ncompanies as the integrated projects.\n\n> So I do think we need to really think about what *must* be in OpenStack\n> for it to be successful, and ensure that story is well thought out, and\n> that the pieces which provide those features in OpenStack are clearly\n> best of breed, so they are deployed in all OpenStack deployments, and\n> can be counted on by users of OpenStack.\n\nI do think we try hard to think this through, but no doubt we need to do\nbetter. Is this conversation concrete enough to really move our thinking\nalong sufficiently, though?\n\n> Because if every version of\n> OpenStack deploys with a different Auth API (an example that\'s current\n> but going away), we can\'t grow an ecosystem of tools around it.\n\nThere\'s a nice concrete example, but it\'s going away? What\'s the best\ncurrent example to talk through?\n\n> This is organic definition of OpenStack through feedback with operators\n> and developers on what\'s minimum needed and currently working well\n> enough that people are happy to maintain it. And make that solid.\n> \n> Having a TC that is independently selected separate from the PTLs allows\n> that group to try to make some holistic calls here.\n> \n> At the end of the day, that\'s probably going to mean saying No to more\n> things. Everytime I turn around everyone wants the TC to say No to\n> things, just not to their particular thing. :) Which is human nature.\n> But I think if we don\'t start saying No to more things we\'re going to\n> end up with a pile of mud that no one is happy with.\n\nThat we\'re being so abstract about all of this is frustrating. I get\nthat no-one wants to start a flamewar, but can someone be concrete about\nwhat they feel we should say \'no\' to but are likely to say \'yes\' to?\n\nMark.\n\n\n\n','<53E37F75.7050704@dague.net>',NULL),('<1407933454.26856.317.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 13:37:34',3600,'2014-08-13 12:37:34',NULL,'[openstack-dev] [all] The future of the integrated release','On Fri, 2014-08-08 at 15:36 -0700, Devananda van der Veen wrote:\n> On Tue, Aug 5, 2014 at 10:02 AM, Monty Taylor <mordred at inaugust.com> wrote:\n\n> > Yes.\n> >\n> > Additionally, and I think we\'ve been getting better at this in the 2 cycles\n> > that we\'ve had an all-elected TC, I think we need to learn how to say no on\n> > technical merit - and we need to learn how to say \"thank you for your\n> > effort, but this isn\'t working out\" Breaking up with someone is hard to do,\n> > but sometimes it\'s best for everyone involved.\n> >\n> \n> I agree.\n> \n> The challenge is scaling the technical assessment of projects. We\'re\n> all busy, and digging deeply enough into a new project to make an\n> accurate assessment of it is time consuming. Some times, there are\n> impartial subject-matter experts who can spot problems very quickly,\n> but how do we actually gauge fitness?\n\nYes, it\'s important the TC does this and it\'s obvious we need to get a\nlot better at it.\n\nThe Marconi architecture threads are an example of us trying harder (and\nkudos to you for taking the time), but it\'s a little disappointing how\nit has turned out. On the one hand there\'s what seems like a \"this\ndoesn\'t make any sense\" gut feeling and on the other hand an earnest,\nbut hardly bite-sized justification for how the API was chosen and how\nit lead to the architecture. Frustrating that appears to not be\nresulting in either improved shared understanding, or improved\narchitecture. Yet everyone is trying really hard.\n\n> Letting the industry field-test a project and feed their experience\n> back into the community is a slow process, but that is the best\n> measure of a project\'s success. I seem to recall this being an\n> implicit expectation a few years ago, but haven\'t seen it discussed in\n> a while.\n\nI think I recall us discussing a \"must have feedback that it\'s\nsuccessfully deployed\" requirement in the last cycle, but we recognized\nthat deployers often wait until a project is integrated.\n\n> I\'m not suggesting we make a policy of it, but if, after a\n> few cycles, a project is still not meeting the needs of users, I think\n> that\'s a very good reason to free up the hold on that role within the\n> stack so other projects can try and fill it (assuming that is even a\n> role we would want filled).\n\nI\'m certainly not against discussing de-integration proposals. But I\ncould imagine a case for de-integrating every single one of our\nintegrated projects. None of our software is perfect. How do we make\nsure we approach this sanely, rather than run the risk of someone\nstarting a witch hunt because of a particular pet peeve?\n\nI could imagine a really useful dashboard showing the current state of\nprojects along a bunch of different lines - summary of latest\ndeployments data from the user survey, links to known scalability\nissues, limitations that operators should take into account, some\ncapturing of trends so we know whether things are improving. All of this\ndata would be useful to the TC, but also hugely useful to operators.\n\nMark.\n\n\n\n','<CAExZKEp8N2pM2Wfed5N5uRU-uwYrqBeNOP0LBbaiWSjJDq3wzw@mail.gmail.com>',NULL),('<1407934372.26856.327.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 13:52:52',3600,'2014-08-13 12:52:52',NULL,'[openstack-dev] [all] The future of the integrated release','On Tue, 2014-08-12 at 14:26 -0400, Eoghan Glynn wrote:\n>  > It seems like this is exactly what the slots give us, though. The core review\n> > team picks a number of slots indicating how much work they think they can\n> > actually do (less than the available number of blueprints), and then\n> > blueprints queue up to get a slot based on priorities and turnaround time\n> > and other criteria that try to make slot allocation fair. By having the\n> > slots, not only is the review priority communicated to the review team, it\n> > is also communicated to anyone watching the project.\n> \n> One thing I\'m not seeing shine through in this discussion of slots is\n> whether any notion of individual cores, or small subsets of the core\n> team with aligned interests, can \"champion\" blueprints that they have\n> a particular interest in.\n> \n> For example it might address some pain-point they\'ve encountered, or\n> impact on some functional area that they themselves have worked on in\n> the past, or line up with their thinking on some architectural point.\n> \n> But for whatever motivation, such small groups of cores currently have\n> the freedom to self-organize in a fairly emergent way and \"champion\"\n> individual BPs that are important to them, simply by *independently*\n> giving those BPs review attention.\n> \n> Whereas under the slots initiative, presumably this power would be\n> subsumed by the \"group will\", as expressed by the prioritization\n> applied to the holding pattern feeding the runways?\n> \n> I\'m not saying this is good or bad, just pointing out a change that\n> we should have our eyes open to.\n\nYeah, I\'m really nervous about that aspect.\n\nSay a contributor proposes a new feature, a couple of core reviewers\nthink it\'s important exciting enough for them to champion it but somehow\nthe \'group will\' is that it\'s not a high enough priority for this\nrelease, even if everyone agrees that it is actually cool and useful.\n\nWhat does imposing that \'group will\' on the two core reviewers and\ncontributor achieve? That the contributor and reviewers will happily\nturn their attention to some of the higher priority work? Or we lose a\ncontributor and two reviewers because they feel disenfranchised?\nProbably somewhere in the middle.\n\nOn the other hand, what happens if work proceeds ahead even if not\ndeemed a high priority? I don\'t think we can say that the contributor\nand two core reviewers were distracted from higher priority work,\nbecause blocking this work is probably unlikely to shift their focus in\na productive way. Perhaps other reviewers are distracted because they\nfeel the work needs more oversight than just the two core reviewers? It\nplaces more of a burden on the gate?\n\nI dunno ... the consequences of imposing group will worry me more than\nthe consequences of allowing small groups to self-organize like this.\n\nMark.\n\n\n\n','<1120628219.29220831.1407868006193.JavaMail.zimbra@redhat.com>',NULL),('<1407935289.26856.342.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 14:08:09',3600,'2014-08-13 13:08:09',NULL,'[openstack-dev] [all] The future of the integrated release','On Tue, 2014-08-12 at 14:12 -0700, Joe Gordon wrote:\n\n\n> Here is the full nova proposal on  \"Blueprint in Kilo: Runways and\n> Project Priorities\"\n>  \n> https://review.openstack.org/#/c/112733/\n> http://docs-draft.openstack.org/33/112733/4/check/gate-nova-docs/5f38603/doc/build/html/devref/runways.html\n\nThanks again for doing this.\n\nFour points in the discussion jump out at me. Let\'s see if I can\nparaphrase without misrepresenting :)\n\n  - ttx - we need tools to be able to visualize these runways\n\n  - danpb - the real problem here is that we don\'t have good tools to \n    help reviewers maintain a todo list which feeds, in part, off \n    blueprint prioritization\n\n  - eglynn - what are the implications for our current ability for \n    groups within the project to self-organize?\n\n  - russellb - why is different from reviewers sponsoring blueprints, \n    how will it work better?\n\n\nI\'ve been struggling to articulate a tooling idea for a while now. Let\nme try again based on the runways idea and the thoughts above ...\n\n\nWhen a reviewer sits down to do some reviews, their goal should be to\nwork through the small number of runways they\'re signed up to and drive\nthe list of reviews that need their attention to zero.\n\nReviewers should be able to create their own runways and allow others\nsign up to them.\n\nThe reviewers responsible for that runway are responsible for pulling\nnew reviews from explicitly defined feeder runways.\n\nSome feeder runways could be automated; no more than a search query for\nsay \"new libvirt patches which aren\'t already in the libvirt driver\nrunway\".\n\nAll of this activity should be visible to everyone. It should be\npossible to look at all the runways, see what runways a patch is in,\nunderstand the flow between runways, etc.\n\n\nThere\'s a lot of detail that would have to be worked out, but I\'m pretty\nconvinced there\'s an opportunity to carve up the review backlog, empower\npeople to help out with managing the backlog, give reviewers manageable\nqueues for them to stay on top of, help ensure that project priorization\nis one of the drivers of reviewer activity and increases contributor\nvisibility into how decisions are made.\n\nMark.\n\n\n\n\n','<CAHXdxOdjJUCLFTaDADoxkyn9tFmOkM4YRogX1Btx_9sjacCeyg@mail.gmail.com>',NULL),('<1407937109-sup-5701@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 06:41:43',-25200,'2014-08-13 13:41:43',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Thierry Carrez\'s message of 2014-08-13 02:54:58 -0700:\n> Rochelle.RochelleGrober wrote:\n> > [...]\n> > So, with all that prologue, here is what I propose (and please consider proposing your improvements/changes to it).  I would like to see for Kilo:\n> > \n> > - IRC meetings and mailing list meetings beginning with Juno release and continuing through the summit that focus on core project needs (what Thierry call \"strategic\") that as a set would be considered the primary focus of the Kilo release for each project.  This could include high priority bugs, refactoring projects, small improvement projects, high interest extensions and new features, specs that didn\'t make it into Juno, etc.\n> > - Develop the list and prioritize it into \"Needs\" and \"Wants.\" Consider these the feeder projects for the two runways if you like.  \n> > - Discuss the lists.  Maybe have a community vote? The vote will \"freeze\" the list, but as in most development project freezes, it can be a soft freeze that the core, or drivers or TC can amend (or throw out for that matter).\n> > [...]\n> \n> One thing we\'ve been unable to do so far is to set \"release goals\" at\n> the beginning of a release cycle and stick to those. It used to be\n> because we were so fast moving that new awesome stuff was proposed\n> mid-cycle and ends up being a key feature (sometimes THE key feature)\n> for the project. Now it\'s because there is so much proposed noone knows\n> what will actually get completed.\n> \n> So while I agree that what you propose is the ultimate solution (and the\n> workflow I\'ve pushed PTLs to follow every single OpenStack release so\n> far), we have struggled to have the visibility, long-term thinking and\n> discipline to stick to it in the past. If you look at the post-summit\n> plans and compare to what we end up in a release, you\'ll see quite a lot\n> of differences :)\n> \n\nI think that shows agility, and isn\'t actually \"a problem\". 6 months\nis quite a long time in the future for some business models. Strategic\nimprovements for the project should be able to stick to a 6 month\nschedule, but companies will likely be tactical about where their\ndeveloper resources are directed for feature work.\n\nThe fact that those resources land code upstream is one of the greatest\nstrengths of OpenStack. Any potential impact on how that happens should\nbe carefully considered when making any changes to process and\ngovernance.\n\n\n','<53EB35F2.3020203@openstack.org>',NULL),('<1407943497.26856.345.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 16:24:57',3600,'2014-08-13 15:24:57',NULL,'[openstack-dev] [nova] so what do i do about libvirt-python if\n i\'m on precise?','On Wed, 2014-08-13 at 10:26 +0100, Daniel P. Berrange wrote:\n> On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote:\n> > On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:\n> > > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:\n> > > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:\n> > > > > While forcing people to move to a newer version of libvirt is\n> > > > > doable on most environments, do we want to do that now? What is\n> > > > > the benefit of doing so?\n> > > > [...]\n> > > > \n> > > > The only dog I have in this fight is that using the split-out\n> > > > libvirt-python on PyPI means we finally get to run Nova unit tests\n> > > > in virtualenvs which aren\'t built with system-site-packages enabled.\n> > > > It\'s been a long-running headache which I\'d like to see eradicated\n> > > > everywhere we can. I understand though if we have to go about it\n> > > > more slowly, I\'m just excited to see it finally within our grasp.\n> > > > -- \n> > > > Jeremy Stanley\n> > > >\n> > > We aren\'t quite forcing people to move to newer versions. Only those\n> > > installing nova test-requirements need newer libvirt.\n> > \n> > Yeah, I\'m a bit confused about the problem here. Is it that people want\n> > to satisfy test-requirements through packages rather than using a\n> > virtualenv?\n> > \n> > (i.e. if people just use virtualenvs for unit tests, there\'s no problem\n> > right?)\n> > \n> > If so, is it possible/easy to create new, alternate packages of the\n> > libvirt python bindings (from PyPI) on their own separately from the\n> > libvirt.so and libvirtd packages?\n> \n> The libvirt python API is (mostly) automatically generated from a\n> description of the XML that is built from the C source files. In\n> tree with have fakelibvirt which is a semi-crappy attempt to provide\n> a pure python libvirt client API with the same signature. IIUC, what\n> you are saying is that we should get a better fakelibvirt that is\n> truely identical with same API coverage /signatures as real libvirt ?\n\nNo, I\'m saying that people are installing packaged versions of recent\nreleases of python libraries. But they\'re skeptical about upgrading\ntheir libvirt packages. With the work done to enable libvirt be uploaded\nto PyPI, can\'t the two be decoupled? Can\'t we have packaged versions of\nthe recent python bindings on PyPI that are independent of the base\npackages containing libvirt.so and libvirtd?\n\n(Or I could be completely misunderstanding the issue people are seeing)\n\nMark.\n\n\n\n','<20140813092605.GD14189@redhat.com>',NULL),('<1407946005.26856.363.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 17:06:45',3600,'2014-08-13 16:06:45',NULL,'[openstack-dev] [nova] stable branches & failure to handle\n review backlog','On Tue, 2014-07-29 at 14:04 +0200, Thierry Carrez wrote:\n> Ihar Hrachyshka a ?crit :\n> > On 29/07/14 12:15, Daniel P. Berrange wrote:\n> >> Looking at the current review backlog I think that we have to\n> >> seriously question whether our stable branch review process in\n> >> Nova is working to an acceptable level\n> > \n> >> On Havana\n> > \n> >>   - 43 patches pending\n> >>   - 19 patches with a single +2\n> >>   - 1 patch with a -1\n> >>   - 0 patches wit a -2\n> >>   - Stalest waiting 111 days since most recent patch upload\n> >>   - Oldest waiting 250 days since first patch upload\n> >>   - 26 patches waiting more than 1 month since most recent upload\n> >>   - 40 patches waiting more than 1 month since first upload\n> > \n> >> On Icehouse:\n> > \n> >>   - 45 patches pending\n> >>   - 17 patches with a single +2\n> >>   - 4 patches with a -1\n> >>   - 1 patch with a -2\n> >>   - Stalest waiting 84 days since most recent patch upload\n> >>   - Oldest waiting 88 days since first patch upload\n> >>   - 10 patches waiting more than 1 month since most recent upload\n> >>   - 29 patches waiting more than 1 month since first upload\n> > \n> >> I think those stats paint a pretty poor picture of our stable branch\n> >> review process, particularly Havana.\n> > \n> >> It should not take us 250 days for our review team to figure out whether\n> >> a patch is suitable material for a stable branch, nor should we have\n> >> nearly all the patches waiting more than 1 month in Havana.\n> > \n> >> These branches are not getting sufficient reviewer attention and we need\n> >> to take steps to fix that.\n> > \n> >> If I had to set a benchmark, assuming CI passes, I\'d expect us to either\n> >> approve or reject submissions for stable within a 2 week window in the\n> >> common case, 1 month at the worst case.\n> > \n> > Totally agreed.\n> \n> A bit of history.\n> \n> At the dawn of time there were no OpenStack stable branches, each\n> distribution was maintaining its own stable branches, duplicating the\n> backporting work.\n\nI\'m not sure how much backporting was going on at the time of the Essex\nsummit. I\'m sure Ubuntu had some backports, but that was probably about\nit?\n\n>  At some point it was suggested (mostly by RedHat and\n> Canonical folks) that there should be collaboration around that task,\n> and the OpenStack project decided to set up \"official\" stable branches\n> where all distributions could share the backporting work. The stable\n> team group was seeded with package maintainers from all over the distro\n> world.\n\nDuring that first design summit session, it was mainly you, me and\nDaviey discussing. Both you and Daviey saw this primarily about distros\ncollaborating, but I never saw it that way.\n\nI don\'t see how any self-respecting open-source project can throw a\nrelease over the wall and have no ability to address critical bugs with\nthat release until the next release 6 months later which will also\ninclude a bunch of new feature work with new bugs. That\'s not a distro\nmaintainer point of view.\n\nAt that Essex summit, we were lamenting how many critical bugs in Nova\nhad been discovered shortly after the Diablo release. Our inability to\ndo a bugfix release of Nova for Diablo seemed like a huge problem to me.\n\n> So these branches originally only exist as a convenient place to\n> collaborate on backporting work. This is completely separate from\n> development work, even if those days backports are often proposed by\n> developers themselves. The stable branch team is separate from the rest\n> of OpenStack teams. We have always been very clear tht if the stable\n> branches are no longer maintained (i.e. if the distributions don\'t see\n> the value of those anymore), then we\'ll consider removing them. We, as a\n> project, only signed up to support those as long as the distros wanted them.\n\nYou can certainly argue that the project never signed up for the\nresponsibility. I don\'t see it that way, but there was certainly always\na debate whether this was the project taking responsibility for bugfix\nreleases or whether it was just downstream distros collaborating.\n\nThe thing about branches going away if they\'re not maintained isn\'t\nanything unusual. If *any* effort within the project becomes so\nunmaintained due to a lack of interest such that we can\'t stand over it,\nthen we should consider retiring it.\n\n> We have been adding new members to the stable branch teams recently, but\n> those tend to come from development teams rather than downstream\n> distributions, and that starts to bend the original landscape.\n> Basically, the stable branch needs to be very conservative to be a\n> source of safe updates -- downstream distributions understand the need\n> to weigh the benefit of the patch vs. the disruption it may cause.\n> Developers have another type of incentive, which is to get the fix they\n> worked on into stable releases, without necessarily being very\n> conservative. Adding more -core people to the stable team to compensate\n> the absence of distro maintainers will ultimately kill those branches.\n\nThat\'s quite a leap to say that -core team members will be so incapable\nof the appropriate level of conservatism that the branch will be killed.\n\nThe idea behind not automatically granting +2 on stable/* to -core\nmembers was simply we didn\'t want people diving in and approving\nunsuitable stuff out of ignorance.\n\nI could totally see an argument now that everyone is a lot more familiar\nwith gerrit, the concept of stable releases is well established and we\nshould be able to trust -core team members to learn how to make the risk\nvs benefit tradeoffs needed for stable reviews.\n\nMark.\n\n\n\n','<53D78DDA.30108@openstack.org>',NULL),('<1407963482.969412914@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-08-13 15:58:02',-18000,'2014-08-13 20:58:02',NULL,'[openstack-community] Promotional Item Recommendations for New\n	OpenStack Store','\nHi everyone,  we are in the process of setting up an OpenStack Store!  It will take a couple of months.  It will include promotional logo items plus reusable assets you can use for local events (banners, tablecloths, etc.) on a borrow or purchase basis.  \n \nWe request your input on promotional items.  So far, popular items we are planning are\nApparel (current and past t-shirts, hoodies, men\'s and women\'s sizes)\nThe North Face laptop backpacks\nPens\nUniversal travel adapters\nStickers\nPlease reply ([ kathyc at openstack.org ]( mailto:kathyc at openstack.org )) with any additional promotional logo items you\'d like to see in the initial store by Monday, August 18.  We can add more later as well. Thank you.\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140813/c227c655/attachment.html>\n\n',NULL,NULL),('<1407968591.26856.369.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 23:23:11',3600,'2014-08-13 22:23:11',NULL,'[openstack-dev] [all] 3rd Party CI vs. Gerrit','On Wed, 2014-08-13 at 12:05 -0700, James E. Blair wrote:\n> corvus at inaugust.com (James E. Blair) writes:\n> \n> > Sean Dague <sean at dague.net> writes:\n> >\n> >> This has all gone far enough that someone actually wrote a Grease Monkey\n> >> script to purge all the 3rd Party CI content out of Jenkins UI. People\n> >> are writing mail filters to dump all the notifications. Dan Berange\n> >> filters all them out of his gerrit query tools.\n> >\n> > I should also mention that there is a pending change to do something\n> > similar via site-local Javascript in our Gerrit:\n> >\n> >   https://review.openstack.org/#/c/95743/\n> >\n> > I don\'t think it\'s an ideal long-term solution, but if it works, we may\n> > have some immediate relief without all having to install greasemonkey\n> > scripts.\n> \n> You may have noticed that this has merged, along with a further change\n> that shows the latest results in a table format.  (You may need to\n> force-reload in your browser to see the change.)\n\nBeautiful! Thank you so much to everyone involved.\n\nMark.\n\n\n\n','<87k36ci51k.fsf@meyer.lemoncheese.net>',NULL),('<1407969943.2444.10.camel@fancy.Bigpond>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 22:45:35',0,'2014-08-13 22:45:35',NULL,'[openstack-dev] Which program for Rally','On Wed, 2014-08-13 at 15:48 -0600, Duncan Thomas wrote:\n> On 13 August 2014 13:57, Matthew Treinish <mtreinish at kortar.org> wrote:\n> > On Tue, Aug 12, 2014 at 01:45:17AM +0400, Boris Pavlovic wrote:\n> >> Keystone, Glance, Cinder, Neutron and Heat are running rally performance\n> >> jobs, that can be used for performance testing, benchmarking, regression\n> >> testing (already now). These jobs supports in-tree plugins for all\n> >> components (scenarios, load generators, benchmark context) and they can use\n> >> Rally fully without interaction with Rally team at all. More about these\n> >> jobs:\n> >> https://docs.google.com/a/mirantis.com/document/d/1s93IBuyx24dM3SmPcboBp7N47RQedT8u4AJPgOHp9-A/\n> >> So I really don\'t see anything like this in tempest (even in observed\n> >> future)\n> \n> > So this is actually the communication problem I mentioned before. Singling out\n> > individual projects and getting them to add a rally job is not \"cross project\"\n> > communication. (this is part of what I meant by \"push using Rally\") There was no\n> > larger discussion on the ML or a topic in the project meeting about adding these\n> > jobs. There was no discussion about the value vs risk of adding new jobs to the\n> > gate. Also, this is why less than half of the integrated projects have these\n> > jobs. Having asymmetry like this between gating workloads on projects helps no\n> > one.\n> \n> So the advantage of the approach, rather than having a massive\n> cross-product discussion, is that interested projects (I\'ve been very\n> interested for a cinder core PoV) act as a test bed for other\n> projects. \'Cross project\' discussions rather come to other teams, they\n> rely on people to find them, where as Boris came to us, said I\'ve got\n> this thing you might like, try it out, tell me what you want. He took\n> feedback, iterated fast and investigated bugs. It has been a genuine\n> pleasure to work with him, and I feel we made progress faster than we\n> would have done if it was trying to please everybody.\n> \n> > That being said the reason I think osprofiler has been more accepted and it\'s\n> > adoption into oslo is not nearly as contentious is because it\'s an independent\n> > library that has value outside of itself. You don\'t need to pull in a monolithic\n> > stack to use it. Which is a design point more conducive with the rest of\n> > OpenStack.\n> \n> Sorry, are you suggesting tempest isn\'t a giant monolithic thing?\n> Because I was able to comprehend the rally code very quickly, that\n> isn\'t even slightly true of tempest. Having one simple tool that does\n> one thing well is exactly what rally has tried to do - tempest seems\n> to want to be five different things at once (CI, instalation tests,\n> trademark, preformance, stress testing, ...)\n> \n> >> Matt, Sean - seriously community is about convincing people, not about\n> >> forcing people to do something against their wiliness.  You are making huge\n> >> architectural decisions without deep knowledge about what is Rally, what\n> >> are use cases, road map, goals and auditory.\n> >>\n> >> IMHO community in my opinion is thing about convincing people. So QA\n> >> program should convince Rally team (at least me) to do such changes. Key\n> >> secret to convince me, is to say how this will help OpenStack to perform\n> >> better.\n> >\n> > If community, per your definition, is about convincing people then there needs\n> > to be a 2-way discussion. This is an especially key point considering the\n> > feedback on this thread is basically the same feedback you\'ve been getting since\n> > you first announced Rally on the ML. [1] (and from even before that I think, but\n> > it\'s hard to remember all the details from that far back)  I\'m afraid that\n> > without a shared willingness to explore what we\'re suggesting because of\n> > preconceived notions then I fail to see the point in moving forward. The fact\n> > that this feedback has been ignored is why this discussion has come up at all.\n> >\n> >>\n> >> Currently Rally team see a lot of issues related to this decision:\n> >>\n> >> 1) It breaks already existing performance jobs (Heat, Glance, Cinder,\n> >> Neutron, Keystone)\n> >\n> > So firstly, I want to say I find these jobs troubling. Not just from the fact\n> > that because of the nature of the gate (2nd level virt on public clouds) the\n> > variability between jobs can be staggering. I can\'t imagine what value there is\n> > in running synthetic benchmarks in this environment. It would only reliably\n> > catch the most egregious of regressions. Also from what I can tell none of these\n> > jobs actually compare the timing data to the previous results, it just generates\n> > the data and makes a pretty graph. The burden appears to be on the user to\n> > figure out what it means, which really isn\'t that useful. How have these jobs\n> > actually helped? IMO the real value in performance testing in the gate is to\n> > capture the longer term trends in the data. Which is something these jobs are\n> > not doing.\n> \n> So I put in a change to dump out the raw data from each run into a\n> zipped json file so that I can start looking at the value of\n> collecting this data.... As an experiment I think it is very worth\n> while. The gate job is none voting, and apparently, at least on the\n> cinder front, highly reliable. The job runs fast enough it isn\'t\n> slowing the gate down - we aren\'t running out of nodes on the gate as\n> far as I can tell, so I don\'t understand the hostility towards it.\n> We\'ll run it for a bit, see if it proves useful, if it doesn\'t then we\n> can turn it off and try something else.\n> \n> I\'m confused by the hostility about this gate job - it is costing us\n> nothing, if it turns out to be a pain we\'ll turn it off.\n> \n> Rally as a general tool has enabled me do do things that I wouldn\'t\n> even consider trying with tempest. There shouldn\'t be a problem with a\n> small number of parallel efforts - that\'s a founding principle of\n> opensource in general.\n\nI can agree with everything you said here.\nFrom the Heat team\'s perspective we want to do some work on improving\nscale and\nperformance and this is a very valuable tool to have at our disposal.\n\n-Angus\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140813/a727c427/attachment.pgp>\n\n','<CAOyZ2aHXTF3pJgyHccwhrBQ7iaVFuhnZ3goFgmQex6N04eyqdQ@mail.gmail.com>',NULL),('<1408007173.26856.382.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 10:06:13',3600,'2014-08-14 09:06:13',NULL,'[openstack-dev] [nova] Retrospective veto revert policy','On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> (Terrible name for a policy, I know)\n> \n> From the version_cap saga here:\n> \n>   https://review.openstack.org/110754\n> \n> I think we need a better understanding of how to approach situations\n> like this.\n> \n> Here\'s my attempt at documenting what I think we\'re expecting the\n> procedure to be:\n> \n>   https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy\n> \n> If it sounds reasonably sane, I can propose its addition to the\n> \"Development policies\" doc.\n\n(In the spirit of \"we really need to step back and laugh at ourselves\nsometimes\" ... )\n\nTwo years ago, we were worried about patches getting merged in less than\n2 hours and had a discussion about imposing a minimum review time. How\ntimes have changed! Is it even possible to land a patch in less than two\nhours now? :)\n\nLooking back over the thread, this part stopped me in my tracks:\n\n  https://lists.launchpad.net/openstack/msg08625.html\n\n    On Tue, Mar 13, 2012, Mark McLoughlin <markmc at xxxxxxxxxx> wrote:\n\n    > Sometimes there can be a few folks working through an issue together and\n    > the patch gets pushed and approved so quickly that no-one else gets a\n    > chance to review.\n\n    Everyone has an opportunity to review even after a patch gets merged.\n\n    JE\n\nIt\'s not quite perfect, but if you squint you could conclude that\nJohannes and I have both completely reversed our opinions in the\nintervening two years :)\n\nThe lesson I take from that is to not get too caught up in the current\nmoment. We\'re growing and evolving rapidly. If we assume everyone is\nacting in good faith, and allow each other to debate earnestly without\nfeelings getting hurt ... we should be able to work through anything.\n\nNow, back on topic - digging through that thread, it doesn\'t seem we\nsettled on the idea of \"we can just revert it later if someone has an\nobjection\" in this thread. Does anyone recall when that idea first came\nup?\n\nThanks,\nMark.\n\n\n\n','<1407855404.26856.196.camel@sorcha>',NULL),('<1408008097.28295.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-14 17:21:37',28800,'2014-08-14 09:21:37',NULL,'[Openstack] [TripleO] Error: Node Not Found','Hi all,\n\n\n\n\n\nI have successfully done a tripleo setup using RDO instack in?\na virtual machine environment. Now, I deleted the overcloud and?\nI am trying to add a physical node to the setup, but I get the error\nas the setup has failed.?\n\nHere are the nova logs:\n\n2014-08-14 04:55:02.449 2208 WARNING nova.compute.manager [-] Bandwidth usage not supported by hypervisor.\n2014-08-14 04:55:37.606 2208 ERROR nova.virt.baremetal.virtual_power_driver [-] Node \"overcloud-notcompute0-fl3hqbooytsv\" with MAC address [u\'xxxxxxxxxxxx\'] not found.\n2014-08-14 04:55:37.607 2208 ERROR nova.compute.manager [-] [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] Periodic sync_power_state task had an error while processing an in\\\nstance.\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] Traceback (most recent call last):\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", lin\\\ne 5206, in _sync_power_states\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? vm_instance = self.driver.get_info(db_instance)\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/virt/baremetal/driver.py\\\n\", line 447, in get_info\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? ps = pm.is_power_on()\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/virt/baremetal/virtual_p\\\nower_driver.py\", line 200, in is_power_on\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? raise exception.NodeNotFound(node_id=self._node_name)\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] NodeNotFound: Node overcloud-notcompute0-fl3hqbooytsv could not be fou\\\nnd.\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528]\n\nI understand from the log that the setup is not able to find the node.\nBut I can ping the machine from my undercloud, then why can\'t it find\nit at the time of deployment?\n\nRegards,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140814/1a9cf0c4/attachment.html>\n\n','<1408008003.93291.YahooMailNeo@web194601.mail.sg3.yahoo.com>',NULL),('<1408008097.28295.YahooMailNeo@web194602.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 17:21:37',28800,'2014-08-14 09:21:37',NULL,'[openstack-dev] [TripleO] Error: Node Not Found','Hi all,\n\n\n\n\n\nI have successfully done a tripleo setup using RDO instack in?\na virtual machine environment. Now, I deleted the overcloud and?\nI am trying to add a physical node to the setup, but I get the error\nas the setup has failed.?\n\nHere are the nova logs:\n\n2014-08-14 04:55:02.449 2208 WARNING nova.compute.manager [-] Bandwidth usage not supported by hypervisor.\n2014-08-14 04:55:37.606 2208 ERROR nova.virt.baremetal.virtual_power_driver [-] Node \"overcloud-notcompute0-fl3hqbooytsv\" with MAC address [u\'xxxxxxxxxxxx\'] not found.\n2014-08-14 04:55:37.607 2208 ERROR nova.compute.manager [-] [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] Periodic sync_power_state task had an error while processing an in\\\nstance.\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] Traceback (most recent call last):\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", lin\\\ne 5206, in _sync_power_states\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? vm_instance = self.driver.get_info(db_instance)\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/virt/baremetal/driver.py\\\n\", line 447, in get_info\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? ps = pm.is_power_on()\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? File \"/usr/lib/python2.7/site-packages/nova/virt/baremetal/virtual_p\\\nower_driver.py\", line 200, in is_power_on\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] ? ? raise exception.NodeNotFound(node_id=self._node_name)\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528] NodeNotFound: Node overcloud-notcompute0-fl3hqbooytsv could not be fou\\\nnd.\n2014-08-14 04:55:37.607 2208 TRACE nova.compute.manager [instance: 4be32cfe-0674-4668-aba4-6ca75b836528]\n\nI understand from the log that the setup is not able to find the node.\nBut I can ping the machine from my undercloud, then why can\'t it find\nit at the time of deployment?\n\nRegards,\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140814/1a9cf0c4/attachment.html>\n\n','<1408008003.93291.YahooMailNeo@web194601.mail.sg3.yahoo.com>',NULL),('<1408011176.26856.399.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 11:12:56',3600,'2014-08-14 10:12:56',NULL,'[openstack-dev] [nova] Retrospective veto revert policy','On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote:\n> Hey\n> \n> (Terrible name for a policy, I know)\n> \n> From the version_cap saga here:\n> \n>   https://review.openstack.org/110754\n> \n> I think we need a better understanding of how to approach situations\n> like this.\n> \n> Here\'s my attempt at documenting what I think we\'re expecting the\n> procedure to be:\n> \n>   https://etherpad.openstack.org/p/nova-retrospective-veto-revert-policy\n> \n> If it sounds reasonably sane, I can propose its addition to the\n> \"Development policies\" doc.\n\nProposed here: https://review.openstack.org/114188\n\nThanks,\nMark.\n\n\n\n','<1407855404.26856.196.camel@sorcha>',NULL),('<1408044716.1425.28.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 14:31:56',-18000,'2014-08-14 19:31:56',NULL,'[openstack-dev] [OpenStack-Dev][Cinder] Cinder Core nomination','Great nomination Walt.  Thank you!\n\n+1\n\nThank you Xing for your contributions!\n\nJay\n\nOn Thu, 2014-08-14 at 06:55 +0000, Boring, Walter wrote:\n> Hey guys,\n>    I wanted to pose a nomination for Cinder core.\n> \n> Xing Yang.\n> She has been active in the cinder community for many releases and has worked on several drivers as well as other features for cinder itself.   She has been doing an awesome job doing reviews and helping folks out in the #openstack-cinder irc channel for a long time.   I think she would be a good addition to the core team.\n> \n> \n> Walt\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<48966877BB617A4CAA36414F27B17AD347339A9F@G4W3294.americas.hpqcorp.net>',NULL),('<1408079810.4760.19.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 05:16:35',0,'2014-08-15 05:16:35',NULL,'[openstack-dev]  [Octavia] Object Model and DB Structure','So I\'ve been assuming that the Octavia object model would be an exact\ncopy of the neutron lbaas one with additional information for Octavia.\nHowever, after thinking about it I\'m not sure this is the right way to\ngo because the object model in neutron lbaas may change in the future,\nand Octavia can\'t just change it\'s object model when neutron\nlbaas/openstack lbaas changes it\'s object model.  So if there are any\nlessons learned we would like to apply to Octavia\'s object model now is\nthe time.\n\nEntity name changes are also on the table if people don\'t really like\nsome of the names.  Even adding new entities or removing entities if\nthere are good reasons isn\'t out of the question.\n\nAnyway here are a few of my suggestions.  Please add on to this if you\nwant.  Also, just flat out tell me I\'m wrong on some of htese\nsuggestions if you feel as such.\n\nA few improvements I\'d suggest (using the current entity names):\n-A real root object that is the only top level object (loadbalancer).\n--This would be 1:M relationship with Listeners, but Listeners would\nonly be children of loadbalancers.\n--Pools, Members, and Health Monitors would follow the same workflow.\n--Basically no shareable entities.\n\n-Provisioning status only on the root object (loadbalancer).\n--PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a\nDEFEERRED status! YAY!)\n--Also maybe a DELETED status.\n\n-Operating status on other entities\n--ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE\n--Pools and Members\n--Listeners have been mentioned but I\'d like to hear more details on\nthat.\n\n-Adding status_description field in, or something similar.  Would only\neixst on loadbalancer entity if loadbalancer is the only top level\nobject.\n\nThanks,\nBrandon\n\n','<CAAGw+Zr3n3L-BD2aMsM7od+G4z0X302onYCf1VqMDCyVzj=wzA@mail.gmail.com>',NULL),('<1408085201.4273.17.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-15 08:46:41',7200,'2014-08-15 06:46:41',NULL,'[Openstack] Connect VM network to exists VLAN network','Hi Nhan, \nI guess more information is required to help you out there. \n\nIt would be helpful to know which setup you\'re using, e.g. a singlenode\nor multinode setup, openvswitch for network virtualiation or something\nelse? Are you using nova network or neutron networking?\n\nIf I got it right you created a tenant network in openstack (in your\ncase vm network). In addition your host (hypervisor) has a an eth\ninterface into the physical network, right? \n\nYou also mentioned that your physical network is a vlan network. Is your\nhypervisor aware of this vlan tagging or is this done by a access port\nconfig in your switch?\n\n\nAnd what you want to achieve is to connect a vm attached to the\nopenstack vm network to your physical vlan network. Did I get you right?\n\nBasically you would create a so called \"provider network\" that\nrepresents your physical network and connect this provider network via a\nvirtual router to your vm network.\n\nMore information you can find here:\nhttp://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n\n\nRegards,\nAndreas\n\n\n\nOn Fri, 2014-08-15 at 00:00 +0700, Nhan Cao wrote:\n> Hi \n> I have to network:\n> vm network: 10.2.21.0/24 \n> exist VLAN network: 192.168.1.0/24\n> I want to connect from my VM network to physic VLAN network. \n> \n> How i config to connect?\n> \n> \n> \n> Thanks :)\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<CACFvPvMCjNbV7oRBmEpNXuaPNgq2qKtB7Wf_WxT=keoqZU6wFQ@mail.gmail.com>',NULL),('<1408085201.4273.17.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-15 08:46:41',7200,'2014-08-15 06:46:41',NULL,'[Openstack-operators] [Openstack] Connect VM network to exists\n	VLAN network','Hi Nhan, \nI guess more information is required to help you out there. \n\nIt would be helpful to know which setup you\'re using, e.g. a singlenode\nor multinode setup, openvswitch for network virtualiation or something\nelse? Are you using nova network or neutron networking?\n\nIf I got it right you created a tenant network in openstack (in your\ncase vm network). In addition your host (hypervisor) has a an eth\ninterface into the physical network, right? \n\nYou also mentioned that your physical network is a vlan network. Is your\nhypervisor aware of this vlan tagging or is this done by a access port\nconfig in your switch?\n\n\nAnd what you want to achieve is to connect a vm attached to the\nopenstack vm network to your physical vlan network. Did I get you right?\n\nBasically you would create a so called \"provider network\" that\nrepresents your physical network and connect this provider network via a\nvirtual router to your vm network.\n\nMore information you can find here:\nhttp://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n\n\nRegards,\nAndreas\n\n\n\nOn Fri, 2014-08-15 at 00:00 +0700, Nhan Cao wrote:\n> Hi \n> I have to network:\n> vm network: 10.2.21.0/24 \n> exist VLAN network: 192.168.1.0/24\n> I want to connect from my VM network to physic VLAN network. \n> \n> How i config to connect?\n> \n> \n> \n> Thanks :)\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<CACFvPvMCjNbV7oRBmEpNXuaPNgq2qKtB7Wf_WxT=keoqZU6wFQ@mail.gmail.com>',NULL),('<1408087122.2706.3.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 15:18:42',28800,'2014-08-15 07:18:42',NULL,'[openstack-dev] gettext question about oslo.i18n library','Hi,\n\n  Recently I just read the code of oslo.i18n library,\n  The lazy translation idea is great!\n\n  But I found a question about gettext \"contextual markers\"\n  and \"plural form\", such as pgettext and ungettext functions,\n  see [3].\n\n  It seems the two gettext functions are missing in the oslo.i18n\nlibrary.\n  Is it correct? or will support it?\n\nThanks,\n  Peng Wu\n\nRefer URL:\n1. https://github.com/openstack/oslo.i18n\n2.\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html\n3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings\n\n\n\n\n',NULL,NULL),('<1408102576.4273.30.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-15 13:36:16',7200,'2014-08-15 11:36:16',NULL,'[Openstack] [Openstack-operators] Connect VM network to exists\n VLAN network','Hi, \njust that we\'re on the same page. Please have a look at this picture:\nhttp://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png\n\nWith the provider network you create a network that matches the green\nExternal & the purple api network (as you have a combined controller +\nnetwork node). This is where you already have vlan, right? \n\nAnd on the green data network you try to use gre, right?\n\nOr does you controller only have one physical nic for all kind of\ntraffic?\n\n\nI\'m sorry but I do not yet understand your setup and what you\'re trying\nto achieve.\n\nPlease keep always the mailing lists on cc, as others might also be\ninterested.\n\n\n\nRegards,\nAndreas\n\n\n\nOn Fri, 2014-08-15 at 14:21 +0700, Nhan Cao wrote:\n> hi,\n> i deploy on multinode with neutron and openvswitch.\n> My Infrastructure has a exists VLAN, now, i\'m using GRE type network.\n> I found a article about that\n>  http://trickycloud.wordpress.com/2013/11/12/setting-up-a-flat-network-with-neutron/\n> Could you give me a advice? i should choose VLAN or GRE for best?\n> Thanks\n> \n> \n> \n> \n> \n> \n> 2014-08-15 13:46 GMT+07:00 Andreas Scheuring\n> <scheuran at linux.vnet.ibm.com>:\n>         Hi Nhan,\n>         I guess more information is required to help you out there.\n>         \n>         It would be helpful to know which setup you\'re using, e.g. a\n>         singlenode\n>         or multinode setup, openvswitch for network virtualiation or\n>         something\n>         else? Are you using nova network or neutron networking?\n>         \n>         If I got it right you created a tenant network in openstack\n>         (in your\n>         case vm network). In addition your host (hypervisor) has a an\n>         eth\n>         interface into the physical network, right?\n>         \n>         You also mentioned that your physical network is a vlan\n>         network. Is your\n>         hypervisor aware of this vlan tagging or is this done by a\n>         access port\n>         config in your switch?\n>         \n>         \n>         And what you want to achieve is to connect a vm attached to\n>         the\n>         openstack vm network to your physical vlan network. Did I get\n>         you right?\n>         \n>         Basically you would create a so called \"provider network\" that\n>         represents your physical network and connect this provider\n>         network via a\n>         virtual router to your vm network.\n>         \n>         More information you can find here:\n>         http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n>         \n>         \n>         Regards,\n>         Andreas\n>         \n>         \n>         \n>         On Fri, 2014-08-15 at 00:00 +0700, Nhan Cao wrote:\n>         > Hi\n>         > I have to network:\n>         > vm network: 10.2.21.0/24\n>         > exist VLAN network: 192.168.1.0/24\n>         > I want to connect from my VM network to physic VLAN network.\n>         >\n>         > How i config to connect?\n>         >\n>         >\n>         >\n>         > Thanks :)\n>         >\n>         >\n>         \n>         > _______________________________________________\n>         > Mailing list:\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>         > Post to     : openstack at lists.openstack.org\n>         > Unsubscribe :\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-operators mailing list\n>         OpenStack-operators at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n\n\n\n\n','<CACFvPvPzCX_k4=cU7w04bWGTwR6BRXW2w_ks3Z9tBQJDxu-c6w@mail.gmail.com>',NULL),('<1408102576.4273.30.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-15 13:36:16',7200,'2014-08-15 11:36:16',NULL,'[Openstack-operators] [Openstack] Connect VM network to exists\n VLAN network','Hi, \njust that we\'re on the same page. Please have a look at this picture:\nhttp://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png\n\nWith the provider network you create a network that matches the green\nExternal & the purple api network (as you have a combined controller +\nnetwork node). This is where you already have vlan, right? \n\nAnd on the green data network you try to use gre, right?\n\nOr does you controller only have one physical nic for all kind of\ntraffic?\n\n\nI\'m sorry but I do not yet understand your setup and what you\'re trying\nto achieve.\n\nPlease keep always the mailing lists on cc, as others might also be\ninterested.\n\n\n\nRegards,\nAndreas\n\n\n\nOn Fri, 2014-08-15 at 14:21 +0700, Nhan Cao wrote:\n> hi,\n> i deploy on multinode with neutron and openvswitch.\n> My Infrastructure has a exists VLAN, now, i\'m using GRE type network.\n> I found a article about that\n>  http://trickycloud.wordpress.com/2013/11/12/setting-up-a-flat-network-with-neutron/\n> Could you give me a advice? i should choose VLAN or GRE for best?\n> Thanks\n> \n> \n> \n> \n> \n> \n> 2014-08-15 13:46 GMT+07:00 Andreas Scheuring\n> <scheuran at linux.vnet.ibm.com>:\n>         Hi Nhan,\n>         I guess more information is required to help you out there.\n>         \n>         It would be helpful to know which setup you\'re using, e.g. a\n>         singlenode\n>         or multinode setup, openvswitch for network virtualiation or\n>         something\n>         else? Are you using nova network or neutron networking?\n>         \n>         If I got it right you created a tenant network in openstack\n>         (in your\n>         case vm network). In addition your host (hypervisor) has a an\n>         eth\n>         interface into the physical network, right?\n>         \n>         You also mentioned that your physical network is a vlan\n>         network. Is your\n>         hypervisor aware of this vlan tagging or is this done by a\n>         access port\n>         config in your switch?\n>         \n>         \n>         And what you want to achieve is to connect a vm attached to\n>         the\n>         openstack vm network to your physical vlan network. Did I get\n>         you right?\n>         \n>         Basically you would create a so called \"provider network\" that\n>         represents your physical network and connect this provider\n>         network via a\n>         virtual router to your vm network.\n>         \n>         More information you can find here:\n>         http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n>         \n>         \n>         Regards,\n>         Andreas\n>         \n>         \n>         \n>         On Fri, 2014-08-15 at 00:00 +0700, Nhan Cao wrote:\n>         > Hi\n>         > I have to network:\n>         > vm network: 10.2.21.0/24\n>         > exist VLAN network: 192.168.1.0/24\n>         > I want to connect from my VM network to physic VLAN network.\n>         >\n>         > How i config to connect?\n>         >\n>         >\n>         >\n>         > Thanks :)\n>         >\n>         >\n>         \n>         > _______________________________________________\n>         > Mailing list:\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>         > Post to     : openstack at lists.openstack.org\n>         > Unsubscribe :\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-operators mailing list\n>         OpenStack-operators at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n> \n\n\n\n\n','<CACFvPvPzCX_k4=cU7w04bWGTwR6BRXW2w_ks3Z9tBQJDxu-c6w@mail.gmail.com>',NULL),('<1408109549.2342.6.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 09:32:29',-14400,'2014-08-15 13:32:29',NULL,'[openstack-dev] [Sahara] Swift authentication and backwards\n compatibility','Thoughts, rapidfire :)\n\nIn short, I think we should plan on backward compat unless some stubborn\ntechnical problem gets in our way ....\n\nI think backward compatibility is a good idea.  We can make the\nuser/pass inputs for data objects optional (they are required\ncurrently), maybe even gray them out in the UI with a checkbox to turn\nthem on, or something like that.\n\nSahara can detect whether or not the proxy domain is there, and whether\nor not it can be created.  If Sahara ends up in a situation where it\nthinks user/pass are required, but the data objects don\'t have them,\nwe can return a meaningful error.\n\nThe job manager can key off of the values supplied for the data source\nobjects (no user/pass? must be proxy) and/or cluster configs (for\ninstance, a new cluster config could be added -- if it\'s absent we\nassume \"old\" cluster and therefore old hadoop swfit plugin).  Workflow\ncan be generated accordingly.\n\nThe hadoop swift plugin can look at the config values provided, as you\nnoted yesterday, and get auth tokens in either manor.\n\nBest,\n\nTrev\n\n\nOn Thu, 2014-08-14 at 22:20 -0400, Michael McCune wrote:\n> hello Sahara folks,\n> \n> I am working to get the revamped spec[1] finalized and I\'d like to know the group\'s thoughts on the idea of backward compatibility. It is possible to implement the new authentication method and remain backward compatible, but we will need to keep the username and password inputs in the Swift data forms.\n> \n> Having the backward compatibility would also give Sahara a way to react in situations where the proxy domain is not available or the administrator doesn\'t wish to use it. I\'m not sure this is the behavior we want, but I don\'t know if it is proper for Sahara to exit if no proxy domain can be found.\n> \n> If we choose not to remain backward compatible then we are requiring Sahara operators to create the new proxy domain needed, and they must update all virtual machine images.\n> \n> Thoughts?\n> \n> regards,\n> mike\n> \n> [1]: https://review.openstack.org/#/c/113591/\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1047990955.21411135.1408069218175.JavaMail.zimbra@redhat.com>',NULL),('<1408109755.31115.46.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-15 09:35:55',-14400,'2014-08-15 13:35:55',NULL,'[Openstack-docs] Networking Guide','On Fri, 2014-08-15 at 14:20 +0200, Andreas Jaeger wrote:\n> On 08/15/2014 02:08 PM, Nicholas Chase wrote:\n> > \n> > On 8/15/2014 5:54 AM, Anne Gentle wrote:\n> >> I agree that the focus is neutron, but with the title being OpenStack\n> >> Networking, the introduction absolutely must talk about nova-network\n> >> and the considerations for when you\'d use nova-network instead of\n> >> neutron. I\'ve asked for the spec to reflect this [1]. Even if it\n> >> simply links\n> >> to http://docs.openstack.org/openstack-ops/content/network_design.html\n> >> this book must indicate immediately that there are multiple\n> >> considerations and network solutions. That\'s what I mean here. The\n> >> Install Guide and Ops Guide will continue to have nova-network info,\n> >> and the Networking Guide should point to those as needed.\n> > \n> > Ah! Yes, I agree, that\'s totally reasonable.\n> \n> Yes, adding it to the intro only for context is fine indeed,\n\nThat certainly makes sense. I\'ve pushed another patch for the spec to\naddress this and some other comments.\n\nhttps://review.openstack.org/#/c/113597/\n\n--\nShaun\n\n\n\n\n','<53EDFB00.5020804@suse.com>',NULL),('<1408127469.58601.YahooMailNeo@web161505.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-15 11:31:09',-25200,'2014-08-15 18:31:09',NULL,'[Openstack-operators] unable to access Horizion dashboard with\n	public IP','Hi Team,\n\n\n\n\n\nI am unable to access Dashboard with public IP it stopped working suddenly, I am able to access from private IP,\n\n?[error] [client xx.xx.xx.xx] Script timed out before returning headers: django.wsgi, referer: http://xx.xx.xx.xx/dashboard/project/\n?[error] [client?xx.xx.xx.xx] Script timed out before returning headers: django.wsgi, referer: http://xx.xx.xx.xx/dashboard/project/instances/03-a5ce-4c17-bd5d-cde9adf068d2/\n?[error] [client?xx.xx.xx.xx] Script timed out before returning headers: django.wsgi, referer: http://xx.xx.xx.xx/dashboard/project/\n[error] [client?xx.xx.xx.xx] Script timed out before returning headers: django.wsgi, referer: http://xx.xx.xx.xx/dashboard/project/\n?[error] [client?xx.xx.xx.xx] Script timed out before returning headers: django.wsgi\n[warn] [client?xx.xx.xx.xx] incomplete redirection target of \'/dashboard/\' for URI \'/\' modified to \'http://xx.xx.xx.xx/dashboard/\'\n?[warn] [client?xx.xx.xx.xx] incomplete redirection target of \'/dashboard/\' for URI \'/\' modified to \'http://xx.xx.xx.xx/dashboard/\'\n?[error] [client?xx.xx.xx.xx] File does not exist: /var/www/html/favicon.ico\n?[error] [client?xx.xx.xx.xx] File does not exist: /var/www/html/favicon.ico\n?[warn] [client?xx.xx.xx.xx] incomplete redirection target of \'/dashboard/\' for URI \'/\' modified to \'http://xx.xx.xx.xx/dashboard/\'\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140815/ca2cc1dd/attachment.html>\n\n','<1408126892.57783.YahooMailNeo@web161501.mail.bf1.yahoo.com>',NULL),('<1408132261-sup-8458@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 12:57:35',-25200,'2014-08-15 19:57:35',NULL,'[openstack-dev] [TripleO] fix poor tarball support in\n	source-repositories','Excerpts from Brownell, Jonathan C (Corvallis)\'s message of 2014-08-15 08:11:18 -0700:\n> The current DIB element support for downloading tarballs via \"source-repository\" allows an entry in the following form:\n> \n> <name> tar <targetdir> <url>\n> \n> Today, this feature is currently used only by the mysql DIB element. You can see how it\'s used here:\n> https://github.com/openstack/tripleo-image-elements/blob/master/elements/mysql/source-repository-mysql\n> \n> However, the underlying diskimage-builder implementation of tarball handling is rather odd and inflexible. After downloading the file (or retrieving from cache) and unpacking into a tmp directory, it performs:\n> \n> mv $tmp/*/* $targetdir\n> \n> This does work as long as the tarball follows a structure where all its files/directories are contained within a single directory, but it fails if the tarball contains no subdirectories. (Even worse is when it contains some files and some subdirectories, in which case the files are lost and the contents of all subdirs get lumped together in the output folder.)\n> \n> Since this tarball support is only used today by the mysql DIB element, I would love to fix this in both diskimage-builder and tripleo-image-element by changing to simply:\n> \n> mv $tmp/* $targetdir\n> \n> And then manually tweaking the directory structure of $targetdir from a new install.d script in the mysql element to restore the desired layout.\n> \n> However, it\'s important to note that this will break backwards compatibility if tarball support is used in its current fashion by users with private DIB elements.\n> \n> Personally, I consider the current behavior so egregious that it really needs to be fixed across the board rather than preserving backwards compatibility.\n> \n> Do others agree? If not, do you have suggestions as to how to improve this mechanism cleanly without sacrificing backwards compatibility?\n> \n\nHow about we make a glob to use, so like this:\n\nmysql tar /usr/local/mysql http://someplace/mysql.tar.gz mysql-5.*\n\nThat would result in\n\n    mv $tmp/mysql-5.*/* $targetdir\n\nAnd then we would warn that assuming the glob will be \'*\' is deprecated,\nto be changed in a later release.\n\nUsers who want your proposed behavior would use . until the default\nchanges. That would result in\n\n    mv $tmp/./* $targetdir\n\n\n','<509A48CAD3ABA547BC1C4A2ECFF2C3DC0B4B970A@G6W2480.americas.hpqcorp.net>',NULL),('<1408140719.12368.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 22:10:21',0,'2014-08-15 22:10:21',NULL,'[openstack-dev] [Octavia] Object Model and DB Structure','Yeah, need details on that.  Maybe he\'s talking about having haproxy\nlisten on many ips and ports, each one being a separate front end\nsection and in the haproxy config with each mapped to its own\ndefault_backend.\n\nEven if that is the case, the load balancer + listener woudl still make\nup one of those frontends so the mapping would still be correct.\nThough, maybe a different structure would make more sense if that is the\ncase.\n\nAlso, I\'ve created a WIP review of the initial database structure:\nhttps://review.openstack.org/#/c/114671/\n\nAdded my own comments so everyone please look at that.  Stephen, if you\ncould comment on what German mentioned that\'d be great.\n\nHave a good weekend!\n\n-Brandon\n\nOn Fri, 2014-08-15 at 20:34 +0000, Eichberger, German wrote:\n> --Basically no shareable entities.\n> +1\n> \n> That will make me insanely happy :-)\n> \n> Regarding Listeners: I was assuming that a LoadBalancer would map to an haproxy instance - and a listener would be part of that haproxy. But I heard Stephen say that this so not so clear cut. So maybe listeners map to haproxy instances...\n> \n> German\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \n> Sent: Thursday, August 14, 2014 10:17 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: [openstack-dev] [Octavia] Object Model and DB Structure\n> \n> So I\'ve been assuming that the Octavia object model would be an exact copy of the neutron lbaas one with additional information for Octavia.\n> However, after thinking about it I\'m not sure this is the right way to go because the object model in neutron lbaas may change in the future, and Octavia can\'t just change it\'s object model when neutron lbaas/openstack lbaas changes it\'s object model.  So if there are any lessons learned we would like to apply to Octavia\'s object model now is the time.\n> \n> Entity name changes are also on the table if people don\'t really like some of the names.  Even adding new entities or removing entities if there are good reasons isn\'t out of the question.\n> \n> Anyway here are a few of my suggestions.  Please add on to this if you want.  Also, just flat out tell me I\'m wrong on some of htese suggestions if you feel as such.\n> \n> A few improvements I\'d suggest (using the current entity names):\n> -A real root object that is the only top level object (loadbalancer).\n> --This would be 1:M relationship with Listeners, but Listeners would only be children of loadbalancers.\n> --Pools, Members, and Health Monitors would follow the same workflow.\n> --Basically no shareable entities.\n> \n> -Provisioning status only on the root object (loadbalancer).\n> --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No need for a DEFEERRED status! YAY!) --Also maybe a DELETED status.\n> \n> -Operating status on other entities\n> --ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools and Members --Listeners have been mentioned but I\'d like to hear more details on that.\n> \n> -Adding status_description field in, or something similar.  Would only eixst on loadbalancer entity if loadbalancer is the only top level object.\n> \n> Thanks,\n> Brandon\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C3C7BEE@G2W2441.americas.hpqcorp.net>',NULL),('<1408162565.52049.YahooMailNeo@web163604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 21:16:05',-25200,'2014-08-16 04:16:05',NULL,'[openstack-dev] [neutron] [third-party] What tests are required\n	to be run','hi edgar,\nthe IBM SDNVE system runs a subset of tempest tests currently, but is triggered for all neutron changes.?we are working on adding more tests to our system.?There was an issue with uploading all the logs properly, which i have fixed. one pending item is to upload the console log as well. also, am experiencing some tempest failures since this morning, and i\'m investigating those presently.\nplease take a look at this run from today, for any additional feedback. thanks for your input.\nGerrit Code Review\n\n? \n? ? ? ? ? \nGerrit Code Review\nLoading Gerrit Code Review ... Gerrit requires a JavaScript enabled browser.   \nView on review.openstack.org Preview by Yahoo  \n? \n?\n\n?\n\nthanks!\ndaya kamath\n\n\n________________________________\n From: Edgar Magana <edgar.magana at workday.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \nSent: Saturday, August 16, 2014 4:29 AM\nSubject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run\n \n\nCorrection\n\nThe right links are:\n\nhttps://review.openstack.org/#/c/114629/\n\nhttps://review.openstack.org/#/c/114393/\n\n\nNot this one:\nhttps://review.openstack.org/#/c/40296/\n\n\nEdgar\n\n\nOn 8/15/14, 3:35 PM, \"Edgar Magana\" <edgar.magana at workday.com> wrote:\n\n>Team,\n>\n>I did a quick audit on the Neutron CI. Very sad results. Only few plugins\n>and drivers are running properly and testing all Neutron\n commits.\n>I created a report here:\n>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi\n>n\n>_and_Drivers\n>\n>\n>We will discuss the actions to take on the next Neutron IRC meeting. So\n>please, reach me out to clarify what is the status of your CI.\n>I had two commits to quickly verify the CI reliability:\n>\n>https://review.openstack.org/#/c/114393/\n>\n>https://review.openstack.org/#/c/40296/\n>\n>\n>I would expect all plugins and drivers passing on the first one and\n>failing for the second but I got so many surprises.\n>\n>Neutron code quality and reliability is a top priority, if you ignore this\n>report that plugin/driver will be candidate to be remove from Neutron\n>tree.\n>\n>Cheers,\n>\n>Edgar\n>\n>P.s. I hate to be the inquisitor here? but someone has to do the dirty\n>job!\n>\n>\n>On 8/14/14, 8:30 AM, \"Kyle Mestery\" <mestery at mestery.com> wrote:\n>\n>>Folks, I\'m not sure if all CI\n accounts are running sufficient tests.\n>>Per the requirements wiki page here [1], everyone needs to be running\n>>more than just Tempest API tests, which I still see most neutron\n>>third-party CI setups doing. I\'d like to ask everyone who operates a\n>>third-party CI account for Neutron to please look at the link below\n>>and make sure you are running appropriate tests. If you have\n>>questions, the weekly third-party meeting [2] is a great place to ask\n>>questions.\n>>\n>>Thanks,\n>>Kyle\n>>\n>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting\n>>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140815/7e36ee8c/attachment.html>\n\n','<D013DE94.6236%edgar.magana@workday.com>',NULL),('<1408162683.48520.YahooMailNeo@web163603.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 21:18:03',-25200,'2014-08-16 04:18:03',NULL,'[openstack-dev] [neutron] [third-party] What tests are required\n	to be run','wrong link-\nplease take a look at this one after log fixes have been put in -\nGerrit Code Review\n\n? \n? ? ? ? ? \nGerrit Code Review\nLoading Gerrit Code Review ... Gerrit requires a JavaScript enabled browser.   \nView on review.openstack.org Preview by Yahoo  \n? \n\n\n________________________________\n From: daya kamath <daya_k at yahoo.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \nSent: Saturday, August 16, 2014 9:46 AM\nSubject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run\n \n\n\nhi edgar,\nthe IBM SDNVE system runs a subset of tempest tests currently, but is triggered for all neutron changes.?we are working on adding more tests to our system.?There was an issue with uploading all the logs properly, which i have fixed. one pending item is to upload the console log as well. also, am experiencing some tempest failures since this morning, and i\'m investigating those presently.\nplease take a look at this run from today, for any additional feedback. thanks for your input.\nGerrit Code Review\n\n? \n? ? ? ? ? \nGerrit Code Review\nLoading Gerrit Code Review ... Gerrit requires a JavaScript enabled browser.   \nView on review.openstack.org Preview by Yahoo  \n? \n?\n\n?\n\nthanks!\ndaya kamath\n\n\n________________________________\n From: Edgar Magana <edgar.magana at workday.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \nSent: Saturday, August 16, 2014 4:29 AM\nSubject: Re: [openstack-dev] [neutron] [third-party] What tests are required to be run\n \n\nCorrection\n\nThe right links are:\n\nhttps://review.openstack.org/#/c/114629/\n\nhttps://review.openstack.org/#/c/114393/\n\n\nNot this one:\nhttps://review.openstack.org/#/c/40296/\n\n\nEdgar\n\n\nOn 8/15/14, 3:35 PM, \"Edgar Magana\" <edgar.magana at workday.com> wrote:\n\n>Team,\n>\n>I did a quick audit on the Neutron CI. Very sad results. Only few plugins\n>and drivers are running properly and testing all Neutron\n commits.\n>I created a report here:\n>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi\n>n\n>_and_Drivers\n>\n>\n>We will discuss the actions to take on the next Neutron IRC meeting. So\n>please, reach me out to clarify what is the status of your CI.\n>I had two commits to quickly verify the CI reliability:\n>\n>https://review.openstack.org/#/c/114393/\n>\n>https://review.openstack.org/#/c/40296/\n>\n>\n>I would expect all plugins and drivers passing on the first one and\n>failing for the second but I got so many surprises.\n>\n>Neutron code quality and reliability is a top priority, if you ignore this\n>report that plugin/driver will be candidate to be remove from Neutron\n>tree.\n>\n>Cheers,\n>\n>Edgar\n>\n>P.s. I hate to be the inquisitor here? but someone has to do the dirty\n>job!\n>\n>\n>On 8/14/14, 8:30 AM, \"Kyle Mestery\" <mestery at mestery.com> wrote:\n>\n>>Folks, I\'m not sure if all CI\n accounts are running sufficient tests.\n>>Per the requirements wiki page here [1], everyone needs to be running\n>>more than just Tempest API tests, which I still see most neutron\n>>third-party CI setups doing. I\'d like to ask everyone who operates a\n>>third-party CI account for Neutron to please look at the link below\n>>and make sure you are running appropriate tests. If you have\n>>questions, the weekly third-party meeting [2] is a great place to ask\n>>questions.\n>>\n>>Thanks,\n>>Kyle\n>>\n>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting\n>>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140815/71fba422/attachment.html>\n\n','<1408162565.52049.YahooMailNeo@web163604.mail.gq1.yahoo.com>',NULL),('<1408164199.3981.14.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-16 04:43:01',0,'2014-08-16 04:43:01',NULL,'[openstack-dev] [Octavia] Object Model and DB Structure','Comments in-line\n\nOn Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:\n> Hi folks,\n> \n> \n> I\'m OK with going with no shareable child entities (Listeners, Pools,\n> Members, TLS-related objects, L7-related objects, etc.). This will\n> simplify a lot of things (like status reporting), and we can probably\n> safely work under the assumption that any user who has a use case in\n> which a shared entity is useful is probably also technically savvy\n> enough to not only be able to manage consistency problems themselves,\n> but is also likely to want to have that level of control.\n> \n> \n> Also, an haproxy instance should map to a single listener. This makes\n> management of the configuration template simpler and the behavior of a\n> single haproxy instance more predictable. Also, when it comes to\n> configuration updates (as will happen, say, when a new member gets\n> added to a pool), it\'s less risky and error prone to restart the\n> haproxy instance for just the affected listener, and not for all\n> listeners on the Octavia VM. The only down-sides I see are that we\n> consume slightly more memory, we don\'t have the advantage of a shared\n> SSL session cache (probably doesn\'t matter for 99.99% of sites using\n> TLS anyway), and certain types of persistence wouldn\'t carry over\n> between different listeners if they\'re implemented poorly by the\n> user. :/  (In other words, negligible down-sides to this.)\n\nThis is fine by me for now, but I think this might be something we can\nrevisit later after we have the advantage of hindsight.  Maybe a\nconfigurable option.\n\n> Other upsides: This allows us to set different \"global\" haproxy\n> settings differently per listener as appropriate. (ex. It might make\n> sense to have one of the several forms of keepalive enabled for the\n> TERMINATED_HTTPS listener for performance reasons, but disable\n> keepalive for the HTTP listener for different performance reasons.)\n> \n> \n> I do want to note though, that this also affects the discussion on\n> statuses:\n> \n> \n> On the statuses:  If we\'re using a separate haproxy instance per\n> listener, I think that probably both the loadbalancer and listener\n> objects have different needs here that are appropriate. Specifically,\n> this is what I\'m thinking, regarding the statuses and what they mean:\n> \n> \n> Loadbalancer:\n>   PENDING_CREATE: VIP address is being assigned (reserved, or put on a\n> port) in Neutron, or is being allocated on Octavia VMs.\n>   ACTIVE: VIP address is up and running on at least one Octavia VM\n> (ex. a ping check would succeed, assuming no blocking firewall rules)\n>   PENDING_DELETE: VIP address is being removed from Octavia VM(s) and\n> reservation in Neutron released\n>  (Is there any need for a PENDING_UPDATE status for a loadbalancer?\n> Shouldn\'t the vip_address be immutable after it\'s created?)\n> \n> \n> Listener:\n>  PENDING_CREATE: A new Listener haproxy configuration is being created\n> on Octavia VM(s)\n>  PENDING_UPDATE: An existing Listener haproxy configuration is being\n> updated on Octavia VM(s)\n>  PENDING_DELETE: Listener haproxy configuration is about to be deleted\n> off associated Octavia VM(s)\n>  ACTIVE: haproxy Listener is up and running (ex. responds to TCP SYN\n> check).\n\nI have no problem with this. However, one thing I often do think about\nis that it\'s not really ever going to be load balancing anything with\njust a load balancer and listener.  It has to have a pool and members as\nwell.  So having ACTIVE on the load balancer and listener, and still not\nreally load balancing anything is a bit odd.  Which is why I\'m in favor\nof only doing creates by specifying the entire tree in one call\n(loadbalancer->listeners->pool->members).  Feel free to disagree with me\non this because I know this not something everyone likes.  I\'m sure I am\nforgetting something that makes this a hard thing to do.  But if this\nwere the case, then I think only having the provisioning status on the\nload balancer makes sense again.  The reason I am advocating for the\nprovisioning status on the load balancer is because it still simpler,\nand only one place to look to see if everything were successful or if\nthere was an issue.\n\nAgain though, what you\'ve proposed I am entirely fine with because it\nworks great with having to create a load balancer first, then listener,\nand so forth.  It would also work fine with a single create call as\nwell.\n> \n> I don\'t think that these kinds of status are useful / appropriate for\n> Pool, Member, Healthmonitor, TLS certificate id, or L7 Policy / Rule\n> objects, as ultimately this boils down to configuration lines in an\n> haproxy config somewhere, and really the Listener status is what will\n> be affected when things are changed.\n\nTotal agreement on this.\n> \n> I\'m basically in agreement with Brandon on his points with operational\n> status, though I would like to see these broken out into their various\n> meanings for the different object types. I also think some object\n> types won\'t need an operational status (eg. L7 Policies,\n> healthmonitors, etc.) since these essentially boil down to lines in an\n> haproxy configuration file.\n\nYeah I was thinking could be more descriptive status names for the load\nbalancer and listener statuses.  I was thinking load balancer could have\nPENDING_VIP_CREATE/UPDATE/DELETE, but then that\'d be painting us into a\ncorner.  More general is needed.  With that in mind, the generic\nPENDING_CREATE/UPDATE/DELETE is adequate enough as long as the docs\nexplain what they mean for each object clearly.\n> \n> Does this make sense?\n\nIndeed.\n> \n> Stephen\n> \n> \n> \n> \n> On Fri, Aug 15, 2014 at 3:10 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Yeah, need details on that.  Maybe he\'s talking about having\n>         haproxy\n>         listen on many ips and ports, each one being a separate front\n>         end\n>         section and in the haproxy config with each mapped to its own\n>         default_backend.\n>         \n>         Even if that is the case, the load balancer + listener woudl\n>         still make\n>         up one of those frontends so the mapping would still be\n>         correct.\n>         Though, maybe a different structure would make more sense if\n>         that is the\n>         case.\n>         \n>         Also, I\'ve created a WIP review of the initial database\n>         structure:\n>         https://review.openstack.org/#/c/114671/\n>         \n>         Added my own comments so everyone please look at that.\n>         Stephen, if you\n>         could comment on what German mentioned that\'d be great.\n>         \n>         Have a good weekend!\n>         \n>         -Brandon\n>         \n>         On Fri, 2014-08-15 at 20:34 +0000, Eichberger, German wrote:\n>         > --Basically no shareable entities.\n>         > +1\n>         >\n>         > That will make me insanely happy :-)\n>         >\n>         > Regarding Listeners: I was assuming that a LoadBalancer\n>         would map to an haproxy instance - and a listener would be\n>         part of that haproxy. But I heard Stephen say that this so not\n>         so clear cut. So maybe listeners map to haproxy instances...\n>         >\n>         > German\n>         >\n>         > -----Original Message-----\n>         > From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]\n>         > Sent: Thursday, August 14, 2014 10:17 PM\n>         > To: openstack-dev at lists.openstack.org\n>         > Subject: [openstack-dev] [Octavia] Object Model and DB\n>         Structure\n>         >\n>         > So I\'ve been assuming that the Octavia object model would be\n>         an exact copy of the neutron lbaas one with additional\n>         information for Octavia.\n>         > However, after thinking about it I\'m not sure this is the\n>         right way to go because the object model in neutron lbaas may\n>         change in the future, and Octavia can\'t just change it\'s\n>         object model when neutron lbaas/openstack lbaas changes it\'s\n>         object model.  So if there are any lessons learned we would\n>         like to apply to Octavia\'s object model now is the time.\n>         >\n>         > Entity name changes are also on the table if people don\'t\n>         really like some of the names.  Even adding new entities or\n>         removing entities if there are good reasons isn\'t out of the\n>         question.\n>         >\n>         > Anyway here are a few of my suggestions.  Please add on to\n>         this if you want.  Also, just flat out tell me I\'m wrong on\n>         some of htese suggestions if you feel as such.\n>         >\n>         > A few improvements I\'d suggest (using the current entity\n>         names):\n>         > -A real root object that is the only top level object\n>         (loadbalancer).\n>         > --This would be 1:M relationship with Listeners, but\n>         Listeners would only be children of loadbalancers.\n>         > --Pools, Members, and Health Monitors would follow the same\n>         workflow.\n>         > --Basically no shareable entities.\n>         >\n>         > -Provisioning status only on the root object (loadbalancer).\n>         > --PENDING_CREATE, PENDING_UPDATE, PENDING_DELETE, ACTIVE (No\n>         need for a DEFEERRED status! YAY!) --Also maybe a DELETED\n>         status.\n>         >\n>         > -Operating status on other entities\n>         > --ACTIVE or ONLINE, DEGRADED, INACTIVE or OFFLINE --Pools\n>         and Members --Listeners have been mentioned but I\'d like to\n>         hear more details on that.\n>         >\n>         > -Adding status_description field in, or something similar.\n>         Would only eixst on loadbalancer entity if loadbalancer is the\n>         only top level object.\n>         >\n>         > Thanks,\n>         > Brandon\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZoUqs-Wy8-cKmFM6xkcNnLPvUMcvjMXMv5K4mOmLmbsMQ@mail.gmail.com>',NULL),('<1408199350-sup-6@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-16 07:33:20',-25200,'2014-08-16 14:33:20',NULL,'[openstack-dev] [TripleO] fix poor tarball support in\n	source-repositories','Excerpts from Jyoti Ranjan\'s message of 2014-08-16 00:57:52 -0700:\n> We will have to be little bit cautious in using glob because of its\n> inherent usage pattern. For e.g. the file starting with . will not get\n> matched.\n> \n\nThat is a separate bug, but I think the answer to that is to use rsync\ninstead of mv and globs. So this:\n\n    mv $tmp/./* $destdir\n\nbecomes this:\n\n    rsync --remove-source-files $tmp/. $destdir\n\n\n','<CAKCrtoM+MRKdHXhQbCA0-jV-YwB2BjKc98isiua5u53czUypDA@mail.gmail.com>',NULL),('<1408222800-sup-9008@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-16 14:01:00',-25200,'2014-08-16 21:01:00',NULL,'[openstack-dev] Time to Samba! :-)','Excerpts from Martinx - ?????\'s message of 2014-08-16 12:03:20 -0700:\n> Hey Stackers,\n> \n>  I\'m wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I\'m\n> using it on a daily basis as an AD DC controller, for both Windows and\n> Linux Instances! With replication, file system ACLs - cifs, built-in LDAP,\n> dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool!\n> \n>  In OpenStack ecosystem, there are awesome solutions like Trove, Solum,\n> Designate and etc... Amazing times BTW! So, why not try to integrate\n> Samba4, working as an AD DC, within OpenStack itself?!\n> \n\nBut, if we did that, what would be left for us to reinvent in our own\nslightly different way?\n\n\n','<CAJSM8J0A+XR-eh3b28sOEEL_t0YJU-T37JcW2JtCs4qpEgKMBw@mail.gmail.com>',NULL),('<1408306301.32192.YahooMailNeo@web163601.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-17 13:11:41',-25200,'2014-08-17 20:11:41',NULL,'[openstack-dev] [infra][Neutron] tempest requirements errors\n	while fetching oslo.i18n>=0.1.0','reposting.\nany pointers from folks on the group?\ni dont see the errors below when running gate jobs manually, but when triggered from zuul, the tempest venv setup fails while trying to fetch some of the oslo packages. earlier i was seeing errors in oslo.il8n, now oslo.utils\nmy first question, is if the package with the same version is already available on the system, is it expected for tempest to try and fetch it from a mirror?\n2nd, since it doesnt seem to be a connectivity issue (the manual build works fine), why is the package not available at?\nlost..\npip.log output is here -?\nPaste #96539 | LodgeIt!\n\n? \n? ? ? ? ? \nPaste #96539 | LodgeIt!\nRequirement already up-to-date: warlock>=1.0.1,<2 in /usr/lib/python2.7/site-packages (from python-glanceclient>=0.13.1->tempest==2.dev807.gfcd64c0)\nGetting page http://pypi.openstack.org/openstack/oslo.utils/\nCould not fetch URL http://pypi.opens...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\nthanks in advance!\n\n\n________________________________\n From: daya kamath <daya_k at yahoo.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>; Openstack-infra <openstack-infra at lists.openstack.org> \nSent: Wednesday, August 6, 2014 9:18 AM\nSubject: [infra][Neutron] tempest requirements errors while fetching oslo.i18n>=0.1.0\n \n\n\nall,\ni\'m seeing continuous errors when the gate script starts running tempest tests for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n >= 0.1.0. this is not happening one-shot, continuously, so i dont think there\'s intermittent connectivity issues.\ninterestingly, when i ran the same job on sandbox, it worked fine.\n\nany pointers?\n\nhere\'s the error log -?Paste #90811 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests\n22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve\n22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest\n22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on paste.openstack.org Preview by Yahoo  \n? \n?\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on?paste.openstack.org Preview by Yahoo  \n? \nhere\'s my pip list output -?Paste #90812 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90812 | LodgeIt!\nalembic (0.6.5) amqp (1.3.3) anyjson (0.3.3) argparse (1.2.1) astroid (1.1.0) Babel (1.3) backports.ssl-match-hostname (3.4.0.2) BeautifulSoup (3.2.1) beautifulsoup4 (4.3.2) boto (2.27.0) bzr (2.6.0) ceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)...  \nView on?paste.openstack.org Preview by Yahoo  \n? \n\nTIA for your help!?\nalso, sorry if you get multiple copies of the message, i got a membership disabled message when i sent it out earlier, and trying again..\n\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140817/d970d354/attachment.html>\n\n','<1407296887.12183.YahooMailNeo@web163606.mail.gq1.yahoo.com>',NULL),('<1408306301.32192.YahooMailNeo@web163601.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-17 13:11:41',-25200,'2014-08-17 20:11:41',NULL,'[OpenStack-Infra] [infra][Neutron] tempest requirements errors\n	while fetching oslo.i18n>=0.1.0','reposting.\nany pointers from folks on the group?\ni dont see the errors below when running gate jobs manually, but when triggered from zuul, the tempest venv setup fails while trying to fetch some of the oslo packages. earlier i was seeing errors in oslo.il8n, now oslo.utils\nmy first question, is if the package with the same version is already available on the system, is it expected for tempest to try and fetch it from a mirror?\n2nd, since it doesnt seem to be a connectivity issue (the manual build works fine), why is the package not available at?\nlost..\npip.log output is here -?\nPaste #96539 | LodgeIt!\n\n? \n? ? ? ? ? \nPaste #96539 | LodgeIt!\nRequirement already up-to-date: warlock>=1.0.1,<2 in /usr/lib/python2.7/site-packages (from python-glanceclient>=0.13.1->tempest==2.dev807.gfcd64c0)\nGetting page http://pypi.openstack.org/openstack/oslo.utils/\nCould not fetch URL http://pypi.opens...  \nView on paste.openstack.org Preview by Yahoo  \n? \n\nthanks in advance!\n\n\n________________________________\n From: daya kamath <daya_k at yahoo.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>; Openstack-infra <openstack-infra at lists.openstack.org> \nSent: Wednesday, August 6, 2014 9:18 AM\nSubject: [infra][Neutron] tempest requirements errors while fetching oslo.i18n>=0.1.0\n \n\n\nall,\ni\'m seeing continuous errors when the gate script starts running tempest tests for neutron. it tries to download some packages even though these are visible in pip list output, and fails when trying to find a source for oslo.i18n >= 0.1.0. this is not happening one-shot, continuously, so i dont think there\'s intermittent connectivity issues.\ninterestingly, when i ran the same job on sandbox, it worked fine.\n\nany pointers?\n\nhere\'s the error log -?Paste #90811 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests\n22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve\n22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest\n22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on paste.openstack.org Preview by Yahoo  \n? \n?\n? \n? ? ? ? ? \nPaste #90811 | LodgeIt!\nRunning tempest sdnve tests 22:40:33 ibmsdnve create: /opt/stack/new/tempest/.tox/ibmsdnve 22:40:35 ibmsdnve develop-inst: /opt/stack/new/tempest 22:40:54 ERROR: invocation failed, logfile: /opt/stack/new/tempest/.tox/ibmsdnve/log/ibmsdnve-1.lo...  \nView on?paste.openstack.org Preview by Yahoo  \n? \nhere\'s my pip list output -?Paste #90812 | LodgeIt!\n? \n? ? ? ? ? \nPaste #90812 | LodgeIt!\nalembic (0.6.5) amqp (1.3.3) anyjson (0.3.3) argparse (1.2.1) astroid (1.1.0) Babel (1.3) backports.ssl-match-hostname (3.4.0.2) BeautifulSoup (3.2.1) beautifulsoup4 (4.3.2) boto (2.27.0) bzr (2.6.0) ceilometer (2014.2.dev50.gb6a5978, /opt/stack/new/ceilometer)...  \nView on?paste.openstack.org Preview by Yahoo  \n? \n\nTIA for your help!?\nalso, sorry if you get multiple copies of the message, i got a membership disabled message when i sent it out earlier, and trying again..\n\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140817/d970d354/attachment-0001.html>\n\n','<1407296887.12183.YahooMailNeo@web163606.mail.gq1.yahoo.com>',NULL),('<1408310570-sup-753@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-17 14:32:56',-25200,'2014-08-17 21:32:56',NULL,'[openstack-dev] [all] The future of the integrated release','Here\'s why folk are questioning Ceilometer:\n\nNova is a set of tools to abstract virtualization implementations.\nNeutron is a set of tools to abstract SDN/NFV implementations.\nCinder is a set of tools to abstract block-device implementations.\nTrove is a set of tools to simplify consumption of existing databases.\nSahara is a set of tools to simplify Hadoop consumption.\nSwift is a feature-complete implementation of object storage, none of\nwhich existed when it was started.\nKeystone supports all of the above, unifying their auth.\nHorizon supports all of the above, unifying their GUI.\n\nCeilometer is a complete implementation of data collection and alerting.\nThere is no shortage of implementations that exist already.\n\nI\'m also core on two projects that are getting some push back these\ndays:\n\nHeat is a complete implementation of orchestration. There are at least a\nfew of these already in existence, though not as many as their are data\ncollection and alerting systems.\n\nTripleO is an attempt to deploy OpenStack using tools that OpenStack\nprovides. There are already quite a few other tools that _can_ deploy\nOpenStack, so it stands to reason that people will question why we\ndon\'t just use those. It is my hope we\'ll push more into the \"unifying\nthe implementations\" space and withdraw a bit from the \"implementing\nstuff\" space.\n\nSo, you see, people are happy to unify around a single abstraction, but\nnot so much around a brand new implementation of things that already\nexist.\n\nExcerpts from Nadya Privalova\'s message of 2014-08-17 11:11:34 -0700:\n> Hello all,\n> \n> As a Ceilometer\'s core, I\'d like to add my 0.02$.\n> \n> During previous discussions it was mentioned several projects which were\n> started or continue to be developed after Ceilometer became integrated. The\n> main question I\'m thinking of is why it was impossible to contribute into\n> existing integrated project? Is it because of Ceilometer\'s architecture,\n> the team or there are some other (maybe political) reasons? I think it\'s a\n> very sad situation when we have 3-4 Ceilometer-like projects from different\n> companies instead of the only one that satisfies everybody. (We don\'t see\n> it in other projects. Though, maybe there are several Novas os Neutrons on\n> StackForge and I don\'t know about it...)\n> Of course, sometimes it\'s much easier to start the project from scratch.\n> But there should be strong reasons for doing this if we are talking about\n> integrated project.\n> IMHO the idea, the role is the most important thing when we are talking\n> about integrated project. And if Ceilometer\'s role is really needed (and I\n> think it is) then we should improve existing implementation, \"merge\" all\n> needs into the one project and the result will be still Ceilometer.\n> \n> Thanks,\n> Nadya\n> \n> On Fri, Aug 15, 2014 at 12:41 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> \n> >\n> >\n> >\n> > On Wed, Aug 13, 2014 at 12:24 PM, Doug Hellmann <doug at doughellmann.com>\n> > wrote:\n> >\n> >>\n> >> On Aug 13, 2014, at 3:05 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> >>\n> >> >\n> >> >>> At the end of the day, that\'s probably going to mean saying No to more\n> >> >>> things. Everytime I turn around everyone wants the TC to say No to\n> >> >>> things, just not to their particular thing. :) Which is human nature.\n> >> >>> But I think if we don\'t start saying No to more things we\'re going to\n> >> >>> end up with a pile of mud that no one is happy with.\n> >> >>\n> >> >> That we\'re being so abstract about all of this is frustrating. I get\n> >> >> that no-one wants to start a flamewar, but can someone be concrete\n> >> about\n> >> >> what they feel we should say \'no\' to but are likely to say \'yes\' to?\n> >> >>\n> >> >>\n> >> >> I\'ll bite, but please note this is a strawman.\n> >> >>\n> >> >> No:\n> >> >> * Accepting any more projects into incubation until we are comfortable\n> >> with\n> >> >> the state of things again\n> >> >> * Marconi\n> >> >> * Ceilometer\n> >> >\n> >> > Well -1 to that, obviously, from me.\n> >> >\n> >> > Ceilometer is on track to fully execute on the gap analysis coverage\n> >> > plan agreed with the TC at the outset of this cycle, and has an active\n> >> > plan in progress to address architectural debt.\n> >>\n> >> Yes, there seems to be an attitude among several people in the community\n> >> that the Ceilometer team denies that there are issues and refuses to work\n> >> on them. Neither of those things is the case from our perspective.\n> >>\n> >\n> > Totally agree.\n> >\n> >\n> >>\n> >> Can you be more specific about the shortcomings you see in the project\n> >> that aren?t being addressed?\n> >>\n> >\n> >\n> > Once again, this is just a strawman.\n> >\n> > I\'m just not sure OpenStack has \'blessed\' the best solution out there.\n> >\n> >\n> > https://wiki.openstack.org/wiki/Ceilometer/Graduation#Why_we_think_we.27re_ready\n> >\n> > \"\n> >\n> >    - Successfully passed the challenge of being adopted by 3 related\n> >    projects which have agreed to join or use ceilometer:\n> >       - Synaps\n> >       - Healthnmon\n> >       - StackTach\n> >       <https://wiki.openstack.org/w/index.php?title=StackTach&action=edit&redlink=1>\n> >       \"\n> >\n> >\n> > Stacktach seems to still be under active development (\n> > http://git.openstack.org/cgit/stackforge/stacktach/log/), is used by\n> > rackspace in production and from everything I hear is more mature then\n> > ceilometer.\n> >\n> >\n> >>\n> >> >\n> >> >> Divert all cross project efforts from the following projects so we can\n> >> focus\n> >> >> our cross project resources. Once we are in a bitter place we can\n> >> expand our\n> >> >> cross project resources to cover these again. This doesn\'t mean\n> >> removing\n> >> >> anything.\n> >> >> * Sahara\n> >> >> * Trove\n> >> >> * Tripleo\n> >> >\n> >> > You write as if cross-project efforts are both of fixed size and\n> >> > amenable to centralized command & control.\n> >> >\n> >> > Neither of which is actually the case, IMO.\n> >> >\n> >> > Additional cross-project resources can be ponied up by the large\n> >> > contributor companies, and existing cross-project resources are not\n> >> > necessarily divertable on command.\n> >>\n> >\n> > Sure additional cross-project resources can and need to be ponied up, but\n> > I am doubtful that will be enough.\n> >\n> >\n> >>\n> >> What ?cross-project efforts? are we talking about? The liaison program in\n> >> Oslo has been a qualified success so far. Would it make sense to extend\n> >> that to other programs and say that each project needs at least one\n> >> designated QA, Infra, Doc, etc. contact?\n> >>\n> >> Doug\n> >>\n> >> >\n> >> >> Yes:\n> >> >> * All integrated projects that are not listed above\n> >> >\n> >> > And what of the other pending graduation request?\n> >> >\n> >> > Cheers,\n> >> > Eoghan\n> >>\n> >> >\n> >> > _______________________________________________\n> >> > OpenStack-dev mailing list\n> >> > OpenStack-dev at lists.openstack.org\n> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n\n\n','<CAKWrcJca1qPX9tCqjB9OjkXoNntQwp9PAqgeTV8MDVKYtG8Q2w@mail.gmail.com>',NULL),('<1408327419.2995.0.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 10:03:39',28800,'2014-08-18 02:03:39',NULL,'[openstack-dev] gettext question about oslo.i18n library','  Yes, I am interested in adding these missing gettext functions to\noslo.i18n library.\n\n  Guess the next step is to create a blueprint for Kilo?\n\nThanks,\n  Peng Wu\n\n\nOn Fri, 2014-08-15 at 16:02 -0400, Doug Hellmann wrote:\n> On Aug 15, 2014, at 3:18 AM, Peng Wu <peng.e.wu at gmail.com> wrote:\n> \n> > Hi,\n> > \n> >  Recently I just read the code of oslo.i18n library,\n> >  The lazy translation idea is great!\n> > \n> >  But I found a question about gettext \"contextual markers\"\n> >  and \"plural form\", such as pgettext and ungettext functions,\n> >  see [3].\n> > \n> >  It seems the two gettext functions are missing in the oslo.i18n\n> > library.\n> >  Is it correct? or will support it?\n> > \n> > Thanks,\n> >  Peng Wu\n> \n> You?re right, those are not present.\n> \n> We apparently haven?t used them anywhere, yet, because they weren?t exposed via the old gettextutils module in the incubator. We should add them. Are you interested in working on a blueprint for Kilo to do that?\n> \n> Doug\n> \n> > \n> > Refer URL:\n> > 1. https://github.com/openstack/oslo.i18n\n> > 2.\n> > http://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html\n> > 3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<6C81D5B5-D32B-4B89-823B-20666E4873EE@doughellmann.com>',NULL),('<1408334229.3928.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 03:56:48',0,'2014-08-18 03:56:48',NULL,'[openstack-dev] [Octavia] Object Model and DB Structure','Oh hello again!\n\nYou know the drill!\n\nOn Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:\n> Hi Brandon,\n> \n> \n> Responses in-line:\n> \n> On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Comments in-line\n>         \n>         On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:\n>         > Hi folks,\n>         >\n>         >\n>         > I\'m OK with going with no shareable child entities\n>         (Listeners, Pools,\n>         > Members, TLS-related objects, L7-related objects, etc.).\n>         This will\n>         > simplify a lot of things (like status reporting), and we can\n>         probably\n>         > safely work under the assumption that any user who has a use\n>         case in\n>         > which a shared entity is useful is probably also technically\n>         savvy\n>         > enough to not only be able to manage consistency problems\n>         themselves,\n>         > but is also likely to want to have that level of control.\n>         >\n>         >\n>         > Also, an haproxy instance should map to a single listener.\n>         This makes\n>         > management of the configuration template simpler and the\n>         behavior of a\n>         > single haproxy instance more predictable. Also, when it\n>         comes to\n>         > configuration updates (as will happen, say, when a new\n>         member gets\n>         > added to a pool), it\'s less risky and error prone to restart\n>         the\n>         > haproxy instance for just the affected listener, and not for\n>         all\n>         > listeners on the Octavia VM. The only down-sides I see are\n>         that we\n>         > consume slightly more memory, we don\'t have the advantage of\n>         a shared\n>         > SSL session cache (probably doesn\'t matter for 99.99% of\n>         sites using\n>         > TLS anyway), and certain types of persistence wouldn\'t carry\n>         over\n>         > between different listeners if they\'re implemented poorly by\n>         the\n>         > user. :/  (In other words, negligible down-sides to this.)\n>         \n>         \n>         This is fine by me for now, but I think this might be\n>         something we can\n>         revisit later after we have the advantage of hindsight.  Maybe\n>         a\n>         configurable option.\n> \n> \n> Sounds good, as long as we agree on a path forward. In the mean time,\n> is there anything I\'m missing which would be a significant advantage\n> of having multiple Listeners configured in a single haproxy instance?\n> (Or rather, where a single haproxy instance maps to a loadbalancer\n> object?)\n\nNo particular reason as of now.  Just feel like that could be something\nthat could hinder a particular feature or even performance in the\nfuture.  It\'s not rooted in any fact or past experience.\n\n>  \n>         I have no problem with this. However, one thing I often do\n>         think about\n>         is that it\'s not really ever going to be load balancing\n>         anything with\n>         just a load balancer and listener.  It has to have a pool and\n>         members as\n>         well.  So having ACTIVE on the load balancer and listener, and\n>         still not\n>         really load balancing anything is a bit odd.  Which is why I\'m\n>         in favor\n>         of only doing creates by specifying the entire tree in one\n>         call\n>         (loadbalancer->listeners->pool->members).  Feel free to\n>         disagree with me\n>         on this because I know this not something everyone likes.  I\'m\n>         sure I am\n>         forgetting something that makes this a hard thing to do.  But\n>         if this\n>         were the case, then I think only having the provisioning\n>         status on the\n>         load balancer makes sense again.  The reason I am advocating\n>         for the\n>         provisioning status on the load balancer is because it still\n>         simpler,\n>         and only one place to look to see if everything were\n>         successful or if\n>         there was an issue.\n> \n> \n> Actually, there is one case where it makes sense to have an ACTIVE\n> Listener when that listener has no pools or members:  Probably the 2nd\n> or 3rd most common type of \"load balancing\" service we deploy is just\n> an HTTP listener on port 80 that redirects all requests to the HTTPS\n> listener on port 443. While this can be done using a (small) pool of\n> back-end servers responding to the port 80 requests, there\'s really no\n> point in not having the haproxy instance do this redirect directly for\n> sites that want all access to happen over SSL. (For users that want\n> them we also insert HSTS headers when we do this... but I digress. ;)\n> )\n> \n> \n> Anyway, my point is that there is a common production use case that\n> calls for a listener with no pools or members.\n\nYeah we do HTTPS redirect too (or HTTP redirect as I would call it...I\ncould digress myself).  I don\'t think its common for our customers, but\nit obviously should still be supported.  Also, wouldn\'t that break the\nonly one listener per instance rule? Also also, I think haproxy 1.5 has\n\"redirect scheme\" option that might do away with the extra frontend\nsection.  I could be wrong though.\n\n>  \n>         \n>         Again though, what you\'ve proposed I am entirely fine with\n>         because it\n>         works great with having to create a load balancer first, then\n>         listener,\n>         and so forth.  It would also work fine with a single create\n>         call as\n>         well.\n> \n> \n> We should probably create more formal API documentation, eh. :)  (Let\n> me pull up my drafts from 5 months ago...)\n\nWhat I\'m hoping the API will look like will be different than those\ndrafts, similar though.  So they\'re probably a good starting point.\nThen again the neutron lbaas api google doc is probably a good one too.\n\n>  \n>         >\n>         > I don\'t think that these kinds of status are useful /\n>         appropriate for\n>         > Pool, Member, Healthmonitor, TLS certificate id, or L7\n>         Policy / Rule\n>         > objects, as ultimately this boils down to configuration\n>         lines in an\n>         > haproxy config somewhere, and really the Listener status is\n>         what will\n>         > be affected when things are changed.\n>         \n>         \n>         Total agreement on this.\n>         >\n>         > I\'m basically in agreement with Brandon on his points with\n>         operational\n>         > status, though I would like to see these broken out into\n>         their various\n>         > meanings for the different object types. I also think some\n>         object\n>         > types won\'t need an operational status (eg. L7 Policies,\n>         > healthmonitors, etc.) since these essentially boil down to\n>         lines in an\n>         > haproxy configuration file.\n>         \n>         \n>         Yeah I was thinking could be more descriptive status names for\n>         the load\n>         balancer and listener statuses.  I was thinking load balancer\n>         could have\n>         PENDING_VIP_CREATE/UPDATE/DELETE, but then that\'d be painting\n>         us into a\n>         corner.  More general is needed.  With that in mind, the\n>         generic\n>         PENDING_CREATE/UPDATE/DELETE is adequate enough as long as the\n>         docs\n>         explain what they mean for each object clearly.\n> \n> \n> Right. Let\'s get this documented. :) Or rather-- let\'s get drafts of\n> this documentation going in gerrit so people can give specific\n> feedback.  (I\'m happy to work on this, so long as I\'m not a blocker on\n> anything else-- I want to make sure anyone who wants to put time into\n> the Octavia project knows how they can be useful, eh. It\'s a major pet\n> peeve of mine to find out after the fact that somebody was waiting on\n> something for me, and that this was a blocker for them being\n> productive.)\n\nI like your documentation skills and attention to detail.  If you don\'t\nmind doing it, unless someone else wants something to do.\n\n>  \n> Stephen\n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZpPUxZPLphh9Vpt-hjK+Kt7A7m2AOhtL_L5x8OZPYCS9g@mail.gmail.com>',NULL),('<1408338005.1958.8.camel@Nokia-N900-42-11>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-18 13:00:05',28800,'2014-08-18 05:00:05',NULL,'[Openstack] How to mirror ubuntu cloud archive?','On Mon Aug 18 2014 12:24:03 PM HKT, gustavo panizzo (gfa) <gfa at zumbi.com.ar> wrote:\n\n> apt-mirror should be able to mirror it\n\nthere\'s that, reprepro, aptly, and more...\n\nThomas\n\n> \n> On 08/18/2014 01:05 AM, sylecn wrote:\n> > Hi stackers,\n> > \n> > The ubuntu cloud archive hosts latest openstack packages for ubuntu LTS\n> > releases.\n> > \n> > https://wiki.ubuntu.com/ServerTeam/CloudArchive\n> > \n> > Is there a rsync interface to mirror it?\n> > \n> > rsync rsync://ubuntu-cloud.archive.canonical.com/\n> > <http://ubuntu-cloud.archive.canonical.com/>\n> > returns no modules.\n> > \n> > -- \n> > /YY Inc. is hiring/ openstack and python developers. Interested? Check\n> > http://soa.game.yy.com/jobs.html\n> > \n> > --\n> > Thanks,\n> > Yuanle\n> > \n> > \n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to \n> >? ? ?  : openstack at lists.openstack.org Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > \n> \n> -- \n> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333\n> \n> \n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to? ?  \n>?  : openstack at lists.openstack.org Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<53F17FE3.10803@zumbi.com.ar>',NULL),('<1408341129.6626.13.camel@ruth.wgtn.cat-it.co.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 17:52:09',43200,'2014-08-18 05:52:09',NULL,'[openstack-dev] Time to Samba! :-)','On Sun, 2014-08-17 at 13:05 +0400, Ruslan Kamaldinov wrote:\n> On Sun, Aug 17, 2014 at 4:16 AM, Adam Lawson <alawson at aqorn.com> wrote:\n> > Doesn\'t Murano address this already?\n> \n> Please note that Murano is no longer a windows-as-a-service or\n> smth-as-a-serivce. Murano is an application catalog [1]. But you\'re\n> absolutely right, this is a perfect use case for Murano - application\n> developer can describe those applications and publish them in catalog,\n> which will enable cloud users to combine those apps together. LDAP,\n> Kerberos, Samba, ActiveDirectory - are applications in terms of\n> Murano.\n> \n> [1] https://wiki.openstack.org/wiki/Murano\n\nG\'Day,\n\nIndeed, I think Murano may well be the natural home of Samba deployed as\nan AD DC, inside a tenant.  I reached out to the Murano team a few\nmonths ago, but haven\'t have any time to put into development of a Samba\nAD DC application yet.  \n\nI work for Catalyst in NZ, and lurk here and quite close to our internal\nOpenStack team.  I think OpenStack is a great opportunity for Samba and\nSamba is a great fit for OpenStack, particularly when we look at the\nemerging market of Desktop as Service, things like hosted Exchange (or\nmore particularly OpenChange), and single-sign-on from the\nWindows-dominated enterprise.\n\nWhat I would like to do is to work closely with someone already more\nfamiliar with the OpenStack world, and provide my expertise and\nassistance to that existing effort. \n\nI also think that Samba does justify being beyond just being an\napplication in Murano, because for the best results, Samba should be\nused, but not administered directly.  Instead, what would bring the best\nout of Samba is deployment like in Trove, where the Tenant does not get\nrights to directly touch the instance - operation of the AD DC should be\nby OpenStack, not the end-user.\n\nFinally, yes Samba certainly plays a role in Manila, and while currently\nvery well hidden, I think that some really great functionality can be\nexposed via the \'generic\' driver that would be far from generic.\nImagine if that driver \'just worked\' with exposed snapshots via the\nwindows \'previous versions\' tab, for example.\n\nOr, imagine if we used the OpenStack machine credentials to securely get\na Kerberos ticket for access to a big multi-tenant file share?\n\nAs I mention, I do lurk here, but also feel free to contact me directly\nor the Samba lists if you are implementing Samba as an OpenStack\nservice, and you think I can help, or think I\'ve missed some\ndiscussion.  \n\nThanks,\n\nAndrew Bartlett\n\n-- \nAndrew Bartlett\nhttp://samba.org/~abartlet/\nAuthentication Developer, Samba Team  http://samba.org\nSamba Developer, Catalyst IT          http://catalyst.net.nz/services/samba\n\n\n\n\n\n\n','<CAPW-O+HhhCP2QxR8Kztn4wH1unqJQ0GKT18b7ug+5PTCqW5XMg@mail.gmail.com>',NULL),('<1408341275.6626.16.camel@ruth.wgtn.cat-it.co.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 17:54:35',43200,'2014-08-18 05:54:35',NULL,'[openstack-dev] Time to Samba! :-)','On Sun, 2014-08-17 at 13:00 +0400, Stan Lagun wrote:\n> This can be addressed by Murano only if its deployed to the cloud (on\n> VM belonging to some tenant). Having it on OpenStack service layer\n> integrated with major OpenStack services sounds very promising. The\n> problem I see is significant overlap with Keystone, especially in\n> Kerberos and LDAP parts\n\nI do agree that Samba belongs, for many use cases, in the OpenStack\nservice layer.  I\'m very interested to understand how you see it\noverlapping with Keystone - both for my understanding and for possible\nintegration or assistance.  \n\nSamba\'s user database I think mostly pertains to the users in a tenant\n(even if not managed by that tenant), wheras I understand Keystone is\ntypically the VMs and their administrators.  For those there is some\noverlap, but not one I think should cause us a major issue, but I\'m very\ninterested to learn more.\n\nThanks,\n\nAndrew Bartlett\n\n-- \nAndrew Bartlett\nhttp://samba.org/~abartlet/\nAuthentication Developer, Samba Team  http://samba.org\nSamba Developer, Catalyst IT          http://catalyst.net.nz/services/samba\n\n\n\n\n\n\n','<CAOCoZibWmgu==ALEHMif5k=rPBSKV3_N_ahwg6+inYRw=dOhVw@mail.gmail.com>',NULL),('<1408342461103.11827@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-18 06:07:56',0,'2014-08-18 06:07:56',NULL,'[Openstack] Keystone \"Too many connections\" Error on Icehouse','\nHi,\n\nI suppose the issue is because all the openstack components are trying to connect to a single Mysql.\nPlease try updating value of \"max_connections\" in /etc/mysql/my.cnf file, and restart the mysql service.\n\n\n-HTH,\nSushma Korati\nsushma_korati at persistent.co.in\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\n\n\n\n________________________________________\nFrom: ZHOU TAO A <tao.a.zhou at alcatel-lucent.com>\nSent: Friday, August 15, 2014 1:50 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Keystone \"Too many connections\" Error on Icehouse\n\nHi all,\n\nHas anyone met the \'too many connections\' error on IceHouse.\nIn my case, it only happen to cinder and heat; nova is fine. And after\nrestarting keystone, everything works fine. But after some while, it\nwill happen again.\n\nI have another deployment which also has the same issue.\n\nheat stack-delete ieccf301-stg\nERROR: Remote error: OperationalError (OperationalError) (1040, \'Too\nmany connections\') None None\n\n\nheat-api.log:\n\n[u\'Traceback (most recent call last):\\n\', u\'  File\n\"/usr/lib/python2.6/site-packages/heat/openstack/common/rpc/amqp.py\",\nline 462, in _process_data\\n    **args)\\n\', u\'  File\n\"/usr/lib/python2.6/site-packages/heat/openstack/common/rpc/dispatcher.py\",\nline 172, in dispatch\\n    result = getattr(proxyobj, method)(ctxt,\n**kwargs)\\n\', u\'  File\n\"/usr/lib/python2.6/site-packages/heat/engine/service.py\", line 63, in\nwrapped\\n    return func(self, ctx, *args, **kwargs)\\n\', u\'  File\n\"/usr/lib/python2.6/site-packages/heat/engine/service.py\", line 407, in\nlist_stacks\\n    sort_dir, filters, tenant_safe) or []\\n\', u\' File\n\"/usr/lib/python2.6/site-packages/heat/db/api.py\", line 125, in\nstack_get_all\\n    marker, sort_dir, filters, tenant_safe)\\n\', u\' File\n\"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py\", line 346,\nin stack_get_all\\n    marker, sort_dir, filters).all()\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py\", line 2241,\nin all\\n    return list(self)\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py\", line 2353,\nin __iter__\\n    return self._execute_and_instances(context)\\n\', u\'\nFile \"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py\", line\n2366, in _execute_and_instances\\n    close_with_result=True)\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/query.py\", line 2357,\nin _connection_from_session\\n    **kw)\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/session.py\", line\n799, in connection\\n    close_with_result=close_with_result)\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/orm/session.py\", line\n805, in _connection_for_bind\\n    return\nengine.contextual_connect(**kwargs)\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/base.py\", line\n1661, in contextual_connect\\n    self.pool.connect(),\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 272, in\nconnect\\n    return _ConnectionFairy(self).checkout()\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 431, in\n__init__\\n    rec = self._connection_record = pool._do_get()\\n\', u\'\nFile \"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 772,\nin _do_get\\n    return self._create_connection()\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 225, in\n_create_connection\\n    return _ConnectionRecord(self)\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 318, in\n__init__\\n    self.connection = self.__connect()\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py\", line 379, in\n__connect\\n    connection = self.__pool._creator()\\n\', u\' File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/strategies.py\",\nline 80, in connect\\n    return dialect.connect(*cargs, **cparams)\\n\',\nu\'  File\n\"/usr/lib64/python2.6/site-packages/sqlalchemy/engine/default.py\", line\n283, in connect\\n    return self.dbapi.connect(*cargs, **cparams)\\n\',\nu\'  File \"/usr/lib64/python2.6/site-packages/MySQLdb/__init__.py\", line\n81, in Connect\\n    return Connection(*args, **kwargs)\\n\', u\'  File\n\"/usr/lib64/python2.6/site-packages/MySQLdb/connections.py\", line 187,\nin __init__\\n    super(Connection, self).__init__(*args, **kwargs2)\\n\',\nu\"OperationalError: (OperationalError) (1040, \'Too many connections\')\nNone None\\n\"\n\n\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n\n\n','<53EDC2C0.1050100@alcatel-lucent.com>',NULL),('<1408344792.5283.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-17 23:53:12',-25200,'2014-08-18 06:53:12',NULL,'[openstack-dev] [OpenStack-Infra] [infra][Neutron] tempest\n	requirements errors while fetching oslo.i18n>=0.1.0','thanks jeremy, that?works!?\n\ni updated?/root/config/modules/openstack_project/files/slave_scripts/select-mirror.sh to use the pypi.python.org mirror.\n\nnot sure why, but the pypi.openstack.org/simple mirror was not getting accessed when triggered through zuul, but it was getting accessed when i did a manual run. (however, i realized openstack-infra does not get updated as part of the gate jobs, so mine is almost 2 months old, and this script no longer exists on infra.)\n\nthanks!\n\n\n\n\n________________________________\n From: Jeremy Stanley <fungi at yuggoth.org>\nTo: daya kamath <daya_k at yahoo.com> \nCc: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>; Openstack-infra <openstack-infra at lists.openstack.org> \nSent: Monday, August 18, 2014 5:47 AM\nSubject: Re: [OpenStack-Infra] [infra][Neutron] tempest requirements errors while fetching oslo.i18n>=0.1.0\n \n\nOn 2014-08-17 13:11:41 -0700 (-0700), daya kamath wrote:\n[...]\n> Getting page http://pypi.openstack.org/openstack/oslo.utils/ Could\n> not fetch URL\n[...]\n\nThat mirror is abandoned and http://pypi.openstack.org/simple/ is\nthe one we\'re maintaining for our jobs now. However, there\'s no\nreason to be using our mirror for YOUR systems. If you\'re not\nrunning a PyPI mirror of your own, you should just use\npypi.python.org instead.\n-- \nJeremy Stanley\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140817/a86fddf9/attachment.html>\n\n','<20140818001724.GS1251@yuggoth.org>',NULL),('<1408344792.5283.YahooMailNeo@web163605.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-17 23:53:12',-25200,'2014-08-18 06:53:12',NULL,'[OpenStack-Infra] [infra][Neutron] tempest requirements errors\n	while fetching oslo.i18n>=0.1.0','thanks jeremy, that?works!?\n\ni updated?/root/config/modules/openstack_project/files/slave_scripts/select-mirror.sh to use the pypi.python.org mirror.\n\nnot sure why, but the pypi.openstack.org/simple mirror was not getting accessed when triggered through zuul, but it was getting accessed when i did a manual run. (however, i realized openstack-infra does not get updated as part of the gate jobs, so mine is almost 2 months old, and this script no longer exists on infra.)\n\nthanks!\n\n\n\n\n________________________________\n From: Jeremy Stanley <fungi at yuggoth.org>\nTo: daya kamath <daya_k at yahoo.com> \nCc: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>; Openstack-infra <openstack-infra at lists.openstack.org> \nSent: Monday, August 18, 2014 5:47 AM\nSubject: Re: [OpenStack-Infra] [infra][Neutron] tempest requirements errors while fetching oslo.i18n>=0.1.0\n \n\nOn 2014-08-17 13:11:41 -0700 (-0700), daya kamath wrote:\n[...]\n> Getting page http://pypi.openstack.org/openstack/oslo.utils/ Could\n> not fetch URL\n[...]\n\nThat mirror is abandoned and http://pypi.openstack.org/simple/ is\nthe one we\'re maintaining for our jobs now. However, there\'s no\nreason to be using our mirror for YOUR systems. If you\'re not\nrunning a PyPI mirror of your own, you should just use\npypi.python.org instead.\n-- \nJeremy Stanley\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140817/a86fddf9/attachment.html>\n\n','<20140818001724.GS1251@yuggoth.org>',NULL),('<1408345466.4188.6.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-18 09:04:26',7200,'2014-08-18 07:04:26',NULL,'[Openstack-operators] I have finally created an instance,\n and it works! However, there is no ethernet card','Assuming you\'re running a libvirt based hypervisor (e.g. kvm). Could you\nplease dump the libvirt xml of your instance?\n\nYou can get it this way\n\nvirsh list --all\n--> shows a list of all virtual servers running on your hypervisor\n\nvirsh dumpxml <vm-id>\n--> dumps the xml of your vm, addressed by the id (first column). Id\ndoes not correlate with UUID!!!!! So if you\'re not sure which list entry\nbelongs to your instance just stop all other via openstack to have only\none running.\n\nPS: on some systems you have to sudo when using virsh.\n\n\nThere should be a subtag of devices called <interface type=\'bridge\'> or\n\'network\' or somehting like that representing your eth interface\n\n\nAndreas\n\n\nOn Fri, 2014-08-15 at 11:43 -0700, Jeff Silverman wrote:\n> I have been surfing the internet, and one of the ideas that comes to\n> mind is modifying the /etc/neutron/agent.ini file on the compute\n> nodes.  In the agent.ini file, there is a comment near the top that is\n> almost helpful:\n> \n> \n> # L3 requires that an interface driver be set. Choose the one that\n> best\n> # matches your plugin.\n> \n> \n> The only plug I know about is ml2.  I have no idea if that is right\n> for me or not.  And I have no idea to choose the interface drive that\n> best matches my plugin.\n> \n> \n> Thank you\n> \n> \n> \n> \n> Jeff\n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> On Fri, Aug 15, 2014 at 10:26 AM, Jeff Silverman <jeff at sweetlabs.com>\n> wrote:\n>         By \"defined a network space for your instances\", does that\n>         mean going through the process as described\n>         in http://docs.openstack.org/icehouse/install-guide/install/yum/content/neutron-ml2-compute-node.html?\n>         \n>         \n>         I got part way through that when I realized that the procedure\n>         was going to bridge packets through neutron.  That\'s not what\n>         I want.  I want the packets to go directly to the physical\n>         router.  For example, I have two tenants, with IP addresses\n>         10.50.15.80/24 and 10.50.18.15.90/24.and the router is at\n>         10.50.15.1.  There is a nice picture of what I am trying to do\n>         at http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#nova_network_traffic_in_cloud .  But if the hypervisor doesn\'t present a virtual device to the guests, then nothing else is going to happen.  The network troubleshooting guide http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#nova_network_traffic_in_cloud does not explain what to do if the virtual NIC is missing.\n>         \n>         \n>         \n>         \n>         Thank you\n>         \n>         \n>         Jeff\n>         \n>         \n>         \n>         \n>         On Fri, Aug 15, 2014 at 9:38 AM, Abel Lopez\n>         <alopgeek at gmail.com> wrote:\n>                 Curious if you?ve defined a network space for your\n>                 instances. If you?re using the traditional\n>                 flat_network, this is known as the ?fixed_address?\n>                 space.\n>                 If you?re using neutron, you would need to create a\n>                 network and a subnet (and router with gateway, etc).\n>                 You?d then assign the instance to a network at launch\n>                 time.\n>                 \n>                 \n>                 \n>                 On Aug 15, 2014, at 9:17 AM, Jeff Silverman\n>                 <jeff at sweetlabs.com> wrote:\n>                 \n>                 > <ip_a.png>\n>                 > \n>                 > ?\n>                 > \n>                 > For those of you that can\'t see pictures:\n>                 > $ sudo ip a\n>                 > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc\n>                 > noqueue\n>                 >     link/loopback 00:00:00:00:00:00 brd\n>                 > 00:00:00:00:00:00\n>                 >     inet 127.0.0.1/8 scope host lo\n>                 >     inet6 ::1/128 scope host\n>                 >         valid_lft forever preferred_1ft forever\n>                 > \n>                 > \n>                 > I suspect that the issue is that the hypervisor is\n>                 > not presenting a virtual ethernet card.\n>                 > \n>                 > \n>                 > Thank you\n>                 > \n>                 > \n>                 > \n>                 > \n>                 > Jeff\n>                 > \n>                 > \n>                 > \n>                 > \n>                 > On Thu, Aug 14, 2014 at 6:57 PM, Nhan Cao\n>                 > <nhanct92 at gmail.com> wrote:\n>                 >         can you show output of command:\n>                 >         ip a\n>                 >         \n>                 >         \n>                 >         \n>                 >         \n>                 >         \n>                 >         \n>                 >         2014-08-15 7:41 GMT+07:00 Jeff Silverman\n>                 >         <jeff at sweetlabs.com>:\n>                 >                 People,\n>                 >                 \n>                 >                 \n>                 >                 I have brought up an instance, and I\n>                 >                 can connect to it using my browser!\n>                 >                  I am so pleased.\n>                 >                 \n>                 >                 \n>                 >                 However, my instance doesn\'t have an\n>                 >                 ethernet device, only a loopback\n>                 >                 device.   My management wants me to\n>                 >                 use a provider network, which I\n>                 >                 understand to mean that my instances\n>                 >                 will have IP addresses in the same\n>                 >                 space as the controller, block\n>                 >                 storage, and compute node\n>                 >                 administrative addresses.  However,\n>                 >                 I think that discussing addressing\n>                 >                 is premature until I have a working\n>                 >                 virtual ethernet card.\n>                 >                 \n>                 >                 \n>                 >                 I am reading\n>                 >                 through http://docs.openstack.org/icehouse/install-guide/install/yum/content/neutron-ml2-compute-node.html and I think that the ML2 plugin is what I need.  However, I think I do not want a network type of GRE, because that encapsulates the packets and I don\'t have anything to un-encapsulate them.\n>                 >                 \n>                 >                 \n>                 >                 Thank you\n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 Jeff\n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 -- \n>                 >                 Jeff Silverman\n>                 >                 Systems Engineer\n>                 >                 (253) 459-2318 (c)\n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 \n>                 >                 _______________________________________________\n>                 >                 OpenStack-operators mailing list\n>                 >                 OpenStack-operators at lists.openstack.org\n>                 >                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>                 >                 \n>                 >         \n>                 >         \n>                 > \n>                 > \n>                 > \n>                 > \n>                 > -- \n>                 > Jeff Silverman\n>                 > Systems Engineer\n>                 > (253) 459-2318 (c)\n>                 > \n>                 > \n>                 > _______________________________________________\n>                 > OpenStack-operators mailing list\n>                 > OpenStack-operators at lists.openstack.org\n>                 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>                 > \n>                 \n>                 \n>         \n>         \n>         \n>         \n>         -- \n>         Jeff Silverman\n>         Systems Engineer\n>         (253) 459-2318 (c)\n>         \n>         \n> \n> \n> \n> \n> -- \n> Jeff Silverman\n> Systems Engineer\n> (253) 459-2318 (c)\n> \n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n\n','<CAObtcxXiv-mgM--i=7H4kSTN2AOZ4ENuh404Y-k8EUsrMcPRAg@mail.gmail.com>',NULL),('<1408371016.15785.20.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 10:10:16',-14400,'2014-08-18 14:10:16',NULL,'[openstack-dev] [all] The future of the integrated release','On Mon, 2014-08-18 at 14:23 +0200, Thierry Carrez wrote:\n> Clint Byrum wrote:\n> > Here\'s why folk are questioning Ceilometer:\n> > \n> > Nova is a set of tools to abstract virtualization implementations.\n> > Neutron is a set of tools to abstract SDN/NFV implementations.\n> > Cinder is a set of tools to abstract block-device implementations.\n> > Trove is a set of tools to simplify consumption of existing databases.\n> > Sahara is a set of tools to simplify Hadoop consumption.\n> > Swift is a feature-complete implementation of object storage, none of\n> > which existed when it was started.\n> > Keystone supports all of the above, unifying their auth.\n> > Horizon supports all of the above, unifying their GUI.\n> > \n> > Ceilometer is a complete implementation of data collection and alerting.\n> > There is no shortage of implementations that exist already.\n> > \n> > I\'m also core on two projects that are getting some push back these\n> > days:\n> > \n> > Heat is a complete implementation of orchestration. There are at least a\n> > few of these already in existence, though not as many as their are data\n> > collection and alerting systems.\n> > \n> > TripleO is an attempt to deploy OpenStack using tools that OpenStack\n> > provides. There are already quite a few other tools that _can_ deploy\n> > OpenStack, so it stands to reason that people will question why we\n> > don\'t just use those. It is my hope we\'ll push more into the \"unifying\n> > the implementations\" space and withdraw a bit from the \"implementing\n> > stuff\" space.\n> > \n> > So, you see, people are happy to unify around a single abstraction, but\n> > not so much around a brand new implementation of things that already\n> > exist.\n> \n> Right, most projects focus on providing abstraction above\n> implementations, and that abstraction is where the real \"domain\n> expertise\" of OpenStack should be (because no one else is going to do it\n> for us). Every time we reinvent something, we are at larger risk because\n> we are out of our common specialty, and we just may not be as good as\n> the domain specialists. That doesn\'t mean we should never reinvent\n> something, but we need to be damn sure it\'s a good idea before we do.\n> It\'s sometimes less fun to piggyback on existing implementations, but if\n> they exist that\'s probably what we should do.\n\nIt\'s certainly a valid angle to evaluate projects on, but it\'s also easy\nto be overly reductive about it - e.g. that rather than \"re-implement\"\nvirtualization management, Nova should just be a thin abstraction over\nvSphere, XenServer and oVirt.\n\nTo take that example, I don\'t think we as a project should be afraid of\nhaving such discussions but it wouldn\'t be productive to frame that\nconversation as \"the sky is falling, Nova re-implements the wheel, we\nshould de-integrate it\".\n\n> While Ceilometer is far from alone in that space, what sets it apart is\n> that even after it was blessed by the TC as \"the one we should all\n> converge on\", we keep on seeing competing implementations for some (if\n> not all) of its scope. Convergence did not happen, and without\n> convergence we struggle in adoption. We need to understand why, and if\n> this is fixable.\n\n\"Convergence did not happen\" is a little unfair. It\'s certainly a busy\nspace, and things like Monasca and InfluxDB are new developments. I\'m\nimpressed at how hard the Ceilometer team works to embrace such\ndevelopments and patiently talks through possibilities for convergence.\nThis attitude is something we should be applauding in an integrated\nproject.\n\nMark.\n\n\n\n','<53F1F037.2020406@openstack.org>',NULL),('<1408377144.4188.22.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-18 17:52:24',7200,'2014-08-18 15:52:24',NULL,'[Openstack] [Openstack-operators] Connect VM network to exists\n VLAN network','Hi Marouen, \n\ninteresting setup that you\'re driving. \nNot sure if I can help you out but let\'s try.\n\nYou\'re able to ping both feets of your router from within your vm -\nthat\'s great!\nBut you cannot ping the routers feets from your hypervisor, right?\n\n--> That makes sense to me. \nIn general you will never be able to ping your instances private ip from\nthe controller or from the hypervisor (this might change with dvr, but\nthat\'s not yet released I guess). Cause neither the hypevisor nor the\ncontroller has a foot into the real tenant network (vlan or whatever). \n\nThe only chance is via the network node, where the virtual router sits.\nOnly there you can enter the tenant network. But this will not work\nwhile just pinging the guest. Let me tell you why:\n\nRouters are realized in network namespaces. So what you have to do is to\nswitch to the network namespace and ping from there\n# ip netns show\n--> shows all network namespaces. There should be one with qrouter.xxxx\n# ip netns exec qrouter-xxxx ip a\n--> list all interfaces in that namespace. Here you should see 2 devices\nwith your routers ip addresses\n# ip netns exec qrouter-xxxx ping <instance-ip>\n--> ping should be possible.\n\n\nThen you also tried out with floating ip and SSH to the floating ip\nworks from a remote host, but not from your openstack nodes, right?\nAnd from your openstack nodes you can also ping the instance, so\nconnection might be there.\nI have no clue what this might be. Somehting with iptables? Floating IPs\nare realized with NAT. Maybe that gives you a hint where to debug...\n\n\nRegards\nAndreas\n\n\n\n\n\nOn Fri, 2014-08-15 at 16:55 +0200, Marouen Mechtri wrote:\n> Another detail that can be useful.\n> I can ping the floating IP of my instance and I can telnet the port\n> 22  from the controller, compute and network nodes\n> \n> \n> Trying 192.168.100.121...\n> Connected to 192.168.100.121.\n> Escape character is \'^]\'.\n> SSH-2.0-dropbear_2012.55\n> \n> \n> but I can not ssh from the controller, compute and network nodes.\n> From an external host I can ssh my instance.\n> \n> \n> \n> \n> Thank you in advance.\n> \n> \n> Best regards,\n> Marouen\n> \n> \n> 2014-08-15 16:17 GMT+02:00 Marouen Mechtri <mechtri.marwen at gmail.com>:\n>         Hi Andreas,\n>         \n>         \n>         I setup OpenStack on multinode (like the picture you\n>         sent http://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png)\n>         and I\'m using Icehouse release with openvswitch and GRE\n>         tunnel.\n>         For more detail about the network configuration:\n>         https://raw.githubusercontent.com/ChaimaGhribi/OpenStack-Icehouse-Installation/master/images/network-topo.jpg\n>         \n>         \n>         \n>         I\'m running the controller and network nodes on VMs (in the\n>         compute node)  and the compute node is my physical host.\n>         \n>         \n>         Evry things are OK and I\'m able to deploy instances and I can\n>         ping from my instance the router gateways (connected to tenant\n>         network and to the extenal nework)\n>         \n>         \n>         The only issue I have I can not ping the tenant address of my\n>         instance and the address of the tenant gateway from the\n>         controller, network and compute nodes.\n>         I can not also ping the controller node from my instance.\n>         \n>         \n>         Could you please help me to solve this issue.\n>         \n>         \n>         Thank you in advance.\n>         Best regards,\n>         Marouen\n>         \n>         \n>         2014-08-15 13:36 GMT+02:00 Andreas Scheuring\n>         <scheuran at linux.vnet.ibm.com>:\n>         \n>                 Hi,\n>                 just that we\'re on the same page. Please have a look\n>                 at this picture:\n>                 http://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png\n>                 \n>                 With the provider network you create a network that\n>                 matches the green\n>                 External & the purple api network (as you have a\n>                 combined controller +\n>                 network node). This is where you already have vlan,\n>                 right?\n>                 \n>                 And on the green data network you try to use gre,\n>                 right?\n>                 \n>                 Or does you controller only have one physical nic for\n>                 all kind of\n>                 traffic?\n>                 \n>                 \n>                 I\'m sorry but I do not yet understand your setup and\n>                 what you\'re trying\n>                 to achieve.\n>                 \n>                 Please keep always the mailing lists on cc, as others\n>                 might also be\n>                 interested.\n>                 \n>                 \n>                 \n>                 Regards,\n>                 Andreas\n>                 \n>                 \n>                 \n>                 On Fri, 2014-08-15 at 14:21 +0700, Nhan Cao wrote:\n>                 > hi,\n>                 > i deploy on multinode with neutron and openvswitch.\n>                 > My Infrastructure has a exists VLAN, now, i\'m using\n>                 GRE type network.\n>                 > I found a article about that\n>                 >\n>                 http://trickycloud.wordpress.com/2013/11/12/setting-up-a-flat-network-with-neutron/\n>                 > Could you give me a advice? i should choose VLAN or\n>                 GRE for best?\n>                 > Thanks\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 > 2014-08-15 13:46 GMT+07:00 Andreas Scheuring\n>                 > <scheuran at linux.vnet.ibm.com>:\n>                 >         Hi Nhan,\n>                 >         I guess more information is required to help\n>                 you out there.\n>                 >\n>                 >         It would be helpful to know which setup\n>                 you\'re using, e.g. a\n>                 >         singlenode\n>                 >         or multinode setup, openvswitch for network\n>                 virtualiation or\n>                 >         something\n>                 >         else? Are you using nova network or neutron\n>                 networking?\n>                 >\n>                 >         If I got it right you created a tenant\n>                 network in openstack\n>                 >         (in your\n>                 >         case vm network). In addition your host\n>                 (hypervisor) has a an\n>                 >         eth\n>                 >         interface into the physical network, right?\n>                 >\n>                 >         You also mentioned that your physical\n>                 network is a vlan\n>                 >         network. Is your\n>                 >         hypervisor aware of this vlan tagging or is\n>                 this done by a\n>                 >         access port\n>                 >         config in your switch?\n>                 >\n>                 >\n>                 >         And what you want to achieve is to connect a\n>                 vm attached to\n>                 >         the\n>                 >         openstack vm network to your physical vlan\n>                 network. Did I get\n>                 >         you right?\n>                 >\n>                 >         Basically you would create a so called\n>                 \"provider network\" that\n>                 >         represents your physical network and connect\n>                 this provider\n>                 >         network via a\n>                 >         virtual router to your vm network.\n>                 >\n>                 >         More information you can find here:\n>                 >\n>                  http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n>                 >\n>                 >\n>                 >         Regards,\n>                 >         Andreas\n>                 >\n>                 >\n>                 >\n>                 >         On Fri, 2014-08-15 at 00:00 +0700, Nhan Cao\n>                 wrote:\n>                 >         > Hi\n>                 >         > I have to network:\n>                 >         > vm network: 10.2.21.0/24\n>                 >         > exist VLAN network: 192.168.1.0/24\n>                 >         > I want to connect from my VM network to\n>                 physic VLAN network.\n>                 >         >\n>                 >         > How i config to connect?\n>                 >         >\n>                 >         >\n>                 >         >\n>                 >         > Thanks :)\n>                 >         >\n>                 >         >\n>                 >\n>                 >         >\n>                 _______________________________________________\n>                 >         > Mailing list:\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 >         > Post to     :\n>                 openstack at lists.openstack.org\n>                 >         > Unsubscribe :\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 >\n>                 >\n>                 >\n>                 >\n>                  _______________________________________________\n>                 \n>                 >         OpenStack-operators mailing list\n>                 >         OpenStack-operators at lists.openstack.org\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>                 >\n>                 >\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 Mailing list:\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 Post to     : openstack at lists.openstack.org\n>                 Unsubscribe :\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 \n>         \n>         \n> \n> \n\n\n\n\n','<CAE4DyDG-6Y5z=85Cy3Ba374j+YVwYgXaxUmP=dA-3zOx8urJiA@mail.gmail.com>',NULL),('<1408377144.4188.22.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-18 17:52:24',7200,'2014-08-18 15:52:24',NULL,'[Openstack-operators] [Openstack] Connect VM network to exists\n VLAN network','Hi Marouen, \n\ninteresting setup that you\'re driving. \nNot sure if I can help you out but let\'s try.\n\nYou\'re able to ping both feets of your router from within your vm -\nthat\'s great!\nBut you cannot ping the routers feets from your hypervisor, right?\n\n--> That makes sense to me. \nIn general you will never be able to ping your instances private ip from\nthe controller or from the hypervisor (this might change with dvr, but\nthat\'s not yet released I guess). Cause neither the hypevisor nor the\ncontroller has a foot into the real tenant network (vlan or whatever). \n\nThe only chance is via the network node, where the virtual router sits.\nOnly there you can enter the tenant network. But this will not work\nwhile just pinging the guest. Let me tell you why:\n\nRouters are realized in network namespaces. So what you have to do is to\nswitch to the network namespace and ping from there\n# ip netns show\n--> shows all network namespaces. There should be one with qrouter.xxxx\n# ip netns exec qrouter-xxxx ip a\n--> list all interfaces in that namespace. Here you should see 2 devices\nwith your routers ip addresses\n# ip netns exec qrouter-xxxx ping <instance-ip>\n--> ping should be possible.\n\n\nThen you also tried out with floating ip and SSH to the floating ip\nworks from a remote host, but not from your openstack nodes, right?\nAnd from your openstack nodes you can also ping the instance, so\nconnection might be there.\nI have no clue what this might be. Somehting with iptables? Floating IPs\nare realized with NAT. Maybe that gives you a hint where to debug...\n\n\nRegards\nAndreas\n\n\n\n\n\nOn Fri, 2014-08-15 at 16:55 +0200, Marouen Mechtri wrote:\n> Another detail that can be useful.\n> I can ping the floating IP of my instance and I can telnet the port\n> 22  from the controller, compute and network nodes\n> \n> \n> Trying 192.168.100.121...\n> Connected to 192.168.100.121.\n> Escape character is \'^]\'.\n> SSH-2.0-dropbear_2012.55\n> \n> \n> but I can not ssh from the controller, compute and network nodes.\n> From an external host I can ssh my instance.\n> \n> \n> \n> \n> Thank you in advance.\n> \n> \n> Best regards,\n> Marouen\n> \n> \n> 2014-08-15 16:17 GMT+02:00 Marouen Mechtri <mechtri.marwen at gmail.com>:\n>         Hi Andreas,\n>         \n>         \n>         I setup OpenStack on multinode (like the picture you\n>         sent http://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png)\n>         and I\'m using Icehouse release with openvswitch and GRE\n>         tunnel.\n>         For more detail about the network configuration:\n>         https://raw.githubusercontent.com/ChaimaGhribi/OpenStack-Icehouse-Installation/master/images/network-topo.jpg\n>         \n>         \n>         \n>         I\'m running the controller and network nodes on VMs (in the\n>         compute node)  and the compute node is my physical host.\n>         \n>         \n>         Evry things are OK and I\'m able to deploy instances and I can\n>         ping from my instance the router gateways (connected to tenant\n>         network and to the extenal nework)\n>         \n>         \n>         The only issue I have I can not ping the tenant address of my\n>         instance and the address of the tenant gateway from the\n>         controller, network and compute nodes.\n>         I can not also ping the controller node from my instance.\n>         \n>         \n>         Could you please help me to solve this issue.\n>         \n>         \n>         Thank you in advance.\n>         Best regards,\n>         Marouen\n>         \n>         \n>         2014-08-15 13:36 GMT+02:00 Andreas Scheuring\n>         <scheuran at linux.vnet.ibm.com>:\n>         \n>                 Hi,\n>                 just that we\'re on the same page. Please have a look\n>                 at this picture:\n>                 http://docs.openstack.org/havana/install-guide/install/apt/content/figures/3/a/common/figures/Neutron-PhysNet-Diagram.png\n>                 \n>                 With the provider network you create a network that\n>                 matches the green\n>                 External & the purple api network (as you have a\n>                 combined controller +\n>                 network node). This is where you already have vlan,\n>                 right?\n>                 \n>                 And on the green data network you try to use gre,\n>                 right?\n>                 \n>                 Or does you controller only have one physical nic for\n>                 all kind of\n>                 traffic?\n>                 \n>                 \n>                 I\'m sorry but I do not yet understand your setup and\n>                 what you\'re trying\n>                 to achieve.\n>                 \n>                 Please keep always the mailing lists on cc, as others\n>                 might also be\n>                 interested.\n>                 \n>                 \n>                 \n>                 Regards,\n>                 Andreas\n>                 \n>                 \n>                 \n>                 On Fri, 2014-08-15 at 14:21 +0700, Nhan Cao wrote:\n>                 > hi,\n>                 > i deploy on multinode with neutron and openvswitch.\n>                 > My Infrastructure has a exists VLAN, now, i\'m using\n>                 GRE type network.\n>                 > I found a article about that\n>                 >\n>                 http://trickycloud.wordpress.com/2013/11/12/setting-up-a-flat-network-with-neutron/\n>                 > Could you give me a advice? i should choose VLAN or\n>                 GRE for best?\n>                 > Thanks\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 > 2014-08-15 13:46 GMT+07:00 Andreas Scheuring\n>                 > <scheuran at linux.vnet.ibm.com>:\n>                 >         Hi Nhan,\n>                 >         I guess more information is required to help\n>                 you out there.\n>                 >\n>                 >         It would be helpful to know which setup\n>                 you\'re using, e.g. a\n>                 >         singlenode\n>                 >         or multinode setup, openvswitch for network\n>                 virtualiation or\n>                 >         something\n>                 >         else? Are you using nova network or neutron\n>                 networking?\n>                 >\n>                 >         If I got it right you created a tenant\n>                 network in openstack\n>                 >         (in your\n>                 >         case vm network). In addition your host\n>                 (hypervisor) has a an\n>                 >         eth\n>                 >         interface into the physical network, right?\n>                 >\n>                 >         You also mentioned that your physical\n>                 network is a vlan\n>                 >         network. Is your\n>                 >         hypervisor aware of this vlan tagging or is\n>                 this done by a\n>                 >         access port\n>                 >         config in your switch?\n>                 >\n>                 >\n>                 >         And what you want to achieve is to connect a\n>                 vm attached to\n>                 >         the\n>                 >         openstack vm network to your physical vlan\n>                 network. Did I get\n>                 >         you right?\n>                 >\n>                 >         Basically you would create a so called\n>                 \"provider network\" that\n>                 >         represents your physical network and connect\n>                 this provider\n>                 >         network via a\n>                 >         virtual router to your vm network.\n>                 >\n>                 >         More information you can find here:\n>                 >\n>                  http://docs.openstack.org/admin-guide-cloud/content/under_the_hood_openvswitch.html#under_the_hood_openvswitch_scenario1\n>                 >\n>                 >\n>                 >         Regards,\n>                 >         Andreas\n>                 >\n>                 >\n>                 >\n>                 >         On Fri, 2014-08-15 at 00:00 +0700, Nhan Cao\n>                 wrote:\n>                 >         > Hi\n>                 >         > I have to network:\n>                 >         > vm network: 10.2.21.0/24\n>                 >         > exist VLAN network: 192.168.1.0/24\n>                 >         > I want to connect from my VM network to\n>                 physic VLAN network.\n>                 >         >\n>                 >         > How i config to connect?\n>                 >         >\n>                 >         >\n>                 >         >\n>                 >         > Thanks :)\n>                 >         >\n>                 >         >\n>                 >\n>                 >         >\n>                 _______________________________________________\n>                 >         > Mailing list:\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 >         > Post to     :\n>                 openstack at lists.openstack.org\n>                 >         > Unsubscribe :\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 >\n>                 >\n>                 >\n>                 >\n>                  _______________________________________________\n>                 \n>                 >         OpenStack-operators mailing list\n>                 >         OpenStack-operators at lists.openstack.org\n>                 >\n>                  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>                 >\n>                 >\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 Mailing list:\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 Post to     : openstack at lists.openstack.org\n>                 Unsubscribe :\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 \n>         \n>         \n> \n> \n\n\n\n\n','<CAE4DyDG-6Y5z=85Cy3Ba374j+YVwYgXaxUmP=dA-3zOx8urJiA@mail.gmail.com>',NULL),('<1408387171.839.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 18:37:36',0,'2014-08-18 18:37:36',NULL,'[openstack-dev] [Octavia] Object Model and DB Structure','Hi German,\nI don\'t think it is a requirement that those two frontend sections (or\nlisten sections) have to live in the same config.  I thought if they\nwere listening on the same IP but different ports it could be in two\ndifferent haproxy instances.  I could be wrong though.\n\nThanks,\nBrandon\n\nOn Mon, 2014-08-18 at 17:21 +0000, Eichberger, German wrote:\n> Hi,\n> \n> My 2 cents for the multiple listeners per load balancer discussion: We have customers who like to have a listener on port 80 and one on port 443 on the same VIP (we had to patch libra to allow two \"listeners\" in one single haproxy) - so having that would be great.\n> \n> I like the proposed status :-)\n> \n> Thanks,\n> German\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \n> Sent: Sunday, August 17, 2014 8:57 PM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [Octavia] Object Model and DB Structure\n> \n> Oh hello again!\n> \n> You know the drill!\n> \n> On Sat, 2014-08-16 at 11:42 -0700, Stephen Balukoff wrote:\n> > Hi Brandon,\n> > \n> > \n> > Responses in-line:\n> > \n> > On Fri, Aug 15, 2014 at 9:43 PM, Brandon Logan \n> > <brandon.logan at rackspace.com> wrote:\n> >         Comments in-line\n> >         \n> >         On Fri, 2014-08-15 at 17:18 -0700, Stephen Balukoff wrote:\n> >         > Hi folks,\n> >         >\n> >         >\n> >         > I\'m OK with going with no shareable child entities\n> >         (Listeners, Pools,\n> >         > Members, TLS-related objects, L7-related objects, etc.).\n> >         This will\n> >         > simplify a lot of things (like status reporting), and we can\n> >         probably\n> >         > safely work under the assumption that any user who has a use\n> >         case in\n> >         > which a shared entity is useful is probably also technically\n> >         savvy\n> >         > enough to not only be able to manage consistency problems\n> >         themselves,\n> >         > but is also likely to want to have that level of control.\n> >         >\n> >         >\n> >         > Also, an haproxy instance should map to a single listener.\n> >         This makes\n> >         > management of the configuration template simpler and the\n> >         behavior of a\n> >         > single haproxy instance more predictable. Also, when it\n> >         comes to\n> >         > configuration updates (as will happen, say, when a new\n> >         member gets\n> >         > added to a pool), it\'s less risky and error prone to restart\n> >         the\n> >         > haproxy instance for just the affected listener, and not for\n> >         all\n> >         > listeners on the Octavia VM. The only down-sides I see are\n> >         that we\n> >         > consume slightly more memory, we don\'t have the advantage of\n> >         a shared\n> >         > SSL session cache (probably doesn\'t matter for 99.99% of\n> >         sites using\n> >         > TLS anyway), and certain types of persistence wouldn\'t carry\n> >         over\n> >         > between different listeners if they\'re implemented poorly by\n> >         the\n> >         > user. :/  (In other words, negligible down-sides to this.)\n> >         \n> >         \n> >         This is fine by me for now, but I think this might be\n> >         something we can\n> >         revisit later after we have the advantage of hindsight.  Maybe\n> >         a\n> >         configurable option.\n> > \n> > \n> > Sounds good, as long as we agree on a path forward. In the mean time, \n> > is there anything I\'m missing which would be a significant advantage \n> > of having multiple Listeners configured in a single haproxy instance?\n> > (Or rather, where a single haproxy instance maps to a loadbalancer\n> > object?)\n> \n> No particular reason as of now.  Just feel like that could be something that could hinder a particular feature or even performance in the future.  It\'s not rooted in any fact or past experience.\n> \n> >  \n> >         I have no problem with this. However, one thing I often do\n> >         think about\n> >         is that it\'s not really ever going to be load balancing\n> >         anything with\n> >         just a load balancer and listener.  It has to have a pool and\n> >         members as\n> >         well.  So having ACTIVE on the load balancer and listener, and\n> >         still not\n> >         really load balancing anything is a bit odd.  Which is why I\'m\n> >         in favor\n> >         of only doing creates by specifying the entire tree in one\n> >         call\n> >         (loadbalancer->listeners->pool->members).  Feel free to\n> >         disagree with me\n> >         on this because I know this not something everyone likes.  I\'m\n> >         sure I am\n> >         forgetting something that makes this a hard thing to do.  But\n> >         if this\n> >         were the case, then I think only having the provisioning\n> >         status on the\n> >         load balancer makes sense again.  The reason I am advocating\n> >         for the\n> >         provisioning status on the load balancer is because it still\n> >         simpler,\n> >         and only one place to look to see if everything were\n> >         successful or if\n> >         there was an issue.\n> > \n> > \n> > Actually, there is one case where it makes sense to have an ACTIVE \n> > Listener when that listener has no pools or members:  Probably the 2nd \n> > or 3rd most common type of \"load balancing\" service we deploy is just \n> > an HTTP listener on port 80 that redirects all requests to the HTTPS \n> > listener on port 443. While this can be done using a (small) pool of \n> > back-end servers responding to the port 80 requests, there\'s really no \n> > point in not having the haproxy instance do this redirect directly for \n> > sites that want all access to happen over SSL. (For users that want \n> > them we also insert HSTS headers when we do this... but I digress. ;)\n> > )\n> > \n> > \n> > Anyway, my point is that there is a common production use case that \n> > calls for a listener with no pools or members.\n> \n> Yeah we do HTTPS redirect too (or HTTP redirect as I would call it...I could digress myself).  I don\'t think its common for our customers, but it obviously should still be supported.  Also, wouldn\'t that break the only one listener per instance rule? Also also, I think haproxy 1.5 has \"redirect scheme\" option that might do away with the extra frontend section.  I could be wrong though.\n> \n> >  \n> >         \n> >         Again though, what you\'ve proposed I am entirely fine with\n> >         because it\n> >         works great with having to create a load balancer first, then\n> >         listener,\n> >         and so forth.  It would also work fine with a single create\n> >         call as\n> >         well.\n> > \n> > \n> > We should probably create more formal API documentation, eh. :)  (Let \n> > me pull up my drafts from 5 months ago...)\n> \n> What I\'m hoping the API will look like will be different than those drafts, similar though.  So they\'re probably a good starting point.\n> Then again the neutron lbaas api google doc is probably a good one too.\n> \n> >  \n> >         >\n> >         > I don\'t think that these kinds of status are useful /\n> >         appropriate for\n> >         > Pool, Member, Healthmonitor, TLS certificate id, or L7\n> >         Policy / Rule\n> >         > objects, as ultimately this boils down to configuration\n> >         lines in an\n> >         > haproxy config somewhere, and really the Listener status is\n> >         what will\n> >         > be affected when things are changed.\n> >         \n> >         \n> >         Total agreement on this.\n> >         >\n> >         > I\'m basically in agreement with Brandon on his points with\n> >         operational\n> >         > status, though I would like to see these broken out into\n> >         their various\n> >         > meanings for the different object types. I also think some\n> >         object\n> >         > types won\'t need an operational status (eg. L7 Policies,\n> >         > healthmonitors, etc.) since these essentially boil down to\n> >         lines in an\n> >         > haproxy configuration file.\n> >         \n> >         \n> >         Yeah I was thinking could be more descriptive status names for\n> >         the load\n> >         balancer and listener statuses.  I was thinking load balancer\n> >         could have\n> >         PENDING_VIP_CREATE/UPDATE/DELETE, but then that\'d be painting\n> >         us into a\n> >         corner.  More general is needed.  With that in mind, the\n> >         generic\n> >         PENDING_CREATE/UPDATE/DELETE is adequate enough as long as the\n> >         docs\n> >         explain what they mean for each object clearly.\n> > \n> > \n> > Right. Let\'s get this documented. :) Or rather-- let\'s get drafts of \n> > this documentation going in gerrit so people can give specific \n> > feedback.  (I\'m happy to work on this, so long as I\'m not a blocker on \n> > anything else-- I want to make sure anyone who wants to put time into \n> > the Octavia project knows how they can be useful, eh. It\'s a major pet \n> > peeve of mine to find out after the fact that somebody was waiting on \n> > something for me, and that this was a blocker for them being\n> > productive.)\n> \n> I like your documentation skills and attention to detail.  If you don\'t mind doing it, unless someone else wants something to do.\n> \n> >  \n> > Stephen\n> > \n> > \n> > \n> > --\n> > Stephen Balukoff\n> > Blue Box Group, LLC\n> > (800)613-4305 x807\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C3C9431@G2W2441.americas.hpqcorp.net>',NULL),('<1408398414.4527.20.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 21:44:57',0,'2014-08-18 21:44:57',NULL,'[openstack-dev] [Octavia] Minutes from 8/13/2014 meeting','Hi Salvatore,\nIt\'d be great to get your contributions in this! If you could only bring\nyour knowledge and experience with Neutron to the table that\'d be very\nbeneficial.  Looking forward to it.\n\nComments in-line\n\nOn Mon, 2014-08-18 at 23:06 +0200, Salvatore Orlando wrote:\n> Hi Trevor,\n> \n> \n> thanks for sharing this minutes!\n> I would like to cooperate a bit to this project\'s developments,\n> possibly without ending up being just deadweight.\n> \n> \n> To this aim I have some comments inline.\n> \n> \n> Salvatore\n> \n> \n> On 18 August 2014 22:25, Trevor Vardeman\n> <trevor.vardeman at rackspace.com> wrote:\n>         Agenda items are numbered, and topics, as discussed, are\n>         described beneath in list format.\n>         \n>         \n>         1) Discuss future of Octavia in light of Neutron-incubator\n>         project proposal.\n>             a) There are many problems with Neutron-Incubator as\n>         currently described\n> \n> \n>  Have you listed your concerns somewhere? AFAICT the incubator\n> definition is in progress and feedback is very valuable at this stage.\n\nWe have, many times.  In etherpad, to Kyle and Mark in IRC meetings.\nNot sure how it will shape up in the end yet though.\n\n> \n> \n>             b) The political happenings in Neutron leave our LBaaS\n>         patches under review unlikely to land in Juno\n> \n> \n> I am a bit disappointed if you feel like  you have been victims of\n> political discussions.\n> The truth in my opinion is much simpler, and is that most of the\n> neutron core team has prioritised features for achieving parity with\n> nova-network or increasing neutron scalability and reliability.\n> In my opinion the incubator proposal will improve this situation by\n> making the lbaas team a lot less dependent on the neutron core team.\n> Considering the level of attention the load balancing team has\n> received I would not be surprised if neutron cores are topping your\n> most-hated list!\n\nI think the main issue everyone has had was that there was an\nexpectation that if we got our code in and went through many iterations\nof reviews then we\'d get into Juno.  We did everything asked of us and\nthis the incubator came in very late.  However, I (and I\'m pretty sure\nmost others) absolutely agree that the incubator should exist, and that\nthe lbaas v2 belongs in there (so does v1).  It was just the timing of\nit based on what the expectations were set forth at the summit.\n\nNeutron cores are not topping our most-hated list at all.  I think we\nall see the cores have a ton of reviews and work to do.  I think its\nmore a symptom of two issues: 1) Neutron\'s scope is too large 2) If\nNeutron\'s scope wants to be that large, then adding more core reviewers\nseems to be the logical solution.\n\nNow the incubator can definitely solve for #1 because it has a path for\nspinning out.  However, the fear is that the incubator will become an\nafter thought for neutron cores.  I hope this is not the case, and I\nhave high hopes for it, but it\'s still a fear even from the most\noptimistic of people.\n\n>  \n>             c) The Incubator proposal doesn\'t affect Octavia\n>         development direction, with inclination to distance ourselves\n>         from Neutron proper\n> \n> \n> It depends on what do you mean by \"proper\" here. If you\'re into a\n> neutron incubator, your ultimate path ideally should be integration\n> with neutron.\n> Instead if you\'re planning on total independence, then it might the\n> case of considering the typical paths new projects follow. I\'m not an\n> expert here, but I think that usually starts from stackforge.\n\nThe incubator does have a spin out path and I believe that may be the\nway forward on this.  I don\'t think spinning out should be something we\nshould focus on too much right now until Octavia is in a good state.\nEither way, I\'m sure we have the blessing of Kyle and Mark to spin out\nat some point and become a project under the Networking Program.  This\ncould be accomplished a number of ways.\n\n>  \n>             d) With the Neutron Incubator proposal in current scope,\n>         efforts of people pushing forward Neutron LBaaS patches should\n>         be re-focused into Octavia.\n> \n> \n> Which probably sounds a reasonable thing to do (and a lot less effort\n> for you as well) \n>         \n>         \n>         2) Discuss operator networking requirements (carry-over from\n>         last week)\n>             a) Both HP and Rackspace seem to agree that as long as\n>         Octavia uses Neutron-like floating IPs, their networks should\n>         be able to work with proposed Octavia topologies\n>             b) (Blue Box) also wanted to meet with Rackspace\'s\n>         networking team during the operator summit a few weeks from\n>         now to thoroughly discuss network concerns\n>         \n>         \n>         3) Discuss v0.5 component design proposal\n>          [https://review.openstack.org/#/c/113458/]\n>             a) Notification for back-end node health (aka being\n>         offline) isn\'t required for 0.5, but is a must have later\n>             b) Notification of LB health (HA Proxy, etc) is definitely\n>         a requirement in 0.5\n>             c) Still looking for more feedback on the proposal itself\n> \n> \n> I\'ll try and find some time to review it. \n>         \n>         \n>         4) Discuss timeline on moving these meetings to IRC.\n>             a) Most members in favor of keeping the webex meetings for\n>         the time being\n>             b) One major point was other openstack/stackforge use\n>         video meetings as their \"primary\" source as well\n> \n> \n> This is one of the reasons for which I don\'t attend load balancing\n> meetings.\n> I find IRC much simpler and effective - and is also fairer to people\n> for whom English is not their first language.\n> Also, perusing IRC logs is much easier than watch/listen to webex\n> recordings.\n> Moreover, you\'d get minutes for free - and you can control the density\n> you want them to have during the meeting!\n\nThese meetings are just for Octavia right now and will eventually get\ninto IRC.  The weekly LBaaS meeting is still in IRC every thursday at\n14:00 UTC.  I\'ve just been pushing for IRC because I hate phone/video\nconferences with many people.  The reasons you outlined are definitely\nthe main reasons to do it, I\'m just being selfish with my own reason.\nThe plan is to eventually get it on IRC.  With the more interest we get\non this the more we need to speed this up.\n\n> \n> \n>         \n>         \n>         \n>         \n>             Sorry for the lack of density.  I forgot to have the\n>         meeting recorded, but I hope I included some major points.\n>          Feel free to respond in line with any more information anyone\n>         can recall concerning the meeting information.  Thanks!\n>         \n>         \n>         -Trevor\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThanks,\nBrandon\n\n\n','<CAGR=i3i6+zkVyAApJ_cjhm7ccmxU-DxqxX-=vN_Pc8tM76OfHA@mail.gmail.com>',NULL),('<1408404069-sup-7409@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 23:31:24',0,'2014-08-18 23:31:24',NULL,'[openstack-dev] [TripleO] devtest environment for virtual or\n	true bare metal','Excerpts from Ben Nemec\'s message of 2014-08-08 22:25:35 +0000:\n> That sounds essentially correct.  Note that all 15 vms aren\'t used in a\n> normal devtest run, but we create them all anyway because of some\n> difficulties adding new environments in some situations (namely CI, I\n> believe).\n> \n> On 08/05/2014 11:27 AM, LeslieWang wrote:\n> > Hi Ben,\n> > Thanks for your reply. \n> > Actually I\'m a little confused by \"virtual environment\". I guess what it means is as below:  - 1 Seed VM as deployment starting point.  - Both undercloud and overcloud images are loaded into Glance of Seed VM.  - 15 VMs are created. 1 for undercloud, 1 for overcloud controller, left 13 are for overcloud compute.  - 1 Host machine acts as container for all 15 VMs. It can be separated from Seed VM.  - Seed VM communicates with Host machine to create 15 VMs and installed corresponding images.  Is it correct? Or can you roughly introduces the topology of the devtest virtual environment.\n> > Best RegardsLeslie Wang\n> >                            \n\nYes, im not sure that \'15 VMs are created\' is entirely correct - we\ncreate 15 vm definitions. This does include qcow2 images but these\ntypically start much smaller than their full possible size on disk.\nThe distinction is, as Ben points out, that we do not actually deploy to\nall of these VMs.\n\nIn addition to the CI issues, we specify a static number that is large\nenough for full runs to more correctly emulate a real deployment -\ntypically you have a set number of servers to deploy on which is not\ndirectly determined by your deployment requirements.\n\nCheers,\nGreg\n\n\n','<53E54E5F.8060109@nemebean.com>',NULL),('<1408407426-sup-8922@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 00:22:08',0,'2014-08-19 00:22:08',NULL,'[openstack-dev] [TripleO] fix poor tarball support in\n	source-repositories','Excerpts from Clint Byrum\'s message of 2014-08-16 14:33:20 +0000:\n> That is a separate bug, but I think the answer to that is to use rsync\n> instead of mv and globs. So this:\n> \n>     mv $tmp/./* $destdir\n> \n> becomes this:\n> \n>     rsync --remove-source-files $tmp/. $destdir\n> \n\n+1 on this approach. It\'s straightforward to explain and fairly easy to\nreason about.\n\nI saw mention of checking the in-tarball contents to determine what to\ndo - I would prefer us to be explicit about the behavior to take rather\nthan depend on some internal structure of an external package. While we\nhave to depend on the structure of the tarball to a certain extent, IMO\nwe should minimize this if possible.\n\n\n','<1408199350-sup-6@fewbar.com>',NULL),('<1408414761.26869.17.camel@ruth.wgtn.cat-it.co.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 14:19:21',43200,'2014-08-19 02:19:21',NULL,'[openstack-dev] Time to Samba! :-)','On Mon, 2014-08-18 at 07:27 +0000, Alessandro Pilotti wrote:\n> Hi Thiago,\n> \n> \n> Like for the Windows case, where we have Heat templates for AD DC and\n> other MSFT related workloads (Exchange, SQL Server, SharePoint, etc)\n> [1], the best place in OpenStack for Samba 4 DC is a dedicated Heat\n> template.\n> \n> \n> Heat is the de facto workload orchestration standard for OpenStack, so\n> I\'d definitely start from there.\n\nInteresting.  How do you see this compared to doing it in Murano?  (In\nany case, I\'m happy to help anyone working on this, no matter the\nlayer). \n\n> Said that, Keystone has AD support via LDAP. It\'d be great to see some\n> documentation for using a Samba 4 DC in place of a Windows DC. \n> \n> \n> Another area of interaction for Samba 4 is Cinder: we have code under\n> review for exporting volumes over SMB, useful for Hyper-V compute\n> nodes and other scenarios. [2]\n\nSamba currently can\'t support HyperV as a SMB server due to a limitation\nin our SMB3 support: https://bugzilla.samba.org/show_bug.cgi?id=9938\nHowever, we are making progress on \'Leases\', which I understand is part\nof required solution here. \n\n> Talking about Nova, in large deployments using Hyper-V compute nodes\n> it\'s common to manage credentials with domain membership, quite useful\n> for live migration in particular. I\'d like to document the usage of a\n> Samba 4 AD DC in this context, although the last time I tried I had\n> issues with Kerberos delegation, required for live migration. Quite\n> some time passed, so it\'s definitely worth giving it another try.\n\nIf you have specific, reproducible issues with our KDC blocking Samba\'s\nuse in OpenStack and are able to work with me to test the solution,\nplease bring them to my personal attention.  I am very happy to address\nspecific use cases, and this one in particular means a lot to me. \n\nThanks,\n\nAndrew Bartlett\n\n-- \nAndrew Bartlett\nhttp://samba.org/~abartlet/\nAuthentication Developer, Samba Team  http://samba.org\nSamba Developer, Catalyst IT          http://catalyst.net.nz/services/samba\n\n\n\n\n\n\n','<BCE060F9-A99C-4C09-A040-0403CA91C0B3@cloudbasesolutions.com>',NULL),('<140841686.27.1383201509392.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-31 06:38:29',0,'2013-10-31 06:38:29',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #40','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/40/>\n\n------------------------------------------\n[...truncated 21090 lines...]\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTest.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  173.582\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           97.270\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  85.881\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        42.900\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     42.769\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    41.978\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      40.346\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       39.034\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        37.837\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         37.355\n\n----------------------------------------------------------------------\nRan 1408 tests in 1632.211s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-624466-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-624466.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-624466/40/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2128661877.14.1382769056160.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1408430146.4219.5.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-19 08:35:46',7200,'2014-08-19 06:35:46',NULL,'[Openstack-operators] I have finally created an instance,\n and it works! However, there is no ethernet card','Hi Jeff, \nwhat does it mean when you\'re saying \"I don\'t want to go through\nneutron\". Does it mean you\'re running nova network?\n\nUsually, when you configured openvswitch as vswitch, neutron should\ncreate the network ports for you. There\'s not much config required to\nuse it. You just need the ml2 core plugin and the openvswitch mechanism\ndriver configured.\n\n\n\nThis is a vlan config I configured some time ago in neutron. But not\nsure about nova network!\n\n\n\n\nneutron.conf:\ncore_plugin = neutron.plugins.ml2.plugin.Ml2Plugin\n\n\nml2_conf.ini:\n[ml2]\ntype_drivers = vlan,flat\nmechanism_drivers = openvswitch\ntenant_network_types = vlan\n\n[ml2_type_vlan]\nnetwork_vlan_ranges = phys-data:1000:2999\n\n\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\n[database]\nconnection = mysql://root:password at 127.0.0.1/neutron_ml2?charset=utf8\n\n[ovs]\nlocal_ip = 9.152.150.204\nbridge_mappings = phys-data:br-data,phys-ex:br-ex\ntenant_network_types = vlan\n\n[agent]\nroot_helper =\nsudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n\n\nOn Mon, 2014-08-18 at 16:33 -0700, Jeff Silverman wrote:\n> I figured out how to give the instance a virtual NIC.  It is getting\n> an IP address from our DHCP, I can ssh in, and I can surf the web.\n> \n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# ifconfig VLAN_15\n> VLAN_15   Link encap:Ethernet  HWaddr 00:25:90:5B:AA:A0  \n>           inet addr:10.50.15.48  Bcast:10.50.15.255  Mask:255.255.255.0\n>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> \n>           RX packets:8355781 errors:0 dropped:0 overruns:0 frame:0\n>           TX packets:1644788 errors:0 dropped:0 overruns:0 carrier:0\n>           collisions:0 txqueuelen:0 \n>           RX bytes:5040893113 (4.6 GiB)  TX bytes:211825561 (202.0 MiB)\n> \n> \n> root at compute1-prod.compute1-prod:/var/log/neutron#  /etc/init.d/openvswitch  start\n> \n> ovs-vsctl list-br   # you should see nothing\n> ovs-vsctl add-br br-int\n> ovs-vsctl list-br\n> ovs-vsctl add-br VLAN_15\n> ovs-vsctl add-br VLAN_20\n> \n> ovs-vsctl list-br\n> \n> Connect the open virtual switch to the instance\n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# virsh attach-interface instance-00000006 bridge VLAN_15\n> Interface attached successfully\n> \n> \n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# \n> \n> I rebooted the guest and voila!\n> \n> $ ifconfig eth0\n> eth0      Link encap:Ethernet  HWaddr 52:54:00:8E:E5:25  \n>           inet addr:10.50.15.239  Bcast:10.50.15.255  Mask:255.255.255.0\n> \n>           inet6 addr: fe80::5054:ff:fe8e:e525/64 Scope:Link\n>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n>           RX packets:1404 errors:0 dropped:0 overruns:0 frame:0\n>           TX packets:256 errors:0 dropped:0 overruns:0 carrier:0\n> \n>           collisions:0 txqueuelen:1000 \n>           RX bytes:82015 (80.0 KiB)  TX bytes:27940 (27.2 KiB)\n>           Interrupt:10 Base address:0x6000 \n> \n> $ \n> The IP address came from our dhcpd and works fine.  dhcpd also provided a default router and populated /etc/resolv.conf\n> \n> \n> My lead asked to add ports to the VLAN since there are two NICs which are bonded together using LACP:\n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl list-ports VLAN_15\n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl list-ports VLAN_20\n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl list-ports br-int\n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl add-port VLAN_15 bond0.15\n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl add-port VLAN_20 bond0.20\n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl list-ports VLAN_15\n> bond0.15\n> root at compute1-prod.compute1-prod:/var/log/neutron# ovs-vsctl list-ports VLAN_20\n> bond0.20\n> root at compute1-prod.compute1-prod:/var/log/neutron# \n> \n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# virsh dumpxml 3 \n> <domain>\n> ...\n>     <interface type=\'bridge\'>\n>       <mac address=\'52:54:00:8e:e5:25\'/>\n>       <source bridge=\'VLAN_15\'/>\n>       <target dev=\'vnet1\'/>\n>       <alias name=\'net0\'/>\n> \n>       <address type=\'pci\' domain=\'0x0000\' bus=\'0x00\' slot=\'0x05\' function=\'0x0\'/>\n>     </interface>\n> ...\n> </domain>\n> \n> root at compute1-prod.compute1-prod:/var/log/neutron# \n> \n> \n> So I know that the hypervisor is working okay.  This is exactly what I want: I want the compute node to connect direct to the physical switch/router.  I don\'t want to go through neutron, which I think will be a bottleneck.  I think I have good enough security upstream to protect the openstack.  But how do I do this configuration using neutron and open virtual switch?  Or is this the way it is supposed to be done?\n> \n> Thank you\n> \n> Jeff\n> \n> \n> \n> \n> On Mon, Aug 18, 2014 at 5:00 AM,\n> <openstack-operators-request at lists.openstack.org> wrote:\n>         Send OpenStack-operators mailing list submissions to\n>                 openstack-operators at lists.openstack.org\n>         \n>         To subscribe or unsubscribe via the World Wide Web, visit\n>         \n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         \n>         or, via email, send a message with subject or body \'help\' to\n>                 openstack-operators-request at lists.openstack.org\n>         \n>         You can reach the person managing the list at\n>                 openstack-operators-owner at lists.openstack.org\n>         \n>         When replying, please edit your Subject line so it is more\n>         specific\n>         than \"Re: Contents of OpenStack-operators digest...\"\n>         \n>         \n>         Today\'s Topics:\n>         \n>            1. How can I select host node to create VM? (Taeheum Na)\n>            2. Re: I have finally created an instance, and it works!\n>               However, there is no ethernet card (Andreas Scheuring)\n>            3. Operations summit (Sean Roberts)\n>         \n>         \n>         ----------------------------------------------------------------------\n>         \n>         Message: 1\n>         Date: Mon, 18 Aug 2014 12:55:58 +0900\n>         From: Taeheum Na <thna at nm.gist.ac.kr>\n>         To: \"openstack-operators at lists.openstack.org\"\n>                 <openstack-operators at lists.openstack.org>\n>         Subject: [Openstack-operators] How can I select host node to\n>         create\n>                 VM?\n>         Message-ID:\n>         \n>         <0145D5DF1C56174FABB6EB834BC4909C03FEBD1915AC at NML2007.netmedia.kjist.ac.kr>\n>         \n>         Content-Type: text/plain; charset=\"us-ascii\"\n>         \n>         Hello,\n>         When I create instance, I want to choice host node.\n>         I saw that by default, VMs are scheduled by filter scheduler\n>         which only consider computing resource.\n>         I want to apply substrate network considered scheduling\n>         algorithm on OpenStack.\n>         To do this one, I have to monitor utilization of\n>         computing/network resources.\n>         Now, I\'m planning to use OpenvSwitch commend to know network\n>         situation.\n>         \n>         Do you have any comment for me? (monitor/scheduling)\n>         \n>         Regards\n>         Taeheum Na\n>         ****************************************************\n>         M.S. candidate of Networked Computing Systems Lab.\n>         School of Information and Communications\n>         GIST (Gwangju Inst. of Sci. and Tech.)\n>         E-mail: thna at nm.gist.ac.kr<mailto:thna at nm.gist.ac.kr>\n>         Phone: +82-10-2238-9424\n>         Office: +82-62-715-2273\n>         \n>         -------------- next part --------------\n>         An HTML attachment was scrubbed...\n>         URL:\n>         <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140818/470f4ef4/attachment-0001.html>\n>         \n>         ------------------------------\n>         \n>         Message: 2\n>         Date: Mon, 18 Aug 2014 09:04:26 +0200\n>         From: Andreas Scheuring <scheuran at linux.vnet.ibm.com>\n>         To: \"openstack-operators at lists.openstack.org\"\n>                 <openstack-operators at lists.openstack.org>\n>         Subject: Re: [Openstack-operators] I have finally created an\n>         instance,\n>                 and it works! However, there is no ethernet card\n>         Message-ID: <1408345466.4188.6.camel at oc5515017671.ibm.com>\n>         Content-Type: text/plain; charset=\"UTF-8\"\n>         \n>         Assuming you\'re running a libvirt based hypervisor (e.g. kvm).\n>         Could you\n>         please dump the libvirt xml of your instance?\n>         \n>         You can get it this way\n>         \n>         virsh list --all\n>         --> shows a list of all virtual servers running on your\n>         hypervisor\n>         \n>         virsh dumpxml <vm-id>\n>         --> dumps the xml of your vm, addressed by the id (first\n>         column). Id\n>         does not correlate with UUID!!!!! So if you\'re not sure which\n>         list entry\n>         belongs to your instance just stop all other via openstack to\n>         have only\n>         one running.\n>         \n>         PS: on some systems you have to sudo when using virsh.\n>         \n>         \n>         There should be a subtag of devices called <interface\n>         type=\'bridge\'> or\n>         \'network\' or somehting like that representing your eth\n>         interface\n>         \n>         \n>         Andreas\n>         \n>         \n>         On Fri, 2014-08-15 at 11:43 -0700, Jeff Silverman wrote:\n>         > I have been surfing the internet, and one of the ideas that\n>         comes to\n>         > mind is modifying the /etc/neutron/agent.ini file on the\n>         compute\n>         > nodes.  In the agent.ini file, there is a comment near the\n>         top that is\n>         > almost helpful:\n>         >\n>         >\n>         > # L3 requires that an interface driver be set. Choose the\n>         one that\n>         > best\n>         > # matches your plugin.\n>         >\n>         >\n>         > The only plug I know about is ml2.  I have no idea if that\n>         is right\n>         > for me or not.  And I have no idea to choose the interface\n>         drive that\n>         > best matches my plugin.\n>         >\n>         >\n>         > Thank you\n>         >\n>         >\n>         >\n>         >\n>         > Jeff\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > On Fri, Aug 15, 2014 at 10:26 AM, Jeff Silverman\n>         <jeff at sweetlabs.com>\n>         > wrote:\n>         >         By \"defined a network space for your instances\",\n>         does that\n>         >         mean going through the process as described\n>         >         in\n>         http://docs.openstack.org/icehouse/install-guide/install/yum/content/neutron-ml2-compute-node.html?\n>         >\n>         >\n>         >         I got part way through that when I realized that the\n>         procedure\n>         >         was going to bridge packets through neutron.  That\'s\n>         not what\n>         >         I want.  I want the packets to go directly to the\n>         physical\n>         >         router.  For example, I have two tenants, with IP\n>         addresses\n>         >         10.50.15.80/24 and 10.50.18.15.90/24.and the router\n>         is at\n>         >         10.50.15.1.  There is a nice picture of what I am\n>         trying to do\n>         >         at\n>         http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#nova_network_traffic_in_cloud .  But if the hypervisor doesn\'t present a virtual device to the guests, then nothing else is going to happen.  The network troubleshooting guide http://docs.openstack.org/openstack-ops/content/network_troubleshooting.html#nova_network_traffic_in_cloud does not explain what to do if the virtual NIC is missing.\n>         >\n>         >\n>         >\n>         >\n>         >         Thank you\n>         >\n>         >\n>         >         Jeff\n>         >\n>         >\n>         >\n>         >\n>         >         On Fri, Aug 15, 2014 at 9:38 AM, Abel Lopez\n>         >         <alopgeek at gmail.com> wrote:\n>         >                 Curious if you?ve defined a network space\n>         for your\n>         >                 instances. If you?re using the traditional\n>         >                 flat_network, this is known as\n>         the ?fixed_address?\n>         >                 space.\n>         >                 If you?re using neutron, you would need to\n>         create a\n>         >                 network and a subnet (and router with\n>         gateway, etc).\n>         >                 You?d then assign the instance to a network\n>         at launch\n>         >                 time.\n>         >\n>         >\n>         >\n>         >                 On Aug 15, 2014, at 9:17 AM, Jeff Silverman\n>         >                 <jeff at sweetlabs.com> wrote:\n>         >\n>         >                 > <ip_a.png>\n>         >                 >\n>         >                 > ?\n>         >                 >\n>         >                 > For those of you that can\'t see pictures:\n>         >                 > $ sudo ip a\n>         >                 > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436\n>         qdisc\n>         >                 > noqueue\n>         >                 >     link/loopback 00:00:00:00:00:00 brd\n>         >                 > 00:00:00:00:00:00\n>         >                 >     inet 127.0.0.1/8 scope host lo\n>         >                 >     inet6 ::1/128 scope host\n>         >                 >         valid_lft forever preferred_1ft\n>         forever\n>         >                 >\n>         >                 >\n>         >                 > I suspect that the issue is that the\n>         hypervisor is\n>         >                 > not presenting a virtual ethernet card.\n>         >                 >\n>         >                 >\n>         >                 > Thank you\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 > Jeff\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 > On Thu, Aug 14, 2014 at 6:57 PM, Nhan Cao\n>         >                 > <nhanct92 at gmail.com> wrote:\n>         >                 >         can you show output of command:\n>         >                 >         ip a\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >         2014-08-15 7:41 GMT+07:00 Jeff\n>         Silverman\n>         >                 >         <jeff at sweetlabs.com>:\n>         >                 >                 People,\n>         >                 >\n>         >                 >\n>         >                 >                 I have brought up an\n>         instance, and I\n>         >                 >                 can connect to it using my\n>         browser!\n>         >                 >                  I am so pleased.\n>         >                 >\n>         >                 >\n>         >                 >                 However, my instance\n>         doesn\'t have an\n>         >                 >                 ethernet device, only a\n>         loopback\n>         >                 >                 device.   My management\n>         wants me to\n>         >                 >                 use a provider network,\n>         which I\n>         >                 >                 understand to mean that my\n>         instances\n>         >                 >                 will have IP addresses in\n>         the same\n>         >                 >                 space as the controller,\n>         block\n>         >                 >                 storage, and compute node\n>         >                 >                 administrative addresses.\n>         However,\n>         >                 >                 I think that discussing\n>         addressing\n>         >                 >                 is premature until I have\n>         a working\n>         >                 >                 virtual ethernet card.\n>         >                 >\n>         >                 >\n>         >                 >                 I am reading\n>         >                 >                 through\n>         http://docs.openstack.org/icehouse/install-guide/install/yum/content/neutron-ml2-compute-node.html and I think that the ML2 plugin is what I need.  However, I think I do not want a network type of GRE, because that encapsulates the packets and I don\'t have anything to un-encapsulate them.\n>         >                 >\n>         >                 >\n>         >                 >                 Thank you\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                 Jeff\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                 --\n>         >                 >                 Jeff Silverman\n>         >                 >                 Systems Engineer\n>         >                 >                 (253) 459-2318 (c)\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>          _______________________________________________\n>         >                 >                 OpenStack-operators\n>         mailing list\n>         >                 >\n>          OpenStack-operators at lists.openstack.org\n>         >                 >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 > --\n>         >                 > Jeff Silverman\n>         >                 > Systems Engineer\n>         >                 > (253) 459-2318 (c)\n>         >                 >\n>         >                 >\n>         >                 >\n>         _______________________________________________\n>         >                 > OpenStack-operators mailing list\n>         >                 > OpenStack-operators at lists.openstack.org\n>         >                 >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         >                 >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >         --\n>         >         Jeff Silverman\n>         >         Systems Engineer\n>         >         (253) 459-2318 (c)\n>         >\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > --\n>         > Jeff Silverman\n>         > Systems Engineer\n>         > (253) 459-2318 (c)\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-operators mailing list\n>         > OpenStack-operators at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         \n>         \n>         \n>         \n>         \n>         ------------------------------\n>         \n>         Message: 3\n>         Date: Mon, 18 Aug 2014 00:34:22 -0700\n>         From: Sean Roberts <seanroberts66 at gmail.com>\n>         To: openstack-operators at lists.openstack.org\n>         Subject: [Openstack-operators] Operations summit\n>         Message-ID: <FA2E9C27-6CB8-45D3-A21B-C2431F54ADBC at gmail.com>\n>         Content-Type: text/plain; charset=\"us-ascii\"\n>         \n>         I wanted to post a few items on the upcoming operator summit\n>         - I am going to moderate the Tuesday 10:30am\n>         Deploy/Config/Upgrade session. Any ideas on content is\n>         welcome.\n>         - I would like to add Congress / Policy to the Tuesday 1:30pm\n>         session along side Puppet, Chef, Salt, and Ansible. I think we\n>         are still missing someone to represent Salt.\n>         - I believe the Monday 10:30am Network session will be on the\n>         Nova.network to Neutron migration path. Any ideas on content\n>         is welcome.\n>         \n>         I am going to think some on the Deploy/Config/Upgrade session\n>         agenda and post it here for early discussion.\n>         \n>         ~ sean\n>         \n>         -------------- next part --------------\n>         An HTML attachment was scrubbed...\n>         URL:\n>         <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140818/3ca3c098/attachment-0001.html>\n>         \n>         ------------------------------\n>         \n>         _______________________________________________\n>         OpenStack-operators mailing list\n>         OpenStack-operators at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>         \n>         \n>         End of OpenStack-operators Digest, Vol 46, Issue 20\n>         ***************************************************\n> \n> \n> \n> \n> -- \n> Jeff Silverman\n> Systems Engineer\n> (253) 459-2318 (c)\n> \n> \n\n\n\n\n','<CAObtcxVyHMqxWD72Kp+xKHFSfMLBQMxbFL0EYDf+JQP2v4Q4Cw@mail.gmail.com>',NULL),('<1408477087.3819.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-19 19:36:05',0,'2014-08-19 19:36:05',NULL,'[Openstack-docs]  Neutron LBaaS Docs','The next iteration of Neutron LBaaS (we call it v2) was going to go in\nJuno.  However that has changed and it will be going into a neutron\nincubator.  It looks like changes to these docs have already been added\nin and replaced the docs for v1.  Now that v2 is going into the\nincubator, v1 will remain in the neutron tree.  What is the process to\nbut v1 docs back in?\n\nI\'m going off these docs:\nhttp://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html#treeDiv\n\nThose are definitely the documentation for v2.  We need that to go back\nto v1.\n\nLet me know what I need to do.\n\nThanks,\nBrandon\n\n',NULL,NULL),('<1408477925-sup-1880@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 19:55:02',0,'2014-08-19 19:55:02',NULL,'[openstack-dev] [TripleO] Future CI jobs','Excerpts from Derek Higgins\'s message of 2014-08-19 10:41:11 +0000:\n> Hi All,\n> \n>    I\'d like to firm up our plans around the ci jobs we discussed at the\n> tripleo sprint, at the time we jotted down the various jobs on an\n> etherpad, to better visualize the matrix of coverage I\'ve put it into a\n> spreadsheet[1]. Before we go about making these changes I\'d like to go\n> through a few questions for firm things up\n> \n> 1. Did we miss any jobs that we should have included?\n>    gfidente mentioned on IRC about adding blockstoragescale and\n> swiftstoragescale jobs into the mix, should we add this to the matrix so\n> at each is tested on at least one of the existing jobs?\n> \n> 2. Which jobs should run where? i.e. we should probably only aim to run\n> a subset of these jobs (possibly 1 fedora and 1 ubuntu?) on non tripleo\n> projects.\n> \n> 3. Are there any jobs here we should remove?\n> \n> 4. Is there anything we should add to the test matrix?\n>    Here I\'m thinking we should consider dependent libraries i.e. have at\n> least one job that uses the git version of dependent libraries rather\n> then the released library\n> \n> 5. On selinux we had said that we would set it to enforcing on Fedora\n> jobs, once its ready we can flick the switch. This may cause us\n> breakages as projects evolve but we can revisit if they are too frequent.\n> \n> Once anybody with an opinion has had had a chance to look over the\n> spreadsheet, I\'ll start to make changes to our existing jobs so that\n> they match jobs on the spreadsheet and then add the new jobs (one at a time)\n> \n> Feel free to add comments to the spreadsheet or reply here.\n> \n> thanks,\n> Derek\n> \n> [1]\n> https://docs.google.com/spreadsheets/d/1LuK4FaG4TJFRwho7bcq6CcgY_7oaGnF-0E6kcK4QoQc/edit?usp=sharing\n> \n\nLooks Great! One suggestion is that due to capacity issues we had a\nprioritization of these jobs and were going to walk down the list to add\nnew jobs as capacity became available. It might be a good idea to add a\ncolumn for this?\n\n-Greg\n\n\n','<53F329C7.1030402@redhat.com>',NULL),('<1408478128-sup-8192@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-19 19:58:24',0,'2014-08-19 19:58:24',NULL,'[openstack-dev] [TripleO] Future CI jobs','Excerpts from Giulio Fidente\'s message of 2014-08-19 12:07:53 +0000:\n> One last comment, maybe a bit OT but I\'m raising it here to see what is \n> the other people opinion: how about we modify the -ha job so that at \n> some point we actually kill one of the controllers and spawn a second \n> user image?\n\nI think this is a great long term goal, but IMO performing an update\nisnt really the type of verification we want for this kind of test. We\nreally should have some minimal tempest testing in place first so we can\nverify that when these types of failures occur our cloud remains in a\nfunctioning state.\n\n- Greg\n\n\n','<53F33E19.9020600@redhat.com>',NULL),('<1408479415.20390.YahooMailNeo@web142805.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-19 13:16:55',-25200,'2014-08-19 20:16:55',NULL,'[Openstack-operators] how can I make a new VM use the project\n	name as sub-domain ?','The dashboard makes the same API calls at the CLI clients, so it should be the same.\n\n-James\n?\n:)=\n\n\nOn Tuesday, August 19, 2014 9:18 AM, Ahmed Ali (ahmeali) <ahmeali at cisco.com> wrote:\n \n\n\n\n\nHi Alex, sorry I did not catch this email earlier, sub-domain can be part of the post script or user-data file, hostname is based on the name you provide during nova boot or a prefixed uuid if more than instance are provisioned. ??\n\nyou can use cloud-init and user data using APIs or ?Post-Creation? script from horizon, .\n\n\n?Examples for cloud-init and user-data:\n\nhttp://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/\n\nLook for?cloud-config-boot-cmds.txt?example, you can run any command to modify hostname\n\nCheers\nAhmed\n\n\nFrom: Alex Leonhardt <aleonhardt.py at gmail.com>\nDate: Sunday, August 17, 2014 at 2:09 AM\nTo: Ahmed Ali <ahmeali at cisco.com>\nCc: Abel Lopez <alopgeek at gmail.com>, openstack-operators <openstack-operators at lists.openstack.org>\nSubject: Re: [Openstack-operators] how can I make a new VM use the project name as sub-domain ?\n\n\nHi Ahmed, \n\nok, thanks - so where does the hostname thats displayed in Horizon come from / is being generated then ? The same domain across all networks is fine at the moment ;) ... we just need to add a \"sub-domain\" to hosts based on the project name.?\n\nThanks for your help!\nAlex\n\n\n\n\nOn 15 August 2014 17:31, Ahmed Ali (ahmeali) <ahmeali at cisco.com> wrote:\n\nIf you use dhcp_domain in nova it will be applied to all projects, IP ranges can be created per project or shared with other projects.\n>\n>\n>>> or do I simply change the OS\'s hostname config and the nova-api & horizon dashboard will pick that up ? ??\n>No, I do not think this will happen\n>\n>\n>Hostnames do not uniquely identify instances, it is the uuid.\n>\n>\n>As far as I know, If you want to custom define hostname and domain per instance it would be worth looking into cloud-init and user data using APIs, from horizon you can use ?Post-Creation? tab during launch instance wizard and provide a customization script.\n>\n>\n>Good luck\n>\n>\n>Ali\n>\n>\n>From: Alex Leonhardt <aleonhardt.py at gmail.com>\n>Date: Friday, August 15, 2014 at 7:08 AM\n>To: Ahmed Ali <ahmeali at cisco.com>\n>Cc: Abel Lopez <alopgeek at gmail.com>, openstack-operators <openstack-operators at lists.openstack.org> \n>\n>Subject: Re: [Openstack-operators] how can I make a new VM use the project name as sub-domain ?\n>\n>\n>\n>Hi,? \n>\n>\n>sorry still not quite what I\'m after ... so, when I use the Horizon Dashboard (or the nova api client) I can create a VM that will then get a name allocated based on what I named it, or, what I chose as a prefix if I want to provision 2 or more instances (uuidgen is used i guess).\n>\n>\n>as I will have the same domain + the same IP ranges set for all projects, there will eventually be 2 hosts would get the exact same name, if I were to put something in place that\'ll automatically update my DNS - how can I change nova/horizon to add a \".$project_name\" to a VM\'s name, or do I simply change the OS\'s hostname config and the nova-api & horizon dashboard will pick that up ??\n>\n>\n>Alex\n>\n>\n>\n>\n>\n>\n>\n>On 14 August 2014 23:59, Ahmed Ali (ahmeali) <ahmeali at cisco.com> wrote:\n>\n>Try to look into changing dhcp_domain in nova.conf to make it work, but will be for all instances.\n>>\n>>\n>>dhcp_domain = <domain> ??\n>>Note: <domain> is the domain name to use for building the hostnames\n>>\n>>\n>>Or look into cloud-init to customize FQDN per instance, see?http://docs.openstack.org/user-guide/content/user-data.html?\n>>\n>>\n>>Hope this is what you are looking for.\n>>\n>>\n>>Ali\n>>\n>>\n>>\n>>\n>>From: Alex Leonhardt <aleonhardt.py at gmail.com>\n>>Date: Thursday, August 14, 2014 at 3:08 PM\n>>To: Abel Lopez <alopgeek at gmail.com>\n>>Cc: openstack-operators <openstack-operators at lists.openstack.org>\n>>Subject: Re: [Openstack-operators] how can I make a new VM use the project name as sub-domain ?\n>>\n>>\n>>\n>>Hi Abel, \n>>\n>>\n>>Yep - I know - but question is, will the OS hostname automatically update the hostname displayed by Horizon when people are using the Dashboard ? Or, if not, how can I convince whatever is creating the VM ( nova-api ? ) to set the hostname as I require ??\n>>\n>>\n>>Alex\n>>\n>>\n>>\n>>\n>>\n>>On 14 August 2014 20:47, Abel Lopez <alopgeek at gmail.com> wrote:\n>>\n>>You can also pass user-data on Horizon, it\'s one of the window tabs in the launch instance dialog.? \n>>>\n>>>\n>>>On Thursday, August 14, 2014, Alex Leonhardt <aleonhardt.py at gmail.com> wrote:\n>>>\n>>>Thanks! \n>>>>\n>>>>\n>>>>What about the openstack dashboard - will it update the VM\'s hostname based on the OS\'s hostname that\'s set ??\n>>>>\n>>>>\n>>>>Alex\n>>>>\n>>>>\n>>>>\n>>>>On 14 August 2014 20:08, Abel Lopez <alopgeek at gmail.com> wrote:\n>>>>\n>>>>Some examples on using user-data \n>>>>>\n>>>>>\n>>>>>http://docs.openstack.org/user-guide/content/user-data.html\n>>>>>\n>>>>>\n>>>>>On Aug 14, 2014, at 11:48 AM, Alex Leonhardt <aleonhardt.py at gmail.com> wrote:\n>>>>>\n>>>>>hi all, \n>>>>>>\n>>>>>>\n>>>>>>am running openstack in a flat-network with just 1 IP range / network and would like to have the VMs\' named after the project, e.g.:\n>>>>>>\n>>>>>>\n>>>>>>project name: dev\n>>>>>>\n>>>>>>\n>>>>>>host name: redis1\n>>>>>>domain: acme.com\n>>>>>>\n>>>>>>\n>>>>>>resulting name: redis1.dev.acme.com\n>>>>>>\n>>>>>>\n>>>>>>at the moment i\'d just get a result of redis1.acme.com - but do want/need the sub-domains as?\n>>>>>>\n>>>>>>\n>>>>>>project: dev?\n>>>>>>and\n>>>>>>project: internal\n>>>>>>and\n>>>>>>project: frontend\n>>>>>>etc.\n>>>>>>\n>>>>>>\n>>>>>>may use the same name for things they work on ... how is this accomplished ? Or where do I have to look at (in the code) to try and make this a default ??\n>>>>>>\n>>>>>>\n>>>>>>Thanks a lot!\n>>>>>>Alex\n>>>>>>\n>>>>>>\n>>>>>>_______________________________________________\n>>>>>>OpenStack-operators mailing list\n>>>>>>OpenStack-operators at lists.openstack.org\n>>>>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>>>>\n>>>>>\n>>>>\n>>\n>\n\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140819/bc7f94c3/attachment.html>\n\n','<D018C19E.333B3%ahmeali@cisco.com>',NULL),('<1408504372.3965.4.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 03:12:26',0,'2014-08-20 03:12:26',NULL,'[openstack-dev] [Octavia] Agenda for 2014-08-20 meeting','After thinking about what can be done to start, because I hate being\nstagnant, I decided to create an etherpad of things that I think need\nmore discussion or can start working on now.\n\nhttps://etherpad.openstack.org/p/Octavia_Action_Items\n\nAdd on to this list if you know of others, as I am sure there are.  Add\ncomments on your opinions of existing items if you wish.  I think if we\nstart listing these things out, and getting a clearer picture, we can\nstart actual work on this.\n\nBeware, there is no order to these.  It\'s a smattering of my random\nthought process.  I\'m sure I have some obvious errors.\n\nThanks,\nBrandon\n\nOn Tue, 2014-08-19 at 14:31 -0700, Stephen Balukoff wrote:\n> I\'ve put the agenda for tomorrow\'s Octavia meeting on the wiki:\n>  https://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda#Agenda\n> \n> \n> Please feel free to edit it there and/or respond to this e-mail with\n> additional items if you would rather not edit the wiki.\n> \n> \n> Thanks,\n> Stephen\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+Zqb-AbLf8E-QXja-JB52ev9w=uWLmsZW=6ntJ_9N0t0eQ@mail.gmail.com>',NULL),('<1408531501.85557.YahooMailNeo@web194605.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 18:45:01',28800,'2014-08-20 10:45:01',NULL,'[openstack-dev] [TripleO] \'qemu-img: error while reading sector\n	xxxxxx: Input/Output error','Hi all,\n\nI have done a TripleO setup using RDO instack. Now,\nI am trying to deploy an overcloud on physical servers.\nI entered all the required parameters in deploy-baremetal-overcloudrc\nand when I ran instack-deploy-overcloud, I get the following?\nerror in nova-compute logs:\n\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] ? ? return processutils.execute(*cmd, **kwargs)\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] ? File \"/usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py\", line 193, in execute\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] ? ? cmd=\' \'.join(cmd))\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] ProcessExecutionError: Unexpected error while running command.\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] Command: qemu-img convert -O raw /mnt/state/var/lib/nova/instances/instance-00000022/disk.part /mnt/state/var/lib/nova/instances/instance-00000022/disk.converted\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] Exit code: 1\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] Stdout: \'\'\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6] Stderr: \'qemu-img: error while reading sector 962560: Input/output error\\n\'\n2014-08-20 06:35:43.483 16428 TRACE nova.compute.manager [instance: 774b5107-5504-4e99-bc77-af5abd8367d6]\n\nCAn anyone please help me with why am I getting\nthis error?\n\nRegards?\n~Peeyush Gupta\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140820/c0d6eadb/attachment.html>\n\n',NULL,NULL),('<1408540320.31115.181.camel@recto>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-20 09:12:00',-14400,'2014-08-20 13:12:00',NULL,'[Openstack-docs] [Openstack-i18n] Switch to itstool for docs\n translation?','On Wed, 2014-08-20 at 12:37 +0200, Andreas Jaeger wrote:\n> Shaun, it is not working in a virtual environment. To reproduce:\n> * Install python virtualenv package\n> * Run \"virtualenv its\"\n> * Run \"source its/bin/activate\" to use the virtualenv\n> * Run now in the virtualenv \"pip install itstool\"\n> \n> It fails with:\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> error: could not create \'/usr/share/itstool\': Permission denied\n> \n> ----------------------------------------\n> Cleaning up...\n> Command /tmp/its/bin/python -c \"import\n> setuptools;__file__=\'/tmp/itstools/build/itstool/setup.py\';exec(compile(open(__file__).read().replace(\'\\r\\n\',\n> \'\\n\'), __file__, \'exec\'))\" install --record\n> /tmp/pip-M39Dm9-record/install-record.txt\n> --single-version-externally-managed --install-headers\n> /tmp/itstools/include/site/python2.7 failed with error code 1 in\n> /tmp/its/build/itstool\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> \n> I suggest to not use \'/usr/share/itstool/its\' in setup.py. Changing this\n> to \'itstool/its\' fixed it for me.\n\nIt scares me a bit to have different versions of the same package\nputting files in different places (pypi package vs upstream tarball).\nBut that\'s probably live-with-able.\n\n> But then it failed with a missing dependency on libxml2. It would be\n> great if the tool could live without the dependency and use lxml\n> instead, otherwise it needs to be setup using site-packages\n> (--system-site-packages)\n\nBut this is a complete non-starter. itstool does rather intricate things\nwith XML. It\'s quite a bit more than parse-and-forget. To change it to\nuse lxml would require a complete rewrite, and I\'m not even sure it can\nbe done. Most XML libraries don\'t let you shoot yourself in the foot as\neasily as libxml2 does.\n\n> We cannot move forward unless itstool can be executed in a virtual\n> environment (using site packages is possible but not desired).\n> \n> Shaun, could you take care of uploading a fixed package, please?\n\nIt\'s unfortunate the servers don\'t just have >=2.0.1. It\'s been out for\na while now. This isn\'t high on my list right now, and it\'s too late in\nthe release cycle to switch anyway. I\'ll get back to it after Juno.\n\n--\nShaun\n\n\n\n\n\n\n','<53F47A4C.8090707@suse.com>',NULL),('<1408550169.3819.8.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 15:54:02',0,'2014-08-20 15:54:02',NULL,'[openstack-dev] [Neutron][LBaaS] Error at context exit for\n subnet in unit test case','Hey Vijay,\nFigured out the issue you are having.  In that particular test you are\ncreating the same subnet twice.  The first time you create it is in the\ncontextlib.nested, the second time is the self.loadbalancer method that\nwill create a subnet if you do not pass it.  So you should pass\nsubnet=subnet in the self.loadbalancer method.\n\nAfter that there are other minor issues in the driver, mainly accessing\nthe obj passed in as a dictionary and not an object (obj[\"id\"] vs\nobj.id).\n\nLet me know if you need more information.\n\nThanks,\nBrandon\nOn Wed, 2014-08-20 at 14:27 +0000, Vijay Venkatachalam wrote:\n> I observed the following text as well \"One or more ports have an IP allocation from this subnet.\"\n> Looks like loadbalancer context exit at \"blah2\" is not cleaning up the port that was created. \n> This ultimately resulted in failure of delete subnet at \"blah3\".\n> \n> ----------------------\n> with self.subnet() as subnet:\n>     blah1\n>     with self.loadbalancer() as lb:\n>         blah2\n>     blah3\n> ----------------------\n> \n> -----Original Message-----\n> From: Vijay Venkatachalam [mailto:Vijay.Venkatachalam at citrix.com] \n> Sent: 20 August 2014 19:12\n> To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org)\n> Subject: [openstack-dev] [Neutron][LBaaS] Error at context exit for subnet in unit test case\n> \n> Hi,\n> \n> I am writing a unit testcase with context as subnet, code here [1]. \n> When the context exits a delete of subnet is attempted and I am getting a MismatchError . Traceback posted here [2]. \n> \n> What could be going wrong here?\n> \n> Testcase is written like the following\n> ----------------------\n> with self.subnet() as subnet:\n>     blah1\n>     blah2\n>     blah3\n> ----------------------\n> \n> I am getting a \"MismatchError: 409 != 204\" error at blah3 when context exits.\n> \n> [1] UnitTestCase Snippet - http://pastebin.com/rMtf2dQX [2] Traceback  - http://pastebin.com/2sPcZ8Jk\n> \n> \n> Thanks,\n> Vijay V.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<26B082831A2B1A4783604AB89B9B2C080E0C41E0@SINPEX01CL03.citrite.net>',NULL),('<1408556019-sup-4339@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 17:35:00',0,'2014-08-20 17:35:00',NULL,'[openstack-dev] [TripleO] Future CI jobs','Excerpts from Derek Higgins\'s message of 2014-08-20 09:06:48 +0000:\n> On 19/08/14 20:58, Gregory Haynes wrote:\n> > Excerpts from Giulio Fidente\'s message of 2014-08-19 12:07:53 +0000:\n> >> One last comment, maybe a bit OT but I\'m raising it here to see what is \n> >> the other people opinion: how about we modify the -ha job so that at \n> >> some point we actually kill one of the controllers and spawn a second \n> >> user image?\n> > \n> > I think this is a great long term goal, but IMO performing an update\n> > isnt really the type of verification we want for this kind of test. We\n> > really should have some minimal tempest testing in place first so we can\n> > verify that when these types of failures occur our cloud remains in a\n> > functioning state.\n> \n> Greg, you said \"performing an update\" did you mean \"killing a controller\n> node\" ?\n> \n> if so I agree, verifying our cloud is still in a working order with\n> tempest would get us more coverage then spawning a node. So once we have\n> tempest in place we can add a test to kill a controller node.\n> \n\nAh, I misread the original message a bit, but sounds like were all on\nthe same page.\n\n\n','<53F46528.6030205@redhat.com>',NULL),('<1408579431.2849857.155013069.5605A378@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 17:03:51',-25200,'2014-08-21 00:03:51',NULL,'[openstack-dev] [neutron][all] switch from mysqldb to another\n eventlet aware mysql client','On Mon, Aug 18, 2014, at 01:59 AM, Ihar Hrachyshka wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> On 17/08/14 02:09, Angus Lees wrote:\n> > \n> > On 16 Aug 2014 06:09, \"Doug Hellmann\" <doug at doughellmann.com \n> > <mailto:doug at doughellmann.com>> wrote:\n> >> \n> >> \n> >> On Aug 15, 2014, at 9:29 AM, Ihar Hrachyshka\n> >> <ihrachys at redhat.com\n> > <mailto:ihrachys at redhat.com>> wrote:\n> >> \n> >>> Signed PGP part Some updates on the matter:\n> >>> \n> >>> - oslo-spec was approved with narrowed scope which is now\n> >>> \'enabled mysqlconnector as an alternative in gate\' instead of\n> >>> \'switch the default db driver to mysqlconnector\'. We\'ll revisit\n> >>> the switch part the next cycle once we have the new driver\n> >>> running in gate and real benchmarking is heavy-lifted.\n> >>> \n> >>> - there are several patches that are needed to make devstack\n> >>> and tempest passing deployment and testing. Those are collected\n> >>> under the hood of: https://review.openstack.org/#/c/114207/ Not\n> >>> much of them.\n> >>> \n> >>> - we\'ll need a new oslo.db release to bump versions (this is\n> >>> needed to set raise_on_warnings=False for the new driver, which\n> >>> was incorrectly set to True in sqlalchemy till very recently).\n> >>> This is expected to be released this month (as per Roman\n> >>> Podoliaka).\n> >> \n> >> This release is currently blocked on landing some changes in\n> >> projects\n> > using the library so they don?t break when the new version starts\n> > using different exception classes. We?re tracking that work in \n> > https://etherpad.openstack.org/p/sqla_exceptions_caught\n> >> \n> >> It looks like we?re down to 2 patches, one for cinder\n> > (https://review.openstack.org/#/c/111760/) and one for glance \n> > (https://review.openstack.org/#/c/109655). Roman, can you verify\n> > that those are the only two projects that need changes for the\n> > exception issue?\n> >> \n> >>> \n> >>> - once the corresponding patch for sqlalchemy-migrate is\n> >>> merged, we\'ll also need a new version released for this.\n> > \n> > So we\'re going for a new version of sqlalchemy?  (We have a\n> > separate workaround for raise_on_warnings that doesn\'t require the\n> > new sqlalchemy release if this brings too many other issues)\n> \n> Wrong. We\'re going for a new version of *sqlalchemy-migrate*. Which is\n> the code that we inherited from Mike and currently track in stackforge.\n> \n> > \n> >>> - on PyPI side, no news for now. The last time I\'ve heard from\n> >>> Geert (the maintainer of MySQL Connector for Python), he was\n> >>> working on this. I suspect there are some legal considerations\n> >>> running inside Oracle. I\'ll update once I know more about\n> >>> that.\n> >> \n> >> If we don?t have the new package on PyPI, how do we plan to\n> >> include it\n> > in the gate? Are there options to allow an exception, or to make\n> > the mirroring software download it anyway?\n> > \n> > We can test via devstack without waiting for pypi, since devstack\n> > will install via rpms/debs.\n> \n> I expect that it will be settled. I have no indication that the issue\n> is unsolvable, it will just take a bit more time than we\'re accustomed\n> to. :)\n> \n> At the moment, we install MySQLdb from distro packages for devstack.\n> Same applies to new driver. It will be still great to see the package\n> published on PyPI so that we can track its version requirements\n> instead of relying on distros to package it properly. But I don\'t see\n> it as a blocker.\n> \n> Also, we will probably be able to run with other drivers supported by\n> SQLAlchemy once all the work is done.\n> \nSo I got bored last night and decided to take a stab at making PyMySQL\nwork since I was a proponent of it earlier. Thankfully it did just\nmostly work like I thought it would.\nhttps://review.openstack.org/#/c/115495/ is the WIP devstack change to\ntest this out.\n\nPostgres tests fail because it was applying the pymysql driver to the\npostgres connection string. We can clean this up later in devstack\nand/or devstack-gate depending on how we need to apply this stuff.\nBashate failed because I had to \"monkeypatch\" in a fix for a ceilometer\nissue loading sqlalchemy drivers. The tempest neutron full job fails on\none test occasionally. Not sure yet if that is normal neutron full\nfailure mode or if a new thing from PyMySQL. The regular tempest job\npasses just fine.\n\nThere are also some DB related errors in the logs that will need to be\ncleaned up but overall it just works. So I would like to repropose that\nwe stop focusing all of this effort on the hard thing and use the easy\nthing if it meets our needs. We can continue to make alternatives work,\nbut that is a different problem that we can solve at a different pace. I\nam not sure how to test the neutron thing that Gus was running into\nthough so we should also check that really quickly.\n\nAlso, the tests themselves don\'t seem to run any faster or slower than\nwhen using the default mysql driver. Hard to complain about that :)\n\nClark\n> > \n> > - Gus\n> > \n> > \n> > \n> > _______________________________________________ OpenStack-dev\n> > mailing list OpenStack-dev at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> \n> iQEcBAEBCgAGBQJT8cCDAAoJEC5aWaUY1u57YgQH/0T6QxHfYv0NUWh95AOS4U24\n> YQ70/A5RD41rn+b/+RU27B97WCY7kJDSn//tfW+THFTZFWZDLy/g2AuXKkbTT3DU\n> 4DTEIvkk4pTtmUhRGLDp4hVWnZ/wKMq1Xtu+jtuXEvz0dcSxgtzwKE3auJ1fD/SL\n> gZPhUQwPpdQASQo8DSh1iziftlpTzvmhsvAAexvDRFdpZs87b7VTH2AFLYRgW47P\n> 07eow5WL9KprR+Yxfg680A9GoghtB0ffGLvQmdnfOaln+MRx51ywTcq3RKeUU4RH\n> fgJjddZOPsKhHHPHEwak8+qd2iZ/AvUh0OvkZ3QqX9Dj3ZcpYnJYMApHQNvnebw=\n> =n5u7\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53F1C083.1060405@redhat.com>',NULL),('<1408580114.2852077.155017545.1D395D92@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 17:15:14',-25200,'2014-08-21 00:15:14',NULL,'[openstack-dev] [All] Switching default test node to Trusty for\n all projects and upgrading tox to version 1.7.2','On Tue, Aug 5, 2014, at 05:04 PM, Clark Boylan wrote:\n> Hello,\n> \n> On August 20th the Infra team will be switching the default test node\n> from Ubuntu Precise to Ubuntu Trusty. This means that `tox -epy27`, `tox\n> -ecover`, `tox -epep8`, `tox -evenv -- python setup.py build_sphinx`\n> will run on Trusty build nodes intead of Precise nodes. This will not\n> affect python 2.6 or 3.3 tests as they will remain on Centos6 and\n> Precise as that is where those python versions are available.\n> \n> Many projects have made the the switch to Trusty already and it has been\n> painless for the most part. The only things we have run into so far are\n> apache 2.2 vs apache 2.4 differences and Solum had rabbitmq problems in\n> their functional test on Trusty (this test will not move to Trusty as\n> part of this). If your project has not already made the transition to\n> Trusty you can make sure you are prepared by running `tox -epy27`, `tox\n> -epep8`, and `tox -evenv -- python setup.py build_sphinx`. I have been\n> trying to do this for as many projects as I can but only have so much\n> time :) your help is appreciated.\n> \n> We will also be upgrading tox on our test slaves to tox 1.7.2. We have\n> pinned to version 1.6.1 for a long time because 1.7.0 broke\n> compatibility with many of our tox.ini files. That problem has since\n> been fixed but another minor issue has cropped up in 1.7.0. Details are\n> at\n> http://lists.openstack.org/pipermail/openstack-dev/2014-July/041283.html.\n> TL;DR is if your tests cannot handle a random python hashseed value you\n> will need to fix your tests or merge a change like\n> https://review.openstack.org/#/c/109700/ to your project. Again, I have\n> done my best to poke at this for as many projects as I can but there are\n> so many of them. Your help is appreciated with this as well.\n> \n> Upgrading tox is important so that we can stop relying on a specific\n> version of tox that developers need to know to install. It will also\n> allow us to move our py33 testing to py34 on Trusty which gives python3\n> testing a long term home.\n> \n> If you have any questions let me know. Thanks again,\n> Clark\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThis work is mostly done. The switch to trusty by default is in for\neveryone now. The tox upgrade is mostly complete but won\'t be done\neverywhere until I have completed rebuilding all of our nodepool images\nand then let nodes built on the old image cycle out. This should be done\nshortly.\n\nPlease do let us know if you see oddness. Happy to help work through\nanything that I missed when testing this stuff.\n\nClark\n\n\n','<1407283479.108844.149561037.285E0C1D@webmail.messagingengine.com>',NULL),('<1408581266.61285.YahooMailNeo@web160301.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-20 17:34:26',-25200,'2014-08-21 00:34:26',NULL,'[Openstack-docs] Networking Guide','Regarding the Networking Guide, I made a rough start on the Scalability HA chapter at the Australian docs swarm, and not really clear what should be in there. You can see the patch here:\nhttps://review.openstack.org/#/c/113076/5\n\n\nNick clarified that it should explain DVR ?concepts and setting it up to work with Neutron. The only information I\'ve found on DVR is:\nhttps://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent\n\nhttps://wiki.openstack.org/wiki/Neutron/DVR/HowTo\n\n\nThe chapter needs a lot more work. Who would be the SMEs I can contact for input and answer questions?\n\nCheers,\nDarren\n\n\n\nOn Friday, 15 August 2014 5:11 AM, Nicholas Chase <nchase at mirantis.com> wrote:\n \n\n\nJust wanted to take a minute to bring everybody up-to-speed on the status of the Networking Guide.\n\nAs many of you know, we are in the process of creating the OpenStack\n    Networking Guide, which is intended to create a resource for those\n    who may not have a deep networking background but now find\n    themselves enmeshed in OpenStack -- in other words, drowning.\n\nThe group actively working on it includes Shaun McCance, Phil\n    Hopkins, and Matt Kassawara, with me sort of hovering and making\n    sure things don\'t get stuck.? We are trying to hold weekly status\n    meetings at 11am EDT on Fridays; if anyone wants to attend, please\n    let me know and I\'ll make sure you get an invite.? (We\'re using\n    Google Hangout.)\n\nShaun has put together a spec for the document, which you can find\n    here:? https://review.openstack.org/#/c/113597/\n\nAs you can see in that document, we\'ve explicitly decided to focus\n    on Neutron, since nova-network is covered elsewhere and the urgency\n    of completing this for the Juno release is high due to the risk of\n    de-integration of the Neutron if we don\'t get it properly\n    documented.\n\nThe guide itself is in git, with everything else, at https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide\n\nIf anyone has any questions or feedback, we\'d love to hear it.\n\nThanks!\n\n----? Nick\n\n\n-- \nNick Chase \n1-650-567-5640\nTechnical Marketing Manager, Mirantis\nEditor, OpenStack:Now\n\n_______________________________________________\nOpenstack-docs mailing list\nOpenstack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140820/41c44342/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: www.openstacksv.com_.png\nType: image/png\nSize: 7160 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140820/41c44342/attachment-0001.png>\n\n','<53ED09BB.3030800@mirantis.com>',NULL),('<1408585245-sup-5459@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 20:33:33',-25200,'2014-08-21 03:33:33',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Robert Collins\'s message of 2014-08-18 23:41:20 -0700:\n> On 18 August 2014 09:32, Clint Byrum <clint at fewbar.com> wrote:\n> \n> I can see your perspective but I don\'t think its internally consistent...\n> \n> > Here\'s why folk are questioning Ceilometer:\n> >\n> > Nova is a set of tools to abstract virtualization implementations.\n> \n> With a big chunk of local things - local image storage (now in\n> glance), scheduling, rebalancing, ACLs and quotas. Other\n> implementations that abstract over VM\'s at various layers already\n> existed when Nova started - some bad ( some very bad!) and others\n> actually quite ok.\n> \n\nThe fact that we have local implementations of domain specific things is\nirrelevant to the difference I\'m trying to point out. Glance needs to\nwork with the same authentication semantics and share a common access\ncatalog to work well with Nova. It\'s unlikely there\'s a generic image\ncatalog that would ever fit this bill. In many ways glance is just an\nabstraction of file storage backends and a database to track a certain\ndomain of files (images, and soon, templates and other such things).\n\nThe point of mentioning Nova is, we didn\'t write libvirt, or xen, we\nwrote an abstraction so that users could consume them via a REST API\nthat shares these useful automated backends like glance.\n\n> > Neutron is a set of tools to abstract SDN/NFV implementations.\n> \n> And implements a DHCP service, DNS service, overlay networking : its\n> much more than an abstraction-over-other-implementations.\n> \n\nNative DHCP and overlay? Last I checked Neutron used dnsmasq and\nopenvswitch, but it has been a few months, and I know that is an eon in\nOpenStack time.\n\n> > Cinder is a set of tools to abstract block-device implementations.\n> > Trove is a set of tools to simplify consumption of existing databases.\n> > Sahara is a set of tools to simplify Hadoop consumption.\n> > Swift is a feature-complete implementation of object storage, none of\n> > which existed when it was started.\n> \n> Swift was started in 2009; Eucalyptus goes back to 2007, with Walrus\n> part of that - I haven\'t checked precise dates, but I\'m pretty sure\n> that it existed and was usable by the start of 2009. There may well be\n> other object storage implementations too - I simply haven\'t checked.\n> \n\nIndeed, and MogileFS was sort of like Swift but not HTTP based. Perhaps\nWalrus was evaluated and inadequate for the CloudFiles product\nrequirements? I don\'t know. But there weren\'t de-facto object stores\nat the time because object stores were just becoming popular.\n\n> > Keystone supports all of the above, unifying their auth.\n> \n> And implementing an IdP (which I know they want to stop doing ;)). And\n> in fact lots of OpenStack projects, for various reasons support *not*\n> using Keystone (something that bugs me, but thats a different\n> discussion).\n> \n\nMy point was it is justified to have a whole implementation and not\njust abstraction because it is meant to enable the ecosystem, not _be_\nthe ecosystem. I actually think Keystone is problematic too, and I often\nwonder why we haven\'t just do OAuth, but I\'m not trying to throw every\nproject under the bus. I\'m trying to state that we accept Keystone because\nit has grown organically to support the needs of all the other pieces.\n\n> > Horizon supports all of the above, unifying their GUI.\n> >\n> > Ceilometer is a complete implementation of data collection and alerting.\n> > There is no shortage of implementations that exist already.\n> >\n> > I\'m also core on two projects that are getting some push back these\n> > days:\n> >\n> > Heat is a complete implementation of orchestration. There are at least a\n> > few of these already in existence, though not as many as their are data\n> > collection and alerting systems.\n> >\n> > TripleO is an attempt to deploy OpenStack using tools that OpenStack\n> > provides. There are already quite a few other tools that _can_ deploy\n> > OpenStack, so it stands to reason that people will question why we\n> > don\'t just use those. It is my hope we\'ll push more into the \"unifying\n> > the implementations\" space and withdraw a bit from the \"implementing\n> > stuff\" space.\n> >\n> > So, you see, people are happy to unify around a single abstraction, but\n> > not so much around a brand new implementation of things that already\n> > exist.\n> \n> If the other examples we had were a lot purer, this explanation would\n> make sense. I think there\'s more to it than that though :).\n> \n\nIf purity is required to show a difference, then I don\'t think I know\nhow to demonstrate what I think is obvious to most of us: Ceilometer\nis an end to end implementation of things that exist in many battle\ntested implementations. I struggle to think of another component of\nOpenStack that has this distinction.\n\n> What exactly, I don\'t know, but its just too easy an answer, and one\n> that doesn\'t stand up to non-trivial examination :(.\n> \n> I\'d like to see more unification of implementations in TripleO - but I\n> still believe our basic principle of using OpenStack technologies that\n> already exist in preference to third party ones is still sound, and\n> offers substantial dogfood and virtuous circle benefits.\n> \n\nRight, agree 100%. What I\'m trying to say is, because we are using the TC\napproved \"winners\", the unknowns and the \"not developed in our ecosystem\"\ntools are all framed as losers. Given that, it should come as no surprise\nthat we have no other tools participating themselves.\n\nIn fact, we ourselves have just barely toyed with things like Ansible\nreplacing bits and pieces, and it has been met with immediate suspicion\nby our community (sorry Steve Baker, I\'m struggling to come up with\nbetter words to characterize your well intentioned questions).\n\n\n','<CAJ3HoZ1XWXqoyoG15fYr3DtzY_gGPgAiPBsp_g-AbjG0qkcq7w@mail.gmail.com>',NULL),('<1408592196-sup-4423@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-20 20:54:34',-25200,'2014-08-21 03:54:34',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Jay Pipes\'s message of 2014-08-20 14:53:22 -0700:\n> On 08/20/2014 05:06 PM, Chris Friesen wrote:\n> > On 08/20/2014 07:21 AM, Jay Pipes wrote:\n> >> Hi Thierry, thanks for the reply. Comments inline. :)\n> >>\n> >> On 08/20/2014 06:32 AM, Thierry Carrez wrote:\n> >>> If we want to follow your model, we probably would have to dissolve\n> >>> programs as they stand right now, and have blessed categories on one\n> >>> side, and teams on the other (with projects from some teams being\n> >>> blessed as the current solution).\n> >>\n> >> Why do we have to have \"blessed\" categories at all? I\'d like to think of\n> >> a day when the TC isn\'t picking winners or losers at all. Level the\n> >> playing field and let the quality of the projects themselves determine\n> >> the winner in the space. Stop the incubation and graduation madness and\n> >> change the role of the TC to instead play an advisory role to upcoming\n> >> (and existing!) projects on the best ways to integrate with other\n> >> OpenStack projects, if integration is something that is natural for the\n> >> project to work towards.\n> >\n> > It seems to me that at some point you need to have a recommended way of\n> > doing things, otherwise it\'s going to be *really hard* for someone to\n> > bring up an OpenStack installation.\n> \n> Why can\'t there be multiple recommended ways of setting up an OpenStack \n> installation? Matter of fact, in reality, there already are multiple \n> recommended ways of setting up an OpenStack installation, aren\'t there?\n> \n> There\'s multiple distributions of OpenStack, multiple ways of doing \n> bare-metal deployment, multiple ways of deploying different message \n> queues and DBs, multiple ways of establishing networking, multiple open \n> and proprietary monitoring systems to choose from, etc. And I don\'t \n> really see anything wrong with that.\n> \n\nThis is an argument for loosely coupling things, rather than tightly\nintegrating things. You will almost always win my vote with that sort of\nmovement, and you have here. +1.\n\n> > We already run into issues with something as basic as competing SQL\n> > databases.\n> \n> If the TC suddenly said \"Only MySQL will be supported\", that would not \n> mean that the greater OpenStack community would be served better. It \n> would just unnecessarily take options away from deployers.\n> \n\nThis is really where \"supported\" becomes the mutex binding us all. The\nmore \"supported\" options, the larger the matrix, the more complex a\nuser\'s decision process becomes.\n\n>  > If every component has several competing implementations and\n> > none of them are \"official\" how many more interaction issues are going\n> > to trip us up?\n> \n> IMO, OpenStack should be about choice. Choice of hypervisor, choice of \n> DB and MQ infrastructure, choice of operating systems, choice of storage \n> vendors, choice of networking vendors.\n> \n\nErr, uh. I think OpenStack should be about users. If having 400 choices\nmeans users are just confused, then OpenStack becomes nothing and\neverything all at once. Choices should be part of the whole not when 1%\nof the market wants a choice, but when 20%+ of the market _requires_\na choice.\n\nWhat we shouldn\'t do is harm that 1%\'s ability to be successful. We should\nfoster it and help it grow, but we don\'t just pull it into the program and\nsay \"You\'re ALSO in OpenStack now!\" and we also don\'t want to force those\nusers to make a hard choice because the better solution is not blessed.\n\n> If there are multiple actively-developed projects that address the same \n> problem space, I think it serves our OpenStack users best to let the \n> projects work things out themselves and let the cream rise to the top. \n> If the cream ends up being one of those projects, so be it. If the cream \n> ends up being a mix of both projects, so be it. The production community \n> will end up determining what that cream should be based on what it \n> deploys into its clouds and what input it supplies to the teams working \n> on competing implementations.\n> \n\nI\'m really not a fan of making it a competitive market. If a space has a\ndiverse set of problems, we can expect it will have a diverse set of\nsolutions that overlap. But that doesn\'t mean they both need to drive\ntoward making that overlap all-encompassing. Sometimes that happens and\nit is good, and sometimes that happens and it causes horrible bloat.\n\n> And who knows... what works or is recommended by one deployer may not be \n> what is best for another type of deployer and I believe we (the \n> TC/governance) do a disservice to our user community by picking a winner \n> in a space too early (or continuing to pick a winner in a clearly \n> unsettled space).\n> \n\nRight, I think our current situation crowds out diversity, when what we\nwant to do is enable it, without confusing the users.\n\n\n','<53F518D2.3090701@gmail.com>',NULL),('<1408635940.4451.24.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 17:45:40',7200,'2014-08-21 15:45:40',NULL,'[openstack-dev] [neutron][ml2] Openvswitch agent support for non\n promic mode adapters','Hi, \nlast week I started discussing an extension to the existing neutron\nopenvswitch agent to support network adapters that are not in\npromiscuous mode. Now I would like to enhance the round to get feedback\nfrom a broader audience via the mailing list.\n\n\nThe Problem\nWhen driving vlan or flat networking, openvswitch requires an network\nadapter in promiscuous mode. \n\n\nWhy not having promiscuous mode in your adapter?\n- Admins like to have full control over their environment and which\nnetwork packets enter the system.\n- The network adapter just does not have support for it.\n\n\nWhat to do?\nLinux net-dev driver offer an interface to manually register additional\nmac addresses (also called secondary unicast addresses). Exploiting this\none can register additional mac addresses to the network adapter. This\nalso works via a well known ip user space tool. \n\n`bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`\n\n\nWhat to do in openstack?\nAs neutron is aware of all the mac addresses that are in use it\'s the\nperfect candidate for doing the mac registrations. The idea is to modify\nthe neutron openvswitch agent that it does the registration on \"port\nadd\" and \"port remove\" via the bridge command.\nThere would be a new optional configuration parameter, something like\n\'non-promisc-mode\' that is by default set to false. Only when set to\ntrue, macs get manually registered. Otherwise the agent behaves like it\ndoes today. So I guess only very little changes to the agent code are\nrequired. From my current point of view we do not need any changes to\nthe ml2 plug-in.\n\n\nBlueprint or a bug?\nI guess it\'s a blueprint.\n\nWhat\'s the timeframe?\nK would be great.\n\n\n\nI would be thankful for any feedback on this! Feel free to contact me\nanytime. Thanks in advance!\n\nRegards, \nAndreas\n\n(irc: scheuran)\n\n\n\n',NULL,NULL),('<1408639059.4076189.155286477.6F5A9EA2@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 09:37:39',-25200,'2014-08-21 16:37:39',NULL,'[openstack-dev] [nova][libvirt] Non-readonly connection to\n libvirt in unit tests','\n\nOn Thu, Aug 21, 2014, at 09:25 AM, Matt Riedemann wrote:\n> \n> \n> On 8/21/2014 10:23 AM, Daniel P. Berrange wrote:\n> > On Thu, Aug 21, 2014 at 11:14:33AM -0400, Solly Ross wrote:\n> >> (reply inline)\n> >>\n> >> ----- Original Message -----\n> >>> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> >>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> >>> Sent: Thursday, August 21, 2014 11:05:18 AM\n> >>> Subject: Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests\n> >>>\n> >>> On Thu, Aug 21, 2014 at 10:52:42AM -0400, Solly Ross wrote:\n> >>>> FYI, the context of this is that I would like to be able to test some\n> >>>> of the libvirt storage pool code against a live file system, as we\n> >>>> currently test the storage pool code.  To do this, we need at least to\n> >>>> be able to get a proper connection to a session daemon.  IMHO, since\n> >>>> these calls aren\'t \"expensive\", so to speak, it should be fine to have\n> >>>> them run against a real libvirt.\n> >>>\n> >>> No it really isn\'t OK to run against the real libvirt host system when\n> >>> in the unit tests. Unit tests must *not* rely on external system state\n> >>> in this way because it will lead to greater instability and unreliability\n> >>> of our unit tests. If you want to test stuff against the real libvirt\n> >>> storage pools then that becomes a functional / integration test suite\n> >>> which is pretty much what tempest is targetting.\n> >>\n> >> That\'s all well and good, but we *currently* manipulates the actual file\n> >> system manually in tests.  Should we then say that we should never manipulate\n> >> the actual file system either?  In that case, there are some tests which\n> >> need to be refactored.\n> >\n> > Places where the tests manipulate the filesystem though should be doing\n> > so in an isolated playpen directory, not in the \"live\" location where\n> > a deployed nova runs, so that\'s not the same thing.\n> >\n> >>>>> So If we require libvirt-python for tests and that requires\n> >>>>> libvirt-bin, what\'s stopping us from just removing fakelibvirt since\n> >>>>> it\'s kind of useless now anyway, right?\n> >>>>\n> >>>> The thing about fakelibvirt is that it allows us to operate against\n> >>>> against a libvirt API without actually doing libvirt-y things like\n> >>>> launching VMs.  Now, libvirt does have a \"test:///default\" URI that\n> >>>> IIRC has similar functionality, so we could start to phase out fake\n> >>>> libvirt in favor of that.  However, there are probably still some\n> >>>> spots where we\'ll want to use fakelibvirt.\n> >>>\n> >>> I\'m actually increasingly of the opinion that we should not in fact\n> >>> be trying to use the real libvirt library in the unit tests at all\n> >>> as it is not really adding any value. We typically nmock out all the\n> >>> actual API calls we exercise so despite \"using\" libvirt-python we\n> >>> are not in fact exercising its code or even validating that we\'re\n> >>> passing the correct numbers of parameters to API calls. Pretty much\n> >>> all we really relying on is the existance of the various global\n> >>> constants that are defined, and that has been nothing but trouble\n> >>> because the constants may or may not be defined depending on the\n> >>> version.\n> >>\n> >> Isn\'t that what \'test:///default\' is supposed to be?  A version of libvirt\n> >> with libvirt not actually touching the rest of the system?\n> >\n> > Yes, that is what it allows for, however, even if we used that URI we\n> > still wouldn\'t be actually exercising any of the libvirt code in any\n> > meaningful way because our unit tests mock out all the API calls that\n> > get touched. So using libvirt-python + test:///default URI doesn\'t\n> > really seem to buy us anything, but it does still mean that developers\n> > need to have libvirt installed in order to run  the unit tests. I\'m\n> > not convinced that is a beneficial tradeoff.\n> >\n> >>> The downside of fakelibvirt is that it is a half-assed implementation\n> >>> of libvirt that we evolve in an adhoc fashion. I\'m exploring the idea\n> >>> of using pythons introspection abilities to query the libvirt-python\n> >>> API and automatically generate a better \'fakelibvirt\' that we can\n> >>> guarantee to match the signatures of the real libvirt library. If we\n> >>> had something like that which we had more confidence in, then we could\n> >>> make the unit tests use that unconditionally. This would make our unit\n> >>> tests more reliable since we would not be suspectible to different API\n> >>> coverage in different libvirt module versions which have tripped us up\n> >>> so many times\n> >\n> > Regards,\n> > Daniel\n> >\n> \n> +1000 to removing the need to have libvirt installed to run unit tests, \n> but that\'s what I\'m seeing today unless I\'m mistaken since we require \n> libvirt-python which requires libvirt as already pointed out.\n> \n> If you revert the change to require libvirt-python and try to run the \n> unit tests, it fails, see bug 1357437 [1].\n> \n> [1] https://bugs.launchpad.net/nova/+bug/1357437\n> \nReverting the change to require libvirt-python is insufficient. That\nrevert will flip back to using system packages and include libvirt\npython lib from your operating system. Libvirt will still be required\njust via a different avenue (nova does try to fall back on its fake\nlibvirt but iirc that doesn\'t always work so well).\n\nIf you want to stop depending on libvirt in unittests you should remove\nthe libvirt-python requirement and not try to use the system package\ninstalled version of libvirt. Then the fake libvirt will have to keep\nworking and will be tested in the gate.\n\nClark\n\n\n','<53F61D6A.4060603@linux.vnet.ibm.com>',NULL),('<1408640680-sup-2369@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 10:18:15',-25200,'2014-08-21 17:18:15',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Duncan Thomas\'s message of 2014-08-21 09:21:06 -0700:\n> On 21 August 2014 14:27, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > Specifically for Triple-O, by making the Deployment program == Triple-O, the\n> > TC has picked the disk-image-based deployment of an undercloud design as The\n> > OpenStack Way of Deployment. And as I\'ve said previously in this thread, I\n> > believe that the deployment space is similarly unsettled, and that it would\n> > be more appropriate to let the Chef cookbooks and Puppet modules currently\n> > sitting in the stackforge/ code namespace live in the openstack/ code\n> > namespace.\n> \n> Totally agree with Jay here, I know people who gave up on trying to\n> get any official project around deployment because they were told they\n> had to do it under the TripleO umbrella\n> \n\nThis was why the _program_ versus _project_ distinction was made. But\nI think we ended up being 1:1 anyway.\n\nPerhaps the deployment program\'s mission statement is too narrow, and\nwe should iterate on that. That others took their ball and went home,\ninstead of asking for a review of that ruling, is a bit disconcerting.\n\nThat probably strikes to the heart of the current crisis. If we were\nbeing reasonable, alternatives to an official OpenStack program\'s mission\nstatement would be debated and considered thoughtfully. I know I made the\nmistake early on of pushing the narrow _TripleO_ vision into what should\nhave been a much broader \"Deployment\" program. I\'m not entirely sure why\nthat seemed o-k to me at the time, or why it was allowed to continue, but\nI think it may be a good exercise to review those events and try to come\nup with a few theories or even conclusions as to what we could do better.\n\n\n','<CAOyZ2aE-yM6_PfjqTEbzANthJ4iYXXZq3BomNrAhrfp=V9UE4A@mail.gmail.com>',NULL),('<1408642895-sup-2058@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-21 11:19:59',-25200,'2014-08-21 18:19:59',NULL,'[Openstack-operators] memcached redundancy','Excerpts from Joe Topjian\'s message of 2014-08-14 09:09:59 -0700:\n> Hello,\n> \n> I have an OpenStack cloud with two HA cloud controllers. Each controller\n> runs the standard controller components: glance, keystone, nova minus\n> compute and network, cinder, horizon, mysql, rabbitmq, and memcached.\n> \n> Everything except memcached is accessed through haproxy and everything is\n> working great (well, rabbit can be finicky ... I might post about that if\n> it continues).\n> \n> The problem I currently have is how to effectively work with memcached in\n> this environment. Since all components are load balanced, they need access\n> to the same memcached servers. That\'s solved by the ability to specify\n> multiple memcached servers in the various openstack config files.\n> \n> But if I take a server down for maintenance, I notice a 2-3 second delay in\n> all requests. I\'ve confirmed it\'s memcached by editing the list of\n> memcached servers in the config files and the delay goes away.\n\nI\'ve seen a few responses to this that show a _massive_ misunderstanding\nof how memcached is intended to work.\n\nMemcached should never need to be load balanced at the connection\nlevel. It has a consistent hash ring based on the keys to handle\nload balancing and failover. If you have 2 servers, and 1 is gone,\nthe failover should happen automatically. This gets important when you\nhave, say, 5 memcached servers as it means that given 1 failed server,\nyou retain n-1 RAM for caching.\n\nWhat I suspect is happening is that we\'re not doing that right by\neither not keeping persistent connections, or retrying dead servers\ntoo aggressively.\n\nIn fact, it looks like the default one used in oslo-incubator\'s\n\'memorycache\', the \'memcache\' driver, will by default retry dead servers\nevery 30 seconds, and wait 3 seconds for a timeout, which probably\nmatches the behavior you see. None of the places I looked in Nova seem\nto allow passing in a different dead_retry or timeout. In my experience,\nyou probably want something like dead_retry == 600, so only one slow\noperation every 10 minutes per process (so if you have 10 nova-api\'s\nrunning, that\'s 10 requests every 10 minutes).\n\nIt is also possible that some of these objects are being re-created on\nevery request, as is common if caching is implemented too deep inside\n\"middleware\" and not at the edges of a solution. I haven\'t dug deep\nenough in, but suffice to say, replicating and load balancing may be the\ncheaper solution to auditing the code and fixing it at this point.\n\n\n','<CA+y7hvjVvQATPGuEENASA2PwSzNHhiz+PDTq8TxNbSZT+dwYDg@mail.gmail.com>',NULL),('<1408645230-sup-8106@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-21 11:21:10',-25200,'2014-08-21 18:21:10',NULL,'[Openstack-operators] memcached redundancy','Excerpts from John Dewey\'s message of 2014-08-14 09:53:50 -0700:\n> Interesting.  I haven?t seen that happen before, and have setup memcached in a similar fashion as you.  The memcached client consistently hashes each key across your set of active memcached servers.  So killing memcached on server x, should only result in failures for data stored on server x.  However, the client should account for this and rehash.  \n> \n\nThe issue is that there is a timeout that must be reached to detect the\ndead server, and occasionally we retry it. If we are recreating the\nclient each request, that timeout is ALWAYS applied before a server is\nmarked as dead.\n\n\n','<0292D58E723E4BF1B83B49A4C3F4A1AD@dewey.ws>',NULL),('<1408646439965.15789@vmem.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-21 18:42:55',0,'2014-08-21 18:42:55',NULL,'[Openstack] How to download image to volume','Hi -\n\n>From the command line, you can supply an image id along with the cinder create command to create a volume from a image storage in glance.\n\neg, cinder create --image-id 25d00ddb-203a-4d50-93e3-103ab05bfbcd ......\n\nJust be sure that your volume is big enough to hold the image!\n\nFor more options, just type \'cinder help create\'.\n\n--ryan\n________________________________________\nFrom: ZHOU TAO A <tao.a.zhou at alcatel-lucent.com>\nSent: Thursday, August 21, 2014 12:13 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] How to download image to volume\n\nHi All,\n\nI know cinder has a subcommand upload-to-image, which can upload volume\nto image service, while I want to do the opposite--download image to\nvolume without recreating the volume. anyone knows how to do that?\n\n\nThanks\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<53F59C2B.4010706@alcatel-lucent.com>',NULL),('<1408646535.4113772.155329853.4555FF6A@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 11:42:15',-25200,'2014-08-21 18:42:15',NULL,'[openstack-dev] [Ceilometer][WSME] Sphinx failing sporadically\n because of wsme autodoc extension','On Thu, Aug 21, 2014, at 11:25 AM, Doug Hellmann wrote:\n> \n> On Aug 21, 2014, at 8:30 AM, Nejc Saje <nsaje at redhat.com> wrote:\n> \n> > Yesterday, doc builds started failing sporadically in Ceilometer gate.\n> > \n> > http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkVSUk9SOiBJbnZvY2F0aW9uRXJyb3I6ICcvaG9tZS9qZW5raW5zL3dvcmtzcGFjZS9nYXRlLWNlaWxvbWV0ZXItZG9jcy8udG94L3ZlbnYvYmluL3B5dGhvbiBzZXR1cC5weSBidWlsZF9zcGhpbngnXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjE3MjgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDg2MjQwMjcyMDF9\n> > \n> > Can someone with more Sphinx-fu than me figure out why Sphinx is using a wsme extension where there is no wsme code? (The build fails when processing ceilometer.alarm module, example of a successful build: https://jenkins02.openstack.org/job/gate-ceilometer-docs/4412/consoleFull\n> \n> We recently updated the CI nodes to run a new image. Perhaps a dependency\n> has changed in a way that is introducing this problem? Can you reproduce\n> it locally? I?ve tried building the docs and was able to successfully\n> build them on my server running Trusty.\n> \n> Doug\n> \nWe made two changes. First we switched all projects to run tests like\nthis on Trusty slave nodes. Ceilometer was switched long before the\ndefault switch so I don\'t think that change is related. Second we\nupgraded tox to version 1.7.2 on our test slaves. However, I didn\'t get\nthe trusty images updated with tox 1.7.2 until late yesterday UTC time\n(close to midnight) and according to logstash the first occurrence of\nthis error was earlier in the evening (around 1900UTC) so I am not\nconvinced that is related either.\n\nUnfortunately I don\'t have any other good ideas for why this may be\nhappening.\n\nClark\n> > \n> > Cheers,\n> > Nejc\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F772DA88-8E3A-49B8-9DAB-37E4331C8A2D@doughellmann.com>',NULL),('<1408648018-sup-6103@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-21 12:08:47',-25200,'2014-08-21 19:08:47',NULL,'[Openstack-operators] memcached redundancy','Excerpts from Joe Topjian\'s message of 2014-08-21 11:57:44 -0700:\n> Hi Clint,\n> \n> Thank you for your input.\n> \n> If I understand you correctly, the core cause seems to be internal to\n> OpenStack? If that\'s true, I will create a bug report about this. I\'m\n> guessing Oslo would be the correct project to file the bug?\n> \n\nOslo is where the \"memorycache\" that nova uses resides. I imagine\nothers use it too. It is entirely possible, though, that each usage of\nthe module itself could require refactoring so that each process keeps a\nsingle cache connection object alive rather than creating one per request,\nand so that each usage of it can make use of dead_retry.\n\n\n','<CA+y7hvgjiz2GotpBbn-breXTT-8OQygwoCTZDy4MyfFBPUNZTw@mail.gmail.com>',NULL),('<1408651709-sup-8785@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 13:12:02',-25200,'2014-08-21 20:12:02',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from David Kranz\'s message of 2014-08-21 12:45:05 -0700:\n> On 08/21/2014 02:39 PM, gordon chung wrote:\n> > > The point I\'ve been making is\n> > > that by the TC continuing to bless only the Ceilometer project as the\n> > > OpenStack Way of Metering, I think we do a disservice to our users by\n> > > picking a winner in a space that is clearly still unsettled.\n> >\n> > can we avoid using the word \'blessed\' -- it\'s extremely vague and \n> > seems controversial. from what i know, no one is being told project \n> > x\'s services are the be all end all and based on experience, companies \n> > (should) know this. i\'ve worked with other alternatives even though i \n> > contribute to ceilometer.\n> > > Totally agree with Jay here, I know people who gave up on trying to\n> > > get any official project around deployment because they were told they\n> > > had to do it under the TripleO umbrella\n> > from the pov of a project that seems to be brought up constantly and \n> > maybe it\'s my naivety, i don\'t really understand the fascination with \n> > branding and the stigma people have placed on \n> > non-\'openstack\'/stackforge projects. it can\'t be a legal thing because \n> > i\'ve gone through that potential mess. also, it\'s just as easy to \n> > contribute to \'non-openstack\' projects as \'openstack\' projects (even \n> > easier if we\'re honest).\n> Yes, we should be honest. The \"even easier\" part is what Sandy cited as \n> the primary motivation for pursuing stacktach instead of ceilometer.\n> \n> I think we need to consider the difference between why OpenStack wants \n> to bless a project, and why a project might want to be blessed by \n> OpenStack. Many folks believe that for OpenStack to be successful it \n> needs to present itself as a stack that can be tested and deployed, not \n> a sack of parts that only the most extremely clever people can manage to \n> assemble into an actual cloud. In order to have such a stack, some code \n> (or, alternatively, dare I say API...) needs to be blessed. Reasonable \n> debates will continue about which pieces are essential to this stack, \n> and which should be left to deployers, but metering was seen as such a \n> component and therefore something needed to be blessed. The hope was \n> that every one would jump on that and make it great but it seems that \n> didn\'t quite happen (at least yet).\n> \n> Though Open Source has many advantages over proprietary development, the \n> ability to choose a direction and marshal resources for efficient \n> delivery is the biggest advantage of proprietary development like what \n> AWS does. The TC process of blessing is, IMO, an attempt to compensate \n> for that in an OpenSource project. Of course if the wrong code is \n> blessed, the negative  impact can be significant. Blessing APIs would be \n\nHm, I wonder if the only difference there is when AWS blesses the wrong\nthing, they evaluate the business impact, and respond by going in a\ndifferent direction, all behind closed doors. The shame is limited to\nthat inner circle.\n\nHere, with full transparency, calling something \"the wrong thing\" is\npretty much public humiliation for the team involved.\n\nSo it stands to reason that we shouldn\'t call something \"the right\nthing\" if we aren\'t comfortable with the potential public shaming.\n\n\n','<53F64C41.7080002@redhat.com>',NULL),('<1408674150-sup-5372@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 19:34:49',-25200,'2014-08-22 02:34:49',NULL,'[openstack-dev] [Glance][Heat] Murano split dsicussion','Excerpts from Georgy Okrokvertskhov\'s message of 2014-08-20 13:14:28 -0700:\n> During last Atlanta summit there were couple discussions about Application\n> Catalog and Application space projects in OpenStack. These cross-project\n> discussions occurred as a result of Murano incubation request [1] during\n> Icehouse cycle.  On the TC meeting devoted to Murano incubation there was\n> an idea about splitting the Murano into parts which might belong to\n> different programs[2].\n> \n> \n> Today, I would like to initiate a discussion about potential splitting of\n> Murano between two or three programs.\n> \n> \n> *App Catalog API to Catalog Program*\n> \n> Application Catalog part can belong to Catalog program, the package\n> repository will move to artifacts repository part where Murano team already\n> participates. API part of App Catalog will add a thin layer of API methods\n> specific to Murano applications and potentially can be implemented as a\n> plugin to artifacts repository. Also this API layer will expose other 3rd\n> party systems API like CloudFoundry ServiceBroker API which is used by\n> CloudFoundry marketplace feature to provide an integration layer between\n> OpenStack Application packages and 3rd party PaaS tools.\n> \n> \n\nI thought this was basically already agreed upon, and that Glance was\njust growing the ability to store more than just images.\n\n> \n> *Murano Engine to Orchestration Program*\n> \n> Murano engine orchestrates the Heat template generation. Complementary to a\n> Heat declarative approach, Murano engine uses imperative approach so that\n> it is possible to control the whole flow of the template generation. The\n> engine uses Heat updates to update Heat templates to reflect changes in\n> applications layout. Murano engine has a concept of actions - special flows\n> which can be called at any time after application deployment to change\n> application parameters or update stacks. The engine is actually\n> complementary to Heat engine and adds the following:\n> \n> \n>    - orchestrate multiple Heat stacks - DR deployments, HA setups, multiple\n>    datacenters deployment\n\nThese sound like features already requested directly in Heat.\n\n>    - Initiate and controls stack updates on application specific events\n\nSounds like workflow. :)\n\n>    - Error handling and self-healing - being imperative Murano allows you\n>    to handle issues and implement additional logic around error handling and\n>    self-healing.\n\nAlso sounds like workflow.\n\n> \n\n\nI think we need to re-think what a program is before we consider this.\n\nI really don\'t know much about Murano. I have no interest in it at\nall, and nobody has come to me saying \"If we only had Murano in our\norchestration toolbox, we\'d solve xxx.\" But making them part of the\nOrchestration program would imply that we\'ll do design sessions together,\nthat we\'ll share the same mission statement, and that we\'ll have just\none PTL. I fail to see why they\'re not another, higher level program\nthat builds on top of the other services.\n\n> \n> \n> *Murano UI to Dashboard Program*\n> \n> Application Catalog requires  a UI focused on user experience. Currently\n> there is a Horizon plugin for Murano App Catalog which adds Application\n> catalog page to browse, search and filter applications. It also adds a\n> dynamic UI functionality to render a Horizon forms without writing an\n> actual code.\n> \n> \n\nI feel like putting all the UI plugins in Horizon is the same mistake\nas putting all of the functional tests in Tempest. It doesn\'t have the\naffect of breaking the gate but it probably is a lot of burden on a\nsingle team.\n\n\n','<CAG_6_okt1-D3CBSv+AybbREW9n1PjRNjzQqu=An+v+y7OkMb3g@mail.gmail.com>',NULL),('<1408684843.91128.155488885.73D284C8@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-21 22:20:43',-25200,'2014-08-22 05:20:43',NULL,'[OpenStack-Infra] Changing the Gerrit Text for -1','On Thu, Aug 21, 2014, at 09:26 PM, Tom Fifield wrote:\n> Hi Infra,\n> \n> I vaguely recall a discussion where it was stated that should someone\n> come up with a better phrase for the -1 text (\"I would prefer that you\n> didn\'t merge this\"), we could change the text to that.\n> \n> The below suggestion has a few people agreeing with it. Perhaps we could\n> put in a patch to change the text, and see how it goes?\n> \n> Regards,\n> \n> \n> Tom\n> \n> \n> -------- Forwarded Message --------\n> Subject: Re: [openstack-dev] Criteria for giving a -1 in a review\n> Date: Thu, 21 Aug 2014 17:21:19 +0100\n> From: Daniel P. Berrange <berrange at redhat.com>\n> Reply-To: Daniel P. Berrange <berrange at redhat.com>, OpenStack\n> Development Mailing List (not for usage questions)\n> <openstack-dev at lists.openstack.org>\n> To: OpenStack Development Mailing List (not for usage questions)\n> <openstack-dev at lists.openstack.org>\n> \n> On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:\n> > \"I would prefer that you didn\'t merge this.\"\n> > \n> > i.e. The project is better off without it.\n> \n> A bit off topic, but I\'ve never liked this message that gets added\n> as it think it sounds overly negative. It would better written\n> as\n> \n>   \"This patch needs further work before it can be merged\"\n> \n> as that gives a positive expectation that the work is still\n> wanted by the project in general\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nUnfortunately, the actual file that needs to be edited to enact this\nchange isn\'t managed by our tooling. We still curate by hand because of\na chicken and egg issue managing the All-Projects ACL file (you can\'t\nmanage the file until you have the file in place...). But we do document\nwhat we expect to be in that file. I have gone ahead and proposed\nhttps://review.openstack.org/#/c/116176 and we can argue over the value\nthere. If we agree one of the gerrit admins can update the All-Projects\nACL file.\n\nClark\n\n\n','<53F6C67F.4030801@openstack.org>',NULL),('<1408689699-sup-6794@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 23:53:42',-25200,'2014-08-22 06:53:42',NULL,'[openstack-dev] [Glance][Heat] Murano split dsicussion','Excerpts from Angus Salkeld\'s message of 2014-08-21 20:14:12 -0700:\n> On Fri, Aug 22, 2014 at 12:34 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Georgy Okrokvertskhov\'s message of 2014-08-20 13:14:28 -0700:\n> > > During last Atlanta summit there were couple discussions about\n> > Application\n> > > Catalog and Application space projects in OpenStack. These cross-project\n> > > discussions occurred as a result of Murano incubation request [1] during\n> > > Icehouse cycle.  On the TC meeting devoted to Murano incubation there was\n> > > an idea about splitting the Murano into parts which might belong to\n> > > different programs[2].\n> > >\n> > >\n> > > Today, I would like to initiate a discussion about potential splitting of\n> > > Murano between two or three programs.\n> > >\n> > >\n> > > *App Catalog API to Catalog Program*\n> > >\n> > > Application Catalog part can belong to Catalog program, the package\n> > > repository will move to artifacts repository part where Murano team\n> > already\n> > > participates. API part of App Catalog will add a thin layer of API\n> > methods\n> > > specific to Murano applications and potentially can be implemented as a\n> > > plugin to artifacts repository. Also this API layer will expose other 3rd\n> > > party systems API like CloudFoundry ServiceBroker API which is used by\n> > > CloudFoundry marketplace feature to provide an integration layer between\n> > > OpenStack Application packages and 3rd party PaaS tools.\n> > >\n> > >\n> >\n> > I thought this was basically already agreed upon, and that Glance was\n> > just growing the ability to store more than just images.\n> >\n> > >\n> > > *Murano Engine to Orchestration Program*\n> > >\n> > > Murano engine orchestrates the Heat template generation. Complementary\n> > to a\n> > > Heat declarative approach, Murano engine uses imperative approach so that\n> > > it is possible to control the whole flow of the template generation. The\n> > > engine uses Heat updates to update Heat templates to reflect changes in\n> > > applications layout. Murano engine has a concept of actions - special\n> > flows\n> > > which can be called at any time after application deployment to change\n> > > application parameters or update stacks. The engine is actually\n> > > complementary to Heat engine and adds the following:\n> > >\n> > >\n> > >    - orchestrate multiple Heat stacks - DR deployments, HA setups,\n> > multiple\n> > >    datacenters deployment\n> >\n> > These sound like features already requested directly in Heat.\n> >\n> > >    - Initiate and controls stack updates on application specific events\n> >\n> > Sounds like workflow. :)\n> >\n> > >    - Error handling and self-healing - being imperative Murano allows you\n> > >    to handle issues and implement additional logic around error handling\n> > and\n> > >    self-healing.\n> >\n> > Also sounds like workflow.\n> >\n> > >\n> >\n> >\n> > I think we need to re-think what a program is before we consider this.\n> >\n> > I really don\'t know much about Murano. I have no interest in it at\n> >\n> \n> \"get off my lawn\";)\n> \n\nAnd turn down that music!\n\nSorry for the fist shaking, but I wan to highlight that I\'m happy to\nconsider it, just not with programs working the way they do now.\n\n> http://stackalytics.com/?project_type=all&module=murano-group\n> \n> HP seems to be involved, you should check it out.\n> \n\nHP is involved in a lot of OpenStack things. It\'s a bit hard for me to\nkeep my eyes on everything we do. Good to know that others have been able\nto take some time and buy into it a bit. +1 for distributing the load. :)\n\n> > all, and nobody has come to me saying \"If we only had Murano in our\n> > orchestration toolbox, we\'d solve xxx.\" But making them part of the\n> >\n> \n> I thought you were saying that opsworks was neat the other day?\n> Murano from what I understand was partly inspired from opsworks, yes\n> it\'s a layer up, but still really the same field.\n>\n\nI was saying that OpsWorks is reportedly popular, yes. I did not make\nthe connection at all from OpsWorks to Murano, and nobody had pointed\nthat out to me until now.\n\n> > Orchestration program would imply that we\'ll do design sessions together,\n> > that we\'ll share the same mission statement, and that we\'ll have just\n> >\n> \n> This is exactly what I hope will happen.\n> \n\nWhich sessions from last summit would we want to give up to make room\nfor the Murano-only focused sessions? How much time in our IRC meeting\nshould we give to Murano-only concerns?\n\nForgive me for being harsh. We have a cloud to deploy using Heat,\nand it is taking far too long to get Heat to do that in an acceptable\nmanner already. Adding load to our PTL and increasing the burden on our\ncommunication channels doesn\'t really seem like something that will\nincrease our velocity. I could be dead wrong though, Murano could be\nexactly what we need. I just don\'t see it, and I\'m sorry to be so direct\nabout saying that.\n\n\n','<CAA16xczJReUmt1Ds1i2o6YWJXJ25666c-8BwzhXjqg66A0M9BA@mail.gmail.com>',NULL),('<1408690784-sup-3920@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 00:03:29',-25200,'2014-08-22 07:03:29',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Michael Chapman\'s message of 2014-08-21 23:30:44 -0700:\n> On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes <jaypipes at gmail.com> wrote:\n> \n> > On 08/19/2014 11:28 PM, Robert Collins wrote:\n> >\n> >> On 20 August 2014 02:37, Jay Pipes <jaypipes at gmail.com> wrote:\n> >> ...\n> >>\n> >>  I\'d like to see more unification of implementations in TripleO - but I\n> >>>> still believe our basic principle of using OpenStack technologies that\n> >>>> already exist in preference to third party ones is still sound, and\n> >>>> offers substantial dogfood and virtuous circle benefits.\n> >>>>\n> >>>\n> >>>\n> >>> No doubt Triple-O serves a valuable dogfood and virtuous cycle purpose.\n> >>> However, I would move that the Deployment Program should welcome the many\n> >>> projects currently in the stackforge/ code namespace that do deployment\n> >>> of\n> >>> OpenStack using traditional configuration management tools like Chef,\n> >>> Puppet, and Ansible. It cannot be argued that these configuration\n> >>> management\n> >>> systems are the de-facto way that OpenStack is deployed outside of HP,\n> >>> and\n> >>> they belong in the Deployment Program, IMO.\n> >>>\n> >>\n> >> I think you mean it \'can be argued\'... ;).\n> >>\n> >\n> > No, I definitely mean \"cannot be argued\" :) HP is the only company I know\n> > of that is deploying OpenStack using Triple-O. The vast majority of\n> > deployers I know of are deploying OpenStack using configuration management\n> > platforms and various systems or glue code for baremetal provisioning.\n> >\n> > Note that I am not saying that Triple-O is bad in any way! I\'m only saying\n> > that it does not represent the way that the majority of real-world\n> > deployments are done.\n> >\n> >\n> > > And I\'d be happy if folk in\n> >\n> >> those communities want to join in the deployment program and have code\n> >> repositories in openstack/. To date, none have asked.\n> >>\n> >\n> > My point in this thread has been and continues to be that by having the TC\n> > \"bless\" a certain project as The OpenStack Way of X, that we implicitly are\n> > saying to other valid alternatives \"Sorry, no need to apply here.\".\n> >\n> >\n> >  As a TC member, I would welcome someone from the Chef community proposing\n> >>> the Chef cookbooks for inclusion in the Deployment program, to live under\n> >>> the openstack/ code namespace. Same for the Puppet modules.\n> >>>\n> >>\n> > While you may personally welcome the Chef community to propose joining the\n> > deployment Program and living under the openstack/ code namespace, I\'m just\n> > saying that the impression our governance model and policies create is one\n> > of exclusion, not inclusion. Hope that clarifies better what I\'ve been\n> > getting at.\n> >\n> >\n> \n> (As one of the core reviewers for the Puppet modules)\n> \n> Without a standardised package build process it\'s quite difficult to test\n> trunk Puppet modules vs trunk official projects. This means we cut release\n> branches some time after the projects themselves to give people a chance to\n> test. Until this changes and the modules can be released with the same\n> cadence as the integrated release I believe they should remain on\n> Stackforge.\n> \n\nSeems like the distros that build the packages are all doing lots of\ndaily-build type stuff that could somehow be leveraged to get over that.\n\n\n','<CABf87XkuUd6hGVDjfQ79_3wcQBjvuv-0Df4tKWzRAuGcohfMsQ@mail.gmail.com>',NULL),('<1408695384.4496.14.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 10:16:24',7200,'2014-08-22 08:16:24',NULL,'[openstack-dev] [neutron][ml2] Openvswitch agent support for\n non promic mode adapters','Thanks for your feedback. \n\nNo, I do not yet have code for it. Just wanted to get a feeling if such\na feature would get acceptance in the community. \nBut if that helps I can sit down and start some prototyping while I\'m\npreparing a blueprint spec in parallel. \n\nThe main part of the implementation I wanted to do on my own to get more\nfamiliar with the code base and to get more in touch with the community.\nBut of course advice and feedback of experienced neutron developers is\nessential!\n\nSo I will proceed like this\n- Create a blueprint\n- Commit first pieces of code to get early feedback (e.g. ask via the\nmailing list or irc)\n- Upload a spec (as soon as the repo is available for K)\n\nDoes that make sense for you?\n\nThanks,\nAndreas\n\n\n\nOn Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:\n> I think this sounds reasonable. Do you have code for this already, or\n> are you looking for a developer to help implement it?\n> \n> \n> On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring\n> <scheuran at linux.vnet.ibm.com> wrote:\n>         Hi,\n>         last week I started discussing an extension to the existing\n>         neutron\n>         openvswitch agent to support network adapters that are not in\n>         promiscuous mode. Now I would like to enhance the round to get\n>         feedback\n>         from a broader audience via the mailing list.\n>         \n>         \n>         The Problem\n>         When driving vlan or flat networking, openvswitch requires an\n>         network\n>         adapter in promiscuous mode.\n>         \n>         \n>         Why not having promiscuous mode in your adapter?\n>         - Admins like to have full control over their environment and\n>         which\n>         network packets enter the system.\n>         - The network adapter just does not have support for it.\n>         \n>         \n>         What to do?\n>         Linux net-dev driver offer an interface to manually register\n>         additional\n>         mac addresses (also called secondary unicast addresses).\n>         Exploiting this\n>         one can register additional mac addresses to the network\n>         adapter. This\n>         also works via a well known ip user space tool.\n>         \n>         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`\n>         \n>         \n>         What to do in openstack?\n>         As neutron is aware of all the mac addresses that are in use\n>         it\'s the\n>         perfect candidate for doing the mac registrations. The idea is\n>         to modify\n>         the neutron openvswitch agent that it does the registration on\n>         \"port\n>         add\" and \"port remove\" via the bridge command.\n>         There would be a new optional configuration parameter,\n>         something like\n>         \'non-promisc-mode\' that is by default set to false. Only when\n>         set to\n>         true, macs get manually registered. Otherwise the agent\n>         behaves like it\n>         does today. So I guess only very little changes to the agent\n>         code are\n>         required. From my current point of view we do not need any\n>         changes to\n>         the ml2 plug-in.\n>         \n>         \n>         Blueprint or a bug?\n>         I guess it\'s a blueprint.\n>         \n>         What\'s the timeframe?\n>         K would be great.\n>         \n>         \n>         \n>         I would be thankful for any feedback on this! Feel free to\n>         contact me\n>         anytime. Thanks in advance!\n>         \n>         Regards,\n>         Andreas\n>         \n>         (irc: scheuran)\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Kevin Benton\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAO_F6JMVT-s-ERjReBPchy=kRaX_XYtsLAbhZ6TL6twfdVjULg@mail.gmail.com>',NULL),('<1408723250.2653.52.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 17:00:50',3600,'2014-08-22 16:00:50',NULL,'[openstack-dev] [all] [ptls] The Czar system,\n or how to scale PTLs','On Fri, 2014-08-22 at 11:01 -0400, Zane Bitter wrote:\n\n> I don\'t see that as something the wider OpenStack community needs to \n> dictate. We have a heavyweight election process for PTLs once every \n> cycle because that used to be the process for electing the TC. Now that \n> it no longer serves this dual purpose, PTL elections have outlived their \n> usefulness.\n> \n> If projects want to have a designated tech lead, let them. If they want \n> to have the lead elected in a form of representative democracy, let \n> them. But there\'s no need to impose that process on every project. If \n> they want to rotate the tech lead every week instead of every 6 months, \n> why not let them? We\'ll soon see from experimentation which models work. \n> Let a thousand flowers bloom, &c.\n\nI like the idea of projects being free to experiment with their\ngovernance rather than the TC mandating detailed governance models from\nabove.\n\nBut I also like the way Thierry is taking a trend we\'re seeing work out\nwell across multiple projects, and generalizing it. If individual\nprojects are to adopt explicit PTL duty delegation, then all the better\nif those projects adopt it in similar ways.\n\ni.e. this should turn out to be an optional \"best practice model\" that\nprojects can choose to adopt, in much the way the *-specs repo idea took\nhold.\n\nMark.\n\n\n\n','<53F75B40.8040603@redhat.com>',NULL),('<1408724170.2653.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 17:16:10',3600,'2014-08-22 16:16:10',NULL,'[openstack-dev] Criteria for giving a -1 in a review','On Fri, 2014-08-22 at 11:01 +0100, Daniel P. Berrange wrote:\n> On Fri, Aug 22, 2014 at 10:49:51AM +0100, Steven Hardy wrote:\n> > On Thu, Aug 21, 2014 at 05:05:04PM +0100, Matthew Booth wrote:\n> > > I also think it\'s worth explicitly documenting a few things we\n> > > might/should mention in a review, but which aren\'t a reason that the\n> > > project would be better off without it:\n> > > \n> > > * Stylistic issues which are not covered by HACKING\n> > > \n> > > By stylistic, I mean changes which have no functional impact on the code\n> > > whatsoever. If a purely stylistic issue is sufficiently important to\n> > > reject code which doesn\'t adhere to it, it is important enough to add to\n> > > HACKING.\n> > \n> > I\'ll sometimes +1 a change if it looks functionally OK but has some\n> > stylistic or cosmetic issues I would prefer to see fixed before giving a\n> > +2.  I see that as a \"soft\" +2, it\'s not blocking anything, but I\'m giving\n> > the patch owner the chance to fix the problem (which they nearly always\n> > do).\n> > \n> > Although if a patch contains really significant uglies, I think giving a \"I\n> > would prefer you didn\'t merge this, in it\'s current state\" with lots of\n> > constructive comments wrt how to improve things is perfectly reasonable.\n> > \n> > > * I can think of a better way of doing this\n> > > \n> > > There may be a better solution, but there is already an existing\n> > > solution. We should only be rejecting work that has already been done if\n> > > it would detract from the project for one of the reasons above. We can\n> > > always improve it further later if we find the developer time.\n> > \n> > Agreed, although again I\'d encourage folks to +1 and leave detailed\n> > information about how to improve the solution - most people (myself\n> > included) really appreciate learning better ways to do things.  I\'ve\n> > definitely become a much better python developer as a result of the\n> > detailed scrutiny and feedback provided via code reviews.\n> > \n> > So while I agree with the general message you seem to be proposing (e.g\n> > don\'t -1 for really trivial stuff), I think it\'s important to recognise\n> > that if there are obvious and non-painful ways to improve code-quality, the\n> > review is the time to do that.\n> \n> One thing I have seen some people (eg Mark McLoughlin) do a number\n> of times is to actually submit followup patches. eg they will point\n> out the minor style issue, or idea for a better approach, but still\n> leave a +1/+2 score. Then submit a followup change to deal with that\n> \"nitpicking\".  This seems like it is quite an effective approach\n> because it ensures the original authors\' work gets through review\n> more quickly. Using a separate follow-on patch also avoids the idea\n> of the reviewer hijacking the original contributors patches by editing\n> them & reposting directly\n\nThat\'s definitely the intent, but I\'ve sometimes regretted it when\nanother reviewer comes along with even *more* trivial concerns and -1s\nmy +2 (another stat we track and over-analyze), and then the submitter\nfixes these new concerns but doesn\'t include my fixups, leaving me with\na patch to rebase ... at which point you just want to cry :)\n\nThat lesson learned, I\'d now tend to only take this approach with a\npatch I\'m about to +2 and approve.\n\nMark.\n\n\n\n','<20140822100152.GI8447@redhat.com>',NULL),('<1408724680-sup-9130@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 09:27:04',-25200,'2014-08-22 16:27:04',NULL,'[openstack-dev] [all] The future of the integrated release','Excerpts from Sean Dague\'s message of 2014-08-22 04:51:49 -0700:\n> On 08/22/2014 01:30 AM, Michael Chapman wrote:\n> > \n> > \n> > \n> > On Fri, Aug 22, 2014 at 2:57 AM, Jay Pipes <jaypipes at gmail.com\n> > <mailto:jaypipes at gmail.com>> wrote:\n> > \n> >     On 08/19/2014 11:28 PM, Robert Collins wrote:\n> > \n> >         On 20 August 2014 02:37, Jay Pipes <jaypipes at gmail.com\n> >         <mailto:jaypipes at gmail.com>> wrote:\n> >         ...\n> > \n> >                 I\'d like to see more unification of implementations in\n> >                 TripleO - but I\n> >                 still believe our basic principle of using OpenStack\n> >                 technologies that\n> >                 already exist in preference to third party ones is still\n> >                 sound, and\n> >                 offers substantial dogfood and virtuous circle benefits.\n> > \n> > \n> > \n> >             No doubt Triple-O serves a valuable dogfood and virtuous\n> >             cycle purpose.\n> >             However, I would move that the Deployment Program should\n> >             welcome the many\n> >             projects currently in the stackforge/ code namespace that do\n> >             deployment of\n> >             OpenStack using traditional configuration management tools\n> >             like Chef,\n> >             Puppet, and Ansible. It cannot be argued that these\n> >             configuration management\n> >             systems are the de-facto way that OpenStack is deployed\n> >             outside of HP, and\n> >             they belong in the Deployment Program, IMO.\n> > \n> > \n> >         I think you mean it \'can be argued\'... ;).\n> > \n> > \n> >     No, I definitely mean \"cannot be argued\" :) HP is the only company I\n> >     know of that is deploying OpenStack using Triple-O. The vast\n> >     majority of deployers I know of are deploying OpenStack using\n> >     configuration management platforms and various systems or glue code\n> >     for baremetal provisioning.\n> > \n> >     Note that I am not saying that Triple-O is bad in any way! I\'m only\n> >     saying that it does not represent the way that the majority of\n> >     real-world deployments are done.\n> > \n> > \n> >     > And I\'d be happy if folk in\n> > \n> >         those communities want to join in the deployment program and\n> >         have code\n> >         repositories in openstack/. To date, none have asked.\n> > \n> > \n> >     My point in this thread has been and continues to be that by having\n> >     the TC \"bless\" a certain project as The OpenStack Way of X, that we\n> >     implicitly are saying to other valid alternatives \"Sorry, no need to\n> >     apply here.\".\n> > \n> > \n> >             As a TC member, I would welcome someone from the Chef\n> >             community proposing\n> >             the Chef cookbooks for inclusion in the Deployment program,\n> >             to live under\n> >             the openstack/ code namespace. Same for the Puppet modules.\n> > \n> > \n> >     While you may personally welcome the Chef community to propose\n> >     joining the deployment Program and living under the openstack/ code\n> >     namespace, I\'m just saying that the impression our governance model\n> >     and policies create is one of exclusion, not inclusion. Hope that\n> >     clarifies better what I\'ve been getting at.\n> > \n> > \n> > \n> > (As one of the core reviewers for the Puppet modules)\n> > \n> > Without a standardised package build process it\'s quite difficult to\n> > test trunk Puppet modules vs trunk official projects. This means we cut\n> > release branches some time after the projects themselves to give people\n> > a chance to test. Until this changes and the modules can be released\n> > with the same cadence as the integrated release I believe they should\n> > remain on Stackforge.\n> > \n> > In addition and perhaps as a consequence, there isn\'t any public\n> > integration testing at this time for the modules, although I know some\n> > parties have developed and maintain their own.\n> > \n> > The Chef modules may be in a different state, but it\'s hard for me to\n> > recommend the Puppet modules become part of an official program at this\n> > stage.\n> \n> Is the focus of the Puppet modules only stable releases with packages?\n> Puppet + git based deploys would be honestly a really handy thing\n> (especially as lots of people end up having custom fixes for their\n> site). The lack of CM tools for git based deploys is I think one of the\n> reasons we seen people using DevStack as a generic installer.\n> \n\nWe have quite a bit of stuff built up in tripleo-image-elements to build\nwhat amounts to a lightweight package inside of an image. I do kind of\nwonder if we\'ve abstracted enough to be able to build system packages\nout of what we have created.\n\nProbably not, but it might be worth looking at, as we are definitely\nbuilt for pointing at git and even pulling in specific refs.\n\n\n','<53F72ED5.60308@dague.net>',NULL),('<1408728161.295875.155686513.443A6A40@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 10:22:41',-25200,'2014-08-22 17:22:41',NULL,'[openstack-dev] [all] new testtools breaking gate','On Fri, Aug 22, 2014, at 05:55 AM, Ihar Hrachyshka wrote:\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> Hi all,\n> \n> this week is quite bumpy for unit testing in gate. First, it was\n> upgrade to new \'tox\' version that broke quite some branches.\n> \nI did a ton of work to make the tox upgrade go smoothly because we knew\nit would be somewhat painful. About a month ago I sent mail to this list\n[0] describing the problem. This thread included a pointer to the bug\nfiled to track this [1] and example work around changes [2] which I\nwrote and proposed for as many projects and branches as I had time to\ntest at that point.\n\nUpdating tox to 1.7.2 is important for a couple reasons. We get a lot of\nconfused developers wondering why using tox doesn\'t work to run their\ntests when all of our documentation says just run tox. Well you needed a\nspecial version (1.6.1). Communicating that to everyone that tries to\nrun tox is hard.\n\nIt is also important because tox adds new features like the hashseed\nrandomization. This is the cause of our problems but it is exposing real\nbugs in openstack [3]. We should be fixing these issues and hopefully my\nproposed workarounds are only temporary.\n\nI decided to push ahead [4] and upgrade tox a couple days ago for a\ncouple reasons. This is an important change as illustrated above and\nfeature freeze and stabilization are rapidly approaching and this\nprobably needed to get in soon to have a chance at getting in at all. I\nfelt this was appropriate because I had done a ton of work prior to make\nthings go as smoothly as possible.\n\nWhere things did not go smoothly was on the reviews for my workaround.\nSome changes were basically ignored [5] others ran into procedural\npaperwork associated with stable branches that are not quite appropriate\nfor changes of this type [6][7]. I get that generally we only want to\nbackport things from master and that we have some specific way to cherry\npick things, but this type of change is to address issues with\nstable/foo directly and has nothing to do with master. I did eventually\ngo through the \"backport\" dance for most of these changes despite this\nnot actually being a true backport.\n\n[0]\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/041283.html\n[1] https://bugs.launchpad.net/cinder/+bug/1348818\n[2] https://review.openstack.org/#/c/109700/\n[3]\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/041496.html\n[4]\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042010.html\n[5] https://review.openstack.org/#/c/109749/\n[6] https://review.openstack.org/#/c/109759/\n[7] https://review.openstack.org/#/c/109750/\n\nWith all of that out of the way are there suggestions for how we can do\nthis better next time? Do we need more time (I gave us about 4 weeks\nwhich seemed like plenty to me)? Perhaps I should send more reminder\nemails? Feedback is very welcome.\n\nThanks,\nClark\n>\n> And today new testtools 0.9.36 were released and were caught by gate,\n> which resulted in the following unit test failures in multiple projects:\n> \n> TestCase.setUp was already called. Do not explicitly call setUp from\n> your tests. In your own setUp, use super to call the base setUp.\n> \n> All branches are affected: havana, icehouse, and master.\n> \n> This is because the following check was released with the new version\n> of the library:\n> https://github.com/testing-cabal/testtools/commit/5c3b92d90a64efaecdc4010a98002bfe8b888517\n> \n> And the temporary fix is to merge the version pin patch in global\n> requirements, backport it to stable branches, and merge the updates\n> from Openstack Proposal Bot to all affected projects. The patch for\n> master requirements is: https://review.openstack.org/#/c/116267/\n> \n> In the meantime, projects will need to fix their tests not to call\n> setUp() and tearDown() twice. This will be the requirement to unpin\n> the version of the library.\n> \n> So, please review, backport, and make sure it lands in project\n> requirements files.\n> \n> /Ihar\n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> \n> iQEcBAEBCgAGBQJT9z3cAAoJEC5aWaUY1u57DtsIAOFtK2i4zkMcC79nOrc5w9DW\n> oO2b064eyLwwbQEaWeeIL2JBSLBxqNV5zeN0eZB3Sq7LQLv0oPaUNTMFG2+gvask\n> JHCTAGKz776Rt7ptcfmpHURwcT9L//+1HXvd+ADtO0sYKwgmvaBF7aA4WFa4TseG\n> JCnAsi5OiOZZgTo/6U1B55srHkZr0DWxqTkKKysZJbR2Pr/ZT9io8yu9uucaz9VH\n> uNLfggtCcjGgccl7IqSUtVRf3lsSGuvBAxVqMszSFJQmFCjy2E26GfsTApp9KXtQ\n> gbCpEns8QCnt6KF9rygjHLMbYikjbITuUfSL2okZelX9VpKNx0CS29K/tRg5/BA=\n> =YavB\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53F73DDC.6080609@redhat.com>',NULL),('<1408728699-sup-5361@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 10:48:03',-25200,'2014-08-22 17:48:03',NULL,'[openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a box?','It has been brought to my attention that Ironic uses the biggest hammer\nin the IPMI toolbox to control chassis power:\n\nhttps://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142\n\nWhich is\n\n    ret = ipmicmd.set_power(\'off\', wait)\n\nThis is the most abrupt form, where the system power should be flipped\noff at a hardware level. The \"short press\" on the power button would be\n\'shutdown\' instead of \'off\'.\n\nI also understand that this has been brought up before, and that the\nanswer given was \"SSH in and shut it down yourself.\" I can respect that\nposition, but I have run into a bit of a pickle using it. Observe:\n\n- ssh box.ip \"poweroff\"\n- poll ironic until power state is off.\n  - This is a race. Ironic is asserting the power. As soon as it sees\n    that the power is off, it will turn it back on.\n\n- ssh box.ip \"halt\"\n  - NO way to know that this has worked. Once SSH is off and the network\n    stack is gone, I cannot actually verify that the disks were\n    unmounted properly, which is the primary area of concern that I\n    have.\n\nThis is particulary important if I\'m issuing a rebuild + preserve\nephemeral, as it is likely I will have lots of I/O going on, and I want\nto make sure that it is all quiesced before I reboot to replace the\nsoftware and reboot.\n\nPerhaps I missed something. If so, please do educate me on how I can\nachieve this without hacking around it. Currently my workaround is to\nmanually unmount the state partition, which is something system shutdown\nis supposed to do and may become problematic if system processes are\nholding it open.\n\nIt seems to me that Ironic should at least try to use the graceful\nshutdown. There can be a timeout, but it would need to be something a user\ncan disable so if graceful never works we never just dump the power on the\nbox. Even a journaled filesystem will take quite a bit to do a full fsck.\n\nThe inability to gracefully shutdown in a reasonable amount of time\nis an error state really, and I need to go to the box and inspect it,\nwhich is precisely the reason we have ERROR states.\n\nThanks for your time. :)\n\n\n',NULL,NULL),('<1408732420-sup-4412@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 11:34:54',-25200,'2014-08-22 18:34:54',NULL,'[openstack-dev] [Ironic] [TripleO] How to gracefully quiesce a\n	box?','Excerpts from Jay Pipes\'s message of 2014-08-22 11:16:05 -0700:\n> On 08/22/2014 01:48 PM, Clint Byrum wrote:\n> > It has been brought to my attention that Ironic uses the biggest hammer\n> > in the IPMI toolbox to control chassis power:\n> >\n> > https://git.openstack.org/cgit/openstack/ironic/tree/ironic/drivers/modules/ipminative.py#n142\n> >\n> > Which is\n> >\n> >      ret = ipmicmd.set_power(\'off\', wait)\n> >\n> > This is the most abrupt form, where the system power should be flipped\n> > off at a hardware level. The \"short press\" on the power button would be\n> > \'shutdown\' instead of \'off\'.\n> >\n> > I also understand that this has been brought up before, and that the\n> > answer given was \"SSH in and shut it down yourself.\" I can respect that\n> > position, but I have run into a bit of a pickle using it. Observe:\n> >\n> > - ssh box.ip \"poweroff\"\n> > - poll ironic until power state is off.\n> >    - This is a race. Ironic is asserting the power. As soon as it sees\n> >      that the power is off, it will turn it back on.\n> >\n> > - ssh box.ip \"halt\"\n> >    - NO way to know that this has worked. Once SSH is off and the network\n> >      stack is gone, I cannot actually verify that the disks were\n> >      unmounted properly, which is the primary area of concern that I\n> >      have.\n> >\n> > This is particulary important if I\'m issuing a rebuild + preserve\n> > ephemeral, as it is likely I will have lots of I/O going on, and I want\n> > to make sure that it is all quiesced before I reboot to replace the\n> > software and reboot.\n> >\n> > Perhaps I missed something. If so, please do educate me on how I can\n> > achieve this without hacking around it. Currently my workaround is to\n> > manually unmount the state partition, which is something system shutdown\n> > is supposed to do and may become problematic if system processes are\n> > holding it open.\n> >\n> > It seems to me that Ironic should at least try to use the graceful\n> > shutdown. There can be a timeout, but it would need to be something a user\n> > can disable so if graceful never works we never just dump the power on the\n> > box. Even a journaled filesystem will take quite a bit to do a full fsck.\n> >\n> > The inability to gracefully shutdown in a reasonable amount of time\n> > is an error state really, and I need to go to the box and inspect it,\n> > which is precisely the reason we have ERROR states.\n> \n> What about placing a runlevel script in /etc/init.d/ and symlinking it \n> to run on shutdown -- i.e. /etc/rc0.d/? You could run fsync or unmount \n> the state partition in that script which would ensure disk state was \n> quiesced, no?\n\nThat\'s already what OS\'s do in their rc0.d.\n\nMy point is, I don\'t have any way to know that process happened, without\nthe box turning itself off after it succeeded.\n\n\n','<53F788E5.4000607@gmail.com>',NULL),('<1408757101-sup-7332@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-23 01:37:16',0,'2014-08-23 01:37:16',NULL,'[openstack-dev] [TripleO][Ironic] Unique way to get a\n	registered machine?','Excerpts from Steve Kowalik\'s message of 2014-08-22 06:32:04 +0000:\n>     At the moment, if you run register-nodes a second time with the same \n> list of nodes, it will happily try and register them and then blow up \n> when Ironic or Nova-bm returns an error. If operators are going to \n> update their master list of nodes to add or remove machines and then run \n> register-nodes again, we need a way to skip registering nodes that are \n> already -- except that I don\'t really want to extract out the UUID of \n> the registered nodes, because that puts an onus on the operators to make \n> sure that the UUID is listed in the master list, and that would be mean \n> requiring manual data entry, or some way to get that data back out in \n> the tool they use to manage their master list, which may not even have \n> an API. Because our intent is for this bridge between an operators \n> master list, and a baremetal service, the intent is for this to run \n> again and again when changes happen.\n\nI dont understand why inputting the UUID into the master list requires\nmanual entry? Why cant we, on insertion, also insert the UUID into the\nnodes list? One potential downside is that operators cannot fully regen\nthe nodes list when editing it but have to \'merge in\' changes but IMO\nthis is a good enough start and preferrable to some non-straightforward\nimplicit behavior done by our own routine.\n\n>     This means we need a way to uniquely identify the machines in the list \n> so we can tell if they are already registered.\n> \n>     For the pxe_ssh driver, this means the set of MAC addresses must intersect.\n> \n>     For other drivers, we think that the pm_address for each machine will \n> be unique. Would it be possible add some advice to that effect to \n> Ironic\'s driver API?\n\nBuilding off my previous comment - If we really want to provide an\nimplicit updating mechanism so operators can re-gen node lists in\nentirety then why not build it as a new processing stage? Im thinking:\n\n1) gen list of just_nodes.json\n2) run update_nodes to update nodes.json containing new data and old\nUUIDS where applicable\n3) pass nodes.json into register nodes\n\nYour proposal of auto detecting updated nodes would live purely in the\nupdate_nodes script but operators could elect to skip this if their node\ngeneration tooling supports it.\n\n- Greg\n\n\n','<53F6E3E4.1000103@wedontsleep.org>',NULL),('<1408773551-sup-5428@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 23:01:29',-25200,'2014-08-23 06:01:29',NULL,'[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in\n	Keystone','I don\'t know how Zaqar does its magic, but I\'d love to see simple signed\nURLs rather than users/passwords. This would work for Heat as well. That\nway we only have to pass in a single predictably formatted string.\n\nExcerpts from Zane Bitter\'s message of 2014-08-22 14:35:38 -0700:\n> Here\'s an interesting fact about Zaqar (the project formerly known as \n> Marconi) that I hadn\'t thought about before this week: it\'s probably the \n> first OpenStack project where a major part of the API primarily faces \n> software running in the cloud rather than facing the user.\n> \n> That is to say, nobody is going to be sending themselves messages on \n> their laptop, from their laptop, via a cloud. At least one end of any \n> given queue is likely to be on a VM in the cloud.\n> \n> That makes me wonder: how does Zaqar authenticate users who are sending \n> and receiving messages (as opposed to setting up the queues in the first \n> place)? Presumably using Keystone, in which case it will run into a \n> problem we\'ve been struggling with in Heat since the very early days.\n> \n> Keystone is generally a front end for an identity store with a 1:1 \n> correspondence between users and actual natural persons. Only the \n> operator can add or remove accounts. This breaks down as soon as you \n> need to authenticate automated services running in the cloud - in \n> particular, you never ever want to store the credentials belonging to an \n> actual natural person in a server in the cloud.\n> \n> Heat has managed to work around this to some extent (for those running \n> the Keystone v3 API) by creating users in a separate domain and more or \n> less doing our own authorisation for them. However, this requires action \n> on the part of the operator, and isn\'t an option for the end user. I \n> guess Zaqar could do something similar and pass out sets of credentials \n> good only for reading and writing to queues (respectively), but it seems \n> like it would be better if the user could create the keystone accounts \n> and set their own access control rules on the queues.\n> \n> On AWS the very first thing a user does is create a bunch of IAM \n> accounts so that they virtually never have to use the credentials \n> associated with their natural person ever again. There are both user \n> accounts and service accounts - the latter IIUC have \n> automatically-rotating keys. Is there anything like this planned in \n> Keystone? Zaqar is likely only the first (I guess second, if you count \n> Heat) of many services that will need it.\n> \n> I have this irrational fear that somebody is going to tell me that this \n> issue is the reason for the hierarchical-multitenancy idea - fear \n> because that both sounds like it requires intrusive changes in every \n> OpenStack project and fails to solve the problem. I hope somebody will \n> disabuse me of that notion in 3... 2... 1...\n> \n> cheers,\n> Zane.\n> \n\n\n','<53F7B7AA.7020400@redhat.com>',NULL),('<1408818799-sup-905@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-23 11:42:56',-25200,'2014-08-23 18:42:56',NULL,'[Openstack] Keystone and Horizon questions','Excerpts from Marcus White\'s message of 2014-08-23 09:55:24 -0700:\n> Hello,\n> I had some keystone and Horizon questions, would apprecite it if\n> anyone can help:-)\n> \n> a. Does Keystone run as a service scaled across multiple nodes? Since\n> it would need access to shared data, I dont understand how it scales.\n> \n\nIt stores data in various backends. The default is SQL, and many use\nLDAP to link with existing ID stores.\n\nIt runs as a REST API in front of those data backends, and scales out\nquite nicely like any other web application.\n\n> b. If it does not run on multiple nodes as a service, how can it\n> handle a large number of concurrent requests?\n> \n> c. Is it expected to be a service that is exposed to the clients on a\n> public cloud? Does Rackspace today do it or any other public cloud?\n> \n\nYes it is expected to be exposed. Users authenticate to keystone and are\ngiven a token which can be used to grant access to the other OpenStack\nservices.\n\n> Some horizon questions also\n> \n> a. Does Horizon allow customization for specific services? Is there\n> any way to add value on top of it for my own Nova or Swift or Cinder\n> view, can I do that or is it whatever is done by the community the\n> only thing available?\n> \n\nIt\'s open source. Go wild. ;) I believe there are hooks for\nskins/themes, and one can add plugins for other functionality.\n\n> b. It seems like Horizon is basic right now, do vendors provide their\n> own GUI for customers?\n> \n\nSee horizon.hpcloud.net for a public cloud provider (disclosure: my\nemployer) using Horizon.\n\n> c. Is there a hardware monitoring also as part of Horizon? For\n> servers? For storage arrays? Is there a standardized agent or\n> something that runs on hardware?\n> \n\nHorizon isn\'t really about \"servers\" and \"arrays\". It is meant as the\ninterface for the users of the cloud, not the operators.\n\n\n','<CALAJOd1QAuRUADHv9NDKNYV5T0YL-FCCOCKtJdSDfngazfsKHQ@mail.gmail.com>',NULL),('<1408833001-sup-5523@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-23 15:35:07',-25200,'2014-08-23 22:35:07',NULL,'[openstack-dev] [all] [ptls] The Czar system,\n	or how to scale PTLs','Excerpts from Dolph Mathews\'s message of 2014-08-22 09:45:37 -0700:\n> On Fri, Aug 22, 2014 at 11:32 AM, Zane Bitter <zbitter at redhat.com> wrote:\n> \n> > On 22/08/14 11:19, Thierry Carrez wrote:\n> >\n> >> Zane Bitter wrote:\n> >>\n> >>> On 22/08/14 08:33, Thierry Carrez wrote:\n> >>>\n> >>>> We also\n> >>>> still need someone to have the final say in case of deadlocked issues.\n> >>>>\n> >>>\n> >>> -1 we really don\'t.\n> >>>\n> >>\n> >> I know we disagree on that :)\n> >>\n> >\n> > No problem, you and I work in different programs so we can both get our\n> > way ;)\n> >\n> >\n> >  People say we don\'t have that many deadlocks in OpenStack for which the\n> >>>> PTL ultimate power is needed, so we could get rid of them. I\'d argue\n> >>>> that the main reason we don\'t have that many deadlocks in OpenStack is\n> >>>> precisely *because* we have a system to break them if they arise.\n> >>>>\n> >>>\n> >>> s/that many/any/ IME and I think that threatening to break a deadlock by\n> >>> fiat is just as bad as actually doing it. And by \'bad\' I mean\n> >>> community-poisoningly, trust-destroyingly bad.\n> >>>\n> >>\n> >> I guess I\'ve been active in too many dysfunctional free and open source\n> >> software projects -- I put a very high value on the ability to make a\n> >> final decision. Not being able to make a decision is about as\n> >> community-poisoning, and also results in inability to make any\n> >> significant change or decision.\n> >>\n> >\n> > I\'m all for getting a final decision, but a \'final\' decision that has been\n> > imposed from outside rather than internalised by the participants is...\n> > rarely final.\n> >\n> \n> The expectation of a PTL isn\'t to stomp around and make \"final\" decisions,\n> it\'s to step in when necessary and help both sides find the best solution.\n> To moderate.\n> \n\nHave we had many instances where a project\'s community divided into\ntwo camps and dug in to the point where they actually needed active\nmoderation? And in those cases, was the PTL not already on one side of\nsaid argument? I\'d prefer specific examples here.\n\n> >\n> > I have yet to see a deadlock in Heat that wasn\'t resolved by better\n> > communication.\n> \n> \n> Moderation == bettering communication. I\'m under the impression that you\n> and Thierry are agreeing here, just from opposite ends of the same spectrum.\n> \n\nI agree as well. PTL is a servant of the community, as any good leader\nis. If the PTL feels they have to drop the hammer, or if an impass is\nreached where they are asked to, it is because they have failed to get\neveryone communicating effectively, not because \"that\'s their job.\"\n\n\n','<CAC=h7gWvSx68OBOBphVbadwV_GnW1fqaKrid0+XBBVjLjdr=Ng@mail.gmail.com>',NULL),('<1408860470-sup-1402@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-23 23:10:09',-25200,'2014-08-24 06:10:09',NULL,'[Openstack] Keystone and Horizon questions','Excerpts from Marcus White\'s message of 2014-08-23 21:17:24 -0700:\n> Thank you Clint, had some follow up questions inline:)\n> \n> On Sun, Aug 24, 2014 at 12:12 AM, Clint Byrum <clint at fewbar.com> wrote:\n> > Excerpts from Marcus White\'s message of 2014-08-23 09:55:24 -0700:\n> >> Hello,\n> >> I had some keystone and Horizon questions, would apprecite it if\n> >> anyone can help:-)\n> >>\n> >> a. Does Keystone run as a service scaled across multiple nodes? Since\n> >> it would need access to shared data, I dont understand how it scales.\n> >>\n> >\n> > It stores data in various backends. The default is SQL, and many use\n> > LDAP to link with existing ID stores.\n> >\n> > It runs as a REST API in front of those data backends, and scales out\n> > quite nicely like any other web application.\n> \n> For SQL, if SQL runs on Keystone with every node, how is the data on\n> all nodes synchronized? Does the SQL server run externally as a\n> service? I read somewhere that SQL runs with keystone hence the\n> qstion.\n> \n\nYou read something false. The reality is it uses \"sqlalchemy\", so people\nuse MySQL, DB2, and Postgres, to name a few I\'ve seen bug reports for.\n\nMany organizations using MySQL/MariaDB with OpenStack use Galera\nsynchronous replication to allow HA and read scaling (writes are sent\nto all nodes).\n\n> >\n> >> b. If it does not run on multiple nodes as a service, how can it\n> >> handle a large number of concurrent requests?\n> >>\n> >> c. Is it expected to be a service that is exposed to the clients on a\n> >> public cloud? Does Rackspace today do it or any other public cloud?\n> >>\n> >\n> > Yes it is expected to be exposed. Users authenticate to keystone and are\n> > given a token which can be used to grant access to the other OpenStack\n> > services.\n> >\n> >> Some horizon questions also\n> >>\n> >> a. Does Horizon allow customization for specific services? Is there\n> >> any way to add value on top of it for my own Nova or Swift or Cinder\n> >> view, can I do that or is it whatever is done by the community the\n> >> only thing available?\n> >>\n> >\n> > It\'s open source. Go wild. ;) I believe there are hooks for\n> > skins/themes, and one can add plugins for other functionality.\n> Can I change the full view of how the Nova part or Cinder part of\n> Swift part looks completely and even present a different set of data?\n> \n\nI Really don\'t know. We\'ve reached the end of my knowledge of Horizon.\n\n\n','<CALAJOd3V1+G4=hm=yW2HLrj=qOGN3iPS25=aMDsjpDLMLZC1Tw@mail.gmail.com>',NULL),('<1408862135.24149.YahooMailNeo@web163604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-23 23:35:35',-25200,'2014-08-24 06:35:35',NULL,'[openstack-dev] unable to run unit tests','fwiw, clarkb advised me to to update testrepository with the following -\n\nbzr clone lp:testrepository\n\n\nto get a more meaningful error log output.\ni have version testrepository=0.0.18 after i updated.\n\nthanks!\ndaya\n\n\n________________________________\n From: Alex Leonhardt <aleonhardt.py at gmail.com>\nTo: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org> \nSent: Sunday, August 24, 2014 2:39 AM\nSubject: Re: [openstack-dev] unable to run unit tests\n \n\n\nThanks! So the real error is :?\n\nUnicodeDecodeError: \'ascii\' codec can\'t decode byte 0xe2 in position 36: ordinal not in range(128)\n\n\nAny clues ? :\\?\n\nAlex\n\n\n\n\nOn 23 August 2014 21:46, Doug Wiegley <dougw at a10networks.com> wrote:\n\nThat?s testr?s friendly way of telling you that you have an import error.\n>\n>Run it with the py26 environment and you?ll get a useful error.\n>\n>No, don?t ask me why.\n>\n>Doug\n>\n>\n>\n>\n>On 8/23/14, 2:33 PM, \"Alex Leonhardt\" <aleonhardt.py at gmail.com> wrote:\n>\n>>Hi All,\n>>\n>>\n>>after some fighting with installing all the bits - I can finally execute\n>>run_tests.sh but I still cannot seem to get it to work properly. This is\n>>what is returning :\n>>\n>>\n>>Non-zero exit code (2) from test listing.\n>>stdout=\'\\xb3)\\x01 at B8nova.tests.test_matchers.TestDictListMatches.test__str\n>>__\\xde|\\xe2\\x9e\\xb3)\\x01 at P@Enova.tests.test_matchers.TestDictListMatches.t\n>>est_describe_difference\\xfeL\\xc1\\xc4\\xb3)\\x01 at I?nova.tests.test_matchers.T\n>>estDictListMatches.test_matches_match\\x93\\xfau\\xb5\\xb3)\\x01 at M@Bnova.tests.\n>>test_matchers.TestDictListMatches.test_mismatch_details\\x18`>_\\xb3)\\x01=4n\n>>ova.tests.test_matchers.TestDictMatches.test__str__\\xca\\x9bK\\xb9\\xb3)\\x01@\n>>L at Anova.tests.test_matchers.TestDictMatches.test_describe_difference\\x94\\x\n>>b6\\x89\\\\\\xb3)\\x01 at E;nova.tests.test_matchers.TestDictMatches.test_matches_\n>>match^V\\xc2v\\xb3)\\x01 at H>nova.tests.test_matchers.TestDictMatches.test_mism\n>>atch_details\\x1bV\\x9e\\xff\\xb3)\\x01=4nova.tests.test_matchers.TestIsSubDict\n>>Of.test__str__\\xb8\\x06h(\\xb3)\\x01 at L@Anova.tests.test_matchers.TestIsSubDic\n>>tOf.test_describe_difference\\xd2\\xdd3\\xea\\xb3)\\x01 at E;nova.tests.test_match\n>>ers.TestIsSubDictOf.test_matches_match~qC\\xd0\\xb3)\\x01 at H>nova.tests.test_m\n>>atchers.TestIsSubDictOf.test_mismatch_detailsA1\\xa3l\\xb3)\\x01<3nova.tests.\n>>test_matchers.TestXMLMatches.test__str__C\\xd1E\\x13\\xb3)\\x01 at K@@nova.tests.\n>>test_matchers.TestXMLMatches.test_describe_difference\\xe0\\xa0\\xb2\\x80\\xb3)\n>>\\x01 at D:nova.tests.test_matchers.TestXMLMatches.test_matches_matchDT\\xe9h\\x\n>>b3)\\x01 at G=nova.tests.test_matchers.TestXMLMatches.test_mismatch_detailse\\x\n>>16\\xb1\\xad\\xb3\n>> `\\x80N\\xdb\\x17text/plain;charset=utf8\\rimport\n>>errors\\x80N\\xa8nova.tests.api.ec2.test_api\\nnova.tests.api.ec2.test_cinder\n>>_cloud\\nnova.tests.api.ec2.test_cloud\\nnova.tests.api.ec2.test_ec2_validat\n>>e\\nnova.tests.api.ec2.test_ec2utils\\nnova.tests.api.ec2.test_error_respons\n>>e\\nnova.tests.api.ec2.test_faults\\nnova.tests.api.ec2.test_middleware\\nnov\n>>a.tests.api.openstack.compute.contrib.test_admin_actions\\nnova.tests.api.o\n>>penstack.compute.contrib.test_agents\\nnova.tests.api.openstack.compute.con\n>>trib.test_aggregates\\nnova.tests.api.openstack.compute.contrib.test_attach\n>>_interfaces\\nnova.tests.api.openstack.compute.contrib.test_availability_zo\n>>ne\\nnova.tests.api.openstack.compute.contrib.test_baremetal_nodes\\nnova.te\n>>sts.api.openstack.compute.contrib.test_cells\\nnova.tests.api.openstack.com\n>>pute.contrib.test_certificates\\nnova.tests.api.openstack.compute.contrib.t\n>>est_cloudpipe\\nnova.tests.api.openstack.compute.contrib.test_cloudpipe_upd\n>>ate\\nnova.tests.api.openstack.compute.contrib.test_config_drive\\nnova.test\n>>s.api.openstack.compute.contrib.test_console_auth_tokens\\nnova.tests.api.o\n>>penstack.compute.contrib.test_console_output\\nnova.tests.api.openstack.com\n>>pute.contrib.test_consoles\\nnova.tests.api.openstack.compute.contrib.test_\n>>createserverext\\nnova.tests.api.openstack.compute.contrib.test_deferred_de\n>>lete\\nnova.tests.api.openstack.compute.contrib.test_disk_config\\nnova.test\n>>s.api.openstack.compute.contrib.test_evacuate\\nnova.tests.api.openstack.co\n>>mpute.contrib.test_extended_availability_zone\\nnova.tests.api.openstack.co\n>>mpute.contrib.test_extended_evacuate_find_host\\nnova.tests.api.openstack.c\n>>ompute.contrib.test_extended_hypervisors\\nnova.tests.api.openstack.compute\n>>.contrib.test_extended_ips\\nnova.tests.api.openstack.compute.contrib.test_\n>>extended_ips_mac\\nnova.tests.api.openstack.compute.contrib.test_extended_r\n>>escue_with_image\\nnova.tests.api.openstack.compute.contrib.test_extended_s\n>>erver_attributes\\nnova.tests.api.openstack.compute.contrib.test_extended_s\n>>tatus\\nnova.tests.api.openstack.compute.contrib.test_extended_virtual_inte\n>>rfaces_net\\nnova.tests.api.openstack.compute.contrib.test_extended_volumes\n>>\\nnova.tests.api.openstack.compute.contrib.test_fixed_ips\\nnova.tests.api.\n>>openstack.compute.contrib.test_flavor_access\\nnova.tests.api.openstack.com\n>>pute.contrib.test_flavor_disabled\\nnova.tests.api.openstack.compute.contri\n>>b.test_flavor_manage\\nnova.tests.api.openstack.compute.contrib.test_flavor\n>>_rxtx\\nnova.tests.api.openstack.compute.contrib.test_flavor_swap\\nnova.tes\n>>ts.api.openstack.compute.contrib.test_flavorextradata\\nnova.tests.api.open\n>>stack.compute.contrib.test_flavors_extra_specs\\nnova.tests.api.openstack.c\n>>ompute.contrib.test_floating_ip_bulk\\nnova.tests.api.openstack.compute.con\n>>trib.test_floating_ip_dns\\nnova.tests.api.openstack.compute.contrib.test_f\n>>loating_ip_pools\\nnova.tests.api.openstack.compute.contrib.test_floating_i\n>>ps\\nnova.tests.api.openstack.compute.contrib.test_fping\\nnova.tests.api.op\n>>enstack.compute.contrib.test_hide_server_addresses\\nnova.tests.api.opensta\n>>ck.compute.contrib.test_hosts\\nnova.tests.api.openstack.compute.contrib.te\n>>st_hypervisor_status\\nnova.tests.api.openstack.compute.contrib.test_hyperv\n>>isors\\nnova.tests.api.openstack.compute.contrib.test_image_size\\nnova.test\n>>s.api.openstack.compute.contrib.test_instance_actions\\nnova.tests.api.open\n>>stack.compute.contrib.test_instance_usage_audit_log\\nnova.tests.api.openst\n>>ack.compute.contrib.test_keypairs\\nnova.tests.api.openstack.compute.contri\n>>b.test_migrations\\nnova.tests.api.openstack.compute.contrib.test_multinic_\n>>xs\\nnova.tests.api.openstack.compute.contrib.test_networks\\nnova.tests.api\n>>.openstack.compute.contrib.test_neutron_security_groups\\nnova.tests.api.op\n>>enstack.compute.contrib.test_quota_classes\\nnova.tests.api.openstack.compu\n>>te.contrib.test_quotas\\nnova.tests.api.openstack.compute.contrib.test_resc\n>>ue\\nnova.tests.api.openstack.compute.contrib.test_scheduler_hints\\nnova.te\n>>sts.api.openstack.compute.contrib.test_security_group_default_rules\\nnova.\n>>tests.api.openstack.compute.contrib.test_security_groups\\nnova.tests.api.o\n>>penstack.compute.contrib.test_server_diagnostics\\nnova.tests.api.openstack\n>>.compute.contrib.test_server_external_events\\nnova.tests.api.openstack.com\n>>pute.contrib.test_server_groups\\nnova.tests.api.openstack.compute.contrib.\n>>test_server_password\\nnova.tests.api.openstack.compute.contrib.test_server\n>>_start_stop\\nnova.tests.api.openstack.compute.contrib.test_server_usage\\nn\n>>ova.tests.api.openstack.compute.contrib.test_services\\nnova.tests.api.open\n>>stack.compute.contrib.test_shelve\\nnova.tests.api.openstack.compute.contri\n>>b.test_simple_tenant_usage\\nnova.tests.api.openstack.compute.contrib.test_\n>>snapshots\\nnova.tests.api.openstack.compute.contrib.test_tenant_networks\\n\n>>nova.tests.api.openstack.compute.contrib.test_used_limits\\nnova.tests.api.\n>>openstack.compute.contrib.test_virtual_interfaces\\nnova.tests.api.openstac\n>>k.compute.contrib.test_volumes\\nnova.tests.api.openstack.compute.plugins.v\n>>3.test_access_ips\\nnova.tests.api.openstack.compute.plugins.v3.test_admin_\n>>actions\\nnova.tests.api.openstack.compute.plugins.v3.test_admin_password\\n\n>>nova.tests.api.openstack.compute.plugins.v3.test_agents\\nnova.tests.api.op\n>>enstack.compute.plugins.v3.test_aggregates\\nnova.tests.api.openstack.compu\n>>te.plugins.v3.test_attach_interfaces\\nnova.tests.api.openstack.compute.plu\n>>gins.v3.test_availability_zone\\nnova.tests.api.openstack.compute.plugins.v\n>>3.test_block_device_mapping\\nnova.tests.api.openstack.compute.plugins.v3.t\n>>est_cells\\nnova.tests.api.openstack.compute.plugins.v3.test_certificates\\n\n>>nova.tests.api.openstack.compute.plugins.v3.test_config_drive\\nnova.tests.\n>>api.openstack.compute.plugins.v3.test_console_auth_tokens\\nnova.tests.api.\n>>openstack.compute.plugins.v3.test_console_output\\nnova.tests.api.openstack\n>>.compute.plugins.v3.test_consoles\\nnova.tests.api.openstack.compute.plugin\n>>s.v3.test_create_backup\\nnova.tests.api.openstack.compute.plugins.v3.test_\n>>deferred_delete\\nnova.tests.api.openstack.compute.plugins.v3.test_evacuate\n>>\\nnova.tests.api.openstack.compute.plugins.v3.test_extended_availability_z\n>>one\\nnova.tests.api.openstack.compute.plugins.v3.test_extended_server_attr\n>>ibutes\\nnova.tests.api.openstack.compute.plugins.v3.test_extended_status\\n\n>>nova.tests.api.openstack.compute.plugins.v3.test_extended_volumes\\nnova.te\n>>sts.api.openstack.compute.plugins.v3.test_extension_info\\nnova.tests.api.o\n>>penstack.compute.plugins.v3.test_flavor_access\\nnova.tests.api.openstack.c\n>>ompute.plugins.v3.test_flavor_manage\\nnova.tests.api.openstack.compute.plu\n>>gins.v3.test_flavor_rxtx\\nnova.tests.api.openstack.compute.plugins.v3.test\n>>_flavors\\nnova.tests.api.openstack.compute.plugins.v3.test_flavors_extra_s\n>>pecs\\nnova.tests.api.openstack.compute.plugins.v3.test_hide_server_address\n>>es\\nnova.tests.api.openstack.compute.plugins.v3.test_hosts\\nnova.tests.api\n>>.openstack.compute.plugins.v3.test_hypervisors\\nnova.tests.api.openstack.c\n>>ompute.plugins.v3.test_instance_actions\\nnova.tests.api.openstack.compute.\n>>plugins.v3.test_keypairs\\nnova.tests.api.openstack.compute.plugins.v3.test\n>>_lock_server\\nnova.tests.api.openstack.compute.plugins.v3.test_migrate_ser\n>>ver\\nnova.tests.api.openstack.compute.plugins.v3.test_migrations\\nnova.tes\n>>ts.api.openstack.compute.plugins.v3.test_multinic\\nnova.tests.api.openstac\n>>k.compute.plugins.v3.test_multiple_create\\nnova.tests.api.openstack.comput\n>>e.plugins.v3.test_pause_server\\nnova.tests.api.openstack.compute.plugins.v\n>>3.test_pci\\nnova.tests.api.openstack.compute.plugins.v3.test_quota_sets\\nn\n>>ova.tests.api.openstack.compute.plugins.v3.test_remote_consoles\\nnova.test\n>>s.api.openstack.compute.plugins.v3.test_rescue\\nnova.tests.api.openstack.c\n>>ompute.plugins.v3.test_scheduler_hints\\nnova.tests.api.openstack.compute.p\n>>lugins.v3.test_security_groups\\nnova.tests.api.openstack.compute.plugins.v\n>>3.test_server_actions\\nnova.tests.api.openstack.compute.plugins.v3.test_se\n>>rver_diagnostics\\nnova.tests.api.openstack.compute.plugins.v3.test_server_\n>>external_events\\nnova.tests.api.openstack.compute.plugins.v3.test_server_m\n>>etadata\\nnova.tests.api.openstack.compute.plugins.v3.test_server_password\\\n>>nnova.tests.api.openstack.compute.plugins.v3.test_server_usage\\nnova.tests\n>>.api.openstack.compute.plugins.v3.test_servers\\nnova.tests.api.openstack.c\n>>ompute.plugins.v3.test_services\\nnova.tests.api.openstack.compute.plugins.\n>>v3.test_shelve\\nnova.tests.api.openstack.compute.plugins.v3.test_suspend_s\n>>erver\\nnova.tests.api.openstack.compute.plugins.v3.test_user_data\\nnova.te\n>>sts.api.openstack.compute.plugins.v3.test_versions\\nnova.tests.api.opensta\n>>ck.compute.test_api\\nnova.tests.api.openstack.compute.test_auth\\nnova.test\n>>s.api.openstack.compute.test_consoles\\nnova.tests.api.openstack.compute.te\n>>st_extensions\\nnova.tests.api.openstack.compute.test_flavors\\nnova.tests.a\n>>pi.openstack.compute.test_image_metadata\\nnova.tests.api.openstack.compute\n>>.test_images\\nnova.tests.api.openstack.compute.test_limits\\nnova.tests.api\n>>.openstack.compute.test_server_actions\\nnova.tests.api.openstack.compute.t\n>>est_server_metadata\\nnova.tests.api.openstack.compute.test_servers\\nnova.t\n>>ests.api.openstack.compute.test_urlmap\\nnova.tests.api.openstack.compute.t\n>>est_v3_auth\\nnova.tests.api.openstack.compute.test_v3_extensions\\nnova.tes\n>>ts.api.openstack.compute.test_versions\\nnova.tests.api.openstack.test_comm\n>>on\\nnova.tests.api.openstack.test_faults\\nnova.tests.api.openstack.test_ma\n>>pper\\nnova.tests.api.openstack.test_wsgi\\nnova.tests.api.openstack.test_xm\n>>lutil\\nnova.tests.api.test_auth\\nnova.tests.api.test_compute_req_id\\nnova.\n>>tests.api.test_sizelimit\\nnova.tests.api.test_validator\\nnova.tests.api.te\n>>st_wsgi\\nnova.tests.cells.test_cells_filters\\nnova.tests.cells.test_cells_\n>>manager\\nnova.tests.cells.test_cells_messaging\\nnova.tests.cells.test_cell\n>>s_rpc_driver\\nnova.tests.cells.test_cells_rpcapi\\nnova.tests.cells.test_ce\n>>lls_scheduler\\nnova.tests.cells.test_cells_state_manager\\nnova.tests.cells\n>>.test_cells_utils\\nnova.tests.cells.test_cells_weights\\nnova.tests.cert.te\n>>st_rpcapi\\nnova.tests.compute.monitors.test_cpu_monitor\\nnova.tests.comput\n>>e.monitors.test_monitors\\nnova.tests.compute.test_arch\\nnova.tests.compute\n>>.test_claims\\nnova.tests.compute.test_compute\\nnova.tests.compute.test_com\n>>pute_api\\nnova.tests.compute.test_compute_cells\\nnova.tests.compute.test_c\n>>ompute_mgr\\nnova.tests.compute.test_compute_utils\\nnova.tests.compute.test\n>>_compute_xen\\nnova.tests.compute.test_flavors\\nnova.tests.compute.test_hos\n>>t_api\\nnova.tests.compute.test_keypairs\\nnova.tests.compute.test_multiple_\n>>nodes\\nnova.tests.compute.test_resource_tracker\\nnova.tests.compute.test_r\n>>esources\\nnova.tests.compute.test_rpcapi\\nnova.tests.compute.test_shelve\\n\n>>nova.tests.compute.test_stats\\nnova.tests.compute.test_virtapi\\nnova.tests\n>>.compute.test_vmmode\\nnova.tests.conductor.tasks.test_live_migrate\\nnova.t\n>>ests.conductor.test_conductor\\nnova.tests.console.test_console\\nnova.tests\n>>.console.test_rpcapi\\nnova.tests.consoleauth.test_consoleauth\\nnova.tests.\n>>consoleauth.test_rpcapi\\nnova.tests.db.test_db_api\\nnova.tests.db.test_mig\n>>ration_utils\\nnova.tests.db.test_migrations\\nnova.tests.db.test_sqlite\\nno\n>>va.tests.image.test_fake\\nnova.tests.image.test_glance\\nnova.tests.image.t\n>>est_s3\\nnova.tests.image.test_transfer_modules\\nnova.tests.integrated.test\n>>_api_samples\\nnova.tests.integrated.test_extensions\\nnova.tests.integrated\n>>.test_login\\nnova.tests.integrated.test_multiprocess_api\\nnova.tests.integ\n>>rated.test_servers\\nnova.tests.integrated.test_xml\\nnova.tests.integrated.\n>>v3.test_access_ips\\nnova.tests.integrated.v3.test_admin_actions\\nnova.test\n>>s.integrated.v3.test_admin_password\\nnova.tests.integrated.v3.test_agents\\\n>>nnova.tests.integrated.v3.test_aggregates\\nnova.tests.integrated.v3.test_a\n>>ttach_interfaces\\nnova.tests.integrated.v3.test_availability_zone\\nnova.te\n>>sts.integrated.v3.test_cells\\nnova.tests.integrated.v3.test_certificates\\n\n>>nova.tests.integrated.v3.test_config_drive\\nnova.tests.integrated.v3.test_\n>>console_auth_tokens\\nnova.tests.integrated.v3.test_console_output\\nnova.te\n>>sts.integrated.v3.test_consoles\\nnova.tests.integrated.v3.test_create_back\n>>up\\nnova.tests.integrated.v3.test_deferred_delete\\nnova.tests.integrated.v\n>>3.test_evacuate\\nnova.tests.integrated.v3.test_extended_availability_zone\\\n>>nnova.tests.integrated.v3.test_extended_server_attributes\\nnova.tests.inte\n>>grated.v3.test_extended_status\\nnova.tests.integrated.v3.test_extended_vol\n>>umes\\nnova.tests.integrated.v3.test_extension_info\\nnova.tests.integrated.\n>>v3.test_flavor_access\\nnova.tests.integrated.v3.test_flavor_extraspecs\\nno\n>>va.tests.integrated.v3.test_flavor_manage\\nnova.tests.integrated.v3.test_f\n>>lavor_rxtx\\nnova.tests.integrated.v3.test_flavors\\nnova.tests.integrated.v\n>>3.test_hide_server_addresses\\nnova.tests.integrated.v3.test_hosts\\nnova.te\n>>sts.integrated.v3.test_hypervisors\\nnova.tests.integrated.v3.test_keypairs\n>>\\nnova.tests.integrated.v3.test_lock_server\\nnova.tests.integrated.v3.test\n>>_migrate_server\\nnova.tests.integrated.v3.test_migrations\\nnova.tests.inte\n>>grated.v3.test_multinic\\nnova.tests.integrated.v3.test_pause_server\\nnova.\n>>tests.integrated.v3.test_pci\\nnova.tests.integrated.v3.test_quota_sets\\nno\n>>va.tests.integrated.v3.test_remote_consoles\\nnova.tests.integrated.v3.test\n>>_rescue\\nnova.tests.integrated.v3.test_scheduler_hints\\nnova.tests.integra\n>>ted.v3.test_security_groups\\nnova.tests.integrated.v3.test_server_actions\\\n>>nnova.tests.integrated.v3.test_server_diagnostics\\nnova.tests.integrated.v\n>>3.test_server_external_events\\nnova.tests.integrated.v3.test_server_metada\n>>ta\\nnova.tests.integrated.v3.test_server_usage\\nnova.tests.integrated.v3.t\n>>est_servers\\nnova.tests.integrated.v3.test_servers_ips\\nnova.tests.integra\n>>ted.v3.test_services\\nnova.tests.integrated.v3.test_shelve\\nnova.tests.int\n>>egrated.v3.test_suspend_server\\nnova.tests.integrated.v3.test_user_data\\nn\n>>ova.tests.keymgr.test_conf_key_mgr\\nnova.tests.keymgr.test_key\\nnova.tests\n>>.keymgr.test_key_mgr\\nnova.tests.keymgr.test_mock_key_mgr\\nnova.tests.keym\n>>gr.test_not_implemented_key_mgr\\nnova.tests.keymgr.test_single_key_mgr\\nno\n>>va.tests.network.security_group.test_neutron_driver\\nnova.tests.network.te\n>>st_api\\nnova.tests.network.test_ipam_lib\\nnova.tests.network.test_linux_ne\n>>t\\nnova.tests.network.test_manager\\nnova.tests.network.test_network_info\\n\n>>nova.tests.network.test_neutronv2\\nnova.tests.network.test_rpcapi\\nnova.te\n>>sts.objects.test_agent\\nnova.tests.objects.test_aggregate\\nnova.tests.obje\n>>cts.test_block_device\\nnova.tests.objects.test_compute_node\\nnova.tests.ob\n>>jects.test_dns_domain\\nnova.tests.objects.test_ec2\\nnova.tests.objects.tes\n>>t_external_event\\nnova.tests.objects.test_fields\\nnova.tests.objects.test_\n>>fixed_ip\\nnova.tests.objects.test_flavor\\nnova.tests.objects.test_floating\n>>_ip\\nnova.tests.objects.test_instance\\nnova.tests.objects.test_instance_ac\n>>tion\\nnova.tests.objects.test_instance_fault\\nnova.tests.objects.test_inst\n>>ance_group\\nnova.tests.objects.test_instance_info_cache\\nnova.tests.object\n>>s.test_keypair\\nnova.tests.objects.test_migration\\nnova.tests.objects.test\n>>_network\\nnova.tests.objects.test_objects\\nnova.tests.objects.test_pci_dev\n>>ice\\nnova.tests.objects.test_quotas\\nnova.tests.objects.test_security_grou\n>>p\\nnova.tests.objects.test_security_group_rule\\nnova.tests.objects.test_se\n>>rvice\\nnova.tests.objects.test_virtual_interface\\nnova.tests.pci.test_pci_\n>>device\\nnova.tests.pci.test_pci_devspec\\nnova.tests.pci.test_pci_manager\\n\n>>nova.tests.pci.test_pci_request\\nnova.tests.pci.test_pci_stats\\nnova.tests\n>>.pci.test_pci_utils\\nnova.tests.pci.test_pci_whitelist\\nnova.tests.schedul\n>>er.test_baremetal_host_manager\\nnova.tests.scheduler.test_caching_schedule\n>>r\\nnova.tests.scheduler.test_chance_scheduler\\nnova.tests.scheduler.test_f\n>>ilter_scheduler\\nnova.tests.scheduler.test_filters\\nnova.tests.scheduler.t\n>>est_filters_utils\\nnova.tests.scheduler.test_host_filters\\nnova.tests.sche\n>>duler.test_host_manager\\nnova.tests.scheduler.test_ironic_host_manager\\nno\n>>va.tests.scheduler.test_rpcapi\\nnova.tests.scheduler.test_scheduler\\nnova.\n>>tests.scheduler.test_scheduler_options\\nnova.tests.scheduler.test_schedule\n>>r_utils\\nnova.tests.scheduler.test_weights\\nnova.tests.servicegroup.test_d\n>>b_servicegroup\\nnova.tests.servicegroup.test_mc_servicegroup\\nnova.tests.s\n>>ervicegroup.test_zk_driver\\nnova.tests.test_api_validation\\nnova.tests.tes\n>>t_availability_zones\\nnova.tests.test_baserpc\\nnova.tests.test_bdm\\nnova.t\n>>ests.test_block_device\\nnova.tests.test_cinder\\nnova.tests.test_configdriv\n>>e2\\nnova.tests.test_context\\nnova.tests.test_crypto\\nnova.tests.test_excep\n>>tion\\nnova.tests.test_flavors\\nnova.tests.test_hacking\\nnova.tests.test_ho\n>>oks\\nnova.tests.test_instance_types_extra_specs\\nnova.tests.test_iptables_\n>>network\\nnova.tests.test_ipv6\\nnova.tests.test_linuxscsi\\nnova.tests.test_\n>>loadables\\nnova.tests.test_metadata\\nnova.tests.test_notifications\\nnova.t\n>>ests.test_nova_manage\\nnova.tests.test_objectstore\\nnova.tests.test_pipeli\n>>b\\nnova.tests.test_policy\\nnova.tests.test_quota\\nnova.tests.test_safeutil\n>>s\\nnova.tests.test_service\\nnova.tests.test_test\\nnova.tests.test_test_uti\n>>ls\\nnova.tests.test_utils\\nnova.tests.test_versions\\nnova.tests.test_weigh\n>>ts\\nnova.tests.test_wsgi\\nnova.tests.virt.baremetal.db.test_bm_interface\\n\n>>nova.tests.virt.baremetal.db.test_bm_node\\nnova.tests.virt.baremetal.test_\n>>driver\\nnova.tests.virt.baremetal.test_iboot_pdu\\nnova.tests.virt.baremeta\n>>l.test_ipmi\\nnova.tests.virt.baremetal.test_nova_baremetal_deploy_helper\\n\n>>nova.tests.virt.baremetal.test_nova_baremetal_manage\\nnova.tests.virt.bare\n>>metal.test_pxe\\nnova.tests.virt.baremetal.test_tilera\\nnova.tests.virt.bar\n>>emetal.test_tilera_pdu\\nnova.tests.virt.baremetal.test_utils\\nnova.tests.v\n>>irt.baremetal.test_virtual_power_driver\\nnova.tests.virt.baremetal.test_vo\n>>lume_driver\\nnova.tests.virt.disk.mount.test_loop\\nnova.tests.virt.disk.mo\n>>unt.test_nbd\\nnova.tests.virt.disk.test_api\\nnova.tests.virt.disk.test_inj\n>>ect\\nnova.tests.virt.disk.vfs.test_guestfs\\nnova.tests.virt.disk.vfs.test_\n>>localfs\\nnova.tests.virt.hyperv.test_basevolumeutils\\nnova.tests.virt.hype\n>>rv.test_hostutils\\nnova.tests.virt.hyperv.test_hypervapi\\nnova.tests.virt.\n>>hyperv.test_migrationops\\nnova.tests.virt.hyperv.test_networkutilsv2\\nnova\n>>.tests.virt.hyperv.test_pathutils\\nnova.tests.virt.hyperv.test_rdpconsoleu\n>>tils\\nnova.tests.virt.hyperv.test_rdpconsoleutilsv2\\nnova.tests.virt.hyper\n>>v.test_utilsfactory\\nnova.tests.virt.hyperv.test_vhdutils\\nnova.tests.virt\n>>.hyperv.test_vhdutilsv2\\nnova.tests.virt.hyperv.test_vmops\\nnova.tests.vir\n>>t.hyperv.test_vmutils\\nnova.tests.virt.hyperv.test_vmutilsv2\\nnova.tests.v\n>>irt.hyperv.test_volumeutils\\nnova.tests.virt.hyperv.test_volumeutilsv2\\nno\n>>va.tests.virt.libvirt.test_blockinfo\\nnova.tests.virt.libvirt.test_config\\\n>>nnova.tests.virt.libvirt.test_designer\\nnova.tests.virt.libvirt.test_dmcry\n>>pt\\nnova.tests.virt.libvirt.test_driver\\nnova.tests.virt.libvirt.test_fake\n>>libvirt\\nnova.tests.virt.libvirt.test_imagebackend\\nnova.tests.virt.libvir\n>>t.test_imagecache\\nnova.tests.virt.libvirt.test_lvm\\nnova.tests.virt.libvi\n>>rt.test_rbd\\nnova.tests.virt.libvirt.test_utils\\nnova.tests.virt.libvirt.t\n>>est_vif\\nnova.tests.virt.libvirt.test_volume\\nnova.tests.virt.test_block_d\n>>evice\\nnova.tests.virt.test_configdrive\\nnova.tests.virt.test_diagnostics\\\n>>nnova.tests.virt.test_driver\\nnova.tests.virt.test_events\\nnova.tests.virt\n>>.test_hardware\\nnova.tests.virt.test_imagecache\\nnova.tests.virt.test_imag\n>>es\\nnova.tests.virt.test_ironic_api_contracts\\nnova.tests.virt.test_virt\\n\n>>nova.tests.virt.test_virt_drivers\\nnova.tests.virt.test_volumeutils\\nnova.\n>>tests.virt.vmwareapi.test_configdrive\\nnova.tests.virt.vmwareapi.test_driv\n>>er_api\\nnova.tests.virt.vmwareapi.test_ds_util\\nnova.tests.virt.vmwareapi.\n>>test_ds_util_datastore_selection\\nnova.tests.virt.vmwareapi.test_error_uti\n>>l\\nnova.tests.virt.vmwareapi.test_imagecache\\nnova.tests.virt.vmwareapi.te\n>>st_io_util\\nnova.tests.virt.vmwareapi.test_read_write_util\\nnova.tests.vir\n>>t.vmwareapi.test_vif\\nnova.tests.virt.vmwareapi.test_vim_util\\nnova.tests.\n>>virt.vmwareapi.test_vm_util\\nnova.tests.virt.vmwareapi.test_vmops\\nnova.te\n>>sts.virt.vmwareapi.test_vmware_images\\nnova.tests.virt.vmwareapi.test_volu\n>>meops\\nnova.tests.virt.xenapi.client.test_objects\\nnova.tests.virt.xenapi.\n>>client.test_session\\nnova.tests.virt.xenapi.image.test_bittorrent\\nnova.te\n>>sts.virt.xenapi.image.test_glance\\nnova.tests.virt.xenapi.image.test_utils\n>>\\nnova.tests.virt.xenapi.image.test_vdi_through_dev\\nnova.tests.virt.xenap\n>>i.test_agent\\nnova.tests.virt.xenapi.test_driver\\nnova.tests.virt.xenapi.t\n>>est_network_utils\\nnova.tests.virt.xenapi.test_vm_utils\\nnova.tests.virt.x\n>>enapi.test_vmops\\nnova.tests.virt.xenapi.test_volume_utils\\nnova.tests.vir\n>>t.xenapi.test_volumeops\\nnova.tests.virt.xenapi.test_xenapi\\nnova.tests.vo\n>>lume.encryptors.test_base\\nnova.tests.volume.encryptors.test_cryptsetup\\nn\n>>ova.tests.volume.encryptors.test_luks\\nnova.tests.volume.encryptors.test_n\n>>op\\nnova.tests.volume.test_cinder~\\xa1\n>> +\', stderr=None\n>>\n>>\n>>\n>>Anyone seen this or has any pointer ?\n>>\n>>\n>>Am running this on fedora 20, fwiw.\n>>\n>>\n>>Alex\n>>\n>>\n>>\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140823/cbe9d2a6/attachment-0001.html>\n\n','<CACSH3Mv6jzA+UX-TMd2jD3zn_Tg6=_YyLepNvJ7GdEk=Kc2jqw@mail.gmail.com>',NULL),('<1408870740-sup-4812@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-24 02:00:21',-25200,'2014-08-24 09:00:21',NULL,'[openstack-dev] [heat] \"heat.conf.sample is not up to date\"','Guessing this is due to the new tox feature which randomizes python\'s\nhash seed.\n\nExcerpts from Mike Spreitzer\'s message of 2014-08-24 00:10:42 -0700:\n> What is going on with this?  If I do a fresh clone of heat and run `tox \n> -epep8` then I get that complaint.  If I then run the recommended command \n> to fix it, and then `tox -epep8` again, I get the same complaint again --- \n> and with different differences exhibited!  The email below carries a \n> typescript showing this.\n> \n> What I really need to know is what to do when committing a change that \n> really does require a change in the sample configuration file.  Of course \n> I tried running generate_sample.sh, but `tox -epep8` still complains. What \n> is the right procedure to get a correct sample committed?  BTW, I am doing \n> the following admittedly risky thing: I run DevStack, and make my changes \n> in /opt/stack/heat/.\n> \n> Thanks,\n> Mike\n> \n> ----- Forwarded by Mike Spreitzer/Watson/IBM on 08/24/2014 03:03 AM -----\n> \n> From:   ubuntu at mjs-dstk-821a (Ubuntu)\n> To:     Mike Spreitzer/Watson/IBM at IBMUS, \n> Date:   08/24/2014 02:55 AM\n> Subject:        fresh flake fail\n> \n> \n> \n> ubuntu at mjs-dstk-821a:~/code$ git clone \n> git://git.openstack.org/openstack/heat.git\n> Cloning into \'heat\'...\n> remote: Counting objects: 49690, done.\n> remote: Compressing objects: 100% (19765/19765), done.\n> remote: Total 49690 (delta 36660), reused 39014 (delta 26526)\n> Receiving objects: 100% (49690/49690), 7.92 MiB | 7.29 MiB/s, done.\n> Resolving deltas: 100% (36660/36660), done.\n> Checking connectivity... done.\n> ubuntu at mjs-dstk-821a:~/code$ cd heat\n> ubuntu at mjs-dstk-821a:~/code/heat$ tox -epep8\n> pep8 create: /home/ubuntu/code/heat/.tox/pep8\n> pep8 installdeps: -r/home/ubuntu/code/heat/requirements.txt, \n> -r/home/ubuntu/code/heat/test-requirements.txt\n> pep8 develop-inst: /home/ubuntu/code/heat\n> pep8 runtests: PYTHONHASHSEED=\'0\'\n> pep8 runtests: commands[0] | flake8 heat bin/heat-api bin/heat-api-cfn \n> bin/heat-api-cloudwatch bin/heat-engine bin/heat-manage contrib\n> pep8 runtests: commands[1] | \n> /home/ubuntu/code/heat/tools/config/check_uptodate.sh\n> --- /tmp/heat.ep2CBe/heat.conf.sample2014-08-24 06:52:54.164849999 +0000\n> +++ etc/heat/heat.conf.sample2014-08-24 06:48:13.664849999 +0000\n> @@ -164,7 +164,7 @@\n>  \n> #allowed_rpc_exception_modules=oslo.messaging.exceptions,nova.exception,cinder.exception,exceptions\n>  \n>  # Qpid broker hostname. (string value)\n> -#qpid_hostname=heat\n> +#qpid_hostname=localhost\n>  \n>  # Qpid broker port. (integer value)\n>  #qpid_port=5672\n> @@ -221,7 +221,7 @@\n>  \n>  # The RabbitMQ broker address where a single node is used.\n>  # (string value)\n> -#rabbit_host=heat\n> +#rabbit_host=localhost\n>  \n>  # The RabbitMQ broker port where a single node is used.\n>  # (integer value)\n> check_uptodate.sh: heat.conf.sample is not up to date.\n> check_uptodate.sh: Please run \n> /home/ubuntu/code/heat/tools/config/generate_sample.sh.\n> ERROR: InvocationError: \n> \'/home/ubuntu/code/heat/tools/config/check_uptodate.sh\'\n> pep8 runtests: commands[2] | \n> /home/ubuntu/code/heat/tools/requirements_style_check.sh requirements.txt \n> test-requirements.txt\n> pep8 runtests: commands[3] | bash -c find heat -type f -regex \'.*\\.pot?\' \n> -print0|xargs -0 -n 1 msgfmt --check-format -o /dev/null\n> ___________________________________ summary \n> ____________________________________\n> ERROR:   pep8: commands failed\n> ubuntu at mjs-dstk-821a:~/code/heat$ \n> ubuntu at mjs-dstk-821a:~/code/heat$ \n> ubuntu at mjs-dstk-821a:~/code/heat$ tools/config/generate_sample.sh\n> ubuntu at mjs-dstk-821a:~/code/heat$ \n> ubuntu at mjs-dstk-821a:~/code/heat$ \n> ubuntu at mjs-dstk-821a:~/code/heat$ \n> ubuntu at mjs-dstk-821a:~/code/heat$ tox -epep8\n> pep8 develop-inst-noop: /home/ubuntu/code/heat\n> pep8 runtests: PYTHONHASHSEED=\'0\'\n> pep8 runtests: commands[0] | flake8 heat bin/heat-api bin/heat-api-cfn \n> bin/heat-api-cloudwatch bin/heat-engine bin/heat-manage contrib\n> pep8 runtests: commands[1] | \n> /home/ubuntu/code/heat/tools/config/check_uptodate.sh\n> --- /tmp/heat.DqIhK5/heat.conf.sample2014-08-24 06:54:34.628849999 +0000\n> +++ etc/heat/heat.conf.sample2014-08-24 06:53:51.540849999 +0000\n> @@ -159,10 +159,6 @@\n>  # Size of RPC connection pool. (integer value)\n>  #rpc_conn_pool_size=30\n>  \n> -# Modules of exceptions that are permitted to be recreated\n> -# upon receiving exception data from an rpc call. (list value)\n> -#allowed_rpc_exception_modules=oslo.messaging.exceptions,nova.exception,cinder.exception,exceptions\n> -\n>  # Qpid broker hostname. (string value)\n>  #qpid_hostname=heat\n>  \n> @@ -301,15 +297,6 @@\n>  # Heartbeat time-to-live. (integer value)\n>  #matchmaker_heartbeat_ttl=600\n>  \n> -# Host to locate redis. (string value)\n> -#host=127.0.0.1\n> -\n> -# Use this port to connect to redis host. (integer value)\n> -#port=6379\n> -\n> -# Password for Redis server (optional). (string value)\n> -#password=<None>\n> -\n>  # Size of RPC greenthread pool. (integer value)\n>  #rpc_thread_pool_size=64\n>  \n> @@ -1229,6 +1216,22 @@\n>  #hash_algorithms=md5\n>  \n>  \n> +[matchmaker_redis]\n> +\n> +#\n> +# Options defined in oslo.messaging\n> +#\n> +\n> +# Host to locate redis. (string value)\n> +#host=127.0.0.1\n> +\n> +# Use this port to connect to redis host. (integer value)\n> +#port=6379\n> +\n> +# Password for Redis server (optional). (string value)\n> +#password=<None>\n> +\n> +\n>  [matchmaker_ring]\n>  \n>  #\n> check_uptodate.sh: heat.conf.sample is not up to date.\n> check_uptodate.sh: Please run \n> /home/ubuntu/code/heat/tools/config/generate_sample.sh.\n> ERROR: InvocationError: \n> \'/home/ubuntu/code/heat/tools/config/check_uptodate.sh\'\n> pep8 runtests: commands[2] | \n> /home/ubuntu/code/heat/tools/requirements_style_check.sh requirements.txt \n> test-requirements.txt\n> pep8 runtests: commands[3] | bash -c find heat -type f -regex \'.*\\.pot?\' \n> -print0|xargs -0 -n 1 msgfmt --check-format -o /dev/null\n> ___________________________________ summary \n\n\n','<OF82DA75A7.22AD1766-ON85257D3E.0026CB71-85257D3E.00276F4D@us.ibm.com>',NULL),('<1408906226.999259.156203653.598B0609@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-24 11:50:26',-25200,'2014-08-24 18:50:26',NULL,'[openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax\n additions/changes','On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote:\n> Hi,\n> \n> With the ongoing development of LBaaS v2, support for v2 of LBaaS in\n> neutronclient is also being developed, as can be seen in [1].\n> The current implementation adds a new syntax for v2; Whereas the v1\n> syntax is \'neutron lb-<object>-<command>\', the new v2 syntax is \'neutron\n> lbaas-<object>-<command>\'.\n> \n> We fear that this can lead to some level of confusion on the users\'\n> side. Currently, nothing prevents a user from trying to create a v1 pool\n> and then trying to add v2 members. Of course the second command will\n> fail, but the error message will be a non-intuitive one.\n> \n> This was discussed at the last weekly IRC meeting ([2]). Some bulletins:\n> \n> 1. As was discussed in the hackathon, there shouldn\'t be more than one\n> version active at any given time - either v1 or v2. Also, using the same\n> syntax for both v1 and v2 is not a good idea (db migration will be\n> difficult when both version share syntax). We believe this should also\n> be enforced in the server side.\n> \n> 2. Therefor, there should be some configuration to specifically enable\n> either version (not both) in case LBaaS is needed. In this case, the\n> other version is disabled (ie. a REST query for non-active version\n> should return a \"not activated\" error). Additionally, adding a\n> \'lb-version\' command to return the version currently active seems like a\n> good user-facing idea. We should see how this doesn\'t negatively effect\n> the db migration process (for example, allowing read-only commands for\n> both versions?)\n> \n> 3. Another decision that\'s needed to be made is the syntax for v2. As\n> mentioned, the current new syntax is \'neutron lbaas-<object>-<command>\'\n> (against the old \'lb-<object>-<action>\'), keeping in mind that once v1\n> is deprecated, a syntax like \'lbv2-<object>-<action>\' would be probably\n> unwanted. Is \'lbaas-<object>-<command>\' okay with everyone?\n> \n> 4. If we are going for different API between versions, appropriate\n> patches also need to be written for lbaas-related scripts and also\n> Tempest, and their maintainers should probably be notified.\n> \n> Are there any issues with one of the points raised above? Does anyone\n> see any other problems which we forgot to write down?\n> \n> Thanks a lot,\n> \n> John Schwarz, Yair Fried,\n> Redhat.\n> \n> [1]: https://review.openstack.org/#/c/111475\n> [2]:\n> http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nAs a user of both the neutron API and python-neutronclient it would be\nmuch better to have the client use a common set of commands for both v1\nand v2 where the specific version used is determined by the keystone\ncatalog or other overriding information. I don\'t want to have to\nremember two different sets of commands with potentially two different\noutputs. Client libraries exist so that users don\'t have to think about\nthis stuff.\n\nThis should prevent confusion as users will use a common version unless\nthey specifically provide an override of some sort.\n\nClark\n\n\n','<53F9EA97.1040003@redhat.com>',NULL),('<1408946297042.4478@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-25 05:51:43',0,'2014-08-25 05:51:43',NULL,'[Openstack] Fwd: nova instance','Hi Javed,\n\n\nThe error \"[Error: No valid host was found. ]. \" means, scheduler is not able to find any computes with required resources.\n\n\nPlease ensure that compute service is running and it has required resources.\n\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in |\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: javed alam <javedamar at gmail.com>\nSent: Saturday, August 23, 2014 6:09 PM\nTo: openstack; Masoom Alam\nSubject: [Openstack] Fwd: nova instance\n\n\n\nhello\ni m new to openstack so need some help\nwen ever i try to launch an instance it gives me the error\n\"Error: Failed to launch instance \"nova_testing\": Please try again later [Error: No valid host was found. ]. \"\n\ni m even unable to find the log files.\n\n\ncan any body help me on this\n\nthanks in advance\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140825/93f0750e/attachment.html>\n\n','<CANmWEO2asCmK-_XTjRAhyqUJQYNsQ-xD-t1YjAqx-nzvOPqaAw@mail.gmail.com>',NULL),('<1408953613.4324.13.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 10:00:13',7200,'2014-08-25 08:00:13',NULL,'[openstack-dev] [neutron][ml2] Openvswitch agent support for\n non promic mode adapters','Hi Irena, \nthanks for your reply. Yes sure, collaboration would be great. \nDo you already have a blueprint out there? Maybe wen can synchup this\nweek to discuss more details? Cause I would like to understand what\nexactly you\'re looking for. Normally I\'m available form 7 UTC to 16 utc\n(today only until 13 utc). My irc name is scheuran. Maybe we can get in\ncontact this week!\n\nYou also where talking about sriov. I saw some blueprint mentioning\nsriov & macvtap. Do you have any insights into this one, too? What we\nalso would like to do is to introduce macvtap as network virtualization\noption. Macvtap also registers mac addresses to network adapters...\n\n\nThanks,\nAndreas\n\n\nOn Sun, 2014-08-24 at 08:51 +0000, Irena Berezovsky wrote:\n> Hi Andreas,\n> Thank you for this initiative.\n> We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. \n> Please let me know if you would like to collaborate on this effort.\n> \n> BR,\n> Irena\n> \n> -----Original Message-----\n> From: Andreas Scheuring [mailto:scheuran at linux.vnet.ibm.com] \n> Sent: Friday, August 22, 2014 11:16 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters\n> \n> Thanks for your feedback. \n> \n> No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. \n> But if that helps I can sit down and start some prototyping while I\'m preparing a blueprint spec in parallel. \n> \n> The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community.\n> But of course advice and feedback of experienced neutron developers is essential!\n> \n> So I will proceed like this\n> - Create a blueprint\n> - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc)\n> - Upload a spec (as soon as the repo is available for K)\n> \n> Does that make sense for you?\n> \n> Thanks,\n> Andreas\n> \n> \n> \n> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:\n> > I think this sounds reasonable. Do you have code for this already, or \n> > are you looking for a developer to help implement it?\n> > \n> > \n> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring \n> > <scheuran at linux.vnet.ibm.com> wrote:\n> >         Hi,\n> >         last week I started discussing an extension to the existing\n> >         neutron\n> >         openvswitch agent to support network adapters that are not in\n> >         promiscuous mode. Now I would like to enhance the round to get\n> >         feedback\n> >         from a broader audience via the mailing list.\n> >         \n> >         \n> >         The Problem\n> >         When driving vlan or flat networking, openvswitch requires an\n> >         network\n> >         adapter in promiscuous mode.\n> >         \n> >         \n> >         Why not having promiscuous mode in your adapter?\n> >         - Admins like to have full control over their environment and\n> >         which\n> >         network packets enter the system.\n> >         - The network adapter just does not have support for it.\n> >         \n> >         \n> >         What to do?\n> >         Linux net-dev driver offer an interface to manually register\n> >         additional\n> >         mac addresses (also called secondary unicast addresses).\n> >         Exploiting this\n> >         one can register additional mac addresses to the network\n> >         adapter. This\n> >         also works via a well known ip user space tool.\n> >         \n> >         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`\n> >         \n> >         \n> >         What to do in openstack?\n> >         As neutron is aware of all the mac addresses that are in use\n> >         it\'s the\n> >         perfect candidate for doing the mac registrations. The idea is\n> >         to modify\n> >         the neutron openvswitch agent that it does the registration on\n> >         \"port\n> >         add\" and \"port remove\" via the bridge command.\n> >         There would be a new optional configuration parameter,\n> >         something like\n> >         \'non-promisc-mode\' that is by default set to false. Only when\n> >         set to\n> >         true, macs get manually registered. Otherwise the agent\n> >         behaves like it\n> >         does today. So I guess only very little changes to the agent\n> >         code are\n> >         required. From my current point of view we do not need any\n> >         changes to\n> >         the ml2 plug-in.\n> >         \n> >         \n> >         Blueprint or a bug?\n> >         I guess it\'s a blueprint.\n> >         \n> >         What\'s the timeframe?\n> >         K would be great.\n> >         \n> >         \n> >         \n> >         I would be thankful for any feedback on this! Feel free to\n> >         contact me\n> >         anytime. Thanks in advance!\n> >         \n> >         Regards,\n> >         Andreas\n> >         \n> >         (irc: scheuran)\n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > --\n> > Kevin Benton\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n\n\n','<10c5543d2ae944de87aff839e11b8cdf@AMSPR05MB406.eurprd05.prod.outlook.com>',NULL),('<1408980924.5509.9.camel@graham-work-laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 15:35:29',0,'2014-08-25 15:35:29',NULL,'[openstack-dev] [designate] [neutron] designate and neutron\n integration','We don\'t actually envisage a bind9 views solution in the near future.\n\nI would imagine (this has not yet been discussed) that we would have\nservice VMs (one per network / tenant) connected to the neutron network,\nand a control network (like how Trove are doing the neutron\nintegration).\n\nDesignate would then manage that server as if it is in its own pool.\n\nWe would need to find a way for neutrons dnsmasq to pass certain queries\nto the designate controlled server, but that should not be an issue\n(AFAIK it can be done with a few lines in the dnsmasq config).\n\n\nOn Mon, 2014-08-25 at 08:59 +0000, Zang MingJie wrote:\n> I don\'t like the idea that uses bind9 views to split networks, due to\n> follow reasons:\n> \n> the designate may not or hard to know the router\'s public address\n> non-router may exist for some isolate networks\n> there is no routes in our dhcp namespace currently\n> \n> I suggest run one bind9 instance for each network which has domain\n> support, and introduce a designate-bind9-agent to control the bind9\n> instances.\n> \n> +--------------+--------------+------------- network\n> |              |              |\n> +---------+    +---------+    +---------+\n> |instance |    | dnsmasq |    |  bind9  |\n> +---------+    +---------+    +---------+ \n> \n>                |              |\n>                +----------+   +---------+\n>                |dhcp agent|   |dns agent|\n>                +----------+   +---------+\n> \n> On Tue, Aug 12, 2014 at 1:41 AM, Hayes, Graham <graham.hayes at hp.com>\n> wrote:\n> >\n> > kazuhiro MIYASHITA,\n> >\n> > As designate progresses with server pools, we aim to have support\n> for a\n> > \'private\' dns server, that could run within a neutron network - is\n> that\n> > the level of integration you were referring to?\n> >\n> > That is, for the time being, a long term goal, and not covered by\n> Carl\'s\n> > Kilo blueprint.\n> >\n> > We talked with both people from both Neutron and Nova in Atlanta,\n> and\n> > worked out the first steps for designate / neutron integration (auto\n> > provisioning of records)\n> >\n> > For that level of integration, we are assuming that a neutron router\n> > will be involved in DNS queries within a network.\n> >\n> > Long term I would prefer to see a \'private pool\' connecting directly\n> to\n> > the Network2 (like any other service VM (LBaaS etc)) and have\n> dnsmasq\n> > pass on only records hosted by that \'private pool\' to designate.\n> >\n> > This is all yet to be fleshed out, so I am open to suggestions. It\n> > requires that we complete server pools, and that work is only just\n> > starting (it was the main focus of our mid-cycle 2 weeks ago).\n> >\n> > Graham\n> >\n> > On Mon, 2014-08-11 at 11:02 -0600, Carl Baldwin wrote:\n> > > kazuhiro MIYASHITA,\n> > >\n> > > I have done a lot of thinking about this.  I have a blueprint on\n> hold\n> > > until Kilo for Neutron/Designate integration [1].\n> > >\n> > > However, my blueprint doesn\'t quite address what you are going\n> after\n> > > here.  An assumption that I have made is that Designate is an\n> external\n> > > or internet facing service so a Neutron router needs to be in the\n> > > datapath to carry requests from dnsmasq to an external network.\n>  The\n> > > advantage of this is that it is how Neutron works today so there\n> is no\n> > > new development needed.\n> > >\n> > > Could you elaborate on the advantages of connecting dnsmasq\n> directly\n> > > to the external network where Designate will be available?\n> > >\n> > > Carl\n> > >\n> > > [1] https://review.openstack.org/#/c/88624/\n> > >\n> > > On Mon, Aug 11, 2014 at 7:51 AM, Miyashita, Kazuhiro\n> > > <miyakz at jp.fujitsu.com> wrote:\n> > > > Hi,\n> > > >\n> > > > I want to ask about neutron and designate integration.\n> > > > I think dnsmasq fowards DNS request from instance to designate\n> is better.\n> > > >\n> > > >                            +------------------------+\n> > > >                            |DNS server(designate)   |\n> > > >                            +------------------------+\n> > > >                                 |\n> > > > -----------------+--------------+------ Network1\n> > > >                  |\n> > > >               +--------+\n> > > >               |dnsmasq |\n> > > >               +--------+\n> > > >                 |\n> > > > -+--------------+---------------------- Network2\n> > > >  |\n> > > > +---------+\n> > > > |instance |\n> > > > +---------+\n> > > >\n> > > > Because it\'s simpler than virtual router connects Network1 and\n> Network2.\n> > > > If router connects network, instance should know where DNS\n> server is. it is complicated.\n> > > > dnsmasq returns its ip address as dns server in DHCP replay by\n> ordinary, so,\n> > > > I think good dnsmasq becomes like a gateway to designate.\n> > > >\n> > > > But, I can\'t connect dnsmasq to Network1. because of today\'s\n> neutron design.\n> > > >\n> > > > Question:\n> > > >   Does designate design team have a plan such as above\n> integration?\n> > > >   or other integration design?\n> > > >\n> > > > *1: Network1 and Network2 are deployed by neutron.\n> > > > *2: neutron deploys dnsmasq as a dhcp server.\n> > > >     dnsmasq can forward DNS request.\n> > > >\n> > > > Thanks,\n> > > >\n> > > > kazuhiro MIYASHITA\n> > > >\n> > > >\n> > > >\n> > > >\n> > > > _______________________________________________\n> > > > OpenStack-dev mailing list\n> > > > OpenStack-dev at lists.openstack.org\n> > > >\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/fd0a0148/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/fd0a0148/attachment.pgp>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/x-pkcs7-signature\nSize: 6961 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/fd0a0148/attachment.bin>\n\n','<CAOrge3rmhgTGars7X+jeFvgxj9Lg95o1V2MCRS8Luc+a+pkMpw@mail.gmail.com>',NULL),('<1408993733.16118.15.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 19:06:15',0,'2014-08-25 19:06:15',NULL,'[openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax\n additions/changes','Hi John,\nComments in-line\n\nOn Sun, 2014-08-24 at 16:37 +0300, John Schwarz wrote:\n> Hi,\n> \n> With the ongoing development of LBaaS v2, support for v2 of LBaaS in\n> neutronclient is also being developed, as can be seen in [1].\n> The current implementation adds a new syntax for v2; Whereas the v1\n> syntax is \'neutron lb-<object>-<command>\', the new v2 syntax is \'neutron\n> lbaas-<object>-<command>\'.\n> \n> We fear that this can lead to some level of confusion on the users\'\n> side. Currently, nothing prevents a user from trying to create a v1 pool\n> and then trying to add v2 members. Of course the second command will\n> fail, but the error message will be a non-intuitive one.\n> \n> This was discussed at the last weekly IRC meeting ([2]). Some bulletins:\n> \n> 1. As was discussed in the hackathon, there shouldn\'t be more than one\n> version active at any given time - either v1 or v2. Also, using the same\n> syntax for both v1 and v2 is not a good idea (db migration will be\n> difficult when both version share syntax). We believe this should also\n> be enforced in the server side.\n\nI actually don\'t think a real decision was made at the hackathon for\nthis.  I know we were originally going to do a shim layer to translate\nv1 calls into v2 and v2 object model to v1 for v1 driver consumption.  I\nam, however, fine with that rule and it will make things much simpler.\nThere will definitely need to be code in the intiialization of both v1\nand v2 plugins that check whether the other version has been\ninitialized, since we cannot guarantee an order in which\nextensions/service plugins are loaded.  This should be trivial to do\nthough.\n\n> \n> 2. Therefor, there should be some configuration to specifically enable\n> either version (not both) in case LBaaS is needed. In this case, the\n> other version is disabled (ie. a REST query for non-active version\n> should return a \"not activated\" error). Additionally, adding a\n> \'lb-version\' command to return the version currently active seems like a\n> good user-facing idea. We should see how this doesn\'t negatively effect\n> the db migration process (for example, allowing read-only commands for\n> both versions?)\n\nA /version endpoint can be added for both v1 and v2 extensions and\nservice plugins.  If it doesn\'t already exist, it would be nice if\nneutron had an endpoint that would return the list of loaded extensions\nand their versions.\n\n> \n> 3. Another decision that\'s needed to be made is the syntax for v2. As\n> mentioned, the current new syntax is \'neutron lbaas-<object>-<command>\'\n> (against the old \'lb-<object>-<action>\'), keeping in mind that once v1\n> is deprecated, a syntax like \'lbv2-<object>-<action>\' would be probably\n> unwanted. Is \'lbaas-<object>-<command>\' okay with everyone?\n\nThat is the reason we with with lbaas because lbv2 looks ugly and we\'d\nbe stuck with it for the lifetime of v2, unless we did another migration\nback to lb for it.  Which seemed wrong to do, since then we\'d have to\naccept both lbv2 and lb commands, and then deprecate lbv2.\n\nI assume this also means you are fine with the prefix in the API\nresource of /lbaas as well then?\n\n> \n> 4. If we are going for different API between versions, appropriate\n> patches also need to be written for lbaas-related scripts and also\n> Tempest, and their maintainers should probably be notified.\n\nCould you elaborate on this? I don\'t understand what you mean by\n\"different API between version.\"\n\n> \n> Are there any issues with one of the points raised above? Does anyone\n> see any other problems which we forgot to write down?\n> \n> Thanks a lot,\n> \n> John Schwarz, Yair Fried,\n> Redhat.\n> \n> [1]: https://review.openstack.org/#/c/111475\n> [2]:\n> http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53F9EA97.1040003@redhat.com>',NULL),('<1408994133.16118.22.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 19:12:55',0,'2014-08-25 19:12:55',NULL,'[openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax\n additions/changes','Hi Clark,\nFrom my understanding the keystone catalog will not contain endpoints\nfor neutron extensions.  I could see it being allowed but since Neutron\ncan enable/disable extensions on a whim, there would need to be some\ncross project communication between keystone and neutron.  I\'m sure\nthere are other issues that would arise from this too.  Then again, I\ncould be wrong and this is already both solved for and allowed in\nKeystone.\n\nRegarding having two separate commands for each version; Since neutron\nextensions don\'t have any kind of versioning built it, it would be tough\nto do through the API at least.  The client can make smart decisions\nthough and make it easier for a user.  However, if lb-<object>-<action>\nworked for both v1 and v2, and the user has no idea what Neutron has\nloaded, I don\'t see that being a better user experience when they try to\ndo a v1 command when v2 has been loaded.\n\nThanks,\nBrandon\nOn Sun, 2014-08-24 at 11:50 -0700, Clark Boylan wrote:\n> On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote:\n> > Hi,\n> > \n> > With the ongoing development of LBaaS v2, support for v2 of LBaaS in\n> > neutronclient is also being developed, as can be seen in [1].\n> > The current implementation adds a new syntax for v2; Whereas the v1\n> > syntax is \'neutron lb-<object>-<command>\', the new v2 syntax is \'neutron\n> > lbaas-<object>-<command>\'.\n> > \n> > We fear that this can lead to some level of confusion on the users\'\n> > side. Currently, nothing prevents a user from trying to create a v1 pool\n> > and then trying to add v2 members. Of course the second command will\n> > fail, but the error message will be a non-intuitive one.\n> > \n> > This was discussed at the last weekly IRC meeting ([2]). Some bulletins:\n> > \n> > 1. As was discussed in the hackathon, there shouldn\'t be more than one\n> > version active at any given time - either v1 or v2. Also, using the same\n> > syntax for both v1 and v2 is not a good idea (db migration will be\n> > difficult when both version share syntax). We believe this should also\n> > be enforced in the server side.\n> > \n> > 2. Therefor, there should be some configuration to specifically enable\n> > either version (not both) in case LBaaS is needed. In this case, the\n> > other version is disabled (ie. a REST query for non-active version\n> > should return a \"not activated\" error). Additionally, adding a\n> > \'lb-version\' command to return the version currently active seems like a\n> > good user-facing idea. We should see how this doesn\'t negatively effect\n> > the db migration process (for example, allowing read-only commands for\n> > both versions?)\n> > \n> > 3. Another decision that\'s needed to be made is the syntax for v2. As\n> > mentioned, the current new syntax is \'neutron lbaas-<object>-<command>\'\n> > (against the old \'lb-<object>-<action>\'), keeping in mind that once v1\n> > is deprecated, a syntax like \'lbv2-<object>-<action>\' would be probably\n> > unwanted. Is \'lbaas-<object>-<command>\' okay with everyone?\n> > \n> > 4. If we are going for different API between versions, appropriate\n> > patches also need to be written for lbaas-related scripts and also\n> > Tempest, and their maintainers should probably be notified.\n> > \n> > Are there any issues with one of the points raised above? Does anyone\n> > see any other problems which we forgot to write down?\n> > \n> > Thanks a lot,\n> > \n> > John Schwarz, Yair Fried,\n> > Redhat.\n> > \n> > [1]: https://review.openstack.org/#/c/111475\n> > [2]:\n> > http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> As a user of both the neutron API and python-neutronclient it would be\n> much better to have the client use a common set of commands for both v1\n> and v2 where the specific version used is determined by the keystone\n> catalog or other overriding information. I don\'t want to have to\n> remember two different sets of commands with potentially two different\n> outputs. Client libraries exist so that users don\'t have to think about\n> this stuff.\n> \n> This should prevent confusion as users will use a common version unless\n> they specifically provide an override of some sort.\n> \n> Clark\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1408906226.999259.156203653.598B0609@webmail.messagingengine.com>',NULL),('<1408994679.41410.YahooMailNeo@web171606.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-25 20:24:39',3600,'2014-08-25 19:24:39',NULL,'[Openstack] HA(High Availability ) mode - OpenStack','\n\nOn Monday, 25 August 2014, 10:04:20, Gowri LN <gowri.ln123 at gmail.com> wrote:\n> Can anyone suggest me where I can get information about how HA is implement is compute node ??\nI am guessing, you are looking for HA of the guest VMs, is that correct?\nI am afraid OpenStack does not offer HA for guest VM in this moment.?\n\n> I know that minimum 3 controllers are required to configure HA mode but my question is,\n> if I add more compute nodes as well will my cluster be more stable?\n> Are the VM s replicated over compute nodes?\n\nThe number 3 is a generic, minimum HA cluster requirement. It helps establish quorum of the cluster. It\'s always good to have odd number of cluster members.?\n- Radoslaw Smigielski \n\n\n\n','<CAHfH98P9cUuw8onUCGXib9Q-Qe6_qwgdqBQCx9Eu4Xf-pcd3rw@mail.gmail.com>',NULL),('<1409021232.1861997.156723061.6AF4288E@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-25 19:47:12',-25200,'2014-08-26 02:47:12',NULL,'[openstack-dev] [cinder]pylint errors with hashlib','On Mon, Aug 25, 2014, at 06:45 PM, Murali Balcha wrote:\n> Pylint on my patch is failing with the following error:\n> \n> Module \'hashlib\' has no \'sha256\'\n> \n> Cinder pylint already has following exceptions,\n> \n> \n> pylint_exceptions:[\"Instance of \'sha1\' has no \'update\' member\", \"\"]\n> \n> pylint_exceptions:[\"Module \'hashlib\' has no \'sha224\' member\", \"\"]\n> \n> \n> So I think \"hashlib has no \'sha256\'\" should be added to the exception\n> list as well. How can I update the exception list?\n> \n> \n> Thanks,\n> \n> Murali Balcha\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI think this may be related to your install of python. Mine does not\nhave this problem.\n\n$ python\nPython 2.7.6 (default, Mar 22 2014, 22:59:56) \n[GCC 4.8.2] on linux2\nType \"help\", \"copyright\", \"credits\" or \"license\" for more information.\n>>> import hashlib\n>>> hashlib.sha256\n<built-in function openssl_sha256>\n>>> hashlib.sha224\n<built-in function openssl_sha224>\n>>> s = hashlib.sha1()\n>>> s.update(\'somestring\')\n>>> \n\nYou should not need to treat these as acceptable failures.\n\nClark\n\n\n','<D0215F09.F717%murali.balcha@triliodata.com>',NULL),('<1409038043.7198.0.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 15:27:23',28800,'2014-08-26 07:27:23',NULL,'[openstack-dev] gettext question about oslo.i18n library','Hi Doug,\n\nI created a i18n blueprint for oslo.i18n.\nURL:\nhttps://blueprints.launchpad.net/openstack-i18n/+spec/more-gettext-supports\n\nCould you review it?\n\nI am reading django gettext code, I think I will use a similar approach\nfor the \"contextual markers\" gettext function.\n\nThanks,\n  Peng Wu\n\nOn Mon, 2014-08-18 at 10:05 -0400, Doug Hellmann wrote:\n> Yes, that would be a good next step.\n> \n> Doug\n> \n> On Aug 17, 2014, at 10:03 PM, Peng Wu <peng.e.wu at gmail.com> wrote:\n> \n> >  Yes, I am interested in adding these missing gettext functions to\n> > oslo.i18n library.\n> > \n> >  Guess the next step is to create a blueprint for Kilo?\n> > \n> > Thanks,\n> >  Peng Wu\n> > \n> > \n> > On Fri, 2014-08-15 at 16:02 -0400, Doug Hellmann wrote:\n> >> On Aug 15, 2014, at 3:18 AM, Peng Wu <peng.e.wu at gmail.com> wrote:\n> >> \n> >>> Hi,\n> >>> \n> >>> Recently I just read the code of oslo.i18n library,\n> >>> The lazy translation idea is great!\n> >>> \n> >>> But I found a question about gettext \"contextual markers\"\n> >>> and \"plural form\", such as pgettext and ungettext functions,\n> >>> see [3].\n> >>> \n> >>> It seems the two gettext functions are missing in the oslo.i18n\n> >>> library.\n> >>> Is it correct? or will support it?\n> >>> \n> >>> Thanks,\n> >>> Peng Wu\n> >> \n> >> You?re right, those are not present.\n> >> \n> >> We apparently haven?t used them anywhere, yet, because they weren?t exposed via the old gettextutils module in the incubator. We should add them. Are you interested in working on a blueprint for Kilo to do that?\n> >> \n> >> Doug\n> >> \n> >>> \n> >>> Refer URL:\n> >>> 1. https://github.com/openstack/oslo.i18n\n> >>> 2.\n> >>> http://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html\n> >>> 3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings\n> >>> \n> >>> \n> >>> \n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >> \n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<D281E33D-001A-4DDF-B3F8-3BA26993B64C@doughellmann.com>',NULL),('<1409045488.3424.86.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 10:31:28',3600,'2014-08-26 09:31:28',NULL,'[openstack-dev] [oslo] Launchpad tracking of oslo projects','On Fri, 2014-08-22 at 11:59 +0200, Thierry Carrez wrote:\n> TL;DR:\n> Let\'s create an Oslo projectgroup in Launchpad to track work across all\n> Oslo libraries. In library projects, let\'s use milestones connected to\n> published versions rather than the common milestones.\n\nSounds good to me, Thierry. Thanks for the thoughtful proposal.\n\nThe part about using integrated release milestones was more about\nhighlighting that we follow a similar development model and cadence -\ni.e. it\'s helpful from a planning perspective to predict whether a given\nfeature is likely to land in juno-1, juno-2 or juno-3. When it comes to\nrelease time, though, I\'d much rather have a launchpad milestone that\nreflects the release itself rather than the development milestone. \n\nSounds like we need to choose between using launchpad milestones for\nplanning or releases, and choosing the latter makes sense to me.\n\nMark.\n\n\n\n','<53F71479.4010401@openstack.org>',NULL),('<1409049011.3424.101.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 11:30:11',3600,'2014-08-26 10:30:11',NULL,'[openstack-dev] [oslo] usage patterns for oslo.config','On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote:\n> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:\n> \n> > On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann <doug at doughellmann.com> wrote:\n> >> \n> >> That?s right. The preferred approach is to put the register_opt() in\n> >> *runtime* code somewhere before the option will be used. That might be in\n> >> the constructor for a class that uses an option, for example, as described\n> >> in\n> >> http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options\n> >> \n> >> Doug\n> > \n> > Interesting.\n> > \n> > I\'ve been following the prevailing example in Nova, which is to\n> > register opts at the top of a module, immediately after defining them.\n> > Is there a situation in which one approach is better than the other?\n> \n> The approach used in Nova is the ?old? way of doing it. It works, but\n> assumes that all of the application code is modifying a global\n> configuration object. The runtime approach allows you to pass a\n> configuration object to a library, which makes it easier to mock the\n> configuration for testing and avoids having the configuration options\n> bleed into the public API of the library. We?ve started using the\n> runtime approach in new Oslo libraries that have configuration\n> options, but changing the implementation in existing application code\n> isn?t strictly necessary.\n\nI\'ve been meaning to dig up some of the old threads and reviews to\ndocument how we got here.\n\nBut briefly:\n\n  * this global CONF variable originates from the gflags FLAGS variable \n    in Nova before oslo.config\n\n  * I was initially determined to get rid of any global variable use \n    and did a lot of work to allow glance use oslo.config without a \n    global variable\n\n      * one example detail of this work - when you use paste.deploy to \n        load an app, you have no ability to pass a config object \n        through paste.deploy to the app. I wrote a little helper that \n        used a thread-local variable to mimic this pass-through.\n\n  * with glance done, I moved on to making keystone use oslo.config and \n    initially didn\'t use the global variable. Then I ran into a veto \n    from termie who felt very strongly that a global variable should be \n    used.\n\n  * in the end, I bought the argument that the use of a global variable \n    was pretty deeply ingrained (especially in Nova) and that we should \n    aim for consistent coding patterns across projects (i.e. Oslo \n    shouldn\'t be just about shared code, but also shared patterns). The \n    only realistic \"standard pattern\" we could hope for was the use of \n    the global variable.\n\n  * with that agreed, we reverted glance back to using a global \n    variable and all projects followed suit\n\n  * the case of libraries is different IMO - we\'d be foolish to design \n    APIs which lock us into using the global object\n\nSo ... I wouldn\'t quite agree that this is \"the new way\" vs \"the old\nway\", but I think it would be reasonable to re-open the discussion about\nusing the global object in our applications. Perhaps, at least, we could\nreduce our dependence on it.\n\nOh look, we have a FAQ on this:\n\nhttps://wiki.openstack.org/wiki/Oslo#Why_does_oslo.config_have_a_CONF_object.3F_Global_object_SUCK.21\n\nMark.\n\n\n\n\n','<81EC7C6D-1BAD-4951-8B5E-C0C7B3371DCA@doughellmann.com>',NULL),('<1409055127254.50764@tataelxsi.co.in>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 12:12:08',0,'2014-08-26 12:12:08',NULL,'[openstack-dev] Private IP allocation','Hi,\n\n\nOpenstack deployment detail : Single node devstack setup\n\n\nIssue Description:\n\nWe are writing a core plugin and trying to create instance provisioned by our plugin. We are able to launch the VM instance successfully via OpenStack horizon. From the horizon, we could see the IP is getting allocated to the VM. But the IP is not seen when we do an ifconfig in the VM\'s terminal. Also, we are not able to ping 2 instances.\n\n>From the CLI, the \"ovs-vsctl show\" command shows:\n\n\nf858da98-365a-4ca0-bfdc-7ab19987a128\n    Bridge br-int\n        Port br-int\n            Interface br-int\n                type: internal\n    ovs_version: \"1.4.6\"\n\n\nHowever, we could see the interfaces when we did ifconfig from the terminal. What are we missing? Do we need to add some configuration for the interface in our plugin?\n\nRegards,\nSanjivini Naikar\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/06623d4c/attachment.html>\n\n',NULL,NULL),('<1409076273.19288.YahooMailNeo@web310005.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 11:04:33',-25200,'2014-08-26 18:04:33',NULL,'[openstack-dev] What does NASA not using OpenStack mean to\n	OS\'s	future','Don\'t feed the troll. :)\n?\n:)=\n\n\nOn Monday, August 25, 2014 12:39 PM, Joshua Harlow <harlowja at outlook.com> wrote:\n \n\n\nSo to see if we can get something useful from this thread.\n\nWhat was your internal analysis, can it be published? Even negative analysis is useful to make openstack better...\n\nIt\'d be nice to have some details on what you found, what u didn\'t find, so that we can all improve...\n\nAfter all that is what it\'s all about.\n\n-Josh\n\n\nOn Aug 25, 2014, at 11:13 AM, Aryeh Friedman <aryeh.friedman at gmail.com> wrote:\n\nIf I was doing that then I would be promoting the platform by name (which I am not)..... I was just pointing out in our own internal ananylis OS came in dead last among all the open source IaaS/PaaS\'s (the current version of mine is not #1 btw)\n>\n>\n>\n>\n>On Mon, Aug 25, 2014 at 2:03 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:\n>\n>On 25 August 2014 10:34, Aryeh Friedman <aryeh.friedman at gmail.com> wrote:\n>>\n>>Do you call Martin Meckos having no clue... he is the one that leveled the second worse criticism after mine... or is Euclapytus not one the founding members of OpenStack (after all many of the glance commands still use it\'s name)\n>>>\n>>\n>>\n>>You appear to be trolling, and throwing around amazingly easy-to-disprove \'factoids\', in an inappropriate forum, in order to drum up support for your own competing open source cloud platform.? Please stop.\n>>\n>>Your time would be much better spent improving your platform rather than coming up with frankly bizarre criticism of the competitors.\n>>-- \n>>Ian.\n>>\n>>_______________________________________________\n>>OpenStack-dev mailing list\n>>OpenStack-dev at lists.openstack.org\n>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>\n>\n>-- \n>\n>Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org\n>\n_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140826/fc0e338c/attachment-0001.html>\n\n','<BLU436-SMTP10F3C6FBA27C97F51FAACFD8DF0@phx.gbl>',NULL),('<1409092317-sup-4930@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-26 15:59:18',-25200,'2014-08-26 22:59:18',NULL,'[openstack-dev] [qa][all][Heat] Packaging of functional tests','Excerpts from Steve Baker\'s message of 2014-08-26 14:25:46 -0700:\n> On 27/08/14 03:18, David Kranz wrote:\n> > On 08/26/2014 10:14 AM, Zane Bitter wrote:\n> >> Steve Baker has started the process of moving Heat tests out of the\n> >> Tempest repository and into the Heat repository, and we\'re looking\n> >> for some guidance on how they should be packaged in a consistent way.\n> >> Apparently there are a few projects already packaging functional\n> >> tests in the package <projectname>.tests.functional (alongside\n> >> <projectname>.tests.unit for the unit tests).\n> >>\n> >> That strikes me as odd in our context, because while the unit tests\n> >> run against the code in the package in which they are embedded, the\n> >> functional tests run against some entirely different code - whatever\n> >> OpenStack cloud you give it the auth URL and credentials for. So\n> >> these tests run from the outside, just like their ancestors in\n> >> Tempest do.\n> >>\n> >> There\'s all kinds of potential confusion here for users and\n> >> packagers. None of it is fatal and all of it can be worked around,\n> >> but if we refrain from doing the thing that makes zero conceptual\n> >> sense then there will be no problem to work around :)\n> > Thanks, Zane. The point of moving functional tests to projects is to\n> > be able to run more of them\n> > in gate jobs for those projects, and allow tempest to survive being\n> > stretched-to-breaking horizontally as we scale to more projects. At\n> > the same time, there are benefits to the\n> > tempest-as-all-in-one-functional-and-integration-suite that we should\n> > try not to lose:\n> >\n> > 1. Strong integration testing without thinking too hard about the\n> > actual dependencies\n> > 2. Protection from mistaken or unwise api changes (tempest two-step\n> > required)\n> > 3. Exportability as a complete blackbox functional test suite that can\n> > be used by Rally, RefStack, deployment validation, etc.\n> >\n> > I think (1) may be the most challenging because tests that are moved\n> > out of tempest might be testing some integration that is not being\n> > covered\n> > by a scenario. We will need to make sure that tempest actually has a\n> > complete enough set of tests to validate integration. Even if this is\n> > all implemented in a way where tempest can see in-project tests as\n> > \"plugins\", there will still not be time to run them all as part of\n> > tempest on every commit to every project, so a selection will have to\n> > be made.\n> >\n> > (2) is quite difficult. In Atlanta we talked about taking a copy of\n> > functional tests into tempest for stable apis. I don\'t know how\n> > workable that is but don\'t see any other real options except vigilance\n> > in reviews of patches that change functional tests.\n> >\n> > (3) is what Zane was addressing. The in-project functional tests need\n> > to be written in a way that they can, at least in some configuration,\n> > run against a real cloud.\n> >\n> >\n> >>\n> >> I suspect from reading the previous thread about \"In-tree functional\n> >> test vision\" that we may actually be dealing with three categories of\n> >> test here rather than two:\n> >>\n> >> * Unit tests that run against the package they are embedded in\n> >> * Functional tests that run against the package they are embedded in\n> >> * Integration tests that run against a specified cloud\n> >>\n> >> i.e. the tests we are now trying to add to Heat might be\n> >> qualitatively different from the <projectname>.tests.functional\n> >> suites that already exist in a few projects. Perhaps someone from\n> >> Neutron and/or Swift can confirm?\n> > That seems right, except that I would call the third \"functional\n> > tests\" and not \"integration tests\", because the purpose is not really\n> > integration but deep testing of a particular service. Tempest would\n> > continue to focus on integration testing. Is there some controversy\n> > about that?\n> > The second category could include whitebox tests.\n> >\n> > I don\'t know about swift, but in neutron the intent was to have these\n> > tests be configurable to run against a real cloud, or not. Maru Newby\n> > would have details.\n> >>\n> >> I\'d like to propose that tests of the third type get their own\n> >> top-level package with a name of the form\n> >> <projectname>-integrationtests (second choice: <projectname>-tempest\n> >> on the principle that they\'re essentially plugins for Tempest). How\n> >> would people feel about standardising that across OpenStack?\n> > +1 But I would not call it \"integrationtests\" for the reason given above.\n> >\n> Because all heat does is interact with other services, what we call\n> functional tests are actually integration tests. Sure, we could mock at\n> the REST API level, but integration coverage is what we need most. This\n\nI\'d call that \"faking\", not mocking, but both could apply.\n\n> lets us verify things like:\n> - how heat handles races in other services leading to resources going\n> into ERROR\n\nA fake that predictably fails (and thus tests failure handling) will\nresult in better coverage than a real service that only fails when that\nreal service is broken. What\'s frustrating is that _both_ are needed to\ncatch bugs.\n\n> - connectivity and interaction between heat and agents on orchestrated\n> servers\n> \n\nThat is definitely a real integration problem, as it also tests OS\'s,\ncloud-init, ec2 metadata, etc. etc.\n\nI\'d like to see fake versions of each API service available (think nova\nfake virt, fake cinder, etc) and simple ways to spin them up with fakes.\n\nOf course full integration tests need more realistic simulation.\nHowever, being able to run a set of tests that do actually exercise the\ninteractions between the real services should lead to more developers\nrunning them in a tight loop and less gate churn.\n\n\n','<53FCFB5A.70408@redhat.com>',NULL),('<1409120451.3424.147.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 07:20:51',3600,'2014-08-27 06:20:51',NULL,'[openstack-dev] [oslo] usage patterns for oslo.config','On Tue, 2014-08-26 at 10:00 -0400, Doug Hellmann wrote:\n> On Aug 26, 2014, at 6:30 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n> \n> > On Mon, 2014-08-11 at 15:06 -0400, Doug Hellmann wrote:\n> >> On Aug 8, 2014, at 7:22 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:\n> >> \n> >>> On Fri, Aug 8, 2014 at 12:41 PM, Doug Hellmann <doug at doughellmann.com> wrote:\n> >>>> \n> >>>> That?s right. The preferred approach is to put the register_opt() in\n> >>>> *runtime* code somewhere before the option will be used. That might be in\n> >>>> the constructor for a class that uses an option, for example, as described\n> >>>> in\n> >>>> http://docs.openstack.org/developer/oslo.config/cfg.html#registering-options\n> >>>> \n> >>>> Doug\n> >>> \n> >>> Interesting.\n> >>> \n> >>> I\'ve been following the prevailing example in Nova, which is to\n> >>> register opts at the top of a module, immediately after defining them.\n> >>> Is there a situation in which one approach is better than the other?\n> >> \n> >> The approach used in Nova is the ?old? way of doing it. It works, but\n> >> assumes that all of the application code is modifying a global\n> >> configuration object. The runtime approach allows you to pass a\n> >> configuration object to a library, which makes it easier to mock the\n> >> configuration for testing and avoids having the configuration options\n> >> bleed into the public API of the library. We?ve started using the\n> >> runtime approach in new Oslo libraries that have configuration\n> >> options, but changing the implementation in existing application code\n> >> isn?t strictly necessary.\n> > \n> > I\'ve been meaning to dig up some of the old threads and reviews to\n> > document how we got here.\n> > \n> > But briefly:\n> > \n> >  * this global CONF variable originates from the gflags FLAGS variable \n> >    in Nova before oslo.config\n> > \n> >  * I was initially determined to get rid of any global variable use \n> >    and did a lot of work to allow glance use oslo.config without a \n> >    global variable\n> > \n> >      * one example detail of this work - when you use paste.deploy to \n> >        load an app, you have no ability to pass a config object \n> >        through paste.deploy to the app. I wrote a little helper that \n> >        used a thread-local variable to mimic this pass-through.\n> > \n> >  * with glance done, I moved on to making keystone use oslo.config and \n> >    initially didn\'t use the global variable. Then I ran into a veto \n> >    from termie who felt very strongly that a global variable should be \n> >    used.\n> > \n> >  * in the end, I bought the argument that the use of a global variable \n> >    was pretty deeply ingrained (especially in Nova) and that we should \n> >    aim for consistent coding patterns across projects (i.e. Oslo \n> >    shouldn\'t be just about shared code, but also shared patterns). The \n> >    only realistic \"standard pattern\" we could hope for was the use of \n> >    the global variable.\n> > \n> >  * with that agreed, we reverted glance back to using a global \n> >    variable and all projects followed suit\n> > \n> >  * the case of libraries is different IMO - we\'d be foolish to design \n> >    APIs which lock us into using the global object\n> > \n> > So ... I wouldn\'t quite agree that this is \"the new way\" vs \"the old\n> > way\", but I think it would be reasonable to re-open the discussion about\n> > using the global object in our applications. Perhaps, at least, we could\n> > reduce our dependence on it.\n> \n> The aspect I was calling ?old? was the ?register options at import\n> time? pattern, not the use of a global. Whether we use a global or\n> not, registering options at runtime in a code path that will be using\n> them is better than relying on import ordering to ensure options are\n> registered before they are used.\n\nI don\'t think I\'ve seen code (except for obscure cases) which uses the\nCONF global directly (as opposed to being passed CONF as a parameter)\nbut doesn\'t register the options at import time.\n\nMark.\n\n\n\n','<3B724162-30F6-4B8C-868C-FE7CD4424312@doughellmann.com>',NULL),('<1409120526.4330.2.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-27 08:22:06',7200,'2014-08-27 06:22:06',NULL,'[Openstack] Instance cannot get any ip address','Hi, \nwhich setup are you running? Devstack singlenode, mulitnode, neutron or\nlegacy nova networking?\n\nDoes the subnet of your internal network has dhcp enabled? You can\nsimply find out having a look at the subnet details in horizon. \n\n\nRegards, \nAndreas\n\n\nOn Wed, 2014-08-27 at 13:48 +0800, Xianyi Ye wrote:\n> Hi all,\n> \n>  \n> \n> I was working on the external network accessing configuration. But I\n> find that after I created an instance, neither internal ip address nor\n> external ip address could be displayed in the response of ?ifconfig?\n> command.\n> \n> However, on Dashboard, I can see both of these 2 ip addresses have\n> been allocated to that instance successfully.\n> \n> Is there anyone knows what?s going on?\n> \n>  \n> \n> I do appreciate anyone?s help.\n> \n>  \n> \n> Thanks very much!\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n','<00df01cfc1ba$8448b8f0$8cda2ad0$@sina.com>',NULL),('<1409147347662.69699@tataelxsi.co.in>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 13:49:08',0,'2014-08-27 13:49:08',NULL,'[openstack-dev] [neutron] static IP & DHCP','Hi,\n\nI want to assign static IP to my instance. However, when trying to do so, the IP doesnt get associated with the VM. My VM boot logs show:\n\nSending discover...\nSending discover...\nSending discover...\nNo lease, failing\n\nWARN: /etc/rc3.d/S40-network failed\n\nHow do I assign a static IP to my VM?\n\n\nRegards,\nSanjivini Naikar\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/3c2dc1fe/attachment.html>\n\n',NULL,NULL),('<1409155003-sup-6814@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 09:40:31',-25200,'2014-08-27 16:40:31',NULL,'[openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report','Excerpts from Zane Bitter\'s message of 2014-08-27 08:41:29 -0700:\n> On 27/08/14 11:04, Steven Hardy wrote:\n> > On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote:\n> >>     I am little bit skeptical about using Swift for this use case because of\n> >>     its eventual consistency issue. I am not sure Swift cluster is good to be\n> >>     used for this kind of problem. Please note that Swift cluster may give you\n> >>     old data at some point of time.\n> >\n> > This is probably not a major problem, but it\'s certainly worth considering.\n> >\n> > My assumption is that the latency of making the replicas consistent will be\n> > small relative to the timeout for things like SoftwareDeployments, so all\n> > we need is to ensure that instances  eventually get the new data, act on\n> \n> That part is fine, but if they get the new data and then later get the \n> old data back again... that would not be so good.\n> \n\nAgreed, and I had not considered that this can happen.\n\nThere is a not-so-simple answer though:\n\n* Heat inserts this as initial metadata:\n\n    {\"metadata\": {}, \"update-url\": \"xxxxxx\", \"version\": 0}\n\n* Polling goes to update-url and ignores metadata <= 0\n\n* Polling finds new metadata in same format, and continues the loop\nwithout talking to Heat\n\nHowever, this makes me rethink why we are having performance problems.\nMOST of the performance problems have two root causes:\n\n* We parse the entire stack to show metadata, because we have to see if\n  there are custom access controls defined in any of the resources used.\n  I actually worked on a patch set to deprecate this part of the resource\n  plugin API because it is impossible to scale this way.\n* We rely on the engine to respond because of the parsing issue.\n\nIf however we could just push metadata into the db fully resolved\nwhenever things in the stack change, and cache the response in the API\nusing Last-Modified/Etag headers, I think we\'d be less inclined to care\nso much about swift for polling. However we are still left with the many\nthousands of keystone users being created vs. thousands of swift tempurls.\n\nThat would also set us up nicely for very easy integration with Zaqar,\nas metadata changes would flow naturally into the message queue for the\nserver through the same mechanism as they flow into the database.\n\n\n','<53FDFC29.8070606@redhat.com>',NULL),('<1409162349-sup-9127@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 11:03:10',-25200,'2014-08-27 18:03:10',NULL,'[openstack-dev] [Heat] Heat Juno Mid-cycle Meetup report','Excerpts from Steven Hardy\'s message of 2014-08-27 10:08:36 -0700:\n> On Wed, Aug 27, 2014 at 09:40:31AM -0700, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-08-27 08:41:29 -0700:\n> > > On 27/08/14 11:04, Steven Hardy wrote:\n> > > > On Wed, Aug 27, 2014 at 07:54:41PM +0530, Jyoti Ranjan wrote:\n> > > >>     I am little bit skeptical about using Swift for this use case because of\n> > > >>     its eventual consistency issue. I am not sure Swift cluster is good to be\n> > > >>     used for this kind of problem. Please note that Swift cluster may give you\n> > > >>     old data at some point of time.\n> > > >\n> > > > This is probably not a major problem, but it\'s certainly worth considering.\n> > > >\n> > > > My assumption is that the latency of making the replicas consistent will be\n> > > > small relative to the timeout for things like SoftwareDeployments, so all\n> > > > we need is to ensure that instances  eventually get the new data, act on\n> > > \n> > > That part is fine, but if they get the new data and then later get the \n> > > old data back again... that would not be so good.\n> > > \n> > \n> > Agreed, and I had not considered that this can happen.\n> > \n> > There is a not-so-simple answer though:\n> > \n> > * Heat inserts this as initial metadata:\n> > \n> >     {\"metadata\": {}, \"update-url\": \"xxxxxx\", \"version\": 0}\n> > \n> > * Polling goes to update-url and ignores metadata <= 0\n> > \n> > * Polling finds new metadata in same format, and continues the loop\n> > without talking to Heat\n> > \n> > However, this makes me rethink why we are having performance problems.\n> > MOST of the performance problems have two root causes:\n> > \n> > * We parse the entire stack to show metadata, because we have to see if\n> >   there are custom access controls defined in any of the resources used.\n> >   I actually worked on a patch set to deprecate this part of the resource\n> >   plugin API because it is impossible to scale this way.\n> > * We rely on the engine to respond because of the parsing issue.\n> > \n> > If however we could just push metadata into the db fully resolved\n> > whenever things in the stack change, and cache the response in the API\n> > using Last-Modified/Etag headers, I think we\'d be less inclined to care\n> > so much about swift for polling. However we are still left with the many\n> > thousands of keystone users being created vs. thousands of swift tempurls.\n> \n> There\'s probably a few relatively simple optimisations we can do if the\n> keystone user thing becomes the bottleneck:\n> - Make the user an attribute of the stack and only create one per\n>   stack/tree-of-stacks\n> - Make the user an attribute of each server resource (probably more secure\n>   but less optimal if your optimal is less keystone users).\n> \n> I don\'t think the many keystone users thing is actually a problem right now\n> though, or is it?\n\n1000 servers means 1000 keystone users to manage, and all of the tokens\nand backend churn that implies.\n\nIt\'s not \"a problem\", but it is quite a bit heavier than tempurls.\n\n\n','<20140827170836.GD8982@t430slt.redhat.com>',NULL),('<1409168079-sup-9994@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 15:25:46',-25200,'2014-08-27 22:25:46',NULL,'[openstack-dev] [all] Design Summit reloaded','Excerpts from Thierry Carrez\'s message of 2014-08-27 05:51:55 -0700:\n> Hi everyone,\n> \n> I\'ve been thinking about what changes we can bring to the Design Summit\n> format to make it more productive. I\'ve heard the feedback from the\n> mid-cycle meetups and would like to apply some of those ideas for Paris,\n> within the constraints we have (already booked space and time). Here is\n> something we could do:\n> \n> Day 1. Cross-project sessions / incubated projects / other projects\n> \n> I think that worked well last time. 3 parallel rooms where we can\n> address top cross-project questions, discuss the results of the various\n> experiments we conducted during juno. Don\'t hesitate to schedule 2 slots\n> for discussions, so that we have time to come to the bottom of those\n> issues. Incubated projects (and maybe \"other\" projects, if space allows)\n> occupy the remaining space on day 1, and could occupy \"pods\" on the\n> other days.\n> \n\nI like it. The only thing I would add is that it would be quite useful if\nthe use of pods were at least partially enhanced by an unconference style\ninterest list.  What I mean is, on day 1 have people suggest topics and\nvote on suggested topics to discuss at the pods, and from then on the pods\ncan host these topics. This is for the \"other\" things that aren\'t well\ndefined until the summit and don\'t have their own rooms for days 2 and 3.\n\nThis is driven by the fact that the pods in Atlanta were almost always\nbusy doing something other than whatever the track that owned them\nwanted. A few projects pods grew to 30-40 people a few times, eating up\nall the chairs for the surrounding pods. TripleO often sat at the Heat\npod because of this for instance.\n\nI don\'t think they should be fully scheduled. They\'re also just great\nplaces to gather and have a good discussion, but it would be useful to\nplan for topic flexibility and help coalesce interested parties, rather\nthan have them be silos that get taken over randomly. Especially since\nthere is a temptation to push the \"other\" topics to them already.\n\n> Day 2 and Day 3. Scheduled sessions for various programs\n> \n> That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> available. So, rather than trying to cover all the scope, the idea would\n> be to focus those sessions on specific issues which really require\n> face-to-face discussion (which can\'t be solved on the ML or using spec\n> discussion) *or* require a lot of user feedback. That way, appearing in\n> the general schedule is very helpful. This will require us to be a lot\n> stricter on what we accept there and what we don\'t -- we won\'t have\n> space for courtesy sessions anymore, and traditional/unnecessary\n> sessions (like my traditional \"release schedule\" one) should just move\n> to the mailing-list.\n> \n> Day 4. Contributors meetups\n> \n> On the last day, we could try to split the space so that we can conduct\n> parallel midcycle-meetup-like contributors gatherings, with no time\n> boundaries and an open agenda. Large projects could get a full day,\n> smaller projects would get half a day (but could continue the discussion\n> in a local bar). Ideally that meetup would end with some alignment on\n> release goals, but the idea is to make the best of that time together to\n> solve the issues you have. Friday would finish with the design summit\n> feedback session, for those who are still around.\n> \n\nLove this. Please if we can also fully enclose these meetups and the\nsession rooms in dry erase boards that would be ideal.\n\n\n','<53FDD46B.5090206@openstack.org>',NULL),('<1409171190082.7596@nebula.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-27 20:26:30',0,'2014-08-27 20:26:30',NULL,'[Openstack] Why security guide advise against uwsgi for\n	deploying	horizon with nginx?','The security guide is written with the general public in mind. While there\'s nothing inherently wrong with uWSGI, it is common for people to look at synthetic performance benchmarks and make their choice based on those. Unfortunately, uWSGI has an incredibly large number of options, choices, features, and configurations for a deployer to tweak, many of which can result in bad performance or security problems. Furthermore, segfaults are pretty common in that codebase (at least with some configuration options), which is not encouraging from a security perspective.?\n\n\nThe conservative choice is to recommend gunicorn which is stable, has fewer features, and is generally easier to configure and deploy correctly. If you prefer uWSGI and already have experience running it, please feel free to use it with Horizon.\n\n\n-Paul\n\n\n________________________________\nFrom: sylecn <sylecn at gmail.com>\nSent: Wednesday, August 27, 2014 1:39 AM\nTo: <openstack at lists.openstack.org>\nSubject: [Openstack] Why security guide advise against uwsgi for deploying horizon with nginx?\n\nHI all,\n\nI\'m trying to deploy horizon with nginx, and to my surprise, the security guide advice against uwsgi, which is the WSGI server of choice for all my other WSGI apps.\n\nIn the security guide [1], it says\n\nWhen using nginx, we recommend gunicorn<http://docs.gunicorn.org/en/latest/deploy.html> as the wsgi host with an appropriate number of synchronous workers. We strongly advise against deployments using fastcgi, scgi, or uWSGI. We strongly advise against the use of synthetic performance benchmarks when choosing a wsgi server.\n\nAnyone know the reason behind this? Is it just personal preferences?\nI see uwsgi has its own benefits beyond being permanent. It has good documentation, easy nginx integration, is stable and is configurable. Why it is advised against?\n\n[1] http://docs.openstack.org/security-guide/content/ch025_web-dashboard.html\n\n--\nYY Inc. is hiring openstack and python developers. Interested? Check http://soa.game.yy.com/jobs.html\n\n--\nThanks,\nYuanle\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140827/d2d7898b/attachment.html>\n\n','<CACGNuiRE7oCPvgdwE-D673rYKth2HDkGJT8wej=DSYG1c9nCyQ@mail.gmail.com>',NULL),('<1409178419-sup-7049@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 15:27:40',-25200,'2014-08-27 22:27:40',NULL,'[openstack-dev] [all] Design Summit reloaded','Excerpts from Sean Dague\'s message of 2014-08-27 06:26:38 -0700:\n> On 08/27/2014 08:51 AM, Thierry Carrez wrote:\n> > Hi everyone,\n> > \n> > I\'ve been thinking about what changes we can bring to the Design Summit\n> > format to make it more productive. I\'ve heard the feedback from the\n> > mid-cycle meetups and would like to apply some of those ideas for Paris,\n> > within the constraints we have (already booked space and time). Here is\n> > something we could do:\n> > \n> > Day 1. Cross-project sessions / incubated projects / other projects\n> > \n> > I think that worked well last time. 3 parallel rooms where we can\n> > address top cross-project questions, discuss the results of the various\n> > experiments we conducted during juno. Don\'t hesitate to schedule 2 slots\n> > for discussions, so that we have time to come to the bottom of those\n> > issues. Incubated projects (and maybe \"other\" projects, if space allows)\n> > occupy the remaining space on day 1, and could occupy \"pods\" on the\n> > other days.\n> > \n> > Day 2 and Day 3. Scheduled sessions for various programs\n> > \n> > That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> > available. So, rather than trying to cover all the scope, the idea would\n> > be to focus those sessions on specific issues which really require\n> > face-to-face discussion (which can\'t be solved on the ML or using spec\n> > discussion) *or* require a lot of user feedback. That way, appearing in\n> > the general schedule is very helpful. This will require us to be a lot\n> > stricter on what we accept there and what we don\'t -- we won\'t have\n> > space for courtesy sessions anymore, and traditional/unnecessary\n> > sessions (like my traditional \"release schedule\" one) should just move\n> > to the mailing-list.\n> > \n> > Day 4. Contributors meetups\n> > \n> > On the last day, we could try to split the space so that we can conduct\n> > parallel midcycle-meetup-like contributors gatherings, with no time\n> > boundaries and an open agenda. Large projects could get a full day,\n> > smaller projects would get half a day (but could continue the discussion\n> > in a local bar). Ideally that meetup would end with some alignment on\n> > release goals, but the idea is to make the best of that time together to\n> > solve the issues you have. Friday would finish with the design summit\n> > feedback session, for those who are still around.\n> > \n> > \n> > I think this proposal makes the best use of our setup: discuss clear\n> > cross-project issues, address key specific topics which need\n> > face-to-face time and broader attendance, then try to replicate the\n> > success of midcycle meetup-like open unscheduled time to discuss\n> > whatever is hot at this point.\n> > \n> > There are still details to work out (is it possible split the space,\n> > should we use the usual design summit CFP website to organize the\n> > \"scheduled\" time...), but I would first like to have your feedback on\n> > this format. Also if you have alternative proposals that would make a\n> > better use of our 4 days, let me know.\n> \n> I definitely like this approach. I think it will be really interesting\n> to collect feedback from people about the value they got from days 2 & 3\n> vs. Day 4.\n> \n> I also wonder if we should lose a slot from days 1 - 3 and expand the\n> hallway time. Hallway track is always pretty interesting, and honestly\n> at a lot of interesting ideas spring up. The 10 minute transitions often\n> seem to feel like you are rushing between places too quickly some times.\n\nYes please. I\'d also be fine with just giving back 5 minutes from each\nsession to facilitate this.\n\n\n','<53FDDC8E.1050808@dague.net>',NULL),('<1409178542-sup-7464@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 15:30:23',-25200,'2014-08-27 22:30:23',NULL,'[openstack-dev] [all] Design Summit reloaded','Excerpts from Anita Kuno\'s message of 2014-08-27 13:48:25 -0700:\n> On 08/27/2014 02:46 PM, John Griffith wrote:\n> > On Wed, Aug 27, 2014 at 9:25 AM, Flavio Percoco <flavio at redhat.com> wrote:\n> > \n> >> On 08/27/2014 03:26 PM, Sean Dague wrote:\n> >>> On 08/27/2014 08:51 AM, Thierry Carrez wrote:\n> >>>> Hi everyone,\n> >>>>\n> >>>> I\'ve been thinking about what changes we can bring to the Design Summit\n> >>>> format to make it more productive. I\'ve heard the feedback from the\n> >>>> mid-cycle meetups and would like to apply some of those ideas for Paris,\n> >>>> within the constraints we have (already booked space and time). Here is\n> >>>> something we could do:\n> >>>>\n> >>>> Day 1. Cross-project sessions / incubated projects / other projects\n> >>>>\n> >>>> I think that worked well last time. 3 parallel rooms where we can\n> >>>> address top cross-project questions, discuss the results of the various\n> >>>> experiments we conducted during juno. Don\'t hesitate to schedule 2 slots\n> >>>> for discussions, so that we have time to come to the bottom of those\n> >>>> issues. Incubated projects (and maybe \"other\" projects, if space allows)\n> >>>> occupy the remaining space on day 1, and could occupy \"pods\" on the\n> >>>> other days.\n> >>>>\n> >>>> Day 2 and Day 3. Scheduled sessions for various programs\n> >>>>\n> >>>> That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> >>>> available. So, rather than trying to cover all the scope, the idea would\n> >>>> be to focus those sessions on specific issues which really require\n> >>>> face-to-face discussion (which can\'t be solved on the ML or using spec\n> >>>> discussion) *or* require a lot of user feedback. That way, appearing in\n> >>>> the general schedule is very helpful. This will require us to be a lot\n> >>>> stricter on what we accept there and what we don\'t -- we won\'t have\n> >>>> space for courtesy sessions anymore, and traditional/unnecessary\n> >>>> sessions (like my traditional \"release schedule\" one) should just move\n> >>>> to the mailing-list.\n> >>>>\n> >>>> Day 4. Contributors meetups\n> >>>>\n> >>>> On the last day, we could try to split the space so that we can conduct\n> >>>> parallel midcycle-meetup-like contributors gatherings, with no time\n> >>>> boundaries and an open agenda. Large projects could get a full day,\n> >>>> smaller projects would get half a day (but could continue the discussion\n> >>>> in a local bar). Ideally that meetup would end with some alignment on\n> >>>> release goals, but the idea is to make the best of that time together to\n> >>>> solve the issues you have. Friday would finish with the design summit\n> >>>> feedback session, for those who are still around.\n> >>>>\n> >>>>\n> >>>> I think this proposal makes the best use of our setup: discuss clear\n> >>>> cross-project issues, address key specific topics which need\n> >>>> face-to-face time and broader attendance, then try to replicate the\n> >>>> success of midcycle meetup-like open unscheduled time to discuss\n> >>>> whatever is hot at this point.\n> >>>>\n> >>>> There are still details to work out (is it possible split the space,\n> >>>> should we use the usual design summit CFP website to organize the\n> >>>> \"scheduled\" time...), but I would first like to have your feedback on\n> >>>> this format. Also if you have alternative proposals that would make a\n> >>>> better use of our 4 days, let me know.\n> >>>\n> >>> I definitely like this approach. I think it will be really interesting\n> >>> to collect feedback from people about the value they got from days 2 & 3\n> >>> vs. Day 4.\n> >>>\n> >>> I also wonder if we should lose a slot from days 1 - 3 and expand the\n> >>> hallway time. Hallway track is always pretty interesting, and honestly\n> >>> at a lot of interesting ideas spring up. The 10 minute transitions often\n> >>> seem to feel like you are rushing between places too quickly some times.\n> >>\n> >> +1\n> >>\n> >> Last summit, it was basically impossible to do any hallway talking and\n> >> even meet some folks face-2-face.\n> >>\n> >> Other than that, I think the proposal is great and makes sense to me.\n> >>\n> >> Flavio\n> >>\n> >> --\n> >> @flaper87\n> >> Flavio Percoco\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> > ?Sounds like a great idea to me:\n> > +1?\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> I think this is a great direction.\n> \n> Here is my dilemma and it might just affect me. I attended 3 mid-cycles\n> this release: one of Neutron\'s (there were 2), QA/Infra and Cinder. The\n> Neutron and Cinder ones were mostly in pursuit of figuring out third\n> party and exchanging information surrounding that (which I feel was\n> successful). The QA/Infra one was, well even though I feel like I have\n> been awol, I still consider this my home.\n> \n> From my perspective and check with Neutron and Cinder to see if they\n> agree, but having at least one person from qa/infra at a mid-cycle helps\n> in small ways. At both I worked with folks to help them make more\n> efficient use of their review time by exploring gerrit queries (there\n> were people who didn\'t know this magic, nor did they think to ask until\n> they saw some dashboards), at Neutron I gave my impromtu\n> this-is-how-infra-testing-works in terms of the moving parts, and\n> fortunately managed to work in a\n> how-to-submit-an-elastic-recheck-fingerprint as well at the Neutron\n> mid-cycle.\n> \n> I don\'t expect to be able to do all these kind of things at summit, but\n> I do think they are valuable.\n> \n> So my dilemma is on day 4 which room do I choose? I\'ll feel pulled in\n> multiple directions and am uncertain how to select, whatever choice I\n> make I will miss out on valuable discussions.\n> \n> Like I said, probably just my problem, but for me it exists.\n\nYou\'re not alone. Heat devs need to keep tabs on quite a few\ncross-project things as well.\n\nIt may make sense to coordinate with your fellow infra people to find\nout when the most interesting topics are happening and simply move\nbetween rooms.\n\n\n','<53FE4419.5010106@anteaya.info>',NULL),('<1409183021.2674524.157564749.18AC6FD3@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 16:43:41',-25200,'2014-08-27 23:43:41',NULL,'[openstack-dev] [infra] [neutron] [tc] Neutron Incubator\n	workflow','\n\nOn Wed, Aug 27, 2014, at 03:52 PM, Ivar Lazzaro wrote:\n> Quoting Stefano from a different thread [0]:\n> \n> The rationale for the separate repository is that Neutron\'s code needs a\n> > lot of love for the *existing* codebase, before new features can be\n> > added (and before core team can accept more responsibilities for it).\n> > But progress is unstoppable: new features are being proposed every cycle\n> > and reviewers bandwidth is not infinite.\n> \n> \n> The long term purpose of the incubator should be to gather all the big\n> new\n> features that may require fast iteration before becoming stable and being\n> eventually merged into the main tree. This is especially important for\n> \"core\" new features, that may have a higher impact on Neutron\'s\n> stability.\n> A great example was made by Kevin with DVR.\n>\nThe issue that Jim was trying to point out is that \'being eventually\nmerged into the main tree\' is not something you can just do. It is\nextremely costly to merge two repos together in this fashion and we\nshould avoid it at all costs. Feature branches make this relatively\ncheap and should probably be considered instead.\n> \n> [0]\n> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044224.html\n> \n> \n> On Wed, Aug 27, 2014 at 1:32 PM, Kevin Benton <blak111 at gmail.com> wrote:\n> \n> > I agree that components isolated to one service or something along those\n> > lines where there is a clear plugin point in Neutron, it might make sense\n> > to separate them permanently. However, at that point why even bother with\n> > the Neutron incubator when a new project can be started?\n> >\n> > The feature branch idea sounds interesting for the one-time big\n> > experimental changes. Are there any other projects that do this right now?\n> >\n> >\n> > On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <corvus at inaugust.com>\n> > wrote:\n> >\n> >> Kevin Benton <blak111 at gmail.com> writes:\n> >>\n> >> > From what I understand, the intended projects for the incubator can\'t\n> >> > operate without neutron because they are just\n> >> extensions/plugins/drivers.\n> >>\n> >> I could have phrased that better.  What I meant was that they could\n> >> operate without being actually in the Neutron repo, not that they could\n> >> not operate without Neutron itself.\n> >>\n> >> The proposal for the incubator is that extensions be developed outside\n> >> of the Neutron repo.  My proposed refinement is that they stay outside\n> >> of the Neutron repo.  They live their entire lives as extension modules\n> >> in separate projects.\n> >>\n> >> > For example, if the DVR modifications to the reference reference L3\n> >> plugin\n> >> > weren\'t already being developed in the tree, DVR could have been\n> >> developed\n> >> > in the incubator and then merged into Neutron once the bugs were ironed\n> >> out\n> >> > so a huge string of Gerrit patches didn\'t need to be tracked. If that\n> >> had\n> >> > happened, would it make sense to keep the L3 plugin as a completely\n> >> > separate project or merge it? I understand this is the approach the load\n> >> > balancer folks took by making Octavia a separate project, but I think it\n> >> > can still operate on its own, where the reference L3 plugin (and many of\n> >> > the other incubator projects) are just classes that expect to be able to\n> >> > make core Neutron calls.\n> >>\n> >> The list of Juno/Kilo candidates doesn\'t seem to have projects that are\n> >> quite so low-level.\n> >>\n> >> If a feature is going to become part of the neutron core, then it should\n> >> be developed in the neutron repository.  If we need a place to land code\n> >> that isn\'t master, it\'s actually far easier to just use a feature branch\n> >> on the neutron repo.  Commits can land there as needed, master can be\n> >> periodically merged into it, and when the feature is ready, the feature\n> >> branch can be merged into master.\n> >>\n> >> I think between those two options: incubate/spin-out components that are\n> >> high-level enough not to have deep integration in the neutron core, and\n> >> using feature branches for large experimental changes to the core\n> >> itself, we can handle the problems the incubator repo is intended to\n> >> address.\n> >>\n> >> -Jim\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >\n> >\n> > --\n> > Kevin Benton\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAGapyGfYsSRC7JFbNXPxp9=15zsARkG5suX4yax=kmaz+P=yBg@mail.gmail.com>',NULL),('<1409183231-sup-2417@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 17:00:55',-25200,'2014-08-28 00:00:55',NULL,'[openstack-dev] [Keystone][Marconi][Heat] Creating accounts in\n	Keystone','Excerpts from Adam Young\'s message of 2014-08-24 20:17:34 -0700:\n> On 08/23/2014 02:01 AM, Clint Byrum wrote:\n> > I don\'t know how Zaqar does its magic, but I\'d love to see simple signed\n> > URLs rather than users/passwords. This would work for Heat as well. That\n> > way we only have to pass in a single predictably formatted string.\n> >\n> > Excerpts from Zane Bitter\'s message of 2014-08-22 14:35:38 -0700:\n> >> Here\'s an interesting fact about Zaqar (the project formerly known as\n> >> Marconi) that I hadn\'t thought about before this week: it\'s probably the\n> >> first OpenStack project where a major part of the API primarily faces\n> \n> \n> \n> Nah, this is the direction we are headed.  Service users (out of LDAP!)  are going to be the norm with a recent feature add to Keytone:\n> \n> \n> http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/\n> \n\nThis complicates the case by requiring me to get tokens and present\nthem, to cache them, etc. I just want to fetch and/or send messages.\n\n\n','<53FAAACE.7090107@redhat.com>',NULL),('<1409183619.2678178.157566621.2D17A9CF@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 16:53:39',-25200,'2014-08-27 23:53:39',NULL,'[openstack-dev] [infra] [neutron] [tc] Neutron Incubator\n	workflow','On Wed, Aug 27, 2014, at 04:05 PM, Joe Gordon wrote:\n> On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair <corvus at inaugust.com>\n> wrote:\n> \n> > Kevin Benton <blak111 at gmail.com> writes:\n> >\n> > > From what I understand, the intended projects for the incubator can\'t\n> > > operate without neutron because they are just extensions/plugins/drivers.\n> >\n> > I could have phrased that better.  What I meant was that they could\n> > operate without being actually in the Neutron repo, not that they could\n> > not operate without Neutron itself.\n> >\n> > The proposal for the incubator is that extensions be developed outside\n> > of the Neutron repo.  My proposed refinement is that they stay outside\n> > of the Neutron repo.  They live their entire lives as extension modules\n> > in separate projects.\n> >\n> > > For example, if the DVR modifications to the reference reference L3\n> > plugin\n> > > weren\'t already being developed in the tree, DVR could have been\n> > developed\n> > > in the incubator and then merged into Neutron once the bugs were ironed\n> > out\n> > > so a huge string of Gerrit patches didn\'t need to be tracked. If that had\n> > > happened, would it make sense to keep the L3 plugin as a completely\n> > > separate project or merge it? I understand this is the approach the load\n> > > balancer folks took by making Octavia a separate project, but I think it\n> > > can still operate on its own, where the reference L3 plugin (and many of\n> > > the other incubator projects) are just classes that expect to be able to\n> > > make core Neutron calls.\n> >\n> > The list of Juno/Kilo candidates doesn\'t seem to have projects that are\n> > quite so low-level.\n> >\n> > If a feature is going to become part of the neutron core, then it should\n> > be developed in the neutron repository.  If we need a place to land code\n> > that isn\'t master, it\'s actually far easier to just use a feature branch\n> > on the neutron repo.  Commits can land there as needed, master can be\n> > periodically merged into it, and when the feature is ready, the feature\n> > branch can be merged into master.\n> >\n> \n> We have feature branches? How do we use them? I am not even sure if\n> feature\n> branches were evaluated as an option when the incubator was proposed.\n> \nWe do. I thought there was a wiki article on how they work but I can\'t\nfind it. Maybe someone else can link it here.\n\nThe basics are someone creates a branch called feature/foo via the\nGerrit GUI [0], for OpenStack projects members of the release managers\ngroup can do this and for other projects we can update ACLs to give the\n-release group permissions to do this (and infra can always do it). Then\nyou push code against that branch `git review feature/foo` (it will push\nto the correct branch if you edit the .gitreview file on that branch).\n\nPeriodically you will want to merge master back into your feature\nbranches so that you don\'t lag too far behind and when the feature is\nready you merge it back into master. You need special perms to push\nmerge commits to Gerrit so that is something that may need to be worked\nout depending on how the existing ACLs look for a project. The swift\ndevs recently did this for their EC feature and may have more feedback.\n\n[0]\nhttps://review.openstack.org/#/admin/projects/openstack/neutron,branches\n> \n> >\n> > I think between those two options: incubate/spin-out components that are\n> > high-level enough not to have deep integration in the neutron core, and\n> > using feature branches for large experimental changes to the core\n> > itself, we can handle the problems the incubator repo is intended to\n> > address.\n> >\n> > -Jim\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAHXdxOe43xA-YjL6FNwZHbP72HQOBB2mnsTn00ymfWZExFtWSQ@mail.gmail.com>',NULL),('<1409184303.114725142@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-08-27 19:05:03',-18000,'2014-08-28 00:05:03',NULL,'[openstack-community] Please Join OpenStack at Connect 2015,\n	April 21-22 in Melbourne, Australia','\nWe\'re considering a good sized sponsorship with an OpenStack Day (for fee program targeting 150-200 attendees) and Ecosystem Pavilion at [ Connect 2015 ]( http://www.con-nect.com.au/index.html ).  In our opinion, this is the best enterprise-focused B2B event in the A/NZ region.  \n \nWe have 5-6 members interested in joining so far.  Each participating company will be a Silver sponsor, have a session on OpenStack Day, a presence in the well-placed pavilion and more. Please contact me at [ kathyc at openstack.org ]( mailto:kathyc at openstak.org ) by September 5 with your pre-commitment interest. Cost will be approximately 8,000 AUD/$7500 USD - less with more ecosystem members.  We are required to book it by September 10.  Thank you!\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140827/bfd8f737/attachment-0001.html>\n\n',NULL,NULL),('<1409203631.19786.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 05:26:24',0,'2014-08-28 05:26:24',NULL,'[openstack-dev] [Octavia] Using Nova Scheduling Affinity and\n AntiAffinity','Nova scheduler has ServerGroupAffinityFilter and\nServerGroupAntiAffinityFilter which does the colocation and apolocation\nfor VMs.  I think this is something we\'ve discussed before about taking\nadvantage of nova\'s scheduling.  I need to verify that this will work\nwith what we (RAX) plan to do, but I\'d like to get everyone else\'s\nthoughts.  Also, if we do decide this works for everyone involved,\nshould we make it mandatory that the nova-compute services are running\nthese two filters?  I\'m also trying to see if we can use this to also do\nour own colocation and apolocation on load balancers, but it looks like\nit will be a bit complex if it can even work.  Hopefully, I can have\nsomething definitive on that soon.\n\nThanks,\nBrandon\n\n','<CAMH0MgLsSJrCtxoGiigA1+gmv8wZTK+_z6=__DMqU+q0zt8yKw@mail.gmail.com>',NULL),('<1409209638.4323.2.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 09:07:18',7200,'2014-08-28 07:07:18',NULL,'[openstack-dev] [nova] [neutron] Specs for K release','Hi, \nis it already possible to submit specs (nova & neutron) for the K\nrelease? Would be great for getting early feedback and tracking\ncomments. Or should I just commit it to the juno folder?\n\nThanks, \nAndreas\n\n\n\n',NULL,NULL),('<1409213671.4323.6.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 10:14:31',7200,'2014-08-28 08:14:31',NULL,'[openstack-dev] [nova] [neutron] Specs for K release','Thanks for your feedback.\n\nSo I will create a branch for my bp, add the kilo folder and commit it\ntogether with my spec.\n\nTo get sphinx running I also had to make changes to the toc tree in \nnova-specs/doc/source/index.rst\n\nI will also commit this change within my branch, right?\n\nthanks, \nAndreas\n\n\n\nOn Thu, 2014-08-28 at 09:48 +0200, Salvatore Orlando wrote:\n> I think it\'s ok to submit specs for Kilo - mostly because it would be\n> a bit pointless submitting them for Juno!\n> \n> \n> Salvatore\n> \n> \n> On 28 August 2014 09:26, Kevin Benton <blak111 at gmail.com> wrote:\n>         You could just make the kilo folder in your commit and then\n>         rebase it once Kilo is open.\n>         \n>         \n>         On Thu, Aug 28, 2014 at 12:07 AM, Andreas Scheuring\n>         <scheuran at linux.vnet.ibm.com> wrote:\n>                 Hi,\n>                 is it already possible to submit specs (nova &\n>                 neutron) for the K\n>                 release? Would be great for getting early feedback and\n>                 tracking\n>                 comments. Or should I just commit it to the juno\n>                 folder?\n>                 \n>                 Thanks,\n>                 Andreas\n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         \n>         -- \n>         Kevin Benton\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAGR=i3hK1ow5VuoqOyX+sTxkFzTAzv6QV=SSxcB6=7S-Ls1EVA@mail.gmail.com>',NULL),('<1409229406.7370.94.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 13:36:46',3600,'2014-08-28 12:36:46',NULL,'[openstack-dev] [oslo.messaging] Request to include AMQP 1.0\n support in Juno-3','On Thu, 2014-08-28 at 13:24 +0200, Flavio Percoco wrote:\n> On 08/27/2014 03:35 PM, Ken Giusti wrote:\n> > Hi All,\n> > \n> > I believe Juno-3 is our last chance to get this feature [1] included\n> > into olso.messaging.\n> > \n> > I honestly believe this patch is about as low risk as possible for a\n> > change that introduces a whole new transport into oslo.messaging.  The\n> > patch shouldn\'t affect the existing transports at all, and doesn\'t\n> > come into play unless the application specifically turns on the new\n> > \'amqp\' transport, which won\'t be the case for existing applications.\n> > \n> > The patch includes a set of functional tests which exercise all the\n> > messaging patterns, timeouts, and even broker failover. These tests do\n> > not mock out any part of the driver - a simple test broker is included\n> > which allows the full driver codepath to be executed and verified.\n> > \n> > IFAIK, the only remaining technical block to adding this feature,\n> > aside from core reviews [2], is sufficient infrastructure test coverage.\n> > We discussed this a bit at the last design summit.  The root of the\n> > issue is that this feature is dependent on a platform-specific library\n> > (proton) that isn\'t in the base repos for most of the CI platforms.\n> > But it is available via EPEL, and the Apache QPID team is actively\n> > working towards getting the packages into Debian (a PPA is available\n> > in the meantime).\n> > \n> > In the interim I\'ve proposed a non-voting CI check job that will\n> > sanity check the new driver on EPEL based systems [3].  I\'m also\n> > working towards adding devstack support [4], which won\'t be done in\n> > time for Juno but nevertheless I\'m making it happen.\n> > \n> > I fear that this feature\'s inclusion is stuck in a chicken/egg\n> > deadlock: the driver won\'t get merged until there is CI support, but\n> > the CI support won\'t run correctly (and probably won\'t get merged)\n> > until the driver is available.  The driver really has to be merged\n> > first, before I can continue with CI/devstack development.\n> > \n> > [1] https://blueprints.launchpad.net/oslo.messaging/+spec/amqp10-driver-implementation\n> > [2] https://review.openstack.org/#/c/75815/\n> > [3] https://review.openstack.org/#/c/115752/\n> > [4] https://review.openstack.org/#/c/109118/\n> \n> \n> Hi Ken,\n> \n> Thanks a lot for your hard work here. As I stated in my last comment on\n> the driver\'s review, I think we should let this driver land and let\n> future patches improve it where/when needed.\n> \n> I agreed on letting the driver land as-is based on the fact that there\n> are patches already submitted ready to enable the gates for this driver.\n\nI feel bad that the driver has been in a pretty complete state for quite\na while but hasn\'t received a whole lot of reviews. There\'s a lot of\npromise to this idea, so it would be ideal if we could unblock it.\n\nOne thing I\'ve been meaning to do this cycle is add concrete advice for\noperators on the state of each driver. I think we\'d be a lot more\ncomfortable merging this in Juno if we could somehow make it clear to\noperators that it\'s experimental right now. My idea was:\n\n  - Write up some notes which discusses the state of each driver e.g.\n\n      - RabbitMQ - the default, used by the majority of OpenStack \n        deployments, perhaps list some of the known bugs, particularly \n        around HA.\n\n      - Qpid - suitable for production, but used in a limited number of \n        deployments. Again, list known issues. Mention that it will \n        probably be removed with the amqp10 driver matures.\n\n      - Proton/AMQP 1.0 - experimental, in active development, will\n        support  multiple brokers and topologies, perhaps a pointer to a\n        wiki page with the current TODO list\n\n      - ZeroMQ - unmaintained and deprecated, planned for removal in\n        Kilo\n\n  - Propose this addition to the API docs and ask the operators list \n    for feedback\n\n  - Propose a patch which adds a load-time deprecation warning to the \n    ZeroMQ driver\n\n  - Include a load-time experimental warning in the proton driver\n\nThoughts on that?\n\n(I understand the ZeroMQ situation needs further discussion - I don\'t\nthink that\'s on-topic for the thread, I was just using it as example of\nwhat kind of advice we\'d be giving in these docs)\n\nMark.\n\n\n\n','<53FF1160.5040103@redhat.com>',NULL),('<1409239213.2306.7.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 11:20:13',-14400,'2014-08-28 15:20:13',NULL,'[openstack-dev] [sahara] Notes on developing Sahara Spark EDP to\n work with swift:// paths','Hi folks,\n\n  I\'ve updated this etherpad with notes from an investigation of\nSpark/Swift and the hadoop-openstack plugin carried in the sahara-extra\nrepo.\n  \n  Following the notes there, I was able to access swift:// paths from\nSpark jobs on a Spark standalone cluster launched from Sahara and then\nfixed up by hand.\n\n  Comments welcome.  This is a POC at this point imho, we have work to\ndo to fully integrate this into Sahara.\n\nhttps://etherpad.openstack.org/p/sahara_spark_edp\n\nBest,\n\nTrevor\n\n\n\n',NULL,NULL),('<1409240937.4323.17.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 17:48:57',7200,'2014-08-28 15:48:57',NULL,'[openstack-dev] [neutron][ml2] Openvswitch agent support for\n non promic mode adapters','Hi Mathieu, \nplease see my comments below.\n\n\nOn Wed, 2014-08-27 at 16:13 +0200, Mathieu Rohon wrote:\n> hi irena,\n> \n> in the proposal of andreas you want to enforce the non-promisc mode\n> per l2-agent? \nyes, kind of. We\'re currently not yet sure how to figure out the right\ninterface for the registration. In the worst case it would be another\nconfig parameter saying \"register macs on ethx\". But maybe there\'s a\nbetter automated way. We need to have a closer look at this.\n\n> so every port managed by this agent will have to be in a\n> non-promisc state?\n> at a first read of the mail, I understood that you want to manage that\n> per port with an extension.\nI guess you came to that conclusion as I was mentioning \"only in vlan\nand flat networking\", right? This applies at least for my use case, but\nI do not yet have full insight into the sriov use case of Irena. \nBut if it\'s also only for vlan and flat networking, an extension might\nbe a good option. But we need a better understanding of the problem and\nof the extension framework first! Thanks for your hint!\n\n> By using an extension, an agent could host promisc and non-promisc\n> net-adapters, and other MD could potentially leverage this info (at\n> least LB MD).\n> On Wed, Aug 27, 2014 at 3:45 PM, Irena Berezovsky <irenab at mellanox.com> wrote:\n> > Hi Mathieu,\n> > We had a short discussion with Andreas about the use case stated below and also considered the SR-IOV related use case.\n> > It seems that all required changes can be encapsulated in the L2 OVS agent, since it requires to add fdb mac registration on adapted interface.\n> > What was your idea related to extension manager in ML2?\n> >\n> > Thanks,\n> > Irena\n> >\n> > -----Original Message-----\n> > From: Mathieu Rohon [mailto:]\n> > Sent: Wednesday, August 27, 2014 3:11 PM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters\n> >\n> > you probably should consider using the future extension manager in ML2 :\n> >\n> > https://review.openstack.org/#/c/89211/\n> >\n\n\n\n\n','<CAAfiWQp_ZQxhMf97Dfmskqj7=XtemjGiwgaZtAQ87RKmn0dDiQ@mail.gmail.com>',NULL),('<1409241462-sup-9617@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 08:58:11',-25200,'2014-08-28 15:58:11',NULL,'[openstack-dev] [Spam] Re: [Openstack][TripleO] [Ironic] What\n	if undercloud machines down, can we reboot overcloud machines?','Excerpts from Jyoti Ranjan\'s message of 2014-08-27 21:20:19 -0700:\n> I do agree but it create an extra requirement for Undercloud if we high\n> availability is important criteria. Because of this, undercloud has to be\n> there 24x7, 365 days and to make it available we need to have HA for this\n> also. So, you indirectly mean that undercloud also should be designed\n> keeping high availability in mind.\n\nI\'m worried that you may be overstating the needs of a typical cloud.\n\nThe undercloud needs to be able to reach a state of availability when\nyou need to boot boxes. Even if you are doing CD and _constantly_\nrebooting boxes, you can take your undercloud down for an hour, as long\nas it can be brought back up for emergencies.\n\nHowever, Ironic has already been designed this way. I believe that\nIronic has a nice dynamic hash ring of server ownership, and if you\nmark a conductor down, the other conductors will assume ownership of\nthe machines that it was holding. So the path to making this HA is\nbasically \"add one more undercloud server.\"\n\nIronic experts, please tell me this is true, and not just something I\ninserted into my own distorted version of reality to help me sleep at\nnight.\n\n\n','<CAKCrtoPkFosn4NtFiz8_peav-gmQL3Ra58v+bjootCfz_hYu5A@mail.gmail.com>',NULL),('<1409245729.2306.8.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 13:08:49',-14400,'2014-08-28 17:08:49',NULL,'[openstack-dev] [sahara] Notes on developing Sahara Spark EDP\n to work with swift:// paths','Gil,\n\n  thanks! I\'ll take a look.\n\nTrevor\n\nOn Thu, 2014-08-28 at 19:31 +0300, Gil Vernik wrote:\n> Hi, \n> \n> In case this is helpful for you, this is the patch i submitted to\n> Spark about Swift and Spark integration ( about to be merged ) \n> https://github.com/apache/spark/pull/1010 \n> \n> I sent information about this patch to this mailing list about two\n> months ago. \n> \n> All the best, \n> Gil. \n> \n> \n> \n> \n> \n> From:        Trevor McKay <tmckay at redhat.com> \n> To:        OpenStack Development Mailing List\n> <openstack-dev at lists.openstack.org> \n> Date:        28/08/2014 06:22 PM \n> Subject:        [openstack-dev] [sahara] Notes on developing Sahara\n> Spark EDP to work with swift:// paths \n> \n> ______________________________________________________________________\n> \n> \n> \n> Hi folks,\n> \n>  I\'ve updated this etherpad with notes from an investigation of\n> Spark/Swift and the hadoop-openstack plugin carried in the\n> sahara-extra\n> repo.\n>  \n>  Following the notes there, I was able to access swift:// paths from\n> Spark jobs on a Spark standalone cluster launched from Sahara and then\n> fixed up by hand.\n> \n>  Comments welcome.  This is a POC at this point imho, we have work to\n> do to fully integrate this into Sahara.\n> \n> https://etherpad.openstack.org/p/sahara_spark_edp\n> \n> Best,\n> \n> Trevor\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OF280FF5AF.994EEE83-ONC2257D42.0059DD95-C2257D42.005AB09B@il.ibm.com>',NULL),('<1409256984.16118.26.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 20:13:28',0,'2014-08-28 20:13:28',NULL,'[openstack-dev] [Octavia] Using Nova Scheduling Affinity and\n AntiAffinity','Yeah we were looking at the SameHost and DifferentHost filters and that\nwill probably do what we need.  Though I was hoping we could do a\ncombination of both but we can make it work with those filters I\nbelieve.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-28 at 14:56 -0400, Susanne Balle wrote:\n> Brandon\n> \n> \n> I am not sure how ready that nova feature is for general use and have\n> asked our nova lead about that. He is on vacation but should be back\n> by the start of next week. I believe this is the right approach for us\n> moving forward.\n> \n> \n> \n> We cannot make it mandatory to run the 2 filters but we can say in the\n> documentation that if these two filters aren\'t set that we cannot\n> guaranty Anti-affinity or Affinity. \n> \n> \n> The other way we can implement this is by using availability zones and\n> host aggregates. This is one technique we use to make sure we deploy\n> our in-cloud services in an HA model. This also would assume that the\n> operator is setting up Availabiltiy zones which we can\'t.\n> \n> \n> http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n> \n> \n> \n> Sahara is currently using the following filters to support host\n> affinity which is probably due to the fact that they did the work\n> before ServerGroups. I am not advocating the use of those filters but\n> just showing you that we can document the feature and it will be up to\n> the operator to set it up to get the right behavior.\n> \n> \n> Regards\n> \n> \n> Susanne \n> \n> \n> \n> Anti-affinity\n> One of the problems in Hadoop running on OpenStack is that there is no\n> ability to control where machine is actually running. We cannot be\n> sure that two new virtual machines are started on different physical\n> machines. As a result, any replication with cluster is not reliable\n> because all replicas may turn up on one physical machine.\n> Anti-affinity feature provides an ability to explicitly tell Sahara to\n> run specified processes on different compute nodes. This is especially\n> useful for Hadoop datanode process to make HDFS replicas reliable.\n> The Anti-Affinity feature requires certain scheduler filters to be\n> enabled on Nova. Edit your/etc/nova/nova.conf in the following way:\n> \n> [DEFAULT]\n> \n> ...\n> \n> scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n> scheduler_default_filters=DifferentHostFilter,SameHostFilter\n> This feature is supported by all plugins out of the box.\n> \n> \n> http://docs.openstack.org/developer/sahara/userdoc/features.html\n> \n> \n> \n> \n> \n> On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Nova scheduler has ServerGroupAffinityFilter and\n>         ServerGroupAntiAffinityFilter which does the colocation and\n>         apolocation\n>         for VMs.  I think this is something we\'ve discussed before\n>         about taking\n>         advantage of nova\'s scheduling.  I need to verify that this\n>         will work\n>         with what we (RAX) plan to do, but I\'d like to get everyone\n>         else\'s\n>         thoughts.  Also, if we do decide this works for everyone\n>         involved,\n>         should we make it mandatory that the nova-compute services are\n>         running\n>         these two filters?  I\'m also trying to see if we can use this\n>         to also do\n>         our own colocation and apolocation on load balancers, but it\n>         looks like\n>         it will be a bit complex if it can even work.  Hopefully, I\n>         can have\n>         something definitive on that soon.\n>         \n>         Thanks,\n>         Brandon\n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+zEXcbOOP5QcEbgoHDxHstLGN93zv59+VWATOTtOoAKeQ@mail.gmail.com>',NULL),('<1409260523.16118.35.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 21:12:26',0,'2014-08-28 21:12:26',NULL,'[openstack-dev] [Octavia] Using Nova Scheduling Affinity and\n AntiAffinity','Trevor and I just worked through some scenarios to make sure it can\nhandle colocation and apolocation.  It looks like it does, however not\neverything will so simple, especially when we introduce horizontal\nscaling.  Trevor\'s going to write up an email about some of the caveats\nbut so far just using a table to track what LB has what VMs and on what\nhosts will be sufficient.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-28 at 13:49 -0700, Stephen Balukoff wrote:\n> I\'m trying to think of a use case that wouldn\'t be satisfied using\n> those filters and am not coming up with anything. As such, I don\'t see\n> a problem using them to fulfill our requirements around colocation and\n> apolocation.\n> \n> \n> Stephen\n> \n> \n> On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Yeah we were looking at the SameHost and DifferentHost filters\n>         and that\n>         will probably do what we need.  Though I was hoping we could\n>         do a\n>         combination of both but we can make it work with those filters\n>         I\n>         believe.\n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle wrote:\n>         > Brandon\n>         >\n>         >\n>         > I am not sure how ready that nova feature is for general use\n>         and have\n>         > asked our nova lead about that. He is on vacation but should\n>         be back\n>         > by the start of next week. I believe this is the right\n>         approach for us\n>         > moving forward.\n>         >\n>         >\n>         >\n>         > We cannot make it mandatory to run the 2 filters but we can\n>         say in the\n>         > documentation that if these two filters aren\'t set that we\n>         cannot\n>         > guaranty Anti-affinity or Affinity.\n>         >\n>         >\n>         > The other way we can implement this is by using availability\n>         zones and\n>         > host aggregates. This is one technique we use to make sure\n>         we deploy\n>         > our in-cloud services in an HA model. This also would assume\n>         that the\n>         > operator is setting up Availabiltiy zones which we can\'t.\n>         >\n>         >\n>         >\n>         http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n>         >\n>         >\n>         >\n>         > Sahara is currently using the following filters to support\n>         host\n>         > affinity which is probably due to the fact that they did the\n>         work\n>         > before ServerGroups. I am not advocating the use of those\n>         filters but\n>         > just showing you that we can document the feature and it\n>         will be up to\n>         > the operator to set it up to get the right behavior.\n>         >\n>         >\n>         > Regards\n>         >\n>         >\n>         > Susanne\n>         >\n>         >\n>         >\n>         > Anti-affinity\n>         > One of the problems in Hadoop running on OpenStack is that\n>         there is no\n>         > ability to control where machine is actually running. We\n>         cannot be\n>         > sure that two new virtual machines are started on different\n>         physical\n>         > machines. As a result, any replication with cluster is not\n>         reliable\n>         > because all replicas may turn up on one physical machine.\n>         > Anti-affinity feature provides an ability to explicitly tell\n>         Sahara to\n>         > run specified processes on different compute nodes. This is\n>         especially\n>         > useful for Hadoop datanode process to make HDFS replicas\n>         reliable.\n>         > The Anti-Affinity feature requires certain scheduler filters\n>         to be\n>         > enabled on Nova. Edit your/etc/nova/nova.conf in the\n>         following way:\n>         >\n>         > [DEFAULT]\n>         >\n>         > ...\n>         >\n>         >\n>         scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n>         > scheduler_default_filters=DifferentHostFilter,SameHostFilter\n>         > This feature is supported by all plugins out of the box.\n>         >\n>         >\n>         >\n>         http://docs.openstack.org/developer/sahara/userdoc/features.html\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan\n>         > <brandon.logan at rackspace.com> wrote:\n>         >         Nova scheduler has ServerGroupAffinityFilter and\n>         >         ServerGroupAntiAffinityFilter which does the\n>         colocation and\n>         >         apolocation\n>         >         for VMs.  I think this is something we\'ve discussed\n>         before\n>         >         about taking\n>         >         advantage of nova\'s scheduling.  I need to verify\n>         that this\n>         >         will work\n>         >         with what we (RAX) plan to do, but I\'d like to get\n>         everyone\n>         >         else\'s\n>         >         thoughts.  Also, if we do decide this works for\n>         everyone\n>         >         involved,\n>         >         should we make it mandatory that the nova-compute\n>         services are\n>         >         running\n>         >         these two filters?  I\'m also trying to see if we can\n>         use this\n>         >         to also do\n>         >         our own colocation and apolocation on load\n>         balancers, but it\n>         >         looks like\n>         >         it will be a bit complex if it can even work.\n>         Hopefully, I\n>         >         can have\n>         >         something definitive on that soon.\n>         >\n>         >         Thanks,\n>         >         Brandon\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZroZfTctKRXJUKP1_Oy-6tXpr7sTXFD3ufu5B=+Pv9aRA@mail.gmail.com>',NULL),('<1409266491.31631.23.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-28 22:54:44',0,'2014-08-28 22:54:44',NULL,'[openstack-dev] [Octavia] Using Nova Scheduling Affinity and\n AntiAffinity','Hello all,\n\nTL;DR\nUsing the SameHostFilter and DifferentHostFilter will work functionally\nfor what Octavia needs for colocation, apolocation, and HA\nanti-affinity.  There are a couple topics that need discussed:\n\nHow should VMs be allocated per host when evaluating colocation, if each\nload balancer minimally has 2 VMs?  (Active-Active or Active-Passive)\n\nHow would a spare node pool handle affinity (i.e. will every host have a\nseparate spare node pool)?\n\n\n\nBrandon and I spent a little time white-boarding our thoughts on this\naffinity/anti-affinity problem.  Basically we came up with a couple\ntables we\'ll need in the DB, and one table representing information\nretrieved from nova, as follows:\nNote:  The tables were written with \"fixed width\" text.  Looks really\nbad in HTML.\n\n\nLB Table\n+-------+----------+-----------+\n| LB_ID | colocate | apolocate |\n+-------+----------+-----------+\n|   1   |          |           |\n+-------+----------+-----------+\n|   2   |          |     1     |\n+-------+----------+-----------+\n|   3   |    2     |           |\n+-------+----------+-----------+\n|   4   |    1     |     3     |\n+-------+----------+-----------+\n\nDB Association Table\n+-------+-------+---------+\n| LB_ID | VM_ID | HOST_ID |\n+-------+-------+---------+\n|   1   |   A   |    I    |\n+-------+-------+---------+\n|   1   |   B   |    II   |\n+-------+-------+---------+\n|   2   |   C   |   III   |\n+-------+-------+---------+\n|   2   |   D   |    IV   |\n+-------+-------+---------+\n|   3   |   E   |   III   |\n+-------+-------+---------+\n|   3   |   F   |    IV   |\n+-------+-------+---------+\n|   4   |   G   |    I    |\n+-------+-------+---------+\n|   4   |   H   |    II   |\n+-------+-------+---------+\n\nNova Information Table\n+-------+----------------+---------------------+---------+\n| VM_ID | SameHostFilter | DifferentHostFilter | HOST_ID |\n+-------+----------------+---------------------+---------+\n|   A   |                |                     |    I    |\n+-------+----------------+---------------------+---------+\n|   B   |                |          A          |    II   |\n+-------+----------------+---------------------+---------+\n|   C   |                |         A B         |   III   |\n+-------+----------------+---------------------+---------+\n|   D   |                |        A B C        |    IV   |\n+-------+----------------+---------------------+---------+\n|   E   |      C D       |                     |   III   |\n+-------+----------------+---------------------+---------+\n|   F   |      C D       |          E          |    IV   |\n+-------+----------------+---------------------+---------+\n|   G   |      A B       |         E F         |    I    |\n+-------+----------------+---------------------+---------+\n|   H   |      A B       |        E F G        |    II   |\n+-------+----------------+---------------------+---------+\n\nThe first thing we discussed was an Active-Active setup.  Above you can\nsee I enforce that the first VM will not be on the same host as the\nsecond.  In the first table, I\'ve given some ideas about what LB will\ncolocate/apolocate with another, and configured them in the association\ntable appropriately.  Can you see any configuration combination we might\nhave over-looked?\n\nAs for scaling, we considered adding of VMs in an Active-Active setup to\nbe just as trivial as the initial creation.  Just include another VM id\nin the list for DifferentHostFilter and it\'ll guarantee a different host\nassignment.\n\nThe second discussion was for Active-Passive, and we decided it would be\nvery similar to Active-Active in accordance to appending to a list for\nfiltering.  For each required Active node created for scaling, standing\nup another Passive node would happen with just another VM id\nspecification in the filter.  This keeps all the Active/Passive on\ndifferent hosts.  One could just as easily write some logic to keep all\nthe Passives on one Host and all the Actives on a different, though this\nwould potentially cause other problems.\n\nOne thing that just popped into my head would be scaling on different\nhosts to different degrees.  Example:  I already have 2 VMs, 1 active\nand 1 passive each (so 4 VMs total right now).  My scaling solution\ncould call for another 4 VMs to be stood up in the same fashion, but the\nhosts matching up like the following table:\n\n+-------+-------+---------+--------+\n| LB_ID | VM_ID | HOST_ID | ACTIVE |\n+-------+-------+---------+--------+\n|   1   |   A   |    I    |    1   |\n+-------+-------+---------+--------+\n|   1   |   B   |    II   |    0   |\n+-------+-------+---------+--------+\n|   2   |   C   |   III   |    1   |\n+-------+-------+---------+--------+\n|   2   |   D   |    IV   |    0   |\n+-------+-------+---------+--------+\n|   1   |   E   |    I    |    1   |\n+-------+-------+---------+--------+\n|   1   |   F   |    II   |    0   |\n+-------+-------+---------+--------+\n|   2   |   G   |   III   |    1   |\n+-------+-------+---------+--------+\n|   2   |   H   |    IV   |    0   |\n+-------+-------+---------+--------+\n\nThis could be done easily in an automated fashion, but how could a\ncustomer ask for something like this, or would we even let them?  Just\nsome thoughts.\n\n-Trevor\n\n\nOn Thu, 2014-08-28 at 17:36 -0400, Susanne Balle wrote:\n> We need to be careful. I believe that a user can use these filters to\n> keep requesting VMs in the case of nova to get to the size of your\n> cloud. \n> \n> \n> Also given that nova now has ServerGroups let\'s not make a quick\n> decision on using something that is being replaced with something\n> better. I suggest we investigated ServerGroups a little more before we\n> discard it.  \n> \n> The operator should really decide how he/she wants Anti-affinity by\n> setting the right filters in nova.\n> \n> \n> Susanne\n> \n> \n> On Thu, Aug 28, 2014 at 5:12 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Trevor and I just worked through some scenarios to make sure\n>         it can\n>         handle colocation and apolocation.  It looks like it does,\n>         however not\n>         everything will so simple, especially when we introduce\n>         horizontal\n>         scaling.  Trevor\'s going to write up an email about some of\n>         the caveats\n>         but so far just using a table to track what LB has what VMs\n>         and on what\n>         hosts will be sufficient.\n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Thu, 2014-08-28 at 13:49 -0700, Stephen Balukoff wrote:\n>         > I\'m trying to think of a use case that wouldn\'t be satisfied\n>         using\n>         > those filters and am not coming up with anything. As such, I\n>         don\'t see\n>         > a problem using them to fulfill our requirements around\n>         colocation and\n>         > apolocation.\n>         >\n>         >\n>         > Stephen\n>         >\n>         >\n>         > On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan\n>         > <brandon.logan at rackspace.com> wrote:\n>         >         Yeah we were looking at the SameHost and\n>         DifferentHost filters\n>         >         and that\n>         >         will probably do what we need.  Though I was hoping\n>         we could\n>         >         do a\n>         >         combination of both but we can make it work with\n>         those filters\n>         >         I\n>         >         believe.\n>         >\n>         >         Thanks,\n>         >         Brandon\n>         >\n>         >         On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle\n>         wrote:\n>         >         > Brandon\n>         >         >\n>         >         >\n>         >         > I am not sure how ready that nova feature is for\n>         general use\n>         >         and have\n>         >         > asked our nova lead about that. He is on vacation\n>         but should\n>         >         be back\n>         >         > by the start of next week. I believe this is the\n>         right\n>         >         approach for us\n>         >         > moving forward.\n>         >         >\n>         >         >\n>         >         >\n>         >         > We cannot make it mandatory to run the 2 filters\n>         but we can\n>         >         say in the\n>         >         > documentation that if these two filters aren\'t set\n>         that we\n>         >         cannot\n>         >         > guaranty Anti-affinity or Affinity.\n>         >         >\n>         >         >\n>         >         > The other way we can implement this is by using\n>         availability\n>         >         zones and\n>         >         > host aggregates. This is one technique we use to\n>         make sure\n>         >         we deploy\n>         >         > our in-cloud services in an HA model. This also\n>         would assume\n>         >         that the\n>         >         > operator is setting up Availabiltiy zones which we\n>         can\'t.\n>         >         >\n>         >         >\n>         >         >\n>         >\n>          http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n>         >         >\n>         >         >\n>         >         >\n>         >         > Sahara is currently using the following filters to\n>         support\n>         >         host\n>         >         > affinity which is probably due to the fact that\n>         they did the\n>         >         work\n>         >         > before ServerGroups. I am not advocating the use\n>         of those\n>         >         filters but\n>         >         > just showing you that we can document the feature\n>         and it\n>         >         will be up to\n>         >         > the operator to set it up to get the right\n>         behavior.\n>         >         >\n>         >         >\n>         >         > Regards\n>         >         >\n>         >         >\n>         >         > Susanne\n>         >         >\n>         >         >\n>         >         >\n>         >         > Anti-affinity\n>         >         > One of the problems in Hadoop running on OpenStack\n>         is that\n>         >         there is no\n>         >         > ability to control where machine is actually\n>         running. We\n>         >         cannot be\n>         >         > sure that two new virtual machines are started on\n>         different\n>         >         physical\n>         >         > machines. As a result, any replication with\n>         cluster is not\n>         >         reliable\n>         >         > because all replicas may turn up on one physical\n>         machine.\n>         >         > Anti-affinity feature provides an ability to\n>         explicitly tell\n>         >         Sahara to\n>         >         > run specified processes on different compute\n>         nodes. This is\n>         >         especially\n>         >         > useful for Hadoop datanode process to make HDFS\n>         replicas\n>         >         reliable.\n>         >         > The Anti-Affinity feature requires certain\n>         scheduler filters\n>         >         to be\n>         >         > enabled on Nova. Edit your/etc/nova/nova.conf in\n>         the\n>         >         following way:\n>         >         >\n>         >         > [DEFAULT]\n>         >         >\n>         >         > ...\n>         >         >\n>         >         >\n>         >\n>          scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n>         >         >\n>         scheduler_default_filters=DifferentHostFilter,SameHostFilter\n>         >         > This feature is supported by all plugins out of\n>         the box.\n>         >         >\n>         >         >\n>         >         >\n>         >\n>          http://docs.openstack.org/developer/sahara/userdoc/features.html\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         >         > On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan\n>         >         > <brandon.logan at rackspace.com> wrote:\n>         >         >         Nova scheduler has\n>         ServerGroupAffinityFilter and\n>         >         >         ServerGroupAntiAffinityFilter which does\n>         the\n>         >         colocation and\n>         >         >         apolocation\n>         >         >         for VMs.  I think this is something we\'ve\n>         discussed\n>         >         before\n>         >         >         about taking\n>         >         >         advantage of nova\'s scheduling.  I need to\n>         verify\n>         >         that this\n>         >         >         will work\n>         >         >         with what we (RAX) plan to do, but I\'d\n>         like to get\n>         >         everyone\n>         >         >         else\'s\n>         >         >         thoughts.  Also, if we do decide this\n>         works for\n>         >         everyone\n>         >         >         involved,\n>         >         >         should we make it mandatory that the\n>         nova-compute\n>         >         services are\n>         >         >         running\n>         >         >         these two filters?  I\'m also trying to see\n>         if we can\n>         >         use this\n>         >         >         to also do\n>         >         >         our own colocation and apolocation on load\n>         >         balancers, but it\n>         >         >         looks like\n>         >         >         it will be a bit complex if it can even\n>         work.\n>         >         Hopefully, I\n>         >         >         can have\n>         >         >         something definitive on that soon.\n>         >         >\n>         >         >         Thanks,\n>         >         >         Brandon\n>         >         >\n>          _______________________________________________\n>         >         >         OpenStack-dev mailing list\n>         >         >         OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >         >\n>         >         >\n>         >         > _______________________________________________\n>         >         > OpenStack-dev mailing list\n>         >         > OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > --\n>         > Stephen Balukoff\n>         > Blue Box Group, LLC\n>         > (800)613-4305 x807\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+zrC98Rn6vtmsHpDrRr9FPDR2KC+f6e8ZV+J+mLAROUQQ@mail.gmail.com>',NULL),('<1409285550.4357.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:12:30',0,'2014-08-29 04:12:30',NULL,'[openstack-dev] [nova] [neutron] Specs for K release','Kyle,\nDoes this apply to blueprints that are destined for the incubator as\nwell?  I assume the incubator does require a spec process too.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-28 at 08:37 -0500, Kyle Mestery wrote:\n> On Thu, Aug 28, 2014 at 8:30 AM, Michael Still <mikal at stillhq.com> wrote:\n> > For nova we haven\'t gotten around to doing this, but it shouldn\'t be a\n> > big deal. I\'ll add it to the agenda for today\'s meeting.\n> >\n> > Michael\n> >\n> For Neutron, I have not gone through and removed specs which merged\n> and haven\'t made it yet. I\'ll do that today with a review to\n> neutron-specs, and once we hit FF next week I\'ll make another pass to\n> remove things which didn\'t make Juno. Keep in mind if your spec\n> doesn\'t make Juno you will have to re-propose it for Kilo.\n> \n> Thanks!\n> Kyle\n> \n> > On Thu, Aug 28, 2014 at 2:07 AM, Andreas Scheuring\n> > <scheuran at linux.vnet.ibm.com> wrote:\n> >> Hi,\n> >> is it already possible to submit specs (nova & neutron) for the K\n> >> release? Would be great for getting early feedback and tracking\n> >> comments. Or should I just commit it to the juno folder?\n> >>\n> >> Thanks,\n> >> Andreas\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> >\n> > --\n> > Rackspace Australia\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAL3VkVwrrgxO7xbuAymb8nRGyd+LUax4r_SY=cZTYdsaaRfXuQ@mail.gmail.com>',NULL),('<1409285921.4357.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:18:41',0,'2014-08-29 04:18:41',NULL,'[openstack-dev] [Octavia] Using Nova Scheduling Affinity and\n AntiAffinity','We may have to put quotas or something built into Octavia.  Since we are\nkeeping the concept of tenant in Octavia, this may as well be done.\nThat probably doesn\'t totally solve the problem though.\n\nServerGroups will be great to use for keeping VMs off the same host for\nHA.  It will be tough to use them for colocation and apolocation of\nloadbalancers, though not impossible from my shallow research of it.\n\nP.S. I feel like I wrote this before so sorry if this is a duplicate,\nbut I must be losing my mind.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-28 at 17:36 -0400, Susanne Balle wrote:\n> We need to be careful. I believe that a user can use these filters to\n> keep requesting VMs in the case of nova to get to the size of your\n> cloud. \n> \n> \n> Also given that nova now has ServerGroups let\'s not make a quick\n> decision on using something that is being replaced with something\n> better. I suggest we investigated ServerGroups a little more before we\n> discard it.  \n> \n> The operator should really decide how he/she wants Anti-affinity by\n> setting the right filters in nova.\n> \n> \n> Susanne\n> \n> \n> On Thu, Aug 28, 2014 at 5:12 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Trevor and I just worked through some scenarios to make sure\n>         it can\n>         handle colocation and apolocation.  It looks like it does,\n>         however not\n>         everything will so simple, especially when we introduce\n>         horizontal\n>         scaling.  Trevor\'s going to write up an email about some of\n>         the caveats\n>         but so far just using a table to track what LB has what VMs\n>         and on what\n>         hosts will be sufficient.\n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Thu, 2014-08-28 at 13:49 -0700, Stephen Balukoff wrote:\n>         > I\'m trying to think of a use case that wouldn\'t be satisfied\n>         using\n>         > those filters and am not coming up with anything. As such, I\n>         don\'t see\n>         > a problem using them to fulfill our requirements around\n>         colocation and\n>         > apolocation.\n>         >\n>         >\n>         > Stephen\n>         >\n>         >\n>         > On Thu, Aug 28, 2014 at 1:13 PM, Brandon Logan\n>         > <brandon.logan at rackspace.com> wrote:\n>         >         Yeah we were looking at the SameHost and\n>         DifferentHost filters\n>         >         and that\n>         >         will probably do what we need.  Though I was hoping\n>         we could\n>         >         do a\n>         >         combination of both but we can make it work with\n>         those filters\n>         >         I\n>         >         believe.\n>         >\n>         >         Thanks,\n>         >         Brandon\n>         >\n>         >         On Thu, 2014-08-28 at 14:56 -0400, Susanne Balle\n>         wrote:\n>         >         > Brandon\n>         >         >\n>         >         >\n>         >         > I am not sure how ready that nova feature is for\n>         general use\n>         >         and have\n>         >         > asked our nova lead about that. He is on vacation\n>         but should\n>         >         be back\n>         >         > by the start of next week. I believe this is the\n>         right\n>         >         approach for us\n>         >         > moving forward.\n>         >         >\n>         >         >\n>         >         >\n>         >         > We cannot make it mandatory to run the 2 filters\n>         but we can\n>         >         say in the\n>         >         > documentation that if these two filters aren\'t set\n>         that we\n>         >         cannot\n>         >         > guaranty Anti-affinity or Affinity.\n>         >         >\n>         >         >\n>         >         > The other way we can implement this is by using\n>         availability\n>         >         zones and\n>         >         > host aggregates. This is one technique we use to\n>         make sure\n>         >         we deploy\n>         >         > our in-cloud services in an HA model. This also\n>         would assume\n>         >         that the\n>         >         > operator is setting up Availabiltiy zones which we\n>         can\'t.\n>         >         >\n>         >         >\n>         >         >\n>         >\n>          http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/\n>         >         >\n>         >         >\n>         >         >\n>         >         > Sahara is currently using the following filters to\n>         support\n>         >         host\n>         >         > affinity which is probably due to the fact that\n>         they did the\n>         >         work\n>         >         > before ServerGroups. I am not advocating the use\n>         of those\n>         >         filters but\n>         >         > just showing you that we can document the feature\n>         and it\n>         >         will be up to\n>         >         > the operator to set it up to get the right\n>         behavior.\n>         >         >\n>         >         >\n>         >         > Regards\n>         >         >\n>         >         >\n>         >         > Susanne\n>         >         >\n>         >         >\n>         >         >\n>         >         > Anti-affinity\n>         >         > One of the problems in Hadoop running on OpenStack\n>         is that\n>         >         there is no\n>         >         > ability to control where machine is actually\n>         running. We\n>         >         cannot be\n>         >         > sure that two new virtual machines are started on\n>         different\n>         >         physical\n>         >         > machines. As a result, any replication with\n>         cluster is not\n>         >         reliable\n>         >         > because all replicas may turn up on one physical\n>         machine.\n>         >         > Anti-affinity feature provides an ability to\n>         explicitly tell\n>         >         Sahara to\n>         >         > run specified processes on different compute\n>         nodes. This is\n>         >         especially\n>         >         > useful for Hadoop datanode process to make HDFS\n>         replicas\n>         >         reliable.\n>         >         > The Anti-Affinity feature requires certain\n>         scheduler filters\n>         >         to be\n>         >         > enabled on Nova. Edit your/etc/nova/nova.conf in\n>         the\n>         >         following way:\n>         >         >\n>         >         > [DEFAULT]\n>         >         >\n>         >         > ...\n>         >         >\n>         >         >\n>         >\n>          scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler\n>         >         >\n>         scheduler_default_filters=DifferentHostFilter,SameHostFilter\n>         >         > This feature is supported by all plugins out of\n>         the box.\n>         >         >\n>         >         >\n>         >         >\n>         >\n>          http://docs.openstack.org/developer/sahara/userdoc/features.html\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         >         >\n>         >         > On Thu, Aug 28, 2014 at 1:26 AM, Brandon Logan\n>         >         > <brandon.logan at rackspace.com> wrote:\n>         >         >         Nova scheduler has\n>         ServerGroupAffinityFilter and\n>         >         >         ServerGroupAntiAffinityFilter which does\n>         the\n>         >         colocation and\n>         >         >         apolocation\n>         >         >         for VMs.  I think this is something we\'ve\n>         discussed\n>         >         before\n>         >         >         about taking\n>         >         >         advantage of nova\'s scheduling.  I need to\n>         verify\n>         >         that this\n>         >         >         will work\n>         >         >         with what we (RAX) plan to do, but I\'d\n>         like to get\n>         >         everyone\n>         >         >         else\'s\n>         >         >         thoughts.  Also, if we do decide this\n>         works for\n>         >         everyone\n>         >         >         involved,\n>         >         >         should we make it mandatory that the\n>         nova-compute\n>         >         services are\n>         >         >         running\n>         >         >         these two filters?  I\'m also trying to see\n>         if we can\n>         >         use this\n>         >         >         to also do\n>         >         >         our own colocation and apolocation on load\n>         >         balancers, but it\n>         >         >         looks like\n>         >         >         it will be a bit complex if it can even\n>         work.\n>         >         Hopefully, I\n>         >         >         can have\n>         >         >         something definitive on that soon.\n>         >         >\n>         >         >         Thanks,\n>         >         >         Brandon\n>         >         >\n>          _______________________________________________\n>         >         >         OpenStack-dev mailing list\n>         >         >         OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >         >\n>         >         >\n>         >         > _______________________________________________\n>         >         > OpenStack-dev mailing list\n>         >         > OpenStack-dev at lists.openstack.org\n>         >         >\n>         >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >         _______________________________________________\n>         >         OpenStack-dev mailing list\n>         >         OpenStack-dev at lists.openstack.org\n>         >\n>          http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         >\n>         >\n>         >\n>         >\n>         >\n>         > --\n>         > Stephen Balukoff\n>         > Blue Box Group, LLC\n>         > (800)613-4305 x807\n>         > _______________________________________________\n>         > OpenStack-dev mailing list\n>         > OpenStack-dev at lists.openstack.org\n>         >\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+zrC98Rn6vtmsHpDrRr9FPDR2KC+f6e8ZV+J+mLAROUQQ@mail.gmail.com>',NULL),('<1409286681.4357.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:31:21',0,'2014-08-29 04:31:21',NULL,'[openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax\n additions/changes','On Tue, 2014-08-26 at 14:22 +0300, John Schwarz wrote:\n> \n> On 08/25/2014 10:06 PM, Brandon Logan wrote:\n> >>\n> >> 2. Therefor, there should be some configuration to specifically enable\n> >> either version (not both) in case LBaaS is needed. In this case, the\n> >> other version is disabled (ie. a REST query for non-active version\n> >> should return a \"not activated\" error). Additionally, adding a\n> >> \'lb-version\' command to return the version currently active seems like a\n> >> good user-facing idea. We should see how this doesn\'t negatively effect\n> >> the db migration process (for example, allowing read-only commands for\n> >> both versions?)\n> > \n> > A /version endpoint can be added for both v1 and v2 extensions and\n> > service plugins.  If it doesn\'t already exist, it would be nice if\n> > neutron had an endpoint that would return the list of loaded extensions\n> > and their versions.\n> > \n> There is \'neutron ext-list\', but I\'m not familiar enough with it or with\n> the REST API to say if we can use that.\n\nLooks like this will be sufficient.  No new rest endpoint needed.\n\n> >>\n> >> 3. Another decision that\'s needed to be made is the syntax for v2. As\n> >> mentioned, the current new syntax is \'neutron lbaas-<object>-<command>\'\n> >> (against the old \'lb-<object>-<action>\'), keeping in mind that once v1\n> >> is deprecated, a syntax like \'lbv2-<object>-<action>\' would be probably\n> >> unwanted. Is \'lbaas-<object>-<command>\' okay with everyone?\n> > \n> > That is the reason we with with lbaas because lbv2 looks ugly and we\'d\n> > be stuck with it for the lifetime of v2, unless we did another migration\n> > back to lb for it.  Which seemed wrong to do, since then we\'d have to\n> > accept both lbv2 and lb commands, and then deprecate lbv2.\n> > \n> > I assume this also means you are fine with the prefix in the API\n> > resource of /lbaas as well then?\n> > \n> I don\'t mind, as long there is a similar mechanism which disables the\n> non-active REST API commands. Does anyone disagree?\n> >>\n> >> 4. If we are going for different API between versions, appropriate\n> >> patches also need to be written for lbaas-related scripts and also\n> >> Tempest, and their maintainers should probably be notified.\n> > \n> > Could you elaborate on this? I don\'t understand what you mean by\n> > \"different API between version.\"\n> > \n> The intention was that the change of the user-facing API also forces\n> changes on other levels - not only neutronclient needs to be modified\n> accordingly, but also tempest system tests, horizon interface regarding\n> LBaaS...\n\nOh yes this is in the works.  Miguel is spearheading the tempest tests\nand has made good progress on it.  Horizon integration hasn\'t begun yet\nthough.  Definitely something we want to get in though.  Have to wait\nuntil more information about the incubator comes out and where these\npatches for other products need to go.\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53FC6DF9.3030405@redhat.com>',NULL),('<1409286798.4357.11.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:33:18',0,'2014-08-29 04:33:18',NULL,'[openstack-dev] [Neutron] [LBaaS] LBaaS v2 API\n	syntax	additions/changes','Hi Yair,\n\nOn Thu, 2014-08-28 at 07:47 -0400, Yair Fried wrote:\n> I would like to add a question to John\'s list\n> \n> \n> \n> ----- Original Message -----\n> > From: \"John Schwarz\" <jschwarz at redhat.com>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> > Sent: Tuesday, August 26, 2014 2:22:33 PM\n> > Subject: Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax	additions/changes\n> > \n> > \n> > \n> > On 08/25/2014 10:06 PM, Brandon Logan wrote:\n> > >>\n> > >> 2. Therefor, there should be some configuration to specifically enable\n> > >> either version (not both) in case LBaaS is needed. In this case, the\n> > >> other version is disabled (ie. a REST query for non-active version\n> > >> should return a \"not activated\" error). Additionally, adding a\n> > >> \'lb-version\' command to return the version currently active seems like a\n> > >> good user-facing idea. We should see how this doesn\'t negatively effect\n> > >> the db migration process (for example, allowing read-only commands for\n> > >> both versions?)\n> > > \n> > > A /version endpoint can be added for both v1 and v2 extensions and\n> > > service plugins.  If it doesn\'t already exist, it would be nice if\n> > > neutron had an endpoint that would return the list of loaded extensions\n> > > and their versions.\n> > > \n> > There is \'neutron ext-list\', but I\'m not familiar enough with it or with\n> > the REST API to say if we can use that.\n> > >>\n> > >> 3. Another decision that\'s needed to be made is the syntax for v2. As\n> > >> mentioned, the current new syntax is \'neutron lbaas-<object>-<command>\'\n> > >> (against the old \'lb-<object>-<action>\'), keeping in mind that once v1\n> > >> is deprecated, a syntax like \'lbv2-<object>-<action>\' would be probably\n> > >> unwanted. Is \'lbaas-<object>-<command>\' okay with everyone?\n> > > \n> > > That is the reason we with with lbaas because lbv2 looks ugly and we\'d\n> > > be stuck with it for the lifetime of v2, unless we did another migration\n> > > back to lb for it.  Which seemed wrong to do, since then we\'d have to\n> > > accept both lbv2 and lb commands, and then deprecate lbv2.\n> > > \n> > > I assume this also means you are fine with the prefix in the API\n> > > resource of /lbaas as well then?\n> > > \n> > I don\'t mind, as long there is a similar mechanism which disables the\n> > non-active REST API commands. Does anyone disagree?\n> > >>\n> > >> 4. If we are going for different API between versions, appropriate\n> > >> patches also need to be written for lbaas-related scripts and also\n> > >> Tempest, and their maintainers should probably be notified.\n> > > \n> > > Could you elaborate on this? I don\'t understand what you mean by\n> > > \"different API between version.\"\n> > > \n> > The intention was that the change of the user-facing API also forces\n> > changes on other levels - not only neutronclient needs to be modified\n> > accordingly, but also tempest system tests, horizon interface regarding\n> > LBaaS...\n> \n> \n> 5. If we accept #3 and #4 to mean that the python-client API and CLI must be \n> changed/updated and so does Tempest clients and tests, then what about other \n> projects consuming the Neutron API? How are Heat and Ceilometer going to be \n> affected by this change?\n\nThat\'s a good question about Heat and Ceilometer, and honestly it hasn\'t\nbeen discussed.  It definitely should be something that should be\nresearched.  I think once the incubator dust has settled and we know\nwhat goes where, we can dive into this further.  Thanks for bringing it\nup.\n\n> \n> Yair\n> \n> \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1830433378.52826180.1409226425690.JavaMail.zimbra@redhat.com>',NULL),('<1409287626.4357.24.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:47:05',0,'2014-08-29 04:47:05',NULL,'[openstack-dev] Design sessions for Neutron LBaaS. What do we\n want/need?','I\'m not sure exactly how many design sessions will be available but it\nseems like 2 for Neutron LBaaS and 2 for Octavia will be hard to\naccomplish.  Neutron LBaaS had 2 in Atlanta didn\'t it?  One broad one\nofr Neutron LBaaS and one more specific to TLS and L7.  I\'m totally on\nboard for having 2 for each though.  I just think since Octavia is still\njust an idea at this point, it\'d be hard getting space and time for a\ndesign session for it, much less 2.  Doesn\'t stop us from doing the pods\nor ad hoc sessions though.\n\nAs for topics:\nNeutron LBaaS\n1) I\'ve been wanting to try and solve the problem (at least I think it\nis a problem) of drivers being responsible for managing the status of\nentities.  In my opinion, Neutron LBaaS should be as consistent as\npossible not matter what drivers are being used.  This is caused by\nsupporting both Asynchronous and Synchronous drivers.  I\'ve got some\nideas on how to solve this.\n2) Different status types on entities.  Operating status and\nProvisioning status.\n\nOctavia\nI hope we have gotten far enough along this to have some really detailed\ndesign discussions.  Hopefully we are within reach of a 0.5 milestone.\nOther than that, too early to tell what exact kind of design talks we\nwill need.\n\nThanks,\nBrandon\n\nOn Thu, 2014-08-28 at 10:49 -0400, Susanne Balle wrote:\n> \n> \n> LBaaS team,\n> \n> \n> As we discussed in the Weekly LBaaS meeting this morning we should\n> make sure we get the design sessions scheduled that we are interested\n> in. \n> \n> \n> We currently agreed on the following:\n> \n> \n> * Neutron LBaaS. we want to schedule 2 sessions. I am assuming that we\n> want to go over status and also the whole incubator thingy and how we\n> will best move forward. \n> \n> \n> * Octavia: We want to schedule 2 sessions. \n> ---  During one of the sessions I would like to discuss the pros and\n> cons of putting Octavia into the Neutron LBaaS incubator project right\n> away. If it is going to be the reference implementation for LBaaS v 2\n> then I believe Octavia belong in Neutron LBaaS v2 incubator. \n> \n> \n> * Flavors which should be coordinated with markmcclain and\n> enikanorov. \n> --- https://review.openstack.org/#/c/102723/\n> \n> \n> Is this too many sessions given the constraints? I am assuming that we\n> can also meet at the pods like we did at the last summit. \n> \n> \n> thoughts?\n> \n> \n> Regards Susanne\n> \n> Thierry\n> Carrez <thierry at openstack.org>\n> Aug 27 (1 day\n> ago)\n> \n> \n> \n> \n> to OpenStack\n> \n> \n> \n> \n> \n> Hi everyone,\n> \n> I\'ve been thinking about what changes we can bring to\n> the Design Summit\n> format to make it more productive. I\'ve heard the feedback from the\n> mid-cycle meetups and would like to apply some of those ideas for\n> Paris,\n> within the constraints we have (already booked space and time). Here\n> is\n> something we could do:\n> \n> Day 1. Cross-project sessions / incubated projects / other projects\n> \n> I think that worked well last time. 3 parallel rooms where we can\n> address top cross-project questions, discuss the results of the\n> various\n> experiments we conducted during juno. Don\'t hesitate to schedule 2\n> slots\n> for discussions, so that we have time to come to the bottom of those\n> issues. Incubated projects (and maybe \"other\" projects, if space\n> allows)\n> occupy the remaining space on day 1, and could occupy \"pods\" on the\n> other days.\n> \n> Day 2 and Day 3. Scheduled sessions for various programs\n> \n> That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> available. So, rather than trying to cover all the scope, the idea\n> would\n> be to focus those sessions on specific issues which really require\n> face-to-face discussion (which can\'t be solved on the ML or using spec\n> discussion) *or* require a lot of user feedback. That way, appearing\n> in\n> the general schedule is very helpful. This will require us to be a lot\n> stricter on what we accept there and what we don\'t -- we won\'t have\n> space for courtesy sessions anymore, and traditional/unnecessary\n> sessions (like my traditional \"release schedule\" one) should just move\n> to the mailing-list.\n> \n> Day 4. Contributors meetups\n> \n> On the last day, we could try to split the space so that we can\n> conduct\n> parallel midcycle-meetup-like contributors gatherings, with no time\n> boundaries and an open agenda. Large projects could get a full day,\n> smaller projects would get half a day (but could continue the\n> discussion\n> in a local bar). Ideally that meetup would end with some alignment on\n> release goals, but the idea is to make the best of that time together\n> to\n> solve the issues you have. Friday would finish with the design summit\n> feedback session, for those who are still around.\n> \n> \n> I think this proposal makes the best use of our setup: discuss clear\n> cross-project issues, address key specific topics which need\n> face-to-face time and broader attendance, then try to replicate the\n> success of midcycle meetup-like open unscheduled time to discuss\n> whatever is hot at this point.\n> \n> There are still details to work out (is it possible split the space,\n> should we use the usual design summit CFP website to organize the\n> \"scheduled\" time...), but I would first like to have your feedback on\n> this format. Also if you have alternative proposals that would make a\n> better use of our 4 days, let me know.\n> \n> Cheers,\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBYD+xSFQ=V96CuZaBzbioOnm=yDyKBY20vSgeZyKmVTsfKSg@mail.gmail.com>',NULL),('<1409287755.4357.26.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:49:15',0,'2014-08-29 04:49:15',NULL,'[openstack-dev] [Neutron][LBass] Design sessions for Neutron\n LBaaS. What do we want/need?','Adding correct subject tags because I replied to the original email.  I\nblame you Susanne!\n\nOn Thu, 2014-08-28 at 23:47 -0500, Brandon Logan wrote:\n> I\'m not sure exactly how many design sessions will be available but it\n> seems like 2 for Neutron LBaaS and 2 for Octavia will be hard to\n> accomplish.  Neutron LBaaS had 2 in Atlanta didn\'t it?  One broad one\n> ofr Neutron LBaaS and one more specific to TLS and L7.  I\'m totally on\n> board for having 2 for each though.  I just think since Octavia is still\n> just an idea at this point, it\'d be hard getting space and time for a\n> design session for it, much less 2.  Doesn\'t stop us from doing the pods\n> or ad hoc sessions though.\n> \n> As for topics:\n> Neutron LBaaS\n> 1) I\'ve been wanting to try and solve the problem (at least I think it\n> is a problem) of drivers being responsible for managing the status of\n> entities.  In my opinion, Neutron LBaaS should be as consistent as\n> possible not matter what drivers are being used.  This is caused by\n> supporting both Asynchronous and Synchronous drivers.  I\'ve got some\n> ideas on how to solve this.\n> 2) Different status types on entities.  Operating status and\n> Provisioning status.\n> \n> Octavia\n> I hope we have gotten far enough along this to have some really detailed\n> design discussions.  Hopefully we are within reach of a 0.5 milestone.\n> Other than that, too early to tell what exact kind of design talks we\n> will need.\n> \n> Thanks,\n> Brandon\n> \n> On Thu, 2014-08-28 at 10:49 -0400, Susanne Balle wrote:\n> > \n> > \n> > LBaaS team,\n> > \n> > \n> > As we discussed in the Weekly LBaaS meeting this morning we should\n> > make sure we get the design sessions scheduled that we are interested\n> > in. \n> > \n> > \n> > We currently agreed on the following:\n> > \n> > \n> > * Neutron LBaaS. we want to schedule 2 sessions. I am assuming that we\n> > want to go over status and also the whole incubator thingy and how we\n> > will best move forward. \n> > \n> > \n> > * Octavia: We want to schedule 2 sessions. \n> > ---  During one of the sessions I would like to discuss the pros and\n> > cons of putting Octavia into the Neutron LBaaS incubator project right\n> > away. If it is going to be the reference implementation for LBaaS v 2\n> > then I believe Octavia belong in Neutron LBaaS v2 incubator. \n> > \n> > \n> > * Flavors which should be coordinated with markmcclain and\n> > enikanorov. \n> > --- https://review.openstack.org/#/c/102723/\n> > \n> > \n> > Is this too many sessions given the constraints? I am assuming that we\n> > can also meet at the pods like we did at the last summit. \n> > \n> > \n> > thoughts?\n> > \n> > \n> > Regards Susanne\n> > \n> > Thierry\n> > Carrez <thierry at openstack.org>\n> > Aug 27 (1 day\n> > ago)\n> > \n> > \n> > \n> > \n> > to OpenStack\n> > \n> > \n> > \n> > \n> > \n> > Hi everyone,\n> > \n> > I\'ve been thinking about what changes we can bring to\n> > the Design Summit\n> > format to make it more productive. I\'ve heard the feedback from the\n> > mid-cycle meetups and would like to apply some of those ideas for\n> > Paris,\n> > within the constraints we have (already booked space and time). Here\n> > is\n> > something we could do:\n> > \n> > Day 1. Cross-project sessions / incubated projects / other projects\n> > \n> > I think that worked well last time. 3 parallel rooms where we can\n> > address top cross-project questions, discuss the results of the\n> > various\n> > experiments we conducted during juno. Don\'t hesitate to schedule 2\n> > slots\n> > for discussions, so that we have time to come to the bottom of those\n> > issues. Incubated projects (and maybe \"other\" projects, if space\n> > allows)\n> > occupy the remaining space on day 1, and could occupy \"pods\" on the\n> > other days.\n> > \n> > Day 2 and Day 3. Scheduled sessions for various programs\n> > \n> > That\'s our traditional scheduled space. We\'ll have a 33% less slots\n> > available. So, rather than trying to cover all the scope, the idea\n> > would\n> > be to focus those sessions on specific issues which really require\n> > face-to-face discussion (which can\'t be solved on the ML or using spec\n> > discussion) *or* require a lot of user feedback. That way, appearing\n> > in\n> > the general schedule is very helpful. This will require us to be a lot\n> > stricter on what we accept there and what we don\'t -- we won\'t have\n> > space for courtesy sessions anymore, and traditional/unnecessary\n> > sessions (like my traditional \"release schedule\" one) should just move\n> > to the mailing-list.\n> > \n> > Day 4. Contributors meetups\n> > \n> > On the last day, we could try to split the space so that we can\n> > conduct\n> > parallel midcycle-meetup-like contributors gatherings, with no time\n> > boundaries and an open agenda. Large projects could get a full day,\n> > smaller projects would get half a day (but could continue the\n> > discussion\n> > in a local bar). Ideally that meetup would end with some alignment on\n> > release goals, but the idea is to make the best of that time together\n> > to\n> > solve the issues you have. Friday would finish with the design summit\n> > feedback session, for those who are still around.\n> > \n> > \n> > I think this proposal makes the best use of our setup: discuss clear\n> > cross-project issues, address key specific topics which need\n> > face-to-face time and broader attendance, then try to replicate the\n> > success of midcycle meetup-like open unscheduled time to discuss\n> > whatever is hot at this point.\n> > \n> > There are still details to work out (is it possible split the space,\n> > should we use the usual design summit CFP website to organize the\n> > \"scheduled\" time...), but I would first like to have your feedback on\n> > this format. Also if you have alternative proposals that would make a\n> > better use of our 4 days, let me know.\n> > \n> > Cheers,\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1409287626.4357.24.camel@localhost>',NULL),('<1409288070.4357.30.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 04:54:30',0,'2014-08-29 04:54:30',NULL,'[openstack-dev]  [Octavia] Migration review update','Updated the migration review:\nhttps://review.openstack.org/#/c/114671/3\n\nAdded the active_node and spare_node table.  Not sure if this is what\npeople had in mind for this, but we do need a table to map load balancer\nto VMs/nodes/devices, so I figured an active_node table would be\nappropriate for that.  Please comment on what needs changed if I have\nthe wrong idea.\n\nThanks,\nBrandon\n\n','<1409285921.4357.5.camel@localhost>',NULL),('<1409316376.3358.2.camel@graham-work-laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 12:46:17',0,'2014-08-29 12:46:17',NULL,'[openstack-dev] [all] Design Summit reloaded','\n\nOn Fri, 2014-08-29 at 11:23 +0200, Thierry Carrez wrote:\n> Anne Gentle wrote:\n> > On Wed, Aug 27, 2014 at 7:51 AM, Thierry Carrez <thierry at openstack.org\n> > <mailto:thierry at openstack.org>> wrote:\n> > \n> >     Hi everyone,\n> > \n> >     I\'ve been thinking about what changes we can bring to the Design Summit\n> >     format to make it more productive. I\'ve heard the feedback from the\n> >     mid-cycle meetups and would like to apply some of those ideas for Paris,\n> >     within the constraints we have (already booked space and time). Here is\n> >     something we could do:\n> > \n> >     Day 1. Cross-project sessions / incubated projects / other projects\n> > \n> >     I think that worked well last time. 3 parallel rooms where we can\n> >     address top cross-project questions, discuss the results of the various\n> >     experiments we conducted during juno. Don\'t hesitate to schedule 2 slots\n> >     for discussions, so that we have time to come to the bottom of those\n> >     issues. Incubated projects (and maybe \"other\" projects, if space allows)\n> >     occupy the remaining space on day 1, and could occupy \"pods\" on the\n> >     other days.\n> > \n> > Yep, I think this works in theory, the tough part will be when all the\n> > incubating projects realize they\'re sending people for a single day?\n> > Maybe it\'ll work out differently than I think though. It means fitting\n> > ironic, barbican, designate, manila, marconi in a day? \n> \n> Actually those projects would get pod space for the rest of the week, so\n> they should stay! Also some of them might have graduated by then :)\n\nWould the programs for those projects not get design summit time? I\nthought the Programs got Design summit time, not projects... If not, can\nthe Programs get design summit time? \n\n> \n> > Also since QA, Infra, and Docs are cross-project AND Programs, where do\n> > they land?\n> \n> I think those teams work on different issues. Some issues require a lot\n> of communication and input because they are cross-project problems that\n> those teams are tasked with solving -- in which case that belongs to the\n> cross-project day. Other issues are more implementation details and\n> require mostly the team members but not so much external input -- those\n> belong to the specific slots or the \"contributors meetup\". Obviously\n> some things will be a bit borderline and we\'ll have to pick one or the\n> other based on available slots.\n> \n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/3bb457b1/attachment.pgp>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/x-pkcs7-signature\nSize: 6961 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/3bb457b1/attachment.bin>\n\n','<5400469D.9000500@openstack.org>',NULL),('<1409354007-sup-5328@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-29 16:16:08',-25200,'2014-08-29 23:16:08',NULL,'[openstack-dev] [TripleO] Heat AWS WaitCondition\'s count','There are still a few lingering wait conditions. They should probably be\ncleaned up from tripleo-heat-templates.\n\nExcerpts from Pavlo Shchelokovskyy\'s message of 2014-08-28 02:26:16 -0700:\n> Hi all,\n> \n> the AWS::CloudFormation::WaitCondition resource in Heat allows to update\n> the \'count\' property, although in real AWS this is prohibited (\n> https://bugs.launchpad.net/heat/+bug/1340100).\n> \n> My question is does TripleO still depends on this behavior of AWS\n> WaitCondition in any way? I want to be sure that fixing the mentioned bug\n> will not break TripleO.\n> \n> Best regards,\n> Pavlo Shchelokovskyy.\n\n\n','<CACfB1usmiGLZsXKNLv20WhFYNMRZGOB-MChOA1hEpKoPKLUqLw@mail.gmail.com>',NULL),('<1409414896.16608.113.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-30 17:08:16',3600,'2014-08-30 16:08:16',NULL,'[openstack-dev] [nova] libvirt version_cap, a postmortem','\nHey\n\nThe libvirt version_cap debacle continues to come up in conversation and\none perception of the whole thing appears to be:\n\n  A controversial patch was \"ninjaed\" by three Red Hat nova-cores and \n  then the same individuals piled on with -2s when a revert was proposed\n  to allow further discussion.\n\nI hope it\'s clear to everyone why that\'s a pretty painful thing to hear.\nHowever, I do see that I didn\'t behave perfectly here. I apologize for\nthat.\n\nIn order to understand where this perception came from, I\'ve gone back\nover the discussions spread across gerrit and the mailing list in order\nto piece together a precise timeline. I\'ve appended that below.\n\nSome conclusions I draw from that tedious exercise:\n\n - Some people came at this from the perspective that we already have \n   a firm, unwritten policy that all code must have functional written \n   tests. Others see that \"test all the things\" is interpreted as a\n   worthy aspiration, but is only one of a number of nuanced factors\n   that needs to be taken into account when considering the addition of\n   a new feature.\n\n   i.e. the former camp saw Dan Smith\'s devref addition as attempting \n   to document an existing policy (perhaps even a more forgiving \n   version of an existing policy), whereas other see it as a dramatic \n   shift to a draconian implementation of \"test all the things\".\n\n - Dan Berrange, Russell and I didn\'t feel like we were \"ninjaing a\n   controversial patch\" - you can see our perspective expressed in \n   multiple places. The patch would have helped the \"live snapshot\" \n   issue, and has other useful applications. It does not affect the \n   broader testing debate.\n\n   Johannes was a solitary voice expressing concerns with the patch, \n   and you could see that Dan was particularly engaged in trying to \n   address those concerns and repeating his feeling that the patch was \n   orthogonal to the testing debate.\n\n   That all being said - the patch did merge too quickly.\n\n - What exacerbates the situation - particularly when people attempt to \n   look back at what happened - is how spread out our conversations \n   are. You look at the version_cap review and don\'t see any of the \n   related discussions on the devref policy review nor the mailing list \n   threads. Our disjoint methods of communicating contribute to \n   misunderstandings.\n\n - When it came to the revert, a couple of things resulted in \n   misunderstandings, hurt feelings and frayed tempers - (a) that our \n   \"retrospective veto revert policy\" wasn\'t well understood and (b) \n   a feeling that there was private, in-person grumbling about us at \n   the mid-cycle while we were absent, with no attempt to talk to us \n   directly.\n\n\nTo take an even further step back - successful communities like ours\nrequire a huge amount of trust between the participants. Trust requires\ncommunication and empathy. If communication breaks down and the pressure\nwe\'re all under erodes our empathy for each others\' positions, then\nsituations can easily get horribly out of control.\n\nThis isn\'t a pleasant situation and we should all strive for better.\nHowever, I tend to measure our \"flamewars\" against this:\n\n  https://mail.gnome.org/archives/gnome-2-0-list/2001-June/msg00132.html\n\nGNOME in June 2001 was my introduction to full-time open-source\ndevelopment, so this episode sticks out in my mind. The two individuals\nin that email were/are immensely capable and reasonable people, yet ...\n\nSo far, we\'re doing pretty okay compared to that and many other\nopen-source flamewars. Let\'s make sure we continue that way by avoiding\nletting situations fester.\n\n\nThanks, and sorry for being a windbag,\nMark.\n\n---\n\n= July 1 =\n\nThe starting point is this review:\n\n   https://review.openstack.org/103923\n\nDan Smith proposes a policy that the libvirt driver may not use libvirt\nfeatures until they have been available in Ubuntu or Fedora for at least\n30 days.\n\nThe commit message mentions:\n\n  \"broken us in the past when we add a new feature that requires a newer\n   libvirt than we test with, and we discover that it\'s totally broken\n   when we upgrade in the gate.\"\n\nwhich AIUI is a reference to the libvirt \"live snapshot\" issue the\nprevious week, which is described here:\n\n  https://review.openstack.org/102643\n\nwhere upgrading to Ubuntu Trusty meant the libvirt version in use in the\ngate went from 0.9.8 to 1.2.2, which caused the \"live snapshot\" code\npaths in Nova for the first time, which appeared to be related to some\nserious gate instability (although the exact root cause wasn\'t\nidentified).\n\nSome background on the libvirt version upgrade can be seen here:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-March/thread.html#30284\n\n= July 1 - July 8 =\n\nBack and forth debate mostly between Dan Smith and Dan Berrange. Sean\nvotes +2, Dan Berrange votes -2.\n\n= July 14 =\n\nRussell adds his support to Dan Berrange\'s position, votes -2. Some\ndebate between Dan and Dan continues. Joe Gordon votes +2. Matt\nRiedemann expresses support-in-principal for Dan Smith\'s approach.\n\n= July 15 =\n\nDebate continues ...\n\n16:12 - I -2 the patch and attempt to take a step back and think about\nhow we could have prevented (or at least mitigated against) the \"live\nsnapshot\" issue and suggest the idea of adding a new configuration\noption:\n\n  [libvirt]\n  version_cap = 1.2.2\n\nwhich would mean we would not automatically start using new libvirt\nfeatures in the gate because of a libvirt version upgrade, but instead\nthe new features would only begin to be used when we merge a change to\nthe default value of version_cap.\n\n16:31 - I leave a separate comment addressing the broader debate about\nour functional test coverage requirements.\n\n16:46 - Dan Berrange likes the version_cap idea\n\n15:37 - Dan Berrange posts an implementation of version_cap:\n\n  https://review.openstack.org/107119\n\nand links to it from in Dan Smith\'s libvirt testing policy review (#103923)\n\n21:49 - Matt expresses some support for the config option, but worries\nabout the precedent being set.\n\n23:14 - Dan Berrange explains his point of view that a \"test all the\nthings\" rule must mean \"test all the things which can be practically\ntested by our current CI system\".\n\n= July 16 =\n\n08:04 - I +2 the version_cap patch after Dan fixes up some issues I\npointed out.\n\n13:44 - 14:28 - Sean and John Garbutt add further thoughts to the\nlibvirt testing policy review without making any comment on the\nversion_cap idea. Sean takes the debate to the mailing list:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-July/040421.html\n\nDebate continues in the thread, largely around the mechanics of how to\nallow a newer version of libvirt be used in the gate.\n\n15:08 - I mention the version_cap proposal on the thread for the first\ntime:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-July/040436.html\n\nand the point I make is the configuration option makes it easier for\noperators to run only code paths that are tested by the gate.\n\n16:44 - Johannes notes that multiple issues with code paths not tested\nin the gate may need to be fixed as part of a future review to increase\nthe default value of version_cap.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040456.html\n\n18:50 - Russell approves the version_cap patch.\n\nhttps://review.openstack.org/107119\n\n= July 17 =\n\n05:38 - The version_cap patch merges.\n\n13:09 - Somewhat related, Dan Berrange and I explain we won\'t be at the\nmid-cycle issue for any test policy discussions. Sean makes a point that\nthe discussion is best had on email/IRC where there is a permanent\nrecord.\n\n14:33 - Johannes expresses concern in gerrit that version_cap got merged\ntoo quickly.\n\nhttps://review.openstack.org/107119\n\n15:17 - Dan Berrange responds to Johannes in gerrit, saying that he\nthinks version_cap is useful irrespective of the broader testing\ndiscussion.\n\n15:28 - Johannes disagrees, asks for a response to his concerns on the\nmailing list.\n\n15:40 - Dan Berrange responds on the mailing list to Johannes\nversion_cap concerns.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040576.html\n\n18:15 - Russell also responds to Johannes.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040597.html\n\n18:31 - Johannes responds to Dan.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040602.html\n\n18:39 - Russell responds to Johannes again.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040604.html\n\n19:13 - Johannes responds again.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040608.html\n\n= July 18 =\n\n07:55 - Dan Berrange responds to Johannes again.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040647.html\n\n09:37 - Sean notices version_cap, thinks it\'s \"interesting\", wonders do\nwe need similar for qemu versions.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-July/040533.html\n\n= July 28 - 30 =\n\nThe Nova mid-cycle meetup in Portland. Neither, Dan, Russell nor I are\npresent, for various personal reasons.\n\nAIUI, a brief \"hallway track\" conversation lead to briefly discussing\nthe version_cap patch in the main sessions which went along the lines of\n\"does anyone find it concerning how this patch was merged\" and the\ngeneral consensus was \"yes, it is concerning\".\n\n= July 30 =\n\nSean Dague proposes a revert of the patch because a) \"it\'s a policy\nchange\" and b) it requires further discussion.\n\nhttps://review.openstack.org/110754\n\n= Aug 7 =\n\nRussell -2s the revert.\n\nMatt raises the topic of the revert on the mailing list.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042284.html\n\nDan Smith, Joe Gordon +2s the revert.\n\n= Aug 8 =\n\nMichael Still, Jay Pipes +2s the revert.\n\nRussell starts experimenting with a gate job to test with latest\nlibvirt.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042470.html\n\n= Aug 11 =\n\nDan Berrange and I return from our (separate :) vacations and -2 the\nrevert.\n\nI describe the revert as a \"proxy battle\", avoiding the real debate\naround testing requirements.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042546.html\n\nJoe tries to capture the concerns about how the version_cap patch was\noriginally merged.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042653.html\n\n= Aug 12 =\n\nI explicitly attempt to address any notion there is a \"corporate agenda\"\nat play here.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042691.html\n\nDan again tries to explain why he thinks version_cap is orthogonal to\nthe broader debate.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042707.html\n\nMichael Still - with Thierry cc-ed - privately emails me, Russell and\nDan Berrange asking us to remove our -2s so that we can have a \"more\ncomplete discussion\". All three of us initially refuse and a bunch of\nhurt feelings are frankly expressed on all sides, with one theme being\nthe perception that this had gotten out of control because we weren\'t at\nthe mid-cycle.\n\nThierry calmed things down be patiently expressing Michael\'s perspective\nthat there is a process to be followed where patches that get merged\nquickly are later seen to be controversial. The red mist begins to\nclear. I propose that we document this \"retrospective veto revert\"\nprocedure to head off any future misunderstanding.\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-August/042728.html\n\nAll three of us remove our -2s. The patch gets reverted.\n\n= Aug 14 =\n\nDan Berrange re-proposes the patch, later changing the default\nversion_cap value.\n\nhttps://review.openstack.org/114307\n\nThe patch has seen very little discussion since then and is still\npending review.\n\n\n\n\n',NULL,NULL),('<1409415811881.41945@tataelxsi.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-30 16:23:29',0,'2014-08-30 16:23:29',NULL,'[Openstack] [nova] Issues while spawning vm','Hi,\n\n\nI am trying to spawn a VM using the cirros image and inject the network information into the VM while spawing. However, I am getting the following warnings/errors.\n\n\nException AttributeError: \"GuestFS instance has no attribute \'_o\'\" in <bound method GuestFS.__del__ of <guestfs.GuestFS instance at 0x43ed6c8>> ignored?\n\n\nIgnoring error injecting net into image (aug_get: no matching node)\n\n\nHow do I resolve this issue and be able to inject the network information into the VM??\n\n\nRegards,\nSanjivini Naikar\n?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140830/25d18ab5/attachment.html>\n\n','<1409415650855.63454@tataelxsi.co.in>',NULL),('<1409606467.2680.7.camel@graham-HP-Z620>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-01 21:21:07',0,'2014-09-01 21:21:07',NULL,'[openstack-dev] [all] Design Summit reloaded','On Fri, 2014-08-29 at 17:56 +0200, Thierry Carrez wrote:\n> Hayes, Graham wrote:\n> >>> Yep, I think this works in theory, the tough part will be when all the\n> >>> incubating projects realize they\'re sending people for a single day?\n> >>> Maybe it\'ll work out differently than I think though. It means fitting\n> >>> ironic, barbican, designate, manila, marconi in a day? \n> >>\n> >> Actually those projects would get pod space for the rest of the week, so\n> >> they should stay! Also some of them might have graduated by then :)\n> > \n> > Would the programs for those projects not get design summit time? I\n> > thought the Programs got Design summit time, not projects... If not, can\n> > the Programs get design summit time? \n> \n> Sure, that\'s what Anne probably meant. Time for the program behind every\n> incubated project.\n> \n\nSure,\n\nI was referring to the the 2 main days - (days 2 and 3)\n\nI thought that was a benefit of having a Program? The PTL chooses the\nsessions, and the PTL is over a program, so I assumed that programs\nwould get both Pods and some design summit time (not 1/2 a day on the\nTuesday)\n\nI know we (designate) got some great work done last year, but most of it\nwas in isolation, as we had one 40 min session, and one 1/2 day session,\nbut the rest of the sessions were unofficial ones, which meant that\npeople in the community who were not as engaged missed out on the\ndiscussions.\n\nWould there be space for programs with incubated projects at the\n\'Contributors meetups\' ?\n\nThanks, \n\n--\nGraham\n\n\n','<5400A2CA.8030102@openstack.org>',NULL),('<1409634756.6357.21.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 05:12:36',0,'2014-09-02 05:12:36',NULL,'[openstack-dev] [neutron][lbaas][octavia]','Hi Susanne and everyone,\n\nMy opinions are that keeping it in stackforge until it gets mature is\nthe best solution.  I\'m pretty sure we can all agree on that.  Whenever\nit is mature then, and only then, we should try to get it into openstack\none way or another.  If Neutron LBaaS v2 is still incubated then it\nshould be relatively easy to get it in that codebase.  If Neutron LBaaS\nhas already spun out, even easier for us.  If we want Octavia to just\nbecome an openstack project all its own then that will be the difficult\npart.\n\nI think the best course of action is to get Octavia itself into the same\ncodebase as LBaaS (Neutron or spun out).  They do go together, and the\nmaintainers will almost always be the same for both.  This makes even\nmore sense when LBaaS is spun out into its own project.\n\nI really think all of the answers to these questions will fall into\nplace when we actually deliver a product that we are all wanting and\ntalking about delivering with Octavia.  Once we prove that we can all\ncome together as a community and manage a product from inception to\nmaturity, we will then have the respect and trust to do what is best for\nan Openstack LBaaS product.\n\nThanks,\nBrandon\n\nOn Mon, 2014-09-01 at 10:18 -0400, Susanne Balle wrote:\n> Kyle, Adam,\n> \n>  \n> \n> Based on this thread Kyle is suggesting the follow moving forward\n> plan: \n> \n>  \n> \n> 1) We incubate Neutron LBaaS V2 in the ?Neutron? incubator ?and freeze\n> LBaas V1.0?\n> 2) ?Eventually? It graduates into a project under the networking\n> program.\n> 3) ?At that point? We deprecate Neutron LBaaS v1.\n> \n>  \n> \n> The words in ?xx? are works I added to make sure I/We understand the\n> whole picture.\n> \n>  \n> \n> And as Adam mentions: Octavia != LBaaS-v2. Octavia is a peer to F5 /\n> Radware / A10 / etc appliances which is a definition I agree with BTW.\n> \n>  \n> \n> What I am trying to now understand is how we will move Octavia into\n> the new LBaaS project? \n> \n>  \n> \n> If we do it later rather than develop Octavia in tree under the new\n> incubated LBaaS project when do we plan to bring it in-tree from\n> Stackforge? Kilo? Later? When LBaaS is a separate project under the\n> Networking program?\n\n>  \n> \n> What are the criteria to bring a driver into the LBaaS project and\n> what do we need to do to replace the existing reference driver? Maybe\n> adding a software driver to LBaaS source tree is less of a problem\n> than converting a whole project to an OpenStack project.\n\n>  \n> \n> Again I am open to both directions I just want to make sure we\n> understand why we are choosing to do one or the other and that our\n>  decision is based on data and not emotions. \n> \n>  \n> \n> I am assuming that keeping Octavia in Stackforge will increase the\n> velocity of the project and allow us more freedom which is goodness.\n> We just need to have a plan to make it part of the Openstack LBaaS\n> project.\n> \n>  \n> \n> Regards Susanne\n> \n> \n> \n> \n> On Sat, Aug 30, 2014 at 2:09 PM, Adam Harwell\n> <adam.harwell at rackspace.com> wrote:\n>         Only really have comments on two of your related points:\n>         \n>         \n>         [Susanne] To me Octavia is a driver so it is very hard to me\n>         to think of it as a standalone project. It needs the new\n>         Neutron LBaaS v2 to function which is why I think of them\n>         together. This of course can change since we can add whatever\n>         layers we want to Octavia.\n>         \n>         \n>         [Adam] I guess I\'ve always shared Stephen\'s\n>         viewpoint ? Octavia != LBaaS-v2. Octavia is a peer to F5 /\n>         Radware / A10 / etcappliances, not to an Openstack API layer\n>         like Neutron-LBaaS. It\'s a little tricky to clearly define\n>         this difference in conversation, and I have noticed that quite\n>         a few people are having the same issue differentiating. In a\n>         small group, having quite a few people not on the same page is\n>         a bit scary, so maybe we need to really sit down and map this\n>         out so everyone is together one way or the other.\n>         \n>         \n>         [Susanne] Ok now I am confused? But I agree with you that it\n>         need to focus on our use cases. I remember us discussing\n>         Octavia being the refenece implementation for OpenStack LBaaS\n>         (whatever that is). Has that changed while I was on vacation?\n>         \n>         \n>         [Adam] I believe that having the Octavia \"driver\" (not the\n>         Octavia codebase itself, technically) become the reference\n>         implementation for Neutron-LBaaS is still the plan in my eyes.\n>         The Octavia Driver in Neutron-LBaaS is a separate bit of code\n>         from the actual Octavia project, similar to the way the A10\n>         driver is a separate bit of code from the A10 appliance. To do\n>         that though, we need Octavia to be fairly close to fully\n>         functional. I believe we can do this because even though the\n>         reference driver would then require an additional service to\n>         run, what it requires is still fully-open-source and (by way\n>         of our plan) available as part of OpenStack core.\n>         \n>         \n>         --Adam\n>         \n>         \n>         https://keybase.io/rm_you\n>         \n>         \n>         \n>         \n>         From: Susanne Balle <sleipnir012 at gmail.com>\n>         Reply-To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         Date: Friday, August 29, 2014 9:19 AM\n>         To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         \n>         Subject: Re: [openstack-dev] [neutron][lbaas][octavia]\n>         \n>         \n>         \n>                 Stephen\n>                 \n>                  \n>                 \n>                 See inline comments.\n>                 \n>                  \n>                 \n>                 Susanne\n>                 \n>                  \n>                 \n>                 -----------------------------------------\n>                 \n>                  \n>                 \n>                 Susanne--\n>                 \n>                  \n>                 \n>                 I think you are conflating the difference between\n>                 \"OpenStack incubation\" and \"Neutron incubator.\" These\n>                 are two very different matters and should be treated\n>                 separately. So, addressing each one individually:\n>                 \n>                  \n>                 \n>                 \"OpenStack Incubation\"\n>                 \n>                 I think this has been the end-goal of Octavia all\n>                 along and continues to be the end-goal. Under this\n>                 scenario, Octavia is its own stand-alone project with\n>                 its own PTL and core developer team, its own\n>                 governance, and should eventually become part of the\n>                 integrated OpenStack release. No project ever starts\n>                 out as \"OpenStack incubated.\"\n>                 \n>                  \n>                 \n>                 [Susanne] I totally agree that the end goal is for\n>                 Neutron LBaaS to become its own incubated project. I\n>                 did miss the nuance that was pointed out by Mestery in\n>                 an earlier email that if a Neutron incubator project\n>                 wants to become a separate project it will have to\n>                 apply for incubation again or at that time. It was my\n>                 understanding that such a Neutron incubated project\n>                 would be grandfathered in but again we do not have\n>                 much details on the process yet.\n>                 \n>                  \n>                 \n>                 To me Octavia is a driver so it is very hard to me to\n>                 think of it as a standalone project. It needs the new\n>                 Neutron LBaaS v2 to function which is why I think of\n>                 them together. This of course can change since we can\n>                 add whatever layers we want to Octavia.\n>                 \n>                  \n>                 \n>                 \"Neutron Incubator\"\n>                 \n>                 This has only become a serious discussion in the last\n>                 few weeks and has yet to land, so there are many\n>                 assumptions about this which don\'t pan out (either\n>                 because of purposeful design and governance decisions,\n>                 or because of how this project actually ends up being\n>                 implemented from a practical standpoint). But given\n>                 the inherent limitations about making statements with\n>                 so many unknowns, the following seem fairly clear from\n>                 what has been shared so far:\n>                 \n>                 ? Neutron incubator is the on-ramp for projects which\n>                 should eventually become a part of Neutron itself.\n>                 \n>                 ? Projects which enter the Neutron incubator on-ramp\n>                 should be fairly close to maturity in their final\n>                 form. I think the intent here is for them to live in\n>                 incubator for 1 or 2 cycles before either being merged\n>                 into Neutron core, or being ejected (as abandoned, or\n>                 as a separate project).\n>                 \n>                 ? Neutron incubator projects effectively do not have\n>                 their own PTL and core developer team, and do not have\n>                 their own governance.\n>                 \n>                 [Susanne] Ok I missed the last point. In an earlier\n>                 discussion Mestery implied that an incubated project\n>                 would have at least one or two of its own cores. Maybe\n>                 that changed between now and then.\n>                 \n>                 In addition we know the following about Neutron LBaaS\n>                 and Octavia:\n>                 \n>                 ? It\'s already (informally?) agreed that the ultimate\n>                 long-term place for a LBaaS solution is probably to be\n>                 spun out into its own project, which might\n>                 appropriately live under a yet-to-be-defined master\n>                 \"Networking\" project. (This would make Neutron, LBaaS,\n>                 VPNaaS, FWaaS, etc. effective \"peer\" projects under\n>                 the Networking umbrella.)  Since this \"Networking\"\n>                 umbrella project has even less defined about it than\n>                 Neutron incubator, it\'s impossible to know whether\n>                 being a part of Neutron incubator would be of any\n>                 benefit to Octavia (or, conversely, to Neutron\n>                 incubator) at all as an on-ramp to becoming part of\n>                 \"Networking.\" Presumably, Octavia might fit well under\n>                 the \"Networking\" umbrella-- but, again, with nothing\n>                 defined there it\'s impossible to draw any reasonable\n>                 conclusions at this time.\n>                 \n>                 [Susanne] We are in agreement here. This was the\n>                 reasons we had the ad-hoc meeting in Atlanta so get a\n>                 feel for hw people felt if we made Neutron LBaaS its\n>                 own project and also how we got an operator large\n>                 scale LBaaS that fit most of our service provider\n>                 requirements. I am just worried because you keep on\n>                 talking of Octavia as a standaloe project. To me it is\n>                 an extension of Neutron LBaaS or of a new LBaaS ?. I\n>                 do not see us (== me) use Octavia in a non OpenStack\n>                 context. And yes it is a driver that I am hoping we\n>                 all expect to become the reference implementation for\n>                 LBaaS.\n>                 \n>                 ? When the LBaaS component spins out of Neutron, it\n>                 will more than likely not be Octavia.  Octavia\n>                 is intentionally less friendly to 3rd party load\n>                 balancer vendors both because it\'s envisioned that\n>                 Octavia would just be another implementation which\n>                 lives along-side said 3rd party vendor products\n>                 (plugging into a higher level LBaaS layer via a\n>                 driver), and because we don\'t want to have to\n>                 compromise certain design features of Octavia to meet\n>                 the lowest common denominator 3rd party vendor\n>                 product. (3rd party vendors are welcome, but we will\n>                 not make design compromises to meet the needs of a\n>                 proprietary product-- compatibility with available\n>                 open-source products and standards trumps this.)\n>                 \n>                 [Susanne] Ok now I am confused? But I agree with you\n>                 that it need to focus on our use cases. I remember us\n>                 discussing Octavia being the refenece implementation\n>                 for OpenStack LBaaS (whatever that is). Has that\n>                 changed while I was on vacation?\n>                 \n>                 The end-game for the above point is: In the future I\n>                 see \"Openstack LBaaS\" (or whatever the project calls\n>                 itself) being a separate but complimentary project to\n>                 Octavia.\n>                 \n>                 ? While its true that we would like Octavia to become\n>                 the reference implementation for Neutron LBaaS, we are\n>                 nowhere near being able to deliver on that. Attempting\n>                 to become a part of Neutron LBaaS right now is likely\n>                 just to create frustration (and very little merged\n>                 code) for both the Octavia and Neutron teams.\n>                 \n>                 [Susanne] Agreed.\n>                 \n>                 So given that the only code in Octavia right now are a\n>                 few database migrations, we are very, very far away\n>                 from being ready for either OpenStack incubation or\n>                 the Neutron incubator project. I don\'t think it\'s very\n>                 useful to be spending time right now worrying about\n>                 either of these outcomes:  We should be working on\n>                 Octavia!\n>                 \n>                 [Susanne] Agreed. You suggested we discuss this on the\n>                 ML NOW. I wanted to wait until the summit given that\n>                 we would have more info on Neutron incubation, etc. I\n>                 haven?t seen much written down on the Neutron\n>                 incubator project so most of what we are doing is\n>                 guessing?.\n>                 \n>                 Please also understand:  I realize that probably the\n>                 reason you\'re asking this right now is because you\n>                 have a mandate within your organization to use only\n>                 \"official\" OpenStack branded components, and if\n>                 Octavia doesn\'t fall within that category, you won\'t\n>                 be able to use it.  Of course everyone working on this\n>                 project wants to make that happen too, so we\'re doing\n>                 everything we can to make sure we don\'t jeopardize\n>                 that possibility. And there are enough voices in this\n>                 project that want that to happen, so I think if we\n>                 strayed from the path to get there, there would be\n>                 sufficient clangor over this that it would be hard to\n>                 miss. But I don\'t think there\'s anyone at all at this\n>                 time that can honestly give you a promise that Octavia\n>                 definitely will be incubated and will definitely end\n>                 up in the integrated OpenStack release.\n>                 \n>                  \n>                 \n>                 If you want to increase the chances of that happening,\n>                 please help push the project forward!\n>                 \n>                  \n>                 \n>                 [Susanne] That is what HP is doing. Remember we were\n>                 here from the beginning helping change the direction\n>                 for LBaaS.\n>                 \n>                  \n>                 \n>                 Thanks,\n>                 \n>                 Stephen\n>                 \n>                  \n>                 \n>                 \n>                 \n>                 \n>                 On Thu, Aug 28, 2014 at 9:52 PM, Stephen Balukoff\n>                 <sbalukoff at bluebox.net> wrote:\n>                         Susanne-- \n>                         \n>                         \n>                         I think you are conflating the difference\n>                         between \"OpenStack incubation\" and \"Neutron\n>                         incubator.\" These are two very different\n>                         matters and should be treated separately. So,\n>                         addressing each one individually:\n>                         \n>                         \n>                         \"OpenStack Incubation\"\n>                         I think this has been the end-goal of Octavia\n>                         all along and continues to be the end-goal.\n>                         Under this scenario, Octavia is its own\n>                         stand-alone project with its own PTL and core\n>                         developer team, its own governance, and should\n>                         eventually become part of the integrated\n>                         OpenStack release. No project ever starts out\n>                         as \"OpenStack incubated.\"\n>                         \n>                         \n>                         \"Neutron Incubator\"\n>                         This has only become a serious discussion in\n>                         the last few weeks and has yet to land, so\n>                         there are many assumptions about this which\n>                         don\'t pan out (either because of purposeful\n>                         design and governance decisions, or because of\n>                         how this project actually ends up being\n>                         implemented from a practical standpoint). But\n>                         given the inherent limitations about making\n>                         statements with so many unknowns, the\n>                         following seem fairly clear from what has been\n>                         shared so far:\n>                               * Neutron incubator is the on-ramp for\n>                                 projects which should eventually\n>                                 become a part of Neutron itself.\n>                               * Projects which enter the Neutron\n>                                 incubator on-ramp should be fairly\n>                                 close to maturity in their final form.\n>                                 I think the intent here is for them to\n>                                 live in incubator for 1 or 2 cycles\n>                                 before either being merged into\n>                                 Neutron core, or being ejected (as\n>                                 abandoned, or as a separate project). \n>                               * Neutron incubator projects effectively\n>                                 do not have their own PTL and core\n>                                 developer team, and do not have their\n>                                 own governance.\n>                         In addition we know the following about\n>                         Neutron LBaaS and Octavia:\n>                               * It\'s already (informally?) agreed that\n>                                 the ultimate long-term place for a\n>                                 LBaaS solution is probably to be spun\n>                                 out into its own project, which might\n>                                 appropriately live under a\n>                                 yet-to-be-defined master \"Networking\"\n>                                 project. (This would make Neutron,\n>                                 LBaaS, VPNaaS, FWaaS, etc. effective\n>                                 \"peer\" projects under the Networking\n>                                 umbrella.)  Since this \"Networking\"\n>                                 umbrella project has even less defined\n>                                 about it than Neutron incubator, it\'s\n>                                 impossible to know whether being a\n>                                 part of Neutron incubator would be of\n>                                 any benefit to Octavia (or,\n>                                 conversely, to Neutron incubator) at\n>                                 all as an on-ramp to becoming part of\n>                                 \"Networking.\" Presumably, Octavia\n>                                 might fit well under the \"Networking\"\n>                                 umbrella-- but, again, with nothing\n>                                 defined there it\'s impossible to draw\n>                                 any reasonable conclusions at this\n>                                 time.\n>                               * When the LBaaS component spins out of\n>                                 Neutron, it will more than likely not\n>                                 be Octavia.  Octavia is intentionally\n>                                 less friendly to 3rd party load\n>                                 balancer vendors both because it\'s\n>                                 envisioned that Octavia would just be\n>                                 another implementation which lives\n>                                 along-side said 3rd party vendor\n>                                 products (plugging into a higher level\n>                                 LBaaS layer via a driver), and because\n>                                 we don\'t want to have to compromise\n>                                 certain design features of Octavia to\n>                                 meet the lowest common denominator 3rd\n>                                 party vendor product. (3rd party\n>                                 vendors are welcome, but we will not\n>                                 make design compromises to meet the\n>                                 needs of a proprietary product--\n>                                 compatibility with available\n>                                 open-source products and standards\n>                                 trumps this.) \n>                               * The end-game for the above point is:\n>                                 In the future I see \"Openstack\n>                                 LBaaS\" (or whatever the project calls\n>                                 itself) being a separate but\n>                                 complimentary project to Octavia.\n>                               * While its true that we would like\n>                                 Octavia to become the reference\n>                                 implementation for Neutron LBaaS, we\n>                                 are nowhere near being able to deliver\n>                                 on that. Attempting to become a part\n>                                 of Neutron LBaaS right now is likely\n>                                 just to create frustration (and very\n>                                 little merged code) for both the\n>                                 Octavia and Neutron teams. \n>                         \n>                         \n>                         \n>                         \n>                         So given that the only code in Octavia right\n>                         now are a few database migrations, we are\n>                         very, very far away from being ready for\n>                         either OpenStack incubation or the Neutron\n>                         incubator project. I don\'t think it\'s very\n>                         useful to be spending time right now worrying\n>                         about either of these outcomes:  We should be\n>                         working on Octavia!\n>                         \n>                         \n>                         Please also understand:  I realize that\n>                         probably the reason you\'re asking this right\n>                         now is because you have a mandate within your\n>                         organization to use only \"official\" OpenStack\n>                         branded components, and if Octavia doesn\'t\n>                         fall within that category, you won\'t be able\n>                         to use it.  Of course everyone working on this\n>                         project wants to make that happen too, so\n>                         we\'re doing everything we can to make sure we\n>                         don\'t jeopardize that possibility. And there\n>                         are enough voices in this project that want\n>                         that to happen, so I think if we strayed from\n>                         the path to get there, there would be\n>                         sufficient clangor over this that it would be\n>                         hard to miss. But I don\'t think there\'s anyone\n>                         at all at this time that can honestly give you\n>                         a promise that Octavia definitely will be\n>                         incubated and will definitely end up in the\n>                         integrated OpenStack release.\n>                         \n>                         \n>                         If you want to increase the chances of that\n>                         happening, please help push the project\n>                         forward!\n>                         \n>                         \n>                         Thanks,\n>                         Stephen\n>                         \n>                         \n>                         \n>                         \n>                         On Thu, Aug 28, 2014 at 2:57 PM, Susanne Balle\n>                         <sleipnir012 at gmail.com> wrote:\n>                         \n>                                  I would like to discuss the pros and\n>                                 cons of putting Octavia into the\n>                                 Neutron LBaaS incubator project right\n>                                 away. If it is going to be the\n>                                 reference implementation for LBaaS v 2\n>                                 then I believe Octavia belong in\n>                                 Neutron LBaaS v2 incubator. \n>                                 \n>                                 \n>                                 The Pros:\n>                                 * Octavia is in Openstack incubation\n>                                 right away along with the lbaas v2\n>                                 code. We do not have to apply for\n>                                 incubation later on. \n>                                 * As incubation project we have our\n>                                 own core and should be able ot commit\n>                                 our code\n>                                 * We are starting out as an OpenStack\n>                                 incubated project\n>                                 \n>                                 \n>                                 The Cons:\n>                                 * Not sure of the velocity of the\n>                                 project\n>                                 * Incubation not well defined.\n>                                 \n>                                 \n>                                 If Octavia starts as a standalone\n>                                 stackforge project we are assuming\n>                                 that it would be looked favorable on\n>                                 when time is to move it into incubated\n>                                 status.\n>                                 \n>                                 \n>                                 Susanne\n>                                 \n>                                 \n>                                 \n>                                 \n>                                 \n>                                 \n>                                 _______________________________________________\n>                                 OpenStack-dev mailing list\n>                                 OpenStack-dev at lists.openstack.org\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                                 \n>                                 \n>                         \n>                         \n>                         \n>                         \n>                         _______________________________________________\n>                         OpenStack-dev mailing list\n>                         OpenStack-dev at lists.openstack.org\n>                         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n\n','<CADBYD+yhdiCOVSW5LtSF4c4ux+b0ui2ektM3R-Sk3V1JxTJhGg@mail.gmail.com>',NULL),('<1409638616.6357.32.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 06:16:56',0,'2014-09-02 06:16:56',NULL,'[openstack-dev]  [Octavia] Blueprints','Added blueprints of tasks in progress and tasks to be done.\n\nhttps://blueprints.launchpad.net/octavia\n\nIf you are working on one of these and your name is not assigned please\nlet me know.  If you are able to assign yourself that\'d be even better\nbut I\'m not sure exactly who can do what.  Also, if you are working on\nsomething that is not listed here, also let me know or add it yourself.\n\nThere are more blueprints that need to be defined but hopefully this\ngives a good jumping off point for anyone who wants to contribute.  Some\nblueprints may end up not needing at all, some may only be needed for\ndiscussion, some may need to be split up into multiple blueprints.  The\npoint is to get these listed out and its easy to know what is being\nworked on.\n\nSo I propose we have a process in place from now on for work items:\n\n1) If you want to work on something, assign yourself (or talk to someone\nwho can assign) to an existing blueprint or create a new one\n(preferrably after everyone agrees its essential for 0.5).\n2) Discuss details with everyone about requirements, implementations,\netc.  You can also update the status of the blueprint to \"Discussion\" (I\ndon\'t know if we want to be strict about that or not, I personally don\'t\ncare).\n3) Change the description of the blueprint to a detailed description of\nwhat you plan to do.\n4) Change the status to \"Started\" (I think this should be mandatory)\n5) Do blueprint (in whatever form is necessary)\n6) Change status of blueprint appropriately\n\nThanks,\nBrandon\n\n','<1409288070.4357.30.camel@localhost>',NULL),('<1409673567.2035.21.camel@debian.cloudwatt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 17:59:27',7200,'2014-09-02 15:59:27',NULL,'[openstack-dev] [magnetodb] Backup procedure for Cassandra\n backend','On Tue, 2014-09-02 at 17:34 +0300, Dmitriy Ukhlov wrote:\n> Hi Romain!\n> \n> \n> Thank you for useful info about your Cassandra backuping.\n\nIt\'s always a pleasure to talk about Cassandra :)\n\n> \n> We have not tried to tune Cassandra compaction properties yet.\n> \n> MagnetoDB is DynamoDB-like REST API and it means that it is key-value\n> storage itself and it should be able to work for different kind of\n> load, because it depends on user application which use MagnetoDB.\n\nThe compaction strategy choice really matters when setting up a cluster.\nIn such a use case, I mean MagnetoDB, we can assume that the database\nwill be updated frequently. Thus LCS is more suitable than STCS.\n\n\n> Do you have some recommendation or comments based on information about\n> read/write ratio?\n\nYes, if read/write ratio >= 2 then LCS is a must have.\nJust be aware that LCS is more IO intensive during compaction than STCS,\nbut it\'s for a good cause.\n\nYou\'ll find information here:\nhttp://www.datastax.com/dev/blog/when-to-use-leveled-compaction\n\nBest,\n\nRomain\n\n\n\n\n\n','<CADpk5BYGseNQSOEQX0ERzQuQKfppdH62k5kJ9yTWurAakTNq1Q@mail.gmail.com>',NULL),('<1409675439.3820.10.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 16:27:59',0,'2014-09-02 16:27:59',NULL,'[openstack-dev] [neutron][lbaas][octavia]','Yeah I\'ve been worried about the term \"driver\" being overused here.\nHowever, it might not be too bad if we get the other terminology correct\n(network driver, vm/container/appliance driver, etc).\n\nI was thinking of ML2 when I said Octavia living in the LBaaS tree might\nbe best.  I was also thinking that it makes sense if the end goal is for\nOctavia to be in openstack.  Also, even if it goes into the LBaaS tree,\nit doesn\'t mean it can\'t be spun out as its own openstack project,\nthough I do recognize the backwards-ness of that.\n\nThat said, I\'m not stongly opposed to either options.  I just want\neveryone involved to be happy, though that is not always going to\nhappen.\n\nThanks,\nBrandon\n\nOn Tue, 2014-09-02 at 15:45 +0000, Doug Wiegley wrote:\n> Hi all,\n> \n> \n> > On the other hand one could also say that Octavia is the ML2\n> equivalent of LBaaS. The equivalence here is very loose. Octavia would\n> be a service-VM framework for doing load balancing using a variety of\n> drivers. The drivers ultimately are in charge of using backends like\n> haproxy or nginx running on the service VM to implement lbaas\n> configuration.\n> \n> \n> This, exactly.  I think it?s much fairer to define Octavia as an LBaaS\n> purpose-built service vm framework, which will use nova and haproxy\n> initially to provide a highly scalable backend. But before we get into\n> terminology misunderstandings, there are a bunch of different\n> ?drivers? at play here, exactly because this is a framework:\n>       * Neutron lbaas drivers ? what we all know and love\n>       * Octavia?s ?network driver? - this is a piece of glue that\n>         exists to hide internal calls we have to make into Neutron\n>         until clean interfaces exist.  It might be a no-op in the case\n>         of an actual neutron lbaas driver, which could serve that\n>         function instead.\n>       * Octavia?s ?vm driver? - this is a piece of glue between the\n>         octavia controller and the nova VMs that are doing the load\n>         balancing.\n>       * Octavia?s ?compute driver? - you guessed it, an abstraction to\n>         Nova and its scheduler.\n> Places that can be the ?front-end? for Octavia:\n>       * Neutron LBaaS v2 driver\n>       * Neutron LBaaS v1 driver\n>       * It?s own REST API\n> Things that could have their own VM drivers:\n>       * haproxy, running inside nova\n>       * Nginx, running inside nova\n>       * Anything else you want, running inside any hypervisor you want\n>       * Vendor soft appliances\n>       * Null-out the VM calls and go straight to some other backend?\n>          Sure, though I?m not sure I?d see the point.\n> There are quite a few synergies with other efforts, and we?re\n> monitoring them, but not waiting for any of them.\n> \n> \n> And I agree with Brandon?s sentiments.  We need to get something built\n> before I?m going to worry too much about where it should live.  Is\n> this a candidate to get sucked into LBaaS?  Sure.  Could the reverse\n> happen?  Sure.  Let?s see how it develops.\n> \n> \n> Incidentally, we are currently having a debate over the use of the\n> term ?vm? (and ?vm driver?) as the name to describe octavia?s\n> backends.  Feel free to chime in\n> here: https://review.openstack.org/#/c/117701/\n> \n> \n> Thanks,\n> doug\n> \n> \n> \n> \n> From: Salvatore Orlando <sorlando at nicira.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage\n> questions)\" <openstack-dev at lists.openstack.org>\n> Date: Tuesday, September 2, 2014 at 9:05 AM\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [neutron][lbaas][octavia]\n> \n> \n> \n> Hi Susanne,\n> \n> \n> I\'m just trying to gain a good understanding of the situation here.\n> More comments and questions inline.\n> \n> \n> Salvatore\n> \n> On 2 September 2014 16:34, Susanne Balle <sleipnir012 at gmail.com>\n> wrote:\n>         Salvatore \n>         \n>         \n>         Thanks for your clarification below around the blueprint.\n>         \n>         \n>         > For LBaaS v2 therefore the relationship between it and\n>         Octavia should be the same as with any other\n>         > backend. I see Octavia has a blueprint for a \"network\n>         driver\" - and the derivable of that should definitely be\n>         > part of the LBaaS project.\n>         \n>         \n>         > For the rest, it would seem a bit strange to me if the LBaaS\n>         project incorporated a backend as well. After \n>         \n>         > all, LBaaS v1 did not incorporate haproxy!\n>         > Also, as Adam points out, Nova does not incorporate an\n>         Hypervisor.\n>         \n>         \n>         In my vision Octavia is a LBaaS framework that should not be\n>         tied to ha-proxy. The interfaces should be clean and at a high\n>         enough level that we can switch load-balancer. We should be\n>         able to switch the load-balancer to nginx so to me the analogy\n>         is more Octavia+LBaaSV2 == nova and hypervisor ==\n>         load-balancer.\n> \n> \n> Indeed I said that it would have been initially tied to haproxy\n> considering the blueprints currently defined for octavia, but I\'m sure\n> the solution could leverage nginx or something else in the future. \n> \n> \n> I think however it is correct to say that LBaaS v2 will have an\n> Octavia driver on par with A10, radware, nestscaler and others.\n> (Correct me if I\'m wrong) On the other hand Octavia, within its\n> implementation, might use different drivers - for instance nginx or\n> haproxy. And in theory it cannot be excluded that the same appliance\n> might implement some vips using haproxy and others using nginx.\n> \n> \n>         \n>         \n>         I am not sure the group is in agreement on the definition I\n>         just wrote. Also going back the definition of Octavia being a\n>         backend then I agree that we should write a blueprint to\n>         incorporate Octavia as a network driver. \n> \n> \n> What about this blueprint?\n> https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver\n>  \n>         \n>         \n>         I guess I had always envisioned what we now call Octavia to be\n>         part of the LBaaS service itself and have ha-proxy, nginx be\n>         the drivers and not have the driver level be at the Octavia\n>         cut-over point, Given this new \"design\" I am now wondering why\n>         we didn\'t just write a driver for Libra and improved on Libra\n>         since to me that is the now the driver level we are\n>         discussing.\n> \n> \n> Octavia could be part of the lbaas service just like neutron has a set\n> of agents which at the end of the day provide a L2/L3 network\n> virtualization service. Personally I\'m of the opinion that I would\n> move that code in a separate repo which could be maintained by\n> networking experts (I can barely plug an ethernet cable into a\n> switch). But the current situation creates a case for Octavia\n> inclusion in lbaas.\n> \n> \n> On the other hand one could also say that Octavia is the ML2\n> equivalent of LBaaS. The equivalence here is very loose. Octavia would\n> be a service-VM framework for doing load balancing using a variety of\n> drivers. The drivers ultimately are in charge of using backends like\n> haproxy or nginx running on the service VM to implement lbaas\n> configuration.\n> To avoid further discussion it might be better to steer away from\n> discussing overlaps and synergies with the service VM project, at\n> least for now.\n> \n> \n> I think the ability of having the Libra driver was discussed in the\n> past. I do not know the details, but it seemed there was not a lot to\n> gain from having a Neutron LBaaS driver pointing to libra (ie: it was\n> much easier to just deploy libra instead of neutron lbaas).\n> \n> \n> Summarising, so far I haven\'t yet an opinion regarding where Octavia\n> will sit.\n> Nevertheless I think this is a discussion that it\'s useful for the\n> medium/long term - it does not seem to me that there is an urgency\n> here.\n> \n> \n>  \n> \n>         \n>         \n>         Regards Susanne\n>         \n>         \n>         On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando\n>         <sorlando at nicira.com> wrote:\n>                 Some more comments from me inline.\n>                 \n>                 Salvatore\n>                 \n>                 \n>                 On 2 September 2014 11:06, Adam Harwell\n>                 <adam.harwell at rackspace.com> wrote:\n>                         I also agree with most of what Brandon said,\n>                         though I am slightly\n>                         concerned by the talk of merging Octavia and\n>                         [Neutron-]LBaaS-v2 codebases.\n>                 \n>                 \n>                 Beyond all the reasons listed in this thread - merging\n>                 codebases is always more difficult that what it seems!\n>                 Also it seems to me there\'s not yet a clear path for\n>                 LBaaS v2. Mostly because of the ongoing neutron\n>                 incubator discussion.\n>                 However in my opinion there are 3 paths (and I have no\n>                 idea whether they might be applicable to Octavia as a\n>                 standalone project).\n>                 1) Aim at becoming part of neutron via the incubator\n>                 or any equivalent mechanisms\n>                 2) Evolve in loosely coupled fashion with neutron, but\n>                 still be part of the networking program. (This means\n>                 that LBaaS APIs will be part of Openstack Network\n>                 APIs)\n>                 3) Evolve independently from neutron, and become part\n>                 of a new program. I have no idea however whether\n>                 there\'s enough material to have a \"load balancing\"\n>                 program, and what would be the timeline for that.\n>                 \n>                 \n>                         \n>                         [blogan] \"I think the best course of action is\n>                         to get Octavia itself into\n>                         the same codebase as LBaaS (Neutron or spun\n>                         out).\"\n>                         \n>                         [sballe] \"What I am trying to now understand\n>                         is how we will move Octavia\n>                         into the new LBaaS project?\"\n>                         \n>                         \n>                         \n>                         I didn\'t think that was ever going to be the\n>                         plan -- sure, we\'d have an\n>                         Octavia driver that is part of the\n>                         [Neutron-]LBaaS-v2 codebase (which\n>                         Susanne did mention as well), but nothing more\n>                         than that. The actual\n>                         Octavia code would still be in its own project\n>                         at the end of all of this,\n>                         right? The driver code could be added to\n>                         [Neutron-]LbaaS-v2 at any point\n>                         once Octavia is mature enough to be used, just\n>                         by submitting it as a CR, I\n>                         believe. Doug might be able to comment on\n>                         that, since he maintains the A10\n>                         driver?\n>                 \n>                 \n>                 From what I gathered so far Octavia is a fully fledged\n>                 load balancing virtual appliance which (at least in\n>                 its first iterations) will leverage haproxy.\n>                 As also stated earlier in this thread it\'s a peer of\n>                 commercial appliances from various vendors.\n>                 \n>                 \n>                 For LBaaS v2 therefore the relationship between it and\n>                 Octavia should be the same as with any other backend.\n>                 I see Octavia has a blueprint for a \"network driver\" -\n>                 and the derivable of that should definitely be part of\n>                 the LBaaS project.\n>                 For the rest, it would seem a bit strange to me if the\n>                 LBaaS project incorporated a backend as well. After\n>                 all, LBaaS v1 did not incorporate haproxy!\n>                 Also, as Adam points out, Nova does not incorporate an\n>                 Hypervisor.\n>                  \n>                         \n>                         Also, I know I\'m opening this same can of\n>                         worms again, but I am curious\n>                         about the HP mandate that \"everything must be\n>                         OpenStack\" when it comes to\n>                         Octavia. Since HP\'s offering would be\n>                         \"[Neutron-]LBaaS-v2\", which happens\n>                         to use Octavia as a backend, does it matter\n>                         whether Octavia is an official\n>                         OpenStack project**? If HP can offer Cloud\n>                         Compute through Nova, and Nova\n>                         uses some hypervisor like Xen or KVM (neither\n>                         of which are a part of\n>                         OpenStack), I am not sure how it is different\n>                         to offer Cloud Load\n>                         Balancing via [Neutron-]LBaaS-v2 which could\n>                         be using a non-Openstack\n>                         implementation for the backend. I don\'t see\n>                         \"Octavia needs to be in\n>                         Openstack\" as a blocker so long as the \"LBaaS\n>                         API\" is part of OpenStack.\n>                         \n>                         **NOTE: I AM DEFINITELY STILL IN FAVOR OF\n>                         OCTAVIA BEING AN OPENSTACK\n>                         PROJECT. THIS IS JUST AN EXAMPLE FOR THE SAKE\n>                         OF THIS PARTICULAR ARGUMENT.\n>                         PLEASE DON\'T THINK THAT I\'M AGAINST OCTAVIA\n>                         BEING OFFICIALLY INCUBATED!**\n>                         \n>                         \n>                          --Adam\n>                         \n>                         \n>                         https://keybase.io/rm_you\n>                         \n>                         \n>                         \n>                         On 9/1/14 10:12 PM, \"Brandon Logan\"\n>                         <brandon.logan at RACKSPACE.COM> wrote:\n>                         \n>                         >Hi Susanne and everyone,\n>                         >\n>                         >My opinions are that keeping it in stackforge\n>                         until it gets mature is\n>                         >the best solution.  I\'m pretty sure we can\n>                         all agree on that.  Whenever\n>                         >it is mature then, and only then, we should\n>                         try to get it into openstack\n>                         >one way or another.  If Neutron LBaaS v2 is\n>                         still incubated then it\n>                         >should be relatively easy to get it in that\n>                         codebase.  If Neutron LBaaS\n>                         >has already spun out, even easier for us.  If\n>                         we want Octavia to just\n>                         >become an openstack project all its own then\n>                         that will be the difficult\n>                         >part.\n>                         >\n>                         >I think the best course of action is to get\n>                         Octavia itself into the same\n>                         >codebase as LBaaS (Neutron or spun out).\n>                         They do go together, and the\n>                         >maintainers will almost always be the same\n>                         for both.  This makes even\n>                         >more sense when LBaaS is spun out into its\n>                         own project.\n>                         >\n>                         >I really think all of the answers to these\n>                         questions will fall into\n>                         >place when we actually deliver a product that\n>                         we are all wanting and\n>                         >talking about delivering with Octavia.  Once\n>                         we prove that we can all\n>                         >come together as a community and manage a\n>                         product from inception to\n>                         >maturity, we will then have the respect and\n>                         trust to do what is best for\n>                         >an Openstack LBaaS product.\n>                         >\n>                         >Thanks,\n>                         >Brandon\n>                         >\n>                         >On Mon, 2014-09-01 at 10:18 -0400, Susanne\n>                         Balle wrote:\n>                         >> Kyle, Adam,\n>                         >>\n>                         >>\n>                         >>\n>                         >> Based on this thread Kyle is suggesting the\n>                         follow moving forward\n>                         >> plan:\n>                         >>\n>                         >>\n>                         >>\n>                         >> 1) We incubate Neutron LBaaS V2 in the\n>                         ?Neutron? incubator ?and freeze\n>                         >> LBaas V1.0?\n>                         >> 2) ?Eventually? It graduates into a project\n>                         under the networking\n>                         >> program.\n>                         >> 3) ?At that point? We deprecate Neutron\n>                         LBaaS v1.\n>                         >>\n>                         >>\n>                         >>\n>                         >> The words in ?xx? are works I added to make\n>                         sure I/We understand the\n>                         >> whole picture.\n>                         >>\n>                         >>\n>                         >>\n>                         >> And as Adam mentions: Octavia != LBaaS-v2.\n>                         Octavia is a peer to F5 /\n>                         >> Radware / A10 / etc appliances which is a\n>                         definition I agree with BTW.\n>                         >>\n>                         >>\n>                         >>\n>                         >> What I am trying to now understand is how\n>                         we will move Octavia into\n>                         >> the new LBaaS project?\n>                         >>\n>                         >>\n>                         >>\n>                         >> If we do it later rather than develop\n>                         Octavia in tree under the new\n>                         >> incubated LBaaS project when do we plan to\n>                         bring it in-tree from\n>                         >> Stackforge? Kilo? Later? When LBaaS is a\n>                         separate project under the\n>                         >> Networking program?\n>                         >\n>                         >>\n>                         >>\n>                         >> What are the criteria to bring a driver\n>                         into the LBaaS project and\n>                         >> what do we need to do to replace the\n>                         existing reference driver? Maybe\n>                         >> adding a software driver to LBaaS source\n>                         tree is less of a problem\n>                         >> than converting a whole project to an\n>                         OpenStack project.\n>                         >\n>                         >>\n>                         >>\n>                         >> Again I am open to both directions I just\n>                         want to make sure we\n>                         >> understand why we are choosing to do one or\n>                         the other and that our\n>                         >>  decision is based on data and not\n>                         emotions.\n>                         >>\n>                         >>\n>                         >>\n>                         >> I am assuming that keeping Octavia in\n>                         Stackforge will increase the\n>                         >> velocity of the project and allow us more\n>                         freedom which is goodness.\n>                         >> We just need to have a plan to make it part\n>                         of the Openstack LBaaS\n>                         >> project.\n>                         >>\n>                         >>\n>                         >>\n>                         >> Regards Susanne\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >> On Sat, Aug 30, 2014 at 2:09 PM, Adam\n>                         Harwell\n>                         >> <adam.harwell at rackspace.com> wrote:\n>                         >>         Only really have comments on two of\n>                         your related points:\n>                         >>\n>                         >>\n>                         >>         [Susanne] To me Octavia is a driver\n>                         so it is very hard to me\n>                         >>         to think of it as a standalone\n>                         project. It needs the new\n>                         >>         Neutron LBaaS v2 to function which\n>                         is why I think of them\n>                         >>         together. This of course can change\n>                         since we can add whatever\n>                         >>         layers we want to Octavia.\n>                         >>\n>                         >>\n>                         >>         [Adam] I guess I\'ve always shared\n>                         Stephen\'s\n>                         >>         viewpoint ? Octavia != LBaaS-v2.\n>                         Octavia is a peer to F5 /\n>                         >>         Radware / A10 / etcappliances, not\n>                         to an Openstack API layer\n>                         >>         like Neutron-LBaaS. It\'s a little\n>                         tricky to clearly define\n>                         >>         this difference in conversation,\n>                         and I have noticed that quite\n>                         >>         a few people are having the same\n>                         issue differentiating. In a\n>                         >>         small group, having quite a few\n>                         people not on the same page is\n>                         >>         a bit scary, so maybe we need to\n>                         really sit down and map this\n>                         >>         out so everyone is together one way\n>                         or the other.\n>                         >>\n>                         >>\n>                         \n>                         >>         [Susanne] Ok now I am confused? But\n>                         I agree with you that it\n>                         >>         need to focus on our use cases. I\n>                         remember us discussing\n>                         >>         Octavia being the refenece\n>                         implementation for OpenStack LBaaS\n>                         >>         (whatever that is). Has that\n>                         changed while I was on vacation?\n>                         >>\n>                         >>\n>                         >>         [Adam] I believe that having the\n>                         Octavia \"driver\" (not the\n>                         >>         Octavia codebase itself,\n>                         technically) become the reference\n>                         >>         implementation for Neutron-LBaaS is\n>                         still the plan in my eyes.\n>                         >>         The Octavia Driver in Neutron-LBaaS\n>                         is a separate bit of code\n>                         >>         from the actual Octavia project,\n>                         similar to the way the A10\n>                         >>         driver is a separate bit of code\n>                         from the A10 appliance. To do\n>                         >>         that though, we need Octavia to be\n>                         fairly close to fully\n>                         >>         functional. I believe we can do\n>                         this because even though the\n>                         >>         reference driver would then require\n>                         an additional service to\n>                         >>         run, what it requires is still\n>                         fully-open-source and (by way\n>                         >>         of our plan) available as part of\n>                         OpenStack core.\n>                         >>\n>                         >>\n>                         >>         --Adam\n>                         >>\n>                         >>\n>                         >>         https://keybase.io/rm_you\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>         From: Susanne Balle\n>                         <sleipnir012 at gmail.com>\n>                         >>         Reply-To: \"OpenStack Development\n>                         Mailing List (not for usage\n>                         >>         questions)\"\n>                         <openstack-dev at lists.openstack.org>\n>                         >>         Date: Friday, August 29, 2014 9:19\n>                         AM\n>                         >>         To: \"OpenStack Development Mailing\n>                         List (not for usage\n>                         >>         questions)\"\n>                         <openstack-dev at lists.openstack.org>\n>                         >>\n>                         >>         Subject: Re: [openstack-dev]\n>                         [neutron][lbaas][octavia]\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 Stephen\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 See inline comments.\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 Susanne\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                          -----------------------------------------\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 Susanne--\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 I think you are conflating\n>                         the difference between\n>                         >>                 \"OpenStack incubation\" and\n>                         \"Neutron incubator.\" These\n>                         >>                 are two very different\n>                         matters and should be treated\n>                         >>                 separately. So, addressing\n>                         each one individually:\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 \"OpenStack Incubation\"\n>                         >>\n>                         >>                 I think this has been the\n>                         end-goal of Octavia all\n>                         >>                 along and continues to be\n>                         the end-goal. Under this\n>                         >>                 scenario, Octavia is its\n>                         own stand-alone project with\n>                         >>                 its own PTL and core\n>                         developer team, its own\n>                         >>                 governance, and should\n>                         eventually become part of the\n>                         >>                 integrated OpenStack\n>                         release. No project ever starts\n>                         >>                 out as \"OpenStack\n>                         incubated.\"\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 [Susanne] I totally agree\n>                         that the end goal is for\n>                         >>                 Neutron LBaaS to become its\n>                         own incubated project. I\n>                         >>                 did miss the nuance that\n>                         was pointed out by Mestery in\n>                         >>                 an earlier email that if a\n>                         Neutron incubator project\n>                         >>                 wants to become a separate\n>                         project it will have to\n>                         >>                 apply for incubation again\n>                         or at that time. It was my\n>                         >>                 understanding that such a\n>                         Neutron incubated project\n>                         >>                 would be grandfathered in\n>                         but again we do not have\n>                         >>                 much details on the process\n>                         yet.\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 To me Octavia is a driver\n>                         so it is very hard to me to\n>                         >>                 think of it as a standalone\n>                         project. It needs the new\n>                         >>                 Neutron LBaaS v2 to\n>                         function which is why I think of\n>                         >>                 them together. This of\n>                         course can change since we can\n>                         >>                 add whatever layers we want\n>                         to Octavia.\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 \"Neutron Incubator\"\n>                         >>\n>                         >>                 This has only become a\n>                         serious discussion in the last\n>                         >>                 few weeks and has yet to\n>                         land, so there are many\n>                         >>                 assumptions about this\n>                         which don\'t pan out (either\n>                         >>                 because of purposeful\n>                         design and governance decisions,\n>                         >>                 or because of how this\n>                         project actually ends up being\n>                         >>                 implemented from a\n>                         practical standpoint). But given\n>                         >>                 the inherent limitations\n>                         about making statements with\n>                         >>                 so many unknowns, the\n>                         following seem fairly clear from\n>                         >>                 what has been shared so\n>                         far:\n>                         >>\n>                         >>                 ? Neutron incubator is the\n>                         on-ramp for projects which\n>                         >>                 should eventually become a\n>                         part of Neutron itself.\n>                         >>\n>                         >>                 ? Projects which enter the\n>                         Neutron incubator on-ramp\n>                         >>                 should be fairly close to\n>                         maturity in their final\n>                         >>                 form. I think the intent\n>                         here is for them to live in\n>                         >>                 incubator for 1 or 2 cycles\n>                         before either being merged\n>                         >>                 into Neutron core, or being\n>                         ejected (as abandoned, or\n>                         >>                 as a separate project).\n>                         >>\n>                         >>                 ? Neutron incubator\n>                         projects effectively do not have\n>                         >>                 their own PTL and core\n>                         developer team, and do not have\n>                         >>                 their own governance.\n>                         >>\n>                         >>                 [Susanne] Ok I missed the\n>                         last point. In an earlier\n>                         >>                 discussion Mestery implied\n>                         that an incubated project\n>                         >>                 would have at least one or\n>                         two of its own cores. Maybe\n>                         >>                 that changed between now\n>                         and then.\n>                         >>\n>                         >>                 In addition we know the\n>                         following about Neutron LBaaS\n>                         >>                 and Octavia:\n>                         >>\n>                         >>                 ? It\'s already\n>                         (informally?) agreed that the ultimate\n>                         >>                 long-term place for a LBaaS\n>                         solution is probably to be\n>                         >>                 spun out into its own\n>                         project, which might\n>                         >>                 appropriately live under a\n>                         yet-to-be-defined master\n>                         >>                 \"Networking\" project. (This\n>                         would make Neutron, LBaaS,\n>                         >>                 VPNaaS, FWaaS, etc.\n>                         effective \"peer\" projects under\n>                         >>                 the Networking umbrella.)\n>                         Since this \"Networking\"\n>                         >>                 umbrella project has even\n>                         less defined about it than\n>                         >>                 Neutron incubator, it\'s\n>                         impossible to know whether\n>                         >>                 being a part of Neutron\n>                         incubator would be of any\n>                         >>                 benefit to Octavia (or,\n>                         conversely, to Neutron\n>                         >>                 incubator) at all as an\n>                         on-ramp to becoming part of\n>                         >>                 \"Networking.\" Presumably,\n>                         Octavia might fit well under\n>                         >>                 the \"Networking\" umbrella--\n>                         but, again, with nothing\n>                         >>                 defined there it\'s\n>                         impossible to draw any reasonable\n>                         >>                 conclusions at this time.\n>                         >>\n>                         >>                 [Susanne] We are in\n>                         agreement here. This was the\n>                         >>                 reasons we had the ad-hoc\n>                         meeting in Atlanta so get a\n>                         >>                 feel for hw people felt if\n>                         we made Neutron LBaaS its\n>                         >>                 own project and also how we\n>                         got an operator large\n>                         >>                 scale LBaaS that fit most\n>                         of our service provider\n>                         >>                 requirements. I am just\n>                         worried because you keep on\n>                         >>                 talking of Octavia as a\n>                         standaloe project. To me it is\n>                         >>                 an extension of Neutron\n>                         LBaaS or of a new LBaaS ?. I\n>                         >>                 do not see us (== me) use\n>                         Octavia in a non OpenStack\n>                         >>                 context. And yes it is a\n>                         driver that I am hoping we\n>                         >>                 all expect to become the\n>                         reference implementation for\n>                         >>                 LBaaS.\n>                         >>\n>                         >>                 ? When the LBaaS component\n>                         spins out of Neutron, it\n>                         >>                 will more than likely not\n>                         be Octavia.  Octavia\n>                         >>                 is intentionally less\n>                         friendly to 3rd party load\n>                         >>                 balancer vendors both\n>                         because it\'s envisioned that\n>                         >>                 Octavia would just be\n>                         another implementation which\n>                         >>                 lives along-side said 3rd\n>                         party vendor products\n>                         >>                 (plugging into a higher\n>                         level LBaaS layer via a\n>                         >>                 driver), and because we\n>                         don\'t want to have to\n>                         >>                 compromise certain design\n>                         features of Octavia to meet\n>                         >>                 the lowest common\n>                         denominator 3rd party vendor\n>                         >>                 product. (3rd party vendors\n>                         are welcome, but we will\n>                         >>                 not make design compromises\n>                         to meet the needs of a\n>                         >>                 proprietary product--\n>                         compatibility with available\n>                         >>                 open-source products and\n>                         standards trumps this.)\n>                         >>\n>                         \n>                         >>                 [Susanne] Ok now I am\n>                         confused? But I agree with you\n>                         >>                 that it need to focus on\n>                         our use cases. I remember us\n>                         >>                 discussing Octavia being\n>                         the refenece implementation\n>                         >>                 for OpenStack LBaaS\n>                         (whatever that is). Has that\n>                         >>                 changed while I was on\n>                         vacation?\n>                         >>\n>                         >>                 The end-game for the above\n>                         point is: In the future I\n>                         >>                 see \"Openstack LBaaS\" (or\n>                         whatever the project calls\n>                         >>                 itself) being a separate\n>                         but complimentary project to\n>                         >>                 Octavia.\n>                         >>\n>                         >>                 ? While its true that we\n>                         would like Octavia to become\n>                         >>                 the reference\n>                         implementation for Neutron LBaaS, we are\n>                         >>                 nowhere near being able to\n>                         deliver on that. Attempting\n>                         >>                 to become a part of Neutron\n>                         LBaaS right now is likely\n>                         >>                 just to create frustration\n>                         (and very little merged\n>                         >>                 code) for both the Octavia\n>                         and Neutron teams.\n>                         >>\n>                         >>                 [Susanne] Agreed.\n>                         >>\n>                         >>                 So given that the only code\n>                         in Octavia right now are a\n>                         >>                 few database migrations, we\n>                         are very, very far away\n>                         >>                 from being ready for either\n>                         OpenStack incubation or\n>                         >>                 the Neutron incubator\n>                         project. I don\'t think it\'s very\n>                         >>                 useful to be spending time\n>                         right now worrying about\n>                         >>                 either of these outcomes:\n>                         We should be working on\n>                         >>                 Octavia!\n>                         >>\n>                         >>                 [Susanne] Agreed. You\n>                         suggested we discuss this on the\n>                         >>                 ML NOW. I wanted to wait\n>                         until the summit given that\n>                         >>                 we would have more info on\n>                         Neutron incubation, etc. I\n>                         >>                 haven?t seen much written\n>                         down on the Neutron\n>                         >>                 incubator project so most\n>                         of what we are doing is\n>                         \n>                         >>                 guessing?.\n>                         >>\n>                         >>                 Please also understand:  I\n>                         realize that probably the\n>                         >>                 reason you\'re asking this\n>                         right now is because you\n>                         >>                 have a mandate within your\n>                         organization to use only\n>                         >>                 \"official\" OpenStack\n>                         branded components, and if\n>                         >>                 Octavia doesn\'t fall within\n>                         that category, you won\'t\n>                         >>                 be able to use it.  Of\n>                         course everyone working on this\n>                         >>                 project wants to make that\n>                         happen too, so we\'re doing\n>                         >>                 everything we can to make\n>                         sure we don\'t jeopardize\n>                         >>                 that possibility. And there\n>                         are enough voices in this\n>                         >>                 project that want that to\n>                         happen, so I think if we\n>                         >>                 strayed from the path to\n>                         get there, there would be\n>                         >>                 sufficient clangor over\n>                         this that it would be hard to\n>                         >>                 miss. But I don\'t think\n>                         there\'s anyone at all at this\n>                         >>                 time that can honestly give\n>                         you a promise that Octavia\n>                         >>                 definitely will be\n>                         incubated and will definitely end\n>                         >>                 up in the integrated\n>                         OpenStack release.\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 If you want to increase the\n>                         chances of that happening,\n>                         >>                 please help push the\n>                         project forward!\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 [Susanne] That is what HP\n>                         is doing. Remember we were\n>                         >>                 here from the beginning\n>                         helping change the direction\n>                         >>                 for LBaaS.\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 Thanks,\n>                         >>\n>                         >>                 Stephen\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>                 On Thu, Aug 28, 2014 at\n>                         9:52 PM, Stephen Balukoff\n>                         >>                 <sbalukoff at bluebox.net>\n>                         wrote:\n>                         >>                         Susanne--\n>                         >>\n>                         >>\n>                         >>                         I think you are\n>                         conflating the difference\n>                         >>                         between \"OpenStack\n>                         incubation\" and \"Neutron\n>                         >>                         incubator.\" These\n>                         are two very different\n>                         >>                         matters and should\n>                         be treated separately. So,\n>                         >>                         addressing each one\n>                         individually:\n>                         >>\n>                         >>\n>                         >>                         \"OpenStack\n>                         Incubation\"\n>                         >>                         I think this has\n>                         been the end-goal of Octavia\n>                         >>                         all along and\n>                         continues to be the end-goal.\n>                         >>                         Under this\n>                         scenario, Octavia is its own\n>                         >>                         stand-alone project\n>                         with its own PTL and core\n>                         >>                         developer team, its\n>                         own governance, and should\n>                         >>                         eventually become\n>                         part of the integrated\n>                         >>                         OpenStack release.\n>                         No project ever starts out\n>                         >>                         as \"OpenStack\n>                         incubated.\"\n>                         >>\n>                         >>\n>                         >>                         \"Neutron Incubator\"\n>                         >>                         This has only\n>                         become a serious discussion in\n>                         >>                         the last few weeks\n>                         and has yet to land, so\n>                         >>                         there are many\n>                         assumptions about this which\n>                         >>                         don\'t pan out\n>                         (either because of purposeful\n>                         >>                         design and\n>                         governance decisions, or because of\n>                         >>                         how this project\n>                         actually ends up being\n>                         >>                         implemented from a\n>                         practical standpoint). But\n>                         >>                         given the inherent\n>                         limitations about making\n>                         >>                         statements with so\n>                         many unknowns, the\n>                         >>                         following seem\n>                         fairly clear from what has been\n>                         >>                         shared so far:\n>                         >>                               * Neutron\n>                         incubator is the on-ramp for\n>                         >>                                 projects\n>                         which should eventually\n>                         >>                                 become a\n>                         part of Neutron itself.\n>                         >>                               * Projects\n>                         which enter the Neutron\n>                         >>                                 incubator\n>                         on-ramp should be fairly\n>                         >>                                 close to\n>                         maturity in their final form.\n>                         >>                                 I think the\n>                         intent here is for them to\n>                         >>                                 live in\n>                         incubator for 1 or 2 cycles\n>                         >>                                 before\n>                         either being merged into\n>                         >>                                 Neutron\n>                         core, or being ejected (as\n>                         >>                                 abandoned,\n>                         or as a separate project).\n>                         >>                               * Neutron\n>                         incubator projects effectively\n>                         >>                                 do not have\n>                         their own PTL and core\n>                         >>                                 developer\n>                         team, and do not have their\n>                         >>                                 own\n>                         governance.\n>                         >>                         In addition we know\n>                         the following about\n>                         >>                         Neutron LBaaS and\n>                         Octavia:\n>                         >>                               * It\'s\n>                         already (informally?) agreed that\n>                         >>                                 the\n>                         ultimate long-term place for a\n>                         >>                                 LBaaS\n>                         solution is probably to be spun\n>                         >>                                 out into\n>                         its own project, which might\n>                         >>\n>                          appropriately live under a\n>                         >>\n>                          yet-to-be-defined master \"Networking\"\n>                         >>                                 project.\n>                         (This would make Neutron,\n>                         >>                                 LBaaS,\n>                         VPNaaS, FWaaS, etc. effective\n>                         >>                                 \"peer\"\n>                         projects under the Networking\n>                         >>                                 umbrella.)\n>                         Since this \"Networking\"\n>                         >>                                 umbrella\n>                         project has even less defined\n>                         >>                                 about it\n>                         than Neutron incubator, it\'s\n>                         >>                                 impossible\n>                         to know whether being a\n>                         >>                                 part of\n>                         Neutron incubator would be of\n>                         >>                                 any benefit\n>                         to Octavia (or,\n>                         >>                                 conversely,\n>                         to Neutron incubator) at\n>                         >>                                 all as an\n>                         on-ramp to becoming part of\n>                         >>\n>                          \"Networking.\" Presumably, Octavia\n>                         >>                                 might fit\n>                         well under the \"Networking\"\n>                         >>                                 umbrella--\n>                         but, again, with nothing\n>                         >>                                 defined\n>                         there it\'s impossible to draw\n>                         >>                                 any\n>                         reasonable conclusions at this\n>                         >>                                 time.\n>                         >>                               * When the\n>                         LBaaS component spins out of\n>                         >>                                 Neutron, it\n>                         will more than likely not\n>                         >>                                 be Octavia.\n>                         Octavia is intentionally\n>                         >>                                 less\n>                         friendly to 3rd party load\n>                         >>                                 balancer\n>                         vendors both because it\'s\n>                         >>                                 envisioned\n>                         that Octavia would just be\n>                         >>                                 another\n>                         implementation which lives\n>                         >>                                 along-side\n>                         said 3rd party vendor\n>                         >>                                 products\n>                         (plugging into a higher level\n>                         >>                                 LBaaS layer\n>                         via a driver), and because\n>                         >>                                 we don\'t\n>                         want to have to compromise\n>                         >>                                 certain\n>                         design features of Octavia to\n>                         >>                                 meet the\n>                         lowest common denominator 3rd\n>                         >>                                 party\n>                         vendor product. (3rd party\n>                         >>                                 vendors are\n>                         welcome, but we will not\n>                         >>                                 make design\n>                         compromises to meet the\n>                         >>                                 needs of a\n>                         proprietary product--\n>                         >>\n>                          compatibility with available\n>                         >>                                 open-source\n>                         products and standards\n>                         >>                                 trumps\n>                         this.)\n>                         >>                               * The\n>                         end-game for the above point is:\n>                         >>                                 In the\n>                         future I see \"Openstack\n>                         >>                                 LBaaS\" (or\n>                         whatever the project calls\n>                         >>                                 itself)\n>                         being a separate but\n>                         >>\n>                          complimentary project to Octavia.\n>                         >>                               * While its\n>                         true that we would like\n>                         >>                                 Octavia to\n>                         become the reference\n>                         >>\n>                          implementation for Neutron LBaaS, we\n>                         >>                                 are nowhere\n>                         near being able to deliver\n>                         >>                                 on that.\n>                         Attempting to become a part\n>                         >>                                 of Neutron\n>                         LBaaS right now is likely\n>                         >>                                 just to\n>                         create frustration (and very\n>                         >>                                 little\n>                         merged code) for both the\n>                         >>                                 Octavia and\n>                         Neutron teams.\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>                         So given that the\n>                         only code in Octavia right\n>                         >>                         now are a few\n>                         database migrations, we are\n>                         >>                         very, very far away\n>                         from being ready for\n>                         >>                         either OpenStack\n>                         incubation or the Neutron\n>                         >>                         incubator project.\n>                         I don\'t think it\'s very\n>                         >>                         useful to be\n>                         spending time right now worrying\n>                         >>                         about either of\n>                         these outcomes:  We should be\n>                         >>                         working on Octavia!\n>                         >>\n>                         >>\n>                         >>                         Please also\n>                         understand:  I realize that\n>                         >>                         probably the reason\n>                         you\'re asking this right\n>                         >>                         now is because you\n>                         have a mandate within your\n>                         >>                         organization to use\n>                         only \"official\" OpenStack\n>                         >>                         branded components,\n>                         and if Octavia doesn\'t\n>                         >>                         fall within that\n>                         category, you won\'t be able\n>                         >>                         to use it.  Of\n>                         course everyone working on this\n>                         >>                         project wants to\n>                         make that happen too, so\n>                         >>                         we\'re doing\n>                         everything we can to make sure we\n>                         >>                         don\'t jeopardize\n>                         that possibility. And there\n>                         >>                         are enough voices\n>                         in this project that want\n>                         >>                         that to happen, so\n>                         I think if we strayed from\n>                         >>                         the path to get\n>                         there, there would be\n>                         >>                         sufficient clangor\n>                         over this that it would be\n>                         >>                         hard to miss. But I\n>                         don\'t think there\'s anyone\n>                         >>                         at all at this time\n>                         that can honestly give you\n>                         >>                         a promise that\n>                         Octavia definitely will be\n>                         >>                         incubated and will\n>                         definitely end up in the\n>                         >>                         integrated\n>                         OpenStack release.\n>                         >>\n>                         >>\n>                         >>                         If you want to\n>                         increase the chances of that\n>                         >>                         happening, please\n>                         help push the project\n>                         >>                         forward!\n>                         >>\n>                         >>\n>                         >>                         Thanks,\n>                         >>                         Stephen\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>                         On Thu, Aug 28,\n>                         2014 at 2:57 PM, Susanne Balle\n>                         >>\n>                          <sleipnir012 at gmail.com> wrote:\n>                         >>\n>                         >>                                  I would\n>                         like to discuss the pros and\n>                         >>                                 cons of\n>                         putting Octavia into the\n>                         >>                                 Neutron\n>                         LBaaS incubator project right\n>                         >>                                 away. If it\n>                         is going to be the\n>                         >>                                 reference\n>                         implementation for LBaaS v 2\n>                         >>                                 then I\n>                         believe Octavia belong in\n>                         >>                                 Neutron\n>                         LBaaS v2 incubator.\n>                         >>\n>                         >>\n>                         >>                                 The Pros:\n>                         >>                                 * Octavia\n>                         is in Openstack incubation\n>                         >>                                 right away\n>                         along with the lbaas v2\n>                         >>                                 code. We do\n>                         not have to apply for\n>                         >>                                 incubation\n>                         later on.\n>                         >>                                 * As\n>                         incubation project we have our\n>                         >>                                 own core\n>                         and should be able ot commit\n>                         >>                                 our code\n>                         >>                                 * We are\n>                         starting out as an OpenStack\n>                         >>                                 incubated\n>                         project\n>                         >>\n>                         >>\n>                         >>                                 The Cons:\n>                         >>                                 * Not sure\n>                         of the velocity of the\n>                         >>                                 project\n>                         >>                                 *\n>                         Incubation not well defined.\n>                         >>\n>                         >>\n>                         >>                                 If Octavia\n>                         starts as a standalone\n>                         >>                                 stackforge\n>                         project we are assuming\n>                         >>                                 that it\n>                         would be looked favorable on\n>                         >>                                 when time\n>                         is to move it into incubated\n>                         >>                                 status.\n>                         >>\n>                         >>\n>                         >>                                 Susanne\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>\n>                         >>_______________________________________________\n>                         >>\n>                          OpenStack-dev mailing list\n>                         >>\n>                          OpenStack-dev at lists.openstack.org\n>                         >>','<D02B3F91.C0F7%dougw@a10networks.com>',NULL),('<1409676204.3820.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 16:40:44',0,'2014-09-02 16:40:44',NULL,'[openstack-dev] [neutron][lbaas][octavia]','Hi Susanne,\n\nI believe the options for Octavia are:\n1) Merge into the LBaaS tree (wherever LBaaS is)\n2) Become its own openstack project\n3) Remains in stackforge for eternity\n\n#1 Is dependent on these options\n1) LBaaS V2 graduates from the incubator into Neutron. V1 is deprecated.\n2) LBaaS V2 remains in incubator until it can be spun out.  V1 in\nNeutron is deprecated.\n3) LBaaS V2 is abandoned in the incubator and LBaaS V1 remains.  (An\nunlikely option)\n\nI don\'t see any other feasible options.\n\nOn Tue, 2014-09-02 at 12:06 -0400, Susanne Balle wrote:\n> Doug\n> \n> \n> I agree with you but I need to understand the options. Susanne\n> \n> \n> >> And I agree with Brandon?s sentiments.  We need to get something\n> built before I?m going to worry too \n> >> much about where it should live.  Is this a candidate to get sucked\n> into LBaaS?  Sure.  Could the reverse \n> >> happen?  Sure.  Let?s see how it develops.\n> \n> \n> \n> On Tue, Sep 2, 2014 at 11:45 AM, Doug Wiegley <dougw at a10networks.com>\n> wrote:\n>         Hi all,\n>         \n>         \n>         > On the other hand one could also say that Octavia is the ML2\n>         equivalent of LBaaS. The equivalence here is very loose.\n>         Octavia would be a service-VM framework for doing load\n>         balancing using a variety of drivers. The drivers ultimately\n>         are in charge of using backends like haproxy or nginx running\n>         on the service VM to implement lbaas configuration.\n>         \n>         \n>         This, exactly.  I think it?s much fairer to define Octavia as\n>         an LBaaS purpose-built service vm framework, which will use\n>         nova and haproxy initially to provide a highly scalable\n>         backend. But before we get into terminology misunderstandings,\n>         there are a bunch of different ?drivers? at play here, exactly\n>         because this is a framework:\n>               * Neutron lbaas drivers ? what we all know and love\n>               * Octavia?s ?network driver? - this is a piece of glue\n>                 that exists to hide internal calls we have to make\n>                 into Neutron until clean interfaces exist.  It might\n>                 be a no-op in the case of an actual neutron lbaas\n>                 driver, which could serve that function instead.\n>               * Octavia?s ?vm driver? - this is a piece of glue\n>                 between the octavia controller and the nova VMs that\n>                 are doing the load balancing.\n>               * Octavia?s ?compute driver? - you guessed it, an\n>                 abstraction to Nova and its scheduler.\n>         Places that can be the ?front-end? for Octavia:\n>               * Neutron LBaaS v2 driver\n>               * Neutron LBaaS v1 driver\n>               * It?s own REST API\n>         Things that could have their own VM drivers:\n>               * haproxy, running inside nova\n>               * Nginx, running inside nova\n>               * Anything else you want, running inside any hypervisor\n>                 you want\n>               * Vendor soft appliances\n>               * Null-out the VM calls and go straight to some other\n>                 backend?  Sure, though I?m not sure I?d see the point.\n>         There are quite a few synergies with other efforts, and we?re\n>         monitoring them, but not waiting for any of them.\n>         \n>         \n>         And I agree with Brandon?s sentiments.  We need to get\n>         something built before I?m going to worry too much about where\n>         it should live.  Is this a candidate to get sucked into\n>         LBaaS?  Sure.  Could the reverse happen?  Sure.  Let?s see how\n>         it develops.\n>         \n>         \n>         Incidentally, we are currently having a debate over the use of\n>         the term ?vm? (and ?vm driver?) as the name to describe\n>         octavia?s backends.  Feel free to chime in\n>         here: https://review.openstack.org/#/c/117701/\n>         \n>         \n>         Thanks,\n>         doug\n>         \n>         \n>         \n>         \n>         From: Salvatore Orlando <sorlando at nicira.com>\n>         \n>         Reply-To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         \n>         Date: Tuesday, September 2, 2014 at 9:05 AM\n>         \n>         To: \"OpenStack Development Mailing List (not for usage\n>         questions)\" <openstack-dev at lists.openstack.org>\n>         Subject: Re: [openstack-dev] [neutron][lbaas][octavia]\n>         \n>         \n>         \n>         Hi Susanne,\n>         \n>         \n>         I\'m just trying to gain a good understanding of the situation\n>         here.\n>         More comments and questions inline.\n>         \n>         \n>         Salvatore\n>         \n>         On 2 September 2014 16:34, Susanne Balle\n>         <sleipnir012 at gmail.com> wrote:\n>                 Salvatore \n>                 \n>                 \n>                 Thanks for your clarification below around the\n>                 blueprint.\n>                 \n>                 \n>                 > For LBaaS v2 therefore the relationship between it\n>                 and Octavia should be the same as with any other\n>                 > backend. I see Octavia has a blueprint for a\n>                 \"network driver\" - and the derivable of that should\n>                 definitely be\n>                 > part of the LBaaS project.\n>                 \n>                 \n>                 > For the rest, it would seem a bit strange to me if\n>                 the LBaaS project incorporated a backend as well.\n>                 After \n>                 \n>                 > all, LBaaS v1 did not incorporate haproxy!\n>                 > Also, as Adam points out, Nova does not incorporate\n>                 an Hypervisor.\n>                 \n>                 \n>                 In my vision Octavia is a LBaaS framework that should\n>                 not be tied to ha-proxy. The interfaces should be\n>                 clean and at a high enough level that we can switch\n>                 load-balancer. We should be able to switch the\n>                 load-balancer to nginx so to me the analogy is more\n>                 Octavia+LBaaSV2 == nova and hypervisor ==\n>                 load-balancer.\n>         \n>         \n>         Indeed I said that it would have been initially tied to\n>         haproxy considering the blueprints currently defined for\n>         octavia, but I\'m sure the solution could leverage nginx or\n>         something else in the future. \n>         \n>         \n>         I think however it is correct to say that LBaaS v2 will have\n>         an Octavia driver on par with A10, radware, nestscaler and\n>         others.\n>         (Correct me if I\'m wrong) On the other hand Octavia, within\n>         its implementation, might use different drivers - for instance\n>         nginx or haproxy. And in theory it cannot be excluded that the\n>         same appliance might implement some vips using haproxy and\n>         others using nginx.\n>         \n>         \n>                 \n>                 \n>                 I am not sure the group is in agreement on the\n>                 definition I just wrote. Also going back the\n>                 definition of Octavia being a backend then I agree\n>                 that we should write a blueprint to incorporate\n>                 Octavia as a network driver. \n>         \n>         \n>         What about this blueprint?\n>         https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver\n>          \n>                 \n>                 \n>                 I guess I had always envisioned what we now call\n>                 Octavia to be part of the LBaaS service itself and\n>                 have ha-proxy, nginx be the drivers and not have the\n>                 driver level be at the Octavia cut-over point, Given\n>                 this new \"design\" I am now wondering why we didn\'t\n>                 just write a driver for Libra and improved on Libra\n>                 since to me that is the now the driver level we are\n>                 discussing.\n>         \n>         \n>         Octavia could be part of the lbaas service just like neutron\n>         has a set of agents which at the end of the day provide a\n>         L2/L3 network virtualization service. Personally I\'m of the\n>         opinion that I would move that code in a separate repo which\n>         could be maintained by networking experts (I can barely plug\n>         an ethernet cable into a switch). But the current situation\n>         creates a case for Octavia inclusion in lbaas.\n>         \n>         \n>         On the other hand one could also say that Octavia is the ML2\n>         equivalent of LBaaS. The equivalence here is very loose.\n>         Octavia would be a service-VM framework for doing load\n>         balancing using a variety of drivers. The drivers ultimately\n>         are in charge of using backends like haproxy or nginx running\n>         on the service VM to implement lbaas configuration.\n>         To avoid further discussion it might be better to steer away\n>         from discussing overlaps and synergies with the service VM\n>         project, at least for now.\n>         \n>         \n>         I think the ability of having the Libra driver was discussed\n>         in the past. I do not know the details, but it seemed there\n>         was not a lot to gain from having a Neutron LBaaS driver\n>         pointing to libra (ie: it was much easier to just deploy libra\n>         instead of neutron lbaas).\n>         \n>         \n>         Summarising, so far I haven\'t yet an opinion regarding where\n>         Octavia will sit.\n>         Nevertheless I think this is a discussion that it\'s useful for\n>         the medium/long term - it does not seem to me that there is an\n>         urgency here.\n>         \n>         \n>          \n>         \n>                 \n>                 \n>                 Regards Susanne\n>                 \n>                 \n>                 On Tue, Sep 2, 2014 at 9:18 AM, Salvatore Orlando\n>                 <sorlando at nicira.com> wrote:\n>                         Some more comments from me inline.\n>                         \n>                         Salvatore\n>                         \n>                         \n>                         On 2 September 2014 11:06, Adam Harwell\n>                         <adam.harwell at rackspace.com> wrote:\n>                                 I also agree with most of what Brandon\n>                                 said, though I am slightly\n>                                 concerned by the talk of merging\n>                                 Octavia and [Neutron-]LBaaS-v2\n>                                 codebases.\n>                         \n>                         \n>                         Beyond all the reasons listed in this thread -\n>                         merging codebases is always more difficult\n>                         that what it seems!\n>                         Also it seems to me there\'s not yet a clear\n>                         path for LBaaS v2. Mostly because of the\n>                         ongoing neutron incubator discussion.\n>                         However in my opinion there are 3 paths (and I\n>                         have no idea whether they might be applicable\n>                         to Octavia as a standalone project).\n>                         1) Aim at becoming part of neutron via the\n>                         incubator or any equivalent mechanisms\n>                         2) Evolve in loosely coupled fashion with\n>                         neutron, but still be part of the networking\n>                         program. (This means that LBaaS APIs will be\n>                         part of Openstack Network APIs)\n>                         3) Evolve independently from neutron, and\n>                         become part of a new program. I have no idea\n>                         however whether there\'s enough material to\n>                         have a \"load balancing\" program, and what\n>                         would be the timeline for that.\n>                         \n>                         \n>                                 \n>                                 [blogan] \"I think the best course of\n>                                 action is to get Octavia itself into\n>                                 the same codebase as LBaaS (Neutron or\n>                                 spun out).\"\n>                                 \n>                                 [sballe] \"What I am trying to now\n>                                 understand is how we will move Octavia\n>                                 into the new LBaaS project?\"\n>                                 \n>                                 \n>                                 \n>                                 I didn\'t think that was ever going to\n>                                 be the plan -- sure, we\'d have an\n>                                 Octavia driver that is part of the\n>                                 [Neutron-]LBaaS-v2 codebase (which\n>                                 Susanne did mention as well), but\n>                                 nothing more than that. The actual\n>                                 Octavia code would still be in its own\n>                                 project at the end of all of this,\n>                                 right? The driver code could be added\n>                                 to [Neutron-]LbaaS-v2 at any point\n>                                 once Octavia is mature enough to be\n>                                 used, just by submitting it as a CR, I\n>                                 believe. Doug might be able to comment\n>                                 on that, since he maintains the A10\n>                                 driver?\n>                         \n>                         \n>                         From what I gathered so far Octavia is a fully\n>                         fledged load balancing virtual appliance which\n>                         (at least in its first iterations) will\n>                         leverage haproxy.\n>                         As also stated earlier in this thread it\'s a\n>                         peer of commercial appliances from various\n>                         vendors.\n>                         \n>                         \n>                         For LBaaS v2 therefore the relationship\n>                         between it and Octavia should be the same as\n>                         with any other backend. I see Octavia has a\n>                         blueprint for a \"network driver\" - and the\n>                         derivable of that should definitely be part of\n>                         the LBaaS project.\n>                         For the rest, it would seem a bit strange to\n>                         me if the LBaaS project incorporated a backend\n>                         as well. After all, LBaaS v1 did not\n>                         incorporate haproxy!\n>                         Also, as Adam points out, Nova does not\n>                         incorporate an Hypervisor.\n>                          \n>                                 \n>                                 Also, I know I\'m opening this same can\n>                                 of worms again, but I am curious\n>                                 about the HP mandate that \"everything\n>                                 must be OpenStack\" when it comes to\n>                                 Octavia. Since HP\'s offering would be\n>                                 \"[Neutron-]LBaaS-v2\", which happens\n>                                 to use Octavia as a backend, does it\n>                                 matter whether Octavia is an official\n>                                 OpenStack project**? If HP can offer\n>                                 Cloud Compute through Nova, and Nova\n>                                 uses some hypervisor like Xen or KVM\n>                                 (neither of which are a part of\n>                                 OpenStack), I am not sure how it is\n>                                 different to offer Cloud Load\n>                                 Balancing via [Neutron-]LBaaS-v2 which\n>                                 could be using a non-Openstack\n>                                 implementation for the backend. I\n>                                 don\'t see \"Octavia needs to be in\n>                                 Openstack\" as a blocker so long as the\n>                                 \"LBaaS API\" is part of OpenStack.\n>                                 \n>                                 **NOTE: I AM DEFINITELY STILL IN FAVOR\n>                                 OF OCTAVIA BEING AN OPENSTACK\n>                                 PROJECT. THIS IS JUST AN EXAMPLE FOR\n>                                 THE SAKE OF THIS PARTICULAR ARGUMENT.\n>                                 PLEASE DON\'T THINK THAT I\'M AGAINST\n>                                 OCTAVIA BEING OFFICIALLY INCUBATED!**\n>                                 \n>                                 \n>                                  --Adam\n>                                 \n>                                 \n>                                 https://keybase.io/rm_you\n>                                 \n>                                 \n>                                 \n>                                 On 9/1/14 10:12 PM, \"Brandon Logan\"\n>                                 <brandon.logan at RACKSPACE.COM> wrote:\n>                                 \n>                                 >Hi Susanne and everyone,\n>                                 >\n>                                 >My opinions are that keeping it in\n>                                 stackforge until it gets mature is\n>                                 >the best solution.  I\'m pretty sure\n>                                 we can all agree on that.  Whenever\n>                                 >it is mature then, and only then, we\n>                                 should try to get it into openstack\n>                                 >one way or another.  If Neutron LBaaS\n>                                 v2 is still incubated then it\n>                                 >should be relatively easy to get it\n>                                 in that codebase.  If Neutron LBaaS\n>                                 >has already spun out, even easier for\n>                                 us.  If we want Octavia to just\n>                                 >become an openstack project all its\n>                                 own then that will be the difficult\n>                                 >part.\n>                                 >\n>                                 >I think the best course of action is\n>                                 to get Octavia itself into the same\n>                                 >codebase as LBaaS (Neutron or spun\n>                                 out).  They do go together, and the\n>                                 >maintainers will almost always be the\n>                                 same for both.  This makes even\n>                                 >more sense when LBaaS is spun out\n>                                 into its own project.\n>                                 >\n>                                 >I really think all of the answers to\n>                                 these questions will fall into\n>                                 >place when we actually deliver a\n>                                 product that we are all wanting and\n>                                 >talking about delivering with\n>                                 Octavia.  Once we prove that we can\n>                                 all\n>                                 >come together as a community and\n>                                 manage a product from inception to\n>                                 >maturity, we will then have the\n>                                 respect and trust to do what is best\n>                                 for\n>                                 >an Openstack LBaaS product.\n>                                 >\n>                                 >Thanks,\n>                                 >Brandon\n>                                 >\n>                                 >On Mon, 2014-09-01 at 10:18 -0400,\n>                                 Susanne Balle wrote:\n>                                 >> Kyle, Adam,\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> Based on this thread Kyle is\n>                                 suggesting the follow moving forward\n>                                 >> plan:\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> 1) We incubate Neutron LBaaS V2 in\n>                                 the ?Neutron? incubator ?and freeze\n>                                 >> LBaas V1.0?\n>                                 >> 2) ?Eventually? It graduates into a\n>                                 project under the networking\n>                                 >> program.\n>                                 >> 3) ?At that point? We deprecate\n>                                 Neutron LBaaS v1.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> The words in ?xx? are works I added\n>                                 to make sure I/We understand the\n>                                 >> whole picture.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> And as Adam mentions: Octavia !=\n>                                 LBaaS-v2. Octavia is a peer to F5 /\n>                                 >> Radware / A10 / etc appliances\n>                                 which is a definition I agree with\n>                                 BTW.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> What I am trying to now understand\n>                                 is how we will move Octavia into\n>                                 >> the new LBaaS project?\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> If we do it later rather than\n>                                 develop Octavia in tree under the new\n>                                 >> incubated LBaaS project when do we\n>                                 plan to bring it in-tree from\n>                                 >> Stackforge? Kilo? Later? When LBaaS\n>                                 is a separate project under the\n>                                 >> Networking program?\n>                                 >\n>                                 >>\n>                                 >>\n>                                 >> What are the criteria to bring a\n>                                 driver into the LBaaS project and\n>                                 >> what do we need to do to replace\n>                                 the existing reference driver? Maybe\n>                                 >> adding a software driver to LBaaS\n>                                 source tree is less of a problem\n>                                 >> than converting a whole project to\n>                                 an OpenStack project.\n>                                 >\n>                                 >>\n>                                 >>\n>                                 >> Again I am open to both directions\n>                                 I just want to make sure we\n>                                 >> understand why we are choosing to\n>                                 do one or the other and that our\n>                                 >>  decision is based on data and not\n>                                 emotions.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> I am assuming that keeping Octavia\n>                                 in Stackforge will increase the\n>                                 >> velocity of the project and allow\n>                                 us more freedom which is goodness.\n>                                 >> We just need to have a plan to make\n>                                 it part of the Openstack LBaaS\n>                                 >> project.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> Regards Susanne\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >> On Sat, Aug 30, 2014 at 2:09 PM,\n>                                 Adam Harwell\n>                                 >> <adam.harwell at rackspace.com> wrote:\n>                                 >>         Only really have comments\n>                                 on two of your related points:\n>                                 >>\n>                                 >>\n>                                 >>         [Susanne] To me Octavia is\n>                                 a driver so it is very hard to me\n>                                 >>         to think of it as a\n>                                 standalone project. It needs the new\n>                                 >>         Neutron LBaaS v2 to\n>                                 function which is why I think of them\n>                                 >>         together. This of course\n>                                 can change since we can add whatever\n>                                 >>         layers we want to Octavia.\n>                                 >>\n>                                 >>\n>                                 >>         [Adam] I guess I\'ve always\n>                                 shared Stephen\'s\n>                                 >>         viewpoint ? Octavia !=\n>                                 LBaaS-v2. Octavia is a peer to F5 /\n>                                 >>         Radware / A10 /\n>                                 etcappliances, not to an Openstack API\n>                                 layer\n>                                 >>         like Neutron-LBaaS. It\'s a\n>                                 little tricky to clearly define\n>                                 >>         this difference in\n>                                 conversation, and I have noticed that\n>                                 quite\n>                                 >>         a few people are having the\n>                                 same issue differentiating. In a\n>                                 >>         small group, having quite a\n>                                 few people not on the same page is\n>                                 >>         a bit scary, so maybe we\n>                                 need to really sit down and map this\n>                                 >>         out so everyone is together\n>                                 one way or the other.\n>                                 >>\n>                                 >>\n>                                 \n>                                 >>         [Susanne] Ok now I am\n>                                 confused? But I agree with you that it\n>                                 >>         need to focus on our use\n>                                 cases. I remember us discussing\n>                                 >>         Octavia being the refenece\n>                                 implementation for OpenStack LBaaS\n>                                 >>         (whatever that is). Has\n>                                 that changed while I was on vacation?\n>                                 >>\n>                                 >>\n>                                 >>         [Adam] I believe that\n>                                 having the Octavia \"driver\" (not the\n>                                 >>         Octavia codebase itself,\n>                                 technically) become the reference\n>                                 >>         implementation for\n>                                 Neutron-LBaaS is still the plan in my\n>                                 eyes.\n>                                 >>         The Octavia Driver in\n>                                 Neutron-LBaaS is a separate bit of\n>                                 code\n>                                 >>         from the actual Octavia\n>                                 project, similar to the way the A10\n>                                 >>         driver is a separate bit of\n>                                 code from the A10 appliance. To do\n>                                 >>         that though, we need\n>                                 Octavia to be fairly close to fully\n>                                 >>         functional. I believe we\n>                                 can do this because even though the\n>                                 >>         reference driver would then\n>                                 require an additional service to\n>                                 >>         run, what it requires is\n>                                 still fully-open-source and (by way\n>                                 >>         of our plan) available as\n>                                 part of OpenStack core.\n>                                 >>\n>                                 >>\n>                                 >>         --Adam\n>                                 >>\n>                                 >>\n>                                 >>         https://keybase.io/rm_you\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>         From: Susanne Balle\n>                                 <sleipnir012 at gmail.com>\n>                                 >>         Reply-To: \"OpenStack\n>                                 Development Mailing List (not for\n>                                 usage\n>                                 >>         questions)\"\n>                                 <openstack-dev at lists.openstack.org>\n>                                 >>         Date: Friday, August 29,\n>                                 2014 9:19 AM\n>                                 >>         To: \"OpenStack Development\n>                                 Mailing List (not for usage\n>                                 >>         questions)\"\n>                                 <openstack-dev at lists.openstack.org>\n>                                 >>\n>                                 >>         Subject: Re:\n>                                 [openstack-dev]\n>                                 [neutron][lbaas][octavia]\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 Stephen\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 See inline\n>                                 comments.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 Susanne\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                  -----------------------------------------\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 Susanne--\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 I think you are\n>                                 conflating the difference between\n>                                 >>                 \"OpenStack\n>                                 incubation\" and \"Neutron incubator.\"\n>                                 These\n>                                 >>                 are two very\n>                                 different matters and should be\n>                                 treated\n>                                 >>                 separately. So,\n>                                 addressing each one individually:\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 \"OpenStack\n>                                 Incubation\"\n>                                 >>\n>                                 >>                 I think this has\n>                                 been the end-goal of Octavia all\n>                                 >>                 along and continues\n>                                 to be the end-goal. Under this\n>                                 >>                 scenario, Octavia\n>                                 is its own stand-alone project with\n>                                 >>                 its own PTL and\n>                                 core developer team, its own\n>                                 >>                 governance, and\n>                                 should eventually become part of the\n>                                 >>                 integrated\n>                                 OpenStack release. No project ever\n>                                 starts\n>                                 >>                 out as \"OpenStack\n>                                 incubated.\"\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 [Susanne] I totally\n>                                 agree that the end goal is for\n>                                 >>                 Neutron LBaaS to\n>                                 become its own incubated project. I\n>                                 >>                 did miss the nuance\n>                                 that was pointed out by Mestery in\n>                                 >>                 an earlier email\n>                                 that if a Neutron incubator project\n>                                 >>                 wants to become a\n>                                 separate project it will have to\n>                                 >>                 apply for\n>                                 incubation again or at that time. It\n>                                 was my\n>                                 >>                 understanding that\n>                                 such a Neutron incubated project\n>                                 >>                 would be\n>                                 grandfathered in but again we do not\n>                                 have\n>                                 >>                 much details on the\n>                                 process yet.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 To me Octavia is a\n>                                 driver so it is very hard to me to\n>                                 >>                 think of it as a\n>                                 standalone project. It needs the new\n>                                 >>                 Neutron LBaaS v2 to\n>                                 function which is why I think of\n>                                 >>                 them together. This\n>                                 of course can change since we can\n>                                 >>                 add whatever layers\n>                                 we want to Octavia.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 \"Neutron Incubator\"\n>                                 >>\n>                                 >>                 This has only\n>                                 become a serious discussion in the\n>                                 last\n>                                 >>                 few weeks and has\n>                                 yet to land, so there are many\n>                                 >>                 assumptions about\n>                                 this which don\'t pan out (either\n>                                 >>                 because of\n>                                 purposeful design and governance\n>                                 decisions,\n>                                 >>                 or because of how\n>                                 this project actually ends up being\n>                                 >>                 implemented from a\n>                                 practical standpoint). But given\n>                                 >>                 the inherent\n>                                 limitations about making statements\n>                                 with\n>                                 >>                 so many unknowns,\n>                                 the following seem fairly clear from\n>                                 >>                 what has been\n>                                 shared so far:\n>                                 >>\n>                                 >>                 ? Neutron incubator\n>                                 is the on-ramp for projects which\n>                                 >>                 should eventually\n>                                 become a part of Neutron itself.\n>                                 >>\n>                                 >>                 ? Projects which\n>                                 enter the Neutron incubator on-ramp\n>                                 >>                 should be fairly\n>                                 close to maturity in their final\n>                                 >>                 form. I think the\n>                                 intent here is for them to live in\n>                                 >>                 incubator for 1 or\n>                                 2 cycles before either being merged\n>                                 >>                 into Neutron core,\n>                                 or being ejected (as abandoned, or\n>                                 >>                 as a separate\n>                                 project).\n>                                 >>\n>                                 >>                 ? Neutron incubator\n>                                 projects effectively do not have\n>                                 >>                 their own PTL and\n>                                 core developer team, and do not have\n>                                 >>                 their own\n>                                 governance.\n>                                 >>\n>                                 >>                 [Susanne] Ok I\n>                                 missed the last point. In an earlier\n>                                 >>                 discussion Mestery\n>                                 implied that an incubated project\n>                                 >>                 would have at least\n>                                 one or two of its own cores. Maybe\n>                                 >>                 that changed\n>                                 between now and then.\n>                                 >>\n>                                 >>                 In addition we know\n>                                 the following about Neutron LBaaS\n>                                 >>                 and Octavia:\n>                                 >>\n>                                 >>                 ? It\'s already\n>                                 (informally?) agreed that the ultimate\n>                                 >>                 long-term place for\n>                                 a LBaaS solution is probably to be\n>                                 >>                 spun out into its\n>                                 own project, which might\n>                                 >>                 appropriately live\n>                                 under a yet-to-be-defined master\n>                                 >>                 \"Networking\"\n>                                 project. (This would make Neutron,\n>                                 LBaaS,\n>                                 >>                 VPNaaS, FWaaS, etc.\n>                                 effective \"peer\" projects under\n>                                 >>                 the Networking\n>                                 umbrella.)  Since this \"Networking\"\n>                                 >>                 umbrella project\n>                                 has even less defined about it than\n>                                 >>                 Neutron incubator,\n>                                 it\'s impossible to know whether\n>                                 >>                 being a part of\n>                                 Neutron incubator would be of any\n>                                 >>                 benefit to Octavia\n>                                 (or, conversely, to Neutron\n>                                 >>                 incubator) at all\n>                                 as an on-ramp to becoming part of\n>                                 >>                 \"Networking.\"\n>                                 Presumably, Octavia might fit well\n>                                 under\n>                                 >>                 the \"Networking\"\n>                                 umbrella-- but, again, with nothing\n>                                 >>                 defined there it\'s\n>                                 impossible to draw any reasonable\n>                                 >>                 conclusions at this\n>                                 time.\n>                                 >>\n>                                 >>                 [Susanne] We are in\n>                                 agreement here. This was the\n>                                 >>                 reasons we had the\n>                                 ad-hoc meeting in Atlanta so get a\n>                                 >>                 feel for hw people\n>                                 felt if we made Neutron LBaaS its\n>                                 >>                 own project and\n>                                 also how we got an operator large\n>                                 >>                 scale LBaaS that\n>                                 fit most of our service provider\n>                                 >>                 requirements. I am\n>                                 just worried because you keep on\n>                                 >>                 talking of Octavia\n>                                 as a standaloe project. To me it is\n>                                 >>                 an extension of\n>                                 Neutron LBaaS or of a new LBaaS ?. I\n>                                 >>                 do not see us (==\n>                                 me) use Octavia in a non OpenStack\n>                                 >>                 context. And yes it\n>                                 is a driver that I am hoping we\n>                                 >>                 all expect to\n>                                 become the reference implementation\n>                                 for\n>                                 >>                 LBaaS.\n>                                 >>\n>                                 >>                 ? When the LBaaS\n>                                 component spins out of Neutron, it\n>                                 >>                 will more than\n>                                 likely not be Octavia.  Octavia\n>                                 >>                 is intentionally\n>                                 less friendly to 3rd party load\n>                                 >>                 balancer vendors\n>                                 both because it\'s envisioned that\n>                                 >>                 Octavia would just\n>                                 be another implementation which\n>                                 >>                 lives along-side\n>                                 said 3rd party vendor products\n>                                 >>                 (plugging into a\n>                                 higher level LBaaS layer via a\n>                                 >>                 driver), and\n>                                 because we don\'t want to have to\n>                                 >>                 compromise certain\n>                                 design features of Octavia to meet\n>                                 >>                 the lowest common\n>                                 denominator 3rd party vendor\n>                                 >>                 product. (3rd party\n>                                 vendors are welcome, but we will\n>                                 >>                 not make design\n>                                 compromises to meet the needs of a\n>                                 >>                 proprietary\n>                                 product-- compatibility with available\n>                                 >>                 open-source\n>                                 products and standards trumps this.)\n>                                 >>\n>                                 \n>                                 >>                 [Susanne] Ok now I\n>                                 am confused? But I agree with you\n>                                 >>                 that it need to\n>                                 focus on our use cases. I remember us\n>                                 >>                 discussing Octavia\n>                                 being the refenece implementation\n>                                 >>                 for OpenStack LBaaS\n>                                 (whatever that is). Has that\n>                                 >>                 changed while I was\n>                                 on vacation?\n>                                 >>\n>                                 >>                 The end-game for\n>                                 the above point is: In the future I\n>                                 >>                 see \"Openstack\n>                                 LBaaS\" (or whatever the project calls\n>                                 >>                 itself) being a\n>                                 separate but complimentary project to\n>                                 >>                 Octavia.\n>                                 >>\n>                                 >>                 ? While its true\n>                                 that we would like Octavia to become\n>                                 >>                 the reference\n>                                 implementation for Neutron LBaaS, we\n>                                 are\n>                                 >>                 nowhere near being\n>                                 able to deliver on that. Attempting\n>                                 >>                 to become a part of\n>                                 Neutron LBaaS right now is likely\n>                                 >>                 just to create\n>                                 frustration (and very little merged\n>                                 >>                 code) for both the\n>                                 Octavia and Neutron teams.\n>                                 >>\n>                                 >>                 [Susanne] Agreed.\n>                                 >>\n>                                 >>                 So given that the\n>                                 only code in Octavia right now are a\n>                                 >>                 few database\n>                                 migrations, we are very, very far away\n>                                 >>                 from being ready\n>                                 for either OpenStack incubation or\n>                                 >>                 the Neutron\n>                                 incubator project. I don\'t think it\'s\n>                                 very\n>                                 >>                 useful to be\n>                                 spending time right now worrying about\n>                                 >>                 either of these\n>                                 outcomes:  We should be working on\n>                                 >>                 Octavia!\n>                                 >>\n>                                 >>                 [Susanne] Agreed.\n>                                 You suggested we discuss this on the\n>                                 >>                 ML NOW. I wanted to\n>                                 wait until the summit given that\n>                                 >>                 we would have more\n>                                 info on Neutron incubation, etc. I\n>                                 >>                 haven?t seen much\n>                                 written down on the Neutron\n>                                 >>                 incubator project\n>                                 so most of what we are doing is\n>                                 \n>                                 >>                 guessing?.\n>                                 >>\n>                                 >>                 Please also\n>                                 understand:  I realize that probably\n>                                 the\n>                                 >>                 reason you\'re\n>                                 asking this right now is because you\n>                                 >>                 have a mandate\n>                                 within your organization to use only\n>                                 >>                 \"official\"\n>                                 OpenStack branded components, and if\n>                                 >>                 Octavia doesn\'t\n>                                 fall within that category, you won\'t\n>                                 >>                 be able to use it.\n>                                 Of course everyone working on this\n>                                 >>                 project wants to\n>                                 make that happen too, so we\'re doing\n>                                 >>                 everything we can\n>                                 to make sure we don\'t jeopardize\n>                                 >>                 that possibility.\n>                                 And there are enough voices in this\n>                                 >>                 project that want\n>                                 that to happen, so I think if we\n>                                 >>                 strayed from the\n>                                 path to get there, there would be\n>                                 >>                 sufficient clangor\n>                                 over this that it would be hard to\n>                                 >>                 miss. But I don\'t\n>                                 think there\'s anyone at all at this\n>                                 >>                 time that can\n>                                 honestly give you a promise that\n>                                 Octavia\n>                                 >>                 definitely will be\n>                                 incubated and will definitely end\n>                                 >>                 up in the\n>                                 integrated OpenStack release.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 If you want to\n>                                 increase the chances of that\n>                                 happening,\n>                                 >>                 please help push\n>                                 the project forward!\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 [Susanne] That is\n>                                 what HP is doing. Remember we were\n>                                 >>                 here from the\n>                                 beginning helping change the direction\n>                                 >>                 for LBaaS.\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 Thanks,\n>                                 >>\n>                                 >>                 Stephen\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>\n>                                 >>                 On Thu, Aug 28,\n>                                 2014 at 9:52 PM, Stephen Balukoff\n>                                 >>\n>                                  <sbalukoff at bluebox.net> wrote:\n>                                 >>                         Susanne--\n>                                 >>\n>                                 >>\n>                                 >>                         I think you\n>                                 are conflating the difference\n>                                 >>                         between\n>                                 \"OpenStack incubation\" and \"Neutron\n>                                 >>                         incubator.\"\n>                                 These are two very different\n>                                 >>                         matters and\n>                                 should be treated separately. So,\n>                                 >>                         addressing\n>                                 each one individually:\n>                                 >>\n>                                 >>\n>                                 >>                         \"OpenStack\n>                                 Incubation\"\n>                                 >>                         I think\n>                                 this has been the end-goal of Octavia\n>                                 >>                         all along\n>                                 and continues to be the end-goal.\n>                                 >>                         Under this\n>                                 scenario, Octavia is its own\n>                                 >>                         stand-alone\n>                                 project with its own PTL and core\n>                                 >>                         developer\n>                                 team, its own governance, and should\n>                                 >>                         eventually\n>                                 become part of the integrated\n>                                 >>                         OpenStack\n>                                 release. No project ever starts out\n>                                 >>                         as\n>                                 \"OpenStack incubated.\"\n>                                 >>\n>                                 >>\n>                                 >>                         \"Neutron\n>                                 Incubator\"\n>                                 >>                         This has\n>                                 only become a serious discussion in\n>                                 >>                         the last\n>                                 few weeks and has yet to land, so\n>                                 >>                         there are\n>                                 many assumptions about this which\n>                                 >>                         don\'t pan\n>                                 out (either because of purposeful\n>                                 >>                         design and\n>                                 governance decisions, or because of\n>                                 >>                         how this\n>                                 project actually ends up being\n>                                 >>                         implemented\n>                                 from a practical standpoint). But\n>                                 >>                         given the\n>                                 inherent limitations about making\n>                                 >>                         statements\n>                                 with so many unknowns, the\n>                                 >>                         following\n>                                 seem fairly clear from what has been\n>                                 >>                         shared so\n>                                 far:\n>                                 >>                               *\n>                                 Neutron incubator is the on-ramp for\n>                                 >>\n>                                  projects which should eventually\n>                                 >>\n>                                  become a part of Neutron itself.\n>                                 >>                               *\n>                                 Projects which enter the Neutron\n>                                 >>\n>                                  incubator on-ramp should be fairly\n>                                 >>\n>                                  close to maturity in their final\n>                                 form.\n>                                 >>                                 I\n>                                 think the intent here is for them to\n>                                 >>\n>                                  live in incubator for 1 or 2 cycles\n>                                 >>\n>                                  before either being merged into\n>                                 >>\n>                                  Neutron core, or being ejected (as\n>                                 >>\n>                                  abandoned, or as a separate project).\n>                                 >>                               *\n>                                 Neutron incubator projects effectively\n>                                 >>                                 do\n>                                 not have their own PTL and core\n>                                 >>\n>                                  developer team, and do not have their\n>                                 >>                                 own\n>                                 governance.\n>                                 >>                         In addition\n>                                 we know the following about\n>                                 >>                         Neutron\n>                                 LBaaS and Octavia:\n>                                 >>                               *\n>                                 It\'s already (informally?) agreed that\n>                                 >>                                 the\n>                                 ultimate long-term place for a\n>                                 >>\n>                                  LBaaS solution is probably to be spun\n>                                 >>                                 out\n>                                 into its own project, which might\n>                                 >>\n>                                  appropriately live under a\n>                                 >>\n>                                  yet-to-be-defined master \"Networking\"\n>                                 >>\n>                                  project. (This would make Neutron,\n>                                 >>\n>                                  LBaaS, VPNaaS, FWaaS, etc. effective\n>                                 >>\n>                                  \"peer\" projects under the Networking\n>                                 >>\n>                                  umbrella.)  Since this \"Networking\"\n>                                 >>\n>                                  umbrella project has even less\n>                                 defined\n>                                 >>\n>                                  about it than Neutron incubator, it\'s\n>                                 >>\n>                                  impossible to know whether being a\n>                                 >>\n>                                  part of Neutron incubator would be of\n>                                 >>                                 any\n>                                 benefit to Octavia (or,\n>                                 >>\n>                                  conversely, to Neutron incubator) at\n>                                 >>                                 all\n>                                 as an on-ramp to becoming part of\n>                                 >>\n>                                  \"Networking.\" Presumably, Octavia\n>                                 >>\n>                                  might fit well under the \"Networking\"\n>                                 >>\n>                                  umbrella-- but, again, with nothing\n>                                 >>\n>                                  defined there it\'s impossible to draw\n>                                 >>                                 any\n>                                 reasonable conclusions at this\n>                                 >>\n>                                  time.\n>                                 >>                               *\n>                                 When the LBaaS component spins out of\n>                                 >>\n>                                  Neutron, it will more than likely not\n>                                 >>                                 be\n>                                 Octavia.  Octavia is intentionally\n>                                 >>\n>                                  less friendly to 3rd party load\n>                                 >>\n>                                  balancer vendors both because it\'s\n>                                 >>\n>                                  envisioned that Octavia would just be\n>                                 >>\n>                                  another implementation which lives\n>                                 >>\n>                                  along-side said 3rd party vendor\n>                                 >>\n>                                  products (plugging into a higher\n>                                 level\n>                                 >>\n>                                  LBaaS layer via a driver), and\n>                                 because\n>                                 >>                                 we\n>                                 don\'t want to have to compromise\n>                                 >>\n>                                  certain design features of Octavia to\n>                                 >>\n>                                  meet the lowest common denominator\n>                                 3rd\n>                                 >>\n>                                  party vendor product. (3rd party\n>                                 >>\n>                                  vendors are welcome, but we will not\n>                                 >>\n>                                  make design compromises to meet the\n>                                 >>\n>                                  needs of a proprietary product--\n>                                 >>\n>                                  compatibility with available\n>                                 >>\n>                                  open-source products and standards\n>                                 >>\n>                                  trumps this.)\n>                                 >>                               * The\n>                                 end-game for the above point is:\n>                                 >>                                 In\n>                                 the future I see \"Openstack\n>                                 >>\n>                                  LBaaS\" (or whatever the project calls\n>        ','<CADBYD+zVCqWuXcahWTfUCbHgYSq==14w4T1wS-f9DMP-B1qQGg@mail.gmail.com>',NULL),('<1409684705.3820.18.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 19:02:25',0,'2014-09-02 19:02:25',NULL,'[openstack-dev] [neutron][lbaas][octavia]','Stephen actually has a trademark request in for Octavia.  It apparently\nwas not trademarks prior to his request.\n\nOn Tue, 2014-09-02 at 20:28 +0200, Salvatore Orlando wrote:\n> Inline.\n> Salvatore\n> \n> On 2 September 2014 19:46, Stephen Balukoff <sbalukoff at bluebox.net>\n> wrote:\n>         For what it\'s worth in this discussion, I agree that the\n>         possible futures of Octavia already discussed (where it lives,\n>         how it relates to Neutron LBaaS, etc.) are all possible. What\n>         actually happens here is going to depend both on the Octavia\n>         team, the Neutron team (especially when it comes to how the\n>         neutron-incubator is practically managed), and anyone else\n>         interested in contributing to these projects.\n>         \n>         \n>         Again, for now, I think it\'s most important to get involved,\n>         write code, and start delivering on the immediate, obvious\n>         things that need to be done for Octavia.\n> \n> \n> Probably... at least we\'ll be speculating about something which\n> actually exists.\n>  \n>         \n>         \n>         In my mind, there are too many unknowns to predict exactly\n>         where things will end up in the long run. About the only thing\n>         I am certain of is that everyone involving themselves in the\n>         Octavia project wants to see it become a part of OpenStack (in\n>         whatever way that happens), and that that will certainly not\n>         happen if we aren\'t able to build the operator-scale load\n>         balancer we all want.\n>         \n>         \n>         Beyond that, I don\'t see a whole lot of point to the\n>         speculation here. :/  (Maybe someone can enlighten me to this\n>         point?)\n> \n> \n> I have speculated only to the extent that it was needed for me to\n> understand what\'s the interface between the two things.\n> Beyond that, I agree and have already pointed out that there is no\n> urgency for prolonging this discussion, unless the lbaas and octavia\n> team feel this will have a bearing on short term developments. I don\'t\n> think so but I do not have the full picture.\n> \n> \n> Talking about pointless things you might want to ensure the name\n> \'octavia\' is not trademarked before writing lots of code! Renames are\n> painful and some openstack projects (like neutron and zaqar) know\n> something about that.\n>  \n> \n>         \n>         \n>         Stephen\n>         \n>         \n>         \n>         \n>         On Tue, Sep 2, 2014 at 9:40 AM, Brandon Logan\n>         <brandon.logan at rackspace.com> wrote:\n>                 Hi Susanne,\n>                 \n>                 I believe the options for Octavia are:\n>                 1) Merge into the LBaaS tree (wherever LBaaS is)\n>                 2) Become its own openstack project\n>                 3) Remains in stackforge for eternity\n>                 \n>                 #1 Is dependent on these options\n>                 1) LBaaS V2 graduates from the incubator into Neutron.\n>                 V1 is deprecated.\n>                 2) LBaaS V2 remains in incubator until it can be spun\n>                 out.  V1 in\n>                 Neutron is deprecated.\n>                 3) LBaaS V2 is abandoned in the incubator and LBaaS V1\n>                 remains.  (An\n>                 unlikely option)\n>                 \n>                 I don\'t see any other feasible options.\n>                 \n>                 On Tue, 2014-09-02 at 12:06 -0400, Susanne Balle\n>                 wrote:\n>                 > Doug\n>                 >\n>                 >\n>                 > I agree with you but I need to understand the\n>                 options. Susanne\n>                 >\n>                 >\n>                 > >> And I agree with Brandon?s sentiments.  We need\n>                 to get something\n>                 > built before I?m going to worry too\n>                 > >> much about where it should live.  Is this a\n>                 candidate to get sucked\n>                 > into LBaaS?  Sure.  Could the reverse\n>                 > >> happen?  Sure.  Let?s see how it develops.\n>                 >\n>                 >\n>                 >\n>                 > On Tue, Sep 2, 2014 at 11:45 AM, Doug Wiegley\n>                 <dougw at a10networks.com>\n>                 > wrote:\n>                 >         Hi all,\n>                 >\n>                 >\n>                 >         > On the other hand one could also say that\n>                 Octavia is the ML2\n>                 >         equivalent of LBaaS. The equivalence here is\n>                 very loose.\n>                 >         Octavia would be a service-VM framework for\n>                 doing load\n>                 >         balancing using a variety of drivers. The\n>                 drivers ultimately\n>                 >         are in charge of using backends like haproxy\n>                 or nginx running\n>                 >         on the service VM to implement lbaas\n>                 configuration.\n>                 >\n>                 >\n>                 >         This, exactly.  I think it?s much fairer to\n>                 define Octavia as\n>                 >         an LBaaS purpose-built service vm framework,\n>                 which will use\n>                 >         nova and haproxy initially to provide a\n>                 highly scalable\n>                 >         backend. But before we get into terminology\n>                 misunderstandings,\n>                 >         there are a bunch of different ?drivers? at\n>                 play here, exactly\n>                 >         because this is a framework:\n>                 \n>                 >               * Neutron lbaas drivers ? what we all\n>                 know and love\n>                 >               * Octavia?s ?network driver? - this is\n>                 a piece of glue\n>                 >                 that exists to hide internal calls\n>                 we have to make\n>                 >                 into Neutron until clean interfaces\n>                 exist.  It might\n>                 >                 be a no-op in the case of an actual\n>                 neutron lbaas\n>                 >                 driver, which could serve that\n>                 function instead.\n>                 \n>                 >               * Octavia?s ?vm driver? - this is a\n>                 piece of glue\n>                 >                 between the octavia controller and\n>                 the nova VMs that\n>                 >                 are doing the load balancing.\n>                 \n>                 >               * Octavia?s ?compute driver? - you\n>                 guessed it, an\n>                 >                 abstraction to Nova and its\n>                 scheduler.\n>                 >         Places that can be the ?front-end? for\n>                 Octavia:\n>                 \n>                 >               * Neutron LBaaS v2 driver\n>                 >               * Neutron LBaaS v1 driver\n>                 \n>                 >               * It?s own REST API\n>                 >         Things that could have their own VM drivers:\n>                 \n>                 >               * haproxy, running inside nova\n>                 >               * Nginx, running inside nova\n>                 \n>                 >               * Anything else you want, running\n>                 inside any hypervisor\n>                 >                 you want\n>                 >               * Vendor soft appliances\n>                 >               * Null-out the VM calls and go\n>                 straight to some other\n>                 >                 backend?  Sure, though I?m not sure\n>                 I?d see the point.\n>                 >         There are quite a few synergies with other\n>                 efforts, and we?re\n>                 >         monitoring them, but not waiting for any of\n>                 them.\n>                 >\n>                 >\n>                 >         And I agree with Brandon?s sentiments.  We\n>                 need to get\n>                 >         something built before I?m going to worry\n>                 too much about where\n>                 >         it should live.  Is this a candidate to get\n>                 sucked into\n>                 >         LBaaS?  Sure.  Could the reverse happen?\n>                 Sure.  Let?s see how\n>                 >         it develops.\n>                 >\n>                 >\n>                 >         Incidentally, we are currently having a\n>                 debate over the use of\n>                 >         the term ?vm? (and ?vm driver?) as the name\n>                 to describe\n>                 >         octavia?s backends.  Feel free to chime in\n>                 >         here:\n>                 https://review.openstack.org/#/c/117701/\n>                 >\n>                 >\n>                 >         Thanks,\n>                 >         doug\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >         From: Salvatore Orlando\n>                 <sorlando at nicira.com>\n>                 >\n>                 >         Reply-To: \"OpenStack Development Mailing\n>                 List (not for usage\n>                 >         questions)\"\n>                 <openstack-dev at lists.openstack.org>\n>                 >\n>                 >         Date: Tuesday, September 2, 2014 at 9:05 AM\n>                 >\n>                 >         To: \"OpenStack Development Mailing List (not\n>                 for usage\n>                 >         questions)\"\n>                 <openstack-dev at lists.openstack.org>\n>                 >         Subject: Re: [openstack-dev]\n>                 [neutron][lbaas][octavia]\n>                 >\n>                 >\n>                 >\n>                 >         Hi Susanne,\n>                 >\n>                 >\n>                 >         I\'m just trying to gain a good understanding\n>                 of the situation\n>                 >         here.\n>                 >         More comments and questions inline.\n>                 >\n>                 >\n>                 >         Salvatore\n>                 >\n>                 >         On 2 September 2014 16:34, Susanne Balle\n>                 >         <sleipnir012 at gmail.com> wrote:\n>                 >                 Salvatore\n>                 >\n>                 >\n>                 >                 Thanks for your clarification below\n>                 around the\n>                 >                 blueprint.\n>                 >\n>                 >\n>                 >                 > For LBaaS v2 therefore the\n>                 relationship between it\n>                 >                 and Octavia should be the same as\n>                 with any other\n>                 >                 > backend. I see Octavia has a\n>                 blueprint for a\n>                 >                 \"network driver\" - and the derivable\n>                 of that should\n>                 >                 definitely be\n>                 >                 > part of the LBaaS project.\n>                 >\n>                 >\n>                 >                 > For the rest, it would seem a bit\n>                 strange to me if\n>                 >                 the LBaaS project incorporated a\n>                 backend as well.\n>                 >                 After\n>                 >\n>                 >                 > all, LBaaS v1 did not incorporate\n>                 haproxy!\n>                 >                 > Also, as Adam points out, Nova\n>                 does not incorporate\n>                 >                 an Hypervisor.\n>                 >\n>                 >\n>                 >                 In my vision Octavia is a LBaaS\n>                 framework that should\n>                 >                 not be tied to ha-proxy. The\n>                 interfaces should be\n>                 >                 clean and at a high enough level\n>                 that we can switch\n>                 >                 load-balancer. We should be able to\n>                 switch the\n>                 >                 load-balancer to nginx so to me the\n>                 analogy is more\n>                 >                 Octavia+LBaaSV2 == nova and\n>                 hypervisor ==\n>                 >                 load-balancer.\n>                 >\n>                 >\n>                 >         Indeed I said that it would have been\n>                 initially tied to\n>                 >         haproxy considering the blueprints currently\n>                 defined for\n>                 >         octavia, but I\'m sure the solution could\n>                 leverage nginx or\n>                 >         something else in the future.\n>                 >\n>                 >\n>                 >         I think however it is correct to say that\n>                 LBaaS v2 will have\n>                 >         an Octavia driver on par with A10, radware,\n>                 nestscaler and\n>                 >         others.\n>                 >         (Correct me if I\'m wrong) On the other hand\n>                 Octavia, within\n>                 >         its implementation, might use different\n>                 drivers - for instance\n>                 >         nginx or haproxy. And in theory it cannot be\n>                 excluded that the\n>                 >         same appliance might implement some vips\n>                 using haproxy and\n>                 >         others using nginx.\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >                 I am not sure the group is in\n>                 agreement on the\n>                 >                 definition I just wrote. Also going\n>                 back the\n>                 >                 definition of Octavia being a\n>                 backend then I agree\n>                 >                 that we should write a blueprint to\n>                 incorporate\n>                 >                 Octavia as a network driver.\n>                 >\n>                 >\n>                 >         What about this blueprint?\n>                 >\n>                  https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver\n>                 >\n>                 >\n>                 >\n>                 >                 I guess I had always envisioned what\n>                 we now call\n>                 >                 Octavia to be part of the LBaaS\n>                 service itself and\n>                 >                 have ha-proxy, nginx be the drivers\n>                 and not have the\n>                 >                 driver level be at the Octavia\n>                 cut-over point, Given\n>                 >                 this new \"design\" I am now wondering\n>                 why we didn\'t\n>                 >                 just write a driver for Libra and\n>                 improved on Libra\n>                 >                 since to me that is the now the\n>                 driver level we are\n>                 >                 discussing.\n>                 >\n>                 >\n>                 >         Octavia could be part of the lbaas service\n>                 just like neutron\n>                 >         has a set of agents which at the end of the\n>                 day provide a\n>                 >         L2/L3 network virtualization service.\n>                 Personally I\'m of the\n>                 >         opinion that I would move that code in a\n>                 separate repo which\n>                 >         could be maintained by networking experts (I\n>                 can barely plug\n>                 >         an ethernet cable into a switch). But the\n>                 current situation\n>                 >         creates a case for Octavia inclusion in\n>                 lbaas.\n>                 >\n>                 >\n>                 >         On the other hand one could also say that\n>                 Octavia is the ML2\n>                 >         equivalent of LBaaS. The equivalence here is\n>                 very loose.\n>                 >         Octavia would be a service-VM framework for\n>                 doing load\n>                 >         balancing using a variety of drivers. The\n>                 drivers ultimately\n>                 >         are in charge of using backends like haproxy\n>                 or nginx running\n>                 >         on the service VM to implement lbaas\n>                 configuration.\n>                 >         To avoid further discussion it might be\n>                 better to steer away\n>                 >         from discussing overlaps and synergies with\n>                 the service VM\n>                 >         project, at least for now.\n>                 >\n>                 >\n>                 >         I think the ability of having the Libra\n>                 driver was discussed\n>                 >         in the past. I do not know the details, but\n>                 it seemed there\n>                 >         was not a lot to gain from having a Neutron\n>                 LBaaS driver\n>                 >         pointing to libra (ie: it was much easier to\n>                 just deploy libra\n>                 >         instead of neutron lbaas).\n>                 >\n>                 >\n>                 >         Summarising, so far I haven\'t yet an opinion\n>                 regarding where\n>                 >         Octavia will sit.\n>                 >         Nevertheless I think this is a discussion\n>                 that it\'s useful for\n>                 >         the medium/long term - it does not seem to\n>                 me that there is an\n>                 >         urgency here.\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >\n>                 >                 Regards Susanne\n>                 >\n>                 >\n>                 >                 On Tue, Sep 2, 2014 at 9:18 AM,\n>                 Salvatore Orlando\n>                 >                 <sorlando at nicira.com> wrote:\n>                 >                         Some more comments from me\n>                 inline.\n>                 >\n>                 >                         Salvatore\n>                 >\n>                 >\n>                 >                         On 2 September 2014 11:06,\n>                 Adam Harwell\n>                 >                         <adam.harwell at rackspace.com>\n>                 wrote:\n>                 >                                 I also agree with\n>                 most of what Brandon\n>                 >                                 said, though I am\n>                 slightly\n>                 >                                 concerned by the\n>                 talk of merging\n>                 >                                 Octavia and\n>                 [Neutron-]LBaaS-v2\n>                 >                                 codebases.\n>                 >\n>                 >\n>                 >                         Beyond all the reasons\n>                 listed in this thread -\n>                 >                         merging codebases is always\n>                 more difficult\n>                 >                         that what it seems!\n>                 >                         Also it seems to me there\'s\n>                 not yet a clear\n>                 >                         path for LBaaS v2. Mostly\n>                 because of the\n>                 >                         ongoing neutron incubator\n>                 discussion.\n>                 >                         However in my opinion there\n>                 are 3 paths (and I\n>                 >                         have no idea whether they\n>                 might be applicable\n>                 >                         to Octavia as a standalone\n>                 project).\n>                 >                         1) Aim at becoming part of\n>                 neutron via the\n>                 >                         incubator or any equivalent\n>                 mechanisms\n>                 >                         2) Evolve in loosely coupled\n>                 fashion with\n>                 >                         neutron, but still be part\n>                 of the networking\n>                 >                         program. (This means that\n>                 LBaaS APIs will be\n>                 >                         part of Openstack Network\n>                 APIs)\n>                 >                         3) Evolve independently from\n>                 neutron, and\n>                 >                         become part of a new\n>                 program. I have no idea\n>                 >                         however whether there\'s\n>                 enough material to\n>                 >                         have a \"load balancing\"\n>                 program, and what\n>                 >                         would be the timeline for\n>                 that.\n>                 >\n>                 >\n>                 >\n>                 >                                 [blogan] \"I think\n>                 the best course of\n>                 >                                 action is to get\n>                 Octavia itself into\n>                 >                                 the same codebase as\n>                 LBaaS (Neutron or\n>                 >                                 spun out).\"\n>                 >\n>                 >                                 [sballe] \"What I am\n>                 trying to now\n>                 >                                 understand is how we\n>                 will move Octavia\n>                 >                                 into the new LBaaS\n>                 project?\"\n>                 >\n>                 >\n>                 >\n>                 >                                 I didn\'t think that\n>                 was ever going to\n>                 >                                 be the plan -- sure,\n>                 we\'d have an\n>                 >                                 Octavia driver that\n>                 is part of the\n>                 >                                 [Neutron-]LBaaS-v2\n>                 codebase (which\n>                 >                                 Susanne did mention\n>                 as well), but\n>                 >                                 nothing more than\n>                 that. The actual\n>                 >                                 Octavia code would\n>                 still be in its own\n>                 >                                 project at the end\n>                 of all of this,\n>                 >                                 right? The driver\n>                 code could be added\n>                 >                                 to\n>                 [Neutron-]LbaaS-v2 at any point\n>                 >                                 once Octavia is\n>                 mature enough to be\n>                 >                                 used, just by\n>                 submitting it as a CR, I\n>                 >                                 believe. Doug might\n>                 be able to comment\n>                 >                                 on that, since he\n>                 maintains the A10\n>                 >                                 driver?\n>                 >\n>                 >\n>                 >                         From what I gathered so far\n>                 Octavia is a fully\n>                 >                         fledged load balancing\n>                 virtual appliance which\n>                 >                         (at least in its first\n>                 iterations) will\n>                 >                         leverage haproxy.\n>                 >                         As also stated earlier in\n>                 this thread it\'s a\n>                 >                         peer of commercial\n>                 appliances from various\n>                 >                         vendors.\n>                 >\n>                 >\n>                 >                         For LBaaS v2 therefore the\n>                 relationship\n>                 >                         between it and Octavia\n>                 should be the same as\n>                 >                         with any other backend. I\n>                 see Octavia has a\n>                 >                         blueprint for a \"network\n>                 driver\" - and the\n>                 >                         derivable of that should\n>                 definitely be part of\n>                 >                         the LBaaS project.\n>                 >                         For the rest, it would seem\n>                 a bit strange to\n>                 >                         me if the LBaaS project\n>                 incorporated a backend\n>                 >                         as well. After all, LBaaS v1\n>                 did not\n>                 >                         incorporate haproxy!\n>                 >                         Also, as Adam points out,\n>                 Nova does not\n>                 >                         incorporate an Hypervisor.\n>                 >\n>                 >\n>                 >                                 Also, I know I\'m\n>                 opening this same can\n>                 >                                 of worms again, but\n>                 I am curious\n>                 >                                 about the HP mandate\n>                 that \"everything\n>                 >                                 must be OpenStack\"\n>                 when it comes to\n>                 >                                 Octavia. Since HP\'s\n>                 offering would be\n>                 >\n>                  \"[Neutron-]LBaaS-v2\", which happens\n>                 >                                 to use Octavia as a\n>                 backend, does it\n>                 >                                 matter whether\n>                 Octavia is an official\n>                 >                                 OpenStack project**?\n>                 If HP can offer\n>                 >                                 Cloud Compute\n>                 through Nova, and Nova\n>                 >                                 uses some hypervisor\n>                 like Xen or KVM\n>                 >                                 (neither of which\n>                 are a part of\n>                 >                                 OpenStack), I am not\n>                 sure how it is\n>                 >                                 different to offer\n>                 Cloud Load\n>                 >                                 Balancing via\n>                 [Neutron-]LBaaS-v2 which\n>                 >                                 could be using a\n>                 non-Openstack\n>                 >                                 implementation for\n>                 the backend. I\n>                 >                                 don\'t see \"Octavia\n>                 needs to be in\n>                 >                                 Openstack\" as a\n>                 blocker so long as the\n>                 >                                 \"LBaaS API\" is part\n>                 of OpenStack.\n>                 >\n>                 >                                 **NOTE: I AM\n>                 DEFINITELY STILL IN FAVOR\n>                 >                                 OF OCTAVIA BEING AN\n>                 OPENSTACK\n>                 >                                 PROJECT. THIS IS\n>                 JUST AN EXAMPLE FOR\n>                 >                                 THE SAKE OF THIS\n>                 PARTICULAR ARGUMENT.\n>                 >                                 PLEASE DON\'T THINK\n>                 THAT I\'M AGAINST\n>                 >                                 OCTAVIA BEING\n>                 OFFICIALLY INCUBATED!**\n>                 >\n>                 >\n>                 >                                  --Adam\n>                 >\n>                 >\n>                 >\n>                  https://keybase.io/rm_you\n>                 >\n>                 >\n>                 >\n>                 >                                 On 9/1/14 10:12 PM,\n>                 \"Brandon Logan\"\n>                 >\n>                  <brandon.logan at RACKSPACE.COM> wrote:\n>                 >\n>                 >                                 >Hi Susanne and\n>                 everyone,\n>                 >                                 >\n>                 >                                 >My opinions are\n>                 that keeping it in\n>                 >                                 stackforge until it\n>                 gets mature is\n>                 >                                 >the best solution.\n>                 I\'m pretty sure\n>                 >                                 we can all agree on\n>                 that.  Whenever\n>                 >                                 >it is mature then,\n>                 and only then, we\n>                 >                                 should try to get it\n>                 into openstack\n>                 >                                 >one way or another.\n>                 If Neutron LBaaS\n>                 >                                 v2 is still\n>                 incubated then it\n>                 >                                 >should be\n>                 relatively easy to get it\n>                 >                                 in that codebase.\n>                 If Neutron LBaaS\n>                 >                                 >has already spun\n>                 out, even easier for\n>                 >                                 us.  If we want\n>                 Octavia to just\n>                 >                                 >become an openstack\n>                 project all its\n>                 >                                 own then that will\n>                 be the difficult\n>                 >                                 >part.\n>                 >                                 >\n>                 >                                 >I think the best\n>                 course of action is\n>                 >                                 to get Octavia\n>                 itself into the same\n>                 >                                 >codebase as LBaaS\n>                 (Neutron or spun\n>                 >                                 out).  They do go\n>                 together, and the\n>                 >                                 >maintainers will\n>                 almost always be the\n>                 >                                 same for both.  This\n>                 makes even\n>                 >                                 >more sense when\n>                 LBaaS is spun out\n>                 >                                 into its own\n>                 project.\n>                 >                                 >\n>                 >                                 >I really think all\n>                 of the answers to\n>                 >                                 these questions will\n>                 fall into\n>                 >                                 >place when we\n>                 actually deliver a\n>                 >                                 product that we are\n>                 all wanting and\n>                 >                                 >talking about\n>                 delivering with\n>                 >                                 Octavia.  Once we\n>                 prove that we can\n>                 >                                 all\n>                 >                                 >come together as a\n>                 community and\n>                 >                                 manage a product\n>                 from inception to\n>                 >                                 >maturity, we will\n>                 then have the\n>                 >                                 respect and trust to\n>                 do what is best\n>                 >                                 for\n>                 >                                 >an Openstack LBaaS\n>                 product.\n>                 >                                 >\n>                 >                                 >Thanks,\n>                 >                                 >Brandon\n>                 >                                 >\n>                 >                                 >On Mon, 2014-09-01\n>                 at 10:18 -0400,\n>                 >                                 Susanne Balle wrote:\n>                 >                                 >> Kyle, Adam,\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> Based on this\n>                 thread Kyle is\n>                 >                                 suggesting the\n>                 follow moving forward\n>                 >                                 >> plan:\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> 1) We incubate\n>                 Neutron LBaaS V2 in\n>                 >                                 the ?Neutron?\n>                 incubator ?and freeze\n>                 >                                 >> LBaas V1.0?\n>                 >                                 >> 2) ?Eventually?\n>                 It graduates into a\n>                 >                                 project under the\n>                 networking\n>                 >                                 >> program.\n>                 >                                 >> 3) ?At that\n>                 point? We deprecate\n>                 >                                 Neutron LBaaS v1.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> The words in ?xx?\n>                 are works I added\n>                 >                                 to make sure I/We\n>                 understand the\n>                 >                                 >> whole picture.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> And as Adam\n>                 mentions: Octavia !=\n>                 >                                 LBaaS-v2. Octavia is\n>                 a peer to F5 /\n>                 >                                 >> Radware / A10 /\n>                 etc appliances\n>                 >                                 which is a\n>                 definition I agree with\n>                 >                                 BTW.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> What I am trying\n>                 to now understand\n>                 >                                 is how we will move\n>                 Octavia into\n>                 >                                 >> the new LBaaS\n>                 project?\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> If we do it later\n>                 rather than\n>                 >                                 develop Octavia in\n>                 tree under the new\n>                 >                                 >> incubated LBaaS\n>                 project when do we\n>                 >                                 plan to bring it\n>                 in-tree from\n>                 >                                 >> Stackforge? Kilo?\n>                 Later? When LBaaS\n>                 >                                 is a separate\n>                 project under the\n>                 >                                 >> Networking\n>                 program?\n>                 >                                 >\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> What are the\n>                 criteria to bring a\n>                 >                                 driver into the\n>                 LBaaS project and\n>                 >                                 >> what do we need\n>                 to do to replace\n>                 >                                 the existing\n>                 reference driver? Maybe\n>                 >                                 >> adding a software\n>                 driver to LBaaS\n>                 >                                 source tree is less\n>                 of a problem\n>                 >                                 >> than converting a\n>                 whole project to\n>                 >                                 an OpenStack\n>                 project.\n>                 >                                 >\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> Again I am open\n>                 to both directions\n>                 >                                 I just want to make\n>                 sure we\n>                 >                                 >> understand why we\n>                 are choosing to\n>                 >                                 do one or the other\n>                 and that our\n>                 >                                 >>  decision is\n>                 based on data and not\n>                 >                                 emotions.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> I am assuming\n>                 that keeping Octavia\n>                 >                                 in Stackforge will\n>                 increase the\n>                 >                                 >> velocity of the\n>                 project and allow\n>                 >                                 us more freedom\n>                 which is goodness.\n>                 >                                 >> We just need to\n>                 have a plan to make\n>                 >                                 it part of the\n>                 Openstack LBaaS\n>                 >                                 >> project.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> Regards Susanne\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >> On Sat, Aug 30,\n>                 2014 at 2:09 PM,\n>                 >                                 Adam Harwell\n>                 >                                 >>\n>                 <adam.harwell at rackspace.com> wrote:\n>                 >                                 >>         Only\n>                 really have comments\n>                 >                                 on two of your\n>                 related points:\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>         [Susanne]\n>                 To me Octavia is\n>                 >                                 a driver so it is\n>                 very hard to me\n>                 >                                 >>         to think\n>                 of it as a\n>                 >                                 standalone project.\n>                 It needs the new\n>                 >                                 >>         Neutron\n>                 LBaaS v2 to\n>                 >                                 function which is\n>                 why I think of them\n>                 >                                 >>         together.\n>                 This of course\n>                 >                                 can change since we\n>                 can add whatever\n>                 >                                 >>         layers we\n>                 want to Octavia.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>         [Adam] I\n>                 guess I\'ve always\n>                 >                                 shared Stephen\'s\n>                 >                                 >>         viewpoint\n>                 ? Octavia !=\n>                 >                                 LBaaS-v2. Octavia is\n>                 a peer to F5 /\n>                 >                                 >>         Radware /\n>                 A10 /\n>                 >                                 etcappliances, not\n>                 to an Openstack API\n>                 >                                 layer\n>                 >                                 >>         like\n>                 Neutron-LBaaS. It\'s a\n>                 >                                 little tricky to\n>                 clearly define\n>                 >                                 >>         this\n>                 difference in\n>                 >                                 conversation, and I\n>                 have noticed that\n>                 >                                 quite\n>                 >                                 >>         a few\n>                 people are having the\n>                 >                                 same issue\n>                 differentiating. In a\n>                 >                                 >>         small\n>                 group, having quite a\n>                 >                                 few people not on\n>                 the same page is\n>                 >                                 >>         a bit\n>                 scary, so maybe we\n>                 >                                 need to really sit\n>                 down and map this\n>                 >                                 >>         out so\n>                 everyone is together\n>                 >                                 one way or the\n>                 other.\n>                 >                                 >>\n>                 >                                 >>\n>                 >\n>                 >                                 >>         [Susanne]\n>                 Ok now I am\n>                 >                                 confused? But I\n>                 agree with you that it\n>                 >                                 >>         need to\n>                 focus on our use\n>                 >                                 cases. I remember us\n>                 discussing\n>                 >                                 >>         Octavia\n>                 being the refenece\n>                 >                                 implementation for\n>                 OpenStack LBaaS\n>                 >                                 >>         (whatever\n>                 that is). Has\n>                 >                                 that changed while I\n>                 was on vacation?\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>         [Adam] I\n>                 believe that\n>                 >                                 having the Octavia\n>                 \"driver\" (not the\n>                 >                                 >>         Octavia\n>                 codebase itself,\n>                 >                                 technically) become\n>                 the reference\n>                 >                                 >>\n>                  implementation for\n>                 >                                 Neutron-LBaaS is\n>                 still the plan in my\n>                 >                                 eyes.\n>                 >                                 >>         The\n>                 Octavia Driver in\n>                 >                                 Neutron-LBaaS is a\n>                 separate bit of\n>                 >                                 code\n>                 >                                 >>         from the\n>                 actual Octavia\n>                 >                                 project, similar to\n>                 the way the A10\n>                 >                                 >>         driver is\n>                 a separate bit of\n>                 >                                 code from the A10\n>                 appliance. To do\n>                 >                                 >>         that\n>                 though, we need\n>                 >                                 Octavia to be fairly\n>                 close to fully\n>                 >                                 >>\n>                  functional. I believe we\n>                 >                                 can do this because\n>                 even though the\n>                 >                                 >>         reference\n>                 driver would then\n>                 >                                 require an\n>                 additional service to\n>                 >                                 >>         run, what\n>                 it requires is\n>                 >                                 still\n>                 fully-open-source and (by way\n>                 >                                 >>         of our\n>                 plan) available as\n>                 >                                 part of OpenStack\n>                 core.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>         --Adam\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  https://keybase.io/rm_you\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>         From:\n>                 Susanne Balle\n>                 >\n>                  <sleipnir012 at gmail.com>\n>                 >                                 >>         Reply-To:\n>                 \"OpenStack\n>                 >                                 Development Mailing\n>                 List (not for\n>                 >                                 usage\n>                 >                                 >>\n>                  questions)\"\n>                 >\n>                  <openstack-dev at lists.openstack.org>\n>                 >                                 >>         Date:\n>                 Friday, August 29,\n>                 >                                 2014 9:19 AM\n>                 >                                 >>         To:\n>                 \"OpenStack Development\n>                 >                                 Mailing List (not\n>                 for usage\n>                 >                                 >>\n>                  questions)\"\n>                 >\n>                  <openstack-dev at lists.openstack.org>\n>                 >                                 >>\n>                 >                                 >>         Subject:\n>                 Re:\n>                 >                                 [openstack-dev]\n>                 >\n>                  [neutron][lbaas][octavia]\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  Stephen\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  See inline\n>                 >                                 comments.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  Susanne\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >\n>                 -----------------------------------------\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  Susanne--\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>                 I\n>                 think you are\n>                 >                                 conflating the\n>                 difference between\n>                 >                                 >>\n>                  \"OpenStack\n>                 >                                 incubation\" and\n>                 \"Neutron incubator.\"\n>                 >                                 These\n>                 >                                 >>\n>                  are two very\n>                 >                                 different matters\n>                 and should be\n>                 >                                 treated\n>                 >                                 >>\n>                  separately. So,\n>                 >                                 addressing each one\n>                 individually:\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  \"OpenStack\n>                 >                                 Incubation\"\n>                 >                                 >>\n>                 >                                 >>                 I\n>                 think this has\n>                 >                                 been the end-goal of\n>                 Octavia all\n>                 >                                 >>\n>                  along and continues\n>                 >                                 to be the end-goal.\n>                 Under this\n>                 >                                 >>\n>                  scenario, Octavia\n>                 >                                 is its own\n>                 stand-alone project with\n>                 >                                 >>\n>                  its own PTL and\n>                 >                                 core developer team,\n>                 its own\n>                 >                                 >>\n>                  governance, and\n>                 >                                 should eventually\n>                 become part of the\n>                 >                                 >>\n>                  integrated\n>                 >                                 OpenStack release.\n>                 No project ever\n>                 >                                 starts\n>                 >                                 >>\n>                  out as \"OpenStack\n>                 >                                 incubated.\"\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  [Susanne] I totally\n>                 >                                 agree that the end\n>                 goal is for\n>                 >                                 >>\n>                  Neutron LBaaS to\n>                 >                                 become its own\n>                 incubated project. I\n>                 >                                 >>\n>                  did miss the nuance\n>                 >                                 that was pointed out\n>                 by Mestery in\n>                 >                                 >>\n>                  an earlier email\n>                 >                                 that if a Neutron\n>                 incubator project\n>                 >                                 >>\n>                  wants to become a\n>                 >                                 separate project it\n>                 will have to\n>                 >                                 >>\n>                  apply for\n>                 >                                 incubation again or\n>                 at that time. It\n>                 >                                 was my\n>                 >                                 >>\n>                  understanding that\n>                 >                                 such a Neutron\n>                 incubated project\n>                 >                                 >>\n>                  would be\n>                 >                                 grandfathered in but\n>                 again we do not\n>                 >                                 have\n>                 >                                 >>\n>                  much details on the\n>                 >                                 process yet.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  To me Octavia is a\n>                 >                                 driver so it is very\n>                 hard to me to\n>                 >                                 >>\n>                  think of it as a\n>                 >                                 standalone project.\n>                 It needs the new\n>                 >                                 >>\n>                  Neutron LBaaS v2 to\n>                 >                                 function which is\n>                 why I think of\n>                 >                                 >>\n>                  them together. This\n>                 >                                 of course can change\n>                 since we can\n>                 >                                 >>\n>                  add whatever layers\n>                 >                                 we want to Octavia.\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                 >                                 >>\n>                  \"Neutron Incubator\"\n>                 >                                 >>\n>                 >                                 >>\n>                  This has only\n>                 >                                 become a serious\n>                 discussion in the\n>                 >                                 last\n>                 >                                 >>\n>                  few weeks and has\n>                 >                                 yet to land, so\n>                 there are many\n>                 >                                 >>\n>                  assumptions about\n>                 >                                 this which don\'t pan\n>                 out (either\n>                 >                                 >>\n>                  because of\n>                 >                                 purposeful design\n>                 and governance\n>                 >                                 decisions,\n>                 >                                 >>\n>                  or because of how\n>                 >                                 this project\n>                 actually ends up being\n>                 >                                 >>\n>                  implemented from a\n>                 >                                 practical\n>                 standpoint). But given\n>                 >                                 >>\n>                  the inherent\n>                 >                                 limitations about\n>                 making statements\n>                 >                                 with\n>                 >                                 >>\n>                  so many unknowns,\n>                 >                                 the following seem\n>                 fairly clear from\n>                 >                                 >>\n>                  what has been\n>                 >                                 shared so far:\n>                 >                                 >>\n>                 >                                 >>                 ?\n>                 Neutron incubator\n>                 >                                 is the on-ramp for\n>                 projects which\n>                 >                                 >>\n>                  should eventually\n>                 >                                 become a part of\n>                 Neutron itself.\n>                 >                                 >>\n>                 >                                 >>                 ?\n>                 Projects which\n>                 >                                 enter the Neutron\n>                 incubator on-ramp\n>                 >                                 >>\n>                  should be fairly\n>                 >                                 close to maturity in\n>                 their final\n>                 >                                 >>\n>                  form. I think the\n>                 >                                 intent here is for\n>                 them to live in\n>                 >                                 >>\n>                  incubator for 1 or\n>                 >                                 2 cycles before\n>                 either being merged\n>                 >                                 >>\n>                  into Neutron core,\n>                 >                                 or being ejected (as\n>                 abandoned, or\n>                 >                                 >>\n>                  as a separate\n>                 >                                 project).\n>                 >                                 >>\n>                 >                                 >>                 ?\n>                 Neutron incubator\n>                 >                                 projects effectively\n>                 do not have\n>                 >                                 >>\n>                  their own PTL and\n>                 >                                 core developer team,\n>                 and do not have\n>                 >                                 >>\n>                  their own\n>                 >                                 governance.\n>                 >                                 >>\n>                 >                                 >>\n>                  [Susanne] Ok I\n>                 >                                 missed the last\n>                 point. In an earlier\n>                 >                                 >>\n>                  discussion Mestery\n>                 >                                 implied that an\n>                 incubated project\n>                 >                                 >>\n>                  would have at least\n>                 >                                 one or two of its\n>                 own cores. Maybe\n>                 >                                 >>\n>                  that changed\n>                 >                                 between now and\n>                 then.\n>                 >                                 >>\n>                 >                                 >>\n>                  In addition we know\n>                 >                                 the following about\n>                 Neutron LBaaS\n>                 >                                 >>\n>                  and Octavia:\n>                 >                                 >>\n>                 >                                 >>                 ?\n>                 It\'s already\n>                 >                                 (informally?) agreed\n>                 that the ultimate\n>                 >                                 >>\n>                  long-term place for\n>                 >                                 a LBaaS solution is\n>                 probably to be\n>                 >                                 >>\n>                  spun out into its\n>                 >                                 own project, which\n>                 might\n>                 >                                 >>\n>                  appropriately live\n>                 >                                 under a\n>                 yet-to-be-defined master\n>                 >                                 >>\n>                  \"Networking\"\n>                 >                                 project. (This would\n>                 make Neutron,\n>                 >                                 LBaaS,\n>                 >                                 >>\n>                  VPNaaS, FWaaS, etc.\n>                 >                                 effective \"peer\"\n>                 projects under\n>                 >                                 >>\n>                  the Networking\n>                 >                                 umbrella.)  Since\n>                 this \"Networking\"\n>                 >                                 >>\n>                  umbrella project\n>                 >                                 has even less\n>                 defined about it than\n>                 >                                 >>\n>                  Neutron incubator,\n>                 >                                 it\'s impossible to\n>                 know whether\n>                 >                                 >>\n>                  being a part of\n>                 >                                 Neutron incubator\n>                 would be of any\n>                 >                                 >>\n>                  benefit to Octavia\n>                 >                                 (or, conversely, to\n>                 Neutron\n>                 >                                 >>\n>                  incubator) at all\n>                 >                                 as an on-ramp to\n>                 becoming part of\n>                 >                                 >>\n>                  \"Networking.\"\n>                 >                                 Presumably, Octavia\n>                 might fit well\n>                 >                                 under\n>                 >                                 >>\n>                  the \"Networking\"\n>                 >                                 umbrella-- but,\n>                 again, with nothing\n>                 >                                 >>\n>                  defined there it\'s\n>                 >                                 impossible to draw\n>                 any reasonable\n>                 >                                 >>\n>                  conclusions at this\n>                 >                                 time.\n>                 >                                 >>\n>                 >                                 >>\n>                  [Susanne] We are in\n>                 >                                 agreement h','<CAGR=i3h3Qs2LGK87=Mo4BUDNThxecJycNyTg0jwz7yVh8LA-vA@mail.gmail.com>',NULL),('<1409685439.4184798.162812457.70EE14C3@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 12:17:19',-25200,'2014-09-02 19:17:19',NULL,'[openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x','On Tue, Sep 2, 2014, at 11:30 AM, Yuriy Taraday wrote:\n> Hello.\n> \n> Currently for alpha releases of oslo libraries we generate either\n> universal\n> or Python 2.x-only wheels. This presents a problem: we can\'t adopt alpha\n> releases in projects where Python 3.x is supported and verified in the\n> gate. I\'ve ran into this in change request [1] generated after\n> global-requirements change [2]. There we have oslotest library that can\'t\n> be built as a universal wheel because of different requirements (mox vs\n> mox3 as I understand is the main difference). Because of that py33 job in\n> [1] failed and we can\'t bump oslotest version in requirements.\n> \n> I propose to change infra scripts that generate and upload wheels to\n> create\n> py3 wheels as well as py2 wheels for projects that support Python 3.x (we\n> can use setup.cfg classifiers to find that out) but don\'t support\n> universal\n> wheels. What do you think about that?\n> \n> [1] https://review.openstack.org/117940\n> [2] https://review.openstack.org/115643\n> \n> -- \n> \n> Kind regards, Yuriy.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nWe may find that we will need to have py3k wheels in addition to the\nexisting wheels at some point, but I don\'t think this use case requires\nit. If oslo.test needs to support python2 and python3 it should use mox3\nin both cases which claims to support python2.6, 2.7 and 3.2. Then you\ncan ship a universal wheel. This should solve the immediate problem.\n\nIt has been pointed out to me that one case where it won\'t be so easy is\noslo.messaging and its use of eventlet under python2. Messaging will\nalmost certainly need python 2 and python 3 wheels to be separate. I\nthink we should continue to use universal wheels where possible and only\nbuild python2 and python3 wheels in the special cases where necessary.\n\nThe setup.cfg classifiers should be able to do that for us, though PBR\nmay need updating? We will also need to learn to upload potentially >1\nwheel in our wheel jobs. That bit is likely straight foward. The last\nthing that we need to make sure we do is that we have some testing in\nplace for the special wheels. We currently have the requirements\nintegration test which runs under python2 checking that we can actually\ninstall all the things together. This ends up exercising our wheels and\nchecking that they actually work. We don\'t have a python3 equivalent for\nthat job. It may be better to work out some explicit checking of the\nwheels we produce that applies to both versions of python. I am not\nquite sure how we should approach that yet.\n\nClark\n\n\n','<CABocrW7bhrUDbo2AZ6P1_Cte+m-B+8wKJ1=DuDBNJDczD7sdVA@mail.gmail.com>',NULL),('<1409689706.5111.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 20:28:26',0,'2014-09-02 20:28:26',NULL,'[openstack-dev] [neutron][lbaas][octavia]','Slightly related, Hulu decides to play new shows Ive never watched\nbefore when im barely watching it and I heard them calling an actresses\nname that caught my attention.\nhttp://the100.wikia.com/wiki/Octavia_Blake\n\nDont\' think it\'ll affect the trademark or anything :P, just thought it\nwas interesting that im hearing this name more and more lately. \nI\'m sure theres another name for it, but ive dubbed this phenomenon the\n\'GTA effect\'. Where once you find, see or hear something you begin to\nfind, see and hear more of it. \n\n\n\n:)\n\nOn Tue, 2014-09-02 at 12:41 -0700, Stephen Balukoff wrote:\n> Yep--  I put in the application at the mid-cycle summit. There were no\n> obvious conflicts at the time, so I\'d be surprised if the application\n> isn\'t approved.  But the USPTO takes months to process these things,\n> so we might not know for a couple months still.\n> \n> \n> Stephen\n> \n> \n> On Tue, Sep 2, 2014 at 12:02 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Stephen actually has a trademark request in for Octavia.  It\n>         apparently\n>         was not trademarks prior to his request.\n>         \n>         On Tue, 2014-09-02 at 20:28 +0200, Salvatore Orlando wrote:\n>         > Inline.\n>         > Salvatore\n>         >\n>         > On 2 September 2014 19:46, Stephen Balukoff\n>         <sbalukoff at bluebox.net>\n>         > wrote:\n>         >         For what it\'s worth in this discussion, I agree that\n>         the\n>         >         possible futures of Octavia already discussed (where\n>         it lives,\n>         >         how it relates to Neutron LBaaS, etc.) are all\n>         possible. What\n>         >         actually happens here is going to depend both on the\n>         Octavia\n>         >         team, the Neutron team (especially when it comes to\n>         how the\n>         >         neutron-incubator is practically managed), and\n>         anyone else\n>         >         interested in contributing to these projects.\n>         >\n>         >\n>         >         Again, for now, I think it\'s most important to get\n>         involved,\n>         >         write code, and start delivering on the immediate,\n>         obvious\n>         >         things that need to be done for Octavia.\n>         >\n>         >\n>         > Probably... at least we\'ll be speculating about something\n>         which\n>         > actually exists.\n>         >\n>         >\n>         >\n>         >         In my mind, there are too many unknowns to predict\n>         exactly\n>         >         where things will end up in the long run. About the\n>         only thing\n>         >         I am certain of is that everyone involving\n>         themselves in the\n>         >         Octavia project wants to see it become a part of\n>         OpenStack (in\n>         >         whatever way that happens), and that that will\n>         certainly not\n>         >         happen if we aren\'t able to build the operator-scale\n>         load\n>         >         balancer we all want.\n>         >\n>         >\n>         >         Beyond that, I don\'t see a whole lot of point to the\n>         >         speculation here. :/  (Maybe someone can enlighten\n>         me to this\n>         >         point?)\n>         >\n>         >\n>         > I have speculated only to the extent that it was needed for\n>         me to\n>         > understand what\'s the interface between the two things.\n>         > Beyond that, I agree and have already pointed out that there\n>         is no\n>         > urgency for prolonging this discussion, unless the lbaas and\n>         octavia\n>         > team feel this will have a bearing on short term\n>         developments. I don\'t\n>         > think so but I do not have the full picture.\n>         >\n>         >\n>         > Talking about pointless things you might want to ensure the\n>         name\n>         > \'octavia\' is not trademarked before writing lots of code!\n>         Renames are\n>         > painful and some openstack projects (like neutron and zaqar)\n>         know\n>         > something about that.\n>         >\n>         >\n>         >\n>         >\n>         >         Stephen\n>         >\n>         >\n>         >\n>         >\n>         >         On Tue, Sep 2, 2014 at 9:40 AM, Brandon Logan\n>         >         <brandon.logan at rackspace.com> wrote:\n>         >                 Hi Susanne,\n>         >\n>         >                 I believe the options for Octavia are:\n>         >                 1) Merge into the LBaaS tree (wherever LBaaS\n>         is)\n>         >                 2) Become its own openstack project\n>         >                 3) Remains in stackforge for eternity\n>         >\n>         >                 #1 Is dependent on these options\n>         >                 1) LBaaS V2 graduates from the incubator\n>         into Neutron.\n>         >                 V1 is deprecated.\n>         >                 2) LBaaS V2 remains in incubator until it\n>         can be spun\n>         >                 out.  V1 in\n>         >                 Neutron is deprecated.\n>         >                 3) LBaaS V2 is abandoned in the incubator\n>         and LBaaS V1\n>         >                 remains.  (An\n>         >                 unlikely option)\n>         >\n>         >                 I don\'t see any other feasible options.\n>         >\n>         >                 On Tue, 2014-09-02 at 12:06 -0400, Susanne\n>         Balle\n>         >                 wrote:\n>         >                 > Doug\n>         >                 >\n>         >                 >\n>         >                 > I agree with you but I need to understand\n>         the\n>         >                 options. Susanne\n>         >                 >\n>         >                 >\n>         >                 > >> And I agree with Brandon?s sentiments.\n>         We need\n>         >                 to get something\n>         >                 > built before I?m going to worry too\n>         >                 > >> much about where it should live.  Is\n>         this a\n>         >                 candidate to get sucked\n>         >                 > into LBaaS?  Sure.  Could the reverse\n>         >                 > >> happen?  Sure.  Let?s see how it\n>         develops.\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 > On Tue, Sep 2, 2014 at 11:45 AM, Doug\n>         Wiegley\n>         >                 <dougw at a10networks.com>\n>         >                 > wrote:\n>         >                 >         Hi all,\n>         >                 >\n>         >                 >\n>         >                 >         > On the other hand one could also\n>         say that\n>         >                 Octavia is the ML2\n>         >                 >         equivalent of LBaaS. The\n>         equivalence here is\n>         >                 very loose.\n>         >                 >         Octavia would be a service-VM\n>         framework for\n>         >                 doing load\n>         >                 >         balancing using a variety of\n>         drivers. The\n>         >                 drivers ultimately\n>         >                 >         are in charge of using backends\n>         like haproxy\n>         >                 or nginx running\n>         >                 >         on the service VM to implement\n>         lbaas\n>         >                 configuration.\n>         >                 >\n>         >                 >\n>         >                 >         This, exactly.  I think it?s much\n>         fairer to\n>         >                 define Octavia as\n>         >                 >         an LBaaS purpose-built service vm\n>         framework,\n>         >                 which will use\n>         >                 >         nova and haproxy initially to\n>         provide a\n>         >                 highly scalable\n>         >                 >         backend. But before we get into\n>         terminology\n>         >                 misunderstandings,\n>         >                 >         there are a bunch of different\n>         ?drivers? at\n>         >                 play here, exactly\n>         >                 >         because this is a framework:\n>         >\n>         >                 >               * Neutron lbaas drivers ?\n>         what we all\n>         >                 know and love\n>         >                 >               * Octavia?s ?network driver?\n>         - this is\n>         >                 a piece of glue\n>         >                 >                 that exists to hide\n>         internal calls\n>         >                 we have to make\n>         >                 >                 into Neutron until clean\n>         interfaces\n>         >                 exist.  It might\n>         >                 >                 be a no-op in the case of\n>         an actual\n>         >                 neutron lbaas\n>         >                 >                 driver, which could serve\n>         that\n>         >                 function instead.\n>         >\n>         >                 >               * Octavia?s ?vm driver? -\n>         this is a\n>         >                 piece of glue\n>         >                 >                 between the octavia\n>         controller and\n>         >                 the nova VMs that\n>         >                 >                 are doing the load\n>         balancing.\n>         >\n>         >                 >               * Octavia?s ?compute driver?\n>         - you\n>         >                 guessed it, an\n>         >                 >                 abstraction to Nova and\n>         its\n>         >                 scheduler.\n>         >                 >         Places that can be the ?front-end?\n>         for\n>         >                 Octavia:\n>         >\n>         >                 >               * Neutron LBaaS v2 driver\n>         >                 >               * Neutron LBaaS v1 driver\n>         >\n>         >                 >               * It?s own REST API\n>         >                 >         Things that could have their own\n>         VM drivers:\n>         >\n>         >                 >               * haproxy, running inside\n>         nova\n>         >                 >               * Nginx, running inside nova\n>         >\n>         >                 >               * Anything else you want,\n>         running\n>         >                 inside any hypervisor\n>         >                 >                 you want\n>         >                 >               * Vendor soft appliances\n>         >                 >               * Null-out the VM calls and\n>         go\n>         >                 straight to some other\n>         >                 >                 backend?  Sure, though I?m\n>         not sure\n>         >                 I?d see the point.\n>         >                 >         There are quite a few synergies\n>         with other\n>         >                 efforts, and we?re\n>         >                 >         monitoring them, but not waiting\n>         for any of\n>         >                 them.\n>         >                 >\n>         >                 >\n>         >                 >         And I agree with Brandon?s\n>         sentiments.  We\n>         >                 need to get\n>         >                 >         something built before I?m going\n>         to worry\n>         >                 too much about where\n>         >                 >         it should live.  Is this a\n>         candidate to get\n>         >                 sucked into\n>         >                 >         LBaaS?  Sure.  Could the reverse\n>         happen?\n>         >                 Sure.  Let?s see how\n>         >                 >         it develops.\n>         >                 >\n>         >                 >\n>         >                 >         Incidentally, we are currently\n>         having a\n>         >                 debate over the use of\n>         >                 >         the term ?vm? (and ?vm driver?) as\n>         the name\n>         >                 to describe\n>         >                 >         octavia?s backends.  Feel free to\n>         chime in\n>         >                 >         here:\n>         >                 https://review.openstack.org/#/c/117701/\n>         >                 >\n>         >                 >\n>         >                 >         Thanks,\n>         >                 >         doug\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >         From: Salvatore Orlando\n>         >                 <sorlando at nicira.com>\n>         >                 >\n>         >                 >         Reply-To: \"OpenStack Development\n>         Mailing\n>         >                 List (not for usage\n>         >                 >         questions)\"\n>         >                 <openstack-dev at lists.openstack.org>\n>         >                 >\n>         >                 >         Date: Tuesday, September 2, 2014\n>         at 9:05 AM\n>         >                 >\n>         >                 >         To: \"OpenStack Development Mailing\n>         List (not\n>         >                 for usage\n>         >                 >         questions)\"\n>         >                 <openstack-dev at lists.openstack.org>\n>         >                 >         Subject: Re: [openstack-dev]\n>         >                 [neutron][lbaas][octavia]\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >         Hi Susanne,\n>         >                 >\n>         >                 >\n>         >                 >         I\'m just trying to gain a good\n>         understanding\n>         >                 of the situation\n>         >                 >         here.\n>         >                 >         More comments and questions\n>         inline.\n>         >                 >\n>         >                 >\n>         >                 >         Salvatore\n>         >                 >\n>         >                 >         On 2 September 2014 16:34, Susanne\n>         Balle\n>         >                 >         <sleipnir012 at gmail.com> wrote:\n>         >                 >                 Salvatore\n>         >                 >\n>         >                 >\n>         >                 >                 Thanks for your\n>         clarification below\n>         >                 around the\n>         >                 >                 blueprint.\n>         >                 >\n>         >                 >\n>         >                 >                 > For LBaaS v2 therefore\n>         the\n>         >                 relationship between it\n>         >                 >                 and Octavia should be the\n>         same as\n>         >                 with any other\n>         >                 >                 > backend. I see Octavia\n>         has a\n>         >                 blueprint for a\n>         >                 >                 \"network driver\" - and the\n>         derivable\n>         >                 of that should\n>         >                 >                 definitely be\n>         >                 >                 > part of the LBaaS\n>         project.\n>         >                 >\n>         >                 >\n>         >                 >                 > For the rest, it would\n>         seem a bit\n>         >                 strange to me if\n>         >                 >                 the LBaaS project\n>         incorporated a\n>         >                 backend as well.\n>         >                 >                 After\n>         >                 >\n>         >                 >                 > all, LBaaS v1 did not\n>         incorporate\n>         >                 haproxy!\n>         >                 >                 > Also, as Adam points\n>         out, Nova\n>         >                 does not incorporate\n>         >                 >                 an Hypervisor.\n>         >                 >\n>         >                 >\n>         >                 >                 In my vision Octavia is a\n>         LBaaS\n>         >                 framework that should\n>         >                 >                 not be tied to ha-proxy.\n>         The\n>         >                 interfaces should be\n>         >                 >                 clean and at a high enough\n>         level\n>         >                 that we can switch\n>         >                 >                 load-balancer. We should\n>         be able to\n>         >                 switch the\n>         >                 >                 load-balancer to nginx so\n>         to me the\n>         >                 analogy is more\n>         >                 >                 Octavia+LBaaSV2 == nova\n>         and\n>         >                 hypervisor ==\n>         >                 >                 load-balancer.\n>         >                 >\n>         >                 >\n>         >                 >         Indeed I said that it would have\n>         been\n>         >                 initially tied to\n>         >                 >         haproxy considering the blueprints\n>         currently\n>         >                 defined for\n>         >                 >         octavia, but I\'m sure the solution\n>         could\n>         >                 leverage nginx or\n>         >                 >         something else in the future.\n>         >                 >\n>         >                 >\n>         >                 >         I think however it is correct to\n>         say that\n>         >                 LBaaS v2 will have\n>         >                 >         an Octavia driver on par with A10,\n>         radware,\n>         >                 nestscaler and\n>         >                 >         others.\n>         >                 >         (Correct me if I\'m wrong) On the\n>         other hand\n>         >                 Octavia, within\n>         >                 >         its implementation, might use\n>         different\n>         >                 drivers - for instance\n>         >                 >         nginx or haproxy. And in theory it\n>         cannot be\n>         >                 excluded that the\n>         >                 >         same appliance might implement\n>         some vips\n>         >                 using haproxy and\n>         >                 >         others using nginx.\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                 I am not sure the group is\n>         in\n>         >                 agreement on the\n>         >                 >                 definition I just wrote.\n>         Also going\n>         >                 back the\n>         >                 >                 definition of Octavia\n>         being a\n>         >                 backend then I agree\n>         >                 >                 that we should write a\n>         blueprint to\n>         >                 incorporate\n>         >                 >                 Octavia as a network\n>         driver.\n>         >                 >\n>         >                 >\n>         >                 >         What about this blueprint?\n>         >                 >\n>         >\n>         https://blueprints.launchpad.net/octavia/+spec/neutron-network-driver\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                 I guess I had always\n>         envisioned what\n>         >                 we now call\n>         >                 >                 Octavia to be part of the\n>         LBaaS\n>         >                 service itself and\n>         >                 >                 have ha-proxy, nginx be\n>         the drivers\n>         >                 and not have the\n>         >                 >                 driver level be at the\n>         Octavia\n>         >                 cut-over point, Given\n>         >                 >                 this new \"design\" I am now\n>         wondering\n>         >                 why we didn\'t\n>         >                 >                 just write a driver for\n>         Libra and\n>         >                 improved on Libra\n>         >                 >                 since to me that is the\n>         now the\n>         >                 driver level we are\n>         >                 >                 discussing.\n>         >                 >\n>         >                 >\n>         >                 >         Octavia could be part of the lbaas\n>         service\n>         >                 just like neutron\n>         >                 >         has a set of agents which at the\n>         end of the\n>         >                 day provide a\n>         >                 >         L2/L3 network virtualization\n>         service.\n>         >                 Personally I\'m of the\n>         >                 >         opinion that I would move that\n>         code in a\n>         >                 separate repo which\n>         >                 >         could be maintained by networking\n>         experts (I\n>         >                 can barely plug\n>         >                 >         an ethernet cable into a switch).\n>         But the\n>         >                 current situation\n>         >                 >         creates a case for Octavia\n>         inclusion in\n>         >                 lbaas.\n>         >                 >\n>         >                 >\n>         >                 >         On the other hand one could also\n>         say that\n>         >                 Octavia is the ML2\n>         >                 >         equivalent of LBaaS. The\n>         equivalence here is\n>         >                 very loose.\n>         >                 >         Octavia would be a service-VM\n>         framework for\n>         >                 doing load\n>         >                 >         balancing using a variety of\n>         drivers. The\n>         >                 drivers ultimately\n>         >                 >         are in charge of using backends\n>         like haproxy\n>         >                 or nginx running\n>         >                 >         on the service VM to implement\n>         lbaas\n>         >                 configuration.\n>         >                 >         To avoid further discussion it\n>         might be\n>         >                 better to steer away\n>         >                 >         from discussing overlaps and\n>         synergies with\n>         >                 the service VM\n>         >                 >         project, at least for now.\n>         >                 >\n>         >                 >\n>         >                 >         I think the ability of having the\n>         Libra\n>         >                 driver was discussed\n>         >                 >         in the past. I do not know the\n>         details, but\n>         >                 it seemed there\n>         >                 >         was not a lot to gain from having\n>         a Neutron\n>         >                 LBaaS driver\n>         >                 >         pointing to libra (ie: it was much\n>         easier to\n>         >                 just deploy libra\n>         >                 >         instead of neutron lbaas).\n>         >                 >\n>         >                 >\n>         >                 >         Summarising, so far I haven\'t yet\n>         an opinion\n>         >                 regarding where\n>         >                 >         Octavia will sit.\n>         >                 >         Nevertheless I think this is a\n>         discussion\n>         >                 that it\'s useful for\n>         >                 >         the medium/long term - it does not\n>         seem to\n>         >                 me that there is an\n>         >                 >         urgency here.\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                 Regards Susanne\n>         >                 >\n>         >                 >\n>         >                 >                 On Tue, Sep 2, 2014 at\n>         9:18 AM,\n>         >                 Salvatore Orlando\n>         >                 >                 <sorlando at nicira.com>\n>         wrote:\n>         >                 >                         Some more comments\n>         from me\n>         >                 inline.\n>         >                 >\n>         >                 >                         Salvatore\n>         >                 >\n>         >                 >\n>         >                 >                         On 2 September\n>         2014 11:06,\n>         >                 Adam Harwell\n>         >                 >\n>          <adam.harwell at rackspace.com>\n>         >                 wrote:\n>         >                 >                                 I also\n>         agree with\n>         >                 most of what Brandon\n>         >                 >                                 said,\n>         though I am\n>         >                 slightly\n>         >                 >                                 concerned\n>         by the\n>         >                 talk of merging\n>         >                 >                                 Octavia\n>         and\n>         >                 [Neutron-]LBaaS-v2\n>         >                 >                                 codebases.\n>         >                 >\n>         >                 >\n>         >                 >                         Beyond all the\n>         reasons\n>         >                 listed in this thread -\n>         >                 >                         merging codebases\n>         is always\n>         >                 more difficult\n>         >                 >                         that what it\n>         seems!\n>         >                 >                         Also it seems to\n>         me there\'s\n>         >                 not yet a clear\n>         >                 >                         path for LBaaS v2.\n>         Mostly\n>         >                 because of the\n>         >                 >                         ongoing neutron\n>         incubator\n>         >                 discussion.\n>         >                 >                         However in my\n>         opinion there\n>         >                 are 3 paths (and I\n>         >                 >                         have no idea\n>         whether they\n>         >                 might be applicable\n>         >                 >                         to Octavia as a\n>         standalone\n>         >                 project).\n>         >                 >                         1) Aim at becoming\n>         part of\n>         >                 neutron via the\n>         >                 >                         incubator or any\n>         equivalent\n>         >                 mechanisms\n>         >                 >                         2) Evolve in\n>         loosely coupled\n>         >                 fashion with\n>         >                 >                         neutron, but still\n>         be part\n>         >                 of the networking\n>         >                 >                         program. (This\n>         means that\n>         >                 LBaaS APIs will be\n>         >                 >                         part of Openstack\n>         Network\n>         >                 APIs)\n>         >                 >                         3) Evolve\n>         independently from\n>         >                 neutron, and\n>         >                 >                         become part of a\n>         new\n>         >                 program. I have no idea\n>         >                 >                         however whether\n>         there\'s\n>         >                 enough material to\n>         >                 >                         have a \"load\n>         balancing\"\n>         >                 program, and what\n>         >                 >                         would be the\n>         timeline for\n>         >                 that.\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                                 [blogan]\n>         \"I think\n>         >                 the best course of\n>         >                 >                                 action is\n>         to get\n>         >                 Octavia itself into\n>         >                 >                                 the same\n>         codebase as\n>         >                 LBaaS (Neutron or\n>         >                 >                                 spun\n>         out).\"\n>         >                 >\n>         >                 >                                 [sballe]\n>         \"What I am\n>         >                 trying to now\n>         >                 >                                 understand\n>         is how we\n>         >                 will move Octavia\n>         >                 >                                 into the\n>         new LBaaS\n>         >                 project?\"\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                                 I didn\'t\n>         think that\n>         >                 was ever going to\n>         >                 >                                 be the\n>         plan -- sure,\n>         >                 we\'d have an\n>         >                 >                                 Octavia\n>         driver that\n>         >                 is part of the\n>         >                 >\n>          [Neutron-]LBaaS-v2\n>         >                 codebase (which\n>         >                 >                                 Susanne\n>         did mention\n>         >                 as well), but\n>         >                 >                                 nothing\n>         more than\n>         >                 that. The actual\n>         >                 >                                 Octavia\n>         code would\n>         >                 still be in its own\n>         >                 >                                 project at\n>         the end\n>         >                 of all of this,\n>         >                 >                                 right? The\n>         driver\n>         >                 code could be added\n>         >                 >                                 to\n>         >                 [Neutron-]LbaaS-v2 at any point\n>         >                 >                                 once\n>         Octavia is\n>         >                 mature enough to be\n>         >                 >                                 used, just\n>         by\n>         >                 submitting it as a CR, I\n>         >                 >                                 believe.\n>         Doug might\n>         >                 be able to comment\n>         >                 >                                 on that,\n>         since he\n>         >                 maintains the A10\n>         >                 >                                 driver?\n>         >                 >\n>         >                 >\n>         >                 >                         From what I\n>         gathered so far\n>         >                 Octavia is a fully\n>         >                 >                         fledged load\n>         balancing\n>         >                 virtual appliance which\n>         >                 >                         (at least in its\n>         first\n>         >                 iterations) will\n>         >                 >                         leverage haproxy.\n>         >                 >                         As also stated\n>         earlier in\n>         >                 this thread it\'s a\n>         >                 >                         peer of commercial\n>         >                 appliances from various\n>         >                 >                         vendors.\n>         >                 >\n>         >                 >\n>         >                 >                         For LBaaS v2\n>         therefore the\n>         >                 relationship\n>         >                 >                         between it and\n>         Octavia\n>         >                 should be the same as\n>         >                 >                         with any other\n>         backend. I\n>         >                 see Octavia has a\n>         >                 >                         blueprint for a\n>         \"network\n>         >                 driver\" - and the\n>         >                 >                         derivable of that\n>         should\n>         >                 definitely be part of\n>         >                 >                         the LBaaS project.\n>         >                 >                         For the rest, it\n>         would seem\n>         >                 a bit strange to\n>         >                 >                         me if the LBaaS\n>         project\n>         >                 incorporated a backend\n>         >                 >                         as well. After\n>         all, LBaaS v1\n>         >                 did not\n>         >                 >                         incorporate\n>         haproxy!\n>         >                 >                         Also, as Adam\n>         points out,\n>         >                 Nova does not\n>         >                 >                         incorporate an\n>         Hypervisor.\n>         >                 >\n>         >                 >\n>         >                 >                                 Also, I\n>         know I\'m\n>         >                 opening this same can\n>         >                 >                                 of worms\n>         again, but\n>         >                 I am curious\n>         >                 >                                 about the\n>         HP mandate\n>         >                 that \"everything\n>         >                 >                                 must be\n>         OpenStack\"\n>         >                 when it comes to\n>         >                 >                                 Octavia.\n>         Since HP\'s\n>         >                 offering would be\n>         >                 >\n>         >                  \"[Neutron-]LBaaS-v2\", which happens\n>         >                 >                                 to use\n>         Octavia as a\n>         >                 backend, does it\n>         >                 >                                 matter\n>         whether\n>         >                 Octavia is an official\n>         >                 >                                 OpenStack\n>         project**?\n>         >                 If HP can offer\n>         >                 >                                 Cloud\n>         Compute\n>         >                 through Nova, and Nova\n>         >                 >                                 uses some\n>         hypervisor\n>         >                 like Xen or KVM\n>         >                 >                                 (neither\n>         of which\n>         >                 are a part of\n>         >                 >\n>          OpenStack), I am not\n>         >                 sure how it is\n>         >                 >                                 different\n>         to offer\n>         >                 Cloud Load\n>         >                 >                                 Balancing\n>         via\n>         >                 [Neutron-]LBaaS-v2 which\n>         >                 >                                 could be\n>         using a\n>         >                 non-Openstack\n>         >                 >\n>          implementation for\n>         >                 the backend. I\n>         >                 >                                 don\'t see\n>         \"Octavia\n>         >                 needs to be in\n>         >                 >                                 Openstack\"\n>         as a\n>         >                 blocker so long as the\n>         >                 >                                 \"LBaaS\n>         API\" is part\n>         >                 of OpenStack.\n>         >                 >\n>         >                 >                                 **NOTE: I\n>         AM\n>         >                 DEFINITELY STILL IN FAVOR\n>         >                 >                                 OF OCTAVIA\n>         BEING AN\n>         >                 OPENSTACK\n>         >                 >                                 PROJECT.\n>         THIS IS\n>         >                 JUST AN EXAMPLE FOR\n>         >                 >                                 THE SAKE\n>         OF THIS\n>         >                 PARTICULAR ARGUMENT.\n>         >                 >                                 PLEASE\n>         DON\'T THINK\n>         >                 THAT I\'M AGAINST\n>         >                 >                                 OCTAVIA\n>         BEING\n>         >                 OFFICIALLY INCUBATED!**\n>         >                 >\n>         >                 >\n>         >                 >                                  --Adam\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                  https://keybase.io/rm_you\n>         >                 >\n>         >                 >\n>         >                 >\n>         >                 >                                 On 9/1/14\n>         10:12 PM,\n>         >                 \"Brandon Logan\"\n>         >                 >\n>         >                  <brandon.logan at RACKSPACE.COM> wrote:\n>         >                 >\n>         >                 >                                 >Hi\n>         Susanne and\n>         >                 everyone,\n>         >                 >                                 >\n>         >                 >                                 >My\n>         opinions are\n>         >                 that keeping it in\n>         >                 >                                 stackforge\n>         until it\n>         >                 gets mature is\n>         >                 >                                 >the best\n>         solution.\n>         >                 I\'m pretty sure\n>         >                 >                                 we can all\n>         agree on\n>         >                 that.  Whenever\n>         >                 >                                 >it is\n>         mature then,\n>         >                 and only then, we\n>         >                 >                                 should try\n>         to get it\n>         >                 into openstack\n>         >                 >                                 >one way\n>         or another.\n>         >                 If Neutron LBaaS\n>         >                 >                                 v2 is\n>         still\n>         >                 incubated then it\n>         >                 >                                 >should be\n>         >                 relatively easy to get it\n>         >                 >                                 in that\n>         codebase.\n>         >                 If Neutron LBaaS\n>         >                 >                                 >has\n>         already spun\n>         >                 out, even easier for\n>         >                 >                                 us.  If we\n>         want\n>         >                 Octavia to just\n>         >                 >                                 >become an\n>         openstack\n>         >                 project all its\n>         >                 >                                 own then\n>         that will\n>         >                 be the difficult\n>         >                 >                                 >part.\n>         >                 >                                 >\n>         >                 >                                 >I think\n>         the best\n>         >                 course of action is\n>         >                 >                                 to get\n>         Octavia\n>         >                 itself into the same\n>         >                 >                                 >codebase\n>         as LBaaS\n>         >                 (Neutron or spun\n>         >                 >                                 out).\n>         They do go\n>         >                 together, and the\n>         >                 >\n>          >maintainers will\n>         >                 almost always be the\n>         >                 >                                 same for\n>         both.  This\n>         >                 makes even\n>         >                 >                                 >more\n>         sense when\n>         >                 LBaaS is spun out\n>         >                 >                                 into its\n>         own\n>         >                 project.\n>         >                 >                                 >\n>         >                 >                                 >I really\n>         think all\n>         >                 of the answers to\n>         >                 >                                 these\n>         questions will\n>         >                 fall into\n>         >                 >                                 >place\n>         when we\n>         >                 actually deliver a\n>         >                 >                                 product\n>         that we are\n>         >                 all wanting and\n>         >                 >                                 >talking\n>         about\n>         >                 delivering with\n>         >                 >                                 Octavia.\n>         Once we\n>         >                 prove that we can\n>         >                 >                                 all\n>         >                 >                                 >come\n>         together as a\n>         >                 community and\n>         >                 >                                 manage a\n>         product\n>         >                 from inception to\n>         >                 >                                 >maturity,\n>         we will\n>         >                 then have the\n>         >                 >                                 respect\n>         and trust to\n>         >                 do what is best\n>         >                 >                                 for\n>         >                 >                                 >an\n>         Openstack LBaaS\n>         >                 product.\n>         >                 >                                 >\n>         >                 >                                 >Thanks,\n>         >                 >                                 >Brandon\n>         >                 >                                 >\n>         >                 >                                 >On Mon,\n>         2014-09-01\n>         >                 at 10:18 -0400,\n>         >                 >                                 Susanne\n>         Balle wrote:\n>         >                 >                                 >> Kyle,\n>         Adam,\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> Based\n>         on this\n>         >                 thread Kyle is\n>         >                 >                                 suggesting\n>         the\n>         >                 follow moving forward\n>         >                 >                                 >> plan:\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> 1) We\n>         incubate\n>         >                 Neutron LBaaS V2 in\n>         >                 >                                 the\n>         ?Neutron?\n>         >                 incubator ?and freeze\n>         >                 >                                 >> LBaas\n>         V1.0?\n>         >                 >                                 >> 2)\n>         ?Eventually?\n>         >                 It graduates into a\n>         >                 >                                 project\n>         under the\n>         >                 networking\n>         >                 >                                 >>\n>         program.\n>         >                 >                                 >> 3) ?At\n>         that\n>         >                 point? We deprecate\n>         >                 >                                 Neutron\n>         LBaaS v1.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> The\n>         words in ?xx?\n>         >                 are works I added\n>         >                 >                                 to make\n>         sure I/We\n>         >                 understand the\n>         >                 >                                 >> whole\n>         picture.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> And as\n>         Adam\n>         >                 mentions: Octavia !=\n>         >                 >                                 LBaaS-v2.\n>         Octavia is\n>         >                 a peer to F5 /\n>         >                 >                                 >>\n>         Radware / A10 /\n>         >                 etc appliances\n>         >                 >                                 which is a\n>         >                 definition I agree with\n>         >                 >                                 BTW.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> What I\n>         am trying\n>         >                 to now understand\n>         >                 >                                 is how we\n>         will move\n>         >                 Octavia into\n>         >                 >                                 >> the new\n>         LBaaS\n>         >                 project?\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> If we\n>         do it later\n>         >                 rather than\n>         >                 >                                 develop\n>         Octavia in\n>         >                 tree under the new\n>         >                 >                                 >>\n>         incubated LBaaS\n>         >                 project when do we\n>         >                 >                                 plan to\n>         bring it\n>         >                 in-tree from\n>         >                 >                                 >>\n>         Stackforge? Kilo?\n>         >                 Later? When LBaaS\n>         >                 >                                 is a\n>         separate\n>         >                 project under the\n>         >                 >                                 >>\n>         Networking\n>         >                 program?\n>         >                 >                                 >\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> What\n>         are the\n>         >                 criteria to bring a\n>         >                 >                                 driver\n>         into the\n>         >                 LBaaS project and\n>         >                 >                                 >> what do\n>         we need\n>         >                 to do to replace\n>         >                 >                                 the\n>         existing\n>         >                 reference driver? Maybe\n>         >                 >                                 >> adding\n>         a software\n>         >                 driver to LBaaS\n>         >                 >                                 source\n>         tree is less\n>         >                 of a problem\n>         >                 >                                 >> than\n>         converting a\n>         >                 whole project to\n>         >                 >                                 an\n>         OpenStack\n>         >                 project.\n>         >                 >                                 >\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> Again I\n>         am open\n>         >                 to both directions\n>         >                 >                                 I just\n>         want to make\n>         >                 sure we\n>         >                 >                                 >>\n>         understand why we\n>         >                 are choosing to\n>         >                 >                                 do one or\n>         the other\n>         >                 and that our\n>         >                 >                                 >>\n>         decision is\n>         >                 based on data and not\n>         >                 >                                 emotions.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> I am\n>         assuming\n>         >                 that keeping Octavia\n>         >                 >                                 in\n>         Stackforge will\n>         >                 increase the\n>         >                 >                                 >>\n>         velocity of the\n>         >                 project and allow\n>         >                 >                                 us more\n>         freedom\n>         >                 which is goodness.\n>         >                 >                                 >> We just\n>         need to\n>         >                 have a plan to make\n>         >                 >                                 it part of\n>         the\n>         >                 Openstack LBaaS\n>         >                 >                                 >>\n>         project.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> Regards\n>         Susanne\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >> On Sat,\n>         Aug 30,\n>         >                 2014 at 2:09 PM,\n>         >                 >                                 Adam\n>         Harwell\n>         >                 >                                 >>\n>         >                 <adam.harwell at rackspace.com> wrote:\n>         >                 >                                 >>\n>          Only\n>         >                 really have comments\n>         >                 >                                 on two of\n>         your\n>         >                 related points:\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          [Susanne]\n>         >                 To me Octavia is\n>         >                 >                                 a driver\n>         so it is\n>         >                 very hard to me\n>         >                 >                                 >>\n>          to think\n>         >                 of it as a\n>         >                 >                                 standalone\n>         project.\n>         >                 It needs the new\n>         >                 >                                 >>\n>          Neutron\n>         >                 LBaaS v2 to\n>         >                 >                                 function\n>         which is\n>         >                 why I think of them\n>         >                 >                                 >>\n>          together.\n>         >                 This of course\n>         >                 >                                 can change\n>         since we\n>         >                 can add whatever\n>         >                 >                                 >>\n>          layers we\n>         >                 want to Octavia.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          [Adam] I\n>         >                 guess I\'ve always\n>         >                 >                                 shared\n>         Stephen\'s\n>         >                 >                                 >>\n>          viewpoint\n>         >                 ? Octavia !=\n>         >                 >                                 LBaaS-v2.\n>         Octavia is\n>         >                 a peer to F5 /\n>         >                 >                                 >>\n>          Radware /\n>         >                 A10 /\n>         >                 >\n>          etcappliances, not\n>         >                 to an Openstack API\n>         >                 >                                 layer\n>         >                 >                                 >>\n>          like\n>         >                 Neutron-LBaaS. It\'s a\n>         >                 >                                 little\n>         tricky to\n>         >                 clearly define\n>         >                 >                                 >>\n>          this\n>         >                 difference in\n>         >                 >\n>          conversation, and I\n>         >                 have noticed that\n>         >                 >                                 quite\n>         >                 >                                 >>\n>          a few\n>         >                 people are having the\n>         >                 >                                 same issue\n>         >                 differentiating. In a\n>         >                 >                                 >>\n>          small\n>         >                 group, having quite a\n>         >                 >                                 few people\n>         not on\n>         >                 the same page is\n>         >                 >                                 >>\n>          a bit\n>         >                 scary, so maybe we\n>         >                 >                                 need to\n>         really sit\n>         >                 down and map this\n>         >                 >                                 >>\n>          out so\n>         >                 everyone is together\n>         >                 >                                 one way or\n>         the\n>         >                 other.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >\n>         >                 >                                 >>\n>          [Susanne]\n>         >                 Ok now I am\n>         >                 >                                 confused?\n>         But I\n>         >                 agree with you that it\n>         >                 >                                 >>\n>          need to\n>         >                 focus on our use\n>         >                 >                                 cases. I\n>         remember us\n>         >                 discussing\n>         >                 >                                 >>\n>          Octavia\n>         >                 being the refenece\n>         >                 >\n>          implementation for\n>         >                 OpenStack LBaaS\n>         >                 >                                 >>\n>          (whatever\n>         >                 that is). Has\n>         >                 >                                 that\n>         changed while I\n>         >                 was on vacation?\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          [Adam] I\n>         >                 believe that\n>         >                 >                                 having the\n>         Octavia\n>         >                 \"driver\" (not the\n>         >                 >                                 >>\n>          Octavia\n>         >                 codebase itself,\n>         >                 >\n>          technically) become\n>         >                 the reference\n>         >                 >                                 >>\n>         >                  implementation for\n>         >                 >\n>          Neutron-LBaaS is\n>         >                 still the plan in my\n>         >                 >                                 eyes.\n>         >                 >                                 >>\n>          The\n>         >                 Octavia Driver in\n>         >                 >\n>          Neutron-LBaaS is a\n>         >                 separate bit of\n>         >                 >                                 code\n>         >                 >                                 >>\n>          from the\n>         >                 actual Octavia\n>         >                 >                                 project,\n>         similar to\n>         >                 the way the A10\n>         >                 >                                 >>\n>          driver is\n>         >                 a separate bit of\n>         >                 >                                 code from\n>         the A10\n>         >                 appliance. To do\n>         >                 >                                 >>\n>          that\n>         >                 though, we need\n>         >                 >                                 Octavia to\n>         be fairly\n>         >                 close to fully\n>         >                 >                                 >>\n>         >                  functional. I believe we\n>         >                 >                                 can do\n>         this because\n>         >                 even though the\n>         >                 >                                 >>\n>          reference\n>         >                 driver would then\n>         >                 >                                 require an\n>         >                 additional service to\n>         >                 >                                 >>\n>          run, what\n>         >                 it requires is\n>         >                 >                                 still\n>         >                 fully-open-source and (by way\n>         >                 >                                 >>\n>          of our\n>         >                 plan) available as\n>         >                 >                                 part of\n>         OpenStack\n>         >                 core.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          --Adam\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                  https://keybase.io/rm_you\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          From:\n>         >                 Susanne Balle\n>         >                 >\n>         >                  <sleipnir012 at gmail.com>\n>         >                 >                                 >>\n>          Reply-To:\n>         >                 \"OpenStack\n>         >                 >\n>          Development Mailing\n>         >                 List (not for\n>         >                 >                                 usage\n>         >                 >                                 >>\n>         >                  questions)\"\n>         >                 >\n>         >                  <openstack-dev at lists.openstack.org>\n>         >                 >                                 >>\n>          Date:\n>         >                 Friday, August 29,\n>         >                 >                                 2014 9:19\n>         AM\n>         >                 >                                 >>\n>          To:\n>         >                 \"OpenStack Development\n>         >                 >                                 Mailing\n>         List (not\n>         >                 for usage\n>         >                 >                                 >>\n>         >                  questions)\"\n>         >                 >\n>         >                  <openstack-dev at lists.openstack.org>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>          Subject:\n>         >                 Re:\n>         >                 >\n>          [openstack-dev]\n>         >                 >\n>         >                  [neutron][lbaas][octavia]\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                  Stephen\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                  See inline\n>         >                 >                                 comments.\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                  Susanne\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >\n>         >                 -----------------------------------------\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                  Susanne--\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>         >                 >                                 >>\n>                  I\n>         >                 think you are\n>         >                 >                                 conflating\n>         the\n>         >                 difference between\n>         >                 >                                 >>\n>         >                  \"OpenStack\n>         >                 >\n>          incubation\" and\n>         >                 \"Neutron incubator.\"\n>         >                 >                                 These\n>         >                 >                                 >>\n>         >                  are two very\n>  ','<CAAGw+ZpZ5Ck1uPz5ASd=AenxO=n3bjm+qB3dDoqm9MREO1P3pQ@mail.gmail.com>',NULL),('<1409692289-sup-1831@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 21:19:38',0,'2014-09-02 21:19:38',NULL,'[openstack-dev] [Ironic] (Non-)consistency of the Ironic hash\n	ring implementation','Excerpts from Nejc Saje\'s message of 2014-09-01 07:48:46 +0000:\n> Hey guys,\n> \n> in Ceilometer we\'re using consistent hash rings to do workload \n> partitioning[1]. We\'ve considered generalizing your hash ring \n> implementation and moving it up to oslo, but unfortunately your \n> implementation is not actually consistent, which is our requirement.\n> \n> Since you divide your ring into a number of equal sized partitions, \n> instead of hashing hosts onto the ring, when you add a new host,\n> an unbound amount of keys get re-mapped to different hosts (instead of \n> the 1/#nodes remapping guaranteed by hash ring). I\'ve confirmed this \n> with the test in aforementioned patch[2].\n\nI am just getting started with the ironic hash ring code, but this seems\nsurprising to me. AIUI we do require some rebalancing when a conductor\nis removed or added (which is normal use of a CHT) but not for every\nhost added. This is supported by the fact that we currently dont have a\nrebalancing routine, so I would be surprised if ironic worked at all if\nwe required it for each host that is added.\n\nCan anyone in Ironic with a bit more experience confirm/deny this?\n\n> \n> If this is good enough for your use-case, great, otherwise we can get a \n> generalized hash ring implementation into oslo for use in both projects \n> or we can both use an external library[3].\n> \n> Cheers,\n> Nejc\n> \n> [1] https://review.openstack.org/#/c/113549/\n> [2] \n> https://review.openstack.org/#/c/113549/21/ceilometer/tests/test_utils.py\n> [3] https://pypi.python.org/pypi/hash_ring\n> \n\nThanks,\nGreg\n\n\n','<540424DE.4020005@redhat.com>',NULL),('<1409692495.3820.21.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-02 21:12:14',0,'2014-09-02 21:12:14',NULL,'[openstack-dev] [neutron][lbaas][octavia]','I am not for this if Octavia is merged into the incubator when LBaaS V2\nis, assuming LBaaS V2 will be merged into it before the summit.  I\'d\nrather Octavia get merged into whatever repository it is destined to\nwhenever it is much more mature.  If Octavia is merged into the\nincubator too soon, I think it\'s velocity will be much less than if it\nwere independent at first.\n\nOn Tue, 2014-09-02 at 13:45 -0700, Stephen Balukoff wrote:\n> Hi Kyle,\n> \n> \n> IMO, that depends entirely on how the incubator project is run. For\n> now, I\'m in favor of remaining separate and letting someone else be\n> the guinea pig. :/  I think we\'ll (all) be more productive this way.\n> \n> \n> Also keep in mind that the LBaaS v2 code is mostly there (just waiting\n> on reviews), so it\'s probably going to be ready for neutron-incubator\n> incubation well before Octavia is ready for anything like that.\n> \n> \n> Stephen\n> \n> On Tue, Sep 2, 2014 at 12:52 PM, Kyle Mestery <mestery at mestery.com>\n> wrote:\n>         \n>         \n>         To me what makes sense here is that we merge the Octavia code\n>         into the\n>         neutron-incubator when the LBaaS V2 code is merged there. If\n>         the end\n>         goal is to spin the LBaaS V2 stuff out into a separate git\n>         repository\n>         and project (under the networking umbrella), this would allow\n>         for the\n>         Octavia driver to be developed alongside the V2 API code, and\n>         in fact\n>         help satisfy one of the requirements around Neutron incubation\n>         graduation: Having a functional driver. And it also allows for\n>         the\n>         driver to continue to live on next to the API.\n>         \n>         What do people think about this?\n>         \n>         Thanks,\n>         Kyle\n>         \n>         \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+Zob4Uy+VgTPScvfbcHkAcQhEykSKse=WxmajVf2sD3n0A@mail.gmail.com>',NULL),('<1409727085.12237.214.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 08:51:25',7200,'2014-09-03 06:51:25',NULL,'[openstack-dev] [TripleO] Review metrics - what do we want to\n measure?','On Wed, 2014-09-03 at 12:58 +1200, Robert Collins wrote:\n> On 14 August 2014 11:03, James Polley <jp at jamezpolley.com> wrote:\n> > In recent history, we\'ve been looking each week at stats from\n> > http://russellbryant.net/openstack-stats/tripleo-openreviews.html to get a\n> > gauge on how our review pipeline is tracking.\n> >\n> > The main stats we\'ve been tracking have been the \"since the last revision\n> > without -1 or -2\". I\'ve included some history at [1], but the summary is\n> > that our 3rd quartile has slipped from 13 days to 16 days over the last 4\n> > weeks or so. Our 1st quartile is fairly steady lately, around 1 day (down\n> > from 4 a month ago) and median is unchanged around 7 days.\n> >\n> > There was lots of discussion in our last meeting about what could be causing\n> > this[2]. However, the thing we wanted to bring to the list for the\n> > discussion is:\n> >\n> > Are we tracking the right metric? Should we be looking to something else to\n> > tell us how well our pipeline is performing?\n> >\n> > The meeting logs have quite a few suggestions about ways we could tweak the\n> > existing metrics, but if we\'re measuring the wrong thing that\'s not going to\n> > help.\n> >\n> > I think that what we are looking for is a metric that lets us know whether\n> > the majority of patches are getting feedback quickly. Maybe there\'s some\n> > other metric that would give us a good indication?\n> \n> If we review all patches quickly and land none, thats bad too :).\n> \n> For the reviewers specifically i think we need a metric(s) that:\n>  - doesn\'t go bad when submitters go awol, don\'t respond etc\n>    - including when they come back - our stats shouldn\'t jump hugely\n> because an old review was resurrected\n>  - when good means submitters will be getting feedback\n>  - flag inventory- things we\'d be happy to have landed that haven\'t\n>    - including things with a -1 from non-core reviewers (*)\n> \n> (*) I often see -1\'s on things core wouldn\'t -1 due to the learning\n> curve involved in becoming core\n> \n> So, as Ben says, I think we need to address the its-not-a-vote issue\n> as a priority, that has tripped us up in lots of ways\n> \n> I think we need to discount -workflow patches where that was set by\n> the submitter, which AFAICT we don\'t do today.\n> \n> Looking at current stats:\n> Longest waiting reviews (based on oldest rev without -1 or -2):\n> \n> 54 days, 2 hours, 41 minutes https://review.openstack.org/106167\n> (Keystone/LDAP integration)\n> That patch had a -1 on Aug 16 1:23 AM: but was quickyl turned to +2.\n> \n> So this patch had a -1 then after discussion it became a +2. And its\n> evolved multiple times.\n> \n> What should we be saying here? Clearly its had little review input\n> over its life, so I think its sadly accurate.\n> \n> I wonder if a big chunk of our sliding quartile is just use not\n> reviewing the oldest reviews.\n\nI\'ve been researching review process in OpenStack and other projects for\na while, and my impression is that at least three timing metrics are\nrelevant:\n\n(1) Total time from submitting a patch to final closing of the review\nprocess (landing that, or a subsequent patch, or finally abandoning).\nThis gives an idea of how the whole process is working.\n\n(2) Time from submitting a patch to that patch being approved (+2 in\nOpenStack, I guess) or declined (and a new patch is requested). This\ngives an idea of how quick reviewers are providing definite feedback to\npatch submitters, and is a metric for each patch cycle.\n\n(3) Time from a patch being reviewed, with a new patch being requested,\nto a new patch being submitted. This gives an idea of the \"reaction\ntime\" of patch submitter.\n\nUsually, you want to keep (1) low, while (2) and (3) give you an idea of\nwhat is happening if (1) gets high.\n\nThere is another relevant metric in some cases, which is\n\n(4) The number of patch cycles per review cycle (that is, how many\npatches are needed per patch landing in master). In some cases, that may\nhelp to explain how (2) and (3) contribute to (1).\n\nAnd a fifth metric gives you a \"throughput\" metric:\n\n(5) BMI (backlog management index), number of new review processes by\nnumber of closed review process for a certain period. It gives an idea\nof whether the backlog is going up (>1) or down (<1), and is usually\nvery interesting when seen over time.\n\n(1) alone is not enough to assess on how well the review process is,\nbecause it could low, but (5) showing an increasing backlog because\nsimply new review requests come too quickly (eg, in periods when\ndevelopers are submitting a lot of patch proposals after a freeze). (1)\ncould also be high, but (5) show a decrease in the backlog, because for\nexample reviewers or submitters are overworked or slowly scheduled, but\nstill the project copes with the backlog. Depending on the relationship\nof (1) and (5), maybe you need more reviewers, or reviewers scheduling\ntheir reviews with more priority wrt other actions, or something else.\n\nNote for example that in a project with low BMI (<1) for a long period,\nbut with a high total delay in reviews (1), usually putting more\nreviewers doesn\'t reduce delay: you have enough of them, what you need\nis them to schedule reviews earlier (or maybe the problem is in\nsubmitters being late in addressing requests for new patches, you look\nat (2), (3) and (4) for that). \n\nI guess usually you need most of these metrics, if not all, to\nunderstand what is happening in a review process.\n\nSaludos,\n\n	Jesus.\n\n-- \nBitergia: http://bitergia.com\n/me at Twitter: https://twitter.com/jgbarah\n\n\n\n','<CAJ3HoZ1-5vEKQ+e8Zfowd=nYUp+0Pc67V8p5iLLYu7CQYLT0Hg@mail.gmail.com>',NULL),('<1409750675.9809.3.camel@debian.cloudwatt>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 15:24:35',7200,'2014-09-03 13:24:35',NULL,'[openstack-dev] [all] [glance] do NOT ever sort requirements.txt','On Wed, 2014-09-03 at 14:03 +0100, Daniel P. Berrange wrote:\n> On Wed, Sep 03, 2014 at 08:37:17AM -0400, Sean Dague wrote:\n> > I\'m not sure why people keep showing up with \"sort requirements\" patches\n> > like - https://review.openstack.org/#/c/76817/6, however, they do.\n> > \n> > All of these need to be -2ed with predjudice.\n> > \n> > requirements.txt is not a declarative interface. The order is important\n> > as pip processes it in the order it is. Changing the order has impacts\n> > on the overall integration which can cause wedges later.\n> \n> Can  requirements.txt contain comment lines ?  If so, it would be\n> worth adding \n> \n>    # The ordering of modules in this file is important\n>    # Do not attempt to re-sort the lines\n> \n> Because 6 months hence people will have probably forgotten about\n> this mail, or if they\'re new contributors, never know it existed.\n> \n> Regards,\n> Daniel\n\nYes, requirements.txt can contain comment lines.\nIt\'s a good idea to keep this information in the file itself.\n\nBest,\nRomain\n\n\n\n\n','<20140903130326.GA21650@redhat.com>',NULL),('<1409759868.1760590.163203209.60DD5232@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 08:57:48',-25200,'2014-09-03 15:57:48',NULL,'[openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x','On Wed, Sep 3, 2014, at 08:22 AM, Doug Hellmann wrote:\n> \n> On Sep 2, 2014, at 3:17 PM, Clark Boylan <cboylan at sapwetik.org> wrote:\n> \n> > On Tue, Sep 2, 2014, at 11:30 AM, Yuriy Taraday wrote:\n> >> Hello.\n> >> \n> >> Currently for alpha releases of oslo libraries we generate either\n> >> universal\n> >> or Python 2.x-only wheels. This presents a problem: we can\'t adopt alpha\n> >> releases in projects where Python 3.x is supported and verified in the\n> >> gate. I\'ve ran into this in change request [1] generated after\n> >> global-requirements change [2]. There we have oslotest library that can\'t\n> >> be built as a universal wheel because of different requirements (mox vs\n> >> mox3 as I understand is the main difference). Because of that py33 job in\n> >> [1] failed and we can\'t bump oslotest version in requirements.\n> >> \n> >> I propose to change infra scripts that generate and upload wheels to\n> >> create\n> >> py3 wheels as well as py2 wheels for projects that support Python 3.x (we\n> >> can use setup.cfg classifiers to find that out) but don\'t support\n> >> universal\n> >> wheels. What do you think about that?\n> >> \n> >> [1] https://review.openstack.org/117940\n> >> [2] https://review.openstack.org/115643\n> >> \n> >> -- \n> >> \n> >> Kind regards, Yuriy.\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > We may find that we will need to have py3k wheels in addition to the\n> > existing wheels at some point, but I don\'t think this use case requires\n> > it. If oslo.test needs to support python2 and python3 it should use mox3\n> > in both cases which claims to support python2.6, 2.7 and 3.2. Then you\n> > can ship a universal wheel. This should solve the immediate problem.\n> \n> That sounds like a good solution to that specific issue. It may also\n> require changes in the application test suites, but those changes can be\n> made as we move them to use oslotest.\n> \n> > \n> > It has been pointed out to me that one case where it won\'t be so easy is\n> > oslo.messaging and its use of eventlet under python2. Messaging will\n> > almost certainly need python 2 and python 3 wheels to be separate. I\n> > think we should continue to use universal wheels where possible and only\n> > build python2 and python3 wheels in the special cases where necessary.\n> > \n> > The setup.cfg classifiers should be able to do that for us, though PBR\n> > may need updating? We will also need to learn to upload potentially >1\n> \n> How do you see that working? We want all of the Oslo libraries to,\n> eventually, support both python 2 and 3. How would we use the classifiers\n> to tell when to build a universal wheel and when to build separate\n> wheels?\n> \nThe classifiers provide info on the versions of python we support. By\ndefault we can build python2 wheel if only 2 is supported, build python3\nwheel if only 3 is supported, build a universal wheel if both are\nsupported. Then we can add a setup.cfg flag to override the universal\nwheel default to build both a python2 and python3 wheel instead. Dstufft\nand mordred should probably comment on this idea before we implement\nanything.\n>\n> > wheel in our wheel jobs. That bit is likely straight foward. The last\n> > thing that we need to make sure we do is that we have some testing in\n> > place for the special wheels. We currently have the requirements\n> > integration test which runs under python2 checking that we can actually\n> > install all the things together. This ends up exercising our wheels and\n> > checking that they actually work. We don\'t have a python3 equivalent for\n> \n> We only know the wheels can be installed. We don?t actually have a test\n> that installs our code and runs it any more (devstack uses ?develop? mode\n> which bypasses some of the installation steps, as we found while fixing\n> the recent neutron/pbr issue with a missing config file in their\n> packaging instructions).\n> \nYup, this would be a second level of testing that we should consider as\nwell. The post install can it do stuff test. We moved our unittesting\naway from using sdist installs in preference for setup.py develop\nequivalent which means that our unittests no longer cover some of this\nstuff for us. Sorry if I hijacked this thread into a \"how do we test\nrelease artifacts?\" thread.\n>\n> > that job. It may be better to work out some explicit checking of the\n> > wheels we produce that applies to both versions of python. I am not\n> > quite sure how we should approach that yet.\n> \n> To fix the asymmetric gating we have between pbr and everything else,\n> Robert suggested setting up some sort of job to install pbr and then\n> build and install a package for the project being tested. We already, as\n> you point out, have a job that does this for all of the projects to test\n> changes to pbr itself. Maybe we can run the same test under python 2 and\n> 3 as part of the same job?\n> \nAnd to get that extra level of tested we can run the unittests in that\npackage install. We won\'t be able to run everything against python3\nbecause of missing support (well we can test installs but the second\nlevel testing will break if a project doesn\'t support python3 properly)\nso we will need some way of selecting that. Using two jobs may be\nsimplest. But that is an implementation detail.\n>\n> Doug\n> \n> > \n> > Clark\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<85F14357-75D9-4E6D-B138-F02F6EF0F618@doughellmann.com>',NULL),('<1409763896.1782911.163229889.3E7C0FAD@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 10:04:56',-25200,'2014-09-03 17:04:56',NULL,'[openstack-dev] znc as a service (was Re: [nova] Is the BP\n approval process broken?)','On Wed, Sep 3, 2014, at 07:26 AM, Ryan Brown wrote:\n> On 09/03/2014 09:35 AM, Sylvain Bauza wrote:\n> > Re: ZNC as a service, I think it\'s OK provided the implementation is\n> > open-sourced with openstack-infra repo group, as for Gerrit, Zuul and\n> > others.\n> > The only problem I can see is how to provide IRC credentials to this, as\n> > I don\'t want to share my creds up to the service.\n> > \n> > -Sylvain\n> There are more than just adoption (user trust) problems. An Open Source\n> implementation wouldn\'t solve the liability concerns, because users\n> would still have logs of their (potentially sensitive) credentials and\n> conversations on servers run by OpenStack Infra.\n> \n> This is different from Gerrit/Zuul etc which just display code/changes\n> and run/display tests on those public items. There isn\'t anything\n> sensitive to be leaked there. Storing credentials and private messages\n> is a different story, and would require much more security work than\n> just storing code and test results.\n> \n> -- \n> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThis doesn\'t solve the privacy issues, but subway [0] was built\nspecifically to tackle the problem of making persistent IRC easy without\nneeding to understand screen/tmux or znc/bip.\n\nMaybe we can sidestep the privacy concerns by providing scipts/puppet\nmanifests/disk image builder elements/something that individuals or\ngroups of people that have some form of trust between each other can use\nto easily spin up something like subway for persistent access.\nUnfortunately, this assumes that individuals or groups of people will\nhave a way to run a persistent service on a server of some sort which\nmay not always be the case.\n\n[0] https://github.com/thedjpetersen/subway\n\nClark\n\n\n','<5407251F.4090108@redhat.com>',NULL),('<1409771324-sup-938@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 19:12:26',0,'2014-09-03 19:12:26',NULL,'[openstack-dev] [Glance][Nova][All] requests 2.4.0 breaks\n	glanceclient','Excerpts from Kuvaja, Erno\'s message of 2014-09-03 12:30:08 +0000:\n> Hi All,\n> \n> While investigating glanceclient gating issues we narrowed it down to requests 2.4.0 which was released 2014-08-29. Urllib3 seems to be raising new ProtocolError which does not get catched and breaks at least glanceclient.\n> Following error can be seen on console \"ProtocolError: (\'Connection aborted.\', gaierror(-2, \'Name or service not known\'))\".\n> \n> Unfortunately we hit on such issue just under the freeze. Apparently this breaks novaclient as well and there is change (https://review.openstack.org/#/c/118332/ )proposed to requirements to limit the version <2.4.0.\n> \n> Is there any other projects using requirements and seeing issues with the latest version?\n\nWeve run into this in tripleo, specifically with os-collect-config.\nHeres the upstream bug:\nhttps://github.com/kennethreitz/requests/issues/2192\n\nWe had to pin it in our project to unwedge CI (otherwise we would be\nblocked on cutting an os-collect-config release).\n\n\n','<EA70533067B8F34F801E964ABCA4C4410C717C5E@G4W3202.americas.hpqcorp.net>',NULL),('<1409771390.1822820.163278809.6ABA5301@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 12:09:50',-25200,'2014-09-03 19:09:50',NULL,'[openstack-dev] [all] [glance] do NOT ever sort requirements.txt','\n\nOn Wed, Sep 3, 2014, at 11:51 AM, Kuvaja, Erno wrote:\n> > -----Original Message-----\n> > From: Sean Dague [mailto:sean at dague.net]\n> > Sent: 03 September 2014 13:37\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt\n> > \n> > I\'m not sure why people keep showing up with \"sort requirements\" patches\n> > like - https://review.openstack.org/#/c/76817/6, however, they do.\n> > \n> > All of these need to be -2ed with predjudice.\n> > \n> > requirements.txt is not a declarative interface. The order is important as pip\n> > processes it in the order it is. Changing the order has impacts on the overall\n> > integration which can cause wedges later.\n> > \n> > So please stop.\n> > \n> > 	-Sean\n> > \n> > --\n> > Sean Dague\n> > http://dague.net\n> >\n> \n> Hi Sean & all,\n> \n> Could you please open this up a little bit? What are we afraid breaking\n> regarding the order of these requirements? I tried to go through pip\n> documentation but I could not find reason of specific order of the lines,\n> references to keep the order there was \'though.\n> \n> I\'m now assuming one thing here as I do not know if that\'s the case. None\n> of the packages enables/disables functionality depending of what has been\n> installed on the system before, but they have their own dependencies to\n> provide those. Based on this assumption I can think of only one scenario\n> causing us issues. That is us abusing the example in point 2 of\n> https://pip.pypa.io/en/latest/user_guide.html#requirements-files meaning;\n> we install package X depending on package Y>=1.0,<2.0 before installing\n> package Z depending on Y>=1.0 to ensure that package Y<2.0 without\n> pinning package Y in our requirements.txt. I certainly hope that this is\n> not the case as depending 3rd party vendor providing us specific version\n> of dependency package would be extremely stupid.\n> \n> Other than that I really don\'t know how the order could cause us issues,\n> but I would be really happy to learn something new today if that is the\n> case or if my assumption went wrong.\n> \n> Best Regards,\n> Erno (jokke_) Kuvaja\n>  \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThe issue is described in the bug that Josh linked\n(https://github.com/pypa/pip/issues/988). Basically pip doesn\'t do\ndependency resolution in a way that lets you treat requirements as order\nindependent. For that to be the case pip would have to evaluate all\ndependencies together then install the intersection of those\ndependencies. Instead it iterates over the list(s) in order and\nevaluates each dependency as it is found.\n\nYour example basically describes where this breaks. You can both depend\non the same dependency at different versions and pip will install a\nversion that satisfies only one of the dependencies and not the other\nleading to a failed install. However I think a more common case is that\nopenstack will pin a dependency and say Y>=1.0,<2.0 and the X dependency\nwill say Y>=1.0. If the X dependency comes first you get version 2.5\nwhich is not valid for your specification of Y>=1.0,<2.0 and pip fails.\nYou fix this by listing Y before X dependency that installs Y with less\nrestrictive boundaries.\n\nAnother example of a slightly different failure would be hacking,\nflake8, pep8, and pyflakes. Hacking installs a specific version of\nflake8, pep8, and pyflakes so that we do static lint checking with\nconsistent checks each release. If you sort this list alphabetically\ninstead of allowing hacking to install its deps flake8 will come first\nand you can get a different version of pep8. Different versions of pep8\ncheck different things and now the gate has broken.\n\nThe most problematic thing is you can\'t count on your dependencies from\nnot breaking you if they come first (because they are evaluated first).\nSo in cases where we know order is important (hacking and pbr and\nprobably a handful of others) we should be listing them as early as\npossible in the requirements.\n\nClark\n\n\n','<EA70533067B8F34F801E964ABCA4C4410C717FC1@G4W3202.americas.hpqcorp.net>',NULL),('<1409777828.1856041.163323113.14944658@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 13:57:08',-25200,'2014-09-03 20:57:08',NULL,'[openstack-dev] [all] [glance] do NOT ever sort requirements.txt','\n\nOn Wed, Sep 3, 2014, at 01:06 PM, Kuvaja, Erno wrote:\n> > -----Original Message-----\n> > From: Clark Boylan [mailto:cboylan at sapwetik.org]\n> > Sent: 03 September 2014 20:10\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt\n> > \n> > \n> > \n> > On Wed, Sep 3, 2014, at 11:51 AM, Kuvaja, Erno wrote:\n> > > > -----Original Message-----\n> > > > From: Sean Dague [mailto:sean at dague.net]\n> > > > Sent: 03 September 2014 13:37\n> > > > To: OpenStack Development Mailing List (not for usage questions)\n> > > > Subject: [openstack-dev] [all] [glance] do NOT ever sort\n> > > > requirements.txt\n> > > >\n> > > > I\'m not sure why people keep showing up with \"sort requirements\"\n> > > > patches like - https://review.openstack.org/#/c/76817/6, however, they\n> > do.\n> > > >\n> > > > All of these need to be -2ed with predjudice.\n> > > >\n> > > > requirements.txt is not a declarative interface. The order is\n> > > > important as pip processes it in the order it is. Changing the order\n> > > > has impacts on the overall integration which can cause wedges later.\n> > > >\n> > > > So please stop.\n> > > >\n> > > > 	-Sean\n> > > >\n> > > > --\n> > > > Sean Dague\n> > > > http://dague.net\n> > > >\n> > >\n> > > Hi Sean & all,\n> > >\n> > > Could you please open this up a little bit? What are we afraid\n> > > breaking regarding the order of these requirements? I tried to go\n> > > through pip documentation but I could not find reason of specific\n> > > order of the lines, references to keep the order there was \'though.\n> > >\n> > > I\'m now assuming one thing here as I do not know if that\'s the case.\n> > > None of the packages enables/disables functionality depending of what\n> > > has been installed on the system before, but they have their own\n> > > dependencies to provide those. Based on this assumption I can think of\n> > > only one scenario causing us issues. That is us abusing the example in\n> > > point 2 of\n> > > https://pip.pypa.io/en/latest/user_guide.html#requirements-files\n> > > meaning; we install package X depending on package Y>=1.0,<2.0 before\n> > > installing package Z depending on Y>=1.0 to ensure that package Y<2.0\n> > > without pinning package Y in our requirements.txt. I certainly hope\n> > > that this is not the case as depending 3rd party vendor providing us specific\n> > version of dependency package would be extremely stupid.\n> > >\n> > > Other than that I really don\'t know how the order could cause us\n> > > issues, but I would be really happy to learn something new today if\n> > > that is the case or if my assumption went wrong.\n> > >\n> > > Best Regards,\n> > > Erno (jokke_) Kuvaja\n> > >\n> > > > _______________________________________________\n> > > > OpenStack-dev mailing list\n> > > > OpenStack-dev at lists.openstack.org\n> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > The issue is described in the bug that Josh linked\n> > (https://github.com/pypa/pip/issues/988). Basically pip doesn\'t do\n> > dependency resolution in a way that lets you treat requirements as order\n> > independent. For that to be the case pip would have to evaluate all\n> > dependencies together then install the intersection of those dependencies.\n> > Instead it iterates over the list(s) in order and evaluates each dependency as\n> > it is found.\n> > \n> > Your example basically describes where this breaks. You can both depend on\n> > the same dependency at different versions and pip will install a version that\n> > satisfies only one of the dependencies and not the other leading to a failed\n> > install. However I think a more common case is that openstack will pin a\n> > dependency and say Y>=1.0,<2.0 and the X dependency will say Y>=1.0. If\n> > the X dependency comes first you get version 2.5 which is not valid for your\n> > specification of Y>=1.0,<2.0 and pip fails.\n> > You fix this by listing Y before X dependency that installs Y with less restrictive\n> > boundaries.\n> > \n> > Another example of a slightly different failure would be hacking, flake8,\n> > pep8, and pyflakes. Hacking installs a specific version of flake8, pep8, and\n> > pyflakes so that we do static lint checking with consistent checks each\n> > release. If you sort this list alphabetically instead of allowing hacking to install\n> > its deps flake8 will come first and you can get a different version of pep8.\n> > Different versions of pep8 check different things and now the gate has\n> > broken.\n> > \n> > The most problematic thing is you can\'t count on your dependencies from\n> > not breaking you if they come first (because they are evaluated first).\n> > So in cases where we know order is important (hacking and pbr and probably\n> > a handful of others) we should be listing them as early as possible in the\n> > requirements.\n> > \n> > Clark\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> Thanks Clark,\n> \n> To be honest the issue nor your explanation did clarify this to me.\n> Please forgive me hunting this, but it seems to be extremely important\n> topic so I would like to understand where it\'s coming from (and hopefully\n> others will benefit from it too). \n> \n> So if I got this right the problem is the dependencies that has not been\n> pinned. Even that issue which has been open is pretty clear about that.\n> Also by the pip documentation and the issue text itself if we have those\n> dependencies pinned to our limits on the first level (our\n> requirements.txt) they will be obeyed regardless where they are on the\n> file. Just their dependencies (that are not listed) are not going to be\n> cross checked.\n> \n> Now wouldn\'t it be right way to attack this problem to actually specify\n> the limits so that we have all of them in the requirements (and they\n> don\'t break if the maintainer of that first one happens to change the\n> dependencies) rather than trusting the order giving us right\n> dependencies?\n> \nPinning all transitive dependencies in all OpenStack projects so that we\ncan avoid a handful of conflicts is not worth it. OpenStack has a couple\nhundred first level dependencies [0] and it is enough work loosely\nmanaging those. Conflicts arise when two first level dependencies have\nsimilar but conflicting second level or more recursive dependencies that\nconflict. We can avoid those conflicts with simple ordering of\ndependency files which is much easier than the alternative.\n\nI do not see any benefit to a naive sort of requirements files but there\nis a benefit to giving them a specific order so that we can avoid these\nconflicts.\n\nIt is also worth nothing that finding new failures as they happen is\nbeneficial. It is painful, but without it there is very little in the\nway of advance warning. You want to find this stuff out as soon as\npossible and not at release time.\n\n[0]\nhttps://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt\n\nClark\n\n\n','<EA70533067B8F34F801E964ABCA4C4410C718071@G4W3202.americas.hpqcorp.net>',NULL),('<1409797568.10073.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 02:26:07',0,'2014-09-04 02:26:07',NULL,'[openstack-dev] [infra][qa][neutron] Neutron full job,\n advanced services, and the integrated gate','On Wed, 2014-09-03 at 15:41 -0500, Kyle Mestery wrote:\n> On Wed, Sep 3, 2014 at 3:22 PM, Sean Dague <sean at dague.net> wrote:\n> > On 08/26/2014 07:47 PM, Salvatore Orlando wrote:\n> >> TL; DR\n> >> A few folks are proposing to stop running tests for neutron advanced\n> >> services [ie: (lb|vpn|fw)aas] in the integrated gate, and run them only\n> >> on the neutron gate.\n> >>\n> >> Reason: projects like nova are 100% orthogonal to neutron advanced\n> >> services. Also, there have been episodes in the past of unreliability of\n> >> tests for these services, and it would be good to limit affected\n> >> projects considering that more api tests and scenarios are being added.\n> >>\n> >> -----\n> >>\n> >> So far the neutron full job runs tests (api and scenarios) for neutron\n> >> \"core\" functionality as well as neutron \"advanced services\", which run\n> >> as neutron service plugin.\n> >>\n> >> It\'s highly unlikely, if not impossible, that changes in projects such\n> >> as nova, glance or ceilometer can have an impact on the stability of\n> >> these services.\n> >> On the other hand, instability in these services can trigger gate\n> >> failures in unrelated projects as long as tests for these services are\n> >> run in the neutron full job in the integrated gate. There have already\n> >> been several gate-breaking bugs in lbaas scenario tests are firewall api\n> >> tests.\n> >> Admittedly, advanced services do not have the same level of coverage as\n> >> core neutron functionality. Therefore as more tests are being added,\n> >> there is an increased possibility of unearthing dormant bugs.\n> >>\n> >> For this reason we are proposing to not run anymore tests for neutron\n> >> advanced services in the integrated gate, but keep them running on the\n> >> neutron gate.\n> >> This means we will have two neutron jobs:\n> >> 1) check-tempest-dsvm-neutron-full which will run only \"core\" neutron\n> >> functionality\n> >> 2) check-tempest-dsvm-neutron-full-ext which will be what the neutron\n> >> full job is today.\n> >>\n> >> The former will be part of the integrated gate, the latter will be part\n> >> of the neutron gate.\n> >> Considering that other integrating services should not have an impact on\n> >> neutron advanced services, this should not make gate testing asymmetric.\n> >>\n> >> However, there might be exceptions for:\n> >> - \"orchestration\" project like heat which in the future might leverage\n> >> capabilities like load balancing\n> >> - oslo-* libraries, as changes in them might have an impact on neutron\n> >> advanced services, since they consume those libraries\n> >>\n> >> Another good question is whether \"extended\" tests should be performed as\n> >> part of functional or tempest checks. My take on this is that scenario\n> >> tests should always be part of tempest. On the other hand I reckon API\n> >> tests should exclusively be part of functional tests, but as so far\n> >> tempest is running a gazillion of API tests, this is probably a\n> >> discussion for the medium/long term.\n> >>\n> >> In order to add this new job there are a few patches under review:\n> >> [1] and [2] Introduces the \'full-ext\' job and devstack-gate support for it.\n> >> [3] Are the patches implementing a blueprint which will enable us to\n> >> specify for which extensions test should be executed.\n> >>\n> >> Finally, one more note about smoketests. Although we\'re planning to get\n> >> rid of them soon, we still have failures in the pg job because of [4].\n> >> For this reasons smoketests are still running for postgres in the\n> >> integrated gate. As load balancing and firewall API tests are part of\n> >> it, they should be removed from the smoke test executed on the\n> >> integrated gate ([5], [6]). This is a temporary measure until the\n> >> postgres issue is fixed.\n> >>\n> >> Regards,\n> >> Salvatore\n> >>\n> >> [1] https://review.openstack.org/#/c/114933/\n> >> [2] https://review.openstack.org/#/c/114932/\n> >> [3] https://review.openstack.org/#/q/status:open+branch:master+topic:bp/branchless-tempest-extensions,n,z\n> >> [4] https://bugs.launchpad.net/nova/+bug/1305892\n> >> [5] https://review.openstack.org/#/c/115022/\n> >> [6] https://review.openstack.org/#/c/115023/\n> >\n> > +1\n> >\n> > I realistically think that we should think about neutron as 2 things.\n> > The L2/L3 services, and the advanced services. L2/L3 seem appropriate to\n> > ensure are tightly integrated to the rest of OpenStack. The advanced\n> > services really are a different beast (and honestly might be better as a\n> > separate OpenStack service that\'s not neutron).\n> >\n> There is talk about spinning these out into a separate\n> repository/project under the networking program. LBaaS V2, for\n> example, is almost certainly going to end up this way. It\'s not\n> unreasonable to think we could do the same with the other services as\n> well.\n\nSpinning out is definitely a goal for the LBaaS team.  This is not only\nbeneficial to LBaaS but also beneficial to Neutron because Neutron\'s\nscope will shrink and it\'s focus more precise.  Getting to that point\nwill require effort from both sides.\n\n> \n> Thanks,\n> Kyle\n> \n> >         -Sean\n> >\n> > --\n> > Sean Dague\n> > http://dague.net\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAL3VkVwWVVHUeOssrHJHNhb7iXbwWk5m6kOuJCVosEdk_wgRNw@mail.gmail.com>',NULL),('<1409797932.10073.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 02:32:11',0,'2014-09-04 02:32:11',NULL,'[openstack-dev] [infra][qa][neutron] Neutron full job,\n advanced services, and the integrated gate','On Wed, 2014-09-03 at 23:10 +0200, Salvatore Orlando wrote:\n> \n> \n> On 3 September 2014 22:10, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n>         \n>         \n>         \n>         On Tue, Aug 26, 2014 at 4:47 PM, Salvatore Orlando\n>         <sorlando at nicira.com> wrote:\n>                 TL; DR\n>                 A few folks are proposing to stop running tests for\n>                 neutron advanced services [ie: (lb|vpn|fw)aas] in the\n>                 integrated gate, and run them only on the neutron\n>                 gate.\n>                 \n>                 \n>                 Reason: projects like nova are 100% orthogonal to\n>                 neutron advanced services. Also, there have been\n>                 episodes in the past of unreliability of tests for\n>                 these services, and it would be good to limit affected\n>                 projects considering that more api tests and scenarios\n>                 are being added.\n>                 \n>                 \n>                 -----\n>                 \n>                 \n>                 So far the neutron full job runs tests (api and\n>                 scenarios) for neutron \"core\" functionality as well as\n>                 neutron \"advanced services\", which run as neutron\n>                 service plugin.\n>                 \n>                 \n>                 It\'s highly unlikely, if not impossible, that changes\n>                 in projects such as nova, glance or ceilometer can\n>                 have an impact on the stability of these services.\n>                 On the other hand, instability in these services can\n>                 trigger gate failures in unrelated projects as long as\n>                 tests for these services are run in the neutron full\n>                 job in the integrated gate. There have already been\n>                 several gate-breaking bugs in lbaas scenario tests are\n>                 firewall api tests.\n>                 \n>                 Admittedly, advanced services do not have the same\n>                 level of coverage as core neutron functionality.\n>                 Therefore as more tests are being added, there is an\n>                 increased possibility of unearthing dormant bugs.\n>                 \n>                 \n>         \n>         \n>         I support this split but for slightly different reasons.  I am\n>         under the impression that neutron advanced services are not\n>         ready for prime time. If that is correct I don\'t think we\n>         should be gating on things that aren\'t ready.\n> \n> \n> I deliberately avoided going into this field in my first post as I did\n> not want my personal opinions to appear as those of the Neutron\n> project core team.\n> Neutron has so far 5 \"service\" plugins. Of those I believe l3 and\n> metering are part of what is neutron core functionality, and, as\n> stated by Sean, should be tested as part of the integrated gate.\n> Metering is a bit of an accessory service so I\'m +/- 0 on whether it\n> should be part or not of integrated gate tests.\n> \n> \n> For load balancing, v1 has been considered fairly stable for a while.\n> However, as it\'s being overhauled with lbaas v2 activities, I might\n> question its production readiness.\n> For VPN, we just do not have yet enough data points to assess its\n> stability in the gate (no scenario test), or production readiness.\n> For firewall, my impression is that it still considered an\n> experimental feature, but I might be mistaken.\n\nComing from a guy who wrote a good portion of the LBaaS V2 code, I agree\nwith Salvatore that I don\'t think it is production ready either, mainly\nbecause there is no driver support for it yet and the reference\nimplementation is not scalable yet. It would be naive and reckless to\nthink it was ready for production. So it is going into the incubator.\n> \n> \n> Considering the above I would also subscribe to Joe\'s point - under\n> the assumption that only things that are production ready should be\n> tested in the integrated gate.\n>  \n>         \n>         \n>          \n>                 For this reason we are proposing to not run anymore\n>                 tests for neutron advanced services in the integrated\n>                 gate, but keep them running on the neutron gate.\n>                 This means we will have two neutron jobs:\n>                 1) check-tempest-dsvm-neutron-full which will run only\n>                 \"core\" neutron functionality\n>                 2) check-tempest-dsvm-neutron-full-ext which will be\n>                 what the neutron full job is today.\n>         \n>         \n>         Using my breakdown, the extended job would include\n>         experimental neutron features. \n>          \n>                 \n>                 \n>                 The former will be part of the integrated gate, the\n>                 latter will be part of the neutron gate.\n>                 Considering that other integrating services should not\n>                 have an impact on neutron advanced services, this\n>                 should not make gate testing asymmetric.\n>                 \n>                 \n>                 However, there might be exceptions for:\n>                 - \"orchestration\" project like heat which in the\n>                 future might leverage capabilities like load balancing\n>                 - oslo-* libraries, as changes in them might have an\n>                 impact on neutron advanced services, since they\n>                 consume those libraries\n>         \n>         \n>         Once another service starts consuming an advanced feature I\n>         think it makes sense to move it to the main neutron-full job.\n>         Especially if we assume that things will only depend on\n>         neutron features that are not too experimental.\n> \n> \n> Correct. Shifting services from neutron\'s full-ext to the integrated\n> gate full job should be easy especially if these projects are spun\n> out.\n> \n> \n>          \n>                 \n>                 \n>                 Another good question is whether \"extended\" tests\n>                 should be performed as part of functional or tempest\n>                 checks. My take on this is that scenario tests should\n>                 always be part of tempest. On the other hand I reckon\n>                 API tests should exclusively be part of functional\n>                 tests, but as so far tempest is running a gazillion of\n>                 API tests, this is probably a discussion for the\n>                 medium/long term. \n>                 \n>                 \n>                 In order to add this new job there are a few patches\n>                 under review:\n>                 [1] and [2] Introduces the \'full-ext\' job and\n>                 devstack-gate support for it.\n>                 [3] Are the patches implementing a blueprint which\n>                 will enable us to specify for which extensions test\n>                 should be executed.\n>                 \n>                 \n>                 Finally, one more note about smoketests. Although\n>                 we\'re planning to get rid of them soon, we still have\n>                 failures in the pg job because of [4]. For this\n>                 reasons smoketests are still running for postgres in\n>                 the integrated gate. As load balancing and firewall\n>                 API tests are part of it, they should be removed from\n>                 the smoke test executed on the integrated gate ([5],\n>                 [6]). This is a temporary measure until the postgres\n>                 issue is fixed.\n>         \n>         \n>         ++\n>          \n>                 \n>                 \n>                 Regards,\n>                 Salvatore\n>                 \n>                 \n>                 [1] https://review.openstack.org/#/c/114933/\n>                 [2] https://review.openstack.org/#/c/114932/\n>                 [3] https://review.openstack.org/#/q/status:open\n>                 +branch:master\n>                 +topic:bp/branchless-tempest-extensions,n,z\n>                 [4] https://bugs.launchpad.net/nova/+bug/1305892\n>                 [5] https://review.openstack.org/#/c/115022/\n>                 [6] https://review.openstack.org/#/c/115023/\n>                 \n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAGR=i3jLg4cqR9Rq6dBhJ8Ey9GaRkZU000vX=QVVA6w6zXnV-Q@mail.gmail.com>',NULL),('<1409798572.10073.18.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 02:42:51',0,'2014-09-04 02:42:51',NULL,'[openstack-dev]  [Neutron][LBass] Item for the meeting tomorrow','Since progress on LBaaS V2 has come to a halt due to the incubator\nlimbo, but mainly because development focus has been put on Octavia for\nmost of the team, I\'d like to suggest discussing whether it is worth\npursuing a solution to the issue (at least what I see as an issue) of\ndrivers being responsible for the status management of entities.  \n\nI\'d rather that status management be taken care of at the plugin layer.\nIf something went wrong then the driver would raise an exception.  The\nplugin would handle the set the status according to what exception\nhappened, usually ERROR.  Currently the problem with doing this is that\ndrivers can be asynchronous, so easily doing this is not an option.  I\nattempted to do this before with the naive assumption that all drivers\nnot using the agent were synchronous.\n\nI\'ve got a possible solution for this problem, but a proof of concept\nwould first need to be done just to verify.  Plus, it would be tough to\ndo without the support of driver maintainers.  So I\'d like to discuss\nthis in the meeting tomorrow morning after any major issues, which I\ndon\'t know of any.\n\nThanks,\nBrandon\n\n','<CAGR=i3hrLyEacrGj_4vxRDsyR0iiREnat7iOyVvCTfRfB3pFCg@mail.gmail.com>',NULL),('<1409816859-sup-4365@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 01:30:44',-25200,'2014-09-04 08:30:44',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Flavio Percoco\'s message of 2014-09-04 00:08:47 -0700:\n> Greetings,\n> \n> Last Tuesday the TC held the first graduation review for Zaqar. During\n> the meeting some concerns arose. I\'ve listed those concerns below with\n> some comments hoping that it will help starting a discussion before the\n> next meeting. In addition, I\'ve added some comments about the project\n> stability at the bottom and an etherpad link pointing to a list of use\n> cases for Zaqar.\n> \n\nHi Flavio. This was an interesting read. As somebody whose attention has\nrecently been drawn to Zaqar, I am quite interested in seeing it\ngraduate.\n\n> # Concerns\n> \n> - Concern on operational burden of requiring NoSQL deploy expertise to\n> the mix of openstack operational skills\n> \n> For those of you not familiar with Zaqar, it currently supports 2 nosql\n> drivers - MongoDB and Redis - and those are the only 2 drivers it\n> supports for now. This will require operators willing to use Zaqar to\n> maintain a new (?) NoSQL technology in their system. Before expressing\n> our thoughts on this matter, let me say that:\n> \n>     1. By removing the SQLAlchemy driver, we basically removed the chance\n> for operators to use an already deployed \"OpenStack-technology\"\n>     2. Zaqar won\'t be backed by any AMQP based messaging technology for\n> now. Here\'s[0] a summary of the research the team (mostly done by\n> Victoria) did during Juno\n>     3. We (OpenStack) used to require Redis for the zmq matchmaker\n>     4. We (OpenStack) also use memcached for caching and as the oslo\n> caching lib becomes available - or a wrapper on top of dogpile.cache -\n> Redis may be used in place of memcached in more and more deployments.\n>     5. Ceilometer\'s recommended storage driver is still MongoDB, although\n> Ceilometer has now support for sqlalchemy. (Please correct me if I\'m wrong).\n> \n> That being said, it\'s obvious we already, to some extent, promote some\n> NoSQL technologies. However, for the sake of the discussion, lets assume\n> we don\'t.\n> \n> I truly believe, with my OpenStack (not Zaqar\'s) hat on, that we can\'t\n> keep avoiding these technologies. NoSQL technologies have been around\n> for years and we should be prepared - including OpenStack operators - to\n> support these technologies. Not every tool is good for all tasks - one\n> of the reasons we removed the sqlalchemy driver in the first place -\n> therefore it\'s impossible to keep an homogeneous environment for all\n> services.\n> \n\nI whole heartedly agree that non traditional storage technologies that\nare becoming mainstream are good candidates for use cases where SQL\nbased storage gets in the way. I wish there wasn\'t so much FUD\n(warranted or not) about MongoDB, but that is the reality we live in.\n\n> With this, I\'m not suggesting to ignore the risks and the extra burden\n> this adds but, instead of attempting to avoid it completely by not\n> evolving the stack of services we provide, we should probably work on\n> defining a reasonable subset of NoSQL services we are OK with\n> supporting. This will help making the burden smaller and it\'ll give\n> operators the option to choose.\n> \n> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> \n> \n> - Concern on should we really reinvent a queue system rather than\n> piggyback on one\n> \n> As mentioned in the meeting on Tuesday, Zaqar is not reinventing message\n> brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack\n> flavor on top. [0]\n> \n\nI think Zaqar is more like SMTP and IMAP than AMQP. You\'re not really\ntrying to connect two processes in real time. You\'re trying to do fully\nasynchronous messaging with fully randomized access to any message.\n\nPerhaps somebody should explore whether the approaches taken by large\nscale IMAP providers could be applied to Zaqar.\n\nAnyway, I can\'t imagine writing a system to intentionally use the\nsemantics of IMAP and SMTP. I\'d be very interested in seeing actual use\ncases for it, apologies if those have been posted before.\n\n> Some things that differentiate Zaqar from SQS is it\'s capability for\n> supporting different protocols without sacrificing multi-tenantcy and\n> other intrinsic features it provides. Some protocols you may consider\n> for Zaqar are: STOMP, MQTT.\n> \n> As far as the backend goes, Zaqar is not re-inventing it either. It sits\n> on top of existing storage technologies that have proven to be fast and\n> reliable for this task. The choice of using NoSQL technologies has a lot\n> to do with this particular thing and the fact that Zaqar needs a storage\n> capable of scaling, replicating and good support for failover.\n> \n\nWhat\'s odd to me is that other systems like Cassandra and Riak are not\nbeing discussed. There are well documented large scale message storage\nsystems on both, and neither is encumbered by the same licensing FUD\nas MongoDB.\n\nAnyway, again if we look at this as a place to storage and retrieve\nmessages, and not as a queue, then talking about databases, instead of\nmessage brokers, makes a lot more sense.\n\n> \n> - concern on the maturity of the NoQSL not AGPL backend (Redis)\n> \n> Redis backend just landed and I\'ve been working on a gate job for it\n> today. Although it hasn\'t been tested in production, if Zaqar graduates,\n> it still has a full development cycle to be tested and improved before\n> the first integrated release happens.\n> \n\nI\'d be quite interested to see how it is expected to scale. From my very\nquick reading of the driver, it only supports a single redis server. No\nconsistent hash ring or anything like that.\n\n> # Use Cases\n> \n> In addition to the aforementioned concerns and comments, I also would\n> like to share an etherpad that contains some use cases that other\n> integrated projects have for Zaqar[0]. The list is not exhaustive and\n> it\'ll contain more information before the next meeting.\n> \n> [0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases\n> \n\nJust taking a look, there are two basic applications needed:\n\n1) An inbox. Horizon wants to know when snapshots are done. Heat wants\nto know what happened during a stack action. Etc.\n\n2) A user-focused message queue. Heat wants to push data to agents.\nSwift wants to synchronize processes when things happen.\n\nTo me, #1 is Zaqar as it is today. #2 is the one that I worry may not\nbe served best by bending #1 onto it.\n\n\n','<54080FFF.3060203@redhat.com>',NULL),('<1409840182741.45677@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-04 14:09:50',0,'2014-09-04 14:09:50',NULL,'[Openstack] error whe creating fisrt keystone user','Hi Stephane,\n\n\nPlease check if keystone service is running or not?\n\ncommand: service openstack-keystone status\n\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: Stephane EVEILLARD <stephane.eveillard at gmail.com>\nSent: Thursday, September 4, 2014 7:17 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] error whe creating fisrt keystone user\n\nHi,\n\nwhen I try to create admin user in keystone,\n\n\nI got the following message :\"The resource could not be found (HTTP 404)\"\n\nand the only message I got in keystone.log is the following :\n\n\"2014-09-04 15:41:56.432 2406 WARNING keystone.openstack.common.versionutils [-] Deprecated: keystone.middleware.core.XmlBodyMiddleware is deprecated as of Icehouse in favor of support for \"application/json\" only and may be removed in K.\"\n\nI\'m tring to install openstack on CentOS 6.4, got no error messages till this one\n\nThanks in advance\n\n\n--\nSt?phane EVEILLARD\nResponsable Syst?me et D?veloppement IBS NETWORK\nCoordinateur Version Fran?aise Openstack\nMembre Association Openstack-fr et  APRIL\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140904/194f6bf6/attachment.html>\n\n','<CAJ9Xk2Cpg8Br19HpK4oRkkZDjYziD51_nyja=sGwC+ZGasCurg@mail.gmail.com>',NULL),('<1409840945282.29816@accenture.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-04 14:28:58',0,'2014-09-04 14:28:58',NULL,'[Openstack]  nova resize error','Hi All,\n\nI am trying to resize the tiny flavor to small using Cirros image in Openstack Icehouse.\n\nI can go ahead and resize, it says 100% complete when I try the resize-confirm\ncommand it gives the below error:\n\n\nnova resize-confirm xxxxxxxxxxxx\nERROR: Cannot \'confirmResize\' while instance is in vm_state active (HTTP 409)\n\nPlease let me know if we have an option to resize flavor in Icehouse?\n\n\nRegards,\nRaghavendra Lad\n\n\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140904/2b8eb88d/attachment.html>\n\n',NULL,NULL),('<1409840963627.1910@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-04 14:22:52',0,'2014-09-04 14:22:52',NULL,'[Openstack] error whe creating fisrt keystone user','Okay,\n\n\nWere you able to create tenant successfully?\n\nand what all variables did you export? please check if OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT have proper values. And try by restarting the keystone service once?\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: Stephane EVEILLARD <stephane.eveillard at gmail.com>\nSent: Thursday, September 4, 2014 7:44 PM\nTo: Sushma Korati\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] error whe creating fisrt keystone user\n\nI\'ve Checked before but get a second look : service is running\n\n\n\n\n2014-09-04 16:09 GMT+02:00 Sushma Korati <sushma_korati at persistent.co.in<mailto:sushma_korati at persistent.co.in>>:\n\nHi Stephane,\n\n\nPlease check if keystone service is running or not?\n\ncommand: service openstack-keystone status\n\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in<mailto:sushma_korati at persistent.co.in>\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com<http://www.persistentsys.com>\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: Stephane EVEILLARD <stephane.eveillard at gmail.com<mailto:stephane.eveillard at gmail.com>>\nSent: Thursday, September 4, 2014 7:17 PM\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: [Openstack] error whe creating fisrt keystone user\n\nHi,\n\nwhen I try to create admin user in keystone,\n\n\nI got the following message :\"The resource could not be found (HTTP 404)\"\n\nand the only message I got in keystone.log is the following :\n\n\"2014-09-04 15:41:56.432 2406 WARNING keystone.openstack.common.versionutils [-] Deprecated: keystone.middleware.core.XmlBodyMiddleware is deprecated as of Icehouse in favor of support for \"application/json\" only and may be removed in K.\"\n\nI\'m tring to install openstack on CentOS 6.4, got no error messages till this one\n\nThanks in advance\n\n\n--\nSt?phane EVEILLARD\nResponsable Syst?me et D?veloppement IBS NETWORK\nCoordinateur Version Fran?aise Openstack\nMembre Association Openstack-fr et  APRIL\n\nDISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n\n\n--\nSt?phane EVEILLARD\nResponsable Syst?me et D?veloppement IBS NETWORK\nCoordinateur Version Fran?aise Openstack\nMembre Association Openstack-fr et  APRIL\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140904/5d9157ff/attachment.html>\n\n','<CAJ9Xk2B8Rn7rqC_6bPgf-VYKTie5K1g0FvpL3PuuYX-q6=gUoQ@mail.gmail.com>',NULL),('<1409842625.2837.9.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:57:05',-14400,'2014-09-04 14:57:05',NULL,'[openstack-dev] [sahara] integration tests in\n python-saharaclient','Yes, I wrote them.  I use them all the time -- no typo that I know of.\nThey are great for spinning up a cluster and running EDP jobs.\n\nThey may need some polish, but the point is to test the whole chain of\noperations from the CLI.  This is contrary to what most OpenStack\nprojects traditionally do -- most CLI testing is only transformation\ntesting, that is it tests the output of CLI commands in Tempest but does\nnot test any kind of integration from the CLI.\n\nDifferent communities however will have different requirements.  At Red\nHat, for instance, many of our customers rely heavily on the command\nline, and our testing includes integration tests from the CLI as the\nentry point.  We want this kind of testing.\n\nIn fact, in the Icehouse release I found a bug by running the CLI\nintegration tests.  There was a mismatch between the CLI and Sahara.\n\nThese tests are not run in CI currently, however, when/if we end up with\nmore horsepower in CI they should be.  They should not be deleted.\n\nBest,\n\nTrevor\n\nOn Wed, 2014-09-03 at 14:58 -0700, Andrew Lazarev wrote:\n> Hi team,\n> \n> \n> Today I\'ve realized that we have some tests called \'integration\'\n> in python-saharaclient. Also I\'ve found out that Jenkins doesn\'t use\n> them and they can\'t be run starting from April because of typo in\n> tox.ini.\n> \n> \n> Does anyone know what these tests are? Does anyone mind if I delete\n> them since we don\'t use them anyway?\n> \n> \n> Thanks,\n> Andrew.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CANzyysg7q4cja3U3bcEaXu0zLUR5NCweUnLcz9KrgtOeoVxx=g@mail.gmail.com>',NULL),('<1409842730.2837.10.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:58:50',-14400,'2014-09-04 14:58:50',NULL,'[openstack-dev] [sahara] integration tests in\n python-saharaclient','by the way, what typo?\n\nTrev\n\nOn Wed, 2014-09-03 at 14:58 -0700, Andrew Lazarev wrote:\n> Hi team,\n> \n> \n> Today I\'ve realized that we have some tests called \'integration\'\n> in python-saharaclient. Also I\'ve found out that Jenkins doesn\'t use\n> them and they can\'t be run starting from April because of typo in\n> tox.ini.\n> \n> \n> Does anyone know what these tests are? Does anyone mind if I delete\n> them since we don\'t use them anyway?\n> \n> \n> Thanks,\n> Andrew.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CANzyysg7q4cja3U3bcEaXu0zLUR5NCweUnLcz9KrgtOeoVxx=g@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1409846245-sup-9327@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:08:45',-25200,'2014-09-04 17:08:45',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Flavio Percoco\'s message of 2014-09-04 06:01:45 -0700:\n> On 09/04/2014 02:14 PM, Sean Dague wrote:\n> > On 09/04/2014 03:08 AM, Flavio Percoco wrote:\n> >> Greetings,\n> >>\n> >> Last Tuesday the TC held the first graduation review for Zaqar. During\n> >> the meeting some concerns arose. I\'ve listed those concerns below with\n> >> some comments hoping that it will help starting a discussion before the\n> >> next meeting. In addition, I\'ve added some comments about the project\n> >> stability at the bottom and an etherpad link pointing to a list of use\n> >> cases for Zaqar.\n> >>\n> >> # Concerns\n> >>\n> >> - Concern on operational burden of requiring NoSQL deploy expertise to\n> >> the mix of openstack operational skills\n> >>\n> >> For those of you not familiar with Zaqar, it currently supports 2 nosql\n> >> drivers - MongoDB and Redis - and those are the only 2 drivers it\n> >> supports for now. This will require operators willing to use Zaqar to\n> >> maintain a new (?) NoSQL technology in their system. Before expressing\n> >> our thoughts on this matter, let me say that:\n> >>\n> >>     1. By removing the SQLAlchemy driver, we basically removed the chance\n> >> for operators to use an already deployed \"OpenStack-technology\"\n> >>     2. Zaqar won\'t be backed by any AMQP based messaging technology for\n> >> now. Here\'s[0] a summary of the research the team (mostly done by\n> >> Victoria) did during Juno\n> >>     3. We (OpenStack) used to require Redis for the zmq matchmaker\n> >>     4. We (OpenStack) also use memcached for caching and as the oslo\n> >> caching lib becomes available - or a wrapper on top of dogpile.cache -\n> >> Redis may be used in place of memcached in more and more deployments.\n> >>     5. Ceilometer\'s recommended storage driver is still MongoDB, although\n> >> Ceilometer has now support for sqlalchemy. (Please correct me if I\'m wrong).\n> >>\n> >> That being said, it\'s obvious we already, to some extent, promote some\n> >> NoSQL technologies. However, for the sake of the discussion, lets assume\n> >> we don\'t.\n> >>\n> >> I truly believe, with my OpenStack (not Zaqar\'s) hat on, that we can\'t\n> >> keep avoiding these technologies. NoSQL technologies have been around\n> >> for years and we should be prepared - including OpenStack operators - to\n> >> support these technologies. Not every tool is good for all tasks - one\n> >> of the reasons we removed the sqlalchemy driver in the first place -\n> >> therefore it\'s impossible to keep an homogeneous environment for all\n> >> services.\n> >>\n> >> With this, I\'m not suggesting to ignore the risks and the extra burden\n> >> this adds but, instead of attempting to avoid it completely by not\n> >> evolving the stack of services we provide, we should probably work on\n> >> defining a reasonable subset of NoSQL services we are OK with\n> >> supporting. This will help making the burden smaller and it\'ll give\n> >> operators the option to choose.\n> >>\n> >> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> > \n> > I\'ve been one of the consistent voices concerned about a hard\n> > requirement on adding NoSQL into the mix. So I\'ll explain that thinking\n> > a bit more.\n> > \n> > I feel like when the TC makes an integration decision previously this\n> > has been about evaluating the project applying for integration, and if\n> > they met some specific criteria they were told about some time in the\n> > past. I think that\'s the wrong approach. It\'s a locally optimized\n> > approach that fails to ask the more interesting question.\n> > \n> > Is OpenStack better as a whole if this is a mandatory component of\n> > OpenStack? Better being defined as technically better (more features,\n> > less janky code work arounds, less unexpected behavior from the stack).\n> > Better from the sense of easier or harder to run an actual cloud by our\n> > Operators (taking into account what kinds of moving parts they are now\n> > expected to manage). Better from the sense of a better user experience\n> > in interacting with OpenStack as whole. Better from a sense that the\n> > OpenStack release will experience less bugs, less unexpected cross\n> > project interactions, an a greater overall feel of consistency so that\n> > the OpenStack API feels like one thing.\n> > \n> > https://dague.net/2014/08/26/openstack-as-layers/\n> > \n> > One of the interesting qualities of Layers 1 & 2 is they all follow an\n> > AMQP + RDBMS pattern (excepting swift). You can have a very effective\n> > IaaS out of that stack. They are the things that you can provide pretty\n> > solid integration testing on (and if you look at where everything stood\n> > before the new TC mandates on testing / upgrade that was basically what\n> > was getting integration tested). (Also note, I\'ll accept Barbican is\n> > probably in the wrong layer, and should be a Layer 2 service.)\n> > \n> > While large shops can afford to have a dedicated team to figure out how\n> > to make mongo or redis HA, provide monitoring, have a DR plan for when a\n> > huricane requires them to flip datacenters, that basically means\n> > OpenStack heads further down the path of \"only for the big folks\". I\n> > don\'t want OpenStack to be only for the big folks, I want OpenStack to\n> > be for all sized folks. I really do want to have all the local small\n> > colleges around here have OpenStack clouds, because it\'s something that\n> > people believe they can do and manage. I know the people that work in\n> > this places, they all come out to the LUG I run. We\'ve talked about\n> > this. OpenStack is basically seen as too complex for them to use as it\n> > stands, and that pains me a ton.\n> > \n> > So I think Zaqar is good software, and really useful part of our\n> > ecosystem, but this added step function burden of a 3rd class of support\n> > software that has to be maintained... seems like it takes us further\n> > away from OpenStack at a small scale. If we were thinking about Zaqar as\n> > a thing that we could replace olso.messaging with, that becomes\n> > interesting in a different way, because we could instead of having 3\n> > classes of support software, remain at 2, just take a sideways shift on\n> > one of them. But that\'s not actually the path we are on.\n> > \n> > So, honestly, I\'ll probably remain -1 on the final integration vote, not\n> > because Zaqar is bad, but because I\'m feeling more firmly that for\n> > OpenStack to not leave the small deployers behind we need to redefine\n> > the tightly integrated piece of OpenStack to basically the Layer 1 & 2\n> > parts of my diagram, and consider the rest of the layers exciting parts\n> > of our ecosystem that more advanced users may choose to deploy to meet\n> > their needs. Smaller tent, big ecosystem, easier on ramp.\n> > \n> > I realize that largely means Zaqar would be caught up in a definition\n> > discussion outside of it\'s control, and that\'s kind of unfortunate, as\n> > Flavio and team have been doing a bang up job of late. But we need to\n> > stop considering \"integration\" as the end game of all interesting\n> > software in the OpenStack ecosystem, and I think it\'s better to have\n> > that conversation sooner rather than later.\n> > \n> > Anyway, my $0.02.\n> \n> I really like your perspective and vision for OpenStack. I think aiming\n> to make OpenStack more accessible for small teams and deployments is\n> something we all should keep in mind and strive for.\n> \n> IIUC, your -1 stays because you think Zaqar is not an essential part of\n> OpenStack and not necessarily because Zaqar requires a NoSQL technology\n> - the later is just an addition to your main concern. But even if your\n> concern was just about the NoSQL technology, I still wonder:\n> \n> Why does it have to be all or nothing?\n> \n> Technically speaking, deployers can install *just* the services they\n> need. These services may or may not depend on other services but there\'s\n> to be a balance between simplifying deployments and making them richer.\n> For example, I could argue saying that deploying Zaqar is very cheap,\n> you just need to install Zaqar, pick a storage and you\'re done. You\n> don\'t need any of the other services because even keystone is optional\n> if you don\'t care about authentication. This probably wouldn\'t be\n> considered an \"OpenStack Cloud\" but it still is a cloud service that is\n> part of - or at least was born as part of - OpenStack.\n> \n\n\"Just install it\" is a pretty tall order. Monitoring, backups, DR,\norchestration, availability, etc. Every new thing we ask everyone to\ninstall adds complexity and thus cost.\n\nOpenStack contributors and operators are quite interested in\nportability. Some operators will want to operate a small cloud and then\ninject some of their work into a much larger cloud. If, however, their\nsmall cloud is lacking Zaqar, and the big one is not, then they cannot\nuse Zaqar on the bigger cloud. This is bad for the bigger cloud. The\nbig cloud operator has it in their best interest to make the small cloud\nmore consumable to seed their section of the market.\n\nWhat is under debate right now, is how much of that extra stuff does\nOpenStack want to champion versus enable. If OpenStack says \"Zaqar is\nour messaging thing, deploy it!\" Cloud operators who don\'t will have to\ndeal with the lack of portability of apps that rely on it to their cloud.\n\nSo, by not championing something optional, we lessen the burden on\nOpenStack operators to support new technologies, and we open up the space\nfor fragmentation. There\'s no one right answer IMO. In spaces like that,\nI don\'t think we should succumb to the subjective arguments and just pull\nsomething in. Instead, I\'d like to see us weigh the options and come up\nwith a third option for when we can\'t choose between \"in\" and \"out\".\n\n\n','<540862B9.1030205@redhat.com>',NULL),('<1409846845471.84278@accenture.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-04 16:07:16',0,'2014-09-04 16:07:16',NULL,'[Openstack] FW:   nova resize error','\n\nHi All,\n\nI am trying to resize the tiny flavor to small using Cirros image in Openstack Icehouse.\n\nI can go ahead and resize, it says 100% complete when I try the resize-confirm\ncommand it gives the below error:\n\n\nnova resize-confirm xxxxxxxxxxxx\nERROR: Cannot \'confirmResize\' while instance is in vm_state active (HTTP 409)\n\nPlease let me know if we have an option to resize flavor in Icehouse?\n\n\nRegards,\nRaghavendra Lad\n\n\n\n?________________\n\nwww.accenture.com\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140904/50681e95/attachment.html>\n-------------- next part --------------\nAn embedded and charset-unspecified text was scrubbed...\nName: nova resize.txt\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140904/50681e95/attachment.txt>\n\n','<1409840945282.29816@accenture.com>',NULL),('<1409850546-sup-754@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 10:16:17',-25200,'2014-09-04 17:16:17',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Flavio Percoco\'s message of 2014-09-04 02:11:15 -0700:\n> Hey Clint,\n> \n> Thanks for reading, some comments in-line:\n> \n> On 09/04/2014 10:30 AM, Clint Byrum wrote:\n> > Excerpts from Flavio Percoco\'s message of 2014-09-04 00:08:47 -0700:\n> \n> [snip]\n> \n> >> - Concern on should we really reinvent a queue system rather than\n> >> piggyback on one\n> >>\n> >> As mentioned in the meeting on Tuesday, Zaqar is not reinventing message\n> >> brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack\n> >> flavor on top. [0]\n> >>\n> > \n> > I think Zaqar is more like SMTP and IMAP than AMQP. You\'re not really\n> > trying to connect two processes in real time. You\'re trying to do fully\n> > asynchronous messaging with fully randomized access to any message.\n> > \n> > Perhaps somebody should explore whether the approaches taken by large\n> > scale IMAP providers could be applied to Zaqar.\n> > \n> > Anyway, I can\'t imagine writing a system to intentionally use the\n> > semantics of IMAP and SMTP. I\'d be very interested in seeing actual use\n> > cases for it, apologies if those have been posted before.\n> > \n> >> Some things that differentiate Zaqar from SQS is it\'s capability for\n> >> supporting different protocols without sacrificing multi-tenantcy and\n> >> other intrinsic features it provides. Some protocols you may consider\n> >> for Zaqar are: STOMP, MQTT.\n> >>\n> >> As far as the backend goes, Zaqar is not re-inventing it either. It sits\n> >> on top of existing storage technologies that have proven to be fast and\n> >> reliable for this task. The choice of using NoSQL technologies has a lot\n> >> to do with this particular thing and the fact that Zaqar needs a storage\n> >> capable of scaling, replicating and good support for failover.\n> >>\n> > \n> > What\'s odd to me is that other systems like Cassandra and Riak are not\n> > being discussed. There are well documented large scale message storage\n> > systems on both, and neither is encumbered by the same licensing FUD\n> > as MongoDB.\n> \n> FWIW, they both have been discussed. As far as Cassandra goes, we raised\n> the red flag after reading reading this post[0]. The post itself may be\n> obsolete already but I don\'t think I have enough knowledge about\n> Cassandra to actually figure this out. Some folks have come to us asking\n> for a Cassandra driver and they were interested in contributing/working\n> on one. I really hope that will happen someday, although it\'ll certainly\n> happen as an external driver. Riak, on the other hand, was certainly a\n> good candidate. What made us go with MongoDB and Redis is they\'re both\n> good for the job, they are both likely already deployed in OpenStack\n> clouds and we have enough knowledge to provide support and maintenance\n> for both drivers.\n\nIt seems like Cassandra is good for when you\'re going to be writing all\nthe time but only reading once. I would agree that this makes it less\nattractive for a generalized messaging platform, since you won\'t know\nhow users will consume the messages, and if they are constantly\nreading then you\'ll have terrible performance.\n\n> >> # Use Cases\n> >>\n> >> In addition to the aforementioned concerns and comments, I also would\n> >> like to share an etherpad that contains some use cases that other\n> >> integrated projects have for Zaqar[0]. The list is not exhaustive and\n> >> it\'ll contain more information before the next meeting.\n> >>\n> >> [0] https://etherpad.openstack.org/p/zaqar-integrated-projects-use-cases\n> >>\n> > \n> > Just taking a look, there are two basic applications needed:\n> > \n> > 1) An inbox. Horizon wants to know when snapshots are done. Heat wants\n> > to know what happened during a stack action. Etc.\n> > \n> > 2) A user-focused message queue. Heat wants to push data to agents.\n> > Swift wants to synchronize processes when things happen.\n> > \n> > To me, #1 is Zaqar as it is today. #2 is the one that I worry may not\n> > be served best by bending #1 onto it.\n> \n> Push semantics are being developed. We\'ve had enough discussions that\n> have helped preparing the ground for it. However, I believe both use\n> cases could be covered by Zaqar as-is.\n> \n> Could you elaborate a bit more on #2? Especially on why you think Zaqar\n> as is can\'t serve this specific case?\n\nThe difference between 1 and 2 is that 2 is a true queueing problem. The\nmessage should go away when it has been consumed, and the volume may be\nrather high. With 1, you have a storage problem, and a database makes a\nlot more sense. If users can stick to type 2 problems, they\'ll be able\nto stay much more lightweight because they won\'t need a large data store\nthat supports random access.\n\n\n','<54082CB3.3080909@redhat.com>',NULL),('<1409879858.3012.5.camel@dhcp-40-102.bne.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 11:17:38',36000,'2014-09-05 01:17:38',NULL,'[openstack-dev] [Horizon][Keystone] Steps toward Kerberos and\n Federation','On Thu, 2014-09-04 at 17:37 -0400, Adam Young wrote:\n> While the Keystone team has made pretty good strides toward Federation \n> for getting a Keystone token, we do not yet have a complete story for \n> Horizon.  The same is true about Kerberos.  I\'ve been working on this, \n> and I want to inform the people that are interested in the approach, as \n> well as get some feedback.\n> \n> My first priority has been Kerberos.  I have a proof of concept of this \n> working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) \n> made me shudder:  its fairly ugly.  A few discussions today have moved \n> things such that I think I can clean up the approach.\n> \n> Phase 1.  DOA should be able to tell whether to use password or Kerberos \n> in order to get a token from Keystone based on an variable set by the \n> Apache web server;  mod_auth_kerb will set\n> \n>          request.META[\'KRB5CCNAME\']\n> \n> only in the kerberos case.  If it gets this variable, DOA will only do \n> Kerberos.  If it does not, it will only do password.  There will be no \n> fallback from Kerberos to password;  this is enforced by mod_auth_kerb, \n> not something we can easily hack around in Django.\n> \n> That gets us Kerberos, but not Federation. Most of the code changes are \n> common with what follows after:\n> \n> Phase 1.5.  Add an optional field  to the password auth page that allows \n> a user to log in with a token instead of userid/password. This can be a \n> hidden field by default if we really want.  DOA now needs to be able to \n> validate a token.  Since Horizon only cares about the hashed version of \n> the tokens anyway, we only to Online lookup, not PKI token validation.  \n> In the successful response, Keystone will to return the properly hashed \n> (SHA256 for example) of the PKI tokens for Horizon to cache.\n> \n> Phase 2.  Use AJAX to get a token from Keystone instead of sending the \n> credentials to the client.  Then pass that token to Horizon in order to \n> login. This implies that Keystone has set up CORS support. This will \n> open the door for Federation.  While it will provide a different path to \n> Kerberos than the stage 1, I think both are valuable approaches and will \n> serve different use cases.  This\n> \n> Phase 3.  Never send your token to Horizon.  In this world, the browser, \n> with full CORS support, makes AJAX calls direct to Nova, Glance, and all \n> other services.\n> \n> Yep, this should be a cross project session for the summit.\n\nSo it was brought up briefly in Atlanta that keystone should provide a\nway to discover the available auth mechanisms. This would mean to me for\nexample: \n\n1. a GET /auth/methods or just GET /auth which would include a list of\nthe methods for retrieving a token. (or just jsonhome entries)\n2. a GET /OS-FEDERATION/idp that would list the available federated\nIDPs. (or just jsonhome entries)\n\nHorizon would then be able to do a similar thing to web services with\n\'login using your google id\' or with user/pass and do some sensible\nthings based on what is allowed, or if it is receiving a kerberos ticket\nand kerberos is one of the allowed methods then bypass all this stuff.\n\nIf we did this wouldn\'t most of \'use CORS/AJAX/kerberos/whatever\' be on\na case by case basis? \n\nI don\'t know Horizon or the DOA very well at all so just let me know if\ni\'ve picked up on completely the wrong things here. \n\n\nJamie\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n','<5408DBA2.6060606@redhat.com>',NULL),('<14098E9E-1F74-4003-A63E-C07C1C511D5C@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 11:00:59',-14400,'2014-10-14 15:00:59',NULL,'[Openstack] Messaging reliability/durability expectations','Thanks Raghu. I think I might not be asking the right questions. Part of my ignorance here comes from not understanding AMQP. I think really what I\'m trying to figure out is whether openstack expects durable queues. It sounds like the answer is no but confirmation of this would be great. Even if it doesn\'t expect durable queues is there a noticeable advantage to openstack to have them?\n\nThanks again!\n\nSent from my iPhone\n\n> On Oct 14, 2014, at 10:12 AM, Raghu Vadapalli <rvatspacket at gmail.com> wrote:\n> \n> \n> \n> \n> \n> ?\n> Raghu\n> \n>> On Tuesday, Oct 14, 2014 at 7:49 AM, Aaron Knister <aaron.knister at gmail.com>, wrote:\n>> Thanks Remo, could you elaborate a little? Which is part of RabbitMQ? The HA layer or the message retransmission? I\'m currently using qpid. Also, just so I\'m clear, is it the openstack code or the low-level messaging drivers (rabbit, zmq, qpid) that retransmit on message delivery failure?\n>> \n>> Thanks!\n> ?\n> That should be the job messaging infrastructure provided by rabbit or qpid \n> Raghu\n>> \n>> Sent from my iPhone\n>> \n>> On Oct 13, 2014, at 11:59 PM, Remo Mattei <remo at italy1.com> wrote:\n>> \n>>> That is part of RabbitMQ and yes it will resend the msg. \n>>> \n>>> Remo \n>>>> On Oct 13, 2014, at 22:31, Aaron Knister <aaron.knister at gmail.com> wrote:\n>>>> \n>>>> Hi Everyone,\n>>>> \n>>>> I\'m building a production-grade cloud where HA is a requirement. I\'m currently working on implementing HA of the messaging layer and am not clear on what the expectations/assumptions are of the messaging layer regarding message durability and reliability. I\'ve seen documentation scattered about that suggests OpenStack makes no assumptions that messages will be delivered or will need to persist for any period of time (https://openstack.redhat.com/Highly_Available_Qpid_for_OpenStack).\n>>>> \n>>>> What\'s the consequence of RPC message loss within openstack? Is it true that it will resend messages?\n>>>> \n>>>> Thanks!\n>>>> \n>>>> -Aaron\n>>>> !DSPAM:1,543c9c2325772110695322!\n>>>> _______________________________________________\n>>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> \n>>>> \n>>>> !DSPAM:1,543c9c2325772110695322!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141014/0631f249/attachment.html>\n\n','<1413295928305.9dc55ad1@Nodemailer>',NULL),('<1409905994074.13473@accenture.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-05 08:30:15',0,'2014-09-05 08:30:15',NULL,'[Openstack] Template for wordpress','Hi,\n\n\nWhats the procedure to implement autoscaling for multiple neutron networks ?\n\n\n\nThanks\n\nKumar\n\n________________________________\nFrom: ?? <yanchao727 at gmail.com>\nSent: Thursday, September 4, 2014 1:15 PM\nTo: Gnan Kumar, Yalla\nCc: <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Template for wordpress\n\nIt\'s possible that your \"My::lb::Server\" didn\'t boot successfully. And it seems there is no option for specifing  a network ID in the webservergroup. Take a look at this link of webservergroup option:\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::AutoScalingGroup\n\nBest Regards?\nChao Yan\n--------------\nMy twitter?Andy Yan @yanchao727<https://twitter.com/yanchao727>\nMy Weibo?http://weibo.com/herewearenow\n--------------\n\n\n2014-09-04 20:19 GMT+08:00 <yalla.gnan.kumar at accenture.com<mailto:yalla.gnan.kumar at accenture.com>>:\nHi All,\n\nI am trying to implement autoscaling using the template attached for multiple neutron networks.\nWhile creating the server in the webservergroup,   it is failing by showing the below error :\n\n------\nweb_server_group       | c6189de2-d748-44f2-9b60-0d2e708e1d1f | Error: Resource CREATE failed: Error: Resource CREATE failed: BadRequest: Multiple possible networks found\n--------\n\n\nI have attached the template to this mail.   Please check it and  let me know how to specify  a network ID in the websergroup   .\n\n\nThanks\nKumar\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com<http://www.accenture.com>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140905/226d6283/attachment.html>\n\n','<CALAMvO80FtgF0RWM3hUSW+iu+KfYFrn1g2e_HMOjZcZ30Qps1Q@mail.gmail.com>',NULL),('<1409912726.27411.39.camel@ws-xeye>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 14:25:26',14400,'2014-09-05 10:25:26',NULL,'[openstack-dev]   [Keystone]  NNN_additional_attribute_mapping','Greetings!\n\nI think I found a problem in extra attributes handling in LDAP backend.\nAlso I\'d like to propose a solution :)\n\nThere is a bug https://bugs.launchpad.net/keystone/+bug/1336769\n\"LDAP additional attribute mappings do not care about model attribute\"\nreported by Marcos Lobo (https://launchpad.net/~marcos-fermin-lobo)\n\nIt describes a problem when server handles requests without any warning\nabout model data mismatches.\nFirst of all I\'ve noticed that all is about optional attributes and it\nseems to be okay to handle them as I see fit. But in the end Marcos\nstates:\n\"I have a mistake in the keystone.conf file and everything is working\nproperly.\"\n\nThis got my attention and I\'ve decided to check field mappings, model\nvalidations CRUD and anything available in that direction.\nI found nothing about model validation. Really, there is no means to be\nsure you received valid data from LDAP backend.\n\nFurthermore keystone.common.ldap.core.BaseLdap._ldap_res_to_model()\ncompletely ignores extra fields mapping while translating received from\nLDAP server data to model structure.\nTests correctly cover only create operation, checking model to ldap\nfield mapping:\nkeystone.tests.test_backend_ldap.LDAPIdentity.test_user_extra_attribute_mapping().\nBut test for retrieval only covers case when \"description\" mapped to\n\"description\":\nkeystone.tests.test_backend_ldap.LDAPIdentity.test_user_extra_attribute_mapping_description_is_returned()\n\nTest passes not because extra mapping works but due to the default\nbehaviour of generic mapping: if mapping not found pass the field as is.\n\nI added required attribute validation to keystone.common.models.Model,\nbut applying it resulted in many test failures.\nFurther analysis revealed that there are some algorythms depending on\nbehaviour such as saving/retrieving model instanses without some fields\ndeclared in a model as required.\nSo I had to fall back to warning instead of raising validation error.\n\nPatch awaits review and I\'m in doubt: is there a single bug, or it has\nto be split.\nhttps://review.openstack.org/#/c/118590/\n\nKind Regards,\nAlexander Makarov,\nSenior Developer,\n\nMirantis, Inc.\n35b/3, Vorontsovskaya St., 109147, Moscow, Russia\n\nTel.: +7 (495) 640-49-04\nTel.: +7 (926) 204-50-60\nSkype: MAKAPOB.AJIEKCAHDP\n\n\n\n',NULL,NULL),('<1409928611771.d91ae029@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 07:50:12',-25200,'2014-09-05 14:50:12',NULL,'[openstack-dev] [nova] FFE server-group-quotas','I\'m willing to sponsor this\n\n\nChris\n?\nSent from Mailbox\n\nOn Fri, Sep 5, 2014 at 10:29 PM, Day, Phil <philip.day at hp.com> wrote:\n\n> Hi,\n> I\'d like to ask for a FFE for the 3 patchsets that implement quotas for server groups.\n> Server groups (which landed in Icehouse) provides a really useful anti-affinity filter for scheduling that a lot of customers woudl like to use, but without some form of quota control to limit the amount of anti-affinity its impossible to enable it as a feature in a public cloud.\n> The code itself is pretty simple - the number of files touched is a side-effect of having three V2 APIs that report quota information and the need to protect the change in V2 via yet another extension.\n> https://review.openstack.org/#/c/104957/\n> https://review.openstack.org/#/c/116073/\n> https://review.openstack.org/#/c/116079/\n> Phil\n>> -----Original Message-----\n>> From: Sahid Orentino Ferdjaoui [mailto:sahid.ferdjaoui at redhat.com]\n>> Sent: 04 September 2014 13:42\n>> To: openstack-dev at lists.openstack.org\n>> Subject: [openstack-dev] [nova] FFE request serial-ports\n>> \n>> Hello,\n>> \n>> I would like to request a FFE for 4 changesets to complete the blueprint\n>> serial-ports.\n>> \n>> Topic on gerrit:\n>> \n>> https://review.openstack.org/#/q/status:open+project:openstack/nova+br\n>> anch:master+topic:bp/serial-ports,n,z\n>> \n>> Blueprint on launchpad.net:\n>>   https://blueprints.launchpad.net/nova/+spec/serial-ports\n>> \n>> They have already been approved but didn\'t get enough time to be merged\n>> by the gate.\n>> \n>> Sponsored by:\n>> Daniel Berrange\n>> Nikola Dipanov\n>> \n>> s.\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140905/e1d90f92/attachment.html>\n\n','<BD26CCD58723F74AA8E6BCB31052A1F0071EC1DB@G5W2737.americas.hpqcorp.net>',NULL),('<1409930709.24731.3.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 10:25:09',-18000,'2014-09-05 15:25:09',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out virt drivers','On Fri, 2014-09-05 at 10:26 +0100, Daniel P. Berrange wrote:\n> > 2. Removal of drivers other than the reference implementation for each\n> > project could be the healthiest option\n> >     a. Requires transparent, public, automated 3\'rd party CI\n> >     b. Requires a TRUE plugin architecture and mentality\n> >     c. Requires a stable and well defined API\n> \n> As mentioned in the original mail I don\'t want to see a situation where\n> we end up with some drivers in tree and others out of tree as it sets up\n> bad dynamics within the project. Those out of tree will always have the\n> impression of being second class citizens and thus there will be constant\n> pressure to accept drivers back into tree. The so called \'reference\'\n> driver that stayed in tree would also continue to be penalized in the\n> way it is today, and so its development would be disadvantaged compared\n> to the out of tree drivers.\n\nI have one quibble with the notion of \"not even one\" driver in core: I\nthink it is probably useful to include a dummy, do-nothing driver that\ncan be used for in-tree functional tests and as an example to point\nthose interested in writing a driver.  Then, the \"second-class citizen\"\nis the one actually in the tree :)  Beyond that, I agree with this\nproposal: it has never made sense to me that *all* drivers live in the\ntree, and it actually offends my sense of organization to have the tree\nso cluttered; we split functions when they get too big, we split modules\nwhen they get too big, and we create subdirectories when packages get\ntoo big, so why not split repos when they get too big?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<20140905092603.GE10103@redhat.com>',NULL),('<1409930983.12623.0.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 11:29:43',-14400,'2014-09-05 15:29:43',NULL,'[openstack-dev] [Sahara][FFE] Requesting exception for Swift\n trust authentication blueprint','Not sure how this is done, but I\'m a core member for Sahara, and I\nhereby sponsor it.\n\nOn Fri, 2014-09-05 at 09:57 -0400, Michael McCune wrote:\n> hey folks,\n> \n> I am requesting an exception for the Swift trust authentication blueprint[1]. This blueprint addresses a security bug in Sahara and represents a significant move towards increased security for Sahara clusters. There are several reviews underway[2] with 1 or 2 more starting today or monday.\n> \n> This feature is initially implemented as optional and as such will have minimal impact on current user deployments. By default it is disabled and requires no additional configuration or management from the end user.\n> \n> My feeling is that there has been vigorous debate and discussion surrounding the implementation of this blueprint and there is consensus among the team that these changes are needed. The code reviews for the bulk of the work have been positive thus far and I have confidence these patches will be accepted within the next week.\n> \n> thanks for considering this exception,\n> mike\n> \n> \n> [1]: https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust-authentication\n> [2]: https://review.openstack.org/#/q/status:open+topic:bp/edp-swift-trust-authentication,n,z\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1110176901.949231.1409925445850.JavaMail.zimbra@redhat.com>',NULL),('<1409969278.20684.2.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 19:07:58',-25200,'2014-09-06 02:07:58',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out virt drivers','\nOn Fri, 2014-09-05 at 08:02 -0400, Sean Dague wrote:\n> On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:\n> > On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:\n> >> On 09/05/2014 06:40 AM, Nikola ?ipanov wrote:\n> >>> A handy example of this I can think of is the currently granted FFE for\n> >>> serial consoles - consider how much of the code went into the common\n> >>> part vs. the libvirt specific part, I would say the ratio is very close\n> >>> to 1 if not even in favour of the common part (current 4 outstanding\n> >>> patches are all for core, and out of the 5 merged - only one of them was\n> >>> purely libvirt specific, assuming virt/ will live in nova-common).\n> >>>\n> >>> Joe asked a similar question elsewhere on the thread.\n> >>>\n> >>> Once again - I am not against doing it - what I am saying is that we\n> >>> need to look into this closer as it may not be as big of a win from the\n> >>> number of changes needed per feature as we may think.\n> >>>\n> >>> Just some things to think about with regards to the whole idea, by no\n> >>> means exhaustive.\n> >>\n> >> So maybe the better question is: what are the top sources of technical\n> >> debt in Nova that we need to address? And if we did, everyone would be\n> >> more sane, and feel less burnt.\n> >>\n> >> Maybe the drivers are the worst debt, and jettisoning them makes them\n> >> someone else\'s problem, so that helps some. I\'m not entirely convinced\n> >> right now.\n> >>\n> >> I think Cells represents a lot of debt right now. It doesn\'t fully work\n> >> with the rest of Nova, and produces a ton of extra code paths special\n> >> cased for the cells path.\n> >>\n> >> The Scheduler has a ton of debt as has been pointed out by the efforts\n> >> in and around Gannt. The focus has been on the split, but realistically\n> >> I\'m with Jay is that we should focus on the debt, and exposing a REST\n> >> interface in Nova.\n> >>\n> >> What about the Nova objects transition? That continues to be slow\n> >> because it\'s basically Dan (with a few other helpers from time to time).\n> >> Would it be helpful if we did an all hands on deck transition of the\n> >> rest of Nova for K1 and just get it done? Would be nice to have the bulk\n> >> of Nova core working on one thing like this and actually be in shared\n> >> context with everyone else for a while.\n> > \n> > I think the idea that we can tell everyone in Nova what they should\n> > focus on for a cycle, or more generally, is doomed to failure. This\n> > isn\'t a closed source company controlled project where you can dictate\n> > what everyones priority must be. We must accept that rely on all our\n> > contributors good will in voluntarily giving their time & resource to\n> > the projct, to scratch whatever itch they have in the project. We have\n> > to encourage them to want to work nova and demonstrate that we value\n> > whatever form of contributor they choose to make. If we have technical\n> > debt that we think is important to address we need to illustrate /\n> > show people why they should care about helping. If they none the less\n> > decide that work isn\'t for them, we can\'t just cast them aside and/or\n> > ignore their contributions, while we get on with other things. This\n> > is why I think it is important that we split up nova to allow each\n> > are to self-organize around what they consider to be priorities in\n> > their area of interest / motivation. Not enabling that is going to\n> > to continue to kill our community\n> \n> I\'m getting tired of the reprieve that because we are an Open Source\n> project declaring priorities is pointless, because it\'s not. I would say\n> it\'s actually the exception that a developer wakes up in the morning and\n> says \"I completely disregard what anyone else thinks is important in\n> this project, this is what I\'m going to do today\". Because if that\'s how\n> they felt they wouldn\'t choose to be part of a community, they would\n> just go do their own thing. Lone wolfs by definition don\'t form\n> communities.\n\nActually, I don\'t think this analysis is accurate.  Some people are\nsimply interested in small aspects of a project.  It\'s the \"scratch your\nown itch\" part of open source.  The thing which makes itch scratchers\nnot lone wolfs is the desire to go the extra mile to make what they\'ve\ndone useful to the community.  If they never do this, they likely have a\nforked repo with only their changes (and are the epitome of a lone\nwolf).  If you scratch your own itch and make the effort to get it\nupstream, you\'re assisting the community (even if that\'s the only piece\nof code you do) and that assistance makes you (at least for a time) part\nof the community.\n\nA community doesn\'t necessarily require continuity from all its\nelements.  It requires continuity from some (the core, if you will), but\nit also allows for contributions from people who only have one or two\nthings they need doing.  For OpenStack to convert its users into its\ncontributors, it is going to have to embrace this, because they likely\nonly need a couple of things fixing, so they\'ll pop into the community,\nfix what they need fixing and then go back to being users again.\n\nSome projects, the linux kernel in particular, deliberately don\'t\nenforce priorities on the contributors.  Priorities are effectively\ngiven by the eagerness of the contributors to get upstream and their\nwillingness to make the contribution acceptable to upstream.  I\'m not\nsaying this is the only (or even the best) way to run a project, but it\ndoes demonstrate that the self organizing nature of communities can be\nharnessed to produce forward momentum.\n\nJames\n\n\n\n\n\n','<5409A648.9010908@dague.net>',NULL),('<1409969785.20684.11.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 19:16:25',-25200,'2014-09-06 02:16:25',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out virt drivers','On Fri, 2014-09-05 at 14:14 +0200, Thierry Carrez wrote:\n> Daniel P. Berrange wrote:\n> > For a long time I\'ve use the LKML \'subsystem maintainers\' model as the\n> > reference point for ideas. In a more LKML like model, each virt team\n> > (or other subsystem team) would have their own separate GIT repo with\n> > a complete Nova codebase, where they did they day to day code submissions,\n> > reviews and merges. Periodically the primary subsystem maintainer would\n> > submit a large pull / merge requests to the overall Nova maintainer.\n> > The $1,000,000 question in such a model is what kind of code review\n> > happens during the big pull requests to integrate subsystem trees. \n> \n> Please note that the Kernel subsystem model is actually a trust tree\n> based on 20 years of trust building. OpenStack is only 4 years old, so\n> it\'s difficult to apply the same model as-is.\n\nThat\'s true but not entirely accurate.  The kernel maintainership is a\ntrust tree, but not every person in that tree has been in the position\nfor 20 years.  We have one or two who have (Dave Miller, net maintainer,\nfor instance), but we have some newcomers: Sarah Sharp has only been on\nUSB3.0 for a year.  People pass in and out of the maintainer tree all\nthe time.\n\nIn many ways, the Open Stack core model is also a trust tree (you elect\npeople to the core and support their nominations because you trust them\nto do the required job).  It\'s not a 1 for 1 conversion, but it should\nbe possible to derive the trust you need from the model you already\nhave, should you wish to make OpenStack function more like the Linux\nKernel.\n\nEssentially Daniel\'s proposal boils down to making the trust boundaries\nalign with separated community interests to get more scaling in the\nmodel.  This is very similar to the way the kernel operates: most\nmaintainers only have expertise in their own areas.  We have a few\npeople with broad reach, like Andrew and Linus, but by and large most\npeople settle down in a much smaller area.  However, you don\'t have to\nfollow the kernel model to get this to happen, you just have to identify\nthe natural interest boundaries of the contributors and align around\nthem (provided they have enough mass to form their own community).\n\nJames\n\n\n\n\n','<5409A926.9050509@openstack.org>',NULL),('<1409976378232.64559@accenture.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-06 04:03:20',0,'2014-09-06 04:03:20',NULL,'[Openstack] Template for wordpress','Any Ideas on implementing autoscaling for multiple neutron networks?\n\n\n\nThanks\n\nKumar\n\n________________________________\nFrom: yalla.gnan.kumar at accenture.com <yalla.gnan.kumar at accenture.com>\nSent: Friday, September 5, 2014 8:30 AM\nTo: yanchao727 at gmail.com\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Template for wordpress\n\n\nHi,\n\n\nWhats the procedure to implement autoscaling for multiple neutron networks ?\n\n\n\nThanks\n\nKumar\n\n________________________________\nFrom: ?? <yanchao727 at gmail.com>\nSent: Thursday, September 4, 2014 1:15 PM\nTo: Gnan Kumar, Yalla\nCc: <openstack at lists.openstack.org>\nSubject: Re: [Openstack] Template for wordpress\n\nIt\'s possible that your \"My::lb::Server\" didn\'t boot successfully. And it seems there is no option for specifing  a network ID in the webservergroup. Take a look at this link of webservergroup option:\nhttp://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::AutoScalingGroup\n\nBest Regards!\nChao Yan\n--------------\nMy twitter:Andy Yan @yanchao727<https://twitter.com/yanchao727>\nMy Weibo:http://weibo.com/herewearenow\n--------------\n\n\n2014-09-04 20:19 GMT+08:00 <yalla.gnan.kumar at accenture.com<mailto:yalla.gnan.kumar at accenture.com>>:\nHi All,\n\nI am trying to implement autoscaling using the template attached for multiple neutron networks.\nWhile creating the server in the webservergroup,   it is failing by showing the below error :\n\n------\nweb_server_group       | c6189de2-d748-44f2-9b60-0d2e708e1d1f | Error: Resource CREATE failed: Error: Resource CREATE failed: BadRequest: Multiple possible networks found\n--------\n\n\nI have attached the template to this mail.   Please check it and  let me know how to specify  a network ID in the websergroup   .\n\n\nThanks\nKumar\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com<http://www.accenture.com>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140906/450b5343/attachment.html>\n\n','<1409905994074.13473@accenture.com>',NULL),('<140ea89312a.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-04 12:53:15',-25200,'2013-09-04 19:53:15',NULL,'[openstack-dev] [nova] key management and Cinder volume\n	encryption','On September 4, 2013 12:28:19 PM \"Coffman, Joel M.\" \n<Joel.Coffman at jhuapl.edu> wrote:\n> The following change provides a key manager implementation that reads a \n> static key from the project\'s configuration: \n> https://review.openstack.org/#/c/45103/\n>\n> This key manager implementation naturally does not provide the same \n> confidentiality that would be proffered by retrieving keys from a service \n> like Barbican or a KMIP server, but it still provides protection against \n> certain attacks like intercepting iSCSI traffic between the compute and \n> storage host and lost / stolen disks.\n>\n>\n\nI know this is meant as a minimalistic stub, but even so shouldn\'t it be \nable to have at least a prior and current key?\n\nHow do you test a key management interface without changing keys?\n\n\n\n\n','<EE1A64E628992240A94E2B625745F016753C6F9D51@aplesstripe.dom1.jhuapl.edu>',NULL),('<1410074514.4115.36.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-07 07:21:54',0,'2014-09-07 07:21:54',NULL,'[openstack-dev] [Octavia] Question about where to\n	render	haproxy configurations','Hi German,\n\nComments in-line\n\nOn Sun, 2014-09-07 at 04:49 +0000, Eichberger, German wrote:\n> Hi Steven,\n> \n>  \n> \n> Thanks for taking the time to lay out the components clearly. I think\n> we are pretty much on the same pageJ\n> \n>  \n> \n> Driver vs, Driver-less\n> \n> I strongly believe that REST is a cleaner interface/integration point\n> ? but  if even Brandon believes that drivers are the better approach\n> (having suffered through the LBaaS v1 driver world which is not an\n> advertisement for this approach) I will concede on that front. Let?s\n> hope nobody makes an asynchronous driver and/or writes straight to the\n> DBJ That said I still believe that adding the driver interface now\n> will lead to some more complexity and I am not sure we will get the\n> interface right in the first version: so let?s agree to develop with a\n> driver in mind but don?t allow third party drivers before the\n> interface has matured. I think that is something we already sort of\n> agreed to, but I just want to make that explicit. \n\nI think the LBaaS V1/V2 driver approach works well enough.  The problems\nthat arose from it were because most entities were root level objects\nand thus had some independent properties to them.  For example, a pool\ncan exist without a listener, and a listener can exist without a load\nbalancer.  The load balancer was the entity tied to the driver.  For\nOctavia, we\'ve already agreed that everything will be a direct or\nindirect child of a load balancer so this should not be an issue.\n\nI agree with you that we will not get the interface right the first\ntime.  I hope no one was planning on starting another driver other than\nhaproxy anytime before 1.0 because I vaguely remember 2.0 being the time\nthat multiple drivers can be used.  By that time the interface should be\nin a good shape.\n\n>  \n> \n> Multiple drivers/version for the same Controller\n> \n> This is a really contentious point for us at HP: If we allow say\n> drivers or even different versions of the same driver, e.g. A, B, C to\n> run in parallel, testing will involve to test all the possible\n> (version) combination to avoid potential side effects. That can get\n> extensive really quick. So HP is proposing, given that we will have\n> 100s of controllers any way, to limit the number of drivers per\n> controller to 1 to aide testing. We can revisit that at a future time\n> when our testing capabilities have improved but for now I believe we\n> should choose that to speed things up. I personally don?t see the need\n> for multiple drivers per controller ? in an operator grade environment\n> we likely don?t need to ?save? on the number of controllers ;-) The\n> only reason we might need two drivers on the same controller is if an\n> Amphora for whatever reason needs to be talked to by two drivers.\n> (e.g. you install nginx and haproxy  and have a driver for each). This\n> use case scares me so we should not allow it.\n> \n> We also see some operational simplifications from supporting only one\n> driver per controller: If we have an update for driver A we don?t need\n> to touch any controller running Driver B. Furthermore we can keep the\n> old version running but make sure no new Amphora gets scheduled there\n> to let it wind down with attrition and then stop that controller when\n> it doesn?t have any more Amphora to serve.\n\nI also agree that we should, for now, only allow 1 driver at a time and\nrevisit it after we\'ve got a solid grasp on everything.  I honestly\ndon\'t think we will have multiple drivers for a while anyway, so by the\ntime we have a solid grasp on it we will know the complexities it will\nintroduce and thus make it a permanent rule or implement it.\n\nI do recognize your worry about the many permutations that could arise\nfrom having a controller driver version and an amphora version.  I might\nbe short-sighted or just blind to it, but would you be testing an nginx\ncontroller driver against an haproxy amphora?  That shouldn\'t work, and\nthus I don\'t see why you would want to test that.  So the only other\noption is testing (as an example) an haproxy 1.5 controller driver with\namphorae that may have different versions of code, scripts, ancillary\napplications, and/or haproxy.  So its possible there could be N number\nof amphorae running haproxy 1.5, if you are planning on keeping older\nversions around.  You would need to test the haproxy 1.5 controller\ndriver against N amphorae versions.  Obviously if we are allowing\nmultiple versions of haproxy controller drivers, then we\'d have to test\nN controller drivers against N amphorae versions.  Correct me if I am\ninterpreting your versioning issue incorrectly.\n\nI see this being a potential issue.  However, right now at least, I\nthink the benefit of not having to update all amphorae in a deployment\nif we need to make a simple config rendering change outweighs this\npotential issue.  I feel like we will be doing a lot more of those\nchanges rather than adding new haproxy version controller drivers.  Even\nwhen a new haproxy version is released, what are the odds that we would\nwant to use it if what we already have works for what we need?  If what\nwe already have doesn\'t, then we\'d probably not use an old and busted\ncontroller and an old and busted amphora version.\n\nThat\'s my take on it currently.  It is subject to change of course.\n\n>  \n> \n> Lastly, I interpreted the word ?VM driver? in the spec along the lines\n> what we have in libra: A driver interface on the Amphora agent that\n> abstracts starting/stopping the haproxy if we end up on some different\n> and abstracts writing the haproxy file. But that is for the agent on\n> the Amphora. I am sorry I got confused  that way when reading the 0.5\n> spec and I am therefore happy we can have that discussion to make\n> things more clear.\n\nI\'m sure more things will come up that we\'ve all made assumptions on and\nwhile reading the specs we read what we thought was what it said, but\nactually didn\'t.\n\n>  \n> \n> German\n> \n>  \n> \n> From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n> Sent: Friday, September 05, 2014 6:26 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [Octavia] Question about where to render\n> haproxy configurations\n> \n> \n>  \n> \n> Hi German,\n> \n>  \n> \n> \n> Responses in-line:\n> \n> \n>  \n> \n> On Fri, Sep 5, 2014 at 2:31 PM, Eichberger, German\n> <german.eichberger at hp.com> wrote:\n> \n> Hi Stephen,\n> \n>  \n> \n> I think this is a good discussion to have and will make it more clear\n> why we chose a specific design. I also believe by having this\n> discussion we will make the design stronger.  I am still a little bit\n> confused what the driver/controller/amphora agent roles are. In my\n> driver-less design we don?t have to worry about the driver which most\n> likely in haproxy?s case will be split to some degree between\n> controller and amphora device.\n> \n> \n>  \n> \n> \n> Yep, I agree that a good technical debate like this can help both to\n> get many people\'s points of view and can help determine the technical\n> merit of one design over another. I appreciate your vigorous\n> participation in this process. :)\n> \n> \n>  \n> \n> \n> So, the purpose of the controller / driver / amphora and the\n> responsibilities they have are somewhat laid out in the Octavia v0.5\n> component design document, but it\'s also possible that there weren\'t\n> enough specifics in that document to answer the concerns brought up in\n> this thread. So, to that end in my mind, I see things like the\n> following:\n> \n> \n>  \n> \n> \n> The controller:\n> \n> \n> * Is responsible for concerns of the Octavia system as a whole,\n> including the intelligence around interfacing with the networking,\n> virtualization, and other layers necessary to set up the amphorae on\n> the network and getting them configured.\n> \n> \n> * Will rarely, if ever, talk directly to the end-systems or -services\n> (like Neutron, Nova, etc.). Instead it goes through a \"clean\" driver\n> interface for each of these.\n> \n> \n> * The controller has direct access to the database where state is\n> stored.\n> \n> \n> * Must load at least one driver, may load several drivers and choose\n> between them based on configuration logic (ex. flavors, config file,\n> etc.)\n> \n> \n>  \n> \n> \n> The driver:\n> \n> \n> * Handles all communication to or from the amphorae\n> \n> \n> * Is loaded by the controller (ie. its interface with the controller\n> is a base class, associated methods, etc. It\'s objects and code, not a\n> RESTful API.)\n> \n> \n> * Speaks amphora-specific protocols on the back-end. In the case of\n> the reference \"haproxy\" amphora, this will most likely be in the form\n> of a RESTful API with an agent on the amp, as well as (probably)\n> HMAC-signed UDP health, status and stats messages from the amp to the\n> driver.\n> \n> \n>  \n> \n> \n> The amphora:\n> \n> \n> * Does the actual load balancing\n> \n> \n> * Is managed by the controller through the driver.\n> \n> \n> * Should be as \"dumb\" as possible.\n> \n> \n> * Comes in different types, based on the software in the amphora\n> image. (Though all amps of a given type should be managed by the same\n> driver.) Types might include \"haproxy,\" \"nginx,\" \"haproxy + nginx,\"\n> \"3rd party vendor X,\" etc.\n> \n> \n> * Should never have direct access to the Octavia database, and\n> therefore attempt to be as stateless as possible, as far as\n> configuration is concerned.\n> \n> \n>  \n> \n> \n> To be honest, our current product does not have a \"driver\" layer per\n> se, since we only interface with one type of back-end. However, we\n> still render our haproxy configs in the controller. :)\n> \n> \n>  \n> \n> \n>          \n>         \n>         So let?s try to sum up what we want a controller to do:\n>         \n>         -         Provision new amphora devices\n>         \n>         -         Monitor/Manage health\n>         \n>         -         Gather stats\n>         \n>         -         Manage/Perform configuration changes\n>         \n>          \n>         \n>         The driver as described would be:\n>         \n>         -         Render configuration changes in a specific format,\n>         e.g. haproxy\n>         \n>          \n>         \n>         Amphora Device:\n>         \n>         -         Communicate with the driver/controller to make\n>         things happen\n>         \n>          \n>         \n>         So as Doug pointed out I can make a very thin driver which\n>         basically passes everything through to the Amphora Device or\n>         on the other hand of the spectrum I can make a very thick\n>         driver which manages all aspects from the amphora life cycle\n>         to whatever (aka kitchen sink). I know we are going for\n>         uttermost flexibility but I believe:\n>         \n>         \n>  \n> \n> \n> So, I\'m not sure it\'s fair to characterize the driver I\'m suggesting\n> as \"very thick.\" If you get right down to it, I\'m pretty sure the only\n> major thing we disagree on here is where the haproxy configuration is\n> rendered:  Just before it\'s sent over the wire to the amphora, or just\n> after it\'s JSON-equivalent is received over the wire from the\n> controller.\n> \n> \n>  \n> \n> \n>         -         With building an haproxy centric controller we don?t\n>         really know which things should be controller/which thing\n>         should be driver. So my shortcut is not to build a driver at\n>         all J\n>         \n>         \n> So, I\'ve become more convinced that having a driver layer there is\n> going to be important if we want to support 3rd party vendors creating\n> their own amphorae at all (which I think we do). It\'s also going to be\n> important if we want to be able to support other versions of\n> open-source amphorae (or experimental versions prior to pushing out to\n> a wider user-base, etc.)\n> \n> \n>  \n> \n> \n> Also, I think: Making ourselves use a driver here also helps keep\n> interfaces clean. This helps us avoid spaghetti code and makes things\n> more maintainable in the long run.\n> \n> \n>         -         The more flexibility increases complexity and makes\n>         it confusing for people to develop components. Should this\n>         concern go into the controller, the driver, or the amphora VM?\n>         Two of them? Three of them? Limiting choices makes it simpler\n>         to achieve that.\n>         \n>         \n> \"Centralize intelligence / decentralize workload.\"  There will often\n> be multiple ways we can solve certain problems, but if we try to\n> follow this mantra, and use clean interfaces between components, it\n> starts to become more clear which code strategies we should be\n> following. Yes, it\'s sometimes hard to know the right way to do\n> things-- which is why we end up having these wonderful debates. ;) But\n> I don\'t think the answer is \"this is hard, let\'s just lump everything\n> together.\"\n> \n> \n>  \n> \n> \n> Also, rule of thumb (perhaps not stated in our constitution... yet):\n>  Try to architect things so the most frequently deployed elements see\n> the fewest changes. (This is actually related to the \"centralize\n> intelligence / decentralize workload\" mantra in a round-about way:\n> Central intelligence elements will be both fewer in number and more\n> frequently changed than \"dumb\" workload components.) This makes\n> managing change for large deployments easier. (Again, it\'s both easier\n> and less risky to update 100 controllers versus 10,000+ amphorae.)\n> \n> \n>  \n> \n> \n>          \n>         \n>         HPs worry is that by creating the potential to run multiple\n>         (version of drivers) drivers, on multiple versions of\n>         controllers, on multiple versions of amphora devices creates a\n>         headache for testing. For example does the version 4.1 haproxy\n>         driver work with the cersion 4.2 controller on an 4.0 amphora\n>         device? Which compatibility matrix do we need to build/test?\n>         Limiting one driver to one controller can help with making\n>         that manageable.\n>         \n>         \n>  \n> \n> \n> Ok, so, I think this is possibly where part of our misunderstanding\n> comes from. I realize above that I said a single driver could talk to\n> multiple versions of back-end amphorae via a couple methods, but let\'s\n> ignore that for a minute and assume that we only test / assume drivers\n> will be speaking with the latest version of the amphorae to which they\n> correspond.\n> \n> \n>  \n> \n> \n> I should probably clarify something that I\'ve been assuming but may\n> not be obvious:  I\'m assuming that the \"version\" of the amphorae\n> (drawn mostly from the version of the glue scripts, agent, and other\n> code we write which lives on the amphora) is numbered separately and\n> moves at a different rate than the version of the driver.  Think of\n> this like the version of the firmware and version of the driver used\n> with your printer. Sometimes a major bugfix entails updating both the\n> firmware and driver. However, it\'s also common for a bugfix / feature\n> enhancement to involve only updating the printer driver version and\n> not the printer firmware.\n> \n> \n>  \n> \n> \n> What I\'m getting at here is that if we\'re doing the configuration\n> rendering in the driver and not on the amphora, there will be some\n> bugfixes / feature enhancements which only entail updating the driver\n> because there are literally no changes that need to be made to the\n> amphora for the bugfix / feature.\n> \n> \n>  \n> \n> \n> Does this actually happen? Yes! To give a concrete example drawn from\n> our product history:  On our existing load balancer product, which is\n> powered by stunnel + haproxy a new OpenSSL vulnerability was\n> discovered, the fix for which was to add a line to the stunnel\n> configuration disabling a certain kind of SSL negotiation. Since we\n> were rendering configurations centrally on our controllers, all we\n> needed to do was update the configuration template on our controller\n> and push out new configs for anyone using SSL termination. Took\n> literally 10 minutes to implement once we understood the problem, and\n> we didn\'t have to touch or otherwise update the software or scripts\n> running on our appliances at all.\n> \n> \n>  \n> \n> \n> It\'s even easier for L7 feature enhancements: You don\'t even have to\n> push anything out to the amphora, just update the controller / driver\n> to expose the new feature and users can then start using it at will.\n> \n> \n>  \n> \n> \n> Are all feature enhancements / bugfixes this easy? No! How do you tell\n> the difference between which changes are major and minor? Anything\n> which touches the code running on the amphora is \"major\" (ie. like a\n> firmware update). Anything which only touches the controller / driver\n> is \"minor\" (ie. like a driver update).\n> \n> \n>  \n> \n> \n> It seems strange to me that we\'d force even minor changes to\n> configurations to be \"major\" updates for the sake of sending\n> JSON-which-will-immediately-be-turned-into-haproxy.cfg over the wire\n> instead of just the haproxy.cfg. :/\n> \n> \n>  \n> \n> \n> So with that in mind:  Please understand that your model and mine do\n> not have to differ in the slightest when it comes to how to manage\n> \'major\' updates, whether that be running a different driver /\n> controller for the new amphora version (Ick!), or doing on-demand lazy\n> upgrades of amphora as the driver discovers old,\n> incompatible-versioned amphora it needs to update (probably smoothest\n> way to handle this, possibly as a default action of the option 2 I\n> mentioned above), or whether we force all amphora to be updated as\n> soon as possible after a controller update (most risky and probably\n> not the best way to handle this). We\'ve yet to define exactly how this\n> workflow should be handled, but it\'s actually somewhat secondary to\n> the problem of where to render the configs.  (Maybe we should have a\n> conversation about this in another thread?)\n> \n> \n>  \n> \n> \n> And in any case, I\'m not seeing a need to ensure the driver works with\n> anything but the latest amphora image version to which it corresponds\n> (again, keeping in mind that amphora image and driver should be\n> allowed to change at different rates and are therefore versioned\n> separately). :/ This is especially the case if we define the default\n> action to be taken upon a failure to push out a new config to be to\n> check the version of the amphora and upgrade as necessary (ie. lazy\n> upgrading)...\n> \n> \n>  \n> \n> \n> Also, not that we can\'t revisit this of course:  But the v0.5\n> component design entailing a \"VM Driver\" already went through gerrit\n> review and was approved (by yourself even!) This discussion was\n> originally about where to render the haproxy configs, but it really\n> seems like y\'all are against the idea of having an amphora driver\n> interface at all. :/\n> \n> \n>  \n> \n> \n> Stephen\n> \n> \n>  \n> \n> \n> \n>  \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807 \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E9E94EB72248DF4EBBF2EE2688208E8D1C3F44F6@G2W2446.americas.hpqcorp.net>',NULL),('<1410192826.3245.4.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 11:13:46',-18000,'2014-09-08 16:13:46',NULL,'[openstack-dev] doubling our core review bandwidth','> tl;dr I think we should drop our \'needs 2x+2 to land\' rule and instead\n> use \'needs 1x+2\'. We can ease up a large chunk of pressure on our\n> review bottleneck, with the only significant negative being that core\n> reviewers may see less of the code going into the system - but they\n> can always read more to stay in shape if thats an issue :)\n\nI\'m going to make a tangential but somewhat related suggestion.  Instead\nof reducing the number of +2s required, what would happen if we gave our\nmore trusted but non-core reviewers the ability to +2, but leave +A in\nthe hands of the existing cores?  That way, their reviews can be counted\nby the core reviewers.  With this change in policy, you still need two\n+2s, but you have more people that can +2, and you only need one of our\nlimited number of cores to review.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAJ3HoZ2tYBaq0ernL1c7_sJ19-qoKuKD0Ew_-Yb8=cELrOvjMQ@mail.gmail.com>',NULL),('<1410205579.4093136.165092797.16514F6E@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 12:46:19',-25200,'2014-09-08 19:46:19',NULL,'[openstack-dev] China blocking access to OpenStack git review\n	push','On Mon, Sep 8, 2014, at 12:20 PM, Thomas Goirand wrote:\n> Am I dreaming, or is the Chinese government is trying to push for the\n> cloud, they said. However, today, bad surprise:\n> \n> # nmap -p 29418 23.253.232.87\n> \n> Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST\n> Nmap scan report for review.openstack.org (23.253.232.87)\n> Host is up (0.21s latency).\n> PORT      STATE    SERVICE\n> 29418/tcp filtered unknown\n> \n> Oh dear ... not fun!\n> \n> FYI, this is from China Unicom (eg: CNC Group)\n> \n> I\'m guessing that this is the Great Firewall of China awesome automated\n> ban script which detected too many ssh connection to a weird port. It\n> has blocked a few of my servers recently too, as it became a way too\n> aggressive. I very much prefer to use my laptop to use git review than\n> having to bounce around servers. :(\n> \n> Are their alternative IPs that I could use for review.openstack.org?\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n> P.S: If a Chinese official read this, an easy way to unlist (legitimate)\n> servers access would be the first action any reasonable Chinese\n> government people must do.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nAs an alternative to pushing via ssh you can push via https over port\n443 which may bypass this port blockage. Both latest git review and the\nversion of gerrit that we are running support this.\n\nThe first step is to generate a gerrit http password, this will be used\nto authenticate against Gerrit. Go to\nhttps://review.openstack.org/#/settings/http-password and generate a\npassword there (note this is independent of your launchpad openid\npassword).\n\nNext step is to get some code clone it from eg\nhttps://git.openstack.org/openstack-dev/sandbox. Now I am sure there is\na better way to have git-review do this for you with config overrides\nsomewhere but we need to add a git remote in that repo called \'gerrit\'.\nBy default all of our .gitreview files set this up for ssh so we will\nmanually add one. `git remote add gerrit\nhttps://username at review.openstack.org/openstack-dev/sandbox`. Finally\nrun `git review -s` to get the needed commit hook and now you are ready\nto push code with `git review` as you normally would. Note when git\nreview asks for a password it will want the password we generated in the\nfirst step.\n\nI am pretty sure this is can be made easier and the manual git remote\nstep is not required if you set up some overrides in git(review) config\nfiles. Maybe the folks that added https support for git review can fill\nus in.\n\nClark\n\n\n','<540E0188.10708@debian.org>',NULL),('<1410206383.27816.0.camel@bluejungle.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 14:59:43',-18000,'2014-09-08 19:59:43',NULL,'[openstack-dev] [cinder][FFE] request for exceptions in\n xiv_ds8k driver','Alon,\n\nThanks, I have added your request to the etherpad\nhttps://etherpad.openstack.org/p/juno-cinder-approved-ffes and it will\nundergo review.\n\nThanks,\nJay\n\n\nOn Mon, 2014-09-08 at 21:55 +0300, Alon Marx wrote:\n> Hi, \n> \n> Please consider the following code changes as Feature Freeze\n> Exceptions. \n> The first code change is needed to support the latest XIV release\n> (version 11.5.0) and is very important for us, and the second code\n> change is simply support for backups. \n> \n> Add domain support for XIV with multitenancy \n> https://review.openstack.org/#/c/118290/ \n> \n> Add support for backups to xiv_ds8k driver \n> https://review.openstack.org/#/c/118298/ \n> \n> Both changes were uploaded, reviewed and all relevant changes made by\n> Juno-3 date. \n> Both changes are very small and simple. \n> Both changes affect only the xiv_ds8k driver. \n> Because the changes are small and simple and have no general affect\n> the risk is negligible. \n> \n> Thank you, \n> Alon Marx \n> \n> \n> mobile +972549170122, office +97236897824\n> email alonma at il.ibm.com\n> IBM XIV, Cloud Storage Solutions (previously HSG) \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<OFE99BD471.029CD878-ONC2257D4D.00637BFE-C2257D4D.0068082F@il.ibm.com>',NULL),('<1410223629-sup-7522@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-08 18:01:27',-25200,'2014-09-09 01:01:27',NULL,'[openstack-dev] memory usage in devstack-gate (the oom-killer\n	strikes again)','Excerpts from Joe Gordon\'s message of 2014-09-08 15:24:29 -0700:\n> Hi All,\n> \n> We have recently started seeing assorted memory issues in the gate\n> including the oom-killer [0] and libvirt throwing memory errors [1].\n> Luckily we run ps and dstat on every devstack run so we have some insight\n> into why we are running out of memory. Based on the output from job taken\n> at random [2][3] a typical run consists of:\n> \n> * 68 openstack api processes alone\n> * the following services are running 8 processes (number of CPUs on test\n> nodes)\n>   * nova-api (we actually run 24 of these, 8 compute, 8 EC2, 8 metadata)\n>   * nova-conductor\n>   * cinder-api\n>   * glance-api\n>   * trove-api\n>   * glance-registry\n>   * trove-conductor\n> * together nova-api, nova-conductor, cinder-api alone take over 45 %MEM\n> (note: some of that is memory usage is counted multiple times as RSS\n> includes shared libraries)\n> * based on dstat numbers, it looks like we don\'t use that much memory\n> before tempest runs, and after tempest runs we use a lot of memory.\n> \n> Based on this information I have two categories of questions:\n> \n> 1) Should we explicitly set the number of workers that services use in\n> devstack? Why have so many workers in a small all-in-one environment? What\n> is the right balance here?\n\nI\'m kind of wondering why we aren\'t pushing everything to go the same\ndirection keystone did with apache. I may be crazy but apache gives us\nall kinds of tools to tune around process forking that we\'ll have to\nreinvent in our own daemon bits (like MaxRequestsPerChild to prevent\nleaky or slow GC from eating all our memory over time).\n\nMeanwhile, the idea on running api processes with ncpu is that we don\'t\nwant to block an API request if there is a CPU available to it. Of\ncourse if we have enough cinder, nova, keystone, trove, etc. requests\nall at one time that we do need to block, we defer to the CPU scheduler\nof the box to do it, rather than queue things up at the event level.\nThis can lead to quite ugly CPU starvation issues, and that is a lot\neasier to tune for if you have one tuning knob for apache + mod_wsgi\ninstead of nservices.\n\nIn production systems I\'d hope that memory would be quite a bit more\navailable than on the bazillions of cloud instances that run tests. So,\nwhile process-per-cpu-per-service is a large percentage of 8G, it is\na very small percentage of 24G+, which is a pretty normal amount of\nmemory to have on an all-in-one type of server that one might choose\nas a baremetal controller. For VMs that are handling production loads,\nIt\'s a pretty easy trade-off to give them a little more RAM so they can\ntake advantage of all the CPU\'s as needed.\n\nAll this to say, since devstack is always expected to be run in a dev\ncontext, and not production, I think it would make sense to dial it\nback to 4 from ncpu.\n\n> \n> 2) Should we be worried that some OpenStack services such as nova-api,\n> nova-conductor and cinder-api take up so much memory? Does there memory\n> usage keep growing over time, does anyone have any numbers to answer this?\n> Why do these processes take up so much memory?\n\nYes I do think we should be worried that they grow quite a bit. I\'ve\nexperienced this problem a few times in a few scripting languages, and\nalmost every time it turned out to be too much data being read from\nthe database or MQ. Moving to tighter messages, and tighter database\ninteraction, nearly always results in less wasted RAM.\n\nI like the other suggestion to start graphing this. Since we have all\nthat dstat data, I wonder if we can just process that directly into\ngraphite.\n\n\n','<CAHXdxOf+Tfk_UFrvhjKcHPk8TSzQAcWi2+pGSJJqm+qxrtoM1Q@mail.gmail.com>',NULL),('<1410241286.72921.YahooMailNeo@web163604.mail.gq1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-09-08 22:41:26',-25200,'2014-09-09 05:41:26',NULL,'[OpenStack-Infra] [Zuul] fixed jenkins slave error in fetching\n	merged source from zuul','all,\ni faced the following issue a few days ago, and wanted to list here, but not sure if its due to my setup, or the scripts need to be updated. my 3rd party CI setup is configured using puppet scripts from jay pipes\'s repo.\n\ni had an issue with the jenkins slave node picking up the merged patch from zuul server, and the slave node was simply picking up the base code from the master branch without the merged change.\nsaw the foll error (or similar) in?devstack-gate-setup-workspace-new.txt -\n2014-08-27 05:48:44.612 | fatal: repository \'http://<servername>/p/openstack/python-openstackclient/\' not found?\n\nthanks to edgar magana for catching, and skolekonov for helping debug!\n\n\ni made the following changes to apache to ensure it served both virtual hosts, this enabled the jenkins slave node to access the git server on the master.?\n\nupdated 50-jenkins.conf and 50-zuul.conf as below-\n\n\n/etc/apache2/sites-available$\ndiff 50-jenkins.conf 50-jenkins.conf.bak\n1,2c1\n<\n<VirtualHost *:80>\n<????????????? ServerName jenkins\n---\n>\n<VirtualHost jenkins:80>\n15c14\n<\n<VirtualHost *:443>\n---\n>\n<VirtualHost jenkins:443>\n?\n/etc/apache2/sites-available$\ndiff 50-zuul.conf 50-zuul.conf.bak\n1c1\n<\n<VirtualHost *:80>\n---\n>\n<VirtualHost zuul:80>\n\n\nthanks,\ndaya\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140908/89906343/attachment-0001.html>\n\n','<d8e7b1509a2c49dc870004c37a66c3ef@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1410270931.2018.25.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 06:55:31',-25200,'2014-09-09 13:55:31',NULL,'[openstack-dev] [nova][neutron][cinder] Averting the Nova\n crisis by splitting out virt drivers','On Mon, 2014-09-08 at 17:20 -0700, Stefano Maffulli wrote:\n> On 09/05/2014 07:07 PM, James Bottomley wrote:\n> > Actually, I don\'t think this analysis is accurate.  Some people are\n> > simply interested in small aspects of a project.  It\'s the \"scratch your\n> > own itch\" part of open source.  The thing which makes itch scratchers\n> > not lone wolfs is the desire to go the extra mile to make what they\'ve\n> > done useful to the community.  If they never do this, they likely have a\n> > forked repo with only their changes (and are the epitome of a lone\n> > wolf).  If you scratch your own itch and make the effort to get it\n> > upstream, you\'re assisting the community (even if that\'s the only piece\n> > of code you do) and that assistance makes you (at least for a time) part\n> > of the community.\n> \n> I\'m starting to think that the processes we have implemented are slowing\n> down (if not preventing) \"scratch your own itch\" contributions. The CLA\n> has been identified as the cause for this but after carefully looking at\n> our development processes and the documentation, I think that\'s only one\n> part of the problem (and maybe not even as big as initially thought).\n\nCLAs are a well known and documented barrier to casual contributions\n(just look at all the project harmony discussion),  they affect one offs\ndisproportionately since they require an investment of effort to\nunderstand and legal resources are often unavailable to individuals.\nThe key problem for individuals in the US is usually do I or my employer\nown my contribution?  Because that makes a huge difference to the\nprocess for signing.\n\n> The gerrit workflow for example is something that requires quite an\n> investment in time and energy and casual developers (think operators\n> fixing small bugs in code, or documentation) have little incentive to go\n> through the learning curve.\n\nI\'ve done both ... I do prefer the patch workflow to the gerrit one, but\nI think that\'s just because the former is what I used for ten years and\nI\'m very comfortable with it.  The good thing about the patch workflow\nis that the initial barrier is very low.  However, the later barriers\ncan be as high or higher.\n\n> To go back in topic, to the proposal to split drivers out of tree, I\n> think we may want to evaluate other, simpler, paths before we embark in\n> a huge task which is already quite clear will require more cross-project\n> coordination.\n> \n> From conversations with PTLs and core reviewers I get the impression\n> that lots of drivers contributions come with bad code.\n\nBad code is a bit of a pejorative term.  However, I can sympathize with\nthe view: In the Linux Kernel, drivers are often the biggest source of\ncoding style and maintenance issues.  I maintain a driver subsystem and\nI would have to admit that a lot of code that goes into those drivers\nthat wouldn\'t be of sufficient quality to be admitted to the core kernel\nwithout a lot more clean up and flow changes.  However, is this bad\ncode?  It mostly works, so it does the job it\'s designed for.  Usually\nthe company producing the device is the one maintaining the driver so as\nlong as they have the maintenance burden and do their job there\'s no\nreal harm.  It\'s a balance, and sometimes I get it wrong, but I do know\nfrom bitter effort that there\'s a limit to what you can get busy\ndevelopers to do in the driver space.\n\n>  These require a\n> lot of time and reviewers energy to be cleaned up, causing burn out and\n> bad feelings on all sides. What if we establish a new \'place\' of some\n> sort where we can send people to improve their code (or dump it without\n> interfering with core?) Somewhere there may be a workflow\n> \"go-improve-over-there\" where a Community Manager (or mentors or some\n> other program we may invent) takes over and does what core reviewers\n> have been trying to do \'on the side\'? The advantage is that this way we\n> don\'t have to change radically how current teams operate, we may be able\n> to start this immediately with Kilo. Thoughts?\n\nI think it\'s a question of communities, like Daniel said.  In the\nkernel, the driver reviewers are a different community from the core\nkernel code reviewers.  Most core reviewers would probably fry their own\neyeballs before they\'d review device driver code.  So the solution is\nnot to make them; instead we set up a review community of people who\nunderstand driver code and make allowances for some of its\neccentricities.  At the end of the day, bad code is measured by defect\ncount which impacts usability for drivers and the reputation of that\ndriver is what suffers.  I\'m sure in OpenStack, driver reputation is an\neasy way to encourage better drivers ... after all hypervisors are\npretty fungible: if the Bar hypervisor driver is awful, you can use the\nFoo hypervisor instead.  People who want you to switch to the Baz\nhypervisor would need to make sure you have a pretty awesome experience\nwhen you take it for a spin, so they\'re most naturally inclined to spend\nthe time writing good code.\n\nTo me, this means you don\'t really want a sin bin where you dump drivers\nand tell them not to come out until they\'re fit to be reviewed by the\ncore; You want a trusted driver community which does its own reviews and\nmeans the core doesn\'t have to review them.\n\nJames\n\n\n\n\n','<540E47E6.3010809@openstack.org>',NULL),('<1410271049-sup-5127@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 07:02:35',-25200,'2014-09-09 14:02:35',NULL,'[openstack-dev] [All] Maintenance mode in OpenStack during\n	patching/upgrades','Excerpts from Mike Scherbakov\'s message of 2014-09-09 00:35:09 -0700:\n> Hi all,\n> please see below original email below from Dmitry. I\'ve modified the\n> subject to bring larger audience to the issue.\n> \n> I\'d like to split the issue into two parts:\n> \n>    1. Maintenance mode for OpenStack controllers in HA mode (HA-ed\n>    Keystone, Glance, etc.)\n>    2. Maintenance mode for OpenStack computes/storage nodes (no HA)\n> \n> For first category, we might not need to have maintenance mode at all. For\n> example, if we apply patching/upgrade one by one node to 3-node HA cluster,\n> 2 nodes will serve requests normally. Is that possible for our HA solutions\n> in Fuel, TripleO, other frameworks?\n\nYou may have a broken cloud if you are pushing out an update that\nrequires a new schema. Some services are better than others about\nhandling old schemas, and can be upgraded before doing schema upgrades.\nBut most of the time you have to do at least a brief downtime:\n\n * turn off DB accessing services\n * update code\n * run db migration\n * turn on DB accessing services\n\nIt is for this very reason, I believe, that Turbo Hipster was added to\nthe gate, so that deployers running against the upstream master branches\ncan have a chance at performing these upgrades in a reasonable amount of\ntime.\n\n> \n> For second category, can not we simply do \"nova-manage service disable...\",\n> so scheduler will simply stop scheduling new workloads on particular host\n> which we want to do maintenance on?\n> \n\nYou probably would want \'nova host-servers-migrate <host>\' at that\npoint, assuming you have migration set up.\n\nhttp://docs.openstack.org/user-guide/content/novaclient_commands.html\n\n> On Thu, Aug 28, 2014 at 6:44 PM, Dmitry Pyzhov <dpyzhov at mirantis.com> wrote:\n> \n> > All,\n> >\n> > I\'m not sure if it deserves to be mentioned in our documentation, this\n> > seems to be a common practice. If an administrator wants to patch his\n> > environment, he should be prepared for a temporary downtime of OpenStack\n> > services. And he should plan to perform patching in advance: choose a time\n> > with minimal load and warn users about possible interruptions of service\n> > availability.\n> >\n> > Our current implementation of patching does not protect from downtime\n> > during the patching procedure. HA deployments seems to be more or less\n> > stable. But it looks like it is possible to schedule an action on a compute\n> > node and get an error because of service restart. Deployments with one\n> > controller... well, you won?t be able to use your cluster until the\n> > patching is finished. There is no way to get rid of downtime here.\n> >\n> > As I understand, we can get rid of possible issues with computes in HA.\n> > But it will require migration of instances and stopping of nova-compute\n> > service before patching. And it will make the overall patching procedure\n> > much longer. Do we want to investigate this process?\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n\n\n','<CAKYN3rOtBhXujq+ahgpmzggCtATwLuiQH53y_N80JzKDpOL6Lw@mail.gmail.com>',NULL),('<1410271617606.19167@accenture.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-09 14:06:39',0,'2014-09-09 14:06:39',NULL,'[Openstack] Keystone problem','Hi,\n\n\nI did check the attached doc. I find that the keystone is not associated properly with the role.\n\n\nYou can try to unset and then keystone token-get, after which try executing the keystone commands by sourcing from the file.\n\n\nLet me know if that helps.\n\n\nRegards,\n\nRaghavendra Lad\n\n\n________________________________\nFrom: Louis-Philippe Reid <louis.philippe.reid at gmail.com>\nSent: Tuesday, September 9, 2014 7:25 PM\nTo: Lad, Raghavendra\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Keystone problem\n\nThanks for your quick reply,  I found an error in my installation when I defined the endpoint.  I used port 5000 for the adminurl.  I restarted from scratch, once again just to be sure it was clean and made sure ton unset the token and service endpoint has you suggested.  I did use the --os commands.   I did create admin and associate everything.  Also, the error I get since I corrected the adminurl is now different.\n\n[root at lecloud100 ~]# env | grep OS_\nOS_PASSWORD=xxxxxxxxxx\nOS_AUTH_URL=http://lecloud100:35357/v2.0\nOS_USERNAME=admin\nOS_TENANT_NAME=admin\n\n# keystone user-list\n\'NoneType\' object has no attribute \'encode\'\n\n\nHere is all the information used to create the config, line by line and debug outputs:\n\nhttp://pastebin.com/6XWVqBqb\n\nThanks,\n\n\n\nOn Tue, Sep 9, 2014 at 8:07 AM, <raghavendra.lad at accenture.com<mailto:raghavendra.lad at accenture.com>> wrote:\nHi,\n\nYou have to unset the service service token and service endpoint.\nUse the keystone  - -os  command to authenticate admin. Create admin associate this user, role and service.\nLet me know if  you encounter any issues.\n\nRegards,\nRaghavendra Lad\n\nFrom: Louis-Philippe Reid [mailto:louis.philippe.reid at gmail.com<mailto:louis.philippe.reid at gmail.com>]\nSent: Tuesday, September 09, 2014 5:28 PM\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: [Openstack] Keystone problem\n\nHi Everyone,\n\nThis is my second OpenStack installation.  My first installation has been really easy but this time I\'m getting a hard time right at the start with Keystone, hope you can shed some light on this issue.  I must be doing something wrong as I did the previous installation only a week ago.\n\nBasically i\'m stuck at \"verify the identity service installation\", where i\'m testing the admin user.\n\nI get a 404 from running keystone user-list with the admin user.  It\'s running fine using OS_SERVICE_TOKEN and OS_SERVICE_ENDPOINT.\n\nI get a \"Auth token not in the request header.\" when running keystone in debug mode when i run the keystone command.\n\nI can run \"keystone token-get\" and get the normal output (id, tenant_id, user_id, ...).  I get the \"Auth token not in the request header.\" in the log though.\n\nI have dropped the keystone database and I have repeated the keystone installation 2 times with no luck.\n\n# rpm -qa | grep keystone\npython-keystone-2014.1.1-1.el6.noarch\nopenstack-keystone-2014.1.1-1.el6.noarch\npython-keystoneclient-0.9.0-1.el6.noarch\n\nHere is a log of relevant information:\n\nhttp://pastebin.com/GcgyPUbd\n\nThanks for you help.\n\n\n\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com<http://www.accenture.com>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140909/e14d16b6/attachment.html>\n\n','<CAEkz3vpV7x=uah_ROqnCk8A7cGf6LRVfP4SYbd0EPoS7RhANkw@mail.gmail.com>',NULL),('<1410285059.3245.17.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 12:50:59',-18000,'2014-09-09 17:50:59',NULL,'[openstack-dev] [neutron] [nova] non-deterministic gate\n failures due to unclosed eventlet Timeouts','On Mon, 2014-09-08 at 17:25 -0400, Jay Pipes wrote:\n> > Thanks, that might be what\'s causing this timeout/gate failure in the\n> > nova unit tests. [1]\n> >\n> > [1] https://bugs.launchpad.net/nova/+bug/1357578\n> \n> Indeed, there are a couple places where eventlet.timeout.Timeout() seems \n> to be used in the test suite without a context manager or calling \n> close() explicitly:\n> \n> tests/virt/libvirt/test_driver.py\n> 8925:                raise eventlet.timeout.Timeout()\n> \n> tests/virt/hyperv/test_vmops.py\n> 196:        mock_with_timeout.side_effect = etimeout.Timeout()\n\nI looked into that too, but the docs for Timeout indicate that it\'s an\nException subclass, and passing it no args doesn\'t seem to start the\ntimer running.  I think you have to explicitly pass a duration value for\nTimeout to enable its timeout behavior, but that\'s just a guess on my\npart at this point?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<540E1EC2.1050709@gmail.com>',NULL),('<1410286885-sup-2952@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 18:32:38',0,'2014-09-09 18:32:38',NULL,'[openstack-dev] [TripleO] Propose adding StevenK to core reviewers','Hello everyone!\n\nI have been working on a meta-review of StevenK\'s reviews and I would\nlike to propose him as a new member of our core team.\n\nAs I\'m sure many have noticed, he has been above our stats requirements\nfor several months now. More importantly, he has been reviewing a wide\nbreadth of topics and seems to have a strong understanding of our code\nbase. He also seems to be doing a great job at providing valuable\nfeedback and being attentive to responses on his reviews.\n\nAs such, I think he would make a great addition to our core team. Can\nthe other core team members please reply with your votes if you agree or\ndisagree.\n\nThanks!\nGreg\n\n\n',NULL,NULL),('<1410305209-sup-7332@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 16:56:03',-25200,'2014-09-09 23:56:03',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Samuel Merritt\'s message of 2014-09-09 16:12:09 -0700:\n> On 9/9/14, 12:03 PM, Monty Taylor wrote:\n> > On 09/04/2014 01:30 AM, Clint Byrum wrote:\n> >> Excerpts from Flavio Percoco\'s message of 2014-09-04 00:08:47 -0700:\n> >>> Greetings,\n> >>>\n> >>> Last Tuesday the TC held the first graduation review for Zaqar. During\n> >>> the meeting some concerns arose. I\'ve listed those concerns below with\n> >>> some comments hoping that it will help starting a discussion before the\n> >>> next meeting. In addition, I\'ve added some comments about the project\n> >>> stability at the bottom and an etherpad link pointing to a list of use\n> >>> cases for Zaqar.\n> >>>\n> >>\n> >> Hi Flavio. This was an interesting read. As somebody whose attention has\n> >> recently been drawn to Zaqar, I am quite interested in seeing it\n> >> graduate.\n> >>\n> >>> # Concerns\n> >>>\n> >>> - Concern on operational burden of requiring NoSQL deploy expertise to\n> >>> the mix of openstack operational skills\n> >>>\n> >>> For those of you not familiar with Zaqar, it currently supports 2 nosql\n> >>> drivers - MongoDB and Redis - and those are the only 2 drivers it\n> >>> supports for now. This will require operators willing to use Zaqar to\n> >>> maintain a new (?) NoSQL technology in their system. Before expressing\n> >>> our thoughts on this matter, let me say that:\n> >>>\n> >>>      1. By removing the SQLAlchemy driver, we basically removed the\n> >>> chance\n> >>> for operators to use an already deployed \"OpenStack-technology\"\n> >>>      2. Zaqar won\'t be backed by any AMQP based messaging technology for\n> >>> now. Here\'s[0] a summary of the research the team (mostly done by\n> >>> Victoria) did during Juno\n> >>>      3. We (OpenStack) used to require Redis for the zmq matchmaker\n> >>>      4. We (OpenStack) also use memcached for caching and as the oslo\n> >>> caching lib becomes available - or a wrapper on top of dogpile.cache -\n> >>> Redis may be used in place of memcached in more and more deployments.\n> >>>      5. Ceilometer\'s recommended storage driver is still MongoDB,\n> >>> although\n> >>> Ceilometer has now support for sqlalchemy. (Please correct me if I\'m\n> >>> wrong).\n> >>>\n> >>> That being said, it\'s obvious we already, to some extent, promote some\n> >>> NoSQL technologies. However, for the sake of the discussion, lets assume\n> >>> we don\'t.\n> >>>\n> >>> I truly believe, with my OpenStack (not Zaqar\'s) hat on, that we can\'t\n> >>> keep avoiding these technologies. NoSQL technologies have been around\n> >>> for years and we should be prepared - including OpenStack operators - to\n> >>> support these technologies. Not every tool is good for all tasks - one\n> >>> of the reasons we removed the sqlalchemy driver in the first place -\n> >>> therefore it\'s impossible to keep an homogeneous environment for all\n> >>> services.\n> >>>\n> >>\n> >> I whole heartedly agree that non traditional storage technologies that\n> >> are becoming mainstream are good candidates for use cases where SQL\n> >> based storage gets in the way. I wish there wasn\'t so much FUD\n> >> (warranted or not) about MongoDB, but that is the reality we live in.\n> >>\n> >>> With this, I\'m not suggesting to ignore the risks and the extra burden\n> >>> this adds but, instead of attempting to avoid it completely by not\n> >>> evolving the stack of services we provide, we should probably work on\n> >>> defining a reasonable subset of NoSQL services we are OK with\n> >>> supporting. This will help making the burden smaller and it\'ll give\n> >>> operators the option to choose.\n> >>>\n> >>> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> >>>\n> >>>\n> >>> - Concern on should we really reinvent a queue system rather than\n> >>> piggyback on one\n> >>>\n> >>> As mentioned in the meeting on Tuesday, Zaqar is not reinventing message\n> >>> brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack\n> >>> flavor on top. [0]\n> >>>\n> >>\n> >> I think Zaqar is more like SMTP and IMAP than AMQP. You\'re not really\n> >> trying to connect two processes in real time. You\'re trying to do fully\n> >> asynchronous messaging with fully randomized access to any message.\n> >>\n> >> Perhaps somebody should explore whether the approaches taken by large\n> >> scale IMAP providers could be applied to Zaqar.\n> >>\n> >> Anyway, I can\'t imagine writing a system to intentionally use the\n> >> semantics of IMAP and SMTP. I\'d be very interested in seeing actual use\n> >> cases for it, apologies if those have been posted before.\n> >\n> > It seems like you\'re EITHER describing something called XMPP that has at\n> > least one open source scalable backend called ejabberd. OR, you\'ve\n> > actually hit the nail on the head with bringing up SMTP and IMAP but for\n> > some reason that feels strange.\n> >\n> > SMTP and IMAP already implement every feature you\'ve described, as well\n> > as retries/failover/HA and a fully end to end secure transport (if\n> > installed properly) If you don\'t actually set them up to run as a public\n> > messaging interface but just as a cloud-local exchange, then you could\n> > get by with very low overhead for a massive throughput - it can very\n> > easily be run on a single machine for Sean\'s simplicity, and could just\n> > as easily be scaled out using well known techniques for public cloud\n> > sized deployments?\n> >\n> > So why not use existing daemons that do this? You could still use the\n> > REST API you\'ve got, but instead of writing it to a mongo backend and\n> > trying to implement all of the things that already exist in SMTP/IMAP -\n> > you could just have them front to it. You could even bypass normal\n> > delivery mechanisms and do neat things with local injection.\n> >\n> > I don\'t care about the NoSQL question on its own. Mongo is fine. Redis\n> > is fine. I don\'t think either has any features for this use case that\n> > make a licks worth of difference compared to MySQL or Postgres, but I\n> > also don\'t think they are a PROBLEM in an of themselves.\n> >\n> > The main thing I care about here is every description I\'ve heard of what\n> > zaqar wants to do (which does seem to be getting clearer through this\n> > thread) is still well implemented somewhere as an existing scalable\n> > service. Is zaqar actually Rabbit with a REST interface? Is it ejabberd\n> > with a rest interface? Or is it IMAP/SMTP with a REST interface. You\'ll\n> > note that probably nobody would think a single server that wanted to be\n> > both Rabbit AND IMAP/SMTP is a good idea ... at least this is one of the\n> > reasons why we all think Microsoft Exchange is a pile of garbage, no?\n> >\n> > I also worry about the fact that one description of zaqar was used to\n> > communicate a need for divergent requirements (it needs to be a\n> > high-volume fast message broker/queue - which, btw, sounds more like\n> > Rabbit/oslo.messaging and less like what Clint describes above) ... and\n> > that\'s why it wants to use falcon and not pecan and why it wants to use\n> > mongo and not SQL. And then what we\'re doing it reimplementing something\n> > like rabbit except in python (again, given as the justification for\n> > deviating from how other bits of OpenStack work)\n> >\n> > BUT - if that\'s not actually what zaqar is - if it isn\'t a rabbit\n> > replacement and doesn\'t need to do massive high volume sub-second\n> > queuing because what it\'s actually modeling is a message subscription\n> > service that\'s closer to email than to anything else, then there is\n> > nothing about the components that are happily used in the rest of\n> > OpenStack that should be precluded from being used. A REST api written\n> > in pecan should be fine ... as should an SQL backend, because 99% of all\n> > operations are going to be primary key lookups where even a moderately\n> > tuned database should be absolutely fine at keeping up.\n> >\n> > So which is it? Because it sounds like to me it\'s a thing that actually\n> > does NOT need to diverge in technology in any way, but that I\'ve been\n> > told that it needs to diverge because it\'s delivering a different set of\n> > features - and I\'m pretty sure if it _is_ the thing that needs to\n> > diverge in technology because of its feature set, then it\'s a thing I\n> > don\'t think we should be implementing in python in OpenStack because it\n> > already exists and it\'s called AMQP.\n> \n> Whether Zaqar is more like AMQP or more like email is a really strange \n> metric to use for considering its inclusion.\n> \n> Let me put on my web application developer\'s hat. Whenever I\'ve worked \n> on a web app, I\'ve invariably wound up needing HTTP servers, background \n> workers, and some sort of queue to connect the two.\n> \n> I\'ve done the thing where I\'ve stored queue entries in the app\'s \n> database and had the workers poll for jobs; the load adds up \n> surprisingly fast, and it\'s got some bad positive-feedback failure \n> modes. However, it is nice and durable, so my app doesn\'t lose messages.\n> \n> I\'ve done the thing where I\'ve thrown together a VM and stuck Redis or \n> rabbitmq or beanstalkd on it. That gets me nice, fast queues, but no \n> semblance of reliability. If that one VM dies, all my queued messages \n> are lost.\n> \n> Then there\'s Zaqar, which is this nice HTTP API that I can use for my \n> application\'s queues. I go and make a couple of POST requests and now \n> I\'ve got some queues for my application to use. My app servers POST \n> messages to their queues, and my background workers sit and make GET \n> requests for messages to process. I can have the whole thing up and \n> running in a few hours. Better yet, I barely have to monitor the thing. \n> I can poll for queue stats every few minutes and alert if the queue gets \n> too full, but that\'s all I\'ve got to do. I don\'t have to worry about my \n> queue VM going into swap, or my queue VM\'s NIC getting saturated, or \n> kernel panics, or automatically promoting rabbitmq slaves to masters, or \n> waking up at 3 AM to fix my app when I lose messages during a rabbitmq \n> promotion, or any of that stuff. Using Zaqar means I can just worry \n> about my application and leave all that other garbage to my cloud provider.\n\nWhat you just described is the queue pattern I spoke of.\n\nIt does not require random access by message ID in any way shape or\nform. It is also well served by AMQP. I wonder if people are still\nconfused by Zaqar\'s API and architecture because this would be fine for\nan architecture if what you describe above were the requirements:\n\nhttps://www.dropbox.com/s/yonloa9ytlf8fdh/ZaqarQueueOnly.png?dl=0\n\nJust stick a REST shim in front of AMQP that enforces tenant permissions\nand maps logical \"zaqar queues\" to whatever the backend serving queue is.\n\nSo why would we need a NoSQL database for the data itself if all we are\ndoing is shoving messages in and taking them out the other end?\n\n\n','<540F8949.9000804@swiftstack.com>',NULL),('<1410307370-sup-4742@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 17:03:11',-25200,'2014-09-10 00:03:11',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Devananda van der Veen\'s message of 2014-09-09 16:47:27 -0700:\n> On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt <sam at swiftstack.com> wrote:\n> > On 9/9/14, 12:03 PM, Monty Taylor wrote:\n> [snip]\n> >> So which is it? Because it sounds like to me it\'s a thing that actually\n> >> does NOT need to diverge in technology in any way, but that I\'ve been\n> >> told that it needs to diverge because it\'s delivering a different set of\n> >> features - and I\'m pretty sure if it _is_ the thing that needs to\n> >> diverge in technology because of its feature set, then it\'s a thing I\n> >> don\'t think we should be implementing in python in OpenStack because it\n> >> already exists and it\'s called AMQP.\n> >\n> >\n> > Whether Zaqar is more like AMQP or more like email is a really strange\n> > metric to use for considering its inclusion.\n> >\n> \n> I don\'t find this strange at all -- I had been judging the technical\n> merits of Zaqar (ex-Marconi) for the last ~18 months based on the\n> understanding that it aimed to provide Queueing-as-a-Service, and\n> found its delivery of that to be lacking on technical grounds. The\n> implementation did not meet my view of what a queue service should\n> provide; it is based on some serious antipatterns (storing a queue in\n> an RDBMS is probably the most obvious); and in fact, it isn\'t even\n> queue-like in the access patterns enabled by the REST API (random\n> access to a set != a queue). That was the basis for a large part of my\n> objections to the project over time, and a source of frustration for\n> me as the developers justified many of their positions rather than\n> accepted feedback and changed course during the incubation period. The\n> reason for this seems clear now...\n> \n> As was pointed out in the TC meeting today, Zaqar is (was?) actually\n> aiming to provide Messaging-as-a-Service -- not queueing as a service!\n> This is another way of saying \"it\'s more like email and less like\n> AMQP\", which means my but-its-not-a-queue objection to the project\'s\n> graduation is irrelevant, and I need to rethink about all my previous\n> assessments of the project.\n\nWell said.\n\n\n','<CAExZKEozQy2uwEs5eR0RVorKY=c_GG9jpqyAyWThZ8RJpA2zEw@mail.gmail.com>',NULL),('<1410329255-sup-1268@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 23:15:29',-25200,'2014-09-10 06:15:29',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Samuel Merritt\'s message of 2014-09-09 19:04:58 -0700:\n> On 9/9/14, 4:47 PM, Devananda van der Veen wrote:\n> > On Tue, Sep 9, 2014 at 4:12 PM, Samuel Merritt <sam at swiftstack.com> wrote:\n> >> On 9/9/14, 12:03 PM, Monty Taylor wrote:\n> > [snip]\n> >>> So which is it? Because it sounds like to me it\'s a thing that actually\n> >>> does NOT need to diverge in technology in any way, but that I\'ve been\n> >>> told that it needs to diverge because it\'s delivering a different set of\n> >>> features - and I\'m pretty sure if it _is_ the thing that needs to\n> >>> diverge in technology because of its feature set, then it\'s a thing I\n> >>> don\'t think we should be implementing in python in OpenStack because it\n> >>> already exists and it\'s called AMQP.\n> >>\n> >>\n> >> Whether Zaqar is more like AMQP or more like email is a really strange\n> >> metric to use for considering its inclusion.\n> >>\n> >\n> > I don\'t find this strange at all -- I had been judging the technical\n> > merits of Zaqar (ex-Marconi) for the last ~18 months based on the\n> > understanding that it aimed to provide Queueing-as-a-Service, and\n> > found its delivery of that to be lacking on technical grounds. The\n> > implementation did not meet my view of what a queue service should\n> > provide; it is based on some serious antipatterns (storing a queue in\n> > an RDBMS is probably the most obvious); and in fact, it isn\'t even\n> > queue-like in the access patterns enabled by the REST API (random\n> > access to a set != a queue). That was the basis for a large part of my\n> > objections to the project over time, and a source of frustration for\n> > me as the developers justified many of their positions rather than\n> > accepted feedback and changed course during the incubation period. The\n> > reason for this seems clear now...\n> >\n> > As was pointed out in the TC meeting today, Zaqar is (was?) actually\n> > aiming to provide Messaging-as-a-Service -- not queueing as a service!\n> > This is another way of saying \"it\'s more like email and less like\n> > AMQP\", which means my but-its-not-a-queue objection to the project\'s\n> > graduation is irrelevant, and I need to rethink about all my previous\n> > assessments of the project.\n> >\n> > The questions now before us are:\n> > - should OpenStack include, in the integrated release, a\n> > messaging-as-a-service component?\n> \n> I certainly think so. I\'ve worked on a few reasonable-scale web \n> applications, and they all followed the same pattern: HTTP app servers \n> serving requests quickly, background workers for long-running tasks, and \n> some sort of durable message-broker/queue-server thing for conveying \n> work from the first to the second.\n> \n> A quick straw poll of my nearby coworkers shows that every non-trivial \n> web application that they\'ve worked on in the last decade follows the \n> same pattern.\n> \n> While not *every* application needs such a thing, web apps are quite \n> common these days, and Zaqar satisfies one of their big requirements. \n> Not only that, it does so in a way that requires much less babysitting \n> than run-your-own-broker does.\n> \n\nI think you missed the distinction.\n\nWhat you describe is _message queueing_. Not messaging. The difference\nbeing the durability and addressability of each message.\n\nAs Devananda pointed out, a queue doesn\'t allow addressing the items in\nthe queue directly. You can generally only send, receive, ACK, or NACK.\n\n\n','<540FB1CA.9010000@swiftstack.com>',NULL),('<1410329761-sup-3773@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-09 23:33:35',-25200,'2014-09-10 06:33:35',NULL,'[openstack-dev] [Heat] convergence flow diagrams','Excerpts from Angus Salkeld\'s message of 2014-09-08 17:15:04 -0700:\n> On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant <ishant.tyagi at hp.com> wrote:\n> \n> >  Hi All,\n> >\n> >\n> >\n> > As per the heat mid cycle meetup whiteboard, we have created the\n> > flowchart and sequence diagram for the convergence . Can you please review\n> > these diagrams and provide your feedback?\n> >\n> >\n> >\n> > https://www.dropbox.com/sh/i8qbjtgfdxn4zx4/AAC6J-Nps8J12TzfuCut49ioa?dl=0\n> >\n> >\n> Great! Good to see something.\n> \n> \n> I was expecting something like:\n> engine ~= like nova-conductor (it\'s the only process that talks to the db -\n> make upgrading easier)\n\nThis complicates things immensely. The engine can just be the workers\ntoo, we\'re just not going to do the observing and converging in the same\ngreenthread.\n\n> observer - purely gets the actual state/properties and writes then to the\n> db (via engine)\n\nIf you look closely at the diagrams, thats what it does.\n\n> worker - has a \"job\" queue and grinds away at running those (resource\n> actions)\n> \n\nThe convergence worker is just another set of RPC API calls that split\nout work into isolated chunks.\n\n> Then engine then \"triggers\" on differences on goal vs. actual state and\n> create a job and sends it to the job queue.\n\nRemember, we\'re not targeting continuous convergence yet. Just\nconvergence when we ask for things.\n\n> - so, on create it sees there is no actual state so it sends a create job\n> for the first resource to the worker queue\n\nThe diagram shows that, but confusingly says \"is difference = 1\". In\nthe original whiteboard this is \'if diff = DNE\'. DNE stands for Does\nNot Exist.\n\n> - when the observer writes the new state for that resource it triggers the\n> next resource create in the dependency tree.\n\nNot the next resource create, but the next resource convergence. And not\njust one either. I think one of the graphs was forgotten, it goes like\nthis:\n\nhttps://www.dropbox.com/s/1h2ee151iriv4i1/resolve_graph.svg?dl=0\n\nThat is what we called \"return happy\" because we were at hour 9 or so of\ntalking and we got a bit punchy. I\'ve renamed it \'resolve_graph\'.\n\n> - like any system that relies on notifications we need timeouts and each\n> stack needs a periodic \"notification\" to make sure\n\n\nThis is, again, the continuous observer model.\n\nhttps://review.openstack.org/#/c/100012/\n\n>   that progress is been made or notify the user that no progress is being\n> made.\n> \n> One question about the observer (in either my setup or the one in the\n> diagram).\n> - If we are relying on rpc notifications all the observer processes will\n> receive a copy of the same notification\n\nPlease read that spec. We talk about a filter.\n\n\n','<CAA16xcyi+oR4sZEjh0fRf=kNkxdYv7XhVDRbC5ijMfzgy_WhfQ@mail.gmail.com>',NULL),('<1410373170-sup-137@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 11:29:57',-25200,'2014-09-10 18:29:57',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Gordon Sim\'s message of 2014-09-10 06:18:52 -0700:\n> On 09/10/2014 09:58 AM, Flavio Percoco wrote:\n> > To clarify the doubts of what Zaqar is or it\'s not, let me quote what\'s\n> > written in the project\'s overview section[0]:\n> >\n> >     \"Zaqar is a multi-tenant cloud messaging service for web developers.\n> \n> How are different tenants isolated from each other? Can different \n> tenants access the same queue? If so, what does Zaqar do to prevent one \n> tenant from negatively affecting the other? If not, how is communication \n> with other tenants achieved.\n> \n> Most messaging systems allow authorisation to be used to restrict what a \n> particular user can access and quotas to restrict their resource \n> consumption. What does Zaqar do differently?\n> \n> > It\n> > combines the ideas pioneered by Amazon\'s SQS product with additional\n> > semantics to support event broadcasting.\n> >\n> >     The service features a fully RESTful API, which developers can use to\n> > send messages between various components of their SaaS and mobile\n> > applications, by using a variety of communication patterns. Underlying\n> > this API is an efficient messaging engine designed with scalability and\n> > security in mind.\n> >\n> >     Other OpenStack components can integrate with Zaqar to surface events\n> > to end users and to communicate with guest agents that run in the\n> > \"over-cloud\" layer.\n> \n> I may be misunderstanding the last sentence, but I think *direct* \n> integration of other OpenStack services with Zaqar would be a bad idea.\n> \n> Wouldn\'t this be better done through olso.messaging\'s notifications in \n> some way? and/or through some standard protocol (and there\'s more than \n> one to choose from)?\n> \n\nIt\'s not direct, nobody is suggesting that.\n\nWhat people are suggesting is that a user would be able to tell Nova\nto put any messages that would want to deliver in a _user_ focused\nqueue/inbox.\n\nThis has nothing to do with oslo.messaging. Users don\'t want many options\nfor backends. They want a simple message passing interface so they don\'t\nhave to babysit one and choose one.\n\nCertainly the \"undercloud\" Zaqar API could be based on the existing\noslo.messaging notifications. A simple daemon that sits between the oslo\nnotifications firehose and Zaqar\'s user queues would be quite efficient.\n\nHowever, putting the whole burden of talking directly to a notification\nbus on the users is unnecessarily complex... especially if they use Java\nand have no idea what oslo is.\n\n> Communicating through a specific, fixed messaging system, with its own \n> unique protocol is actually a step backwards in my opinion, especially \n> for things that you want to keep as loosely coupled as possible. This is \n> exactly why various standard protocols emerged.\n> \n\nYou\'re thinking like an operator. Think like an application developer.\nThey\'re asking you \"how do I subscribe to notifications about _just my\ninstances_ from Nova?\", not \"how do I pump 40,000 messages per second\nthrough a message bus that I fully control?\"\n\n\n','<54104FBC.8040006@redhat.com>',NULL),('<1410410714.5714.5.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 04:45:14',0,'2014-09-11 04:45:14',NULL,'[openstack-dev] [WSME] Complex Type Validation Issue On\n Deserialization','I\'m having an issue where incoming validation of a complex type with a an attribute of type IPv4Address is failing validation when it is a correct ipv4 address.  Same is happening for UuidType and IPv6AddressType.  I am using using Pecan with WSME 0.6.1 and python 2.7.6.\n\nComplex Type:\nclass LoadBalancer(wtypes.Base):\n    ip_address = wtypes.wsattr(wtypes.IPv4AddressType)\n\nController Method:\n@pecan.wsexpose(v1types.LoadBalancer, body=v1types.LoadBalancer)\ndef post(self, load_balancer):\n   return load_balancer\n\n\nWhen doing a POST to the correct resource with this body:\n\n{\"ip_address\": \"10.0.0.1\"}\n\nI am getting this error:\n\n{\ndebuginfo: null\nfaultcode: \"Server\"\nfaultstring: \"Value should be IPv4 format\"\n}\n\n\nit looks like in the fromjson method when it starts validating the actual ip \"10.0.0.1\" it is sending an instantiation of the IPv4AddressType instead of the actual ip address \"10.0.0.1\" to wsme.types.validate_value.  Am I doing something wrong or is this a bug?  The stack trace did not yield anymore information, unless you want the actual methods called.  I can provide that if needed.\n\nThanks,\nBrandon\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/28e18d2f/attachment.html>\n\n','<CANWE-CkxqKOxa3Ud-tGg3x+JoTJgCsF742N9ewA1eiUmGiOjpA@mail.gmail.com>',NULL),('<1410417283.7133.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 06:34:42',0,'2014-09-11 06:34:42',NULL,'[openstack-dev] [WSME] Complex Type Validation Issue On\n Deserialization','Fixed the issue and it\'s a boneheaded one as I suspected.\n\nI need to initialize the type ala wtypes.IPv4AddressType() instead of\njust wtypes.IPv4AddressType.\n\nDoes appear that the validation for the IPv4AddressType has a bug where\nis should return the value, but there is no return at all.\n\nThanks,\nBrandon\n\nOn Thu, 2014-09-11 at 04:45 +0000, Brandon Logan wrote:\n> I\'m having an issue where incoming validation of a complex type with a\n> an attribute of type IPv4Address is failing validation when it is a\n> correct ipv4 address.  Same is happening for UuidType and\n> IPv6AddressType.  I am using using Pecan with WSME 0.6.1 and python\n> 2.7.6.\n> \n> Complex Type:\n> class LoadBalancer(wtypes.Base):\n>     ip_address = wtypes.wsattr(wtypes.IPv4AddressType)\n> \n> Controller Method:\n> @pecan.wsexpose(v1types.LoadBalancer, body=v1types.LoadBalancer)\n> def post(self, load_balancer):\n>    return load_balancer\n> \n> \n> When doing a POST to the correct resource with this body:\n> \n> {\"ip_address\": \"10.0.0.1\"}\n> \n> I am getting this error:\n> \n> {\n> debuginfo: null\n> faultcode: \"Server\"\n> faultstring: \"Value should be IPv4 format\"\n> }\n> \n> \n> it looks like in the fromjson method when it starts validating the\n> actual ip \"10.0.0.1\" it is sending an instantiation of the\n> IPv4AddressType instead of the actual ip address \"10.0.0.1\" to\n> wsme.types.validate_value.  Am I doing something wrong or is this a\n> bug?  The stack trace did not yield anymore information, unless you\n> want the actual methods called.  I can provide that if needed.\n> \n> Thanks,\n> Brandon \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1410410714.5714.5.camel@localhost>',NULL),('<1410446119.2103.30.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 07:35:19',-25200,'2014-09-11 14:35:19',NULL,'[openstack-dev] [nova][neutron][cinder] Averting the Nova\n crisis by splitting out virt drivers','On Thu, 2014-09-11 at 07:36 -0400, Sean Dague wrote:\n> >>> b) The conflict Dan is speaking of is around the current situation where we\n> >>> have a limited core review team bandwidth and we have to pick and choose\n> >>> which virt driver-specific features we will review. This leads to bad\n> >>> feelings and conflict.\n> >>\n> >> The way this worked in the past is we had cores who were subject\n> >> matter experts in various parts of the code -- there is a clear set of\n> >> cores who \"get\" xen or libivrt for example and I feel like those\n> >> drivers get reasonable review times. What\'s happened though is that\n> >> we\'ve added a bunch of drivers without adding subject matter experts\n> >> to core to cover those drivers. Those newer drivers therefore have a\n> >> harder time getting things reviewed and approved.\n> > \n> > FYI, for Juno at least I really don\'t consider that even the libvirt\n> > driver got acceptable review times in any sense. The pain of waiting\n> > for reviews in libvirt code I\'ve submitted this cycle is what prompted\n> > me to start this thread. All the virt drivers are suffering way more\n> > than they should be, but those without core team representation suffer\n> > to an even greater degree.  And this is ignoring the point Jay & I\n> > were making about how the use of a single team means that there is\n> > always contention for feature approval, so much work gets cut right\n> > at the start even if maintainers of that area felt it was valuable\n> > and worth taking.\n> \n> I continue to not understand how N non overlapping teams makes this any\n> better. You have to pay the integration cost somewhere. Right now we\'re\n> trying to pay it 1 patch at a time. This model means the integration\n> units get much bigger, and with less common ground.\n\nOK, so look at a concrete example: in 2002, the Linux kernel went with\nbitkeeper precisely because we\'d reached the scaling limit of a single\nintegration point, so we took the kernel from a single contributing team\nto a bunch of them.  This was expanded with git in 2005 and leads to the\nhundreds of contributing teams we have today.\n\nThe reason this scales nicely is precisely because the integration costs\nare lower.  However, there are a couple of principles that really assist\nus getting there.  The first is internal API management: an Internal API\nis a contract between two teams (may be more, but usually two).  If\nsomeone wants to change this API they have to negotiate between the two\n(or more) teams.  This naturally means that only the affected components\nreview this API change, but *only* they need to review it, so it doesn\'t\nbubble up to the whole kernel community.  The second is automation:\nlinux-next and the zero day test programme build and smoke test an\nintegration of all our development trees.  If one team does something\nthat impacts another in their development tree, this system gives us\nimmediate warning.  Basically we run continuous integration, so when\nLinus does his actual integration pull, everything goes smoothly (that\'s\nhow we integrate all the 300 or so trees for a kernel release in about\nten days).  We also now have a lot of review automation (checkpatch.pl\nfor instance), but that\'s independent of the number of teams\n\nIn this model the scaling comes from the local reviews and integration.\nThe more teams the greater the scaling.  The factor which obstructs\nscaling is the internal API ... it usually doesn\'t make sense to\nseparate a component where there\'s no API between the two pieces ...\nhowever, if you think there should be, separating and telling the teams\nto figure it out is a great way to generate the API.   The point here is\nthat since an API is a contract, forcing people to negotiate and abide\nby the contract tends to make them think much more carefully about it.\nInternal API moves from being a global issue to being a local one.\n\nBy the way, the extra link work is actually time well spent because it\nmeans the link APIs are negotiated by teams with use cases not just\ndesigned by abstract architecture.  The greater the link pain the\ngreater the indication that there\'s an API problem and the greater the\npressure on the teams either end to fix it.  Once the link pain is\nminimised, the API is likely a good one.\n\n> Look at how much active work in crossing core teams we\'ve had to do to\n> make any real progress on the neutron replacing nova-network front. And\n> how slow that process is. I think you\'ll see that hugely show up here.\n\nWell, as I said, separating the components leads to API negotiation\nbetween the teams  Because of the API negotiation, taking one thing and\nmaking it two does cause more work, and it\'s visible work because the\ntwo new teams get to do the API negotiation which didn\'t exist before.\nThe trick to getting the model to scale is the network effect.  The\nscaling comes by splitting out into high numbers of teams (say N) the\nadded work comes in the links (the API contracts) between the N teams.\nIf the network is star shaped (everything touches everything else), then\nyou\'ve achieved nothing other than a large increase in work because you\nnow have N(N-1) links to negotiate and they\'re global not local.\nHowever, if the connections are nicely local and hierarchical, you find\nthat the number of connections is much lower than N^2 (in fact o(N) is\nthe ideal scaling ratio because that means the network is largely local)\nand you gain a lot of scaling.\n\nThe point is just separating may not give scale because you also need to\nminimise the number of links by seeking locality.  In the nova case,\nseparating nova core from drivers core will give you a link, but the API\nis fairly well known already.  Separating individual drivers from driver\ncore gives you one link per driver, but no link to the core, so if you\nmake the drivers core team up from the drivers teams, you should give\nadded velocity to driver development and review and it only needs to\nnegotiate with the nova core if the driver core API needs modifying.\nThe drivers can negotiate with the drivers core for their local needs.\nThe pain on the nova<->driver core link is what keeps that API sane\nbecause changes have to be well considered.\n\nJames\n\n\n\n\n','<54118922.1060705@dague.net>',NULL),('<1410450005.2103.37.camel@jarvis.lan>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 08:40:05',-25200,'2014-09-11 15:40:05',NULL,'[openstack-dev] [nova][neutron][cinder] Averting the Nova\n crisis by splitting out virt drivers','On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:\n> On 11 September 2014 15:35, James Bottomley\n> <James.Bottomley at hansenpartnership.com> wrote:\n> \n> > OK, so look at a concrete example: in 2002, the Linux kernel went with\n> > bitkeeper precisely because we\'d reached the scaling limit of a single\n> > integration point, so we took the kernel from a single contributing team\n> > to a bunch of them.  This was expanded with git in 2005 and leads to the\n> > hundreds of contributing teams we have today.\n> \n> \n> One thing the kernel has that Openstack doesn\'t, that alter the way\n> this model plays out, is a couple of very strong, forthright and frank\n> personalities at the top who are pretty well respected. Both Andrew\n> and Linux (and others) regularly if not frequently rip into ideas\n> quite scathingly, even after they have passed other barriers and\n> gauntlets and just say no to things. Openstack has nothing of this\n> sort, and there is no evidence that e.g. the TC can, should or desire\n> to fill this role.\n\nLinus is the court of last appeal.  It\'s already a team negotiation\nfailure if stuff bubbles up to him.  The somewhat abrasive response\nyou\'ll get if you\'re being stupid acts as strong downward incentive on\nthe teams to sort out their own API squabbles *before* they get this\ntype of visibility.\n\nThe whole point of open source is aligning the structures with the\ndesire to fix it yourself.  In an ideal world, everything would get\nsorted at the local level and nothing would bubble up.  Of course, the\nworld isn\'t ideal, so you need some court of last appeal, but it doesn\'t\nhave to be an individual ... it just has to be something that\'s\ndaunting, to encourage local settlement, and decisive.\n\nEvery process has to have something like this anyway.  If there\'s no\nprocess way of sorting out intractable disputes, they go on for ever and\ndamage the project.\n\nJames\n\n\n\n\n','<CAOyZ2aGv_TOd9TZ18aMtHpokTHLa9aO-_kGQ2_FZ8mP1D4EhNA@mail.gmail.com>',NULL),('<1410458520.18368.69.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 14:02:00',-14400,'2014-09-11 18:02:00',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out virt drivers','On Thu, 2014-09-04 at 11:24 +0100, Daniel P. Berrange wrote:\n> Position statement\n> ==================\n> \n> Over the past year I\'ve increasingly come to the conclusion that\n> Nova is heading for (or probably already at) a major crisis. If\n> steps are not taken to avert this, the project is likely to loose\n> a non-trivial amount of talent, both regular code contributors and\n> core team members. That includes myself. This is not good for\n> Nova\'s long term health and so should be of concern to anyone\n> involved in Nova and OpenStack.\n> \n> For those who don\'t want to read the whole mail, the executive\n> summary is that the nova-core team is an unfixable bottleneck\n> in our development process with our current project structure.\n> The only way I see to remove the bottleneck is to split the virt\n> drivers out of tree and let them all have their own core teams\n> in their area of code, leaving current nova core to focus on\n> all the common code outside the virt driver impls. I, now, none\n> the less urge people to read the whole mail.\n> \n\n\nI\'ve always referred to the virt/driver.py API as an internal API\nmeaning there are no guarantees about it being preserved across\nreleases. I\'m not saying this is correct... just that it is what we\'ve\ngot.  While OpenStack attempts to do a good job at stabilizing its\npublic API\'s we haven\'t done the same for internal API\'s. It is actually\nquite painful to be out of tree at this point as I\'ve seen with the\nIronic driver being out of the Nova tree. (really glad that is back in\nnow!)\n\nSo because we haven\'t designed things to be split out in this regard we\ncan\'t just go and do it. \n\nI tinkered with some numbers... not sure if this helps or hurts my\nstance but here goes. By my calculation this is the number of commits\nwe\'ve made that touched each virt driver tree for the last 3 releases\nplus stuff done to-date in Juno.\n\nCreated using a command like this in each virt directory for each\nrelease: git log origin/stable/havana..origin/stable/icehouse\n--no-merges --pretty=oneline . | wc -l\n\nessex => folsom:\n\n baremetal: 26\n hyperv: 9\n libvirt: 222\n vmwareapi: 18\n xenapi: 164\n* total for above: 439\n\nfolsom => grizzly:\n\n baremetal: 83\n hyperv: 58\n libvirt: 254\n vmwareapi: 59\n xenapi: 126\n   * total for above: 580\n\ngrizzly => havana:\n\n baremetal: 48\n hyperv: 55\n libvirt: 157\n vmwareapi: 105\n xenapi: 123\n   * total for above: 488\n\nhavana => icehouse:\n\n baremetal: 45\n hyperv: 42\n libvirt: 212\n vmwareapi: 121\n xenapi: 100\n   * total for above: 520\n\nicehouse => master:\n\n baremetal: 26\n hyperv: 32\n libvirt: 188\n vmwareapi: 121\n xenapi: 71\n   * total for above: 438\n\n-------\n\nA couple of things jump out at me from the numbers:\n\n -drivers that are being deprecated (baremetal) still have lots of\nchanges. Some of these changes are valid bug fixes for the driver but a\nmajority of them are actually related to internal cleanups and interface\nchanges. This goes towards the fact that Nova isn\'t mature enough to do\na split like this yet.\n\n -the number of commits landed isn\'t growing *that* much across releases\nin the virt driver trees. Presumably we think we were doing a better job\n2 years ago? But the number of changes in the virt trees is largely the\nsame... perhaps this is because people aren\'t submitting stuff because\nthey are frustrated though?\n\n-------\n\nFor comparison here are the total number of commits for each Nova\nrelease (includes the above commits):\n\nessex -> folsom: 1708\nfolsom -> grizzly: 2131\ngrizzly -> havana: 2188\nhavana -> icehouse: 1696\nicehouse -> master: 1493\n\n-------\n\nSo say around 30% of the commits for a given release touch the virt\ndrivers themselves.. many of them aren\'t specifically related to the\nvirt drivers. Rather just general Nova internal cleanups because the\ninterfaces aren\'t stable.\n\nAnd while splitting Nova virt drivers might help out some I\'m not sure\nit helps the general Nova issue in that we have more reviews with less\nof the good ones landing. Nova is a weird beast at the moment and just\nsplitting things like this is probably going to harm as much as it helps\n(like we saw with Ironic) unless we stabilize the APIs... and even then\nI\'m skeptical of death by a million tiny sub-projects. I\'m just not\nconvinced this is the number #1 pain point around Nova reviews. What\nabout the other 70%?\n\nFor me a lot of the frustration with reviews is around test/gate time,\npushing things through, rechecks, etc... and if we break something it\ntakes just as much time to get the revert in. The last point (the\nability to revert code quickly) is a really important one as it\nsometimes takes days to get a simple (obvious) revert landed. This\nleaves groups like TripleO who have their own CI and 3rd party testing\nsystems which also capable of finding many critical issues in the\ndifficult position of having to revert/cherry pick critical changes for\ndays at a time in order to keep things running.\n\nMaybe I\'m impatient (I totally am!) but I see much of the review\nslowdown as a result of the feedback loop times increasing over the\nyears. OpenStack has some really great CI and testing but I think our\nfocus on not breaking things actually has us painted into a corner. We\nare losing our agility and the review process is paying the price. At\nthis point I think splitting out the virt drivers would be more of a\ndistraction than a help.\n\nDan\n\n\n\n\n\n\n','<20140904102428.GE772@redhat.com>',NULL),('<1410462050-sup-3110@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 12:11:25',-25200,'2014-09-11 19:11:25',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Flavio Percoco\'s message of 2014-09-11 04:14:30 -0700:\n> On 09/10/2014 03:45 PM, Gordon Sim wrote:\n> > On 09/10/2014 01:51 PM, Thierry Carrez wrote:\n> >> I think we do need, as Samuel puts it, \"some sort of durable\n> >> message-broker/queue-server thing\". It\'s a basic application building\n> >> block. Some claim it\'s THE basic application building block, more useful\n> >> than database provisioning. It\'s definitely a layer above pure IaaS, so\n> >> if we end up splitting OpenStack into layers this clearly won\'t be in\n> >> the inner one. But I think \"IaaS+\" basic application building blocks\n> >> belong in OpenStack one way or another. That\'s the reason I supported\n> >> Designate (\"everyone needs DNS\") and Trove (\"everyone needs DBs\").\n> >>\n> >> With that said, I think yesterday there was a concern that Zaqar might\n> >> not fill the \"some sort of durable message-broker/queue-server thing\"\n> >> role well. The argument goes something like: if it was a queue-server\n> >> then it should actually be built on top of Rabbit; if it was a\n> >> message-broker it should be built on top of postfix/dovecot; the current\n> >> architecture is only justified because it\'s something in between, so\n> >> it\'s broken.\n> > \n> > What is the distinction between a message broker and a queue server? To\n> > me those terms both imply something broadly similar (message broker\n> > perhaps being a little bit more generic). I could see Zaqar perhaps as\n> > somewhere between messaging and data-storage.\n> \n> I agree with Gordon here. I really don\'t know how to say this without\n> creating more confusion. Zaqar is a messaging service. Messages are the\n> most important entity in Zaqar. This, however, does not forbid anyone to\n> use Zaqar as a queue. It has the required semantics, it guarantees FIFO\n> and other queuing specific patterns. This doesn\'t mean Zaqar is trying\n> to do something outside its scope, it comes for free.\n> \n\nIt comes with a huge cost actually, so saying it comes for free is a\nmisrepresentation. It is a side effect of developing a superset of\nqueueing. But that superset is only useful to a small number of your\nstated use cases. Many of your use cases (including the one I\'ve been\ninvolved with, Heat pushing metadata to servers) are entirely served by\nthe much simpler, much lighter weight, pure queueing service.\n\n> Is Zaqar being optimized as a *queuing* service? I\'d say no. Our goal is\n> to optimize Zaqar for delivering messages and supporting different\n> messaging patterns.\n> \n\nAwesome! Just please don\'t expect people to get excited about it for\nthe lighter weight queueing workloads that you\'ve claimed as use cases.\n\nI totally see Horizon using it to keep events for users. I see Heat\nusing it for stack events as well. I would bet that Trove would benefit\nfrom being able to communicate messages to users.\n\nBut I think in between Zaqar and the backends will likely be a lighter\nweight queue-only service that the users can just subscribe to when they\ndon\'t want an inbox. And I think that lighter weight queue service is\nfar more important for OpenStack than the full blown random access\ninbox.\n\nI think the reason such a thing has not appeared is because we were all\nsort of running into \"but Zaqar is already incubated\". Now that we\'ve\nfleshed out the difference, I think those of us that need a lightweight\nmulti-tenant queue service should add it to OpenStack.  Separately. I hope\nthat doesn\'t offend you and the rest of the excellent Zaqar developers. It\nis just a different thing.\n\n> Should we remove all the semantics that allow people to use Zaqar as a\n> queue service? I don\'t think so either. Again, the semantics are there\n> because Zaqar is using them to do its job. Whether other folks may/may\n> not use Zaqar as a queue service is out of our control.\n> \n> This doesn\'t mean the project is broken.\n> \n\nNo, definitely not broken. It just isn\'t actually necessary for many of\nthe stated use cases.\n\n\n','<54118416.7090209@redhat.com>',NULL),('<1410473147.3245.21.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 17:05:47',-18000,'2014-09-11 22:05:47',NULL,'[openstack-dev] [solum] pep8 - splitting expressions','On Tue, 2014-09-09 at 12:05 -0700, Gilbert Pilz wrote:\n> I have a question with regards to splitting expressions in order to\n> conform to the pep8 line-length restriction. I have the following bit\n> of code:\n> \n> \n>             res = amodel.Assemblies(uri=common.ASSEM_URI_STR %\n>                                     pecan.request.host_url,\n>                                     name=\'Solum_CAMP_assemblies\',\n>                                     type=\'assemblies\',\n>                                     description=common.ASSEM_DESC_STR,\n>                                     assembly_links=a_links,\n>                                     parameter_definitions_uri=common.ASSEM_PARAM_STR %\n>                                     pecan.request.host_url)\n\nI\'d suggest trying:\n\n        res = amodel.Assemblies(\n            uri=common.ASSEM_URI_STR % pecan.request.host_url,\n            name=\'Solum_CAMP_assemblies\',\n            type=\'assemblies\',\n            description=common.ASSEM_DESC_STR,\n            assembly_links=a_links,\n            parameter_definitions_uri=common.ASSEM_PARAM_STR %\n            pecan.request.host_url)\n\nBy moving the first argument to a line by itself, pep8 can be satisfied\nby indenting the following lines by 4 spaces.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<00D9D113-6499-498E-88AB-6BCD0A6ED43B@oracle.com>',NULL),('<1410483566-sup-1238@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 18:29:33',-25200,'2014-09-12 01:29:33',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Zane Bitter\'s message of 2014-09-11 15:21:26 -0700:\n> On 09/09/14 19:56, Clint Byrum wrote:\n> > Excerpts from Samuel Merritt\'s message of 2014-09-09 16:12:09 -0700:\n> >> On 9/9/14, 12:03 PM, Monty Taylor wrote:\n> >>> On 09/04/2014 01:30 AM, Clint Byrum wrote:\n> >>>> Excerpts from Flavio Percoco\'s message of 2014-09-04 00:08:47 -0700:\n> >>>>> Greetings,\n> >>>>>\n> >>>>> Last Tuesday the TC held the first graduation review for Zaqar. During\n> >>>>> the meeting some concerns arose. I\'ve listed those concerns below with\n> >>>>> some comments hoping that it will help starting a discussion before the\n> >>>>> next meeting. In addition, I\'ve added some comments about the project\n> >>>>> stability at the bottom and an etherpad link pointing to a list of use\n> >>>>> cases for Zaqar.\n> >>>>>\n> >>>>\n> >>>> Hi Flavio. This was an interesting read. As somebody whose attention has\n> >>>> recently been drawn to Zaqar, I am quite interested in seeing it\n> >>>> graduate.\n> >>>>\n> >>>>> # Concerns\n> >>>>>\n> >>>>> - Concern on operational burden of requiring NoSQL deploy expertise to\n> >>>>> the mix of openstack operational skills\n> >>>>>\n> >>>>> For those of you not familiar with Zaqar, it currently supports 2 nosql\n> >>>>> drivers - MongoDB and Redis - and those are the only 2 drivers it\n> >>>>> supports for now. This will require operators willing to use Zaqar to\n> >>>>> maintain a new (?) NoSQL technology in their system. Before expressing\n> >>>>> our thoughts on this matter, let me say that:\n> >>>>>\n> >>>>>       1. By removing the SQLAlchemy driver, we basically removed the\n> >>>>> chance\n> >>>>> for operators to use an already deployed \"OpenStack-technology\"\n> >>>>>       2. Zaqar won\'t be backed by any AMQP based messaging technology for\n> >>>>> now. Here\'s[0] a summary of the research the team (mostly done by\n> >>>>> Victoria) did during Juno\n> >>>>>       3. We (OpenStack) used to require Redis for the zmq matchmaker\n> >>>>>       4. We (OpenStack) also use memcached for caching and as the oslo\n> >>>>> caching lib becomes available - or a wrapper on top of dogpile.cache -\n> >>>>> Redis may be used in place of memcached in more and more deployments.\n> >>>>>       5. Ceilometer\'s recommended storage driver is still MongoDB,\n> >>>>> although\n> >>>>> Ceilometer has now support for sqlalchemy. (Please correct me if I\'m\n> >>>>> wrong).\n> >>>>>\n> >>>>> That being said, it\'s obvious we already, to some extent, promote some\n> >>>>> NoSQL technologies. However, for the sake of the discussion, lets assume\n> >>>>> we don\'t.\n> >>>>>\n> >>>>> I truly believe, with my OpenStack (not Zaqar\'s) hat on, that we can\'t\n> >>>>> keep avoiding these technologies. NoSQL technologies have been around\n> >>>>> for years and we should be prepared - including OpenStack operators - to\n> >>>>> support these technologies. Not every tool is good for all tasks - one\n> >>>>> of the reasons we removed the sqlalchemy driver in the first place -\n> >>>>> therefore it\'s impossible to keep an homogeneous environment for all\n> >>>>> services.\n> >>>>>\n> >>>>\n> >>>> I whole heartedly agree that non traditional storage technologies that\n> >>>> are becoming mainstream are good candidates for use cases where SQL\n> >>>> based storage gets in the way. I wish there wasn\'t so much FUD\n> >>>> (warranted or not) about MongoDB, but that is the reality we live in.\n> >>>>\n> >>>>> With this, I\'m not suggesting to ignore the risks and the extra burden\n> >>>>> this adds but, instead of attempting to avoid it completely by not\n> >>>>> evolving the stack of services we provide, we should probably work on\n> >>>>> defining a reasonable subset of NoSQL services we are OK with\n> >>>>> supporting. This will help making the burden smaller and it\'ll give\n> >>>>> operators the option to choose.\n> >>>>>\n> >>>>> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> >>>>>\n> >>>>>\n> >>>>> - Concern on should we really reinvent a queue system rather than\n> >>>>> piggyback on one\n> >>>>>\n> >>>>> As mentioned in the meeting on Tuesday, Zaqar is not reinventing message\n> >>>>> brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack\n> >>>>> flavor on top. [0]\n> >>>>>\n> >>>>\n> >>>> I think Zaqar is more like SMTP and IMAP than AMQP. You\'re not really\n> >>>> trying to connect two processes in real time. You\'re trying to do fully\n> >>>> asynchronous messaging with fully randomized access to any message.\n> >>>>\n> >>>> Perhaps somebody should explore whether the approaches taken by large\n> >>>> scale IMAP providers could be applied to Zaqar.\n> >>>>\n> >>>> Anyway, I can\'t imagine writing a system to intentionally use the\n> >>>> semantics of IMAP and SMTP. I\'d be very interested in seeing actual use\n> >>>> cases for it, apologies if those have been posted before.\n> >>>\n> >>> It seems like you\'re EITHER describing something called XMPP that has at\n> >>> least one open source scalable backend called ejabberd. OR, you\'ve\n> >>> actually hit the nail on the head with bringing up SMTP and IMAP but for\n> >>> some reason that feels strange.\n> >>>\n> >>> SMTP and IMAP already implement every feature you\'ve described, as well\n> >>> as retries/failover/HA and a fully end to end secure transport (if\n> >>> installed properly) If you don\'t actually set them up to run as a public\n> >>> messaging interface but just as a cloud-local exchange, then you could\n> >>> get by with very low overhead for a massive throughput - it can very\n> >>> easily be run on a single machine for Sean\'s simplicity, and could just\n> >>> as easily be scaled out using well known techniques for public cloud\n> >>> sized deployments?\n> >>>\n> >>> So why not use existing daemons that do this? You could still use the\n> >>> REST API you\'ve got, but instead of writing it to a mongo backend and\n> >>> trying to implement all of the things that already exist in SMTP/IMAP -\n> >>> you could just have them front to it. You could even bypass normal\n> >>> delivery mechanisms and do neat things with local injection.\n> >>>\n> >>> I don\'t care about the NoSQL question on its own. Mongo is fine. Redis\n> >>> is fine. I don\'t think either has any features for this use case that\n> >>> make a licks worth of difference compared to MySQL or Postgres, but I\n> >>> also don\'t think they are a PROBLEM in an of themselves.\n> >>>\n> >>> The main thing I care about here is every description I\'ve heard of what\n> >>> zaqar wants to do (which does seem to be getting clearer through this\n> >>> thread) is still well implemented somewhere as an existing scalable\n> >>> service. Is zaqar actually Rabbit with a REST interface? Is it ejabberd\n> >>> with a rest interface? Or is it IMAP/SMTP with a REST interface. You\'ll\n> >>> note that probably nobody would think a single server that wanted to be\n> >>> both Rabbit AND IMAP/SMTP is a good idea ... at least this is one of the\n> >>> reasons why we all think Microsoft Exchange is a pile of garbage, no?\n> >>>\n> >>> I also worry about the fact that one description of zaqar was used to\n> >>> communicate a need for divergent requirements (it needs to be a\n> >>> high-volume fast message broker/queue - which, btw, sounds more like\n> >>> Rabbit/oslo.messaging and less like what Clint describes above) ... and\n> >>> that\'s why it wants to use falcon and not pecan and why it wants to use\n> >>> mongo and not SQL. And then what we\'re doing it reimplementing something\n> >>> like rabbit except in python (again, given as the justification for\n> >>> deviating from how other bits of OpenStack work)\n> >>>\n> >>> BUT - if that\'s not actually what zaqar is - if it isn\'t a rabbit\n> >>> replacement and doesn\'t need to do massive high volume sub-second\n> >>> queuing because what it\'s actually modeling is a message subscription\n> >>> service that\'s closer to email than to anything else, then there is\n> >>> nothing about the components that are happily used in the rest of\n> >>> OpenStack that should be precluded from being used. A REST api written\n> >>> in pecan should be fine ... as should an SQL backend, because 99% of all\n> >>> operations are going to be primary key lookups where even a moderately\n> >>> tuned database should be absolutely fine at keeping up.\n> >>>\n> >>> So which is it? Because it sounds like to me it\'s a thing that actually\n> >>> does NOT need to diverge in technology in any way, but that I\'ve been\n> >>> told that it needs to diverge because it\'s delivering a different set of\n> >>> features - and I\'m pretty sure if it _is_ the thing that needs to\n> >>> diverge in technology because of its feature set, then it\'s a thing I\n> >>> don\'t think we should be implementing in python in OpenStack because it\n> >>> already exists and it\'s called AMQP.\n> >>\n> >> Whether Zaqar is more like AMQP or more like email is a really strange\n> >> metric to use for considering its inclusion.\n> >>\n> >> Let me put on my web application developer\'s hat. Whenever I\'ve worked\n> >> on a web app, I\'ve invariably wound up needing HTTP servers, background\n> >> workers, and some sort of queue to connect the two.\n> >>\n> >> I\'ve done the thing where I\'ve stored queue entries in the app\'s\n> >> database and had the workers poll for jobs; the load adds up\n> >> surprisingly fast, and it\'s got some bad positive-feedback failure\n> >> modes. However, it is nice and durable, so my app doesn\'t lose messages.\n> >>\n> >> I\'ve done the thing where I\'ve thrown together a VM and stuck Redis or\n> >> rabbitmq or beanstalkd on it. That gets me nice, fast queues, but no\n> >> semblance of reliability. If that one VM dies, all my queued messages\n> >> are lost.\n> >>\n> >> Then there\'s Zaqar, which is this nice HTTP API that I can use for my\n> >> application\'s queues. I go and make a couple of POST requests and now\n> >> I\'ve got some queues for my application to use. My app servers POST\n> >> messages to their queues, and my background workers sit and make GET\n> >> requests for messages to process. I can have the whole thing up and\n> >> running in a few hours. Better yet, I barely have to monitor the thing.\n> >> I can poll for queue stats every few minutes and alert if the queue gets\n> >> too full, but that\'s all I\'ve got to do. I don\'t have to worry about my\n> >> queue VM going into swap, or my queue VM\'s NIC getting saturated, or\n> >> kernel panics, or automatically promoting rabbitmq slaves to masters, or\n> >> waking up at 3 AM to fix my app when I lose messages during a rabbitmq\n> >> promotion, or any of that stuff. Using Zaqar means I can just worry\n> >> about my application and leave all that other garbage to my cloud provider.\n> >\n> > What you just described is the queue pattern I spoke of.\n> >\n> > It does not require random access by message ID in any way shape or\n> > form. It is also well served by AMQP. I wonder if people are still\n> > confused by Zaqar\'s API and architecture because this would be fine for\n> > an architecture if what you describe above were the requirements:\n> >\n> > https://www.dropbox.com/s/yonloa9ytlf8fdh/ZaqarQueueOnly.png?dl=0\n> >\n> > Just stick a REST shim in front of AMQP that enforces tenant permissions\n> > and maps logical \"zaqar queues\" to whatever the backend serving queue is.\n> >\n> > So why would we need a NoSQL database for the data itself if all we are\n> > doing is shoving messages in and taking them out the other end?\n> \n> This was one of the ideas suggested by the TC at the last graduation \n> review (or was it the incubation review? I forget). The Zaqar team \n> looked into it and this was the outcome (for now):\n> \n> http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> \n\nI\'ve just re-read that, and it still feels the same as the first time:\nthis feels like justification for the current body of work, instead of\nanalysis for the necessity for the current feature set or feasibility of\nscaling it.\n\n\"The third motivation is something that Marconi brings to traditional\nbrokers. With Marconi, it\'s possible to add per-queue sharding\ncapabilities to traditional brokers. By using Marconi\'s pools and flavors\nit is possible to create separate clusters of storage that will be used\ncooperatively based on the pool settings.\"\n\nThis statement does not seem use-case driven. It appears to be supporting\nthe current implementation which, I assume, was done to work around\nthe problem of databases not being able to scale like a queue. Users\nwill just want to be able to reason about the messaging guarantees like\n\"delivered at least once\" and durability.\n\nMeanwhile there are quite a few message brokers that can scale in the\nsame way, that Zaqar wouldn\'t even have to model.\n\n\"The API was designed to be browsable but without sacrificing the\n\"messaging\" feel of every queuing system. New things are being added to\nmake it more message based without sacrificing browsability.\"\n\nThis browsability is, at its core, the thing that concerns me and probably\nothers who are expressing their opinions. It\'s not that we don\'t think\nit can be done, but we don\'t think it should be done when there are so\nmany use cases solved by a regular old message queue.\n\nThe fact that sessions are a part of AMQP makes it complicated to\nemulate over HTTP when messages need to be ACK\'d. However, it seems\npretty straight forward to me to have session ID as part of the API, and\nto have an RPC bus like we do now for our usual OpenStack services that\nhas a topic per session. Then have the API frontends speaking over that\nbus, pushing ACK\'s down that topic to a backend engine that maintains\nthe session. This is double-messaging for everything, which I wish I\ncould think of a better solution for, but it is still lighter weight\nthan putting all of the messages into a database.\n\nFinally, two of the main sections in that article state \"Store and\nForward\" and \"Message access by ID\" are important to Zaqar. Those two\nconcepts are SMTP and IMAP in a nutshell. It still kind of boggles\nmy mind that these weren\'t considered as backends, given that their\nprotocols even match reasonably well to the parts of Zaqar\'s API that\npertain to messages. They may not be sexy, but I\'d be quite surprised\nif there wasn\'t an SMTP+IMAP combination out there that can scale at\nleast as cost effectively as Redis.\n\nAnyway, I stand by my original feeling that Zaqar needs to do one\nthing well, and currently it looks to be attempting to do one thing\nwell (inbox style messaging) and another thing (simple message queue)\nas well as can be done while working inside the same constraints as\ninbox style messaging.\n\n\n','<54122066.9070105@redhat.com>',NULL),('<1410503207314.58821@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-12 06:26:48',0,'2014-09-12 06:26:48',NULL,'[Openstack] nova not able to find networks','Hi Srinivas,\n\n\nCan you please check if nova.conf  has proper neutron details.\n\n\nnetwork_api_class = nova.network.neutronv2.api.API\n\n[neutron]\nservice_metadata_proxy = True\nurl = http://1.x.x.x:9696\nregion_name = RegionOne\nadmin_tenant_name = service\nauth_strategy = keystone\nadmin_auth_url = http://1.x.x.x:35357/v2.0\nadmin_password = Openstack1\nadmin_username = neutron\n\n\nIf yes, then try restarting the nova services and check.\n\n\nRegards,\nSushma Korati\nsushma_korati at persistent.co.in |\nPersistent Systems Ltd. |  Partners in Innovation | www.persistentsys.com\nP Please consider your environmental responsibility: Before printing this e-mail or any other document, ask yourself whether you need a hard copy.\n\n\n________________________________\nFrom: Srinivasreddy R <srinivasreddy4390 at gmail.com>\nSent: Friday, September 12, 2014 11:33 AM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] nova not able to find networks\n\nhi,\n1. i have created a router\nneutron router-create demo-router\n\n2. attached the router to demo tenant demo-subnet\nneutron router-interface-add demo-router demo-subnet\n\n3. attached the router to external network\n neutron router-gateway-set demo-router ext-net\n\n4.\nroot at user-ThinkCentre-M73:/home/user# neutron net-list\n+--------------------------------------+----------+-----------------------------------------------------+\n| id                                   | name     | subnets                                             |\n+--------------------------------------+----------+-----------------------------------------------------+\n| d81390bf-281c-40b6-a611-6a193da88963 | ext-net  | fc4b6684-b0f9-4983-94ed-7d075880e921 203.0.113.0/24<http://203.0.113.0/24> |\n| e1bd057f-59c3-426e-9c2e-f3e2953a392e | demo-net | e6bea0e8-a27d-45f1-b95e-461b611f9a42 192.168.1.0/24<http://192.168.1.0/24> |\n+--------------------------------------+----------+-----------------------------------------------------+\n\n5.\nroot at user-ThinkCentre-M73:/home/user# nova net-list\n+----+-------+------+\n| ID | Label | CIDR |\n+----+-------+------+\n+----+-------+------+\n\n\nwe are able to see  neutron ne-list but not able to see nova net-list .\nwhile we have created successfully net list for nova as well as neutron .\nneutron can able to see both ext-net and demo-net .\nbut nova not able to see networks .\n\ni have checked with the admin, demo user .\n\nplease help me how to proceed further .\n\nwe are following  3 node setup installation .\nhttp://docs.openstack.org/icehouse/install-guide/install/apt/content/\n\nthanks,\nsrinivas.\n\n\n\n\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140912/47f2c121/attachment.html>\n\n','<CAJP4VWht6OMeiNK8jCDa7ovnw=EUqUNh4pJRTda1_d7s6E9YqQ@mail.gmail.com>',NULL),('<1410517662.11963.49.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 11:27:42',3600,'2014-09-12 10:27:42',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n Comments on the concerns arose during the TC meeting]','On Wed, 2014-09-10 at 14:51 +0200, Thierry Carrez wrote:\n> Flavio Percoco wrote:\n> > [...]\n> > Based on the feedback from the meeting[3], the current main concern is:\n> > \n> > - Do we need a messaging service with a feature-set akin to SQS+SNS?\n> > [...]\n> \n> I think we do need, as Samuel puts it, \"some sort of durable\n> message-broker/queue-server thing\". It\'s a basic application building\n> block. Some claim it\'s THE basic application building block, more useful\n> than database provisioning. It\'s definitely a layer above pure IaaS, so\n> if we end up splitting OpenStack into layers this clearly won\'t be in\n> the inner one. But I think \"IaaS+\" basic application building blocks\n> belong in OpenStack one way or another. That\'s the reason I supported\n> Designate (\"everyone needs DNS\") and Trove (\"everyone needs DBs\").\n> \n> With that said, I think yesterday there was a concern that Zaqar might\n> not fill the \"some sort of durable message-broker/queue-server thing\"\n> role well. The argument goes something like: if it was a queue-server\n> then it should actually be built on top of Rabbit; if it was a\n> message-broker it should be built on top of postfix/dovecot; the current\n> architecture is only justified because it\'s something in between, so\n> it\'s broken.\n> \n> I guess I don\'t mind that much zaqar being \"something in between\":\n> unless I misunderstood, exposing extra primitives doesn\'t prevent the\n> \"queue-server\" use case from being filled. Even considering the\n> message-broker case, I\'m also not convinced building it on top of\n> postfix/dovecot would be a net win compared to building it on top of\n> Redis, to be honest.\n\nAFAICT, this part of the debate boils down to the following argument:\n\n  If Zaqar implemented messaging-as-a-service with only queuing \n  semantics (and no random access semantics), it\'s design would \n  naturally be dramatically different and \"simply\" implement a \n  multi-tenant REST API in front of AMQP queues like this:\n\n    https://www.dropbox.com/s/yonloa9ytlf8fdh/ZaqarQueueOnly.png?dl=0\n\n  and that this architecture would allow for dramatically improved \n  throughput for end-users while not making the cost of providing the \n  service prohibitive to operators.\n\nYou can\'t dismiss that argument out-of-hand, but I wonder (a) whether\nthe claimed performance improvement is going to make a dramatic\ndifference to the SQS-like use case and (b) whether backing this thing\nwith an RDBMS and multiple highly available, durable AMQP broker\nclusters is going to be too much of a burden on operators for whatever\nperformance improvements it does gain.\n\nBut the troubling part of this debate is where we repeatedly batter the\nZaqar team with hypotheses like these and appear to only barely\nentertain their carefully considered justification for their design\ndecisions like:\n\n  https://wiki.openstack.org/wiki/Frequently_asked_questions_%28Zaqar%29#Is_Zaqar_a_provisioning_service_or_a_data_API.3F\n  https://wiki.openstack.org/wiki/Frequently_asked_questions_%28Zaqar%29#What_messaging_patterns_does_Zaqar_support.3F\n\nI would like to see an SQS-like API provided by OpenStack, I accept the\nreasons for Zaqar\'s design decisions to date, I respect that those\ndecisions were made carefully by highly competent members of our\ncommunity and I expect Zaqar to evolve (like all projects) in the years\nahead based on more real-world feedback, new hypotheses or ideas, and\nlessons learned from trying things out.\n\nMark.\n\n\n\n','<54104940.4040108@openstack.org>',NULL),('<1410518133.11963.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 11:35:33',3600,'2014-09-12 10:35:33',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n the TC meeting','On Wed, 2014-09-10 at 12:46 -0700, Monty Taylor wrote:\n> On 09/09/2014 07:04 PM, Samuel Merritt wrote:\n> > On 9/9/14, 4:47 PM, Devananda van der Veen wrote:\n\n> >> The questions now before us are:\n> >> - should OpenStack include, in the integrated release, a\n> >> messaging-as-a-service component?\n> >\n> > I certainly think so. I\'ve worked on a few reasonable-scale web\n> > applications, and they all followed the same pattern: HTTP app servers\n> > serving requests quickly, background workers for long-running tasks, and\n> > some sort of durable message-broker/queue-server thing for conveying\n> > work from the first to the second.\n> >\n> > A quick straw poll of my nearby coworkers shows that every non-trivial\n> > web application that they\'ve worked on in the last decade follows the\n> > same pattern.\n> >\n> > While not *every* application needs such a thing, web apps are quite\n> > common these days, and Zaqar satisfies one of their big requirements.\n> > Not only that, it does so in a way that requires much less babysitting\n> > than run-your-own-broker does.\n> \n> Right. But here\'s the thing.\n> \n> What you just described is what we all thought zaqar was aiming to be in \n> the beginning. We did not think it was a GOOD implementation of that, so \n> while we agreed that it would be useful to have one of those, we were \n> not crazy about the implementation.\n\nThose generalizations are uncomfortably sweeping.\n\nWhat Samuel just described is one of the messaging patterns that Zaqar\nimplements and some (members of the TC?) believed that this messaging\npattern was the only pattern that Zaqar aimed to implement.\n\nSome (members of the TC?) formed strong, negative opinions about how\nthis messaging pattern was implemented, but some/all of those same\npeople agreed a messaging API implementing those semantics would be a\nuseful thing to have.\n\nMark.\n\n\n\n','<5410AA8E.3060200@inaugust.com>',NULL),('<1410540798-sup-8920@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 10:13:01',-25200,'2014-09-12 17:13:01',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Thierry Carrez\'s message of 2014-09-12 02:16:42 -0700:\n> Clint Byrum wrote:\n> > Excerpts from Flavio Percoco\'s message of 2014-09-11 04:14:30 -0700:\n> >> Is Zaqar being optimized as a *queuing* service? I\'d say no. Our goal is\n> >> to optimize Zaqar for delivering messages and supporting different\n> >> messaging patterns.\n> > \n> > Awesome! Just please don\'t expect people to get excited about it for\n> > the lighter weight queueing workloads that you\'ve claimed as use cases.\n> > \n> > I totally see Horizon using it to keep events for users. I see Heat\n> > using it for stack events as well. I would bet that Trove would benefit\n> > from being able to communicate messages to users.\n> > \n> > But I think in between Zaqar and the backends will likely be a lighter\n> > weight queue-only service that the users can just subscribe to when they\n> > don\'t want an inbox. And I think that lighter weight queue service is\n> > far more important for OpenStack than the full blown random access\n> > inbox.\n> > \n> > I think the reason such a thing has not appeared is because we were all\n> > sort of running into \"but Zaqar is already incubated\". Now that we\'ve\n> > fleshed out the difference, I think those of us that need a lightweight\n> > multi-tenant queue service should add it to OpenStack.  Separately. I hope\n> > that doesn\'t offend you and the rest of the excellent Zaqar developers. It\n> > is just a different thing.\n> > \n> >> Should we remove all the semantics that allow people to use Zaqar as a\n> >> queue service? I don\'t think so either. Again, the semantics are there\n> >> because Zaqar is using them to do its job. Whether other folks may/may\n> >> not use Zaqar as a queue service is out of our control.\n> >>\n> >> This doesn\'t mean the project is broken.\n> > \n> > No, definitely not broken. It just isn\'t actually necessary for many of\n> > the stated use cases.\n> \n> Clint,\n> \n> If I read you correctly, you\'re basically saying the Zaqar is overkill\n> for a lot of people who only want a multi-tenant queue service. It\'s\n> doing A+B. Why does that prevent people who only need A from using it ?\n> \n> Is it that it\'s actually not doing A well, from a user perspective ?\n> Like the performance sucks, or it\'s missing a key primitive ?\n> \n> Is it that it\'s unnecessarily complex to deploy, from a deployer\n> perspective, and that something only doing A would be simpler, while\n> covering most of the use cases?\n> \n> Is it something else ?\n> \n> I want to make sure I understand your objection. In the \"user\n> perspective\" it might make sense to pursue both options as separate\n> projects. In the \"deployer perspective\" case, having a project doing A+B\n> and a project doing A doesn\'t solve anything. So this affects the\n> decision we have to take next Tuesday...\n\nI believe that Zaqar does two things, inbox semantics, and queue\nsemantics. I believe the queueing is a side-effect of needing some kind\nof queue to enable users to store and subscribe to messages in the\ninbox.\n\nWhat I\'d rather see is an API for queueing, and an API for inboxes\nwhich integrates well with the queueing API. For instance, if a user\nsays \"give me an inbox\" I think Zaqar should return a queue handle for\nsending into the inbox the same way Nova gives you a Neutron port if\nyou don\'t give it one. You might also ask for a queue to receive push\nmessages from the inbox. Point being, the queues are not the inbox,\nand the inbox is not the queues.\n\nHowever, if I just want a queue, just give me a queue. Don\'t store my\nmessages in a randomly addressable space, and don\'t saddle the deployer\nwith the burden of such storage. Put the queue API in front of a scalable\nmessage queue and give me a nice simple HTTP API. Users would likely be\nthrilled. Heat, Nova, Ceilometer, probably Trove and Sahara, could all\nmake use of just this. Only Horizon seems to need a place to keep the\nmessages around while users inspect them.\n\nWhether that is two projects, or one, separation between the two API\'s,\nand thus two very different types of backends, is something I think\nwill lead to more deployers wanting to deploy both, so that they can\nbill usage appropriately and so that their users can choose wisely.\n\n\n','<5412B9FA.4070806@openstack.org>',NULL),('<1410542058-sup-4143@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 10:29:58',-25200,'2014-09-12 17:29:58',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Mark McLoughlin\'s message of 2014-09-12 03:27:42 -0700:\n> On Wed, 2014-09-10 at 14:51 +0200, Thierry Carrez wrote:\n> > Flavio Percoco wrote:\n> > > [...]\n> > > Based on the feedback from the meeting[3], the current main concern is:\n> > > \n> > > - Do we need a messaging service with a feature-set akin to SQS+SNS?\n> > > [...]\n> > \n> > I think we do need, as Samuel puts it, \"some sort of durable\n> > message-broker/queue-server thing\". It\'s a basic application building\n> > block. Some claim it\'s THE basic application building block, more useful\n> > than database provisioning. It\'s definitely a layer above pure IaaS, so\n> > if we end up splitting OpenStack into layers this clearly won\'t be in\n> > the inner one. But I think \"IaaS+\" basic application building blocks\n> > belong in OpenStack one way or another. That\'s the reason I supported\n> > Designate (\"everyone needs DNS\") and Trove (\"everyone needs DBs\").\n> > \n> > With that said, I think yesterday there was a concern that Zaqar might\n> > not fill the \"some sort of durable message-broker/queue-server thing\"\n> > role well. The argument goes something like: if it was a queue-server\n> > then it should actually be built on top of Rabbit; if it was a\n> > message-broker it should be built on top of postfix/dovecot; the current\n> > architecture is only justified because it\'s something in between, so\n> > it\'s broken.\n> > \n> > I guess I don\'t mind that much zaqar being \"something in between\":\n> > unless I misunderstood, exposing extra primitives doesn\'t prevent the\n> > \"queue-server\" use case from being filled. Even considering the\n> > message-broker case, I\'m also not convinced building it on top of\n> > postfix/dovecot would be a net win compared to building it on top of\n> > Redis, to be honest.\n> \n> AFAICT, this part of the debate boils down to the following argument:\n> \n>   If Zaqar implemented messaging-as-a-service with only queuing \n>   semantics (and no random access semantics), it\'s design would \n>   naturally be dramatically different and \"simply\" implement a \n>   multi-tenant REST API in front of AMQP queues like this:\n> \n>     https://www.dropbox.com/s/yonloa9ytlf8fdh/ZaqarQueueOnly.png?dl=0\n> \n>   and that this architecture would allow for dramatically improved \n>   throughput for end-users while not making the cost of providing the \n>   service prohibitive to operators.\n> \n> You can\'t dismiss that argument out-of-hand, but I wonder (a) whether\n> the claimed performance improvement is going to make a dramatic\n> difference to the SQS-like use case and (b) whether backing this thing\n> with an RDBMS and multiple highly available, durable AMQP broker\n> clusters is going to be too much of a burden on operators for whatever\n> performance improvements it does gain.\n\nHaving had experience taking queue-only data out of RDBMS\'s and even SMTP\nsolutions, and putting them into queues, I can say that it was generally\nquite a bit more reliable and cheaper to maintain.\n\nHowever, as I\'ve been thinking about this more, I am concerned about the\ncomplexity of trying to use a stateless protocol like HTTP for reliable\ndelivery, given that these queues all use a session model that relies\non connection persistence. That may very well invalidate my hypothesis.\n\n> \n> But the troubling part of this debate is where we repeatedly batter the\n> Zaqar team with hypotheses like these and appear to only barely\n> entertain their carefully considered justification for their design\n> decisions like:\n> \n>   https://wiki.openstack.org/wiki/Frequently_asked_questions_%28Zaqar%29#Is_Zaqar_a_provisioning_service_or_a_data_API.3F\n>   https://wiki.openstack.org/wiki/Frequently_asked_questions_%28Zaqar%29#What_messaging_patterns_does_Zaqar_support.3F\n> \n> I would like to see an SQS-like API provided by OpenStack, I accept the\n> reasons for Zaqar\'s design decisions to date, I respect that those\n> decisions were made carefully by highly competent members of our\n> community and I expect Zaqar to evolve (like all projects) in the years\n> ahead based on more real-world feedback, new hypotheses or ideas, and\n> lessons learned from trying things out.\n\nI have read those and I truly believe that the Zaqar team, who I believe\nare already a valuable part of the OpenStack family, are doing good work.\nSeriously, I believe it is valuable as is and I trust them to do what\nthey have stated they will do.\n\nLet me explain my position again. Heat is in dire need of a way to\ncommunicate with instances that is efficient. It has no need for a full\nmessaging stack.. just a way for users to have things pushed from Heat\nto their instances efficiently.\n\nSo, to reiterate why I keep going on about this: If a messaging service\nis to become an integrated part of OpenStack\'s release, we should think\ncarefully about the ramifications for operators _and_ users of not\nhaving a light weight queue-only option, when that seems to fit _most_\nof the use cases.\n\n\n','<1410517662.11963.49.camel@sorcha>',NULL),('<1410542636.3245.23.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 12:23:56',-18000,'2014-09-12 17:23:56',NULL,'[openstack-dev] [solum] pep8 - splitting expressions','On Thu, 2014-09-11 at 18:35 -0500, Ed Leafe wrote:\n> On Sep 11, 2014, at 5:05 PM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:\n> \n> > I\'d suggest trying:\n> > \n> >        res = amodel.Assemblies(\n> >            uri=common.ASSEM_URI_STR % pecan.request.host_url,\n> >            name=\'Solum_CAMP_assemblies\',\n> >            type=\'assemblies\',\n> >            description=common.ASSEM_DESC_STR,\n> >            assembly_links=a_links,\n> >            parameter_definitions_uri=common.ASSEM_PARAM_STR %\n> >            pecan.request.host_url)\n> > \n> > By moving the first argument to a line by itself, pep8 can be satisfied\n> > by indenting the following lines by 4 spaces.\n> \n> When not using visual indentation, the standard is to indent two\n> levels (i.e., 8 spaces), to distinguish it from typical blocks. But\n> yes, I much prefer this than creating temporary names to accommodate\n> the visual indentation style.\n\nUsing an 8 space indent here would result in an E126 pep8 error, which\nis why I use 4 spaces for this case.  Of course, I don\'t know if Solum\nenforces E126.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<BED645C8-BB42-42EC-AF2B-4BFE481DFD33@leafe.com>',NULL),('<1410543276-sup-5912@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 10:43:10',-25200,'2014-09-12 17:43:10',NULL,'[openstack-dev] [Zaqar] Comments on the concerns arose during\n	the TC meeting','Excerpts from Flavio Percoco\'s message of 2014-09-12 00:22:35 -0700:\n> On 09/12/2014 03:29 AM, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-09-11 15:21:26 -0700:\n> >> On 09/09/14 19:56, Clint Byrum wrote:\n> >>> Excerpts from Samuel Merritt\'s message of 2014-09-09 16:12:09 -0700:\n> >>>> On 9/9/14, 12:03 PM, Monty Taylor wrote:\n> >>>>> On 09/04/2014 01:30 AM, Clint Byrum wrote:\n> >>>>>> Excerpts from Flavio Percoco\'s message of 2014-09-04 00:08:47 -0700:\n> >>>>>>> Greetings,\n> >>>>>>>\n> >>>>>>> Last Tuesday the TC held the first graduation review for Zaqar. During\n> >>>>>>> the meeting some concerns arose. I\'ve listed those concerns below with\n> >>>>>>> some comments hoping that it will help starting a discussion before the\n> >>>>>>> next meeting. In addition, I\'ve added some comments about the project\n> >>>>>>> stability at the bottom and an etherpad link pointing to a list of use\n> >>>>>>> cases for Zaqar.\n> >>>>>>>\n> >>>>>>\n> >>>>>> Hi Flavio. This was an interesting read. As somebody whose attention has\n> >>>>>> recently been drawn to Zaqar, I am quite interested in seeing it\n> >>>>>> graduate.\n> >>>>>>\n> >>>>>>> # Concerns\n> >>>>>>>\n> >>>>>>> - Concern on operational burden of requiring NoSQL deploy expertise to\n> >>>>>>> the mix of openstack operational skills\n> >>>>>>>\n> >>>>>>> For those of you not familiar with Zaqar, it currently supports 2 nosql\n> >>>>>>> drivers - MongoDB and Redis - and those are the only 2 drivers it\n> >>>>>>> supports for now. This will require operators willing to use Zaqar to\n> >>>>>>> maintain a new (?) NoSQL technology in their system. Before expressing\n> >>>>>>> our thoughts on this matter, let me say that:\n> >>>>>>>\n> >>>>>>>       1. By removing the SQLAlchemy driver, we basically removed the\n> >>>>>>> chance\n> >>>>>>> for operators to use an already deployed \"OpenStack-technology\"\n> >>>>>>>       2. Zaqar won\'t be backed by any AMQP based messaging technology for\n> >>>>>>> now. Here\'s[0] a summary of the research the team (mostly done by\n> >>>>>>> Victoria) did during Juno\n> >>>>>>>       3. We (OpenStack) used to require Redis for the zmq matchmaker\n> >>>>>>>       4. We (OpenStack) also use memcached for caching and as the oslo\n> >>>>>>> caching lib becomes available - or a wrapper on top of dogpile.cache -\n> >>>>>>> Redis may be used in place of memcached in more and more deployments.\n> >>>>>>>       5. Ceilometer\'s recommended storage driver is still MongoDB,\n> >>>>>>> although\n> >>>>>>> Ceilometer has now support for sqlalchemy. (Please correct me if I\'m\n> >>>>>>> wrong).\n> >>>>>>>\n> >>>>>>> That being said, it\'s obvious we already, to some extent, promote some\n> >>>>>>> NoSQL technologies. However, for the sake of the discussion, lets assume\n> >>>>>>> we don\'t.\n> >>>>>>>\n> >>>>>>> I truly believe, with my OpenStack (not Zaqar\'s) hat on, that we can\'t\n> >>>>>>> keep avoiding these technologies. NoSQL technologies have been around\n> >>>>>>> for years and we should be prepared - including OpenStack operators - to\n> >>>>>>> support these technologies. Not every tool is good for all tasks - one\n> >>>>>>> of the reasons we removed the sqlalchemy driver in the first place -\n> >>>>>>> therefore it\'s impossible to keep an homogeneous environment for all\n> >>>>>>> services.\n> >>>>>>>\n> >>>>>>\n> >>>>>> I whole heartedly agree that non traditional storage technologies that\n> >>>>>> are becoming mainstream are good candidates for use cases where SQL\n> >>>>>> based storage gets in the way. I wish there wasn\'t so much FUD\n> >>>>>> (warranted or not) about MongoDB, but that is the reality we live in.\n> >>>>>>\n> >>>>>>> With this, I\'m not suggesting to ignore the risks and the extra burden\n> >>>>>>> this adds but, instead of attempting to avoid it completely by not\n> >>>>>>> evolving the stack of services we provide, we should probably work on\n> >>>>>>> defining a reasonable subset of NoSQL services we are OK with\n> >>>>>>> supporting. This will help making the burden smaller and it\'ll give\n> >>>>>>> operators the option to choose.\n> >>>>>>>\n> >>>>>>> [0] http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> >>>>>>>\n> >>>>>>>\n> >>>>>>> - Concern on should we really reinvent a queue system rather than\n> >>>>>>> piggyback on one\n> >>>>>>>\n> >>>>>>> As mentioned in the meeting on Tuesday, Zaqar is not reinventing message\n> >>>>>>> brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack\n> >>>>>>> flavor on top. [0]\n> >>>>>>>\n> >>>>>>\n> >>>>>> I think Zaqar is more like SMTP and IMAP than AMQP. You\'re not really\n> >>>>>> trying to connect two processes in real time. You\'re trying to do fully\n> >>>>>> asynchronous messaging with fully randomized access to any message.\n> >>>>>>\n> >>>>>> Perhaps somebody should explore whether the approaches taken by large\n> >>>>>> scale IMAP providers could be applied to Zaqar.\n> >>>>>>\n> >>>>>> Anyway, I can\'t imagine writing a system to intentionally use the\n> >>>>>> semantics of IMAP and SMTP. I\'d be very interested in seeing actual use\n> >>>>>> cases for it, apologies if those have been posted before.\n> >>>>>\n> >>>>> It seems like you\'re EITHER describing something called XMPP that has at\n> >>>>> least one open source scalable backend called ejabberd. OR, you\'ve\n> >>>>> actually hit the nail on the head with bringing up SMTP and IMAP but for\n> >>>>> some reason that feels strange.\n> >>>>>\n> >>>>> SMTP and IMAP already implement every feature you\'ve described, as well\n> >>>>> as retries/failover/HA and a fully end to end secure transport (if\n> >>>>> installed properly) If you don\'t actually set them up to run as a public\n> >>>>> messaging interface but just as a cloud-local exchange, then you could\n> >>>>> get by with very low overhead for a massive throughput - it can very\n> >>>>> easily be run on a single machine for Sean\'s simplicity, and could just\n> >>>>> as easily be scaled out using well known techniques for public cloud\n> >>>>> sized deployments?\n> >>>>>\n> >>>>> So why not use existing daemons that do this? You could still use the\n> >>>>> REST API you\'ve got, but instead of writing it to a mongo backend and\n> >>>>> trying to implement all of the things that already exist in SMTP/IMAP -\n> >>>>> you could just have them front to it. You could even bypass normal\n> >>>>> delivery mechanisms and do neat things with local injection.\n> >>>>>\n> >>>>> I don\'t care about the NoSQL question on its own. Mongo is fine. Redis\n> >>>>> is fine. I don\'t think either has any features for this use case that\n> >>>>> make a licks worth of difference compared to MySQL or Postgres, but I\n> >>>>> also don\'t think they are a PROBLEM in an of themselves.\n> >>>>>\n> >>>>> The main thing I care about here is every description I\'ve heard of what\n> >>>>> zaqar wants to do (which does seem to be getting clearer through this\n> >>>>> thread) is still well implemented somewhere as an existing scalable\n> >>>>> service. Is zaqar actually Rabbit with a REST interface? Is it ejabberd\n> >>>>> with a rest interface? Or is it IMAP/SMTP with a REST interface. You\'ll\n> >>>>> note that probably nobody would think a single server that wanted to be\n> >>>>> both Rabbit AND IMAP/SMTP is a good idea ... at least this is one of the\n> >>>>> reasons why we all think Microsoft Exchange is a pile of garbage, no?\n> >>>>>\n> >>>>> I also worry about the fact that one description of zaqar was used to\n> >>>>> communicate a need for divergent requirements (it needs to be a\n> >>>>> high-volume fast message broker/queue - which, btw, sounds more like\n> >>>>> Rabbit/oslo.messaging and less like what Clint describes above) ... and\n> >>>>> that\'s why it wants to use falcon and not pecan and why it wants to use\n> >>>>> mongo and not SQL. And then what we\'re doing it reimplementing something\n> >>>>> like rabbit except in python (again, given as the justification for\n> >>>>> deviating from how other bits of OpenStack work)\n> >>>>>\n> >>>>> BUT - if that\'s not actually what zaqar is - if it isn\'t a rabbit\n> >>>>> replacement and doesn\'t need to do massive high volume sub-second\n> >>>>> queuing because what it\'s actually modeling is a message subscription\n> >>>>> service that\'s closer to email than to anything else, then there is\n> >>>>> nothing about the components that are happily used in the rest of\n> >>>>> OpenStack that should be precluded from being used. A REST api written\n> >>>>> in pecan should be fine ... as should an SQL backend, because 99% of all\n> >>>>> operations are going to be primary key lookups where even a moderately\n> >>>>> tuned database should be absolutely fine at keeping up.\n> >>>>>\n> >>>>> So which is it? Because it sounds like to me it\'s a thing that actually\n> >>>>> does NOT need to diverge in technology in any way, but that I\'ve been\n> >>>>> told that it needs to diverge because it\'s delivering a different set of\n> >>>>> features - and I\'m pretty sure if it _is_ the thing that needs to\n> >>>>> diverge in technology because of its feature set, then it\'s a thing I\n> >>>>> don\'t think we should be implementing in python in OpenStack because it\n> >>>>> already exists and it\'s called AMQP.\n> >>>>\n> >>>> Whether Zaqar is more like AMQP or more like email is a really strange\n> >>>> metric to use for considering its inclusion.\n> >>>>\n> >>>> Let me put on my web application developer\'s hat. Whenever I\'ve worked\n> >>>> on a web app, I\'ve invariably wound up needing HTTP servers, background\n> >>>> workers, and some sort of queue to connect the two.\n> >>>>\n> >>>> I\'ve done the thing where I\'ve stored queue entries in the app\'s\n> >>>> database and had the workers poll for jobs; the load adds up\n> >>>> surprisingly fast, and it\'s got some bad positive-feedback failure\n> >>>> modes. However, it is nice and durable, so my app doesn\'t lose messages.\n> >>>>\n> >>>> I\'ve done the thing where I\'ve thrown together a VM and stuck Redis or\n> >>>> rabbitmq or beanstalkd on it. That gets me nice, fast queues, but no\n> >>>> semblance of reliability. If that one VM dies, all my queued messages\n> >>>> are lost.\n> >>>>\n> >>>> Then there\'s Zaqar, which is this nice HTTP API that I can use for my\n> >>>> application\'s queues. I go and make a couple of POST requests and now\n> >>>> I\'ve got some queues for my application to use. My app servers POST\n> >>>> messages to their queues, and my background workers sit and make GET\n> >>>> requests for messages to process. I can have the whole thing up and\n> >>>> running in a few hours. Better yet, I barely have to monitor the thing.\n> >>>> I can poll for queue stats every few minutes and alert if the queue gets\n> >>>> too full, but that\'s all I\'ve got to do. I don\'t have to worry about my\n> >>>> queue VM going into swap, or my queue VM\'s NIC getting saturated, or\n> >>>> kernel panics, or automatically promoting rabbitmq slaves to masters, or\n> >>>> waking up at 3 AM to fix my app when I lose messages during a rabbitmq\n> >>>> promotion, or any of that stuff. Using Zaqar means I can just worry\n> >>>> about my application and leave all that other garbage to my cloud provider.\n> >>>\n> >>> What you just described is the queue pattern I spoke of.\n> >>>\n> >>> It does not require random access by message ID in any way shape or\n> >>> form. It is also well served by AMQP. I wonder if people are still\n> >>> confused by Zaqar\'s API and architecture because this would be fine for\n> >>> an architecture if what you describe above were the requirements:\n> >>>\n> >>> https://www.dropbox.com/s/yonloa9ytlf8fdh/ZaqarQueueOnly.png?dl=0\n> >>>\n> >>> Just stick a REST shim in front of AMQP that enforces tenant permissions\n> >>> and maps logical \"zaqar queues\" to whatever the backend serving queue is.\n> >>>\n> >>> So why would we need a NoSQL database for the data itself if all we are\n> >>> doing is shoving messages in and taking them out the other end?\n> >>\n> >> This was one of the ideas suggested by the TC at the last graduation \n> >> review (or was it the incubation review? I forget). The Zaqar team \n> >> looked into it and this was the outcome (for now):\n> >>\n> >> http://blog.flaper87.com/post/marconi-amqp-see-you-later/\n> >>\n> > \n> > I\'ve just re-read that, and it still feels the same as the first time:\n> > this feels like justification for the current body of work, instead of\n> > analysis for the necessity for the current feature set or feasibility of\n> > scaling it.\n> \n> To be fair, the analysis was done based one the current feature-set, the\n> amount of work required, the project goals in mind and the feasibility\n> of doing something like that in terms of time and short-term goals.\n> Still, the use cases were kept in mind and that\'s the reason why the\n> post keeps the doors open for future evaluation (at least that was the\n> goal :P)\n> \n> > \"The third motivation is something that Marconi brings to traditional\n> > brokers. With Marconi, it\'s possible to add per-queue sharding\n> > capabilities to traditional brokers. By using Marconi\'s pools and flavors\n> > it is possible to create separate clusters of storage that will be used\n> > cooperatively based on the pool settings.\"\n> > \n> > This statement does not seem use-case driven. It appears to be supporting\n> > the current implementation which, I assume, was done to work around\n> > the problem of databases not being able to scale like a queue. Users\n> > will just want to be able to reason about the messaging guarantees like\n> > \"delivered at least once\" and durability.\n> \n> This is not correct. Zaqar is not just trying to address use cases from\n> a user perspective but also the operator\'s.\n> \n> Pools and flavors were not added because of databases not scaling as\n> message-brokers. Furthermore, one of the use-cases when we started\n> talking about adding pools was that scaling brokers is not as simple as\n> it is presented.\n> \n> Pools and flavors have different use cases. Pools in particular were\n> added to add better scaling capabilities to Zaqar. In addition to that,\n> pools also allow operators to isolate clusters for specific queues or\n> tenants if necessary.\n> \n> Flavors, instead, are a user-facing feature. They allow users to choose\n> on what *type* of pool they want their messages. They can choose that\n> based on the flavor capabilities, which are basically the pool\n> capabilities. For instance, a user may choose between sending messages\n> to a `in-memory` pool to have a higher throughput or to a durable pool.\n> \n> The above obviously requires Zaqar to be deployed on top of different\n> storage and it also requires pools to be configured by the admin. But\n> both features address use-cases, for both operators and users, which we\n> consider valuable. Both features are optional.\n> \n\nThis was a fantastic explanation, thank you. I have read a few of the\ndocuments on it, but what you said above succinctly explains how use\ncases are extremely well served by these features. Thank you.\n\n> > Meanwhile there are quite a few message brokers that can scale in the\n> > same way, that Zaqar wouldn\'t even have to model.\n> > \n> > \"The API was designed to be browsable but without sacrificing the\n> > \"messaging\" feel of every queuing system. New things are being added to\n> > make it more message based without sacrificing browsability.\"\n> > \n> > This browsability is, at its core, the thing that concerns me and probably\n> > others who are expressing their opinions. It\'s not that we don\'t think\n> > it can be done, but we don\'t think it should be done when there are so\n> > many use cases solved by a regular old message queue.\n> > \n> \n> I\'m going to, probably, oversimplify here so bare with me. Browsability\n> is just another way to access messages. It makes it easier for users to\n> stream messages out of Zaqar if that\'s what works best for them. I\n> understand that what I\'m describing is precisely what a queue does but\n> in Zaqar it\'s a way for users to follow-their-nose and keep consuming\n> messages.\n> \n> I\'m not saying it couldn\'t be revisited, though. I\'m trying to explain\n> that it adds support for a common way to access messages.\n> \n\nBrowsability (my spell checker doesn\'t think that is a word. ;) is\nnothing new to the email user. It\'s a well known problem space really.\n\n> > The fact that sessions are a part of AMQP makes it complicated to\n> > emulate over HTTP when messages need to be ACK\'d. However, it seems\n> > pretty straight forward to me to have session ID as part of the API, and\n> > to have an RPC bus like we do now for our usual OpenStack services that\n> > has a topic per session. Then have the API frontends speaking over that\n> > bus, pushing ACK\'s down that topic to a backend engine that maintains\n> > the session. This is double-messaging for everything, which I wish I\n> > could think of a better solution for, but it is still lighter weight\n> > than putting all of the messages into a database.\n> \n> I\'m not sure I follow what you suggested here so I\'ll wait before I\n> comment. What I didn\'t understand is whether you were thinking to have\n> that solution as part of Zaqar or as a way to achieve browsability\n> without Zaqar.\n> \n\nI\'m only addressing the difficulty that AMQP would have with getting ACK\'s\nback to an original session. That paragraph is meant to highlight a key\nproblem with consumption of messages reliably from existing brokers via\nan HTTP API. If we can\'t use ACK\'s for reliably delivery, we can\'t have\nreliably delivery with queue semantics. It\'s a key part of AMQP that\nhelps the brokers operate efficiently. If they had to look messages up\nby ID without an open session, they\'d be back in the same problem space\nas Zaqar: looking them up in a database.\n\n> > Finally, two of the main sections in that article state \"Store and\n> > Forward\" and \"Message access by ID\" are important to Zaqar. Those two\n> > concepts are SMTP and IMAP in a nutshell. It still kind of boggles\n> > my mind that these weren\'t considered as backends, given that their\n> > protocols even match reasonably well to the parts of Zaqar\'s API that\n> > pertain to messages. They may not be sexy, but I\'d be quite surprised\n> > if there wasn\'t an SMTP+IMAP combination out there that can scale at\n> > least as cost effectively as Redis.\n> \n> FWIW, the article doesn\'t say \"Message access by ID\" is important. It\n> says that it\'s there now and we can\'t simply remove it because there are\n> people already using it.\n> \n\nI think it has become clear, that it should be proposed for deprecation\nas soon as a v2 API is published and available without those semantics.\n\n> In the other hand, store-and-forward is indeed, as of now, a key and\n> important point in Zaqar\'s architecture. The choices the team has made\n> for the storage drivers have been questioned a lot since its inception.\n> At the incubation meeting the feedback was that mongodb\'s AGPL license\n> was not good, hence sqlalchemy was added. At the first graduation\n> attempt the sqlalchemy driver didn\'t turn out to be as good as we hoped,\n> hence redis was added. And now IMAP. Don\'t get me wrong, I\'m not trying\n> to be mean/jerk, really. What I\'m trying to get at is that behind the\n> choices the team has made there were technical aspects that were taken\n> under consideration. I know you\'re not saying there weren\'t but I think\n> it\'s worth highlighting this.\n\nI also don\'t mean to suggest that you _must_ try IMAP. I meant to say,\nyou might find it quite easy to map the driver requirements to IMAP,\nand that there are quite a few very scalable IMAP services available as\nstoring lots of messsages is an old problem that has been solved for a\nlong time.\n\nApologies if my message dismissed your previous contributions, which are\nsignificant and impressive. I only mean to say: wow, that looks like\nemail to me.\n\n\n','<54129F3B.8000300@redhat.com>',NULL),('<1410546677.9468.17.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 18:27:55',0,'2014-09-12 18:27:55',NULL,'[openstack-dev] [Octavia] Responsibilities for controller drivers','IN IRC the topic came up about supporting many-to-many load balancers to\namphorae.  I believe a consensus was made that allowing only one-to-many\nload balancers to amphorae would be the first step forward, and\nre-evaluate later, since colocation and apolocation will need to work\n(which brings up another topic, defining what it actually means to be\ncolocated: On the same amphorae, on the same amphorae host, on the same\ncell/cluster, on the same data center/availability zone. That should be\nsomething we discuss later, but not right now).\n\nI am fine with that decisions, but Doug brought up a good point that\nthis could very well just be a decision for the controller driver and\nOctavia shouldn\'t mandate this for all drivers.  So I think we need to\nclearly define what decisions are the responsibility of the controller\ndriver versus what decisions are mandated by Octavia\'s construct.\n\nItems I can come up with off the top of my head:\n\n1) LB:Amphora - M:N vs 1:N\n2) VIPs:LB - M:N vs 1:N\n3) Pool:HMs - 1:N vs 1:1\n\nI\'m sure there are others.  I\'m sure each one will need to be evaluated\non a case-by-case basis.  We will be walking a fine line between\nflexibility and complexity.  We just need to define how far over that\nline and in which direction we are willing to go.\n\nThanks,\nBrandon\n\n','<CAAGw+ZrnWVsTUdJQRUfxC6_M5-RESr9=3cCVLHys0Cr0Y8s8KQ@mail.gmail.com>',NULL),('<1410578750.388929.1384265520500.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 15:12:00',3600,'2013-11-12 14:12:00',NULL,'[openstack-dev] [Nova] Recent change breaks manual control of\n service enabled / disabled status - suggest it is backed out and re-worked','I\'ll work on Daniel\'s suggestion and will send a patch for review.\n\nVladik\n\n----- Original Message -----\n> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, 12 November, 2013 5:32:28 AM\n> Subject: Re: [openstack-dev] [Nova] Recent change breaks manual control of service enabled / disabled status -\n> suggest it is backed out and re-worked\n> \n> On Mon, Nov 11, 2013 at 11:34:10AM +0000, Day, Phil wrote:\n> > Hi Folks,\n> > \n> > I\'d like to get some eyes on a bug I just filed:\n> > https://bugs.launchpad.net/nova/+bug/1250049\n> > \n> > A recent change (https://review.openstack.org/#/c/52189/9 ) introduced the\n> > automatic disable / re-enable of nova-compute when connection to libvirt\n> > is lost and recovered.   The problem is that it doesn\'t take any account\n> > of the fact that a cloud administrator may have other reasons for\n> > disabling a service, and always put nova-compute back into an enabled\n> > state.\n> > \n> > The impact of this is pretty big for us - at any point in time we have a\n> > number of servers disabled for various operational reasons, and there are\n> > times when we need to restart libvirt as part of a deployment.  With this\n> > change in place all of those hosts are returned to an enabled state, and\n> > the reason that they were disabled is lost.\n> > \n> > While I like the concept that an error condition like this should disable\n> > the host from a scheduling perspective, I think it needs to be implemented\n> > as an additional form of disablement (i.e a separate value kept in the\n> > ServiceGroup API), not an override of the current one.\n> > \n> > I\'d like to propose that the current change is reverted as a priority, and\n> > a new approach then submitted as a second step that works alongside the\n> > current enable /disable reason.\n> > \n> > Sorry for not catching this in the review stage - I didn\'t notice this one\n> > at all.\n> \n> It seems like it would be pretty easy to just use an explicit\n> \'disable_reason\'\n> string value, and then only automatically re-enable if the string matches the\n> one we set when disabling it originally. I think that should be easy enough\n> for\n> someone to do without needing to revert the entire original change.\n> \n> Daniel\n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20131112103228.GD3644@redhat.com>',NULL),('<1410706478-sup-3831@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-14 08:09:39',-25200,'2014-09-14 15:09:39',NULL,'[openstack-dev] [Heat] Defining what is a SupportStatus version','Excerpts from Gauvain Pocentek\'s message of 2014-09-04 22:29:05 -0700:\n> Hi,\n> \n> A bit of background: I\'m working on the publication of the HOT \n> resources reference on docs.openstack.org. This book is mostly \n> autogenerated from the heat source code, using the sphinx XML output. To \n> avoid publishing several references (one per released version, as is \n> done for the OpenStack config-reference), I\'d like to add information \n> about the support status of each resource (when they appeared, when \n> they\'ve been deprecated, and so on).\n> \n> So the plan is to use the SupportStatus class and its `version` \n> attribute (see https://review.openstack.org/#/c/116443/ ). And the \n> question is, what information should the version attribute hold? \n> Possibilities include the release code name (Icehouse, Juno), or the \n> release version (2014.1, 2014.2). But this wouldn\'t be useful for users \n> of clouds continuously deployed.\n> \n>  From my documenter point of view, using the code name seems the right \n> option, because it fits with the rest of the documentation.\n> \n> What do you think would be the best choice from the heat devs POV?\n\nWhat we ship in-tree is the standard library for Heat. I think Heat\nshould not tie things to the release of OpenStack, but only to itself.\n\nThe idea is to simply version the standard library of resources separately\neven from the language. Added resources and properties would be minor\nbumps, deprecating or removing anything would be a major bump. Users then\njust need an API call that allows querying the standard library version.\n\nWith this scheme, we can provide a gate test that prevents breaking the\nrules, and automatically generate the docs still. Doing this would sync\nbetter with continuous deployers who will be running \"Juno\" well before\nthere is a \"2014.2\".\n\nAnyway, Heat largely exists to support portability of apps between\nOpenStack clouds. Many many OpenStack clouds don\'t run one release,\nand we don\'t require them to do so. So tying to the release is, IMO,\na poor coice. We do the same thing with HOT\'s internals, so why not also\ndo the standard library this way?\n\n\n','<2be915f038fca7d18910d070de4d0a5c@objectif-libre.com>',NULL),('<1410709442.13961466.1401289993478.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 11:13:13',-14400,'2014-05-28 15:13:13',NULL,'[openstack-dev] Specifying file encoding','\n\n----- Original Message -----\n> From: \"P?draig Brady\" <P at draigBrady.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, May 28, 2014 6:28:28 AM\n> Subject: Re: [openstack-dev] Specifying file encoding\n> \n> On 05/28/2014 08:16 AM, Martin Geisler wrote:\n> > Hi everybody,\n> > \n> > I\'m trying to get my feet wet with OpenStack development, \n\nWelcome aboard!  Thanks for contributing.  :)\n\n>> so I recently\n> > tried to submit some small patches. One small thing I noticed was that\n> > some files used\n> > \n> >   # -*- encoding: utf-8 -*-\n> > \n> > to specify the file encoding for both Python and Emacs. Unfortunately,\n> > Emacs expects you to set \"coding\", not \"encoding\". Python is fine with\n> > either. I submitted a set of patches for this:\n> > \n> > * https://review.openstack.org/95862\n> > * https://review.openstack.org/95864\n> > * https://review.openstack.org/95865\n> > * https://review.openstack.org/95869\n> > * https://review.openstack.org/95871\n> > * https://review.openstack.org/95880\n> > * https://review.openstack.org/95882\n> > * https://review.openstack.org/95886\n> > \n> > It was pointed out to me that such a change ought to be coordinated\n> > better via bug(s) or the mailinglist, so here I am :)\n> \n> This is valid change.\n> I don\'t see why there is any question\n> as it only improves the situation for emacs\n> which will pop up an error when trying to edit these files.\n\nI guess I approach this differently.  When I saw this patch, my first thought was to validate\nif the line being changed needed to exist at all.\n\nIf the file has valid non-ascii characters that effect its execution, are absolutely required\nfor documentation to convey a specific meaning, or in strings that need to translate, then I agree\nthe change is valid.  But in the case the characters in the file can be changed, it seems like the\nbug is the extra encoding comment itself.\n\nTaking tuskar for example, the files in question seem to only need this encoding line to support\nthe copyright symbol.  \n\n[rb at localhost tuskar]$ grep -R -i -P \"[^\\x00-\\x7F]\" ./*\nBinary file ./doc/source/api/img/model_v2.jpg matches\nBinary file ./doc/source/api/img/model_v4.odg matches\nBinary file ./doc/source/api/img/model.odg matches\nBinary file ./doc/source/api/img/model_v3.jpg matches\nBinary file ./doc/source/api/img/model_v3.odg matches\nBinary file ./doc/source/api/img/model_v2.odg matches\nBinary file ./doc/source/api/img/model_v4.jpg matches\nBinary file ./doc/source/api/img/model_v1.jpg matches\nBinary file ./doc/source/_static/header_bg.jpg matches\nBinary file ./doc/source/_static/header-line.gif matches\nBinary file ./doc/source/_static/openstack_logo.png matches\n./tuskar/api/hooks.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n./tuskar/api/app.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n./tuskar/api/acl.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n./tuskar/common/service.py:# Copyright ? 2012 eNovance <licensing at enovance.com>\n./tuskar/tests/api/api.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n\n\nIn the U.S., copyright notices haven\'t really been needed since 1989.  You also only need to include\none instance of the symbol, \"Copyright\" or \"copr\" [1].  If the requirements for copyright are different\noutside the U.S., then I hope we capture that in the copyright wiki page [2].  Maybe the current info\nin that wiki needs to be updated or at least notated as to why the specific notice text is suggested. \n\nUnless there is another valid requirement to keep the ? in the files, I think it\'s best if we just\nremove them altogether and eliminate the need to add the encoding comments at all.\n\n\n- Ryan\n\n> \n> You could create a bug I suppose\n> to reference all the changes though I don\'t\n> think that\'s mandatory since this isn\'t user facing.\n> \n> cheers,\n> P?draig.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n[1] http://www.copyright.gov/circs/circ03.pdf\n[2] https://wiki.openstack.org/wiki/Documentation/Copyright\n\n\n','<5385BA4C.7080304@draigBrady.com>',NULL),('<1410798507-sup-6563@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 09:50:24',-25200,'2014-09-15 16:50:24',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n	and \"ready state\" orchestration','Excerpts from Steven Hardy\'s message of 2014-09-15 04:44:24 -0700:\n> All,\n> \n> Starting this thread as a follow-up to a strongly negative reaction by the\n> Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and\n> subsequent very detailed justification and discussion of why they may be\n> useful in this spec[2].\n> \n> Back in Atlanta, I had some discussions with folks interesting in making\n> \"ready state\"[3] preparation of bare-metal resources possible when\n> deploying bare-metal nodes via TripleO/Heat/Ironic.\n> \n> The initial assumption is that there is some discovery step (either\n> automatic or static generation of a manifest of nodes), that can be input\n> to either Ironic or Heat.\n> \n> Following discovery, but before an undercloud deploying OpenStack onto the\n> nodes, there are a few steps which may be desired, to get the hardware into\n> a state where it\'s ready and fully optimized for the subsequent deployment:\n> \n> - Updating and aligning firmware to meet requirements of qualification or\n>   site policy\n> - Optimization of BIOS configuration to match workloads the node is\n>   expected to run\n> - Management of machine-local storage, e.g configuring local RAID for\n>   optimal resilience or performance.\n> \n> Interfaces to Ironic are landing (or have landed)[4][5][6] which make many\n> of these steps possible, but there\'s no easy way to either encapsulate the\n> (currently mostly vendor specific) data associated with each step, or to\n> coordinate sequencing of the steps.\n> \n\nFirst, Ironic is hidden under Nova as far as TripleO is concerned. So\nmucking with the servers underneath Nova during deployment is a difficult\nproposition. Would I look up the Ironic node ID of the nova server,\nand then optimize it for the workload after the workload arrived? Why\nwouldn\'t I just do that optimization before the deployment?\n\n> What is required is some tool to take a text definition of the required\n> configuration, turn it into a correctly sequenced series of API calls to\n> Ironic, expose any data associated with those API calls, and declare\n> success or failure on completion.  This is what Heat does.\n> \n\nI\'d rather see Ironic define or adopt a narrow scope document format\nthat it can consume for bulk loading. Heat is extremely generic, and thus\ncarries a ton of complexity for what is probably doable with a CSV file.\n\n> So the idea is to create some basic (contrib, disabled by default) Ironic\n> heat resources, then explore the idea of orchestrating ready-state\n> configuration via Heat.\n> \n> Given that Devananda and I have been banging heads over this for some time\n> now, I\'d like to get broader feedback of the idea, my interpretation of\n> \"ready state\" applied to the tripleo undercloud, and any alternative\n> implementation ideas.\n> \n\nI think there may be value in being able to tie Ironic calls to other\nOpenStack API calls. I\'m dubious that this is an important idea, but\nI think if somebody wants to step forward with their use case for it,\nthen the resources might make sense. However, I realy don\'t see the\n_enrollment_ phase as capturing any value that isn\'t entirely offset by\nadded complexity.\n\n\n','<20140915114423.GA5174@t430slt.redhat.com>',NULL),('<1410799890-sup-9159@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 09:59:16',-25200,'2014-09-15 16:59:16',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n	and \"ready state\" orchestration','Excerpts from James Slagle\'s message of 2014-09-15 08:15:21 -0700:\n> On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy <shardy at redhat.com> wrote:\n> > All,\n> >\n> > Starting this thread as a follow-up to a strongly negative reaction by the\n> > Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and\n> > subsequent very detailed justification and discussion of why they may be\n> > useful in this spec[2].\n> >\n> > Back in Atlanta, I had some discussions with folks interesting in making\n> > \"ready state\"[3] preparation of bare-metal resources possible when\n> > deploying bare-metal nodes via TripleO/Heat/Ironic.\n> \n> After a cursory reading of the references, it seems there\'s a couple of issues:\n> - are the features to move hardware to a \"ready-state\" even going to\n> be in Ironic proper, whether that means in ironic at all or just in\n> contrib.\n> - assuming some of the features are there, should Heat have any Ironic\n> resources given that Ironic\'s API is admin-only.\n> \n> >\n> > The initial assumption is that there is some discovery step (either\n> > automatic or static generation of a manifest of nodes), that can be input\n> > to either Ironic or Heat.\n> \n> I think it makes a lot of sense to use Heat to do the bulk\n> registration of nodes via Ironic. I understand the argument that the\n> Ironic API should be \"admin-only\" a little bit for the non-TripleO\n> case, but for TripleO, we only have admins interfacing with the\n> Undercloud. The user of a TripleO undercloud is the deployer/operator\n> and in some scenarios this may not be the undercloud admin. So,\n> talking about TripleO, I don\'t really buy that the Ironic API is\n> admin-only.\n> \n> Therefore, why not have some declarative Heat resources for things\n> like Ironic nodes, that the deployer can make use of in a Heat\n> template to do bulk node registration?\n> \n> The alternative listed in the spec:\n> \n> \"Don?t implement the resources and rely on scripts which directly\n> interact with the Ironic API, prior to any orchestration via Heat.\"\n> \n> would just be a bit silly IMO. That goes against one of the main\n> drivers of TripleO, which is to use OpenStack wherever possible. Why\n> go off and write some other thing that is going to parse a\n> json/yaml/csv of nodes and orchestrate a bunch of Ironic api calls?\n> Why would it be ok for that other thing to use Ironic\'s \"admin-only\"\n> API yet claim it\'s not ok for Heat on the undercloud to do so?\n> \n\nAn alternative that is missed, is to just define a bulk loading format\nfor hardware, or adopt an existing one (I find it hard to believe there\nisn\'t already an open format for this), and make use of it in Ironic.\n\nThe analogy I\'d use is shipping dry goods in a refrigerated truck.\nIt\'s heavier, has a bit less capacity, and unnecessary features.  If all\nyou have is the refrigerated truck, ok. But we\'re talking about _building_\na special dry-goods add-on to our refrigerated truck (Heat) to avoid\nbuilding the same thing into the regular trucks we already have (Ironic).\n\n> > Following discovery, but before an undercloud deploying OpenStack onto the\n> > nodes, there are a few steps which may be desired, to get the hardware into\n> > a state where it\'s ready and fully optimized for the subsequent deployment:\n> >\n> > - Updating and aligning firmware to meet requirements of qualification or\n> >   site policy\n> > - Optimization of BIOS configuration to match workloads the node is\n> >   expected to run\n> > - Management of machine-local storage, e.g configuring local RAID for\n> >   optimal resilience or performance.\n> >\n> > Interfaces to Ironic are landing (or have landed)[4][5][6] which make many\n> > of these steps possible, but there\'s no easy way to either encapsulate the\n> > (currently mostly vendor specific) data associated with each step, or to\n> > coordinate sequencing of the steps.\n> >\n> > What is required is some tool to take a text definition of the required\n> > configuration, turn it into a correctly sequenced series of API calls to\n> > Ironic, expose any data associated with those API calls, and declare\n> > success or failure on completion.  This is what Heat does.\n> >\n> > So the idea is to create some basic (contrib, disabled by default) Ironic\n> > heat resources, then explore the idea of orchestrating ready-state\n> > configuration via Heat.\n> >\n> > Given that Devananda and I have been banging heads over this for some time\n> > now, I\'d like to get broader feedback of the idea, my interpretation of\n> > \"ready state\" applied to the tripleo undercloud, and any alternative\n> > implementation ideas.\n> \n> My opinion is that if the features are in Ironic, they should be\n> exposed via Heat resources for orchestration. If the TripleO case is\n> too much of a one-off (which I don\'t really think it is), then sure,\n> keep it all in contrib so that no one gets confused about why the\n> resources are there.\n> \n\nAnd I think if this is a common thing that Ironic users need to do,\nthen Ironic should do it, not Heat.\n\n\n','<CAHV77z9c_h=ki7tSGDXF1WrMD3Hb4eFVKbrjOodhw09V=29aEw@mail.gmail.com>',NULL),('<1410801787-sup-6866@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 10:28:07',-25200,'2014-09-15 17:28:07',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Flavio Percoco\'s message of 2014-09-15 00:57:05 -0700:\n> On 09/12/2014 07:13 PM, Clint Byrum wrote:\n> > Excerpts from Thierry Carrez\'s message of 2014-09-12 02:16:42 -0700:\n> >> Clint Byrum wrote:\n> >>> Excerpts from Flavio Percoco\'s message of 2014-09-11 04:14:30 -0700:\n> >>>> Is Zaqar being optimized as a *queuing* service? I\'d say no. Our goal is\n> >>>> to optimize Zaqar for delivering messages and supporting different\n> >>>> messaging patterns.\n> >>>\n> >>> Awesome! Just please don\'t expect people to get excited about it for\n> >>> the lighter weight queueing workloads that you\'ve claimed as use cases.\n> >>>\n> >>> I totally see Horizon using it to keep events for users. I see Heat\n> >>> using it for stack events as well. I would bet that Trove would benefit\n> >>> from being able to communicate messages to users.\n> >>>\n> >>> But I think in between Zaqar and the backends will likely be a lighter\n> >>> weight queue-only service that the users can just subscribe to when they\n> >>> don\'t want an inbox. And I think that lighter weight queue service is\n> >>> far more important for OpenStack than the full blown random access\n> >>> inbox.\n> >>>\n> >>> I think the reason such a thing has not appeared is because we were all\n> >>> sort of running into \"but Zaqar is already incubated\". Now that we\'ve\n> >>> fleshed out the difference, I think those of us that need a lightweight\n> >>> multi-tenant queue service should add it to OpenStack.  Separately. I hope\n> >>> that doesn\'t offend you and the rest of the excellent Zaqar developers. It\n> >>> is just a different thing.\n> >>>\n> >>>> Should we remove all the semantics that allow people to use Zaqar as a\n> >>>> queue service? I don\'t think so either. Again, the semantics are there\n> >>>> because Zaqar is using them to do its job. Whether other folks may/may\n> >>>> not use Zaqar as a queue service is out of our control.\n> >>>>\n> >>>> This doesn\'t mean the project is broken.\n> >>>\n> >>> No, definitely not broken. It just isn\'t actually necessary for many of\n> >>> the stated use cases.\n> >>\n> >> Clint,\n> >>\n> >> If I read you correctly, you\'re basically saying the Zaqar is overkill\n> >> for a lot of people who only want a multi-tenant queue service. It\'s\n> >> doing A+B. Why does that prevent people who only need A from using it ?\n> >>\n> >> Is it that it\'s actually not doing A well, from a user perspective ?\n> >> Like the performance sucks, or it\'s missing a key primitive ?\n> >>\n> >> Is it that it\'s unnecessarily complex to deploy, from a deployer\n> >> perspective, and that something only doing A would be simpler, while\n> >> covering most of the use cases?\n> >>\n> >> Is it something else ?\n> >>\n> >> I want to make sure I understand your objection. In the \"user\n> >> perspective\" it might make sense to pursue both options as separate\n> >> projects. In the \"deployer perspective\" case, having a project doing A+B\n> >> and a project doing A doesn\'t solve anything. So this affects the\n> >> decision we have to take next Tuesday...\n> > \n> > I believe that Zaqar does two things, inbox semantics, and queue\n> > semantics. I believe the queueing is a side-effect of needing some kind\n> > of queue to enable users to store and subscribe to messages in the\n> > inbox.\n> > \n> > What I\'d rather see is an API for queueing, and an API for inboxes\n> > which integrates well with the queueing API. For instance, if a user\n> > says \"give me an inbox\" I think Zaqar should return a queue handle for\n> > sending into the inbox the same way Nova gives you a Neutron port if\n> > you don\'t give it one. You might also ask for a queue to receive push\n> > messages from the inbox. Point being, the queues are not the inbox,\n> > and the inbox is not the queues.\n> > \n> > However, if I just want a queue, just give me a queue. Don\'t store my\n> > messages in a randomly addressable space, and don\'t saddle the deployer\n> > with the burden of such storage. Put the queue API in front of a scalable\n> > message queue and give me a nice simple HTTP API. Users would likely be\n> > thrilled. Heat, Nova, Ceilometer, probably Trove and Sahara, could all\n> > make use of just this. Only Horizon seems to need a place to keep the\n> > messages around while users inspect them.\n> > \n> > Whether that is two projects, or one, separation between the two API\'s,\n> > and thus two very different types of backends, is something I think\n> > will lead to more deployers wanting to deploy both, so that they can\n> > bill usage appropriately and so that their users can choose wisely.\n> \n> This is one of the use-cases we designed flavors for. One of the mail\n> ideas behind flavors is giving the user the choice of where they want\n> their messages to be stored. This certainly requires the deployer to\n> have installed stores that are good for each job. For example, based on\n> the current existing drivers, a deployer could have configured a\n> high-throughput flavor on top of a redis node that has been configured\n> to perform for this job. Alongside to this flavor, the deployer could\'ve\n> configured a flavor that features durability on top of mongodb or redis.\n> \n> When the user creates the queue/bucket/inbox/whatever they want to put\n> their messages into, they\'ll be able to choose where those messages\n> should be stored into based on their needs.\n> \n> I do understand your objection is not against Zaqar being able to do\n> this now or not but whether an integrate API for both kind of semantics\n> makes sense or not. I still fail to see why they need to be separated,\n> though. Billing can still happen properly based on the resource usage,\n> flavors and other metrics.\n\nAs long as it can be built into the API that certain flavors don\'t allow\npagination of messages, I can see it working. Also maybe some flavors\nare auto-ACK and thus can be backed entirely by AMQP/gearman/etc. without\nany special gymnastics to support sessions.\n\nHowever, I tend to think that if one thing is a superset of the other,\nthey can also be separate, and typically in a scale-out context, if\nsomething can be separate, it should be.\n\n\n','<54169BD1.8070608@redhat.com>',NULL),('<1410803503398.4135@jvf.cc>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 17:51:43',0,'2014-09-15 17:51:43',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n and \"ready state\" orchestration','Steven,\n\nIt\'s important to note that two of the blueprints you reference: \n\nhttps://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt\nhttps://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery\n\nare both very unlikely to land in Ironic -- these are configuration and discovery pieces that best fit inside a operator-deployed CMDB, rather than Ironic trying to extend its scope significantly to include these type of functions. I expect the scoping or Ironic with regards to hardware discovery/interrogation as well as configuration of hardware (like I will outline below) to be hot topics in Ironic design summit sessions at Paris.\n\nA good way of looking at it is that Ironic is responsible for hardware *at provision time*. Registering the nodes in Ironic, as well as hardware settings/maintenance/etc while a workload is provisioned is left to the operators\' CMDB. \n\nThis means what Ironic *can* do is modify the configuration of a node at provision time based on information passed down the provisioning pipeline. For instance, if you wanted to configure certain firmware pieces at provision time, you could do something like this:\n\nNova flavor sets capability:vm_hypervisor in the flavor that maps to the Ironic node. This would map to an Ironic driver that exposes vm_hypervisor as a capability, and upon seeing capability:vm_hypervisor has been requested, could then configure the firmware/BIOS of the machine to \'hypervisor friendly\' settings, such as VT bit on and Turbo mode off. You could map multiple different combinations of capabilities as different Ironic flavors, and have them all represent different configurations of the same pool of nodes. So, you end up with two categories of abilities: inherent abilities of the node (such as amount of RAM or CPU installed), and configurable abilities (i.e. things than can be turned on/off at provision time on demand) -- or perhaps, in the future, even things like RAM and CPU will be dynamically provisioned into nodes at provision time. \n\n-Jay Faulkner\n\n________________________________________\nFrom: Steven Hardy <shardy at redhat.com>\nSent: Monday, September 15, 2014 4:44 AM\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and \"ready state\" orchestration\n\nAll,\n\nStarting this thread as a follow-up to a strongly negative reaction by the\nIronic PTL to my patches[1] adding initial Heat->Ironic integration, and\nsubsequent very detailed justification and discussion of why they may be\nuseful in this spec[2].\n\nBack in Atlanta, I had some discussions with folks interesting in making\n\"ready state\"[3] preparation of bare-metal resources possible when\ndeploying bare-metal nodes via TripleO/Heat/Ironic.\n\nThe initial assumption is that there is some discovery step (either\nautomatic or static generation of a manifest of nodes), that can be input\nto either Ironic or Heat.\n\nFollowing discovery, but before an undercloud deploying OpenStack onto the\nnodes, there are a few steps which may be desired, to get the hardware into\na state where it\'s ready and fully optimized for the subsequent deployment:\n\n- Updating and aligning firmware to meet requirements of qualification or\n  site policy\n- Optimization of BIOS configuration to match workloads the node is\n  expected to run\n- Management of machine-local storage, e.g configuring local RAID for\n  optimal resilience or performance.\n\nInterfaces to Ironic are landing (or have landed)[4][5][6] which make many\nof these steps possible, but there\'s no easy way to either encapsulate the\n(currently mostly vendor specific) data associated with each step, or to\ncoordinate sequencing of the steps.\n\nWhat is required is some tool to take a text definition of the required\nconfiguration, turn it into a correctly sequenced series of API calls to\nIronic, expose any data associated with those API calls, and declare\nsuccess or failure on completion.  This is what Heat does.\n\nSo the idea is to create some basic (contrib, disabled by default) Ironic\nheat resources, then explore the idea of orchestrating ready-state\nconfiguration via Heat.\n\nGiven that Devananda and I have been banging heads over this for some time\nnow, I\'d like to get broader feedback of the idea, my interpretation of\n\"ready state\" applied to the tripleo undercloud, and any alternative\nimplementation ideas.\n\nThanks!\n\nSteve\n\n[1] https://review.openstack.org/#/c/104222/\n[2] https://review.openstack.org/#/c/120778/\n[3] http://robhirschfeld.com/2014/04/25/ready-state-infrastructure/\n[4] https://blueprints.launchpad.net/ironic/+spec/drac-management-driver\n[5] https://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt\n[6] https://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20140915114423.GA5174@t430slt.redhat.com>',NULL),('<1410805936.26709.2.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 20:32:16',7200,'2014-09-15 18:32:16',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n and \"ready state\" orchestration','On Mon, 2014-09-15 at 11:04 -0700, Jim Rollenhagen wrote:\n> On Mon, Sep 15, 2014 at 12:44:24PM +0100, Steven Hardy wrote:\n> > All,\n> > \n> > Starting this thread as a follow-up to a strongly negative reaction by the\n> > Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and\n> > subsequent very detailed justification and discussion of why they may be\n> > useful in this spec[2].\n> > \n> > Back in Atlanta, I had some discussions with folks interesting in making\n> > \"ready state\"[3] preparation of bare-metal resources possible when\n> > deploying bare-metal nodes via TripleO/Heat/Ironic.\n> > \n> > The initial assumption is that there is some discovery step (either\n> > automatic or static generation of a manifest of nodes), that can be input\n> > to either Ironic or Heat.\n> \n> We\'ve discussed this a *lot* within Ironic, and have decided that\n> auto-discovery (with registration) is out of scope for Ironic. \nEven if there is such an agreement, it\'s the first time I hear about it.\nAll previous discussions _I\'m aware of_ (e.g. midcycle) ended up with\n\"we can discover only things that are required for scheduling\". When did\nit change?\n\n> In my\n> opinion, this is straightforward enough for operators to write small\n> scripts to take a CSV/JSON/whatever file and register the nodes in that\n> file with Ironic. This is what we\'ve done at Rackspace, and it\'s really\n> not that annoying; the hard part is dealing with incorrect data from\n> the (vendor|DC team|whatever).\nProvided this CSV contains all the required data, not only IPMI\ncredentials, which IIRC is often the case.\n\n> \n> That said, I like the thought of Ironic having a bulk-registration\n> feature with some sort of specified format (I imagine this would just be\n> a simple JSON list of node objects).\n> \n> We are likely doing a session on discovery in general in Paris. It seems\n> like the main topic will be about how to interface with external\n> inventory management systems to coordinate node discovery. Maybe Heat is\n> a valid tool to integrate with here, maybe not.\n> \n> > Following discovery, but before an undercloud deploying OpenStack onto the\n> > nodes, there are a few steps which may be desired, to get the hardware into\n> > a state where it\'s ready and fully optimized for the subsequent deployment:\n> \n> These pieces are mostly being done downstream, and (IMO) in scope for\n> Ironic in the Kilo cycle. More below.\n> \n> > - Updating and aligning firmware to meet requirements of qualification or\n> >   site policy\n> \n> Rackspace does this today as part of what we call \"decommissioning\".\n> There are patches up for review for both ironic-python-agent (IPA) [1] and\n> Ironic [2] itself. We have support for 1) flashing a BIOS on a node, and\n> 2) Writing a set of BIOS settings to a node (these are embedded in the agent\n> image as a set, not through an Ironic API). These are both implemented as\n> a hardware manager plugin, and so can easily be vendor-specific.\n> \n> I expect this to land upstream in the Kilo release.\n> \n> > - Optimization of BIOS configuration to match workloads the node is\n> >   expected to run\n> \n> The Ironic team has also discussed this, mostly at the last mid-cycle\n> meetup. We\'ll likely have a session on \"capabilities\", which we think\n> might be the best way to handle this case. Essentially, a node can be\n> tagged with arbitrary capabilities, e.g. \"hypervisor\", which Nova\n> (flavors?) could use for scheduling, and Ironic drivers could use to do\n> per-provisioning work, like setting BIOS settings. This may even tie in\n> with the next point.\n> \n> Looks like Jay just ninja\'d me a bit on this point. :)\n> \n> > - Management of machine-local storage, e.g configuring local RAID for\n> >   optimal resilience or performance.\n> \n> I don\'t see why Ironic couldn\'t do something with this in Kilo. It\'s\n> dangerously close to the \"inventory management\" line, however I think\n> it\'s reasonable for a user to specify that his or her root partition\n> should be on a RAID or a specific disk out of many in the node.\n> \n> > Interfaces to Ironic are landing (or have landed)[4][5][6] which make many\n> > of these steps possible, but there\'s no easy way to either encapsulate the\n> > (currently mostly vendor specific) data associated with each step, or to\n> > coordinate sequencing of the steps.\n> \n> It\'s important to remember that just because a blueprint/spec exists,\n> does not mean it will be approved. :) I don\'t expect the \"DRAC\n> discovery\" blueprint to go through, and the \"DRAC RAID\" blueprint is\n> questionable, with regards to scope.\n> \n> > What is required is some tool to take a text definition of the required\n> > configuration, turn it into a correctly sequenced series of API calls to\n> > Ironic, expose any data associated with those API calls, and declare\n> > success or failure on completion.  This is what Heat does.\n> \n> This is a fair point, however none of these use cases have code landed\n> in mainline Ironic, and certainly don\'t have APIs exposed, with the\n> exception of node registration. Is it useful to start writing plumbing to\n> talk to APIs that don\'t exist?\n> \n> All that said, I don\'t think it\'s unreasonable for Heat to talk directly\n> to Ironic, but only if there\'s a valid use case that Ironic can\'t (or\n> won\'t) provide a solution for.\n> \n> // jim\n> \n> [1] https://review.openstack.org/104379\n> [2] https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:decom-nodes,n,z\n> \n> > So the idea is to create some basic (contrib, disabled by default) Ironic\n> > heat resources, then explore the idea of orchestrating ready-state\n> > configuration via Heat.\n> > \n> > Given that Devananda and I have been banging heads over this for some time\n> > now, I\'d like to get broader feedback of the idea, my interpretation of\n> > \"ready state\" applied to the tripleo undercloud, and any alternative\n> > implementation ideas.\n> > \n> > Thanks!\n> > \n> > Steve\n> > \n> > [1] https://review.openstack.org/#/c/104222/\n> > [2] https://review.openstack.org/#/c/120778/\n> > [3] http://robhirschfeld.com/2014/04/25/ready-state-infrastructure/\n> > [4] https://blueprints.launchpad.net/ironic/+spec/drac-management-driver\n> > [5] https://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt\n> > [6] https://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery\n> > \n> \n> \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140915180400.GA17340@jimrollenhagen.com>',NULL),('<1410806634-sup-9214@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 11:58:45',-25200,'2014-09-15 18:58:45',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n	and \"ready state\" orchestration','Excerpts from Steven Hardy\'s message of 2014-09-15 10:10:05 -0700:\n> On Mon, Sep 15, 2014 at 09:50:24AM -0700, Clint Byrum wrote:\n> > Excerpts from Steven Hardy\'s message of 2014-09-15 04:44:24 -0700:\n> > > All,\n> > > \n> > > Starting this thread as a follow-up to a strongly negative reaction by the\n> > > Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and\n> > > subsequent very detailed justification and discussion of why they may be\n> > > useful in this spec[2].\n> > > \n> > > Back in Atlanta, I had some discussions with folks interesting in making\n> > > \"ready state\"[3] preparation of bare-metal resources possible when\n> > > deploying bare-metal nodes via TripleO/Heat/Ironic.\n> > > \n> > > The initial assumption is that there is some discovery step (either\n> > > automatic or static generation of a manifest of nodes), that can be input\n> > > to either Ironic or Heat.\n> > > \n> > > Following discovery, but before an undercloud deploying OpenStack onto the\n> > > nodes, there are a few steps which may be desired, to get the hardware into\n> > > a state where it\'s ready and fully optimized for the subsequent deployment:\n> > > \n> > > - Updating and aligning firmware to meet requirements of qualification or\n> > >   site policy\n> > > - Optimization of BIOS configuration to match workloads the node is\n> > >   expected to run\n> > > - Management of machine-local storage, e.g configuring local RAID for\n> > >   optimal resilience or performance.\n> > > \n> > > Interfaces to Ironic are landing (or have landed)[4][5][6] which make many\n> > > of these steps possible, but there\'s no easy way to either encapsulate the\n> > > (currently mostly vendor specific) data associated with each step, or to\n> > > coordinate sequencing of the steps.\n> > > \n> > \n> > First, Ironic is hidden under Nova as far as TripleO is concerned. So\n> > mucking with the servers underneath Nova during deployment is a difficult\n> > proposition. Would I look up the Ironic node ID of the nova server,\n> > and then optimize it for the workload after the workload arrived? Why\n> > wouldn\'t I just do that optimization before the deployment?\n> \n> That\'s exactly what I\'m proposing - a series of preparatory steps performed\n> before the node is visible to nova, before the deployment.\n> \n\nOk good, so I didn\'t misunderstand. I\'m having trouble seeing where Heat\nis a good fit there.\n\n> The whole point is that Ironic is hidden under nova, and provides no way to\n> perform these pre-deploy steps via interaction with nova.\n> \n> > \n> > > What is required is some tool to take a text definition of the required\n> > > configuration, turn it into a correctly sequenced series of API calls to\n> > > Ironic, expose any data associated with those API calls, and declare\n> > > success or failure on completion.  This is what Heat does.\n> > > \n> > \n> > I\'d rather see Ironic define or adopt a narrow scope document format\n> > that it can consume for bulk loading. Heat is extremely generic, and thus\n> > carries a ton of complexity for what is probably doable with a CSV file.\n> \n> Perhaps you can read the spec - it\'s not really about the bulk-load part,\n> it\'s about orchestrating the steps to prepare the node, after it\'s\n> registered with Ironic, but before it\'s ready to have the stuff deployed to\n> it.\n> \n\nSounds like workflow to me. :-P\n\n> What tool do you think will \"just do that optimization before the\n> deployment\"? (snark not intended, I genuinely want to know, is it scripts\n> in TripleO, some sysadmin pre-deploy steps, magic in Ironic?)\n>\n\nIf it can all be done by calls to the ironic client with the node ID and\nparameters from the user, I\'d suggest that this is a simple workflow\nand can be done in the step prior to \'heat stack-create\'. I don\'t see\nany reason to keep a bunch of records around in Heat to describe what\nhappened, identically, for Ironic nodes. It is an ephemeral step in the\nevolution of the system, not something we need to edit on a regular basis.\n\nMy new bar for whether something is a good fit for Heat is what happens\nto my workload when I update it. If I go into my Ironic pre-registration\nstack and change things around, the likely case is that my box reboots\nto re-apply BIOS updates with the new paramters. And there is a missing\ndependency expression when using the orchestration tool to do the\nworkflow job. It may actually be necessary to always do these things to\nthe hardware in a certain sequence. But editting the Heat template and\nupdating has no way to express that.\n\nTo contrast this with developing it in a workflow control language\n(like bash), it is imperative so I am consciously deciding to re-apply\nthose things by running it. If I only want to do one step, I just do\nthe one step.\n\nBasically, the imperative model is rigid, sharp, and pointy, but the\ndeclarative model is soft and maleable, and full of unexpected sharp\npointy things. I think users are more comfortable with knowing where\nthe sharp and pointy things are, than stumbling on them.\n\n> > > So the idea is to create some basic (contrib, disabled by default) Ironic\n> > > heat resources, then explore the idea of orchestrating ready-state\n> > > configuration via Heat.\n> > > \n> > > Given that Devananda and I have been banging heads over this for some time\n> > > now, I\'d like to get broader feedback of the idea, my interpretation of\n> > > \"ready state\" applied to the tripleo undercloud, and any alternative\n> > > implementation ideas.\n> > > \n> > \n> > I think there may be value in being able to tie Ironic calls to other\n> > OpenStack API calls. I\'m dubious that this is an important idea, but\n> > I think if somebody wants to step forward with their use case for it,\n> > then the resources might make sense. However, I realy don\'t see the\n> > _enrollment_ phase as capturing any value that isn\'t entirely offset by\n> > added complexity.\n> \n> I\'ve stepped forward with a use-case for it, in the spec, and it\'s not\n> about the enrollment phase (although Heat could do that, if for example it\n> was used to manage the series of steps required for autodiscovery).\n> \n\nYeah I think I got confused by the talk of it in other branches of the\nthread. I think I understand now that this is a post-enrollment\nworkflow.\n\n> If there\'s a better way to do this, I\'m very happy to hear about it, but I\n> am getting a little tired of folks telling me the idea is dubious without\n> offering any alternative solution to the requirement :(\n\nAny workflow tool will do this just fine. I do think Heat is an o-k choice\nfor this, but I\'d rather see TripleO embrace more workflow control via\nAPI, than bend Heat into that role.\n\n\n','<20140915171004.GB21759@t430slt.redhat.com>',NULL),('<1410808640-sup-5060@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 12:33:00',-25200,'2014-09-15 19:33:00',NULL,'[openstack-dev] [Zaqar] Zaqar graduation (round 2) [was:\n	Comments on the concerns arose during the TC meeting]','Excerpts from Zane Bitter\'s message of 2014-09-15 12:05:09 -0700:\n> On 15/09/14 13:28, Clint Byrum wrote:\n> > Excerpts from Flavio Percoco\'s message of 2014-09-15 00:57:05 -0700:\n> >> On 09/12/2014 07:13 PM, Clint Byrum wrote:\n> >>> Excerpts from Thierry Carrez\'s message of 2014-09-12 02:16:42 -0700:\n> >>>> Clint Byrum wrote:\n> >>>>> Excerpts from Flavio Percoco\'s message of 2014-09-11 04:14:30 -0700:\n> >>>>>> Is Zaqar being optimized as a *queuing* service? I\'d say no. Our goal is\n> >>>>>> to optimize Zaqar for delivering messages and supporting different\n> >>>>>> messaging patterns.\n> >>>>>\n> >>>>> Awesome! Just please don\'t expect people to get excited about it for\n> >>>>> the lighter weight queueing workloads that you\'ve claimed as use cases.\n> >>>>>\n> >>>>> I totally see Horizon using it to keep events for users. I see Heat\n> >>>>> using it for stack events as well. I would bet that Trove would benefit\n> >>>>> from being able to communicate messages to users.\n> >>>>>\n> >>>>> But I think in between Zaqar and the backends will likely be a lighter\n> >>>>> weight queue-only service that the users can just subscribe to when they\n> >>>>> don\'t want an inbox. And I think that lighter weight queue service is\n> >>>>> far more important for OpenStack than the full blown random access\n> >>>>> inbox.\n> >>>>>\n> >>>>> I think the reason such a thing has not appeared is because we were all\n> >>>>> sort of running into \"but Zaqar is already incubated\". Now that we\'ve\n> >>>>> fleshed out the difference, I think those of us that need a lightweight\n> >>>>> multi-tenant queue service should add it to OpenStack.  Separately. I hope\n> >>>>> that doesn\'t offend you and the rest of the excellent Zaqar developers. It\n> >>>>> is just a different thing.\n> >>>>>\n> >>>>>> Should we remove all the semantics that allow people to use Zaqar as a\n> >>>>>> queue service? I don\'t think so either. Again, the semantics are there\n> >>>>>> because Zaqar is using them to do its job. Whether other folks may/may\n> >>>>>> not use Zaqar as a queue service is out of our control.\n> >>>>>>\n> >>>>>> This doesn\'t mean the project is broken.\n> >>>>>\n> >>>>> No, definitely not broken. It just isn\'t actually necessary for many of\n> >>>>> the stated use cases.\n> >>>>\n> >>>> Clint,\n> >>>>\n> >>>> If I read you correctly, you\'re basically saying the Zaqar is overkill\n> >>>> for a lot of people who only want a multi-tenant queue service. It\'s\n> >>>> doing A+B. Why does that prevent people who only need A from using it ?\n> >>>>\n> >>>> Is it that it\'s actually not doing A well, from a user perspective ?\n> >>>> Like the performance sucks, or it\'s missing a key primitive ?\n> >>>>\n> >>>> Is it that it\'s unnecessarily complex to deploy, from a deployer\n> >>>> perspective, and that something only doing A would be simpler, while\n> >>>> covering most of the use cases?\n> >>>>\n> >>>> Is it something else ?\n> >>>>\n> >>>> I want to make sure I understand your objection. In the \"user\n> >>>> perspective\" it might make sense to pursue both options as separate\n> >>>> projects. In the \"deployer perspective\" case, having a project doing A+B\n> >>>> and a project doing A doesn\'t solve anything. So this affects the\n> >>>> decision we have to take next Tuesday...\n> >>>\n> >>> I believe that Zaqar does two things, inbox semantics, and queue\n> >>> semantics. I believe the queueing is a side-effect of needing some kind\n> >>> of queue to enable users to store and subscribe to messages in the\n> >>> inbox.\n> >>>\n> >>> What I\'d rather see is an API for queueing, and an API for inboxes\n> >>> which integrates well with the queueing API. For instance, if a user\n> >>> says \"give me an inbox\" I think Zaqar should return a queue handle for\n> >>> sending into the inbox the same way Nova gives you a Neutron port if\n> >>> you don\'t give it one. You might also ask for a queue to receive push\n> >>> messages from the inbox. Point being, the queues are not the inbox,\n> >>> and the inbox is not the queues.\n> >>>\n> >>> However, if I just want a queue, just give me a queue. Don\'t store my\n> >>> messages in a randomly addressable space, and don\'t saddle the deployer\n> >>> with the burden of such storage. Put the queue API in front of a scalable\n> >>> message queue and give me a nice simple HTTP API. Users would likely be\n> >>> thrilled. Heat, Nova, Ceilometer, probably Trove and Sahara, could all\n> >>> make use of just this. Only Horizon seems to need a place to keep the\n> >>> messages around while users inspect them.\n> >>>\n> >>> Whether that is two projects, or one, separation between the two API\'s,\n> >>> and thus two very different types of backends, is something I think\n> >>> will lead to more deployers wanting to deploy both, so that they can\n> >>> bill usage appropriately and so that their users can choose wisely.\n> >>\n> >> This is one of the use-cases we designed flavors for. One of the mail\n> >> ideas behind flavors is giving the user the choice of where they want\n> >> their messages to be stored. This certainly requires the deployer to\n> >> have installed stores that are good for each job. For example, based on\n> >> the current existing drivers, a deployer could have configured a\n> >> high-throughput flavor on top of a redis node that has been configured\n> >> to perform for this job. Alongside to this flavor, the deployer could\'ve\n> >> configured a flavor that features durability on top of mongodb or redis.\n> >>\n> >> When the user creates the queue/bucket/inbox/whatever they want to put\n> >> their messages into, they\'ll be able to choose where those messages\n> >> should be stored into based on their needs.\n> >>\n> >> I do understand your objection is not against Zaqar being able to do\n> >> this now or not but whether an integrate API for both kind of semantics\n> >> makes sense or not. I still fail to see why they need to be separated,\n> >> though. Billing can still happen properly based on the resource usage,\n> >> flavors and other metrics.\n> >\n> > As long as it can be built into the API that certain flavors don\'t allow\n> > pagination of messages, I can see it working.\n> \n> If the v2 API removes random access to messages, is there any reason for \n> it to allow listing of messages at all? AFAICT the v2 API could \n> eliminate any access to or knowledge about anything but the first \n> unclaimed message in the queue while still satisfying all of the target \n> use cases.\n> \n\nI don\'t think that handles Horizon\'s case. The notifications need to\nstick around, and be acknowledged by the user, and that may not happen\nin order. If it doesn\'t happen, then the messages actually need to be\navailable from the queue again.\n\n> > Also maybe some flavors\n> > are auto-ACK and thus can be backed entirely by AMQP/gearman/etc. without\n> > any special gymnastics to support sessions.\n> \n> That doesn\'t make a lot of sense to me - if you have an extremely high \n> volume of messages and you don\'t care about losing some, just spin up \n> your own AMQP broker on a Nova server. Zaqar offers guaranteed delivery \n> of messages, which at very small scales can only be economically \n> provided by the cloud operator. Users who don\'t care about either of \n> those things have a host of other good, cheap options already. If you \n> just want someone else to administer that for you, then you get the \n> Trove-style queue-provisioning service that was mooted at various points \n> in this thread.\n> \n\nThe issue is how do you ACK messages in AMQP transactions without the\nactive session where the message came from? Since we have a stateless\nHTTP protocol, we need something to maintain that specific AMQP session\nuntil the HTTP protocol receives an ACK from the client after the client\nhas consumed or somehow stored the message. So, these queues have to be\nauto-ACK, or we have to figure out a way to have something maintain the\nsession.\n\n> > However, I tend to think that if one thing is a superset of the other,\n> > they can also be separate, and typically in a scale-out context, if\n> > something can be separate, it should be.\n> \n> AIUI the Zaqar API processes are essentially stateless and defer the \n> storage to some other system encapsulated behind a storage plugin. Given \n> that the storage parts already scale out separately, it doesn\'t follow \n> at all that they should have separate APIs for scale-out reasons.\n> \n\nIf we drop the Horizon use case, I agree.\n\nHowever, if Horizon still wants to show the user all the notifications,\nout of order, and paginated, and ack\'d in different orders (read: the\ninbox use case) then that is, IMO, an entirely separate concern that\nwould basically be the v1 API.\n\n\n','<54173865.30701@redhat.com>',NULL),('<1410816535-sup-3305@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 14:33:34',-25200,'2014-09-15 21:33:34',NULL,'[openstack-dev] [Heat] Defining what is a SupportStatus version','Excerpts from Zane Bitter\'s message of 2014-09-15 09:31:33 -0700:\n> On 14/09/14 11:09, Clint Byrum wrote:\n> > Excerpts from Gauvain Pocentek\'s message of 2014-09-04 22:29:05 -0700:\n> >> Hi,\n> >>\n> >> A bit of background: I\'m working on the publication of the HOT\n> >> resources reference on docs.openstack.org. This book is mostly\n> >> autogenerated from the heat source code, using the sphinx XML output. To\n> >> avoid publishing several references (one per released version, as is\n> >> done for the OpenStack config-reference), I\'d like to add information\n> >> about the support status of each resource (when they appeared, when\n> >> they\'ve been deprecated, and so on).\n> >>\n> >> So the plan is to use the SupportStatus class and its `version`\n> >> attribute (see https://review.openstack.org/#/c/116443/ ). And the\n> >> question is, what information should the version attribute hold?\n> >> Possibilities include the release code name (Icehouse, Juno), or the\n> >> release version (2014.1, 2014.2). But this wouldn\'t be useful for users\n> >> of clouds continuously deployed.\n> >>\n> >>   From my documenter point of view, using the code name seems the right\n> >> option, because it fits with the rest of the documentation.\n> >>\n> >> What do you think would be the best choice from the heat devs POV?\n> >\n> > What we ship in-tree is the standard library for Heat. I think Heat\n> > should not tie things to the release of OpenStack, but only to itself.\n> \n> \"Standard Library\" implies that everyone has it available, but in \n> reality operators can (and will, and do) deploy any combination of \n> resource types that they want.\n> \n\nMmk, I guess I was being too optimistic about how homogeneous OpenStack\nclouds might be.\n\n> > The idea is to simply version the standard library of resources separately\n> > even from the language. Added resources and properties would be minor\n> > bumps, deprecating or removing anything would be a major bump. Users then\n> > just need an API call that allows querying the standard library version.\n> \n> We already have API calls to actually inspect resource types. I don\'t \n> think a semantic version number is helpful here, since the different \n> existing combinations of resources types are not expressible linearly.\n> \n> There\'s no really good answer here, but the only real answer is making \n> sure it\'s easy for people to generate the docs themselves for their \n> actual deployment.\n> \n\nThat\'s an interesting idea. By any chance do we have something that\npublishes the docs directly from source tree into swift? Might make it\neasier if we could just do that as part of code pushes for those who run\nclouds from source.\n\n> > With this scheme, we can provide a gate test that prevents breaking the\n> > rules, and automatically generate the docs still. Doing this would sync\n> > better with continuous deployers who will be running \"Juno\" well before\n> > there is a \"2014.2\".\n> \n> Maybe continuous deployers should continuously deploy their own docs? \n> For any given cloud the only thing that matters is what it supports \n> right now.\n>\n\nThats an interesting idea, but I like what the user wants is to see how\nthis cloud is different than the other clouds.\n\n> > Anyway, Heat largely exists to support portability of apps between\n> > OpenStack clouds. Many many OpenStack clouds don\'t run one release,\n> > and we don\'t require them to do so. So tying to the release is, IMO,\n> > a poor coice.\n> \n> The original question was about docs.openstack.org, and in that context \n> I think tying it to the release version is a good choice, because \n> that\'s... how OpenStack is released. Individual clouds, however, really \n> need to deploy their own docs that document what they actually support.\n> \n\nYeah I hadn\'t thought of that before. I like the idea but I wonder how\npractical it is for CD private clouds.\n\n> The flip side of this, of course, is that whatever we use for the \n> version strings on docs.openstack.org will all make its way into all the \n> other documentation that gets built, and I do understand your point in \n> that context. But versioning the \"standard library\" of plugins as if it \n> were a monolithic, always-available thing seems wrong to me.\n>\n\nYeah I think it is too optimistic in retrospect.\n\n> > We do the same thing with HOT\'s internals, so why not also\n> > do the standard library this way?\n> \n> The current process for HOT is for every OpenStack development cycle \n> (Juno is the first to use this) to give it a \'version\' string that is \n> the expected date of the next release (in the future), and continuous \n> deployers who use the new one before that date are on their own (i.e. \n> it\'s not considered stable). So not really comparable.\n> \n\nI think there\'s a difference between a CD operator making it available,\nand saying they support it. Just like a new API version in OpenStack, it\nmay be there, but they may communicate to users it is alpha until after\nit gets released upstream. I think that is the same for this, and so I\nthink that using the version number is probably fine.\n\n\n','<54171465.6080203@redhat.com>',NULL),('<1410816927-sup-2510@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 21:37:35',0,'2014-09-15 21:37:35',NULL,'[openstack-dev] [tripleo] Adding hp1 back running tripleo CI','This is a total shot in the dark, but a couple of us ran into issues\nwith the Ubuntu Trusty kernel (I know I hit it on HP hardware) that was\ncausing severely degraded performance for TripleO. This fixed with a\nrecently released kernel in Trusty... maybe you could be running into\nthis?\n\n-Greg\n\n> Also its worth noting the test I have been using to compare jobs is the\n> F20 overcloud job, something has happened recently causing this job to\n> run slower then it used to run (possibly upto 30 minutes slower), I\'ll\n> now try to get to the bottom of this. So the times may not end up being\n> as high as referenced above but I\'m assuming the relative differences\n> between the two clouds wont change.\n> \n> thoughts?\n> Derek\n> \n\n\n','<5417113F.2040809@redhat.com>',NULL),('<1410822576-sup-2523@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-15 16:10:29',-25200,'2014-09-15 23:10:29',NULL,'[openstack-dev] [glance][all] Help with interpreting the log\n	level guidelines','Excerpts from Sean Dague\'s message of 2014-09-15 16:02:04 -0700:\n> On 09/15/2014 07:00 PM, Mark Washenberger wrote:\n> > Hi there logging experts,\n> > \n> > We\'ve recently had a little disagreement in the glance team about the\n> > appropriate log levels for http requests that end up failing due to user\n> > errors. An example would be a request to get an image that does not\n> > exist, which results in a 404 Not Found request.\n> > \n> > On one hand, this event is an error, so DEBUG or INFO seem a little too\n> > low. On the other hand, this error doesn\'t generally require any kind of\n> > operator investigation or indicate any actual failure of the service, so\n> > perhaps it is excessive to log it at WARN or ERROR.\n> > \n> > Please provide feedback to help us resolve this dispute if you feel you can!\n> \n> My feeling is this is an INFO level. There is really nothing the admin\n> should care about here.\n\nAgree with Sean. INFO are useful for investigations. WARN and ERROR are\ncause for alarm.\n\n\n','<54176FEC.7080202@dague.net>',NULL),('<1410834749.3545.8.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-16 02:32:29',0,'2014-09-16 02:32:29',NULL,'[openstack-dev] [Octavia] Responsibilities for controller\n drivers','Hi Stephen,\n\nSame drill\n\nOn Mon, 2014-09-15 at 13:33 -0700, Stephen Balukoff wrote:\n> Hi Brandon!\n> \n> \n> My responses in-line:\n> \n> On Fri, Sep 12, 2014 at 11:27 AM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         IN IRC the topic came up about supporting many-to-many load\n>         balancers to\n>         amphorae.  I believe a consensus was made that allowing only\n>         one-to-many\n>         load balancers to amphorae would be the first step forward,\n>         and\n>         re-evaluate later, since colocation and apolocation will need\n>         to work\n>         (which brings up another topic, defining what it actually\n>         means to be\n>         colocated: On the same amphorae, on the same amphorae host, on\n>         the same\n>         cell/cluster, on the same data center/availability zone. That\n>         should be\n>         something we discuss later, but not right now).\n>         \n>         I am fine with that decisions, but Doug brought up a good\n>         point that\n>         this could very well just be a decision for the controller\n>         driver and\n>         Octavia shouldn\'t mandate this for all drivers.  So I think we\n>         need to\n>         clearly define what decisions are the responsibility of the\n>         controller\n>         driver versus what decisions are mandated by Octavia\'s\n>         construct.\n> \n> \n> In my mind, the only thing dictated by the controller to the driver\n> here would be things related to colocation / apolocation. So in order\n> to fully have that discussion here, we first need to have a\n> conversation about what these things actually mean in the context of\n> Octavia and/or get specific requirements from operators here.  The\n> reference driver (ie. haproxy amphora) will of course have to follow a\n> given behavior here as well, and there\'s the possibility that even if\n> we don\'t dictate behavior in one way or another, operators and users\n> may come to expect the behavior of the reference driver here to become\n> the defacto requirements.\n\nSo since with HA we will want apolocation, are you saying the controller\nshould dictate that every driver create a load balancer\'s amphorae on\ndifferent hosts?  I\'m not sure the controller could enforce this, other\nthan code reviews, but I might be a short-sighted here.\n\n>  \n>         \n>         Items I can come up with off the top of my head:\n>         \n>         1) LB:Amphora - M:N vs 1:N\n> \n> \n> My opinion:  For simplicity, first revision should be 1:N, but leave\n> open the possibility of M:N at a later date, depending on what people\n> require. That is to say, we\'ll only do 1:N at first so we can have\n> simpler scheduling algorithms for now, but let\'s not paint ourselves\n> into a corner in other portions of the code by assuming there will\n> only ever be one LB on an amphora.\n\nThis is reasonable.  Of course, this brings up the question on whether\nwe should keep the table structure as is with a M:N relationship.  My\nopinion is we start with the 1:N table structure.  My reasons are in\nresponse to your comment on this review:\n\nhttps://review.openstack.org/#/c/116718/\n\n>  \n>         2) VIPs:LB - M:N vs 1:N\n> \n> \n> So, I would revise that to be N:1 or 1:1. I don\'t think we\'ll ever\n> want to support a case where multiple LBs share the same VIP.\n> (Multiple amphorae per VIP, yes... but not multiple LBs per VIP. LBs\n> are logical constructs that also provide for good separation of\n> concerns, particularly around security.)\n\nYeah sorry about that, brain fart.  Unless we want shareable VIPs!?\nanyone? anyone?\n> \n> \n> The most solid use case for N:1 that I\'ve heard is the IPv6 use case,\n> where a user wants to expose the exact same services over IPv4 and\n> IPv6, and therefore it makes sense to be able to have multiple VIPs\n> per load balancer. (In fact, I\'m not aware of other use cases here\n> that hold any water.) Having said this, we\'re quite a ways from IPv6\n> being ready for use in the underlying networking infrastructure.\n> So...  again, I would say let\'s go with 1:1 for now to make things\n> simple for scheduling, but not paint ourselves into a corner here\n> architecturally in other areas of the code by assuming there will only\n> ever be one VIP per LB.\n\nYeah N:1 every comes up as something we should and can do, we\'ll revisit\nit then.\n> \n> \n>         3) Pool:HMs - 1:N vs 1:1\n> \n> \n> Does anyone have a solid use case for having more than one health\n> monitor per pool?  (And how do you resolve conflicts in health monitor\n> check results?)  I can\'t think of one, so 1:1 has my vote here.\n\nI don\'t know of any strong ones, but it is allowed by some vendors.\n> \n> \n>  \n>         \n>         I\'m sure there are others.  I\'m sure each one will need to be\n>         evaluated\n>         on a case-by-case basis.  We will be walking a fine line\n>         between\n>         flexibility and complexity.  We just need to define how far\n>         over that\n>         line and in which direction we are willing to go.\n>         \n>         Thanks,\n>         Brandon\n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZrJjZ0QgkjrWVAbs1MsBPoW7Ly1R5YD9XD+AB5pMZ=bag@mail.gmail.com>',NULL),('<1410851925.5922.0.camel@dhcp-16-172.nay.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-16 15:18:45',28800,'2014-09-16 07:18:45',NULL,'[openstack-dev] gettext question about oslo.i18n library','Hi Ben,\n  Thanks very much for the information!\n  I moved the blueprint to:\n  https://blueprints.launchpad.net/oslo.i18n/+spec/more-gettext-support\nBest Regards,\n  Peng Wu\n\nOn Tue, 2014-08-26 at 10:05 -0500, Ben Nemec wrote:\n> Hi Peng,\n> \n> We\'re using the spec process described in\n> https://wiki.openstack.org/wiki/Oslo#Design_Proposals to manage\n> blueprints now.  You\'ll need to create a spec review as described in the\n> wiki for this.  Unfortunately, I don\'t think we\'ve opened up Kilo specs\n> yet, so you might want to either wait for just put it in Juno for now\n> and rebase to Kilo when that\'s available.\n> \n> -Ben\n> \n> On 08/26/2014 02:27 AM, Peng Wu wrote:\n> > Hi Doug,\n> > \n> > I created a i18n blueprint for oslo.i18n.\n> > URL:\n> > https://blueprints.launchpad.net/openstack-i18n/+spec/more-gettext-supports\n> > \n> > Could you review it?\n> > \n> > I am reading django gettext code, I think I will use a similar approach\n> > for the \"contextual markers\" gettext function.\n> > \n> > Thanks,\n> >   Peng Wu\n> > \n> > On Mon, 2014-08-18 at 10:05 -0400, Doug Hellmann wrote:\n> >> Yes, that would be a good next step.\n> >>\n> >> Doug\n> >>\n> >> On Aug 17, 2014, at 10:03 PM, Peng Wu <peng.e.wu at gmail.com> wrote:\n> >>\n> >>>  Yes, I am interested in adding these missing gettext functions to\n> >>> oslo.i18n library.\n> >>>\n> >>>  Guess the next step is to create a blueprint for Kilo?\n> >>>\n> >>> Thanks,\n> >>>  Peng Wu\n> >>>\n> >>>\n> >>> On Fri, 2014-08-15 at 16:02 -0400, Doug Hellmann wrote:\n> >>>> On Aug 15, 2014, at 3:18 AM, Peng Wu <peng.e.wu at gmail.com> wrote:\n> >>>>\n> >>>>> Hi,\n> >>>>>\n> >>>>> Recently I just read the code of oslo.i18n library,\n> >>>>> The lazy translation idea is great!\n> >>>>>\n> >>>>> But I found a question about gettext \"contextual markers\"\n> >>>>> and \"plural form\", such as pgettext and ungettext functions,\n> >>>>> see [3].\n> >>>>>\n> >>>>> It seems the two gettext functions are missing in the oslo.i18n\n> >>>>> library.\n> >>>>> Is it correct? or will support it?\n> >>>>>\n> >>>>> Thanks,\n> >>>>> Peng Wu\n> >>>>\n> >>>> You?re right, those are not present.\n> >>>>\n> >>>> We apparently haven?t used them anywhere, yet, because they weren?t exposed via the old gettextutils module in the incubator. We should add them. Are you interested in working on a blueprint for Kilo to do that?\n> >>>>\n> >>>> Doug\n> >>>>\n> >>>>>\n> >>>>> Refer URL:\n> >>>>> 1. https://github.com/openstack/oslo.i18n\n> >>>>> 2.\n> >>>>> http://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html\n> >>>>> 3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings\n> >>>>>\n> >>>>>\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<53FCA225.2080800@nemebean.com>',NULL),('<1410852a158.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 07:42:17',-25200,'2013-09-10 14:42:17',NULL,'[Openstack] Why GlusterFS should not be integrated with\n	OpenStack','I\'m an architect at Nexenta. So not surprisingly I fully agree that Gluster \nis a poor choice for storage in OpenStack.\n\nHowever the real question is what criteria storage vendors should be judged \nby the project. These should be\nclearly stated and easily verified. Once compliance is dealt with, judging \nthe quality of specific solutions and\ntheir suitability to specific needs is something that the end users should \ndo, not the openstack project.\n\nThe Cinder project has set minimum standards for Volume Drivers for the \nHavana release. Those standards should be applied without debating their \nspecifics for Gluster on the mailing list.\n\nStorage vendors are used to dealing with certification processes. We know \nhow to deal with rules that state your software must do X and Y by date Z.\n\nI would be in full agreement, however, that OpenStack should not \naccommodate an API tailored to Gluster\'s unique architecture.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130910/5021a95c/attachment.html>\n\n','<CAMUFnfYvr24GkOA_j_yx4qpGVSk-Oii1TLN7hTsfN2kNXQpvYA@mail.gmail.com>',NULL),('<1410872162.33.1385705243130.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-29 06:07:22',0,'2013-11-29 06:07:22',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-all-stable-havana #6','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all-stable-havana/6/>\n\n------------------------------------------\n[...truncated 11943 lines...]\n2013-11-29 06:06:03 + [[ -z deb ]]\n2013-11-29 06:06:03 + \'[\' deb = deb \']\'\n2013-11-29 06:06:03 + sudo mysql -uroot -psecret -h127.0.0.1 -e \'GRANT ALL PRIVILEGES ON *.* TO \'\\\'\'root\'\\\'\'@\'\\\'\'%\'\\\'\' identified by \'\\\'\'secret\'\\\'\';\'\n2013-11-29 06:06:03 + sudo sed -i \'/^bind-address/s/127.0.0.1/0.0.0.0/g\' /etc/mysql/my.cnf\n+ exec\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-11-29 06:06:06 + sudo grep -q default-storage-engine /etc/mysql/my.cnf\n+ exec\n2013-11-29 06:06:06 + sudo sed -i -e \'/^\\[mysqld\\]/ a default-storage-engine = InnoDB\' /etc/mysql/my.cnf\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-11-29 06:06:06 + sudo sed -i /log.slow.queries/d /etc/mysql/my.cnf\n2013-11-29 06:06:06 + sudo sed -i -e \'/^\\[mysqld\\]/ a log-slow-queries = /var/log/mysql/mysql-slow.log\' /etc/mysql/my.cnf\n2013-11-29 06:06:06 + sudo sed -i /long.query.time/d /etc/mysql/my.cnf\n2013-11-29 06:06:06 + sudo sed -i -e \'/^\\[mysqld\\]/ a long-query-time = 0\' /etc/mysql/my.cnf\n2013-11-29 06:06:06 + sudo sed -i /log.queries.not.using.indexes/d /etc/mysql/my.cnf\n2013-11-29 06:06:06 + sudo sed -i -e \'/^\\[mysqld\\]/ a log-queries-not-using-indexes\' /etc/mysql/my.cnf\n2013-11-29 06:06:06 + restart_service mysql\n2013-11-29 06:06:06 + is_ubuntu\n2013-11-29 06:06:06 + [[ -z deb ]]\n2013-11-29 06:06:06 + \'[\' deb = deb \']\'\n2013-11-29 06:06:06 + sudo /usr/sbin/service mysql restart\n2013-11-29 06:06:06 mysql stop/waiting\n2013-11-29 06:06:06 mysql start/running, process 15238\n2013-11-29 06:06:06 ++ trueorfalse True False\n2013-11-29 06:06:06 ++ local default=True\n2013-11-29 06:06:06 ++ local testval=False\n2013-11-29 06:06:06 ++ [[ -z False ]]\n2013-11-29 06:06:06 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-11-29 06:06:06 ++ echo False\n2013-11-29 06:06:06 ++ return\n2013-11-29 06:06:06 + USE_SCREEN=False\n2013-11-29 06:06:06 + [[ False == \\T\\r\\u\\e ]]\n2013-11-29 06:06:06 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-11-29 06:06:06 + [[ -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-11-29 06:06:06 + init_service_check\n2013-11-29 06:06:06 + SCREEN_NAME=stack\n2013-11-29 06:06:06 + SERVICE_DIR=/opt/stack/new/status\n2013-11-29 06:06:06 + [[ ! -d /opt/stack/new/status/stack ]]\n2013-11-29 06:06:06 + mkdir -p /opt/stack/new/status/stack\n2013-11-29 06:06:06 + rm -f \'/opt/stack/new/status/stack/*.failure\'\n2013-11-29 06:06:06 + is_service_enabled sysstat\n2013-11-29 06:06:06 + services=sysstat\n2013-11-29 06:06:06 + for service in \'${services}\'\n2013-11-29 06:06:06 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,sysstat, ]]\n2013-11-29 06:06:06 + return 0\n2013-11-29 06:06:06 + [[ -n /opt/stack/new/screen-logs ]]\n2013-11-29 06:06:06 + screen_it sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:06 + SCREEN_NAME=stack\n2013-11-29 06:06:06 + SERVICE_DIR=/opt/stack/new/status\n2013-11-29 06:06:06 ++ trueorfalse True False\n2013-11-29 06:06:06 ++ local default=True\n2013-11-29 06:06:06 ++ local testval=False\n2013-11-29 06:06:06 ++ [[ -z False ]]\n2013-11-29 06:06:06 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-11-29 06:06:06 ++ echo False\n2013-11-29 06:06:06 ++ return\n2013-11-29 06:06:06 + USE_SCREEN=False\n2013-11-29 06:06:06 + is_service_enabled sysstat\n2013-11-29 06:06:06 + services=sysstat\n2013-11-29 06:06:06 + for service in \'${services}\'\n2013-11-29 06:06:06 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,sysstat, ]]\n2013-11-29 06:06:06 + return 0\n2013-11-29 06:06:06 + screen_rc sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:06 + SCREEN_NAME=stack\n2013-11-29 06:06:06 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-11-29 06:06:06 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-11-29 06:06:06 + echo \'sessionname stack\'\n2013-11-29 06:06:07 + echo \'hardstatus alwayslastline \'\\\'\'\'\\\'\'\'\n2013-11-29 06:06:07 + echo \'setenv PROMPT_COMMAND /bin/true\'\n2013-11-29 06:06:07 + echo \'screen -t shell bash\'\n2013-11-29 06:06:07 + grep sysstat /opt/stack/new/devstack/stack-screenrc\n2013-11-29 06:06:07 ++ echo -ne \'\\015\'\n2013-11-29 06:06:07 + NL=$\'\\r\'\n2013-11-29 06:06:07 + echo \'screen -t sysstat bash\'\n2013-11-29 06:06:07 + echo \'stuff \"sar -o /opt/stack/new/screen-logs/sysstat.dat 1\n\"\'\n2013-11-29 06:06:07 + [[ False = \\T\\r\\u\\e ]]\n2013-11-29 06:06:07 + run_process sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:07 + local service=sysstat\n2013-11-29 06:06:07 + local \'command=sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:07 + echo 15903\n2013-11-29 06:06:07 + _run_process sysstat \'sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:07 + local service=sysstat\n2013-11-29 06:06:07 + local \'command=sar -o /opt/stack/new/screen-logs/sysstat.dat 1\'\n2013-11-29 06:06:07 + exec\n2013-11-29 06:06:07 + exec\n2013-11-29 06:06:07 + is_service_enabled key\n2013-11-29 06:06:07 + services=key\n2013-11-29 06:06:07 + for service in \'${services}\'\n2013-11-29 06:06:07 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,key, ]]\n2013-11-29 06:06:07 + return 0\n2013-11-29 06:06:07 + echo_summary \'Starting Keystone\'\n2013-11-29 06:06:07 + [[ -t 3 ]]\n2013-11-29 06:06:07 + echo -e Starting Keystone\n2013-11-29 06:06:07 Starting Keystone\n2013-11-29 06:06:07 + init_keystone\n2013-11-29 06:06:07 + recreate_database keystone utf8\n2013-11-29 06:06:07 + local db=keystone\n2013-11-29 06:06:07 + local charset=utf8\n2013-11-29 06:06:07 + recreate_database_mysql keystone utf8\n2013-11-29 06:06:07 + local db=keystone\n2013-11-29 06:06:07 + local charset=utf8\n2013-11-29 06:06:07 + mysql -uroot -psecret -h127.0.0.1 -e \'DROP DATABASE IF EXISTS keystone;\'\n2013-11-29 06:06:07 + mysql -uroot -psecret -h127.0.0.1 -e \'CREATE DATABASE keystone CHARACTER SET utf8;\'\n2013-11-29 06:06:07 + /opt/stack/new/keystone/bin/keystone-manage db_sync\n2013-11-29 06:06:07 + [[ PKI == \\P\\K\\I ]]\n2013-11-29 06:06:07 + rm -rf /etc/keystone/ssl\n2013-11-29 06:06:07 + /opt/stack/new/keystone/bin/keystone-manage pki_setup\n2013-11-29 06:06:07 2013-11-29 06:06:06.450 15991 INFO keystone.common.openssl [-] openssl genrsa -out /etc/keystone/ssl/certs/cakey.pem 2048\n2013-11-29 06:06:07 Generating RSA private key, 2048 bit long modulus\n2013-11-29 06:06:07 ..+++\n2013-11-29 06:06:07 ......................................................+++\n2013-11-29 06:06:07 e is 65537 (0x10001)\n2013-11-29 06:06:07 2013-11-29 06:06:06.628 15991 INFO keystone.common.openssl [-] openssl req -new -x509 -extensions v3_ca -key /etc/keystone/ssl/certs/cakey.pem -out /etc/keystone/ssl/certs/ca.pem -days 3650 -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com\n2013-11-29 06:06:07 2013-11-29 06:06:06.643 15991 INFO keystone.common.openssl [-] openssl genrsa -out /etc/keystone/ssl/private/signing_key.pem 2048 \n2013-11-29 06:06:07 Generating RSA private key, 2048 bit long modulus\n2013-11-29 06:06:07 ..................+++\n2013-11-29 06:06:07 ........................+++\n2013-11-29 06:06:07 e is 65537 (0x10001)\n2013-11-29 06:06:07 2013-11-29 06:06:06.779 15991 INFO keystone.common.openssl [-] openssl req -key /etc/keystone/ssl/private/signing_key.pem -new -out /etc/keystone/ssl/certs/req.pem -config /etc/keystone/ssl/certs/openssl.conf -subj /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com\n2013-11-29 06:06:07 2013-11-29 06:06:06.794 15991 INFO keystone.common.openssl [-] openssl ca -batch -out /etc/keystone/ssl/certs/signing_cert.pem -config /etc/keystone/ssl/certs/openssl.conf -days 3650d -cert /etc/keystone/ssl/certs/ca.pem -keyfile /etc/keystone/ssl/certs/cakey.pem -infiles /etc/keystone/ssl/certs/req.pem\n2013-11-29 06:06:07 Using configuration from /etc/keystone/ssl/certs/openssl.conf\n2013-11-29 06:06:07 Check that the request matches the signature\n2013-11-29 06:06:07 Signature ok\n2013-11-29 06:06:07 The Subject\'s Distinguished Name is as follows\n2013-11-29 06:06:07 countryName           :PRINTABLE:\'US\'\n2013-11-29 06:06:07 stateOrProvinceName   :ASN.1 12:\'Unset\'\n2013-11-29 06:06:07 localityName          :ASN.1 12:\'Unset\'\n2013-11-29 06:06:07 organizationName      :ASN.1 12:\'Unset\'\n2013-11-29 06:06:07 commonName            :ASN.1 12:\'www.example.com\'\n2013-11-29 06:06:07 Certificate is to be certified until Nov 27 06:06:06 2023 GMT (3650 days)\n2013-11-29 06:06:07 \n2013-11-29 06:06:07 Write out database with 1 new entries\n2013-11-29 06:06:07 Data Base Updated\n2013-11-29 06:06:07 + sudo mkdir -p /var/cache/keystone\n2013-11-29 06:06:07 + sudo chown stack /var/cache/keystone\n2013-11-29 06:06:07 + rm -f \'/var/cache/keystone/*\'\n2013-11-29 06:06:07 + start_keystone\n2013-11-29 06:06:07 + local service_port=5000\n2013-11-29 06:06:07 + is_service_enabled tls-proxy\n2013-11-29 06:06:07 + services=tls-proxy\n2013-11-29 06:06:07 + for service in \'${services}\'\n2013-11-29 06:06:07 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,tls-proxy, ]]\n2013-11-29 06:06:07 + [[ tls-proxy == n-cell-* ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\n\\o\\v\\a ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\c\\i\\n\\d\\e\\r ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\g\\l\\a\\n\\c\\e ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\n\\e\\u\\t\\r\\o\\n ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\t\\r\\o\\v\\e ]]\n2013-11-29 06:06:07 + [[ tls-proxy == \\s\\w\\i\\f\\t ]]\n2013-11-29 06:06:07 + [[ tls-proxy == s-* ]]\n2013-11-29 06:06:07 + return 1\n2013-11-29 06:06:07 + is_apache_enabled_service key\n2013-11-29 06:06:07 + services=key\n2013-11-29 06:06:07 + for service in \'${services}\'\n2013-11-29 06:06:07 + [[ ,, =~ ,key, ]]\n2013-11-29 06:06:07 + return 1\n2013-11-29 06:06:07 + screen_it key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:06:07 + SCREEN_NAME=stack\n2013-11-29 06:06:07 + SERVICE_DIR=/opt/stack/new/status\n2013-11-29 06:06:07 ++ trueorfalse True False\n2013-11-29 06:06:07 ++ local default=True\n2013-11-29 06:06:07 ++ local testval=False\n2013-11-29 06:06:07 ++ [[ -z False ]]\n2013-11-29 06:06:07 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-11-29 06:06:07 ++ echo False\n2013-11-29 06:06:07 ++ return\n2013-11-29 06:06:07 + USE_SCREEN=False\n2013-11-29 06:06:07 + is_service_enabled key\n2013-11-29 06:06:07 + services=key\n2013-11-29 06:06:07 + for service in \'${services}\'\n2013-11-29 06:06:07 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,key, ]]\n2013-11-29 06:06:07 + return 0\n2013-11-29 06:06:07 + screen_rc key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:06:07 + SCREEN_NAME=stack\n2013-11-29 06:06:07 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-11-29 06:06:07 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-11-29 06:07:06 + grep key /opt/stack/new/devstack/stack-screenrc\n2013-11-29 06:07:06 ++ echo -ne \'\\015\'\n2013-11-29 06:07:06 + NL=$\'\\r\'\n2013-11-29 06:07:06 + echo \'screen -t key bash\'\n2013-11-29 06:07:06 + echo \'stuff \"cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\n\"\'\n2013-11-29 06:07:06 + [[ False = \\T\\r\\u\\e ]]\n2013-11-29 06:07:06 + run_process key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:07:06 + local service=key\n2013-11-29 06:07:06 + local \'command=cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:07:06 + echo 16013\n2013-11-29 06:07:06 + _run_process key \'cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:07:06 + echo \'Waiting for keystone to start...\'\n2013-11-29 06:07:06 Waiting for keystone to start...\n2013-11-29 06:07:06 + timeout 60 sh -c \'while ! curl --noproxy \'\\\'\'*\'\\\'\' -s http://127.0.0.1:5000/v2.0/ >/dev/null; do sleep 1; done\'\n2013-11-29 06:07:06 + local service=key\n2013-11-29 06:07:06 + local \'command=cd /opt/stack/new/keystone && /opt/stack/new/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf --log-config /etc/keystone/logging.conf -d --debug\'\n2013-11-29 06:07:06 + exec\n2013-11-29 06:07:06 + exec\n2013-11-29 06:07:06 + die 376 \'keystone did not start\'\n2013-11-29 06:07:06 + local exitcode=0\n2013-11-29 06:07:06 + set +o xtrace\n2013-11-29 06:07:06 [Call Trace]\n2013-11-29 06:07:06 ./stack.sh:859:start_keystone\n2013-11-29 06:07:06 /opt/stack/new/devstack/lib/keystone:376:die\n2013-11-29 06:07:06 [ERROR] /opt/stack/new/devstack/lib/keystone:376 keystone did not start\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-762616-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-762616.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all-stable-havana/devstack-precise-hpcloud-az1-762616/6/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1410888134.291822244@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-09-16 12:22:14',-18000,'2014-09-16 17:22:14',NULL,'[openstack-community] OpenStack Interop Opportunities','An HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140916/a3040ef2/attachment-0001.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: Interop and Cloud Connect New_York_2014_OpenStack Boot Camp marketing proposal 090914.pdf\nType: application/pdf\nSize: 523631 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140916/a3040ef2/attachment-0001.pdf>\n\n',NULL,NULL),('<1410937454.56431.YahooMailNeo@web160301.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-17 00:04:14',-25200,'2014-09-17 07:04:14',NULL,'[Openstack-docs] Review #119980','Hi everyone,\n\nI\'ve submitted a patch which addresses a bug in the Havana documentation:\nhttps://review.openstack.org/#/c/119980/\n\n\nCan anyone confirm if this change can also be committed to master?\n\nCheers,\nDarren\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140917/d140e7ef/attachment.html>\n\n',NULL,NULL),('<1410938658.16393.11.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 09:24:18',7200,'2014-09-17 07:24:18',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n and \"ready state\" orchestration','On Tue, 2014-09-16 at 15:42 -0400, Zane Bitter wrote:\n> On 16/09/14 15:24, Devananda van der Veen wrote:\n> > On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter <zbitter at redhat.com> wrote:\n> >> On 16/09/14 13:56, Devananda van der Veen wrote:\n> >>>\n> >>> On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy <shardy at redhat.com> wrote:\n> >>>>\n> >>>> For example, today, I\'ve been looking at the steps required for driving\n> >>>> autodiscovery:\n> >>>>\n> >>>> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno\n> >>>>\n> >>>> Driving this process looks a lot like application orchestration:\n> >>>>\n> >>>> 1. Take some input (IPMI credentials and MAC addresses)\n> >>>> 2. Maybe build an image and ramdisk(could drop credentials in)\n> >>>> 3. Interact with the Ironic API to register nodes in maintenance mode\n> >>>> 4. Boot the nodes, monitor state, wait for a signal back containing some\n> >>>>      data obtained during discovery (same as WaitConditions or\n> >>>>      SoftwareDeployment resources in Heat..)\n> >>>> 5. Shutdown the nodes and mark them ready for use by nova\n> >>>>\n> >>>\n> >>> My apologies if the following sounds snarky -- but I think there are a\n> >>> few misconceptions that need to be cleared up about how and when one\n> >>> might use Ironic. I also disagree that 1..5 looks like application\n> >>> orchestration. Step 4 is a workflow, which I\'ll go into in a bit, but\n> >>> this doesn\'t look at all like describing or launching an application\n> >>> to me.\n> >>\n> >>\n> >> +1 (Although step 3 does sound to me like something that matches Heat\'s\n> >> scope.)\n> >\n> > I think it\'s a simplistic use case, and Heat supports a lot more\n> > complexity than is necessary to enroll nodes with Ironic.\n> >\n> >>\n> >>> Step 1 is just parse a text file.\n> >>>\n> >>> Step 2 should be a prerequisite to doing -anything- with Ironic. Those\n> >>> images need to be built and loaded in Glance, and the image UUID(s)\n> >>> need to be set on each Node in Ironic (or on the Nova flavor, if going\n> >>> that route) after enrollment. Sure, Heat can express this\n> >>> declaratively (ironic.node.driver_info must contain key:deploy_kernel\n> >>> with value:NNNN), but are you suggesting that Heat build the images,\n> >>> or just take the UUIDs as input?\n> >>>\n> >>> Step 3 is, again, just parse a text file\n> >>>\n> >>> I\'m going to make an assumption here [*], because I think step 4 is\n> >>> misleading. You shouldn\'t \"boot a node\" using Ironic -- you do that\n> >>> through Nova. And you _dont_ get to specify which node you\'re booting.\n> >>> You ask Nova to provision an _instance_ on a _flavor_ and it picks an\n> >>> available node from the pool of nodes that match the request.\n> >>\n> >>\n> >> I think your assumption is incorrect. Steve is well aware that provisioning\n> >> a bare-metal Ironic server is done through the Nova API. What he\'s\n> >> suggesting here is that the nodes would be booted - not Nova-booted, but\n> >> booted in the sense of having power physically applied - while in\n> >> maintenance mode in order to do autodiscovery of their capabilities,\n> >\n> > Except simply applying power doesn\'t, in itself, accomplish anything\n> > besides causing the machine to power on. Ironic will only prepare the\n> > PXE boot environment when initiating a _deploy_.\n> \n>  From what I gather elsewhere in this thread, the autodiscovery stuff is \n> a proposal for the future, not something that exists in Ironic now, and \n> that may be the source of the confusion.\n> \n> In any case, the etherpad linked at the top of this email was written by \n> someone in the Ironic team and _clearly_ describes PXE booting a \n> \"discovery image\" in maintenance mode in order to obtain hardware \n> information about the box.\nIf was written by me and it seems to be my fault that I didn\'t state\nthere more clear that this work is not and probably will not be merged\ninto Ironic upstream. Sorry for the confusion.\n\nThat said, my experiments proved quite possible (though not without some\nnetwork-related hacks as of now) to follow these steps to collect (aka\ndiscover) hardware information required for scheduling from a node,\nknowing only it\'s IPMI credentials.\n\n> \n> cheers,\n> Zane.\n> \n> >> which\n> >> is presumably hard to do automatically when they\'re turned off.\n> >\n> > Vendors often have ways to do this while the power is turned off, eg.\n> > via the OOB management interface.\n> >\n> >> He\'s also\n> >> suggesting that Heat could drive this process, which I happen to disagree\n> >> with because it is a workflow not an end state.\n> >\n> > +1\n> >\n> >> However the main takeaway\n> >> here is that you guys are talking completely past one another, and have been\n> >> for some time.\n> >>\n> >\n> > Perhaps more detail in the expected interactions with Ironic would be\n> > helpful and avoid me making (perhaps incorrect) assumptions.\n> >\n> > -D\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<541892C0.8070907@redhat.com>',NULL),('<1410953316.21766.6.camel@dhcp130-200.brq.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 13:28:36',7200,'2014-09-17 11:28:36',NULL,'[openstack-dev] [tripleo][heat][ironic] Heat Ironic resources\n and \"ready state\" orchestration','On Wed, 2014-09-17 at 10:36 +0100, Steven Hardy wrote:\n> On Tue, Sep 16, 2014 at 02:06:59PM -0700, Devananda van der Veen wrote:\n> > On Tue, Sep 16, 2014 at 12:42 PM, Zane Bitter <zbitter at redhat.com> wrote:\n> > > On 16/09/14 15:24, Devananda van der Veen wrote:\n> > >>\n> > >> On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter <zbitter at redhat.com> wrote:\n> > >>>\n> > >>> On 16/09/14 13:56, Devananda van der Veen wrote:\n> > >>>>\n> > >>>>\n> > >>>> On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy <shardy at redhat.com> wrote:\n> > >>>>>\n> > >>>>>\n> > >>>>> For example, today, I\'ve been looking at the steps required for driving\n> > >>>>> autodiscovery:\n> > >>>>>\n> > >>>>> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno\n> > >>>>>\n> > >>>>> Driving this process looks a lot like application orchestration:\n> > >>>>>\n> > >>>>> 1. Take some input (IPMI credentials and MAC addresses)\n> > >>>>> 2. Maybe build an image and ramdisk(could drop credentials in)\n> > >>>>> 3. Interact with the Ironic API to register nodes in maintenance mode\n> > >>>>> 4. Boot the nodes, monitor state, wait for a signal back containing\n> > >>>>> some\n> > >>>>>      data obtained during discovery (same as WaitConditions or\n> > >>>>>      SoftwareDeployment resources in Heat..)\n> > >>>>> 5. Shutdown the nodes and mark them ready for use by nova\n> > >>>>>\n> > >>>>\n> > >>>> My apologies if the following sounds snarky -- but I think there are a\n> > >>>> few misconceptions that need to be cleared up about how and when one\n> > >>>> might use Ironic. I also disagree that 1..5 looks like application\n> > >>>> orchestration. Step 4 is a workflow, which I\'ll go into in a bit, but\n> > >>>> this doesn\'t look at all like describing or launching an application\n> > >>>> to me.\n> > >>>\n> > >>>\n> > >>>\n> > >>> +1 (Although step 3 does sound to me like something that matches Heat\'s\n> > >>> scope.)\n> > >>\n> > >>\n> > >> I think it\'s a simplistic use case, and Heat supports a lot more\n> > >> complexity than is necessary to enroll nodes with Ironic.\n> > >>\n> > >>>\n> > >>>> Step 1 is just parse a text file.\n> > >>>>\n> > >>>> Step 2 should be a prerequisite to doing -anything- with Ironic. Those\n> > >>>> images need to be built and loaded in Glance, and the image UUID(s)\n> > >>>> need to be set on each Node in Ironic (or on the Nova flavor, if going\n> > >>>> that route) after enrollment. Sure, Heat can express this\n> > >>>> declaratively (ironic.node.driver_info must contain key:deploy_kernel\n> > >>>> with value:NNNN), but are you suggesting that Heat build the images,\n> > >>>> or just take the UUIDs as input?\n> > >>>>\n> > >>>> Step 3 is, again, just parse a text file\n> > >>>>\n> > >>>> I\'m going to make an assumption here [*], because I think step 4 is\n> > >>>> misleading. You shouldn\'t \"boot a node\" using Ironic -- you do that\n> > >>>> through Nova. And you _dont_ get to specify which node you\'re booting.\n> > >>>> You ask Nova to provision an _instance_ on a _flavor_ and it picks an\n> > >>>> available node from the pool of nodes that match the request.\n> > >>>\n> > >>>\n> > >>>\n> > >>> I think your assumption is incorrect. Steve is well aware that\n> > >>> provisioning\n> > >>> a bare-metal Ironic server is done through the Nova API. What he\'s\n> > >>> suggesting here is that the nodes would be booted - not Nova-booted, but\n> > >>> booted in the sense of having power physically applied - while in\n> > >>> maintenance mode in order to do autodiscovery of their capabilities,\n> > >>\n> > >>\n> > >> Except simply applying power doesn\'t, in itself, accomplish anything\n> > >> besides causing the machine to power on. Ironic will only prepare the\n> > >> PXE boot environment when initiating a _deploy_.\n> > >\n> > >\n> > > From what I gather elsewhere in this thread, the autodiscovery stuff is a\n> > > proposal for the future, not something that exists in Ironic now, and that\n> > > may be the source of the confusion.\n> > >\n> > > In any case, the etherpad linked at the top of this email was written by\n> > > someone in the Ironic team and _clearly_ describes PXE booting a \"discovery\n> > > image\" in maintenance mode in order to obtain hardware information about the\n> > > box.\n> > >\n> > \n> > Huh. I should have looked at that earlier in the discussion. It is\n> > referring to out-of-tree code whose spec was not approved during Juno.\n> > \n> > Apparently, and unfortunately, throughout much of this discussion,\n> > folks have been referring to potential features Ironic might someday\n> > have, whereas I have been focused on the features we actually support\n> > today. That is probably why it seems we are \"talking past each other.\"\n> \n> FWIW I think a big part of the problem has been that you\'ve been focussing\n> on the fact that my solution doesn\'t match your preconceived ideas of how\n> Ironic should interface with the world, while completely ignoring the\n> use-case, e.g the actual problem I\'m trying to solve.\n> \n> That is why I\'m referring to features Ironic might someday have - because\n> Ironic currently does not solve my problem, so I\'m looking for a workable\n> way to change that.\n> \n> When I posted the draft Ironic resources, I did fail to provide detailed\n> use-case info, so my bad there, but since I\'ve posted the spec I don\'t\n> really feel like the discussion has been much more productive - I\'ve tried,\n> repeatedly, to get you to understand my use-case, and you\'ve tried,\n> repeatedly, to tell me my implementation is wrong (without providing any\n> fully-formed alternative, I call this \"unqualified your-idea-sucks\", a\n> common and destructive review anti-pattern IMO)\n> \n> It wasn\'t until Jay Faulkner\'s message earlier in this thread that someone\n> actually proposed a possible (partial) alternative solution to the \"ready\n> state\" use case, and that isn\'t implemented at all in Ironic yet.\n> \n> Maybe referring to stuff like autodiscovery was a mistake, but I was just\n> trying to highlight that there are some interesting and potentially\n> innovative possiblities which could be explored, if we had some Ironic heat\n> resources.  It sounds like doing the whole autodiscovery thing in bash is\n> what folks prefer, which is fine, nothing stops them doing that regardless\n> of anything we do in Heat.\n> \n> Anyway, lets try to summarize the key points and capture the main\n> work-items:\n> \n> 1. Not everyone will have an enterprise CMDB, so there should be some way\n> to input inventory without one (even if it is a text file fed into\n> ironicclient). The bulk-loading format to do this is TBD.\n> \n> 2. A way to generate that inventory in an automated way is desirable for\n> some folks, but looks likely to be out-of-scope for Ironic.  Folks are -1\n> on using heat to drive this process, so we\'ll probably end up with some\n> scary shell scripts instead, or maybe a mistral workflow in future.\nWell, IMO we need it at least for TripleO, whether in Ironic or not.\nWhat\'s the point of having OpenStack deploy OpenStack, if in the middle\nwe\'ll ask operators to use scripts/some CMDB to make Ironic node\ndatabase ready-to-use?\n\n> \n> 3. Vendor-specific optimization of nodes for particular roles will be\n> handled via Ironic drivers, which expose capabilities which can be selected\n> via nova flavors. (is there a BP for this?)\n> \n> 4. Stuff like RAID configuration will be handled via in-band config\n> management tools, nobody has offered any solution for using management\n> interfaces to do this, and drac-raid-mgmt is unlikely to land in Ironic\n> (where would such an interface be appropriate then?)\n> \n> 5. Nobody has offered any solution for management and convergence of BIOS\n> and firmware levels (would this be part of the Ironic driver mentioned in\n> (3), or are we punting the entire problem to in-band provision-time tooling?)\nBy the way, these 3 points are important to multi-tenant baremetals in\nthe future. Can Ironic rely on some tooling to assure that tenant has\nleft the hardware in a usable state? I don\'t think so. For me it\'s part\nof Ironic lifecycle management.\n\n> \n> If anyone can help by providing existing BP\'s related to the above (which I\n> can follow and/or contribute to) that would be great - I\'m happy to drop\n> the whole Heat resource thing, but only if there\'s a clear path to solving\n> the problems in some other/better way.\n> \n> Thanks,\n> \n> Steve\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20140917093617.GB17326@t430slt.redhat.com>',NULL),('<1410957543.7225.47.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-09-17 13:39:03',3600,'2014-09-17 12:39:03',NULL,'[openstack-tc] [Fwd: Re: [OpenStack-DefCore] Updated Bylaws]','Hey\n\nI think TC members should be paying closer attention to proposed bylaws\nchanges. See my concerns below. I\'ve uploaded what I think are the\nlatest proposed changes to here:\n\nhttps://wiki.openstack.org/wiki/File:Change-Pro_Redline_-_233015232-v15-OpenStackFoundation_Bylaws_FINAL_%28as_amended_September_7,_2012%29_and_233015232-v24-OpenStackFoundation_Bylaws_FINAL_.pdf\n\nMark.\n-------------- next part --------------\nAn embedded message was scrubbed...\nFrom: Mark McLoughlin <markmc at redhat.com>\nSubject: Re: [OpenStack-DefCore] Updated Bylaws\nDate: Wed, 17 Sep 2014 13:22:14 +0100\nSize: 9098\nURL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20140917/5d5c9ad2/attachment.mht>\n\n',NULL,NULL),('<1410969556.8806.52.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-09-17 16:59:16',3600,'2014-09-17 15:59:16',NULL,'[openstack-tc] [Fwd: Re: [OpenStack-DefCore] Updated Bylaws]','On Wed, 2014-09-17 at 09:34 -0400, Sean Dague wrote:\n> On 09/17/2014 08:39 AM, Mark McLoughlin wrote:\n> > Hey\n> > \n> > I think TC members should be paying closer attention to proposed bylaws\n> > changes. See my concerns below. I\'ve uploaded what I think are the\n> > latest proposed changes to here:\n> > \n> > https://wiki.openstack.org/wiki/File:Change-Pro_Redline_-_233015232-v15-OpenStackFoundation_Bylaws_FINAL_%28as_amended_September_7,_2012%29_and_233015232-v24-OpenStackFoundation_Bylaws_FINAL_.pdf\n> > \n\n> I\'m not on the defcore list so I didn\'t see this. Is there a reason this\n> didn\'t go to the foundation list?\n\nJosh dragged it from a private thread onto defcore. My guess is it was\nintended to be sent to the foundation list *after* the board had\ndiscussed it? That would not be my preferred approach.\n\n> I\'m actually quite concerned by the removal of the TC authority to\n> define the integrated release in a downwards direction without board\n> approval.\n\nThe only *intended* change in TC authority AFAICT is that we would have\nto get sign-off from the board to remote Core modules from the\nIntegrated Release. I understand the intent with that, but it smells of\n\"we can\'t trust the TC to make good decisions\" oversight.\n\nMark.\n\n\n\n','<54198DF0.7080802@dague.net>',NULL),('<1410973221-sup-7985@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 10:05:28',-25200,'2014-09-17 17:05:28',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','This is where Debian\'s \"one urllib3 to rule them all\" model fails in\na modern fast paced world. Debian is arguably doing the right thing by\npushing everyone to use one API, and one library, so that when that one\nlibrary is found to be vulnerable to security problems, one update covers\neveryone. Also, this is an HTTP/HTTPS library.. so nobody can make the\nargument that security isn\'t paramount in this context.\n\nBut we all know that the \"app store\" model has started to bleed down into\nbackend applications, and now you just ship the virtualenv or docker\ncontainer that has your app as you tested it, and if that means you\'re\n20 versions behind on urllib3, that\'s your problem, not the OS vendor\'s.\n\nI think it is _completely_ irresponsible of requests, a library, to\nembed another library. But I don\'t know if we can avoid making use of\nit if we are going to be exposed to objects that are attached to it.\n\nAnyway, Thomas, if you\'re going to send the mob with pitchforks and\ntorches somewhere, I\'d say send them to wherever requests makes its\nhome. OpenStack is just buying their mutated product.\n\nExcerpts from Donald Stufft\'s message of 2014-09-17 08:22:48 -0700:\n> Looking at the code on my phone it looks completely correct to use the vendored copy here and it wouldn\'t actually work otherwise. \n> \n> > On Sep 17, 2014, at 11:17 AM, Donald Stufft <donald at stufft.io> wrote:\n> > \n> > I don\'t know the specific situation but it\'s appropriate to do this if you\'re using requests and wish to interact with the urllib3 that requests is using.\n> > \n> >> On Sep 17, 2014, at 11:15 AM, Thomas Goirand <zigo at debian.org> wrote:\n> >> \n> >> Hi,\n> >> \n> >> I\'m horrified by what I just found. I have just found out this in\n> >> glanceclient:\n> >> \n> >> File \"<bla>/tests/test_ssl.py\", line 19, in <module>\n> >>   from requests.packages.urllib3 import poolmanager\n> >> ImportError: No module named packages.urllib3\n> >> \n> >> Please *DO NOT* do this. Instead, please use urllib3 from ... urllib3.\n> >> Not from requests. The fact that requests is embedding its own version\n> >> of urllib3 is an heresy. In Debian, the embedded version of urllib3 is\n> >> removed from requests.\n> >> \n> >> In Debian, we spend a lot of time to \"un-vendorize\" stuff, because\n> >> that\'s a security nightmare. I don\'t want to have to patch all of\n> >> OpenStack to do it there as well.\n> >> \n> >> And no, there\'s no good excuse here...\n> >> \n> >> Thomas Goirand (zigo)\n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5DFB754D-726E-4894-8D8A-475AD9590D83@stufft.io>',NULL),('<1410979499-sup-6741@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 11:46:50',-25200,'2014-09-17 18:46:50',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Davanum Srinivas\'s message of 2014-09-17 10:15:29 -0700:\n> I was trying request-ifying oslo.vmware and ran into this as well:\n> https://review.openstack.org/#/c/121956/\n> \n> And we don\'t seem to have urllib3 in global-requirements either.\n> Should we do that first?\n\nHonestly, after reading this:\n\nhttps://github.com/kennethreitz/requests/pull/1812\n\nI think we might want to consider requests a poor option. Its author\nclearly doesn\'t understand the role a _library_ plays in software\ndevelopment and considers requests an application, not a library.\n\nFor instance, why is requests exposing internal implementation details\nat all?  It should be wrapping any exceptions or objects to avoid\nforcing users to make this choice at all.\n\n\n','<CANw6fcGikUrfdPgyZTfJAztDBA1gP081wA1bkPpmoa=uzMrc5A@mail.gmail.com>',NULL),('<1410979736-sup-2040@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 12:04:14',-25200,'2014-09-17 19:04:14',NULL,'[openstack-dev] [heat][nova] VM restarting on host failure in\n	convergence','Excerpts from Jastrzebski, Michal\'s message of 2014-09-17 06:03:06 -0700:\n> All,\n> \n> Currently OpenStack does not have a built-in HA mechanism for tenant\n> instances which could restore virtual machines in case of a host\n> failure. Openstack assumes every app is designed for failure and can\n> handle instance failure and will self-remediate, but that is rarely\n> the case for the very large Enterprise application ecosystem.\n> Many existing enterprise applications are stateful, and assume that\n> the physical infrastructure is always on.\n> \n\nThere is a fundamental debate that OpenStack\'s vendors need to work out\nhere. Existing applications are well served by existing virtualization\nplatforms. Turning OpenStack into a work-alike to oVirt is not the end\ngoal here. It\'s a happy accident that traditional apps can sometimes be\nbent onto the cloud without much modification.\n\nThe thing that clouds do is they give development teams a _limited_\ninfrastructure that lets IT do what they\'re good at (keep the\ninfrastructure up) and lets development teams do what they\'re good at (run\ntheir app). By putting HA into the _app_, and not the _infrastructure_,\nthe dev teams get agility and scalability. No more waiting weeks for\nallocationg specialized servers with hardware fencing setups and fibre\nchannel controllers to house a shared disk system so the super reliable\nvirtualization can hide HA from the user.\n\nSpin up vms. Spin up volumes.  Run some replication between regions,\nand be resilient.\n\nSo, as long as it is understood that whatever is being proposed should\nbe an application centric feature, and not an infrastructure centric\nfeature, this argument remains interesting in the \"cloud\" context.\nOtherwise, it is just an invitation for OpenStack to open up direct\ncompetition with behemoths like vCenter.\n\n> Even the OpenStack controller services themselves do not gracefully\n> handle failure.\n> \n\nWhich ones?\n\n> When these applications were virtualized, they were virtualized on\n> platforms that enabled very high SLAs for each virtual machine,\n> allowing the application to not be rewritten as the IT team moved them\n> from physical to virtual. Now while these apps cannot benefit from\n> methods like automatic scaleout, the application owners will greatly\n> benefit from the self-service capabilities they will recieve as they\n> utilize the OpenStack control plane.\n> \n\nThese apps were virtualized for IT\'s benefit. But the application authors\nand users are now stuck in high-cost virtualization. The cloud is best\nutilized when IT can control that cost and shift the burden of uptime\nto the users by offering them more overall capacity and flexibility with\nthe caveat that the individual resources will not be as reliable.\n\nSo what I\'m most interested in is helping authors change their apps to\nbe reslient on their own, not in putting more burden on IT.\n\n> I\'d like to suggest to expand heat convergence mechanism to enable\n> self-remediation of virtual machines and other heat resources.\n> \n\nConvergence is still nascent. I don\'t know if I\'d pile on to what might\ntake another 12 - 18 months to get done anyway. We\'re just now figuring\nout how to get started where we thought we might already be 1/3 of the\nway through. Just something to consider.\n\n\n','<5C451B3D6BCE1443888323FE7B0AA306010D72A4@IRSMSX107.ger.corp.intel.com>',NULL),('<141097c9e80.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-10 13:07:46',-25200,'2013-09-10 20:07:46',NULL,'[Openstack] Why GlusterFS should not be integrated with\n	OpenStack','\nI\'m an architect at Nexenta. So not surprisingly I fully agree that Gluster \nis a poor choice for storage in OpenStack.\n\nHowever the real question is what criteria storage vendors should be judged \nby the project. These should be\nclearly stated and easily verified. Once compliance is dealt with, judging \nthe quality of specific solutions and\ntheir suitability to specific needs is something that the end users should \ndo, not the openstack project.\n\nThe Cinder project has set minimum standards for Volume Drivers for the \nHavana release. Those standards should be applied without debating their \nspecifics for Gluster on the mailing list.\n\nStorage vendors are used to dealing with certification processes. We know \nhow to deal with rules that state your software must do X and Y by date Z.\n\nI would be in full agreement, however, that OpenStack should not \naccommodate an API tailored to Gluster\'s unique architecture.\n\n\n\n\n','<CAGqxmDO4O+W6sL6ssB6yRsNG9u3bSnr_Bc8wsevSGRZ+e64HCQ@mail.gmail.com>',NULL),('<1410980926-sup-8255@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 12:09:38',-25200,'2014-09-17 19:09:38',NULL,'[openstack-dev] [tripleo] Adding hp1 back running tripleo CI','Excerpts from Derek Higgins\'s message of 2014-09-17 06:53:25 -0700:\n> On 15/09/14 22:37, Gregory Haynes wrote:\n> > This is a total shot in the dark, but a couple of us ran into issues\n> > with the Ubuntu Trusty kernel (I know I hit it on HP hardware) that was\n> > causing severely degraded performance for TripleO. This fixed with a\n> > recently released kernel in Trusty... maybe you could be running into\n> > this?\n> \n> thanks Greg,\n> \n> To try this out, I\'ve redeployed the new testenv image and ran 35\n> overcloud jobs on it(32 passed), the average time for these was 130\n> minutes so unfortunately no major difference.\n> \n> The old kernel was\n> 3.13.0-33-generic #58-Ubuntu SMP Tue Jul 29 16:45:05 UTC 2014 x86_64\n\nThis kernel definitely had the kvm bugs Greg and I exprienced in the\npast\n\n> the one one is\n> 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64\n> \n\nDarn. This one does not. Is it possible the hardware is just less\npowerful?\n\n\n','<54199255.1040209@redhat.com>',NULL),('<1410983207.8806.73.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-09-17 20:46:47',3600,'2014-09-17 19:46:47',NULL,'[openstack-tc] [Fwd: Re: [OpenStack-DefCore] Updated Bylaws]','On Wed, 2014-09-17 at 15:07 -0400, Jay Pipes wrote:\n> On 09/17/2014 08:39 AM, Mark McLoughlin wrote:\n> > Hey\n> >\n> > I think TC members should be paying closer attention to proposed bylaws\n> > changes. See my concerns below. I\'ve uploaded what I think are the\n> > latest proposed changes to here:\n> >\n> > https://wiki.openstack.org/wiki/File:Change-Pro_Redline_-_233015232-v15-OpenStackFoundation_Bylaws_FINAL_%28as_amended_September_7,_2012%29_and_233015232-v24-OpenStackFoundation_Bylaws_FINAL_.pdf\n> \n> Basic question: why are any of these changes necessary or being pushed?\n\nIt\'s mostly triggered by defcore, hence it supposedly being a\nsubcommittee of the defcore comittee. The defcore changes are the ones\nrelated to trademark policy, changing the definition of the \"Core\nOpenStack project\" and distinguishing between the Integrated Release and\nthe OpenStack Project.\n\nThe ATC related changes are in response to feedback from the TC?\n\nThe changes to the Legal Affairs Committee are because its current\nde-facto structure differs from what\'s defined in the bylaws.\n\nIn summary, \"defcore stuff with some scope creep\". That said, the\ndefcore committee proper seems to recommend not proceeding with any\nbylaws changes at this time.\n\nMark.\n\n\n\n','<5419DBFF.5050607@gmail.com>',NULL),('<1410992208-sup-6061@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 15:22:05',-25200,'2014-09-17 22:22:05',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Ian Cordasco\'s message of 2014-09-17 12:42:57 -0700:\n> On 9/17/14, 1:46 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> >Excerpts from Davanum Srinivas\'s message of 2014-09-17 10:15:29 -0700:\n> >> I was trying request-ifying oslo.vmware and ran into this as well:\n> >> https://review.openstack.org/#/c/121956/\n> >> \n> >> And we don\'t seem to have urllib3 in global-requirements either.\n> >> Should we do that first?\n> >\n> >Honestly, after reading this:\n> >\n> >https://github.com/kennethreitz/requests/pull/1812\n> >\n> >I think we might want to consider requests a poor option. Its author\n> >clearly doesn\'t understand the role a _library_ plays in software\n> >development and considers requests an application, not a library.\n> \n> Yes that is Kenneth?s opinion. That is not the opinion of the core\n> developers though. We see it as a library but this is something we aren?t\n> going to currently change any time soon.\n> \n\nGood to know but troubling to hear that there\'s no change in sight.\n\n> >For instance, why is requests exposing internal implementation details\n> >at all?\n> \n> Where exactly are we exposing internal implementation details? A normal\n> user (even advanced users) can use requests without ever digging into\n> requests.packages. What implementation details are we exposing and where?\n> \n> >It should be wrapping any exceptions or objects to avoid\n> >forcing users to make this choice at all.\n> \n> We do. Occasionally (like in 2.4.0) urllib3 adds an exception that we\n> missed notice of and it slips through. We released 2.4.1 a couple days\n> later with the fix for that. Pretty much every error we?ve seen or know\n> about is caught and rewrapped as a requests exception. I?m not sure what\n> you?re arguing here, unless of course you have not used requests.\n> \n\nI had seen handling of urllib3 exceptions in some requests code and was\nseeing a few issues about that. I understand now that it is not\nintentional, but a side effect of misunderstanding.\n\n> That aside, I?ve been mulling over how effectively the clients use\n> requests. I haven?t investigated all of them, but many seem to reach into\n> implementation details on their own. If I remember nova client has\n> something it has commented as ?connection pooling? while requests and\n> urllib3 do that automatically. I haven?t started to investigate exactly\n> why they do this. Likewise, glance client has custom certificate\n> verification in glanceclient.common.https. Why? I?m not exactly certain\n> yet. It seems for the most part from what little I?ve seen that requests\n> is too high-level a library for OpenStack?s needs at best, and actively\n> obscures details OpenStack developers need (or don?t realize requests\n> provides in most cases).\n> \n\nIndeed, it sounds like there has been some misuse of requests that led\nto the situation.\n\n> Circling back to the issue of vendoring though: it?s a conscious decision\n> to do this, and in the last two years there have been 2 CVEs reported for\n> requests. There have been none for urllib3 and none for chardet. (Frankly\n> I don?t think either urllib3 or chardet have had any CVEs reported against\n> them, but let?s ignore that for now.) While security is typically the\n> chief concern with vendoring, none of the libraries we use have had\n> security issues rendering it a moot point in my opinion. The benefits of\n> vendoring for us as a team have been numerous and we will likely continue\n> to do it until it stops benefiting us and our users.\n> \n\nOn a micro scale, you are absolutely correct. The point is not that\nthere is a tactical reason for urllib3 to be de-vendored, but rather\nthat there is a strategic reason to not use vendored libraries. When\nupdates are necessary, they must be complete, and rapid. Please refer\nto the zlib travesty to see why everyone, not just distribution vendors,\nshould be extremely concerned about embedded libraries.\n\n\n','<D03F47B5.2E86%ian.cordasco@rackspace.com>',NULL),('<1410997745.2169149.168768269.0F0C570C@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 16:49:05',-25200,'2014-09-17 23:49:05',NULL,'[openstack-dev] PostgreSQL jobs slow in the gate','Hello,\n\nRecent sampling of test run times shows that our tempest jobs run\nagainst clouds using PostgreSQL are significantly slower than jobs run\nagainst clouds using MySQL.\n\n(check|gate)-tempest-dsvm-full has an average run time of 52.9 minutes\n(stddev 5.92 minutes) over 516 runs.\n(check|gate)-tempest-dsvm-postgres-full has an average run time of 73.78\nminutes (stddev 11.01 minutes) over 493 runs.\n\nI think this is a bug and and an important one to solve prior to release\nif we want to continue to care and feed for PostgreSQL support. I\nhaven\'t filed a bug in LP because I am not sure where the slowness is\nand creating a bug against all the projects is painful. (If there are\nsuggestions for how to do this in a non painful way I will happily go\nfile a proper bug).\n\nIs there interest in fixing this? If not we should probably reconsider\nremoving these PostgreSQL jobs from the gate.\n\nNote, a quick spot check indicates the increase in job time is not\nrelated to job setup. Total time before running tempest appears to be\njust over 18 minutes in the jobs I checked.\n\nThank you,\nClark\n\n\n',NULL,NULL),('<1411004886.2196301.168822813.1A002D0E@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 18:48:06',-25200,'2014-09-18 01:48:06',NULL,'[openstack-dev] PostgreSQL jobs slow in the gate','On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:\n> \n> \n> On 9/17/2014 7:59 PM, Ian Wienand wrote:\n> > On 09/18/2014 09:49 AM, Clark Boylan wrote:\n> >> Recent sampling of test run times shows that our tempest jobs run\n> >> against clouds using PostgreSQL are significantly slower than jobs run\n> >> against clouds using MySQL.\n> >\n> > FYI There is a possibly relevant review out for max_connections limits\n> > [1], although it seems to have some issues with shmem usage\n> >\n> > -i\n> >\n> > [1] https://review.openstack.org/#/c/121952/\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> That\'s a backport of a fix from master where we were hitting fatal \n> errors due to too many DB connections which was brought on by the \n> changes to cinder and glance to run as many workers as there were CPUs \n> available.  So I don\'t think it probably plays here...\n> \n> The errors pointed out in another part of the thread have been around \n> for awhile, I think they are due to negative tests where we\'re hitting \n> unique constraints because of the negative tests, so they are expected.\n> \n> We should also note that the postgresql jobs run with the nova metadata \n> API service, I\'m not sure how much of a factor that would have here.\n> \n> Is there anything else unique about those jobs from the MySQL ones?\n>\nGood question. There are apparently other differences. The postgres job\nruns Keystone under eventlet instead of via apache mod_wsgi. It also\nsets FORCE_CONFIGDRIVE=False instead of always. And the final difference\nI can find is the one you point out, nova api metadata service is run as\nan independent thing.\n\nCould these things be related? It would be relatively simple to push a\nchange or two to devstack-gate to test this but there are enough options\nhere that I probably won\'t do that until we think at least one of these\noptions is at fault.\n> \n> -- \n> \n> Thanks,\n> \n> Matt Riedemann\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<541A3748.3010007@linux.vnet.ibm.com>',NULL),('<1411012212.2228068.168852477.1E778F3D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-17 20:50:12',-25200,'2014-09-18 03:50:12',NULL,'[openstack-dev] PostgreSQL jobs slow in the gate','On Wed, Sep 17, 2014, at 06:48 PM, Clark Boylan wrote:\n> On Wed, Sep 17, 2014, at 06:37 PM, Matt Riedemann wrote:\n> > \n> > \n> > On 9/17/2014 7:59 PM, Ian Wienand wrote:\n> > > On 09/18/2014 09:49 AM, Clark Boylan wrote:\n> > >> Recent sampling of test run times shows that our tempest jobs run\n> > >> against clouds using PostgreSQL are significantly slower than jobs run\n> > >> against clouds using MySQL.\n> > >\n> > > FYI There is a possibly relevant review out for max_connections limits\n> > > [1], although it seems to have some issues with shmem usage\n> > >\n> > > -i\n> > >\n> > > [1] https://review.openstack.org/#/c/121952/\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > \n> > That\'s a backport of a fix from master where we were hitting fatal \n> > errors due to too many DB connections which was brought on by the \n> > changes to cinder and glance to run as many workers as there were CPUs \n> > available.  So I don\'t think it probably plays here...\n> > \n> > The errors pointed out in another part of the thread have been around \n> > for awhile, I think they are due to negative tests where we\'re hitting \n> > unique constraints because of the negative tests, so they are expected.\n> > \n> > We should also note that the postgresql jobs run with the nova metadata \n> > API service, I\'m not sure how much of a factor that would have here.\n> > \n> > Is there anything else unique about those jobs from the MySQL ones?\n> >\n> Good question. There are apparently other differences. The postgres job\n> runs Keystone under eventlet instead of via apache mod_wsgi. It also\n> sets FORCE_CONFIGDRIVE=False instead of always. And the final difference\n> I can find is the one you point out, nova api metadata service is run as\n> an independent thing.\n> \n> Could these things be related? It would be relatively simple to push a\n> change or two to devstack-gate to test this but there are enough options\n> here that I probably won\'t do that until we think at least one of these\n> options is at fault.\nI am starting to feel bad that I picked on PostgreSQL and completely\nforgot that there were other items in play here. I went ahead and\nuploaded [0] to run all devstack jobs without keystone wsgi services\n(eventlet) and [1] to run all devstack job with keystone wsgi services\nand the initial results are pretty telling.\n\nIt appears that keystone eventlet is the source of the slowness in this\njob. With keystone eventlet all of the devstack jobs are slower and with\nkeystone wsgi all of the jobs are quicker. Probably need to collect a\nbit more data but this doesn\'t look good for keystone eventlet.\n\nThank you Matt for pointing me in this direction.\n\n[0] https://review.openstack.org/#/c/122299/\n[1] https://review.openstack.org/#/c/122300/\n> > \n> > -- \n> > \n> > Thanks,\n> > \n> > Matt Riedemann\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1411004886.2196301.168822813.1A002D0E@webmail.messagingengine.com>',NULL),('<1411049718-sup-3678@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 07:18:57',-25200,'2014-09-18 14:18:57',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Donald Stufft\'s message of 2014-09-18 04:58:06 -0700:\n> \n> > On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:\n> > \n> >> \n> >> Linux distributions are not the end be all of distribution models and\n> >> they don?t get to dictate to upstream.\n> > \n> > Well, distributions is where the final user is, and where software gets\n> > consumed. Our priority should be the end users.\n> \n> \n> Distributions are not the only place that people get their software from,\n> unless you think that the ~3 million downloads requests has received\n> on PyPI in the last 30 days are distributions downloading requests to\n> package in their OSs.\n> \n\nDo pypi users not also need to be able to detect and fix any versions\nof libraries they might have? If one has some virtualenvs with various\nlibraries and apps installed and no --system-site-packages, one would\nprobably still want to run \'pip freeze\' in all of them and find out what\nlibraries are there and need to be fixed.\n\nAnyway, generally security updates require a comprehensive strategy.\nOne common comprehensive strategy is version assertion.\n\nVendoring complicates that immensely.\n\n\n','<07FE7E51-9F06-46E9-BB7B-E6F9820DCE9A@stufft.io>',NULL),('<1411050111-sup-7055@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 07:24:55',-25200,'2014-09-18 14:24:55',NULL,'[openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed\n	Queues','Great job highlighting what our friends over at Amazon are doing.\n\nIt\'s clear from these snippets, and a few other pieces of documentation\nfor SQS I\'ve read, that the Amazon team approached SQS from a _massive_\nscaling perspective. I think what may be forcing a lot of this frustration\nwith Zaqar is that it was designed with a much smaller scale in mind.\n\nI think as long as that is the case, the design will remain in question.\nI\'d be comfortable saying that the use cases I\'ve been thinking about\nare entirely fine with the limitations SQS has.\n\nExcerpts from Joe Gordon\'s message of 2014-09-17 13:36:18 -0700:\n> Hi All,\n> \n> My understanding of Zaqar is that it\'s like SQS. SQS uses distributed\n> queues, which have a few unusual properties [0]:\n> Message Order\n> \n> Amazon SQS makes a best effort to preserve order in messages, but due to\n> the distributed nature of the queue, we cannot guarantee you will receive\n> messages in the exact order you sent them. If your system requires that\n> order be preserved, we recommend you place sequencing information in each\n> message so you can reorder the messages upon receipt.\n> At-Least-Once Delivery\n> \n> Amazon SQS stores copies of your messages on multiple servers for\n> redundancy and high availability. On rare occasions, one of the servers\n> storing a copy of a message might be unavailable when you receive or delete\n> the message. If that occurs, the copy of the message will not be deleted on\n> that unavailable server, and you might get that message copy again when you\n> receive messages. Because of this, you must design your application to be\n> idempotent (i.e., it must not be adversely affected if it processes the\n> same message more than once).\n> Message Sample\n> \n> The behavior of retrieving messages from the queue depends whether you are\n> using short (standard) polling, the default behavior, or long polling. For\n> more information about long polling, see Amazon SQS Long Polling\n> <http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html>\n> .\n> \n> With short polling, when you retrieve messages from the queue, Amazon SQS\n> samples a subset of the servers (based on a weighted random distribution)\n> and returns messages from just those servers. This means that a particular\n> receive request might not return all your messages. Or, if you have a small\n> number of messages in your queue (less than 1000), it means a particular\n> request might not return any of your messages, whereas a subsequent request\n> will. If you keep retrieving from your queues, Amazon SQS will sample all\n> of the servers, and you will receive all of your messages.\n> \n> The following figure shows short polling behavior of messages being\n> returned after one of your system components makes a receive request.\n> Amazon SQS samples several of the servers (in gray) and returns the\n> messages from those servers (Message A, C, D, and B). Message E is not\n> returned to this particular request, but it would be returned to a\n> subsequent request.\n> \n> \n> \n> Presumably SQS has these properties because it makes the system scalable,\n> if so does Zaqar have the same properties (not just making these same\n> guarantees in the API, but actually having these properties in the\n> backends)? And if not, why? I looked on the wiki [1] for information on\n> this, but couldn\'t find anything.\n> \n> \n> \n> \n> \n> [0]\n> http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/DistributedQueues.html\n> [1] https://wiki.openstack.org/wiki/Zaqar\n\n\n','<CAHXdxOdyevOP=y7obnKbF0eJYSm1+z0=LefWroKCXWwSE1pnRw@mail.gmail.com>',NULL),('<1411051356-sup-1329@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 09:29:53',-25200,'2014-09-18 16:29:53',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Donald Stufft\'s message of 2014-09-18 07:30:27 -0700:\n> \n> > On Sep 18, 2014, at 10:18 AM, Clint Byrum <clint at fewbar.com> wrote:\n> > \n> > Excerpts from Donald Stufft\'s message of 2014-09-18 04:58:06 -0700:\n> >> \n> >>> On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:\n> >>> \n> >>>> \n> >>>> Linux distributions are not the end be all of distribution models and\n> >>>> they don?t get to dictate to upstream.\n> >>> \n> >>> Well, distributions is where the final user is, and where software gets\n> >>> consumed. Our priority should be the end users.\n> >> \n> >> \n> >> Distributions are not the only place that people get their software from,\n> >> unless you think that the ~3 million downloads requests has received\n> >> on PyPI in the last 30 days are distributions downloading requests to\n> >> package in their OSs.\n> >> \n> > \n> > Do pypi users not also need to be able to detect and fix any versions\n> > of libraries they might have? If one has some virtualenvs with various\n> > libraries and apps installed and no --system-site-packages, one would\n> > probably still want to run \'pip freeze\' in all of them and find out what\n> > libraries are there and need to be fixed.\n> > \n> > Anyway, generally security updates require a comprehensive strategy.\n> > One common comprehensive strategy is version assertion.\n> > \n> > Vendoring complicates that immensely.\n> \n> It doesn?t really matter. PyPI doesn?t dictate to projects who host there what\n> that project is allowed to do except in some very broad circumstances. Whether\n> or not requests *should* do this doesn\'t really have any bearing on what\n> Openstack should do to cope with it. The facts are that requests does it, and\n> that people pulling things from PyPI is an actual platform that needs thought\n> about.\n> \n> This leaves Openstack with a few reasonable/sane options:\n> \n> 1) Decide that vendoring in requests is unacceptable to what Openstack as a\n>    project is willing to support, and cease the use of requests.\n> 2) Decide that what requests offers is good enough that it outweighs the fact\n>    that it vendors urllib3 and continue using it.\n> \n\nThere\'s also 3) fork requests, which is the democratic way to vote out\nan upstream that isn\'t supporting the needs of the masses.\n\nI don\'t think we\'re anywhere near there, but I wanted to make it clear\nthere _is_ a more extreme option.\n\n> If the 2nd option is chosen, then doing anything but supporting the fact that\n> requests vendors urllib3 within the code that openstack writes is hurting the\n> users who fetch these projects from PyPI because you don\'t agree with one of\n> the choices that requests makes. By all means do conditional imports to lessen\n> the impact that the choice requests has made (and the one that Openstack has\n> made to use requests) on downstream distributors, but unconditionally importing\n> from the top level urllib3 for use within requests is flat out wrong.\n> \n> Obviously neither of these options excludes the choice to lean on requests to\n> reverse this decision as well. However that is best done elsewhere as the\n> person making that decision isn\'t a member of these mailing lists as far as\n> I am aware.\n> \n\nTo be clear, I think we should keep using requests. But we should lend\nour influence upstream and explain that our users are required to deal\nwith this in a way that perhaps hasn\'t been considered or given the\nappropriate priority.\n\n\n','<D843A0FA-4275-448D-829B-F3A3E599BEB3@stufft.io>',NULL),('<1411058009-sup-6689@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 09:40:47',-25200,'2014-09-18 16:40:47',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Ian Cordasco\'s message of 2014-09-18 07:35:10 -0700:\n> On 9/18/14, 9:18 AM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> >Excerpts from Donald Stufft\'s message of 2014-09-18 04:58:06 -0700:\n> >> \n> >> > On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:\n> >> > \n> >> >> \n> >> >> Linux distributions are not the end be all of distribution models and\n> >> >> they don?t get to dictate to upstream.\n> >> > \n> >> > Well, distributions is where the final user is, and where software\n> >>gets\n> >> > consumed. Our priority should be the end users.\n> >> \n> >> \n> >> Distributions are not the only place that people get their software\n> >>from,\n> >> unless you think that the ~3 million downloads requests has received\n> >> on PyPI in the last 30 days are distributions downloading requests to\n> >> package in their OSs.\n> >> \n> >\n> >Do pypi users not also need to be able to detect and fix any versions\n> >of libraries they might have? If one has some virtualenvs with various\n> >libraries and apps installed and no --system-site-packages, one would\n> >probably still want to run \'pip freeze\' in all of them and find out what\n> >libraries are there and need to be fixed.\n> >\n> >Anyway, generally security updates require a comprehensive strategy.\n> >One common comprehensive strategy is version assertion.\n> >\n> >Vendoring complicates that immensely.\n> \n> Except that even OpenStack doesn?t pin requests because of how\n> extraordinarily stable our API is. While you can argue that Kenneth has\n> non-standard opinions about his library, Cory and I take backwards\n> compatibility and stability very seriously. This means anyone can upgrade\n> to a newer version of requests without worrying that it will be backwards\n> incompatible. \n> \n\nAll of your hard work is very much appreciated. I don\'t understand what\nyour assertion means though. We don\'t pin things. However, our users end\nup \"pinning\" when they install via pip, and our distros end up \"pinning\"\nwhen they deliver a version. Without any indication that urllib3 is in\nthe system, they will fail at any cursory version audit that looks for it.\n\nI\'m not saying either way is right or wrong either.. I\'m suggesting\nthat this is a valid, proven method for large scale risk assessment,\nand it is complicated quite a bit by vendored libraries.\n\n\n','<D040572A.2FC0%ian.cordasco@rackspace.com>',NULL),('<1411058476-sup-5487@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-18 09:45:21',-25200,'2014-09-18 16:45:21',NULL,'[Openstack-operators] Openstack and mysql galera with haproxy','Excerpts from S?awek Kap?o?ski\'s message of 2014-09-18 09:29:27 -0700:\n> Hello,\n> \n> Is anyone here using openstack with mysql galera and haproxy? Have You got any \n> problems with that?\n> I was today installed such ha infra for database (two mysql servers in galera \n> cluster and haproxy on controller and neutron node, this haproxy is connecting \n> to one of galera servers with round robin algorithm). Generally all is working \n> fine but I have few problems:\n> 1. I have a lot of messages like: \n> WARNING neutron.openstack.common.db.sqlalchemy.session [-] Got mysql server \n> has gone away: (2006, \'MySQL server has gone away\')\n> 2. I have (most on neutron) many errors like:\n> OperationalError: (OperationalError) (2013, \'Lost connection to MySQL server \n> during query\') \'UPDATE ml2_port_bindings SET vif_type=%s, driver=%s, \n> segment=%s WHERE ml2_port_bindings.port_id =\n\n1 and 2 look like timeout issues. Check haproxy\'s timeouts. They need\nto be just a little longer than MySQL\'s connection timeouts.\n\n> 3. Also errors:\n> StaleDataError: UPDATE statement on table \'ports\' expected to update 1 row(s); \n> 0 were matched.\n> 4. and errors:\n> DBDeadlock: (OperationalError) (1213, \'Deadlock found when trying to get lock; \n> try restarting transaction\') \'UPDATE ipavailabilityranges SET first_ip=%s WHERE \n> ipavailabilityranges.allocation_pool_id =\n\n3 and 4 are a known issue. Our code doesn\'t always retry transactions,\nwhich is required to use Galera ACTIVE/ACTIVE. Basically, that doesn\'t\nwork.\n\nYou can use ACTIVE/PASSIVE, and even do vertical partitioning where\none of the servers is ACTIVE for Nova, but another one is ACTIVE for\nNeutron. But AFAIK, ACTIVE/ACTIVE isn\'t being tested and the work hasn\'t\nbeen done to make the concurrent transactions work properly.\n\n\n','<2868711.0OK9hAyyMb@laptop>',NULL),('<1411070506-sup-8925@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-18 13:03:02',-25200,'2014-09-18 20:03:02',NULL,'[Openstack-operators] Openstack and mysql galera with haproxy','Excerpts from S?awek Kap?o?ski\'s message of 2014-09-18 12:34:53 -0700:\n> Hello,\n> \n> Thanks all of You guys for help. I will try to apply that percona\'s scripts \n> and configure it in active/pasive mode.\n> About \"mysql has gone away\" I thought so it is not big problem but it looks \n> \"ugly\" in logs \n> Simon - I think that it is not related strictly to neutron and similar \n> problems can happend also in nova.\n> \n> I have one more question to You guys. I know that there is mysql cluster \n> solution based on galera which is made by percona. Is it really better that \n> \"pure\" mysql-wsrep and galera installed or maybe it doesn\'t matter?\n> \n\nOne big reason it might be \"better\" is that Percona is quite good at\nsupporting it. It also has direct support for more efficient re-syncing\nby using xtrabackup instead of the rather cumbersome \"SST\". But I could\nbe mistaken, and pure mysql-wsrep might also have that.\n\n\n','<3360395.GaSOl65f3U@laptop>',NULL),('<1411087519-sup-3629@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-18 17:49:00',-25200,'2014-09-19 00:49:00',NULL,'[openstack-dev] [nova] Expand resource name allowed characters','Excerpts from Christopher Yeoh\'s message of 2014-09-18 16:57:12 -0700:\n> On Thu, 18 Sep 2014 12:12:28 -0400\n> Sean Dague <sean at dague.net> wrote:\n> > > When we can return the json-schema to user in the future, can we say\n> > > that means API accepting utf8 or utf8mb4 is discoverable? If it is\n> > > discoverable, then we needn\'t limit anything in our python code.\n> > \n> > Honestly, we should accept utf8 (no weird mysqlism not quite utf8). We\n> > should make the default scheme for our dbs support that on names (but\n> > only for the name columns). The failure of a backend to do utf8 for\n> > real should return an error to the user. Let\'s not make this more\n> > complicated than it needs to be.\n> \n> I agree that discoverability for this is not the way to go - I think its\n> too complicated for end users. I don\'t know enough about mysql to know\n> if utf8mb4 is going to a performance issue but if its not then we\n> should just support utf-8 properly. \n> \n> We can we can catch the db errors. However whilst converting db\n> errors causing 500s is fairly straightforward when an error occurs that\n> deep in Nova it also means a lot of potential unwinding work in the db\n> and compute layers which is complicated and error prone. So i\'d prefer\n> to avoid the situation with input validation in the first place. \n\nJust to add a reference into the discussion:\n\nhttp://dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html\n\nIt does have the same limitation of making fixed width keys and CHAR()\ncolumns. It goes from 3 bytes per CHAR position, to 4, so it should not\nbe a database wide default, but something we use sparingly.\n\nNote that the right answer for things that are not utf-8 (like UUID\'s)\nis not to set a charset of latin1, but use BINARY/VARBINARY. Last\ntime I tried I had a difficult time coercing SQLAlchemy to model the\ndifference.. but maybe I just didn\'t look in the right part of the manual.\n\n\n','<20140919092712.53336a38@pingu>',NULL),('<1411107723.20748.53.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-09-19 07:22:03',3600,'2014-09-19 06:22:03',NULL,'[OpenStack Foundation] Supporting materials from board meetings','Hi Alan\n\n(For the background of people not on the board - in advance of each\nmeeting, Alan does an excellent job of getting board members to send\ntheir supporting materials like papers and slide decks so that board\nmembers can be fully prepared for the meeting.)\n\nOur transparency policy doesn\'t address the topic of this sort of\nmaterial:\n\n  http://www.openstack.org/legal/transparency-policy/\n\nBut I think the spirit of it would suggest that the materials should be\npublished after the meeting - perhaps you could publish them, or perhaps\nJonathan could include them in his summary?\n\nThe material is hugely useful to board members, but I think also hugely\nuseful to the wider membership. And since the material is discussed and\nreferenced in the open board meetings, it\'s already public information.\n\nThanks,\nMark.\n\n\n\n',NULL,NULL),('<1411110037.4417.9.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-19 09:00:37',7200,'2014-09-19 07:00:37',NULL,'[Openstack] able to ping but not able to ssh to instance','Hi Srinivas, \nin the past I had a similar issue while I was setting up openstack with\ndevstack. Not sure if that fits for your issue, as you\'re not using\ndevstack if I got it right.\n\nThe reason for this where the default security groups and rules config\nof devstack. If you have a look at the this concept, you will realize\nthat there are two types of remotes you can define a rule for:\n* CIDR or\n* Security Group\nThe default rule for ingress IPv4 traffic was set to something like\n\"Allow INGRESS for all IPv4 traffic from remote Security Group default\"\n--> Only Ingress IPv4 traffic from other instances that have the\nsecurity group default where allowed. As my laptop is not member of the\nsecurity group default (of course, only instances can!) I was not able\nto ssh or even ping from outside into the guest. (vice verca it was\nworking as egress is defined for CIDR 0.0.0.0/0) From guest to guest of\ncourse ssh was working as both instances where member of the default\ngroup.\n\n\n\nSo what I had to do is to add a new rule like\n\"allow Ingress SSH traffic from remote CIDR 0.0.0.0/0\"\n--> CIDR 0.0.0.0/0 means just everything :)\n\nHope that helps\n\n\nAndreas \n(irc: scheuran)\n\n\n\n\nOn Fri, 2014-09-19 at 09:41 +0530, Srinivasreddy R wrote:\n> hi, \n> i have checked security group rules . \n> my instance is pinging to router and even a device  in external\n> network .\n> mostly my problem may in host\'s firewall .\n> how can i identify which rule is dropping the ssh traffic .?\n> how can  i confirm that ssh traffic is blocked at firewall .?\n> i there any way to see the firewall dropped packets ?\n> \n> \n> thanks ,\n> srinivas.\n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> On Thu, Sep 18, 2014 at 7:36 PM, Akilesh K <akilesh1597 at gmail.com>\n> wrote:\n>         I believe you have checked the security group rules. Make sure\n>         the instance is able to ping the router. If yes the problem\n>         lies in your host\'s firewall rules. Flush the hosts iptable\n>         rules(you may take a backup before you do that). \n>         \n>         \n>         On Thu, Sep 18, 2014 at 7:32 PM, Srinivasreddy R\n>         <srinivasreddy4390 at gmail.com> wrote:\n>                 \n>                 hi ,\n>                 \n>                 thanks for your reply .\n>                 \n>                 \n>                 1. i have checked ssh server is running in instance ..\n>                 \n>                     ssh from one instance to another is possible using\n>                 private network[demo-net] .\n>                 \n>                 2. checked  ssh is running in port 22\n>                 \n>                 3. telnet <ip>  22 is not working .\n>                 \n>                 \n>                 \n>                 4. output when i run ssh using verbose  pasted at \n>                 \n>                 http://paste.openstack.org/show/112860/\n>                 \n>                 \n>                 \n>                  \n>                 \n>                 ==================================\n>                 \n>                 ip tables output \n>                 \n>                 \n>                 my internal network for vm is 11.0.0.x and external\n>                 network is 172.0.0.x \n>                 \n>                 \n>                 \n>                 root at user-ThinkCentre-M73:/home/user# ip netns exec\n>                 qrouter-f6e00f94-1c6d-4cf5-8cae-319e393240fe  iptables\n>                 -t nat -S\n>                 -P PREROUTING ACCEPT\n>                 -P INPUT ACCEPT\n>                 -P OUTPUT ACCEPT\n>                 -P POSTROUTING ACCEPT\n>                 -N neutron-l3-agent-OUTPUT\n>                 -N neutron-l3-agent-POSTROUTING\n>                 -N neutron-l3-agent-PREROUTING\n>                 -N neutron-l3-agent-float-snat\n>                 -N neutron-l3-agent-snat\n>                 -N neutron-postrouting-bottom\n>                 -A PREROUTING -j neutron-l3-agent-PREROUTING\n>                 -A OUTPUT -j neutron-l3-agent-OUTPUT\n>                 -A POSTROUTING -j neutron-l3-agent-POSTROUTING\n>                 -A POSTROUTING -j neutron-postrouting-bottom\n>                 -A neutron-l3-agent-OUTPUT -d 172.0.0.7/32 -j DNAT\n>                 --to-destination 11.0.0.9\n>                 -A neutron-l3-agent-OUTPUT -d 172.0.0.3/32 -j DNAT\n>                 --to-destination 11.0.0.2\n>                 -A neutron-l3-agent-OUTPUT -d 172.0.0.4/32 -j DNAT\n>                 --to-destination 11.0.0.5\n>                 -A neutron-l3-agent-POSTROUTING ! -i qg-ec80d9fb-82 !\n>                 -o qg-ec80d9fb-82 -m conntrack ! --ctstate DNAT -j\n>                 ACCEPT\n>                 -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32\n>                 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697\n>                 -A neutron-l3-agent-PREROUTING -d 172.0.0.7/32 -j DNAT\n>                 --to-destination 11.0.0.9\n>                 -A neutron-l3-agent-PREROUTING -d 172.0.0.3/32 -j DNAT\n>                 --to-destination 11.0.0.2\n>                 -A neutron-l3-agent-PREROUTING -d 172.0.0.4/32 -j DNAT\n>                 --to-destination 11.0.0.5\n>                 -A neutron-l3-agent-float-snat -s 11.0.0.9/32 -j SNAT\n>                 --to-source 172.0.0.7\n>                 -A neutron-l3-agent-float-snat -s 11.0.0.2/32 -j SNAT\n>                 --to-source 172.0.0.3\n>                 -A neutron-l3-agent-float-snat -s 11.0.0.5/32 -j SNAT\n>                 --to-source 172.0.0.4\n>                 -A neutron-l3-agent-snat -j\n>                 neutron-l3-agent-float-snat\n>                 -A neutron-l3-agent-snat -s 11.0.0.0/24 -j SNAT\n>                 --to-source 172.0.0.2\n>                 -A neutron-postrouting-bottom -j neutron-l3-agent-snat\n>                 \n>                 \n>                 \n>                 \n>                 =====================\n>                 \n>                 i pasted my dump flows of br-tun at \n>                 http://paste.openstack.org/show/112859/\n>                 \n>                 \n>                 \n>                 \n>                 \n>                 as per the doc\n>                  https://openstack.redhat.com/Networking_in_too_much_detail\n>                 \n>                 \n>                 \n>                 br-ex is connected to router , router is connected to\n>                 br-int , br-int is connected to bt-tun .\n>                 \n>                 \n>                 i have captured at br-int . my ssh request is reaching\n>                 to br-int but not going through tunnel .\n>                 \n>                 \n>                 please help me .\n>                 \n>                 \n>                 \n>                 \n>                 \n>                 \n>                 thanks,\n>                 srinivas.\n>                 \n>                 \n>                 \n>                 \n>                 On Wed, Sep 17, 2014 at 9:30 PM, Sajith Kariyawasam\n>                 <sajhak at gmail.com> wrote:\n>                         Hi,\n>                         \n>                         \n>                         Could be due to,\n>                             ssh server is not up and running in your\n>                         instance,\n>                             or running in a different port rather than\n>                         port 22,\n>                             or, ssh port access is restricted in\n>                         openstack key pair configuration\n>                         \n>                         \n>                         You could also try telnet to check the\n>                         connectivity, \n>                         $ telnet <ip> 22\n>                         \n>                         \n>                         Thanks,\n>                         Sajith\n>                                   \n>                         \n>                         On Wed, Sep 17, 2014 at 8:59 PM, Zolt?n Lajos\n>                         Kis <zoltan.lajos.kis at ericsson.com> wrote:\n>                         \n>                                 Hi,\n>                                 \n>                                  \n>                                 \n>                                 What?s the output of running ssh with\n>                                 the verbose (-v) flag?\n>                                 \n>                                  \n>                                 \n>                                 BR,\n>                                 \n>                                 Zoltan\n>                                 \n>                                  \n>                                 \n>                                 From: Srinivasreddy R\n>                                 [mailto:srinivasreddy4390 at gmail.com] \n>                                 Sent: Wednesday, September 17, 2014\n>                                 5:16 PM\n>                                 To: openstack at lists.openstack.org\n>                                 Subject: [Openstack] able to ping but\n>                                 not able to ssh to instance\n>                                 \n>                                 \n>                                  \n>                                 \n>                                 hi,\n>                                 \n>                                 \n>                                 i am able to ping my instance form\n>                                 external network . \n>                                 \n>                                 \n>                                 but  not able to ssh to the\n>                                 instance . \n>                                 \n>                                 \n>                                 i am using floating ip s for ping,ssh.\n>                                 \n>                                 \n>                                 please help me .\n>                                 \n>                                 thanks,\n>                                 srinivas.\n>                                 \n>                                 \n>                                 \n>                                 \n>                                 _______________________________________________\n>                                 Mailing list:\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                                 Post to     :\n>                                 openstack at lists.openstack.org\n>                                 Unsubscribe :\n>                                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                                 \n>                         \n>                         \n>                         \n>                         \n>                         -- \n>                         Best Regards\n>                         Sajith\n>                 \n>                 \n>                 \n>                 _______________________________________________\n>                 Mailing list:\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 Post to     : openstack at lists.openstack.org\n>                 Unsubscribe :\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>                 \n>         \n>         \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-- \nAndreas (irc: scheuran)\n\n\n\n','<CAJP4VWixQuJxbz0kNYSG497fRWaPOr1GW5FYLnhRp3UYKpHCCw@mail.gmail.com>',NULL),('<1411110808.4417.13.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-19 09:13:28',7200,'2014-09-19 07:13:28',NULL,'[Openstack] Question about VXLAN support','Thanks for this clarification. \nJust wondering: Do multiple network nodes (router + dhcp) help to exceed\nthe 4k subnet limitation? In such a scenario, will dhcp + routing be\ndistributed or is a second network node just something like a\nhot-standby?\n\nThanks!\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Thu, 2014-09-18 at 09:47 -0400, George Mihaiescu wrote:\n> The VLAN ID is only locally significant to each compute node, so same\n> subnet belonging to same tenant could would have different VLAN tags\n> on different compute nodes.\n> \n> VLAN tag 1 could be used by subnet1 of tenant A on node1 and by\n> subnet1 of tenant B on node 2, with no conflicts.\n> \n>  \n> \n> Both VXLAN and GRE add a 24-bit header, so the maximum number of\n> tunnels is 16 million but each compute node can locally implement only\n> a maximum of 4096 different neutron subnets.\n> \n> What are the chances that you have more than 4096 instances on a\n> compute node, each connected to a different neutron subnet?\n> \n> What are the chances that you have more than 409 instances on a\n> compute node, each connected to 10 different neutron subnets?\n> \n>  \n> \n> The same limitation applies to the Neutron node (because a tunnel\n> endpoint exists there as well), so you cannot have a Neutron node\n> where a L3 agent and a DHCP agent serve more than 4096 Neutron\n> subnets, but you would hit other limits by then.\n> \n>  \n> \n> George\n> \n>  \n> \n>                                    \n> ______________________________________________________________________\n> From: BYEONG-GI KIM [mailto:kimbyeonggi at gmail.com] \n> Sent: Wednesday, September 17, 2014 10:41 PM\n> To: George Mihaiescu; openstack at lists.openstack.org\n> Subject: Re: [Openstack] Question about VXLAN support\n> \n> \n>  \n> \n> Dear George\n> \n>  \n> \n> \n> Thank you for the reply. \n> \n> \n>  \n> \n> \n> I\'m a little confused about your reply. \n> \n> \n>  \n> \n> \n> Can be the same tag number assigned to different tenant? For example,\n> I assume the situation where a subnet 1 assigned tag number 1 and it\n> belongs to tenant A, and a subnet b is also assigned tag number 1 and\n> it belongs to tenant B. Or, should be the tag number different even if\n> subnets belong to different tenant?\n> \n> \n>  \n> \n> \n> If the later case, the tag number seems much more strictly limited,\n> because a tenant can have many subnet. If a subnet has 10 subnets,\n> which means 10 tag numbers must be assigned, the openstack only create\n> about 400 tenants.\n> \n> \n>  \n> \n> \n> Is the VXLAN network type in OpenStack really scalable comparing with\n> VLAN or GRE? Or does the current OpenStack just provide functionality\n> to handle VXLAN header?\n> \n> \n>  \n> \n> \n> Please let me know good example about VXLAN usage, which can provide\n> scalability for multi-tenant on OpenStack. I\'d like to know whether\n> more than 100000 tenants could be handled by VXLAN on the latest\n> OpenStack implementation or not.\n> \n> \n>  \n> \n> \n> Best regards\n> \n> \n>  \n> \n> \n> Byeong-Gi KIM\n> \n> \n>  \n> \n> 2014-09-18 11:20 GMT+09:00 George Mihaiescu <George.Mihaiescu at q9.com>:\n> \n> The internal VLAD ID is indeed limited to 4096 but this internal tag\n> number is used to isolate different neutron subnets, not tenants. \n> \n> A tenant could create 10 neutron networks each with its own subnet and\n> then start 10 instances each attached to a separate net/subnet. If\n> these instances would be scheduled on the same compute node then they\n> would all use different internal VLAN IDs (locally unique to that\n> node).\n> \n>  \n> \n> Basically, you?re right that there is a built-in limitation of 4096\n> instances attached to 4096 different Neutron net/subnets on a compute\n> node, but it?s not realistic to actually start that many instances on\n> a compute node.\n> \n>  \n> \n> George\n> \n>  \n> \n>  \n> \n>                                    \n> ______________________________________________________________________\n> From: BYEONG-GI KIM [mailto:kimbyeonggi at gmail.com] \n> Sent: Wednesday, September 17, 2014 8:47 PM\n> To: openstack at lists.openstack.org\n> Subject: [Openstack] Question about VXLAN support\n> \n> \n>  \n> \n> Hello.\n> \n>  \n> \n> \n> I have a question about the VXLAN support on OpenStack.\n> \n> \n>  \n> \n> \n> As far as I know, the OVS operates like the below:\n> \n> \n>  \n> \n> \n> 1. A tag number is created to identify each tenant, and it is used\n> between br-int and br-tun. Furthermore the tag number is identified as\n> a VLAN ID (I checked it via tcpdump).\n> \n> \n>  \n> \n> \n> 2. After the packet arrived at br-tun, it is encapsulated and VNI\n> (VXLAN Network Identifier) is attached. The binding information\n> between the VLAN ID (tag number) and the VNI is stored in OVSDB. \n> \n> \n>  \n> \n> \n> If the operation is correct, it seems that the number of tenants which\n> can be created is still limited to about 4000, which is the supported\n> range of VLAN, because the tag number is used to identify each tenant\n> at the inside of br-int regardless of the supported range of VNI. \n> \n> \n>  \n> \n> \n> If more than 5000 tenants are created in a Compute Node, how could be\n> these identified after the packet arrived at br-int? In the theory,\n> the 4500th tenant should have 4500 tag number but the tag number is\n> presented as VLAN ID so that it cannot be assigned over 4096.\n> \n> \n>  \n> \n> \n> Any advice and comment would really be appreciated.\n> \n> \n>  \n> \n> \n> Best regards\n> \n> \n>  \n> \n> \n> Byeong-Gi KIM\n> \n> \n>  \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<413FEEF1743111439393FB76D0221E482799F9B0@leopard.zoo.q9networks.com>',NULL),('<1411120929429.eb8c45ca@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-19 03:02:10',-25200,'2014-09-19 10:02:10',NULL,'[Openstack] able to ping but not able to ssh to instance','Just to confirm if iptables are the issue try stopping iptables and see if it works and then you can debug further.?\nSent from Mailbox\n\nOn Fri, Sep 19, 2014 at 3:55 AM, Srinivasreddy R\n<srinivasreddy4390 at gmail.com> wrote:\n\n> hi,\n> i had addeed  a rule for (ingress, tcp, port 22 and cidr 0.0.0.0/0).  still\n> not able to ssh .\n> my instance overview\n> http://paste.openstack.org/show/113170/\n> i pasted my ip tables [ nat, mangle,filter] output ..\n> please let me know i want to add or delete any thing in iptables .\n> http://paste.openstack.org/show/113164/\n> thanks,\n> srinivas.\n> On Fri, Sep 19, 2014 at 12:39 PM, Akilesh K <akilesh1597 at gmail.com> wrote:\n>> The mail from Andreas was correct you need to add a rule for (ingress,\n>> tcp, port 22 and cidr 0.0.0.0/0).\n>>\n>> In case the rule is already there. check the host firewall rules using\n>> iptables -t nat -L\n>> iptables -t mangle -L\n>> iptables -t filter -L\n>>\n>> None of the tables should have any rule.\n>>\n>> On Fri, Sep 19, 2014 at 9:41 AM, Srinivasreddy R <\n>> srinivasreddy4390 at gmail.com> wrote:\n>>\n>>> hi,\n>>> i have checked security group rules .\n>>> my instance is pinging to router and even a device  in external network .\n>>> mostly my problem may in host\'s firewall .\n>>> how can i identify which rule is dropping the ssh traffic .?\n>>> how can  i confirm that ssh traffic is blocked at firewall .?\n>>> i there any way to see the firewall dropped packets ?\n>>>\n>>> thanks ,\n>>> srinivas.\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>>\n>>> On Thu, Sep 18, 2014 at 7:36 PM, Akilesh K <akilesh1597 at gmail.com> wrote:\n>>>\n>>>> I believe you have checked the security group rules. Make sure the\n>>>> instance is able to ping the router. If yes the problem lies in your host\'s\n>>>> firewall rules. Flush the hosts iptable rules(you may take a backup before\n>>>> you do that).\n>>>>\n>>>> On Thu, Sep 18, 2014 at 7:32 PM, Srinivasreddy R <\n>>>> srinivasreddy4390 at gmail.com> wrote:\n>>>>\n>>>>> hi ,\n>>>>> thanks for your reply .\n>>>>>\n>>>>> 1. i have checked ssh server is running in instance ..\n>>>>>     ssh from one instance to another is possible using private\n>>>>> network[demo-net] .\n>>>>> 2. checked  ssh is running in port 22\n>>>>> 3. telnet <ip>  22 is not working .\n>>>>>\n>>>>>\n>>>>> 4. output when i run ssh using verbose  pasted at\n>>>>>\n>>>>> http://paste.openstack.org/show/112860/\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>> ==================================\n>>>>> ip tables output\n>>>>>\n>>>>> my internal network for vm is 11.0.0.x and external network is\n>>>>> 172.0.0.x\n>>>>>\n>>>>>\n>>>>> root at user-ThinkCentre-M73:/home/user# ip netns exec\n>>>>> qrouter-f6e00f94-1c6d-4cf5-8cae-319e393240fe  iptables -t nat -S\n>>>>> -P PREROUTING ACCEPT\n>>>>> -P INPUT ACCEPT\n>>>>> -P OUTPUT ACCEPT\n>>>>> -P POSTROUTING ACCEPT\n>>>>> -N neutron-l3-agent-OUTPUT\n>>>>> -N neutron-l3-agent-POSTROUTING\n>>>>> -N neutron-l3-agent-PREROUTING\n>>>>> -N neutron-l3-agent-float-snat\n>>>>> -N neutron-l3-agent-snat\n>>>>> -N neutron-postrouting-bottom\n>>>>> -A PREROUTING -j neutron-l3-agent-PREROUTING\n>>>>> -A OUTPUT -j neutron-l3-agent-OUTPUT\n>>>>> -A POSTROUTING -j neutron-l3-agent-POSTROUTING\n>>>>> -A POSTROUTING -j neutron-postrouting-bottom\n>>>>> -A neutron-l3-agent-OUTPUT -d 172.0.0.7/32 -j DNAT --to-destination\n>>>>> 11.0.0.9\n>>>>> -A neutron-l3-agent-OUTPUT -d 172.0.0.3/32 -j DNAT --to-destination\n>>>>> 11.0.0.2\n>>>>> -A neutron-l3-agent-OUTPUT -d 172.0.0.4/32 -j DNAT --to-destination\n>>>>> 11.0.0.5\n>>>>> -A neutron-l3-agent-POSTROUTING ! -i qg-ec80d9fb-82 ! -o qg-ec80d9fb-82\n>>>>> -m conntrack ! --ctstate DNAT -j ACCEPT\n>>>>> -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp\n>>>>> --dport 80 -j REDIRECT --to-ports 9697\n>>>>> -A neutron-l3-agent-PREROUTING -d 172.0.0.7/32 -j DNAT\n>>>>> --to-destination 11.0.0.9\n>>>>> -A neutron-l3-agent-PREROUTING -d 172.0.0.3/32 -j DNAT\n>>>>> --to-destination 11.0.0.2\n>>>>> -A neutron-l3-agent-PREROUTING -d 172.0.0.4/32 -j DNAT\n>>>>> --to-destination 11.0.0.5\n>>>>> -A neutron-l3-agent-float-snat -s 11.0.0.9/32 -j SNAT --to-source\n>>>>> 172.0.0.7\n>>>>> -A neutron-l3-agent-float-snat -s 11.0.0.2/32 -j SNAT --to-source\n>>>>> 172.0.0.3\n>>>>> -A neutron-l3-agent-float-snat -s 11.0.0.5/32 -j SNAT --to-source\n>>>>> 172.0.0.4\n>>>>> -A neutron-l3-agent-snat -j neutron-l3-agent-float-snat\n>>>>> -A neutron-l3-agent-snat -s 11.0.0.0/24 -j SNAT --to-source 172.0.0.2\n>>>>> -A neutron-postrouting-bottom -j neutron-l3-agent-snat\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>> =====================\n>>>>> i pasted my dump flows of br-tun at\n>>>>> http://paste.openstack.org/show/112859/\n>>>>>\n>>>>>\n>>>>>\n>>>>> as per the doc\n>>>>>  https://openstack.redhat.com/Networking_in_too_much_detail\n>>>>>\n>>>>> br-ex is connected to router , router is connected to br-int , br-int\n>>>>> is connected to bt-tun .\n>>>>>\n>>>>> i have captured at br-int . my ssh request is reaching to br-int but\n>>>>> not going through tunnel .\n>>>>>\n>>>>> please help me .\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>> thanks,\n>>>>> srinivas.\n>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>>> On Wed, Sep 17, 2014 at 9:30 PM, Sajith Kariyawasam <sajhak at gmail.com>\n>>>>> wrote:\n>>>>>\n>>>>>> Hi,\n>>>>>>\n>>>>>> Could be due to,\n>>>>>>     ssh server is not up and running in your instance,\n>>>>>>     or running in a different port rather than port 22,\n>>>>>>     or, ssh port access is restricted in openstack key pair\n>>>>>> configuration\n>>>>>>\n>>>>>> You could also try telnet to check the connectivity,\n>>>>>> $ telnet <ip> 22\n>>>>>>\n>>>>>> Thanks,\n>>>>>> Sajith\n>>>>>>\n>>>>>>\n>>>>>> On Wed, Sep 17, 2014 at 8:59 PM, Zolt?n Lajos Kis <\n>>>>>> zoltan.lajos.kis at ericsson.com> wrote:\n>>>>>>\n>>>>>>>  Hi,\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>> What?s the output of running ssh with the verbose (-v) flag?\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>> BR,\n>>>>>>>\n>>>>>>> Zoltan\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>> *From:* Srinivasreddy R [mailto:srinivasreddy4390 at gmail.com]\n>>>>>>> *Sent:* Wednesday, September 17, 2014 5:16 PM\n>>>>>>> *To:* openstack at lists.openstack.org\n>>>>>>> *Subject:* [Openstack] able to ping but not able to ssh to instance\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>> hi,\n>>>>>>>\n>>>>>>> i am able to ping my instance form external network .\n>>>>>>>\n>>>>>>> but  not able to ssh to the instance .\n>>>>>>>\n>>>>>>> i am using floating ip s for ping,ssh.\n>>>>>>>\n>>>>>>> please help me .\n>>>>>>>\n>>>>>>> thanks,\n>>>>>>> srinivas.\n>>>>>>>\n>>>>>>> _______________________________________________\n>>>>>>> Mailing list:\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>> Post to     : openstack at lists.openstack.org\n>>>>>>> Unsubscribe :\n>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>>>\n>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> --\n>>>>>> Best Regards\n>>>>>> Sajith\n>>>>>>\n>>>>>\n>>>>>\n>>>>> _______________________________________________\n>>>>> Mailing list:\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>> Post to     : openstack at lists.openstack.org\n>>>>> Unsubscribe :\n>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>\n>>>>>\n>>>>\n>>>\n>>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140919/0fec203b/attachment.html>\n\n','<CAJP4VWhzoRq+a_ha+BygzCFVbQGswkV_uferctO7ZTUakVf5BQ@mail.gmail.com>',NULL),('<1411130338.4285.81.camel@parato.micasa>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 14:38:58',7200,'2014-09-19 12:38:58',NULL,'[openstack-dev] [metrics] Another issue when analyzing SSH\n Gerrit (as young as August 2014)','On Fri, 2014-09-19 at 11:39 +0100, Daniel P. Berrange wrote:\n> On Fri, Sep 19, 2014 at 12:30:50PM +0200, Daniel Izquierdo wrote:\n> > Hi!\n> > \n> > After having a more in depth review of data coming from Gerrit, some other\n> > issues appear when using the SSH Gerrit API.\n> > \n> > Some of the dates when reviewing the code (Code-Review, Verified, etc) seem\n> > to be inconsistent with the data found in the comments section.\n> > \n> > Example: issue https://review.openstack.org/#/c/98688/  (Heat project).\n> > \n> > Let\'s take the PatchSet 44.\n> > \n> > $ ssh -p 29418 review.openstack.org gerrit query 98688 --format=JSON\n> > --files --comments --patch-sets --all-approvals --commit-message\n> > --submit-records\n> > \n> > After parsing a bit the JSON file...\n> > \n> > Revision (patchset) 44 (cf7819ccdbf8999fc963e9c8d400c932ad780674)\n> >   Date: 2014-08-14 03:18:48\n> >   Code-Review: 1\n> >     Date: 2014-07-23 07:01:31\n> >   Code-Review: 1\n> >     Date: 2014-07-31 11:16:21\n> >   Code-Review: 1\n> >     Date: 2014-08-01 10:53:28\n> >   Code-Review: 2\n> >     Date: 2014-08-12 20:15:14\n> >   Code-Review: -1\n> >     Date: 2014-08-14 10:23:55\n> >   Workflow: -1\n> >     Date: 2014-08-18 00:36:32\n> >   Verified: 1\n> >     Date: 2014-09-01 12:39:05\n> > \n> > \n> > \n> > As you can see, the date of some of the reviews are older than the upload\n> > date of the patchset 44 (Aug 14 3:18).\n> \n> It looks like Patchset 44 is a trivial update of previous patchsets. When\n> gerrit detects this, the votes from previous patchsets are copied across\n> to the new patchset, and the time of those votes is preserved, since they\n> are not actual new votes. So in that way, you can get votes which are\n> older than the patchset itself.\n\nThanks a lot for the clarification. In that case, I understand that the\n\"safe\" way of knowing to which patchset corresponds a given approval is\nto look at the dates (of the approval and of the patchset), not at the\npatchset number. Do you think that\'s right?\n\n	Jesus.\n\n> Regards,\n> Daniel\n\n-- \nBitergia: http://bitergia.com\n/me at Twitter: https://twitter.com/jgbarah\n\n\n\n','<20140919103909.GB15899@redhat.com>',NULL),('<1411130939-sup-9928@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 06:07:44',-25200,'2014-09-19 13:07:44',NULL,'[openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed\n	Queues','Excerpts from Eoghan Glynn\'s message of 2014-09-19 04:23:55 -0700:\n> \n> > Hi All,\n> > \n> > My understanding of Zaqar is that it\'s like SQS. SQS uses distributed queues,\n> > which have a few unusual properties [0]:\n> > Message Order\n> > \n> > \n> > Amazon SQS makes a best effort to preserve order in messages, but due to the\n> > distributed nature of the queue, we cannot guarantee you will receive\n> > messages in the exact order you sent them. If your system requires that\n> > order be preserved, we recommend you place sequencing information in each\n> > message so you can reorder the messages upon receipt.\n> > At-Least-Once Delivery\n> > \n> > \n> > Amazon SQS stores copies of your messages on multiple servers for redundancy\n> > and high availability. On rare occasions, one of the servers storing a copy\n> > of a message might be unavailable when you receive or delete the message. If\n> > that occurs, the copy of the message will not be deleted on that unavailable\n> > server, and you might get that message copy again when you receive messages.\n> > Because of this, you must design your application to be idempotent (i.e., it\n> > must not be adversely affected if it processes the same message more than\n> > once).\n> > Message Sample\n> > \n> > \n> > The behavior of retrieving messages from the queue depends whether you are\n> > using short (standard) polling, the default behavior, or long polling. For\n> > more information about long polling, see Amazon SQS Long Polling .\n> > \n> > With short polling, when you retrieve messages from the queue, Amazon SQS\n> > samples a subset of the servers (based on a weighted random distribution)\n> > and returns messages from just those servers. This means that a particular\n> > receive request might not return all your messages. Or, if you have a small\n> > number of messages in your queue (less than 1000), it means a particular\n> > request might not return any of your messages, whereas a subsequent request\n> > will. If you keep retrieving from your queues, Amazon SQS will sample all of\n> > the servers, and you will receive all of your messages.\n> > \n> > The following figure shows short polling behavior of messages being returned\n> > after one of your system components makes a receive request. Amazon SQS\n> > samples several of the servers (in gray) and returns the messages from those\n> > servers (Message A, C, D, and B). Message E is not returned to this\n> > particular request, but it would be returned to a subsequent request.\n> > \n> > \n> > \n> > \n> > \n> > \n> > \n> > Presumably SQS has these properties because it makes the system scalable, if\n> > so does Zaqar have the same properties (not just making these same\n> > guarantees in the API, but actually having these properties in the\n> > backends)? And if not, why? I looked on the wiki [1] for information on\n> > this, but couldn\'t find anything.\n> \n> The premise of this thread is flawed I think.\n> \n> It seems to be predicated on a direct quote from the public\n> documentation of a closed-source system justifying some\n> assumptions about the internal architecture and design goals\n> of that closed-source system.\n> \n> It then proceeds to hold zaqar to account for not making\n> the same choices as that closed-source system.\n> \n\nI don\'t think we want Zaqar to make the same choices. OpenStack\'s\nconstraints are different from AWS\'s.\n\nI want to highlight that our expectations are for the API to support\ndeploying at scale. SQS _clearly_ started with a point of extreme scale\nfor the deployer, and thus is a good example of an API that is limited\nenough to scale like that.\n\nWhat has always been the concern is that Zaqar would make it extremely\ncomplicated and/or costly to get to that level.\n\n> This puts the zaqar folks in a no-win situation, as it\'s hard\n> to refute such arguments when they have no visibility over\n> the innards of that closed-source system.\n> \n\nNobody expects to know the insides. But the outsides, the parts that\nare public, are brilliant because they are _limited_, and yet they still\nsupport many many use cases.\n\n> Sure, the assumption may well be correct that the designers\n> of SQS made the choice to expose applications to out-of-order\n> messages as this was the only practical way of acheiving their\n> scalability goals.\n> \n> But since the code isn\'t on github and the design discussions\n> aren\'t publicly archived, we have no way of validating that.\n> \n\nWe don\'t need to see the code. Not requiring ordering makes the whole\nproblem easier to reason about. You don\'t need explicit pools anymore.\nJust throw messages wherever, and make sure that everywhere gets\npolled on a reasonable enough frequency. This is the kind of thing\noperations loves. No global state means no split brain to avoid, no\nsynchronization. Does it solve all problems? no. But it solves a single\none, REALLY well.\n\nFrankly I don\'t understand why there would be this argument to hold on\nto so many use cases and so much API surface area. Zaqar\'s life gets\neasier without ordering guarantees or message browsing. And it still\nretains _many_ of its potential users.\n\n\n','<1875819006.12487299.1411125835282.JavaMail.zimbra@redhat.com>',NULL),('<1411133282.4417.19.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 15:28:02',7200,'2014-09-19 13:28:02',NULL,'[openstack-dev] [neutron] vxlan port iptables configuration','Hi\nI just was playing around with various neutron-openvswitch-agent vxlan\nconfigurations. The default port for vxlan traffic is 4789. I had\nexpected that when the neutron-openvswitch-agent reads the configured\nvxlan port (or gets the default) it also would add an iptables rule to\nallow incoming traffic via this port. But this did not happen.\n\n\nIs it because such an iptables setup is to be considered as hypervisor\nsetup which is not done by openstack? Or should this be the job of the\nfirewall driver (in my case ovshybridiptablesfirewall driver)?\n\nAny thoughts on this?\n\nThanks\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1411134288-sup-4255@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 11:31:10',-25200,'2014-09-19 18:31:10',NULL,'[openstack-dev] [Heat][Zaqar] Integration plan moving forward','Excerpts from Flavio Percoco\'s message of 2014-09-18 02:07:09 -0700:\n> Greetings,\n> \n> If I recall correctly, Heat was planning to adopt Zaqar regardless of\n> the result of the graduation attempt (please correct me if I\'m wrong).\n> Based on this assumption, I\'d like to start working on a plan forward to\n> make this integration happen.\n> \n> So far, these are the use cases I\'ve collected from past discussions:\n> \n> * Notify  heat user before an action is taken, and after - Heat may want\n> to wait  for a response before proceeding - notifications not\n> necessarily needed  and signed read-only queues might help, but not\n> necessary\n>     * For integrating with user\'s tools\n>         * Monitoring\n>         * Control surface\n>         * Config management tools\n>     * Does not require notifications and/or read-only/signed queue endpoints\n>         *[These may be helpful, but were not brought up in the discussion]\n\nThis is perhaps the most important need. It would be fully satisfied by\nout of order messages as long as we have guaranteed \"at least once\"\ndelivery.\n\n[for the rest, I\'ve reduced the indent, as I don\'t think they were meant\nto be underneath the one above]\n\n> * Subscribe to an aggregate feed of interesting events from other\n>   open-stack components (such as Nova)\n>     * Heat is often deployed in a different place than other\n>       components and doesn\'t have access to the AMQP bus\n>     * Large  deployments consist of multiple AMQP brokers, and there\n>       doesn\'t seem to  be a nice way to aggregate all those events [need to\n>       confirm]\n\nI\'ve also heard tell that Ceilometer wants to be a sieve for these. I\'ve\nno idea why that makes sense, but I have heard it said.\n\n> * Push metadata updates to os-collect-config agent running in\n>   servers, instead of having them poll Heat\n\nThis one is fine with an out of order durable queue.\n\n> \n> \n> Few questions that I think we should start from:\n> \n> - Does the above list cover Heat\'s needs?\n> - Which of the use cases listed above should be addressed first?\n> - Can we split the above into milestones w/ due dates?\n> \n> \n> Thanks,\n> Flavio\n> \n\n\n','<541AA0BD.7010003@redhat.com>',NULL),('<1411151473-sup-2979@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 11:34:26',-25200,'2014-09-19 18:34:26',NULL,'[openstack-dev] [Heat][Zaqar] Integration plan moving forward','Excerpts from Flavio Percoco\'s message of 2014-09-19 02:37:08 -0700:\n> On 09/18/2014 11:51 AM, Angus Salkeld wrote:\n> > \n> > On 18/09/2014 7:11 PM, \"Flavio Percoco\" <flavio at redhat.com\n> > <mailto:flavio at redhat.com>> wrote:\n> >>\n> >> Greetings,\n> >>\n> >> If I recall correctly, Heat was planning to adopt Zaqar regardless of\n> >> the result of the graduation attempt (please correct me if I\'m wrong).\n> >> Based on this assumption, I\'d like to start working on a plan forward to\n> >> make this integration happen.\n> >>\n> >> So far, these are the use cases I\'ve collected from past discussions:\n> >>\n> >> * Notify  heat user before an action is taken, and after - Heat may want\n> >> to wait  for a response before proceeding - notifications not\n> >> necessarily needed  and signed read-only queues might help, but not\n> >> necessary\n> >>     * For integrating with user\'s tools\n> >>         * Monitoring\n> >>         * Control surface\n> >>         * Config management tools\n> >>     * Does not require notifications and/or read-only/signed queue\n> > endpoints\n> >>         *[These may be helpful, but were not brought up in the discussion]\n> >>     * Subscribe to an aggregate feed of interesting events from other\n> >> open-stack components (such as Nova)\n> >>         * Heat is often deployed in a different place than other\n> >> components and doesn\'t have access to the AMQP bus\n> >>         * Large  deployments consist of multiple AMQP brokers, and there\n> >> doesn\'t seem to  be a nice way to aggregate all those events [need to\n> >> confirm]\n> >>     * Push metadata updates to os-collect-config agent running in\n> >> servers, instead of having them poll Heat\n> >>\n> >>\n> >> Few questions that I think we should start from:\n> >>\n> >> - Does the above list cover Heat\'s needs?\n> >> - Which of the use cases listed above should be addressed first?\n> > \n> > IMHO it would be great to simply replace the event store we have\n> > currently, so that the user can get a stream of progress messages during\n> > the deployment.\n> \n> Could you point me to the right piece of code and/or documentation so I\n> can understand better what it does and where do you want it to go?\n\nhttps://git.openstack.org/cgit/openstack/heat/tree/heat/engine/event.py\n\nWe currently use db_api to store these in the database, which is costly.\n\nWould be much better if we could just shove them into a message queue for\nthe user. It is problematic though, as we have event-list and event-show\nin the Heat API which basically work the same as the things we\'ve been\nwanting removed from Zaqar\'s API: access by ID and pagination. ;)\n\nI think ideally we\'d deprecate those or populate them with nothing if\nthe user has opted to use messaging instead.\n\n\n','<541BF944.1000505@redhat.com>',NULL),('<1411151866-sup-7528@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 11:44:18',-25200,'2014-09-19 18:44:18',NULL,'[openstack-dev] Please do *NOT* use \"vendorized\" versions of\n	anything (here: glanceclient using requests.packages.urllib3)','Excerpts from Ian Cordasco\'s message of 2014-09-18 10:33:04 -0700:\n> \n> On 9/18/14, 11:29 AM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> >Excerpts from Donald Stufft\'s message of 2014-09-18 07:30:27 -0700:\n> >> \n> >> > On Sep 18, 2014, at 10:18 AM, Clint Byrum <clint at fewbar.com> wrote:\n> >> > \n> >> > Excerpts from Donald Stufft\'s message of 2014-09-18 04:58:06 -0700:\n> >> >> \n> >> >>> On Sep 18, 2014, at 7:54 AM, Thomas Goirand <zigo at debian.org> wrote:\n> >> >>> \n> >> >>>> \n> >> >>>> Linux distributions are not the end be all of distribution models\n> >>and\n> >> >>>> they don?t get to dictate to upstream.\n> >> >>> \n> >> >>> Well, distributions is where the final user is, and where software\n> >>gets\n> >> >>> consumed. Our priority should be the end users.\n> >> >> \n> >> >> \n> >> >> Distributions are not the only place that people get their software\n> >>from,\n> >> >> unless you think that the ~3 million downloads requests has received\n> >> >> on PyPI in the last 30 days are distributions downloading requests to\n> >> >> package in their OSs.\n> >> >> \n> >> > \n> >> > Do pypi users not also need to be able to detect and fix any versions\n> >> > of libraries they might have? If one has some virtualenvs with various\n> >> > libraries and apps installed and no --system-site-packages, one would\n> >> > probably still want to run \'pip freeze\' in all of them and find out\n> >>what\n> >> > libraries are there and need to be fixed.\n> >> > \n> >> > Anyway, generally security updates require a comprehensive strategy.\n> >> > One common comprehensive strategy is version assertion.\n> >> > \n> >> > Vendoring complicates that immensely.\n> >> \n> >> It doesn?t really matter. PyPI doesn?t dictate to projects who host\n> >>there what\n> >> that project is allowed to do except in some very broad circumstances.\n> >>Whether\n> >> or not requests *should* do this doesn\'t really have any bearing on what\n> >> Openstack should do to cope with it. The facts are that requests does\n> >>it, and\n> >> that people pulling things from PyPI is an actual platform that needs\n> >>thought\n> >> about.\n> >> \n> >> This leaves Openstack with a few reasonable/sane options:\n> >> \n> >> 1) Decide that vendoring in requests is unacceptable to what Openstack\n> >>as a\n> >>    project is willing to support, and cease the use of requests.\n> >> 2) Decide that what requests offers is good enough that it outweighs\n> >>the fact\n> >>    that it vendors urllib3 and continue using it.\n> >> \n> >\n> >There\'s also 3) fork requests, which is the democratic way to vote out\n> >an upstream that isn\'t supporting the needs of the masses.\n> \n> Given requests? download count, I have to doubt that OpenStack users\n> constitute the masses in this case.\n> \n\nThis wasn\'t \"the masses\" from the requests stand point, but from the\nOpenStack standpoint. Consider the case of a small island territory\nof a much larger nation. At some point most of them have claimed their\nindependence from the larger nation unless the larger nation is willing\nto step up and make them a full member with a real vote. This allows\nthem to act in their best interest. So even if it means a much more\ndifficult road, it is the road most advantageous to them.\n\nAlso upon reflection, it\'s a bit interesting that forking requests is\nbeing dismissed so quickly, when in essence, requests maintains a fork\nof urllib3 in tree (albeit, one that is just a fork from the _releases_,\nnot from the whole project).\n\n> >I don\'t think we\'re anywhere near there, but I wanted to make it clear\n> >there _is_ a more extreme option.\n> >\n> >> If the 2nd option is chosen, then doing anything but supporting the\n> >>fact that\n> >> requests vendors urllib3 within the code that openstack writes is\n> >>hurting the\n> >> users who fetch these projects from PyPI because you don\'t agree with\n> >>one of\n> >> the choices that requests makes. By all means do conditional imports to\n> >>lessen\n> >> the impact that the choice requests has made (and the one that\n> >>Openstack has\n> >> made to use requests) on downstream distributors, but unconditionally\n> >>importing\n> >> from the top level urllib3 for use within requests is flat out wrong.\n> >> \n> >> Obviously neither of these options excludes the choice to lean on\n> >>requests to\n> >> reverse this decision as well. However that is best done elsewhere as\n> >>the\n> >> person making that decision isn\'t a member of these mailing lists as\n> >>far as\n> >> I am aware.\n> >> \n> >\n> >To be clear, I think we should keep using requests. But we should lend\n> >our influence upstream and explain that our users are required to deal\n> >with this in a way that perhaps hasn\'t been considered or given the\n> >appropriate priority.\n> \n> It?s been considered several times. There have been multiple issues.\n> There?s more than just the one you linked to. The decision is highly\n> unlikely to change whether it?s coming from a group of people in OpenStack\n> or another distribution package maintainer.\n> \n\nIndeed, hence my thinking that forking requests might be in order. Even\nif that fork is just a long lived fork that stays mostly in sync, but\nwithout urllib3 vendored. I think that has actually already happened in\nthe distros... so I wonder how painful it would be to do the same thing\non pypi, and let the distros just consume that.\n\nAnyway, I\'m not going to take that challenge on, so I think this\ndiscussion should end here. We\'ll just have to let the distros keep doing\nthe job of supporting this form of risk assessment. The rest of us are\njust going to have to keep trying the actual exploit test code everywhere.\n\n\n','<D0408041.2FF3%ian.cordasco@rackspace.com>',NULL),('<1411193227.45879.YahooMailNeo@web171603.mail.ir2.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-20 07:07:07',3600,'2014-09-20 06:07:07',NULL,'[Openstack] cinder create error','\n>>>> root at controller:/var/log/cinder# more cinder-scheduler.log\n>>>> 2014-09-12 22:47:41.757 10328 ERROR cinder.scheduler.flows.create_volume [req-5c268fcf-5c4d-49ed-be1b-0460411e76b0 33444db757c14559add65a2e606c2102 d4c3bf6ee2af44129fc38bf76f4a5623 - - -] Failed \n>>>> to schedule_create_volume: No valid host was found. \n>>>> 2014-09-12 22:56:01.742 10328 WARNING cinder.context [-] Arguments dropped when creating context: {\'user\': u\'dfbdec26a06a4c5cb35f994937b092fb\', \'tenant\': u\'0faf8d7dfdac4a53af195b5436992976\', \'use\n>>>> r_identity\': u\'dfbdec26a06a4c5cb35f994937b092fb 0faf8d7dfdac4a53af195b5436992976 - - -\'}\n>>>> 2014-09-12 22:56:01.765 10328 ERROR cinder.scheduler.flows.create_volume [req-230d0a9c-851c-4612-9549-cc9fb07a2197 dfbdec26a06a4c5cb35f994937b092fb 0faf8d7dfdac4a53af195b5436992976 - - -] Failed \n>>>> to schedule_create_volume: No valid host was found. \n>>>> root at controller:/var/log/cinder#  \n\nIMHO, tke key to resolve this problem is to look back on cinder-scheduler.log where you see this error:\n\n\n>> Failed to schedule_create_volume: No valid host was found. \n\nAlso looking on your cinder.conf, you seem to be using LVM over iSCSI as a storage, is that correct?\n\"No valid host was found\" probably means some cinder or iSCSI misconfiguration, ie:\n\n\n\n1.I don\'t see any LVM filters in your config so schedululer may be confised\n2. double check if your hosts really have woorking iSCSI access to your storage? this is often source of many problems\n\n\nCheers,\nRadek.\n\n\n','<CAO2aJAzWW9_85ZYFPC2ydeyFQniSs5B3AmhepKcuoXaeYvP8og@mail.gmail.com>',NULL),('<1411376643.364.1367042615331.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:03:35',0,'2013-04-27 06:03:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-docs-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal11 in workspace <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/>\nCheckout:periodic-glance-docs-stable-grizzly / <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/> - hudson.remoting.Channel at 1dc0dbe0:quantal11\nUsing strategy: Default\nLast Built Revision: Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/glance.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/glance.git\nCommencing build of Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\nChecking out Revision 43c5fdacd62ec6f4e78d466ac5905f2b581a476f (origin/stable/grizzly)\n[periodic-glance-docs-stable-grizzly] $ /bin/bash -xe /tmp/hudson3782242532156087216.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack glance\n+ org=openstack\n+ project=glance\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack glance\n+ org=openstack\n+ project=glance\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' glance == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-glance-docs-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 42178 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-glance-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal11\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'b722e23b-0c4d-4c22-9a0f-1eb5f960cb76\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'43c5fdacd62ec6f4e78d466ac5905f2b581a476f\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal11\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 42178 166.78.63.46 22\'}\nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\nNo distributions at all found for greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires> (line 4))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1411382940.20748.180.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 11:49:00',3600,'2014-09-22 10:49:00',NULL,'[openstack-dev] Thoughts on OpenStack Layers and a Big Tent\n model','Hey\n\nOn Thu, 2014-09-18 at 11:53 -0700, Monty Taylor wrote:\n> Hey all,\n> \n> I\'ve recently been thinking a lot about Sean\'s Layers stuff. So I wrote\n> a blog post which Jim Blair and Devananda were kind enough to help me edit.\n> \n> http://inaugust.com/post/108\n\nLots of great stuff here, but too much to respond to everything in\ndetail.\n\nI love the way you\'ve framed this in terms of the needs of developers,\ndistributors, deployers and end users. I\'d like to make sure we\'re\nfocused on tackling those places where we\'re failing these groups, so:\n\n\n - Developers\n\n   I think we\'re catering pretty well to developers with the \"big tent\"\n   concept of Programs. There\'s been some good discussion about how\n   Programs could be better at embracing projects in their related area,\n   and that would be great to pursue. But the general concept - of \n   endorsing and empowering teams of people collaborating in the\n   OpenStack way - has a lot of legs, I think.\n\n   I also think our release cadence does a pretty good job of serving \n   developers. We\'ve talked many times about the benefit of it, and I\'d \n   like to see it applied to more than just the \"server projects\".\n\n   OTOH, the integrated gate is straining, and a source of frustration \n   for everyone. You raise the question of whether everything currently \n   in the integrated release needs to be co-gated, and I totally agree \n   that needs re-visiting.\n\n\n - Distributors\n\n   We may be doing a better job of catering to distributors than any \n   other group. For example, things like the release cadence, stable \n   branch and common set of dependencies works pretty well.\n\n.  The concept of an integrated release (with an incubation process) is\n   great, because it nicely defines a set of stuff that distributors\n   should ship. Certainly, life would be more difficult for distributors\n   if there was a smaller set of projects in the release and a whole \n   bunch of other projects which are interesting to distro users, but \n   with an ambiguous level of commitment from our community. Right now, \n   our integration process has a huge amount of influence over what \n   gets shipped by distros, and that in turn serves distro users by \n   ensuring a greater level of commonality between distros.\n\n\n - Operators\n\n   I think the feedback we\'ve been getting over the past few cycles \n   suggests we are failing this group the most.\n\n   Operators want to offer a compelling set of services to their users, \n   but they want those services to be stable, performant, and perhaps \n   most importantly, cost-effective. No operator wants to have to\n   invest a huge amount of time in getting a new service running.\n\n   You suggest a \"Production Ready\" tag. Absolutely - our graduation of \n   projects has been interpreted as meaning \"production ready\", when \n   it\'s actually more useful as a signal to distros rather than \n   operators. Graduation does not necessarily imply that a service is\n   ready for \"production\", no matter how you define \"production\".\n\n   I\'d like to think we could give more nuanced advice to operators than\n   a simple tag, but perhaps the information gathering process that\n   projects would need to go through to be awarded that tag would \n   uncover the more detailed information for operators.\n\n   You could question whether the TC is the right body for this \n   process. How might it work if the User Committee owned this?\n\n   There are many other ways we can and should help operators, \n   obviously, but this \"setting expectations\" is the aspect most \n   relevant to this discussion.\n\n\n - End users\n\n   You\'re right that we don\'t pay sufficient attention to this group.\n   For me, the highest priority challenge here is interoperability. \n   Particularly interoperability between public clouds.\n\n   The only real interop effort to date you can point to is the \n   board-owned DefCore and RefStack efforts. The idea being that a\n   trademark program with API testing requirements will focus minds on\n   interoperability. I\'d love us (as a community) to be making more\n   rapid progress on interoperability, but at least there are no\n   encouraging signs that we should make some definite progress soon.\n\n   Your end-user focused concrete suggestions (#7-#10) are interesting,\n   and I find myself thinking about how much of a positive effect on \n   interop each of them would have. For example, making our tools \n   multi-cloud aware would help encourage people to demand interop from \n   their providers. I also agree that end-user tools should support \n   older versions of our APIs, but don\'t think that necessarily implies \n   rolling releases.\n\n\n\nSo, if I was to pick the areas which I think would address our most\npressing challenges:\n\n  1) Shrinking the integrated gate, and allowing per-project testing \n     strategies other than shoving every integrated project into the \n     gate.\n\n  2) Giving more direction to operators about the readiness of our \n     projects for different use cases. A process around awarding \n     \"Production Ready\" tags sounds interesting, but I suspect the \n     information uncovered by the process might be as interesting to \n     operators as the tag itself. Consider whether it makes sense for \n     the User Committee to own this process, rather than the TC.\n\n  3) Driving towards concrete and measurable progress on interop. \n     Establishing the defcore/refstack process is great, but I\'m super \n     anxious to see it make a tangible difference to end users.\n\nThanks,\nMark.\n  \n\n\n\n','<541B2A12.9040007@inaugust.com>',NULL),('<1411406615.14193.33.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 12:23:35',-18000,'2014-09-22 17:23:35',NULL,'[openstack-dev] [neutron] [infra] Python 2.6 tests can\'t possibly\n be passing in neutron','My team just ran into an issue where neutron was not passing unit tests\nwhen run under Python 2.6.  We tracked this down to a test support\nfunction using collections.OrderedDict.  This was in locally forked\ncode, but when I compared it to upstream code, I found that the code in\nupstream neutron is identical?meaning that upstream neutron cannot\npossibly be passing unit tests under Python 2.6.  Yet, somehow, the\nneutron reviews I\'ve looked at are passing the Python 2.6 gate!  Any\nideas as to how this could be happening?\n\nFor the record, the problem is in neutron/tests/unit/test_api_v2.py:148,\nin the function _get_collection_kwargs(), which uses\ncollections.OrderedDict.  As there\'s no reason to use OrderedDict here\nthat I can see?there\'s no definite order on the initialization, and all\nconsumers pass it to an assert_called_once_with() method with the \'**\'\noperator?I have proposed a review[1] to replace it with a simple dict.\n\n[1] https://review.openstack.org/#/c/123189/\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1411408346-sup-7900@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 10:57:37',-25200,'2014-09-22 17:57:37',NULL,'[openstack-dev] Oslo messaging vs zaqar','Geoff, do you expect all of our users to write all of their messaging\ncode in Python?\n\noslo.messaging is a _python_ library.\n\nZaqar is a service with a REST API -- accessible to any application.\n\nAs Zane\'s sarcastic reply implied, these are as related as sharks are\nto tornados. Could they be combined? Yes [1]. But the only result would be\ndead people and sharks strewn about the landscape.\n\n[1] http://www.imdb.com/title/tt2724064/\n\nExcerpts from Geoff O\'Callaghan\'s message of 2014-09-20 01:17:45 -0700:\n> Hi all,\n> I\'m just trying to understand the messaging strategy in openstack.    It\n> seems we have at least 2 messaging layers.\n> \n> Oslo.messaging and zaqar,  Can someone explain to me why there are two?\n> To quote from the zaqar faq :\n> ---------\n> How does Zaqar compare to oslo.messaging?\n> \n> oslo.messsaging is an RPC library used throughout OpenStack to manage\n> distributed commands by sending messages through different messaging\n> layers. Oslo Messaging was originally developed as an abstraction over\n> AMQP, but has since added support for ZeroMQ.\n> \n> As opposed to Oslo Messaging, Zaqar is a messaging service for the over and\n> under cloud. As a service, it is meant to be consumed by using libraries\n> for different languages. Zaqar currently supports 1 protocol (HTTP) and\n> sits on top of other existing technologies (MongoDB as of version 1.0).\n> --------\n> It seems to my casual view that we could have one and scale that and use it\n> for SQS style messages, internal messaging (which could include logging)\n> all managed by message schemas and QoS.  This would give a very robust and\n> flexible system for endpoints to consume.\n> \n> Is there a plan to consolidate?\n> \n> Rgds\n> Geoff\n\n\n','<CACBaitvw5yr3mJaQ024B1g4MncmEd7qavXnJ15Uame-qxEaqkw@mail.gmail.com>',NULL),('<1411408684.14193.38.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 12:58:04',-18000,'2014-09-22 17:58:04',NULL,'[openstack-dev] [neutron] [infra] Python 2.6 tests can\'t\n possibly be passing in neutron','On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote:\n> What about:\n> \n> https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12\n\nPulling in ordereddict doesn\'t do anything if your code doesn\'t use it\nwhen OrderedDict isn\'t in collections, which is the case here.  Further,\nthere\'s no reason that _get_collection_kwargs() needs to use an\nOrderedDict: it\'s initialized in an arbitrary order (generator\ncomprehension over a set), then later passed to functions with **, which\nconverts it to a plain old dict.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAK+RQeYsBXHbsqTS=10wtotZrNqB16_z42oAr3CRXw=O6oJTiA@mail.gmail.com>',NULL),('<1411411872.675230082@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-09-22 13:51:12',-18000,'2014-09-22 18:51:12',NULL,'[openstack-community] Join Mark Collier on OASIS WateringHole\n	Hangout on September 30','\nJoin Mark Collier, OpenStack Foundation, and other  FOSS and standards experts as the topic of \"How Open Standards and Open Source complement and/or compete\" is discussed.  Topics include has code has replaced formats, whether APIs have replaced standards, and what to make of all the new projects like OpenStack, OpenDaylight, OpenInterconnect and AllSeen. What is \"open\" going to mean in 2020?  Join this live-without-a-net, 30-minute chat. The session is open to all and may be viewed via [ Google+ ]( https://plus.google.com/events/cl4ioj4879j14ssdcd7u1fdb5oc?authkey=CPimkcn-r97SngE ) or the [ OASIS YouTube Channel ]( https://www.youtube.com/user/OASISopen ). \n \nOpen Standards and Open Source: Either/or Both?https://www.oasis-open.org/events/Hangout9-2014[30 Sept @11:00 AM EDT]\n \n-- \nRegards,\n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140922/6bcb2d2b/attachment.html>\n\n',NULL,NULL),('<1411439837-sup-8150@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 20:13:55',-25200,'2014-09-23 03:13:55',NULL,'[openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed\n	Queues','Excerpts from Joe Gordon\'s message of 2014-09-22 19:04:03 -0700:\n> On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter <zbitter at redhat.com> wrote:\n> \n> > On 22/09/14 17:06, Joe Gordon wrote:\n> >\n> >> On Mon, Sep 22, 2014 at 9:58 AM, Zane Bitter <zbitter at redhat.com> wrote:\n> >>\n> >>  On 22/09/14 10:11, Gordon Sim wrote:\n> >>>\n> >>>  On 09/19/2014 09:13 PM, Zane Bitter wrote:\n> >>>>\n> >>>>  SQS offers very, very limited guarantees, and it\'s clear that the\n> >>>>> reason\n> >>>>> for that is to make it massively, massively scalable in the way that\n> >>>>> e.g. S3 is scalable while also remaining comparably durable (S3 is\n> >>>>> supposedly designed for 11 nines, BTW).\n> >>>>>\n> >>>>> Zaqar, meanwhile, seems to be promising the world in terms of\n> >>>>> guarantees. (And then taking it away in the fine print, where it says\n> >>>>> that the operator can disregard many of them, potentially without the\n> >>>>> user\'s knowledge.)\n> >>>>>\n> >>>>> On the other hand, IIUC Zaqar does in fact have a sharding feature\n> >>>>> (\"Pools\") which is its answer to the massive scaling question.\n> >>>>>\n> >>>>>\n> >>>> There are different dimensions to the scaling problem.\n> >>>>\n> >>>>\n> >>> Many thanks for this analysis, Gordon. This is really helpful stuff.\n> >>>\n> >>>   As I understand it, pools don\'t help scaling a given queue since all\n> >>> the\n> >>>\n> >>>> messages for that queue must be in the same pool. At present traffic\n> >>>> through different Zaqar queues are essentially entirely orthogonal\n> >>>> streams. Pooling can help scale the number of such orthogonal streams,\n> >>>> but to be honest, that\'s the easier part of the problem.\n> >>>>\n> >>>>\n> >>> But I think it\'s also the important part of the problem. When I talk\n> >>> about\n> >>> scaling, I mean 1 million clients sending 10 messages per second each,\n> >>> not\n> >>> 10 clients sending 1 million messages per second each.\n> >>>\n> >>> When a user gets to the point that individual queues have massive\n> >>> throughput, it\'s unlikely that a one-size-fits-all cloud offering like\n> >>> Zaqar or SQS is _ever_ going to meet their needs. Those users will want\n> >>> to\n> >>> spin up and configure their own messaging systems on Nova servers, and at\n> >>> that kind of size they\'ll be able to afford to. (In fact, they may not be\n> >>> able to afford _not_ to, assuming per-message-based pricing.)\n> >>>\n> >>>\n> >> Running a message queue that has a high guarantee of not loosing a message\n> >> is hard and SQS promises exactly that, it *will* deliver your message. If\n> >> a\n> >> use case can handle occasionally dropping messages then running your own\n> >> MQ\n> >> makes more sense.\n> >>\n> >> SQS is designed to handle massive queues as well, while I haven\'t found\n> >> any\n> >> examples of queues that have 1 million messages/second being sent or\n> >> received  30k to 100k messages/second is not unheard of [0][1][2].\n> >>\n> >> [0] https://www.youtube.com/watch?v=zwLC5xmCZUs#t=22m53s\n> >> [1] http://java.dzone.com/articles/benchmarking-sqs\n> >> [2]\n> >> http://www.slideshare.net/AmazonWebServices/massive-\n> >> message-processing-with-amazon-sqs-and-amazon-\n> >> dynamodb-arc301-aws-reinvent-2013-28431182\n> >>\n> >\n> > Thanks for digging those up, that\'s really helpful input. I think number\n> > [1] kind of summed up part of what I\'m arguing here though:\n> >\n> > \"But once your requirements get above 35k messages per second, chances are\n> > you need custom solutions anyway; not to mention that while SQS is cheap,\n> > it may become expensive with such loads.\"\n> \n> \n> If you don\'t require the reliability guarantees that SQS provides then\n> perhaps. But I would be surprised to hear that a user can set up something\n> with this level of uptime for less:\n> \n> \"Amazon SQS runs within Amazon?s high-availability data centers, so queues\n> will be available whenever applications need them. To prevent messages from\n> being lost or becoming unavailable, all messages are stored redundantly\n> across multiple servers and data centers.\" [1]\n> \n\nThis is pretty easily doable with gearman or even just using Redis\ndirectly. But it is still ops for end users. The AWS users I\'ve talked to\nwho use SQS do so because they like that they can use RDS, SQS, and ELB,\nand have only one type of thing to operate: their app.\n\n> >\n> >\n> >    There is also the possibility of using the sharding capabilities of the\n> >>>\n> >>>> underlying storage. But the pattern of use will determine how effective\n> >>>> that can be.\n> >>>>\n> >>>> So for example, on the ordering question, if order is defined by a\n> >>>> single sequence number held in the database and atomically incremented\n> >>>> for every message published, that is not likely to be something where\n> >>>> the databases sharding is going to help in scaling the number of\n> >>>> concurrent publications.\n> >>>>\n> >>>> Though sharding would allow scaling the total number messages on the\n> >>>> queue (by distributing them over multiple shards), the total ordering of\n> >>>> those messages reduces it\'s effectiveness in scaling the number of\n> >>>> concurrent getters (e.g. the concurrent subscribers in pub-sub) since\n> >>>> they will all be getting the messages in exactly the same order.\n> >>>>\n> >>>> Strict ordering impacts the competing consumers case also (and is in my\n> >>>> opinion of limited value as a guarantee anyway). At any given time, the\n> >>>> head of the queue is in one shard, and all concurrent claim requests\n> >>>> will contend for messages in that same shard. Though the unsuccessful\n> >>>> claimants may then move to another shard as the head moves, they will\n> >>>> all again try to access the messages in the same order.\n> >>>>\n> >>>> So if Zaqar\'s goal is to scale the number of orthogonal queues, and the\n> >>>> number of messages held at any time within these, the pooling facility\n> >>>> and any sharding capability in the underlying store for a pool would\n> >>>> likely be effective even with the strict ordering guarantee.\n> >>>>\n> >>>>\n> >>> IMHO this is (or should be) the goal - support enormous numbers of\n> >>> small-to-moderate sized queues.\n> >>>\n> >>\n> >>\n> >> If 50,000 messages per second doesn\'t count as small-to-moderate then\n> >> Zaqar\n> >> does not fulfill a major SQS use case.\n> >>\n> >\n> > It\'s not a drop-in replacement, but as I mentioned you can recreate the\n> > SQS semantics exactly *and* get the scalability benefits of that approach\n> > by sharding at the application level and then round-robin polling.\n> \n> > As I also mentioned, this is pretty easy to implement, and is only\n> > required for really big applications that are more likely to be written by\n> > developers who already Know What They\'re Doing(TM). While the reverse\n> > (emulating Zaqar semantics, i.e. FIFO, in SQS) is tricky, error-prone, and\n> > conceivably required by or at least desirable for all kinds of\n> > beginner-level applications. (It\'s also pretty useful for a lot of use\n> > cases in OpenStack itself, where OpenStack services are sending messages to\n> > the user.)\n> \n> \n> \n> I\'m not convinced that is as simple to implement well as you make it out to\n> be, now every receiver has to poll N endpoints instead of 1. How would this\n> work with Long Polling? What is the impact on expanding the number of\n> connections? How do you make this auto scale? etc.\n> \n\nIt\'s pretty easy to setup a select loop on multiple HTTP requests. I\ndon\'t think this complicates things. Also once you assume responsibility\nfor the service that does the queueing, you\'re also more likely to\naccept a binary protocol rather than rely on long poll / REST semantics.\n\nNumber of connections I don\'t understand given the situation above. One\nper client per availability-zone covered?\n\nAuto-scaling is a bit beyond the scope of the discussion. Nobody is\npromising that Zaqar will auto-scale itself.\n\n> I don\'t know enough about the target audience to know if adding the FIFO\n> guarantee is a good trade off or not. But I don\'t follow your use case for\n> OpenStack service sending messages to the user; when do these need to be in\n> order?\n> \n\nI don\'t think the FIFO is needed in most cases. It\'s the kind of thing\nthat really helps you when you need it, but otherwise it\'s just sitting\nthere doing nothing for you, costing your operator more to guarantee.\n\n> >\n> >\n> >    If scaling the number of communicants on a given communication channel\n> >>>\n> >>>> is a goal however, then strict ordering may hamper that. If it does, it\n> >>>> seems to me that this is not just a policy tweak on the underlying\n> >>>> datastore to choose the desired balance between ordering and scale, but\n> >>>> a more fundamental question on the internal structure of the queue\n> >>>> implementation built on top of the datastore.\n> >>>>\n> >>>>\n> >>> I agree with your analysis, but I don\'t think this should be a goal.\n> >>>\n> >>> Note that the user can still implement this themselves using\n> >>> application-level sharding - if you know that in-order delivery is not\n> >>> important to you, then randomly assign clients to a queue and then poll\n> >>> all\n> >>> of the queues in the round-robin. This yields _exactly_ the same\n> >>> semantics\n> >>> as SQS.\n> >>>\n> >>\n> >>\n> >>  The reverse is true of SQS - if you want FIFO then you have to implement\n> >>> re-ordering by sequence number in your application. (I\'m not certain, but\n> >>> it also sounds very much like this situation is ripe for losing messages\n> >>> when your client dies.)\n> >>>\n> >>> So the question is: in which use case do we want to push additional\n> >>> complexity into the application? The case where there are truly massive\n> >>> volumes of messages flowing to a single point? Or the case where the\n> >>> application wants the messages in order?\n> >>>\n> >>> I\'d suggest both that the former applications are better able to handle\n> >>> that extra complexity and that the latter applications are probably more\n> >>> common. So it seems that the Zaqar team made a good decision.\n> >>>\n> >>>\n> >> If Zaqar is supposed to be comparable to amazon SQS, then it has picked\n> >> the\n> >> wrong choice.\n> >>\n> >\n> > It has certainly picked a different choice. It seems like a choice that is\n> > friendlier to beginners and simple applications, while shifting some\n> > complexity to larger applications without excluding them as a use case.\n> > That\'s certainly not an invalid choice.\n> \n> > It isn\'t OpenStack\'s job to be cloning AWS services after all... we can\n> > definitely address the same problems better when we see the opportunity. We\n> > should, of course, think very carefully about all the consequences,\n> > intended and unintended, of changing a model that is already proven in the\n> > field and the market, so I\'m very glad this discussion is happening. But\n> > after digging into it, the choice doesn\'t seem \"wrong\" to me.\n> >\n> \n> To me this is less about valid or invalid choices. The Zaqar team is\n> comparing Zaqar to SQS, but after digging into the two of them, zaqar\n> barely looks like SQS. Zaqar doesn\'t guarantee what IMHO is the most\n> important parts of SQS: the message will be delivered and will never be\n> lost by SQS. Zaqar doesn\'t have the same scaling properties as SQS. Zaqar\n> is aiming for low latency per message, SQS doesn\'t appear to be. So if\n> Zaqar isn\'t SQS what is Zaqar and why should I use it?\n> \n\nI have to agree. I\'d like to see a simple, non-ordered, high latency,\nhigh scale messaging service that can be used cheaply by cloud operators\nand users. What I see instead is a very powerful, ordered, low latency,\nmedium scale messaging service that will likely cost a lot to scale out\nto the thousands of users level.\n\n\n','<CAHXdxOf+iPEQVM8g9ZXMCpBUOzsj4v-t=K-vGkdtWxLzW+ETUA@mail.gmail.com>',NULL),('<1411444844-sup-9342@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 21:02:51',-25200,'2014-09-23 04:02:51',NULL,'[openstack-dev] [Heat] Question regarding Stack updates and\n	templates','Excerpts from Angus Salkeld\'s message of 2014-09-22 20:31:46 -0700:\n> On Tue, Sep 23, 2014 at 1:04 AM, Anant Patil <anant.patil at hp.com> wrote:\n> \n> > Hi,\n> >\n> > In convergence, we discuss about having concurrent updates to a stack. I\n> > wanted to know if it is safe to assume that the an update will be a\n> > super set of it\'s previous updates. Understanding this is critical to\n> > arrive at implementation of concurrent stack operations.\n> >\n> > Assuming that an admin will have VCS setup and will issue requests by\n> > checking-out the template and modifying it, I could see that the updates\n> > will be incremental and not discreet. Is this assumption correct? When\n> > an update is issued before a previous update is complete, would the\n> > template for that be based on the template of previously issued\n> > incomplete update or the last completed one?\n> >\n> \n> I don\'t think you can assume anything about the update. What if the user\n> just posts a\n> totally different template? That is still a valid update. Or they post an\n> empty template\n> to delete the resources.\n\nAgreed. The new template simply replaces the graph with a new version.\nIf that graph happens to change everything, then the old things will now\nbe in a \"should not exist\" desired state and the new template convergence\nshould remove them when it gets to the garbage collection at the end.\n\n\n','<CAA16xcyz1Ysn4jMVpf6FL=WfLkGBe8i_z6h=dB-kRs2YitOAtA@mail.gmail.com>',NULL),('<1411445017-sup-2560@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 21:12:02',-25200,'2014-09-23 04:12:02',NULL,'[openstack-dev] [Heat] Convergence: Backing up template instead\n	of stack','Excerpts from Angus Salkeld\'s message of 2014-09-22 20:15:43 -0700:\n> On Tue, Sep 23, 2014 at 1:09 AM, Anant Patil <anant.patil at hp.com> wrote:\n> \n> > Hi,\n> >\n> > One of the steps in the direction of convergence is to enable Heat\n> > engine to handle concurrent stack operations. The main convergence spec\n> > talks about it. Resource versioning would be needed to handle concurrent\n> > stack operations.\n> >\n> > As of now, while updating a stack, a backup stack is created with a new\n> > ID and only one update runs at a time. If we keep the raw_template\n> > linked to it\'s previous completed template, i.e. have a back up of\n> > template instead of stack, we avoid having backup of stack.\n> >\n> > Since there won\'t be a backup stack and only one stack_id to be dealt\n> > with, resources and their versions can be queried for a stack with that\n> > single ID. The idea is to identify resources for a stack by using stack\n> > id and version. Please let me know your thoughts.\n> >\n> \n> Hi Anant,\n> \n> This seems more complex than it needs to be.\n> \n> I could be wrong, but I thought the aim was to simply update the goal state.\n> The backup stack is just the last working stack. So if you update and there\n> is already an update you don\'t need to touch the backup stack.\n> \n> Anyone else that was at the meetup want to fill us in?\n> \n\nThe backup stack is a device used to collect items to operate on after\nthe current action is complete. It is entirely an implementation detail.\n\nResources that can be updated in place will have their resource record\nsuperseded, but retain their physical resource ID.\n\nThis is one area where the resource plugin API is particularly sticky,\nas resources are allowed to raise the \"replace me\" exception if in-place\nupdates fail. That is o-k though, at that point we will just comply by\ncreating a replacement resource as if we never tried the in-place update.\n\nIn order to facilitate this, we must expand the resource data model to\ninclude a version. Replacement resources will be marked as \"current\" and\nto-be-removed resources marked for deletion. We can also keep all current\n- 1 resources around to facilitate rollback until the stack reaches a\n\"complete\" state again. Once that is done, we can remove the backup stack.\n\n\n','<CAA16xcwrNh30nu5E2LQqoebykT7mmHMdWsneH_fx6sB-oetp2w@mail.gmail.com>',NULL),('<1411447984-sup-9906@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-22 21:56:01',-25200,'2014-09-23 04:56:01',NULL,'[openstack-dev] Oslo messaging vs zaqar','Excerpts from Geoff O\'Callaghan\'s message of 2014-09-22 17:30:47 -0700:\n> On 23/09/2014 1:59 AM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> >\n> > Geoff, do you expect all of our users to write all of their messaging\n> > code in Python?\n> >\n> > oslo.messaging is a _python_ library.\n> >\n> > Zaqar is a service with a REST API -- accessible to any application.\n> \n> No I do not.   I am suggesting thaf a well designed, scalable and robust\n> messaging layer can meet the requirements of both as well as a number of\n> other openstack servuces.  How the messaging layer is consumed isn\'t the\n> issue.\n> \n> Below is what I originally posted.\n> \n> > > --------\n> > > It seems to my casual view that we could have one and scale that and\n> use it\n> > > for SQS style messages, internal messaging (which could include logging)\n> > > all managed by message schemas and QoS.  This would give a very robust\n> and\n> > > flexible system for endpoints to consume.\n> > >\n> > > Is there a plan to consolidate?\n> \n\nSorry for the snark George. I was very confused by the text above, and\nI still am. I am confused because consolidation requires commonalities,\nof which to my mind, there are almost none other than the relationship\nto the very abstract term \"messaging\".\n\n\n','<CACBaituiQtV7TBVKT2aeWufC0=2gGy7W1_1n28Jp=Dx_z6MA8A@mail.gmail.com>',NULL),('<1411492254.6321.12.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 13:10:54',-14400,'2014-09-23 17:10:54',NULL,'[openstack-dev] [nova] 2 weeks in the bug tracker','On Fri, 2014-09-19 at 09:13 -0400, Sean Dague wrote:\n> I\'ve spent the better part of the last 2 weeks in the Nova bug tracker\n> to try to turn it into something that doesn\'t cause people to run away\n> screaming. I don\'t remember exactly where we started at open bug count 2\n> weeks ago (it was north of 1400, with > 200 bugs in new, but it might\n> have been north of 1600), but as of this email we\'re at < 1000 open bugs\n> (I\'m counting Fix Committed as closed, even though LP does not), and ~0\n> new bugs (depending on the time of the day).\n> \n> == Philosophy in Triaging ==\n> \n> I\'m going to lay out the philosophy of triaging I\'ve had, because this\n> may also set the tone going forward.\n> \n> A bug tracker is a tool to help us make a better release. It does not\n> exist for it\'s own good, it exists to help. Which means when evaluating\n> what stays in and what leaves we need to evaluate if any particular\n> artifact will help us make a better release. But also more importantly\n> realize that there is a cost for carrying every artifact in the tracker.\n> Resolving duplicates gets non linearly harder as the number of artifacts\n> go up. Triaging gets non-linearly hard as the number of artifacts go up.\n> \n> With this I was being somewhat pragmatic about closing bugs. An old bug\n> that is just a stacktrace is typically not useful. An old bug that is a\n> vague sentence that we should refactor a particular module (with no\n> specifics on the details) is not useful. A bug reported against a very\n> old version of OpenStack where the code has changed a lot in the\n> relevant area, and there aren\'t responses from the author, is not\n> useful. Not useful bugs just add debt, and we should get rid of them.\n> That makes the chance of pulling a random bug off the tracker something\n> that you could actually look at fixing, instead of mostly just stalling out.\n> \n> So I closed a lot of stuff as Invalid / Opinion that fell into those camps.\n> \n> == Keeping New Bugs at close to 0 ==\n> \n> After driving the bugs in the New state down to zero last week, I found\n> it\'s actually pretty easy to keep it at 0.\n> \n> We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20%\n> aren\'t actually a bug, and can be closed immediately. ~30% look like a\n> bug, but don\'t have anywhere near enough information in them, and\n> flipping them to incomplete with questions quickly means we have a real\n> chance of getting the right info. ~10% are fixable in < 30 minutes worth\n> of work. And the rest are real bugs, that seem to have enough to dive\n> into it, and can be triaged into Confirmed, set a priority, and add the\n> appropriate tags for the area.\n> \n> But, more importantly, this means we can filter bug quality on the way\n> in. And we can also encourage bug reporters that are giving us good\n> stuff, or even easy stuff, as we respond quickly.\n> \n> Recommendation #1: we adopt a 0 new bugs policy to keep this from\n> getting away from us in the future.\n> \n> == Our worse bug reporters are often core reviewers ==\n> \n> I\'m going to pick on Dan Prince here, mostly because I have a recent\n> concrete example, however in triaging the bug queue much of the core\n> team is to blame (including myself).\n> \n> https://bugs.launchpad.net/nova/+bug/1368773 is a terrible bug. Also, it\n> was set incomplete and no response. I\'m almost 100% sure it\'s a dupe of\n> the multiprocess bug we\'ve been tracking down but it\'s so terse that you\n> can\'t get to the bottom of it.\n\n\nThis bug was filed as a result of a cryptic (to me at the time) gate\nunit test failure that occurred in this review:\n\nhttps://review.openstack.org/#/c/120099/\n\nI mistakenly grabbed the last timeout error instead of looking at the\noriginal timeout. Within 30 minutes or so of my post Matt Riedemann had\ncorrectly classified it as https://bugs.launchpad.net/nova/+bug/1357578\n\nI\'ve added some extra data and marked it as a dup.\n\nDan\n\n\n> \n> There were a ton of 2012 nova bugs that were basically \"post it notes\".\n> Oh, \"we should refactor this function\". Full stop. While those are fine\n> for personal tracking, their value goes to zero probably 3 months after\n> they are files, especially if the reporter stops working on the issue at\n> hand. Nova has plenty of \"wouldn\'t it be great if we... \" ideas. I\'m not\n> convinced using bugs for those is useful unless we go and close them out\n> aggressively if they stall.\n> \n> Also, if Nova core can\'t file a good bug, it\'s hard to set the example\n> for others in our community.\n> \n> Recommendation #2: hey, Nova core, lets be better about filing the kinds\n> of bugs we want to see! mkay!\n> \n> Recommendation #3: Let\'s create a tag for \"personal work items\" or\n> something for these class of TODOs people are leaving themselves that\n> make them a ton easier to cull later when they stall and no one else has\n> enough context to pick them up.\n> \n> == Tags ==\n> \n> The aggressive tagging that Tracy brought into the project has been\n> awesome. It definitely helps slice out into better functional areas.\n> Here is the top of our current official tag list (and bug count):\n> \n> 95 compute\n> 83 libvirt\n> 74 api\n> 68 vmware\n> 67 network\n> 41 db\n> 40 testing\n> 40 volumes\n> 36 ec2\n> 35 icehouse-backport-potential\n> 32 low-hanging-fruit\n> 31 xenserver\n> 25 ironic\n> 23 hyper-v\n> 16 cells\n> 14 scheduler\n> 12 baremetal\n> 9 ceph\n> 9 security\n> 8 oslo\n> ...\n> \n> So, good stuff. However I think we probably want to take a further step\n> and attempt to get champions for tags. So that tag owners would ensure\n> their bug list looks sane, and actually spend some time fixing them.\n> It\'s pretty clear, for instance, that the ec2 bugs are just piling up,\n> and very few fixes coming in. Cells seems like it\'s in the same camp (a\n> bunch of recent bugs have been cells related, it looks like a lot more\n> deployments are trying it).\n> \n> Probably the most important thing in tag owners would be cleaning up the\n> bugs in the tag. Realizing that 2 bugs were actually the same bug.\n> Cleaning up descriptions / titles / etc so that people can move forward\n> on them.\n> \n> Recommendation #4: create tag champions\n> \n> == Soft Spots ==\n> \n> After looking at probably close to 1000 bugs in 2 weeks I have a\n> particular impression of soft spots that we have.\n> \n> Quotas are kind of a mess. It\'s not clear that we\'re even eventually\n> consistent. There are a lot of bugs about creating servers, deleteing\n> servers, and leaking quota in the process. I know Jay and Sylvan are\n> diving hard on the resource tracker right now, I think this should be a\n> Kilo focus area because it creates terrible confusion and bugs for people.\n> \n> EC2 has definitely regressed, especially after block device mapping\n> changes, to the point that it\'s not clear it\'s functional outside of the\n> most basic server create commands. The EC2 code is largely unchanged\n> since 2012, and only lightly tested, we need to decide if this is\n> important or not, and either fix it or delete it. There have been many\n> past hands going up that said they would help, and then they never do\n> (you known who you are).\n> \n> The VM State machine model is .... Well it\'s at least suboptimal, but\n> it\'s also clear that it\'s massively leaky, and the way we handle it\n> internally means we end up in inconsistent wedges all the time. I expect\n> the complexity here causes a ton of bugs. We need some refactoring to\n> make things a ton more clear about what\'s supposed to be happening, and\n> how to rollback when they go wrong. I think the Tasks work was headed\n> down that path, but that seems stalled now.\n> \n> Cross interaction with Neutron and Cinder remains racey. We are pretty\n> optimistic on when resources will be available. Even the event interface\n> with Neutron hasn\'t fully addressed this. I think a really great Design\n> Summit session would be Nova + Neutron + Cinder to figure out a shared\n> architecture to address this. I\'d expect this to be at least a double\n> session.\n> \n> Recommendation #5 - 8: we should get on those things :)\n> \n> == Triaging Inconsistencies ==\n> \n> I found some inconsistencies in how people were triaging bugs, and the\n> state inconsistencies probably don\'t help with making the bugs seem\n> confusing: https://wiki.openstack.org/wiki/BugTriage provides some\n> guideance.\n> \n> Importantly:\n> \n> Incomplete is an Open state. For bugzilla folks this is NEEDSINFO. I saw\n> a bunch of \'closing\' comments but a move to Incomplete.\n> \n> Triaged should be used if the solution to fix the bug is in the bug\n> itself. Triaged is Confirmed + Solution at enough details to fix it.\n> \n> Incomplete bugs should not have assignees or milestones, otherwise it\n> won\'t time out.\n> \n> == General Cleanup Rules ==\n> \n> Here are some general cleanup rules that I was using:\n> \n> If an Incomplete bug has no response after 30 days it\'s fair game to\n> close (Invalid, Opinion, Won\'t Fix).\n> \n> If a bug is In Progress with no patch posted after 30 days, it is not In\n> Progress. Remove assignee, move back to last state (probably confirmed).\n> Move to Opinion if it\'s really a \"post it note\".\n> \n> If a bug is In Progress but the patches were abandoned, it\'s no longer\n> In Progress. Remove assignee, move back to last state (probably\n> confirmed). Move to Opinion if it\'s really a \"post it note\".\n> \n> == Rescuing Stalled Fixes ==\n> \n> Over the course of this I found a bunch of the In Progress bugs were\n> real issues, with real fixes, that had stalled out for one of a number\n> of reasons. Often it had a -1 \'needs unit tests\' on it, and it\'s sort of\n> clear the author didn\'t really know how to do that for this patch. Other\n> times the author\'s first language was not english, and the patch commit\n> message was confusing enough that no one understood what it was fixing.\n> (One of these bugs I restored, rewrote the commit message, and then it\n> sailed through the process.)\n> \n> Recommendation #9: if you are going to -1 for unit tests, please go the\n> extra step of saying \'I think you should write a test that does X, Y, Z\'.\n> \n> Recommendation #10: We need to find a better balance in rewriting commit\n> messages. Maybe we should just make it socially acceptable to rewrite\n> the commit message as part of review.\n> \n> ....\n> \n> I\'m sure there are other thoughts, but my brain is running out of steam.\n> These were the things that popped to the top of my head. It\'s definitely\n> been really interesting to spend this much time with the tracker to\n> build a bigger picture of this feedback channel we have from our users.\n> Hopefully other folks found some of this handy.\n> \n> 	-Sean\n> \n\n\n\n\n','<541C2BF9.50808@dague.net>',NULL),('<1411492558.4120.2.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 12:15:58',-18000,'2014-09-23 17:15:58',NULL,'[openstack-dev] [Nova] Some ideas for micro-version\n implementation','On Tue, 2014-09-23 at 12:09 -0400, Jay Pipes wrote:\n> I\'d like to say finally that I think there should be an OpenStack API \n> working group whose job it is to both pull together a set of OpenStack \n> API practices as well as evaluate new REST APIs proposed in the \n> OpenStack ecosystem to provide guidance to new projects or new \n> subprojects wishing to add resources to an existing REST API.\n\nOne of the things that\'s been bothering me about OpenStack for a while\nnow is the fact that we have all these different APIs on different\nendpoints.  What I\'ve been wondering about is if we should create a\nunified ReST API service to replace the service from all of the\nindividual projects.  Then, users can just hit that one service to\nhandle all their different interactions.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<54219B29.4020107@gmail.com>',NULL),('<1411495855.4120.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 13:10:55',-18000,'2014-09-23 18:10:55',NULL,'[openstack-dev] [Nova] Some ideas for micro-version\n implementation','On Tue, 2014-09-23 at 18:39 +0100, Louis Taylor wrote:\n> On Tue, Sep 23, 2014 at 01:32:50PM -0400, Andrew Laski wrote:\n> > I\'ve been thinking along very similar lines, but I don\'t think each current\n> > API needs to be replaced.  I would very much like to see a unified API\n> > project that could be responsible for managing requests to \"boot an instance\n> > with this network and that volume\" which would make requests to\n> > Nova/Neutron/Cinder on the users behalf.\n> \n> Isn\'t this what openstacksdk [0] is?\n> \n> [0] https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK\n\nWell, openstacksdk is a client, and we\'re talking about a server.  A\nserver, in this instance, has some advantages over a client, including\nmaking it easier to create that client in the first place :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<20140923173957.GA10345@gmail.com>',NULL),('<1411510005-sup-7617@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 15:09:53',-25200,'2014-09-23 22:09:53',NULL,'[openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed\n	Queues','Excerpts from Joe Gordon\'s message of 2014-09-23 14:59:33 -0700:\n> On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <zbitter at redhat.com> wrote:\n> \n> > On 22/09/14 22:04, Joe Gordon wrote:\n> >\n> >> To me this is less about valid or invalid choices. The Zaqar team is\n> >> comparing Zaqar to SQS, but after digging into the two of them, zaqar\n> >> barely looks like SQS. Zaqar doesn\'t guarantee what IMHO is the most\n> >> important parts of SQS: the message will be delivered and will never be\n> >> lost by SQS.\n> >>\n> >\n> > I agree that this is the most important feature. Happily, Flavio has\n> > clarified this in his other thread[1]:\n> >\n> >  *Zaqar\'s vision is to provide a cross-cloud interoperable,\n> >   fully-reliable messaging service at scale that is both, easy and not\n> >   invasive, for deployers and users.*\n> >\n> >   ...\n> >\n> >   Zaqar aims to be a fully-reliable service, therefore messages should\n> >   never be lost under any circumstances except for when the message\'s\n> >   expiration time (ttl) is reached\n> >\n> > So Zaqar _will_ guarantee reliable delivery.\n> >\n> >  Zaqar doesn\'t have the same scaling properties as SQS.\n> >>\n> >\n> > This is true. (That\'s not to say it won\'t scale, but it doesn\'t scale in\n> > exactly the same way that SQS does because it has a different architecture.)\n> >\n> > It appears that the main reason for this is the ordering guarantee, which\n> > was introduced in response to feedback from users. So this is clearly a\n> > different design choice: SQS chose reliability plus effectively infinite\n> > scalability, while Zaqar chose reliability plus FIFO. It\'s not feasible to\n> > satisfy all three simultaneously, so the options are:\n> >\n> > 1) Implement two separate modes and allow the user to decide\n> > 2) Continue to choose FIFO over infinite scalability\n> > 3) Drop FIFO and choose infinite scalability instead\n> >\n> > This is one of the key points on which we need to get buy-in from the\n> > community on selecting one of these as the long-term strategy.\n> >\n> >  Zaqar is aiming for low latency per message, SQS doesn\'t appear to be.\n> >>\n> >\n> > I\'ve seen no evidence that Zaqar is actually aiming for that. There are\n> > waaay lower-latency ways to implement messaging if you don\'t care about\n> > durability (you wouldn\'t do store-and-forward, for a start). If you see a\n> > lot of talk about low latency, it\'s probably because for a long time people\n> > insisted on comparing Zaqar to RabbitMQ instead of SQS.\n> >\n> \n> I thought this was why Zaqar uses Falcon and not Pecan/WSME?\n> \n> \"For an application like Marconi where throughput and latency is of\n> paramount importance, I recommend Falcon over Pecan.\"\n> https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation#Recommendation\n> \n> Yes that statement mentions throughput as well, but it does mention latency\n> as well.\n> \n\nI definitely see where that may have subtly suggested the wrong\nthing, if indeed latency isn\'t a top concern.\n\nI think what it probably should say is something like this:\n\n\"For an application like Marconi where there will be many repetitive,\nsmall requests, a lighter weight solution such as Falcon is preferred\nover Pecan.\"\n\nAs in, we care about the cost of all those requests, not so much about\nthe latency.\n\n\n','<CAHXdxOcx0Lc9UOs1=XFqL2awYDTbC-sMFMBEtFuJSpRstkzV8w@mail.gmail.com>',NULL),('<1411533419.3579.11.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 04:37:00',0,'2014-09-24 04:37:00',NULL,'[openstack-dev] [Neutron][LBaaS] Migrations in feature branch','Well the problem with resequencing on a merge is that a code change for\nthe first migration must be added first and merged into the feature\nbranch before the merge is done.  Obviously this takes review time\nunless someone of authority pushes it through.  We\'ll run into this same\nproblem on rebases too if we care about keeping the migration sequenced\ncorrectly after rebases (which we don\'t have to, only on a merge do we\nreally need to care).  If we did what Henry suggested in that we only\nkeep one migration file for the entire feature, we\'d still have to do\nthe same thing.  I\'m not sure that buys us much other than keeping the\nfeature\'s migration all in one file.\n\nI\'d also say that code in master should definitely NOT be dependent on\ncode in a feature branch, much less a migration.  This was a requirement\nof the incubator as well.\n\nSo yeah this sounds like a problem but one that really only needs to be\nsolved at merge time.  There will definitely need to be coordination\nwith the cores when merge time comes.  Then again, I\'d be a bit worried\nif there wasn\'t since a feature branch being merged into master is a\nhuge deal.  Unless I am missing something I don\'t see this as a big\nproblem, but I am highly capable of being blind to many things.\n\nThanks,\nBrandon\n\n\nOn Wed, 2014-09-24 at 01:38 +0000, Doug Wiegley wrote:\n> Hi Eugene,\n> \n> \n> Just my take, but I assumed that we?d re-sequence the migrations at\n> merge time, if needed.  Feature branches aren?t meant to be optional\n> add-on components (I think), nor are they meant to live that long.\n>  Just a place to collaborate and work on a large chunk of code until\n> it?s ready to merge.  Though exactly what those merge criteria are is\n> also yet to be determined.\n> \n> \n> I understand that you?re raising a general problem, but given lbaas\n> v2?s state, I don?t expect this issue to cause many practical problems\n> in this particular case.\n> \n> \n> This is also an issue for the incubator, whenever it rolls around.\n> \n> \n> Thanks,\n> doug\n> \n> \n> \n> \n> On September 23, 2014 at 6:59:44 PM, Eugene Nikanorov\n> (enikanorov at mirantis.com) wrote:\n> \n> > \n> > Hi neutron and lbaas folks. \n> > \n> > \n> > Recently I briefly looked at one of lbaas proposed into feature\n> > branch.\n> > I see migration IDs there are lined into a general migration\n> > sequence.\n> > \n> > \n> > I think something is definitely wrong with this approach as\n> > feature-branch components are optional, and also master branch can\'t\n> > depend on revision IDs in\n> > feature-branch (as we moved to unconditional migrations)\n> > \n> > \n> > So far the solution to this problem that I see is to have separate\n> > migration script, or in fact, separate revision sequence. The\n> > problem is that DB models in feature branch may depend on models of\n> > master branch, which means that each revision of feature-branch\n> > should have a kind of \"minimum required\" revision of the master\n> > branch.\n> > The problem that revision IDs don\'t form linear order, so we can\'t\n> > have \'minimum\' unless that separate migration script may analyze\n> > master branch migration sequence and find minimum required migration\n> > ID.\n> > \n> > \n> > Thoughts?\n> > \n> > \n> > Thanks,\n> > Eugene.\n> > _______________________________________________ \n> > OpenStack-dev mailing list \n> > OpenStack-dev at lists.openstack.org \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> > \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<etPan.5422206d.238e1f29.1a36@wiegley-mini.local.tld>',NULL),('<1411545049-sup-4992@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 00:57:01',-25200,'2014-09-24 07:57:01',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Jay Pipes\'s message of 2014-09-23 21:38:37 -0700:\n> On 09/23/2014 10:29 PM, Steven Dake wrote:\n> > There is a deployment program - tripleo is just one implementation.\n> \n> Nope, that is not correct. Like it or not (I personally don\'t), Triple-O \n> is *the* Deployment Program for OpenStack:\n> \n> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n284\n> \n> Saying Triple-O is just one implementation of a deployment program is \n> like saying Heat is just one implementation of an orchestration program. \n> It isn\'t. It\'s *the* implemenation of an orchestration program that has \n> been blessed by the TC:\n> \n> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n112\n> \n\nThat was written before we learned everything we\'ve learned in the last\n12 months. I think it is unfair to simply point to this and imply that\nbending or even changing it is not open for discussion.\n\n>  > We\n> > went through this with Heat and various projects that want to extend\n> > heat (eg Murano) and one big mistake I think Murano folks made was not\n> > figuring out where there code would go prior to writing it.  I\'m only\n> > making a statement as to where I think it should belong.\n> \n> Sorry, I have to call you to task on this.\n> \n> You think it was a mistake for the Murano folks to \"not figure out where \n> the code would go prior to writing it\"? For the record, Murano existed \n> nearly 2 years ago, as a response to various customer requests. Having \n> the ability to properly deploy Windows applications like SQL Server and \n> Active Directory into an OpenStack cloud was more important to the \n> Murano developers than trying to predict what the whims of the OpenStack \n> developer and governance model would be months or years down the road.\n> \n> Tell me, did any of Heat\'s code exist prior to deciding to propose it \n> for incubation? Saying that Murano developers should have thought about \n> where their code would live is holding them to a higher standard than \n> any of the other developer communities. Did folks working on \n> disk-image-builder pre-validate with the TC or the mailing list that the \n> dib code would \"live in the triple-o program\"? No, of course not. It was \n> developed naturally and then placed into the program that fit it best.\n> \n> Murano was developed naturally in exactly the same way, and the Murano \n> developers have been nothing but accommodating to every request made of \n> them by the TC (and those requests have been entirely different over the \n> last 18 months, ranging from \"split it out\" to \"just propose another \n> program\") and by the PTLs for projects that requested they split various \n> parts of Murano out into existing programs.\n> \n> The Murano developers have done no power grab, have deliberately tried \n> to be as community-focused and amenable to all requests as possible, and \n> yet they are treated with disdain by a number of folks in the core Heat \n> developer community, including yourself, Clint and Zane. And honestly, I \n> don\'t get it... all Murano is doing is generating Heat templates and \n> trying to fill in some pieces that Heat isn\'t interested in doing. I \n> don\'t see why there is so much animosity towards a project that has, to \n> my knowledge, acted in precisely the ways that we\'ve asked projects to \n> act in the OpenStack community: with openness, transparency, and \n> community good will.\n\nDisdain is hardly the right word. Disdain implies we don\'t have any\nrespect at all for Murano. I cannot speak for others, but I do have\nrespect. I\'m just not interested in Murano.\n\nFWIW, I think what Steven Dake is saying is that he does not want to\nend up in the same position Murano is in. I think that is unlikely,\nas we\'re seeing many projects hitting the same wall, which is the cause\nfor discussing changing how we include or exclude projects.\n\n\n','<54224ACD.1020304@gmail.com>',NULL),('<1411545574-sup-1310@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 01:03:15',-25200,'2014-09-24 08:03:15',NULL,'[openstack-dev] [TripleO] PTL Candidacy','I am writing to announce my candidacy for OpenStack Deployment PTL.\n\nThose of you involved with the deployment program may be surprised to\nsee my name here. I\'ve been quiet lately, distracted by an experiment\nwhich was announced by Allison Randal a few months back. [1]\n\nThe experiment has been going well. We\'ve had to narrow our focus from\nthe broader OpenStack project and just push hard to get HP\'s Helion\nProduct ready for release, but we\'re ready to bring everything back out\ninto the open and add it to the options for the deployment program. Most\nrecently our \'tripleo-ansible\' repository has been added to stackforge [2],\nand I hope we can work out a way where it lands in the official deployment\nnamespace once we have broader interest.\n\nThose facts may cause some readers to panic, and others to rejoice,\nbut I would ask you to keep reading, even if you think the facts above\nmight disqualify me from your ballot.\n\nMy intention is to serve as PTL for OpenStack Deployment. I want to\nemphasize the word \"serve\". I believe that a PTL\'s first job is to serve\nthe mission of the program.\n\nI have watched Robert serve closely, and I think I understand the wide\nreach the program already has. We make use of Ironic, Nova, Glance,\nNeutron, and Heat, and we need to interface directly with those projects\nto be successful, regardless of any other tools in use.\n\nHowever, I don\'t think the way to scale this project is to buckle down and\ntry to be a hero-PTL. We need to make the program\'s mission more appealing\nto a greater number of OpenStack operators that want to deploy and manage\nOpenStack. This will widen our focus, which may slow some things down,\nbut we can collaborate, and find common ground on many issues while still\npushing forward on the fronts that are important to each organization.\n\nMy recent experience with Ansible has convinced me that Ansible is not\n_the_ answer, but that Ansible is _an_ answer which serves the needs\nof some OpenStack users. Heat serves other needs, where Puppet, Chef,\nSalt, and SSH in a for loop serve yet more diverse needs.\n\nSo, with that in mind, I want to succinctly state my priorities for\nthe role:\n\n * Serve the operators. Our feedback from operators has been extremely\n   mixed. We need to do a better job of turning operators into OpenStack\n   Deployment users and contributors.\n\n * Improve diversity. I have been as guilty as anyone else in the past\n   of slamming the door on those who wanted to join our effort but with\n   a different use case. This was a mistake. Looking forward, the door\n   needs to stay open, and be widened. Without that, we won\'t be able\n   to welcome more operators.\n\n * March toward a presence in the \"gate\". I know that \"the gate\" is\n   a hot term and up for debate right now. However, there will always\n   be a gate of some kind for the projects in the integrated release,\n   and I\'d like to see a more production-like test in that gate. From\n   the beginning, TripleO has been focused on supporting continuous\n   deployment models, so it would make a lot of sense to have TripleO\n   doing integration testing of the integrated release. If there is\n   a continued stripping down of the gate, then TripleO would still\n   certainly be a valuable CI job for the integrated release. We\'ve had\n   TripleO break numerous times because we run with a focus on production\n   ready settings and multiple nodes which exposes new facets of the\n   code that go untouched in the single-node simple-and-fast focused\n   devstack tests.\n   \n   Of course, our CI has not exactly been rock solid, for various\n   reasons. We need to make it a priority to get CI handled for at least\n   the primary tooling, and at the same time welcome and support efforts\n   to make use of our infrastructure for alternative tooling. This isn\'t\n   something I necessarily think will happen in the next 6 months, but\n   I think one role that a PTL can be asked to serve is as shepherd of\n   long term efforts, and this is definitely one of those.\n\nSo, I thank you for taking the time to read this, and hope that whatever\nhappens we can build a better deployment program this cycle.\n\n-Clint Byrum\n\n[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042589.html\n[2] https://git.openstack.org/cgit/stackforge/tripleo-ansible\n\n\n',NULL,NULL),('<1411572297.4120.6.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 10:24:57',-18000,'2014-09-24 15:24:57',NULL,'[openstack-dev] [Nova] [All] API standards working group','On Tue, 2014-09-23 at 18:18 -0400, Jay Pipes wrote:\n> Yes, I\'d be willing to head up the working group... or at least \n> participate in it.\n\nI\'ll raise my hand to participate?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<5421F1D0.1090006@gmail.com>',NULL),('<1411577992-sup-6988@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 10:07:54',-25200,'2014-09-24 17:07:54',NULL,'[openstack-dev] [Zaqar] The horse is dead. Long live the horse.','Sorry for the vague subject[1]. I just wanted to commend Flavio Percoco\nand the Zaqar team for maintaining poise and being excellent citizens\nof OpenStack whilst being questioned intensely by the likes of me,\nand others.\n\nI feel that this questioning has been useful, and will allow us to reason\nabout Zaqar in the future. So, I recommend that we stop questioning,\nand start coding.\n\nIf you feel that a lighter weight system with different guarantees will\nserve the users of OpenStack better than Zaqar, then own up and write it.\n\nMeanwhile, I suggest we spend our communication bandwidth and effort\non reasoning about the bigger problem that Zaqar exposes, and which I\nthink Monty has highlighted in his recent thread about the big tent.\n\nAnyway, thanks for listening.\n\n-Clint\n\n[1] The subject is a reference to beating a dead horse. Zaqar is not a\nhorse, and is not dead. The first person to get angry about my declaration\nof Zaqar\'s death should be asked to wear a ridiculous sombrero to the\nnext summit.\n\n\n',NULL,NULL),('<1411583080-sup-2017@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 11:48:42',-25200,'2014-09-24 18:48:42',NULL,'[openstack-dev] Thoughts on OpenStack Layers and a Big Tent\n	model','Excerpts from Robert Collins\'s message of 2014-09-23 21:14:47 -0700:\n> No one helped me edit this :)\n> \n> http://rbtcollins.wordpress.com/2014/09/24/what-poles-for-the-tent/\n> \n> I hope I haven\'t zoned out and just channelled someone else here ;)\n> \n\nThis sounds like \"API\'s are what matters.\" You did spend some time\nworking with Simon Wardley, didn\'t you? ;)\n\nI think it\'s a sound argument, but I\'d like to banish the term \"reference\nimplementation\" from any discussions around what OpenStack, as a project,\ndelivers. It has too many negative feelings wrapped up in it.\n\nI also want to call attention to how what you describe feels an awful\nlot like POSIX to me. Basically offering guarantees of API compatibility,\nbut then letting vendors run wild around and behind it.\n\nI\'m not sure if that is a good thing, or a bad thing. I do, however,\nthink if we can avoid a massive vendor battle that involves multiple\nvendors pushing multiple implementations, we will save our companies a\nlot of money, and our users will get what they need sooner.\n\n\n','<CAJ3HoZ0NrSABnHM6p0cc5R37Vs4ihqqeN04jtxZB=Larf5M_uw@mail.gmail.com>',NULL),('<1411585454.60411396@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-09-24 14:04:14',-18000,'2014-09-24 19:04:14',NULL,'[openstack-community] OpenStack Speaking and Support Opportunities\n	SAP TechEd && d-code Events','\nSAP has offered the OpenStack community the following opportunities at their TechEd && d-code technical education events in Las Vegas (Oct 20-24) and Berlin (Nov 11-13). If interested in one or more, or for more information, please contact Inga Bereza at [ inga.bereza at sap.com ]( mailto:inga.bereza at sap.com ). Thank you.\n \nOpen Source Area:\nTechnical expert/developer for the Open Source counter in the exhibit area, in Las Vegas and Berlin.\nSAP will provide 3-day show floor pass to the OpenStack expert(s).\nTech Talk: \n30-min talk(s) on OpenStack followed by 15 min of Q&A.\nIf you would like to participate in a Tech Talk, please provide Inga with the topic, speaker, and paragraph describing the talk.\nOpen Source panel session at SAP Live studio: \nThomas Grassl will be moderating an open source panel with 3-4 open source project representatives.\nTopics and questions will be discussed with the panelists closer to the event dates.\nMeetings with bloggers and SAP Mentors:\nMeetings will be arranged closer to the event dates.\nDetails of the events:\n[ SAP TechEd && d-code Las Vegas ]( http://www.sapdcode.com/2014/usa/home.htm )\n[ SAP TechEd && d-code Berlin ]( http://www.sapdcode.com/2014/emea/home.htm )\n\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140924/2fb3c872/attachment.html>\n\n',NULL,NULL),('<1411591123.4432.2.camel@bswartz-u904>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 20:37:49',0,'2014-09-24 20:37:49',NULL,'[openstack-dev] [Manila] PTL Candidacy','Hello! I have been the de-facto PTL for Manila from the conception of\nthe project up to now. Since Manila is an officially incubated OpenStack\nprogram, I have the opportunity to run for election and hopefully become\nthe officially elected PTL for the Manila project.\n\nI\'m running because I feel that the vision of the Manila project is\nstill not achieved, even though we\'ve made tremendous strides in the\nlast year, and I want to see the project mature and become part of\ncore OpenStack.\n\nSome of you may remember the roots of the Manila project, when we\nproposed shared file system management as an extension to the\nthen-nascent Cinder project during the Folsom release. It\'s taken a lot\nof attempts and failures to arrive at the current Manila project, and\nit\'s been an exciting and humbling journey, where along the way I\'ve\nhad the opportunity to work with many great individuals.\n\nMy vision for the future of the Manila includes:\n* Getting more integrated with the rest of OpenStack. We have Devstack,\n  Tempest, and Horizon integration, and I\'d like to get that code into\n  the right places where it can be maintained. We also need to add Heat\n  integration, and more complete documentation.\n* Working with distributions on issues related to packaging and\n  installation to make Manila as easy to use as possible. This includes\n  work with Chef and Puppet.\n* Making Manila usable in more environments. Manila\'s design center has\n  been large-scale public clouds, but we haven\'t spent enough time on\n  small/medium scale environments -- the kind the developers typically\n  have and the kind that users typically start out with.\n* Taking good ideas from the rest of OpenStack. We\'re a small team and\n  we can\'t do everything ourselves. The OpenStack ecosystem is full of\n  excellent technology and I want to make sure we take the best ideas\n  and apply them to Manila. In particular, there are some features I\'d\n  like to copy from the Cinder project.\n* A focus on quality. I want to make sure we keep test coverage high\n  as we add new features, and increase test coverage on existing\n  features. I also want to try to start vendor CI similar to what\n  Cinder has.\n* Lastly, I expect to work with vendors to get more drivers contributed\n  to expand Manila\'s hardware support. I am very interested in\n  smoothing out some of the networking complexities that make it\n  difficult to write drivers today.\n\nI hope you will support my candidacy so I can continue to lead Manila\ntowards eventual integration with OpenStack and realize my dream of\nshared file system management in the cloud.\n\nThank you,\nBen Swartzlander\nManila PTL, NetApp Architect\n\n\n',NULL,NULL),('<1411596393-sup-4466@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 15:14:17',-25200,'2014-09-24 22:14:17',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Steven Dake\'s message of 2014-09-23 15:40:29 -0700:\n> *Hi folks,***\n> *\n> \n> \n> I\'m pleased to announce the development of a new project Kolla which is \n> Greek for glue :). Kolla has a goal of providing an implementation that \n> deploys OpenStack using Kubernetes and Docker. This project will begin \n> as a StackForge project separate from the TripleO/Deployment program \n> code base. Our long term goal is to merge into the TripleO/Deployment \n> program rather then create a new program.\n> \n> \n> Docker is a container technology for delivering hermetically sealed \n> applications and has about 620 technical contributors [1]. We intend to \n> produce docker images for a variety of platforms beginning with Fedora \n> 20. We are completely open to any distro support, so if folks want to \n> add new Linux distribution to Kolla please feel free to submit patches :)\n> \n> \n> Kubernetes at the most basic level is a Docker scheduler produced by and \n> used within Google [2]. Kubernetes has in excess of 100 technical \n> contributors. Kubernetes is more then just a scheduler, it provides \n> additional functionality such as load balancing and scaling and has a \n> significant roadmap.\n> \n\nYou had me at Docker.. \n\n\"Kubernetes establishes robust declarative primitives for maintaining\nthe desired state requested by the user. We see these primitives as\nthe main value added by Kubernetes. Self-healing mechanisms, such as\nauto-restarting, re-scheduling, and replicating containers require active\ncontrollers, not just imperative orchestration.\"\n\nBut the bit above has me a bit nervous...\n\nI\'m not exactly ignorant of what declarative orchestration is, and of\nlate I\'ve found it to be more trouble than I had previously imagined it\nwould be. All of the features above are desirable in any application,\nwhether docker managed or not, and have been discussed for Heat\nspecifically. I\'m not entirely sure I want these things in my OpenStack\ndeployment, but it will be interesting to see if there are operators who\nwant them bad enough to deal with the inherent complexities of trying to\nwrite such a thing for an application as demanding as OpenStack.\n\nAnyway, I would definitely be interested in seeing if we can plug it\ninto the interfaces we already have for image building, config file and\nsystem state management. Thanks for sharing, and see you in the\ndeployment trenches. :)\n\n\n','<5421F6DD.4060906@redhat.com>',NULL),('<1411613716-sup-2@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 19:57:08',-25200,'2014-09-25 02:57:08',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Angus Lees\'s message of 2014-09-24 18:33:22 -0700:\n> These last few don\'t have strong existing options within OpenStack yet (as far \n> as I\'m aware).  Having explored a few different approaches recently, kubernetes \n> is certainly not the only option - but is a reasonable contender here.\n> \n> \n> So: I certainly don\'t see kubernetes as competing with anything in OpenStack - \n> but as filling a gap in job management with something that has a fairly \n> lightweight config syntax and is relatively simple to deploy on VMs or \n> baremetal.  I also think the phrase \"integrating kubernetes into OpenStack\" is \n> overstating the task at hand.\n> \n\nReading more on the design and intention, I think it very much competes\nwith Heat. The moment it learns to talk to Nova, it becomes a convergence\nengine for OpenStack.\n\n\n','<7024808.dsdmfkuS0q@hounddog>',NULL),('<1411617397-sup-8029@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 21:02:35',-25200,'2014-09-25 04:02:35',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Steven Dake\'s message of 2014-09-24 20:02:49 -0700:\n> On 09/24/2014 03:31 PM, Alan Kavanagh wrote:\n> >\n> > Steven\n> >\n> > I have to ask what is the motivation and benefits we get from \n> > integrating Kubernetes into Openstack? Would be really useful if you \n> > can elaborate and outline some use cases and benefits Openstack and \n> > Kubernetes can gain.\n> >\n> > /Alan\n> >\n> Alan,\n> \n> I am either unaware or ignorant of another Docker scheduler that is \n> currently available that has a big (100+ folks) development community.  \n> Kubernetes meets these requirements and is my main motivation for using \n> it to schedule Docker containers.  There are other ways to skin this cat \n> - The TripleO folks wanted at one point to deploy nova with the nova \n> docker VM manager to do such a thing. This model seemed a little clunky \n> to me since it isn\'t purpose built around containers.\n> \n\nAgreed. Containers are a special kind of workload, not a VM. However, I\ndo think that a container manager could be taught manage vms and vice\nversa.\n\n> As far as use cases go, the main use case is to run a specific Docker \n> container on a specific Kubernetes \"minion\" bare metal host. These \n> docker containers are then composed of the various config tools and \n> services for each detailed service in OpenStack.  For example, mysql \n> would be a container, and tools to configure the mysql service would \n> exist in the container.  Kubernetes would pass config options for the \n> mysql database prior to scheduling and once scheduled, Kubernetes would \n> be responsible for connecting the various containers together.\n>\n\nI like it. This is just good old fashioned encapsulation, finally\napplied to ops.\n\nI also like that it rides on top of OpenStack entirely, and doesn\'t have\nto be integrated.\n\nHowever, this does make me think that Keystone domains should be exposable\nto services inside your cloud for use as SSO. It would be quite handy\nif the keystone users used for the VMs that host Kubernetes could use\nthe same credentials to manage the containers.\n\n\n','<542385D9.70302@redhat.com>',NULL),('<1411617772-sup-5868@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 21:13:53',-25200,'2014-09-25 04:13:53',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Mike Spreitzer\'s message of 2014-09-24 20:49:20 -0700:\n> Steven Dake <sdake at redhat.com> wrote on 09/24/2014 11:02:49 PM:\n> \n> > On 09/24/2014 03:31 PM, Alan Kavanagh wrote:\n> > Steven\n> > I have to ask what is the motivation and benefits we get from \n> > integrating Kubernetes into Openstack? Would be really useful if you\n> > can elaborate and outline some use cases and benefits Openstack and \n> > Kubernetes can gain. \n> >  \n> > /Alan\n> >  \n> > Alan,\n> > \n> > I am either unaware or ignorant of another Docker scheduler that is \n> > currently available that has a big (100+ folks) development \n> > community.  Kubernetes meets these requirements and is my main \n> > motivation for using it to schedule Docker containers.  There are \n> > other ways to skin this cat - The TripleO folks wanted at one point \n> > to deploy nova with the nova docker VM manager to do such a thing.  \n> > This model seemed a little clunky to me since it isn\'t purpose built\n> > around containers.\n> \n> Does TripleO require container functionality that is not available\n> when using the Docker driver for Nova?\n> \n> As far as I can tell, the quantitative handling of capacities and\n> demands in Kubernetes is much inferior to what Nova does today.\n> \n\nYes, TripleO needs to manage baremetal and containers from a single\nhost. Nova and Neutron do not offer this as a feature unfortunately.\n\n> > As far as use cases go, the main use case is to run a specific \n> > Docker container on a specific Kubernetes \"minion\" bare metal host.\n> \n> If TripleO already knows it wants to run a specific Docker image\n> on a specific host then TripleO does not need a scheduler.\n> \n\nTripleO does not ever specify destination host, because Nova does not\nallow that, nor should it. It does want to isolate failure domains so\nthat all three Galera nodes aren\'t on the same PDU, but we\'ve not really\ngotten to the point where we can do that yet.\n\n> > These docker containers are then composed of the various config \n> > tools and services for each detailed service in OpenStack.  For \n> > example, mysql would be a container, and tools to configure the \n> > mysql service would exist in the container.  Kubernetes would pass \n> > config options for the mysql database prior to scheduling\n> \n> I am not sure what is meant here by \"pass config options\" nor how it\n> would be done prior to scheduling; can you please clarify?\n> I do not imagine Kubernetes would *choose* the config values,\n> K8s does not know anything about configuring OpenStack.\n> Before scheduling, there is no running container to pass\n> anything to.\n> \n\nDocker containers tend to use environment variables passed to the initial\ncommand to configure things. The Kubernetes API allows setting these\nenvironment variables on creation of the container.\n\n> >                                                           and once \n> > scheduled, Kubernetes would be responsible for connecting the \n> > various containers together.\n> \n> Kubernetes has a limited role in connecting containers together.\n> K8s creates the networking environment in which the containers\n> *can* communicate, and passes environment variables into containers\n> telling them from what protocol://host:port/ to import each imported\n> endpoint.  Kubernetes creates a universal reverse proxy on each\n> minion, to provide endpoints that do not vary as the servers\n> move around.\n> It is up to stuff outside Kubernetes to decide\n> what should be connected to what, and it is up to the containers\n> to read the environment variables and actually connect.\n> \n\nThis is a nice simple interface though, and I like that it is narrowly\ndefined, not trying to be \"anything that containers want to share with\nother containers.\"\n\n\n','<OF5947FB3B.5FC50C16-ON85257D5E.0012438C-85257D5E.0014FEF4@us.ibm.com>',NULL),('<1411618475-sup-7617@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-24 21:20:12',-25200,'2014-09-25 04:20:12',NULL,'[openstack-dev] [Ceilometer] MySQL performance and Mongodb\n	backend maturity question','Excerpts from Qiming Teng\'s message of 2014-09-24 20:37:39 -0700:\n> Hi,\n> \n> Some weeks ago, I checked my then latest devstack install and I learned\n> this: event support in Ceilometer is only available for sqlalchemy\n> backend; mongodb backend was still under development.  I have been using\n> MySQL during the past weeks and now I think I\'m trapped by a performance\n> problem of MySQL.\n> \n> One or two Nova servers were launched and remain idle for about 10 days.\n> Now I\'m seeing a lot of data accumulated in db and I wanted to cleanse\n> it manually.  Here is what I got:\n> \n> mysql> select count(*) from metadata_text;\n> +----------+\n> | count(*) |\n> +----------+\n> | 25249913 |\n> +----------+\n> 1 row in set (3.83 sec)\n> \n> mysql> delete from metadata_text limit 1000;\n> Query OK, 1000 rows affected (0.02 sec)\n> \n> mysql> delete from metadata_text limit 10000;\n> Query OK, 10000 rows affected (0.39 sec)\n> \n> mysql> delete from metadata_text limit 100000;\n> Query OK, 100000 rows affected (2.31 sec)\n> \n> mysql> delete from metadata_text limit 1000000;\n> Query OK, 1000000 rows affected (25.32 sec)\n> \n> mysql> delete from metadata_text limit 2000000;\n> Query OK, 2000000 rows affected (1 min 16.17 sec)\n> \n> mysql> delete from metadata_text limit 4000000;\n> Query OK, 4000000 rows affected (7 min 40.40 sec)\n> \n> There were 25M records in one table.  The deletion time is reaching an\n> unacceptable level (7 minutes for 4M records) and it was not increasing\n> in a linear way.  Maybe DB experts can show me how to optimize this?\n\nWow, you definitely do not want to be doing transactions like that on a\nregular basis. It is just murder on performance and can be deadly for\nthings like replication. If you plan to do the whole table, just use\ntruncate table.\n\nThis is not unique to Ceilometer, and is in fact as old as databases\nreally.\n\nThere is a fantastic tool for doing it as efficiently as possible\nthough:\n\nhttp://www.percona.com/doc/percona-toolkit/2.1/pt-archiver.html\n\nIt will try to order by the physical blocks in the table, and do small\nchunks continuously to minimize the impact. You can also have it sleep\nfor an amount of time based on how long the last delete took, so that\nyou are responsive to server load and impact.\n\nThe approach pt-archiver uses should be built in to any purge commands,\nbut many of the purge commands I\'ve encountered in OpenStack just throw\na massive delete at the DB and hope for the best. I have not looked at\nCeilometer\'s.\n\nPlease note this is mostly an operational question, and not a development\nquestion, so I think this thread might want to move over to the openstack@\nmailing list.\n\n\n','<20140925033736.GA16052@localhost>',NULL),('<1411628005-sup-7563@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 00:01:48',-25200,'2014-09-25 07:01:48',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Mike Spreitzer\'s message of 2014-09-24 22:01:54 -0700:\n> Clint Byrum <clint at fewbar.com> wrote on 09/25/2014 12:13:53 AM:\n> \n> > Excerpts from Mike Spreitzer\'s message of 2014-09-24 20:49:20 -0700:\n> > > Steven Dake <sdake at redhat.com> wrote on 09/24/2014 11:02:49 PM:\n> > > > ...\n> > > ...\n> > > Does TripleO require container functionality that is not available\n> > > when using the Docker driver for Nova?\n> > > \n> > > As far as I can tell, the quantitative handling of capacities and\n> > > demands in Kubernetes is much inferior to what Nova does today.\n> > > \n> > \n> > Yes, TripleO needs to manage baremetal and containers from a single\n> > host. Nova and Neutron do not offer this as a feature unfortunately.\n> \n> In what sense would Kubernetes \"manage baremetal\" (at all)?\n> By \"from a single host\" do you mean that a client on one host\n> can manage remote baremetal and containers?\n> \n> I can see that Kubernetes allows a client on one host to get\n> containers placed remotely --- but so does the Docker driver for Nova.\n> \n\nI mean that one box would need to host Ironic, Docker, and Nova, for\nthe purposes of deploying OpenStack. We call it the \"undercloud\", or\nsometimes the \"Deployment Cloud\".\n\nIt\'s not necessarily something that Nova/Neutron cannot do by design,\nbut it doesn\'t work now.\n\n> > \n> > > > As far as use cases go, the main use case is to run a specific \n> > > > Docker container on a specific Kubernetes \"minion\" bare metal host.\n> \n> Clint, in another branch of this email tree you referred to\n> \"the VMs that host Kubernetes\".  How does that square with\n> Steve\'s text that seems to imply bare metal minions?\n> \n\nThat was in a more general context, discussing using Kubernetes for\ngeneral deployment. Could have just as easily have said \"hosts\",\n\"machines\", or \"instances\".\n\n> I can see that some people have had much more detailed design\n> discussions than I have yet found.  Perhaps it would be helpful\n> to share an organized presentation of the design thoughts in\n> more detail.\n> \n\nI personally have not had any detailed discussions about this before it\nwas announced. I\'ve just dug into the design and some of the code of\nKubernetes because it is quite interesting to me.\n\n> > > \n> > > If TripleO already knows it wants to run a specific Docker image\n> > > on a specific host then TripleO does not need a scheduler.\n> > > \n> > \n> > TripleO does not ever specify destination host, because Nova does not\n> > allow that, nor should it. It does want to isolate failure domains so\n> > that all three Galera nodes aren\'t on the same PDU, but we\'ve not really\n> > gotten to the point where we can do that yet.\n> \n> So I am still not clear on what Steve is trying to say is the main use \n> case.\n> Kubernetes is even farther from balancing among PDUs than Nova is.\n> At least Nova has a framework in which this issue can be posed and solved.\n> I mean a framework that actually can carry the necessary information.\n> The Kubernetes scheduler interface is extremely impoverished in the\n> information it passes and it uses GO structs --- which, like C structs,\n> can not be subclassed.\n\nI don\'t think this is totally clear yet. The thing that Steven seems to be\ntrying to solve is deploying OpenStack using docker, and Kubernetes may\nvery well be a better choice than Nova for this. There are some really\nnice features, and a lot of the benefits we\'ve been citing about image\nbased deployments are realized in docker without the pain of a full OS\nimage to redeploy all the time.\n\nThe structs vs. classes argument is completely out of line and has\nnothing to do with where Kubernetes might go in the future. It\'s like\nsaying because cars use internal combustion engines they are limited. It\nis just a facet of how it works today.\n\n> Nova\'s filter scheduler includes a fatal bug that bites when balancing and \n> you want more than\n> one element per area, see https://bugs.launchpad.net/nova/+bug/1373478.\n> However: (a) you might not need more than one element per area and\n> (b) fixing that bug is a much smaller job than expanding the mind of K8s.\n> \n\nPerhaps. I am quite a fan of set based design, and Kubernetes is a\nnarrowly focused single implementation solution, where Nova is a broadly\nfocused abstraction layer for VM\'s. I think it is worthwhile to push\na bit into the Kubernetes space and see whether the limitations are\nimportant or not.\n\n\n','<OFE6F0E706.A2F0D134-ON85257D5E.0019DDB4-85257D5E.001BA380@us.ibm.com>',NULL),('<1411653682.77274.YahooMailNeo@web126103.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-25 07:01:22',-25200,'2014-09-25 14:01:22',NULL,'[Openstack-docs] Welcome to Elke Vorheis!','Thanks for the welcoming words. Elke\n \nElke Vorheis\n(650) 291-1375 (cell)\nelkev at yahoo.com (email)\n\n\nOn Thursday, September 25, 2014 6:58 AM, Nicholas Chase <nchase at mirantis.com> wrote:\n \n\n\nJust wanted to take a moment to welcome Elke Vorheis, an experienced \ncontract technical writer who\'s going to be helping us out in getting \nthrough our backlog.  Elke will start out helping with the Networking \nGuide and the Install Guide where needed.\n\nThanks, and welcome aboard, Elke!\n\n----  Nick\n-- \nNick Chase\n1-650-567-5640\nTechnical Marketing Manager, Mirantis\nEditor, OpenStack:Now\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140925/6ae9640e/attachment.html>\n\n','<54241F1D.7070402@mirantis.com>',NULL),('<1411660454-sup-704@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 08:55:09',-25200,'2014-09-25 15:55:09',NULL,'[openstack-dev] [Ceilometer] MySQL performance and Mongodb\n	backend maturity question','Excerpts from Daniele Venzano\'s message of 2014-09-25 02:40:11 -0700:\n> On 09/25/14 10:12, Qiming Teng wrote:\n> > Yes, just about 3 VMs running on two hosts, for at most 3 weeks. This \n> > is leading me to another question -- any best practices/tools to \n> > retire the old data on a regular basis? Regards, Qiming\n> \n> There is a tool: ceilometer-expirer\n> \n> I tried to use it on a mysql database, since I had the same table size \n> problem as you and it made the machine hit swap. I think it tries to \n> load the whole table in memory.\n> Just to see if it would eventually finish, I let it run for 1 week \n> before throwing away the whole database and move on.\n> \n> Now I use Ceilometer\'s pipeline to forward events to elasticsearch via \n> udp + logstash and do not use Ceilometer\'s DB or API at all.\n> \n\nInteresting, this almost sounds like what should be the default\nconfiguration honestly.\n\n\n','<5423E2FB.5020101@eurecom.fr>',NULL),('<1411662790-sup-8907@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 09:34:57',-25200,'2014-09-25 16:34:57',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','First, Kevin, please try to figure out a way to reply in-line when you\'re\nreplying to multiple levels of threads. Even if you have to copy and\nquote it manually.. it took me reading your message and the previous\nmessage 3 times to understand the context.\n\nSecond, I don\'t think anybody minds having a control plane for each\nlevel of control. The point isn\'t to replace the undercloud, but to\nreplace nova rebuild as the way you push out new software while\nretaining the benefits of the image approach.\n\nExcerpts from Fox, Kevin M\'s message of 2014-09-25 09:07:10 -0700:\n> Then you still need all the kubernetes api/daemons for the master and slaves. If you ignore the complexity this adds, then it seems simpler then just using openstack for it. but really, it still is an under/overcloud kind of setup, your just using kubernetes for the undercloud, and openstack for the overcloud?\n> \n> Thanks,\n> Kevin\n> ________________________________\n> From: Steven Dake [sdake at redhat.com]\n> Sent: Wednesday, September 24, 2014 8:02 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker\n> \n> On 09/24/2014 03:31 PM, Alan Kavanagh wrote:\n> Steven\n> I have to ask what is the motivation and benefits we get from integrating Kubernetes into Openstack? Would be really useful if you can elaborate and outline some use cases and benefits Openstack and Kubernetes can gain.\n> \n> /Alan\n> \n> Alan,\n> \n> I am either unaware or ignorant of another Docker scheduler that is currently available that has a big (100+ folks) development community.  Kubernetes meets these requirements and is my main motivation for using it to schedule Docker containers.  There are other ways to skin this cat - The TripleO folks wanted at one point to deploy nova with the nova docker VM manager to do such a thing.  This model seemed a little clunky to me since it isn\'t purpose built around containers.\n> \n> As far as use cases go, the main use case is to run a specific Docker container on a specific Kubernetes \"minion\" bare metal host.  These docker containers are then composed of the various config tools and services for each detailed service in OpenStack.  For example, mysql would be a container, and tools to configure the mysql service would exist in the container.  Kubernetes would pass config options for the mysql database prior to scheduling and once scheduled, Kubernetes would be responsible for connecting the various containers together.\n> \n> Regards\n> -steve\n> \n> \n> \n> From: Steven Dake [mailto:sdake at redhat.com]\n> Sent: September-24-14 7:41 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker\n> \n> On 09/24/2014 10:12 AM, Joshua Harlow wrote:\n> Sounds like an interesting project/goal and will be interesting to see where this goes.\n> \n> A few questions/comments:\n> \n> How much golang will people be exposed to with this addition?\n> \n> Joshua,\n> \n> I expect very little.  We intend to use Kubernetes as an upstream project, rather then something we contribute to directly.\n> \n> \n> Seeing that this could be the first \'go\' using project it will be interesting to see where this goes (since afaik none of the infra support exists, and people aren\'t likely to familiar with go vs python in the openstack community overall).\n> \n> What\'s your thoughts on how this will affect the existing openstack container effort?\n> \n> I don\'t think it will have any impact on the existing Magnum project.  At some point if Magnum implements scheduling of docker containers, we may add support for Magnum in addition to Kubernetes, but it is impossible to tell at this point.  I don\'t want to derail either project by trying to force them together unnaturally so early.\n> \n> \n> I see that kubernetes isn\'t exactly a small project either (~90k LOC, for those who use these types of metrics), so I wonder how that will affect people getting involved here, aka, who has the resources/operators/other... available to actually setup/deploy/run kubernetes, when operators are likely still just struggling to run openstack itself (at least operators are getting used to the openstack warts, a new set of kubernetes warts could not be so helpful).\n> \n> Yup it is fairly large in size.  Time will tell if this approach will work.\n> \n> This is an experiment as Robert and others on the thread have pointed out :).\n> \n> Regards\n> -steve\n> \n> \n> On Sep 23, 2014, at 3:40 PM, Steven Dake <sdake at redhat.com<mailto:sdake at redhat.com>> wrote:\n> \n> \n> Hi folks,\n> \n> I\'m pleased to announce the development of a new project Kolla which is Greek for glue :). Kolla has a goal of providing an implementation that deploys OpenStack using Kubernetes and Docker. This project will begin as a StackForge project separate from the TripleO/Deployment program code base. Our long term goal is to merge into the TripleO/Deployment program rather then create a new program.\n> \n> \n> \n> Docker is a container technology for delivering hermetically sealed applications and has about 620 technical contributors [1]. We intend to produce docker images for a variety of platforms beginning with Fedora 20. We are completely open to any distro support, so if folks want to add new Linux distribution to Kolla please feel free to submit patches :)\n> \n> \n> \n> Kubernetes at the most basic level is a Docker scheduler produced by and used within Google [2]. Kubernetes has in excess of 100 technical contributors. Kubernetes is more then just a scheduler, it provides additional functionality such as load balancing and scaling and has a significant roadmap.\n> \n> \n> The #tripleo channel on Freenode will be used for Kolla developer and user communication. Even though we plan to become part of the Deployment program long term, as we experiment we believe it is best to hold a separate weekly one hour IRC meeting on Mondays at 2000 UTC in #openstack-meeting [3].\n> \n> \n> This project has been discussed with the current TripleO PTL (Robert Collins) and he seemed very supportive and agreed with the organization of the project outlined above. James Slagle, a TripleO core developer, has kindly offered to liase between Kolla and the broader TripleO community.\n> \n> \n> \n> I personally feel it is necessary to start from a nearly empty repository when kicking off a new project. As a result, there is limited code in the repository [4] at this time. I suspect folks will start cranking out a kick-ass implementation once the Kolla/Stackforge integration support is reviewed by the infra team [5].\n> \n> \n> \n> The initial core team is composed of Steven Dake, Ryan Hallisey, James Lebocki, Jeff Peeler, James Slagle, Lars Kellogg-Sedman, and David Vossel. The core team will be reviewed every 6 weeks to add fresh developers.\n> \n> \n> Please join the core team in designing and inventing this rockin\' new technology!\n> \n> \n> Regards\n> -steve\n> \n> \n> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n> \n> \n> \n> [1] https://github.com/docker/docker [2] https://github.com/GoogleCloudPlatform/kubernetes\n> \n> [3] https://wiki.openstack.org/wiki/Meetings/Kolla [4] https://github.com/jlabocki/superhappyfunshow [5] https://review.openstack.org/#/c/122972/\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> \n> _______________________________________________\n> \n> OpenStack-dev mailing list\n> \n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1A3C52DFCD06494D8528644858247BF0880B14@EX10MBOX03.pnnl.gov>',NULL),('<1411663192-sup-4279@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-25 09:43:33',-25200,'2014-09-25 16:43:33',NULL,'[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and\n	Manage OpenStack using Kubernetes and Docker','Excerpts from Fox, Kevin M\'s message of 2014-09-25 09:13:26 -0700:\n> Why can\'t you manage baremetal and containers from a single host with nova/neutron? Is this a current missing feature, or has the development teams said they will never implement it?\n> \n\nIt\'s a bug.\n\nBut it is also a complexity that isn\'t really handled well in Nova\'s\ncurrent design. Nova wants to send the workload onto the machine, and\nthat is it. In this case, you have two workloads, one hosted on the other,\nand Nova has no model for that. You end up in a weird situation where one\n(baremetal) is host for other (containers) and no real way to separate\nthe two or identify that dependency.\n\nI think it\'s worth pursuing in OpenStack, but Steven is solving deployment\nof OpenStack today with tools that exist today. I think Kolla may very\nwell prove that the container approach is too different from Nova\'s design\nand wants to be more separate, at which point our big tent will be in\nan interesting position: Do we adopt Kubernetes and put an OpenStack\nAPI on it, or do we re-implement it.\n\n\n','<1A3C52DFCD06494D8528644858247BF0880B32@EX10MBOX03.pnnl.gov>',NULL),('<1411677630.71003.YahooMailNeo@web126105.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-25 13:40:30',-25200,'2014-09-25 20:40:30',NULL,'[Openstack-docs] Welcome to Elke Vorheis!','Hi Anne,\n\nThanks for the kind words. Looking forward to working with you. By the way, I sent an invite on Skype. Elke\n \nElke Vorheis\n(650) 291-1375 (cell)\nelkev at yahoo.com (email)\n\n\nOn Thursday, September 25, 2014 1:22 PM, Anne Gentle <anne at openstack.org> wrote:\n \n\n\nWelcome Elke! So nice to have you here. Feel free to ask us questions here, on IRC, or you can call/Skype me. I\'m annegentle all over the place. :)\n\nThanks for working with us!\nAnne\n\n\nOn Thu, Sep 25, 2014 at 8:56 AM, Nicholas Chase <nchase at mirantis.com> wrote:\n\nJust wanted to take a moment to welcome Elke Vorheis, an experienced contract technical writer who\'s going to be helping us out in getting through our backlog.  Elke will start out helping with the Networking Guide and the Install Guide where needed.\n>\n>Thanks, and welcome aboard, Elke!\n>\n>----  Nick\n>-- \n>Nick Chase\n>1-650-567-5640\n>Technical Marketing Manager, Mirantis\n>Editor, OpenStack:Now\n>\n>_______________________________________________\n>Openstack-docs mailing list\n>Openstack-docs at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140925/bfb95a96/attachment.html>\n\n','<CAD0KtVFbc3dw8B4nxce5BG9j-hDvkMrFAW7xMtU1+qG9OYaRtA@mail.gmail.com>',NULL),('<1411738388586.331b3914@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-26 06:33:09',-25200,'2014-09-26 13:33:09',NULL,'[Openstack] understanding flows of ovs in openstack','What I would suggest is ovs switch independently of openstack by using mininet and then explore openstack ovs usage?\n\n\n\n\n\n\n\nJust my2cents\n?\nSent from Mailbox\n\n\n\n\n\nOn Friday, Sep 26, 2014 at 9:30 AM, Srinivasreddy R <srinivasreddy4390 at gmail.com>, wrote:\n\n\n\n\nhi ,\n\ni want to understand? the role of openvswitch? in openstack .\n\nhow and what flows are configured? in both compute and networknode . \n\nplease suggest .\n\n\nthanks,\nsrinivas.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140926/bc702671/attachment.html>\n\n','<CAJP4VWgrph2A1Kq2L+_+dsGddcif01ONLikqu4MufRBd=bPq8w@mail.gmail.com>',NULL),('<1411771919-sup-3476@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-26 15:56:40',-25200,'2014-09-26 22:56:40',NULL,'[openstack-dev] Thoughts on OpenStack Layers and a Big Tent\n	model','Excerpts from Jay Pipes\'s message of 2014-09-26 14:43:40 -0700:\n> Hi James, thanks for the corrections/explanations. A comment inline (and \n> a further question) :)\n> \n> On 09/26/2014 05:35 PM, James Slagle wrote:\n> > On Fri, Sep 26, 2014 at 4:50 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n> >> Heh, I just got off the phone with Monty talking about this :) Comments\n> >> inline...\n> >>\n> >> On 09/22/2014 03:11 PM, Tim Bell wrote:\n> >>>\n> >>> The quality designation is really important for the operator\n> >>> community who are trying to work out what we can give to our end\n> >>> users.\n> >>\n> >>\n> >> So, I think it\'s important to point out here that there are three different\n> >> kinds of operators/deployers:\n> >>\n> >>   * Ones who use a distribution of OpenStack (RDO, UCA, MOS, Nebula, Piston,\n> >> etc)\n> >>   * Ones who use Triple-O\n> >>   * Ones who go it alone and install (via source, a mixture of source and\n> >> packages, via config management like Chef or Puppet, etc)\n> >\n> > I\'m not sure TripleO fits in this list. It is not just a collection of\n> > prescriptive OpenStack bits used to do a deployment. TripleO is\n> > tooling to build OpenStack to deploy OpenStack. You can use whatever\n> > \"source\" (packages, distribution, released tarballs, straight from\n> > git) you want to build that OpenStack. TripleO could deploy your first\n> > or third bullet item.\n> \n> OK, fair point, thanks for that added bit of description.\n> \n> >> In reality, you are referring to the last group, since operators in the\n> >> first group are saying \"we are relying on a distribution to make informed\n> >> choices about what is ready for prime time because we tested these things\n> >> together\". Operators in the second group are really only HP right now,\n> >> AFAICT, and Triple-O\'s \"opinion\" on the production readiness of the things\n> >> it deploys in the undercloud are roughly equal to \"all of the integrated\n> >> release that the TC defines\".\n> >\n> > FWIW, TripleO offers deploying using distributions, by installing from\n> > packages from the RDO repositories. There\'s nothing RDO specific about\n> > it though, any packaged OpenStack distribution could be installed with\n> > the TripleO tooling. RDO is just likely the most well tested.\n> \n> Oh, good to know. Sorry, my information about Triple-O\'s undercloud \n> setup is clearly outdated. I thought that the undercloud was build from \n> source repositories devstack-style. Thanks for hitting me with a \n> cluestick. :)\n> \n> > Even when not installing via a distribution, and either directly from\n> > trunk or the integrated release tarballs, I don\'t know that any\n> > TripleO opinion enters into it. TripleO uses the integrated projects\n> > of OpenStack to deploy an overcloud. In an overcloud, you may see\n> > support for some incubated projects, depending on if there\'s interest\n> > from the community for that support.\n> \n> OK, interesting. So, in summary, Triple-O really doesn\'t offer much of a \n> \"this is production-ready\" stamp to anything based on whether it deploys \n> a project or not. So, operators who deploy with Triple-O would be in the \n> \"you\'re on your own\" camp from the bulleted list above. Would that be a \n> fair statement?\n\nThe one thing that builds an overcloud in a prescriptive manner is called\n\'tripleo-incubator\' precisely because we don\'t believe it is ready to be\ncalled a release. It does focus on testing the integrated release only\nthough, and so is closer to your original #2. It\'s just important to\nnote that this is just our own distribution, and does not fully represent\nthe whole output of the program.\n\n\n','<5425DE0C.4020003@gmail.com>',NULL),('<1411772471-sup-9938@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-26 16:07:02',-25200,'2014-09-26 23:07:02',NULL,'[Openstack] [Nova] How does/will Openstack handle instance\n	replicas?','Excerpts from Adam Lawson\'s message of 2014-09-26 14:43:40 -0700:\n> Hello fellow stackers.\n> \n> I\'m looking for discussions/plans re VM continuity.\n> \n> I.e. Protection for instances using ephemeral storage against host failures\n> or auto-failover capability for instances on hosts where the host suffers\n> from an attitude problem?\n> \n> I know fail-overs are supported and I\'m quite certain auto-fail-overs are\n> possible in the event of a host failure (hosting instances not using shared\n> storage). I just can\'t find where this has been addressed/discussed.\n> \n> Someone help a brother out? ; )\n\nI\'m sure some of that is possible, but it\'s a cloud, so why not do things\nthe cloud way?\n\nSpin up redundant bits in disparate availability zones. Replicate only\nwhat must be replicated. Use volumes for DR only when replication would\nbe too expensive.\n\nInstances are cattle, not pets. Keep them alive just long enough to make\nyour profit.\n\n\n','<CAJfWK4-CMcKxR+1fyUsYqZwzK=c7CHbv7CFMNAPHN1u4jigTbg@mail.gmail.com>',NULL),('<1411802257-sup-1325@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-27 00:32:38',-25200,'2014-09-27 07:32:38',NULL,'[Openstack] [Nova] How does/will Openstack handle instance\n	replicas?','So, what you\'re looking for is basically the same old IT, but with an\nAPI. I get that. For me, the point of this cloud thing is so that server\noperators can make _reasonable_ guarantees, and application operators\ncan make use of them in an automated fashion.\n\nIf you start guaranteeing 4 and 5 nines for single VM\'s, you\'re right\nback in the boat of spending a lot on server infrastructure even if your\nusers could live without it sometimes.\n\nCompute hosts are going to go down. Networks are going to partition. It\nis not actually expensive to deal with that at the application layer. In\nfact when you know your business rules, you\'ll do a better job at doing\nthis efficiently than some blanket \"replicate all the things\" layer might.\n\nI know, some clouds are just new ways to chop up these fancy 40 core\nmegaservers that everyone is shipping. I\'m sure OpenStack can do it, but\nI\'m saying, I don\'t think OpenStack _should_ do it.\n\nExcerpts from Adam Lawson\'s message of 2014-09-26 20:30:29 -0700:\n> Generally speaking that\'s true when you have full control over how you\n> deploy applications as a consumer. As a provider however, cloud resiliency\n> is king and it\'s generally frowned upon to associate instances directly to\n> the underlying physical hardware for any reason. It\'s good when instances\n> can come and go as needed, but in a production context, a failed compute\n> host shouldn\'t take down every instance hosted on it. Otherwise there is no\n> real abstraction going on and the cloud loses immense value.\n> On Sep 26, 2014 4:15 PM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> \n> > Excerpts from Adam Lawson\'s message of 2014-09-26 14:43:40 -0700:\n> > > Hello fellow stackers.\n> > >\n> > > I\'m looking for discussions/plans re VM continuity.\n> > >\n> > > I.e. Protection for instances using ephemeral storage against host\n> > failures\n> > > or auto-failover capability for instances on hosts where the host suffers\n> > > from an attitude problem?\n> > >\n> > > I know fail-overs are supported and I\'m quite certain auto-fail-overs are\n> > > possible in the event of a host failure (hosting instances not using\n> > shared\n> > > storage). I just can\'t find where this has been addressed/discussed.\n> > >\n> > > Someone help a brother out? ; )\n> >\n> > I\'m sure some of that is possible, but it\'s a cloud, so why not do things\n> > the cloud way?\n> >\n> > Spin up redundant bits in disparate availability zones. Replicate only\n> > what must be replicated. Use volumes for DR only when replication would\n> > be too expensive.\n> >\n> > Instances are cattle, not pets. Keep them alive just long enough to make\n> > your profit.\n> >\n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >\n\n\n','<CAJfWK49u60a7bAO+URoYJ2BtWH9VmYo_WQyeBXcLN7C4og5kAA@mail.gmail.com>',NULL),('<1412012288414.dac1f6c6@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-29 10:38:09',-25200,'2014-09-29 17:38:09',NULL,'[Openstack] Rackspace abandons Open vSwitch ?','---\nRaghu V. Vadapalli\nPrincipal Software Architect \nSmart Packet Solutions\n\n\n\n\nOn Monday, Sep 29, 2014 at 1:33 PM, NAPIERALAMARIA H <mn1921 at att.com>, wrote:\n\nOn 27.09.2014 06:37, Jason K?lker wrote:\n\n>> On Sat, Sep 27, 2014 at 3:50 AM, Raghu Vadapalli <rvatspac... at gmail.com> \n\n>> wrote:\n\n>>> As per this news article listed below, Rackspace is abandoning Open vSwitch.\n\n>>> Is this where everyone else going in general ?\n\n>> \n\n>> That conclusion is inaccurate. The entirety of the public cloud runs\n\n>> openvswitch for both public/servicenet connectivity as well as\n\n>> isolated tenant network features.The article is referring to the\n\n>> private cloud distribution no longer choosing to use the Neutron\n\n>> OpenVswitch plugin\n\n>> (https://github.com/openstack/neutron/tree/master/neutron/plugins/openvswitch)\n\n>> as it is being deprecated. The ML2 plugin replaces this and can use a\n\n>> variety of mechanisms including openvswitch.\n\n>> \n\n>> The article\'s conclusion that openvswitch is not ready for production\n\n>> and high-volume workloads is ludicrous. Versions 2.0+ perform very\n\n>> well with multithreading in the vswitchd process and megaflows in the\n\n>> datapath. However it is important to point out that datapath\n\n>> performance is very much related to the flows programmed. A poorly\n\n>> written flow set will result in bad performance. Tuning the flows and\n\n>> optimizing the ability for megaflow\'ing is the key to high throughput.\n\n?\n\n> That\'s the theory though and the article seems to talk about practical\n\n> problem Rackspace ran into with OVS so it would have been nice to learn\n\n> what specifically was the problem.\n\n?\n\n> What are the alternatives though? As far as I know the regular linux\n\n> bridge lacks most of the features of OVS and these are the only to\n\n> options I\'ve played with so far. Is the a third alternative out there\n\n> that they\'ve switched to?\n\n?\n\nOne alternative is OpenContrail vRouter as ML3 plugin. It meets the scale and feature requirements.\n\n?\n\nMaria\n\n?\n\n\n\n?did you?mean to say contrail with ML2 not ML3 ? I am not quite sure contrail integration but is ml3 available in icehouse yet ?\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140929/8fc5bbc5/attachment.html>\n\n','<1D70D757A2C9D54D83B4CBD7625FA80E01D94627@MISOUT7MSGUSRCF.ITServices.sbc.com>',NULL),('<1412020098.2845955.173125313.15457305@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-29 12:48:18',-25200,'2014-09-29 19:48:18',NULL,'[openstack-dev] Unusual behavior on committing a change','On Mon, Sep 29, 2014, at 12:34 PM, Sharan Kumar M wrote:\n> Hi all,\n> \n> I am getting some weird things when I try to submit a patch for review.\n> May\n> be I am doing something wrong.\n> \n> I cloned the repo, setup git review and setup my gerrit username in git\n> config. I updated an image in the docs/source/images directory and\n> committed. After I commit, I get the git status report as\n> \n> \"Your branch and \'origin/master\' have diverged,\n> and have 1 and 1 different commit each, respectively.\"\n> \n> When I see the log, the last commit is authored by\n> jenkins at review.openstack.org with the same commit message as mine. The\n> author name is supposed to be mine right? The last time I submitted for\n> review, the commit message had my name as author.\n> \n> Could someone help me out with this issue?\n> Thanks,\n> Sharan Kumar M\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI think you may have amended the last commit that Gerrit merged rather\nthan creating a new commit. Did you run `git commit --amend` on top of\nthe last upstream commit?\n\nIf so the easiest way to fix this is probably to `git checkout master &&\ngit reset --hard origin/master` then make your changes and finally `git\ncommit` without the --amend.\n\nClark\n\n\n','<CAKp-o+gAUyCrPSnZDf4P_zq9_+=V2VW_+H=b13xFu6vcLbdq0w@mail.gmail.com>',NULL),('<1412032312-sup-780@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-29 16:15:26',-25200,'2014-09-29 23:15:26',NULL,'[openstack-dev] [keystone][swift] Has anybody considered\n	storing tokens in Swift?','Excerpts from Clay Gerrard\'s message of 2014-09-29 16:05:14 -0700:\n> On Mon, Sep 29, 2014 at 2:53 PM, Chmouel Boudjnah <chmouel at enovance.com>\n> wrote:\n> \n> >\n> >\n> > eventual consistency will only affect container listing  and I don\'t think\n> > there is a need for container listing in that driver.\n> >\n> >\n> well now hold on...\n> \n> if you\'re doing an overwrite in the face of server failures you could still\n> get a stale read if a server with an old copy comes back into the fray and\n> you read before replication sorts it out, or read a old version of a key\n> you deleted....\n\nFor tokens, there are really only two answers that matter:\n\n* does ID==X exist?  * has ID==X been revoked?\n\nI think as long as you have a separate container for revocations and\ntokens, then resurrections would be fine. The records themselves would\nbe immutable so edits aren\'t a problem.\n\nIt would, however, be bad to get a 404 for something that is otherwise\npresent.. as that will result in an erroneous failure for the client.\n\n\n','<CA+_JKzr5n_vNwXy02JA2Raujb3pN-PXkxaeSSRp=fCK=_h3PhA@mail.gmail.com>',NULL),('<1412177419.4399.3.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-01 17:30:19',7200,'2014-10-01 15:30:19',NULL,'[Openstack] Unable to assign ip to instance in compute node-2','If you\'re using tunneling (e.g vxlan) you may have to enable the vxlan\nport (default 4789) for incoming traffic on your compute nodes iptables.\nMy default iptables rules sent back an icmp admin prohibited to the dhcp\noffer, so I also never got an ip addresss.\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Tue, 2014-09-30 at 16:46 +0530, Srinivasreddy R wrote:\n> hi,\n> \n> I have  configured  3 node  setup. Able to access instance form\n> external network and internal network .\n> \n> i have attached another compute node in the current 3 node setup . \n> \n> Launched instance in compute-2  but instance is not able to get the\n> internal ip address  through dhcp .\n> \n> Is there any additional configuration required when i added new\n> compute node .\n> \n> How can i debug this .\n> \n> \n>  Able to see IP for that instance when launching nova list command on\n> controller node as well on dash board. \n> \n> user at user-ThinkCentre-M73:~$ nova list\n> +--------------------------------------+----------------+--------+------------+-------------+--------------------------------+\n> | ID                                   | Name           | Status |\n> Task State | Power State | Networks                       |\n> +--------------------------------------+----------------+--------+------------+-------------+--------------------------------+\n> | a28e3e67-7621-418a-9626-838c2396cd34 | comp2-inst3    | ACTIVE | -\n> | Running     | demo-net=11.0.0.34, 172.0.0.10 |\n> | 83cf5d08-23a0-45b4-9485-07fa035b58b7 | ins1           | ACTIVE | -\n> | Running     | demo-net=11.0.0.9, 172.0.0.7   |\n> | b2b57156-0c7f-4669-9946-b4a0e6ae8c1f | my_instance001 | ACTIVE | -\n> | Running     | demo-net=11.0.0.2, 172.0.0.3   |\n> | 2a311004-76e1-4c71-b043-76ebd306179f | my_instance002 | ACTIVE | -\n> | Running     | demo-net=11.0.0.5, 172.0.0.4   |\n> | 16af4e2e-8247-45eb-93dd-fc1304bf4601 | open-instance1 | ACTIVE | -\n> | Running     | demo-net=11.0.0.11, 172.0.0.8  |\n>  \n> \n> \n> thanks,\n> srinivas.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<CAJP4VWiFMW0Rofc7yh5FOx0GXsgf8d6Ri6gOYWRrvjpiud7L6A@mail.gmail.com>',NULL),('<1412182558-sup-922@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 09:57:01',-25200,'2014-10-01 16:57:01',NULL,'[openstack-dev] [kolla] Kolla Blueprints','Excerpts from Steven Dake\'s message of 2014-10-01 08:04:38 -0700:\n> On 09/30/2014 09:55 AM, Chmouel Boudjnah wrote:\n> >\n> > On Tue, Sep 30, 2014 at 6:41 PM, Steven Dake <sdake at redhat.com \n> > <mailto:sdake at redhat.com>> wrote:\n> >\n> >\n> >     I\'ve done a first round of prioritization.  I think key things we\n> >     need people to step up for are nova and rabbitmq containers.\n> >\n> >     For the developers, please take a moment to pick a specific\n> >     blueprint to work on.  If your already working on something, this\n> >     hsould help to prevent duplicate work :)\n> >\n> >\n> >\n> > As I understand in the current implementations[1]  the containers are \n> > configured with a mix of shell scripts using crudini and other shell \n> > command. Is it the way to configure the containers? and is a \n> > deployment tool like Ansible (or others) is something that is planned \n> > to be used in the future?\n> >\n> > Chmouel\n> >\n> Chmouel,\n> \n> I am not really sure what the best solution to configure the \n> containers.  It is clear to me the current shell scripts are fragile in \n> nature and do not handle container restart properly.  The idea of using \n> Puppet or Ansible as a CM tool has been discussed with no resolution.  \n> At the moment, I\'m satisified with a somewhat hacky solution if we can \n> get the containers operational.\n\nWhat if we modified diskimage-builder to create docker containers out\nof the existing tripleo-image-elements?\n\n\n','<542C1806.7030908@redhat.com>',NULL),('<1412194716.2512198.174068529.15B7B13B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 13:18:36',-25200,'2014-10-01 20:18:36',NULL,'[openstack-dev] [nova][neutron] \"Sideways\" grenade job to test Nova\n Network to Neutron migration','Hello,\n\nOne of the requirements placed on Ironic was that they must have a path\nfrom Nova Baremetal to Ironic and that path should be tested. This\nresulted in a \"sideways\" grenade job which instead of going from one\nrelease of OpenStack to another, swaps out components within a release.\nIn this case the current Juno release.\n\nWhen throwing this together for Ironic I went ahead and put a skeleton\njob, check-grenade-dsvm-neutron-sideways, in place for testing a Nova\nNetwork to Neutron \"sideways\" upgrade. This job is in the experimental\nqueues for Neutron, grenade, and devstack-gate at the moment and does\nnot pass. While it may be too late to focus on this for Juno it would be\ngreat if Neutron and Nova could make this test pass early in the Kilo\ncycle as a clear Nova Network to Neutron process is often asked for.\n\nRandom choice of current job result can be found at\nhttp://logs.openstack.org/29/123629/1/experimental/check-grenade-dsvm-neutron-sideways/fb45df6/\n\nThe way this job works is it sets up an \"old\" and \"new\" pair of master\nbased cloud configs. The \"old\" side is configured to use Nova Network\nand the \"new\" side is configured to use Neutron. Grenade then fires up\nthe \"old\" cloud, adds some things to it, runs some tests, shuts it down,\n\"upgrades\", then checks that things still work in the \"new\" cloud. My\nbest guess is that most of the work here will need to be done in the\n\"upgrade\" section where we teach Grenade (and consequently everyone\nelse) how to make this transition.\n\nThanks,\nClark\n\n\n',NULL,NULL),('<1412214044-sup-1812@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 18:50:33',-25200,'2014-10-02 01:50:33',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Recently we\'ve been testing image based updates using TripleO, and we\'ve\nrun into an interesting conundrum.\n\nCurrently, our image build scripts create a user per service for the\nimage. We don\'t, at this time, assert a UID, so it could get any UID in\nthe /etc/passwd database of the image.\n\nHowever, if we add a service that happens to have its users created\nbefore a previously existing service, the UID\'s shift by one. When\nthis new image is deployed, the username might be \'ceilometer\', but\n/mnt/state/var/lib/ceilometer is now owned by \'cinder\'.\n\nHere are 3 approaches, which are not mutually exclusive to one another.\nThere are likely others, and I\'d be interested in hearing your ideas.\n\n* Static UID\'s for all state-preserving services. Basically we\'d just\n  allocate these UID\'s from a static pool and those are always the UIDs\n  no matter what. This is the simplest solution, but does not help\n  anybody who is already looking to update a TripleO cloud. Also, this\n  would cause problems if TripleO wants to merge with any existing\n  system that might also want to use similar UID\'s. This also provides\n  no guard against non-static UID\'s storing things on the state\n  partition.\n\n* Fix the UID\'s on image update. We can backup /etc/passwd and\n  /etc/group to /mnt/state, and on bootup we can diff the two, and any\n  UIDs that changed can be migrated. This could be very costly if the\n  swift storage UID changed, with millions of files present on the\n  system. This merge process is also not atomic and may not be\n  reversible, so it is a bit scary to automate this.\n\n* Assert ownership when registering state path. We could have any\n  state-preserving elements register their desire for any important\n  globs for the state drive to be owned by a particular symbolic\n  username. This is just a different, more manual way to fix the UID\'s\n  and carries the same cons.\n\nSo, what do people think?\n\n\n',NULL,NULL),('<1412215557-sup-5793@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 02:09:38',0,'2014-10-02 02:09:38',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Clint Byrum\'s message of 2014-10-02 01:50:33 +0000:\n> Recently we\'ve been testing image based updates using TripleO, and we\'ve\n> run into an interesting conundrum.\n> \n> Currently, our image build scripts create a user per service for the\n> image. We don\'t, at this time, assert a UID, so it could get any UID in\n> the /etc/passwd database of the image.\n> \n> However, if we add a service that happens to have its users created\n> before a previously existing service, the UID\'s shift by one. When\n> this new image is deployed, the username might be \'ceilometer\', but\n> /mnt/state/var/lib/ceilometer is now owned by \'cinder\'.\n\nWow, nice find!\n\n> \n> Here are 3 approaches, which are not mutually exclusive to one another.\n> There are likely others, and I\'d be interested in hearing your ideas.\n> \n> * Static UID\'s for all state-preserving services. Basically we\'d just\n>   allocate these UID\'s from a static pool and those are always the UIDs\n>   no matter what. This is the simplest solution, but does not help\n>   anybody who is already looking to update a TripleO cloud. Also, this\n>   would cause problems if TripleO wants to merge with any existing\n>   system that might also want to use similar UID\'s. This also provides\n>   no guard against non-static UID\'s storing things on the state\n>   partition.\n\n+1 for this approach for the reasons mentioned.\n\n> \n> * Fix the UID\'s on image update. We can backup /etc/passwd and\n>   /etc/group to /mnt/state, and on bootup we can diff the two, and any\n>   UIDs that changed can be migrated. This could be very costly if the\n>   swift storage UID changed, with millions of files present on the\n>   system. This merge process is also not atomic and may not be\n>   reversible, so it is a bit scary to automate this.\n\nIf we really want to go with this type of aproach we could also just\ncopy the existing /etc/passwd into the image thats being built. Then\nwhen users are added they should be added in after existing users.\n\nI still prefer the first solution, though.\n\n> \n> * Assert ownership when registering state path. We could have any\n>   state-preserving elements register their desire for any important\n>   globs for the state drive to be owned by a particular symbolic\n>   username. This is just a different, more manual way to fix the UID\'s\n>   and carries the same cons.\n> \n> So, what do people think?\n> \n\n\n','<1412214044-sup-1812@fewbar.com>',NULL),('<1412231680-sup-9021@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 06:43:29',0,'2014-10-02 06:43:29',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from James Polley\'s message of 2014-10-02 05:37:25 +0000:\n> All three of the options presented here seem to assume that UIDs will always be allocated at image-build time. I think that\'s because most of these UIDs will be used to write files into the chroot at image-create time - if I could think of some way around that, I think we could avoid this problem more neatly by not assigning the UIDs until first boot\n> \n> But since we can\'t do that, would it be possible to compromise by having the UIDs read in from heat metadata, and using the current allocation process if none is provided?\n> \n> This should allow people who prefer to have static UIDs to have simple drop-in config, but also allow people who want to dynamically read from existing images to scrape the details and then drop them in.\n> \n> To aid people who have existing images, perhaps we could provide a small tool (if one doesn\'t already exist) that simply reads /etc/passwd and returns a JSON username:uid map, to be added into the heat local environment when building the next image?\n> \n\nWhat I was suggesting before as an alternate solution is a more simple\nversion of this - just copy the existing /etc/passwd and friends into\nthe chroot at the start of building a new image. This should cause new\nusers to be created in a safe way.\n\nIMO I like the uid pinning better as a solution, though.\n\nCheers,\nGreg\n\n\n','<8B8C1194-4D93-4828-9A95-2F12AB2C49DF@jamezpolley.com>',NULL),('<1412234412.4314.11.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 09:20:12',7200,'2014-10-02 07:20:12',NULL,'[openstack-dev] [neutron] openvswitch integration','Hi together, \nI\'m wondering why ovs was integrated into openstack in the way it is\ntoday\n(http://docs.openstack.org/grizzly/openstack-network/admin/content/under_the_hood_openvswitch.html)\n\nEspecially I would like to understand\n- why does every physical interface have its own bridge? (I guess you\ncould also plug it directly into the br-int)\n- and why does the br-int use vlan separation and not directly the\nconfigured tenant-network-type separation (e.g. vxlan or something\nelse)? Tagging a packet with the internal vlan and then converting it to\nthe external vlan again looks strange to me in the first place.\n\nIt\'s just a feeling but this surely has impact on the performance. I\nguess latency and cpu consumption will surely go up with this design.\nAre there any technical or historical reasons for it? Or is it just to\nreduce complexity?\n\nThanks!\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1412259155-sup-2710@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 07:15:30',-25200,'2014-10-02 14:15:30',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Gregory Haynes\'s message of 2014-10-01 19:09:38 -0700:\n> Excerpts from Clint Byrum\'s message of 2014-10-02 01:50:33 +0000:\n> > Recently we\'ve been testing image based updates using TripleO, and we\'ve\n> > run into an interesting conundrum.\n> > \n> > Currently, our image build scripts create a user per service for the\n> > image. We don\'t, at this time, assert a UID, so it could get any UID in\n> > the /etc/passwd database of the image.\n> > \n> > However, if we add a service that happens to have its users created\n> > before a previously existing service, the UID\'s shift by one. When\n> > this new image is deployed, the username might be \'ceilometer\', but\n> > /mnt/state/var/lib/ceilometer is now owned by \'cinder\'.\n> \n> Wow, nice find!\n> \n\nIndeed, the Helion dev team discovered this one whilst working on updating\nbetween alternating builds that added or removed some services.\n\nOh, I forgot to mention the bug reference:\n\nhttps://bugs.launchpad.net/tripleo/+bug/1374626\n\n> > \n> > Here are 3 approaches, which are not mutually exclusive to one another.\n> > There are likely others, and I\'d be interested in hearing your ideas.\n> > \n> > * Static UID\'s for all state-preserving services. Basically we\'d just\n> >   allocate these UID\'s from a static pool and those are always the UIDs\n> >   no matter what. This is the simplest solution, but does not help\n> >   anybody who is already looking to update a TripleO cloud. Also, this\n> >   would cause problems if TripleO wants to merge with any existing\n> >   system that might also want to use similar UID\'s. This also provides\n> >   no guard against non-static UID\'s storing things on the state\n> >   partition.\n> \n> +1 for this approach for the reasons mentioned.\n> \n> > \n> > * Fix the UID\'s on image update. We can backup /etc/passwd and\n> >   /etc/group to /mnt/state, and on bootup we can diff the two, and any\n> >   UIDs that changed can be migrated. This could be very costly if the\n> >   swift storage UID changed, with millions of files present on the\n> >   system. This merge process is also not atomic and may not be\n> >   reversible, so it is a bit scary to automate this.\n> \n> If we really want to go with this type of aproach we could also just\n> copy the existing /etc/passwd into the image thats being built. Then\n> when users are added they should be added in after existing users.\n> \n\nI do like this approach, and it isn\'t one I had considered. We will know\nwhat image we want to update from in nearly every situation. Also this\nsupports another case, which is rolling back to the previous image,\nquite well.\n\nReally this is just an automated form of static UID assignment.\n\n\n','<1412215557-sup-5793@greghaynes0.opus.gah>',NULL),('<1412259335-sup-4086@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 07:25:04',-25200,'2014-10-02 14:25:04',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from James Polley\'s message of 2014-10-01 22:37:25 -0700:\n> All three of the options presented here seem to assume that UIDs will always be allocated at image-build time. I think that\'s because most of these UIDs will be used to write files into the chroot at image-create time - if I could think of some way around that, I think we could avoid this problem more neatly by not assigning the UIDs until first boot\n> \n\nYeah I don\'t think we\'re going to work around that. It is part of the\nmagic of images that the metadata is all in place and there\'s no \"churn\"\nat boot.\n\n> But since we can\'t do that, would it be possible to compromise by having the UIDs read in from heat metadata, and using the current allocation process if none is provided?\n> \n\nI really, really dislike this. Post-boot tools like Heat are for\nper-server customization and site-wide changes. UIDs seem like plumbing\nunder the hood.\n\n> This should allow people who prefer to have static UIDs to have simple drop-in config, but also allow people who want to dynamically read from existing images to scrape the details and then drop them in.\n> \n\nI see your point, and I\'m now confused as I don\'t really understand what\nwould make somebody prefer dynamic UID allocation.\n\n> To aid people who have existing images, perhaps we could provide a small tool (if one doesn\'t already exist) that simply reads /etc/passwd and returns a JSON username:uid map, to be added into the heat local environment when building the next image?\n> \n\nOr a tool that reads the image, and returns /etc/passwd and /etc/group.\n\nThanks very much for your thoughts. :)\n\n\n','<8B8C1194-4D93-4828-9A95-2F12AB2C49DF@jamezpolley.com>',NULL),('<1412259912-sup-3697@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 07:26:34',-25200,'2014-10-02 14:26:34',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Sullivan, Jon Paul\'s message of 2014-10-02 02:08:26 -0700:\n> > -----Original Message-----\n> > From: Clint Byrum [mailto:clint at fewbar.com]\n> > Sent: 02 October 2014 02:51\n> > To: openstack-dev\n> > Subject: [openstack-dev] [TripleO] a need to assert user ownership in\n> > preserved state\n> > \n> > Recently we\'ve been testing image based updates using TripleO, and we\'ve\n> > run into an interesting conundrum.\n> > \n> > Currently, our image build scripts create a user per service for the\n> > image. We don\'t, at this time, assert a UID, so it could get any UID in\n> > the /etc/passwd database of the image.\n> > \n> > However, if we add a service that happens to have its users created\n> > before a previously existing service, the UID\'s shift by one. When this\n> > new image is deployed, the username might be \'ceilometer\', but\n> > /mnt/state/var/lib/ceilometer is now owned by \'cinder\'.\n> > \n> > Here are 3 approaches, which are not mutually exclusive to one another.\n> > There are likely others, and I\'d be interested in hearing your ideas.\n> > \n> > * Static UID\'s for all state-preserving services. Basically we\'d just\n> >   allocate these UID\'s from a static pool and those are always the UIDs\n> >   no matter what. This is the simplest solution, but does not help\n> >   anybody who is already looking to update a TripleO cloud. Also, this\n> >   would cause problems if TripleO wants to merge with any existing\n> >   system that might also want to use similar UID\'s. This also provides\n> >   no guard against non-static UID\'s storing things on the state\n> >   partition.\n> > \n> > * Fix the UID\'s on image update. We can backup /etc/passwd and\n> >   /etc/group to /mnt/state, and on bootup we can diff the two, and any\n> >   UIDs that changed can be migrated. This could be very costly if the\n> >   swift storage UID changed, with millions of files present on the\n> >   system. This merge process is also not atomic and may not be\n> >   reversible, so it is a bit scary to automate this.\n> > \n> > * Assert ownership when registering state path. We could have any\n> >   state-preserving elements register their desire for any important\n> >   globs for the state drive to be owned by a particular symbolic\n> >   username. This is just a different, more manual way to fix the UID\'s\n> >   and carries the same cons.\n> \n> For these last two cases, of fixing the file ownership on first boot based on the previous UIDs of a username, why would we decide to fix the data files?\n> \n> If instead we were to change the UIDs such that the data files were correct, the only thing to fix up would be the installed files in the image, which are a well-defined and limited set of files.\n> \n\nGreat point JP!\n\nI think that this is similar to Greg\'s suggestion of copying the uid/gid\ndatabase into the image. If we copy it in before the image is built, we\n\"fix\" the image by building it right in the first place.\n\n\n','<A5492763B7A1E640AEB5E1C05208B1F254643408@G4W3226.americas.hpqcorp.net>',NULL),('<1412299.uHUqTzmSEE@dblinov.sw.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-26 20:17:58',14400,'2014-03-26 16:17:58',NULL,'[Openstack] [glance] uploading new data for an existing image','On Wednesday 26 March 2014 15:38:03 Christian Berendt wrote:\n> On 03/26/2014 03:19 PM, stuart.mclaren at hp.com wrote:\n> > This is not supported - image data is immutable.\n> \n> $ glance image-create --name TESTING --container-format bare\n> --disk-format raw --file cirros-0.3.1-x86_64-disk.img\n> \n> checksum: d972013792949d0d3ba628fbe8685bce\n> \n> $ glance image-update --file cirros-0.3.2-x86_64-disk.img TESTING\n> \n> checksum: d972013792949d0d3ba628fbe8685bce\n> \n> The second command returned without an error and has not uploaded the\n> new image. But it should be possible, shouldn\'t it?\n> \n>   --file <FILE>         Local file that contains disk image to be\n>                         uploaded during update. Alternatively, images\n>                         can be passed to the client via stdin.\n> \n> Christian.\n\nIt\'s probably a bug in a glance client, with v2 API it reports error \ncorrectly:\n\nglance --os-image-api-version=2  image-update ed56772d-67f4-4d7e-\na10f-88d66e242642 --min-ram 128 --file new-image \nRequest returned failure status.\n403 Forbidden\nAttribute \'file\' is read-only.\n    (HTTP 403)\n\n-- \nDmitry Guryanov\n\n\n','<5332E64B.10206@b1-systems.de>',NULL),('<1412317438.30441.13.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-03 07:23:58',3600,'2014-10-03 06:23:58',NULL,'[OpenStack Foundation] Resigning as Individual Director','Hi there\n\nWith Brian Stevens recent departure with Red Hat, our Platinum Director\nboard seat is now vacant. We have decided that I should represent Red\nHat on the board.\n\nThis implies that I must resign as Individual Director. Personally, this\nis a difficult decision for me, because I\'ve always greatly valued being\nan independent voice representing the individual members. I\'m also\nconscious that resigning now is going to cause some churn quite late in\nthe year.\n\nThe reasoning goes like this - we think I can best represent Red Hat on\nthe board, we don\'t think it\'s ideal to leave a Platinum Director seat\nvacant for any length of time, and we\'d prefer to avoid the churn of\nappointing a temporary Red Hat representative while I serve the\nremainder of my term as Individual Director.\n\nJonathan has been working to figure out the process which should follow\nan Individual Director resignation. I\'ll let him share details on that.\n\nMy sincere apologies if this disappoints anyone. I have been honored to\nserve as Individual Director, and I\'m very grateful to everyone who\nvoted for me.\n\nThanks!\n\nMark.\n\n\n\n',NULL,NULL),('<1412323689.30441.29.camel@sorcha>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-03 09:08:09',3600,'2014-10-03 08:08:09',NULL,'[OpenStack Foundation] [Foundation Board] Resigning as\n	Individual Director','On Thu, 2014-10-02 at 23:33 -0700, Monty Taylor wrote:\n> On 10/02/2014 11:23 PM, Mark McLoughlin wrote:\n> > Hi there\n> > \n> > With Brian Stevens recent departure with Red Hat, our Platinum Director\n> > board seat is now vacant. We have decided that I should represent Red\n> > Hat on the board.\n> > \n> > This implies that I must resign as Individual Director. Personally, this\n> > is a difficult decision for me, because I\'ve always greatly valued being\n> > an independent voice representing the individual members. I\'m also\n> > conscious that resigning now is going to cause some churn quite late in\n> > the year.\n> > \n> > The reasoning goes like this - we think I can best represent Red Hat on\n> > the board, we don\'t think it\'s ideal to leave a Platinum Director seat\n> > vacant for any length of time, and we\'d prefer to avoid the churn of\n> > appointing a temporary Red Hat representative while I serve the\n> > remainder of my term as Individual Director.\n> \n> I, for one, think the idea of having you in the Platinum seat as someone\n> who has the community support to be elected directly is pretty exciting\n> actually. I also have no doubt that your voice will remain your voice.\n> \n> > Jonathan has been working to figure out the process which should follow\n> > an Individual Director resignation. I\'ll let him share details on that.\n> > \n> > My sincere apologies if this disappoints anyone. I have been honored to\n> > serve as Individual Director, and I\'m very grateful to everyone who\n> > voted for me.\n> \n> I\'ll miss having you in the Individual ranks - but am glad you\'ll still\n> be with us.\n\nThanks Monty, appreciated :)\n\nMark.\n\n\n\n','<542E4342.40403@inaugust.com>',NULL),('<1412354218.311615258@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-10-03 11:36:58',-18000,'2014-10-03 16:36:58',NULL,'[openstack-community] OpenStack Event Policy','\nIf you are planning an OpenStack-branded event, please review the Event Policy at [ http://www.openstack.org/brand/event-policy/ ]( http://www.openstack.org/brand/event-policy/ ).  One change: you can now post your OpenStack events directly to the openstack.org/community/events page at the upper right \"Post An Event For Free\" link.  Exciting additions for regional event organizers are in the works for later this year (post-Paris Summit); stay tuned!  Thank you.\n \n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141003/9cb091d3/attachment.html>\n\n',NULL,NULL),('<1412364262774.1b5020a3@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-03 12:24:23',-25200,'2014-10-03 19:24:23',NULL,'[openstack-dev] [Cinder][TripleO] Last days to elect your PTL!','Are the commits to Tuskar or Tuskar UI? Tuskar is under the tripleo project group but Tuskar UI is under Horizon IIRC.\n\nOn Fri, Oct 3, 2014 at 8:22 PM, John Griffith <john.griffith at solidfire.com>\nwrote:\n\n> On Fri, Oct 3, 2014 at 1:14 PM, Jason Rist <jrist at redhat.com> wrote:\n>> On 10/01/2014 08:22 PM, Tristan Cacqueray wrote:\n>> > Hello Cinder and TripleO contributors,\n>> >\n>> > Just a quick reminder that elections are closing soon, if you haven\'t\n>> > already you should use your right to vote and pick your favourite\n>> candidate!\n>> >\n>> > Thanks for your time!\n>> > Tristan\n>> >\n>> >\n>> >\n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >\n>> Hi Tristan - I\'m not a super heavy contributor, but I think I have a few\n>> commits.  I didn\'t ever get an email from the voting provider?\n>>\n>> Thanks,\n>> Jason\n>>\n>> --\n>> Jason E. Rist\n>> Senior Software Engineer\n>> OpenStack Management UI\n>> Red Hat, Inc.\n>> openuc: +1.972.707.6408\n>> mobile: +1.720.256.3933\n>> Freenode: jrist\n>> github/identi.ca: knowncitizen\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n> ?Hey Jason,\n> I could be wrong, but it looks like you\'ve committed to Tuskar and\n> Horizon?.  Since those were uncontested you would not receive a voting\n> invite.  You only get to vote on the projects you commit to.\n> Thanks,\n> John\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/f59a2f81/attachment.html>\n\n','<CA+qL3LVc5DDaczq2XbYCscE3b8ObLHMakF6DJEgJO-9VmxY30w@mail.gmail.com>',NULL),('<1412365443.3274272.174916949.38F541FE@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-10-03 12:44:03',-25200,'2014-10-03 19:44:03',NULL,'[OpenStack-Infra] DevStack on CentOS','On Fri, Oct 3, 2014, at 03:53 AM, Parimala Prahlada wrote:\n> Hi,\n> \n> I am newbie to openstack community.  I was looking to participate in OPW\n> and hence started setting up devstack.\n> I am referring http://sayalilunkad.github.io/posts/Devstack/.\n> \n> I have a VM with CentOS6.4 installed with git (1.8.4), perl (5.10.1),\n> python (2.7.5) etc.\n> With this setup, I started with initial setup of DevStack.\n> \n> However, when I run the script \"stack.sh\" to install OpenStack, I am\n> getting the following error.\n> \n> \n> **********************************************************************************************************************************************************************************************************************************\n> \n> Downloading Packages:\n> http://repoforge.mirror.net.in/repoforge/redhat/el6/en/i386/extras/RPMS/\n> *git-1.7.12.4-1.el6.rfx.i686.rpm*: [Errno -1] Package does not match\n> intended download. Suggestion: run yum --enablerepo=rpmforge-extras clean\n> metadata\n> Trying other mirror.\n> \n> http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-6/python-migrate-0.8.2-1.el6.noarch.rpm:\n> [Errno 14] PYCURL ERROR 6 - \"Couldn\'t resolve host\n> \'repos.fedorapeople.org\'\"\n> Trying other mirror.\n> http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-6/python-prettytable-0.7.2-1.el6.noarch.rpm:\n> [Errno 14] PYCURL ERROR 6 - \"Couldn\'t resolve host\n> \'repos.fedorapeople.org\'\"\n> Trying other mirror.\n> http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-6/python-webob-1.2.3-8.el6.noarch.rpm:\n> [Errno 14] PYCURL ERROR 6 - \"Couldn\'t resolve host\n> \'repos.fedorapeople.org\'\"\n> Trying other mirror.\n> http://mirror.smartmedia.net.id/repoforge/redhat/el6/en/i386/extras/RPMS/qemu-img-0.15.0-1.el6.rfx.i686.rpm:\n> [Errno 14] PYCURL ERROR 6 - \"Couldn\'t resolve host\n> \'mirror.smartmedia.net.id\n> \'\"\n> Trying other mirror.\n> \n> \n> Error Downloading Packages:\n>   python-prettytable-0.7.2-1.el6.noarch: failure:\n> python-prettytable-0.7.2-1.el6.noarch.rpm from openstack-icehouse: [Errno\n> 256] No more mirrors to try.\n>   python-migrate-0.8.2-1.el6.noarch: failure:\n> python-migrate-0.8.2-1.el6.noarch.rpm from openstack-icehouse: [Errno\n> 256]\n> No more mirrors to try.\n>   python-webob-1.2.3-8.el6.noarch: failure:\n> python-webob-1.2.3-8.el6.noarch.rpm from openstack-icehouse: [Errno 256]\n> No\n> more mirrors to try.\n> \n> ++ [[ 1 != 0 ]]\n> ++ die 1115 \'Yum install failure\'\n> ++ local exitcode=0\n> ++ set +o xtrace\n> [Call Trace]\n> ./stack.sh:687:source\n> /home/parimala/OPW-2014/devstack/tools/install_prereqs.sh:64:install_package\n> /home/parimala/OPW-2014/devstack/functions-common:1055:real_install_package\n> /home/parimala/OPW-2014/devstack/functions-common:1043:yum_install\n> /home/parimala/OPW-2014/devstack/functions-common:1115:die\n> [ERROR] /home/parimala/OPW-2014/devstack/functions-common:1115 Yum\n> install\n> failure\n> Error on exit\n> World dumping... see ./worlddump-2014-10-02-142624.txt for details\n> \n> **********************************************************************************************************************************************************************************************************************************\n> \n> \n> stack.sh is trying to download git 1.7.12.\n> As I have mentioned earlier, I am having git 1.8.4 already installed on\n> my\n> system.\n> So why is the script looking for an older version of git?  Can I force\n> the\n> script to use the existing installation of packages?\n> \n> Any help in this regard is highly appreciated.\n> \n> (I have to fix a bug to submit my application for the OPW, hence please\n> help)\n> \n> Thanks and Regards,\n> Parimala\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nIt looks like yum tried to get packages from repos.fedorapeople.org and\nDNS resolution failed. Perhaps this was a temporary failure and\nrerunning will not run into name resolution problems? Also, we have\nnever really tested devstack on CentOS like we do on Ubuntu. This will\nprobably change with CentOS 7 in the near future but not with 6. You\nmight also try using Ubuntu Precise or Trusty VMs.\n\nAs for the git thing that may depend on how you have newer git\ninstalled. Was 1.8.4 installed via yum so that the package DB knows that\nit exists? I don\'t think devstack care about a specific version it is\njust ensuring that git exists.\n\nClark\n\n\n','<CAPDA-OK5RckDfcFLg0Yv+_miHUzDydd_nrQ9Tnbi-LL4N5aL+g@mail.gmail.com>',NULL),('<1412380924.54790.YahooMailNeo@web181704.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-03 17:02:04',-25200,'2014-10-04 00:02:04',NULL,'[Openstack] stale data returned even when \"X-Newest : True\" is used','Hello,\n\nI did a test on a SWIFT cluster to verify the use of X-Newest header with GET/HEAD requests.\nHowever, the GET/HEAD requests are still returning an older copy of the object.\nThis behavior persists even after 5 hours.\n\nThe relevant HTTP headers are given below. SWIFT version is 2.0.3.\n\nI am looking for some guidance on how to debug this on the SWIFT side.\n\nThis is the information I received from the people that set up this SWIFT cluster:\n====\n\nWe have One Haproxy loadbalancer , connected to two SWIFT proxies and then they further connect to 3 storage nodes (12 disk of 2000 GB each).\n====\n\nRegards,\nPramodh\n\nPUT updates the object from 37014 bytes to 37200 bytes.\n\n----------------------------------\nPUT /v1/AUTH_4d6923c0011f4ba3a40af75d522d3494/riverbedprimary%2D7/sourcefile1?format=xml HTTP/1.1\nHost: 192.168.0.195:8080\nAccept: */*\nContent-Type: application/octet-stream\nDate: Fri, 03 Oct 2014 18:46:14 GMT\nEtag: 6ea9ae59e1e932297f0d9d7b02e91244\nX-Auth-Token: b0510a7aca424a32a04d21072bb2561d\nX-Object-Meta-Md5: 6ea9ae59e1e932297f0d9d7b02e91244\nContent-Length: 37200\n\nHTTP/1.1 201 Created\nLast-Modified: Fri, 03 Oct 2014 18:44:54 GMT\nContent-Length: 0\nEtag: 6ea9ae59e1e932297f0d9d7b02e91244\nContent-Type: text/html; charset=UTF-8\nX-Trans-Id: txb9d2715069e3411da9e1c-00542eeea5\nDate: Fri, 03 Oct 2014 18:44:53 GMT\n======\n\n\nHEAD returns content length 37014 bytes in spite of X-Newest being set to true.\n--------------------------------------------\nHEAD /v1/AUTH_4d6923c0011f4ba3a40af75d522d3494/riverbedprimary%2D7/sourcefile1 HTTP/1.1\nHost: 192.168.0.195:8080\nAccept: */*\nDate: Fri, 03 Oct 2014 19:00:40 GMT\nX-Auth-Token: 1394369b9fdd4206be647a0b09fc51a2\nX-Newest: True\n\nHTTP/1.1 200 OK\nContent-Length: 37014\nContent-Type: application/octet-stream\nAccept-Ranges: bytes\nLast-Modified: Fri, 03 Oct 2014 18:46:11 GMT\nEtag: 12efe95bad4a32822303580f184098a9\nX-Timestamp: 1412361970.27333\nX-Object-Meta-Md5: 12efe95bad4a32822303580f184098a9\nX-Trans-Id: tx87c0e41dce6f4ddda3d17-00542ef207\nDate: Fri, 03 Oct 2014 18:59:19 GMT\n======\n\n\nSame result with GET\n--------------------------\n\nGET /v1/AUTH_4d6923c0011f4ba3a40af75d522d3494/riverbedprimary%2D7/sourcefile1 HTTP/1.1\nHost: 192.168.0.195:8080\nAccept: */*\nDate: Fri, 03 Oct 2014 19:04:21 GMT\nX-Auth-Token: 77ed6791288e4ea0879a6b484e5f9603\nX-Newest: True\n\nHTTP/1.1 200 OK\nContent-Length: 37014\nContent-Type: application/octet-stream\nAccept-Ranges: bytes\nLast-Modified: Fri, 03 Oct 2014 18:46:11 GMT\nEtag: 12efe95bad4a32822303580f184098a9\nX-Timestamp: 1412361970.27333\nX-Object-Meta-Md5: 12efe95bad4a32822303580f184098a9\nX-Trans-Id: txb54c347ffc15444a9afa5-00542ef2e4\nDate: Fri, 03 Oct 2014 19:03:00 GMT\n======\n\nHEAD /v1/AUTH_4d6923c0011f4ba3a40af75d522d3494/riverbedprimary%2D7/sourcefile1 HTTP/1.1\nHost: 192.168.0.195:8080\nAccept: */*\nDate: Fri, 03 Oct 2014 19:22:41 GMT\nX-Auth-Token: a1d4771da0d8424aa6a4a6a5a4a17eaa\nX-Newest: True\n\nHTTP/1.1 200 OK\nContent-Length: 37014\nContent-Type: application/octet-stream\nAccept-Ranges: bytes\nLast-Modified: Fri, 03 Oct 2014 18:46:11 GMT\nEtag: 12efe95bad4a32822303580f184098a9\nX-Timestamp: 1412361970.27333\nX-Object-Meta-Md5: 12efe95bad4a32822303580f184098a9\nX-Trans-Id: txc13e1852db0d48f3b9c35-00542ef77f\nDate: Fri, 03 Oct 2014 19:22:39 GMT\n======\n\nGET /v1/AUTH_4d6923c0011f4ba3a40af75d522d3494/riverbedprimary%2D7/sourcefile1 HTTP/1.1\nHost: 192.168.0.195:8080\nAccept: */*\nDate: Fri, 03 Oct 2014 19:22:50 GMT\nX-Auth-Token: b2289a21703a4129b448e9dca11e03b7\nX-Newest: True\n\nHTTP/1.1 200 OK\nContent-Length: 37014\nContent-Type: application/octet-stream\nAccept-Ranges: bytes\nLast-Modified: Fri, 03 Oct 2014 18:46:11 GMT\nEtag: 12efe95bad4a32822303580f184098a9\nX-Timestamp: 1412361970.27333\nX-Object-Meta-Md5: 12efe95bad4a32822303580f184098a9\nX-Trans-Id: tx31b18ad62d6b4f07abb51-00542ef739\nDate: Fri, 03 Oct 2014 19:21:29 GMT\n======\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141003/aa3616c3/attachment.html>\n\n',NULL,NULL),('<1412436170-sup-3756@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-04 08:24:54',-25200,'2014-10-04 15:24:54',NULL,'[openstack-dev] [Group-based Policy] Database migration chain','\nExcerpts from Mike Bayer\'s message of 2014-10-04 08:10:38 -0700:\n> \n> On Oct 4, 2014, at 1:10 AM, Kevin Benton <blak111 at gmail.com> wrote:\n> \n> > Does sqlalchemy have good support for cross-database foreign keys? I was under the impression that they cannot be implemented with the normal syntax and semantics of an intra-database foreign-key constraint. \n> \n> cross ?database? is not typically portable, but cross ?schema? is.   \n> \n> different database vendors have different notions of ?databases? or ?schemas?.\n> \n> if you can get the ?other database? to be accessible from the target database via ?otherdatabase.sometable?, then you?re in.\n> \n> from SQLAlchemy?s perspective, it?s just a name with a dot.   It?s the database itself that has to support the foreign key at the scope you are shooting for.\n> \n\nAll true, however, there are zero guarantees that databases will be\nhosted on the same server, and typically permissions are setup to prevent\ncross-schema joins.\n\nTypically we use the public API\'s when we want to access data in a\ndifferent application. The database is a private implementation detail\nof each application.\n\n\n','<362257E1-65B3-4123-90B6-B700D96E0A5B@redhat.com>',NULL),('<1412603284-sup-1624@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 14:06:02',0,'2014-10-06 14:06:02',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Clint Byrum\'s message of 2014-10-02 14:15:30 +0000:\n> Excerpts from Gregory Haynes\'s message of 2014-10-01 19:09:38 -0700:\n> > If we really want to go with this type of aproach we could also just\n> > copy the existing /etc/passwd into the image thats being built. Then\n> > when users are added they should be added in after existing users.\n> > \n> \n> I do like this approach, and it isn\'t one I had considered. We will know\n> what image we want to update from in nearly every situation. Also this\n> supports another case, which is rolling back to the previous image,\n> quite well.\n> \n> Really this is just an automated form of static UID assignment.\n> \n\nNow that ive proposed this id like to make an argument against the copy\n/etc/passwd as our long term solution (sorry). I do think its a not bad\nimmediate fix, but long term id prefer actual static UID assignment out\nof the solutions proposed so far.\n\nIt seems like determining how to build a new image based on the state of\na previous image is an exact anti-pattern that read only / ephemeral\ninstances aim to solve - minimize entropy collected over time from doing\nupdates. Were also adding a requirement that user databases are now\nprecious data which cannot ever be lost for a given image type. Its\nworth noting that these are both issues that operators will encounter.\n\nStatic UID/GID assignment requires more developer work but AFAICT it\npasses less potential issues off onto operators (which should be our\ngoal).\n\nCheers,\nGreg\n\n\n','<1412259155-sup-2710@fewbar.com>',NULL),('<1412612993-sup-6369@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 09:41:49',-25200,'2014-10-06 16:41:49',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Gregory Haynes\'s message of 2014-10-06 07:06:02 -0700:\n> Excerpts from Clint Byrum\'s message of 2014-10-02 14:15:30 +0000:\n> > Excerpts from Gregory Haynes\'s message of 2014-10-01 19:09:38 -0700:\n> > > If we really want to go with this type of aproach we could also just\n> > > copy the existing /etc/passwd into the image thats being built. Then\n> > > when users are added they should be added in after existing users.\n> > > \n> > \n> > I do like this approach, and it isn\'t one I had considered. We will know\n> > what image we want to update from in nearly every situation. Also this\n> > supports another case, which is rolling back to the previous image,\n> > quite well.\n> > \n> > Really this is just an automated form of static UID assignment.\n> > \n> \n> Now that ive proposed this id like to make an argument against the copy\n> /etc/passwd as our long term solution (sorry). I do think its a not bad\n> immediate fix, but long term id prefer actual static UID assignment out\n> of the solutions proposed so far.\n> \n\nWe have to be _extremely_ careful in how we manage this. I actually think\nit has potential to really blow up in our faces. We need to give people\na way to move forward without us merging a patch, and at the same time\nwe need to make sure we provide a consistent set of UIDs for anything\npeople may want to deploy with diskimage-builder.\n\n> It seems like determining how to build a new image based on the state of\n> a previous image is an exact anti-pattern that read only / ephemeral\n> instances aim to solve - minimize entropy collected over time from doing\n> updates. Were also adding a requirement that user databases are now\n> precious data which cannot ever be lost for a given image type. Its\n> worth noting that these are both issues that operators will encounter.\n> \n\nI disagree with some of these points. Expecting Linux filesystems to\nbe consumable from any machine without a source of consistent UIDs/GIDs\nis the anti-pattern. Using /etc/passwd and /etc/group from the previous\nimage is just one such source, and it is one source that anybody who has\na previous image will always have.\n\nIf you\'ve deployed using TripleO\'s tools already, you will not have\nthe same UIDs that our centralized UID registry would have. We could\nalso just deploy FreeIPA on all controllers, delay UID allocations, and\nput everything in LDAP. Having our own special project for static UIDs\nfeels like a third possible implementation, not one I\'m ready to say is\n\"the way\".\n\nI\'m leaning more toward keeping a copy of the UID/GID/symbolic-name\ndatabase anywhere that has state, and use a guard against making use of\na system database which conflicts with existing mappings on the state\ndrive. Then we can use either a static UID project, or previous images,\nas the source of UIDs/GIDs for new images, to avoid hitting the guard.\n\n> Static UID/GID assignment requires more developer work but AFAICT it\n> passes less potential issues off onto operators (which should be our\n> goal).\n\n\n+1 for making this as painless as possible on operators.\n\n\n','<1412603284-sup-1624@greghaynes0.opus.gah>',NULL),('<1412617224.4160.25.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-06 17:40:16',0,'2014-10-06 17:40:16',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management','Hello All, \n\nI wanted to start a discussion on floating IP management and ultimately\ndecide how the LBaaS group wants to handle the association. \n\nThere is a need to utilize floating IPs(FLIP) and its API calls to\nassociate a FLIP to the neutron port that we currently spin up. \n\nSee DOCS here:\n\n> http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_create.html\n\nCurrently, LBaaS will make internal service calls (clean interface :/) to create and attach a Neutron port. \nThe VIP from this port is added to the Loadbalancer object of the Load balancer configuration and returned to the user.\n\nThis creates a bit of a problem if we want to associate a FLIP with the port and display the FLIP to the user instead of\nthe ports VIP because the port is currently created and attached in the plugin and there is no code anywhere to handle the FLIP\nassociation. \n\nTo keep this short and to the point:\n\nWe need to discuss where and how we want to handle this association. I have a few questions to start it off. \n\nDo we want to add logic in the plugin to call the FLIP association API?\n\nIf we have logic in the plugin should we have configuration that identifies weather to use/return the FLIP instead the port VIP?\n\nWould we rather have logic for FLIP association in the drivers?\n\nIf logic is in the drivers would we still return the port VIP to the user then later overwrite it with the FLIP? \nOr would we have configuration to not return the port VIP initially, but an additional query would show the associated FLIP.\n\n\nIs there an internal service call for this, and if so would we use it instead of API calls? \n\n\nTheres plenty of other thoughts and questions to be asked and discussed in regards to FLIP handling, \nhopefully this will get us going. I\'m certain I may not be completely understanding this and \nis the hopes of this email to clarify any uncertainties. \n\n\n\n\n\n\n',NULL,NULL),('<1412702585-sup-4082@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 10:49:59',-25200,'2014-10-07 17:49:59',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Chris Jones\'s message of 2014-10-07 04:35:33 -0700:\n> Hi\n> \n> > On 6 Oct 2014, at 17:41, Clint Byrum <clint at fewbar.com> wrote:\n> > We have to be _extremely_ careful in how we manage this. I actually think\n> > it has potential to really blow up in our faces.\n> \n> Yes, anything we do here has the potential to be extremely ruinous for operators, but the reality is that any existing TripleO deployment is at pretty severe risk of blowing up because of UIDs/GIDs changing when they update.\n> \n> > We need to give people\n> > a way to move forward without us merging a patch, and at the same time\n> > we need to make sure we provide a consistent set of UIDs for anything\n> > people may want to deploy with diskimage-builder.\n> \n> IMO the only desirable option *has* to be that we statically define UIDs and GIDs in the elements, because:\n>  1: Requires no data fragments to be kept safe and fed to subsequent build processes\n>  2: Doesn\'t do anything dynamic on first boot that could take hours/days\n>  3: Can be thoroughly audited at build time to ensure correctness\n> \n> As you rightly point out though, any existing deployments will definitely be disrupted by this, but as I said above, all we\'d be doing there is moving the needle from \"possible/probable\" to \"definite\".\n> \n> Since the only leftovers we have from their previous image builds, are the images themselves, we could add the ability for a DIB run to extract IDs from a previous image, but this couldn\'t be required as a default build option, so we\'d still risk existing deployments if they don\'t notice this feature.\n> \n> We could create a script that would spider an existing cloud and extract its ID mappings, to produce a fragment to feed into future builds, but again we\'re relying on operators to know that they need to do this.\n> \n\nWelllll... they\'d know they need to do _something_ because their UIDs\nand GIDs are all horked up (technical term).\n\n> Instead, I agree with Greg\'s view that this is our fault and we should fix it. We didn\'t think of this sooner, and as a result, our users are at risk. If we don\'t entirely fix this ourselves, we will be both expecting them to become aware of this issue and expecting them to do additional work to mitigate it.\n> \n> To that end, I think we should audit all of our elements for use of /mnt/state/ and use the specific knowledge we have of the software they relate to, to build one-time ID migration scripts, which would:\n>  1: Execute before any related services start\n>  2: Compare the now-static ID mappings against known files in /mnt/state\n>  3: chown/chgrp any files/directories that need migrating\n>  4: store a flag file in /mnt/state indicating that this process doesn\'t need to run again\n> \n> It does mean they have a potentially painfully long update process once, but the result will be a completely stable, static arrangement that will not require them to preserve precious build fragments for the rest of time. Nor does it require some odd run-time remapping, or any additional mechanisms to centralise user management (e.g. LDAP. Please, no LDAP!)\n> \n> I think that tying ourselves and our operators into knots because we\'re afraid of the hit of one-time data migration, is crazy.\n> \n> AFAICS, the only risk left at that point, is elements that other people are maintaining. If we consider that to be a sufficient risk, we can still build the mechanism for injecting ID values from a previous build (essentially just seeding the static values that we\'d be setting anyway) and apologise to the users who need that, or who don\'t discover its existence and break their clouds.\n\nI\'m not afraid of running migrations once. I want to make sure we never\n_plan_ to run migrations as part of regular operation.\n\nI agree with most of what you\'ve written, but first I\'d start with this:\n\n* Create an element which exports /etc/passwd and /etc/group from build\nprocess.\n\n* Create an element which imports /etc/passwd and /etc/group from local\ndisk into image. This will have an element-provides of uid-gid-map\n\n* Create a separate element called \'static-users\' which also provides\nuid-gid-map. Contains a map of uids and gids, and creates users early on\nwith static UIDs/GIDs only. Disables usual commands used to add users and\ngroups (error message should explain well enough that user can add their\nown element that provides uid-gid-map or switch to importing/exporting).\n\n* Make use-ephemeral depend on uid-gid-map.\n\n* Make tripleo-ci build with static-users, and recommend it in TripleO\ndocumentation.\n\nOnce that is done, we will be producing builds with static users. If you\nwant to create a user for base TripleO, you\'ll need to do it by hand in\nthe static-users element. If you are downstream and want to do things\ndifferently that should be easy, just provide your own uid-gid-map\nelement.\n\nAs for migrations, that is fairly simple and can be done generically,\nI\'ve already written a script that does it fairly reliably. The only\nworry is of course that large collections of files will take a long\ntime. I\'ll submit that as a separate element called \'fix-state-uid-gid\'\nor something like that. We might as well include it in the default build,\nso that our images start fixing this problem now. :-P\n\n\n','<FC6F1489-A802-45E5-A14D-931BB22B98F9@tenshu.net>',NULL),('<1412710206.4498.52.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 19:25:54',0,'2014-10-07 19:25:54',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management','I\'ll add some more info to this as well:\n\nNeutron LBaaS creates the neutron port for the VIP in the plugin layer\nbefore drivers ever have any control.  In the case of an async driver,\nit will then call the driver\'s create method, and then return to the\nuser the vip info.  This means the user will know the VIP before the\ndriver even finishes creating the load balancer.\n\nSo if Octavia is just going to create a floating IP and then associate\nthat floating IP to the neutron port, there is the problem of the user\nnot ever seeing the correct VIP (which would be the floating iP).\n\nSo really, we need to have a very detailed discussion on what the\noptions are for us to get this to work for those of us intending to use\nfloating ips as VIPs while also working for those only requiring a\nneutron port.  I\'m pretty sure this will require changing the way V2\nbehaves, but there\'s more discussion points needed on that.  Luckily, V2\nis in a feature branch and not merged into Neutron master, so we can\nchange it pretty easily.  Phil and I will bring this up in the meeting\ntomorrow, which may lead to a meeting topic in the neutron lbaas\nmeeting.\n\nThanks,\nBrandon\n\n\nOn Mon, 2014-10-06 at 17:40 +0000, Phillip Toohill wrote:\n> Hello All, \n> \n> I wanted to start a discussion on floating IP management and ultimately\n> decide how the LBaaS group wants to handle the association. \n> \n> There is a need to utilize floating IPs(FLIP) and its API calls to\n> associate a FLIP to the neutron port that we currently spin up. \n> \n> See DOCS here:\n> \n> > http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_create.html\n> \n> Currently, LBaaS will make internal service calls (clean interface :/) to create and attach a Neutron port. \n> The VIP from this port is added to the Loadbalancer object of the Load balancer configuration and returned to the user.\n> \n> This creates a bit of a problem if we want to associate a FLIP with the port and display the FLIP to the user instead of\n> the ports VIP because the port is currently created and attached in the plugin and there is no code anywhere to handle the FLIP\n> association. \n> \n> To keep this short and to the point:\n> \n> We need to discuss where and how we want to handle this association. I have a few questions to start it off. \n> \n> Do we want to add logic in the plugin to call the FLIP association API?\n> \n> If we have logic in the plugin should we have configuration that identifies weather to use/return the FLIP instead the port VIP?\n> \n> Would we rather have logic for FLIP association in the drivers?\n> \n> If logic is in the drivers would we still return the port VIP to the user then later overwrite it with the FLIP? \n> Or would we have configuration to not return the port VIP initially, but an additional query would show the associated FLIP.\n> \n> \n> Is there an internal service call for this, and if so would we use it instead of API calls? \n> \n> \n> Theres plenty of other thoughts and questions to be asked and discussed in regards to FLIP handling, \n> hopefully this will get us going. I\'m certain I may not be completely understanding this and \n> is the hopes of this email to clarify any uncertainties. \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1412617224.4160.25.camel@localhost>',NULL),('<1412710455-sup-1409@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 12:47:13',-25200,'2014-10-07 19:47:13',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Chris Jones\'s message of 2014-10-07 12:23:20 -0700:\n> Hi\n> \n> > On 7 Oct 2014, at 18:49, Clint Byrum <clint at fewbar.com> wrote:\n> > * Create an element which imports /etc/passwd and /etc/group from local\n> > disk into image. This will have an element-provides of uid-gid-map\n> \n> I don\'t think it should import those files wholesale, IMO that\'s making way too many assumptions about the similarity of the two builds.\n> \n\nDisagree on the grounds that the point of this is to deal with people\nwho already have images and want to update them. We\'re not trying to\nenable people to deploy radically different OS\'s or anything like that.\n\n> I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each.\n> The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen).\n> \n\nThat is a lot of complexity for the case that we don\'t want people to\nuse (constantly carrying /etc/passwd and /etc/group forward).\n\n> > * Create a separate element called \'static-users\' which also provides\n> > uid-gid-map. Contains a map of uids and gids, and creates users early on\n> \n> I don\'t like the idea of keeping the map in a single element, for several reasons:\n>  1: Harder to maintain across multiple element repos (e.g. we have two repos, do we have a static-users equivalent in each?)\n>  2: Harder for downstreams to fork if they want to add an element we don\'t carry\n>  3: Harder for devs to commit to, especially if it means they need to simultaneously land something in di-b and t-i-e.\n> \n\nI think that makes sense. The per-element expressions will still need\nto be coalesced into one place to check for conflicts. I suppose if we\nuse \"add only\" tools that will work.\n\n> > with static UIDs/GIDs only. Disables usual commands used to add users and\n> > groups (error message should explain well enough that user can add their\n> \n> Are you suggesting disabling those during build time only, or runtime too? I strongly dislike the latter and I\'m not thrilled about the former. I\'d rather we leave them as-is and audit the passwd/group files at the end of the build, vs what we were expecting from the elements.\n> \n> (we should also be aware that by enforcing this, we\'ll be increasing the number of elements we need to supply, because any dependencies that get pulled in during the build, which create users/groups, will now error/fail the build)\n> \n\nSo I think we still do care about these. MySQL puts its files on\n/mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files\non /mnt/state. If an element installs a package that needs a user, we\nhave to treat that as our responsibility to handle, because we want to\npreserve /mnt/state.\n\n> > As for migrations, that is fairly simple and can be done generically,\n> > I\'ve already written a script that does it fairly reliably. The only\n> \n> Curious to see how that works - how can it know that /mnt/state/some/random/dir currently listed as \"ceilometer\" was actually owned by \"swift\" on the previous boot?\n\nIt also has to have access to the previous image\'s /etc/passwd and\n/etc/group. In the context I wrote it in, updating via ansible, I can\ncheat and copy that into /mnt/state before rebuilding the box. But we\ncan do that in our elements too. :)\n\n\n','<492D28BA-75FD-4A14-9512-C282F45F3280@tenshu.net>',NULL),('<1412717259-sup-6699@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 14:32:42',-25200,'2014-10-07 21:32:42',NULL,'[openstack-dev] [TripleO] a need to assert user ownership in\n	preserved state','Excerpts from Chris Jones\'s message of 2014-10-07 13:27:07 -0700:\n> Hi\n> \n> > On 7 Oct 2014, at 20:47, Clint Byrum <clint at fewbar.com> wrote:\n> >> \n> >> I don\'t think it should import those files wholesale, IMO that\'s making way too many assumptions about the similarity of the two builds.\n> > Disagree on the grounds that the point of this is to deal with people\n> > who already have images and want to update them. We\'re not trying to\n> > enable people to deploy radically different OS\'s or anything like that.\n> \n> My point is that we don\'t know what else is changing under the hood. Switching OS is a bit extreme, but we don\'t know that they\'re not going to pull in an OS upgrade at the same time and have everything change substantially, or even just introduce one additional dependency which we would destroy the uid/gid for.\n> \n\nOk, any time we can fail at build time is good, so merging is important. I agree now.\n\n> >> I think this needs to be at least somewhat driven from the elements themselves - they need to declare the users/groups they need and likely offer a default UID/GID for each.\n> >> The element you describe could consult the elements to determine which users/groups need to be created, pull the values it needs from the passwd/group files if they exist, or fall back on the offered static defaults if not, then use normal tools to create the user/group (mainly so we respect whatever libnss settings the operator has chosen).\n> >> \n> > \n> > That is a lot of complexity for the case that we don\'t want people to\n> > use (constantly carrying /etc/passwd and /etc/group forward).\n> \n> As tchaypo pointed out on IRC, if we do this static route, we are laying down a great big concrete slab of opinion in our images. I\'m all for opinionated software, but we need to give people an out, which means we probably want to have a way for the suggested default UID/GIDs to be overridden, i.e. roughly what I described. We can just use that override to inject the pre-existing passwd/group values, if we so desire.\n> \n\nMmk. I think having an override is important, but I feel that we can do it\nin a more straight forward manner. I may not have thought it all the way\nthrough.\n\n\n','<7C038FA7-E17D-402C-83C0-A12D70D699AE@tenshu.net>',NULL),('<1412847702.8141.99.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-10-09 10:41:42',3600,'2014-10-09 09:41:42',NULL,'[openstack-tc] Not running in the TC election','Hey\n\nI\'ve decided not to run in the TC election. I\'ve switched my focus at\nRed Hat recently and I know I\'m going to have little or no time to\ncontribute upstream, at least for the next while.\n\nEven if I could get elected to the TC again, I wouldn\'t feel comfortable\nhaving a vote in some of the big decisions we have to make over the next\n6 months if I\'m not also contributing significantly.\n\nThierry and I were talking about my situation a few weeks ago and he\nsaid something like \"sounds like you\'re cashing out?\"[1]. Ouch, huh? :)\nAfter talking about it some more, he decided it sounded more like \"duty\ncalls\". That\'s a good way of looking at it.\n\nI\'m going to continue to be completely focused on helping make OpenStack\nsuccessful through my work at Red Hat. That work will be largely\ninvisible to the community, and its significance will pale in comparison\nto the work going on in the project itself.\n\nAnyway, I\'ll be following y\'all closely. Bon courage! :)\n\nSee you in Paris,\n\nMark.\n\n[1] - to be clear, I\'m just teasing Thierry here - his comment was\nactually much more insightful and helpful than it sounds out of\ncontext :)\n\n\n\n',NULL,NULL),('<1412856209.21517.YahooMailBasic@web160901.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-09 05:03:29',-25200,'2014-10-09 12:03:29',NULL,'[Openstack] Add physical interface','Hello,\n\nIs it possible to add a physcial interface to an instance?\nI am using Icehouse with 3 node setup with controller, neutron and nova.\n\nThanks\nRV\n\n\n',NULL,NULL),('<1412886281-sup-2284@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-09 20:32:26',0,'2014-10-09 20:32:26',NULL,'[openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning','Hello TripleO-ers,\n\nLast time around there was a lot of feedback that we should plan our\nmid-cycle metup a lot sooner, so lets do that! I\'ve created a (mostly\nbare) etherpad here:\n\nhttps://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n\nNote that there are currently no possible venues listed. If you are able\nto provide a possible venue (Thank you!) please reply and/or add it to\nthe etherpad.\n\nI have also listed a few possible Mon-Fri meetup dates. Do not take this\nas any indication that Mon-Fri is an ideal meetup length or time of\nweek, and feel free to add feedback / combinations of your own.\nPersonally, I felt pretty burned out by Friday last time so maybe\nMon-Wed is a better size?\n\nCheers,\nGreg\n\n\n',NULL,NULL),('<1413031485046.72067@persistent.co.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-11 12:38:10',0,'2014-10-11 12:38:10',NULL,'[Openstack] [icehouse][HA]','Hi Chinasubbareddy,\n\n\nAs far as I know the below installers can deploy a HA env:\n\n1. Cisco openstack Installer : http://docwiki.cisco.com/wiki/OpenStack:_Icehouse_Installer\n\n2. Fuel: https://wiki.openstack.org/wiki/Fuel\n\n\n-HTH\n\nSushma\n\n________________________________\nFrom: Chinasubbareddy M <chinasubbareddy_m at persistent.co.in>\nSent: Saturday, October 11, 2014 4:35 PM\nTo: openstack at lists.openstack.org\nSubject: [Openstack] [icehouse][HA]\n\nHi,\n\nI have a requirement to install openstack icehouse HA setup with 10 nodes running Ubuntu 14.04 operating system.\nPlease suggest a suitable deployment tool for the above requirement. Any documents or url\'s would be helpful.\n\n\nRegards,\nSubbareddy,\nPersistent systems ltd.\n\nDISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141011/3e861d6d/attachment.html>\n\n','<068f331b9aac4bcb8356f35fb8db3442@HKXPR04MB183.apcprd04.prod.outlook.com>',NULL),('<1413160615534.df5265af@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-12 17:36:56',-25200,'2014-10-13 00:36:56',NULL,'[openstack-dev] [neutron] Can Neutron VPNaaS work with\n strongswan? (Openswan removed from Debian)','There is a blueprint for supporting StrongSwan in Kilo release:\n\n\nhttps://review.openstack.org/#/c/101457/\n\n\n\n\nXu Han\n?\nXu Han Peng (xuhanp)\n\nOn Sun, Oct 12, 2014 at 12:26 PM, Thomas Goirand <zigo at debian.org> wrote:\n\n> Hi,\n> As you may know, OpenSwan has been largely unmaintained in Debian, and\n> then was removed from Testing, and then Sid last summer. OpenSwan had\n> some unaddressed security issues, and removing it from Debian was IMO\n> the correct thing to do. Ubuntu followed, and Utopic doesn\'t have\n> OpenSwan anymore either.\n> Though there\'s StrongSwan, which is apparently an alternative. But can\n> Neutron work with it? If not, how much work would it be to make Neutron\n> use StrongSwan instead of OpenSwan, and could the maintainers of the\n> VPNaaS people do this be worked on for Kilo? BTW, why not using\n> something as popular as OpenVPN, which has more chances to be well\n> maintained?\n> Cheers,\n> Thomas Goirand (zigo)\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141012/146808a9/attachment.html>\n\n','<543A027D.2060204@debian.org>',NULL),('<1413264398.61238.YahooMailNeo@web160301.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-13 22:26:38',-25200,'2014-10-14 05:26:38',NULL,'[OpenStack-docs] Review Identity Service diagram','Hi everyone,\n\nI\'ve drafted a simplified Identity Service process flow diagram:\nBug #1362460 ?There aint any arrow to show direction of message ...? : Bugs : openstack-manuals\n\n  \n             \nBug #1362460 ?There aint any arrow to show direction of ...\nIn the diagram describing flows of messages between different entities involved in Keystone services, there is no directional information given to interpret the sen...  \nView on bugs.launchp... Preview by Yahoo  \n  \nI\'d appreciate any input and feedback so I can complete the diagram and upload it as a patch.\n\nThanks,\n\nRegards,\nDarren\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141013/a27a70cb/attachment-0001.html>\n\n',NULL,NULL),('<1413268514.4301.4.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 08:35:14',7200,'2014-10-14 06:35:14',NULL,'[Openstack] [openstacl][neutron][ml2][vlan]','Hi, \n\nPlease check if the agent is available via \n#neutron agent-list\n\n\n\nThis is my working vlan configuration:\n\nCompute Node ml2.conf:\n\n[ml2]\ntype_drivers = local,flat,vlan,gre,vxlan\nmechanism_drivers = openvswitch,linuxbridge\n[ml2_type_vlan]\nnetwork_vlan_ranges = phys-data:1000:1005\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n[ovs]\nlocal_ip = 9.152.150.191\nbridge_mappings = phys-data:br-data\ntenant_network_types = vlan\n\n[agent]\nroot_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n    (--> not sure if the root helper also fits for you. I had to adapt\nthe default config as on my system it was located in another\ndirectory...)\n\n\n\ncombined Network/Controller Node ml2 cof:\n\n[ml2]\ntenant_network_types = vlan\ntype_drivers = vlan,flat\nmechanism_drivers = openvswitch\n[ml2_type_vlan]\nnetwork_vlan_ranges = phys-data:1000:1005\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\n\n[database]\nconnection = mysql://root:mysql-root-pw at 127.0.0.1/neutron_ml2?charset\n\n[ovs]\ntenant_network_types = vlan\nbridge_mappings = phys-data:br-data,phys-ex:br-ext\nlocal_ip = 1.2.3.4\n\n[agent]\nroot_helper =\nsudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Sat, 2014-10-11 at 20:03 +0200, S?awek Kap?o?ski wrote:\n> Hello,\n> \n> Check in neutron-server logs why port is not bind correctly on host.\n> \n> ---\n> Best regards\n> S?awek Kap?o?ski\n> slawek at kaplonski.pl\n> \n> Dnia sobota, 11 pa?dziernika 2014 04:37:50 Chinasubbareddy M pisze:\n> > Hi ,\n> > \n> > When I am configuring ML2 plugin with vlan based network ,  nova boot is\n> > failing with following error ,where as if I change the driver from ML2 to\n> > OVS  , things are working fine . Please suggest.\n> > \n> > \n> > Here is the ml2 configuration:\n> > \n> > [ml2]\n> > type_drivers = vlan\n> > tenant_network_types = vlan\n> > mechanism drivers = openvswitch\n> > [ml2_type_vlan]\n> > network_vlan_ranges = physnet1:1:4094\n> > [ovs]\n> > tenant_network_type = vlan\n> > network_vlan_ranges = physnet1:1:4094\n> > bridge_mappings = physnet1:br-eth1\n> > [securitygroup]\n> > firewall_driver =\n> > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> > enable_security_group = True\n> > \n> > /etc/neutron/neutron.conf:\n> > core_plugin = ml2\n> > service_plugins = router\n> > allow_overlapping_ips = True\n> > \n> > \n> > logs:\n> > \n> > \n> > root at build-server:/etc/init# grep -ir \"241e4c21-5604-4a1b-a782-f44128fbd0b3\"\n> > /var/log/nova/* /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053\n> > 21941 ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821\n> > 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0]\n> > [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Instance failed to spawn\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> > Traceback (most recent call last):\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720,\n> > in _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> > TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> >     block_device_info) /var/log/nova/nova-compute.log:2014-09-11\n> > 02:41:23.053 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250,\n> > in spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> > write_to_disk=True) /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431,\n> > in to_xml /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> > TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> >     disk_info, rescue, block_device_info)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n> > 3247, in get_guest_config /var/log/nova/nova-compute.log:2014-09-11\n> > 02:41:23.053 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384,\n> > in get_config /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> > TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> >     _(\"Unexpected vif_type=%s\") % vif_type)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> > NovaException: Unexpected vif_type=binding_failed\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:23.877 21941 ERROR\n> > nova.virt.libvirt.driver [-] [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance\n> > disappeared. /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> > ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821\n> > 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0]\n> > [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Error: Unexpected\n> > vif_type=binding_failed /var/log/nova/nova-compute.log:2014-09-11\n> > 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3] Traceback (most recent call last):\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1311,\n> > in _build_instance /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]     set_access_ip=set_access_ip)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 399,\n> > in decorated_function /var/log/nova/nova-compute.log:2014-09-11\n> > 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]     return function(self, context,\n> > *args, **kwargs) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1723, in\n> > _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> > LOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py\",\n> > line 68, in __exit__ /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]     six.reraise(self.type_,\n> > self.value, self.tb) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720, in\n> > _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> > block_device_info) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250,\n> > in spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> > write_to_disk=True) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> > 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> > \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431,\n> > in to_xml /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> > TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> >     disk_info, rescue, block_device_info)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n> > 3247, in get_guest_config /var/log/nova/nova-compute.log:2014-09-11\n> > 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> > File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384,\n> > in get_config /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> > TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> >     _(\"Unexpected vif_type=%s\") % vif_type)\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> > NovaException: Unexpected vif_type=binding_failed\n> > /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> > nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> > /var/log/nova/nova-compute.log:2014-09-11 02:50:44.135 23339 ERROR\n> > nova.virt.libvirt.driver [-] [instance:\n> > 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance\n> > disappeared.\n> > \n> > \n> > Regards,\n> > Subbareddy\n> > Persistent systems ltd.\n> > \n> > \n> > DISCLAIMER\n> > ==========\n> > This e-mail may contain privileged and confidential information which is the\n> > property of Persistent Systems Ltd. It is intended only for the use of the\n> > individual or entity to which it is addressed. If you are not the intended\n> > recipient, you are not authorized to read, retain, copy, print, distribute\n> > or use this message. If you have received this communication in error,\n> > please notify the sender and delete all copies of this message. Persistent\n> > Systems Ltd. does not accept any liability for virus infected mails.\n> _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<1630532.Nxo50OVooN@laptop>',NULL),('<1413295928305.9dc55ad1@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 07:12:08',-25200,'2014-10-14 14:12:08',NULL,'[Openstack] Messaging reliability/durability expectations','?\nRaghu\n\n\nOn Tuesday, Oct 14, 2014 at 7:49 AM, Aaron Knister <aaron.knister at gmail.com>, wrote:\n\nThanks Remo, could you elaborate a little? Which is part of RabbitMQ? The HA layer or the message retransmission? I\'m currently using qpid. Also, just so I\'m clear, is it the openstack code or the low-level messaging drivers (rabbit, zmq, qpid) that retransmit on message delivery failure?\n\n\n\n\nThanks!\n\n\n\n\n?That should be the job messaging infrastructure provided by rabbit or qpid?\n\nRaghu\n\n\n\nSent from my iPhone\n\n\n\nOn Oct 13, 2014, at 11:59 PM, Remo Mattei <remo at italy1.com> wrote:\n\n\n\nThat is part of RabbitMQ and yes it will resend the msg.?\n\n\nRemo?\n\nOn Oct 13, 2014, at 22:31, Aaron Knister <aaron.knister at gmail.com> wrote:\n\n\n\n\nHi Everyone,\n\n\n\n\nI\'m building a production-grade cloud where HA is a requirement. I\'m currently working on implementing HA of the messaging layer and am not clear on what the expectations/assumptions are of the messaging layer regarding message durability and reliability. I\'ve seen documentation scattered about that suggests OpenStack makes no assumptions that messages will be delivered or will need to persist for any period of time (https://openstack.redhat.com/Highly_Available_Qpid_for_OpenStack).\n\n\n\n\nWhat\'s the consequence of RPC message loss within openstack? Is it true that it will resend messages?\n\n\n\n\nThanks!\n\n\n\n\n-Aaron\n\n!DSPAM:1,543c9c2325772110695322!\n\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to ????: openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n!DSPAM:1,543c9c2325772110695322!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141014/b8036c26/attachment.html>\n\n','<ED484056-1013-427B-880E-189E61084105@gmail.com>',NULL),('<1413305991.11814.YahooMailNeo@web121201.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 09:59:51',-25200,'2014-10-14 16:59:51',NULL,'[Openstack] Name Resolution problem (ICEHOUSE)','Hi all,\n\nSo I have a DNS (or at least it seems to be only DNS) problem with the VM\'s I have created. I cannot resolve anything from within the VM\'s. I can ping outside by IP (ie, I can ping google,etc but only by IP) but cannot do a dig, curl, nslookup, etc by name. I have no clue why this is happening and Ive tried some of the solutions other have recommended at Ask Openstack but to no avail. I was hoping someone here maybe able to point me in the right direction. I have also posted the question at Ask, all the node stack details are here:\n\nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers\n\n  \n          \nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers\nHi all, So I cant seem to access the internet from my VMs. I can access the floating IPs from anywhere in our network and from all nodes now (controller/network/compute) just fine (but strangely I cannot access the private ips, the tenant network from any of the nodes?!) but cant ...  \nView on ask.openstack.org Preview by Yahoo  \n  \n\n\nThanks in advance for any help!\n\nAmit\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141014/94956ce6/attachment.html>\n\n',NULL,NULL),('<1413308070-sup-617@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 17:37:43',0,'2014-10-14 17:37:43',NULL,'[openstack-dev] [TripleO] Strategy for testing and merging the\n	merge.py-free templates','Excerpts from Tomas Sedovic\'s message of 2014-10-14 08:55:30 +0000:\n> James Slagle proposed something like this when I talked to him on IRC:\n> \n> 1. teach devtest about the new templates, driven by a \n> OVERCLOUD_USE_MERGE_PY switch (defaulting to the merge.py-based templates)\n> 2. Do a CI run of the new template patches, merge them\n> 3. Add a (initially non-voting?) job to test the heat-only templates\n> 4. When we\'ve resolved all the issues stopping up from the switch, make \n> the native templates default, deprecate the merge.py ones\n\nThis sounds good to me. I would support even making it voting from the\nstart if it is on-par with pass rates of our other jobs (which seems\nlike it should be). The main question here is whether we have the\ncapacity for this (derekh?) as I know we tend to run close to our\ncapacity limit worth of jobs.\n\nCheers,\nGreg\n\n\n','<543CE502.4010106@redhat.com>',NULL),('<1413315633.33373.YahooMailNeo@web121204.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 12:40:33',-25200,'2014-10-14 19:40:33',NULL,'[Openstack] Name Resolution problem (ICEHOUSE)','Hi James,\n\nThanks for the response! Yeah Ive tried that no luck. My resolv.conf on a VM  (192.168.1.5) is as follows:\n\nnameserver 192.168.1.3 \nnameserver 10.7.0.1\nsearch openstacklocal\n\nThe first is the  demo-subnet dhcp address.\nThe second is the outside network gateway/dns address.\n\nNeither work. Whenever I try anything this what I get:\n\n dig domain.com @8.8.8.8\n\n; <<>> DiG 9.9.5-3-Ubuntu <<>> domain.com @8.8.8.8\n;; global options: +cmd\n;; connection timed out; no servers could be reached\n\n\nWeirdly, when I try to do an nslookup from the VM and then tcpdump on port 53, on the network node qrouter namespace I see no requests, but I do see requests on the compute node:\n\n15:37:36.150955 IP (tos 0x0, ttl 64, id 64629, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n15:37:41.151060 IP (tos 0x0, ttl 64, id 64630, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n15:37:46.151166 IP (tos 0x0, ttl 64, id 64631, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n\n\nAlso I can do an nslookup from the namespace itself and works no problem:\n\n\nip netns exec qrouter-d9b5f02b-48c5-44a1-bc4b-7ba0336ee201 nslookup www.google.com\nServer:         10.7.0.1\nAddress:        10.7.0.1#53\n\nNon-authoritative answer:\nName:   www.google.com\nAddress: 74.125.225.148\nName:   www.google.com\nAddress: 74.125.225.146\n...etc....\n\n\n\n\n\n\nOn Tuesday, October 14, 2014 3:05 PM, James Denton <james.denton at rackspace.com> wrote:\n \n\n\nHi Amit,\n\nHave you tried specifying a name server with dig? Ie. dig domain.com @8.8.8.8 <?google DNS\n\nHave you confirmed your instances have a resolver configured in /etc/resolv.conf? This usually occurs via DHCP.\n\nJames\n\nFrom: Amit Anand <mr_amitanand at yahoo.com>\nReply-To: Amit Anand <mr_amitanand at yahoo.com>\nDate: Tuesday, October 14, 2014 at 11:59 AM\nTo: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: [Openstack] Name Resolution problem (ICEHOUSE)\n\n\nHi all,\n\nSo I have a DNS (or at least it seems to be only DNS) problem with the VM\'s I have created. I cannot resolve anything from within the VM\'s. I can ping outside by IP (ie, I can ping google,etc but only by IP) but cannot do a dig, curl, nslookup, etc by name. I have no clue why this is happening and Ive tried some of the solutions other have recommended at Ask Openstack but to no avail. I was hoping someone here maybe able to point me in the right direction. I have also posted the question at Ask, all the node stack details are here:\n\nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers\n\n  \n          \nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers \nHi all, So I cant seem to access the internet from my VMs. I can access the floating IPs from anywhere in our network and from all nodes now (controller/network/compute) just fine (but strangely I cannot access the private ips, the tenant network from any of the nodes?!) but cant ...  \nView on ask.openstack.org Preview by Yahoo  \n  \n\n\nThanks in advance for any help!\n\nAmit\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141014/562a5fb9/attachment.html>\n\n','<D062DE0A.A55C5%james.denton@rackspace.com>',NULL),('<1413315753.60519.YahooMailNeo@web121201.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-14 12:42:33',-25200,'2014-10-14 19:42:33',NULL,'[Openstack] Name Resolution problem (ICEHOUSE)','Also forgot to specify my VM external address is 10.7.7.105. The external network CIDR is 10.7.0.0/16 gateway is 10.7.0.1.\n\n\n\n\n\nOn Tuesday, October 14, 2014 3:40 PM, Amit Anand <mr_amitanand at yahoo.com> wrote:\n \n\n\nHi James,\n\nThanks for the response! Yeah Ive tried that no luck. My resolv.conf on a VM  (192.168.1.5) is as follows:\n\nnameserver 192.168.1.3 \nnameserver 10.7.0.1\nsearch openstacklocal\n\nThe first is the  demo-subnet dhcp address.\nThe second is the outside network gateway/dns address.\n\nNeither work. Whenever I try anything this what I get:\n\n dig domain.com @8.8.8.8\n\n; <<>> DiG 9.9.5-3-Ubuntu <<>> domain.com @8.8.8.8\n;; global options: +cmd\n;; connection timed out; no servers could be reached\n\n\nWeirdly, when I try to do an nslookup from the VM and then tcpdump on port 53, on the network node qrouter namespace I see no requests, but I do see requests on the compute node:\n\n15:37:36.150955 IP (tos 0x0, ttl 64, id 64629, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n15:37:41.151060 IP (tos 0x0, ttl 64, id 64630, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n15:37:46.151166 IP (tos 0x0, ttl 64, id 64631, offset 0, flags [none], proto UDP (17), length 67)\n    192.168.1.5.35247 > 8.8.8.8.domain: 28059+ [1au] A? domain.com. (39)\n\n\nAlso I can do an nslookup from the namespace itself and works no problem:\n\n\nip netns exec qrouter-d9b5f02b-48c5-44a1-bc4b-7ba0336ee201 nslookup www.google.com\nServer:         10.7.0.1\nAddress:        10.7.0.1#53\n\nNon-authoritative answer:\nName:   www.google.com\nAddress: 74.125.225.148\nName:   www.google.com\nAddress: 74.125.225.146\n...etc....\n\n\n\n\n\n\nOn Tuesday, October 14, 2014 3:05 PM, James Denton <james.denton at rackspace.com> wrote:\n \n\n\nHi Amit,\n\nHave you tried specifying a name server with dig? Ie. dig domain.com @8.8.8.8 <?google DNS\n\nHave you confirmed your instances have a resolver configured in /etc/resolv.conf? This usually occurs via DHCP.\n\nJames\n\nFrom: Amit Anand <mr_amitanand at yahoo.com>\nReply-To: Amit Anand <mr_amitanand at yahoo.com>\nDate: Tuesday, October 14, 2014 at 11:59 AM\nTo: \"openstack at lists.openstack.org\" <openstack at lists.openstack.org>\nSubject: [Openstack] Name Resolution problem (ICEHOUSE)\n\n\nHi all,\n\nSo I have a DNS (or at least it seems to be only DNS) problem with the VM\'s I have created. I cannot resolve anything from within the VM\'s. I can ping outside by IP (ie, I can ping google,etc but only by IP) but cannot do a dig, curl, nslookup, etc by name. I have no clue why this is happening and Ive tried some of the solutions other have recommended at Ask Openstack but to no avail. I was hoping someone here maybe able to point me in the right direction. I have also posted the question at Ask, all the node stack details are here:\n\nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers\n\n  \n          \nNo internet access from VM - Ask OpenStack: Q&A Site for OpenStack Users and Developers \nHi all, So I cant seem to access the internet from my VMs. I can access the floating IPs from anywhere in our network and from all nodes now (controller/network/compute) just fine (but strangely I cannot access the private ips, the tenant network from any of the nodes?!) but cant ...  \nView on ask.openstack.org Preview by Yahoo  \n  \n\n\nThanks in advance for any help!\n\nAmit\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141014/3d4453b7/attachment.html>\n\n','<1413315633.33373.YahooMailNeo@web121204.mail.ne1.yahoo.com>',NULL),('<1413317057-sup-9656@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 13:12:50',-25200,'2014-10-14 20:12:50',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','Excerpts from Lars Kellogg-Stedman\'s message of 2014-10-14 12:50:48 -0700:\n> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:\n> > I think the above strategy is spot on. Unfortunately, that\'s not how the\n> > Docker ecosystem works.\n> \n> I\'m not sure I agree here, but again nobody is forcing you to use this\n> tool.\n> \n> > operating system that the image is built for. I see you didn\'t respond to my\n> > point that in your openstack-containers environment, you end up with Debian\n> > *and* Fedora images, since you use the \"official\" MySQL dockerhub image. And\n> > therefore you will end up needing to know sysadmin specifics (such as how\n> > network interfaces are set up) on multiple operating system distributions.\n> \n> I missed that part, but ideally you don\'t *care* about the\n> distribution in use.  All you care about is the application.  Your\n> container environment (docker itself, or maybe a higher level\n> abstraction) sets up networking for you, and away you go.\n> \n> If you have to perform system administration tasks inside your\n> containers, my general feeling is that something is wrong.\n> \n\nSpeaking as a curmudgeon ops guy from \"back in the day\".. the reason\nI choose the OS I do is precisely because it helps me _when something\nis wrong_. And the best way an OS can help me is to provide excellent\ndebugging tools, and otherwise move out of the way.\n\nWhen something _is_ wrong and I want to attach GDB to mysqld in said\ncontainer, I could build a new container with debugging tools installed,\nbut that may lose the very system state that I\'m debugging. So I need to\nrun things inside the container like apt-get or yum to install GDB.. and\nat some point you start to realize that having a whole OS is actually a\ngood thing even if it means needing to think about a few more things up\nfront, such as \"which OS will I use?\" and \"what tools do I need installed\nin my containers?\"\n\nWhat I mean to say is, just grabbing off the shelf has unstated\nconsequences.\n\n> > Sure, Docker isn\'t any more limiting than using a VM or bare hardware, but\n> > if you use the \"official\" Docker images, it is more limiting, no?\n> \n> No more so than grabbing a virtual appliance rather than building a\n> system yourself.  \n> \n> In other words: sure, it\'s less flexible, but possibly it\'s faster to\n> get started, which is especially useful if your primary goal is not\n> \"be a database administrator\" but is actually \"write an application\n> that uses a database backend\".\n> \n> I think there are uses cases for both \"official\" and customized\n> images.\n> \n\nIn the case of Kolla, we\'re deploying OpenStack, not just some new\napplication that uses a database backend. I think the bar is a bit\nhigher for operations than end-user applications, since it sits below\nthe abstractions, much closer to the metal.\n\n\n','<20141014195048.GG13176@redhat.com>',NULL),('<1413322150-sup-3223@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 14:38:46',-25200,'2014-10-14 21:38:46',NULL,'[openstack-dev] [Heat] image requirements for Heat software\n	config','Excerpts from Thomas Spatzier\'s message of 2014-10-14 10:13:27 -0700:\n> \n> Hi all,\n> \n> I have been experimenting a lot with Heat software config to  check out\n> what works today, and to think about potential next steps.\n> I\'ve also worked on an internal project where we are leveraging software\n> config as of the Icehouse release.\n> \n> I think what we can do now from a user\'s perspective in a HOT template is\n> really nice and resonates well also with customers I\'ve talked to.\n> One of the points where we are constantly having issues, and also got some\n> push back from customers, are the requirements on the in-instance tools and\n> the process of building base images.\n> One observation is that building a base image with all the right stuff\n> inside sometimes is a brittle process; the other point is that a lot of\n> customers do not like a lot of requirements on their base images. They want\n> to maintain one set of corporate base images, with as little modification\n> on top as possible.\n> \n> Regarding the process of building base images, the currently documented way\n> [1] of using diskimage-builder turns out to be a bit unstable sometimes.\n> Not because diskimage-builder is unstable, but probably because it pulls in\n> components from a couple of sources:\n> #1 we have a dependency on implementation of the Heat engine of course (So\n> this is not pulled in to the image building process, but the dependency is\n> there)\n> #2 we depend on features in python-heatclient (and other python-* clients)\n> #3 we pull in implementation from the heat-templates repo\n> #4 we depend on tripleo-image-elements\n> #5 we depend on os-collect-config, os-refresh-config and os-apply-config\n> #6 we depend on diskimage-builder itself\n> \n> Heat itself and python-heatclient are reasonably well in synch because\n> there is a release process for both, so we can tell users with some\n> certainty that a feature will work with release X of OpenStack and Heat and\n> version x.z.y of python-heatclient. For the other 4 sources, success\n> sometimes depends on the time of day when you try to build an image\n> (depending on what changes are currently included in each repo). So\n> basically there does not seem to be a consolidated release process across\n> all that is currently needed for software config.\n> \n\nI don\'t really understand why a \"consolidated release process across\nall\" would be desired or needed.\n\n#3 is pretty odd. You\'re pulling in templates from the examples repo?\n\nFor #4-#6, those are all on pypi and released on a regular basis. Build\nyourself a bandersnatch mirror and you\'ll have locally controlled access\nto them which should eliminate any reliability issues.\n\n> The ideal solution would be to have one self-contained package that is easy\n> to install on various distributions (an rpm, deb, MSI ...).\n> Secondly, it would be ideal to not have to bake additional things into the\n> image but doing bootstrapping during instance creation based on an existing\n> cloud-init enabled image. For that we would have to strip requirements down\n> to a bare minimum required for software config. One thing that comes to my\n> mind is the cirros software config example [2] that Steven Hardy created.\n> It is admittedly no up to what one could do with an image built according\n> to [1] but on the other hand is really slick, whereas [1] installs a whole\n> set of things into the image (some of which do not really seem to be needed\n> for software config).\n\nThe agent problem is one reason I\'ve been drifting away from Heat\nfor software configuration, and toward Ansible. Mind you, I wrote\nos-collect-config to have as few dependencies as possible as one attempt\naround this problem. Still it isn\'t capable enough to do the job on its\nown, so you end up needing os-apply-config and then os-refresh-config\nto tie the two together.\n\nAnsible requires sshd, and python, with a strong recommendation for\nsudo. These are all things that pretty much every Linux distribution is\ngoing to have available.\n\n> \n> Another issue that comes to mind: what about operating systems not\n> supported by diskimage-builder (Windows), or other hypervisor platforms?\n> \n\nThere is a windows-diskimage-builder:\n\nhttps://git.openstack.org/cgit/stackforge/windows-diskimage-builder\n\ndiskimage-builder can produce raw images, so that should be convertible\nto pretty much any other hypervisor\'s preferred disk format.\n\n\n','<OF3B88B433.E9585BEF-ONC1257D70.00441CE8-C1257D71.005E9D84@de.ibm.com>',NULL),('<1413334507-sup-5687@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 18:10:37',-25200,'2014-10-15 01:10:37',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','Excerpts from Fox, Kevin M\'s message of 2014-10-14 17:40:16 -0700:\n> I\'m not arguing that everything should be managed by one systemd, I\'m\n> just saying, for certain types of containers, a single docker container\n> with systemd in it might be preferable to trying to slice it unnaturally\n> into several containers.\n> \n\nCan you be more concrete? Most of the time things that need to be in\nthe same machine tend to have some kind of controller already. Meanwhile\nit is worth noting that you can have one _image_, but several containers\nrunning from that one image. So if you\'re trying to run a few pieces of\nNeutron, for instance, you can have multiple containers each from that\none neutron image.\n\n> Systemd has invested a lot of time/effort to be able to relaunch failed\n> services, support spawning and maintaining unix sockets and services\n> across them, etc, that you\'d have to push out of and across docker\n> containers. All of that can be done, but why reinvent the wheel? Like you\n> said, pacemaker can be made to make it all work, but I have yet to see\n> a way to deploy pacemaker services anywhere near as easy as systemd+yum\n> makes it. (Thanks be to redhat. :)\n> \n\nThere are some of us who are rather annoyed that systemd tries to do\nthis in such a naive way and assumes everyone will want that kind of\nmanagement. It\'s the same naivet? that leads people to think if they\nmake their app server systemd service depend on their mysql systemd\nservice that this will eliminate startup problems. Once you have more\nthan one server, it doesn\'t work.\n\nKubernetes adds a distributed awareness of the containers that makes it\nuniquely positioned to do most of those jobs much better than systemd\ncan.\n\n> The answer seems to be, its not \"dockerish\". Thats ok. I just wanted to\n> understand the issue for what it is. If there is a really good reason for\n> not wanting to do it, or that its just \"not the way things are done\". I\'ve\n> had kind of the opposite feeling regarding docker containers. Docker use\n> to do very bad things when killing the container. nasty if you wanted\n> your database not to go corrupt. killing pid 1 is a bit sketchy then\n> forcing the container down after 10 seconds was particularly bad. having\n> something like systemd in place allows the database to be notified, then\n> shutdown properly. Sure you can script up enough shell to make this work,\n> but you have to do some difficult code, over and over again... Docker\n> has gotten better more recently but it still makes me a bit nervous\n> using it for statefull things.\n> \n\nWhat I think David was saying was that the process you want to run under\nsystemd is the pid 1 of the container. So if killing that would be bad,\nit would also be bad to stop the systemd service, which would do the\nsame thing: send it SIGTERM. If that causes all hell to break loose, the\nstateful thing isn\'t worth a dime, because it isn\'t crash safe.\n\n> As for recovery, systemd can do the recovery too. I\'d argue at this\n> point in time, I\'d expect systemd recovery to probably work better\n> then some custom shell scripts when it comes to doing the right thing\n> recovering at bring up. The other thing is, recovery is not just about\n> pid1 going away. often it sticks around and other badness is going\n> on. Its A way to know things are bad, but you can\'t necessarily rely on\n> it to know the container\'s healty. You need more robust checks for that.\n\nI think one thing people like about Kubernetes is that when a container\ncrashes, and needs to be brought back up, it may actually be brought\nup on a different, less busy, more healthy host. I could be wrong, or\nthat might be in the \"FUTURE\" section. But the point is, recovery and\nstart-up are not things that always want to happen on the same box.\n\n\n','<1A3C52DFCD06494D8528644858247BF088C31B@EX10MBOX03.pnnl.gov>',NULL),('<1413337977.21196108.1370762780200.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-09 03:26:20',-14400,'2013-06-09 07:26:20',NULL,'[openstack-qa] Is tempest must be able to operate without\n identity admin privileges?','Looks like everybody is able to change the quota at the same time, when he creates the test user.\n\nIt implies the question:\n Why do we create new tenants in test case,\n  which must be able to run in parallel with a single tenant ?\n\n Why we not just create tenants only when it is really needed ?\n\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: openstack-qa at lists.openstack.org\n> Sent: Sunday, June 9, 2013 12:17:29 AM\n> Subject: Re: [openstack-qa] Is tempest must be able to operate without identity admin privileges?\n> \n> On 06/08/2013 02:05 PM, Daryl Walleck wrote:\n> > There\'s other ways to work around the quotas issue. The way I\'ve been\n> > handling this is configuring users that have modified quota groups. This\n> > has allowed me to run all my compute tests in parallel with a single user.\n> \n> Note that the above solution runs into the exact same issue that Attila\n> is talking about: you need admin privileges in order to change the quota\n> of a tenant.\n> \n> Best,\n> -jay\n> \n> > Daryl\n> >\n> > -----Original Message-----\n> > From: Attila Fazekas [mailto:afazekas at redhat.com]\n> > Sent: Saturday, June 8, 2013 8:04 AM\n> > To: Sean Dague\n> > Cc: All Things QA.\n> > Subject: Re: [openstack-qa] Is tempest must be able to operate without\n> > identity admin privileges?\n> >\n> > Do we want parallel execution in this cases ?\n> > - obviously yes\n> > - nice to have\n> > - who cares\n> >\n> > Can we expect larger quota than the default 10 in this case ?\n> > - never\n> > - usually\n> > - always\n> >\n> >\n> > ----- Original Message -----\n> >> From: \"Sean Dague\" <sean at dague.net>\n> >> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> >> Cc: \"Attila Fazekas\" <afazekas at redhat.com>\n> >> Sent: Saturday, June 8, 2013 1:49:40 PM\n> >> Subject: Re: [openstack-qa] Is tempest must be able to operate without\n> >> identity admin privileges?\n> >>\n> >> On 06/08/2013 03:06 AM, Attila Fazekas wrote:\n> >>> Hi All,\n> >>>\n> >>> In modeling viewpoint keeping the ability to run tempest without\n> >>> identity admin credentials is not easy.\n> >>>\n> >>> The demo and alt_demo user is still in the config to maintain the\n> >>> ability, to run tempest against a cloud where you do not know the\n> >>> identity admin credentials.\n> >>>\n> >>> I would like to know, is it real use case for anyone ?\n> >>>\n> >>> Without these users you lose the ability to run tempest against any\n> >>> cloud where you do not know the admin credentials.\n> >>>\n> >>> The benefits of removing these can give you:\n> >>>    - simpler model\n> >>>    - better role based test suite\n> >>\n> >> Yes, it is a real use case, we can\'t remove that.\n> >>\n> >> 	-Sean\n> >>\n> >> --\n> >> Sean Dague\n> >> http://dague.net\n> >>\n> >\n> > _______________________________________________\n> > openstack-qa mailing list\n> > openstack-qa at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >\n> > _______________________________________________\n> > openstack-qa mailing list\n> > openstack-qa at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >\n> \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B3AD79.6080300@gmail.com>',NULL),('<1413359015.2068.16.camel@jarvis>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 09:43:35',7200,'2014-10-15 07:43:35',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','On Tue, 2014-10-14 at 19:52 -0400, David Vossel wrote:\n> \n> ----- Original Message -----\n> > Ok, why are you so down on running systemd in a container?\n> \n> It goes against the grain.\n> \n> From a distributed systems view, we gain quite a bit of control by maintaining\n> \"one service per container\". Containers can be re-organised and re-purposed dynamically.\n> If we have systemd trying to manage an entire stack of resources within a container,\n> we lose this control.\n> \n> From my perspective a containerized application stack needs to be managed externally\n> by whatever is orchestrating the containers to begin with. When we take a step back\n> and look at how we actually want to deploy containers, systemd doesn\'t make much sense.\n> It actually limits us in the long run.\n> \n> Also... recovery. Using systemd to manage a stack of resources within a single container\n> makes it difficult for whatever is externally enforcing the availability of that container\n> to detect the health of the container.  As it is now, the actual service is pid 1 of a\n> container. If that service dies, the container dies. If systemd is pid 1, there can\n> be all kinds of chaos occurring within the container, but the external distributed\n> orchestration system won\'t have a clue (unless it invokes some custom health monitoring\n> tools within the container itself, which will likely be the case someday.)\n\nI don\'t really think this is a good argument.  If you\'re using docker,\ndocker is the management and orchestration system for the containers.\nThere\'s no dogmatic answer to the question should you run init in the\ncontainer.\n\nThe reason for not running init inside a container managed by docker is\nthat you want the template to be thin for ease of orchestration and\ntransfer, so you want to share as much as possible with the host.  The\nmore junk you put into the container, the fatter and less agile it\nbecomes, so you should probably share the init system with the host in\nthis paradigm.\n\nConversely, containers can be used to virtualize full operating systems.\nThis isn\'t the standard way of doing docker, but LXC and OpenVZ by\ndefault do containers this way.  For this type of container, because you\nhave a full OS running inside the container, you have to also have\nsystemd (assuming it\'s the init system) running within the container.\n\nJames\n\n\n\n\n','<152430654.41668597.1413330723017.JavaMail.zimbra@redhat.com>',NULL),('<1413387236-sup-3801@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 09:51:03',-25200,'2014-10-15 16:51:03',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','Excerpts from Vishvananda Ishaya\'s message of 2014-10-15 07:52:34 -0700:\n> \n> On Oct 14, 2014, at 1:12 PM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Lars Kellogg-Stedman\'s message of 2014-10-14 12:50:48 -0700:\n> >> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:\n> >>> I think the above strategy is spot on. Unfortunately, that\'s not how the\n> >>> Docker ecosystem works.\n> >> \n> >> I\'m not sure I agree here, but again nobody is forcing you to use this\n> >> tool.\n> >> \n> >>> operating system that the image is built for. I see you didn\'t respond to my\n> >>> point that in your openstack-containers environment, you end up with Debian\n> >>> *and* Fedora images, since you use the \"official\" MySQL dockerhub image. And\n> >>> therefore you will end up needing to know sysadmin specifics (such as how\n> >>> network interfaces are set up) on multiple operating system distributions.\n> >> \n> >> I missed that part, but ideally you don\'t *care* about the\n> >> distribution in use.  All you care about is the application.  Your\n> >> container environment (docker itself, or maybe a higher level\n> >> abstraction) sets up networking for you, and away you go.\n> >> \n> >> If you have to perform system administration tasks inside your\n> >> containers, my general feeling is that something is wrong.\n> >> \n> > \n> > Speaking as a curmudgeon ops guy from \"back in the day\".. the reason\n> > I choose the OS I do is precisely because it helps me _when something\n> > is wrong_. And the best way an OS can help me is to provide excellent\n> > debugging tools, and otherwise move out of the way.\n> > \n> > When something _is_ wrong and I want to attach GDB to mysqld in said\n> > container, I could build a new container with debugging tools installed,\n> > but that may lose the very system state that I\'m debugging. So I need to\n> > run things inside the container like apt-get or yum to install GDB.. and\n> > at some point you start to realize that having a whole OS is actually a\n> > good thing even if it means needing to think about a few more things up\n> > front, such as \"which OS will I use?\" and \"what tools do I need installed\n> > in my containers?\"\n> > \n> > What I mean to say is, just grabbing off the shelf has unstated\n> > consequences.\n> \n> If this is how people are going to use and think about containers, I would\n> submit they are a huge waste of time. The performance value they offer is\n> dramatically outweighed by the flexibilty and existing tooling that exists\n> for virtual machines. As I state in my blog post[1] if we really want to\n> get value from containers, we must convert to the single application per\n> container view. This means having standard ways of doing the above either\n> on the host machine or in a debugging container that is as easy (or easier)\n> than the workflow you mention. There are not good ways to do this yet, and\n> the community hand-waves it away, saying things like, \"well you could ??.\n> You could isn?t good enough. The result is that a lot of people that are\n> using containers today are doing fat containers with a full os.\n> \n\nI think we really agree.\n\nWhat the container universe hasn\'t worked out is all the stuff that the\ndistros have worked out for a long time now: consistency.\n\nI think it would be a good idea for containers\' filesystem contents to\nbe a whole distro. What\'s at question in this thread is what should be\nrunning. If we can just chroot into the container\'s FS and run apt-get/yum\ninstall our tools, and then nsenter and attach to the running process,\nthen huzzah: I think we have best of both worlds.\n\nTo the container makers: consider that things can and will go wrong,\nand the answer may already exist as a traditional tool, and not be\n\"restart the container\".\n\n\n','<6829EC70-E67F-4181-A489-062490C36E7C@gmail.com>',NULL),('<1413388156.4059.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 10:49:16',-18000,'2014-10-15 15:49:16',NULL,'[openstack-dev] [api] API recommendation','Now that we have an API working group forming, I\'d like to kick off some\ndiscussion over one point I\'d really like to see our APIs using (and\nI\'ll probably drop it in to the repo once that gets fully set up): the\ndifference between synchronous and asynchronous operations.  Using nova\nas an example?right now, if you kick off a long-running operation, such\nas a server create or a reboot, you watch the resource itself to\ndetermine the status of the operation.  What I\'d like to propose is that\nfuture APIs use a separate \"operation\" resource to track status\ninformation on the particular operation.  For instance, if we were to\nrebuild the nova API with this idea in mind, booting a new server would\ngive you a server handle and an operation handle; querying the server\nresource would give you summary information about the state of the\nserver (running, not running) and pending operations, while querying the\noperation would give you detailed information about the status of the\noperation.  As another example, issuing a reboot would give you the\noperation handle; you\'d see the operation in a queue on the server\nresource, but the actual state of the operation itself would be listed\non that operation.  As a side effect, this would allow us (not require,\nthough) to queue up operations on a resource, and allow us to cancel an\noperation that has not yet been started.\n\nThoughts?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1413390705.14142.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 16:26:24',0,'2014-10-15 16:26:24',NULL,'[openstack-dev]  [Octavia] Octavia Meeting Agenda 10-15-2014','I\'ve added an Agenda for the meeting today.\n\nhttps://wiki.openstack.org/wiki/Octavia/Weekly_Meeting_Agenda\n\nMay not get to all of it but won\'t be a big deal.\n\nThanks,\nBrandon\n\n','<CAAGw+ZpBqkN4Fe4a8bzX4V1-E5expzFsfmTBSDEgjo44-dzh=g@mail.gmail.com>',NULL),('<1413406177.4059.6.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 15:49:37',-18000,'2014-10-15 20:49:37',NULL,'[openstack-dev] [api] API recommendation','On Wed, 2014-10-15 at 12:39 -0400, Andrew Laski wrote:\n> On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote:\n> > Now that we have an API working group forming, I\'d like to kick off some\n> > discussion over one point I\'d really like to see our APIs using (and\n> > I\'ll probably drop it in to the repo once that gets fully set up): the\n> > difference between synchronous and asynchronous operations.  Using nova\n> > as an example?right now, if you kick off a long-running operation, such\n> > as a server create or a reboot, you watch the resource itself to\n> > determine the status of the operation.  What I\'d like to propose is that\n> > future APIs use a separate \"operation\" resource to track status\n> > information on the particular operation.  For instance, if we were to\n> > rebuild the nova API with this idea in mind, booting a new server would\n> > give you a server handle and an operation handle; querying the server\n> > resource would give you summary information about the state of the\n> > server (running, not running) and pending operations, while querying the\n> > operation would give you detailed information about the status of the\n> > operation.  As another example, issuing a reboot would give you the\n> > operation handle; you\'d see the operation in a queue on the server\n> > resource, but the actual state of the operation itself would be listed\n> > on that operation.  As a side effect, this would allow us (not require,\n> > though) to queue up operations on a resource, and allow us to cancel an\n> > operation that has not yet been started.\n> >\n> > Thoughts?\n> \n> Something like https://review.openstack.org/#/c/86938/ ?\n> \n> I know that Jay has proposed a similar thing before as well.  I would \n> love to get some feedback from others on this as it\'s something I\'m \n> going to propose for Nova in Kilo.\n\nYep, something very much like that :)  But the idea behind my proposal\nis to make that a codified API guideline, rather than just an addition\nto Nova.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<543EA32D.7010405@rackspace.com>',NULL),('<1413409111.67603.YahooMailNeo@web121204.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-15 14:38:31',-25200,'2014-10-15 21:38:31',NULL,'[Openstack] Trouble adding volume to instance','Some more trouble shooting on this (and still no progress) I see this when I reboot (or use targetcli which is below this log):\n\n\n[root at block1 Python-2014-09-30-15:11:51-7481]# more backtrace\nnode.py:60:_create_in_cfs_ine:RTSLibError: Could not create NetworkPortal in configFS.\n\nTraceback (most recent call last):\n  File \"/bin/cinder-rtstool\", line 238, in <module>\n    sys.exit(main())\n  File \"/bin/cinder-rtstool\", line 203, in main\n    create(backing_device, name, userid, password, initiator_iqns)\n  File \"/bin/cinder-rtstool\", line 95, in create\n    rtslib.NetworkPortal(tpg_new, \'0.0.0.0\', 3260, mode=\'any\')\n  File \"/usr/lib/python2.7/site-packages/rtslib/target.py\", line 694, in __init__\n    self._create_in_cfs_ine(mode)\n  File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60, in _create_in_cfs_ine\n    % self.__class__.__name__)\nRTSLibError: Could not create NetworkPortal in configFS.\n\nLocal variables in innermost frame:\nself: <NetworkPortal 0.0.0.0 port 3260>\nmode: \'any\'\n\n\nFROM targetcli:\n\n/iscsi/iqn.20.../tpg1/portals> ls\no- portals ............................................................................................................ [Portals: 0]\n/iscsi/iqn.20.../tpg1/portals> create ip_address=10.7.5.41\nUsing default IP port 3260\nCould not create NetworkPortal in configFS.\n\n\n\nOn Tuesday, October 7, 2014 11:07 AM, Amit Anand <mr_amitanand at yahoo.com> wrote:\n \n\n\nHi all,\n\nBeen troubleshooting this for a while now and cant seem to figure out what wrong, reaching out here hoping that maybe someone would have some input/advice on how to fix. I am trying to add a volume to an instance and it keeps failing with the following errors below. Would appreciate any insight as I am wits end and I apologize in advance if this is not a place to ask questions such as these - Ive tried the AskOpenstack and have gotten nothing. Thanks!!\n\n[root at block1 tgt]# cinder list\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n|                  ID                  |   Status  | Display Name | Size | Volume Type | Bootable | Attached to |\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n| 4c6e1b15-2c7e-4bca-aae4-925cc054db8d | available |   myVolume   |  1   |     None    |  false   |             |\n| b8df2a1a-48df-443c-a078-bec907d8462d | available |   amitvol    |  20  |     None    |  false   |             |\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n\n\n\nBlock node error log:\n\n2014-10-07 10:58:46.720 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231    bb7ce560d1e9482b862679cefaf5ae69 - - -] Failed to create iscsi target for volume id:volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231    bb7ce560d1e9482b862679cefaf5ae69 - - -] Unexpected error while running command.\nCommand: sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool create /dev/cinder-volumes/volume-b8df2a1a-48df-443c-a078-bec907   d8462d iqn.2010-10.org.openstack:volume-b8df2a1a-48df-443c-a078-bec907d8462d 8HayuR8mAq7QpK9y7soB iZypk62NhziXmfvdZMDf\nExit code: 1\nStdout: \'Error creating NetworkPortal: ensure port 3260 is not in use by another service.\\n\'\nStderr: \'Traceback (most recent call last):\\n  File \"/bin/cinder-rtstool\", line 238, in <module>\\n    sys.exit(main())\\n  File \"/bin/ci   nder-rtstool\", line 203, in main\\n    create(backing_device, name, userid, password, initiator_iqns)\\n  File \"/bin/cinder-rtstool\", lin   e 95, in create\\n    rtslib.NetworkPortal(tpg_new, \\\'0.0.0.0\\\', 3260, mode=\\\'any\\\')\\n  File \"/usr/lib/python2.7/site-packages/rtslib/ta   rget.py\", line 694, in __init__\\n    self._create_in_cfs_ine(mode)\\n  File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60,    in _create_in_cfs_ine\\n    % self.__class__.__name__)\\nrtslib.utils.RTSLibError: Could not create NetworkPortal in configFS.\\n\'\n\n2014-10-07 10:58:46.721 31375 ERROR oslo.messaging.rpc.dispatcher [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a71921374   22231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Exception during message handling: Failed to create iscsi target for volume volume-b8df2a   1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher   File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\"   , line 540, in create_iscsi_target\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher     raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher ISCSITargetCreateFailed: Failed to create iscsi target for volume vol   ume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher\n\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137   422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Returning exception Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a   078-bec907d8462d. to caller\n\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137   422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/site-packages/oslo/   messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', \'  File \"/usr/lib/python2.7/site-packages/os   lo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', \'  File \"/usr/l   ib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, *   *new_args)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\',    \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(co  \n ntext, volume)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data = sel   f.target_helper.create_export(context, volume, volume_path)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line    53, in create_export\\n    chap_auth)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_i   scsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', \'ISCSITargetCreateFailed: Failed to create iscsi target    for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\']\n\n\nController node error log:\n\n2014-10-07 10:58:46.745 12232 ERROR cinder.api.middleware.fault [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Caught error: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n[u\'Traceback (most recent call last):\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(context, volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data = self.target_helper.create_export(context, volume, volume_path)\\n\',\n u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n    chap_auth)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].\n\n\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault RemoteError: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault [u\'Traceback (most recent call last):\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(context, volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data =\n self.target_helper.create_export(context, volume, volume_path)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n    chap_auth)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141015/08e237d5/attachment.html>\n\n','<1752860495.568004.1412694437273.JavaMail.yahoo@jws10071.mail.ne1.yahoo.com>',NULL),('<1413411115.95041.YahooMailNeo@web121204.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-15 15:11:55',-25200,'2014-10-15 22:11:55',NULL,'[Openstack] Trouble adding volume to instance','**Resending as another Openstack user informed me this was being directed to Spam in Gmail** \n\nThanks Boris!\n\nHi all,\n\nSome more trouble shooting on this (and still no progress) I see this when I reboot (or use targetcli which is below this log):\n\n\n[root at block1 Python-2014-09-30-15:11:51-7481]# more backtrace\nnode.py:60:_create_in_cfs_ine:RTSLibError: Could not create NetworkPortal in configFS.\n\nTraceback (most recent call last):\n  File \"/bin/cinder-rtstool\", line 238, in <module>\n    sys.exit(main())\n  File \"/bin/cinder-rtstool\", line 203, in main\n    create(backing_device, name, userid, password, initiator_iqns)\n  File \"/bin/cinder-rtstool\", line 95, in create\n    rtslib.NetworkPortal(tpg_new, \'0.0.0.0\', 3260, mode=\'any\')\n  File \"/usr/lib/python2.7/site-packages/rtslib/target.py\", line 694, in __init__\n    self._create_in_cfs_ine(mode)\n  File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60, in _create_in_cfs_ine\n    % self.__class__.__name__)\nRTSLibError: Could not create NetworkPortal in configFS.\n\nLocal variables in innermost frame:\nself: <NetworkPortal 0.0.0.0 port 3260>\nmode: \'any\'\n\n\nFROM targetcli:\n\n/iscsi/iqn.20.../tpg1/portals> ls\no- portals ............................................................................................................ [Portals: 0]\n/iscsi/iqn.20.../tpg1/portals> create ip_address=10.7.5.41\nUsing default IP port 3260\nCould not create NetworkPortal in configFS.\n\n\nOn Wednesday, October 15, 2014 5:38 PM, Amit Anand <mr_amitanand at yahoo.com> wrote:\n \n\n\nSome more trouble shooting on this (and still no progress) I see this when I reboot (or use targetcli which is below this log):\n\n\n[root at block1 Python-2014-09-30-15:11:51-7481]# more backtrace\nnode.py:60:_create_in_cfs_ine:RTSLibError: Could not create NetworkPortal in configFS.\n\nTraceback (most recent call last):\n  File \"/bin/cinder-rtstool\", line 238, in <module>\n    sys.exit(main())\n  File \"/bin/cinder-rtstool\", line 203, in main\n    create(backing_device, name, userid, password, initiator_iqns)\n  File \"/bin/cinder-rtstool\", line 95, in create\n    rtslib.NetworkPortal(tpg_new, \'0.0.0.0\', 3260, mode=\'any\')\n  File \"/usr/lib/python2.7/site-packages/rtslib/target.py\", line 694, in __init__\n    self._create_in_cfs_ine(mode)\n  File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60, in _create_in_cfs_ine\n    % self.__class__.__name__)\nRTSLibError: Could not create NetworkPortal in configFS.\n\nLocal variables in innermost frame:\nself: <NetworkPortal 0.0.0.0 port 3260>\nmode: \'any\'\n\n\nFROM targetcli:\n\n/iscsi/iqn.20.../tpg1/portals> ls\no- portals ............................................................................................................ [Portals: 0]\n/iscsi/iqn.20.../tpg1/portals> create ip_address=10.7.5.41\nUsing default IP port 3260\nCould not create NetworkPortal in configFS.\n\n\n\nOn Tuesday, October 7, 2014 11:07 AM, Amit Anand <mr_amitanand at yahoo.com> wrote:\n \n\n\nHi all,\n\nBeen troubleshooting this for a while now and cant seem to figure out what wrong, reaching out here hoping that maybe someone would have some input/advice on how to fix. I am trying to add a volume to an instance and it keeps failing with the following errors below. Would appreciate any insight as I am wits end and I apologize in advance if this is not a place to ask questions such as these - Ive tried the AskOpenstack and have gotten nothing. Thanks!!\n\n[root at block1 tgt]# cinder list\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n|                  ID                  |   Status  | Display Name | Size | Volume Type | Bootable | Attached to |\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n| 4c6e1b15-2c7e-4bca-aae4-925cc054db8d | available |   myVolume   |  1   |     None    |  false   |             |\n| b8df2a1a-48df-443c-a078-bec907d8462d | available |   amitvol    |  20  |     None    |  false   |             |\n+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n\n\n\nBlock node error log:\n\n2014-10-07 10:58:46.720 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231    bb7ce560d1e9482b862679cefaf5ae69 - - -] Failed to create iscsi target for volume id:volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231    bb7ce560d1e9482b862679cefaf5ae69 - - -] Unexpected error while running command.\nCommand: sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool create /dev/cinder-volumes/volume-b8df2a1a-48df-443c-a078-bec907   d8462d iqn.2010-10.org.openstack:volume-b8df2a1a-48df-443c-a078-bec907d8462d 8HayuR8mAq7QpK9y7soB iZypk62NhziXmfvdZMDf\nExit code: 1\nStdout: \'Error creating NetworkPortal: ensure port 3260 is not in use by another service.\\n\'\nStderr: \'Traceback (most recent call last):\\n  File \"/bin/cinder-rtstool\", line 238, in <module>\\n    sys.exit(main())\\n  File \"/bin/ci   nder-rtstool\", line 203, in main\\n    create(backing_device, name, userid, password, initiator_iqns)\\n  File \"/bin/cinder-rtstool\", lin   e 95, in create\\n    rtslib.NetworkPortal(tpg_new, \\\'0.0.0.0\\\', 3260, mode=\\\'any\\\')\\n  File \"/usr/lib/python2.7/site-packages/rtslib/ta   rget.py\", line 694, in __init__\\n    self._create_in_cfs_ine(mode)\\n  File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60,    in _create_in_cfs_ine\\n    % self.__class__.__name__)\\nrtslib.utils.RTSLibError: Could not create NetworkPortal in configFS.\\n\'\n\n2014-10-07 10:58:46.721 31375 ERROR oslo.messaging.rpc.dispatcher [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a71921374   22231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Exception during message handling: Failed to create iscsi target for volume volume-b8df2a   1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher   File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\"   , line 540, in create_iscsi_target\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher     raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher ISCSITargetCreateFailed: Failed to create iscsi target for volume vol   ume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher\n\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137   422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Returning exception Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a   078-bec907d8462d. to caller\n\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137   422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] [\'Traceback (most recent call last):\\n\', \'  File \"/usr/lib/python2.7/site-packages/oslo/   messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', \'  File \"/usr/lib/python2.7/site-packages/os   lo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', \'  File \"/usr/l   ib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, *   *new_args)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\',    \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(co  \n ntext, volume)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data = sel   f.target_helper.create_export(context, volume, volume_path)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line    53, in create_export\\n    chap_auth)\\n\', \'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_i   scsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', \'ISCSITargetCreateFailed: Failed to create iscsi target    for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\']\n\n\nController node error log:\n\n2014-10-07 10:58:46.745 12232 ERROR cinder.api.middleware.fault [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Caught error: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n[u\'Traceback (most recent call last):\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(context, volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data = self.target_helper.create_export(context, volume, volume_path)\\n\',\n u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n    chap_auth)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].\n\n\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault RemoteError: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault [u\'Traceback (most recent call last):\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n    incoming.message))\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n    return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n    result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n    volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n    return self._create_export(context, volume)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n    data =\n self.target_helper.create_export(context, volume, volume_path)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n    chap_auth)\\n\', u\'  File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n    raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141015/eba83d7c/attachment.html>\n\n','<1413409111.67603.YahooMailNeo@web121204.mail.ne1.yahoo.com>',NULL),('<1413412180.21249.YahooMailNeo@web121202.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-15 15:29:40',-25200,'2014-10-15 22:29:40',NULL,'[Openstack] Trouble adding volume to instance','So looks like it went again to spam. Ive put the errors Im getting here:\n\n\n\nPaste #121364 | LodgeIt!\n\n  \n          \nPaste #121364 | LodgeIt!\n[root at block1 Python-2014-09-30-15:11:51-7481]# more backtrace\nnode.py:60:_create_in_cfs_ine:RTSLibError: Could not create NetworkPortal in configFS.   \nView on paste.openstack.org Preview by Yahoo  \n  \n \nHi all,\n\nSome more trouble shooting on this (and still no progress) I see this when I reboot (or use targetcli which is below this log):\n\n\n\nOn Wednesday, October 15, 2014 6:21 PM, ????? ?????? <bbobrov at mirantis.com> wrote:\n \n\n\n? ????????? ?? Thursday 16 of October 2014 02:11:55 Amit ???????:\n> **Resending as another Openstack user informed me this was being\n> directed to Spam in Gmail**\n\nWent to spam again.\n\nMaybe you should put all the logs to http://paste.openstack.org?\n\n-- \nRegards,\n\nBoris\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141015/133e8e79/attachment.html>\n\n','<201410160221.47911.bbobrov@mirantis.com>',NULL),('<1413413500.16021.3.camel@jarvis>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 00:51:40',7200,'2014-10-15 22:51:40',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','On Wed, 2014-10-15 at 11:24 -0400, David Vossel wrote:\n> \n> ----- Original Message -----\n> > On Tue, 2014-10-14 at 19:52 -0400, David Vossel wrote:\n> > > \n> > > ----- Original Message -----\n> > > > Ok, why are you so down on running systemd in a container?\n> > > \n> > > It goes against the grain.\n> > > \n> > > From a distributed systems view, we gain quite a bit of control by\n> > > maintaining\n> > > \"one service per container\". Containers can be re-organised and re-purposed\n> > > dynamically.\n> > > If we have systemd trying to manage an entire stack of resources within a\n> > > container,\n> > > we lose this control.\n> > > \n> > > From my perspective a containerized application stack needs to be managed\n> > > externally\n> > > by whatever is orchestrating the containers to begin with. When we take a\n> > > step back\n> > > and look at how we actually want to deploy containers, systemd doesn\'t make\n> > > much sense.\n> > > It actually limits us in the long run.\n> > > \n> > > Also... recovery. Using systemd to manage a stack of resources within a\n> > > single container\n> > > makes it difficult for whatever is externally enforcing the availability of\n> > > that container\n> > > to detect the health of the container.  As it is now, the actual service is\n> > > pid 1 of a\n> > > container. If that service dies, the container dies. If systemd is pid 1,\n> > > there can\n> > > be all kinds of chaos occurring within the container, but the external\n> > > distributed\n> > > orchestration system won\'t have a clue (unless it invokes some custom\n> > > health monitoring\n> > > tools within the container itself, which will likely be the case someday.)\n> > \n> > I don\'t really think this is a good argument.  If you\'re using docker,\n> > docker is the management and orchestration system for the containers.\n> \n> no, docker is a local tool for pulling images and launching containers.\n> Docker is not the distributed resource manager in charge of overseeing\n> what machines launch what containers and how those containers are linked\n> together.\n\nWell, neither is systemd: fleet management has a variety of solution.\n\n> > There\'s no dogmatic answer to the question should you run init in the\n> > container.\n> \n> an init daemon might make sense to put in some containers where we have\n> a tightly coupled resource stack. There could be a use case where it would\n> make more sense to put these resources in a single container.\n> \n> I don\'t think systemd is a good solution for the init daemon though. Systemd\n> attempts to handle recovery itself as if it has the entire view of the \n> system. With containers, the system view exists outside of the containers.\n> If we put an internal init daemon within the containers, that daemon needs\n> to escalate internal failures. The easiest way to do this is to\n> have init die if it encounters a resource failure (init is pid 1, pid 1 exiting\n> causes container to exit, container exiting gets the attention of whatever\n> is managing the containers)\n\nI won\'t comment on what init should be.  However, init should not be\nrunning in application containers, as I have said because it complicates\nthe situation.  Application containers are more compelling the simpler\nthey are constructed because they\'re easier to describe in xml +\ntemplates.\n\n> > The reason for not running init inside a container managed by docker is\n> > that you want the template to be thin for ease of orchestration and\n> > transfer, so you want to share as much as possible with the host.  The\n> > more junk you put into the container, the fatter and less agile it\n> > becomes, so you should probably share the init system with the host in\n> > this paradigm.\n> \n> I don\'t think the local init system and containers should have anything\n> to do with one another.  I said this in a previous reply, I\'m approaching\n> this problem from a distributed management perspective. The host\'s\n> init daemon only has a local view of the world. \n\nIf the container is an OS container, what you run inside is a full OS\nstack; the only sharing is the kernel, so you get whatever the distro is\nusing as init and for some of them, that\'s systemd.  You have no choice\nfor OS containers.\n\n> > \n> > Conversely, containers can be used to virtualize full operating systems.\n> > This isn\'t the standard way of doing docker, but LXC and OpenVZ by\n> > default do containers this way.  For this type of container, because you\n> > have a full OS running inside the container, you have to also have\n> > systemd (assuming it\'s the init system) running within the container.\n> \n> sure, if you want to do this use systemd. I don\'t understand the use case\n> where this makes any sense though. For me this falls in the \"yeah you can do it,\n> but why?\" category.\n\nIt\'s the standard Service Provider use case: containers are used as\ndense, lightweight Virtual Environments for Virtual Private Servers.\nThe customer can be provisioned with whatever OS they like, but you\nstill get 3x the density and the huge elasticity improvements of\ncontainers.\n\nJames\n\n\n\n\n','<630315848.42013083.1413386690624.JavaMail.zimbra@redhat.com>',NULL),('<1413427709-sup-8539@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 20:19:03',-25200,'2014-10-16 03:19:03',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','Excerpts from Angus Lees\'s message of 2014-10-15 17:30:52 -0700:\n> On Wed, 15 Oct 2014 09:51:03 AM Clint Byrum wrote:\n> > Excerpts from Vishvananda Ishaya\'s message of 2014-10-15 07:52:34 -0700:\n> > > On Oct 14, 2014, at 1:12 PM, Clint Byrum <clint at fewbar.com> wrote:\n> > > > Excerpts from Lars Kellogg-Stedman\'s message of 2014-10-14 12:50:48 \n> -0700:\n> > > >> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:\n> > > >>> I think the above strategy is spot on. Unfortunately, that\'s not how\n> > > >>> the\n> > > >>> Docker ecosystem works.\n> > > >> \n> > > >> I\'m not sure I agree here, but again nobody is forcing you to use this\n> > > >> tool.\n> > > >> \n> > > >>> operating system that the image is built for. I see you didn\'t respond\n> > > >>> to my point that in your openstack-containers environment, you end up\n> > > >>> with Debian *and* Fedora images, since you use the \"official\" MySQL\n> > > >>> dockerhub image. And therefore you will end up needing to know\n> > > >>> sysadmin specifics (such as how network interfaces are set up) on\n> > > >>> multiple operating system distributions.> >> \n> > > >> I missed that part, but ideally you don\'t *care* about the\n> > > >> distribution in use.  All you care about is the application.  Your\n> > > >> container environment (docker itself, or maybe a higher level\n> > > >> abstraction) sets up networking for you, and away you go.\n> > > >> \n> > > >> If you have to perform system administration tasks inside your\n> > > >> containers, my general feeling is that something is wrong.\n> > > > \n> > > > Speaking as a curmudgeon ops guy from \"back in the day\".. the reason\n> > > > I choose the OS I do is precisely because it helps me _when something\n> > > > is wrong_. And the best way an OS can help me is to provide excellent\n> > > > debugging tools, and otherwise move out of the way.\n> > > > \n> > > > When something _is_ wrong and I want to attach GDB to mysqld in said\n> > > > container, I could build a new container with debugging tools installed,\n> > > > but that may lose the very system state that I\'m debugging. So I need to\n> > > > run things inside the container like apt-get or yum to install GDB.. and\n> > > > at some point you start to realize that having a whole OS is actually a\n> > > > good thing even if it means needing to think about a few more things up\n> > > > front, such as \"which OS will I use?\" and \"what tools do I need\n> > > > installed\n> > > > in my containers?\"\n> > > > \n> > > > What I mean to say is, just grabbing off the shelf has unstated\n> > > > consequences.\n> > > \n> > > If this is how people are going to use and think about containers, I would\n> > > submit they are a huge waste of time. The performance value they offer is\n> > > dramatically outweighed by the flexibilty and existing tooling that exists\n> > > for virtual machines. As I state in my blog post[1] if we really want to\n> > > get value from containers, we must convert to the single application per\n> > > container view. This means having standard ways of doing the above either\n> > > on the host machine or in a debugging container that is as easy (or\n> > > easier)\n> > > than the workflow you mention. There are not good ways to do this yet, and\n> > > the community hand-waves it away, saying things like, \"well you could ??.\n> > > You could isn?t good enough. The result is that a lot of people that are\n> > > using containers today are doing fat containers with a full os.\n> > \n> > I think we really agree.\n> > \n> > What the container universe hasn\'t worked out is all the stuff that the\n> > distros have worked out for a long time now: consistency.\n> > \n> > I think it would be a good idea for containers\' filesystem contents to\n> > be a whole distro. What\'s at question in this thread is what should be\n> > running. If we can just chroot into the container\'s FS and run apt-get/yum\n> > install our tools, and then nsenter and attach to the running process,\n> > then huzzah: I think we have best of both worlds.\n> \n> Erm, yes that\'s exactly what you can do with containers (docker, lxc, and \n> presumably any other use of containers with a private/ephemeral filesystem).\n> \n\nThe point I was trying to make is that this case was not being addressed\nby the \"don\'t run init in a container\" crowd. I am in that crowd, and\nthus, wanted to make the point: this is how I think it will work when\nI do finally get around to trying containers for a real workload.\n\n> To others here:\n> \n> There\'s a lot of strongly-held opinions being expressed on this thread, and a \n> number of them appear to be based on misinformation or a lack of understanding \n> of the technology and goals.  I\'m happy to talk over IRC/VC/whatever to anyone \n> about why I think this sort of stuff is worth pursuing (and I assume there are \n> plenty of others too).  I\'d also suggest reading docs and/or in-person at your \n> local docker/devops meetup would be a more efficient method of learning rather \n> than this to-and-fro on the os-dev mailing list...\n> \n\nI think you may have been mistaken about the purpose of this list. It is\nfor openstack developers to discuss exactly the things you\'re talking\nabout not discussing on this list. You\'ve done a great job of helping us\nclear these things up. Don\'t turn around and tell us \"now don\'t ever do\nthat again.\" just as we\'re about to understand. ;)\n\n\n','<2792147.ThoQ0gbaBG@hounddog>',NULL),('<1413441458.4332.7.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 08:37:38',7200,'2014-10-16 06:37:38',NULL,'[openstack-dev] [devstack] Question about the\n \"OVS_PHYSICAL_BRIDGE\" attribute defined in localrc','I\'m not sure about the exact reason, but this is what I think: \n\nIt\'s intended behavior, as adding an interface to a bridge is a\ndisruptive task. Here an example.\n\nYou want to add your eth0 interface that has an ip address assigned to\nyour bridge br-p1p1. You could do this with ovs-vsctl add-port br-p1p1\neth0. This causes your eth0 to become a slave of the bridge --> you\ncannot use the eth0 device for communication anymore. So your host won\'t\nbe reachable over the network anymore! To solve this you have to take\naway the ip configuration of your eth interface and put this config on\nyour br-p1p1. E.g ifconfig eth0 0; ifconfig br-p1p1 1.2.3.4/24\nNow your host should be reachable again.\n\nIf eth0 is your only interface, I guess there\'s a big risk, that you\nlock out yourself if this would be part of devstack.\n\nHope that helps\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-10-15 at 14:28 +0000, Danny Choi (dannchoi) wrote:\n> Hi,\n> \n> \n> When I have \"OVS_PHYSICAL_BRIDGE=br-p1p1? defined in localrc, devstack\n> creates the OVS bridge \"br-p1p1\".\n> \n> \n> localadmin at qa4:~/devstack$ sudo ovs-vsctl show\n> \n> 5f845d2e-9647-47f2-b92d-139f6faaf39e\n> \n>     Bridge \"br-p1p1\"     <<<<<\n> \n>         Port \"phy-br-p1p1\"\n> \n>             Interface \"phy-br-p1p1\"\n> \n>                 type: patch\n> \n>                 options: {peer=\"int-br-p1p1\"}\n> \n>         Port \"br-p1p1\"\n> \n>             Interface \"br-p1p1\"\n> \n>                 type: internal\n> \n> \n> However, no physical port is added to it.  I have to manually do it.\n> \n> \n> localadmin at qa4:~/devstack$ sudo ovs-vsctl add-port br-p1p1 p1p1\n> \n> localadmin at qa4:~/devstack$ sudo ovs-vsctl show\n> \n> 5f845d2e-9647-47f2-b92d-139f6faaf39e\n> \n>    Bridge \"br-p1p1\"\n> \n>        Port \"phy-br-p1p1\"\n> \n>            Interface \"phy-br-p1p1\"\n> \n>                type: patch\n> \n>                options: {peer=\"int-br-p1p1\"}\n> \n>        Port \"br-p1p1\"\n> \n>            Interface \"br-p1p1\"\n> \n>                type: internal\n> \n>        Port ?p1p1?     <<<<<\n> \n>             Interface ?p1p1\"\n> \n> \n> \n> Is this expected behavior?\n> \n> \n> Thanks,\n> \n> Danny\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<D063FC7C.1E50%dannchoi@cisco.com>',NULL),('<1413449723.1634951.1395752193086.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-25 08:56:33',-14400,'2014-03-25 12:56:33',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials\n	to	Keystone','\n\n> Hi,\n> \n> Right now Ironic is being responsible for storing the credentials for the\n> IPMI and SSH drivers (and potentially other drivers in the future), I wonder\n> if we should delegate this task to Keystone. The Keystone V3 API now has a\n> /credentials endpoint which would allow us to specify arbitrary types (not\n> only ec2 anymore) and use it as a credential store[1].\n> \n> That would avoid further fragmentation of credentials being stored in\n> different places in OpenStack, and make the management of the credentials\n> easier (Think about a situation where many nodes share the same IPMI\n> username/password and we need to update it, if this is stored in Keystone it\n> only needs to be updated there once cause nodes will only hold a reference\n> to it)\n> \n> It also was pointed to me that setting a hard dependency on Keystone V3 might\n> significantly raises the bar for integration with existing clouds*. So\n> perhaps we should make it optional? In the same way we can specify a\n> username/password or key_filename for the ssh driver we could have a\n> reference to a credential in Keystone V3?\n> \n> What you guys think about the idea?\n\nHi Lucas,\n\nAt a high level, this sounds like an excellent idea to me.\n\nIIUC the major blocker to ceilometer taking point on controlling the\nIPMI polling cycle has been secure access to these credentials. If these\nwere available to ceilometer in a controlled way via keystone, then the\nIPMI polling cycle could be managed in a very similar way to the ceilo\npolling activity on the hypervisor and SMNP daemons.\n\nHowever, I\'m a little fuzzy on the detail of enabling this via keystone\nv3, so it would be great to drill down into the detail either on the ML\nor at summit. \n\nFor example, would it be in the guise of a trust that delegates limited\nprivilege to allow the ceilometer user call GET /credentials to retrieve\nthe IPMI user/pass?\n\nOr would the project_id parameter to POST /credentials suffice to limit\naccess to IPMI credentials to the ceilometer tenant only? (as opposed to\nallowing any other openstack service access these creds)\n\nIn that case, would we need to also decouple the ceilometer user from\nthe generic service tenant?\n\nCheers,\nEoghan\n\n> What are the cloud operators/sysadmins\n> view on that?\n> \n> * There\'s also some ongoing thoughts about using v3 for other things in\n> Ironic (e.g signed url\'s) but that\'s kinda out of the topic.\n> \n> \n> [1]\n> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#create-credential-post-credentials\n> Ironic bp (discussion):\n> https://blueprints.launchpad.net/ironic/+spec/credentials-keystone-v3\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAB1EZBoMeKJme=4dTk2nffx0a9Jd4Xwc5jQsk3+1iH+nUM2zFw@mail.gmail.com>',NULL),('<1413488975-sup-1194@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 13:14:26',-25200,'2014-10-16 20:14:26',NULL,'[openstack-dev] [TripleO] Summit scheduling - using our time\n	together wisely.','The format has changed slightly this summit, to help encourage a more\ncollaborative design experience, rather than rapid fire mass-inclusion\nsummit sessions. So we have two 40-minute long slots, and one whole day\nof contributor meetup.[1]\n\nOur etherpad topics page has received quite a few additions now [2], and\nso I\'d like to hear thoughts on what things we want to talk about in the\nmeetup versus the sessions.\n\nA few things I think we should stipulate:\n\n* The scheduled sessions will be heavily attended by the community at\n  large. This often includes those who are just curious, or those who\n  want to make sure that their voice is heard. These sessions should be\n  reserved for those topics which have the most external influence or\n  are the most dependent on other projects.\n\n* The meetup will be at the end of the week so at the end of it, we\n  can\'t then go to any other meetups and ask for things / participate\n  in those design activities. This reinforces that scheduled session\n  time should be focused on things that are externally focused so that\n  we can take the result of those discussions into any of the sessions\n  that are after.\n\n* The Ops Summit is Wendesday/Thursday [3], which overlaps with these\n  sessions. I am keenly interested in gathering more contribution from\n  those already operating and deploying OpenStack. It can go both ways,\n  but I think it might make sense to have more ops-centric topics\n  discussed on Friday, when those participants might not be fully\n  wrapped up in the ops sessions.\n\nIf we can all agree on those points, given the current topics, I think\nour scheduled sessions should target at least (but not limited to):\n\n* Cinder + CEPH\n* Layer 3 segmentation\n\nI think those might fit into 40 minutes, as long as we hash some things\nout here on the mailing list first. Cinder + CEPH is really just a\ncheck-in to make sure we\'re on track to providing it. Layer 3, I\'ve had\ndiscussions with Ironic and Neutron people and I think we have a plan,\nbut I wanted to present it in the open and discuss the short term goals\nto see if it satisfies what users may want for the Kilo time frame.\n\nSo, I would encourage you all to look at the etherpad, and expand on\ntopics or add more, and then reply to this thread with ideas for how\nbest to use our precious time together.\n\n[1] http://kilodesignsummit.sched.org/overview/type/tripleo\n[2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics\n[3] http://kilodesignsummit.sched.org/overview/type/ops+summit\n\n\n',NULL,NULL),('<1413494303.969124289@mail.openstack.org>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-10-16 16:18:23',-18000,'2014-10-16 21:18:23',NULL,'[Openstack-operators] Requesting OpenStack Operators to Help Staff\n	Booth at USENIX LISA','\nHi everyone,  [ USENIX LISA ]( https://www.usenix.org/conference/lisa14 ) (Large Installation System Administration Conference) is coming up November 9-14 in Seattle, WA.  Yes, it\'s the week after the Paris Summit! 1000+ sysadmins, DevOps, architects, software engineers, and more will attend. OpenStack is a silver sponsor and a premier exhibitor.  We have a limited number of full conference passes to offer to experienced OpenStack operators who would like to help staff our booth to talk to the attendees about OpenStack - and attend sessions.\n \nThe free passes cover the main conference program, meals, and evening events Wednesday-Friday, Nov 12-14.  The booth is open for staffing Wed., Nov 12 from 12-7pm and Thurs., Nov 13 from 10am-2pm.  \n \nPlease reply with your role in your company.  We\'ll confirm technical candidates on a first-come, first-served basis.  If/when we run out of full conference passes, we have expo only passes to offer.  \n \nOther OpenStack activities at LISA:\nHalf day training on Monday, Nov. 10 by Mirantis (fee applies)\nDreamhost providing OpenStack-based virtual machines to LISA Lab\nOpenStack demo on Thursday, Nov. 13 by Canonical\nThank you for your support!\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141016/bf9f0de0/attachment.html>\n\n',NULL,NULL),('<1413525468-sup-341@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 23:00:40',-25200,'2014-10-17 06:00:40',NULL,'[openstack-dev] [all] add cyclomatic complexity check to pep8\n	target','Excerpts from Mike Spreitzer\'s message of 2014-10-16 22:24:30 -0700:\n> I like the idea of measuring complexity.  I looked briefly at `python -m \n> mccabe`.  It seems to measure each method independently.  Is this really \n> fair?  If I have a class with some big methods, and I break it down into \n> more numerous and smaller methods, then the largest method gets smaller, \n> but the number of methods gets larger.  A large number of methods is \n> itself a form of complexity.  It is not clear to me that said re-org has \n> necessarily made the class easier to understand.  I can also break one \n> class into two, but it is not clear to me that the project has necessarily \n> become easier to understand.  While it is true that when you truly make a \n> project easier to understand you sometimes break it into more classes, it \n> is also true that you can do a bad job of re-organizing a set of classes \n> while still reducing the size of the largest method.  Has the McCabe \n> metric been evaluated on Python projects?  There is a danger in focusing \n> on what is easy to measure if that is not really what you want to \n> optimize.\n> \n> BTW, I find that one of the complexity issues for me when I am learning \n> about a Python class is doing the whole-program type inference so that I \n> know what the arguments are.  It seems to me that if you want to measure \n> complexity of Python code then something like the complexity of the \n> argument typing should be taken into account.\n> \n\nFences don\'t solve problems. Fences make it harder to cause problems.\n\nOf course you can still do the wrong thing and make the code worse. But\nyou can\'t do _this_ wrong thing without asserting why you need to.\n\n\n','<OF6B330C2C.1F7FA81F-ON85257D74.001C0600-85257D74.001DB597@us.ibm.com>',NULL),('<14135287.130.1353311239239.JavaMail.sthakkar@sthakkar-mbair.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-18 23:47:22',-28800,'2012-11-19 07:47:22',NULL,'[openstack-dev] [Quantum]How to contribute LBaas driver?','Hi Hu,\n\nYes, that is the correct process. We initially were having separate LBaaS discussions during/after the summit but it has now been separated into distinct work items. If you\'re interested in helping, ping us when we discuss LBaaS during the quantum meeting\n\nCheers,\nSachin\n\n----- Original Message -----\nFrom: \"HuYanrui\" <huyr at arraynetworks.com.cn>\nTo: openstack-dev at lists.openstack.org\nSent: Sunday, November 18, 2012 11:28:26 PM\nSubject: [openstack-dev] [Quantum]How to contribute LBaas driver?\n\n\n\nGuys, \nJust want to make sure how to contribue LBaas driver (commercial)? \nIs this process same with contribute plugin in quantum like this page? - \nhttp://wiki.openstack.org/QuantumDevelopment \n\n\n\nHu Yanrui \n\nArray Networks Inc. \n\nTel: 86 010-84446688 ext 259 \n\nE-mail : huyr at arraynetworks.com.cn \n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<C3DFEDBB75E54032812FAE0B5026A054@PC201007301138>',NULL),('<1413562004.25342235.1417531866358.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 09:51:06',-18000,'2014-12-02 14:51:06',NULL,'[openstack-dev] [qa] Should it be allowed to attach 2\n interfaces from the same subnet to a VM?','----- Original Message -----\n> From: \"Danny Choi (dannchoi)\" <dannchoi at cisco.com>\n> To: openstack-dev at lists.openstack.org\n> \n> Hi,\n> \n> When I attach 2 interfaces from the same subnet to a VM, there is no error\n> returned and\n> both interfaces come up.\n> \n> lab at tme211:/opt/stack/logs$ nova interface-attach --net-id\n> e38dba4a-74ed-4312-ba21-2a04b5c5a5b5 cirros-1\n> \n> lab at tme211:/opt/stack/logs$ nova list\n> \n> +--------------------------------------+----------+--------+------------+-------------+-------------------+\n> \n> | ID                                   | Name     | Status | Task State |\n> | Power State | Networks          |\n> \n> +--------------------------------------+----------+--------+------------+-------------+-------------------+\n> \n> | 9d88d0b5-2453-4657-8058-987980ec7744 | cirros-1 | ACTIVE | -          |\n> | Running     | private=10.0.0.10 |\n> \n> +--------------------------------------+----------+--------+------------+-------------+-------------------+\n> \n> lab at tme211:/opt/stack/logs$ nova interface-attach --net-id\n> e38dba4a-74ed-4312-ba21-2a04b5c5a5b5 cirros-1\n> \n> lab at tme211:/opt/stack/logs$ nova list\n> \n> +--------------------------------------+----------+--------+------------+-------------+------------------------------+\n> \n> | ID                                   | Name     | Status | Task State |\n> | Power State | Networks                     |\n> \n> +--------------------------------------+----------+--------+------------+-------------+------------------------------+\n> \n> | 9d88d0b5-2453-4657-8058-987980ec7744 | cirros-1 | ACTIVE | -          |\n> | Running     | private=10.0.0.10, 10.0.0.11 |\n> \n> +--------------------------------------+----------+--------+------------+-------------+------------------------------+\n> \n> \n> $ ifconfig\n> \n> eth0      Link encap:Ethernet  HWaddr FA:16:3E:92:2D:2B\n> \n>           inet addr:10.0.0.10  Bcast:10.0.0.255  Mask:255.255.255.0\n> \n>           inet6 addr: fe80::f816:3eff:fe92:2d2b/64 Scope:Link\n> \n>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> \n>           RX packets:514 errors:0 dropped:0 overruns:0 frame:0\n> \n>           TX packets:307 errors:0 dropped:0 overruns:0 carrier:0\n> \n>           collisions:0 txqueuelen:1000\n> \n>           RX bytes:48342 (47.2 KiB)  TX bytes:41750 (40.7 KiB)\n> \n> \n> eth1      Link encap:Ethernet  HWaddr FA:16:3E:EF:55:BC\n> \n>           inet addr:10.0.0.11  Bcast:10.0.0.255  Mask:255.255.255.0\n> \n>           inet6 addr: fe80::f816:3eff:feef:55bc/64 Scope:Link\n> \n>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n> \n>           RX packets:49 errors:0 dropped:0 overruns:0 frame:0\n> \n>           TX packets:8 errors:0 dropped:0 overruns:0 carrier:0\n> \n>           collisions:0 txqueuelen:1000\n> \n>           RX bytes:3556 (3.4 KiB)  TX bytes:1120 (1.0 KiB)\n> \n> \n> \n> Should this operation be allowed?\n\nSupport for this was explicitly added in Juno:\n\n    https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net\n\nDo you have a concrete reason in mind as to why this should *not* be allowed?\n\nThanks,\n\nSteve\n\n\n','<D0A2885B.2EBF%dannchoi@cisco.com>',NULL),('<1413562665.16.1387435482506.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-19 06:44:42',0,'2013-12-19 06:44:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-python26-havana #10','See <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/10/changes>\n\nChanges:\n\n[twilson] Add fwaas_driver.ini to setup.cfg\n\n[Salvatore Orlando] NVP: propagate net-gw update to backend\n\n------------------------------------------\n[...truncated 142 lines...]\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins01.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.iaqChS2r50/tmpsFJCrv\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.iaqChS2r50/tmprwZkBw\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.iaqChS2r50/tmpDMUBCd\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1 ${PYTHON:-python} -m subunit.run discover -t ./ neutron/tests/unit  --load-list /tmp/tmp.iaqChS2r50/tmp30SFhW\nRan 9422 tests in 2222.770s\nPASSED (id=0, skips=335)\nSlowest Tests\nTest id                                                                                                                Runtime (s)\n---------------------------------------------------------------------------------------------------------------------  -----------\nneutron.tests.unit.nicira.test_nvp_sync.NvpSyncTestCase.test_sync_chunk_larger_maxpagesize_triggers_multiple_requests  13.152\nneutron.tests.unit.nicira.test_nicira_plugin.TestNiciraPortsV2.test_recycling                                          10.791\nneutron.tests.unit.nicira.test_edge_router.ServiceRouterTestCase.test_floatingip_update_different_router               10.380\nneutron.tests.unit.nicira.test_edge_router.NvpRouterTestCase.test_floatingip_update_different_router                    9.617\nneutron.tests.unit.nec.test_router.NecRouterOpenFlowTestCase.test_floatingip_update_different_router                    8.872\nneutron.tests.unit.test_extension_extraroute.ExtraRouteDBSepTestCaseXML.test_floatingip_update_different_router         8.494\nneutron.tests.unit.test_l3_plugin.L3NatDBIntTestCase.test_floatingip_update_different_router                            8.304\nneutron.tests.unit.test_extension_extraroute.ExtraRouteDBIntTestCase.test_floatingip_update_different_router            8.228\nneutron.tests.unit.test_extension_extraroute.ExtraRouteDBIntTestCaseXML.test_floatingip_update_different_router         8.191\nneutron.tests.unit.nicira.test_nicira_plugin.TestNiciraL3NatTestCase.test_floatingip_update_different_router            8.096\n___________________________________ summary ____________________________________\n  py26: commands succeeded\n  congratulations :)\n+ result=0\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==2.0.10\nalembic==0.6.1\namqp==1.3.3\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\ncliff==1.4.5\ncmd2==0.6.7\nconfigobj==4.7.2\ncoverage==3.7.1\ndiscover==0.4.0\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonrpclib==0.1.3\nkombu==3.0.8\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nneutron==jenkins.periodic.neutron.python26.havana.10\nordereddict==1.1\noslo.config==1.2.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npyflakes==0.7.3\npyparsing==2.0.1\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-subunit==0.0.16\npytz==2013.8\npyudev==0.16.1\nrepoze.lru==0.6\nrequests==2.1.0\nsetuptools-git==1.0\nsimplejson==3.3.1\nsix==1.4.1\nstevedore==0.13\ntestrepository==0.0.18\ntesttools==0.9.34\nwaitress==0.8.8\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py26/bin/subunit-1to2\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\nBuild timed out (after 40 minutes). Marking the build as failed.\n/usr/local/jenkins/slave_scripts/run-unittests.sh: line 62:  3376 Terminated              gzip -9 ./testr_results.html\n+ export PYTHON=.tox/py26/bin/python\n+ PYTHON=.tox/py26/bin/python\n+ set -e\n++ .tox/py26/bin/testr last\n++ sed -ne \'s/Ran \\([0-9]\\+\\).*tests in.*/\\1/p\'\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-havana/centos6-3/10\n[SCP] Copying console log.\n\n\n','<1203424309.15.1387349334007.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<14136421.4199.1352398225469.JavaMail.sthakkar@sthakkar-mbair.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-08 10:10:25',-28800,'2012-11-08 18:10:25',NULL,'[openstack-dev] LBaaS meeting - Thursday 11/8','Hello all,\n\nJust to keep the list up to date, we are using the following etherpad for notes/discussion topics:\nhttps://etherpad.openstack.org/grizzly-lbaas-workitems\n\nCheers,\nSachin\n\n----- Original Message -----\nThe following meeting has been modified:\n\nSubject: LBaaS meeting - Thursday 11/8 \nOrganizer: \"Sachin Thakkar\" <sthakkar at vmware.com> \n\nLocation: VMware Palo Alto Building A (Hemlock) \nTime: Thursday, November 8, 2012, 9:30:00 AM - 11:30:00 AM GMT -08:00 US/Canada Pacific\n \nInvitees: openstack-dev at lists.openstack.org; eperdomo at cisco.com; Greg_Jacobs at Dell.com; apalanisamy at paypal.com; cnaik at paypal.com; Youcef.Laribi at eu.citrix.com; SamuelB at radware.com; sorlando at vmware.com; dwendlandt at vmware.com; lcui at vmware.com; smaskalik at vmware.com ... \n\n\n*~*~*~*~*~*~*~*~*~*\n\nHi all, \n\nAs discussed during Tuesday\'s LBaaS meeting, we will have a follow up tomorrow (Thursday 11/8) to further drill down into each of the tasks involved. \n\nWe will be meeting in-person at the VMware Palo Alto Campus. Additionally, we will open up the phone bridge (details below) for remote participants. Apologies for the early meeting time, but I want to make sure we pick a time which can accommodate the global teams in Russia, China, England, Israel etc. We can run later if we need to, but I\'ll block a couple hours for the time being. \n\nIn person: \nVMware Palo Alto \nBuilding A \nHemlock Conference Room \n3401 Hillview Ave \nPalo Alto, CA 94304 \nGoogle Map: http://goo.gl/maps/Ao59S \n\nThere is a reception desk at the front of the building who will be able to reach me and guide you to the conference room. \n\nDial in: \nParticipant Passcode: 697 737 3510 \nCall-in toll-free number (Premiere): 1-866-715-6501 (US) \nAdditional Regional Numbers: http://pages.pgi-email.com/page.aspx?qs=5c591a8916642e738e03c25585184f841174bd68edc7b376f211065726f20c4087d2dbd294c95628953b9ebd93c298f8a59d287357f683bc937b0420662c826d43f873082e5033f476121c74d72cc5ed151c4b30a31fa1b2 \n\nAll who are interested are welcome to join. \n\nCheers, \nSachin \n\n\n',NULL,NULL),('<1413646986871-55528.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-18 08:43:06',-25200,'2014-10-18 15:43:06',NULL,'[openstack-dev] [keystone] Support for external authentication\n (i.e. REMOTE_USER) in Havana','Hello,\n\nThank you for posting this issue to openstack-dev. I had posted this on the\nopenstack general user list and was waiting for response.\n\nMay i know, if we have any progress regarding this issue.\n\nI am trying to use external HTTPD authentication with kerberos and LDAP\nidentity backend, in Havana.\n\nI think, few things have changed with Openstack Icehouse release and\nKeystone 0.9.0 on CentOS 6.5.\n\nCurrently I face a similar issue to yours : I get a full username with\ndomain as REMOTE_USER from apache, and keystone tries to search LDAP  along\nwith my domain name. ( i have not mentioned any domain information to\nkeystone. i assume it is called \'default\', while my domain is: example.com )\n\nI see that - External Default and External Domain are no longer supported by\nkeystone but intstead - \n\nkeystone.auth.plugins.external.DefaultDomain or\nexternal=keystone.auth.plugins.external.Domain are valid as of now.\n\nI also tried using keystone.auth.plugins.external.kerberos after checking\nthe code, but it does not make any difference.\n\nFor example:\n\nIf i authenticate using kerberos with : lohit.valleru at example.com. I see the\nfollowing in the logs.\n\nDEBUG keystone.common.ldap.core [-] LDAP search:\ndn=ou=People,dc=example,dc=come, scope=1,\nquery=(&(uid=lohit.valleru at example.com)(objectClass=posixAccount)),\nattrs=[\'mail\', \'userPassword\', \'enabled\', \'uid\'] search_s\n/usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:807\n2014-10-18 02:34:36.459 5592 DEBUG keystone.common.ldap.core [-] LDAP unbind\nunbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:777\n2014-10-18 02:34:36.460 5592 WARNING keystone.common.wsgi [-] Authorization\nfailed. Unable to lookup user lohit.valleru at example.com from 172.31.41.104\n\nAlso, i see that keystone always searches with \"uid\", no matter what i enter\nas a mapping value for userid/username in keystone.conf . I do not\nunderstand if this is a bug or limitation. ( The above logs show that they\nare not able to find uid with lohit.valleru at example.com since LDAP contains\nuid without domain name)\n\nMay i know, how do i request keystone to split REMOTE_USER? Do i need to\nmention default domain and sync with database in order for this to work?\n\nAlso, May i know - what modifications do i need to do to Havana to disable\nusername and password authentication, but instead use external\nauthentication such as Kerberos/REMOTE_USER.\n\nIs anyone working on these scenarios? or do we have any better solutions?\n\nI have read about Federation and Shibboleth authentication, but i believe\nthat is not the same as REMOTE_USER/Kerberos authentication.\n\nThank you,\n\nLohit\n\nThank you,\n\nLohit\n\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/keystone-Support-for-external-authentication-i-e-REMOTE-USER-in-Havana-tp22185p55528.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<20131029125920.GA11753@yuso.ifca.es>',NULL),('<1413822984.43117.YahooMailNeo@web126106.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-20 09:36:24',-25200,'2014-10-20 16:36:24',NULL,'[OpenStack-docs] xinclude statements for the Networking Guide','Hello Anne,\n\nI am the new writer for the Networking Guide. Last week I finally started to work on the Networking Guide. It looks like the \"chunks\" of content that essentially make up the equivalent of a topic (and subtopics) are all separated via xinclude statements instead of being directly included in the chapter file as a section. I therefore assumed that this method was supposed to be followed with respect to all future modifications, deletions, and additions for this document.\n\nHowever, when I raised this issue with the small group of folks I work with, they indicated that i should get in touch with you to see if this structure of having xinclude statements that basically represent topics is the chosen method that I should follow in the future for this document?\n\nSince I am a newbie to OpenStack, please let me know if this is the appropriate method of communicating with you.\n\nRegards and thanks,\n \nElke Vorheis\n(650) 291-1375 (cell)\nelkev at yahoo.com (email)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141020/c3e4c728/attachment.html>\n\n',NULL,NULL),('<1413825700.21298.YahooMailNeo@web126101.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-10-20 10:21:40',-25200,'2014-10-20 17:21:40',NULL,'[OpenStack-docs] xinclude statements for the Networking Guide','Hello Anne,\n\nThanks for the quick response. I agree with you that xinclude statements are probably the best way to approximate topic-based writing and provide one avenue to leverage the re-use of content/files. Therefore I will take your advice and plan to continue the restructuring of the Networking Guide based on the use of xinclude statements.\n\nIf you have any other sage advice, can you please share. I am new to OpenStack and would appreciate any helpful hints.\n\nThanks again, Elke\n \nElke Vorheis\n(650) 291-1375 (cell)\nelkev at yahoo.com (email)\n\n\nOn Monday, October 20, 2014 10:13 AM, Anne Gentle <anne at openstack.org> wrote:\n \n\n\nThanks for asking on the list Elke. It\'s not really my decision, but we do like to work in similar ways, and it helps the core reviewers (there are about a dozen of us active) know how to review your patches. So the mailing list is best, thanks.\n\nGenerally speaking, yes, we want to move towards a topic-oriented model, and the xi:include chunking lets us do that. \n\nThanks,\nAnne\n\n\nOn Mon, Oct 20, 2014 at 11:36 AM, Elke Vorheis <elkev at yahoo.com> wrote:\n\nHello Anne,\n>\n>\n>I am the new writer for the Networking Guide. Last week I finally started to work on the Networking Guide. It looks like the \"chunks\" of content that essentially make up the equivalent of a topic (and subtopics) are all separated via xinclude statements instead of being directly included in the chapter file as a section. I therefore assumed that this method was supposed to be followed with respect to all future modifications, deletions, and additions for this document.\n>\n>\n>However, when I raised this issue with the small group of folks I work with, they indicated that i should get in touch with you to see if this structure of having xinclude statements that basically represent topics is the chosen method that I should follow in the future for this document?\n>\n>\n>Since I am a newbie to OpenStack, please let me know if this is the appropriate method of communicating with you.\n>\n>\n>Regards and thanks,\n> \n>Elke Vorheis\n>(650) 291-1375 (cell)\n>elkev at yahoo.com (email)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141020/f2c918e0/attachment-0001.html>\n\n','<CAD0KtVGJrvqJEL0-WaCOn__R7z5i_2CFoB3GyJM1JkB17nvTOw@mail.gmail.com>',NULL),('<1413831047.85372467@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-10-20 13:50:47',-18000,'2014-10-20 18:50:47',NULL,'[openstack-community] Can you help staff the OpenStack booth at USENIX LISA, Nov 12-13?','\nHi everyone,  [ USENIX LISA ]( https://www.usenix.org/conference/lisa14 ) (Large Installation System Administration Conference) is coming up November 9-14 in Seattle, WA.  Yes, it\'s the week after the Paris Summit! 1000+ sysadmins, DevOps, architects, software engineers, and more will attend. OpenStack is a silver sponsor and a premier exhibitor.  We have a limited number of full conference passes to offer to experienced OpenStack operators, architects and developers who would like to help staff our booth to talk to the attendees about OpenStack - and attend sessions.\n \nThe no-charge passes cover the main conference program, meals, and evening events Wednesday-Friday, Nov 12-14.  The booth is open for staffing Wed., Nov 12 from 12-7pm and Thurs., Nov 13 from 10am-2pm.  \n \nPlease reply with your role in your company.  We\'ll confirm technical candidates on a first-come, first-served basis.  If/when we run out of full conference passes, we have expo passes to offer.  \n \nOther OpenStack activities at LISA:\nHalf day training on Monday, Nov. 10 by Mirantis (fee applies)\nDreamhost providing OpenStack-based virtual machines to LISA Lab\nOpenStack demo on Thursday, Nov. 13 by Canonical\nThank you for your support!\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141020/a9eb90f4/attachment.html>\n\n',NULL,NULL),('<1413866845.50.1369895844399.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-30 06:37:24',0,'2013-05-30 06:37:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #50','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/50/changes>\n\nChanges:\n\n[Gary Kotton] Add support for dnsmasq version 2.48\n\n[Gary Kotton] Add l3 attribute to network\n\n------------------------------------------\n[...truncated 4973 lines...]\nTestABCDriver\n    test_get_device_name                                         OK    0.00\n    test_l3_init                                                 OK    0.01\nTestBridgeInterfaceDriver\n    test_get_device_name                                         OK    0.00\n    test_plug_dev_exists                                         OK    0.01\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    0.01\n    test_unplug                                                  OK    0.01\n    test_unplug_no_device                                        OK    0.01\nTestMetaInterfaceDriver\n    test_get_device_plugin_tag                                   OK    0.01\n    test_get_driver_by_network_id                                OK    0.01\n    test_set_device_plugin_tag                                   OK    0.01\nTestOVSInterfaceDriver\n    test_get_device_name                                         OK    0.00\n    test_plug_alt_bridge                                         OK    0.01\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    2.11\n    test_unplug                                                  OK    0.01\nTestOVSInterfaceDriverWithVeth\n    test_get_device_name                                         OK    0.00\n    test_plug_alt_bridge                                         OK    0.01\n    test_plug_mtu                                                OK    0.01\n    test_plug_no_ns                                              OK    0.01\n    test_plug_with_ns                                            OK    0.01\n    test_plug_with_prefix                                        OK    0.01\n    test_unplug                                                  OK    0.01\nTestDeviceExists\n    test_device_does_not_exist                                   OK    0.00\n    test_device_exists                                           OK    0.00\nTestIPCommandBase\n    test_as_root                                                 OK    0.00\n    test_as_root_with_options                                    OK    0.00\n    test_run                                                     OK    0.00\n    test_run_with_options                                        OK    0.00\nTestIPDevice\n    test_eq_diff_name                                            OK    0.00\n    test_eq_diff_namespace                                       OK    0.00\n    test_eq_other_is_none                                        OK    0.00\n    test_eq_same_name                                            OK    0.00\n    test_eq_same_namespace                                       OK    0.00\n    test_str                                                     OK    0.00\nTestIPDeviceCommandBase\n    test_name_property                                           OK    0.00\nTestIpAddrCommand\n    test_add_address                                             OK    0.00\n    test_add_address_scoped                                      OK    0.00\n    test_del_address                                             OK    0.00\n    test_flush                                                   OK    0.00\n    test_list                                                    OK    0.00\n    test_list_filtered                                           OK    0.00\nTestIpLinkCommand\n    test_address_property                                        OK    0.00\n    test_alias_property                                          OK    0.00\n    test_delete                                                  OK    0.00\n    test_mtu_property                                            OK    0.00\n    test_qdisc_property                                          OK    0.00\n    test_qlen_property                                           OK    0.00\n    test_set_address                                             OK    0.00\n    test_set_alias                                               OK    0.00\n    test_set_down                                                OK    0.00\n    test_set_mtu                                                 OK    0.00\n    test_set_name                                                OK    0.00\n    test_set_netns                                               OK    0.00\n    test_set_up                                                  OK    0.00\n    test_settings_property                                       OK    0.00\n    test_state_property                                          OK    0.00\nTestIpNetnsCommand\n    test_add_namespace                                           OK    0.00\n    test_delete_namespace                                        OK    0.00\n    test_execute                                                 OK    0.00\n    test_execute_env_var_prepend                                 OK    0.00\n    test_namespace_doest_not_exist                               OK    0.01\n    test_namespace_exists                                        OK    0.00\nTestIpRouteCommand\n    test_add_gateway                                             OK    0.00\n    test_del_gateway                                             OK    0.00\n    test_get_gateway                                             OK    0.00\n    test_pullup_route                                            OK    0.00\n    test_pullup_route_first                                      OK    0.00\nTestIpWrapper\n    test_add_device_to_namespace                                 OK    0.00\n    test_add_device_to_namespace_is_none                         OK    0.00\n    test_add_tuntap                                              OK    0.00\n    test_add_veth                                                OK    0.00\n    test_add_veth_with_namespaces                                OK    0.00\n    test_ensure_namespace                                        OK    0.01\n    test_ensure_namespace_existing                               OK    0.01\n    test_garbage_collect_namespace_does_not_exist                OK    0.00\n    test_garbage_collect_namespace_existing_empty_ns             OK    0.01\n    test_garbage_collect_namespace_existing_not_empty            OK    0.01\n    test_get_device                                              OK    0.00\n    test_get_devices                                             OK    0.01\n    test_get_devices_malformed_line                              OK    0.00\n    test_get_namespaces                                          OK    0.00\n    test_namespace_is_empty                                      OK    0.00\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.10\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.05\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.05\n    test_pool_stats                                              OK    2.29\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.07\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    2.33\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.00\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.00\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.01\n    test_init_exists                                             OK    0.01\n    test_init_exists_unlink_fails_file_still_exists              OK    0.01\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.01\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.31\n    test_show_quotas_with_admin                                  Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.uMbjO4rMh2\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/50\n[SCP] Copying console log.\n\n\n','<1992662602.47.1369809451734.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1413910082-sup-3133@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-21 12:08:10',-18000,'2014-10-21 17:08:10',NULL,'[openstack-dev] [Ironic] [Triple-O] Openstack Onboarding','Excerpts from Adam Lawson\'s message of 2014-10-20 18:47:36 -0500:\n> I made a similar comment to the Triple-O design summmit etherpad in hopes\n> others have a similar interest in Kilo but I wanted to share evangelize my\n> thoughts with the community for discussion:\n> \n> For better or for worse, one thing I\'ve heard over and over is how\n> Openstack community/TC approves/prefers the use of TripleO and Ironic to\n> deploy Openstack on bare metal. Cool, but for the majority of users\n> considering using Openstack in their organization, the question always goes\n> back to: If I\'m not savvy enough yet to install Openstack without these\n> tools, how do I setup TripleO and Ironic? Seems like a chien and egg thing.\n> \n> There has not been much discussion (that I\'ve noticed) re making a\n> deployment process easy to erect. That should be the easy part but it\'s as\n> confusing as the second part for most who are starting out. Using Openstack\n> to deploy Openstack means the installer method should be straight forward\n> and itself should be easy to install for users with limited understanding\n> of Openstack or the tooling methods used by OOO and Ironic. But the bar to\n> use Openstack continues to be a relatively-high engineering hurdle. It\n> always has been and I\'d love to see that change in the next cycle.\n> \n> Something that comes to mind:\n> \n>    - Setup Process Definition\n>    - Quickstart Wizards\n>    - Tooling\n> \n> The above may seem to be dumbing down the process but widespread Openstack\n> adoption requires an easy on-boarding process and so far, it simply doesn\'t\n> exist.\n\nYou\'re so right, we do need that.\n\nAnd it is something we\'ve talked about a lot amongst ourselves, but we\nclearly haven\'t publicized it.\n\nBasically what you described is what Tuskar is intended to be.\n\nThe basic idea for a TripleO install remains the same as when we first\ndefined it:\n\n* Boot a seed VM on a machine physically attached to the provisioning\n  network. Seed VM is an Ironic based single machine OpenStack.\n\n* Inform the seed\'s Ironic about the first real machine you want it to\n  deploy as a deployment cloud (aka \"undercloud\") machine.\n\n* Deploy first deployment cloud machine.\n\n* Shut down the seed. [1]\n\n* Inform deployment cloud of inventory for all hardware.\n\n* Deploy the user cloud (aka \"overcloud\")\n\nSo Tuskar would be a part of that deployment cloud, and would ask you\nthings about your hardware, your desired configuration, and help you\nget the inventory loaded.\n\nSo, ideally our gate would leave the images we test as part of the\nartifacts for build, and we could just distribute those as part of each\nrelease. That probably wouldn\'t be too hard to do, but those images\naren\'t exactly small so I would want to have some kind of strategy for\ndistributing them and limiting the unique images users are exposed to so\nwe\'re not encouraging people to run CD by downloading each commit\'s image.\n\nThere\'s also, I think, an interesting shift coming that the Kolla project\nis investigating, which is that perhaps what we should distribute is\ndocker images, not qcow2\'s. That idea is still pretty new, but we should\ndefinitely think about how that might be better for everyone.\n\n[1] We don\'t do this now because there is still some interdependency\nbetween seed and undercloud. We\'re working on it.\n\n\n','<CAJfWK49iYw30L6L930tr+=wJuF+zYZejarO-RiBK0MhnBu-WCw@mail.gmail.com>',NULL),('<1413993967.88035701@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-10-22 11:06:07',-18000,'2014-10-22 16:06:07',NULL,'[openstack-community] Your company in the OpenStack Pavilion at\n	Gartner Data Center Conference','\nThere are 1-2 spots left in the OpenStack Pavilion at the [ Gartner Data Center Conference ]( http://www.gartner.com/technology/summits/na/data-center/ ), December 2-5, 2014 in Las Vegas.  This year\'s theme is a perfect fit for OpenStack and the ecosystem\'s products and services - Leading Infrastructure & Operations: Delivering New Levels of Innovation and Productivity!\n \nLast year, we found the leads very, very good. The cost for one kiosk is $15,000 US and includes the carpet, power, kiosk with locking counter, lead retrieval system/device, 1 booth staff pass and 1 full conference pass each.  We\'ll develop a piece of collateral with the participating members that describe the companies in the pavilion and market it via OpenStack communications channels. The Foundation is providing all the pavilion graphics, info counter, and more.  Extra costs for participating companies are\n- graphics\n- AV (optional)\n- Internet (no wireless in Expo Hall, so have to order wired line)\n- Shipping/drayage\n \nFeel free to forward this to others in your company.  Kindly reply to me directly if interested. Thank you.  \n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141022/b7051451/attachment.html>\n\n',NULL,NULL),('<1414010951.2981854.182169993.204E3760@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-22 13:49:11',-25200,'2014-10-22 20:49:11',NULL,'[openstack-dev] [api] API Workgroup git repository','It is a code change :) Everything is a code change around here. You will\nwant to update the projects.yaml file in openstack-infra/project-config\n[0]. If you add a \'homepage:\nhttps://wiki.openstack.org/wiki/API_Working_Group\' key value pair to the\napi-wg dict there the jeepyb tooling should update the project homepage\nin github for you. If it doesn\'t then we probably have a bug somewhere\nand that should be fixed.\n\n[0]\nhttps://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n287\n\nAll that said, we really try to downplay the importance of github as\nwell. It is a mirror for us, but it is a discoverable mirror so updating\nthe \'homepage\' is probably a reasonable thing to do.\n\nClark\n\nOn Wed, Oct 22, 2014, at 01:36 PM, Everett Toews wrote:\n> I notice at the top of the GitHub mirror page [1] it reads, \"API Working\n> Group http://openstack.org?\n> \n> Can we get that changed to \"API Working Group\n> https://wiki.openstack.org/wiki/API_Working_Group??\n> \n> That URL would be much more helpful to people who come across the GitHub\n> repo. It\'s not a code change so we would need a repo owner to actually\n> make the change. Who should I contact about that?\n> \n> Thanks,\n> Everett\n> \n> [1] https://github.com/openstack/api-wg/\n> \n> \n> On Oct 22, 2014, at 1:08 AM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:\n> \n> > Hi,\n> > \n> > The API Workgroup git repository has been setup and you can access it\n> > here.\n> > \n> > http://git.openstack.org/cgit/openstack/api-wg/\n> > \n> > There is some content there though not all the proposed guidelines from\n> > the wiki page are in yet:\n> > \n> > https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines\n> > \n> > Please feel free to start submitting patches to the document.\n> > \n> > I have submitted a patch to convert the initial content from markdown to\n> > rst and setup the tox targets to produce an html document. Seemed to be\n> > an easier route as it seems to be the preferred format for OpenStack\n> > projects and we can just copy all the build/check bits from the specs\n> > repositories. Also doesn\'t require any changes to required packages.\n> > \n> > https://review.openstack.org/130120\n> > \n> > Until this is merged its probably better to base any patches on this\n> > one.\n> > \n> > Chris\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<4793C6F1-41B8-4CCA-98F2-7BE78A414D27@rackspace.com>',NULL),('<1414081638-sup-9315@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-23 09:36:59',-25200,'2014-10-23 16:36:59',NULL,'[Openstack] [Tripleo][Ironic] How does overcloud get route\n	169.254.169.254','Excerpts from ??\'s message of 2014-10-23 01:08:09 -0700:\n> Hi, All:\n>         I recently deployed an Overcloud machine using Undercloud. And when\n> login to the overcloud . It has the following route:\n> stack at undercloud002-undercloud-xjjnlfe5guan:~$ route -n\n> Kernel IP routing table\n> Destination     Gateway         Genmask         Flags Metric Ref    Use\n> Iface\n> 0.0.0.0         192.0.2.1       0.0.0.0         UG    0      0        0 eth5\n> *169.254.169.254 192.0.2.1       255.255.255.255 UGH   0      0        0\n> eth5*\n> 192.0.2.0       0.0.0.0         255.255.255.0   U     0      0        0 eth5\n>        I wonder who wrote the *169.254.169.254 *route and when did it\n> happened ? It is build in the image or otherwise ?\n> \n\nDHCP allows pushing static routes via option 21. So we push said route\nvia DHCP. This is a built-in feature of Neutron.\n\n\n','<CALAMvO9CfLMy2RSOgzNBkg45516qm+VFMbp5SQkVq_S+gOzRLw@mail.gmail.com>',NULL),('<1414081804.3248.2.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-23 11:30:04',-18000,'2014-10-23 16:30:04',NULL,'[openstack-dev] [oslo] python 2.6 support for oslo libraries','On Thu, 2014-10-23 at 18:56 +0300, Andrey Kurilin wrote:\n> Just a joke: Can we drop supporting Python 2.6, when several project\n> still have hooks for Python 2.4?\n> \n> https://github.com/openstack/python-novaclient/blob/master/novaclient/exceptions.py#L195-L203\n> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/exceptions.py#L147-L155\n\nIt may have been intended as a joke, but it\'s worth pointing out that\nthe Xen plugins for nova (at least) have to be compatible with Python\n2.4, because they run on the Xenserver, which has an antiquated Python\ninstalled :)\n\nAs for the clients, we could probably drop that segment now; it\'s not\nlike we *test* against 2.4, right?  :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAEVmkazeHnaSt0F81bL2xtim_SV4Go=xCDkaqLhD8fC7PnQRhw@mail.gmail.com>',NULL),('<1414083820.893211386@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-10-23 12:03:40',-18000,'2014-10-23 17:03:40',NULL,'[openstack-community] MEF Requests OpenStack Speaker for GEN14\n	Breakfast, Nov. 19 in Washington DC','\nThe [ MEF (Metro Ethernet Forum) ]( https://metroethernetforum.org/ ) requests an OpenStack participant in the following session at their [ GEN14 ]( http://www.gen14.com/ ) conference.  It is a breakfast meeting 7:30-8:50am, Wednesday, November 19, at the Gaylord National Resort and Convention Center, Washington DC. Please contact Rami Yaron,  [ rami at metroethernet.org ]( mailto:rami at metroethernet.org ) if interested in representing the OpenStack Foundation at this breakfast.  \n \nMany OpenStack members are already speaking.  If you work with them, please inform them so they may also convey the OpenStack message.  Thank you.\n \nStandards Update Breakfast - Network Technology Building Blocks Enabling Higher-Value Cloud-Centric Services\n \nChair: Stan Hubbard, GEN14 Program Director  |  Ralph Santitoro, Director of Solutions Planning - Emerging Markets, Fujitsu Network Communications, Board, MEF  | Nicolas \"Neela\" Jacques, Executive Director, OpenDaylight  |  Mehmet Toy, Distinguished Engineer, Comcast; Board, CloudEthernet Forum; Co-Chair of CEF\'s Architecture Working Group; Chair, IEEE Cable Networks & Services Committee  | Marc Cohn, Senior Director, Market Development, Ciena; Chairman, Market Education Committee, ONF; Board, OpenDaylight |  Scott Mansfield, Principal Engineer, Ericsson; Board, MEF - Perspective on IETF & ITU-T Initiatives\n\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141023/2b695149/attachment.html>\n\n',NULL,NULL),('<1414101554.3248.9.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-23 16:59:14',-18000,'2014-10-23 21:59:14',NULL,'[openstack-dev] [oslo] python 2.6 support for oslo libraries','On Thu, 2014-10-23 at 17:19 -0400, Doug Hellmann wrote:\n> I?m not aware of any Oslo code that presents a problem for those\n> plugins. We wouldn?t want to cause a problem, but as you say, we don?t\n> have anywhere to test 2.4 code. Do you know if the Xen driver uses any\n> of the Oslo code?\n\nI missed the [oslo] tag in the subject line and was thinking generally;\nso no, none of the Xen plugins use anything from oslo, because of the\nneed to support 2.4.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<0ACF3416-3C73-4DAD-9CB6-7C85B3BE6EE2@doughellmann.com>',NULL),('<1414110694.663282.182680869.55D330E8@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-23 17:31:34',-25200,'2014-10-24 00:31:34',NULL,'[openstack-dev] Deprecation of Python 2.6 CI Testing','Hello,\n\nAt the Atlanta summit there was a session on removing python2.6\ntesting/support from the OpenStack Kilo release [0]. The Infra team is\nworking on enacting this change in the near future.\n\nThe way that this will work is python26 jobs will be removed from\nrunning on master and feature branches of projects that have\nstable/icehouse and/or stable/juno branches. The python26 jobs will\nstill continue to run against the stable branches. Any project that is a\nlibrary consumed by stable releases but does not have stable branches\nwill have python26 run against that project\'s master branch. This is\nnecessary to ensure we don\'t break backward compatibility with stable\nreleases.\n\nThis essentially boils down to: no python26 jobs against server project\nmaster branches, but python26 jobs continue to run against stable\nbranches. Python-*client and oslo projects[1] will continue to have\npython26 jobs run against their master branches. All other projects will\nhave python26 jobs completely removed (including stackforge).\n\nIf you are a project slated to have python26 removed and would prefer to\ncontinue testing python26 that is doable, but we ask that you propose a\nchange atop the removal change [2] that adds python26 back to your\nproject. This way it is clear through git history and review that this\nis a desired state. Also, this serves as a warning to the future where\nwe will drop all python26 jobs when stable/juno is no longer supported.\nAt that point we will stop building slaves capable of running python26\njobs.\n\nRough timeline for making these changes is early next week for OpenStack\nprojects. Then at the end of November (November 30th) we will make the \nchanges to stackforge. This should give us plenty of time to work out \nwhich stackforge projects wish to continue testing python26.\n\n[0] https://etherpad.openstack.org/p/juno-cross-project-future-of-python\n[1]\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-October/048999.html\n[2] https://review.openstack.org/129434\n\nLet me or the Infra team know if you have any questions,\nClark\n\n\n',NULL,NULL),('<1414163129.530814.182904789.6E27EEB0@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-24 09:05:29',-21600,'2014-10-24 15:05:29',NULL,'[openstack-dev] [Glance][Cinder] The sorry state of cinder\'s\n driver in Glance','\n\nOn Fri, Oct 24, 2014, at 07:59 AM, Flavio Percoco wrote:\n> On 10/24/2014 03:29 PM, Mike Perez wrote:\n> > On 09:11 Thu 23 Oct     , Flavio Percoco wrote:\n> >> According to the use-cases explained in this thread (also in the emails\n> >> from John and Mathieu) this is something that\'d be good having. I\'m\n> >> looking forward to seeing the driver completed.\n> >>\n> >> As John mentioned in his email, we should probably sync again in K-1 to\n> >> see if there\'s been some progress on the bricks side and the other\n> >> things this driver depends on. If there hasn\'t, we should probably get\n> >> rid of it and add it back once it can actually be full-featured.\n> > \n> > I\'m unsure if Brick [1] will be completed in time. With that in mind, even if\n> > we were to deprecate the glance driver for Kilo, Brick will likely be done by\n> > then and we would just be removing the deprecation in L, assuming the driver is\n> > completed in L. I think that would be confusing to users. It\'s unfortunate this\n> > was merged in the current state, but I would just say leave things as is with\n> > intentions at the latest to have the driver completed in L. If we\'re afraid no\n> > one is going to complete the driver, deprecate it now.\n> > \n> > [1] - https://github.com/hemna/cinder-brick\n> \n> Thanks, Mike. This is great feedback.\n> \n> I wonder how strong is the dependency between the cinder driver and\n> bricks. I mean, it\'d be cool if we could complete the implementation in\n> a perhaps not so optimized way - on top of cinder\'s API? - and then use\n> the bricks library when it\'s done.\n\nI fear my mention of Brick may have thrown things out of whack here. \nFrankly for now I think that whole thing should be ignored as it\npertains to this topic.  We\'ve made the mistake of deferring things\nbased on that whole idea in the past and it hasn\'t gone well. \n\nGlance shouldn\'t need most of the stuff that\'s going on in there anyway\nI don\'t think.  I think Flavio keyed in on the main point IMO \"how\nstrong of a dependency\", ideally I hope the answer is \"not very\".  The\nother thing about this is my conversations with folks in the past were\nthat Glance should be kept pretty darn light in terms of any data path\ntype stuff.  We really should intend for it to be not much more than a\nregistry and serve as a conduit.  If that\'s changed or I\'m wrong on that\nfeel free to shout, but previous conversations with Mark suggested that\nmoving things like initiators and targets in to Glance was not ideal\n(and I agree). \n\n> \n> Thoughts on the above? It sounds hacky, I know. :)\n\nYes, please, let\'s move forward with it like we were saying earlier. \nThere\'s still a number of gaps and some hand waving I think so really\nit\'s something I think we just need to dive into.\n\n> \n> Cheers,\n> Flavio\n> \n> -- \n> @flaper87\n> Flavio Percoco\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<544A5B3E.2070006@redhat.com>',NULL),('<1414187275.3846.21.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-24 21:47:13',0,'2014-10-24 21:47:13',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Octavia\'s API becoming\n spun out LBaaS','With the recent talk about advanced services spinning out of Neutron,\nand the fact most of the LBaaS community has wanted LBaaS to spin out of\nNeutron, I wanted to bring up a possibility and gauge interest and\nopinion on this possibility.\n\nOctavia is going to (and has) an API.  The current thinking is that an\nOctavia driver will be created in Neutron LBaaS that will make a\nrequests to the Octavia API.  When LBaaS spins out of Neutron, it will\nneed a standalone API.  Octavia\'s API seems to be a good solution to\nthis.  It will support vendor drivers much like the current Neutron\nLBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an\nexact duplicate.  Octavia will be growing more mature in stackforge at a\nhigher velocity than an Openstack project, so I expect by the time Kilo\ncomes around it\'s API will be very mature.\n\nOctavia\'s API doesn\'t have to be called Octavia either.  It can be\nseparated out and it can be called Openstack LBaaS, and the rest of\nOctavia (the actual brains of it) will just be another driver to\nOpenstack LBaaS, which would retain the Octavia name.\n\nThis is my PROS and CONS list to using Octavia\'s API as the spun out\nLBaaS:\n\nPROS\n1. Time will need to be spent on a spun out LBaaS\'s API anyway.  Octavia\nwill already have this done.\n2. Most of the same people working on Octavia have worked on Neutron\nLBaaS v2.\n3. It\'s out of Neutron faster, which is good for Neutron and LBaaS.\n\nCONS\n1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet\nanother version of an LBaaS API.\n2. The Octavia API will also have a separate Operator API which will\nmost likely only work with Octavia, not any vendors.\n\nThe CONS are easily solvable, and IMHO the PROS greatly outweigh the\nCONS.\n\nThis is just my opinion though and I\'d like to hear back from as many as\npossible.  Add on to the PROS and CONS if wanted.\n\nIf it is direction we can agree on going then we can add as a talking\npoint in the advanced services spin out meeting:\n\nhttp://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VEq66HWx3UY\n\nThanks,\nBrandon\n\n','<CAAGw+Zri9RxeCCMbGZY9uokPqtpP91hPV9YPgMjgsRsoXV=XPA@mail.gmail.com>',NULL),('<1414226607.14.1381817488300.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-15 06:11:28',0,'2013-10-15 06:11:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #31','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/31/changes>\n\nChanges:\n\n[zhiyanl] Adding \'download_image\' policy enforcement to image cache middleware\n\n------------------------------------------\n[...truncated 954 lines...]\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.02\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.02\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.20\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.02\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: \n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, None\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 71.47 secs:\n    15.57    TestGlanceControl.test_bouncing\n    14.23    TestGlanceControl.test_reload\n    14.01    TestGlanceControl.test_respawn\n    13.87    TestBinGlanceCacheManage.test_queue\n    13.80    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 932 tests in 602.486s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-31\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=96\n+ \'[\' 96 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.zNu4dtb2PY\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/31/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-10/31\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1414283194-sup-9981@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-25 17:35:04',-25200,'2014-10-26 00:35:04',NULL,'[openstack-dev] [Heat] Convergence prototyping','Excerpts from Zane Bitter\'s message of 2014-10-23 11:10:29 -0700:\n> Hi folks,\n> I\'ve been looking at the convergence stuff, and become a bit concerned \n> that we\'re more or less flying blind (or at least I have been) in trying \n> to figure out the design, and also that some of the first implementation \n> efforts seem to be around the stuff that is _most_ expensive to change \n> (e.g. database schemata).\n> \n> What we really want is to experiment on stuff that is cheap to change \n> with a view to figuring out the big picture without having to iterate on \n> the expensive stuff. To that end, I started last week to write a little \n> prototype system to demonstrate the concepts of convergence. (Note that \n> none of this code is intended to end up in Heat!) You can find the code \n> here:\n> \n> https://github.com/zaneb/heat-convergence-prototype\n> \n> Note that this is a *very* early prototype. At the moment it can create \n> resources, and not much else. I plan to continue working on it to \n> implement updates and so forth. My hope is that we can develop a test \n> framework and scenarios around this that can eventually be transplanted \n> into Heat\'s functional tests. So the prototype code is throwaway, but \n> the tests we might write against it in future should be useful.\n> \n> I\'d like to encourage anyone who needs to figure out any part of the \n> design of convergence to fork the repo and try out some alternatives - \n> it should be very lightweight to do so. I will also entertain pull \n> requests (though I see my branch primarily as a vehicle for my own \n> learning at this early stage, so if you want to go in a different \n> direction it may be best to do so on your own branch), and the issue \n> tracker is enabled if there is something you want to track.\n> \n> I have learned a bunch of stuff already:\n> \n> * The proposed spec for persisting the dependency graph \n> (https://review.openstack.org/#/c/123749/1) is really well done. Kudos \n> to Anant and the other folks who had input to it. I have left comments \n> based on what I learned so far from trying it out.\n> \n> \n> * We should isolate the problem of merging two branches of execution \n> (i.e. knowing when to trigger a check on one resource that depends on \n> multiple others). Either in a library (like taskflow) or just a separate \n> database table (like my current prototype). Baking it into the \n> orchestration algorithms (e.g. by marking nodes in the dependency graph) \n> would be a colossal mistake IMHO.\n> \n> \n> * Our overarching plan is backwards.\n> \n> There are two quite separable parts to this architecture - the worker \n> and the observer. Up until now, we have been assuming that implementing \n> the observer would be the first step. Originally we thought that this \n> would give us the best incremental benefits. At the mid-cycle meetup we \n> came to the conclusion that there were actually no real incremental \n> benefits to be had until everything was close to completion. I am now of \n> the opinion that we had it exactly backwards - the observer \n> implementation should come last. That will allow us to deliver \n> incremental benefits from the observer sooner.\n> \n> The problem with the observer is that it requires new plugins. (That \n> sucks BTW, because a lot of the value of Heat is in having all of these \n> tested, working plugins. I\'d love it if we could take the opportunity to \n> design a plugin framework such that plugins would require much less \n> custom code, but it looks like a really hard job.) Basically this means \n> that convergence would be stalled until we could rewrite all the \n> plugins. I think it\'s much better to implement a first stage that can \n> work with existing plugins *or* the new ones we\'ll eventually have with \n> the observer. That allows us to get some benefits soon and further \n> incremental benefits as we convert plugins one at a time. It should also \n> mean a transition period (possibly with a performance penalty) for \n> existing plugin authors, and for things like HARestarter (can we please \n> please deprecate it now?).\n> \n> So the two phases I\'m proposing are:\n>   1. (Workers) Distribute tasks for individual resources among workers; \n> implement update-during-update (no more locking).\n>   2. (Observers) Compare against real-world values instead of template \n> values to determine when updates are needed. Make use of notifications \n> and such.\n> \n> I believe it\'s quite realistic to aim to get #1 done for Kilo. There \n> could also be a phase 1.5, where we use the existing stack-check \n> mechanism to detect the most egregious divergences between template and \n> reality (e.g. whole resource is missing should be easy-ish). I think \n> this means that we could have a feasible Autoscaling API for Kilo if \n> folks step up to work on it - and in any case now is the time to start \n> on that to avoid it being delayed more than it needs to be based purely \n> on the availability of underlying features. That\'s why I proposed a \n> session on Autoscaling for the design summit.\n> \n> \n> * This thing is going to _hammer_ the database\n> \n> The advantage is that we\'ll be able to spread the access across an \n> arbitrary number of workers, but it\'s still going to be brutal because \n> there\'s only one database. We\'ll need to work hard to keep DB access to \n> the minimum we can.\n> \n\nI think it will just hammer the DB in different ways from the current\nimplementation. Currently, one must do a _lot_ of queries to parse a\nstack. And to do almost any operation, one ends up parsing the stack.\n\nConversely, with everything being resource oriented, while operations\nwill do more DB queries and transactions, they\'ll be smaller and more\nlike single key reads/writes.\n\nAlso, the new design will lend itself toward sharding by resource,\nsince only the stack\'s graph will need to be related to other resources\nand thus on a single DB. But that is _way_ down the road. I think with a\nmodest sized database server/cluster one can likely run tens of thousands\nof concurrent tiny reads/writes per second.\n\n\n','<54494495.20702@redhat.com>',NULL),('<1414340295-sup-5599@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-26 17:01:07',-25200,'2014-10-27 00:01:07',NULL,'[openstack-dev] [all] Key signing at the summit?','Hi everyone! We have a summit rapidly approaching, and to my knowledge,\nno key signing event planned. That is unfortunate, as the web of trust\nthat we started building in Atlanta would be quite stronger as we add\nmore European developers who I\'m sure will be present in large numbers\ndue to proximity.\n\nI believe we may be too late to do a mass keysigning, though if others\nfeel we have time to gather fingerprints and disseminate a list for\nprinting, then I will try to devote some time to it in the next 24\nhours. However, I want to encourage everyone to print out your signature\nen-masse (hint hint: print it on your business cards) so that you can\ndo an impromptu verification of identity with somebody. It may also be\nvaluable to arrange a time where everyone can be present with their\ngovernment issued IDs even if there isn\'t a mass list.\n\n\n',NULL,NULL),('<1414370148.3819.9.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 00:35:48',0,'2014-10-27 00:35:48',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Octavia\'s API\n becoming spun out LBaaS','Good questions Doug.  My answers are as follows:\n\n1. Yes\n2. Some time after Kilo (same as I don\'t know when)\n3. The main reason a spin out makes sense from Neutron is that the scope\nfor Neutron is too large for the attention advances services needs from\nthe Neutron Core.  If all of advanced services spins out, I see that\nrepeating itself within an advanced services project.  More and more\n\"advanced services\" will get added in and the scope will become too\nlarge.  There would definitely be benefits to it though, but I think we\nwould end up being right where we are today.\n4. I brought this up now so that we can decide whether we want to\ndiscuss it at the advanced services spin out session.  I don\'t see the\nharm in opinions being discussed before the summit, during the summit,\nand more thoroughly after the summit.\n\nYes the brunt of the time will not be spent on the API, but since it\nseemed like an opportunity to kill two birds with one stone, I figured\nit warranted a discussion.\n\nThanks,\nBrandon\n\nOn Sun, 2014-10-26 at 23:15 +0000, Doug Wiegley wrote:\n> Hi all,\n> \n> Before we get into the details of which API goes where, I?d like to see us\n> answer the questions of:\n> \n> 1. Are we spinning out?\n> 2. When?\n> 3. With or without the rest of advanced services?\n> 4. Do we want to wait until we (the royal ?we? of ?the Neutron team?) have\n> had the Paris summit discussions on vendor split-out and adv. services\n> spinout before we answer those questions?  (Yes, that question is leading.)\n> \n> To me, the ?where does the API live? is an implementation detail, and not\n> where the time will need to be spent.\n> \n> For the record, my answers are:\n> \n> 1. Yes.\n> 2. I don?t know.\n> 3. I don?t know; this needs some serious discussion.\n> 4. Yes.\n> \n> Thanks,\n> doug\n> \n> On 10/24/14, 3:47 PM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM> wrote:\n> \n> >With the recent talk about advanced services spinning out of Neutron,\n> >and the fact most of the LBaaS community has wanted LBaaS to spin out of\n> >Neutron, I wanted to bring up a possibility and gauge interest and\n> >opinion on this possibility.\n> >\n> >Octavia is going to (and has) an API.  The current thinking is that an\n> >Octavia driver will be created in Neutron LBaaS that will make a\n> >requests to the Octavia API.  When LBaaS spins out of Neutron, it will\n> >need a standalone API.  Octavia\'s API seems to be a good solution to\n> >this.  It will support vendor drivers much like the current Neutron\n> >LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not an\n> >exact duplicate.  Octavia will be growing more mature in stackforge at a\n> >higher velocity than an Openstack project, so I expect by the time Kilo\n> >comes around it\'s API will be very mature.\n> >\n> >Octavia\'s API doesn\'t have to be called Octavia either.  It can be\n> >separated out and it can be called Openstack LBaaS, and the rest of\n> >Octavia (the actual brains of it) will just be another driver to\n> >Openstack LBaaS, which would retain the Octavia name.\n> >\n> >This is my PROS and CONS list to using Octavia\'s API as the spun out\n> >LBaaS:\n> >\n> >PROS\n> >1. Time will need to be spent on a spun out LBaaS\'s API anyway.  Octavia\n> >will already have this done.\n> >2. Most of the same people working on Octavia have worked on Neutron\n> >LBaaS v2.\n> >3. It\'s out of Neutron faster, which is good for Neutron and LBaaS.\n> >\n> >CONS\n> >1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be yet\n> >another version of an LBaaS API.\n> >2. The Octavia API will also have a separate Operator API which will\n> >most likely only work with Octavia, not any vendors.\n> >\n> >The CONS are easily solvable, and IMHO the PROS greatly outweigh the\n> >CONS.\n> >\n> >This is just my opinion though and I\'d like to hear back from as many as\n> >possible.  Add on to the PROS and CONS if wanted.\n> >\n> >If it is direction we can agree on going then we can add as a talking\n> >point in the advanced services spin out meeting:\n> >\n> >http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.\n> >VEq66HWx3UY\n> >\n> >Thanks,\n> >Brandon\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D072DAD6.12E32%dougw@a10networks.com>',NULL),('<1414390025.2579979.183620317.39B28EC8@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-26 23:07:05',-25200,'2014-10-27 06:07:05',NULL,'[openstack-dev] [all] Key signing at the summit?','On Sun, Oct 26, 2014, at 17:01, Clint Byrum wrote:\n> I believe we may be too late to do a mass keysigning, though if others\n> feel we have time to gather fingerprints and disseminate a list for\n> printing, then I will try to devote some time to it in the next 24\n> hours. However, I want to encourage everyone to print out your signature\n> en-masse (hint hint: print it on your business cards) so that you can\n> do an impromptu verification of identity with somebody. It may also be\n> valuable to arrange a time where everyone can be present with their\n> government issued IDs even if there isn\'t a mass list.\n\nI will be offering to give out my personal card, which has my gpg\nfingerprint printed on it.\n\nI will also try to get more keybase.io invites, for those who want them.\n keybase.io is a web service that provides an independently provable\nbinding between your social media and github identities, and your gpg\nkey.\n\npub   4096R/62CCC1E5 2014-03-30 [expires: 2018-03-29]\n      Key fingerprint = 4F48 0261 701C B81F B003  3401 7322 9172 62CC\n      C1E5\nuid                  Mark Atwood <me at mark.atwood.name>\nuid                  Mark Atwood <mark.atwood at hp.com>\n\n-- \nMark Atwood <me at mark.atwood.name>\n+1-206-604-2198\n\n\n\n','<1414340295-sup-5599@fewbar.com>',NULL),('<1414425511-sup-6429@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 09:00:42',-25200,'2014-10-27 16:00:42',NULL,'[openstack-dev] [heat][ceilometer]: scale up/ down based on\n	number of instances in a group','Excerpts from Daniel Comnea\'s message of 2014-10-27 04:16:32 -0700:\n> Yes i did but if you look at this example\n> \n> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml\n> \n> \n> the flow is simple:\n> \n> CPU alarm in Ceilometer triggers the \"type: OS::Heat::ScalingPolicy\" which\n> then triggers the \"type: OS::Heat::AutoScalingGroup\"\n> \n> \n> \n> Now what i want is to be able to always maintain a min number of instances\n> in my Group, if is min_size been reached than trigger HEAT to spun a new\n> one to be min_size + n\n> \n\nSounds like you\'re expecting Heat to respond to the stop/delete of one\nof the instances in the group.\n\nIt doesn\'t do that.. yet. There\'s a very large scale effort under way\ncalled \'convergence\' that will add such a capability to Heat (by having\nHeat try to assert that reality should match intention). Until then it\ndoesn\'t support this use case very well.\n\n\n','<CAOBAnZNFmdJv6HXar9i77DnLqrfRodxMkZq6kZ1cL+158xQ7VQ@mail.gmail.com>',NULL),('<1414429723-sup-7387@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 10:17:51',-25200,'2014-10-27 17:17:51',NULL,'[openstack-dev] [all] Key signing at the summit?','Excerpts from Jeremy Stanley\'s message of 2014-10-27 07:45:27 -0700:\n> On 2014-10-26 17:01:07 -0700 (-0700), Clint Byrum wrote:\n> > Hi everyone! We have a summit rapidly approaching, and to my knowledge,\n> > no key signing event planned. That is unfortunate, as the web of trust\n> > that we started building in Atlanta would be quite stronger as we add\n> > more European developers who I\'m sure will be present in large numbers\n> > due to proximity.\n> [...]\n> \n> I took the prior lack of discussion on the ML to imply interest in\n> repeating the exercise in an organized fashion was low. Those of us\n> who regularly engage in ad-hoc keysigning will likely already have\n> business cards or slips with full key fingerprints/names and\n> passports or similar ID with us already. Since the majority of the\n> OpenStack WoT is currently between release management, quality\n> assurance and project infrastructure teams, I proposed this is one\n> of the things which can go on quietly in the background over the\n> course of our shared meet-up on Friday.\n> \n\nOften it\'s not clear that one needs to dive into the WoT until two people\nare on opposite sides of the planet wanting to communicate in some secure\nfashion. Because of this, I feel a need to facilitate key signing even\nif there aren\'t that many who are excited about it.\n\nWe\'re short on time, and I think trying to push the full process will tax\ntoo many. I like the idea of ad-hoc keysigning quietly in the background,\nas that will also help educate people on how to grow their trust network\nthemselves, without just attending events like our signing party in\nAtlanta.\n\nUnless somebody else wants to gather the list of fingerprints and secure\na space for a larger meeting, I would just encourage everyone to bring\ncopies of your fingerprint and proof of your identity so that others can\nsign your key. If you\'re unsure of how to do this, I suggest you ask in\n#openstack-infra or directly ask any of us who you\'ve seen discussing\nkey signing in the past.\n\n> If there is interest in doing another Sassaman-Projected Method\n> exercise at future events, a USB document camera would be useful to\n> procure in advance (my earlier experiment with the digital\n> microscope worked well in the lab but was not so successful in the\n> wild since I ended up lacking a tall enough stand to properly\n> encompass larger IDs and so had to try some pretty hacky\n> workarounds). There is relatively inexpensive equipment on the\n> market which does this sort of thing well and is compact enough to\n> easily bring in luggage, I just don\'t happen to have anything like\n> that on hand currently.\n\nI thought it worked quite nicely, but I do think it stressed you out too\nmuch and we should look at securing a camera for mid-cycles and the\nnext summit.\n\n\n','<20141027144527.GD2497@yuggoth.org>',NULL),('<1414430560-sup-9530@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 10:30:47',-25200,'2014-10-27 17:30:47',NULL,'[openstack-dev] [TripleO] Summit scheduling - using our time\n	together wisely.','I\'m anxious to get titles for the scheduled sessions so that people can\nstart planning their daily schedules. I have heard some opinions about\nthe Neutron/Nova/Ironic work that needs to happen to support L3 (I think\nwe should still bring it up) and also a bit about Cinder HA. I think\nthese are things that will benefit from a f2f conversation with the\nOpenStack community at large.\n\nI also think that the biggest theme I see beyond that is UI/onboarding.\nSo I think we should split the 2 40 minute sessions into these two\nthings:\n\n\n* L3 Networking + Cinder HA\n - Summary of changes needed in Cinder/Neutron/Nova/Ironic/etc.\n - Configuration changes needed\n - UI changes\n\n* TripleO\'s onramp - All things new contributor\n - QuintupleO progress report\n - Tuskar progress report\n - Alternative implementations roll call\n   - Kolla\n   - Puppet\n   - Ansible\n\nThe rest of the things in the etherpad will make for a good agenda for\nFriday.\n\nDoes anyone have anything to add, or dissent to register?\n\nExcerpts from Clint Byrum\'s message of 2014-10-16 13:14:26 -0700:\n> The format has changed slightly this summit, to help encourage a more\n> collaborative design experience, rather than rapid fire mass-inclusion\n> summit sessions. So we have two 40-minute long slots, and one whole day\n> of contributor meetup.[1]\n> \n> Our etherpad topics page has received quite a few additions now [2], and\n> so I\'d like to hear thoughts on what things we want to talk about in the\n> meetup versus the sessions.\n> \n> A few things I think we should stipulate:\n> \n> * The scheduled sessions will be heavily attended by the community at\n>   large. This often includes those who are just curious, or those who\n>   want to make sure that their voice is heard. These sessions should be\n>   reserved for those topics which have the most external influence or\n>   are the most dependent on other projects.\n> \n> * The meetup will be at the end of the week so at the end of it, we\n>   can\'t then go to any other meetups and ask for things / participate\n>   in those design activities. This reinforces that scheduled session\n>   time should be focused on things that are externally focused so that\n>   we can take the result of those discussions into any of the sessions\n>   that are after.\n> \n> * The Ops Summit is Wendesday/Thursday [3], which overlaps with these\n>   sessions. I am keenly interested in gathering more contribution from\n>   those already operating and deploying OpenStack. It can go both ways,\n>   but I think it might make sense to have more ops-centric topics\n>   discussed on Friday, when those participants might not be fully\n>   wrapped up in the ops sessions.\n> \n> If we can all agree on those points, given the current topics, I think\n> our scheduled sessions should target at least (but not limited to):\n> \n> * Cinder + CEPH\n> * Layer 3 segmentation\n> \n> I think those might fit into 40 minutes, as long as we hash some things\n> out here on the mailing list first. Cinder + CEPH is really just a\n> check-in to make sure we\'re on track to providing it. Layer 3, I\'ve had\n> discussions with Ironic and Neutron people and I think we have a plan,\n> but I wanted to present it in the open and discuss the short term goals\n> to see if it satisfies what users may want for the Kilo time frame.\n> \n> So, I would encourage you all to look at the etherpad, and expand on\n> topics or add more, and then reply to this thread with ideas for how\n> best to use our precious time together.\n> \n> [1] http://kilodesignsummit.sched.org/overview/type/tripleo\n> [2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics\n> [3] http://kilodesignsummit.sched.org/overview/type/ops+summit\n\n\n','<1413488975-sup-1194@fewbar.com>',NULL),('<1414435153.3573.2.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 18:39:13',0,'2014-10-27 18:39:13',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Octavia\'s API\n becoming spun out LBaaS','Hi Jay,\nJust so you have some information on the API before the meeting here is\nthe spec for it:\n\nhttps://review.openstack.org/#/c/122338/\n\nI\'m sure there is a lot of details that might be missing but it should\ngive you a decent idea.  Sorry for the markup/markdown being dumb if you\ntry to build with spinx.  Probably easier to just read the raw .rst\nfile.\n\nThanks,\nBrandon\n\nOn Mon, 2014-10-27 at 14:05 -0400, Jay Pipes wrote:\n> Yup, can do! :)\n> \n> -jay\n> \n> On 10/27/2014 01:55 PM, Doug Wiegley wrote:\n> > Hi Jay,\n> >\n> > Let?s add that as an agenda item at our Weekly IRC meeting.  Can you make\n> > this timeslot?\n> >\n> > https://wiki.openstack.org/wiki/Octavia#Meetings\n> >\n> >\n> > Thanks,\n> > Doug\n> >\n> >\n> > On 10/27/14, 11:27 AM, \"Jay Pipes\" <jaypipes at gmail.com> wrote:\n> >\n> >> Sorry for top-posting, but where can the API working group see the\n> >> proposed Octavia API specification or documentation? I\'d love it if the\n> >> API WG could be involved in reviewing the public REST API.\n> >>\n> >> Best,\n> >> -jay\n> >>\n> >> On 10/27/2014 10:01 AM, Kyle Mestery wrote:\n> >>> On Sun, Oct 26, 2014 at 8:01 PM, Doug Wiegley <dougw at a10networks.com>\n> >>> wrote:\n> >>>> Hi Brandon,\n> >>>>\n> >>>>> 4. I brought this up now so that we can decide whether we want to\n> >>>>> discuss it at the advanced services spin out session.  I don\'t see the\n> >>>>> harm in opinions being discussed before the summit, during the summit,\n> >>>>> and more thoroughly after the summit.\n> >>>>\n> >>>> I agree with this sentiment.  I?d just like to pull-up to the decision\n> >>>> level, and if we can get some consensus on how we move forward, we can\n> >>>> bring a concrete plan to the summit instead of 40 minutes of Kumbaya.\n> >>>> We\n> >>>> love each other.  Check.  Things are going to change sometime.  Check.\n> >>>> We\n> >>>> might spin-out someday.  Check.  Now, let?s jump to the interesting\n> >>>> part.\n> >>>>\n> >>> I think we all know we want to spin these out, as Doug says we just\n> >>> need to have a plan around how we make that happen. I\'m in agreement\n> >>> with Doug\'s sentiment above.\n> >>>\n> >>>>> 3. The main reason a spin out makes sense from Neutron is that the\n> >>>>> scope\n> >>>>> for Neutron is too large for the attention advances services needs\n> >>>>> from\n> >>>>> the Neutron Core.  If all of advanced services spins out, I see that\n> >>>>\n> >>>> There is merit here, but consider the sorts of things that an advanced\n> >>>> services framework should be doing:\n> >>>>\n> >>>> - plugging into neutron ports, with all manner of topologies\n> >>>> - service VM handling\n> >>>> - plugging into nova-network\n> >>>> - service chaining\n> >>>> - applying things like security groups to services\n> >>>>\n> >>>> ? this is all stuff that Octavia is talking about implementing itself\n> >>>> in a\n> >>>> basically defensive manner, instead of leveraging other work.  And\n> >>>> there\n> >>>> are specific reasons for that.  But, maybe we can at least take steps\n> >>>> to\n> >>>> not be incompatible about it.  Or maybe there is a hierarchy of\n> >>>> Neutron ->\n> >>>> Services -> LB, where we?re still spun out, but not doing it in a way\n> >>>> that\n> >>>> we have to re-implement the world all the time.  It?s at least worth a\n> >>>> conversation or three.\n> >>>>\n> >>> Doug, can you document this on the etherpad for the \"services spinout\"\n> >>> [1]? I\'ve added some brief text at the top on what the objective for\n> >>> this session is, but documenting more along the lines of what you have\n> >>> here would be good.\n> >>>\n> >>> Thanks,\n> >>> Kyle\n> >>>\n> >>> [1] https://etherpad.openstack.org/p/neutron-services\n> >>>\n> >>>> Thanks,\n> >>>> Doug\n> >>>>\n> >>>>\n> >>>>\n> >>>>\n> >>>> On 10/26/14, 6:35 PM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM>\n> >>>> wrote:\n> >>>>\n> >>>>> Good questions Doug.  My answers are as follows:\n> >>>>>\n> >>>>> 1. Yes\n> >>>>> 2. Some time after Kilo (same as I don\'t know when)\n> >>>>> 3. The main reason a spin out makes sense from Neutron is that the\n> >>>>> scope\n> >>>>> for Neutron is too large for the attention advances services needs\n> >>>>> from\n> >>>>> the Neutron Core.  If all of advanced services spins out, I see that\n> >>>>> repeating itself within an advanced services project.  More and more\n> >>>>> \"advanced services\" will get added in and the scope will become too\n> >>>>> large.  There would definitely be benefits to it though, but I think\n> >>>>> we\n> >>>>> would end up being right where we are today.\n> >>>>> 4. I brought this up now so that we can decide whether we want to\n> >>>>> discuss it at the advanced services spin out session.  I don\'t see the\n> >>>>> harm in opinions being discussed before the summit, during the summit,\n> >>>>> and more thoroughly after the summit.\n> >>>>>\n> >>>>> Yes the brunt of the time will not be spent on the API, but since it\n> >>>>> seemed like an opportunity to kill two birds with one stone, I figured\n> >>>>> it warranted a discussion.\n> >>>>>\n> >>>>> Thanks,\n> >>>>> Brandon\n> >>>>>\n> >>>>> On Sun, 2014-10-26 at 23:15 +0000, Doug Wiegley wrote:\n> >>>>>> Hi all,\n> >>>>>>\n> >>>>>> Before we get into the details of which API goes where, I?d like to\n> >>>>>> see\n> >>>>>> us\n> >>>>>> answer the questions of:\n> >>>>>>\n> >>>>>> 1. Are we spinning out?\n> >>>>>> 2. When?\n> >>>>>> 3. With or without the rest of advanced services?\n> >>>>>> 4. Do we want to wait until we (the royal ?we? of ?the Neutron team?)\n> >>>>>> have\n> >>>>>> had the Paris summit discussions on vendor split-out and adv.\n> >>>>>> services\n> >>>>>> spinout before we answer those questions?  (Yes, that question is\n> >>>>>> leading.)\n> >>>>>>\n> >>>>>> To me, the ?where does the API live? is an implementation detail, and\n> >>>>>> not\n> >>>>>> where the time will need to be spent.\n> >>>>>>\n> >>>>>> For the record, my answers are:\n> >>>>>>\n> >>>>>> 1. Yes.\n> >>>>>> 2. I don?t know.\n> >>>>>> 3. I don?t know; this needs some serious discussion.\n> >>>>>> 4. Yes.\n> >>>>>>\n> >>>>>> Thanks,\n> >>>>>> doug\n> >>>>>>\n> >>>>>> On 10/24/14, 3:47 PM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM>\n> >>>>>> wrote:\n> >>>>>>\n> >>>>>>> With the recent talk about advanced services spinning out of\n> >>>>>>> Neutron,\n> >>>>>>> and the fact most of the LBaaS community has wanted LBaaS to spin\n> >>>>>>> out\n> >>>>>> of\n> >>>>>>> Neutron, I wanted to bring up a possibility and gauge interest and\n> >>>>>>> opinion on this possibility.\n> >>>>>>>\n> >>>>>>> Octavia is going to (and has) an API.  The current thinking is that\n> >>>>>>> an\n> >>>>>>> Octavia driver will be created in Neutron LBaaS that will make a\n> >>>>>>> requests to the Octavia API.  When LBaaS spins out of Neutron, it\n> >>>>>>> will\n> >>>>>>> need a standalone API.  Octavia\'s API seems to be a good solution to\n> >>>>>>> this.  It will support vendor drivers much like the current Neutron\n> >>>>>>> LBaaS does.  It has a similar API as Neutron LBaaS v2, but its not\n> >>>>>>> an\n> >>>>>>> exact duplicate.  Octavia will be growing more mature in stackforge\n> >>>>>>> at\n> >>>>>> a\n> >>>>>>> higher velocity than an Openstack project, so I expect by the time\n> >>>>>>> Kilo\n> >>>>>>> comes around it\'s API will be very mature.\n> >>>>>>>\n> >>>>>>> Octavia\'s API doesn\'t have to be called Octavia either.  It can be\n> >>>>>>> separated out and it can be called Openstack LBaaS, and the rest of\n> >>>>>>> Octavia (the actual brains of it) will just be another driver to\n> >>>>>>> Openstack LBaaS, which would retain the Octavia name.\n> >>>>>>>\n> >>>>>>> This is my PROS and CONS list to using Octavia\'s API as the spun out\n> >>>>>>> LBaaS:\n> >>>>>>>\n> >>>>>>> PROS\n> >>>>>>> 1. Time will need to be spent on a spun out LBaaS\'s API anyway.\n> >>>>>> Octavia\n> >>>>>>> will already have this done.\n> >>>>>>> 2. Most of the same people working on Octavia have worked on Neutron\n> >>>>>>> LBaaS v2.\n> >>>>>>> 3. It\'s out of Neutron faster, which is good for Neutron and LBaaS.\n> >>>>>>>\n> >>>>>>> CONS\n> >>>>>>> 1. The Octavia API is dissimilar enough from Neutron LBaaS v2 to be\n> >>>>>>> yet\n> >>>>>>> another version of an LBaaS API.\n> >>>>>>> 2. The Octavia API will also have a separate Operator API which will\n> >>>>>>> most likely only work with Octavia, not any vendors.\n> >>>>>>>\n> >>>>>>> The CONS are easily solvable, and IMHO the PROS greatly outweigh the\n> >>>>>>> CONS.\n> >>>>>>>\n> >>>>>>> This is just my opinion though and I\'d like to hear back from as\n> >>>>>>> many\n> >>>>>> as\n> >>>>>>> possible.  Add on to the PROS and CONS if wanted.\n> >>>>>>>\n> >>>>>>> If it is direction we can agree on going then we can add as a\n> >>>>>>> talking\n> >>>>>>> point in the advanced services spin out meeting:\n> >>>>>>>\n> >>>>>>\n> >>>>>>>\n> >>>>>>> http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f\n> >>>>>>> 1a6\n> >>>>>>> #.\n> >>>>>>> VEq66HWx3UY\n> >>>>>>>\n> >>>>>>> Thanks,\n> >>>>>>> Brandon\n> >>>>>>> _______________________________________________\n> >>>>>>> OpenStack-dev mailing list\n> >>>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>>\n> >>>>>> _______________________________________________\n> >>>>>> OpenStack-dev mailing list\n> >>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>\n> >>>>> _______________________________________________\n> >>>>> OpenStack-dev mailing list\n> >>>>> OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<544E8979.6000609@gmail.com>',NULL),('<1414439558-sup-173@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 12:59:40',-25200,'2014-10-27 19:59:40',NULL,'[openstack-dev] [TripleO] Summit scheduling - using our time\n	together wisely.','Excerpts from Ben Nemec\'s message of 2014-10-27 11:39:31 -0700:\n> On 10/27/2014 12:30 PM, Clint Byrum wrote:\n> > I\'m anxious to get titles for the scheduled sessions so that people can\n> > start planning their daily schedules. I have heard some opinions about\n> > the Neutron/Nova/Ironic work that needs to happen to support L3 (I think\n> > we should still bring it up) and also a bit about Cinder HA. I think\n> > these are things that will benefit from a f2f conversation with the\n> > OpenStack community at large.\n> > \n> > I also think that the biggest theme I see beyond that is UI/onboarding.\n> > So I think we should split the 2 40 minute sessions into these two\n> > things:\n> > \n> > \n> > * L3 Networking + Cinder HA\n> >  - Summary of changes needed in Cinder/Neutron/Nova/Ironic/etc.\n> >  - Configuration changes needed\n> >  - UI changes\n> \n> I still have some reservations about these, as I noted in my previous\n> mail, but at this point I don\'t have an alternative suggestion so I\n> guess +1 from me.\n> \n\nRegardless of the changes that need to happen outside TripleO\'s\nprojects, we will have new things to configure, and new user interface\nelements to discuss in Tuskar. I also want to check in on the status of\nany changes we do need to drive. I want to use the scheduled sessions\nfor this so that anyone from those teams can come and comment, or\nusers/operators can come to understand how the change needs to percolate\nthrough the rest of OpenStack.\n\n> > \n> > * TripleO\'s onramp - All things new contributor\n> >  - QuintupleO progress report\n> \n> This should be pretty brief, unless someone else has done a bunch of\n> work on it that I\'m not aware of.  Nothing has really changed on my end\n> since the blog post I made on this about a month ago.\n>\n\nI think that\'s exactly what I\'d like to see: the summary of what you\nwrote about. This is for public dissemination and also for Q&A. We are\ncrowd-sourcing ideas in this context, not really putting together design\nelements. I mostly want to make sure people who have tried it or are\ninterested in trying it can get connected with you and the rest of the\nteam in this context. \"Embrace the beta testers\" basically.\n\n> >  - Tuskar progress report\n> >  - Alternative implementations roll call\n> \n> Any one of these seems like a potential rabbit hole that could end up\n> taking the entire session.  I definitely think these are important\n> topics to discuss, but if we\'re going to try to fit them into one of the\n> sessions I think we need to be very, very clear about the scope of the\n> discussion.  With basically five topics in this session, each one has\n> less than 10 minutes available to it.  We\'re talking very brief\n> introduction and maybe a couple of questions here.\n>\n\nYes, they all need to have deeper discussions on Friday. What I want to\ndo here is to have the people interested and responsible in these tool\nsets stand up, introduce themselves, state clearly what their project\nis trying to accomplish, and that is all. This way interested parties\ncan engage with these individuals and we can come to Friday ready to\nwork together on the topics that are most urgent and that have the\nbroadest appeal.\n\n\n','<544E9163.6040109@nemebean.com>',NULL),('<1414451891.800603.183983477.5D63D65B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-10-27 16:18:11',-25200,'2014-10-27 23:18:11',NULL,'[OpenStack-Infra] OpenStack-Infra] [Third Party Testing] Gerrit\n account needed?','On Mon, Oct 27, 2014, at 10:49 AM, Nurit Vilosny wrote:\n> HI,\n> We already have a working CI system as part of Neutron tests.\n> We want to start participate in Cinder CI.\n> Can we use the same Gerrit account to trigger these different jobs or\n> should we have a separate account for cinder?\n> Is any registration needed for the same account?\n> \n> Thanks for the help,\n> Nurit\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nHi there,\n\nYou can either use the existing account or get a new one. Typically the\ndecision on which path to take is based on your needs. Is this going to\nbe a single shared CI system on the back end for both Neutron and Cinder\ntesting? If not it is probably easier to have a second account so that\nyou don\'t end up needing to coordinate various backends with the same\naccount.\n\nAlso, if you use the same account then you should keep in mind that\nvoting is done on a per project basis. So if you are able to vote on\nNeutron you may not necessarily vote on Cinder.\n\nIn any case if you can provide us with a bit more info on how you will\nbe implementing the new Cinder tests we can provide a recommendation for\nthe simplest path towards testing Cinder.\n\nFinally, I was asked to point you at the Third Party IRC meetings which\nhappen in #openstack-meeting on freenode every Monday at 1800UTC [1].\nThe organizers of that meeting indicated they could help you figure out\none account vs multiple as well.\n\n[1] https://wiki.openstack.org/wiki/Meetings#Third_Party_Meeting\n\nHope this helps,\nClark Boylan\n\n\n','<9467308fd6fb4bea839afec2c120eb9a@AM2PR05MB0817.eurprd05.prod.outlook.com>',NULL),('<1414458931-sup-880@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-27 18:24:57',-25200,'2014-10-28 01:24:57',NULL,'[openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack','Excerpts from Steven Hardy\'s message of 2014-10-27 15:16:59 -0700:\n> Hi all,\n> \n> Lately I\'ve been spending a lot more time digging into TripleO and Tuskar,\n> and started looking for a way to spin up simple tests (and in particular,\n> play with Tuskar UI/API) without necessarily having the overhead of setting\n> up a full devtest environment every time.\n> \n> So I decided to hack on a patch which automates starting tuskar-api via\n> devstack, here\'s a quick HOWTO if you want to try it:\n> \n> 1. Pull devstack patch\n>     https://review.openstack.org/#/c/131218/\n> \n> 2. Add t-api to localrc\n>     \"enable_service t-api\"\n>     Here\'s my example (Ironic enabled) localrc:\n>     https://gist.github.com/hardys/2cfd2892ce0e63fa8155\n> \n> 3. Add tuskar roles\n>     git clone git://github.com/openstack/tripleo-heat-templates.git\n>     cd tripleo-heat-templates?\n>     tuskar-load-roles --config-file /etc/tuskar/tuskar.conf -r compute.yaml -r controller.yaml\n> \n> 3. clone+install tuskar-ui\n>     git clone git://github.com/openstack/tuskar-ui.git\n>     cd tuskar-ui\n>     python setup.py install\n> \n> 4. Copy tuskar-ui horizon config\n>     cp ~/tuskar-ui/_50_tuskar.py.example\n> /opt/stack/horizon/openstack_dashboard/local/enabled/_50_tuskar.py\n>     sudo systemctl restart httpd.service\n> \n> This provides a basically functional tuskar API and UI, which is enough for\n> basic testing of tuskar, tuskarclient and (to some extent) the UI.\n> \n> I hit some issues, please let me know if new bugs are needed for these, or\n> if you can suggest solutions:\n> \n> 1. UI Infrastructure->Overview page always says No controller/compute node,\n>    even though both roles are loaded\n> \n> 2. UI Service configuration has no content at all\n> \n> 3. UI Deployment Roles page says \"Metering service is not enabled.\", but\n>    ceilometer is installed and active\n> \n> 4. UI: If, Ironic isn\'t available for any reason, you get a big error from the\n>    \"Nodes\" page of the UI\n> \n> 5. API: You can\'t create or modify roles via the API, or even view the\n> content of the role after creating it\n> \n> 6. After running tuskar-load-roles, the overcloud_roles table is always\n> empty (related to 1?)\n> \n> I\'d be interested in peoples thoughts about this general approach - ideally\n> I\'d like to end up at a point where you could launch an overcloud template\n> directly via heat on devstack (with ironic enabled and the appropriate\n> controller/compute images in glance obviously) - has anyone else tried\n> that?\n> \n\nThis is pretty awesome Steve, thanks for working on it. I think until\nwe have QuintupleO and can run things on a cloud instead of a single\nmachine, devtest\'s insistence to do things in a production-esque way\nwill make it too heavy for most developers.\n\n\n','<20141027221658.GB1441@t430slt.redhat.com>',NULL),('<1414490011.4298.15.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 10:53:31',3600,'2014-10-28 09:53:31',NULL,'[openstack-dev] [nova][CI] nova-networking or neutron netwokring\n	for CI','Hi, \nwe\'re preparing to add a new platform, libvirt-kvm on system z\n(https://blueprints.launchpad.net/nova/+spec/libvirt-kvm-systemz), to\nthe HypervisorSupportMatrix\nhttps://wiki.openstack.org/wiki/HypervisorSupportMatrix .\n\n\nThis matrix also lists a number of networking features (e.g. vlan\nnetworking, routing,..). \n\nIf I interpret the footnotes correctly, these network items refer only\nto nova-networking, right? So if I plan to support vlan networking with\nneutron, but not with nova-networking it would be an \"x\" in the related\ncell, right?\n\n\nNow thinking one step further in the direction of a CI system for the\nnew platform. \n\nAre current nova CI platforms configured with nova-networking or with\nneutron networking? Or is networking in general not even a part of the\nnova CI approach?\n\n\nMy current assumption is that any networking is a requirement and most\nof the systems would go with nova-networking. Is this true?\n\nIf so, does it make sense to run the CI system with neutron networking\ninstead of nova-networking? What\'s the best practice in this area?\n\nNot sure about the deprecation plans of nova-networking. But setting up\nthe CI environment might also take a while. Do you think it\'s still\nworthwhile spending time for the nova-network integration in the CI\nsystem, if it might be deprecated in the future anyhow? \n\n\nAny input?\n\nThanks a lot!\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1414521055-sup-7874@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 11:34:14',-25200,'2014-10-28 18:34:14',NULL,'[openstack-dev] [tuskar][tripleo] Tuskar/TripleO on Devstack','Excerpts from Ben Nemec\'s message of 2014-10-28 11:13:22 -0700:\n> On 10/28/2014 06:18 AM, Steven Hardy wrote:\n> > On Tue, Oct 28, 2014 at 11:08:05PM +1300, Robert Collins wrote:\n> >> On 28 October 2014 22:51, Steven Hardy <shardy at redhat.com> wrote:\n> >>> On Tue, Oct 28, 2014 at 03:22:36PM +1300, Robert Collins wrote:\n> >>>> So this should work and I think its generally good.\n> >>>>\n> >>>> But - I\'m curious, you only need a single image for devtest to\n> >>>> experiment with tuskar - the seed - which should be about the same\n> >>>> speed (or faster, if you have hot caches) than devstack, and you\'ll\n> >>>> get Ironic and nodes registered so that the panels have stuff to show.\n> >>>\n> >>> TBH it\'s not so much about speed (although, for me, devstack is faster as\n> >>> I\'ve not yet mirrored all-the-things locally, I only have a squid cache),\n> >>> it\'s about establishing a productive test/debug/hack/re-test workflow.\n> >>\n> >> mm, squid-cache should still give pretty good results. If its not, bug\n> >> time :). That said..\n> >>\n> >>> I\'ve been configuring devstack to create Ironic nodes FWIW, so that works\n> >>> OK too.\n> >>\n> >> Cool.\n> >>\n> >>> It\'s entirely possible I\'m missing some key information on how to compose\n> >>> my images to be debug friendly, but here\'s my devtest frustration:\n> >>>\n> >>> 1. Run devtest to create seed + overcloud\n> >>\n> >> If you\'re in dev-of-a-component cycle, I wouldn\'t do that. I\'d run\n> >> devtest_seed.sh only. The seed has everything on it, so the rest is\n> >> waste (unless you need all the overcloud bits - in which case I\'d\n> >> still tune things - e.g. I\'d degrade to single node, and I\'d iterate\n> >> on devtest_overcloud.sh, *not* on the full plumbing each time).\n> > \n> > Yup, I went round a few iterations of those, e.g running devtest_overcloud\n> > with -c so I could more quickly re-deploy, until I realized I could drive\n> > heat directly, so I started doing that :)\n> > \n> > Most of my investigations atm are around investigating Heat issues, or\n> > testing new tripleo-heat-templates stuff, so I do need to spin up the\n> > overcloud (and update it, which is where the fun really began ref bug \n> > #1383709 and #1384750 ...)\n> > \n> >>> 2. Hit an issue, say a Heat bug (not that *those* ever happen! ;D)\n> >>> 3. Log onto seed VM to debug the issue.  Discover there are no logs.\n> >>\n> >> We should fix that - is there a bug open? Thats a fairly serious issue\n> >> for debugging a deployment.\n> > \n> > I\'ve not yet raised one, as I wasn\'t sure if it was either by design, or if\n> > I was missing some crucial element from my DiB config.\n> > \n> > If you consider it a bug, I\'ll raise one and look into a fix.\n> > \n> >>> 4. Restart the heat-engine logging somewhere\n> >>> 5. Realize heat-engine isn\'t quite latest master\n> >>> 6. Git pull heat, discover networking won\'t allow it\n> >>\n> >> Ugh. Thats horrid. Is it a fedora thing? My seed here can git pull\n> >> totally fine - I\'ve depended heavily on that to debug various things\n> >> over time.\n> > \n> > Not yet dug into it in a lot of detail tbh, my other VMs can access the\n> > internet fine so it may be something simple, I\'ll look into it.\n> \n> Are you sure this is a networking thing?  When I try a git pull I get this:\n> \n> [root at localhost heat]# git pull\n> fatal:\n> \'/home/bnemec/.cache/image-create/source-repositories/heat_dc24d8f2ad92ef55b8479c7ef858dfeba8bf0c84\'\n> does not appear to be a git repository\n> fatal: Could not read from remote repository.\n> \n> That\'s actually because the git repo on the seed would have come from\n> the local cache during the image build.  We should probably reset the\n> remote to a sane value once we\'re done with the cache one.\n> \n> Networking-wise, my Fedora seed can pull from git.o.o just fine though.\n> \n\nI think we should actually just rip the git repos out of the images in\nproduction installs. What good does it do sending many MB of copies of\nthe git repos around? Perhaps just record HEAD somewhere in a manifest\nand rm -r the source repos during cleanup.d.\n\nBut, for supporting dev/test, we could definitely leave them there and\nchange the remotes back to their canonical (as far as diskimage-builder\nknows) sources.\n\n\n','<544FDCC2.6020503@nemebean.com>',NULL),('<1414534246-sup-8388@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 15:14:07',-25200,'2014-10-28 22:14:07',NULL,'[openstack-dev] [neutron][nova] New specs on routed networking','Excerpts from Cory Benfield\'s message of 2014-10-24 06:38:44 -0700:\n> All,\n> \n> Project Calico [1] is an open source approach to virtual networking based on L3 routing as opposed to L2 bridging.  In order to accommodate this approach within OpenStack, we\'ve just submitted 3 blueprints that cover\n> \n> -  minor changes to nova to add a new VIF type [2]\n> -  some changes to neutron to add DHCP support for routed interfaces [3]\n> -  an ML2 mechanism driver that adds support for Project Calico [4].\n> \n> We feel that allowing for routed network interfaces is of general use within OpenStack, which was our motivation for submitting [2] and [3].  We also recognise that there is an open question over the future of 3rd party ML2 drivers in OpenStack, but until that is finally resolved in Paris, we felt submitting our driver spec [4] was appropriate (not least to provide more context on the changes proposed in [2] and [3]).\n> \n> We\'re extremely keen to hear any and all feedback on these proposals from the community.  We\'ll be around at the Paris summit in a couple of weeks and would love to discuss with anyone else who is interested in this direction. \n\nI\'m quite interested in this, as we\'ve recently been looking at how to\nscale OpenStack on bare metal servers beyond the limits of a single flat\nL2 network. We have a blueprint for it in TripleO as well:\n\nhttps://blueprints.launchpad.net/tripleo/+spec/l3-network-segmentation\n\nHopefully you will be at the summit and can attend our scheduled session,\nwhich I believe will be some time on Wednesday.\n\nWe\'re basically just planning on having routers configured out of band\nand just writing a Nova filter to ensure that the compute host has a\nproperty which matches the network names requested with a server.\n\nBut if we could automate that too, that would make for an even more\nautomatic and scalable solution.\n\n\n','<583d73e1542e4df99c0a35f850af990d@DM2PR0201MB0831.namprd02.prod.outlook.com>',NULL),('<1414563749626-56323.post@n7.nabble.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 23:22:29',-25200,'2014-10-29 06:22:29',NULL,'[openstack-dev] [all] [tc] Multi-clouds integration by\n	OpenStack cascading','This is very interesting problem to solve.\nI am curious to know how the reachability is provided across different\nDatacenter.\nHow to know which VM is part of which Datacenter? \nVM may be in different Zone but under same DC or in different DC itself.\n\nHow this problem is solved?\n\n\nthanks & regards,\nkeshava\n\n\n\n--\nView this message in context: http://openstack.10931.n7.nabble.com/all-tc-Multi-clouds-integration-by-OpenStack-cascading-tp54115p56323.html\nSent from the Developer mailing list archive at Nabble.com.\n\n\n','<5E7A3D1BF5FD014E86E5F971CF446EFF541C9E58@szxema505-mbx.china.huawei.com>',NULL),('<1414574600.4498.16.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 10:23:20',3600,'2014-10-29 09:23:20',NULL,'[openstack-dev] [nova][CI] nova-networking or neutron\n netwokring for CI','Thanks for the feedback. \n\nOK, got it, nova networking is not a requirement for a CI. Then I\'ll see\nnot a single reason to support it. We will investigate in the neutron\nway for our CI and also for production.\n\nNow coming back to the Hypervisorsupportmatrix\n( https://wiki.openstack.org/wiki/HypervisorSupportMatrix ). \nI guess the scope of this matrix is only nova and not neutron,cinder,..\nisn\'t it? \n\nSo in this matrix I have to tick the networking lines (vlan, routing,..)\nas NOT supported, right? (as scope is neutron-networking, altough we\nwould \"support\" it with neutron).\n\nThanks, \nAndreas\n\n\n\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Tue, 2014-10-28 at 11:06 -0700, Joe Gordon wrote:\n> \n> \n> On Tue, Oct 28, 2014 at 6:44 AM, Dan Smith <dms at danplanet.com> wrote:\n>         > Are current nova CI platforms configured with\n>         nova-networking or with\n>         > neutron networking? Or is networking in general not even a\n>         part of the\n>         > nova CI approach?\n>         \n>         I think we have several that only run on Neutron, so I think\n>         it\'s fine\n>         to just do that.\n> \n> \n> Agreed, neutron should be considered required for all of the reasons\n> listed above.\n>  \n>         \n>         --Dan\n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAHXdxOc8fBwXsuu=7cHtPm00pJUQNSH5+R+vjXoVtV5z5NtxVg@mail.gmail.com>',NULL),('<1414575919.4498.23.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-29 10:45:19',3600,'2014-10-29 09:45:19',NULL,'[Openstack] Q: How do you set up your external networks?','So you want all users to direclty connect to this network? What about\nthe shared parameter?\n\nhttp://docs.openstack.org/admin-guide-cloud/content/advanced_networking.html\n\n\n\"neutron net-create --shared public-net\"\n\n\nRegards, \n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Tue, 2014-10-28 at 15:08 -0400, Don Waterloo wrote:\n> I think I am missing something on a best practice here.\n> \n> I have an external \'provider\' network called ext-net.\n> Into that i have attached via the admin-user a router called\n> \'public-rtr\' and a subnet called \'public\'.\n> \n> If I set \'external:True\' on public, then I can use heat constructs like this:\n> \n>   rtr:\n>     type: OS::Neutron::Router\n>     properties:\n>       admin_state_up: True\n>       name: \'rtr\'\n>       external_gateway_info:\n>         network: \"public\"\n> \n> but, each user needs to be \'admin\'.\n> \n> If I set external:False on public, I can attach instances manually to\n> it, but i cannot use \'external_gateway_info\' to attach a router to it.\n> \n> What am I supposed to do? I don\'t want all users to be admin, but i do\n> want all users to be able to attach to the network.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n\n','<CAKrvkGcoeR4MShKbZ7M+B0Pyjm1jwFs+y7yuAn-7jA3V6WL-kg@mail.gmail.com>',NULL),('<1414609872923.44615@metaswitch.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 19:11:13',0,'2014-10-29 19:11:13',NULL,'[openstack-dev] [neutron][nova] New specs on routed networking','> Some of us are looking at a different model. I?d be interested in your thoughts.\n\nFred,\n\nThanks for the link to the drafts. They look extremely similar to the \napproach we\'ve been pursuing for Project Calico, and it\'s good to see \nthat we\'re not the only people thinking in this direction.\n\nIt looks like the main differences between our approach and yours are \nthat we\'ve tried to come up with a model that works both for IPv4 and \nIPv6 (although we agree that moving the data center fabric to IPv6 has a \nlot of advantages - e.g. we are planning on using 464XLAT as the \nmechanism to handle IPv4 overlap).  Given this, we\'ve focused our \npolicy/security model on ACLs rather than flow labels.  An interesting \nderivative effect of that choice is that any policy or security model \ncan be enforced (such as intra-tenant controls, extra-cloud controls, \netc).\n\nAs a side note, we have been interested in using flow labels as \nnamespace identifiers and for SFC.  Recently, we have moved away from \nthat thinking given the guidance that the flow label should be not be \nmodified in flight.  If you believe that such modifications will be \nacceptable, we would love to discuss that with you, and see where we can \ncollaborate.\n\nAs it is, I believe our proposed changes to Nova and Neutron should be \ngeneric enough to provide a basis for implementing your approach as well \nas supporting our Project Calico ML2 driver. If they aren\'t, we should \nwork together to make whatever changes we have to make to achieve that \ngenerality.\n\nIt might also be worth checking out our agent code[0]. It\'s in the \nmiddle of a rewrite at the minute so the code is unfinished, but it \nhandles a lot of what you\'d be doing with your proposed drafts. \nHopefully it\'d be a useful jumping off point.\n\nCory\n\n[0]: https://github.com/Metaswitch/calico/tree/master/calico/felix\n\n\n','<3840B44C-F1A4-4672-8D5C-D409BE725EAE@cisco.com>',NULL),('<1414632222-sup-4026@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 18:27:48',-25200,'2014-10-30 01:27:48',NULL,'[openstack-dev] TC election by the numbers','Excerpts from Eoghan Glynn\'s message of 2014-10-29 16:37:42 -0700:\n> \n> > > On Oct 29, 2014, at 3:32 PM, Eoghan Glynn <eglynn at redhat.com> wrote:\n> > > \n> > > \n> > > Folks,\n> > > \n> > > I haven\'t seen the customary number-crunching on the recent TC election,\n> > > so I quickly ran the numbers myself.\n> > > \n> > > Voter Turnout\n> > > =============\n> > > \n> > > The turnout rate continues to decline, in this case from 29.7% to 26.7%.\n> > > \n> > > Here\'s how the participation rates have shaped up since the first TC2.0\n> > > election:\n> > > \n> > > Election | Electorate | Voted | Turnout | Change\n> > > ------------------------------------------------\n> > > 10/2013  | 1106       | 342   | 30.9%   | -8.0%\n> > > 04/2014  | 1510       | 448   | 29.7%   | -4.1%\n> > > 10/2014  | 1892       | 506   | 26.7%   | -9.9%\n> > \n> > \n> > Overall percentage of the electorate voting is declining, but absolute\n> > numbers of voters has increased. And in fact, the electorate has grown more\n> > than the turnout has declined.\n> \n> True that, but AFAIK the generally accepted metric on participation rates\n> in elections is turnout as opposed to absolute voter numbers.\n> \n\nIIRC, there is no method for removing foundation members. So there are\nlikely a number of people listed who have moved on to other activities and\nare no longer involved with OpenStack. I\'d actually be quite interested\nto see the turnout numbers with voters who missed the last two elections\nprior to this one filtered out.\n\n\n','<1871996780.3247695.1414625862270.JavaMail.zimbra@redhat.com>',NULL),('<1414657701.0.1376719922714.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-17 06:12:02',0,'2013-08-17 06:12:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/6/>\n\n------------------------------------------\n[...truncated 3739 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 33.97 secs:\n    8.31    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    7.00    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.49    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    6.24    TestTokenRevoking.test_removing_role_assignment_does_not_affect_other_users\n    5.94    TestTokenAPIs.test_revoke_token\n----------------------------------------------------------------------\nRan 1300 tests in 453.912s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.6.1\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.6\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ihZIvVeA6m\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise10/6\n[SCP] Copying console log.\n\n\n','<147508342.4.1376633758361.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<141468219.5osWzahBRd@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 11:25:51',39600,'2014-10-29 00:25:51',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements','On Tue, 28 Oct 2014 04:42:27 PM Jorge Miramontes wrote:\n> Thanks for the reply Angus,\n> \n> DDoS attacks are definitely a concern we are trying to address here. My\n> assumptions are based on a solution that is engineered for this type of\n> thing. Are you more concerned with network I/O during a DoS attack or\n> storing the logs? Under the idea I had, I wanted to make the amount of\n> time logs are stored for configurable so that the operator can choose\n> whether they want the logs after processing or not. The network I/O of\n> pumping logs out is a concern of mine, however.\n\nMy primary concern was the generated network I/O, and the write bandwidth to \nstorage media implied by that (not so much the accumulated volume of data).\n\nWe\'re in an era where 10Gb/s networking is now common for serving/loadbalancer \ninfrastructure and as far as I can see the trend for networking is climbing \nmore steeply that storage I/O, so it\'s only going to get worse.   10Gb/s of \nshort-lived connections is a *lot* to try to write to reliable storage \nsomewhere and later analyse.\nIt\'s a useful option for some users, but it would be a shame to have to limit \nloadbalancer throughput by the logging infrastructure just because we didn\'t \nhave an alternative available.\n\nI think you\'re right, that we don\'t have an obviously-correct choice here.  I \nthink we need to expose both cheap sampling/polling of counters and more \ndetailed logging of connections matching patterns (and indeed actual packet \ncapture would be nice too).  Someone could then choose to base their billing \non either datasource depending on their own accuracy-vs-cost-of-collection \ntradeoffs.  I don\'t see that either approach is going to be sufficiently \nuniversal to obsolete the other :(\n\nAlso: UDP.   Most providers are all about HTTP now, but there are still some \npeople that need to bill for UDP, SIP, VPN, etc traffic.\n\n - Gus\n\n> Sampling seems like the go-to solution for gathering usage but I was\n> looking for something different as sampling can get messy and can be\n> inaccurate for certain metrics. Depending on the sampling rate, this\n> solution has the potential to miss spikes in traffic if you are gathering\n> gauge metrics such as active connections/sessions. Using logs would be\n> 100% accurate in this case. Also, I\'m assuming LBaaS will have events so\n> combining sampling with events (CREATE, UPDATE, SUSPEND, DELETE, etc.)\n> gets complicated. Combining logs with events is arguably less complicated\n> as the granularity of logs is high. Due to this granularity, one can split\n> the logs based on the event times cleanly. Since sampling will have a\n> fixed cadence you will have to perform a \"manual\" sample at the time of\n> the event (i.e. add complexity).\n> \n> At the end of the day there is no free lunch so more insight is\n> appreciated. Thanks for the feedback.\n> \n> Cheers,\n> --Jorge\n> \n> On 10/27/14 6:55 PM, \"Angus Lees\" <gus at inodes.org> wrote:\n> >On Wed, 22 Oct 2014 11:29:27 AM Robert van Leeuwen wrote:\n> >> > I,d like to start a conversation on usage requirements and have a few\n> >> > suggestions. I advocate that, since we will be using TCP and\n> >>\n> >>HTTP/HTTPS\n> >>\n> >> > based protocols, we inherently enable connection logging for load\n> >> \n> >> > balancers for several reasons:\n> >> Just request from the operator side of things:\n> >> Please think about the scalability when storing all logs.\n> >> \n> >> e.g. we are currently logging http requests to one load balanced\n> >>\n> >>application\n> >>\n> >> (that would be a fit for LBAAS) It is about 500 requests per second,\n> >>\n> >>which\n> >>\n> >> adds up to 40GB per day (in elasticsearch.) Please make sure whatever\n> >> solution is chosen it can cope with machines doing 1000s of requests per\n> >> second...\n> >\n> >And to take this further, what happens during DoS attack (either syn\n> >flood or\n> >full connections)?  How do we ensure that we don\'t lose our logging\n> >system\n> >and/or amplify the DoS attack?\n> >\n> >One solution is sampling, with a tunable knob for the sampling rate -\n> >perhaps\n> >tunable per-vip.  This still increases linearly with attack traffic,\n> >unless you\n> >use time-based sampling (1-every-N-seconds rather than 1-every-N-packets).\n> >\n> >One of the advantages of (eg) polling the number of current sessions is\n> >that\n> >the cost of that monitoring is essentially fixed regardless of the number\n> >of\n> >connections passing through.  Numerous other metrics (rate of new\n> >connections,\n> >etc) also have this property and could presumably be used for accurate\n> >billing\n> >- without amplifying attacks.\n> >\n> >I think we should be careful about whether we want logging or metrics for\n> >more\n> >accurate billing.  Both are useful, but full logging is only really\n> >required\n> >for ad-hoc debugging (important! but different).\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D075289D.1907D%jorge.miramontes@rackspace.com>',NULL),('<1414931006.2037565.186064789.12D28433@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-02 05:23:26',-25200,'2014-11-02 12:23:26',NULL,'[openstack-dev] Keybase.io invites for OpenStack people (was Re:\n Key signing at the summit?)','> I will also try to get more keybase.io invites, for those who want them.\n>  keybase.io is a web service that provides an independently provable\n> binding between your social media and github identities, and your gpg\n> key.\n\nI have been granted *many* invites from keybase.io for OpenStack\ndevelopers.\n\nI have already sent an invite to everyone who already participated in\nthe keysigning party in Hong Kong and in Atlanta.\n\nIf anyone else wants an invite, do please approach me at the Summit in\nParis, or email me.\n\n..m\n\n--\nMark Atwood <mark.atwood at hp.com>  \nMark Atwood <me at mark.atwood.name>\n\n\n','<1414390025.2579979.183620317.39B28EC8@webmail.messagingengine.com>',NULL),('<1415258732-sup-4576@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-06 08:26:43',3600,'2014-11-06 07:26:43',NULL,'[openstack-dev] [Heat] New function: first_nonnull','Excerpts from Lee, Alexis\'s message of 2014-11-05 15:46:43 +0100:\n> I\'m considering adding a function which takes a list and returns the first\n> non-null, non-empty value in that list.\n> \n> So you could do EG:\n> \n>     some_thing:\n>         config:\n>             ControlVIP:\n>                 first_nonnull:\n>                 - {get_param: ControlVIP}\n>                 - {get_attr: [ControlVirtualIP, fixed_ips, 0, ip_address]}]}\n> \n> I\'m open to other names, EG \"some\", \"or\", \"fallback_list\" etc.\n> \n> Steve Hardy suggested building this into get_attr or Fn::Select. My feeling\n> is that those each do one job well right now, I\'m happy to take a steer\n> though.\n> \n> What do you think please?\n> \n\nYes this is super useful for writing responsive, reusable templates.\n\nI\'d like to suggest that this be called \'coalesce\' as that is what SQL\ncalls it.\n\n\n','<5F9B2395CDE96E41B0F8FA39020435FF2A6113E8@G2W2441.americas.hpqcorp.net>',NULL),('<1415287100065.d6ef52c2@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-06 07:18:20',-28800,'2014-11-06 15:18:20',NULL,'[openstack-dev] [Neutron] IPv6 team summit meetup','Hey,?\n\nSince we don\'t have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)?\n\n\nWe can meet at 12:30 at the meet up place?Neuilly?lobby of Le Meridien and go to lunch together after that.\n\n\nXu Han?\n\n\n\n\n?\nSent from Mailbox for iPhone\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141106/c7b62daa/attachment.html>\n\n',NULL,NULL),('<1415287768-sup-863@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-06 16:33:24',3600,'2014-11-06 15:33:24',NULL,'[Openstack-operators] Proposal for an \'Operations\' project','Excerpts from Michael Chapman\'s message of 2014-11-06 12:20:52 +0100:\n> Hi Operators!\n> \n> I felt like OpenStack didn\'t have enough projects, so here\'s another one.\n> \n> During the summit I feel like I\'m repeatedly having the same conversations\n> with different groups about bespoke approaches to operational tasks, and\n> wrapping these in a project might be a way to promote collaboration on them.\n> \n> Off the top of my head there\'s half a dozen things that might belong here:\n> \n>  - Packaging tooling (spec files/fpm script/whatever)\n>  - (Ansible/other) playbooks for common tasks\n>  - Log aggregation (Logstash/Splunk) filters and tagging\n>  - Monitoring (Nagios) checks\n>  - Ops dashboards\n> \n> There\'s also things that *might* belong here but maybe not:\n> \n>  - Chef/Puppet/Ansible/Salt OpenStack config management modules\n> \n> Today these are generally either wrapped up in products from various\n> companies, or in each company\'s github repo.\n> \n\nExcept in the case of TripleO which is available as an official\nOpenStack project.\n\nI think we\'re at a point where we\'re far more open than we\'ve ever been\nbefore to the idea of collaborating with many different tools and\napproaches. So, would you entertain the idea of participating in the \"Deployment\"\nprogram rather than starting smoething new?\n\n> For those of you who are still around at the design summit and don\'t have\n> plans for tomorrow, how about we meet on Friday morning at the large white\n> couch in the meridian foyer at 9am? Let\'s see what we can sort out.\n> \n\nYou\'re more than welcome in the TripleO meetup tomorrow in Gaughin.\n\n\n','<CABf87XmbbD5ZPz=oPxmdF_he_jxQkheV72dYbp3X9ACte3+mvg@mail.gmail.com>',NULL),('<1415361785.21510.0.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-07 07:03:05',-18000,'2014-11-07 12:03:05',NULL,'[openstack-dev] [Barbican] Nominating Steve Heyman\n	for	barbican-core','+1 for me.\n\nOn Thu, 2014-11-06 at 11:21 +0000, John Wood wrote:\n> +1\n> \n> Thanks,\n> John\n> \n> ________________________________________\n> From: Nathan Reller [rellerreller at yahoo.com]\n> Sent: Thursday, November 06, 2014 3:35 AM\n> To: Openstack-Dev\n> Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for     barbican-core\n> \n> +1 for me\n> \n> -Nate\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<49F5BF8205841548AB38409969C7AB3F9D95E464@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1415361814.21510.1.camel@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-07 07:03:34',-18000,'2014-11-07 12:03:34',NULL,'[openstack-dev] [Barbican] Nominating Juan Antonio Osorio\n Robles for barbican-core','+1 for me.\n\nOn Wed, 2014-11-05 at 15:53 +0000, Douglas Mendizabal wrote:\n> Hi All,\n> \n> \n> I would like to nominate Juan Antonio Osorio Robles to the\n> barbican-core team.\n> \n> \n> Juan has been consistently giving us very well thought out and\n> constructive reviews for Barbican, python-barbicanclient and\n> barbican-specs.  It?s obvious from his reviews that he cares deeply\n> for the quality of the Barbican project, and I think he will be a\n> great addition to the core team.\n> \n> \n> As a reminder to barbican-core members, we use the voting process\n> outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add\n> members to our team.\n> \n> \n> References:\n> \n> \n> http://stackalytics.com/report/contribution/barbican-group/90\n> \n> \n> Thanks,\n> Douglas\n> \n> \n> --------------------\n> Douglas Mendiz?bal\n> IRC: redrobot\n> PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<D0800668.369FA%douglas.mendizabal@rackspace.com>',NULL),('<1415378191.32.1375509802680.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-03 06:03:22',0,'2013-08-03 06:03:22',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #122','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/122/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-180900 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #211455 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-postgres-stable-grizzly] $ /bin/bash -xe /tmp/hudson3365340952774222031.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-postgres-stable-grizzly] $ /bin/bash -xe /tmp/hudson9006103111106411537.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_POSTGRES=1\n+ DEVSTACK_GATE_POSTGRES=1\n+ export DEVSTACK_GATE_TEMPEST_FULL=1\n+ DEVSTACK_GATE_TEMPEST_FULL=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-180900\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-180900/122\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-180900/122/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-180900/122/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1415550158-sup-3392@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-09 08:45:44',-28800,'2014-11-09 16:45:44',NULL,'[Openstack-operators] Proposal for an \'Operations\' project','Excerpts from Jeremy Stanley\'s message of 2014-11-08 16:23:02 -0800:\n> On 2014-11-08 04:08:08 -0500 (-0500), Fischer, Matt wrote:\n> [...]\n> > Perhaps some of the code fits in some places as previously\n> > mentioned on the list, but the issue is that none of those\n> > projects really focus on operations. The projects are inevitably\n> > developer focused, despite the best attempts to get operator\n> > feedback.\n> [...]\n> \n> I would counter that we have lots of operator-focused projects\n> already underway... the Infra and QA teams, for example, have plenty\n> of projects which are entirely shell scripts and configuration\n> management. If you were in any of the Deployment Program\'s design\n> sessions, there was a fairly consistent message that Triple-O is\n> encouraging direct involvement from the various config management\n> teams to bring more officialness to the diverse tools with which\n> OpenStack is deployed and managed at production sites.\n> \n> If the projects you want to start aren\'t focused on deployment and\n> lifecycle management, nor on community infrastructure tools, nor on\n> documentation, then I would buy that there\'s some potential project\n> use cases for which we haven\'t made suitable homes yet. But I\'d hate\n> to see that used to further what I see as an unnecessary separation\n> between \"developers\" and \"operators.\"\n\nThere\'s this crazy movement underway called \"DevOps\" where we stop\ntreating these two groups as independent victims of each-other\'s\nconflicting responsibilities. Instead we need to see each as simply _more_\nfocused on one responsibility or another, but all on the same team with\nthe same end goal of a stable, agile deployment.\n\nGiven that most of us seem to believe that, I am really confused\nwhy anybody sees the Deployment Program as anything other than an\noperations focused project. It is entirely focused on deploying and\noperating OpenStack. The fact that we\'ve stated we will use components\nof OpenStack whenever that is possible is secondary to the first charge\nof actually deploying a managable OpenStack cloud.\n\nNow I understand, in the past we have been entirely prescriptive and\nopinionated on levels that have made large portions of the operators\nfeel excluded. That may have been necessary to make some early progress,\nbut I don\'t believe it will continue.\n\nI sat with several people who attended the gathering of operators that\nthis thread references, and at least the few of us there agreed that most\nof what they discussed wasn\'t specifically about deploying OpenStack,\nbut about deploying it with all of the supporting tools that surround\nOpenStack. This sounds like the beginnings of a complimentary program.\n\nI am quite excited to see some discussion around coalescing these\nefforts. Having diverse deployments is useful for finding efficient ways\nto solve real problems. How you get logs into LogStash and what Kibana\nqueries you use to find issues is interesting. Whether you express that\nyou want your logs in LogStash as Chef, Puppet, or diskimage-builder\nelements with os-apply-config templates and os-refresh-config scripts\nis pretty uninteresting in comparison.\n\n\n','<20141109002302.GW2497@yuggoth.org>',NULL),('<1415551856-sup-8421@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-09 08:54:29',-28800,'2014-11-09 16:54:29',NULL,'[openstack-dev] [Heat] New function: first_nonnull','Excerpts from Angus Salkeld\'s message of 2014-11-09 00:15:42 -0800:\n> On 06/11/2014 8:32 AM, \"Clint Byrum\" <clint at fewbar.com> wrote:\n> >\n> > Excerpts from Lee, Alexis\'s message of 2014-11-05 15:46:43 +0100:\n> > > I\'m considering adding a function which takes a list and returns the\n> first\n> > > non-null, non-empty value in that list.\n> > >\n> > > So you could do EG:\n> > >\n> > >     some_thing:\n> > >         config:\n> > >             ControlVIP:\n> > >                 first_nonnull:\n> > >                 - {get_param: ControlVIP}\n> > >                 - {get_attr: [ControlVirtualIP, fixed_ips, 0,\n> ip_address]}]}\n> > >\n> > > I\'m open to other names, EG \"some\", \"or\", \"fallback_list\" etc.\n> > >\n> > > Steve Hardy suggested building this into get_attr or Fn::Select. My\n> feeling\n> > > is that those each do one job well right now, I\'m happy to take a steer\n> > > though.\n> > >\n> > > What do you think please?\n> > >\n> >\n> > Yes this is super useful for writing responsive, reusable templates.\n> >\n> > I\'d like to suggest that this be called \'coalesce\' as that is what SQL\n> > calls it.\n> \n> Although I have no clue why they called it that (colalesce mean join/merge\n> not get first non-null). I\'d rather it be called what it does\n> \"first_nonnull()\" seems more obvious to me. We could also try the\n> conditional as Zane suggested.\n\nI believe it is called that because it is meant to coalesce a list of\nvariables in descending priority into one, which is precisely the use\ncase presented.\n\nThat said, first_nonnull is fine too if that nuance is not as obvious to\nothers as it is to me. :-P\n\n\n','<CAA16xcxVupoG6cKa8a6Y0R__nTjN76HL_1o3nCz_s0TVL_Vnww@mail.gmail.com>',NULL),('<1415552118-sup-2525@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-09 08:58:38',-28800,'2014-11-09 16:58:38',NULL,'[openstack-dev] [Heat] New function: first_nonnull','Excerpts from Zane Bitter\'s message of 2014-11-06 15:35:09 -0800:\n> On 06/11/14 20:44, Steven Hardy wrote:\n> > On Wed, Nov 05, 2014 at 02:46:43PM +0000, Lee, Alexis wrote:\n> >>     I\'m considering adding a function which takes a list and returns the first\n> >>\n> >>     non-null, non-empty value in that list.\n> >>\n> >>     So you could do EG:\n> >>\n> >>         some_thing:\n> >>\n> >>             config:\n> >>\n> >>                 ControlVIP:\n> >>\n> >>                     first_nonnull:\n> >>\n> >>                     - {get_param: ControlVIP}\n> >>\n> >>                     - {get_attr: [ControlVirtualIP, fixed_ips, 0,\n> >>     ip_address]}]}\n> >>\n> >>\n> >>     I\'m open to other names, EG \"some\", \"or\", \"fallback_list\" etc.\n> >>\n> >>     Steve Hardy suggested building this into get_attr or Fn::Select. My\n> >>     feeling is that those each do one job well right now, I\'m happy to\n> >>     take a steer though.\n> >\n> > Ah, from our IRC discussion I was thinking you wanted primarily list\n> > filtering of get_attr output, thus thinking an optional argument would make\n> > more sense than a new function.\n> >\n> > I see now that you\'re actually looking for something of a poor-mans\n> > conditional, so you choose either the ControlVIP parameter, or the\n> > ControlVirtualIP attribute, for which your proposal is probably cleaner -\n> > my concern is just that we avoid a proliferation of different list\n> > select/filter functions, when we could just have one.\n> \n> \n> Crazy thought: why not just implement conditionals? We had a proto-spec \n> for them started at one point...\n> \n\nThe coalesce/first_nonnull is just a shortcut for a common conditional\nproblem. I\'d agree that conditionals are useful as well, but they might\nbe better served by more time to bake than this more narrow case.\n\n\n','<545C05AD.6090605@redhat.com>',NULL),('<1415635052.3966.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-10 15:57:30',0,'2014-11-10 15:57:30',NULL,'[openstack-dev] [neutron][lbaas] meeting day/time change','https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting\n\nThat is updated for lbaas and advanced services with the new times.\n\nThanks,\nBrandon\n\nOn Mon, 2014-11-10 at 11:07 +0000, Doug Wiegley wrote:\n> #openstack-meeting-4\n> \n> \n> > On Nov 10, 2014, at 10:33 AM, Evgeny Fedoruk <EvgenyF at Radware.com> wrote:\n> > \n> > Thanks,\n> > Evg\n> > \n> > -----Original Message-----\n> > From: Doug Wiegley [mailto:dougw at a10networks.com] \n> > Sent: Friday, November 07, 2014 9:04 PM\n> > To: OpenStack Development Mailing List\n> > Subject: [openstack-dev] [neutron][lbaas] meeting day/time change\n> > \n> > Hi all,\n> > \n> > Neutron LBaaS meetings are now going to be Tuesdays at 16:00 UTC.\n> > \n> > Safe travels. \n> > \n> > Thanks,\n> > Doug\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<28382F5F-34AC-4FC1-9F74-38B398845E7F@a10networks.com>',NULL),('<1415636103-sup-7916@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-10 08:21:55',-28800,'2014-11-10 16:21:55',NULL,'[Openstack-operators] Proposal for an \'Operations\' project','Excerpts from Michael Chapman\'s message of 2014-11-10 02:33:33 -0800:\n> Here\'s the etherpad from Friday:\n> https://etherpad.openstack.org/p/kilo-summit-ops-opsprogram\n> \n> Jonothan: Your example of including log filters in oslo is extremely\n> confusing. I am talking about something like this:\n> https://github.com/OpenStratus/openstack-logstash/blob/master/agent.conf\n> \n> Which really doesn\'t belong in oslo. There\'s similar configuration for\n> equivalents such as splunk or fluentd, all doing roughly the same thing\n> depending on the operator\'s tool of choice.\n> \n> Same idea for nagios/sensu/zabbix/$other_tool\n> \n> Jeremy: OpenStack is so large that setting up packaging, monitoring and log\n> aggregation for it isn\'t something that can be done easily, yet without\n> configuring any monitoring or log aggregation it is extremely difficult to\n> diagnose and fix issues in a running cloud, and without a packaging\n> pipeline fixes can\'t be deployed easily.\n> \n> As to whether to include these things in the deployment program, I would\n> say that I think the Deployment program is covering a \'delivery mechanism\',\n> whereas the things I am talking about are \'things to be delivered\'. Clint\n> and I had a quick chat on Friday during the TripleO session and I think we\n> are thinking along very similar lines.\n> \n\nIndeed we are. The Deployment program is more than just a delivery\nmechanism, but also an operations mechanism. We don\'t want to deliver\nan unrealistic system. But we are emphatically going to make sure that\nwe define good interfaces to allow other tools to be substituted on\neither side. The thinking would be that users who have proven\nconfigurations of various support systems can collaborate in an ops\nproject, and as long as they implement the configuration interfaces that\nwe define together, they can be swapped in and still take advantage of\nthe deployment program\'s work.\n\nLikewise, if somebody has a deployment model that they want to use other\nthan the one we\'ve been building, they can write to those interfaces\nand get the benefits of the work of others.\n\n> I want to have a bunch of repos with things that deployment tools\n> (including Fuel and TripleO and anything else that gets cooked up) can\n> easily consume to improve the operator experience.\n> I want a standard packaging system so that sites doing CI/CD today can all\n> build packages from their own repos and collaborate on the specs/process in\n> an upstream location, and I want it to be easily clone-able locally.\n> I want it all under a single program so that in the future we can\n> potentially reward and acknowledge people doing the work as contributors to\n> OpenStack.\n\nIndeed. I think TripleO can scale to more contributors, but it seems to\nme you have defined a clear point of collaboration that can be beneficial\nto the community independent of TripleO.\n\n\n','<CABf87X=4pzk7pfLm_ZFLPnCET1E8Fgo5wUGtVehut4=T22smdA@mail.gmail.com>',NULL),('<1415636981-sup-5665@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-10 08:35:40',-28800,'2014-11-10 16:35:40',NULL,'[openstack-dev] [TripleO] Seed Removal - The thing we forgot to\n	talk about at the summit..','Every summit there\'s at least one big thing that we somehow avoided\ntalking about as a group. We had fantastic discussions but we somehow\nforgot to talk about this.\n\nI\'d like to get this done _soon_. To be clear, the plan has always been\n(I forgot this and had to be reminded, it has been so long):\n\n* Make the undercloud a scaled-out seed (so point Galera and Rabbit at\nthe seed\'s Galera/Rabbit)\n* Once undercloud is up, shutdown seed and remove references to it.\n\nThe blocker for this is that if we then want to do an update of the\nundercloud, we can\'t touch Heat during said operation, because Heat\nwould lose state when the undercloud node it is running on got rebooted.\n\nWe have two ways to deal with that now:\n\n* Re-issue the update since we have update retry now\n* Use tripleo-ansible from outside of the undercloud itself or in a way\nin which it actively tries not to disrupt itself.\n\nI\'ll be working on this first by submitting a spec but I wanted to make\nsure any discussion of these points happens before I run off and try to\nwrite something.\n\n\n',NULL,NULL),('<1415650973.3966.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-10 20:22:50',0,'2014-11-10 20:22:50',NULL,'[openstack-dev] [neutron] Reminder: No meeting this week','Congrats! Another little mestery in the world, scary!\n\nOn Mon, 2014-11-10 at 12:22 -0600, Kyle Mestery wrote:\n> Since most folks are either freshly back from traveling, in the midst\n> of returning, or perhaps even with a new baby, we\'ll be skipping this\n> week\'s meeting. We\'ll resume next week at our normally scheduled time\n> [1] of 1400UTC on Tuesday.\n> \n> Thanks!\n> Kyle\n> \n> [1] https://wiki.openstack.org/wiki/Network/Meetings\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAL3VkVwv8FaRw5s+TYTS6U4zHvp+OhXG--=EcuddxcO-GF1Pxg@mail.gmail.com>',NULL),('<1415666031-sup-2202@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-10 16:36:19',-28800,'2014-11-11 00:36:19',NULL,'[openstack-dev] [all] Key signing at the summit?','Excerpts from Thomas Goirand\'s message of 2014-11-10 16:26:30 -0800:\n> On 10/27/2014 10:45 PM, Jeremy Stanley wrote:\n> > If there is interest in doing another Sassaman-Projected Method\n> > exercise at future events\n> \n> I really wish we do *not* reproduce what happened in Atlanta.\n> \n> We had a few seconds to check IDs, and sorry, but I\'m not familiar with\n> most US driver\'s licenses. It went so fast that I couldn\'t even catch up\n> with my printed list checkmarks.\n> \n> I also usually don\'t trust government IDs in general, and I very much\n> prefer to know people, and check that there\'s others in the project that\n> can vouch for their identity.\n> \n> Even better: I usually don\'t sign *at all* the keys from the people I\n> wont recognize if I see them again. Otherwise, I don\'t see the point at\n> all, if we just sign the keys of everyone in the room. We then better\n> have just an OpenStack keyring, just like there\'s a Debian developer\n> keyring, on which we delegate the trust to some kind of organization\n> (but this needs to be used for something...).\n> \n> If we do another key signing party in Vancouver, then I propose that:\n> \n> 1/ We take enough time (1 hour is the bare minimum)\n> 2/ We use that time so we can gather in small groups of people that we\n> don\'t know, and take the time to present ourselves to others, and tell\n> what we do, who we are, etc.\n> \n> It doesn\'t mater if we end-up signing a lot less keys. And for those\n> persons which we know already, it\'s easy to ask for a fingerprint copy,\n> and this can take just a few seconds (no need to even check for the\n> government IDs).\n> \n\nThomas, that is your prerogative, but most of us accept the Sassaman\nmethods for mass key-signing. Going slower is probably a good idea,\nbut the method itself isn\'t a problem for most of us.\n\n\n','<546157B6.3070404@debian.org>',NULL),('<1415717363.4607.6.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-11 15:49:23',3600,'2014-11-11 14:49:23',NULL,'[Openstack] Access Denied error in launching instance through\n devstack','Yes, to restart the services you can all the rejoin-stack.sh script. You\ncan navigate within the screens with commands. (E.g. ctl + a  \" for the\nscreen overview). Go to the service you want to restart and just stop it\nwith ctl + c and start it again using the last command from the history\n(arrow up). \n\nNot sure about your error. Can you provide more information in form of\nlogfiles (nova and neutron logs)? If enabled, they are located\nunder /opt/stack/logs/screen/screen-*. \n\nYou can enable detailed screen logging with the following parameters in\nyour local.conf\n\nVERBOSE=True\nSCREEN_LOGDIR=$DEST/logs/screen\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Tue, 2014-11-11 at 18:40 +0530, Srinivasreddy R wrote:\n> \n> hi,\n> i am trying to install openstack through devstack for  multinode\n> [controller , compute] setup . \n> facing error while launching the instance . using ubuntu14.04 . pls\n> help me how to debug .\n> and i want to restart the services do i need to run the script\n> rejoin-stack.sh\n>  \n>  \n> \n> below is the instance overview .\n>  \n> Instance Overview\n> Info\n> \n> ______________________________________________________________________\n> Name\n>         instance32\n> ID\n>         834a3a8a-5bf5-4d77-b00f-396dd2ca9324\n> Status\n>         Error\n> Availability Zone\n>         nova\n> Created\n>         Nov. 11, 2014, 8:37 p.m.\n> Uptime\n>         23 minutes\n> Fault\n> \n> ______________________________________________________________________\n> Message\n>         <HTML><HEAD> <TITLE>Access Denied</TITLE> <STYLE\n>         type=\"text/css\"> body{margin:10% 0 0\n>         18%;font-family:arial}blockquote{margin-left:0}.cont{width:80%} .summ{background-color:#EC8025;color:#fff;border-radius:5px 5px 0 0;font-size:18px;padding:3px 3px 3p\n> Code\n>         500\n> Details\n>         File \"/opt/stack/nova/nova/compute/manager.py\", line 290, in\n>         decorated_function return function(self, context, *args,\n>         **kwargs) File \"/opt/stack/nova/nova/compute/manager.py\", line\n>         2069, in run_instance do_run_instance() File\n>         \"/opt/stack/nova/nova/openstack/common/lockutils.py\", line\n>         249, in inner return f(*args, **kwargs) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 2068, in\n>         do_run_instance legacy_bdm_in_spec) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 1201, in\n>         _run_instance notify(\"error\", fault=e) # notify that build\n>         failed File\n>         \"/opt/stack/nova/nova/openstack/common/excutils.py\", line 68,\n>         in __exit__ six.reraise(self.type_, self.value, self.tb) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 1185, in\n>         _run_instance instance, image_meta, legacy_bdm_in_spec) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 1349, in\n>         _build_instance filter_properties, bdms, legacy_bdm_in_spec)\n>         File \"/opt/stack/nova/nova/compute/manager.py\", line 1395, in\n>         _reschedule_or_error self._log_original_error(exc_info,\n>         instance_uuid) File\n>         \"/opt/stack/nova/nova/openstack/common/excutils.py\", line 68,\n>         in __exit__ six.reraise(self.type_, self.value, self.tb) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 1390, in\n>         _reschedule_or_error bdms, requested_networks) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 2116, in\n>         _shutdown_instance self._try_deallocate_network(context,\n>         instance, requested_networks) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 2080, in\n>         _try_deallocate_network\n>         self._set_instance_error_state(context, instance[\'uuid\']) File\n>         \"/opt/stack/nova/nova/openstack/common/excutils.py\", line 68,\n>         in __exit__ six.reraise(self.type_, self.value, self.tb) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 2075, in\n>         _try_deallocate_network self._deallocate_network(context,\n>         instance, requested_networks) File\n>         \"/opt/stack/nova/nova/compute/manager.py\", line 1769, in\n>         _deallocate_network context, instance,\n>         requested_networks=requested_networks) File\n>         \"/opt/stack/nova/nova/network/neutronv2/api.py\", line 410, in\n>         deallocate_for_instance data =\n>         neutron.list_ports(**search_opts) File\n>         \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 98, in with_params ret = self.function(instance, *args, **kwargs) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 316, in list_ports **_params) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1338, in list for r in self._pagination(collection, path, **params): File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1351, in _pagination res = self.get(path, params=params) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1324, in get headers=headers, params=params) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1301, in retry_request headers=headers, params=params) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1255, in do_request self._handle_fault_response(status_code, replybody) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 1220, in _handle_fault_response exception_handler_v20(status_code, des_error_body) File \"/opt/stack/python-neutronclient/neutronclient/v2_0/client.py\", line 79, in exception_handler_v20 message=message) \n> Created\n>         Nov. 11, 2014, 8:37 p.m.\n> Specs\n> \n> ______________________________________________________________________\n> Flavor\n>         m1.nano\n> RAM\n>         64MB\n> VCPUs\n>         1 VCPU\n> Disk\n>         0GB\n> IP Addresses\n> \n> ______________________________________________________________________\n> Security Groups\n> \n> ______________________________________________________________________\n> Meta\n> \n> ______________________________________________________________________\n> Key Name\n>         None\n> Image Name\n>         cirros-0.3.1-x86_64-uec\n> Volumes Attached\n> \n> ______________________________________________________________________\n> Volume\n>         No volumes attached.\n>  \n> \n>  \n> \n> thanks,\n> \n> srinivas.\n> \n>  \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<CAJP4VWh5_dxDtZpEJROhMk3sU48YZ=pk=in2SfzQ2xt-zcLUdw@mail.gmail.com>',NULL),('<1415717703.22918.0.camel@aleeredhat.laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-11 09:55:03',-18000,'2014-11-11 14:55:03',NULL,'[openstack-dev] [Barbican][OSSG] Mid Cycle Attendance /\n Crossover.','+1\n\nOn Tue, 2014-11-11 at 08:49 -0500, Nathan Reller wrote:\n> > How many people would want to attend both the OSSG mid-cycle and the Barbican one?\n> \n> +1\n> \n> -Nate\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAMKdHYpEnAvT_3_PbLJny9gr47OnEPMiezW99jHO+jxQxL48xw@mail.gmail.com>',NULL),('<1415720080-sup-771@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-11 07:38:07',-28800,'2014-11-11 15:38:07',NULL,'[openstack-dev] [all] Key signing at the summit?','Excerpts from Jeremy Stanley\'s message of 2014-11-11 06:31:57 -0800:\n> On 2014-11-10 23:55:59 -0500 (-0500), Adam Young wrote:\n> > Um, yeah. What Zigo said.\n> \n> Agreed. I tried out keybase.io (but not the insane private key\n> hosting obviously), was unimpressed and have since deleted my\n> account. I\'ll acknowledge that as someone who already doesn\'t use\n> social media and considers it a blight on the Internet as a whole, I\n> was likely not their target audience anyway.\n> \n\nIt\'s sort of odd that you think bringing the same capability we have\nhad for decades with IRC to web users is a blight on the internet. ;)\nThe blight is the people being stupid .. not the technology in use.\n\n> I respect that they\'re trying to bring OpenPGP and\n> cryptocommunication in general to a wider audience, but sort of\n> thought the crypto community had already learned the \"trust us with\n> your private key\" lesson during the Hushmail incident of 2007. I\n> fear keybase.io is doomed to repeat that unfortunate bit of history.\n> \n\nYeah storing private keys is the dumb part.\n\n> For anyone who wants to find my public key, it\'s already in the SKS\n> pool and replicated to most other popular keyserver networks replete\n> with accumulated signatures.\n\nThey\'re simply trying to close the loop between the identification\nprocess most internet users have now (social networking) and OpenPGP keys.\nHowever, I think alienating those who understand it by storing private\nkeys is not a winning strategy.\n\n\n','<20141111143156.GZ2497@yuggoth.org>',NULL),('<1415724096.5943.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-11 10:41:36',-21600,'2014-11-11 16:41:36',NULL,'[Openstack] nova \'absolute-limits\': where does it get the\n totalInstancesUsed from? (they are wrong)','On Tue, 2014-11-11 at 08:53 -0500, Don Waterloo wrote:\n> In horizon, i see \'14 instances used for me. This in turn comes from\n> the same source as \'nova absolute-limits\'.\n> The problem is, I have 0 instances in use.\n> I even removed all instances for my user-id and my project-id from the\n> nova database. Now \'select count(*) from instances where user_id =\n> \'XXXX or project_id = YYYY\'\' returns 0 for me. But I still see this\n> \'14\' come out.\n\nIf I recall correctly, this data is acquired from the quota_usages\ntable, which keeps track of the number of instances in use, as well as\nthe number of outstanding reservations.  If you\'re in the habit of\nmanually modifying your database, that could cause the number to be out\nof sync; of course, bugs could also cause a desync.  By default, nova\ndoes not automatically perform a quota usage resync, but this can be\nenabled using one of the two options \"until_refresh\" or \"max_age\", in\nthe [DEFAULT] section.  You could try setting until_refresh to a\nsuitable value, say, 50, then restarting nova.  The value \"14\" may still\nshow until the next time you request an instance, at which time it\n*should* refresh.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAKrvkGdcv=ZhGiXxxV+cdkbyp7XYQVSALKWdA4ioMRT3PQjC-g@mail.gmail.com>',NULL),('<1415727555-sup-6116@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-11 10:12:33',-28800,'2014-11-11 18:12:33',NULL,'[openstack-dev] [Heat] Conditionals,\n	was: New function: first_nonnull','Excerpts from Alexis Lee\'s message of 2014-11-10 09:34:13 -0800:\n> Zane Bitter said on Fri, Nov 07, 2014 at 12:35:09AM +0100:\n> > Crazy thought: why not just implement conditionals? We had a\n> > proto-spec for them started at one point...\n> \n> I didn\'t know that was on the table :)\n> \n> How about we support YAQL expressions? https://github.com/ativelkov/yaql\n> Plus some HOFs (higher-order functions) like cond, map, filter, foldleft\n> etc?\n> \n> Here\'s first_nonnull:\n> \n>   config:\n>     Fn::Select\n>       - 0\n>       filter:\n>         - yaql: \"$.0 != null\"\n>         - <item1>\n>         - <itemN>\n> \n> Making the \'yaql\' function eponymous means we can easily plug other\n> expression languages in later if we choose.\n> \n\nCool. I think this aligns nicely with my suggestion at the summit that\nwe also allow writing functions in javascript. This would allow people\nto write their own first_nonnull/coalesce until we have a chance to add\nit:\n\n  config:\n    embed:\n      lang: javascript\n      args: - item1\n            - item2\n      code: |\n        for (arg in args) {\n          if (arg !== null) {\n            return arg\n          }\n        }\n        return null;\n\nI\'d really love to have this functionality but I doubt I\'ll have time to\nspec and land it. Does anybody else think this functionality would be a\ngood way to allow template authors flexibility that they desire?\n\n\n','<20141110173413.GA6157@hp.com>',NULL),('<1415758461-sup-3975@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-11 18:17:04',-28800,'2014-11-12 02:17:04',NULL,'[openstack-dev] [neutron] Neutron mid-cycle announcement','Just as a counter-point: The entire reason that a mid-cycle is an\nimportant thing to do is to achieve higher bandwidth communication between\ncontributors. We can do Hangouts all the time and that\'s certainly a\nuseful thing. But making the people in the room who have high bandwidth\nslow down for those who are at the other end of low-bandwidth may not be\na productive thing as a whole.\n\nAnyway, just a thought as somebody who has tried this before.\n\nExcerpts from Marios Andreou\'s message of 2014-11-11 08:56:05 -0800:\n> +1 would be great to at least have a hangout going\n> \n> \n> \n> _sent from my mobile device, sorry for spacing/spelling/top-posting/.*_\n> \n> -----Original Message-----\n> From: Kyle Mestery [mestery at mestery.com]\n> Received: Tuesday, 11 Nov 2014, 16:14\n> To: OpenStack Development Mailing List (not for usage questions) [openstack-dev at lists.openstack.org]\n> Subject: Re: [openstack-dev] [neutron] Neutron mid-cycle announcement\n> \n> On Tue, Nov 11, 2014 at 8:00 AM, Gary Kotton <gkotton at vmware.com> wrote:\n> > Hi,\n> > For those unable to attend will there be an option of remote access?\n> > Thanks\n> > Gary\n> >\n> We\'ll do our best to make this happen. I\'ll see if we can get a Google\n> Hangout going in the room, and make sure people are on IRC.\n> \n> Thanks!\n> Kyle\n> \n> > On 11/11/14, 3:04 PM, \"Kyle Mestery\" <mestery at mestery.com> wrote:\n> >\n> >>Hi folks:\n> >>\n> >>Apologies for the delay in announcing the Neutron mid-cycle, but I was\n> >>confirming the details up until last night. I\'ve captured the details\n> >>on an etherpad here [1]. The dates are December 8-10\n> >>(Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,\n> >>USA.\n> >>\n> >>We\'re still collecting information on hotels which should be on the\n> >>etherpad later today.\n> >>\n> >>Thanks, looking forward to seeing everyone I missed in Paris!\n> >>Kyle\n> >>\n> >>[1] https://etherpad.openstack.org/p/neutron-kilo-midcycle\n> >>\n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >>OpenStack-dev at lists.openstack.org\n> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1294300487.9740491.1415724965102.JavaMail.zimbra@zmail14.collab.prod.int.phx2.redhat.com>',NULL),('<1415803948-sup-8201@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 07:10:58',-28800,'2014-11-12 15:10:58',NULL,'[openstack-dev] [Heat] Conditionals,\n	was: New function: first_nonnull','Excerpts from Zane Bitter\'s message of 2014-11-11 13:06:17 -0800:\n> On 11/11/14 13:34, Ryan Brown wrote:\n> > I am strongly against allowing arbitrary Javascript functions for\n> > complexity reasons. It\'s already difficult enough to get meaningful\n> > errors when you **** up your YAML syntax.\n> \n> Agreed, and FWIW literally everyone that Clint has pitched the JS idea \n> to thought it was crazy ;)\n> \n\nSo far nobody has stepped up to defend me, so I\'ll accept that maybe\npeople do think it is crazy. What I\'m really confused by is why we have\na new weird ugly language like YAQL (sorry, it, like JQ, is hideous),\nand that would somehow be less crazy than a well known mature language\nthat has always been meant for embedding such as javascript.\n\nAnyway, I\'d prefer YAQL over trying to get the intrinsic functions in\nHOT just right. Users will want to do things we don\'t expect. I say, let\nthem, or large sections of the users will simply move on to something\nelse.\n\n\n','<54627A49.8050300@redhat.com>',NULL),('<1415814531-sup-6369@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 10:00:18',-28800,'2014-11-12 18:00:18',NULL,'[openstack-dev] [Heat] Conditionals,\n	was: New function: first_nonnull','Excerpts from Zane Bitter\'s message of 2014-11-12 08:42:44 -0800:\n> On 12/11/14 10:10, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-11-11 13:06:17 -0800:\n> >> On 11/11/14 13:34, Ryan Brown wrote:\n> >>> I am strongly against allowing arbitrary Javascript functions for\n> >>> complexity reasons. It\'s already difficult enough to get meaningful\n> >>> errors when you **** up your YAML syntax.\n> >>\n> >> Agreed, and FWIW literally everyone that Clint has pitched the JS idea\n> >> to thought it was crazy ;)\n> >>\n> >\n> > So far nobody has stepped up to defend me,\n> \n> I\'ll defend you, but I can\'t defend the idea :)\n> \n> > so I\'ll accept that maybe\n> > people do think it is crazy. What I\'m really confused by is why we have\n> > a new weird ugly language like YAQL (sorry, it, like JQ, is hideous),\n> \n> Agreed, and appealing to its similarity with Perl or PHP (or BASIC!) is \n> probably not the way to win over Python developers :D\n> \n> > and that would somehow be less crazy than a well known mature language\n> > that has always been meant for embedding such as javascript.\n> \n> JS is a Turing-complete language, it\'s an entirely different kettle of \n> fish to a domain-specific language that is inherently safe to interpret \n> from user input. Sure, we can try to lock it down. It\'s a very tricky \n> job to get right. (Plus it requires a new external dependency of unknown \n> quality... honestly if you\'re going to embed a Turing-complete language, \n> Python is a much more obvious choice than JS.)\n> \n\nThere\'s a key difference though. Python was never designed to be run\nfrom untrusted sources. Javascript was _from the beginning_. There are\nat least two independent javascript implementations which both have been\ndesigned from the ground up to run code from websites in the local\ninterpreter. From the standpoint of Heat, it would be even easier to do\nthis.\n\nPerhaps I can carve out some of that negative-1000-days of free time I\nhave and I can make it a resource plugin, with the properties being code\nand references to other resources, and the attributes being the return.\n\n> > Anyway, I\'d prefer YAQL over trying to get the intrinsic functions in\n> > HOT just right. Users will want to do things we don\'t expect. I say, let\n> > them, or large sections of the users will simply move on to something\n> > else.\n> \n> The other side of that argument is that users are doing one of two \n> things with data they have obtained from resources in the template:\n> \n> 1) Passing data to software deployments\n> 2) Passing data to other resources\n> \n> In case (1) they can easily transform the data into whatever format they \n> want using their own scripts, running on their own server.\n> \n> In case (2), if it\'s not easy for them to just do what they want without \n> having to perform this kind of manipulation, we have failed to design \n> good resources. And if we give people the tools to just paper over the \n> problem, we\'ll never hear about it so we can correct it at the source, \n> just launch a thousand hard-to-maintain hacks into the world.\n> \n\nI for one would rather serve the users than ourselves, and preventing\nthem from papering over the problems so they have to whine at us is a\nself-serving agenda.\n\nAs a primary whiner about Heat for a long time, I respect a lot that\nthis development team _bends over backwards_ to respond to user\nrequests. It\'s amazing that way.\n\nHowever, I think to grow beyond open source savvy, deeply integrated\nusers like me, one has to let the users solve their own problems. They\'ll\nknow that their javascript or YAQL is debt sometimes, and they can\ncome to Heat\'s development community with suggestions like \"If you had\na coalesce function I wouldn\'t need to write it in javascript\". But if\nyou don\'t give them _something_, they\'ll just move on.\n\nAnyway, probably looking further down the road than I need to, but\nplease keep an open mind for this idea, as users tend to use tools that\nsolve their problem _and_ get out of their way in all other cases.\n\n\n','<54638E04.3060600@redhat.com>',NULL),('<1415830560-sup-8790@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 14:30:11',-28800,'2014-11-12 22:30:11',NULL,'[openstack-dev] [TripleO] [Ironic] [Cinder] \"Baremetal volumes\" --\n	how to model direct attached storage','Each summit since we created \"preserve ephemeral\" mode in Nova, I have\nsome conversations where at least one person\'s brain breaks for a\nsecond. There isn\'t always alcohol involved before, there almost\ncertainly is always a drink needed after. The very term is vexing, and I\nthink we have done ourselves a disservice to have it, even if it was the\nbest option at the time.\n\nTo be clear, in TripleO, we need a way to keep the data on a local\ndirect attached storage device while deploying a new image to the box.\nIf we were on VMs, we\'d attach volumes, and just deploy new VMs and move\nthe volume over. If we had a SAN, we\'d just move the LUN\'s. But at some\npoint when you deploy a cloud you\'re holding data that is expensive to\nreplicate all at once, and so you\'d rather just keep using the same\nserver instead of trying to move the data.\n\nSince we don\'t have baremetal Cinder, we had to come up with a way to\ndo this, so we used Nova rebuild, and slipped it a special command that\nsaid \"don\'t overwrite the partition you\'d normally make the \'ephemeral\'\"\npartition. This works fine, but it is confusing and limiting. We\'d like\nsomething better.\n\nI had an interesting discussion with Devananda in which he suggested an\nalternative approach. If we were to bring up cinder-volume on our deploy\nramdisks, and configure it in such a way that it claimed ownership of\nthe section of disk we\'d like to preserve, then we could allocate that\nstorage as a volume. From there, we could boot from volume, or \"attach\"\nthe volume to the instance (which would really just tell us how to find\nthe volume). When we want to write a new image, we can just delete the old\ninstance and create a new one, scheduled to wherever that volume already\nis. This would require the nova scheduler to have a filter available\nwhere we could select a host by the volumes it has, so we can make sure to\nsend the instance request back to the box that still has all of the data.\n\nAlternatively we can keep on using rebuild, but let the volume model the\npreservation rather than our special case.\n\nThoughts? Suggestions? I feel like this might take some time, but it is\nnecessary to consider it now so we can drive any work we need to get it\ndone soon.\n\n\n',NULL,NULL),('<1415841647448.67019c0d@Nodemailer>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-12 17:20:48',-28800,'2014-11-13 01:20:48',NULL,'[Openstack] [Nova Juno]','?\nRaghu\n\n\nOn Wednesday, Nov 12, 2014 at 2:13 PM, John Griffith <john.griffith at solidfire.com>, wrote:\nOn Wed, Nov 12, 2014 at 11:16 AM, Amit Anand <aanand at viimed.com> wrote:\n\n> Hi all,\n\n>\n\n> So been trying to figure out why this is happening I was hoping yall could\n\n> maybe shed some light on it asI really would not like to have recreate\n\n> everything on my controller node!\n\n>\n\n> So whenever I try to sync the nova database:\n\n> su -s /bin/sh -c \"nova-manage db sync\" nova\n\n>\n\n> I get this error in my logs:\n\n> 2014-11-12 13:09:45.323 29721 TRACE nova     raise operational_error\n\n> 2014-11-12 13:09:45.323 29721 TRACE nova OperationalError:\n\n> (OperationalError) (1045, \"Access denied for user \'nova\'@\'localhost\' (using\n\n> password: YES)\") None None\n\n>\n\n>\n\n> Ive tried dropping and recreating the nova table but still keep getting the\n\n> same error. Ive looked into the mysql database for the users and this is\n\n> what I have:\n\n>\n\n> Database changed\n\n> MariaDB [mysql]> SELECT user,password,host FROM user;\n\n> +----------+-------------------------------------------+-----------+\n\n> | user     | password                                  | host      |\n\n> +----------+-------------------------------------------+-----------+\n\n> | root     | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n\n> | root     | *7088873CEA983CB57491834389F9BB9369B9D756 | 127.0.0.1 |\n\n> | root     | *7088873CEA983CB57491834389F9BB9369B9D756 | ::1       |\n\n> | keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n\n> | keystone | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n\n> | glance   | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n\n> | glance   | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n\n> | neutron  | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n\n> | neutron  | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n\n> | nova     | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n\n> | nova     | *7088873CEA983CB57491834389F9BB9369B9D756 | localhost |\n\n> | root     | *7088873CEA983CB57491834389F9BB9369B9D756 | %         |\n\n> +----------+-------------------------------------------+-----------+\n\n> 12 rows in set (0.00 sec)\n\n>\n\n>\n\n> Any ideas on how to fix this would be greatly appreciated. Thank you very\n\n> much!\n\n>\n\n> Amit\n\n>\n\n> _______________________________________________\n\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n> Post to     : openstack at lists.openstack.org\n\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n>\n\n\nI seem to recall hitting something like this in an upgrade I did, and\n\nI\'m not sure but check your permissions on your /etc/nova directory,\n\nparticularly nova.conf.  I ran into the same problem and that\'s what\n\nit turned out to be.?\n[rvv]\n\n\nMost likely the mysql password and configuration file don\'t match.?\n_______________________________________________\n\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\nPost to     : openstack at lists.openstack.org\n\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141112/adcedbd6/attachment.html>\n\n','<CA+qL3LU=aniCRtOEwN=S-DCEWLkvROqj0tD6fkOyM9Bj8xYe6w@mail.gmail.com>',NULL),('<1415889808-sup-7496@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 06:58:54',-28800,'2014-11-13 14:58:54',NULL,'[openstack-dev] [Heat] Using Job Queues for timeout ops','Excerpts from Zane Bitter\'s message of 2014-11-13 05:54:03 -0800:\n> On 13/11/14 03:29, Murugan, Visnusaran wrote:\n> > Hi all,\n> >\n> > Convergence-POC distributes stack operations by sending resource actions\n> > over RPC for any heat-engine to execute. Entire stack lifecycle will be\n> > controlled by worker/observer notifications. This distributed model has\n> > its own advantages and disadvantages.\n> >\n> > Any stack operation has a timeout and a single engine will be\n> > responsible for it. If that engine goes down, timeout is lost along with\n> > it. So a traditional way is for other engines to recreate timeout from\n> > scratch. Also a missed resource action notification will be detected\n> > only when stack operation timeout happens.\n> >\n> > To overcome this, we will need the following capability:\n> >\n> > 1.Resource timeout (can be used for retry)\n> \n> I don\'t believe this is strictly needed for phase 1 (essentially we \n> don\'t have it now, so nothing gets worse).\n> \n\nWe do have a stack timeout, and it stands to reason that we won\'t have a\nsingle box with a timeout greenthread after this, so a strategy is\nneeded.\n\n> For phase 2, yes, we\'ll want it. One thing we haven\'t discussed much is \n> that if we used Zaqar for this then the observer could claim a message \n> but not acknowledge it until it had processed it, so we could have \n> guaranteed delivery.\n>\n\nFrankly, if oslo.messaging doesn\'t support reliable delivery then we\nneed to add it. Zaqar should have nothing to do with this and is, IMO, a\npoor choice at this stage, though I like the idea of using it in the\nfuture so that we can make Heat more of an outside-the-cloud app.\n\n> > 2.Recover from engine failure (loss of stack timeout, resource action\n> > notification)\n> >\n> > Suggestion:\n> >\n> > 1.Use task queue like celery to host timeouts for both stack and resource.\n> \n> I believe Celery is more or less a non-starter as an OpenStack \n> dependency because it uses Kombu directly to talk to the queue, vs. \n> oslo.messaging which is an abstraction layer over Kombu, Qpid, ZeroMQ \n> and maybe others in the future. i.e. requiring Celery means that some \n> users would be forced to install Rabbit for the first time.\n>\n> One option would be to fork Celery and replace Kombu with oslo.messaging \n> as its abstraction layer. Good luck getting that maintained though, \n> since Celery _invented_ Kombu to be it\'s abstraction layer.\n> \n\nA slight side point here: Kombu supports Qpid and ZeroMQ. Oslo.messaging\nis more about having a unified API than a set of magic backends. It\nactually boggles my mind why we didn\'t just use kombu (cue 20 reactions\nwith people saying it wasn\'t EXACTLY right), but I think we\'re committed\nto oslo.messaging now. Anyway, celery would need no such refactor, as\nkombu would be able to access the same bus as everything else just fine.\n\n> > 2.Poll database for engine failures and restart timers/ retrigger\n> > resource retry (IMHO: This would be a traditional and weighs heavy)\n> >\n> > 3.Migrate heat to use TaskFlow. (Too many code change)\n> \n> If it\'s just handling timed triggers (maybe this is closer to #2) and \n> not migrating the whole code base, then I don\'t see why it would be a \n> big change (or even a change at all - it\'s basically new functionality). \n> I\'m not sure if TaskFlow has something like this already. If not we \n> could also look at what Mistral is doing with timed tasks and see if we \n> could spin some of it out into an Oslo library.\n> \n\nI feel like it boils down to something running periodically checking for\nscheduled tasks that are due to run but have not run yet. I wonder if we\ncan actually look at Ironic for how they do this, because Ironic polls\npower state of machines constantly, and uses a hash ring to make sure\nonly one conductor is polling any one machine at a time. If we broke\nstacks up into a hash ring like that for the purpose of singleton tasks\nlike timeout checking, that might work out nicely.\n\n\n','<5464B7FB.4050900@redhat.com>',NULL),('<1415890740-sup-725@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 07:10:34',-28800,'2014-11-13 15:10:34',NULL,'[openstack-dev] [Heat] Using Job Queues for timeout ops','Excerpts from Joshua Harlow\'s message of 2014-11-13 00:45:07 -0800:\n> A question;\n> \n> How is using something like celery in heat vs taskflow in heat (or at least concept [1]) \'to many code change\'.\n> \n> Both seem like change of similar levels ;-)\n> \n\nI\'ve tried a few times to dive into refactoring some things to use\nTaskFlow at a shallow level, and have always gotten confused and\nfrustrated.\n\nThe amount of lines that are changed probably is the same. But the\nmassive shift in thinking is not an easy one to make. It may be worth some\nthinking on providing a shorter bridge to TaskFlow adoption, because I\'m\na huge fan of the idea and would _start_ something with it in a heartbeat,\nbut refactoring things to use it feels really weird to me.\n\n> What was your metric for determining the code change either would have (out of curiosity)?\n> \n> Perhaps u should look at [2], although I\'m unclear on what the desired functionality is here.\n> \n> Do u want the single engine to transfer its work to another engine when it \'goes down\'? If so then the jobboard model + zookeper inherently does this.\n> \n> Or maybe u want something else? I\'m probably confused because u seem to be asking for resource timeouts + recover from engine failure (which seems like a liveness issue and not a resource timeout one), those 2 things seem separable.\n> \n\nI agree with you on this. It is definitely a liveness problem. The\nresource timeout isn\'t something I\'ve seen discussed before. We do have\na stack timeout, and we need to keep on honoring that, but we can do\nthat with a job that sleeps for the stack timeout if we have a liveness\nguarantee that will resurrect the job (with the sleep shortened by the\ntime since stack-update-time) somewhere else if the original engine\ncan\'t complete the job.\n\n> [1] http://docs.openstack.org/developer/taskflow/jobs.html\n> \n> [2] http://docs.openstack.org/developer/taskflow/examples.html#jobboard-producer-consumer-simple\n> \n> On Nov 13, 2014, at 12:29 AM, Murugan, Visnusaran <visnusaran.murugan at hp.com> wrote:\n> \n> > Hi all,\n> >  \n> > Convergence-POC distributes stack operations by sending resource actions over RPC for any heat-engine to execute. Entire stack lifecycle will be controlled by worker/observer notifications. This distributed model has its own advantages and disadvantages.\n> >  \n> > Any stack operation has a timeout and a single engine will be responsible for it. If that engine goes down, timeout is lost along with it. So a traditional way is for other engines to recreate timeout from scratch. Also a missed resource action notification will be detected only when stack operation timeout happens.\n> >  \n> > To overcome this, we will need the following capability:\n> > 1.       Resource timeout (can be used for retry)\n> > 2.       Recover from engine failure (loss of stack timeout, resource action notification)\n> >  \n> >  \n> > Suggestion:\n> > 1.       Use task queue like celery to host timeouts for both stack and resource.\n> > 2.       Poll database for engine failures and restart timers/ retrigger resource retry (IMHO: This would be a traditional and weighs heavy)\n> > 3.       Migrate heat to use TaskFlow. (Too many code change)\n> >  \n> > I am not suggesting we use Task Flow. Using celery will have very minimum code change. (decorate appropriate functions)\n> >  \n> >  \n> > Your thoughts.\n> >  \n> > -Vishnu\n> > IRC: ckmvishnu\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<BLU436-SMTP11976214E23644E79794B1FD88F0@phx.gbl>',NULL),('<1415902420-sup-7384@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 10:59:56',-28800,'2014-11-13 18:59:56',NULL,'[openstack-dev] [Heat] Using Job Queues for timeout ops','Excerpts from Zane Bitter\'s message of 2014-11-13 09:55:43 -0800:\n> On 13/11/14 09:58, Clint Byrum wrote:\n> > Excerpts from Zane Bitter\'s message of 2014-11-13 05:54:03 -0800:\n> >> On 13/11/14 03:29, Murugan, Visnusaran wrote:\n> >>> Hi all,\n> >>>\n> >>> Convergence-POC distributes stack operations by sending resource actions\n> >>> over RPC for any heat-engine to execute. Entire stack lifecycle will be\n> >>> controlled by worker/observer notifications. This distributed model has\n> >>> its own advantages and disadvantages.\n> >>>\n> >>> Any stack operation has a timeout and a single engine will be\n> >>> responsible for it. If that engine goes down, timeout is lost along with\n> >>> it. So a traditional way is for other engines to recreate timeout from\n> >>> scratch. Also a missed resource action notification will be detected\n> >>> only when stack operation timeout happens.\n> >>>\n> >>> To overcome this, we will need the following capability:\n> >>>\n> >>> 1.Resource timeout (can be used for retry)\n> >>\n> >> I don\'t believe this is strictly needed for phase 1 (essentially we\n> >> don\'t have it now, so nothing gets worse).\n> >>\n> >\n> > We do have a stack timeout, and it stands to reason that we won\'t have a\n> > single box with a timeout greenthread after this, so a strategy is\n> > needed.\n> \n> Right, that was 2, but I was talking specifically about the resource \n> retry. I think we agree on both points.\n> \n> >> For phase 2, yes, we\'ll want it. One thing we haven\'t discussed much is\n> >> that if we used Zaqar for this then the observer could claim a message\n> >> but not acknowledge it until it had processed it, so we could have\n> >> guaranteed delivery.\n> >>\n> >\n> > Frankly, if oslo.messaging doesn\'t support reliable delivery then we\n> > need to add it.\n> \n> That is straight-up impossible with AMQP. Either you ack the message and \n> risk losing it if the worker dies before processing is complete, or you \n> don\'t ack the message until it\'s processed and you become a blocker for \n> every other worker trying to pull jobs off the queue. It works fine when \n> you have only one worker; otherwise not so much. This is the crux of the \n> whole \"why isn\'t Zaqar just Rabbit\" debate.\n> \n\nI\'m not sure we have the same understanding of AMQP, so hopefully we can\nclarify here. This stackoverflow answer echoes my understanding:\n\nhttp://stackoverflow.com/questions/17841843/rabbitmq-does-one-consumer-block-the-other-consumers-of-the-same-queue\n\nNot ack\'ing just means they might get retransmitted if we never ack. It\ndoesn\'t block other consumers. And as the link above quotes from the\nAMQP spec, when there are multiple consumers, FIFO is not guaranteed.\nOther consumers get other messages.\n\nSo just add the ability for a consumer to read, work, ack to\noslo.messaging, and this is mostly handled via AMQP. Of course that\nalso likely means no zeromq for Heat without accepting that messages\nmay be lost if workers die.\n\nBasically we need to add something that is not \"RPC\" but instead\n\"jobqueue\" that mimics this:\n\nhttp://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo/messaging/rpc/dispatcher.py#n131\n\nI\'ve always been suspicious of this bit of code, as it basically means\nthat if anything fails between that call, and the one below it, we have\nlost contact, but as long as clients are written to re-send when there\nis a lack of reply, there shouldn\'t be a problem. But, for a job queue,\nthere is no reply, and so the worker would dispatch, and then\nacknowledge after the dispatched call had returned (including having\ncompleted the step where new messages are added to the queue for any\nnewly-possible children).\n\nJust to be clear, I believe what Zaqar adds is the ability to peek at\na specific message ID and not affect it in the queue, which is entirely\ndifferent than ACK\'ing the ones you\'ve already received in your session.\n\n> Most stuff in OpenStack gets around this by doing synchronous calls \n> across oslo.messaging, where there is an end-to-end ack. We don\'t want \n> that here though. We\'ll probably have to make do with having ways to \n> recover after a failure (kick off another update with the same data is \n> always an option). The hard part is that if something dies we don\'t \n> really want to wait until the stack timeout to start recovering.\n>\n\nI fully agree. Josh\'s point about using a coordination service like\nZookeeper to maintain liveness is an interesting one here. If we just\nmake sure that all the workers that have claimed work off the queue are\nalive, that should be sufficient to prevent a hanging stack situation\nlike you describe above.\n\n> > Zaqar should have nothing to do with this and is, IMO, a\n> > poor choice at this stage, though I like the idea of using it in the\n> > future so that we can make Heat more of an outside-the-cloud app.\n> \n> I\'m inclined to agree that it would be hard to force operators to deploy \n> Zaqar in order to be able to deploy Heat, and that we should probably be \n> cautious for that reason.\n> \n> That said, from a purely technical point of view it\'s not a poor choice \n> at all - it has *exactly* the semantics we want (unlike AMQP), and at \n> least to the extent that the operator wants to offer Zaqar to users \n> anyway it completely eliminates a whole backend that they would \n> otherwise have to deploy. It\'s a tragedy that all of OpenStack has not \n> been designed to build upon itself in this way and it causes me physical \n> pain to know that we\'re about to perpetuate it.\n> \n> >>> 2.Recover from engine failure (loss of stack timeout, resource action\n> >>> notification)\n> >>>\n> >>> Suggestion:\n> >>>\n> >>> 1.Use task queue like celery to host timeouts for both stack and resource.\n> >>\n> >> I believe Celery is more or less a non-starter as an OpenStack\n> >> dependency because it uses Kombu directly to talk to the queue, vs.\n> >> oslo.messaging which is an abstraction layer over Kombu, Qpid, ZeroMQ\n> >> and maybe others in the future. i.e. requiring Celery means that some\n> >> users would be forced to install Rabbit for the first time.\n> >>\n> >> One option would be to fork Celery and replace Kombu with oslo.messaging\n> >> as its abstraction layer. Good luck getting that maintained though,\n> >> since Celery _invented_ Kombu to be it\'s abstraction layer.\n> >>\n> >\n> > A slight side point here: Kombu supports Qpid and ZeroMQ. Oslo.messaging\n> \n> You\'re right about Kombu supporting Qpid, it appears they added it. I \n> don\'t see ZeroMQ on the list though:\n> \n> http://kombu.readthedocs.org/en/latest/userguide/connections.html#transport-comparison\n> \n\nThey, confusingly, call it zmq, and it may not be in a recent release:\n\nhttps://github.com/celery/kombu/blob/master/kombu/transport/zmq.py\n\n> > is more about having a unified API than a set of magic backends. It\n> > actually boggles my mind why we didn\'t just use kombu (cue 20 reactions\n> > with people saying it wasn\'t EXACTLY right), but I think we\'re committed\n> \n> Well, we also have to take into account the fact that Qpid support was \n> added only during the last 9 months, whereas oslo.messaging was \n> implemented 3 years ago and time travel hasn\'t been invented yet (for \n> any definition of \'yet\').\n> \n\nGo back in time 3 years ago, and perhaps we could have done all the work\nwe\'ve done in kombu. Hindsight though.\n\n> > to oslo.messaging now. Anyway, celery would need no such refactor, as\n> > kombu would be able to access the same bus as everything else just fine.\n> \n> Interesting, so that would make it easier to get Celery added to the \n> global requirements, although we\'d likely still have headaches to deal \n> with around configuration.\n> \n\nYeah, I\'m not advocating for celery, just pointing out that it has\nbecome more like what we already deploy. :)\n\n> >>> 2.Poll database for engine failures and restart timers/ retrigger\n> >>> resource retry (IMHO: This would be a traditional and weighs heavy)\n> >>>\n> >>> 3.Migrate heat to use TaskFlow. (Too many code change)\n> >>\n> >> If it\'s just handling timed triggers (maybe this is closer to #2) and\n> >> not migrating the whole code base, then I don\'t see why it would be a\n> >> big change (or even a change at all - it\'s basically new functionality).\n> >> I\'m not sure if TaskFlow has something like this already. If not we\n> >> could also look at what Mistral is doing with timed tasks and see if we\n> >> could spin some of it out into an Oslo library.\n> >>\n> >\n> > I feel like it boils down to something running periodically checking for\n> > scheduled tasks that are due to run but have not run yet. I wonder if we\n> > can actually look at Ironic for how they do this, because Ironic polls\n> > power state of machines constantly, and uses a hash ring to make sure\n> > only one conductor is polling any one machine at a time. If we broke\n> > stacks up into a hash ring like that for the purpose of singleton tasks\n> > like timeout checking, that might work out nicely.\n> \n> +1 for something like this, and +2 if we can get it from a library we \n> don\'t have to write ourselves (whether it be TaskFlow or something spun \n> out of Mistral or Ironic into Oslo).\n> \n\nRight, those things are fairly generic and would definitely fit nicely\nin a library.\n\nSo, the simplest possible solution, I think, is to lock resource id +\ngraph version. Since we are scared of Zookeeper, we\'ll need a periodic\njob in the engines that looks for stale locks, or we have to wait for\nanother stack operation to check for them.\n\n\n','<5464F09F.8090107@redhat.com>',NULL),('<1415922167-sup-953@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 15:56:01',-28800,'2014-11-13 23:56:01',NULL,'[openstack-dev] [all] config options not correctly deprecated','Excerpts from Ben Nemec\'s message of 2014-11-13 15:20:47 -0800:\n> On 11/10/2014 05:00 AM, Daniel P. Berrange wrote:\n> > On Mon, Nov 10, 2014 at 09:45:02AM +0000, Derek Higgins wrote:\n> >> Tl;dr oslo.config wasn\'t logging warnings about deprecated config\n> >> options, do we need to support them for another cycle?\n> > \n> > AFAIK, there has not been any change in olso.config behaviour\n> > in the Juno release, as compared to previous releases. The\n> > oslo.config behaviour is that the generated sample config file\n> > contain all the deprecation information.\n> > \n> > The idea that olso.config issue log warnings is a decent RFE\n> > to make the use of deprecated config settings more visible.\n> > This is an enhancement though, not a bug.\n> > \n> >> A set of patches to remove deprecated options in Nova was landed on\n> >> Thursday[1], these were marked as deprecated during the juno dev cycle\n> >> and got removed now that kilo has started.\n> > \n> > Yes, this is our standard practice - at the start of each release\n> > cycle, we delete anything that was marked as deprected in the\n> > previous release cycle. ie we give downstream users/apps 1 release\n> > cycle of grace to move to the new option names.\n> > \n> >> Most of the deprecated config options are listed as deprecated in the\n> >> documentation for nova.conf changes[2] linked to from the Nova upgrade\n> >> section in the Juno release notes[3] (the deprecated cinder config\n> >> options are not listed here along with the allowed_direct_url_schemes\n> >> glance option).\n> > \n> > The sample  nova.conf generated by olso lists all the deprecations.\n> > \n> > For example, for cinder options it shows what the old config option\n> > name was.\n> > \n> >   [cinder]\n> > \n> >   #\n> >   # Options defined in nova.volume.cinder\n> >   #\n> > \n> >   # Info to match when looking for cinder in the service\n> >   # catalog. Format is: separated values of the form:\n> >   # <service_type>:<service_name>:<endpoint_type> (string value)\n> >   # Deprecated group/name - [DEFAULT]/cinder_catalog_info\n> >   #catalog_info=volume:cinder:publicURL\n> > \n> > Also note the deprecated name will not appear as an option in the\n> > sample config file at all, other than in this deprecation comment.\n> > \n> > \n> >> My main worry is that there were no warnings about these options being\n> >> deprecated in nova\'s logs (as a result they were still being used in\n> >> tripleo), once I noticed tripleo\'s CI jobs were failing and discovered\n> >> the reason I submitted 4 reverts to put back the deprecated options in\n> >> nova[4] as I believe they should now be supported for another cycle\n> >> (along with a fix to oslo.config to log warnings about their use). The 4\n> >> patches have now been blocked as they go \"against our deprecation policy\".\n> >>\n> >> I believe the correct way to handle this is to support these options for\n> >> another cycle so that other operators don\'t get hit when upgrading to\n> >> kilo. While at that same time fix oslo.config to report the deprecated\n> >> options in kilo.\n> > \n> >> I have marked this mail with the [all] tag because there are other\n> >> projects using the same \"deprecated_name\" (or \"deprecated_group\")\n> >> parameter when adding config options, I think those projects also now\n> >> need to support their deprecated options for another cycle.\n> > \n> > AFAIK, there\'s nothing different about Juno vs previous release cycles,\n> > so I don\'t see any reason to do anything different this time around.\n> > No matter what we do there is always a possibility that downstream\n> > apps / users will not notice and/or ignore the deprecation. We should\n> > certainly look at how to make deprecation more obvious, but I don\'t\n> > think we should change our policy just because an app missed the fact\n> > that these were deprecated.\n> \n> So the difference to me is that this cycle we are aware that we\'re\n> creating a crappy experience for deployers.  In the past we didn\'t have\n> anything in the CI environment simulating a real deployment so these\n> sorts of issues went unnoticed.  IMHO telling deployers that they have\n> to troll the sample configs and try to figure out which deprecated opts\n> they\'re still using is not an acceptable answer.\n> \n\nI don\'t know if this is really fair, as all of the deprecated options do\nappear here:\n\nhttp://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html\n\nSo the real bug is that in TripleO we\'re not paying attention to the\nappropriate stream of deprecations. Logs on running systems is a mighty\nbig hammer when the documentation is being updated for us, and we\'re\njust not paying attention in the right place.\n\nBTW, where SHOULD continuous deployers pay attention for this stuff?\n\n> Now that we do know, I think we need to address the issue.  The first\n> step is to revert the deprecated removals - they\'re not hurting\n> anything, and if we wait another cycle we can fix oslo.config and then\n> remove them once deployers have had a reasonable chance to address the\n> deprecation.\n> \n\nIn this case, we can just fix the templates. Are we broken? Yes. Can we\nfix it? YES! I would definitely appreciate the reverts preceding that,\nso that we can land other things without having to pin Nova, but we can\ndeal if that isn\'t an option.\n\nIf we can ask that projects use \'check experimental\' whenever they remove\nanything deprecated and take the failures seriously, that will help with\nthis. We\'re trying our best to come up with good policies to keep up,\nbut sometimes we fall behind or, in this case, had no good policy for\nkeeping up.\n\n> This is one of the big reasons we want to have a deployment program\n> upstream.  It surfaces these sorts of shortcomings in a way that\n> probably wouldn\'t have happened before.  I think it would be a shame if\n> we ignore that because \"we\'ve always done it that way.\"\n> \n\nThanks Ben, that is indeed why we are still very much interested in\nhaving TripleO in the integrated gate some day. That said, if we can\'t\nkeep up with the stream of config changes needed, we\'ll just be a thorn\nin the side of each project that wants to move forward. So we need to\nget better at keeping up with the times.\n\n\n','<54653CCF.1080409@nemebean.com>',NULL),('<1415923173-sup-2670@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-13 16:08:55',-28800,'2014-11-14 00:08:55',NULL,'[openstack-dev] [Heat] Using Job Queues for timeout ops','Excerpts from Joshua Harlow\'s message of 2014-11-13 14:01:14 -0800:\n> On Nov 13, 2014, at 7:10 AM, Clint Byrum <clint at fewbar.com> wrote:\n> \n> > Excerpts from Joshua Harlow\'s message of 2014-11-13 00:45:07 -0800:\n> >> A question;\n> >> \n> >> How is using something like celery in heat vs taskflow in heat (or at least concept [1]) \'to many code change\'.\n> >> \n> >> Both seem like change of similar levels ;-)\n> >> \n> > \n> > I\'ve tried a few times to dive into refactoring some things to use\n> > TaskFlow at a shallow level, and have always gotten confused and\n> > frustrated.\n> > \n> > The amount of lines that are changed probably is the same. But the\n> > massive shift in thinking is not an easy one to make. It may be worth some\n> > thinking on providing a shorter bridge to TaskFlow adoption, because I\'m\n> > a huge fan of the idea and would _start_ something with it in a heartbeat,\n> > but refactoring things to use it feels really weird to me.\n> \n> I wonder how I can make that better...\n> \n> Where the concepts that new/different? Maybe I just have more of a functional programming background and the way taskflow gets you to create tasks that are later executed, order them ahead of time, and then *later* run them is still a foreign concept for folks that have not done things with non-procedural languages. What were the confusion points, how may I help address them? More docs maybe, more examples, something else?\n\nMy feeling is that it is hard to let go of the language constructs that\n_seem_ to solve the problems TaskFlow does, even though in fact they are\nthe problem because they\'re using the stack for control-flow where we\nwant that control-flow to yield to TaskFlow.\n\nI also kind of feel like the Twisted folks answered a similar question\nwith inline callbacks and made things \"easier\" but more complex in\ndoing so. If I had a good answer I would give it to you though. :)\n\n> \n> I would agree that the jobboard[0] concept is different than the other parts of taskflow, but it could be useful here:\n> \n> Basically at its core its a application of zookeeper where \'jobs\' are posted to a directory (using sequenced nodes in zookeeper, so that ordering is retained). Entities then acquire ephemeral locks on those \'jobs\' (these locks will be released if the owner process disconnects, or fails...) and then work on the contents of that job (where contents can be pretty much arbitrary). This creates a highly available job queue (queue-like due to the node sequencing[1]), and it sounds pretty similar to what zaqar could provide in theory (except the zookeeper one is proven, battle-hardened, works and exists...). But we should of course continue being scared of zookeeper, because u know, who wants to use a tool where it would fit, haha (this is a joke).\n> \n\nSo ordering is a distraction from the task at hand. But the locks that\nindicate liveness of the workers is very interesting to me. Since we\ndon\'t actually have requirements of ordering on the front-end of the task\n(we do on the completion of certain tasks, but we can use a DB for that),\nI wonder if we can just get the same effect with a durable queue that uses\na reliable messaging pattern where we don\'t ack until we\'re done. That\nwould achieve the goal of liveness.\n\n> [0] https://github.com/openstack/taskflow/blob/master/taskflow/jobs/jobboard.py#L25 \n> \n> [1] http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#Sequence+Nodes+--+Unique+Naming\n> \n> > \n> >> What was your metric for determining the code change either would have (out of curiosity)?\n> >> \n> >> Perhaps u should look at [2], although I\'m unclear on what the desired functionality is here.\n> >> \n> >> Do u want the single engine to transfer its work to another engine when it \'goes down\'? If so then the jobboard model + zookeper inherently does this.\n> >> \n> >> Or maybe u want something else? I\'m probably confused because u seem to be asking for resource timeouts + recover from engine failure (which seems like a liveness issue and not a resource timeout one), those 2 things seem separable.\n> >> \n> > \n> > I agree with you on this. It is definitely a liveness problem. The\n> > resource timeout isn\'t something I\'ve seen discussed before. We do have\n> > a stack timeout, and we need to keep on honoring that, but we can do\n> > that with a job that sleeps for the stack timeout if we have a liveness\n> > guarantee that will resurrect the job (with the sleep shortened by the\n> > time since stack-update-time) somewhere else if the original engine\n> > can\'t complete the job.\n> > \n> >> [1] http://docs.openstack.org/developer/taskflow/jobs.html\n> >> \n> >> [2] http://docs.openstack.org/developer/taskflow/examples.html#jobboard-producer-consumer-simple\n> >> \n> >> On Nov 13, 2014, at 12:29 AM, Murugan, Visnusaran <visnusaran.murugan at hp.com> wrote:\n> >> \n> >>> Hi all,\n> >>> \n> >>> Convergence-POC distributes stack operations by sending resource actions over RPC for any heat-engine to execute. Entire stack lifecycle will be controlled by worker/observer notifications. This distributed model has its own advantages and disadvantages.\n> >>> \n> >>> Any stack operation has a timeout and a single engine will be responsible for it. If that engine goes down, timeout is lost along with it. So a traditional way is for other engines to recreate timeout from scratch. Also a missed resource action notification will be detected only when stack operation timeout happens.\n> >>> \n> >>> To overcome this, we will need the following capability:\n> >>> 1.       Resource timeout (can be used for retry)\n> >>> 2.       Recover from engine failure (loss of stack timeout, resource action notification)\n> >>> \n> >>> \n> >>> Suggestion:\n> >>> 1.       Use task queue like celery to host timeouts for both stack and resource.\n> >>> 2.       Poll database for engine failures and restart timers/ retrigger resource retry (IMHO: This would be a traditional and weighs heavy)\n> >>> 3.       Migrate heat to use TaskFlow. (Too many code change)\n> >>> \n> >>> I am not suggesting we use Task Flow. Using celery will have very minimum code change. (decorate appropriate functions)\n> >>> \n> >>> \n> >>> Your thoughts.\n> >>> \n> >>> -Vishnu\n> >>> IRC: ckmvishnu\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<BLU436-SMTP32B041305427FF9B962632D88F0@phx.gbl>',NULL),('<1415967890.12195.YahooMailNeo@web160304.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-14 04:24:50',-28800,'2014-11-14 12:24:50',NULL,'[OpenStack-docs] Diagram color scheme','In [2], I prefer the Compute node, and in [3], I prefer the Network node color scheme. The font color for the node labels could be lighter so it is easier to read.\n\nThis is a good step towards having some consistency with diagrams in the upstream docs. When this is finalized, can we add this information to the documentation conventions wiki, and include other conventions such as file formats, graphics resolution and size, and recommended tools? It would also be helpful to have some guidelines about creating different diagrams, such as network architecture diagrams and process flow diagrams.\n\n\nRegards,\n\nDarren \n\n\n\n\n\nOn Friday, 14 November 2014, 12:50, Nick Chase <nchase at mirantis.com> wrote:\n \n\n\nOn the color, I definitely prefer the light version; much easier to read.  Any of the colors actually work, I think.\n\nOn the monotone, I actually LIKE the object storage nodes the best,\n    though that\'s not saying much; I don\'t like the monotone much at\n    all, actually, particularly compared with the color.  At small font\n    sizes, I don\'t tink there\'s enough contrast on the baqckground\n    colors.  The content colors are good, though.  That\'s why the Object\n    Storage nodes work, I think.  (Still prefer the color/light version,\n    though.)\n\nNice job finding this.\n\n----  Nick\n\n\n\nOn 11/13/2014 8:28 PM, Matt Kassawara wrote:\n\nNeedless to say, our existing diagram color schemes vary by document and sometimes look rather hideous. For example, I used the red-green-blue theme in the installation guide to improve contrast among the networks, but it lacks the civility you would find in other professional documentation. Similar to networking, colors are hard. For example, themes that implement many shades of one or two colors look professional but limit the ability to contrast important items. On the other hand, themes that implement many diverse colors offer many ways to contrast important items, but look harsh. I haven\'t found a theme that provides a decent balance until Robb Romans (a coworker at Rackspace) pointed out the Solarized theme [1] today. Although somewhat optimized for text, this theme provides several decent dark/light combinations for diagrams requiring less contrast and a series of diverse yet soft colors for diagrams requiring more contrast. After messing around a\n bit, I came up with a few potential color variants using this theme. Please review the dark/light example for simple diagrams [2] and the diverse color example for complex/contrasty diagrams [3] and provide comments. For the first diagram, indicate which of the controller node, network node, compute node, and block storage node objects look the best (ignore the object storage nodes). For the second diagram, indicate which of the nodes (dark/light) and network colors look best. You can also reject this theme completely. However, if you do, please provide one or more suitable alternatives. I would like to upload a series of revitalized diagrams to the installation guide as soon as possible. \n>\n>\n>Matt\n>\n>\n>[1] http://ethanschoonover.com/solarized\n>[2] http://23.253.231.218/rpc-diagrams/os-examplearchneutron-hw.png\n>[3] http://23.253.231.218/rpc-diagrams/os-examplearchneutron-networks.png\n>\n>\n>_______________________________________________\nOpenStack-docs mailing list OpenStack-docs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs \n\n\n_______________________________________________\nOpenStack-docs mailing list\nOpenStack-docs at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20141114/e89f7516/attachment.html>\n\n','<1625584237.482240.1415932894090.JavaMail.yahoo@jws106105.mail.bf1.yahoo.com>',NULL),('<1415973932-sup-4897@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-14 06:08:42',-28800,'2014-11-14 14:08:42',NULL,'[openstack-dev] [TripleO] [Ironic] [Cinder] \"Baremetal volumes\"\n	-- how to model direct attached storage','Excerpts from Chris Jones\'s message of 2014-11-14 00:42:48 -0800:\n> Hi\n> \n> My thoughts:\n> \n> Shoe-horning the ephemeral partition into Cinder seems like a lot of pain for almost no gain[1]. The only gain I can think of would be that we could bring a node down, boot it into a special ramdisk that exposes the volume to the network, so cindery operations (e.g. migration) could be performed, but I\'m not even sure if anyone is asking for that?\n> \n> Forcing Cinder to understand and track something it can never normally do anything with, seems like we\'re just trying to squeeze ourselves into an ever-shrinking VM costume!\n> \n> Having said that, \"preserve ephemeral\" is a terrible oxymoron, so if we can do something about it, we probably should.\n> \n> How about instead, we teach Nova/Ironic about a concept of \"no ephemeral\"? They make a partition on the first disk for the first image they deploy, and then they never touch the other part(s) of the disk(s), until the instance is destroyed. This creates one additional burden for operators, which is to create and format a partition the first time they boot, but since this is a very small number of commands, and something we could trivially bake into our (root?) elements, I\'m not sure it\'s a huge problem.\n> \n> This gets rid of the cognitive dissonance of preserving something that is described as ephemeral, and (IMO) makes it extremely clear that OpenStack isn\'t going to touch anything but the first partition of the first disk. If this were baked into the flavour rather than something we tack onto a nova rebuild command, it offers greater safety for operators, against the risk of accidentallying a vital state partition with a misconstructed rebuild command.\n> \n\n+1\n\nA predictable and simple rule seems like it would go a long way to\ndecoupling state preservation from rebuild, which I like very much.\n\nThere is, of course, the issue of decom then, but that has never been a\nconcern for TripleO, and for OnMetal, they think we\'re a bit daft trying\nto preserve state while delivering new images anyway. :)\n\n\n','<6E90CCD4-62D0-48EE-9A9C-C11E8E78FD9A@tenshu.net>',NULL),('<1416003406-sup-509@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-14 14:18:25',-28800,'2014-11-14 22:18:25',NULL,'[openstack-dev] LTFS integration with OpenStack Swift for\n	scenario like - Data Archival as a Service .','Excerpts from Samuel Merritt\'s message of 2014-11-14 10:06:53 -0800:\n> On 11/13/14, 10:19 PM, Sachin Goswami wrote:\n> > In OpenStack Swift - xfs file system is integrated which provides a\n> > maximum file system size of 8 exbibytes minus one byte (263-1 bytes).\n> \n> Not exactly. The Swift storage nodes keep their data on POSIX \n> filesystems with support for extended attributes. While XFS filesystems \n> are typically used, XFS is not required.\n> \n> > We are studying use of LTFS integration with OpenStack Swift for\n> > scenario like - *Data Archival as a Service* .\n> >\n> > Was integration of LTFS with Swift considered before? If so, can you\n> >  please share your study output? Will integration of LTFS with Swift\n> > fit into existing Swift architecture ?\n> \n> Assuming it\'s POSIX enough and supports extended attributes, a tape \n> filesystem on a spinning disk might technically work, but I don\'t see it \n> performing well at all.\n> \n> If you\'re talking about using actual tapes for data storage, I can\'t \n> imagine that working out for you. Most clients aren\'t prepared to wait \n> multiple minutes for HTTP responses while a tape laboriously spins back \n> and forth, so they\'ll just time out.\n> \n\nAgreed. You\'d need to have a separate API for freezing and thawing data\nI think, similar to the way glacier works. However, my understanding of\nglacier is that it is simply a massive bank of cheap disks which are\nlargely kept powered off until either a ton of requests for data on a\nsingle disk arrive, or a certain amount of time has passed. The benefit\nof this is that there is no intermediary storage required. The disks\nare either online, and you can read your data, or offline, and you have\nto wait.\n\n\n','<546644BD.7040801@swiftstack.com>',NULL),('<1416246026.3223.11.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 11:40:26',-21600,'2014-11-17 17:40:26',NULL,'[openstack-dev] Process for program without lead','On Mon, 2014-11-17 at 17:25 +0000, Hayes, Graham wrote:\n> Quite often people will come forward in a vacuum - people who thought\n> they were not right for the job, or felt that someone else would suit\n> the role better can come forward in a by-election. (I only have\n> anecdotal evidence for this, but it is first hand, based on other\n> voluntary, self organising groups I have been part of, and run elections\n> for over the years).\n> \n> I would suggest when nominations close with no candidates, they re-open\n> immediately for one week, at with point, if there is no candidates I\n> goes to the TC.\n\nWhile I think the point is valid, an alternate process would be for the\nelection coordinator(s) to point out the lack of candidates and issue a\nreminder for the procedure a certain amount of time prior to the end of\nthe nomination period.  Say, if no candidates have been put forward with\n3 days left in the nomination period, then the election coordinator\nwould send out the appropriate reminder email.  I think this would have\nthe same effect as the one week re-open period without delaying the\nelection process.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<325F898546FBBF4487D24D6D606A277E031E96D3@G4W3202.americas.hpqcorp.net>',NULL),('<1416247776-sup-9311@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-11-17 10:11:13',-28800,'2014-11-17 18:11:13',NULL,'[OpenStack-Infra] Chicken and Egg patches','Excerpts from Spencer Krum\'s message of 2014-11-17 02:36:20 -0800:\n> Hi,\n> \n> I help run a clone of infra and our developers have a desire to land\n> \'chicken and egg\' patches. What I mean by this is one patchset on one\n> project and another patchset on another project such that tests cannot pass\n> on either individually, but together, everything works. Right now we can\'t\n> land these kind of changes.\n> \n> Is this performed upstream? How can I get this kind of behavior out of my\n> openstackci infrastructure?\n\nAs Monty said, this is not done.\n\nOne thing: this is a sign they are breaking whatever interface exists\nbetween the two projects.\n\n\n','<CADt6FWNhswg-kAdkf+qavaZws6y1RDWOWmiFTqJyz1pAKVA3JQ@mail.gmail.com>',NULL),('<1416254598.3223.16.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 14:03:18',-21600,'2014-11-17 20:03:18',NULL,'[openstack-dev] [api] Requesting opinion/guideline on IDs vs\n hrefs','On Mon, 2014-11-17 at 19:47 +0000, Shaunak Kashyap wrote:\n> Poppy APIs refer to a flavor in their request and/or response\n> representations. Some representations do this by using the flavor ID\n> (e.g. 12345) while others use the flavor resource URI (e.g.\n> {base}/flavors/12345).\n> \n> In this context, I created a bug[2] to settle on one way of referring\n> to a flavor across all API representations in Poppy. So the question\n> to the API working group is this:\n> \n> How should flavors be referred to in Poppy API representations? Some\n> options to consider:\n> \n> a) Using a ?flavor_id? (or similar) property whose value is the flavor\n> ID (e.g. 12345),\n> b) Using a ?flavor_ref? (or similar) property whose value is the\n> flavor resource URI (e.g. {base}/flavors/12345),\n> c) Using a ?links? property whose value is an array of links, one of\n> which has an object like { ?rel?: ?flavor?, ?href?:\n> ?{base}/flavors/12345? },\n> d) Similar to c) but using HAL[3] instead,\n> e) A combination of a) and c),\n> f) A combination of a) and d),\n> g) Something else?\n\nI can\'t think of any API in OpenStack that uses a URI for referencing\nanything.  We may have *links* in the payloads, but those are provided\nfor convenience; anytime nova refers to a flavor, it returns the flavor\nUUID.\n\nI would, by the way, suggest using UUIDs rather than plain IDs, for\nconsistency with the rest of the APIs?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<565AAA13-EC7A-4B0F-95C7-8979CD951EC6@rackspace.com>',NULL),('<1416269934.3223.27.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-17 18:18:54',-21600,'2014-11-18 00:18:54',NULL,'[openstack-dev] Quota management and enforcement across projects','On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote:\n> I?ve spent a bit of time thinking about the resource ownership issue.\n> The challenge there is we don?t currently have any libraries that\n> define tables in the schema of an application. I think that?s a good\n> pattern to maintain, since it avoids introducing a lot of tricky\n> issues like how to manage migrations for the library, how to ensure\n> they are run by the application, etc. The fact that this common quota\n> thing needs to store some data in a schema that it controls says to me\n> that it is really an app and not a library. Making the quota manager\n> an app solves the API definition issue, too, since we can describe a\n> generic way to configure quotas and other applications can then use\n> that API to define specific rules using the quota manager?s API.\n> \n> I don?t know if we need a new application or if it would make sense\n> to, as with policy, add quota management features to keystone. A\n> single well-defined app has some appeal, but there?s also a certain\n> amount of extra ramp-up time needed to go that route that we wouldn?t\n> need if we added the features directly to keystone.\n\nI\'ll also point out that it was largely because of the storage needs\nthat I chose to propose Boson[1] as a separate app, rather than as a\nlibrary.  Further, the dimensions over which quota-covered resources\nneeded to be tracked seemed to me to be complicated enough that it would\nbe better to define a new app and make it support that one domain well,\nwhich is why I didn\'t propose it as something to add to Keystone.\nConsider: nova has quotas that are applied by user, other quotas that\nare applied by tenant, and even some quotas on what could be considered\nsub-resources?a limit on the number of security group rules per security\ngroup, for instance.\n\nMy current feeling is that, if we can figure out a way to make the quota\nproblem into an acceptable library, that will work; it would probably\nhave to maintain its own database separate from the client app and have\nfeatures for automatically managing the schema, since we couldn\'t\nnecessarily rely on the client app to invoke the proper juju there.  If,\non the other hand, that ends up failing, then the best route is probably\nto begin by developing a separate app, like Boson, as a PoC; then, after\nwe have some idea of just how difficult it is to actually solve the\nproblem, we can evaluate whether it makes sense to actually fold it into\na service like Keystone, or whether it should stand on its own.\n\n(Personally, I think Boson should be created and should stand on its\nown, but I also envision using it for purposes outside of OpenStack?)\n\nJust my $.02?\n\n[1] https://wiki.openstack.org/wiki/Boson\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<FA784836-0133-4B28-8E73-EF21DA36A270@doughellmann.com>',NULL),('<1416334708-sup-7940@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-18 10:58:23',-28800,'2014-11-18 18:58:23',NULL,'[openstack-dev] [all] Scale out bug-triage by making it easier\n	for people to contribute','Excerpts from Flavio Percoco\'s message of 2014-11-17 08:46:19 -0800:\n> Greetings,\n> \n> Regardless of how big/small bugs backlog is for each project, I\n> believe this is a common, annoying and difficult problem. At the oslo\n> meeting today, we\'re talking about how to address our bug triage\n> process and I proposed something that I\'ve seen done in other\n> communities (rust-language [0]) that I consider useful and a good\n> option for OpenStack too.\n> \n> The process consist in a bot that sends an email to every *volunteer*\n> with 10 bugs to review/triage for the week. Each volunteer follows the\n> triage standards, applies tags and provides information on whether the\n> bug is still valid or not. The volunteer doesn\'t have to fix the bug,\n> just triage it.\n> \n> In openstack, we could have a job that does this and then have people\n> from each team volunteer to help with triage. The benefits I see are:\n> \n> * Interested folks don\'t have to go through the list and filter the\n> bugs they want to triage. The bot should be smart enough to pick the\n> oldest, most critical, etc.\n> \n> * It\'s a totally opt-in process and volunteers can obviously ignore\n> emails if they don\'t have time that week.\n> \n> * It helps scaling out the triage process without poking people around\n> and without having to do a \"call for volunteers\" every meeting/cycle/etc\n> \n> The above doesn\'t solve the problme completely but just like reviews,\n> it\'d be an optional, completely opt-in process that people can sign up\n> for.\n> \n\nMy experience in Ubuntu, where we encouraged non-developers to triage\nbugs, was that non-developers often ask the wrong questions and\nsometimes even harm the process by putting something in the wrong\npriority or state because of a lack of deep understanding.\n\nTriage in a hospital is done by experienced nurses and doctors working\ntogether, not \"triagers\". This is because it may not always be obvious\nto somebody just how important a problem is. We have the same set of\nproblems. The most important thing is that developers see it as an\nimportant task and take part. New volunteers should be getting involved\nat every level, not just bug triage.\n\nI think the best approach to this, like reviews, is to have a place\nwhere users can go to drive the triage workload to 0. For instance, the\nubuntu server team had this report for triage:\n\nhttp://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html\n\nSadly, it looks like they\'re overwhelmed or have abandoned the effort\n(I hope this doesn\'t say something about Ubuntu server itself..), but\nthe basic process was to move bugs off these lists. I\'m sure if we ask\nnice the author of that code will share it with us and we could adapt\nit for OpenStack projects.\n\n\n','<20141117164619.GB9319@redhat.com>',NULL),('<1416343498.427576.192593665.1BE18657@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-11-18 12:44:58',-28800,'2014-11-18 20:44:58',NULL,'[OpenStack-Infra] Naming for project-specific external test\n	accounts','On Mon, Nov 17, 2014, at 04:21 PM, Jeremy Stanley wrote:\n> When we put together our third-party CI account naming scheme a few\n> months ago, discussion was mostly focused on how to avoid confusion\n> on official projects where we have upwards of 50 systems providing\n> feedback on a proposed change. Requirements like \"include the name\n> of your company and subsystem being tested\" or \"the account name\n> can\'t include the name of the project\" make sense there, but we have\n> another somewhat unrelated use case for these accounts which also\n> needs some consideration.\n> \n> Consider a project whose community collaboratively maintains a\n> single external test system to provide feedback about things that we\n> won\'t or can\'t easily test in our infrastructure... I\'ve seen a lot\n> of confusion around how those accounts are allowed to be named.\n> Consider the following existing accounts as examples:\n> \n>     Compass CI\n>     Docker CI\n>     Fuel CI\n>     MagnetoDB CI\n>     Puppet CI\n>     Sahara Hadoop Cluster CI\n> \n> I\'ve proposed https://review.openstack.org/135050 in an attempt to\n> reach some consensus that for this particular use case, having an\n> account like \"YourProject CI\" for your community to use in reporting\n> test results on your project is acceptable. I\'m bringing this up now\n> because we have somewhere around half a dozen outstanding account\n> requests (some more than a month old) matching this particular\n> pattern and I\'d like to be able to just go ahead and take care of\n> them, but I don\'t want to go upsetting anyone over the possibility\n> that we\'ve violated our hard-and-fast rules for third-party CI\n> account naming.\n> -- \n> Jeremy Stanley\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n+2 (and I have voted that way on 135050). Stackforge exists to encourage\nawesomeness and when the frameworks it is built on impede that we should\nconsider updating the framework. There is clearly a need for third party\ntesting for Stackforge projects and they may not have a company backing\nor subsystem being tested. They just need to run tests outside of\nupstream for reasons and we should enable that.\n\nClark\n\n\n','<20141118002154.GC2497@yuggoth.org>',NULL),('<1416345640-sup-6210@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-18 21:25:43',0,'2014-11-18 21:25:43',NULL,'[openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning','Excerpts from Gregory Haynes\'s message of 2014-10-09 20:32:26 +0000:\n> Hello TripleO-ers,\n> \n> Last time around there was a lot of feedback that we should plan our\n> mid-cycle metup a lot sooner, so lets do that! I\'ve created a (mostly\n> bare) etherpad here:\n> \n> https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n> \n> Note that there are currently no possible venues listed. If you are able\n> to provide a possible venue (Thank you!) please reply and/or add it to\n> the etherpad.\n> \n> I have also listed a few possible Mon-Fri meetup dates. Do not take this\n> as any indication that Mon-Fri is an ideal meetup length or time of\n> week, and feel free to add feedback / combinations of your own.\n> Personally, I felt pretty burned out by Friday last time so maybe\n> Mon-Wed is a better size?\n\nA bit of a status update: We are in the works of getting approval for a\nSeattle location to host our mid-cycle sprint. If you havent already\n(which is most everyone at this point) please add your preferences to\nthe list of dates at the bottom of the etherpad.\n\nMore updates to come!\n\nCheers,\nGreg\n\n\n','<1412886281-sup-2284@greghaynes0.opus.gah>',NULL),('<1416346258.6053247.1397589382354.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 15:16:22',-14400,'2014-04-15 19:16:22',NULL,'[openstack-dev] [Nova] nova-specs','Just wanted to confirm what Sean said -- as someone who just joined the OpenStack community last\nyear, going to implement a vaguely worded blueprint and then having the code review be derailed\nwith people saying \"well, you probably should be using this completely different design\" is fairly\nfrustrating.  While you come to anticipate certain changes, IMHO it\'s definitely much better to decide\non the design *before* you start coding, that way code reviews can focus on the code, and you don\'t have\nto completely rewrite patches as much.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: openstack-dev at lists.openstack.org\nSent: Tuesday, April 15, 2014 1:45:16 PM\nSubject: Re: [openstack-dev] [Nova] nova-specs\n\nOn 04/15/2014 11:42 AM, Russell Bryant wrote:\n> On 04/15/2014 11:01 AM, Brian Elliott wrote:\n>>> * specs review. The new blueprint process is a work of genius, and I\n>>> think its already working better than what we\'ve had in previous\n>>> releases. However, there are a lot of blueprints there in review, and\n>>> we need to focus on making sure these get looked at sooner rather than\n>>> later. I\'d especially like to encourage operators to take a look at\n>>> blueprints relevant to their interests. Phil Day from HP has been\n>>> doing a really good job at this, and I\'d like to see more of it.\n>>\n>> I have mixed feelings about the nova-specs repo.  I dig the open collaboration of the blueprints process, but I also think there is a danger of getting too process-oriented here.  Are these design documents expected to call out every detail of a feature?  Ideally, I?d like to see only very high level documentation in the specs repo.  Basically, the spec could include just enough detail for people to agree that they think a feature is worth inclusion.  More detailed discussion could remain on the code reviews since they are the actual end work product.\n> \n> There is a balance to be found here.  The benefit of doing more review\n> earlier is to change direction as necessary when it\'s *much* easier to\n> do so.  It\'s a lot more time consuming to do re-work after code has been\n> written, than re-work in a spec.\n> \n> Yes, it\'s more up front work, but I think it will speed up the process\n> overall.  It means we\'re much more in agreement and on the same page\n> before code even shows up.  That\'s huge.\n> \n> One of the big problems we\'ve had in code review is the amount of churn\n> and re-work required.  That is killing our throughput in code review.\n> If we can do more up front work that will reduce re-work later, it\'s\n> going to be a *huge* help to our primary project bottleneck: the code\n> review queue.\n\nI think the previous process is a huge demotivator to contributors, when\nthey file a blueprint with minimal info, it gets approved, they spend\nmonths working on it, and only at the end of the process does the idea\nget dug into enough for people to realize that it\'s not what anyone wants.\n\nAt that point people are so invested in the time they spent on this\nfeature that turning that conversation productive is really hard.\n\nCatching more of these up front and being more explicit about what Nova\nwants in a cycle is goodness.\n\n	-Sean\n\n-- \nSean Dague\nSamsung Research America\nsean at dague.net / sean.dague at samsung.com\nhttp://dague.net\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<534D702C.40603@dague.net>',NULL),('<1416431412-sup-6582@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 13:14:08',-28800,'2014-11-19 21:14:08',NULL,'[openstack-dev] [Neutron] DB: transaction isolation and related\n	questions','Excerpts from Mike Bayer\'s message of 2014-11-19 10:05:35 -0800:\n> \n> > On Nov 18, 2014, at 1:38 PM, Eugene Nikanorov <enikanorov at mirantis.com> wrote:\n> > \n> > Hi neutron folks,\n> > \n> > There is an ongoing effort to refactor some neutron DB logic to be compatible with galera/mysql which doesn\'t support locking (with_lockmode(\'update\')).\n> > \n> > Some code paths that used locking in the past were rewritten to retry the operation if they detect that an object was modified concurrently.\n> > The problem here is that all DB operations (CRUD) are performed in the scope of some transaction that makes complex operations to be executed in atomic manner.\n> > For mysql the default transaction isolation level is \'REPEATABLE READ\' which means that once the code issue a query within a transaction, this query will return the same result while in this transaction (e.g. the snapshot is taken by the DB during the first query and then reused for the same query).\n> > In other words, the retry logic like the following will not work:\n> > \n> > def allocate_obj():\n> >     with session.begin(subtrans=True):\n> >          for i in xrange(n_retries):\n> >               obj = session.query(Model).filter_by(filters)\n> >               count = session.query(Model).filter_by(id=obj.id <http://obj.id/>).update({\'allocated\': True})\n> >               if count:\n> >                    return obj\n> > \n> > since usually methods like allocate_obj() is called from within another transaction, we can\'t simply put transaction under \'for\' loop to fix the issue.\n> \n> has this been confirmed?  the point of systems like repeatable read is not just that you read the ?old? data, it?s also to ensure that updates to that data either proceed or fail explicitly; locking is also used to prevent concurrent access that can?t be reconciled.  A lower isolation removes these advantages.  \n> \n\nYes this is confirmed and fails reliably on Galera based systems.\n\n> I ran a simple test in two MySQL sessions as follows:\n> \n> session 1:\n> \n> mysql> create table some_table(data integer) engine=innodb;\n> Query OK, 0 rows affected (0.01 sec)\n> \n> mysql> insert into some_table(data) values (1);\n> Query OK, 1 row affected (0.00 sec)\n> \n> mysql> begin;\n> Query OK, 0 rows affected (0.00 sec)\n> \n> mysql> select data from some_table;\n> +------+\n> | data |\n> +------+\n> |    1 |\n> +------+\n> 1 row in set (0.00 sec)\n> \n> \n> session 2:\n> \n> mysql> begin;\n> Query OK, 0 rows affected (0.00 sec)\n> \n> mysql> update some_table set data=2 where data=1;\n> Query OK, 1 row affected (0.00 sec)\n> Rows matched: 1  Changed: 1  Warnings: 0\n> \n> then back in session 1, I ran:\n> \n> mysql> update some_table set data=3 where data=1;\n> \n> this query blocked;  that?s because session 2 has placed a write lock on the table.  this is the effect of repeatable read isolation.\n\nWith Galera this session might happen on another node. There is no\ndistributed lock, so this would not block...\n\n> \n> while it blocked, I went to session 2 and committed the in-progress transaction:\n> \n> mysql> commit;\n> Query OK, 0 rows affected (0.00 sec)\n> \n> then session 1 unblocked, and it reported, correctly, that zero rows were affected:\n> \n> Query OK, 0 rows affected (7.29 sec)\n> Rows matched: 0  Changed: 0  Warnings: 0\n> \n> the update had not taken place, as was stated by ?rows matched\":\n> \n> mysql> select * from some_table;\n> +------+\n> | data |\n> +------+\n> |    1 |\n> +------+\n> 1 row in set (0.00 sec)\n> \n> the code in question would do a retry at this point; it is checking the number of rows matched, and that number is accurate.\n> \n> if our code did *not* block at the point of our UPDATE, then it would have proceeded, and the other transaction would have overwritten what we just did, when it committed.   I don?t know that read committed is necessarily any better here.\n> \n> now perhaps, with Galera, none of this works correctly.  That would be a different issue in which case sure, we should use whatever isolation is recommended for Galera.  But I?d want to potentially peg it to the fact that Galera is in use, or not.\n> \n> would love also to hear from Jay Pipes on this since he literally wrote the book on MySQL ! :)\n\nWhat you missed is that with Galera the commit that happened last would\nbe rolled back. This is a reality in many scenarios on SQL databases and\nshould be handled _regardless_ of Galera. It is a valid way to handle\ndeadlocks on single node DBs as well (pgsql will do this sometimes).\n\nOne simply cannot rely on multi-statement transactions to always succeed.\n\n\n','<8EEAB00D-5088-46E8-802F-B2F052B567DE@redhat.com>',NULL),('<1416432311-sup-1472@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-19 13:28:16',-28800,'2014-11-19 21:28:16',NULL,'[Openstack-operators] Operations project: Packaging','Excerpts from Michael Chapman\'s message of 2014-11-17 22:16:28 -0800:\n> Hi all,\n> \n> Packaging was one of the biggest points of interest in the Friday Paris\n> meeting, and I\'d like to use this thread to have a centralised discussion\n> and/or argument regarding whether there is a packaging system that is\n> flexible enough that we can adopt it as a community and reduce the\n> fragmentation. This conversation began in Paris, but will likely continue\n> for some time.\n> \n> The Friday session indicates that as operators we have common requirements:\n> \n> A system that takes the sources from upstream projects and produces\n> artifacts (packages or images).\n> \n> There are numerous projects that have attempted to solve this problem. Some\n> are on stackforge, some live outside. If you are an author or a user of one\n> of these systems, please give your opinion.\n> \n> Once it becomes clear who is interested in this topic, we can create a\n> working group that will move towards standardising on a single system that\n> meets the needs of the community. Once the key individuals for this project\n> are clear, we can schedule an appropriate meeting time on irc for further\n> discussion that will probably be needed.\n\nThe responses to this thread have been pretty interesting.\n\nCount me in as interested in pulling packages into the image building\nthat we do for TripleO. A number of operators have expressed confusion\nand concern about updating an app with whole image updates, so it would\nbe quite useful if we could instead just help people build and distribute\ntheir own packages on top of the image based deploys that we already do.\n\n\n','<CABf87X=L5qEpj0nXyXoMM1qVAdZRq7Rwh6q87aO89F+RWeb_gg@mail.gmail.com>',NULL),('<1416436753.3986.3.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 22:38:31',0,'2014-11-19 22:38:31',NULL,'[openstack-dev]  [neutron][lbaas] Abandon Old LBaaS V2 Review','Evgeny,\nSince change sets got moved to the feature branch, this review has\nremained on master.  It needs to be abandoned:\n\nhttps://review.openstack.org/#/c/109849/\n\nThanks,\nBrandon\n\nOn Mon, 2014-11-17 at 12:31 -0800, Stephen Balukoff wrote:\n> Awesome!\n> \n> On Mon, Nov 10, 2014 at 9:10 AM, Susanne Balle <sleipnir012 at gmail.com>\n> wrote:\n>         Works for me. Susanne\n>         \n>         On Mon, Nov 10, 2014 at 10:57 AM, Brandon Logan\n>         <brandon.logan at rackspace.com> wrote:\n>                 https://wiki.openstack.org/wiki/Meetings#LBaaS_meeting\n>                 \n>                 That is updated for lbaas and advanced services with\n>                 the new times.\n>                 \n>                 Thanks,\n>                 Brandon\n>                 \n>                 On Mon, 2014-11-10 at 11:07 +0000, Doug Wiegley wrote:\n>                 > #openstack-meeting-4\n>                 >\n>                 >\n>                 > > On Nov 10, 2014, at 10:33 AM, Evgeny Fedoruk\n>                 <EvgenyF at Radware.com> wrote:\n>                 > >\n>                 > > Thanks,\n>                 > > Evg\n>                 > >\n>                 > > -----Original Message-----\n>                 > > From: Doug Wiegley [mailto:dougw at a10networks.com]\n>                 > > Sent: Friday, November 07, 2014 9:04 PM\n>                 > > To: OpenStack Development Mailing List\n>                 > > Subject: [openstack-dev] [neutron][lbaas] meeting\n>                 day/time change\n>                 > >\n>                 > > Hi all,\n>                 > >\n>                 > > Neutron LBaaS meetings are now going to be\n>                 Tuesdays at 16:00 UTC.\n>                 > >\n>                 > > Safe travels.\n>                 > >\n>                 > > Thanks,\n>                 > > Doug\n>                 > >\n>                 > >\n>                 > > _______________________________________________\n>                 > > OpenStack-dev mailing list\n>                 > > OpenStack-dev at lists.openstack.org\n>                 > >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 > >\n>                 > > _______________________________________________\n>                 > > OpenStack-dev mailing list\n>                 > > OpenStack-dev at lists.openstack.org\n>                 > >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 >\n>                 > _______________________________________________\n>                 > OpenStack-dev mailing list\n>                 > OpenStack-dev at lists.openstack.org\n>                 >\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>                 _______________________________________________\n>                 OpenStack-dev mailing list\n>                 OpenStack-dev at lists.openstack.org\n>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>                 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZrHd93Pu1iB3-Nuvb4cvKjwEWA50NWtJMZxv++W9viRvg@mail.gmail.com>',NULL),('<1416440371.3212.1.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 17:39:31',-21600,'2014-11-19 23:39:31',NULL,'[openstack-dev] Quota management and enforcement across projects','On Thu, 2014-11-20 at 10:16 +1100, Blair Bethwaite wrote:\n> For actions initiated directly through core OpenStack service APIs\n> (Nova, Cinder, Neutron, etc - anything using Keystone policy),\n> shouldn\'t quota-enforcement be handled by Keystone? To me this is just\n> a subset of authz, and OpenStack already has a well established\n> service for such decisions.\n\nIf you look a little earlier in the thread, you will find a post from me\nwhere I point out just how complicated quota management actually is.  I\nsuggest that it should be developed as a proof-of-concept as a separate\nservice; from there, we can see whether it makes sense to roll it into\nKeystone or maintain it as a separate thing.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CA+z5DswCkbhFHrYa30moFFV4-kYsWOsWY5ACB814Y+_RVTVeGw@mail.gmail.com>',NULL),('<1416479397.15832.56.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-11-20 10:29:57',0,'2014-11-20 10:29:57',NULL,'[openstack-tc] Fwd: Revised Bylaws','On Wed, 2014-11-19 at 16:00 -0800, Joe Gordon wrote:\n\n> \n> * When removing appendix 8, you are removing the explicit guarantee\n> that the OpenStack Word Mark is shared with the community. While I\n> fully support making it easier to adjust the commercial trademark\n> usage, I am not very keen on making it easier to change the guarantee\n> that the non-commercial trademark usage.\n> \n> \n> \"We share the OpenStack Word Mark with the community for the purposes of open source \n> discussion, development and support of the OpenStack project and technology. We understand \n> that such use is mostly for non-commercial purposes and therefore we will allow the use of the \n> OpenStack Word Mark, without a license, when used in a ?referential? phrase only to describe \n> the OpenStack Project or the OpenStack code base, provided you comply with the following \n> requirements:\"\n\nAgree with the concern, and I said similarly previously:\n\nhttp://lists.openstack.org/pipermail/defcore-committee/2014-September/000384.html\n\n  As for removing the trademark policy from the bylaws, I see the policy\n  as a high-level set of principles about how the trademarks should be\n  managed and I\'m fine with those principles requiring bylaws changes.\n  However, specific implementation details of those principles (like the\n  exact set of trademark programs) should determined by the board.\n\n  In other words, if there are parts of the trademark policy which are\n  \"implementation details\" which we feel should be determined by the\n  board, why not just remove those details from the policy?\n\nIt\'s true the current policy goes into a little too much of the\nimplementation details - i.e. the details of the existing commercial\ntrademark programs - but allows the Foundation to create other programs:\n\n  http://lists.openstack.org/pipermail/foundation/2014-June/001701.html\n\n    It lays out several of the licensing programs that existed at the\n    time of drafting but also states \"Other licensing programs may be\n    available for a specific use.\n\nand this is why an \"OpenStack Powered Compute\"[1] program could be\nintroduced with no bylaws-changing trademark policy change required.\n\nSo it appears to me that removing the trademark policy from the bylaws\nisn\'t required for us to make progress on anything, but it does - as you\nsay - remove that assurance that the trademark will always be available\nfor non-commercial use.\n\nMark.\n\n[1] - http://lists.openstack.org/pipermail/defcore-committee/2014-October/000418.html\n\n\n\n','<CAHXdxOf69nih+4AvP6N=uDCk9JbhjJhp0QD_TSGn4wxLjYT0Fw@mail.gmail.com>',NULL),('<1416501567.3417.1.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-20 10:39:27',-21600,'2014-11-20 16:39:27',NULL,'[openstack-dev] [api] Counting resources','On Thu, 2014-11-20 at 08:28 -0800, Morgan Fainberg wrote:\n> The only thing I want to caution against is making a SQL-specific\n> choice. In the case of some other backends, it may not be possible\n> (for an extremely large dataset) to get a full count, where SQL does\n> this fairly elegantly. For example, LDAP (in some cases) may have an\n> administrative limit that will say that no more than 10,000 entries\n> would be returned; likely you?re going to have an issue, since you\n> need to issue the query and see how many things match, if you hit the\n> overall limit you?ll get the same count every time (but possibly a\n> different dataset).\n\nHmmm?interesting limitation.\n\n> I want to be very careful that we?re not recommending functionality as\n> a baseline that should be used as a pattern across all similar APIs,\n> especially since we have some backends/storage systems that can?t\n> elegantly always support it.\n> \n> \n> Personally, I like Gerrit?s model (as Sean described) - with the above\n> caveat that not all backends support this type of count.\n\nHow about if we include some sentinel that can be used to indicate that\ncount is unsupported, to cover cases such as an LDAP backend?  That\ncould be as simple as allowing a null value.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<D2C954A2-BF2C-40F1-8B48-3AB5417941A5@gmail.com>',NULL),('<1416504144-sup-8401@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-11-20 09:29:47',-28800,'2014-11-20 17:29:47',NULL,'[OpenStack-Infra] [storyboard] Paging results','Excerpts from Jay Pipes\'s message of 2014-11-19 19:35:18 -0800:\n> On 11/19/2014 09:49 PM, Robert Collins wrote:\n> > On 20 November 2014 13:43, Jay Pipes <jaypipes at gmail.com> wrote:\n> >> On 11/19/2014 07:32 PM, Michael Krotscheck wrote:\n> >>>\n> >>> Jay-\n> >>>\n> >>> My own UX tests have demonstrated a need for both page jumping, and\n> >>> being able to communicate to a user where they are in their list. I\'d be\n> >>> happy to show you the videos if you have a few hours.\n> >>\n> >>\n> >> I don\'t have a few hours, no. :) But, what use case does jumping to page 7\n> >> of some results listing fulfill?\n> >\n> > For one, remembering where you were and coming back to it (more or less).\n> \n> Sorry, I don\'t get this at all. I have never, once, wanted to coming \n> back to some random page of results. I often want to come back to a \n> specific record, but that\'s not what we\'re talking about here.\n> \n> I can think of no time in my life that I\'ve thought to myself \"Oh, you \n> know, I really should go back to page 17 of my Google search results for \n> \'frobnozzle\'\". It just isn\'t a valid use case, IME.\n> \n\n\"I saw a bug about that, can\'t remember the title exactly but it was\naround page 17.\"\n\n> > Jumping by batch index is cheap compared to the proposed\n> > clone-the-result-set-ids thing, and IME useful enough that I\'d be\n> > annoyed at a system without it.\n> \n> What does \"jump to page 17\" give you -- usefulness-wise -- over seeing \n> that there is a) X number of results in total and/or b) there are more \n> results to page through?\n> \n\nHuman brains don\'t all work the same. Perhaps there are quite a few\npeople who jump to specific pages.\n\n> > @Michael - I suggest just using a simple stable batch marker - e.g.\n> > the unique key of the edge of the batch - which is stable enough to\n> > handle inserts and deletes without double-showing or skipping rows.\n> \n> That\'s what already exists in olso.db.utils.paginate_query(). The marker \n> is the unique key of the edge of the batch.\n> \n\nPretty sure one could count the batches one time and assign page numbers\nto them as they\'re seen in a cache, rather than materializing a whole\nresult set.\n\n\n','<546D6176.4030203@gmail.com>',NULL),('<1416506545.09852585@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-11-20 12:02:25',-21600,'2014-11-20 18:02:25',NULL,'[openstack-community] One spot left in OpenStack Pavilion at\n	Gartner Data Center Conference','\nAct soon to take advantage of the last spot in the OpenStack Pavilion at the Gartner Data Center Conference, Dec. 2-5 in Las Vegas.  Join the Foundation, Metacloud (now part of Cisco), Canonical and Internap at this high-quality event.  The audience is IT infrastructure decision makers and architects.  Participants were happy with the qualified contacts they made at last year\'s event!  Please contact me for details if interested. Thank you.\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141120/a1f9932f/attachment.html>\n\n',NULL,NULL),('<1416664217241.7e6e6bc6@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-22 05:50:18',-28800,'2014-11-22 13:50:18',NULL,'[openstack-dev] Status of Neutron IPv6 dual stack','Harm,\n\n\nWe were not able to enable dual stack with l3 routers in Juno release. You may need to wait for Kilo to see if that can be pushed in.\n\n\n\n\nXu Han?\n?\nXu Han Peng (xuhanp)\n\nOn Sat, Nov 22, 2014 at 3:03 AM, Harm Weites <harm at weites.com> wrote:\n\n> Hi,\n> We\'re running Juno since a few weeks now, is it now possible to go dual\n> stack with l3-routers or are there some pieces missing and should I wait\n> for Kilo?\n> -Harm\n> On 08/19/2014 07:08 PM, Dane Leblanc (leblancd) wrote:\n>>\n>> Hi Harm:\n>>\n>>  \n>>\n>> Unfortunately I haven?t had time to complete the changes yet. Even\n>> if/when these changes are completed, it?s unlikely that this blueprint\n>> will get approved for Juno, but I?ll see what I can do.\n>>\n>>  \n>>\n>> Thanks,\n>>\n>> Dane\n>>\n>>  \n>>\n>>  \n>>\n>> *From:*Harm Weites [mailto:harm at weites.com]\n>> *Sent:* Tuesday, August 19, 2014 12:53 PM\n>> *To:* openstack-dev at lists.openstack.org\n>> *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack\n>>\n>>  \n>>\n>> Thiago,\n>>\n>> My old setup was dual-stacked, simply using a flat linuxbridge. It\'s\n>> just that I now realy would like to separate multiple tenants using L3\n>> routers, which should be easy (dual stacked) to achieve once Dane\'s\n>> work is completed.\n>>\n>> Did you find the time to commit those required changes for that yet Dane?\n>>\n>> Regards,\n>> Harm\n>>\n>> op 16-08-14 23:33, Martinx - ????? schreef:\n>>\n>>     Guys,\n>>\n>>      \n>>\n>>     Just for the record, I\'m using IceHouse in a Dual-Stacked\n>>     environment (with security groups working) but, Instance\'s IPv6\n>>     address are static (no upstream SLAAC, arrived in Juno-2, I think)\n>>     and the topology is `VLAN Provider Networks`, no Neutron L3\n>>     Router. Where each VLAN have v4/v6 addrs, same upstream router\n>>     (also dual-stacked - still no radvd enabled).\n>>\n>>      \n>>\n>>     Looking forward to start testing L3 + IPv6 in K...\n>>\n>>      \n>>\n>>     Best,\n>>\n>>     Thiago\n>>\n>>      \n>>\n>>     On 16 August 2014 16:21, Harm Weites <harm at weites.com\n>>     <mailto:harm at weites.com>> wrote:\n>>\n>>     Hi Dane,\n>>\n>>     Thanks, that looks promising. Once support for multiple v6\n>>     addresses on\n>>     gateway ports is added I\'ll be happy to give this a go. Should it work\n>>     just fine with an otherwise Icehouse based deployment?\n>>\n>>     Regards,\n>>     Harm\n>>\n>>     op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:\n>>\n>>     > Hi Harm:\n>>     >\n>>     > Can you take a look at the following, which should address this:\n>>     >   \n>>      https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes\n>>     >\n>>     > There are some diffs out for review for this blueprint:\n>>     >    https://review.openstack.org/#/c/113339/\n>>     > but the change to support 1 V4 + multiple V6 addresses on a\n>>     gateway port hasn\'t been added yet. I should be adding this soon.\n>>     >\n>>     > There was a request for a Juno feature freeze exception for this\n>>     blueprint, but there\'s been no response, so this may not get\n>>     approved until K release.\n>>     >\n>>     > -Dane\n>>     >\n>>     > -----Original Message-----\n>>     > From: Harm Weites [mailto:harm at weites.com <mailto:harm at weites.com>]\n>>     > Sent: Saturday, August 16, 2014 2:22 PM\n>>     > To: openstack-dev at lists.openstack.org\n>>     <mailto:openstack-dev at lists.openstack.org>\n>>     > Subject: [openstack-dev] Status of Neutron IPv6 dual stack\n>>     >\n>>     > Hi,\n>>     >\n>>     > Given the work on [1] has been abandoned, I\'m wondering what the\n>>     current status of going dual stack is. Of course, given Neutron\n>>     got something like that on it\'s roadmap.\n>>     >\n>>     > The initial BP [2] aimed for Havana and Icehouse, and I\'m\n>>     unaware of something similar to achieve a dual stack network. What\n>>     are the options, if any? To my knowledge it all comes down to\n>>     supporting multiple exterior interfaces (networks) on a l3-agent,\n>>     which is currently limited to just 1: either IP4 or IP6.\n>>     >\n>>     > [1] https://review.openstack.org/#/c/77471/\n>>     > [2]\n>>     >\n>>     https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port\n>>     >\n>>     > Regards,\n>>     > Harm\n>>     >\n>>     > _______________________________________________\n>>     > OpenStack-dev mailing list\n>>     > OpenStack-dev at lists.openstack.org\n>>     <mailto:OpenStack-dev at lists.openstack.org>\n>>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>     >\n>>     > _______________________________________________\n>>     > OpenStack-dev mailing list\n>>     > OpenStack-dev at lists.openstack.org\n>>     <mailto:OpenStack-dev at lists.openstack.org>\n>>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n>>     _______________________________________________\n>>     OpenStack-dev mailing list\n>>     OpenStack-dev at lists.openstack.org\n>>     <mailto:OpenStack-dev at lists.openstack.org>\n>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>      \n>>\n>>\n>>\n>>\n>>     _______________________________________________\n>>\n>>     OpenStack-dev mailing list\n>>\n>>     OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>\n>>\n>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>  \n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141122/5e119bde/attachment.html>\n\n','<546F8C26.6070209@weites.com>',NULL),('<1416853335.3672.12.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-24 13:22:15',-18000,'2014-11-24 18:22:15',NULL,'[openstack-dev] [sahara] Discussion on cm_api for global requirement','Hello all,\n\n  at our last Sahara IRC meeting we started discussing whether or not to add\na global requirement for cm_api.py https://review.openstack.org/#/c/130153/\n\n  One issue (but not the only issue) is that cm_api is not packaged for Fedora,\nCentos, or Ubuntu currently. The global requirements README points out that adding\nrequirements for a new dependency more or less forces the distros to package the \ndependency for the next OS release.\n\n  Given that cm_api is needed for a plugin, but not for core Sahara functionality,\nshould we request that the global requirement be added, or should we seek to add\na global requirement only if/when cm_api is packaged?\n\n  Alternatively, can we support the plugin with additional documentation (ie, how\nto install cm_api on the Sahara node)?\n\n  Those present at the meeting agreed that it was probably better to defer a global\nrequirement until/unless cm_api is packaged to avoid a burden on the distros.\n\n  Thoughts?\n\nBest,\n\nTrevor\n\nMinutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-11-20-18.01.html\nLogs: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-11-20-18.01.log.html\nhttps://github.com/openstack/requirements\n\n\n\n\n\n',NULL,NULL),('<1416867738.3960.19.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-24 22:23:20',0,'2014-11-24 22:23:20',NULL,'[openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use\n Cases that led us to adopt this.','My impression is that the statuses of each entity will be shown on a\ndetailed info request of a loadbalancer.  The root level objects would\nnot have any statuses.  For example a user makes a GET request\nto /loadbalancers/{lb_id} and the status of every child of that load\nbalancer is show in a \"status_tree\" json object.  For example:\n\n{\"name\": \"loadbalancer1\",\n \"status_tree\":\n  {\"listeners\": \n    [{\"name\": \"listener1\", \"operating_status\": \"ACTIVE\",\n      \"default_pool\":\n        {\"name\": \"pool1\", \"status\": \"ACTIVE\",\n         \"members\":\n           [{\"ip_address\": \"10.0.0.1\", \"status\": \"OFFLINE\"}]}}\n\nSam, correct me if I am wrong.\n\nI generally like this idea.  I do have a few reservations with this:\n\n1) Creating and updating a load balancer requires a full tree\nconfiguration with the current extension/plugin logic in neutron.  Since\nupdates will require a full tree, it means the user would have to know\nthe full tree configuration just to simply update a name.  Solving this\nwould require nested child resources in the URL, which the current\nneutron extension/plugin does not allow.  Maybe the new one will.\n\n2) The status_tree can get quite large depending on the number of\nlisteners and pools being used.  This is a minor issue really as it will\nmake horizon\'s (or any other UI tool\'s) job easier to show statuses.\n\nThanks,\nBrandon\n\nOn Mon, 2014-11-24 at 12:43 -0800, Stephen Balukoff wrote:\n> Hi Samuel,\n> \n> \n> We\'ve actually been avoiding having a deeper discussion about status\n> in Neutron LBaaS since this can get pretty hairy as the back-end\n> implementations get more complicated. I suspect managing that is\n> probably one of the bigger reasons we have disagreements around object\n> sharing. Perhaps it\'s time we discussed representing state\n> \"correctly\" (whatever that means), instead of a round-a-bout\n> discussion about object sharing (which, I think, is really just\n> avoiding this issue)?\n> \n> \n> Do you have a proposal about how status should be represented\n> (possibly including a description of the state machine) if we collapse\n> everything down to be logical objects except the loadbalancer object?\n> (From what you\'re proposing, I suspect it might be too general to, for\n> example, represent the UP/DOWN status of members of a given pool.)\n> \n> \n> Also, from an haproxy perspective, sharing pools within a single\n> listener actually isn\'t a problem. That is to say, having the same\n> L7Policy pointing at the same pool is OK, so I personally don\'t have a\n> problem allowing sharing of objects within the scope of parent\n> objects. What do the rest of y\'all think?\n> \n> \n> Stephen\n> \n> \n> \n> On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici\n> <SamuelB at radware.com> wrote:\n>         Hi Stephen,\n>         \n>          \n>         \n>         1.      The issue is that if we do 1:1 and allow status/state\n>         to proliferate throughout all objects we will then get an\n>         issue to fix it later, hence even if we do not do sharing, I\n>         would still like to have all objects besides LB be treated as\n>         logical.\n>         \n>         2.      The 3rd use case bellow will not be reasonable without\n>         pool sharing between different policies. Specifying different\n>         pools which are the same for each policy make it non-started\n>         to me. \n>         \n>          \n>         \n>         -Sam.\n>         \n>          \n>         \n>          \n>         \n>          \n>         \n>         From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n>         Sent: Friday, November 21, 2014 10:26 PM\n>         To: OpenStack Development Mailing List (not for usage\n>         questions)\n>         Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects\n>         in LBaaS - Use Cases that led us to adopt this.\n>         \n>          \n>         \n>         I think the idea was to implement 1:1 initially to reduce the\n>         amount of code and operational complexity we\'d have to deal\n>         with in initial revisions of LBaaS v2. Many to many can be\n>         simulated in this scenario, though it does shift the burden of\n>         maintenance to the end user. It does greatly simplify the\n>         initial code for v2, in any case, though.\n>         \n>         \n>          \n>         \n>         \n>         Did we ever agree to allowing listeners to be shared among\n>         load balancers?  I think that still might be a N:1\n>         relationship even in our latest models.\n>         \n>          \n>         \n>         \n>         There\'s also the difficulty introduced by supporting different\n>         flavors:  Since flavors are essentially an association between\n>         a load balancer object and a driver (with parameters), once\n>         flavors are introduced, any sub-objects of a given load\n>         balancer objects must necessarily be purely logical until they\n>         are associated with a load balancer.  I know there was talk of\n>         forcing these objects to be sub-objects of a load balancer\n>         which can\'t be accessed independently of the load balancer\n>         (which would have much the same effect as what you discuss:\n>         State / status only make sense once logical objects have an\n>         instantiation somewhere.) However, the currently proposed API\n>         treats most objects as root objects, which breaks this\n>         paradigm.\n>         \n>         \n>          \n>         \n>         \n>         How we handle status and updates once there\'s an instantiation\n>         of these logical objects is where we start getting into real\n>         complexity.\n>         \n>         \n>          \n>         \n>         \n>         It seems to me there\'s a lot of complexity introduced when we\n>         allow a lot of many to many relationships without a whole lot\n>         of benefit in real-world deployment scenarios. In most cases,\n>         objects are not going to be shared, and in those cases with\n>         sufficiently complicated deployments in which shared objects\n>         could be used, the user is likely to be sophisticated enough\n>         and skilled enough to manage updating what are essentially\n>         \"copies\" of objects, and would likely have an opinion about\n>         how individual failures should be handled which wouldn\'t\n>         necessarily coincide with what we developers of the system\n>         would assume. That is to say, allowing too many many to many\n>         relationships feels like a solution to a problem that doesn\'t\n>         really exist, and introduces a lot of unnecessary complexity.\n>         \n>         \n>          \n>         \n>         \n>         In any case, though, I feel like we should walk before we run:\n>         Implementing 1:1 initially is a good idea to get us rolling.\n>         Whether we then implement 1:N or M:N after that is another\n>         question entirely. But in any case, it seems like a bad idea\n>         to try to start with M:N.\n>         \n>         \n>          \n>         \n>         \n>         Stephen\n>         \n>         \n>          \n>         \n>         \n>          \n>         \n>         On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici\n>         <SamuelB at radware.com> wrote:\n>         \n>         Hi,\n>         \n>         Per discussion I had at OpenStack Summit/Paris with Brandon\n>         and Doug, I would like to remind everyone why we choose to\n>         follow a model where pools and listeners are shared (many to\n>         many relationships).\n>         \n>         Use Cases:\n>         1. The same application is being exposed via different LB\n>         objects.\n>         For example: users coming from the internal \"private\"\n>         organization network, have an LB1(private_VIP) -->\n>         Listener1(TLS) -->Pool1 and user coming from the \"internet\",\n>         have LB2(public_vip)-->Listener1(TLS)-->Pool1.\n>         This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP)\n>         --> Listener1(TLS) -->Pool1 and LB_v6(ipv6_VIP) -->\n>         Listener1(TLS) -->Pool1\n>         The operator would like to be able to manage the pool\n>         membership in cases of updates and error in a single place.\n>         \n>         2. The same group of servers is being used via different\n>         listeners optionally also connected to different LB objects.\n>         For example: users coming from the internal \"private\"\n>         organization network, have an LB1(private_VIP) -->\n>         Listener1(HTTP) -->Pool1 and user coming from the \"internet\",\n>         have LB2(public_vip)-->Listener2(TLS)-->Pool1.\n>         The LBs may use different flavors as LB2 needs TLS termination\n>         and may prefer a different \"stronger\" flavor.\n>         The operator would like to be able to manage the pool\n>         membership in cases of updates and error in a single place.\n>         \n>         3. The same group of servers is being used in several\n>         different L7_Policies connected to a listener. Such listener\n>         may be reused as in use case 1.\n>         For example: LB1(VIP1)-->Listener_L7(TLS)\n>                                                     |\n>         \n>         +-->L7_Policy1(rules..)-->Pool1\n>                                                     |\n>         \n>         +-->L7_Policy2(rules..)-->Pool2\n>                                                     |\n>         \n>         +-->L7_Policy3(rules..)-->Pool1\n>                                                     |\n>         \n>         +-->L7_Policy3(rules..)-->Reject\n>         \n>         \n>         I think that the \"key\" issue handling correctly the\n>         \"provisioning\" state and the operation state in a many to many\n>         model.\n>         This is an issue as we have attached status fields to each and\n>         every object in the model.\n>         A side effect of the above is that to understand the\n>         \"provisioning/operation\" status one needs to check many\n>         different objects.\n>         \n>         To remedy this, I would like to turn all objects besides the\n>         LB to be logical objects. This means that the only place to\n>         manage the status/state will be on the LB object.\n>         Such status should be hierarchical so that logical object\n>         attached to an LB, would have their status consumed out of the\n>         LB object itself (in case of an error).\n>         We also need to discuss how modifications of a logical object\n>         will be \"rendered\" to the concrete LB objects.\n>         You may want to revisit\n>         https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r the \"Logical Model + Provisioning Status + Operation Status + Statistics\" for a somewhat more detailed explanation albeit it uses the LBaaS v1 model as a reference.\n>         \n>         Regards,\n>                 -Sam.\n>         \n>         \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n>         \n>         \n>         \n>          \n>         \n>         \n>         -- \n>         \n>         Stephen Balukoff \n>         Blue Box Group, LLC \n>         (800)613-4305 x807 \n>         \n>         \n>         \n>         _______________________________________________\n>         OpenStack-dev mailing list\n>         OpenStack-dev at lists.openstack.org\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>         \n> \n> \n> \n> \n> -- \n> Stephen Balukoff \n> Blue Box Group, LLC \n> (800)613-4305 x807\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAAGw+ZpT=s3mRjG56oXR0zLhvHGAPM-EStDXTK5kqmYatKZFXw@mail.gmail.com>',NULL),('<1416869090.3092.12.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-24 16:44:50',-21600,'2014-11-24 22:44:50',NULL,'[openstack-dev] [Nova] Handling soft delete for instance rows\n in a new cells database','On Tue, 2014-11-25 at 09:20 +1100, Michael Still wrote:\n>  - we do what we do in the current nova database -- we have a deleted\n> column, and we set it to true when we delete the instance.\n\nActually, current nova uses the\noslo.db.sqlalchemy.models.SoftDeleteMixin class, which defines the\ncolumns \'deleted_at\' (a DateTime) and \'deleted\' (an *integer*).  It also\ndefines a \'soft_delete()\' method, which sets the \'deleted\' column to the\nrow \'id\'.  As I understand it, this is to keep from breaking uniqueness\nconstraints; you factor in \'deleted\' in your uniqueness constraint, and\nyou can have as many identical deleted records as you want?\n\n>  - we have shadow tables and we move delete rows to a shadow table.\n> \n>  - something else super clever I haven\'t thought of.\n\nWell, one thought might be to create a single \'audit\' table with a\ncouple of columns?a timestamp, say, and some sort of description of the\nchange, perhaps as a JSON object.  On a \'delete\' operation, you could\nstore the values of the row into this audit table.\n\n>From an operator\'s standpoint, this could provide the required auditing\nand perhaps even a limited DR solution, while centralizing the data you\nneed to monitor in a single location, which makes it easier to trim the\ndata at intervals as needed.  While I\'ve proposed this as a soft-delete\nsolution, it would also provide the ability to record other changes to\nobjects; one could even include a column to record who performed the\nchange.  And of course I\'ve suggested this as a DB table, but we could\nalso consider the merits of ditching the table and doing the same thing\nas some sort of notification through the notifications system?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAEd1pt4NY8T=S5o5W0etaUqJ5vG_x5Mh6rWtTnZ7x8FgcV4caQ@mail.gmail.com>',NULL),('<1416928101.3279.7.camel@tmckaylt.rdu.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 10:08:21',-18000,'2014-11-25 15:08:21',NULL,'[openstack-dev] [sahara] Asia friendly IRC meeting time','+1 for me, too.  But I agree with Mike -- we need input from Saratov and\nsimilar time zones.\n\nI think though that the folks in Saratov generally try to shift hours\nanyway, to better align with the rest of us.  So I think something that\nworks for the US will likely work for them.\n\nTrev\n\nOn Tue, 2014-11-25 at 09:54 -0500, michael mccune wrote:\n> On 11/25/2014 02:37 AM, Zhidong Yu wrote:\n> > I know it\'s difficult to find a time good for both US, Europe and Asia.\n> > I suggest we could have two different meeting series with different\n> > time, i.e. US/Europe meeting this week, US/Asia meeting next week, and\n> > so on.\n> \n> i\'d be ok with alternating week schedules\n> \n> > My proposal:\n> >      18:00UTC: Moscow (9pm)    China(2am)     US West(10am)\n> >      00:00UTC: Moscow (3am)    China(8am)     US West(4pm)\n> >\n> \n> this works for me, but i realize it might be difficult for the folks in \n> Russia. not sure if there is a better option though.\n> \n> thanks for putting this forward Zhidong\n> \n> regards,\n> mike\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<5474981B.7090905@redhat.com>',NULL),('<1416935765.3337419.195281053.6E1808C3@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-11-25 09:16:05',-28800,'2014-11-25 17:16:05',NULL,'[OpenStack-Infra] [openstack-infra] [zuul] GitPython 0.3.2.1\n	fixes','\n\nOn Tue, Nov 25, 2014, at 06:55 AM, Heald, Mike wrote:\n> Hi all,\n> \n> I\'ve been investigating why the tests break with\n> GitPython 0.3.2.1, and I\'ve tracked the problem down\n> to a commit in GitPython, but I\'m not sure where\n> the fix should go.\n> \n> In GitPython, commit ff13922f [1], a call to finalize_process\n> was added into the Repo class. finalize_process\n> is there to make sure the call to the git binary is\n> shut down cleanly, but it also picks up exit code 128\n> and re-raises the GitCommandError exception if the\n> binary exited with that return code, otherwise it suppresses\n> the exception. The comments state that return code 128\n> is used if there was a connection error, so it makes sense\n> that we\'d raise an exception then. However, 128 is also\n> returned if you ask for a rev-list for a ref that does\n> not exist locally [2], which we legitimately do in zuul (at least\n> in the tests), but because of that added call, zuul\n> acts as if there was a connection error. That shouldn\'t\n> happen.\n> \n> I can think of a few options to fix this:\n> \n> 1) Fix zuul so that we handle GitCommandError when we\'re\n> checking out refs. There\'s a review open [3] that already\n> fixes the tests, and it seems that we already handle\n> GitCommandError in the main code when we know it\n> could happen.\n> \n> 2) Fix finalize_process somehow to only re-raise the\n> exception when git is dealing with a remote source - \n> this seems very tricky as we\'d need to inspect the original\n> command used to spawn the process...\n> \n> 3) Deal with the GitCommandError in GitPython, handling\n> GitCommandError when we know we\'re not dealing with a\n> remote source, or it doesn\'t make sense to raise a connection\n> related error (like, when you\'re checking for local untracked files).\n> \n> 4) Do 1 and 3.\n> \n> What looks best? I\'m keen to get this fixed :)\n> \n> Cheers,\n> Mike\n> \n> [1] https://github.com/gitpython-developers/GitPython/commit/ff13922f\n> [2] :\n> mikeh at TARDIS:~/code/zuul$ git rev-list refs/i/do/not/exist\n> fatal: ambiguous argument \'refs/i/do/not/exist\': unknown revision or path\n> not in the working tree.\n> Use \'--\' to separate paths from revisions, like this:\n> \'git <command> [<revision>...] -- [<file>...]\'\n> mikeh at TARDIS:~/code/zuul$ echo $?\n> 128\n> [3] https://review.openstack.org/#/c/136281/\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nI think we should move ahead with 1 and potentially try 3. I am not sure\nhow easy it will be to get the fix into GitPython but we can give it a\ngo and as long as we also do 1 and handle these exceptions in Zuul then\ngetting the fix into GitPython isn\'t critical. The other benefit to\nhandling these cases in Zuul is we will support a larger number of\nGitPython releases (we can exclude those that we don\'t work with but not\ndoing that is even better).\n\nClark\n\n\n','<311995D1237EC0498D6D8FAFA73D6F458B0A89@G9W0762.americas.hpqcorp.net>',NULL),('<1416984585274.70206@accenture.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 06:49:46',0,'2014-11-26 06:49:46',NULL,'[openstack-dev] [Murano] - puka dependency','y\n\n\nHi All,\n\nI am new to Murano trying to implement on Openstack Juno with Ubuntu 14.04 LTS version. However It needs puka <0.7 as dependency.\nI would appreciate any help with the build guides. I also find Github prompts for username and password while I try installing packages.\n\n\n\nWarm Regards,\nRaghavendra Lad\n\n\n\n________________________________\n\nThis message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n______________________________________________________________________________________\n\nwww.accenture.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141126/5bef1ab1/attachment-0001.html>\n\n','<9cc51511fa7546419c4d0d546442217b@BY2PR42MB101.048d.mgd.msft.net>',NULL);
INSERT INTO `messages` VALUES ('<1416987262.4483.11.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-26 08:34:22',3600,'2014-11-26 07:34:22',NULL,'[Openstack-operators] Need help to setup instance tunnel.','Hi Geo, \nyour packet will be sent out of br-tun via the gre-xxxxx port \"pointing\"\nto your compute node. So what you have to do is to put the ip address to\nyour eth interface connected to the wire. The same of course on the\ncontroller node. Putting the ip address on the br-tun does not make\nsense, as it just hangs around without any physical port plugged in.\n\nThis is how my ovs-vsctl show looks like on the compute node.\n\novs-vsctl show\n9253a3f8-3c28-4953-ae85-ca94aa0d4fb1\n    Bridge br-tun\n        Port br-tun\n            Interface br-tun\n                type: internal\n        Port \"gre-c0a801ca\"\n            Interface \"gre-c0a801ca\"\n                type: gre\n                options: {in_key=flow, local_ip=\"192.168.1.190\",\nout_key=flow, remote_ip=\"192.168.1.202\"}\n        Port patch-int\n            Interface patch-int\n                type: patch\n                options: {peer=patch-tun}\n    Bridge br-int\n        Port br-int\n            Interface br-int\n                type: internal\n        Port patch-tun\n            Interface patch-tun\n                type: patch\n                options: {peer=patch-int}\n        Port \"qvo1c352474-0c\"\n            tag: 1\n            Interface \"qvo1c352474-0c\"\n        Port \"qvo5782980b-be\"\n            tag: 4095\n            Interface \"qvo5782980b-be\"\n    ovs_version: \"2.1.2\"\n\n\n\nAnd this is the ip configuration of the net device used:\n\n22: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast\nstate DOWN qlen 1000\n    link/ether 02:00:00:39:13:9a brd ff:ff:ff:ff:ff:ff\n    inet 192.168.1.190/24 brd 192.168.1.255 scope global eth0\n       valid_lft forever preferred_lft forever\n\n\n\n\n\nAnd this is my ml2.conf on the compute node\n\n[ovs]\nlocal_ip = 192.168.1.190\ntunnel_type = gre\nenable_tunneling = True\n\n\n\nRegards\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-11-26 at 01:39 +0530, Geo Varghese wrote:\n> Hi Team,\n> \n> \n> \n> I need some help to setup instance tunnel.\n> \n> \n> I tried 2 node installation today and successfully added new compute1\n> node. \n> \n> Later i have created new VM on new compute1 node. It successfully\n> spawned but the issue is it couldn\'t get dhcp ip.\n> \n> Due to this eth0 is not assigned with an IP address. I think instance\n> tunnel interface is not correct.\n> \n> Currently I set IP to automatically created interface br-tun, do i\n> need to create new instance tunnel?\n> \n> =========================================\n> br-tun Link encap:Ethernet HWaddr 6a:65:2d:ed:90:44 \n> inet addr:192.168.123.179 Bcast:192.168.123.255 Mask:255.255.255.0\n> inet6 addr: fe80::98c7:a1ff:fef6:bcd7/64 Scope:Link\n> UP BROADCAST RUNNING MTU:1500 Metric:1\n> RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0\n> collisions:0 txqueuelen:0 \n> RX bytes:0 (0.0 B) TX bytes:648 (648.0 B)\n> =========================================\n> \n> And given this Ip addres(192.168.123.179) in [mvs] configuration\n> (/etc/neutron/plugins/ml2/ml2_conf.ini)\n> \n> [ovs]\n> local_ip = 192.168.123.179\n> tunnel_type = gre\n> enable_tunneling = True\n> \n> Is it correct? Please help me.\n> \n> \n> --\n> Regards,\n> Geo Varghese\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<CADB-E-sUMB+U6rO=UwDk4FCupQ2r6m54mGe5smKEkO+A0LG-ZA@mail.gmail.com>',NULL),('<1417000854.3031.79.camel@linode2.nicolast.be>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 12:20:54',3600,'2014-11-26 11:20:54',NULL,'[openstack-dev] [nova] Proposal new hacking rules','On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:\n> I think pointing out that the default failure \n> message for testtools.TestCase.assertEqual() uses the terms\n> \"reference\" \n> (expected) and \"actual\" is a reason why reviewers *should* ask patch \n> submitters to use (expected, actual) ordering.\n\nIs there any reason for this specific ordering? Not sure about others,\nbut I tend to write equality comparisons like this\n\n    if var == 1:\n\ninstead of\n\n    if 1 == var:\n\n(although I\'ve seen the latter in C code before).\n\nThis gives rise to\n\n    assert var == 1\n\nor, moving into `unittest` domain\n\n    assertEqual(var, 1)\n\nreading it as \'Assert `var` equals 1\', which makes me wonder why the\n`assertEqual` API is defined the other way around (unlike how I\'d write\nany other equality check).\n\nNicolas\n\n\n\n','<547376C4.8030004@gmail.com>',NULL),('<1417007097.4483.26.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 14:04:57',3600,'2014-11-26 13:04:57',NULL,'[openstack-dev] [devstack] environment variables in local.conf\n	post-config section','Hi together, \nis there a way to use Environment variables in the local.conf\npost-config section?\n\nOn my system (stable/juno devstack) not the content of the variable, but\nthe variable name itself is being inserted into the config file.\n\n\nSo e.g. \n[[post-config|$NOVA_CONF]]\n[DEFAULT]\nvncserver_proxyclient_address=$HOST_IP_MGMT\n\nresults in nova.conf as:\nvncserver_proxyclient_address = $HOST_IP_MGMT\n\n\n\nThanks\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1417008943.4483.29.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-26 14:35:43',3600,'2014-11-26 13:35:43',NULL,'[Openstack] Cannot launch instance: No valid host was found:\n Port failed to bind on host','Hi Uwe, \ncould you please provide the content of your /etc/neutron/plugin.ini of\nthe compute and the network node?\n\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-11-26 at 14:14 +0100, Uwe Sauter wrote:\n> Hi George,\n> \n> it seems I missed to list that service for the compute hosts.\n> These are the services running on those hosts:\n> \n> [root at os483401 ~]# systemctl list-units | grep -i open\n> neutron-openvswitch-agent.service\n>                          loaded active running   OpenStack Neutron Open\n> vSwitch Agent\n> openstack-nova-compute.service\n>                          loaded active running   OpenStack Nova Compute\n> Server\n> openvswitch-nonetwork.service\n>                          loaded active exited    Open vSwitch Internal Unit\n> openvswitch.service\n>                          loaded active exited    Open vSwitch\n> sshd.service\n>                          loaded active running   OpenSSH server daemon\n> iscsid.socket\n>                          loaded active listening Open-iSCSI iscsid Socket\n> iscsiuio.socket\n>                          loaded active listening Open-iSCSI iscsiuio Socket\n> \n> [root at os483401 ~]# systemctl status neutron-openvswitch-agent.service\n> neutron-openvswitch-agent.service - OpenStack Neutron Open vSwitch Agent\n>    Loaded: loaded\n> (/usr/lib/systemd/system/neutron-openvswitch-agent.service; enabled)\n>    Active: active (running) since Wed 2014-11-26 13:00:14 CET; 1h 11min ago\n>  Main PID: 1348 (neutron-openvsw)\n>    CGroup: /system.slice/neutron-openvswitch-agent.service\n>            ??1348 /usr/bin/python /usr/bin/neutron-openvswitch-agent\n> --config-file /usr/share/neutron/neutron-dist.conf --config-file\n> /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini --log-f...\n>            ??2627 sudo neutron-rootwrap /etc/neutron/rootwrap.conf\n> ovsdb-client monitor Interface name,ofport --format=json\n>            ??2629 /usr/bin/python /usr/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovsdb-client monitor Interface name,ofport\n> --format=json\n>            ??2631 /bin/ovsdb-client monitor Interface name,ofport\n> --format=json\n> \n> Nov 26 14:11:01 os483401.localnet sudo[9850]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:03 os483401.localnet sudo[9853]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:05 os483401.localnet sudo[9856]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:07 os483401.localnet sudo[9859]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:09 os483401.localnet sudo[9863]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:11 os483401.localnet sudo[9866]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:13 os483401.localnet sudo[9869]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:15 os483401.localnet sudo[9880]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:17 os483401.localnet sudo[9883]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> Nov 26 14:11:19 os483401.localnet sudo[9886]: neutron : TTY=unknown ;\n> PWD=/ ; USER=root ; COMMAND=/bin/neutron-rootwrap\n> /etc/neutron/rootwrap.conf ovs-ofctl dump-flows br-int table=23\n> \n> Any other ideas?\n> \n> Thanks,\n> \n> 	Uwe\n> \n> \n> Am 26.11.2014 um 13:49 schrieb George Mihaiescu:\n> > You have to install the neutron-openvswitch-agent on the compute nodes\n> > as well.\n> > \n> > On 26 Nov 2014 06:57, \"Uwe Sauter\" <uwe.sauter.de at gmail.com\n> > <mailto:uwe.sauter.de at gmail.com>> wrote:\n> > \n> >     Hi all,\n> > \n> >     I\'m trying to setup Juno on five hosts (CentOS 7), following along the\n> >     three-node setup guide as close as possible. My setup differs in that I\n> >     have separate nodes for storage (cinder, glance) and network (neutron)\n> >     and two compute hosts:\n> > \n> >     Here\'s a list of the services that run on each host, hostname aliases in\n> >     parentheses\n> > \n> >     os484001 (db mq ntp horizon keystone neutron-controller nova-controller)\n> >       dnsmasq (for name resolution in management network)\n> >       ntp\n> >       mariadb\n> >       memcached\n> >       httpd (horizon)\n> >       rabbitmq-server\n> >       keystone\n> >       nova-api\n> >       nova-cert\n> >       nova-condictor\n> >       nova-consoleauth\n> >       nova-novncproxy\n> >       nova-scheduler\n> >       neutron-server\n> >     os403801 (cinder cinder01 glance)\n> >       cinder-api\n> >       cinder-scheduler\n> >       cinder-volume\n> >       glance-api\n> >       glance-registry\n> >       target\n> >     os483601 (neutron)\n> >       neutron-dhcp-agent\n> >       neutron-l3-agent\n> >       neutron-metadata-agent\n> >       neutron-openvswitch-agent\n> >       neutron-ovs-cleanup\n> >       openvswitch\n> >     os483401 and os483201 (nova01 and nova02)\n> >       libvirtd\n> >       openstack-nova-compute\n> >       openvswitch\n> > \n> >     I have come as far as as installing cinder (chapter 8) and then ran into\n> >     the following issue: every time I try to start a new instance Horizon\n> >     shows a popup \"No valid host was found\". I didn\'t try to start an\n> >     instance before.\n> > \n> >     neutron server.log on the controller node (os484001) shows:\n> > \n> >     2014-11-26 11:09:56.363 5137 WARNING neutron.plugins.ml2.managers\n> >     [req-c40eb39a-ea68-4e0f-a901-bf267befd050 None] Failed to bind port\n> >     3cfcfa07-ab38-4ff3-8615-974334e6944e on host nova01\n> > \n> >     nova-compute.log from the hypervisor show:\n> > \n> >     2014-11-26 11:09:52.981 5436 DEBUG nova.compute.resources.vcpu\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Total CPUs: 8 VCPUs,\n> >     used: 0.00 VCPUs test\n> >     /usr/lib/python2.7/site-packages/nova/compute/resources/vcpu.py:51\n> >     2014-11-26 11:09:52.982 5436 DEBUG nova.compute.resources.vcpu\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] CPUs limit not\n> >     specified, defaulting to unlimited test\n> >     /usr/lib/python2.7/site-packages/nova/compute/resources/vcpu.py:55\n> >     2014-11-26 11:09:52.982 5436 AUDIT nova.compute.claims\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Claim successful\n> >     2014-11-26 11:09:53.092 5436 INFO nova.scheduler.client.report\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Compute_service record\n> >     updated for (\'nova01\', \'os483401.localnet\')\n> >     2014-11-26 11:09:53.204 5436 INFO nova.scheduler.client.report\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Compute_service record\n> >     updated for (\'nova01\', \'os483401.localnet\')\n> >     2014-11-26 11:09:53.207 5436 DEBUG nova.compute.manager [-] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Allocating IP information in the\n> >     background. _allocate_network_async\n> >     /usr/lib/python2.7/site-packages/nova/compute/manager.py:1627\n> >     2014-11-26 11:09:53.208 5436 DEBUG nova.network.neutronv2.api [-]\n> >     [instance: 5ac622df-fcbf-4e41-bac9-001ca00d43ac] allocate_for_instance()\n> >     allocate_for_instance\n> >     /usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py:279\n> >     2014-11-26 11:09:53.208 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/networks.json?id=1206629d-045d-4c3a-b83f-f0bf5dbb0add\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/networks.json?id=1206629d-045d-4c3a-b83f-f0bf5dbb0add\n> >     -X> GET -H \"X-Auth-Token: c63d5bcad5924a7ea8a9eaf2ff0c8156\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.240 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'271\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-bdea570d-d713-434e-9e93-129cb98d8c32\'}\n> >     {\"networks\": [{\"status\": \"ACTIVE\", \"subnets\":\n> >     [\"cc4d4225-bf18-4e02-a752-e4dbf381f250\"], \"name\": \"demo-net\",\n> >     \"router:external\": false, \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"admin_state_up\": true, \"shared\":\n> >     false, \"id\": \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.240 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/security-groups.json?tenant_id=5d3a5bbf404c4db28067929f40ba170e\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/security-groups.json?tenant_id=5d3a5bbf404c4db28067929f40ba170e\n> >     -X> GET -H \"X-Auth-Token: c63d5bcad5924a7ea8a9eaf2ff0c8156\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.259 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'1535\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-a1cad97a-7266-4d5c-837e-06a57475f047\'}\n> >     {\"security_groups\": [{\"tenant_id\": \"5d3a5bbf404c4db28067929f40ba170e\",\n> >     \"description\": \"default\", \"id\": \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\",\n> >     \"security_group_rules\": [{\"remote_group_id\": null, \"direction\":\n> >     \"egress\", \"remote_ip_prefix\": null, \"protocol\": null, \"ethertype\":\n> >     \"IPv4\", \"tenant_id\": \"5d3a5bbf404c4db28067929f40ba170e\",\n> >     \"port_range_max\": null, \"port_range_min\": null, \"id\":\n> >     \"08fe4d2c-3475-4efe-baa6-5d3f1200b964\", \"security_group_id\":\n> >     \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"}, {\"remote_group_id\": null,\n> >     \"direction\": \"egress\", \"remote_ip_prefix\": null, \"protocol\": null,\n> >     \"ethertype\": \"IPv6\", \"tenant_id\": \"5d3a5bbf404c4db28067929f40ba170e\",\n> >     \"port_range_max\": null, \"port_range_min\": null, \"id\":\n> >     \"390f124d-d357-4348-897a-c055c7b81375\", \"security_group_id\":\n> >     \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"}, {\"remote_group_id\":\n> >     \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\", \"direction\": \"ingress\",\n> >     \"remote_ip_prefix\": null, \"protocol\": null, \"ethertype\": \"IPv4\",\n> >     \"tenant_id\": \"5d3a5bbf404c4db28067929f40ba170e\", \"port_range_max\": null,\n> >     \"port_range_min\": null, \"id\": \"66b6e33e-3972-4e87-9d3c-97623ae74bcb\",\n> >     \"security_group_id\": \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"},\n> >     {\"remote_group_id\": \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\", \"direction\":\n> >     \"ingress\", \"remote_ip_prefix\": null, \"protocol\": null, \"ethertype\":\n> >     \"IPv6\", \"tenant_id\": \"5d3a5bbf404c4db28067929f40ba170e\",\n> >     \"port_range_max\": null, \"port_range_min\": null, \"id\":\n> >     \"6ad70f09-28b6-4b08-b860-997565b3e4b0\", \"security_group_id\":\n> >     \"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"}], \"name\": \"default\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.260 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i http://neutron-controller:9696/v2.0/extensions.json -X GET\n> >     -H \"X-Auth-Token: c63d5bcad5924a7ea8a9eaf2ff0c8156\" -H \"User-Agent:\n> >     python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.267 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'4111\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-f52c371f-7dc5-4fbb-8cba-f68387b19be3\'}\n> >     {\"extensions\": [{\"updated\": \"2012-10-05T10:00:00-00:00\", \"name\":\n> >     \"security-group\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/securitygroups/api/v2.0\", \"alias\":\n> >     \"security-group\", \"description\": \"The security groups extension.\"},\n> >     {\"updated\": \"2013-02-07T10:00:00-00:00\", \"name\": \"L3 Agent Scheduler\",\n> >     \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/l3_agent_scheduler/api/v1.0\", \"alias\":\n> >     \"l3_agent_scheduler\", \"description\": \"Schedule routers among l3\n> >     agents\"}, {\"updated\": \"2013-03-28T10:00:00-00:00\", \"name\": \"Neutron L3\n> >     Configurable external gateway mode\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/neutron/ext-gw-mode/api/v1.0\", \"alias\":\n> >     \"ext-gw-mode\", \"description\": \"Extension of the router abstraction for\n> >     specifying whether SNAT should occur on the external gateway\"},\n> >     {\"updated\": \"2014-02-03T10:00:00-00:00\", \"name\": \"Port Binding\",\n> >     \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/binding/api/v1.0\", \"alias\": \"binding\",\n> >     \"description\": \"Expose port bindings of a virtual port to external\n> >     application\"}, {\"updated\": \"2012-09-07T10:00:00-00:00\", \"name\":\n> >     \"Provider Network\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/provider/api/v1.0\", \"alias\": \"provider\",\n> >     \"description\": \"Expose mapping of virtual networks to physical\n> >     networks\"}, {\"updated\": \"2013-02-03T10:00:00-00:00\", \"name\": \"agent\",\n> >     \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/agent/api/v2.0\", \"alias\": \"agent\",\n> >     \"description\": \"The agent management extension.\"}, {\"updated\":\n> >     \"2012-07-29T10:00:00-00:00\", \"name\": \"Quota management support\",\n> >     \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/network/ext/quotas-sets/api/v2.0\", \"alias\":\n> >     \"quotas\", \"description\": \"Expose functions for quotas management per\n> >     tenant\"}, {\"updated\": \"2013-02-07T10:00:00-00:00\", \"name\": \"DHCP Agent\n> >     Scheduler\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/dhcp_agent_scheduler/api/v1.0\", \"alias\":\n> >     \"dhcp_agent_scheduler\", \"description\": \"Schedule networks among dhcp\n> >     agents\"}, {\"updated\": \"2014-04-26T00:00:00-00:00\", \"name\": \"HA Router\n> >     extension\", \"links\": [], \"namespace\": \"\", \"alias\": \"l3-ha\",\n> >     \"description\": \"Add HA capability to routers.\"}, {\"updated\":\n> >     \"2013-06-27T10:00:00-00:00\", \"name\": \"Multi Provider Network\", \"links\":\n> >     [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/multi-provider/api/v1.0\", \"alias\":\n> >     \"multi-provider\", \"description\": \"Expose mapping of virtual networks to\n> >     multiple physical networks\"}, {\"updated\": \"2013-01-14T10:00:00-00:00\",\n> >     \"name\": \"Neutron external network\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/neutron/external_net/api/v1.0\", \"alias\":\n> >     \"external-net\", \"description\": \"Adds external network attribute to\n> >     network resource.\"}, {\"updated\": \"2012-07-20T10:00:00-00:00\", \"name\":\n> >     \"Neutron L3 Router\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/neutron/router/api/v1.0\", \"alias\":\n> >     \"router\", \"description\": \"Router abstraction for basic L3 forwarding\n> >     between L2 Neutron networks and access to external networks via a NAT\n> >     gateway.\"}, {\"updated\": \"2013-07-23T10:00:00-00:00\", \"name\": \"Allowed\n> >     Address Pairs\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/allowedaddresspairs/api/v2.0\", \"alias\":\n> >     \"allowed-address-pairs\", \"description\": \"Provides allowed address\n> >     pairs\"}, {\"updated\": \"2013-02-01T10:00:00-00:00\", \"name\": \"Neutron Extra\n> >     Route\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/neutron/extraroutes/api/v1.0\", \"alias\":\n> >     \"extraroute\", \"description\": \"Extra routes configuration for L3\n> >     router\"}, {\"updated\": \"2013-03-17T12:00:00-00:00\", \"name\": \"Neutron\n> >     Extra DHCP opts\", \"links\": [], \"namespace\":\n> >     \"http://docs.openstack.org/ext/neutron/extra_dhcp_opt/api/v1.0\",\n> >     \"alias\": \"extra_dhcp_opt\", \"description\": \"Extra options configuration\n> >     for DHCP. For example PXE boot options to DHCP clients can be specified\n> >     (e.g. tftp-server, server-ip-address, bootfile-name)\"}, {\"updated\":\n> >     \"2014-06-1T10:00:00-00:00\", \"name\": \"Distributed Virtual Router\",\n> >     \"links\": [], \"namespace\": \"http://docs.openstack.org/ext/dvr/api/v1.0\",\n> >     \"alias\": \"dvr\", \"description\": \"Enables configuration of Distributed\n> >     Virtual Routers.\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.272 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i http://neutron-controller:9696/v2.0/ports.json -X POST -H\n> >     \"X-Auth-Token: eac96c62e33d439bb2f4af52fe0e963c\" -H \"User-Agent:\n> >     python-neutronclient\" -d \'{\"port\": {\"binding:host_id\": \"nova01\",\n> >     \"admin_state_up\": true, \"network_id\":\n> >     \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\", \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"device_owner\": \"compute:nova\",\n> >     \"security_groups\": [\"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"],\n> >     \"device_id\": \"5ac622df-fcbf-4e41-bac9-001ca00d43ac\"}}\'\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.300 5436 DEBUG nova.block_device\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] block_device_list []\n> >     volume_in_mapping\n> >     /usr/lib/python2.7/site-packages/nova/block_device.py:555\n> >     2014-11-26 11:09:53.440 5436 DEBUG nova.block_device\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] block_device_list []\n> >     volume_in_mapping\n> >     /usr/lib/python2.7/site-packages/nova/block_device.py:555\n> >     2014-11-26 11:09:53.441 5436 INFO nova.virt.libvirt.driver\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Creating image\n> >     2014-11-26 11:09:53.444 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Running cmd\n> >     (subprocess): env LC_ALL=C LANG=C qemu-img info\n> >     /var/lib/nova/instances/_base/3d07303977c640ff3d0e46b4566187db9ca7389b\n> >     execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:161\n> >     2014-11-26 11:09:53.472 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Result was 0 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:195\n> >     2014-11-26 11:09:53.475 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Running cmd\n> >     (subprocess): env LC_ALL=C LANG=C qemu-img info\n> >     /var/lib/nova/instances/_base/3d07303977c640ff3d0e46b4566187db9ca7389b\n> >     execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:161\n> >     2014-11-26 11:09:53.500 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Result was 0 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:195\n> >     2014-11-26 11:09:53.501 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Running cmd\n> >     (subprocess): qemu-img create -f qcow2 -o\n> >     backing_file=/var/lib/nova/instances/_base/3d07303977c640ff3d0e46b4566187db9ca7389b\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk\n> >     execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:161\n> >     2014-11-26 11:09:53.524 5436 DEBUG neutronclient.client [-] RESP:201\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'697\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-c40eb39a-ea68-4e0f-a901-bf267befd050\'}\n> >     {\"port\": {\"status\": \"DOWN\", \"binding:host_id\": \"nova01\",\n> >     \"allowed_address_pairs\": [], \"extra_dhcp_opts\": [], \"device_owner\":\n> >     \"compute:nova\", \"binding:profile\": {}, \"fixed_ips\": [{\"subnet_id\":\n> >     \"cc4d4225-bf18-4e02-a752-e4dbf381f250\", \"ip_address\":\n> >     \"192.168.200.12\"}], \"id\": \"3cfcfa07-ab38-4ff3-8615-974334e6944e\",\n> >     \"security_groups\": [\"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"],\n> >     \"device_id\": \"5ac622df-fcbf-4e41-bac9-001ca00d43ac\", \"name\": \"\",\n> >     \"admin_state_up\": true, \"network_id\":\n> >     \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\", \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"binding:vif_details\": {},\n> >     \"binding:vnic_type\": \"normal\", \"binding:vif_type\": \"binding_failed\",\n> >     \"mac_address\": \"fa:16:3e:41:de:fa\"}}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.528 5436 DEBUG nova.network.neutronv2.api [-]\n> >     [instance: 5ac622df-fcbf-4e41-bac9-001ca00d43ac] Successfully created\n> >     port: 3cfcfa07-ab38-4ff3-8615-974334e6944e _create_port\n> >     /usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py:216\n> >     2014-11-26 11:09:53.528 5436 DEBUG nova.network.neutronv2.api [-]\n> >     [instance: 5ac622df-fcbf-4e41-bac9-001ca00d43ac] get_instance_nw_info()\n> >     _get_instance_nw_info\n> >     /usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py:610\n> >     2014-11-26 11:09:53.531 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/ports.json?tenant_id=5d3a5bbf404c4db28067929f40ba170e&device_id=5ac622df-fcbf-4e41-bac9-001ca00d43ac\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/ports.json?tenant_id=5d3a5bbf404c4db28067929f40ba170e&device_id=5ac622df-fcbf-4e41-bac9-001ca00d43ac\n> >     -X> GET -H \"X-Auth-Token: eac96c62e33d439bb2f4af52fe0e963c\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.534 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Result was 0 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:195\n> >     2014-11-26 11:09:53.535 5436 DEBUG nova.virt.disk.api\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Checking if we can\n> >     resize image\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk.\n> >     size=1073741824 can_resize_image\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/api.py:192\n> >     2014-11-26 11:09:53.535 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Running cmd\n> >     (subprocess): env LC_ALL=C LANG=C qemu-img info\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk\n> >     execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:161\n> >     2014-11-26 11:09:53.561 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'700\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-9db7630a-7434-43e6-989c-d617e2e339c7\'}\n> >     {\"ports\": [{\"status\": \"DOWN\", \"binding:host_id\": \"nova01\",\n> >     \"allowed_address_pairs\": [], \"extra_dhcp_opts\": [], \"device_owner\":\n> >     \"compute:nova\", \"binding:profile\": {}, \"fixed_ips\": [{\"subnet_id\":\n> >     \"cc4d4225-bf18-4e02-a752-e4dbf381f250\", \"ip_address\":\n> >     \"192.168.200.12\"}], \"id\": \"3cfcfa07-ab38-4ff3-8615-974334e6944e\",\n> >     \"security_groups\": [\"b84f3a98-58b7-4de8-8a78-6e1b56433a8b\"],\n> >     \"device_id\": \"5ac622df-fcbf-4e41-bac9-001ca00d43ac\", \"name\": \"\",\n> >     \"admin_state_up\": true, \"network_id\":\n> >     \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\", \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"binding:vif_details\": {},\n> >     \"binding:vnic_type\": \"normal\", \"binding:vif_type\": \"binding_failed\",\n> >     \"mac_address\": \"fa:16:3e:41:de:fa\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.568 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/floatingips.json?fixed_ip_address=192.168.200.12&port_id=3cfcfa07-ab38-4ff3-8615-974334e6944e\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/floatingips.json?fixed_ip_address=192.168.200.12&port_id=3cfcfa07-ab38-4ff3-8615-974334e6944e\n> >     -X> GET -H \"X-Auth-Token: eac96c62e33d439bb2f4af52fe0e963c\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.571 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Result was 0 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:195\n> >     2014-11-26 11:09:53.572 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Running cmd\n> >     (subprocess): qemu-img resize\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk\n> >     1073741824 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:161\n> >     2014-11-26 11:09:53.596 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'19\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-a80708cf-2528-44fa-b4f0-48d362109cbe\'}\n> >     {\"floatingips\": []}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.602 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/subnets.json?id=cc4d4225-bf18-4e02-a752-e4dbf381f250\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/subnets.json?id=cc4d4225-bf18-4e02-a752-e4dbf381f250\n> >     -X> GET -H \"X-Auth-Token: c63d5bcad5924a7ea8a9eaf2ff0c8156\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.606 5436 DEBUG nova.openstack.common.processutils\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Result was 0 execute\n> >     /usr/lib/python2.7/site-packages/nova/openstack/common/processutils.py:195\n> >     2014-11-26 11:09:53.607 5436 DEBUG nova.virt.disk.api\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Checking if we can\n> >     resize filesystem inside\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk.\n> >     CoW=True is_image_partitionless\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/api.py:206\n> >     2014-11-26 11:09:53.607 5436 DEBUG nova.virt.disk.vfs.api\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Instance for image\n> >     imgfile=/var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk\n> >     imgfmt=qcow2\n> >     partition=None instance_for_image\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/api.py:45\n> >     2014-11-26 11:09:53.607 5436 DEBUG nova.virt.disk.vfs.api\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Using primary VFSGuestFS\n> >     instance_for_image\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/api.py:49\n> >     2014-11-26 11:09:53.607 5436 DEBUG nova.virt.disk.vfs.guestfs\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Setting up appliance for\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk qcow2\n> >     setup /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/guestfs.py:137\n> >     2014-11-26 11:09:53.608 5436 WARNING nova.virt.disk.vfs.guestfs\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Unable to force TCG\n> >     mode, libguestfs too old? \'GuestFS\' object has no attribute\n> >     \'set_backend_settings\'\n> >     2014-11-26 11:09:53.623 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'453\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-c3ccd45f-3029-4af5-9952-6000667e78c3\'}\n> >     {\"subnets\": [{\"name\": \"demo-subnet\", \"enable_dhcp\": true, \"network_id\":\n> >     \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\", \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"dns_nameservers\": [], \"gateway_ip\":\n> >     \"192.168.200.254\", \"ipv6_ra_mode\": null, \"allocation_pools\": [{\"start\":\n> >     \"192.168.200.1\", \"end\": \"192.168.200.253\"}], \"host_routes\": [],\n> >     \"ip_version\": 4, \"ipv6_address_mode\": null, \"cidr\":\n> >     \"192.168.200.0/24 <http://192.168.200.0/24>\",\n> >     \"id\": \"cc4d4225-bf18-4e02-a752-e4dbf381f250\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.624 5436 DEBUG neutronclient.client [-]\n> >     REQ: curl -i\n> >     http://neutron-controller:9696/v2.0/ports.json?network_id=1206629d-045d-4c3a-b83f-f0bf5dbb0add&device_owner=network%3Adhcp\n> >     -X\n> >     <http://neutron-controller:9696/v2.0/ports.json?network_id=1206629d-045d-4c3a-b83f-f0bf5dbb0add&device_owner=network%3Adhcp\n> >     -X> GET -H \"X-Auth-Token: c63d5bcad5924a7ea8a9eaf2ff0c8156\" -H\n> >     \"User-Agent: python-neutronclient\"\n> >      http_log_req\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:140\n> >     2014-11-26 11:09:53.654 5436 DEBUG neutronclient.client [-] RESP:200\n> >     {\'date\': \'Wed, 26 Nov 2014 10:09:56 GMT\', \'content-length\': \'585\',\n> >     \'content-type\': \'application/json; charset=UTF-8\',\n> >     \'x-openstack-request-id\': \'req-1fb5195c-4c2f-421a-912b-77ff4c441e3b\'}\n> >     {\"ports\": [{\"status\": \"DOWN\", \"name\": \"\", \"allowed_address_pairs\": [],\n> >     \"admin_state_up\": true, \"network_id\":\n> >     \"1206629d-045d-4c3a-b83f-f0bf5dbb0add\", \"tenant_id\":\n> >     \"5d3a5bbf404c4db28067929f40ba170e\", \"extra_dhcp_opts\": [],\n> >     \"binding:vnic_type\": \"normal\", \"device_owner\": \"network:dhcp\",\n> >     \"mac_address\": \"fa:16:3e:09:a0:e0\", \"fixed_ips\": [{\"subnet_id\":\n> >     \"cc4d4225-bf18-4e02-a752-e4dbf381f250\", \"ip_address\": \"192.168.200.7\"}],\n> >     \"id\": \"9a654803-c082-4e3f-ba17-05572a51601e\", \"security_groups\": [],\n> >     \"device_id\":\n> >     \"dhcpab855245-c8d0-5774-a10d-facfbf4f3939-1206629d-045d-4c3a-b83f-f0bf5dbb0add\"}]}\n> >      http_log_resp\n> >     /usr/lib/python2.7/site-packages/neutronclient/common/utils.py:149\n> >     2014-11-26 11:09:53.655 5436 DEBUG nova.network.base_api [-] Updating\n> >     cache with info: [VIF({\'profile\': {}, \'ovs_interfaceid\': None,\n> >     \'network\': Network({\'bridge\': None, \'subnets\': [Subnet({\'ips\':\n> >     [FixedIP({\'meta\': {}, \'version\': 4, \'type\': \'fixed\', \'floating_ips\': [],\n> >     \'address\': u\'192.168.200.12\'})], \'version\': 4, \'meta\': {\'dhcp_server\':\n> >     u\'192.168.200.7\'}, \'dns\': [], \'routes\': [], \'cidr\':\n> >     u\'192.168.200.0/24 <http://192.168.200.0/24>\',\n> >     \'gateway\': IP({\'meta\': {}, \'version\': 4, \'type\': \'gateway\', \'address\':\n> >     u\'192.168.200.254\'})})], \'meta\': {\'injected\': False, \'tenant_id\':\n> >     u\'5d3a5bbf404c4db28067929f40ba170e\'}, \'id\':\n> >     u\'1206629d-045d-4c3a-b83f-f0bf5dbb0add\', \'label\': u\'demo-net\'}),\n> >     \'devname\': u\'tap3cfcfa07-ab\', \'vnic_type\': u\'normal\', \'qbh_params\':\n> >     None, \'meta\': {}, \'details\': {}, \'address\': u\'fa:16:3e:41:de:fa\',\n> >     \'active\': False, \'type\': u\'binding_failed\', \'id\':\n> >     u\'3cfcfa07-ab38-4ff3-8615-974334e6944e\', \'qbg_params\': None})]\n> >     update_instance_cache_with_nw_info\n> >     /usr/lib/python2.7/site-packages/nova/network/base_api.py:40\n> >     2014-11-26 11:09:53.671 5436 DEBUG nova.compute.manager [-] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Instance network_info:\n> >     |[VIF({\'profile\': {}, \'ovs_interfaceid\': None, \'network\':\n> >     Network({\'bridge\': None, \'subnets\': [Subnet({\'ips\': [FixedIP({\'meta\':\n> >     {}, \'version\': 4, \'type\': \'fixed\', \'floating_ips\': [], \'address\':\n> >     u\'192.168.200.12\'})], \'version\': 4, \'meta\': {\'dhcp_server\':\n> >     u\'192.168.200.7\'}, \'dns\': [], \'routes\': [], \'cidr\':\n> >     u\'192.168.200.0/24 <http://192.168.200.0/24>\',\n> >     \'gateway\': IP({\'meta\': {}, \'version\': 4, \'type\': \'gateway\', \'address\':\n> >     u\'192.168.200.254\'})})], \'meta\': {\'injected\': False, \'tenant_id\':\n> >     u\'5d3a5bbf404c4db28067929f40ba170e\'}, \'id\':\n> >     u\'1206629d-045d-4c3a-b83f-f0bf5dbb0add\', \'label\': u\'demo-net\'}),\n> >     \'devname\': u\'tap3cfcfa07-ab\', \'vnic_type\': u\'normal\', \'qbh_params\':\n> >     None, \'meta\': {}, \'details\': {}, \'address\': u\'fa:16:3e:41:de:fa\',\n> >     \'active\': False, \'type\': u\'binding_failed\', \'id\':\n> >     u\'3cfcfa07-ab38-4ff3-8615-974334e6944e\', \'qbg_params\': None})]|\n> >     _allocate_network_async\n> >     /usr/lib/python2.7/site-packages/nova/compute/manager.py:1644\n> >     2014-11-26 11:09:53.798 5436 INFO nova.scheduler.client.report [-]\n> >     Compute_service record updated for (\'nova01\', \'os483401.localnet\')\n> >     2014-11-26 11:09:58.215 5436 DEBUG nova.virt.disk.vfs.guestfs\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Mount guest OS image\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk\n> >     partition None setup_os_static\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/guestfs.py:83\n> >     2014-11-26 11:09:58.260 5436 DEBUG nova.virt.disk.vfs.guestfs\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Tearing down appliance\n> >     teardown\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/vfs/guestfs.py:185\n> >     2014-11-26 11:09:58.262 5436 WARNING nova.virt.disk.vfs.guestfs\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Failed to close augeas\n> >     aug_close: do_aug_close: you must call \'aug-init\' first to\n> >     initialize Augeas\n> >     2014-11-26 11:09:58.317 5436 DEBUG nova.virt.disk.api\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Unable to mount image\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk with\n> >     error Error mounting\n> >     /var/lib/nova/instances/5ac622df-fcbf-4e41-bac9-001ca00d43ac/disk with\n> >     libguestfs (mount_options: /dev/sda on / (options: \'\'): mount: /dev/sda\n> >     is write-protected, mounting read-only\n> >     mount: unknown filesystem type \'(null)\'). Cannot resize.\n> >     is_image_partitionless\n> >     /usr/lib/python2.7/site-packages/nova/virt/disk/api.py:218\n> >     2014-11-26 11:09:58.319 5436 DEBUG nova.virt.libvirt.driver\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Start _get_guest_xml\n> >     network_info=[VIF({\'profile\': {}, \'ovs_interfaceid\': None, \'network\':\n> >     Network({\'bridge\': None, \'subnets\': [Subnet({\'ips\': [FixedIP({\'meta\':\n> >     {}, \'version\': 4, \'type\': \'fixed\', \'floating_ips\': [], \'address\':\n> >     u\'192.168.200.12\'})], \'version\': 4, \'meta\': {\'dhcp_server\':\n> >     u\'192.168.200.7\'}, \'dns\': [], \'routes\': [], \'cidr\':\n> >     u\'192.168.200.0/24 <http://192.168.200.0/24>\',\n> >     \'gateway\': IP({\'meta\': {}, \'version\': 4, \'type\': \'gateway\', \'address\':\n> >     u\'192.168.200.254\'})})], \'meta\': {\'injected\': False, \'tenant_id\':\n> >     u\'5d3a5bbf404c4db28067929f40ba170e\'}, \'id\':\n> >     u\'1206629d-045d-4c3a-b83f-f0bf5dbb0add\', \'label\': u\'demo-net\'}),\n> >     \'devname\': u\'tap3cfcfa07-ab\', \'vnic_type\': u\'normal\', \'qbh_params\':\n> >     None, \'meta\': {}, \'details\': {}, \'address\': u\'fa:16:3e:41:de:fa\',\n> >     \'active\': False, \'type\': u\'binding_failed\', \'id\':\n> >     u\'3cfcfa07-ab38-4ff3-8615-974334e6944e\', \'qbg_params\': None})]\n> >     disk_info={\'disk_bus\': \'virtio\', \'cdrom_bus\': \'ide\', \'mapping\': {\'disk\':\n> >     {\'bus\': \'virtio\', \'boot_index\': \'1\', \'type\': \'disk\', \'dev\': u\'vda\'},\n> >     \'root\': {\'bus\': \'virtio\', \'boot_index\': \'1\', \'type\': \'disk\', \'dev\':\n> >     u\'vda\'}}} image_meta={u\'status\': u\'active\', u\'deleted\': False,\n> >     u\'container_format\': u\'bare\', u\'min_ram\': 0, u\'updated_at\':\n> >     u\'2014-11-18T10:30:54.000000\', u\'min_disk\': 0, u\'owner\':\n> >     u\'eded32b718c9481f9e8d4f19185b766c\', u\'is_public\': True, u\'deleted_at\':\n> >     None, u\'properties\': {}, u\'size\': 13200896, u\'name\':\n> >     u\'cirros-0.3.3-x86_64\', u\'checksum\':\n> >     u\'133eae9fb1c98f45894a4e60d8736619\', u\'created_at\':\n> >     u\'2014-11-18T10:30:53.000000\', u\'disk_format\': u\'qcow2\', u\'id\':\n> >     u\'2d7d75c2-17b7-4483-9182-f82295b97088\'} rescue=None\n> >     block_device_info={\'block_device_mapping\': [], \'root_device_name\':\n> >     u\'/dev/vda\', \'ephemerals\': [], \'swap\': None} _get_guest_xml\n> >     /usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py:4147\n> >     2014-11-26 11:09:58.351 5436 DEBUG nova.virt.libvirt.driver\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] CPU mode \'host-model\'\n> >     model \'\' was chosen _get_guest_cpu_model_config\n> >     /usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py:3361\n> >     2014-11-26 11:09:58.351 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Getting desirable\n> >     topologies for flavor\n> >     Flavor(created_at=None,deleted=False,deleted_at=None,disabled=False,ephemeral_gb=0,extra_specs={},flavorid=\'1\',id=2,is_public=True,memory_mb=512,name=\'m1.tiny\',projects=<?>,root_gb=1,rxtx_factor=1.0,swap=0,updated_at=None,vcpu_weight=0,vcpus=1)\n> >     and image_meta {u\'status\': u\'active\', u\'deleted\': False,\n> >     u\'container_format\': u\'bare\', u\'min_ram\': 0, u\'updated_at\':\n> >     u\'2014-11-18T10:30:54.000000\', u\'min_disk\': 0, u\'owner\':\n> >     u\'eded32b718c9481f9e8d4f19185b766c\', u\'is_public\': True, u\'deleted_at\':\n> >     None, u\'properties\': {}, u\'size\': 13200896, u\'name\':\n> >     u\'cirros-0.3.3-x86_64\', u\'checksum\':\n> >     u\'133eae9fb1c98f45894a4e60d8736619\', u\'created_at\':\n> >     u\'2014-11-18T10:30:53.000000\', u\'disk_format\': u\'qcow2\', u\'id\':\n> >     u\'2d7d75c2-17b7-4483-9182-f82295b97088\'} get_desirable_configs\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:501\n> >     2014-11-26 11:09:58.352 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Flavor limits\n> >     65536:65536:65536 get_topology_constraints\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:295\n> >     2014-11-26 11:09:58.352 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Image limits\n> >     65536:65536:65536 get_topology_constraints\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:308\n> >     2014-11-26 11:09:58.353 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Flavor pref -1:-1:-1\n> >     get_topology_constraints\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:331\n> >     2014-11-26 11:09:58.353 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Image pref -1:-1:-1\n> >     get_topology_constraints\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:353\n> >     2014-11-26 11:09:58.353 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Chosen -1:-1:-1 limits\n> >     65536:65536:65536 get_topology_constraints\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:382\n> >     2014-11-26 11:09:58.353 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Build topologies for 1\n> >     vcpu(s) 1:1:1 get_possible_topologies\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:418\n> >     2014-11-26 11:09:58.354 5436 DEBUG nova.virt.hardware\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] Got 1 possible\n> >     topologies get_possible_topologies\n> >     /usr/lib/python2.7/site-packages/nova/virt/hardware.py:441\n> >     2014-11-26 11:09:58.357 5436 DEBUG nova.virt.libvirt.vif\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] vif_type=binding_failed\n> >     instance=Instance(access_ip_v4=None,access_ip_v6=None,architecture=None,auto_disk_config=True,availability_zone=\'nova\',cell_name=None,cleaned=False,config_drive=\'\',created_at=2014-11-26T10:09:55Z,default_ephemeral_device=None,default_swap_device=None,deleted=False,deleted_at=None,disable_terminate=False,display_description=\'cirros-test-1\',display_name=\'cirros-test-1\',ephemeral_gb=0,ephemeral_key_uuid=None,fault=<?>,host=\'nova01\',hostname=\'cirros-test-1\',id=10,image_ref=\'2d7d75c2-17b7-4483-9182-f82295b97088\',info_cache=InstanceInfoCache,instance_type_id=2,kernel_id=\'\',key_data=None,key_name=None,launch_index=0,launched_at=None,launched_on=\'nova01\',locked=False,locked_by=None,memory_mb=512,metadata={},node=\'os483401.localnet\',numa_topology=None,os_type=None,pci_devices=<?>,power_state=0,progress=0,project_id=\'5d3a5bbf404c4db28067929f40ba170e\',ramdisk_id=\'\',reservation_id=\'r-yngmwn2d\',root_device_name=\'/dev/vda\',root_gb=1,scheduled_at=None,security_groups=SecurityGroupList,shutdown\n> _termi\n> >     nate=False,system_metadata={image_base_image_ref=\'2d7d75c2-17b7-4483-9182-f82295b97088\',image_container_format=\'bare\',image_disk_format=\'qcow2\',image_min_disk=\'1\',image_min_ram=\'0\',instance_type_ephemeral_gb=\'0\',instance_type_flavorid=\'1\',instance_type_id=\'2\',instance_type_memory_mb=\'512\',instance_type_name=\'m1.tiny\',instance_type_root_gb=\'1\',instance_type_rxtx_factor=\'1.0\',instance_type_swap=\'0\',instance_type_vcpu_weight=None,instance_type_vcpus=\'1\',network_allocated=\'True\'},task_state=\'spawning\',terminated_at=None,updated_at=2014-11-26T10:09:56Z,user_data=None,user_id=\'0c6d9637e6d24fc78ee3bce2ceedcfe7\',uuid=5ac622df-fcbf-4e41-bac9-001ca00d43ac,vcpus=1,vm_mode=None,vm_state=\'building\')\n> >     vif=VIF({\'profile\': {}, \'ovs_interfaceid\': None, \'network\':\n> >     Network({\'bridge\': None, \'subnets\': [Subnet({\'ips\': [FixedIP({\'meta\':\n> >     {}, \'version\': 4, \'type\': \'fixed\', \'floating_ips\': [], \'address\':\n> >     u\'192.168.200.12\'})], \'version\': 4, \'meta\': {\'dhcp_server\':\n> >     u\'192.168.200.7\'}, \'dns\': [], \'routes\': [], \'cidr\':\n> >     u\'192.168.200.0/24 <http://192.168.200.0/24>\',\n> >     \'gateway\': IP({\'meta\': {}, \'version\': 4, \'type\': \'gateway\', \'address\':\n> >     u\'192.168.200.254\'})})], \'meta\': {\'injected\': False, \'tenant_id\':\n> >     u\'5d3a5bbf404c4db28067929f40ba170e\'}, \'id\':\n> >     u\'1206629d-045d-4c3a-b83f-f0bf5dbb0add\', \'label\': u\'demo-net\'}),\n> >     \'devname\': u\'tap3cfcfa07-ab\', \'vnic_type\': u\'normal\', \'qbh_params\':\n> >     None, \'meta\': {}, \'details\': {}, \'address\': u\'fa:16:3e:41:de:fa\',\n> >     \'active\': False, \'type\': u\'binding_failed\', \'id\':\n> >     u\'3cfcfa07-ab38-4ff3-8615-974334e6944e\', \'qbg_params\': None})\n> >     virt_typeqemu get_config\n> >     /usr/lib/python2.7/site-packages/nova/virt/libvirt/vif.py:342\n> >     2014-11-26 11:09:58.359 5436 ERROR nova.compute.manager\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Instance failed to spawn\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Traceback (most recent call last):\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", line 2231,\n> >     in _build_resources\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]     yield resources\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/compute/manager.py\", line 2101,\n> >     in _build_and_run_instance\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]\n> >     block_device_info=block_device_info)\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py\", line\n> >     2619, in spawn\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]     write_to_disk=True)\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py\", line\n> >     4150, in _get_guest_xml\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]     context)\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py\", line\n> >     3936, in _get_guest_config\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]     flavor,\n> >     CONF.libvirt.virt_type)\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]   File\n> >     \"/usr/lib/python2.7/site-packages/nova/virt/libvirt/vif.py\", line 352,\n> >     in get_config\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]     _(\"Unexpected vif_type=%s\") %\n> >     vif_type)\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] NovaException: Unexpected\n> >     vif_type=binding_failed\n> >     2014-11-26 11:09:58.359 5436 TRACE nova.compute.manager [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac]\n> >     2014-11-26 11:09:58.360 5436 AUDIT nova.compute.manager\n> >     [req-ab961686-99ab-4112-8755-a9f2326b9a5b None] [instance:\n> >     5ac622df-fcbf-4e41-bac9-001ca00d43ac] Terminating instance\n> >     2014-11-26 11:09:58.365 5436 WARNING nova.virt.libvirt.driver [-]\n> >     [instance: 5ac622df-fcbf-4e41-bac9-001ca00d43ac] During wait destroy,\n> >     instance disappeared.\n> > \n> > \n> > \n> >     Any ideas what\'s wrong or where I have to investigate further? What more\n> >     info do you need to help?\n> > \n> >     Thanks in advance,\n> > \n> >             Uwe\n> > \n> >     _______________________________________________\n> >     Mailing list:\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >     Post to     : openstack at lists.openstack.org\n> >     <mailto:openstack at lists.openstack.org>\n> >     Unsubscribe :\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<5475D21F.5030507@gmail.com>',NULL),('<1417012123.3031.87.camel@linode2.nicolast.be>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 15:28:43',3600,'2014-11-26 14:28:43',NULL,'[openstack-dev] [nova] Proposal new hacking rules','On Wed, 2014-11-26 at 08:54 -0500, Jay Pipes wrote:\n> On 11/26/2014 06:20 AM, Nicolas Trangez wrote:\n> > On Mon, 2014-11-24 at 13:19 -0500, Jay Pipes wrote:\n> >> I think pointing out that the default failure\n> >> message for testtools.TestCase.assertEqual() uses the terms\n> >> \"reference\"\n> >> (expected) and \"actual\" is a reason why reviewers *should* ask patch\n> >> submitters to use (expected, actual) ordering.\n> >\n> > Is there any reason for this specific ordering? Not sure about others,\n> > but I tend to write equality comparisons like this\n> >\n> >      if var == 1:\n> >\n> > instead of\n> >\n> >      if 1 == var:\n> >\n> > (although I\'ve seen the latter in C code before).\n> >\n> > This gives rise to\n> >\n> >      assert var == 1\n> >\n> > or, moving into `unittest` domain\n> >\n> >      assertEqual(var, 1)\n> >\n> > reading it as \'Assert `var` equals 1\', which makes me wonder why the\n> > `assertEqual` API is defined the other way around (unlike how I\'d write\n> > any other equality check).\n> \n> It\'s not about an equality condition.\n> \n> It\'s about the message that is produced by \n> testtools.TestCase.assertEqual(), and the helpfulness of that message \n> when the order of the arguments is reversed.\n\nI\'m aware of that. I was just wondering whether there\'s a particular\nreason the ordering (and as a result of that the error message) was\nchosen as it is.\n\nI\'d rather design the API as `assertEqual(value, expected)`, and let the\nmessage indeed say \'Expected ..., but got ...\' (and using the argument\nvalues accordingly).\n\nNicolas\n\n\n\n','<5475DB9B.5060802@gmail.com>',NULL),('<1417013485.4483.30.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 15:51:25',3600,'2014-11-26 14:51:25',NULL,'[openstack-dev] [devstack] environment variables in	local.conf\n post-config section','That\'s it. Thanks!\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-11-26 at 15:10 +0100, jordan pittier wrote:\n> Hi,\n> It should work with your current local.conf. You may be facing this bug : https://bugs.launchpad.net/devstack/+bug/1386413\n> \n> Jordan\n> \n> ----- Original Message -----\n> From: \"Andreas Scheuring\" <scheuran at linux.vnet.ibm.com>\n> To: \"openstack-dev\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, 26 November, 2014 2:04:57 PM\n> Subject: [openstack-dev] [devstack] environment variables in local.conf	post-config section\n> \n> Hi together, \n> is there a way to use Environment variables in the local.conf\n> post-config section?\n> \n> On my system (stable/juno devstack) not the content of the variable, but\n> the variable name itself is being inserted into the config file.\n> \n> \n> So e.g. \n> [[post-config|$NOVA_CONF]]\n> [DEFAULT]\n> vncserver_proxyclient_address=$HOST_IP_MGMT\n> \n> results in nova.conf as:\n> vncserver_proxyclient_address = $HOST_IP_MGMT\n> \n> \n> \n> Thanks\n> \n\n\n\n','<854804218.2199452.1417011006279.JavaMail.root@mailnew.scality.com>',NULL),('<1417014372.4483.36.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-26 16:06:12',3600,'2014-11-26 15:06:12',NULL,'[openstack-dev] [Devstack] Juno Backport for Bug \"Revert Single\n quote iniset argument in merge_config_file\"','Hi, \ndo you think we could backport this bug to the devstack stable/juno\nrelease? \nhttps://review.openstack.org/#/c/131334/\n\nThis bug prohibits people to use the local.conf from icehouse, when they\ntake use of variables for defining configuration values\n\n\n\nAn example. The local.conf looks like this:\n> [[post-config|$NOVA_CONF]]\n> [DEFAULT]\n> vncserver_proxyclient_address=$HOST_IP_MGMT\n> \n\nWith stable/juno this results in nova.conf as:\n> vncserver_proxyclient_address = $HOST_IP_MGMT\n\n\nThe above mentioned bug solves this problem.\n\nDo you think it\'s worthwile backporting it?\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1417015862.4483.42.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-26 16:31:02',3600,'2014-11-26 15:31:02',NULL,'[Openstack] Cannot launch instance: No valid host was found:\n Port failed to bind on host','Hi Uwe, \nthis is how my config for the ovs agent looks like. This one is working\nbut some of the parameters might be duplicates to the default or not\neven required. I still have to figure this out. \nBut at least it is working ;)\n\n\n\nCompute Node:\n\n[ovs]\nenable_tunneling = True\ntenant_network_type = gre\ntunnel_id_ranges = 1:1000\ntunnel_type = gre\nlocal_ip = 192.168.1.190\n\n\n[agent]\ntunnel_types = gre\nroot_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\n\n\nNework Node:\n\n[ml2]\ntenant_network_types = gre\ntype_drivers = local,flat,vlan,gre,vxlan\nmechanism_drivers = openvswitch,linuxbridge\n\n[ml2_type_gre]\ntunnel_id_ranges = 1:1000\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\n[database]\nconnection = mysql://root:XXX at 127.0.0.1/neutron_ml2?charset=utf8\n\n[ovs]\nbridge_mappings = phys-ex:br-ext\ntunnel_id_ranges = 1001:2000\ntenant_network_type = gre\ntunnel_type = gre\nenable_tunneling = True  \nlocal_ip = 192.168.1.202\n\n[agent]\ntunnel_types = gre\nroot_helper =\nsudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n\n\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-11-26 at 14:59 +0100, Uwe Sauter wrote:\n> Hi Andreas,\n> \n> on each host /etc/neutron/plugin.ini is a symlink to\n> /etc/neutron/plugins/ml2/ml2_conf.ini.\n> \n> Content on the controller node:\n> \n> [ml2]\n> mechanism_drivers = openvswitch\n> tenant_network_types = gre\n> type_drivers = gre,vlan\n> \n> [ml2_type_flat]\n> \n> [ml2_type_vlan]\n> network_vlan_ranges = external:202:202\n> \n> [ml2_type_gre]\n> tunnel_id_ranges = 1:1000\n> \n> [ml2_type_vxlan]\n> \n> [securitygroup]\n> enable_ipset = True\n> enable_security_group = True\n> firewall_driver =\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> \n> [database]\n> connection = mysql://neutron:XXXXXX at db/neutron\n> \n> \n> Content on the network node:\n> \n> [ml2]\n> mechanism_drivers = openvswitch\n> tenant_network_types = gre\n> type_drivers = gre,vlan\n> \n> [ml2_type_flat]\n> \n> [ml2_type_vlan]\n> network_vlan_ranges = external:202:202\n> \n> [ml2_type_gre]\n> tunnel_id_ranges = 1:1000\n> \n> [ml2_type_vxlan]\n> \n> [securitygroup]\n> enable_ipset = True\n> enable_security_group = True\n> firewall_driver =\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> \n> [ovs]\n> bridge_mappings = external:br-ex\n> enable_tunneling = True\n> local_ip = 172.20.10.3\n> tunnel_types = gre\n> \n> [database]\n> connection = mysql://neutron:XXXXXX at db/neutron\n> \n> \n> Content on the compute nodes:\n> \n> [ml2]\n> mechanism_drivers = openvswitch\n> tenant_network_types = gre\n> type_drivers = gre,vlan\n> \n> [ml2_type_flat]\n> \n> [ml2_type_vlan]\n> network_vlan_ranges = external:202:202\n> \n> [ml2_type_gre]\n> tunnel_id_ranges = 1:1000\n> \n> [ml2_type_vxlan]\n> \n> [securitygroup]\n> enable_ipset = True\n> enable_security_group = True\n> firewall_driver =\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> \n> [ovs]\n> enable_tunneling = True\n> local_ip = 172.20.10.4     #this is different for the second node\n> tunnel_types = gre\n> \n> [database]\n> connection = mysql://neutron:XXXXXX at db/neutron\n> \n> \n> Regards,\n> \n> 	Uwe\n> \n> \n> \n> \n> Am 26.11.2014 um 14:35 schrieb Andreas Scheuring:\n> > Hi Uwe, \n> > could you please provide the content of your /etc/neutron/plugin.ini of\n> > the compute and the network node?\n> > \n> > \n> > \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n\n','<5475DCDA.9000205@gmail.com>',NULL),('<1417078047.4491.2.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-27 09:47:27',3600,'2014-11-27 08:47:27',NULL,'[Openstack] Cannot launch instance: No valid host was found:\n Port failed to bind on host','Hi Uwe, \nthis config is from a icehouse system. Maybe things have changed since\nthen. And as mentioned before, I\'m not even sure if all parameters are\nrequired... still have to figure this out. This is just how I got it\nrunning. So I cannot give you a certain reason ;)\n\nThanks\n\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Wed, 2014-11-26 at 17:32 +0100, Uwe Sauter wrote:\n> Hi Andreas,\n> \n> can you elaborate why you have [agent] sections in your config. I read\n> somewhere a few days ago, that these aren\'t necessary with Juno and they\n> are not mentioned in the Juno docs.\n> \n> Meanwhile I found out that neutron-openvswitch-agent.service crashed on\n> the network node (see my mail from a few minutes back).\n> \n> Regards,\n> \n> 	Uwe\n> \n> \n> \n> Am 26.11.2014 um 16:31 schrieb Andreas Scheuring:\n> > Hi Uwe, \n> > this is how my config for the ovs agent looks like. This one is working\n> > but some of the parameters might be duplicates to the default or not\n> > even required. I still have to figure this out. \n> > But at least it is working ;)\n> > \n> > \n> > \n> > Compute Node:\n> > \n> > [ovs]\n> > enable_tunneling = True\n> > tenant_network_type = gre\n> > tunnel_id_ranges = 1:1000\n> > tunnel_type = gre\n> > local_ip = 192.168.1.190\n> > \n> > \n> > [agent]\n> > tunnel_types = gre\n> > root_helper = sudo /usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n> > \n> > \n> > [securitygroup]\n> > firewall_driver =\n> > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> > \n> > \n> > \n> > Nework Node:\n> > \n> > [ml2]\n> > tenant_network_types = gre\n> > type_drivers = local,flat,vlan,gre,vxlan\n> > mechanism_drivers = openvswitch,linuxbridge\n> > \n> > [ml2_type_gre]\n> > tunnel_id_ranges = 1:1000\n> > [securitygroup]\n> > firewall_driver =\n> > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> > \n> > [database]\n> > connection = mysql://root:XXX at 127.0.0.1/neutron_ml2?charset=utf8\n> > \n> > [ovs]\n> > bridge_mappings = phys-ex:br-ext\n> > tunnel_id_ranges = 1001:2000\n> > tenant_network_type = gre\n> > tunnel_type = gre\n> > enable_tunneling = True  \n> > local_ip = 192.168.1.202\n> > \n> > [agent]\n> > tunnel_types = gre\n> > root_helper =\n> > sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n> > \n> > \n> > \n> > \n> > \n> > \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n\n','<54760090.6050200@gmail.com>',NULL),('<1417174662.4480.6.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-28 12:37:42',3600,'2014-11-28 11:37:42',NULL,'[Openstack] Cannot launch instance: No valid host was found:\n Port failed to bind on host','Hi Uwe, me again.\nI just applied the gre on my new stable/juno system. This is the minimal\nset of parameters that was required (also using ml2pop).\n\n\ncontroller:\n[[post-config|/$Q_PLUGIN_CONF_FILE]]\n[ml2]\ntenant_network_types = gre\nmechanism_drivers = openvswitch,l2population\n\n[ml2_type_gre]\ntunnel_id_ranges = 1:1000\n\n[ovs]\nlocal_ip = $HOST_IP_DATA\nenable_tunneling=True\nbridge_mappings = phys-ex:br-ext\n\n[agent]\ntunnel_types = gre\nl2_population = True\nroot_helper =\nsudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n\ncompute:\n[[post-config|/$Q_PLUGIN_CONF_FILE]]\n[ovs]\nlocal_ip = $HOST_IP_DATA\nenable_tunneling=True\n\n[agent]\ntunnel_types = gre\nl2_population = True\nroot_helper =\nsudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n\n\n\nI also had a look at openvswitch agent code. These are the\nvariables/sections that are used:\n\n\nbridge_mappings = q_utils.parse_mappings(config.OVS.bridge_mappings)\ninteg_br=config.OVS.integration_bridge,\ntun_br=config.OVS.tunnel_bridge,\nlocal_ip=config.OVS.local_ip,\nroot_helper=config.AGENT.root_helper,\npolling_interval=config.AGENT.polling_interval,\nminimize_polling=config.AGENT.minimize_polling,\ntunnel_types=config.AGENT.tunnel_types,\nveth_mtu=config.AGENT.veth_mtu,\nenable_distributed_routing=config.AGENT.enable_distributed_routing,\nl2_population=config.AGENT.l2_population,\narp_responder=config.AGENT.arp_responder,\nuse_veth_interconnection=config.OVS.use_veth_interconnection,\n\n--> so the agent section still seems to be valid. Maybe there\'s shortcut\nin the code that also the ovs section is treated as agent section or\nvice versa. But that\'s just a guess. Also haven\'t tried it out so far\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Thu, 2014-11-27 at 09:47 +0100, Andreas Scheuring wrote:\n> Hi Uwe, \n> this config is from a icehouse system. Maybe things have changed since\n> then. And as mentioned before, I\'m not even sure if all parameters are\n> required... still have to figure this out. This is just how I got it\n> running. So I cannot give you a certain reason ;)\n> \n> Thanks\n> \n> \n> \n\n\n\n','<1417078047.4491.2.camel@oc5515017671.ibm.com>',NULL),('<1417184216.4480.11.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-28 15:16:56',3600,'2014-11-28 14:16:56',NULL,'[Openstack] Cannot launch instance: No valid host was found:\n Port failed to bind on host','Maybe one thing I to add, This is a devstack post-config. So what was\ntaken in addition from the default config is: \n\n[ml2] \ntype_drivers = flat,gre\n\n\n[securitygroup]\nfirewall_driver =\nneutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n\n\n\nAnd I predefined the bridge br-ext.\n\n\nGood Luck and enjoy your weekend!\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Fri, 2014-11-28 at 14:17 +0100, Uwe Sauter wrote:\n> Hi Andreas,\n> \n> it seems I screwed up my installation (not only Neutron). I\'m in the\n> progress of resetting everything to the not-yet-configured state.\n> \n> I\'ll try to adapt your config example and will report back once I come\n> to that point again.\n> \n> Thanks again and have a nice weekend,\n> \n> 	Uwe\n> \n> \n> Am 28.11.2014 um 12:37 schrieb Andreas Scheuring:\n> > Hi Uwe, me again.\n> > I just applied the gre on my new stable/juno system. This is the minimal\n> > set of parameters that was required (also using ml2pop).\n> > \n> > \n> > controller:\n> > [[post-config|/$Q_PLUGIN_CONF_FILE]]\n> > [ml2]\n> > tenant_network_types = gre\n> > mechanism_drivers = openvswitch,l2population\n> > \n> > [ml2_type_gre]\n> > tunnel_id_ranges = 1:1000\n> > \n> > [ovs]\n> > local_ip = $HOST_IP_DATA\n> > enable_tunneling=True\n> > bridge_mappings = phys-ex:br-ext\n> > \n> > [agent]\n> > tunnel_types = gre\n> > l2_population = True\n> > root_helper =\n> > sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n> > \n> > \n> > \n> > compute:\n> > [[post-config|/$Q_PLUGIN_CONF_FILE]]\n> > [ovs]\n> > local_ip = $HOST_IP_DATA\n> > enable_tunneling=True\n> > \n> > [agent]\n> > tunnel_types = gre\n> > l2_population = True\n> > root_helper =\n> > sudo /usr/local/bin/neutron-rootwrap /etc/neutron/rootwrap.conf\n> > \n> > \n> > \n> > I also had a look at openvswitch agent code. These are the\n> > variables/sections that are used:\n> > \n> > \n> > bridge_mappings = q_utils.parse_mappings(config.OVS.bridge_mappings)\n> > integ_br=config.OVS.integration_bridge,\n> > tun_br=config.OVS.tunnel_bridge,\n> > local_ip=config.OVS.local_ip,\n> > root_helper=config.AGENT.root_helper,\n> > polling_interval=config.AGENT.polling_interval,\n> > minimize_polling=config.AGENT.minimize_polling,\n> > tunnel_types=config.AGENT.tunnel_types,\n> > veth_mtu=config.AGENT.veth_mtu,\n> > enable_distributed_routing=config.AGENT.enable_distributed_routing,\n> > l2_population=config.AGENT.l2_population,\n> > arp_responder=config.AGENT.arp_responder,\n> > use_veth_interconnection=config.OVS.use_veth_interconnection,\n> > \n> > --> so the agent section still seems to be valid. Maybe there\'s shortcut\n> > in the code that also the ovs section is treated as agent section or\n> > vice versa. But that\'s just a guess. Also haven\'t tried it out so far\n> > \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n\n','<547875FF.7050900@gmail.com>',NULL),('<1417398680.3087.1.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 11:51:20',36000,'2014-12-01 01:51:20',NULL,'[openstack-dev] [keystone][oslo] Handling contexts and policy\n enforcement in services','TL;DR: I think we can handle most of oslo.context with some additions to\nauth_token middleware and simplify policy enforcement (from a service\nperspective) at the same time.\n\nThere is currently a push to release oslo.context as a\nlibrary, for reference:\nhttps://github.com/openstack/oslo.context/blob/master/oslo_context/context.py\n\nWhilst I love the intent to standardize this\nfunctionality I think that many of the requirements in there\nare incorrect and don\'t apply to all services. It is my\nunderstanding for example that read_only, show_deleted are\nessentially nova requirements, and the use of is_admin needs\nto be killed off, not standardized.\n\nCurrently each service builds a context based on headers\nmade available from auth_token middleware and some\nadditional interpretations based on that user\nauthentication. Each service does this slightly differently\nbased on its needs/when it copied it from nova.\n\nI propose that auth_token middleware essentially handle the\ncreation and management of an authentication object that\nwill be passed and used by all services. This will\nstandardize so much of the oslo.context library that I\'m not\nsure it will be still needed. I bring this up now as I am\nwanting to push this way and don\'t want to change things\nafter everyone has adopted oslo.context.\n\nThe current release of auth_token middleware creates and\npasses to services (via env[\'keystone.token_auth\']) an auth\nplugin that can be passed to clients to use the current user\nauthentication. My intention here is to expand that object\nto expose all of the authentication information required for\nthe services to operate.\n\nThere are two components to context that I can see:\n\n - The current authentication information that is retrieved\n   from auth_token middleware.\n - service specific context added based on that user\n   information eg read_only, show_deleted, is_admin,\n   resource_id\n\nRegarding the first point of current authentication there\nare three places I can see this used:\n\n - communicating with other services as that user\n - associating resources with a user/project\n - policy enforcement\n\nAddressing each of the \'current authentication\' needs:\n\n - As mentioned for service to service communication\n   auth_token middleware already provides an auth_plugin\n   that can be used with (at this point most) of the\n   clients. This greatly simplifies reusing an existing\n   token and correctly using the service catalog as each\n   client would do this differently. In future this plugin\n   will be extended to provide support for concepts such as\n   filling in the X-Service-Token [1] on behalf of the\n   service, managing the request id, and generally\n   standardizing service->service communication without\n   requiring explicit support from every project and client.\n\n - Given that this authentication plugin is built within\n   auth_token middleware it is a fairly trivial step to\n   provide public properties on this object to give access\n   to the current user_id, project_id and other relevant\n   authentication data that the services can access. This is\n   fairly well handled today but it means it is done without\n   the service having to fetch all these objects from\n   headers.\n\n - With upcoming changes to policy to handle features such\n   as the X-Service-Token the existing context will need to\n   gain a bunch of new entries. With the keystone team\n   looking to wrap policy enforcement into its own\n   standalone library it makes more sense to provide this\n   authentication object directly to policy enforcement.\n   This will allow the keystone team to manipulate policy\n   data from both auth_token and the enforcement side,\n   letting us introduce new features to policy transparent\n   to the services. It will also standardize the naming of\n   variables within these policy files.\n\nWhat is left for a context object after this is managing\nserialization and deserialization of this auth object and\nany additional fields (read_only etc) that are generally\ncalculated at context creation time. This would be a very\nsmall library.\n\nThere are still a number of steps to getting there:\n\n - Adding enough data to the existing authentication plugin\n   to allow policy enforcement and general usage.\n - Making the authentication object serializable for\n   transmitting between services.\n - Extracting policy enforcement into a library.\n\nHowever I think that this approach brings enough benefits to\nhold off on releasing and standardizing the use of the\ncurrent context objects.\n\nI\'d love to hear everyone thoughts on this, and where it\nwould fall down. I see there could be some issues with how\nthe context would fit into nova\'s versioned objects for\nexample - but I think this would be the same issues that an\noslo.context library would face anyway.\n\nJamie\n\n\n[1] This is where service->service communication includes\nthe service token as well as the user token to allow smarter\npolicy and resource access. For example, a user can\'t access\ncertain neutron functions directly however it should be\nallowed when nova calls neutron on behalf of a user, or an\nobject that a service made on behalf of a user can only be\ndeleted when the service makes the request on behalf of that\nuser.\n\n\n\n\n',NULL,NULL),('<1417462918.209.1368166753639.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-10 06:19:13',0,'2013-05-10 06:19:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly-centos6 #10','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/10/changes>\n\nChanges:\n\n[Alan Pevec] Bump stable/grizzly next version to 2013.1.2\n\n------------------------------------------\n[...truncated 1159 lines...]\nTestStoreImage\n    test_image_delayed_delete                                    OK    0.00\n    test_image_delete                                            OK    0.00\n    test_image_get_data                                          OK    0.00\n    test_image_set_data                                          OK    0.00\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/functional/test_bin_glance_control.py\",> line 192, in test_bouncing\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.77 secs:\n    26.48    TestScrubber.test_scrubber_app\n    20.86    TestScrubber.test_delayed_delete\n    15.03    TestRootApi.test_version_configurations\n    14.83    TestGlanceControl.test_reload\n    14.57    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1102 tests in 616.994s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.centos6.10\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.31\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.fMShhzwO58\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/10\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/10/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1417464757-sup-2646@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 12:19:16',-28800,'2014-12-01 20:19:16',NULL,'[openstack-dev] [Heat] Convergence proof-of-concept showdown','Excerpts from Anant Patil\'s message of 2014-11-30 23:02:29 -0800:\n> On 27-Nov-14 18:03, Murugan, Visnusaran wrote:\n> > Hi Zane,\n> > \n> >  \n> > \n> > At this stage our implementation (as mentioned in wiki\n> > <https://wiki.openstack.org/wiki/Heat/ConvergenceDesign>) achieves your\n> > design goals.\n> > \n> >  \n> > \n> > 1.       In case of a parallel update, our implementation adjusts graph\n> > according to new template and waits for dispatched resource tasks to\n> > complete.\n> > \n> > 2.       Reason for basing our PoC on Heat code:\n> > \n> > a.       To solve contention processing parent resource by all dependent\n> > resources in parallel.\n> > \n> > b.      To avoid porting issue from PoC to HeatBase. (just to be aware\n> > of potential issues asap)\n> > \n> > 3.       Resource timeout would be helpful, but I guess its resource\n> > specific and has to come from template and default values from plugins.\n> > \n> > 4.       We see resource notification aggregation and processing next\n> > level of resources without contention and with minimal DB usage as the\n> > problem area. We are working on the following approaches in *parallel.*\n> > \n> > a.       Use a Queue per stack to serialize notification.\n> > \n> > b.      Get parent ProcessLog (ResourceID, EngineID) and initiate\n> > convergence upon first child notification. Subsequent children who fail\n> > to get parent resource lock will directly send message to waiting parent\n> > task (topic=stack_id.parent_resource_id)\n> > \n> > Based on performance/feedback we can select either or a mashed version.\n> > \n> >  \n> > \n> > Advantages:\n> > \n> > 1.       Failed Resource tasks can be re-initiated after ProcessLog\n> > table lookup.\n> > \n> > 2.       One worker == one resource.\n> > \n> > 3.       Supports concurrent updates\n> > \n> > 4.       Delete == update with empty stack\n> > \n> > 5.       Rollback == update to previous know good/completed stack.\n> > \n> >  \n> > \n> > Disadvantages:\n> > \n> > 1.       Still holds stackLock (WIP to remove with ProcessLog)\n> > \n> >  \n> > \n> > Completely understand your concern on reviewing our code, since commits\n> > are numerous and there is change of course at places.  Our start commit\n> > is [c1b3eb22f7ab6ea60b095f88982247dd249139bf] though this might not help J\n> > \n> >  \n> > \n> > Your Thoughts.\n> > \n> >  \n> > \n> > Happy Thanksgiving.\n> > \n> > Vishnu.\n> > \n> >  \n> > \n> > *From:*Angus Salkeld [mailto:asalkeld at mirantis.com]\n> > *Sent:* Thursday, November 27, 2014 9:46 AM\n> > *To:* OpenStack Development Mailing List (not for usage questions)\n> > *Subject:* Re: [openstack-dev] [Heat] Convergence proof-of-concept showdown\n> > \n> >  \n> > \n> > On Thu, Nov 27, 2014 at 12:20 PM, Zane Bitter <zbitter at redhat.com\n> > <mailto:zbitter at redhat.com>> wrote:\n> > \n> >     A bunch of us have spent the last few weeks working independently on\n> >     proof of concept designs for the convergence architecture. I think\n> >     those efforts have now reached a sufficient level of maturity that\n> >     we should start working together on synthesising them into a plan\n> >     that everyone can forge ahead with. As a starting point I\'m going to\n> >     summarise my take on the three efforts; hopefully the authors of the\n> >     other two will weigh in to give us their perspective.\n> > \n> > \n> >     Zane\'s Proposal\n> >     ===============\n> > \n> >     https://github.com/zaneb/heat-convergence-prototype/tree/distributed-graph\n> > \n> >     I implemented this as a simulator of the algorithm rather than using\n> >     the Heat codebase itself in order to be able to iterate rapidly on\n> >     the design, and indeed I have changed my mind many, many times in\n> >     the process of implementing it. Its notable departure from a\n> >     realistic simulation is that it runs only one operation at a time -\n> >     essentially giving up the ability to detect race conditions in\n> >     exchange for a completely deterministic test framework. You just\n> >     have to imagine where the locks need to be. Incidentally, the test\n> >     framework is designed so that it can easily be ported to the actual\n> >     Heat code base as functional tests so that the same scenarios could\n> >     be used without modification, allowing us to have confidence that\n> >     the eventual implementation is a faithful replication of the\n> >     simulation (which can be rapidly experimented on, adjusted and\n> >     tested when we inevitably run into implementation issues).\n> > \n> >     This is a complete implementation of Phase 1 (i.e. using existing\n> >     resource plugins), including update-during-update, resource\n> >     clean-up, replace on update and rollback; with tests.\n> > \n> >     Some of the design goals which were successfully incorporated:\n> >     - Minimise changes to Heat (it\'s essentially a distributed version\n> >     of the existing algorithm), and in particular to the database\n> >     - Work with the existing plugin API\n> >     - Limit total DB access for Resource/Stack to O(n) in the number of\n> >     resources\n> >     - Limit overall DB access to O(m) in the number of edges\n> >     - Limit lock contention to only those operations actually contending\n> >     (i.e. no global locks)\n> >     - Each worker task deals with only one resource\n> >     - Only read resource attributes once\n> > \n> > \n> >     Open questions:\n> >     - What do we do when we encounter a resource that is in progress\n> >     from a previous update while doing a subsequent update? Obviously we\n> >     don\'t want to interrupt it, as it will likely be left in an unknown\n> >     state. Making a replacement is one obvious answer, but in many cases\n> >     there could be serious down-sides to that. How long should we wait\n> >     before trying it? What if it\'s still in progress because the engine\n> >     processing the resource already died?\n> > \n> >  \n> > \n> > Also, how do we implement resource level timeouts in general?\n> > \n> >  \n> > \n> > \n> >     Micha?\'s Proposal\n> >     =================\n> > \n> >     https://github.com/inc0/heat-convergence-prototype/tree/iterative\n> > \n> >     Note that a version modified by me to use the same test scenario\n> >     format (but not the same scenarios) is here:\n> > \n> >     https://github.com/zaneb/heat-convergence-prototype/tree/iterative-adapted\n> > \n> >     This is based on my simulation framework after a fashion, but with\n> >     everything implemented synchronously and a lot of handwaving about\n> >     how the actual implementation could be distributed. The central\n> >     premise is that at each step of the algorithm, the entire graph is\n> >     examined for tasks that can be performed next, and those are then\n> >     started. Once all are complete (it\'s synchronous, remember), the\n> >     next step is run. Keen observers will be asking how we know when it\n> >     is time to run the next step in a distributed version of this\n> >     algorithm, where it will be run and what to do about resources that\n> >     are in an intermediate state at that time. All of these questions\n> >     remain unanswered.\n> > \n> >  \n> > \n> > Yes, I was struggling to figure out how it could manage an IN_PROGRESS\n> > state as it\'s stateless. So you end up treading on the other action\'s toes.\n> > \n> > Assuming we use the resource\'s state (IN_PROGRESS) you could get around\n> > that. Then you kick off a converge when ever an action completes (if\n> > there is nothing new to be\n> > \n> > done then do nothing).\n> > \n> >  \n> > \n> > \n> >     A non-exhaustive list of concerns I have:\n> >     - Replace on update is not implemented yet\n> >     - AFAIK rollback is not implemented yet\n> >     - The simulation doesn\'t actually implement the proposed architecture\n> >     - This approach is punishingly heavy on the database - O(n^2) or worse\n> > \n> >  \n> > \n> > Yes, re-reading the state of all resources when ever run a new converge\n> > is worrying, but I think Michal had some ideas to minimize this.\n> > \n> >  \n> > \n> >     - A lot of phase 2 is mixed in with phase 1 here, making it\n> >     difficult to evaluate which changes need to be made first and\n> >     whether this approach works with existing plugins\n> >     - The code is not really based on how Heat works at the moment, so\n> >     there would be either a major redesign required or lots of radical\n> >     changes in Heat or both\n> > \n> >     I think there\'s a fair chance that given another 3-4 weeks to work\n> >     on this, all of these issues and others could probably be resolved.\n> >     The question for me at this point is not so much \"if\" but \"why\".\n> > \n> >     Micha? believes that this approach will make Phase 2 easier to\n> >     implement, which is a valid reason to consider it. However, I\'m not\n> >     aware of any particular issues that my approach would cause in\n> >     implementing phase 2 (note that I have barely looked into it at all\n> >     though). In fact, I very much want Phase 2 to be entirely\n> >     encapsulated by the Resource class, so that the plugin type (legacy\n> >     vs. convergence-enabled) is transparent to the rest of the system.\n> >     Only in this way can we be sure that we\'ll be able to maintain\n> >     support for legacy plugins. So a phase 1 that mixes in aspects of\n> >     phase 2 is actually a bad thing in my view.\n> > \n> >     I really appreciate the effort that has gone into this already, but\n> >     in the absence of specific problems with building phase 2 on top of\n> >     another approach that are solved by this one, I\'m ready to call this\n> >     a distraction.\n> > \n> >  \n> > \n> > In it\'s defence, I like the simplicity of it. The concepts and code are\n> > easy to understand - tho\' part of this is doesn\'t implement all the\n> > stuff on your list yet.\n> > \n> >  \n> > \n> > \n> > \n> >     Anant & Friends\' Proposal\n> >     =========================\n> > \n> >     First off, I have found this very difficult to review properly since\n> >     the code is not separate from the huge mass of Heat code and nor is\n> >     the commit history in the form that patch submissions would take\n> >     (but rather includes backtracking and iteration on the design). As a\n> >     result, most of the information here has been gleaned from\n> >     discussions about the code rather than direct review. I have\n> >     repeatedly suggested that this proof of concept work should be done\n> >     using the simulator framework instead, unfortunately so far to no avail.\n> > \n> >     The last we heard on the mailing list about this, resource clean-up\n> >     had not yet been implemented. That was a major concern because that\n> >     is the more difficult half of the algorithm. Since then there have\n> >     been a lot more commits, but it\'s not yet clear whether resource\n> >     clean-up, update-during-update, replace-on-update and rollback have\n> >     been implemented, though it is clear that at least some progress has\n> >     been made on most or all of them. Perhaps someone can give us an update.\n> > \n> > \n> > https://github.com/anantpatil/heat-convergence-poc\n> >  \n> > \n> > \n> >     AIUI this code also mixes phase 2 with phase 1, which is a concern.\n> >     For me the highest priority for phase 1 is to be sure that it works\n> >     with existing plugins. Not only because we need to continue to\n> >     support them, but because converting all of our existing\n> >     \'integration-y\' unit tests to functional tests that operate in a\n> >     distributed system is virtually impossible in the time frame we have\n> >     available. So the existing test code needs to stick around, and the\n> >     existing stack create/update/delete mechanisms need to remain in\n> >     place until such time as we have equivalent functional test coverage\n> >     to begin eliminating existing unit tests. (We\'ll also, of course,\n> >     need to have unit tests for the individual elements of the new\n> >     distributed workflow, functional tests to confirm that the\n> >     distributed workflow works in principle as a whole - the scenarios\n> >     from the simulator can help with _part_ of this - and, not least, an\n> >     algorithm that is as similar as possible to the current one so that\n> >     our existing tests remain at least somewhat representative and don\'t\n> >     require too many major changes themselves.)\n> > \n> >     Speaking of tests, I gathered that this branch included tests, but I\n> >     don\'t know to what extent there are automated end-to-end functional\n> >     tests of the algorithm?\n> > \n> >     From what I can gather, the approach seems broadly similar to the\n> >     one I eventually settled on also. The major difference appears to be\n> >     in how we merge two or more streams of execution (i.e. when one\n> >     resource depends on two or more others). In my approach, the\n> >     dependencies are stored in the resources and each joining of streams\n> >     creates a database row to track it, which is easily locked with\n> >     contention on the lock extending only to those resources which are\n> >     direct dependencies of the one waiting. In this approach, both the\n> >     dependencies and the progress through the graph are stored in a\n> >     database table, necessitating (a) reading of the entire table (as it\n> >     relates to the current stack) on every resource operation, and (b)\n> >     locking of the entire table (which is hard) when marking a resource\n> >     operation complete.\n> > \n> >     I chatted to Anant about this today and he mentioned that they had\n> >     solved the locking problem by dispatching updates to a queue that is\n> >     read by a single engine per stack.\n> > \n> >     My approach also has the neat side-effects of pushing the data\n> >     required to resolve get_resource and get_att (without having to\n> >     reload the resources again and query them) as well as to update\n> >     dependencies (e.g. because of a replacement or deletion) along with\n> >     the flow of triggers. I don\'t know if anything similar is at work here.\n> > \n> >     It\'s entirely possible that the best design might combine elements\n> >     of both approaches.\n> > \n> >     The same open questions I detailed under my proposal also apply to\n> >     this one, if I understand correctly.\n> > \n> > \n> >     I\'m certain that I won\'t have represented everyone\'s work fairly\n> >     here, so I encourage folks to dive in and correct any errors about\n> >     theirs and ask any questions you might have about mine. (In case you\n> >     have been living under a rock, note that I\'ll be out of the office\n> >     for the rest of the week due to Thanksgiving so don\'t expect\n> >     immediate replies.)\n> > \n> >     I also think this would be a great time for the wider Heat community\n> >     to dive in and start asking questions and suggesting ideas. We need\n> >     to, ahem, converge on a shared understanding of the design so we can\n> >     all get to work delivering it for Kilo.\n> > \n> >  \n> > \n> > Agree, we need to get moving on this.\n> > \n> > -Angus\n> >  \n> > \n> > \n> >     cheers,\n> >     Zane.\n> > \n> >     _______________________________________________\n> >     OpenStack-dev mailing list\n> >     OpenStack-dev at lists.openstack.org\n> >     <mailto:OpenStack-dev at lists.openstack.org>\n> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> >  \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> Thanks Zane for your e-mail Zane and summarizing everyone\'s work.\n> \n> The design goals mentioned above looks more of performance goals and\n> constraints to me. I understand that it is unacceptable to have a poorly\n> performing engine and Resource plug-ins broken. Convergence spec clearly\n> mentions that the existing Resource plugins should not be changed.\n> \n> IMHO, and my teams\' HO, the design goals of convergence would be:\n> 1. Stability: No transient failures, either in Openstack/external\n> services or resources themselves, should fail the stack. Therefore, we\n> need to have Observers to check for divergence and converge a resource\n> if needed, to bring back to stable state.\n> 2. Resiliency: Heat engines should be able to take up tasks in case of\n> failures/restarts.\n> 3. Backward compatibility: \"We don\'t break the user space.\" No existing\n> stacks should break.\n> \n> We started the PoC with these goals in mind, any performance\n> optimization would be a plus point for us. Note than I am neglecting the\n> performance goal, just that it should be next in the pipeline. The\n> questions we should ask ourselves is whether we are storing enough data\n> (state of stack) in DB to enable resiliency? Are we distributing the\n> load evenly to all Heat engines? Does our notification mechanism\n> provides us some form of guarantee or acknowledgement?\n> \n> In retrospective, we had to struggle a lot to understand the existing\n> Heat engine. We couldn\'t have done justice by just creating another\n> project in GitHub and without any concrete understanding of existing\n> state-of-affairs. We are not at the same page with Heat core members, we\n> are novice and cores are experts.\n> \n> I am glad that we experimented with the Heat engine directly. The\n> current Heat engine is not resilient and the messaging also lacks\n> reliability. We (my team and I guess cores also) understand that async\n> message passing would be the way to go as synchronous RPC calls simply\n> wouldn\'t scale. But with async message passing there has to be some\n> mechanism of ACKing back, which I think lacks in current infrastructure.\n> \n> How could we provide stable user defined stack if the underlying Heat\n> core lacks it? Convergence is all about stable stacks. To make the\n> current Heat core stable we need to have, at the least:\n> 1. Some mechanism to ACK back messages over AMQP. Or some other solid\n> mechanism of message passing.\n> 2. Some mechanism for fault tolerance in Heat engine using external\n> tools/infrastructure like Celerey/Zookeeper. Without external\n> infrastructure/tool we will end-up bloating Heat engine with lot of\n> boiler-plate code to achieve this. We had recommended Celery in our\n> previous e-mail (from Vishnu.)\n> \n> It was due to our experiments with Heat engines for this PoC, we could\n> come up with above recommendations.\n> \n> Sate of our PoC\n> ---------------\n> \n> On GitHub: https://github.com/anantpatil/heat-convergence-poc\n> \n> Our current implementation of PoC locks the stack after each\n> notification to mark the graph as traversed and produce next level of\n> resources for convergence. We are facing challenges in\n> removing/minimizing these locks. We also have two different school of\n> thoughts for solving this lock issue as mentioned above in Vishnu\'s\n> e-mail. I will these descibe in detail the Wiki. There would different\n> branches in our GitHub for these two approaches.\n> \n\nIt would be helpful if you explained why you need to _lock_ the stack.\nMVCC in the database should be enough here. Basically you need to:\n\nbegin transaction\nupdate traversal information\nselect resolvable nodes\n{in code not sql -- send converge commands into async queue}\ncommit\n\nAny failure inside this transation should rollback the transaction and\nretry this. It is o-k to have duplicate converge commands for a resource.\n\nThis should be the single point of synchronization between workers that\nare resolving resources. Or perhaps this is the lock you meant? Either\nway, this isn\'t avoidable if you want to make sure everything is attempted\nat least once without having to continuously poll and re-poll the stack\nto look for unresolved resources. That is an option, but not one that I\nthink is going to be as simple as the transactional method.\n\n\n','<547C1285.7090909@hp.com>',NULL),('<1417474177-sup-8420@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 14:58:58',-28800,'2014-12-01 22:58:58',NULL,'[openstack-dev] [TripleO] mid-cycle details final draft','Hello! I\'ve received confirmation that our venue, the HP offices in\ndowntown Seattle, will be available for the most-often-preferred\nleast-often-cannot week of Feb 16 - 20.\n\nOur venue has a maximum of 20 participants, but I only have 16 possible\nattendees now. Please add yourself to that list _now_ if you will be\njoining us.\n\nI\'ve asked our office staff to confirm Feb 18 - 20 (Wed-Fri). When they\ndo, I will reply to this thread to let everyone know so you can all\nstart to book travel. See the etherpad for travel details.\n\nhttps://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n\n\n',NULL,NULL),('<1417478279-sup-9084@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 16:05:28',-28800,'2014-12-02 00:05:28',NULL,'[openstack-dev] [Heat] Using Job Queues for timeout ops','Excerpts from Zane Bitter\'s message of 2014-12-01 13:05:42 -0800:\n> On 13/11/14 13:59, Clint Byrum wrote:\n> > I\'m not sure we have the same understanding of AMQP, so hopefully we can\n> > clarify here. This stackoverflow answer echoes my understanding:\n> >\n> > http://stackoverflow.com/questions/17841843/rabbitmq-does-one-consumer-block-the-other-consumers-of-the-same-queue\n> >\n> > Not ack\'ing just means they might get retransmitted if we never ack. It\n> > doesn\'t block other consumers. And as the link above quotes from the\n> > AMQP spec, when there are multiple consumers, FIFO is not guaranteed.\n> > Other consumers get other messages.\n> \n> Thanks, obviously my recollection of how AMQP works was coloured too \n> much by oslo.messaging.\n> \n> > So just add the ability for a consumer to read, work, ack to\n> > oslo.messaging, and this is mostly handled via AMQP. Of course that\n> > also likely means no zeromq for Heat without accepting that messages\n> > may be lost if workers die.\n> >\n> > Basically we need to add something that is not \"RPC\" but instead\n> > \"jobqueue\" that mimics this:\n> >\n> > http://git.openstack.org/cgit/openstack/oslo.messaging/tree/oslo/messaging/rpc/dispatcher.py#n131\n> >\n> > I\'ve always been suspicious of this bit of code, as it basically means\n> > that if anything fails between that call, and the one below it, we have\n> > lost contact, but as long as clients are written to re-send when there\n> > is a lack of reply, there shouldn\'t be a problem. But, for a job queue,\n> > there is no reply, and so the worker would dispatch, and then\n> > acknowledge after the dispatched call had returned (including having\n> > completed the step where new messages are added to the queue for any\n> > newly-possible children).\n> \n> I\'m curious how people are deploying Rabbit at the moment. Are they \n> setting up multiple brokers and writing messages to disk before \n> accepting them? I assume yes on the former but no on the latter, since \n> there\'s no particular point in having e.g. 5 nines durability in the \n> queue when the overall system is as weak as your flakiest node.\n> \n\nUsually the pseudo-code should be:\n\nmsg = queue.read()\ndo_something_idempotent_with(msg.payload)\nmsg.ack()\n\nThe idea is to ack only after you\'ve done _everything_ with the payload,\nbut to not freak out if somebody already did _some_ of what you did with\nthe payload.\n\n> OTOH if we were to add what you\'re proposing, then we would need folks \n> to deploy Rabbit that way (at least for Heat), since waiting for Acks on \n> receipt is insufficient to make messaging reliable if the broker can \n> easily outright lose the message.\n> \n\nIf you ask RabbitMQ to make a message durable, it writes it to a durable\nqueue storage. If your broker is in a cluster, it makes sure it\'s\nwritten into _many_ queue storages.\n\nCurrently if you deploy TripleO w/ 3 controllers, you get a clustered\nRabbitMQ and sufficient durability for the pattern I cited. Users may\nnot be deploying this way, but they should be.\n\nI\'m sort of assuming qpid\'s clustering works the same. 0mq will likely\nnot work at all for this. Other options are feasible too, like a simple\nredis queue that you abuse as a job queue.\n\n> I think all of the proposed approaches would benefit from this feature, \n> but I\'m concerned about any increased burden on deployers too.\n\nRight now they have the burden of supporting coarse timeouts which seems\nlike it will fail often. That seems worse in my head.\n\n\n','<547CD826.6010204@redhat.com>',NULL),('<1417495283-sup-444@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 20:46:14',-28800,'2014-12-02 04:46:14',NULL,'[openstack-dev] [diskimage-builder] Tracing levels for scripts\n	(119023)','Excerpts from James Slagle\'s message of 2014-11-28 11:27:20 -0800:\n> On Thu, Nov 27, 2014 at 1:29 PM, Sullivan, Jon Paul\n> <JonPaul.Sullivan at hp.com> wrote:\n> >> -----Original Message-----\n> >> From: Ben Nemec [mailto:openstack at nemebean.com]\n> >> Sent: 26 November 2014 17:03\n> >> To: OpenStack Development Mailing List (not for usage questions)\n> >> Subject: Re: [openstack-dev] [diskimage-builder] Tracing levels for\n> >> scripts (119023)\n> >>\n> >> On 11/25/2014 10:58 PM, Ian Wienand wrote:\n> >> > Hi,\n> >> >\n> >> > My change [1] to enable a consistent tracing mechanism for the many\n> >> > scripts diskimage-builder runs during its build seems to have hit a\n> >> > stalemate.\n> >> >\n> >> > I hope we can agree that the current situation is not good.  When\n> >> > trying to develop with diskimage-builder, I find myself constantly\n> >> > going and fiddling with \"set -x\" in various scripts, requiring me\n> >> > re-running things needlessly as I try and trace what\'s happening.\n> >> > Conversley some scripts set -x all the time and give output when you\n> >> > don\'t want it.\n> >> >\n> >> > Now nodepool is using d-i-b more, it would be even nicer to have\n> >> > consistency in the tracing so relevant info is captured in the image\n> >> > build logs.\n> >> >\n> >> > The crux of the issue seems to be some disagreement between reviewers\n> >> > over having a single \"trace everything\" flag or a more fine-grained\n> >> > approach, as currently implemented after it was asked for in reviews.\n> >> >\n> >> > I must be honest, I feel a bit silly calling out essentially a\n> >> > four-line patch here.\n> >>\n> >> My objections are documented in the review, but basically boil down to\n> >> the fact that it\'s not a four line patch, it\'s a 500+ line patch that\n> >> does essentially the same thing as:\n> >>\n> >> set +e\n> >> set -x\n> >> export SHELLOPTS\n> >\n> > I don\'t think this is true, as there are many more things in SHELLOPTS than just xtrace.  I think it is wrong to call the two approaches equivalent.\n> >\n> >>\n> >> in disk-image-create.  You do lose set -e in disk-image-create itself on\n> >> debug runs because that\'s not something we can safely propagate,\n> >> although we could work around that by unsetting it before calling hooks.\n> >>  FWIW I\'ve used this method locally and it worked fine.\n> >\n> > So this does say that your alternative implementation has a difference from the proposed one.  And that the difference has a negative impact.\n> >\n> >>\n> >> The only drawback is it doesn\'t allow the granularity of an if block in\n> >> every script, but I don\'t personally see that as a particularly useful\n> >> feature anyway.  I would like to hear from someone who requested that\n> >> functionality as to what their use case is and how they would define the\n> >> different debug levels before we merge an intrusive patch that would\n> >> need to be added to every single new script in dib or tripleo going\n> >> forward.\n> >\n> > So currently we have boilerplate to be added to all new elements, and that boilerplate is:\n> >\n> >     set -eux\n> >     set -o pipefail\n> >\n> > This patch would change that boilerplate to:\n> >\n> >     if [ ${DIB_DEBUG_TRACE:-0} -gt 0 ]; then\n> >         set -x\n> >     fi\n> >     set -eu\n> >     set -o pipefail\n> >\n> > So it\'s adding 3 lines.  It doesn\'t seem onerous, especially as most people creating a new element will either copy an existing one or copy/paste the header anyway.\n> >\n> > I think that giving control over what is effectively debug or non-debug output is a desirable feature.\n> \n> I don\'t think it\'s debug vs non-debug. I think script writers that\n> have explicitly used set -x previously have then operated under the\n> assumption that they don\'t need to add any useful logging since it\'s\n> running -x. In that case, this patch is actually harmful.\n> \n\nI believe James has hit the nail squarely on the head with the paragraph\nabove.\n\nI propose a way forward for this:\n\n1) Conform all o-r-c scripts to the logging standards we have in\nOpenStack, or write new standards for diskimage-builder and conform\nthem to those standards. Abolish non-conditional xtrace in any script\nconforming to the standards.\n\n2) Once that is done, implement optional -x. I rather prefer the explicit\nconditional set -x implementation over SHELLOPTS. As somebody else\npointed out, it feels like asking for unintended side-effects. But the\n\"how\" is far less important than the \"what\" in this case, which step 1\nwill better define.\n\nAnyone else have a better plan?\n\n\n','<CAHV77z8+0FS+axAZ3s+P7B+M=sSvsEOD=YviZ9kwi73Oug4Vtg@mail.gmail.com>',NULL),('<1417541257.4057.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 17:27:33',0,'2014-12-02 17:27:33',NULL,'[openstack-dev]  [neutron][lbaas] Kilo Midcycle Meetup','Per the meeting, put together an etherpad here:\n\nhttps://etherpad.openstack.org/p/lbaas-kilo-meetup\n\nI would like to get the location and dates finalized ASAP (preferrably\nthe next couple of days).\n\nWe\'ll also try to do the same as the neutron and octava meetups for\nremote attendees.\n\n','<F36E8145F2571242A675F56CF60964562895378B@ILMB1.corp.radware.com>',NULL),('<1417542135-sup-3131@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 09:51:21',-28800,'2014-12-02 17:51:21',NULL,'[openstack-dev] [qa] Should it be allowed to attach 2\n	interfaces from the same subnet to a VM?','Excerpts from Danny Choi (dannchoi)\'s message of 2014-12-02 08:34:07 -0800:\n> Hi Andrea,\n> \n> Though both interfaces come up, only one will response to the ping from the neutron router.\n> When I disable it, then the second one will response to ping.\n> So it looks like only one interface is useful at a time.\n> \n\nI believe both interfaces can be used independently by setting\narp_announce to 1 or 2. As in:\n\nsysctl -w net.ipv4.conf.all.arp_announce=2\n\nMight want to try both settings. The documentation is here:\n\nhttps://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt\n\n\n','<D0A3542E.2F1E%dannchoi@cisco.com>',NULL),('<1417548734-sup-3382@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 11:49:34',-28800,'2014-12-02 19:49:34',NULL,'[openstack-dev] [Heat] Convergence proof-of-concept showdown','Excerpts from Anant Patil\'s message of 2014-12-02 10:37:31 -0800:\n> Yes, that\'s the synchronization block for which we use the stack lock.\n> Currently, a thread spin waits to acquire the lock to enter this critical\n> section.\n> \n> I don\'t really know how to do application level transaction. Is there an\n> external library for that? AFAIK, we cannot switch from DB transaction to\n> application level to do some computation to resolve next set of resources,\n> submit to async queue, and again continue with the DB transaction. The\n> transnational method looks attractive and clean to me but I am limited by\n> my knowledge.Or do you mean to have DB transaction object made available\n> via DB APIs and use them in the application? Please share your thoughts.\n> \n\nEvery DB request has a context attached to the currently running\ngreenthread which has the DB session object. So yes, you do begin the\ntransaction in one db API call, and try to commit it in another after\nhaving attempted any application logic.  The whole thing should always be\nin a try/except retry loop to handle deadlocks and conflicts introduced\nby multi-master sync replication like Galera.\n\nFor non-transactional backends, they would have to use a spin lock like\nyou\'re using now.\n\n> To avoid locking the stack, we were thinking of designating a single engine\n> with responsibility of processing all notifications for a stack. All the\n> workers will notify on the stack topic, which only one engine listens to\n> and then the notifications end up in a queue (local to the engine, per\n> stack), from where they are taken up one-by-one to continue the stack\n> operation. The convergence jobs are produced by this engine for the stack\n> it is responsible for, and they might end-up in any of the engines. But the\n> notifications for a stack are directed to one engine to avoid contention\n> for lock. The convergence load is leveled and distributed, and stack lock\n> is not needed.\n> \n\nNo don\'t do that. You already have that engine, it is the database engine\nand it is intended to be used for synchronization and will achieve a\nhigher degree of concurrency in bigger stacks because it will only block\ntwo workers when they try to inspect or change the same rows.\n\n\n','<CAN25hfgrX7WLCD2j+7+LirFD61GN-QjQMGcB1thLZUU-EP4UEg@mail.gmail.com>',NULL),('<1417559171-sup-8883@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 14:30:47',-28800,'2014-12-02 22:30:47',NULL,'[openstack-dev] [diskimage-builder] Tracing levels for scripts\n	(119023)','Excerpts from Ian Wienand\'s message of 2014-12-02 11:22:31 -0800:\n> On 12/02/2014 03:46 PM, Clint Byrum wrote:\n> > 1) Conform all o-r-c scripts to the logging standards we have in\n> > OpenStack, or write new standards for diskimage-builder and conform\n> > them to those standards. Abolish non-conditional xtrace in any script\n> > conforming to the standards.\n> \n> Honestly in the list of things that need doing in openstack, this must\n> be near the bottom.\n> \n> The whole reason I wrote this is because \"disk-image-create -x ...\"\n> doesn\'t do what any reasonable person expects it to; i.e. trace all\n> the scripts it starts.\n> \n> Having a way to trace execution of all d-i-b scripts is all that\'s\n> needed and gives sufficient detail to debug issues.\n\nSeveral developers have expressed their concern for an all-or-nothing\napproach to this. The concern is that when you turn off the \"trace all\"\nyou lose the author-intended \"info\" level messages.\n\nI for one find the idea of printing every cp, cat, echo and ls command out\nrather frustratingly verbose when scanning logs from a normal run. Do I\nwant it sometimes? YES, but it will actually hinder normal image building\niteration if we only have a toggle of \"all trace\" or \"no trace\".\n\n\n','<547E1177.4030705@redhat.com>',NULL),('<1417600749.20200.5.camel@etc.gen.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-03 22:59:09',46800,'2014-12-03 09:59:09',NULL,'[openstack-dev] [neutron] Private external network','Hi,\n\nI\'m picking up this thread from a few months ago, as I have a\nrequirement for a private external network and after doing some testing\ntoday came to the conclusion that this isn\'t currently possible. Rats.\n\nOn Tue, 2014-10-14 at 17:42 +0000, A, Keshava wrote:\n> Hi,\n> \n> Across these private External network/tenant :: floating IP can be\n> shared ? \n\nI would think not. The external network and associated floating IPs\nshould only be accessible by the tenant (or tenants?) which are granted\nto use it.\n\nAt a guess that tenants thought above is where the RBAC considerations\ncome in.\n\nDoes anyone have any pointers to the previous discussions on this? The\nBP [0] which ?douard linked to states it was untargetted due to\ncommunity discussions but has no links or other references to those\ndiscussions. \n\nCheers,\nAndrew\n\n[0]\nhttps://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks\n\n\n-- \nAndrew Ruthven, Wellington, New Zealand\nandrew at etc.gen.nz             |     linux.conf.au 2015 \n  New Zealand\'s only Cloud:   |  BeAwesome in Auckland, NZ\nhttps://catalyst.net.nz/cloud | http://lca2015.linux.org.au\n\n\n\n\n','<891761EAFA335D44AD1FFDB9B4A8C063C7C080@G4W3216.americas.hpqcorp.net>',NULL),('<1417608080.4484.4.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-03 13:01:20',3600,'2014-12-03 12:01:20',NULL,'[openstack-dev] [Neutron] DVR Slides from Paris Summit','Hi, \nis there a way to get access to the slides from the DVR session of the\nParis summit? Unfortunately the slides in the video are not readable. \n\nSpeakers were Swaminathan Vasudevan, Jack McCann, Vivekanandan,\nNarasimhan, Rajeev Grover, Michael Smith. So maybe one of you can post\nthem on slideshare or somewhere else? That would be great.\n\nThis is the link to the related video\n\nhttps://www.openstack.org/summit/openstack-paris-summit-2014/session-videos/presentation/architectural-overview-of-distributed-virtual-routers-in-openstack-neutron\n\n\n\nThanks\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1417631988-sup-5421@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-03 10:41:01',-28800,'2014-12-03 18:41:01',NULL,'[openstack-dev] [diskimage-builder] Tracing levels for scripts\n	(119023)','Excerpts from Chris Jones\'s message of 2014-12-03 02:47:30 -0800:\n> Hi\n> \n> I am very sympathetic to this view. We have a patch in hand that improves the situation. We also have disagreement about the ideal situation.\n> \n> I +2\'d Ian\'s patch because it makes things work better than they do now. If we can arrive at an ideal solution later, great, but the more I think about logging from a multitude of bash scripts, and tricks like XTRACE_FD, the more I think it\'s crazy and we should just incrementally improve the non-trace logging as a separate exercise, leaving working tracing for true debugging situations.\n> \n\nForgive me, I am not pushing for an ideal situation, but I don\'t want a\nregression.\n\nRunning without -x right now has authors xtracing as a rule. Meaning\nthat the moment this merges, the amount of output goes to almost nil\ncompared to what it is now.\n\nBasically this is just more of the same OpenStack wrong-headed idea, \"you\nhave to run in DEBUG logging mode to be able to understand any issue\".\n\nI\'m totally willing to compromise on the ideal for something that is\ngood enough, but I\'m saying this is not good enough _if_ it turns off\ntracing for all scripts.\n\nWhat if the patch is reworked to leave the current trace-all-the-time\nmode in place, and we iterate on each script to make tracing conditional\nas we add proper logging?\n\n\n','<3C6FDAE6-9BEB-4E9B-91A8-BD5AE724C6D7@tenshu.net>',NULL),('<1417650129.19489.14.camel@bitergia.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 00:42:09',3600,'2014-12-03 23:42:09',NULL,'[openstack-dev] How to get openstack bugs data for research?','You can download a database dump with (hopefully) information for all\nLaunchpad tickets corresponding to OpenStack, already organized and\nready to be queried:\n\nhttp://activity.openstack.org/dash/browser/data/db/tickets.mysql.7z\n\n(linked from\nhttp://activity.openstack.org/dash/browser/data_sources.html )\n\nIt is a 7z-zipped file with includes a MySQL dump of the actual\ndatabase, produced by Bicho (one of the tools in MetricsGrimoire). It is\nupdated daily.\n\nYou can just feed it to MySQL, and start to do your queries. There is\nsome information about Bicho and the database schema used at\n\nhttps://github.com/MetricsGrimoire/Bicho/wiki\n\nhttps://github.com/MetricsGrimoire/Bicho/wiki/Database-Schema\n\nPlease, let me know if you need further info.\n\nSaludos,\n\n	Jesus.\n\nOn Wed, 2014-12-03 at 20:20 +0800, zfx0906 at gmail.com wrote:\n> Hi, all\n> \n> \n> I am a graduate student in Peking University, our lab do some research\n> on open source projects. \n> This is our introduction: https://passion-lab.org/\n> \n> \n> Now we need openstack issues data for research, I found the issues\n> list: https://bugs.launchpad.net/openstack/\n> I want to download the openstack issues data, Could anyone tell me how\n> to download the data? Or is there some link or API for download the\n> data?\n> \n> \n> And I found 9464  bugs in https://bugs.launchpad.net/openstack/ ?is\n> this all? why so few?\n> \n> \n> Many thanks!\n> \n> \n> Beat regards,\n> Feixue, Zhang\n> \n> \n> \n> ______________________________________________________________________\n> zfx0906 at gmail.com\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nBitergia: http://bitergia.com\n/me at Twitter: https://twitter.com/jgbarah\n\n\n\n','<2014120320204186973010@gmail.com>',NULL),('<1417660515.836.3.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-03 21:35:15',-18000,'2014-12-04 02:35:15',NULL,'[openstack-dev] [tripleo] Managing no-mergepy template\n duplication','On Wed, 2014-12-03 at 10:11 +0000, Steven Hardy wrote:\n> Hi all,\n> \n> Lately I\'ve been spending more time looking at tripleo and doing some\n> reviews. I\'m particularly interested in helping the no-mergepy and\n> subsequent puppet-software-config implementations mature (as well as\n> improving overcloud updates via heat).\n> \n> Since Tomas\'s patch landed[1] to enable --no-mergepy in\n> tripleo-heat-templates, it\'s become apparent that frequently patches are\n> submitted which only update overcloud-source.yaml, so I\'ve been trying to\n> catch these and ask for a corresponding change to e.g controller.yaml.\n> \n> This raises the following questions:\n> \n> 1. Is it reasonable to -1 a patch and ask folks to update in both places?\n\nYes! In fact until we abandon merge.py we shouldn\'t land anything that\ndoesn\'t make the change in both places. Probably more important to make\nsure things go into the new (no-mergepy) templates though.\n\n> 2. How are we going to handle this duplication and divergence?\n\nMove as quickly as possible to the new without-mergepy varients? That is\nmy vote anyways.\n\n> 3. What\'s the status of getting gating CI on the --no-mergepy templates?\n\nDevtest already supports it by simply setting an option (which sets an\nENV variable). Just need to update tripleo-ci to do that and then make\nthe switch.\n\n> 4. What barriers exist (now that I\'ve implemented[2] the eliding functionality\n> requested[3] for ResourceGroup) to moving to the --no-mergepy\n> implementation by default?\n\nNone that I know of.\n\n> \n> Thanks for any clarification you can provide! :)\n> \n> Steve\n> \n> [1] https://review.openstack.org/#/c/123100/\n> [2] https://review.openstack.org/#/c/128365/\n> [3] https://review.openstack.org/#/c/123713/\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20141203101059.GA23017@t430slt.redhat.com>',NULL),('<1417661497-sup-1964@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-03 18:54:48',-28800,'2014-12-04 02:54:48',NULL,'[openstack-dev] [tripleo] Managing no-mergepy template\n	duplication','Excerpts from Dan Prince\'s message of 2014-12-03 18:35:15 -0800:\n> On Wed, 2014-12-03 at 10:11 +0000, Steven Hardy wrote:\n> > Hi all,\n> > \n> > Lately I\'ve been spending more time looking at tripleo and doing some\n> > reviews. I\'m particularly interested in helping the no-mergepy and\n> > subsequent puppet-software-config implementations mature (as well as\n> > improving overcloud updates via heat).\n> > \n> > Since Tomas\'s patch landed[1] to enable --no-mergepy in\n> > tripleo-heat-templates, it\'s become apparent that frequently patches are\n> > submitted which only update overcloud-source.yaml, so I\'ve been trying to\n> > catch these and ask for a corresponding change to e.g controller.yaml.\n> > \n> > This raises the following questions:\n> > \n> > 1. Is it reasonable to -1 a patch and ask folks to update in both places?\n> \n> Yes! In fact until we abandon merge.py we shouldn\'t land anything that\n> doesn\'t make the change in both places. Probably more important to make\n> sure things go into the new (no-mergepy) templates though.\n> \n> > 2. How are we going to handle this duplication and divergence?\n> \n> Move as quickly as possible to the new without-mergepy varients? That is\n> my vote anyways.\n> \n> > 3. What\'s the status of getting gating CI on the --no-mergepy templates?\n> \n> Devtest already supports it by simply setting an option (which sets an\n> ENV variable). Just need to update tripleo-ci to do that and then make\n> the switch.\n> \n> > 4. What barriers exist (now that I\'ve implemented[2] the eliding functionality\n> > requested[3] for ResourceGroup) to moving to the --no-mergepy\n> > implementation by default?\n> \n> None that I know of.\n> \n\nI concur with Dan. Elide was the last reason not to use this.\n\nOne thing to consider is that there is no actual upgrade path from\nnon-autoscaling-group based clouds, to auto-scaling-group based\ntemplates. We should consider how we\'ll do that before making it the\ndefault. So, I suggest we discuss possible upgrade paths and then move\nforward with switching one of the CI jobs to using the new templates.\n\n\n','<1417660515.836.3.camel@dovetail.localdomain>',NULL),('<1417691476.18966.2.camel@etc.gen.nz>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 00:11:16',46800,'2014-12-04 11:11:16',NULL,'[openstack-dev] [neutron] Private external network','On Wed, 2014-12-03 at 02:08 -0800, Kevin Benton wrote:\n> There is a current blueprint under discussion[1] which would have\n> covered the external network access control as well, however it looks\n> like the scope is going to have to be reduced for this cycle so it\n> will be limited to shared networks if it\'s accepted at all.\n> \n> \n> 1. https://review.openstack.org/#/c/132661/\n\nGreat, that looks to cover off what I need to achieve. Thanks Kevin!\n\n\n-- \nAndrew Ruthven, Wellington, New Zealand\nandrew at etc.gen.nz             |     linux.conf.au 2015 \n  New Zealand\'s only Cloud:   |  BeAwesome in Auckland, NZ\nhttps://catalyst.net.nz/cloud | http://lca2015.linux.org.au\n\n\n\n\n','<CAO_F6JO_qjSoPmkV1iGDE=XVdutPU71xk-P=yhx8tD-8JSPfDg@mail.gmail.com>',NULL),('<1417698596.2112.1.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 08:09:56',-18000,'2014-12-04 13:09:56',NULL,'[openstack-dev] [TripleO] Do we want to remove Nova-bm support?','On Thu, 2014-12-04 at 15:47 +1100, Steve Kowalik wrote:\n> Hi all,\n> \n> 	I\'m becoming increasingly concerned about all of the code paths\n> in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use\n> nova-baremetal rather than Ironic. We do not check nova-bm support in\n> CI, haven\'t for at least a month, and I\'m concerned that parts of it\n> may be slowly bit-rotting.\n> \n> 	I think our documentation is fairly clear that nova-baremetal is\n> deprecated and Ironic is the way forward, and I know it flies in the\n> face of backwards-compatibility, but do we want to bite the bullet and\n> remove nova-bm support?\n\nI\'d vote yes.\n\nGiven that our CI jobs all currently use Ironic I think it is safe to\nmove forwards and remove the old Nova BM configuration.\n\nDan\n\n> \n> Cheers,\n\n\n\n\n','<547FE757.9030701@wedontsleep.org>',NULL),('<1417699460.2112.13.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 08:24:20',-18000,'2014-12-04 13:24:20',NULL,'[openstack-dev] [TripleO] Meeting purpose','On Thu, 2014-12-04 at 10:11 +0100, James Polley wrote:\n> Hi all, \n> \n> \n> The other topic that has come up a few times in our meetings is: what\n> value do we get from these meetings?\n\nOften. Not much. :( Partially my own fault too since I haven\'t been good\nabout adding items to the agenda myself ahead of time.\n\n> \n> \n> There\'s no doubt that regular meetings provide value - but that\n> doesn\'t mean that everything we do in them is valuable.\n> \n> \n> As an example of something that I think doesn\'t add much value in the\n> meeting - DerekH has already been giving semi-regular CI/CD status\n> reports via email. I\'d like to make these weekly update emails\n> regular, and take the update off the meeting agenda. I\'m offering to\n> share the load with him to make this easier to achieve.\n> \n> \n> Are there other things on our regular agenda that you feel aren\'t\n> offering much value?\n\nI\'d propose we axe the regular agenda entirely and let people promote\nthings in open discussion if they need to. In fact the regular agenda\noften seems like a bunch of motions we go through... to the extent that\nwhile the TripleO meeting was going on we\'ve actually discussed what was\nin my opinion the most important things in the normal #tripleo IRC\nchannel. Is getting through our review stats really that important!?\n\n>  Are there things you\'d like to see moved onto, or off, the agenda?\n\nPerhaps a streamlined agenda like this would work better:\n\n * Bugs\n * Projects needing releases\n * Open Discussion (including important SPECs, CI, or anything needing\nattention). ** Leader might have to drive this **\n\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAPtRfUGpLveeaTkh1FayEnjjAPoo-uApwX4gTFBWhrmg_AEU7g@mail.gmail.com>',NULL),('<1417700253.2112.23.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 08:37:33',-18000,'2014-12-04 13:37:33',NULL,'[openstack-dev] [TripleO] CI report : 1/11/2014 - 4/12/2014','On Thu, 2014-12-04 at 11:51 +0000, Derek Higgins wrote:\n> A month since my last update, sorry my bad\n> \n> since the last email we\'ve had 5 incidents causing ci failures\n> \n> 26/11/2014 : Lots of ubuntu jobs failed over 24 hours (maybe half)\n> - We seem to suffer any time an ubuntu mirror isn\'t in sync causing hash\n> mismatch errors. For now I\'ve pinned DNS on our proxy to a specific\n> server so we stop DNS round robining\n\nThis sound fine to me. I personally like the model where you pin to a\nspecific mirror, perhaps one that is geographically closer to your\ndatacenter. This also makes Squid caching (in the rack) happier in some\ncases.\n\n> \n> 21/11/2014 : All tripleo jobs failed for about 16 hours\n> - Neutron started asserting that local_ip be set to a valid ip address,\n> on the seed we had been leaving it blank\n> - Cinder moved to using  oslo.concurreny which in turn requires that\n> lock_path be set, we are now setting it\n\n\nThinking about how we might catch these ahead of time with our limited\nresources ATM. These sorts of failures all seem related to configuration\nand or requirements changes. I wonder if we were to selectively\n(automatically) run check experimental jobs on all reviews with\nassociated tickets which have either doc changes or modify\nrequirements.txt. Probably a bit of work to pull this off but if we had\na report containing these results \"coming down the pike\" we might be\nable to catch them ahead of time.\n\n\n> \n> 8/11/2014 : All fedora tripleo jobs failed for about 60 hours (over a\n> weekend)\n> - A url being accessed on  https://bzr.linuxfoundation.org is no longer\n> available, we removed the dependency\n> \n> 7/11/2014 : All tripleo tests failed for about 24 hours\n> - Options were removed from nova.conf that had been deprecated (although\n> no deprecation warnings were being reported), we were still using these\n> in tripleo\n> \n> as always more details can be found here\n> https://etherpad.openstack.org/p/tripleo-ci-breakages\n\nThanks for sending this out! Very useful.\n\nDan\n\n> \n> thanks,\n> Derek.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<54804AA5.9090902@redhat.com>',NULL),('<1417710824.486.1367215618555.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-29 06:06:58',0,'2013-04-29 06:06:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #19','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-29 06:06:54    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:06:54,178 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-29 06:06:54,179 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:06:54,180 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,180 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,181 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-29 06:06:54,181 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-29 06:06:54,182 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-29 06:06:54  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-29 06:06:54,183 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:06:54    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:06:54,184 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,186 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.186567\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.186567\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54,187 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,188 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,188 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,189 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54,190 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.189381\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.189381\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54,190 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,191 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,191 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:06:54,192 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,193 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,194 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54,194 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.193958\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.193958\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54,195 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,196 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,196 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:06:54,197 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,198 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,198 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54,199 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.198877\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.198877\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54,200 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,200 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,201 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:06:54,202 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,202 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,203 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:06:54,204 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:06:54,205 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.204487\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:06:54.204487\', resource_metadata={}) from 0 transformer\n2013-04-29 06:06:54,206 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,206 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54,207 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:06:54,207 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:06:54,208 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.098s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.19\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a79.g3acd2a5\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a415.g25541a5\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.PvKFHpNN6L\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/19\n[SCP] Copying console log.\n\n\n','<1678149485.427.1367129143360.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1417719771-sup-5483@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 11:04:45',-28800,'2014-12-04 19:04:45',NULL,'[openstack-dev] [TripleO] [Ironic] Do we want to remove Nova-bm\n	support?','Excerpts from Steve Kowalik\'s message of 2014-12-03 20:47:19 -0800:\n> Hi all,\n> \n>     I\'m becoming increasingly concerned about all of the code paths\n> in tripleo-incubator that check $USE_IRONIC -eq 0 -- that is, use\n> nova-baremetal rather than Ironic. We do not check nova-bm support in\n> CI, haven\'t for at least a month, and I\'m concerned that parts of it\n> may be slowly bit-rotting.\n> \n>     I think our documentation is fairly clear that nova-baremetal is\n> deprecated and Ironic is the way forward, and I know it flies in the\n> face of backwards-compatibility, but do we want to bite the bullet and\n> remove nova-bm support?\n\nHas Ironic settled on a migration path/tool from nova-bm? If yes, then\nwe should remove nova-bm support and point people at the migration\ndocumentation.\n\nIf Ironic decided not to provide one, then we should just remove support\nas well.\n\nIf Ironic just isn\'t done yet, then removing nova-bm in TripleO is\npremature and we should wait for them to finish.\n\n\n','<547FE757.9030701@wedontsleep.org>',NULL),('<1417727947-sup-1606@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 13:24:02',-28800,'2014-12-04 21:24:02',NULL,'[openstack-dev] [TripleO] Do we want to remove Nova-bm support?','Excerpts from Ben Nemec\'s message of 2014-12-04 11:12:10 -0800:\n> FWIW, I think the \"correct\" thing to do here is to get our Juno jobs up\n> and running and have one of them verify the nova-bm code paths for this\n> cycle, and then remove it next cycle.\n> \n> That said, I have no idea how close we are to actually having Juno jobs\n> and I agree that we have no idea if the nova-bm code actually works\n> anymore (although that applies to backwards compat as a whole too).\n> \n> I guess I\'m inclined to just leave it though.  AFAIK the nova-bm code\n> isn\'t hurting anything, and if it does happen to be working and have a\n> user then removing it would break them for no good reason.  If it\'s not\n> working then it\'s not working and nobody\'s going to accidentally start\n> using it.  The only real downside of leaving it is if it is working and\n> someone would happen to override our defaults, ignore all the\n> deprecation warnings, and start using it anyway.  I don\'t see that as a\n> big concern.\n> \n> But I\'m not super attached to nova-bm either, so just my 2 cents.\n> \n\nI think this is overly cautious, but I can\'t think of a moderately\ncautious plan, so let\'s just land deprecation warning messages in the\nimage builds and devtest scripts. I don\'t know if there\'s much more we\ncan do without running the risk of yanking the rug out from some silent\nuser out there.\n\n\n','<5480B20A.5080804@nemebean.com>',NULL),('<1417735253.3315371.198607341.1EF60179@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 15:20:53',-28800,'2014-12-04 23:20:53',NULL,'[openstack-dev] [TripleO] Using python logging.conf for openstack\n	services','Hello TripleOers,\n\nI got a patch together to move us off of our upstart exec <service> |\nlogger -t <service> hack [1] and this got me wondering - why aren\'t we\nusing the python logging.conf supported by most OpenStack projects [2]\nto write out logs to files in our desired location? \n\nThis is highly desirable for a couple reasons:\n\n* Less complexity / more straightforward. Basically we wouldn\'t have to\nrun rsyslog or similar and have app config to talk to syslog then syslog\nconfig to put our logs where we want. We also don\'t have to battle with\nupstart + rsyslog vs systemd-journald differences and maintain two sets\nof configuration.\n\n* We get actual control over formatting. This is a double edged sword in\nthat AFAICT you *have* to control formatting if you\'re using a\nlogging.conf with a custom log handler. This means it would be a bit of\na divergence from our \"use the defaults\" policy but there are some\nlogging formats in the OpenStack docs [3] named \"normal\", maybe this\ncould be acceptable? The big win here is we can avoid issues like having\nduplicate timestamps [4] (this issue still exists on Ubuntu, at least)\nwithout having to do two sets of configuration, one for upstart +\nrsyslog, one for systemd.\n\n* This makes setting custom logging configuration a lot more feasible\nfor operators. As-is, if an operator wants to forward logs to an\nexisting central log server we dont really have a good way for them to\ndo this. We also have a requirement that we can come up with a way to\nexpose the rsyslog/journald config options needed to do this to\noperators. If we are using logging.conf we can just use our existing\npassthrough-config system to let operators simply write out custom\nlogging.conf files which are already documented by OpenStack.\n\nThoughts? Comments? Concerns?\n\nCheers,\nGreg\n\n[1] - https://review.openstack.org/#/c/138844/\n[2] -\nhttp://docs.openstack.org/admin-guide-cloud/content/section_manage-logs.html\n* Note that Swift does not support this\n[3] -\nhttp://docs.openstack.org/trunk/config-reference/content/section_keystone-logging.conf.html\n[4] - https://review.openstack.org/#/c/104619/\n\n-- \n  Gregory Haynes\n  greg at greghaynes.net\n\n\n',NULL,NULL),('<1417737096-sup-7722@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 15:56:00',-28800,'2014-12-04 23:56:00',NULL,'[openstack-dev] [TripleO] Using python logging.conf for\n	openstack services','Excerpts from Gregory Haynes\'s message of 2014-12-04 15:20:53 -0800:\n> Hello TripleOers,\n> \n> I got a patch together to move us off of our upstart exec <service> |\n> logger -t <service> hack [1] and this got me wondering - why aren\'t we\n> using the python logging.conf supported by most OpenStack projects [2]\n> to write out logs to files in our desired location? \n> \n> This is highly desirable for a couple reasons:\n> \n> * Less complexity / more straightforward. Basically we wouldn\'t have to\n> run rsyslog or similar and have app config to talk to syslog then syslog\n> config to put our logs where we want. We also don\'t have to battle with\n> upstart + rsyslog vs systemd-journald differences and maintain two sets\n> of configuration.\n> \n\n+1 for less complexity and for just using the normal OS logging\nfacilities that exist and are quite efficient.\n\n> * We get actual control over formatting. This is a double edged sword in\n> that AFAICT you *have* to control formatting if you\'re using a\n> logging.conf with a custom log handler. This means it would be a bit of\n> a divergence from our \"use the defaults\" policy but there are some\n> logging formats in the OpenStack docs [3] named \"normal\", maybe this\n> could be acceptable? The big win here is we can avoid issues like having\n> duplicate timestamps [4] (this issue still exists on Ubuntu, at least)\n> without having to do two sets of configuration, one for upstart +\n> rsyslog, one for systemd.\n> \n\nThis thread might need to get an [all] tag, and we might need to ask the\nquestion \"why isn\'t syslog the default?\". I don\'t have a good answer for\nthat, so I think we might want to consider doing it, but I especially\nwould like to hear from operators how many of them actually log things\nto syslog vs. on disk or something else.\n\n> * This makes setting custom logging configuration a lot more feasible\n> for operators. As-is, if an operator wants to forward logs to an\n> existing central log server we dont really have a good way for them to\n> do this. We also have a requirement that we can come up with a way to\n> expose the rsyslog/journald config options needed to do this to\n> operators. If we are using logging.conf we can just use our existing\n> passthrough-config system to let operators simply write out custom\n> logging.conf files which are already documented by OpenStack.\n\nAs usual, the parameters we have should just be things that we want to\nask users about on nearly every deployment. So I concur that passthrough\nis the way to go, since it will only be for those who don\'t want to use\nsyslog for logging.\n\n\n','<1417735253.3315371.198607341.1EF60179@webmail.messagingengine.com>',NULL),('<1417737958.4577.25.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 00:05:33',0,'2014-12-05 00:05:33',NULL,'[openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use\n Cases that led us to adopt this.','Sorry it\'s taken me a while to respond to this.\n\nSo I wasn\'t thinking about this correctly.  I was afraid you would have\nto pass in a full tree of parent child representations to /loadbalancers\nto update anything a load balancer it is associated to (including down\nto members).  However, after thinking about it, a user would just make\nan association call on each object.  For Example, associate member1 with\npool1, associate pool1 with listener1, then associate loadbalancer1 with\nlistener1.  Updating is just as simple as updating each entity.\n\nThis does bring up another problem though.  If a listener can live on\nmany load balancers, and a pool can live on many listeners, and a member\ncan live on many pools, there\'s lot of permutations to keep track of for\nstatus.  you can\'t just link a member\'s status to a load balancer bc a\nmember can exist on many pools under that load balancer, and each pool\ncan exist under many listeners under that load balancer.  For example,\nsay I have these:\n\nlb1\nlb2\nlistener1\nlistener2\npool1\npool2\nmember1\nmember2\n\nlb1 -> [listener1, listener2]\nlb2 -> [listener1]\nlistener1 -> [pool1, pool2]\nlistener2 -> [pool1]\npool1 -> [member1, member2]\npool2 -> [member1]\n\nmember1 can now have a different statuses under pool1 and pool2.  since\nlistener1 and listener2 both have pool1, this means member1 will now\nhave a different status for listener1 -> pool1 and listener2 -> pool2\ncombination.  And so forth for load balancers.\n\nBasically there\'s a lot of permutations and combinations to keep track\nof with this model for statuses.  Showing these in the body of load\nbalancer details can get quite large.\n\nI hope this makes sense because my brain is ready to explode.\n\nThanks,\nBrandon\n\nOn Thu, 2014-11-27 at 08:52 +0000, Samuel Bercovici wrote:\n> Brandon, can you please explain further (1) bellow?\n> \n> -----Original Message-----\n> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM] \n> Sent: Tuesday, November 25, 2014 12:23 AM\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.\n> \n> My impression is that the statuses of each entity will be shown on a detailed info request of a loadbalancer.  The root level objects would not have any statuses.  For example a user makes a GET request to /loadbalancers/{lb_id} and the status of every child of that load balancer is show in a \"status_tree\" json object.  For example:\n> \n> {\"name\": \"loadbalancer1\",\n>  \"status_tree\":\n>   {\"listeners\": \n>     [{\"name\": \"listener1\", \"operating_status\": \"ACTIVE\",\n>       \"default_pool\":\n>         {\"name\": \"pool1\", \"status\": \"ACTIVE\",\n>          \"members\":\n>            [{\"ip_address\": \"10.0.0.1\", \"status\": \"OFFLINE\"}]}}\n> \n> Sam, correct me if I am wrong.\n> \n> I generally like this idea.  I do have a few reservations with this:\n> \n> 1) Creating and updating a load balancer requires a full tree configuration with the current extension/plugin logic in neutron.  Since updates will require a full tree, it means the user would have to know the full tree configuration just to simply update a name.  Solving this would require nested child resources in the URL, which the current neutron extension/plugin does not allow.  Maybe the new one will.\n> \n> 2) The status_tree can get quite large depending on the number of listeners and pools being used.  This is a minor issue really as it will make horizon\'s (or any other UI tool\'s) job easier to show statuses.\n> \n> Thanks,\n> Brandon\n> \n> On Mon, 2014-11-24 at 12:43 -0800, Stephen Balukoff wrote:\n> > Hi Samuel,\n> > \n> > \n> > We\'ve actually been avoiding having a deeper discussion about status \n> > in Neutron LBaaS since this can get pretty hairy as the back-end \n> > implementations get more complicated. I suspect managing that is \n> > probably one of the bigger reasons we have disagreements around object \n> > sharing. Perhaps it\'s time we discussed representing state \"correctly\" \n> > (whatever that means), instead of a round-a-bout discussion about \n> > object sharing (which, I think, is really just avoiding this issue)?\n> > \n> > \n> > Do you have a proposal about how status should be represented \n> > (possibly including a description of the state machine) if we collapse \n> > everything down to be logical objects except the loadbalancer object?\n> > (From what you\'re proposing, I suspect it might be too general to, for \n> > example, represent the UP/DOWN status of members of a given pool.)\n> > \n> > \n> > Also, from an haproxy perspective, sharing pools within a single \n> > listener actually isn\'t a problem. That is to say, having the same \n> > L7Policy pointing at the same pool is OK, so I personally don\'t have a \n> > problem allowing sharing of objects within the scope of parent \n> > objects. What do the rest of y\'all think?\n> > \n> > \n> > Stephen\n> > \n> > \n> > \n> > On Sat, Nov 22, 2014 at 11:06 PM, Samuel Bercovici \n> > <SamuelB at radware.com> wrote:\n> >         Hi Stephen,\n> >         \n> >          \n> >         \n> >         1.      The issue is that if we do 1:1 and allow status/state\n> >         to proliferate throughout all objects we will then get an\n> >         issue to fix it later, hence even if we do not do sharing, I\n> >         would still like to have all objects besides LB be treated as\n> >         logical.\n> >         \n> >         2.      The 3rd use case bellow will not be reasonable without\n> >         pool sharing between different policies. Specifying different\n> >         pools which are the same for each policy make it non-started\n> >         to me. \n> >         \n> >          \n> >         \n> >         -Sam.\n> >         \n> >          \n> >         \n> >          \n> >         \n> >          \n> >         \n> >         From: Stephen Balukoff [mailto:sbalukoff at bluebox.net] \n> >         Sent: Friday, November 21, 2014 10:26 PM\n> >         To: OpenStack Development Mailing List (not for usage\n> >         questions)\n> >         Subject: Re: [openstack-dev] [neutron][lbaas] Shared Objects\n> >         in LBaaS - Use Cases that led us to adopt this.\n> >         \n> >          \n> >         \n> >         I think the idea was to implement 1:1 initially to reduce the\n> >         amount of code and operational complexity we\'d have to deal\n> >         with in initial revisions of LBaaS v2. Many to many can be\n> >         simulated in this scenario, though it does shift the burden of\n> >         maintenance to the end user. It does greatly simplify the\n> >         initial code for v2, in any case, though.\n> >         \n> >         \n> >          \n> >         \n> >         \n> >         Did we ever agree to allowing listeners to be shared among\n> >         load balancers?  I think that still might be a N:1\n> >         relationship even in our latest models.\n> >         \n> >          \n> >         \n> >         \n> >         There\'s also the difficulty introduced by supporting different\n> >         flavors:  Since flavors are essentially an association between\n> >         a load balancer object and a driver (with parameters), once\n> >         flavors are introduced, any sub-objects of a given load\n> >         balancer objects must necessarily be purely logical until they\n> >         are associated with a load balancer.  I know there was talk of\n> >         forcing these objects to be sub-objects of a load balancer\n> >         which can\'t be accessed independently of the load balancer\n> >         (which would have much the same effect as what you discuss:\n> >         State / status only make sense once logical objects have an\n> >         instantiation somewhere.) However, the currently proposed API\n> >         treats most objects as root objects, which breaks this\n> >         paradigm.\n> >         \n> >         \n> >          \n> >         \n> >         \n> >         How we handle status and updates once there\'s an instantiation\n> >         of these logical objects is where we start getting into real\n> >         complexity.\n> >         \n> >         \n> >          \n> >         \n> >         \n> >         It seems to me there\'s a lot of complexity introduced when we\n> >         allow a lot of many to many relationships without a whole lot\n> >         of benefit in real-world deployment scenarios. In most cases,\n> >         objects are not going to be shared, and in those cases with\n> >         sufficiently complicated deployments in which shared objects\n> >         could be used, the user is likely to be sophisticated enough\n> >         and skilled enough to manage updating what are essentially\n> >         \"copies\" of objects, and would likely have an opinion about\n> >         how individual failures should be handled which wouldn\'t\n> >         necessarily coincide with what we developers of the system\n> >         would assume. That is to say, allowing too many many to many\n> >         relationships feels like a solution to a problem that doesn\'t\n> >         really exist, and introduces a lot of unnecessary complexity.\n> >         \n> >         \n> >          \n> >         \n> >         \n> >         In any case, though, I feel like we should walk before we run:\n> >         Implementing 1:1 initially is a good idea to get us rolling.\n> >         Whether we then implement 1:N or M:N after that is another\n> >         question entirely. But in any case, it seems like a bad idea\n> >         to try to start with M:N.\n> >         \n> >         \n> >          \n> >         \n> >         \n> >         Stephen\n> >         \n> >         \n> >          \n> >         \n> >         \n> >          \n> >         \n> >         On Thu, Nov 20, 2014 at 4:52 AM, Samuel Bercovici\n> >         <SamuelB at radware.com> wrote:\n> >         \n> >         Hi,\n> >         \n> >         Per discussion I had at OpenStack Summit/Paris with Brandon\n> >         and Doug, I would like to remind everyone why we choose to\n> >         follow a model where pools and listeners are shared (many to\n> >         many relationships).\n> >         \n> >         Use Cases:\n> >         1. The same application is being exposed via different LB\n> >         objects.\n> >         For example: users coming from the internal \"private\"\n> >         organization network, have an LB1(private_VIP) -->\n> >         Listener1(TLS) -->Pool1 and user coming from the \"internet\",\n> >         have LB2(public_vip)-->Listener1(TLS)-->Pool1.\n> >         This may also happen to support ipv4 and ipv6: LB_v4(ipv4_VIP)\n> >         --> Listener1(TLS) -->Pool1 and LB_v6(ipv6_VIP) -->\n> >         Listener1(TLS) -->Pool1\n> >         The operator would like to be able to manage the pool\n> >         membership in cases of updates and error in a single place.\n> >         \n> >         2. The same group of servers is being used via different\n> >         listeners optionally also connected to different LB objects.\n> >         For example: users coming from the internal \"private\"\n> >         organization network, have an LB1(private_VIP) -->\n> >         Listener1(HTTP) -->Pool1 and user coming from the \"internet\",\n> >         have LB2(public_vip)-->Listener2(TLS)-->Pool1.\n> >         The LBs may use different flavors as LB2 needs TLS termination\n> >         and may prefer a different \"stronger\" flavor.\n> >         The operator would like to be able to manage the pool\n> >         membership in cases of updates and error in a single place.\n> >         \n> >         3. The same group of servers is being used in several\n> >         different L7_Policies connected to a listener. Such listener\n> >         may be reused as in use case 1.\n> >         For example: LB1(VIP1)-->Listener_L7(TLS)\n> >                                                     |\n> >         \n> >         +-->L7_Policy1(rules..)-->Pool1\n> >                                                     |\n> >         \n> >         +-->L7_Policy2(rules..)-->Pool2\n> >                                                     |\n> >         \n> >         +-->L7_Policy3(rules..)-->Pool1\n> >                                                     |\n> >         \n> >         +-->L7_Policy3(rules..)-->Reject\n> >         \n> >         \n> >         I think that the \"key\" issue handling correctly the\n> >         \"provisioning\" state and the operation state in a many to many\n> >         model.\n> >         This is an issue as we have attached status fields to each and\n> >         every object in the model.\n> >         A side effect of the above is that to understand the\n> >         \"provisioning/operation\" status one needs to check many\n> >         different objects.\n> >         \n> >         To remedy this, I would like to turn all objects besides the\n> >         LB to be logical objects. This means that the only place to\n> >         manage the status/state will be on the LB object.\n> >         Such status should be hierarchical so that logical object\n> >         attached to an LB, would have their status consumed out of the\n> >         LB object itself (in case of an error).\n> >         We also need to discuss how modifications of a logical object\n> >         will be \"rendered\" to the concrete LB objects.\n> >         You may want to revisit\n> >         https://docs.google.com/document/d/1D-1n8nCEFurYzvEBxIRfXfffnImcIPwWSctAG-NXonY/edit#heading=h.3rvy5drl5b5r the \"Logical Model + Provisioning Status + Operation Status + Statistics\" for a somewhat more detailed explanation albeit it uses the LBaaS v1 model as a reference.\n> >         \n> >         Regards,\n> >                 -Sam.\n> >         \n> >         \n> >         \n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> >         \n> >         \n> >         \n> >          \n> >         \n> >         \n> >         --\n> >         \n> >         Stephen Balukoff \n> >         Blue Box Group, LLC \n> >         (800)613-4305 x807\n> >         \n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> > \n> > \n> > \n> > \n> > --\n> > Stephen Balukoff\n> > Blue Box Group, LLC\n> > (800)613-4305 x807\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<F36E8145F2571242A675F56CF60964562895378B@ILMB1.corp.radware.com>',NULL),('<1417739958.2470427.1373554285588.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-11 10:51:25',-14400,'2013-07-11 14:51:25',NULL,'[openstack-dev] The danger of capping python-*clients in core\n projects, and forbidding it in the future','Hi Dirk,\n\n\"Dirk M?ller\" <dirk at dmllr.de> wrote:\n> > Indeed. The whole idea behind a single release channel for python client\n> > libraries was that you should always be running the latest, as they\n> > should drastically enforce backward compatibility.\n> \n> Well, backward compatibility can be tricky when it comes to test.\n> We\'ve for example recently had an issue where the newer keystoneclient\n> broke mocking in tests. It is debateable if tests are part of the\n> backward compatibility or not.\n> \n> See for example https://bugs.launchpad.net/horizon/+bug/1196823\n\nThis is arguably a deficiency of mox, which (apparently?) doesn\'t let us mock properties automatically.\n\n> This is currently also preventing me from being able to get a change\n> on stable/grizzly past gating checks (which stumble on exactly this\n> \"regression\").\n\nThe grizzly backport for the stubs has been merged [0] so patches should be unblocked now.\n\nRegards,\n\nJulie\n\n[0] https://review.openstack.org/#/c/35309/\n\n\n','<CAL5wTH4Yx84N0iA4VDFtFQzTRBVuPMfzcSAnTCnYY_oX=dXHYQ@mail.gmail.com>',NULL),('<1417796378.28080.2.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 11:19:38',-18000,'2014-12-05 16:19:38',NULL,'[openstack-dev] [tripleo] Managing no-mergepy template\n duplication','On Wed, 2014-12-03 at 14:42 +0100, Tomas Sedovic wrote:\n> On 12/03/2014 11:11 AM, Steven Hardy wrote:\n> > Hi all,\n> >\n> > Lately I\'ve been spending more time looking at tripleo and doing some\n> > reviews. I\'m particularly interested in helping the no-mergepy and\n> > subsequent puppet-software-config implementations mature (as well as\n> > improving overcloud updates via heat).\n> >\n> > Since Tomas\'s patch landed[1] to enable --no-mergepy in\n> > tripleo-heat-templates, it\'s become apparent that frequently patches are\n> > submitted which only update overcloud-source.yaml, so I\'ve been trying to\n> > catch these and ask for a corresponding change to e.g controller.yaml.\n> >\n> \n> You beat me to this. Thanks for writing it up!\n> \n> > This raises the following questions:\n> >\n> > 1. Is it reasonable to -1 a patch and ask folks to update in both places?\n> \n> I\'m in favour.\n> \n> > 2. How are we going to handle this duplication and divergence?\n\n\nTo follow this up we are getting in really bad shape with divergence\nalready. I found 3 missing sets of Rabbit, Keystone, and Neutron DVR\nparameters which due to the merge window were properly ported into\novercloud-without-mergepy.yaml yet.\n\nhttps://review.openstack.org/#/c/139649/ (missing Rabbit parameters)\n\nhttps://review.openstack.org/#/c/139656/ (missing Keystone parameters)\n\nhttps://review.openstack.org/#/c/139671/ (missing Neutron DVR\nparameters)\n\nWe need to be very careful at this point not to continue merging things\ninto overcloud-source.yaml which don\'t have the equivalent bits for\novercloud-without-mergepy.yaml.\n\nDan\n\n> \n> I\'m not sure we can. get_file doesn\'t handle structured data and I don\'t \n> know what else we can do. Maybe we could split out all SoftwareConfig \n> resources to separate files (like Dan did in [nova config])? But the \n> SoftwareDeployments, nova servers, etc. have a different structure.\n> \n> [nova config] https://review.openstack.org/#/c/130303/\n> \n> > 3. What\'s the status of getting gating CI on the --no-mergepy templates?\n> \n> Derek, can we add a job that\'s identical to \n> \"check-tripleo-ironic-overcloud-{f20,precise}-nonha\" except it passes \n> \"--no-mergepy\" to devtest.sh?\n> \n> > 4. What barriers exist (now that I\'ve implemented[2] the eliding functionality\n> > requested[3] for ResourceGroup) to moving to the --no-mergepy\n> > implementation by default?\n> \n> I\'m about to post a patch that moves us from ResourceGroup to \n> AutoScalingGroup (for rolling updates), which is going to complicate \n> this a bit.\n> \n> Barring that, I think you\'ve identified all the requirements: CI job, \n> parity between the merge/non-merge templates and a process that \n> maintains it going forward (or puts the old ones in a maintanence-only \n> mode).\n> \n> Anyone have anything else that\'s missing?\n> \n> >\n> > Thanks for any clarification you can provide! :)\n> >\n> > Steve\n> >\n> > [1] https://review.openstack.org/#/c/123100/\n> > [2] https://review.openstack.org/#/c/128365/\n> > [3] https://review.openstack.org/#/c/123713/\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<547F135D.6060805@redhat.com>',NULL),('<1417801839.4046797.199334109.686351C1@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 09:50:39',-28800,'2014-12-05 17:50:39',NULL,'[openstack-dev] Session length on wiki.openstack.org','On Fri, Dec 5, 2014, at 06:26 AM, Jeremy Stanley wrote:\n> On 2014-12-04 18:37:48 -0700 (-0700), Carl Baldwin wrote:\n> > +1  I\'ve been meaning to say something like this but never got\n> > around to it.  Thanks for speaking up.\n> \n> https://storyboard.openstack.org/#!/story/1172753\n> \n> I think Ryan said it might be a bug in the OpenID plug-in, but if so\n> he didn\'t put that comment in the bug.\n> -- \n> Jeremy Stanley\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI dug up an upstream bug for this [0] unfortunately it is quite terse\nand not very helpful. Anyone with existing mediwiki account credentials\nwant to ping that thread and see if we can get more info?\n\n[0]\nhttp://www.mediawiki.org/w/index.php?title=Thread:Extension_talk:OpenID/Is_it_possible_to_change_the_expiration_of_the_session/cookie_for_logged-in_users%3F&lqt_method=thread_history\n\nClark\n\n\n','<20141205142645.GL2497@yuggoth.org>',NULL),('<1417802400-sup-2353@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 10:00:56',-28800,'2014-12-05 18:00:56',NULL,'[openstack-dev] [TripleO] Alternate meeting time','Excerpts from marios\'s message of 2014-12-04 02:40:23 -0800:\n> On 04/12/14 11:40, James Polley wrote:\n> > Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we\'ve\n> > had 10 people respond so far. The winning time so far is Monday 2100UTC\n> > - 7 \"yes\" and one \"If I have to\".\n> \n> for me it currently shows 1200 UTC as the preferred time.\n> \n> So to be clear, we are voting here for the alternate meeting. The\n> \'original\' meeting is at 1900UTC. If in fact 2100UTC ends up being the\n> most popular, what would be the point of an alternating meeting that is\n> only 2 hours apart in time?\n> \n\nActually that\'s a good point. I didn\'t really think about it before I\nvoted, but the regular time is perfect for me, so perhaps I should\nremove my vote, and anyone else who does not need the alternate time\nshould consider doing so as well.\n\n\n','<54803A17.3040403@redhat.com>',NULL),('<1417804955-sup-403@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-05 10:49:20',-28800,'2014-12-05 18:49:20',NULL,'[openstack-dev] [tripleo] Managing no-mergepy template\n	duplication','Excerpts from Steven Hardy\'s message of 2014-12-04 01:09:18 -0800:\n> On Wed, Dec 03, 2014 at 06:54:48PM -0800, Clint Byrum wrote:\n> > Excerpts from Dan Prince\'s message of 2014-12-03 18:35:15 -0800:\n> > > On Wed, 2014-12-03 at 10:11 +0000, Steven Hardy wrote:\n> > > > Hi all,\n> > > > \n> > > > Lately I\'ve been spending more time looking at tripleo and doing some\n> > > > reviews. I\'m particularly interested in helping the no-mergepy and\n> > > > subsequent puppet-software-config implementations mature (as well as\n> > > > improving overcloud updates via heat).\n> > > > \n> > > > Since Tomas\'s patch landed[1] to enable --no-mergepy in\n> > > > tripleo-heat-templates, it\'s become apparent that frequently patches are\n> > > > submitted which only update overcloud-source.yaml, so I\'ve been trying to\n> > > > catch these and ask for a corresponding change to e.g controller.yaml.\n> > > > \n> > > > This raises the following questions:\n> > > > \n> > > > 1. Is it reasonable to -1 a patch and ask folks to update in both places?\n> > > \n> > > Yes! In fact until we abandon merge.py we shouldn\'t land anything that\n> > > doesn\'t make the change in both places. Probably more important to make\n> > > sure things go into the new (no-mergepy) templates though.\n> > > \n> > > > 2. How are we going to handle this duplication and divergence?\n> > > \n> > > Move as quickly as possible to the new without-mergepy varients? That is\n> > > my vote anyways.\n> > > \n> > > > 3. What\'s the status of getting gating CI on the --no-mergepy templates?\n> > > \n> > > Devtest already supports it by simply setting an option (which sets an\n> > > ENV variable). Just need to update tripleo-ci to do that and then make\n> > > the switch.\n> > > \n> > > > 4. What barriers exist (now that I\'ve implemented[2] the eliding functionality\n> > > > requested[3] for ResourceGroup) to moving to the --no-mergepy\n> > > > implementation by default?\n> > > \n> > > None that I know of.\n> > > \n> > \n> > I concur with Dan. Elide was the last reason not to use this.\n> \n> That\'s great news! :)\n> \n> > One thing to consider is that there is no actual upgrade path from\n> > non-autoscaling-group based clouds, to auto-scaling-group based\n> > templates. We should consider how we\'ll do that before making it the\n> > default. So, I suggest we discuss possible upgrade paths and then move\n> > forward with switching one of the CI jobs to using the new templates.\n> \n> This is probably going to be really hard :(\n> \n> The sort of pattern which might work is:\n> \n> 1. Abandon mergepy based stack\n> 2. Have helper script to reformat abandon data into nomergepy based adopt\n> data\n> 3. Adopt stack\n> \n> Unforunately there are several abandon/adopt bugs we\'ll have to fix if we\n> decide this is the way to go (original author hasn\'t maintained it, but we\n> can pick up the slack if it\'s on the critical path for TripleO).\n> \n> An alternative could be the external resource feature Angus is looking at:\n> \n> https://review.openstack.org/#/c/134848/\n> \n> This would be more limited (we just reference rather than manage the\n> existing resources), but potentially safer.\n> \n> The main risk here is import (or subsequent update) operations becoming\n> destructive and replacing things, but I guess to some extent this is a risk\n> with any change to tripleo-heat-templates.\n> \n\nSo you and I talked on IRC, but I want to socialize what we talked about\nmore.\n\nThe abandon/adopt pipeline is a bit broken in Heat and hasn\'t proven to be\nas useful as I\'d hoped when it was first specced out. It seems too broad,\nand relies on any tools understanding how to morph a whole new format\n(the abandon json).\n\nWith external_reference, the external upgrade process just needs to know\nhow to morph the template. So if we\'re combining 8 existing servers into\nan autoscaling group, we just need to know how to make an autoscaling\ngroup with 8 servers as the external reference ids. This is, I think,\nthe shortest path to a working solution, as I feel the external\nreference work in Heat is relatively straight forward and the spec has\nwidescale agreement.\n\nThere was another approach I mentioned, which is that we can teach Heat\nhow to morph resources. So we could teach Heat that servers can be made\ninto autoscaling groups, and vice-versa. This is a whole new feature\nthough, and IMO, something that should be tackled _after_ we make it\nwork with the external_reference feature, as this is basically a\nsuperset of what we\'ll do externally.\n\n> Has any thought been given to upgrade CI testing?  I\'m thinking grenade or\n> grenade-style testing here where we test maintaing a deployed overcloud\n> over an upgrade of (some subset of) changes.\n> \n> I know the upgrade testing thing will be hard, but to me it\'s a key\n> requirement to mature heat-driven updates vs those driven by external\n> tooling.\n\nUpgrade testing is vital to the future of the project IMO. We really\nhaven\'t validated the image based update method upstream yet. In Helion,\nwe\'re using tripleo-ansible for updates, and that works great, but we\nneed to get that or something similar into the pipeline for the gate,\nor every user who adopts will be left with a ton of work if they want\nto do upgrades.\n\nThe approach we\'ve used for testing in Helion is to deploy the new commit,\nthen generate a new image with a new file, and upgrade (thanks JP for your\namazing work on this btw, hopefully we can realize this upstream soon. :)\n\nThat is not ideal though. What we need to do is test upgrading from\nthe last commit to the new one, and arguably, also from the last stable\nrelease to the new commit (ala grenade).\n\n\n','<20141204090918.GA8949@t430slt.redhat.com>',NULL),('<1417BB72064CD64A9E1661172A74A5573FC29E6D@MAIL703.KDS.KEANE.COM>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-27 07:21:24',0,'2014-11-27 07:21:24',NULL,'[Openstack] [Glance][Stable] Review request for stable/icehouse\n	patch','Hello All,\n\nI have submitted a back-port patch to stable/icehouse, for which I\'ve cherry picked https://review.openstack.org/#/c/128301/ and made few additional changes. This is not 1:1 cherry pick from the one that landed to master as the retrying module is not available in the stable/icehouse.\nSo would like stable-maint-core team to review this patch and give their suggestions on the same.\n\nPlease Review: https://review.openstack.org/#/c/130029/\n\nNote:\nThis patch is a bit different as it is not a straightforward cherry-pick from the commit in master, so would like to open discussion on mailing list.\n\nThanks & Regards,\nAnkit Agrawal\n\n\n______________________________________________________________________\nDisclaimer: This email and any attachments are sent in strictest confidence\nfor the sole use of the addressee and may contain legally privileged,\nconfidential, and proprietary data. If you are not the intended recipient,\nplease advise the sender by replying promptly to this email and then delete\nand destroy this email and any attachments without any further use, copying\nor forwarding.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141127/59c99810/attachment.html>\n\n',NULL,NULL),('<1417BB72064CD64A9E1661172A74A5573FC29FD6@MAIL703.KDS.KEANE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-27 07:54:47',0,'2014-11-27 07:54:47',NULL,'[openstack-dev] [Glance][Stable] Review request for stable/icehouse\n	patch','Hello All,\n\nI have submitted a back-port patch to stable/icehouse, for which I\'ve cherry picked https://review.openstack.org/#/c/128301/ and made few additional changes. This is not 1:1 cherry pick from the one that landed to master as the retrying module is not available in the stable/icehouse.\nSo would like stable-maint-core team to review this patch and give their suggestions on the same.\n\nPlease Review: https://review.openstack.org/#/c/130029/\n\nNote:\nThis patch is a bit different as it is not a straightforward cherry-pick from the commit in master, so would like to open discussion on mailing list.\n\nThanks & Regards,\nAnkit Agrawal\n\n______________________________________________________________________\nDisclaimer: This email and any attachments are sent in strictest confidence\nfor the sole use of the addressee and may contain legally privileged,\nconfidential, and proprietary data. If you are not the intended recipient,\nplease advise the sender by replying promptly to this email and then delete\nand destroy this email and any attachments without any further use, copying\nor forwarding.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141127/c44b0679/attachment.html>\n\n',NULL,NULL),('<1417BB72064CD64A9E1661172A74A5573FC4411B@MAIL703.KDS.KEANE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 10:17:03',0,'2015-02-04 10:17:03',NULL,'[openstack-dev] [Nova] log request-id mappings implementation','Hi All,\n\nI have submitted a patch in Nova [1] to log request-id mappings between cross projects which is a prerequisite for cinder-spec \'Return request ID to caller\' [2] to be completed.\n\nThis patch will extract cinder\'s request-id returned from cinder-client\'s response headers and will log it with corresponding nova\'s request id.\nTo log these request-id mappings earlier we were planning to use oslo-incubator\'s \"request_utils\" module based on the patch [3]. Since \"request_utils\" has been removed recently from oslo-incubator [4], I have moved \"link_request_ids\" method from \"request_utils\" to nova utils.\n\n[1] https://review.openstack.org/#/c/152820/\n[2] https://review.openstack.org/#/c/132161/6\n[3] https://review.openstack.org/#/c/69538/\n[4] https://review.openstack.org/#/c/150370/\n\nWe\'ve also submitted a cinder-client patch to return request-id which is under review.\ncinder-client patch: https://review.openstack.org/#/c/152075/\n\nI am seeking early feedback from the community for the approach I am using so please let me know your opinions on the same.\n\nThanks & Regards,\nAnkit Agrawal\n\n______________________________________________________________________\nDisclaimer: This email and any attachments are sent in strictest confidence\nfor the sole use of the addressee and may contain legally privileged,\nconfidential, and proprietary data. If you are not the intended recipient,\nplease advise the sender by replying promptly to this email and then delete\nand destroy this email and any attachments without any further use, copying\nor forwarding.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150204/6adb4404/attachment.html>\n\n',NULL,NULL),('<1417BB72064CD64A9E1661172A74A5579874E7@MAIL703.KDS.KEANE.COM>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-25 15:43:37',0,'2014-06-25 15:43:37',NULL,'[openstack-dev] [Nova] 0 byte image is created with instance\n snapshot if instance is booted using volume','Hi All,\n\nWhen I boot an instance from volume and the take snapshot of that instance it creates a volume snapshot and also an image of 0 byte.\nI can boot a new instance using this 0 byte image, but I am not sure why this image with 0 byte is created here?\n\nCan someone please help me to understand this.\n\nThanks,\nAnkit Agrawal\n\n______________________________________________________________________\nDisclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/43271e0e/attachment.html>\n\n',NULL,NULL),('<1417fe9be18.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 13:02:09',-25200,'2013-10-03 20:02:09',NULL,'[openstack-dev] [nova] RFC: adding \"on_shared_storage\" field to\n	instance','\n\nOn October 3, 2013 12:44:50 PM Chris Friesen <chris.friesen at windriver.com> \nwrote:\n>\n> I was wondering if there is any interest in adding an \"on_shared_storage\" \n> field to the Instance class.  This would be set once at instance creation \n> time and we would then be able to avoid having the admin manually pass it \n> in for the various API calls (evacuate/rebuild_instance/migration/etc.)\n>\n> It could even be set automatically for the case of booting off block \n> storage, and maybe we add a config flag indicating that a given compute \n> node is using shared storage for its instances.\n>\n> This would also allow for \"nova host-evacuate\" to work properly if some of \n> the instances are on unshared storage and some are booting from block \n> storage (which is shared).  As it stands, the host-evacuate command assumes \n> that they\'re all the same.\n>\n> Thoughts?\n>\n> Chris\n\n*What* is on shared storage?\n\nThe boot drive?\nA snapshot of the running VM?\n\n\n\n\n','<524DC932.1060700@windriver.com>',NULL),('<1418040006.4540.7.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-08 13:00:06',3600,'2014-12-08 12:00:06',NULL,'[Openstack] Openstack Network Architecture with two ethernet\n card possible with Neutron Network?','In a few words: \n\nThe tenant network is the software defined network you can create in the\nnetwork tab of the horizon dashboard. There could be a couple of them.\nThis is where you connect your instances to.\n\nThe logical networks (tenant networks) somehow have to map to the\nnetwork physics. Therfore there are several virtualization technologies\navailable in Openstack: VLAN, VXLAN, GRE. So a tenant network is an\nopenstack construct that is always (to be more preceise: in most cases)\nmapped to a virtual network in your physics. When having a look at\nopenstack network charts, the pyhsical network used for tenant networks\nis the \"data network\". \n\nHope that helps\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Fri, 2014-12-05 at 16:36 +0530, dhanesh1212121212 wrote:\n> Hi All,\n> \n> \n> Above Minimal architecture example for Openstack networking shows\n> three different networks.\n> \n> \n> External Network is to Access the VM\'s from OUTSIDE the Network.\n> \n> \n> Management to Configure Openstack services\n> \n> \n> Storage to communicate.\n> \n> \n> can somebody explain me what is the concept of tenant network.\n> \n> \n> \n> Regards,\n> \n> Dhanesh M.\n> \n> \n> \n> On Thu, Dec 4, 2014 at 10:52 AM, dhanesh1212121212\n> <dhanesh1212 at gmail.com> wrote:\n>         Hi All,\n>         \n>         \n>         \n>         In openstack Docs for Juno the \"Minimal architecture example\n>         for Openstack networking shows the below.\n>         \n>         \n>         1. Controller one ethernet card with network ( 10.0.0.0 )\n>         \n>         \n>         2. Network Node with three ethernet card ( 10.0.0.0\n>         (management), 10.0.1.0 (Tunnel network), 203.0.113.0\n>         (unnumbered external network) )\n>         \n>         \n>         3. Compute Node with three ethernet card ( 10.0.0.0\n>         (management), 10.0.1.0 (Tunnel network), 10.0.2.0 (storage\n>         network).\n>         \n>         \n>         4. Block storage with  two ethernet card ( 10.0.0.0\n>         (management), 10.0.2.0 (storage network).\n>         \n>         \n>         5. Object storage with two ethernet card ( 10.0.0.0\n>         (management), 10.0.2.0 (storage network).\n>         \n>         \n>         Please guide me to configure the same neutron network with two\n>         ethernet card and two\n>          machines.\n>         \n>         \n>         Example:\n>         \n>         First machine\n>         \n>         \n>         Controller + Block storage + object storage\n>         \n>         \n>         \n>          Second Machine\n>         \n>         \n>         Compute Node + Network Node\n>         \n>         \n>         \n>         Regards,\n>         \n>         Dhanesh M\n>         8056229570\n>         \n>         \n>         \n>         \n>         \n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<CAA0wu4eaOMpFd+TrNCKXPcWzZjFsKH60eFzTp2U1Cq3kW6ChzQ@mail.gmail.com>',NULL),('<1418050120681.46696@persistent.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-08 14:41:55',0,'2014-12-08 14:41:55',NULL,'[openstack-dev] [Mistral] Query on creating multiple resources','Hello All,\n\n\nCan we create multiple resources using a single task, like multiple keypairs or security-groups or networks etc?\n\n\nI am trying to extend the existing \"create_vm\" workflow, such that it accepts a list of security groups. In the workflow, before create_vm I am trying to create the security group if it does not exist.\n\n\nJust to test the security group functionality individually I wrote a sample workflow:\n\n--------------------\n\nversion: \'2.0\'\n\nname: secgroup_actions\n\nworkflows:\n  create_security_group:\n    type: direct\n    input:\n      - name\n      - description\n\n    tasks:\n      create_secgroups:\n        action: nova.security_groups_create name={$.name} description={$.description}\n------------\n\nThis is a straight forward workflow, but I am unable figure out how to pass multiple security groups to the above workflow.\n\nI tried passing multiple dicts in context file but it did not work.\n\n------\n\n{\n  \"name\": \"secgrp1\",\n  \"description\": \"using mistral\"\n},\n{\n  \"name\": \"secgrp2\",\n  \"description\": \"using mistral\"\n}\n\n-----\n\nIs there any way to modify this workflow such that it creates more than one security group?\n\nPlease help.\n\n\nRegards,\n\nSushma\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141208/61582e39/attachment.html>\n\n','<1418048476946.19042@persistent.com>',NULL),('<1418058695.6209.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-08 11:11:35',-21600,'2014-12-08 17:11:35',NULL,'[openstack-dev] [api] Using query string or request body to\n pass parameter','On Mon, 2014-12-08 at 14:07 +0800, Eli Qiao wrote:\n> I wonder if we can use body in delete, currently , there isn\'t any\n> case used in v2/v3 api.\n\nNo, many frameworks raise an error if you try to include a body with a\nDELETE request.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<54854039.3030405@linux.vnet.ibm.com>',NULL),('<1418083127.6209.11.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-08 17:58:47',-21600,'2014-12-08 23:58:47',NULL,'[openstack-dev] [api] Using query string or request body to\n pass parameter','On Tue, 2014-12-09 at 07:38 +0800, Alex Xu wrote:\n> Not sure all, nova is limited\n> at https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L79\n> That under our control.\n\nIt is, but the client frameworks aren\'t, and some of them prohibit\nsending a body with a DELETE request.  Further, RFC7231 has this to say\nabout DELETE request bodies:\n\n        A payload within a DELETE request message has no defined semantics;\n        sending a payload body on a DELETE request might cause some existing\n        implementations to reject the request.\n\n(?4.3.5)\n\nI think we have to conclude that, if we need a request body, we cannot\nuse the DELETE method.  We can modify the operation, such as setting a\n\"force\" flag, with a query parameter on the URI, but a request body\nshould be considered out of bounds with respect to DELETE.\n\n> Maybe not just ask question for delete, also for other method.\n> \n> 2014-12-09 1:11 GMT+08:00 Kevin L. Mitchell <kevin.mitchell at rackspace.com>:\n>         On Mon, 2014-12-08 at 14:07 +0800, Eli Qiao wrote:\n>         > I wonder if we can use body in delete, currently , there isn\'t any\n>         > case used in v2/v3 api.\n>         \n>         No, many frameworks raise an error if you try to include a body with a\n>         DELETE request.\n>         --\n>         Kevin L. Mitchell <kevin.mitchell at rackspace.com>\n>         Rackspace\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAH7mGatP=+CFvL8cDiSBfZ4i-KshX6x36N_oSjL_4kpMbcB3ig@mail.gmail.com>',NULL),('<1418101615-sup-6563@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-08 21:46:26',-28800,'2014-12-09 05:46:26',NULL,'[Openstack] Technical advantages of Openstack over Cloudstack','Excerpts from Jay Pipes\'s message of 2014-12-08 13:52:38 -0800:\n> Hi Jordi, thank you SO much for this email. It is excellent feedback for \n> our community and our developers. I\'ve provided some comments inline, \n> but overall just wanted to thank you for bringing some of these product \n> needs to our attention.\n> \n> On 12/03/2014 01:42 PM, Jordi Moles Blanco wrote:\n> > And that\'s why I\'m asking you as Openstack experts. You see, I managed\n> > to deploy a Cloustack 4.4.1 platform with 2 compute nodes (for\n> > live-migration testing) in less than 2 hours, while it took me days to\n> > deploy an Openstack infrastructure that was functional and sometimes it\n> > just breaks and I have to reboot some nodes or redeploy with Fuel.\n> \n> This is an extremely common complaint about OpenStack. That it is just \n> too difficult to install and configure a simple OpenStack environment \n> with common compute, block storage, and networking functionality.\n> \n> I could sit here and say that this problem is due to the fact that \n> OpenStack\'s community has embraced each and every configuration \n> management system, deployment architecture, and package management \n> platform and therefore the complexity you find is simply due to the \n> dizzying array of options and flexibility offered by the ecosystem.\n> \n> But, of course, that would be a complete cop-out and terrible excuse. \n> The fact is, our installation and deployment story is currently overly \n> complicated, inconsistently documented, and difficult for newcomers to \n> get their heads around. That needs to be fixed.\n> \n\nWe\'ve at least decided, in spirit, to provide a single mission for\nautomated Deployment using OpenStack itself. HP is even shipping a\nproduct, Helion, that uses it.\n\nTurns out this isn\'t the easiest thing in the world. OpenStack is a\nservice oriented architecture, and making a _generic_ deployment tool,\neven just focusing on the default configurations, is a challenge with\nsuch a flexible architecture.\n\nKeep your eyes on the Tuskar space. It is intended to be a nice GUI for\nplanning and deploying OpenStack. That, combined with a more generally\nconsumable Deployment program, should have us in much better shape soon.\n\n\n','<54861DA6.4010304@gmail.com>',NULL),('<1418104273303.62515@persistent.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 05:44:28',0,'2014-12-09 05:44:28',NULL,'[openstack-dev] [Mistral] Query on creating multiple resources','Hello All,\n\n\nCan we create multiple resources using a single task, like multiple keypairs or security-groups or networks etc?\n\n\nI am trying to extend the existing \"create_vm\" workflow, such that it accepts a list of security groups. In the workflow, before create_vm I am trying to create the security group if it does not exist.\n\n\nJust to test the security group functionality individually I wrote a sample workflow:\n\n--------------------\n\nversion: \'2.0\'\n\nname: secgroup_actions\n\nworkflows:\n  create_security_group:\n    type: direct\n    input:\n      - name\n      - description\n\n    tasks:\n      create_secgroups:\n        action: nova.security_groups_create name={$.name} description={$.description}\n------------\n\nThis is a straight forward workflow, but I am unable figure out how to pass multiple security groups to the above workflow.\n\nI tried passing multiple dicts in context file but it did not work.\n\n------\n\n{\n  \"name\": \"secgrp1\",\n  \"description\": \"using mistral\"\n},\n{\n  \"name\": \"secgrp2\",\n  \"description\": \"using mistral\"\n}\n\n-----\n\nIs there any way to modify this workflow such that it creates more than one security group?\n\nPlease help.\n\n\nRegards,\n\nSushma\n\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/46b3f14a/attachment.html>\n\n','<1418050120681.46696@persistent.com>',NULL),('<1418105060569.62922@persistent.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 05:57:35',0,'2014-12-09 05:57:35',NULL,'[openstack-dev]  [Mistral] Query on creating multiple resources','\nHi,\n\n\nThank you guys.\n\n\nYes I am able to do this with heat, but I faced issues while trying the same with mistral.\n\nAs suggested will try with the latest mistral branch. Thank you once again.\n\n\nRegards,\n\nSushma\n\n\n________________________________\n\n\nFrom: Georgy Okrokvertskhov [mailto:gokrokvertskhov at mirantis.com]\nSent: Tuesday, December 09, 2014 6:07 AM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [Mistral] Query on creating multiple resources\n\nHi Sushma,\n\nDid you explore Heat templates? As Zane mentioned you can do this via Heat template without writing any workflows.\nDo you have any specific use cases which you can\'t solve with Heat template?\n\nCreate VM workflow was a demo example. Mistral potentially can be used by Heat or other orchestration tools to do actual interaction with API, but for user it might be easier to use Heat functionality.\n\nThanks,\nGeorgy\n\nOn Mon, Dec 8, 2014 at 7:54 AM, Nikolay Makhotkin <nmakhotkin at mirantis.com<mailto:nmakhotkin at mirantis.com>> wrote:\nHi, Sushma!\nCan we create multiple resources using a single task, like multiple keypairs or security-groups or networks etc?\n\nYes, we can. This feature is in the development now and it is considered as experimental - https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections\n\nJust clone the last master branch from mistral.\n\nYou can specify \"for-each\" task property and provide the array of data to your workflow:\n\n --------------------\n\nversion: \'2.0\'\n\nname: secgroup_actions\n\nworkflows:\n  create_security_group:\n    type: direct\n    input:\n      - array_with_names_and_descriptions\n\n    tasks:\n      create_secgroups:\n\n        for-each:\n\n          data: $.array_with_names_and_descriptions\n        action: nova.security_groups_create name={$.data.name<http://data.name>} description={$.data.description}\n------------\n\nOn Mon, Dec 8, 2014 at 6:36 PM, Zane Bitter <zbitter at redhat.com<mailto:zbitter at redhat.com>> wrote:\nOn 08/12/14 09:41, Sushma Korati wrote:\nCan we create multiple resources using a single task, like multiple\nkeypairs or security-groups or networks etc?\n\nDefine them in a Heat template and create the Heat stack as a single task.\n\n- ZB\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nBest Regards,\nNikolay\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nGeorgy Okrokvertskhov\nArchitect,\nOpenStack Platform Products,\nMirantis\nhttp://www.mirantis.com<http://www.mirantis.com/>\nTel. +1 650 963 9828\nMob. +1 650 996 3284\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/420872fd/attachment.html>\n\n','<SINPR04MB011E730E41861D744DB556286650@SINPR04MB011.apcprd04.prod.outlook.com>',NULL),('<1418122385.31992.74.camel@linode2.nicolast.be>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 11:53:05',3600,'2014-12-09 10:53:05',NULL,'[openstack-dev] People of OpenStack (and their IRC nicks)','On Tue, 2014-12-09 at 10:46 +0000, Matthew Gilliard wrote:\n> can we autogenerate it somehow?\n\nMaybe some \'irc_nick\' field in Stackalytic\'s default_data.json could be\nadded and used to populate such page?\n\nNicolas\n\n\n\n','<CAEWajFN7Zfk8CJ=HxrxWgmvuBkDuHE0TurQmE3UmmUHSaK8Kzg@mail.gmail.com>',NULL),('<1418144281.4233.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 10:58:01',-21600,'2014-12-09 16:58:01',NULL,'[openstack-dev] [hacking] proposed rules drop for 1.0','On Tue, 2014-12-09 at 10:05 -0500, Sean Dague wrote:\n> Sure, the H8* group is git commit messages. It\'s checking for line\n> length in the commit message.\n\nI agree the H8* group should be dropped.  It would be appropriate to\ncreate a new gate check job that validated that, but it should not be\npart of hacking.\n\n> H3* are all the module import rules:\n> \n> Imports\n> -------\n> - [H302] Do not import objects, only modules (*)\n> - [H301] Do not import more than one module per line (*)\n> - [H303] Do not use wildcard ``*`` import (*)\n> - [H304] Do not make relative imports\n> - Order your imports by the full module path\n> - [H305 H306 H307] Organize your imports according to the `Import order\n>   template`_ and `Real-world Import Order Examples`_ below.\n> \n> I think these remain reasonable guidelines, but H302 is exceptionally\n> tricky to get right, and we keep not getting it right.\n> \n> H305-307 are actually impossible to get right. Things come in and out of\n> stdlib in python all the time.\n> \n> \n> I think it\'s time to just decide to be reasonable Humans and that these\n> are guidelines.\n> \n> The H3* set of rules is also why you have to install *all* of\n> requirements.txt and test-requirements.txt in your pep8 tox target,\n> because H302 actually inspects the sys.modules to attempt to figure out\n> if things are correct.\n\nI agree that dropping H302 and the grouping checks makes sense.  I think\nwe should keep the H301, H303, H304, and the basic ordering checks,\nhowever; it doesn\'t seem to me that these would be that difficult to\nimplement or maintain.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<54870FCC.3010006@dague.net>',NULL),('<1418145653.4233.14.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 11:20:53',-21600,'2014-12-09 17:20:53',NULL,'[openstack-dev] [hacking] proposed rules drop for 1.0','On Tue, 2014-12-09 at 12:05 -0500, Sean Dague wrote:\n> > I agree that dropping H302 and the grouping checks makes sense.  I\n> think\n> > we should keep the H301, H303, H304, and the basic ordering checks,\n> > however; it doesn\'t seem to me that these would be that difficult to\n> > implement or maintain.\n> \n> Well, be careful what you think is easy -\n> https://github.com/openstack-dev/hacking/blob/master/hacking/checks/imports.py\n> :)\n\nSo, hacking_import_rules() is very complex.  However, it implements H302\nas well as H301, H303, and H304.  I feel it can be simplified to just a\ntextual match rule if we remove the H302 implementation: H301 just needs\nto exclude imports with \',\', H303 needs to exclude imports with \'*\', and\nH304 is already implemented as a regular expression match.  It looks\nlike the basic ordering check I was referring to is H306, which isn\'t\nall that complicated.  It seems like the rest of the code is related to\nthe checks which I just agreed should be dropped :)  Am I missing\nanything?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<54872BDC.5070407@dague.net>',NULL),('<1418149486-sup-3128@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 10:34:24',-28800,'2014-12-09 18:34:24',NULL,'[openstack-dev] [Ironic] Fuel agent proposal','Excerpts from Yuriy Zveryanskyy\'s message of 2014-12-09 04:05:03 -0800:\n> Good day Ironicers.\n> \n> I do not want to discuss questions like \"Is feature X good for release \n> Y?\" or \"Is feature Z in Ironic scope or not?\".\n> I want to get an answer for this: Is Ironic a flexible, easy extendable \n> and user-oriented solution for deployment?\n\nI surely hope it is.\n\n> Yes, it is I think. IPA is the great software, but Fuel Agent proposes a \n> different and alternative way for deploying.\n\nIt\'s not fundamentally different, it is just capable of other things.\n\n> Devananda wrote about \"pets\" and \"cattle\", and maybe some want to manage \n> \"pets\" rather than \"cattle\"? Let\n> users do a choice.\n\nIMO this is too high-level of a discussion for Ironic to get bogged\ndown in. Disks can have partitions and be hosted in RAID controllers,\nand these things _MUST_ come before an OS is put on the disks, but after\npower control happens. Since Ironic does put OS\'s on disks, and control\npower, I believe it is obligated to provide an interface for rich disk\nconfiguration.\n\nThere are valid use cases for _both_ of those things in \"cattle\", which\nis a higher level problem that should not cloud the low level interface\ndiscussion.\n\nSo IMO, Ironic needs to provide an interface for agents to richly\nconfigure disks, whether IPA supports it or not.\n\nWould I like to see these things in IPA so that there isn\'t a mismatch\nof features? Yes. Does that matter _now_? Not really. The FuelAgent can\nprove out the interface while the features migrate into IPA.\n\n> We do not plan to change any Ironic API for the driver, internal or \n> external (as opposed to IPA, this was done for it).\n> If there will be no one for Fuel Agent\'s driver support I think this \n> driver should be removed from Ironic tree (I heard\n> this practice is used in Linux kernel).\n> \n\nWe have a _hyperv_ driver in Nova.. I think we can have a \"something\nwe\'re not entirely 100% on board with\" in Ironic.\n\nAll of that said, I would admonish FuelAgent developers to work to\ncommit to combine their agent with IPA long term. I would admonish Ironic\ndevelopers to be receptive to things that users want. It doesn\'t always\nmean taking responsibility for implementations, but you _do_ need to\nconsider the pain of not providing interfaces and of forcing people to\nremain out of tree (remember when Ironic\'s driver wasn\'t in Nova\'s tree?)\n\n\n','<5486E56F.9060606@mirantis.com>',NULL),('<1418156598.4233.21.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 14:23:18',-21600,'2014-12-09 20:23:18',NULL,'[openstack-dev] [hacking] proposed rules drop for 1.0','On Tue, 2014-12-09 at 13:46 -0500, Sean Dague wrote:\n> Yes, the following fails H305 and H306.\n> \n> nova/tests/fixtures.py\n> \n> \"\"\"Fixtures for Nova tests.\"\"\"\n> from __future__ import absolute_import\n> \n> import gettext\n> import logging\n> import os\n> import uuid\n> \n> import fixtures\n> from oslo.config import cfg\n> \n> from nova.db import migration\n> from nova.db.sqlalchemy import api as session\n> from nova import service\n> \n> \n> Because name normalization is hard (fixtures is normalized to\n> nova.tests.fixtures so H305 thinks it should be in group 3, and H306\n> thinks it should be after oslo.config import cfg).\n> \n> To sort things you have to normalize them.\n\nI agree you have to normalize imports to sort them, but to my mind the\nappropriate normalization here is purely textual; we shouldn\'t be\nexpecting any relative imports (and should raise an error if there are\nany).  Still, that does show that some work needs to be done to the\nsimpler H306 test (probably involving changes to the core import\nnormalization)?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<5487438C.2010504@dague.net>',NULL),('<1418169303-sup-199@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 15:56:28',-28800,'2014-12-09 23:56:28',NULL,'[openstack-dev] People of OpenStack (and their IRC nicks)','Excerpts from Angus Salkeld\'s message of 2014-12-09 15:25:59 -0800:\n> On Wed, Dec 10, 2014 at 5:11 AM, Stefano Maffulli <stefano at openstack.org>\n> wrote:\n> \n> > On 12/09/2014 06:04 AM, Jeremy Stanley wrote:\n> > > We already have a solution for tracking the contributor->IRC\n> > > mapping--add it to your Foundation Member Profile. For example, mine\n> > > is in there already:\n> > >\n> > >     http://www.openstack.org/community/members/profile/5479\n> >\n> > I recommend updating the openstack.org member profile and add IRC\n> > nickname there (and while you\'re there, update your affiliation history).\n> >\n> > There is also a search engine on:\n> >\n> > http://www.openstack.org/community/members/\n> >\n> >\n> Except that info doesn\'t appear nicely in review. Some people put their\n> nick in their \"Full Name\" in\n> gerrit. Hopefully Clint doesn\'t mind:\n> \n> https://review.openstack.org/#/q/owner:%22Clint+%27SpamapS%27+Byrum%22+status:open,n,z\n> \n\nIndeed, I really didn\'t like that I\'d be reviewing somebody\'s change,\nand talking to them on IRC, and not know if they knew who I was.\n\nIt also has the odd side effect that gerritbot triggers my IRC filters\nwhen I \'git review\'.\n\n\n','<CAA16xcy87RyF-pAhNU3DcAoiKrJYK55EQgGBsOhJP5Ff04prqg@mail.gmail.com>',NULL),('<1418190532.10125.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-10 05:48:52',0,'2014-12-10 05:48:52',NULL,'[openstack-dev] [neutron][lbaas] Kilo Midcycle Meetup','It\'s set.  We\'ll be having the meetup on Feb 2-6 in San Antonio at RAX\nHQ.  I\'ll add a list of hotels and the address on the etherpad.\n\nhttps://etherpad.openstack.org/p/lbaas-kilo-meetup\n\nThanks,\nBrandon\n\nOn Tue, 2014-12-02 at 17:27 +0000, Brandon Logan wrote:\n> Per the meeting, put together an etherpad here:\n> \n> https://etherpad.openstack.org/p/lbaas-kilo-meetup\n> \n> I would like to get the location and dates finalized ASAP (preferrably\n> the next couple of days).\n> \n> We\'ll also try to do the same as the neutron and octava meetups for\n> remote attendees.\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1417541257.4057.1.camel@localhost>',NULL),('<1418231671-sup-7546@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-10 09:15:41',-28800,'2014-12-10 17:15:41',NULL,'[openstack-dev] [TripleO] mid-cycle details final draft','Just FYI, we ran into a last minute scheduling conflict with the venue\nand are sorting it out, so please _do not book travel yet_. Worst case\nit will move to Feb 16 - 18 instead of 18 - 20.\n\nExcerpts from Clint Byrum\'s message of 2014-12-01 14:58:58 -0800:\n> Hello! I\'ve received confirmation that our venue, the HP offices in\n> downtown Seattle, will be available for the most-often-preferred\n> least-often-cannot week of Feb 16 - 20.\n> \n> Our venue has a maximum of 20 participants, but I only have 16 possible\n> attendees now. Please add yourself to that list _now_ if you will be\n> joining us.\n> \n> I\'ve asked our office staff to confirm Feb 18 - 20 (Wed-Fri). When they\n> do, I will reply to this thread to let everyone know so you can all\n> start to book travel. See the etherpad for travel details.\n> \n> https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n\n\n','<1417474177-sup-8420@fewbar.com>',NULL),('<1418247379.1887051.201395737.3992C87F@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-10 13:36:19',-28800,'2014-12-10 21:36:19',NULL,'[openstack-dev] [TripleO] Bug Squashing Day','A couple weeks ago we discussed having a bug squash day. AFAICT we all\nforgot, and we still have a huge bug backlog. I\'d like to propose we\nmake next Wed. (12/17, in whatever 24 window is Wed. in your time zone)\na bug squashing day. Hopefully we can add this as an item to our weekly\nmeeting on Tues. to help remind everyone the day before.\n\nCheers,\nGreg\n\n-- \n  Gregory Haynes\n  greg at greghaynes.net\n\n\n',NULL,NULL),('<1418316933.5473.11.camel@aleeredhat.laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-11 11:55:33',-18000,'2014-12-11 16:55:33',NULL,'[openstack-dev] [barbican] PKCS#11 configuration','Which HSM do you have?\n\nOn Thu, 2014-12-11 at 07:24 -0800, Ivan Wallis wrote:\n> Hi,\n> \n> \n> I am trying to configure Barbican with an external HSM that has a\n> PKCS#11 provider and just wondering if someone can point me in the\n> right direction on how to configure this type of environment?\n> \n> \n> Regards,\n> Ivan\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<CAEqbhqspVrLQbiX5xsERTTJ0_rN9k9X3dR+vkUp9GzuFBBo=nA@mail.gmail.com>',NULL),('<1418342649-sup-7892@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-11 16:23:53',-28800,'2014-12-12 00:23:53',NULL,'[openstack-dev] [Neutron] UniqueConstraint for name and\n	tenant_id in security group','Excerpts from Jay Pipes\'s message of 2014-12-11 05:43:46 -0800:\n> On 12/11/2014 07:22 AM, Anna Kamyshnikova wrote:\n> > Hello everyone!\n> >\n> > In neutron there is a rather old bug [1] about adding uniqueness for\n> > security group name and tenant id. I found this idea reasonable and\n> > started working on fix for this bug [2]. I think it is good to add a\n> > uniqueconstraint because:\n> >\n> > 1) In nova there is such constraint for security groups\n> > https://github.com/openstack/nova/blob/stable/juno/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#L1155-L1157.\n> > So I think that it is rather disruptive that it is impossible to create\n> > security group with the same name in nova, but possible in neutron.\n> > 2) Users get confused having security groups with the same name.\n> >\n> > In comment for proposed change Assaf Muller and Maru Newby object for\n> > such solution and suggested another option, so I think we need more eyes\n> > on this change.\n> >\n> > I would like to ask you to share your thoughts on this topic.\n> > [1] - https://bugs.launchpad.net/neutron/+bug/1194579\n> > [2] - https://review.openstack.org/135006\n> \n> I\'m generally in favor of making name attributes opaque, utf-8 strings \n> that are entirely user-defined and have no constraints on them. I \n> consider the name to be just a tag that the user places on some \n> resource. It is the resource\'s ID that is unique.\n> \n> I do realize that Nova takes a different approach to *some* resources, \n> including the security group name.\n> \n> End of the day, it\'s probably just a personal preference whether names \n> should be unique to a tenant/user or not.\n> \n\nThe problem with this approach is that it requires the user to have an\nexternal mechanism to achieve idempotency. By allowing an opaque string\nthat the user submits to you to be guaranteed to be unique, you allow\nthe user to write \"dumber\" code around creation in an unreliable\nfashion. So instead of\n\n\nwhile True:\n  try:\n    item = clientlib.find(name=\'foo\')[0]\n    break\n  except NotFound:\n    try:\n      item = clientlib.create(name=\'foo\')\n      break\n    except UniqueConflict:\n      item = clientlib.find(name=\'foo\')[0]\n      break\n\nYou can keep retrying forever because you know only one thing with that\nname will ever exist.\n\nWithout unique names, you have to write weird stuff like this to do a\nretry.\n\nwhile len(clientlib.find(name=\'foo\')) < 1:\n  try:\n    item = clientlib.create(name=\'foo\')\n    list = clientlib.searchfor(name=\'foo\')\n    for found_item in list:\n      if found_item.id != item.id:\n        clientlib.delete(found_item.id)\n\nName can certainly remain not-unique and free-form, but don\'t discount\nthe value of a unique value that the user specifies.\n\n\n','<54899F92.2060900@gmail.com>',NULL),('<1418535117.10675.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-14 05:31:57',0,'2014-12-14 05:31:57',NULL,'[openstack-dev] [neutron][vpnaas] Working on unit tests...','Paul,\nIt looks like you put that method call in all the right places.  You\nwould know if you didn\'t, because the unit tests would fail bc of the\npolicy.json.  \n\nNot sure on the tempests tests.  I\'m sure Doug and Kyle know more about\nthat, so hopefully they can chime in.\n\nThanks,\nBrandon\n\nOn Sat, 2014-12-13 at 19:06 +0000, Paul Michali (pcm) wrote:\n> For the new VPNaaS repo, I have\n> created https://review.openstack.org/#/c/141532/ to move the tests\n> from tests.skip and modify the imports. This has Brandon?s change to\n> setup policy.json, and Ihar?s one-liner for moving get_admin_context()\n> in one test (should we upstream his, and I rebase mine?).\n> \n> \n> Please look it over, as I?m not sure if I put the override_nvalues()\n> calls in the right places or not.\n> \n> \n> It passes unit tests in Jenkins. The Tempest tests all fail. Is that\n> expected? What?s the plan for functional and tempest tests with these\n> other repos?\n> \n> \n> Thanks!\n> \n> \n> \n> \n> PCM (Paul Michali)\n> \n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pc_m (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<B66FCB43-151D-4048-956A-1EF4C1ED7005@cisco.com>',NULL),('<1418581324.6578.0@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 19:22:04',3600,'2014-12-14 18:22:04',NULL,'[Openstack] VM lose connectivity if created new. Have to restart\n neutron-plugin-openvswitch-agent','Hi all, \n\nQuestion is. Why I have to restart neutron-plugin-openvswitch-agent to \nrecover networking from new machines?\n\n\nI found a problem creating machines in a new node I\'ve built. And \nrealized that this happens on all my nodes of current version. \n\nneutron 2.3.4\nnova      2.17.0\n\nMy logs shows that neutron assign vlan 2 for the new machine and this \ncauses the machine to not have connectivity. \n\n---------------------------------------\n2014-12-14 17:57:07.321 12501 INFO \nneutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Assigning 2 as \nlocal vlan for net-id=727b0415-f066-40d9-8147-183e07dd7b23\n20\n---------------------------------------\n\n\nIf I shut down the machine and restart neutron plugin agent for ovs:\n\n#> restart neutron-plugin-openvswitch-agent\n\n\n---------------------------------------\n ...  assigning 1 as local vlan for \nnet-id=727b0415-f066-40d9-8147-183e07dd7b23\n\n---------------------------------------\n\n\nAnd the machine recovers connectivity. \n\nIn the even of faillure (after creating it):\n\nIf I start the machine without ip and set it manually I can try to ping \nit. It says it\'s not reachable but after restating the plugin \nautomatically recovers connectivity. So no restart or further \nconfiguration is made. \n\n\nMaybe I have something wrong configured but it seems like a bug.\n\n\nCan someone point me to the right place?\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/b1d812bc/attachment.html>\n\n',NULL,NULL),('<1418582201.6578.1@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 19:36:41',3600,'2014-12-14 18:36:41',NULL,'[Openstack] What\'s physical network for?','Hi all, \n\nI\'m installing a new compute node from scratch and reviewing all old \nconfig. I\'ve found two setting that seems equal, one in ml2 plugin and \none in openvswitch.\n\nBut I don\'t really understand why they are.\n\novs_neutron_plugin.ini:\n	bridge_mappings = default:br0,extnet1:br-ex\n\n\nml2/ml2_conf.ini:\n[ovs]\nbridge_mappings = default:br0,extnet1:br-ex\n\n\nFor me it\'s strange the settings are in both places. I think this is a \nresult of upgrading without taking much care of removing old config.\n\n\n But also it\'s strange that everything works with the bridges br0 and \nbr-ex without physical interface. I mean, seems to do nothing but it \nneeds to be there.  \nAlso I should expect VM be attached to br0 (Default) but it\'s not, they \nare attached to the br-int (integration bridge), for me this is \ncorrect. Since it\'s described here like this:\n\nhttps://openstack.redhat.com/Networking_in_too_much_detail\n\nAnd works ok. \n\nSo what\'s the purporse of these bridges?\n\nHere is:\n\nneutron 2.3.4\nnova      2.17.0\n\nBest regards,\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/6d75415a/attachment.html>\n\n',NULL,NULL),('<1418586921.6578.2@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 20:55:21',3600,'2014-12-14 19:55:21',NULL,'[Openstack] What\'s physical network for?','Hi Uwe, \n\nreally I started directly with neutron. Never gone with legacy. \n\nBut I suppose there\'s old config laying around. I still think that \nbridge_mapping is needed for VLAN config I use. Every paper describes \nGRE config, but I still feel more confortable using VLANs.\n\nAny other help about this issue? Can someone confirm if I can get rid \nof the directives in both configs?\n\nI suppose I cannot because they get in effect when started the ovs \nplugin.\n\nThank you in advance.\n\n\n\nEl dom, 14 de dic 2014 a las 8:40 , Uwe Sauter \n<uwe.sauter.de at gmail.com> escribi?:\n> Hi,\n> \n> I presume that you upgraded from an older version that used \n> nova-network\n> (now called legacy networking).\n> \n> Using neutron means that VMs aren\'t connected to br0 directly any more\n> as there is a whole virtual networking infrastructure in place.\n> \n> To give a small overview:\n> \n> On a compute node a VM connects to br-int (integration bridge). This\n> bridge itself is connected through a virtual cable to br-tun \n> (tunneling\n> bridge). That bridge has also assigned a physical interface that \n> allows\n> traffic to flow to the network node\n> \n> On the network node there also exists a br-tun that has a physical\n> interface attached. Through this inferface traffic enters the node.\n> br-tun is virtually connected to br-ex that has a separate physical\n> interface attached that connects to \"the outside\", meaning the\n> networking infrastructure outside your cloud.\n> \n> I cannot help you with the configuration issue but recommend that you\n> familiarize yourself with neutron.\n> \n> Regards,\n> \n> 	Uwe\n> \n> Am 14.12.2014 um 19:36 schrieb Gonzalo Aguilar Delgado:\n>>  Hi all, \n>>  \n>>  I\'m installing a new compute node from scratch and reviewing all old\n>>  config. I\'ve found two setting that seems equal, one in ml2 plugin \n>> and\n>>  one in openvswitch.\n>>  \n>>  But I don\'t really understand why they are.\n>>  \n>>  ovs_neutron_plugin.ini:\n>>  bridge_mappings = default:br0,extnet1:br-ex\n>>  \n>>  \n>>  ml2/ml2_conf.ini:\n>>  [ovs]\n>>  bridge_mappings = default:br0,extnet1:br-ex\n>>  \n>>  \n>>  For me it\'s strange the settings are in both places. I think this \n>> is a\n>>  result of upgrading without taking much care of removing old config.\n>>  \n>>  \n>>   But also it\'s strange that everything works with the bridges br0 \n>> and\n>>  br-ex without physical interface. I mean, seems to do nothing but it\n>>  needs to be there.  \n>>  Also I should expect VM be attached to br0 (Default) but it\'s not, \n>> they\n>>  are attached to the br-int (integration bridge), for me this is \n>> correct.\n>>  Since it\'s described here like this:\n>>  \n>>  https://openstack.redhat.com/Networking_in_too_much_detail\n>>  \n>>  And works ok. \n>>  \n>>  So what\'s the purporse of these bridges?\n>>  \n>>  Here is:\n>>  \n>>  neutron 2.3.4\n>>  nova      2.17.0\n>>  \n>>  Best regards,\n>>  \n>>  \n>>  \n>>  \n>>  \n>>  _______________________________________________\n>>  Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>  Post to     : openstack at lists.openstack.org\n>>  Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>  \n> \n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/3118f56b/attachment.html>\n\n','<548DE792.6070502@gmail.com>',NULL),('<1418593009.6578.3@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 22:36:49',3600,'2014-12-14 21:36:49',NULL,'[Openstack] VM lose connectivity if created new. Have to\n restart neutron-plugin-openvswitch-agent','Hi Adrian, \n\nIt\'s ubuntu trusty and network cards are intel, broadcom and marvell\n\nMarvell Technology Group Ltd. 88SE912x \nBroadcom Corporation NetXtreme II BCM5706 Gigabit Ethernet\nIntel Corporation 82574L Gigabit Network\n\nBut I don\'t think it\'s the problem. It seems more a problem on config \nor maybe a bug, since it doesn\'t fail on any other circumstances. And \nI\'m running ceph! It needs reliable network. \n\nWhat are you looking at?\n\n\nEl dom, 14 de dic 2014 a las 9:11 , Adri?n Norte Fern?ndez \n<adrian at bashlines.com> escribi?:\n> Which SO and network cards are you using?\n> \n> El 14/12/2014 19:35, \"Gonzalo Aguilar Delgado\" \n> <gaguilar at aguilardelgado.com> escribi?:\n>> Hi all, \n>> \n>> Question is. Why I have to restart neutron-plugin-openvswitch-agent \n>> to recover networking from new machines?\n>> \n>> \n>> I found a problem creating machines in a new node I\'ve built. And \n>> realized that this happens on all my nodes of current version. \n>> \n>> neutron 2.3.4\n>> nova      2.17.0\n>> \n>> My logs shows that neutron assign vlan 2 for the new machine and \n>> this causes the machine to not have connectivity. \n>> \n>> ---------------------------------------\n>> 2014-12-14 17:57:07.321 12501 INFO \n>> neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Assigning 2 \n>> as local vlan for net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>> 20\n>> ---------------------------------------\n>> \n>> \n>> If I shut down the machine and restart neutron plugin agent for ovs:\n>> \n>> #> restart neutron-plugin-openvswitch-agent\n>> \n>> \n>> ---------------------------------------\n>>  ...  assigning 1 as local vlan for \n>> net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>> \n>> ---------------------------------------\n>> \n>> \n>> And the machine recovers connectivity. \n>> \n>> In the even of faillure (after creating it):\n>> \n>> If I start the machine without ip and set it manually I can try to \n>> ping it. It says it\'s not reachable but after restating the plugin \n>> automatically recovers connectivity. So no restart or further \n>> configuration is made. \n>> \n>> \n>> Maybe I have something wrong configured but it seems like a bug.\n>> \n>> \n>> Can someone point me to the right place?\n>> \n>> \n>> _______________________________________________\n>> Mailing list: \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> Post to     : openstack at lists.openstack.org\n>> Unsubscribe : \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/888f15a6/attachment.html>\n\n','<CAJw1JyUPM1e+Z9o5CQ83ppyt5icr-rnqzWcRoDqPKMVnpEhd4A@mail.gmail.com>',NULL),('<1418593161.6578.4@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 22:39:21',3600,'2014-12-14 21:39:21',NULL,'[Openstack] What\'s physical network for?','Hi again Uwe, \n\nIt makes sense for me. Since external networks are not used on \ncompute-nodes. I must say that even configuring this without physical \ninterface the VM on that machine has network access to the external \nnetwork. \n\nSo I can suppose that in case this is for external network mapping, \nthen it should only have effect in the neutron node. \n\nBut as said. Any light will be great.\n\n\n\nEl dom, 14 de dic 2014 a las 9:25 , Uwe Sauter \n<uwe.sauter.de at gmail.com> escribi?:\n> As far as I know, bridge_mapping is used to let neutron know which\n> bridge should be uses for the (possibly more than one) external \n> network(s).\n> \n> If someone else could jump in and give a bit more detail, I\'d \n> appreciate\n> that, too.\n> \n> Regards,\n> \n> 	Uwe\n> \n> \n> Am 14.12.2014 um 20:55 schrieb Gonzalo Aguilar Delgado:\n>>  Hi Uwe, \n>>  \n>>  really I started directly with neutron. Never gone with legacy. \n>>  \n>>  But I suppose there\'s old config laying around. I still think that\n>>  bridge_mapping is needed for VLAN config I use. Every paper \n>> describes\n>>  GRE config, but I still feel more confortable using VLANs.\n>>  \n>>  Any other help about this issue? Can someone confirm if I can get \n>> rid of\n>>  the directives in both configs?\n>>  \n>>  I suppose I cannot because they get in effect when started the ovs \n>> plugin.\n>>  \n>>  Thank you in advance.\n>>  \n>>  \n>>  \n>>  El dom, 14 de dic 2014 a las 8:40 , Uwe Sauter \n>> <uwe.sauter.de at gmail.com>\n>>  escribi?:\n>>>  Hi, I presume that you upgraded from an older version that used\n>>>  nova-network (now called legacy networking). Using neutron means \n>>> that\n>>>  VMs aren\'t connected to br0 directly any more as there is a whole\n>>>  virtual networking infrastructure in place. To give a small \n>>> overview:\n>>>  On a compute node a VM connects to br-int (integration bridge). \n>>> This\n>>>  bridge itself is connected through a virtual cable to br-tun\n>>>  (tunneling bridge). That bridge has also assigned a physical \n>>> interface\n>>>  that allows traffic to flow to the network node On the network node\n>>>  there also exists a br-tun that has a physical interface attached.\n>>>  Through this inferface traffic enters the node. br-tun is virtually\n>>>  connected to br-ex that has a separate physical interface attached\n>>>  that connects to \"the outside\", meaning the networking \n>>> infrastructure\n>>>  outside your cloud. I cannot help you with the configuration issue \n>>> but\n>>>  recommend that you familiarize yourself with neutron. Regards, Uwe \n>>> Am\n>>>  14.12.2014 um 19:36 schrieb Gonzalo Aguilar Delgado:\n>>> \n>>>      Hi all, I\'m installing a new compute node from scratch and\n>>>      reviewing all old config. I\'ve found two setting that seems \n>>> equal,\n>>>      one in ml2 plugin and one in openvswitch. But I don\'t really\n>>>      understand why they are. ovs_neutron_plugin.ini: \n>>> bridge_mappings =\n>>>      default:br0,extnet1:br-ex ml2/ml2_conf.ini: [ovs] \n>>> bridge_mappings\n>>>      = default:br0,extnet1:br-ex For me it\'s strange the settings \n>>> are\n>>>      in both places. I think this is a result of upgrading without\n>>>      taking much care of removing old config. But also it\'s strange\n>>>      that everything works with the bridges br0 and br-ex without\n>>>      physical interface. I mean, seems to do nothing but it needs \n>>> to be\n>>>      there. Also I should expect VM be attached to br0 (Default) but\n>>>      it\'s not, they are attached to the br-int (integration bridge),\n>>>      for me this is correct. Since it\'s described here like this:\n>>>      https://openstack.redhat.com/Networking_in_too_much_detail And\n>>>      works ok. So what\'s the purporse of these bridges? Here is:\n>>>      neutron 2.3.4 nova 2.17.0 Best regards,\n>>>      _______________________________________________ Mailing list:\n>>>      http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>>> Post\n>>>      to : openstack at lists.openstack.org Unsubscribe :\n>>>      http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n>>> \n>>>  _______________________________________________ Mailing list:\n>>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post \n>>> to\n>>>  : openstack at lists.openstack.org Unsubscribe :\n>>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/e2baf667/attachment.html>\n\n','<548DF234.4060905@gmail.com>',NULL),('<1418593900.6578.5@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 22:51:40',3600,'2014-12-14 21:51:40',NULL,'[Openstack] VM lose connectivity if created new. Have to\n restart neutron-plugin-openvswitch-agent','Hi Adri?n, \n\nIn my case I learnt the bad way also. And now I purchased some Intel \npci cards and add it to servers that have not much reliable cards. \n\nI post my bridge config:\n\n   Bridge \"br0\"\n        Port \"phy-br0\"\n            Interface \"phy-br0\"\n        Port \"br0\"\n            Interface \"br0\"\n                type: internal\n    Bridge br-int\n        fail_mode: secure\n        Port \"qvob27f1522-73\"\n            tag: 1\n            Interface \"qvob27f1522-73\"\n        Port int-br-ex\n            Interface int-br-ex\n        Port br-int\n            Interface br-int\n                type: internal\n        Port \"qvo9da5cf98-f1\"\n            tag: 1\n            Interface \"qvo9da5cf98-f1\"\n        Port \"int-br0\"\n            Interface \"int-br0\"\n        Port \"qvo377f7953-d2\"\n            tag: 1\n            Interface \"qvo377f7953-d2\"\n        Port \"eth0\"\n            Interface \"eth0\"\n        Port \"qvod1b2e6dc-7f\"\n            tag: 1\n            Interface \"qvod1b2e6dc-7f\"\n    Bridge br-ex\n        Port br-ex\n            Interface br-ex\n                type: internal\n        Port phy-br-ex\n            Interface phy-br-ex\n    ovs_version: \"2.0.2\"\n\n\nEl dom, 14 de dic 2014 a las 10:41 , Adri?n Norte Fern?ndez \n<adrian at bashlines.com> escribi?:\n> I had a similar problem because a cheap realtek card.\n> \n> Do you have logs? Can you post the result of ovs-vsctl show command \n> on compute node?\n> \n> El 14/12/2014 22:36, \"Gonzalo Aguilar Delgado\" \n> <gaguilar at aguilardelgado.com> escribi?:\n>> Hi Adrian, \n>> \n>> It\'s ubuntu trusty and network cards are intel, broadcom and marvell\n>> \n>> Marvell Technology Group Ltd. 88SE912x \n>> Broadcom Corporation NetXtreme II BCM5706 Gigabit Ethernet\n>> Intel Corporation 82574L Gigabit Network\n>> \n>> But I don\'t think it\'s the problem. It seems more a problem on \n>> config or maybe a bug, since it doesn\'t fail on any other \n>> circumstances. And I\'m running ceph! It needs reliable network. \n>> \n>> What are you looking at?\n>> \n>> \n>> El dom, 14 de dic 2014 a las 9:11 , Adri?n Norte Fern?ndez \n>> <adrian at bashlines.com> escribi?:\n>>> Which SO and network cards are you using?\n>>> \n>>> El 14/12/2014 19:35, \"Gonzalo Aguilar Delgado\" \n>>> <gaguilar at aguilardelgado.com> escribi?:\n>>>> Hi all, \n>>>> \n>>>> Question is. Why I have to restart \n>>>> neutron-plugin-openvswitch-agent to recover networking from new \n>>>> machines?\n>>>> \n>>>> \n>>>> I found a problem creating machines in a new node I\'ve built. And \n>>>> realized that this happens on all my nodes of current version. \n>>>> \n>>>> neutron 2.3.4\n>>>> nova      2.17.0\n>>>> \n>>>> My logs shows that neutron assign vlan 2 for the new machine and \n>>>> this causes the machine to not have connectivity. \n>>>> \n>>>> ---------------------------------------\n>>>> 2014-12-14 17:57:07.321 12501 INFO \n>>>> neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] Assigning \n>>>> 2 as local vlan for net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>>>> 20\n>>>> ---------------------------------------\n>>>> \n>>>> \n>>>> If I shut down the machine and restart neutron plugin agent for \n>>>> ovs:\n>>>> \n>>>> #> restart neutron-plugin-openvswitch-agent\n>>>> \n>>>> \n>>>> ---------------------------------------\n>>>>  ...  assigning 1 as local vlan for \n>>>> net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>>>> \n>>>> ---------------------------------------\n>>>> \n>>>> \n>>>> And the machine recovers connectivity. \n>>>> \n>>>> In the even of faillure (after creating it):\n>>>> \n>>>> If I start the machine without ip and set it manually I can try to \n>>>> ping it. It says it\'s not reachable but after restating the plugin \n>>>> automatically recovers connectivity. So no restart or further \n>>>> configuration is made. \n>>>> \n>>>> \n>>>> Maybe I have something wrong configured but it seems like a bug.\n>>>> \n>>>> \n>>>> Can someone point me to the right place?\n>>>> \n>>>> \n>>>> _______________________________________________\n>>>> Mailing list: \n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> Post to     : openstack at lists.openstack.org\n>>>> Unsubscribe : \n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/1b86e079/attachment.html>\n\n','<CAJw1JyVwi4r2EsBWP-bDhJJyyOh=epGjVMEkyErSMMRqV5Qiog@mail.gmail.com>',NULL),('<1418594622.6578.6@smtp.aguilardelgado.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-14 23:03:42',3600,'2014-12-14 22:03:42',NULL,'[Openstack] VM lose connectivity if created new. Have to\n restart neutron-plugin-openvswitch-agent','Hi Adri?n, \n\nIn fact, I have everything bridget to create VM outside the openstack \nwith KVM. \n\nBut in this case I made them just because they were specified in the \nexample configuration of the openvswitch plugin. And ml2 plugin later.\n\nThey are the br0 and br-ext. I asked for this in another thread.\n\nBut I don\'t know what are they for.\n\n\n\nEl dom, 14 de dic 2014 a las 10:59 , Adri?n Norte Fern?ndez \n<adrian at bashlines.com> escribi?:\n> Why do you have two physical bridged networks on your compute node?\n> \n> El 14/12/2014 22:51, \"Gonzalo Aguilar Delgado\" \n> <gaguilar at aguilardelgado.com> escribi?:\n>> Hi Adri?n, \n>> \n>> In my case I learnt the bad way also. And now I purchased some Intel \n>> pci cards and add it to servers that have not much reliable cards. \n>> \n>> I post my bridge config:\n>> \n>>    Bridge \"br0\"\n>>         Port \"phy-br0\"\n>>             Interface \"phy-br0\"\n>>         Port \"br0\"\n>>             Interface \"br0\"\n>>                 type: internal\n>>     Bridge br-int\n>>         fail_mode: secure\n>>         Port \"qvob27f1522-73\"\n>>             tag: 1\n>>             Interface \"qvob27f1522-73\"\n>>         Port int-br-ex\n>>             Interface int-br-ex\n>>         Port br-int\n>>             Interface br-int\n>>                 type: internal\n>>         Port \"qvo9da5cf98-f1\"\n>>             tag: 1\n>>             Interface \"qvo9da5cf98-f1\"\n>>         Port \"int-br0\"\n>>             Interface \"int-br0\"\n>>         Port \"qvo377f7953-d2\"\n>>             tag: 1\n>>             Interface \"qvo377f7953-d2\"\n>>         Port \"eth0\"\n>>             Interface \"eth0\"\n>>         Port \"qvod1b2e6dc-7f\"\n>>             tag: 1\n>>             Interface \"qvod1b2e6dc-7f\"\n>>     Bridge br-ex\n>>         Port br-ex\n>>             Interface br-ex\n>>                 type: internal\n>>         Port phy-br-ex\n>>             Interface phy-br-ex\n>>     ovs_version: \"2.0.2\"\n>> \n>> \n>> El dom, 14 de dic 2014 a las 10:41 , Adri?n Norte Fern?ndez \n>> <adrian at bashlines.com> escribi?:\n>>> I had a similar problem because a cheap realtek card.\n>>> \n>>> Do you have logs? Can you post the result of ovs-vsctl show command \n>>> on compute node?\n>>> \n>>> El 14/12/2014 22:36, \"Gonzalo Aguilar Delgado\" \n>>> <gaguilar at aguilardelgado.com> escribi?:\n>>>> Hi Adrian, \n>>>> \n>>>> It\'s ubuntu trusty and network cards are intel, broadcom and \n>>>> marvell\n>>>> \n>>>> Marvell Technology Group Ltd. 88SE912x \n>>>> Broadcom Corporation NetXtreme II BCM5706 Gigabit Ethernet\n>>>> Intel Corporation 82574L Gigabit Network\n>>>> \n>>>> But I don\'t think it\'s the problem. It seems more a problem on \n>>>> config or maybe a bug, since it doesn\'t fail on any other \n>>>> circumstances. And I\'m running ceph! It needs reliable network. \n>>>> \n>>>> What are you looking at?\n>>>> \n>>>> \n>>>> El dom, 14 de dic 2014 a las 9:11 , Adri?n Norte Fern?ndez \n>>>> <adrian at bashlines.com> escribi?:\n>>>>> Which SO and network cards are you using?\n>>>>> \n>>>>> El 14/12/2014 19:35, \"Gonzalo Aguilar Delgado\" \n>>>>> <gaguilar at aguilardelgado.com> escribi?:\n>>>>>> Hi all, \n>>>>>> \n>>>>>> Question is. Why I have to restart \n>>>>>> neutron-plugin-openvswitch-agent to recover networking from new \n>>>>>> machines?\n>>>>>> \n>>>>>> \n>>>>>> I found a problem creating machines in a new node I\'ve built. \n>>>>>> And realized that this happens on all my nodes of current \n>>>>>> version. \n>>>>>> \n>>>>>> neutron 2.3.4\n>>>>>> nova      2.17.0\n>>>>>> \n>>>>>> My logs shows that neutron assign vlan 2 for the new machine and \n>>>>>> this causes the machine to not have connectivity. \n>>>>>> \n>>>>>> ---------------------------------------\n>>>>>> 2014-12-14 17:57:07.321 12501 INFO \n>>>>>> neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] \n>>>>>> Assigning 2 as local vlan for \n>>>>>> net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>>>>>> 20\n>>>>>> ---------------------------------------\n>>>>>> \n>>>>>> \n>>>>>> If I shut down the machine and restart neutron plugin agent for \n>>>>>> ovs:\n>>>>>> \n>>>>>> #> restart neutron-plugin-openvswitch-agent\n>>>>>> \n>>>>>> \n>>>>>> ---------------------------------------\n>>>>>>  ...  assigning 1 as local vlan for \n>>>>>> net-id=727b0415-f066-40d9-8147-183e07dd7b23\n>>>>>> \n>>>>>> ---------------------------------------\n>>>>>> \n>>>>>> \n>>>>>> And the machine recovers connectivity. \n>>>>>> \n>>>>>> In the even of faillure (after creating it):\n>>>>>> \n>>>>>> If I start the machine without ip and set it manually I can try \n>>>>>> to ping it. It says it\'s not reachable but after restating the \n>>>>>> plugin automatically recovers connectivity. So no restart or \n>>>>>> further configuration is made. \n>>>>>> \n>>>>>> \n>>>>>> Maybe I have something wrong configured but it seems like a bug.\n>>>>>> \n>>>>>> \n>>>>>> Can someone point me to the right place?\n>>>>>> \n>>>>>> \n>>>>>> _______________________________________________\n>>>>>> Mailing list: \n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> Post to     : openstack at lists.openstack.org\n>>>>>> Unsubscribe : \n>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>>>>> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141214/9bf87a1b/attachment.html>\n\n','<CAJw1JyX1p8Ez_edoV4BkUn8_hCsqozbv-Wy6ZHLVs3TOzcW37g@mail.gmail.com>',NULL),('<1418630016.4479.16.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-15 08:53:36',3600,'2014-12-15 07:53:36',NULL,'[Openstack] What\'s physical network for?','Hi Gonzalo, \nfrom having a look, at the configuration reference [1], I see that the\nbridge_mappings is only required in the [ovs] section [2] and not in the\nml2 configuration for vlan [3]. \n\n\nAnd also the code says, that the bridge_mappings attribute needs to be\nin the [ovs] section.\n\n\nYou\'re talking about two configuration files. I guess the question is,\nwhich config file is used by your services (neutron-openvswitch-agent\nand  neutron-server)? You can find out via\n\n# ps -ax | grep neutron- \n\n\nMaybe one of your files is not even used? Or maybe the neutron server\ntakes one and the openvswitch agent the other file. The relevant file is\nthe one that is used by openvswitch The attribute should be in there!\n\nJust have a try! Change it in your config file, restart the neutron\nservices and check if it is still working.\n\n\nWhen is it required? Always for vlan and flat networking in the data or\nin the external network. But it\'s not  required for tunneling in the\ndatanetwork. I\'m not sure about tunneling in the external network!! I\'ll\ngive you an example: \n\nDatanetwork = gre, External network=flat --> bridge_mappings specifies\nthe bridge for the external flat network. \n\nDatanetwork =vxlan, external network = vxlan --> I don\'t know! \n\nDatanetwork vlan, external network flat --> Bridges for both network\nneed to be specified\n\n\n\nHope this helps!\n\n\n[1]\nhttp://docs.openstack.org/juno/config-reference/content/section_networking-options-reference.html\n\n[2]\nhttp://docs.openstack.org/juno/config-reference/content/networking-plugin-openvswitch_agent.html\n\n[3]\nhttp://docs.openstack.org/juno/config-reference/content/networking-plugin-ml2_vlan.html\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Sun, 2014-12-14 at 22:39 +0100, Gonzalo Aguilar Delgado wrote:\n> Hi again Uwe, \n> \n> \n> It makes sense for me. Since external networks are not used on\n> compute-nodes. I must say that even configuring this without physical\n> interface the VM on that machine has network access to the external\n> network. \n> \n> \n> So I can suppose that in case this is for external network mapping,\n> then it should only have effect in the neutron node. \n> \n> \n> But as said. Any light will be great.\n> \n> \n> \n> \n> El dom, 14 de dic 2014 a las 9:25 , Uwe Sauter\n> <uwe.sauter.de at gmail.com> escribi?:\n> > As far as I know, bridge_mapping is used to let neutron know which\n> > bridge should be uses for the (possibly more than one) external\n> > network(s). If someone else could jump in and give a bit more\n> > detail, I\'d appreciate that, too. Regards, Uwe Am 14.12.2014 um\n> > 20:55 schrieb Gonzalo Aguilar Delgado: \n> >         Hi Uwe, really I started directly with neutron. Never gone\n> >         with legacy. But I suppose there\'s old config laying around.\n> >         I still think that bridge_mapping is needed for VLAN config\n> >         I use. Every paper describes GRE config, but I still feel\n> >         more confortable using VLANs. Any other help about this\n> >         issue? Can someone confirm if I can get rid of the\n> >         directives in both configs? I suppose I cannot because they\n> >         get in effect when started the ovs plugin. Thank you in\n> >         advance. El dom, 14 de dic 2014 a las 8:40 , Uwe Sauter\n> >         <uwe.sauter.de at gmail.com> escribi?: \n> >                 Hi, I presume that you upgraded from an older\n> >                 version that used nova-network (now called legacy\n> >                 networking). Using neutron means that VMs aren\'t\n> >                 connected to br0 directly any more as there is a\n> >                 whole virtual networking infrastructure in place. To\n> >                 give a small overview: On a compute node a VM\n> >                 connects to br-int (integration bridge). This bridge\n> >                 itself is connected through a virtual cable to\n> >                 br-tun (tunneling bridge). That bridge has also\n> >                 assigned a physical interface that allows traffic to\n> >                 flow to the network node On the network node there\n> >                 also exists a br-tun that has a physical interface\n> >                 attached. Through this inferface traffic enters the\n> >                 node. br-tun is virtually connected to br-ex that\n> >                 has a separate physical interface attached that\n> >                 connects to \"the outside\", meaning the networking\n> >                 infrastructure outside your cloud. I cannot help you\n> >                 with the configuration issue but recommend that you\n> >                 familiarize yourself with neutron. Regards, Uwe Am\n> >                 14.12.2014 um 19:36 schrieb Gonzalo Aguilar Delgado:\n> >                 Hi all, I\'m installing a new compute node from\n> >                 scratch and reviewing all old config. I\'ve found two\n> >                 setting that seems equal, one in ml2 plugin and one\n> >                 in openvswitch. But I don\'t really understand why\n> >                 they are. ovs_neutron_plugin.ini: bridge_mappings =\n> >                 default:br0,extnet1:br-ex ml2/ml2_conf.ini: [ovs]\n> >                 bridge_mappings = default:br0,extnet1:br-ex For me\n> >                 it\'s strange the settings are in both places. I\n> >                 think this is a result of upgrading without taking\n> >                 much care of removing old config. But also it\'s\n> >                 strange that everything works with the bridges br0\n> >                 and br-ex without physical interface. I mean, seems\n> >                 to do nothing but it needs to be there. Also I\n> >                 should expect VM be attached to br0 (Default) but\n> >                 it\'s not, they are attached to the br-int\n> >                 (integration bridge), for me this is correct. Since\n> >                 it\'s described here like this:\n> >                 https://openstack.redhat.com/Networking_in_too_much_detail And works ok. So what\'s the purporse of these bridges? Here is: neutron 2.3.4 nova 2.17.0 Best regards, _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<1418593161.6578.4@smtp.aguilardelgado.com>',NULL),('<1418658934-sup-597@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 08:00:01',-28800,'2014-12-15 16:00:01',NULL,'[openstack-dev] Do all OpenStack daemons support sd_notify?','Excerpts from Ihar Hrachyshka\'s message of 2014-12-15 07:21:04 -0800:\n> Hash: SHA512\n> \n> On 14/12/14 09:45, Thomas Goirand wrote:\n> > Hi,\n> > \n> > As I am slowing fixing all systemd issues for the daemons of\n> > OpenStack in Debian (and hopefully, have this ready before the\n> > freeze of Jessie), I was wondering what kind of Type= directive to\n> > put on the systemd .service files. I have noticed that in Fedora,\n> > there\'s Type=notify. So my question is:\n> > \n> > Do all OpenStack daemons, as a rule, support the DBus sd_notify\n> > thing? Should I always use Type=notify for systemd .service files?\n> > Can this be called a general rule with no exception?\n> \n> (I will talk about neutron only.)\n> \n> I guess Type=notify is supposed to be used with daemons that use\n> Service class from oslo-incubator that provides systemd notification\n> mechanism, or call to systemd.notify_once() otherwise.\n> \n> In terms of Neutron, neutron-server process is doing it, metadata\n> agent also seems to do it, while OVS agent seems to not. So it really\n> should depend on each service and the way it\'s implemented. You cannot\n> just assume that every Neutron service reports back to systemd.\n> \n> In terms of Fedora, we have Type=notify for neutron-server service only.\n> \n> BTW now that more distributions are interested in shipping unit files\n> for services, should we upstream them and ship the same thing in all\n> interested distributions?\n> \n\nSince we can expect the five currently implemented OS\'s in TripleO to all\nhave systemd by default soon (Debian, Fedora, openSUSE, RHEL, Ubuntu),\nit would make a lot of sense for us to make the systemd unit files that\nTripleO generates set Type=notify wherever possible. So hopefully we can\nactually make such a guarantee upstream sometime in the not-so-distant\nfuture, especially since our CI will run two of the more distinct forks,\nUbuntu and Fedora.\n\n\n','<548EFC60.2020505@redhat.com>',NULL),('<1418660028-sup-6503@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 11:29:03',-28800,'2014-12-15 19:29:03',NULL,'[openstack-dev] [Heat] Convergence proof-of-concept showdown','Excerpts from Anant Patil\'s message of 2014-12-15 07:15:30 -0800:\n> On 13-Dec-14 05:42, Zane Bitter wrote:\n> > On 12/12/14 05:29, Murugan, Visnusaran wrote:\n> >>\n> >>\n> >>> -----Original Message-----\n> >>> From: Zane Bitter [mailto:zbitter at redhat.com]\n> >>> Sent: Friday, December 12, 2014 6:37 AM\n> >>> To: openstack-dev at lists.openstack.org\n> >>> Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept\n> >>> showdown\n> >>>\n> >>> On 11/12/14 08:26, Murugan, Visnusaran wrote:\n> >>>>>> [Murugan, Visnusaran]\n> >>>>>> In case of rollback where we have to cleanup earlier version of\n> >>>>>> resources,\n> >>>>> we could get the order from old template. We\'d prefer not to have a\n> >>>>> graph table.\n> >>>>>\n> >>>>> In theory you could get it by keeping old templates around. But that\n> >>>>> means keeping a lot of templates, and it will be hard to keep track\n> >>>>> of when you want to delete them. It also means that when starting an\n> >>>>> update you\'ll need to load every existing previous version of the\n> >>>>> template in order to calculate the dependencies. It also leaves the\n> >>>>> dependencies in an ambiguous state when a resource fails, and\n> >>>>> although that can be worked around it will be a giant pain to implement.\n> >>>>>\n> >>>>\n> >>>> Agree that looking to all templates for a delete is not good. But\n> >>>> baring Complexity, we feel we could achieve it by way of having an\n> >>>> update and a delete stream for a stack update operation. I will\n> >>>> elaborate in detail in the etherpad sometime tomorrow :)\n> >>>>\n> >>>>> I agree that I\'d prefer not to have a graph table. After trying a\n> >>>>> couple of different things I decided to store the dependencies in the\n> >>>>> Resource table, where we can read or write them virtually for free\n> >>>>> because it turns out that we are always reading or updating the\n> >>>>> Resource itself at exactly the same time anyway.\n> >>>>>\n> >>>>\n> >>>> Not sure how this will work in an update scenario when a resource does\n> >>>> not change and its dependencies do.\n> >>>\n> >>> We\'ll always update the requirements, even when the properties don\'t\n> >>> change.\n> >>>\n> >>\n> >> Can you elaborate a bit on rollback.\n> > \n> > I didn\'t do anything special to handle rollback. It\'s possible that we \n> > need to - obviously the difference in the UpdateReplace + rollback case \n> > is that the replaced resource is now the one we want to keep, and yet \n> > the replaced_by/replaces dependency will force the newer (replacement) \n> > resource to be checked for deletion first, which is an inversion of the \n> > usual order.\n> > \n> \n> This is where the version is so handy! For UpdateReplaced ones, there is\n> an older version to go back to. This version could just be template ID,\n> as I mentioned in another e-mail. All resources are at the current\n> template ID if they are found in the current template, even if they is\n> no need to update them. Otherwise, they need to be cleaned-up in the\n> order given in the previous templates.\n> \n> I think the template ID is used as version as far as I can see in Zane\'s\n> PoC. If the resource template key doesn\'t match the current template\n> key, the resource is deleted. The version is misnomer here, but that\n> field (template id) is used as though we had versions of resources.\n> \n> > However, I tried to think of a scenario where that would cause problems \n> > and I couldn\'t come up with one. Provided we know the actual, real-world \n> > dependencies of each resource I don\'t think the ordering of those two \n> > checks matters.\n> > \n> > In fact, I currently can\'t think of a case where the dependency order \n> > between replacement and replaced resources matters at all. It matters in \n> > the current Heat implementation because resources are artificially \n> > segmented into the current and backup stacks, but with a holistic view \n> > of dependencies that may well not be required. I tried taking that line \n> > out of the simulator code and all the tests still passed. If anybody can \n> > think of a scenario in which it would make a difference, I would be very \n> > interested to hear it.\n> > \n> > In any event though, it should be no problem to reverse the direction of \n> > that one edge in these particular circumstances if it does turn out to \n> > be a problem.\n> > \n> >> We had an approach with depends_on\n> >> and needed_by columns in ResourceTable. But dropped it when we figured out\n> >> we had too many DB operations for Update.\n> > \n> > Yeah, I initially ran into this problem too - you have a bunch of nodes \n> > that are waiting on the current node, and now you have to go look them \n> > all up in the database to see what else they\'re waiting on in order to \n> > tell if they\'re ready to be triggered.\n> > \n> > It turns out the answer is to distribute the writes but centralise the \n> > reads. So at the start of the update, we read all of the Resources, \n> > obtain their dependencies and build one central graph[1]. We than make \n> > that graph available to each resource (either by passing it as a \n> > notification parameter, or storing it somewhere central in the DB that \n> > they will all have to read anyway, i.e. the Stack). But when we update a \n> > dependency we don\'t update the central graph, we update the individual \n> > Resource so there\'s no global lock required.\n> > \n> > [1] \n> > https://github.com/zaneb/heat-convergence-prototype/blob/distributed-graph/converge/stack.py#L166-L168\n> > \n> \n> A centralized graph and decision making will make the implementation far\n> more simpler than distributed. This looks academic, but the simplicity\n> beats everything! When each worker has to decide, there needs to be\n> lock, only DB transactions are not enough. In contrast, when the\n> decision making is centralized, that particular critical section can be\n> attempted with transaction and re-attempted if needed.\n> \n\nI\'m concerned that we\'re losing sight of the whole point of convergence.\n\nYes, concurrency is hard, and state management is really the only thing\nhard about concurrency.\n\nWhat Zane is suggesting is a lock-free approach commonly called \'Read\nCopy Update\' or \"RCU\". It has high reader concurrency, but relies on\nthere only being one writer. It is quite simple, and has proven itself\nenough to even be included in the Linux kernel:\n\nhttp://lwn.net/Articles/263130/\n\n> With the distributed approach, I see following drawbacks:\n> 1. Every time a resource is done, the peer resources (siblings) are\n> checked to see if they are done and the parent is propagated. This\n> happens for each resource.\n\nThis is slightly inaccurate.\n\nEvery time a resource is done, resources that depend on that resource\nare checked to see if they still have any unresolved dependencies.\n\n> 2. The worker has to run through all the resources to see if the stack\n> is done, to mark it as completed.\n\nIf a worker completes a resource which has no dependent resources, it\nonly needs to check to see if all of the other edges of the graph are\ncomplete to mark the state as complete. There is no full traversal\nunless you want to make sure nothing regressed, which is not the way any\nof the specs read.\n\n> 3. The decision to converge is made by each worker resulting in lot of\n> contention. The centralized graph restricts the contention point to one\n> place where we can use DB transactions. It is easier to maintain code\n> where particular decisions are made at a place rather than at many\n> places.\n\nWhy not let multiple workers use DB transactions? The contention happens\n_only if it needs to happen to preserve transaction consistency_ instead\nof _always_.\n\n> 4. The complex part we are trying to solve is to decide on what to do\n> next when a resource is done. With centralized graph, this is abstracted\n> out to the DB API. The API will return the next set of nodes. A smart\n> SQL query can reduce a lot of logic currently being coded in\n> worker/engine.\n\nHaving seen many such \"smart\" SQL queries, I have to say, this is\nterrifying. Complexity in database access is by far the single biggest\nobstacle to scaling out.\n\nI don\'t really know why you\'d want logic to move into the database. It\nis the one place that you must keep simple in order to scale. We can\nscale out python like crazy.. but SQL is generally a single threaded,\nimpossible to debug component. So make the schema obvious and accesses\nto it straight forward.\n\nI think we need to land somewhere between the two approaches though.\nHere is my idea for DB interaction, I realize now it\'s been in my head\nfor a while but I never shared:\n\nCREATE TABLE resource (\n  id ...,\n  ! all the stuff now\n  version int,\n  replaced_by int,\n  complete_order int,\n  primary key (id, version),\n  key idx_replaced_by (replaced_by));\n\nCREATE TABLE resource_dependencies (\n  id ....,\n  version int,\n  needed_by ...\n  primary key (id, version, needed_by));\n\nThen completion happens something like this:\n\nBEGIN\nSELECT @complete_order := MAX(complete_order) FROM resource WHERE stack_id = :stack_id:\nSET @complete_order := @complete_order + 1\nUPDATE resource SET complete_order = @complete_order, state=\'COMPLETE\' WHERE id=:id: AND version=:version:;\n! if there is a replaced_version\nUPDATE resource SET replaced_by=:version: WHERE id=:id: AND version=:replaced_version:;\nSELECT DISTINCT r.id FROM resource r INNER JOIN resource_dependencies rd\n       ON r.id = rd.resource_id AND r.version = rd.version\nWHERE r.version=:version: AND rd.needed_by=:id: AND r.state != \'COMPLETE\'\n<python>\nfor id in results:\n  convergequeue.submit(id)\n</python>\nCOMMIT\n\nPerhaps I\'ve missed some revelation that makes this hard or impossible.\nBut I don\'t see a ton of database churn (one update per completion is\nmeh). I also don\'t see a lot of complexity in the query. The\ncomplete_order can be used to handle deletes in the right order later\n(note that I know that is probably the wrong way to do it and sequences\nare a thing that can be used for this).\n\n> 5. What would be the starting point for resource clean-up? The clean-up\n> has to start when all the resources are updated. With no centralized\n> graph, the DB has to be searched for all the resources with no\n> dependencies and with older versions (or having older template keys) and\n> start removing them. With centralized graph, this would be a simpler\n> with a SQL queries returning what needs to be done. The search space for\n> where to start with clean-up will be huge.\n\n\"Searched\" may be the wrong way. With the table structure above, you can\nfind everything to delete with this query:\n\n! Outright deletes\nSELECT r_old.id\nFROM resource r_old LEFT OUTER JOIN resource r_new\n  ON r_old.id = r_new.id AND r_old.version = :cleanup_version:\nWHERE r_new.id IS NULL OR r_old.replaced_by IS NOT NULL\nORDER BY DESC r.complete_order;\n\nThat should delete everything in more or less the right order. I think\nfor that one you can just delete the rows as they\'re confirmed deleted\nfrom the plugins, no large transaction needed since we\'d not expect\nthese rows to be updated anymore.\n\n> 6. When engine restarts, the search space on where to start will be\n> huge. With a centralized graph, the abstracted API to get next set of\n> nodes makes the implementation of decision simpler.\n> \n> I am convinced enough that it is simpler to assign the responsibility to\n> engine on what needs to be done next. No locks will be required, not\n> even resource locks! It is simpler from implementation, understanding\n> and maintenance perspective.\n> \n\nI thought you started saying you would need locks, but now saying you\nwon\'t. I agree no abstract locking is needed, just a consistent view of\nthe graph in the DB.\n\n\n','<548EFB12.2090303@hp.com>',NULL),('<1418670702.429643.203185881.0EC40628@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 11:11:42',-28800,'2014-12-15 19:11:42',NULL,'[openstack-dev] oslo.db 1.3.0 released','\n\nOn Mon, Dec 15, 2014, at 11:09 AM, Doug Hellmann wrote:\n> \n> On Dec 15, 2014, at 2:02 PM, Donald Stufft <donald at stufft.io> wrote:\n> \n> > \n> >> On Dec 15, 2014, at 1:57 PM, Sean Dague <sean at dague.net> wrote:\n> >> \n> >> On 12/15/2014 01:53 PM, Donald Stufft wrote:\n> >>> \n> >>>> On Dec 15, 2014, at 1:50 PM, Sean Dague <sean at dague.net> wrote:\n> >>>> \n> >>>> On 12/15/2014 12:01 PM, Jeremy Stanley wrote:\n> >>>>> On 2014-12-15 11:53:07 -0500 (-0500), Doug Hellmann wrote:\n> >>>>> [...]\n> >>>>>> This release is primarily meant to update the SQLAlchemy dependency\n> >>>>>> to resolve the issue with the new version of setuptools changing\n> >>>>>> how it evaluates version range specifications.\n> >>>>> [...]\n> >>>>> \n> >>>>> However note that I\'m in the middle of forcing a refresh on a couple\n> >>>>> of our PyPI mirror servers, so it may be a couple hours before we\n> >>>>> see the effects of this throughout all of our infrastructure.\n> >>>>> \n> >>>> \n> >>>> It looks like this change has broken the grenade jobs because now\n> >>>> oslo.db 1.3.0 ends up being installed in stable/juno environments, which\n> >>>> has incompatible requirements with the rest of stable juno.\n> >>>> \n> >>>> http://logs.openstack.org/07/137307/1/gate//gate-grenade-dsvm/048ee63//logs/old/screen-s-proxy.txt.gz\n> >>>> \n> >>>> pkg_resources.VersionConflict: SQLAlchemy 0.8.4 is installed but\n> >>>> SQLAlchemy>=0.9.7,<=0.9.99 is required by [\'oslo.db\']\n> >>>> \n> >>>> 	-Sean\n> >>> \n> >>> It should probably use the specifier from Juno which matches the old\n> >>> specifier in functionality.\n> >> \n> >> Probably, but that was specifically reverted here -\n> >> https://review.openstack.org/#/c/138546/2/global-requirements.txt,cm\n> >> \n> > \n> > Not sure I follow, that doesn?t seem to contain any SQLAlchemy changes?\n> > \n> > I mean stable/juno has this -> SQLAlchemy>=0.8.4,<=0.9.99,!=0.9.0,!=0.9.1,!=0.9.2,!=0.9.3,!=0.9.4,!=0.9.5,!=0.9.6\n> > and master has this -> SQLAlchemy>=0.9.7,<=0.9.99\n> > \n> > I forget who it was but someone suggested just dropping 0.8 in global\n> > requirements over the weekend so that?s what I did.\n> > \n> > It appears oslo.db used the SQLAlchemy specifier from master which means that\n> > it won?t work with SQLAlchemy in the 0.8 series. So probably oslo.db should\n> > instead use the one from stable/juno?\n> \n> Master oslo.db has to match the requirements list being used elsewhere in\n> master, so it can?t use the requirements spec from a stable branch.\n> \n> Can we cap oslo.db in juno to 1.2.0? That should work as a minimum\n> version in the requirements list for master, which would let us maintain\n> an overlapping requirements range to support rolling updates.\n> \n> Doug\n> \n> > \n> > ---\n> > Donald Stufft\n> > PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nI think you need a 1.2.1 release that doesn\'t have the broken\nrequirement for sqlalchemy then cap on that in stable/juno.\n\nClark\n\n\n','<61F31B60-A123-442B-91CB-53B85CAA7420@doughellmann.com>',NULL),('<1418685669-sup-1749@fewbar.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-15 15:25:17',-28800,'2014-12-15 23:25:17',NULL,'[Openstack-operators] Heat in production?','We (the TripleO developers) use Heat as part of TripleO to manage small\n(40 nodes) clouds for TripleO. This means that we\'re using Heat to manage\nour bare metal nodes which are in turn managed by nova+ironic.\n\nFor the most part it is only used to bring up new nodes or change\nparameters (not something we do often). For that purpose, it works fine.\n\nIcehouse Heat lacks some really nice features that came out in Juno,\nnot the least of which being that Juno\'s Heat can resume from failed\noperations where Icehouse cannot.\n\nAlso, my employer, HP, is shipping Heat as part of the Helion distribution\nof OpenStack. I\'m not certain if anybody is in full production using\nthe Heat in Helion just yet, as it only recently released.\n\nI also know that Rackspace has been running some kind of Heat public\nbeta/alpha/something for a while, so it might be worth asking them about\ntheir Heat.\n\nExcerpts from Ari Rubenstein\'s message of 2014-12-15 15:10:50 -0800:\n> Hi there,\n> My name is Ari Rubenstein, and I\'m new to the list.? I\'ve been researching Heat.? I was wondering if anyone has direct experience or links to how customers are Heat orchestration in the real world.\n> Use cases?? Experiences?? Best practices?? Gotchas?\n> I\'m working with a customer on an Icehouse based cluster.? They\'re wondering if Heat is ready for production or should be considered beta.? I\'ve heard good things about Heat, but the customer is cautious.\n> Thanks in advance,\n> - Ari\n\n\n','<2072815641.332366.1418685050891.JavaMail.yahoo@jws100160.mail.ne1.yahoo.com>',NULL),('<1418688234-sup-7495@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 16:06:34',-28800,'2014-12-16 00:06:34',NULL,'[openstack-dev] Unsafe Abandon','Excerpts from Ari Rubenstein\'s message of 2014-12-15 12:32:08 -0800:\n> Hi there,\n> I\'m new to the list, and trying to get more information about the following issue:\n> \n> https://bugs.launchpad.net/heat/+bug/1353670\n> Is there anyone on the list who can explain under what conditions a user might hit this?? Workarounds?? ETA for a fix?\n\nHi Ari. Welcome, and thanks for your interest in OpenStack and Heat!\n\nA bit of etiquette first: Please do not reply to existing threads to\nstart a new one. That is known as a \"hijack\":\n\nhttps://wiki.openstack.org/wiki/MailingListEtiquette#Changing_Subject\n\nAlso, for bugs, you\'ll find it\'s best to ask in the comments of the bug,\nas those who are most interested and able to answer should already be\nsubscribed and can respond there.\n\n\n','<857945511.287944.1418675528377.JavaMail.yahoo@jws100112.mail.ne1.yahoo.com>',NULL),('<1418703212-sup-8801@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 20:26:06',-28800,'2014-12-16 04:26:06',NULL,'[openstack-dev] [TripleO] mid-cycle details -- CONFIRMED Feb.\n	18 - 20','I\'m happy to announce we\'ve cleared the schedule and the Mid-Cycle is\nconfirmed for February 18 - 20 in Seattle, WA at HP\'s downtown offices.\n\nPlease refer to the etherpad linked below for details including address\nand instructions for access to the building.\n\nPLEASE make sure you add yourself to the list of confirmed attendees\non the etherpad *BEFORE* booking travel. We have a hard limit of 30\nparticipants, so if you are not certain you have a spot, please contact\nme before booking travel.\n\nExcerpts from Clint Byrum\'s message of 2014-12-01 14:58:58 -0800:\n> Hello! I\'ve received confirmation that our venue, the HP offices in\n> downtown Seattle, will be available for the most-often-preferred\n> least-often-cannot week of Feb 16 - 20.\n> \n> Our venue has a maximum of 20 participants, but I only have 16 possible\n> attendees now. Please add yourself to that list _now_ if you will be\n> joining us.\n> \n> I\'ve asked our office staff to confirm Feb 18 - 20 (Wed-Fri). When they\n> do, I will reply to this thread to let everyone know so you can all\n> start to book travel. See the etherpad for travel details.\n> \n> https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n\n\n','<1417474177-sup-8420@fewbar.com>',NULL),('<1418733697.16928.106.camel@sorcha>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 12:41:37',0,'2014-12-16 12:41:37',NULL,'[openstack-dev] [oslo] interesting problem with config filter','Hi Doug,\n\nOn Mon, 2014-12-08 at 15:58 -0500, Doug Hellmann wrote:\n> As we?ve discussed a few times, we want to isolate applications from\n> the configuration options defined by libraries. One way we have of\n> doing that is the ConfigFilter class in oslo.config. When a regular\n> ConfigOpts instance is wrapped with a filter, a library can register\n> new options on the filter that are not visible to anything that\n> doesn?t have the filter object.\n\nOr to put it more simply, the configuration options registered by the\nlibrary should not be part of the public API of the library.\n\n>  Unfortunately, the Neutron team has identified an issue with this\n> approach. We have a bug report [1] from them about the way we?re using\n> config filters in oslo.concurrency specifically, but the issue applies\n> to their use everywhere. \n> \n> The neutron tests set the default for oslo.concurrency?s lock_path\n> variable to ?$state_path/lock?, and the state_path option is defined\n> in their application. With the filter in place, interpolation of\n> $state_path to generate the lock_path value fails because state_path\n> is not known to the ConfigFilter instance.\n\nIt seems that Neutron sets this default in its etc/neutron.conf file in\nits git tree:\n\n  lock_path = $state_path/lock\n\nI think we should be aiming for defaults like this to be set in code,\nand for the sample config files to contain nothing but comments. So,\nneutron should do:\n\n  lockutils.set_defaults(lock_path=\"$state_path/lock\")\n\nThat\'s a side detail, however.\n\n> The reverse would also happen (if the value of state_path was somehow\n> defined to depend on lock_path),\n\nThis dependency wouldn\'t/shouldn\'t be code - because Neutron *code*\nshouldn\'t know about the existence of library config options.\nNeutron deployers absolutely will be aware of lock_path however.\n\n>  and that?s actually a bigger concern to me. A deployer should be able\n> to use interpolation anywhere, and not worry about whether the options\n> are in parts of the code that can see each other. The values are all\n> in one file, as far as they know, and so interpolation should ?just\n> work?.\n\nYes, if a deployer looks at a sample configuration file, all options\nlisted in there seem like they\'re in-play for substitution use within\nthe value of another option. For string substitution only, I\'d say there\nshould be a global namespace where all options are registered.\n\nNow ... one caveat on all of this ... I do think the string substitution\nfeature is pretty obscure and mostly just used in default values.\n\n> I see a few solutions:\n> \n> 1. Don?t use the config filter at all.\n> 2. Make the config filter able to add new options and still see\n> everything else that is already defined (only filter in one\n> direction).\n> 3. Leave things as they are, and make the error message better.\n\n4. Just tackle this specific case by making lock_path implicitly\nrelative to a base path the application can set via an API, so Neutron\nwould do:\n\n  lockutils.set_base_path(CONF.state_path)\n\nat startup.\n\n5. Make the toplevel ConfigOpts aware of all filters hanging off it, and\nsomehow cycle through all of those filters just when doing string\nsubstitution.\n\n> Because of the deployment implications of using the filter, I?m\n> inclined to go with choice 1 or 2. However, choice 2 leaves open the\n> possibility of a deployer wanting to use the value of an option\n> defined by one filtered set of code when defining another. I don?t\n> know how frequently that might come up, but it seems like the error\n> would be very confusing, especially if both options are set in the\n> same config file.\n> \n> I think that leaves option 1, which means our plans for hiding options\n> from applications need to be rethought.\n> \n> Does anyone else see another solution that I?m missing?\n\nI\'d do something like (3) and (4), then wait to see if it crops up\nmultiple times in the future before tackling a more general solution.\n\nWith option (1), the basic thing to think about is how to maintain API\ncompatibility - if we expose the options through the API, how do we deal\nwith future moves, removals, renames, and changing semantics of those\nconfig options.\n\nMark.\n\n\n\n','<4BCA7D02-38D6-4B5B-A496-8EB259C1A792@doughellmann.com>',NULL),('<1418759063-sup-5722@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 19:47:54',0,'2014-12-16 19:47:54',NULL,'[openstack-dev] [TripleO] Bug Squashing Day','> > On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes <greg at greghaynes.net>\n> > wrote:\n> >\n> >> A couple weeks ago we discussed having a bug squash day. AFAICT we all\n> >> forgot, and we still have a huge bug backlog. I\'d like to propose we\n> >> make next Wed. (12/17, in whatever 24 window is Wed. in your time zone)\n> >> a bug squashing day. Hopefully we can add this as an item to our weekly\n> >> meeting on Tues. to help remind everyone the day before.\n\nFriendly Reminder that tomorrow (or today for some time zones) is our\nbug squash day! I hope to see youall in IRC squashing some of our\n(least) favorite bugs.\n\nRandom Factoid: We currently have 299 open bugs.\n\nCheers,\nGreg\n\n\n','<CAPtRfUE3CBuyb8KFPSAuctZwKXjM=6SiR4GarRMhx=MgH_4RLw@mail.gmail.com>',NULL),('<1418889564-sup-2547@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-18 08:04:48',0,'2014-12-18 08:04:48',NULL,'[openstack-dev] [TripleO] Bug Squashing Day','Excerpts from Gregory Haynes\'s message of 2014-12-16 19:47:54 +0000:\n> > > On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes <greg at greghaynes.net>\n> > > wrote:\n> > >\n> > >> A couple weeks ago we discussed having a bug squash day. AFAICT we all\n> > >> forgot, and we still have a huge bug backlog. I\'d like to propose we\n> > >> make next Wed. (12/17, in whatever 24 window is Wed. in your time zone)\n> > >> a bug squashing day. Hopefully we can add this as an item to our weekly\n> > >> meeting on Tues. to help remind everyone the day before.\n> \n> Friendly Reminder that tomorrow (or today for some time zones) is our\n> bug squash day! I hope to see youall in IRC squashing some of our\n> (least) favorite bugs.\n> \n> Random Factoid: We currently have 299 open bugs.\n\nThanks to everyone who participated in our bug squash day! We are now\ndown to 264 open bugs (down from 299). There was also a fair number of\nbugs filed today as part of our (anti) bug squashing efforts, bringing\nour total bugs operated on today to >50.\n\nThanks, again!\n\nCheers,\nGreg\n\n\n','<1418759063-sup-5722@greghaynes0.opus.gah>',NULL),('<1418920820.5523.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-18 10:40:20',-21600,'2014-12-18 16:40:20',NULL,'[openstack-dev] ask for usage of quota reserve','On Thu, 2014-12-18 at 15:34 +0800, Eli Qiao(Li Yong Qiao) wrote:\n> can anyone tell if we call quotas.reserve() but never call\n> quotas.commit() or quotas.rollback().\n> what will happen?\n\nA reservation is always created with an expiration time; by default,\nthis expiration time is 86400 seconds (1 day) after the time at which\nthe reservation is created.  Expired reservations are deleted by the\n_expire_reservations() periodic task, which is defined on the scheduler.\nThus, if a resource is reserved, but never committed or rolled back, it\nshould continue to affect quota requests for approximately one day, then\nbe automatically rolled back by the scheduler.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<54928389.1020903@linux.vnet.ibm.com>',NULL),('<1418923406-sup-4459@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-18 09:35:27',-28800,'2014-12-18 17:35:27',NULL,'[openstack-dev] [Heat] Convergence proof-of-concept showdown','Excerpts from Anant Patil\'s message of 2014-12-16 07:36:58 -0800:\n> On 16-Dec-14 00:59, Clint Byrum wrote:\n> > Excerpts from Anant Patil\'s message of 2014-12-15 07:15:30 -0800:\n> >> On 13-Dec-14 05:42, Zane Bitter wrote:\n> >>> On 12/12/14 05:29, Murugan, Visnusaran wrote:\n> >>>>\n> >>>>\n> >>>>> -----Original Message-----\n> >>>>> From: Zane Bitter [mailto:zbitter at redhat.com]\n> >>>>> Sent: Friday, December 12, 2014 6:37 AM\n> >>>>> To: openstack-dev at lists.openstack.org\n> >>>>> Subject: Re: [openstack-dev] [Heat] Convergence proof-of-concept\n> >>>>> showdown\n> >>>>>\n> >>>>> On 11/12/14 08:26, Murugan, Visnusaran wrote:\n> >>>>>>>> [Murugan, Visnusaran]\n> >>>>>>>> In case of rollback where we have to cleanup earlier version of\n> >>>>>>>> resources,\n> >>>>>>> we could get the order from old template. We\'d prefer not to have a\n> >>>>>>> graph table.\n> >>>>>>>\n> >>>>>>> In theory you could get it by keeping old templates around. But that\n> >>>>>>> means keeping a lot of templates, and it will be hard to keep track\n> >>>>>>> of when you want to delete them. It also means that when starting an\n> >>>>>>> update you\'ll need to load every existing previous version of the\n> >>>>>>> template in order to calculate the dependencies. It also leaves the\n> >>>>>>> dependencies in an ambiguous state when a resource fails, and\n> >>>>>>> although that can be worked around it will be a giant pain to implement.\n> >>>>>>>\n> >>>>>>\n> >>>>>> Agree that looking to all templates for a delete is not good. But\n> >>>>>> baring Complexity, we feel we could achieve it by way of having an\n> >>>>>> update and a delete stream for a stack update operation. I will\n> >>>>>> elaborate in detail in the etherpad sometime tomorrow :)\n> >>>>>>\n> >>>>>>> I agree that I\'d prefer not to have a graph table. After trying a\n> >>>>>>> couple of different things I decided to store the dependencies in the\n> >>>>>>> Resource table, where we can read or write them virtually for free\n> >>>>>>> because it turns out that we are always reading or updating the\n> >>>>>>> Resource itself at exactly the same time anyway.\n> >>>>>>>\n> >>>>>>\n> >>>>>> Not sure how this will work in an update scenario when a resource does\n> >>>>>> not change and its dependencies do.\n> >>>>>\n> >>>>> We\'ll always update the requirements, even when the properties don\'t\n> >>>>> change.\n> >>>>>\n> >>>>\n> >>>> Can you elaborate a bit on rollback.\n> >>>\n> >>> I didn\'t do anything special to handle rollback. It\'s possible that we \n> >>> need to - obviously the difference in the UpdateReplace + rollback case \n> >>> is that the replaced resource is now the one we want to keep, and yet \n> >>> the replaced_by/replaces dependency will force the newer (replacement) \n> >>> resource to be checked for deletion first, which is an inversion of the \n> >>> usual order.\n> >>>\n> >>\n> >> This is where the version is so handy! For UpdateReplaced ones, there is\n> >> an older version to go back to. This version could just be template ID,\n> >> as I mentioned in another e-mail. All resources are at the current\n> >> template ID if they are found in the current template, even if they is\n> >> no need to update them. Otherwise, they need to be cleaned-up in the\n> >> order given in the previous templates.\n> >>\n> >> I think the template ID is used as version as far as I can see in Zane\'s\n> >> PoC. If the resource template key doesn\'t match the current template\n> >> key, the resource is deleted. The version is misnomer here, but that\n> >> field (template id) is used as though we had versions of resources.\n> >>\n> >>> However, I tried to think of a scenario where that would cause problems \n> >>> and I couldn\'t come up with one. Provided we know the actual, real-world \n> >>> dependencies of each resource I don\'t think the ordering of those two \n> >>> checks matters.\n> >>>\n> >>> In fact, I currently can\'t think of a case where the dependency order \n> >>> between replacement and replaced resources matters at all. It matters in \n> >>> the current Heat implementation because resources are artificially \n> >>> segmented into the current and backup stacks, but with a holistic view \n> >>> of dependencies that may well not be required. I tried taking that line \n> >>> out of the simulator code and all the tests still passed. If anybody can \n> >>> think of a scenario in which it would make a difference, I would be very \n> >>> interested to hear it.\n> >>>\n> >>> In any event though, it should be no problem to reverse the direction of \n> >>> that one edge in these particular circumstances if it does turn out to \n> >>> be a problem.\n> >>>\n> >>>> We had an approach with depends_on\n> >>>> and needed_by columns in ResourceTable. But dropped it when we figured out\n> >>>> we had too many DB operations for Update.\n> >>>\n> >>> Yeah, I initially ran into this problem too - you have a bunch of nodes \n> >>> that are waiting on the current node, and now you have to go look them \n> >>> all up in the database to see what else they\'re waiting on in order to \n> >>> tell if they\'re ready to be triggered.\n> >>>\n> >>> It turns out the answer is to distribute the writes but centralise the \n> >>> reads. So at the start of the update, we read all of the Resources, \n> >>> obtain their dependencies and build one central graph[1]. We than make \n> >>> that graph available to each resource (either by passing it as a \n> >>> notification parameter, or storing it somewhere central in the DB that \n> >>> they will all have to read anyway, i.e. the Stack). But when we update a \n> >>> dependency we don\'t update the central graph, we update the individual \n> >>> Resource so there\'s no global lock required.\n> >>>\n> >>> [1] \n> >>> https://github.com/zaneb/heat-convergence-prototype/blob/distributed-graph/converge/stack.py#L166-L168\n> >>>\n> >>\n> >> A centralized graph and decision making will make the implementation far\n> >> more simpler than distributed. This looks academic, but the simplicity\n> >> beats everything! When each worker has to decide, there needs to be\n> >> lock, only DB transactions are not enough. In contrast, when the\n> >> decision making is centralized, that particular critical section can be\n> >> attempted with transaction and re-attempted if needed.\n> >>\n> > \n> > I\'m concerned that we\'re losing sight of the whole point of convergence.\n> > \n> > Yes, concurrency is hard, and state management is really the only thing\n> > hard about concurrency.\n> > \n> > What Zane is suggesting is a lock-free approach commonly called \'Read\n> > Copy Update\' or \"RCU\". It has high reader concurrency, but relies on\n> > there only being one writer. It is quite simple, and has proven itself\n> > enough to even be included in the Linux kernel:\n> > \n> > http://lwn.net/Articles/263130/\n> > \n> I am afraid Zane is saying the other way: \"distribute the writes but\n> centralize the reads\". Nevertheless, what I meant by having a centralize\n\nOh I missed that the writes were happening by anybody, but the reads\nweren\'t. Thanks.\n\n> decision making is the same thing you are pointing to. By centralize I\n> mean:\n> 1. Have the graph in DB, not the edges distributed in the resource\n> table. Also, having the graph in DB doesn\'t mean we need to lock it each\n> time we update traversal information or compute next set of ready\n> resources/tasks.\n> 2. Take the responsibility of what-to-do-next out of worker. This is the\n> \"writer\" part, where upon receiving a notification the engine will\n> update the graph in DB and compute the next set of resources to be\n> converged (having all dependencies resolved). I agree that there will be\n> multiple instances of engine which could execute this section code (this\n> code will become the critical section), so in that sense it is not\n> centralized. But this approach differs from workers making the decision,\n> where, each worker reads from DB and updates the sync point. Instead, if\n> the workers send \"done\" notification to engine, the engine can update\n> the graph traversal and issue request for next set of tasks. All the\n> workers and observers read from DB, send notifications to engine, while\n> the engine writes to DB. This may not be strictly followed. Please also\n> note that updating a graph doesn\'t mean that we have to lock anything.\n> As the notifications arrive, the graph is updated, in a TX, and\n> re-attempted if the two notifications try to update the same row and the\n> TX fails. The workers are *part of* engine but not really *are the\n> engine*. Given an instance of engine, and multiple workers (greenlet\n> threads), I can see that it turns out to be what you are suggesting\n> about RCU. Please correct me if I am wrong.\n> \n\nSo this is definitely interesting.\n\nRCU works extremely well if you have a high ratio of reads to writes and\na natural single writer. For instance, if you have a game where there\nis a scoring system and no readers do anything that depend on writes\nthat they cause themselves. The views of the scores are all read and\ndisplayed, but updates to the score can just be thrown into an async\nqueue and when the writer gets to them, the score increases, and the\nplayers display the new score the next time they read the score.\n\nIn this case, you have tightly coupled reads to writes, so I can say now\nafter thinking about it that RCU is not a great fit. Letting each entity\ndo an atomic transaction using the DB\'s row level locks will scale out\nbetter than a single writer pattern.\n\nI do see one advantage to having writes separate from workers. That is\nthe fact that the Heat database will likely scale differently than the\nendpoints the plugins in Heat will. So it may make sense to have 100\nworkers doing calls to nova/swift/glance/cinder/etc., but you might only\nhave a database that can reasonably do 10 transactions at once.\n\nThis is premature optimization IMO, but it might make sense to have a\ndisciplined approach to the code so that moving those bits apart later\nwill be possible.\n\n> I do not insist that it has to be the way I am saying. I am merely\n> brainstorming to see if the \"centralized\" write makes sense in this\n> case. I also admit that I do not have performance data, and I am not any\n> DB expert.\n> \n\nIndeed, thanks for your thoughts, they are much appreciated. We have\nquite a few experts that may be reading this thread so if we say\nsomething stupid (likely) they will hopefully correct us. Until then we\ncan discuss things logically and test our hypotheses as necessary. :)\n\n> >> With the distributed approach, I see following drawbacks:\n> >> 1. Every time a resource is done, the peer resources (siblings) are\n> >> checked to see if they are done and the parent is propagated. This\n> >> happens for each resource.\n> > \n> > This is slightly inaccurate.\n> > \n> > Every time a resource is done, resources that depend on that resource\n> > are checked to see if they still have any unresolved dependencies.\n> > \n> \n> Yes. If we have a graph in DB, we should be able to easily compute this.\n> If the edges are distributed and kept along with the resources in the\n> resources, we might have to execute multiple queries or keep the graph\n> in memory.\n> \n> >> 2. The worker has to run through all the resources to see if the stack\n> >> is done, to mark it as completed.\n> > \n> > If a worker completes a resource which has no dependent resources, it\n> > only needs to check to see if all of the other edges of the graph are\n> > complete to mark the state as complete. There is no full traversal\n> > unless you want to make sure nothing regressed, which is not the way any\n> > of the specs read.\n> > \n> \n> I agree. For this same reason I am favoring to have the graph in DB. I\n> also noted that Zane is not against keeping the graph in DB, but only\n> that store the *actual* dependencies in resources (may be physical\n> resource ID?). This is fine I think, though we will be looking at graph\n> table some times(create/update) and looking at these dependencies in\n> resource table at other times (delete/clean-up?). The graph can\n> instantly tell if it is done or not when we look at it, but for\n> clean-ups and delelts we would have to rely on resource table also.\n> \n\nIt\'s important to get a schema that makes sense, but if need be, we can\nadapt as we learn what does and doesn\'t work. I\'d go with the simplest\nschema that makes sense at first. IMO one table for one entity is better\nthan two tables for one entity. 1:1 relationships always seem to be\nabout optimization, not simplification.\n\n> >> 3. The decision to converge is made by each worker resulting in lot of\n> >> contention. The centralized graph restricts the contention point to one\n> >> place where we can use DB transactions. It is easier to maintain code\n> >> where particular decisions are made at a place rather than at many\n> >> places.\n> > \n> > Why not let multiple workers use DB transactions? The contention happens\n> > _only if it needs to happen to preserve transaction consistency_ instead\n> > of _always_.\n> > \n> \n> Sure! When the workers are done with the current resource they can\n> update the DB and pick-up the parent if it is ready. The DB interactions\n> can happen as a TX. But then there would be no\n> one-writer-multiple-reader if we follow this. All the workers write and\n> read.\n> \n> >> 4. The complex part we are trying to solve is to decide on what to do\n> >> next when a resource is done. With centralized graph, this is abstracted\n> >> out to the DB API. The API will return the next set of nodes. A smart\n> >> SQL query can reduce a lot of logic currently being coded in\n> >> worker/engine.\n> > \n> > Having seen many such \"smart\" SQL queries, I have to say, this is\n> > terrifying. Complexity in database access is by far the single biggest\n> > obstacle to scaling out.\n> > \n> > I don\'t really know why you\'d want logic to move into the database. It\n> > is the one place that you must keep simple in order to scale. We can\n> > scale out python like crazy.. but SQL is generally a single threaded,\n> > impossible to debug component. So make the schema obvious and accesses\n> > to it straight forward.\n> > \n> > I think we need to land somewhere between the two approaches though.\n> > Here is my idea for DB interaction, I realize now it\'s been in my head\n> > for a while but I never shared:\n> > \n> > CREATE TABLE resource (\n> >   id ...,\n> >   ! all the stuff now\n> >   version int,\n> >   replaced_by int,\n> >   complete_order int,\n> >   primary key (id, version),\n> >   key idx_replaced_by (replaced_by));\n> > \n> > CREATE TABLE resource_dependencies (\n> >   id ....,\n> >   version int,\n> >   needed_by ...\n> >   primary key (id, version, needed_by));\n> > \n> > Then completion happens something like this:\n> > \n> > BEGIN\n> > SELECT @complete_order := MAX(complete_order) FROM resource WHERE stack_id = :stack_id:\n> > SET @complete_order := @complete_order + 1\n> > UPDATE resource SET complete_order = @complete_order, state=\'COMPLETE\' WHERE id=:id: AND version=:version:;\n> > ! if there is a replaced_version\n> > UPDATE resource SET replaced_by=:version: WHERE id=:id: AND version=:replaced_version:;\n> > SELECT DISTINCT r.id FROM resource r INNER JOIN resource_dependencies rd\n> >        ON r.id = rd.resource_id AND r.version = rd.version\n> > WHERE r.version=:version: AND rd.needed_by=:id: AND r.state != \'COMPLETE\'\n> > <python>\n> > for id in results:\n> >   convergequeue.submit(id)\n> > </python>\n> > COMMIT\n> > \n> > Perhaps I\'ve missed some revelation that makes this hard or impossible.\n> > But I don\'t see a ton of database churn (one update per completion is\n> > meh). I also don\'t see a lot of complexity in the query. The\n> > complete_order can be used to handle deletes in the right order later\n> > (note that I know that is probably the wrong way to do it and sequences\n> > are a thing that can be used for this).\n> > \n> >> 5. What would be the starting point for resource clean-up? The clean-up\n> >> has to start when all the resources are updated. With no centralized\n> >> graph, the DB has to be searched for all the resources with no\n> >> dependencies and with older versions (or having older template keys) and\n> >> start removing them. With centralized graph, this would be a simpler\n> >> with a SQL queries returning what needs to be done. The search space for\n> >> where to start with clean-up will be huge.\n> > \n> > \"Searched\" may be the wrong way. With the table structure above, you can\n> > find everything to delete with this query:\n> > \n> > ! Outright deletes\n> > SELECT r_old.id\n> > FROM resource r_old LEFT OUTER JOIN resource r_new\n> >   ON r_old.id = r_new.id AND r_old.version = :cleanup_version:\n> > WHERE r_new.id IS NULL OR r_old.replaced_by IS NOT NULL\n> > ORDER BY DESC r.complete_order;\n> > \n> > That should delete everything in more or less the right order. I think\n> > for that one you can just delete the rows as they\'re confirmed deleted\n> > from the plugins, no large transaction needed since we\'d not expect\n> > these rows to be updated anymore.\n> > \n> \n> Well, I meant simple SQL queries where we JOIN the graph table and\n> resource table to see if a resource can be taken up for convergence. It\n> is possible that the graph says a resource is ready since it has all the\n> dependencies stisfied, but have a previous version still in progress\n> from previous update. By smart, I never meant any complex queries, but\n> only the ones which solve _our problem_. The queries which you have\n> suggested above is what I meant. I was not sure we were using the DB in\n> the way you are suggesting, hence called for utilizing it in a better\n> way.\n> \n\nUnderstood, and thanks for enduring my fear of SQL logic bombs. :)\n\n> >> 6. When engine restarts, the search space on where to start will be\n> >> huge. With a centralized graph, the abstracted API to get next set of\n> >> nodes makes the implementation of decision simpler.\n> >>\n> >> I am convinced enough that it is simpler to assign the responsibility to\n> >> engine on what needs to be done next. No locks will be required, not\n> >> even resource locks! It is simpler from implementation, understanding\n> >> and maintenance perspective.\n> >>\n> > \n> > I thought you started saying you would need locks, but now saying you\n> > won\'t.\n> \n> No. We wanted to get rid of the stack lock we were using to avoid the\n> concurrency issues, and you had suggested using DB transactions. We had\n> other ideas but DB TX looked cleaner to us and we are proceeding with\n> it.\n> \n\nAwesome. :)\n\n\n','<5490519A.3090804@hp.com>',NULL),('<1418935241.843132252@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2014-12-18 14:40:41',-21600,'2014-12-18 20:40:41',NULL,'[openstack-community] 2015 OpenStack Events Plan and Call for Papers','\nI apologize in advance for those of you who are on multiple mailing lists (Marketing, Community, Women of OpenStack, and the Enterprise workgroup.  Please delete duplicates, thanks!\n \nThe 2015 event plan is now available.   We\'ve posted the information in the OpenStack blog, direct link [ http://www.openstack.org/blog/2014/12/2015-openstack-foundation-events-plan-and-calls-for-papers-available/ ]( http://www.openstack.org/blog/2014/12/2015-openstack-foundation-events-plan-and-calls-for-papers-available/ ). We\'re accepting feedback and input. There are also opportunities to join the Foundation at first half 2015 events in London and Melbourne.  \n \nBe sure to check out the CFP deadlines (Call for Papers/Proposals - requests for speaking sessions).  Many are coming up soon.  For example, the deadline to submit a session request for the June Cloud Expo East, DevOps Summit, Big Data Expo, IoT Expo, and SDDC Expo - all co-located events in New York City - is December 31, 2014.  Sessions are the best way to reach prospective OpenStack users while demonstrating your knowledge and expertise.  \n \nThank you for your support of events this year and we look forward to your participation in 2015.  Happy holidays to you and yours!\n \n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141218/1552ea7e/attachment.html>\n\n',NULL,NULL),('<1419021723-sup-6568@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-19 20:43:28',0,'2014-12-19 20:43:28',NULL,'[openstack-dev] [TripleO] CI/CD report - 2014-12-12 - 2014-12-19','Excerpts from James Polley\'s message of 2014-12-19 17:10:41 +0000:\n> Two major CI outages this week\n> \n> 2014-12-12 - 2014-12-15 - pip install MySQL-python failing on fedora\n> - There was an updated mariadb-devel package, which caused pip install of\n> the python bindings to fail as gcc could not build using the provided\n> headers.\n>  - derekh put in a workaround on the 15th but we have to wait until\n> upstream provides a fixed package for a permanent resolution\n> \n> 2014-12-17 - failures in many projects on py33 tests\n> - Caused by an unexpected interaction between new features in pbr and the\n> way docutils handles python3 compatibility\n> - derekh resolved this by tweaking the build process to not build pbr -\n> just download the latest pbr from upstream\n\nI am a bad person and forgot to update our CI outage etherpad, but we\nhad another outage that was caused by the setuptools PEP440 breakage:\n\nhttps://review.openstack.org/#/c/141659/\n\nWe might be able to revert this now if the world is fixed....\n\n\n','<CAPtRfUH6GWUqe1nUJC5F34hf1P9BHv+OT3pTKV9NVe_1OxUeUA@mail.gmail.com>',NULL),('<1419184201.13766.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-21 17:49:58',0,'2014-12-21 17:49:58',NULL,'[openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16','The extensions are remaining in neutron until the Neutron WSGI Refactor\nis completed so it\'s easier for them to test all extensions and that\nnothing breaks.  I do believe the plan is to move the extensions into\nthe service repos once this is completed.\n\nThanks,\nBrandon\nOn Sun, 2014-12-21 at 10:14 +0000, Evgeny Fedoruk wrote:\n> Hi Doug,\n> How are you? \n> I have a question regarding https://review.openstack.org/#/c/141247/ change set\n> Extension changes are not part of this change. I also see the whole extension mechanism is out of the new repository.\n> I may be missed something. Are we replacing  the mechanism with something else? Or we will add it separately in other change set?\n> \n> Thanks,\n> Evg\n> \n> -----Original Message-----\n> From: Doug Wiegley [mailto:dougw at a10networks.com] \n> Sent: Sunday, December 14, 2014 7:46 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: [openstack-dev] [neutron][lbaas] Canceling lbaas meeting 12/16\n> \n> Unless someone has an urgent agenda item, and due to the mid-cycle for Octavia, which has a bunch of overlap with the lbaas team, let?s cancel this week. If you have post-split lbaas v2 questions, please find me in #openstack-lbaas.\n> \n> The only announcement was going to be: If you are waiting to re-submit/submit lbaasv2 changes for the new repo, please monitor this review, or make your change dependent on it:\n> \n> https://review.openstack.org/#/c/141247/\n> \n> \n> Thanks,\n> Doug\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D115164D7987674C94CA87CD65704AC32831B891@ILMB2.corp.radware.com>',NULL),('<1419443658-sup-7248@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-24 10:18:08',-28800,'2014-12-24 18:18:08',NULL,'[openstack-dev] [heat] Application level HA via Heat','Excerpts from Renat Akhmerov\'s message of 2014-12-24 03:40:22 -0800:\n> Hi\n> \n> > Ok, I\'m quite happy to accept this may be a better long-term solution, but\n> > can anyone comment on the current maturity level of Mistral?  Questions\n> > which spring to mind are:\n> > \n> > - Is the DSL stable now?\n> \n> You can think ?yes? because although we keep adding new features we do it in a backwards compatible manner. I personally try to be very cautious about this.\n> \n> > - What\'s the roadmap re incubation (there are a lot of TBD\'s here:\n> >    https://wiki.openstack.org/wiki/Mistral/Incubation)\n> \n> Ooh yeah, this page is very very obsolete which is actually my fault because I didn?t pay a lot of attention to this after I heard all these rumors about TC changing the whole approach around getting projects incubated/integrated.\n> \n> I think incubation readiness from a technical perspective is good (various style checks, procedures etc.), even if there?s still something that we need to adjust it must not be difficult and time consuming. The main question for the last half a year has been ?What OpenStack program best fits Mistral??. So far we?ve had two candidates: Orchestration and some new program (e.g. Workflow Service). However, nothing is decided yet on that.\n> \n\nIt\'s probably worth re-thinking the discussion above given the governance\nchanges that are being worked on:\n\nhttp://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html\n\n\n','<2EF9C3F5-FA84-488A-BE0D-F17D4F9D6D60@mirantis.com>',NULL),('<1419465844.1579869.206582569.45614D69@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-12-24 16:04:04',-28800,'2014-12-25 00:04:04',NULL,'[OpenStack-docs] Galera Cluster - HA Guide','Hey,\n\nWanted to let you all know, I just sent the update to the Galera Cluster\npage in the High Availability guide out for review.\n\nmerry christmas,\n\n  K. Dyer\n\nOn Fri, Oct 31, 2014, at 07:18 AM, Kenneth P. J. Dyer wrote:\n> \n> Hi,\n> \n> I\'m Kenneth, tech writer with Avocet Editors.  I\'m updating the docs for \n> Galera Cluster at Codership.  Sakari Keskitalo suggested I talk to you \n> all about doing some work on the Galera entry for your HA Guide while \n> I\'m at it.\n> \n> What do I need to do to get set up?\n> \n> -- \n> \n>       Kenneth P. J. Dyer,\n>       Avocet Editorial Consultants\n>       kenneth at avoceteditors.com\n> \n> \n> _______________________________________________\n> OpenStack-docs mailing list\n> OpenStack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<5453A84B.7030908@avoceteditors.com>',NULL),('<1419621614.2963.5.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/community',NULL,'2014-12-26 11:20:14',-28800,'2014-12-26 19:20:14',NULL,'[openstack-community] OpenStack Community Weekly Newsletter (Dec 20\n	- 26)','            Last newsletter of 2014, see you again in 2015!\n\n\nUniversity of Hawaii College of Education harnesses OpenStack to support\nfaculty research via a secure private cloud\n\nOpenStack powers a Holodeck at University of Hawaii at Manoa... Read the\nfull story on Mirantis blog.\n\n\nThe TOSCA Cloud State of the Union\n\nA nice summary of the status of OpenStack Heat and the relation between\nthe different specifications to describe topology and orchestration in\ncloud world.\n\n\nRelevant Conversations\n\n      * Application level HA via Heat \n      * The state of nova-network to neutron migration \n      * [Openstack-operators] Packaging sample config versions  \n\nDeadlines and Development Priorities\n\n      * [nova] Kilo Project Priorities \n      * Neutron Priorities for Kilo \n      * [Nova] Mid-cycle meetup details for kilo\n\nSecurity Advisories and Notices\n\n      * [OSSA-2014-041] Glance v2 API unrestricted path traversal\n\nReports from Previous Events\n\n      * Rhones-Alpes meetup summary\n\nTips ?n Tricks\n\n      * By Lars Kellogg-Stedman: Accessing the serial console of your\n        Nova servers\n      * By Darryl Cauldwell:Create A vSphere OpenStack Glance Windows VM\n        Image \n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * [Call for Speaker, Sponsor, Participants] OpenStack Day in Korea\n        - Feb. 05, 2015\n      * Jan 15, 2015 Deep Dive into Trove Austin, Texas, US\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * Volunteers needed for OpenStack Stand at FOSDEM in Brussels \n      * Symantec joins OpenStack Foundation as Gold Member!\n      * Keystone Middleware 1.3.1 release \n      * OpenStack Crossproject Meeting: suspended for holidays.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * how to extract the image details from glance api\n      * HEAT grub commands for CentOS 7 Nova Instance\n      * swift change replication address\n      * Solaris 11.2 Openstack - CSRF Verification failed\n      * How to retrieve ceilometer statistics for the meter\n        \"network.incoming.bytes\" for an instance\n      * Nova Scheduler warning \"Host has more disk space than database\n        expected\" on launching instances\n      * How to configure VirtualBox based testing environment?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20141226/f40cf604/attachment.html>\n\n',NULL,NULL),('<1419621614.2963.5.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2014-12-26 11:20:14',-28800,'2014-12-26 19:20:14',NULL,'[openstack-announce] OpenStack Community Weekly Newsletter (Dec 20\n	- 26)','            Last newsletter of 2014, see you again in 2015!\n\n\nUniversity of Hawaii College of Education harnesses OpenStack to support\nfaculty research via a secure private cloud\n\nOpenStack powers a Holodeck at University of Hawaii at Manoa... Read the\nfull story on Mirantis blog.\n\n\nThe TOSCA Cloud State of the Union\n\nA nice summary of the status of OpenStack Heat and the relation between\nthe different specifications to describe topology and orchestration in\ncloud world.\n\n\nRelevant Conversations\n\n      * Application level HA via Heat \n      * The state of nova-network to neutron migration \n      * [Openstack-operators] Packaging sample config versions  \n\nDeadlines and Development Priorities\n\n      * [nova] Kilo Project Priorities \n      * Neutron Priorities for Kilo \n      * [Nova] Mid-cycle meetup details for kilo\n\nSecurity Advisories and Notices\n\n      * [OSSA-2014-041] Glance v2 API unrestricted path traversal\n\nReports from Previous Events\n\n      * Rhones-Alpes meetup summary\n\nTips ?n Tricks\n\n      * By Lars Kellogg-Stedman: Accessing the serial console of your\n        Nova servers\n      * By Darryl Cauldwell:Create A vSphere OpenStack Glance Windows VM\n        Image \n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * [Call for Speaker, Sponsor, Participants] OpenStack Day in Korea\n        - Feb. 05, 2015\n      * Jan 15, 2015 Deep Dive into Trove Austin, Texas, US\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * Volunteers needed for OpenStack Stand at FOSDEM in Brussels \n      * Symantec joins OpenStack Foundation as Gold Member!\n      * Keystone Middleware 1.3.1 release \n      * OpenStack Crossproject Meeting: suspended for holidays.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * how to extract the image details from glance api\n      * HEAT grub commands for CentOS 7 Nova Instance\n      * swift change replication address\n      * Solaris 11.2 Openstack - CSRF Verification failed\n      * How to retrieve ceilometer statistics for the meter\n        \"network.incoming.bytes\" for an instance\n      * Nova Scheduler warning \"Host has more disk space than database\n        expected\" on launching instances\n      * How to configure VirtualBox based testing environment?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20141226/f40cf604/attachment.html>\n\n',NULL,NULL),('<1419621614.2963.5.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-26 11:20:14',-28800,'2014-12-26 19:20:14',NULL,'[Openstack-operators] OpenStack Community Weekly Newsletter (Dec 20\n	- 26)','            Last newsletter of 2014, see you again in 2015!\n\n\nUniversity of Hawaii College of Education harnesses OpenStack to support\nfaculty research via a secure private cloud\n\nOpenStack powers a Holodeck at University of Hawaii at Manoa... Read the\nfull story on Mirantis blog.\n\n\nThe TOSCA Cloud State of the Union\n\nA nice summary of the status of OpenStack Heat and the relation between\nthe different specifications to describe topology and orchestration in\ncloud world.\n\n\nRelevant Conversations\n\n      * Application level HA via Heat \n      * The state of nova-network to neutron migration \n      * [Openstack-operators] Packaging sample config versions  \n\nDeadlines and Development Priorities\n\n      * [nova] Kilo Project Priorities \n      * Neutron Priorities for Kilo \n      * [Nova] Mid-cycle meetup details for kilo\n\nSecurity Advisories and Notices\n\n      * [OSSA-2014-041] Glance v2 API unrestricted path traversal\n\nReports from Previous Events\n\n      * Rhones-Alpes meetup summary\n\nTips ?n Tricks\n\n      * By Lars Kellogg-Stedman: Accessing the serial console of your\n        Nova servers\n      * By Darryl Cauldwell:Create A vSphere OpenStack Glance Windows VM\n        Image \n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * [Call for Speaker, Sponsor, Participants] OpenStack Day in Korea\n        - Feb. 05, 2015\n      * Jan 15, 2015 Deep Dive into Trove Austin, Texas, US\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * Volunteers needed for OpenStack Stand at FOSDEM in Brussels \n      * Symantec joins OpenStack Foundation as Gold Member!\n      * Keystone Middleware 1.3.1 release \n      * OpenStack Crossproject Meeting: suspended for holidays.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * how to extract the image details from glance api\n      * HEAT grub commands for CentOS 7 Nova Instance\n      * swift change replication address\n      * Solaris 11.2 Openstack - CSRF Verification failed\n      * How to retrieve ceilometer statistics for the meter\n        \"network.incoming.bytes\" for an instance\n      * Nova Scheduler warning \"Host has more disk space than database\n        expected\" on launching instances\n      * How to configure VirtualBox based testing environment?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141226/f40cf604/attachment.html>\n\n',NULL,NULL),('<141982859165819630@unknownmsgid>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-06 10:34:18',-25200,'2013-08-06 17:34:18',NULL,'[Openstack] RPC timeout in nova-compute','Hello jiaan,\n\nCan you paste your nova and quantum(l3-agent,dhcp) conf , even logs for\nquantum.\n\nRegards,\nRitesh\n\nSent from my Windows Phone From: Jiaan Zeng\nSent: 06-08-2013 09:12 PM\nTo: Ritesh Nanda; openstack at lists.openstack.org\nSubject: Re: [Openstack] RPC timeout in nova-compute\nI use a single node setup. The /var/log/rabbitmq-<hostname> log does\nshow some warnings e.g., \"exception on TCP connection <0.13967.0> from\n192.168.100.1:57097 connection_closed_abruptly\". Below is the log\nfile. What does that exception mean?\n\n=INFO REPORT==== 4-Aug-2013::16:39:00 ===\nclosing TCP connection <0.6353.1> from 192.168.100.1:57249\n\n=INFO REPORT==== 4-Aug-2013::16:39:00 ===\nclosing TCP connection <0.13958.0> from 192.168.100.1:57092\n\n=WARNING REPORT==== 4-Aug-2013::16:39:00 ===\nexception on TCP connection <0.8253.2> from 192.168.100.1:57455\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:00 ===\nclosing TCP connection <0.8253.2> from 192.168.100.1:57455\n\n=WARNING REPORT==== 4-Aug-2013::16:39:00 ===\nexception on TCP connection <0.14191.0> from 192.168.100.1:57103\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:00 ===\nclosing TCP connection <0.14191.0> from 192.168.100.1:57103\n\n=INFO REPORT==== 4-Aug-2013::16:39:01 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58251\n\n=INFO REPORT==== 4-Aug-2013::16:39:01 ===\nstarting TCP connection <0.25306.109> from 192.168.100.1:58251\n\n=INFO REPORT==== 4-Aug-2013::16:39:01 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58252\n\n=INFO REPORT==== 4-Aug-2013::16:39:01 ===\nstarting TCP connection <0.25383.109> from 192.168.100.1:58252\n\n=WARNING REPORT==== 4-Aug-2013::16:39:14 ===\nexception on TCP connection <0.7516.2> from 192.168.100.1:57426\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.7516.2> from 192.168.100.1:57426\n\n=WARNING REPORT==== 4-Aug-2013::16:39:14 ===\nexception on TCP connection <0.13967.0> from 192.168.100.1:57097\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.13967.0> from 192.168.100.1:57097\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.25306.109> from 192.168.100.1:58251\n\n=WARNING REPORT==== 4-Aug-2013::16:39:14 ===\nexception on TCP connection <0.25383.109> from 192.168.100.1:58252\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.25383.109> from 192.168.100.1:58252\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.15319.1> from 192.168.100.1:57346\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.14119.0> from 192.168.100.1:57102\n\n=WARNING REPORT==== 4-Aug-2013::16:39:14 ===\nexception on TCP connection <0.13978.0> from 192.168.100.1:57098\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:14 ===\nclosing TCP connection <0.13978.0> from 192.168.100.1:57098\n\n=WARNING REPORT==== 4-Aug-2013::16:39:15 ===\nexception on TCP connection <0.13989.0> from 192.168.100.1:57099\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\nclosing TCP connection <0.13989.0> from 192.168.100.1:57099\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\nclosing TCP connection <0.14011.0> from 192.168.100.1:57101\n\n=WARNING REPORT==== 4-Aug-2013::16:39:15 ===\nexception on TCP connection <0.14000.0> from 192.168.100.1:57100\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\nclosing TCP connection <0.14000.0> from 192.168.100.1:57100\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58253\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\nstarting TCP connection <0.25600.109> from 192.168.100.1:58253\n\n=INFO REPORT==== 4-Aug-2013::16:39:15 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58255\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58260\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\nstarting TCP connection <0.25673.109> from 192.168.100.1:58260\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58262\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\nstarting TCP connection <0.25699.109> from 192.168.100.1:58262\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58263\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\nstarting TCP connection <0.25708.109> from 192.168.100.1:58263\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58264\n\n=INFO REPORT==== 4-Aug-2013::16:39:16 ===\nstarting TCP connection <0.25730.109> from 192.168.100.1:58264\n\n=INFO REPORT==== 4-Aug-2013::16:39:36 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58265\n\n=INFO REPORT==== 4-Aug-2013::16:39:36 ===\nstarting TCP connection <0.26098.109> from 192.168.100.1:58265\n\n=INFO REPORT==== 4-Aug-2013::16:41:07 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58276\n\n=INFO REPORT==== 4-Aug-2013::16:41:07 ===\nstarting TCP connection <0.27137.109> from 192.168.100.1:58276\n\n=INFO REPORT==== 4-Aug-2013::16:41:36 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58280\n\n=INFO REPORT==== 4-Aug-2013::16:41:36 ===\nstarting TCP connection <0.27569.109> from 192.168.100.1:58280\n\n=INFO REPORT==== 4-Aug-2013::16:54:49 ===\nChanging password for \'guest\'\n\n=WARNING REPORT==== 4-Aug-2013::16:58:51 ===\nexception on TCP connection <0.27137.109> from 192.168.100.1:58276\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:51 ===\nclosing TCP connection <0.27137.109> from 192.168.100.1:58276\n\n=WARNING REPORT==== 4-Aug-2013::16:58:52 ===\nexception on TCP connection <0.25609.109> from 192.168.100.1:58255\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25609.109> from 192.168.100.1:58255\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.26098.109> from 192.168.100.1:58265\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25600.109> from 192.168.100.1:58253\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.27569.109> from 192.168.100.1:58280\n\n=WARNING REPORT==== 4-Aug-2013::16:58:52 ===\nexception on TCP connection <0.25699.109> from 192.168.100.1:58262\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25699.109> from 192.168.100.1:58262\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25627.109> from 192.168.100.1:58259\n\n=WARNING REPORT==== 4-Aug-2013::16:58:52 ===\nexception on TCP connection <0.25618.109> from 192.168.100.1:58258\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25618.109> from 192.168.100.1:58258\n\n=WARNING REPORT==== 4-Aug-2013::16:58:52 ===\nexception on TCP connection <0.25673.109> from 192.168.100.1:58260\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25673.109> from 192.168.100.1:58260\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25730.109> from 192.168.100.1:58264\n\n=WARNING REPORT==== 4-Aug-2013::16:58:52 ===\nexception on TCP connection <0.25708.109> from 192.168.100.1:58263\nconnection_closed_abruptly\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nclosing TCP connection <0.25708.109> from 192.168.100.1:58263\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58286\n\n=INFO REPORT==== 4-Aug-2013::16:58:52 ===\nstarting TCP connection <0.6987.110> from 192.168.100.1:58286\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58287\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\nstarting TCP connection <0.6996.110> from 192.168.100.1:58287\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58290\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\nstarting TCP connection <0.7018.110> from 192.168.100.1:58290\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58291\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\nstarting TCP connection <0.7027.110> from 192.168.100.1:58291\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58295\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\nstarting TCP connection <0.7107.110> from 192.168.100.1:58295\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58296\n\n=INFO REPORT==== 4-Aug-2013::16:58:53 ===\nstarting TCP connection <0.7116.110> from 192.168.100.1:58296\n\n=INFO REPORT==== 4-Aug-2013::16:59:27 ===\nLimiting to approx 924 file handles (829 sockets)\n\n=INFO REPORT==== 4-Aug-2013::16:59:27 ===\nMemory limit set to 25741MB of 64354MB total.\n\n=INFO REPORT==== 4-Aug-2013::16:59:27 ===\nmsg_store_transient: using rabbit_msg_store_ets_index to provide index\n\n=INFO REPORT==== 4-Aug-2013::16:59:27 ===\nmsg_store_persistent: using rabbit_msg_store_ets_index to provide index\n\n=WARNING REPORT==== 4-Aug-2013::16:59:27 ===\nmsg_store_persistent: rebuilding indices from scratch\n\n=INFO REPORT==== 4-Aug-2013::16:59:27 ===\nstarted TCP Listener on [::]:5672\n\n=INFO REPORT==== 4-Aug-2013::16:59:28 ===\naccepted TCP connection on [::]:5672 from 192.168.100.1:58320\n\n\n\n\n\n\nOn Mon, Aug 5, 2013 at 3:01 PM, Ritesh Nanda <riteshnanda09 at gmail.com> wrote:\n> no i was taking about in case you have multi-node setup, can you share your\n> /var/log/rabbitmq-<hostname> log , it must be showing something when you get\n> rpc error in nova.\n>\n>\n> On Mon, Aug 5, 2013 at 11:50 PM, Jiaan Zeng <l.allen09 at gmail.com> wrote:\n>>\n>> Hi Ritesh,\n>>\n>> I am not following. All the services run on a single node, i.e.,\n>> compute node and control node co-locate. Do you mean I should remove\n>> nova-conductor in a single node setup?\n>>\n>> The sql_connection string is as follows.\n>> sql_connection=mysql://nova:nova at IP/nova\n>>\n>> On Mon, Aug 5, 2013 at 12:58 PM, Ritesh Nanda <riteshnanda09 at gmail.com>\n>> wrote:\n>> > Hello ,\n>> >\n>> > Please check nova-conductor should be not on the compute node , try\n>> > mentioning sql_connection string in nova.conf on compute node.\n>> >\n>> >\n>> > On Mon, Aug 5, 2013 at 3:45 PM, Somanchi Trinath-B39208\n>> > <B39208 at freescale.com> wrote:\n>> >>\n>> >> Can you post the exact error from the nova log...\n>> >>\n>> >> --\n>> >> Trinath Somanchi - B39208\n>> >> trinath.somanchi at freescale.com | extn: 4048\n>> >>\n>> >> -----Original Message-----\n>> >> From: Jiaan Zeng [mailto:l.allen09 at gmail.com]\n>> >> Sent: Monday, August 05, 2013 7:49 AM\n>> >> To: openstack at lists.openstack.org\n>> >> Subject: [Openstack] RPC timeout in nova-compute\n>> >>\n>> >> Hi,\n>> >>\n>> >> I have been struggling on setting up quantum with grizzly for a long\n>> >> time.\n>> >> From nova-compute.log, I can see there is a RPC timeout error from\n>> >> get_instance_nw_info() function in file\n>> >> /usr/lib/python2.7/dist-packages/nova/network/api.py\n>> >>\n>> >> quantum-server is listening on 0.0.0.0:9696\n>> >>\n>> >> I already set network_api_class=nova.network.quantumv2.api.API. Isn\'t\n>> >> the\n>> >> get_instance_nw_info() function supposed to be in\n>> >> /usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py?\n>> >>\n>> >> It seems nova compute is not picking up the network_api_class setting\n>> >> although I restarted nova service after the configuration file was\n>> >> changed.\n>> >>\n>> >> Any clues why this is happening? Thanks a lot.\n>> >>\n>> >> --\n>> >> Regards,\n>> >> Jiaan\n>> >>\n>> >> _______________________________________________\n>> >> Mailing list:\n>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> >> Post to     : openstack at lists.openstack.org\n>> >> Unsubscribe :\n>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> >>\n>> >>\n>> >>\n>> >> _______________________________________________\n>> >> Mailing list:\n>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> >> Post to     : openstack at lists.openstack.org\n>> >> Unsubscribe :\n>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> >\n>> >\n>> >\n>> >\n>> > --\n>> >\n>> >  With Regards\n>> >\n>> >  Ritesh Nanda\n>> >\n>> >\n>> >\n>> >\n>>\n>>\n>>\n>> --\n>> Regards,\n>> Jiaan\n>\n>\n>\n>\n> --\n>\n>  With Regards\n>\n>  Ritesh Nanda\n>\n>\n>\n>\n\n\n\n-- \nRegards,\nJiaan\n\n\n',NULL,NULL),('<1419896367.3415.7.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-29 15:39:27',-28800,'2014-12-29 23:39:27',NULL,'[Openstack-operators] Fostering OpenStack Users','On Tue, 2014-12-30 at 09:57 +1300, James Dempsey wrote:\n> How do you help new OpenStack users learn to build awesome stuff in your\n> OpenStack clouds?\n\nGreat topic. I don\'t think there is much literature specific for\nOpenStack around this. I have seen a lot of \'getting started\' guides for\nother services, mostly public clouds. \n\nI guess it would make good content for the end user portal,\nhttp://developer.openstack.org\n\n/stef\n\n\n\n','<54A1C03F.30204@catalyst.net.nz>',NULL),('<1419957256.3402.2.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-30 10:34:16',-21600,'2014-12-30 16:34:16',NULL,'[openstack-dev] [Nova] should \'ip address\' be retrived when\n decribe host?','On Tue, 2014-12-30 at 14:52 +0800, Lingxian Kong wrote:\n> Just as what Jay Lau said, \'nova hypervisor-show <hypervisor_id>\'\n> indeed returns host ip address, and there are more other information\n> included than \'nova host-describe <hostname>\'. I feel a little\n> confused about the \'host\' and \'hypervisor\', what\'s the difference\n> between them? For cloud operator, maybe \'host\' is more usefull and\n> intuitive for management than \'hypervisor\'. From the implementation\n> perspective, both \'compute_nodes\' and \'services\' database tables are\n> used for them. Should them be combined for more common use cases?\n\nWell, the host and the hypervisor are conceptually distinct objects.\nThe hypervisor is, obviously, the thing on which all the VMs run.  The\nhost, though, is the node running the corresponding nova-compute\nservice, which may be separate from the hypervisor.  For instance, on\nXen-based setups, the host runs in a VM on the hypervisor.  There has\nalso been discussion of allowing one host to be responsible for multiple\nhypervisors, which would be useful for providers with large numbers of\nhypervisors.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CALjNAZ2aEBTJ2N1CAWko6gLkSjF6jxb+ywn=gaPQiMgswC4TtQ@mail.gmail.com>',NULL),('<141DEFAD-6E69-4430-892D-F70E929DDD08@rackspace.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-16 22:01:19',0,'2014-01-16 22:01:19',NULL,'[Openstack] [nova] [rfc] drop XML from v3 API entirely','On Jan 16, 2014, at 6:22 AM, Sean Dague wrote:\n\n> That also assumes that survey responders understood the question the way\n> we are interpreting it. The actual question should have been:\n> \n> What toolkits do you use to interface with the OpenStack API?\n> * OpenStack command line (i.e. nova cli)\n> * openstack python libraries\n> * jclouds\n> * deltacloud\n> ...\n> * other - please specify\n> * none - wrote our own\n> \n> If you wrote your own toolkit for accessing the OpenStack API what wire\n> format are you using?\n> * JSON\n> * XML\n> \n> If you wrote your own toolkit for accessing the OpenStack API what\n> programming language did you write it in?\n> * C/C++\n> * C#\n> * Java\n> * Python\n> * Perl\n> * PHP\n> * Ruby\n> * Other (please specify)\n> \n> \n> Because the question as worded assumes far too much shared context and\n> understanding in what we were looking for. We all understood what we\n> wanted, but didn\'t unroll that in a specific enough way in the user survey.\n\nThis is good start on this stuff. It reminds me of an email Ryan Lane sent to the user-committee list [1]. I think now is the time to start asking for this kind of information in the user survey.\n\nThe user survey is mostly targeted at OpenStack operators right now so the wording might be kind of tricky but we need to try before the next big user survey push.\n\nI think it\'s worthwhile to start a new thread and formulate these questions. I\'ll kick it off right now.\n\nEverett\n\n[1] http://lists.openstack.org/pipermail/user-committee/2013-November/000186.html\n\n','<52D7CEEF.2090206@dague.net>',NULL),('<1420366005.6110551.1374196694686.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 18:18:14',-25200,'2013-07-19 01:18:14',NULL,'[openstack-dev] [vmware] VMwareAPI sub-team status update','I figure this out BTW. I had set up the account as \"hartsock\" then change the name to \"hartsocks\" the single sign on recognized me as the same person but the gerrit review system did not. I\'ve moved the patch under \"hartsocks\" and now I can see all the settings. I would like to have the accounts merged so I get all my brownie points. But, at least the mystery was solved.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"David Ripton\" <dripton at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, July 3, 2013 10:25:47 AM\n> Subject: Re: [openstack-dev] [vmware] VMwareAPI sub-team status update\n> \n> On 07/03/2013 11:51 AM, Shawn Hartsock wrote:\n> \n> > Work in progress:\n> > * https://review.openstack.org/#/c/35502/ <- I can\'t click the \"Work in\n> > progress button\" I\'m not sure how else to signal that I\'m still working...\n> > help?\n> \n> It\'s your patch.  You should be able to.  (I just successfully put one\n> of my reviews into WIP state and then back to Ready for Review, so it\'s\n> not globally broken.)  Are you logged into Gerrit?\n> \n> --\n> David Ripton   Red Hat   dripton at redhat.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51D45E9B.7010701@redhat.com>',NULL),('<1420404780-sup-2486@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-04 12:55:13',-28800,'2015-01-04 20:55:13',NULL,'[openstack-dev] [TripleO] Meetup Reminder','Happy New Year!\n\nJust a friendly reminder to those of you who are interested in TripleO,\nwe have a three-day Meetup scheduled for February 18-20 in Seattle, WA.\nAll are welcome, though space is limited to 30 participants. Thus far we\nhave 8 people signed up in the etherpad:\n\nhttps://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup\n\nPlease do add yourself to the list if you intend to come. There is\ninformation on hotels and we will add any event notifications and agenda\nitems that come up.\n\nThanks, and see you all there!\n\n\n',NULL,NULL),('<1420474679.3172.1.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-05 10:17:59',-21600,'2015-01-05 16:17:59',NULL,'[Openstack] [OpenStackClient] Adding Image \'member\' commands','(Shouldn\'t this be on openstack-dev?)\n\nOn Fri, 2015-01-02 at 14:10 -0600, Dean Troyer wrote:\n\n> * Is --no-share the correct antonym of --share?  --unshare maybe?  We\n> have a pattern of using regular English words were possible (enable|\n> disable) rather than the GNU style of prepending \'no-\' to options, but\n> that is my current backup.\n\nMy mental model insists that \"--no-share\" would remove all shares, so\nperhaps that\'s not the correct antonym.  How about \"--grant\" and\n\"--revoke\"?\n\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAOJFoEt8+DfHJ7wtgZic8afW+i_eiRExfvPNn5vdauoBNXyjug@mail.gmail.com>',NULL),('<1420570013.2984.6.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-06 12:46:53',-21600,'2015-01-06 18:46:53',NULL,'[openstack-dev] [api] [sdk] Proposal to achieve consistency in\n client side sorting','On Tue, 2015-01-06 at 12:19 -0600, Anne Gentle wrote:\n> I\'m all for consistency. Sounds like a great case for the API Working\n> Group to document. You can propose a patch describing the way we want\n> sorting to work. \n> \n> \n> See https://review.openstack.org/#/q/project:openstack/api-wg,n,z\n\nI really think that the API WG should be responsible for the REST API\nonly, TBH, and maybe for the Pythonic APIs.  Once we start talking about\nCLI options, I think that\'s outside the API WG\'s perview, and we\nprobably should have that be up to CLI authors.  My thinking is that a\nREST API and a Python API are both used by developers, where we have one\nset of conventions; but when you start talking about CLI, you\'re really\ntalking about UX, and the rules there can be vastly different.\n\nNow, my personal preference on the CLI side is that \"--sort key[:dir]\"\nis the way to go, but I helped hash that out in the novaclient\nimplementation as a reviewer.  I also had suggestions about how it\nshould be transmitted in the REST API, but that had already been settled\nat the blueprint phase; that may be something the API WG will want to\ntake up and review and provide guidance on now, though?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAD0KtVFcCO0K=g90vVZfs0ZD4bfpsYEnm673NMKetnGbvLOw-A@mail.gmail.com>',NULL),('<1420571982.334.1357171495154.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-03 00:04:55',0,'2013-01-03 00:04:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #94','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/94/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/94\n[SCP] Copying console log.\n\n\n','<1940578373.319.1357085086404.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1420651182-sup-4166@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-07 09:29:56',-28800,'2015-01-07 17:29:56',NULL,'[openstack-dev] [TripleO] Switching CI back to amd64','Excerpts from Derek Higgins\'s message of 2015-01-07 02:51:41 -0800:\n> Hi All,\n>     I intended to bring this up at this mornings meeting but the train I\n> was on had no power sockets (and I had no battery) so sending to the\n> list instead.\n> \n> We currently run our CI with on images built for i386, we took this\n> decision a while back to save memory ( at the time is allowed us to move\n> the amount of memory required in our VMs from 4G to 2G (exactly where in\n> those bands the hard requirements are I don\'t know)\n> \n> Since then we have had to move back to 3G for the i386 VM as 2G was no\n> longer enough so the saving in memory is no longer as dramatic.\n> \n> Now that the difference isn\'t as dramatic, I propose we switch back to\n> amd64 (with 4G vms) in order to CI on what would be closer to a\n> production deployment and before making the switch wanted to throw the\n> idea out there for others to digest.\n> \n> This obviously would impact our capacity as we will have to reduce the\n> number of testenvs per testenv hosts. Our capacity (in RH1 and roughly\n> speaking) allows us to run about 1440 ci jobs per day. I believe we can\n> make the switch and still keep capacity above 1200 with a few other changes\n> 1. Add some more testenv hosts, we have 2 unused hosts at the moment and\n> we can probably take 2 of the compute nodes from the overcloud.\n> 2. Kill VM\'s at the end of each CI test (as opposed to leaving them\n> running until the next CI test kills them), allowing us to more\n> successfully overcommit on RAM\n> 3. maybe look into adding swap on the test env hosts, they don\'t\n> currently have any, so over committing RAM is a problem the the OOM\n> killer is handling from time to time (I only noticed this yesterday).\n> \n> The other benefit to doing this is that is we were to ever want to CI\n> images build with packages (this has come up in previous meetings) we\n> wouldn\'t need to provide i386 packages just for CI, while the rest of\n> the world uses the amd64.\n\n+1 on all counts.\n\nIt\'s also important to note that we should actually have a whole new\nrack of servers added to capacity soon (I think soon is about 6 months\nso far, but we are at least committed to it). So this would be, at worst,\na temporary loss of 240 jobs per day.\n\n\n','<54AD0FBD.8030502@redhat.com>',NULL),('<1420663601988.02420434@Nodemailer>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-07 12:46:42',-28800,'2015-01-07 20:46:42',NULL,'[openstack-dev] [Keystone] Is anyone working on the following\n patch?','Hmmm... Might want to check with Morgan to make sure we want that. I thought he had (and probably merged) an alternative. Otherwise I\'m fine if you want to pick it up and rebase it.\n\n\n\n?\nSent from Mailbox\n\nOn Wed, Jan 7, 2015 at 2:48 PM, Dolph Mathews <dolph.mathews at gmail.com>\nwrote:\n\n> On Wed, Jan 7, 2015 at 10:32 AM, Lance Bragstad <lbragstad at gmail.com> wrote:\n>> https://review.openstack.org/#/c/113586/ is owned by dstanek but I\n>> understand he is out this week at a conference?\n>>\n>>\n> Correct.\n>> It might be worth dropping in #openstack-keystone and seeing if dstanek\n>> would be alright with you picking it up, since you\'re building on it.\n>>\n> I CC\'d him here, as I figure async communication might be easier for him if\n> he\'s mostly AFK.\n>>\n>> On Wed, Jan 7, 2015 at 12:21 AM, Ajaya Agrawal <ajku.agr at gmail.com> wrote:\n>>\n>>> https://review.openstack.org/#/c/113586/\n>>>\n>>> Two of my patches depend on this patch.\n>>> https://review.openstack.org/#/c/113277/\n>>> https://review.openstack.org/#/c/110575/\n>>>\n>>>\n>>> Cheers,\n>>> Ajaya\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150107/f042031b/attachment.html>\n\n','<CAC=h7gUmOhbZ-5_RApFxi6LcKNBqOJjHfhTNUEe5C1cSPKEjNA@mail.gmail.com>',NULL),('<1420694751.86801066.1387397503476.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-18 15:11:43',-18000,'2013-12-18 20:11:43',NULL,'[openstack-dev] Adding DB migration items to the common\n	review	checklist','\n\n----- Original Message -----\n> From: \"Matt Riedemann\" <mriedem at linux.vnet.ibm.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, December 18, 2013 12:27:49 PM\n> Subject: [openstack-dev] Adding DB migration items to the common review	checklist\n> \n> I\'ve seen this come up a few times in reviews and was thinking we should\n> put something in the general review checklist wiki for it [1].\n> \n> Basically I have three things I\'d like to have in the list for DB\n> migrations:\n> \n> 1. Unique constraints should be named. Different DB engines and\n> SQLAlchemy dialects automatically name the constraint their own way,\n> which can be troublesome for universal migrations. We should avoid this\n> by enforcing that UCs are named when they are created. This means not\n> using the unique=True arg in UniqueConstraint if the name arg isn\'t\n> provided.\n> \n> 2. Foreign keys should be named for the same reasons in #1.\n> \n> 3. Foreign keys shouldn\'t be created against nullable columns. Some DB\n> engines don\'t allow unique constraints over nullable columns and if you\n> can\'t create the unique constraint you can\'t create the foreign key, so\n> we should avoid this. If you need the FK, then the pre-req is to make\n> the target column non-nullable. Think of the instances.uuid column in\n> nova for example.\n> \n> Unless anyone has a strong objection to this, I\'ll update the review\n> checklist wiki with these items.\n\nNo objection to these.\n\nOne possible addition would be to make sure that migrations stand on their own as much as possible. Code sharing, while good in many cases, can bite you in DB migrations because fixing a bug in the shared code may change the behavior of an old (released) migration. So by sharing migration code it then can  become easier to break upgrades paths down the road. If we make some exceptions to this rule with nova.db.sqlalchemy we need to be very careful that we don\'t change the behavior in those functions. Automated tests help here too.\n\nDan\n\n> \n> [1] https://wiki.openstack.org/wiki/ReviewChecklist\n> \n> --\n> \n> Thanks,\n> \n> Matt Riedemann\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52B1DB15.8030700@linux.vnet.ibm.com>',NULL),('<1420739367-sup-7386@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 09:58:40',-28800,'2015-01-08 17:58:40',NULL,'[openstack-dev] [heat][tripleo] Making diskimage-builder\n	install from forked repo?','Excerpts from Steven Hardy\'s message of 2015-01-08 09:37:55 -0800:\n> Hi all,\n> \n> I\'m trying to test a fedora-software-config image with some updated\n> components.  I need:\n> \n> - Install latest master os-apply-config (the commit I want isn\'t released)\n> - Install os-refresh-config fork from https://review.openstack.org/#/c/145764\n> \n> I can\'t even get the o-a-c from master part working:\n> \n> export PATH=\"${PWD}/dib-utils/bin:$PATH\"\n> export\n> ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements\n> export DIB_INSTALLTYPE_os_apply_config=source\n> \n> diskimage-builder/bin/disk-image-create vm fedora selinux-permissive \\\n>   os-collect-config os-refresh-config os-apply-config \\\n>   heat-config-ansible \\\n>   heat-config-cfn-init \\\n>   heat-config-docker \\\n>   heat-config-puppet \\\n>   heat-config-salt \\\n>   heat-config-script \\\n>   ntp \\\n>   -o fedora-software-config.qcow2\n> \n> This is what I\'m doing, both tools end up as pip installed versions AFAICS,\n> so I\'ve had to resort to manually hacking the image post-DiB using\n> virt-copy-in.\n> \n> Pretty sure there\'s a way to make DiB do this, but don\'t know what, anyone\n> able to share some clues?  Do I have to hack the elements, or is there a\n> better way?\n> \n> The docs are pretty sparse, so any help would be much appreciated! :)\n> \n\nHi Steve. The os-*-config tools represent a bit of a quandry for us,\nas we want to test and run with released versions, not latest git, so\nthe elements just install from pypi. I believe we use devpi in testing\nto test new commits to the tools themselves.\n\nSo you can probably setup a devpi instance locally, and upload the\ncommits you want to it, and then build the image with the \'pypi\' element\nadded and this:\n\nPYPI_MIRROR_URL=http://localhost:3141/\n\nSee diskimage-builder/elements/pypi/README.md for more info on how to\nset this up.\n\n\n','<20150108173755.GB10687@t430slt.redhat.com>',NULL),('<1420739721-sup-981@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 18:06:16',0,'2015-01-08 18:06:16',NULL,'[openstack-dev] [heat][tripleo] Making diskimage-builder\n	install from forked repo?','Excerpts from Steven Hardy\'s message of 2015-01-08 17:37:55 +0000:\n> Hi all,\n> \n> I\'m trying to test a fedora-software-config image with some updated\n> components.  I need:\n> \n> - Install latest master os-apply-config (the commit I want isn\'t released)\n> - Install os-refresh-config fork from https://review.openstack.org/#/c/145764\n> \n> I can\'t even get the o-a-c from master part working:\n> \n> export PATH=\"${PWD}/dib-utils/bin:$PATH\"\n> export\n> ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements\n> export DIB_INSTALLTYPE_os_apply_config=source\n> \n> diskimage-builder/bin/disk-image-create vm fedora selinux-permissive \\\n>   os-collect-config os-refresh-config os-apply-config \\\n>   heat-config-ansible \\\n>   heat-config-cfn-init \\\n>   heat-config-docker \\\n>   heat-config-puppet \\\n>   heat-config-salt \\\n>   heat-config-script \\\n>   ntp \\\n>   -o fedora-software-config.qcow2\n> \n> This is what I\'m doing, both tools end up as pip installed versions AFAICS,\n> so I\'ve had to resort to manually hacking the image post-DiB using\n> virt-copy-in.\n> \n> Pretty sure there\'s a way to make DiB do this, but don\'t know what, anyone\n> able to share some clues?  Do I have to hack the elements, or is there a\n> better way?\n> \n> The docs are pretty sparse, so any help would be much appreciated! :)\n> \n> Thanks,\n> \n> Steve\n> \n\nHey Steve,\n\nsource-repositories is your friend here :) (check out\ndib/elements/source-repositires/README). One potential gotcha is that\nbecause source-repositires is an element it really only applies to tools\nused within images (and os-apply-config is used outside the image). To\nfix this we have a shim in tripleo-incubator/scripts/pull-tools which\nemulates the functionality of source-repositories.\n\nExample usage:\n\n* checkout os-apply-config to the ref you wish to use\n* export DIB_REPOLOCATION_os_apply_config=\"/path/to/oac\"\n* export DIB_REPOREF_os_refresh_config=\"refs/changes/64/145764/1\"\n* start your devtesting\n\nHTH,\nGreg\n\n\n','<20150108173755.GB10687@t430slt.redhat.com>',NULL),('<1420740493-sup-906@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 18:13:18',0,'2015-01-08 18:13:18',NULL,'[openstack-dev] [heat][tripleo] Making diskimage-builder\n	install from forked repo?','Excerpts from Gregory Haynes\'s message of 2015-01-08 18:06:16 +0000:\n> Excerpts from Steven Hardy\'s message of 2015-01-08 17:37:55 +0000:\n> > Hi all,\n> > \n> > I\'m trying to test a fedora-software-config image with some updated\n> > components.  I need:\n> > \n> > - Install latest master os-apply-config (the commit I want isn\'t released)\n> > - Install os-refresh-config fork from https://review.openstack.org/#/c/145764\n> > \n> > I can\'t even get the o-a-c from master part working:\n> > \n> > export PATH=\"${PWD}/dib-utils/bin:$PATH\"\n> > export\n> > ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/software-config/elements\n> > export DIB_INSTALLTYPE_os_apply_config=source\n> > \n> > diskimage-builder/bin/disk-image-create vm fedora selinux-permissive \\\n> >   os-collect-config os-refresh-config os-apply-config \\\n> >   heat-config-ansible \\\n> >   heat-config-cfn-init \\\n> >   heat-config-docker \\\n> >   heat-config-puppet \\\n> >   heat-config-salt \\\n> >   heat-config-script \\\n> >   ntp \\\n> >   -o fedora-software-config.qcow2\n> > \n> > This is what I\'m doing, both tools end up as pip installed versions AFAICS,\n> > so I\'ve had to resort to manually hacking the image post-DiB using\n> > virt-copy-in.\n> > \n> > Pretty sure there\'s a way to make DiB do this, but don\'t know what, anyone\n> > able to share some clues?  Do I have to hack the elements, or is there a\n> > better way?\n> > \n> > The docs are pretty sparse, so any help would be much appreciated! :)\n> > \n> > Thanks,\n> > \n> > Steve\n> > \n> \n> Hey Steve,\n> \n> source-repositories is your friend here :) (check out\n> dib/elements/source-repositires/README). One potential gotcha is that\n> because source-repositires is an element it really only applies to tools\n> used within images (and os-apply-config is used outside the image). To\n> fix this we have a shim in tripleo-incubator/scripts/pull-tools which\n> emulates the functionality of source-repositories.\n> \n> Example usage:\n> \n> * checkout os-apply-config to the ref you wish to use\n> * export DIB_REPOLOCATION_os_apply_config=\"/path/to/oac\"\n> * export DIB_REPOREF_os_refresh_config=\"refs/changes/64/145764/1\"\n> * start your devtesting\n\nActually, Chris\'s response is 100% correct. Even in the source\ninstalltype we appear to be pip installing these tools so this will not\nwork.\n\nIn our CI we work around this by creating a local pypi mirror and\nconfiguring pip to fall back to an upstream mirror. We then build\nsdist\'s for anything we want to install via git and add them to our\n\'overlay mirror\':\n\nCode:\nhttp://git.openstack.org/cgit/openstack-infra/tripleo-ci/tree/toci_devtest.sh#n139\n\nObviously, this isnt the most user friendly approach, but its an option.\n\nGood luck,\nGreg\n\n\n','<1420739721-sup-981@greghaynes0.opus.gah>',NULL),('<1420741577-sup-5543@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 10:38:09',-28800,'2015-01-08 18:38:09',NULL,'[openstack-dev] [heat][tripleo] Making diskimage-builder\n	install from forked repo?','Excerpts from Chris Jones\'s message of 2015-01-08 10:16:14 -0800:\n> Hi\n> \n> > On 8 Jan 2015, at 17:58, Clint Byrum <clint at fewbar.com> wrote:\n> > \n> > Excerpts from Steven Hardy\'s message of 2015-01-08 09:37:55 -0800:\n> > So you can probably setup a devpi instance locally, and upload the\n> > commits you want to it, and then build the image with the \'pypi\' element\n> \n> Given that we have a pretty good release frequency of all our tools, is this burden on devs/testers actually justified at this point, versus the potential consistency we could have with source repo flexibility in other openstack components?\n> \n\nWe\'ve been discussing in #tripleo and I think you\'re right. I think we\ncan solve this by just switching to source-repositories and providing\na relatively simple tool to set release tags when people want released\nversions only.\n\n\n','<F5D911F4-EF35-4CB3-AAA1-3C9B4490B178@tenshu.net>',NULL),('<1420741884.5026.27.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 10:31:24',-28800,'2015-01-08 18:31:24',NULL,'[openstack-dev] The scope of OpenStack wiki [all]','hello folks,\n\nTL;DR Many wiki pages and categories are maintained elsewhere and to\navoid confusion to newcomers we need to agree on a new scope for the\nwiki. A suggestion below is to limit its scope to content that doesn\'t\nneed/want peer-review and is not hosted elsewhere (no duplication).\n\nThe wiki served for many years the purpose of \'poor man CMS\' when we\ndidn\'t have an easy way to collaboratively create content. So the wiki\nended up hosting pages like \'Getting started with OpenStack\', demo\nvideos, How to contribute, mission, to document our culture / shared\nunderstandings (4 opens, release cycle, use of blueprints, stable branch\npolicy...), to maintain the list of Programs, meetings/teams, blueprints\nand specs, lots of random documentation and more.\n\nLots of the content originally placed on the wiki was there because\nthere was no better place. Now that we have more mature content and\nprocesses, these are finding their way out of the wiki like: \n\n      * http://governance.openstack.org\n      * http://specs.openstack.org\n      * http://docs.openstack.org/infra/manual/\n\nAlso, the Introduction to OpenStack is maintained on\nwww.openstack.org/software/ together with introductory videos and other\nbasic material. A redesign of openstack.org/community and the new portal\ngroups.openstack.org are making even more wiki pages obsolete.\n\nThis makes the wiki very confusing to newcomers and more likely to host\nconflicting information.\n\nI would propose to restrict the scope of the wiki to things that\nanything that don\'t need or want to be peer-reviewed. Things like:\n\n  * agendas for meetings, sprints, etc\n  * list of etherpads for summits\n  * quick prototypes of new programs (mentors, upstream training) before\nthey find a stable home (which can still be the wiki)\n\nAlso, documentation for contributors and users should not be on the\nwiki, but on docs.openstack.org (where it can be found more easily).\n\nIf nobody objects, I\'ll start by proposing a new home page design and\nstart tagging content that may be moved elsewhere. \n\n/stef\n\n\n\n',NULL,NULL),('<1420747786.79674181@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-08 14:09:46',-21600,'2015-01-08 20:09:46',NULL,'[openstack-community] More Pods Available in OpenStack\'s Open Cloud\n	Park section - confirm by Jan. 31','\nUPDATE!  The OpenStack corner has expanded to half of the Open Cloud Park!  We have 2 members confirmed and 3 more very close, so there is only 1 guaranteed spot left. There are 11,000+ enterprise attendees historically and this year it\'s being heavily marketed to service providers and developers as well.  Here are the details.  You can also refer to the [ blog post ]( http://www.openstack.org/blog/2014/12/2015-openstack-foundation-events-plan-and-calls-for-papers-available/ ) for information on this, other conferences, and Call For Papers deadlines and links.  Thank you.\n \n[ Cloud Expo Europe ]( http://www.cloudexpoeurope.com/ ) is March 11-12, 2015 in London.  OpenStack is working with the producer CloserStill Media on an Open Cloud Park.  It is a 14m x 14m area decorated with grass and trees, with a theater in the center.  OpenStack and just 3 - NOW 6 - of our members will have one corner - NOW HALF-  of the park. Other open cloud providers will have other corners.\n \nThis is an excellent way to be there without incurring a lot of cost and booth overhead. Here is what the package includes.  \n \nMember Package:\nPod in Park includes:\nTable\nPlasma screen\nBack wall panel carrying partner logo and messaging\nElectricity and lighting\nSlot in Open Cloud & Developer Park Presentation Circle\n20 minute presentation session, self-led\nYou can scan your leads to your session\nMarketing campaign:\nLogo to appear on:\n  Promotional e-mails\n  Website homepage\n  Company name and profile in the show guide\nOpportunity to co-market the event to your prospects with personalised promotions designed by the Cloud Expo Europe Marketing Team\nOpportunity to nominate 20 prospects for us to contact  (on your behalf and subject to approval) as part of our VIP telemarketing campaign\n TOTAL COST: ?4,500 per OpenStack Partner\n--\n\nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150108/1990766d/attachment.html>\n\n',NULL,NULL),('<1420761206.5423.12.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-08 15:53:26',-28800,'2015-01-08 23:53:26',NULL,'[openstack-dev] The scope of OpenStack wiki [all]','On Thu, 2015-01-08 at 12:52 -0800, Sean Roberts wrote:\n> Thanks for bringing this up Stef. I have found while introducing\n> OpenStack fundamentals in the user groups, what seems logical to us,\n> the fully OpenStack immersed, is confusing to newcomers. \n\nYeah, I\'m diving more in the wiki in preparation for a redesign for\ndocs.openstack.org/developer (which I think should be called\ncontributor/ in order to avoid collision with developer.openstack.org).\nThe How_to_contribute page on the wiki is way past its time and needs to\nbe gutted, too.\n\n> A specific example comes from the How To Contribute wikipage.\n> Explaining the corporate CLA and CCLA link was moved to the infra\n> manual. It is cleaner presentation of the information for sure. It\n> also left the google searchable wiki links hanging. This is the\n> primary way most newcomers will look for information.  It wasn\'t easy\n> to find the information once it was brought to my attention it was\n> missing. I fixed it up pretty easily after that. \n> \nIndeed, this is something I\'ve experienced myself. Moving content\naround, changing processes, etc are things we should all be doing with\ncare allowing time and constant communication across multiple channels\n(and taking care of proper http redirects, when possible, to instruct\nweb spiders, too).\n\nIn order to better map the anchors we had on the wiki, I\'ve suggested to\nadd a subsection to the developer guide in infra-manual:\nhttps://review.openstack.org/145971\n\nso that we can have something more precise for CLA then the general link\nto \nhttp://docs.openstack.org/infra/manual/developers.html#account-setup\n\nI\'ve also moved most of the content from CLA-FAQ into a set of FAQ on\nAsk OpenStack, since that site gets lots more hits from search engines:\n\nhttps://ask.openstack.org/en/questions/scope:all/sort:activity-desc/tags:cla,faq/page:1/\n\n/stef\n\n\n\n','<2929D15C-EE1D-4616-86BA-46A552C3CAA1@gmail.com>',NULL),('<1420824197.5423.35.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-09 09:23:17',-28800,'2015-01-09 17:23:17',NULL,'[openstack-dev] The scope of OpenStack wiki [all]','On Fri, 2015-01-09 at 10:35 +0100, Thierry Carrez wrote:\n> One of the issues here is that the wiki also serves as a default\n> starting page for \"all things not on www.openstack.org\" (its main page\n> is a list of relevant links). So at the same time we are moving\n> authoritative content out of the wiki to more appropriate,\n> version-controlled and peer-reviewed sites, we are still relying on the\n> wiki as a reference catalog or starting point to find those more\n> appropriate sites. That is IMHO what creates the confusion on where the\n> authoritative content actually lives.\n\nThere is an intention to redesign the Community page\nhttp://www.openstack.org/community/: maybe this can be used as a\nstarting point for discovery of governance, specs, infra manual,\ncontributor docs, etc? \n\nThe wiki may need a new category for \'stackforge\' projects but probably\nit makes sense to wait until the new programs.yaml and some tags are\nset. Eventually we may match those tags in wiki [[Category:]]...\nsomething for the future. \n\nBetween redesigning www/Community and docs/developers(contributors) I\'m\nquite confident that most personas currently served by the wiki will\nhave their interests served better elsewhere.\n\nTo answer Carol\'s comment: no content will be pushed out of the wiki\nwithout a proper migration and redirection. We\'re discussing the \"scope\"\nof the wiki so that we can communicate more clearly what content should\nbe expected to be in the wiki and what we should plan on putting\nelsewhere (since so much redesigning is going on).\n\n> So we also need to revisit how to make navigation between the various\n> web properties of OpenStack more seamless and discoverable, so that we\n> don\'t rely on the wiki starting page for that important role.\n\nIndeed. The new www.openstack.org has a better navigation bar, IMHO and\nthe wiki pages (and mailing list archives and other sites) have been\nleft behind. It shouldn\'t be too hard to sync the navigations for the\nsites and offer a common to-level path at least.\n\n/stef\n\n\n\n','<54AFA0E7.4080307@openstack.org>',NULL),('<1420830777.5423.47.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-09 11:12:57',-28800,'2015-01-09 19:12:57',NULL,'[openstack-dev] openstack-dev topics now work correctly','Dear all,\n\nif you\'ve tried the topics on this mailing list and haven\'t received\nemails, well... we had a problem on our side: the topics were not setup\ncorrectly.\n\nLuigi Toscano helped isolate the problem and point at the solution[1].\nHe noticed that only the \"QA topic\" was working and that\'s the only one\ndefined with a single regular expression, while all the others use\nmultiple line regexp.\n\nI corrected the regexp as described in the mailman FAQ and tested that\nthe delivery works correctly. If you want to subscribe only to some\ntopics now you can. Thanks again to Luigi for the help. \n\nCheers,\nstef\n\n[1] http://wiki.list.org/pages/viewpage.action?pageId=8683547\n\n\n\n\n',NULL,NULL),('<1420849554-sup-8301@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-09 16:28:48',-28800,'2015-01-10 00:28:48',NULL,'[openstack-dev] [Heat] Convergence proof-of-concept showdown','Excerpts from Zane Bitter\'s message of 2015-01-09 14:57:21 -0800:\n> On 08/01/15 05:39, Anant Patil wrote:\n> > 1. The stack was failing when there were single disjoint resources or\n> > just one resource in template. The graph did not include this resource\n> > due to a minor bug in dependency_names(). I have added a test case and\n> > fix here:\n> > https://github.com/anantpatil/heat-convergence-prototype/commit/b58abd77cf596475ecf3f19ed38adf8ad3bb6b3b\n> \n> Thanks, sorry about that! I will push a patch to fix it up.\n> \n> > 2. The resource graph is created with keys in both forward order\n> > traversal and reverse order traversal and the update will finish the\n> > forward order and attempt the reverse order. If this is the case, then\n> > the update-replaced resources will be deleted before the update is\n> > complete and if the update fails, the old resource is not available for\n> > roll-back; a new resource has to be created then. I have added a test\n> > case at the above mentioned location.\n> >\n> > In our PoC, the updates (concurrent updates) won\'t remove a\n> > update-replaced resource until all the resources are updated, and\n> > resource clean-up phase is started.\n> \n> Hmmm, this is a really interesting question actually. That\'s certainly \n> not how Heat works at the moment; we\'ve always assumed that rollback is \n> \"best-effort\" at recovering the exact resources you had before. It would \n> be great to have users weigh in on how they expect this to behave. I\'m \n> curious now what CloudFormation does.\n> \n> I\'m reluctant to change it though because I\'m pretty sure this is \n> definitely *not* how you would want e.g. a rolling update of an \n> autoscaling group to happen.\n> \n> > It is unacceptable to remove the old\n> > resource to be rolled-back to since it may have changes which the user\n> > doesn\'t want to loose;\n> \n> If they didn\'t want to lose it they shouldn\'t have tried an update that \n> would replace it. If an update causes a replacement or an interruption \n> to service then I consider the same fair game for the rollback - the \n> user has already given us permission for that kind of change. (Whether \n> the user\'s consent was informed is a separate question, addressed by \n> Ryan\'s update-preview work.)\n> \n\nIn the original vision we had for using scaled groups to manage, say,\nnova-compute nodes, you definitely can\'t \"create\" new servers, so you\ncan\'t just create all the new instances without de-allocating some.\n\nThat said, thats why we are using in-place methods like rebuild.\n\nI think it would be acceptable to have cleanup run asynchronously,\nand to have rollback re-create anything that has already been cleaned up.\n\n\n','<54B05CD1.8060803@redhat.com>',NULL),('<1420849961.5423.62.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-09 16:32:41',-28800,'2015-01-10 00:32:41',NULL,'[openstack-community] OpenStack Community Weekly Newsletter (Week 1,\n	2015)','                              Happy 2015!\n\nOpenStack Gold Director Selector Election Results for 2015\n\n      * Aptira ? Tristan Goode\n      * Cisco ? Lew Tucker\n      * Dreamhost ? Simon Anderson\n      * EMC ? Sean Roberts\n      * Mirantis ? Boris Renski\n      * Nebula ? Chris Kemp\n      * (new) NetApp ? Robert Esker\n      * (new) Symantec ? Steven Hallett\n\n\nWelcome to all and good work!\n\n\nWomen of OpenStack Working Session Update\n\nThe WOS Group has a established a new women-of-openstack mailing list\nand is hosting next week a webinar to help Designing an OpenStack Summit\nSession Submission for Success. Register now, as this webinar comes just\nin time for the\n\n\n\nOpenStack Summit Vancouver Call For Speakers \nSubmissions are open now for Vancouver OpenStack Summit 2015.\n\n\nGate Bug Triage Conclusion\n\nA few months ago Matthew Treinish wrote about debugging a gate failure.\nHe wrote an update about the conclusion to the triage efforts for the\nOut Of Memory failures on Neutron jobs. The cause of the failures was\nrunning out of memory but what was leading to the OOM failures wasn?t\njust limited to neutron. It was just that the neutron jobs ran with more\nservices which used more memory which made failures there more common.\n\n\nSneak Peek into Heat New Features in OpenStack Kilo Release\n\nArthur Berezin gives a sneak peek at the new upcoming features in Kilo\nrelease, just as the first Kilo milestone has been reached.\n\n\nRelevant Conversations\n\n      * Requirements for future ?OpenStack projects? \n      * OpenStack: Evolution\n      * 10 pounds of OpenStack cloud in a 5 pound bag? Do we need a\n        bigger bag? WARNING: explicit images\n      * Vancouver Design Summit format changes \n      * [nova] reckoning time for nova ec2 stack \n      * OpenStack Product Management Kilo Midcycle Meeting\n\nDeadlines and Development Priorities\n\n      * [Nova] Kilo Release Status ? just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * review log guidelines\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-001] L3 agent denial of service with radvd 2.0+\n        (CVE-2014-8153)\n      * [OSSA 2014-041.1] Glance v2 API unrestricted path traversal\n        (CVE-2014-9493) ERRATA 1\n\nTips ?n Tricks\n\n      * By Tim Bell: Using bitnami images with OpenStack\n      * By Rob Hirschfeld: OpenCrowbar v2.1 Video Tour from Metal to\n        OpenStack and beyond\n      * By Jay Pipes: Understanding reservations, concurrency, and\n        locking in Nova\n      * By Giulio Fidente: Ceph for Cinder in TripleO\n      * By benn: Reliability Analysis of OpenStack VMs using Python,\n        fabric and R ? Part 1: Reliability Concepts\n      * By Robert van Leeuwen: The kernel panics from 2014 on our\n        OpenStack Hypervisors\n      * By Assaf Muller: Juno Advanced Routing Compatibility\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 10, 2015 OpenStack Mini Meetup, Chennai Chennai, Tamil Nadu,\n        IN\n      * Jan 11, 2015 OpenStack India Meetup, Bangalore BANGALORE,\n        Karnataka, IN\n      * Jan 14, 2015 BareMetal & OpenNetworking webinar Mountain View,\n        CA, US\n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 ? 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 ? 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 ? 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 ? 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 ? 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 ? 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 ? 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * 6 new things Fedora 21 brings to the open source cloud\n      * OpenStack Gold Director Selector Election Results for 2015\n      * What?s Up Doc? Jan 8 2015 \n      * [stable] release notes for 2014.2.2 \n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Does anyone have Xenserver 6.5 and Openstack playing nicely?\n      * Does Stackalytics have API to report data for a specific period?\n      * Windows 7 VM taking on IP from wrong subnet\n      * how to install vpnaas under juno with dvr ?\n      * Does Swift send updates when objects have been modified in a\n        container?\n      * HEAT grub commands for CentOS 7 Nova Instance\n        \n\nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150109/00cbcda5/attachment.html>\n\n',NULL,NULL),('<1420849961.5423.62.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2015-01-09 16:32:41',-28800,'2015-01-10 00:32:41',NULL,'[openstack-announce] OpenStack Community Weekly Newsletter (Week 1,\n	2015)','                              Happy 2015!\n\nOpenStack Gold Director Selector Election Results for 2015\n\n      * Aptira ? Tristan Goode\n      * Cisco ? Lew Tucker\n      * Dreamhost ? Simon Anderson\n      * EMC ? Sean Roberts\n      * Mirantis ? Boris Renski\n      * Nebula ? Chris Kemp\n      * (new) NetApp ? Robert Esker\n      * (new) Symantec ? Steven Hallett\n\n\nWelcome to all and good work!\n\n\nWomen of OpenStack Working Session Update\n\nThe WOS Group has a established a new women-of-openstack mailing list\nand is hosting next week a webinar to help Designing an OpenStack Summit\nSession Submission for Success. Register now, as this webinar comes just\nin time for the\n\n\n\nOpenStack Summit Vancouver Call For Speakers \nSubmissions are open now for Vancouver OpenStack Summit 2015.\n\n\nGate Bug Triage Conclusion\n\nA few months ago Matthew Treinish wrote about debugging a gate failure.\nHe wrote an update about the conclusion to the triage efforts for the\nOut Of Memory failures on Neutron jobs. The cause of the failures was\nrunning out of memory but what was leading to the OOM failures wasn?t\njust limited to neutron. It was just that the neutron jobs ran with more\nservices which used more memory which made failures there more common.\n\n\nSneak Peek into Heat New Features in OpenStack Kilo Release\n\nArthur Berezin gives a sneak peek at the new upcoming features in Kilo\nrelease, just as the first Kilo milestone has been reached.\n\n\nRelevant Conversations\n\n      * Requirements for future ?OpenStack projects? \n      * OpenStack: Evolution\n      * 10 pounds of OpenStack cloud in a 5 pound bag? Do we need a\n        bigger bag? WARNING: explicit images\n      * Vancouver Design Summit format changes \n      * [nova] reckoning time for nova ec2 stack \n      * OpenStack Product Management Kilo Midcycle Meeting\n\nDeadlines and Development Priorities\n\n      * [Nova] Kilo Release Status ? just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * review log guidelines\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-001] L3 agent denial of service with radvd 2.0+\n        (CVE-2014-8153)\n      * [OSSA 2014-041.1] Glance v2 API unrestricted path traversal\n        (CVE-2014-9493) ERRATA 1\n\nTips ?n Tricks\n\n      * By Tim Bell: Using bitnami images with OpenStack\n      * By Rob Hirschfeld: OpenCrowbar v2.1 Video Tour from Metal to\n        OpenStack and beyond\n      * By Jay Pipes: Understanding reservations, concurrency, and\n        locking in Nova\n      * By Giulio Fidente: Ceph for Cinder in TripleO\n      * By benn: Reliability Analysis of OpenStack VMs using Python,\n        fabric and R ? Part 1: Reliability Concepts\n      * By Robert van Leeuwen: The kernel panics from 2014 on our\n        OpenStack Hypervisors\n      * By Assaf Muller: Juno Advanced Routing Compatibility\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 10, 2015 OpenStack Mini Meetup, Chennai Chennai, Tamil Nadu,\n        IN\n      * Jan 11, 2015 OpenStack India Meetup, Bangalore BANGALORE,\n        Karnataka, IN\n      * Jan 14, 2015 BareMetal & OpenNetworking webinar Mountain View,\n        CA, US\n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 ? 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 ? 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 ? 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 ? 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 ? 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 ? 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 ? 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * 6 new things Fedora 21 brings to the open source cloud\n      * OpenStack Gold Director Selector Election Results for 2015\n      * What?s Up Doc? Jan 8 2015 \n      * [stable] release notes for 2014.2.2 \n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Does anyone have Xenserver 6.5 and Openstack playing nicely?\n      * Does Stackalytics have API to report data for a specific period?\n      * Windows 7 VM taking on IP from wrong subnet\n      * how to install vpnaas under juno with dvr ?\n      * Does Swift send updates when objects have been modified in a\n        container?\n      * HEAT grub commands for CentOS 7 Nova Instance\n        \n\nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20150109/00cbcda5/attachment.html>\n\n',NULL,NULL),('<1420849961.5423.62.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-09 16:32:41',-28800,'2015-01-10 00:32:41',NULL,'[Openstack-operators] OpenStack Community Weekly Newsletter (Week 1,\n	2015)','                              Happy 2015!\n\nOpenStack Gold Director Selector Election Results for 2015\n\n      * Aptira ? Tristan Goode\n      * Cisco ? Lew Tucker\n      * Dreamhost ? Simon Anderson\n      * EMC ? Sean Roberts\n      * Mirantis ? Boris Renski\n      * Nebula ? Chris Kemp\n      * (new) NetApp ? Robert Esker\n      * (new) Symantec ? Steven Hallett\n\n\nWelcome to all and good work!\n\n\nWomen of OpenStack Working Session Update\n\nThe WOS Group has a established a new women-of-openstack mailing list\nand is hosting next week a webinar to help Designing an OpenStack Summit\nSession Submission for Success. Register now, as this webinar comes just\nin time for the\n\n\n\nOpenStack Summit Vancouver Call For Speakers \nSubmissions are open now for Vancouver OpenStack Summit 2015.\n\n\nGate Bug Triage Conclusion\n\nA few months ago Matthew Treinish wrote about debugging a gate failure.\nHe wrote an update about the conclusion to the triage efforts for the\nOut Of Memory failures on Neutron jobs. The cause of the failures was\nrunning out of memory but what was leading to the OOM failures wasn?t\njust limited to neutron. It was just that the neutron jobs ran with more\nservices which used more memory which made failures there more common.\n\n\nSneak Peek into Heat New Features in OpenStack Kilo Release\n\nArthur Berezin gives a sneak peek at the new upcoming features in Kilo\nrelease, just as the first Kilo milestone has been reached.\n\n\nRelevant Conversations\n\n      * Requirements for future ?OpenStack projects? \n      * OpenStack: Evolution\n      * 10 pounds of OpenStack cloud in a 5 pound bag? Do we need a\n        bigger bag? WARNING: explicit images\n      * Vancouver Design Summit format changes \n      * [nova] reckoning time for nova ec2 stack \n      * OpenStack Product Management Kilo Midcycle Meeting\n\nDeadlines and Development Priorities\n\n      * [Nova] Kilo Release Status ? just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * review log guidelines\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-001] L3 agent denial of service with radvd 2.0+\n        (CVE-2014-8153)\n      * [OSSA 2014-041.1] Glance v2 API unrestricted path traversal\n        (CVE-2014-9493) ERRATA 1\n\nTips ?n Tricks\n\n      * By Tim Bell: Using bitnami images with OpenStack\n      * By Rob Hirschfeld: OpenCrowbar v2.1 Video Tour from Metal to\n        OpenStack and beyond\n      * By Jay Pipes: Understanding reservations, concurrency, and\n        locking in Nova\n      * By Giulio Fidente: Ceph for Cinder in TripleO\n      * By benn: Reliability Analysis of OpenStack VMs using Python,\n        fabric and R ? Part 1: Reliability Concepts\n      * By Robert van Leeuwen: The kernel panics from 2014 on our\n        OpenStack Hypervisors\n      * By Assaf Muller: Juno Advanced Routing Compatibility\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 10, 2015 OpenStack Mini Meetup, Chennai Chennai, Tamil Nadu,\n        IN\n      * Jan 11, 2015 OpenStack India Meetup, Bangalore BANGALORE,\n        Karnataka, IN\n      * Jan 14, 2015 BareMetal & OpenNetworking webinar Mountain View,\n        CA, US\n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 ? 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 ? 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 ? 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 ? 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 ? 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 ? 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 ? 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * 6 new things Fedora 21 brings to the open source cloud\n      * OpenStack Gold Director Selector Election Results for 2015\n      * What?s Up Doc? Jan 8 2015 \n      * [stable] release notes for 2014.2.2 \n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Does anyone have Xenserver 6.5 and Openstack playing nicely?\n      * Does Stackalytics have API to report data for a specific period?\n      * Windows 7 VM taking on IP from wrong subnet\n      * how to install vpnaas under juno with dvr ?\n      * Does Swift send updates when objects have been modified in a\n        container?\n      * HEAT grub commands for CentOS 7 Nova Instance\n        \n\nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150109/00cbcda5/attachment-0001.html>\n\n',NULL,NULL),('<1420850843.5423.70.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2015-01-09 16:47:23',-28800,'2015-01-10 00:47:23',NULL,'[openstack-announce] [addendum to] OpenStack Community Weekly\n	Newsletter (Week 1, 2015)','[one important paragraph was left out. I apologize for the double post.]\n\n\"First App\" Tutorial for OpenStack\nOpenStack needs something like the tutorial \"Writing your first Django\napp\". We\'re looking for volunteers to flesh out ideas on what this\ntutorial would look like for OpenStack and how it would work.\nParticularly we need to think about the kinds of example applications we\nshould go with. There\'s an etherpad and your ideas are welcome there or\njoin the conversation.\n\n\nOpenStack Gold Director Selector Election Results for 2015\n\n      * Aptira ? Tristan Goode\n      * Cisco ? Lew Tucker\n      * Dreamhost ? Simon Anderson\n      * EMC ? Sean Roberts\n      * Mirantis ? Boris Renski\n      * Nebula ? Chris Kemp\n      * (new) NetApp ? Robert Esker\n      * (new) Symantec ? Steven Hallett\n\n\nWelcome to all and good work!\n\n\n\nWomen of OpenStack Working Session Update\n\nThe WOS Group has a established a new women-of-openstack mailing list\nand is hosting next week a webinar to help Designing an OpenStack Summit\nSession Submission for Success. Register now, as this webinar comes just\nin time for the\n\n\n\nOpenStack Summit Vancouver Call For Speakers \nSubmissions are open now for Vancouver OpenStack Summit 2015.\n\n\n\nGate Bug Triage Conclusion\n\nA few months ago Matthew Treinish wrote about debugging a gate failure.\nHe wrote an update about the conclusion to the triage efforts for the\nOut Of Memory failures on Neutron jobs. The cause of the failures was\nrunning out of memory but what was leading to the OOM failures wasn?t\njust limited to neutron. It was just that the neutron jobs ran with more\nservices which used more memory which made failures there more common.\n\n\n\nSneak Peek into Heat New Features in OpenStack Kilo Release\n\nArthur Berezin gives a sneak peek at the new upcoming features in Kilo\nrelease, just as the first Kilo milestone has been reached.\n\n\n\nRelevant Conversations\n\n      * Requirements for future ?OpenStack projects?\n      * OpenStack: Evolution\n      * 10 pounds of OpenStack cloud in a 5 pound bag? Do we need a\n        bigger bag? WARNING: explicit images\n      * Vancouver Design Summit format changes\n      * [nova] reckoning time for nova ec2 stack\n      * OpenStack Product Management Kilo Midcycle Meeting\n\nDeadlines and Development Priorities\n\n      * [Nova] Kilo Release Status ? just passed spec freeze\n      * [neutron] BPs in Launchpad for Kilo-2\n      * review log guidelines\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-001] L3 agent denial of service with radvd 2.0+\n        (CVE-2014-8153)\n      * [OSSA 2014-041.1] Glance v2 API unrestricted path traversal\n        (CVE-2014-9493) ERRATA 1\n\nTips ?n Tricks\n\n      * By Tim Bell: Using bitnami images with OpenStack\n      * By Rob Hirschfeld: OpenCrowbar v2.1 Video Tour from Metal to\n        OpenStack and beyond\n      * By Jay Pipes: Understanding reservations, concurrency, and\n        locking in Nova\n      * By Giulio Fidente: Ceph for Cinder in TripleO\n      * By benn: Reliability Analysis of OpenStack VMs using Python,\n        fabric and R ? Part 1: Reliability Concepts\n      * By Robert van Leeuwen: The kernel panics from 2014 on our\n        OpenStack Hypervisors\n      * By Assaf Muller: Juno Advanced Routing Compatibility\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 10, 2015 OpenStack Mini Meetup, Chennai Chennai, Tamil Nadu,\n        IN\n      * Jan 11, 2015 OpenStack India Meetup, Bangalore BANGALORE,\n        Karnataka, IN\n      * Jan 14, 2015 BareMetal & OpenNetworking webinar Mountain View,\n        CA, US\n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 ? 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 ? 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 ? 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 ? 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 ? 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 ? 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 ? 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * 6 new things Fedora 21 brings to the open source cloud\n      * OpenStack Gold Director Selector Election Results for 2015\n      * What?s Up Doc? Jan 8 2015\n      * [stable] release notes for 2014.2.2\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Does anyone have Xenserver 6.5 and Openstack playing nicely?\n      * Does Stackalytics have API to report data for a specific period?\n      * Windows 7 VM taking on IP from wrong subnet\n      * how to install vpnaas under juno with dvr ?\n      * Does Swift send updates when objects have been modified in a\n        container?\n      * HEAT grub commands for CentOS 7 Nova Instance\n\n\nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20150109/092e2ec5/attachment-0001.html>\n\n','<1420849961.5423.62.camel@sputacchio.gateway.2wire.net>',NULL),('<1420850843.5423.70.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-09 16:47:23',-28800,'2015-01-10 00:47:23',NULL,'[Openstack-operators] [addendum to] OpenStack Community Weekly\n	Newsletter (Week 1, 2015)','[one important paragraph was left out. I apologize for the double post.]\n\n\"First App\" Tutorial for OpenStack\nOpenStack needs something like the tutorial \"Writing your first Django\napp\". We\'re looking for volunteers to flesh out ideas on what this\ntutorial would look like for OpenStack and how it would work.\nParticularly we need to think about the kinds of example applications we\nshould go with. There\'s an etherpad and your ideas are welcome there or\njoin the conversation.\n\n\nOpenStack Gold Director Selector Election Results for 2015\n\n      * Aptira ? Tristan Goode\n      * Cisco ? Lew Tucker\n      * Dreamhost ? Simon Anderson\n      * EMC ? Sean Roberts\n      * Mirantis ? Boris Renski\n      * Nebula ? Chris Kemp\n      * (new) NetApp ? Robert Esker\n      * (new) Symantec ? Steven Hallett\n\n\nWelcome to all and good work!\n\n\n\nWomen of OpenStack Working Session Update\n\nThe WOS Group has a established a new women-of-openstack mailing list\nand is hosting next week a webinar to help Designing an OpenStack Summit\nSession Submission for Success. Register now, as this webinar comes just\nin time for the\n\n\n\nOpenStack Summit Vancouver Call For Speakers \nSubmissions are open now for Vancouver OpenStack Summit 2015.\n\n\n\nGate Bug Triage Conclusion\n\nA few months ago Matthew Treinish wrote about debugging a gate failure.\nHe wrote an update about the conclusion to the triage efforts for the\nOut Of Memory failures on Neutron jobs. The cause of the failures was\nrunning out of memory but what was leading to the OOM failures wasn?t\njust limited to neutron. It was just that the neutron jobs ran with more\nservices which used more memory which made failures there more common.\n\n\n\nSneak Peek into Heat New Features in OpenStack Kilo Release\n\nArthur Berezin gives a sneak peek at the new upcoming features in Kilo\nrelease, just as the first Kilo milestone has been reached.\n\n\n\nRelevant Conversations\n\n      * Requirements for future ?OpenStack projects?\n      * OpenStack: Evolution\n      * 10 pounds of OpenStack cloud in a 5 pound bag? Do we need a\n        bigger bag? WARNING: explicit images\n      * Vancouver Design Summit format changes\n      * [nova] reckoning time for nova ec2 stack\n      * OpenStack Product Management Kilo Midcycle Meeting\n\nDeadlines and Development Priorities\n\n      * [Nova] Kilo Release Status ? just passed spec freeze\n      * [neutron] BPs in Launchpad for Kilo-2\n      * review log guidelines\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-001] L3 agent denial of service with radvd 2.0+\n        (CVE-2014-8153)\n      * [OSSA 2014-041.1] Glance v2 API unrestricted path traversal\n        (CVE-2014-9493) ERRATA 1\n\nTips ?n Tricks\n\n      * By Tim Bell: Using bitnami images with OpenStack\n      * By Rob Hirschfeld: OpenCrowbar v2.1 Video Tour from Metal to\n        OpenStack and beyond\n      * By Jay Pipes: Understanding reservations, concurrency, and\n        locking in Nova\n      * By Giulio Fidente: Ceph for Cinder in TripleO\n      * By benn: Reliability Analysis of OpenStack VMs using Python,\n        fabric and R ? Part 1: Reliability Concepts\n      * By Robert van Leeuwen: The kernel panics from 2014 on our\n        OpenStack Hypervisors\n      * By Assaf Muller: Juno Advanced Routing Compatibility\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 10, 2015 OpenStack Mini Meetup, Chennai Chennai, Tamil Nadu,\n        IN\n      * Jan 11, 2015 OpenStack India Meetup, Bangalore BANGALORE,\n        Karnataka, IN\n      * Jan 14, 2015 BareMetal & OpenNetworking webinar Mountain View,\n        CA, US\n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 ? 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 ? 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 ? 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 ? 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Apr 13 ? 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 ? 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 ? 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * 6 new things Fedora 21 brings to the open source cloud\n      * OpenStack Gold Director Selector Election Results for 2015\n      * What?s Up Doc? Jan 8 2015\n      * [stable] release notes for 2014.2.2\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Does anyone have Xenserver 6.5 and Openstack playing nicely?\n      * Does Stackalytics have API to report data for a specific period?\n      * Windows 7 VM taking on IP from wrong subnet\n      * how to install vpnaas under juno with dvr ?\n      * Does Swift send updates when objects have been modified in a\n        container?\n      * HEAT grub commands for CentOS 7 Nova Instance\n\n\nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150109/092e2ec5/attachment.html>\n\n','<1420849961.5423.62.camel@sputacchio.gateway.2wire.net>',NULL),('<14210922.1f758.14955e242b6.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 16:32:11',28800,'2014-10-28 08:32:11',NULL,'[openstack-dev] [neutron] vm can not transport large file under\n neutron ml2 + linux bridge + vxlan','One more question.\nVxlan use udp, how can vxlan promise reliability.\n\n\n? 2014-10-28 15:51:02?\"Ian Wells\" <ijw.ubuntu at cack.org.uk> ???\n\nOn 28 October 2014 00:30, Li Tianqing <jazeltq at 163.com> wrote:\n\nlan, you are right, the receiver only receive packet that small than 1450. Because the sender does not send large packets at the begining, so\ntcpdump can catch some small packets. \n\n\nAnother question about the mtu, what if we clear the  DF in the ip packets?  Then l2 can split packets into smaller mtu size?\n\n\nRouters can split packets.  L2 networks don\'t understand IP headers and therefore can\'t fragment packets.  DF doesn\'t change that.\n\n\n(DF is there to make PMTU discovery work, incidentially; it\'s what prompts routers to return PMTU exceeded messages.)\n--\n\nIan.\n\n\n\nAt 2014-10-28 15:15:51, \"Li Tianqing\" <jazeltq at 163.com> wrote:\n\nThe problem is that it is not at the begining to transmit large file. It is after some packets trasmited, then the connection is choked. \nAfter the connection choked, from the bridge in compute host we can see the sender send packets, and the receiver can not get the packets.\nIf it is the pmtud, then at the very begining, the packet can not transmit from the begining.\n\n\nAt 2014-10-28 14:10:09, \"Ian Wells\" <ijw.ubuntu at cack.org.uk> wrote:\n\nPath MTU discovery works on a path - something with an L3 router in the way - where the outbound interface has a smaller MTU than the inbound one.  You\'re transmitting across an L2 network - no L3 routers present.  You send a 1500 byte packet, the network fabric (which is not L3, has no address, and therefore has no means to answer you) does all that it can do with that packet - it drops it.  The sender retransmits, assuming congestion, but the same thing happens.  Eventually the sender decides there\'s a network problem and times out.\n\nThis is a common problem with Openstack deployments, although various features of the virtual networking let you get away with it, with some configs and not others.  OVS used to fake a PMTU exceeded message from the destination if you tried to pass an overlarge packet - not in spec, but it hid the problem nicely.  I have a suspicion that some implementations will fragment the containing UDP packet, which is also not in spec and also solves the problem (albeit with poor performance).\n\nThe right answer for you is to set the MTU in your machines to the same MTU you\'ve given the network, that is, 1450 bytes.  You can do this by setting a DHCP option for MTU, providing your VMs support that option (search the web for the solution, I don\'t have it offhand) or lower the MTU by hand or by script when you start your VM.\n\n\nThe right answer for everyone is to properly determine and advertise the network MTU to VMs (which, with provider networks, is not even consistent from one network to the next) and that\'s the spec Kyle is referring to.  We\'ll be fixing this in Kilo.\n--\n\nIan.\n\n\n\n\nOn 27 October 2014 20:14, Li Tianqing <jazeltq at 163.com> wrote:\n\n\n\n\n\n\n\n--\n\nBest\n    Li Tianqing\n\n\n\nAt 2014-10-27 17:42:41, \"Ihar Hrachyshka\" <ihrachys at redhat.com> wrote:\n>-----BEGIN PGP SIGNED MESSAGE-----\n>Hash: SHA512\n>\n>On 27/10/14 02:18, Li Tianqing wrote:\n>> Hello, Right now, we test neutron under havana release. We\n>> configured network_device_mtu=1450 in neutron.conf, After create\n>> vm, we found the vm interface\'s mtu is 1500, the ping, ssh, is ok.\n>> But if we scp large file between vms then scp display \'stalled\'.\n>> And iperf is also can not completed. If we configured vm\'s mtu to\n>> 1450, then iperf, scp all is ok. If we iperf with -M 1300, then the\n>> iperf is ok too. The vms path mtu discovery is set by default. I do\n>> not know why the vm whose mtu is 1500 can not send large file.\n>\n>There is a neutron spec currently in discussion for Kilo to finally\n>fix MTU issues due to tunneling, that also tries to propagate MTU\n\n>inside instances: https://review.openstack.org/#/c/105989/\n\n\nThe problem is i do not know why the vm with 1500 mtu can not send large file? \nI found the packet send out all with DF, and is it because the DF set default by linux cause the packet\nbe dropped? And the application do not handle the return back icmp packet with the smaller mtu?\n\n\n>\n>/Ihar\n>-----BEGIN PGP SIGNATURE-----\n>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n>\n>iQEcBAEBCgAGBQJUThORAAoJEC5aWaUY1u571u4H/3EqEVPL1Q9KgymrudLpAdRh\n>fwNarwPWT8Ed+0x7WIXAr7OFXX1P90cKRAZKTlAEEI94vOrdr0s608ZX8awMuLeu\n>+LB6IA7nMpgJammfDb8zNmYLHuTQGGatXblOinvtm3XXIcNbkNu8840MTV3y/Jdq\n>Mndtz69TrjTrjn7r9REJ4bnRIlL4DGo+gufXPD49+yax1y/woefqwZPU13kO6j6R\n>Q0+MAy13ptg2NwX26OI+Sb801W0kpDXby6WZjfekXqxqv62fY1/lPQ3oqqJBd95K\n>EFe5NuogLV7UGH5vydQJa0eO2jw5lh8qLuHSShGcDEp/N6oQWiDzXYYYoEQdUic=\n>=jRQ/\n>-----END PGP SIGNATURE-----\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141028/69c8659d/attachment.html>\n\n','<CAPoubz47o7=sMZ1dyKfa9QJO9urtdSri2_dKX5SMddR4rm+5zg@mail.gmail.com>',NULL),('<1421094709-sup-6289@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-12 20:36:04',0,'2015-01-12 20:36:04',NULL,'[openstack-dev] [all] [api] gabbi: A tool for declarative\n	testing of APIs','Excerpts from Chris Dent\'s message of 2015-01-12 19:20:18 +0000:\n> \n> After some discussion with Sean Dague and a few others it became\n> clear that it would be a good idea to introduce a new tool I\'ve been\n> working on to the list to get a sense of its usefulness generally,\n> work towards getting it into global requirements, and get the\n> documentation fleshed out so that people can actually figure out how\n> to use it well.\n> \n> tl;dr: Help me make this interesting tool useful to you and your\n> HTTP testing by reading this message and following some of the links\n> and asking any questions that come up.\n> \n> The tool is called gabbi\n> \n>      https://github.com/cdent/gabbi\n>      http://gabbi.readthedocs.org/\n>      https://pypi.python.org/pypi/gabbi\n> \n> It describes itself as a tool for running HTTP tests where requests\n> and responses are represented in a declarative form. Its main\n> purpose is to allow testing of APIs where the focus of test writing\n> (and reading!) is on the HTTP requests and responses, not on a bunch of\n> Python (that obscures the HTTP).\n> \n> The tests are written in YAML and the simplest test file has this form:\n> \n> ```\n> tests:\n> - name: a test\n>    url: /\n> ```\n> \n> This test will pass if the response status code is \'200\'.\n> \n> The test file is loaded by a small amount of python code which transforms\n> the file into an ordered sequence of TestCases in a TestSuite[1].\n> \n> ```\n> def load_tests(loader, tests, pattern):\n>      \"\"\"Provide a TestSuite to the discovery process.\"\"\"\n>          test_dir = os.path.join(os.path.dirname(__file__), TESTS_DIR)\n>          return driver.build_tests(test_dir, loader, host=None,\n>                                    intercept=SimpleWsgi,\n>                                    fixture_module=sys.modules[__name__])\n> ```\n> \n> The loader provides either:\n> \n> * a host to which real over-the-network requests are made\n> * a WSGI app which is wsgi-intercept-ed[2]\n> \n> If an individual TestCase is asked to be run by the testrunner, those tests\n> that are prior to it in the same file are run first, as prerequisites.\n> \n> Each test file can declare a sequence of nested fixtures to be loaded\n> from a configured (in the loader) module. Fixtures are context managers\n> (they establish the fixture upon __enter__ and destroy it upon\n> __exit__).\n> \n> With a proper group_regex setting in .testr.conf each YAML file can\n> run in its own process in a concurrent test runner.\n> \n> The docs contain information on the format of the test files:\n> \n>      http://gabbi.readthedocs.org/en/latest/format.html\n> \n> Each test can state request headers and bodies and evaluate both response\n> headers and response bodies. Request bodies can be strings in the\n> YAML, files read from disk, or JSON created from YAML structures.\n> Response verifcation can use JSONPath[3] to inspect the details of\n> response bodies. Response header validation may use regular\n> expressions.\n> \n> There is limited support for refering to the previous request\n> to construct URIs, potentially allowing traversal of a full HATEOAS\n> compliant API.\n> \n> At the moment the most complete examples of how things work are:\n> \n> * Ceilometer\'s pending use of gabbi:\n>    https://review.openstack.org/#/c/146187/\n> * Gabbi\'s testing of gabbi:\n>    https://github.com/cdent/gabbi/tree/master/gabbi/gabbits_intercept\n>    (the loader and faked WSGI app for those yaml files is in:\n>    https://github.com/cdent/gabbi/blob/master/gabbi/test_intercept.py)\n> \n> One obvious thing that will need to happen is a suite of concrete\n> examples on how to use the various features. I\'m hoping that\n> feedback will help drive that.\n> \n> In my own experimentation with gabbi I\'ve found it very useful. It\'s\n> helped me explore and learn the ceilometer API in a way that existing\n> test code has completely failed to do. It\'s also helped reveal\n> several warts that will be very useful to fix. And it is fast. To\n> run and to write. I hope that with some work it can be useful to you\n> too.\n> \n> Thanks.\n> \n> [1] Getting gabbi to play well with PyUnit style tests and\n>      with infrastructure like subunit and testrepository was one of\n>      the most challenging parts of the build, but the result has been\n>      a lot of flexbility.\n> \n> [2] https://pypi.python.org/pypi/wsgi_intercept\n> [3] https://pypi.python.org/pypi/jsonpath-rw\n> \n\nAwesome! I was discussing trying to add extensions to RAML[1] so we\ncould do something like this the other day. Is there any reason you\ndidnt use an existing modeling language like this?\n\nCheers,\nGreg\n\n[1] http://raml.org/\n\n\n','<alpine.OSX.2.11.1501121840510.19059@seed.local>',NULL),('<1421106648.15162754.1398675441044.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-28 04:57:21',-14400,'2014-04-28 08:57:21',NULL,'[openstack-dev] [nova][neutron] VIF event callbacks implementation','Hi, \n\nI came across the implementation of \nhttps://blueprints.launchpad.net/neutron/+spec/nova-event-callback\nand have a question about the way it was implemented.\n\nI notice that now Neutron has a dependency on Nova and needs to be configured\nto have nova details (API endpoint, user, password, tenant, etc).\nAside from creating a sort of cyclic dependency between the two, it is my\nunderstanding that Neutron is meant to be a \"stand alone\" service capable of\nbeing consumed by other compute managers (i.e. oVirt).\nThis breaks that paradigm.\n\nSo my question is: Why use API and not RPC?\n\nI saw that there is already a notification system in Neutron that notifies on\neach port update (among other things) which are currently consumed by Ceilometer.\nWhy not have Nova use those notifications to decide that a VIF got plugged correctly,\nfloating IPs changed, and so on?\n\nI am willing to make the necessary changes to decouple Neutron from Nova, but\nwant to understand the rationale behind the original decision of using API\nand not RPC notifications.\n\nRegards,\nMike\n\n\n','<1736113350.11394071.1398675103249.JavaMail.zimbra@redhat.com>',NULL),('<1421148995.5693.10.camel@jells>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-13 11:36:40',0,'2015-01-13 11:36:40',NULL,'[openstack-dev] [Fuel] Lack of additional setup on 10Gbit\n interfaces.','On mon, 2015-01-12 at 14:31 -0800, Dmitry Borodaenko wrote:\n> Hi Piotr,\n> \n> Thanks for writing up a detailed summary of the problem! At the\n> moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to\n> add this functionality to Fuel Web UI [1]\n> \n> [0] http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configuration-via-cli\n> [1] https://blueprints.launchpad.net/fuel/+spec/set-mtu-for-interfaces\nGood point. I missed this.\nSo from cli I can patch this before initial \"deploy changes\".\nChanging this on deployed environment is, or is not possible?\n\nbtw. is there a way to force from fuel master node puppetsync on\nparticular deployed environment?\n\n> \n> I\'m not sure it\'s safe to assume that if you have a 10G NICs the rest\n> of your network is going to support jumbo frames, do you think simply\n> being able to set MTU explicitly (when you know for a fact that\n> particular MTU value works) would be good enough of a solution?\nYes, I think that setting this should be based on user decision, and\nshould be configurable per interface in some point of webui.\n\n\n-- \n  jell\n\n','<CAM0pNLN=e2orwhbnrw6_E6hOs=MK6BsB4h4rQ9==SAGrqL=HBg@mail.gmail.com>',NULL),('<1421184035.3132.9.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-13 15:20:35',-21600,'2015-01-13 21:20:35',NULL,'[openstack-dev] [oslo] Test failures due to oslo_concurrency?','Noticed that https://review.openstack.org/#/c/145626/ failed tests.\nThat\'s kind of curious, as all it does is alter HACKING.rst.\nInvestigation of the test failures[1] showed some UTF-8 decoding errors\nthat appeared to be coming from oslo_concurrency/processutils.py.  Any\nideas?\n\n[1] http://logs.openstack.org/26/145626/2/check/gate-nova-python27/b350bbc/console.html\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n',NULL,NULL),('<1421205985.3388.72.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-13 19:26:25',-28800,'2015-01-14 03:26:25',NULL,'[OpenStack-Infra] Stackforge projects: \"Manila Image Project\"\n and licensing considerations','On Tue, 2015-01-13 at 18:28 +0000, Csaba Henk wrote:\n> What we are puzzled on is the license. This is something we have to\n> figure out before we think of setting up the project. In general it\'s\n> understood that Apache License (v2) is preferred. Question:\n> is that a strict requirement on Stackforge or just a suggestion?\n\nAs fungi said, there are no strong requirements for Stackforge. \n\nOn Tue, 2015-01-13 at 14:15 -0500, Doug Hellmann wrote:\n> The foundation does have some rules that apply to official projects, \n> though\n\nI believe those rules, in practice, apply only to things (for lack of a\nbetter word) that intend to use an OpenStack trademark. The trademark\nrules are hopefully going to get more clear as DefCore makes more\nprogress.\n\n> - Lot of related previous art are GPL/LGPL licensed in entirety or\n>   partially so we have to know if can use them.\n\nI have the impression there are some OpenStack repositories already\nincorporating LGPL software. IIRC there was a thread on legal-discuss\nabout this. \n\n> - Note that the image project is different from standard Openstack\n>   related projects because it\'s a \"meta-tool\", like a compiler:\n>   you don\'t deploy it on site, what you deploy is it\'s outcome\n>   (a VM image).\n\nThis makes me thing that it\'s not a service with a public API, or is it?\nIn other words, do you think that DefCore will consider this\nproject/meta-tool as a factor to decide if a cloud (distribution) is\ncompatible with another? If the answer is not or unlikely then I\'d not\nworry too much about the \'openstack officiality\' of this project.\n\n> - AFAIU #1: the VM image (the output of the tool) is considered to be\n>   a distribution of all the sofware contained in it, which means that\n>   an image builder has to comply with licensing of these software\n>   individually, and patches that are applied on the sources might be\n>   constrained in terms of licensing (if the source is covered by a\n>   copyleft license). So it\'s not feasible to have a pure \n>   APLv2 image builder anyway. What licensing of the image builder\n>   itself (ie. not the patches) has an impact on is the \"scaffolding\"\n>   bundled with the image (init scripts, etc).\n\nthis is complicated :) If I understood you correctly, you\'re wrong here:\nwhatever license you pick for your meta-tool, the license of its output\n(the distribution) won\'t be affected by it. The image builder can safely\nignore the license of the individual packages put in the distribution\n(especially if those images are not going to be distributed --use vs\ndistribution). I don\'t understand the sentence:\n\n> [the image builder] has to comply with licensing of [...] patches that\n> are applied on the sources\n\nWhich sources? What patches is the image builder going to apply, to\nwhich package? \n\nIt may make sense to review how copyright works with GNU Compiler\nCollection (gcc), if you haven\'t read that recently. GCC is distributed\nwith strong copyleft and yet it\'s used to build very proprietary\nexecutables. So, it\'s not true that if you license the\nmanila-image-builder you can only build \'free as in freedom\'\ndistributions. The license of a compiler doesn\'t \'transfer\' over to its\noutput. \n\nEven if the builder tool puts something of itself into its output (like\nit copies init-scripts from itself into the image), there is an argument\nthat the output can still be *not* a derivative. The FSF has an article\nabout this case, written to explain GNU bison\'s behaviour:\nhttp://www.gnu.org/licenses/gpl-faq.html#CanIUseGPLToolsForNF\n\n> - AFAIU #2: the above concerns the one who would like to use and customize\n>   the image builder; regarding the end user who just receives and deploys \n>   the image, and applies changes/updates to it from the distributor\n>   of the image (if there is such a feature), the distributor is free\n>   to specify the terms of usage, as long as the image is made of open\n>   source software.\n\nI\'m afraid I can\'t understand this part. I guess you\'ll have to provide\nmore details and examples of how the tool is supposed to work, what\npackages it will collect and distribute from whom to whom.\n\nThe key element to understand which license \"transfers\" to other\nsoftware is to find the answer to the question: is this thing a\nderivative of this other thing? and ask the question iteratively going\nupstream, from the final output (the image built) all the way up to its\nindividual pieces. \n\nHTH\nIAmNotALawyerThisIsNotALegalAdvice\n\n/stef\n\n\n\n','<slrnmbaorr.17k.csaba@ibm-x3550-01.lab.eng.brq.redhat.com>',NULL),('<1421259122-sup-354@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 10:14:45',-28800,'2015-01-14 18:14:45',NULL,'[openstack-dev] [TripleO] nominating James Polley for tripleo-core','Hello! It has been a while since we expanded our review team. The\nnumbers aren\'t easy to read with recent dips caused by the summit and\nholidays. However, I believe James has demonstrated superb review skills\nand a commitment to the project that shows broad awareness of the\nproject.\n\nBelow are the results of a meta-review I did, selecting recent reviews\nby James with comments and a final score. I didn\'t find any reviews by\nJames that I objected to.\n\nhttps://review.openstack.org/#/c/133554/ -- Took charge and provided\nvaluable feedback. +2\nhttps://review.openstack.org/#/c/114360/ -- Good -1 asking for better\ncommit message and then timely follow-up +1 with positive comments for\nmore improvement. +2\nhttps://review.openstack.org/#/c/138947/ -- Simpler review, +1\'d on Dec.\n19 and no follow-up since. Allowing 2 weeks for holiday vacation, this\nis only really about 7 - 10 working days and acceptable. +2\nhttps://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of\nrecent change with alternatives to the approach submitted as patches.\nhttps://review.openstack.org/#/c/139876/ -- Simpler review, +1\'d in\nagreement with everyone else. +1\nhttps://review.openstack.org/#/c/142621/ -- Thoughtful +1 with\nconsideration for other reviewers. +2\nhttps://review.openstack.org/#/c/113983/ -- Thorough spec review with\ngrammar pedantry noted as something that would not prevent a positive\nreview score. +2\n\nAll current tripleo-core members are invited to vote at this time. Thank\nyou!\n\n\n',NULL,NULL),('<1421263337-sup-7693@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 19:26:33',0,'2015-01-14 19:26:33',NULL,'[openstack-dev] [TripleO] nominating James Polley for\n	tripleo-core','Excerpts from Clint Byrum\'s message of 2015-01-14 18:14:45 +0000:\n> Hello! It has been a while since we expanded our review team. The\n> numbers aren\'t easy to read with recent dips caused by the summit and\n> holidays. However, I believe James has demonstrated superb review skills\n> and a commitment to the project that shows broad awareness of the\n> project.\n> \n> Below are the results of a meta-review I did, selecting recent reviews\n> by James with comments and a final score. I didn\'t find any reviews by\n> James that I objected to.\n> \n> https://review.openstack.org/#/c/133554/ -- Took charge and provided\n> valuable feedback. +2\n> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better\n> commit message and then timely follow-up +1 with positive comments for\n> more improvement. +2\n> https://review.openstack.org/#/c/138947/ -- Simpler review, +1\'d on Dec.\n> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this\n> is only really about 7 - 10 working days and acceptable. +2\n> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of\n> recent change with alternatives to the approach submitted as patches.\n> https://review.openstack.org/#/c/139876/ -- Simpler review, +1\'d in\n> agreement with everyone else. +1\n> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with\n> consideration for other reviewers. +2\n> https://review.openstack.org/#/c/113983/ -- Thorough spec review with\n> grammar pedantry noted as something that would not prevent a positive\n> review score. +2\n> \n> All current tripleo-core members are invited to vote at this time. Thank\n> you!\n> \n\nDefinite +1.\n\n-Greg\n\n\n','<1421259122-sup-354@fewbar.com>',NULL),('<1421269438-sup-9323@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 13:07:05',-28800,'2015-01-14 21:07:05',NULL,'[openstack-dev] [TripleO] nominating James Polley for\n	tripleo-core','Excerpts from James Polley\'s message of 2015-01-14 12:46:37 -0800:\n> Thanks for the nomination Clint (and +1s from people who have already\n> responded)\n> \n> At this stage, I believe we\'ve traditionally[1] asked[2] the potential new\n> Core Reviewer to commit to 3 reviews per work-day.\n> \n> I don\'t feel that that\'s a commitment I can make at this point. It\'s not\n> something I\'ve been able to achieve in the past - I\'ve come close over the\n> last 30 days, but the 90 day report shows me barely above 2 per day. I\n> think my current throughput is something I can commit to maintaining, and\n> I\'d like to think that it can grow over time; but I don\'t think I can\n> commit to doing anything more than I\'ve already been able to do.\n> \n> If the rest of the core reviewers think I\'m still making a valuable\n> contribution, I\'m more than happy to accept this nomination.\n> \n\nIMO we need to re-evaluate that requirement. None of us has done a great\njob at sustaining it, however as a team we\'ve managed to at least get\nenough reviews done to keep the tubes flowing. I know that at one point\nwe got really backed up, but what solved that was a combination of a few\nless patches getting submitted (probably because of the long wait time)\nand a few more reviewers being added. So having more good reviewers like\nyourself seems more important than having more perfect reviewers.\n\nAlso the main reason for wanting people to do 3 per day is to maintain\nfamiliarity with the code. I think you\'ve been able to remain familiar\nwith your traditional rate just fine.\n\n\n','<CAPtRfUGLweuwsNb9pf5mwKPoR9rnXZxUac0Qx+f-uYoQo0t88A@mail.gmail.com>',NULL),('<1421275675.19633.13.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-14 16:47:55',-21600,'2015-01-14 22:47:55',NULL,'[OpenStack Foundation] [Gold Members] [Foundation Board]\n Election is open','On Thu, 2015-01-15 at 09:14 +1100, Tristan Goode wrote:\n> And this to the Foundation list too.\n\n\nAs a reminder, Alan Clark wrote up a good template if you\'re looking to\nencourage voting inside of your organizations.  Note that the message\ndoes not encourage people how to vote, only that they do cast a vote.\nEvery individual member\'s vote is theirs to cast, regardless of\naffiliation.\n\nDetails:\nhttp://lists.openstack.org/pipermail/defcore-committee/2015-January/000476.html \n\n/stef\n\n\n\n\n','<e477a9b4df0e0db7c2e473613fb1b5b8@mail.gmail.com>',NULL),('<1421296365.19633.22.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-14 22:32:45',-21600,'2015-01-15 04:32:45',NULL,'[Openstack] Why all OpenStack Foundation Individual Members should\n vote now [all]','HOW TO VOTE: If you are an eligible voter[1], you should have received\nan email with the subject ?OpenStack Foundation ? 2015 Individual\nDirector Election? from secretary at openstack.org. This email includes\nyour unique voting link. If you did not receive an email, please contact\nsecretary at openstack.org.\n\nIf you are an active member of the OpenStack Foundation, you should have\nreceived an email in your inbox with a link to vote for renewal of the\nBoard of Directors and to change the Foundation?s bylaws. The changes to\nthe bylaws make this election different from others and require your\nvote.\n\nDuring 2014, the OpenStack community created several revisions of the\nBylaws as part of the process to define what makes up core OpenStack\nfunctionality. The proposed revisions to the Bylaws are meant to provide\nflexibility in determining the software required for use of the\nOpenStack trademarks. The revisions also permit the adoption of the\n?DefCore? procedures and any changes to those procedures in the future.\nThese amendments have already gone through fifteen revisions with\ncomments from the Technical Committee, DefCore Committee, OpenStack\nFoundation management, Legal Affairs Committee and the Board of\nDirectors.\n\nNow it?s your turn: the change to the bylaws require that least 25% of\nthe eligible voters cast a vote. If the quorum is not reached, the\nbylaws won?t change and the work of the Foundation will be more\ncomplicated.\n\nYou have a duty to fulfill and it won?t take much of your time. You can\nlearn more about the amendments\nhttps://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment. We need your click to reach the quorum to improve the Foundation.\n\n[1] Eligible voters are individual members of the OpenStack Foundation\nwho joined the foundation more than 180 days ago.\n\n\n\n',NULL,NULL),('<1421296365.19633.22.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-14 22:32:45',-21600,'2015-01-15 04:32:45',NULL,'[openstack-dev] Why all OpenStack Foundation Individual Members\n should vote now [all]','HOW TO VOTE: If you are an eligible voter[1], you should have received\nan email with the subject ?OpenStack Foundation ? 2015 Individual\nDirector Election? from secretary at openstack.org. This email includes\nyour unique voting link. If you did not receive an email, please contact\nsecretary at openstack.org.\n\nIf you are an active member of the OpenStack Foundation, you should have\nreceived an email in your inbox with a link to vote for renewal of the\nBoard of Directors and to change the Foundation?s bylaws. The changes to\nthe bylaws make this election different from others and require your\nvote.\n\nDuring 2014, the OpenStack community created several revisions of the\nBylaws as part of the process to define what makes up core OpenStack\nfunctionality. The proposed revisions to the Bylaws are meant to provide\nflexibility in determining the software required for use of the\nOpenStack trademarks. The revisions also permit the adoption of the\n?DefCore? procedures and any changes to those procedures in the future.\nThese amendments have already gone through fifteen revisions with\ncomments from the Technical Committee, DefCore Committee, OpenStack\nFoundation management, Legal Affairs Committee and the Board of\nDirectors.\n\nNow it?s your turn: the change to the bylaws require that least 25% of\nthe eligible voters cast a vote. If the quorum is not reached, the\nbylaws won?t change and the work of the Foundation will be more\ncomplicated.\n\nYou have a duty to fulfill and it won?t take much of your time. You can\nlearn more about the amendments\nhttps://wiki.openstack.org/wiki/Governance/Foundation/2014ProposedBylawsAmendment. We need your click to reach the quorum to improve the Foundation.\n\n[1] Eligible voters are individual members of the OpenStack Foundation\nwho joined the foundation more than 180 days ago.\n\n\n\n',NULL,NULL),('<1421296772.114124775@apps.rackspace.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-14 23:39:32',-18000,'2015-01-15 04:39:32',NULL,'[OpenStack Foundation] Elections: Could we set the IRC topic?.','Yes, we can although I don\'t know how to do that. CC-ing the infra team since I believe they have access to that.\n\nMy guess is that the people who pay attention to IRC have already voted because I\'d expect them to be the most involved set of folks anyway. But probably adding there a link to http://www.openstack.org/blog/2015/01/why-all-openstack-foundation-individual-members-should-vote-now/ won\'t hurt for sure.\n\nProbably a message to the General and -dev mailing lists also would help move the needle (sending one now).\n\n/stef\n\n-----Original Message-----\nFrom: \"Alan Clark\" <aclark at suse.com>\nSent: Wednesday, January 14, 2015 7:23pm\nTo: foundation at lists.openstack.org, foundation-board at lists.openstack.org, \"Stefano Maffulli\" <stefano at openstack.org>, \"Thierry Carrez\" <thierry at openstack.org>\nSubject: Re: Elections: Could we set the IRC topic?.\n\nStef, Thierry \n\nA suggestion:  Could we set the IRC topic, at end of mtgs (aka header) on the appropriate channels to \"Get out and vote today!\" \n\nSeems like meeting, meeting-alt, community, dev would be great targets.\n\nI\'ll be happy if people start complaining that we are spamming them about voting :-)\n\nthanks,\nAlanClark\n\n\n\n\n\n','<54B6A629020000CC00014F2A@prv-mh.provo.novell.com>',NULL),('<1421296772.114124775@apps.rackspace.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-14 23:39:32',-18000,'2015-01-15 04:39:32',NULL,'[OpenStack-Infra] Elections: Could we set the IRC topic?.','Yes, we can although I don\'t know how to do that. CC-ing the infra team since I believe they have access to that.\n\nMy guess is that the people who pay attention to IRC have already voted because I\'d expect them to be the most involved set of folks anyway. But probably adding there a link to http://www.openstack.org/blog/2015/01/why-all-openstack-foundation-individual-members-should-vote-now/ won\'t hurt for sure.\n\nProbably a message to the General and -dev mailing lists also would help move the needle (sending one now).\n\n/stef\n\n-----Original Message-----\nFrom: \"Alan Clark\" <aclark at suse.com>\nSent: Wednesday, January 14, 2015 7:23pm\nTo: foundation at lists.openstack.org, foundation-board at lists.openstack.org, \"Stefano Maffulli\" <stefano at openstack.org>, \"Thierry Carrez\" <thierry at openstack.org>\nSubject: Re: Elections: Could we set the IRC topic?.\n\nStef, Thierry \n\nA suggestion:  Could we set the IRC topic, at end of mtgs (aka header) on the appropriate channels to \"Get out and vote today!\" \n\nSeems like meeting, meeting-alt, community, dev would be great targets.\n\nI\'ll be happy if people start complaining that we are spamming them about voting :-)\n\nthanks,\nAlanClark\n\n\n\n\n\n','<54B6A629020000CC00014F2A@prv-mh.provo.novell.com>',NULL),('<1421325554.9679.9.camel@ruuvari.hard.ware.fi>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-15 12:39:14',0,'2015-01-15 12:39:14',NULL,'[openstack-community] OpenStack promotial merhandise for\n	OpenStackFin meetup?','Hi,\n\nwe\'re holding again a community event in Helsinki, Finland, 4th of\nMarch.\n\nhttp://www.meetup.com/OpenStack-Finland-User-Group/events/219849986/\n\nIs there a known way to have some OpenStack t-shirts, bells & whistles?\nIs there a OS-foundation promo shop of any kind? Anyone interested of\nsponsoring such for our local event of around 150 people?\n\nWe as a company sponsor (along other sponsors we find) the event with\nvenue, snacks and drinks. But some company neutral OpenStack t-shirts or\nsmth would be cool to have too.\n\nBR,\n Ilkka\n\n-- \nIlkka Tengvall\nAdvisory Consultant, Cloud Architecture\nemail:  ilkka.tengvall at cybercom.com\nmobile: +358408443462\nweb:    http://cybercom.com - http://cybercom.fi \n\n\n',NULL,NULL),('<1421340714975.7e6668f@Nodemailer>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-15 08:51:55',-28800,'2015-01-15 16:51:55',NULL,'[OpenStack Foundation] Elections: Could we set the IRC topic?.','That\'s actually a great point. Could the order of voting be switched so page one shows the bylaws instead of candidates?\n\n?\nSent from Mailbox\n\nOn Thu, Jan 15, 2015 at 8:46 AM, Tim Bell <Tim.Bell at cern.ch> wrote:\n\n> Some people seem to be unaware that they do not need to vote for the individual directors. This may be worth emphasising as the time left to study the manifestoes may put people off from voting for the bylaws.\n> Tim\n>> -----Original Message-----\n>> From: Jonathan Bryce [mailto:jonathan at openstack.org]\n>> Sent: 15 January 2015 17:41\n>> To: foundation at lists.openstack.org\n>> Subject: Re: [OpenStack Foundation] Elections: Could we set the IRC topic?.\n>> \n>> At this point, I think we have a good shot of getting across the quorum line given\n>> our pace over the last 24 hours. The most effective mechanism has been direct\n>> emails to the remaining eligible voters, and at this point, I don?t think it?s\n>> necessary to spam those channels (like IRC) that have probably had a high voting\n>> ratio already among their audience.\n>> \n>> Another reminder email will be going out shortly and we?ll provide an update\n>> later today on the progress.\n>> \n>> Jonathan\n>> \n>> \n>> > On Jan 15, 2015, at 9:28 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:\n>> >\n>> > On 2015-01-14 17:23:53 -0700 (-0700), Alan Clark wrote:\n>> >> A suggestion: Could we set the IRC topic, at end of mtgs (aka\n>> >> header) on the appropriate channels to \"Get out and vote today!\"\n>> >\n>> > We have an IRC bot we use for temporarily modifying channel topics and\n>> > making in-channel announcements, though it\'s not really intended to be\n>> > used to alter topics for more than a few hours (susceptible to\n>> > connectivity issues and netsplits which can cause a loss of state and\n>> > result in topics getting \"stuck\" with the temporary text). As\n>> > mentioned in other replies, channel topics while persistent are\n>> > actually not that noticeable in most IRC clients--abusing that bot to\n>> > do a few brief election reminder announcements in channels might reach\n>> > more people. I\'m trying to get some consensus from our other\n>> > infrastructure admins on this possibility since people can be a little\n>> > touchy about what they may see as unnecessary spam in IRC.\n>> >\n>> >> Seems like meeting, meeting-alt, community, dev would be great\n>> >> targets.\n>> >\n>> > Our statusbot currently sits in ~60 OpenStack-related channels:\n>> >\n>> > <URL:\n>> > https://git.openstack.org/cgit/openstack-infra/system-config/tree/mani\n>> > fests/site.pp#n266 >\n>> >\n>> >> I\'ll be happy if people start complaining that we are spamming them\n>> >> about voting :-)\n>> >\n>> > It\'s a distinct possibility.\n>> > --\n>> > Jeremy Stanley\n>> > _______________________________________________\n>> > Foundation mailing list\n>> > Foundation at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>> \n>> \n>> _______________________________________________\n>> Foundation mailing list\n>> Foundation at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20150115/1126f6d4/attachment.html>\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E50102684741@CERNXCHG41.cern.ch>',NULL),('<1421344768-sup-1711@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 09:59:52',-28800,'2015-01-15 17:59:52',NULL,'[openstack-dev] [TripleO] nominating James Polley for\n	tripleo-core','Excerpts from Chuck Carlino\'s message of 2015-01-15 09:43:41 -0800:\n> On 01/15/2015 08:49 AM, Alexis Lee wrote:\n> > Clint Byrum said on Wed, Jan 14, 2015 at 10:14:45AM -0800:\n> >> holidays. However, I believe James has demonstrated superb review skills\n> >> and a commitment to the project that shows broad awareness of the\n> >> project.\n> > Big +1. Thanks for taking the time to meta-review, Clint.\n> >\n> >\n> > Alexis\n> \n> I don\'t get a vote, but just wanted to point out James\' excellent \n> contributions in chasing down neutron issues.\n> \n> Hmm, now that I\'ve said it, I\'m not entirely certain he\'d have wanted me \n> to :P\n> \n\nAwesome, so James is our Neutron person now. :)\n\n\n','<54B7FC4D.9050100@gmail.com>',NULL),('<1421345387.11587.0.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 13:09:47',-18000,'2015-01-15 18:09:47',NULL,'[openstack-dev] [TripleO] nominating James Polley for\n tripleo-core','On Wed, 2015-01-14 at 10:14 -0800, Clint Byrum wrote:\n> Hello! It has been a while since we expanded our review team. The\n> numbers aren\'t easy to read with recent dips caused by the summit and\n> holidays. However, I believe James has demonstrated superb review skills\n> and a commitment to the project that shows broad awareness of the\n> project.\n> \n> Below are the results of a meta-review I did, selecting recent reviews\n> by James with comments and a final score. I didn\'t find any reviews by\n> James that I objected to.\n> \n> https://review.openstack.org/#/c/133554/ -- Took charge and provided\n> valuable feedback. +2\n> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better\n> commit message and then timely follow-up +1 with positive comments for\n> more improvement. +2\n> https://review.openstack.org/#/c/138947/ -- Simpler review, +1\'d on Dec.\n> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this\n> is only really about 7 - 10 working days and acceptable. +2\n> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of\n> recent change with alternatives to the approach submitted as patches.\n> https://review.openstack.org/#/c/139876/ -- Simpler review, +1\'d in\n> agreement with everyone else. +1\n> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with\n> consideration for other reviewers. +2\n> https://review.openstack.org/#/c/113983/ -- Thorough spec review with\n> grammar pedantry noted as something that would not prevent a positive\n> review score. +2\n> \n> All current tripleo-core members are invited to vote at this time. Thank\n> you!\n\n+1\n\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1421259122-sup-354@fewbar.com>',NULL),('<1421345697.11587.3.camel@dovetail.localdomain>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 13:14:57',-18000,'2015-01-15 18:14:57',NULL,'[openstack-dev] [TripleO] Switching CI back to amd64','On Wed, 2015-01-07 at 10:51 +0000, Derek Higgins wrote:\n> Hi All,\n>     I intended to bring this up at this mornings meeting but the train I\n> was on had no power sockets (and I had no battery) so sending to the\n> list instead.\n> \n> We currently run our CI with on images built for i386, we took this\n> decision a while back to save memory ( at the time is allowed us to move\n> the amount of memory required in our VMs from 4G to 2G (exactly where in\n> those bands the hard requirements are I don\'t know)\n> \n> Since then we have had to move back to 3G for the i386 VM as 2G was no\n> longer enough so the saving in memory is no longer as dramatic.\n> \n> Now that the difference isn\'t as dramatic, I propose we switch back to\n> amd64 (with 4G vms) in order to CI on what would be closer to a\n> production deployment and before making the switch wanted to throw the\n> idea out there for others to digest.\n> \n> This obviously would impact our capacity as we will have to reduce the\n> number of testenvs per testenv hosts. Our capacity (in RH1 and roughly\n> speaking) allows us to run about 1440 ci jobs per day. I believe we can\n> make the switch and still keep capacity above 1200 with a few other changes\n> 1. Add some more testenv hosts, we have 2 unused hosts at the moment and\n> we can probably take 2 of the compute nodes from the overcloud.\n> 2. Kill VM\'s at the end of each CI test (as opposed to leaving them\n> running until the next CI test kills them), allowing us to more\n> successfully overcommit on RAM\n> 3. maybe look into adding swap on the test env hosts, they don\'t\n> currently have any, so over committing RAM is a problem the the OOM\n> killer is handling from time to time (I only noticed this yesterday).\n> \n> The other benefit to doing this is that is we were to ever want to CI\n> images build with packages (this has come up in previous meetings) we\n> wouldn\'t need to provide i386 packages just for CI, while the rest of\n> the world uses the amd64.\n\n+1. I\'ve been wishing we\'d switch back to x86_64 for a while now. Even\nif it takes a bit more space I think ultimately this makes thing a bit\neasier on us so lets do it.\n\nDan\n\n> \n> Thanks,\n> Derek.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<54AD0FBD.8030502@redhat.com>',NULL),('<1421347025-sup-2482@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 10:39:08',-28800,'2015-01-15 18:39:08',NULL,'[openstack-dev] [TripleO] nominating James Polley for\n	tripleo-core','In about 24 hours we\'ve seen 9 core +1\'s, one non-core +1, and only one\ndissenting opinion from James himself which I think we have properly\ndismissed. With my nomination counting as an additional +1, that is 10,\nwhich is 50% of the 20 cores active the last 90 days.\n\nI believe this vote has carried. Please welcome James Polley to the\nTripleO core reviewer team. :)\n\nExcerpts from Clint Byrum\'s message of 2015-01-14 10:14:45 -0800:\n> Hello! It has been a while since we expanded our review team. The\n> numbers aren\'t easy to read with recent dips caused by the summit and\n> holidays. However, I believe James has demonstrated superb review skills\n> and a commitment to the project that shows broad awareness of the\n> project.\n> \n> Below are the results of a meta-review I did, selecting recent reviews\n> by James with comments and a final score. I didn\'t find any reviews by\n> James that I objected to.\n> \n> https://review.openstack.org/#/c/133554/ -- Took charge and provided\n> valuable feedback. +2\n> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better\n> commit message and then timely follow-up +1 with positive comments for\n> more improvement. +2\n> https://review.openstack.org/#/c/138947/ -- Simpler review, +1\'d on Dec.\n> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this\n> is only really about 7 - 10 working days and acceptable. +2\n> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of\n> recent change with alternatives to the approach submitted as patches.\n> https://review.openstack.org/#/c/139876/ -- Simpler review, +1\'d in\n> agreement with everyone else. +1\n> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with\n> consideration for other reviewers. +2\n> https://review.openstack.org/#/c/113983/ -- Thorough spec review with\n> grammar pedantry noted as something that would not prevent a positive\n> review score. +2\n> \n> All current tripleo-core members are invited to vote at this time. Thank\n> you!\n\n\n','<1421259122-sup-354@fewbar.com>',NULL),('<1421347310-sup-745@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-15 10:55:04',-28800,'2015-01-15 18:55:04',NULL,'[openstack-dev] [TripleO] Part two of core reviewer team -- pruning','Hello! Now that we\'ve added James, I have some suggestions for members\nthat should be dropped.\n\nI have communicated with some of these individuals and confirmed they\nare not interested in continuing. So for posterity sake I\'m noting\nthese two removals, effective immediately:\n\nTzu-mainn Chen\nImre Farkas\n\nThe following members have not submitted any reviews in 90 days, but I\nwasn\'t able to contact them immediately. If you are on this list and\nwould like to stay or step down, please reply directly to me or on the\nlist. Since we still have data blips from the traditional December\nbreak, I don\'t think we should think too much about the numbers beyond\nthis until next month.\n\n\nMembers with no reviews in 90 days:\n\nMartyn Taylor\nRadomir Dopieralski\n\n\n',NULL,NULL),('<1421433234-sup-9670@fewbar.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-16 10:37:54',-28800,'2015-01-16 18:37:54',NULL,'[OpenStack-Infra] Stackforge projects: \"Manila Image Project\"\n	and licensing considerations','Excerpts from Dave Walker\'s message of 2015-01-16 05:13:14 -0800:\n> On 13 January 2015 at 18:28, Csaba Henk <csaba at redhat.com> wrote:\n> <SNIP>\n> > We (Manila developers) plan to start a new side-project that would\n> > be hosted on Stackforge. It\'s tentatively named \"Manila Image Project\",\n> > although it would not necessarily be Manila specific.\n> >\n> > It\'s aim is to provide infrastructure for building custom VM images.\n> <SNIP>\n> \n> At risk of going off topic, I am curious how this fits under the\n> Manila project scope.  My understanding of Manila is that it is a File\n> Shares service.  This seems to have an odd overlap with creating VM\n> images.\n> \n> Can you point me to the design or blueprint for this need, so I can\n> better understand?\n\nI think it\'s quite a bit on-topic. Manila is just another agent that\nneeds to be deployed somewhere, and you can avoid any licensing concerns\nby providing the same level of install instructions as all of the other\nagents that OpenStack projects provide.\n\nIf you do want it to be more turn-key, I\'d recommend producing\ndiskimage-builder elements to build on one of the minimal distros that\nexist, and distribute those elements. That\'s basically how Heat has\noperated, and you can probably look at how Trove and Sahara handle their\nagents as well for more insight into this.\n\nLeave image distribution to the Linux distros -- just help users\ncustomize the images as needed.\n\n\n','<CACyjiAgPYBaBvWtZYPhOqCehozqFFuWWH=jdNuT3oxAm6SYJKA@mail.gmail.com>',NULL),('<1421438805-sup-1759@fewbar.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-16 12:10:43',-28800,'2015-01-16 20:10:43',NULL,'[Openstack] [Heat] Heat supports OpenStack operation','Excerpts from Steven Hardy\'s message of 2015-01-16 01:11:44 -0800:\n> On Fri, Jan 16, 2015 at 08:34:47AM +0000, Duan, Li-Gong (Gary at HPServers-Core-OE-PSC) wrote:\n> >    Does Heat support executing an OpenStack operation, such as migrating an\n> >    Nova instance, powering off a Nova instance?\n> \n> We call state changes which don\'t affect the definition of the stack an\n> \"action\", and we only support suspend and resume at present (e.g heat\n> action-suspend <stack name>)\n> \n> It may be possible to add support for more actions (until now nobody has\n> asked for them), but note it only really makes sense to drive such actions\n> via heat when dependencies/ordering are important.\n> \n> For example, when suspending then resuming a stack containing a WebServer\n> instance and a DatabaseServer instance, you want DatabaseServer to be\n> resumed before WebServer (same order as on stack create)\n> \n> So, it might make sense to have an action which can power-off a whole\n> stack, turning off each nova node in the right order (you could write a\n> little script which does the same thing quite easily though..).\n> \n> It probably doesn\'t make much sense for heat to support things like\n> migrating an instance, since it\'s an operation which isn\'t scoped to the\n> stack and it\'s dependencies, it\'s likely an operator wants to migrate a\n> workload off a specific compute node, which is something Heat has no\n> visibility of at all.\n> \n> >    I know currently Heat does a good job on launching cloud cluster or\n> >    application, such as deploying a Nova instance with specified network\n> >    configuration, but not sure how to control(not launch or delete) a Nova\n> >    instance or cinder volume.\n> \n> Right now, the easiest answer is write a little script which uses\n> information from heat (e.g to get the UUID\'s for the resources you want to\n> control) then e.g calls nova.\n> \n> >    If Heat does not support these OpenStack operation, what is the best Heat\n> >    way if we want to execute some operations, such as powering off a Nova\n> >    instance, in Heat template?\n> \n> As mentioned above, these lifecycle operations affect the stack state, but\n> not it\'s definition, so it probably doesn\'t make sense to expose actions\n> like powering off an instance in the heat template.\n\nWe have discussed in the past adding a target state as a property for\nservers. Right now we only target ACTIVE, but we could certainly target\nSTOPPED and issue stops. It makes sense in certain instances.\n\nThat said, I think most of the time you want to use a workflow tool\n(like Ansible or Mistral) to orchestrate actions. Heat can\'t possibly\nknow all the sequencing all services may require before and after a\nserver is stopped. So in these instances you either want the workflow\ntool to drive Heat, or to have Heat defer to the workflow tool using\nsoftware-config/software-deployment.\n\n\n','<20150116091143.GA16053@t430slt.redhat.com>',NULL),('<1421443922.4235.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-16 21:29:48',0,'2015-01-16 21:29:48',NULL,'[openstack-dev] [neutron] Next week\'s meeting is cancelled (and\n some other notes)','I\'m pretty sure you just destroyed everyone\'s vision with that.\n\nOn Fri, 2015-01-16 at 21:23 +0000, Doug Wiegley wrote:\n> It?s not pretty, but if the topic has been set correctly, this finds\n> everything open with a Kilo-2 blueprint:\n> \n> \n> https://review.openstack.org/#/q/project:openstack/neutron+status:open\n> +(topic:bp/wsgi-pecan-switch+OR+topic:bp/plugin-interface-perestroika\n> +OR+topic:bp/reorganize-unit-test-tree+OR\n> +topic:bp/restructure-l2-agent+OR+topic:bp/rootwrap-daemon-mode+OR\n> +topic:bp/retargetable-functional-testing+OR\n> +topic:bp/refactor-iptables-firewall-driver+OR+topic:bp/vsctl-to-ovsdb\n> +OR+topic:bp/lbaas-api-and-objmodel-improvement+OR\n> +topic:bp/restructure-l3-agent+OR+topic:bp/neutron-ovs-dvr-vlan+OR\n> +topic:bp/allow-specific-floating-ip-address+OR\n> +topic:bp/ipset-manager-refactor+OR\n> +topic:bp/agent-child-processes-status+OR\n> +topic:bp/extra-dhcp-opts-ipv4-ipv6+OR\n> +topic:bp/ipsec-strongswan-driver+OR+topic:bp/ofagent-bridge-setup+OR\n> +topic:bp/arp-spoof-patch-ebtables+OR+topic:bp/report-ha-router-master\n> +OR+topic:bp/conntrack-in-security-group+OR\n> +topic:bp/allow-mac-to-be-updated+OR+topic:bp/specify-router-ext-ip+OR\n> +topic:bp/a10-lbaas-v2-driver+OR+topic:bp/brocade-vyatta-fwaas-plugin\n> +OR+topic:bp/netscaler-lbaas-v2-driver+OR+topic:bp/ofagent-sub-driver\n> +OR+topic:bp/ml2-cisco-nexus-mechdriver-providernet+OR\n> +topic:bp/ofagent-flow-based-tunneling+OR\n> +topic:bp/ml2-ovs-portsecurity+OR+topic:bp/fwaas-cisco+OR\n> +topic:bp/freescale-fwaas-plugin+OR\n> +topic:bp/rpc-docs-and-namespace),n,z\n> \n> \n> \n> \n> \n> \n> From: Kyle Mestery <mestery at mestery.com>\n> Reply-To: \"OpenStack Development Mailing List (not for usage\n> questions)\" <openstack-dev at lists.openstack.org>\n> Date: Friday, January 16, 2015 at 1:33 PM\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Subject: [openstack-dev] [neutron] Next week\'s meeting is cancelled\n> (and some other notes)\n> \n> \n> \n> Folks:\n> \n> \n> It\'s a holiday in the US next Monday [1], so I\'m going to cancel the\n> weekly Neutron team meeting. We\'ll reconvene per the normal schedule\n> [2] next on Tuesday, January 27 (my birthday!) at 1400 UTC.\n> \n> One thing I\'d like to mention here is on the topic of reviewing code.\n> When reviewing code in Neutron, please make sure you\'re looking at\n> approved BPs for reviews. In this case, we should be actively\n> reviewing Kilo-2 BPs [3]. The links to the reviews are in the BPs\n> themselves. Until someone builds a better integrated dashboard for\n> gerrit that takes into account the LP priority, this is the best I can\n> offer you. But I encourage people to please prioritize their reviews\n> by looking at BPs approved rather than just popping gerrit up and\n> starting at the top of what it presents you.\n> \n> Thanks, have a great weekend everyone!\n> \n> Kyle\n> \n> [1] http://en.wikipedia.org/wiki/Martin_Luther_King,_Jr._Day\n> [2] https://wiki.openstack.org/wiki/Network/Meetings\n> [3] https://launchpad.net/neutron/+milestone/kilo-2\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D0DECF47.1DA28%dougw@a10networks.com>',NULL),('<1421446728.19633.43.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-16 16:18:48',-21600,'2015-01-16 22:18:48',NULL,'[openstack-community] OpenStack Community Weekly Newsletter (Jan 9\n	- 16)','2015 Election Results\nThank you to everyone who voted in this year\'s election. We reached\nquorum and passed the three bylaws amendments. We also reached quorum in\nelecting eight Individual Directors to the 2015 OpenStack Board of\nDirectors.\n\nAnd the winner is....\n\nIndividual Directors\n\n      * Tim Bell\n      * Russell Bryant\n      * Alex Freedland\n      * Rob Hirschfeld\n      * Vishvananda Ishaya\n      * Kavit Munshi\n      * Egle Sigler\n      * Monty Taylor\n\n\nPlatinum Directors\n\n      * Alan Clark\n      * Eileen Evans\n      * Toby Ford\n      * Van Lindberg\n      * Mark McLoughlin\n      * Todd Moore\n      * Imad Sousou\n      * John Zannos\n\n\nGold Directors\n\n      * Simon Anderson\n      * Robert Esker\n      * Tristan Goode\n      * Steven Hallett\n      * Chris Kemp\n      * Boris Renski\n      * Sean Roberts\n      * Lew Tucker\n\nKilo Nova deploy recommendations\n\nWhat would a Nova developer tell a deployer to think about before their\nfirst OpenStack install? Michael Still shares his thought process to\nconsider your options and make informed decisions.\n\nOpenStack Ambassadors Come Together\n\nAmbassadors to help other user groups through communicating. meeting\nalternating Weekly on first, third, fifth Tuesdays at 08:00 GMT and\nsecond and fourth Fridays at 18:00 GMT on the chat.freenode.net IRC\nchannel: #openstack-meeting-alt.\n\nSmall openstack \n\nAn interesting conversation on the Operators mailing list discussing\nrequest for small installation of openstack (about 3-5 nodes). The\nmessages started in December, continued in January and drifted to\ndiscuss distributed glance.\n\nUser self registration and management\n\nAdrian Turjak asked on the Development mailing list if there is any\ninterest or need for an open-source user registration and management\nservice for people using OpenStack. There seems to be a basic need a way\nfor users to sign up themselves, choose their own password, and request\nnew users to be added to their project. David Chadwick pointed to a\nblueprint and a demo of the system for University of Kent.Enrique Garcia\nalso expressed interest in helping out in the effort.\n\n\n\nThe Road to Vancouver\n\n      * Call For Speakers\n\nRelevant Conversations\n\n      * Requirements for future \"OpenStack projects\" \n      * The Future of OpenStack is Now, 2015\n      * Infrastructure Puppet module split sprint, Jan 28 \n      * Vancouver Design Summit format changes \n      * Another Nova spec update\n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [Nova] Kilo Release Status - just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme\n\nTips ?n Tricks\n\n      * By S?bastien Han: Fix nova-scheduler issue with RBD and UUID not\n        found\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * OpenStack Product Management Kilo Midcycle Meeting\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Heat AutoScalingGroup with different user data\n      * How to retrieve updated topology after an autoscaling has been\n        done?\n      * How to configure OCCI API with OpenStack/DevStack?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150116/aa3ae906/attachment.html>\n\n',NULL,NULL),('<1421446728.19633.43.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2015-01-16 16:18:48',-21600,'2015-01-16 22:18:48',NULL,'[openstack-announce] OpenStack Community Weekly Newsletter (Jan 9 -\n	16)','2015 Election Results\nThank you to everyone who voted in this year\'s election. We reached\nquorum and passed the three bylaws amendments. We also reached quorum in\nelecting eight Individual Directors to the 2015 OpenStack Board of\nDirectors.\n\nAnd the winner is....\n\nIndividual Directors\n\n      * Tim Bell\n      * Russell Bryant\n      * Alex Freedland\n      * Rob Hirschfeld\n      * Vishvananda Ishaya\n      * Kavit Munshi\n      * Egle Sigler\n      * Monty Taylor\n\n\nPlatinum Directors\n\n      * Alan Clark\n      * Eileen Evans\n      * Toby Ford\n      * Van Lindberg\n      * Mark McLoughlin\n      * Todd Moore\n      * Imad Sousou\n      * John Zannos\n\n\nGold Directors\n\n      * Simon Anderson\n      * Robert Esker\n      * Tristan Goode\n      * Steven Hallett\n      * Chris Kemp\n      * Boris Renski\n      * Sean Roberts\n      * Lew Tucker\n\nKilo Nova deploy recommendations\n\nWhat would a Nova developer tell a deployer to think about before their\nfirst OpenStack install? Michael Still shares his thought process to\nconsider your options and make informed decisions.\n\nOpenStack Ambassadors Come Together\n\nAmbassadors to help other user groups through communicating. meeting\nalternating Weekly on first, third, fifth Tuesdays at 08:00 GMT and\nsecond and fourth Fridays at 18:00 GMT on the chat.freenode.net IRC\nchannel: #openstack-meeting-alt.\n\nSmall openstack \n\nAn interesting conversation on the Operators mailing list discussing\nrequest for small installation of openstack (about 3-5 nodes). The\nmessages started in December, continued in January and drifted to\ndiscuss distributed glance.\n\nUser self registration and management\n\nAdrian Turjak asked on the Development mailing list if there is any\ninterest or need for an open-source user registration and management\nservice for people using OpenStack. There seems to be a basic need a way\nfor users to sign up themselves, choose their own password, and request\nnew users to be added to their project. David Chadwick pointed to a\nblueprint and a demo of the system for University of Kent.Enrique Garcia\nalso expressed interest in helping out in the effort.\n\n\n\nThe Road to Vancouver\n\n      * Call For Speakers\n\nRelevant Conversations\n\n      * Requirements for future \"OpenStack projects\" \n      * The Future of OpenStack is Now, 2015\n      * Infrastructure Puppet module split sprint, Jan 28 \n      * Vancouver Design Summit format changes \n      * Another Nova spec update\n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [Nova] Kilo Release Status - just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme\n\nTips ?n Tricks\n\n      * By S?bastien Han: Fix nova-scheduler issue with RBD and UUID not\n        found\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * OpenStack Product Management Kilo Midcycle Meeting\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Heat AutoScalingGroup with different user data\n      * How to retrieve updated topology after an autoscaling has been\n        done?\n      * How to configure OCCI API with OpenStack/DevStack?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20150116/aa3ae906/attachment.html>\n\n',NULL,NULL),('<1421446728.19633.43.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-16 16:18:48',-21600,'2015-01-16 22:18:48',NULL,'[Openstack-operators] OpenStack Community Weekly Newsletter (Jan 9\n	- 16)','2015 Election Results\nThank you to everyone who voted in this year\'s election. We reached\nquorum and passed the three bylaws amendments. We also reached quorum in\nelecting eight Individual Directors to the 2015 OpenStack Board of\nDirectors.\n\nAnd the winner is....\n\nIndividual Directors\n\n      * Tim Bell\n      * Russell Bryant\n      * Alex Freedland\n      * Rob Hirschfeld\n      * Vishvananda Ishaya\n      * Kavit Munshi\n      * Egle Sigler\n      * Monty Taylor\n\n\nPlatinum Directors\n\n      * Alan Clark\n      * Eileen Evans\n      * Toby Ford\n      * Van Lindberg\n      * Mark McLoughlin\n      * Todd Moore\n      * Imad Sousou\n      * John Zannos\n\n\nGold Directors\n\n      * Simon Anderson\n      * Robert Esker\n      * Tristan Goode\n      * Steven Hallett\n      * Chris Kemp\n      * Boris Renski\n      * Sean Roberts\n      * Lew Tucker\n\nKilo Nova deploy recommendations\n\nWhat would a Nova developer tell a deployer to think about before their\nfirst OpenStack install? Michael Still shares his thought process to\nconsider your options and make informed decisions.\n\nOpenStack Ambassadors Come Together\n\nAmbassadors to help other user groups through communicating. meeting\nalternating Weekly on first, third, fifth Tuesdays at 08:00 GMT and\nsecond and fourth Fridays at 18:00 GMT on the chat.freenode.net IRC\nchannel: #openstack-meeting-alt.\n\nSmall openstack \n\nAn interesting conversation on the Operators mailing list discussing\nrequest for small installation of openstack (about 3-5 nodes). The\nmessages started in December, continued in January and drifted to\ndiscuss distributed glance.\n\nUser self registration and management\n\nAdrian Turjak asked on the Development mailing list if there is any\ninterest or need for an open-source user registration and management\nservice for people using OpenStack. There seems to be a basic need a way\nfor users to sign up themselves, choose their own password, and request\nnew users to be added to their project. David Chadwick pointed to a\nblueprint and a demo of the system for University of Kent.Enrique Garcia\nalso expressed interest in helping out in the effort.\n\n\n\nThe Road to Vancouver\n\n      * Call For Speakers\n\nRelevant Conversations\n\n      * Requirements for future \"OpenStack projects\" \n      * The Future of OpenStack is Now, 2015\n      * Infrastructure Puppet module split sprint, Jan 28 \n      * Vancouver Design Summit format changes \n      * Another Nova spec update\n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [Nova] Kilo Release Status - just passed spec freeze \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme\n\nTips ?n Tricks\n\n      * By S?bastien Han: Fix nova-scheduler issue with RBD and UUID not\n        found\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Jan 19, 2015 OpenStack Meetup Nuremberg Nuremberg, Bavaria, DE\n      * Jan 22, 2015 OpenStack L.A. January Meetup Pasadena, CA, US\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n\nOther News\n\n      * OpenStack Product Management Kilo Midcycle Meeting\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Heat AutoScalingGroup with different user data\n      * How to retrieve updated topology after an autoscaling has been\n        done?\n      * How to configure OCCI API with OpenStack/DevStack?\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150116/aa3ae906/attachment.html>\n\n',NULL,NULL),('<1421621586.19633.60.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-18 14:53:06',-28800,'2015-01-18 22:53:06',NULL,'[openstack-dev] [all] \"All rights reserved\" V.S. \"Apache\n license\"','On Sat, 2015-01-17 at 16:07 -0500, Monty Taylor wrote:\n> It\'s actually a set of words that is no longer necessary as of the year\n> 2000. It\'s not communicating anything about a granted license, which is\n> what the Apache License does - it\'s actually just asserting that the\n> original copyright holder asserts that they have not waived any of their\n> rights as a copyright holder. However, the Berne convention grants this\n> automatically without a positive assertion.\n\nI think ZhiQiang Fan\'s question is about the sentence \"all rights\nreserved\" followed by the implicit \"some rights not reserved\" granted by\nthe Apache license, rather than the meaning of \'all rights reserved\'\nalone. You\'re right that such sentence by itself is meaningless but in\nthe context of the Apache license I think it\'s confusing at best,\nprobably wrong.\n\nI don\'t remember seeing this case discussed on legal-discuss and I\'m\nquite sure that the right way to apply the Apache license to source code\nis *not* by saying \"(C) `date +%Y` Foo Corp, All Rights Reserved\"\nfollowed by Apache license (see appendix on\nhttp://www.apache.org/licenses/LICENSE-2.0)\n\nMaybe a passage on legal-discuss would be better?\n\n/stef\n\n\n\n','<54BACF16.2090905@inaugust.com>',NULL),('<1421697366.36523183.1394824393126.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-14 15:13:13',-14400,'2014-03-14 19:13:13',NULL,'[Openstack-docs] Conventions on naming [clarifications]','----- Original Message -----\n> On 03/14/2014 06:33 AM, Don Domingo wrote:\n> > Hi,\n> > \n> > I apologize for bringing this up a bit late, seeing as the OpenStack\n> > project naming conventions have already been discussed last month:\n> > http://lists.openstack.org/pipermail/openstack-docs/2014-February/003804.html\n> > \n> > Anyhow, I wanted to clarify:\n> > \n> > * Why do \"Identity Service\" and \"Image Service\" have the word \"Service\" as\n> > part of their names? I assume that this is the case, seeing as \"Service\"\n> > is initcapped?\n> \n> I guess that\'s historical..\n\nYeah, it\'s interesting because the names endorsed by the TC are recorded here:\n\n    http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml\n\n...and while \"Image Service appears to be recorded there, \"Identity Service\" is referred to just as \"Identity\". I\'m not sure there is a method to the madness there :). Which programs get included in core and thus can be prefixed with OpenStack is the domain of the board.\n\nThanks,\n\nSteve\n\n\n','<5323503F.4020607@suse.com>',NULL),('<1421699625.5009.5.camel@alliance-it.com>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-19 15:33:45',-18000,'2015-01-19 20:33:45',NULL,'[openstack-community] Baltimore OpenStack Meetup #2 - Feb 19','OpenStack meetup happening Feb. 19th at #Alliance Baltimore MD, RSVP via http://www.meetup.com/OpenStack-Baltimore/  More updates via @OpenStackMD\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150119/3ee4a9ca/attachment.html>\n\n',NULL,NULL),('<1421699752.5009.7.camel@alliance-it.com>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-19 15:35:52',-18000,'2015-01-19 20:35:52',NULL,'[openstack-community] Richmond VA OpenStack Meetup #2 - Feb 19','OpenStack meetup happening Jan 22nd at #Alliance Richmond VA RSVP via http://www.meetup.com/OpenStack-Richmond/<http://www.meetup.com/OpenStack-Richmond/?> updates via @OpenStackVA\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150119/1021f801/attachment.html>\n\n','<1421699625.5009.5.camel@alliance-it.com>',NULL),('<14216c2f200.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-01 20:02:25',-25200,'2013-11-02 03:02:25',NULL,'[Openstack] Wiping of old cinder volumes','Why not just ask the volume driver to \"delete securely\" or \'delete with wipe\'?\nIt could even be a level of erasure, if people want to be real paranoid.\nWhatever it is, the vendor\'s volume driver will know the best way to do it.\n\n\n\n\n','<CA+qL3LWpyT6OR0CRxySnoYsr6VVoeS_1wMoh=gJc17=MJ6A84g@mail.gmail.com>',NULL),('<1421704484.5814.12.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-19 15:54:44',-21600,'2015-01-19 21:54:44',NULL,'[openstack-dev] [api] Optional Properties in an Entity','On Mon, 2015-01-19 at 19:55 +0000, Douglas Mendizabal wrote:\n> I?m curious about something that came up during a bug discussion in\n> one of the Barbican weekly meetings.  The question is about optional\n> properties in an entity.  e.g. We have a Secret entity that has some\n> properties that are optional, such as the Secret?s name.  We were\n> split on what the best approach for returning the secret\n> representation would be when an optional property is not set.\n> \n> In one camp, some developers would like to see the properties returned\n> no matter what.  That is to say, the Secret dictionary would include a\n> key for ?name? set to null every single time.  i.e.\n[snip]\n> On the other camp, some developers would like to see optional\n> properties omitted if they were not set by the user.\n> \n> The advantage of always returning the property is that the response is\n> easier to parse, since you don?t have to check for the existence of\n> the optional keys.  The argument against it is that it makes the API\n> more rigid, and clients more fragile.\n\nI keep trying to come up with technical arguments for or against, and\nthe only one I can come up with that has any true meaning is that\nomitting properties reduces bandwidth usage a little?but I don\'t really\nthink that\'s something we\'ve particularly concerned about.  Thus, from a\ntechnical perspective, either way is perfectly fine, and we just have to\nanswer consistency.\n\nWhen we look at consistency, we look at everything else in OpenStack.\n>From the standpoint of the nova API (with which I am the most familiar),\nI am not aware of any property that is ever omitted from any payload\nwithout versioning coming in to the picture, even if its value is null.\nThus, I would argue that we should encourage the first situation, where\nall properties are included, even if their value is null.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<BDA299C2-332B-4264-BB38-8921C9455AD0@rackspace.com>',NULL),('<1421727687.4087.10.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 04:21:27',0,'2015-01-20 04:21:27',NULL,'[openstack-dev] [neutron][lbaas] Pool member status \'ACTIVE\'\n even on health check failure','Hi Varun,\n\nCould you tell me which driver you are using? If you\'re running the\nHaproxyOnHostPluginDriver then that should do a check every 6 seconds\nfor members being down.  However, other drivers may not do this.  It\'s\nup to the driver.\n\nAs for providing health monitor stats, those currently are not being\nprovided.  There haven\'t been any plans for that yet because everyone\nhas been focused on getting the v2 API out.  Which is almost complete\nand plan for that to be completed for Kilo-3.  If you\'d like to be able\nto retrieve some health stats, please list them and let us know.  We\'ll\nhopefully be able to get them in after v2 has completed.\n\nThanks,\nBrandon\n\nOn Mon, 2015-01-19 at 14:42 -0800, Varun Lodaya wrote:\n> Hi All,\n> \n> \n> I am trying to get LBaaS running on stable Juno. I can get all the\n> LBaaS components correctly installed and working as expected. But I am\n> facing some issues with the health-monitor. I am not quite sure if\n> it?s working as expected.\n> \n> \n> I have 2 ubuntu servers as members of http-pool and I have stopped\n> apache process on 1 of the servers. I have HTTP health-monitor\n> configured on the pool which runs every 1 min and checks for 200\n> response code on HTTP GET. I was expecting it to FAIL after 3 retries\n> and make the status ?INACTIVE? for the member where apache is not\n> running. But for some reason, it?s always ACTIVE. \n> \n> \n> Can somebody help me with how is it suppose to work and if it?s a bug?\n> \n> \n> Also, currently I don?t see any health monitor stats with neutron. Is\n> there any plan to get health monitor stats in future releases?\n> \n> \n> Thanks,\n> Varun\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D0E2C86E.12FC%Lodaya_VarunMukesh@symantec.com>',NULL),('<1421770497.6147.24.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 17:14:57',3600,'2015-01-20 16:14:57',NULL,'[openstack-dev] [Fuel] 10Gbe performance issue.','Hi,\n\nI am facing issue with performance of 10 Gigabit Ethernet.\n\nEnvironment 2 hosts each:\n- 2 * Intel(R) Xeon(R) CPU E5-2690 v2\n- Intel 82599ES 10Gb Ethernet\n- 128GB RAM\n\nSystem:\n- Centos 6.5 delivered by fuel 6.0\n\niperf during test of network performance over single stream report\n2,5-3Gbps (when using 4+ connection, cumulative transfer can hit over\n9Gbps)\n\nFor comparison, same test was run on official Centos 6.5 with result at\nminimum 9,3 Gbps\n\nIn both cases default MTU 1500 was set.\n\n>From my analyses it looks like something is limiting i/o performance per\nstream.\n\nAre you aware of this issue, and can you comment on it?\n\nThis is critical for our deployment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150120/a4484bb5/attachment.html>\n\n',NULL,NULL),('<1421779786.4035.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 18:49:47',0,'2015-01-20 18:49:47',NULL,'[openstack-dev] [neutron][lbaas] Health Monitor association\n with pool','Hmm that is for lbaas v2 docs which shouldn\'t be in the docs yet because\nit is not ready.  We will need to file a bug with the docs team to get\nthe v1 docs back in until v2 is ready to be used (which should be\nrelatively soon).  Thanks for letting us know!\n\nThanks,\nBrandon\n\nOn Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:\n> Hi,\n> \n> \n> The openstack documentation for LBaaS Neutron v2 APIs does not clearly\n> define way to associate a HealthMonitor with a pool.\n>       * Will it be done via pool update - put method at\n>         \"/v2.0/pools/{pool_id}\".\n>       * Or it will be done via post method at\n>         \"/v2.0/lb/pools/{pool_id}/health_monitors\"\n> Any other link detailing LBaaS v2 APIs will be great help.\n> Thanks in advance. \n> \n> \n> Regards\n> Shreshtha Joshi\n> \n> \n> =====-----=====-----=====\n> Notice: The information contained in this e-mail\n> message and/or attachments to it may contain \n> confidential or privileged information. If you are \n> not the intended recipient, any dissemination, use, \n> review, distribution, printing or copying of the \n> information contained in this e-mail message \n> and/or attachments to it are strictly prohibited. If \n> you have received this communication in error, \n> please notify us by reply e-mail or telephone and \n> immediately and permanently delete the message \n> and any attachments. Thank you\n> \n\n\n','<OF8A88BC7E.BA9437A7-ON65257DD3.001700BD-65257DD3.002400D1@tcs.com>',NULL),('<1421779874.4035.1.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 18:51:15',0,'2015-01-20 18:51:15',NULL,'[openstack-dev] [neutron][lbaas] Pool member status \'ACTIVE\'\n even on health check failure','Yeah before we get those stats in we\'ll need to finalize v2 because that\nwill affect how the API shows those types of stats to the user.\n\nOn Mon, 2015-01-19 at 22:33 -0800, Varun Lodaya wrote:\n> Hey Brandon,\n> \n> Thanks for the response. My bad. Seems there is a small bug in horizon.\n> The moment you configure a health monitor, it shows up in the pool. I\n> thought it automatically got associated. But when I checked via CLI, it\n> was not. After associating it via CLI (not able to associate it via\n> horizon, the drop down for health-monitors doesn?t seem to work), it seems\n> to work fine :).\n> \n> As per stats, ideally, it?s good to get counters like:\n> ICMP successful requests: x\n> ICMP response  timeouts: y\n> ICMP response failures: z\n> \n> HTTP successful responses: a\n> HTTP timeouts: b\n> .\n> .\n> .\n> \n> \n> Just an initial thought, this sort of verifies that monitors are working\n> as expected. Like in current situation, I had to manually login to the\n> server to see if the server is catering to any health-monitoring requests.\n> \n> Even getting haproxy stats is not very straightforward, as you need to\n> open a unix socket in haproxy cfg and restart the haproxy instance which\n> might not be possible in production sometimes.\n> \n> Thanks,\n> Varun\n> \n> \n> \n> On 1/19/15, 8:21 PM, \"Brandon Logan\" <brandon.logan at RACKSPACE.COM> wrote:\n> \n> >Hi Varun,\n> >\n> >Could you tell me which driver you are using? If you\'re running the\n> >HaproxyOnHostPluginDriver then that should do a check every 6 seconds\n> >for members being down.  However, other drivers may not do this.  It\'s\n> >up to the driver.\n> >\n> >As for providing health monitor stats, those currently are not being\n> >provided.  There haven\'t been any plans for that yet because everyone\n> >has been focused on getting the v2 API out.  Which is almost complete\n> >and plan for that to be completed for Kilo-3.  If you\'d like to be able\n> >to retrieve some health stats, please list them and let us know.  We\'ll\n> >hopefully be able to get them in after v2 has completed.\n> >\n> >Thanks,\n> >Brandon\n> >\n> >On Mon, 2015-01-19 at 14:42 -0800, Varun Lodaya wrote:\n> >> Hi All,\n> >> \n> >> \n> >> I am trying to get LBaaS running on stable Juno. I can get all the\n> >> LBaaS components correctly installed and working as expected. But I am\n> >> facing some issues with the health-monitor. I am not quite sure if\n> >> it?s working as expected.\n> >> \n> >> \n> >> I have 2 ubuntu servers as members of http-pool and I have stopped\n> >> apache process on 1 of the servers. I have HTTP health-monitor\n> >> configured on the pool which runs every 1 min and checks for 200\n> >> response code on HTTP GET. I was expecting it to FAIL after 3 retries\n> >> and make the status ?INACTIVE? for the member where apache is not\n> >> running. But for some reason, it?s always ACTIVE.\n> >> \n> >> \n> >> Can somebody help me with how is it suppose to work and if it?s a bug?\n> >> \n> >> \n> >> Also, currently I don?t see any health monitor stats with neutron. Is\n> >> there any plan to get health monitor stats in future releases?\n> >> \n> >> \n> >> Thanks,\n> >> Varun\n> >> \n> >>_________________________________________________________________________\n> >>_\n> >> OpenStack Development Mailing List (not for usage questions)\n> >> Unsubscribe: \n> >>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >__________________________________________________________________________\n> >OpenStack Development Mailing List (not for usage questions)\n> >Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<D0E334E2.130A%Lodaya_VarunMukesh@symantec.com>',NULL),('<1421780510.3533359.216378869.3B14350A@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-20 11:01:50',-28800,'2015-01-20 19:01:50',NULL,'[OpenStack-Infra] Software Factory Openstack Infra Collaboration','On Wed, Jan 14, 2015, at 10:45 AM, Christian Schwede wrote:\n> Hello all,\n> \n> we built an internal development platform called \"Software Factory\" and\n> opened it up under an Apache License on Github. While we essentially use\n> the same tools as the openstack-infra team, like Gerrit, Zuul, Jenkins;\n> our deployment is quite different with eDeploy and Heat for provisioning\n> and custom made Puppet manifests.\n> \n> We have also added a few elements to expand and unify the development\n> experience, including:\n> \n> - Support for other bug trackers (e.g. redmine)\n> - Support for other auth systems (e.g. github)\n> - CLI for creating projects\n> - Unifying top-level menu\n> - Top-level dashboard\n> \n> At  this stage of development, we understand that some of our work is\n> within the scope of the openstack-infra, which is why we would like to\n> start the conversation on how to proceed and potentially collaborate in\n> conjunction with the infra community. We are interested in having\n> discussions about the future of openstack-infra project and how we might\n> contribute.\nAwesome. It would be great to collaborate to extend the OpenStack infra\nto better meet your needs and likely better meet our needs in the\nprocess. I am excited to see what we can do.\n>\n> In particular, we are looking into:\n>  - Extending Zuul, in particular on configuration file management and\n> multiple nodes job assignment.\nWe talked briefly about multiple node assignment and how we accomplish\nthat today. Would be great to hear back to see if this does what you\nneed. If not we should work on fixing that. (For those that may not have\nseen the IRC discssion nodepool can build groups of nodes and assign\nthem to Jenkins as an atomic unit. This is provided by the subnode\nfeature mentioned in the nodepool docs [0].\n> - Generic third party CI integration\nWe would very much like this too. Current idea of getting there is to\nsplit out our puppet modules into independent modules to make them more\ncomposable, then once that is done we can compose them for the infra\nteam and for third party CI systems. We are having a virtual sprint to\nfinish up the initial puppet module cleanup January 28th [1], if you are\ninterested in helping out you can join us there.\n> \n> We would like to discuss the kind of challenges the infra team faces to\n> potentially align our work and submit patches upstream.\nThis might make a good Infra meeting topic [2] to kick off the initial\ndiscussion and figure out where we can go from there?\n> \n> For further info, access to source code, and documentation please head\n> over to http://softwarefactory.enovance.com\n> \n> Best Regards,\n> \n> The Software Factory Team - Fabien, George, James, Mathieu, Tristan and\n> Christian\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n[0] http://ci.openstack.org/nodepool/configuration.html#labels\n[1]\nhttp://lists.openstack.org/pipermail/openstack-infra/2015-January/002323.html\n[2] https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting\n\nThanks,\nClark\n\n\n','<54B6B949.8050407@enovance.com>',NULL),('<1421788901.3576557.216433545.37643647@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-20 13:21:41',-28800,'2015-01-20 21:21:41',NULL,'[openstack-dev] [tc][python-clients] More freedom for all\n python clients','On Wed, Jan 14, 2015, at 04:50 AM, Sean Dague wrote:\n> On 01/14/2015 03:55 AM, Flavio Percoco wrote:\n> > On 13/01/15 14:31 -0500, Sean Dague wrote:\n> >> On 01/13/2015 02:10 PM, Jay Pipes wrote:\n> >>> On 01/13/2015 12:39 PM, Zane Bitter wrote:\n> >>>> On 13/01/15 10:01, Jeremy Stanley wrote:\n> >>>>> On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:\n> >>>>>> Why doesn\'t rally just remove itself from projects.txt, then there\n> >>>>>> would be no restrictions on what it adds.\n> >>>>>\n> >>>>> I second this recommendation. If Rally wants to depend on things\n> >>>>> which are not part of OpenStack and not required to run or test\n> >>>>> OpenStack in an official capacity (and since it\'s not an official\n> >>>>> OpenStack project it\'s entirely within its rights to want to do\n> >>>>> that), then forcing it to comply with the list of requirements for\n> >>>>> official OpenStack projects is an unnecessarily restrictive choice.\n> >>>>\n> >>>> FWIW I don\'t really agree with this advice. The purpose of\n> >>>> openstack/requirements is to ensure that it\'s possible to create a\n> >>>> distribution of OpenStack without conflicting version requirements, not\n> >>>> to force every project to use every dependency listed. As such, some\n> >>>> co-ordination around client libraries for related projects seems\n> >>>> like it\n> >>>> ought to be an uncontroversial addition. (Obviously it\'s easy to\n> >>>> imagine\n> >>>> potential additions that would legitimately be highly controversial,\n> >>>> but\n> >>>> IMHO this isn\'t one of them.) Saying that we require people to use our\n> >>>> tools to get into the club but that our tools are not going to\n> >>>> accommodate them in any way until they are in sounds a bit too close to\n> >>>> \"Go away\" to my ears.\n> >>>\n> >>> +1\n> >>\n> >> I think as we grow global-requirements probably needs to be broken up\n> >> into functional lists. What\'s allowed in base-iass, what\'s allowed in\n> >> application services, what\'s allowed in docs, etc, etc.\n> >>\n> >> The complexity of keeping the g-r list actually working goes up sort of\n> >> n^2 as the size of it, because pip doesn\'t have a real solver. This is a\n> >> barely functional set of plate spinning so \"just add everything\" misses\n> >> the point that the breaks get more and more difficult to unwind.\n> >>\n> >> If someone is up for stepping up and contributing to breaking up into\n> >> \"domains\", please do. But I think while this remains a global list we\n> >> really do need to be a bit careful here.\n> > \n> > Do we really need a per-domain g-r?\n> > \n> > With the upcoming changes in the openstack governance model, I believe\n> > this won\'t scale even if we break it into per-domain basis. Some\n> > questions that need answeres are:\n> > \n> > - Who\'s going to review the per domain g-r ?\n> > \n> > If it\'s a centralized team, then it won\'t definitely scale. If it\'s\n> > the domain team then, what\'s the real point of having these\n> > requirements?\n> > \n> > - How are we going to support the creation and maintnance of these g-r\n> >  in the gate? Are they actually worth it?\n> > \n> > \n> > While I understand why we have g-r, I really don\'t think it\'ll scale\n> > for a broader community as we\'re envisioning it. With that in mind,\n> > I\'d probably recommend to have 1 requirements group for the base-caas\n> > integrated gate and let other projects and groups have their own\n> > requirements. That is, non base-caas projects should get the versions\n> > of their common requirements from g-r so that they won\'t conflict if\n> > they\'re installed alongside with any of the base-caas projects. But\n> > other than those base requirements, I\'d let non base-caas projects\n> > have what they need (which is pretty much what heat\'s team has done\n> > with the contrib packages, AFAICT).\n> > \n> > I know this opens the doors for version conflicts between the\n> > requirements of non base-caas projects but I think this is a more\n> > welcoming (and non-blocking) way to do things until we\'ve a better\n> > one.\n> > \n> > Hope the above makes some sense.... I blame the lack of coffee if it\n> > doesn\'t,\n> > Flavio\n> \n> We have the base infrastructure of that in devstack today with a SOFT\n> requirements update -\n> https://github.com/openstack-dev/devstack/blob/master/functions-common#L1696-L1704\n> \n> If you are not in projects.txt, and you set your REQUIREMENTS_MODE=soft\n> in your devstack run, we will leave extra dependencies untouched.\n> Probably a few more bits required to make it really easy to expose, but\n> that direction is also feasable.\n> \n> The reason I brought up domains though is that some groups really want\n> the facility to have common requirements lists across a domain. Like the\n> OpenStack Docs team. They\'ve currently inserted a ton of stuff in g-r\n> that really shouldn\'t be there because they have a lot of git trees, and\n> the synchronization is a nice feature.\n> \n> However, if there were domain specific lists, that would be fine. A\n> collection of projects that want to coordinate could all agree on a\n> domain specific set of lists, and off we go. Maybe that list wouldn\'t\n> even need to be contained in the main repo, it could be in a sub repo so\n> have different approvers.\n> \nThis ml thread came up in the TC meeting today and I am responding here\nto catch the thread up with the meeting. The soft update option is the\nsuggested fix for non openstack projects that want to have most of their\nrequirements managed by global requirements.\n\nFor the project structure reform opening things up we should consider\nloosening the criteria to get on the list and make it primarily based on\ntechnical criteria such as py3k support, license compatibility, upstream\nsupport/activity, and so on (basically the current criteria with less of\na focus on where the project comes from if it is otherwise healthy).\nThen individual projects would choose the subset they need to depend on.\nThis model should be viable with different domains as well if we go that\nroute.\n\nThe following is not from the TC meeting but addressing other portions\nof this conversation:\n\nAt least one concern with this option is that as the number of total\nrequirements goes up is the difficulty in debugging installation\nconflicts becomes more difficult too. I have suggested that we could\nwrite tools to help with this. Install bisection based on pip logs for\nexample, but these tools are still theoretical so I may be\noverestimating their usefulness.\n\nTo address the community scaling aspect I think you push a lot of work\nback on deployers/users if we don\'t curate requirements for anything\nthat ends up tagged as \"production ready\" (or whatever the equivalent\ntag becomes). Essentially we are saying \"this doesn\'t scale for us so\nnow you deal with the fallout. Have fun\", which isn\'t very friendly to\npeople consuming the software. We already have an absurd number of\nrequirements and management of them has appeared to scale. I don\'t\nforesee my workload going up if we open up the list as suggested.\n\nThanks,\nClark\n\n\n\n','<54B66624.4050103@dague.net>',NULL),('<1421837636.2601.35.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 10:53:42',0,'2015-01-21 10:53:42',NULL,'[openstack-dev] [Fuel] 10Gbe performance issue.','On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:\n>[...]\n> How this was measured? VM to VM? Compute to compute? \niperf between compute/ceph-compute/ceph nodes.\n\n> In any case, what is your deployment configuration, especially VLAND or GRE, networking gear, etc.\nWe have almost default setup from clean fuel 6.0, vlan based.\nWe are doing iperf based on 82599ES 10-Gigabit SFP+ interfaces (used in\nour setup only for storage network) connected by fibre through Arista\n7150.\n\nResults on centos 6.5 deployed from fuel:\n 0.0-10.0 sec  3.09 GBytes  2.65 Gbits/sec\n\nResults on centos 6.5 from official site:\n 0.0-10.0 sec  10.9 GBytes  9.38 Gbits/sec\n\nIn both cases tests were done with default tcp window size - 19.3KByte.\nIn both cases default mtu was with value 1500.\n\nCommands used in test (after adding iperf tool from rpm):\n  on one node:\n    iperf -s -p 8777 \n  on other node:\n    iperf -c ip_address_of_server_in_storage_network -p 8777 -t 10\n\n(port 8777 is one of passed as ACCEPT in iptables setup from fuel)\n\nDifferences are in kernel (from centos or from mirantis), values\nin /etc/sysctl.conf (plain or from mirantis) and probably in cgroups\nsettings.\n\nProbably in ~30 minutes we also will have results on plain centos with\nmirantis kernel, and on fuel deployed centos with plain centos kernel\n(2.6.32 in both cases, but with different patchset subnumber).\n\n-- \n  Regards,\n  jell\n\n','<53D5A031-2019-408E-AB5D-8ED452263B03@mirantis.com>',NULL),('<1421838559.2601.46.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 11:09:04',0,'2015-01-21 11:09:04',NULL,'[openstack-dev] [Fuel] [webui] Setting one dns server address in ui.','Hi.\n\nIn time of environment setup, there is a place in webui to provide dns\nservers addresses on network tab, in neutron l3 configuration. There is\nno way to set only one address.\nSetting same ip in both input fields is permitted by webui, but later,\nin time of deploy - neutron called from puppet files fails to setup\ninternal network (Net04 in my setup).\n\nIf two addresses are mandatory, there should be check if they are\ndifferent?\n\nOr should be there a way to setup only one address?\n\n-- \n  Regards,\n  jell\n\n',NULL,NULL),('<1421839239.2601.53.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 11:20:24',0,'2015-01-21 11:20:24',NULL,'[openstack-dev] [Fuel] 10Gbe performance issue.','On Wed, 2015-01-21 at 10:53 +0000, Skamruk, Piotr wrote:\n> On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:\n> >[...]\n> > How this was measured? VM to VM? Compute to compute? \n>[...]\n> Probably in ~30 minutes we also will have results on plain centos with\n> mirantis kernel, and on fuel deployed centos with plain centos kernel\n> (2.6.32 in both cases, but with different patchset subnumber).\n\nOK, our test were done little badly. On plain centos iperf were runned\ndirectly on physical interfaces, but under fuel deployed nodes... We\nware using br-storage interfaces, which in real are openvs based.\n\nSo this is not a kernel problem, but this is a single stream over ovs\nissue.\n\nSo we will investigate this further... \n\n-- \n  Regards,\n  jell\n\n','<1421837636.2601.35.camel@intel.com>',NULL),('<1421843021.2601.56.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 12:23:26',0,'2015-01-21 12:23:26',NULL,'[openstack-dev] [Fuel] [webui] Setting one dns server address\n in ui.','On Wed, 2015-01-21 at 15:50 +0400, Vladimir Kuklin wrote:\n> Piotr, the easiest workaround is to patch neutron_subnet type to\n> perform munge operation that uses uniq function somewhere here:\n> https://github.com/stackforge/puppet-neutron/blob/master/lib/puppet/type/neutron_subnet.rb#L56-L60. We would also appreciate if you filed a bug to Fuel launchpad.\nFilled bug lies under https://bugs.launchpad.net/fuel/+bug/1413182 link.\n\n-- \n  Regards,\n  jell\n\n\n','<CAHAWLf3_yVjMMEWF3jQHO-DDuoU2T-reySoUCF99RTN5s8_RDA@mail.gmail.com>',NULL),('<1421859109.6237.6.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-21 16:51:49',0,'2015-01-21 16:51:49',NULL,'[openstack-dev] [neutron][lbaas] Health Monitor association\n with pool','Thanks for your quick work on this Anne!\n\nOn Tue, 2015-01-20 at 15:54 -0600, Anne Gentle wrote:\n> \n> \n> On Tue, Jan 20, 2015 at 12:49 PM, Brandon Logan\n> <brandon.logan at rackspace.com> wrote:\n>         Hmm that is for lbaas v2 docs which shouldn\'t be in the docs\n>         yet because\n>         it is not ready.  We will need to file a bug with the docs\n>         team to get\n>         the v1 docs back in until v2 is ready to be used (which should\n>         be\n>         relatively soon).  Thanks for letting us know!\n> \n> \n> Hi all,\n> \n> \n> I\'ve fixed the logged\n> bug: https://bugs.launchpad.net/openstack-manuals/+bug/1412944\n> \n> \n> Longer explanation, the referenced link [1] is to a source document\n> that is going to openstack-attic as soon as the infra team does their\n> scheduled gerrit downtime. [2] Also, since our build jobs don\'t delete\n> old files, I had to manually delete the outdated docs. Once this spec\n> is complete this particular issue won\'t happen any more. [3] \n> \n> \n> \n> Thanks,\n> Anne\n> \n> \n> 1. http://docs.openstack.org/api/openstack-network/2.0/content/lbaas_ext.html\n> 2. https://review.openstack.org/#/c/145289/\n> 3. http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html\n> \n> \n>  \n>         \n>         Thanks,\n>         Brandon\n>         \n>         On Tue, 2015-01-20 at 12:03 +0530, Shreshtha Joshi wrote:\n>         > Hi,\n>         >\n>         >\n>         > The openstack documentation for LBaaS Neutron v2 APIs does\n>         not clearly\n>         > define way to associate a HealthMonitor with a pool.\n>         >       * Will it be done via pool update - put method at\n>         >         \"/v2.0/pools/{pool_id}\".\n>         >       * Or it will be done via post method at\n>         >         \"/v2.0/lb/pools/{pool_id}/health_monitors\"\n>         > Any other link detailing LBaaS v2 APIs will be great help.\n>         > Thanks in advance.\n>         >\n>         >\n>         > Regards\n>         > Shreshtha Joshi\n>         >\n>         >\n>         > =====-----=====-----=====\n>         > Notice: The information contained in this e-mail\n>         > message and/or attachments to it may contain\n>         > confidential or privileged information. If you are\n>         > not the intended recipient, any dissemination, use,\n>         > review, distribution, printing or copying of the\n>         > information contained in this e-mail message\n>         > and/or attachments to it are strictly prohibited. If\n>         > you have received this communication in error,\n>         > please notify us by reply e-mail or telephone and\n>         > immediately and permanently delete the message\n>         > and any attachments. Thank you\n>         >\n>         \n>         __________________________________________________________________________\n>         OpenStack Development Mailing List (not for usage questions)\n>         Unsubscribe:\n>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Anne Gentle\n> annegentle at justwriteclick.com\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAD0KtVHVsVqzedfKM0i5scgytEE9X-gKBRDw-sY4cDSvODRzbw@mail.gmail.com>',NULL),('<1421925569.6704.17.camel@intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 12:19:29',3600,'2015-01-22 11:19:29',NULL,'[openstack-dev] [Fuel] 10Gbe performance issue.','Thanks, Rick looks like GRO was something we was missing in our setup.\n\nHere are some results form my tests\n\niperf with GRO disabled on server side : 2,5-3Gbps\niperf with GRO enabled on server side :  3,5-4 Gbps (gro was enabled on\neth0, br-eth0, br-storage)\n\nAdditionally i used OVS VLAN splinters option \"Enable OVS VLAN splinters\nhard trunks workaround\" of fuel deployment\n\niperf with GRO disabled using hw VLAN splinters and MTU 1,5k : ~5 Gbps\niperf with GRO disabled using hw VLAN splinters and MTU 9k    : 9-10\nGbps\niperf with GRO enabled using hw VLAN splinters and MTU 1,5k  : 9-10 Gbps\n\nThen i tested iperf between machines of 2 different configurations (with\nOVS VLAN splinters, and without it),\n\ndefault->OVS_VLAN_spliters (GRO disabled) : 2,5 Gbps\ndefault->OVS_VLAN_spliters (GRO enabled) : 5 Gbps\n\nOVS_VLAN_spliters->default (GRO disabled) : 2,5-3 Gbps\nOVS_VLAN_spliters->default (GRO enabled) : 5-10 Gbps\n\nThis looks like OVS is not performing good enough in this setup for\ntagged vlans (our br-storage is running on tagged vlan)\n\nany commands?\n\n\nDnia 2015-01-21, ?ro o godzinie 08:47 -0800, Rick Jones pisze:\n\n> On 01/21/2015 03:20 AM, Skamruk, Piotr wrote:\n> > On Wed, 2015-01-21 at 10:53 +0000, Skamruk, Piotr wrote:\n> >> On Tue, 2015-01-20 at 17:41 +0100, Tomasz Napierala wrote:\n> >>> [...]\n> >>> How this was measured? VM to VM? Compute to compute?\n> >> [...]\n> >> Probably in ~30 minutes we also will have results on plain centos with\n> >> mirantis kernel, and on fuel deployed centos with plain centos kernel\n> >> (2.6.32 in both cases, but with different patchset subnumber).\n> >\n> > OK, our test were done little badly. On plain centos iperf were runned\n> > directly on physical interfaces, but under fuel deployed nodes... We\n> > ware using br-storage interfaces, which in real are openvs based.\n> >\n> > So this is not a kernel problem, but this is a single stream over ovs\n> > issue.\n> >\n> > So we will investigate this further...\n> >\n> \n> Not sure if iperf will emit it, but you might look at the bytes per \n> receive on the receiving end.  Or  you can hang a tcpdump off the \n> receiving interface (the br-storage I presume here) and see if you are \n> getting the likes of GRO - if you are getting GRO you will see \"large\" \n> TCP segments in the packet trace on the receiving side.  You can do the \n> same with the physical interfaces for comparison.\n> \n> 2.5 to 3 Gbit/s \"feels\" rather like what one would get with 10 GbE in \n> the days before GRO/LRO.\n> \n> happy benchmarking,\n> \n> rick jones\n> http://www.netperf.org/\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150122/f587102e/attachment.html>\n\n','<54BFD824.3030105@hp.com>',NULL),('<1421955427.3990.0.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 19:37:06',0,'2015-01-22 19:37:06',NULL,'[openstack-dev] [neutron] Changes to the core team','Congratulations Doug!\n\nOn Thu, 2015-01-22 at 11:21 -0600, Kyle Mestery wrote:\n> On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery <mestery at mestery.com>\n> wrote:\n>         The last time we looked at core reviewer stats was in December\n>         [1]. In looking at the current stats, I\'m going to propose\n>         some changes to the core team. Reviews are the most important\n>         part of being a core reviewer, so we need to ensure cores are\n>         doing reviews. The stats for the 90 day period [2] indicate\n>         some changes are needed for core reviewers who are no longer\n>         reviewing on pace with the other core reviewers.\n>         \n>         \n>         First of all, I\'m removing Sumit Naiksatam from neutron-core.\n>         Sumit has been a core reviewer for a long time, and his past\n>         contributions are very much thanked by the entire OpenStack\n>         Neutron team. If Sumit jumps back in with thoughtful reviews\n>         in the future, we can look at getting him back as a Neutron\n>         core reviewer. But for now, his stats indicate he\'s not\n>         reviewing at a level consistent with the rest of the Neutron\n>         core reviewers.\n>         \n>         \n>         As part of the change, I\'d like to propose Doug Wiegley as a\n>         new Neutron core reviewer. Doug has been actively reviewing\n>         code across not only all the Neutron projects, but also other\n>         projects such as infra. His help and work in the services\n>         split in December were the reason we were so successful in\n>         making that happen. Doug has also been instrumental in the\n>         Neutron LBaaS V2 rollout, as well as helping to merge code in\n>         the other neutron service repositories.\n>         \n>         I\'d also like to take this time to remind everyone that\n>         reviewing code is a responsibility, in Neutron the same as\n>         other projects. And core reviewers are especially beholden to\n>         this responsibility. I\'d also like to point out that +1/-1\n>         reviews are very useful, and I encourage everyone to continue\n>         reviewing code even if you are not a core reviewer.\n>         \n>         Existing neutron cores, please vote +1/-1 for the addition of\n>         Doug to the core team.\n>         \n>         \n> It\'s been a week, and Doug has received plenty of support. Welcome to\n> the Neutron Core Review team Doug!\n> \n> Kyle\n>  \n> \n>         Thanks!\n>         Kyle\n>         \n>         [1]\n>         http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html\n>         [2]\n>         http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt\n>         \n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAL3VkVzB5oAbY9Z73qPeY1v-BthLqMJnywbxd4nEuND0_=Zjmw@mail.gmail.com>',NULL),('<1421969783.4882.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-22 17:36:23',-21600,'2015-01-22 23:36:23',NULL,'[openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke\n the gate','On Wed, 2015-01-21 at 18:48 -0800, Joshua Harlow wrote:\n> Another thing that I just started whipping together:\n> \n> https://gist.github.com/harlowja/5e39ec5ca9e3f0d9a21f\n\nOne problem, though, is that parse_requirements() now requires the\nsession keyword argument.  In version 6.0.6, parse_requirements() begins\nwith:\n\n        def parse_requirements(filename, finder=None, comes_from=None, options=None,\n                               session=None):\n            if session is None:\n                raise TypeError(\n                    \"parse_requirements() missing 1 required keyword argument: \"\n                    \"\'session\'\"\n                )\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<BLU436-SMTP1058D81D2D85A8908F8D319D8490@phx.gbl>',NULL),('<1421997666.3730.41.camel@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 07:21:06',0,'2015-01-23 07:21:06',NULL,'[openstack-dev]  [neutron][lbaas] Object statuses','\nSo I am resurrecting this topic now because we put this discussion on a a brief hold,\nbut are now discussing it again and need to decide asap. We\'ve all agreed we need a\nprovisioning_status and operating_status fields. We now need to decide where to show\nthese statuses to the user.\n\nOption 1:\nShow the statuses directly on the entity.\n\nOption 2-A:\nShow a status tree only on the load balancer object, but not on any entities.\n\nOption 2-B:\nExpose a resource for a GET request that will return that status tree.\n\nExample:\nGET /lbaas/loadbalancers/{LB_UUID}/statuses\n\n\nOption 1 is probably what most people are used to but it doesn\'t allow for sharing of\nobjects, and when/if sharing is enabled, it will cause a break in contract and a new\nversion of the API.  So it would essentially disallow object sharing.  This requires\na lot less work to implement.\n\nOption 2-* can be done with or without sharing, and when/if object sharing is enabled\nit wont break contract.  This will require more work to implement.\n\nMy personal opinion is in favor of Option 2-B, but wouldn\'t argue with 2-A either.\n\nThanks,\nBrandon\n\n\n\n','<F36E8145F2571242A675F56CF609645628965468@ILMB1.corp.radware.com>',NULL),('<1422026838.895299.217925105.6BE7683D@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 10:27:18',-18000,'2015-01-23 15:27:18',NULL,'[openstack-dev] [oslo] [nova] [all] potential enginefacade\n adjustment - can everyone live with this?','\n\nOn Thu, Jan 22, 2015, at 10:36 AM, Mike Bayer wrote:\n> Hey all -\n> \n> Concerning the enginefacade system, approved blueprint:\n> \n> https://review.openstack.org/#/c/125181/\n> \n> which will replace the use of oslo_db.sqlalchemy.EngineFacade ultimately\n> across all projects that use it (which is, all of them that use a\n> database).\n> \n> We are struggling to find a solution for the issue of application-defined\n> contexts that might do things that the facade needs to know about, namely\n> 1. that the object might be copied using deepcopy() or 2. that the object\n> might be sent into a new set of worker threads, where its attributes are\n> accessed concurrently.\n> \n> While the above blueprint and the implementations so far have assumed\n> that we need to receive this context object and use simple assignment,\n> e.g. ?context.session = the_session? in order to provide its attributes,\n> in order to accommodate 1. and 2. I?ve had to add a significant amount of\n> complexity in order to accommodate those needs (see patch set 28 at\n> https://review.openstack.org/#/c/138215/).   It all works fine, but\n> predictably, people are not comfortable with the extra few yards into the\n> weeds it has to go to make all that happen.  In particular, in order to\n> accommodate a RequestContext that is running in a different thread, it\n> has to be copied first, because we have no ability to make the ?.session?\n> or ?.connection? attributes dynamic without access to the RequestContext\n> class up front.\n> \n> So, what?s the alternative.   It?s that enginefacade is given just a tiny\n> bit of visibility into the *class* used to create your context, such as\n> in Nova, the nova.context.RequestContext class, so that we can place\n> dynamic descriptors on it before instantiation (or I suppose we could\n> monkeypatch the class on the first RequestContext object we see, but that\n> seems even less desirable).   The blueprint went out of its way to avoid\n> this.   But with contexts being copied and thrown into threads, I didn?t\n> consider these use cases and I?d have probably needed to do the BP\n> differently.\n> \n> So what does the change look like?    If you?re not Nova, imagine you?re\n> cinder.context.RequestContext, heat.common.context.RequestContext,\n> glance.context.RequestContext, etc.    We throw a class decorator onto\n> the class so that enginefacade can add some descriptors:\n> \n> diff --git a/nova/context.py b/nova/context.py\n> index e78636c..205f926 100644\n> --- a/nova/context.py\n> +++ b/nova/context.py\n> @@ -22,6 +22,7 @@ import copy\n> from keystoneclient import auth\n> from keystoneclient import service_catalog\n> from oslo.utils import timeutils\n> +from oslo_db.sqlalchemy import enginefacade\n> import six\n> \n> from nova import exception\n> @@ -61,6 +62,7 @@ class _ContextAuthPlugin(auth.BaseAuthPlugin):\n>                                             region_name=region_name)\n> \n> \n> + at enginefacade.transaction_context_provider\n> class RequestContext(object):\n>     \"\"\"Security context and request information.\n> \n> \n> the implementation of this one can be seen here:\n> https://review.openstack.org/#/c/149289/.   In particular we can see all\n> the lines of code removed from oslo?s approach, and in fact there?s a lot\n> more nasties I can take out once I get to work on that some more.\n> \n> so what?s controversial about this?   It?s that there?s an\n> ?oslo_db.sqlalchemy? import up front in the XYZ/context.py module of\n> every participating project, outside of where anything else ?sqlalchemy?\n> happens.  \n> \n> There?s potentially other ways to do this - subclasses of RequestContext\n> that are generated by abstract factories, for one.   As I left my Java\n> gigs years ago I?m hesitant to go there either :).   Perhaps projects can\n> opt to run their RequestContext class through this decorator\n> conditionally, wherever it is that it gets decided they are about to use\n> their db/sqlalchemy/api.py module.\n> \n> So can I please get +1 / -1 from the list on, ?oslo_db.sqlalchemy wants\n> an up-front patch on everyone?s RequestContext class?  ?  thanks!\n\nWe put the new base class for RequestContext in its own library because\nboth the logging and messaging code wanted to influence it\'s API. Would\nit make sense to do this database setup there, too?\n\nDoug\n\n> \n> - mike\n> \n> \n> \n> \n> \n> \n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<B053231D-5C6C-4E3D-A9D2-AE6D147105EE@redhat.com>',NULL),('<1422036097.1512919.217993045.62AF52B7@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 13:01:37',-18000,'2015-01-23 18:01:37',NULL,'[openstack-dev] oslo_log/oslo_config initialization','\n\nOn Wed, Jan 21, 2015, at 08:11 AM, Qiming Teng wrote:\n> On Wed, Jan 21, 2015 at 12:27:15PM +0200, Denis Makogon wrote:\n> > On Wed, Jan 21, 2015 at 12:16 PM, Qiming Teng <tengqim at linux.vnet.ibm.com>\n> > wrote:\n> > \n> > > Hi,\n> > >\n> > > In the oslo_log 0.1.0 release, the setup() function demands for a conf\n> > > parameter, but I have failed to find any hint about setting this up.\n> > >\n> > > The problem is cfg.CONF() returns None, so the following code fails:\n> > >\n> > >   conf = cfg.CONF(name=\'prog\', project=\'project\')\n> > >   # conf is always None here, so the following call fails\n> > >   log.setup(conf, \'project\')\n> > >\n> > > Another attempt also failed, because it cannot find any options:\n> > >\n> > >   log.setup(cfg.CONF, \'project\')\n> > >\n> > > Any hint or sample code to setup logging if I\'m abandoning the log\n> > > module from oslo.incubator?\n> > >\n> > >\n> > You might take a look at\n> > https://github.com/openstack/oslo.log/blob/master/oslo_log/_options.py\n> > Those options are what oslo_log expects to find in service configuration\n> > files.\n> \n> Okay, my guess is that both oslo_config and oslo_log are trying to\n> register_cli_options. I have to create a configuration object for\n> oslo_log to work, and it means CLI options are registered once.\n> Later on, when I\'m calling log.register_options(), it is conflicting\n> with previous registration.\n> \n> So, I\'m doubting whether these two packages have been tested together?\n\nThe problem is the order of the calls. As described in\nhttp://docs.openstack.org/developer/oslo.log/usage.html#in-an-application\nyou need to call log.register_options() before parsing the command line\noptions, so before you call cfg.CONF().\n\nDoug\n\n> \n> Regards,\n>   Qiming\n> \n> > > Regards,\n> > >   Qiming\n> > >\n> > >\n> > > __________________________________________________________________________\n> > > OpenStack Development Mailing List (not for usage questions)\n> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > \n> > \n> > Kind regards,\n> > Denis M.\n> \n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20150121131059.GA22090@localhost>',NULL),('<1422036431.1514491.217995533.700B31B9@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 13:07:11',-18000,'2015-01-23 18:07:11',NULL,'[openstack-dev] [oslo] [nova] [all] potential enginefacade\n adjustment - can everyone live with this?','\n\nOn Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:\n> \n> \n> Mike Bayer <mbayer at redhat.com> wrote:\n> \n> > \n> > \n> > Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n> > \n> >> On 01/23/2015 05:38 PM, Mike Bayer wrote:\n> >>> Doug Hellmann <doug at doughellmann.com> wrote:\n> >>> \n> >>>> We put the new base class for RequestContext in its own library because\n> >>>> both the logging and messaging code wanted to influence it\'s API. Would\n> >>>> it make sense to do this database setup there, too?\n> >>> whoa, where?s that? is this an oslo-wide RequestContext class ? that would\n> >>> solve everything b.c. right now every project seems to implement\n> >>> RequestContext themselves.\n> \n> \n> so Doug -\n> \n> How does this ?influence of API? occur, would oslo.db import\n> oslo_context.context and patch onto RequestContext at that point? Or the\n> other way around? Or? ?\n\nNo, it\'s a social thing. I didn\'t want dependencies between\noslo.messaging and oslo.log, but the API of the context needs to support\nuse cases in both places.\n\nYour case might be different, in that we might need to actually have\noslo.context depend on oslo.db in order to call some setup code. We\'ll\nhave to think about whether that makes sense and what other dependencies\nit might introduce between the existing users of oslo.context.\n\nDoug\n\n> \n> \n> I?m almost joyful that this is here.   Assuming we can get everyone to\n> use it, should be straightforward for that right?\n> \n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<03B28A0E-1E87-4C9A-9A55-EEA9C8C91C08@redhat.com>',NULL),('<1422061275.1606557.218126097.7790A061@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-23 20:01:15',-18000,'2015-01-24 01:01:15',NULL,'[openstack-dev] [oslo] Why are we continuing to add new\n namespaced oslo libs?','\n\nOn Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:\n> Hi,\n> \n> I\'ve just noticed that oslo.log made it to global-requirements.txt 9\n> days ago. How come are we still adding some name.spaced oslo libs?\n> Wasn\'t the outcome of the discussion in Paris that we shouldn\'t do that\n> anymore, and that we should be using oslo-log instead of oslo.log?\n> \n> Is three something that I am missing here?\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n\nThe naming is described in the spec:\nhttp://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html\n\ntl;dr - We did it this way to make life easier for the packagers.\n\nDoug\n\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54C2EBE0.7010308@debian.org>',NULL),('<1422062084.3395.20.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-23 17:14:44',-28800,'2015-01-24 01:14:44',NULL,'[openstack-community] OpenStack Community Weekly Newsletter (Jan 16\n	- 23)','The Whys and Hows of the Oslo Namespace Change\nDuring the Kilo cycle the Oslo team has been busy deprecating the oslo.\nnamespace in all of our projects. The first question this probably\nraises for most people is: why? Ben Nemec has the answer in his blog\npost and also explains how the Common Libraries team has fixed the\nissue.\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9\n      * Accepting applications for OpenStack Travel Support Program\n\nRelevant Conversations\n\n      * Will the Big Tent ?break? OpenStack?\n      * OpenStack Product Management Kilo Midcycle Topics Finalized\n      * The OpenStack Elections - Another Look\n      * The OpenStack Foundation lumbers toward a stronger IP policy\n      * EC2 API standalone service \n      * Vancouver Design Summit format changes \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n      * Infrastructure Puppet module split sprint, Jan 28 \n\nReports From Previous Events\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Linux Conf Australia 2015\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002.1] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme (CVE-2015-1195) ERRATA 1 \n\nTips ?n Tricks\n\n      * By Alessandro Pilotti: SaltStack states for OpenStack\n      * By S?bastien Han: OpenStack Cinder with Ceph under the hood\n      * By James Page: Extreme OpenStack: Scale testing OpenStack\n        Messaging\n      * By Jason Baker: Building a successful OpenStack group\n      * By S?bastien Han: OpenStack: disable a compute node during its\n        first bootstrap\n      * By Shaifali Agrawal: Two Merge so far?\n      * By Lars Kellogg-Stedman: Running nova-libvirt and nova-docker on\n        the same host\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 26 - 27, 2015 Product Management Group Meeting Palo Alto,\n        CA, US\n      * Jan 26, 2015 OpenStack Production-Grade Doha, QA\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Group Based Policy - Announcing Release \n      * Call for Testing: Ubuntu OpenStack Kilo-1 development milestone\n      * Neutron versus Chaos Monkey: Is Neutron Reliable At Scale?\n      * Announcing git-deps: commit dependency analysis / visualization\n        tool\n      * gabbi: A tool for declarative testing of APIs \n      * What\'s Up Doc? Jan 23 2015 [heat] [cinder] \n      * Announcing Magnum\'s First Release \n      * OpenStack Crossproject Meeting: (skipped).\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Migrate VMs from oVirt to OpenStack\n      * Why openvswitch logs appear in a different timezone?\n      * openstack_dashboard wsgi gives \"m2crypto.so: wrong ELF class:\n        ELFCLASS32\" error\n      * Red Hat Enterprise Linux OpenStack Platform 5 reference\n        architecture or tutorial for HA installation\n      * mirroring traffic between vm\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150123/2af22dab/attachment.html>\n\n',NULL,NULL),('<1422062084.3395.20.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2015-01-23 17:14:44',-28800,'2015-01-24 01:14:44',NULL,'[openstack-announce] OpenStack Community Weekly Newsletter (Jan 16\n	- 23)','The Whys and Hows of the Oslo Namespace Change\nDuring the Kilo cycle the Oslo team has been busy deprecating the oslo.\nnamespace in all of our projects. The first question this probably\nraises for most people is: why? Ben Nemec has the answer in his blog\npost and also explains how the Common Libraries team has fixed the\nissue.\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9\n      * Accepting applications for OpenStack Travel Support Program\n\nRelevant Conversations\n\n      * Will the Big Tent ?break? OpenStack?\n      * OpenStack Product Management Kilo Midcycle Topics Finalized\n      * The OpenStack Elections - Another Look\n      * The OpenStack Foundation lumbers toward a stronger IP policy\n      * EC2 API standalone service \n      * Vancouver Design Summit format changes \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n      * Infrastructure Puppet module split sprint, Jan 28 \n\nReports From Previous Events\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Linux Conf Australia 2015\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002.1] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme (CVE-2015-1195) ERRATA 1 \n\nTips ?n Tricks\n\n      * By Alessandro Pilotti: SaltStack states for OpenStack\n      * By S?bastien Han: OpenStack Cinder with Ceph under the hood\n      * By James Page: Extreme OpenStack: Scale testing OpenStack\n        Messaging\n      * By Jason Baker: Building a successful OpenStack group\n      * By S?bastien Han: OpenStack: disable a compute node during its\n        first bootstrap\n      * By Shaifali Agrawal: Two Merge so far?\n      * By Lars Kellogg-Stedman: Running nova-libvirt and nova-docker on\n        the same host\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 26 - 27, 2015 Product Management Group Meeting Palo Alto,\n        CA, US\n      * Jan 26, 2015 OpenStack Production-Grade Doha, QA\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Group Based Policy - Announcing Release \n      * Call for Testing: Ubuntu OpenStack Kilo-1 development milestone\n      * Neutron versus Chaos Monkey: Is Neutron Reliable At Scale?\n      * Announcing git-deps: commit dependency analysis / visualization\n        tool\n      * gabbi: A tool for declarative testing of APIs \n      * What\'s Up Doc? Jan 23 2015 [heat] [cinder] \n      * Announcing Magnum\'s First Release \n      * OpenStack Crossproject Meeting: (skipped).\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Migrate VMs from oVirt to OpenStack\n      * Why openvswitch logs appear in a different timezone?\n      * openstack_dashboard wsgi gives \"m2crypto.so: wrong ELF class:\n        ELFCLASS32\" error\n      * Red Hat Enterprise Linux OpenStack Platform 5 reference\n        architecture or tutorial for HA installation\n      * mirroring traffic between vm\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20150123/2af22dab/attachment.html>\n\n',NULL,NULL),('<1422062084.3395.20.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-23 17:14:44',-28800,'2015-01-24 01:14:44',NULL,'[Openstack-operators] OpenStack Community Weekly Newsletter (Jan 16\n	- 23)','The Whys and Hows of the Oslo Namespace Change\nDuring the Kilo cycle the Oslo team has been busy deprecating the oslo.\nnamespace in all of our projects. The first question this probably\nraises for most people is: why? Ben Nemec has the answer in his blog\npost and also explains how the Common Libraries team has fixed the\nissue.\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9\n      * Accepting applications for OpenStack Travel Support Program\n\nRelevant Conversations\n\n      * Will the Big Tent ?break? OpenStack?\n      * OpenStack Product Management Kilo Midcycle Topics Finalized\n      * The OpenStack Elections - Another Look\n      * The OpenStack Foundation lumbers toward a stronger IP policy\n      * EC2 API standalone service \n      * Vancouver Design Summit format changes \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * Etherpad for the Nova midcycle meetup \n      * Etherpad for the Keystone midcycle meetup \n      * Etherpad for the Cinder midcycle meetup \n      * [neutron] BPs in Launchpad for Kilo-2 \n      * [Ironic] Bay Area Midcycle \n      * [barbican] Kilo Mid-Cycle Sprint\n      * Infrastructure Puppet module split sprint, Jan 28 \n\nReports From Previous Events\n\n      * OpenStack Bootstrapping Hour - oslo.messaging anti-patterns -\n        Friday Jan 16th 17:00 UTC \n      * Linux Conf Australia 2015\n\nSecurity Advisories and Notices\n\n      * [OSSA 2015-002.1] Glance v2 API unrestricted path traversal\n        through filesystem:// scheme (CVE-2015-1195) ERRATA 1 \n\nTips ?n Tricks\n\n      * By Alessandro Pilotti: SaltStack states for OpenStack\n      * By S?bastien Han: OpenStack Cinder with Ceph under the hood\n      * By James Page: Extreme OpenStack: Scale testing OpenStack\n        Messaging\n      * By Jason Baker: Building a successful OpenStack group\n      * By S?bastien Han: OpenStack: disable a compute node during its\n        first bootstrap\n      * By Shaifali Agrawal: Two Merge so far?\n      * By Lars Kellogg-Stedman: Running nova-libvirt and nova-docker on\n        the same host\n\nUpcoming Events\n\n2015 OpenStack Foundation Events Plan and Calls for Papers Available.\nThe 2015 events plan is now available on the Global Events Calendar\nwiki. The detailed spreadsheet covers industry events, Summits (dates\nand locations), as well as regional OpenStack Days organized by the\ncommunity.  If you?re interested in sponsoring or speaking at a planned\nOpenStack Day, please contact the contact listed in the spreadsheet.\n\n\n      * Jan 26 - 27, 2015 Product Management Group Meeting Palo Alto,\n        CA, US\n      * Jan 26, 2015 OpenStack Production-Grade Doha, QA\n      * Jan 27 - 29, 2015 Cinder Kilo Midcycle Meetup Austin, Texas, US\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Group Based Policy - Announcing Release \n      * Call for Testing: Ubuntu OpenStack Kilo-1 development milestone\n      * Neutron versus Chaos Monkey: Is Neutron Reliable At Scale?\n      * Announcing git-deps: commit dependency analysis / visualization\n        tool\n      * gabbi: A tool for declarative testing of APIs \n      * What\'s Up Doc? Jan 23 2015 [heat] [cinder] \n      * Announcing Magnum\'s First Release \n      * OpenStack Crossproject Meeting: (skipped).\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * Migrate VMs from oVirt to OpenStack\n      * Why openvswitch logs appear in a different timezone?\n      * openstack_dashboard wsgi gives \"m2crypto.so: wrong ELF class:\n        ELFCLASS32\" error\n      * Red Hat Enterprise Linux OpenStack Platform 5 reference\n        architecture or tutorial for HA installation\n      * mirroring traffic between vm\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150123/2af22dab/attachment.html>\n\n',NULL,NULL),('<1422199463.22896686.1384370105573.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 14:15:05',-18000,'2013-11-13 19:15:05',NULL,'[openstack-dev] [Solum] Some initial code copying for\n db/migration','\n\n----- Original Message -----\n> +1 for ease of iteration till we decide on the model\n> (and so not worry about remotability right now :)).\n> \n> Just to verify that I understand the proposed strawman commit,\n> it will use nova/object/* like hierarchy to define Solum specific domain\n> objects\n> in which specific methods would be exposed whose implementation will use\n> sqlalchemy ORM calls internally.\n\nYeah, base abstract class / interface / field definitions, with a subclass implementation that is accessed via a factory/lookup table.  I had started on that track but wanted to get the remotability feedback early (I don\'t like mucking around with the sqlalchemy metaclasses early on unless it\'s something we view as critical).  The remotable path would separate the orm model and then do the same translation that happens today in nova/ironic with _from_db_object where we create two objects, then copy them back and forth a bunch.  The first implementation could be converted to the second, I don\'t see the second being something we\'d convert to the first since it\'s more work.  I\'ve also included examples of live schema update with the three states (old schema, new schema but write-only, new schema and no access to the old schema) for various types of changes (rename, split columns, add subtable relationship).\n\nI could do both to compare but figured we could argue out remotability via ML.\n\n> \n> Sounds good to me.\n> \n> As long as we are able to discuss and debate the perceived advantages of the\n> object approach\n> (that it makes handling versioned data easier, and that it allows using sql\n> and non-sql\n>  backends) we should be good.\n> \n> Btw, thanks for sending across link to the F1 paper.\n> \n> Regards,\n> - Devdatta\n> \n> \n> -----Original Message-----\n> From: \"Clayton Coleman\" <ccoleman at redhat.com>\n> Sent: Wednesday, November 13, 2013 12:29pm\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Cc: \"devdatta kulkarni\" <devdatta.kulkarni at rackspace.com>\n> Subject: Re: [openstack-dev] [Solum] Some initial code copying for\n> db/migration\n> \n> ----- Original Message -----\n> > \n> > The abstraction will probably always leak something, but in general it\n> > comes\n> > down to isolating a full transaction behind a coarse method.  Was going to\n> > try to demonstrate that as I went.\n> > \n> \n> I\'ve almost got something ready for feedback and review - before I do that I\n> wanted to follow up with remotability and it\'s relative importance:\n> \n> Is remotability of DB interactions a prime requirement for all OpenStack\n> services? Judging by what I\'ve seen so far, it\'s primarily to ensure that DB\n> passwords are isolated from the API code, with a tiny amount of being able\n> to scale business logic independently.  Are there other reasons?\n> \n> For DB password separation, it\'s never been a huge concern to us\n> operationally - do others have strong enough opinions either way to say that\n> it continues to be important vs. not?\n> \n> For the separated scale behavior, at the control plane scale outs we suspect\n> we\'ll have (2-20?), does separating the api and a background layer provide\n> benefit?\n>    \n> The other items that have been mentioned that loosely couple with\n> remotability are versioned upgrades, but we can solve those in a combined\n> layer as well with an appropriately chosen API abstraction.\n> \n> If remotability of DB calls is not a short term or medium term objective,\n> then I was going to put together a strawman commit that binds domain object\n> implementation subclasses that are tied to sqlalchemy ORM, but with the\n> granular create/save/update calls called out and enforced.  If it is a\n> short/medium objective, we\'d use the object field list to copy from the ORM,\n> with the duplicate object creation that it entails.  The former is easier to\n> iterate on as we develop to decide on the model, the latter is easier to\n> make remoteable (can\'t have the SQL orm state inside the object that is\n> being serialized easily).  There\'s an argument the latter enforces stronger\n> code guarantees as well (there\'s no way for people to use tricky orm magic\n> methods added to the object, although that\'s a bit less of an issue with\n> sqlalchemy than other models).\n> \n> Thoughts?\n> \n> \n> \n\n\n','<1384368517.145828871@apps.rackspace.com>',NULL),('<1422243295.1870201.218708249.4C68995B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-25 19:34:55',-28800,'2015-01-26 03:34:55',NULL,'[OpenStack-Infra] (no subject)','On Fri, Jan 23, 2015, at 07:04 AM, sheepdog ci wrote:\n> ssh-rsa\n> AAAAB3NzaC1yc2EAAAADAQABAAABAQDePPatJEcXKxS+75zW7vuXc+P1bmR8hzbrNqirQKtpSOEwYOAzxaeZonDTdFyvj4tww3JjvTMt+HYuG5Yhz2DlEj377KokVy8JQetCYwrSFQ7g8Yi8zUHm+KFSCrpd6XAJWSoEh4sWdyPXpjLb0cr5ccK2ryTB3H/wyQ2RbZgA/seumS3FU4X2XMiVpNcwtjfmBT/Gmv88/1E8UULwZzB5e8gxDUF6w/5dnVOP1zl8akic3MBwLf29WHSJvBpv+AiIsceTsJfvww50EXVeAqbr73ubPEmsO1xIGFSgZVNFo/U4ADU9OBaNOWA1PLkUscIjY7pIUXSqs/CupXQK1fWn\n> root at openstack-sheepdog-ci\n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nIs this a request to update the ssh public key for the sheepdog-ci third\nparty testing account? If so we are pushing for third party testers to\nuse the new self service account process to create a new account that\nthey can manage themselves whenever requests for updates that require\nGerrit admins come in.\n\nThe process to create a self managed account can be found at\nhttp://ci.openstack.org/third_party.html#creating-a-service-account.\n\nIf this was not the purpose of the email please do let us know what the\nintent was and we shall do our best to help.\n\nThank you,\nClark\n\n\n','<CAJNfhd9ACfqT2RgAkBHkHV5K5vA60Mriup=W+NvbFc2p_yHMOA@mail.gmail.com>',NULL),('<1422266308.4603.19.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 10:58:28',3600,'2015-01-26 09:58:28',NULL,'[openstack-dev] [neutron] [rhel7] minimal dnsmasq version','Hi Ihar, \nwe\'re currently running stable/juno devstack on rhel7 base. But I see\ntroubles to get it running on the master branch due to bug  1408297.\n\nThe fix for this bug increases the minimal dnsmasq version for master\nbranch up to 2.67. I also recognized the stable/juno item that leaves a\nwarning if this version level is not reached - that\'s why it is working\nfine for us so far.\n\nYou mentioned in the following thread\n\nhttp://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html\n\n, that redhat plans to backport the mac-ip matching feature to version\n2.66. \n\nAre you planning any additional Neutron code changes to also allow the\nversion 2.66 or an older one of dnsmasq or may this new version for rhel\ncome with the kilo rdo release? At least for IPv4 Use cases the 2.67\nversion is not required....\n\nThe only workaround I could imagine so far is to install a fedora\npackage.\n\nThanks!\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\n\n\n\n',NULL,NULL),('<1422284001.4603.21.camel@oc5515017671.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 15:53:21',3600,'2015-01-26 14:53:21',NULL,'[openstack-dev] [neutron] [rhel7] minimal dnsmasq version','Thanks Ihar for sharing your thoughts!\n\n\n-- \nAndreas \n(irc: scheuran)\n\n\nOn Mon, 2015-01-26 at 11:30 +0100, Ihar Hrachyshka wrote:\n> Hi Andreas,\n> \n> On 01/26/2015 10:58 AM, Andreas Scheuring wrote:\n> > Hi Ihar,\n> > we\'re currently running stable/juno devstack on rhel7 base. But I see\n> > troubles to get it running on the master branch due to bug  1408297.\n> >\n> > The fix for this bug increases the minimal dnsmasq version for master\n> > branch up to 2.67. I also recognized the stable/juno item that leaves a\n> > warning if this version level is not reached - that\'s why it is working\n> > fine for us so far.\n> >\n> > You mentioned in the following thread\n> >\n> > http://lists.openstack.org/pipermail/openstack-dev/2015-January/053980.html\n> >\n> > , that redhat plans to backport the mac-ip matching feature to version\n> > 2.66.\n> \n> Not exactly. I only said that for some conservative distributions that \n> strictly control any version bumps, simple bump of dnsmasq to 2.67 may \n> be not an option, and hence they may consider backporting the feature \n> they miss as an alternative. I haven\'t mentioned which route Red Hat \n> will go though.\n> \n> You may be interested in tracking the following Red Hat bug to see how \n> it goes:\n> https://bugzilla.redhat.com/show_bug.cgi?id=1179756\n> \n> >\n> > Are you planning any additional Neutron code changes to also allow the\n> > version 2.66 or an older one of dnsmasq or may this new version for rhel\n> > come with the kilo rdo release? At least for IPv4 Use cases the 2.67\n> > version is not required....\n> \n> Yes, I have a patch in review to move the version check from DHCP agent \n> to sanity_check tool [1]. I will update it today since it seems the \n> issue gets a lot of traction and attention recently (f.e. see [2]).\n> \n> Note that at the moment, there is no RDO Kilo release yet. Though you \n> may find some packages for Kilo in Delorean (RDO based on master) [3].\n> \n> We hope that EL7 will receive an update for dnsmasq to allow it to serve \n> IPv6 stateful subnets in the near future, as far as I know teams are \n> actively working on delivering it. Once we get the update, we\'ll be ok \n> to disable the warning in Juno [4] (in Red Hat repos, not upstream).\n> \n> [1]: https://review.openstack.org/148577\n> [2]: https://bugs.launchpad.net/bugs/1413042\n> [3]: http://209.132.178.33/repos/report.html\n> [4]: \n> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/dhcp.py?h=stable/juno#n334\n> \n> >\n> > The only workaround I could imagine so far is to install a fedora\n> > package.\n> \n> Yes, that\'s a way to go for now. Sorry for any inconvenience due to that.\n> \n> >\n> > Thanks!\n> >\n> >\n> \n\n\n\n','<54C6172A.6090806@redhat.com>',NULL),('<1422284689.3712508.219007817.405B2E71@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 10:04:49',-18000,'2015-01-26 15:04:49',NULL,'[openstack-dev] [oslo] [nova] [all] potential enginefacade\n adjustment - can everyone live with this?','\n\nOn Mon, Jan 26, 2015, at 08:55 AM, Matthew Booth wrote:\n> On 23/01/15 19:47, Mike Bayer wrote:\n> > \n> > \n> > Doug Hellmann <doug at doughellmann.com> wrote:\n> > \n> >>\n> >>\n> >> On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote:\n> >>> Mike Bayer <mbayer at redhat.com> wrote:\n> >>>\n> >>>> Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n> >>>>\n> >>>>> On 01/23/2015 05:38 PM, Mike Bayer wrote:\n> >>>>>> Doug Hellmann <doug at doughellmann.com> wrote:\n> >>>>>>\n> >>>>>>> We put the new base class for RequestContext in its own library because\n> >>>>>>> both the logging and messaging code wanted to influence it\'s API. Would\n> >>>>>>> it make sense to do this database setup there, too?\n> >>>>>> whoa, where?s that? is this an oslo-wide RequestContext class ? that would\n> >>>>>> solve everything b.c. right now every project seems to implement\n> >>>>>> RequestContext themselves.\n> >>>\n> >>>\n> >>> so Doug -\n> >>>\n> >>> How does this ?influence of API? occur, would oslo.db import\n> >>> oslo_context.context and patch onto RequestContext at that point? Or the\n> >>> other way around? Or? ?\n> >>\n> >> No, it\'s a social thing. I didn\'t want dependencies between\n> >> oslo.messaging and oslo.log, but the API of the context needs to support\n> >> use cases in both places.\n> >>\n> >> Your case might be different, in that we might need to actually have\n> >> oslo.context depend on oslo.db in order to call some setup code. We\'ll\n> >> have to think about whether that makes sense and what other dependencies\n> >> it might introduce between the existing users of oslo.context.\n> > \n> > hey Doug -\n> > \n> > for the moment, I have oslo_db.sqlalchemy.enginefacade applying its descriptors at import time onto oslo_context:\n\nOK. I\'ll have to think about that. We\'ve been trying to move away from\nimport-time side-effects elsewhere (especially with configuration\noptions) so we may want to think about doing the decoration at runtime,\neither through a hook discovered by oslo.context or by placing the call\nright in oslo.context. Let\'s talk about options this week.\n\n> > \n> > https://review.openstack.org/#/c/138215/30/oslo_db/sqlalchemy/enginefacade.py\n> > \n> > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l692\n> > \n> > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l498\n> \n> May I suggest that we decouple these changes by doing both? Oslo\'s\n> RequestContext object can have the enginefacade decorator applied to it,\n> so any project which uses it doesn\'t have to apply it themselves.\n> Meanwhile, the decorator remains part of the public api for projects not\n> using the oslo RequestContext.\n\nWe can leave the function in the public API, but oslo.log assumes the\napplication is using a context class subclassed from the base class\nprovided in oslo.context. As we evolve that integration, we\'ll make\nappropriate changes to the base class so they will usually be\ntransparent to the application code, so it\'s going to be safer to just\nuse the base class we provide.\n\nDoug\n\n> \n> I suggest that we\'ll probably stay with a decorator within oslo, anyway.\n> It doesn\'t lend itself well to a Mixin, as we need a reference to a\n> specific _TransactionContextManager, and moving code directly into\n> RequestContext would be a very invasive coupling.\n> \n> Matt\n> -- \n> Matthew Booth\n> Red Hat Engineering, Virtualisation Team\n> \n> Phone: +442070094448 (UK)\n> GPG ID:  D33C3490\n> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54C6475C.2020106@redhat.com>',NULL),('<1422286381156.70378@kemptechnologies.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 15:32:05',0,'2015-01-26 15:32:05',NULL,'[openstack-dev]  [neutron] lbaas driver implementation question','Hi all,\n\nImplementing a driver for lbaas and am running into some trouble.\n\nThe load balancer is a VM hosted on the compute node within devstack and the driver can create vips, pools and members no problem.\n\nThe problem lies when trying to access the service hosted by the VIP.\n\n>From TCP dumps on the load balancer instance we can see that the traffic hits the load balancer and the load balancer replies but the reply does not reach the client.\n\nIs there an implementation reason why this might occur (i.e. not creating a port or doing some neutron configuration within the driver) or could there be another issue at play here.\n\nWe are using stable/juno devstack for test purposes. We can access the load balancer GUI no problem via the browser its just anything hosted by the LB services is inaccessible.\n\nAny help would be appreciated\n\nThanks,\nShane.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150126/fc0b1975/attachment.html>\n\n',NULL,NULL),('<1422295917.3798857.219091445.38285B71@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 13:11:57',-18000,'2015-01-26 18:11:57',NULL,'[openstack-dev] [tc] do we really need project tags in the\n governance repository?','\n\nOn Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:\n> Doug Hellmann wrote:\n> > [...]\n> > So, my proposal is that we re-evaluate our decision to introduce a tagging system and complicated taxonomy to the *governance* repository, and think about whether the same information can either be found elsewhere already or *should live elsewhere* and needs to be developed there. We can keep the integrated release tag that we have in place now, but we should not adopt any other tags and we should phase out the tag system when we drop the integrated release tag.\n> \n> I agree that tag application/removal could be more distributed. The\n> original draft for the spec explicitly proposed that the TC delegates\n> (some) tag application to other groups, but in those discussions you\n> were the one resisting the idea and requiring that the TC retained clear\n> oversight :)\n\nThe TC should be responsible for evaluating teams and projects that want\nto join OpenStack. If we use tags for that purpose, then we should vote\non them. We don\'t seem to be using tags for that purpose, though (at\nleast not after we drop the incubated release tag).\n\n> I\'m open to alternative suggestions on where the list of tags, their\n> definition and the list projects they apply to should live. If you don\'t\n> like that being in the governance repository, what would have your\n> preference ?\n\n>From the very beginning I have taken the position that tags are by\nthemselves not sufficiently useful for evaluating projects. If someone\nwants to choose between Ceilometer, Monasca, or StackTach, we\'re\nunlikely to come up with tags that will let them do that. They need\nin-depth discussions of deployment options, performance characteristics,\nand feature trade-offs.\n\n> That said, I object to only saying \"this is all information that can be\n> found elsewhere or should live elsewhere\", because that is just keeping\n> the current situation -- where that information exists somewhere but\n> can\'t be efficiently found by our downstream consumers. We need a\n> taxonomy and clear definitions for tags, so that our users can easily\n> find, understand and navigate such project metadata.\n\nAs someone new to the project, I would not think to look in the\ngovernance documents for \"state\" information about a project. I would\nsearch for things like \"install guide openstack\" or \"component list\nopenstack\" and expect to find them in the documentation. So I think\nputting the information in those (or similar) places will actually make\nit easier to find for someone that hasn\'t been involved in the\ndiscussion of tags and the governance repository.\n\nIf we need a component list with descriptions, let\'s build that. It can\nbe managed by a team of interested parties -- perhaps some of the\noperators or deployers, for example. I don\'t know if we have an existing\nplace where it would make sense to put it, or if we need a new\nrepository. We\'ve been applying DRY to the existing projects/programs\nlist and saying that because we already have a list in the governance\nrepository we shouldn\'t repeat that information elsewhere, but we\'re\nalso starting to go to a lot of lengths to define a format to hold\ninformation (tags, with metadata, a taxonomy, etc.) that isn\'t needed\nfor project governance. That makes me think we\'re trying to force-fit\nthis idea into a single list.\n\n> The tagging proposal (only one-month old) has so far received a pretty\n> good reception from operators and other downstream users, who see it as\n> a way to explain and contribute what type of information matters to\n> them. The Technical Committee members are not the only people who can\n> propose tags.\n\nI agree that a product matrix with some basic information will be useful\nfor deployers and operators to find project details, which can then go\ninto more depth about the issues operators and other downstream users\ncare about. I just don\'t think the TC needs to host or maintain that\nmatrix itself.\n\nWhen we talk about things going into the governance repository, we\nshould apply two rules. First, we should consider whether it is\n*appropriate* for the TC to be making decisions about the topic.\nSubjective tags fail this test. Second, we should consider whether it is\n*necessary* for the TC to be making the decision. Objective tags fail\nthis test.\n\nDoug\n\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54C67332.5000101@openstack.org>',NULL),('<1422305613-sup-2580@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-26 12:56:08',-28800,'2015-01-26 20:56:08',NULL,'[openstack-dev] [tc][python-clients] More freedom for all\n	python clients','Excerpts from Robert Collins\'s message of 2015-01-26 12:29:37 -0800:\n> On 27 January 2015 at 09:01, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> >\n> >\n> > On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague <sean at dague.net> wrote:\n> >>\n> >> On 01/20/2015 08:15 PM, Robert Collins wrote:\n> >> > On 21 January 2015 at 10:21, Clark Boylan <cboylan at sapwetik.org> wrote:\n> >> > ...\n> >> >> This ml thread came up in the TC meeting today and I am responding here\n> >> >> to catch the thread up with the meeting. The soft update option is the\n> >> >> suggested fix for non openstack projects that want to have most of\n> >> >> their\n> >> >> requirements managed by global requirements.\n> >> >>\n> >> >> For the project structure reform opening things up we should consider\n> >> >> loosening the criteria to get on the list and make it primarily based\n> >> >> on\n> >> >> technical criteria such as py3k support, license compatibility,\n> >> >> upstream\n> >> >> support/activity, and so on (basically the current criteria with less\n> >> >> of\n> >> >> a focus on where the project comes from if it is otherwise healthy).\n> >> >> Then individual projects would choose the subset they need to depend\n> >> >> on.\n> >> >> This model should be viable with different domains as well if we go\n> >> >> that\n> >> >> route.\n> >> >>\n> >> >> The following is not from the TC meeting but addressing other portions\n> >> >> of this conversation:\n> >> >>\n> >> >> At least one concern with this option is that as the number of total\n> >> >> requirements goes up is the difficulty in debugging installation\n> >> >> conflicts becomes more difficult too. I have suggested that we could\n> >> >> write tools to help with this. Install bisection based on pip logs for\n> >> >> example, but these tools are still theoretical so I may be\n> >> >> overestimating their usefulness.\n> >> >>\n> >> >> To address the community scaling aspect I think you push a lot of work\n> >> >> back on deployers/users if we don\'t curate requirements for anything\n> >> >> that ends up tagged as \"production ready\" (or whatever the equivalent\n> >> >> tag becomes). Essentially we are saying \"this doesn\'t scale for us so\n> >> >> now you deal with the fallout. Have fun\", which isn\'t very friendly to\n> >> >> people consuming the software. We already have an absurd number of\n> >> >> requirements and management of them has appeared to scale. I don\'t\n> >> >> foresee my workload going up if we open up the list as suggested.\n> >> >\n> >> > Perhaps I missed something, but the initial request wasn\'t about\n> >> > random packages, it was about other stackforge clients - these are\n> >> > things in the ecosystem! I\'m glad we have technical solutions, but it\n> >> > just seems odd to me that adding them would ever have been\n> >> > controversial.\n> >>\n> >> Well, I think Clark and I have different opinions of how much of a pain\n> >> unwinding the requirements are, and how long these tend to leave the\n> >> gate broken. I am happy to also put it in a \"somebody elses problem\n> >> field\" for resolving the issues. :)\n> >>\n> >> Honestly, I think we\'re actually at a different point, where we need to\n> >> stop assuming that the sane way to deal with python is to install it\n> >> into system libraries, and just put every service in a venv and get rid\n> >> of global requirements entirely. Global requirements was a scaling fix\n> >> for getting to 10 coexisting projects. I don\'t think it actually works\n> >> well with 50 ecosystem projects. Which is why I proposed the domains\n> >> solution instead.\n> >>\n> >\n> > ++ using per service virtual environments would help us avoid a whole class\n> > of nasty issues. On the flip side doing this makes things harder for distros\n> > to find a set of non-conflicting dependencies etc.\n> >\n> >>\n> >> > On the pip solver side, joe gordon was working on a thing to install a\n> >> > fixed set of packages by bypassing the pip resolver... not sure how\n> >> > thats progressing.\n> >>\n> >> I think if we are talking seriously about bypassing the pip resolver, we\n> >> should step back and think about that fact. Because now we\'re producting\n> >> a custom installation process that will produce an answer for us, which\n> >> is completely different than any answer that anyone else is getting for\n> >> how to get a coherent system.\n> >\n> >\n> > Fully agreed, I am looking into avoiding pips dependency solver for stable\n> > branches only right now. But using per service venvs would be even better.\n> >\n>\n<moved post to bottom for us backwards folk who see the quotes in\noriginal order>\n> TripleO has done per service venvs for a couple years now, and it\n> doesn\'t solve the fragility issue that our unbounded deps cause. It\n> avoids most but not all conflicting deps within OpenStack, and none of\n> the \'upstream broke us\' cases.\n> \n\nNote that we are not testing per-service venvs anymore because of the\nextreme high cost of building the controller images with so many separate\nvenvs. We just put the openstack namespaced pieces in one big \"openstack\"\nvenv now.\n\n\n','<CAJ3HoZ2EVGK6AowDLdWhpu4Yjox3r1p3VXGvVz1uqyxfP1u8eQ@mail.gmail.com>',NULL),('<1422336855.2926925.219339185.17285DB4@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-26 21:34:15',-28800,'2015-01-27 05:34:15',NULL,'[OpenStack-Infra] Requesting to add \"devstac-plugin-glusterfs\"\n gerrit groups','On Mon, Jan 26, 2015, at 09:23 PM, Bharat Kumar wrote:\n> Hi,\n> \n> My patch [1], to create \"devstack-plugin-glusterfs\" got merged.\n> So I am requesting for add me to both \" devstack-plugin-glusterfs-core\" \n> and \" devstack-plugin-glusterfs-release\" groups in gerrit.\n> \n> Below are my gerrit details:\n> \n> Email ID: bharat.kobagana at redhat.com\n> UserName: bharatkk\n> Full Name: Bharat Kumar Kobagana\n> \n> Please let me know if you need more details.\n> \n> [1] https://review.openstack.org/#/c/146822/\n> \n> -- \n> Warm Regards,\n> Bharat Kumar Kobagana\n> Software Engineer\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\nI have added you as the initial member of these two groups.\n\nClark\n\n\n','<54C720E3.4010601@redhat.com>',NULL),('<1422339.y2QVvN38U0@dblinov.sw.ru>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-26 20:15:37',14400,'2014-03-26 16:15:37',NULL,'[Openstack] [glance] uploading new data for an existing image','On Wednesday 26 March 2014 14:27:49 Micha?l Van de Borne wrote:\n> are you talking about snapshotting the running instance?\n> \n> \n\nNo, I just want to know, is it possible, that image data will change after it \nhas been uploaded for the first time.\n\n> cheers,\n> \n> m.\n> \n> Le 26/03/14 14:16, Dmitry Guryanov a ?crit :\n> > Hello!\n> > \n> > Is it possible to update image data in Glance? For example you have\n> > created an image, used it for some time. Then you\'ve updated software in\n> > it and want to upload that new disk without creating new image in glance.\n> > \n> > --\n> > Dmitry Guryanov\n> > \n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-- \nDmitry Guryanov\n\n\n','<5332D5D5.4070601@cetic.be>',NULL),('<1422373339.3149322.219538861.6D612FA5@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-27 07:42:19',-28800,'2015-01-27 15:42:19',NULL,'[OpenStack-Infra] (no subject)','In that case the document I linked previously,\nhttp://ci.openstack.org/third_party.html#creating-a-service-account, is\nwhat you need. It should walk you through creating a service account\nthat you can manage on your own. The other portions of that page contain\nother useful info for setting up a third party CI system as well.\n\nHope this helps,\nClark\n\nOn Mon, Jan 26, 2015, at 11:36 PM, sheepdog ci wrote:\n> hi Clark,\n>     I\'m sorry about the email bother you,because I want to build a third\n> party ci system for cinder(sheepdog driver),and I find the follow post\n> that\n> maybe outdated. until now, I haven\'t complete it.\n> http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/\n> \n>    I\'m very appreciate if you can provide a detailed steps about this.\n> \n> thanks,\n> xiaolong xu\n> \n> \n> \n> \n> On Mon, Jan 26, 2015 at 11:34 AM, Clark Boylan <cboylan at sapwetik.org>\n> wrote:\n> \n> > On Fri, Jan 23, 2015, at 07:04 AM, sheepdog ci wrote:\n> > > ssh-rsa\n> > >\n> > AAAAB3NzaC1yc2EAAAADAQABAAABAQDePPatJEcXKxS+75zW7vuXc+P1bmR8hzbrNqirQKtpSOEwYOAzxaeZonDTdFyvj4tww3JjvTMt+HYuG5Yhz2DlEj377KokVy8JQetCYwrSFQ7g8Yi8zUHm+KFSCrpd6XAJWSoEh4sWdyPXpjLb0cr5ccK2ryTB3H/wyQ2RbZgA/seumS3FU4X2XMiVpNcwtjfmBT/Gmv88/1E8UULwZzB5e8gxDUF6w/5dnVOP1zl8akic3MBwLf29WHSJvBpv+AiIsceTsJfvww50EXVeAqbr73ubPEmsO1xIGFSgZVNFo/U4ADU9OBaNOWA1PLkUscIjY7pIUXSqs/CupXQK1fWn\n> > > root at openstack-sheepdog-ci\n> > > _______________________________________________\n> > > OpenStack-Infra mailing list\n> > > OpenStack-Infra at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> >\n> > Is this a request to update the ssh public key for the sheepdog-ci third\n> > party testing account? If so we are pushing for third party testers to\n> > use the new self service account process to create a new account that\n> > they can manage themselves whenever requests for updates that require\n> > Gerrit admins come in.\n> >\n> > The process to create a self managed account can be found at\n> > http://ci.openstack.org/third_party.html#creating-a-service-account.\n> >\n> > If this was not the purpose of the email please do let us know what the\n> > intent was and we shall do our best to help.\n> >\n> > Thank you,\n> > Clark\n> >\n\n\n','<CAJNfhd84S3rXRRw-UpzKsMSpNBcn09BC=vZWVhZygOZg-JDLSg@mail.gmail.com>',NULL),('<1422377719.650518.219576189.6D9C54CC@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 11:55:19',-18000,'2015-01-27 16:55:19',NULL,'[openstack-dev] [oslo][heat] potentially breaking release of\n oslo.messaging Tuesday 27th','\n\nOn Mon, Jan 26, 2015, at 06:57 PM, Angus Salkeld wrote:\n> On Tue, Jan 27, 2015 at 8:05 AM, Doug Hellmann <doug at doughellmann.com>\n> wrote:\n> \n> > We?ve held up the oslo.messaging release with the namespace package work\n> > for a while now while we work with the nova, designate, and heat teams to\n> > fix things up so their tests won?t break. We think the one remaining issue\n> > is in heat, where some tests are mocking private parts of oslo.messaging.\n> >\n> > There?s a bug filed at https://bugs.launchpad.net/heat/+bug/1412836\n> >\n> > I think asalkeld fixed similar tests in\n> > https://review.openstack.org/#/c/145094/1/heat/tests/test_stack_lock.py\n> > but missed these at the time.\n> >\n> > I would propose a fix, but I really don?t understand the test suite or\n> > what?s going on there. If someone else does propose a fix, please ping me\n> > in #openstack-oslo on IRC and I?ll test the pre-release against it to see\n> > if the issue is resolved.\n> >\n> >\n> This should sort it out: https://review.openstack.org/150185\n> \n> -Angus\n\nThanks!\n\nDoug\n\n> \n> \n> > I plan to release the new version of oslo.messaging around 15:00 UTC on 27\n> > Jan, but I will wait if there?s a fix in heat?s merge queue.\n> >\n> > Doug\n> >\n> >\n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAA16xcxm-F7+Y-4gZwBcztzMnA7xyFNriEr9MqFmvEeEoDrBcg@mail.gmail.com>',NULL),('<1422378016174.37453@wipro.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-27 17:00:18',0,'2015-01-27 17:00:18',NULL,'[Openstack] Guest to Host works but host to guest does not','Hi,\n\n I am unable to ping/ssh from my host VM to guest VM.  However opposite works just fine, that is I am able to ping from guest  to host VM. Currently I am accessing my guest from horizon console and  have tried pinging/sshing into my host VM and it works just fine. I have  also tried using network namespace to ping from host to guest but it  does not work. I am using? neutron network.\n\nI have already enabled ICMP/TCP/UDP port access using the following\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535 0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default udp 1 65535 0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default icmp -1 -1 0.0.0.0/0\n\nAny pointers would be helpful.\n\nThanks \nAshish\n\n\n\n\n',NULL,NULL),('<1422378778.658317.219579341.62CA5E7C@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 12:12:58',-18000,'2015-01-27 17:12:58',NULL,'[openstack-dev] [tc] do we really need project tags in the\n governance repository?','\n\nOn Tue, Jan 27, 2015, at 05:46 AM, Thierry Carrez wrote:\n> Doug Hellmann wrote:\n> > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:\n> > [...]\n> >> I\'m open to alternative suggestions on where the list of tags, their\n> >> definition and the list projects they apply to should live. If you don\'t\n> >> like that being in the governance repository, what would have your\n> >> preference ?\n> > \n> > From the very beginning I have taken the position that tags are by\n> > themselves not sufficiently useful for evaluating projects. If someone\n> > wants to choose between Ceilometer, Monasca, or StackTach, we\'re\n> > unlikely to come up with tags that will let them do that. They need\n> > in-depth discussions of deployment options, performance characteristics,\n> > and feature trade-offs.\n> \n> They are still useful to give people a chance to discover that those 3\n> are competing in the same space, and potentially get an idea of which\n> one (if any) is deployed on more than one public cloud, better\n> documented, or security-supported. I agree with you that an\n> (opinionated) article comparing those 3 solutions would be a nice thing\n> to have, but I\'m just saying that basic, clearly-defined reference\n> project metadata still has a lot of value, especially as we grow the\n> number of projects.\n\nRight. My main argument is that this isn\'t something for the TC to do,\nnot that it shouldn\'t be done. I\'m not convinced it\'s that useful, but I\ndon\'t have a problem if someone else does it.\n\n> \n> >> That said, I object to only saying \"this is all information that can be\n> >> found elsewhere or should live elsewhere\", because that is just keeping\n> >> the current situation -- where that information exists somewhere but\n> >> can\'t be efficiently found by our downstream consumers. We need a\n> >> taxonomy and clear definitions for tags, so that our users can easily\n> >> find, understand and navigate such project metadata.\n> > \n> > As someone new to the project, I would not think to look in the\n> > governance documents for \"state\" information about a project. I would\n> > search for things like \"install guide openstack\" or \"component list\n> > openstack\" and expect to find them in the documentation. So I think\n> > putting the information in those (or similar) places will actually make\n> > it easier to find for someone that hasn\'t been involved in the\n> > discussion of tags and the governance repository.\n> \n> The idea here is to have the reference information in some\n> Gerrit-controlled repository (currently openstack/governance, but I\'m\n> open to moving this elsewhere), and have that reference information\n> consumed by the openstack.org website when you navigate to the\n> \"Software\" section, to present a browseable/searchable list of projects\n> with project metadata. I don\'t expect anyone to read the YAML file from\n> the governance repository. On the other hand, the software section of\n> the openstack.org website is by far the most visited page of all our web\n> properties, so I expect most people to see that.\n\nRight, I didn\'t think anyone would be reading the YAML file either. I\ndidn\'t realize we were planning to publish the information anywhere\nother than the published version of the governance docs. That\'s not\nreally the crux of my argument, though.\n\n> \n> > If we need a component list with descriptions, let\'s build that. It can\n> > be managed by a team of interested parties -- perhaps some of the\n> > operators or deployers, for example. I don\'t know if we have an existing\n> > place where it would make sense to put it, or if we need a new\n> > repository.\n> > \n> > We\'ve been applying DRY to the existing projects/programs\n> > list and saying that because we already have a list in the governance\n> > repository we shouldn\'t repeat that information elsewhere, but we\'re\n> > also starting to go to a lot of lengths to define a format to hold\n> > information (tags, with metadata, a taxonomy, etc.) that isn\'t needed\n> > for project governance. That makes me think we\'re trying to force-fit\n> > this idea into a single list.\n> \n> If I understand you correctly, you\'d like to have the project teams list\n> (previously known as programs) in the governance repository, together\n> with the list of their associated code repositories. Then you would have\n> a duplicate list of code repositories, with their associated tag\n> metadata, in some other repository. I understand the limits of DRY, but\n\nNo. I don\'t think a product list needs to have a list of repositories.\nIt only needs a list of products. In some cases those map 1:1, but not\nin all cases. In any case, I would expect the Nova team to want their\nproduct called \"Nova\" and not \"openstack/nova\". For teams with more than\none product, or more than one repository creating a single product, we\nneed the product names somewhere anyway. So let\'s just make a list of\nproduct names somewhere. We can use tags or sentences or whatever to\ndescribe them. But doing that is just writing product documentation. It\nisn\'t project governance.\n\n> that duplication still sounds like a maintenance nightmare (especially\n> given how often the repository list is updated)... How do you make sure\n> that repositories in A are in B ? Some check test at the gate ?\n\nI trust that teams who have gone to the trouble of asking to be part of\nOpenStack will want their products listed and will submit the patches to\ndo it.\n\n> Alternatively we could have the project teams / code repositories\n> association live in the \"other repository\" and just duplicate the\n> project teams list, which arguably should be smaller. That means we\n> would also delegate the repository scope sanity-check to the \"other\n> repository\" maintainers, but I\'m fine with that. We could have one file\n> per project team and a check test that validates the project team exists\n> in the governance repository. The only (small) issue with that option is\n> that code repositories translate into ATCs, which translate into TC\n> voters, so this is arguably a governance thing.\n\nRight, we should keep the list of the repositories in the governance\nrepository. The product list doesn\'t need a list of the source\nrepositories.\n\n> \n> >> The tagging proposal (only one-month old) has so far received a pretty\n> >> good reception from operators and other downstream users, who see it as\n> >> a way to explain and contribute what type of information matters to\n> >> them. The Technical Committee members are not the only people who can\n> >> propose tags.\n> > \n> > I agree that a product matrix with some basic information will be useful\n> > for deployers and operators to find project details, which can then go\n> > into more depth about the issues operators and other downstream users\n> > care about. I just don\'t think the TC needs to host or maintain that\n> > matrix itself.\n> > \n> > When we talk about things going into the governance repository, we\n> > should apply two rules. First, we should consider whether it is\n> > *appropriate* for the TC to be making decisions about the topic.\n> > Subjective tags fail this test. Second, we should consider whether it is\n> > *necessary* for the TC to be making the decision. Objective tags fail\n> > this test.\n> \n> We are a bit in the openstack-specs situation. The TC is not the only\n> party involved in them (in fact, we value PTL feedback on those more\n> than we value feedback from TC members), but we use the TC to\n> sanity-check them, rubberstamp them or tally the votes on them. That\'s\n> what we currently do for the code repositories lists in programs.yaml as\n> well: when repositories are added to a program, we just sanity-check\n> that the PTL is on board with it and that the repository still matches\n> the scope of the program -- this is not a real vote and more like a\n> rubberstamp. I expect our work on project lists and tags to be mostly\n> the same. Each tag process would be delegated to a more appropriate or\n> more necessary group, the TC would just sanity-check that the rules are\n> followed before Workflow+1ing the proposed change. I think this is\n> necessary, at least until Gerrit lets us express *much* more complex\n> approval rules.\n\nI\'m concerned that we\'re building a complex process for delegating\nsomething with TC verification that doesn\'t actually need to be\nverified. If we\'re anticipating rubberstamping tags, then we should\nfully delegate them. We will still manage which projects are on the\nofficial list, which is the responsibility given to us in the bylaws,\nand I trust whoever is managing the product list document to not include\nanything that isn\'t on the official list.\n\nDoug\n\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54C76C6B.7040106@openstack.org>',NULL),('<1422378954.659395.219586085.7AAF60B1@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 12:15:54',-18000,'2015-01-27 17:15:54',NULL,'[openstack-dev] [oslo.messaging] Performance testing. Initial\n	steps.','\n\nOn Tue, Jan 27, 2015, at 10:56 AM, Denis Makogon wrote:\n> On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann <doug at doughellmann.com>\n> wrote:\n> \n> >\n> > > On Jan 15, 2015, at 1:30 PM, Denis Makogon <dmakogon at mirantis.com>\n> > wrote:\n> > >\n> > > Good day to All,\n> > >\n> > > The question that i?d like to raise here is not simple one, so i?d like\n> > to involve as much readers as i can. I?d like to speak about oslo.messaging\n> > performance testing. As community we?ve put lots of efforts in making\n> > oslo.messaging widely used drivers stable as much as possible. Stability is\n> > a good thing, but is it enough for saying ?works well?? I?d say that it?s\n> > not.\n> > > Since oslo.messaging uses driver-based messaging workflow, it makes\n> > sense to dig into each driver and collect all required/possible performance\n> > metrics.\n> > > First of all, it does make sense to figure out how to perform\n> > performance testing, first that came into my mind is to simulate high load\n> > on one of corresponding drivers. Here comes the question of how it can be\n> > accomplished withing available oslo.messaging tools - high load on any\n> > driver can perform an application that:\n> > >       ? can populate multiple emitters(rpc clients) and consumers (rpc\n> > servers).\n> > >       ? can force clients to send messages of pre-defined number of\n> > messages of any length.\n> >\n> > That makes sense.\n> >\n> > > Another thing is why do we need such thing. Profiling, performance\n> > testing can improve the way in which our drivers were implemented. It can\n> > show us actual ?bottlenecks? in messaging process, in general. In some\n> > cases it does make sense to figure out where problem takes its place -\n> > whether AMQP causes messaging problems or certain driver that speaks to\n> > AMQP fails.\n> > > Next thing that i want to discuss the architecture of\n> > profiling/performance testing. As i can see it seemed to be a ?good? way to\n> > add profiling code to each driver. If there?s any objection or better\n> > solution, please bring them to the light.\n> >\n> > What sort of extra profiling code do you anticipate needing?\n> >\n> >\n> As i can foresee (taking into account [1]) couple decorators, possibly\n> one\n> that handles metering process. The biggest part of code will take\n> highload\n> tool that\'ll be a part of messaging. But another question adding certain\n> dependecies to the project.\n> \n> \n> > > Once we?d have final design for profiling we would need to figure out\n> > tools for profiling. After searching over the web, i found pretty\n> > interesting topic related to python profiling [1]. After certain\n> > investigations it does makes sense discuss next profiling options(apply one\n> > or both):\n> > >       ? Line-by-line timing and execution frequency with a profiler\n> > (there are possible Pros and Cons, but i would say the per-line statistics\n> > is more than appreciable at initial performance testing steps)\n> > >       ? Memory/CPU consumption\n> > > Metrics. The most useful metric for us is time, any time-based metric,\n> > since it is very useful to know at which step or/and by whom delay/timeout\n> > caused, for example, so as it said, we would be able to figure out whether\n> > AMQP or driver fails to do what it was designed for.\n> > > Before proposing spec i?d like to figure out any other requirements, use\n> > cases and restrictions for messaging performance testing. Also, if there\n> > any stories of success in boosting python performance - feel free to share\n> > it.\n> >\n> > The metrics to measure depend on the goal. Do we think the messaging code\n> > is using too much memory? Is it too slow? Or is there something else\n> > causing concern?\n> >\n> > It does make sense to have profiling for cases when trying to upscale\n> cluster and it\'ll be a good thing to have an ability to figure out if\n> scaled AMQP service has it\'s best configuration (i guess here would come\n> the question about doing performance testing using well-known tools), and\n> the most interesting question is about how messaging driver decreases (or\n> leaves untouched) throughput between RPC client and server. This metering\n> results can be compared to those tools that were designed for performance\n> testing. And that\'s why it\'ll be good step forward having\n> profiling/performance testing using high load technic.\n\nThat makes it sound like you want to build performance testing tools for\nthe infrastructure oslo.messaging is using, and not for oslo.messaging\nitself. Is that right?\n\nDoug\n\n> \n> \n> > >\n> > >\n> > >\n> > > [1] http://www.huyng.com/posts/python-performance-analysis/\n> > >\n> > > Kind regards,\n> > > Denis Makogon\n> > > IRC: denis_makogon\n> > > dmakogon at mirantis.com\n> > >\n> > >\n> > __________________________________________________________________________\n> > > OpenStack Development Mailing List (not for usage questions)\n> > > Unsubscribe:\n> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> Kind regards,\n> Denis M.\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPR0WpJxxLstLMb9g2yCL-UvPLAixNfUqePsmj4ud9J6yCMXbA@mail.gmail.com>',NULL),('<1422379425.3282461.219590321.734DFB63@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 09:23:45',-28800,'2015-01-27 17:23:45',NULL,'[openstack-dev] [oslo] temporarily disabling python 3.x testing\n for oslo.messaging and oslo.rootwrap','\n\nOn Tue, Jan 27, 2015, at 09:06 AM, victor stinner wrote:\n> Hi,\n> \n> What is the Python bug? Do you have a reference to the bug report and the\n> patch?\n> \nhttps://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907\nIs the bug I filed with the ubuntu package and it has links back to the\nupstream python bug.\n\nhttps://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1382607\nis less problematic but also an issue for rootwrap.\n> Python 3.4.3 release schedule:\n> \"3.4.3rc1 will be tagged Saturday February 7 and released Sunday February\n> 8.  3.4.3 final will follow two weeks later, tagged Saturday February 21\n> and released Sunday February 22.\"\n> https://mail.python.org/pipermail/python-dev/2015-January/137773.html\n> \n> Victor\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nClark\n\n\n','<1814900499.7900064.1422378393986.JavaMail.zimbra@enovance.com>',NULL),('<1422379736192.24438@wipro.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-27 17:28:58',0,'2015-01-27 17:28:58',NULL,'[Openstack] Guest to host works but host to guest does not','\nHi,\n\n\"Resending as the previous mail was returned back for some reason\"\n\n I am unable to ping/ssh from my host VM to guest VM.  However opposite works just fine, that is I am able to ping from guest  to host VM. Currently I am accessing my guest from horizon console and  have tried pinging/sshing into my host VM and it works just fine. I have  also tried using network namespace to ping from host to guest but it  does not work. I am using  neutron network.\n\nI have already enabled ICMP/TCP/UDP port access using the following\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535 0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default udp 1 65535 0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default icmp -1 -1 0.0.0.0/0\n\nAny pointers would be helpful.\n\nThanks\nAshish\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150127/b841f36e/attachment.html>\n\n',NULL,NULL),('<1422379948.3203374.219590957.5974200C@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 09:32:28',-28800,'2015-01-27 17:32:28',NULL,'[openstack-dev] [oslo] temporarily disabling python 3.x testing\n for oslo.messaging and oslo.rootwrap','\n\nOn Tue, Jan 27, 2015, at 09:13 AM, Julien Danjou wrote:\n> On Tue, Jan 27 2015, Doug Hellmann wrote:\n> \n> > The infra team has been working hard to update our Python 3 testing for all\n> > projects to run on 3.4 instead of 3.3. Two of the last projects to be able to\n> > shift are oslo.messaging and oslo.rootwrap. The test suites for both projects\n> > trigger a segfault bug in the 3.4 interpreter as it is shipped on Ubuntu\n> > Trusty. The fix for the segfault is already available upstream, and the team at\n> > Canonical is working on packaging a new release, but our schedules are out of\n> > sync. Maintaining a separate image and pool of testing nodes for 3.3 testing of\n> > just these two projects is going to be a bit of a burden, and so the infra team\n> > has asked if we?re willing to turn off the 3.3 jobs for the two projects,\n> > leaving us without 3.x testing in the gate until the 3.4 interpreter on Trusty\n> > is updated.\n> \n> Isn\'t there any way to have an ugly work-around in those libs that\n> wouldn\'t trigger the Python 3.4 segfault or at least disable the\n> responsible tests until Python 3.4 gets fixed?\n> \nSo the issue is that the garbage collector segfaults on null objects in\nthe to be garbage collected list. Which means that by the time garbage\ncollection breaks you don\'t have the info you need to know what\nreferences lead to the segfault. I spent a bit of time in gdb debugging\nthis and narrowed it down enough to realize what the bug was and find it\nwas fixed in later python releases but didn\'t have the time to sort out\nhow to figure out specifically which references in oslo.messaging caused\nthe garbage collector to fall over.\n\nFor oslo.rootwrap it affected any tests that ran with logging due to the\nway rootwrap does logging iirc.\n\nClark\n\n\n','<m2wq48ywng.fsf@danjou.info>',NULL),('<1422382074-sup-5560@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 10:15:27',-28800,'2015-01-27 18:15:27',NULL,'[openstack-dev] [tc] do we really need project tags in the\n	governance repository?','Excerpts from Thierry Carrez\'s message of 2015-01-27 02:46:03 -0800:\n> Doug Hellmann wrote:\n> > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote:\n> > [...]\n> >> I\'m open to alternative suggestions on where the list of tags, their\n> >> definition and the list projects they apply to should live. If you don\'t\n> >> like that being in the governance repository, what would have your\n> >> preference ?\n> > \n> > From the very beginning I have taken the position that tags are by\n> > themselves not sufficiently useful for evaluating projects. If someone\n> > wants to choose between Ceilometer, Monasca, or StackTach, we\'re\n> > unlikely to come up with tags that will let them do that. They need\n> > in-depth discussions of deployment options, performance characteristics,\n> > and feature trade-offs.\n> \n> They are still useful to give people a chance to discover that those 3\n> are competing in the same space, and potentially get an idea of which\n> one (if any) is deployed on more than one public cloud, better\n> documented, or security-supported. I agree with you that an\n> (opinionated) article comparing those 3 solutions would be a nice thing\n> to have, but I\'m just saying that basic, clearly-defined reference\n> project metadata still has a lot of value, especially as we grow the\n> number of projects.\n> \n\nI agree with your statement that summary reference metadata is useful. I\nagree with Doug that it is inappropriate for the TC to assign it.\n\n> >> That said, I object to only saying \"this is all information that can be\n> >> found elsewhere or should live elsewhere\", because that is just keeping\n> >> the current situation -- where that information exists somewhere but\n> >> can\'t be efficiently found by our downstream consumers. We need a\n> >> taxonomy and clear definitions for tags, so that our users can easily\n> >> find, understand and navigate such project metadata.\n> > \n> > As someone new to the project, I would not think to look in the\n> > governance documents for \"state\" information about a project. I would\n> > search for things like \"install guide openstack\" or \"component list\n> > openstack\" and expect to find them in the documentation. So I think\n> > putting the information in those (or similar) places will actually make\n> > it easier to find for someone that hasn\'t been involved in the\n> > discussion of tags and the governance repository.\n> \n> The idea here is to have the reference information in some\n> Gerrit-controlled repository (currently openstack/governance, but I\'m\n> open to moving this elsewhere), and have that reference information\n> consumed by the openstack.org website when you navigate to the\n> \"Software\" section, to present a browseable/searchable list of projects\n> with project metadata. I don\'t expect anyone to read the YAML file from\n> the governance repository. On the other hand, the software section of\n> the openstack.org website is by far the most visited page of all our web\n> properties, so I expect most people to see that.\n> \n\nJust like we gather docs and specs into single websites, we could also\ngather project metadata. Let the projects set their tags. One thing\nthat might make sense for the TC to do is to elevate certain tags to\na more important status that they _will_ provide guidance on when to\nuse. However, the actual project to tag mapping would work quite well\nas a single file in whatever repository the project team thinks would\nbe the best starting point for a new user.\n\n\n','<54C76C6B.7040106@openstack.org>',NULL),('<1422382664-sup-3287@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 10:21:02',-28800,'2015-01-27 18:21:02',NULL,'[openstack-dev] [Openstack-operators] [openstack-operators]\n	[Keystone] flush expired tokens and moves deleted instance','\nExcerpts from Tim Bell\'s message of 2015-01-25 22:10:10 -0800:\n> This is often mentioned as one of those items which catches every OpenStack cloud operator at some time. It\'s not clear to me that there could not be a scheduled job built into the system with a default frequency (configurable, ideally).\n> \n> If we are all configuring this as a cron job, is there a reason that it could not be built into the code ?\n> \nIt has come up before.\n\nThe main reason not to build it into the code as it\'s even better to\njust _never store tokens_:\n\nhttps://blueprints.launchpad.net/keystone/+spec/non-persistent-tokens\nhttp://git.openstack.org/cgit/openstack/keystone-specs/plain/specs/juno/non-persistent-tokens.rst\n\nor just use certs:\n\nhttps://blueprints.launchpad.net/keystone/+spec/keystone-tokenless-authz-with-x509-ssl-client-cert\n\nThe general thought is that putting lots of things in the database that\ndon\'t need to be stored anywhere is a bad idea. The need for the cron\njob is just a symptom of that bug.\n\n\n','<5D7F9996EA547448BC6C54C8C5AAF4E501026E92D3@CERNXCHG41.cern.ch>',NULL),('<1422382899.689695.219616757.0004C705@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 13:21:39',-18000,'2015-01-27 18:21:39',NULL,'[openstack-dev] [oslo] temporarily disabling python 3.x testing\n for oslo.messaging and oslo.rootwrap','\n\nOn Tue, Jan 27, 2015, at 12:06 PM, victor stinner wrote:\n> Hi,\n> \n> What is the Python bug? Do you have a reference to the bug report and the\n> patch?\n\nhttp://bugs.python.org/issue21435\n\n> \n> Python 3.4.3 release schedule:\n> \"3.4.3rc1 will be tagged Saturday February 7 and released Sunday February\n> 8.  3.4.3 final will follow two weeks later, tagged Saturday February 21\n> and released Sunday February 22.\"\n> https://mail.python.org/pipermail/python-dev/2015-January/137773.html\n> \n> Victor\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1814900499.7900064.1422378393986.JavaMail.zimbra@enovance.com>',NULL),('<1422382973.690547.219617425.7F5B754C@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 13:22:53',-18000,'2015-01-27 18:22:53',NULL,'[openstack-dev] [oslo] temporarily disabling python 3.x testing\n for oslo.messaging and oslo.rootwrap','\n\nOn Tue, Jan 27, 2015, at 12:44 PM, Julien Danjou wrote:\n> On Tue, Jan 27 2015, Clark Boylan wrote:\n> \n> > So the issue is that the garbage collector segfaults on null objects in\n> > the to be garbage collected list. Which means that by the time garbage\n> > collection breaks you don\'t have the info you need to know what\n> > references lead to the segfault. I spent a bit of time in gdb debugging\n> > this and narrowed it down enough to realize what the bug was and find it\n> > was fixed in later python releases but didn\'t have the time to sort out\n> > how to figure out specifically which references in oslo.messaging caused\n> > the garbage collector to fall over.\n> \n> ????)?????\n> \n> Ok, then let\'s disable it I guess. If there\'s a chance to keep something\n> has even a non-voting job, that\'d be cool, but I\'m not even sure that\'s\n> an option if it just doesn\'t work and we can\'t keep py33.\n\nI did think about a non-voting job, but there\'s not much point. We\nexpect it to fail with the segfault, so we would just be wasting\nresources. :-/\n\n> \n> -- \n> Julien Danjou\n> ;; Free Software hacker\n> ;; http://julien.danjou.info\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> Email had 1 attachment:\n> + signature.asc\n>   1k (application/pgp-signature)\n\n\n','<m2oapkyv86.fsf@danjou.info>',NULL),('<1422383496.694117.219619477.641CC441@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 13:31:36',-18000,'2015-01-27 18:31:36',NULL,'[openstack-dev] [oslo.messaging] Performance testing. Initial\n	steps.','\n\nOn Tue, Jan 27, 2015, at 12:28 PM, Denis Makogon wrote:\n> On Tue, Jan 27, 2015 at 7:15 PM, Doug Hellmann <doug at doughellmann.com>\n> wrote:\n> \n> >\n> >\n> > On Tue, Jan 27, 2015, at 10:56 AM, Denis Makogon wrote:\n> > > On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann <doug at doughellmann.com>\n> > > wrote:\n> > >\n> > > >\n> > > > > On Jan 15, 2015, at 1:30 PM, Denis Makogon <dmakogon at mirantis.com>\n> > > > wrote:\n> > > > >\n> > > > > Good day to All,\n> > > > >\n> > > > > The question that i?d like to raise here is not simple one, so i?d\n> > like\n> > > > to involve as much readers as i can. I?d like to speak about\n> > oslo.messaging\n> > > > performance testing. As community we?ve put lots of efforts in making\n> > > > oslo.messaging widely used drivers stable as much as possible.\n> > Stability is\n> > > > a good thing, but is it enough for saying ?works well?? I?d say that\n> > it?s\n> > > > not.\n> > > > > Since oslo.messaging uses driver-based messaging workflow, it makes\n> > > > sense to dig into each driver and collect all required/possible\n> > performance\n> > > > metrics.\n> > > > > First of all, it does make sense to figure out how to perform\n> > > > performance testing, first that came into my mind is to simulate high\n> > load\n> > > > on one of corresponding drivers. Here comes the question of how it can\n> > be\n> > > > accomplished withing available oslo.messaging tools - high load on any\n> > > > driver can perform an application that:\n> > > > >       ? can populate multiple emitters(rpc clients) and consumers\n> > (rpc\n> > > > servers).\n> > > > >       ? can force clients to send messages of pre-defined number of\n> > > > messages of any length.\n> > > >\n> > > > That makes sense.\n> > > >\n> > > > > Another thing is why do we need such thing. Profiling, performance\n> > > > testing can improve the way in which our drivers were implemented. It\n> > can\n> > > > show us actual ?bottlenecks? in messaging process, in general. In some\n> > > > cases it does make sense to figure out where problem takes its place -\n> > > > whether AMQP causes messaging problems or certain driver that speaks to\n> > > > AMQP fails.\n> > > > > Next thing that i want to discuss the architecture of\n> > > > profiling/performance testing. As i can see it seemed to be a ?good?\n> > way to\n> > > > add profiling code to each driver. If there?s any objection or better\n> > > > solution, please bring them to the light.\n> > > >\n> > > > What sort of extra profiling code do you anticipate needing?\n> > > >\n> > > >\n> > > As i can foresee (taking into account [1]) couple decorators, possibly\n> > > one\n> > > that handles metering process. The biggest part of code will take\n> > > highload\n> > > tool that\'ll be a part of messaging. But another question adding certain\n> > > dependecies to the project.\n> > >\n> > >\n> > > > > Once we?d have final design for profiling we would need to figure out\n> > > > tools for profiling. After searching over the web, i found pretty\n> > > > interesting topic related to python profiling [1]. After certain\n> > > > investigations it does makes sense discuss next profiling\n> > options(apply one\n> > > > or both):\n> > > > >       ? Line-by-line timing and execution frequency with a profiler\n> > > > (there are possible Pros and Cons, but i would say the per-line\n> > statistics\n> > > > is more than appreciable at initial performance testing steps)\n> > > > >       ? Memory/CPU consumption\n> > > > > Metrics. The most useful metric for us is time, any time-based\n> > metric,\n> > > > since it is very useful to know at which step or/and by whom\n> > delay/timeout\n> > > > caused, for example, so as it said, we would be able to figure out\n> > whether\n> > > > AMQP or driver fails to do what it was designed for.\n> > > > > Before proposing spec i?d like to figure out any other requirements,\n> > use\n> > > > cases and restrictions for messaging performance testing. Also, if\n> > there\n> > > > any stories of success in boosting python performance - feel free to\n> > share\n> > > > it.\n> > > >\n> > > > The metrics to measure depend on the goal. Do we think the messaging\n> > code\n> > > > is using too much memory? Is it too slow? Or is there something else\n> > > > causing concern?\n> > > >\n> > > > It does make sense to have profiling for cases when trying to upscale\n> > > cluster and it\'ll be a good thing to have an ability to figure out if\n> > > scaled AMQP service has it\'s best configuration (i guess here would come\n> > > the question about doing performance testing using well-known tools), and\n> > > the most interesting question is about how messaging driver decreases (or\n> > > leaves untouched) throughput between RPC client and server. This metering\n> > > results can be compared to those tools that were designed for performance\n> > > testing. And that\'s why it\'ll be good step forward having\n> > > profiling/performance testing using high load technic.\n> >\n> > That makes it sound like you want to build performance testing tools for\n> > the infrastructure oslo.messaging is using, and not for oslo.messaging\n> > itself. Is that right?\n> >\n> > I\'d like to build tool that would be able to profile messaging over\n> various deployments. This \"tool\" would give me an ability to compare\n> results of performance testing produced by native tools and\n> oslo.messaging-based tool, eventually it would lead us into digging into\n> code and trying to figure out where \"bad things\" are happening (that\'s\n> the\n> actual place where we would need to profile messaging code). Correct me\n> if\n> i\'m wrong.\n\nIt would be interesting to have recommendations for deployment of rabbit\nor qpid based on performance testing with oslo.messaging. It would also\nbe interesting to have recommendations for changes to the implementation\nof oslo.messaging based on performance testing. I\'m not sure you want to\ndo full-stack testing for the latter, though.\n\nEither way, I think you would be able to start the testing without any\nchanges in oslo.messaging.\n\nDoug\n\n> \n> Doug\n> >\n> > >\n> > >\n> > > > >\n> > > > >\n> > > > >\n> > > > > [1] http://www.huyng.com/posts/python-performance-analysis/\n> > > > >\n> > > > > Kind regards,\n> > > > > Denis Makogon\n> > > > > IRC: denis_makogon\n> > > > > dmakogon at mirantis.com\n> > > > >\n> > > > >\n> > > >\n> > __________________________________________________________________________\n> > > > > OpenStack Development Mailing List (not for usage questions)\n> > > > > Unsubscribe:\n> > > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >\n> > > >\n> > > >\n> > __________________________________________________________________________\n> > > > OpenStack Development Mailing List (not for usage questions)\n> > > > Unsubscribe:\n> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > >\n> > >\n> > > Kind regards,\n> > > Denis M.\n> > >\n> > __________________________________________________________________________\n> > > OpenStack Development Mailing List (not for usage questions)\n> > > Unsubscribe:\n> > > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> Kind regards,\n> Denis M.\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPR0Wp+cGEx55g9syYHhONitMoUh5sah4_BZCZHGLAD0=faJow@mail.gmail.com>',NULL),('<1422394159-sup-8777@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 13:33:55',-28800,'2015-01-27 21:33:55',NULL,'[openstack-dev] [Openstack-operators] [openstack-operators]\n	[Keystone] flush expired tokens and moves deleted instance','The problem with running in memcached is now you have to keep _EVERY_\ntoken in RAM. This is not any cheaper than cleaning out a giant on-disk\ntable.\n\nAlso worth noting is that memcached can produce frustrating results unless\nyou run it with -M. That is because without -M, your tokens may be removed\nwell before their expiration and well before memcached fills up if the\nslabs that are allocated in the early days of running are filled up.\nAlso single users that have many tokens will overrun the per-item limit\nin memcached with the size of the token ID list.\n\nThere\'s no magic bullet.. just trade-offs that may or may not work well\nfor your site.\n\nExcerpts from John Dewey\'s message of 2015-01-27 10:41:33 -0800:\n> This is one reason to use the memcached backend. Why replicate these tokens in the first place. \n> \n> On Tuesday, January 27, 2015 at 10:21 AM, Clint Byrum wrote:\n> \n> > \n> > Excerpts from Tim Bell\'s message of 2015-01-25 22:10:10 -0800:\n> > > This is often mentioned as one of those items which catches every OpenStack cloud operator at some time. It\'s not clear to me that there could not be a scheduled job built into the system with a default frequency (configurable, ideally).\n> > > \n> > > If we are all configuring this as a cron job, is there a reason that it could not be built into the code ?\n> > It has come up before.\n> > \n> > The main reason not to build it into the code as it\'s even better to\n> > just _never store tokens_:\n> > \n> > https://blueprints.launchpad.net/keystone/+spec/non-persistent-tokens\n> > http://git.openstack.org/cgit/openstack/keystone-specs/plain/specs/juno/non-persistent-tokens.rst\n> > \n> > or just use certs:\n> > \n> > https://blueprints.launchpad.net/keystone/+spec/keystone-tokenless-authz-with-x509-ssl-client-cert\n> > \n> > The general thought is that putting lots of things in the database that\n> > don\'t need to be stored anywhere is a bad idea. The need for the cron\n> > job is just a symptom of that bug.\n> > \n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n\n\n','<07842C408EC94BF6AF01626D17E4D742@dewey.ws>',NULL),('<1422397390.1129958.219720373.030BD3D3@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-27 17:23:10',-18000,'2015-01-27 22:23:10',NULL,'[openstack-dev] oslo.messaging 1.6.0 released','There were some issues with the build job, so this release has just gone\nlive. I apologize for the delay.\n\nDoug\n\nOn Tue, Jan 27, 2015, at 02:05 PM, Doug Hellmann wrote:\n> The Oslo team is pleased to announce the release of:\n> \n> oslo.messaging 1.6.0: Oslo Messaging API\n> \n> The primary reason for this release is to move the code\n> out of the oslo namespace package as part of\n> https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages\n> \n> This release also includes requirements updates, and several months worth\n> of bug fixes.\n> \n> For more details, please see the git log history below and:\n> \n> http://launchpad.net/oslo.messaging/+milestone/1.6.0\n> \n> Please report issues through launchpad:\n> \n> http://bugs.launchpad.net/oslo.messaging\n> Changes in /home/dhellmann/repos/openstack/oslo.messaging 1.5.1..1.6.0\n> ----------------------------------------------------------------------\n> \n> bfb8c97 Updated from global requirements\n> eb92511 Expose _impl_test for designate\n> ee31a84 Update Oslo imports to remove namespace package\n> 563376c Speedup the rabbit tests\n> f286ef1 Fix functionnal tests\n> db7371c Fixed docstring for Notifier\n> 386f5da zmq: Refactor test case shared code\n> 7680897 Add more private symbols to the old namespace package\n> 2832051 Updated from global requirements\n> b888ee3 Fixes test_two_pools_three_listener\n> 0c49f0d Add TimerTestCase missing tests case\n> be9fca7 fix qpid test issue with eventlet monkey patching\n> 0ca1b1e Make setup.cfg packages include oslo.messaging\n> 408d0da Upgrade to hacking 0.10\n> a6d068a Add oslo.messaging._drivers.common for heat tests\n> 1fa0e6a Port zmq driver to Python 3\n> bc8675a fix qpid test issue with eventlet monkey patching\n> e55a83e Move files out of the namespace package\n> 31a149a Add a info log when a reconnection occurs\n> 44132d4 rabbit: fix timeout timer when duration is None\n> c18f9f7 Don\'t log each received messages\n> 3e2d142 Fix some comments in a backporting review session\n> c40ba04 Enable IPv6-support in libzmq by default\n> 372bc49 Add a thread + futures executor based executor\n> 56a9c55 safe_log Sanitize Passwords in List of Dicts\n> 709c401 Updated from global requirements\n> 98bfdd1 rabbit: add some tests when rpc_backend is set\n> d3e6ea1 Warns user if thread monkeypatch is not done\n> cd71c47 Add functional and unit 0mq driver tests\n> 15aa5cb The executor doesn\'t need to set the timeout\n> 43a9dc1 qpid: honor iterconsume timeout\n> 023b7f4 rabbit: more precise iterconsume timeout\n> 737afde Workflow documentation is now in infra-manual\n> 66db2b3 Touch up grammar in warning messages\n> 4e6dabb Make the RPCVersionCapError message clearer\n> 254405d Doc: \'wait\' releases driver connection, not \'stop\'\n> 09cd9c0 Don\'t allow call with fanout target\n> 0844037 Add an optional executor callback to dispatcher\n> eb21f6b Warn user if needed when the process is forked\n> 7ad0d7e Fix reconnect race condition with RabbitMQ cluster\n> 1624793 Add more TLS protocols to rabbit impl\n> 6987b8a Fix incorrect attribute name in matchmaker_redis\n> \n> Diffstat (except docs and test files)\n> -------------------------------------\n> \n> CONTRIBUTING.rst                                   |   7 +-\n> oslo/messaging/__init__.py                         |  15 +\n> oslo/messaging/_cmd/__init__.py                    |   1 -\n> oslo/messaging/_cmd/zmq_receiver.py                |  39 -\n> oslo/messaging/_drivers/__init__.py                |   1 -\n> oslo/messaging/_drivers/amqp.py                    | 222 -----\n> oslo/messaging/_drivers/amqpdriver.py              | 472 ----------\n> oslo/messaging/_drivers/base.py                    | 108 ---\n> oslo/messaging/_drivers/common.py                  | 343 +-------\n> oslo/messaging/_drivers/impl_fake.py               | 233 -----\n> oslo/messaging/_drivers/impl_qpid.py               | 731 ----------------\n> oslo/messaging/_drivers/impl_rabbit.py             | 783\n> -----------------\n> oslo/messaging/_drivers/impl_zmq.py                | 941\n> --------------------\n> oslo/messaging/_drivers/matchmaker.py              | 321 -------\n> oslo/messaging/_drivers/matchmaker_redis.py        | 139 ---\n> oslo/messaging/_drivers/matchmaker_ring.py         | 104 ---\n> oslo/messaging/_drivers/pool.py                    |  88 --\n> oslo/messaging/_drivers/protocols/__init__.py      |   0\n> oslo/messaging/_drivers/protocols/amqp/__init__.py |   0\n> .../_drivers/protocols/amqp/controller.py          | 589 -------------\n> oslo/messaging/_drivers/protocols/amqp/driver.py   | 295 -------\n> .../messaging/_drivers/protocols/amqp/eventloop.py | 339 -------\n> oslo/messaging/_drivers/protocols/amqp/opts.py     |  73 --\n> oslo/messaging/_executors/base.py                  |  33 +-\n> oslo/messaging/_executors/impl_blocking.py         |  56 --\n> oslo/messaging/_executors/impl_eventlet.py         | 112 ---\n> oslo/messaging/_i18n.py                            |  35 -\n> oslo/messaging/_utils.py                           |  41 -\n> oslo/messaging/conffixture.py                      |  67 +-\n> oslo/messaging/exceptions.py                       |  29 +-\n> oslo/messaging/localcontext.py                     |  44 +-\n> oslo/messaging/notify/__init__.py                  |   1 +\n> oslo/messaging/notify/_impl_log.py                 |  35 -\n> oslo/messaging/notify/_impl_messaging.py           |  60 --\n> oslo/messaging/notify/_impl_noop.py                |  24 -\n> oslo/messaging/notify/_impl_routing.py             | 135 ---\n> oslo/messaging/notify/_impl_test.py                |  34 -\n> oslo/messaging/notify/dispatcher.py                | 119 +--\n> oslo/messaging/notify/listener.py                  | 123 +--\n> oslo/messaging/notify/log_handler.py               |  48 +-\n> oslo/messaging/notify/logger.py                    |  70 +-\n> oslo/messaging/notify/middleware.py                | 117 +--\n> oslo/messaging/notify/notifier.py                  | 304 +------\n> oslo/messaging/openstack/__init__.py               |   0\n> oslo/messaging/openstack/common/__init__.py        |   0\n> oslo/messaging/openstack/common/context.py         | 126 ---\n> oslo/messaging/opts.py                             |  75 --\n> oslo/messaging/rpc/client.py                       | 382 +-------\n> oslo/messaging/rpc/dispatcher.py                   | 178 +---\n> oslo/messaging/rpc/server.py                       | 138 +--\n> oslo/messaging/serializer.py                       |  65 +-\n> oslo/messaging/server.py                           | 135 +--\n> oslo/messaging/target.py                           |  83 +-\n> oslo/messaging/transport.py                        | 413 +--------\n> oslo_messaging/__init__.py                         |  23 +\n> oslo_messaging/_cmd/__init__.py                    |   1 +\n> oslo_messaging/_cmd/zmq_receiver.py                |  40 +\n> oslo_messaging/_drivers/__init__.py                |   1 +\n> oslo_messaging/_drivers/amqp.py                    | 224 +++++\n> oslo_messaging/_drivers/amqpdriver.py              | 453 ++++++++++\n> oslo_messaging/_drivers/base.py                    | 114 +++\n> oslo_messaging/_drivers/common.py                  | 356 ++++++++\n> oslo_messaging/_drivers/impl_fake.py               | 241 +++++\n> oslo_messaging/_drivers/impl_qpid.py               | 775 ++++++++++++++++\n> oslo_messaging/_drivers/impl_rabbit.py             | 832\n> ++++++++++++++++++\n> oslo_messaging/_drivers/impl_zmq.py                | 973\n> +++++++++++++++++++++\n> oslo_messaging/_drivers/matchmaker.py              | 321 +++++++\n> oslo_messaging/_drivers/matchmaker_redis.py        | 140 +++\n> oslo_messaging/_drivers/matchmaker_ring.py         | 105 +++\n> oslo_messaging/_drivers/pool.py                    |  88 ++\n> oslo_messaging/_drivers/protocols/__init__.py      |   0\n> oslo_messaging/_drivers/protocols/amqp/__init__.py |   0\n> .../_drivers/protocols/amqp/controller.py          | 589 +++++++++++++\n> oslo_messaging/_drivers/protocols/amqp/driver.py   | 296 +++++++\n> .../_drivers/protocols/amqp/eventloop.py           | 339 +++++++\n> oslo_messaging/_drivers/protocols/amqp/opts.py     |  73 ++\n> oslo_messaging/_executors/__init__.py              |   0\n> oslo_messaging/_executors/base.py                  |  53 ++\n> oslo_messaging/_executors/impl_blocking.py         |  57 ++\n> oslo_messaging/_executors/impl_eventlet.py         | 118 +++\n> oslo_messaging/_executors/impl_thread.py           | 131 +++\n> oslo_messaging/_i18n.py                            |  35 +\n> oslo_messaging/_utils.py                           |  41 +\n> oslo_messaging/conffixture.py                      |  78 ++\n> oslo_messaging/exceptions.py                       |  40 +\n> oslo_messaging/localcontext.py                     |  55 ++\n> oslo_messaging/notify/__init__.py                  |  27 +\n> oslo_messaging/notify/_impl_log.py                 |  41 +\n> oslo_messaging/notify/_impl_messaging.py           |  60 ++\n> oslo_messaging/notify/_impl_noop.py                |  24 +\n> oslo_messaging/notify/_impl_routing.py             | 135 +++\n> oslo_messaging/notify/_impl_test.py                |  34 +\n> oslo_messaging/notify/dispatcher.py                | 135 +++\n> oslo_messaging/notify/listener.py                  | 137 +++\n> oslo_messaging/notify/log_handler.py               |  42 +\n> oslo_messaging/notify/logger.py                    |  82 ++\n> oslo_messaging/notify/middleware.py                | 128 +++\n> oslo_messaging/notify/notifier.py                  | 315 +++++++\n> oslo_messaging/openstack/__init__.py               |   0\n> oslo_messaging/openstack/common/__init__.py        |   0\n> oslo_messaging/openstack/common/context.py         | 126 +++\n> oslo_messaging/opts.py                             |  75 ++\n> oslo_messaging/rpc/__init__.py                     |  32 +\n> oslo_messaging/rpc/client.py                       | 397 +++++++++\n> oslo_messaging/rpc/dispatcher.py                   | 195 +++++\n> oslo_messaging/rpc/server.py                       | 152 ++++\n> oslo_messaging/serializer.py                       |  76 ++\n> oslo_messaging/server.py                           | 150 ++++\n> oslo_messaging/target.py                           |  94 ++\n> oslo_messaging/transport.py                        | 424 +++++++++\n> requirements-py3.txt                               |  10 +-\n> requirements.txt                                   |  15 +-\n> setup.cfg                                          |  34 +-\n> test-requirements-py3.txt                          |   2 +-\n> test-requirements.txt                              |   5 +-\n> tox.ini                                            |   8 +-\n> 195 files changed, 18219 insertions(+), 9934 deletions(-)\n> \n> Requirements updates\n> --------------------\n> \n> diff --git a/requirements-py3.txt b/requirements-py3.txt\n> index e074095..64f3cb8 100644\n> --- a/requirements-py3.txt\n> +++ b/requirements-py3.txt\n> @@ -5,4 +5,4 @@\n> -oslo.config>=1.4.0  # Apache-2.0\n> -oslo.serialization>=1.0.0               # Apache-2.0\n> -oslo.utils>=1.0.0                       # Apache-2.0\n> -oslo.i18n>=1.0.0  # Apache-2.0\n> +oslo.config>=1.6.0  # Apache-2.0\n> +oslo.serialization>=1.2.0               # Apache-2.0\n> +oslo.utils>=1.2.0                       # Apache-2.0\n> +oslo.i18n>=1.3.0  # Apache-2.0\n> @@ -21 +21 @@ kombu>=2.5.0\n> -oslo.middleware>=0.1.0                  # Apache-2.0\n> +oslo.middleware>=0.3.0                  # Apache-2.0\n> diff --git a/requirements.txt b/requirements.txt\n> index 3f80258..352b14a 100644\n> --- a/requirements.txt\n> +++ b/requirements.txt\n> @@ -7,4 +7,4 @@ pbr>=0.6,!=0.7,<1.0\n> -oslo.config>=1.4.0  # Apache-2.0\n> -oslo.utils>=1.0.0                       # Apache-2.0\n> -oslo.serialization>=1.0.0               # Apache-2.0\n> -oslo.i18n>=1.0.0  # Apache-2.0\n> +oslo.config>=1.6.0  # Apache-2.0\n> +oslo.utils>=1.2.0                       # Apache-2.0\n> +oslo.serialization>=1.2.0               # Apache-2.0\n> +oslo.i18n>=1.3.0  # Apache-2.0\n> @@ -19 +19 @@ six>=1.7.0\n> -eventlet>=0.15.2\n> +eventlet>=0.16.1\n> @@ -28 +28,4 @@ kombu>=2.5.0\n> -oslo.middleware>=0.1.0                  # Apache-2.0\n> +oslo.middleware>=0.3.0                  # Apache-2.0\n> +\n> +# for the futures based executor\n> +futures>=2.1.6\n> diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt\n> index 49c9cba..937c9f2 100644\n> --- a/test-requirements-py3.txt\n> +++ b/test-requirements-py3.txt\n> @@ -6 +6 @@\n> -hacking>=0.9.1,<0.10\n> +hacking>=0.10.0,<0.11\n> diff --git a/test-requirements.txt b/test-requirements.txt\n> index 3105e4c..0b2a583 100644\n> --- a/test-requirements.txt\n> +++ b/test-requirements.txt\n> @@ -6 +6 @@\n> -hacking>=0.9.2,<0.10\n> +hacking>=0.10.0,<0.11\n> @@ -23,0 +24,3 @@ redis>=2.10.0\n> +# for test_impl_zmq\n> +pyzmq>=14.3.1\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<DEA2B882-2A8D-4C7F-892B-14E35AEB2626@doughellmann.com>',NULL),('<1422421674106.11107@wipro.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-28 05:07:55',0,'2015-01-28 05:07:55',NULL,'[Openstack] Guest to Host works but host to guest does not','Hi Srinivas,\n\n\nThis is a single VM setup this means all the components are installed on the same VM. This VM has got 2 ethernet interfaces eth0 and eth1. Access to TCP/22 is already enabled as you can see from\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535 0.0.0.0/0<http://0.0.0.0/0>\n\n\nRegards\n\nAshish\n\n\n________________________________\nFrom: Srinivasreddy R <srinivasreddy4390 at gmail.com>\nSent: Wednesday, January 28, 2015 12:03 AM\nTo: Ashish Jain (WT01 - BAS)\nSubject: Re: [Openstack] Guest to Host works but host to guest does not\n\ni think you cannot access VM from compute node or controller .\ninsted you can loging through external network [need to enable tcp/22, icmp rules in security group rules ].A pc connected to br-ex via an external physical interface in controller node .\n\nregards,\nsrinivas.\n\n\nOn Tue, Jan 27, 2015 at 10:30 PM, <ashish.jain14 at wipro.com<mailto:ashish.jain14 at wipro.com>> wrote:\nHi,\n\n I am unable to ping/ssh from my host VM to guest VM.  However opposite works just fine, that is I am able to ping from guest  to host VM. Currently I am accessing my guest from horizon console and  have tried pinging/sshing into my host VM and it works just fine. I have  also tried using network namespace to ping from host to guest but it  does not work. I am using  neutron network.\n\nI have already enabled ICMP/TCP/UDP port access using the following\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535 0.0.0.0/0<http://0.0.0.0/0>\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default udp 1 65535 0.0.0.0/0<http://0.0.0.0/0>\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default icmp -1 -1 0.0.0.0/0<http://0.0.0.0/0>\n\nAny pointers would be helpful.\n\nThanks\nAshish\n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n--\nthanks\nsrinivas.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150128/0d4479db/attachment.html>\n\n','<CAJP4VWiGwO1C2a-n8ZBv=f+uSFDYHgrahNOdYrFWg1EWGrFkNg@mail.gmail.com>',NULL),('<1422444317121.14791@kemptechnologies.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 11:24:20',0,'2015-01-28 11:24:20',NULL,'[openstack-dev]  [neutron] lbaas driver implementation question','Thanks for your response.\n\n\nWe have analysed the issue further and the DG is not the problem.\n\n\n\nWe have taken tcpdumps on all interfaces and we can see that the ping reaches the VIP on the driver virtual appliance and the virtual appliance responds to the ping. It responds with the mac address of the switch. Once it hits the switch, the traffic is dropped. The virtual appliance itself has no issues and it is using the same MAC Address.\n\n\n\nI have done a dump on the flows for ovs and I can see that the flow for the ping request is set up but the flow for the reply is not.\n\n\n\nThe action on the port I believe is normal so should send handle the requests normally.\n\n\n\nWhat could be causing the flow not to be created for the reply? Is there a misconfiguration somewhere along the line?\n\n\nCheers,\n\n\nShane McGough\nJunior Software Developer\nKEMP Technologies\nNational Technology Park, Limerick, Ireland.\n\nkemptechnologies.com<https://kemptechnologies.com/> | @KEMPtech<https://twitter.com/KEMPtech> | LinkedIn<https://www.linkedin.com/company/kemp-technologies>\n________________________________\nFrom: Jain, Vivek <VIVEKJAIN at ebay.com>\nSent: Monday, January 26, 2015 6:42 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] [neutron] lbaas driver implementation question\n\nCan you try to ping the client IP from your Load Balancer and see if that works. I am suspecting that default gateway used on LB is not correct.\n\nThanks,\nVivek\n\nFrom: Shane McGough <smcgough at kemptechnologies.com<mailto:smcgough at kemptechnologies.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Monday, January 26, 2015 at 7:32 AM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: [openstack-dev] [neutron] lbaas driver implementation question\n\nHi all,\n\nImplementing a driver for lbaas and am running into some trouble.\n\nThe load balancer is a VM hosted on the compute node within devstack and the driver can create vips, pools and members no problem.\n\nThe problem lies when trying to access the service hosted by the VIP.\n\n>From TCP dumps on the load balancer instance we can see that the traffic hits the load balancer and the load balancer replies but the reply does not reach the client.\n\nIs there an implementation reason why this might occur (i.e. not creating a port or doing some neutron configuration within the driver) or could there be another issue at play here.\n\nWe are using stable/juno devstack for test purposes. We can access the load balancer GUI no problem via the browser its just anything hosted by the LB services is inaccessible.\n\nAny help would be appreciated\n\nThanks,\nShane.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/b73ddbc9/attachment.html>\n\n','<D0EBCA1D.51170%vivekjain@ebay.com>',NULL),('<1422449971.45.1383372378307.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:06:18',0,'2013-11-02 06:06:18',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-ceilometer-python26-stable-grizzly #43','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/43/>\n\n\n\n',NULL,NULL),('<1422456395.211050.220009397.316A1599@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 09:46:35',-18000,'2015-01-28 14:46:35',NULL,'[openstack-dev] [oslo.messaging] Performance testing. Initial\n	steps.','\n\nOn Wed, Jan 28, 2015, at 03:23 AM, Denis Makogon wrote:\n> On Tue, Jan 27, 2015 at 10:26 PM, Gordon Sim <gsim at redhat.com> wrote:\n> \n> > On 01/27/2015 06:31 PM, Doug Hellmann wrote:\n> >\n> >> On Tue, Jan 27, 2015, at 12:28 PM, Denis Makogon wrote:\n> >>\n> >>> I\'d like to build tool that would be able to profile messaging over\n> >>> various deployments. This \"tool\" would give me an ability to compare\n> >>> results of performance testing produced by native tools and\n> >>> oslo.messaging-based tool, eventually it would lead us into digging into\n> >>> code and trying to figure out where \"bad things\" are happening (that\'s\n> >>> the\n> >>> actual place where we would need to profile messaging code). Correct me\n> >>> if\n> >>> i\'m wrong.\n> >>>\n> >>\n> >> It would be interesting to have recommendations for deployment of rabbit\n> >> or qpid based on performance testing with oslo.messaging. It would also\n> >> be interesting to have recommendations for changes to the implementation\n> >> of oslo.messaging based on performance testing. I\'m not sure you want to\n> >> do full-stack testing for the latter, though.\n> >>\n> >> Either way, I think you would be able to start the testing without any\n> >> changes in oslo.messaging.\n> >>\n> >\n> > I agree. I think the first step is to define what to measure and then\n> > construct an application using olso.messaging that allows the data of\n> > interest to be captured using different drivers and indeed different\n> > configurations of a given driver.\n> >\n> > I wrote a very simple test application to test one aspect that I felt was\n> > important, namely the scalability of the RPC mechanism as you increase the\n> > number of clients and servers involved. The code I used is\n> > https://github.com/grs/ombt, its probably stale at the moment, I only\n> > link to it as an example of approach.\n> >\n> > Using that test code I was then able to compare performance in this one\n> > aspect across drivers (the \'rabbit\', \'qpid\' and new amqp 1.0 based drivers\n> > _ I wanted to try zmq, but couldn\'t figure out how to get it working at the\n> > time), and for different deployment options using a given driver (amqp 1.0\n> > using qpidd or qpid dispatch router in either standalone or with multiple\n> > connected routers).\n> >\n> > There are of course several other aspects that I think would be important\n> > to explore: notifications, more specific variations in the RPC \'topology\'\n> > i.e. number of clients on given server number of servers in single group\n> > etc, and a better tool (or set of tools) would allow all of these to be\n> > explored.\n> >\n> > From my experimentation, I believe the biggest differences in scalability\n> > are going to come not from optimising the code in oslo.messaging so much as\n> > choosing different patterns for communication. Those choices may be\n> > constrained by other aspects as well of course, notably approach to\n> > reliability.\n> >\n> >\n> >\n> After couple internal discussions and hours of investigations, i think\n> i\'ve\n> foung the most applicabale solution\n> that will accomplish performance testing approach and will eventually be\n> evaluated as messaging drivers\n> configuration and AMQP service deployment recommendataion.\n> \n> Solution that i\'ve been talking about is already pretty well-known across\n> OpenStack components - Rally and its scenarios.\n> Why it would be the best option? Rally scenarios would not touch\n> messaging\n>  core part. Scenarios are gate-able.\n> Even if we\'re talking about internal testing, scenarios are very useful\n> in\n> this case,\n> since they are something that can be tuned/configured taking into account\n> environment needs.\n> \n> Doug, Gordon, what do you think about bringing scenarios into messaging?\n\nI think I need more detail about what you mean by that.\n\nDoug\n\n> \n> __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> Kind regards,\n> Denis M.\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPR0WpJCxw0b9YyRT7D2s2edfaREpzXZfqwrJdxLve2cWC6gyQ@mail.gmail.com>',NULL),('<1422459810.9463.5.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 10:43:30',-18000,'2015-01-28 15:43:30',NULL,'[openstack-dev] [sahara] About Sahara Oozie plan and Spark CDH\n	Issues','Intel folks,\n\nBelated welcome to Sahara!  Thank you for your recent commits.\n\nMoving this thread to openstack-dev so others may contribute, cc\'ing\nDaniele and Pietro who pioneered the Spark plugin.\n\nI\'ll respond with another email about Oozie work, but I want to\naddress the Spark/Swift issue in CDH since I have been working\non it and there is a task which still needs to be done -- that\nis to upgrade the CDH version in the spark image and see if\nthe situation improves (see below)\n\nRelevant reviews are here:\n\nhttps://review.openstack.org/146659\nhttps://review.openstack.org/147955\nhttps://review.openstack.org/147985\nhttps://review.openstack.org/146659\n\nIn the first review, you can see that we set an extra driver\nclasspath to pull in \'/usr/lib/hadoop/lib/jackson-core-asl-1.8.8.jar.\n\nThis is because the spark-assembly JAR in CDH4 contains classes from\njackson-mapper-asl-1.8.8 and jackson-core-asl-1.9.x. When the\nhadoop-swift.jar dereferences a Swift path, it calls into code\nfrom jackson-mapper-asl-1.8.8 which uses JsonClass.  But JsonClass\nwas removed in jackson-core-asl-1.9.x, so there is an exception.\n\nTherefore, we need to use the classpath to either upgrade the version of\njackson-mapper-asl to 1.9.x or downgrade the version of jackson-core-asl\nto 1.8.8 (both work in my testing).  However, the first of these options\nrequires us to bundle an extra jar.  Since /usr/lib/hadoop already\ncontains jackson-core-asl-1.8.8, it is easier to just add that to the\nclasspath and downgrade the jackson version.\n\nNote, there are some references to this problem on the spark mailing list,\nwe are not the only ones to encounter it.\n\nHowever, I am not completely comfortable with mixing versions and\npatching the classpath this way.  It looks to me like the Spark assembly\nused in CDH5 has consistent versions, and I would like to try updating\nthe CDH version in sahara-image-elments to CDH5 for Spark. If this fixes\nthe problem and removes the need for the extra classpath, that would be\ngreat.\n\nWould someone like to take on this change? (modifying sahara-image-elements\nto use CDH5 for Spark images) I can make a blueprint for\nit.\n\nMore to come about Oozie topics.\n\nBest regards,\n\nTrevor\n\nOn Thu, 2015-01-15 at 15:34 +0000, Chen, Weiting wrote:\n> Hi Mckay.\n> \n>  \n> \n> We are Intel team and contributing OpenStack Sahara project.\n> \n> We are new in Sahara and would like to do more contributions in this\n> project.\n> \n> So far, we are focusing on Sahara CDH Plugin.\n> \n> So if there is any issues related on this, please feel free to discuss\n> with us.\n> \n>  \n> \n> During IRC meeting, there are two issues you mentioned and we would\n> like to discuss with you.\n> \n> 1.      Oozie Workflow Support: \n> \n> Do you have any plan could share with us about your idea?\n> \n> Because in our case, we are testing to run a java action job with\n> HBase library support and also facing some problems about Oozie\n> support.\n> \n> So it should be good to share the experience with each other.\n> \n> \n> \n> 2.      Spark CDH Issues: \n> \n> Could you provide more information about this issue? In CDH Plugin, we\n> have used CDH 5 to finish swift test. So it should be fine to upgrade\n> CDH 4 to 5.\n> \n>  \n> \n> \n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/c134ebc9/attachment.html>\n\n','<6EEB8A90CDE31C4680037A635100E8FF847A8C@SHSMSX104.ccr.corp.intel.com>',NULL),('<1422464222.9463.7.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 11:57:02',-18000,'2015-01-28 16:57:02',NULL,'[openstack-dev] [sahara] About Sahara Oozie plan and Spark CDH\n	Issues','Daniele,\n\n  Excellent! I\'ll have to keep a closer eye on bigfoot activity :) I\'ll\npursue this.\n\nBest,\n\nTrevor\n\nOn Wed, 2015-01-28 at 17:40 +0100, Daniele Venzano wrote:\n> Hello everyone,\n> \n> there is already some code in our repository:\n> https://github.com/bigfootproject/savanna-image-elements\n> \n> I did the necessary changes to have the Spark element use the cdh5\n> element. I updated also to Spark 1.2. The old cloudera HDFS-only\n> element is still needed for generating cdh4 images (but probably cdh4\n> support can be thrown away).\n> \n> Unfortunately I do not have the time to do the necessary\n> testing/validation and submit for review. I also changed the CDH\n> element so that it can install only HDFS, if so required.\n> The changes I made are simple and all contained in the last commit on\n> the master branch of that repo.\n> \n> The image generated with this code runs in Sahara without any further\n> changes. Feel free to take the code, clean it up and submit for review.\n> \n> Dan\n> \n> On Wed, Jan 28, 2015 at 10:43:30AM -0500, Trevor McKay wrote:\n> > Intel folks,\n> > \n> > Belated welcome to Sahara!  Thank you for your recent commits.\n> > \n> > Moving this thread to openstack-dev so others may contribute, cc\'ing\n> > Daniele and Pietro who pioneered the Spark plugin.\n> > \n> > I\'ll respond with another email about Oozie work, but I want to\n> > address the Spark/Swift issue in CDH since I have been working\n> > on it and there is a task which still needs to be done -- that\n> > is to upgrade the CDH version in the spark image and see if\n> > the situation improves (see below)\n> > \n> > Relevant reviews are here:\n> > \n> > https://review.openstack.org/146659\n> > https://review.openstack.org/147955\n> > https://review.openstack.org/147985\n> > https://review.openstack.org/146659\n> > \n> > In the first review, you can see that we set an extra driver\n> > classpath to pull in \'/usr/lib/hadoop/lib/jackson-core-asl-1.8.8.jar.\n> > \n> > This is because the spark-assembly JAR in CDH4 contains classes from\n> > jackson-mapper-asl-1.8.8 and jackson-core-asl-1.9.x. When the\n> > hadoop-swift.jar dereferences a Swift path, it calls into code\n> > from jackson-mapper-asl-1.8.8 which uses JsonClass.  But JsonClass\n> > was removed in jackson-core-asl-1.9.x, so there is an exception.\n> > \n> > Therefore, we need to use the classpath to either upgrade the version of\n> > jackson-mapper-asl to 1.9.x or downgrade the version of jackson-core-asl\n> > to 1.8.8 (both work in my testing).  However, the first of these options\n> > requires us to bundle an extra jar.  Since /usr/lib/hadoop already\n> > contains jackson-core-asl-1.8.8, it is easier to just add that to the\n> > classpath and downgrade the jackson version.\n> > \n> > Note, there are some references to this problem on the spark mailing list,\n> > we are not the only ones to encounter it.\n> > \n> > However, I am not completely comfortable with mixing versions and\n> > patching the classpath this way.  It looks to me like the Spark assembly\n> > used in CDH5 has consistent versions, and I would like to try updating\n> > the CDH version in sahara-image-elments to CDH5 for Spark. If this fixes\n> > the problem and removes the need for the extra classpath, that would be\n> > great.\n> > \n> > Would someone like to take on this change? (modifying sahara-image-elements\n> > to use CDH5 for Spark images) I can make a blueprint for\n> > it.\n> > \n> > More to come about Oozie topics.\n> > \n> > Best regards,\n> > \n> > Trevor\n> > \n> > On Thu, 2015-01-15 at 15:34 +0000, Chen, Weiting wrote:\n> > > Hi Mckay.\n> > > \n> > >  \n> > > \n> > > We are Intel team and contributing OpenStack Sahara project.\n> > > \n> > > We are new in Sahara and would like to do more contributions in this\n> > > project.\n> > > \n> > > So far, we are focusing on Sahara CDH Plugin.\n> > > \n> > > So if there is any issues related on this, please feel free to discuss\n> > > with us.\n> > > \n> > >  \n> > > \n> > > During IRC meeting, there are two issues you mentioned and we would\n> > > like to discuss with you.\n> > > \n> > > 1.      Oozie Workflow Support: \n> > > \n> > > Do you have any plan could share with us about your idea?\n> > > \n> > > Because in our case, we are testing to run a java action job with\n> > > HBase library support and also facing some problems about Oozie\n> > > support.\n> > > \n> > > So it should be good to share the experience with each other.\n> > > \n> > > \n> > > \n> > > 2.      Spark CDH Issues: \n> > > \n> > > Could you provide more information about this issue? In CDH Plugin, we\n> > > have used CDH 5 to finish swift test. So it should be fine to upgrade\n> > > CDH 4 to 5.\n> > > \n> > >  \n> > > \n> > > \n> > \n> > \n> > \n> \n\n\n\n\n','<20150128164009.GE17787@brownhat.eu>',NULL),('<1422470787-sup-2541@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 10:47:38',-28800,'2015-01-28 18:47:38',NULL,'[openstack-dev] [Heat] core team changes','Excerpts from Angus Salkeld\'s message of 2015-01-27 17:36:41 -0800:\n> Hi all\n> \n> After having a look at the stats:\n> http://stackalytics.com/report/contribution/heat-group/90\n> http://stackalytics.com/?module=heat-group&metric=person-day\n> \n> I\'d like to propose the following changes to the Heat core team:\n> \n> Add:\n> Qiming Teng\n> Huang Tianhua\n> \n> Remove:\n> Bartosz G?rski (Bartosz has indicated that he is happy to be removed and\n> doesn\'t have the time to work on heat ATM).\n> \n> Core team please respond with +/- 1.\n> \n\nI think I\'m far enough removed from day to day reviewing of Heat that you\ncan remove me from the core team as well. I really haven\'t been able to\nfocus on Heat directly lately, and thus I don\'t have any idea of Qiming\nand Huang are suitable for core reviewer status.\n\n\n','<CAA16xcxdrVXTQ9_cuVwHgPb9BbK2Df7uX-7rOZ__O+r2UNhbQA@mail.gmail.com>',NULL),('<1422472308.291492.220131089.491E9AC8@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 14:11:48',-18000,'2015-01-28 19:11:48',NULL,'[openstack-dev] oslo.vmware 0.9.0 released','This release is breaking the stable/juno jobs, so we\'re putting a cap on\nthe library version in juno.\n\nhttps://review.openstack.org/#/c/150919/\n\nOn Wed, Jan 28, 2015, at 12:53 PM, Doug Hellmann wrote:\n> The Oslo team is pleased to announce the release of:\n> \n> oslo.vmware 0.9.0: Oslo VMware library for OpenStack projects\n> \n> The primary reason for this release is to move the code\n> out of the oslo namespace package as part of\n> https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages\n> \n> For more details, please see the git log history below and:\n> \n> http://launchpad.net/oslo.vmware/+milestone/0.9.0\n> \n> Please report issues through launchpad:\n> \n> http://bugs.launchpad.net/oslo.vmware\n> Changes in /home/dhellmann/repos/openstack/oslo.vmware 0.8.0..0.9.0\n> -------------------------------------------------------------------\n> \n> a59c209 Imported Translations from Transifex\n> c51cece Updated from global requirements\n> 9ed4d8a Correct usage to oslo_vmware\n> de27110 Fix line wrapping\n> 3c67c7b Updated from global requirements\n> 95de8ba Correct the doc usage example\n> c4fa9f3 Fix missing project name in installation doc\n> f1dcd53 Imported Translations from Transifex\n> c87b38a Imported Translations from Transifex\n> a229faf Fix race during session creation\n> 2df3a62 Make setup.cfg packages include oslo.vmware\n> a1f0e8c Updated from global requirements\n> 48771e6 Move files out of the namespace package\n> bc6477a Use ToggleLazy fixture from oslo.i18n\n> 84f03f5 Use _is_valid_ipv6 from oslo.utils\n> 93740df Allow checking api session\n> 77dc51e Updated from global requirements\n> e70a057 Updated from global requirements\n> 24681fa Add pbr to installation requirements\n> a251d82 Update urllib3 requirements\n> 3f7a04e Workflow documentation is now in infra-manual\n> 3f842f4 Fix re-create session during transient failures\n> 7c39e50 Imported Translations from Transifex\n> \n> Diffstat (except docs and test files)\n> -------------------------------------\n> \n> CONTRIBUTING.rst                                   |   7 +-\n> HACKING.rst                                        |   5 +-\n> openstack-common.conf                              |   2 +-\n> .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po  |  19 +-\n> .../fr/LC_MESSAGES/oslo.vmware-log-warning.po      |  33 +-\n> oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po   | 161 ++--\n> oslo.vmware/locale/oslo.vmware-log-info.pot        |  19 +-\n> oslo.vmware/locale/oslo.vmware-log-warning.pot     |  31 +-\n> oslo.vmware/locale/oslo.vmware.pot                 | 151 ++--\n> oslo/vmware/__init__.py                            |  26 +\n> oslo/vmware/_i18n.py                               |  35 -\n> oslo/vmware/api.py                                 | 486 +----------\n> oslo/vmware/common/__init__.py                     |   0\n> oslo/vmware/common/loopingcall.py                  | 144 ----\n> oslo/vmware/constants.py                           |  21 +-\n> oslo/vmware/exceptions.py                          | 250 +-----\n> oslo/vmware/image_transfer.py                      | 597 +-------------\n> oslo/vmware/objects/datacenter.py                  |  16 +-\n> oslo/vmware/objects/datastore.py                   | 307 +------\n> oslo/vmware/pbm.py                                 | 189 +----\n> oslo/vmware/rw_handles.py                          | 628 +--------------\n> oslo/vmware/service.py                             | 346 +-------\n> oslo/vmware/vim.py                                 |  39 +-\n> oslo/vmware/vim_util.py                            | 475 +----------\n> oslo/vmware/wsdl/5.5/core-types.xsd                | 242 ------\n> oslo/vmware/wsdl/5.5/pbm-messagetypes.xsd          | 155 ----\n> oslo/vmware/wsdl/5.5/pbm-types.xsd                 | 729\n> -----------------\n> oslo/vmware/wsdl/5.5/pbm.wsdl                      | 889\n> ---------------------\n> oslo/vmware/wsdl/5.5/pbmService.wsdl               |  16 -\n> oslo_vmware/__init__.py                            |   0\n> oslo_vmware/_i18n.py                               |  35 +\n> oslo_vmware/api.py                                 | 490 ++++++++++++\n> oslo_vmware/common/__init__.py                     |   0\n> oslo_vmware/common/loopingcall.py                  | 144 ++++\n> oslo_vmware/constants.py                           |  32 +\n> oslo_vmware/exceptions.py                          | 261 ++++++\n> oslo_vmware/image_transfer.py                      | 608 ++++++++++++++\n> oslo_vmware/objects/__init__.py                    |   0\n> oslo_vmware/objects/datacenter.py                  |  27 +\n> oslo_vmware/objects/datastore.py                   | 318 ++++++++\n> oslo_vmware/pbm.py                                 | 200 +++++\n> oslo_vmware/rw_handles.py                          | 632 +++++++++++++++\n> oslo_vmware/service.py                             | 357 +++++++++\n> oslo_vmware/vim.py                                 |  50 ++\n> oslo_vmware/vim_util.py                            | 486 +++++++++++\n> oslo_vmware/wsdl/5.5/core-types.xsd                | 242 ++++++\n> oslo_vmware/wsdl/5.5/pbm-messagetypes.xsd          | 155 ++++\n> oslo_vmware/wsdl/5.5/pbm-types.xsd                 | 729\n> +++++++++++++++++\n> oslo_vmware/wsdl/5.5/pbm.wsdl                      | 889\n> +++++++++++++++++++++\n> oslo_vmware/wsdl/5.5/pbmService.wsdl               |  16 +\n> requirements-py3.txt                               |   8 +-\n> requirements.txt                                   |  11 +-\n> setup.cfg                                          |   2 +\n> tox.ini                                            |   3 +-\n> 76 files changed, 9038 insertions(+), 5887 deletions(-)\n> \n> Requirements updates\n> --------------------\n> \n> diff --git a/requirements-py3.txt b/requirements-py3.txt\n> index b14f525..8988bcb 100644\n> --- a/requirements-py3.txt\n> +++ b/requirements-py3.txt\n> @@ -14,2 +14,2 @@ six>=1.7.0\n> -oslo.i18n>=1.0.0  # Apache-2.0\n> -oslo.utils>=1.0.0                       # Apache-2.0\n> +oslo.i18n>=1.3.0  # Apache-2.0\n> +oslo.utils>=1.2.0                       # Apache-2.0\n> @@ -22 +22 @@ suds-jurko>=0.6\n> -eventlet>=0.15.2\n> +eventlet>=0.16.1\n> @@ -24 +24 @@ requests>=2.2.0,!=2.4.0\n> -urllib3>=1.7.1\n> +urllib3>=1.8.3\n> diff --git a/requirements.txt b/requirements.txt\n> index 6939fd3..dfb723a 100644\n> --- a/requirements.txt\n> +++ b/requirements.txt\n> @@ -4,0 +5,2 @@\n> +pbr>=0.6,!=0.7,<1.0\n> +\n> @@ -14,2 +16,2 @@ six>=1.7.0\n> -oslo.i18n>=1.0.0  # Apache-2.0\n> -oslo.utils>=1.0.0                       # Apache-2.0\n> +oslo.i18n>=1.3.0  # Apache-2.0\n> +oslo.utils>=1.2.0                       # Apache-2.0\n> @@ -22 +24 @@ suds>=0.4\n> -eventlet>=0.15.2\n> +eventlet>=0.16.1\n> @@ -24 +26,2 @@ requests>=2.2.0,!=2.4.0\n> -urllib3>=1.7.1\n> +urllib3>=1.8.3\n> +oslo.concurrency>=1.4.1         # Apache-2.0\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<8AA96792-2D2E-41A0-9985-F47730DB1981@doughellmann.com>',NULL),('<1422472428.6760.0.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 13:13:48',-21600,'2015-01-28 19:13:48',NULL,'[openstack-dev] [nova] Nominating Melanie Witt for\n python-novaclient-core','On Tue, 2015-01-27 at 14:41 -0800, Michael Still wrote:\n> I would like to nominate Melanie Witt for the python-novaclient-core\n> team.\n\nI +1 this?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAEd1pt7rhzxiyDkPgu=Ftsw=vxEVJhoELXhuSjxrMoHc-v+XXg@mail.gmail.com>',NULL),('<1422472983.6760.4.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 13:23:03',-21600,'2015-01-28 19:23:03',NULL,'[openstack-dev] design question : green thread model','On Wed, 2015-01-28 at 22:48 +0530, murali reddy wrote:\n> On hosts with multi-core processors, it does not seem optimal to run a\n> single service instance with just green thread. I understand that on\n> controller node, we can run one or more nova services but still it\n> does not seem to utilize multi-core processors.\n\nIt\'s also worth pointing out that Python itself isn\'t all that\nparallelizable, even using the core threading packages.  (See [1] for a\nwrite-up about the main block for multiple core utilization in Python,\nnamely the GIL.)  The upshot is that this is why some components like\nnova-api have the capability to fork; but the other components that use\ngreen threads are largely IO-bound, so threading based on IO call\nblocking makes sense there.\n\n[1] https://wiki.python.org/moin/GlobalInterpreterLock\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<CAP95EB+QyfaSOv2LA_3WTsZjVQ-TokC+qpvYpP9jcjO-i4K7Dw@mail.gmail.com>',NULL),('<1422488351-sup-6874@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 15:40:18',-28800,'2015-01-28 23:40:18',NULL,'[openstack-dev] [oslo.db] PyMySQL review','Excerpts from Johannes Erdfelt\'s message of 2015-01-28 15:33:25 -0800:\n> On Wed, Jan 28, 2015, Mike Bayer <mbayer at redhat.com> wrote:\n> > I can envision turning this driver into a total monster, adding\n> > C-speedups where needed but without getting in the way of async\n> > patching, adding new APIs for explicit async, and everything else.\n> > However, I?ve no idea what the developers have an appetite for.\n> \n> This is great information. I appreciate the work on evaluating it.\n> \n> Can I bring up the alternative of dropping eventlet and switching to\n> native threads?\n> \n> We spend a lot of time working on the various incompatibilies between\n> eventlet and other libraries we use. It also restricts us by making it\n> difficult to use an entire class of python modules (that use C\n> extensions for performance, etc).\n> \n> I personally have spent more time than I wish to admit fixing bugs in\n> eventlet and troubleshooting problems we\'ve had.\n> \n> And it\'s never been clear to me why we *need* to use eventlet or\n> green threads in general.\n> \n> Our modern Nova appears to only be weakly tied to eventlet and greenlet.\n> I think we would spend less time replacing eventlet with native threads\n> than we\'ll spend in the future trying to fit our code and dependencies\n> into the eventlet shaped hole we currently have.\n> \n> I\'m not as familiar with the code in other OpenStack projects, but from\n> what I have seen, they appear to be similar to Nova and are only weakly\n> tied to eventlet/greenlet.\n\nAs is often the case with threading, a reason to avoid using it is\nthat libraries often aren\'t able or willing to assert thread safety.\n\nThat said, one way to fix that, is to fix those libraries that we do\nwant to use, to be thread safe. :)\n\n\n','<20150128233325.GI16939@sventech.com>',NULL),('<1422489822.363672.220243245.1764593E@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 19:03:42',-18000,'2015-01-29 00:03:42',NULL,'[openstack-dev] [oslo.db] PyMySQL review','\n\nOn Wed, Jan 28, 2015, at 06:50 PM, Johannes Erdfelt wrote:\n> On Wed, Jan 28, 2015, Clint Byrum <clint at fewbar.com> wrote:\n> > As is often the case with threading, a reason to avoid using it is\n> > that libraries often aren\'t able or willing to assert thread safety.\n> > \n> > That said, one way to fix that, is to fix those libraries that we do\n> > want to use, to be thread safe. :)\n> \n> I floated this idea across some coworkers recently and they brought up a\n> similar concern, which is concurrency in general, both within our code\n> and dependencies.\n> \n> I can\'t find many places in Nova (at least) that are concurrent in the\n> sense that one object will be used by multiple threads. nova-scheduler\n> is likely one place. nova-compute would likely be easy to fix if there\n> are any problems.\n> \n> That said, I think the only way to know for sure is to try it out and\n> see. I\'m going to hack up a proof of concept and see how difficult this\n> will be.\n\nI hope someone who was around at the time will chime in with more detail\nabout why green threads were deemed better than regular threads, and I\nlook forward to seeing your analysis of a change. There is already a\nthread-based executor in oslo.messaging, which *should* be usable in the\napplications when you remove eventlet.\n\nDoug\n\n> \n> JE\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20150128235044.GJ16939@sventech.com>',NULL),('<1422508505064.16460@wipro.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-29 05:15:06',0,'2015-01-29 05:15:06',NULL,'[Openstack] Guest to Host works but host to guest does not','Hi Srinivas,\n\nHere are the details:\n\n1) ifconfig -a \n\nroot at controller:/home/ashish# ifconfig -a\nbr-eth2   Link encap:Ethernet  HWaddr 08:00:27:37:ac:ae\n          inet addr:192.168.56.2  Bcast:192.168.56.255  Mask:255.255.255.0\n          inet6 addr: fe80::10e9:c6ff:fec1:ca6c/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1\n          RX packets:13156 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:30363 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:1115044 (1.1 MB)  TX bytes:4070007 (4.0 MB)\n\nbr-int    Link encap:Ethernet  HWaddr a6:11:2a:83:d4:48\n          inet6 addr: fe80::48a9:34ff:fe1c:1a06/64 Scope:Link\n          UP BROADCAST RUNNING  MTU:1500  Metric:1\n          RX packets:750 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:73696 (73.6 KB)  TX bytes:648 (648.0 B)\n\neth0      Link encap:Ethernet  HWaddr 08:00:27:73:0e:0d\n          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0\n          inet6 addr: fe80::a00:27ff:fe73:e0d/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:488 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:571 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:46795 (46.7 KB)  TX bytes:49402 (49.4 KB)\n\neth1      Link encap:Ethernet  HWaddr 08:00:27:37:ac:ae\n          inet6 addr: fe80::a00:27ff:fe37:acae/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n          RX packets:20069 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:31071 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:1695919 (1.6 MB)  TX bytes:4752990 (4.7 MB)\n\nint-br-eth2 Link encap:Ethernet  HWaddr b2:94:ca:76:85:39\n          inet6 addr: fe80::b094:caff:fe76:8539/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:8047 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:217 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:693379 (693.3 KB)  TX bytes:15126 (15.1 KB)\n\nlo        Link encap:Local Loopback\n          inet addr:127.0.0.1  Mask:255.0.0.0\n          inet6 addr: ::1/128 Scope:Host\n          UP LOOPBACK RUNNING  MTU:65536  Metric:1\n          RX packets:526321 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:526321 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:154582422 (154.5 MB)  TX bytes:154582422 (154.5 MB)\n\novs-system Link encap:Ethernet  HWaddr 4a:34:03:77:d9:ad\n          BROADCAST MULTICAST  MTU:1500  Metric:1\n          RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n\nphy-br-eth2 Link encap:Ethernet  HWaddr ba:75:4e:f3:86:fa\n          inet6 addr: fe80::b875:4eff:fef3:86fa/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:217 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:8047 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:15126 (15.1 KB)  TX bytes:693379 (693.3 KB)\n\nqbr222f9329-6d Link encap:Ethernet  HWaddr ce:6b:e3:6e:3b:00\n          inet6 addr: fe80::4ee:8dff:fe45:e64b/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:7660 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:538565 (538.5 KB)  TX bytes:3420 (3.4 KB)\n\nqbr98a6b5f7-65 Link encap:Ethernet  HWaddr 4a:f9:40:e5:be:6b\n          inet6 addr: fe80::9887:cff:fed4:b679/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:712 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:60524 (60.5 KB)  TX bytes:1740 (1.7 KB)\n\nqvb222f9329-6d Link encap:Ethernet  HWaddr ce:6b:e3:6e:3b:00\n          inet6 addr: fe80::cc6b:e3ff:fe6e:3b00/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n          RX packets:7835 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:153 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:673219 (673.2 KB)  TX bytes:10760 (10.7 KB)\n\nqvb98a6b5f7-65 Link encap:Ethernet  HWaddr 4a:f9:40:e5:be:6b\n          inet6 addr: fe80::48f9:40ff:fee5:be6b/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n          RX packets:984 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:96680 (96.6 KB)  TX bytes:4244 (4.2 KB)\n\nqvo222f9329-6d Link encap:Ethernet  HWaddr fe:f0:9b:cc:bc:27\n          inet6 addr: fe80::fcf0:9bff:fecc:bc27/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n          RX packets:153 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:7835 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:10760 (10.7 KB)  TX bytes:673219 (673.2 KB)\n\nqvo98a6b5f7-65 Link encap:Ethernet  HWaddr 6a:67:9c:a9:43:04\n          inet6 addr: fe80::6867:9cff:fea9:4304/64 Scope:Link\n          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1\n          RX packets:63 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:984 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000\n          RX bytes:4244 (4.2 KB)  TX bytes:96680 (96.6 KB)\n\ntap222f9329-6d Link encap:Ethernet  HWaddr fe:16:3e:1e:53:0d\n          inet6 addr: fe80::fc16:3eff:fe1e:530d/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:79 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:142 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:500\n          RX bytes:7412 (7.4 KB)  TX bytes:10708 (10.7 KB)\n\ntap98a6b5f7-65 Link encap:Ethernet  HWaddr fe:16:3e:10:c9:66\n          inet6 addr: fe80::fc16:3eff:fe10:c966/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n          RX packets:23 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:77 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:500\n          RX bytes:2036 (2.0 KB)  TX bytes:4954 (4.9 KB)\n\nvirbr0    Link encap:Ethernet  HWaddr be:2e:88:cd:96:d2\n          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0\n          UP BROADCAST MULTICAST  MTU:1500  Metric:1\n          RX packets:0 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:0\n          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)\n\n2) brctl show\n\nroot at controller:/home/ashish# brctl show\nbridge name     bridge id               STP enabled     interfaces\nqbr222f9329-6d          8000.ce6be36e3b00       no              qvb222f9329-6d\n                                                        tap222f9329-6d\nqbr98a6b5f7-65          8000.4af940e5be6b       no              qvb98a6b5f7-65\n                                                        tap98a6b5f7-65\nvirbr0          8000.000000000000       yes\n\n3) ovs-vsctl show\nroot at controller:/home/ashish# ovs-vsctl show\n1e062790-8818-4b76-ad43-20186b9550f6\n    Bridge \"br-eth2\"\n        Port \"eth1\"\n            Interface \"eth1\"\n        Port \"phy-br-eth2\"\n            Interface \"phy-br-eth2\"\n        Port \"br-eth2\"\n            Interface \"br-eth2\"\n                type: internal\n    Bridge br-int\n        fail_mode: secure\n        Port br-int\n            Interface br-int\n                type: internal\n        Port \"qvo222f9329-6d\"\n            tag: 1\n            Interface \"qvo222f9329-6d\"\n        Port \"int-br-eth2\"\n            Interface \"int-br-eth2\"\n        Port \"tap0b9f0fa0-bc\"\n            tag: 1\n            Interface \"tap0b9f0fa0-bc\"\n                type: internal\n        Port \"qvo98a6b5f7-65\"\n            tag: 1\n            Interface \"qvo98a6b5f7-65\"\n    ovs_version: \"2.0.2\"\n\n4) root at controller:/home/ashish# ovs-ofctl dump-flows br-eth2\nNXST_FLOW reply (xid=0x4):\n cookie=0x0, duration=17240.03s, table=0, n_packets=188, n_bytes=13160, idle_age=30, priority=4,in_port=2,dl_vlan=1 actions=strip_vlan,NORMAL\n cookie=0x0, duration=17252.053s, table=0, n_packets=31, n_bytes=2558, idle_age=17192, priority=2,in_port=2 actions=drop\n cookie=0x0, duration=17252.933s, table=0, n_packets=50500, n_bytes=5784007, idle_age=0, priority=1 actions=NORMAL\n\nroot at controller:/home/ashish# ovs-ofctl dump-flows br-int\nNXST_FLOW reply (xid=0x4):\n cookie=0x0, duration=17258.668s, table=0, n_packets=8124, n_bytes=699836, idle_age=0, priority=3,in_port=1,vlan_tci=0x0000 actions=mod_vlan_vid:1,NORMAL\n cookie=0x0, duration=17270.823s, table=0, n_packets=7, n_bytes=578, idle_age=17264, priority=2,in_port=1 actions=drop\n cookie=0x0, duration=17272.667s, table=0, n_packets=245, n_bytes=18394, idle_age=49, priority=1 actions=NORMAL\n cookie=0x0, duration=17272.383s, table=22, n_packets=0, n_bytes=0, idle_age=17272, priority=0 actions=drop\n\n\nThanks for all your help!\n\nRegards\nAshish\n\n\nFrom: Srinivasreddy R <srinivasreddy4390 at gmail.com>\nSent: Wednesday, January 28, 2015 11:09 AM\nTo: Ashish Jain (WT01 - BAS)\nSubject: Re: [Openstack] Guest to Host works but host to guest does not\n? \n\n\nhi ashish,\n\n\ncan you give \n1.ifconfig -a\n2.brctl show\n3. ovs-vsctl show\n4.ovs-ofctl dump-flows <bridges>\n\n\nregards\nSrinivas.\n\n\n\n \n\n\nOn Wed, Jan 28, 2015 at 10:37 AM, <ashish.jain14 at wipro.com> wrote:\n\n\nHi Srinivas,\n\n\nThis is a single VM setup this means all the components are installed on the same VM. This VM has got 2 ethernet interfaces eth0 and eth1. Access to TCP/22 is already enabled as you can see from \n nova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535  0.0.0.0/0\n\n\n Regards\nAshish\n\n\n\n\n\nFrom: Srinivasreddy R <srinivasreddy4390 at gmail.com>\nSent: Wednesday, January 28, 2015 12:03 AM\nTo: Ashish Jain (WT01 - BAS)\nSubject: Re: [Openstack] Guest to Host works but host to guest does not\n? \n\n\n\ni think you cannot access VM from compute node or controller .\ninsted you can loging through external network [need to enable tcp/22, icmp rules in security group rules ].A pc connected to br-ex via an external physical interface in controller node .\n\n\nregards,\nsrinivas.\n\n\n\n\nOn Tue, Jan 27, 2015 at 10:30 PM, <ashish.jain14 at wipro.com> wrote:\n Hi,\n\n?I am unable to ping/ssh from my host VM to guest VM.? However opposite works just fine, that is I am able to ping from guest? to host VM. Currently I am accessing my guest from horizon console and? have tried pinging/sshing into my host VM and it works just  fine. I have? also tried using network namespace to ping from host to guest but it? does not work. I am using? neutron network.\n\nI have already enabled ICMP/TCP/UDP port access using the following\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default tcp 1 65535  0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default udp 1 65535  0.0.0.0/0\n\nnova --os-tenant-name TenantA --os-username UserA --os-password password --os-auth-url=http://localhost:5000/v2.0 \\\nsecgroup-add-rule default icmp -1 -1 0.0.0.0/0\n\nAny pointers would be helpful.\n\nThanks\nAshish\n\n\n\n_______________________________________________\nMailing list:  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? ?: openstack at lists.openstack.org\nUnsubscribe :  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n \n\n\n\n -- \n\n\nthanks\nsrinivas.             \n\n\n-- \n\n\nthanks\nsrinivas.       \n\n','<CAJP4VWiX5wsKi_f9-QiQ6YVSjfG7jRRVTMpUOrqyNP+yGY87xg@mail.gmail.com>',NULL),('<1422522847.11916.57.camel@scality.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 10:14:07',3600,'2015-01-29 09:14:07',NULL,'[openstack-dev] [Swift] Swift GUI (free or open source)?','On Wed, 2015-01-28 at 17:35 -0800, Adam Lawson wrote:\n> Okay cool beans. Incidentally, are there any efforts out there going\n> through the motions that you know about (even abandoned)? I\'d be willing to\n> prop them a bit if they\'re low on development resources..\n\nI don\'t know of any such project(s), but I\'d be very interested in this\nas well.\n\nNicolas\n\n\n\n','<CAJfWK49LofPLFynmg+3tuYC7=sTk-rcDMUOgOLSXxs6zTFojkQ@mail.gmail.com>',NULL),('<1422539366.578539.220484533.7BF9198F@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 08:49:26',-18000,'2015-01-29 13:49:26',NULL,'[openstack-dev] [oslo.db] PyMySQL review','\n\nOn Wed, Jan 28, 2015, at 07:57 PM, Johannes Erdfelt wrote:\n> On Wed, Jan 28, 2015, Vishvananda Ishaya <vishvananda at gmail.com> wrote:\n> > On Jan 28, 2015, at 4:03 PM, Doug Hellmann <doug at doughellmann.com> wrote:\n> > > I hope someone who was around at the time will chime in with more detail\n> > > about why green threads were deemed better than regular threads, and I\n> > > look forward to seeing your analysis of a change. There is already a\n> > > thread-based executor in oslo.messaging, which *should* be usable in the\n> > > applications when you remove eventlet.\n> > \n> > Threading was never really considered. The initial version tried to get a\n> > working api server up as quickly as possible and it used tonado. This was\n> > quickly replaced with twisted since tornado was really new at the time and\n> > had bugs. We then switched to eventlet when swift joined the party so we\n> > didn?t have multiple concurrency stacks.\n> > \n> > By the time someone came up with the idea of using different concurrency\n> > models for the api server and the backend services, we were already pretty\n> > far down the greenthread path.\n> \n> Not sure if it helps more than this explanation, but there was a\n> blueprint and accompanying wiki page that explains the move from twisted\n> to eventlet:\n> \n> https://blueprints.launchpad.net/nova/+spec/unified-service-architecture\n> \n> https://wiki.openstack.org/wiki/UnifiedServiceArchitecture\n\nThanks Vish & Johannes, that\'s good background. There are a lot of\nfactors to consider, and having a full picture of the history of how we\ngot to where we are will help us make informed decisions about any\nproposed changes.\n\nDoug\n\n> \n> JE\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20150129005716.GK16939@sventech.com>',NULL),('<1422548657.629289.220556049.50170E05@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 11:24:17',-18000,'2015-01-29 16:24:17',NULL,'[openstack-dev] [oslo] Why are we continuing to add new\n namespaced oslo libs?','\n\nOn Thu, Jan 29, 2015, at 11:03 AM, Thomas Goirand wrote:\n> On 01/24/2015 02:01 AM, Doug Hellmann wrote:\n> > \n> > \n> > On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:\n> >> Hi,\n> >>\n> >> I\'ve just noticed that oslo.log made it to global-requirements.txt 9\n> >> days ago. How come are we still adding some name.spaced oslo libs?\n> >> Wasn\'t the outcome of the discussion in Paris that we shouldn\'t do that\n> >> anymore, and that we should be using oslo-log instead of oslo.log?\n> >>\n> >> Is three something that I am missing here?\n> >>\n> >> Cheers,\n> >>\n> >> Thomas Goirand (zigo)\n> > \n> > The naming is described in the spec:\n> > http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html\n> > \n> > tl;dr - We did it this way to make life easier for the packagers.\n> > \n> > Doug\n> \n> Hi Doug,\n> \n> Sorry for the late reply.\n> \n> Well, you\'re not making the life of *package maintainers* more easy,\n> that\'s in fact the opposite way, I\'m afraid.\n> \n> The Debian policy is that Python module packages should be named after\n> the import statement in a source file. Meaning that if we do:\n> \n> import oslo_db\n> \n> then the package should be called python-oslo-db. This means that I will\n> have to rename all the Debian packages to remove the dot and put a dash\n> instead. But by doing so, if OpenStack upstream is keeping the old\n> naming convention, then all the requirements.txt will be \"wrong\" (by\n> wrong, I mean from my perspective as a package maintainer), and the\n> automated dependency calculation of dh_python2 will put package names\n> with dots instead of dashes.\n> \n> So, what is going to happen, is that I\'ll have to, for each and every\n> package, build a dictionary of translations in debian/pydist-overrides.\n\nThat\'s unfortunate, but you\'re the only packager who seems to have this\nissue.\n\nI\'ve already spent 2 months more time working on this transition than I\nplanned, so I\'m not planning to do anything else disruptive with it this\ncycle. If it remains a problem, or some of the other packagers support\nrenaming the packages, we can discuss it at the L summit to be done\nduring the L cycle.\n\nDoug\n\n> For example:\n> \n> # cat debian/pydist-overrides\n> oslo.db python-oslo-db\n> \n> This is very error prone, and I may miss lots of dependencies this way,\n> leading to the packages having wrong dependencies. I have a way to avoid\n> the issue, which would be to add a Provides: python-oslo.db in the\n> python-oslo-db package, but this should only be considered as a\n> transition thing.\n> \n> Also, as a side note, but it may be interesting for some: the package\n> python-oslo-db should have Breaks: python-oslo.db (<< OLD_VERSION) and\n> Replaces: (<< OLD_VERSION), as otherwise upgrades will simply fail\n> (because 2 different packages can\'t contain the same files on the\n> filesystem).\n> \n> So if you really want to make our lives more easy, please do the full\n> migration, and move completely away from dots.\n> \n> Also, I\'d like to tell you that I feel very sorry that I couldn\'t attend\n> the session about the oslo namespace in Paris. I was taken by my company\n> to a \"culture building\" session all the afternoon. After reading the\n> above, I feel sorry that I didn\'t attend the namespace session instead.\n> :(\n> \n> Cheers,\n> \n> Thomas Goirand (zigo)\n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54CA59C4.4050202@debian.org>',NULL),('<1422553355-sup-1638@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 09:51:32',-28800,'2015-01-29 17:51:32',NULL,'[openstack-dev] [Heat][Keystone] Native keystone resources in\n	Heat','Excerpts from Zane Bitter\'s message of 2015-01-29 08:41:36 -0800:\n> I got a question today about creating keystone users/roles/tenants in \n> Heat templates. We currently support creating users via the \n> AWS::IAM::User resource, but we don\'t have a native equivalent.\n> \n> IIUC keystone now allows you to add users to a domain that is otherwise \n> backed by a read-only backend (i.e. LDAP). If this means that it\'s now \n> possible to configure a cloud so that one need not be an admin to create \n> users then I think it would be a really useful thing to expose in Heat. \n> Does anyone know if that\'s the case?\n> \n\nI think you got that a little backward. Keystone lets you have domains\nthat are read/write, and domains that are read-only. So you can have\n\"the real users\" in LDAP and then give a different class of user their\nown keystone-only domain that they can control.\n\nThat is a bit confusing to the real functionality gap, which I think\nis a corner case but worth exploring. Being able to create a user in a\ndomain that the user provides credentials for is a useful thing. A user\nmay want to deploy their own instance control mechanism (like standalone\nHeat!) for instance, and having a limited-access user for this created\nby a domain admin with credentials that are only ever stored in Heat\nseems like a win. Some care is needed to make sure the role can\'t just\n\'stack show\' on Heat and grab the admin creds, but that seems like\nsomething that would go in a deployer guide.. something like \"Make sure\ndomain admins know not to give delegated users the \'heat-user\' role.\"\n\n> I think roles and tenants are likely to remain admin-only, but we have \n> precedent for including resources like that in /contrib... this seems \n> like it would be comparably useful.\n> \n\nI feel like admin-only things will matter as soon as real multi-cloud\nsupport exists in Heat. What I really want is to have a Heat in my\nmanagement cloud that reaches into my managed cloud when necessary.\nRight now in TripleO we have to keep anything admin-only out of the\nHeat templates and run the utilities from os-cloud-config \"somewhere\"\nbecause we don\'t want admin credentials (even just trusts) in Heat. But\nif we could use the deployment(under) cloud\'s Heat to reach into the\nuser(over) cloud to add users, roles, networks, etc., then that would\nmaintain the separation our security auditors desire.\n\n\n','<54CA62C0.8090909@redhat.com>',NULL),('<1422556327-sup-5080@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 10:35:10',-28800,'2015-01-29 18:35:10',NULL,'[openstack-dev] [oslo.db] PyMySQL review','Excerpts from Vishvananda Ishaya\'s message of 2015-01-29 10:21:58 -0800:\n> \n> On Jan 29, 2015, at 8:57 AM, Roman Podoliaka <rpodolyaka at mirantis.com> wrote:\n> \n> > Jeremy,\n> > \n> > I don\'t have exact numbers, so yeah, it\'s just an assumption based on\n> > looking at the nova-api/scheduler logs with connection_debug set to\n> > 100.\n> > \n> > But that\'s a good point you are making here: it will be interesting to\n> > see what difference enabling of PyMySQL will make for tempest/rally\n> > workloads, rather than just running synthetic tests. I\'m going to give\n> > it a try on my devstack installation.\n> \n> \n> FWIW I tested this a while ago on some perf tests on nova and cinder that we\n> run internally and I found pymysql to be slower by about 10%. It appears that\n> we were cpu bound in python more often than we were blocking talking to the\n> db. I do recall someone doing a similar test in neutron saw some speedup,\n> however. On our side we also exposed a few race conditions which made it less\n> stable. We hit a few hard deadlocks in volume create IIRC. \n> \n> I don?t think switching is going to give us much benefit right away. We will\n> need a few optimizations and bugfixes in other areas (particularly in our\n> sqlalchemy usage) before we will derive any benefit from the switch.\n> \n\nNo magic bullets, right? I think we can all resolve this statement in\nour heads though: \"fast and never concurrent\" will eventually lose to\n\"concurrent and potentially fast with optimizations.\"\n\nThe question is, how long does the hare (python-mysqldb) have to sleep\nbefore the tortoise (PyMySQL) wins? Right now it\'s still a close race, but\nif the tortoise even gains 10% speed, it likely becomes no contest at all.\n\n\n','<9BDA4651-548A-453C-B299-E4A196AEABED@gmail.com>',NULL),('<1422559184.685772.220637069.3439DC4A@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-29 14:19:44',-18000,'2015-01-29 19:19:44',NULL,'[openstack-dev] [barbican] python-barbicanclient 3.0.2 released','\n\nOn Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote:\n> On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague <sean at dague.net> wrote:\n> \n> > So, honestly, yes.\n> >\n> > For a library to release safely it must:\n> >\n> > * have stable-compat jobs running (this was the issue with barbican client)\n> > * if it has a stable/juno branch it must be pinned in stable/juno (this\n> > was the issue on most of the oslo libs)\n> >\n> \n> We use the clients for two very different things.\n> \n> 1. As a python library to communicate between services\n> 2. A command line tool that can talk to all supported versions of our\n> APIs\n> (stable/icehouse, stable/juno and master).\n> \n> With our current testing setup, we try using the latest release on stable\n> branches for both 1. and 2.  That means clients need overlapping\n> dependencies with the stable branches.   I don\'t think this is a\n> reasonable\n> requirement, and am not sure what we gain from it.\n> \n> Instead I propose we pin the client version for 1 and use the latest\n> release for 2.  We should be able to do this easily by putting all\n> command\n> line tools inside of venvs using pipsi[0]. This way we continue to test\n> the\n> clients API compatibility with stable branches without requiring\n> dependency\n> compatibility (I roped Dean Troyer into working on this at the nova mid\n> cycle).\n> \n> Once this is done, we should be able to go ahead and pin all explicit\n> dependencies on stable branches [1].\n\n++\n\nThanks to both of you for working on this!\n\nDoug\n\n> \n> [0] https://pypi.python.org/pypi/pipsi/0.8\n> [1] https://review.openstack.org/#/c/147451/\n> \n> \n> >\n> >         -Sean\n> >\n> > On 01/29/2015 12:07 PM, Kyle Mestery wrote:\n> > > Maybe we should defer all client releases until we know for sure if each\n> > > of them are ticking timebombs.\n> > >\n> > > On Thu, Jan 29, 2015 at 11:00 AM, Morgan Fainberg\n> > > <morgan.fainberg at gmail.com <mailto:morgan.fainberg at gmail.com>> wrote:\n> > >\n> > >     Good question! I was planning a keystone liens release very soon,\n> > >     but will hold off of it will break everything.\n> > >\n> > >     --Morgan\n> > >\n> > >\n> > >     On Thursday, January 29, 2015, Thierry Carrez <thierry at openstack.org\n> > >     <mailto:thierry at openstack.org>> wrote:\n> > >\n> > >         Sean Dague wrote:\n> > >         > On 01/27/2015 05:21 PM, Sean Dague wrote:\n> > >         >> On 01/27/2015 03:55 PM, Douglas Mendizabal wrote:\n> > >         >>> Hi openstack-dev,\n> > >         >>>\n> > >         >>> The barbican team would like to announce the release of\n> > >         >>> python-barbicanclient 3.0.2.  This is a minor release that\n> > >         fixes a bug\n> > >         >>> in the pbr versioning that was preventing the client from\n> > >         working correctly.\n> > >         >>>\n> > >         >>> The release is available on PyPI\n> > >         >>>\n> > >         >>> https://pypi.python.org/pypi/python-barbicanclient/3.0.2\n> > >         >>\n> > >         >> Which just broke everything, because it creates incompatible\n> > >         >> requirements in stable/juno with cinder. :(\n> > >         >\n> > >         > Here is the footnote -\n> > >         >\n> > >\n> > http://logs.openstack.org/18/150618/1/check/check-grenade-dsvm/c727602/logs/grenade.sh.txt.gz#_2015-01-28_00_04_54_429\n> > >\n> > >         This seems to have been caused by this requirements sync:\n> > >\n> > >\n> > http://git.openstack.org/cgit/openstack/python-barbicanclient/commit/requirements.txt?id=054d81fb63053c3ce5f1c87736f832750f6311b3\n> > >\n> > >         but then the same requirements sync happened in all other\n> > clients:\n> > >\n> > >\n> > http://git.openstack.org/cgit/openstack/python-novaclient/commit/requirements.txt?id=17367002609f011710014aef12a898e9f16db81c\n> > >\n> > >         Does that mean that all the clients are time bombs that will\n> > break\n> > >         stable/juno when their next release is tagged ?\n> > >\n> > >         --\n> > >         Thierry Carrez (ttx)\n> > >\n> > >\n> > >\n> >  __________________________________________________________________________\n> > >     OpenStack Development Mailing List (not for usage questions)\n> > >     Unsubscribe:\n> > >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > >     <\n> > http://OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>\n> > >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > >\n> > >\n> > >\n> > >\n> > __________________________________________________________________________\n> > > OpenStack Development Mailing List (not for usage questions)\n> > > Unsubscribe:\n> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> >\n> > --\n> > Sean Dague\n> > http://dague.net\n> >\n> >\n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAHXdxOfDg+FZK_qTqGBrf53GkGe6HBER6TuuS0GnKeCg6DStZQ@mail.gmail.com>',NULL),('<1422576152.8846.65.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-29 16:02:32',-28800,'2015-01-30 00:02:32',NULL,'[Openstack] [All] Summit Session Proposal Voting','\nOn Wed, 2015-01-28 at 09:27 -0600, John Griffith wrote:\n> You are exactly correct Thierry, being a track chair a few times in\n> the process has been something like:\n> * PIck a cut off based on votes\n> * Review remaining submissions as a panel\n\nI followed a different process when I\'ve been track-chair, one that\ndoesn\'t look much at the results of public voting:\n\n - Establish a \"Theme\" with fellow co-chair, a sort of objective for the\ntracks we want to have presented to the public. \n - Ignore the popularFor example, I look at the popularity of videos in\nthe tracks I chaired as feedbackFor example, I look at the popularity of\nvideos in the tracks I chaired as feedbackity contest\n - Evaluate every single proposal submitted against the objective\ndefined above\n - Rank the  proposals\n - Look at the results of the popularity contest to unblock difficult\ndecisions and disagreements.\n\nAll track chairs are instructed to look at the results of the voting\nsessions but not to consider those more than another tool to help them\nmake hard decisions. For example, I also looked at the popularity of\nrecorded videos to gauge the interests in a topic or the skills of a\nspeaker.\n\nThe public voting gets people to talk about the summit, gives them an\nexcuse to promote their creations and ultimately is fun. It\'s not meant\nto be serious otherwise it would be work :)\n\n/stef\n\n\n\n\n','<CA+qL3LViGX7urmorKokC2KT7-j6ajpBMiOg27zC1pBg1ky=PQQ@mail.gmail.com>',NULL),('<1422614768.7371.15.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-30 02:46:08',-28800,'2015-01-30 10:46:08',NULL,'[OpenStack Foundation] Finding people to work on the EC2 API in\n Nova','On Thu, 2015-01-29 at 16:01 -0800, Michael Still wrote:\n> However, we got here because no one is maintaining the code in Nova\n> for the EC2 API. This is despite repeated calls over the last 18\n> months (at least).\n\nI\'d love to get to the root cause before we jump to look for solutions.\nThe story we hear is that EC2 is important and according to the user\nsurvey there are users that seem to be using OpenStack\'s EC2 code. Nova\ndevelopers point out though that the EC2 code is broken and unusable. So\nsomething is out of whack: either user report are more \'wishes\' than\nusage or the openstack code is not as bad or someone else is feeding\nthese users good code (that is not in openstack repositories) or\nsomething else.\n\nI would suggest that we start by reaching out to these users. \n\nWhich questions shall we ask them? I\'d start from:\n\n* where did you get the EC2 API: vanilla openstack (version, etc) or via\na vendor? which vendor?\n* how do you use the EC2 code? Anecdotes are enough I think at this\npoint.\n\n\nTim and user committee: do you think I or Tom can get the list of\nrespondents to the user survey who declared to use EC2 so we can ask\nthem more questions?\n\nIf not, we can start by asking on the operators list and blog posts and\nwait for someone to come forward.\n\n\n\n\n\n','<CAEd1pt7d54YfCGZKo3bRtq1LY9k2o=9hheADf=V8VjzpxxCCKQ@mail.gmail.com>',NULL),('<1422614768.7371.15.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 02:46:08',-28800,'2015-01-30 10:46:08',NULL,'[openstack-dev] [OpenStack Foundation] Finding people to work\n on the EC2 API in Nova','On Thu, 2015-01-29 at 16:01 -0800, Michael Still wrote:\n> However, we got here because no one is maintaining the code in Nova\n> for the EC2 API. This is despite repeated calls over the last 18\n> months (at least).\n\nI\'d love to get to the root cause before we jump to look for solutions.\nThe story we hear is that EC2 is important and according to the user\nsurvey there are users that seem to be using OpenStack\'s EC2 code. Nova\ndevelopers point out though that the EC2 code is broken and unusable. So\nsomething is out of whack: either user report are more \'wishes\' than\nusage or the openstack code is not as bad or someone else is feeding\nthese users good code (that is not in openstack repositories) or\nsomething else.\n\nI would suggest that we start by reaching out to these users. \n\nWhich questions shall we ask them? I\'d start from:\n\n* where did you get the EC2 API: vanilla openstack (version, etc) or via\na vendor? which vendor?\n* how do you use the EC2 code? Anecdotes are enough I think at this\npoint.\n\n\nTim and user committee: do you think I or Tom can get the list of\nrespondents to the user survey who declared to use EC2 so we can ask\nthem more questions?\n\nIf not, we can start by asking on the operators list and blog posts and\nwait for someone to come forward.\n\n\n\n\n\n','<CAEd1pt7d54YfCGZKo3bRtq1LY9k2o=9hheADf=V8VjzpxxCCKQ@mail.gmail.com>',NULL),('<1422616359.7371.17.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/community',NULL,'2015-01-30 12:12:39',3600,'2015-01-30 11:12:39',NULL,'[openstack-community] OpenStack Community Weekly Newsletter (Jan 23\n	- 30)','\nWorking to bridge the developer/end-user divide in OpenStack\n\nThe Product Working Group will embark on a listening campaign to improve\ndialogue between developers and their managers.\n\nHow to craft a successful OpenStack Summit proposal\n\nInspiration, tips and a kick in the pants for the Feb. 9 deadline.\n\nAn atomic upgrade process for OpenStack compute nodes\n\nSteve Dake has been involved with the Kolla project, a project to\ncontainerize OpenStack as well as Magnum, a project to provide\ncontainers as a service. In his blog post he talks about containers, how\nthey are are super useful as an upgrade tool for OpenStack.\n\nBuilding a cloud career with OpenStack\n\nWhat can OpenStack do for you? How about helping you along your career?\nOpenStack is a growing space and there are more than enough jobs still\nto go around for qualified seekers. So how do you go about getting one\nof those jobs?\n\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9 ? DEADLINE APPROACHING\n        FAST\n      * Applications for OpenStack Travel Support Program\n      * Vancouver Summit Sponsorships Now Available\n      * Canada Visa Information\n      * Official Hotel Room Blocks\n      * Next batch of invites to Kilo contributors will be sent after a\n        new milestone is released\n\nRelevant Conversations\n\n      * Finding people to work on the EC2 API in Nova\n      * Vancouver Design Summit format changes \n      * do we really need project tags in the governance repository? \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * [neutron] BPs in Launchpad for Kilo-2 \n\nReports From Previous Events\n\n      * OpenStack Nova Mid-cycle Meetup, Day 1\n      * Day One of the OpenStack Product Management Kilo Midcycle\n      * OpenStack Nova Mid-cycle Meetup, Day 2\n      * Day Two of the OpenStack Product Management Kilo Midcycle\n\nSecurity Advisories and Notices\n\n      * Glance user storage quota bypass (CVE-2014-9623) \n\nTips ?n Tricks\n\n      * By Antonio Cimmino: How to install a multi region devstack\n        Part-1\n      * By Tim Bell: Exceeding tracked connections\n      * By Adam Johnson: Scalable open virtual networking with MidoNet\n      * By Christian Berendt: Simple auto scaling environment with Heat\n\nUpcoming Events\n\nThe 2015 events plan is now available on the Global Events Calendar\nwiki.\n\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Swift Feature Highlight - TempURLs\n      * FOSDEM 2015: Where you can learn more about OpenStack\n      * Interview with Kenneth Hui: Involvement with OpenStack, thoughts\n        and future of the Trove project, and more\n      * Why Fuel now runs on Docker\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * How to set up a Federation in Openstack Juno?\n      * Attempt to install Nova-Docker driver on Fedora 21\n      * how to use keyring?\n      * Can\'t get requested routers from kwarg in def sync_routers\n      * VNC port not open in firewall\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150130/ce3a9a8b/attachment-0001.html>\n\n',NULL,NULL),('<1422616359.7371.17.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-announce',NULL,'2015-01-30 12:12:39',3600,'2015-01-30 11:12:39',NULL,'[openstack-announce] OpenStack Community Weekly Newsletter (Jan 23\n	- 30)','\nWorking to bridge the developer/end-user divide in OpenStack\n\nThe Product Working Group will embark on a listening campaign to improve\ndialogue between developers and their managers.\n\nHow to craft a successful OpenStack Summit proposal\n\nInspiration, tips and a kick in the pants for the Feb. 9 deadline.\n\nAn atomic upgrade process for OpenStack compute nodes\n\nSteve Dake has been involved with the Kolla project, a project to\ncontainerize OpenStack as well as Magnum, a project to provide\ncontainers as a service. In his blog post he talks about containers, how\nthey are are super useful as an upgrade tool for OpenStack.\n\nBuilding a cloud career with OpenStack\n\nWhat can OpenStack do for you? How about helping you along your career?\nOpenStack is a growing space and there are more than enough jobs still\nto go around for qualified seekers. So how do you go about getting one\nof those jobs?\n\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9 ? DEADLINE APPROACHING\n        FAST\n      * Applications for OpenStack Travel Support Program\n      * Vancouver Summit Sponsorships Now Available\n      * Canada Visa Information\n      * Official Hotel Room Blocks\n      * Next batch of invites to Kilo contributors will be sent after a\n        new milestone is released\n\nRelevant Conversations\n\n      * Finding people to work on the EC2 API in Nova\n      * Vancouver Design Summit format changes \n      * do we really need project tags in the governance repository? \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * [neutron] BPs in Launchpad for Kilo-2 \n\nReports From Previous Events\n\n      * OpenStack Nova Mid-cycle Meetup, Day 1\n      * Day One of the OpenStack Product Management Kilo Midcycle\n      * OpenStack Nova Mid-cycle Meetup, Day 2\n      * Day Two of the OpenStack Product Management Kilo Midcycle\n\nSecurity Advisories and Notices\n\n      * Glance user storage quota bypass (CVE-2014-9623) \n\nTips ?n Tricks\n\n      * By Antonio Cimmino: How to install a multi region devstack\n        Part-1\n      * By Tim Bell: Exceeding tracked connections\n      * By Adam Johnson: Scalable open virtual networking with MidoNet\n      * By Christian Berendt: Simple auto scaling environment with Heat\n\nUpcoming Events\n\nThe 2015 events plan is now available on the Global Events Calendar\nwiki.\n\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Swift Feature Highlight - TempURLs\n      * FOSDEM 2015: Where you can learn more about OpenStack\n      * Interview with Kenneth Hui: Involvement with OpenStack, thoughts\n        and future of the Trove project, and more\n      * Why Fuel now runs on Docker\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * How to set up a Federation in Openstack Juno?\n      * Attempt to install Nova-Docker driver on Fedora 21\n      * how to use keyring?\n      * Can\'t get requested routers from kwarg in def sync_routers\n      * VNC port not open in firewall\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-announce/attachments/20150130/ce3a9a8b/attachment.html>\n\n',NULL,NULL),('<1422616359.7371.17.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-01-30 12:12:39',3600,'2015-01-30 11:12:39',NULL,'[Openstack-operators] OpenStack Community Weekly Newsletter (Jan 23\n	- 30)','\nWorking to bridge the developer/end-user divide in OpenStack\n\nThe Product Working Group will embark on a listening campaign to improve\ndialogue between developers and their managers.\n\nHow to craft a successful OpenStack Summit proposal\n\nInspiration, tips and a kick in the pants for the Feb. 9 deadline.\n\nAn atomic upgrade process for OpenStack compute nodes\n\nSteve Dake has been involved with the Kolla project, a project to\ncontainerize OpenStack as well as Magnum, a project to provide\ncontainers as a service. In his blog post he talks about containers, how\nthey are are super useful as an upgrade tool for OpenStack.\n\nBuilding a cloud career with OpenStack\n\nWhat can OpenStack do for you? How about helping you along your career?\nOpenStack is a growing space and there are more than enough jobs still\nto go around for qualified seekers. So how do you go about getting one\nof those jobs?\n\n\nThe Road to Vancouver\n\n      * Call For Speakers open until February 9 ? DEADLINE APPROACHING\n        FAST\n      * Applications for OpenStack Travel Support Program\n      * Vancouver Summit Sponsorships Now Available\n      * Canada Visa Information\n      * Official Hotel Room Blocks\n      * Next batch of invites to Kilo contributors will be sent after a\n        new milestone is released\n\nRelevant Conversations\n\n      * Finding people to work on the EC2 API in Nova\n      * Vancouver Design Summit format changes \n      * do we really need project tags in the governance repository? \n\nDeadlines and Development Priorities\n\n      * [Keystone] Spec proposal deadline Feb 5 \n      * [Cinder] Cutoff deadlines for cinder drivers: volume drivers\n        need to have a CI by end of K-3, March 19th 2015\n      * [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th\n        Feb \n      * [neutron] BPs in Launchpad for Kilo-2 \n\nReports From Previous Events\n\n      * OpenStack Nova Mid-cycle Meetup, Day 1\n      * Day One of the OpenStack Product Management Kilo Midcycle\n      * OpenStack Nova Mid-cycle Meetup, Day 2\n      * Day Two of the OpenStack Product Management Kilo Midcycle\n\nSecurity Advisories and Notices\n\n      * Glance user storage quota bypass (CVE-2014-9623) \n\nTips ?n Tricks\n\n      * By Antonio Cimmino: How to install a multi region devstack\n        Part-1\n      * By Tim Bell: Exceeding tracked connections\n      * By Adam Johnson: Scalable open virtual networking with MidoNet\n      * By Christian Berendt: Simple auto scaling environment with Heat\n\nUpcoming Events\n\nThe 2015 events plan is now available on the Global Events Calendar\nwiki.\n\n      * Jan 31 - Feb 01, 2015 FOSDEM Brussels, BE\n      * Feb 02 - 03, 2015 Upstream Training in Japan Tokyo, JP\n      * Feb 02, 2015 OpenStack Seattle Meetup Seattle, WA, US\n      * Feb 03 - 04, 2015 OpenStack Days Tokyo 2015 Tokyo, JP\n      * Feb 05, 2015 OpenStack Day in Korea Seoul, Seoul, KR\n      * Feb 11, 2015 HandsOn Prescriptive Topology Mgr Mountain View,\n        CA, US\n      * Feb 11, 2015 CloudCamp Bangladesh @Digital World Dhaka, BD\n      * Feb 18, 2015 First OpenStack BW Meetup Stuttgart,\n        Baden-W?rttemberg, DE\n      * Feb 19 - 20, 2015 World Techies Forum Mumbai, Maharashtra, IN\n      * Mar 04, 2015 OpenStack Finland meetup Helsinki, Uusimaa, FI\n      * Mar 11 - 12, 2015 Cloud Expo Europe London, GB\n      * Mar 26, 2015 PDX OpenStack Hackathon Portland, OR, US\n      * Apr 08 - 16, 2015 PyCon 2015 Montreal, Quebec, CA\n      * Apr 13 - 14, 2015 OpenStack Live Santa Clara, CA, US\n      * Apr 21 - 22, 2015 CONNECT 2015 Melbourne, Victoria, AU\n      * Apr 22 - 23, 2015 China SDNNFV Conference Beijing, CN\n      * May 05 - 07, 2015 CeBIT AU 2015 Sydney, NSW, AU\n      * May 18 - 22, 2015 OpenStack Summit May 2015 Vancouver, BC\n      * Jun 11, 2015 OpenStack DACH Day 2015 Berlin, DE\n      * Jul 20 - 24, 2015 OSCON 2015 Portland, OR, US\n      * Aug 10 - 13, 2015 Gartner Catalyst Conference San Diego, CA, US\n      * Sep 17, 2015 OpenStack Benelux Conference 2015 Bussum, NL\n      * Oct 04 - 08, 2015 Gartner SymposiumITxpo Orlando, FL, US\n      * Nov 15 - 20, 2015 Supercomputing 15 Austin, TX, US\n\nOther News\n\n      * Swift Feature Highlight - TempURLs\n      * FOSDEM 2015: Where you can learn more about OpenStack\n      * Interview with Kenneth Hui: Involvement with OpenStack, thoughts\n        and future of the Trove project, and more\n      * Why Fuel now runs on Docker\n      * OpenStack Crossproject Meeting: Summary and full logs.\n\nGot Answers?\n\nAsk OpenStack is the go-to destination for OpenStack users. Interesting\nquestions waiting for answers:\n\n\n      * How to set up a Federation in Openstack Juno?\n      * Attempt to install Nova-Docker driver on Fedora 21\n      * how to use keyring?\n      * Can\'t get requested routers from kwarg in def sync_routers\n      * VNC port not open in firewall\n        \n        \nThe weekly newsletter is a way for the community to learn about all the\nvarious activities occurring on a weekly basis. If you would like to add\ncontent to a weekly update or have an idea about this newsletter, please\nleave a comment.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150130/ce3a9a8b/attachment.html>\n\n',NULL,NULL),('<1422631076.987049.221001221.07C1D9D6@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 10:17:56',-18000,'2015-01-30 15:17:56',NULL,'[openstack-dev] [all] Question about import module','\n\nOn Thu, Jan 29, 2015, at 09:10 PM, liuxinguo wrote:\n> *         I have seen that the module \'oslo.config\' have changed to\n> \'oslo_config\' in Kilo but in Juno it is still \'oslo.config\'.\n> \n> I want my code work compatibly both for Juno and Kilo so I import this\n> module in this way:\n> \n> try:\n>     from oslo_config import cfg\n> except:\n> from oslo.config import cfg\n> \n> *         Does this way of importing module will be accepted by the\n> community<app:ds:community>? Or is there any other better\n> way<app:ds:way>?\n\nThere\'s no need to do this. The config library still supports using\noslo.config for now, and we are going to cap the versions of the\nlibraries used in Juno to avoid issues in the future.\n\nPlease update master branches of any projects using Oslo libraries to\nimport from the new name only.\n\nDoug\n\n> \n> Thanks and regards,\n> Liu\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<E97AE00C7CAEC3489EF8B5A429A8B2842DA72933@szxeml504-mbx.china.huawei.com>',NULL),('<1422631702.990157.221002733.583E7B42@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 10:28:22',-18000,'2015-01-30 15:28:22',NULL,'[openstack-dev] [oslo.db] PyMySQL review','\n\nOn Thu, Jan 29, 2015, at 07:03 PM, Angus Lees wrote:\n> The other factor I haven\'t seen mentioned here is that our usual\n> eventlet+mysqldb setup can deadlock rather easily(*), resulting in the\n> entire python process sitting idle for 30s until the mysqldb deadlock\n> timer\n> goes off and raises an exception.  At this point (in nova at least), the\n> request is usually retried and almost certainly succeeds.  In neutron (as\n> another example), the requests weren\'t so easy to retry and code examples\n> where this was noticed had to be explicitly restructured to defer work\n> that\n> might yield the greenlet.\n> ie: it\'s a big cost on coding, and deployments, as well as just being\n> plain\n> incorrect code.\n> \n> (*) eg: send simultaneous requests that modify the same resource.\n> Eventually you\'ll have two greenlets within the same api server executing\n> conflicting database operations.  Entire python process freezes.   (Note\n> this is not a regular db transaction block, neither greenlet will ever\n> exit\n> their transactions without the deadlock timer).\n> \n> Bug here: https://bugs.launchpad.net/oslo.db/+bug/1350149\n> Test that reproduces the issue here:\n> https://review.openstack.org/#/c/104436/\n> \n> I\'m dismayed that the conversation always skews towards discussing\n> performance when the current choice isn\'t even correct yet, and that as a\n> community we seem to be unwilling/unable to get behind what should be\n> quite\n> an obvious technical issue with straightforward solutions.\n\nMy impression of this thread is that we\'re reaching consensus that we\nshould move to PyMySQL, but that we want to make that move carefully\nbecause we expect issues due to the changes in performance and context\nswitching behaviors. We\'ve seen in the past that even slight changes in\nsome timings expose race conditions, so while raw performance isn\'t\ncritical the timing can be as tests run in the gate. Spending some time\non a migration & test plan, and making sure that people are ready to\nhelp debug those sorts of issues, are good next steps.\n\nThe issue of moving off of eventlet can be addressed separately, after\nthe driver change.\n\nSo, do we need a cross-project spec to write down those details?\n\nDoug\n\n> \n> If we absolutely can\'t switch to another mysql driver, another option\n> that\n> was suggested recently (and passes the above test) is using\n> eventlet.monkey_patch(MySQLdb=True).  I haven\'t done the investigation to\n> find out why that isn\'t the default, or what the downsides are.  This\n> obviously doesn\'t help us with other factors, like python3-ness either.\n> \n>  - Gus\n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAPA_H3f=L0J8uq-3UHYH-N82JXBCAq0Pm5C2LbO9dqfH8GesoA@mail.gmail.com>',NULL),('<1422638909.1130040.221057337.464A947B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 09:28:29',-28800,'2015-01-30 17:28:29',NULL,'[openstack-dev] [infra] Nominating Elizabeth K. Joseph for\n infra-core and root','On Fri, Jan 30, 2015, at 09:20 AM, James E. Blair wrote:\n> Hi,\n> \n> The Infrastructure program has a unique three-tier team structure:\n> contributors (that\'s all of us!), core members (people with +2 ability\n> on infra projects in Gerrit) and root members (people with\n> administrative access).  Read all about it here:\n> \n>   http://ci.openstack.org/project.html#team\n> \n> Elizabeth K. Joseph has been reviewing a significant number of infra\n> patches for some time now.  She has taken on a number of very large\n> projects, including setting up our Git server farm, adding support for\n> infra servers running on CentOS, and setting up the Zanata translation\n> system (and all of this without shell access to production machines).\n> \n> She understands all of our servers, regardless of function, size, or\n> operating system.  She has frequently spoken publicly about the unique\n> way in which we perform systems administration, articulating what we are\n> doing and why in a way that inspires us as much as others.\n> \n> Due to her strong systems administration background, I am nominating her\n> for both infra-core and infra-root simultaneously.  I expect many of us\n> are looking forward to seeing her insight and direction applied with +2s\n> but also equally excited for her to be able to troubleshoot things when\n> our best-laid plans meet reality.\n> \n> Please respond with any comments or concerns.\n> \n> Thanks, Elizabeth, for all your work!\n> \n> -Jim\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n+1 install the pleia2 rootkit. This is exciting, will be great to have\npleia2 join the core and admin groups.\n\nClark\n\n\n','<87mw50kwwj.fsf@meyer.lemoncheese.net>',NULL),('<1422638909.1130040.221057337.464A947B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-01-30 09:28:29',-28800,'2015-01-30 17:28:29',NULL,'[OpenStack-Infra] [openstack-dev] [infra] Nominating Elizabeth\n K. Joseph for infra-core and root','On Fri, Jan 30, 2015, at 09:20 AM, James E. Blair wrote:\n> Hi,\n> \n> The Infrastructure program has a unique three-tier team structure:\n> contributors (that\'s all of us!), core members (people with +2 ability\n> on infra projects in Gerrit) and root members (people with\n> administrative access).  Read all about it here:\n> \n>   http://ci.openstack.org/project.html#team\n> \n> Elizabeth K. Joseph has been reviewing a significant number of infra\n> patches for some time now.  She has taken on a number of very large\n> projects, including setting up our Git server farm, adding support for\n> infra servers running on CentOS, and setting up the Zanata translation\n> system (and all of this without shell access to production machines).\n> \n> She understands all of our servers, regardless of function, size, or\n> operating system.  She has frequently spoken publicly about the unique\n> way in which we perform systems administration, articulating what we are\n> doing and why in a way that inspires us as much as others.\n> \n> Due to her strong systems administration background, I am nominating her\n> for both infra-core and infra-root simultaneously.  I expect many of us\n> are looking forward to seeing her insight and direction applied with +2s\n> but also equally excited for her to be able to troubleshoot things when\n> our best-laid plans meet reality.\n> \n> Please respond with any comments or concerns.\n> \n> Thanks, Elizabeth, for all your work!\n> \n> -Jim\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n+1 install the pleia2 rootkit. This is exciting, will be great to have\npleia2 join the core and admin groups.\n\nClark\n\n\n','<87mw50kwwj.fsf@meyer.lemoncheese.net>',NULL),('<1422641977-sup-4777@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 18:28:19',0,'2015-01-30 18:28:19',NULL,'[openstack-dev] [tripleo] Undercloud heat version expectations','Excerpts from Steven Hardy\'s message of 2015-01-30 10:29:05 +0000:\n> Hi all,\n> \n> I\'ve had a couple of discussions lately causing me to question $subject,\n> and in particular what our expectations are around tripleo-heat-templates\n> working with older (e.g non trunk) versions of Heat in the undercloud.\n> \n> For example, in [1], we\'re discussing merging a template-level workaround\n> for a heat bug which has been fixed for nearly 4 months (I\'ve now proposed\n> a stable/juno backport..) - this raises the question, do we actually\n> support tripleo-heat-templates with a stable/juno heat in the undercloud?\n> \n> Related to this is discussion such as [2], where ideally I\'d like us to\n> start using some new-shiny features we\'ve been landing in heat to make the\n> templates cleaner - is this valid, e.g can I start proposing template\n> changes to tripleo-heat-templates which will definitely require\n> new-for-kilo heat functionality?\n> \n> Thanks,\n> \n> Steve\n> \n> [1] https://review.openstack.org/#/c/151038/\n> [2] https://review.openstack.org/#/c/151389/\n> \n\nHey Steve,\n\nA while ago (last mid cycle IIRC) we decided that rather than maintain\nstable branches we would ensure that we could deploy stable openstack\nreleases from trunk. I believe Heat falls under this umbrella, and we\nneed to make sure that we support deploying at least the latest stable\nheat release.\n\nThat being said, were lacking in this plan ATM. We *really* should have\na stable release CI job. We do have a spec though[1].\n\nCheers,\nGreg\n\n\n[1] http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/backwards-compat-policy.rst\n\n\n','<20150130102904.GC892@t430slt.redhat.com>',NULL),('<1422651853-sup-120@greghaynes0.opus.gah>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 21:25:51',0,'2015-01-30 21:25:51',NULL,'[openstack-dev] [tripleo] Undercloud heat version expectations','Excerpts from Gregory Haynes\'s message of 2015-01-30 18:28:19 +0000:\n> Excerpts from Steven Hardy\'s message of 2015-01-30 10:29:05 +0000:\n> > Hi all,\n> > \n> > I\'ve had a couple of discussions lately causing me to question $subject,\n> > and in particular what our expectations are around tripleo-heat-templates\n> > working with older (e.g non trunk) versions of Heat in the undercloud.\n> > \n> > For example, in [1], we\'re discussing merging a template-level workaround\n> > for a heat bug which has been fixed for nearly 4 months (I\'ve now proposed\n> > a stable/juno backport..) - this raises the question, do we actually\n> > support tripleo-heat-templates with a stable/juno heat in the undercloud?\n> > \n> > Related to this is discussion such as [2], where ideally I\'d like us to\n> > start using some new-shiny features we\'ve been landing in heat to make the\n> > templates cleaner - is this valid, e.g can I start proposing template\n> > changes to tripleo-heat-templates which will definitely require\n> > new-for-kilo heat functionality?\n> > \n> > Thanks,\n> > \n> > Steve\n> > \n> > [1] https://review.openstack.org/#/c/151038/\n> > [2] https://review.openstack.org/#/c/151389/\n> > \n> \n> Hey Steve,\n> \n> A while ago (last mid cycle IIRC) we decided that rather than maintain\n> stable branches we would ensure that we could deploy stable openstack\n> releases from trunk. I believe Heat falls under this umbrella, and we\n> need to make sure that we support deploying at least the latest stable\n> heat release.\n> \n> That being said, were lacking in this plan ATM. We *really* should have\n> a stable release CI job. We do have a spec though[1].\n> \n> Cheers,\n> Greg\n> \n> \n> [1] http://git.openstack.org/cgit/openstack/tripleo-specs/tree/specs/juno/backwards-compat-policy.rst\n\nWe had a discussion in IRC about this and I wanted to bring up the points\nthat were made on the ML. By the end of the discussion I think the\nconsensus there was that we should resurrect the stable branches.\nTherefore, I am especially seeking input from people who have arguments\nfor keeping our current \'deploy stable openstack from master\' goals.\n\nOur goal of being able to deploy stable openstack branches using HEAD of\ntripleo tools makes some new feature development more difficult on\nmaster than it needs to be. Specifically, dprince has been feeling this\npain in the tripleo/puppet integration work he is doing. There is also\nsome new heat feature work we could benefit from (like the patches\nabove) that were going to have to wait multiple cycles for or maintain\nmultiple implementations of. Therefore we should look into resurreting\nour stable branches.\n\nThe backwards compat spec specifies that tripleo-image-elements and\ntripleo-heat-templates are co-dependent WRT backwards compat. This\nprobably made some sense at the time of the spec writing since\nalternatives to tripleo-image-elements did not exist, but with the\ntripleo/puppet work we need to revisit this.\n\nThoughts? Comments?\n\nCheers,\nGreg\n\n\n','<1422641977-sup-4777@greghaynes0.opus.gah>',NULL),('<1422653013.2947.11.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 15:23:33',-21600,'2015-01-30 21:23:33',NULL,'[openstack-dev] [Openstack-operators] [all][log] Openstack\n	HTTP	error codes','On Fri, 2015-01-30 at 21:08 +0000, Everett Toews wrote:\n> Project: A client dealing with the API already knows what project\n> (service) they?re dealing with. Including this in an API error message\n> would be redundant. That?s not necessarily so bad and it could\n> actually be convenient for client logging purposes to have this there.\n\nDo they?  We boot a server and interact with Cinder and Neutron, right?\nWhat if the nova API is simply forwarding an error that originally came\nfrom Cinder?\n\n> Vendor/Component: Including any vendor information at all would be\n> leaking implementation details. This absolutely cannot be exposed in\n> an API error message. Even including the component would be leaking\n> too much.\n\nWhile I agree with you from a security standpoint, this is probably\ncoming in due to a desire to namespace the errors.  Ideally, we\'d have a\nset of common error codes to cover conditions that the API user could\nrectify (\"You picked a nic type we don\'t support\" or something like\nthat), but I fear there may always be errors that are things the API\nuser could rectify but which don\'t fit into any of those buckets?\n\n> Error Catalog Number: If there could be alignment around this, that\n> would be great.\n[snip]\n> Criticality: This might be useful to clients? I don?t know. I don?t\n> feel too strongly about it.\n\nI feel this part of the code needs more thought to properly round out.\nIs it intended to convey information similar to the distinction between\n4xx and 5xx errors in HTTP?  (\"You made an error\" vs. \"The server messed\nup\".)  Is it intended to convey a retryable condition?  (\"If you retry\nthis, it may succeed.\")  If it\'s intended to convey that the server\nmessed up spectacularly and that everything\'s broken now, well? :)\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<D67EFB03-2FD1-478D-8D41-FDD88CBA25F0@rackspace.com>',NULL),('<1422657620.2947.14.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-30 16:40:20',-21600,'2015-01-30 22:40:20',NULL,'[openstack-dev] Which repo should the API WG use?','On Fri, 2015-01-30 at 22:33 +0000, Everett Toews wrote:\n> It was suggested that the API WG use the openstack-specs [1] and/or\n> the api-wg [2] repo to publish its guidelines. We?ve already arrived\n> at the consensus that we should only use 1 repo [3]. So the purpose of\n> this thread is to decide...\n> \n> Should the API WG use the openstack-specs repo or the api-wg repo?\n> \n> Let?s discuss.\n\nWell, the guidelines are just that: guidelines.  They don\'t implicitly\npropose changes to any OpenStack projects, just provide guidance for\nfuture API changes.  Thus, I think they should go in a repo separate\nfrom any of our *-specs repos; to me, a spec provides documentation of a\nchange, and is thus independent of the guidelines.\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<8344BA1B-D1B4-48C4-BC33-052723F05AC5@rackspace.com>',NULL),('<1422900272.4218.38.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 13:04:32',-18000,'2015-02-02 18:04:32',NULL,'[openstack-dev] [sahara] Spark CDH followup and questions related\n	to DIB','Hello all,\n\n  I tried a Spark image with the cdh5 element Daniele describes below,\nbut it did not fix the jackson version issue. The spark assembly still\ndepends on inconsistent versions.\n\n  Looking into the spark git a little bit more, I discovered that in the\ncdh5-1.2.0_5.3.0 branch the jackson version is settable. I built spark\non this branch with jackson 1.9.13 and was able to run Spark EDP without\nany classpath manipulations. But, it doesn\'t appear to be released yet.\n\n  A couple questions come out of this:\n\n1) When do we move to cdh5.3 for spark images? Do we try to do this in\nKilo?\n\nThe work is already started, as noted below.  Daniele has done initial\nwork using cdh5 for the spark plugin and the Intel folks are working on \ncdh5 and cdh5.3 for the CDH plugin.\n\n2) Do we carry a Spark assembly for Sahara ourselves, or wait for a\nrelease tarball from CDH that uses this branch and sets a consistent\njackson version?  \n\nI asked about any plans to release a tarball from this\nbranch on the apache spark users list, waiting for a response.\n\nOne alternative is for us to host our own spark build that we can use in\nsahara-image-elements. The other idea is for us to wait for a release\ntarball at http://archive.apache.org/dist/spark/ and continue to use the\nclasspath workaround in spark EDP for the time being.\n\n3) Do we fix up sahara-image-elements to support multiple spark\nversions? \n\nHistorically sahara-image-elements only supports a single version for\nspark images.  This is different from the other plugins.  Since we have\nagreed to carry support for a release cycle of older versions after\nintroducing a new one, should we support both cdh4 and cdh5.x? This will\nrequire changes in diskimage_create.sh.\n\n4) Like #3, do we fix up the spark plugin in Sahara to handle multiple\nversions? This is similar to the work the Intel folks are doing now to\nseparate cdh5 and cdh5.3 code in the cdh plugin.\n\nI am wondering if the above 4 issues result in too much work to add to\nkilo-3. Do we make an incremental improvement over Juno, having\nspark-swift integration in EDP on cdh4 but without other changes and\naddress the above issues in L, or do we push on and try to resolve it\nall for Kilo?\n\nBest regards,\n\nTrevor\n\nOn Wed, 2015-01-28 at 11:57 -0500, Trevor McKay wrote:\n> Daniele,\n> \n>   Excellent! I\'ll have to keep a closer eye on bigfoot activity :) I\'ll\n> pursue this.\n> \n> Best,\n> \n> Trevor\n> \n> On Wed, 2015-01-28 at 17:40 +0100, Daniele Venzano wrote:\n> > Hello everyone,\n> > \n> > there is already some code in our repository:\n> > https://github.com/bigfootproject/savanna-image-elements\n> > \n> > I did the necessary changes to have the Spark element use the cdh5\n> > element. I updated also to Spark 1.2. The old cloudera HDFS-only\n> > element is still needed for generating cdh4 images (but probably cdh4\n> > support can be thrown away).\n> > \n> > Unfortunately I do not have the time to do the necessary\n> > testing/validation and submit for review. I also changed the CDH\n> > element so that it can install only HDFS, if so required.\n> > The changes I made are simple and all contained in the last commit on\n> > the master branch of that repo.\n> > \n> > The image generated with this code runs in Sahara without any further\n> > changes. Feel free to take the code, clean it up and submit for review.\n> > \n> > Dan\n> > \n> > On Wed, Jan 28, 2015 at 10:43:30AM -0500, Trevor McKay wrote:\n> > > Intel folks,\n> > > \n> > > Belated welcome to Sahara!  Thank you for your recent commits.\n> > > \n> > > Moving this thread to openstack-dev so others may contribute, cc\'ing\n> > > Daniele and Pietro who pioneered the Spark plugin.\n> > > \n> > > I\'ll respond with another email about Oozie work, but I want to\n> > > address the Spark/Swift issue in CDH since I have been working\n> > > on it and there is a task which still needs to be done -- that\n> > > is to upgrade the CDH version in the spark image and see if\n> > > the situation improves (see below)\n> > > \n> > > Relevant reviews are here:\n> > > \n> > > https://review.openstack.org/146659\n> > > https://review.openstack.org/147955\n> > > https://review.openstack.org/147985\n> > > https://review.openstack.org/146659\n> > > \n> > > In the first review, you can see that we set an extra driver\n> > > classpath to pull in \'/usr/lib/hadoop/lib/jackson-core-asl-1.8.8.jar.\n> > > \n> > > This is because the spark-assembly JAR in CDH4 contains classes from\n> > > jackson-mapper-asl-1.8.8 and jackson-core-asl-1.9.x. When the\n> > > hadoop-swift.jar dereferences a Swift path, it calls into code\n> > > from jackson-mapper-asl-1.8.8 which uses JsonClass.  But JsonClass\n> > > was removed in jackson-core-asl-1.9.x, so there is an exception.\n> > > \n> > > Therefore, we need to use the classpath to either upgrade the version of\n> > > jackson-mapper-asl to 1.9.x or downgrade the version of jackson-core-asl\n> > > to 1.8.8 (both work in my testing).  However, the first of these options\n> > > requires us to bundle an extra jar.  Since /usr/lib/hadoop already\n> > > contains jackson-core-asl-1.8.8, it is easier to just add that to the\n> > > classpath and downgrade the jackson version.\n> > > \n> > > Note, there are some references to this problem on the spark mailing list,\n> > > we are not the only ones to encounter it.\n> > > \n> > > However, I am not completely comfortable with mixing versions and\n> > > patching the classpath this way.  It looks to me like the Spark assembly\n> > > used in CDH5 has consistent versions, and I would like to try updating\n> > > the CDH version in sahara-image-elments to CDH5 for Spark. If this fixes\n> > > the problem and removes the need for the extra classpath, that would be\n> > > great.\n> > > \n> > > Would someone like to take on this change? (modifying sahara-image-elements\n> > > to use CDH5 for Spark images) I can make a blueprint for\n> > > it.\n> > > \n> > > More to come about Oozie topics.\n> > > \n> > > Best regards,\n> > > \n> > > Trevor\n> > > \n> > > On Thu, 2015-01-15 at 15:34 +0000, Chen, Weiting wrote:\n> > > > Hi Mckay.\n> > > > \n> > > >  \n> > > > \n> > > > We are Intel team and contributing OpenStack Sahara project.\n> > > > \n> > > > We are new in Sahara and would like to do more contributions in this\n> > > > project.\n> > > > \n> > > > So far, we are focusing on Sahara CDH Plugin.\n> > > > \n> > > > So if there is any issues related on this, please feel free to discuss\n> > > > with us.\n> > > > \n> > > >  \n> > > > \n> > > > During IRC meeting, there are two issues you mentioned and we would\n> > > > like to discuss with you.\n> > > > \n> > > > 1.      Oozie Workflow Support: \n> > > > \n> > > > Do you have any plan could share with us about your idea?\n> > > > \n> > > > Because in our case, we are testing to run a java action job with\n> > > > HBase library support and also facing some problems about Oozie\n> > > > support.\n> > > > \n> > > > So it should be good to share the experience with each other.\n> > > > \n> > > > \n> > > > \n> > > > 2.      Spark CDH Issues: \n> > > > \n> > > > Could you provide more information about this issue? In CDH Plugin, we\n> > > > have used CDH 5 to finish swift test. So it should be fine to upgrade\n> > > > CDH 4 to 5.\n> > > > \n> > > >  \n> > > > \n> > > > \n> > > \n> > > \n> > > \n> > \n> \n> \n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1422464222.9463.7.camel@redhat.com>',NULL),('<1422903528.20033.6.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-02-02 19:58:48',3600,'2015-02-02 18:58:48',NULL,'[Openstack] Call for Speakers - February 9 Deadline!','February 9th is the deadline to submit a talk for the May 2015 Vancouver\nSummit\n\nWould you like to speak at the May 2015 OpenStack Summit in Vancouver?\n\nThen hurry up and submit a talk! February 9 is the final day that\nspeaking submissions will be accepted.\n\nhttps://www.openstack.org/summit/vancouver-2015/call-for-speakers/\n\n\n\n',NULL,NULL),('<1422903578.4218.51.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 13:59:38',-18000,'2015-02-02 18:59:38',NULL,'[openstack-dev] About Sahara Oozie plan','Hi,\n\n  Thanks for your patience.  I have been consumed with spark-swift, but\nI can start to address these questions now :)\n\nOn (1) (a) below, I will try to reproduce and look at how we can better\nsupport classpath in EDP. I\'ll let you know what I find.\nWe may need to add some configuration options for EDP or change how it\nworks.\n\nOn (1) (b) below, in the edp-move-examples.rst spec for Juno we\ndescribed a directory structure that could be used\nfor separating hadoop1 vs hadoop2 specific directories.  Maybe we can do\nsomething similar based on plugins\n\nFor instance, if we have some hbase examples, we can make subdirectories\nfor each plugin.  Common parts can be\nshared, plugin-specific files can be stored in the subdirectories.\n\n(and perhaps the \"hadoop2\" example already there should just be a\nsubdirectory under \"edp-java\")\n\nBest,\n\nTrevor\n\n--\n\nHi McKay\nThx for your support\nI will talk details of these items as below:\n\n(1)     EDP job in Java action\n\n   The background is that we want write integration test case for newly\nadded services like HBase, zookeeper just like the way the edp-examples\ndoes( sample code under sahara/etc/edp-examples/). So I thought I can\nwrote an example via edp job by Java action to test HBase Service, then\nI wrote the HBaseTest.java and packaged as a jar file, and run this jar\nmanually with the command \"java -cp `hbase classpath` HBaseTest.jar\nHBaseTest\", it works well in the vm(provisioned by sahara with cdh\nplugin).\n?/usr/lib/jvm/java-7-oracle-cloudera/bin/java -cp \"HBaseTest.jar:`hbase\nclasspath`\" HBaseTest?\nSo I want run this job via horizon in sahara job execution page, but\nfound no place to pass the `hbase classpath` parameter.(I have tried\njava_opt and configuration and args, all failed). When I pass the ?-cp\n`hbase classpath`? to java_opts in horizon job execution page. Oozie\nraise this error as below\n\n?2015-01-15 16:43:26,074 WARN\norg.apache.oozie.action.hadoop.JavaActionExecutor:\nSERVER[hbase-master-copy-copy-001.novalocal] USER[hdfs] GROUP[-] TOKEN[]\nAPP[job-wf] JOB[0000045-150105050354389-oozie-oozi-W]\nACTION[0000045-150105050354389-oozie-oozi-W at job-node] LauncherMapper\ndied, check Hadoop LOG for job\n[hbase-master-copy-copy-001.novalocal:8032:job_1420434100219_0054]\n2015-01-15 16:43:26,172 INFO\norg.apache.oozie.command.wf.ActionEndXCommand:\nSERVER[hbase-master-copy-copy-001.novalocal] USER[hdfs] GROUP[-] TOKEN[]\nAPP[job-wf] JOB[0000045-150105050354389-oozie-oozi-W]\nACTION[0000045-150105050354389-oozie-oozi-W at job-node] ERROR is\nconsidered as FAILED for SLA?\n\nSo I stuck with this issue, I can?t write the integration test in sahara\n( could not pass the classpath parameter), \nI have check oozie official site .\nhttps://cwiki.apache.org/confluence/display/OOZIE/Java+Cookbook found no\nhelp info.\n \n   So about the EDP job in java, I have two problems right now:\na)      How to pass classpath to java action as I mention before. So\nthis also reminds me that we can allow user to modify or upload this own\nworkflow.xml, then we can provide more options for user.\nb)      I concern that it?s hard to have a common edp-example for HBase\nfor all plugin(cdh dhp), because the example code depends on third party\njars(for example hbase-client.jar?) and different platform(CDH HDP) they\nmay have different version hbase-client.jar, for example, cdh use\nhbase-client-0.98.6-cdh5.2.1.jar. \n\nattached is a zip file which contains HBaseTest.jar and the source code.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150202/9768d0f0/attachment.html>\n\n',NULL,NULL),('<1422904921.4218.61.camel@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 14:22:01',-18000,'2015-02-02 19:22:01',NULL,'[openstack-dev] About Sahara Oozie plan','Answers to other questions:\n\n2) (first part) Yes, I think Oozie shell actions are a great idea. I can\nhelp work on a spec for this.\n\nIn general, Sahara should be able to support any kind of Oozie action.\nEach will require a new job type, changes to the Oozie engine, and a UI\nform to handle submission. We talked about shell actions once upon a\ntime. I don\'t think a spec for that will be too difficult.\n\nTypically when adding new Oozie actions, I start by running things with\nthe Oozie command line to figure out what\'s possible and what the\nworkflow.xml looks like in general.\n\n\nWe also talked about allowing a user to upload raw workflows -- the\ndifficulty there is figuring out what Sahara generates vs what the user\nwrites, so this may be a more complicated topic. I think it will have to\nwait for another cycle.\n\n2) (error information)\n\nYes, the lack of good error information is a big problem in my opinion,\nbut we have no plan for it at this time.\n\nThe OpenStack approach seems to be to look through lots of log files to\nidentify errors.  For EDP, we may need to support a similar approach by\nallowing job logs to be easily retrieved from clusters and written\nsomewhere a user can parse through them for error information.  Any\nideas on how to do this are welcome.\n\nTrevor\n\n-- \n\n(2)     Sahara oozie plan\n\nSo when I search the solution for HBase test case, I found\nhttp://archive.cloudera.com/cdh5/cdh/5/oozie/DG_ShellActionExtension.html , it talks about oozie shell action job type, I believe my first issue in EDP job in java action can be solved by shell action, because I can set <exec>java</exec> <argument>`hbase classpath`</argument> in workflow.xml, just like the way I run this jar in the vm console by command. So I raise a bp for adding oozie shell action https://blueprints.launchpad.net/sahara/+spec/add-edp-shell-action  I will make further research on the bp/specs and update the spec. In today?s meeting , you mentioned about allow user to upload his own workflow.xml, I am interesting about this , we can provide our support to this part, so can you provide some bp/specs or other docs for me? So we can discuss for more.\n\nFor more, is there any plan to provide edp job error info to the user? I\nthink this is also important, currently we just have \"killed\" label, no\nmore information.\n\n\n\n','<1422903578.4218.51.camel@redhat.com>',NULL),('<1422904927.20033.7.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2015-02-02 20:22:07',3600,'2015-02-02 19:22:07',NULL,'[Openstack-operators] Call for Speakers - February 9 Deadline!','\nFebruary 9th is the deadline to submit a talk for the May 2015 Vancouver\nSummit\n\nWould you like to speak at the May 2015 OpenStack Summit in Vancouver?\n\nThen hurry up and submit a talk! February 9 is the final day that\nspeaking submissions will be accepted.\n\nhttps://www.openstack.org/summit/vancouver-2015/call-for-speakers/\n\n\n\n',NULL,NULL),('<1422906696.20033.18.camel@sputacchio.gateway.2wire.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 20:51:36',3600,'2015-02-02 19:51:36',NULL,'[openstack-dev] The API WG mission statement','On Fri, 2015-01-30 at 23:05 +0000, Everett Toews wrote:\n> To converge the OpenStack APIs to a consistent and pragmatic RESTful\n> design by creating guidelines that the projects should follow. The\n> intent is not to create backwards incompatible changes in existing\n> APIs, but to have new APIs and future versions of existing APIs\n> converge.\n\nIt\'s looking good already. I think it would be good also to mention the\nend-recipients of the consistent and pragmatic RESTful design so that\nwhoever reads the mission is reminded why that\'s important. Something\nlike:\n\n        To improve developer experience converging the OpenStack API to\n        a consistent and pragmatic RESTful design. The working group\n        creates guidelines that all OpenStack projects should follow,\n        avoids introducing backwards incompatible changes in existing\n        APIs and promotes convergence of new APIs and future versions of\n        existing APIs.\n\nmore or less...\n\n/stef\n\n\n\n','<64C7D715-8BE6-4B6F-AF36-452E25BDC95B@rackspace.com>',NULL),('<1422914367.3151606.222194353.71DB8B59@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 16:59:27',-18000,'2015-02-02 21:59:27',NULL,'[openstack-dev] [oslo] oslo.versionedobjects repository is\n ready for pre-import review','\n\nOn Mon, Feb 2, 2015, at 04:33 PM, Doug Hellmann wrote:\n> I?ve prepared a copy of nova.objects as oslo_versionedobjects in\n> https://github.com/dhellmann/oslo.versionedobjects-import. The script to\n> create the repository is part of the update to the spec in\n> https://review.openstack.org/152222.\n> \n> Please look over the code so you are familiar with it. Dan and I have\n> already talked about the need to rewrite the tests that depend on nova?s\n> service code, so those are set to skip for now. We?ll need to do some\n> work to make the lib compatible with python 3, so I?ll make sure the\n> project-config patch does not enable those tests, yet.\n> \n> Please post comments on the code here on the list in case I end up\n> needing to rebuild that import repository.\n> \n> I?ll give everyone a few days before removing the WIP flag from the infra\n> change to import this new repository\n> (https://review.openstack.org/151792).\n\nI filed bugs for a few known issues that we\'ll need to work on before\nthe first release: https://bugs.launchpad.net/oslo.versionedobjects\n\nDoug\n\n\n','<BD0AB812-1606-49E9-85FE-44440FCF3F02@doughellmann.com>',NULL),('<1422985815-sup-1740@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-03 09:57:59',-28800,'2015-02-03 17:57:59',NULL,'[openstack-dev] [heat] operators vs users for choosing\n	convergence engine','Excerpts from Angus Salkeld\'s message of 2015-02-03 02:40:44 -0800:\n> On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker <sbaker at redhat.com> wrote:\n> \n> > A spec has been raised to add a config option to allow operators to choose\n> > whether to use the new convergence engine for stack operations. For some\n> > context you should read the spec first [1]\n> >\n> > Rather than doing this, I would like to propose the following:\n> > * Users can (optionally) choose which engine to use by specifying an\n> > engine parameter on stack-create (choice of classic or convergence)\n> > * Operators can set a config option which determines which engine to use\n> > if the user makes no explicit choice\n> > * Heat developers will set the default config option from classic to\n> > convergence when convergence is deemed sufficiently mature\n> >\n> > I realize it is not ideal to expose this kind of internal implementation\n> > detail to the user, but choosing convergence _will_ result in different\n> > stack behaviour (such as multiple concurrent update operations) so there is\n> > an argument for giving the user the choice. Given enough supporting\n> > documentation they can choose whether convergence might be worth trying for\n> > a given stack (for example, a large stack which receives frequent updates)\n> >\n> > Operators likely won\'t feel they have enough knowledge to make the call\n> > that a heat install should be switched to using all convergence, and users\n> > will never be able to try it until the operators do (or the default\n> > switches).\n> >\n> > Finally, there are also some benefits to heat developers. Creating a whole\n> > new gate job to test convergence-enabled heat will consume its share of CI\n> > resource. I\'m hoping to make it possible for some of our functional tests\n> > to run against a number of scenarios/environments. Being able to run tests\n> > under classic and convergence scenarios in one test run will be a great\n> > help (for performance profiling too).\n> >\n> \n> Hi\n> \n> I didn\'t have a good initial response to this, but it\'s growing on me. One\n> issue is the specific option that we expose, it\'s not nice having\n> a dead option once we totally switch over and remove \"classic\". So is it\n> worth coming up with a real feature that convergence-phase-1 enables\n> and use that (like enable-concurrent-updates). Then we need to think if we\n> would actually want to keep that feature around (as in\n> once \"classic\" is gone is it possible to maintain\n> \"disable-concurrent-update\").\n> \n\nThere are other features of convergence that will be less obvious.\nHaving stack operations survive a restart of the engines is a pretty big\none that one might have a hard time grasping, but will be appreciated by\nusers. Also being able to push a bigger stack in will be a large benefit,\nthough perhaps not one that is realized on day 1.\n\nAnyway, I\'d prefer that they just be versioned, and not named. The names\nare too implementation specific. A v1 stack will be expected to work\nwith v1 stack tested templates and parameters for as long as we support\nv1 stacks.\n\nA v2 stack will be expected to work similarly, but may act differently,\nand thus a user can treat this as another API update that they need to\ndeal with. The features will be a force multiplier, but the recommendation\nof the team by removing the \"experimental\" tag will be the primary\nmotivator. And for operators, when they\'re comfortable with new stacks all\ngoing to v2 they can enable that as the default. If they trust the Heat\ndevelopers, they can just go to v2 as default when the Heat devs say so.\n\nOnce we get all of the example templates to work with v2 and write some\nnew v2-specific stacks, thats the time to write a migration tool and\ndeprecate v1.\n\nSo, to be clear, I\'m fully in support of Steve Baker\'s suggestion to let\nthe users choose which engine to use. However, I think we should treat\nit not as an \"engine\" choice, but as an \"interface\" choice. The fact that\nit takes a whole new engine to support the new features of the interface\nis the implementation detail that no end-user needs to care about.\n\n\n','<CAA16xcxiRWqo9F7o2WSGmakK05iHOYkerMp+Y93w+kzJTySthQ@mail.gmail.com>',NULL),('<1422986663.64978283@mail.openstack.org>','http://lists.openstack.org/pipermail/community',NULL,'2015-02-03 12:04:23',-21600,'2015-02-03 18:04:23',NULL,'[openstack-community] OpenStack Contributors: Interested in speaking at Cloud Expo Europe?','\nWe have a 25 minute presentation opportunity in the in-booth theater in the Developer and Open Cloud Park booth of Cloud Expo Europe.  It\'s either going to be on March 11 or 12.  We\'d like a contributor to speak or join me in presenting the [ OpenStack for Technical Audiences presentation ]( http://www.openstack.org/assets/marketing/presentations/OpenStack-for-Technical-Audiences-November-10-2014.pptx ).  Note, the facts, course list, etc. will be updated just prior to the event.  Please reply to me directly if interested ([ kathyc at openstack.org ]( mailto:kathyc at openstack.org )).  \n \nThere may be another spot on a Hybrid Cloud panel.  For this one, I\'ll be looking for users with private clouds accessing public clouds for extra resources on demand.  \n \nThank you, as always, for your support!\n-- \nRegards, \n\nKathy Cacciatore\nConsulting Marketing Manager\nOpenStack Foundation\n1-512-970-2807 (mobile)\nPart time: Monday - Thursday, 9am - 2pm US CT\nkathyc at openstack.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20150203/adf77801/attachment.html>\n\n',NULL,NULL),('<1422989218-sup-4176@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-03 11:12:00',-28800,'2015-02-03 19:12:00',NULL,'[openstack-dev] [heat] operators vs users for choosing\n	convergence engine','Excerpts from Zane Bitter\'s message of 2015-02-03 10:00:44 -0800:\n> On 02/02/15 19:52, Steve Baker wrote:\n> > A spec has been raised to add a config option to allow operators to\n> > choose whether to use the new convergence engine for stack operations.\n> > For some context you should read the spec first [1]\n> >\n> > Rather than doing this, I would like to propose the following:\n> \n> I am strongly, strongly opposed to making this part of the API.\n> \n> > * Users can (optionally) choose which engine to use by specifying an\n> > engine parameter on stack-create (choice of classic or convergence)\n> > * Operators can set a config option which determines which engine to use\n> > if the user makes no explicit choice\n> > * Heat developers will set the default config option from classic to\n> > convergence when convergence is deemed sufficiently mature\n> \n> We\'d also need a way for operators to prevent users from enabling \n> convergence if they\'re not ready to support it.\n> \n\nThis would be relatively simple to do by simply providing a list of the\nsupported stack versions.\n\n> > I realize it is not ideal to expose this kind of internal implementation\n> > detail to the user, but choosing convergence _will_ result in different\n> > stack behaviour (such as multiple concurrent update operations) so there\n> > is an argument for giving the user the choice. Given enough supporting\n> > documentation they can choose whether convergence might be worth trying\n> > for a given stack (for example, a large stack which receives frequent\n> > updates)\n> \n> It\'s supposed to be a strict improvement; we don\'t need to ask \n> permission. We have made major changes of this type in practically every \n> Heat release. When we switched from creating resources serially to \n> creating them in parallel in Havana we didn\'t ask permission. We just \n> did it. We when started allowing users to recover from a failed \n> operation in Juno we didn\'t ask permission. We just did it. We don\'t \n> need to ask permission to allow concurrent updates. We can just do it.\n> \n\nThe visible change in making things parallel was minimal. In talking\nabout convergence, it\'s become clear that users can and should expect\nsomething radically different when they issue stack updates. I\'d love to\nsay that it can be done to just bind convergence into the old ways, but\ndoing so would also remove the benefit of having it.\n\nAlso allowing resume wasn\'t a new behavior, it was fixing a bug really\n(that state was lost on failed operations). Convergence is a pretty\ndifferent beast from the current model, and letting users fall back\nto the old one means that when things break they can solve their own\nproblem while the operator and devs figure it out. The operator may know\nwhat is breaking their side, but they may have very little idea of what\nis happening on the end-user\'s side.\n\n> The only difference here is that we are being a bit smarter and \n> uncoupling our development schedule from the release cycle. There are 15 \n> other blueprints, essentially all of which have to be complete before \n> convergence is usable at all. It won\'t do *anything at all* until we are \n> at least 12 blueprints in. The config option buys us time to land them \n> without the risk of something half-finished appearing in the release \n> (trunk-chasers will also thank us). It has no other legitimate purpose IMO.\n> \n\nThe config option only really allows an operator to go forward. If\nthe users start expecting concurrent updates and resiliency, and then\nall their stacks are rolled back to the old engine because #reasons,\nthis puts pressure on the operator. This will make operators delay the\nforward progress onto convergence for as long as possible.\n\nI\'m also not entirely sure rolling the config option back to the old\nsetting would even be possible without breaking any in-progress stacks.\n\n> The goal is IN NO WAY to maintain separate code paths in the long term. \n> The config option is simply a development strategy to allow us to land \n> code without screwing up a release and while maintaining as much test \n> coverage as possible.\n> \n\nNobody plans to maintain the Keystone v2 domainless implementation forever\ntoo. But letting users consider domains and other v3 options for a while\nmeans that the ecosystem grows more naturally without giving up ground\nto instability. Once the v3 adoption rate is high enough, people will\nlikely look at removing the old code because nobody uses it. In my\nopinion OpenStack has been far too eager to deprecate and remove things\nthat users rely on, but I do think this will happen and should happen\neventually.\n\n> > Operators likely won\'t feel they have enough knowledge to make the call\n> > that a heat install should be switched to using all convergence, and\n> > users will never be able to try it until the operators do (or the\n> > default switches).\n> \n> Hardly anyone should have to make a call. We should flip the default as \n> soon as all of the blueprints have landed (i.e. as soon as it works at \n> all), provided that a release is not imminent. (Realistically, at this \n> point I think we have to say the target is to do it as early as in \n> Lizard as we can.) That means for those chasing trunk they get it as \n> soon as it works at all, and for those using stable releases they get it \n> at the next release, just like every other feature we have ever added.\n> \n> As a bonus, trunk-chasing operators who need to can temporarily delay \n> enabling of convergence until a point of their choosing in the release \n> cycle by overriding the default. Anybody in that position likely has \n> enough knowledge to make the right call for them.\n> \n\nThe end users need a vote too. Operators will certainly know when\nconvergence based stacks are costing them less than classic stacks. But\nthey may not know that the new convergence stacks are breaking users. So\nrather than an operator flipping the config option and suddenly breaking\nusers, if they can flip the default, wait a while, and then inform any\nusers that are doing things \"the old way\" that it will be turned off some\nday, that lets both sides move forward at a pace that makes sense to them.\n\n> So I believe that all of our stakeholders are catered to by the config \n> option: operators & users who want a stable, tested release; \n> operator/users who want to experiment on the bleeding edge; and \n> operators who chase trunk but whose users require stability.\n> \n> The only group that benefits from enshrining the choice in the API - \n> users who want to experiment with the bleeding edge, but who don\'t \n> control their own OpenStack deployment - doesn\'t actually exist, and if \n> it did then this would be among the least of their problems.\n> \n\nLast I checked there was at least one limited beta of a public Heat\nwhere the users don\'t control their cloud directly. Also it\'s likely in\ncorporate environments that the Heat users won\'t control the Heat\nservice directly. But those users may be ready to try concurrent updates\nbefore the feature has fully stabilized.\n\nAnyway, there\'s one facet you might have missed, which is that by putting\nit in the API you serve the users who can\'t immediately adapt to changes\nin the new engine\'s behavior, and want to use the old behavior.\n\n> > Finally, there are also some benefits to heat developers. Creating a\n> > whole new gate job to test convergence-enabled heat will consume its\n> > share of CI resource. I\'m hoping to make it possible for some of our\n> > functional tests to run against a number of scenarios/environments.\n> > Being able to run tests under classic and convergence scenarios in one\n> > test run will be a great help (for performance profiling too).\n> \n> I think this is the strongest argument in favour. However, I\'d like to \n> think it would be possible to run the functional tests twice in the \n> gate, changing the config and restarting the engine in between.\n> \n> But if the worst comes to the worst, then although I think it\'s \n> preferable to use one VM for twice as long vs. two VMs for the same \n> length of time, I don\'t think the impact on resource utilisation in the \n> gate of choosing one over the other is likely to be huge. And I don\'t \n> see this situation persisting for a long time. The purpose of running \n> both sets of tests is to buy us time to write a migration tool without \n> having to delay flipping the config switch until it is ready. So we\'d \n> likely only have to continue running the legacy tests for one release cycle.\n> \n\nThe matrix of config settings should just be assumed to be ludicrous\nat this point. So adding one more full iteration in the test matrix\nis, I think, out of the question. But testing that interface surface\narea hasn\'t diverged in ways that we don\'t expect is a more tractable\nproblem. That said, I see this as a temporary improvement, so I don\'t\nreally think it is \"the reason\" to offer the option.\n\n\n','<54D10CCC.2020707@redhat.com>',NULL),('<1422990391.6078.5.camel@einstein.kev>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-03 13:06:31',-21600,'2015-02-03 19:06:31',NULL,'[openstack-dev] The API WG mission statement','On Tue, 2015-02-03 at 18:49 +0000, Everett Toews wrote:\n> I?ll echo Mike?s sentiment that we should be very mindful of the idea\n> that these are guidelines not hard standards. Hmmmm?even that might be\n> a bit restrictive. In the Openstack HTTP error codes [1] discussion\n> I?m getting the impression that there is a desire to make this a\n> standard. Perhaps we need to leave the door open to setting standards\n> in certain cases?\n\nI tend to be in the \"guideline for now\" camp, but I see us slowly\nshifting over to establishing standards where it makes sense.  Once the\nerror codes discussion truly starts to converge toward consensus\n(something I feel it\'s close to, but not quite there yet), it seems\nreasonable to make it a guideline.  As far as standards go?if we go with\nthe idea of header addition to tell the client about the codes, it\nbecomes something that can easily be added to all OpenStack APIs, and\nonce that happens, then I can foresee it becoming a formal standard\nrecommended by the API WG?\n-- \nKevin L. Mitchell <kevin.mitchell at rackspace.com>\nRackspace\n\n\n\n','<F5FF10DD-D73A-421A-AAA4-B00090575028@rackspace.com>',NULL),('<1423065769.3732956.223055213.5FEC9358@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2015-02-04 08:02:49',-28800,'2015-02-04 16:02:49',NULL,'[OpenStack-Infra] Code Review needs another verified','\n\nOn Wed, Feb 4, 2015, at 07:51 AM, MICHON Anthony wrote:\n> Hi all\n> \n> We committed some change on a newly created project and the review\n> (https://review.openstack.org/#/c/147182/\n> )  needs another +1 verified, Jenkins gave +1 but how give another +1 ?\n> It seems that others projects do not need a +2 verified to pass to the\n> next step  (example here : https://review.openstack.org/#/c/140517/)\n> Does it missing some configuration somewhere, here are our Here are the\n> project-config files :\n> https://review.openstack.org/#/c/131989/\n> \nAll changes require +2 verified, +2 Code Review, and +1 Workflow in\norder to merge. In your example [0] the green checkmarks signify that\nthis is the case. At a quick glance your job config looks fine.\n\nI believe the reason your change is not going into the gate queue and\ngetting a +2 verified then merging is this change depends on an\nabandoned change [1] making it unmergable. I would just rebase your\nchange to remove this dependency then it should work as expected.\n\n[0] https://review.openstack.org/#/c/140517/\n[1] https://review.openstack.org/#/c/147121/\n\nClark\n\n\n','<0a29efdcd49f4e439418af1642d6fb0b@31L-EX02.eurogiciel.fr>',NULL),('<1423072608-sup-2106@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 10:13:58',-28800,'2015-02-04 18:13:58',NULL,'[openstack-dev] [nova][cinder][neutron][security] Rootwrap on\n	root-intensive nodes','Excerpts from Tristan Cacqueray\'s message of 2015-02-04 09:02:19 -0800:\n> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:\n> > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:\n> >> What solutions do we have ?\n> >>\n> >> (1) we could get our act together and audit and fix those filter\n> >> definitions. Remove superfluous usage of root rights, make use of\n> >> advanced filters for where we actually need them. We have been preaching\n> >> for that at many many design summits. This is a lot of work though...\n> >> There were such efforts in the past, but they were never completed for\n> >> some types of nodes. Worse, the bad filter definitions kept coming back,\n> >> since developers take shortcuts, reviewers may not have sufficient\n> >> security awareness to detect crappy filter definitions, and I don\'t\n> >> think we can design a gate test that would have such awareness.\n> >>\n> >> (2) bite the bullet and accept that some types of nodes actually need\n> >> root rights for so many different things, they should just run as root\n> >> anyway. I know a few distributions which won\'t be very pleased by such a\n> >> prospect, but that would be a more honest approach (rather than claiming\n> >> we provide efficient isolation when we really don\'t). An added benefit\n> >> is that we could replace a number of shell calls by Python code, which\n> >> would simplify the code and increase performance.\n> >>\n> >> (3) intermediary solution where we would run as the nova user but run\n> >> sudo COMMAND directly (instead of sudo nova-rootwrap CONFIG COMMAND).\n> >> That would leave it up to distros to choose between a blanket sudoer or\n> >> maintain their own filtering rules. I think it\'s a bit hypocritical\n> >> though (pretend the distros could filter if they wanted it, when we\n> >> dropped the towel on doing that ourselves). I\'m also not convinced it\'s\n> >> more secure than solution 2, and it prevents from reducing the number of\n> >> shell-outs, which I think is a worthy idea.\n> >>\n> >> In all cases I would not drop the baby with the bath water, and keep\n> >> rootwrap for all the cases where root rights are needed on a very\n> >> specific set of commands (like neutron, or nova\'s api-metadata). The\n> >> daemon mode should address the performance issue for the projects making\n> >> a lot of calls.\n> > \n> > \n> > (4) I think that ultimately we need to ditch rootwrap and provide a proper\n> > privilege separated, formal RPC mechanism for each project.\n> > \n> > eg instead of having a rootwrap command, or rootwrap server attempting\n> > to validate safety of\n> > \n> >     qemu-img create -f qcow2 /var/lib/nova/instances/instance00001/disk.qcow2\n> > \n> > we should have a  nova-compute-worker daemon running as root, that accepts\n> > an RPC command from nova-compute running unprivileged. eg\n> > \n> >     CreateImage(\"instane0001\", \"qcow2\", \"disk.qcow\")\n> > \n> > This immediately makes it trivial to validate that we\'re not trying to\n> > trick qemu-img into overwriting some key system file.\n> > \n> > This is certainly alot more work than trying to patchup rootwrap, but\n> > it would provide a level of security that rootwrap can never achieve IMHO.\n> > \n> \n> This 4th idea sounds interesting, though we are assuming this new service\n> running as root would be exempt of bug, especially if it uses the same\n> libraries as non-root services... For example a major bug in python would\n> give attacker direct root access while the rootwrap solution would in\n> theory keep the intruder at the sudo level...\n> \n\nI don\'t believe that anyone assumes the new service would be without\nbugs. But just like the OpenSSH team saw years ago, privilege separation\nmeans that you can absolutely know what is running as root, and what is\nnot. So when you decide to commit your resources to code audits, you\n_start_ with the things that run with elevated privileges.\n\n> \n> For completeness, I\'d like to propose a more long-term solution:\n> \n> (5) Get ride of root! Seriously, OpenStack could support security mechanism\n> like SELinux or AppArmor in order to properly isolate service and let them\n> run what they need to run.\n> \n> For what it worth, the underlying issue here is having a single almighty super\n> user: root and thus we should, at least, consider solution that remove the\n> need of such powers (e.g. kernel module loading, ptrace or raw socket).\n> \n\nWe don\'t need a security module to drop all of those capabilities\nentirely and run as a hobbled root user. By my measure, this process for\nnova-compute would only need CAP_NET_ADMIN, CAP_SYS_ADMIN and CAP_KILL.\nThese capabilities can be audited per-agent and even verified as needed\nsimply by running integration tests without each one to see what breaks.\n\n> Beside, as long as sensitive process are not contained at the system level,\n> the attack surface for a non-root user is still very wide (e.g. system calls,\n> setuid binaries, ipc, ...)\n> \n> \n> While this might sounds impossible to implement upstream because it\'s too\n> vendor specific or just because of other technicals difficulties,\n> I guess it still deserves a mention in this thread.\n> \n\nI think OpenStack can do its part by making privilege separation a\nreality for the security sensitive parts of OpenStack, and that will\nease pressure to implement strong controls in any security modules the\nLinux distros ship with.\n\n\n','<54D2509B.7090504@enovance.com>',NULL),('<1423073646-sup-8023@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 10:15:10',-28800,'2015-02-04 18:15:10',NULL,'[openstack-dev] [nova][cinder][neutron][security] Rootwrap on\n	root-intensive nodes','Excerpts from Daniel P. Berrange\'s message of 2015-02-04 03:57:53 -0800:\n> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:\n> > The first one is performance -- each call would spawn a Python\n> > interpreter which would then call the system command. This was fine when\n> > there were just a few calls here and there, not so much when it\'s called\n> > a hundred times in a row. During the Juno cycle, a daemon mode was added\n> > to solve this issue. It is significantly faster than running sudo\n> > directly (the often-suggested alternative). Projects still have to start\n> > adopting it though. Neutron and Cinder have started work to do that in Kilo.\n> > \n> > The second problem is the quality of the filter definitions. Rootwrap is\n> > a framework to enable isolation. It\'s only as good as the filters each\n> > project defines. Most of them rely on CommandFilters that do not check\n> > any argument, instead of using more powerful filters (which are arguably\n> > more painful to maintain). Developers routinely add filter definitions\n> > that basically remove any isolation that might have been there, like\n> > allowing blank dd, tee, chown or chmod.\n> \n> I think this is really the key point which shows rootwrap as a concept\n> is broken by design IMHO. Root wrap is essentially trying to provide an\n> API for invoking privileged operations, but instead of actually designing\n> an explicit API for the operations, we done by implicit one based on\n> command args. From a security POV I think this approach is doomed to\n> failure, but command arg strings are faaaar to expressive a concept\n> to deal with.\n> \n> > What solutions do we have ?\n> > \n> > (1) we could get our act together and audit and fix those filter\n> > definitions. Remove superfluous usage of root rights, make use of\n> > advanced filters for where we actually need them. We have been preaching\n> > for that at many many design summits. This is a lot of work though...\n> > There were such efforts in the past, but they were never completed for\n> > some types of nodes. Worse, the bad filter definitions kept coming back,\n> > since developers take shortcuts, reviewers may not have sufficient\n> > security awareness to detect crappy filter definitions, and I don\'t\n> > think we can design a gate test that would have such awareness.\n> > \n> > (2) bite the bullet and accept that some types of nodes actually need\n> > root rights for so many different things, they should just run as root\n> > anyway. I know a few distributions which won\'t be very pleased by such a\n> > prospect, but that would be a more honest approach (rather than claiming\n> > we provide efficient isolation when we really don\'t). An added benefit\n> > is that we could replace a number of shell calls by Python code, which\n> > would simplify the code and increase performance.\n> > \n> > (3) intermediary solution where we would run as the nova user but run\n> > sudo COMMAND directly (instead of sudo nova-rootwrap CONFIG COMMAND).\n> > That would leave it up to distros to choose between a blanket sudoer or\n> > maintain their own filtering rules. I think it\'s a bit hypocritical\n> > though (pretend the distros could filter if they wanted it, when we\n> > dropped the towel on doing that ourselves). I\'m also not convinced it\'s\n> > more secure than solution 2, and it prevents from reducing the number of\n> > shell-outs, which I think is a worthy idea.\n> > \n> > In all cases I would not drop the baby with the bath water, and keep\n> > rootwrap for all the cases where root rights are needed on a very\n> > specific set of commands (like neutron, or nova\'s api-metadata). The\n> > daemon mode should address the performance issue for the projects making\n> > a lot of calls.\n> \n> \n> (4) I think that ultimately we need to ditch rootwrap and provide a proper\n> privilege separated, formal RPC mechanism for each project.\n> \n> eg instead of having a rootwrap command, or rootwrap server attempting\n> to validate safety of\n> \n>     qemu-img create -f qcow2 /var/lib/nova/instances/instance00001/disk.qcow2\n> \n> we should have a  nova-compute-worker daemon running as root, that accepts\n> an RPC command from nova-compute running unprivileged. eg\n> \n>     CreateImage(\"instane0001\", \"qcow2\", \"disk.qcow\")\n> \n> This immediately makes it trivial to validate that we\'re not trying to\n> trick qemu-img into overwriting some key system file.\n> \n> This is certainly alot more work than trying to patchup rootwrap, but\n> it would provide a level of security that rootwrap can never achieve IMHO.\n> \n\n+1, I think you\'re right on Daniel. Count me in for future discussions\nand work on this.\n\n\n','<20150204115753.GO3032@redhat.com>',NULL),('<1423086935-sup-9833@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 13:59:10',-28800,'2015-02-04 21:59:10',NULL,'[openstack-dev] [all][oslo.db][nova] TL;\n	DR Things everybody should know about Galera','Excerpts from Matthew Booth\'s message of 2015-02-04 08:30:32 -0800:\n> * Write followed by read on a different node can return stale data\n> \n> During a commit, Galera replicates a transaction out to all other db\n> nodes. Due to its design, Galera knows these transactions will be\n> successfully committed to the remote node eventually[2], but it doesn\'t\n> commit them straight away. The remote node will check these outstanding\n> replication transactions for write conflicts on commit, but not for\n> read. This means that you can do:\n> \n> A: start transaction;\n> A: insert into foo values(1)\n> A: commit;\n> B: select * from foo; <-- May not contain the value we inserted above[3]\n> \n> This means that even for \'synchronous\' slaves, if a client makes an RPC\n> call which writes a row to write master A, then another RPC call which\n> expects to read that row from synchronous slave node B, there\'s no\n> default guarantee that it\'ll be there.\n> \n> Galera exposes a session variable which will fix this: wsrep_sync_wait\n> (or wsrep_causal_reads on older mysql). However, this isn\'t the default.\n> It presumably has a performance cost, but I don\'t know what it is, or\n> how it scales with various workloads.\n> \n\nwsrep_sync_wait/wsrep_casual_reads doesn\'t actually hit the cluster\nany harder, it simply tells the local Galera node \"if you\'re not caught\nup with the highest known sync point, don\'t answer queries yet\". So it\nwill slow down that particular query as it waits for an update from the\nleader about sync point and, if necessary, waits for the local engine\nto catch up to that point. However, it isn\'t going to push that query\noff to all the other boxes or anything like that.\n\n\n','<54D24928.1050006@redhat.com>',NULL),('<1423087155-sup-1516@fewbar.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 14:04:29',-28800,'2015-02-04 22:04:29',NULL,'[openstack-dev] [all][oslo.db][nova] TL;\n	DR Things everybody should know about Galera','Excerpts from Joshua Harlow\'s message of 2015-02-04 13:24:20 -0800:\n> How interesting,\n> \n> Why are people using galera if it behaves like this? :-/\n> \n\nNote that any true MVCC database will roll back transactions on\nconflicts. One must always have a deadlock detection algorithm of\nsome kind.\n\nGalera behaves like this because it is enormously costly to be synchronous\nat all times for everything. So it is synchronous when you want it to be,\nand async when you don\'t.\n\nNote that it\'s likely NDB (aka \"MySQL Cluster\") would work fairly well\nfor OpenStack\'s workloads, and does not suffer from this. However, it\nrequires low latency high bandwidth links between all nodes (infiniband\nrecommended) or it will just plain suck. So Galera is a cheaper, easier\nto tune and reason about option.\n\n> Are the people that are using it know/aware that this happens? :-/\n> \n\nI think the problem really is that it is somewhat de facto, and used\nwithout being tested. The gate doesn\'t set up a three node Galera db and\ntest that OpenStack works right. Also it is inherently a race condition,\nand thus will be a hard one to test.\n\nThats where having knowledge of it and taking time to engineer a\nsolution that makes sense is really the best course I can think of.\n\n\n','<BLU436-SMTP2073D53870923572C4A709ED83A0@phx.gbl>',NULL),('<1423088368.84048.223224053.34C58A6B@webmail.messagingengine.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-04 17:19:28',-18000,'2015-02-04 22:19:28',NULL,'[openstack-dev] [oslo][nova][cinder] removing request_utils\n from oslo-incubator','I was primarily trying to explain what happened for ankit_ag, since we\ndon\'t seem to overlap on IRC.\n\nIf someone cares about the feature, they should get the cross-project\nspec going because I don\'t think this is something only nova cores\nshould be deciding.\n\nOn Wed, Feb 4, 2015, at 04:34 PM, Davanum Srinivas wrote:\n> Doug,\n> \n> So the ball is in the Nova core(s) court?\n> \n> -- dims\n> \n> On Wed, Feb 4, 2015 at 12:16 PM, Doug Hellmann <doug at doughellmann.com>\n> wrote:\n> > About 12 hours ago in #openstack-oslo ankit_ag asked about the request_utils module that was removed from oslo-incubator and how to proceed to get it into nova.\n> >\n> > The module was deleted a few days ago [1] because nothing was actually using it and it appeared to be related to a nova blueprint [2], the spec for which was abandoned at the end of juno [3]. The one copy that had been synced into cinder wasn?t being used, and was also deleted [4] as part of this housekeeping work.\n> >\n> > As I said in the review, we removed the code from the incubator because it appeared to be a dead end. If that impression is incorrect, we should get the spec and blueprint resurrected (probably as a cross-project spec rather than just in nova) and then we can consider the best course for proceeding with the implementation.\n> >\n> > Doug\n> >\n> > [1] https://review.openstack.org/#/c/150370/\n> > [2] https://blueprints.launchpad.net/nova/+spec/log-request-id-mappings\n> > [3] https://review.openstack.org/#/c/106878/\n> > [4] https://review.openstack.org/#/c/150369/\n> > __________________________________________________________________________\n> > OpenStack Development Mailing List (not for usage questions)\n> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> -- \n> Davanum Srinivas :: https://twitter.com/dims\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe:\n> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CANw6fcEYQD+BGErm7uRD+8FVJy+zRhw23M9x7m63VKD=5NOGiA@mail.gmail.com>',NULL),('<1423195600.2543934.1384643372002.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-16 18:09:32',-18000,'2013-11-16 23:09:32',NULL,'[Openstack-docs] Broken MySQL chapter','----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: \"Gauvain Pocentek\" <gauvain.pocentek at objectif-libre.com>\n> Cc: \"openstack-docs\" <openstack-docs at lists.openstack.org>\n> Sent: Saturday, November 16, 2013 5:54:12 PM\n> Subject: Re: [Openstack-docs] Broken MySQL chapter\n> \n> ----- Original Message -----\n> > From: \"Gauvain Pocentek\" <gauvain.pocentek at objectif-libre.com>\n> > To: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> > Cc: \"openstack-docs\" <openstack-docs at lists.openstack.org>\n> > Sent: Saturday, November 16, 2013 12:42:36 AM\n> > Subject: Re: [Openstack-docs] Broken MySQL chapter\n> > \n> > Hey,\n> > \n> > Le 15/11/2013 22:01, Anne Gentle a ?crit?:\n> > > Any root cause we can avoid?\n> > \n> > If we were dealing with code I\'d say \"we lack unit tests\", but for\n> > documentation it is probably very hard to manage (are there some tools\n> > out there to test documentation?).\n> \n> Doing \"proper\" CI with full coverage that actually extracts and runs all the\n> instructions is difficult, but in this case I think we could pick the cause\n> of the issue up in validation. I\'ve proposed an update to test.py here:\n> \n>     https://review.openstack.org/#/c/56790/\n> \n> For the change in question the output would have been:\n> \n> python ./tools/test.py --check-syntax\n> Checking syntax of xml files...\n>  Validating install-guide/ch_basics.xml\n>   install-guide/ch_basics.xml: {http://docbook.org/ns/docbook}itemizedlist os\n>   profiling ([\'opensuse\', \'sles\']) conflicts with os profiling of\n>   {http://docbook.org/ns/docbook}screen on line 276.\n> Check failed, validated 1 xml files with 1 failures.\n\nRunning this against all books I found a few other instances of this problem we need to look at:\n\nChecking syntax of all xml files...\n  install-guide/section_dashboard-install.xml: {http://docbook.org/ns/docbook}step os profiling ([\'opensuse\', \'sles\', \'fedora\', \'centos\', \'rhel\']) conflicts with os profiling of {http://docbook.org/ns/docbook}screen on line 177.\n  install-guide/section_glance-install.xml: {http://docbook.org/ns/docbook}step os profiling ([\'rhel\', \'centos\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}para on line 60.\n  install-guide/section_nova-compute.xml: {http://docbook.org/ns/docbook}step os profiling ([\'rhel\', \'centos\', \'fedora\']) conflicts with os profiling of {http://docbook.org/ns/docbook}screen on line 97.\n  install-guide/section_heat-install.xml: {http://docbook.org/ns/docbook}procedure os profiling ([\'rhel\', \'centos\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}para on line 39.\n  install-guide/section_nova-controller.xml: {http://docbook.org/ns/docbook}step os profiling ([\'rhel\', \'centos\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}para on line 61.\n  install-guide/section_ceilometer-install.xml: {http://docbook.org/ns/docbook}step os profiling ([\'rhel\', \'centos\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}para on line 123.\n  install-guide/section_cinder-node.xml: {http://docbook.org/ns/docbook}step os profiling ([\'centos\', \'rhel\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}programlisting on line 117.\n  install-guide/section_cinder-controller.xml: {http://docbook.org/ns/docbook}step os profiling ([\'rhel\', \'centos\', \'fedora\', \'opensuse\', \'sles\', \'ubuntu\']) conflicts with os profiling of {http://docbook.org/ns/docbook}para on line 38.\nCheck failed, validated 717 xml files with 8 failures.\n\nFor the most part they seem to be cases where the os profile of the parent lists every os *except* debian and then one of the children has os=\"debian\".\n\n-Steve\n\n\n','<2135062921.2543731.1384642452369.JavaMail.root@redhat.com>',NULL),('<1424114507.4.1375768933479.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-06 06:02:13',0,'2013-08-06 06:02:13',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #1','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/1/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-104 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #95 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stress] $ /bin/bash -xe /tmp/hudson6954091212599143922.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stress] $ /bin/bash -xe /tmp/hudson7601380120388413452.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_STRESS=1\n+ DEVSTACK_GATE_TEMPEST_STRESS=1\n+ export ZUUL_BRANCH=master\n+ ZUUL_BRANCH=master\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-104\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-104/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-104/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-104/1/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1426885168.30.1352592283381.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-11 00:04:43',0,'2012-11-11 00:04:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-diablo #89','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/89/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/>\nCheckout:periodic-horizon-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/> - hudson.remoting.Channel at 740355a4:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson8973715951659953595.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-diablo/89\n[SCP] Copying console log.\n\n\n','<89441382.16.1352505843173.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1427292782.3.1352419480763.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:04:40',0,'2012-11-09 00:04:40',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #87','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/87/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.35\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.06\n    test_public_versions                                        OK  0.06\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 18.250s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 6.86 secs:\n    2.20       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    2.17       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    0.35       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at d471f65231427d54c329697982533e6868b7cdb1#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 65554ea32f0b35b7ba623dccb92489f556d89efa#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1427844916.160801412190585008.JavaMail.nobody@grtx1rmd003.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-01 19:09:45',0,'2014-10-01 19:09:45',NULL,'[OpenStack Foundation] Invitation to OpenStack High 5 Board Wrapup\n	November 6, 2014','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack High 5 Board Wrapup November 6, 2014\nHost: Alan Clark\nDate: Thursday, November 6, 2014\nTime: 8:00 am, Pacific Standard Time (San Francisco, GMT-08:00)\nSession number: 494 157 894\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t516895ebafcb2cf3e50833feef793a33\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t5e94dde746d24f961f8cf7eedc58f1ef\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=ted524d960c7eecbc5091129b1d5f873e\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=300257313&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 494 157 894\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20141001/fe88e387/attachment.html>\n\n',NULL,NULL),('<1427875843.54724500.1413898989946.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-21 09:43:09',-14400,'2014-10-21 13:43:09',NULL,'[openstack-dev] [Keystone] Question regarding Service Catalog\n and	Identity entries...','\n\n----- Original Message -----\n> From: \"Ben Meyer\" <ben.meyer at rackspace.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Monday, October 20, 2014 3:53:39 PM\n> Subject: Re: [openstack-dev] [Keystone] Question regarding Service Catalog and	Identity entries...\n> \n> On 10/20/2014 08:12 AM, Jamie Lennox wrote:\n> > ----- Original Message -----\n> >> From: \"Ben Meyer\" <ben.meyer at rackspace.com>\n> >> To: openstack-dev at lists.openstack.org\n> >> Cc: \"Jamie Painter\" <jamie.painter at rackspace.com>\n> >> Sent: Tuesday, October 7, 2014 4:31:16 PM\n> >> Subject: [openstack-dev] [Keystone] Question regarding Service Catalog and\n> >> 	Identity entries...\n> >>\n> >> I am trying to use the Python Keystone client to integration\n> >> authentication functionality into a project I am contributing to\n> >> (https://github.com/rackerlabs/deuce-client).\n> >> However, I ran into a situation where if I do the following:\n> >>\n> >>>>> c = keystoneclient.v2_0.client.Client(username=\'username\',\n> >> password=\'password\',\n> >> auth_url=\"https://keystone-compatible-service.example.com/v2.0/\")\n> >> Failed to retrieve management_url from token\n> >>\n> >> I traced it through the Python Keystoneclient code and it fails due to\n> >> not finding the \"identity\" service entry in the Service Catalog. The\n> >> authentication otherwise happens in that it has already received a\n> >> \"successful\" response and a full Service Catalog, aside from the\n> >> \"missing\" identity service. This happens with both version 0.10 and 0.11\n> >> python keystone clients; I did not try older clients.\n> >>\n> >> Talking with the service provider, their version does not include itself\n> >> in the Service Catalog, and they learned the Keystone itself inserts\n> >> itself into the Service Catalog.\n> >> I can certainly understand why it having the identity service entry be\n> >> part of the Service Catalog, but for them it is (at least for now) not\n> >> desirable to do so.\n> >>\n> >> Questions:\n> >> - Is it now a standard that Keystone inserts itself into the Service\n> >> Catalog?\n> > It\'s not a standard that keystone inserts itself into the catalog, the\n> > cloud operator should maintain the list of endpoints for their deployment\n> > and the \'identity\' service should be amongst those endpoints. I\'m unclear\n> > as to why it would be undesirable to list the identity endpoint in the\n> > service catalog. How would this addition change their deployment?\n> The argument is that the Service Catalog is too big so they are hesitant\n> to add new entries to it; and \'identity\' in the catalog is redundant\n> since you have to know the \'identity\' end-point to even get the service\n> catalog in the first place.\n> \n> Not saying I agree, just that\'s the argument being made. If it is\n> \"required by Keystone\" to be self-referential then they are likely to\n> add it.\n\nIt\'s required for the CRUD operations (managing users, projects, roles etc) of keystoneclient. Whether it\'s realistic that you would ever separate the auth process to a different host than the keystone CRUD I\'m not sure, i\'ve never seen it, but the idea is that beyond that initial auth contact there really is no difference between keystone and any other service and keystoneclient will look up the catalog to determine how to talk to keystone. \n\n> > The problem with the code that you provided is that the token that is being\n> > returned from your code is unscoped. Which means that it is not associated\n> > with a project and therefore it doesn\'t have a service catalog because the\n> > catalog can be project specific. Thus when you go to perform an operation\n> > the client will look for the URL it is supposed to talk to in an empty\n> > list and fail to find the identity endpoint. This message really needs to\n> > be improved. If you add a project_id or project_name to the client\n> > information then you should get back a token with a catalog.\n> \n> In my normal case I\'m using the project_id field; but have found that it\n> didn\'t really matter what was used for the credentials in this case\n> since they simply don\'t have the \'identity\' end-points in the Service\n> Catalog.\n> \n> >> - Or is the Python Keystone Client broken because it is forcing it to be\n> >> so?\n> > I wouldn\'t say that it is broken because having an identity endpoint in\n> > your catalog is a required part of a deployment, in the same way that\n> > having a \'compute\' endpoint is required if you want to talk to nova. I\n> > would be surprised by any decision to purposefully omit the \'identity\'\n> > endpoint from the service catalog.\n> \n> See above; but from what you are presenting here it sounds like the\n> deployment is \"broken\" so it is in fact \"required by Keystone\", even if\n> only \"a required part of a deployment\".\n\nAs keystoneclient is used by heat, horizon etc I would think it\'s safe to say it\'s required. \n\n> Thanks\n> \n> Ben\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<544513E3.8030105@rackspace.com>',NULL),('<1428110352.25317591.1402514571012.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-11 15:22:51',-14400,'2014-06-11 19:22:51',NULL,'[openstack-dev] [nova][ceilometer] FloatingIp pollster	spamming\n n-api logs (bug 1328694)','\n> > Thanks for bringing this to the list Matt, comments inline ...\n> >\n> >> tl;dr: some pervasive changes were made to nova to enable polling in\n> >> ceilometer which broke some things and in my opinion shouldn\'t have been\n> >> merged as a bug fix but rather should have been a blueprint.\n> >>\n> >> ===\n> >>\n> >> The detailed version:\n> >>\n> >> I opened bug 1328694 [1] yesterday and found that came back to some\n> >> changes made in ceilometer for bug 1262124 [2].\n> >>\n> >> Upon further inspection, the original ceilometer bug 1262124 made some\n> >> changes to the nova os-floating-ips API extension and the database API\n> >> [3], and changes to python-novaclient [4] to enable ceilometer to use\n> >> the new API changes (basically pass --all-tenants when listing floating\n> >> IPs).\n> >>\n> >> The original nova change introduced bug 1328694 which spams the nova-api\n> >> logs due to the ceilometer change [5] which does the polling, and right\n> >> now in the gate ceilometer is polling every 15 seconds.\n> >\n> > IIUC that polling cadence in the gate is in the process of being reverted\n> > to the out-of-the-box default of 600s.\n> >\n> >> I pushed a revert in ceilometer to fix the spam bug and a separate patch\n> >> was pushed to nova to fix the problem in the network API.\n> >\n> > Thank you for that. The revert is just now approved on the ceilometer side,\n> > and is wending its merry way through the gate.\n> >\n> >> The bigger problem I see here is that these changes were all made under\n> >> the guise of a bug when I think this is actually a blueprint.  We have\n> >> changes to the nova API, changes to the nova database API, CLI changes,\n> >> potential performance impacts (ceilometer can be hitting the nova\n> >> database a lot when polling here), security impacts (ceilometer needs\n> >> admin access to the nova API to list floating IPs for all tenants),\n> >> documentation impacts (the API and CLI changes are not documented), etc.\n> >>\n> >> So right now we\'re left with, in my mind, two questions:\n> >>\n> >> 1. Do we just fix the spam bug 1328694 and move on, or\n> >> 2. Do we revert the nova API/CLI changes and require this goes through\n> >> the nova-spec blueprint review process, which should have happened in\n> >> the first place.\n> >\n> > So just to repeat the points I made on the unlogged #os-nova IRC channel\n> > earlier, for posterity here ...\n> >\n> > Nova already exposed an all_tenants flag in multiple APIs (servers,\n> > volumes,\n> > security-groups etc.) and these would have:\n> >\n> >    (a) generally pre-existed ceilometer\'s usage of the corresponding APIs\n> >\n> > and:\n> >\n> >    (b) been tracked and proposed at the time via straight-forward LP bugs,\n> >        as  opposed to being considered blueprint material\n> >\n> > So the manner of the addition of the all_tenants flag to the floating_ips\n> > API looks like it just followed existing custom & practice.\n> >\n> > Though that said, the blueprint process and in particular the nova-specs\n> > aspect, has been tightened up since then.\n> >\n> > My preference would be to fix the issue in the underlying API, but to use\n> > this as \"a teachable moment\" ... i.e. to require more oversight (in the\n> > form of a reviewed & approved BP spec) when such API changes are proposed\n> > in the future.\n> >\n> > Cheers,\n> > Eoghan\n> >\n> >> Are there other concerns here?  If there are no major objections to the\n> >> code that\'s already merged, then #2 might be excessive but we\'d still\n> >> need docs changes.\n> >>\n> >> I\'ve already put this on the nova meeting agenda for tomorrow.\n> >>\n> >> [1] https://bugs.launchpad.net/ceilometer/+bug/1328694\n> >> [2] https://bugs.launchpad.net/nova/+bug/1262124\n> >> [3] https://review.openstack.org/#/c/81429/\n> >> [4] https://review.openstack.org/#/c/83660/\n> >> [5] https://review.openstack.org/#/c/83676/\n> >>\n> >> --\n> >>\n> >> Thanks,\n> >>\n> >> Matt Riedemann\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> While there is precedent for --all-tenants with some of the other APIs,\n> I\'m concerned about where this stops.  When ceilometer wants polling on\n> some other resources that the nova API exposes, will it need the same\n> thing?  Doing all of this polling for resources in all tenants in nova\n> puts an undue burden on the nova API and the database.\n\nYes, that\'s a fair point.\n\nThe only other existing usage of a nova API all_tenants flag by\nceilometer is on the nova servers API, but that\'s more self-\nlimiting by virtue of the fact that the query is also constrained\nby host (i.e. to discover details for all instances running on a\nsingle compute node).\n\nEven in that single existing case, we have some ideas on how to\nreduce the API polling frequency by detecting when these details\nneed to be refreshed (e.g. only when a new instance is booted, or\nan existing instance is resized or migrated).\n\n> Can we do something with notifications here instead?  That\'s where the\n> nova-spec process would have probably caught this.\n\nOK, there is possibly a case for rebasing this aspect of floating IP\ndiscovery on notifications as opposed to polling. I\'ll discuss further\nwith the original author.\n\nCheers,\nEoghan\n\n\n','<5398A21A.9030600@linux.vnet.ibm.com>',NULL),('<14286a54f50.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-23 12:27:35',-28800,'2013-11-23 20:27:35',NULL,'[openstack-dev] tenant or project','\n\nOn November 23, 2013 4:09:49 AM Christopher Yeoh <cbkyeoh at gmail.com> wrote:\n> Hi,\n>\n> So in the past we\'ve used both tenant and project to refer to the same\n> thing and I think its been a source of confusion for people new to\n> OpenStack. In the Nova code we use both, but at least for the API we\'ve\n> been trying to consistently present to the client tenant (which is the\n> majority usage) rather than project.\n> And then Russell pointed out in https://review.openstack.org/#/c/57612/\n> that the Keystone uses project in the Keystone V3 API rather than\n> tenant. http://api.openstack.org/api-ref-identity.html#identity-v3\n>\n> I think that we should be consistent across the openstack projects.\n> From a very quick look at the core openstack projects I think that they\n> mostly use tenant at the moment rather than project.\n>\n> Does this change in Keystone nomenclature signify that we all should be\n> moving to use project rather than tenant in the future (its not\n> too late to do a big a search and replace for the Nova V3 API). And is\n> the plan for Keystone python client to also change to project rather\n> than tenant?\n>\n\nThe advantage of \"Tenant\" over \"project\" is that it is far more intuitively \nobvious\nthat resources and users belong to a single tenant than it is that they \nbelong to\na single project.\n\nCompanies that are the customers of data centers are likely to have many\n\"projects\", and want their employees to have access to multiple projects.\nI think we are better off with a label that creates a clear expectation of\none-bill-payer equals one-tenant.\n\nAll the data is far simpler with that rule.\n\n\n\n\n\n','<20131123223949.22e00ec2@rockhopper>',NULL),('<142883745a8.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-23 19:46:35',-28800,'2013-11-24 03:46:35',NULL,'[openstack-dev] tenant or project','I have seen several people request that their users be members of two \n\"projects\" and that they be allow to publish objects that are \"Shared\" by \nmultiple \"projects\".\n\nFor some reason the people who request these complex data constructions \nalways prefer to call the enclosing entity a \"project\". I have not heard \nsuch a request for multi-tenant objects and/or users.\n\nThe important point is that the \"mix and match\" approach actually creates \ncomplex objects where it is difficult to determine who has the right to \ndelete them, modify them, change who has access to them, etc. The far \nsimpler rule\nis that all objects/resources have a single owner, whether that owner is \ncalled a \"project\" or a \"tenant\".\n\nThe term \"project\", in common english usage, does not have any semantics \nimplying exclusivity. Indeed we have \"Cross project teams\" and resources \nare commonly shared by multiple projects within one company.\n\nThe fact that \"projects\" are typically things *within* a company is exactly \nwhy it is a poor term for the outermost enclosure of resources.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/d71e7659/attachment.html>\n\n','<14288339c28.27c8.bb076ccec8ae525cad5cdfe3be415180@nexenta.com>',NULL),('<1429FDD3-563A-490E-9F57-66D0700B9330@motorolasolutions.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-11 22:49:30',0,'2014-02-11 22:49:30',NULL,'[Openstack] Neutron (Havana) configuration on Ubuntu','Oops! forgot to hit ?reply all?.  Sorry for the duplicates? Also adding additional observations/questions.\n\nWhen I attach to the compute node, I don?t see any network namespaces. Is this normal? Admittedly, I haven?t read up on all the gory details of neutron (which I probably need to do this evening).\n\nOriginal message follows:\n\n-------------------------\n\nHi Yuanle,\n\nOK, checking the console log, it doesn?t appear that my instance is getting the dhcp assigned address?\n\n--------\nStarting network...\nudhcpc (v1.20.1) started\nSending discover...\nSending discover...\nSending discover...\nNo lease, failing\nWARN: /etc/rc3.d/S40-network failed\ncirros-ds \'net\' up at 181.14\nchecking http://169.254.169.254/2009-04-04/instance-id\nfailed 1/20: up 181.15. reques\n????\n\nand later, in summary I see?\n\n=== network info ===\nif-info: lo,up,127.0.0.1,8,::1\nif-info: eth0,up,,8,fe80::f816:3eff:fe56:3612\n=== datasource: None None ===\n=== cirros: current=0.3.1 uptime=221.94 ===\nroute: fscanf\n=== pinging gateway failed, debugging connection ===\n############ debug start ##############\n### /etc/init.d/sshd start\nStarting dropbear sshd: OK\nroute: fscanf\n### ifconfig -a\neth0      Link encap:Ethernet  HWaddr FA:16:3E:56:36:12  \n         inet6 addr: fe80::f816:3eff:fe56:3612/64 Scope:Link\n         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1\n         RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n         TX packets:8 errors:0 dropped:0 overruns:0 carrier:0\n         collisions:0 txqueuelen:1000 \n         RX bytes:468 (468.0 B)  TX bytes:1112 (1.0 KiB)\n\nlo        Link encap:Local Loopback  \n         inet addr:127.0.0.1  Mask:255.0.0.0\n         inet6 addr: ::1/128 Scope:Host\n         UP LOOPBACK RUNNING  MTU:16436  Metric:1\n         RX packets:12 errors:0 dropped:0 overruns:0 frame:0\n         TX packets:12 errors:0 dropped:0 overruns:0 carrier:0\n         collisions:0 txqueuelen:0 \n         RX bytes:1020 (1020.0 B)  TX bytes:1020 (1020.0 B)\n\n### route -n\nKernel IP routing table\nDestination     Gateway         Genmask         Flags Metric Ref    Use Iface\n\nI don?t see anything in the logs that indicates a problem to me, so I?m missing something.  Checking the DHCP logs on the network/controller node I see the address is being allocated.  The instance, however, isn?t seeing the DHCP server. Multi-cast issue? Any guidance is appreciated and thanks again. \n\nRegards,\n/ross\n\nOn Feb 10, 2014, at 7:58 PM, sylecn <sylecn at gmail.com> wrote:\n\n> Hi Ross,\n> \n> 1. Make sure you have enabled ping (ICMP) in security groups.\n>    The default security groups does not allow ping.\n> \n>    neutron security-group-rule-create --direction ingress --protocol icmp $SG_ID\n> \n>    I suggest you explicitly create security group and use that when you\n>    boot instance. In this case, I see two security groups named\n>    \"default\". Better add that rule for both.\n> \n> 2. Check whether you can ping the fixed ip.\n>    Run on the neutron node:\n> \n>    sudo ip netns exec qrouter-43c596c4-65fe-4c22-a48a-0a6e200abf78 ping -c 4 10.0.1.2\n> \n> 3. Check console log of the vm. Did it boot correctly? Did it get IP from DHCP?\n> \n>    nova console-log tvm1\n> \n> Thanks,\n> Yuanle\n> \n> \n> \n> On Tue, Feb 11, 2014 at 8:52 AM, Lillie Ross-CDSR11 <Ross.Lillie at motorolasolutions.com> wrote:\n> If this issue has already been discussed, please excuse.\n> \n> I?m somewhat confused about neutron configuration and tenancy. Correct me if I?m wrong. \n> \n> First, I?ve create a private network under the ?admin? tenant named ?admin-net\'. I?ve associated a subnet named admin-net.1 with the admin-net with a CIDR of 10.0.1.0/24.\n> \n> Next, I created a network with router:external set to True associated with our campus network named ?campus-net?.  This network was created under the ?service? tenant?. I also create a router named ?campus-gw? under the ?service? tenant and set it?s gateway to be the ?campus-net? network.\n> \n> Finally, I create a floating address pool under the ?admin? tenant named ?admin-net.float\', and add it as an interface to the ?campus-gw? router.  I also create a default security group under the ?admin? tenant to allow SSH and ICMP access.\n> \n> When I boot an image, as a member of the admin tenant, the instance is correctly assigned an IP address from the admin tenant?s private network.  I next allocate (nova floating-ip-create admin-net.float) a floating IP address and associated it my running instance.\n> \n> However, I?m unable to ping the running instance, and I see no indication of the end of the tunnel being established on the network/controller node.\n> \n> I?m not that well versed with network namespaces nor the openvswitch commands. \n> \n> 2 questions.  Does my overall configuration sound correct? And how best to diagnose what?s going on here?  Any pointers would be helpful. Additional details can be provided as needed.  Thanks loads in advance.\n> \n> Regards,\n> /ross\n> \n> ?\n> \n> (neutron) net-list\n> +--------------------------------------+------------+----------------------------------------------------+\n> | id                                   | name       | subnets                                            |\n> +--------------------------------------+------------+----------------------------------------------------+\n> | 2426f4d8-a983-4f50-ab5a-fd2a37e5cd94 | campus-net | a948538d-c2c2-4c02-9116-b89a79f0c73a 173.23.0.0/16 |\n> | e6984375-f35b-4636-a293-43d0d296e0ff | admin-net  | 2ced890b-944f-4f6e-8f7a-3f5a4d07c2bb 10.0.1.0/24   |\n> +--------------------------------------+------------+----------------------------------------------------+\n> (neutron) subnet-list\n> +--------------------------------------+--------------------+---------------+---------------------------------------------------+\n> | id                                   | name               | cidr          | allocation_pools                                  |\n> +--------------------------------------+--------------------+---------------+---------------------------------------------------+\n> | 2ced890b-944f-4f6e-8f7a-3f5a4d07c2bb | admin-net.1        | 10.0.1.0/24   | {\"start\": \"10.0.1.2\", \"end\": \"10.0.1.254\"}        |\n> | a948538d-c2c2-4c02-9116-b89a79f0c73a | admin-net.floating | 173.23.0.0/16 | {\"start\": \"173.23.182.2\", \"end\": \"173.23.182.15\"} |\n> +--------------------------------------+--------------------+---------------+---------------------------------------------------+\n> (neutron) router-list\n> +--------------------------------------+-----------+-----------------------------------------------------------------------------+\n> | id                                   | name      | external_gateway_info                                                       |\n> +--------------------------------------+-----------+-----------------------------------------------------------------------------+\n> | 43c596c4-65fe-4c22-a48a-0a6e200abf78 | campus-gw | {\"network_id\": \"2426f4d8-a983-4f50-ab5a-fd2a37e5cd94\", \"enable_snat\": true} |\n> +--------------------------------------+-----------+-----------------------------------------------------------------------------+\n> (neutron) router-show campus-gw\n> +-----------------------+-----------------------------------------------------------------------------+\n> | Field                 | Value                                                                       |\n> +-----------------------+-----------------------------------------------------------------------------+\n> | admin_state_up        | True                                                                        |\n> | external_gateway_info | {\"network_id\": \"2426f4d8-a983-4f50-ab5a-fd2a37e5cd94\", \"enable_snat\": true} |\n> | id                    | 43c596c4-65fe-4c22-a48a-0a6e200abf78                                        |\n> | name                  | campus-gw                                                                   |\n> | routes                |                                                                             |\n> | status                | ACTIVE                                                                      |\n> | tenant_id             | service                                                                     |\n> +-----------------------+-----------------------------------------------------------------------------+\n> (neutron) security-group-list\n> +--------------------------------------+---------+-------------+\n> | id                                   | name    | description |\n> +--------------------------------------+---------+-------------+\n> | 0d66a3e2-7a0f-4caf-8b63-c3c8f3106242 | default | default     |\n> | c87230fa-9193-47a7-8ade-cec5f7f6b958 | default | default     |\n> +--------------------------------------+---------+-------------+\n> (neutron) \n> root at cirrus3:/var/log/neutron# nova list\n> +--------------------------------------+------+--------+------------+-------------+----------------------------------+\n> | ID                                   | Name | Status | Task State | Power State | Networks                         |\n> +--------------------------------------+------+--------+------------+-------------+----------------------------------+\n> | ccdf7541-3a74-4289-a8ce-9fe5cffe9dbd | tvm1 | ACTIVE | None       | Running     | admin-net=10.0.1.2, 173.23.182.3 |\n> +--------------------------------------+------+--------+------------+-------------+----------------------------------+\n> root at cirrus3:/var/log/neutron# nova show tvm1\n> +--------------------------------------+----------------------------------------------------------+\n> | Property                             | Value                                                    |\n> +--------------------------------------+----------------------------------------------------------+\n> | status                               | ACTIVE                                                   |\n> | updated                              | 2014-02-11T00:03:25Z                                     |\n> | OS-EXT-STS:task_state                | None                                                     |\n> | OS-EXT-SRV-ATTR:host                 | cn1                                                      |\n> | key_name                             | root                                                     |\n> | image                                | cirros (57a9f5d6-8b07-4bdb-b8a0-900de339d804)            |\n> | admin-net network                    | 10.0.1.2, 173.23.182.3                                   |\n> | hostId                               | 982cd20cde9c5f8514c95b5ca8530258fa9454cdc988a8b007a6d20b |\n> | OS-EXT-STS:vm_state                  | active                                                   |\n> | OS-EXT-SRV-ATTR:instance_name        | instance-00000021                                        |\n> | OS-SRV-USG:launched_at               | 2014-02-11T00:03:25.000000                               |\n> | OS-EXT-SRV-ATTR:hypervisor_hostname  | cn1                                                      |\n> | flavor                               | m1.tiny (1)                                              |\n> | id                                   | ccdf7541-3a74-4289-a8ce-9fe5cffe9dbd                     |\n> | security_groups                      | [{u\'name\': u\'default\'}]                                  |\n> | OS-SRV-USG:terminated_at             | None                                                     |\n> | user_id                              | 090a2de6e74b4573bd29318d4f494191                         |\n> | name                                 | tvm1                                                     |\n> | created                              | 2014-02-11T00:02:47Z                                     |\n> | tenant_id                            | ec54b7cadcab4620bbb6d568be7bd4a8                         |\n> | OS-DCF:diskConfig                    | MANUAL                                                   |\n> | metadata                             | {}                                                       |\n> | os-extended-volumes:volumes_attached | []                                                       |\n> | accessIPv4                           |                                                          |\n> | accessIPv6                           |                                                          |\n> | progress                             | 0                                                        |\n> | OS-EXT-STS:power_state               | 1                                                        |\n> | OS-EXT-AZ:availability_zone          | nova                                                     |\n> | config_drive                         |                                                          |\n> +--------------------------------------+----------------------------------------------------------+\n> root at cirrus3:/var/log/neutron# \n> \n> --\n> Ross Lillie\n> Distinguished Member of Technical Staff\n> Motorola Solutions, Inc.\n> \n> motorolasolutions.com\n> O: +1.847.576.0012\n> M: +1.847.980.2241\n> E: ross.lillie at motorolasolutions.com\n> \n> \n> <MSI-Email-Identity-sm.png>\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n\n\n\n\n\n','<CACGNuiSF=yMbeS0tr_LW0BzHpZggUoA5ddVb8jG9fjSqktDi0g@mail.gmail.com>',NULL),('<1430154953.301.1358921728620.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-23 06:15:28',0,'2013-01-23 06:15:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #114','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/114/>\n\n------------------------------------------\n[...truncated 919 lines...]\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.02\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.22\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.03\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.02\n    test_get_non_existing                                        OK    0.02\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.02\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: test_post_image_content_bad_container_format (glance.tests.functional.v1.test_api.TestApi)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 1283, in test_post_image_content_bad_container_format\n    self._do_test_post_image_content_bad_format(\'container_format\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 1248, in _do_test_post_image_content_bad_format\n    self.assertEqual(response.status, 200)\nAssertionError: 500 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (500, 200))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 81.16 secs:\n    16.90    TestGlanceControl.test_bouncing\n    16.73    TestBinGlanceCacheManage.test_queue\n    16.00    TestBinGlance.test_results_filtering\n    15.93    TestScrubber.test_delayed_delete\n    15.60    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 919 tests in 643.680s\n\nFAILED (SKIP=103, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6rc1\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.11.0\nglance==jenkins-periodic-glance-python26-stable-folsom-114\ngreenlet==0.4.0\nhttplib2==0.7.7\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==0.8.0\nkombu==2.5.4\nlxml==3.1beta1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==1.1.0\nsimplejson==3.0.7\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.oBg47uw2Cx\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/114\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/114/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1430176638.21.1385618823501.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-28 06:07:03',0,'2013-11-28 06:07:03',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python26-stable-havana #5','See <https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-havana/5/>\n\n\n\n',NULL,NULL),('<1430191202.1.1370499739877.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-06 06:22:19',0,'2013-06-06 06:22:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #248','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/248/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:57751\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:57751/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19108) wsgi starting up on http://127.0.0.1:57751/\n\nnova.osapi_compute.wsgi.server: INFO: (19108) accepted (\'127.0.0.1\', 48422)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [06/Jun/2013 06:17:09] \"GET /v2 HTTP/1.1\" 204 216 0.000751\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-2cacfbee-e723-4859-97a6-8720cb768003</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19108) accepted (\'127.0.0.1\', 48423)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xad8d190>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xad8d190>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:57751/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-06 06:17:09 19108 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:57751/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [06/Jun/2013 06:17:09] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.242979\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 609d2e9434184352ae9e2f6136eb5715 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:37902\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:37902/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19108) wsgi starting up on http://127.0.0.1:37902/\n\nnova.osapi_compute.wsgi.server: INFO: (19108) accepted (\'127.0.0.1\', 48376)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [06/Jun/2013 06:17:10] \"GET /v2 HTTP/1.1\" 204 216 0.001053\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-f7e9eedb-5507-4a8c-ac30-84df786eddc8</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19108) accepted (\'127.0.0.1\', 48377)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa24e350>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa24e350>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:37902/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     name)\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-06 06:17:10 19108 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37902/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [06/Jun/2013 06:17:10] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.286878\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.11\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.SV9eEGM415\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/248\n[SCP] Copying console log.\n\n\n','<930259477.57.1370413366831.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1432832593.5377687.1390290994164.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 02:56:34',-18000,'2014-01-21 07:56:34',NULL,'[openstack-dev] Validation of IP','You can instead use netaddr:\nimport netaddr\ntry:\n    netaddr.IPAddress(input)\nexcept AddrFormatError:\n    logging.error(\'Nope!\')\nelse:\n    doSomethingWith(input)\n\nYou could also:\nif netaddr.IPAddress(\'10.0.0.1\') in netaddr.IPNetwork(\'10.0.0.0/8\'):\n    logging.error(\'Yup!\')\n\n\nAssaf Muller, Cloud Networking Engineer \nRed Hat \n\n----- Original Message -----\nFrom: \"iKhan\" <ik.ibadkhan at gmail.com>\nTo: \"openstack-dev\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, January 21, 2014 4:55:05 AM\nSubject: [openstack-dev] Validation of IP\n\nHi, \n\nI am planning to validate an IP which is accepted part of input from user in cinder, I need to verify if IP address is valid and it is up in the network. The dirty way or only way that I know as of now is to create a socket object and perform inet_aton() and gethostbyaddr() \n\nJut worried if these operations are safe to perform. \n\n-- \nThanks, \nIbad Khan \n9686594607 \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADBmBnsbXTWKc_eumLeE9Za_sRufL+6dipgtxd_ZwFVSqFWeoA@mail.gmail.com>',NULL),('<143319292.26341739.1375750900977.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-05 21:01:40',-14400,'2013-08-06 01:01:40',NULL,'[openstack-dev] instances fail to boot on el6 (glance schema error\n	issue)','As of an hour ago the el6 (Centos) builds in SmokeStack all started failing. I\'ve documented the initial issue I\'m seeing in this ticket:\n\n https://bugs.launchpad.net/nova/+bug/1208656\n\nThe issue seems to be that we now hit a SchemaError which bubbles up from glanceclient when the new direct download plugin code runs. This only seems to happen on distributions using python 2.6 as I\'m not seeing the same thing on Fedora.\n\nThis stack trace also highlights the fact that the Glance v2 API now seems to be a requirement for Nova... and I\'m not sure this is a good thing considering we still use the v1 API for many things as well. Ideally we\'d have all Nova -> Glance communication use a single version of the Glance API (either v1 or v2... not both) right?\n\n----\n\nSorry I didn\'t catch this one sooner. We only recently enabled Centos testing again (due to some resource limitations). Plus I just got back from vacation. :)\n\nDan\n\n\n','<1374387238.26340698.1375750410759.JavaMail.root@redhat.com>',NULL),('<1433204304.4375672.1422952305366.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-03 03:31:45',-18000,'2015-02-03 08:31:45',NULL,'[openstack-dev] [Heat][Keystone] Native keystone resources in\n Heat','I think the user resource should not have \"roles\" in it. There should be a \"Role Assignment\" resource that grants roles to users on either tenants (projects) or domains. On the other hand, the user resource should have a domain association. Also, consider adding support for groups and in the future maybe also federation. As for trusts, I don\'t think it should be Heat\'s responsibility to set them  up, because it\'s up to the users themselves to create and grant trusts to their trustees.\n\n----- Original Message -----\nFrom: \"Zane Bitter\" <zbitter at redhat.com>\nTo: openstack-dev at lists.openstack.org\nSent: Tuesday, 3 February, 2015 12:26:41 AM\nSubject: Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat\n\nOn 30/01/15 02:19, Thomas Spatzier wrote:\n>> From: Zane Bitter <zbitter at redhat.com>\n>> To: openstack Development Mailing List\n> <openstack-dev at lists.openstack.org>\n>> Date: 29/01/2015 17:47\n>> Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in\n> Heat\n>>\n>> I got a question today about creating keystone users/roles/tenants in\n>> Heat templates. We currently support creating users via the\n>> AWS::IAM::User resource, but we don\'t have a native equivalent.\n>>\n>> IIUC keystone now allows you to add users to a domain that is otherwise\n>> backed by a read-only backend (i.e. LDAP). If this means that it\'s now\n>> possible to configure a cloud so that one need not be an admin to create\n>> users then I think it would be a really useful thing to expose in Heat.\n>> Does anyone know if that\'s the case?\n>>\n>> I think roles and tenants are likely to remain admin-only, but we have\n>> precedent for including resources like that in /contrib... this seems\n>> like it would be comparably useful.\n>>\n>> Thoughts?\n>\n> I am really not a keystone expert, so don\'t know what the security\n> implications would be, but I have heard the requirement or wish to be able\n> to create users, roles etc. from a template many times. I\'ve talked to\n> people who want to explore this for onboarding use cases, e.g. for\n> onboarding of lines of business in a company, or for onboarding customers\n> in a public cloud case. They would like to be able to have templates that\n> lay out the overall structure for authentication stuff, and then\n> parameterize it for each onboarding process.\n> If this is something to be enabled, that would be interesting to explore.\n\nThanks for the input everyone. I raised a spec + blueprint here:\n\nhttps://review.openstack.org/152309\n\nI don\'t have any immediate plans to work on this, so if anybody wants to \ngrab it they\'d be more than welcome :)\n\ncheers,\nZane.\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<54CFF9A1.4040809@redhat.com>',NULL),('<1433369DB68D1D4AA444506EF70475FC05704D6B@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 15:02:47',0,'2013-06-05 15:02:47',NULL,'[openstack-dev] Feedback wanted please on proposal to make root\n disk size variable','Hi Scott,\n \n> The other thing I don\'t like about it is that, currently (at least in\n> libvirt driver), ephemeral disks are cached.  This is because ephemeral\n> disks are attached with a filesystem already created on them. That\n> allows the user to immediately use the disk without having to do mkfs,\n> and the caching of that image saves the host from having to do it on\n> every instance launch.\n> \n> If you use:\n>  ephemeral_gb = (flavor.root_gb + flavor.ephemeral_gb) -\n> instance.root_gb and instance.root_gb all of a sudden varies greatly\n> amoung instances, then the host will be creating ephemeral images (and\n> mkfs\'ing them) possibly for every instance.\n\nIt is my understanding that the filesystem is created on the COW layer of the ephemeral disks (disk.local) and not on the backing file itself by cloudinit or similar software after instance startup. I\'m not sure if there\'s any data on the backing file itself.\n \nInstance.root_gb can be either equal to flavor.root_gb or image.min_disk. So yes, the number of ephemeral backing disks will be equal to the different min_disk sizes. But do the backing files for disk.local actually have any data or just sparse files?\n\nCheers,\n~parthi\n\n','<alpine.DEB.2.02.1306050939410.7482@brickies>',NULL),('<1433369DB68D1D4AA444506EF70475FC05704D9F@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-05 15:26:37',0,'2013-06-05 15:26:37',NULL,'[openstack-dev] Feedback wanted please on proposal to make root\n disk size variable','\n> \n> Hi Scott,\n> \n> > The other thing I don\'t like about it is that, currently (at least in\n> > libvirt driver), ephemeral disks are cached.  This is because\n> ephemeral\n> > disks are attached with a filesystem already created on them. That\n> > allows the user to immediately use the disk without having to do\n> mkfs,\n> > and the caching of that image saves the host from having to do it on\n> > every instance launch.\n> >\n> > If you use:\n> >  ephemeral_gb = (flavor.root_gb + flavor.ephemeral_gb) -\n> > instance.root_gb and instance.root_gb all of a sudden varies greatly\n> > amoung instances, then the host will be creating ephemeral images\n> (and\n> > mkfs\'ing them) possibly for every instance.\n> \n> It is my understanding that the filesystem is created on the COW layer\n> of the ephemeral disks (disk.local) and not on the backing file itself\n> by cloudinit or similar software after instance startup. I\'m not sure\n> if there\'s any data on the backing file itself.\n> \n\nYou\'re right. A filesystem is indeed created on the backing file. Sorry :)\n\n\n> Instance.root_gb can be either equal to flavor.root_gb or\n> image.min_disk. So yes, the number of ephemeral backing disks will be\n> equal to the different min_disk sizes. But do the backing files for\n> disk.local actually have any data or just sparse files?\n> \n> Cheers,\n> ~parthi\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC057260B9@G5W2715.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-13 20:44:22',0,'2013-07-13 20:44:22',NULL,'[openstack-dev] Reset established vnc connections','Hello,\n\nI\'ve proposed the following blueprint and would appreciate feedback.\n\nhttps://blueprints.launchpad.net/nova/+spec/reset-vnc-console\n\nThis is in response to some of the security concerns around VNC we have seen in deployed clusters. An established console connection can be passive and the user cannot do anything if he suspects a connected adversary without changing VM state. In this blueprint we propose that we allow the user to reset any existing console connections using a client call something like\n\nnova reset-all-vnc-consoles <server>\n\nMy search didn\'t point towards any existing effort/blueprints in this line but please let me know if there\'s one so that I can join that. If not I\'d like to start work on this.\n\nThanks\n~parthi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130713/289f6525/attachment.html>\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC087EA247@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-29 13:31:23',0,'2013-11-29 13:31:23',NULL,'[openstack-dev] jsonschema version constraint','Hi,\n\nDo we need to update the jsonschema constraint in the requirements.txt? Many tests are failing with jsonschema 1.3.0 with the same error.\n\n======================================================================\nFAIL: nova.tests.test_api_validation.AdditionalPropertiesDisableTestCase.test_validate_additionalProperties_disable\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  pythonlogging:\'\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"/tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/tests/test_api_validation.py\", line 133, in setUp\n    @validation.schema(request_body_schema=schema)\n  File \"/tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/__init__.py\", line 36, in schema\n    schema_validator = _SchemaValidator(request_body_schema)\n  File \"/tmp/buildd/nova-2014.1.dev990.g2c795f0/nova/api/validation/validators.py\", line 51, in __init__\n    validator_cls = jsonschema.validators.extend(self.validator_org,\nAttributeError: \'dict\' object has no attribute \'extend\'\n\n\n~parthi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131129/e69242f7/attachment.html>\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC0880BD25@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-16 13:25:09',0,'2013-12-16 13:25:09',NULL,'[openstack-dev] [Nova][libvirt]when deleting instance which is\n in migrating state, instance files can be stay in destination node forever','Isn?t just handling the exception instance_not_found enough? By this time source would?ve been cleaned up. Destination VM resources will get cleaned up by the periodic task since the VM is not associated with this host. Am I missing something here?\n\n\nFrom: ?? [mailto:w.wanghong1 at gmail.com]\nSent: 16 December 2013 11:32\nTo: openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [Nova][libvirt]when deleting instance which is in migrating state, instance files can be stay in destination node forever\n\nHi all.\nWhen I try to fix a bug:https://bugs.launchpad.net/nova/+bug/1242961,\nI get a trouble.\n\nTo reproduce the bug is very easy. Live migrate a vm in block_migration mode,\nand then delelte the vm immediately.\n\nThe reason of this bug is as follow:\n1. Because live migrate costs more time, so the vm will be deleted sucessfully\n   before live migrate complete. And then, we will get an exception while live\n   migrating.\n2. After live migrate failed, we start to rollback. But, in the rollback method\n   we will get or modify the info of vm from db. Because the vm has been deleted\n   already, so we will get instance_not_found exception and rollback will be\n   faild too.\n\nI have two ways to fix the bug:\ni)Add check in nova-api. When try to delete a vm, we return an error message if\nthe vm_state is LIVE_MIGRATING. This way is very simple, but need to carefully\nconsider. I have found a related discussion:\nhttp://lists.openstack.org/pipermail/openstack-dev/2013-October/017454.html, but\nit has no result in the discussion.\nii)Before live migrate we get all the data needed by rollback method, and add a\nnew rollback method. The new method will clean up resources at destination based\non the above data(The resouces at source has been already cleaned up by\ndeleting).\n\nI have no idea whitch one I should choose. Or, any other ideas?:)\n\nRegards,\nwanghong\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131216/165790f0/attachment.html>\n\n','<CAKA_48D=FQakYxtK1vTkiFB9RwN0znunFv62CY6wnH+9R=1SiQ@mail.gmail.com>',NULL),('<1433369DB68D1D4AA444506EF70475FC08841E5E@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 13:47:34',0,'2014-02-04 13:47:34',NULL,'[openstack-dev] suspending a paused instance','Hi,\n\nIs there a compelling reason why we shouldn\'t support suspending an already paused VM? I\'ve raised https://bugs.launchpad.net/nova/+bug/1276154 to get some context into this design.\n\nCheers\n~parthi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/36c0b318/attachment.html>\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC08867A73@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-04 11:23:50',0,'2014-03-04 11:23:50',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','Arindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140304/14a10672/attachment.html>\n\n','<DUB123-W311EDA675251F3C29AC674DF8E0@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC08867B7D@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-04 12:14:32',0,'2014-03-04 12:14:32',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','Reading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140304/57931a18/attachment.html>\n\n','<DUB123-W469D2226524ACBF94AE335DF8E0@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC0886F660@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 10:12:14',0,'2014-03-05 10:12:14',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','Seems like qemu doesn\'t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that\'ll be great. Thanks.\n\nAlso what\'s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there\'s no improvement try - although I don\'t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI\'m just wondering if it\'s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting...\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it\'s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/0ea49c6a/attachment.html>\n\n','<DUB123-W2249C6B914CC6591A7C0A0DF8E0@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC088707CB@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 13:23:41',0,'2014-03-05 13:23:41',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','What are /dev/kvm permissions?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 11:09\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nWhich user I must add in root group? nova or qemu?\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 10:12:14 +0000\nSeems like qemu doesn\'t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that\'ll be great. Thanks.\n\nAlso what\'s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there\'s no improvement try - although I don\'t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI\'m just wondering if it\'s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting...\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it\'s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/d0660983/attachment.html>\n\n','<DUB123-W370011D3DCD0C0DB4F02E3DF890@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC088707DB@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 13:30:18',0,'2014-03-05 13:30:18',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','What were your build time options for qemu?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:29\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nthe permission of /dev/kvm:\n\ncrw-rw-rw-+ 1 root kvm 10, 232 Mar  4 14:28 /dev/kvm\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:23:41 +0000\nWhat are /dev/kvm permissions?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 11:09\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nWhich user I must add in root group? nova or qemu?\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 10:12:14 +0000\nSeems like qemu doesn\'t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that\'ll be great. Thanks.\n\nAlso what\'s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there\'s no improvement try - although I don\'t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI\'m just wondering if it\'s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting...\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it\'s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/697ca7b8/attachment.html>\n\n','<DUB123-W453CAE207AEB452FAD3B9DDF890@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC088707EF@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 13:37:22',0,'2014-03-05 13:37:22',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','Try setting user and group to root in /etc/libvirt/qemu.conf\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:36\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\n./configure --enable-trace-backend=ftrace --enable-kvm --enable-vhost-net --enable-virtfs --target-list=x86_64-linux-user,x86_64-softmmu\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:30:18 +0000\nWhat were your build time options for qemu?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:29\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nthe permission of /dev/kvm:\n\ncrw-rw-rw-+ 1 root kvm 10, 232 Mar  4 14:28 /dev/kvm\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:23:41 +0000\nWhat are /dev/kvm permissions?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 11:09\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nWhich user I must add in root group? nova or qemu?\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 10:12:14 +0000\nSeems like qemu doesn\'t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that\'ll be great. Thanks.\n\nAlso what\'s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there\'s no improvement try - although I don\'t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI\'m just wondering if it\'s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting...\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it\'s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/d82b8908/attachment.html>\n\n','<DUB123-W39A38E9527C9129D2E69ADDF890@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC08870821@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 13:53:25',0,'2014-03-05 13:53:25',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','If that doesn\'t work try setting clear_emulator_capabilities=0\n\nFrom: Parthipan, Loganathan\nSent: 05 March 2014 13:37\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nTry setting user and group to root in /etc/libvirt/qemu.conf\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:36\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\n./configure --enable-trace-backend=ftrace --enable-kvm --enable-vhost-net --enable-virtfs --target-list=x86_64-linux-user,x86_64-softmmu\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:30:18 +0000\nWhat were your build time options for qemu?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:29\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nthe permission of /dev/kvm:\n\ncrw-rw-rw-+ 1 root kvm 10, 232 Mar  4 14:28 /dev/kvm\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:23:41 +0000\nWhat are /dev/kvm permissions?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 11:09\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nWhich user I must add in root group? nova or qemu?\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 10:12:14 +0000\nSeems like qemu doesn\'t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that\'ll be great. Thanks.\n\nAlso what\'s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there\'s no improvement try - although I don\'t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI\'m just wondering if it\'s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting...\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it\'s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don\'t think the problem is due to injection failure at libguestfs. It\'s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you \'apt-get remove python-guestfs\' and try? I\'d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/6a5dd7f7/attachment-0001.html>\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC088718D5@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-05 15:16:25',0,'2014-03-05 15:16:25',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','The guestfs error is due to a misconfiguration of guestfs and will only result in not having files injected before booting. Usually this is harmless as cloud-init like software will fix it after booting.\n\nGlad the VM booted ?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 15:10\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nchanging /etc/libvirt/qemu.conf helped [Image removed by sender. Emoji] . clear_emulator_capabilities=0 was already set.\n\nVM boots up, but it still has the same error in log.\n\nlog <http://paste.openstack.org/raw/72621/>\n\ninstance-log<http://paste.openstack.org/raw/72622/>\n\nls -alh /var/lib/nova/instances/7d79e021-72a9-4e5c-b2e5-312e16355dcd/\ntotal 52M\ndrwxr-xr-x 2 nova nova 4.0K Mar  5 15:50 .\ndrwxr-xr-x 5 nova nova 4.0K Mar  5 15:50 ..\n-rw-rw---- 1 root root  25K Mar  5 15:51 console.log\n-rw-r--r-- 1 root root  52M Mar  5 15:51 disk\n-rw-r--r-- 1 nova nova 1.6K Mar  5 15:50 libvirt.xml\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:53:25 +0000\nIf that doesn?t work try setting clear_emulator_capabilities=0\n\nFrom: Parthipan, Loganathan\nSent: 05 March 2014 13:37\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nTry setting user and group to root in /etc/libvirt/qemu.conf\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:36\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\n./configure --enable-trace-backend=ftrace --enable-kvm --enable-vhost-net --enable-virtfs --target-list=x86_64-linux-user,x86_64-softmmu\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:30:18 +0000\nWhat were your build time options for qemu?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 13:29\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nthe permission of /dev/kvm:\n\ncrw-rw-rw-+ 1 root kvm 10, 232 Mar  4 14:28 /dev/kvm\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:23:41 +0000\nWhat are /dev/kvm permissions?\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 05 March 2014 11:09\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nWhich user I must add in root group? nova or qemu?\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 10:12:14 +0000\nSeems like qemu doesn?t have the privileges to read /sys/kernel/debug/tracing/tracing_on\n\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 15:15\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nboth\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable is 1.\n\nThe logs are:\n\nlibvirtd-debug<http://paste.openstack.org/raw/72197/> (sorry for lots of garbage in this file)\n\n/var/log/messages<http://paste.openstack.org/raw/72198/>\n\ninstance.log<http://paste.openstack.org/raw/72205/>\n\nAfter disabling tracing_on and tracing kvm events, it gave the same error.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 14:07:31 +0000\nIf you can that?ll be great. Thanks.\n\nAlso what?s in\n\n/sys/kernel/debug/tracing/tracing_on\n/sys/kernel/debug/tracing/events/kvm/enable\n\nTry running after\necho 0 > /sys/kernel/debug/tracing/tracing_on\n\nIf there?s no improvement try - although I don?t know what it really does (I need to read the code)\necho 0 > /sys/kernel/debug/tracing/events/kvm/enable\n\nI?m just wondering if it?s due to some permission/ACL issues when trying to write into debugfs using ftrace, given your observation on different tracing backends.\n\nThanks for reporting and spending time on this.\n\nCheers\n~parthi\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 13:27\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIts a multi-node deployment with nova-network.\n\nIf you want I can recreate the error and send you the logs.\n\nRegards,\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 13:21:24 +0000\nInteresting?\n\nIs it a single node deployment? Do you have any other log data such as libvirt_debug.log, libvirt/qemu/instance-xxxx.log? Any errors/warnings during the time of instance creation in syslog?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 12:56\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nit only happens when I enable\n\n--enable-trace-backend=ftrace\n\nwith\n--enable-trace-backend=simple\n\nworks fine.\n\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 12:33:55 +0000\nAlso check if it?s a cgroups issue since the binary location changed. You could look at the syslog and kern.log\n\n\nFrom: Parthipan, Loganathan\nSent: 04 March 2014 12:15\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nReading your log, I don?t think the problem is due to injection failure at libguestfs. It?s a warning and is ignored.\n\nSeems more like a network setup issue. Are you using neutron? Is the network/subnet etc setup properly?\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 11:50\nTo: Parthipan, Loganathan; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi Parthipan,\n\nWhen I try to do yum remove python-libguestfs.\nIt also wants to remove openstack-nova-compute. So, I can not.\n\nRegards,\nArindam\n________________________________\nFrom: parthipan at hp.com\nTo: arindam at live.com; openstack at lists.openstack.org\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Tue, 4 Mar 2014 11:23:50 +0000\nArindam,\n\nWhat happens if you ?apt-get remove python-guestfs? and try? I?d expect it to fallback to nbdmount.\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 04 March 2014 10:40\nTo: openstack at lists.openstack.org\nSubject: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\nI have a working Openstack Grizzly setup with nova-network on Scientific Linux. As, SL comes with a old qemu:\n\nqemu-kvm-0.12.1.2-2.355.el6_4.6.x86_64\n\nI am trying to upgrade it to qemu-1.7.0 from source.\n\nThe configuration output<http://pastebin.com/raw.php?i=geEEXm79>.\n\nAs, openstack use /usr/libexec/qemu-kvm to start up VM, i linked\nqemu-kvm to qemu-system-x86_64:\nls -l /usr/libexec/qemu-kvm lrwxrwxrwx 1 root root 33 Feb 19 15:25 /usr/libexec/qemu-kvm -> /usr/local/bin/qemu-system-x86_64\n\nBut when I try to start VM, I get following error:\n\nWARNING nova.virt.disk.api [req-7dfd6cf1-db21-403d-abbf-ccb5f0273a6a\nb829b65d0675416198f9e4838b5009e2 9a2e060772204260b53b52ea1c12db97]\nIgnoring error injecting data into image\n(Error mounting /var/lib/nova/instances/07c0898e-7d75-448d-b4fe-2c37f681b846/disk\nwith libguestfs (child process died unexpectedly))\n\nThe full error log is here<http://pastebin.com/raw.php?i=FD8N47mk>.\n\nOutput of libguestfs-test-tool is here<http://pastebin.com/raw.php?i=EKWQWH1y>.\n\nRegards,\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/97e3529e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ~WRD000.jpg\nType: image/jpeg\nSize: 823 bytes\nDesc: ~WRD000.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140305/97e3529e/attachment.jpg>\n\n','<DUB123-W373629FB5255017087440EDF890@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC08874F1B@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-06 10:19:56',0,'2014-03-06 10:19:56',NULL,'[Openstack] Error mounting disk with libguestfs (child process\n died unexpectedly)','Arindam,\n\nIf you don?t want to see the error in the logs you can configure /etc/nova/nova.conf to\n\n[libvirt]\ninject_partition = -2\n\nThe guest can then inject files and metadata after it starts up, which is more preferable.\n\n~parthi\n\nFrom: Arindam Choudhury [mailto:arindam at live.com]\nSent: 06 March 2014 09:48\nTo: ???; openstack at lists.openstack.org\nSubject: Re: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nHi,\n\nIt will be very helpful if you can share your procedure. My libguestfs version is libguestfs-1.16.34-2.el6.x86_64\n________________________________\nDate: Thu, 6 Mar 2014 09:24:51 +0800\nSubject: Re: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nFrom: lilinguo8212 at gmail.com\nTo: arindam at live.com\nI\'ve been done. The guestfs\'s python file has a bug.\nBug I forget what is version of the guestfs. If you can\'t deal the problem, I can find out what I have done.\n\n2014-03-05 23:30 GMT+08:00 Arindam Choudhury <arindam at live.com<mailto:arindam at live.com>>:\n\nThanking a lot for helping me.\n________________________________\nFrom: parthipan at hp.com<mailto:parthipan at hp.com>\nTo: arindam at live.com<mailto:arindam at live.com>\nCC: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\n\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 15:16:25 +0000\nThe guestfs error is due to a misconfiguration of guestfs and will only result in not having files injected before booting. Usually this is harmless as cloud-init like software will fix it after booting.\n\nGlad the VM booted :)\n\n\nFrom: Arindam Choudhury [mailto:arindam at live.com<mailto:arindam at live.com>]\nSent: 05 March 2014 15:10\n\nTo: Parthipan, Loganathan\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\nchanging /etc/libvirt/qemu.conf helped [Image removed by sender. Image removed by sender. Emoji] . clear_emulator_capabilities=0 was already set.\n\nVM boots up, but it still has the same error in log.\n\nlog <http://paste.openstack.org/raw/72621/>\n\ninstance-log<http://paste.openstack.org/raw/72622/>\n\nls -alh /var/lib/nova/instances/7d79e021-72a9-4e5c-b2e5-312e16355dcd/\ntotal 52M\ndrwxr-xr-x 2 nova nova 4.0K Mar  5 15:50 .\ndrwxr-xr-x 5 nova nova 4.0K Mar  5 15:50 ..\n-rw-rw---- 1 root root  25K Mar  5 15:51 console.log\n-rw-r--r-- 1 root root  52M Mar  5 15:51 disk\n-rw-r--r-- 1 nova nova 1.6K Mar  5 15:50 libvirt.xml\n\n________________________________\n\nFrom: parthipan at hp.com<mailto:parthipan at hp.com>\nTo: arindam at live.com<mailto:arindam at live.com>; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\nDate: Wed, 5 Mar 2014 13:53:25 +0000\nIf that doesn?t work try setting clear_emulator_capabilities=0\n\nFrom: Parthipan, Loganathan\nSent: 05 March 2014 13:37\nTo: \'Arindam Choudhury\'; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\nTry setting user and group to root in /etc/libvirt/qemu.conf\n\nFrom: Arindam Choudhury [mailto:arindam at live.com<mailto:arindam at live.com>]\nSent: 05 March 2014 13:36\nTo: Parthipan, Loganathan; openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: RE: [Openstack] Error mounting disk with libguestfs (child process died unexpectedly)\n\n\n./configure --enable-trace-backend=ftrace --enable-kvm --enable-vhost-net --enable-virtfs --target-list=x86_64-linux-user,x86_64-softmmu\n...\n\n[??????]\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/1046145e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: ~WRD000.jpg\nType: image/jpeg\nSize: 823 bytes\nDesc: ~WRD000.jpg\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140306/1046145e/attachment.jpg>\n\n','<DUB123-W283A7CEE62832AD36EE391DF880@phx.gbl>',NULL),('<1433369DB68D1D4AA444506EF70475FC088A11D1@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 12:40:54',0,'2014-04-01 12:40:54',NULL,'[openstack-dev] Deprecation of config variables','Hello,\n\nWhat\'s the definition of deprecation of config variables in Openstack? I\'d have thought that the new variables would be usable during the grace period. But it looks like that\'s not the case.\n\nFor instance, currently libvirt_type is deprecated and virt_type is the new variable. However, only libvirt_type is read and virt_type is ignored.\n\nThanks\n~parthi\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/1126883c/attachment.html>\n\n',NULL,NULL),('<1433369DB68D1D4AA444506EF70475FC088A1277@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 14:03:39',0,'2014-04-01 14:03:39',NULL,'[openstack-dev] Deprecation of config variables','\n\n> -----Original Message-----\n> From: Russell Bryant [mailto:rbryant at redhat.com]\n> Sent: 01 April 2014 14:24\n> To: openstack-dev at lists.openstack.org\n> Subject: Re: [openstack-dev] Deprecation of config variables\n> \n\n\n> \n> You may have just mixed up the sections the options go in.\n> \n\nYou\'re correct, the sections.. :) Thanks.\n\n\n>     [libvirt]\n>     # Libvirt domain type (valid options are: kvm, lxc, qemu, uml,\n>     # xen) (string value)\n>     # Deprecated group/name - [DEFAULT]/libvirt_type\n>     #virt_type=kvm\n> \n> So, the old option was:\n> \n>     [DEFAULT]\n>     libvirt_type=kvm\n> \n> The new option is:\n> \n>     [libvirt]\n>     virt_type=kvm\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<533ABE0D.9060002@redhat.com>',NULL),('<1433369DB68D1D4AA444506EF70475FC088A8CFA@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 09:30:13',0,'2014-04-02 09:30:13',NULL,'[openstack-dev] Nova Live Migration issue','Can you confirm that it\'s no longer running on the source node and only running on the destination node?\n\nWhat\'s your libvirt version?\n\nPossibly the libvirt monitor lost connection and didn\'t complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on.\n\nFrom: Nikolay Starodubtsev [mailto:nstarodubtsev at mirantis.com]\nSent: 02 April 2014 09:01\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Nova Live Migration issue\n\nHi!\nCan you show libvirt logs?\n\n\n\n\nNikolay Starodubtsev\n\nSoftware Engineer\n\nMirantis Inc.\n\n\n\nSkype: dark_harlequine1\n\n2014-04-02 11:55 GMT+04:00 abhishek jain <ashujain9727 at gmail.com<mailto:ashujain9727 at gmail.com>>:\nHi all\nI\'m following the below link for VM migration from one compute node to the another from the controller node using devstack ..\n\nhttp://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/\nI\'m able to migrate the instance from one compute node to the other compute node using the below command.\n\nnova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1\nThe instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node.\n\nHowever the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time.\nMoreover when i type nova show <instance -id> command,the old host of the instance is reflected instead of the new one.\nPlease help regarding this.\nThanks\nAbhishek Jain\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/00b2e837/attachment.html>\n\n','<CAAa8YgAL7iq8UWLezk7jg1o4LOA4NS3qKGp=2H=VM96UCOw_3w@mail.gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1433369DB68D1D4AA444506EF70475FC088A9F38@G6W2481.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 11:44:10',0,'2014-04-02 11:44:10',NULL,'[openstack-dev] Nova Live Migration issue','Hello Abhishek,\n\nDid you check on the source node whether the instance is still running or even defined (virsh list -all). This is because nova notices that the migration is completed when the VM in the source is gone and then triggers the post-migration.\n\nIIRC, there\'s a bug in 0.x libvirt where the destination qemu disconnection is not picked up by the source libvirt, causing nova migration thread to wait. I don\'t know if libvirt 1.x works with nova properly yet.\n\nCheers\n~parthi\n\n\nFrom: abhishek jain [mailto:ashujain9727 at gmail.com]\nSent: 02 April 2014 12:28\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Nova Live Migration issue\n\nThanks Nikolay and Parthipan\n\nI have confirmed that the instance is running on the newer compute node by using sudo virsh list command.\nI\'m using below libvirt version ..\n\nlibvirtd (libvirt) 0.9.8\nActually I will not be able to present  the libvirt logs due to setup problem.I\'ll send logs as soon as possible.\nPlease let me know if any thing needs to be taken care in libvirt during the configuration\n\n\nOn Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan <parthipan at hp.com<mailto:parthipan at hp.com>> wrote:\nCan you confirm that it\'s no longer running on the source node and only running on the destination node?\n\nWhat\'s your libvirt version?\n\nPossibly the libvirt monitor lost connection and didn\'t complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on.\n\nFrom: Nikolay Starodubtsev [mailto:nstarodubtsev at mirantis.com<mailto:nstarodubtsev at mirantis.com>]\nSent: 02 April 2014 09:01\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Nova Live Migration issue\n\nHi!\nCan you show libvirt logs?\n\n\n\n\nNikolay Starodubtsev\n\nSoftware Engineer\n\nMirantis Inc.\n\n\n\nSkype: dark_harlequine1\n\n2014-04-02 11:55 GMT+04:00 abhishek jain <ashujain9727 at gmail.com<mailto:ashujain9727 at gmail.com>>:\nHi all\nI\'m following the below link for VM migration from one compute node to the another from the controller node using devstack ..\n\nhttp://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/\nI\'m able to migrate the instance from one compute node to the other compute node using the below command.\n\nnova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1\nThe instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node.\n\nHowever the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time.\nMoreover when i type nova show <instance -id> command,the old host of the instance is reflected instead of the new one.\nPlease help regarding this.\nThanks\nAbhishek Jain\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/907b6a07/attachment.html>\n\n','<CA+9-LvvaqKJF82oGd3bgvYYJ2d-U-UktwsFh9_09r=sqpQ_mSg@mail.gmail.com>',NULL),('<1433369DB68D1D4AA444506EF70475FC1924290C@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-13 12:21:50',0,'2014-05-13 12:21:50',NULL,'[Openstack] [openstack-dev] booting VM with customized kernel\n and rootfs image','You can upload your custom kernel/rootdisk pair to glance and use the rootdisk uuid to boot an instance.\n\nhttp://docs.openstack.org/user-guide/content/cli_manage_images.html\n\n\nFrom: sonia verma [mailto:soniaverma9727 at gmail.com]\nSent: 13 May 2014 06:33\nTo: OpenStack Development Mailing List (not for usage questions); openstack at lists.openstack.org\nSubject: [openstack-dev] booting VM with customized kernel and rootfs image\n\nHi all\nI have installed openstack using devstack.I\'m able able to boot VM from the opebstack dashboard onto the compute node.\nNow i need to boot VM from the openstack dashboard(controller node) onto compute node using customized kernel imae and rootfs.\nTherefore my question is whether can we boot VM from controller node onto compute node using the customized kernel and rootfs image.\nPlease help regarding this.\n\n\nThanks\nSonia\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140513/5f09057b/attachment.html>\n\n','<CAJ7Vayj8LEA9h-kmoSzr7T04Tn7=Hf+Qori3_A_F5bp=0MPHhA@mail.gmail.com>',NULL),('<1433369DB68D1D4AA444506EF70475FC19242918@G5W2731.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-13 12:27:35',0,'2014-05-13 12:27:35',NULL,'[Openstack] instances stuck in \"powering on\"','Or rather, the compute cannot talk to the conductor. Try setting use_local=true in the compute nova.conf and restart nova-compute.\n\n> -----Original Message-----\n> From: Dimitri Maziuk [mailto:dmaziuk at bmrb.wisc.edu]\n> Sent: 12 May 2014 19:10\n> To: openstack at lists.openstack.org\n> Subject: [Openstack] instances stuck in \"powering on\"\n> \n> Hi everyone,\n> \n> I moved my bootable volumes to better storage (nfs backend) by copying\n> files and editing provider_location in cinder db. The instances were\n> shut off for that, of course.\n> \n> Now when I power them on via dashboard, some (not all) of them get\n> stuck in \"powering on\" for as long as I care to wait. On the compute\n> host compute.log is full of\n> \n> > TRACE nova.openstack.common.rpc.amqp\n> > task run WARNING nova.openstack.common.loopingcall [-] outlasted\n> > interval by 50.018454 sec ERROR nova.openstack.common.periodic_task\n> [-] Error during ComputeManager._sync_power_states: Timeout while\n> waiting on RPC response - topic: \"conductor\", RPC method:\n> \"object_class_action\" info: \"<unknown>\"\n> \n> -- completely unhelpful since I\'m getting tons of them during normal\n> operation, too.\n> \n> \"virsh start instance-XXXXXX\" works, \"nova reset-state --active\" clears\n> up the \"powering-on\" but doesn\'t mark it \"Running\" regardless of\n> instance\'s power state.\n> \n> So it looks like dashboard can\'t talk to the compute. Any hints as to\n> why & where to look?\n> \n> (centos 6.current, rdo, havana, simple stupid setup w/ noop nova\n> networking and bootable volumes.)\n> \n> TIA\n> --\n> Dimitri Maziuk\n> Programmer/sysadmin\n> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu\n\n\n\n','<53710E7D.6010509@bmrb.wisc.edu>',NULL),('<1433922576.72.1383631393302.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-05 06:03:13',0,'2013-11-05 06:03:13',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-neutron-docs-stable-grizzly #43','See <https://jenkins01.openstack.org/job/periodic-neutron-docs-stable-grizzly/43/>\n\n\n\n','<972748525.39.1383372219908.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1435919412.2147840.1388675298439.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-02 10:08:18',-18000,'2014-01-02 15:08:18',NULL,'[Openstack] Ceilometer meter list not showing all meters','\nHi Swapnil,\n\nThe key distinction between the compute meters you\'re seeing and\nthe ones that are absent is that the latter are derived from notifications\nemitted by nova, whereas the former are generated via polling of the\nhypervisor.\n\nI suspect the reason you\'re not seeing the notification-driven meters\nis a side-effect of the recent split-off of the notification agent from\nthe collector service:\n\n  https://blueprints.launchpad.net/ceilometer/+spec/split-collector\n\nIs your devstack clone sufficiently recent to include the following\ncommit?\n\n  https://github.com/openstack-dev/devstack/commit/1c402286\n\nIf not, you\'ll need to fetch and rebase your devstack.\n\nIf so, please also check that your localrc includes ceilometer-anotification\nin the enabled services, e.g.\n\n  grep \'enable_service .*ceilometer-anotification\' devstack/localrc\n\nCheers,\nEoghan\n\n\n\n----- Original Message -----\n> \n> \n> Hi,\n> \n> \n> \n> I have the latest openstack deployed(through devstack) with Ceilometer\n> (ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api)\n> installed.\n> \n> \n> \n> from the meter list i am getting only the following meters data.\n> \n> \n> \n> cpu, cpu_util, disk.read.bytes, disk.read.requests, disk.write.bytes,\n> disk.write.requests, instance, instance:m1.nano, network.incoming.bytes,\n> network.incoming.packets, network.outgoing.bytes, network.outgoing.packets\n> \n> \n> \n> What about the rest of the meters like ram,vcpus,etc as mentioned in this\n> url: http://docs.openstack.org/developer/ceilometer/measurements.html\n> \n> \n> \n> I referred the following web pages for additional configurations required :\n> http://docs.openstack.org/developer/ceilometer/configuration.html\n> \n> http://docs.openstack.org/developer/ceilometer/install/manual.html#installing-manually\n> \n> \n> \n> I have also asked it on Launchpad:\n> https://answers.launchpad.net/ceilometer/+question/241511\n> \n> \n> \n> Why i am not able to get other meters data?\n> \n> \n> \n> \n> \n> Regards,\n> \n> Swapnil\n> \n> \n> DISCLAIMER ========== This e-mail may contain privileged and confidential\n> information which is the property of Persistent Systems Ltd. It is intended\n> only for the use of the individual or entity to which it is addressed. If\n> you are not the intended recipient, you are not authorized to read, retain,\n> copy, print, distribute or use this message. If you have received this\n> communication in error, please notify the sender and delete all copies of\n> this message. Persistent Systems Ltd. does not accept any liability for\n> virus infected mails.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<9ABF6B8480702948892B4C469286CA6B2A8CB8AC@HJ-MBX1.persistent.co.in>',NULL),('<1436527507.218.1356570555925.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-12-27 01:09:15',0,'2012-12-27 01:09:15',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #49','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/49/>\n\n------------------------------------------\n[...truncated 15216 lines...]\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yN1QwMTowNToxMi4zNjg5MjMiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI4VDAxOjA1OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAiaWQiOiAiMDI0ZmZmZTNmYmFlNDI3YWE2Y2M0MTMwNjBiMjFmMTMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZjY4NjJhODM5Y2M0NDExOGY4ZTZjOTZlMTVmZmVmMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNzkyZTIzOTRiNDUxNGIzMzk1MzczYjU0NTM1YjVkNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJpZCI6ICJlM2MyYWFmYzg5M2Y0YTVhOGZjN2RjYWVjYWYyNTAyYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwMWFmY2M0MzhjYjc0YzdmOWI3ZmRlMDhjNzViY2QyNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIiwgImlkIjogIjE4ZTkxZGNlM2Y3ZjQyZGVhZjgxYzE2MDA1Y2EzNGFkIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjZlNmEwYzNjZTgxZDQ2YmNhMGNiMmUxOGU2MzI4MTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiY2M4NDNiNzFiY2QyNDY3YTlhNmI4MzIyMTlmM2QwNzYiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYjFmMmRjNDkwYTk1NDc4ZGJhZTIzYTI2YWU4OWQ5ZjUiLCAiNTRjMTBmNGEzZWQyNDE0YTg4NjZjNjgxMzMzMDIyOGEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBgYWcQbJyWP0fpzBNQ+UCa9j9nb9JfwpzmF3wHqlW-m9g2fd8Em41980jKrNxT2seydgIwRcai2lD-h2yXOxbYUZ6sfmon54GGhymORZ+wQ8kuT9L5RXcJG0nmVY+3TCXVIR63UNj5IMlqcoa+KHqfxjejwXt5SVkdUkH71C2Ktw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/06677803-81a4-435a-a43c-30efb9dd4a98\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 27 Dec 2012 01:05:32 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-03426c76-b5dc-4631-88be-7e48c8a93a86\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yN1QwMTowNToxMi4zNjg5MjMiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI4VDAxOjA1OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAiaWQiOiAiMDI0ZmZmZTNmYmFlNDI3YWE2Y2M0MTMwNjBiMjFmMTMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZjY4NjJhODM5Y2M0NDExOGY4ZTZjOTZlMTVmZmVmMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNzkyZTIzOTRiNDUxNGIzMzk1MzczYjU0NTM1YjVkNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJpZCI6ICJlM2MyYWFmYzg5M2Y0YTVhOGZjN2RjYWVjYWYyNTAyYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwMWFmY2M0MzhjYjc0YzdmOWI3ZmRlMDhjNzViY2QyNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIiwgImlkIjogIjE4ZTkxZGNlM2Y3ZjQyZGVhZjgxYzE2MDA1Y2EzNGFkIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjZlNmEwYzNjZTgxZDQ2YmNhMGNiMmUxOGU2MzI4MTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiY2M4NDNiNzFiY2QyNDY3YTlhNmI4MzIyMTlmM2QwNzYiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYjFmMmRjNDkwYTk1NDc4ZGJhZTIzYTI2YWU4OWQ5ZjUiLCAiNTRjMTBmNGEzZWQyNDE0YTg4NjZjNjgxMzMzMDIyOGEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBgYWcQbJyWP0fpzBNQ+UCa9j9nb9JfwpzmF3wHqlW-m9g2fd8Em41980jKrNxT2seydgIwRcai2lD-h2yXOxbYUZ6sfmon54GGhymORZ+wQ8kuT9L5RXcJG0nmVY+3TCXVIR63UNj5IMlqcoa+KHqfxjejwXt5SVkdUkH71C2Ktw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/acda7214-9146-472b-9c1b-07906cb5dc84\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 27 Dec 2012 01:05:32 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-9cffe2c8-0cda-4777-a354-f4d3b1e0f1ec\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yN1QwMTowNToxMi4zNjg5MjMiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI4VDAxOjA1OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAiaWQiOiAiMDI0ZmZmZTNmYmFlNDI3YWE2Y2M0MTMwNjBiMjFmMTMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZjY4NjJhODM5Y2M0NDExOGY4ZTZjOTZlMTVmZmVmMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNzkyZTIzOTRiNDUxNGIzMzk1MzczYjU0NTM1YjVkNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJpZCI6ICJlM2MyYWFmYzg5M2Y0YTVhOGZjN2RjYWVjYWYyNTAyYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwMWFmY2M0MzhjYjc0YzdmOWI3ZmRlMDhjNzViY2QyNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIiwgImlkIjogIjE4ZTkxZGNlM2Y3ZjQyZGVhZjgxYzE2MDA1Y2EzNGFkIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjZlNmEwYzNjZTgxZDQ2YmNhMGNiMmUxOGU2MzI4MTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiY2M4NDNiNzFiY2QyNDY3YTlhNmI4MzIyMTlmM2QwNzYiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYjFmMmRjNDkwYTk1NDc4ZGJhZTIzYTI2YWU4OWQ5ZjUiLCAiNTRjMTBmNGEzZWQyNDE0YTg4NjZjNjgxMzMzMDIyOGEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBgYWcQbJyWP0fpzBNQ+UCa9j9nb9JfwpzmF3wHqlW-m9g2fd8Em41980jKrNxT2seydgIwRcai2lD-h2yXOxbYUZ6sfmon54GGhymORZ+wQ8kuT9L5RXcJG0nmVY+3TCXVIR63UNj5IMlqcoa+KHqfxjejwXt5SVkdUkH71C2Ktw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f9b29aaf-671e-4e09-8830-271407fa2bef\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 27 Dec 2012 01:05:34 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-ad12025b-151e-45fd-8ac1-14334f50c619\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yN1QwMTowNToxMi4zNjg5MjMiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI4VDAxOjA1OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAiaWQiOiAiMDI0ZmZmZTNmYmFlNDI3YWE2Y2M0MTMwNjBiMjFmMTMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZjY4NjJhODM5Y2M0NDExOGY4ZTZjOTZlMTVmZmVmMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNzkyZTIzOTRiNDUxNGIzMzk1MzczYjU0NTM1YjVkNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJpZCI6ICJlM2MyYWFmYzg5M2Y0YTVhOGZjN2RjYWVjYWYyNTAyYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwMWFmY2M0MzhjYjc0YzdmOWI3ZmRlMDhjNzViY2QyNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIiwgImlkIjogIjE4ZTkxZGNlM2Y3ZjQyZGVhZjgxYzE2MDA1Y2EzNGFkIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjZlNmEwYzNjZTgxZDQ2YmNhMGNiMmUxOGU2MzI4MTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiY2M4NDNiNzFiY2QyNDY3YTlhNmI4MzIyMTlmM2QwNzYiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYjFmMmRjNDkwYTk1NDc4ZGJhZTIzYTI2YWU4OWQ5ZjUiLCAiNTRjMTBmNGEzZWQyNDE0YTg4NjZjNjgxMzMzMDIyOGEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBgYWcQbJyWP0fpzBNQ+UCa9j9nb9JfwpzmF3wHqlW-m9g2fd8Em41980jKrNxT2seydgIwRcai2lD-h2yXOxbYUZ6sfmon54GGhymORZ+wQ8kuT9L5RXcJG0nmVY+3TCXVIR63UNj5IMlqcoa+KHqfxjejwXt5SVkdUkH71C2Ktw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/049c6546-4629-479d-a506-7ea32d6698b2\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 27 Dec 2012 01:05:34 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-bf89803c-ea84-4ad8-92a2-355aaeaf026e\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMi0xMi0yN1QwMTowNToxMi4zNjg5MjMiLCAiZXhwaXJlcyI6ICIyMDEyLTEyLTI4VDAxOjA1OjEyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNzZiMmQ5Yzc2NDBhNDg2MzkzM2Q5MjE1Mjc4ZTAxZGQiLCAiaWQiOiAiMDI0ZmZmZTNmYmFlNDI3YWE2Y2M0MTMwNjBiMjFmMTMiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICJmZjY4NjJhODM5Y2M0NDExOGY4ZTZjOTZlMTVmZmVmMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNzkyZTIzOTRiNDUxNGIzMzk1MzczYjU0NTM1YjVkNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCIsICJpZCI6ICJlM2MyYWFmYzg5M2Y0YTVhOGZjN2RjYWVjYWYyNTAyYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwMWFmY2M0MzhjYjc0YzdmOWI3ZmRlMDhjNzViY2QyNCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzc2YjJkOWM3NjQwYTQ4NjM5MzNkOTIxNTI3OGUwMWRkIiwgImlkIjogIjE4ZTkxZGNlM2Y3ZjQyZGVhZjgxYzE2MDA1Y2EzNGFkIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF83NmIyZDljNzY0MGE0ODYzOTMzZDkyMTUyNzhlMDFkZCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjZlNmEwYzNjZTgxZDQ2YmNhMGNiMmUxOGU2MzI4MTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiY2M4NDNiNzFiY2QyNDY3YTlhNmI4MzIyMTlmM2QwNzYiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYjFmMmRjNDkwYTk1NDc4ZGJhZTIzYTI2YWU4OWQ5ZjUiLCAiNTRjMTBmNGEzZWQyNDE0YTg4NjZjNjgxMzMzMDIyOGEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBgYWcQbJyWP0fpzBNQ+UCa9j9nb9JfwpzmF3wHqlW-m9g2fd8Em41980jKrNxT2seydgIwRcai2lD-h2yXOxbYUZ6sfmon54GGhymORZ+wQ8kuT9L5RXcJG0nmVY+3TCXVIR63UNj5IMlqcoa+KHqfxjejwXt5SVkdUkH71C2Ktw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/39521449-f9e0-4848-b5d9-ae3df1afe6d5\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 27 Dec 2012 01:05:35 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-ac8bccc7-2ad1-472a-b92d-f80d1298fe5f\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\nAdd metadata to account ... ok\nDelete metadata from account ... ok\nList all account metadata ... ok\nList of all containers should not be empty ... ok\nUpdate/Retrieve/Delete Container Metadata ... ok\nCreate a container, test responses ... ok\nCreate and Delete a container, test responses ... ok\nAdd metadata to object ... ok\nGET object after expiry time ... SKIP: Until bug 1069849 is resolved.\nMake container public-readable, and access the object ... ok\nCopy storage object ... ok\nCopy storage object across containers ... ok\nCopy storage object ... ok\nChange the content type of an existing object ... ok\nCreate storage object, test response ... ok\nCreate and delete a storage object, test responses ... ok\nRetrieve object\'s data(in response body) ... ok\nAdd metadata to storage object, test if metadata is retrievable ... ok\nVersioned container responses tests ... ok\nCreate/get/delete volume with volume_type and extra spec. ... ok\nCreate/Delete volume type. ... ok\nCreate/get volume type. ... ok\nList Volume types. ... ok\nCreate/Delete volume type extra spec. ... FAIL\nCreate/get volume type extra spec ... FAIL\nList Volume types extra specs. ... FAIL\nUpdate volume type extra specs ... FAIL\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not create volume type extra spec for invalid POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for none POST body. ... SKIP: Until bug 1090322 is fixed\nShould not create volume type extra spec for nonexistent volume ... ok\nShould not delete volume type extra spec for nonexistent ... ok\nShould not get volume type extra spec for nonexistent extra spec ... ok\nShould not get volume type extra spec for nonexistent type id. ... ok\nShould not list volume type extra spec for nonexistent type id. ... ok\nShould not update volume type extra specs with multiple specs as ... ok\nShould not update volume type extra specs with no body ... SKIP: Until bug 1090320 is fixed\nShould not update volume type extra specs with none id. ... ok\nShould not update volume type extra specs with nonexistent id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nShould not be able to create volume type with an empty name. ... SKIP: Until bug 1090356 is fixed\nShould not be able to create volume with nonexistent volume_type. ... ok\nShould not be able to delete volume type with nonexistent type id. ... ok\nShould not be able to get volume type with nonexistent type id. ... ok\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nFAIL: Create/Delete volume type extra spec.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 91, in test_volume_type_extra_spec_create_delete\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/e512f82d71464ee2b5603255be04c1eb/types/c11e8fc2-ab2c-42a0-907c-1f65bb575517/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec2\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 27 Dec 2012 01:06:00 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-66971d22-b6dc-48ab-aafd-afc7f7dd2d55\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Create/get volume type extra spec\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 109, in test_volume_type_extra_spec_create_get\n    self.fail(\"Could not create a volume_type extra spec\")\nAssertionError: Could not create a volume_type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not create a volume_type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/e512f82d71464ee2b5603255be04c1eb/types/c11e8fc2-ab2c-42a0-907c-1f65bb575517/extra_specs\ntempest.common.rest_client: ERROR: Request Body: {\"extra_specs\": {\"spec1\": \"val1\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 27 Dec 2012 01:06:01 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-0af54a0f-e2d0-48a6-a4c0-eed91cf01b17\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: List Volume types extra specs.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 59, in test_volume_type_extra_specs_list\n    self.fail(\"Could not list volume types extra specs\")\nAssertionError: Could not list volume types extra specs\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Could not list volume types extra specs\')\n    \n\n======================================================================\nFAIL: Update volume type extra specs\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types_extra_specs.py\", line 75, in test_volume_type_extra_specs_update\n    self.fail(\"Couldnt update volume type extra spec\")\nAssertionError: Couldnt update volume type extra spec\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Couldnt update volume type extra spec\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/e512f82d71464ee2b5603255be04c1eb/types/c11e8fc2-ab2c-42a0-907c-1f65bb575517/extra_specs/spec1\ntempest.common.rest_client: ERROR: Request Body: {\"spec1\": \"val2\"}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 27 Dec 2012 01:06:01 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-83d87227-d775-4360-a9cd-ac4cefee8964\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 587 tests in 2645.154s\n\nFAILED (SKIP=73, failures=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/rabbitmq/rabbit at devstack-1356564087-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/rabbitmq/rabbit at devstack-1356564087.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/49/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<649459971.200.1356484026240.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<14385380.1252311385719777112.JavaMail.defaultUser@defaultHost>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-29 11:09:37',3600,'2013-11-29 10:09:37',NULL,'[Openstack]  Application deployment','Hello everyone,\n\nI\'m searching for an application deployment feature into Openstack. This \nmodule should let me deploy an application (plus the application server\nneeded to run it) on an already istantiated VM of Openstack.\nBasically, I\'m thinking it as a SSH + SCP process which accesses the VM to \ninstall the application server and then copies the web app file (.war, ...) \ninto the deployment folder of the server.\n\nIs there any module or project which can do the trick?\n\nThank you\n\n\n',NULL,NULL),('<1438567161.14.1352505665734.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:01:05',0,'2012-11-10 00:01:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-diablo #88','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/88/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/>\nCheckout:periodic-horizon-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson230070673287192355.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-diablo/88\n[SCP] Copying console log.\n\n\n','<1795769166.0.1352419277604.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<143861007.79.1383890965337.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-08 06:09:25',0,'2013-11-08 06:09:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #53','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/53/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4695810>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4695810>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46a6290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46a6290>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-c750dcfb-253a-40d0-9925-a8753afed3f8\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:08:58Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'58\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'58\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:08:58Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'58\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'58\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:08:58+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'58\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'58\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:08:58-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'58\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'58\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:08:58Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'58\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'58\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46b4d10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19d56d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.43 secs:\n    16.04    TestScrubber.test_delayed_delete\n    13.51    TestGlanceControl.test_reload\n    13.29    TestGlanceControl.test_bouncing\n    13.26    TestGlanceControl.test_respawn\n    12.34    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 498.635s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-53\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.LidYlwdBLK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/53\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/53/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/53\n[SCP] Copying console log.\n\n\n','<1887542530.77.1383804727425.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1439353177.226.1354666307771.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-05 00:11:47',0,'2012-12-05 00:11:47',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #65','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/65/>\n\n\n\n','<1104064076.210.1354579929525.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<143A09F3-EF33-4AFA-AEE1-AD6F3269B1C8@linux.vnet.ibm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-25 12:25:57',0,'2014-11-25 12:25:57',NULL,'[openstack-dev] [Keystone] Splitting up the assignment component','Hi\n\nAs most of you know, we have approved a spec (https://review.openstack.org/#/c/129397/) to split the assignments component up into two pieces, and the code (divided up into a series of patches) is currently in review (https://review.openstack.org/#/c/130954/). While most aspects of the split appear to have agreement, there is one aspect that has been questioned - and that is the whether \"roles\' should be in the \"resource\" component, as proposed?\n\nFirst, let\'s recap the goals here:\n\n1) The current \"assignment\" component is really what\'s left after we split off users/groups into \"identity\" some releases ago.  \"Assignments\" is pretty complicated and messy - and we need a better structure (as an example, just doing the split allowed me to find 5 bugs in our current implementation - and I wouldn\'t be surprised if there are more).  This is made more urgent by the fact that we are about to land some big new changes in this area, e.g. hierarchical projects and a re-implemntation (for performance) of list_role_assignments.\n\n2) While Keystone may have started off as a service where we \"store all the users, credentials & permissions\" needed to access other OpenStack services, we more and more see Keystone as a wrapper for existing corporate authentication and authorisation mechanisms - and it\'s job is really to provided a common mechanism and language for these to be consumed across OpenStack services.  To do this well, we must make sure that the keystone components are split along sensible lines...so that they can individually wrap these corporate directories/services.  The classic case of this was are previous split off of Identity...and this new proposal takes this a step further.\n\n3) As more and more broad OpenStack powered clouds are created, we must makes sure that our Keystone implementation is as flexible as possible. We already plan to support new abstractions for things like cloud providers enabling resellers to do business within one OpenStack cloud (by providing hierarchical multi-tenancy, domain-roles etc.). Our current assignments model is a) slightly unusual in that all roles are global and every assignment has actor-target-role, and b) cannot easily be substituted for alternate assignment models (even for the whole of an OpenStack installation, let alone on a domain by domain basis)\n\nThe proposal for splitting the assignment component is trying to provide a better basis for the above.  It separates the storing and CRUD operations of domain/projects/roles into a \"resource\" component, while leaving the pure assignment model in \"assignment\".  The rationale for this is that the resource component defines the entities that the rest of the OpenStack services (and their policy engines) understand...while assignment is a pure mapper between these entities. The details of these mappings are never exposed outside of Keystone, except for the generation of contents of a token.  This would allow new assignment models to be introduced that, as long as they support the api to \"list what role_ids are mapped to project_id X for user_id Y\", then the rest of OpenStack would never know anything had changed.\n\nSo to (finally) get the the point of this post...where should the role definitions live? The proposal is that these live in \"resource\", because:\n\na) They represent the definition of how Keystone and the other services define permission - and this should be independent of whatever assignment model we choose\nb) We may well chose (in the future) to morph what we currently means as a role...into what they really are, which is a capability.  Once we have domain-specifc roles (groups), which map to \"global roles\", then we may well end up, more often than not, with a role representing a single API capability.  \"Roles\" might even be \"created\" simply by a service registering its capabilities with Keystone.  Again, this should be independent of any assignment model.\nc) By placing roles in the resource component, we allow much greater flexibility....for example we could have different domains having different assignment models (e.g. one RABC, one ABAC, one HenrysWeirdAccessControl (HWAC). Obviously this would be aimed at a different type of cloud than one that has multiple layers of domain inheritance - but that\'s part of the goal of OpenStack, to allow different models to be supported.\n\nI am absolutely open to arguments that roles should remain with \"assignments\"...but right now the above feels the better solution. I\'ve put this topic on the agenda for today\'s Keystone IRC meeting.\n\nHenry\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141125/f5089458/attachment.pgp>\n\n',NULL,NULL),('<144105007.809851.1404219977920.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-01 09:06:17',-14400,'2014-07-01 13:06:17',NULL,'[openstack-dev] [neutron]Performance of security group','\n\nOk, I was talking with ?douard @ IRC, and as I have time to work \ninto this problem, I could file an specific spec for the security\ngroup RPC optimization, a masterplan in two steps:\n\n1) Refactor the current RPC communication for security_groups_for_devices,\n   which could be used for full syncs, etc..\n\n2) Benchmark && make use of a fanout queue per security group to make\n   sure only the hosts with instances on a certain security group get\n   the updates as they happen.\n\n@shihanzhang do you find it reasonable?\n\n\n\n----- Original Message -----\n> ----- Original Message -----\n> > @Nachi: Yes that could a good improvement to factorize the RPC mechanism.\n> > \n> > Another idea:\n> > What about creating a RPC topic per security group (quid of the RPC topic\n> > scalability) on which an agent subscribes if one of its ports is associated\n> > to the security group?\n> > \n> > Regards,\n> > ?douard.\n> > \n> > \n> \n> \n> Hmm, Interesting,\n> \n> @Nachi, I\'m not sure I fully understood:\n> \n> \n> SG_LIST [ SG1, SG2]\n> SG_RULE_LIST = [SG_Rule1, SG_Rule2] ..\n> port[SG_ID1, SG_ID2], port2 , port3\n> \n> \n> Probably we may need to include also the\n> SG_IP_LIST = [SG_IP1, SG_IP2] ...\n> \n> \n> and let the agent do all the combination work.\n> \n> Something like this could make sense?\n> \n> Security_Groups = {SG1:{IPs:[....],RULES:[....],\n>                    SG2:{IPs:[....],RULES:[....]}\n>                   }\n> \n> Ports = {Port1:[SG1, SG2], Port2: [SG1] .... }\n> \n> \n> @Edouard, actually I like the idea of having the agent subscribed\n> to security groups they have ports on... That would remove the need to\n> include\n> all the security groups information on every call...\n> \n> But would need another call to get the full information of a set of security\n> groups\n> at start/resync if we don\'t already have any.\n> \n> \n> > \n> > On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang < ayshihanzhang at 126.com >\n> > wrote:\n> > \n> > \n> > \n> > hi Miguel ?ngel,\n> > I am very agree with you about the following point:\n> > >  * physical implementation on the hosts (ipsets, nftables, ... )\n> > --this can reduce the load of compute node.\n> > >  * rpc communication mechanisms.\n> > -- this can reduce the load of neutron server\n> > can you help me to review my BP specs?\n> > \n> > \n> > \n> > \n> > \n> > \n> > \n> > At 2014-06-19 10:11:34, \"Miguel Angel Ajo Pelayo\" < mangelajo at redhat.com >\n> > wrote:\n> > >\n> > >  Hi it\'s a very interesting topic, I was getting ready to raise\n> > >the same concerns about our security groups implementation, shihanzhang\n> > >thank you for starting this topic.\n> > >\n> > >  Not only at low level where (with our default security group\n> > >rules -allow all incoming from \'default\' sg- the iptable rules\n> > >will grow in ~X^2 for a tenant, and, the\n> > >\"security_group_rules_for_devices\"\n> > >rpc call from ovs-agent to neutron-server grows to message sizes of\n> > >>100MB,\n> > >generating serious scalability issues or timeouts/retries that\n> > >totally break neutron service.\n> > >\n> > >   (example trace of that RPC call with a few instances\n> > > http://www.fpaste.org/104401/14008522/ )\n> > >\n> > >  I believe that we also need to review the RPC calling mechanism\n> > >for the OVS agent here, there are several possible approaches to breaking\n> > >down (or/and CIDR compressing) the information we return via this api\n> > >call.\n> > >\n> > >\n> > >   So we have to look at two things here:\n> > >\n> > >  * physical implementation on the hosts (ipsets, nftables, ... )\n> > >  * rpc communication mechanisms.\n> > >\n> > >   Best regards,\n> > >Miguel ?ngel.\n> > >\n> > >----- Mensaje original -----\n> > >\n> > >> Do you though about nftables that will replace {ip,ip6,arp,eb}tables?\n> > >> It also based on the rule set mechanism.\n> > >> The issue in that proposition, it\'s only stable since the begin of the\n> > >> year\n> > >> and on Linux kernel 3.13.\n> > >> But there lot of pros I don\'t list here (leverage iptables limitation,\n> > >> efficient update rule, rule set, standardization of netfilter\n> > >> commands...).\n> > >\n> > >> ?douard.\n> > >\n> > >> On Thu, Jun 19, 2014 at 8:25 AM, henry hly < henry4hly at gmail.com >\n> > >> wrote:\n> > >\n> > >> > we have done some tests, but have different result: the performance is\n> > >> > nearly\n> > >> > the same for empty and 5k rules in iptable, but huge gap between\n> > >> > enable/disable iptable hook on linux bridge\n> > >> \n> > >\n> > >> > On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang < ayshihanzhang at 126.com\n> > >> > >\n> > >> > wrote:\n> > >> \n> > >\n> > >> > > Now I have not get accurate test data, but I can confirm the\n> > >> > > following\n> > >> > > points?\n> > >> > \n> > >> \n> > >> > > 1. In compute node, the iptable\'s chain of a VM is liner, iptable\n> > >> > > filter\n> > >> > > it\n> > >> > > one by one, if a VM in default security group and this default\n> > >> > > security\n> > >> > > group have many members, but ipset chain is set, the time ipset\n> > >> > > filter\n> > >> > > one\n> > >> > > and many member is not much difference.\n> > >> > \n> > >> \n> > >> > > 2. when the iptable rule is very large, the probability of failure\n> > >> > > that\n> > >> > > iptable-save save the iptable rule is very large.\n> > >> > \n> > >> \n> > >\n> > >> > > At 2014-06-19 10:55:56, \"Kevin Benton\" < blak111 at gmail.com > wrote:\n> > >> > \n> > >> \n> > >\n> > >> > > > This sounds like a good idea to handle some of the performance\n> > >> > > > issues\n> > >> > > > until\n> > >> > > > the ovs firewall can be implemented down the the line.\n> > >> > > \n> > >> > \n> > >> \n> > >> > > > Do you have any performance comparisons?\n> > >> > > \n> > >> > \n> > >> \n> > >> > > > On Jun 18, 2014 7:46 PM, \"shihanzhang\" < ayshihanzhang at 126.com >\n> > >> > > > wrote:\n> > >> > > \n> > >> > \n> > >> \n> > >\n> > >> > > > > Hello all,\n> > >> > > > \n> > >> > > \n> > >> > \n> > >> \n> > >\n> > >> > > > > Now in neutron, it use iptable implementing security group, but\n> > >> > > > > the\n> > >> > > > > performance of this implementation is very poor, there is a bug:\n> > >> > > > > https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this\n> > >> > > > > problem.\n> > >> > > > > In\n> > >> > > > > his test, w ith default security groups(which has remote\n> > >> > > > > security\n> > >> > > > > group),\n> > >> > > > > beyond 250-300 VMs, there were around 6k Iptable rules on evry\n> > >> > > > > compute\n> > >> > > > > node,\n> > >> > > > > although his patch can reduce the processing time, but it don\'t\n> > >> > > > > solve\n> > >> > > > > this\n> > >> > > > > problem fundamentally. I have commit a BP to solve this problem:\n> > >> > > > > https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security\n> > >> > > > > >> > > >\n> > >> > > \n> > >> > \n> > >> \n> > >> > > > > There are other people interested in this it?\n> > >> > > > \n> > >> > > \n> > >> > \n> > >> \n> > >\n> > >> > > > > _______________________________________________\n> > >> > > > \n> > >> > > \n> > >> > \n> > >> \n> > >> > > > > OpenStack-dev mailing list\n> > >> > > > \n> > >> > > \n> > >> > \n> > >> \n> > >> > > > > OpenStack-dev at lists.openstack.org >> > > >\n> > >> > > \n> > >> > \n> > >> \n> > >> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >> > > > > >> > > >\n> > >> > > \n> > >> > \n> > >> \n> > >\n> > >> > > _______________________________________________\n> > >> > \n> > >> \n> > >> > > OpenStack-dev mailing list\n> > >> > \n> > >> \n> > >> > > OpenStack-dev at lists.openstack.org >> >\n> > >> \n> > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>\n> > >> > > >\n> > >> \n> > >\n> > >> > _______________________________________________\n> > >> \n> > >> > OpenStack-dev mailing list\n> > >> \n> > >> > OpenStack-dev at lists.openstack.org >>\n> > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>\n> > >\n> > >> _______________________________________________\n> > >> OpenStack-dev mailing list\n> > >> OpenStack-dev at lists.openstack.org >>\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >\n> > >_______________________________________________\n> > >OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org >\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<63918211.23661719.1403803970286.JavaMail.zimbra@redhat.com>',NULL),('<1441090571.1268289.1380818836388.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-03 12:47:16',-14400,'2013-10-03 16:47:16',NULL,'[Openstack-stable-maint] Stable grizzly failures','Hi.\n\nFirst - unskip proposed https://review.openstack.org/#/c/49589/\n   but I\'m worried that it will suffer from https://bugs.launchpad.net/neutron/+bug/1234181\n\nSecond - python-keyring issue seems already fixed in keyring>=2.1\n   as per https://bitbucket.org/kang/python-keyring-lib/issue/115/error-root-could-not-find-any-typelib-for#comment-6139490 \n   so we can continue with unpinning after that - https://bugs.launchpad.net/devstack/+bug/1217120\n\n----- Original Message -----\n> From: \"Thierry Carrez\" <thierry at openstack.org>\n> To: \"Pavel Sedlak\" <psedlak at redhat.com>\n> Cc: \"openstack-stable-maint\" <openstack-stable-maint at lists.openstack.org>, \"Alan Pevec\" <apevec at gmail.com>, \"David\n> Kranz\" <dkranz at redhat.com>\n> Sent: Thursday, September 26, 2013 11:53:22 AM\n> Subject: Re: [Openstack-stable-maint] Stable grizzly failures\n> \n> Thierry Carrez wrote:\n> > Pavel Sedlak wrote:\n> >> Yes we should be ok to remove those skips with keyring < 2.0.\n> >>\n> >> But to stop thinking about it, we should first at least\n> >> get https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1197988\n> >> moving,\n> >> but I can\'t re-open it. So who can?\n> > \n> > You should probably file a separate bug about the reintroduction of the\n> > same issue in 2.0, referencing the original bug. That\'s better than\n> > reopening a but that was (correctly) closed.\n> > \n> >> Also I\'ve proposed backport of complete cli-output logging also to\n> >> tempest-stable/grizly https://review.openstack.org/#/c/46485/.\n> >> I would suggest that un-skip should better happen after that, so we don\'t\n> >> find ourself in the dark again.\n> > \n> > OK, let\'s get some tempest eyes on this one...\n> \n> That change was merged... If you don\'t see any other obstacle, please\n> push a change to unskip the tests... would be great to have that in\n> before we actually do 2013.1.4.\n> \n> --\n> Thierry Carrez (ttx)\n> \n\n-- \nPavel Sedl?k <psedlak at redhat.com>\n OpenStack Quality Engineer\n Red Hat Czech / BRQ\n irc: psedlak\n phone: +420532294659 | (82) 62659\n\n\n\n','<52440412.7040707@openstack.org>',NULL),('<1441576316.30.1385879360879.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-01 06:29:20',0,'2013-12-01 06:29:20',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #7','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/7/>\n\n------------------------------------------\n[...truncated 20904 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  188.319\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           93.925\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  74.555\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        41.156\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         40.463\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             37.378\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                36.501\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     34.702\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    33.632\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     33.234\n\n----------------------------------------------------------------------\nRan 1340 tests in 1295.345s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-766616-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-766616.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-766616/7/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<578750000.27.1385792909654.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1441690851.406661360097322097.JavaMail.nobody@rsj2rmd006.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-02-05 20:48:42',0,'2013-02-05 20:48:42',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting\n February 12, 2013 F2F Full Day Meeting','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the February 12th OpenStack board meeting. \n\nThis board meeting is a face-to-face meeting.  For those board members who are unable to attend in person and community members who wish to listen in please join using WebEx. \n\nPlease join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting February 12, 2013 F2F Full Day Meeting\nHost: Alan Clark\nDate: Tuesday, February 12, 2013\nTime: 10:00 am, Pacific Standard Time (San Francisco, GMT-08:00)\nSession number: 922 185 465\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=216316677&UID=1512836597&HMAC=4e4dba683d05f1b40389517db47c141d48f61d55&RT=MiM0\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=216316677&EF=MA&UUID=1512836597&SHA2=j9PTs3ycd8bQC0y200GcudTPKwd6RVyqC9id5VxeWQs%3D&RT=MiM0\n\n\n\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=216316677&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 185 465\n\n\nhttp://www.webex.com\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130205/19a1bc99/attachment.html>\n\n',NULL,NULL),('<1442595220.22117464.1409836934599.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 15:22:14',7200,'2014-09-04 13:22:14',NULL,'[openstack-dev] [nova] [feature freeze exception] FFE for\n libvirt-start-lxc-from-block-devices','Hello,\n\nI would like to ask for an extension for libvirt-start-lxc-from-block-devices feature. It has been previously pushed from Ice house to Juno.\nThe spec [1] has been approved. One of the patches is a bug fix. Another patch has been already approved and failed in the gate.\nAll patches has a +2 from Daniel Berrange.\n\nThe list of the remaining patches are in [2].\n\n\n[1] https://review.openstack.org/#/c/88062\n[2] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/libvirt-start-lxc-from-block-devices,n,z\n\nThank you,\nVladik\n\n\n','<64436281.22114701.1409836112075.JavaMail.zimbra@enovance.com>',NULL),('<1442742900.35.1381212667008.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-08 06:11:06',0,'2013-10-08 06:11:06',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #32','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/32/>\n\n------------------------------------------\n[...truncated 952 lines...]\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 61, in test_interrupt_avoids_respawn_storm\n    execute(cmd, raise_error=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/utils.py\",> line 255, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command kill -INT 9972 9971 did not succeed. Returned an exit code of 1.\n\nSTDOUT: \n\nSTDERR: /bin/sh: 1: kill: No such process\n\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.68 secs:\n    14.22    TestScrubber.test_delayed_delete\n    13.82    TestGlanceControl.test_reload\n    13.59    TestGlanceControl.test_respawn\n    13.52    TestGlanceControl.test_bouncing\n    12.53    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 926 tests in 509.006s\n\nFAILED (SKIP=89, errors=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-32\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.7.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.EpGh0yndkg\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/32/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise3/32\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1442965516.3032947.1353083515173.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 11:31:55',-18000,'2012-11-16 16:31:55',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction	going forward','\n\n----- Original Message -----\n> \n> ________________________________________\n> From: Eoghan Glynn [eglynn at redhat.com]\n> Sent: Friday, November 16, 2012 7:44 AM\n> \n> >OK, I think we need to distinguish an (at least blurry) line between\n> >instrumentation and monitoring.\n> >\n> >For me monitoring is mostly about coarse-grained observables that\n> >allow user-oriented questions to be asked about cloud resources:\n> >\n> > - are my instances running hot?\n> > - are my volumes falling behind with queued I/O?\n> > - is my load balancer spitting out many 503s?\n> >... etc.\n> >\n> >Whereas instrumentation to me implies much more internal-facing\n> >and fine-grained concerns such as:\n> >\n> > - what\'s the fault-rate & latency for a particular API?\n> > - how much time is being spent accessing the DB?\n> > - how many idle connections are currently in some pool?\n> >\n> >I\'m maybe stating the obvious above, but the point is that its\n> >the type of question being asked that distinguishes monitoring\n> >from instrumentation, not the sampling rate.\n> >\n> >For certain types of monitoring, I think we do need relatively\n> >high sampling rates (e.g. once or twice a minute) that are near\n> >constant (61s, 59s, 62s, ... as opposed to 45s, 75s, 52s, ...).\n> >In that case, I\'m not sure we can rely on the cadence of the\n> >notifications issued by a busy nova compute service.\n> \n> Yes, the line between instrumentation and monitoring can get a little\n> blurry here and I think there are some important points you bring up\n> here.\n> \n> I would *never* assume anything in user space. I think monitoring of\n> the users instances is out of scope for all things OpenStack. The\n> users might deploy whatever tools they like for checking i/o, disk,\n> network, etc.\n\nThat\'s an interesting point of view, that I hadn\'t considered before.\n\nI would see AWS CloudWatch as a user-oriented monitoring service,\nand would have assumed that there is scope for something similar\nto be part of openstack.\n\nWhen you say its out of scope, do you mean that it shouldn\'t be\nsomething addressed by the IaaS fabric, and should instead be\nsomething that users bolt on top by running agents *within* their\ninstances?\n\n(as opposed to some piece of the openstack infrastructure doing\n this monitoring from *outside* the instance)\n \nI recall the Heat team ran into some complications on this whole\nwithin-versus-without question, as the openstack RBAC mechanisms\naren\'t yet flexible enough to easily grant in-instance agents\ncredentials giving limited roles such as the ability to report\nmetrics to a CW-like metricstore.\n\n\n> For the Deployer of openstack, yes they will want to check if the\n> Services are running hot, falling behind queued i/o or the public\n> openstack api load balancer is spitting out 503\'s. My\n> differentiation of instrumentation and monitoring in these cases are\n> related to the sample rate and size of the payload. 503\'s, i/o, etc\n> I would view as instrumentation. Sampled frequently and with little\n> payload. This is the classic statsd/graphite data. Shown in a big\n> graph on the wall of the Network Operations Center. Monitoring would\n> be larger, slower, chunkier data for Capacity Planning, etc.\n> Lifecycle state falls into the Monitoring camp as well. \"Are things\n> progressing as expected? Or will they be a problem down the road.\"\n\nOK, so this cloud-operator-oriented view is also crucial, but I\'d\nbe leery about making this the entire focus of our efforts (i.e. by\nassuming that users will sort themselves out with their own monitoring\nsolution).\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF038883D3F94C@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1443989689.44077955.1413914005446.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-21 13:53:25',-14400,'2014-10-21 17:53:25',NULL,'[openstack-dev] [Nova] Automatic evacuate','\n\n----- Original Message -----\n> > -----Original Message-----\n> > From: Russell Bryant [mailto:rbryant at redhat.com]\n> > Sent: October 21, 2014 15:07\n> > To: openstack-dev at lists.openstack.org\n> > Subject: Re: [openstack-dev] [Nova] Automatic evacuate\n> > \n> > On 10/21/2014 06:44 AM, Bal?zs Gibizer wrote:\n> > > Hi,\n> > >\n> > > Sorry for the top posting but it was hard to fit my complete view inline.\n> > >\n> > > I\'m also thinking about a possible solution for automatic server\n> > > evacuation. I see two separate sub problems of this problem:\n> > > 1)compute node monitoring and fencing, 2)automatic server evacuation\n> > >\n> > > Compute node monitoring is currently implemented in servicegroup\n> > > module of nova. As far as I understand pacemaker is the proposed\n> > > solution in this thread to solve both monitoring and fencing but we\n> > > tried and found out that pacemaker_remote on baremetal does not work\n> > > together with fencing (yet), see [1]. So if we need fencing then\n> > > either we have to go for normal pacemaker instead of pacemaker_remote\n> > > but that solution doesn\'t scale or we configure and call stonith\n> > > directly when pacemaker detect the compute node failure.\n> > \n> > I didn\'t get the same conclusion from the link you reference.  It says:\n> > \n> > \"That is not to say however that fencing of a baremetal node works any\n> > differently than that of a normal cluster-node. The Pacemaker policy engine\n> > understands how to fence baremetal remote-nodes. As long as a fencing\n> > device exists, the cluster is capable of ensuring baremetal nodes are\n> > fenced\n> > in the exact same way as normal cluster-nodes are fenced.\"\n> > \n> > So, it sounds like the core pacemaker cluster can fence the node to me.\n> >  I CC\'d David Vossel, a pacemaker developer, to see if he can help clarify.\n> \n> It seems there is a contradiction between chapter 1.5 and 7.2 in [1] as 7.2\n> states:\n> \" There are some complications involved with understanding a bare-metal\n> node\'s state that virtual nodes don\'t have. Once this logic is complete,\n> pacemaker will be able to integrate bare-metal nodes in the same way virtual\n> remote-nodes currently are. Some special considerations for fencing will\n> need to be addressed. \"\n> Let\'s wait for David\'s statement on this.\n\nHey, That\'s me!\n\nI can definitely clear all this up.\n\nFirst off, this document is out of sync with the current state upstream. We\'re\nalready past Pacemaker v1.1.12 upstream. Section 7.2 of the document being\nreferenced is still talking about future v1.1.11 features.\n\nI\'ll make it simple. If the document references anything that needs to be done\nin the future, it\'s already done.  Pacemaker remote is feature complete at this\npoint. I\'ve accomplished everything I originally set out to do. I see one change\nthough. In 7.1 I talk about wanting pacemaker to be able to manage resources in\ncontainers. I mention something about libvirt sandbox. I scrapped whatever I was\ndoing there. Pacemaker now has docker support.\nhttps://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/docker\n\nI\'ve known this document is out of date. It\'s on my giant list of things to do.\nSorry for any confusion.\n\nAs far as pacemaker remote and fencing goes, remote-nodes are fenced the exact\nsame way as cluster-nodes. The only consideration that needs to be made is that\nthe cluster-nodes (nodes running the full pacemaker+corosync stack) are the only\nnodes allowed to initiate fencing. All you have to do is make sure the fencing\ndevices you want to use to fence remote-nodes are accessible to the cluster-nodes.\n>From there you are good to go.\n\nLet me know if there\'s anything else I can clear up. Pacemaker remote was designed\nto be the solution for the exact scenario you all are discussing here.  Compute nodes\nand pacemaker remote are made for one another :D\n\nIf anyone is interested in prototyping pacemaker remote for this compute node use\ncase, make sure to include me. I have done quite a bit research into how to maximize\npacemaker\'s ability to scale horizontally. As part of that research I\'ve made a few\nchanges that are directly related to all of this that are not yet in an official\npacemaker release.  Come to me for the latest rpms and you\'ll have a less painful\nexperience setting all this up :)\n\n-- Vossel\n\n\n\n\n\n\n\n> \n> Cheers,\n> Gibi\n> \n> > \n> > --\n> > Russell Bryant\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<9B0DC2BE4E53754AAFDE729C12B1BB601C81361E@ESESSMB103.ericsson.se>',NULL),('<1443f74ec81f4f12b9750fefe83dc265@BN1PR03MB153.namprd03.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-02-19 12:37:28',0,'2014-02-19 12:37:28',NULL,'[OpenStack-Infra] External Testing :: install-master.sh errors','Hi Jay-\n\n\nWhile installing the master node  using install_master.sh,\n\n\nI get this error\n\n\nCould not parse configuration file: Certificate names must be lower case; see #1168\n\n\nwith the command,\n\n\nsudo puppet apply --verbose $PUPPET_MODULE_PATH -e \"class {\'os_ext_testing::master\': $CLASS_ARGS }\"\n\n\nWhen I print the command, the complete key and certificate file contents are given in the JSON format. I feel, that this error specifies that it needs only lower case string rather than upper case.\n\n\nAlso, do we need to provide the file names or the file contents in the JSON string to the \"puppet apply\" command.\n\n\nKindly guide me resolve the same.\n\n\nThanks in advance,\n\n\n--\n\nTrinath S\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140219/ecb0e18c/attachment.html>\n\n',NULL,NULL),('<1444181655.2976627.1392739941288.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-18 17:12:21',3600,'2014-02-18 16:12:21',NULL,'[openstack-dev] [Heat] lazy translation is breaking Heat','> This change was recently merged:\n> \n> https://review.openstack.org/#/c/69133/\n> \n> Unfortunately it didn\'t enable lazy translations for the unit tests, so it\n> didn\'t catch the many places in Heat that won\'t work when lazy translations\n> are enabled. Notably there are a lot of cases where the code adds the result\n> of a call to _() with another string, and Message objects (which are\n> returned from _ when lazy translations are enabled) can\'t be added,\n> resulting in an exception being raised.\n> \n> I think the best course of action would be to revert this change, and then\n> reintroduce it along with patches to fix all the problems, while enabling it\n> for the unit tests so bugs won\'t be reintroduced in the future.\n\n+1 for me to revert it. It broke Heat before, and it did it again because we didn\'t have any tests. Let\'s have a proper test environment for not making that mistake again and again.\n\n-- \nThomas\n\n\n','<CAPkRfUSSu8jRxd6b8FM=c4NjMaH_ikiu1CSy35q_S-7mnKybDw@mail.gmail.com>',NULL),('<1445297960.316.1366784564623.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-24 06:22:44',0,'2013-04-24 06:22:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #14','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/14/>\n\n------------------------------------------\n[...truncated 1165 lines...]\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.01\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.02\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.02\n    test_connection_with_snet                                    OK    0.03\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.03\n    test_connection_invalid_user                                 OK    0.02\n    test_connection_missing_user                                 OK    0.03\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.03\n    test_connection_with_region                                  OK    0.03\n    test_connection_with_service_type                            OK    0.02\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.02\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_cache_middleware.TestImageCacheSqlite.test_cache_middleware_transparent_v2\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 140, in test_cache_middleware_transparent_v2\n    body=json.dumps(image_entity))\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 106.96 secs:\n    29.08    TestScrubber.test_scrubber_app\n    22.94    TestScrubber.test_delayed_delete\n    19.99    TestRootApi.test_version_configurations\n    18.75    TestBinGlanceCacheManage.test_queue\n    16.19    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1102 tests in 777.267s\n\nFAILED (SKIP=55, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.0\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.14\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.1.2\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.30\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.A75vBGpVVV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/14\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/14/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1445508271.12760437.1343854521718.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-01 16:55:21',-14400,'2012-08-01 20:55:21',NULL,'[openstack-dev] 3-rd party endpoint lookup and interpolation','I think that this pattern ( \"do on behalf of\") is going to be very common.  I\'ll take a look at the V3 API and see if we have it covered.\n\n\n----- Original Message -----\nFrom: \"Pete Zaitcev\" <zaitcev at redhat.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nCc: ayoung at redhat.com\nSent: Wednesday, August 1, 2012 2:11:57 PM\nSubject: Re: [openstack-dev] 3-rd party endpoint lookup and interpolation\n\nOn Tue, 31 Jul 2012 11:56:32 -0400\nAdam Young <ayoung at redhat.com> wrote:\n\n> > So, ideally I would like an API call that permits an administrator account\n> > to submit own credentials, but look up and interpolate someone else\'s\n> > StorageURL. Do we have such a call?\n> \n> Did you ever get an answer?  What approach did you take?\n\nI ran with the double-list for now, like this:\n\ndef find_storage_url(par, keystone):\n\n    slist = keystone.services.list()\n    swift_svc = None\n    for svc in slist:\n        if svc.type == \'object-store\':\n            swift_svc = svc\n    if not swift_svc:\n        raise LocalError(\"No \'object-store\' service\")\n\n    elist = keystone.endpoints.list()\n    swift_ep = None\n    for ep in elist:\n        if ep.service_id == swift_svc.id:\n            swift_ep = ep\n            break\n    if not swift_ep:\n        raise LocalError(\"No endpoint for service id %s\" % swift_svc.id)\n    return swift_ep.publicurl\n\nAlthough cumbersome, this is not called for every user, and only\nloops across the limited number of services and endpoints, not across\nall users. So it\'s acceptable, just annoying. I do not demand that\nwe enhance Keystone API for this use case.\n\n-- Pete\n\n\n','<20120801121157.530087c8@lembas.zaitcev.lan>',NULL),('<1445692422.24.1380003214136.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-24 06:13:33',0,'2013-09-24 06:13:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #30','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/30/>\n\n------------------------------------------\n[...truncated 5511 lines...]\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 21471\n+ mkdir -p /opt/stack/new/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sudo iptables -S -v\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ awk \'{print \"sudo iptables\",$0}\'\n+ bash\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ sudo iptables -S -v -t nat\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ grep \'\\-A\'\n+ sed s/-A/-D/g\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ bash\n+ sudo iptables -S -v\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ bash\n+ awk \'{print \"sudo iptables\",$0}\'\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ sudo iptables -S -v -t nat\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ grep \'\\-N\'\n+ sed s/-N/-X/g\n+ bash\n++ sudo virsh list --all\n++ grep instance-\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ xargs sudo iscsiadm --mode node --logout\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ grep volume-\n+ cut -d \' \' -f2\n+ sudo iscsiadm --mode node --op delete\niscsiadm: iscsiadm: no records found!\nno records found!\n+ true\n+ sudo rm -rf \'/opt/stack/new/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/new/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4,<1.5 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/https%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.8.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_compressor%2Fdjango_compressor-1.3.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth<1.1.0 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /opt/stack/new/python-cinderclient (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/new/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /opt/stack/new/python-keystoneclient (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/new/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nRequirement already satisfied (use --upgrade to upgrade): pytz>=2010h in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 10))\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.6.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fdjango-appconf%2Fdjango-appconf-0.6.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): oslo.config>=1.2.0a3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from python-keystoneclient->-r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing>=1.5.6,<2.0 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2012.2.5 to easy-install.pth file\n\nInstalled /opt/stack/new/horizon\nProcessing dependencies for horizon==2012.2.5\nerror: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-24-060123\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-378531-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-378531.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az2-378531/30/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1445729929.24859630.1411577427173.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-24 12:50:27',-14400,'2014-09-24 16:50:27',NULL,'[Openstack] [TripleO]Error while running RDO instack','----- Original Message -----\n> From: \"Peeyush Gupta\" <gpeeyush at linux.vnet.ibm.com>\n> To: openstack at lists.openstack.org\n> \n> Hi all,\n> \n> I have been trying to set up TripleO using RDO instack. I tried it in\n> virtual environment and it works fine. Now, I am trying on physical\n> environment. I installed Fedora 20 on a machine and set up the user stack.\n> Now, when I run \'instack-install-undercloud-packages\', I am getting the\n> following error:\n> \n> + output \'Running /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo\'\n> ++ date\n> + echo dib-run-parts Tue Sep 23 13:00:52 IST 2014 Running\n> /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo\n> dib-run-parts Tue Sep 23 13:00:52 IST 2014 Running\n> /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo\n> + target_tag=00-allow-heat-admin-sudo\n> + date +%s.%N\n> + /tmp/tmpzgbZSQ/pre-install.d/00-allow-heat-admin-sudo\n> /etc/sudoers.d/x2goserver: bad permissions, should be mode 0440\n> /etc/sudoers: parsed OK\n> /etc/sudoers.d/50_stack_sh: parsed OK\n> /etc/sudoers.d/cinder-rootwrap: parsed OK\n> /etc/sudoers.d/heat-admin-notty: parsed OK\n> /etc/sudoers.d/nova-rootwrap: parsed OK\n> /etc/sudoers.d/stack: parsed OK\n> INFO: 2014-09-23 13:00:52,440 -- ############### End stdout/stderr\n> logging ###############\n> ERROR: 2014-09-23 13:00:52,441 --     Hook FAILED.\n> ERROR: 2014-09-23 13:00:52,441 -- Failed running command\n> [\'dib-run-parts\', u\'/tmp/tmpzgbZSQ/pre-install.d\']\n> \n> Then I ran \' dib-run-parts /tmp/tmpNMJP7_/pre-install.d\' command and\n> here is the error I got:\n> \n> + source /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests\n> ++ set -eu\n> ++ export DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests\n> ++ DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests\n> /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests: line 20:\n> IMAGE_NAME: unbound variable\n> \n> So, as I understand there is no IMAGE_NAME set in the system. So, I put\n> fedora-20-undercloud-package as IMAGE_NAME. I am not sure if that is\n> correct or not. Now, I ran the command again (the dib one) and here is\n> the error:\n> \n> + source /tmp/tmpNMJP7_/pre-install.d/../environment.d/15-manifests\n> ++ set -eu\n> ++ export DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests\n> ++ DIB_MANIFEST_IMAGE_DIR=/etc/dib-manifests\n> ++ export DIB_MANIFEST_SAVE_DIR=fedora-20-undercloud-packages.d/\n> ++ DIB_MANIFEST_SAVE_DIR=fedora-20-undercloud-packages.d/\n> + for target in \'$targets\'\n> + output \'Running /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo\'\n> ++ date\n> + echo dib-run-parts Tue Sep 23 13:04:16 IST 2014 Running\n> /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo\n> dib-run-parts Tue Sep 23 13:04:16 IST 2014 Running\n> /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo\n> + target_tag=00-allow-heat-admin-sudo\n> + date +%s.%N\n> + /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo\n> /tmp/tmpNMJP7_/pre-install.d/00-allow-heat-admin-sudo: line 6:\n> /etc/sudoers.d/heat-admin-notty: Permission denied\n> \n> Can you please help me resolve the error?\n> \n> Thanks,\n> \n> --\n> Peeyush Gupta\n> gpeeyush at linux.vnet.ibm.com\n\nHi Peeyush,\n\nDid you create the stack user and add them to sudo?:\n\n# useradd stack\n# passwd stack # specify a password\n# echo \"stack        ALL=(ALL)       NOPASSWD: ALL\" > /etc/sudoers.d/stack\n# chmod 0440 /etc/sudoers.d/stack\n\nSee the bottom of this page:\n\n    https://openstack.redhat.com/Deploying_RDO_on_a_Baremetal_Environment_using_Instack\n\n-Steve\n\n\n','<542149F8.3050007@linux.vnet.ibm.com>',NULL),('<1445992469.881927.1346781621487.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-04 11:00:21',-25200,'2012-09-04 18:00:21',NULL,'[openstack-dev] Is volume attachment to an LXC instance is broken?','\n?Is volume attachment to an LXC instance is broken?\n\n?I\'m trying to run the following command:\n$ euca-attach-volume vol-00000007 -i i-0000000b -d /dev/vdc\n\nIt fails and the nova-compute log is copied and pasted below.\nThe error message is : \n??\"InvalidDevicePath: The supplied device path (/dev/a) is invalid.\"\nThe device name given is \"/dev/vdc\", but it looks like that get_device_name_for_instance()\nchanges it to \'/dev/a\'.\nAnd it ends up the error of \"InvalidDevicePath\".\n\nIs it bug or my mistake?\nI pulled the nova from github on August 29th.\nAnd the followings are configured in /etc/nova/nova.conf file.\n??use_cow_images=True\n??libvirt_type=lxc\n\n?Thanks,\n?David\n\n------------- log of nova-compute ---------------\n\n2012-09-04 13:37:46 DEBUG nova.utils [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Got semaphore \"f3fb4350-a72e-404f-a21f-10f333fe67e8\" for method \"do_reserve\"... from (pid=13108) inner /usr/local/nova/nova/utils.py:712\n2012-09-04 13:37:46 DEBUG nova.utils [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Attempting to grab semaphore \"compute_resources\" for method \"update_load_stats_for_instance\"... from (pid=13108) inner /usr/local/nova/nova/utils.py:708\n2012-09-04 13:37:46 DEBUG nova.utils [req-79250a0b-6c11-4afc-a0a4-75736d3853c5 admin admin] Got semaphore \"compute_resources\" for method \"update_load_stats_for_instance\"... from (pid=13108) inner /usr/local/nova/nova/utils.py:712\n2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in _process_data\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? rval = self.proxy.dispatch(ctxt, version, method, **args)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145, in dispatch\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? return getattr(proxyobj, method)(ctxt, **kwargs)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? temp_level, payload)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? return f(*args, **kw)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 211, in decorated_function\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? pass\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 204, in decorated_function\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? return function(self, context, *args, **kwargs)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 237, in decorated_function\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? instance_uuid, e, sys.exc_info())\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? self.gen.next()\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 226, in decorated_function\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? return function(self, context, *args, **kwargs)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 2057, in reserve_block_device_name\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? return do_reserve()\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/utils.py\", line 733, in inner\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? retval = f(*args, **kwargs)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/manager.py\", line 2051, in do_reserve\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? device)\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? File \"/usr/local/nova/nova/compute/utils.py\", line 56, in get_device_name_for_instance\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp ? ? raise exception.InvalidDevicePath(path=mappings[\'root\'])\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp InvalidDevicePath: The supplied device path (/dev/a) is invalid.\n2012-09-04 13:37:46 TRACE nova.openstack.common.rpc.amqp\n2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.common [-] Returning exception The supplied device path (/dev/a) is invalid. to caller\n2012-09-04 13:37:46 ERROR nova.openstack.common.rpc.common [-] [\'Traceback (most recent call last):\\n\', \' ?File \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in _process_data\\n ? ?rval = self.proxy.dispatch(ctxt, version, method, **args)\\n\', \' ?File \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145, in dispatch\\n ? ?return getattr(proxyobj, method)(ctxt, **kwargs)\\n\', \' ?File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\\n ? ?temp_level, payload)\\n\', \' ?File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n ? ?self.gen.next()\\n\', \' ?File \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\\n ? ?return f(*args, **kw)\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 211, in decorated_function\\n ? ?pass\\n\', \' ?File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n ? ?self.gen.next()\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 204, in decorated_function\\n ? ?return function(self, context, *args, **kwargs)\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 237, in decorated_function\\n ? ?instance_uuid, e, sys.exc_info())\\n\', \' ?File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\\n ? ?self.gen.next()\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 226, in decorated_function\\n ? ?return function(self, context, *args, **kwargs)\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 2057, in reserve_block_device_name\\n ? ?return do_reserve()\\n\', \' ?File \"/usr/local/nova/nova/utils.py\", line 733, in inner\\n ? ?retval = f(*args, **kwargs)\\n\', \' ?File \"/usr/local/nova/nova/compute/manager.py\", line 2051, in do_reserve\\n ? ?device)\\n\', \' ?File \"/usr/local/nova/nova/compute/utils.py\", line 56, in get_device_name_for_instance\\n ? ?raise exception.InvalidDevicePath(path=mappings[\\\'root\\\'])\\n\', \'InvalidDevicePath: The supplied device path (/dev/a) is invalid.\\n\']\n\n\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n','<470496884.881792.1346780503704.JavaMail.root@zm.isi.edu>',NULL),('<1446014331.6.1384930592889.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-20 06:56:32',0,'2013-11-20 06:56:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-havana #1','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-havana/1/>\n\n------------------------------------------\n[...truncated 21242 lines...]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_create_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_delete_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_get_object[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke]\ntempest.api.object_storage.test_object_services.ObjectTest.test_object_metadata[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_container_object_without_using_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_network_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_ports_until_quota_hit[network] ... ok\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network]\ntempest.scenario.test_network_quotas.TestNetworkQuotaBasic.test_create_subnet_until_quota_hit[network] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... FAIL\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\n\nprocess-returncode\nprocess-returncode ... FAIL\n\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-11-20 06:44:19,178 Starting new HTTP connection (1): 127.0.0.1\n2013-11-20 06:44:19,278 Starting new HTTP connection (1): 127.0.0.1\n2013-11-20 06:44:51,710 Connected (version 2.0, client dropbear_2012.55)\n2013-11-20 06:44:51,929 Authentication (publickey) successful!\n2013-11-20 06:44:52,106 Connected (version 2.0, client dropbear_2012.55)\n2013-11-20 06:44:52,304 Authentication (publickey) successful!\n2013-11-20 06:44:52,307 Secsh channel 1 opened.\n2013-11-20 06:44:52,484 Connected (version 2.0, client dropbear_2012.55)\n2013-11-20 06:44:52,674 Authentication (publickey) successful!\n2013-11-20 06:44:52,677 Secsh channel 1 opened.\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 83, in test_snapshot_pattern\n    server_from_snapshot = self._boot_image(snapshot_image.id)\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 37, in _boot_image\n    return self.create_server(image=image_id, create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 403, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 295, in status_timeout\n    not_found_exception=not_found_exception)\n  File \"tempest/scenario/manager.py\", line 352, in _status_timeout\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Timed out waiting for thing f20d5d87-4f5c-4700-89cb-ce4322439225                       to become ACTIVE\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 248 tests in 1435.211s\n\nFAILED (failures=2, skipped=9)\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                 441.557\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  171.942\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          112.043\ntempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops[compute,gate,network,smoke]           33.373\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]             20.287\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                          16.955\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]                      13.043\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]               12.328\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]                            9.690\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]      9.359\nERROR: InvocationError: \'/bin/sh tools/pretty_tox_serial.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])((smoke)|(^tempest\\\\.scenario)) \'\n___________________________________ summary ____________________________________\nERROR:   smoke-serial: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-692278-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-692278.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-lbaas.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-q-vpn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/neutron-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-havana/devstack-precise-hpcloud-az1-692278/1/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1446091.PBAkd8tyBk@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-28 10:55:37',39600,'2014-10-27 23:55:37',NULL,'[openstack-dev] [Neutron][LBaaS][Octavia] Usage Requirements','On Wed, 22 Oct 2014 11:29:27 AM Robert van Leeuwen wrote:\n> > I,d like to start a conversation on usage requirements and have a few\n> > suggestions. I advocate that, since we will be using TCP and HTTP/HTTPS\n> > based protocols, we inherently enable connection logging for load\n> \n> > balancers for several reasons:\n> Just request from the operator side of things:\n> Please think about the scalability when storing all logs.\n> \n> e.g. we are currently logging http requests to one load balanced application\n> (that would be a fit for LBAAS) It is about 500 requests per second, which\n> adds up to 40GB per day (in elasticsearch.) Please make sure whatever\n> solution is chosen it can cope with machines doing 1000s of requests per\n> second...\n\nAnd to take this further, what happens during DoS attack (either syn flood or \nfull connections)?  How do we ensure that we don\'t lose our logging system \nand/or amplify the DoS attack?\n\nOne solution is sampling, with a tunable knob for the sampling rate - perhaps \ntunable per-vip.  This still increases linearly with attack traffic, unless you \nuse time-based sampling (1-every-N-seconds rather than 1-every-N-packets).\n\nOne of the advantages of (eg) polling the number of current sessions is that \nthe cost of that monitoring is essentially fixed regardless of the number of \nconnections passing through.  Numerous other metrics (rate of new connections, \netc) also have this property and could presumably be used for accurate billing \n- without amplifying attacks.\n\nI think we should be careful about whether we want logging or metrics for more \naccurate billing.  Both are useful, but full logging is only really required \nfor ad-hoc debugging (important! but different).\n\n-- \n - Gus\n\n\n','<79E00D9220302D448C1D59B5224ED12D8DB5A234@EchoDB02.spil.local>',NULL),('<1446372814.15872310.1389307610723.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 17:46:50',-18000,'2014-01-09 22:46:50',NULL,'[openstack-dev] [TripleO][Tuskar] Domain Model Locations','\n\n----- Original Message -----\n> On Thu, 2014-01-09 at 16:02 -0500, Tzu-Mainn Chen wrote:> There are a\n> number of other models in the tuskar code[1], do we need to\n> > > consider these now too?\n> > > \n> > > [1]:\n> > > https://github.com/openstack/tuskar/blob/master/tuskar/db/sqlalchemy/models.py\n> > \n> > Nope, these are gone now, in favor of Tuskar interacting directly with\n> > Ironic, Heat, etc.\n> \n> Hmm, not quite.\n> \n> If compare the models in Ironic [1] to Tuskar\'s (link above), there are\n> some dramatic differences. Notably:\n> \n> * No Rack model in Ironic. Closest model seems to be the Chassis model\n> [2], but the Ironic Chassis model doesn\'t have nearly the entity\n> specificity that Tuskar\'s Rack model has. For example, the following\n> (important) attributes are missing from Ironic\'s Chassis model:\n>  - slots (how does Ironic know how many RU are in a chassis?)\n>  - location (very important for integration with operations inventory\n> management systems, trust me)\n>  - subnet (based on my experience, I\'ve seen deployers use a\n> rack-by-rack or paired-rack control and data plane network static IP\n> assignment. While Tuskar\'s single subnet attribute is not really\n> adequate for describing production deployments that typically have 3+\n> management, data and overlay network routing rules for each rack, at\n> least Tuskar has the concept of networking rules in its Rack model,\n> while Ironic does not)\n>  - state (how does Ironic know whether a rack is provisioned fully or\n> not? Must it query each each Node\'s powr_state field that has a\n> chassis_id matching the Chassis\' id field?)\n>  -\n> * The Tuskar Rack model has a field \"chassis_id\". I have no idea what\n> this is... or its relation to the Ironic Chassis model.\n> \n> As much as the Tuskar Chassis model is lacking compared to the Tuskar\n> Rack model, the opposite problem exists for each project\'s model of\n> Node. In Tuskar, the Node model is pretty bare and useless, whereas\n> Ironic\'s Node model is much richer.\n> \n> So, it\'s not as simple as it may initially seem :)\n\nAh, I should have been clearer in my statement - my understanding is that\nwe\'re scrapping concepts like Rack entirely.\n\nMainn\n\n> Best,\n> -jay\n> \n> [1]\n> https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py\n> [2]\n> https://github.com/openstack/ironic/blob/master/ironic/db/sqlalchemy/models.py#L83\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1389303734.23412.24.camel@cranky>',NULL),('<1446929572.439.1359528723135.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-30 06:52:02',0,'2013-01-30 06:52:02',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #83','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/83/>\n\n------------------------------------------\n[...truncated 16155 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:18 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-38037ae7-9937-4498-8c76-b0f09a334ce2\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/d7284ea4-26b8-48c9-bb23-8c0e511c35e6\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:18 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-1ce8234b-48e0-4a75-8935-ee51c420e1e5\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/64635c8b-15ce-4c3d-a47d-eebc52d0bc0c\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:19 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-3978009c-fab4-4e0f-9aba-272ff2ff6b19\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/6a78bd1b-8ffe-4fa2-9ad0-6646e3fcf192\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:19 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-189981fe-d928-4d37-b4a0-3caed6e70654\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/7b8bf765-e961-4f94-a0cf-b24f1e787caa\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:20 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-073ecaeb-cfe0-4932-bb0b-611d48b087d2\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/6e28426a-c79a-4543-8cad-1bd88bde754f\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:21 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-15941cef-edb1-418b-84b0-013070616f2b\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/55ecad61-5dcf-49f4-9dd5-9269910de759\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:21 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-82d855ef-2723-4e9c-a1a6-0575b62e4f56\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/5e256aa3-51ba-4e66-a897-13d3a4214247\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:22 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-63f08198-4ccb-46c3-9e99-e5b191c459e4\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/9d022985-ca8f-4a48-9205-b87d1accfdd0\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:22 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-e77ff11a-58e0-4076-a2c7-976fbfb925bc\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0zMFQwNjo0OTowOC4wNTkxNzUiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTMxVDA2OjQ5OjA4WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzk3ZWUyOTY1MzBmNDY1NDk2YWM5NTY3MDdmMGRhNTIiLCAiaWQiOiAiMDFjMzBlM2Y3Yzc1NGMxOWE3MmZmMjE0NmNiNjVkMmQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3YjM2YzFmOTZkNjU0YzNhYTQ1MjM4MjkwYzE4Zjk5OSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiYTEzYzEzZWNkNWEyNDM1YjllYzc3NjlkNDY3ZGQ2N2MiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiIsICJpZCI6ICJmNGRhZDc4MzJjOTA0MTNjYTEwZTRhYWZlZGE4MGNlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxMTI5ZDk0OTZkNmI0YTgyYjQwODVlOTI3MDRjOGJlYiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM5N2VlMjk2NTMwZjQ2NTQ5NmFjOTU2NzA3ZjBkYTUyIiwgImlkIjogImU5M2EwZGU2OWJjNDQ3YjM4OGU2ZWMyZDA5NmUzMTA1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOTdlZTI5NjUzMGY0NjU0OTZhYzk1NjcwN2YwZGE1MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjQxNWVlNjAwZmMwMzQ2MzFhYTg5ZWQzM2YyNjA5YmY0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNmEwYmYyODNlYzkyNDg5OTlmN2MyYjY4MmQyMjIwZmQiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOGU0YTE5MmI4NjhjNDU0Nzk3YjM2MjFiZmI0ZmFlMjEiLCAiMjdiZTA4ZDk3M2IxNGRmMWEyOTJiNjIzZWFmMTJiYTEiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCaGu1jtlM0AiT1RvsS7luisSUsLH6kePrugUHOLFwjEBVZ6z7bzUFjqIB8dt2FiM7Tctc1Oo3zU4sNLZUX1+aO5kJq22Mx-7H7-6cR9ErFCXUsla236sOzvyLMDC72xD+sUN5wYya3238AVE16JOIc9Vg6085DhB4d7VFa95Wmgg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/821a50a4-8a96-45a8-bfa2-fff9e39550e7\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 30 Jan 2013 06:49:23 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-87bdba42-fa4f-4153-9fab-32c884119967\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntempest.tests.object_storage.test_account_services.AccountTest.test_list_containers_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization ... SKIP: Until Bug 1093743 is resolved.\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_invalid_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_none_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_no_body ... SKIP: Until bug 1090320 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... SKIP: Until bug 1090322 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... SKIP: Until bug 1090320 is fixed\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_create_with_empty_name ... SKIP: Until bug 1090356 is fixed\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... SKIP: Until bug 1090356 is fixed\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestJSON.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\n\n======================================================================\nERROR: tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestJSON.test_associate_ip_to_server_without_passing_floating_ip\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/floating_ips_client.py\", line 73, in associate_floating_ip_to_server\n    resp, body = self.post(url, post_body, self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n\n-------------------- >> begin captured logging << --------------------\ntempest.tests.compute: DEBUG: Entering tempest.tests.compute.setup_package\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/dec312965e0645229633d96da8140514/servers/3f1d5020-c2a3-4f5b-bea3-8f34eae22481/action\ntempest.common.rest_client: ERROR: Request Body: {\"addFloatingIp\": {\"address\": \"\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Wed, 30 Jan 2013 06:25:02 GMT\', \'status\': \'400\', \'content-length\': \'82\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-ed57f2aa-a32a-44ef-b456-dcebb4884d36\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'badRequest\': {u\'message\': u\'Error. Unable to associate floating ip\', u\'code\': 400}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: tempest.tests.compute.floating_ips.test_floating_ips_actions.FloatingIPsTestXML.test_associate_ip_to_server_without_passing_floating_ip\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/floating_ips/test_floating_ips_actions.py\", line 200, in test_associate_ip_to_server_without_passing_floating_ip\n    self.server_id)\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/floating_ips_client.py\", line 83, in associate_floating_ip_to_server\n    resp, body = self.post(url, str(doc), self.headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 262, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n\n-------------------- >> begin captured logging << --------------------\ntempest.tests.compute: DEBUG: Entering tempest.tests.compute.setup_package\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/85ff0d85af47408f8727732ecadb13bc/servers/da0b9c8f-bb55-4341-b742-ea68138b7322/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<addFloatingIp address=\"\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Wed, 30 Jan 2013 06:25:42 GMT\', \'status\': \'400\', \'content-length\': \'144\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-4776fe4e-ae7b-42cd-b3bc-fd41703dc30a\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'Error. Unable to associate floating ip\', \'code\': \'400\'}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 566 tests in 1611.254s\n\nFAILED (SKIP=75, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/rabbitmq/rabbit at devstack-1359511317-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/rabbitmq/rabbit at devstack-1359511317.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/83/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<374058474.425.1359441538271.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1447118607.41.1378447688388.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-06 06:08:08',0,'2013-09-06 06:08:08',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #15','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/15/>\n\n------------------------------------------\n[...truncated 17420 lines...]\n2013-09-06 06:07:31 # This section contains the configuration options used when executing tests\n2013-09-06 06:07:31 # against the OpenStack Block Storage API service\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-06 06:07:31 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-06 06:07:31 # probably want to leave this value as \"volume\"\n2013-09-06 06:07:31 catalog_type = volume\n2013-09-06 06:07:31 # Number of seconds to wait while looping to check the status of a\n2013-09-06 06:07:31 # volume that is being made available\n2013-09-06 06:07:31 build_interval = 1\n2013-09-06 06:07:31 # Number of seconds to time out on waiting for a volume\n2013-09-06 06:07:31 # to be available or reach an expected status\n2013-09-06 06:07:31 build_timeout = 400\n2013-09-06 06:07:31 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-06 06:07:31 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-06 06:07:31 # have to be different)\n2013-09-06 06:07:31 multi_backend_enabled = false\n2013-09-06 06:07:31 backend1_name = BACKEND_1\n2013-09-06 06:07:31 backend2_name = BACKEND_2\n2013-09-06 06:07:31 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-06 06:07:31 # You should update to reflect those exported by configured backend driver.\n2013-09-06 06:07:31 storage_protocol = iSCSI\n2013-09-06 06:07:31 vendor_name = Open Source\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 [object-storage]\n2013-09-06 06:07:31 # This section contains configuration options used when executing tests\n2013-09-06 06:07:31 # against the OpenStack Object Storage API.\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # You can configure the credentials in the compute section\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-06 06:07:31 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-06 06:07:31 # this value as \"object-store\"\n2013-09-06 06:07:31 catalog_type = object-store\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Number of seconds to time on waiting for a container to container\n2013-09-06 06:07:31 # synchronization complete\n2013-09-06 06:07:31 container_sync_timeout = 120\n2013-09-06 06:07:31 # Number of seconds to wait while looping to check the status of a\n2013-09-06 06:07:31 # container to container synchronization\n2013-09-06 06:07:31 container_sync_interval = 5\n2013-09-06 06:07:31 # Set to True if the Account Quota middleware is enabled\n2013-09-06 06:07:31 accounts_quotas_available = True\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Set operator role for tests that require creating a container\n2013-09-06 06:07:31 operator_role = Member\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 [boto]\n2013-09-06 06:07:31 ssh_user = cirros\n2013-09-06 06:07:31 # This section contains configuration options used when executing tests\n2013-09-06 06:07:31 # with boto.\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # EC2 URL\n2013-09-06 06:07:31 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-06 06:07:31 # S3 URL\n2013-09-06 06:07:31 s3_url = http://127.0.0.1:3333\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-06 06:07:31 aws_access =\n2013-09-06 06:07:31 aws_secret =\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Image materials for S3 upload\n2013-09-06 06:07:31 # ALL content of the specified directory will be uploaded to S3\n2013-09-06 06:07:31 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-06 06:07:31 # Subdirectories not allowed!\n2013-09-06 06:07:31 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-06 06:07:31 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-06 06:07:31 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-06 06:07:31 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Instance type\n2013-09-06 06:07:31 instance_type = m1.nano\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # TCP/IP connection timeout\n2013-09-06 06:07:31 http_socket_timeout = 30\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Number of retries actions on connection or 5xx error\n2013-09-06 06:07:31 num_retries = 1\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Status change wait timout\n2013-09-06 06:07:31 build_timeout = 400\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Status change wait interval\n2013-09-06 06:07:31 build_interval = 1\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 [orchestration]\n2013-09-06 06:07:31 # Status change wait interval\n2013-09-06 06:07:31 build_interval = 1\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Status change wait timout. This may vary across environments as some some\n2013-09-06 06:07:31 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-06 06:07:31 build_timeout = 300\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Instance type for tests. Needs to be big enough for a\n2013-09-06 06:07:31 # full OS plus the test workload\n2013-09-06 06:07:31 instance_type = m1.micro\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-06 06:07:31 # If not specified, tests that spawn instances will not run\n2013-09-06 06:07:31 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-06 06:07:31 # any key, which will generate a keypair for each test class\n2013-09-06 06:07:31 #keypair_name = heat_key\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 [dashboard]\n2013-09-06 06:07:31 # URL where to find the dashboard home page\n2013-09-06 06:07:31 dashboard_url = http://127.0.0.1/\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # URL where to submit the login form\n2013-09-06 06:07:31 login_url = http://127.0.0.1/auth/login/\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 [scenario]\n2013-09-06 06:07:31 # Directory containing image files\n2013-09-06 06:07:31 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # AMI image file name\n2013-09-06 06:07:31 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # ARI image file name\n2013-09-06 06:07:31 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-06 06:07:31 \n2013-09-06 06:07:31 # AKI image file name\n2013-09-06 06:07:32 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-06 06:07:32 \n2013-09-06 06:07:32 # ssh username for the image file\n2013-09-06 06:07:32 ssh_user = cirros\n2013-09-06 06:07:32 \n2013-09-06 06:07:32 # specifies how many resources to request at once. Used for large operations\n2013-09-06 06:07:32 # testing.\"\n2013-09-06 06:07:32 large_ops_number = 0\n2013-09-06 06:07:32 \n2013-09-06 06:07:32 [cli]\n2013-09-06 06:07:32 # Enable cli tests\n2013-09-06 06:07:32 enabled = True\n2013-09-06 06:07:32 # directory where python client binaries are located\n2013-09-06 06:07:32 cli_dir = /usr/local/bin\n2013-09-06 06:07:32 # Number of seconds to wait on a CLI timeout\n2013-09-06 06:07:32 timeout = 15\n2013-09-06 06:07:32 \n2013-09-06 06:07:32 [service_available]\n2013-09-06 06:07:32 # Whether or not cinder is expected to be available\n2013-09-06 06:07:32 cinder = True\n2013-09-06 06:07:32 # Whether or not neutron is expected to be available\n2013-09-06 06:07:32 neutron = False\n2013-09-06 06:07:32 # Whether or not glance is expected to be available\n2013-09-06 06:07:32 glance = True\n2013-09-06 06:07:32 # Whether or not swift is expected to be available\n2013-09-06 06:07:32 swift = True\n2013-09-06 06:07:32 # Whether or not nova is expected to be available\n2013-09-06 06:07:32 nova = True\n2013-09-06 06:07:32 # Whether or not Heat is expected to be available\n2013-09-06 06:07:32 heat = True\n2013-09-06 06:07:32 # Whether or not horizon is expected to be available\n2013-09-06 06:07:32 horizon = True\n2013-09-06 06:07:32 \n2013-09-06 06:07:32 [stress]\n2013-09-06 06:07:32 # Maximum number of instances to create during test\n2013-09-06 06:07:32 max_instances = 32\n2013-09-06 06:07:32 # Time (in seconds) between log file error checks\n2013-09-06 06:07:32 log_check_interval = 60\n2013-09-06 06:07:32 # The default number of threads created while stress test\n2013-09-06 06:07:32 default_thread_number_per_action=4\n2013-09-06 06:07:32 ++ IFS=\' 	\n2013-09-06 06:07:32 \'\n2013-09-06 06:07:32 ++ set +o errexit\n2013-09-06 06:07:32 ++ init_tempest\n2013-09-06 06:07:32 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-06 06:07:32 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-06 06:07:32 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-06 06:07:32 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-06 06:07:32 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1698.g22942ba.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-225295-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-225295.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-225295/15/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1103078338.21.1378188497768.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1447189278.108626.1394709856887.JavaMail.zimbra@ct.infn.it>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 12:24:16',3600,'2014-03-13 11:24:16',NULL,'[openstack-dev] [swift] Replication multi cloud','Hi all,\n\nwe would use the replication mechanism in swift to replicate the data\nin two swift instances deployed in different clouds with different keystones\nand administrative domains.\n\nIs this possible with the current replication facilities or they should\nstay in the same cloud sharing the keystone?\n\nCheers,\nMarco\n\n\n\n-- \n====================================================\nEng. Marco Fargetta, PhD\n\nIstituto Nazionale di Fisica Nucleare (INFN)\nCatania, Italy\n\nEMail: Marco.Fargetta at ct.infn.it\n====================================================\n\n\n','<638224523.108610.1394709670940.JavaMail.zimbra@ct.infn.it>',NULL),('<1447875689.2651789.1390418028041.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 20:13:48',3600,'2014-01-22 19:13:48',NULL,'[openstack-dev] [ceilometer] per domain/project/user limits on\n	alarms','Greetings,\n\nI\'d be interested in some opinions and feedback on the following blueprint: https://blueprints.launchpad.net/ceilometer/+spec/quotas-on-alarms\n\nI think it\'d be interesting to allow admins to limit the number of running alarms at any of the three levels defined by keystone. Thoughts ?\n\nThanks,\n\nMatthieu Huin \n\nmhu at enovance.com \nhttp://www.enovance.com \neNovance SaS - 10 rue de la Victoire 75009 Paris - France \n\n\n\n','<543856763.2651578.1390417862981.JavaMail.root@enovance.com>',NULL),('<1447888971.116.1384495612787.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-15 06:06:52',0,'2013-11-15 06:06:52',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #41','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/41/>\n\n------------------------------------------\n[...truncated 15245 lines...]\n2013-11-15 06:06:19 bin_dir = /opt/stack/new/nova/bin\n2013-11-15 06:06:19 \n\n\n\nHorizon is now available at http://127.0.0.1/\nKeystone is serving at http://127.0.0.1:5000/v2.0/\nExamples on using novaclient command line is in exercise.sh\nThe default users are: admin and demo\nThe password: secret\nThis is your host ip: 10.5.134.235\n2013-11-15 06:06:19 # Connection string to the database of Compute service\nRemoving sudo privileges for devstack user\n2013-11-15 06:06:19 db_uri = mysql://root:secret at localhost/nova\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Path to a private key file for SSH access to remote hosts\n2013-11-15 06:06:19 path_to_private_key = /opt/stack/new/tempest/id_rsa\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [compute-admin]\n2013-11-15 06:06:19 # This should be the username of a user WITH administrative privileges\n2013-11-15 06:06:19 # If not defined the admin user from the identity section will be used\n2013-11-15 06:06:19 username =\n2013-11-15 06:06:19 # The above administrative user\'s password\n2013-11-15 06:06:19 password =secret\nRunning tempest smoke tests\n2013-11-15 06:06:19 # The above administrative user\'s tenant name\n2013-11-15 06:06:19 tenant_name =\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [image]\n2013-11-15 06:06:19 # This section contains configuration options used when executing tests\n2013-11-15 06:06:19 # against the OpenStack Images API\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The type of endpoint for an Image API service. Unless you have a\n2013-11-15 06:06:19 # custom Keystone service catalog implementation, you probably want to leave\n2013-11-15 06:06:19 # this value as \"image\"\n2013-11-15 06:06:19 catalog_type = image\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The version of the OpenStack Images API to use\n2013-11-15 06:06:19 api_version = 1\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [network]\n2013-11-15 06:06:19 # This section contains configuration options used when executing tests\n2013-11-15 06:06:19 # against the OpenStack Network API.\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Version of the Quantum API\n2013-11-15 06:06:19 api_version = 2.0\n2013-11-15 06:06:19 # Catalog type of the Quantum Service\n2013-11-15 06:06:19 catalog_type = network\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # A large private cidr block from which to allocate smaller blocks for\n2013-11-15 06:06:19 # tenant networks.\n2013-11-15 06:06:19 tenant_network_cidr = 10.100.0.0/16\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The mask bits used to partition the tenant block.\n2013-11-15 06:06:19 tenant_network_mask_bits = 29\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # If tenant networks are reachable, connectivity checks will be\n2013-11-15 06:06:19 # performed directly against addresses on those networks.\n2013-11-15 06:06:19 tenant_networks_reachable = false\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Id of the public network that provides external connectivity.\n2013-11-15 06:06:19 public_network_id = 04db7e63-e385-4e0b-8d2a-fb37e474d16d\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Id of a shared public router that provides external connectivity.\n2013-11-15 06:06:19 # A shared public router would commonly be used where IP namespaces\n2013-11-15 06:06:19 # were disabled.  If namespaces are enabled, it would be preferable\n2013-11-15 06:06:19 # for each tenant to have their own router.\n2013-11-15 06:06:19 public_router_id = \n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Whether or not quantum is expected to be available\n2013-11-15 06:06:19 quantum_available = True\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [volume]\n2013-11-15 06:06:19 # This section contains the configuration options used when executing tests\n2013-11-15 06:06:19 # against the OpenStack Block Storage API service\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The type of endpoint for a Cinder or Block Storage API service.\n2013-11-15 06:06:19 # Unless you have a custom Keystone service catalog implementation, you\n2013-11-15 06:06:19 # probably want to leave this value as \"volume\"\n2013-11-15 06:06:19 catalog_type = volume\n2013-11-15 06:06:19 # Number of seconds to wait while looping to check the status of a\n2013-11-15 06:06:19 # volume that is being made available\n2013-11-15 06:06:19 build_interval = 3\n2013-11-15 06:06:19 # Number of seconds to time out on waiting for a volume\n2013-11-15 06:06:19 # to be available or reach an expected status\n2013-11-15 06:06:19 build_timeout = 400\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [object-storage]\n2013-11-15 06:06:19 # This section contains configuration options used when executing tests\n2013-11-15 06:06:19 # against the OpenStack Object Storage API.\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # You can configure the credentials in the compute section\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-11-15 06:06:19 # custom Keystone service catalog implementation, you probably want to leave\n2013-11-15 06:06:19 # this value as \"object-store\"\n2013-11-15 06:06:19 catalog_type = object-store\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Number of seconds to time on waiting for a container to container\n2013-11-15 06:06:19 # synchronization complete\n2013-11-15 06:06:19 container_sync_timeout = 120\n2013-11-15 06:06:19 # Number of seconds to wait while looping to check the status of a\n2013-11-15 06:06:19 # container to container synchronization\n2013-11-15 06:06:19 container_sync_interval = 5\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 [boto]\n2013-11-15 06:06:19 ssh_user = cirros\n2013-11-15 06:06:19 # This section contains configuration options used when executing tests\n2013-11-15 06:06:19 # with boto.\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # EC2 URL\n2013-11-15 06:06:19 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-11-15 06:06:19 # S3 URL\n2013-11-15 06:06:19 s3_url = http://127.0.0.1:3333\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-11-15 06:06:19 aws_access =\n2013-11-15 06:06:19 aws_secret =\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #Image materials for S3 upload\n2013-11-15 06:06:19 # ALL content of the specified directory will be uploaded to S3\n2013-11-15 06:06:19 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\nERROR: unknown environment \'smoke-serial\'\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # The manifest.xml files, must be in the s3_materials_path directory\n2013-11-15 06:06:19 # Subdirectories not allowed!\n2013-11-15 06:06:19 # The filenames will be used as a Keys in the S3 Buckets\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-11-15 06:06:19 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-11-15 06:06:19 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-11-15 06:06:19 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #Instance type\n2013-11-15 06:06:19 instance_type = m1.nano\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #TCP/IP connection timeout\n2013-11-15 06:06:19 http_socket_timeout = 30\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 #Number of retries actions on connection or 5xx error\n2013-11-15 06:06:19 num_retries = 1\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Status change wait timout\n2013-11-15 06:06:19 build_timeout = 400\n2013-11-15 06:06:19 \n2013-11-15 06:06:19 # Status change wait interval\n2013-11-15 06:06:19 build_interval = 3\n2013-11-15 06:06:19 ++ IFS=\' 	\n2013-11-15 06:06:19 \'\n2013-11-15 06:06:19 ++ set +o errexit\n2013-11-15 06:06:19 ++ init_tempest\n2013-11-15 06:06:19 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-11-15 06:06:19 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-11-15 06:06:19 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-11-15 06:06:19 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-11-15 06:06:19 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-11-15 06:06:19 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-11-15 06:06:19 ++ echo \'Prepare aki/ari/ami Images\'\n2013-11-15 06:06:19 Prepare aki/ari/ami Images\n2013-11-15 06:06:20 ++ cat\n2013-11-15 06:06:20 ++ source /opt/stack/new/devstack/accrc/demo/demo\n2013-11-15 06:06:20 +++ export EC2_ACCESS_KEY=4c5dc5f5ba71464691fab5e250613673\n2013-11-15 06:06:20 +++ EC2_ACCESS_KEY=4c5dc5f5ba71464691fab5e250613673\n2013-11-15 06:06:20 +++ export EC2_SECRET_KEY=9bc4812b6d4c4d598b8cb74f416d2acd\n2013-11-15 06:06:20 +++ EC2_SECRET_KEY=9bc4812b6d4c4d598b8cb74f416d2acd\n2013-11-15 06:06:20 +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-11-15 06:06:20 +++ EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-11-15 06:06:20 +++ export S3_URL=http://127.0.0.1:3333\n2013-11-15 06:06:20 +++ S3_URL=http://127.0.0.1:3333\n2013-11-15 06:06:20 +++ export OS_USERNAME=demo\n2013-11-15 06:06:20 +++ OS_USERNAME=demo\n2013-11-15 06:06:20 +++ export OS_TENANT_NAME=demo\n2013-11-15 06:06:20 +++ OS_TENANT_NAME=demo\n2013-11-15 06:06:20 +++ export OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-11-15 06:06:20 +++ OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-11-15 06:06:20 +++ export EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-11-15 06:06:20 +++ EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-11-15 06:06:20 +++ export EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-11-15 06:06:20 +++ EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-11-15 06:06:20 +++ export EC2_USER_ID=42\n2013-11-15 06:06:20 +++ EC2_USER_ID=42\n2013-11-15 06:06:20 +++ export EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-15 06:06:20 +++ EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-11-15 06:06:20 +++ export NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-659597-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-659597.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-q-l3.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az1-659597/41/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<14488bba210.27ad.6c47a7e13dc6dbbaf5b2f145b8976162@openstack.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 10:16:43',-21600,'2014-03-03 16:16:43',NULL,'[openstack-dev] [OpenStack-Dev] [Cinder] Open Source and\n	community working together','+1\n\nSent with AquaMail for Android\nhttp://www.aqua-mail.com\n\n\nOn March 3, 2014 10:12:43 AM Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On Sat, 2014-03-01 at 16:30 -0700, John Griffith wrote:\n> > Hey,\n> > I just wanted to send out a quick note on a topic that came up\n> > recently.  Unfortunately the folks that I\'d like to read this most;\n> > don\'t participate on the ML typically, but I\'d at least like to raise\n> > some community awareness.\n> > We all know OpenStack is growing at a rapid pace and has a lot of\n> > promise, so much so that there\'s an enormous field of vendors and OS\n> > distributions that are focusing a lot of effort and marketing on the\n> > project.\n> > Something that came up recently in the Cinder project is that one of\n> > the backend device vendors wasn\'t happy with a feature that somebody\n> > was working on and contributed a patch for.  Instead of providing a\n> > meaningful review and suggesting alternatives to the patch they set up\n> > meetings with other vendors leaving the active members of the\n> > community out and picked things apart in their own format out of the\n> > public view.  Nobody from the core Cinder team was involved in these\n> > discussions or meetings (at least that I\'ve been made aware of).\n> > I don\'t want to go into detail about who, what, where etc at this\n> > point.  I instead, I want to point out that in my opinion this is no\n> > way to operate in an Open Source community.  Collaboration is one\n> > thing, but ambushing other peoples work is entirely unacceptable in my\n> > opinion.  OpenStack provides a plethora of ways to participate and\n> > voice your opinion, whether it be this mailing list, the IRC channels\n> > which are monitored daily and also host a published weekly meeting for\n> > most projects.  Of course when in doubt you\'re welcome to send me an\n> > email at any time with questions or concerns that you have about a\n> > patch.  In any case however the proper way to address concerns about a\n> > submitted patch is to provide a review for that patch.\n> > Everybody has a voice and the ability to participate, and the most\n> > effective way to do that is by thorough, timely and constructive code\n> > reviews.\n> > I\'d also like to point out that while a number of companies and\n> > vendors have fancy taglines like \"The Leaders of OpenStack\", they\'re\n> > not.  OpenStack is a community effort, as of right now there is no\n> > company that leads or runs OpenStack.  If you have issues or concerns\n> > on the development side you need to take those up with the development\n> > community, not vendor xyz.\n>\n> +100\n>\n> And another +1 for use of the word plethora.\n>\n> I will point out -- not knowing who these actors were -- that sometimes\n> it is tough for some folks to adapt to open community methodologies and\n> open discussions. Some people simply don\'t know any other way of\n> resolving differences other than to work in private or develop what they\n> consider to be \"consensus\" between favored parties in order to drive\n> \"change by bullying\". We must, as a community, both make it clear\n> (through posts such as this) that this behavior is antithetical to how\n> the OpenStack community functions, and also provide these individuals\n> with as much assistance as possible in changing their long-practiced\n> habits. Some stick. Some carrot.\n>\n> Best,\n> -jay\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<1393862967.2742.12.camel@sleepy>',NULL),('<1448945548.11.1382854153566.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-27 06:09:13',0,'2013-10-27 06:09:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #45','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/45/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46a9fd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46a9fd0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e34090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e34090>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-550a6555-f744-4d2d-9112-c51f4e485ee6\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:08:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:08:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:08:47+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'47\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:08:47-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'47\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:08:47Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'47\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'47\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bc1790>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22296d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 66.67 secs:\n    13.94    TestGlanceControl.test_bouncing\n    13.73    TestScrubber.test_delayed_delete\n    13.44    TestGlanceControl.test_reload\n    13.25    TestGlanceControl.test_respawn\n    12.31    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 483.314s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-45\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.JUYNuZWl9x\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/45\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/45/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/45\n[SCP] Copying console log.\n\n\n','<762244496.10.1382767925600.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1449094673.7477989.1362680270142.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 13:17:50',-18000,'2013-03-07 18:17:50',NULL,'[openstack-dev] [Nova] Proposal to add Andrew Laski to nova-core','+1\n\n----- Original Message -----\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, March 6, 2013 2:31:03 PM\n> Subject: [openstack-dev] [Nova] Proposal to add Andrew Laski to nova-core\n> \n> Greetings,\n> \n> I would like to propose adding Andrew Laski (alaski) to the nova-core\n> team.\n> \n>     https://review.openstack.org/#/dashboard/5441\n> \n> Andrew has been quite active lately helping out with reviews and\n> contributing to Nova.  He also implemented the instance-actions\n> blueprint for Grizzly.\n> \n>     https://blueprints.launchpad.net/nova/+spec/instance-actions\n> \n> Please respond with comments, +1s, or objections within one week.\n> \n> Thanks,\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51379977.9090806@redhat.com>',NULL),('<1449321682.42.1352937978064.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-15 00:06:17',0,'2012-11-15 00:06:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-diablo #93','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/93/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/>\nCheckout:periodic-horizon-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/> - hudson.remoting.Channel at 2933c2d2:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson2555820881411612487.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-diablo/93\n[SCP] Copying console log.\n\n\n','<1217373149.14.1352851558681.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1449680848.14856148.1383242394417.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-31 13:59:54',-14400,'2013-10-31 17:59:54',NULL,'[Openstack-docs] Integrating Ask OpenStack in docs','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> To: \"David Cramer\" <david.cramer at rackspace.com>\n> Cc: \"openstack-docs at lists.openstack.org\" <Openstack-docs at lists.openstack.org>, \"Evgeny Fadeev\"\n> <evgeny.fadeev at gmail.com>\n> Sent: Thursday, October 31, 2013 12:53:13 PM\n> Subject: Re: [Openstack-docs] Integrating Ask OpenStack in docs\n> \n> Yes, these and other down sides:\n> \n> Disqus is proprietary software.\n> Disqus terms of service definitely spook off open source contributors who\n> tend to have a higher concern around data sharing, ads. [1]\n> Disqus automatically changed settings last year to monetization settings\n> which I had to manually change for each site ID.\n> Disqus RSS feed is no longer available without a login.\n\nI can answer a few of these based on my use of the site:\n\n> I do have implementation requests for the replacement.\n> - Can you embed code snippets?\n\nYes, using markdown (indent four spaces or surround in tildas, there is also a button on the WYSIWYG editor).\n\n> - Does it provide spam/robot protection?\n> - Can we \"bulk close\" or expire threads that are opened at a specific point\n> in time? For example, closing all moderation and asking on the Diablo or\n> Folsom releases.\n\nIs there a particular driver for wanting to do this other than that the documentation wouldn\'t be updated? My thinking is we\'d just turn off our notifications on these (might be a requirement for more advanced tag filtering, more on that below), if the community is still asking (and answering) questions on these then I don\'t think they should be treated differently to any other question on ask.o.o - though ther eis a closure reason for \"not relevant or outdated\".\n\n> - Can we have RSS notification, text notification, email notifications when\n> a new thread is started, when one gets a reply, for an entire book?\n\nAn RSS feed is automatically created for all tags, email notifications are available (instant, daily digest, weekly digest, or none) and you would configure them based on the tags of interest as well. From the UI it\'s not clear to me how you would configure email notification based on a combination of tags (for instance \"install-guide\" + \"yum\" + \"neutron\", but not \"install-guide\" + \"apt\" + \"neutron\", or even something like \"install-guide\" + \"yum\" - \"diablo\"). \n\nUltimately all notification related questions really come back to what tags are used when raising a question from the documentation and what filtering can be exposed by ask when generating the existing RSS feeds and emails.\n\n> - Can notifications be controlled by group or by individual users only?\n> - Will the mobile user experience be supported?\n\nask.o.o seems to work OK on mobile (actually better than docs.openstack.org - are we meant to be exposing a mobile specific version of the site?).\n\n> - Can we have analytics reports available on which pages are generating the\n> most questions, hotly debated, what time of day do they occur, how long\n> does it take for someone to respond?\n> - Will we be able to moderate the threads by closing down a thread or\n> deleting a reply completely?\n\nAs you earn points on the ask.o.o site you gain moderator abilities, 500 is the threshold for being able to delete content. Part of the idea in these systems is that as users gain points they are guided on how to best use their powers as they are granted.\n\nThanks,\n\nSteve\n\n\n','<CAD0KtVGcX7aE3gywP+KqxQXXPi2b435OLteNUfMb-+psDKJOkw@mail.gmail.com>',NULL),('<1449838550.56.1379053677079.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-13 06:27:57',0,'2013-09-13 06:27:57',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all #23','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/23/>\n\n\n\n','<987084354.52.1378967602469.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<144c0794d38.2758.186cb8a1d497decef8b2d9ec142dfe33@mailbox.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-14 13:03:26',3600,'2014-03-14 12:03:26',NULL,'[openstack-dev] [horizon] Selenium (which is non-free) is back\n	again in Horizon (Icehouse Beta 3)','\n\n\nAm 14. M?rz 2014 12:32:41 schrieb Thomas Goirand <zigo at debian.org>:\n\n> Hi,\n>\n> A few months ago, I raised the fact that Selenium *CANNOT* be a hard\n> test-requirements.txt build-dependency of Horizon, because it is\n> non-free (because of binaries like the browser plug-ins not being\n> build-able from source). So it was removed.\n>\n> Now, on the new Icehouse beta 3, it\'s back again, and I get some unit\n> tests errors (see below).\n>\n> Guys, could we stop having this kind of regressions, and make Selenium\n> tests not mandatory? They aren\'t runnable in Debian.\n\nIdentical situation with openSUSE. And I guess Fedora is no different.\n\n>\n> Cheers,\n>\n> Thomas Goirand (zigo)\n>\n> ======================================================================\n> ERROR: Failure: ImportError (No module named selenium)\n> ----------------------------------------------------------------------\n>   File \"openstack_dashboard/test/integration_tests/helpers.py\", line 17,\n> in <module>\n>     import selenium\n> ImportError: No module named selenium\n>\n> ======================================================================\n> ERROR: Failure: ImportError (No module named selenium.webdriver.common.keys)\n>  File \"openstack_dashboard/test/integration_tests/tests/test_login.py\",\n> line 15, in <module>\n>     import selenium.webdriver.common.keys as keys\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nViele Gr??e,\nSascha Peilicke\n\n\n\n\n','<5322E87F.2030001@debian.org>',NULL),('<144FD7B5-0C2F-44E8-A6B0-3EFAB85BADAE@2cups.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-14 11:44:03',-25200,'2014-01-14 18:44:03',NULL,'[Openstack-docs] Copyright statements in docs source files','So, on one hand we have a perceived reticence to contribute to copyrighted works (which I believe is a valid point)\n\nOn the other hand, we have the reality that clearly stating copyright on a file helps to protect the contributors in the community (by clearly demonstrating who holds copyright)\n\nThis may be a good opportunity for an article on OpenStack.org as well a session at the design summit.\nRegards,\n\nColin\n\nColin McNamara\nPeople | Process | Technology\n--------------------------------------------\nMobile: 	858-208-8105\nTwitter:	@colinmcnamara\nLinkedin:	www.linkedin.com/in/colinmcnamara\nBlog:	www.colinmcnamara.com\nEmail:	colin at 2cups.com	\n\n\n\n\n\n\n\nOn Jan 14, 2014, at 11:30 AM, Rich Bowen <rbowen at redhat.com> wrote:\n\n> \n> On 01/14/2014 01:23 PM, Steve Gordon wrote:\n>> ----- Original Message -----\n>>> Maybe I\'m reading this incorrectly, but my interpretation is that\n>>> there\'s one big copyright page where this information should go, versus\n>>> on individual pages, which is what I think the original question is about.\n>> I believe it refers to the page being edited, if you can find a central page listing all the copyright attributions currently present in OpenStack I\'ll be impressed (there\'s 200+ variations in Nova alone). What I believe Rich was referring to is this type of attribution which is (very) prevalent in the OpenStack code base - including in the developer documentation within those repos:\n>> \n>>     http://git.openstack.org/cgit/openstack/ceilometer/tree/doc/source/install/dbreco.rst\n>> \n>> \n> \n> That was in fact the actual file I was editing as I sent that email.\n> \n> I\'ve actually had people ask me, when looking at files like this, if they have to ask the author for permission to submit patches against that file. If we can avoid making people even think that thought, we\'ve done a good thing for the community.\n> \n> See also http://producingoss.com/en/managing-volunteers.html#territoriality for another take on this issue, just in case Karl\'s voice carries more weight than mine.\n> \n> -- \n> Rich Bowen - rbowen at redhat.com\n> OpenStack Community Liaison\n> http://openstack.redhat.com/\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140114/91c624fc/attachment.html>\n\n','<52D58244.9010405@redhat.com>',NULL),('<1450394829.7768883.1404501704059.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-07-04 15:21:44',-14400,'2014-07-04 19:21:44',NULL,'[Openstack-docs] Which docbookxi.rng file to use with XML\n	Copy	Editor','----- Original Message -----\n> From: \"Laurel Michaels\" <lmichaels at tesora.com>\n> To: openstack-docs at lists.openstack.org\n>\n> I am using XML Copy Editor. When I open a file that the openstack.ent\n> statement:\n> \n> \n> <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n> <!DOCTYPE chapter [\n> <!ENTITY % openstack SYSTEM \"../common/entities/openstack.ent\">\n> %openstack;\n> ]>\n> \n> I now get a validation error.\n> \n> I believe I need a new docbookxi.rng file to validate against. Andreas\n> suggested that I ask the list which one to use for XML Copy Editor.\n> \n> Any ideas?\n\nIt\'s been a while since I used one of these editors, but humour me and try with the rackbook.rng file from here:\n\n    http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/os_doc_tools/resources\n\n-Steve\n\n\n','<1271584604e6438a8171f3424699f059@BY2PR07MB044.namprd07.prod.outlook.com>',NULL),('<1450438077.19579088.1378984793783.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-12 07:19:53',-14400,'2013-09-12 11:19:53',NULL,'[openstack-dev] [qa] nominations for tempest-core','+1 for both of them\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, September 11, 2013 10:32:11 PM\nSubject: [openstack-dev] [qa] nominations for tempest-core\n\nWe\'re in Feature Freeze for the Open Stack projects, which actually \nmeans we\'re starting the busy cycle for Tempest in people landing \nadditional tests for verification of features that hadn\'t gone in until \nrecently. As such, I think now is a good time to consider some new core \nmembers. There are two people I think have been doing an exceptional job \nthat we should include in the core group\n\nMark Koderer has been spear heading the stress testing in Tempest, \ncompleting the new stress testing for the H3 milestone, and has gotten \nvery active in reviews over the last three months.\n\nYou can see his contributions here: \nhttps://review.openstack.org/#/q/project:openstack/tempest+owner:m.koderer%2540telekom.de,n,z\n\nAnd his code reviews here: his reviews here - \nhttps://review.openstack.org/#/q/project:openstack/tempest+reviewer:m.koderer%2540telekom.de,n,z\n\n\nGiulio Fidente did a lot of great work bringing our volumes testing up \nto par early in the cycle, and has been very active in reviews since the \nHavana cycle opened up.\n\nYou can see his contributions here: \nhttps://review.openstack.org/#/q/project:openstack/tempest+owner:gfidente%2540redhat.com,n,z\n\nAnd his code reviews here: his reviews here - \nhttps://review.openstack.org/#/q/project:openstack/tempest+reviewer:gfidente%2540redhat.com,n,z\n\n\nBoth have been active in blueprints and the openstack-qa meetings all \nsummer long, and I think would make excellent additions to the Tempest \ncore team.\n\nCurrent QA core members, please vote +1 or -1 to these nominations when \nyou get a chance. We\'ll keep the polls open for 5 days or until everyone \nhas voiced their votes.\n\nFor reference here are the 90 day review stats for Tempest as of today:\n\nReviews for the last 90 days in tempest\n** -- tempest-core team member\n+----------------------+-----------------------------------+\n|       Reviewer       | Reviews (-2|-1|+1|+2) (+/- ratio) |\n+----------------------+-----------------------------------+\n|     afazekas **      |     275 (1|29|18|227) (89.1%)     |\n|      sdague **       |      198 (4|60|0|134) (67.7%)     |\n|       gfidente       |      130 (0|55|75|0) (57.7%)      |\n|    david-kranz **    |      112 (1|24|0|87) (77.7%)      |\n|     treinish **      |      109 (5|32|0|72) (66.1%)      |\n|      cyeoh-0 **      |       87 (0|19|4|64) (78.2%)      |\n|       mkoderer       |       69 (0|20|49|0) (71.0%)      |\n|     jaypipes **      |       65 (0|22|0|43) (66.2%)      |\n|        igawa         |       49 (0|10|39|0) (79.6%)      |\n|       oomichi        |       30 (0|9|21|0) (70.0%)       |\n|         jogo         |       26 (0|12|14|0) (53.8%)      |\n|       adalbas        |       22 (0|4|18|0) (81.8%)       |\n| ravikumar-venkatesan |       22 (0|2|20|0) (90.9%)       |\n|       ivan-zhu       |       21 (0|10|11|0) (52.4%)      |\n|       mriedem        |        13 (0|4|9|0) (69.2%)       |\n|   andrea-frittoli    |        12 (0|4|8|0) (66.7%)       |\n|       mkollaro       |        10 (0|5|5|0) (50.0%)       |\n|      zhikunliu       |        10 (0|4|6|0) (60.0%)       |\n|        Anju5         |        9 (0|0|9|0) (100.0%)       |\n|       anteaya        |        7 (0|3|4|0) (57.1%)        |\n|         Anju         |        7 (0|0|7|0) (100.0%)       |\n|   steve-stevebaker   |        6 (0|3|3|0) (50.0%)        |\n|       prekarat       |        5 (0|3|2|0) (40.0%)        |\n|        rahmu         |        5 (0|2|3|0) (60.0%)        |\n|       psedlak        |        4 (0|3|1|0) (25.0%)        |\n|        minsel        |        4 (0|3|1|0) (25.0%)        |\n|    zhiteng-huang     |        3 (0|2|1|0) (33.3%)        |\n|         maru         |        3 (0|1|2|0) (66.7%)        |\n|       iwienand       |        3 (0|1|2|0) (66.7%)        |\n|    FujiokaYuuichi    |        3 (0|1|2|0) (66.7%)        |\n|        dolph         |        3 (0|0|3|0) (100.0%)       |\n|     cthiel-suse      |        3 (0|0|3|0) (100.0%)       |\n|    walter-boring     |         2 (0|2|0|0) (0.0%)        |\n|        bnemec        |         2 (0|2|0|0) (0.0%)        |\n|       lifeless       |        2 (0|1|1|0) (50.0%)        |\n|    fabien-boucher    |        2 (0|1|1|0) (50.0%)        |\n|     alex_gaynor      |        2 (0|1|1|0) (50.0%)        |\n|        alaski        |        2 (0|1|1|0) (50.0%)        |\n|       krtaylor       |        2 (0|0|2|0) (100.0%)       |\n|       cbehrens       |        2 (0|0|2|0) (100.0%)       |\n|       Sumanth        |        2 (0|0|2|0) (100.0%)       |\n|         ttx          |         1 (0|1|0|0) (0.0%)        |\n|       rvaknin        |         1 (0|1|0|0) (0.0%)        |\n|     rohitkarajgi     |         1 (0|1|0|0) (0.0%)        |\n|       ndipanov       |         1 (0|1|0|0) (0.0%)        |\n|   michaeltchapman    |         1 (0|1|0|0) (0.0%)        |\n|       maurosr        |         1 (0|1|0|0) (0.0%)        |\n|      mate-lakat      |         1 (0|1|0|0) (0.0%)        |\n|       jecarey        |         1 (0|1|0|0) (0.0%)        |\n|         jdc          |         1 (0|1|0|0) (0.0%)        |\n|      hartsocks       |         1 (0|1|0|0) (0.0%)        |\n|        flwang        |         1 (0|1|0|0) (0.0%)        |\n|      dscannell       |         1 (0|1|0|0) (0.0%)        |\n|        blk-u         |         1 (0|1|0|0) (0.0%)        |\n|       JordanP        |         1 (0|1|0|0) (0.0%)        |\n|       zhhuabj        |        1 (0|0|1|0) (100.0%)       |\n|       zhaoqin        |        1 (0|0|1|0) (100.0%)       |\n|      yoshimatsu      |        1 (0|0|1|0) (100.0%)       |\n|      vsergeyev       |        1 (0|0|1|0) (100.0%)       |\n|       unknown        |        1 (0|0|1|0) (100.0%)       |\n|        tmello        |        1 (0|0|1|0) (100.0%)       |\n|       tkammer        |        1 (0|0|1|0) (100.0%)       |\n|      thang.pham      |        1 (0|0|1|0) (100.0%)       |\n|    syerrapragada     |        1 (0|0|1|0) (100.0%)       |\n|        swann         |        1 (0|0|1|0) (100.0%)       |\n|        sthaha        |        1 (0|0|1|0) (100.0%)       |\n|        sileht        |        1 (0|0|1|0) (100.0%)       |\n|         seif         |        1 (0|0|1|0) (100.0%)       |\n|       saurabh        |        1 (0|0|1|0) (100.0%)       |\n|        novel         |        1 (0|0|1|0) (100.0%)       |\n|       mpavlase       |        1 (0|0|1|0) (100.0%)       |\n|       mapleoin       |        1 (0|0|1|0) (100.0%)       |\n|       kadachi        |        1 (0|0|1|0) (100.0%)       |\n|     johngarbutt      |        1 (0|0|1|0) (100.0%)       |\n|    john-griffith     |        1 (0|0|1|0) (100.0%)       |\n|    jerome-gallard    |        1 (0|0|1|0) (100.0%)       |\n|       jdanjou        |        1 (0|0|1|0) (100.0%)       |\n|       guochbo        |        1 (0|0|1|0) (100.0%)       |\n|        danms         |        1 (0|0|1|0) (100.0%)       |\n|       cboylan        |        1 (0|0|1|0) (100.0%)       |\n|       asalkeld       |        1 (0|0|1|0) (100.0%)       |\n|        arosen        |        1 (0|0|1|0) (100.0%)       |\n|  armando-migliaccio  |        1 (0|0|1|0) (100.0%)       |\n|         alla         |        1 (0|0|1|0) (100.0%)       |\n|      aji-zqfan       |        1 (0|0|1|0) (100.0%)       |\n|        Liang         |        1 (0|0|1|0) (100.0%)       |\n+----------------------+-----------------------------------+\n\n\n	-Sean\n\n-- \nSean Dague\nhttp://dague.net\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5230D34B.9040905@dague.net>',NULL),('<1450467770.22493220.1383840034308.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 11:00:34',-18000,'2013-11-07 16:00:34',NULL,'[openstack-dev] A Tool for Making OpenStack Log Reading a\n	Bit	Easier','Sure, that sounds like a good idea.  Count me in.\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, November 6, 2013 5:31:12 PM\nSubject: Re: [openstack-dev] A Tool for Making OpenStack Log Reading a Bit	Easier\n\nFirst, very cool tool, nice work!\n\nI wonder if it\'s reasonable (or interesting) to take these approaches\nand bring them into os-loganalyze. That would mean there was common\nparsing routines, and then we would just call out to different\nfunctions if were were trying to do HTML or ANSI coloring. I\npersonally live so often off the weblogs that I honestly hadn\'t\nthought about the local case, which would be definitely interesting.\nIt would also be really great if adding semantics to one use did it\nfor the other as well, so people would see the same output when they\nwere looking at test failures as when they were doing local\ndevelopment.\n\nIf you are interested in trying to join efforts there, let me know.\n\nOn Wed, Nov 6, 2013 at 9:36 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n>\n>\n>\n> On Wed, Nov 6, 2013 at 9:10 AM, Clint Byrum <clint at fewbar.com> wrote:\n>>\n>> I often use ccze to look at logs. It has some built in things like\n>> coloring the words \"warn\" or \"warning\" yellow and \"error\" red. It would\n>> be great to have this filter added as another ccze plugin.\n>>\n>\n> Sean Dague, wrote a really slick tool for logs.openstack.org that is\n> similar:\n>\n> http://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/README.rst\n>\n> http://logs.openstack.org/98/54198/7/check/check-tempest-devstack-vm-neutron/a153156/logs/screen-q-svc.txt.gz?level=TRACE\n>\n>>\n>> Excerpts from Solly Ross\'s message of 2013-11-06 05:58:02 +0800:\n>> > Hello All,\n>> > The other day, I was reading through a debug-level OpenStack log, and\n>> > came to the realization that reading OpenStack debug-level logs was\n>> > difficult, to say the least -- they can be very busy, and it is hard to\n>> > quickly filter out relevant information.  Thus, I wrote a little Perl script\n>> > to make reading dense debug-level logs a bit easier:\n>> > https://github.com/DirectXMan12/os_log_prettifier.  I figured that I\'d share\n>> > it with other people.  Basically, the script highlights certain key details\n>> > using color and bolding (via ANSI control codes), and can filter lines based\n>> > on subject (in the form of \'x.y.z\') or message type, using regular\n>> > expressions.  I hope people find it useful!\n>> >\n>> > Best Regards,\n>> > Solly Ross\n>> >\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n-- \nSean Dague\nhttp://dague.net\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CA+3gSVrkfJr8DKzYuygnwEjX1LwPmuF2dyhxgS=1FeXRdHMR3w@mail.gmail.com>',NULL),('<145061240.15.1352505675559.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:01:15',0,'2012-11-10 00:01:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-diablo #88','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/88/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/>\nCheckout:periodic-horizon-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/> - hudson.remoting.Channel at 740355a4:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson1352189764751580305.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-diablo/88\n[SCP] Copying console log.\n\n\n','<1924164454.1.1352419279047.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1451335840.835432.1418918340043.JavaMail.yahoo@jws10635.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-18 15:58:59',0,'2014-12-18 15:58:59',NULL,'[openstack-dev] [Neutron] fixed ip info shown for port even\n when dhcp is disabled','Hi John,Thanks for the pointers. I shall take a look and get back.\nRegards,Paddu\n \n\n     On Thursday, December 18, 2014 6:23 AM, John Belamaric <jbelamaric at infoblox.com> wrote:\n   \n\n Hi Paddu,\nTake a look at what we are working on in Kilo [1] for external IPAM. While this does not address DHCP specifically, it does allow you to use an external source to allocate the IP that OpenStack uses, which may solve your problem.\nAnother solution to your question is to invert the logic - you need to take the IP allocated by OpenStack and program the DHCP server to provide a fixed IP for that MAC.\nYou may be interested in looking at this Etherpad [2] that Don Kehn put together gathering all the various DHCP blueprints and related info, and also at this BP [3] for including a DHCP relay so we can utilize external DHCP more easily.\n[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam[2]?https://etherpad.openstack.org/p/neutron-dhcp-org[3]?https://blueprints.launchpad.net/neutron/+spec/dhcp-relay\nJohn\nFrom: Padmanabhan Krishnan <kprad1 at yahoo.com>\nReply-To: Padmanabhan Krishnan <kprad1 at yahoo.com>, \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nDate: Wednesday, December 17, 2014 at 6:06 PM\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled\n\nThis means whatever tools the operators are using, it need to make sure the IP address assigned inside the VM matches with Openstack has assigned to the port.Bringing the question that i had in another thread on the same topic:\nIf one wants to use the provider DHCP server and not have Openstack\'s DHCP or L3 agent/DVR, it may not be possible to do so even with DHCP disabled in Openstack network. Even if the provider DHCP server is configured with the same start/end range in the same subnet, there\'s no guarantee that it will match with Openstack assigned IP address for bulk VM launches or? when there\'s a failure case.So, how does one deploy external DHCP with Openstack?\nIf Openstack hasn\'t assigned a IP address when DHCP is disabled for a network, can\'t port_update be done with the provider DHCP specified IP address to put the anti-spoofing and security rules?With Openstack assigned IP address, port_update cannot be done since IP address aren\'t in sync and can overlap.\nThanks,Paddu\n\n\n\nOn 12/16/14 4:30 AM, \"Pasquale Porreca\" <pasquale.porreca at dektech.com.au>\nwrote:\n\n>I understood and I agree that assigning the ip address to the port is\n>not a bug, however showing it to the user, at least in Horizon dashboard\n>where it pops up in the main instance screen without a specific search,\n>can be very confusing.\n>\n>On 12/16/14 12:25, Salvatore Orlando wrote:\n>> In Neutron IP address management and distribution are separated\n>>concepts.\n>> IP addresses are assigned to ports even when DHCP is disabled. That IP\n>> address is indeed used to configure anti-spoofing rules and security\n>>groups.\n>> \n>> It is however understandable that one wonders why an IP address is\n>>assigned\n>> to a port if there is no DHCP server to communicate that address.\n>>Operators\n>> might decide to use different tools to ensure the IP address is then\n>> assigned to the instance\'s ports. On XenServer for instance one could\n>>use a\n>> guest agent reading network configuration from XenStore; as another\n>> example, older versions of Openstack used to inject network\n>>configuration\n>> into the instance file system; I reckon that today\'s configdrive might\n>>also\n>> be used to configure instance\'s networking.\n>> \n>> Summarising I don\'t think this is a bug. Nevertheless if you have any\n>>idea\n>> regarding improvements on the API UX feel free to file a bug report.\n>> \n>> Salvatore\n>> \n>> On 16 December 2014 at 10:41, Pasquale Porreca <\n>> pasquale.porreca at dektech.com.au> wrote:\n>>>\n>>> Is there a specific reason for which a fixed ip is bound to a port on a\n>>> subnet where dhcp is disabled? it is confusing to have this info shown\n>>> when the instance doesn\'t have actually an ip on that port.\n>>> Should I fill a bug report, or is this a wanted behavior?\n>>>\n>>> --\n>>> Pasquale Porreca\n>>>\n>>> DEK Technologies\n>>> Via dei Castelli Romani, 22\n>>> 00040 Pomezia (Roma)\n>>>\n>>> Mobile +39 3394823805\n>>> Skype paskporr\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>\n>-- \n>Pasquale Porreca\n>\n>DEK Technologies\n>Via dei Castelli Romani, 22\n>00040 Pomezia (Roma)\n>\n>Mobile +39 3394823805\n>Skype paskporr\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141218/1123e5a8/attachment.html>\n\n','<D0B849D4.AB9FF%jbelamaric@infoblox.com>',NULL),('<14514393.878571349922171466.JavaMail.weblogic@epml01>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 02:22:52',0,'2012-10-11 02:22:52',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','Hi all, I\'m sending this message again in plain text not html.\n\nHi Eoghan,\n\n> 2. What technology is the metrics store based on, at a high level?\n> (e.g. RDBMS accessed via sqlalchemy, noSQL store such as MongoDB,\n> etc.)\n>\n> 3. How are you performing datapoint aggregation? (e.g. eagerly on\n> metric ingestion, versus lazily on get)\n>\n\nIn addition to Joonwon\'s,\n\nSynaps basically stores metric data aggregated with 1 minute resolution in hybrid way, in-memory of storm workers and Cassandra database. And it rolls those aggregated datapoints up again when another resolutions of statistics are requested. \n\nStorm holds time-series datapoints within flexible sliding window per metric based on its longest period of alarm so that it can evaluate alarms without any reading operation from Cassandra database.\n\nSynaps was designed with inspiration by following posts:\n[1] https://www.cloudkick.com/blog/2010/mar/02/4_months_with_cassandra/\n[2] http://pyvideo.org/video/675/storm-the-hadoop-of-realtime-stream-processing\n\nHi Endre,\n\n> But how does Synaps then difffer from Ceilometer? It looks to be duplicated\n> efforts here?\n> \n\nI think I don\'t understand Ceilometer enough but as I know its main purpose is to be a billing system based on hourly collected data while Synaps is focusing to be a monitoring service which deals with more amount of data more frequently.\n\nThank you,\nJune Yi\n\n------- Original Message -------\nSender : Endre Karlson<endre.karlson at gmail.com>\nDate : 2012-10-11 06:04 (GMT+09:00)\nTitle : Re: [openstack-dev] Introducing Synaps project that provides AWS CloudWatch compatible API\n\nBut how does Synaps then difffer from Ceilometer? It looks to be duplicated efforts here?\n\n\nEndre.\n\n\n2012/10/10 Joonwon Lee <joonwon7.lee at samsung.com>\n\nHi, Eoghan,\n1. No, we don\'t have any relation with ceilometer.\n2. Cassandra and Storm (as explained in http://wiki.openstack.org/Synaps)\n3. As far as I understand, aggregation is performed lazily on the request.\n (Metrics are collected every minute and aggregated according to the request.)\n\nDeok-June Yi can explain with more details tomorrow, if you want.\nThanks,\nJoonwon Lee\n\n\n------- Original Message -------\nSender : Eoghan Glynn<eglynn at redhat.com>\n\nDate : Oct 10, 2012 21:14 (GMT+09:00)\n\nTitle : Re: [openstack-dev] Introducing Synaps project that provides AWS CloudWatch compatible API\n\n\n\nHi Joonwon Lee,\n\n> Unfortunately, we could not attend the Design Summit. We also need\n> some time\n> before opening our source codes, mostly for our internal process. We\n> will try to shorten this time.\n\nIt\'s unfortunate you guys won\'t be at the summit, as it would have\nbeen great to discuss in that forum.\n\nBut that said, the quicker you can push the code through your internal\nprocess, the better.\n\n\n> Now we\'re preparing the overview of our project and other\n> documentation.\n> If you have any questions, feel free to ask them at any time.\n\nA few immediate questions that spring to mind:\n\n1. Are you re-using any of the ceilometer[1] infrastructure for\n   your metrics collection pipeline?\n\n2. What technology is the metrics store based on, at a high level?\n   (e.g. RDBMS accessed via sqlalchemy, noSQL store such as MongoDB,\n    etc.)\n\n3. How are you performing datapoint aggregation? (e.g. eagerly on\n   metric ingestion, versus lazily on get)\n\nCheers,\nEoghan\n\n[1] http://ceilometer.readthedocs.org/en/latest/architecture.html\n\n\n> Here are answers of June Yi for Steven Hardy\'s questions below.\n> > - Is the metric collection secure/authenticated?\n> > - Are metrics collected from the hypervisors or in-instance?\n> > - Can service monitoring (in instance) metrics be collected?\n> > - Is the API authenticated (ie via keystone ec2 credentials?)\n>\n> All metrics are collected using the API. The API is authenticated via\n> auth\n> module came from Nova.Authenticate WSGI middleware which supports AWS\n> signature v2. It works well with LdapDriver. But we did not tested if\n> it is\n> working with keystone yet.\n>\n> Default metrics (i.e. CPUUtilization, disk IO, network IO) are\n> collected\n> from hypervisors. Custom metrics can be collected from in-instance or\n> any other source.\n>\n> Regards,\n> --\n> Joonwon Lee, principal software engineer, Samsung SDS\n>\n>\n> ------- Original Message -------\n> Sender : Eoghan Glynn\n\n> Date : 2012-10-10 18:59 (GMT+09:00)\n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n>\n>\n>\n> > > > I\'m working for Synaps project that provides AWS CloudWatch\n> > > > compatible API at Samsung SDS.\n> > > > Currently, we have plan to open the project to the community.\n> > > >\n> > > > Here I introduce Synaps project:\n> > > > http://wiki.openstack.org/Synaps\n> > >\n> > > Details are a bit scarce but at first glance there seem to be an\n> > > overlap\n> > > with the CloudWatch work in the Heat project ?\n> >\n> > There certainly seems to be from the description, but pretty hard\n> > to\n> > evaluate until we see some code ;)\n>\n> Yes, I would second that.\n>\n> Once the code is out the open, the community will be much better\n> placed\n> to judge which approach will make sense to concentrate efforts on.\n>\n> June Yi - are you planning on attending the design summit?\n>\n> Cheers,\n> Eoghan\n>\n>\n> > > Any chance the two groups could meet at the Design Summit next\n> > > week\n> > > and\n> > > make sure we don\'t duplicate effort here ?\n> > >\n> > > Angus Saskeld has a session on CloudWatch in the Incubation room:\n> > > http://openstacksummitfall2012.sched.org/event/60b0bcf1253efcb3dd72dff531d59d26\n> >\n> > Angus Salkeld and Steve Dake will be at the Summit and could\n> > discuss,\n> > also\n> > possible overlap with metric collection in ceilometer (has been\n> > discussed\n> > previously).\n> >\n> > I have several questions which will be make/break for the heat\n> > usage\n> > of\n> > Cloudwatch:\n> >\n> > - Is the metric collection secure/authenticated?\n> > - Are metrics collected from the hypervisors or in-instance?\n> > - Can service monitoring (in instance) metrics be collected?\n> > - Is the API authenticated (ie via keystone ec2 credentials?)\n> >\n> > Many more questions, need to see code and evaluate if we could use\n> > this for\n> > heat or if we continue with our own implementation.\n> >\n> > --\n> > Steve Hardy\n> > Red Hat Engineering, Cloud\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n',NULL,NULL),('<1451441039.295.1356998660416.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-01 00:04:20',0,'2013-01-01 00:04:20',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #92','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/92/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.57 secs:\n    2.45    Kc11TestCase.test_admin_requires_adminness\n    2.30    KcEssex3TestCase.test_admin_requires_adminness\n    2.23    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.07    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 48.150s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==3.0.0\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Rj6ydHaFzn\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/92\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/92/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1237032789.283.1356912271058.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<145156126.8.1382681491426.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-25 06:11:31',0,'2013-10-25 06:11:31',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #44','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/44/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e1c9d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e1c9d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x51a64d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x51a64d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-7414b004-8689-476b-8b03-762f6274afcb\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:11:05+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:11:05-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x67a6850>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2b30d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 69.85 secs:\n    15.70    TestGlanceControl.test_bouncing\n    14.14    TestScrubber.test_delayed_delete\n    13.80    TestGlanceControl.test_reload\n    13.58    TestGlanceControl.test_respawn\n    12.62    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 529.902s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-44\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.L8bWmXb2Az\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/44\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/44/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise12/44\n[SCP] Copying console log.\n\n\n','<2139948872.3.1382508852689.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<145199227.42.1361772792298.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-25 06:13:12',0,'2013-02-25 06:13:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-folsom #147','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/147/>\n\n------------------------------------------\n[...truncated 979 lines...]\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.02\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.00\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: test_create (glance.tests.unit.v2.test_images_resource.TestImagesDeserializerWithExtendedSchema)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v2/test_images_resource.py\",> line 1118, in test_create\n    output = self.deserializer.create(request)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 361, in create\n    return self._parse_image(request)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 317, in _parse_image\n    self.schema.validate(body)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/schema.py\",> line 32, in validate\n    jsonschema.validate(obj, self.raw())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 1239, in validate\n    cls.check_schema(schema)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 141, in check_schema\n    error.message, validator=error.validator, path=error.path,\nSchemaError: True is not of type u\'array\'\n\n======================================================================\nERROR: test_create_bad_data (glance.tests.unit.v2.test_images_resource.TestImagesDeserializerWithExtendedSchema)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v2/test_images_resource.py\",> line 1131, in test_create_bad_data\n    self.deserializer.create, request)\n  File \"/usr/lib/python2.7/unittest/case.py\", line 471, in assertRaises\n    callableObj(*args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 361, in create\n    return self._parse_image(request)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 317, in _parse_image\n    self.schema.validate(body)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/schema.py\",> line 32, in validate\n    jsonschema.validate(obj, self.raw())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 1239, in validate\n    cls.check_schema(schema)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 141, in check_schema\n    error.message, validator=error.validator, path=error.path,\nSchemaError: True is not of type u\'array\'\n\n======================================================================\nERROR: test_update (glance.tests.unit.v2.test_images_resource.TestImagesDeserializerWithExtendedSchema)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v2/test_images_resource.py\",> line 1137, in test_update\n    output = self.deserializer.update(request)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 459, in update\n    self._validate_change(change)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 434, in _validate_change\n    self.schema.validate(partial_image)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/schema.py\",> line 32, in validate\n    jsonschema.validate(obj, self.raw())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 1239, in validate\n    cls.check_schema(schema)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 141, in check_schema\n    error.message, validator=error.validator, path=error.path,\nSchemaError: True is not of type u\'array\'\n\n======================================================================\nERROR: test_update_bad_data (glance.tests.unit.v2.test_images_resource.TestImagesDeserializerWithExtendedSchema)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v2/test_images_resource.py\",> line 1148, in test_update_bad_data\n    self.deserializer.update, request)\n  File \"/usr/lib/python2.7/unittest/case.py\", line 471, in assertRaises\n    callableObj(*args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 459, in update\n    self._validate_change(change)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/api/v2/images.py\",> line 434, in _validate_change\n    self.schema.validate(partial_image)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/schema.py\",> line 32, in validate\n    jsonschema.validate(obj, self.raw())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 1239, in validate\n    cls.check_schema(schema)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/jsonschema.py\",> line 141, in check_schema\n    error.message, validator=error.validator, path=error.path,\nSchemaError: True is not of type u\'array\'\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.68 secs:\n    14.25    TestGlanceControl.test_bouncing\n    14.14    TestScrubber.test_delayed_delete\n    13.85    TestGlanceControl.test_reload\n    13.64    TestGlanceControl.test_respawn\n    12.79    TestBinGlance.test_results_pagination\n----------------------------------------------------------------------\nRan 919 tests in 481.470s\n\nFAILED (SKIP=103, errors=4)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.8\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python27-stable-folsom-147\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\njsonschema==1.0.0\nkombu==2.5.6\nlxml==3.1.0\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==1.1.0\nsimplejson==3.1.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.844D34ALKO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/147\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/147/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1451F1B1-87F4-40AC-A5F7-E2795FFB4AA4@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-07 22:19:44',-10800,'2013-11-08 01:19:44',NULL,'[openstack-dev] nova-api fails to start','It was a new installation, but i tried a couple more times, removed all the component folders and it worked\n\n--\n_______________________________\nTelles Mota Vidal N?brega\n\nUndergraduated in Computer Science at Federal University of Campina Grande (UFCG)\nDeveloper at PulsarOpenStack Project - HP\n\nOn 07 Nov 2013, at 17:54, Krishanu Dhar <rony.kris at gmail.com> wrote:\n\n> Hey Telies - Were you trying to recreate the failure? or is it a new installation?\n> \n> \n> On Fri, Nov 8, 2013 at 2:13 AM, Telles Nobrega <tellesnobrega at gmail.com> wrote:\n> Now i have something like your problem, im getting \n> die 609 \'nova-api did not start\'\n> \n> \n> On Thu, Nov 7, 2013 at 4:11 PM, Krishanu Dhar <rony.kris at gmail.com> wrote:\n> thanks man, incidentally i ran into your post too and it got me going. However, I was wondering if the fix should go in stack.sh.stack.sh\n> \n> \n> On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J <sergio.j.cazzolato at intel.com> wrote:\n> Hi, I had the same issue and fixed that doing a chwon and changing the ownership to my user of the files in /etc/nova where the owner was the user nova.\n> \n>  \n> \n> In my case the files were: api-paste.ini and policy.json\n> \n>  \n> \n> I posted the solution there too:\n> \n>  \n> \n> http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module\n> \n>  \n> \n> Thanks\n> \n>  \n> \n>  \n> \n> From: Krishanu Dhar [mailto:rony.kris at gmail.com] \n> Sent: Thursday, November 07, 2013 3:40 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] nova-api fails to start\n> \n>  \n> \n> Any other recommendations on how to have a successful devstack installation?\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar <rony.kris at gmail.com> wrote:\n> \n> below is an error that\'s probably the cause...\n> \n> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied: \'/etc/nova/api-paste.ini\'\n> 2013-11-07 23:24:14.758 TRACE nova \n> n-api failed to start\n> \n> krish at krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini\n> -rw------- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini\n> \n> isn\'t it expected to fail if the file is owned by \"nova\"... weird.\n> \n>  \n> \n>  \n> \n>  \n> \n> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar <rony.kris at gmail.com> wrote:\n> \n> it did not even start the process in my case.\n> \n> I tried looking up email threads in google and looks like quite a few have run into this before, but couldn\'t find a working fix.\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega <tellesnobrega at gmail.com> wrote:\n> \n> Weird, i had the same problem, but when i kill the processes it works\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar <rony.kris at gmail.com> wrote:\n> \n> Nothing was left behind. \n> \n> #ps aux|grep -ie nova did not return anything.\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega <tellesnobrega at gmail.com> wrote:\n> \n> Did you check if there are any nova process left running?\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar <rony.kris at gmail.com> wrote:\n> \n> Appreciate the responses. But there is something wrong with this. I ran unstack.sh again and retried the installation. it failed with the same message. \n> \n> So, what are my options right now?\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega <tellesnobrega at gmail.com> wrote:\n> \n> Sometimes after ./unstack is ran, some process are still runnning for nova. \n> \n> Try running this to kill them all (ps aux | grep -ie nova | awk \'{print $2}\' | xargs kill -9) and try ./stack again\n> \n>  \n> \n> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M <noorul at noorul.com> wrote:\n> \n> Krishanu Dhar <rony.kris at gmail.com> writes:\n> \n> > Hi,\n> >\n> > I was trying to install the devstack and it failed while starting the nova\n> > api. below is a snippet from the console. Is it a bug?\n> >\n> >\n> > + screen -S stack -p n-api -X stuff \'cd /opt/stack/nova &&\n> > /usr/local/bin/nova-a\'i || echo \"n-api failed to start\" | tee\n> > \"/opt/stack/status/stack/n-api.failure\"\n> > + echo \'Waiting for nova-api to start...\'\n> > Waiting for nova-api to start...\n> > + wait_for_service 60 http://10.0.2.15:8774\n> > + local timeout=60\n> > + local url=http://10.0.2.15:8774\n> > + timeout 60 sh -c \'while ! curl --noproxy \'\\\'\'*\'\\\'\' -s\n> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done\'\n> > + die 628 \'nova-api did not start\'\n> > + local exitcode=0\n> > + set +o xtrace\n> > [Call Trace]\n> > ./stack.sh:1084:start_nova_api\n> > /home/krish/devstack/lib/nova:628:die\n> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start\n> > krish at krish-VirtualBox:~/devstack$\n> \n> Did you try \"screen -x stack\" ?\n> \n> Regards,\n> Noorul\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n>  \n> \n> --\n> \n> ------------------------------------------\n> Telles Mota Vidal Nobrega\n> Developer at PulsarOpenStack Project - HP/LSD-UFCG\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> \n> \n> \n>  \n> \n> --\n> \n> ------------------------------------------\n> Telles Mota Vidal Nobrega\n> Developer at PulsarOpenStack Project - HP/LSD-UFCG\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> \n> \n> \n>  \n> \n> --\n> \n> ------------------------------------------\n> Telles Mota Vidal Nobrega\n> Developer at PulsarOpenStack Project - HP/LSD-UFCG\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Krishanu\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> ------------------------------------------\n> Telles Mota Vidal Nobrega\n> Developer at PulsarOpenStack Project - HP/LSD-UFCG\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> -- \n> Krishanu\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/d4e74ecc/attachment.html>\n\n','<CAL6MZqc-PVnzxuQeDDGe6SmRiZrQcbEhMUHJpQfd_G=7YXojCQ@mail.gmail.com>',NULL),('<1452133997.79.1367820922066.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-06 06:15:22',0,'2013-05-06 06:15:22',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly-centos6 #6','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/6/>\n\n------------------------------------------\n[...truncated 3973 lines...]\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 489, in test_user_list_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:43582/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 823, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:44554/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 842, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:41315/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 496, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:34973/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 512, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:42523/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 34.75 secs:\n    7.74    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.82    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.79    KcEssex3TestCase.test_admin_requires_adminness\n    6.72    Kc11TestCase.test_admin_requires_adminness\n    6.69    KcMasterTestCase.test_admin_requires_adminness\n----------------------------------------------------------------------\nRan 1272 tests in 472.613s\n\nFAILED (SKIP=82, errors=129)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.centos6.6\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=66\n+ \'[\' 66 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.BwHRCILt7D\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/6\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/6/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1795159583.58.1367734519740.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1452351306.1351351393866080201.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-03-03 17:01:20',0,'2014-03-03 17:01:20',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n Meeting March 4, 2014 (F2F meeting)','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting March 4, 2014 (F2F meeting)\nHost: Alan Clark\nDate: Tuesday, March 4, 2014\nTime: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00)\n\nSession number: 926 584 365\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t7f162cbf8667e42cc4c43fcb840e31a8\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb74dc31225bf9c2c3a45c14a0a7098b4\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=272441082&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 926 584 365\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t8c379f2c453e2fe18a869125327e39a2\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140303/b4a5d3e7/attachment.html>\n\n',NULL,NULL),('<1452809875.24.1374473054319.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-22 06:04:14',0,'2013-07-22 06:04:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #294','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/294/>\n\n------------------------------------------\n[...truncated 8986 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 204, in test_workflow_finalization\n    self.assertTrue(flow.finalize())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 747, in finalize\n    exceptions.handle(self.request)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 0.89 secs:\n    0.37    RoleAPITests.test_get_default_role\n    0.17    HorizonTests.test_lazy_urls\n    0.13    DataTableTests.test_summation_row\n    0.12    DataTableTests.test_table_action_attributes\n    0.10    NetworkTests.test_subnet_create_post_cidr_inconsistent\n----------------------------------------------------------------------\nRan 350 tests in 4.736s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.19\npep8==1.4.6\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.oauy5ls5we\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/294\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/294/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/294/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<482914358.19.1374386675978.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<145281021.33632740.1405062496478.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-11 00:08:16',-25200,'2014-07-11 07:08:16',NULL,'[openstack-dev] [nova][vmware] Convert to rescue by adding the\n rescue image and booting from it','Definitely +1.\n\nThis change will allow us to get rid of the of the ugly special cases where we use the instance name instead of the uuid and will make the code cleaner.  Let\'s go for it!\n\nThanks,\nRado\n\n----- Original Message -----\n> Currently we create a rescue instance by creating a new VM with the\n> original instance\'s image, then adding the original instance\'s first\n> disk to it, and booting. This means we have 2 VMs, which we need to be\n> careful of when cleaning up. Also when suspending, and probably other\n> edge cases. We also don\'t support:\n> \n> * Rescue images other than the instance\'s creation image\n> * Rescue of an instance which wasn\'t created from an image\n> * Access to cinder volumes from a rescue instance\n> \n> I\'ve created a dirty hack which, instead of creating a new VM, attaches\n> the given rescue image to the VM and boots from it:\n> \n> https://review.openstack.org/#/c/106078/\n> \n> It works for me. It supports all of the above, doesn\'t require special\n> handling on destroy, and works with suspend[1]. It also doesn\'t trigger\n> the spurious warning message about unknown VMs on the cluster which,\n> while unimportant in itself, is an example of an edge case caused by\n> having 2 VMs.\n> \n> Does this seem a reasonable way to go? It would be dependent on a\n> refactoring of the image cache code so we could cache the rescue image.\n> \n> Matt\n> \n> [1] If suspend of a rescued image wasn\'t broken at the api level,\n> anyway. I have a patch for that: https://review.openstack.org/#/c/106082/\n> --\n> Matthew Booth\n> Red Hat Engineering, Virtualisation Team\n> \n> Phone: +442070094448 (UK)\n> GPG ID:  D33C3490\n> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<53BEB6DB.3070100@redhat.com>',NULL),('<1453060255.5790602.1412334804227.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-03 07:13:24',-14400,'2014-10-03 11:13:24',NULL,'[openstack-dev] [all][tc] governance changes for \"big tent\"\n model','\n> As promised at this week?s TC meeting, I have applied the various blog posts\n> and mailing list threads related to changing our governance model to a\n> series of patches against the openstack/governance repository [1].\n> \n> I have tried to include all of the inputs, as well as my own opinions, and\n> look at how each proposal needs to be reflected in our current policies so\n> we do not drop commitments we want to retain along with the processes we are\n> shedding [2].\n> \n> I am sure we need more discussion, so I have staged the changes as a series\n> rather than one big patch. Please consider the patches together when\n> commenting. There are many related changes, and some incremental steps won?t\n> make sense without the changes that come after (hey, just like code!).\n\nThanks Doug for moving this discussion out of the blogosphere and\ninto gerrit. That will be very helpful in driving the discussion\nforward.\n\nHowever, given the proximity of the TC elections, should these all\npatches all be workflow -1\'d as WIP to ensure nothing lands before\nthe incoming TC is ratified?\n\n(I\'m assuming here that the decision-making on these fairly radical\nproposals should rest with the new post-election TC - is that a\ncorrect assumption?)\n\nCheers,\nEoghan\n\n\n','<72EA5FA5-7A34-4EDD-A800-416D06A5E28D@doughellmann.com>',NULL),('<1453536.LUXbslVTY5@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 16:12:42',7200,'2014-07-07 14:12:42',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Le lundi 7 juillet 2014, 11:26:27 Gordon Sim a ?crit :\n> > When we switch to asyncio\'s event loop, all of this code needs to be\n> > ported to asyncio\'s explicitly asynchronous approach. We might do:\n> >    @asyncio.coroutine\n> >    \n> >    def foo(self):\n> >        result = yield from some_async_op(...)\n> >        return do_stuff(result)\n> > \n> > or:\n> >    @asyncio.coroutine\n> >    def foo(self):\n> >        fut = Future()\n> >        some_async_op(callback=fut.set_result)\n> >        ...\n> >        result = yield from fut\n> >        return do_stuff(result)\n> > \n> > Porting from eventlet\'s implicit async approach to asyncio\'s explicit\n> > async API will be seriously time consuming and we need to be able to do\n> > it piece-by-piece.\n> \n> Am I right in saying that this implies a change to the effective API for\n> oslo.messaging[1]? I.e. every invocation on the library, e.g. a call or\n> a cast, will need to be changed to be explicitly asynchronous?\n>\n> [1] Not necessarily a change to the signature of functions, but a change\n> to the manner in which they are invoked.\n\nThe first step is to patch endpoints to add @trollius.coroutine to the methods, \nand add yield From(...) on asynchronous tasks.\n\nLater we may modify Oslo Messaging to be able to call an RPC method \nasynchronously, a method which would return a Trollius coroutine or task \ndirectly. The problem is that Oslo Messaging currently hides \"implementation\" \ndetails like eventlet. Returning a Trollius object means that Oslo Messaging \nwill use explicitly Trollius. I\'m not sure that OpenStack is ready for that \ntoday.\n\nVictor\n\n\n','<53BA75D3.9030501@redhat.com>',NULL),('<1454780018.67.1386742283412.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:11:23',0,'2013-12-11 06:11:23',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-grizzly #3','See <https://jenkins01.openstack.org/job/periodic-glance-python26-grizzly/3/>\n\n\n\n','<876338209.56.1386483239322.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1456006693.1.1368771800161.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-17 06:23:20',0,'2013-05-17 06:23:20',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #228','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/228/>\n\n------------------------------------------\n[...truncated 12595 lines...]\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for b64cd06680234573998fc18d33f37a04 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:50847\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:50847/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (21516) wsgi starting up on http://127.0.0.1:50847/\n\nnova.osapi_compute.wsgi.server: INFO: (21516) accepted (\'127.0.0.1\', 55691)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [17/May/2013 06:18:02] \"GET /v2 HTTP/1.1\" 204 216 0.001064\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-30443678-1795-48a9-bc45-3b0c137cf5bd</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (21516) accepted (\'127.0.0.1\', 55692)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8e9e7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8e9e7d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:50847/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:50847/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [17/May/2013 06:18:03] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.243630\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 7a021d9d06804e08b06f579294bf8ca9 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:60617\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:60617/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (21516) wsgi starting up on http://127.0.0.1:60617/\n\nnova.osapi_compute.wsgi.server: INFO: (21516) accepted (\'127.0.0.1\', 40386)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [17/May/2013 06:18:03] \"GET /v2 HTTP/1.1\" 204 216 0.001128\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-3d3cf805-b59c-4732-8828-8db939818974</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (21516) accepted (\'127.0.0.1\', 40387)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b033d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b033d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:60617/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     name)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-17 06:18:03 21516 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:60617/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [17/May/2013 06:18:03] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.282046\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.F3SzE4dtga\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/228\n[SCP] Copying console log.\n\n\n','<1553623347.287.1368685454332.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1456368584.27125203.1375799345778.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 10:29:05',-14400,'2013-08-06 14:29:05',NULL,'[openstack-dev] instances fail to boot on el6 (glance schema\n error	issue)','Okay. The quick fix is to remove the extra Glance V2 call when CONF.allowed_direct_url_schemes is disabled.\n\n https://review.openstack.org/#/c/40426/1\n\nThis effectively avoids calling the Glance V2 API on python 2.6 (thus avoiding the schema validation issue).\n\nThe real issue here is still unresolved however and it looks like we still have some work to do to get all the fancy new Glance V2 stuff fully working on python 2.6 distros (RHEL/Centos, etc).\n\nDan\n\n----- Original Message -----\n> From: \"Dan Prince\" <dprince at redhat.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, August 5, 2013 9:01:40 PM\n> Subject: [openstack-dev] instances fail to boot on el6 (glance schema error	issue)\n> \n> As of an hour ago the el6 (Centos) builds in SmokeStack all started failing.\n> I\'ve documented the initial issue I\'m seeing in this ticket:\n> \n>  https://bugs.launchpad.net/nova/+bug/1208656\n> \n> The issue seems to be that we now hit a SchemaError which bubbles up from\n> glanceclient when the new direct download plugin code runs. This only seems\n> to happen on distributions using python 2.6 as I\'m not seeing the same thing\n> on Fedora.\n> \n> This stack trace also highlights the fact that the Glance v2 API now seems to\n> be a requirement for Nova... and I\'m not sure this is a good thing\n> considering we still use the v1 API for many things as well. Ideally we\'d\n> have all Nova -> Glance communication use a single version of the Glance API\n> (either v1 or v2... not both) right?\n> \n> Dan\n\n\n','<143319292.26341739.1375750900977.JavaMail.root@redhat.com>',NULL),('<145646731.0.1375768928931.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:02:08',0,'2013-08-06 06:02:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #1','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/1/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-92 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #93 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson7231838392554393327.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson3217463266800712848.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_CINDER=1\n+ DEVSTACK_GATE_CINDER=1\n+ export ZUUL_BRANCH=stable/folsom\n+ ZUUL_BRANCH=stable/folsom\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-92\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-92/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-92/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-92/1/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1457031010.28920305.1407837255359.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-12 05:54:15',-14400,'2014-08-12 09:54:15',NULL,'[openstack-dev]\n	[tc][ceilometer]	Some	background	on	the	gnocchi	project','\n\n> >> Doesn\'t InfluxDB do the same?\n> > InfluxDB stores timeseries data primarily.\n> >\n> > Gnocchi in intended to store strongly-typed OpenStack resource\n> > representations (instance, images, etc.) in addition to providing\n> > a means to access timeseries data associated with those resources.\n> >\n> > So to answer your question: no, IIUC, it doesn\'t do the same thing.\n> \n> Ok, I think I\'m getting closer on this.\n\nGreat!\n\n> Thanks for the clarification. Sadly, I have more questions :)\n\nAny time, Sandy :)\n \n> Is this closer? \"a metadata repo for resources (instances, images, etc)\n> + an abstraction to some TSDB(s)\"?\n\nSomewhat closer (more clarification below on the metadata repository\naspect, and the completeness/authority of same).\n\n> Hmm, thinking out loud ... if it\'s a metadata repo for resources, who is\n> the authoritative source for what the resource is? Ceilometer/Gnocchi or\n> the source service?\n\nThe source service is authoritative.\n\n> For example, if I want to query instance power state do I ask ceilometer\n> or Nova?\n\nIn that scenario, you\'d ask nova.\n\nIf, on the other hand, you wanted to average out the CPU utilization\nover all instances with a certain metadata attribute set (e.g. some\nuser metadata set by Heat that indicated membership of an autoscaling\ngroup), then you\'d ask ceilometer.\n\n> Or is it metadata about the time-series data collected for that\n> resource?\n\nBoth. But the focus of my preceding remarks was on the latter.\n\n> In which case, I think most tsdb\'s have some sort of \"series\n> description\" facilities.\n\nSure, and those should be used for metadata related directly to\nthe timeseries (granularity, retention etc.)\n\n> I guess my question is, what makes this metadata unique and how\n> would it differ from the metadata ceilometer already collects?\n\nThe primary difference between the way ceilometer currently stores\nmetadata, is the avoidance of per-sample snapshots of resource\nmetadata (as stated in the initial mail on this thread).\n \n> Will it be using Glance, now that Glance is becoming a pure metadata repo?\n\nNo, we have no plans to use glance for this.\n\nBy becoming a pure metadata repo, presumably you mean this spec:\n\n  https://github.com/openstack/glance-specs/blob/master/specs/juno/metadata-schema-catalog.rst\n\nI don\'t see this on the glance roadmap for Juno:\n\n  https://blueprints.launchpad.net/glance/juno \n\nso presumably the integration of graffiti and glance is still more\nof a longer term intent, than a present-tense \"becoming\".\n\nI\'m totally open to correction on this by markwash and others,\nbut my reading of the debate around the recent change in glance\'s\nmission statement was that the primary focus in the immediate\nterm was to expand into providing an artifact repository (for\nartifacts such as Heat templates), while not to *precluding* any\nfuture expansion into also providing a metadata repository.\n\nThe fossil-record of that discussion is here:\n\n  https://review.openstack.org/98002\n\n> > Though of course these things are not a million miles from each\n> > other, one is just a step up in the abstraction stack, having a\n> > wider and more OpenStack-specific scope.\n> \n> Could it be a generic timeseries service? Is it \"openstack specific\"\n> because it uses stackforge/python/oslo?\n\nNo, I meant OpenStack-specific in terms of it understanding\nsomething of the nature of OpenStack resources and their ownership\n(e.g. instances, with some metadata, each being associated with a\nuser & tenant etc.)\n\nNot OpenStack-specific in the sense that it takes dependencies from\noslo or stackforge.\n\nAs for using python: yes, gnocchi is implemented in python, like\nmuch of the rest of OpenStack.  However, no, I don\'t think that\nchoice of implementation language makes it OpenStack-specific.\n\n> I assume the rules and schemas will be data-driven (vs. hard-coded)?\n\nWell one of the ideas was to move away from loosely typed\nrepresentations of resources in ceilometer, in the form of a dict\nof metadata containing whatever it contains, and instead decide\nupfront what was the specific minimal information per resource\ntype that we need to store.\n\n> ... and since the ceilometer collectors already do the bridge work, is\n> it a pre-packaging of definitions that target openstack specifically?\n\nI\'m not entirely sure of what you mean by the bridge work in\nthis context.\n\nThe ceilometer collector effectively acts a concentrator, by\npersisting the metering messages emitted by the other ceilometer\nagents (i.e. the compute, central, & notification agents) to the\nmetering store.\n\nThese samples are stored by the collector pretty much as-is, so\nthere\'s no real bridging going on currently in the collector (in\nthe sense of mapping or transforming).\n\nHowever, the collector is indeed the obvious hook point for\nceilometer to emit data to gnocchi.\n\n> (not sure about \"wider and more specific\")\n\nI presume you\'re thinking oxymoron with \"wider and more specific\"?\n\nI meant:\n\n * \"wider\" in the sense that it covers more ground than generic\n   timeseries data storage\n\n * \"more specific\" in the sense that some of that extra ground is\n   quite OpenStack-oriented\n\nDoes that make my intended meaning a bit clearer?\n\n> Sorry if this was already hashed out in Atlanta.\n\nYes it was, at length in both the design sessions and the\n\"project pod\".\n\n(For background, the pod idea was a new innovation in Atlanta,\neffectively a big fluid space with loosely assigned per-project\ntables and informal/ emergent scheduling of discussions ... kinda\nlike the old unconference track, but a bit more focused, and also\nopen to hearing about stuff \"by osmosis\").\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A52BB29E@ORD1EXD02.RACKSPACE.CORP>',NULL),('<14587125.4770.1384816759572.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-18 15:19:08',-28800,'2013-11-18 23:19:08',NULL,'[openstack-dev] Congress: an open policy framework','Inline.\n\n----- Original Message -----\n| From: \"Adam Young\" <ayoung at redhat.com>\n| To: openstack-dev at lists.openstack.org\n| Sent: Friday, November 15, 2013 2:46:02 PM\n| Subject: Re: [openstack-dev] Congress: an open policy framework\n|\n| On 11/14/2013 11:39 AM, Tim Hinrichs wrote:\n| > I completely agree that making Congress successful will rely\n| > crucially on addressing performance and scalability issues.  Some\n| > thoughts...\n| >\n| > 1. We\'re definitely intending to cache data locally to avoid\n| > repeated API calls.  In fact, a prototype cache is already in\n| > place.  We haven\'t yet hooked up API calls (other than to AD).  We\n| > envision some data sources pushing us data (updates) and some data\n| > sources requiring us to periodically pull.\n| So, I think that you should start with what we already have working.\n| Policy distribution is a part of Keystone now.  Policy processing\n| uses\n| Oslo policy.py.  I am not sure why it would make sense to have a\n| separate program.  I would be more than happy to house this work\n| inside\n| the existing Keystone architecture.\n|\n| >\n| > 2. My main concern for scalability/performance is for proactive\n| > enforcement, where at least conceptually Congress is on the\n| > critical path for API calls.\n| >\n| > One thought is that we could splice out, say, the network portion\n| > of the Congress policy and push it down into neutron, assuming\n| > neutron could enforce that policy.  This would at least eliminate\n| > cross-component communication.  It would require a policy engine\n| > on each of the OS components, but (a) there already is one on many\n| > components and (b) if there isn\'t, we can rely on reactive\n| > enforcement.\n| >\n| > The downside with policy-caching on other OS components are the\n| > usual problems with staleness and data replication, e.g. maybe\n| > we\'d end up copying all of nova\'s VM data into neutron so that\n| > neutron could enforce its policy.  But because we have reactive\n| > enforcement to rely on, we could always approximate the policy\n| > that we push down (conservatively) to catch the common mistakes\n| > and leave the remainder to reactive enforcement.  For example, we\n| > might be able to auto-generate the current policy.json files for\n| > each component from Congress\'s policy.\n| >\n| > Keeping Congress out of the critical path for every API call is one\n| > of the reasons it was designed to do reactive enforcement as well\n| > as proactive enforcement.\n|\n| I think all these questions have come up multiple times with\n| Keystone.\n| There was a signifcant discussion about Configuration management,\n| which\n| would encompass policy.  We were discussing the Key Distribution\n| Service\n| as well. It bascially comes down to \"inside the undercloud\" versus\n| outside (end user facing).\n|\n| Termie\'s suggestion was that we needed to consider using something\n| like\n| Zookeeper.  I think he is right.\n|\n\nI\'ve heard different people mean different things by \"configuration mgmt\".  Some are talking about managing server configurations e.g. with Puppet.  Others are talking about managing the overall configuration of the cloud across components (e.g. every network connected to a VM must be owned by someone in the same group as the VMs owner).  Congress is intended to support whatever configuration management/policy you can write in terms of the cloud services you have available.  We don\'t differentiate between configuration management and policy.\n\n| >\n| > 3. Another option is to build high-performance optimizations for\n| > certain fragments of the policy language.  Then the cloud\n| > architect can decide whether she wants to utilize a more\n| > expressive language whose performance is worse or a less\n| > expressive language whose performance is better.\n|\n| So we should not be writing yet another policy language.  We have a\n| simple one in Open Stack already, and there are many, many ones out\n| there already.  XACML is the standard for authorization decisions, as\n| an\n| example.  Puppet  falls into this role as well.\n|\n\nNot all languages are created equal, which is especially true of declarative/policy languages.  The one we\'ve prototyped is more expressive than the languages you mention (though is general-purpose, not domain-specific like Puppet).  We\'re not inventing yet another policy language--we\'re using a core fragment of SQL that\'s been studied and used for 50 years.  We\'re simply advocating its use.  We\'re also building a policy engine around it for both proactive enforcement (stopping violations before they occur) and reactive enforcement (correcting violations after they occur).  We\'re also adding algorithms that help an admin understand her current policy as well as hypothetical changes to that policy and its data sources.  Finally, we\'re providing data integration functionality for the cloud services over which policy is written.\n\n|\n| I don\'t think this effort makes sense as a stand alone project.\n| Either\n| it should be part of Keystone if it just for the existing acces\n| policy,\n| or it should be part of a larger configuration management effort.  I\n| realize that there is a commonality of effort in policy enforcement\n| that\n| sounds like it should be a stand alone project, but I think that\n| there\n| is much more to the conversation than just that.\n\nIf the right thing for the OS ecosystem is that Congress is absorbed into another component, we\'re happy to do that.  We didn\'t think Keystone fit the bill, but maybe we were wrong.  Can you help me understand some more about Keystone and how Congress would fit in?\n\nAs I understand it, Keystone is an identity service, which to me means it handles authentication and manages user attributes.  When combined with oslo-policy, it also handles authorization in so far as user attributes suffice for making authorization decisions.  Is this basically right? \n\nThe main reason I didn\'t see Congress as fitting under the Keystone umbrella is that Congress deals with authorization policies based on data that I wouldn\'t expect within an identity service.  Instead of a policy that authorizes an API request based solely on user-attributes and the parameters of the request, Congress policies can be conditioned on all kinds of information from arbitrary cloud data sources, e.g. antivirus scanners, VM attributes, network attributes, inventory management systems.\n\nThe other thing that made me think Congress might not belong in Keystone was its policy engine.  We envision Congress enforcing the policy both proactively (stopping violations before they happen) and reactively (fixing violations after they occur).  The proactive version is a natural fit with oslo-policy/Keystone.  The reactive version requires a  policy engine that constantly listens for updates to data sources, checks for policy violations, and takes action to correct violations.  There are also plans for a dashboard interface for admins to control reactive enforcement and investigate the policy, its violations, and the consequences of policy changes.  This operational model didn\'t seem to fit with what I knew about Keystone.\n\nAgain, we\'re happy to do the right thing here.  Just not sure what the right thing is.\n\nTim\n\n\n','<5286A42A.3050303@redhat.com>',NULL),('<1458871673.4334381.1386622518762.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 15:55:18',-18000,'2013-12-09 20:55:18',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','> >        * created as part of undercloud install process\n> >        * can create additional management nodes (F)\n> >     * Resource nodes\n> >\n> >                         ^ nodes is again confusing layers - nodes are\n> > what things are deployed to, but they aren\'t the entry point\n> >\n> > Can you, please be a bit more specific here? I don\'t understand this note.\n> \n> By the way, can you get your email client to insert > before the text\n> you are replying to rather than HTML | marks? Hard to tell what I\n> wrote and what you did :).\n> \n> By that note I meant, that Nodes are not resources, Resource instances\n> run on Nodes. Nodes are the generic pool of hardware we can deploy\n> things onto.\n\nI don\'t think \"resource nodes\" is intended to imply that nodes are resources; rather, it\'s supposed to\nindicate that it\'s a node where a resource instance runs.  It\'s supposed to separate it from \"management node\"\nand \"unallocated node\".\n\n> >     * Unallocated nodes\n> >\n> > This implies an \'allocation\' step, that we don\'t have - how about\n> > \'Idle nodes\' or something.\n> >\n> > It can be auto-allocation. I don\'t see problem with \'unallocated\' term.\n> \n> Ok, it\'s not a biggy. I do think it will frame things poorly and lead\n> to an expectation about how TripleO works that doesn\'t match how it\n> does, but we can change it later if I\'m right, and if I\'m wrong, well\n> it won\'t be the first time :).\n> \n\nI\'m interested in what the distinction you\'re making here is.  I\'d rather get things\ndefined correctly the first time, and it\'s very possible that I\'m missing a fundamental\ndefinition here.\n\n\nMainn\n\n\n','<CAJ3HoZ0o+BvEmYw6nLKC=KiHCK3hFOs5LRFstxKXhBSpQ6ixLg@mail.gmail.com>',NULL),('<1459933.THEhJWAmP7@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-01 09:10:33',7200,'2014-04-01 07:10:33',NULL,'[Openstack] [NOVA] Missing network info in nova list','Hello,\n\nMaybe the problem is not that missing data in nova\'s database becasue when I \nmade: \nnova --debug list\nthen I see that it is asking neutron about ports and this missing IP is \ncorretly send from neutron. \nAlso when I made:\nnova interface-list <instance_id>\nthen there is no problem and IP is displayed. But still this IP is missing in \nlist of instances and I displaying instance details (also in horizon). \n\n--\nBest regards\nS?awek Kap?o?ski\n\nDnia poniedzia?ek, 31 marca 2014 18:17:18 S?awek Kap?o?ski pisze:\n> Hello,\n> \n> I have openstack installation with neutron. When I made test and create\n> many instances in one query (using --num-instances) all was ok but one\n> instance (from 80 created) has no IP address when I made \"nova list\" or\n> \"nova show \". I found that there is missing value in \"network info\" in\n> nova database in \"Instance-info-cache\" table. Everything except that is\n> working fine: port with this IP is assigned to instance in neutron,\n> binding is ok, instance has got configured this IP and I can ping it.\n> Maybe someone know why this informations are missing in nova database\n> and how to refresh it?\n\n\n','<9262ce7e59cd746e879053ea0cc37360@kaplonski.pl>',NULL),('<1459933.THEhJWAmP7@laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 09:10:33',7200,'2014-04-01 07:10:33',NULL,'[openstack-dev] [Openstack] [NOVA] Missing network info in nova\n	list','Hello,\n\nMaybe the problem is not that missing data in nova\'s database becasue when I \nmade: \nnova --debug list\nthen I see that it is asking neutron about ports and this missing IP is \ncorretly send from neutron. \nAlso when I made:\nnova interface-list <instance_id>\nthen there is no problem and IP is displayed. But still this IP is missing in \nlist of instances and I displaying instance details (also in horizon). \n\n--\nBest regards\nS?awek Kap?o?ski\n\nDnia poniedzia?ek, 31 marca 2014 18:17:18 S?awek Kap?o?ski pisze:\n> Hello,\n> \n> I have openstack installation with neutron. When I made test and create\n> many instances in one query (using --num-instances) all was ok but one\n> instance (from 80 created) has no IP address when I made \"nova list\" or\n> \"nova show \". I found that there is missing value in \"network info\" in\n> nova database in \"Instance-info-cache\" table. Everything except that is\n> working fine: port with this IP is assigned to instance in neutron,\n> binding is ok, instance has got configured this IP and I can ping it.\n> Maybe someone know why this informations are missing in nova database\n> and how to refresh it?\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n','<9262ce7e59cd746e879053ea0cc37360@kaplonski.pl>',NULL),('<1460390923.0.1371363777377.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-16 06:22:57',0,'2013-06-16 06:22:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #258','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/258/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:58170\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:58170/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19675) wsgi starting up on http://127.0.0.1:58170/\n\nnova.osapi_compute.wsgi.server: INFO: (19675) accepted (\'127.0.0.1\', 37112)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/Jun/2013 06:17:34] \"GET /v2 HTTP/1.1\" 204 216 0.000774\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-a7f3db4d-db86-4294-804e-48e709c8251c</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19675) accepted (\'127.0.0.1\', 37113)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa80efd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa80efd0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:58170/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:58170/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/Jun/2013 06:17:35] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.249049\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for e97815ae21764d8ebe66a76178b7139c \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:37101\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:37101/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19675) wsgi starting up on http://127.0.0.1:37101/\n\nnova.osapi_compute.wsgi.server: INFO: (19675) accepted (\'127.0.0.1\', 53403)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/Jun/2013 06:17:35] \"GET /v2 HTTP/1.1\" 204 216 0.001029\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-38817004-2b66-4951-ba8a-8e021439855c</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19675) accepted (\'127.0.0.1\', 53404)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9657050>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9657050>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:37101/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     name)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-16 06:17:35 19675 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:37101/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/Jun/2013 06:17:35] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.312523\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.16\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.l5ujpFlbyM\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/258\n[SCP] Copying console log.\n\n\n','<983383631.0.1371277384147.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1460473670.155.1366007137239.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-15 06:25:37',0,'2013-04-15 06:25:37',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #5','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/5/>\n\n\n\n','<1974923733.138.1365920223822.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1460515356.21578637.1417192412678.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-11-28 11:33:32',-18000,'2014-11-28 16:33:32',NULL,'[OpenStack-docs] Usage of OmniGraffle','----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: \"Christian Berendt\" <berendt at b1-systems.de>, openstack-docs at lists.openstack.org\n> \n> I see the situation a bit differently. I donate a lot of time to upstream\n> contributions of which diagrams consume a significant portion and prefer to\n> use whatever application makes the process most efficient and the output\n> most professional providing it can support files that follow open\n> standards. OmniGraffle meets these requirements. I don\'t see anyone\n> complaining about the use of oXygen for XML files which has a tendency to\n> occasionally restructure (indents, line lengths, etc.) files and add\n> proprietary metadata (usually in comments) to them.\n\nI imagine you see fewer complaints about the latter because we are all able to edit those files using whatever open source tool we want (vim, emacs, nano, gedit, kate, whatever) and the rendering of it to the viewer is ultimately still consistent as that\'s handled by the common docbook toolchain we all use.\n\nAs I understood it you were redoing all the diagrams with the intent of providing a consistent format that others who add or edit the diagrams in the future would be able to make them consistent. I don\'t think we can expect people to do that if they can\'t do it without using this tool.\n\n-Steve\n\n\n','<CABA+jQoLEcmJfTM_nEN-c0cJtyz-Rez0u9CXuTpi4u3t97tA6g@mail.gmail.com>',NULL),('<1460534939.5532851392834224640.JavaMail.nobody@rsj2rmd001.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-19 18:23:44',0,'2014-02-19 18:23:44',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting March\n	4, 2014 (F2F meeting)','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting March 4, 2014 (F2F meeting)\nHost: Alan Clark\nDate: Tuesday, March 4, 2014\nTime: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00)\nSession number: 926 584 365\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t7f162cbf8667e42cc4c43fcb840e31a8\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t8c379f2c453e2fe18a869125327e39a2\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb74dc31225bf9c2c3a45c14a0a7098b4\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=272441082&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 926 584 365\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140219/45b0d4a8/attachment.html>\n\n',NULL,NULL),('<146080370.61195264.1379999962231.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-23 22:19:22',-25200,'2013-09-24 05:19:22',NULL,'[openstack-dev] [LBaaS][Horizon] Subnet for VIP?','Hi,\n\nWhen adding a VIP for this pool, we suppose to specify the subnet which the VIP will be on. However, the Horizon UI forces us to provide an IP address for the VIP from the subnet which we used to create the pool. That subnet for pool is supposed to be the subnet for pool\'s members, not the subnet for the VIP.\n\nThis looks like a UI bug?\n\nThanks,\n-Kaiwei\n\n\n','<402001933.61192284.1379999566029.JavaMail.root@vmware.com>',NULL),('<1461774.q2K8NS2Zsv@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-08 16:19:30',39600,'2014-10-08 05:19:30',NULL,'[openstack-dev] [kolla] kolla, keystone, and endpoints (oh my!)','On Tue, 7 Oct 2014 10:27:44 PM Lars Kellogg-Stedman wrote:\n> On Tue, Oct 07, 2014 at 06:14:22PM +1100, Angus Lees wrote:\n> > What you haven\'t stated here is whether the catalog endpoints should be\n> > reachable outside the kubernetes minions or not.\n> \n> I thought I had been clear about that, but reading over the email it\n> looks like the part where I made that clear was actually already iny\n> my head.\n> \n> This solution was meant primarily to facilitate pod-to-pod\n> communication, particularly in cases where a service ends up moving\n> from one minion to another.\n\nAh cool.  In that case a solution will only be _required_ whenever we can\'t \nspecify the endpoint URL directly (from the usual k8s env vars). Assuming the \nsoftware we run in pods is scripted/automated, then we can also afford for our \nsolution to be a bit more verbose and unpleasant.  (Of course, we _do_ still \nneed a solution)\n\n> > 1.  Fixed hostname\n> > \n> > Add something like this to the start.sh wrapper script:\n> >  echo $SERVICE_HOST proxy >> /etc/hosts\n> > \n> > and then use http://proxy:$port/... etc as the endpoint in keystone\n> > catalog.\n> This was one of my first thoughts, but according to the\n> #google_containers folks, SERVICE_HOST is going away real soon now:\n> \n>   https://github.com/GoogleCloudPlatform/kubernetes/pull/1402\n> \n> There will be a per-service ip available, so we could still do\n> something similar.\n\nYep, exactly.  Having just read through \nhttps://github.com/GoogleCloudPlatform/kubernetes/issues/1107 it looks like \nall the options under consideration are trying to make a known hostname at \nleast as easy as the above.\n\nI humbly suggest we go with the known-hostname option, and adapt the precise \napproach as kubernetes/pull/1402-and-similar evolves.  (In particular, we\'ll \nprobably need per-service hostnames reasonably soon)\n\n> > Create a regular OpenStack loadbalancer and configure this (possibly\n> > publicly available) IP in keystone catalog.\n> > \n> > I _think_ this could even be a loadbalancer controlled by the neutron we\n> > just set up, assuming the the loadbalancer HA works without help and the\n> > nova<-> \n> > >neutron \"bootstrap\" layer was setup using regular k8s service env vars\n> > >and\n> > \n> > not the loadbalancer IPs.\n> \n> There\'s no guarantee that we\'re running Kubernetes on top of\n> openstack, and I don\'t think we could use Neutron deployed inside\n> kubernetes because we\'d want the LB in place for basic services like\n> keystone and the database server.\n\nMy thought was that we would use directly configured URLs (based on the usual \nk8s env vars) wherever possible.   The catalog endpoints are mostly used by \nend-user tools, and these of course can be delayed after the deployed neutron \nis functional.\n\nWhat I\'m unsure of, is if there is any openstack service which *must* use \nkeystone catalogs (rather than explicit URL configuration) to find other \nopenstack components.  I suspect there is no such service - or if there is \n(horizon?), it isn\'t required to create a functional neutron loadbalancer.\n\nI agree it\'s a bit mind-twisting, and that in itself is a disadvantage of this \noption.\n\n-- \n - Gus\n\n\n','<20141008022744.GB18248@redhat.com>',NULL),('<1461919355.34.1381039940748.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-06 06:12:20',0,'2013-10-06 06:12:20',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #29','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/29/>\n\n\n\n','<181525190.28.1380953539905.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1462358743.33188.1377840578132.JavaMail.root@mail.gslab.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-30 10:59:38',19800,'2013-08-30 05:29:38',NULL,'[Openstack] Fwd: Horizon(dashboard) Code modification.(adding new\n	forms)','\n\n----- Forwarded Message -----\nFrom: \"Priti Sarap\" <priti.sarap at gslab.com>\nTo: openstack at lists.openstack.org\nSent: Thursday, August 29, 2013 6:43:01 PM\nSubject: Horizon(dashboard) Code modification.(adding new forms)\n\nHii all,\n   I have added an Import button on Openstack API(in admin/images),clicking on which I get a \n   pop-up which ask for some values from user and it has a submit button \n   clicking on which flow goes on next page which is coming as a static page \n   but I want it as a pop up n for bringing it I added success url of pop-up page as url of \n   this next static page.I looked out all horizon code but it is not supported anywhere.Can anyone\n   please suggest me the solution.\n   \nRegards,\nPriti   \n\n\n','<150162012.31793.1377781980997.JavaMail.root@mail.gslab.com>',NULL),('<1462430571.64.1386741900552.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:05:00',0,'2013-12-11 06:05:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-docs-havana #2','See <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/2/changes>\n\nChanges:\n\n[edouard.thuleau] Fix OVS agent reclaims local VLAN\n\n[Salvatore Orlando] Ensure NVP API connection port is always an integer\n\n[zhhuabj] Support uncompressed ipv6 address and abbreviated ipv4 address\n\n[carl.baldwin] Creates multiple worker processes for API server\n\n[Akihiro Motoki] Mocking ryu plugin notifier in ryu plugin test\n\n[Akihiro Motoki] Sync openstack.common.local from oslo\n\n[twilson] Add vpnaas and debug filters to setup.cfg\n\n[flaper87] Sync rpc fix from oslo-incubator\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise7 in workspace <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/>\nCheckout:periodic-neutron-docs-havana / <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/> - hudson.remoting.Channel at 6e8cc7de:precise7\nUsing strategy: Default\nLast Built Revision: Revision 7d74411a43b55c9ac574fda4bca4ea77563e70ce (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/neutron\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/neutron\nCommencing build of Revision cec8127f0972d20646a8df49c13021174c346e27 (origin/stable/havana)\nChecking out Revision cec8127f0972d20646a8df49c13021174c346e27 (origin/stable/havana)\n[periodic-neutron-docs-havana] $ /bin/bash -xe /tmp/hudson2436790605842197775.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack neutron\n+ org=openstack\n+ project=neutron\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack neutron /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=neutron\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z neutron ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack neutron\n++ org=openstack\n++ project=neutron\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack neutron /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=neutron\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z neutron ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/neutron /opt/requirements/projects.txt\nopenstack/neutron\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/test-requirements.txt,> setuptools_git>=0.4\nvenv inst: <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/dist/neutron-jenkins.periodic.neutron.docs.havana.2.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-neutron-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-havana/precise7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-havana/precise7/2\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1462778023.8307157.1385466607646.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-11-26 06:50:07',-18000,'2013-11-26 11:50:07',NULL,'[Openstack-docs] OpenStack Docs Google Hangout Monday,\n December 2, 2013 at 03:00:00 UTC','----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Anne Gentle\" <anne at openstack.org>, openstack-docs at lists.openstack.org\n> Sent: Tuesday, November 26, 2013 3:21:06 AM\n> Subject: Re: [Openstack-docs] OpenStack Docs Google Hangout Monday, December 2, 2013 at 03:00:00 UTC\n> \n> On 11/26/2013 12:10 AM, Anne Gentle wrote:\n> > Hi all,\n> > I\'ve been wanting to get us chatting online as a final wrap-up to\n> > Icehouse planning, so I\'ve convinced Tom, Summer, and Stephen to join me\n> > in a Google Hangout next Sunday in my evening time, Summer and Tom\'s\n> > morning time.\n> > \n> > The idea is to pepper us with questions about the Summit, then discuss\n> > the Icehouse release and documentation plans. Here\'s an outline for the\n> > discussion, also on the wiki:\n> > \n> > Creating new CLI Reference listing commands and subcommands\n> > Moving API specs into project repos\n> > Creating OpenStack API Guide\n> > Documenting what types of content goes into each book\n> > Maintaining Install Guide\n> > Maintaining and revising Cloud Administrator Guide\n> > Prioritizing docs - integrated projects, training guides, DocImpact,\n> > reviews\n> > Anything else? Add it\n> > to\n> > https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Google_Hangout_for_Docs\n> > \n> > A few minutes before the scheduled time, I\'ll publish the Google On Air\n> > link from my annegentle at gmail.com <mailto:annegentle at gmail.com> account.\n> > For more info about Google On Air,\n> > see http://www.google.com/+/learnmore/hangouts/onair.html#tab0\n> > \n> > I hope you all can make it!\n> \n> That\'s 4am Monday morning my time - I doubt I\'ll make it,\n> \n> Andreas\n\nIndeed, and as I will be in the same time zone that day neither can I :).\n\n-Steve\n\n\n','<529459F2.40100@suse.com>',NULL),('<1462961421.2.1377169243613.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-22 11:00:43',0,'2013-08-22 11:00:43',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #12','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/12/>\n\n------------------------------------------\n[...truncated 21851 lines...]\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 5.573/5.573/5.573/0.000 ms\n++ cinder list\n++ grep ex-vol-68558724\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1377168261\n+ cinder create --display_name ex-vol-68558724 --display_description \'test volume: ex-vol-68558724\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-22T10:44:22.203597      |\n| display_description |     test volume: ex-vol-68558724     |\n|     display_name    |           ex-vol-68558724            |\n|          id         | 9a894216-df4d-4366-9703-d5369fb8bb0b |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-68558724 | grep available; do sleep 1; done\'\n| 9a894216-df4d-4366-9703-d5369fb8bb0b | available | ex-vol-68558724 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377168264\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-68558724\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 9a894216-df4d-4366-9703-d5369fb8bb0b | available | ex-vol-68558724 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=9a894216-df4d-4366-9703-d5369fb8bb0b\n+ die_if_not_set 165 VOL_ID \'Failure retrieving volume ID for ex-vol-68558724\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1377168265\n+ nova volume-attach c2cbfdf6-5c17-4d67-aaf1-a0f814141620 9a894216-df4d-4366-9703-d5369fb8bb0b /dev/vdb\nERROR:root:Could not find any typelib for GnomeKeyring\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | c2cbfdf6-5c17-4d67-aaf1-a0f814141620 |\n| id       | 9a894216-df4d-4366-9703-d5369fb8bb0b |\n| volumeId | 9a894216-df4d-4366-9703-d5369fb8bb0b |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-68558724 | grep in-use; do sleep 1; done\'\n| 9a894216-df4d-4366-9703-d5369fb8bb0b | in-use | ex-vol-68558724 |  1   |     None    |  False   | c2cbfdf6-5c17-4d67-aaf1-a0f814141620 |\n++ date +%s\n+ end_time=1377168269\n+ echo \'Completed volume-attach in 4 seconds\'\nCompleted volume-attach in 4 seconds\n++ cinder list\n++ grep ex-vol-68558724\n++ get_field -1\n++ head -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 9a894216-df4d-4366-9703-d5369fb8bb0b | in-use | ex-vol-68558724 |  1   |     None    |  False   | c2cbfdf6-5c17-4d67-aaf1-a0f814141620 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=c2cbfdf6-5c17-4d67-aaf1-a0f814141620\n+ die_if_not_set 179 VOL_ATTACH \'Failure retrieving ex-vol-68558724 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ c2cbfdf6-5c17-4d67-aaf1-a0f814141620 != c2cbfdf6-5c17-4d67-aaf1-a0f814141620 ]]\n++ date +%s\n+ start_time=1377168270\n+ nova volume-detach c2cbfdf6-5c17-4d67-aaf1-a0f814141620 9a894216-df4d-4366-9703-d5369fb8bb0b\nERROR:root:Could not find any typelib for GnomeKeyring\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-68558724 | grep available; do sleep 1; done\'\n| 9a894216-df4d-4366-9703-d5369fb8bb0b | available | ex-vol-68558724 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377168273\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1377168273\n+ cinder delete 9a894216-df4d-4366-9703-d5369fb8bb0b\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-68558724; do sleep 1; done\'\n| 9a894216-df4d-4366-9703-d5369fb8bb0b | deleting | ex-vol-68558724 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1377168276\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete c2cbfdf6-5c17-4d67-aaf1-a0f814141620\nERROR:root:Could not find any typelib for GnomeKeyring\n+ timeout 60 sh -c \'while nova list | grep -q c2cbfdf6-5c17-4d67-aaf1-a0f814141620; do sleep 1; done\'\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\nERROR:root:Could not find any typelib for GnomeKeyring\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\nERROR:root:Could not find any typelib for GnomeKeyring\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1594.geff800e.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpfbmnm9\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpq7eND3\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpgojBpB\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp_vB2GX\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2473 tests in 829.065s\nFAILED (id=0, failures=2, skips=68)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-152021-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-152021.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-152021/12/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<733264648.2.1377067564848.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1463071822.10900876.1400706638496.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-21 17:10:38',-14400,'2014-05-21 21:10:38',NULL,'[openstack-dev] [Neutron][L3][ To Learn VM prefix to have\n reachability in the cloud using routing protocol ..','----- Original Message -----\n> \n> \n> Hi,\n> \n> My Name is Keshava who was talking about using IGP to learn VM prefix and\n> advertise to have reachability within the cloud in the last Atlanta summit.\n> \n\nIs there a document that could explain the use cases for something like this?\n\n> Instead of running BGP below are the thoughts to use OSPF routing protocol\n> which support hierarchical network design also.\n> \n> Here are my thoughts about the same.\n> \n> \n> \n> 1. OSPF will be running in each of the Nodes under that TOR/switch for a\n> particular Area.\n> \n> 2. Tennant VM prefix needs to added as static route\n> \n> 3. Each of the Nodes will form adjacency with each other in that area.\n> \n> a. If it is broadcast network then of the OSPF router will become ?Designated\n> router/DR? on behalf all others in that area .\n> \n> 4. L-1 switch/Nodes acting as Area-border router ( ABR) will connect to\n> L2-switch which is Area-0.\n> \n> This will help for\n> \n> Route-aggregation,\n> \n> Avoid flooding of routes if any Node is going down.\n> \n> If any of the Node/Router is of higher/low capacity it is possible to say\n> ?forwarding option to other router? for egress traffic.\n> \n> \n> \n> Let us know peoples opinion about the same.\n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> \n> Thanks & regards,\n> \n> Keshava.A\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<891761EAFA335D44AD1FFDB9B4A8C063AE5477@G9W0733.americas.hpqcorp.net>',NULL),('<1463179101.18.1370844811636.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-10 06:13:31',0,'2013-06-10 06:13:31',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #61','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/61/>\n\n------------------------------------------\n[...truncated 1166 lines...]\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.01\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_api.TestApi.test_zero_initial_size\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 496, in test_zero_initial_size\n    response, content = http.request(path, \'POST\', headers=headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 89.14 secs:\n    26.06    TestScrubber.test_scrubber_app\n    20.46    TestScrubber.test_delayed_delete\n    14.48    TestGlanceControl.test_reload\n    14.19    TestGlanceControl.test_respawn\n    13.95    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1101 tests in 579.108s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.5\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python27.stable.grizzly.61\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.14\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.5\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.31\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.RkdIKkbsQT\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/61\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/61/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1463887443.348.1357258179610.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-04 00:09:39',0,'2013-01-04 00:09:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #95','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/95/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/95\n[SCP] Copying console log.\n\n\n','<1420571982.334.1357171495154.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1464058161.18.1382940762850.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-28 06:12:42',0,'2013-10-28 06:12:42',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #33','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/33/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54396d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54396d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50860d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50860d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-abae0b86-60d0-4a85-8c8e-6518eeec368b\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x2f237d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x2f237d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x2f237d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x2f237d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:12:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:12:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:12:05+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:12:05-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:12:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60a1950>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1ac52d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 88.04 secs:\n    25.53    TestScrubber.test_scrubber_app\n    20.16    TestScrubber.test_delayed_delete\n    14.44    TestGlanceControl.test_reload\n    14.08    TestGlanceControl.test_respawn\n    13.83    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 574.923s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.33\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.22\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.V7fMqHZSKr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/33/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise12/33\n[SCP] Copying console log.\n\n\n','<580815.11.1382767837747.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1464360370.44366984.1403787248824.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 08:54:08',-14400,'2014-06-26 12:54:08',NULL,'[openstack-dev] [NFV] Meeting summary 2014-06-26','Meeting summary\n\n        https://etherpad.openstack.org/p/nfv-meeting-agenda (russellb, 14:01:24)\n\n    review actions (russellb, 14:01:36)\n        https://github.com/sbauza/gerrit-dashboard-nfv (sgordon, 14:02:06)\n        http://bit.ly/1iFdldx (sgordon, 14:02:13)\n        ACTION: russellb to spin up a cloud VM for bauzas to host NFV dashboard script (russellb, 14:04:55)\n        https://github.com/sbauza/gerrit-dashboard-nfv (russellb, 14:06:08)\n        http://lists.openstack.org/pipermail/openstack-dev/2014-June/038556.html (russellb, 14:07:41)\n\n    blueprints (russellb, 14:16:50)\n        http://lists.openstack.org/pipermail/openstack-dev/2014-June/038475.html (sgordon, 14:23:00)\n        https://review.openstack.org/97716 (sgordon, 14:24:33)\n\n    Paris mid-cycle spring next week (russellb, 14:40:05)\n        https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 (russellb, 14:40:15)\n\n    open discussion (russellb, 14:40:48)\n        https://review.openstack.org/#/c/96138/ (sgordon, 14:44:33)\n        https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost (sgordon, 14:45:59)\n\nAction items\n\n    russellb to spin up a cloud VM for bauzas to host NFV dashboard script\n\nFull logs: http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-06-25-14.00.log.html\n\n\n','<1796607025.44364311.1403787127187.JavaMail.zimbra@redhat.com>',NULL),('<1464474.zedg3mfLNv@dblinov.sw.ru>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 22:45:17',14400,'2014-08-18 18:45:17',NULL,'[openstack-dev] I\'ve published parallels SDK','Hello!\n\nI\'ve published parallels-sdk:\n\nhttps://github.com/Parallels/parallels-sdk\n\n-- \nDmitry Guryanov\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140818/cfda33fe/attachment.html>\n\n',NULL,NULL),('<1465312486.14.1385533394820.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-27 06:23:14',0,'2013-11-27 06:23:14',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python26-stable-grizzly #67','See <https://jenkins02.openstack.org/job/periodic-cinder-python26-stable-grizzly/67/>\n\n\n\n',NULL,NULL),('<14658388.RJX01snU8Q@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-08 14:47:36',7200,'2014-07-08 12:47:36',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','Hi Joshua,\n\nYou asked a lot of questions. I will try to answer.\n\nLe lundi 7 juillet 2014, 17:41:34 Joshua Harlow a ?crit :\n> * Why focus on a replacement low level execution model integration instead\n> of higher level workflow library or service (taskflow, mistral... other)\n> integration?\n\nI don\'t know tasklow, I cannot answer to this question.\n\nHow do you write such code using taskflow?\n\n  @asyncio.coroutine\n  def foo(self):\n      result = yield from some_async_op(...)\n      return do_stuff(result)\n\n\n> * Was the heat (asyncio-like) execution model[1] examined and learned from\n> before considering moving to asyncio?\n\nI looked at Heat coroutines, but it has a design very different from asyncio.\n\nIn short, asyncio uses an event loop running somewhere in the background, \nwhereas Heat explicitly schedules the execution of some tasks (with \n\"TaskRunner\"), blocks until it gets the result and then stop completly its \n\"event loop\". It\'s possible to implement that with asyncio, there is for \nexample a run_until_complete() method stopping the event loop when a future is \ndone. But asyncio event loop is designed to run \"forever\", so various projects \ncan run tasks \"at the same time\", not only a very specific section of the code \nto run a set of tasks.\n\nasyncio is not only designed to schedule callbacks, it\'s also designed to \nmanager file descriptors (especially sockets). It can also spawn and manager \nsubprocessses. This is not supported by Heat scheduler.\n\nIMO Heat scheduler is too specific, it cannot be used widely in OpenStack.\n\n\n>   * A side-question, how do asyncio and/or trollius support debugging, do\n> they support tracing individual co-routines? What about introspecting the\n> state a coroutine has associated with it? Eventlet at least has\n> http://eventlet.net/doc/modules/debug.html (which is better than nothing);\n> does an equivalent exist?\n\nasyncio documentation has a section dedicated to debug:\nhttps://docs.python.org/dev/library/asyncio-dev.html\n\nasyncio.Task has get_stack() and print_stack() methods can be used to get the \ncurrent state of a task. I don\'t know if it is what you are looking for.\n\nI modified recently asyncio Task and Handle to save the traceback where they \nwere created, it\'s now much easier to debug code. asyncio now also logs \"slow \ncallbacks\" which may block the event loop (reduce the reactivity).\n\nRead: We are making progress to ease the development and debug asyncio code.\n\nI don\'t know exactly what you expect for debugging. However, there is no \n\"tracing\" feature\" in asyncio yet.\n\n\n> This is the part that I really wonder about. Since asyncio isn\'t just a\n> drop-in replacement for eventlet (which hid the async part under its\n> *black magic*), I very much wonder how the community will respond to this\n> kind of mindset change (along with its new *black magic*).\n\nI disagree with you, asyncio is not \"black magic\". It\'s well defined. The \nexecution of a coroutine is complex, but it doesn\'t use magic. IMO eventlet \ntask switching is more black magic, it\'s not possible to guess it just by \nreading the code.\n\nSorry but asyncio is nothing new :-( It\'s just a fresh design based on \nprevious projects.\n\nPython has Twisted since more than 10 years. More recently, Tornado came. Both \nsupport coroutines using \"yield\" (see @inlineCallbacks and toro). Thanks to \nthese two projects, there are already libraries which have an async API, using \ncoroutines or callbacks.\n\nThese are just the two major projects, they are much more projects, but they \nare smaller and younger.\n\nOther programming languages are also moving to asynchronous programming. Read \nfor example this article which lists some of them:\nhttps://glyph.twistedmatrix.com/2014/02/unyielding.html\n\n\n> * Is the larger python community ready for this?\n> \n> Seeing other responses for supporting libraries that aren\'t asyncio\n> compatible it doesn\'t inspire confidence that this path is ready to be\n> headed down. Partially this is due to the fact that its a completely new\n> programming model and alot of underlying libraries will be forced to\n> change to accommodate this (sqlalchemy, others listed in [5]...).\n\nThe design of the asyncio core is really simple, it\'s mostly based on \ncallbacks. Callbacks is an old concept, and many libraries already accept a \ncallback to send the result when they are done.\n\nIn asyncio, you can use loop.call_soon(callback) to schedule the execution of \na callback, and future.add_done_callback() to connect a future to a callback.\n\nOh by way, the core of Twisted and Tornado also uses callbacks. Using \ncallbacks makes you compatible with Twisted, Tornado and asyncio.\n\n\nasyncio already has projects compatible with it, see this list:\nhttps://code.google.com/p/tulip/wiki/ThirdParty\n\nThere are for example Redis, PostgreSQL and MongoDB drivers. There is also an \nAMQP implementation.\n\n\nYou are not forced to make your code async. You can run blocking code in \nthreads (a pool of threads) using loop.run_in_executor(). For example, DNS \nresolution is currently done like that (the socket.getaddrinfo() function is \nblocking). Or you also just block until you get the result, in some cases it \ndoes not impact performances (ex: CLI client waiting for the answer of a \nserver).\n\n\n> Along a related question,\n> seeing that openstack needs to support py2.x and py3.x will this mean that\n> trollius will be required to be used in 3.x (as it is the least common\n> denominator, not new syntax like \'yield from\' that won\'t exist in 2.x).\n> Does this mean that libraries that will now be required to change will be\n> required to use trollius (the pulsar[6] framework seemed to mesh these two\n> nicely); is this understood by those authors?\n\nIt *is* possible to write code working on asyncio and trollius:\nhttp://trollius.readthedocs.org/#write-code-working-on-trollius-and-tulip\n\nThey are different options for that. They are already projects supporting \nasyncio and trollius.\n\n\n> Is this the direction we\n> want to go down (if we stay focused on ensuring py3.x compatible, then why\n> not just jump to py3.x in the first place)?\n\nFYI OpenStack does not support Python 3 right now. I\'m working on porting \nOpenStack to Python 3, we made huge progress, but it\'s not done yet.\n\nAnyway, the new RHEL 7 release doesn\'t provide Python 3.3 in the default \nsystem, you have to enable the SCL repository (which provides Python 3.3). And \nPython 2.7 or even 2.6 is still used in production.\n\nI would also prefer to use directly \"yield from\" and \"just\" drop Python 2 \nsupport. But dropping Python 2 support is not going to happen before at least \n2 years.\n\nWe should port OpenStack to Python 3 right now!\nhttp://techs.enovance.com/6521/openstack_python3\n\nStatus of the port to Python 3:\nhttps://wiki.openstack.org/wiki/Python3\n\n\nI hope that I replied to some of your questions.\n\nVictor\n\n\n','<CFE0292E.66B04%harlowja@yahoo-inc.com>',NULL),('<1467318408.77.1367820835916.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-06 06:13:55',0,'2013-05-06 06:13:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #26','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/26/>\n\n------------------------------------------\n[...truncated 1329 lines...]\n    test_create_endpoint                                         OK    1.06\n    test_create_endpoint_400                                     OK    1.04\n    test_create_endpoint_on_v2                                   OK    1.73\n    test_create_service                                          OK    1.05\n    test_delete_endpoint                                         OK    1.03\n    test_delete_service                                          OK    0.97\n    test_get_endpoint                                            OK    0.97\n    test_get_service                                             OK    0.99\n    test_list_endpoints                                          OK    0.96\n    test_list_endpoints_xml                                      OK    0.95\n    test_list_services                                           OK    0.97\n    test_list_services_xml                                       OK    0.97\n    test_update_endpoint                                         OK    0.99\n    test_update_service                                          OK    0.99\nIdentityTestCase\n    test_add_user_to_group                                       OK    0.98\n    test_check_user_in_group                                     OK    2.50\n    test_create_credential                                       OK    1.14\n    test_create_domain                                           OK    1.10\n    test_create_group                                            OK    1.09\n    test_create_project                                          OK    1.09\n    test_create_role                                             OK    1.08\n    test_create_user                                             OK    1.05\n    test_crud_group_domain_role_grants                           OK    2.34\n    test_crud_group_project_role_grants                          OK    2.30\n    test_crud_user_domain_role_grants                            OK    2.26\n    test_crud_user_project_role_grants                           OK    1.62\n    test_delete_credential                                       OK    1.01\n    test_delete_domain                                           OK    1.43\n    test_delete_enabled_domain_fails                             OK    0.96\n    test_delete_group                                            OK    0.98\n    test_delete_project                                          OK    1.01\n    test_delete_role                                             OK    1.00\n    test_delete_user                                             OK    2.13\n    test_disable_domain                                          OK    2.54\n    test_get_credential                                          OK    0.94\n    test_get_domain                                              OK    2.18\n    test_get_group                                               OK    1.13\n    test_get_project                                             OK    1.12\n    test_get_role                                                OK    1.09\n    test_get_user                                                OK    1.08\n    test_list_credentials                                        OK    1.09\n    test_list_credentials_xml                                    OK    1.05\n    test_list_domains                                            OK    1.04\n    test_list_domains_xml                                        OK    0.98\n    test_list_groups                                             OK    1.32\n    test_list_groups_xml                                         OK    1.03\n    test_list_projects                                           OK    1.00\n    test_list_projects_xml                                       OK    1.00\n    test_list_roles                                              OK    1.00\n    test_list_roles_xml                                          OK    0.97\n    test_list_users                                              OK    1.02\n    test_list_users_in_group                                     OK    1.32\n    test_list_users_xml                                          OK    0.99\n    test_remove_user_from_group                                  OK    1.33\n    test_update_credential                                       OK    1.00\n    test_update_domain                                           OK    2.24\n    test_update_group                                            OK    1.16\n    test_update_project                                          OK    1.15\n    test_update_role                                             OK    1.12\n    test_update_user                                             OK    1.10\nPolicyTestCase\n    test_create_policy                                           OK    1.08\n    test_delete_policy                                           OK    1.08\n    test_get_policy                                              OK    1.06\n    test_list_policies                                           OK    1.04\n    test_list_policies_xml                                       OK    1.04\n    test_update_policy                                           OK    1.02\nIdentityTestProtectedCase\n    test_get_user_protected_match_id                             OK    0.99\n    test_list_filtered_domains                                   OK    1.57\n    test_list_groups_protected_by_domain                         OK    1.31\n    test_list_groups_protected_by_domain_and_filtered            OK    1.00\n    test_list_users_filtered_by_domain                           OK    1.02\n    test_list_users_protected_by_domain                          OK    1.29\n    test_list_users_unprotected                                  OK    0.98\n    test_multiple_filters                                        OK    0.98\nVersionTestCase\n    test_admin_version_v2                                        OK    0.15\n    test_admin_version_v3                                        OK    0.16\n    test_admin_versions                                          OK    0.11\n    test_public_version_v2                                       OK    1.35\n    test_public_version_v3                                       OK    0.12\n    test_public_versions                                         OK    0.11\nApplicationTest\n    test_query_string_available                                  OK    0.01\n    test_render_response                                         OK    0.00\n    test_render_response_custom_headers                          OK    0.01\n    test_render_response_custom_status                           OK    0.00\n    test_render_response_no_body                                 OK    0.00\n    test_response_content_type                                   OK    0.01\n\n======================================================================\nERROR: Make sure both public and admin API work with ipv6.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_ipv6.py\",> line 43, in test_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 18.59 secs:\n    5.19    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    4.50    TestTokenRevoking.test_group_membership_changes_revokes_token\n    3.27    TestTrustAuth.test_trust_crud\n    2.91    TestTrustAuth.test_v3_v2_intermix_trustor_not_in_default_domaini_failed\n    2.72    TestTokenAPIs.test_v3_v2_intermix_non_default_project_failed\n----------------------------------------------------------------------\nRan 1272 tests in 386.743s\n\nFAILED (SKIP=82, errors=3)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.26\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=68\n+ \'[\' 68 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.i9l049cNrk\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/26\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/26/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<613765144.57.1367734497268.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1467426836.43.1352937989708.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-15 00:06:29',0,'2012-11-15 00:06:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #93','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/93/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.35\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.06\n    test_public_versions                                        OK  0.05\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 18.686s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.16 secs:\n    2.41       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    2.27       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.35       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.1\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at e39351ec65bb00b33d3d57785976daefe9d27c2c#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 6b8f966364d917e61f5011090b28ae7456b76e71#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/93\n[SCP] Copying console log.\n\n\n','<496430442.13.1352851489070.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1467876968.4927391.1395419142607.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-21 12:25:42',-14400,'2014-03-21 16:25:42',NULL,'[openstack-dev] [TripleO] test environment requirements','\n\n----- Original Message -----\n> From: \"Robert Collins\" <robertc at robertcollins.net>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, March 13, 2014 5:51:30 AM\n> Subject: [openstack-dev] [TripleO] test environment requirements\n> \n> So we already have pretty high requirements - its basically a 16G\n> workstation as minimum.\n> \n> Specifically to test the full story:\n>  - a seed VM\n>  - an undercloud VM (bm deploy infra)\n>  - 1 overcloud control VM\n>  - 2 overcloud hypervisor VMs\n> ====\n>    5 VMs with 2+G RAM each.\n> \n> To test the overcloud alone against the seed we save 1 VM, to skip the\n> overcloud we save 3.\n> \n> However, as HA matures we\'re about to add 4 more VMs: we need a HA\n> control plane for both the under and overclouds:\n>  - a seed VM\n>  - 3 undercloud VMs (HA bm deploy infra)\n>  - 3 overcloud control VMs (HA)\n>  - 2 overcloud hypervisor VMs\n> ====\n>    9 VMs with 2+G RAM each == 18GB\n> \n> What should we do about this?\n> \n> A few thoughts to kick start discussion:\n>  - use Ironic to test across multiple machines (involves tunnelling\n> brbm across machines, fairly easy)\n>  - shrink the VM sizes (causes thrashing)\n>  - tell folk to toughen up and get bigger machines (ahahahahaha, no)\n>  - make the default configuration inline the hypervisors on the\n> overcloud with the control plane:\n>    - a seed VM\n>    - 3 undercloud VMs (HA bm deploy infra)\n>    - 3 overcloud all-in-one VMs (HA)\n>   ====\n>      7 VMs with 2+G RAM each == 14GB\n> \n> \n> I think its important that we exercise features like HA and live\n> migration regularly by developers, so I\'m quite keen to have a fairly\n> solid systematic answer that will let us catch things like bad\n> firewall rules on the control node preventing network tunnelling\n> etc...\n\nI\'m all for supporting HA development and testing within devtest. I\'m *against* forcing it on all users as a default.\n\nI can imaging wanting to cut corners and have configurations flexible on both ends (undercloud and overcloud). I may for example deploy a single all-in-one undercloud when I\'m testing overcloud HA. Or vice versa.\n\nI think I\'m one of the few (if not the only) developer who uses almost exclusive baremetal (besides seed VM) when test/developing TripleO. Forcing users who want to do this to have 6-7 real machines is a bit much I think. Arguably wasteful even. By requiring more machines to run through devtest you actually make it harder for people to test it on real hardware which is usually harder to come by. Given deployment on real bare metal is sort of the point or TripleO I\'d very much like to see more developers using it rather than less.\n\nSo by all means lets support HA... but lets do it in a way that is configurable (i.e. not forcing people to be wasters)\n\nDan\n\n> e.g. we benefit the more things are split out like scale\n> deployments are. OTOH testing the micro-cloud that folk may start with\n> is also a really good idea....\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ0YSnYviesuVXfeJi2qUH+0zj1-qDOz-Dvrp4eUXWsj9Q@mail.gmail.com>',NULL),('<1467F3A7-04BA-445B-A2BE-9799D2EA2990@it.uu.se>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-11-09 13:13:54',3600,'2011-11-09 12:13:54',NULL,'[Openstack-operators] Problem send HTTP GET request.','Hi,\n\nI am trying to get the object from Swift store using GET request  \nheader but facing some problem,\n\nI read from the following document\n\nhttp://docs.openstack.org/bexar/openstack-object-storage/developer/content/ch03s03.html\n\nThat the header should look like this\n\nGET /<api version>/<account>/<container>/<object> HTTP/1.1\n   Host: storage.swiftdrive.com\n   X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb\n\nI did the same and make my GET request something like this\n\n----------------------------------------------------------------------------------\nGET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nAuthorization: AWS system:root:VTbBHyLrCdLnxClvd1bVFZcLpy8=\n\n----------------------------------------------------------------------------------\n\nNot that the last line is empty right after the Authentication. But it  \njust hangs. no answer form the server. I try to change the header to  \nget it working but no success :-( . Try-4 is interesting.\n\nFollowing are my tries..\n\nTry -1\n\n----------------------------------------------------------------------------------\nGET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nAuthorization: AWS system:root:yR7OHVFGgsZ4xHJp7RKHv9CuNtY=\n\n\n----------------------------------------------------------------------------------\nNow two empty line in the end. and I got the following response.\n\nHTTP/1.1 403 Forbidden\nContent-Type: text/xml; charset=UTF-8\nContent-Length: 124\nDate: Wed, 09 Nov 2011 11:47:47 GMT\n\n\nTry-2\n\n----------------------------------------------------------------------------------\nGET /v1.0/root/rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nAuthorization: AWS system:root:R9She9vkYVXQszVMfDqaeTNtUhQ=\n\n----------------------------------------------------------------------------------\nchange account from system:root to root (I don\'t know why but just  \nwant to try) ....\n\nHTTP/1.1 403 Forbidden\nContent-Type: text/xml; charset=UTF-8\nContent-Length: 124\nDate: Wed, 09 Nov 2011 11:47:47 GMT\n\n\nTry-3\n\n----------------------------------------------------------------------------------\nGET /v1.0/system:root/rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nDate: Wed, 09 Nov 2011 12:03:06 GMT\nRange: bytes=0-3\nAuthorization: AWS system:root:pHhOqVriW4zNmBW9MO1a7rNhHjI=\n\n\n----------------------------------------------------------------------------------\n\nHTTP/1.1 403 Forbidden\nContent-Type: text/xml; charset=UTF-8\nContent-Length: 124\nDate: Wed, 09 Nov 2011 11:47:47 GMT\n\n\nTry-4\n\n----------------------------------------------------------------------------------\nGET /rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nDate: Wed, 09 Nov 2011 12:04:57 GMT\nRange: bytes=0-3\nAuthorization: AWS system:root:oQX68HKwnH1OnBJhTmHGz3cm4b4=\n\n\n----------------------------------------------------------------------------------\nI have removed the version and the account details  and then at least  \nthe request message get changed. No more forbidden response. But now  \nits \"206 Partial Content\" and after getting the headers  the read  \nbytes are 0.\n\n\nHTTP/1.1 206 Partial Content\nn: 44\nline: Last-Modified: Tue, 01 Nov 2011 16:13:21 GMT\nn: 17\nline: Content-Length: 4\nn: 38\nline: Etag: f3e0c75e57766c5581a6978e2b70698f\nn: 38\nline: Content-Type: application/octet-stream\nn: 35\nline: Date: Wed, 09 Nov 2011 12:01:30 GMT\nn: 0\nline:\nn: 4\nline: root\nn: 0\nline:\n\nThen I send only HEAD request without version and account and that  \nruns successfully\n\n------------------------------------------------------------------------------------------\nHEAD /rootContainer/eventdata.root HTTP/1.1\nHost: swift.uppmax.se\nDate: Wed, 09 Nov 2011 12:14:11 GMT\nAuthorization: AWS system:root:dAWDu4I8SJyY02HEIirYejDWn2w=\n\n\n------------------------------------------------------------------------------------------\n\ngDebug Header: HTTP/1.1 200 OK\ngDebug Header: Last-Modified: Tue, 01 Nov 2011 16:13:21 GMT\ngDebug Header: Content-Length: 13\ngDebug Header: Etag: f3e0c75e57766c5581a6978e2b70698f\ngDebug Header: Content-Type: text/plain\ngDebug Header: Date: Wed, 09 Nov 2011 12:10:45 GMT\n\n\n\nIf I use command line tool everything is working fine. Can someone  \nplease point out what is wrong or how should I modify things.\n\nThanks.\n\n\nSalman Zubair Toor\nPh.Lic. Scientific Computing\nPh.D candidate\nDivision of Scientific Computing\nUppsala University, Sweden\nsalman.toor at it.uu.se\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111109/5fa05299/attachment.html>\n\n',NULL,NULL),('<1468583786.67.1367736467819.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-05 06:47:47',0,'2013-05-05 06:47:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #25','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/25/>\n\n------------------------------------------\n[...truncated 4554 lines...]\n    test_default_security_group                                  OK    0.28\n    test_default_security_group_rules                            OK    0.34\n    test_delete_default_security_group_fail                      OK    0.21\n    test_delete_security_group                                   OK    0.22\n    test_get_security_group                                      OK    0.31\n    test_list_ports_security_group                               OK    0.39\n    test_list_security_group_rules                               OK    0.33\n    test_list_security_group_rules_with_pagination               OK    0.33\n    test_list_security_group_rules_with_pagination_reverse       OK    0.35\n    test_list_security_group_rules_with_sort                     OK    2.55\n    test_list_security_groups                                    OK    0.37\n    test_list_security_groups_with_pagination                    OK    0.38\n    test_list_security_groups_with_pagination_reverse            OK    0.40\n    test_list_security_groups_with_sort                          OK    0.35\n    test_update_port_remove_security_group_empty_list            OK    0.44\n    test_update_port_remove_security_group_none                  OK    0.44\n    test_update_port_with_multiple_security_groups               OK    0.49\n    test_update_port_with_security_group                         OK    0.48\nActionExtensionTest\n    test_extended_action_for_adding_extra_data                   OK    0.20\n    test_extended_action_for_deleting_extra_data                 OK    0.04\n    test_returns_404_for_non_existent_action                     OK    0.03\n    test_returns_404_for_non_existent_resource                   OK    0.02\nExtensionControllerTest\n    test_extension_can_be_accessed_by_alias                      OK    0.04\n    test_index_gets_all_registerd_extensions                     OK    0.02\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionControllerTestXML\n    test_extension_can_be_accessed_by_alias                      OK    0.02\n    test_index_gets_all_registerd_extensions                     OK    0.02\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionManagerTest\n    test_invalid_extensions_are_not_registered                   OK    0.00\nPluginAwareExtensionManagerTest\n    test_extension_loaded_for_non_core_plugin                    OK    0.00\n    test_extensions_are_loaded_for_plugin_with_expected_interfaceOK    0.00\n    test_extensions_are_not_loaded_for_plugins_unaware_of_extensionsOK    0.00\n    test_extensions_expecting_quantum_plugin_interface_are_loadedOK    0.00\n    test_extensions_not_loaded_for_plugin_without_expected_interfaceOK    0.00\n    test_extensions_without_need_for__plugin_interface_are_loadedOK    0.00\n    test_unsupported_extensions_are_not_loaded                   OK    0.00\nRequestExtensionTest\n    test_edit_previously_uneditable_field                        OK    0.02\n    test_extend_get_resource_response                            OK    0.02\n    test_get_resources                                           OK    0.06\n    test_headers_can_be_extended                                 OK    0.02\nResourceExtensionTest\n    test_exceptions_notimplemented                               OK    0.07\n    test_plugin_prefix_with_parent_resource                      OK    0.08\n    test_resource_can_be_added_as_extension                      OK    0.02\n    test_resource_ext_for_formatted_req_on_custom_collection_actionOK    0.02\n    test_resource_ext_for_nested_resource_custom_collection_actionOK    0.02\n    test_resource_ext_with_custom_member_action_gets_plugin_prefixOK    0.03\n    test_resource_extension_for_delete_custom_collection_action  OK    0.01\n    test_resource_extension_for_get_custom_collection_action     OK    0.01\n    test_resource_extension_for_post_custom_collection_action    OK    0.01\n    test_resource_extension_for_put_custom_collection_action     OK    0.01\n    test_resource_extension_with_custom_member_action            OK    0.02\n    test_resource_extension_with_custom_member_action_and_attr_mapOK    0.04\n    test_resource_gets_prefix_of_plugin                          OK    2.15\n    test_returns_404_for_non_existent_extension                  OK    0.01\nIptablesFirewallTestCase\n    test_defer_apply                                             OK    0.01\n    test_filter_defer_with_exception                             OK    0.01\n    test_filter_ipv4_egress                                      OK    0.01\n    test_filter_ipv4_egress_icmp                                 OK    0.01\n    test_filter_ipv4_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv4_egress_prefix                               OK    0.01\n    test_filter_ipv4_egress_tcp                                  OK    0.01\n    test_filter_ipv4_egress_tcp_mport                            OK    0.01\n    test_filter_ipv4_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_tcp_port                             OK    0.02\n    test_filter_ipv4_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv4_egress_udp                                  OK    0.01\n    test_filter_ipv4_egress_udp_mport                            OK    0.01\n    test_filter_ipv4_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_udp_port                             OK    0.01\n    test_filter_ipv4_egress_udp_prefix                           OK    0.01\n    test_filter_ipv4_ingress                                     OK    0.01\n    test_filter_ipv4_ingress_icmp                                OK    0.01\n    test_filter_ipv4_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv4_ingress_prefix                              OK    0.01\n    test_filter_ipv4_ingress_tcp                                 OK    0.02\n    test_filter_ipv4_ingress_tcp_mport                           OK    0.02\n    test_filter_ipv4_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_tcp_port                            OK    0.02\n    test_filter_ipv4_ingress_tcp_prefix                          OK    0.02\n    test_filter_ipv4_ingress_udp                                 OK    0.01\n    test_filter_ipv4_ingress_udp_mport                           OK    0.01\n    test_filter_ipv4_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_udp_port                            OK    0.01\n    test_filter_ipv4_ingress_udp_prefix                          OK    0.01\n    test_filter_ipv6_egress                                      OK    0.01\n    test_filter_ipv6_egress_icmp                                 OK    0.01\n    test_filter_ipv6_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv6_egress_prefix                               OK    0.01\n    test_filter_ipv6_egress_tcp                                  OK    0.01\n    test_filter_ipv6_egress_tcp_mport                            OK    0.01\n    test_filter_ipv6_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_tcp_port                             OK    0.01\n    test_filter_ipv6_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv6_egress_udp                                  OK    0.01\n    test_filter_ipv6_egress_udp_mport                            OK    0.01\n    test_filter_ipv6_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_udp_port                             OK    0.01\n    test_filter_ipv6_egress_udp_prefix                           OK    0.01\n    test_filter_ipv6_ingress                                     OK    0.01\n    test_filter_ipv6_ingress_icmp                                OK    0.01\n    test_filter_ipv6_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv6_ingress_prefix                              OK    0.01\n    test_filter_ipv6_ingress_tcp                                 OK    0.01\n    test_filter_ipv6_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv6_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_tcp_port                            OK    0.01\n    test_filter_ipv6_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv6_ingress_udp                                 OK    0.01\n    test_filter_ipv6_ingress_udp_mport                           OK    0.01\n    test_filter_ipv6_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_udp_port                            OK    0.01\n    test_filter_ipv6_ingress_udp_prefix                          OK    0.01\n    test_prepare_port_filter_with_no_sg                          OK    0.01\n    test_remove_unknown_port                                     OK    0.01\n    test_update_delete_port_filter                               OK    0.01\nIptablesManagerStateFulTestCase\n    test_add_and_remove_chain                                    OK    0.00\n    test_add_filter_rule                                         OK    0.00\n    test_add_nat_rule                                            OK    0.00\n    test_add_rule_to_a_nonexistent_chain                         OK    0.00\n    test_binary_name                                             OK    0.01\n    test_get_chanin_name                                         OK    0.00\n    test_remove_nonexistent_chain                                OK    0.00\n    test_remove_nonexistent_rule                                 OK    0.00\nIptablesManagerStateLessTestCase\n    test_nat_not_found                                           OK    0.00\nTestBasicRouterOperations\n    testAgentAddExternalGateway                                  OK    0.02\n    testAgentAddFloatingIP                                       OK    0.02\n    testAgentAddInternalNetwork                                  OK    0.02\n    testAgentCreate                                              OK    0.01\n    testAgentRemoveExternalGateway                               OK    0.02\n    testAgentRemoveFloatingIP                                    OK    0.02\n    testAgentRemoveInternalNetwork                               OK    0.02\n    testAgentRoutingTableUpdated                                 OK    0.01\n    testAgentRoutingTableUpdatedNoNameSpace                      OK    0.01\n    testDestroyNamespace                                         OK    0.01\n    testDestroyNamespaceWithRouterId                             OK    2.17\n    testProcessRouter                                            OK    0.03\n    testRouterInfoCreate                                         OK    0.01\n    testRoutersWithAdminStateDown                                OK    0.01\n    testRoutesUpdated                                            OK    0.01\n    testRoutesUpdatedNoNamespace                                 OK    0.01\n    testSingleLoopRouterRemoval                                  OK    0.03\nTestL3AgentEventHandler\n    test_spawn_metadata_proxy                                    OK    0.01\nL3NatDBTestCase\n    test_create_external_network_admin_suceeds                   OK    0.21\n    test_create_external_network_non_admin_fails                 OK    0.15\n    test_create_floating_non_ext_network_returns_400             OK    0.29\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.14\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.14\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.13\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.53\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.52\n    test_create_port_external_network_admin_suceeds              OK    0.46\n    test_create_port_external_network_non_admin_fails            OK    0.31\n    test_floating_ip_direct_port_delete_returns_409              OK    3.01\n    test_floatingip_crd_ops                                      OK    0.77\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    0.73\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    0.83\n    test_floatingip_list_with_pagination                         OK    3.10\n    test_floatingip_list_with_pagination_reverse                 OK    0.76\n    test_floatingip_list_with_port_id                            OK    0.81\n    test_floatingip_list_with_sort                               OK    0.97\n    test_floatingip_port_delete                                  OK    1.08\n    test_floatingip_update                                       Build timed out (after 30 minutes). Marking the build as failed.\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n++ rm -rf /tmp/tmp.0TCwcSnL5B\n[SCP] Connecting to static.openstack.org\nBabel==0.9.6\nJinja2==2.6\nMako==0.8.0\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==1.3.3\nalembic==0.5.0\namqplib==0.6.1\nanyjson==0.3.3\nargparse==1.2.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\nconfigobj==4.7.2\ncoverage==3.6\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkombu==1.0.4\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.3.3\nprettytable==0.7.2\npyparsing==1.5.7\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-subunit==0.0.11\npyudev==0.16.1\nquantum==jenkins.periodic.quantum.python26.stable.grizzly.25\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\ntermcolor==1.1.0\ntestrepository==0.0.15\ntesttools==0.9.31\nwsgiref==0.1.2\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/25\n[SCP] Copying console log.\n\n\n','<464679749.46.1367650068749.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1468919285.105.1384149701386.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-11 06:01:41',0,'2013-11-11 06:01:41',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #59','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/59/>\n\n\n\n','<1834672532.102.1384063327579.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1468cd63.000019dc.0000006f@VMWARE-5KNQC8NC.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-27 14:53:56',-28800,'2012-11-27 22:53:56',NULL,'[openstack-dev] 答复:  答复: 答复: [Quantum] [LBaaS] Health Monitor Failure Detection','I?m pretty sure that Haproxy doesn?t support multiple health_monitors\nper pool.  If the driver is Haproxy, we should validate this limitation.\nIt should be straightforward to map the Haproxy pool status to the very\nsingle health_monitor associated with it.\n\n\n\nThanks\n\nLeon\n\n???: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]\n????: 2012?11?27? 14:33\n???: OpenStack Development Mailing List\n??: Re: [openstack-dev] ??: ??: [Quantum] [LBaaS] Health Monitor\nFailure Detection\n\n\n\nHi Ilya,\n\n\n\n1) It is not an option to use \"GET /members/{member_id}\" for retrieving\nhealth status, since it needs to call the driver/device (and thus become\nasynchronous). I vote for a separate method that retrieves health data,\nactually it may be similar to \"get_stats\".\n\n\n\nHealth status is not the only ?dynamic?/read-only attribute. The\n?status? attribute of VIP, pool, etc. can change at any time, so does a\nmember?s health. It would complicate the API to separate calls for have\n?static? attributes versus ?dynamic? ones of an entity. So, either the\nGET should be serviced by the driver like the other calls, or there needs\nto be a way between the plugin and the driver to update these dynamic (or\noperational) attributes of entities in the DB.\n\n\n\n2) Not all load balancers able to map the health status back to health\nmonitor (HAProxy is an example). We may consider the following response:\n\n{\n\n    \"status\": \"FAIL\",\n\n    \"ext_code\": \"L4_CON\",\n\n    \"details\": \"Connection refused (tcp rst)\",\n\n    \"health_monitor_id\": \"f3eeab00-8367-4524-b662-55e64d4cacb5\"\n\n}\n\nwhere attributes \'ext_code\' and \'health_monitor_id\' are optional.\n\n\n\nIlya, can you first confirm whether HA-Proxy can support several health\nmonitors per pool or not? If it can support only one, then the mapping is\nobvious, no?\n\n\n\nYoucef\n\n\n\nFrom: Ilya Shakhat [mailto:ishakhat at mirantis.com]\nSent: Tuesday, November 27, 2012 10:35 AM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] ??: ??: [Quantum] [LBaaS] Health Monitor\nFailure Detection\n\n\n\nMy 2 notes on the topic :)\n\n1) It is not an option to use \"GET /members/{member_id}\" for retrieving\nhealth status, since it needs to call the driver/device (and thus become\nasynchronous). I vote for a separate method that retrieves health data,\nactually it may be similar to \"get_stats\".\n\n2) Not all load balancers able to map the health status back to health\nmonitor (HAProxy is an example). We may consider the following response:\n\n{\n\n    \"status\": \"FAIL\",\n\n    \"ext_code\": \"L4_CON\",\n\n    \"details\": \"Connection refused (tcp rst)\",\n\n    \"health_monitor_id\": \"f3eeab00-8367-4524-b662-55e64d4cacb5\"\n\n}\n\nwhere attributes \'ext_code\' and \'health_monitor_id\' are optional.\n\n\n\nThanks,\n\nIlya\n\n\n\n2012/11/27 Leon Cui <lcui at vmware.com>\n\nYoucef/Peter,\n\nYes it sounds good to me.\n\n\n\nThanks\n\nLeon\n\n???: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]\n????: 2012?11?26? 17:20\n\n\n???: OpenStack Development Mailing List\n\n??: Re: [openstack-dev] ??: [Quantum] [LBaaS] Health Monitor Failure\nDetection\n\n\n\nHi Leon,\n\n\n\nYes, as Peter pointed out, user needs to know which health check has\nfailed. Whether we want this information to appear in the existing ?GET\n/members/{member_id}? or whether we want to have a new API for ?GET\n/members/{member_id}/details?, I?m fine with both. Currently however, we\ndo not have ?/details? sub-resource for any other resource (it?s not a\npattern we are following in the API), so I see introducing it just for\nthis case may be an overkill.\n\n\n\nThanks\n\nYoucef\n\n\n\nFrom: Mellquist, Peter [mailto:peter.mellquist at hp.com]\nSent: Monday, November 26, 2012 2:58 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] ??: [Quantum] [LBaaS] Health Monitor\nFailure Detection\n\n\n\nHi Leon,\n\n\n\nThe admin / user needs to know the specific health monitor which has\nfailed so that they may take appropriate action to fix the member with the\nfailed health check. If we not provide this detail, then the root cause on\nwhy the member has gone ?inactive? will be unknown. Most JSON parsers\nallow parsing fields of interest and ignoring others so it should not be\nan issue for clients who are not interested in health monitors but ? that\nbeing said as we continue to work out important use cases, like this one,\nwe may find that a refactoring of the REST resources may be needed. I see\nthis as an iterative process.\n\n\n\nThanks,\n\nPeter.\n\n\n\nFrom: Leon Cui [mailto:lcui at vmware.com]\nSent: Thursday, November 22, 2012 4:49 PM\nTo: \'OpenStack Development Mailing List\'\nSubject: [openstack-dev] ??: [Quantum] [LBaaS] Health Monitor Failure\nDetection\n\n\n\nHi Peter and Youcef,\n\nShowing the health monitor status details in member might be too much for\nuser.  In most time, user (and Mgmt UI) might be only interested in the\noverall pool/member status unless user wants to drill down to the details.\nMy concern is that we are adding more and more details in the top resource\nGET API which add more payload and complex to parse. I?m wondering if we\ncan add a separate API GET /resource/<resource_id>/details which can\nexpose more detailed information for each resource.\n\n\n\nJust my 2 cents.\n\n\n\nThanks\n\nLeon\n\n???: Mellquist, Peter [mailto:peter.mellquist at hp.com]\n????: 2012?11?22? 5:06\n???: OpenStack Development Mailing List\n??: Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure\nDetection\n\n\n\nHi Youcef,\n\n\n\nThis looks like it will work fine. I like this since it shows the state of\nall the monitors for the member.\n\n\n\nPeter.\n\n\n\n\n\nFrom: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]\nSent: Wednesday, November 21, 2012 12:34 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [Quantum] [LBaaS] Health Monitor Failure\nDetection\n\n\n\nHi Peter,\n\n\n\nYes you bring up a good point that we missed in the API. Usually in LB\nproducts when user displays the member, then the monitors used to monitor\nthe member and their status are also displayed. We can adopt the same\napproach as follows:\n\n\n\n\"member\" :  {\n\n                \"id\":\"c57f581b-c834-408f-93fa-30543cf30618\",\n\n                \"tenant_id\": \"310df60f-2a10-4ee5-9554-98393092194c\",\n\n                \"pool_id\": \"cfc6589d-f949-4c66-99d2-c2da56ef3764\",\n\n                \"address\": \"192.168.224.31\",\n\n                \"port\": 8080,\n\n               \"weight\" : 1,\n\n                \"admin_state_up\" : true,\n\n                \"status\" : \"INACTIVE\",\n\n                \"health_monitors_status\" : [\n\n                     {\n\n                        \"health_monitor_id\" :\n\"f3eeab00-8367-4524-b662-55e64d4cacb5\",\n\n                        \"status\" : \"FAIL\"\n\n                     },\n\n                     {\n\n                        \"health_monitor_id\" :\n\"70995ff0-341a-11e2-81c1-0800200c9a66\",\n\n                        \"status\" : \"SUCCESS\"\n\n                     }\n\n\n\n                ]\n\n              }\n\n\n\nWould this  be acceptable?\n\n\n\nYoucef\n\n\n\n\n\nFrom: Mellquist, Peter [mailto:peter.mellquist at hp.com]\nSent: Wednesday, November 21, 2012 11:17 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] Quantum LBaaS Health Monitor Failure Detection\n\n\n\nHi LBaaS?ers,\n\n\n\nWith the current capability to associate multiple health monitors with a\npool, it does not seem possible to see which specific health monitor has\ndetected an issue. For example, If I have a PING and HTTP monitor and the\nHTTP monitor fails how can the user or admin have visibility into the\nspecific failure?\n\n?When a pool has several monitors associated with it, each member of the\npool is monitored by all these monitors. If any monitor declares the\nmember as unhealthy, then the member status is changed to INACTIVE and the\nmember won\'t participate in its pool\'s load balancing. In other words, ALL\nmonitors must declare the member to be healthy for it to stay ACTIVE. ?\n\nMember status changing to INACTIVE does not describe the reason why.\nWould  it make sense to have a member status reason with the reference to\nthe health monitor id in this case? We could then see which health monitor\nis failing and allow the user or admin to take appropriate action.\n\n\n\nPeter.\n\n\"member\" :  {\n\n                \"id\":\"c57f581b-c834-408f-93fa-30543cf30618\",\n\n                \"tenant_id\": \"310df60f-2a10-4ee5-9554-98393092194c\",\n\n                \"pool_id\": \"cfc6589d-f949-4c66-99d2-c2da56ef3764\",\n\n                \"address\": \"192.168.224.31\",\n\n                \"port\": 8080,\n\n               \"weight\" : 1,\n\n                \"admin_state_up\" : true,\n\n                \"status\" : \"INACTIVE\",\n\n                \"status_reason\" : \"f3eeab00-8367-4524-b662-55e64d4cacb5\"\n\n              }\n\n\n\n{\n\n    \"health_monitor\" :\n\n      {\n\n         \"id\" : \"f3eeab00-8367-4524-b662-55e64d4cacb5\",\n\n         \"type\" : \"HTTP\",\n\n         \"delay\" : 20,\n\n         \"timeout\": 10,\n\n         \"max_retries\": 3,\n\n         \"http_method\" : \"GET\",\n\n         \"url_path\" : \"/\",\n\n         \"expected_codes\" : \"200,202\",\n\n         \"admin_state_up\": true,\n\n         \"status\": \"ACTIVE\"\n\n      }\n\n}\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121127/73f32c93/attachment-0001.html>\n\n','<7B14C05615DB43488B85E143995BD5490108201BF3F0@LONPMAILBOX01.citrite.net>',NULL),('<1469031808.69.1383545657260.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:14:17',0,'2013-11-04 06:14:17',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-keystone-python26-stable-grizzly #58','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/58/>\n\n\n\n','<1283264922.45.1383372880136.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1469094395.56.1352765123163.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-13 00:05:23',0,'2012-11-13 00:05:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-diablo #91','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/91/>\n\n------------------------------------------\n[...truncated 263 lines...]\n    test_get_image_details_by_name                               OK    0.05\n    test_get_image_details_by_property                           OK    0.06\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.04\n    test_get_image_details_marker_limit                          OK    0.07\n    test_get_image_details_sort_disk_format_asc                  OK    0.07\n    test_get_image_details_with_maximum_size                     OK    0.05\n    test_get_image_details_with_minimum_size                     OK    0.05\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.04\n    test_get_image_index_limit                                   OK    0.06\n    test_get_image_index_limit_None                              OK    0.07\n    test_get_image_index_marker                                  OK    0.07\n    test_get_image_index_marker_limit                            OK    0.07\n    test_get_image_members                                       OK    0.04\n    test_get_image_members_not_existing                          OK    0.04\n    test_get_image_non_existing                                  OK    0.04\n    test_get_index_sort_container_format_desc                    OK    0.06\n    test_get_index_sort_created_at_asc                           OK    0.06\n    test_get_index_sort_disk_format_asc                          OK    0.06\n    test_get_index_sort_id_desc                                  OK    0.07\n    test_get_index_sort_name_asc                                 OK    0.06\n    test_get_index_sort_size_asc                                 OK    0.06\n    test_get_index_sort_status_desc                              OK    0.07\n    test_get_index_sort_updated_at_desc                          OK    0.06\n    test_get_member_images                                       OK    0.04\n    test_replace_members                                         OK    0.04\n    test_update_image                                            OK    0.06\n    test_update_image_not_existing                               OK    0.04\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.00\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.00\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.16\n    test_version_control_existing_db                             OK    0.75\n    test_walk_versions                                           OK    0.65\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.01\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 37.58 secs:\n    11.57    TestScrubber.test_delayed_delete\n    8.46    TestBinGlance.test_results_filtering\n    6.53    TestBinGlance.test_results_pagination\n    5.90    TestBinGlance.test_results_sorting\n    5.13    TestBinGlance.test_add_list_update_list\n----------------------------------------------------------------------\nRan 338 tests in 95.911s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.4\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-diablo/91\n[SCP] Copying console log.\n\n\n','<1938842337.42.1352678702670.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1469406601.123.1364191497692.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-25 06:04:57',0,'2013-03-25 06:04:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #175','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/175/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson6783958298767360131.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.22WuPmhNXH\n+ TMPDIR=/tmp/tmp.22WuPmhNXH\n+ trap \'rm -rf /tmp/tmp.22WuPmhNXH\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.11 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.38    RoleAPITests.test_get_default_role\n    0.28    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.603s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.22WuPmhNXH\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/175\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/175/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/175/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1124441716.109.1364105077494.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1471160553.24225321.1391617098296.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:18:18',-18000,'2014-02-05 16:18:18',NULL,'[openstack-dev] [Openstack-docs] Conventions on naming','----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Mark McLoughlin\" <markmc at redhat.com>, \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Cc: \"Jonathan Bryce\" <jonathan at openstack.org>\n> Sent: Wednesday, February 5, 2014 9:17:39 AM\n> Subject: Re: [openstack-dev] [Openstack-docs] Conventions on naming\n> \n> On 02/05/2014 01:09 PM, Mark McLoughlin wrote:\n> > On Wed, 2014-02-05 at 11:52 +0100, Thierry Carrez wrote:\n> >> Steve Gordon wrote:\n> >>>> From: \"Anne Gentle\" <anne.gentle at rackspace.com>\n> >>>> Based on today\'s Technical Committee meeting and conversations with the\n> >>>> OpenStack board members, I need to change our Conventions for service\n> >>>> names\n> >>>> at\n> >>>> https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names\n> >>>> .\n> >>>>\n> >>>> Previously we have indicated that Ceilometer could be named OpenStack\n> >>>> Telemetry and Heat could be named OpenStack Orchestration. That\'s not\n> >>>> the\n> >>>> case, and we need to change those names.\n> >>>>\n> >>>> To quote the TC meeting, ceilometer and heat are \"other modules\" (second\n> >>>> sentence from 4.1 in\n> >>>> http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/)\n> >>>> distributed with the Core OpenStack Project.\n> >>>>\n> >>>> Here\'s what I intend to change the wiki page to:\n> >>>>  Here\'s the list of project and module names and their official names\n> >>>>  and\n> >>>> capitalization:\n> >>>>\n> >>>> Ceilometer module\n> >>>> Cinder: OpenStack Block Storage\n> >>>> Glance: OpenStack Image Service\n> >>>> Heat module\n> >>>> Horizon: OpenStack dashboard\n> >>>> Keystone: OpenStack Identity Service\n> >>>> Neutron: OpenStack Networking\n> >>>> Nova: OpenStack Compute\n> >>>> Swift: OpenStack Object Storage\n> >>\n> >> Small correction. The TC had not indicated that Ceilometer could be\n> >> named \"OpenStack Telemetry\" and Heat could be named \"OpenStack\n> >> Orchestration\". We formally asked[1] the board to allow (or disallow)\n> >> that naming (or more precisely, that use of the trademark).\n> >>\n> >> [1]\n> >> https://github.com/openstack/governance/blob/master/resolutions/20131106-ceilometer-and-heat-official-names\n> >>\n> >> We haven\'t got a formal and clear answer from the board on that request\n> >> yet. I suspect they are waiting for progress on DefCore before deciding.\n> >>\n> >> If you need an answer *now* (and I suspect you do), it might make sense\n> >> to ask foundation staff/lawyers about using those OpenStack names with\n> >> the current state of the bylaws and trademark usage rules, rather than\n> >> the hypothetical future state under discussion.\n> > \n> > Basically, yes - I think having the Foundation confirm that it\'s\n> > appropriate to use \"OpenStack Telemetry\" in the docs is the right thing.\n> > \n> > There\'s an awful lot of confusion about the subject and, ultimately,\n> > it\'s the Foundation staff who are responsible for enforcing (and giving\n> > advise to people on) the trademark usage rules. I\'ve cc-ed Jonathan so\n> > he knows about this issue.\n> > \n> > But FWIW, the TC\'s request is asking for Ceilometer and Heat to be\n> > allowed use their \"Telemetry\" and \"Orchestration\" names in *all* of the\n> > circumstances where e.g. Nova is allowed use its \"Compute\" name.\n> > \n> > Reading again this clause in the bylaws:\n> > \n> >   \"The other modules which are part of the OpenStack Project, but\n> >    not the Core OpenStack Project may not be identified using the\n> >    OpenStack trademark except when distributed with the Core OpenStack\n> >    Project.\"\n> > \n> > it could well be said that this case of naming conventions in the docs\n> > for the entire OpenStack Project falls under the \"distributed with\" case\n> > and it is perfectly fine to refer to \"OpenStack Telemetry\" in the docs.\n> > I\'d really like to see the Foundation staff give their opinion on this,\n> > though.\n> \n> What Steve is asking IMO is whether we have to change \"OpenStack\n> Telemetry\" to \"Ceilometer module\" or whether we can just say \"Telemetry\"\n> without the OpenStack in front of it,\n> \n> Andreas\n\nConstraining myself to the topic of what we should be using in the documentation, yes this is what I\'m asking. This makes more sense to me than switching to calling them the \"Heat module\" and \"Ceilometer module\" because:\n\n1) It resolves the issue of using the OpenStack mark where it (apparently) shouldn\'t be used.\n2) It means we\'re still using the \"formal\" name for the program as defined by the TC [1] (it is my understanding this remains the purview of the TC, it\'s control of the mark that the board are exercising here).\n3) It is a more minor change/jump and therefore provides more continuity and less confusion to readers (and similarly if one of them ever becomes endorsed as core and we need to switch again).\n\nThanks,\n\nSteve\n\n[1] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml\n\n\n','<52F24803.5070403@suse.com>',NULL),('<1471474056.66.1375770807292.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-06 06:33:27',0,'2013-08-06 06:33:27',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #60','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/60/>\n\n------------------------------------------\n[...truncated 23268 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=7.31 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 7.312/7.312/7.312/0.000 ms\n++ cinder list\n++ grep ex-vol-6a883b06\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1375769604\n+ cinder create --display_name ex-vol-6a883b06 --display_description \'test volume: ex-vol-6a883b06\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-06T06:13:24.703600      |\n| display_description |     test volume: ex-vol-6a883b06     |\n|     display_name    |           ex-vol-6a883b06            |\n|          id         | 461aaeb4-e66f-4f55-8ba4-26b760d05140 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6a883b06 | grep available; do sleep 1; done\'\n| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | available | ex-vol-6a883b06 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375769607\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-6a883b06\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | available | ex-vol-6a883b06 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=461aaeb4-e66f-4f55-8ba4-26b760d05140\n+ die_if_not_set 164 VOL_ID \'Failure retrieving volume ID for ex-vol-6a883b06\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1375769607\n+ nova volume-attach d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 461aaeb4-e66f-4f55-8ba4-26b760d05140 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 |\n| id       | 461aaeb4-e66f-4f55-8ba4-26b760d05140 |\n| volumeId | 461aaeb4-e66f-4f55-8ba4-26b760d05140 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6a883b06 | grep in-use; do sleep 1; done\'\n| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | in-use | ex-vol-6a883b06 |  1   |     None    |  False   | d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 |\n++ date +%s\n+ end_time=1375769611\n+ echo \'Completed volume-attach in 4 seconds\'\nCompleted volume-attach in 4 seconds\n++ cinder list\n++ grep ex-vol-6a883b06\n++ get_field -1\n++ read data\n++ head -1\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | in-use | ex-vol-6a883b06 |  1   |     None    |  False   | d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=d26dd02e-e6ac-4410-bc5b-4d4b0ae84123\n+ die_if_not_set 178 VOL_ATTACH \'Failure retrieving ex-vol-6a883b06 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 != d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 ]]\n++ date +%s\n+ start_time=1375769612\n+ nova volume-detach d26dd02e-e6ac-4410-bc5b-4d4b0ae84123 461aaeb4-e66f-4f55-8ba4-26b760d05140\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6a883b06 | grep available; do sleep 1; done\'\n| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | available | ex-vol-6a883b06 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375769615\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1375769615\n+ cinder delete 461aaeb4-e66f-4f55-8ba4-26b760d05140\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-6a883b06; do sleep 1; done\'\n| 461aaeb4-e66f-4f55-8ba4-26b760d05140 | deleting | ex-vol-6a883b06 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375769618\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete d26dd02e-e6ac-4410-bc5b-4d4b0ae84123\n+ timeout 60 sh -c \'while nova list | grep -q d26dd02e-e6ac-4410-bc5b-4d4b0ae84123; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1517.g39f25f8.zip\nall runtests: commands[0] | python setup.py testr --slowest\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpmHFjMc\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpAfM53U\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpZxoM9r\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpwNGfuK\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-3\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 28, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2406 tests in 1114.190s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/rabbitmq/rabbit at devstack-1375756266-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/rabbitmq/rabbit at devstack-1375756266.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-185271/60/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<587475949.51.1375682584385.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1471994720.19668277.1370498263480.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-06 01:57:43',-14400,'2013-06-06 05:57:43',NULL,'[openstack-qa] Tempest Architecture/Design brainstorming','Hi All,\n\nI am looking for ideas for unifying the tempest \"Object Model\" and to enhance it\'s capabilities.\n\nSeveral interesting topic:\n- Plug-ability\n- Identity management (\"impersonate the right person efficiently\")\n- test case selection (based on supported feature, installed services..)\n\nAn ideal proposal should answer the \n- What you would like to achieve.\n- Why do you want/need this. \n- How do you want to do it.\n\nFeel free to add incomplete idea as well.\n\nBest Regards,\nAttila\n\nPS.: python is not juts OOP language, \nwe should use the imperative and functional programming styles as well.\n\n\n','<542468131.19664806.1370497761068.JavaMail.root@redhat.com>',NULL),('<1472544367.16.1369116472791.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-21 06:07:52',0,'2013-05-21 06:07:52',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #232','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/232/>\n\n------------------------------------------\n[...truncated 845 lines...]\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140413268453192:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_verify_signed_token_succeeds_for_unrevoked_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 533, in test_verify_signed_token_succeeds_for_unrevoked_token\n    self.middleware.verify_signed_token(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139778456094536:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_fetch_revocation_list_with_expire (test_auth_token_middleware.StackResponseAuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 422, in test_fetch_revocation_list_with_expire\n    fetched_list = jsonutils.loads(self.middleware.fetch_revocation_list())\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 820, in fetch_revocation_list\n    return self.cms_verify(data[\'signed\'])\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140692548130632:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_default_tenant_signed_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 483, in test_default_tenant_signed_token\n    self.assert_unscoped_default_tenant_auto_scopes(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 476, in assert_unscoped_default_tenant_auto_scopes\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139737228789576:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_memcache_set_expired (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 629, in test_memcache_set_expired\n    self.assertEqual(len(self.middleware._cache.set_value), 2)\nAssertionError: 7 != 2\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.middleware.auth_token: DEBUG: Cached Token 9bba6849c9e1f77727ae7813fd151115 seems expired\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140380907378504:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: DEBUG: Marking token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg== as unauthorized in memcache\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_valid_signed_request (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 461, in test_valid_signed_request\n    self.assert_valid_request_200(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 450, in assert_valid_request_200\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139776161441608:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 24.03 secs:\n    7.28    KcMasterTestCase.test_admin_requires_adminness\n    7.06    Kc11TestCase.test_admin_requires_adminness\n    6.97    KcEssex3TestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.20    KcMasterSqlTestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 701 tests in 78.646s\n\nFAILED (SKIP=11, errors=4, failures=3)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.16\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeystone==2012.2.5\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=43\n+ \'[\' 43 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.MpQAodzYjv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/232\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/232/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1090145752.12.1369030155166.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1472951244.13.1382768846347.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-26 06:27:26',0,'2013-10-26 06:27:26',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #42','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/42/>\n\n------------------------------------------\n[...truncated 18279 lines...]\n2013-10-26 06:07:03 catalog_type = object-store\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # The name of a region for object storage. If empty or commented-out, the\n2013-10-26 06:07:03 # value of identity.region is used instead. If no such region is found in\n2013-10-26 06:07:03 # the service catalog, the first found one is used.\n2013-10-26 06:07:03 #region = RegionOne\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Number of seconds to time on waiting for a container to container\n2013-10-26 06:07:03 # synchronization complete\n2013-10-26 06:07:03 container_sync_timeout = 120\n2013-10-26 06:07:03 # Number of seconds to wait while looping to check the status of a\n2013-10-26 06:07:03 # container to container synchronization\n2013-10-26 06:07:03 container_sync_interval = 5\n2013-10-26 06:07:03 # Set to True if the Account Quota middleware is enabled\n2013-10-26 06:07:03 accounts_quotas_available = True\n2013-10-26 06:07:03 # Set to True if the Container Quota middleware is enabled\n2013-10-26 06:07:03 container_quotas_available = True\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Set operator role for tests that require creating a container\n2013-10-26 06:07:03 operator_role = Member\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [boto]\n2013-10-26 06:07:03 ssh_user = cirros\n2013-10-26 06:07:03 # This section contains configuration options used when executing tests\n2013-10-26 06:07:03 # with boto.\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # EC2 URL\n2013-10-26 06:07:03 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-10-26 06:07:03 # S3 URL\n2013-10-26 06:07:03 s3_url = http://127.0.0.1:3333\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-10-26 06:07:03 aws_access =\n2013-10-26 06:07:03 aws_secret =\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Image materials for S3 upload\n2013-10-26 06:07:03 # ALL content of the specified directory will be uploaded to S3\n2013-10-26 06:07:03 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # The manifest.xml files, must be in the s3_materials_path directory\n2013-10-26 06:07:03 # Subdirectories not allowed!\n2013-10-26 06:07:03 # The filenames will be used as a Keys in the S3 Buckets\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-10-26 06:07:03 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-10-26 06:07:03 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-10-26 06:07:03 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Instance type\n2013-10-26 06:07:03 instance_type = m1.nano\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # TCP/IP connection timeout\n2013-10-26 06:07:03 http_socket_timeout = 30\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Number of retries actions on connection or 5xx error\n2013-10-26 06:07:03 num_retries = 1\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Status change wait timout\n2013-10-26 06:07:03 build_timeout = 400\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Status change wait interval\n2013-10-26 06:07:03 build_interval = 1\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [orchestration]\n2013-10-26 06:07:03 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-10-26 06:07:03 # custom Keystone service catalog implementation, you probably want to leave\n2013-10-26 06:07:03 # this value as \"orchestration\"\n2013-10-26 06:07:03 catalog_type = orchestration\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # The name of a region for orchestration. If empty or commented-out, the value\n2013-10-26 06:07:03 # of identity.region is used instead. If no such region is found in the service\n2013-10-26 06:07:03 # catalog, the first found one is used.\n2013-10-26 06:07:03 #region = RegionOne\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Status change wait interval\n2013-10-26 06:07:03 build_interval = 1\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Status change wait timout. This may vary across environments as some some\n2013-10-26 06:07:03 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-10-26 06:07:03 build_timeout = 300\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Instance type for tests. Needs to be big enough for a\n2013-10-26 06:07:03 # full OS plus the test workload\n2013-10-26 06:07:03 instance_type = m1.micro\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Name of heat-cfntools enabled image to use when launching test instances\n2013-10-26 06:07:03 # If not specified, tests that spawn instances will not run\n2013-10-26 06:07:03 #image_ref = ubuntu-vm-heat-cfntools\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # Name of existing keypair to launch servers with. The default is not to specify\n2013-10-26 06:07:03 # any key, which will generate a keypair for each test class\n2013-10-26 06:07:03 #keypair_name = heat_key\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [dashboard]\n2013-10-26 06:07:03 # URL where to find the dashboard home page\n2013-10-26 06:07:03 dashboard_url = http://127.0.0.1/\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # URL where to submit the login form\n2013-10-26 06:07:03 login_url = http://127.0.0.1/auth/login/\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [scenario]\n2013-10-26 06:07:03 # Directory containing image files\n2013-10-26 06:07:03 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # AMI image file name\n2013-10-26 06:07:03 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # ARI image file name\n2013-10-26 06:07:03 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # AKI image file name\n2013-10-26 06:07:03 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # ssh username for the image file\n2013-10-26 06:07:03 ssh_user = cirros\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 # specifies how many resources to request at once. Used for large operations\n2013-10-26 06:07:03 # testing.\"\n2013-10-26 06:07:03 large_ops_number = 0\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [cli]\n2013-10-26 06:07:03 # Enable cli tests\n2013-10-26 06:07:03 enabled = True\n2013-10-26 06:07:03 # directory where python client binaries are located\n2013-10-26 06:07:03 cli_dir = /usr/local/bin\n2013-10-26 06:07:03 # Number of seconds to wait on a CLI timeout\n2013-10-26 06:07:03 timeout = 15\n2013-10-26 06:07:03 \n2013-10-26 06:07:03 [service_available]\n2013-10-26 06:07:03 # Whether or not cinder is expected to be available\n2013-10-26 06:07:03 cinder = True\nall develop-inst: /opt/stack/new/tempest\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp3QjjfL\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpJjkVKX\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpAGEDwL\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpsCcu0S\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_hosts_negative\ntags: worker-1\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_hosts_negative\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_hosts_negative.py\", line 23, in <module>\n    class HostsAdminNegativeTestJSON(base.BaseComputeAdminTest):\nAttributeError: \'module\' object has no attribute \'BaseComputeAdminTest\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2861 tests in 1115.464s\nFAILED (id=0, failures=2, skips=76)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-610344-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-610344.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-610344/42/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1982376982.10.1382682648177.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1473061370.9307069.1416120508835.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-16 01:48:28',-18000,'2014-11-16 06:48:28',NULL,'[Openstack] Openstack','Hi, \n\nIf all your application needs is a connection between the instances, just connect all three instances on same virtual network. \nThen check nova security group rules (think of it like you would of a firewall) add rules for needed ports and that\'s it. \nInstances should be able to access one another over the ports you enabled. \n\nCheck these links:\nhttp://docs.openstack.org/openstack-ops/content/network_design.html\ndocs.openstack.org/openstack-ops/content/security_groups.html \n\nREST interface, if I\'m guessing what you are referring to, is the method used to manage Openstack deployments. \nhttps://wiki.openstack.org/wiki/OpenStackRESTAPI\nhttps://blueprints.launchpad.net/nova/+spec/open-stack-api\n\nHope this help a bit.\nTshefi\n\n\n----- Original Message -----\nFrom: \"Sandhya S\" <coolssandy at gmail.com>\nTo: openstack at lists.openstack.org\nSent: Friday, November 14, 2014 7:53:51 PM\nSubject: [Openstack] Openstack\n\nHi all, \n\nMy application requires three servers which are in 3 different VM\'s to communicate with each other. \nSo how can it be approached? Should REST interface be deployed? \n\n\n\nThanks \n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<CAANYUcGpdnDENhRYzLqzPnamjVgFbaMUQrX5TepKiBu4jkxOtQ@mail.gmail.com>',NULL),('<1473413468.154.1356307533570.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-24 00:05:33',0,'2012-12-24 00:05:33',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-swift-docs-stable-folsom #84','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/84/>\n\n\n\n','<1356854431.125.1356221107454.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1473623153.719541.1408294958079.JavaMail.zimbra@tipit.net>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-08-17 12:02:38',-18000,'2014-08-17 17:02:38',NULL,'[OpenStack-Infra] OpenStack.org endpoint - outage at Rackspace','Just a heads up that there has been an outage at Rackspace that could prevent the endpoint at OpenStack.org from working properly when Gerrit/Launchpad is attempting to check for Foundation Member status. Rackspace is working on the issue and hope to have it resolved soon, however, there isn\'t a lot of detail at this point. If you have reports of users having trouble creating new Gerrit accounts or updating existing, that\'s likely what the problem is. I\'ll update this as soon as we find the matter resolved from Rackspace. \n\nThanks, \n\nJimmy McArthur / tipit.net <jimmy at tipit.net> \no: 512.481.1161 \nm: 512.965.4846 \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140817/15213d49/attachment.html>\n\n','<CAKO+H+Lk23o6ejfG0Y5_3syNa1OBY10vyrkQDUyhpxmnLRHoAA@mail.gmail.com>',NULL),('<1473858936.1280108.1383331631904.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 11:47:11',-25200,'2013-11-01 18:47:11',NULL,'[openstack-dev] [nova][scheduler]The database\n	access	in	the	scheduler filters','Thanks: TIL.\n\nThe filter invocation per host is the bit I was forgetting. \n\nI\'m assuming that the facts about the hosts don\'t change several times a second so if you held the facts in RAM and then asserted the rules against those facts allowing for age-out/invalidation based on incoming updates then the whole system will run faster. I remember a thread on using dogpile/memoization for this kind of thing.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Yunhong Jiang\" <yunhong.jiang at intel.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Friday, November 1, 2013 1:42:03 PM\n> Subject: Re: [openstack-dev] [nova][scheduler]The database access	in	the	scheduler filters\n> \n> Shawn, yes, there is 56 VM access every second, and for each VM access, the\n> scheduler will invoke filter for each host, that means, for each VM access,\n> the filter function will be invoked 10k times.\n> So 56 * 10k = 560k, yes, half of 1M, but still big number.\n> \n> --jyh\n> \n> > -----Original Message-----\n> > From: Shawn Hartsock [mailto:hartsocks at vmware.com]\n> > Sent: Friday, November 01, 2013 8:20 AM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [nova][scheduler]The database access in the\n> > scheduler filters\n> > \n> > \n> > \n> > ----- Original Message -----\n> > > From: \"Yunhong Jiang\" <yunhong.jiang at intel.com>\n> > > To: openstack-dev at lists.openstack.org\n> > > Sent: Thursday, October 31, 2013 6:39:29 PM\n> > > Subject: [openstack-dev] [nova][scheduler]The database access in the\n> > 	scheduler filters\n> > >\n> > > I noticed several filters (AggregateMultiTenancyIsoaltion, ram_filter,\n> > > type_filter, AggregateInstanceExtraSpecsFilter) have DB access in the\n> > > host_passes(). Some will even access for each invocation.\n> > >\n> > > Just curios if this is considered a performance issue? With a 10k nodes,\n> > 60\n> > > VM per node, and 3 hours VM life cycle cloud, it will have more than 1\n> > > million DB access per second. Not a small number IMHO.\n> > >\n> > > Thanks\n> > > --jyh\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > \n> > Sorry if I\'m dumb, but please try to explain things to me. I don\'t think I\n> > follow...\n> > \n> > 10k nodes, 60 VM per node... is 600k VM in the whole cloud. A 3 hour life\n> > cycle for a VM means every hour 1/3 the nodes turn over so 200k VM\n> > are created/deleted per hour ... divide by 60 for ... 3,333.333 per minute\n> > or ... divide by 60 for ... 55.5 VM creations/deletions per second ...\n> > \n> > ... did I do that math right? So where\'s the million DB accesses per second\n> > come from? Are the rules fired for every VM on every access so that 600k\n> > VM + 1 new VM means the rules fire 600k + 1 times? What? Sorry... really\n> > confused.\n> > \n> > # Shawn Hartsock\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<DDCAE26804250545B9934A2056554AA01FBACA58@ORSMSX108.amr.corp.intel.com>',NULL),('<1474833382.283571418244088797.JavaMail.root@amundsen.cs.athabascau.ca>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-10 13:41:28',-25200,'2014-12-10 20:41:28',NULL,'[Openstack] SOLVED:  neutron won\'t bind to 9696','for posterity:\n\nlooks like some package conflicts creeped into my setup. I have had to re-trace my steps and:\n\n1. install yum-plugins-priorities \n2. run yum distribution-synchronization\n3. \"just in case\" installed openstack-selinux\n\nafter doing above on all nodes things are working as expected.\n\n----- \"Dmitry Makovey\" <dmitry at athabascau.ca> wrote:\n\n> Hi,\n> \n> I\'m having an odd issue. Under RHEL6 with RDO IceHouse I\'m trying\n> rnning\n> the same setup procedure I ran successfully under CentOS6 vith RDO\n> IceHouse a few month back. I have checked and re-checked configs and\n> they all look reasonably \"the same\" (apart from original setup being\n> done on a diff. network, and inside of bunch of VMs).\n> \n> So what I\'m having is neutron-server running but not binding to the\n> 9696\n> port, nothing in error logs suggests the cause. \"openstack-status\"\n> runs\n> fine for the rest of the services, but since neutron is botched I\'ve\n> only been able to confirm keystone and glance being functional.\n> \n> Currently my /etc/neutron/neutron.conf contains both\n> {verbose,debug}=True\n> \n> What else could be done to locate the issue? (obviously neutron-debug\n> is\n> of no use as it can\'t talk to server).\n> \n> selinux is in enforcing, however I\'ve ran with permissive mode with\n> the\n> same results.\n> \n> log output on neutron-startup is here:\n> https://gist.github.com/droopy4096/d866aa9aa968fe0c61b1\n> \n> -- \n> Dmitry Makovey\n> Web Systems Administrator\n> Athabasca University\n> (780) 675-6245\n> ---\n> Confidence is what you have before you understand the problem\n>     Woody Allen\n> \n> When in trouble when in doubt run in circles scream and shout\n>      http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330\n> \n> \n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-- \n    This communication is intended for the use of the recipient to whom it\n    is addressed, and may contain confidential, personal, and or privileged\n    information. Please contact us immediately if you are not the intended\n    recipient of this communication, and do not copy, distribute, or take\n    action relying on it. Any communications received in error, or\n    subsequent reply, should be deleted or destroyed.\n---\n\n\n\n','<5486225B.4060601@athabascau.ca>',NULL),('<1474916667.385.1359268352582.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-27 06:32:32',0,'2013-01-27 06:32:32',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #118','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/118/>\n\n\n\n','<879132000.364.1359185509437.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<147508342.4.1376633758361.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-16 06:15:58',0,'2013-08-16 06:15:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 3738 lines...]\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 32.76 secs:\n    8.04    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.74    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.17    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    6.04    TestTokenRevoking.test_removing_role_assignment_does_not_affect_other_users\n    5.77    TestTokenAPIs.test_revoke_token\n----------------------------------------------------------------------\nRan 1300 tests in 436.293s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.7\nargparse==1.2.1\nastroid==1.0.0\nbeautifulsoup4==4.3.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.11\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.6.1\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.5\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==1.0.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.6\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.asLtSf5icG\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise2/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1476441668.16938186.1383229237300.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 10:20:37',-14400,'2013-10-31 14:20:37',NULL,'[openstack-dev] [Solum] Separation of concerns for 0.1\n	git	deploy blueprint','\n\n----- Original Message -----\n> Hi Clayton,\n> \n> Thank you for creating these diagrams. They are a great starting point for\n> discussions\n> around the git deploy blueprint.\n> \n> Some questions/comments:\n> \n> In both the diagrams, what do the arrows indicate?\n> Data flow, control-flow, or some kind of ordering relationship?\n\n\"Happens after\" mostly.  It was intended to be less formal than a true sequence flow, just a vehicle iterate and discuss until we\'d nailed down any mismatches in how each of us looks at the overall flow, then move on to more formal definitions.\n\n> Especially, the arrow from \'respond to client\' to \'HEAT\' box in the top\n> diagram\n> is a bit confusing. Correct me if I am wrong, but my guess is that the\n> meaning\n> of that arrow is, \'stack create\' will happen after responding to client has\n> happened.\n> Although, this may not be necessarily true (both those steps can happen in\n> async manner).\n\nYou and Adrian are right - I\'ll go back and explicitly call out the asynchronicity.\n\n> \n> Second, how do you envision tying together the two diagrams/high-level flows?\n> Specifically, once we have a built artifact (second diagram), how do we go\n> about deploying it?\n\nI\'ll throw another one in that\'s really abstract and follow up in a response.  I think the easy answer is \"make a change to the \'plan\', turn the plan into a HOT template, call HEAT to update the stack\".  Over time Heat stack update then is the natural boundary for versions of an app.\n\n> \n> We could either have, build abstraction -> REST API -> deploy abstraction,\n> or, build abstraction -> deploy abstraction. What are your thoughts on this?\n> \n\nWorking backwards, builds usually create resources somewhere and sometimes those resources are large (e.g Jenkins and a Glance image, for instance).  The builder needs a clean endpoint to notify Solum that a new deployment artifact is available that replaces one of the existing deployment artifacts.  There\'s a big gray area here because it depends on how strongly Solum specifies this flow - the less strongly the flow is specified the more flexibility there is to integrate complex systems (Gerritt, Jenkins, existing corporate build procesess), the more strongly the flow is specified the easier it is to provide valuable outcomes.  My guess is that there probably is a \"new artifact available\" API call that updates an existing artifact which triggers a redeploy.  An artifact might be a zip, a WAR, a docker image, a glance image, a VM img file, etc.  I think this is a good topic for the build subgroup.\n\n\n','<1383195778.462528780@apps.rackspace.com>',NULL),('<1476653766.8585033.1361781974942.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-25 03:46:14',-18000,'2013-02-25 08:46:14',NULL,'[openstack-qa] New Client Test Suite','It is a big surprise.\n\nI tough we choose a path outside from the tempest/ directory because that moment we didn\'t wanted to add it to the full tempest-devstack gate. \nWe discussed about some kind of incubation \"workflow\".\n\nWhen does it changed ? What is the current agreement about the incubation ?\n\nWhen will the CLI tests verify the output ?  \n\n----- Original Message -----\nFrom: \"Joe Gordon\" <jogo at cloudscaling.com>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Thursday, February 21, 2013 7:47:35 PM\nSubject: Re: [openstack-qa] New Client Test Suite\n\n\nHi All, \n\n\nI am pleased to say that the CLI tests are now gating ( https://review.openstack.org/#/c/22096/ ). They run at the end of the standard tempest test (example: http://logs.openstack.org/22546/5/check/gate-tempest-devstack-vm-full/4878/console.html.gz ). \n\n\nThe current set of tests are very basic and need a lot of work. But now that the CLI tests are self-gating it should be easy for anyone to contribute to them. Currently we have: \n* uses tempest.conf \n* in unittest framework \n* admin user only \n* python-novaclient only \n* read-only tests \n\n\nBut we would like to have: \n* Tests for all python-*clients \n* Tests for all *-manage binaries \n* Tests for both admin and regular users \n* Read/Write tests (spin up a VM with client do something etc) \n\n\n\n\n\n\nDaryl, as for your WIP patch, I will take a look at it hopefully there are some things we can use from it. \n\n\nbest, \nJoe Gordon \n\n\nOn Thu, Feb 21, 2013 at 8:18 AM, Daryl Walleck < daryl.walleck at rackspace.com > wrote: \n\n\nAhh, I didn\'t realize we an agreed upon solution for command line testing already. If there\'s nothing of use that can be pulled from what I submitted, I\'ll withdraw the branch. \n\nDaryl \n________________________________________ \nFrom: Jay Pipes [ jaypipes at gmail.com ] \nSent: Thursday, February 21, 2013 9:44 AM \nTo: openstack-qa at lists.openstack.org \n\n\nSubject: Re: [openstack-qa] New Client Test Suite \n\nOn 02/21/2013 10:24 AM, Daryl Walleck wrote: \n> It took me a bit longer than I hoped, but I but a basic outline of some of the command line tests we have out in a WIP branch. If there\'s enough interest, I can get this merged into Tempest properly. \n> \n> https://review.openstack.org/#/c/22552/ \n\nHi Daryl! \n\nWe now have a CLI test module in Tempest: \n\nhttps://github.com/openstack/tempest/tree/master/cli \n\nIf we bring in your CLI tests, I think I\'d prefer to: \n\na) Keep the code style consistent with the rest of Tempest \nb) Use the simple framework that Joe put together for the cli tests \ncurrently in Tempest \n\nBest, \n-jay \n\n> Daryl \n> ________________________________________ \n> From: Sam Danes [ sam.danes at RACKSPACE.COM ] \n> Sent: Thursday, February 14, 2013 11:15 AM \n> To: All Things QA. \n> Subject: Re: [openstack-qa] New Client Test Suite \n> \n> I\'ve given Daryl a pointer to the prototype code we wrote. He\'ll work on getting it out to the community. \n> \n> -----Original Message----- \n> From: Attila Fazekas [mailto: afazekas at redhat.com ] \n> Sent: Thursday, February 14, 2013 7:33 AM \n> To: All Things QA. \n> Subject: Re: [openstack-qa] New Client Test Suite \n> \n> Very good idea! \n> \n> I think it can fit into tempest repository, but in a different directory. \n> \n> I would extend a scope too. \n> \n> At the first Round: \n> - *mange command tests. \n> - remote execution (with ssh connection pooling) The whitebox test type (not the existing test case), partially should be converted to utilities, partially the functionality should move to the new folder. \n> https://github.com/openstack/tempest/blob/master/tempest/whitebox.py#L138 \n> \n> \n> ----- Original Message ----- \n>> From: \"Daryl Walleck\" < daryl.walleck at RACKSPACE.COM > \n>> To: \"All Things QA.\" < openstack-qa at lists.openstack.org > \n>> Sent: Thursday, February 14, 2013 3:33:20 AM \n>> Subject: Re: [openstack-qa] New Client Test Suite \n>> \n>> \n>> \n>> \n>> \n>> We\'ve bumped into some Novaclient only issues before in the past as \n>> well. Sam and some of his team did prototype some tests that execute \n>> using Novaclient. If there\'s any interest I can see about getting it \n>> into a WIP branch to get eyes on it. \n>> \n>> \n>> \n>> Daryl \n>> \n>> \n>> From: Joe Gordon [ jogo at cloudscaling.com ] \n>> Sent: Tuesday, February 12, 2013 4:39 PM \n>> To: openstack-qa at lists.openstack.org \n>> Subject: [openstack-qa] New Client Test Suite \n>> \n>> \n>> \n>> \n>> Hi All, \n>> \n>> We currently have thorough API tests (Tempest) that do an excellent \n>> job of testing nova, glance, keystone, etc. But to date we don\'t have \n>> anything that tests the assorted python clients. \n>> \n>> \n>> Extensive python client tests, which would consist of mostly shell \n>> commands, would prevent many bugs from arising such as: \n>> https://bugs.launchpad.net/python-novaclient/+bug/1122958 . \n>> \n>> \n>> The question is where should theses tests live? \n>> \n>> \n>> * Devstack/smoketests - these are just smoketests and are not designed \n>> to be exhaustive \n>> * Tempest - currently explicitly doesn\'t use the python clients, but \n>> we can add a separate folder that tests the clients \n>> * In respective client repos - easier to require new tests when adding \n>> to client, but will result in divergent test suites \n>> * Separate Repo - perhaps this is premature? \n>> \n>> \n>> I propose adding a separate folder in tempest to run the python client \n>> tests, and taking it from there. \n>> \n>> \n>> \n>> \n>> best, \n>> Joe Gordon \n>> _______________________________________________ \n>> openstack-qa mailing list \n>> openstack-qa at lists.openstack.org \n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n>> \n> \n> _______________________________________________ \n> openstack-qa mailing list \n> openstack-qa at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n> \n> _______________________________________________ \n> openstack-qa mailing list \n> openstack-qa at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n> \n> _______________________________________________ \n> openstack-qa mailing list \n> openstack-qa at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n> \n\n_______________________________________________ \nopenstack-qa mailing list \nopenstack-qa at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n\n_______________________________________________ \nopenstack-qa mailing list \nopenstack-qa at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa \n\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<CAKe5d-QjLism1M8EwQ7ACKSKZXZDyaA1OnQ2=RSnyCScLQNE+g@mail.gmail.com>',NULL),('<14768904-C7A1-471B-98D6-A584A32E8C9E@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-01 21:56:23',-18000,'2014-02-02 02:56:23',NULL,'[openstack-dev] [Neutron][IPv6] Private or Public network?','Hi, Anthony:\n\nThanks a lot for the quick response! I didn\'t think about the provider network scenarios. I feel grateful you brought it up. I will add provider network to the chart.\n\nHere is my understanding:\n\nPrivate network: VM is attached to a subnet with NO default gateway at all, i.e. completely isolated\nProvider network:  VM is attached to a physical network with a physical router acting as gateway, which is outside of OpenStack?s control\n\nFrom implementation perspective, both cases are identical since Openstack won?t see the gateway port on neutron router. Hence, Openstack should not be responsible to send IPv6 RA. Being said, the code I am developing will perform a check:\n\n1) If an IPv6 subnet does NOT have gateway port on neutron router (i.e. either private or provider network), then only the first two highlighted combinations are considered as valid. Because the rest five options requires RA announcement.\n2) If an IPv6 subnet does have gateway port on neutron router (i.e public network), then only the last five highlighted combinations are considered as valid. Because the first two options turn off RA announcement, which makes existing gateway port on neutron router useless.\n\nPlease keep me honest here??.\n\nThanks again!\n\nShixiong\n\n\n\n\nOn Feb 1, 2014, at 7:16 PM, Veiga, Anthony <Anthony_Veiga at cable.comcast.com> wrote:\n\n> See Inline\n> \n>> Hi, guys:\n>> \n>> While I am implementing the code to support IPv6 two mode keywords, a question came to my mind and I would like to see your opinions.\n>> \n>> If you look at the table below, you will notice that the first two combinations highlighted with red underline have ?ipv6_ra_mode? set to OFF. I think these two options only make sense if the tenant subnet is PRIVATE, i.e. the subnet is not attached to any router. In this case, OpenStack should NOT send RA; On the flip side, if the subset is PUBLIC, i.e. the subnet is attached to a router, then the corresopnding port on the router should be THE default gateway for the tenant subnet, hence, need to handle RA announcement.\n> \n> \n> These options also make sense if you consider the first column of your chart.  In both of these cases, they are listed as having an external router.  This is REQUIRED for a provider network where the routed is not owned by OpenStack.  Please do NOT consider these private-only.\n> \n>> \n>> In summary, I believe it doesn?t make sense to allow OpenStack to create default gateway for a tenant network, but suppress RA from the default gateway port on Neutron router. If so, the default gateway port is pretty much useless. This is the way I am coding now. However, I might overlook some scenarios. Please chime in if you see any use cases beyond what this table covers.\n> \n> \n> If my upstream router is on-link, then I need to set it as the gateway (for security purposes, we need to be able to filter RAs from rogue agents).  However, I still want OpenStack to handle address assignment.\n> \n>> \n>> Thanks!\n>> \n>> Shixiong\n>> \n>> P.S. The PDF file of this table is uploaded to my Dropbox. Here is the link: \n>> https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf\n>> \n>> \n>> <PastedGraphic-1.png>\n>> \n>> \n>> \n> <PastedGraphic-1.png>_______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140201/a527bca9/attachment.html>\n\n','<CF12F7EC.6EB9%anthony_veiga@cable.comcast.com>',NULL),('<1477215522.520.1367303470209.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-30 06:31:10',0,'2013-04-30 06:31:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #20','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/20/>\n\n------------------------------------------\n[...truncated 2306 lines...]\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.common.wsgi: DEBUG: ******************** REQUEST ENVIRON ********************\nkeystone.common.wsgi: DEBUG: SCRIPT_NAME = /v2.0\nkeystone.common.wsgi: DEBUG: webob.adhoc_attrs = {\'response\': <Response at 0xcf9a590 200 OK>}\nkeystone.common.wsgi: DEBUG: REQUEST_METHOD = GET\nkeystone.common.wsgi: DEBUG: PATH_INFO = /tenants\nkeystone.common.wsgi: DEBUG: SERVER_PROTOCOL = HTTP/1.0\nkeystone.common.wsgi: DEBUG: HTTP_X_AUTH_TOKEN = MIICmAYJKoZIhvcNAQcCoIICiTCCAoUCAQExCTAHBgUrDgMCGjCCASYGCSqGSIb3DQEHAaCCARcEggETeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC44MTcyMDAiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW10sICJuYW1lIjogIkZPTyJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogW119fX0xggFJMIIBRQIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAV844IynOUp7ervaxDkoZtQdedtV2whs6-PTPscAwi9Uutzvw8p4GwubGXMPdR3xSxsFtlnOgKhVKs6o9WeLdTU52pPgxUkFHe5UQBYlOk8bt00P3MmJtyb7NBfC8DzngZDhfJRPVnA5xS2eLxnY9wkTDwxIL9WYlxuXO8PcuIVc=\nkeystone.common.wsgi: DEBUG: HTTP_USER_AGENT = python-keystoneclient\nkeystone.common.wsgi: DEBUG: REMOTE_PORT = 57512\nkeystone.common.wsgi: DEBUG: SERVER_NAME = 127.0.0.1\nkeystone.common.wsgi: DEBUG: REMOTE_ADDR = 127.0.0.1\nkeystone.common.wsgi: DEBUG: eventlet.input = <eventlet.wsgi.Input object at 0xc4834d0>\nkeystone.common.wsgi: DEBUG: wsgi.url_scheme = http\nkeystone.common.wsgi: DEBUG: SERVER_PORT = 51398\nkeystone.common.wsgi: DEBUG: wsgi.input = <eventlet.wsgi.Input object at 0xc4834d0>\nkeystone.common.wsgi: DEBUG: openstack.context = {\'token_id\': \'MIICmAYJKoZIhvcNAQcCoIICiTCCAoUCAQExCTAHBgUrDgMCGjCCASYGCSqGSIb3DQEHAaCCARcEggETeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC44MTcyMDAiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW10sICJuYW1lIjogIkZPTyJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogW119fX0xggFJMIIBRQIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAV844IynOUp7ervaxDkoZtQdedtV2whs6-PTPscAwi9Uutzvw8p4GwubGXMPdR3xSxsFtlnOgKhVKs6o9WeLdTU52pPgxUkFHe5UQBYlOk8bt00P3MmJtyb7NBfC8DzngZDhfJRPVnA5xS2eLxnY9wkTDwxIL9WYlxuXO8PcuIVc=\', \'is_admin\': False}\nkeystone.common.wsgi: DEBUG: HTTP_HOST = localhost:51398\nkeystone.common.wsgi: DEBUG: wsgi.multithread = True\nkeystone.common.wsgi: DEBUG: eventlet.posthooks = []\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT = */*\nkeystone.common.wsgi: DEBUG: wsgi.version = (1, 0)\nkeystone.common.wsgi: DEBUG: RAW_PATH_INFO = /v2.0/tenants\nkeystone.common.wsgi: DEBUG: GATEWAY_INTERFACE = CGI/1.1\nkeystone.common.wsgi: DEBUG: wsgi.run_once = False\nkeystone.common.wsgi: DEBUG: wsgi.errors = <nose.plugins.xunit.Tee object at 0xd52e290>\nkeystone.common.wsgi: DEBUG: wsgi.multiprocess = False\nkeystone.common.wsgi: DEBUG: CONTENT_TYPE = text/plain\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT_ENCODING = gzip, deflate, compress\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: ******************** REQUEST BODY ********************\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: arg_dict: {}\nkeystone.common.wsgi: DEBUG: ******************** RESPONSE HEADERS ********************\nkeystone.common.wsgi: DEBUG: Vary = X-Auth-Token\nkeystone.common.wsgi: DEBUG: Content-Type = application/json\nkeystone.common.wsgi: DEBUG: Content-Length = 111\nkeystone.common.wsgi: DEBUG: \nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.common.wsgi: DEBUG: ******************** RESPONSE BODY ********************\nkeystone.common.wsgi: DEBUG: {\"tenants_links\": [], \"tenants\": [{\"description\": \"description\", \"enabled\": true, \"id\": \"bar\", \"name\": \"BAR\"}]}\naccess: INFO: 127.0.0.1 - - [30/Apr/2013:06:20:55 +0000] \"GET http://localhost:51398/v2.0/tenants HTTP/1.0\" 200 111\neventlet.wsgi.server: DEBUG: 127.0.0.1 - - [30/Apr/2013 06:20:55] \"GET /v2.0/tenants HTTP/1.1\" 200 240 0.019785\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/tenants HTTP/1.1\" 200 111\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\neventlet.wsgi.server: DEBUG: (16585) accepted (\'127.0.0.1\', 45394)\n\nkeystone.common.wsgi: DEBUG: ******************** REQUEST ENVIRON ********************\nkeystone.common.wsgi: DEBUG: SCRIPT_NAME = /v2.0\nkeystone.common.wsgi: DEBUG: webob.adhoc_attrs = {\'response\': <Response at 0xd9a9c50 200 OK>}\nkeystone.common.wsgi: DEBUG: REQUEST_METHOD = DELETE\nkeystone.common.wsgi: DEBUG: PATH_INFO = /tokens/MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA==\nkeystone.common.wsgi: DEBUG: SERVER_PROTOCOL = HTTP/1.0\nkeystone.common.wsgi: DEBUG: REMOTE_ADDR = 127.0.0.1\nkeystone.common.wsgi: DEBUG: HTTP_X_AUTH_TOKEN = MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA==\nkeystone.common.wsgi: DEBUG: HTTP_USER_AGENT = python-keystoneclient\nkeystone.common.wsgi: DEBUG: eventlet.posthooks = []\nkeystone.common.wsgi: DEBUG: RAW_PATH_INFO = /v2.0/tokens/MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA==\nkeystone.common.wsgi: DEBUG: REMOTE_PORT = 45394\nkeystone.common.wsgi: DEBUG: eventlet.input = <eventlet.wsgi.Input object at 0xcceaf50>\nkeystone.common.wsgi: DEBUG: wsgi.url_scheme = http\nkeystone.common.wsgi: DEBUG: webob._body_file = (<io.BufferedReader object at 0xd9a9b10>, <eventlet.wsgi.Input object at 0xcceaf50>)\nkeystone.common.wsgi: DEBUG: SERVER_PORT = 37645\nkeystone.common.wsgi: DEBUG: wsgi.input = <io.BytesIO object at 0xd6b1830>\nkeystone.common.wsgi: DEBUG: openstack.context = {\'token_id\': \'MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA==\', \'is_admin\': False}\nkeystone.common.wsgi: DEBUG: HTTP_HOST = localhost:37645\nkeystone.common.wsgi: DEBUG: wsgi.multithread = True\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT = */*\nkeystone.common.wsgi: DEBUG: wsgi.version = (1, 0)\nkeystone.common.wsgi: DEBUG: SERVER_NAME = 127.0.0.1\nkeystone.common.wsgi: DEBUG: GATEWAY_INTERFACE = CGI/1.1\nkeystone.common.wsgi: DEBUG: wsgi.run_once = False\nkeystone.common.wsgi: DEBUG: wsgi.errors = <nose.plugins.xunit.Tee object at 0xd52e290>\nkeystone.common.wsgi: DEBUG: wsgi.multiprocess = False\nkeystone.common.wsgi: DEBUG: CONTENT_TYPE = text/plain\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT_ENCODING = gzip, deflate, compress\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: ******************** REQUEST BODY ********************\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: arg_dict: {\'token_id\': u\'MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA==\'}\nkeystone.policy.backends.rules: DEBUG: enforce admin_required: {\'user_id\': u\'foo\', u\'is_admin\': u\'1\', u\'roles\': [u\'admin\'], \'tenant_id\': u\'bar\'}\nkeystone.common.wsgi: DEBUG: ******************** RESPONSE HEADERS ********************\nkeystone.common.wsgi: DEBUG: Vary = X-Auth-Token\nkeystone.common.wsgi: DEBUG: Content-Length = 0\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: ******************** RESPONSE BODY ********************\nkeystone.common.wsgi: DEBUG: \naccess: INFO: 127.0.0.1 - - [30/Apr/2013:06:20:55 +0000] \"DELETE http://localhost:37645/v2.0/tokens/MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA%3D%3D HTTP/1.0\" 204 -\neventlet.wsgi.server: DEBUG: 127.0.0.1 - - [30/Apr/2013 06:20:55] \"DELETE /v2.0/tokens/MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA== HTTP/1.1\" 204 103 0.041011\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"DELETE /v2.0/tokens/MIIDCQYJKoZIhvcNAQcCoIIC+jCCAvYCAQExCTAHBgUrDgMCGjCCAZcGCSqGSIb3DQEHAaCCAYgEggGEeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC41ODIzNzYiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImRlc2NyaXB0aW9uIiwgImVuYWJsZWQiOiB0cnVlLCAiaWQiOiAiYmFyIiwgIm5hbWUiOiAiQkFSIn19LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiRk9PIn0sICJtZXRhZGF0YSI6IHsiaXNfYWRtaW4iOiAiMSIsICJyb2xlcyI6IFsiYWRtaW4iXX19fTGCAUkwggFFAgEBMIGkMIGeMQowCAYDVQQFEwE1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55dmFsZTESMBAGA1UEChMJT3BlblN0YWNrMREwDwYDVQQLEwhLZXlzdG9uZTElMCMGCSqGSIb3DQEJARYWa2V5c3RvbmVAb3BlbnN0YWNrLm9yZzEUMBIGA1UEAxMLU2VsZiBTaWduZWQCAREwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCNtC00uD8PpR7U3StpgQS+MVmviEKdRpS+IlTKwu+-PYMj7nx9E2-pPDkj9z+VBHDXOUIXwp2rcoEBiT1rlaT+-8ontEfyp53Ox51k442PQjVdPW81tRFU-4GiGY8pSS8jjoqUct2iRfO08ZbaVcXSXGyKhQXl-57cX8uLFMyAiA== HTTP/1.1\" 204 0\nkeystoneclient.client: DEBUG: No body was returned.\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\neventlet.wsgi.server: DEBUG: (16585) accepted (\'127.0.0.1\', 57514)\n\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.common.wsgi: DEBUG: ******************** REQUEST ENVIRON ********************\nkeystone.common.wsgi: DEBUG: SCRIPT_NAME = /v2.0\nkeystone.common.wsgi: DEBUG: webob.adhoc_attrs = {\'response\': <Response at 0xcceab50 200 OK>}\nkeystone.common.wsgi: DEBUG: REQUEST_METHOD = GET\nkeystone.common.wsgi: DEBUG: PATH_INFO = /tenants\nkeystone.common.wsgi: DEBUG: SERVER_PROTOCOL = HTTP/1.0\nkeystone.common.wsgi: DEBUG: HTTP_X_AUTH_TOKEN = MIICmAYJKoZIhvcNAQcCoIICiTCCAoUCAQExCTAHBgUrDgMCGjCCASYGCSqGSIb3DQEHAaCCARcEggETeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC44MTcyMDAiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW10sICJuYW1lIjogIkZPTyJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogW119fX0xggFJMIIBRQIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAV844IynOUp7ervaxDkoZtQdedtV2whs6-PTPscAwi9Uutzvw8p4GwubGXMPdR3xSxsFtlnOgKhVKs6o9WeLdTU52pPgxUkFHe5UQBYlOk8bt00P3MmJtyb7NBfC8DzngZDhfJRPVnA5xS2eLxnY9wkTDwxIL9WYlxuXO8PcuIVc=\nkeystone.common.wsgi: DEBUG: HTTP_USER_AGENT = python-keystoneclient\nkeystone.common.wsgi: DEBUG: REMOTE_PORT = 57514\nkeystone.common.wsgi: DEBUG: SERVER_NAME = 127.0.0.1\nkeystone.common.wsgi: DEBUG: REMOTE_ADDR = 127.0.0.1\nkeystone.common.wsgi: DEBUG: eventlet.input = <eventlet.wsgi.Input object at 0xc483f10>\nkeystone.common.wsgi: DEBUG: wsgi.url_scheme = http\nkeystone.common.wsgi: DEBUG: SERVER_PORT = 51398\nkeystone.common.wsgi: DEBUG: wsgi.input = <eventlet.wsgi.Input object at 0xc483f10>\nkeystone.common.wsgi: DEBUG: openstack.context = {\'token_id\': \'MIICmAYJKoZIhvcNAQcCoIICiTCCAoUCAQExCTAHBgUrDgMCGjCCASYGCSqGSIb3DQEHAaCCARcEggETeyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wNC0zMFQwNjoyMDo1NC44MTcyMDAiLCAiZXhwaXJlcyI6ICIyMDEzLTA1LTAxVDA2OjIwOjU0WiIsICJpZCI6ICJwbGFjZWhvbGRlciJ9LCAic2VydmljZUNhdGFsb2ciOiBbXSwgInVzZXIiOiB7InVzZXJuYW1lIjogIkZPTyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZm9vIiwgInJvbGVzIjogW10sICJuYW1lIjogIkZPTyJ9LCAibWV0YWRhdGEiOiB7ImlzX2FkbWluIjogMCwgInJvbGVzIjogW119fX0xggFJMIIBRQIBATCBpDCBnjEKMAgGA1UEBRMBNTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxEjAQBgNVBAoTCU9wZW5TdGFjazERMA8GA1UECxMIS2V5c3RvbmUxJTAjBgkqhkiG9w0BCQEWFmtleXN0b25lQG9wZW5zdGFjay5vcmcxFDASBgNVBAMTC1NlbGYgU2lnbmVkAgERMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAV844IynOUp7ervaxDkoZtQdedtV2whs6-PTPscAwi9Uutzvw8p4GwubGXMPdR3xSxsFtlnOgKhVKs6o9WeLdTU52pPgxUkFHe5UQBYlOk8bt00P3MmJtyb7NBfC8DzngZDhfJRPVnA5xS2eLxnY9wkTDwxIL9WYlxuXO8PcuIVc=\', \'is_admin\': False}\nkeystone.common.wsgi: DEBUG: HTTP_HOST = localhost:51398\nkeystone.common.wsgi: DEBUG: wsgi.multithread = True\nkeystone.common.wsgi: DEBUG: eventlet.posthooks = []\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT = */*\nkeystone.common.wsgi: DEBUG: wsgi.version = (1, 0)\nkeystone.common.wsgi: DEBUG: RAW_PATH_INFO = /v2.0/tenants\nkeystone.common.wsgi: DEBUG: GATEWAY_INTERFACE = CGI/1.1\nkeystone.common.wsgi: DEBUG: wsgi.run_once = False\nkeystone.common.wsgi: DEBUG: wsgi.errors = <nose.plugins.xunit.Tee object at 0xd52e290>\nkeystone.common.wsgi: DEBUG: wsgi.multiprocess = False\nkeystone.common.wsgi: DEBUG: CONTENT_TYPE = text/plain\nkeystone.common.wsgi: DEBUG: HTTP_ACCEPT_ENCODING = gzip, deflate, compress\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: ******************** REQUEST BODY ********************\nkeystone.common.wsgi: DEBUG: \nkeystone.common.wsgi: DEBUG: arg_dict: {}\nkeystone.common.wsgi: DEBUG: ******************** RESPONSE HEADERS ********************\nkeystone.common.wsgi: DEBUG: Vary = X-Auth-Token\nkeystone.common.wsgi: DEBUG: Content-Type = application/json\nkeystone.common.wsgi: DEBUG: Content-Length = 111\nkeystone.common.wsgi: DEBUG: \nkeystone.contrib.stats.core: WARNING: Unable to resolve API as either public or admin: localhost:51398\nkeystone.common.wsgi: DEBUG: ******************** RESPONSE BODY ********************\nkeystone.common.wsgi: DEBUG: {\"tenants_links\": [], \"tenants\": [{\"description\": \"description\", \"enabled\": true, \"id\": \"bar\", \"name\": \"BAR\"}]}\naccess: INFO: 127.0.0.1 - - [30/Apr/2013:06:20:55 +0000] \"GET http://localhost:51398/v2.0/tenants HTTP/1.0\" 200 111\neventlet.wsgi.server: DEBUG: 127.0.0.1 - - [30/Apr/2013 06:20:55] \"GET /v2.0/tenants HTTP/1.1\" 200 240 0.013447\n\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/tenants HTTP/1.1\" 200 111\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 34.82 secs:\n    9.22    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    7.61    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.15    TestAuthXML.test_domain_id_scoped_token_with_user_id\n    6.13    TestTrustAuth.test_trust_crud\n    5.71    IdentityTestCase.test_disable_domain\n----------------------------------------------------------------------\nRan 1272 tests in 758.746s\n\nFAILED (SKIP=84, errors=2, failures=2)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.20\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=68\n+ \'[\' 68 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KzddngYsh0\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/20\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/20/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2061100992.500.1367216775566.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1477236480.5.1377584585281.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-27 06:23:05',0,'2013-08-27 06:23:05',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #15','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/15/>\n\n------------------------------------------\n[...truncated 17374 lines...]\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Set operator role for tests that require creating a container\n2013-08-27 06:08:00 operator_role = Member\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [boto]\n2013-08-27 06:08:00 ssh_user = cirros\n2013-08-27 06:08:00 # This section contains configuration options used when executing tests\n2013-08-27 06:08:00 # with boto.\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # EC2 URL\n2013-08-27 06:08:00 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-08-27 06:08:00 # S3 URL\n2013-08-27 06:08:00 s3_url = http://127.0.0.1:3333\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-08-27 06:08:00 aws_access =\n2013-08-27 06:08:00 aws_secret =\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Image materials for S3 upload\n2013-08-27 06:08:00 # ALL content of the specified directory will be uploaded to S3\n2013-08-27 06:08:00 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # The manifest.xml files, must be in the s3_materials_path directory\n2013-08-27 06:08:00 # Subdirectories not allowed!\n2013-08-27 06:08:00 # The filenames will be used as a Keys in the S3 Buckets\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-08-27 06:08:00 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-08-27 06:08:00 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-08-27 06:08:00 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Instance type\n2013-08-27 06:08:00 instance_type = m1.nano\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # TCP/IP connection timeout\n2013-08-27 06:08:00 http_socket_timeout = 30\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Number of retries actions on connection or 5xx error\n2013-08-27 06:08:00 num_retries = 1\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Status change wait timout\n2013-08-27 06:08:00 build_timeout = 400\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Status change wait interval\n2013-08-27 06:08:00 build_interval = 1\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [orchestration]\n2013-08-27 06:08:00 # Status change wait interval\n2013-08-27 06:08:00 build_interval = 1\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Status change wait timout. This may vary across environments as some some\n2013-08-27 06:08:00 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-08-27 06:08:00 build_timeout = 300\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Instance type for tests. Needs to be big enough for a\n2013-08-27 06:08:00 # full OS plus the test workload\n2013-08-27 06:08:00 instance_type = m1.micro\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Name of heat-cfntools enabled image to use when launching test instances\n2013-08-27 06:08:00 # If not specified, tests that spawn instances will not run\n2013-08-27 06:08:00 #image_ref = ubuntu-vm-heat-cfntools\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # Name of existing keypair to launch servers with. The default is not to specify\n2013-08-27 06:08:00 # any key, which will generate a keypair for each test class\n2013-08-27 06:08:00 #keypair_name = heat_key\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [dashboard]\n2013-08-27 06:08:00 # URL where to find the dashboard home page\n2013-08-27 06:08:00 dashboard_url = http://127.0.0.1/\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # URL where to submit the login form\n2013-08-27 06:08:00 login_url = http://127.0.0.1/auth/login/\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [scenario]\n2013-08-27 06:08:00 # Directory containing image files\n2013-08-27 06:08:00 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # AMI image file name\n2013-08-27 06:08:00 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # ARI image file name\n2013-08-27 06:08:00 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # AKI image file name\n2013-08-27 06:08:00 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # ssh username for the image file\n2013-08-27 06:08:00 ssh_user = cirros\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 # specifies how many resources to request at once. Used for large operations\n2013-08-27 06:08:00 # testing.\"\n2013-08-27 06:08:00 large_ops_number = 0\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [cli]\n2013-08-27 06:08:00 # Enable cli tests\n2013-08-27 06:08:00 enabled = True\n2013-08-27 06:08:00 # directory where python client binaries are located\n2013-08-27 06:08:00 cli_dir = /usr/local/bin\n2013-08-27 06:08:00 # Number of seconds to wait on a CLI timeout\n2013-08-27 06:08:00 timeout = 15\n2013-08-27 06:08:00 \n2013-08-27 06:08:00 [service_available]\n2013-08-27 06:08:00 # Whether or not cinder is expected to be available\n2013-08-27 06:08:00 cinder = True\n2013-08-27 06:08:00 # Whether or not neutron is expected to be available\n2013-08-27 06:08:00 neutron = False\n2013-08-27 06:08:00 # Whether or not glance is expected to be available\n2013-08-27 06:08:00 glance = True\n2013-08-27 06:08:00 # Whether or not swift is expected to be available\n2013-08-27 06:08:00 swift = True\n2013-08-27 06:08:00 # Whether or not nova is expected to be available\n2013-08-27 06:08:00 nova = True\n2013-08-27 06:08:00 # Whether or not Heat is expected to be available\n2013-08-27 06:08:00 heat = True\n2013-08-27 06:08:00 # Whether or not horizon is expected to be available\n2013-08-27 06:08:00 horizon = True\n2013-08-27 06:08:00 ++ IFS=\' 	\n2013-08-27 06:08:00 \'\n2013-08-27 06:08:00 ++ set +o errexit\n2013-08-27 06:08:00 ++ init_tempest\n2013-08-27 06:08:00 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-08-27 06:08:00 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-27 06:08:00 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-08-27 06:08:00 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-08-27 06:08:00 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-08-27 06:08:00 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-08-27 06:08:00 ++ echo \'Prepare aki/ari/ami Images\'\n2013-08-27 06:08:00 Prepare aki/ari/ami Images\n2013-08-27 06:08:00 ++ cat\n2013-08-27 06:08:00 ++ source /opt/stack/new/devstack/accrc/demo/demo\n2013-08-27 06:08:00 +++ export EC2_ACCESS_KEY=a3c400d16f0847aab312d5de14033cb7\n2013-08-27 06:08:00 +++ EC2_ACCESS_KEY=a3c400d16f0847aab312d5de14033cb7\n2013-08-27 06:08:00 +++ export EC2_SECRET_KEY=2f2b06e3837c45a2ab9affc00c9511d7\n2013-08-27 06:08:00 +++ EC2_SECRET_KEY=2f2b06e3837c45a2ab9affc00c9511d7\n2013-08-27 06:08:00 +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-08-27 06:08:00 +++ EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-08-27 06:08:00 +++ export S3_URL=http://127.0.0.1:3333\n2013-08-27 06:08:00 +++ S3_URL=http://127.0.0.1:3333\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1629.g59f5cde.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpM57sLj\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpBIP5h2\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp4lctwh\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpTcih7s\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-2\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2479 tests in 843.124s\nFAILED (id=0, failures=2, skips=69)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-174855-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-174855.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-174855/15/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<767714638.9.1377324830873.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1477418587.16198705.1400766254970.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 09:44:14',-14400,'2014-05-22 13:44:14',NULL,'[openstack-dev] [Neutron][NFV] NFV BoF at design summit','\n\n----- Original Message -----\n> From: \"Kevin Benton\" <blak111 at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, May 22, 2014 2:48:37 AM\n> Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit\n> \n> >3. OpenStack itself should ( its own Compute Node/L3/Routing,  Controller\n> )  have (5 nine capable) reliability.\n> \n> Can you elaborate on this a little more? Reliability is pretty deployment\n> specific (e.g. database chosen, number of cluster members, etc). I\'m sure\n> nobody would disagree that OpenStack should be reliable, but without\n> specific issues to address it doesn\'t really give us a clear target.\n> \n> Thanks,\n> Kevin Benton\n\nI think this comment applies equally to the other items listed. There seemed to be agreement at the BoF that one of our key tasks/challenges is to boil down such high level NFV requirements to create actionable feature requests/proposals in the context of OpenStack.\n\nThanks,\n\nSteve\n\n\n','<CAO_F6JMru-P59ttjcgBmCrcPUOBgByW+kcMAV7J1THCGE9vqgQ@mail.gmail.com>',NULL),('<1477959177.106.1384150163446.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-11 06:09:23',0,'2013-11-11 06:09:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #55','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/55/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54e8d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54e8d90>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50f2110>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50f2110>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-89a3f3af-0a23-40ba-913e-f908d1e67c64\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:09:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:09:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:09:00+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'00\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:09:00-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'00\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:09:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e05250>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x20ffd50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.61 secs:\n    13.72    TestGlanceControl.test_bouncing\n    13.37    TestScrubber.test_delayed_delete\n    13.25    TestGlanceControl.test_reload\n    13.09    TestGlanceControl.test_respawn\n    12.18    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 444.217s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-55\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.TiedH3xOyz\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/55\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/55/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise34/55\n[SCP] Copying console log.\n\n\n','<1085755770.96.1383891089662.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1478478588.37.1372660533139.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-01 06:35:33',0,'2013-07-01 06:35:33',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-postgres-stable-grizzly #88','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/88/>\n\n\n\n','<1897170937.34.1372577359309.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1478773319.25.1387004061788.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-14 06:54:21',0,'2013-12-14 06:54:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-full-havana #7','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-full-havana/7/>\n\n------------------------------------------\n[...truncated 20900 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  200.050\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          100.091\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  70.433\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        50.537\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]          49.995\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        49.342\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     48.419\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         47.512\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_manual_disk_config[gate]   44.657\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        43.826\n\n======================================================================\nFAIL: setUpClass (tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON)\nsetUpClass (tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/api/compute/admin/test_aggregates.py\", line 42, in setUpClass\n    resp, hosts_all = cls.os_adm.hosts_client.list_hosts()\n  File \"tempest/services/compute/json/hosts_client.py\", line 37, in list_hosts\n    resp, body = self.get(url)\n  File \"tempest/common/rest_client.py\", line 305, in get\n    return self.request(\'GET\', url, headers)\n  File \"tempest/common/rest_client.py\", line 436, in request\n    resp, resp_body)\n  File \"tempest/common/rest_client.py\", line 478, in _error_checker\n    raise exceptions.Unauthorized()\nUnauthorized: Unauthorized\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 1324 tests in 1688.990s\n\nFAILED (failures=2, skipped=72)\nERROR: InvocationError: \'/bin/sh tools/pretty_tox.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])(^tempest\\\\.(api|scenario|thirdparty|cli)) \'\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-859504-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-859504.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-full-havana/devstack-precise-hpcloud-az2-859504/7/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1478906491.44.1383372795147.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:13:15',0,'2013-11-02 06:13:15',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-tempest-devstack-vm-cinder-stable-folsom #52','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/52/>\n\n\n\n',NULL,NULL),('<1479994500.130721421870477570.JavaMail.nobody@grtx1rmd001.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-21 20:01:17',0,'2015-01-21 20:01:17',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n Meeting January 28, 2015 Noon Pacific','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting January 28, 2015 Noon Pacific\nHost: Alan Clark\nDate: Wednesday, January 28, 2015\nTime: 12:00 pm, Pacific Standard Time (San Francisco, GMT-08:00)\n\nSession number: 924 559 806\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=tf8dac82330b876022a1dabfb372ca5eb\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb282c75f876eec6dc65f873c9c7a0353\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=322986372&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 924 559 806\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=td1173e8dae8f6dc055859304c18b49e9\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20150121/325612ba/attachment.html>\n\n',NULL,NULL),('<148003018.77.1353110873240.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-17 00:07:52',0,'2012-11-17 00:07:52',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #16','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/16/>\n\n------------------------------------------\n[...truncated 4829 lines...]\n++ line=\'signing_dir = /tmp/keystone-signing-nova\'\n++ echo /tmp/keystone-signing-nova\n+ [[ -z /tmp/keystone-signing-nova ]]\n+ sed -i -e \'/^\\[filter:authtoken\\]/,/^\\[.*\\]/ s|^\\(signing_dir[ \\t]*=[ \\t]*\\).*$|\\1/var/cache/nova|\' /etc/nova/api-paste.ini\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,n-cpu, ]]\n+ return 0\n+ sudo sysctl -w net.ipv4.ip_forward=1\nnet.ipv4.ip_forward = 1\n+ sudo modprobe nbd\n+ [[ kvm == \\k\\v\\m ]]\n+ sudo modprobe kvm\nFATAL: Module kvm not found.\n+ true\n+ \'[\' \'!\' -e /dev/kvm \']\'\n+ echo \'WARNING: Switching to QEMU\'\nWARNING: Switching to QEMU\n+ LIBVIRT_TYPE=qemu\n+ which selinuxenabled\n+ [[ qemu == \\l\\x\\c ]]\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net =~ q- ]]\n+ return 1\n+ [[ deb = \\d\\e\\b ]]\n+ LIBVIRT_DAEMON=libvirt-bin\n++ whoami\n+ sudo usermod -a -G libvirtd stack\n+ restart_service libvirt-bin\n+ [[ -z deb ]]\n+ [[ deb = \\d\\e\\b ]]\n+ sudo /usr/sbin/service libvirt-bin restart\nlibvirt-bin stop/waiting\nlibvirt-bin start/running, process 3699\n+ mkdir -p /opt/stack/data/nova/instances\n+ \'[\' -L /dev/disk/by-label/nova-instances \']\'\n+ cleanup_nova\n+ is_service_enabled n-cpu\n+ services=n-cpu\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,n-cpu, ]]\n+ return 0\n+ clean_iptables\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ bash\n+ awk \'{print \"sudo iptables\",$0}\'\n+ grep \'\\-A\'\n+ grep nova\n+ sed s/-A/-D/g\n+ sudo iptables -S -v\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed s/-A/-D/g\n+ grep \'\\-A\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ sudo iptables -S -v -t nat\n+ bash\n+ sed s/-N/-X/g\n+ awk \'{print \"sudo iptables\",$0}\'\n+ grep \'\\-N\'\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n+ grep nova\n+ sudo iptables -S -v\n+ sudo iptables -S -v -t nat\n+ bash\n+ awk \'{print \"sudo iptables -t nat\",$0}\'\n+ sed s/-N/-X/g\n+ grep \'\\-N\'\n+ grep nova\n+ sed \'s/-c [0-9]* [0-9]* //g\'\n++ sed \'s/.*\\(instance-[0-9a-fA-F]*\\).*/\\1/g\'\n++ grep instance-\n++ sudo virsh list --all\n+ instances=\n+ \'[\' \'!\' \'\' = \'\' \']\'\n+ sudo iscsiadm --mode node\n+ xargs sudo iscsiadm --mode node --logout\n+ cut -d \' \' -f2\n+ grep volume-\niscsiadm: no records found!\n+ sudo iscsiadm --mode node\n+ sudo iscsiadm --mode node --op delete\n+ cut -d \' \' -f2\n+ grep volume-\niscsiadm: no records found!\niscsiadm: no records found!\n+ true\n+ sudo rm -rf \'/opt/stack/data/nova/instances/*\'\n+ is_service_enabled horizon\n+ services=horizon\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-net, =~ ,horizon, ]]\n+ return 0\n+ setup_develop /opt/stack/horizon\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/horizon\n+ python setup.py egg_info\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning egg_info\ncreating horizon.egg-info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' horizon.egg-info/dependency_links.txt\n+ raw_links=\n++ xargs\n++ echo\n+ depend_links=\n++ \'[\' \'!\' -r horizon.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r horizon.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r horizon.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ [[ \'\' != \\F\\a\\l\\s\\e ]]\n+ PIP_MIRROR_OPT=--use-mirrors\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r horizon.egg-info/requires.txt\nDownloading/unpacking Django>=1.4 (from -r horizon.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2FD%2FDjango%2FDjango-1.4.2.tar.gz\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r horizon.egg-info/requires.txt (line 2))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_compressor%2Fdjango_compressor-1.2.tar.gz\n  Running setup.py egg_info for package django-compressor\n    \nDownloading/unpacking django-openstack-auth>=1.0.3 (from -r horizon.egg-info/requires.txt (line 3))\n  Downloading django_openstack_auth-1.0.4.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango_openstack_auth%2Fdjango_openstack_auth-1.0.4.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nRequirement already satisfied (use --upgrade to upgrade): python-cinderclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): python-glanceclient<2 in /opt/stack/python-glanceclient (from -r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/python-novaclient (from -r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.0 in /usr/local/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): python-swiftclient>1.1,<2 in /opt/stack/python-swiftclient (from -r horizon.egg-info/requires.txt (line 9))\nDownloading/unpacking pytz (from -r horizon.egg-info/requires.txt (line 10))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fp%2Fpytz%2Fpytz-2012h.tar.bz2\n  Running setup.py egg_info for package pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\nRequirement already satisfied (use --upgrade to upgrade): lockfile in /usr/lib/python2.7/dist-packages (from -r horizon.egg-info/requires.txt (line 11))\nDownloading/unpacking django-appconf>=0.4 (from django-compressor->-r horizon.egg-info/requires.txt (line 2))\n  Downloading django-appconf-0.5.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.python.org%2Fpackages%2Fsource%2Fd%2Fdjango-appconf%2Fdjango-appconf-0.5.tar.gz\n  Running setup.py egg_info for package django-appconf\n    \nRequirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): prettytable in /usr/local/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-cinderclient->-r horizon.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): warlock<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-novaclient->-r horizon.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): cliff>=1.2.1 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): pyparsing in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): jsonschema==0.2 in /usr/local/lib/python2.7/dist-packages (from warlock<2->python-glanceclient<2->-r horizon.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nRequirement already satisfied (use --upgrade to upgrade): cmd2 in /usr/lib/python2.7/dist-packages (from cliff>=1.2.1->python-quantumclient>=2.0->-r horizon.egg-info/requires.txt (line 8))\nInstalling collected packages: Django, django-compressor, django-openstack-auth, pytz, django-appconf\n  Running setup.py install for Django\n    changing mode of build/scripts-2.7/django-admin.py from 644 to 755\n    \n    changing mode of /usr/local/bin/django-admin.py to 755\n  Running setup.py install for django-compressor\n    \n  Running setup.py install for django-openstack-auth\n    \n  Running setup.py install for pytz\n    \n    warning: no files found matching \'*.pot\' under directory \'pytz\'\n    warning: no previously-included files found matching \'test_zdump.py\'\n  Running setup.py install for django-appconf\n    \nSuccessfully installed Django django-compressor django-openstack-auth pytz django-appconf\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nWarning: Could not import Horizon dependencies. This is normal during installation.\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to horizon.egg-info/requires.txt\nwriting horizon.egg-info/PKG-INFO\nwriting top-level names to horizon.egg-info/top_level.txt\nwriting dependency_links to horizon.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'*.css_t\' under directory \'doc\'\nwarning: no files found matching \'*.csv\' under directory \'horizon\'\nwarning: no files found matching \'*.template\' under directory \'horizon\'\nwarning: no files found matching \'*.js\' under directory \'openstack_dashboard\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no previously-included files found matching \'openstack_dashboard/local/local_settings.py\'\nwriting manifest file \'horizon.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/horizon.egg-link (link to .)\nAdding horizon 2013.1 to easy-install.pth file\n\nInstalled /opt/stack/horizon\nProcessing dependencies for horizon==2013.1\nerror: Installed distribution python-keystoneclient 0.2.0 conflicts with requirement python-keystoneclient>=0.1.2,<0.2\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/devstacklog.txt.2012-11-17-000449\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/16/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1480231108.35.1375510180248.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-03 06:09:40',0,'2013-08-03 06:09:40',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-python27-stable-grizzly #115','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/115/changes>\n\n\n\n','<50428238.23.1375423753456.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1481908529.23773717.1407002033536.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-02 13:53:53',-14400,'2014-08-02 17:53:53',NULL,'[Openstack-docs] Streamlined contribution workflow','\nThanks for the quick response Anne, just some further discussion inline.\n\n> > Digging through the git fossil-record in the openstack-manuals repo,\n> > I think I\'ve found at least a partial answer to my question in the\n> > form of this commit:\n> >\n> >   https://github.com/openstack/openstack-manuals/commit/cb407504\n> >\n> > This seems to be exactly what I was looking for: a lightweight model\n> > for contributions to documentation using a simple, widely-understood\n> > format (in this case, reStructuredText).\n> >\n> \n> Yes we are experimenting with it for the Heat Orchestration (HOT)\n> Templates, a chapter to go into the End User Guide.\n\nCool.\n\nIs the other content in the end-user guide also going to start off\nas RST just like the HOT chapter, or will it be mixed source?\n(i.e. some RST, some native docbook)\n\n> > My follow-on questions would be:\n> >\n> >  * is this model only possible if the content is being targetted\n> >    at a brand new guide, as opposed to a new chapter in an existing\n> >    guide (such as the admin guide)?\n> >\n> >\n> Right, we didn\'t want to start up a whole new document, so we need a\n> chapter in an existing. Sorry you missed that conversation at the Summit.\n\nWell, if by the summit conversation you mean this session:\n\n  https://etherpad.openstack.org/p/beefing-up-user-and-operations-guides\n\nI was there and recall the decision to put ceilometer into a new section\nof the existing guide.\n\nMy question was more along the lines of: *given* that we\'ve decided\nto put the ceilometer content into a new chapter of an existing guide,\nwould that decision make it impossible to use the new lightweight RST\ncontribution model?\n\n(i.e. is that model only applicable to content going into new guides?)\n\n> >  * is the intent that the documentation team will take this RST\n> >    content and translate it to docbook markup for PDF generation,\n> >    or is it going to be used as-is in the documentation base?\n> >\n> >\n> It can go as-is if it\'s written well enough. We hope to automate, but these\n> are early steps.\n\nCool :)\n\n> >  * now that the ceilometer team has started down the road of making\n> >    doc contributions in XML markup, would it makse sense to fully\n> >    or partially switch to the lightweight RST approach at this stage?\n> >\n> >\n> Here\'s what I assert:\n> - Teams who tend to write in RST only tend to _not_ cover very complex\n> topic for operators. Keystone and federation and PKI comes to mind, as well\n> as Swift and storage policies. They write in RST, but not in a lot of depth\n> (more from the code perspective), so operators are hurting for good info\n> and best practices. I don\'t support an approach that continues this pain.\n\nSure, I *absolutely* want to ease this pain also.\n\nBut TBH I didn\'t really see a strong connection between the format\nused to impart the information and the utility of that information to\noperators.\n\n(as long as the basic attributes are present in the format used, e.g.\nclarity, linkability, searchability, indexing etc.)\n\n> I think pro writers use pro tools and have the ability to advocate for a\n> particular audience.\n\nAbsolutely agree in the case of professional writers. The time invested\nin getting these pro writers up to speed with the professional tooling is\nof course time spent, as it\'ll pay off again and again into the future.\n\nSo no question from my side that the documentation team should continue\nto choose whatever tooling that works for them.\n\nMy train of thought was simply that the RoI calculus for this ramp-up\nperiod is a bit different for non-professional writers, i.e. external\nproject team members occasionally contributing content into the docs\npipeline.\n\n> - Standing up new guides again and again is not what we want, it won\'t\n> scale well and it\'s away from where I want us to go. I would like to get\n> away from such a book model but we\'ll need a new framework for that. I\'m\n> working on web design prior to moving to a new framework. We will still\n> need books but we also need a page approach, and we\'re working on that in\n> stages. So for now we fit into titles we have rather than continuing to add\n> more book titles. We are adding References Guides that can be automated\n> when we can since they are less time-consuming.\n\nAgreed that the proliferation of new guides is not the way to go.\n\n> - Complex doc needs require complex doc tools. We don\'t have a translation\n> toolchain in place for RST/Sphinx. We don\'t have a way to cross-include\n> content across projects in a meaningful way. We can\'t make print-ready PDF\n> from RST/Sphinx that\'s as high quality as the set we sell on Lulu. I can\'t\n> quickly drop those requirements just to add easier authoring.\n> - We don\'t have to rely only on devs for good docs. If you\'re having a hard\n> time finding resources then we need to find a technical writing resource\n> for your team. Being at Redhat you should have Docbook experts available to\n> you -- let\'s figure out how to connect you to technical writing resources\n> so your developers don\'t struggle.\n\nWell, given that time is short here, with juno-3 looming less\nthan 5 weeks away, I wouldn\'t have huge confidence in locating\nDocbook-expert resources in Red Hat who are re-assignable and\nin a position to ramp up on ceilometer in time to make a difference\nto getting this effort over the line.\n\nSo my instinct would be that we need to figure this out within\nthe constraints of the existing resources.\n\nIf I\'m hearing you correctly, it seems that we should stick with\nthe XML-markup for this effort, as reverting the RST would not be\na practical proposition.\n\nIn that case, I think we should try to streamline the process in\nother, more limited, ways.\n\nOne thing that I think could be useful would be to have a\nwell-defined agreed signal to indicate that the project-team\nauthor is satisfied with the initial rough content from a\ntechnical correctness and completeness PoV, and would like the\ndocumentation team to start with the revision/polish process on\nthe content.\n\nPerhaps we could agree that the author removing their WIP -1\non their patch(es) could act as that hand-over point?\n\nSo as long as the WIP -1 is still in place, the project author is\nstill iterating over the content for correctness & completeness.\nOnce that flag is taken off, it\'s open season on getting the doc\nteam\'s polish applied and the patch landed.\n\nWould that kind of approach make sense?\n\nThanks,\nEoghan\n\n\n','<CAD0KtVFW-O--3JG2d5P2Z7AEzGCNjpCtVjtbf1Byviq+DCHKqg@mail.gmail.com>',NULL),('<1482626853.7101268.1364392311972.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-27 09:51:51',-14400,'2013-03-27 13:51:51',NULL,'[openstack-dev] Updating pip-requires in the stable branch','Hi all,\n\nI\'m currently looking into bug 1157950 [0] for Horizon, which is about adding support for the new fixed_ips quota. The fix depends on a recent version of the Nova client (2.12.0) and I\'m wondering about the impact of having to update pip-requires when backporting it to Folsom. Would increasing the nova client required version cause trouble for the distributions packaging openstack? Without stable branches for the clients I\'m not sure what other solution there is. Any thought/best practice?\n\nThanks,\n\nJulie\n\n\n[0] https://bugs.launchpad.net/horizon/+bug/1157950\n\n\n','<1125139047.7014423.1364380751844.JavaMail.root@redhat.com>',NULL),('<1483102695.3100060.1416225659068.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-11-17 07:00:59',-18000,'2014-11-17 12:00:59',NULL,'[Openstack] Ceilometer Api error in Juno','\nHi,\n\nHow did you install ceilometer, using packages or direct from git?\n\nIf using packages, what OS are you working on? (Fedora, Ubuntu, CentOS etc.)\n\nNote that the bson.code module is provided by the python-bson package on\nFedora, which is a dependency of python-pymongo, which is in turn required\nby the ceilometer packages.\n\nI suspect there is a similar dependency structure on Ubuntu.\n\nThese dependencies are generally handled by the underlying package manager,\ni.e. the yum utility in the case of Fedora or CentOS.\n\nCheers,\nEoghan \n\n----- m channappa negalur <m.channappa.negalur at accenture.com> wrote:\n> Hello Geeks,\n> \n> I have installed three node openstack Juno. I was configuring ceilometer using mongodb as back end.\n> \n> I found my ceilometer-api is not starting and throwing some module error.\n> \n> root at Control:/var/log/ceilometer# tail -50 ceilometer-api.log\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 170, in _load_plugins\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer     self._on_load_failure_callback(self, ep, err)\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 50, in _default_on_load_failure\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer     raise err\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer ImportError: No module named bson.code\n> 2014-11-15 12:02:02.124 23900 TRACE ceilometer\n> 2014-11-16 22:22:30.649 17570 CRITICAL ceilometer [-] ImportError: No module named bson.code\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer Traceback (most recent call last):\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/bin/ceilometer-api\", line 10, in <module>\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     sys.exit(main())\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/cmd/api.py\", line 23, in main\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     srv = app.build_server()\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 157, in build_server\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     app = load_app()\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 153, in load_app\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return deploy.loadapp(\"config:\" + cfg_file)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 247, in loadapp\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return loadobj(APP, uri, name=name, **kw)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 272, in loadobj\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return context.create()\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 710, in create\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return self.object_type.invoke(self)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 203, in invoke\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     app = context.app_context.create()\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 710, in create\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return self.object_type.invoke(self)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py\", line 146, in invoke\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return fix_call(context.object, context.global_conf, **context.local_conf)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/paste/deploy/util.py\", line 55, in fix_call\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     val = callable(*args, **kw)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 181, in app_factory\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return VersionSelectorApplication()\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 104, in __init__\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     self.v2 = setup_app(pecan_config=pc)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/api/app.py\", line 68, in setup_app\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     storage.get_connection_from_config(cfg.CONF, \'metering\'),\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 82, in get_connection_from_config\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     return get_connection(url, namespace)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/__init__.py\", line 93, in get_connection\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     mgr = driver.DriverManager(namespace, engine_name)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 45, in __init__\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     verify_requirements=verify_requirements,\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/named.py\", line 55, in __init__\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     verify_requirements)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/extension.py\", line 170, in _load_plugins\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     self._on_load_failure_callback(self, ep, err)\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer   File \"/usr/lib/python2.7/dist-packages/stevedore/driver.py\", line 50, in _default_on_load_failure\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer     raise err\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer ImportError: No module named bson.code\n> 2014-11-16 22:22:30.649 17570 TRACE ceilometer\n> \n> \n> Looking for some help..\n> \n> Regards,\n> Malleshi CN\n> \n> ________________________________\n> \n> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.\n> ______________________________________________________________________________________\n> \n> www.accenture.com\n\n\n','<21cdf970ae844cbc9da5d212b6586d59@BY2PR42MB181.048d.mgd.msft.net>',NULL);
INSERT INTO `messages` VALUES ('<1483410400.8.1376375364441.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-13 06:29:24',0,'2013-08-13 06:29:24',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #6','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/6/>\n\n------------------------------------------\n[...truncated 21040 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=3.63 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 3.630/3.630/3.630/0.000 ms\n++ cinder list\n++ grep ex-vol-6b173758\n++ head -1\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1376374283\n+ cinder create --display_name ex-vol-6b173758 --display_description \'test volume: ex-vol-6b173758\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-13T06:11:23.737508      |\n| display_description |     test volume: ex-vol-6b173758     |\n|     display_name    |           ex-vol-6b173758            |\n|          id         | 603cd5db-b823-4228-9122-94e5bb41433d |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6b173758 | grep available; do sleep 1; done\'\n| 603cd5db-b823-4228-9122-94e5bb41433d | available | ex-vol-6b173758 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376374285\n+ echo \'Completed cinder create in 2 seconds\'\nCompleted cinder create in 2 seconds\n++ cinder list\n++ grep ex-vol-6b173758\n++ get_field 1\n++ head -1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 603cd5db-b823-4228-9122-94e5bb41433d | available | ex-vol-6b173758 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=603cd5db-b823-4228-9122-94e5bb41433d\n+ die_if_not_set 164 VOL_ID \'Failure retrieving volume ID for ex-vol-6b173758\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1376374286\n+ nova volume-attach 4ec31fc6-6996-42a1-aef7-11b77287b028 603cd5db-b823-4228-9122-94e5bb41433d /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 4ec31fc6-6996-42a1-aef7-11b77287b028 |\n| id       | 603cd5db-b823-4228-9122-94e5bb41433d |\n| volumeId | 603cd5db-b823-4228-9122-94e5bb41433d |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6b173758 | grep in-use; do sleep 1; done\'\n| 603cd5db-b823-4228-9122-94e5bb41433d | in-use | ex-vol-6b173758 |  1   |     None    |  False   | 4ec31fc6-6996-42a1-aef7-11b77287b028 |\n++ date +%s\n+ end_time=1376374291\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-6b173758\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 603cd5db-b823-4228-9122-94e5bb41433d | in-use | ex-vol-6b173758 |  1   |     None    |  False   | 4ec31fc6-6996-42a1-aef7-11b77287b028 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=4ec31fc6-6996-42a1-aef7-11b77287b028\n+ die_if_not_set 178 VOL_ATTACH \'Failure retrieving ex-vol-6b173758 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 4ec31fc6-6996-42a1-aef7-11b77287b028 != 4ec31fc6-6996-42a1-aef7-11b77287b028 ]]\n++ date +%s\n+ start_time=1376374292\n+ nova volume-detach 4ec31fc6-6996-42a1-aef7-11b77287b028 603cd5db-b823-4228-9122-94e5bb41433d\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6b173758 | grep available; do sleep 1; done\'\n| 603cd5db-b823-4228-9122-94e5bb41433d | available | ex-vol-6b173758 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376374295\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1376374295\n+ cinder delete 603cd5db-b823-4228-9122-94e5bb41433d\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-6b173758; do sleep 1; done\'\n| 603cd5db-b823-4228-9122-94e5bb41433d | deleting | ex-vol-6b173758 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376374298\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 4ec31fc6-6996-42a1-aef7-11b77287b028\n+ timeout 60 sh -c \'while nova list | grep -q 4ec31fc6-6996-42a1-aef7-11b77287b028; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1557.g3049dc9.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpeUzFjq\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpmmB4s7\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpUB79v1\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpcLEvin\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-2\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 28, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2456 tests in 992.555s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/rabbitmq/rabbit at devstack-1376372494-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/rabbitmq/rabbit at devstack-1376372494.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-7343/6/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2027232466.2.1376202476995.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1484751610.80.1383891148129.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-08 06:12:28',0,'2013-11-08 06:12:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #51','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/51/>\n\n------------------------------------------\n[...truncated 1480 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3fc43d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3252e10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3252e10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-bf7943b8-6295-4428-a25d-7956aba1bdaf\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x21e6b90> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x21e6b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x21e6b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x21e6b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:11:45Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'45\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'45\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:11:45Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'45\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'45\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:11:45+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'45\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'45\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:11:45-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'45\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'45\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:11:45Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'45\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'45\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x537e090>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0xea1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.72 secs:\n    26.50    TestScrubber.test_scrubber_app\n    20.81    TestScrubber.test_delayed_delete\n    14.90    TestGlanceControl.test_reload\n    14.90    TestRootApi.test_version_configurations\n    14.61    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 646.793s\n\nFAILED (SKIP=42, failures=3)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.51\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=124\n+ \'[\' 124 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.s61aNvQkUj\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/51/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-3/51\n[SCP] Copying console log.\n\n\n','<280449328.76.1383718357070.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1485464554.2288072.1376522599475.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-14 19:23:19',-14400,'2013-08-14 23:23:19',NULL,'[Openstack-docs] Increasing Jenkins timeout?','----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: Openstack-docs at lists.openstack.org\n> Sent: Wednesday, August 14, 2013 2:59:14 AM\n> Subject: [Openstack-docs] Increasing Jenkins timeout?\n> \n> I\'ve seen several times in the last days that Jenkins thought it run\n> into a timeout - while the job was still running. Currently, the full\n> openstack-manuals job needs at least 26 minutes and has a timeout of 30\n> mins.\n> \n> Could somebody increase the timeout from 30mins to a larger value,\n> please? I propose to go for 40.\n> \n> The alternative would be to find ways to speed up the building of the\n> manuals. Increasing the Jenkins timeout seems to me the short-term solution.\n\n+1 from me too having just run into it.\n\nThanks,\n\nSteve\n\n\n','<520B2AC2.2090609@suse.com>',NULL),('<1485739739.406.1355271641988.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-12 00:20:41',0,'2012-12-12 00:20:41',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #72','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/72/>\n\n\n\n','<1737254898.387.1355184921208.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1486168947.5969307.1404653327264.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-06 09:28:47',-14400,'2014-07-06 13:28:47',NULL,'[openstack-dev] [oslo] Asyncio and oslo.messaging','\n\n> This is an attempt to summarize a really useful discussion that Victor,\n> Flavio and I have been having today. At the bottom are some background\n> links - basically what I have open in my browser right now thinking\n> through all of this.\n\nThanks for the detailed summary, it puts a more flesh on the bones\nthan a brief conversation on the fringes of the Paris mid-cycle.\n\nJust a few clarifications and suggestions inline to add into the\nmix.\n\n> We\'re attempting to take baby-steps towards moving completely from\n> eventlet to asyncio/trollius. The thinking is for Ceilometer to be the\n> first victim.\n\nFirst beneficiary, I hope :)\n \n> Ceilometer\'s code is run in response to various I/O events like REST API\n> requests, RPC calls, notifications received, etc. We eventually want the\n> asyncio event loop to be what schedules Ceilometer\'s code in response to\n> these events. Right now, it is eventlet doing that.\n\nYes.\n\nAnd there is one other class of stimulus, also related to eventlet,\nthat is very important for triggering the execution of ceilometer\nlogic. That would be the timed tasks that drive polling of:\n\n * REST APIs provided by other openstack services \n * the local hypervisor running on each compute node\n * the SNMP daemons running at host-level etc.\n\nand also trigger periodic alarm evaluation.\n\nIIUC these tasks are all mediated via the oslo threadgroup\'s\nusage of eventlet.greenpool[1]. Would this logic also be replaced\nas part of this effort?\n\n> Now, because we\'re using eventlet, the code that is run in response to\n> these events looks like synchronous code that makes a bunch of\n> synchronous calls. For example, the code might do some_sync_op() and\n> that will cause a context switch to a different greenthread (within the\n> same native thread) where we might handle another I/O event (like a REST\n> API request)\n\nJust to make the point that most of the agents in the ceilometer\nzoo tend to react to just a single type of stimulus, as opposed\nto a mix of dispatching from both message bus and the REST API.\n\nSo to classify, we\'d have:\n\n * compute-agent: timer tasks for polling\n * central-agent: timer tasks for polling\n * notification-agent: dispatch of \"external\" notifications from\n   the message bus\n * collector: dispatch of \"internal\" metering messages from the\n   message bus\n * api-service: dispatch of REST API calls\n * alarm-evaluator: timer tasks for alarm evaluation\n * alarm-notifier: dispatch of \"internal\" alarm notifications\n\nIIRC, the only case where there\'s a significant mix of trigger\nstyles is the partitioned alarm evaluator, where assignments of\nalarm subsets for evaluation is driven over RPC, whereas the\nactual thresholding is triggered by a timer.\n\n> Porting from eventlet\'s implicit async approach to asyncio\'s explicit\n> async API will be seriously time consuming and we need to be able to do\n> it piece-by-piece.\n\nYes, I agree, a step-wise approach is the key here.\n\nSo I\'d love to have some sense of the time horizon for this\neffort. It clearly feels like a multi-cycle effort, so the main\nquestion in my mind right now is whether we should be targeting\nthe first deliverables for juno-3?\n\nThat would provide a proof-point in advance of the K* summit,\nwhere I presume the task would be get wider buy-in for the idea.\n\nIf it makes sense to go ahead and aim the first baby steps for\njuno-3, then we\'d need to have a ceilometer-spec detailing these\nchanges. This would need to be proposed by say EoW and then\nlanded before the spec acceptance deadline for juno (~July 21st).\n\nWe could use this spec proposal to dig into the perceived benefits\nof this effort:\n\n * the obvious win around getting rid of the eventlet black-magic\n * plus possibly other benefits such as code clarity and ease of\n   maintenance\n\nand OTOH get a heads-up on the risks:\n\n * possible immaturity in the new framework?\n * overhead involved in contributors getting to grips with the\n   new coroutine model\n\n> The question then becomes what do we need to do in order to port a\n> single oslo.messaging RPC endpoint method in Ceilometer to asyncio\'s\n> explicit async approach?\n\nOne approach would be to select one well-defined area of ceilometer\nas an initial test-bed for these ideas.\n\nAnd one potential candidate for that would be the partitioned alarm\nevaluator, which uses:\n\n 1. fan-out RPC for the heartbeats underpinning master-slave\n    coordination\n 2. RPC calls for alarm allocations and assignments\n\nI spoke to Cyril Roelandt at the mid-cycle, who is interested in:\n\n * replacing #1 with the tooz distributed co-ordination library[2]\n * and also possibly replacing #2 with taskflow\n\nThe benefit of using taskflow for \"sticky\" task assignments isn\'t\n100% clear, so it may actually make better sense to just use tooz\nfor the leadership election, and the new asyncio model for #2.\n\nStarting there would have the advantage of being out on the side\nof the main ceilometer pipeline.\n\nHowever, if we do decide to go ahead with taskflow, then we could\nfine another good starting point for asyncio as an alternative.\n\n>   - when all of ceilometer has been ported over to asyncio coroutines,\n>     we can stop monkey patching, stop using greenio and switch to the\n>     asyncio event loop\n\n... kick back and light a cigar! :)\n\nCheers,\nEoghan\n\n[1] https://github.com/openstack/oslo-incubator/blob/master/openstack/common/threadgroup.py#L72\n[2] https://github.com/stackforge/tooz\n[3] https://wiki.openstack.org/wiki/TaskFlow\n\n\n','<1404401278.2723.59.camel@sorcha>',NULL),('<1486473234.8844026.1398182280803.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-22 11:58:00',-14400,'2014-04-22 15:58:00',NULL,'[openstack-dev] [nova] Looking for experienced guide to\n understand	libvirt driver','Hi Scott,\n\nI\'ve actually been diving through those Nova code paths recently, to work on a BP\nto move the Nova libvirt driver to use libvirt storage pools for image backends,\nso I may be able to help you.  Just FYI, if my blueprint gets accepted, it may\nactually reduce the amount of code that you have to write, since libvirt already\nhas a (limitted) storage driver for sheepdog (see the BP here: https://review.openstack.org/#/c/86947/)\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Scott Devoid\" <devoid at anl.gov>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, April 21, 2014 7:38:13 PM\nSubject: [openstack-dev] [nova] Looking for experienced guide to understand	libvirt driver\n\nHi folks! \n\nI am working to add Sheepdog as a disk backend for the libvirt driver. I have a blueprint started and an early version of the code. However I am having trouble working my way thorough the code in the libvirt driver. The storage code doesn\'t feel vary modular to start with and my changes only seem to make it worse; e.g. adding more if blocks to 400 line functions. \n\nIs there an experienced contributor that could spend 30 minutes walking through parts of the code? \n\n- Blueprint: https://review.openstack.org/#/c/82584/ \n- Nova code: https://review.openstack.org/#/c/74148/ \n- Devstack code: https://review.openstack.org/#/c/89434/ \n\nThanks, \n~ Scott \n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJrQjSvV=tK7idmhQs_BUEfaAVDFV-7oA1OjPa8k9FPiBykxwA@mail.gmail.com>',NULL),('<1487240.ESrPn4LiIK@linux-9244.site>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-25 11:29:38',28800,'2013-09-25 03:29:38',NULL,'[Openstack] How to set up cinder with SAN','Hi Vladimir,\n\nIt seems you want vm to access storage via fibre channel.  \nI did the same thing in a test environment the other day.  \nI connected devices as shown in the diagram below:\n\nYou should configure all nova nodes follow this:\n\nhttp://docs.openstack.org/grizzly/openstack-compute/admin/content/fibrechannel.html\n\nand also configure cinder node like this:\n\nhttp://docs.openstack.org/grizzly/openstack-block-storage/admin/content/hp-3par-driver.html\n\nThen cinder will take over the control of disk array, create or delete volume etc.  When a \nvolume attached to vm, vm can access it via fibre channel directly.\n\nBut I don\'t think HP p2000 is supported, check this:\nhttps://wiki.openstack.org/wiki/CinderSupportMatrix\n\n\n\n\n\nOn Tuesday, September 24, 2013 10:44:46 AM Vladimir Parf wrote:\n\n\nHi! Please help sort out the issue with the setting cinder and SAN. I have a SAN storage HP \nP 2000, and 10 blade servers all connected via Fibre Channel. \nI can not understand how I configure Cinder. Do I understand correctly that each Compute-\nnode I will have to connect the LUN. \n  \nFor example: \n  \ncompute-node-2 => LUN 10TB (+LVM); \ncompute-node-3 => LUN 10TB (+LVM); \ncompute-node-4 => LUN 10TB (+LVM); \ncompute-node-5 => LUN 10TB (+LVM); \n  \nWhether to adjust the cinder on each compute-nodes ? How then adjust cinder ins master \nnode? \n\n\n-- \n~ Kai\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130925/85db208f/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: f-c1.png\nType: image/png\nSize: 75399 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130925/85db208f/attachment.png>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: f-c1.png\nType: image/png\nSize: 82392 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130925/85db208f/attachment-0001.png>\n\n','<524134DE.1060307@yandex.ru>',NULL),('<148735080.152.1356307479587.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-24 00:04:39',0,'2012-12-24 00:04:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #84','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/84/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/84\n[SCP] Copying console log.\n\n\n','<1283591334.130.1356221149247.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1487406004.6604694.1397662924400.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-16 11:42:04',-14400,'2014-04-16 15:42:04',NULL,'[openstack-dev] [neutron] Neutron BP review process for Juno','Additionally, storing lots of binary blobs in a Git repo is sub-optimal,\nas the repo size ballons very quickly.  Storing images on the Wiki, or\nelsewhere that has stable image hosting, is a much better solution, IMHO\n(but try asciiflow or asciiflow traditional first!).\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Kyle Mestery\" <mestery at noironetworks.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, April 16, 2014 9:52:09 AM\nSubject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno\n\nActually, +1 to that Salvatore! I\'ve found asciiflow.com to be superb\nfor these types of things.\n\nOn Wed, Apr 16, 2014 at 8:39 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n> if the image you\'re adding is a diagram, I would think about asciiflow.com\n> first!\n>\n>\n> On 16 April 2014 15:09, Kyle Mestery <mestery at noironetworks.com> wrote:\n>>\n>> I think the problem is that your spec should be at the toplevel of the\n>> juno directory, and that\'s why the UT is failing. Can you move your\n>> spec up a level, including the image? You can create a spec images\n>> directory to put them in there and reference it in the spec as well if\n>> you want.\n>>\n>> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam\n>> <sumitnaiksatam at gmail.com> wrote:\n>> > What\'s the convention for adding images to the patch? The following\n>> > directory structure seemed logical to me (but the current UT will not\n>> > allow it):\n>> >\n>> > specs/juno/<bp-name>/<bp-name>.rst\n>> > specs/juno/<bp-name>/images/<image1>.png\n>> >\n>> > Thanks,\n>> > ~Sumit.\n>> >\n>> >\n>> >\n>> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin <carl at ecbaldwin.net>\n>> > wrote:\n>> >> +1.  I think we\'ll like this process better.  I hope to have some of\n>> >> the first blueprints to propose to the new repository very soon.\n>> >>\n>> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery\n>> >> <mestery at noironetworks.com> wrote:\n>> >>> Given the success the Nova team has had in handling reviews using\n>> >>> their new nova-specs gerrit repository, I think it makes a lot of\n>> >>> sense for Neutron to do the same. With this in mind, I\'ve added\n>> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,\n>> >>> this is how Neutron BPs will be handled by the Neutron core team. If\n>> >>> you are currently working on a BP or code for Juno which is attached\n>> >>> to a BP, please file the BP using the process here [1].\n>> >>>\n>> >>> Given this is our first attempt at using this for reviews, I\n>> >>> anticipate there may be a few hiccups along the way. Please reply on\n>> >>> this thread or reach out in #openstack-neutron and we\'ll sort through\n>> >>> whatever issues we find.\n>> >>>\n>> >>> Thanks!\n>> >>> Kyle\n>> >>>\n>> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron\n>> >>>\n>> >>> _______________________________________________\n>> >>> OpenStack-dev mailing list\n>> >>> OpenStack-dev at lists.openstack.org\n>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >>\n>> >> _______________________________________________\n>> >> OpenStack-dev mailing list\n>> >> OpenStack-dev at lists.openstack.org\n>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >\n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi3Spx48FwwDPOeBteoipme0g0K2kOwThR+XOq9-wZr-nA@mail.gmail.com>',NULL),('<1487523272.248.1356739463868.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-29 00:04:23',0,'2012-12-29 00:04:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-folsom #89','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/89/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.44 secs:\n    2.41    Kc11TestCase.test_admin_requires_adminness\n    2.30    KcEssex3TestCase.test_admin_requires_adminness\n    2.15    KcMasterTestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.07    KcEssex3TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 46.983s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b2\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.SmqfBMhEDI\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/89\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-folsom/89/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<49631232.229.1356653079196.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1487566068.67.1365574580596.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-10 06:16:20',0,'2013-04-10 06:16:20',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-folsom #191','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/191/>\n\n------------------------------------------\n[...truncated 12867 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/nose/plugins/xunit.py\",> line 136, in write\n    s.write(*args)\nRuntimeError: maximum recursion depth exceeded while calling a Python object\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: S3 Objectstore listening on 127.0.0.1:3333\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_unknown_bucket (nova.tests.test_objectstore.S3APITestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/tests/test_objectstore.py\",> line 65, in setUp\n    port=FLAGS.s3_port)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/nova/wsgi.py\",> line 72, in __init__\n    self._socket = eventlet.listen((host, port), backlog=backlog)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/eventlet/convenience.py\",> line 38, in listen\n    sock.bind(addr)\n  File \"/usr/lib/python2.7/socket.py\", line 224, in meth\n    return getattr(self._sock,name)(*args)\nerror: [Errno 98] Address already in use\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 25.83 secs:\n    7.84    ComputeTestCase.test_state_revert\n    5.31    CloudTestCase.test_instance_initiated_shutdown_behavior\n    5.06    StorwizeSVCDriverTestCase.test_storwize_svc_flashcopy\n    4.47    ServersTest.test_create_multiple_servers\n    3.15    CloudTestCase.test_create_image_with_reboot\n----------------------------------------------------------------------\nRan 3726 tests in 624.296s\n\nFAILED (SKIP=7, errors=11)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==1.0.4\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosehtmloutput==0.0.4\nnova==2012.2.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nova/tests/nose_results.html\n+ \'[\' -f ./nova/tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nova/tests/nose_results.html\n+ passcount=457\n+ \'[\' 457 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.0oEX57DQEu\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-folsom/191\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-nova-python27-stable-folsom/191/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1007073706.50.1365488201054.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1487675142.261154.1399576934795.JavaMail.root@mail>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-08 15:22:14',-14400,'2014-05-08 19:22:14',NULL,'[openstack-dev] [Ceilometer] [MONaaS] Monitoring as a Service','Hello everyone!\n\nI have participated to today\'s Ceilometer meeting.\n\nYou can read it here (2014-05-08): http://eavesdrop.openstack.org/meetings/ceilometer/2014/\n\nAs proposed by eglynn, MONaaS will become a recurring topic in Ceilometer\'s meetings. It was proposed to start adding MONaaS as a recurring topic starting the week after the summit, that would be May 22.\n\nUntil then, I suggest you try contributing to the Etherpad. The first problem that we have to solve is to define the project\'s scope. In order to correctly answer to this question, we need a detailed list of possible use cases. Don\'t hesitate to work on this on the Etherpad before May 22.\n\nA sub-team could be formed to work on the blueprint, this team would have regular MONaaS-specific meeting. I will be proposing this on May 22.\n\nTo avoid all confusion with Metal as a Service, I have renamed pages to MONaaS.\nNew wiki page: https://wiki.openstack.org/wiki/MONaaS\nNew Etherpad: https://etherpad.openstack.org/p/MONaaS\n\nBest regards,\nAlexandre Viau\n\n\n','<1355689835.111580.1399565124942.JavaMail.root@mail>',NULL),('<1487914690.66.1360131487222.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-06 06:18:07',0,'2013-02-06 06:18:07',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #128','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/128/>\n\n\n\n','<1743852786.49.1360045052132.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<148815725.76.1373609323431.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-12 06:08:43',0,'2013-07-12 06:08:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-python27-stable-grizzly #93','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/93/changes>\n\n\n\n','<1118869816.64.1373522998250.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1489022515.322.1366786568701.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-24 06:56:08',0,'2013-04-24 06:56:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #14','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/14/changes>\n\nChanges:\n\n[Gary Kotton] Make \"shared\" filter more compatible with diff DBs\n\n[Gary Kotton] Add missing security group quota settings to quantum.conf\n\n[Gary Kotton] Improve the deprecated message about DEFAULT.root_helper\n\n------------------------------------------\n[...truncated 4324 lines...]\n    test_network_update_end_admin_state_up                       OK    0.01\n    test_port_delete_end                                         OK    0.01\n    test_port_delete_end_unknown_port                            OK    0.01\n    test_port_update_end                                         OK    0.01\n    test_refresh_dhcp_helper_exception_during_rpc                OK    0.01\n    test_refresh_dhcp_helper_no_dhcp_enabled_networks            OK    2.23\n    test_subnet_update_end                                       OK    0.01\n    test_subnet_update_end_delete_payload                        OK    0.01\n    test_subnet_update_end_restart                               OK    0.01\nTestDhcpLeaseRelay\n    test_handler_invalid_data                                    OK    0.01\n    test_handler_other_exception                                 OK    0.00\n    test_handler_valid_data                                      OK    0.01\n    test_init_relay_socket_path_no_prev_socket                   OK    0.00\n    test_init_relay_socket_path_prev_socket_exists               OK    0.00\n    test_init_relay_socket_path_prev_socket_unlink_failure       OK    0.00\n    test_start                                                   OK    0.01\nTestDhcpPluginApiProxy\n    test_get_active_networks                                     OK    0.00\n    test_get_dhcp_port                                           OK    0.00\n    test_get_network_info                                        OK    0.00\n    test_release_dhcp_port                                       OK    0.00\n    test_release_port_fixed_ip                                   OK    0.00\n    test_update_lease_expiration                                 OK    0.01\nTestDictModel\n    test_basic_dict                                              OK    0.00\n    test_dict_contains_list                                      OK    0.00\n    test_dict_contains_list_of_dicts                             OK    0.00\n    test_dict_has_sub_dict                                       OK    0.00\nTestLogArgs\n    test_log_args_with_log_dir_and_file                          OK    0.00\n    test_log_args_without_log_dir                                OK    0.00\n    test_log_args_without_log_dir_and_file                       OK    0.00\n    test_log_args_without_log_file                               OK    0.00\nTestNetworkCache\n    test_get_network_by_id                                       OK    0.00\n    test_get_network_by_port_id                                  OK    0.00\n    test_get_network_by_subnet_id                                OK    0.00\n    test_get_network_ids                                         OK    0.00\n    test_get_port_by_id                                          OK    0.00\n    test_put_network                                             OK    0.00\n    test_put_network_existing                                    OK    0.00\n    test_put_port                                                OK    0.00\n    test_put_port_existing                                       OK    0.00\n    test_remove_network                                          OK    0.00\n    test_remove_port_existing                                    OK    0.00\nExtensionExtendedAttributeTestCase\n    test_ext_test_resource_create                                OK    0.09\n    test_ext_test_resource_get                                   OK    0.03\nExtraRouteDBTestCase\n    test_create_external_network_admin_suceeds                   OK    0.25\n    test_create_external_network_non_admin_fails                 OK    0.16\n    test_create_floating_non_ext_network_returns_400             OK    0.38\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.21\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.13\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.14\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.52\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.51\n    test_create_port_external_network_admin_suceeds              OK    0.30\n    test_create_port_external_network_non_admin_fails            OK    0.26\n    test_floating_ip_direct_port_delete_returns_409              OK    3.16\n    test_floatingip_crd_ops                                      OK    0.81\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    0.85\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    0.73\n    test_floatingip_list_with_pagination                         OK    0.60\n    test_floatingip_list_with_pagination_reverse                 OK    2.63\n    test_floatingip_list_with_sort                               OK    0.70\n    test_floatingip_port_delete                                  OK    0.92\n    test_floatingip_update                                       OK    0.74\n    test_floatingip_with_assoc                                   OK    1.05\n    test_floatingip_with_assoc_fails                             OK    2.81\n    test_floatingips_op_agent                                    OK    0.71\n    test_get_network_succeeds_without_filter                     OK    0.16\n    test_interfaces_op_agent                                     OK    0.38\n    test_l3_agent_routers_query_floatingips                      OK    0.79\n    test_l3_agent_routers_query_gateway                          OK    0.39\n    test_l3_agent_routers_query_ignore_interfaces_with_moreThanOneIpOK    0.40\n    test_l3_agent_routers_query_interfaces                       OK    3.06\n    test_list_nets_external                                      OK    0.27\n    test_list_nets_external_pagination                           SKIP\n    test_network_filter_hook_admin_context                       OK    0.25\n    test_network_filter_hook_nonadmin_context                    OK    0.21\n    test_network_update_external                                 OK    0.52\n    test_network_update_external_failure                         OK    0.40\n    test_nexthop_is_port_ip                                      OK    0.38\n    test_no_destination_route                                    OK    0.37\n    test_no_nexthop_route                                        OK    0.37\n    test_none_destination                                        OK    0.38\n    test_none_nexthop                                            OK    2.65\n    test_route_update_with_multi_routes                          OK    0.44\n    test_route_update_with_one_route                             OK    0.44\n    test_router_add_gateway                                      OK    0.58\n    test_router_add_gateway_dup_subnet1_returns_400              OK    0.53\n    test_router_add_gateway_dup_subnet2_returns_400              OK    0.39\n    test_router_add_gateway_invalid_network_returns_404          OK    0.19\n    test_router_add_gateway_net_not_external_returns_400         OK    0.29\n    test_router_add_gateway_no_subnet_returns_400                OK    0.26\n    test_router_add_gateway_tenant_ctx                           OK    0.39\n    test_router_add_interface_dup_subnet1_returns_400            OK    2.48\n    test_router_add_interface_dup_subnet2_returns_400            OK    0.44\n    test_router_add_interface_no_data_returns_400                OK    0.18\n    test_router_add_interface_overlapped_cidr_returns_400        OK    0.60\n    test_router_add_interface_port                               OK    0.37\n    test_router_add_interface_port_bad_tenant_returns_404        OK    0.37\n    test_router_add_interface_subnet                             OK    0.36\n    test_router_add_interface_subnet_with_bad_tenant_returns_404 OK    0.44\n    test_router_add_interface_subnet_with_port_from_other_tenant OK    2.75\n    test_router_create                                           OK    0.18\n    test_router_create_with_gwinfo                               OK    0.33\n    test_router_delete                                           OK    0.20\n    test_router_delete_subnet_inuse_returns_409                  OK    0.36\n    test_router_delete_with_floatingip_existed_returns_409       OK    0.68\n    test_router_delete_with_port_existed_returns_409             OK    0.39\n    test_router_gateway_op_agent                                 OK    0.39\n    test_router_interface_in_use_by_route                        OK    0.44\n    test_router_list                                             OK    0.25\n    test_router_list_with_pagination                             OK    2.52\n    test_router_list_with_pagination_reverse                     OK    0.38\n    test_router_list_with_parameters                             OK    0.44\n    test_router_list_with_sort                                   OK    0.31\n    test_router_remove_interface_inuse_returns_409               OK    0.35\n    test_router_remove_interface_wrong_port_returns_404          OK    0.50\n    test_router_remove_interface_wrong_subnet_returns_409        OK    0.45\n    test_router_show                                             OK    0.20\n    test_router_update                                           OK    0.20\n    test_router_update_delete_routes                             OK    0.47\n    test_router_update_gateway                                   OK    2.38\n    test_router_update_gateway_to_empty_with_existed_floatingip  OK    0.72\n    test_router_update_gateway_with_existed_floatingip           OK    1.50\n    test_router_update_on_external_port                          OK    0.47\n    test_router_update_with_dup_address                          OK    0.37\n    test_router_update_with_invalid_ip_address                   OK    0.37\n    test_router_update_with_invalid_nexthop_ip                   OK    2.65\n    test_router_update_with_nexthop_is_outside_port_subnet       OK    0.38\n    test_router_update_with_too_many_routes                      OK    0.39\n    test_two_fips_one_port_invalid_return_409                    OK    0.83\nTestPortSecurity\n    test_create_network_with_portsecurity_false                  OK    0.19\n    test_create_network_with_portsecurity_mac                    OK    0.18\n    test_create_port_default_true                                OK    0.33\n    test_create_port_on_port_security_false_network              OK    0.23\n    test_create_port_passing_true                                OK    0.23\n    test_create_port_security_off_shared_network                 OK    0.27\n    test_create_port_security_overrides_network_value            OK    0.22\n    test_create_port_with_default_security_group                 OK    0.31\n    test_update_port_remove_port_security_security_group         OK    2.49\n    test_update_port_remove_port_security_security_group_readd   OK    0.46\n    test_update_port_security_off_shared_network                 OK    0.27\n    test_update_port_security_off_with_security_group            OK    0.36\n    test_updating_network_port_security                          OK    0.19\nTestSecurityGroups\n    test_create_default_security_group_fail                      OK    0.16\n    test_create_delete_security_group_port_in_use                OK    0.38\n    test_create_port_with_bad_security_group                     OK    0.26\n    test_create_port_with_non_uuid                               OK    0.24\n    test_create_security_group                                   OK    0.20\n    test_create_security_group_rule_bad_remote_group_id          OK    0.20\n    test_create_security_group_rule_bad_security_group_id        OK    0.17\n    test_create_security_group_rule_bad_tenant                   OK    0.20\n    test_create_security_group_rule_bad_tenant_remote_group_id   OK    0.22\n    test_create_security_group_rule_bad_tenant_security_group_ruleOK    0.23\n    test_create_security_group_rule_bulk_emulated                OK    2.24\n    test_create_security_group_rule_bulk_native                  SKIP\n    test_create_security_group_rule_case_insensitive             OK    0.33\n    test_create_security_group_rule_differnt_security_group_ids  SKIP\n    test_create_security_group_rule_duplicate_rule_db            SKIP\n    test_create_security_group_rule_duplicate_rule_db_emulated   OK    0.47\n    test_create_security_group_rule_duplicate_rule_in_post       SKIP\n    test_create_security_group_rule_duplicate_rule_in_post_emulatedOK    0.24\n    test_create_security_group_rule_duplicate_rules              OK    0.27\n    test_create_security_group_rule_ethertype_invalid_as_number  OK    0.21\n    test_create_security_group_rule_group_id                     OK    0.25\n    test_create_security_group_rule_min_port_greater_max         OK    0.24\n    test_create_security_group_rule_ports_but_no_protocol        OK    0.24\n    test_create_security_group_rule_protocol_invalid_as_number   OK    0.19\n    test_create_security_group_rule_remote_ip_prefix             OK    0.22\n    test_create_security_group_rule_with_invalid_ethertype       OK    0.14\n    test_create_security_group_rule_with_invalid_protocol        OK    0.14\n    test_create_security_group_source_group_ip_and_ip_prefix     OK    0.15\n    test_default_security_group                                  OK    0.21\n    test_default_security_group_rules                            OK    0.21\n    test_delete_default_security_group_fail                      OK    2.91\n    test_delete_security_group                                   OK    0.21\n    test_get_security_group                                      OK    0.25\n    test_list_ports_security_group                               OK    0.34\n    test_list_security_group_rules                               OK    0.36\n    test_list_security_group_rules_with_pagination               OK    0.32\n    test_list_security_group_rules_with_pagination_reverse       OK    0.31\n    test_list_security_group_rules_with_sort                     OK    0.31\n    test_list_security_groups                                    OK    0.26\n    test_list_security_groups_with_pagination                    OK    0.28\n    test_list_security_groups_with_pagination_reverse            OK    0.27\n    test_list_security_groups_with_sort                          OK    0.27\n    test_update_port_remove_security_group_empty_list            OK    0.44\n    test_update_port_remove_security_group_none                  OK    2.85\n    test_update_port_with_multiple_security_groups               OK    0.47\n    test_update_port_with_security_group                         OK    0.42\nTestSecurityGroupsXML\n    test_create_default_security_group_fail                      OK    0.15\n    test_create_delete_security_group_port_in_use                OK    0.35\n    test_create_port_with_bad_security_group                     OK    0.26\n    test_create_port_with_non_uuid                               OK    0.24\n    test_create_security_group                                   OK    0.20\n    test_create_security_group_rule_bad_remote_group_id          OK    0.20\n    test_create_security_group_rule_bad_security_group_id        OK    0.17\n    test_create_security_group_rule_bad_tenant                   OK    0.25\n    test_create_security_group_rule_bad_tenant_remote_group_id   OK    0.40\n    test_create_security_group_rule_bad_tenant_security_group_ruleOK    0.34\n    test_create_security_group_rule_bulk_emulated                OK    0.37\n    test_create_security_group_rule_bulk_native                  SKIP\n    test_create_security_group_rule_case_insensitive             OK    0.21\n    test_create_security_group_rule_differnt_security_group_ids  SKIP\n    test_create_security_group_rule_duplicate_rule_db            SKIP\n    test_create_security_group_rule_duplicate_rule_db_emulated   OK    0.40\n    test_create_security_group_rule_duplicate_rule_in_post       SKIP\n    test_create_security_group_rule_duplicate_rule_in_post_emulatedOK    0.23\n    test_create_security_group_rule_duplicate_rules              OK    0.28\n    test_create_security_group_rule_ethertype_invalid_as_number  OK    0.21\n    test_create_security_group_rule_group_id                     OK    0.27\n    test_create_security_group_rule_min_port_greater_max         OK    0.25\n    test_create_security_group_rule_ports_but_no_protocol        OK    0.24\n    test_create_security_group_rule_protocol_invalid_as_number   OK    0.19\n    test_create_security_group_rule_remote_ip_prefix             OK    0.23\n    test_create_security_group_rule_with_invalid_ethertype       OK    0.14\n    test_create_security_group_rule_with_invalid_protocol        OK    0.18\n    test_create_security_group_source_group_ip_and_ip_prefix     OK    0.22\n    test_default_security_group                                  OK    0.28\n    test_default_security_group_rules                            OK    0.24\n    test_delete_default_security_group_fail                      OK    0.22\n    test_delete_security_group                                   OK    0.23\n    test_get_security_group                                      OK    0.26\n    test_list_ports_security_group                               OK    2.37\n    test_list_security_group_rules                               OK    0.39\n    test_list_security_group_rules_with_pagination               OK    0.33\n    test_list_security_group_rules_with_pagination_reverse       OK    0.33\n    test_list_security_group_rules_with_sort                     OK    0.31\n    test_list_security_groups                                    OK    0.27\n    test_list_security_groups_with_pagination                    OK    0.29\n    test_list_security_groups_with_pagination_reverse            OK    0.29\n    test_list_security_groups_with_sort                          OK    0.30\n    test_update_port_remove_security_group_empty_list            Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.5FrDyuwGq8\n[SCP] Connecting to static.openstack.org\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1: 23300 Terminated              tox -e$venv\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/14\n[SCP] Copying console log.\n\n\n','<7974267.303.1366699615750.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1489072536.376.1367042689717.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:04:49',0,'2013-04-27 06:04:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric8 in workspace <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/>\nCheckout:periodic-ceilometer-python26-stable-grizzly / <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/> - hudson.remoting.Channel at 787582d3:oneiric8\nUsing strategy: Default\nLast Built Revision: Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/ceilometer.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/ceilometer.git\nCommencing build of Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\nChecking out Revision 75529b8bb00bbb9566eb3270ab070e89f7f94d97 (origin/stable/grizzly)\n[periodic-ceilometer-python26-stable-grizzly] $ /bin/bash -xe /tmp/hudson7858944954760063416.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack ceilometer\n+ version=26\n+ org=openstack\n+ project=ceilometer\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.WyuvphGfkJ\n+ TMPDIR=/tmp/tmp.WyuvphGfkJ\n+ trap \'rm -rf /tmp/tmp.WyuvphGfkJ\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack ceilometer\n+ org=openstack\n+ project=ceilometer\n+ [[ -z openstack ]]\n+ [[ -z ceilometer ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' ceilometer == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.ceilometer.python26.stable.grizzly.17\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-ceilometer-python26-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 60887 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-ceilometer-python26-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182611.942611-1818615746\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric8\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.WyuvphGfkJ\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'aa5b2403-87d8-4795-8c6e-13366d8f5d04\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'75529b8bb00bbb9566eb3270ab070e89f7f94d97\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric8\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 60887 166.78.48.106 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking http://tarballs.openstack.org/nova/nova-master.tar.gz (from -r <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires> (line 11))\n  Running setup.py egg_info for package from http://tarballs.openstack.org/nova/nova-master.tar.gz\n    Download error on http://pypi.openstack.org/openstack/setuptools_git/: timed out -- Some packages may not be found!\n    Download error on http://pypi.openstack.org/openstack/setuptools-git/: timed out -- Some packages may not be found!\n    Couldn\'t find index page for \'setuptools_git\' (maybe misspelled?)\n    Download error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n    No local packages or download links found for setuptools-git>=0.4\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"/tmp/tmp.WyuvphGfkJ/pip-sPz7pK-build/setup.py\", line 80, in <module>\n        py_modules=[])\n      File \"/usr/lib/python2.6/distutils/core.py\", line 113, in setup\n        _setup_distribution = dist = klass(attrs)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 221, in __init__\n        self.fetch_build_eggs(attrs.pop(\'setup_requires\'))\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 245, in fetch_build_eggs\n        parse_requirements(requires), installer=self.fetch_build_egg\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 586, in resolve\n        dist = best[req.key] = env.best_match(req, self, installer)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 831, in best_match\n        return self.obtain(req, installer) # try and download/install\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 843, in obtain\n        return installer(requirement)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 295, in fetch_build_egg\n        return cmd.easy_install(req)\n      File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/command/easy_install.py\",> line 592, in easy_install\n        raise DistutilsError(msg)\n    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse(\'setuptools-git>=0.4\')\n    Complete output from command python setup.py egg_info:\n    Download error on http://pypi.openstack.org/openstack/setuptools_git/: timed out -- Some packages may not be found!\n\nDownload error on http://pypi.openstack.org/openstack/setuptools-git/: timed out -- Some packages may not be found!\n\nCouldn\'t find index page for \'setuptools_git\' (maybe misspelled?)\n\nDownload error on http://pypi.openstack.org/openstack/: timed out -- Some packages may not be found!\n\nNo local packages or download links found for setuptools-git>=0.4\n\nTraceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"/tmp/tmp.WyuvphGfkJ/pip-sPz7pK-build/setup.py\", line 80, in <module>\n\n    py_modules=[])\n\n  File \"/usr/lib/python2.6/distutils/core.py\", line 113, in setup\n\n    _setup_distribution = dist = klass(attrs)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 221, in __init__\n\n    self.fetch_build_eggs(attrs.pop(\'setup_requires\'))\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 245, in fetch_build_eggs\n\n    parse_requirements(requires), installer=self.fetch_build_egg\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 586, in resolve\n\n    dist = best[req.key] = env.best_match(req, self, installer)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 831, in best_match\n\n    return self.obtain(req, installer) # try and download/install\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/pkg_resources.py\",> line 843, in obtain\n\n    return installer(requirement)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/dist.py\",> line 295, in fetch_build_egg\n\n    return cmd.easy_install(req)\n\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/distribute-0.6.34-py2.6.egg/setuptools/command/easy_install.py\",> line 592, in easy_install\n\n    raise DistutilsError(msg)\n\ndistutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse(\'setuptools-git>=0.4\')\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in /tmp/tmp.WyuvphGfkJ/pip-sPz7pK-build\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/test-requires,> -r<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tools/pip-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.WyuvphGfkJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n','<573022266.345.1366956416832.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<14893CDA-B76C-4F2E-B9C2-507E17D7EC64@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-18 20:00:03',32400,'2013-12-18 11:00:03',NULL,'[Openstack] Upgrade only Neutron from Grizzly to Havana with\n	others in Grizzly','Thank you.\nI have installed and now use OpenStack Grizzly platform.\nBut, I also hope to use ML2 plugin/drivers and LBaaS without changing and/or reinstall other OpenStack components. \n\nI am not sure if it is possible or not. So I wish to get help.\n\n- Jong-Geun Park\n\n2013. 12. 18., ?? 4:45, dheeru <dheerendra.madhusudhana at gmail.com> ??:\n\n> Good question. You can give it a shot. It may work. Also any reason you would like upgrade to only Neutron ?. If you looking for any specific feature of Neutron which got into Havana, it may break. \n> \n> I have not tried anything like this and giving inputs on my guesss.\n> \n> -Dheeru\n> @Community Service\n> \n> \n> On Wed, Dec 18, 2013 at 10:52 AM, Jong-Geun PARK <cyberlation at gmail.com> wrote:\n> Hi,\n> Is it possible to upgrade only Neutron from Grizzly to Havana while other projects such as Nova, Keystone, and so on are installed with Grizzly ?\n> If possible, can you let me know how ?\n> \n> Thank you,\n> - Jong-Geun Park\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> \n> -- \n> -dheeru\n> @Community Service\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131218/d9d4adcf/attachment.html>\n\n','<CAKV+guc-0NL7sx8Dpjzrs7ApDH89MxUGuZuvK1t3am2OCfLR7w@mail.gmail.com>',NULL),('<148EAA36-E26F-4820-ADA9-133A5D014818@brocade.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 00:44:28',0,'2014-11-19 00:44:28',NULL,'[openstack-dev] [tc][neutron] Proposal to split Neutron into\n separate repositories','I agree with Paul as advanced services go beyond just L4-L7.  Today, VPNaaS deals with L3 connectivity but belongs in advanced services.  Where does Edge-VPN work belong?  We need a broader definition for advanced services area.\n\nThanks,\n?Hanif.\n\nFrom: \"Paul Michali (pcm)\" <pcm at cisco.com<mailto:pcm at cisco.com>>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nDate: Tuesday, November 18, 2014 at 4:08 PM\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>\nSubject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories\n\nOn Nov 18, 2014, at 6:36 PM, Armando M. <armamig at gmail.com<mailto:armamig at gmail.com>> wrote:\n\nMark, Kyle,\n\nWhat is the strategy for tracking the progress and all the details about this initiative? Blueprint spec, wiki page, or something else?\n\nOne thing I personally found useful about the spec approach adopted in [1], was that we could quickly and effectively incorporate community feedback; having said that I am not sure that the same approach makes sense here, hence the question.\n\nAlso, what happens for experimental efforts that are neither L2-3 nor L4-7 (e.g. TaaS or NFV related ones?), but they may still benefit from this decomposition (as it promotes better separation of responsibilities)? Where would they live? I am not sure we made any particular progress of the incubator project idea that was floated a while back.\n\nWould it make sense to define the advanced services repo as being for services that are beyond basic connectivity and routing? For example, VPN can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion as to what?s in and what?s out.\n\n\nRegards,\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com<mailto:pcm at cisco.com>\nIRC ??..? pc_m (irc.freenode.com<http://irc.freenode.com>)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nCheers,\nArmando\n\n[1] https://review.openstack.org/#/c/134680/\n\nOn 18 November 2014 15:32, Doug Wiegley <dougw at a10networks.com<mailto:dougw at a10networks.com>> wrote:\nHi,\n\n> so the specs repository would continue to be shared during the Kilo cycle.\n\nOne of the reasons to split is that these two teams have different priorities and velocities.  Wouldn?t that be easier to track/manage as separate launchpad projects and specs repos, irrespective of who is approving them?\n\nThanks,\ndoug\n\n\n\nOn Nov 18, 2014, at 10:31 PM, Mark McClain <mark at mcclain.xyz<mailto:mark at mcclain.xyz>> wrote:\n\nAll-\n\nOver the last several months, the members of the Networking Program have been discussing ways to improve the management of our program.  When the Quantum project was initially launched, we envisioned a combined service that included all things network related.  This vision served us well in the early days as the team mostly focused on building out layers 2 and 3; however, we?ve run into growth challenges as the project started building out layers 4 through 7.  Initially, we thought that development would float across all layers of the networking stack, but the reality is that the development concentrates around either layer 2 and 3 or layers 4 through 7.  In the last few cycles, we?ve also discovered that these concentrations have different velocities and a single core team forces one to match the other to the detriment of the one forced to slow down.\n\nGoing forward we want to divide the Neutron repository into two separate repositories lead by a common Networking PTL.  The current mission of the program will remain unchanged [1].  The split would be as follows:\n\nNeutron (Layer 2 and 3)\n- Provides REST service and technology agnostic abstractions for layer 2 and layer 3 services.\n\nNeutron Advanced Services Library (Layers 4 through 7)\n- A python library which is co-released with Neutron\n- The advance service library provides controllers that can be configured to manage the abstractions for layer 4 through 7 services.\n\nMechanics of the split:\n- Both repositories are members of the same program, so the specs repository would continue to be shared during the Kilo cycle.  The PTL and the drivers team will retain approval responsibilities they now share.\n- The split would occur around Kilo-1 (subject to coordination of the Infra and Networking teams). The timing is designed to enable the proposed REST changes to land around the time of the December development sprint.\n- The core team for each repository will be determined and proposed by Kyle Mestery for approval by the current core team.\n- The Neutron Server and the Neutron Adv Services Library would be co-gated to ensure that incompatibilities are not introduced.\n- The Advance Service Library would be an optional dependency of Neutron, so integrated cross-project checks would not be required to enable it during testing.\n- The split should not adversely impact operators and the Networking program should maintain standard OpenStack compatibility and deprecation cycles.\n\nThis proposal to divide into two repositories achieved a strong consensus at the recent Paris Design Summit and it does not conflict with the current governance model or any proposals circulating as part of the ?Big Tent? discussion.\n\nKyle and mark\n\n[1] https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/c1ecb1d4/attachment.html>\n\n','<8F4F1D79-9DDD-4910-9CC6-C899758F4EC2@cisco.com>',NULL),('<1490384030.36.1383372180040.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:03:00',0,'2013-11-02 06:03:00',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-glance-docs-stable-folsom #49','See <https://jenkins01.openstack.org/job/periodic-glance-docs-stable-folsom/49/>\n\n\n\n',NULL,NULL),('<1490464300.4702137.1384227339401.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-12 11:35:36',28800,'2013-11-12 03:35:36',NULL,'[Openstack] [Nova] How to graceful shutdown a windows instance on\n	kvm hypervisor?','Hi all,\nYou know that the stop operation of nova will destroy the instance, and windows guest will perform a self-checking while booting after the destroy, the more serious problem is windows may run into blue screen situation.\nDo you have any good ideas for this issue?\n\nThanks a lot!\n\n2013-11-12\n\n\n\nWangpan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131112/71016c83/attachment.html>\n\n',NULL,NULL),('<1490602058.38860265.1403530428908.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-23 09:33:48',-14400,'2014-06-23 13:33:48',NULL,'[openstack-dev] [TripleO] CI status update for this week','\n\n----- Original Message -----\n> \n> \n> Well we probably need some backwards compat glue to keep deploying supported\n> versions. More on that in the spec I\'m drafting.\n\nA spec around deploying multiple versions of the overcloud? If so, great :-)\n\nRe: https://bugs.launchpad.net/tripleo/+bug/1330735 and deploying older \nversions of the overcloud. Trying an icehouse overcloud using the latest (fixed) \nundercloud should just work right? Assuming the stable/icehouse branches of \ntripleo-image-elements were used to build the overcloud images and same \nfor tripleo-heat-templates to deploy it?\n\n> On 21 Jun 2014 12:26, \"Dan Prince\" < dprince at redhat.com > wrote:\n> \n> \n> On Fri, 2014-06-20 at 16:51 -0400, Charles Crouch wrote:\n> > \n> > ----- Original Message -----\n> > > Not a great week for TripleO CI. We had 3 different failures related to:\n> > > \n> > > Nova [1]: we were using a deprecated config option\n> > > Heat [2]: missing heat data obtained from the Heat CFN API\n> > > Neutron [3]: a broken GRE overlay network setup\n> > \n> > The last two are bugs, but is there anything tripleo can do about avoiding\n> > the first one in the future?:\n> \n> Yes. Reviewing and monitoring our log files would have been helpful\n> here. Nova did nothing wrong... we were just plain using an old option\n> which was deprecated in Icehouse.\n> \n> With TripleO\'s upstream focus we need to maintain a balancing act and\n> try to avoid using new option names until a release has been made. I\n> think once the release is made however (Icehouse in this case) we should\n> immediately move to drop all deprecated options and use the new\n> versions. If we follow a process like this we should be safe guarded\n> from this sort of failure in the future.\n> \n> Dan\n> \n> > e.g. reviewing a list of deprecated options and seeing when they will be\n> > removed.\n> > \n> > do the integrated projects have a protocol for when an option is deprecated\n> > and at what point it can be removed?\n> > e.g. if I make something deprecated in icehouse I can remove it in juno,\n> > but if I\n> > make something deprecated at the start of juno I can\'t remove it at the end\n> > of juno?\n> > \n> > > \n> > > The TripleO check jobs look to be running stable again today so if your\n> > > patch had failures from earlier this week then recheck away (perhaps\n> > > referencing one of these bugs if appropriate). The queue is fairly empty\n> > > right now...\n> > > \n> > > Thanks for all the help in tracking these down and getting things fixed.\n> > > \n> > > [1] https://bugs.launchpad.net/tripleo/+bug/1292105\n> > \n> > I think [1] was meant to be\n> > https://bugs.launchpad.net/tripleo/+bug/1330735\n> > \n> > > [2] https://bugs.launchpad.net/heat/+bug/1331720\n> > > [3] https://bugs.launchpad.net/tripleo/+bug/1292105\n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ1xmgawg9CtLB-FV8MRoS=zU0ZOUvQZoWrBC6=T=zZ1WA@mail.gmail.com>',NULL),('<1491016806.25.1378275036132.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:10:36',0,'2013-09-04 06:10:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #14','See <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/14/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-12 in workspace <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/>\nCheckout:periodic-keystone-python26-stable-folsom / <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/> - hudson.remoting.Channel at a455eab:centos6-12\nUsing strategy: Default\nLast Built Revision: Revision 5d602cfefc6ace218a3a7dc70f255bbf3c0f33e1 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/keystone\ngit --version\ngit version 1.7.1\nERROR: Error cloning remote repo \'origin\' : Could not clone git://git.openstack.org/openstack/keystone\nhudson.plugins.git.GitException: Could not clone git://git.openstack.org/openstack/keystone\n	at hudson.plugins.git.GitAPI.clone(GitAPI.java:271)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1102)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2415)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n	at java.lang.Thread.run(Thread.java:724)\nCaused by: hudson.plugins.git.GitException: Command \"git clone --progress -o origin git://git.openstack.org/openstack/keystone <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/\"> returned status code 128:\nstdout: Initialized empty Git repository in <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/.git/>\n\nstderr: git.openstack.org[0: 2001:4800:7813:516:3bc3:d7f6:ff04:aacb]: errno=Connection timed out\ngit.openstack.org[0: 192.237.223.224]: errno=Connection timed out\nfatal: unable to connect a socket (Connection timed out)\n\n	at hudson.plugins.git.GitAPI.launchCommandIn(GitAPI.java:863)\n	at hudson.plugins.git.GitAPI.access$000(GitAPI.java:40)\n	at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:267)\n	at hudson.plugins.git.GitAPI$1.invoke(GitAPI.java:246)\n	at hudson.FilePath.act(FilePath.java:906)\n	at hudson.FilePath.act(FilePath.java:879)\n	at hudson.plugins.git.GitAPI.clone(GitAPI.java:246)\n	... 12 more\nTrying next repository\nERROR: Could not clone repository\nFATAL: Could not clone\nhudson.plugins.git.GitException: Could not clone\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1114)\n	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:1044)\n	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2415)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:118)\n	at hudson.remoting.UserRequest.perform(UserRequest.java:48)\n	at hudson.remoting.Request$2.run(Request.java:326)\n	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)\n	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n	at java.util.concurrent.FutureTask.run(FutureTask.java:166)\n	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n	at java.lang.Thread.run(Thread.java:724)\n\n\n',NULL,NULL),('<14912E69-9275-4508-8A3C-CD880212F47D@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 22:15:21',0,'2013-10-31 22:15:21',NULL,'[openstack-dev] [Solum] HOLD THE DATES: Design Workshop @SFO','Jay,\n\nIt is November 19 and 20. Looks like because it was sent as a calendar invite that the notes were scrubbed. Here is the text:\n\nWorkshop sessions\nNov 19 Tuesday 9:30 am - 5 pm\nNov 20 Wednesday 9:30 am - 3:00 pm (we break early on Wednesday if some of us want to catch an evening return flight)\n\nEtherpad for event planning-\nhttps://etherpad.openstack.org/p/SolumSFOCommunityWorkshop\n\nCheers,\n\nAdrian\n\nOn Oct 31, 2013, at 3:02 PM, Jay Pipes <jaypipes at gmail.com>\n wrote:\n\n> On 10/31/2013 05:41 PM, Roshan Agrawal wrote:\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> I think you probably want to say which particular dates people should hold. :)\n> \n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<5272D37B.50907@gmail.com>',NULL),('<1491383516.23.1387865423300.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-24 06:10:23',0,'2013-12-24 06:10:23',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-havana #7','See <https://jenkins01.openstack.org/job/periodic-glance-python26-havana/7/>\n\n\n\n','<1339913146.22.1387779014947.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1491407.EklKKt1P6t@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-13 14:27:13',36000,'2014-06-13 04:27:13',NULL,'[openstack-dev] [nova] Distributed locking','On Thu, 12 Jun 2014 05:06:38 PM Julien Danjou wrote:\n> On Thu, Jun 12 2014, Matthew Booth wrote:\n> > This looks interesting. It doesn\'t have hooks for fencing, though.\n> > \n> > What\'s the status of tooz? Would you be interested in adding fencing\n> > hooks?\n> \n> It\'s maintained and developer, we have plan to use it in Ceilometer and\n> others projects. Joshua also wants to use it for Taskflow.\n> \n> We are blocked for now by https://review.openstack.org/#/c/93443/ and by\n> the lack of resource to complete that request obviously, so help\n> appreciated. :)\n> \n> As for fencing hooks, it sounds like a good idea.\n\nAs far as I understand these things, in distributed-locking-speak \"fencing\" \njust means \"breaking someone else\'s lock\".\n\nI think your options here are (and apologies if I\'m repeating things that are \nobvious):\n\n1. Have a \"force unlock\" protocol (numerous alternatives exist).  Assume the \nlock holder implements it properly and stops accessing the shared resource \nwhen asked.\n\n2. Kill the lock holder using some method unrelated to the locking service and \nwait for the locking protocol to realise ex-holder is dead through usual \nliveness tests.  Assume not being able to hold the lock implies no longer able \nto access the shared resource.\nThe \"liveness test\" usually involves the holder pinging the lock service \nperiodically, and everyone has to wait for some agreed timeout before assuming \na client is dead.\n\n(1) involves a lot of trust - and seems particularly bad if the reason you are \nbreaking the lock is because the holder is misbehaving.\nAssuming (2) is the only reasonable choice, I don\'t think the lock service \nneeds explicit support for fencing, since the exact method for killing the \nholder is unrelated, and relatively uninteresting (probably always going to be \nan instance delete in OS).\n\n\nPerhaps more interesting is exactly what conditions you require before \nattempting to kill the lock holder - you wouldn\'t want just any job deciding \nit was warranted, or else a misbehaving client would cause mayhem.  Again, I \nsuggest your options here are:\n\n1. Require human judgement.\nie: provide monitoring for whatever is misbehaving and make it obvious that \none mitigation is to nuke the apparent holder.\n\n2. Require the lock breaker to be able to reach a majority of nodes as some \nproof of \"I\'m working, my opinion must be right\".\nIn a paxos system, reaching a majority of nodes basically becomes \"hold a \nlock\", we end back up with \"my liveness test is better than yours somehow\", \nand I\'m not sure how to resolve that without human judgement (but I\'m not \nfamiliar with existing approaches).  Again, I don\'t think this needs \nadditional support from the lock service, beyond a liveness test (which \nzookeeper, for example, has).\n\ntl;dr: I\'m interested in what sort of automated fencing behaviour you\'d like.\n\n-- \n - Gus\n\n\n','<m2sina88w1.fsf@danjou.info>',NULL),('<1493000666.95497035.1389139557465.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 19:05:57',-18000,'2014-01-08 00:05:57',NULL,'[openstack-dev] [TripleO] Installing from packages\n	in	tripleo-image-elements','\n\n----- Original Message -----\n> From: \"James Slagle\" <james.slagle at gmail.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, January 7, 2014 3:01:07 PM\n> Subject: [openstack-dev] [TripleO] Installing from packages in	tripleo-image-elements\n> \n> Hi,\n> \n> I\'d like to discuss some possible ways we could install the OpenStack\n> components from packages in tripleo-image-elements.  As most folks are\n> probably aware, there is a \"fork\" of tripleo-image-elements called\n> tripleo-puppet-elements which does install using packages, but it does\n> so using Puppet to do the installation and for managing the\n> configuration of the installed components.  I\'d like to kind of set\n> that aside for a moment and just discuss how we might support\n> installing from packages using tripleo-image-elements directly and not\n> using Puppet.\n\nI very much support having the option to use real packages within the tripleo-image-elements. Given we already use packages for some elements like Rabbit/MySQL/etc... supporting the option to use standard distribution packages for the OpenStack elements makes a lot of sense to me. \n\n> \n> One idea would be to add support for a new type (or likely 2 new\n> types: rpm and dpkg) to the source-repositories element.\n> source-repositories already knows about the git, tar, and file types,\n> so it seems somewhat natural to have additional types for rpm and\n> dpkg.\n> \n> A complication with that approach is that the existing elements assume\n> they\'re setting up everything from source.  So, if we take a look at\n> the nova element, and specifically install.d/74-nova, that script does\n> stuff like install a nova service, adds a nova user, creates needed\n> directories, etc.  All of that wouldn\'t need to be done if we were\n> installing from rpm or dpkg, b/c presumably the package would take\n> care of all that.\n> \n> We could fix that by making the install.d scripts only run if you\'re\n> installing a component from source.  In that sense, it might make\n> sense to add a new hook, source-install.d and only run those scripts\n> if the type is a source type in the source-repositories configuration.\n>  We could then have a package-install.d to handle the installation\n> from the packages type.   The install.d hook could still exist to do\n> things that might be common to the 2 methods.\n> \n> Thoughts on that approach or other ideas?\n> \n> I\'m currently working on a patchset I can submit to help prove it out.\n>  But, I\'d like to start discussion on the approach now to see if there\n> are other ideas or major opposition to that approach.\n\nThis seems like a reasonable first stab at it. Can\'t wait to see what you come up with.\n\n\n> \n> --\n> -- James Slagle\n> --\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHV77z_NdriW5tqjnMAD-A7nzRPnaZo6ReO_zSRhttsmLo1x_g@mail.gmail.com>',NULL),('<1493250634.89.1356048605262.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-21 00:10:05',0,'2012-12-21 00:10:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #81','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/81/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.77 secs:\n    2.55    Kc11TestCase.test_admin_requires_adminness\n    2.37    KcEssex3TestCase.test_admin_requires_adminness\n    2.25    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 48.895s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.0.2\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.HtRjUi59HL\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/81\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/81/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1494470410.54.1370154132758.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-02 06:22:12',0,'2013-06-02 06:22:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #244','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/244/>\n\n------------------------------------------\n[...truncated 12617 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:38119\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:38119/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (15158) wsgi starting up on http://127.0.0.1:38119/\n\nnova.osapi_compute.wsgi.server: INFO: (15158) accepted (\'127.0.0.1\', 50724)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/Jun/2013 06:16:55] \"GET /v2 HTTP/1.1\" 204 216 0.000752\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-f3c4f4bf-db81-43e0-b8fc-7f88993e44ea</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (15158) accepted (\'127.0.0.1\', 50725)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xad4d990>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xad4d990>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:38119/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:38119/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/Jun/2013 06:16:56] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.246102\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 85dd5d9412fe4d698b2d023c8d77ba7c \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:50445\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:50445/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (15158) wsgi starting up on http://127.0.0.1:50445/\n\nnova.osapi_compute.wsgi.server: INFO: (15158) accepted (\'127.0.0.1\', 45253)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/Jun/2013 06:16:56] \"GET /v2 HTTP/1.1\" 204 216 0.001039\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-8a75461d-8d0d-4f95-9d29-9ceff0f71f1d</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (15158) accepted (\'127.0.0.1\', 45254)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xaa27c50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xaa27c50>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:50445/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     name)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-02 06:16:56 15158 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:50445/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/Jun/2013 06:16:56] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.279314\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.11\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.4\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.5t1UcsYwBu\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/244\n[SCP] Copying console log.\n\n\n','<2064765912.53.1370067764353.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1494503496.3361058.1353183412854.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-17 15:16:52',-18000,'2012-11-17 20:16:52',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction	going forward','\n\n> >> I would *never* assume anything in user space. I think monitoring\n> >> of\n> >> the users instances is out of scope for all things OpenStack. The\n> >> users might deploy whatever tools they like for checking i/o,\n> >> disk,\n> >> network, etc.\n> >\n> >That\'s an interesting point of view, that I hadn\'t considered\n> >before.\n> >\n> >I would see AWS CloudWatch as a user-oriented monitoring service,\n> >and would have assumed that there is scope for something similar\n> >to be part of openstack.\n> >\n> >When you say its out of scope, do you mean that it shouldn\'t be\n> >something addressed by the IaaS fabric, and should instead be\n> >something that users bolt on top by running agents *within* their\n> >instances?\n> >\n> >(as opposed to some piece of the openstack infrastructure doing\n> > this monitoring from *outside* the instance)\n> >\n> >I recall the Heat team ran into some complications on this whole\n> >within-versus-without question, as the openstack RBAC mechanisms\n> >aren\'t yet flexible enough to easily grant in-instance agents\n> >credentials giving limited roles such as the ability to report\n> >metrics to a CW-like metricstore.\n> \n> Well, now we\'re getting to the crux of the matter and one that I\n> brought up in the IRC meeting yesterday. My concern is that\n> ceilometer is becoming a kitchen sink for this stuff.\n\n\nOK, I can see how the recent expansion of the cielometer project\'s\nmandate might be viewed as \"mission creep\" from one perspective.\n\nHowever my own view is that we need to be more than a toolbox of\nlow-level tools to extract data from the IaaS fabric, and instead\nceilometer can and should include complete services for reasoning\nover and leveraging these data (whether it be the ceilometer-api\nservice exposing rich views over the metering store, or a CloudWatch\nclone providing access to aggregated metrics & alarming over same). \n\nThat said, I think we can fulfill both roles - i.e. provide a home\nfor tools that could be used to compose higher-level services *and*\nalso provide implementations of some of those services.\n\nI also like you idea of ceilo being the honest broker to drive\nrelevant requirements within the core projects.\n\nCheers,\nEoghan\n\n\n> Two summits\n> ago the mandate was clear \"There is no billing, we need billing, so\n> let\'s build this ...\" (I remember because I suggested to look at\n> Yagi/StackTach/Tach back then). This was also the impetus for the\n> \"integration\" proposal as I saw the scope widening. To have\n> ceilometer become a set of low-level tools that can be used to get\n> data out and away from core OpenStack services and a basis for other\n> tools to build upon (Heat, CloudWatch/Synaps, StackTach, etc). Tools\n> of this sort are vitally important to a successful OpenStack\n> deployment, but it should be mix-and-match or \"your mileage may\n> vary\".\n> \n> I think ceilometer should be a smaller, more tightly focused\n> collection of utilities, vs. trying to be all things to all people.\n> \n> If a project like Heat runs into problems with something like the\n> RBAC mechanism or the polling interval from Compute, that would be\n> the Ceilometer teams job to broker a solution with Core and expose\n> that solution to everyone.\n> \n> The Rackspace Linux/Windows agents for Xen are open sourced:\n> https://github.com/rackspace/openstack-guest-agents-windows-xenserver\n> https://github.com/rackspace/openstack-guest-agents-unix\n> \n> That might be a starting point for an agent-level api that can feed\n> into that eco-system? But again, I think it\'s a separate problem ...\n> perhaps even a separate project?\n> \n> >> For the Deployer of openstack, yes they will want to check if the\n> >> Services are running hot, falling behind queued i/o or the public\n> >> openstack api load balancer is spitting out 503\'s. My\n> >> differentiation of instrumentation and monitoring in these cases\n> >> are\n> >> related to the sample rate and size of the payload. 503\'s, i/o,\n> >> etc\n> >> I would view as instrumentation. Sampled frequently and with\n> >> little\n> >> payload. This is the classic statsd/graphite data. Shown in a big\n> >> graph on the wall of the Network Operations Center. Monitoring\n> >> would\n> >> be larger, slower, chunkier data for Capacity Planning, etc.\n> >> Lifecycle state falls into the Monitoring camp as well. \"Are\n> >> things\n> >> progressing as expected? Or will they be a problem down the road.\"\n> >\n> >OK, so this cloud-operator-oriented view is also crucial, but I\'d\n> >be leery about making this the entire focus of our efforts (i.e. by\n> >assuming that users will sort themselves out with their own\n> >monitoring\n> >solution).\n> \n> Yeah, it\'s a tricky line to cross ... stepping into user-space. There\n> are a raft of 3rd party companies I\'m sure would want to have a say\n> in how this happens. So many OpenStack startups are centered around\n> this very problem.\n> \n> >Cheers,\n> >Eoghan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<60A3427EF882A54BA0A1971AE6EF038883D3F9C4@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1495525037.88.1380090585884.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-25 06:29:45',0,'2013-09-25 06:29:45',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #26','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/26/>\n\n------------------------------------------\n[...truncated 20807 lines...]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\nInitialized empty Git repository in /tmp/tempest-unitz5PSQ3/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitxJUVtC/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          204.452\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  173.332\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  64.275\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       38.524\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]    32.690\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         31.648\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      31.127\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_rebuild_server[gate,smoke]                    30.769\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        30.435\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                30.413\n\n----------------------------------------------------------------------\nRan 1226 tests in 1271.430s\n\nOK (skipped=64)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-384367-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-384367.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-384367/26/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1677863900.76.1379831789294.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1495973719.12.1381816967979.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-15 06:02:47',0,'2013-10-15 06:02:47',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python27-stable-grizzly #33','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/33/changes>\n\n\n\n','<1731140587.6.1381730558191.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1496447018.33.1374559647543.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-23 06:07:27',0,'2013-07-23 06:07:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #295','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/295/>\n\n------------------------------------------\n[...truncated 2636 lines...]\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.128.g58d436e to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.128.g58d436e\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.128.g58d436e\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.10.g8ffaa0a to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.10.g8ffaa0a\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.10.g8ffaa0a\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/rabbitmq/rabbit at devstack-1374553250-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/rabbitmq/rabbit at devstack-1374553250.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/295/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1070784000.27.1374473149899.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1496762637.26.1375509790001.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-03 06:03:09',0,'2013-08-03 06:03:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #29','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/29/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-180894 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #211453 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-neutron-stable-grizzly] $ /bin/bash -xe /tmp/hudson1004518481402493215.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-neutron-stable-grizzly] $ /bin/bash -xe /tmp/hudson7578481246270754602.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_NEUTRON=1\n+ DEVSTACK_GATE_NEUTRON=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-180894\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-180894/29\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-180894/29/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-180894/29/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1496803638.30256715.1376405599555.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-13 07:53:19',-25200,'2013-08-13 14:53:19',NULL,'[Openstack] Fwd: [vmwareapi] Could we distribute wsdl files\n from vSphere SDK?','Thanks. I\'ll sit down and do this today. That documentation has been wrong quite a while.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Christian Berendt\" <berendt at b1-systems.de>\n> To: \"Shawn Hartsock\" <hartsocks at vmware.com>\n> Cc: \"Roman Sokolkov\" <rsokolkov at gmail.com>, openstack at lists.openstack.org\n> Sent: Tuesday, August 13, 2013 10:48:30 AM\n> Subject: Re: [Openstack] Fwd: [vmwareapi] Could we distribute wsdl files from vSphere SDK?\n> \n> On 08/13/2013 04:42 PM, Shawn Hartsock wrote:\n> > Could someone direct me to how to fix the official docs? I\'ll do that\n> > *today*... it\'s on my to-do list anyway.\n> \n> Have a look at https://wiki.openstack.org/wiki/Documentation/HowTo.\n> \n> HTH, Christian.\n> \n> --\n> Christian Berendt\n> Cloud Computing Solution Architect\n> Mail: berendt at b1-systems.de\n> \n> B1 Systems GmbH\n> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de\n> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537\n> \n\n\n','<520A473E.5020205@b1-systems.de>',NULL),('<1496921340.12443369.1411116780205.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-19 04:53:00',-14400,'2014-09-19 08:53:00',NULL,'[openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core','\n\n> Hi,\n> \n> Nejc has been doing a great work and has been very helpful during the\n> Juno cycle and his help is very valuable.\n> \n> I\'d like to propose that we add Nejc Saje to the ceilometer-core group.\n> \n> Please, dear ceilometer-core members, reply with your votes!\n\nWith eight yeas and zero nays, I think we can call a result in this\nvote.\n\nWelcome to the ceilometer-core team Nejc!\n\nCheers,\nEoghan\n\n\n','<m24mwfojaz.fsf@danjou.info>',NULL),('<1497026674.1060413.1411143787206.JavaMail.app@ela4-app1327.prod>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-19 16:23:07',0,'2014-09-19 16:23:07',NULL,'[Openstack] 徐本磊，希望您能加我为领英联系人','??????:\n??????????????\n\nRajdeep Dua\nDirector R&amp;D\n\n??: http://www.linkedin.com/blink?simpleRedirect=c3oVe30UdzAMc30UdjoTe34VdjR4imVLqnhxt6BSrCACclZoiANaojAZumlbp6lOomxP9zwOnT9BoCRBrlZBt6BSrCAZqSkCpnhFtCVFtSlKbnhMpmdzoiRybmRSrCBvrmRLoORIrmkZpSVFqSdxsDgCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCpnhFtCV9sClyrmlJfm4CpORPtnpGsjAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12875636_117&markAsRead=\n\nRajdeep Dua??? http://www.linkedin.com/blink?simpleRedirect=c3wQe3wVdjR4in9BoCRBrip1iCRcfmVBqSZkq7hRoipBrm5KfmlMulhEt7lx9zsNclYScPoRdPwOckBve3gRe3kVc3sPfnhMpmdzgmVLqnhxt6BSrCACe39vsClyrmlJnSlQqnpKqjRHpipBt6BSrCBTpmUJpmRxryRybmRSrCBvrmRLoORIrmkZpSVFqSdxsDgCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCtD1KfngCpORPtnpGsjAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12875636_117&markAsRead=\n\n???????????????????????: http://www.linkedin.com/blink?simpleRedirect=6sJsTlSqD4Vc6AJd6tUtjgSfmhFpipRlD8St4pPrkERhll1tktdtRhIiAlRt4YSh6tIe51CjmNEpjd5pQBjr7pOszpUdmhKs71ybmdIc49fcj9MiChOkPtgt7pblTlfqll1gk51tCN9hyRxu5lTkkxhgjRAqmZI9zwOnT9BoCRBrlZBt6BSrCAZqSkCpnhFtCVFtSlKbm9RsSVRbmoJrnpKqlZJrmZzbmNJpjRDrCBHoS5Ot2pDrnBdsSV5gmJjc4xhgjRKpmJLl6hFripPtmkZt2pDbndRtCFNej1FbjhDu7kQdzRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&msgID=I12875636_117&markAsRead=\n\n???????? (???? - yocto????)? ????????????: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9zwOnT9BoCRBrlZBt6BSrCAZqSkCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCr79lpmdFtD9BkT9BrmZQsTlzfm4CpORPtnpGsjAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12875636_117&markAsRead=\n&copy;2014 LinkedIn Ireland Limited ????????????????????: 477441?????: 70 Sir John Roberson&apos;s Quay, Dublin 2\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140919/acec67e1/attachment.html>\n\n',NULL,NULL),('<1498066365.43.1375596188293.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-04 06:03:08',0,'2013-08-04 06:03:08',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #29','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-coverage/29/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-181610 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-coverage/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #212086 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-coverage] $ /bin/bash -xe /tmp/hudson3186889113202511124.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-coverage] $ /bin/bash -xe /tmp/hudson5353356133918320593.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_COVERAGE=1\n+ DEVSTACK_GATE_TEMPEST_COVERAGE=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-181610\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-181610/29\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-181610/29/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-181610/29/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1498511696.94.1380177703413.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-26 06:41:43',0,'2013-09-26 06:41:43',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all #29','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/29/>\n\n\n\n','<1549326626.75.1379831630362.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1498563085.285.1368599765482.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-15 06:36:05',0,'2013-05-15 06:36:05',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-quantum-python26-stable-grizzly #35','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/35/changes>\n\n\n\n','<1526417771.280.1368514512172.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1498787011.71.1383546689313.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-04 06:31:29',0,'2013-11-04 06:31:29',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #51','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/51/>\n\n------------------------------------------\n[...truncated 21205 lines...]\ntempest.api.object_storage.test_object_services.PublicObjectTest.test_access_public_object_with_another_user_creds[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version ... ok\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_get_object_after_expiration_time[gate,negative]\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_get_object_after_expiration_time[gate,negative] ... ok\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_get_object_using_temp_url[gate]\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_get_object_using_temp_url[gate] ... ok\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_put_object_using_temp_url[gate]\ntempest.api.object_storage.test_object_temp_url.ObjectTempUrlTest.test_put_object_using_temp_url[gate] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_extend[gate] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_extend[gate]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_extend[gate] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumesListTest.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestXML.test_create_snapshot_without_passing_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           124.641\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]    76.714\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   62.742\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   37.093\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]        37.066\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                              34.878\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                 34.844\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      33.570\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]          31.943\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]        31.927\n\n----------------------------------------------------------------------\nRan 1433 tests in 1286.926s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-633662-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-633662.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-633662/51/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<527992223.62.1383460273572.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1499008234.6.1375855350053.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-07 06:02:29',0,'2013-08-07 06:02:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/2/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-1269 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #1258 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-neutron-stable-grizzly] $ /bin/bash -xe /tmp/hudson5930995451996871950.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-neutron-stable-grizzly] $ /bin/bash -xe /tmp/hudson5174291104276542075.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_NEUTRON=1\n+ DEVSTACK_GATE_NEUTRON=1\n+ export ZUUL_BRANCH=stable/grizzly\n+ ZUUL_BRANCH=stable/grizzly\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-1269\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-1269/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-1269/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-1269/2/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<883628283.2.1375768930775.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<14990126.767.1389802815962.JavaMail.yfried@yfried-mobl-rh>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 11:20:22',-18000,'2014-01-15 16:20:22',NULL,'[openstack-dev] [qa][Neutron][Tempest][Network] Break down\n NetworkBasicOps to smaller test cases','Hi Guys\nAs Maru pointed out - NetworkBasicOps scenario has grown out of proportion and is no longer \"basic\" ops.\n\nSo, I started breaking it down to smaller test cases that can fail independently.\n\nThose test cases share the same setup and tear-down code:\n1. create network resources (and verify them)\n2. create VM with floating IP.\n\nI see 2 options to manage these resources:\n1. Completely isolated - resources are created and cleaned using setUp() and tearDown() methods [1]. Moving cleanup to tearDown revealed this bug [2]. Apparently the previous way (with tearDownClass) wasn\'t as fast). This has the side effect of having expensive resources (ie VMs and floating IPs) created and discarded  multiple times though they are unchanged.\n\n2. Shared Resources - Using the idea of (or actually using) Fixtures - use the same resources unless a test case fails, in which case resources are deleted and created by the next test case [3].\n\nI would like to hear your opinions, and know if anyone has any thoughts or ideas on which direction is best, and why.\n\nOnce this is completed, we can move on to other scenarios as well\n\nRegards\nYair\n\n[1] fully isolated - https://review.openstack.org/#/c/66879/\n[2] https://bugs.launchpad.net/nova/+bug/1269407/+choose-affected-product\n[3] shared resources - https://review.openstack.org/#/c/64622/\n\n\n','<16558159.748.1389801722729.JavaMail.yfried@yfried-mobl-rh>',NULL),('<1499152.409013.1413932198437.JavaMail.yahoo@jws100153.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-21 22:56:38',0,'2014-10-21 22:56:38',NULL,'[openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even\n though all resources are DELETE_COMPLETE','Greetings all,\nI\'m using Heat from Icehouse and I\'m hitting a problem that I\'m hoping y\'all can shed some light on.\nI have no problems doing stack-create. I can watch the MySQL commands go by and see it happily update the stack table so that it eventually shows up as CREATE_COMPLETE. When I delete the stack, everything seems to be working fine. ?I see the MySQL update that sets the stack to DELETE IN PROGRESS as well as the updates that sets my single resource to DELETE_COMPLETE... but I never see the final update to the stack table to set it to DELETE COMPLETE.\nOne very odd thing that I found in the MySQL logs (snippet below), is a query that includes that stack name but with an extra \'*\' character append to it. My stack is named \'xyzzy8\' but notice the \'xzyzzy8*\' in the constraint. That\'s not going to return anything and I\'m wondering if that is what\'s preventing the final stack DELETE_COMPLTE update from happening??\nThere are no errors in the any of the heat logs.\nAny guidance would be greatly appreciated!\n\nKen\nSELECT stack.status_reason AS stack_status_reason, stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action AS stack_action, stack.status AS stack_status, stack.id AS stack_id, stack.name AS stack_name, stack.raw_template_id AS stack_raw_template_id, stack.username AS stack_username, stack.tenant AS stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback AS stack_disable_rollback, stack.stack_user_project_id AS stack_stack_user_project_id, stack.updated_at AS stack_updated_atFROM stackWHERE stack.deleted_at IS NULL AND (stack.tenant = \'c6c488223aae4e97bf56dda8cef36b3b\' OR stack.stack_user_project_id = \'c6c488223aae4e97bf56dda8cef36b3b\') AND stack.name = \'xyzzy8*\' AND stack.owner_id = \'9a3e56d7-0c10-4c1c-8c54-0e5580cee121\'\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/91e8fc44/attachment.html>\n\n',NULL,NULL),('<1499869301.46147463.1386131764687.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 20:36:04',-28800,'2013-12-04 04:36:04',NULL,'[Openstack] vmwareapi with VMwareESXDriver','To be clear, OpenStack Grizzly contains the VCDriver that performs the standard set of Nova VM operations (start, stop, suspend, resume, etc.) by talking directly to vCenter without the need for additional commercial technologies. See: http://docs.openstack.org/grizzly/openstack-compute/admin/content/vmware.html . \n\nThe Nova vCenter integration has been tested by a fair number of people and deployed in production by a handful. While we still provide bug fixes for Grizzly, we recommend the more recent Havana release for any new production deployments. There is also a legacy Nova driver that talks directly to ESX (the original model prior to Grizzly, contributed by Citrix I believe). This driver is not actively maintained and I have not been part of any customer installs with it, so I cannot comment on what does or does not work. \n\nDan \n\n----- Original Message -----\n\n| From: \"Kai KT Tong\" <tongkai at cn.ibm.com>\n| To: \"Hai Quan Chen\" <chenhaiq at cn.ibm.com>\n| Cc: openstack at lists.openstack.org\n| Sent: Tuesday, December 3, 2013 6:05:53 PM\n| Subject: Re: [Openstack] vmwareapi with VMwareESXDriver\n\n| Hi:\n\n| Below is some information about the mail from Hai Quan Chen:\n\n| In our lab, our OpenStack (Grizzly) can connect to vCenter to view OS\n| machines and images. It needs two IBM production: SCE and Smartcloud.\n\n| EXSI 5.1, 5.0 4.x are supported.\n\n| For now it can only review these OS resources and can not manage OS resources\n| such as deploy/start/stop. We lack customization steps.\n\n| Thanks & Best Regards ,\n| Kai KT Tong\n| ******************************************************\n| Cloud & Smarter Infrastructure\n| China Development\n| China Software Development Lab,\n| Notes ID: Kai KT Tong/China/IBM at IBMCN\n| E-Mail : tongkai at cn.ibm.com\n| Tel: 86-10-8245 3574\n| ******************************************************\n| Shangdi Software Park Ring Build 2RW337\n\n| Shangdi, Haidian District,\n\n| Beijing 100193, P.R.China\n| ******************************************************\n\n| Hai Quan Chen---2013/12/04 09:18:19---ESXi 5.x could virtualize on Mac\n| hardware. In my lab, I have a running ESXi on Mac mini server, whic\n\n| From: Hai Quan Chen/China/IBM at IBMCN\n| To: Jeremy Stanley <fungi at yuggoth.org>,\n| Cc: openstack at lists.openstack.org\n| Date: 2013/12/04 09:18\n| Subject: Re: [Openstack] vmwareapi with VMwareESXDriver\n\n| ESXi 5.x could virtualize on Mac hardware.\n\n| In my lab, I have a running ESXi on Mac mini server, which connects to\n| Openstack via vCenter.\n\n| From: Jeremy Stanley <fungi at yuggoth.org>\n| To: openstack at lists.openstack.org\n| Date: 2013/12/04 07:46\n| Subject: Re: [Openstack] vmwareapi with VMwareESXDriver\n\n| On 2013-12-03 14:47:48 -0800 (-0800), Stefano Maffulli wrote:\n| [...]\n| > If so, I haven\'t heard of anybody virtualizing OS X but I\'d be happy to\n| > be proven wrong.\n\n| As recently as last year a former employer of mine was looking into\n| it, but the issue turned out to be one of licensing. Apple didn\'t\n| license OS X for running on any hardware except their own, so while\n| there were some ways to make it technically possible it was not\n| _legally_ possible. This also seems to be reflected in VMware\'s\n| knowledge base now...\n\n| <URL:\n| http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000131\n| >\n\n| --\n| Jeremy Stanley\n\n| _______________________________________________\n| Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n| Post to : openstack at lists.openstack.org\n| Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n| _______________________________________________\n| Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n| Post to : openstack at lists.openstack.org\n| Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n| _______________________________________________\n| Mailing list:\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=t5YtbXHG2df6xO5KoKrEMNdOm0bq9Z1Ul2ozifXcEl0%3D%0A&s=e153de035bb63034bb90fe3f72e576c62dc194d94b00674a2db4ae29cea6b149\n| Post to : openstack at lists.openstack.org\n| Unsubscribe :\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=t5YtbXHG2df6xO5KoKrEMNdOm0bq9Z1Ul2ozifXcEl0%3D%0A&s=e153de035bb63034bb90fe3f72e576c62dc194d94b00674a2db4ae29cea6b149\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/1d8fc3a4/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: graycol.gif\nType: image/gif\nSize: 105 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131203/1d8fc3a4/attachment.gif>\n\n','<OF09928699.1B8BF956-ON48257C37.000B0F63-48257C37.000B8389@cn.ibm.com>',NULL),('<149EC934-2BE3-46DE-8105-0FA52042C059@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-15 22:07:27',-25200,'2014-06-16 05:07:27',NULL,'[Openstack] networking problem while creating multiple external\n	networks using multiple l3 agents','Are you using Ubuntu or red hat? Ml2 or not ? \n\nInviato da iPhone (?)\n\n> Il giorno Jun 15, 2014, alle ore 21:08, BYEONG-GI KIM <kimbyeonggi at gmail.com> ha scritto:\n> \n> Dear Yang, \n> \n> Thank you for the reply.\n> \n> I\'ve checked the connection between aqrouter and a vm like this way;\n> \n> 1. ping from qrouter to br-ext in order to identify the external network is set correctly: it works fine.\n> 2. ping from a vm where locates in an internal network to a qrouter which connects with the network: it doesn\'t work. In detail, I used tcpdump on each bridge to check the connection status. The ping (ICMP Request message) arrived at br-int/br-tun on the Compute Node successfully. The ping, however, could not arrive at br-int/br-tun on the Network Node. The Request messsage could arrive at the Ethernet port for Internal Network on the Network Node. I also checked the connection by a reverse way; The ping from qrouter even could not be delivered to br-int on the Network Node. Of course I set up the firewall rule properly... \n> \n> My Networking set up is GRE and I deployed my openstack testbed environment using VMware workstation. I\'ve been trying to deploy two external networks using multiple l3 agents, and the multiple l3 agents are running on same node (Network Node). The status of the router_interface for connection between Internal Network and the corresponding qrouter is shown as DOWN on dashboard. \n> \n> I don\'t know how to solve this problem. I tried to re-create external network/subnet/qrouter according to the http://www.gossamer-threads.com/lists/openstack/dev/36353?do=post_view_flat, but still doesn\'t work.\n> \n> Should the router_id in l3-agent.ini file indicate id which can find \'ip netns\' on Network Node or indicate id which can find \'neutron router-list\' on Controller Node? As you know, the ids are a little different; qrouter-xxxx or just xxxx\n> \n> Anyway, the setting up multiple external networks makes me upset now. :(\n> \n> Best regards\n> \n> Byeong-Gi Kim\n> \n> \n> \n> \n> 2014-06-16 11:11 GMT+09:00 Alex Yang <alex890714 at gmail.com>:\n>> Hi Kim,\n>> \n>> You should check the firewall rule of the vm at first. Then, If the qrouter and vm are not in the same host, you should check the connection of tunnel between the two host by using ovs-vsctl show. \n>> Using tcpdump to inspect the packets in br-ext, br-int is also useful.\n>> \n>> \n>> \n>> 2014-06-13 14:51 GMT+08:00 BYEONG-GI KIM <kimbyeonggi at gmail.com>:\n>>> Hello.\n>>> \n>>> I created two external networks using multiple l3 agents by referring to both http://docs.openstack.org/admin-guide-cloud/content/adv_cfg_l3_agent_multi_extnet.html and https://answers.launchpad.net/neutron/+question/236230, and it seems work fine...\n>>> \n>>> When I tried to ping from a qrouter, which connects with both an external network called \"external1\" and an internal network, to a vm where located in the internal network, however, the ping could not be sent successfully.\n>>> \n>>> The qrouter can ping to br-ex, and another qrouter which connects with the second external network named \"external2\" also can ping to br-ex-2. The problem is that status for connection between each qrouter and internal network has been \"DOWN\" instead of \"ACTIVE\"...\n>>> \n>>> Did anybody suffer from such problem and solve it? I\'d appreciate any help and comments for solving it.\n>>> \n>>> Thanks in advance.\n>>> \n>>> Best regards\n>>> \n>>> Byeong-Gi KIM\n>>> \n>>> \n>>> _______________________________________________\n>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>>> Post to     : openstack at lists.openstack.org\n>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>> \n>> \n>> \n>> -- \n>>   ??\n>>   Email:       alex890714 at gmail.com\n>> GitHub:       https://github.com/AlexYangYu\n>>  Weibo:       http://www.weibo.com/alexyangyu\n> \n> !DSPAM:1,539e6f6e98513861191222!\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,539e6f6e98513861191222!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140615/ba85e698/attachment.html>\n\n','<CAEHt_JbHM5ggJFZZP=remcLWvnROQkXoYy8wtok16xU-BJwe0Q@mail.gmail.com>',NULL),('<149F4840-C3F1-495A-B49C-D4A82D24377C@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 09:34:42',-25200,'2014-03-26 16:34:42',NULL,'[openstack-dev] [nova][cinder] Refactor ISCSIDriver to support\n	other iSCSI transports besides TCP','This all makes sense to me. I would suggest a blueprint and a pull request as soon as Juno opens.\n\nVish\n\nOn Mar 25, 2014, at 8:07 AM, Shlomi Sasson <shlomis at mellanox.com> wrote:\n\n> Hi,\n>  \n> I want to share with the community the following challenge:\n> Currently, Vendors who have their iSCSI driver, and want to add RDMA transport (iSER), cannot leverage their existing plug-in which inherit from iSCSI\n> And must modify their driver or create an additional plug-in driver which inherit from iSER, and copy the exact same code.\n>  \n> Instead I believe a simpler approach is to add a new attribute to ISCSIDriver to support other iSCSI transports besides TCP, which will allow minimal changes to support iSER.\n> The existing ISERDriver code will be removed, this will eliminate significant code and class duplication, and will work with all the iSCSI vendors who supports both TCP and RDMA without the need to modify their plug-in drivers.\n>  \n> To achieve that both cinder & nova requires slight changes:\n> For cinder, I wish to add a  parameter called ?transport? (default to iscsi) to distinguish between the transports and use the existing ?iscsi_ip_address? parameter for any transport type connection.\n> For nova, I wish to add a parameter called ?default_rdma? (default to false) to enable initiator side.\n> The outcome will avoid code duplication and the need to add more classes.\n>  \n> I am not sure what will be the right approach to handle this, I already have the code, should I open a bug or blueprint to track this issue?\n>  \n> Best Regards,\n> Shlomi\n>  \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/2dffb192/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/2dffb192/attachment.pgp>\n\n','<A553DA4BC496C64EAD0C5B21A4D4C72895F216FC@MTLDAG01.mtl.com>',NULL),('<14ac8d1d.1e9cd.145cfae8d72.Coremail.ayshihanzhang@126.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-06 11:58:14',28800,'2014-05-06 03:58:14',NULL,'[openstack-dev] [neutron]what\'s diffrent between the type \'PING\' and ‘TCP’ in health_monitor','Hi everyone!\nI\'ve enabled LBaaS with haproxy, I\'ve configured a pool with vip and members, the health_monitor type is \'PING\', then I found the status of members is always \'INACTIVE\', when I execute  \'nc -l -p \' in member server, the status of member become \'ACTIVE\', who can help me to explain  what\'s diffrent between the type \'PING\' and ?TCP? in health_monitor.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/094451ae/attachment.html>\n\n',NULL,NULL),('<14af04c35b0.278a.724bfb4e02fbbdf80530460149ac8b11@openstack.org>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-15 19:12:15',-21600,'2015-01-16 01:12:15',NULL,'[OpenStack Foundation] Elections: Could we set the IRC topic?.','Good news everyone: we\'ve now passed our quorum number for voters on the \nbylaws amendments. The election will remain open for voting for another 16 \nhours.\n\nThanks everyone for the help in publicizing this important activity!\n\n\nOn January 15, 2015 4:07:42 PM Jonathan Bryce <jonathan at openstack.org> wrote:\n\n> We are now at ~3,200 who have voted on the Bylaws amendments (3,373 is the \n> number needed for quorum). The election will close at 1700UTC tomorrow, \n> approximately 19 hours from now. The pace has been pretty good today and if \n> it continues, we should make it to the required number of voters in time.\n>\n> Jonathan\n>\n>\n>\n> > On Jan 15, 2015, at 10:41 AM, Jonathan Bryce <jonathan at openstack.org> wrote:\n> >\n> > At this point, I think we have a good shot of getting across the quorum \n> line given our pace over the last 24 hours. The most effective mechanism \n> has been direct emails to the remaining eligible voters, and at this point, \n> I don?t think it?s necessary to spam those channels (like IRC) that have \n> probably had a high voting ratio already among their audience.\n> >\n> > Another reminder email will be going out shortly and we?ll provide an \n> update later today on the progress.\n> >\n> > Jonathan\n> >\n> >\n> >> On Jan 15, 2015, at 9:28 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:\n> >>\n> >> On 2015-01-14 17:23:53 -0700 (-0700), Alan Clark wrote:\n> >>> A suggestion: Could we set the IRC topic, at end of mtgs (aka\n> >>> header) on the appropriate channels to \"Get out and vote today!\"\n> >>\n> >> We have an IRC bot we use for temporarily modifying channel topics\n> >> and making in-channel announcements, though it\'s not really intended\n> >> to be used to alter topics for more than a few hours (susceptible to\n> >> connectivity issues and netsplits which can cause a loss of state\n> >> and result in topics getting \"stuck\" with the temporary text). As\n> >> mentioned in other replies, channel topics while persistent are\n> >> actually not that noticeable in most IRC clients--abusing that bot\n> >> to do a few brief election reminder announcements in channels might\n> >> reach more people. I\'m trying to get some consensus from our other\n> >> infrastructure admins on this possibility since people can be a\n> >> little touchy about what they may see as unnecessary spam in IRC.\n> >>\n> >>> Seems like meeting, meeting-alt, community, dev would be great\n> >>> targets.\n> >>\n> >> Our statusbot currently sits in ~60 OpenStack-related channels:\n> >>\n> >> <URL: \n> https://git.openstack.org/cgit/openstack-infra/system-config/tree/manifests/site.pp#n266 \n> >\n> >>\n> >>> I\'ll be happy if people start complaining that we are spamming\n> >>> them about voting :-)\n> >>\n> >> It\'s a distinct possibility.\n> >> --\n> >> Jeremy Stanley\n> >> _______________________________________________\n> >> Foundation mailing list\n> >> Foundation at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> >\n> >\n> > _______________________________________________\n> > Foundation mailing list\n> > Foundation at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>\n>\n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n','<27F87AA9-E40A-497E-8A11-EB55D1B2F1CD@openstack.org>',NULL),('<14B2D4D7E4368A48A25DB9ABA48A5E4A25020A4B@G4W3204.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-14 15:33:16',0,'2013-01-14 15:33:16',NULL,'[openstack-dev] Glance hang uploading images','Hi Daniel,\n\nWe\'ve had this in production for sometime (slight different patch on diablo )  and on folsom code base\nwithout issues. (Ubuntu natty and precise)\nIs this specific to Fedora 18? (i.e. do you know if it is reproducible on Fedora 16 for\nExample?)\nThe code change reverts a previous change to use multiple wsgi apps for glance (which was a fix for an \nIssue with multiple worker threads) \nInstead it uses one wsgi app but uses one database engine per worker process so that\nDatabase sessions do not become muddled.\n\nAre you saying all uploading fails on Fedora 18 i.e. Glance does not work on Fedora1 17\nor that after a certain period it fails.\nHow many registry, glance api processes are you using and if you set debugging (sql also)\nWhats in the logs?\n\nI will be happy to help debug if I can reproduce.\n\nThanks,\n\ntherese\n\n\n-----Original Message-----\nFrom: Daniel P. Berrange [mailto:berrange at redhat.com] \nSent: 14 January 2013 14:29\nTo: openstack-dev at lists.openstack.org\nCc: McHale, Therese\nSubject: Glance hang uploading images\n\nEver since this change went into Glance:\n\n  commit 0e9111ca59ee5e487f23f5db91c6f8c33036410b\n  Author: Therese McHale <therese.mchale at hp.com>\n  Date:   Thu Dec 13 13:34:19 2012 +0000\n\n    Use one wsgi app, one dbengine worker.\n\n    Return to using one wsgi application but use one database engine\n    per worker process.\n\n    Fixes Bug #1089916\n\n    Change-Id: Iea4b1b925208317c3c6ee3c9461b6723f3168405\n\nDevstack will get stuck at uploading images into glance. Debugging shows that the glance services themselves have hung. Even after killing the devstack \'glance\' client process, further calls to glance all hang, until the glance services are restarted.\n\nI\'m guessing this is not happening to everyone, otherwise this would have been fixed by now. So does anyone have any ideas why this might be happening ?\n\nI\'m using Fedora 18 and devstack setup fresh from GIT.\n\nRegards,\nDaniel\n-- \n|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n|: http://libvirt.org              -o-             http://virt-manager.org :|\n|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n\n\n','<20130114142852.GG12941@redhat.com>',NULL),('<14B2D4D7E4368A48A25DB9ABA48A5E4A25021366@G4W3204.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-15 11:53:19',0,'2013-01-15 11:53:19',NULL,'[openstack-dev] Glance hang uploading images','Daniel,\n\nApi log shows:\n\n>>2013-01-14 18:42:56.18 DEBUG glance.registry.client [ab1e07b0-97fa-4508-96ac-1d6375282271 1947906b9e9f42e7bdfd29c9219fcda0 1e80f28a9dd1425bb905c1192317cfb2] \n>>Registry request PUT /images/f5a9f8c4-b82b-4192-8379-cb4619bff1d6 HTTP 200 request id req-81b04d9c-0672-4b50-b450-9eb3a764bcdc do_request >>/home/berrange/src/cloud/glance/glance/registry/client.py:95\n\nLooks like the put of the image worked.\n\nBut there is this:\n\n>>No handlers could be found for logger \"qpid.messaging\"\n\nRegistry log shows:\n\n>>2013-01-14 18:42:56.16 INFO glance.registry.api.v1.images [81b04d9c-0672-4b50-b450-9eb3a764bcdc 1947906b9e9f42e7bdfd29c9219fcda0 1e80f28a9dd1425bb905c1192317cfb2] >>Updating metadata for image f5a9f8c4-b82b-4192-8379-cb4619bff1d6 \n\nLooks ok.  If you set this in default_log_levels:    eventlet.wsgi.server=DEBUG,sqlalchemy.DEBUG   I would see more debug, i.e. see the full\nSql resultset to confirm everything returned ok from sql/see more wsgi output.  (This is what was changed in the patch)\n\nOn the qpid/messaging  error...were you getting this before the problem?\nI\'m not using qpid messaging/just using the defaults in the example conf file (e.g. qpid_host=localhost for me as this is what is in the\nExample glance-api.conf,  whereas you use - I think correctly based on the code -  qpid_hostname=localhost, you also have qpid_notificaton_topic=notifications\nWhereas this is set to \'glance_notifications\' on my system.)\n\nIf you log a bug for this and add the extra debug there I can look at it there.\n\n-therese\n\n-----Original Message-----\nFrom: Daniel P. Berrange [mailto:berrange at redhat.com] \nSent: 14 January 2013 18:49\nTo: McHale, Therese\nCc: openstack-dev at lists.openstack.org\nSubject: Re: Glance hang uploading images\n\nOn Mon, Jan 14, 2013 at 03:33:16PM +0000, McHale, Therese wrote:\n> Hi Daniel,\n> \n> We\'ve had this in production for sometime (slight different patch on \n> diablo )  and on folsom code base without issues. (Ubuntu natty and \n> precise) Is this specific to Fedora 18? (i.e. do you know if it is \n> reproducible on Fedora 16 for\n> Example?)\n> The code change reverts a previous change to use multiple wsgi apps \n> for glance (which was a fix for an Issue with multiple worker threads) \n> Instead it uses one wsgi app but uses one database engine per worker \n> process so that Database sessions do not become muddled.\n> \n> Are you saying all uploading fails on Fedora 18 i.e. Glance does not \n> work on Fedora1 17 or that after a certain period it fails.\n> How many registry, glance api processes are you using and if you set \n> debugging (sql also)\n\nIt fails the moment you trying to upload an image, eg\n\n # glance add name=f16-jeos is_public=true disk_format=qcow2 container_format=bare < files/f16-x86_64-openstack-sda.qcow2 \n\nI\'ve not tried on any other Fedora version. The config file settings are all the defaults as set by devstack. I\'ve not modified the number of registry/api processes.\n\n> Whats in the logs?\n\nThe logs are attached here - this is recording from the startup of glance to the hang occurring\n\nRegards,\nDaniel\n-- \n|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n|: http://libvirt.org              -o-             http://virt-manager.org :|\n|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n\n\n','<20130114184909.GK12941@redhat.com>',NULL),('<14B4E107-B349-4CA8-802C-959478484A16@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 16:13:30',-28800,'2013-01-24 00:13:30',NULL,'[openstack-dev] [nova] OSAPI and deleted flavors','\nOn Jan 23, 2013, at 3:38 PM, Kieran Spear <kispear at gmail.com> wrote:\n\n> Hi all,\n> \n> I\'m investigating:\n> https://bugs.launchpad.net/horizon/+bug/1100444\n> \n> Curling v2/tenant_id/flavors/1 we get a previously deleted flavor even if a \"newer\" flavor exists with the same flavor id. This makes it impossible to retrieve the newer flavor directly by ID.\n> \n> We use UUIDs for flavor ids now in Horizon, so it\'s not an issue, but novaclient still allows the flavor id to be specified manually.\n> \n> Does nova itself still allow you to create flavors with the same flavor id as a deleted flavor?\n\n\nYes it does. Although you shouldn\'t be able to access deleted flavors that way so that sounds like a bug.\n\nVish\n\n','<51007486.6020008@gmail.com>',NULL),('<14B571F2-09BC-4504-B389-0DA6094779A4@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-26 09:09:43',-25200,'2013-10-26 16:09:43',NULL,'[openstack-dev] [nova] Thoughs please on how to address a\n	problem with mutliple deletes leading to a nova-compute\n	thread pool problem','Deletes should only be allowed when the vm is in a power off state. This will allow consistent state transition.\n\nThanks\nAl\n\n\nOn Oct 26, 2013, at 8:55 AM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n\n> I think I will try to have a unconference at the HK summit about ideas the cinder developers (and the taskflow developers, since it\'s not a concept that is unique /applicable to just cinder) are having about said state machine (and it\'s potential usage).\n> \n> So look out for that, be interesting to have some nova folks involved there also :-)\n> \n> Sent from my really tiny device...\n> \n> On Oct 26, 2013, at 3:14 AM, \"Alex Glikson\" <GLIKSON at il.ibm.com> wrote:\n> \n>> +1 \n>> \n>> Regards, \n>> Alex \n>> \n>> \n>> Joshua Harlow <harlowja at yahoo-inc.com> wrote on 26/10/2013 09:29:03 AM:\n>> > \n>> > An idea that others and I are having for a similar use case in \n>> > cinder (or it appears to be similar).\n>> > \n>> > If there was a well defined state machine/s in nova with well \n>> > defined and managed transitions between states then it seems like \n>> > this state machine could resume on failure as well as be interrupted\n>> > when a \"dueling\" or preemptable operation arrives (a delete while \n>> > being created for example). This way not only would it be very clear\n>> > the set of states and transitions but it would also be clear how \n>> > preemption occurs (and under what cases). \n>> > \n>> > Right now in nova there is a distributed and ad-hoc state machine \n>> > which if it was more formalized it could inherit some if the \n>> > described useful capabilities. It would also be much more resilient \n>> > to these types of locking problems that u described. \n>> > \n>> > IMHO that\'s the only way these types of problems will be fully be \n>> > fixed, not by more queues or more periodic tasks, but by solidifying\n>> > & formalizing the state machines that compose the work nova does.\n>> > \n>> > Sent from my really tiny device...\n>> > \n>> > > On Oct 25, 2013, at 3:52 AM, \"Day, Phil\" <philip.day at hp.com> wrote:\n>> > > \n>> > > Hi Folks,\n>> > > \n>> > > We\'re very occasionally seeing problems where a thread processing \n>> > a create hangs (and we\'ve seen when taking to Cinder and Glance).  \n>> > Whilst those issues need to be hunted down in their own rights, they\n>> > do show up what seems to me to be a weakness in the processing of \n>> > delete requests that I\'d like to get some feedback on.\n>> > > \n>> > > Delete is the one operation that is allowed regardless of the \n>> > Instance state (since it\'s a one-way operation, and users should \n>> > always be able to free up their quota).   However when we get a \n>> > create thread hung in one of these states, the delete requests when \n>> > they hit the manager will also block as they are synchronized on the\n>> > uuid.   Because the user making the delete request doesn\'t see \n>> > anything happen they tend to submit more delete requests.   The \n>> > Service is still up, so these go to the computer manager as well, \n>> > and eventually all of the threads will be waiting for the lock, and \n>> > the compute manager will stop consuming new messages.\n>> > > \n>> > > The problem isn\'t limited to deletes - although in most cases the \n>> > change of state in the API means that you have to keep making \n>> > different calls to get past the state checker logic to do it with an\n>> > instance stuck in another state.   Users also seem to be more \n>> > impatient with deletes, as they are trying to free up quota for other things. \n>> > > \n>> > > So while I know that we should never get a thread into a hung \n>> > state into the first place, I was wondering about one of the \n>> > following approaches to address just the delete case:\n>> > > \n>> > > i) Change the delete call on the manager so it doesn\'t wait for \n>> > the uuid lock.  Deletes should be coded so that they work regardless\n>> > of the state of the VM, and other actions should be able to cope \n>> > with a delete being performed from under them.  There is of course \n>> > no guarantee that the delete itself won\'t block as well. \n>> > > \n>> > > ii) Record in the API server that a delete has been started (maybe\n>> > enough to use the task state being set to DELETEING in the API if \n>> > we\'re sure this doesn\'t get cleared), and add a periodic task in the\n>> > compute manager to check for and delete instances that are in a \n>> > \"DELETING\" state for more than some timeout. Then the API, knowing \n>> > that the delete will be processes eventually can just no-op any \n>> > further delete requests.\n>> > > \n>> > > iii) Add some hook into the ServiceGroup API so that the timer \n>> > could depend on getting a free thread from the compute manager pool \n>> > (ie run some no-op task) - so that of there are no free threads then\n>> > the service becomes down. That would (eventually) stop the scheduler\n>> > from sending new requests to it, and make deleted be processed in \n>> > the API server but won\'t of course help with commands for other \n>> > instances on the same host.\n>> > > \n>> > > iv) Move away from having a general topic and thread pool for all \n>> > requests, and start a listener on an instance specific topic for \n>> > each running instance on a host (leaving the general topic and pool \n>> > just for creates and other non-instance calls like the hypervisor \n>> > API).   Then a blocked task would only affect request for a specificinstance.\n>> > > \n>> > > I\'m tending towards ii) as a simple and pragmatic solution in the \n>> > near term, although I like both iii) and iv) as being both generally\n>> > good enhancments - but iv) in particular feels like a pretty seismic change.\n>> > > \n>> > > Thoughts please,\n>> > > \n>> > > Phil        \n>> > > \n>> > > _______________________________________________\n>> > > OpenStack-dev mailing list\n>> > > OpenStack-dev at lists.openstack.org\n>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> > \n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> >\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131026/91127fb3/attachment.html>\n\n','<F0E8FC99-6855-43E7-9A38-D632583D43AF@yahoo-inc.com>',NULL),('<14C1148B-D1BA-4DC0-A0F1-D123D746752F@stackstorm.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 14:51:29',-25200,'2014-04-01 21:51:29',NULL,'[openstack-dev] [Mistral] How Mistral handling long running\n	delegate tasks','Even more responses inline :)\nOn Mar 31, 2014, at 8:44 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n\n> More responses inline :)\n> \n> From: Dmitri Zimine <dz at stackstorm.com>\n> Date: Monday, March 31, 2014 at 5:59 PM\n> To: Joshua Harlow <harlowja at yahoo-inc.com>\n> Cc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Subject: Re: [openstack-dev] [Mistral] How Mistral handling long running delegate tasks\n> \n>> Inline...\n>> On Mar 27, 2014, at 5:10 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>> \n>>> Thanks for the description!\n>>> \n>>> The steps here seem very much like what a taskflow engine does (which is good).\n>>> \n>>> To connect this to how I think could work in taskflow.\n>>> Someone creates tasks/flows describing the work to-be-done (converting a DSL -> taskflow tasks/flows/retry[1] objects?)\n>>> On execute(workflow) engine creates a new workflow execution, computes the first batch of tasks, creates executor for those tasks (remote, local?) and executes those tasks.\n>>> Waits for response back from futures returned from executor.\n>>> Receives futures responses (or receives new response DELAY, for example), or exceptions?\n>>> Continues sending out batches of tasks that can be still be executing (aka tasks that don\'t have dependency on output of delayed tasks).\n>>> If any delayed tasks after repeating #2-5 as many times as it can, the engine will shut itself down (see http://tinyurl.com/l3x3rrb).\n>> Why would engine treat long running tasks differently? The model Mistral tried out is the engine sends the batch of tasks and goes asleep; the \'worker/executor\' is calling engine back when the task(s) complete. Can it be applied \n> \n> \n> Not all ways of using taskflow I think want to go \'asleep\', some active conductors I would think actually stay \'awake\', that?s why I was thinking this would be a comprimise, the usage of \'DELAY\' (via exception or return) would allow a task to say it is going to be finished sometime in the future (btw started this @ https://review.openstack.org/#/c/84277/ --- WIP, likely won\'t go into taskflow 0.2 but seems like a reasonable start on something like this proposal). To me offering just the going asleep way means that all users of taskflow need to have some type of entrypoint (rest, mq, other?) that restarts the engine on result finishing. I\'d rather not force that model onto all users (since that seems inappropriate).\nI understand and agree with not enforcing this model on all users. On a flip side, TaskFlow enforces the current model on Mistral :) It calls for supporting more models (to your earlier point of 3rd mode of operations). The BP proposal is a step in the direction but still a compromise. How can we support both \'active\' and \'passive\' models, sharing the same \'library\' - of all things responsible for control flow and data flow?\n\nHere is a strawman (DISCLAIMER: this is sharing ideas and brainstorming: I don\'t know enough of TaksFlow to suggest): \n1) break the run loop: add engine.run_async() method which instead of looping the tasks till the flow completes (http://tinyurl.com/nou2em9), only schedules the first batch and returns; \nhttps://github.com/openstack/taskflow/blob/master/taskflow/engines/action_engine/graph_action.py#L61-L68\n\n2) introduce engine.task_complete(?) method that marks the current task complete, computes the next tasks ready for execution, schedules them and returns; loosely, doing this part: https://github.com/openstack/taskflow/blob/master/taskflow/engines/action_engine/graph_action.py#L75-L85\n\n3) make executor signal engine back by calling engine.task_complete(?): executor.execute_task() submits the task to the worker queue and calls engine.task_complete(status, results, etc.) instead of waiting for task completion and returning the results. \n\nAnd looks like it all can be done as a third lazy_engine, without messing the current two engines? \n\n\n> \n>> \n>>> On delay task finishing some API/webhook/other (the mechanism imho shouldn\'t be tied to webhooks, at least not in taskflow, but should be left up to the user of taskflow to decide how to accomplish this) will be/must be responsible for resuming the engine and setting the result for the previous delayed task.\n>> Oh no, webhook is the way to expose it to 3rd party system. From the library standpoint it\'s just an API call. \n>> \n>> One can do it even now by getting the appropriate Flow_details, instantiating and engine (flow, flow_details) and running it to continue from where it left out. Is it how you mean it? But I keep on dreaming of a passive version of TaskFlow engine which treats all tasks the same and exposes one extra method - handle_tasks. \n> \n> \n> I was thinking that, although I\'m unsure on the one extra method idea, can u explain more :) What would handle_tasks do? Restart/resume the engine (basically the work u stated \'getting the appropriate Flow_details, instantiating and engine (flow, flow_details) and running it to continue\')? Seems like a tiny helper function if its really wanted, but maybe I\'m misunderstanding.  It might be connected into a recent taskflow BP @ https://blueprints.launchpad.net/taskflow/+spec/generic-flow-conductor?\n\nhandle_task ops, I meant, engine.task_complete() - engine\'s call back to receive the task results. See above. \nAgain, I don\'t know enough to suggest TaskFlow solutions. Just brainstorming. \n@Kirill, can you also give his view here? \n>>> Repeat 2 -> 7 until all tasks have executed/failed.\n>>> Profit!\n>> \n>>> This seems like it could be accomplished, although there are race conditions in the #6 (what if multiple delayed requests are received at the same time)? What locking is done to ensure that this doesn\'t cause conflicts?\n>> Engine must handle concurrent calls of mutation methods - start, stop, handle_action. How -  differs depending on engine running in multiple threads or in event loop on queues of calls. \n> \n> \n> Agreed, to me this requires some level of locking, likely something that the tooz library can provide (or in concept is similar to what the jobboard concept provides, single \'atomic\' engine access to a given workflow, ensuring this with a distributing locking scheme, such as zookeeper).\n> \n>> \n>>> Does the POC solve that part (no simultaneous step #5 from below)?\n>> Yes although we may want to revisit the current solution. \n> \n> \n> Is it using some form of database locking? :(\n> \n>> \n>>> There was a mention of a watch-dog (ideally to ensure that delayed tasks can\'t just sit around forever), was that implemented?\n>> If _delayed_ tasks and \'normal\' tasks are treat alike, this is just a matter of timeout as a generic property on a task. So Mistral didn\'t have to have it. For the proposal above, a separate treatment is necessary for _delayed_ tasks. \n> \n> \n> Who responds to the timeout though? Isn\'t that process the watchdog then? Likely the triggering of a timeout causes something to react (in both cases).\nThe workflow engine IS this watch-dog (and in Mistral, engine is a single manager for all flow executions, in the prototype we call it engine_manager and I hate this name :)) Engine live in process or as a separate process. And it is passive - executed in a thread of a callee. E.g., in process is either called on messaging event handler thread, or by web method thread.\n\n\n>>> \n>>> [1] https://wiki.openstack.org/wiki/TaskFlow#Retries (new feature!)\n>> This is nice. I would call it a \'repeater\': running a sub flow several times with various data for various reasons is reacher then \'retry\'. \n>> What about the \'retry policy\' on individual task? \n> \n> \n> We went back and forth on names a few times (controller, retry, and a few others I think), haha. Retry is what currently stuck :-P\n> \n> Repeater does sound nice also though, damn naming of \'things\' ;)\n> \n> For retries on individual tasks since taskflow supports flow nesting its not that hard to do this (although it might not be the most elegant).\n> \n> >>> flow = LinearFlow(\"blah blah\")\n> >>> flow.add(LinearFlow(\"subblahblah\", retry=XYZ).add(OneTask()) <<< where the one task is literally one task, haha.\n> \n> A running example @ http://tinyurl.com/kv8q2t8\n> \n> Room for improvement obviously (isn\'t there always), but that would/should work.\n\nThat may be good enough: when DSL is translated to flow, and the task demands repetition with timeout, it\'s ok to do this trick under the hood when compiling a flow. \nflow.add(LinearFlow(\"subblahblah\", retry=XYZ).add(OneTask().add(Timeout(timeout))\n\n> \n> -Josh\n> \n>> \n>>> \n>>> From: Dmitri Zimine <dz at stackstorm.com>\n>>> Reply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>>> Date: Thursday, March 27, 2014 at 4:43 PM\n>>> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n>>> Subject: [openstack-dev] [Mistral] How Mistral handling long running delegate tasks\n>>> \n>>>> Following up on http://tinyurl.com/l8gtmsw and http://tinyurl.com/n3v9lt8: this explains how Mistral handles long running delegate tasks. Note that a \'passive\' workflow engine can handle both normal tasks and delegates the same way. I\'ll also put that on ActionDesign wiki, after discussion.\n>>>> \n>>>> Diagram: \n>>>> https://docs.google.com/a/stackstorm.com/drawings/d/147_EpdatpN_sOLQ0LS07SWhaC3N85c95TkKMAeQ_a4c/edit?usp=sharing\n>>>> \n>>>> 1. On start(workflow), engine creates a new workflow execution, computes the first batch of tasks, sends them to ActionRunner [1].\n>>>> 2. ActionRunner creates an action and calls action.run(input)\n>>>> 3. Action does the work (compute (10!)), produce the results,  and return the results to executor. If it returns, status=SUCCESS. If it fails it throws exception, status=ERROR.\n>>>> 4. ActionRunner notifies Engine that the task is complete task_done(execution, task, status, results)[2]\n>>>> 5. Engine computes the next task(s) ready to trigger, according to control flow and data flow, and sends them to ActionRunner.\n>>>> 6. Like step 2: ActionRunner calls the action\'s run(input)\n>>>> 7. A delegate action doesn\'t produce results: it calls out the 3rd party system, which is expected to make a callback to a workflow service with the results. It returns to ActionRunner without results, \"immediately\".  \n>>>> 8. ActionRunner marks status=RUNNING [?]\n>>>> 9. 3rd party system takes \'long time\' == longer then any system component can be assumed to stay alive. \n>>>> 10. 3rd party component calls Mistral WebHook which resolves to engine.task_complete(workbook, id, status, results)  \n>>>> \n>>>> Comments: \n>>>> * One Engine handles multiple executions of multiple workflows. It exposes two main operations: start(workflow) and task_complete(execution, task, status, results), and responsible for defining the next batch of tasks based on control flow and data flow. Engine is passive - it runs in a hosts\' thread. Engine and ActionRunner communicate via task queues asynchronously, for details, see  https://wiki.openstack.org/wiki/Mistral/POC \n>>>> \n>>>> * Engine doesn\'t distinct sync and async actions, it doesn\'t deal with Actions at all. It only reacts to task completions, handling the results, updating the state, and queuing next set of tasks.\n>>>> \n>>>> * Only Action can know and define if it is a delegate or not. Some protocol required to let ActionRunner know that the action is not returning the results immediately. A convention of returning None may be sufficient. \n>>>> \n>>>> * Mistral exposes  engine.task_done in the REST API so 3rd party systems can call a web hook.\n>>>> \n>>>> DZ.\n>>>> \n>>>> [1]  I use ActionRunner instead of Executor (current name) to avoid confusion: it is Engine which is responsible for executions, and ActionRunner only runs actions. We should rename it in the code.\n>>>> \n>>>> [2] I use task_done for briefly and out of pure spite, in the code it is conveny_task_results.\n>> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140401/bf4b6177/attachment.html>\n\n','<CF5F8033.5B02D%harlowja@yahoo-inc.com>',NULL),('<14D686E4-398A-4A78-A3B3-EA155036876A@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-09 17:02:08',-14400,'2014-03-09 21:02:08',NULL,'[openstack-dev] [Ironic] A ramdisk agent','FYI, the API scaffolding isn?t actually released yet, though I?m planning on making a pecan release with this in the next week or two.\n\n---\nRyan Petrello\nSenior Developer, DreamHost\nryan.petrello at dreamhost.com\n\nOn Mar 9, 2014, at 12:10 PM, Devananda van der Veen <devananda.vdv at gmail.com> wrote:\n\n> For those looking at Pecan/WSME\'fying the agent, some scaffolding was recently added to Pecan which may interest you.\n> \n> https://review.openstack.org/#/c/78682/\n> \n> \n> -Deva\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAExZKErP7=9ke+NmFa=19Ad+ktTvC980gtwN1i4DuvV_ueF-Bw@mail.gmail.com>',NULL),('<14d81ed3da42b96f8a33989db233d501@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 17:58:38',3600,'2014-03-17 16:58:38',NULL,'[openstack-dev] [Openstack-docs] [Neutron] Docs for new plugins','Hi,\n\nLe 2014-03-17 16:01, Steve Gordon a ?crit?:\n> ----- Original Message -----\n>> Edgar:\n>> \n>> I don\'t see the configuration options for the OpenDaylight ML2\n>> MechanismDriver\n>> added here yet, even though the code was checked in well over a week \n>> ago.\n>> How long does it take to autogenerate this page from the code?\n>> \n>> Thanks!\n>> Kyle\n> \n> Adding the docs list, I suspect there are two issues here. The first\n> is that the generation of the config-reference content is initiated\n> manually and potentially hasn\'t been done since this was added. The\n> second is that prior to running it the flag mappings file needs to be\n> updated [1], this maps a given configuration option to a group and is\n> the main hole in our current automation process for this guide.\n> \n> Edgar/Kyle can you check whether the new options are listed in there\n> and we\'ll arrange to get this re-generated for rc1?\n\nFYI I\'ve just submitted an updated flagmappings (and generated tables) \nfor review: https://review.openstack.org/#/c/81013/\n\nLet me know if the options are there and correctly categorized.\n\nThanks,\n\nGauvain\n\n\n> [1]\n> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/neutron.flagmappings\n> \n>> On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana <emagana at plumgrid.com> \n>> wrote:\n>> \n>>> You should be able to add your plugin here:\n>>> \n>>> http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html\n>>> \n>>> Thanks,\n>>> \n>>> Edgar\n>>> \n>>> From: Mohammad Banikazemi <mb at us.ibm.com>\n>>> Date: Monday, March 10, 2014 2:40 PM\n>>> To: OpenStack List <openstack-dev at lists.openstack.org>\n>>> Cc: Edgar Magana <emagana at plumgrid.com>\n>>> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins\n>>> \n>>> Would like to know what to do for adding documentation for a new \n>>> plugin.\n>>> Can someone point me to the right place/process please.\n>>> \n>>> Thanks,\n>>> \n>>> Mohammad\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n\n\n','<1740319377.1213620.1395068512402.JavaMail.zimbra@redhat.com>',NULL),('<14d81ed3da42b96f8a33989db233d501@objectif-libre.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-17 17:58:38',3600,'2014-03-17 16:58:38',NULL,'[Openstack-docs] [openstack-dev] [Neutron] Docs for new plugins','Hi,\n\nLe 2014-03-17 16:01, Steve Gordon a ?crit?:\n> ----- Original Message -----\n>> Edgar:\n>> \n>> I don\'t see the configuration options for the OpenDaylight ML2\n>> MechanismDriver\n>> added here yet, even though the code was checked in well over a week \n>> ago.\n>> How long does it take to autogenerate this page from the code?\n>> \n>> Thanks!\n>> Kyle\n> \n> Adding the docs list, I suspect there are two issues here. The first\n> is that the generation of the config-reference content is initiated\n> manually and potentially hasn\'t been done since this was added. The\n> second is that prior to running it the flag mappings file needs to be\n> updated [1], this maps a given configuration option to a group and is\n> the main hole in our current automation process for this guide.\n> \n> Edgar/Kyle can you check whether the new options are listed in there\n> and we\'ll arrange to get this re-generated for rc1?\n\nFYI I\'ve just submitted an updated flagmappings (and generated tables) \nfor review: https://review.openstack.org/#/c/81013/\n\nLet me know if the options are there and correctly categorized.\n\nThanks,\n\nGauvain\n\n\n> [1]\n> http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/neutron.flagmappings\n> \n>> On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana <emagana at plumgrid.com> \n>> wrote:\n>> \n>>> You should be able to add your plugin here:\n>>> \n>>> http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html\n>>> \n>>> Thanks,\n>>> \n>>> Edgar\n>>> \n>>> From: Mohammad Banikazemi <mb at us.ibm.com>\n>>> Date: Monday, March 10, 2014 2:40 PM\n>>> To: OpenStack List <openstack-dev at lists.openstack.org>\n>>> Cc: Edgar Magana <emagana at plumgrid.com>\n>>> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins\n>>> \n>>> Would like to know what to do for adding documentation for a new \n>>> plugin.\n>>> Can someone point me to the right place/process please.\n>>> \n>>> Thanks,\n>>> \n>>> Mohammad\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n\n\n','<1740319377.1213620.1395068512402.JavaMail.zimbra@redhat.com>',NULL),('<14dae9340d8f6e4e1404d6050895@google.com>','http://lists.openstack.org/pipermail/transparency',NULL,'2013-02-18 19:50:11',0,'2013-02-18 19:50:11',NULL,'[Transparency] Invitation: OpenStack Transparency Working Group-\n Kickoff @ Thu Feb 21, 2013 9am - 10am (Transparency@lists.openstack.org)','You have been invited to the following event.\n\nTitle: OpenStack Transparency Working Group- Kickoff\nWhen: Thu Feb 21, 2013 9am ? 10am Pacific Time\nCalendar: Transparency at lists.openstack.org\nWho:\n     * Joshua McKenty - organizer\n     * Transparency at lists.openstack.org\n\nEvent details:  \nhttps://www.google.com/calendar/event?action=VIEW&eid=XzYxMWs0ZGE1Nm9xajRiYTI2NHBqYWI5azg4czMyYjlvNm9zM2NiOW42dDE0YWNpNTcxMzNpYzlwNjAgdHJhbnNwYXJlbmN5QGxpc3RzLm9wZW5zdGFjay5vcmc&tok=MjIjam9zaHVhQHBpc3RvbmNsb3VkLmNvbTg5NTJmMTk1ZTc0Y2Q5OWIyMjRlMTMzNGZkZWEwMjc2YTY0Mjc0OTI&ctz=America/Los_Angeles&hl=en\n\nInvitation from Google Calendar: https://www.google.com/calendar/\n\nYou are receiving this courtesy email at the account  \ntransparency at lists.openstack.org because you are an attendee of this event.\n\nTo stop receiving future notifications for this event, decline this event.  \nAlternatively you can sign up for a Google account at  \nhttps://www.google.com/calendar/ and control your notification settings for  \nyour entire calendar.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/transparency/attachments/20130218/cdb5a79e/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: not available\nType: text/calendar\nSize: 1147 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/transparency/attachments/20130218/cdb5a79e/attachment.ics>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: invite.ics\nType: application/ics\nSize: 1177 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/transparency/attachments/20130218/cdb5a79e/attachment.bin>\n\n',NULL,NULL),('<14dc882b.1fee6.148fa122e88.Coremail.dboyzhong@163.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-10 20:39:28',28800,'2014-10-10 12:39:28',NULL,'[OpenStack Foundation] openstack swift performance question','Hi.\n    i am a newer software engineer on swift, i made a performance test againest swift , and i found the performance is worse when i PUT 1KB data to cluster, the QPS is only 16/s? i want to know why the performance is not good when the data is small. bellow is the detail:\nenvironment:\n\n\n1) Computer:  Inter Xeon 2.5G  4 core,   8G Memory an  1TB xfs harddisk(7.2K, SATA)\n2) OS : Centos 6.5\n3) swift cluster across 4 computer and each computer setup all of swift services.\n4) every proxy server configure 8 workers\n5)every object server configure 8 workers\n6)test suite:  swift-bench\n7)swift-bench configure 10 concurrency threads. test 1000 times on 1KB data\n8)using nginx for load banlance\n9)using keystone for auth\n\n\ntest result:\nPUT:           16.7/s\nGET:            82.3/s\nDELETE:     65.4/s\n\n\ncan you give me a official test result? and can you explain why my test is so bad?\n                                                                                                                                                                    thanks!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20141010/849cec9d/attachment.html>\n\n',NULL,NULL),('<14EA320DEB7C0748A4E41977589B7F0C5C39AF3E@ORSMSX105.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 17:50:35',0,'2013-06-06 17:50:35',NULL,'[openstack-dev] [heat] as-update-policy implementation questions','Heat team,\n\nRegarding blueprint https://blueprints.launchpad.net/heat/+spec/as-update-policy, can you answer the following so to help me speed up where to look?\n\n1) I\'m currently thinking that the UpdatePolicy would be enforced (if defined in the stack template) at either AutoScalingGroup.adjust or InstanceGroup.resize in ./heat/engine/resources/autoscaling.py.  I\'m trying to understand the flow.  It\'s not obvious to me where in the cloud watch code that invoke the adjust or resize method when alarm condition is met.  Can you point me in the right direction?\n\n2) Since this relates to rolling update, I need to keep the adjust/resize task in the scheduler until it completed the rolling update.  Do I use the TaskRunner and set up steps in the task with sleep in between steps according to the UpdatePolicy?\n\nAny other guidance?\n\nThanks.\nWinson\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/23891928/attachment.html>\n\n',NULL,NULL),('<14EA320DEB7C0748A4E41977589B7F0C5C3BFDFC@ORSMSX105.amr.corp.intel.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 20:33:08',0,'2013-06-17 20:33:08',NULL,'[openstack-dev] [metrics] Code contribution by 3rd party consultant\n on behalf of a corporation','Metrics team,\n\nIs there a best practice for counting commits made by a 3rd party consultants/contractors (with multiple affiliations) on behalf of another corporation?  I recently had a conversation with Stefano and he suggested adding a \"Contributed for: <affiliation>\" in the commit message.  Stefano recommended that I get the dialog started here...\n\nThanks.\nWinson\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130617/9c1c42b6/attachment.html>\n\n',NULL,NULL),('<14EE2A20-8797-42C3-B472-F2CDD405C401@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-29 09:03:13',-14400,'2013-05-29 13:03:13',NULL,'[openstack-dev] VPNaaS','See inline PCM:\n\nOn May 28, 2013, at 12:37 PM, Eleouet Francois wrote:\n\n>> I think you want to test $file, right?\n> \n> Yes, sorry for that, shouldn\'t have add it as it was meaningless for\n> the example.\n> \n>> Does sound like we want to use Strongswan, if at all possible. This sounds like it\'ll do that, huh?\n> \n> To my opinion, It would be better regarding its documentation and support.\n> \n> The only concern is about strongswan requiring some extra information in\n> /etc or /var/run (as it will only see its own files in it). It isn\'t a\n> problem for the current use case, but it may be required for some extra\n> plugin we may want to use in the future (lots of may...)\n> \n> By the way, I tested it against an actual quantum router deployment,\n\nPCM: I\'d be interested in hearing more about how you set this up.  Are you using DevStack?\n\n\n\n> it\n> works fine but requires some extra tricks: we have to insert iptables\n> rules for traffic to be correctly encrypted. Strongswan is able to insert\n> its own filter rules using \"leftfirewall\" parameter. Anyway, it doesn\'t\n> manages nat rules, so IPsec traffic from VMs won\'t cross the router until\n> we add this kind of iptables rule:\n> \n> iptables -t nat -D POSTROUTING -s local_cidr -d peer_cidr -m policy \\\n> --dir out --pol ipsec --reqid 16384 --proto 50 -j ACCEPT\n\nPCM: Just so I better understand the rule?\n\nIs this applying an IPSec policy on a new connection creation between the source/dest?\n\nHow does it modify the packet (POSTROUTING/output direction)?\n\nCan you elaborate on the --reqid?\nIs that the specific policy that is to be applied?\nHow does that relate to what we are setting up in StrongSwan?\n\n\n> \n> Strongswan can set it automatically if we provide it with a custom _updown\n> script (using \"leftupdown\" parameter).\n\nPCM: Can you elaborate on this more?\n\n\n> IptablesManager could also be an\n> option (reqid is also configurable).\n> \n> Note: this extra driver complexity is probably not specific to strongswan,\n> it\'s probably the same in openswan (not tested).\n\nPCM: Great stuff Francois! I was on vacation and have been trying to catch up since the long holiday weekend.\n\nSounds like we\'re going to try StrongSwan. I had been peeking at OpenSwan a bit and found a book (reading through it to get some background on all this).\n\nI see you provided another script too. Will try that out. Does that have the mapping that Nachi is looking for, to support our primary use case (site to site), or do we need to work on the mapping?\n\nWould like to coordinate who\'s doing what, so we don\'t duplicate effort here. Nachi/Francois, just let me know what you\'re working through and what you\'d like me to look into (I\'m new to IPSec and Free/Open/StrongSwan, but can help out as needed).\n\n\nRegards,\n\nPCM\n\n\n\n\n> \n> Francois.\n\n\n\n','<CAFTAuVd-VGQ9VXj5NtQgPTZj2AgO+2kao51uOpF-KMjEh0EdAw@mail.gmail.com>',NULL),('<14F37EAB727F4BA489D11885B0343B1B@PC201007301138>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-04 14:51:40',28800,'2013-11-04 06:51:40',NULL,'[Openstack] [LBAAS] roadmap','Same question,Vip address from floating IPs currently not supported in load balance vip page.\nIs this till not supported in H release?\nWhat\'s the roadmap if no.\n  ----- Original Message ----- \n  From: Yannick Foeillet \n  To: openstack at lists.openstack.org \n  Sent: Friday, September 06, 2013 11:00 PM\n  Subject: [Openstack] [LBAAS] roadmap\n\n\n  Hi Openstackers,\n\n\n  I am running a grizzly os plateform and i\'ve tried to implement LBAAS with quantum-lbaas-agent package.\n  Installation and configuration are pretty simples, but i was stopped when i tried to assign a floating ip as VIP.\n  It seems not to be supported yet, and i am wondering if anybody knows when this feature will be enabled.\n\n\n  Thanks for answers.\n\n\n  -- \n  Yannick Foeillet\n\n\n\n\n\n------------------------------------------------------------------------------\n\n\n  _______________________________________________\n  Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n  Post to     : openstack at lists.openstack.org\n  Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131104/1e529877/attachment.html>\n\n',NULL,NULL),('<1501537726.24.1365315385668.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-07 06:16:25',0,'2013-04-07 06:16:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #188','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/188/>\n\n------------------------------------------\n[...truncated 950 lines...]\n    test_get                                                     OK    0.03\n    test_get_calling_format_default                              OK    0.02\n    test_get_calling_format_path                                 OK    0.03\n    test_get_non_existing                                        OK    0.03\n    test_get_s3_bad_location                                     OK    0.03\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.21\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.02\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.02\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.09\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.02\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.02\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.02\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: test_results_filtering (glance.tests.functional.test_bin_glance.TestBinGlance)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance.py\",> line 741, in test_results_filtering\n    exitcode, out, err = execute(cmd)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 255, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command bin/glance --port=51488 add is_public=True name=Name1 disk_format=vhd container_format=ovf foo=bar did not succeed. Returned an exit code of 1.\n\nSTDOUT: The progressbar doesn\'t show-up because the headers[x-meta-size] is zero or missing\nUploading image \'Name1\'\n\nFailed to add image. Got error:\nThe request returned 500 Internal Server Error.\nNote: Your image metadata may still be in the registry, but the image\'s status will likely be \'killed\'.\n\n\nSTDERR: WARNING! This tool is deprecated in favor of python-glanceclient (see http://github.com/openstack/python-glanceclient).\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 117.19 secs:\n    50.18    TestGlanceControl.test_bouncing\n    18.55    TestBinGlanceCacheManage.test_queue\n    16.79    TestRootApi.test_version_configurations\n    16.36    TestScrubber.test_delayed_delete\n    15.31    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 926 tests in 727.359s\n\nFAILED (SKIP=106, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.10\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-188\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.1.0\nkombu==2.5.8\nlxml==3.1.1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.xvnX2qHhC7\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/188\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/188/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1501852031.6595010.1353676005242.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 08:06:45',-18000,'2012-11-23 13:06:45',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n> >Wouldn\'t we have to address the same kind of versioning issues?\n>\n> Angus Salkeld wrote:\n> \n> Yes but a much simpler API:\n> provide get_counters() and use Counter().\n> \n> To my mind much less to go wrong.\n\nOK, though as pointed out earlier in the thread, the virt polling API\nwould also be fairly simple and limited (though not necessarily\ncompletely static and unchanging, hence the need for versioning).\n\n> Thierry Carrez wrote:\n>\n> ...but without the process headaches of releasing that layer as a\n> separate library. You\'d still need to agree on an API contract between\n> that plugin and Ceilometer, but it doesn\'t need to leak into release\n> versioning.\n\nOK, so this plugin would just be versioned with the master nova version\n(e.g. 2012.2) and picked up by ceilo from a (complete) local nova install?\n\nCheers,\nEoghan\n\n\n','<20121123101929.GA786@redhat.com>',NULL),('<1501870292.30.1383286351537.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-01 06:12:31',0,'2013-11-01 06:12:31',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #41','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/41/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60ffdd0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5ba12d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5ba12d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-46b5a94f-0f2c-4e35-b9a2-866c3b61d6ef\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x3bc29b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x3bc29b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x3bc29b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x3bc29b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:11:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:11:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:11:52+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'52\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:11:52-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'52\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:11:52Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'52\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'52\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6e1b8d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2880b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.00 secs:\n    26.19    TestScrubber.test_scrubber_app\n    20.65    TestScrubber.test_delayed_delete\n    14.87    TestRootApi.test_version_configurations\n    14.74    TestGlanceControl.test_reload\n    14.55    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 629.534s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.41\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.twSinkTdMu\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/41/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-4/41\n[SCP] Copying console log.\n\n\n','<1746935139.23.1383113579695.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1502344485.1.1376547367746.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-15 06:16:07',0,'2013-08-15 06:16:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #5','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 3737 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 282.93 secs:\n    122.18    KcEssex3TestCase.test_admin_requires_adminness\n    81.08    KcMasterTestCase.test_admin_requires_adminness\n    65.11    Kc11TestCase.test_admin_requires_adminness\n    7.47    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    7.09    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1300 tests in 762.830s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.6.1\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.5\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KqaVbEJHpo\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-7/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1502496069.9661027.1422888337352.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-02-02 15:45:37',3600,'2015-02-02 14:45:37',NULL,'[openstack-dev] [nova][libvirt] RFC: ensuring live\n	migration	ends','\n\n----- Original Message -----\n> From: \"Daniel P. Berrange\" <berrange at redhat.com>\n> To: \"Robert Collins\" <robertc at robertcollins.net>\n> Cc: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>,\n> openstack-operators at lists.openstack.org\n> Sent: Monday, 2 February, 2015 5:56:56 AM\n> Subject: Re: [openstack-dev] [nova][libvirt] RFC: ensuring live migration	ends\n> \n> On Mon, Feb 02, 2015 at 08:24:20AM +1300, Robert Collins wrote:\n> > On 31 January 2015 at 05:47, Daniel P. Berrange <berrange at redhat.com>\n> > wrote:\n> > > In working on a recent Nova migration bug\n> > >\n> > >   https://bugs.launchpad.net/nova/+bug/1414065\n> > >\n> > > I had cause to refactor the way the nova libvirt driver monitors live\n> > > migration completion/failure/progress. This refactor has opened the\n> > > door for doing more intelligent active management of the live migration\n> > > process.\n> > ...\n> > > What kind of things would be the biggest win from Operators\' or tenants\'\n> > > POV ?\n> > \n> > Awesome. Couple thoughts from my perspective. Firstly, there\'s a bunch\n> > of situation dependent tuning. One thing Crowbar does really nicely is\n> > that you specify the host layout in broad abstract terms - e.g. \'first\n> > 10G network link\' and so on : some of your settings above like whether\n> > to compress page are going to be heavily dependent on the bandwidth\n> > available (I doubt that compression is a win on a 100G link for\n> > instance, and would be suspect at 10G even). So it would be nice if\n> > there was a single dial or two to set and Nova would auto-calculate\n> > good defaults from that (with appropriate overrides being available).\n> \n> I wonder how such an idea would fit into Nova, since it doesn\'t really\n> have that kind of knowledge about the network deployment characteristics.\n> \n> > Operationally avoiding trouble is better than being able to fix it, so\n> > I quite like the idea of defaulting the auto-converge option on, or\n> > perhaps making it controllable via flavours, so that operators can\n> > offer (and identify!) those particularly performance sensitive\n> > workloads rather than having to guess which instances are special and\n> > which aren\'t.\n> \n> I\'ll investigate the auto-converge further to find out what the\n> potential downsides of it are. If we can unconditionally enable\n> it, it would be simpler than adding yet more tunables.\n> \n> > Being able to cancel the migration would be good. Relatedly being able\n> > to restart nova-compute while a migration is going on would be good\n> > (or put differently, a migration happening shouldn\'t prevent a deploy\n> > of Nova code: interlocks like that make continuous deployment much\n> > harder).\n> > \n> > If we can\'t already, I\'d like as a user to be able to see that the\n> > migration is happening (allows diagnosis of transient issues during\n> > the migration). Some ops folk may want to hide that of course.\n> > \n> > I\'m not sure that automatically rolling back after N minutes makes\n> > sense : if the impact on the cluster is significant then 1 minute vs\n> > 10 doesn\'t instrinsically matter: what matters more is preventing too\n> > many concurrent migrations, so that would be another feature that I\n> > don\'t think we have yet: don\'t allow more than some N inbound and M\n> > outbound live migrations to a compute host at any time, to prevent IO\n> > storms. We may want to log with NOTIFICATION migrations that are still\n> > progressing but appear to be having trouble completing. And of course\n> > an admin API to query all migrations in progress to allow API driven\n> > health checks by monitoring tools - which gives the power to manage\n> > things to admins without us having to write a probably-too-simple\n> > config interface.\n> \n> Interesting, the point about concurrent migrations hadn\'t occurred to\n> me before, but it does of course make sense since migration is\n> primarily network bandwidth limited, though disk bandwidth is relevant\n> too if doing block migration.\n\nIndeed, there was a lot time spent investigating this topic (in Ovirt again)\nand eventually it was decided to expose a config option and allow 3 concurrent\nmigrations by default.\n\nhttps://github.com/oVirt/vdsm/blob/master/lib/vdsm/config.py.in#L126\n\n> \n> Regards,\n> Daniel\n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> __________________________________________________________________________\n> OpenStack Development Mailing List (not for usage questions)\n> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20150202105656.GF10017@redhat.com>',NULL),('<1502973536.1.1384845074123.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-19 07:11:13',0,'2013-11-19 07:11:13',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #1','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/1/>\n\n------------------------------------------\n[...truncated 20850 lines...]\ntempest.api.object_storage.test_container_acl.ObjectTestACLs.test_write_object_without_using_creds[gate,negative]\ntempest.api.object_storage.test_container_acl.ObjectTestACLs.test_write_object_without_using_creds[gate,negative] ... ok\ntempest.api.object_storage.test_container_acl.ObjectTestACLs.test_write_object_without_write_rights[gate,negative,smoke]\ntempest.api.object_storage.test_container_acl.ObjectTestACLs.test_write_object_without_write_rights[gate,negative,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_large_object[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_large_object[gate,smoke] ... ok\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_too_many_objects[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_too_many_objects[gate,smoke] ... ok\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_valid_object[gate,smoke]\ntempest.api.object_storage.test_container_quotas.ContainerQuotasTest.test_upload_valid_object[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.api.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization[gate]\ntempest.api.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization[gate] ... skipped u\'Skipped until Bug: 1093743 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          136.937\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  84.851\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   74.695\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        42.756\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     40.596\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        39.592\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    36.302\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      35.206\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]          35.062\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                34.880\n\n----------------------------------------------------------------------\nRan 1340 tests in 1335.410s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-678557-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-678557.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-678557/1/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<150389014.249.1364969130371.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-03 06:05:30',0,'2013-04-03 06:05:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #184','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/184/>\n\n------------------------------------------\n[...truncated 2476 lines...]\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_novaclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_novaclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_novaclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_novaclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.2.g62cf0f4 to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.2.g62cf0f4\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.0\nBest match: requests 1.2.0\nrequests 1.2.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.1\nBest match: prettytable 0.7.1\nprettytable 0.7.1 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.2.g62cf0f4\n+ setup_develop /opt/stack/new/python-openstackclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-openstackclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_openstackclient.egg-info\nwriting requirements to python_openstackclient.egg-info/requires.txt\nwriting python_openstackclient.egg-info/PKG-INFO\nwriting top-level names to python_openstackclient.egg-info/top_level.txt\nwriting dependency_links to python_openstackclient.egg-info/dependency_links.txt\nwriting entry points to python_openstackclient.egg-info/entry_points.txt\nwriting manifest file \'python_openstackclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'openstackclient/versioninfo\'\nwarning: no previously-included files matching \'*.pyc\' found anywhere in distribution\nwriting manifest file \'python_openstackclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_openstackclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_openstackclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_openstackclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_openstackclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_openstackclient.egg-info/requires.txt\nDownloading/unpacking cliff (from -r python_openstackclient.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fcliff%2Fcliff-1.3.2.tar.gz\n  Running setup.py egg_info for package cliff\n    \nRequirement already satisfied (use --upgrade to upgrade): keyring in /usr/lib/python2.7/dist-packages (from -r python_openstackclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): pycrypto in /usr/lib/python2.7/dist-packages (from -r python_openstackclient.egg-info/requires.txt (line 3))\nDownloading/unpacking python-glanceclient>=0.5.1 (from -r python_openstackclient.egg-info/requires.txt (line 4))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-glanceclient%2Fpython-glanceclient-0.8.0.tar.gz\n  Running setup.py egg_info for package python-glanceclient\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nRequirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2,<1.0 in /opt/stack/new/python-keystoneclient (from -r python_openstackclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): python-novaclient>=2 in /opt/stack/new/python-novaclient (from -r python_openstackclient.egg-info/requires.txt (line 6))\nDownloading/unpacking python-cinderclient>=1 (from -r python_openstackclient.egg-info/requires.txt (line 7))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-cinderclient%2Fpython-cinderclient-1.0.3.tar.gz\n  Running setup.py egg_info for package python-cinderclient\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from cliff->-r python_openstackclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from cliff->-r python_openstackclient.egg-info/requires.txt (line 1))\nDownloading/unpacking cmd2==0.6.4 (from cliff->-r python_openstackclient.egg-info/requires.txt (line 1))\n  Downloading cmd2-0.6.4.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fcmd2%2Fcmd2-0.6.4.tar.gz\n  Running setup.py egg_info for package cmd2\n    \nDownloading/unpacking pyparsing==1.5.7 (from cliff->-r python_openstackclient.egg-info/requires.txt (line 1))\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyparsing%2Fpyparsing-1.5.7.tar.gz\n  Running setup.py egg_info for package pyparsing\n    \nRequirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient>=0.5.1->-r python_openstackclient.egg-info/requires.txt (line 4))\nDownloading/unpacking warlock>=0.7.0,<2 (from python-glanceclient>=0.5.1->-r python_openstackclient.egg-info/requires.txt (line 4))\n  Downloading warlock-0.8.2.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fwarlock%2Fwarlock-0.8.2.tar.gz\n  Running setup.py egg_info for package warlock\n    \n    warning: no files found matching \'LICENSE\'\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2,<1.0->-r python_openstackclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2,<1.0->-r python_openstackclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2,<1.0->-r python_openstackclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2,<1.0->-r python_openstackclient.egg-info/requires.txt (line 5))\nDownloading/unpacking jsonschema>=0.7,<2 (from warlock>=0.7.0,<2->python-glanceclient>=0.5.1->-r python_openstackclient.egg-info/requires.txt (line 4))\n  Downloading jsonschema-1.1.0.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fjsonschema%2Fjsonschema-1.1.0.tar.gz\n  Running setup.py egg_info for package jsonschema\n    \nDownloading/unpacking jsonpatch>=0.10,<=0.12 (from warlock>=0.7.0,<2->python-glanceclient>=0.5.1->-r python_openstackclient.egg-info/requires.txt (line 4))\n  Downloading jsonpatch-0.12.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fjsonpatch%2Fjsonpatch-0.12.tar.gz\n  Running setup.py egg_info for package jsonpatch\n    \nDownloading/unpacking jsonpointer>=0.6 (from jsonpatch>=0.10,<=0.12->warlock>=0.7.0,<2->python-glanceclient>=0.5.1->-r python_openstackclient.egg-info/requires.txt (line 4))\n  Downloading jsonpointer-0.7.tar.gz\n  Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fjsonpointer%2Fjsonpointer-0.7.tar.gz\n  Running setup.py egg_info for package jsonpointer\n    \nInstalling collected packages: cliff, python-glanceclient, python-cinderclient, cmd2, pyparsing, warlock, jsonschema, jsonpatch, jsonpointer\n  Running setup.py install for cliff\n    \n  Running setup.py install for python-glanceclient\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    Installing glance script to /usr/local/bin\n  Running setup.py install for python-cinderclient\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    Installing cinder script to /usr/local/bin\n  Found existing installation: cmd2 0.6.3\n    Uninstalling cmd2:\n      Successfully uninstalled cmd2\n  Running setup.py install for cmd2\n    \n  Running setup.py install for pyparsing\n    \n  Running setup.py install for warlock\n    \n    warning: no files found matching \'LICENSE\'\n  Running setup.py install for jsonschema\n    \n  Running setup.py install for jsonpatch\n    \n  Running setup.py install for jsonpointer\n    \nSuccessfully installed cliff python-glanceclient python-cinderclient cmd2 pyparsing warlock jsonschema jsonpatch jsonpointer\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_openstackclient.egg-info/requires.txt\nwriting python_openstackclient.egg-info/PKG-INFO\nwriting top-level names to python_openstackclient.egg-info/top_level.txt\nwriting dependency_links to python_openstackclient.egg-info/dependency_links.txt\nwriting entry points to python_openstackclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'openstackclient/versioninfo\'\nwarning: no previously-included files matching \'*.pyc\' found anywhere in distribution\nwriting manifest file \'python_openstackclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-openstackclient.egg-link (link to .)\nAdding python-openstackclient 95bf187 to easy-install.pth file\nInstalling openstack script to /usr/local/bin\n\nInstalled /opt/stack/new/python-openstackclient\nProcessing dependencies for python-openstackclient==95bf187\nerror: Installed distribution prettytable 0.7.1 conflicts with requirement prettytable>=0.6,<0.7\n++ failed\n++ local r=1\n+++ jobs -p\n++ kill\n++ set +o xtrace\nstack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-04-03-060247\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/rabbitmq/rabbit at devstack-1364965302-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/rabbitmq/rabbit at devstack-1364965302.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/184/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1504320863.12689007.1392912486508.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-20 11:08:06',-18000,'2014-02-20 16:08:06',NULL,'[Openstack-docs] Docs meeting minutes on eavesdrop','Hi Anne,\n\nI notice on eavesdrop.openstack.org we\'ve built up quite a collection of different \"names\" (not sure what meetbot calls them) for the docs meetings:\n\n[DIR]	doc_team_meeting/\n[DIR]	doc_web/\n[DIR]	doc_web_meeting/\n[DIR]	doc_web_team/\n[DIR]	doc_web_team_meeting/\n[DIR]	docteam/\n[DIR]	docteammeeting/\n[DIR]	docwebteam/\n\nWould it be possible to:\n\na) Consolidate on a single variation of the above and carve it in stone (ensuring that leaders of both meetings know what it is - for instance the last two APAC ones appear to be in docteam).\n\nb) Get our kindly infra folk to consolidate the above directories into the one decided on above to avoid future confusion.\n\nAsking because it\'s becoming a bit of a guessing game to go back and review an action item or discussion after the fact :).\n\nThanks,\n\nSteve\n\n\n\n','<842519349.12685696.1392912280681.JavaMail.zimbra@redhat.com>',NULL),('<150434243.175.1358319843378.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-16 07:04:03',0,'2013-01-16 07:04:03',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #8','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/8/>\n\n------------------------------------------\n[...truncated 15705 lines...]\nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:34 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-e3ccc6a4-faa7-40fa-995c-ca6239c2c636\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\nSKIP: No OpenStack Network API endpoint\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/52a635a3-e14c-4f6f-b3d2-37ff4a57c226\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:30 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-51c49613-6c8b-4df5-8dc4-a7e737f00250\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/39ea13f5-2ab5-45b1-b21c-3882a4c4721f\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:30 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-063d401b-2acb-4dee-b6ae-73be5b85da24\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/3328ed77-7ec8-4729-9328-b8d8a51be0f4\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:31 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d2525d3c-1f3b-4022-9897-aec660eace04\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/851eb1a4-2677-4443-9a53-bb2cbf0d459c\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:31 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-bb87bcf9-5c71-4026-b9eb-0d3f15b92815\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/7324acc9-ef65-4111-a0d1-8dd8799229b4\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:31 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-846d1132-8fe7-4657-be5a-7c352c381f8d\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/732ca3a3-b82c-4bbc-967d-c8a700400f01\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:32 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d4be907b-b135-492e-a51d-dd7f802283b0\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/98869cd0-88eb-448e-9c28-1399e06de61f\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:32 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c44c3e38-5f01-4e76-80fa-c3f6f7078796\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/26b4821a-dde8-4871-b0c2-777943fc2635\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:33 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-dd799516-d44a-4577-ae3f-f56160fff9ec\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/71cdbcba-621c-47ca-b41f-b08b7ebbf89f\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:33 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-5a71978e-afa7-4daf-8c48-8fd0ab629221\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNlQwNzowMDoyMi4zOTk1NTIiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE3VDA3OjAwOjIyWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvOTVjZDlhM2ViY2NjNGMwZWI5ZGZlNzI4MzhjNzY2ZTAiLCAiaWQiOiAiMzEyZTk5Njk4ZThmNGM3MzkyNDZjMjdiNDIwMjhmOWYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIxNTU5MGM5YzcyMTc0ODIzYjI5YTgwZTc5YjlhMzdmMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMmIwMzRhNWFkOTczNDAwMzk1OTM2MmFiMGQzMjEyZmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCIsICJpZCI6ICJhYjcyMzUzMjllMDc0Y2ExOGRmODdkNGI5MTgxNzNhYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIxZDQwY2Q5ZTk1ZGM0ZWFiYTFkZTVjMWE1MWJlZWY3NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzk1Y2Q5YTNlYmNjYzRjMGViOWRmZTcyODM4Yzc2NmUwIiwgImlkIjogIjAzYjk4ODM1OWU4ZTQ3ZTRiYmE3NWYzZmVkYWFkYzhhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF85NWNkOWEzZWJjY2M0YzBlYjlkZmU3MjgzOGM3NjZlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjBmYWVmNTEwZjM4ZDQxZmJhZGFiMTZjMTkxOTJkZGE1IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNjdlNDdkYjhmOGJkNDRmNTgzYTUzYWRlMDZmNjM1M2IiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOWFlMWZhMjhiNGRiNDJjZTlmZDk1ZGYwMjg2M2I0YmEiLCAiZWE4N2VjZGQ3NzI0NGM0NGI4MWRhNGM4ZTM4MzhhMGIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBN+JRT4t8SjoaVGM+O5SL6XM6i8srES0XnwTl29F5LpeuPwEKwOZov1873jyOwA4mr82Jv+wmdm64vM0L92lShPA30uU0SP3ggkQBt+oOcU6wAJVJq29UGFDdMnHyGNh-IC8nUzCLlLDxYcYcJt3-S5RRA+RnVRMuGLgzbQYtLUA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/ad7e4af8-8b61-49ef-8308-5dd2d92103df\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Wed, 16 Jan 2013 07:00:34 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-e3ccc6a4-faa7-40fa-995c-ca6239c2c636\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 659 tests in 2078.658s\n\nOK (SKIP=78)\nGenerating coverage report\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 194, in <module>\n    main(sys.argv)\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 179, in main\n    shutil.copytree(path, CLI.output)\n  File \"/usr/lib/python2.7/shutil.py\", line 175, in copytree\n    os.makedirs(dst)\n  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\n    mkdir(name, mode)\nOSError: [Errno 13] Permission denied: \'<https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/ws/logs/coverage-report\'>\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/rabbitmq/rabbit at devstack-1358290911-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/rabbitmq/rabbit at devstack-1358290911.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/8/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1679629631.158.1358236817318.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1504476039.425.1367129109506.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:05:09',0,'2013-04-28 06:05:09',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-docs-stable-folsom #209','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/209/>\n\n\n\n','<1664582651.378.1367042724065.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1504780510.7875.1409356111994.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-08-29 23:48:31',0,'2014-08-29 23:48:31',NULL,'[OpenStack Foundation] Listing director \"class\" on our web site','It is similarly the case that Sean Roberts is listed as a director (representing Yahoo), however, since his recent departure from Yahoo, should not be listed either.?Gil Yehuda,?Person. Open Source, Standards, and many words \n\n     On Friday, August 29, 2014 2:29 AM, Nicolas Barcet <nicolas at barcet.com> wrote:\n   \n \n\n For what it is worth, note that I am still listed as a director on this page, which I am not anymore.\nNick\n\nOn Fri, Aug 29, 2014 at 1:04 AM, <Rob_Hirschfeld at dell.com> wrote:\n\nMichael,?The list exists here: http://www.openstack.org/blog/tag/elections/ ?I believe this was discussed at some point and, since we are all supposed to represent OpenStack not our companies, was not included.? I?m not taking a position, just trying to recall the discussion.?Rob> -----Original Message-----\n> From: Michael Still [mailto:mikal at stillhq.com]\n> Sent: Thursday, August 28, 2014 2:16 PM\n> To: foundation at lists.openstack.org\n> Subject: [OpenStack Foundation] Listing director \"class\" on our web \n> site\n> \n> Hi!\n> \n> Would it be possible to get the type of director for each board \n> position listed on \n> http://www.openstack.org/foundation/board-of-directors/ ? I think it would be good for it to be obvious who is an individual director for example.\n> \n> Thanks,\n> Michael\n> \n> --\n> Rackspace Australia\n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n\n\n\n-- \nNicolas Barcet <nicolas at barcet.com>\na.k.a. nijaba, nick\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\n \n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140829/bef72c96/attachment.html>\n\n','<CAEcpoL9jy8MkKukTE0wSwA716rgASqXnLfnnUAygYg2dWHA5oQ@mail.gmail.com>',NULL),('<1504790312.2332176.1352965868809.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 02:51:08',-18000,'2012-11-15 07:51:08',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n\n> Yeah, the derived metric was probably a bad example, if the time\n> samples were actually timestamped on the nova side (e.g. at the\n\ns/actually/accurately/\n\n> time of reading from libvirt as opposed to a random number of\n> millis later when the notification is sent) then the derivation\n> could indeed be done on the consumer side.\n\n\n','<186013382.2331753.1352965548163.JavaMail.root@redhat.com>',NULL),('<1504974440.10790873.1380511492676.JavaMail.hzfangjh@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-30 11:23:39',28800,'2013-09-30 03:23:39',NULL,'[Openstack] Review request for bp add-multi-availability-zones-tests','Hi everyone,\n\nI registered a blue print:\n\n- Specify availability zones when creating servers\nhttps://blueprints.launchpad.net/tempest/+spec/add-multi-availability-zones-tests\n\nPlease check and review it.\n\nBest Regards,\nJinhe Fang\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20130930/ee3decfb/attachment.html>\n\n',NULL,NULL),('<1505359014.61.1373522817531.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-11 06:06:57',0,'2013-07-11 06:06:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #283','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/283/>\n\n------------------------------------------\n[...truncated 2680 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.110.ga45c49b to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.110.ga45c49b\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.110.ga45c49b\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.2.gc460ebf to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.2.gc460ebf\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.2.gc460ebf\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/rabbitmq/rabbit at devstack-1373522493-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/rabbitmq/rabbit at devstack-1373522493.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/283/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1271397673.55.1373436293855.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1505934.DFE397IUbE@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-02 12:08:02',36000,'2014-10-02 02:08:02',NULL,'[openstack-dev] [kolla] Kolla Blueprints','On Wed, 1 Oct 2014 09:05:23 PM Fox, Kevin M wrote:\n> Has anyone figured out a way of having a floating ip like feature with\n> docker so that you can have rabbitmq, mysql, or ceph mon\'s at fixed ip\'s\n> and be able to migrate them around from physical host to physical host and\n> still have them at fixed locations that you can easily put in static config\n> files?\n\nThis is part of the additional functionality kubernetes adds on top of docker.\n\nkubernetes uses a \"proxy\" on every host which knows about all the published \n\"services\".  The services share a port space (ie: every service has to have a \nunique port assigned), and the proxies know where to forward requests to find \none of the backends for that service.\n\ndocker communicates parameters via environment variables and has a few \nstandard environment variables that are used for \"links\" to other containers.  \nKubernetes also uses these link env variables but points them at the proxies \ninstead of directly to the other containers.  Since oslo.config can\'t look up \nenvironment variables directly (that\'s something I\'d like to add), I have a \nsimple shell one-liner that expands environment variables in the relevant \nconfig files before starting the openstack server.\n\nAs a concrete example: I configure a keystone service in my kubernetes config \nand in my static config files I use values like:\n\n   identity_uri = http://$ENV[KEYSTONE_PORT_5000_TCP_ADDR]:\n$ENV[KEYSTONE_PORT_5000_TCP_PORT]/v2.0\n\ndocker/kubernetes sets those env variables to refer to the proxy on the local \nhost and the port number from my service config - this information is static \nfor the lifetime of that docker instance.  The proxy will reroute the requests \ndynamically to wherever the actual instances are running right now.\n\nI hope that\'s enough detail - I encourage you to read the kubernetes docs \nsince they have diagrams, etc that will make it much clearer than the above.\n\n - Gus\n\n> Maybe iptables rules? Maybe adding another bridge? Maybe just disabling the\n> docker network stack all together and binding the service to a fixed,\n> static address on the host?\n> \n> Also, I ran across:\n> http://jperrin.github.io/centos/2014/09/25/centos-docker-and-systemd/ and\n> it does seem to work. I was able to get openssh-server and keystone to work\n> in the same container without needing to write custom start/stop scripts.\n> This kind of setup would make a nova compute container much, much easier.\n> \n> Thanks,\n> Kevin\n> ________________________________\n> From: Steven Dake [sdake at redhat.com]\n> Sent: Wednesday, October 01, 2014 8:04 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [kolla] Kolla Blueprints\n> \n> On 09/30/2014 09:55 AM, Chmouel Boudjnah wrote:\n> \n> On Tue, Sep 30, 2014 at 6:41 PM, Steven Dake\n> <sdake at redhat.com<mailto:sdake at redhat.com>> wrote:\n> \n> I\'ve done a first round of prioritization.  I think key things we need\n> people to step up for are nova and rabbitmq containers.\n> \n> For the developers, please take a moment to pick a specific blueprint to\n> work on.  If your already working on something, this hsould help to prevent\n> duplicate work :)\n> \n> \n> As I understand in the current implementations[1]  the containers are\n> configured with a mix of shell scripts using crudini and other shell\n> command. Is it the way to configure the containers? and is a deployment\n> tool like Ansible (or others) is something that is planned to be used in\n> the future?\n> \n> Chmouel\n> \n> Chmouel,\n> \n> I am not really sure what the best solution to configure the containers.  It\n> is clear to me the current shell scripts are fragile in nature and do not\n> handle container restart properly.  The idea of using Puppet or Ansible as\n> a CM tool has been discussed with no resolution.  At the moment, I\'m\n> satisified with a somewhat hacky solution if we can get the containers\n> operational.\n> \n> Regards,\n> -steve\n> \n> \n> \n> \n> [1] from https://github.com/jlabocki/superhappyfunshow/\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \n - Gus\n\n\n','<1A3C52DFCD06494D8528644858247BF0885A16@EX10MBOX03.pnnl.gov>',NULL),('<15062102-F4B6-4D0E-AD16-95C72DC6282A@alcatel-lucent.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-05 07:22:33',0,'2014-10-05 07:22:33',NULL,'[openstack-dev] ETSI NFV gap analysis [NFV]','Team,\n\nFollowing my action item from last week  IRC.\nIt seems that the document is ready for submission by ETSI NFV team.\nIt was written in a liaison form as this is how they are used to operate.\nThey are wondering who should they send it to...\nIMHO it seems a good idea that the NFV sub group will \"receive\" it in behalf of the community.\n\nThoughts?\n\nItai\n\nSent from my iPhone\n\n',NULL,NULL),('<1506312.zbyrY9FoEP@cacao>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 08:58:05',7200,'2014-06-10 06:58:05',NULL,'[openstack-dev] [Cinder] DRBD integration as volume driver','Hello Duncan,\n\n> The best thing to do with the code is push up a gerrit review! No need\n> to be shy, and you\'re very welcome to push up code before the\n> blueprint is in, it just won\'t get merged.\nthank you for your encouragement!\n\n\nI pushed another fix for Cinder last week (2 lines, allowing to start \nthe services via \"pudb\") by committing\n\n\ncommit 7b6c6685ba3fb40b6ed65d8e3697fa9aac899d85\nAuthor: Philipp Marek <philipp.marek at linbit.com>\nDate:   Fri Jun 6 11:48:52 2014 +0200\n\n    Make starting cinder services possible with \"pudb\", too.\n\n\nI had that rebased to be on top of\n    6ff7d035bf507bf2ec9d066e3fcf81f29b4b481c\n(the then-master HEAD), and pushed to\n    refs/for/master\non\n    ssh://phmarek at review.openstack.org:29418/openstack/cinder\n\nbut couldn\'t find the commit in Gerrit anywhere ..\n\nEven a search\n    https://review.openstack.org/#/q/owner:self,n,z\nis empty.\n\n\nClicking around I found\n    https://review.openstack.org/#/admin/projects/openstack/cinder\nwhich says \n    Require a valid contributor agreement to upload: TRUE\nbut to the best of my knowledge this should be done:\n    https://review.openstack.org/#/settings/agreements\nsays\n    Verified   ICLA   OpenStack Individual Contributor License Agreement\n\n\nSo I\'m a bit confused right now - what am I doing wrong?\n\n\n\n> I\'m very interested in this code.\nAs soon as I\'ve figured out how this Gerrit thing works you can take a \nlook ... (or even sooner, see the github link in my previous mail.)\n\n\n\nRegards,\n\nPhil\n\n\n\n','<CAOyZ2aHUf_=O9ZVJ6OqfPDGXqB=RohJ4VqZtjmY9S1m3um-8PQ@mail.gmail.com>',NULL),('<1506408519.11752229.1417430217629.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-01 05:36:57',-18000,'2014-12-01 10:36:57',NULL,'[openstack-dev] [api] Counting resources','\n\n> detail=concise is not a media type and looking at the grammar in the RFC it\n> wouldn?t be valid.\n> I think the grammar would allow for \"application/json; detail=concise\". See\n> the last line in the definition of the \"media-range\" nonterminal in the\n> grammar (copied below for convenience):\n> Accept         = \"Accept\" \":\"\n>                         #( media-range [ accept-params ] )\n> media-range    = ( \"*/*\"\n>                         | ( type \"/\" \"*\" )\n>                         | ( type \"/\" subtype )\n>                         ) *( \";\" parameter )\n>        accept-params  = \";\" \"q\" \"=\" qvalue *( accept-extension )\n>        accept-extension = \";\" token [ \"=\" ( token | quoted-string ) ]\n> The grammar does not define the \"parameter\" nonterminal but there is an\n> example in the same section that seems to suggest what it could look like:\n> Accept: text/*, text/html, text/html;level=1, */*\n> Shaunak\n> On Nov 26, 2014, at 2:03 PM, Everett Toews < everett.toews at RACKSPACE.COM >\n> wrote:\n> \n> \n> \n> \n> On Nov 20, 2014, at 4:06 PM, Eoghan Glynn < eglynn at redhat.com > wrote:\n> \n> \n> \n> How about allowing the caller to specify what level of detail\n> they require via the Accept header?\n> \n> ? GET /<prefix>/<resource_name>\n> Accept: application/json; detail=concise\n> \n> \"The Accept request-header field can be used to specify certain media types\n> which are acceptable for the response.? [1]\n> \n> detail=concise is not a media type and looking at the grammar in the RFC it\n> wouldn?t be valid. It?s not appropriate for the Accept header.\n\nWell it\'s not a media type for sure, as it\'s intended to be an\n\"accept-extension\".\n\n(which is allowed by the spec to be specified in the Accept header,\n in addition to media types & q-values)\n\nCheers,\nEoghan\n \n> Everett\n> \n> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<18E25F50-F987-48AF-AF41-D030E2377DD5@rackspace.com>',NULL),('<150641609.3489845.1392912736901.JavaMail.zimbra@dneg.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-20 16:12:16',0,'2014-02-20 16:12:16',NULL,'[openstack-dev] git-review patch: Fix parsing of SCP-style URLs','Really don\'t want to have to resolve conflicts again or battle through making the test suite succeed... Please can someone merge this? \n\nhttps://review.openstack.org/#/c/72751/ \nhttps://bugs.launchpad.net/git-review/+bug/1279016 \n\nThanks! \n\nAlexander Jones \nDouble Negative R&D \nwww.dneg.com \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/dda7ad0f/attachment.html>\n\n','<194215642.3489390.1392912683609.JavaMail.zimbra@dneg.com>',NULL),('<1506454316.32.1355789629822.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-18 00:13:49',0,'2012-12-18 00:13:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #78','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/78/>\n\n\n\n','<1554139905.21.1355703138302.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1506897088.355.1355098386751.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-10 00:13:06',0,'2012-12-10 00:13:06',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #70','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/70/>\n\n------------------------------------------\n[...truncated 11852 lines...]\nPASS euca\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nFailure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\n\n======================================================================\nERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n    CONFIG = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n    super(UsersTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n    super(BaseIdentityAdminTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n    super(UsersTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n    super(BaseIdentityAdminTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n    super(VolumesActionsTest, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n    super(VolumesGetTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n    super(VolumesGetTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n    super(VolumeListTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n    super(VolumeListTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 1 test in 0.024s\n\nFAILED (errors=8)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/rabbitmq/rabbit at devstack-1354994451-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/rabbitmq/rabbit at devstack-1354994451.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/70/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1353314818.316.1355011945527.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1508084037.98.1384409554793.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-14 06:12:34',0,'2013-11-14 06:12:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #56','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/56/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3df1110>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x49b06d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x49b06d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-96b05ba5-ce3c-4c50-84d4-388d06586a61\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x3034cf8> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x3034cf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x3034cf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x3034cf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:11:51Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'51\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'51\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-15T06:11:51Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'51\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'15\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'51\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-16T06:11:51+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'51\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'16\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'16\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'51\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-16T06:11:51-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'51\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'16\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'16\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'51\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2013-11-17T06:11:51Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'51\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'17\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'17\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'51\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x625e790>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1cf1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 92.13 secs:\n    26.48    TestScrubber.test_scrubber_app\n    20.88    TestScrubber.test_delayed_delete\n    15.14    TestRootApi.test_version_configurations\n    15.03    TestGlanceControl.test_reload\n    14.59    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 654.482s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.16.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.56\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Yxb9VUu5HN\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/56/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-11/56\n[SCP] Copying console log.\n\n\n','<2008410105.93.1384323230506.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1508227350.15.1357345230692.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-05 00:20:30',0,'2013-01-05 00:20:30',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-folsom #96','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-folsom/96/changes>\n\n\n\n','<1029073497.353.1357258419702.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1508356604.6174013.1375021011779.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-28 10:16:51',-14400,'2013-07-28 14:16:51',NULL,'[openstack-dev] Fwd: Blueprint information','Hi\n\nHi, I am interested in helping out with QE efforts on upstream\nOpenStack, specifically around Neutron.\n\nI\'m trying to understand the following blueprint,can you please point me to more detailed design\n\nhttps://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip\n\n\nThanks\n\nOfer Blaut  \n\n\n\n','<1040779228.6173927.1375020924402.JavaMail.root@redhat.com>',NULL),('<1508536.FNC9VmlF4z@bort.suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 18:01:12',3600,'2014-03-27 17:01:12',NULL,'[openstack-dev] [Horizon] pre-running lesscpy','On Thursday 27 March 2014 16:32:37 Christian Berendt wrote:\n> Hi.\n> \n> Is it possible to pre-run lesscpy? When accessing Horizon in my devstack\n> environment the first time lesscpy is always running several seconds in\n> the background.\n\nI\'ve started to investigate Cython for lesscpy. That should speed things up. \n0.10.1 is slightly faster already, but it was deferred to Juno (See \nhttps://review.openstack.org/#/c/70619/)\n\n> Tried to run python manage.py compress (setting COMPRESS_OFFLINE=True in\n> the settings.py), but afterwards lesscpy is still running in the\n> background when accessing Horizon the first time.\n\nThis is odd. I\'ll have a look...\n-- \nViele Gr??e,\nSascha Peilicke\n\n\n','<53344495.7000603@b1-systems.de>',NULL),('<1509960714.23731.1378849097835.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-10 14:38:17',-25200,'2013-09-10 21:38:17',NULL,'[openstack-dev] [nova] [pci device passthrough] fails with\n \"NameError: global name \'_\' is not defined\"','\n\n----- Original Message -----\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n> To: \"David Kang\" <dkang at isi.edu>\n> Cc: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, September 10, 2013 5:17:15 PM\n> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails with \"NameError: global name \'_\' is not defined\"\n> On 09/10/2013 05:03 PM, David Kang wrote:\n> >\n> > ----- Original Message -----\n> >> From: \"Russell Bryant\" <rbryant at redhat.com>\n> >> To: \"OpenStack Development Mailing List\"\n> >> <openstack-dev at lists.openstack.org>\n> >> Cc: \"David Kang\" <dkang at isi.edu>\n> >> Sent: Tuesday, September 10, 2013 4:42:41 PM\n> >> Subject: Re: [openstack-dev] [nova] [pci device passthrough] fails\n> >> with \"NameError: global name \'_\' is not defined\"\n> >> On 09/10/2013 03:56 PM, David Kang wrote:\n> >>>\n> >>>  Hi,\n> >>>\n> >>>   I\'m trying to test pci device passthrough feature.\n> >>> Havana3 is installed using Packstack on CentOS 6.4.\n> >>> Nova-compute dies right after start with error \"NameError: global\n> >>> name \'_\' is not defined\".\n> >>> I\'m not sure if it is due to misconfiguration of nova.conf or bug.\n> >>> Any help will be appreciated.\n> >>>\n> >>> Here is the info:\n> >>>\n> >>> /etc/nova/nova.conf:\n> >>> pci_alias={\"name\":\"test\", \"product_id\":\"7190\", \"vendor_id\":\"8086\",\n> >>> \"device_type\":\"ACCEL\"}\n> >>>\n> >>> pci_passthrough_whitelist=[{\"vendor_id\":\"8086\",\"product_id\":\"7190\"}]\n> >>>\n> >>>  With that configuration, nova-compute fails with the following\n> >>>  log:\n> >>>\n> >>>   File\n> >>>   \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> >>>   line 461, in _process_data\n> >>>     **args)\n> >>>\n> >>>   File\n> >>>   \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\",\n> >>>   line 172, in dispatch\n> >>>     result = getattr(proxyobj, method)(ctxt, **kwargs)\n> >>>\n> >>>   File\n> >>>   \"/usr/lib/python2.6/site-packages/nova/conductor/manager.py\",\n> >>>   line 567, in object_action\n> >>>     result = getattr(objinst, objmethod)(context, *args, **kwargs)\n> >>>\n> >>>   File \"/usr/lib/python2.6/site-packages/nova/objects/base.py\",\n> >>>   line\n> >>>   141, in wrapper\n> >>>     return fn(self, ctxt, *args, **kwargs)\n> >>>\n> >>>   File\n> >>>   \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\",\n> >>>   line 242, in save\n> >>>     self._from_db_object(context, self, db_pci)\n> >>>\n> >>> NameError: global name \'_\' is not defined\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup Traceback (most recent call\n> >>> last):\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py\",\n> >>> line 117, in wait\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup x.wait()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py\",\n> >>> line 49, in wait\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return self.thread.wait()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line\n> >>> 166, in wait\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return self._exit_event.wait()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/eventlet/event.py\", line 116, in\n> >>> wait\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return hubs.get_hub().switch()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py\", line 177,\n> >>> in switch\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return self.greenlet.switch()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line\n> >>> 192, in main\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup result = function(*args,\n> >>> **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/service.py\",\n> >>> line 65, in run_service\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup service.start()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/service.py\", line 164, in\n> >>> start\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup self.manager.pre_start_hook()\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line\n> >>> 805, in pre_start_hook\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> self.update_available_resource(nova.context.get_admin_context())\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line\n> >>> 4773, in update_available_resource\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> rt.update_available_resource(context)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py\",\n> >>> line 246, in inner\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return f(*args, **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> >>> line 318, in update_available_resource\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup self._sync_compute_node(context,\n> >>> resources)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> >>> line 347, in _sync_compute_node\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup self._update(context, resources,\n> >>> prune_stats=True)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> >>> line 420, in _update\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup self.pci_tracker.save(context)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/pci/pci_manager.py\", line\n> >>> 126, in save\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup dev.save(context)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/objects/base.py\", line 134,\n> >>> in wrapper\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup ctxt, self, fn.__name__, args,\n> >>> kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/conductor/rpcapi.py\", line\n> >>> 497, in object_action\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup objmethod=objmethod, args=args,\n> >>> kwargs=kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/rpcclient.py\", line 85, in\n> >>> call\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return\n> >>> self._invoke(self.proxy.call, ctxt, method, **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/rpcclient.py\", line 63, in\n> >>> _invoke\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return cast_or_call(ctxt, msg,\n> >>> **self.kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/proxy.py\",\n> >>> line 126, in call\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup result = rpc.call(context,\n> >>> real_topic, msg, timeout)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/__init__.py\",\n> >>> line 139, in call\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return _get_impl().call(CONF,\n> >>> context, topic, msg, timeout)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py\",\n> >>> line 794, in call\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> rpc_amqp.get_connection_pool(conf,\n> >>> Connection))\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> >>> line 574, in call\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup rv = list(rv)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> >>> line 539, in __iter__\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup raise result\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup NameError: global name \'_\' is\n> >>> not\n> >>> defined\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup Traceback (most recent call\n> >>> last):\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> >>> line 461, in _process_data\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup **args)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\",\n> >>> line 172, in dispatch\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup result = getattr(proxyobj,\n> >>> method)(ctxt, **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/conductor/manager.py\", line\n> >>> 567, in object_action\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup result = getattr(objinst,\n> >>> objmethod)(context, *args, **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/objects/base.py\", line 141,\n> >>> in wrapper\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup return fn(self, ctxt, *args,\n> >>> **kwargs)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup File\n> >>> \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\",\n> >>> line\n> >>> 242, in save\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup self._from_db_object(context,\n> >>> self, db_pci)\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup\n> >>> 2013-09-10 12:52:23.774 14749 TRACE\n> >>> nova.openstack.common.threadgroup NameError: global name \'_\' is\n> >>> not\n> >>> defined\n> >>\n> >> Can you file a bug for this?\n> >>\n> >> Fix here: https://review.openstack.org/45949\n> >>\n> >> --\n> >> Russell Bryant\n> >\n> >\n> >\n> >  Thanks, Russell.\n> >\n> >  The bug is reported.\n> > https://bugs.launchpad.net/nova/+bug/1223559\n> >\n> >  But, another error happens after the patch is applied. \"TypeError:\n> >  expected string or buffer\".\n> >\n> > ----- log message -----\n> >\n> >   File\n> >   \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> >   line 461, in _process_data\n> >     **args)\n> >\n> >   File\n> >   \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\",\n> >   line 172, in dispatch\n> >     result = getattr(proxyobj, method)(ctxt, **kwargs)\n> >\n> >   File \"/usr/lib/python2.6/site-packages/nova/conductor/manager.py\",\n> >   line 567, in object_action\n> >     result = getattr(objinst, objmethod)(context, *args, **kwargs)\n> >\n> >   File \"/usr/lib/python2.6/site-packages/nova/objects/base.py\", line\n> >   141, in wrapper\n> >     return fn(self, ctxt, *args, **kwargs)\n> >\n> >   File\n> >   \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\",\n> >   line 243, in save\n> >     self._from_db_object(context, self, db_pci)\n> >\n> >   File\n> >   \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\",\n> >   line 150, in _from_db_object\n> >     pci_device.extra_info = jsonutils.loads(extra_info)\n> >\n> >   File\n> >   \"/usr/lib/python2.6/site-packages/nova/openstack/common/jsonutils.py\",\n> >   line 158, in loads\n> >     return json.loads(s)\n> >\n> >   File \"/usr/lib64/python2.6/json/__init__.py\", line 307, in loads\n> >     return _default_decoder.decode(s)\n> >\n> >   File \"/usr/lib64/python2.6/json/decoder.py\", line 319, in decode\n> >     obj, end = self.raw_decode(s, idx=_w(s, 0).end())\n> >\n> > TypeError: expected string or buffer\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup Traceback (most recent call last):\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py\",\n> > line 117, in wait\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup x.wait()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/threadgroup.py\",\n> > line 49, in wait\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return self.thread.wait()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line\n> > 166, in wait\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return self._exit_event.wait()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/eventlet/event.py\", line 116, in\n> > wait\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return hubs.get_hub().switch()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/eventlet/hubs/hub.py\", line 177,\n> > in switch\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return self.greenlet.switch()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/eventlet/greenthread.py\", line\n> > 192, in main\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup result = function(*args, **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/service.py\",\n> > line 65, in run_service\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup service.start()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/service.py\", line 164, in\n> > start\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup self.manager.pre_start_hook()\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line\n> > 805, in pre_start_hook\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > self.update_available_resource(nova.context.get_admin_context())\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line\n> > 4773, in update_available_resource\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > rt.update_available_resource(context)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py\",\n> > line 246, in inner\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return f(*args, **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> > line 318, in update_available_resource\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup self._sync_compute_node(context,\n> > resources)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> > line 347, in _sync_compute_node\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup self._update(context, resources,\n> > prune_stats=True)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/compute/resource_tracker.py\",\n> > line 420, in _update\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup self.pci_tracker.save(context)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/pci/pci_manager.py\", line\n> > 126, in save\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup dev.save(context)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/objects/base.py\", line 134,\n> > in wrapper\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup ctxt, self, fn.__name__, args,\n> > kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/conductor/rpcapi.py\", line\n> > 497, in object_action\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup objmethod=objmethod, args=args,\n> > kwargs=kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/rpcclient.py\", line 85, in\n> > call\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return\n> > self._invoke(self.proxy.call, ctxt, method, **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/rpcclient.py\", line 63, in\n> > _invoke\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return cast_or_call(ctxt, msg,\n> > **self.kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/proxy.py\",\n> > line 126, in call\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup result = rpc.call(context,\n> > real_topic, msg, timeout)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/__init__.py\",\n> > line 139, in call\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return _get_impl().call(CONF,\n> > context, topic, msg, timeout)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py\",\n> > line 794, in call\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup rpc_amqp.get_connection_pool(conf,\n> > Connection))\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> > line 574, in call\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup rv = list(rv)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> > line 539, in __iter__\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup raise result\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup TypeError: expected string or\n> > buffer\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup Traceback (most recent call last):\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py\",\n> > line 461, in _process_data\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup **args)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py\",\n> > line 172, in dispatch\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup result = getattr(proxyobj,\n> > method)(ctxt, **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/conductor/manager.py\", line\n> > 567, in object_action\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup result = getattr(objinst,\n> > objmethod)(context, *args, **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/objects/base.py\", line 141,\n> > in wrapper\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return fn(self, ctxt, *args,\n> > **kwargs)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\", line\n> > 243, in save\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup self._from_db_object(context,\n> > self, db_pci)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/objects/pci_device.py\", line\n> > 150, in _from_db_object\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup pci_device.extra_info =\n> > jsonutils.loads(extra_info)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib/python2.6/site-packages/nova/openstack/common/jsonutils.py\",\n> > line 158, in loads\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return json.loads(s)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib64/python2.6/json/__init__.py\", line 307, in loads\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup return _default_decoder.decode(s)\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup File\n> > \"/usr/lib64/python2.6/json/decoder.py\", line 319, in decode\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup obj, end = self.raw_decode(s,\n> > idx=_w(s, 0).end())\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup\n> > 2013-09-10 13:56:35.366 16736 TRACE\n> > nova.openstack.common.threadgroup TypeError: expected string or\n> > buffer\n> \n> Try this:\n> \n> diff --git a/nova/objects/pci_device.py b/nova/objects/pci_device.py\n> index a83b8f3..d0a628a 100644\n> --- a/nova/objects/pci_device.py\n> +++ b/nova/objects/pci_device.py\n> @@ -145,7 +145,7 @@ class PciDevice(base.NovaPersistentObject,\n> base.NovaObject):\n> if key != \'extra_info\':\n> pci_device[key] = db_dev[key]\n> else:\n> - extra_info = db_dev.get(\"extra_info\")\n> + extra_info = db_dev.get(\"extra_info\", \'{}\')\n> pci_device.extra_info = jsonutils.loads(extra_info)\n> pci_device._context = context\n> pci_device.obj_reset_changes()\n> \n> \n> --\n> Russell Bryant\n\n\n The same error happens.\nThe error message says \"TypeError: expected string or buffer\".\n\n David\n\n\n','<522F8C5B.8060303@redhat.com>',NULL),('<1510792655.2869906.1353064227279.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 06:10:27',-18000,'2012-11-16 11:10:27',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n> > We\'re talking specifically about values like disk I/O, CPU stats,\n> > etc. That data isn\'t generated as part of a notification, that\'s\n> > why we\'re having to poll for it.  What we\'re looking for is a\n> > solution that doesn\'t involve ceilometer importing part of nova\'s\n> > code *in an unsupported way*, as it does now. Some of the options\n> > presented involve new network-based communication between the\n> > existing ceilometer agent and the compute agent (RPC or REST, in\n> > different directions). None of those is really optimal, because we\n> > don\'t want to burden the compute agent with lots of calls asking\n> > for stats, either for metering or for monitoring. I think the\n> > option the ceilometer team is favoring at the moment is making the\n> > hypervisor library in nova a public API, so we can use it without\n> > fear of the API changing in unannounced ways. That would let us\n> > keep the hypervisor polling in a separate daemon from the\n> > hypervisor management.  There are details to work out about how\n> > such a separate library would be implemented.\n> > \n> \n> If we create a separate polling daemon in ceilometer, will it be\n> openstack-style? \n\nWell we already have a separate polling daemon, the ceilo compute\nagent.\n\nNot sure what you mean exactly by \"openstack-style\" in this context.\n\nCurrently we use the common periodic task support to trigger the\npolling cycle, but as you point out in another thread, this only\noffers weak timing guarantees so may need to be revisited (e.g. to\nallow high-priority time-sensitive tasks to be distinguished, as\nyou\'ve suggested).\n  \n\n> If yes, possibly that can be in nova/glance also?\n\nDo you mean, will ceilo poll glance in the same way as it does nova?\n\nCurrently glance is polled by ceilo for image existence via the public\nglance API, so this doesn\'t need to be co-located is the same way that\nthe ceilo compute agent needs to be deployed to each compute node.\nInstead the glance polling is handled from the ceilo central agent.\n\n\n> Not sure if any other requirement for such daemon.\n> Of course, it\'s different that the ceilometer agent is simple, and\n> can handle the daemon better, but I think that should apply to all,\n> if we make the daemon implementation robust?\n\nDo you mean, if we harden the common period task support these\nimprovements should be used across the board not just in ceilo?\n\nAbsolutely!\n\nCheers,\nEoghan\n\n\n','<DDCAE26804250545B9934A2056554AA0349EDB@SHSMSX101.ccr.corp.intel.com>',NULL),('<1511473899.5224547.1353422654161.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-20 09:44:14',-18000,'2012-11-20 14:44:14',NULL,'[openstack-dev] [ceilometer] alternative publication conduits','\n\n> I create a draft patch on https://review.openstack.org/#/c/16522/ .\n> \n> Can anyone (Julien, Doug, Eoghan, or anyone else) have a look on it?\n\nThanks for the patch! I\'ll take a look and get back with feedback on\ngerrit.\n\nCheers,\nEoghan\n\n> It still an initial patch, and if the method is acceptable for you,\n> I will continue the effort to make it a final one.\n> \n> Thanks\n> --jyh\n> \n> > -----Original Message-----\n> > From: Eoghan Glynn [mailto:eglynn at redhat.com]\n> > Sent: Friday, October 26, 2012 9:34 PM\n> > To: OpenStack Development Mailing List\n> > Subject: [openstack-dev] [ceilometer] alternative publication\n> > conduits\n> > \n> > \n> > Hi Ceilo Folks,\n> > \n> > TL;DR: just wanted to get feedback on some initial ideas on how\n> > we might accommodate different conduits of publication from the\n> > ceilo pollsters and notification handlers.\n> > \n> > Currently, we\'re obviously hard-coded to always publish via the\n> > message bus, so the idea is to support alternative/additional\n> > publication routes, according to the following outline:\n> > \n> >  - a ceilo notification handler or pollster can be associated\n> >    via config with a chain of zero or more Publishers\n> > \n> >  - each Publisher knows now to emit their representation over some\n> >    conduit (AMQP notification, CW PutMetricData call, statsd UDP\n> >    packet, or whatever)\n> > \n> >  - a ceilometer notification handler or pollster provides a\n> >    Transformer corresponding to each of its Publishers, which\n> >    knows how to transform domain-specific raw data into the\n> >    relevant representation\n> > \n> >  - the batching of transformer output is up to the Publisher\n> > \n> >  - each Publisher has an independent frequency, so not all\n> >    Publishers are called to publish every measurement\n> > \n> > So for example the compute.libvirt.DiskIOPollster would provide a\n> > transformer to map the raw disk stats reported by libvirt into\n> > DiskWriteOps, DiskWriteBytes, DiskReadOps & DiskReadBytes metric\n> > datapoints for CW, also indicating that this should be published\n> > very minute. This CWPublisher would handle batching these data\n> > as a single PutMetricData call.\n> > \n> > The DiskIOPollster would also provide a second Transformer to\n> > mediate between the raw stats format and the ceilo Counter\n> > representation for metering.  Additionally, this second Publisher\n> > could be configured with a longer period (as befits metering data\n> > likely to be consumed by a billing engine).\n> > \n> > Now the frequency aspect is a bit awkward. For notifications,\n> > the frequency of the \"exists\" style of usage audit is out of our\n> > hands, depending usually on the configuration of the emitter\n> > (e.g. the nova instance_usage_audit_period config). Whereas ceilo\n> > config direct controls only the frequency of polling. So one idea\n> > would be for a publisher\'s frequency only to impact on the periods\n> > under ceilo control - i.e. we\'d accept and publish notifications\n> > whenever we get them, whereas the polling cycle would be determined\n> > by the greatest common divisor of all the configured publisher\n> > periods for each set of related pollsters (the config would\n> > probably\n> > have to be restricted so to ensure a sane GCD).\n> > \n> > Also, I\'m assuming that an alternative publication route would\n> > generally be used when the target endpoint is not the ceilo\n> > collector\n> > & metering store ... i.e. non-standard publisher would most often\n> > be used in order to hive off the data to an alternative endpoint\n> > or store, such as a CW metrics store, or say to be dumped as RRD\n> > files to be consumed by graphite.\n> > \n> > Thoughts?\n> > \n> > Cheers,\n> > Eoghan\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<DDCAE26804250545B9934A2056554AA03506A5@SHSMSX101.ccr.corp.intel.com>',NULL),('<1511490774.881855.1386081055801.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 09:30:55',-18000,'2013-12-03 14:30:55',NULL,'[openstack-dev] {TripleO] UI Wireframes - close to\n implementation	start','> Hey folks,\n\n> I opened 2 issues on UX discussion forum with TripleO UI topics:\n\n> Resource Management:\n> http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/\n> - this section was already reviewed before, there is not much surprises, just\n> smaller updates\n> - we are about to implement this area\n\n> http://ask-openstackux.rhcloud.com/question/96/tripleo-ui-deployment-management/\n> - these are completely new views and they need a lot of attention so that in\n> time we don\'t change direction drastically\n> - any feedback here is welcome\n\n> We need to get into implementation ASAP. It doesn\'t mean that we have\n> everything perfect from the very beginning, but that we have direction and\n> we move forward by enhancements.\n\n> Therefor implementation of above mentioned areas should start very soon.\n\n> If all possible, I will try to record walkthrough with further explanations.\n> If you have any questions or feedback, please follow the threads on\n> ask-openstackux.\n\n> Thanks\n> -- Jarda\n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\nThese wireframes look really good! However, would it be possible to get the list of requirements driving them? For example, something on the level of: \n\n1) removal of resource classes and racks \n2) what happens behind the scenes when deployment occurs \n3) the purpose of \"compute class\" \n4) etc \n\nI think it\'d be easier to understand the \"big picture\" that way. Thanks! \n\nMainn \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/ee33f437/attachment.html>\n\n','<529DA3A7.1090907@redhat.com>',NULL),('<1512BAC4-8E3F-422C-84BE-1F16D15E141E@pd.infn.it>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-23 22:17:33',7200,'2014-04-23 20:17:33',NULL,'[Openstack-operators] Problem after VM\'s Hard Reboot','It seems that this \n\nhttps://bugs.launchpad.net/nova/+bug/1240849\n\ncan be the cause of my problem. And it is fixed on IceHouse.\nDoes someone confirm ?\n\n	A.\n\nOn 23 Apr 2014, at 16:44, Alvise Dorigo <alvise.dorigo at pd.infn.it> wrote:\n\n> Hi,\n> I\'ve an Havana installation with distributed services (controller node,\n> network node running only the neutron agents, compute node).\n> The Network node is redundant with dhcp agent in HA mode active/active\n> (2 instances running on 2 different network nodes).\n> \n> I noticed that, often, after an Hard Reboot the VM is unable to talk to\n> the dhcp agent to obtain its private IP. I observed that when this\n> happens, the tap of the VM doesn\'t have the VLAN tag it had before, during the normal functioning.\n> \n> This problem doesn\'t occur if a Soft Reboot is performed (e.g. a\n> \"reboot\" issued from the console).\n> \n> Is this known or experienced by someone else ?\n> \n> thanks,\n> \n>     Alvise\n> \n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140423/5485c12f/attachment.html>\n\n','<5357D1BB.4010606@pd.infn.it>',NULL),('<1513430835.37.1383372209839.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:03:29',0,'2013-11-02 06:03:29',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-horizon-docs-stable-grizzly #48','See <https://jenkins01.openstack.org/job/periodic-horizon-docs-stable-grizzly/48/>\n\n\n\n',NULL,NULL),('<1513728626.60.1375769392812.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:09:52',0,'2013-08-06 06:09:52',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #121','See <https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/121/changes>\n\nChanges:\n\n[shardy] Only call FnGetAtt if resource is in acceptable state.\n\n[shardy] Define behaviour for properties with None values.\n\n[shardy] Fix SecurityGroups for AWS::AutoScaling::LaunchConfiguration\n\n------------------------------------------\n[...truncated 643 lines...]\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 176, in test_FnGetAtt\n    self.assertEqual(s2.CREATE_COMPLETE, s2.state)\nAssertionError: \'CREATE_COMPLETE\' != \'CREATE_FAILED\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\" = \'%s != %s\' % (safe_repr(\'CREATE_COMPLETE\'), safe_repr(\'CREATE_FAILED\'))\n    \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\" = self._formatMessage(\"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\", \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\")\n>>  raise self.failureException(\"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: ERROR: create Instance \"S2\"\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/engine/resource.py\",> line 320, in create\n    self.handle_create()\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 765, in __call__\n    return mock_method(*params, **named_params)\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1002, in __call__\n    expected_method = self._VerifyMethodCall()\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1049, in _VerifyMethodCall\n    expected = self._PopNextMethod()\n  File \"<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1035, in _PopNextMethod\n    raise UnexpectedMethodCallError(self, None)\nUnexpectedMethodCallError: Unexpected method call handle_create.__call__() -> None\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.223s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.9\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.121\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.12\nlxml==2.3.5\nmox==0.5.3\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npyflakes==0.7.3\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-memcached==1.53\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.DQxkiktKLr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise13/121\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1514928643.5.1374132349647.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-18 07:25:49',0,'2013-07-18 07:25:49',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stress #10','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stress/10/>\n\n\n\n','<1235670994.24.1374041418374.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1514952527.197.1364623591348.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-30 06:06:31',0,'2013-03-30 06:06:31',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #180','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/180/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric7 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/>\nCheckout:periodic-horizon-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/> - hudson.remoting.Channel at 20cb3eea:oneiric7\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.2\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson1913344403898905912.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.yrdwhoyGrV\n+ TMPDIR=/tmp/tmp.yrdwhoyGrV\n+ trap \'rm -rf /tmp/tmp.yrdwhoyGrV\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy26 runtests: commands[0]\nRunning Horizon application tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py>:1235: DeprecationWarning: The syntax for the url template tag is changing. Load the `url` tag from the `future` tag library to start using the new behavior.\n  category=DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/contrib/auth/__init__.py>:26: DeprecationWarning: Authentication backends without a `supports_inactive_user` attribute are deprecated. Please define it in <class \'openstack_auth.backend.KeystoneBackend\'>.\n  DeprecationWarning)\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.56 secs:\n    0.59    UserSettingsTest.test_timezone_offset_is_displayed\n    0.57    ImagesViewTest.test_images_list_get_pagination\n    0.55    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.51    SwiftTests.test_upload\n    0.33    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 19.358s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==1.1.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.12.0\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.yrdwhoyGrV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/180\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/180/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/180/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<174286041.184.1364537323994.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1515139550.35.1381040916832.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-06 06:28:36',0,'2013-10-06 06:28:36',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #31','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/31/>\n\n------------------------------------------\n[...truncated 21482 lines...]\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nInitialized empty Git repository in /tmp/tempest-unitHRUDiX/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitK6l8sn/.git/\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate] ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           192.632\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   177.987\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   70.296\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]         37.214\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_specify_keypair[gate]                                35.299\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         27.022\ntempest.api.compute.images.test_images.ImagesTestXML.test_create_image_from_stopped_server[gate,negative]                 26.935\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]     26.463\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]           25.319\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   24.726\n\n----------------------------------------------------------------------\nRan 1191 tests in 1171.066s\n\nOK (skipped=42)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-545573-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-545573.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-545573/31/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<982556279.23.1380695864356.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1515245.sU3eREtjOs@michael-hp-z400-workstation>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-01 16:47:59',3600,'2014-07-01 15:47:59',NULL,'[openstack-dev] [TripleO] Use MariaDB by default on Fedora','I propose making mysql an abstract element and user must choose either percona \nor mariadb-rpm element.CI must be setup correctly\n\nMichael\n\nOn Monday 30 June 2014 12:02:09 Clint Byrum wrote:\n> Excerpts from Michael Kerrin\'s message of 2014-06-30 02:16:07 -0700:\n> > I am trying to finish off https://review.openstack.org/#/c/90134 - percona\n> > xtradb cluster for debian based system.\n> > \n> > I have read into this thread that I can error out on Redhat systems when\n> > trying to install percona and tell them to use mariadb instead, percona\n> > isn\'t support here. Is this correct?\n> \n> Probably. But if CI for Fedora breaks as a result you\'ll need a solution\n> first.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/4d10fa5d/attachment.html>\n\n','<1404154901-sup-4723@fewbar.com>',NULL),('<1515698148.6.1377238574966.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-23 06:16:14',0,'2013-08-23 06:16:14',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #10','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/10/>\n\n\n\n','<1567655370.1.1377167490098.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1515786181.44.1374732147355.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-25 06:02:27',0,'2013-07-25 06:02:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #297','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/297/>\n\n------------------------------------------\n[...truncated 56 lines...]\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/297/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python26-stable-folsom-297\', \'SSH_CLIENT\': \'198.101.231.203 36730 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/bin:/bin:/usr/bin\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python26-stable-folsom\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NLSPATH\': \'/usr/dt/lib/nls/msg/%L/%N.cat\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'centos6 centos6-6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.Pb2WsS8QJd\', \'DEBEMAIL\': \'hudson at openstack.org\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'BUILD_ID\': \'2013-07-25_06-00-25\', \'BUILD_NUMBER\': \'297\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'17712d2f-1b7e-4864-8b42-15249681a1ad\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'centos6-6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#297\', \'XFILESEARCHPATH\': \'/usr/dt/app-defaults/%L/Dt\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 36730 166.78.7.162 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-9gL46T/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-9gL46T/d2to1-0.2.10/egg-dist-tmp-u6NfDN\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-ZOIzK9/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-ZOIzK9/setuptools-git-1.0/egg-dist-tmp-ilw4tX\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-keystoneclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-oa1c_L/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-oa1c_L/d2to1-0.2.10/egg-dist-tmp-YMgU1L\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-UDUnCZ/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-UDUnCZ/setuptools-git-1.0/egg-dist-tmp-Ce_s80\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-quantumclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-NJlOdE/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-NJlOdE/d2to1-0.2.10/egg-dist-tmp-yxzfAl\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.Pb2WsS8QJd/easy_install-X5Bgma/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.Pb2WsS8QJd/easy_install-X5Bgma/setuptools-git-1.0/egg-dist-tmp-jF3vLn\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Pb2WsS8QJd\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/297\n[SCP] Copying console log.\n\n\n','<1173825287.37.1374645739501.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1516994945.9459474.1354211849498.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-29 12:57:29',-18000,'2012-11-29 17:57:29',NULL,'[openstack-dev] [ceilometer][synaps] Ceilometer and Synaps joining\n	forces','\n\nHi Folks,\n\nWe\'ve been thinking that the Synaps and Ceilometer projects\nshould join forces, given that Ceilometer is concerned with all\nthings measurement-related for OpenStack, with a particular focus\non the user-oriented aspects (i.e. metering and monitoring the\nuser-view of cloud resources) for the grizzly release cycle.\n\nThe Synaps project[1] has produced a CloudWatch-style implementation\nfor OpenStack, with a Cassandra-based metric store, designed from\nthe ground up to be highly scalable.\n\nIn Ceilometer we\'ve been working recently on a multi-publish\nblueprint[2], which will provide the initial integration point for\nmeasurements taken by the Ceilometer compute agent to be published\nvia the CloudWatch public API.\n\nSo the missions of the two projects dovetail nicely.\n\nThe Heat project also has a rudimentary CloudWatch implementation[3],\nbut the main contributor to that would be happy to re-focus their\nefforts on a more general-purpose solution.\n\nLet\'s have a detailed discussion about the technicalities of managing\nthe two codebases, issue tracking, task prioritization etc.\n\nBut for now, I\'d like to welcome the Synaps contributors into the fold :)\n\nCheers,\nEoghan\n\n[1] https://launchpad.net/synaps\n[2] https://blueprints.launchpad.net/ceilometer/+spec/multi-publisher\n[3] https://github.com/heat-api/heat/wiki/Roadmap-Feature:-cloudwatch-api\n\n\n','<604707549.9455875.1354211597772.JavaMail.root@redhat.com>',NULL),('<1517147686.131964.1418804134592.JavaMail.yahoo@jws106138.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-17 08:15:34',0,'2014-12-17 08:15:34',NULL,'[openstack-dev] [Neutron][Nova][DHCP] Use case of enable_dhcp\n option when creating a network','  Hello,I have a question regarding the enable_dhcp option when creating a network. \n\nWhen a VM is attached to? a network where enable_dhcp is False, I understand that the DHCP namespace is not created for the network and the VM does not get any IP address after it boots up and sends a DHCP Discover.But, I also see that the Neutron port is filled with the fixed IP value from the network pool even though there\'s no DHCP associated with the subnet.?So, for such VM\'s, does one need to statically configure the IP address with whatever Neutron has allocated from the pool?\nWhat exactly is the use case of the above??\nI do understand that for providing public network access to VM\'s, an external network is generally created with enable-dhcp option set to False. Is it only for this purpose?\nI was thinking of a case of external/provider DHCP servers from where VM\'s can get their IP addresses and when one does not want to use L3 agent/DVR. In such cases, one may want to disable DHCP when creating networks. ?Isn\'t this a use-case?\nAppreciate any response or corrections with my above understanding.\n\nThanks,Paddu? \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141217/3ddcf1d7/attachment.html>\n\n',NULL,NULL),('<1517309843.16492.1396946747794.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 10:45:47',7200,'2014-04-08 08:45:47',NULL,'[openstack-dev] Issues when running unit tests in OpenStack','Oh, I already got feedback from colleagues :-) Thanks.\n\n> (1) First problem: if a Python module cannot be loaded, my terminal is\n> flooded with a binary stream which looks like:\n> \n> ...\n> tCase.test_deprecated_without_replacement\\xd7\\xe1\\x06\\xa1\\xb3)\\x01 at l@atests.unit.test_versionutils.DeprecatedTestCa\n> ...\n\nThis issue was reported:\nhttps://bugs.launchpad.net/testrepository/+bug/1271133\n\nIt looks to depend on 4 changes in 4 projects:\n\n* subunit: https://code.launchpad.net/~alexei-kornienko/subunit/bug-1271133\n* testrepository: https://code.launchpad.net/~alexei-kornienko/testrepository/bug-1271133\n* testtools: https://github.com/testing-cabal/testtools/pull/77\n* Python unittest (for testtools): http://bugs.python.org/issue19746\n\n> (2) When a test fails, it\'s hard to find the command to rerun a single\n> failing test.\n> \n> ...\n> I try sometimes to activate the virtualenv and then type:\n> \n>    testr run tests.unit.test_timeutils.TestIso8601Time.test_west_normalize\n\nIn the virtual environment, the following command works and is fast:\n\n   python -m testtools.run tests.test_swiftclient.TestPutObject.test_unicode_ok\n\nVictor\n\n\n','<950040688.14462.1396944827038.JavaMail.zimbra@enovance.com>',NULL),('<1517488040.161.1366009158989.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-04-15 06:59:18',0,'2013-04-15 06:59:18',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #97','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/97/>\n\n------------------------------------------\n[...truncated 19145 lines...]\n2013-04-15 06:30:12,040 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:12,040 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:12,108 Response Status: 200\n2013-04-15 06:30:12,108 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:12 GMT\', \'x-compute-request-id\': \'req-40e0d2b3-7273-46b0-b930-ac47c9f485d3\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:12,108 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:15,112 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:15,112 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:15,184 Response Status: 200\n2013-04-15 06:30:15,184 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:15 GMT\', \'x-compute-request-id\': \'req-c64cb9c0-c1eb-43a0-a6b7-ed4188101a34\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:15,184 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:18,186 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:18,186 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:18,244 Response Status: 200\n2013-04-15 06:30:18,244 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:18 GMT\', \'x-compute-request-id\': \'req-90e0a512-7829-4f62-bdf7-65ae7d4fabde\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:18,244 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:21,248 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:21,248 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:21,324 Response Status: 200\n2013-04-15 06:30:21,324 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:21 GMT\', \'x-compute-request-id\': \'req-ebf0097f-f850-4f15-8374-2a513947dfbb\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:21,324 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:24,328 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:24,328 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:24,385 Response Status: 200\n2013-04-15 06:30:24,385 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:24 GMT\', \'x-compute-request-id\': \'req-44de4c5a-ffca-4422-93c2-588f66905470\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:24,385 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:27,392 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:27,392 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:27,454 Response Status: 200\n2013-04-15 06:30:27,454 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:27 GMT\', \'x-compute-request-id\': \'req-4375d760-e6b8-4b0d-8a2c-3fa1e275d680\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:27,454 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:30,458 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:30,458 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:30,636 Response Status: 200\n2013-04-15 06:30:30,636 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:30 GMT\', \'x-compute-request-id\': \'req-089d90d6-9257-419e-baf8-06f95deac6ae\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:30,636 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:33,640 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:33,640 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:33,696 Response Status: 200\n2013-04-15 06:30:33,696 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:33 GMT\', \'x-compute-request-id\': \'req-05141b52-4e03-4f61-a4b5-0e37382c4466\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:33,696 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:36,700 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:36,700 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:36,765 Response Status: 200\n2013-04-15 06:30:36,765 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:36 GMT\', \'x-compute-request-id\': \'req-405452f1-6d32-4e3e-88e3-135f708cb64f\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:36,765 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:39,768 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:39,768 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:39,824 Response Status: 200\n2013-04-15 06:30:39,824 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:39 GMT\', \'x-compute-request-id\': \'req-ab7dffb5-5a0a-4b36-92a0-f9ae573d0220\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:39,824 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:42,832 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:42,832 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:42,892 Response Status: 200\n2013-04-15 06:30:42,892 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:42 GMT\', \'x-compute-request-id\': \'req-40f90fc4-e901-4810-86e8-0d32a136e308\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:42,892 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:45,892 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:45,892 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:45,964 Response Status: 200\n2013-04-15 06:30:45,964 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:45 GMT\', \'x-compute-request-id\': \'req-d3e6b33c-33d2-40b2-8b31-d26d79ff50d5\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:45,964 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:48,968 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:48,968 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:49,052 Response Status: 200\n2013-04-15 06:30:49,052 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:49 GMT\', \'x-compute-request-id\': \'req-b6b36fd6-ea5a-4f49-a6b4-46e57172682f\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:49,052 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:52,056 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:52,056 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:52,128 Response Status: 200\n2013-04-15 06:30:52,128 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:52 GMT\', \'x-compute-request-id\': \'req-7ef7f532-93b9-4289-b6e7-28bb11457997\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:52,128 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:55,130 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:55,132 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:55,196 Response Status: 200\n2013-04-15 06:30:55,196 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:55 GMT\', \'x-compute-request-id\': \'req-8fb44745-9a6f-42c5-845d-7387ba7292da\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:55,196 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:30:58,200 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:30:58,200 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:30:58,256 Response Status: 200\n2013-04-15 06:30:58,256 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:30:58 GMT\', \'x-compute-request-id\': \'req-69c4e742-f278-4e3b-8cac-ad157b32a7be\', \'content-type\': \'application/json\'}\n2013-04-15 06:30:58,256 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:01,260 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:01,260 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:01,316 Response Status: 200\n2013-04-15 06:31:01,316 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:01 GMT\', \'x-compute-request-id\': \'req-f69a44df-e679-4712-aae4-22d70388af74\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:01,316 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:04,320 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:04,320 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:04,392 Response Status: 200\n2013-04-15 06:31:04,392 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:04 GMT\', \'x-compute-request-id\': \'req-aa6f3d0c-8a17-41be-8406-d652f96a3a31\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:04,392 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:07,396 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:07,396 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:07,452 Response Status: 200\n2013-04-15 06:31:07,452 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:07 GMT\', \'x-compute-request-id\': \'req-5e6b7b3e-280f-484f-bdc2-106e1678e5b8\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:07,452 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:10,457 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:10,457 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:10,516 Response Status: 200\n2013-04-15 06:31:10,516 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:10 GMT\', \'x-compute-request-id\': \'req-6accaaa9-56d4-48b6-a49d-a9f3fd0ac203\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:10,516 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:13,520 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:13,520 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:13,584 Response Status: 200\n2013-04-15 06:31:13,584 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:13 GMT\', \'x-compute-request-id\': \'req-b572f2de-de01-4398-9f24-1b6c7187b1ad\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:13,584 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:16,588 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:16,588 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:16,648 Response Status: 200\n2013-04-15 06:31:16,648 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:16 GMT\', \'x-compute-request-id\': \'req-1503a388-7a22-4985-92de-a65749a6b3dc\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:16,648 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:19,653 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:19,653 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:19,708 Response Status: 200\n2013-04-15 06:31:19,708 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:19 GMT\', \'x-compute-request-id\': \'req-d6dff878-0aab-494e-b204-a4c3b035a590\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:19,708 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:22,712 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:22,712 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:22,776 Response Status: 200\n2013-04-15 06:31:22,776 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:22 GMT\', \'x-compute-request-id\': \'req-807abda6-303f-4d24-87eb-52c03952ff07\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:22,776 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:25,780 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:25,780 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:25,836 Response Status: 200\n2013-04-15 06:31:25,836 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:25 GMT\', \'x-compute-request-id\': \'req-0302abec-fb64-4a80-98a6-432401e34842\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:25,836 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:28,840 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:28,840 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:28,900 Response Status: 200\n2013-04-15 06:31:28,900 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:28 GMT\', \'x-compute-request-id\': \'req-f43b307b-883b-4a81-9566-1ab216c24edf\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:28,900 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:31,900 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:31,900 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:31,960 Response Status: 200\n2013-04-15 06:31:31,960 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:31 GMT\', \'x-compute-request-id\': \'req-4e2bd7d6-ad1d-44ca-80e1-be52a5d5a52f\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:31,960 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:34,964 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:34,964 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:35,024 Response Status: 200\n2013-04-15 06:31:35,028 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:35 GMT\', \'x-compute-request-id\': \'req-e8e3fbbe-34f5-4345-9ebf-2f80dfcbe6cb\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:35,028 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:38,032 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:38,032 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:38,092 Response Status: 200\n2013-04-15 06:31:38,092 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:38 GMT\', \'x-compute-request-id\': \'req-5dc8329e-43d5-4d70-83b5-cd2be58e8771\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:38,092 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:41,096 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:41,096 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:41,156 Response Status: 200\n2013-04-15 06:31:41,156 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:41 GMT\', \'x-compute-request-id\': \'req-1a5964fa-bc48-4c30-8790-ad3b2de8e7ff\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:41,156 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:44,160 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:44,160 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:44,220 Response Status: 200\n2013-04-15 06:31:44,220 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:44 GMT\', \'x-compute-request-id\': \'req-89c71df9-893a-4cbf-8c95-5706dad1eeda\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:44,220 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/images/8c5d44fe-57a5-445e-a789-1c00ab2f7a31\", \"rel\": \"bookmark\"}]}, \"OS-EXT-STS:task_state\": \"rebooting_hard\", \"OS-EXT-STS:vm_state\": \"active\", \"flavor\": {\"id\": \"42\", \"links\": [{\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/flavors/42\", \"rel\": \"bookmark\"}]}, \"id\": \"7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"security_groups\": [{\"name\": \"default\"}], \"OS-EXT-AZ:availability_zone\": \"nova\", \"user_id\": \"46986726fe2f40a891317615c5099839\", \"name\": \"ServerActionsTestJSON-instance2112005475\", \"created\": \"2013-04-15T06:25:03Z\", \"tenant_id\": \"c59c5dda41da412d8f2459a797cce2aa\", \"OS-DCF:diskConfig\": \"MANUAL\", \"accessIPv4\": \"\", \"accessIPv6\": \"\", \"OS-EXT-STS:power_state\": 1, \"config_drive\": \"\", \"metadata\": {}}}\n2013-04-15 06:31:47,224 Request: GET http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\n2013-04-15 06:31:47,224 Request Headers: {\'X-Auth-Token\': \'<Token omitted>\'}\n2013-04-15 06:31:47,284 Response Status: 200\n2013-04-15 06:31:47,284 Response Headers: {\'content-length\': \'1425\', \'content-location\': u\'http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\', \'date\': \'Mon, 15 Apr 2013 06:31:47 GMT\', \'x-compute-request-id\': \'req-08ba3f4b-531a-40c1-84ad-0b82bf3c7b4c\', \'content-type\': \'application/json\'}\n2013-04-15 06:31:47,284 Response Body: {\"server\": {\"status\": \"HARD_REBOOT\", \"updated\": \"2013-04-15T06:25:26Z\", \"hostId\": \"37fe6cdb6c7187e257cd577602e30969fb05c88a86fab0fac529ad99\", \"addresses\": {\"private\": [{\"OS-EXT-IPS-MAC:mac_addr\": \"fa:16:3e:83:84:b2\", \"version\": 4, \"addr\": \"10.1.0.37\", \"OS-EXT-IPS:type\": \"fixed\"}]}, \"links\": [{\"href\": \"http://127.0.0.1:8774/v2/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"self\"}, {\"href\": \"http://127.0.0.1:8774/c59c5dda41da412d8f2459a797cce2aa/servers/7dc1cefb-738d-43e6-ac91-73f6616bd931\", \"rel\": \"bookmark\"}], \"key_name\": null, \"image\": {\"id\": \"8c5d44fe-57a5-445e-a789-1c00ab2f',NULL,NULL),('<1517596682.6109898.1390870781749.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-27 19:59:41',-18000,'2014-01-28 00:59:41',NULL,'[openstack-dev] [Keystone] bp proposal: quotas on users and\n projects per domain','\n\n----- Original Message -----\n> From: \"Florent Flament\" <florent.flament-ext at cloudwatt.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Friday, 24 January, 2014 8:07:28 AM\n> Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on users and projects per domain\n> \n> I understand that not everyone may be interested in such feature.\n> \n> On the other hand, some (maybe shallow) Openstack users may be\n> interested in setting quotas on users or projects. Also, this feature\n> wouldn\'t do any harm to the other users who wouldn\'t use it.\n> \n> If some contributors are willing to spend some time in adding this\n> feature to Openstack, is there any reason not to accept it ?\n\nI have in general no problem with users/projects/domains/etc being quota-ed\nfor a business decision (and i don\'t work for a provider) but as part of a more\nglobal initiative that all resource types in OpenStack can be quotaed and this\nwould be managed by some other service (This i think would be a difficult\nservice to write). \n\nI don\'t see the point in implementing this directly as a keystone feature.\nAs Dolph mentioned these are not resource heavy concepts that we have a practical \nneed to limit. In most situations i imagine service providers who want this\nhave means to achieve it via the backend they use store to. \n\nNote that the idea of storing quota data in keystone has come up before\nand has generally never gained much traction. \n\nJamie\n\n> On Thu, 2014-01-23 at 14:55 -0600, Dolph Mathews wrote:\n> > \n> > On Thu, Jan 23, 2014 at 9:59 AM, Florent Flament\n> > <florent.flament-ext at cloudwatt.com> wrote:\n> >         Hi,\n> >         \n> >         \n> >         Although it is true that projects and users don\'t consume a\n> >         lot of resources, I think that there may be cases where\n> >         setting quotas (possibly large) may be useful.\n> >         \n> >         \n> >         \n> >         For instance, a cloud provider may wish to prevent domain\n> >         administrators to mistakingly create an infinite number of\n> >         users and/or projects, by calling APIs in a bugging loop.\n> >         \n> > \n> > \n> > That sounds like it would be better solved by API rate limiting, not\n> > quotas.\n> >  \n> >         \n> >         \n> >         \n> >         Moreover, if quotas can be disabled, I don\'t see any reason\n> >         not to allow cloud operators to set quotas on users and/or\n> >         projects if they wishes to do so for whatever marketing reason\n> >         (e.g. charging more to allow more users or projects).\n> >         \n> > \n> > \n> > That\'s the shallow business decision I was alluding to, which I don\'t\n> > think we have any reason to support in-tree.\n> >  \n> >         \n> >         \n> >         \n> >         Regards,\n> >         \n> >         Florent Flament\n> >         \n> >         \n> >         \n> >         \n> >         \n> >         ______________________________________________________________\n> >         From: \"Dolph Mathews\" <dolph.mathews at gmail.com>\n> >         To: \"OpenStack Development Mailing List (not for usage\n> >         questions)\" <openstack-dev at lists.openstack.org>\n> >         Sent: Thursday, January 23, 2014 3:09:51 PM\n> >         Subject: Re: [openstack-dev] [Keystone] bp proposal: quotas on\n> >         users and projects per domain\n> >         \n> >         \n> >         \n> >         ... why? It strikes me as a rather shallow business decision\n> >         to limit the number of users or projects in a system, as\n> >         neither are actually cost-consuming resources.\n> >         \n> >         \n> >         On Thu, Jan 23, 2014 at 6:43 AM, Matthieu Huin\n> >         <matthieu.huin at enovance.com> wrote:\n> >                 Hello,\n> >                 \n> >                 I\'d be interested in opinions and feedback on the\n> >                 following blueprint:\n> >                 https://blueprints.launchpad.net/keystone/+spec/tenants-users-quotas\n> >                 \n> >                 The idea is to add a mechanism preventing the creation\n> >                 of users or projects once a quota per domain is met. I\n> >                 believe this could be interesting for cloud providers\n> >                 who delegate administrative rights under domains to\n> >                 their customers.\n> >                 \n> >                 I\'d like to hear the community\'s thoughts on this,\n> >                 especially in terms of viability.\n> >                 \n> >                 Many thanks,\n> >                 \n> >                 Matthieu Huin\n> >                 \n> >                 mhu at enovance.com\n> >                 http://www.enovance.com\n> >                 eNovance SaS - 10 rue de la Victoire 75009 Paris -\n> >                 France\n> >                 \n> >                 \n> >                 _______________________________________________\n> >                 OpenStack-dev mailing list\n> >                 OpenStack-dev at lists.openstack.org\n> >                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> >         \n> >         \n> >         \n> >         _______________________________________________\n> >         OpenStack-dev mailing list\n> >         OpenStack-dev at lists.openstack.org\n> >         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >         \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1390514848.9398.0.camel@macnux.lan>',NULL),('<1517804765.26383741.1385127546178.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-22 08:39:06',-18000,'2013-11-22 13:39:06',NULL,'[Openstack] [Ceilometer] Alarms','\nHi Greg,\n\nThe alarming feature of ceilometer is intended to be user-oriented,\ni.e. focused on the user-view of cloud resources.\n\nIt is not intended to be infrastructure-oriented, i.e. focused on the\noperator-view of the underpinning datacenter fabric.\n\nSo if understand your question correctly, the answer I thing is no,\nwe are not addressing the ?general? cases you had in mind.\n\nCheers,\nEoghan\n\n----- Original Message -----\n> \n> \n> A general question about Alarms in Ceilometer ?\n> \n> \n> \n> Is the intent that Ceilometer is collecting, managing & distributing\n> ?general? OpenStack Alarms ?\n> \n> ? All of the documentation around Alarms in Ceilometer is about PM Threshold\n> Alarms;\n> i.e. Alarms triggered when a PM Counter crosses a specified threshold\n> \n> ? But there are other types of Alarms associated with an OpenStack Cloud\n> \n> o Alarms related to equipment failures,\n> \n> o Alarms related to network failures,\n> \n> o Etc.\n> \n> ? I have not seen any discussions suggesting that Ceilometer be used to\n> collect, manage & distribute ?general? OpenStack Alarms\n> \n> ? The architecture for managing Alarms would be very similar to that of PMs ?\n> \n> o The Ceilometer Architecture of Listener / Pollster Plugins and Publisher\n> Plugins applies well to general Alarm Management as well\n> \n> ? i.e. Listener / Pollster Plugins for listening or monitoring fault\n> conditions\n> \n> ? Publisher Plugins for generating the appropriate Alarms and sending to an\n> Alarm Collector\n> \n> ? An Alarm Collector with backend plugins for Northbound Management\n> Interfaces (SNMP, Netconf, etc.)\n> \n> \n> \n> Comments ?\n> \n> \n> \n> \n> \n> Greg.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n','<5058BED8BBDF5D4F898AD4366E6B36E01D3DAD00@ALA-MBA.corp.ad.wrs.com>',NULL),('<1518221470.64052167.1379690119980.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 08:15:19',-25200,'2013-09-20 15:15:19',NULL,'[openstack-dev] [Nova][vmware] VMwareAPI sub-team reviews\n update 2013-09-19','Hi Gary,\n\nOnly one of those is not already listed:  https://review.openstack.org/#/c/47503/ - disabling linked clone and cacheing of images\n\nI\'ll spend some cycles to see why it wasn\'t picked up by default. I\'ve bumped up it\'s vmwareapi-team priority as it seems pretty important.\n\n# Shawn Hartsock\n\n\n----- Original Message -----\n> From: \"Gary Kotton\" <gkotton at vmware.com>\n> To: \"Shawn Hartsock\" <hartsocks at vmware.com>, openstack-dev at lists.openstack.org\n> Sent: Friday, September 20, 2013 10:07:59 AM\n> Subject: Re: [openstack-dev][Nova][vmware] VMwareAPI sub-team reviews update 2013-09-19\n> \n> Hi,\n> The following two patches are really important (they are really simple and\n> have been around since beginning of August - they are rebased every couple\n> of days):-\n> - https://review.openstack.org/#/c/40298/ - Tempest snapshot fails\n> - https://review.openstack.org/#/c/43994/ - Disk copy fails\n> There are a number of patches that we need to base on top of these that\n> are high/critical (depending on how one looks at it). They are namely:\n> - https://review.openstack.org/#/c/46730/ - flavor root disk sizes are not\n> honored\n> - https://review.openstack.org/#/c/47503/ - disabling linked clone and\n> cacheing of images\n> - https://review.openstack.org/#/c/46231/ - VM resize\n> Thanks\n> Gary\n> \n> On 9/19/13 11:39 PM, \"Shawn Hartsock\" <hartsocks at vmware.com> wrote:\n> \n> >Greetings stackers!\n> >\n> >A quick mid-week update on the patches we\'re tracking for Havana-rc1.\n> >There was a bug in my vote counting code that I use to query votes. Some\n> >of the older patches were getting their votes counted wrong. Tracking the\n> >\"age\" of a submitted patchset (number of days since a patchset was\n> >posted) and the revision number helps spot these problems. I try to\n> >validate these reports by hand, but I do miss things on occasion. Let me\n> >know if I need to add or edit something.\n> >\n> >Ordered by priority:\n> >* High/Critical https://bugs.launchpad.net/bugs/1223709\n> >https://review.openstack.org/46027 readiness:ready for core\n> >* High/Critical https://bugs.launchpad.net/bugs/1216510\n> >https://review.openstack.org/43616 readiness:needs one more +2/approval\n> >* High/Critical https://bugs.launchpad.net/bugs/1226211\n> >https://review.openstack.org/46789 readiness:ready for core\n> >* High/Critical https://bugs.launchpad.net/bugs/1217541\n> >https://review.openstack.org/43621 readiness:needs review\n> >* High/High https://bugs.launchpad.net/bugs/1187853\n> >https://review.openstack.org/45349 readiness:ready for core\n> >* Medium/High https://bugs.launchpad.net/bugs/1190515\n> >https://review.openstack.org/33100 readiness:ready for core\n> >* High https://bugs.launchpad.net/bugs/1184807\n> >https://review.openstack.org/40298 readiness:ready for core\n> >* High https://bugs.launchpad.net/bugs/1214850\n> >https://review.openstack.org/43270 readiness:needs review\n> >* High https://bugs.launchpad.net/bugs/1226052\n> >https://review.openstack.org/46730 readiness:needs review\n> >* High https://bugs.launchpad.net/bugs/1226826\n> >https://review.openstack.org/47030 readiness:needs review\n> >* High https://bugs.launchpad.net/bugs/1225002\n> >https://review.openstack.org/41977 readiness:ready for core\n> >* High https://bugs.launchpad.net/bugs/1194018\n> >https://review.openstack.org/43641 readiness:ready for core\n> >* High https://bugs.launchpad.net/bugs/1171226\n> >https://review.openstack.org/43994 readiness:ready for core\n> >* Medium https://bugs.launchpad.net/bugs/1183654\n> >https://review.openstack.org/45203 readiness:needs revision\n> >* Medium https://bugs.launchpad.net/bugs/1223074\n> >https://review.openstack.org/45864 readiness:needs review\n> >* Medium https://bugs.launchpad.net/bugs/1199954\n> >https://review.openstack.org/46231 readiness:needs review\n> >* Medium https://bugs.launchpad.net/bugs/1222349\n> >https://review.openstack.org/45570 readiness:needs one more +2/approval\n> >* Medium https://bugs.launchpad.net/bugs/1216961\n> >https://review.openstack.org/43721 readiness:needs one more +2/approval\n> >* Medium https://bugs.launchpad.net/bugs/1215352\n> >https://review.openstack.org/43268 readiness:needs one more +2/approval\n> >* Medium https://bugs.launchpad.net/bugs/1197041\n> >https://review.openstack.org/43621 readiness:needs review\n> >* Medium https://bugs.launchpad.net/bugs/1222948\n> >https://review.openstack.org/46400 readiness:needs revision\n> >* Medium https://bugs.launchpad.net/bugs/1226238\n> >https://review.openstack.org/46824 readiness:needs review\n> >* Medium https://bugs.launchpad.net/bugs/1224479\n> >https://review.openstack.org/46277 readiness:ready for core\n> >* Medium https://bugs.launchpad.net/bugs/1207064\n> >https://review.openstack.org/42024 readiness:needs revision\n> >* Medium https://bugs.launchpad.net/bugs/1180044\n> >https://review.openstack.org/43270 readiness:needs review\n> >* Medium https://bugs.launchpad.net/bugs/1226425\n> >https://review.openstack.org/46895 readiness:needs revision\n> >* Low https://bugs.launchpad.net/bugs/1215958\n> >https://review.openstack.org/43665 readiness:needs review\n> >* Low https://bugs.launchpad.net/bugs/1226450\n> >https://review.openstack.org/46896 readiness:ready for core\n> >\n> >--------------------------------------------------------------------------\n> >------\n> >Ordered by fitness for review:\n> >\n> >== needs one more +2/approval ==\n> >* Medium https://bugs.launchpad.net/bugs/1222349 review:\n> >https://review.openstack.org/45570\n> >	title: \'VMware: datastore_regex is not honoured\'\n> >	votes: +2:1, +1:5, -1:0, -2:0  age: 11 days revision: 4\n> >* Medium https://bugs.launchpad.net/bugs/1216961 review:\n> >https://review.openstack.org/43721\n> >	title: \'VMware: exceptions for RetrievePropertiesEx incorrectly handled\'\n> >	votes: +2:1, +1:5, -1:0, -2:0  age: 1 days revision: 2\n> >* Medium https://bugs.launchpad.net/bugs/1215352 review:\n> >https://review.openstack.org/43268\n> >	title: \'VMware: unable to access VNC console if password is not\n> >configured\'\n> >	votes: +2:1, +1:3, -1:0, -2:0  age: 1 days revision: 12\n> >* High/Critical https://bugs.launchpad.net/bugs/1216510 review:\n> >https://review.openstack.org/43616\n> >	title: \'VMware: exception when accessing invalid nodename\'\n> >	votes: +2:1, +1:5, -1:0, -2:0  age: 3 days revision: 8\n> >\n> >== ready for core ==\n> >* High/Critical https://bugs.launchpad.net/bugs/1223709 review:\n> >https://review.openstack.org/46027\n> >	title: \'VMware: boot from volume exception\'\n> >	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 3\n> >* High https://bugs.launchpad.net/bugs/1184807 review:\n> >https://review.openstack.org/40298\n> >	title: \'Snapshot failure with VMwareVCDriver\'\n> >	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 18\n> >* High https://bugs.launchpad.net/bugs/1225002 review:\n> >https://review.openstack.org/41977\n> >	title: \'VMware: no VM connectivity when opaque network does not match\n> >bridge id\'\n> >	votes: +2:0, +1:5, -1:0, -2:0  age: 4 days revision: 5\n> >* Low https://bugs.launchpad.net/bugs/1226450 review:\n> >https://review.openstack.org/46896\n> >	title: \'no image cache tests for VMware Hyper\'\n> >	votes: +2:0, +1:4, -1:0, -2:0  age: 2 days revision: 1\n> >* Medium https://bugs.launchpad.net/bugs/1224479 review:\n> >https://review.openstack.org/46277\n> >	title: \'[vmware] InvalidURL nonnumeric port in read_write_ util with\n> >ipv6 host\'\n> >	votes: +2:0, +1:4, -1:0, -2:0  age: 7 days revision: 5\n> >* Medium/High https://bugs.launchpad.net/bugs/1190515 review:\n> >https://review.openstack.org/33100\n> >	title: \'Incorrect host stats reported by VMWare VCDriver\'\n> >	votes: +2:0, +1:7, -1:0, -2:0  age: 1 days revision: 19\n> >* High https://bugs.launchpad.net/bugs/1194018 review:\n> >https://review.openstack.org/43641\n> >	title: \'Can\'t use vmware distributed virtual switch with nova\'\n> >	votes: +2:0, +1:5, -1:0, -2:0  age: 25 days revision: 14\n> >* High/Critical https://bugs.launchpad.net/bugs/1226211 review:\n> >https://review.openstack.org/46789\n> >	title: \'VMware: some API\'s return only data on the first cluster and not\n> >the correct cluster\'\n> >	votes: +2:0, +1:7, -1:0, -2:0  age: 3 days revision: 1\n> >* High https://bugs.launchpad.net/bugs/1171226 review:\n> >https://review.openstack.org/43994\n> >	title: \'VMwareVCDriver: Sparse disk copy error on spawn\'\n> >	votes: +2:0, +1:5, -1:0, -2:0  age: 1 days revision: 18\n> >* High/High https://bugs.launchpad.net/bugs/1187853 review:\n> >https://review.openstack.org/45349\n> >	title: \'VMWAREAPI: Problem with starting Windows instances on ESXi 5.1\'\n> >	votes: +2:0, +1:6, -1:0, -2:0  age: 14 days revision: 9\n> >\n> >== needs review ==\n> >* Medium https://bugs.launchpad.net/bugs/1223074 review:\n> >https://review.openstack.org/45864\n> >	title: \'vsphere: Instance with volume attachment stuck with DELETING\n> >status\'\n> >	votes: +2:0, +1:4, -1:0, -2:0  age: 1 days revision: 4\n> >* Medium https://bugs.launchpad.net/bugs/1199954 review:\n> >https://review.openstack.org/46231\n> >	title: \'VCDriver: Failed to resize instance\'\n> >	votes: +2:0, +1:3, -1:0, -2:0  age: 2 days revision: 6\n> >* Low https://bugs.launchpad.net/bugs/1215958 review:\n> >https://review.openstack.org/43665\n> >	title: \'vim_util get_dynamic_property propSet need not be set - makes\n> >vmware driver hard to diagnose\'\n> >	votes: +2:0, +1:3, -1:0, -2:0  age: 11 days revision: 5\n> >* High https://bugs.launchpad.net/bugs/1214850 review:\n> >https://review.openstack.org/43270\n> >	title: \'vmware driver selection of vm_folder_ref does not account for\n> >datastore\'\n> >	votes: +2:0, +1:1, -1:0, -2:0  age: 28 days revision: 1\n> >* Medium https://bugs.launchpad.net/bugs/1197041 review:\n> >https://review.openstack.org/43621\n> >	title: \'nova compute crashes if you do not have any hosts in your\n> >cluster\'\n> >	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 5\n> >* High https://bugs.launchpad.net/bugs/1226052 review:\n> >https://review.openstack.org/46730\n> >	title: \'VMware: VM creation ignores the size of the flavor root disk\'\n> >	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 7\n> >* Medium https://bugs.launchpad.net/bugs/1226238 review:\n> >https://review.openstack.org/46824\n> >	title: \'VMware Driver reports SwitchNotFound when network already exists\'\n> >	votes: +2:0, +1:3, -1:0, -2:0  age: 3 days revision: 1\n> >* High https://bugs.launchpad.net/bugs/1226826 review:\n> >https://review.openstack.org/47030\n> >	title: \'VMwareVCDriver: detaching volume  fails with TypeError\'\n> >	votes: +2:0, +1:4, -1:0, -2:0  age: 1 days revision: 2\n> >* Medium https://bugs.launchpad.net/bugs/1180044 review:\n> >https://review.openstack.org/43270\n> >	title: \'nova failures when vCenter has multiple datacenters\'\n> >	votes: +2:0, +1:1, -1:0, -2:0  age: 28 days revision: 1\n> >* High/Critical https://bugs.launchpad.net/bugs/1217541 review:\n> >https://review.openstack.org/43621\n> >	title: \'vmwareapi drivers - most summary fields need not be set\'\n> >	votes: +2:0, +1:2, -1:0, -2:0  age: 0 days revision: 5\n> >\n> >== needs revision ==\n> >* Medium https://bugs.launchpad.net/bugs/1183654 review:\n> >https://review.openstack.org/45203\n> >	title: \'vmware code is using deprecated API that may not handle\n> >inventories over 100 items properly\'\n> >	votes: +2:0, +1:1, -1:1, -2:0  age: 14 days revision: 2\n> >* Medium https://bugs.launchpad.net/bugs/1222948 review:\n> >https://review.openstack.org/46400\n> >	title: \'VMware: booting multiple instances fails if image is not in\n> >cache\'\n> >	votes: +2:0, +1:1, -1:2, -2:0  age: 7 days revision: 6\n> >* Medium https://bugs.launchpad.net/bugs/1207064 review:\n> >https://review.openstack.org/42024\n> >	title: \'VMWare : Disabling linked clone does not cache images on the\n> >datastore\'\n> >	votes: +2:0, +1:1, -1:3, -2:0  age: 1 days revision: 11\n> >* Medium https://bugs.launchpad.net/bugs/1226425 review:\n> >https://review.openstack.org/46895\n> >	title: \'Problem specifying VMware network name in FlatNetworking\'\n> >	votes: +2:0, +1:2, -1:1, -2:0  age: 2 days revision: 3\n> >\n> ># Shawn Hartsock\n> \n\n\n','<CE623026.D651%gkotton@vmware.com>',NULL),('<1518367855.2963370.1392639705546.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-17 07:21:45',-18000,'2014-02-17 12:21:45',NULL,'[openstack-dev] [TripleO][Neutron] Urgent\n	python-neutronclient	release needed','I\'ve asked Mark McClain to tag a new release before *specifically* because we\'re going to hit the issue. The issue is in both master and stable/havana. Latest client releases were tagged by Mark, but since he seems to be busy these days, I think someone should step in and tag and release a new client ASAP, otherwise we leave stable/havana neutron broken for indefinite time. It\'s unacceptable.\n/Ihar\n\n----- Original Message -----\n> https://bugs.launchpad.net/neutron/+bug/1280941\n> \n> I haven\'t done a chapter-and-verse trace of what happened, but it\n> looks like a latent bug in the neutronclient lib was tickled by some\n> neutron change, fixed in neutronclient, and then neutron started using\n> the feature without bumping requirements.txt (as is needed for all\n> hard dependencies).\n> \n> As a result, TripleO clouds currently break, because we\'re meeting\n> requirements.txt, but requirements.txt is faulty.\n> \n> If someone with Neutron can-do-relase acls can do a release asap I\n> think that would be the best fix. Alternatively, we could hunt down\n> and backout whatever Neutron change tickles this (but a client release\n> seems best overall to me).\n> \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ1Rg_ovOnUV9d44RC5Z7+7CwAdgLc9GRGt1_wzcSw5wRQ@mail.gmail.com>',NULL),('<1519483188.58.1374819053452.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-26 06:10:53',0,'2013-07-26 06:10:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #298','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/298/>\n\n------------------------------------------\n[...truncated 2611 lines...]\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.131.g3f0312e to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.131.g3f0312e\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.131.g3f0312e\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.13.g5d9c6f8 to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.13.g5d9c6f8\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.19\nBest match: pbr 0.5.19\nProcessing pbr-0.5.19-py2.7.egg\nRemoving pbr 0.5.19 from easy-install.pth file\npbr 0.5.19 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.19-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.13.g5d9c6f8\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/rabbitmq/rabbit at devstack-1374817248-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/rabbitmq/rabbit at devstack-1374817248.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/298/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<203466195.49.1374732311423.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1519875676.29.1385620191218.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-28 06:29:50',0,'2013-11-28 06:29:50',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #5','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/5/>\n\n------------------------------------------\n[...truncated 20905 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           143.234\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   93.733\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]    68.175\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         48.233\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                     46.783\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]      42.526\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      40.179\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]         38.116\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   36.174\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]                           36.113\n\n----------------------------------------------------------------------\nRan 1340 tests in 1327.813s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-758681-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-758681.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-758681/5/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<253987598.27.1385447698409.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<151A821C5A7941DE8C4227D79EF8116B@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 16:03:59',-18000,'2012-11-05 21:03:59',NULL,'[openstack-dev] Asynchronous logging','\n> I\'m curious what led you to making this change in the first place. Did\n> you observe a problem or was it more theoretical?\n>  \n>  \n>  \n\n\nAsynchonous logging is a common pattern because logging is a relatively frequent and slow operation. It blocks a lot, which makes it a good candidate for being more friendly with eventlet.\n\nHere are the results of timing devstack\'s exercise.sh with logging_async=True versus False.\n\n-----------------------------\nSYNC logging\n-----------------------------\n\n\nsync#1real    4m16.933s\nuser    0m47.031s\nsys     0m13.229s\n\nsync#2:\nreal    3m4.645s\nuser    0m36.558s\nsys     0m10.129s\n\nsync#3:\nreal    3m9.707s\nuser    0m37.582s\nsys     0m10.965s\n\n-----------------------------\nASYNC logging\n-----------------------------\n\n\nasync#1\nreal    3m6.595s\n\nasync #2\nreal    2m29.525s\nuser    0m30.042s\nsys     0m10.037s\n\nasync #3\nreal    1m36.233s\nuser    0m26.914s\nsys     0m8.109s\n\nasync #4  (because the time went down on the third test, I ran a 4th?)\nreal    1m35.997s\nuser    0m27.046s\nsys     0m8.085s\n\n\n-----------------------------\n\nRegards,\nEric Windisch\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121105/6d4c7a84/attachment.html>\n\n','<50980A59.40300@redhat.com>',NULL),('<151AF842-FF63-4EFC-8B9C-6FD96B2A0782@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-02 15:17:09',-25200,'2013-07-02 22:17:09',NULL,'[openstack-dev] trove and heat integration status','Howdy,\n\none of the TC requests for integration of trove was to integrate heat. While this is a small task for single instance installations, when we get into clustering it seems a bit more painful. Id like to submit the following as a place to start the discussion for why we would/wouldnt integrate heat (now). This is, in NO WAY, to say we will not integrate heat. Its just a matter of timing and requirements for our \'soon to be\' cluster api. I am, however, targeting getting trove to work in a rpm environment, as it is tied to apt currently.\n\n1) Companies who are looking at trove are not yet looking at heat, and a hard dependency might stifle growth of the product initially\n	? CERN\n2) homogeneous LaunchConfiguration\n	? a database cluster is heterogeneous\n	? Our cluster configuration will need to specify different sized slaves, and allow a customer to upgrade a single slaves configuration\n	? heat said if this is something that has a good use case, they could potentially make it happen (not sure of timeframe)\n3) have to modify template to scale out\n	? This doable but will require hacking a template in code and pushing that template\n	? I assume removing a slave will require the same finagling of the template\n	? I understand that a better version of this is coming (not sure of timeframe)\n\nI will be tracking the following at [1]\n\n[1] https://wiki.openstack.org/wiki/Trove/HeatIntegration\n\n',NULL,NULL),('<1520363796.416.1367043173925.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:12:53',0,'2013-04-27 06:12:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric8 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/>\nCheckout:periodic-nova-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/> - hudson.remoting.Channel at 787582d3:oneiric8\nUsing strategy: Default\nLast Built Revision: Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\nChecking out Revision 9ecd965eaf03dac01f81964a1e782223d2e2d1a8 (origin/stable/folsom)\n[periodic-nova-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson1663785224151982692.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.Apf39FP1iA\n+ TMPDIR=/tmp/tmp.Apf39FP1iA\n+ trap \'rm -rf /tmp/tmp.Apf39FP1iA\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\n2012.2.5\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-nova-python26-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 60887 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-nova-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182611.942611-1818615746\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric8\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.Apf39FP1iA\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-08-04\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'c463da34-0908-4eaf-95ac-20d642ea8367\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9ecd965eaf03dac01f81964a1e782223d2e2d1a8\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric8\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 60887 166.78.48.106 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires> (line 1))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires> (line 1))\nNo distributions at all found for SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires> (line 1))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Apf39FP1iA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1520547265.79.1386828735542.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-12 06:12:15',0,'2013-12-12 06:12:15',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-dsvm-large-ops-havana #5','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-large-ops-havana/5/>\n\n\n\n','<1905906140.69.1386742885045.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1521266.Rz4CBXU6NB@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-14 11:06:27',36000,'2014-08-14 01:06:27',NULL,'[openstack-dev] [neutron] Which changes need accompanying bugs?','On Wed, 13 Aug 2014 12:46:03 AM Kevin Benton wrote:\n> I\'m not sure what the guideline is, but I would like to point out a good\n> reason to have the bug report even for obvious fixes.\n> When users encounters bugs, they go to launchpad to report them. They don\'t\n> first scan the commits of the master branch to see what was fixed. Having\n> the bug in launchpad provides a way to track the status (fixed, backported,\n> impact, etc) of the bug and reduces the chances of duplicated bugs.\n\nAha, I didn\'t realise there were people interested in the state of the code \nbut following only bugs and not review/commit logs.  In particular release \nbackporting.  Good to know!\n\n> Can you provide an example of a patch that you felt was trivial that a\n> reviewer requested a bug for so we have something concrete to discuss and\n> establish guidelines around?\n\nHere\'s one that fixes unittests in the presence of HTTP_PROXY:\nhttps://review.openstack.org/#/c/110853/\n(I see I haven\'t filed the bug report for that yet, I\'ll do that now)\n\n.. and another that is removing an unused argument to a function:\nhttps://review.openstack.org/#/c/111180/\nI _think_ the intention here was to have a discussion of implementation impact \non the bug rather than in the review(?) but that discussion hasn\'t moved \n(yet).\n\n\nTo be clear: I\'m perfectly happy to file an accompanying bug for each change \n(_every_ change if desired!).\nI want to make sure my accompanying bug reports are as useful as they can be, \nso I\'m trying to learn how and when they\'re used.  At the moment I\'m basically \nwaiting until a reviewer asks for one and then copying the change description \nand a prose version of the initial patch into a new bug report.\n\n-- \n - Gus\n\n\n','<CAO_F6JMRL2t_WDbvkVrVBbjC2EXyQmtPouAfDdfmRLPwkp1Xtw@mail.gmail.com>',NULL),('<1521363575.5.1375077724892.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-29 06:02:04',0,'2013-07-29 06:02:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #301','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/301/>\n\n------------------------------------------\n[...truncated 23 lines...]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/301/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-301\', \'SSH_CLIENT\': \'198.101.231.203 50638 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374971246.29332-2038398225\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise5\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-29_06-00-47\', \'BUILD_NUMBER\': \'301\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'34e9313d-d467-4021-89b0-717875e1f5af\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise5\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#301\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50638 50.56.249.212 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-b7yo95/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-b7yo95/d2to1-0.2.10/egg-dist-tmp-vkrRAO\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-LNTVCF/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-LNTVCF/setuptools-git-1.0/egg-dist-tmp-WhtVez\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-FJmWXj/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-FJmWXj/d2to1-0.2.10/egg-dist-tmp-bSGHd7\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-v9MINE/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-v9MINE/setuptools-git-1.0/egg-dist-tmp-0vALEv\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-NyiKlK/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-NyiKlK/d2to1-0.2.10/egg-dist-tmp-yWk1I5\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-yLELHm/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-yLELHm/setuptools-git-1.0/egg-dist-tmp-lh7vTu\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/301\n[SCP] Copying console log.\n\n\n','<1523989032.0.1374991339834.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1521616.7R635FXVIN@stoner-laptop.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-26 13:03:06',-14400,'2014-09-26 17:03:06',NULL,'[Openstack] Nova guest NUMA placement questions','On Friday, September 26, 2014 03:09:05 PM Daniel P. Berrange wrote:\n\n> > 1. What happens on an overcommit for the number of guest CPUs?\n> > \n> >    - For example, if I have a system with 2 sockets 4 cores each,\n> >    what\n> > \n> > would happen if I have 2 guests, each one wanting 6 cores (assuming\n> > this is not in violation of the hw:cpu_max_cores)?\n> > 2. What happens on an overcommit on memory?\n> \n> The memory and CPU overcommit settings are still honoured when Nova\n> does NUMA placement. eg if you have a host with 2 NUMA nodes, each\n> with 4 physical CPUs and CPU overcommit ratio of x3, then Nova will\n> treat this as being a system with 2 NUMA nodes, each with 12 CPUs.\n> Similarly for memory overcommit.\n> \n\nSo in the scenario you describe above, each guest configuration would be \nconstrained to one NUMA node (since the NUMA node would present itself \nlogically as having 12 CPUs)?  \n\nI was trying to think of a scenario where the guest configuration would \nhave to split up among more than one NUMA node. \n\nRegards,\nSean Toner\n\n\n\n\n\n','<20140926140905.GE25221@redhat.com>',NULL),('<1522037002.456.1367129565083.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:12:45',0,'2013-04-28 06:12:45',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/18/>\n\n\n\n','<1100166618.368.1367042671012.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1522213825.326.1359072139324.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-25 00:02:19',0,'2013-01-25 00:02:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-folsom #116','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/116/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise8 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/>\nCheckout:periodic-swift-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/> - hudson.remoting.Channel at 37c09c93:precise8\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson2527472945277041155.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/116/\', \'BUILD_TAG\': \'jenkins-periodic-swift-docs-stable-folsom-116\', \'SSH_CLIENT\': \'198.101.231.203 44340 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1358882894.605390-1598935191\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'JOB_NAME\': \'periodic-swift-docs-stable-folsom\', \'NODE_LABELS\': \'precise precise8\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-25_00-01-26\', \'BUILD_NUMBER\': \'116\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'1590a7c3-b885-462d-af79-fc133b6a9147\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise8\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 44340 108.166.59.177 22\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-folsom/116\n[SCP] Copying console log.\n\n\n','<828157601.305.1358985712662.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1523989032.0.1374991339834.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-28 06:02:19',0,'2013-07-28 06:02:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #300','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/300/>\n\n------------------------------------------\n[...truncated 23 lines...]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/300/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-300\', \'SSH_CLIENT\': \'198.101.231.203 47584 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374971245.887978-1249220051\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise10\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-28_06-00-44\', \'BUILD_NUMBER\': \'300\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'cb9303f2-0316-4414-a3d9-811eb9860c82\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise10\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#300\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 47584 166.78.138.110 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-Cx_wmu/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Cx_wmu/d2to1-0.2.10/egg-dist-tmp-sVBIfn\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-F9ao4W/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-F9ao4W/setuptools-git-1.0/egg-dist-tmp-tMFe1i\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-XWAIVF/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-XWAIVF/d2to1-0.2.10/egg-dist-tmp-aly4j8\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-6WIl9l/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-6WIl9l/setuptools-git-1.0/egg-dist-tmp-Ngm1VH\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-md98PI/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-md98PI/d2to1-0.2.10/egg-dist-tmp-RBxcJL\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-9QQqo3/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-9QQqo3/setuptools-git-1.0/egg-dist-tmp-4hOlzK\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/300\n[SCP] Copying console log.\n\n\n','<1312995300.60.1374904903740.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<152430654.41668597.1413330723017.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 19:52:03',-14400,'2014-10-14 23:52:03',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','\n\n----- Original Message -----\n> Ok, why are you so down on running systemd in a container?\n\nIt goes against the grain.\n\n>From a distributed systems view, we gain quite a bit of control by maintaining\n\"one service per container\". Containers can be re-organised and re-purposed dynamically.\nIf we have systemd trying to manage an entire stack of resources within a container,\nwe lose this control.\n\n>From my perspective a containerized application stack needs to be managed externally\nby whatever is orchestrating the containers to begin with. When we take a step back\nand look at how we actually want to deploy containers, systemd doesn\'t make much sense.\nIt actually limits us in the long run.\n\nAlso... recovery. Using systemd to manage a stack of resources within a single container\nmakes it difficult for whatever is externally enforcing the availability of that container\nto detect the health of the container.  As it is now, the actual service is pid 1 of a\ncontainer. If that service dies, the container dies. If systemd is pid 1, there can\nbe all kinds of chaos occurring within the container, but the external distributed\norchestration system won\'t have a clue (unless it invokes some custom health monitoring\ntools within the container itself, which will likely be the case someday.)\n\n-- Vossel\n\n\n> Pacemaker works, but its kind of a pain to setup compared just yum installing\n> a few packages and setting init to systemd. There are some benefits for\n> sure, but if you have to force all the docker components onto the same\n> physical machine anyway, why bother with the extra complexity?\n>\n> Thanks,\n> Kevin\n> \n> ________________________________________\n> From: David Vossel [dvossel at redhat.com]\n> Sent: Tuesday, October 14, 2014 3:14 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [kolla] on Dockerfile patterns\n> \n> ----- Original Message -----\n> > Same thing works with cloud init too...\n> >\n> >\n> > I\'ve been waiting on systemd working inside a container for a while. it\n> > seems\n> > to work now.\n> \n> oh no...\n> \n> > The idea being its hard to write a shell script to get everything up and\n> > running with all the interactions that may need to happen. The init\n> > system\'s\n> > already designed for that. Take a nova-compute docker container for\n> > example,\n> > you probably need nova-compute, libvirt, neutron-openvswitch-agent, and the\n> > celiometer-agent all backed in. Writing a shell script to get it all\n> > started\n> > and shut down properly would be really ugly.\n> >\n> > You could split it up into 4 containers and try and ensure they are\n> > coscheduled and all the pieces are able to talk to each other, but why?\n> > Putting them all in one container with systemd starting the subprocesses is\n> > much easier and shouldn\'t have many drawbacks. The components code is\n> > designed and tested assuming the pieces are all together.\n> \n> What you need is a dependency model that is enforced outside of the\n> containers. Something\n> that manages the order containers are started/stopped/recovered in. This\n> allows\n> you to isolate your containers with 1 service per container, yet still\n> express that\n> container with service A needs to start before container with service B.\n> \n> Pacemaker does this easily. There\'s even a docker resource-agent for\n> Pacemaker now.\n> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/docker\n> \n> -- Vossel\n> \n> ps. don\'t run systemd in a container... If you think you should, talk to me\n> first.\n> \n> >\n> > You can even add a ssh server in there easily too and then ansible in to do\n> > whatever other stuff you want to do to the container like add other\n> > monitoring and such....\n> >\n> > Ansible or puppet or whatever should work better in this arrangement too\n> > since existing code assumes you can just systemctl start foo;\n> >\n> > Kevin\n> > ________________________________________\n> > From: Lars Kellogg-Stedman [lars at redhat.com]\n> > Sent: Tuesday, October 14, 2014 12:10 PM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [kolla] on Dockerfile patterns\n> >\n> > On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:\n> > > With Docker, you are limited to the operating system of whatever the\n> > > image\n> > > uses.\n> >\n> > See, that\'s the part I disagree with.  What I was saying about ansible\n> > and puppet in my email is that I think the right thing to do is take\n> > advantage of those tools:\n> >\n> >   FROM ubuntu\n> >\n> >   RUN apt-get install ansible\n> >   COPY my_ansible_config.yaml /my_ansible_config.yaml\n> >   RUN ansible /my_ansible_config.yaml\n> >\n> > Or:\n> >\n> >   FROM Fedora\n> >\n> >   RUN yum install ansible\n> >   COPY my_ansible_config.yaml /my_ansible_config.yaml\n> >   RUN ansible /my_ansible_config.yaml\n> >\n> > Put the minimal instructions in your dockerfile to bootstrap your\n> > preferred configuration management tool. This is exactly what you\n> > would do when booting, say, a Nova instance into an openstack\n> > environment: you can provide a shell script to cloud-init that would\n> > install whatever packages are required to run your config management\n> > tool, and then run that tool.\n> >\n> > Once you have bootstrapped your cm environment you can take advantage\n> > of all those distribution-agnostic cm tools.\n> >\n> > In other words, using docker is no more limiting than using a vm or\n> > bare hardware that has been installed with your distribution of\n> > choice.\n> >\n> > > [1] Is there an official MySQL docker image? I found 553 Dockerhub\n> > > repositories for MySQL images...\n> >\n> > Yes, it\'s called \"mysql\".  It is in fact one of the official images\n> > highlighted on https://registry.hub.docker.com/.\n> >\n> > > >I have looked into using Puppet as part of both the build and runtime\n> > > >configuration process, but I haven\'t spent much time on it yet.\n> > >\n> > > Oh, I don\'t think Puppet is any better than Ansible for these things.\n> >\n> > I think it\'s pretty clear that I was not suggesting it was better than\n> > ansible.  That is hardly relevant to this discussion.  I was only\n> > saying that is what *I* have looked at, and I was agreeing that *any*\n> > configuration management system is probably better than writing shells\n> > cript.\n> >\n> > > How would I go about essentially transferring the ownership of the RPC\n> > > exchanges that the original nova-conductor container managed to the new\n> > > nova-conductor container? Would it be as simple as shutting down the old\n> > > container and starting up the new nova-conductor container using things\n> > > like\n> > > --link rabbitmq:rabbitmq in the startup docker line?\n> >\n> > I think that you would not necessarily rely on --link for this sort of\n> > thing.  Under kubernetes, you would use a \"service\" definition, in\n> > which kubernetes maintains a proxy that directs traffic to the\n> > appropriate place as containers are created and destroyed.\n> >\n> > Outside of kubernetes, you would use some other service discovery\n> > mechanism; there are many available (etcd, consul, serf, etc).\n> >\n> > But this isn\'t particularly a docker problem.  This is the same\n> > problem you would face running the same software on top of a cloud\n> > environment in which you cannot predict things like ip addresses a\n> > priori.\n> >\n> > --\n> > Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}\n> > Cloud Engineering / OpenStack          | http://blog.oddbit.com/\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1A3C52DFCD06494D8528644858247BF088B6E0@EX10MBOX03.pnnl.gov>',NULL),('<1524413274.10172168.1405193065576.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-12 15:24:25',-14400,'2014-07-12 19:24:25',NULL,'[openstack-dev] [qa][all] Branchless Tempest beyond pure-API\n tests, impact on backporting policy','\n> So I\'m not sure that this should be a mandatory thing, but an\n> opt-in. My real concern is the manpower, who is going to take the\n> time to write all the test suites for all of the projects. I think\n> it would be better to add that on-demand as the extra testing is\n> required. That being said, I definitely view doing this as a good\n> thing and something to be encouraged, because tempest won\'t be able\n> to test everything.\n>\n> The other thing to also consider is duplicated effort between\n> projects. For an example, look at the CLI tests in Tempest, the\n> functional testing framework for testing CLI formatting was\n> essentially the same between all the clients which is why they\'re in\n> tempest. Under your proposal here, CLI tests should be moved back to\n> the clients. But, would that mean we have a bunch of copy and pasted\n> versions of the CLI test framework between all the project.\n>\n> I really want to avoid a situation where every project does the same\n> basic testing differently just in a rush to spin up functional\n> testing. I think coming up with a solution for a place with common\n> test patterns and frameworks that can be maintained independently of\n> all the projects and consumed for project specific testing is\n> something we should figure out first. (I\'m not sure oslo would be\n> the right place for this necessarily)\n\nYep, I\'d have similar concerns about dupication of effort and\ndivergence in a rush to spin up in-tree mini-Tempests across all the\nprojects.\n\nSo, I think it would be really great to have one or two really solid\nexemplar in-tree functional test suites in place, in order to allow\nthe inevitable initial mistakes to be made the minimal number of\ntimes.\n\nIdeally the QA team would have an advisory, assisting role in getting\nthese spun up so that the project gets the benefit of their domain\nexpertise.\n\nOf course it would be preferable also to have the re-usable elements\nof the test infrastructure in a consumable form that the laggard\nprojects can easily pick up without doing whole-scale copy\'n\'paste.\n\n> So I think that the contract unit tests work well specifically for\n> the ironic use case, but isn\'t a general solution. Mostly because\n> the Nova driver api is an unstable interface and there is no reason\n> for that to change. It\'s also a temporary thing because eventually\n> the driver will be moved into Nova and then the only cross-project\n> interaction between Ironic and Nova will be over the stable REST\n> APIs.\n>\n> I think in general we should try to avoid doing non REST API\n> cross-project communication.\n\nAs I\'ve pointed out before, I don\'t think it\'s feasible for ceilometer\nto switch to using only REST APIs for cross-project communication.\n\nHowever what we can do is finally grasp the nettle of \"contractizing\"\nnotifications, as discussed on this related thread:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-July/039858.html\n\nThe realistic time horizon for that is the K* cycle I suspect, but\noverall from that thread there seems to be some appetite for actually\ndoing it finally. \n\n> So hopefully there won\'t be more of\n> these class of things, and if there are we can tackle them on a per\n> case basis. But, even if it\'s a non REST API I don\'t think we should\n> ever encourage or really allow any cross-project interactions over\n> unstable interfaces.\n\nYes, if we go from discouragement to explicitly *disallowing* such\ninteractions, that\'s probably something that would need to mandated\nat TC level IMO, with the appropriate grandfathering of existing usage.\n\nIs this something you or Sean (being a member of the TC) or I could\ndrive?\n\nI\'d be happy to draft some language for a governance patch, but having\nbeen to-and-fro the well before on such patches, I\'m well aware that a\nTC member pushing it would add considerably to effectiveness.\n\n> As a solution for notifications I\'d rather see a separate\n> notification white/grey (or any other monochrome shade) box test\n> suite. If as a project we say that notifications have to be\n> versioned for any change we can then enforce that easily with an\n> external test suite that contains the definitions for all the\n> notification. It then just makes a bunch of api calls and sits on\n> RPC verifying the notification format. (or something of that ilk)\n\nDo you mean a *single* external test suite?\n\nAs opposed to multiple test suites, each validating the notifications\nemitted by each project?\n\nThe reason I\'m laboring this point is that such an over-arching\ntestsuite feels a little Tempest-y. Seems it would have to spin up an\nentire devstack and then tickle the services into producing a range\nof notifications before consuming and verifying the events.\n\nWould that possibly be more lightweight if tested on a service-by-service\nbasis?\n\n> I agree that normally whitebox testing needs to be tightly coupled\n> with the data models in the projects, but I feel like notifications\n> are slightly different.  Mostly, because the basic format is the\n> same between all the projects to make consumption simpler. So\n> instead of duplicating the work to validate the notifications in all\n> the projects it would be better to just implement it once.  I also\n> think tempest being an external audit on the API has been invaluable\n> so enforcing that for notifications would have similar benefits.\n\nSo, do I take from that your vision is for something Tempest-y,\nexcept with notifications as opposed to APIs being the primary\naxis of verification?\n\n> As an aside I think it would probably be fair if this was maintained\n> as part of ceilometer or the telemetry program, since that\'s really\n> all notifications are used for. (or least as AIUI) But, it would\n> still be a co-gating test suite for anything that emits\n> notifications.\n\nPossibly. Though I\'m not sure ceilo should really be considered the\nexclusive consumer of these notifications. We have things on stackforge\n(e.g. StackTach) that also consume events, and other integrated projects\nhave expressed interest in doing so (e.g. Horizon).\n\n> I think the only real issue in your proposal is that the boundaries\n> between all the test classifications aren\'t as well defined as they\n> seem. I agree that having more intermediate classes of testing is\n> definitely a good thing to do.  Especially, since there is a great\n> deal of hand waving on the details between what is being run in\n> between tempest and unit tests. But, the issue as I see it is\n> without guidelines on what type of tests belong where we\'ll end up\n> with a bunch duplicated work.\n\nYes, we really need to protect the community from burning a lot of\nduplicated effort to end up with a hotchpotch of different functional\ntesting harnesses.\n\n> It\'s the same problem we have all the time in tempest, where we get\n> a lot of patches that exceed the scope of tempest, despite it being\n> arguably clearly outlined in the developer docs. But, the complexity\n> is higher in this situation, because of having a bunch of different\n> types of test suites that are available to add a new test to. I just\n> think before we adopt #2 as mandatory it\'s important to have a\n> better definition on the scope of the project specific functional\n> testing.\n\nSo, I\'m glad you brought up exceeding the scope of Tempest, I think it\nreally needs to communicated more widely exactly what Tempest is and\nisn\'t. Maybe we just didn\'t reads the docco with enough care, but I\nguess the gung-ho adoption of Tempest was at least partially driven by\nthe perception that it was crucial to being considered a \"good\ncitizen\" in openstack (c.f. the relevant TC mandates).\n\n> I think that negative testing is still part of tempest in your\n> proposal. I still feel that the negative space of an API still is\n> part of the contract, and should be externally validated. As part of\n> tempest I think we need to revisit the negative space solution\n> again, because I haven\'t seen much growth on the automatic test\n> generation. We also can probably be way more targeted about what\n> we\'re running, but I don\'t think punting on negative testing in\n> tempest is something we should do.\n\nI agree, negative tests are IMO a crucial aspect of ensuring a\nusable API implementation.\n\n> I agree that we should be directly testing the cross-project\n> integration points which aren\'t REST APIs.\n\nDo you mean, directly testing in Tempest or directly testing\nelsewhere?\n\n> I definitely think more testing is always better.\n\nAin\'t that the truth! :)\n\n> I just want to make sure we\'re targeting the right things, because\n> this proposal is pushing for a lot extra work for everyone. I want\n> to make sure that before we commit to something this large that it\'s\n> the right direction.\n\n+100.\n\nI\'m not even sure what the appropriate mechanism is for \"commit[ting]\nto something this large\". At the very least it needs cross-project\napproval approval/acquiescence at the PTLs meeting. If this had come\nup a couple months ago, obviously we\'d have been discussing at length\nat the cross-project track in ATL. OTOH I don\'t know if we can leave\nit fester until the K* summit.\n\nCheers,\nEoghan\n\n\n','<20140710134854.GA922@Sazabi.treinish>',NULL),('<1524761383.14.1377929777965.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-31 06:16:17',0,'2013-08-31 06:16:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #12','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/12/>\n\n------------------------------------------\n[...truncated 951 lines...]\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.02\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.02\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.20\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.02\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: We test that the \'--respawn\' option causes the API server\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 161, in test_respawn\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, \'Unexpected server launch status\'\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.51 secs:\n    19.91    TestGlanceControl.test_bouncing\n    19.14    TestBinGlance.test_results_filtering\n    18.14    TestRootApi.test_version_configurations\n    18.04    TestBinGlanceCacheManage.test_queue\n    16.28    TestScrubber.test_delayed_delete\n----------------------------------------------------------------------\nRan 926 tests in 763.293s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python26-stable-folsom-12\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.6.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Yg0tb6dlxM\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/12/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-9/12\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1525121480.428.1367129146626.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:05:46',0,'2013-04-28 06:05:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-docs-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-ceilometer-docs-stable-grizzly/18/>\n\n\n\n','<1164048471.359.1367042605211.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1525377.1721.1352160169796.JavaMail.sthakkar@sthakkar-mbair.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 16:02:50',-28800,'2012-11-06 00:02:50',NULL,'[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion','Yes, I think having a vendor specific adapter is very much in the plan. It should remain extensible in this manner. As Youcef mentioned, I doubt it\'ll be XSDs since there isn\'t as much XML in the quantum project but the same model used for L2 should work.\n\nSachin\n\n----- Original Message -----\nFrom: \"Youcef Laribi\" <Youcef.Laribi at eu.citrix.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, November 5, 2012 1:48:15 PM\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion\n\n\n\n\n\nHi Peter, \n\n\n\nI think we all agree that the LBaaS APIs allows for extensions in line with other OpenStack APIs. As I said earlier the use of XSDs to generate the APIs is not an established practice in OpenStack projects (and in Quantum), but we can certainly use XSDs to document the API if it helps. Vendor drivers should be able to support extensions. If the user wants to use a certain LBaaS extension and this extension is only implemented by some vendors drivers, then this could be used to select that vendor?s implementation (using the ?service type? mechanism described by Salvatore?). \n\n\n\nYoucef \n\n\n\n\n\n\n\n\n\nFrom: Mellquist, Peter [mailto:peter.mellquist at hp.com] \nSent: Monday, November 5, 2012 1:16 PM \nTo: OpenStack Development Mailing List \nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\nHi Youcef, \n\n\n\nThis sound good. One question, can the model be extended by a vendor specific adapter? ( In Atlas, you had the XSDs (schema ) allow <anyAttributes> which seemed to allow this ) \n\n\n\nThanks \n\nPeter. \n\n\n\n\n\nFrom: Youcef Laribi [ mailto:Youcef.Laribi at eu.citrix.com ] \nSent: Monday, November 05, 2012 1:03 PM \nTo: OpenStack Development Mailing List \nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\nReturning to the LBaaS plugin design, my current assumption (and I want to check if this is shared) is that we don?t want to have a separate LBaaS plugin for each vendor (even though this is of course possible). There is a core functionality in LBaaS that needs to be implemented anyway and therefore if we agree how this is done, it makes sense to have one piece (one plugin) doing this (like the eBay and Atlas services had). This piece (the LBaaS plugin) will for example maintain the LBaaS data model as defined by the API. Then there are the vendor-specific parts (the ones we called ?adapters? in Atlas, others call them ?drivers?, etc.). And we would want to be able to have several of these vendor drivers loaded simultaneously in an LBaaS service. \n\n\n\nSome of these drivers can also implement several ?advanced services?. So, a vendor?s ?driver? could implement more than one ?advanced service? interface if it wants to (e.g. a firewall + lb) therefore interfacing with several Quantum plugins. I have a picture illustrating this setup ( http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+LBaaS+plugin+with+providers.png ). Would love to hear your thoughts on the above. \n\n\n\nYoucef \n\n\n\n\n\n\n\n\n\n\n\nFrom: Salvatore Orlando [ mailto:sorlando at nicira.com ] \nSent: Monday, November 5, 2012 8:03 AM \nTo: OpenStack Development Mailing List \nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\nHi Youcef, \n\n\n\n\n\nsorry about the delay in my reply. \n\n\nI think consensus about the right approach is starting to maturing. I totally agree with you on the need for having clear interfaces. \n\n\n\n\n\nFor the L3 functionality, at the summit we decided to regard it as \"core\". And indeed I already have a blueprint for moving the APIs from extensions to core. \n\n\nSo, technically speaking, L3 will become part of the core plugin. \n\n\n\n\n\nHowever, as I also discussed on the wiki page, I\'d like community input to understand how to deal with Floating IPs, which despite being part of the L3 extension kind of represent an \"advanced\" service. \n\n\n\n\n\nSalvatore \n\n\nOn 2 November 2012 20:00, Youcef Laribi < Youcef.Laribi at eu.citrix.com > wrote: \n\n\n\nThanks Salvatore. I?m also in favor of loading several plugins and have clean interfaces between them. \n\n\n\nDoes this mean the L3 functionality will be factored out in its own plugin if we go with the ?multiple plugins? approach, or will you keep it in the ?core plugin? ? \n\n\n\nYoucef \n\n\n\n\n\n\n\n\n\n\nFrom: Salvatore Orlando [mailto: sorlando at nicira.com ] \nSent: Friday, November 2, 2012 10:28 AM \n\n\n\n\nTo: OpenStack Development Mailing List \nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\n\n\nYoucef, \n\n\n\n\n\nThe proposals you\'ve described are exactly the ones being considered on the wiki page. \n\n\nI am considering both at the moment, and I\'m evaluating them along the following dimensions: \n\n\n1) Flexibility (and the multiple plugins approach here is a winner, probably) \n\n\n2) Impact on Quantum architecture (single plugin would be the one with the lowest impact) \n\n\n3) Implementation effort (here I am still undecided, as the approach with a single plugin ends up moving the complexity from Quantum server to the plugin) \n\n\n\n\n\nIt seems we have not yet a clear decision, but several people from the community are advocating for clean, separate interfaces among plugins. \n\n\nAnother option we might consider is whether we start adopting 1 plugin per type of service (so 1 core plugin, 1 firewall plugin, 1 load balancing plugin), and update quantum to dispatch the call to the appropriate plugin. \n\n\nOn this single \'LB\' plugin we can immediately start providing an OSS implementation, so that Quantum users will have the ability of testing the feature. Vendor-specific plugin might follow suit. What we will not have immediately (and I mean G-1 or G-2) is the ability of serving multiple providers at the same time, which is one of the fundamental requirements for LBaaS, but we can commit to add this capability by G-3. \n\n\n\n\n\nThanks, \n\n\nSalvatore \n\n\n\n\n\nOn 2 November 2012 16:45, Youcef Laribi < Youcef.Laribi at eu.citrix.com > wrote: \n\n\n\nThanks Eugene, Salvatore for validating the current situation. Now let me try to understand the changes we are proposing for incorporating LBaaS and other ?advanced services?. \n\n\n\nAll current ?Core plugins? in Quantum like the ?Linux Bridge? plugin implement the L2 core APIs, and some of these plugins also implement the L3 extension. Today, there can only be one ?core plugin? running in Quantum. So, the total of the APIs supported will depend the core plugin that was configured. \n\n\n\nAre we saying, that we will modify some of these core plugins to also implement the LBaaS extension, so they will expose the LBaaS APIs in addition to the L2 and L3 APIs ? If not, is the proposal to modify Quantum to support more than one plugin at a time (a ?core? one + others) ? \n\n\n\nYoucef \n\n\n\n\n\n\n\nFrom: Salvatore Orlando [mailto: sorlando at nicira.com ] \nSent: Friday, November 2, 2012 2:11 AM \n\n\n\nTo: OpenStack Development Mailing List \n\nSubject: Re: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\n\n\nYoucef, \n\n\n\n\n\nI think that picture describes quite well the framework Quantum is already adopting for l2/l3 connectivity. \n\n\nWe could do down that route for LBaaS as well. However for supporting multiple providers we\'ll need to keep in mind that we might need some logic, within the Quantum plugin for dispatching to the appropriate agent. \n\n\n\n\n\nWith your permission, I will take your picture and use it in the service insertion wiki page, which I will update with the outcome of the recent discussions we had. \n\n\n\n\n\nSalvatore \n\n\nOn 2 November 2012 07:22, Eugene Nikanorov < enikanorov at mirantis.com > wrote: \n\nHi Youcef, \n\n\n\n\n\nThe picture you\'ve made is quite accurate. \n\n\nMy opinion is that we should adopt the same approach for lbaas, e.g. extension - plugin - agent - drivers. \n\n\n\n\n\nThanks, \n\n\nEugene. \n\n\n\n\nOn Fri, Nov 2, 2012 at 10:44 AM, Youcef Laribi < Youcef.Laribi at eu.citrix.com > wrote: \n\n\n\n\n\n\n\nEugene, Salvatore, \n\n\n\nIn order to clarify the terminology in our meetings and not get confused, I?m trying to draw a picture that represents how Quantum is organized today (mostly for myself). I have uploaded an attempt here: \n\nhttp://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Internal+components.png \n\n\n\nCan you please check it for accuracy since you are familiar with the code? Once we agree and understand this picture, we can more easily discuss what needs to be changed in Quantum to accommodate LBaaS. \n\n\n\nYoucef \n\n\n\nFrom: Eugene Nikanorov [mailto: enikanorov at mirantis.com ] \nSent: Wednesday, October 31, 2012 6:32 AM \nTo: openstack-dev at lists.openstack.org \nSubject: [openstack-dev] [Quantum][LBaaS] Advanced Services Insertion \n\n\n\n\n\nHi Salvatore, \n\n\n\n\n\nI\'d like to give some feedback/questions based on yesterday\'s meeting discussion and your renewed http://wiki.openstack.org/Quantum/ServiceInsertion page. \n\n\n\n\n\nFirst of all, I think it\'s worth to fix the terminology just to avoid any confusion: \n\n\n\n\n\n- extension (API extension) - set of REST calls \n\n\n- plugin - code that implements certain API, works with quantum database, pushes calls to agents \n\n\n- core plugin - code that implements core API (networks, subnets, ports, L3) \n\n\n- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent \n\n\n- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices. \n\n\n\n\n\nSome thoughts on the Service Insertion proposal: \n\n\n\n\n\n1. It seems that multiplugin approach is the right way to move further compared to \"mixin\" approach where we inject and modify code of the core plugin. \n\n\nThis will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management). \n\n\n\n\n\n2. Having several implementations of the same service type. \n\n\nIf all services of the certain type implement the same calls, then something should allow to route the call to particular plugin. \n\n\nThe options include: \n\n\n1) passing particular service impl as a url parameter \n\n\n2) having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json \n\n\n3) having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available \n\n\n\n\n\nMy preference is (2): first of all, it \"splits\" whole API between core API and Adv Svc API, and also does so for different service type implementations. \n\n\nAlthough URIs may not be so short as we want them, that could prevent from naming collisions between different service types. \n\n\n\n\n\n3. Service Insertion: \n\n\nI was thinking about routed/floating-mode insertion and there is a certain thing I don\'t understand: the workflow. \n\n\nIt seems that the whole thing is somehow close to what we used to call \"device management\" in mirantis implementaion of lbaas, but it doesn\'t look like solving all device management tasks. \n\n\n\n\n\nSo in our implementation of LBaaS the workflow was as following: \n\n\n1) admin creates the device. Essentially it\'s just an instruction to LBaaS of where is the device (it\'s address), which type is it and credentials to manage it. \n\n\n2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration \n\n\n\n\n\nIf we\'re talking about workflow within Quantum it could look like following (scenario 1 - shared HW device): \n\n\n1) admin creates the device. The same as in lbaas - address, type, credentials \n\n\n2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration), \n\n\nconfigures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network \n\n\n\n\n\nIf we\'re talking about private balancer with Quantum, then: \n\n\n1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance. \n\n\n2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required \n\n\n\n\n\nIt would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be. \n\n\n\n\n\nThanks, \n\n\nEugene. \n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<7B14C05615DB43488B85E143995BD54901081F7C9B0D@LONPMAILBOX01.citrite.net>',NULL),('<1525456614.10877864.1371064460049.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-12 15:14:20',-14400,'2013-06-12 19:14:20',NULL,'[openstack-dev] XenServer 6 tests failing this morning','\n\n----- Original Message -----\n> From: \"Bob Ball\" <bob.ball at citrix.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, June 12, 2013 11:23:15 AM\n> Subject: Re: [openstack-dev] XenServer 6 tests failing this morning\n> \n> I\'ve fixed this - the VMs should now be start-able.  They have the free\n> XenServer license applied to them,\n> \n> Could you add some earlier warning so that we get a clear message if the VMs\n> fail to start vs fail after they have started?\n> \n> Having the primary symptom being the xenstore issue is slightly weird :)  I\n> imagine the smokestack tests should fail rather than timeout in this case?\n\nThis wasn\'t by design... it was simple the first time we\'ve hit it. I honestly thought we had already installed licenses on these so I initially didn\'t expect it either. Totally agree that this was a bit cryptic to figure out from the logs though. In any case feel free to throw up a patch to improve the error checking here.\n\nIn the meantime now that we have new licenses installed the XenServer 6.1 tests are running again. :)\n\nDan\n\n> \n> Bob\n> \n> -----Original Message-----\n> From: Dan Prince [mailto:dprince at redhat.com]\n> Sent: 12 June 2013 15:54\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] XenServer 6 tests failing this morning\n> \n> \n> \n> ----- Original Message -----\n> > From: \"Bob Ball\" <bob.ball at citrix.com>\n> > To: \"OpenStack Development Mailing List\"\n> > <openstack-dev at lists.openstack.org>\n> > Sent: Wednesday, June 12, 2013 9:33:06 AM\n> > Subject: Re: [openstack-dev] XenServer 6 tests failing this morning\n> > \n> > Sorry, I should have replied to the list as well.\n> > \n> > We debugged this one off-list as the debugging included IP addresses\n> > and some private information.\n> > \n> > The root cause is actually a VM dying and smokestack continually\n> > asking for the SSH key, so we had a constant stream of xenstore-read\n> > requests for /local/domain/-1/data/ssh_key.\n> \n> I can add a fix to check for a valid DOM id before asking for the ssh_key....\n> but the fact that the VMs die is the root cause of the failure so we need to\n> fix that first.\n> \n> I took a closer look this morning and it looks like the machines simply need\n> licenses. Bob: Can you guys have a look at getting licenses for these\n> machines?\n> \n> # xe vm-start uuid=d497ad9a-cdb2-333d-fd43-b0d1ab8a0a80\n> Your license has expired.  Please contact your support representative.\n> \n> Dan\n> \n> > \n> > This is something that Dan is looking at fixing in smokestack, and\n> > hopefully we will get more information on what happened with the test\n> > domains separately.\n> \n> \n> \n> \n> \n> \n> > \n> > Bob\n> > \n> > -----Original Message-----\n> > From: John Garbutt [mailto:john at johngarbutt.com]\n> > Sent: 12 June 2013 14:20\n> > To: OpenStack Development Mailing List\n> > Subject: Re: [openstack-dev] XenServer 6 tests failing this morning\n> > \n> > So apparently the errors are harmless:\n> > http://forums.citrix.com/message.jspa?messageID=1670827\n> > \n> > It is probably when nova is polling for the agent to respond.\n> > I assume the image you are using does have the agent present?\n> > \n> > But 1.2G worth seems... excessive.\n> > Its worth checking that log rotate is working correctly?\n> > I don\'t remember what all the defaults are.\n> > \n> > Also, is the timeout due to everything slowing up and you running out\n> > of Dom0 disk space? Or was there something else going on? I guess\n> > clearing out all the logs should give us a bit of time to find the real\n> > problem.\n> > \n> > John\n> > \n> > On 11 June 2013 12:57, Dan Prince <dprince at redhat.com> wrote:\n> > > Hi all,\n> > >\n> > > As of this morning it looks like the / partition on the SmokeStack\n> > > xenserver machines is full. The issue seems to be that the\n> > > xenstored-access.log has grown to 1.2G in less than 12 hours. Tons\n> > > of\n> > > this:\n> > >\n> > > [root at 10-13-39-10 log]# tail xenstored-access.log Jun 11 11:49:12\n> > > 10-13-39-10 /opt/xensource/bin/xenstored:  A14411977 newconn Jun 11\n> > > 11:49:12 10-13-39-10 /opt/xensource/bin/xenstored:  A14411977\n> > > error     ENOENT\n> > > Jun 11 11:49:12 10-13-39-10 /opt/xensource/bin/xenstored:  A14411977\n> > > endconn\n> > >\n> > > Any idea if this an upstream regression or perhaps a configuration issue?\n> > >\n> > > The SmokeStack tests are still running... but they all timeout after\n> > > an hour.\n> > >\n> > > Dan\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<BB824EA959B82F43820FFEE5E6B00AA6034FD7@LONPEX01CL01.citrite.net>',NULL),('<15254B9D-1D77-42EF-A298-F6846323463A@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-02 11:50:19',25200,'2014-04-02 04:50:19',NULL,'[openstack-dev] [Mistral] Review reminder','LGTM. If others agree we can fix the jenkins job.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 02 Apr 2014, at 07:51, Dmitri Zimine <dz at stackstorm.com> wrote:\n\n> We agreed to review this and if/when OK, fix the murano-cli. Can you guys please take a look? \n> https://review.openstack.org/#/c/81941/\n> \n> DZ>\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140402/8fdd0ea9/attachment.html>\n\n','<D1EDA06A-1A09-4BF7-96C2-12AA086C294D@stackstorm.com>',NULL),('<1525578727.6954295.1375190326086.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-30 09:18:46',-14400,'2013-07-30 13:18:46',NULL,'[openstack-dev] Blueprint information -\n	security-group-rules-protocol-numbers','Please discard \n\nThanks\n\nOfer \n\n----- Original Message -----\n> From: \"Ofer Blaut\" <oblaut at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Cc: arosen at nicira.com\n> Sent: Tuesday, July 30, 2013 3:50:42 PM\n> Subject: Blueprint information - security-group-rules-protocol-numbers\n> \n> Hi,\n> \n> I am interested in helping out with QE efforts on upstream\n> OpenStack, specifically around Neutron.\n> \n> I\'m trying to understand the following blueprint,It will be great if you can\n> point me to a detailed spec\n> \n> https://blueprints.launchpad.net/neutron/+spec/security-group-rules-protocol-numbers\n> \n> Thanks\n> \n> Ofer\n\n\n','<209507163.6939136.1375188642650.JavaMail.root@redhat.com>',NULL),('<1525689104.225.1354666303557.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-05 00:11:43',0,'2012-12-05 00:11:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #65','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/65/>\n\n\n\n','<1526067233.211.1354579940694.JavaMail.jenkins@jenkins.openstack.org>',NULL);
INSERT INTO `messages` VALUES ('<1526067233.211.1354579940694.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-04 00:12:20',0,'2012-12-04 00:12:20',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #64','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/64/>\n\n------------------------------------------\n[...truncated 907 lines...]\nTestStore\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.02\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.02\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.18\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: We test that a mis-configured default_store causes the API server\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 1233, in test_unsupported_default_store\n    **self.__dict__.copy())\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/__init__.py\",> line 570, in start_server\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, \'Unexpected server launch status\'\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.94 secs:\n    15.02    TestGlanceControl.test_bouncing\n    14.22    TestScrubber.test_delayed_delete\n    13.80    TestGlanceControl.test_reload\n    13.60    TestGlanceControl.test_respawn\n    12.31    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 913 tests in 484.206s\n\nFAILED (SKIP=100, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.9.1\neventlet==0.9.17\nglance==jenkins-periodic-glance-python26-stable-folsom-64\ngreenlet==0.4.0\nhttplib2==0.7.7\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==0.7\nkombu==2.5.3\nlxml==3.0.1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==0.14.2\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/64\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/64/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1526172401.16572277.1383161152042.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 15:25:52',-14400,'2013-10-30 19:25:52',NULL,'[openstack-dev] [Solum] Solum transitioned to openstack-dev','----- Original Message -----\n> Hi,\n> \n> The Solum team has agreed[1] to use openstack-dev, and has closed its\n> project-specific mailing list. We look forward to discussing ongoing design\n> and development efforts here. We are also transitioning to an openstack\n> meeting channel for subsequent public meetings.\n> \n> Regards,\n> \n> Adrian Otto\n> \n> [1] Minutes: http://irclogs.solum.io/2013/solum.2013-10-29-16.01.html\n> \n\nAnd for reference, here\'s [2] the archive of the discussions that had happened prior to us deciding to pollute the dev list.\n\n[2] http://lists.solum.io/pipermail/solum/\n\n\n','<398A7889-8C7F-4003-A4CA-8B2995FB57F5@rackspace.com>',NULL),('<1526409571.463392.1364908704133.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-02 09:18:24',-14400,'2013-04-02 13:18:24',NULL,'[openstack-dev] new Reviewday location','A quick update on Reviewday:\n\nReviewday is a report that helps present a prioritized list of reviews that people should be working on.\n\nThanks to some recent help from Elizabeth Krumbach ReviewDay has moved under status.openstack.org. The new report location is here:\n\n http://status.openstack.org/reviews/\n\nThe old location at reviewday.ohthree.com will likely be decommissioned in the near future.\n\nAlso, if you are interested in hacking you can find the latest code here:\n\n https://github.com/openstack-infra/reviewday\n\nDan Prince (dprince)\n\n\n','<1021321195.460122.1364908023895.JavaMail.root@redhat.com>',NULL),('<1526417771.280.1368514512172.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-14 06:55:12',0,'2013-05-14 06:55:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #34','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/34/changes>\n\nChanges:\n\n[Gary Kotton] Validate that netaddr does not receive a string with whitespace\n\n[Gary Kotton] Fix 500 raised on disassociate_floatingips when out of sync\n\n[Gary Kotton] Change Daemon class to better match process command lines.\n\n------------------------------------------\n[...truncated 5046 lines...]\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.10\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.05\n    test_member_list                                             OK    0.05\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    2.19\n    test_pool_get                                                OK    0.05\n    test_pool_list                                               OK    0.05\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.05\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.07\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    2.29\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.07\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.00\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.01\n    test_init_exists                                             OK    0.01\n    test_init_exists_unlink_fails_file_still_exists              OK    0.01\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.00\n    test_call_internal_server_error                              OK    0.00\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.01\n    test_main_dont_fork                                          OK    0.02\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.00\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    2.53\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.42\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.33\n    test_quotas_default_values                                   OK    0.37\n    test_show_quotas_with_admin                                  OK    0.45\n    test_show_quotas_without_admin_forbidden                     OK    0.61\n    test_update_quotas_forbidden                                 OK    2.60\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.20\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.20\n    test_list_quotas_with_admin                                  OK    0.20\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    2.58\n    test_quotas_limit_check                                      OK    0.20\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.20\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.24\n    test_show_quotas_with_owner_tenant                           OK    0.22\n    test_show_quotas_without_admin_forbidden_returns_403         OK    2.69\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.20\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.21\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.22\n    test_list_quotas_with_admin                                  OK    2.57\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_quotas_default_values                                   OK    0.20\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.20\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.21\n    test_quotas_limit_check_with_over_quota                      OK    0.22\n    test_quotas_loaded_bad_returns_404                           OK    2.56\n    test_quotas_loaded_right                                     OK    0.20\n    test_show_quotas_with_admin                                  OK    0.20\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.22\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    2.57\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.20\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.48\n    test_KillFilter_deleted_exe                                  OK    0.01\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.45\n    test_health_monitor_delete_with_router_id                    OK    0.37\n    test_health_monitor_delete_without_router_id                 OK    0.31\n    test_health_monitor_update_with_router_id                    OK    0.29\n    test_health_monitor_update_without_router_id                 OK    0.28\n    test_pool_create                                             OK    0.27\n    test_pool_delete_with_router_id                              OK    0.29\n    test_pool_delete_without_router_id                           OK    0.29\n    test_pool_update_with_router_id                              OK    3.48\n    test_pool_update_without_router_id                           OK    0.26\n    test_router_create_no_service_type_id                        OK    0.22\n    test_router_create_with_service_type_id                      OK    0.22\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.22\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.24\n    test_vip_create                                              OK    0.28\n    test_vip_delete_with_router_id                               OK    0.32\n    test_vip_delete_without_router_id                            OK    0.32\n    test_vip_update_with_router_id                               OK    0.29\n    test_vip_update_without_router_id                            OK    2.84\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.45\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.45\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.52\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.42\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.43\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.51\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv4_ingress           Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.SfL6wjSSnT\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/34\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1526471866.20.1383026927446.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-29 06:08:47',0,'2013-10-29 06:08:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #51','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/51/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4b60e50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4b60e50>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5857590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5857590>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-d67d02ac-b5d5-43de-b57d-a83df18421f9\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x37147d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x37147d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x37147d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x37147d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:08:21Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'21\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-30T06:08:21Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'21\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'30\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'30\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:08:21+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'21\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:08:21-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'21\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:08:21Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'21\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x688d950>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22b82d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 82.69 secs:\n    24.13    TestScrubber.test_scrubber_app\n    18.86    TestScrubber.test_delayed_delete\n    13.50    TestGlanceControl.test_reload\n    13.28    TestGlanceControl.test_respawn\n    12.93    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 449.751s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.51\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.22\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.LiVvNYQwNK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/51/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise35/51\n[SCP] Copying console log.\n\n\n','<283799617.12.1382854178144.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<152652886.21209341.1391396376617.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-02 21:59:36',-18000,'2014-02-03 02:59:36',NULL,'[Openstack-docs] Proposal: CLI Reference manual','\n\n----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>, \"Anne Gentle\" <anne at openstack.org>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Friday, January 31, 2014 1:44:04 AM\n> Subject: Re: [Openstack-docs] Proposal: CLI Reference manual\n> \n> On 01/30/2014 04:26 PM, Diane Fleming wrote:\n> > Actually, I\'m fine either way ? keeping it as appendix or as separate book.\n> > \n> > But either way, I think we need to improve the formatting ? I\'ll open a\n> > bug for that.\n\nAnd can the \'install the clients\' section be removed? Clients should already be installed via the Installation Guide?\n\n> \n> Yes, please do open a bug. I\'ll see what I can do to improve it.\n> \n> > What does everyone else think about keeping command ref as appendix, or\n> > moving to separate book?\n> \n> I\'m fine either way.  Having one more guide, will not really cost us\n> more work than having it in the appendices. And having a guide would\n> give us *one* location for the content instead of currently two guides\n> with both the same large appendix.\nDefinitely vote for having it\n\n> \n> And I\'m even fine with removing the appendix and not having a book since\n> these are help texts users could get themselves on the command line...\n> Still, it\'s nice to have a common location to look it up and be aware of\n> these. And since there are no man pages for these, this it probably the\n> best way to have it,\n\n+1 on removing the CLI info from both EUG and AUG and providing links (really dislike bloat-by-duplication).\n\nBut was there a reason for not just putting the CLI info into the Configuration Reference Guide?\nWe\'re removing the HowTos from that guide, which means the whole thing really is a reference now?\n\n\ncheers, Summer\n> \n> Andreas\n> --\n>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi\n>   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>    GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong\n\n\n','<52EA7344.7000706@suse.com>',NULL),('<1526804634.8849343.1401440973013.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-30 11:09:33',7200,'2014-05-30 09:09:33',NULL,'[openstack-dev] [keystone] Redesign of Keystone Federation','Hello,\n\nFor what it is worth I was toying around with the possibility to extend the federation mapping mechanism to be used with keystone\'s external auth plugin. I believe this would allow easy, immediate and generic support of other federation protocols through apache mods without the need to write specific auth plugins unless it is needed.\nI\'ve pushed a very early PoC on this and given some basic guidelines to make it work with OpenID here: \n\n* PoC: https://review.openstack.org/#/c/92079/\n* Blueprint: https://blueprints.launchpad.net/keystone/+spec/external-auth-federation-mapping\n\nI\'d be happy to get some feedback and push work forward on it if it can be of any use to the project. Let me know what you think !\n\nRegards\n\nMatthieu Huin \n\nmhu at enovance.com\n\n----- Original Message -----\n> From: \"David Chadwick\" <d.w.chadwick at kent.ac.uk>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, May 28, 2014 5:59:48 PM\n> Subject: [openstack-dev]  [keystone] Redesign of Keystone Federation\n> \n> Hi Everyone\n> \n> at the Atlanta meeting the following slides were presented during the\n> federation session\n> \n> http://www.slideshare.net/davidwchadwick/keystone-apach-authn\n> \n> It was acknowledged that the current design is sub-optimal, but was a\n> best first efforts to get something working in time for the IceHouse\n> release, which it did successfully.\n> \n> Now is the time to redesign federated access in Keystone in order to\n> allow for:\n> i) the inclusion of more federation protocols such as OpenID and OpenID\n> Connect via Apache plugins\n> ii) federating together multiple Keystone installations\n> iii) the inclusion of federation protocols directly into Keystone where\n> good Apache plugins dont yet exist e.g. IETF ABFAB\n> \n> The Proposed Design (1) in the slide show is the simplest change to\n> make, in which the Authn module has different plugins for different\n> federation protocols, whether via Apache or not.\n> \n> The Proposed Design (2) is cleaner since the plugins are directly into\n> Keystone and not via the Authn module, but it requires more\n> re-engineering work, and it was questioned in Atlanta whether that\n> effort exists or not.\n> \n> Kent therefore proposes that we go with Proposed Design (1). Kent will\n> provide drafts of the revised APIs and the re-engineered code for\n> inspection and approval by the group, if the group agrees to go with\n> this revised design.\n> \n> If you have any questions about the proposed re-design, please don\'t\n> hesitate to ask\n> \n> regards\n> \n> David and Kristy\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<538607F4.9020401@kent.ac.uk>',NULL),('<1527188.caIsbBe1aB@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-21 11:03:31',3600,'2014-02-21 10:03:31',NULL,'[openstack-dev] [solum] async / threading for python 2 and 3','Le vendredi 21 f?vrier 2014, 09:27:49 Angus Salkeld a ?crit :\n> >Honestly, I have no answer to your question right now (\"How useful is\n> >trollius ...\").\n> >(...) \n> >I asked your question on Tulip mailing list to see how a single code base\n> >could support Tulip (yield from) and Trollius (yield). At least check if\n> >it\'s technically possible.\n\nShort answer: it\'s possible to write code working on Trollius (Python 2 and 3) \n/ Tulip (Python 3.3+) / CPython 3.4 (asyncio) if you use callbacks. The core \nof the asyncio module (event loop and scheduler) uses callbacks. If you only \nuses callbacks, you can also support Twisted and Tornado frameworks.\n\nFor example, the AutobahnPython project adopted this design and thanks to \nthat, it supports Trollius, Tulip and CPython asyncio, but also Twisted:\n\n    https://github.com/tavendo/AutobahnPython\n\nSo you have to find a WSGI server using callbacks instead of \"yield from\". It \nshould not be hard since asyncio is young, callbacks was the only option \nbefore greenlet/eventlet, and Twisted and Tornado (which use callbacks) are \nstill widely used.\n\nVictor\n\n\n','<20140220232749.GA9129@rackspace.com>',NULL),('<1527345982.15.1373954724582.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-16 06:05:24',0,'2013-07-16 06:05:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #288','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/288/>\n\n------------------------------------------\n[...truncated 9008 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.11 secs:\n    0.37    RoleAPITests.test_get_default_role\n    0.24    HorizonTests.test_lazy_urls\n    0.18    DataTableTests.test_summation_row\n    0.16    DataTableTests.test_table_action_attributes\n    0.15    NetworkTests.test_subnet_create_post_gw_inconsistent\n----------------------------------------------------------------------\nRan 350 tests in 7.696s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.dPeF1MaJQi\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/288\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/288/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/288/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<771653337.9.1373868249527.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1527402.GNBzLu5GcH@laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-01 21:26:07',7200,'2014-10-01 19:26:07',NULL,'[openstack-dev] [Openstack] Glance on swift problem','Hello,\n\nThanks for Your help but it not helps. I checked that for sure on each swift \nnode there is a lot of free space. What can confirm that is fact that when I \ntry to create image with size about 1.7GB and I have \nswift_store_large_object_size set to 1GB than there is error (always after \nsend first chunk to swift (200MB). When I only change \nswift_store_large_object_size to 2GB and restart glance-api than the same \nimage is created correctly (it is then in one big object).\n\n---\nBest regards\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\nDnia wtorek, 30 wrze?nia 2014 22:28:11 Timur Nurlygayanov pisze:\n> Hi Slawek,\n> \n> we faced the same error and this is issue with Swift.\n> We can see 100% disk usage on the Swift node during the file upload and\n> looks like Swift can\'t send info about status of the file loading in time.\n> \n> On our environments we found the workaround for this issue:\n> 1. Set  swift_store_large_object_size = 200 in glance.conf.\n> 2. Add to Swift proxy-server.conf:\n> \n> [DEFAULT]\n> ...\n> node_timeout = 90\n> \n> Probably we can set this value as default value for this parameter instead\n> of \'30\'?\n> \n> \n> Regards,\n> Timur\n> \n> \n> On Tue, Sep 30, 2014 at 7:41 PM, S?awek Kap?o?ski <slawek at kaplonski.pl>\n> \n> wrote:\n> > Hello,\n> > \n> > I can\'t find that upload from was previous logs but I now try to upload\n> > same image once again. In glance there was exactly same error. In swift\n> > logs I have:\n> > \n> > Sep 30 17:35:10 127.0.0.1 proxy-server X.X.X.X Y.Y.Y.Y\n> > 30/Sep/2014/15/35/10 HEAD /v1/AUTH_7ef5a7661ccd4c069e3ad387a6dceebd/glance\n> > HTTP/1.0 204\n> > Sep 30 17:35:16 127.0.0.1 proxy-server X.X.X.X Y.Y.Y.Y\n> > 30/Sep/2014/15/35/16 PUT /v1/AUTH_7ef5a7661ccd4c069e3ad387a6dcee\n> > bd/glance/fa5dfe09-74f5-4287-9852-d2f1991eebc0-00001 HTTP/1.0 201 - -\n> > \n> > Best regards\n> > Slawek Kaplonski\n> > \n> > W dniu 2014-09-30 17:03, Kuo Hugo napisa?(a):\n> >> Hi ,\n> >> \n> >> Could you please post the log of related requests in Swift\'s log ???\n> >> \n> >> Thanks // Hugo\n> >> \n> >> 2014-09-30 22:20 GMT+08:00 S?awek Kap?o?ski <slawek at kaplonski.pl>:\n> >>  Hello,\n> >>  \n> >>> I\'m using openstack havana release and glance with swift backend.\n> >>> Today I found that I have problem when I create image with url in\n> >>> \"--copy-from\" when image is bigger than my\n> >>> \"swift_store_large_object_size\" because then glance is trying to\n> >>> split image to chunks with size given in\n> >>> \"swift_store_large_object_chunk_size\" and when try to upload first\n> >>> chunk to swift I have error:\n> >>> \n> >>> 2014-09-30 15:05:29.361 18023 ERROR glance.store.swift [-] Error\n> >>> during chunked upload to backend, deleting stale chunks\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift Traceback\n> >>> (most recent call last):\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift   File\n> >>> \"/usr/lib/python2.7/dist-packages/glance/store/swift.py\", line 384,\n> >>> in add\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n> >>> \n> >>>  content_length=content_length)\n> >>> \n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift   File\n> >>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line 1234,\n> >>> in put_object\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n> >>> \n> >>>  response_dict=response_dict)\n> >>> \n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift   File\n> >>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line 1143,\n> >>> in _retry\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n> >>> \n> >>>  reset_func(func, *args, **kwargs)\n> >>> \n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift   File\n> >>> \"/usr/lib/python2.7/dist-packages/swiftclient/client.py\", line 1215,\n> >>> in _default_reset\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift     %\n> >>> (container, obj))\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n> >>> ClientException: put_object(\'glance\',\n> >>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n> >>> ability to reset contents for reupload.\n> >>> 2014-09-30 15:05:29.361 18023 TRACE glance.store.swift\n> >>> 2014-09-30 15:05:29.362 18023 ERROR glance.store.swift [-] Failed\n> >>> to add object to Swift.\n> >>> Got error from Swift: put_object(\'glance\',\n> >>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n> >>> ability to reset contents for reupload.\n> >>> 2014-09-30 15:05:29.362 18023 ERROR glance.api.v1.upload_utils [-]\n> >>> Failed to upload image 9f56ccec-deeb-4020-95ba-ca7bf1170056\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> Traceback (most recent call last):\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  File\n> >>> \n> >>> \"/usr/lib/python2.7/dist-packages/glance/api/v1/upload_utils.py\",\n> >>> line 101, in upload_data_to_store\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  store)\n> >>> \n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  File \"/usr/lib/python2.7/dist-packages/glance/store/__init__.py\",\n> >>> \n> >>> line 333, in store_add_to_backend\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  (location, size, checksum, metadata) = store.add(image_id, data,\n> >>> \n> >>> size)\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  File \"/usr/lib/python2.7/dist-packages/glance/store/swift.py\",\n> >>> \n> >>> line 447, in add\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> \n> >>>  raise glance.store.BackendException(msg)\n> >>> \n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils\n> >>> BackendException: Failed to add object to Swift.\n> >>> 2014-09-30 15:05:29.362 18023 TRACE glance.api.v1.upload_utils Got\n> >>> error from Swift: put_object(\'glance\',\n> >>> \'9f56ccec-deeb-4020-95ba-ca7bf1170056-00001\', ...) failure and no\n> >>> ability to reset contents for reupload.\n> >>> \n> >>> Does someone of You got same error and know what is solution of it?\n> >>> I was searching about that in google but I not found anything what\n> >>> could solve my problem.\n> >>> \n> >>> --\n> >>> Best regards\n> >>> S?awek Kap?o?ski\n> >>> slawek at kaplonski.pl\n> >>> \n> >>> _______________________________________________\n> >>> Mailing list:\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n> >>> Post to     : openstack at lists.openstack.org\n> >>> Unsubscribe :\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack [1]\n> >> \n> >> Links:\n> >> ------\n> >> [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > \n> > --\n> > Pozdrawiam\n> > S?awek Kap?o?ski\n> > slawek at kaplonski.pl\n> > \n> > _______________________________________________\n> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/\n> > openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/\n> > openstack\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141001/3cac99b7/attachment.pgp>\n\n','<CAHCYybPGcD3fGMec=5Umuak1Fr=PW6kR=bW5QeE+_cKPJKxDVg@mail.gmail.com>',NULL),('<1527544327.67.1383459127668.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:12:07',0,'2013-11-03 06:12:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #43','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/43/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5ce9210>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52c0710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52c0710>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-badec394-938b-4180-bccb-4740b15a117e\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x39439b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x39439b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x39439b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x39439b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:11:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:11:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:11:27+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'27\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:11:27-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'27\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:11:27Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'27\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b6b250>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2600b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 90.79 secs:\n    26.25    TestScrubber.test_scrubber_app\n    20.56    TestScrubber.test_delayed_delete\n    14.81    TestGlanceControl.test_reload\n    14.67    TestGlanceControl.test_bouncing\n    14.49    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 631.585s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.43\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.tGzevjkYuZ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/43/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-4/43\n[SCP] Copying console log.\n\n\n','<713111524.53.1383372949602.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1527609141.3.1376632944184.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-16 06:02:24',0,'2013-08-16 06:02:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-12 in workspace <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/>\nCheckout:periodic-nova-python26-stable-grizzly / <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/> - hudson.remoting.Channel at 1559dca5:centos6-12\nUsing strategy: Default\nLast Built Revision: Revision 37e3b55ad2f9ae581a30927f13442d68364babbc (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 37e3b55ad2f9ae581a30927f13442d68364babbc (origin/stable/grizzly)\nChecking out Revision 37e3b55ad2f9ae581a30927f13442d68364babbc (origin/stable/grizzly)\n[periodic-nova-python26-stable-grizzly] $ /bin/bash -xe /tmp/hudson8824066657474377880.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.7U6w1FZONO\n+ TMPDIR=/tmp/tmp.7U6w1FZONO\n+ trap \'rm -rf /tmp/tmp.7U6w1FZONO\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.5\n+ tox -epy26\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/bin/pip\'),> \'install\', \'--pre\', \'-r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'USERIDCAUSE\', \'HUDSON_URL\': \'https://jenkins02.openstack.org/\', \'BUILD_URL\': \'https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/5/\', \'BUILD_TAG\': \'jenkins-periodic-nova-python26-stable-grizzly-5\', \'SSH_CLIENT\': \'166.78.48.99 54837 22\', \'JENKINS_URL\': \'https://jenkins02.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/\',> \'PATH\': \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/bin>:/usr/local/bin:/bin:/usr/bin\', \'NODE_LABELS\': \'centos6 centos6-12\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-nova-python26-stable-grizzly\', \'ZUUL_PROJECT\': \'openstack/nova\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'NLSPATH\': \'/usr/dt/lib/nls/msg/%L/%N.cat\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'TMPDIR\': \'/tmp/tmp.7U6w1FZONO\', \'DEBEMAIL\': \'hudson at openstack.org\', \'HOME\': \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/tmp/pseudo-home\',> \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'BUILD_ID\': \'2013-08-16_06-00-46\', \'BUILD_NUMBER\': \'5\', \'HUDSON_COOKIE\': \'ae3534d1-6306-4d20-a760-342b601c9999\', \'JOB_URL\': \'https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/\', \'BASE_LOG_PATH\': \'periodic\', \'BUILD_CAUSE_USERIDCAUSE\': \'true\', \'GIT_COMMIT\': \'37e3b55ad2f9ae581a30927f13442d68364babbc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'_\': \'/usr/bin/tox\', \'ZUUL_PIPELINE\': \'periodic\', \'ZUUL_UUID\': \'fb4d682c9f0e47d49254154ce9c8af9d\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'centos6-12\', \'LOG_PATH\': \'periodic/periodic-nova-python26-stable-grizzly/fb4d682\', \'PWD\': \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#5\', \'XFILESEARCHPATH\': \'/usr/dt/app-defaults/%L/Dt\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'166.78.48.99 54837 166.78.18.38 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\', \'GIT_BRANCH\': \'origin/stable/grizzly\'}\nDownloading/unpacking SQLAlchemy>=0.7.8,<0.7.99 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 1))\n  Running setup.py egg_info for package SQLAlchemy\n    warning: no files found matching \'*.jpg\' under directory \'doc\'\n    no previously-included directories found matching \'doc/build/output\'\nDownloading/unpacking Cheetah>=2.4.4 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Cheetah\n    warning: no files found matching \'examples\'\n    warning: no files found matching \'docs\'\n    warning: no files found matching \'bin\'\n    warning: no files found matching \'*\' under directory \'docs\'\n    warning: no files found matching \'*\' under directory \'examples\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'docs\'\nDownloading/unpacking amqplib>=0.6.1 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package amqplib\nDownloading/unpacking anyjson>=0.2.4 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading anyjson-0.3.3.tar.gz\n  Running setup.py egg_info for package anyjson\nDownloading/unpacking argparse (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 5))\n  You are installing an externally hosted file. Future versions of pip will default to disallowing externally hosted files.\n  Running setup.py egg_info for package argparse\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    warning: no previously-included files matching \'*.pyo\' found anywhere in distribution\n    warning: no previously-included files matching \'*.orig\' found anywhere in distribution\n    warning: no previously-included files matching \'*.rej\' found anywhere in distribution\n    no previously-included directories found matching \'doc/_build\'\n    no previously-included directories found matching \'env24\'\n    no previously-included directories found matching \'env25\'\n    no previously-included directories found matching \'env26\'\n    no previously-included directories found matching \'env27\'\nDownloading/unpacking boto (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package boto\n    warning: no files found matching \'boto/mturk/test/*.doctest\'\n    warning: no files found matching \'boto/mturk/test/.gitignore\'\nDownloading/unpacking eventlet>=0.9.17 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking kombu>=1.0.4 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package kombu\nDownloading/unpacking lxml>=2.3 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package lxml\n    /usr/lib64/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'bugtrack_url\'\n      warnings.warn(msg)\n    Building lxml version 3.2.3.\n    Building without Cython.\n    Using build configuration of libxslt 1.1.26\n    Building against libxml2/libxslt in the following directory: /usr/lib64\n    warning: no previously-included files found matching \'*.py\'\n    warning: no files found matching \'*.txt\' under directory \'src/lxml/tests\'\nDownloading/unpacking routes>=1.12.3 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package routes\n    warning: no previously-included files matching \'.DS_Store\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgignore\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgtags\' found anywhere in distribution\nDownloading/unpacking WebOb==1.2.3 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package WebOb\n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Running setup.py egg_info for package greenlet\nDownloading/unpacking PasteDeploy>=1.5.0 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 13))\n  Downloading PasteDeploy-1.5.0.tar.gz\n  Running setup.py egg_info for package PasteDeploy\nDownloading/unpacking paste (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 14))\n  Running setup.py egg_info for package paste\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build/_sources\'\nDownloading/unpacking sqlalchemy-migrate>=0.7.2 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 15))\n  Running setup.py egg_info for package sqlalchemy-migrate\n    warning: no files found matching \'*\' under directory \'tests\'\n    warning: no previously-included files matching \'*pyc\' found anywhere in distribution\n    warning: no previously-included files found matching \'.hgtags\'\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build\'\nDownloading/unpacking netaddr>=0.7.6 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 16))\n  Could not find a version that satisfies the requirement netaddr>=0.7.6 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 16)) (from versions: 0.7.1, 0.6.3, 0.6.2, 0.7.3, 0.7.3, 0.5, 0.6, 0.4, 0.6.4, 0.7.2, 0.6.1, 0.7.2, 0.5.1, 0.6.1, 0.6, 0.6.4, 0.5.2, 0.3.1, 0.7.1, 0.6.3, 0.5, 0.6.2, 0.3.1, 0.7, 0.7, 0.5.1, 0.4, 0.5.2, 0.7.4, 0.7.4, 0.7.3, 0.7.3, 0.7.2, 0.7.2, 0.7.1, 0.7.1, 0.7, 0.7, 0.6.4, 0.6.4, 0.6.3, 0.6.3, 0.6.2, 0.6.2, 0.6.1, 0.6.1, 0.6, 0.6, 0.5.2, 0.5.2, 0.5.1, 0.5.1, 0.5, 0.5, 0.4, 0.4, 0.3.1, 0.3.1, 0.3, 0.3, 0.2, 0.1)\nCleaning up...\nNo distributions matching the version for netaddr>=0.7.6 (from -r <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires> (line 16))\nStoring complete log in <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/tmp/pseudo-home/.pip/pip.log>\n\nERROR: could not install deps [-r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.7U6w1FZONO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly/centos6-12/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1528277932.59.1379225559403.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-15 06:12:39',0,'2013-09-15 06:12:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-grizzly #21','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/21/>\n\n------------------------------------------\n[...truncated 31 lines...]\n+ TMPDIR=/tmp/tmp.EP9xiKkwq2\n+ trap \'rm -rf /tmp/tmp.EP9xiKkwq2\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' nova == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.21\n+ tox -epy26\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires>\npy26 inst: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.21.zip>\npy26 runtests: commands[0] | python tools/patch_tox_venv.py\npy26 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.EP9xiKkwq2/tmpZo7ayN\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.EP9xiKkwq2/tmpUIlFa2\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.EP9xiKkwq2/tmpv0KnHG\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.EP9xiKkwq2/tmp0zKhFH\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\ntags: worker-2\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group idufsi\n0.77816s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nCreate Security Group anqdsq\n0.65673s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress idufsi\n0.131657s None GET /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64]  text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 582, in test_authorize_revoke_security_group_foreign_group\n    group.authorize(src_group=other_group)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group uraseda\n0.71749s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress uraseda\n0.109291s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 419, in test_authorize_revoke_security_group_cidr\n    group.authorize(\'tcp\', 80, 81, \'0.0.0.0/0\')\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group iafpust\n0.69214s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress iafpust\n0.105358s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 521, in test_authorize_revoke_security_group_cidr_v6\n    group.authorize(\'tcp\', 80, 81, \'::/0\')\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11310 tests in 439.745s\nFAILED (id=0, failures=5, skips=13)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.21\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.11\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nunittest2==0.5.1\nwarlock==1.0.1\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py26/bin/subunit-1to2\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.EP9xiKkwq2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly/centos6-2/21\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1528528318.0.1370498890582.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-06 06:08:10',0,'2013-06-06 06:08:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-folsom #248','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/248/>\n\n------------------------------------------\n[...truncated 56 lines...]\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/248/\', \'BUILD_TAG\': \'jenkins-periodic-nova-python27-stable-folsom-248\', \'SSH_CLIENT\': \'198.101.231.203 60773 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-nova-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1370456916.808503-1144370449\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise1\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.l5xonGRdnZ\', \'DEBEMAIL\': \'hudson at openstack.org\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'BUILD_ID\': \'2013-06-06_06-05-15\', \'BUILD_NUMBER\': \'248\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'2ea500ae-091a-4fab-891f-89e5013bad7c\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'2fcd06c3c2dbfb7a91b93ac3d2b915849c165d0c\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise1\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#248\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 60773 64.49.246.243 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking SQLAlchemy>=0.7.8,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Running setup.py egg_info for package SQLAlchemy\n    \n    warning: no files found matching \'*.jpg\' under directory \'doc\'\n    no previously-included directories found matching \'doc/build/output\'\nDownloading/unpacking Cheetah==2.4.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Cheetah\n    \n    warning: no files found matching \'examples\'\n    warning: no files found matching \'docs\'\n    warning: no files found matching \'bin\'\n    warning: no files found matching \'*\' under directory \'docs\'\n    warning: no files found matching \'*\' under directory \'examples\'\n    warning: no previously-included files matching \'*.pyc\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'cheetah\'\n    warning: no previously-included files matching \'*~\' found under directory \'docs\'\n    warning: no previously-included files matching \'*.aux\' found under directory \'docs\'\nDownloading/unpacking amqplib==0.6.1 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package amqplib\n    \nDownloading/unpacking anyjson==0.2.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading anyjson-0.2.4.tar.gz\n  Running setup.py egg_info for package anyjson\n    \nDownloading/unpacking boto==2.1.1 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package boto\n    \nDownloading/unpacking eventlet>=0.9.17 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking kombu==1.0.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package kombu\n    \nDownloading/unpacking lxml>=2.3,<=2.3.5 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package lxml\n    Building lxml version 2.3.5.\n    Building without Cython.\n    Using build configuration of libxslt 1.1.26\n    Building against libxml2/libxslt in the following directory: /usr/lib/x86_64-linux-gnu\n    \n    warning: no previously-included files found matching \'*.py\'\nDownloading/unpacking routes==1.12.3 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 9))\n  Real name of requirement routes is Routes\n  Running setup.py egg_info for package routes\n    \n    warning: no previously-included files matching \'.DS_Store\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgignore\' found anywhere in distribution\n    warning: no previously-included files matching \'*.hgtags\' found anywhere in distribution\nDownloading/unpacking WebOb==1.0.8 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package greenlet\n    \nDownloading/unpacking PasteDeploy==1.5.0 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 12))\n  Downloading PasteDeploy-1.5.0.tar.gz\n  Running setup.py egg_info for package PasteDeploy\n    \nDownloading/unpacking paste (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 13))\n  Real name of requirement paste is Paste\n  Running setup.py egg_info for package paste\n    \n    warning: no previously-included files matching \'*\' found under directory \'docs/_build/_sources\'\nDownloading/unpacking sqlalchemy-migrate>=0.7.2 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 14))\n  Running setup.py egg_info for package sqlalchemy-migrate\n    \n    warning: no files found matching \'*\' under directory \'tests\'\n    warning: no previously-included files matching \'*pyc\' found anywhere in distribution\n    warning: no previously-included files found matching \'.hgtags\'\n    warning: no previously-included files matching \'*\' found under directory \'docs/_build\'\nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 15))\n  Running setup.py egg_info for package netaddr\n    \n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking suds==0.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 16))\n  Running setup.py egg_info for package suds\n    \nDownloading/unpacking paramiko (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 17))\n  Running setup.py egg_info for package paramiko\n    \nDownloading/unpacking Babel>=0.9.6 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 18))\n  Running setup.py egg_info for package Babel\n    \nDownloading/unpacking iso8601>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 19))\n  Downloading iso8601-0.1.4.tar.gz\n  Running setup.py egg_info for package iso8601\n    \nDownloading/unpacking httplib2 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 20))\n  Running setup.py egg_info for package httplib2\n    \nDownloading/unpacking setuptools-git>=0.4 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 21))\n  Real name of requirement setuptools_git is setuptools-git\n  Downloading setuptools-git-1.0b1.tar.gz\n  Running setup.py egg_info for package setuptools-git\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \nDownloading/unpacking python-quantumclient>=2.1 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 22))\n  Running setup.py egg_info for package python-quantumclient\n    \nDownloading/unpacking python-glanceclient>=0.5.0,<2 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 23))\n  Running setup.py egg_info for package python-glanceclient\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/build/python-glanceclient/setuptools_git-1.0b1-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nRequirement already satisfied (use --upgrade to upgrade): distribute>=0.6.24 in <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg> (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 2))\nDownloading/unpacking coverage (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 4))\n  Running setup.py egg_info for package coverage\n    \n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\nDownloading/unpacking mox==0.5.3 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 5))\n  Downloading mox-0.5.3.tar.gz\n  Running setup.py egg_info for package mox\n    \nDownloading/unpacking nose<1.3.0 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 6))\n  Running setup.py egg_info for package nose\n    \n    no previously-included directories found matching \'doc/.build\'\nDownloading/unpacking openstack.nose-plugin>=0.7 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 7))\n  Downloading openstack.nose_plugin-0.11.tar.gz\n  Running setup.py egg_info for package openstack.nose-plugin\n    \nDownloading/unpacking nosehtmloutput (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 8))\n  Downloading nosehtmloutput-0.0.4.tar.gz\n  Running setup.py egg_info for package nosehtmloutput\n    no previously-included directories found matching \'doc/.build\'\n    \n    Installed <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/build/nosehtmloutput/nose-1.3.0-py2.7.egg>\n    \nDownloading/unpacking pep8==1.1 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 9))\n  Downloading pep8-1.1.tar.gz\n  Running setup.py egg_info for package pep8\n    \nDownloading/unpacking pylint==0.25.2 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 10))\n  Running setup.py egg_info for package pylint\n    \n    package init file \'./test/__init__.py\' not found (or not a regular file)\n    warning: no files found matching \'*.html\' under directory \'doc\'\n    warning: no files found matching \'*.txt2\' under directory \'test\'\n    warning: no files found matching \'noext\'\nDownloading/unpacking sphinx>=1.1.2 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 11))\n  Real name of requirement sphinx is Sphinx\n  Running setup.py egg_info for package sphinx\n    \n    warning: no files found matching \'README\'\n    no previously-included directories found matching \'doc/_build\'\nDownloading/unpacking feedparser (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 12))\n  Running setup.py egg_info for package feedparser\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires> (line 13))\n  Running setup.py egg_info for package python-cinderclient\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer\'\n      warnings.warn(msg)\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'mainainer_email\'\n      warnings.warn(msg)\n    \n    Installed <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/build/python-cinderclient/setuptools_git-1.0b1-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking Markdown>=2.0.1 (from Cheetah==2.4.4->-r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Markdown\n    \nDownloading/unpacking decorator (from sqlalchemy-migrate>=0.7.2->-r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires> (line 14))\n  Error <urlopen error timed out> while getting http://pypi.openstack.org/openstack/decorator/decorator-3.4.0.tar.gz (from http://pypi.openstack.org/openstack/decorator/)\nException:\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/basecommand.py\",> line 139, in main\n    status = self.run(options, args)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/commands/install.py\",> line 266, in run\n    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/req.py\",> line 1033, in prepare_files\n    self.unpack_url(url, location, self.is_download)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/req.py\",> line 1161, in unpack_url\n    retval = unpack_http_url(link, location, self.download_cache, self.download_dir)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/download.py\",> line 534, in unpack_http_url\n    resp = _get_response_from_url(target_url, link)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/download.py\",> line 569, in _get_response_from_url\n    resp = urlopen(target_url)\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/download.py\",> line 143, in __call__\n    response = self.get_opener(scheme=scheme).open(url)\n  File \"/usr/lib/python2.7/urllib2.py\", line 400, in open\n    response = self._open(req, data)\n  File \"/usr/lib/python2.7/urllib2.py\", line 418, in _open\n    \'_open\', req)\n  File \"/usr/lib/python2.7/urllib2.py\", line 378, in _call_chain\n    result = func(*args)\n  File \"/usr/lib/python2.7/urllib2.py\", line 1207, in http_open\n    return self.do_open(httplib.HTTPConnection, req)\n  File \"/usr/lib/python2.7/urllib2.py\", line 1177, in do_open\n    raise URLError(err)\nURLError: <urlopen error timed out>\n\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.l5xonGRdnZ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-folsom/248\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1529111176.858501.1345832618639.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-24 11:23:38',-25200,'2012-08-24 18:23:38',NULL,'[openstack-dev] Discussion about where to put database\n	for	bare-metal provisioning (review 10726)','\n?Vish,\n\n?I\'ve tested your code and did more testing.\nThere are a couple of problems.\n1. host name should be unique. If not, any repetitive updates of new capabilities with the same host name are simply overwritten.\n2. We cannot generate arbitrary host names on the fly.\n??The scheduler (I tested filter scheduler) gets host names from db.\n??So, if a host name is not in the \'services\' table, it is not considered by the scheduler at all.\n\nSo, to make your suggestions possible, nova-compute should register N different host names in \'services\' table,\nand N corresponding entries in \'compute_nodes\' table.\nHere is an example:\n\nmysql> select id, host, binary, topic, report_count, disabled, availability_zone from services;\n+----+-------------+----------------+-----------+--------------+----------+-------------------+\n| id | host ? ? ? ?| binary ? ? ? ? | topic ? ? | report_count | disabled | availability_zone |\n+----+-------------+----------------+-----------+--------------+----------+-------------------+\n| ?1 | bespin101 ? | nova-scheduler | scheduler | ? ? ? ?17145 | ? ? ? ?0 | nova ? ? ? ? ? ? ?|\n| ?2 | bespin101 ? | nova-network ? | network ? | ? ? ? ?16819 | ? ? ? ?0 | nova ? ? ? ? ? ? ?|\n| ?3 | bespin101-0 | nova-compute ? | compute ? | ? ? ? ?16405 | ? ? ? ?0 | nova ? ? ? ? ? ? ?|\n| ?4 | bespin101-1 | nova-compute ? | compute ? | ? ? ? ? ? ?1 | ? ? ? ?0 | nova ? ? ? ? ? ? ?|\n+----+-------------+----------------+-----------+--------------+----------+-------------------+\n\nmysql> select id, service_id, hypervisor_hostname from compute_nodes;\n+----+------------+------------------------+\n| id | service_id | hypervisor_hostname ? ?|\n+----+------------+------------------------+\n| ?1 | ? ? ? ? ?3 | bespin101.east.isi.edu |\n| ?2 | ? ? ? ? ?4 | bespin101.east.isi.edu |\n+----+------------+------------------------+\n\n?Then, nova db (compute_nodes table) has entries of all bare-metal nodes.\nWhat do you think of this approach.\nDo you have any better approach?\n\n?Thanks,\n?David\n\n\n\n----- Original Message -----\n> To elaborate, something the below. I\'m not absolutely sure you need to\n> be able to set service_name and host, but this gives you the option to\n> do so if needed.\n> \n> iff --git a/nova/manager.py b/nova/manager.py\n> index c6711aa..c0f4669 100644\n> --- a/nova/manager.py\n> +++ b/nova/manager.py\n> @@ -217,6 +217,8 @@ class SchedulerDependentManager(Manager):\n> \n> def update_service_capabilities(self, capabilities):\n> \"\"\"Remember these capabilities to send on next periodic update.\"\"\"\n> + if not isinstance(capabilities, list):\n> + capabilities = [capabilities]\n> self.last_capabilities = capabilities\n> \n> @periodic_task\n> @@ -224,5 +226,8 @@ class SchedulerDependentManager(Manager):\n> \"\"\"Pass data back to the scheduler at a periodic interval.\"\"\"\n> if self.last_capabilities:\n> LOG.debug(_(\'Notifying Schedulers of capabilities ...\'))\n> - self.scheduler_rpcapi.update_service_capabilities(context,\n> - self.service_name, self.host, self.last_capabilities)\n> + for capability_item in self.last_capabilities:\n> + name = capability_item.get(\'service_name\', self.service_name)\n> + host = capability_item.get(\'host\', self.host)\n> + self.scheduler_rpcapi.update_service_capabilities(context,\n> + name, host, capability_item)\n> \n> On Aug 21, 2012, at 1:28 PM, David Kang <dkang at isi.edu> wrote:\n> \n> >\n> > ?Hi Vish,\n> >\n> > ?We are trying to change our code according to your comment.\n> > I want to ask a question.\n> >\n> >>>> a) modify driver.get_host_stats to be able to return a list of\n> >>>> host\n> >>>> stats instead of just one. Report the whole list back to the\n> >>>> scheduler. We could modify the receiving end to accept a list as\n> >>>> well\n> >>>> or just make multiple calls to\n> >>>> self.update_service_capabilities(capabilities)\n> >\n> > ?Modifying driver.get_host_stats to return a list of host stats is\n> > ?easy.\n> > Calling muliple calls to\n> > self.update_service_capabilities(capabilities) doesn\'t seem to work,\n> > because \'capabilities\' is overwritten each time.\n> >\n> > ?Modifying the receiving end to accept a list seems to be easy.\n> > However, \'capabilities\' is assumed to be dictionary by all other\n> > scheduler routines,\n> > it looks like that we have to change all of them to handle\n> > \'capability\' as a list of dictionary.\n> >\n> > ?If my understanding is correct, it would affect many parts of the\n> > ?scheduler.\n> > Is it what you recommended?\n> >\n> > ?Thanks,\n> > ?David\n> >\n> >\n> > ----- Original Message -----\n> >> This was an immediate goal, the bare-metal nova-compute node could\n> >> keep an internal database, but report capabilities through nova in\n> >> the\n> >> common way with the changes below. Then the scheduler wouldn\'t need\n> >> access to the bare metal database at all.\n> >>\n> >> On Aug 15, 2012, at 4:23 PM, David Kang <dkang at isi.edu> wrote:\n> >>\n> >>>\n> >>> Hi Vish,\n> >>>\n> >>> Is this discussion for long-term goal or for this Folsom release?\n> >>>\n> >>> We still believe that bare-metal database is needed\n> >>> because there is not an automated way how bare-metal nodes report\n> >>> their capabilities\n> >>> to their bare-metal nova-compute node.\n> >>>\n> >>> Thanks,\n> >>> David\n> >>>\n> >>>>\n> >>>> I am interested in finding a solution that enables bare-metal and\n> >>>> virtualized requests to be serviced through the same scheduler\n> >>>> where\n> >>>> the compute_nodes table has a full view of schedulable resources.\n> >>>> This\n> >>>> would seem to simplify the end-to-end flow while opening up some\n> >>>> additional use cases (e.g. dynamic allocation of a node from\n> >>>> bare-metal to hypervisor and back).\n> >>>>\n> >>>> One approach would be to have a proxy running a single\n> >>>> nova-compute\n> >>>> daemon fronting the bare-metal nodes . That nova-compute daemon\n> >>>> would\n> >>>> report up many HostState objects (1 per bare-metal node) to\n> >>>> become\n> >>>> entries in the compute_nodes table and accessible through the\n> >>>> scheduler HostManager object.\n> >>>>\n> >>>>\n> >>>>\n> >>>>\n> >>>> The HostState object would set cpu_info, vcpus, member_mb and\n> >>>> local_gb\n> >>>> values to be used for scheduling with the hypervisor_host field\n> >>>> holding the bare-metal machine address (e.g. for IPMI based\n> >>>> commands)\n> >>>> and hypervisor_type = NONE. The bare-metal Flavors are created\n> >>>> with\n> >>>> an\n> >>>> extra_spec of hypervisor_type= NONE and the corresponding\n> >>>> compute_capabilities_filter would reduce the available hosts to\n> >>>> those\n> >>>> bare_metal nodes. The scheduler would need to understand that\n> >>>> hypervisor_type = NONE means you need an exact fit (or best-fit)\n> >>>> host\n> >>>> vs weighting them (perhaps through the multi-scheduler). The\n> >>>> scheduler\n> >>>> would cast out the message to the <topic>.<service-hostname>\n> >>>> (code\n> >>>> today uses the HostState hostname), with the compute driver\n> >>>> having\n> >>>> to\n> >>>> understand if it must be serviced elsewhere (but does not break\n> >>>> any\n> >>>> existing implementations since it is 1 to 1).\n> >>>>\n> >>>>\n> >>>>\n> >>>>\n> >>>>\n> >>>> Does this solution seem workable? Anything I missed?\n> >>>>\n> >>>> The bare metal driver already is proxying for the other nodes so\n> >>>> it\n> >>>> sounds like we need a couple of things to make this happen:\n> >>>>\n> >>>>\n> >>>> a) modify driver.get_host_stats to be able to return a list of\n> >>>> host\n> >>>> stats instead of just one. Report the whole list back to the\n> >>>> scheduler. We could modify the receiving end to accept a list as\n> >>>> well\n> >>>> or just make multiple calls to\n> >>>> self.update_service_capabilities(capabilities)\n> >>>>\n> >>>>\n> >>>> b) make a few minor changes to the scheduler to make sure\n> >>>> filtering\n> >>>> still works. Note the changes here may be very helpful:\n> >>>>\n> >>>>\n> >>>> https://review.openstack.org/10327\n> >>>>\n> >>>>\n> >>>> c) we have to make sure that instances launched on those nodes\n> >>>> take\n> >>>> up\n> >>>> the entire host state somehow. We could probably do this by\n> >>>> making\n> >>>> sure that the instance_type ram, mb, gb etc. matches what the\n> >>>> node\n> >>>> has, but we may want a new boolean field \"used\" if those aren\'t\n> >>>> sufficient.\n> >>>>\n> >>>>\n> >>>> I This approach seems pretty good. We could potentially get rid\n> >>>> of\n> >>>> the\n> >>>> shared bare_metal_node table. I guess the only other concern is\n> >>>> how\n> >>>> you populate the capabilities that the bare metal nodes are\n> >>>> reporting.\n> >>>> I guess an api extension that rpcs to a baremetal node to add the\n> >>>> node. Maybe someday this could be autogenerated by the bare metal\n> >>>> host\n> >>>> looking in its arp table for dhcp requests! :)\n> >>>>\n> >>>>\n> >>>> Vish\n> >>>>\n> >>>> _______________________________________________\n> >>>> OpenStack-dev mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1D7088E5-0D11-4DE6-9B88-D45338B3F544@gmail.com>',NULL),('<1529359307.68657.1394011342151.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-05 17:22:20',28800,'2014-03-05 09:22:20',NULL,'[openstack-dev] [nova] Questions about guest\n	NUMA	and	memory	binding policies','Hi Liuji, \n\nI\'m the owner of bp support-libvirt-vcpu-topology, \nThere are four main reasons that I did not continue to work on it: \n1. the design proposal has not confirmed by core developers of nova \n2. this bp is not accepted in Icehouse development stage \n3. Daniel expects that this bp should consider together with the other one numa-aware-cpu-binding, but I have no idea to do this for now \n4. I have no enough time to do this at this moment \n\n2014-03-05\n\n\n\nWangpan\n\n\n\n????\"Liuji (Jeremy)\" <jeremy.liu at huawei.com>\n?????2014-03-05 15:02\n???Re: [openstack-dev] [nova] Questions about guest NUMA and memory binding policies\n????\"OpenStack Development Mailing List (not for usage questions)\"<openstack-dev at lists.openstack.org>\n???\"Luohao \\(brian\\)\"<brian.luohao at huawei.com>,\"Yuanjing \\(D\\)\"<yj.yuan at huawei.com>\n\nHi Steve, \n\nThanks for your reply. \n\nI didn\'t know why the blueprint numa-aware-cpu-binding seems to have no more progress until read the two mails mentioned in your mail. \n\nThe use case analysis in the mails are very clear, they are also what I concern about. \nI agree that we shouldn\'t provide pCPU/vCPU mapping for the ending user and how to provide them for the user need more consideration.  \n\nThe use cases I concern more are the pCPU\'s exclusively use(pCPU:vCPU=1:1) and the guest numa. \n\n\nThanks, \nJeremy Liu \n\n\n> -----Original Message----- \n> From: Steve Gordon [mailto:sgordon at redhat.com] \n> Sent: Tuesday, March 04, 2014 10:29 AM \n> To: OpenStack Development Mailing List (not for usage questions) \n> Cc: Luohao (brian); Yuanjing (D) \n> Subject: Re: [openstack-dev] [nova] Questions about guest NUMA and memory \n> binding policies \n>  \n> ----- Original Message ----- \n> > Hi, all \n> > \n> > I search the current blueprints and old mails in the mail list, but \n> > find nothing about Guest NUMA and setting memory binding policies. \n> > I just find a blueprint about vcpu topology and a blueprint about CPU \n> > binding. \n> > \n> > https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topol \n> > ogy https://blueprints.launchpad.net/nova/+spec/numa-aware-cpu-binding \n> > \n> > Is there any plan for the guest NUMA and memory binding policies setting? \n> > \n> > Thanks, \n> > Jeremy Liu \n>  \n> Hi Jeremy, \n>  \n> As you\'ve discovered there have been a few attempts at getting some work \n> started in this area. Dan Berrange outlined some of the possibilities in this area \n> in a previous mailing list post [1] though it\'s multi-faceted, there are a lot of \n> different ways to break it down. If you dig into the details you will note that the \n> support-libvirt-vcpu-topology blueprint in particular got a fair way along but \n> there were some concerns noted in the code reviews and on the list [2] around \n> the design. \n>  \n> It seems like this is an area that there is a decent amount of interest in and we \n> should work on list to flesh out a design proposal, ideally this would be \n> presented for further discussion at the Juno design summit. What are your \n> particular needs/desires from a NUMA aware nova scheduler? \n>  \n> Thanks, \n>  \n> Steve \n>  \n> [1] \n> http://lists.openstack.org/pipermail/openstack-dev/2013-November/019715.h \n> tml \n> [2] \n> http://lists.openstack.org/pipermail/openstack-dev/2013-December/022940.h \n> tml \n>  \n> _______________________________________________ \n> OpenStack-dev mailing list \n> OpenStack-dev at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140305/1eb5a9ad/attachment.html>\n\n','<3353B972624C8B49AB43F74428B4701D5D0B0521@SZXEMA512-MBX.china.huawei.com>',NULL),('<1529724177.9156771.1394705608470.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 11:13:28',3600,'2014-03-13 10:13:28',NULL,'[openstack-dev] [heat][neutron] OS::Heat::AutoScalingGroup\n	and	OS::Neutron::PoolMember?','\n> Has anybody exercised the case of OS::Heat::AutoScalingGroup scaling a nested\n> stack that includes a OS::Neutron::PoolMember? Should I expect this to work?\n\nHi Mike,\n\nYes I tested it and it works. I\'m trying to build an example for heat-templates putting it all together. I\'m mostly struggling with how to include the nested stack nicely (without a HTTP URL), but everything else seems fine.\n\nCheers,\n\n-- \nThomas\n\n\n','<OFEE141A97.3AA5D0D8-ON85257C99.0065E1AC-85257C99.0066143D@us.ibm.com>',NULL),('<152C56E4-DE15-478D-862D-C0F635B4ECCC@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-20 05:01:23',0,'2013-10-20 05:01:23',NULL,'[openstack-dev] Gerrit tools','I created some gerrit tools that I think others might find useful.\n\nhttps://github.com/harlowja/gerrit_view\n\nThe neat one there is a curses based real time gerrit review receiver that uses a similar mechanism as the gerrit irc bot to sit on the gerrit event queue and receive events.\n\nSo no longer will u web browser haters (and console lovers) have to refresh to see changes. Haha.\n\nHopefully it works for u guys :)\n\nPull requests welcome too :)\n\nSent from my really tiny device...\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131020/d2325b8b/attachment.html>\n\n',NULL,NULL),('<1530056143.286.1368684844189.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-16 06:14:04',0,'2013-05-16 06:14:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #227','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/227/>\n\n\n\n','<1658506120.282.1368598446727.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1531319585.68.1383459146555.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:12:26',0,'2013-11-03 06:12:26',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-nova-python27-stable-grizzly #40','See <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/40/>\n\n\n\n','<1937544771.48.1383372528565.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1531786351.598385.1351871877884.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 11:57:57',-14400,'2012-11-02 15:57:57',NULL,'[openstack-dev] [ceilometer] database timestamps timezones','\n\n> > Looking over https://bugs.launchpad.net/ceilometer/+bug/1048647,\n> > we\'d\n> > like some feedback on timezone aware datetimes for the timestamp\n> > fields (in Meters and Resources tables).  From what I understand,\n> > some\n> > backends do not support timezone in timestamp type fields , such as\n> > MongoDB and Postgres.  I think the way Nova handles it is that it\n> > expects all timestamps in the database is expected to be UTC.\n> \n> Postgres actually has separate types for timestamp without time zone\n> and\n> timestamp with time zone.\n> \n> But I think it makes a lot more sense to just use UTC timestamps\n> everywhere, rather than using timezone-aware timestamps which will\n> involve more database-specific code.  If you care about the user\'s\n> timezone, you can put it in a separate column.\n\nTotally agree about standardizing on UTC ... having lived with\nsystems using TZ-specific timestamps, its a never-ending saga of\nconfusion & pain.\n\nCheers,\nEoghan\n\n\n','<5093E66F.4010505@redhat.com>',NULL),('<153182312.17.1380612650245.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-01 07:30:50',0,'2013-10-01 07:30:50',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-coverage #29','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/29/>\n\n\n\n','<897312643.5.1380349736038.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1532045009.44.1355875463660.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-19 00:04:24',0,'2012-12-19 00:04:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #79','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/79/>\n\n------------------------------------------\n[...truncated 2286 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/79\n[SCP] Copying console log.\n\n\n','<1909239334.28.1355789062510.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1532123667.24908225.1384940093136.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-20 04:34:53',-18000,'2013-11-20 09:34:53',NULL,'[Openstack] [openstack][ceilometer] Periodic checks error\n	on	Compute node with ceilometer','\nHi Jean-Daniel,\n\nThat doesn\'t look like a ceilometer issue.\n\nRather, IIUC it\'s a case of the nova-compute agent reporting an issue\nfrom the nova-conductor service when it calls out to the conductor over\nRPC to record the beginning of a task in the task log.\n\nInterestingly, the error message seems to suggest that the nova-conductor\nis using sqlite:\n\n  DBError SQLite DateTime type only accepts Python datetime and date objects as input.\n\nwhereas the nova.conf you quote suggests that mysql is in use:\n\n  connection = mysql://nova:password at infra-eval-03/nova\n\nPlease check the config used by your nova-conductor service, as the\nsame DB should be configured for the nova services across the board.\n\nCheers,\nEoghan  \n\n----- Original Message -----\n> ?? Hi stackers!\n> \n> When integrating ceilometer I experience periodic task errors on a compute\n> node.\n> I paste below my configurations, if anyone has experienced this or a clue of\n> what could be the cause info would be very helpful.\n> \n> The error output is:\n> nova-compute.log======================================\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> Traceback (most recent call last):\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/periodic_task.py\",\n> line 180, in run_periodic_tasks\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> task(self, context)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 4495, in\n> _instance_usage_audit\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> self.host, num_instances)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/compute/utils.py\", line 372, in\n> start_instance_usage_audit\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> \"Instance usage audit started...\")\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/conductor/api.py\", line 279, in\n> task_log_begin_task\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> task_items, message)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/conductor/rpcapi.py\", line 411, in\n> task_log_begin_task\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> task_items=task_items, message=message)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/rpcclient.py\", line 85, in call\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> return self._invoke(self.proxy.call, ctxt, method, **kwargs)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/rpcclient.py\", line 63, in _invoke\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> return cast_or_call(ctxt, msg, **self.kwargs)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/proxy.py\", line\n> 126, in call\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> result = rpc.call(context, real_topic, msg, timeout)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/__init__.py\",\n> line 139, in call\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> return _get_impl().call(CONF, context, topic, msg, timeout)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py\",\n> line 816, in call\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> rpc_amqp.get_connection_pool(conf, Connection))\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line\n> 574, in call\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task rv =\n> list(rv)\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line\n> 539, in __iter__\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task raise\n> result\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> RemoteError: Remote error: DBError SQLite DateTime type only accepts Python\n> datetime and date objects as input. (original cause: TypeError: SQLite\n> DateTime type only accepts Python datetime and date objects as input.)\n> \'INSERT INTO task_log (created_at, updated_at, deleted_at, deleted,\n> task_name, state, host, period_beginning, period_ending, message,\n> task_items, errors) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)\'\n> [{\'period_ending\': u\'2013-11-20T06:00:00.000000\', \'state\': \'RUNNING\',\n> \'updated_at\': None, \'host\': u\'infra-eval-06\', \'task_items\': 2, \'task_name\':\n> u\'instance_usage_audit\', \'period_beginning\': u\'2013-11-20T05:00:00.000000\',\n> \'message\': u\'Instance usage audit started...\', \'deleted_at\': None}]\n> 2013-11-20 15:01:46.068 22480 TRACE nova.openstack.common.periodic_task\n> [u\'Traceback (most recent call last):\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py\", line\n> 461, in _process_data\\n **args)\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py\",\n> line 172, in dispatch\\n result = getattr(proxyobj, method)(ctxt,\n> **kwargs)\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/conductor/manager.py\", line 471, in\n> task_log_begin_task\\n message)\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/db/api.py\", line 1891, in\n> task_log_begin_task\\n message)\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 108, in\n> wrapper\\n return f(*args, **kwargs)\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 5435, in\n> task_log_begin_task\\n task.save()\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/models.py\",\n> line 53, in save\\n session.flush()\\n\', u\' File\n> \"/usr/lib/python2.7/dist-packages/nova/openstack/common/db/sqlalchemy/session.py\",\n> line 543, in _wrap\\n raise exception.DBError(e)\\n\', u\"DBError: SQLite\n> DateTime type only accepts Python datetime and date objects as input.\n> (original cause: TypeError: SQLite DateTime type only accepts Python\n> datetime and date objects as input.) \'INSERT INTO task_log (created_at,\n> updated_at, deleted_at, deleted, task_name, state, host, period_beginning,\n> period_ending, message, task_items, errors) VALUES (?, ?, ?, ?, ?, ?, ?, ?,\n> ?, ?, ?, ?)\' [{\'period_ending\': u\'2013-11-20T06:00:00.000000\', \'state\':\n> \'RUNNING\', \'updated_at\': None, \'host\': u\'infra-eval-06\', \'task_items\': 2,\n> \'task_name\': u\'instance_usage_audit\', \'period_beginning\':\n> u\'2013-11-20T05:00:00.000000\', \'message\': u\'Instance usage audit\n> started...\', \'deleted_at\': None}]\\n\"].\n> ?===========================================?\n> \n> My nova.conf is:\n> nova.conf?===========================================?\n> [DEFAULT]\n> dhcpbridge_flagfile=/etc/nova/nova.conf\n> dhcpbridge=/usr/bin/nova-dhcpbridge\n> logdir=/var/log/nova\n> state_path=/var/lib/nova\n> lock_path=/var/lock/nova\n> force_dhcp_release=True\n> iscsi_helper=tgtadm\n> libvirt_use_virtio_for_bridges=True\n> connection_type=libvirt\n> root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf\n> verbose=False\n> debug=False\n> ec2_private_dns_show_ip=True\n> api_paste_config=/etc/nova/api-paste.ini\n> volumes_path=/var/lib/nova/volumes\n> enabled_apis=ec2,osapi_compute,metadata\n> connection = mysql://nova:password at infra-eval-03/nova\n> my_ip=192.168.1.26\n> vncserver_listen=0.0.0.0\n> vncserver_proxyclient_address=172.16.1.16\n> rpc_backend = nova.rpc.impl_kombu\n> rabbit_host = infra-eval-03\n> glance_host = infra-eval-03\n> network_api_class=nova.network.neutronv2.api.API\n> neutron_url= http://infra-eval-03:9696\n> neutron_auth_strategy=keystone\n> neutron_admin_tenant_name=service\n> neutron_admin_username=neutron\n> neutron_admin_password=password\n> neutron_admin_auth_url= http://infra-eval-03:35357/v2.0\n> firewall_driver=nova.virt.firewall.NoopFirewallDriver\n> ??===========================================?\n> \n> My ceilometer conf file is:\n> ceilometer.conf?===========================================?\n> [DEFAULT]\n> sqlite_db=ceilometer.sqlite\n> log_dir=/var/log/ceilometer\n> rabbit_host=infra-eval-03\n> [publisher_rpc]\n> metering_secret=password\n> [ssl]\n> [database]\n> connection = mongodb://ceilometer:password at infra-eval-03:27017/ceilometer\n> [alarm]\n> [rpc_notifier2]\n> [api]\n> [service_credentials]\n> [dispatcher_file]\n> [keystone_authtoken]\n> auth_host = infra-eval-03\n> auth_port = 35357\n> auth_protocol = http\n> admin_tenant_name = service\n> admin_user = ceilometer\n> admin_password = password\n> auth_uri = http://192.168.1.23:5000\n> [collector]\n> [matchmaker_ring]\n> [matchmaker_redis]\n> ?===========================================??\n> \n> regards\n> \n> \n> BUSSY Jean-Daniel\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n','<CANB=HGgt4t-ZtJfVGg1OEZ+f6ivyxqmHFSCt-ahDd=wzfGr=9A@mail.gmail.com>',NULL),('<1532641472.30247301.1376404920599.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-13 07:42:00',-25200,'2013-08-13 14:42:00',NULL,'[Openstack] Fwd: [vmwareapi] Could we distribute wsdl files\n from	vSphere SDK?','Hi,\n\nCould someone direct me to how to fix the official docs? I\'ll do that *today*... it\'s on my to-do list anyway.\n\nI wrote this up: https://wiki.openstack.org/wiki/NovaVMware/Documentation#SOAP_WSDL_issues\n\nTo explain things. The official documentation is actually wrong. You don\'t need to download the SDK unless you are using version 5.0 ... as for licensing, the SDK is protected behind this link http://www.vmware.com/support/developer/vc-sdk/ which forces you through some EULA. You can skip this step if you just pull the SDK from your ESXi or vCenter host directly (whomever installed the server will have clicked through the EULA).\n\nIt would probably be best to not distribute the WSDL with the driver code since there are only a few corner cases when you should need to do that and hopefully the versions of vSphere that will need the work-around will age out as new versions that play well Python/OpenStack take root.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Roman Sokolkov\" <rsokolkov at gmail.com>\n> To: openstack at lists.openstack.org\n> Sent: Tuesday, August 13, 2013 10:06:20 AM\n> Subject: [Openstack] Fwd: [vmwareapi] Could we distribute wsdl files from	vSphere SDK?\n> \n> Hi, folks\n> \n> Here<http://docs.openstack.org/trunk/openstack-compute/admin/content/vmware.html>metioned\n> that we need vsphere SDK to use with vmwareapi drivers. It could\n> be downloaded from vmware.com only by authorized users.\n> \n> As i understand nova uses only wsdl files from this SDK. What are license\n> terms for wsdl files from SDK?\n> \n> Could we distribute necessary wsdl files with our deployment packs?\n> \n>    - I\'ve found\n> discussion<https://groups.google.com/forum/#!msg/jclouds-dev/dT3MkGT2eNo/7bERFdi8HY0J>,\n>    but without answer.\n>    - and official FAQ <https://communities.vmware.com/docs/DOC-7983>, but\n>    it also not clear for me.\n> \n> Thanks, Roman\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CACN2ZVCuUxWFbvOR6SPDmjJ9m7Va9S0sBvAQMRq5ha1P6rGHcA@mail.gmail.com>',NULL),('<1532952597.2522231399726878997.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-05-10 13:01:18',0,'2014-05-10 13:01:18',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting May 11, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting May 11, 2014\nHost: Alan Clark\nDate: Sunday, May 11, 2014\nTime: 6:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 921 164 008\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t36392890b38257c9c1519d6f3174295c\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=ta4aaef79bc7c2b5231f8d086ab53b442\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=281300022&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 921 164 008\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t6045ad7f579154735bc1e4b2ce9966e4\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140510/60afd248/attachment.html>\n\n',NULL,NULL),('<1532C51C-E008-4BA9-B252-5691B9F517AE@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-10 14:40:29',-25200,'2014-03-10 21:40:29',NULL,'[openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit\n	review','+1\n\nI think there should be naming standard for all reviews (e.g. [test] Jenkins, [test-external] VMware) so that gerrit css can colorize automatic review comments no matter the project.\n\n\nm.\n\nOn Mar 7, 2014, at 2:08 AM, Chmouel Boudjnah <chmouel at enovance.com> wrote:\n\n> if peoples like this why don\'t we have it directly on the reviews?\n> \n> Chmouel.\n> \n> \n> On Tue, Mar 4, 2014 at 10:00 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:\n> Nachi,\n> \n> Great!  I\'d been meaning to do something like this.  I took yours and\n> tweaked it a bit to highlight failed Jenkins builds in red and grey\n> other Jenkins messages.  Human reviews are left in blue.\n> \n> javascript:(function(){\n>     list = document.querySelectorAll(\'td.GJEA35ODGC\');\n>     for(i in list) {\n>         title = list[i];\n>         if(! title.innerHTML) { continue; }\n>         text = title.nextSibling;\n>         if (text.innerHTML.search(\'Build failed\') > 0) {\n>             title.style.color=\'red\'\n>         } else if(title.innerHTML.search(\'Jenkins|CI|Ryu|Testing|Mine\') >= 0) {\n>             title.style.color=\'#666666\'\n>         } else {\n>             title.style.color=\'blue\'\n>         }\n>     }\n> })()\n> \n> Carl\n> \n> On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno <nachi at ntti3.com> wrote:\n> > Hi folks\n> >\n> > I wrote an bookmarklet for neutron gerrit review.\n> > This bookmarklet make the comment title for 3rd party ci as gray.\n> >\n> > javascript:(function(){list =\n> > document.querySelectorAll(\'td.GJEA35ODGC\'); for(i in\n> > list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML &&\n> > list[i].innerHTML.search(\'CI|Ryu|Testing|Mine\') >\n> > 0){list[i].style.color=\'#666666\'}else{list[i].style.color=\'red\'}};})()\n> >\n> > enjoy :)\n> > Nachi\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAPeWyqzesMpDdo-w_=Jt3BtrLVBM3r6LRJ-Sv3LvyHQW4ZqRNA@mail.gmail.com>',NULL),('<1533346942.150.1364364269734.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-27 06:04:29',0,'2013-03-27 06:04:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #177','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/177/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson301374882701932280.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.dbfOfxTjMS\n+ TMPDIR=/tmp/tmp.dbfOfxTjMS\n+ trap \'rm -rf /tmp/tmp.dbfOfxTjMS\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.11 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.38    RoleAPITests.test_get_default_role\n    0.28    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.612s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.dbfOfxTjMS\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/177\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/177/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/177/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<46657887.136.1364277876751.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<153334745.210.1356566712433.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-27 00:05:12',0,'2012-12-27 00:05:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #87','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/87/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/87\n[SCP] Copying console log.\n\n\n','<1186775556.191.1356480266702.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1533735016.15.1377930129941.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-31 06:22:09',0,'2013-08-31 06:22:09',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #9','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/9/>\n\n------------------------------------------\n[...truncated 17344 lines...]\n2013-08-31 06:05:58 # Number of seconds to wait while looping to check the status of a\n2013-08-31 06:05:58 # container to container synchronization\n2013-08-31 06:05:58 container_sync_interval = 5\n2013-08-31 06:05:58 # Set to True if the Account Quota middleware is enabled\n2013-08-31 06:05:58 accounts_quotas_available = True\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Set operator role for tests that require creating a container\n2013-08-31 06:05:58 operator_role = Member\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [boto]\n2013-08-31 06:05:58 ssh_user = cirros\n2013-08-31 06:05:58 # This section contains configuration options used when executing tests\n2013-08-31 06:05:58 # with boto.\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # EC2 URL\n2013-08-31 06:05:58 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-08-31 06:05:58 # S3 URL\n2013-08-31 06:05:58 s3_url = http://127.0.0.1:3333\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-08-31 06:05:58 aws_access =\n2013-08-31 06:05:58 aws_secret =\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Image materials for S3 upload\n2013-08-31 06:05:58 # ALL content of the specified directory will be uploaded to S3\n2013-08-31 06:05:58 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # The manifest.xml files, must be in the s3_materials_path directory\n2013-08-31 06:05:58 # Subdirectories not allowed!\n2013-08-31 06:05:58 # The filenames will be used as a Keys in the S3 Buckets\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-08-31 06:05:58 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-08-31 06:05:58 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-08-31 06:05:58 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Instance type\n2013-08-31 06:05:58 instance_type = m1.nano\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # TCP/IP connection timeout\n2013-08-31 06:05:58 http_socket_timeout = 30\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Number of retries actions on connection or 5xx error\n2013-08-31 06:05:58 num_retries = 1\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Status change wait timout\n2013-08-31 06:05:58 build_timeout = 400\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Status change wait interval\n2013-08-31 06:05:58 build_interval = 1\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [orchestration]\n2013-08-31 06:05:58 # Status change wait interval\n2013-08-31 06:05:58 build_interval = 1\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Status change wait timout. This may vary across environments as some some\n2013-08-31 06:05:58 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-08-31 06:05:58 build_timeout = 300\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Instance type for tests. Needs to be big enough for a\n2013-08-31 06:05:58 # full OS plus the test workload\n2013-08-31 06:05:58 instance_type = m1.micro\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Name of heat-cfntools enabled image to use when launching test instances\n2013-08-31 06:05:58 # If not specified, tests that spawn instances will not run\n2013-08-31 06:05:58 #image_ref = ubuntu-vm-heat-cfntools\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # Name of existing keypair to launch servers with. The default is not to specify\n2013-08-31 06:05:58 # any key, which will generate a keypair for each test class\n2013-08-31 06:05:58 #keypair_name = heat_key\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [dashboard]\n2013-08-31 06:05:58 # URL where to find the dashboard home page\n2013-08-31 06:05:58 dashboard_url = http://127.0.0.1/\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # URL where to submit the login form\n2013-08-31 06:05:58 login_url = http://127.0.0.1/auth/login/\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [scenario]\n2013-08-31 06:05:58 # Directory containing image files\n2013-08-31 06:05:58 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # AMI image file name\n2013-08-31 06:05:58 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # ARI image file name\n2013-08-31 06:05:58 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # AKI image file name\n2013-08-31 06:05:58 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # ssh username for the image file\n2013-08-31 06:05:58 ssh_user = cirros\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 # specifies how many resources to request at once. Used for large operations\n2013-08-31 06:05:58 # testing.\"\n2013-08-31 06:05:58 large_ops_number = 0\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [cli]\n2013-08-31 06:05:58 # Enable cli tests\n2013-08-31 06:05:58 enabled = True\n2013-08-31 06:05:58 # directory where python client binaries are located\n2013-08-31 06:05:58 cli_dir = /usr/local/bin\n2013-08-31 06:05:58 # Number of seconds to wait on a CLI timeout\n2013-08-31 06:05:58 timeout = 15\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [service_available]\n2013-08-31 06:05:58 # Whether or not cinder is expected to be available\n2013-08-31 06:05:58 cinder = True\n2013-08-31 06:05:58 # Whether or not neutron is expected to be available\n2013-08-31 06:05:58 neutron = False\n2013-08-31 06:05:58 # Whether or not glance is expected to be available\n2013-08-31 06:05:58 glance = True\n2013-08-31 06:05:58 # Whether or not swift is expected to be available\n2013-08-31 06:05:58 swift = True\n2013-08-31 06:05:58 # Whether or not nova is expected to be available\n2013-08-31 06:05:58 nova = True\n2013-08-31 06:05:58 # Whether or not Heat is expected to be available\n2013-08-31 06:05:58 heat = True\n2013-08-31 06:05:58 # Whether or not horizon is expected to be available\n2013-08-31 06:05:58 horizon = True\n2013-08-31 06:05:58 \n2013-08-31 06:05:58 [stress]\n2013-08-31 06:05:58 # Maximum number of instances to create during test\n2013-08-31 06:05:58 max_instances = 32\n2013-08-31 06:05:58 # Time (in seconds) between log file error checks\n2013-08-31 06:05:58 log_check_interval = 60\n2013-08-31 06:05:58 # The default number of threads created while stress test\n2013-08-31 06:05:58 default_thread_number_per_action=4\n2013-08-31 06:05:58 ++ IFS=\' 	\n2013-08-31 06:05:58 \'\n2013-08-31 06:05:58 ++ set +o errexit\n2013-08-31 06:05:58 ++ init_tempest\n2013-08-31 06:05:58 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-08-31 06:05:58 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-31 06:05:58 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-08-31 06:05:58 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-08-31 06:05:58 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1658.gedaa084.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp7hJD3L\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpR0ETb0\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpdC7oVk\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp_UuT04\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 33, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-0\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2513 tests in 918.234s\nFAILED (id=0, failures=2, skips=71)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-197128-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-197128.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az2-197128/9/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2012412169.11.1377843857691.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<153501d00ecc$e4da1880$ae8e4980$@chinacloud.com.cn>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-03 15:43:56',28800,'2014-12-03 07:43:56',NULL,'[Openstack] [Ceilometer] looking for alarm best practice - please\n	help','Hi folks,\n\n \n\nI wonder if anyone could share some best practice regarding to the usage of\nceilometer alarm. We are using the alarm evaluation/notification of\nceilometer and we don\'t feel very well of the way we use it. Below is our\nproblem:\n\n \n\n============================\n\nScenario:\n\nWhen cpu usage or memory usage above a certain threshold, alerts should be\ndisplayed on admin\'s web page. There should be a 3 level alerts according to\nmeter value, namely notice, warning, fatal. Notice means the meter value is\nbetween 50% ~ 70%, warning means between 70% ~ 85% and fatal means above 85%\n\nFor example:\n\n* when one vm\'s cpu usage is 72%, an alert message should be displayed\nsaying \"Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above\n70%\".\n\n* when one vm\'s memory usage is 90%, another alert message should be created\nsaying \"Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] memory usage is\nabove 85%\"\n\n \n\nOur current Solution:\n\nWe used ceilometer alarm evaluation/notification to implement this. To\ndistinguish which VM and which meter is above what value, we\'ve created one\nalarm for each VM by each condition. So, to monitor 1 VM, 6 alarms will be\ncreated because there are 2 meters and for each meter there are 3 levels.\nThat means, if there are 100 VMs to be monitored, 600 alarms will be\ncreated.\n\n \n\nProblems:\n\n* The first problem is, when the number of meters increases, the number of\nalarms will be multiplied. For example, customer may want alerts on disk and\nnetwork IO rates, and if we do that, there will be 4*3=12 alarms for each\nVM. \n\n* The second problem is, when one VM is created, multiple alarms will be\ncreated, meaning multiple http requests will be fired. In the case above, 6\nHTTP requests will be needed once a VM is created. And this number also\nincreases as the number of meters goes up.\n\n=============================\n\n \n\nDo anyone have any suggestions?\n\n \n\n \n\n \n\nBest Regards!\n\nKurt Rao\n\n  _____  \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141203/cd81abdd/attachment.html>\n\n',NULL,NULL),('<1535252690.257499.1391158498017.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-31 09:54:58',3600,'2014-01-31 08:54:58',NULL,'[openstack-dev] [Heat] About LaunchConfiguration and Autoscaling','\n\n> On 30/01/14 12:20, Randall Burt wrote:\n> > On Jan 30, 2014, at 12:09 PM, Clint Byrum<clint at fewbar.com>\n> >   wrote:\n> \n> >> >I would hope we would solve that at a deeper level, rather than making\n> >> >resources for the things we think will need re-use. I think nested stacks\n> >> >allow this level of re-use already anyway. Software config just allows\n> >> >sub-resource composition.\n> > Agreed. Codifying re-use inside specific resource types is a game of\n> > catch-up I don\'t think we can win in the end.\n> \n> Thomas started this discussion talking about resources, but IMHO it\'s\n> mostly really about the scaling API. It just happens that we\'re\n> implementing the resources first and they need to match what we\n> eventually decide the API should look like.\n\nNot talking about the API was completely intentional. I believe that we should offer the best resource interface possible, regardless of the underlying API.\n\n> So we\'re creating a new API. That doesn\'t happen very often. It\'s\n> absolutely appropriate to consider whether we want two classes of\n> resources in that API to have a 1:1 or 1:Many relationship, regardless\n> of how many fancy transclusion things we have in the templates. For a\n> start because one of the main reasons to create an API is so people can\n> access it without templates.\n\nFair enough.\n\nTo give my opinion, I think we\'re overstating how useful it\'d be to reuse launch configurations. The real reusability is at software config level, not so much about what flavor you want to use when starting an instance. Also, we already have provider templates to be able to embed resources and their properties.\n\nFinally, if we go back to the API, it\'s one less thing to manage and simplify the model. The group becomes the bag containing scaling properties and resource definition.\n\n-- \nThomas\n\n\n','<52EB1C4F.7070503@redhat.com>',NULL),('<1535859604.7.1377326663544.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-24 06:44:23',0,'2013-08-24 06:44:23',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #14','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/14/>\n\n\n\n','<538346114.4.1377240808223.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1536414515.34253232.1403794477886.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-26 10:54:37',-14400,'2014-06-26 14:54:37',NULL,'[openstack-dev] [horizon][novnc] Browser Usage for noVNC','It was recommended I cross-post this for visibility.\nDevs are welcome to provide feedback as well ;-)\n\nBest Regards,\nSolly Ross\n\n----- Forwarded Message -----\nFrom: \"Solly Ross\" <sross at redhat.com>\nTo: openstack-operators at lists.openstack.org\nSent: Tuesday, June 24, 2014 1:29:15 PM\nSubject: Browser Usage for noVNC\n\nHello Operators,\n\nI\'m part of the noVNC upstream development team.  noVNC, for those of you who don\'t know, is the HTML5 VNC client\nintegrated into Horizon (the OpenStack dashboard).  We are considering removing support for some older browsers, and\nwanted to make sure that we wouldn\'t be inconveniencing anybody too much.  Are there any operators who still aim to\nsupport connecting with any of the following browsers:\n\n- Firefox < 11.0\n- Chrome < 16.0\n- IE < 10.0\n- Safari < 6.0\n(insert uncommon browser here that doesn\'t support WebSockets natively)\n\nIf so, what is your minimum browser version?\n\nBest Regards,\nSolly Ross\n\n\n','<1897676716.32953671.1403630955743.JavaMail.zimbra@redhat.com>',NULL),('<153664223.121.1384582500274.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-16 06:15:00',0,'2013-11-16 06:15:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #46','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/46/>\n\n------------------------------------------\n[...truncated 1175 lines...]\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_cache_middleware.TestImageCacheManageSqlite.test_cache_manage_get_cached_images\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 464, in test_cache_manage_get_cached_images\n    self.verify_no_images()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 349, in verify_no_images\n    self.assertEqual(response.status, 200)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 500 != 200\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 96.84 secs:\n    27.55    TestScrubber.test_scrubber_app\n    21.76    TestScrubber.test_delayed_delete\n    16.45    TestRootApi.test_version_configurations\n    15.66    TestBinGlanceCacheManage.test_queue\n    15.43    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1109 tests in 708.888s\n\nFAILED (SKIP=42, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.17.0\ncffi==0.8\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.46\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.3.0\nkombu==3.0.5\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.2KNuAHXaul\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/46/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise20/46\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1536741879.1418959.1383558740998.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 10:52:21',3600,'2013-11-04 09:52:21',NULL,'[openstack-dev]  [horizon] BootstrapV3 and lessc','Hi,\n\nI talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. When node was removed it was compiling the less template at runtime, this is useful in development but not in production. Maybe it is possible to perform a dist task which will compile the less template for the package target. \n\nIf we keep lesscpy we will have to maintain it every time less pre processor will upgrade, it is a lot of work in addition for few benefits. Currently, a review is waiting for the integration of bootstrap https://review.openstack.org/#/c/49710/ using lessc (node compiler). \n\nI need your reviews on this topic because a lot of work is currently done for the ui of Horizon and the integration of Bootstrap v3 is a huge bottleneck for further development. \n\n\n\n','<1668736406.1409907.1383556805419.JavaMail.root@enovance.com>',NULL),('<1537181330.13478379.1410578401358.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-09-12 23:20:01',-14400,'2014-09-13 03:20:01',NULL,'[Openstack-docs] Install Guide Status','----- Original Message -----\n> From: \"Matt Kassawara\" <mkassawara at gmail.com>\n> To: \"Nicholas Chase\" <nchase at mirantis.com>\n> \n> I created a wiki page covering necessary changes (so far) for Juno based on\n> a combination of the following:\n> \n> 1) Configuration file changes from the configuration reference.\n> 2) Installation of \"core\" services on Ubuntu using Juno milestone 2\n> packages. Both the neutron and nova-network environments appear to work.\n> However, the milestone 2 packages don\'t fully support the [neutron] section\n> in nova.conf so the neutron environment uses a mixture of old and new\n> locations.\n> \n> Surprisingly, I didn\'t have to peek at gate configurations for hints. Also,\n> I\'m still waiting on packages for RH/CentOS/Fedora and hope someone\n> familiar with SUSE and Debian can validate these changes well ahead of\n> release on 16 October.\n\nWe\'re currently running CI on M-3 based packages for RDO. Unfortunately there has still been a heavy skew towards feature delivery in the last milestone in Juno (e.g. M-1: 4 blueprints, M-2: 8 blueprints, M-3 26: blueprints in Nova) so I would expect there is quite some potential for change there.\n\n-Steve\n\n\n','<CABA+jQqbVoY3ky3NyUwGt3CyEsVLFWmmGcu1HR-Yq7wgdyjUzA@mail.gmail.com>',NULL),('<1537219263.244.1368339225343.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:13:45',0,'2013-05-12 06:13:45',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #223','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/223/>\n\n\n\n','<220123144.227.1368252738310.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<15386efb2502018e6f788a42a28686ba@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:59:07',-21600,'2014-01-22 16:59:07',NULL,'[openstack-dev] [OpenStack-Dev] Cherry picking commit from\n	oslo-incubator','On 2014-01-22 06:32, Sean Dague wrote:\n> I think we need to graduate things to stable interfaces a lot faster.\n> Realizing that stable just means \"have to deprecate to change it\". So\n> the interface is still changeable, just requires standard deprecation\n> techniques. Which we are trying to get more python libraries to do\n> anyway, so it would be good if we built up a bunch of best practices \n> here.\n> \n> 	-Sean\n\nBig +1 to this.  Eliminating the sync process is going to be the \ncleanest solution for the code that is stable enough to be usable with \nthings like automatic syncs.  The less code that is left in incubator, \nthe easier the syncs will be.\n\nThat said, I think there\'s only a few people (Doug, Mark, and Thierry?) \nwho have done the promote to library thing, and I will admit I don\'t \nhave a good handle on what is involved.  It may be that we need better \ndocumentation of that process so more people can help out with it.  I \nknow Michael Still mentioned he was planning to graduate lockutils but \ndidn\'t know exactly how.\n\n-Ben\n\n\n','<52DFBA77.4050201@dague.net>',NULL),('<1538949.RG6Jh0LEBA@linux-opjy.site>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-08-21 16:02:40',28800,'2013-08-21 08:02:40',NULL,'[Openstack-operators] Use FC disk array for storage.','Hi all,\n\nI want to use FC disk array for block storage in my openstack cloud.\nBut I\'m not sure how to connect those devices.\nI drew this network topology diagram(http://goo.gl/PtTwtZ), could some tell me \nwhether it\'s correct or not.\n\nB.R.\nRibo\n\n\n\n\n',NULL,NULL),('<1539087966.46.1352679123652.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:12:03',0,'2012-11-12 00:12:03',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-diablo #90','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/90/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/>\nCheckout:periodic-swift-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/> - hudson.remoting.Channel at 740355a4:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson2119180730159475851.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-diablo/90\n[SCP] Copying console log.\n\n\n','<828470105.34.1352592635369.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<153A71C3-D575-42DB-87AA-DD6385E0ADEA@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-18 10:12:32',-28800,'2014-02-18 18:12:32',NULL,'[openstack-dev] [Neutron] VPC Proposal','We have started a discussion on the proper model to implement a Virtual Private Cloud (VPC) feature in openstack.\n\nI feel that there was not a lot of discussion on this topic in the past, and this may be because of the ML tags used.\nI am pointing out this discussion to this group with the Neutron tag as I think that networking is a big aspect of VPC.\n\nPlease, jump in the discussion and share your comments.\n\nSee http://lists.openstack.org/pipermail/openstack-dev/2014-February/026892.html\n\nand \n\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-February/027171.html\n\nJC\n\n',NULL,NULL),('<1540255527.148317.1395035777564.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-17 01:56:17',-14400,'2014-03-17 05:56:17',NULL,'[Openstack-docs] Conventions on naming [clarifications]','Thanks Diane. I\'ll take that as an indication that the word \"Service\" can be dropped from keystone\'s name. I\'m editing the \"Documentation/Conventions\" wiki now. \n\nI\'m still puzzled with \"OpenStack Image Service\" though. The links provided by Diane F and Steve G include the word \"Service\" with uppercase \"S\". Is the uppercase \"S\" of \"Service\" here a strict convention? From what I can see, we typically use \"service\" (lowercase \"s\") when referring to other services, such as \"Compute service\" or \"Block Storage service\". Is there any good reason for us to make an exception with \"Image Service\"? Or should we actually be using uppercase \"S\" with \"Service\" beside service names -- meaning we\'ll have to change all instances of, say, \"Compute service\" to \"Compute Service\"?\n\nAnne Gentle, can you provide some guidance on this? Thanks!\n\nRegards,\nDon Domingo\nContent Author - OpenStack\nEngineering Content Services\nEmail: ddomingo at redhat.com\nIRC: ddomingo\n\n\n\n----- Original Message -----\nFrom: \"Diane Fleming\" <diane.fleming at rackspace.com>\nTo: \"Don Domingo\" <ddomingo at redhat.com>\nCc: \"Steve Gordon\" <sgordon at redhat.com>, \"Andreas Jaeger\" <aj at suse.com>, openstack-docs at lists.openstack.org\nSent: Monday, March 17, 2014 10:54:26 AM\nSubject: Re: [Openstack-docs] Conventions on naming [clarifications]\n\nIf you look at OpenStack Capabilities section on this page http://www.openstack.org/software/roadmap/, the names match what Steve found.  \n\nSent from my iPhone\n\n> On Mar 16, 2014, at 7:46 PM, \"Don Domingo\" <ddomingo at redhat.com> wrote:\n> \n> I can patch out the 20 instances of \"Compute Service\", not a problem.\n> Personally, I prefer the word \"service\" as lowercase.\n> \n> BTW, bear in mind that as I have not been with the project that long,\n> I\'ve only been using the Conventions page for naming guidance:\n> https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names\n> \n> If \"Compute Service\" is incorrect, then why are \"Identity Service\" and \"Image\n> Service\" (capital \"S\") correct? Or, if we\'re adhering to TC guidance,\n> as Steve G mentioned before, \"Identity\" was endorsed, not \"Identity Service\".\n> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml\n> \n> Can we clarify with the TC whether we need to strictly refer to glance as\n> \"Image Service\" or if we could simply refer to it as \"Image service\" (small\n> \"s\")? This would make the naming consistent.\n> \n> Also, as the TC document Steve G quoted does not endorse \"Identity\n> Service\", can we now revise that to \"OpenStack Identity\" on the\n> Conventions page?\n> \n> Once we clarify the naming convention, I can start pushing patches.\n> \n> Regards,\n> Don Domingo\n> Content Author - OpenStack\n> Engineering Content Services\n> Email: ddomingo at redhat.com\n> IRC: ddomingo\n> \n> \n> \n> ----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Don Domingo\" <ddomingo at redhat.com>, openstack-docs at lists.openstack.org\n> Sent: Saturday, March 15, 2014 4:53:51 AM\n> Subject: Re: [Openstack-docs] Conventions on naming [clarifications]\n> \n>> On 03/14/2014 06:33 AM, Don Domingo wrote:\n>> Hi,\n>> \n>> I apologize for bringing this up a bit late, seeing as the OpenStack project naming conventions have already been discussed last month:\n>> http://lists.openstack.org/pipermail/openstack-docs/2014-February/003804.html\n>> \n>> Anyhow, I wanted to clarify:\n>> \n>> * Why do \"Identity Service\" and \"Image Service\" have the word \"Service\" as part of their names? I assume that this is the case, seeing as \"Service\" is initcapped?\n> \n> I guess that\'s historical..\n> \n>> * Are there instances where, say, \"the Compute service\" is valid? Or should such instances be replaced with \"the OpenStack Compute service\"? And is the convention for Compute true for Block Storage, Networking, etc?\n> \n> We use \"OpenStack Compute\" and appreviate as \"Compute\"  - thus both are\n> valid\n> \n>> I\'m asking because, specifically for \"Compute\", the usage is varied across the documentation:\n>> \n>>    \"the Compute service\" - 54\n>>    \"the Compute Service\" - 18\n> \n>>    \"the OpenStack Compute service\" - 6\n>>    \"the OpenStack Compute Service\" - 2\n> \n> Do you want to send a patch for those 20 wrong settings? Would be\n> appreciated!\n> \n>> I only checked Compute to help illustrate the situation. I haven\'t checked the usage stats yet for the other service names, though I\'m sure we\'ll find similar naming variations with Networking, Block Storage, etc. I can spend time applying the correct convention, but I\'d like to verify exactly what convention to follow in this regard (not just for Compute, but for all of them).\n> \n> Whenever I review and see a wrong setting, I speak up - and others do so\n> as well. And there are a few that search and fix...\n> \n>> Again, I apologize for only bringing this up now, a month after it\'s already been discussed. It\'s just that I didn\'t realize the extent of the naming variation until now (I\'ve only started contributing late January 2014).\n> \n> No worries, questions for clarification are always welcome.\n> \n> Andreas\n> -- \n> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n> \n> \n> ----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: \"Andreas Jaeger\" <aj at suse.com>\n> Cc: \"Don Domingo\" <ddomingo at redhat.com>, openstack-docs at lists.openstack.org\n> Sent: Saturday, March 15, 2014 5:13:13 AM\n> Subject: Re: [Openstack-docs] Conventions on naming [clarifications]\n> \n> ----- Original Message -----\n>>> On 03/14/2014 06:33 AM, Don Domingo wrote:\n>>> Hi,\n>>> \n>>> I apologize for bringing this up a bit late, seeing as the OpenStack\n>>> project naming conventions have already been discussed last month:\n>>> http://lists.openstack.org/pipermail/openstack-docs/2014-February/003804.html\n>>> \n>>> Anyhow, I wanted to clarify:\n>>> \n>>> * Why do \"Identity Service\" and \"Image Service\" have the word \"Service\" as\n>>> part of their names? I assume that this is the case, seeing as \"Service\"\n>>> is initcapped?\n>> \n>> I guess that\'s historical..\n> \n> Yeah, it\'s interesting because the names endorsed by the TC are recorded here:\n> \n>    http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml\n> \n> ...and while \"Image Service appears to be recorded there, \"Identity Service\" is referred to just as \"Identity\". I\'m not sure there is a method to the madness there :). Which programs get included in core and thus can be prefixed with OpenStack is the domain of the board.\n> \n> Thanks,\n> \n> Steve\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n','<D865110A-3435-49C1-A022-D709E64DB2B9@RACKSPACE.COM>',NULL),('<1541093341.66.1386741995572.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:06:35',0,'2013-12-11 06:06:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-docs-havana #8','See <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/8/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise15 in workspace <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/>\nCheckout:periodic-nova-docs-havana / <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/> - hudson.remoting.Channel at 1ebf2a66:precise15\nUsing strategy: Default\nLast Built Revision: Revision 5a9551d91b30af3da122bf9516ec346d8c725ee4 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/nova\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/nova\nCommencing build of Revision 5a9551d91b30af3da122bf9516ec346d8c725ee4 (origin/stable/havana)\nChecking out Revision 5a9551d91b30af3da122bf9516ec346d8c725ee4 (origin/stable/havana)\n[periodic-nova-docs-havana] $ /bin/bash -xe /tmp/hudson7133641613041896375.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack nova\n+ org=openstack\n+ project=nova\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack nova /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=nova\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack nova /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=nova\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/nova /opt/requirements/projects.txt\nopenstack/nova\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nvenv create: <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/test-requirements.txt>\nvenv develop-inst: <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-nova-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-havana/precise15\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-havana/precise15/8\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1541111604.39.1381219050532.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-08 07:57:30',0,'2013-10-08 07:57:30',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stress #31','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/31/>\n\n\n\n','<514743494.37.1381126155893.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1541567582.61443218.1380037256454.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-24 08:40:56',-25200,'2013-09-24 15:40:56',NULL,'[openstack-dev] [LBaaS][Horizon] Subnet for VIP?','I didn\'t know current lbaas plugin has such limitation. Although I think the UI should not incur such limitation as the lbaas API definition does allow this, I\'m fine with it. \n\nThanks, \n-Kaiwei \n\n----- Original Message -----\n\nFrom: \"Eugene Nikanorov\" <enikanorov at mirantis.com> \nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org> \nSent: Tuesday, September 24, 2013 2:00:33 AM \nSubject: Re: [openstack-dev] [LBaaS][Horizon] Subnet for VIP? \n\nHi Fank, \n\nThat looks like Horizon limitation that is bound to current reference implementation of lbaas service where VIP should be on a subnet where pool\'s memebers are. \nSo it\'s not a bug. Expect this to change in Icehouse. \n\nThanks, \nEugene. \n\n\n\nOn Tue, Sep 24, 2013 at 9:19 AM, < fank at vmware.com > wrote: \n\n\nHi, \n\nWhen adding a VIP for this pool, we suppose to specify the subnet which the VIP will be on. However, the Horizon UI forces us to provide an IP address for the VIP from the subnet which we used to create the pool. That subnet for pool is supposed to be the subnet for pool\'s members, not the subnet for the VIP. \n\nThis looks like a UI bug? \n\nThanks, \n-Kaiwei \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130924/08601ded/attachment.html>\n\n','<CAJfiwORG0Mw35WWudvS_=cQzQH7cKzf-68FzsudFguSXMvnHEA@mail.gmail.com>',NULL),('<1543442868.35.1378361906414.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-05 06:18:26',0,'2013-09-05 06:18:26',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #17','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/17/>\n\n------------------------------------------\n[...truncated 17389 lines...]\n2013-09-05 06:17:53 # This section contains the configuration options used when executing tests\n2013-09-05 06:17:53 # against the OpenStack Block Storage API service\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-05 06:17:53 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-05 06:17:53 # probably want to leave this value as \"volume\"\n2013-09-05 06:17:53 catalog_type = volume\n2013-09-05 06:17:53 # Number of seconds to wait while looping to check the status of a\n2013-09-05 06:17:53 # volume that is being made available\n2013-09-05 06:17:53 build_interval = 1\n2013-09-05 06:17:53 # Number of seconds to time out on waiting for a volume\n2013-09-05 06:17:53 # to be available or reach an expected status\n2013-09-05 06:17:53 build_timeout = 400\n2013-09-05 06:17:53 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-05 06:17:53 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-05 06:17:53 # have to be different)\n2013-09-05 06:17:53 multi_backend_enabled = false\n2013-09-05 06:17:53 backend1_name = BACKEND_1\n2013-09-05 06:17:53 backend2_name = BACKEND_2\n2013-09-05 06:17:53 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-05 06:17:53 # You should update to reflect those exported by configured backend driver.\n2013-09-05 06:17:53 storage_protocol = iSCSI\n2013-09-05 06:17:53 vendor_name = Open Source\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 [object-storage]\n2013-09-05 06:17:53 # This section contains configuration options used when executing tests\n2013-09-05 06:17:53 # against the OpenStack Object Storage API.\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # You can configure the credentials in the compute section\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-05 06:17:53 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-05 06:17:53 # this value as \"object-store\"\n2013-09-05 06:17:53 catalog_type = object-store\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Number of seconds to time on waiting for a container to container\n2013-09-05 06:17:53 # synchronization complete\n2013-09-05 06:17:53 container_sync_timeout = 120\n2013-09-05 06:17:53 # Number of seconds to wait while looping to check the status of a\n2013-09-05 06:17:53 # container to container synchronization\n2013-09-05 06:17:53 container_sync_interval = 5\n2013-09-05 06:17:53 # Set to True if the Account Quota middleware is enabled\n2013-09-05 06:17:53 accounts_quotas_available = True\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Set operator role for tests that require creating a container\n2013-09-05 06:17:53 operator_role = Member\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 [boto]\n2013-09-05 06:17:53 ssh_user = cirros\n2013-09-05 06:17:53 # This section contains configuration options used when executing tests\n2013-09-05 06:17:53 # with boto.\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # EC2 URL\n2013-09-05 06:17:53 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-05 06:17:53 # S3 URL\n2013-09-05 06:17:53 s3_url = http://127.0.0.1:3333\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-05 06:17:53 aws_access =\n2013-09-05 06:17:53 aws_secret =\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Image materials for S3 upload\n2013-09-05 06:17:53 # ALL content of the specified directory will be uploaded to S3\n2013-09-05 06:17:53 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-05 06:17:53 # Subdirectories not allowed!\n2013-09-05 06:17:53 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-05 06:17:53 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-05 06:17:53 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-05 06:17:53 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Instance type\n2013-09-05 06:17:53 instance_type = m1.nano\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # TCP/IP connection timeout\n2013-09-05 06:17:53 http_socket_timeout = 30\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Number of retries actions on connection or 5xx error\n2013-09-05 06:17:53 num_retries = 1\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Status change wait timout\n2013-09-05 06:17:53 build_timeout = 400\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Status change wait interval\n2013-09-05 06:17:53 build_interval = 1\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 [orchestration]\n2013-09-05 06:17:53 # Status change wait interval\n2013-09-05 06:17:53 build_interval = 1\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Status change wait timout. This may vary across environments as some some\n2013-09-05 06:17:53 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-05 06:17:53 build_timeout = 300\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Instance type for tests. Needs to be big enough for a\n2013-09-05 06:17:53 # full OS plus the test workload\n2013-09-05 06:17:53 instance_type = m1.micro\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-05 06:17:53 # If not specified, tests that spawn instances will not run\n2013-09-05 06:17:53 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-05 06:17:53 # any key, which will generate a keypair for each test class\n2013-09-05 06:17:53 #keypair_name = heat_key\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 [dashboard]\n2013-09-05 06:17:53 # URL where to find the dashboard home page\n2013-09-05 06:17:53 dashboard_url = http://127.0.0.1/\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # URL where to submit the login form\n2013-09-05 06:17:53 login_url = http://127.0.0.1/auth/login/\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 [scenario]\n2013-09-05 06:17:53 # Directory containing image files\n2013-09-05 06:17:53 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # AMI image file name\n2013-09-05 06:17:53 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # ARI image file name\n2013-09-05 06:17:53 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-05 06:17:53 \n2013-09-05 06:17:53 # AKI image file name\n2013-09-05 06:17:54 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-05 06:17:54 \n2013-09-05 06:17:54 # ssh username for the image file\n2013-09-05 06:17:54 ssh_user = cirros\n2013-09-05 06:17:54 \n2013-09-05 06:17:54 # specifies how many resources to request at once. Used for large operations\n2013-09-05 06:17:54 # testing.\"\n2013-09-05 06:17:54 large_ops_number = 0\n2013-09-05 06:17:54 \n2013-09-05 06:17:54 [cli]\n2013-09-05 06:17:54 # Enable cli tests\n2013-09-05 06:17:54 enabled = True\n2013-09-05 06:17:54 # directory where python client binaries are located\n2013-09-05 06:17:54 cli_dir = /usr/local/bin\n2013-09-05 06:17:54 # Number of seconds to wait on a CLI timeout\n2013-09-05 06:17:54 timeout = 15\n2013-09-05 06:17:54 \n2013-09-05 06:17:54 [service_available]\n2013-09-05 06:17:54 # Whether or not cinder is expected to be available\n2013-09-05 06:17:54 cinder = True\n2013-09-05 06:17:54 # Whether or not neutron is expected to be available\n2013-09-05 06:17:54 neutron = False\n2013-09-05 06:17:54 # Whether or not glance is expected to be available\n2013-09-05 06:17:54 glance = True\n2013-09-05 06:17:54 # Whether or not swift is expected to be available\n2013-09-05 06:17:54 swift = True\n2013-09-05 06:17:54 # Whether or not nova is expected to be available\n2013-09-05 06:17:54 nova = True\n2013-09-05 06:17:54 # Whether or not Heat is expected to be available\n2013-09-05 06:17:54 heat = True\n2013-09-05 06:17:54 # Whether or not horizon is expected to be available\n2013-09-05 06:17:54 horizon = True\n2013-09-05 06:17:54 \n2013-09-05 06:17:54 [stress]\n2013-09-05 06:17:54 # Maximum number of instances to create during test\n2013-09-05 06:17:54 max_instances = 32\n2013-09-05 06:17:54 # Time (in seconds) between log file error checks\n2013-09-05 06:17:54 log_check_interval = 60\n2013-09-05 06:17:54 # The default number of threads created while stress test\n2013-09-05 06:17:54 default_thread_number_per_action=4\n2013-09-05 06:17:54 ++ IFS=\' 	\n2013-09-05 06:17:54 \'\n2013-09-05 06:17:54 ++ set +o errexit\n2013-09-05 06:17:54 ++ init_tempest\n2013-09-05 06:17:54 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-05 06:17:54 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-05 06:17:54 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-05 06:17:54 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-05 06:17:54 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1690.g8029f8a.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-218717-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-218717.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-218717/17/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1029493687.33.1378276287335.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1543504211.9.1380521327942.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-30 06:08:47',0,'2013-09-30 06:08:47',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #32','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/32/>\n\n------------------------------------------\n[...truncated 18399 lines...]\n2013-09-30 06:08:06 # You can configure the credentials in the compute section\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-30 06:08:06 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-30 06:08:06 # this value as \"object-store\"\n2013-09-30 06:08:06 catalog_type = object-store\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # The name of a region for object storage. If empty or commented-out, the\n2013-09-30 06:08:06 # value of identity.region is used instead. If no such region is found in\n2013-09-30 06:08:06 # the service catalog, the first found one is used.\n2013-09-30 06:08:06 #region = RegionOne\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Number of seconds to time on waiting for a container to container\n2013-09-30 06:08:06 # synchronization complete\n2013-09-30 06:08:06 container_sync_timeout = 120\n2013-09-30 06:08:06 # Number of seconds to wait while looping to check the status of a\n2013-09-30 06:08:06 # container to container synchronization\n2013-09-30 06:08:06 container_sync_interval = 5\n2013-09-30 06:08:06 # Set to True if the Account Quota middleware is enabled\n2013-09-30 06:08:06 accounts_quotas_available = True\n2013-09-30 06:08:06 # Set to True if the Container Quota middleware is enabled\n2013-09-30 06:08:06 container_quotas_available = True\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Set operator role for tests that require creating a container\n2013-09-30 06:08:06 operator_role = Member\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [boto]\n2013-09-30 06:08:06 ssh_user = cirros\n2013-09-30 06:08:06 # This section contains configuration options used when executing tests\n2013-09-30 06:08:06 # with boto.\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # EC2 URL\n2013-09-30 06:08:06 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-30 06:08:06 # S3 URL\n2013-09-30 06:08:06 s3_url = http://127.0.0.1:3333\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-30 06:08:06 aws_access =\n2013-09-30 06:08:06 aws_secret =\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Image materials for S3 upload\n2013-09-30 06:08:06 # ALL content of the specified directory will be uploaded to S3\n2013-09-30 06:08:06 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-30 06:08:06 # Subdirectories not allowed!\n2013-09-30 06:08:06 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-30 06:08:06 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-30 06:08:06 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-30 06:08:06 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Instance type\n2013-09-30 06:08:06 instance_type = m1.nano\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # TCP/IP connection timeout\n2013-09-30 06:08:06 http_socket_timeout = 30\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Number of retries actions on connection or 5xx error\n2013-09-30 06:08:06 num_retries = 1\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Status change wait timout\n2013-09-30 06:08:06 build_timeout = 400\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Status change wait interval\n2013-09-30 06:08:06 build_interval = 1\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [orchestration]\n2013-09-30 06:08:06 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-09-30 06:08:06 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-30 06:08:06 # this value as \"orchestration\"\n2013-09-30 06:08:06 catalog_type = orchestration\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # The name of a region for orchestration. If empty or commented-out, the value\n2013-09-30 06:08:06 # of identity.region is used instead. If no such region is found in the service\n2013-09-30 06:08:06 # catalog, the first found one is used.\n2013-09-30 06:08:06 #region = RegionOne\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Status change wait interval\n2013-09-30 06:08:06 build_interval = 1\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Status change wait timout. This may vary across environments as some some\n2013-09-30 06:08:06 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-30 06:08:06 build_timeout = 300\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Instance type for tests. Needs to be big enough for a\n2013-09-30 06:08:06 # full OS plus the test workload\n2013-09-30 06:08:06 instance_type = m1.micro\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-30 06:08:06 # If not specified, tests that spawn instances will not run\n2013-09-30 06:08:06 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-30 06:08:06 # any key, which will generate a keypair for each test class\n2013-09-30 06:08:06 #keypair_name = heat_key\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [dashboard]\n2013-09-30 06:08:06 # URL where to find the dashboard home page\n2013-09-30 06:08:06 dashboard_url = http://127.0.0.1/\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # URL where to submit the login form\n2013-09-30 06:08:06 login_url = http://127.0.0.1/auth/login/\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [scenario]\n2013-09-30 06:08:06 # Directory containing image files\n2013-09-30 06:08:06 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # AMI image file name\n2013-09-30 06:08:06 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # ARI image file name\n2013-09-30 06:08:06 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # AKI image file name\n2013-09-30 06:08:06 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # ssh username for the image file\n2013-09-30 06:08:06 ssh_user = cirros\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 # specifies how many resources to request at once. Used for large operations\n2013-09-30 06:08:06 # testing.\"\n2013-09-30 06:08:06 large_ops_number = 0\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [cli]\n2013-09-30 06:08:06 # Enable cli tests\n2013-09-30 06:08:06 enabled = True\n2013-09-30 06:08:06 # directory where python client binaries are located\n2013-09-30 06:08:06 cli_dir = /usr/local/bin\n2013-09-30 06:08:06 # Number of seconds to wait on a CLI timeout\n2013-09-30 06:08:06 timeout = 15\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [service_available]\n2013-09-30 06:08:06 # Whether or not cinder is expected to be available\n2013-09-30 06:08:06 cinder = True\n2013-09-30 06:08:06 # Whether or not neutron is expected to be available\n2013-09-30 06:08:06 neutron = False\n2013-09-30 06:08:06 # Whether or not glance is expected to be available\n2013-09-30 06:08:06 glance = True\n2013-09-30 06:08:06 # Whether or not swift is expected to be available\n2013-09-30 06:08:06 swift = True\n2013-09-30 06:08:06 # Whether or not nova is expected to be available\n2013-09-30 06:08:06 nova = True\n2013-09-30 06:08:06 # Whether or not Heat is expected to be available\n2013-09-30 06:08:06 heat = True\n2013-09-30 06:08:06 # Whether or not horizon is expected to be available\n2013-09-30 06:08:06 horizon = True\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [stress]\n2013-09-30 06:08:06 # Maximum number of instances to create during test\n2013-09-30 06:08:06 max_instances = 32\n2013-09-30 06:08:06 # Time (in seconds) between log file error checks\n2013-09-30 06:08:06 log_check_interval = 60\n2013-09-30 06:08:06 # The default number of threads created while stress test\n2013-09-30 06:08:06 default_thread_number_per_action=4\n2013-09-30 06:08:06 \n2013-09-30 06:08:06 [debug]\n2013-09-30 06:08:06 # Enable diagnostic commands\n2013-09-30 06:08:06 enable = True\n2013-09-30 06:08:06 ++ IFS=\' 	\n2013-09-30 06:08:06 \'\n2013-09-30 06:08:06 ++ set +o errexit\n2013-09-30 06:08:06 ++ init_tempest\n2013-09-30 06:08:06 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-30 06:08:06 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-30 06:08:06 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-30 06:08:06 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-30 06:08:06 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-09-30 06:08:06 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-09-30 06:08:06 ++ echo \'Prepare aki/ari/ami Images\'\n2013-09-30 06:08:06 Prepare aki/ari/ami Images\n2013-09-30 06:08:06 ++ cat\n2013-09-30 06:08:06 ++ source /opt/stack/new/devstack/accrc/demo/demo\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1877.g7061c70.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600 -S\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/stress/bin/python -m tempest/stress/run_stress -a -d 3600 -S\'\n___________________________________ summary ____________________________________\nERROR:   stress: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-418188-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-418188.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-418188/32/logs/tempest.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1543566915.1.1385103318444.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-22 06:55:17',0,'2013-11-22 06:55:17',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #1','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/1/>\n\n------------------------------------------\n[...truncated 20835 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   198.877\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           107.889\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   64.943\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                     41.576\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]        39.399\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         38.192\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                       37.533\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      36.836\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]        35.057\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   32.846\n\n----------------------------------------------------------------------\nRan 1340 tests in 1385.241s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-720720-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-720720.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az3-720720/1/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<154416313.65.1386828184283.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:03:04',0,'2013-12-12 06:03:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-docs-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/6/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise22 in workspace <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/>\nCheckout:periodic-glance-docs-grizzly / <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/> - hudson.remoting.Channel at 767ffae6:precise22\nUsing strategy: Default\nLast Built Revision: Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/glance\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/glance\nCommencing build of Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\nChecking out Revision f4aaf8eaa6f3649542e745a927de5650c15b47fc (origin/stable/grizzly)\n[periodic-glance-docs-grizzly] $ /bin/bash -xe /tmp/hudson6068090440178141713.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack glance\n+ org=openstack\n+ project=glance\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack glance /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=glance\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack glance\n++ org=openstack\n++ project=glance\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack glance /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=glance\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z glance ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/glance /opt/requirements/projects.txt\nopenstack/glance\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/tools/test-requires>\nvenv inst: <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/dist/glance-jenkins.periodic.glance.docs.grizzly.6.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/>\nGenerating doc/source/api/glance.api.authorization.rst\nGenerating doc/source/api/glance.api.cached_images.rst\nGenerating doc/source/api/glance.api.common.rst\nGenerating doc/source/api/glance.api.middleware.cache.rst\nGenerating doc/source/api/glance.api.middleware.cache_manage.rst\nGenerating doc/source/api/glance.api.middleware.context.rst\nGenerating doc/source/api/glance.api.middleware.version_negotiation.rst\nGenerating doc/source/api/glance.api.policy.rst\nGenerating doc/source/api/glance.api.v1.controller.rst\nGenerating doc/source/api/glance.api.v1.filters.rst\nGenerating doc/source/api/glance.api.v1.images.rst\nGenerating doc/source/api/glance.api.v1.members.rst\nGenerating doc/source/api/glance.api.v1.router.rst\nGenerating doc/source/api/glance.api.v2.image_data.rst\nGenerating doc/source/api/glance.api.v2.image_members.rst\nGenerating doc/source/api/glance.api.v2.image_tags.rst\nGenerating doc/source/api/glance.api.v2.images.rst\nGenerating doc/source/api/glance.api.v2.router.rst\nGenerating doc/source/api/glance.api.v2.schemas.rst\nGenerating doc/source/api/glance.api.versions.rst\nGenerating doc/source/api/glance.common.auth.rst\nGenerating doc/source/api/glance.common.client.rst\nGenerating doc/source/api/glance.common.config.rst\nGenerating doc/source/api/glance.common.crypt.rst\nGenerating doc/source/api/glance.common.exception.rst\nGenerating doc/source/api/glance.common.utils.rst\nGenerating doc/source/api/glance.common.wsgi.rst\nGenerating doc/source/api/glance.context.rst\nGenerating doc/source/api/glance.db.migration.rst\nGenerating doc/source/api/glance.db.simple.api.rst\nGenerating doc/source/api/glance.db.sqlalchemy.api.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.schema.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.001_add_images_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.002_add_image_properties_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.003_add_disk_format.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.004_add_checksum.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.005_size_big_integer.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.006_key_to_name.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.007_add_owner.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.008_add_image_members_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.009_add_mindisk_and_minram.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.010_default_update_at.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.011_make_mindisk_and_minram_notnull.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.012_id_to_uuid.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.013_add_protected.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.014_add_image_tags_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.015_quote_swift_credentials.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.016_add_status_image_member.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.017_quote_encrypted_swift_credentials.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.018_add_image_locations_table.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.019_migrate_image_locations.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.020_drop_images_table_location.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.021_set_engine_mysql_innodb.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migrate_repo.versions.022_image_member_index.rst\nGenerating doc/source/api/glance.db.sqlalchemy.migration.rst\nGenerating doc/source/api/glance.db.sqlalchemy.models.rst\nGenerating doc/source/api/glance.domain.proxy.rst\nGenerating doc/source/api/glance.gateway.rst\nGenerating doc/source/api/glance.image_cache.base.rst\nGenerating doc/source/api/glance.image_cache.cleaner.rst\nGenerating doc/source/api/glance.image_cache.client.rst\nGenerating doc/source/api/glance.image_cache.drivers.base.rst\nGenerating doc/source/api/glance.image_cache.drivers.sqlite.rst\nGenerating doc/source/api/glance.image_cache.drivers.xattr.rst\nGenerating doc/source/api/glance.image_cache.prefetcher.rst\nGenerating doc/source/api/glance.image_cache.pruner.rst\nGenerating doc/source/api/glance.notifier.notify_kombu.rst\nGenerating doc/source/api/glance.notifier.notify_log.rst\nGenerating doc/source/api/glance.notifier.notify_noop.rst\nGenerating doc/source/api/glance.notifier.notify_qpid.rst\nGenerating doc/source/api/glance.notifier.strategy.rst\nGenerating doc/source/api/glance.openstack.common.gettextutils.rst\nGenerating doc/source/api/glance.openstack.common.importutils.rst\nGenerating doc/source/api/glance.openstack.common.jsonutils.rst\nGenerating doc/source/api/glance.openstack.common.local.rst\nGenerating doc/source/api/glance.openstack.common.log.rst\nGenerating doc/source/api/glance.openstack.common.notifier.api.rst\nGenerating doc/source/api/glance.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/glance.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/glance.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/glance.openstack.common.policy.rst\nGenerating doc/source/api/glance.openstack.common.setup.rst\nGenerating doc/source/api/glance.openstack.common.strutils.rst\nGenerating doc/source/api/glance.openstack.common.timeutils.rst\nGenerating doc/source/api/glance.openstack.common.uuidutils.rst\nGenerating doc/source/api/glance.openstack.common.version.rst\nGenerating doc/source/api/glance.registry.api.v1.images.rst\nGenerating doc/source/api/glance.registry.api.v1.members.rst\nGenerating doc/source/api/glance.registry.client.rst\nGenerating doc/source/api/glance.schema.rst\nGenerating doc/source/api/glance.store.base.rst\nGenerating doc/source/api/glance.store.filesystem.rst\nGenerating doc/source/api/glance.store.http.rst\nGenerating doc/source/api/glance.store.location.rst\nGenerating doc/source/api/glance.store.rbd.rst\nGenerating doc/source/api/glance.store.s3.rst\nGenerating doc/source/api/glance.store.scrubber.rst\nGenerating doc/source/api/glance.store.swift.rst\nGenerating doc/source/api/glance.tests.functional.db.base.rst\nGenerating doc/source/api/glance.tests.functional.db.test_simple.rst\nGenerating doc/source/api/glance.tests.functional.db.test_sqlalchemy.rst\nGenerating doc/source/api/glance.tests.functional.store.test_filesystem.rst\nGenerating doc/source/api/glance.tests.functional.store.test_http.rst\nGenerating doc/source/api/glance.tests.functional.store.test_s3.rst\nGenerating doc/source/api/glance.tests.functional.store.test_swift.rst\nGenerating doc/source/api/glance.tests.functional.store_utils.rst\nGenerating doc/source/api/glance.tests.functional.test_api.rst\nGenerating doc/source/api/glance.tests.functional.test_bin_glance_cache_manage.rst\nGenerating doc/source/api/glance.tests.functional.test_bin_glance_control.rst\nGenerating doc/source/api/glance.tests.functional.test_cache_middleware.rst\nGenerating doc/source/api/glance.tests.functional.test_client_exceptions.rst\nGenerating doc/source/api/glance.tests.functional.test_client_redirects.rst\nGenerating doc/source/api/glance.tests.functional.test_glance_manage.rst\nGenerating doc/source/api/glance.tests.functional.test_logging.rst\nGenerating doc/source/api/glance.tests.functional.test_scrubber.rst\nGenerating doc/source/api/glance.tests.functional.test_sqlite.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_api.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_copy_to_file.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_misc.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_multiprocessing.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_rbd.rst\nGenerating doc/source/api/glance.tests.functional.v1.test_ssl.rst\nGenerating doc/source/api/glance.tests.functional.v2.test_images.rst\nGenerating doc/source/api/glance.tests.functional.v2.test_schemas.rst\nGenerating doc/source/api/glance.tests.stubs.rst\nGenerating doc/source/api/glance.tests.unit.api.test_common.rst\nGenerating doc/source/api/glance.tests.unit.base.rst\nGenerating doc/source/api/glance.tests.unit.common.test_client.rst\nGenerating doc/source/api/glance.tests.unit.common.test_exception.rst\nGenerating doc/source/api/glance.tests.unit.test_auth.rst\nGenerating doc/source/api/glance.tests.unit.test_cache_middleware.rst\nGenerating doc/source/api/glance.tests.unit.test_clients.rst\nGenerating doc/source/api/glance.tests.unit.test_config.rst\nGenerating doc/source/api/glance.tests.unit.test_context.rst\nGenerating doc/source/api/glance.tests.unit.test_context_middleware.rst\nGenerating doc/source/api/glance.tests.unit.test_db.rst\nGenerating doc/source/api/glance.tests.unit.test_domain.rst\nGenerating doc/source/api/glance.tests.unit.test_domain_proxy.rst\nGenerating doc/source/api/glance.tests.unit.test_filesystem_store.rst\nGenerating doc/source/api/glance.tests.unit.test_glance_replicator.rst\nGenerating doc/source/api/glance.tests.unit.test_http_store.rst\nGenerating doc/source/api/glance.tests.unit.test_image_cache.rst\nGenerating doc/source/api/glance.tests.unit.test_migrations.rst\nGenerating doc/source/api/glance.tests.unit.test_misc.rst\nGenerating doc/source/api/glance.tests.unit.test_notifier.rst\nGenerating doc/source/api/glance.tests.unit.test_policy.rst\nGenerating doc/source/api/glance.tests.unit.test_s3_store.rst\nGenerating doc/source/api/glance.tests.unit.test_schema.rst\nGenerating doc/source/api/glance.tests.unit.test_store_image.rst\nGenerating doc/source/api/glance.tests.unit.test_store_location.rst\nGenerating doc/source/api/glance.tests.unit.test_swift_store.rst\nGenerating doc/source/api/glance.tests.unit.test_utils.rst\nGenerating doc/source/api/glance.tests.unit.test_versions.rst\nGenerating doc/source/api/glance.tests.unit.test_wsgi.rst\nGenerating doc/source/api/glance.tests.unit.utils.rst\nGenerating doc/source/api/glance.tests.unit.v1.test_api.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_data_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_members_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_image_tags_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_images_resource.rst\nGenerating doc/source/api/glance.tests.unit.v2.test_schemas_resource.rst\nGenerating doc/source/api/glance.tests.utils.rst\nGenerating doc/source/api/glance.version.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-docs-grizzly/precise22\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-docs-grizzly/precise22/6\n[SCP] Copying console log.\n\n\n','<2139188722.46.1386741822728.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<154431548.2918464.1419938837199.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-30 06:27:17',-18000,'2014-12-30 11:27:17',NULL,'[Openstack-operators] Neutron DVR HA','Sorry I can\'t open zip files on this email. You need l2pop to not exist\nin the ML2 mechanism drivers list in neutron.conf where the Neutron server\nis, and you need l2population = False in each OVS agent.\n\n----- Original Message -----\n> \n> [Text File:warning1.txt]\n> \n> Hi Asaf,\n> \n> I think I disabled it, but maybe you can check my conf files? I\'ve attached\n> the zip.\n> \n> Thanks\n> \n> On Tue, Dec 30, 2014 at 8:27 AM, Assaf Muller < amuller at redhat.com > wrote:\n> \n> \n> \n> \n> ----- Original Message -----\n> > Hi Britt,\n> > \n> > some update on this after running tcpdump:\n> > \n> > I have keepalived master running on controller01, If I reboot this server\n> > it\n> > failovers to controller02 which now becomes Keepalived Master, then I see\n> > ping packets arriving to controller02, this is good.\n> > \n> > However when the controller01 comes online I see that ping requests stop\n> > being forwarded to controller02 and start being sent to controller01 that\n> > is\n> > now in Backup State, so it stops working.\n> > \n> \n> If traffic is being forwarded to a backup node, that sounds like L2pop is on.\n> Is that true by chance?\n> \n> > Any hint for this?\n> > \n> > Thanks\n> > \n> > \n> > \n> > On Mon, Dec 29, 2014 at 11:06 AM, Pedro Sousa < pgsousa at gmail.com > wrote:\n> > \n> > \n> > \n> > Yes,\n> > \n> > I was using l2pop, disabled it, but the issue remains.\n> > \n> > I also stopped \"bogus VRRP\" messages configuring a user/password for\n> > keepalived, but when I reboot the servers, I see keepalived process running\n> > on them but I cannot ping the virtual router ip address anymore.\n> > \n> > So I rebooted the node that is running Keepalived as Master, starts pinging\n> > again, but when that node comes online, everything stops working. Anyone\n> > experienced this?\n> > \n> > Thanks\n> > \n> > \n> > On Tue, Dec 23, 2014 at 5:03 PM, David Martin < dmartls1 at gmail.com > wrote:\n> > \n> > \n> > \n> > Are you using l2pop? Until https://bugs.launchpad.net/neutron/+bug/1365476\n> > is\n> > fixed it\'s pretty broken.\n> > \n> > On Tue, Dec 23, 2014 at 10:48 AM, Britt Houser (bhouser) <\n> > bhouser at cisco.com\n> > > wrote:\n> > \n> > \n> > \n> > Unfortunately I\'ve not had a chance yet to play with neutron router HA, so\n> > no\n> > hints from me. =( Can you give a little more details about \"it stops\n> > working\"? I.e. You see packets dropped while controller 1 is down? Do\n> > packets begin flowing before controller1 comes back online? Does\n> > controller1\n> > come back online successfully? Do packets begin to flow after controller1\n> > comes back online? Perhaps that will help.\n> > \n> > Thx,\n> > britt\n> > \n> > From: Pedro Sousa < pgsousa at gmail.com >\n> > Date: Tuesday, December 23, 2014 at 11:14 AM\n> > To: Britt Houser < bhouser at cisco.com >\n> > Cc: \" OpenStack-operators at lists.openstack.org \" <\n> > OpenStack-operators at lists.openstack.org >\n> > Subject: Re: [Openstack-operators] Neutron DVR HA\n> > \n> > I understand Britt, thanks.\n> > \n> > So I disabled DVR and tried to test L3_HA, but it\'s not working properly,\n> > it\n> > seems a keepalived issue. I see that it\'s running on 3 nodes:\n> > \n> > [root at controller01 keepalived]# neutron l3-agent-list-hosting-router\n> > harouter\n> > +--------------------------------------+--------------+----------------+-------+\n> > | id | host | admin_state_up | alive |\n> > +--------------------------------------+--------------+----------------+-------+\n> > | 09cfad44-2bb2-4683-a803-ed70f3a46a6a | controller01 | True | :-) |\n> > | 58ff7c42-7e71-4750-9f05-61ad5fbc5776 | compute03 | True | :-) |\n> > | 8d778c6a-94df-40b7-a2d6-120668e699ca | compute02 | True | :-) |\n> > +--------------------------------------+--------------+----------------+-------+\n> > \n> > However if I reboot one of the l3-agent nodes it stops working. I see this\n> > in\n> > the logs:\n> > \n> > Dec 23 16:12:28 Compute02 Keepalived_vrrp[18928]: ip address associated\n> > with\n> > VRID not present in received packet : 172.16.28.20\n> > Dec 23 16:12:28 Compute02 Keepalived_vrrp[18928]: one or more VIP\n> > associated\n> > with VRID mismatch actual MASTER advert\n> > Dec 23 16:12:28 Compute02 Keepalived_vrrp[18928]: bogus VRRP packet\n> > received\n> > on ha-a509de81-1c !!!\n> > Dec 23 16:12:28 Compute02 Keepalived_vrrp[18928]: VRRP_Instance(VR_1)\n> > ignoring received advertisment...\n> > \n> > Dec 23 16:13:10 Compute03 Keepalived_vrrp[12501]: VRRP_Instance(VR_1)\n> > ignoring received advertisment...\n> > Dec 23 16:13:12 Compute03 Keepalived_vrrp[12501]: ip address associated\n> > with\n> > VRID not present in received packet : 172.16.28.20\n> > Dec 23 16:13:12 Compute03 Keepalived_vrrp[12501]: one or more VIP\n> > associated\n> > with VRID mismatch actual MASTER advert\n> > Dec 23 16:13:12 Compute03 Keepalived_vrrp[12501]: bogus VRRP packet\n> > received\n> > on ha-d5718741-ef !!!\n> > Dec 23 16:13:12 Compute03 Keepalived_vrrp[12501]: VRRP_Instance(VR_1)\n> > ignoring received advertisment...\n> > \n> > Any hint?\n> > \n> > Thanks\n> > \n> > \n> > \n> > On Tue, Dec 23, 2014 at 3:17 PM, Britt Houser (bhouser) < bhouser at cisco.com\n> > >\n> > wrote:\n> > \n> > \n> > \n> > Currently HA and DVR are mutually exclusive features.\n> > \n> > From: Pedro Sousa < pgsousa at gmail.com >\n> > Date: Tuesday, December 23, 2014 at 9:42 AM\n> > To: \" OpenStack-operators at lists.openstack.org \" <\n> > OpenStack-operators at lists.openstack.org >\n> > Subject: [Openstack-operators] Neutron DVR HA\n> > \n> > Hi all,\n> > \n> > I\'ve been trying Neutron DVR with 2 controllers + 2 computes. When I create\n> > a\n> > router I can see that is running on all the servers:\n> > \n> > [root at controller01 ~]# neutron l3-agent-list-hosting-router router\n> > +--------------------------------------+--------------+----------------+-------+\n> > | id | host | admin_state_up | alive |\n> > +--------------------------------------+--------------+----------------+-------+\n> > | 09cfad44-2bb2-4683-a803-ed70f3a46a6a | controller01 | True | :-) |\n> > | 0ca01d56-b6dd-483d-9c49-cc7209da2a5a | controller02 | True | :-) |\n> > | 52379f0f-9046-4b73-9d87-bab7f96be5e7 | compute01 | True | :-) |\n> > | 8d778c6a-94df-40b7-a2d6-120668e699ca | compute02 | True | :-) |\n> > +--------------------------------------+--------------+----------------+-------+\n> > \n> > However if controller01 server dies I cannot ping ip external gateway\n> > anymore. Is this the expected behavior? Shouldn\'t it failback to the\n> > another\n> > controller node?\n> > \n> > Thanks\n> > \n> > \n> > _______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> > \n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> > \n> \n> \n\n\n','<CA+E02ZBdq49hgrumij5WsF88g6NkuH3ay7pXLyxF57nbXMZObg@mail.gmail.com>',NULL),('<1544595543.10524739.1352320321769.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-07 15:32:01',-18000,'2012-11-07 20:32:01',NULL,'[openstack-dev] [metering][ceilometer] Unified Instrumentation,\n Metering, Monitoring ...','\n> Here\'s a first pass at a proposal for unifying StackTach/Ceilometer\n> and other instrumentation/metering/monitoring efforts.\n> \n> It\'s v1, so bend, spindle, mutilate as needed ... but send feedback!\n> \n> http://wiki.openstack.org/UnifiedInstrumentationMetering\n\nThanks for putting this together Sandy,\n\nWe were debating on IRC (#heat) earlier the merits of moving the\nceilometer \"emission\" logic into the services, e.g. directly into the\nnova-compute node. At first sight, this seemed to be what you were\ngetting at with the suggestion:\n\n \"Remove the Compute service that Ceilometer uses and integrate the\n  existing fanout compute notifications into the data collected by the\n  workers. There\'s no need for yet-another-worker.\"\n\nWhile this could be feasible for measurements driven directly by\nnotifications, I\'m struggling with the idea of moving say the libvirt\npolling out of the ceilometer compute agent, as this seems to leak too\nmany monitoring-related concerns directly into nova (cadence of polling,\nsemantics of libvirt stats reported etc.).\n\nSo I just wanted to clarify whether the type of low level unification\nyou\'re proposing includes both push & pull (i.e. notification & polling)\nor whether you mainly had just former in mind when it comes to ceilometer.\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF03887708E884@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1544683951.15871302.1381694533504.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-10-13 16:02:13',-14400,'2013-10-13 20:02:13',NULL,'[OpenStack-Infra] Third Party Testing: ServiceAccount for\n posting	reviews','\n\n----- Original Message -----\n> From: \"Sreeram Yerrapragada\" <syerrapragada at vmware.com>\n> To: \"Dan Prince\" <dprince at redhat.com>\n> Cc: openstack-infra at lists.openstack.org\n> Sent: Friday, October 11, 2013 4:17:54 PM\n> Subject: Re: [OpenStack-Infra] Third Party Testing: ServiceAccount for posting	reviews\n> \n> Here is the new name\n> \n> Account Name: VMware Mine Sweeper\n\nNice! Sounds good to me.\n\n> Pub key: <Attached>\n> \n> Thanks,\n> Sreeram\n> \n> ----- Original Message -----\n> From: \"Dan Prince\" <dprince at redhat.com>\n> To: \"Sreeram Yerrapragada\" <syerrapragada at vmware.com>\n> Cc: openstack-infra at lists.openstack.org\n> Sent: Thursday, October 10, 2013 5:24:42 AM\n> Subject: Re: [OpenStack-Infra] Third Party Testing: ServiceAccount for\n> posting	reviews\n> \n> \n> \n> ----- Original Message -----\n> > From: \"Sreeram Yerrapragada\" <syerrapragada at vmware.com>\n> > To: openstack-infra at lists.openstack.org\n> > Sent: Wednesday, October 9, 2013 5:26:47 PM\n> > Subject: [OpenStack-Infra] Third Party Testing: ServiceAccount for posting\n> > 	reviews\n> > \n> > Hi Admin,\n> > \n> > Here at vmware we have setup a Jenkins CI environment based on Gerrit\n> > Plugin\n> > and would like to post reviews. Could you please create a dedicated\n> > account?\n> > \n> > AccountName: \" SmokeSignal \"\n> \n> Cool name, but slightly similar to another 3rd party smoke testing tool\n> (SmokeStack). Any chance you guys would be open to choose something a bit\n> different to avoid confusion?\n> \n> Dan\n> \n> > Public key: <Attached>\n> > \n> > Please let me know if you need any other information.\n> > \n> > Thanks\n> > Sreeram\n> > \n> > _______________________________________________\n> > OpenStack-Infra mailing list\n> > OpenStack-Infra at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n> > \n> \n\n\n','<1986863932.85754324.1381522674902.JavaMail.root@vmware.com>',NULL),('<1544945936.51.1386742043072.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:07:23',0,'2013-12-11 06:07:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-docs-grizzly #4','See <https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/4/>\n\n------------------------------------------\n[...truncated 489 lines...]\nGenerating doc/source/api/nova.tests.fake_hosts.rst\nGenerating doc/source/api/nova.tests.fake_imagebackend.rst\nGenerating doc/source/api/nova.tests.fake_instance_actions.rst\nGenerating doc/source/api/nova.tests.fake_ldap.rst\nGenerating doc/source/api/nova.tests.fake_libvirt_utils.rst\nGenerating doc/source/api/nova.tests.fake_loadables.fake_loadable1.rst\nGenerating doc/source/api/nova.tests.fake_loadables.fake_loadable2.rst\nGenerating doc/source/api/nova.tests.fake_network.rst\nGenerating doc/source/api/nova.tests.fake_network_cache_model.rst\nGenerating doc/source/api/nova.tests.fake_policy.rst\nGenerating doc/source/api/nova.tests.fake_utils.rst\nGenerating doc/source/api/nova.tests.fake_volume.rst\nGenerating doc/source/api/nova.tests.fakeguestfs.rst\nGenerating doc/source/api/nova.tests.fakelibvirt.rst\nGenerating doc/source/api/nova.tests.glance.stubs.rst\nGenerating doc/source/api/nova.tests.hyperv.db_fakes.rst\nGenerating doc/source/api/nova.tests.hyperv.fake.rst\nGenerating doc/source/api/nova.tests.image.fake.rst\nGenerating doc/source/api/nova.tests.image.test_fake.rst\nGenerating doc/source/api/nova.tests.image.test_glance.rst\nGenerating doc/source/api/nova.tests.image.test_s3.rst\nGenerating doc/source/api/nova.tests.integrated.api.client.rst\nGenerating doc/source/api/nova.tests.integrated.integrated_helpers.rst\nGenerating doc/source/api/nova.tests.integrated.test_api_samples.rst\nGenerating doc/source/api/nova.tests.integrated.test_extensions.rst\nGenerating doc/source/api/nova.tests.integrated.test_login.rst\nGenerating doc/source/api/nova.tests.integrated.test_multiprocess_api.rst\nGenerating doc/source/api/nova.tests.integrated.test_servers.rst\nGenerating doc/source/api/nova.tests.integrated.test_xml.rst\nGenerating doc/source/api/nova.tests.matchers.rst\nGenerating doc/source/api/nova.tests.monkey_patch_example.example_a.rst\nGenerating doc/source/api/nova.tests.monkey_patch_example.example_b.rst\nGenerating doc/source/api/nova.tests.network.security_group.test_quantum_driver.rst\nGenerating doc/source/api/nova.tests.network.test_api.rst\nGenerating doc/source/api/nova.tests.network.test_deprecated_api.rst\nGenerating doc/source/api/nova.tests.network.test_linux_net.rst\nGenerating doc/source/api/nova.tests.network.test_manager.rst\nGenerating doc/source/api/nova.tests.network.test_network_info.rst\nGenerating doc/source/api/nova.tests.network.test_quantumv2.rst\nGenerating doc/source/api/nova.tests.network.test_rpcapi.rst\nGenerating doc/source/api/nova.tests.policy_fixture.rst\nGenerating doc/source/api/nova.tests.scheduler.fakes.rst\nGenerating doc/source/api/nova.tests.scheduler.test_chance_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_filter_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_host_filters.rst\nGenerating doc/source/api/nova.tests.scheduler.test_host_manager.rst\nGenerating doc/source/api/nova.tests.scheduler.test_least_cost.rst\nGenerating doc/source/api/nova.tests.scheduler.test_multi_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_rpcapi.rst\nGenerating doc/source/api/nova.tests.scheduler.test_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_scheduler_options.rst\nGenerating doc/source/api/nova.tests.scheduler.test_weights.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_db_servicegroup.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_mc_servicegroup.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_zk_driver.rst\nGenerating doc/source/api/nova.tests.test_api.rst\nGenerating doc/source/api/nova.tests.test_availability_zones.rst\nGenerating doc/source/api/nova.tests.test_bdm.rst\nGenerating doc/source/api/nova.tests.test_block_device.rst\nGenerating doc/source/api/nova.tests.test_cinder.rst\nGenerating doc/source/api/nova.tests.test_configdrive2.rst\nGenerating doc/source/api/nova.tests.test_context.rst\nGenerating doc/source/api/nova.tests.test_crypto.rst\nGenerating doc/source/api/nova.tests.test_db_api.rst\nGenerating doc/source/api/nova.tests.test_driver.rst\nGenerating doc/source/api/nova.tests.test_exception.rst\nGenerating doc/source/api/nova.tests.test_fakelibvirt.rst\nGenerating doc/source/api/nova.tests.test_filters.rst\nGenerating doc/source/api/nova.tests.test_hooks.rst\nGenerating doc/source/api/nova.tests.test_hypervapi.rst\nGenerating doc/source/api/nova.tests.test_image_utils.rst\nGenerating doc/source/api/nova.tests.test_imagebackend.rst\nGenerating doc/source/api/nova.tests.test_imagecache.rst\nGenerating doc/source/api/nova.tests.test_instance_types.rst\nGenerating doc/source/api/nova.tests.test_instance_types_extra_specs.rst\nGenerating doc/source/api/nova.tests.test_iptables_network.rst\nGenerating doc/source/api/nova.tests.test_ipv6.rst\nGenerating doc/source/api/nova.tests.test_libvirt.rst\nGenerating doc/source/api/nova.tests.test_libvirt_blockinfo.rst\nGenerating doc/source/api/nova.tests.test_libvirt_config.rst\nGenerating doc/source/api/nova.tests.test_libvirt_utils.rst\nGenerating doc/source/api/nova.tests.test_libvirt_vif.rst\nGenerating doc/source/api/nova.tests.test_libvirt_volume.rst\nGenerating doc/source/api/nova.tests.test_linuxscsi.rst\nGenerating doc/source/api/nova.tests.test_loadables.rst\nGenerating doc/source/api/nova.tests.test_matchers.rst\nGenerating doc/source/api/nova.tests.test_metadata.rst\nGenerating doc/source/api/nova.tests.test_migration_utils.rst\nGenerating doc/source/api/nova.tests.test_migrations.rst\nGenerating doc/source/api/nova.tests.test_misc.rst\nGenerating doc/source/api/nova.tests.test_notifications.rst\nGenerating doc/source/api/nova.tests.test_nova_manage.rst\nGenerating doc/source/api/nova.tests.test_objectstore.rst\nGenerating doc/source/api/nova.tests.test_periodic_tasks.rst\nGenerating doc/source/api/nova.tests.test_pipelib.rst\nGenerating doc/source/api/nova.tests.test_plugin_api_extensions.rst\nGenerating doc/source/api/nova.tests.test_policy.rst\nGenerating doc/source/api/nova.tests.test_powervm.rst\nGenerating doc/source/api/nova.tests.test_quota.rst\nGenerating doc/source/api/nova.tests.test_safeutils.rst\nGenerating doc/source/api/nova.tests.test_service.rst\nGenerating doc/source/api/nova.tests.test_test.rst\nGenerating doc/source/api/nova.tests.test_test_utils.rst\nGenerating doc/source/api/nova.tests.test_utils.rst\nGenerating doc/source/api/nova.tests.test_versions.rst\nGenerating doc/source/api/nova.tests.test_virt.rst\nGenerating doc/source/api/nova.tests.test_virt_disk.rst\nGenerating doc/source/api/nova.tests.test_virt_disk_vfs_guestfs.rst\nGenerating doc/source/api/nova.tests.test_virt_disk_vfs_localfs.rst\nGenerating doc/source/api/nova.tests.test_virt_drivers.rst\nGenerating doc/source/api/nova.tests.test_vmmode.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vif.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vm_util.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vmops.rst\nGenerating doc/source/api/nova.tests.test_wsgi.rst\nGenerating doc/source/api/nova.tests.test_xenapi.rst\nGenerating doc/source/api/nova.tests.utils.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_api.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_loop.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_nbd.rst\nGenerating doc/source/api/nova.tests.virt.hyperv.test_vhdutils.rst\nGenerating doc/source/api/nova.tests.virt.test_images.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.imageupload.test_glance.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.test_vm_utils.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.test_volumeops.rst\nGenerating doc/source/api/nova.tests.vmwareapi.db_fakes.rst\nGenerating doc/source/api/nova.tests.vmwareapi.stubs.rst\nGenerating doc/source/api/nova.tests.xenapi.stubs.rst\nGenerating doc/source/api/nova.tests.xenapi.test_vm_utils.rst\nGenerating doc/source/api/nova.utils.rst\nGenerating doc/source/api/nova.version.rst\nGenerating doc/source/api/nova.virt.baremetal.baremetal_states.rst\nGenerating doc/source/api/nova.virt.baremetal.base.rst\nGenerating doc/source/api/nova.virt.baremetal.db.api.rst\nGenerating doc/source/api/nova.virt.baremetal.db.migration.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.api.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.001_init.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.002_drop_bm_deployments.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.003_add_uuid_to_bm_nodes.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.004_add_instance_name_to_bm_nodes.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migration.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.models.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.session.rst\nGenerating doc/source/api/nova.virt.baremetal.driver.rst\nGenerating doc/source/api/nova.virt.baremetal.fake.rst\nGenerating doc/source/api/nova.virt.baremetal.ipmi.rst\nGenerating doc/source/api/nova.virt.baremetal.pxe.rst\nGenerating doc/source/api/nova.virt.baremetal.utils.rst\nGenerating doc/source/api/nova.virt.baremetal.vif_driver.rst\nGenerating doc/source/api/nova.virt.baremetal.virtual_power_driver.rst\nGenerating doc/source/api/nova.virt.baremetal.virtual_power_driver_settings.rst\nGenerating doc/source/api/nova.virt.baremetal.volume_driver.rst\nGenerating doc/source/api/nova.virt.configdrive.rst\nGenerating doc/source/api/nova.virt.disk.api.rst\nGenerating doc/source/api/nova.virt.disk.mount.api.rst\nGenerating doc/source/api/nova.virt.disk.mount.loop.rst\nGenerating doc/source/api/nova.virt.disk.mount.nbd.rst\nGenerating doc/source/api/nova.virt.disk.vfs.api.rst\nGenerating doc/source/api/nova.virt.disk.vfs.guestfs.rst\nGenerating doc/source/api/nova.virt.disk.vfs.localfs.rst\nGenerating doc/source/api/nova.virt.driver.rst\nGenerating doc/source/api/nova.virt.event.rst\nGenerating doc/source/api/nova.virt.fake.rst\nGenerating doc/source/api/nova.virt.firewall.rst\nGenerating doc/source/api/nova.virt.hyperv.basevolumeutils.rst\nGenerating doc/source/api/nova.virt.hyperv.constants.rst\nGenerating doc/source/api/nova.virt.hyperv.driver.rst\nGenerating doc/source/api/nova.virt.hyperv.hostops.rst\nGenerating doc/source/api/nova.virt.hyperv.hostutils.rst\nGenerating doc/source/api/nova.virt.hyperv.imagecache.rst\nGenerating doc/source/api/nova.virt.hyperv.livemigrationops.rst\nGenerating doc/source/api/nova.virt.hyperv.livemigrationutils.rst\nGenerating doc/source/api/nova.virt.hyperv.migrationops.rst\nGenerating doc/source/api/nova.virt.hyperv.networkutils.rst\nGenerating doc/source/api/nova.virt.hyperv.pathutils.rst\nGenerating doc/source/api/nova.virt.hyperv.snapshotops.rst\nGenerating doc/source/api/nova.virt.hyperv.vhdutils.rst\nGenerating doc/source/api/nova.virt.hyperv.vif.rst\nGenerating doc/source/api/nova.virt.hyperv.vmops.rst\nGenerating doc/source/api/nova.virt.hyperv.vmutils.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeops.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeutils.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeutilsv2.rst\nGenerating doc/source/api/nova.virt.images.rst\nGenerating doc/source/api/nova.virt.libvirt.blockinfo.rst\nGenerating doc/source/api/nova.virt.libvirt.config.rst\nGenerating doc/source/api/nova.virt.libvirt.designer.rst\nGenerating doc/source/api/nova.virt.libvirt.driver.rst\nGenerating doc/source/api/nova.virt.libvirt.firewall.rst\nGenerating doc/source/api/nova.virt.libvirt.imagebackend.rst\nGenerating doc/source/api/nova.virt.libvirt.imagecache.rst\nGenerating doc/source/api/nova.virt.libvirt.utils.rst\nGenerating doc/source/api/nova.virt.libvirt.vif.rst\nGenerating doc/source/api/nova.virt.libvirt.volume.rst\nGenerating doc/source/api/nova.virt.libvirt.volume_nfs.rst\nGenerating doc/source/api/nova.virt.netutils.rst\nGenerating doc/source/api/nova.virt.powervm.blockdev.rst\nGenerating doc/source/api/nova.virt.powervm.command.rst\nGenerating doc/source/api/nova.virt.powervm.common.rst\nGenerating doc/source/api/nova.virt.powervm.constants.rst\nGenerating doc/source/api/nova.virt.powervm.driver.rst\nGenerating doc/source/api/nova.virt.powervm.exception.rst\nGenerating doc/source/api/nova.virt.powervm.lpar.rst\nGenerating doc/source/api/nova.virt.powervm.operator.rst\nGenerating doc/source/api/nova.virt.storage_users.rst\nGenerating doc/source/api/nova.virt.virtapi.rst\nGenerating doc/source/api/nova.virt.vmwareapi.driver.rst\nGenerating doc/source/api/nova.virt.vmwareapi.error_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.fake.rst\nGenerating doc/source/api/nova.virt.vmwareapi.host.rst\nGenerating doc/source/api/nova.virt.vmwareapi.io_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.network_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.read_write_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vif.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vim.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vim_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vm_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vmops.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vmware_images.rst\nGenerating doc/source/api/nova.virt.vmwareapi.volume_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.volumeops.rst\nGenerating doc/source/api/nova.virt.xenapi.agent.rst\nGenerating doc/source/api/nova.virt.xenapi.driver.rst\nGenerating doc/source/api/nova.virt.xenapi.fake.rst\nGenerating doc/source/api/nova.virt.xenapi.firewall.rst\nGenerating doc/source/api/nova.virt.xenapi.host.rst\nGenerating doc/source/api/nova.virt.xenapi.imageupload.glance.rst\nGenerating doc/source/api/nova.virt.xenapi.network_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.pool.rst\nGenerating doc/source/api/nova.virt.xenapi.pool_states.rst\nGenerating doc/source/api/nova.virt.xenapi.vif.rst\nGenerating doc/source/api/nova.virt.xenapi.vm_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.vmops.rst\nGenerating doc/source/api/nova.virt.xenapi.volume_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.volumeops.rst\nGenerating doc/source/api/nova.vnc.xvp_proxy.rst\nGenerating doc/source/api/nova.volume.cinder.rst\nGenerating doc/source/api/nova.weights.rst\nGenerating doc/source/api/nova.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-grizzly/precise20\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-grizzly/precise20/4\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1545004568.2104129.1418746426731.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 11:13:46',-18000,'2014-12-16 16:13:46',NULL,'[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday December\n 17th @ 1400 UTC in #openstack-meeting-alt','Hi all,\n\nJust a reminder that the Telco Working Group will be meeting @ 1400 UTC in #openstack-meeting on Wednesday December 17th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add items. Note that I would also like to propose that we skip the meetings which would have fallen on December 24th and December 31st due to it being a holiday period for many participants. This would make the next meeting following this one January 7th.\n\nThanks,\n\nSteve\n\n\n','<62420988.2067575.1418743794299.JavaMail.zimbra@redhat.com>',NULL),('<1545004568.2104129.1418746426731.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-16 11:13:46',-18000,'2014-12-16 16:13:46',NULL,'[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday\n December 17th @ 1400 UTC in #openstack-meeting-alt','Hi all,\n\nJust a reminder that the Telco Working Group will be meeting @ 1400 UTC in #openstack-meeting on Wednesday December 17th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add items. Note that I would also like to propose that we skip the meetings which would have fallen on December 24th and December 31st due to it being a holiday period for many participants. This would make the next meeting following this one January 7th.\n\nThanks,\n\nSteve\n\n\n','<62420988.2067575.1418743794299.JavaMail.zimbra@redhat.com>',NULL),('<1545184603.25.1383114589824.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-30 06:29:49',0,'2013-10-30 06:29:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #43','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/43/>\n\n------------------------------------------\n[...truncated 15132 lines...]\n2013-10-30 06:06:03,673 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=RunInstances&ImageId=ami-00000001&InstanceType=m1.nano&KernelId=aki-00000003&KeyName=keypair-115425&MaxCount=1&MinCount=1&RamdiskId=ari-00000002&SecurityGroup.1=securitygroup-813653&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A03Z&Version=2011-12-15\n2013-10-30 06:06:03,673 len(b64)=44\n2013-10-30 06:06:03,673 base64 encoded digest: IobEzDBdG0gUyV3/ym0oUzhmOie8p2mMFbBnjC+1RUA=\n2013-10-30 06:06:03,673 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=RunInstances&ImageId=ami-00000001&InstanceType=m1.nano&KernelId=aki-00000003&KeyName=keypair-115425&MaxCount=1&MinCount=1&RamdiskId=ari-00000002&SecurityGroup.1=securitygroup-813653&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A03Z&Version=2011-12-15 Signature: IobEzDBdG0gUyV3/ym0oUzhmOie8p2mMFbBnjC+1RUA=\n2013-10-30 06:06:04,146 <?xml version=\"1.0\" ?><RunInstancesResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-e1ea8cdc-0f5f-4553-aa9b-bf3067c8cfe2</requestId><ownerId>5f129ddaacbf4681b5bebed29c3df47b</ownerId><groupSet><item><groupId>securitygroup-813653</groupId></item></groupSet><reservationId>r-zu2k8b5u</reservationId><instancesSet><item><placement><availabilityZone>nova</availabilityZone></placement><rootDeviceType>instance-store</rootDeviceType><keyName>keypair-115425</keyName><instanceId>i-00000001</instanceId><instanceState><code>0</code><name>pending</name></instanceState><publicDnsName/><imageId>ami-00000001</imageId><productCodesSet/><privateDnsName>server-15d80a51-a09a-4c52-a504-bda1bd0b2b4b</privateDnsName><dnsName>server-15d80a51-a09a-4c52-a504-bda1bd0b2b4b</dnsName><launchTime>2013-10-30T06:06:04.000Z</launchTime><amiLaunchIndex>0</amiLaunchIndex><rootDeviceName>/dev/sda1</rootDeviceName><kernelId>aki-00000003</kernelId><ramdiskId>ari-00000002</ramdiskId><ipAddress/><instanceType>m1.nano</instanceType><privateIpAddress/></item></instancesSet></RunInstancesResponse>\n2013-10-30 06:06:04,147 Method: POST\n2013-10-30 06:06:04,148 Path: /services/Cloud/\n2013-10-30 06:06:04,148 Data: \n2013-10-30 06:06:04,148 Headers: {}\n2013-10-30 06:06:04,148 Host: 127.0.0.1:8773\n2013-10-30 06:06:04,148 establishing HTTP connection: kwargs={\'timeout\': 30}\n2013-10-30 06:06:04,148 Token: None\n2013-10-30 06:06:04,148 using _calc_signature_2\n2013-10-30 06:06:04,148 query string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=CreateVolume&AvailabilityZone=nova&SignatureMethod=HmacSHA256&SignatureVersion=2&Size=1&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,148 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=CreateVolume&AvailabilityZone=nova&SignatureMethod=HmacSHA256&SignatureVersion=2&Size=1&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,148 len(b64)=44\n2013-10-30 06:06:04,148 base64 encoded digest: guTA4HJwkwqTP0zgKtms/ml8UHNZN+XJ5UGh/my1lNQ=\n2013-10-30 06:06:04,148 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=CreateVolume&AvailabilityZone=nova&SignatureMethod=HmacSHA256&SignatureVersion=2&Size=1&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15 Signature: guTA4HJwkwqTP0zgKtms/ml8UHNZN+XJ5UGh/my1lNQ=\n2013-10-30 06:06:04,655 <?xml version=\"1.0\" ?><CreateVolumeResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-535e4427-f694-4d07-a903-3a8b86b336f6</requestId><status>creating</status><availabilityZone>nova</availabilityZone><volumeId>vol-00000001</volumeId><attachmentSet><item/></attachmentSet><snapshotId/><createTime>2013-10-30T06:06:04.530601</createTime><size>1</size></CreateVolumeResponse>\n2013-10-30 06:06:04,655 closing all HTTP connections\n2013-10-30 06:06:04,655 state: pending\n2013-10-30 06:06:04,656 Method: POST\n2013-10-30 06:06:04,656 Path: /services/Cloud/\n2013-10-30 06:06:04,656 Data: \n2013-10-30 06:06:04,656 Headers: {}\n2013-10-30 06:06:04,656 Host: 127.0.0.1:8773\n2013-10-30 06:06:04,656 Token: None\n2013-10-30 06:06:04,656 using _calc_signature_2\n2013-10-30 06:06:04,656 query string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,656 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,656 len(b64)=44\n2013-10-30 06:06:04,656 base64 encoded digest: SHG9092hrkFjjYlIYe7E4UWzYqDIh5l9OsX7+BKl0Es=\n2013-10-30 06:06:04,656 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15 Signature: SHG9092hrkFjjYlIYe7E4UWzYqDIh5l9OsX7+BKl0Es=\n2013-10-30 06:06:04,834 <?xml version=\"1.0\" ?><DescribeInstancesResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-001459f5-0069-4c0f-89ee-83b21cd877fc</requestId><reservationSet><item><ownerId>5f129ddaacbf4681b5bebed29c3df47b</ownerId><groupSet><item><groupId>securitygroup-813653</groupId></item></groupSet><reservationId>r-zu2k8b5u</reservationId><instancesSet><item><placement><availabilityZone>nova</availabilityZone></placement><rootDeviceType>instance-store</rootDeviceType><keyName>keypair-115425</keyName><instanceId>i-00000001</instanceId><instanceState><code>0</code><name>error</name></instanceState><publicDnsName/><imageId>ami-00000001</imageId><productCodesSet/><privateDnsName>server-15d80a51-a09a-4c52-a504-bda1bd0b2b4b</privateDnsName><dnsName>server-15d80a51-a09a-4c52-a504-bda1bd0b2b4b</dnsName><launchTime>2013-10-30T06:06:04.000Z</launchTime><amiLaunchIndex>0</amiLaunchIndex><rootDeviceName>/dev/sda1</rootDeviceName><kernelId>aki-00000003</kernelId><ramdiskId>ari-00000002</ramdiskId><ipAddress/><instanceType>m1.nano</instanceType><privateIpAddress/></item></instancesSet></item></reservationSet></DescribeInstancesResponse>\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: tempest.tests.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[smoke]\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/boto/test_ec2_instance_run.py\", line 105, in test_run_stop_terminate_instance\n    self.assertInstanceStateWait(instance, \"running\")\n  File \"/opt/stack/new/tempest/tempest/testboto.py\", line 348, in assertInstanceStateWait\n    state = self.waitInstanceState(lfunction, wait_for)\n  File \"/opt/stack/new/tempest/tempest/testboto.py\", line 333, in waitInstanceState\n    self.valid_instance_state)\n  File \"/opt/stack/new/tempest/tempest/testboto.py\", line 324, in state_wait_gone\n    self.assertIn(state, valid_set | self.gone_set)\n  File \"/usr/local/lib/python2.7/dist-packages/testtools/testcase.py\", line 328, in assertIn\n    self.assertThat(haystack, Contains(needle))\n  File \"/usr/local/lib/python2.7/dist-packages/testtools/testcase.py\", line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: u\'error\' not in set([\'paused\', \'terminated\', \'running\', \'stopped\', \'pending\', \'_GONE\', \'stopping\', \'shutting-down\'])\n\n-------------------- >> begin captured logging << --------------------\n2013-10-30 06:06:04,850 Method: POST\n2013-10-30 06:06:04,850 Path: /services/Cloud/\n2013-10-30 06:06:04,850 Data: \n2013-10-30 06:06:04,850 Headers: {}\n2013-10-30 06:06:04,850 Host: 127.0.0.1:8773\n2013-10-30 06:06:04,851 establishing HTTP connection: kwargs={\'timeout\': 30}\n2013-10-30 06:06:04,851 Token: None\n2013-10-30 06:06:04,851 using _calc_signature_2\n2013-10-30 06:06:04,851 query string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeImages&ImageId.1=ami-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,851 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeImages&ImageId.1=ami-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15\n2013-10-30 06:06:04,851 len(b64)=44\n2013-10-30 06:06:04,851 base64 encoded digest: FoopZ8oSsKLboUc4ZU9HN81OcmzWF3Y91X7je6u1J2U=\n2013-10-30 06:06:04,851 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeImages&ImageId.1=ami-00000001&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A04Z&Version=2011-12-15 Signature: FoopZ8oSsKLboUc4ZU9HN81OcmzWF3Y91X7je6u1J2U=\n2013-10-30 06:06:05,068 <?xml version=\"1.0\" ?><DescribeImagesResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-086348bd-5b84-4f80-8b88-408d45bf7a2c</requestId><imagesSet><item><description/><imageOwnerId>5f129ddaacbf4681b5bebed29c3df47b</imageOwnerId><isPublic>false</isPublic><imageId>ami-00000001</imageId><imageState>available</imageState><architecture>x86_64</architecture><imageLocation>s3bucket-159703/cirros-0.3.1-x86_64-blank.img.manifest.xml</imageLocation><rootDeviceType>instance-store</rootDeviceType><rootDeviceName>/dev/sda1</rootDeviceName><imageType>machine</imageType><name>ami-name-43463</name></item></imagesSet></DescribeImagesResponse>\n2013-10-30 06:06:05,069 closing all HTTP connections\n2013-10-30 06:06:05,069 Method: POST\n2013-10-30 06:06:05,069 Path: /services/Cloud/\n2013-10-30 06:06:05,069 Data: \n2013-10-30 06:06:05,069 Headers: {}\n2013-10-30 06:06:05,069 Host: 127.0.0.1:8773\n2013-10-30 06:06:05,069 Token: None\n2013-10-30 06:06:05,069 using _calc_signature_2\n2013-10-30 06:06:05,069 query string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=RunInstances&ImageId=ami-00000001&InstanceType=m1.nano&KernelId=aki-00000003&MaxCount=1&MinCount=1&RamdiskId=ari-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15\n2013-10-30 06:06:05,070 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=RunInstances&ImageId=ami-00000001&InstanceType=m1.nano&KernelId=aki-00000003&MaxCount=1&MinCount=1&RamdiskId=ari-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15\n2013-10-30 06:06:05,070 len(b64)=44\n2013-10-30 06:06:05,070 base64 encoded digest: aDZjQBBEewIbeOxrFFppqOTS/6FFKtvnQWlxsjLdN6A=\n2013-10-30 06:06:05,070 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=RunInstances&ImageId=ami-00000001&InstanceType=m1.nano&KernelId=aki-00000003&MaxCount=1&MinCount=1&RamdiskId=ari-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15 Signature: aDZjQBBEewIbeOxrFFppqOTS/6FFKtvnQWlxsjLdN6A=\n2013-10-30 06:06:05,503 <?xml version=\"1.0\" ?><RunInstancesResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-9fb9c9e3-86fc-4539-bad2-3125214ba067</requestId><ownerId>5f129ddaacbf4681b5bebed29c3df47b</ownerId><groupSet><item><groupId>default</groupId></item></groupSet><reservationId>r-qmm02msg</reservationId><instancesSet><item><placement><availabilityZone>nova</availabilityZone></placement><rootDeviceType>instance-store</rootDeviceType><keyName/><instanceId>i-00000002</instanceId><instanceState><code>0</code><name>pending</name></instanceState><publicDnsName/><imageId>ami-00000001</imageId><productCodesSet/><privateDnsName>server-56244b78-5a8f-4ad0-ac98-4d544dea0d84</privateDnsName><dnsName>server-56244b78-5a8f-4ad0-ac98-4d544dea0d84</dnsName><launchTime>2013-10-30T06:06:05.000Z</launchTime><amiLaunchIndex>0</amiLaunchIndex><rootDeviceName>/dev/sda1</rootDeviceName><kernelId>aki-00000003</kernelId><ramdiskId>ari-00000002</ramdiskId><ipAddress/><instanceType>m1.nano</instanceType><privateIpAddress/></item></instancesSet></RunInstancesResponse>\n2013-10-30 06:06:05,504 state: pending\n2013-10-30 06:06:05,504 Method: POST\n2013-10-30 06:06:05,504 Path: /services/Cloud/\n2013-10-30 06:06:05,504 Data: \n2013-10-30 06:06:05,504 Headers: {}\n2013-10-30 06:06:05,504 Host: 127.0.0.1:8773\n2013-10-30 06:06:05,504 Token: None\n2013-10-30 06:06:05,504 using _calc_signature_2\n2013-10-30 06:06:05,504 query string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15\n2013-10-30 06:06:05,504 string_to_sign: POST\n127.0.0.1:8773\n/services/Cloud/\nAWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15\n2013-10-30 06:06:05,504 len(b64)=44\n2013-10-30 06:06:05,504 base64 encoded digest: h+5w/7G9q3VsafQV1Rt6KgM3tfG7+d++GvIBOOxVnjo=\n2013-10-30 06:06:05,504 query_string: AWSAccessKeyId=e0938fb037574111b9c384dbc896b130&Action=DescribeInstances&InstanceId.1=i-00000002&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2013-10-30T06%3A06%3A05Z&Version=2011-12-15 Signature: h+5w/7G9q3VsafQV1Rt6KgM3tfG7+d++GvIBOOxVnjo=\n2013-10-30 06:06:05,691 <?xml version=\"1.0\" ?><DescribeInstancesResponse xmlns=\"http://ec2.amazonaws.com/doc/2011-12-15/\"><requestId>req-8ef7f6ae-a899-4fea-aa2f-2604bc91ac65</requestId><reservationSet><item><ownerId>5f129ddaacbf4681b5bebed29c3df47b</ownerId><groupSet><item><groupId>default</groupId></item></groupSet><reservationId>r-qmm02msg</reservationId><instancesSet><item><placement><availabilityZone>nova</availabilityZone></placement><rootDeviceType>instance-store</rootDeviceType><keyName/><instanceId>i-00000002</instanceId><instanceState><code>0</code><name>error</name></instanceState><publicDnsName/><imageId>ami-00000001</imageId><productCodesSet/><privateDnsName>server-56244b78-5a8f-4ad0-ac98-4d544dea0d84</privateDnsName><dnsName>server-56244b78-5a8f-4ad0-ac98-4d544dea0d84</dnsName><launchTime>2013-10-30T06:06:05.000Z</launchTime><amiLaunchIndex>0</amiLaunchIndex><rootDeviceName>/dev/sda1</rootDeviceName><kernelId>aki-00000003</kernelId><ramdiskId>ari-00000002</ramdiskId><ipAddress/><instanceType>m1.nano</instanceType><privateIpAddress/></item></instancesSet></item></reservationSet></DescribeInstancesResponse>\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 826 tests in 1371.334s\n\nFAILED (SKIP=73, failures=2)\nERROR: InvocationError: \'/usr/local/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-full.xml -sv tempest\'\nfull runtests: commands[1] | nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\nWARNING:test command found but not installed in testenv\n  cmd: /usr/local/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/full\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... SKIP: version is empty, bug 1138844\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-cli.xml\n----------------------------------------------------------------------\nRan 54 tests in 32.414s\n\nOK (SKIP=4)\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-619325-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-619325.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-619325/43/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1545FDFF136B45DF82EA0866058D696A@cloudscaling.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-25 16:58:25',-14400,'2012-09-25 20:58:25',NULL,'[openstack-dev] Quantum + ZeroMQ (with a sprinkling of Nova) in\n	Folsom','The reason for the change is because subscription happen on the first element. We were only doing push/pull and depending on the matchmaker before, so the order wasn\'t significant. With the addition of actual pub/sub, this change becomes necessary.\n\nWith better matchmakers, as I expect to land in Grizzly, this will be less an issue, although it might still be seen as an optimization in that case. \n\nRegards,\nEric Windisch\n\n\nOn Tuesday, September 25, 2012 at 16:55 PM, Russell Bryant wrote:\n\n> On 09/25/2012 04:53 PM, Eric Windisch wrote:\n> > Note that before this patch, it wasn\'t at all compatible with Quantum. \n> > \n> > Even leaving Nova as it is, it could simply be \"unsupported\" in Quantum.\n> > \n> > For Grizzly, we can either opt to revert this change to the message format, or\n> > support versioning.\n> \n> \n> \n> Can you elaborate on the purpose of the format change?\n> \n> Is this it? Why not just swap them back and leave it how it was?\n> \n> - self.outq.send([str(msg_id), str(topic), str(\'cast\'),\n> + self.outq.send([str(topic), str(msg_id), str(\'cast\'),\n> \n> \n> -- \n> Russell Bryant\n\n\n\n\n\n','<50621A2D.1060104@redhat.com>',NULL),('<154610874.205.1366265219402.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-18 06:06:59',0,'2013-04-18 06:06:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #8','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/8/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-18 06:06:53    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-18 06:06:53,861 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-18 06:06:53,862 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-18 06:06:53,863 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53,863 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53,864 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-18 06:06:53,864 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-18 06:06:53,865 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-18 06:06:53  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-18 06:06:53,866 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-18 06:06:53    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-18 06:06:53,866 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:53,870 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:53.869901\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:53.869901\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:53,871 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53,871 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53,872 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:53,873 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:53     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:53,874 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:53.873321\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:53.873321\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:53,874 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53,875 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53,876 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-18 06:06:53,876 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:53,877 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:53    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:54,019 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54,021 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.019109\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.019109\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54,022 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,023 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54,024 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-18 06:06:54,025 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,026 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:54,028 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54,029 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.028572\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.028572\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54,030 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,031 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54,032 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-18 06:06:54,033 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,034 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:54,036 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-18 06:06:54,038 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-18 06:06:54,039 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.038693\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-18T06:06:54.038693\', resource_metadata={}) from 0 transformer\n2013-04-18 06:06:54,041 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,042 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54,043 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-18 06:06:54,044 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-18 06:06:54,045 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-18 06:06:54    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 21.928s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.8\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a325.gd8e81f6\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.sLFEWS9ybm\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/8\n[SCP] Copying console log.\n\n\n','<1729404483.187.1366178830050.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<154662044.5.1384930247335.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-20 06:50:47',0,'2013-11-20 06:50:47',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all-stable-havana #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all-stable-havana/2/>\n\n\n\n',NULL,NULL),('<1546787551.1023187.1397229584810.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-11 17:19:44',7200,'2014-04-11 15:19:44',NULL,'[openstack-dev] more oslo liaisons needed','> I see that several projects have their Oslo liaisons lined up\n> (https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons). It would be\n> great if we had at least one volunteer from each project before the\n> summit, so we can get a head start on the coordination work.\n\nHi Doug,\n\nI\'d be happy to handle the role for Heat.\n\nCheers,\n\n-- \nThomas\n\n\n','<CADb+p3T4DHhnvHfMgnhCnuR-sFC=__zXDy9xV+PXDib4ZuoM3g@mail.gmail.com>',NULL),('<1546876298.418.1367129046878.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:04:06',0,'2013-04-28 06:04:06',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-docs-stable-folsom #209','See <https://jenkins.openstack.org/job/periodic-glance-docs-stable-folsom/209/>\n\n\n\n','<210439519.360.1367042608229.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1546eb4ed5184ef8bcbd892fa0c9592d@BN1PR05MB076.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-08-13 04:06:15',0,'2013-08-13 04:06:15',NULL,'[OpenStack Foundation] Foundation Digest, Vol 21, Issue 8','We\'re happy to host at Nebula in Mountain View if you guys want to do something in south bay.\n\nChris\n\n\nChris C. Kemp | CEO\nOffice: 650.539.9901 | Cell: 650.898.7783\n?\nNebula, Inc. | www.nebula.com\n215 Castro Street| Mountain View, CA 94041\n\n\n-----Original Message-----\nFrom: foundation-request at lists.openstack.org [mailto:foundation-request at lists.openstack.org] \nSent: Monday, August 12, 2013 8:11 PM\nTo: foundation at lists.openstack.org\nSubject: Foundation Digest, Vol 21, Issue 8\n\nSend Foundation mailing list submissions to\n	foundation at lists.openstack.org\n\nTo subscribe or unsubscribe via the World Wide Web, visit\n	http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\nor, via email, send a message with subject or body \'help\' to\n	foundation-request at lists.openstack.org\n\nYou can reach the person managing the list at\n	foundation-owner at lists.openstack.org\n\nWhen replying, please edit your Subject line so it is more specific than \"Re: Contents of Foundation digest...\"\n\n\nToday\'s Topics:\n\n   1. Re: [Foundation Board] [openstack-tc] Spider / What is Core\n      Discussion opportunity: SJC or SFO 8/27 evening (Kyle MacDonald)\n   2. Re: [Foundation Board] Spider / What is Core	Discussion\n      opportunity: SJC or SFO 8/27 evening (Joshua McKenty)\n\n\n----------------------------------------------------------------------\n\nMessage: 1\nDate: Mon, 12 Aug 2013 17:05:32 -0700\nFrom: Kyle MacDonald <kyle.macdonald at canonical.com>\nTo: John Dickinson <me at not.mn>\nCc: \"foundation at lists.openstack.org\" <foundation at lists.openstack.org>,\n	\"foundation-board at lists.openstack.org\"\n	<foundation-board at lists.openstack.org>,\n	\"openstack-tc at lists.openstack.org\" <openstack-tc at lists.openstack.org>,\n	\"Rob_Hirschfeld at dell.com\" <Rob_Hirschfeld at dell.com>\nSubject: Re: [OpenStack Foundation] [Foundation Board] [openstack-tc]\n	Spider / What is Core Discussion opportunity: SJC or SFO 8/27 evening\nMessage-ID: <5453800316225166129 at unknownmsgid>\nContent-Type: text/plain; charset=windows-1252\n\nI would attend in SF as well\nKyle\n\nSent from my iPhone\n\nOn Aug 12, 2013, at 4:59 PM, John Dickinson <me at not.mn> wrote:\n\n> I\'d love to. I\'m in (ie live and work in) San Francisco, so I can do something here.\n>\n> --john\n>\n>\n>\n> On Aug 12, 2013, at 12:24 PM, Rob_Hirschfeld at Dell.com wrote:\n>\n>> All,\n>>\n>> I?m going to be in the Bay Area and available in the evening on 8/27.  Is anyone interested in having a face-to-face meeting about core that night?\n>>\n>> I?ve got a meeting downtown in San Fran until 5, so I?m happy to meet there or take the train south for a 6:30 meeting.\n>>\n>> If there?s interest, will someone local take a lead in getting a location?  I think it?s reasonable to setup a hangout for remote people too.\n>>\n>> Rob\n>> ______________________________\n>> Rob Hirschfeld\n>> Sr. Distinguished Cloud Solution Architect Dell | Cloud Edge, Data \n>> Center Solutions blog robhirschfeld.com, twitter @zehicle Please \n>> note, I am based in the CENTRAL (-6) time zone\n>>\n>> _______________________________________________\n>> OpenStack-TC mailing list\n>> OpenStack-TC at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n>\n> _______________________________________________\n> Foundation-board mailing list\n> Foundation-board at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n\n\n\n------------------------------\n\nMessage: 2\nDate: Mon, 12 Aug 2013 20:10:43 -0700\nFrom: Joshua McKenty <joshua at pistoncloud.com>\nTo: \"Evans, Eileen\" <eileen.evans at hp.com>\nCc: foundation <foundation at lists.openstack.org>, foundation-board\n	<foundation-board at lists.openstack.org>, openstack-tc\n	<openstack-tc at lists.openstack.org>\nSubject: Re: [OpenStack Foundation] [Foundation Board] Spider / What\n	is Core	Discussion opportunity: SJC or SFO 8/27 evening\nMessage-ID: <37B5478F-DEA7-4BDE-950E-F4D01692DE9F at pistoncloud.com>\nContent-Type: text/plain; charset=\"windows-1252\"\n\nObviously none of you are going to the VMworld parties? but I am, and I think Rob\'s heard more than enough of my opinions on core already ;)\n\nSeriously, though, I\'m sad to miss the discussion. Maybe I\'ll try and join late.\n--\n\nJoshua McKenty\nChief Technology Officer\nPiston Cloud Computing, Inc.\n+1 (650) 242-5683\n+1 (650) 283-6846\nhttp://www.pistoncloud.com\n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\nOn Aug 12, 2013, at 6:41 PM, \"Evans, Eileen\" <eileen.evans at hp.com> wrote:\n\n> Thanks, Rob!  I could also get us space at HP?s offices in Palo Alto (off of Page Mill). \n>  \n> Best,\n> Eileen\n>  \n> From: John Mark Walker [mailto:johnmark at redhat.com]\n> Sent: Monday, August 12, 2013 4:52 PM\n> To: Dave Nielsen\n> Cc: foundation; foundation-board; openstack-tc\n> Subject: Re: [Foundation Board] [OpenStack Foundation] Spider / What \n> is Core Discussion opportunity: SJC or SFO 8/27 evening\n>  \n> I could probably get some space in Red Hat\'s office in Mountain View - let me know. It\'s reasonably close to CalTrain - I would need names and affiliations by 8/26.\n>  \n> We\'re also hosting a Gluster Community workshop at Rackspace\'s SF office that day - I could try to see about getting a space there after we\'re finished (5pm).\n>  \n> -John Mark Walker\n> Gluster Community Leader, Red Hat\n>  \n>  \n>  \n> I\'m in as well and would prefer mid/south bay. If no one offers space in SF, then I can get us space in mid-peninsula at SVForum office in Redwood Shores or in south bay at HP Cloud just off 101/237. Or I can find us a space near the Caltrain station in Mountain View. \n>  \n> Anyone else want to attend so we can break the tie?\n> \n> Dave\n>  \n> On Mon, Aug 12, 2013 at 3:50 PM, Sean Roberts <seanrob at yahoo-inc.com> wrote:\n> I\'m available as well. Mid or south bay as preference, but I could make SF.\n>  \n> \n> Sean Roberts\n> Infrastructure Strategy\n> seanrob at yahoo-inc.com (925) 980-4729\n> \n> \n> On Aug 12, 2013, at 12:24 PM, Rob_Hirschfeld at Dell.com wrote:\n>  \n> All,\n>  \n> I?m going to be in the Bay Area and available in the evening on 8/27.  Is anyone interested in having a face-to-face meeting about core that night?\n>  \n> I?ve got a meeting downtown in San Fran until 5, so I?m happy to meet there or take the train south for a 6:30 meeting.\n>  \n> If there?s interest, will someone local take a lead in getting a location?  I think it?s reasonable to setup a hangout for remote people too.\n>  \n> Rob\n> ______________________________\n> Rob Hirschfeld\n> Sr. Distinguished Cloud Solution Architect Dell | Cloud Edge, Data \n> Center Solutions blog robhirschfeld.com, twitter @zehicle Please note, \n> I am based in the CENTRAL (-6) time zone\n>  \n> _______________________________________________\n> Foundation-board mailing list\n> Foundation-board at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n>  \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> \n>  \n> \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>  \n> _______________________________________________\n> Foundation-board mailing list\n> Foundation-board at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation-board\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130812/dad59e83/attachment.html>\n\n------------------------------\n\n_______________________________________________\nFoundation mailing list\nFoundation at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n\n\nEnd of Foundation Digest, Vol 21, Issue 8\n*****************************************\n\n\n','<mailman.4642.1376363445.785.foundation@lists.openstack.org>',NULL),('<1547816722.86.1353889025737.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-26 00:17:05',0,'2012-11-26 00:17:05',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #56','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/56/>\n\n\n\n','<443511296.64.1353802098370.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1547906396.28.1380953445876.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-05 06:10:45',0,'2013-10-05 06:10:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #38','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/38/>\n\n------------------------------------------\n[...truncated 13538 lines...]\n    s,%COMPUTE_DB_URI%,mysql://root:secret at localhost/nova,g;\n    s,%IMAGE_HOST%,127.0.0.1,g;\n    s,%IMAGE_PORT%,9292,g;\n    s,%IMAGE_API_VERSION%,1,g;\n    s,%IMAGE_CATALOG_TYPE%,image,g;\n    s,%COMPUTE_ADMIN_USERNAME%,admin,g;\n    s,%COMPUTE_ADMIN_PASSWORD%,secret,g;\n    s,%COMPUTE_ADMIN_TENANT_NAME%,admin,g;\n    s,%IDENTITY_ADMIN_USERNAME%,admin,g;\n    s,%IDENTITY_ADMIN_PASSWORD%,secret,g;\n    s,%IDENTITY_ADMIN_TENANT_NAME%,admin,g;\n    s,%NETWORK_CATALOG_TYPE%,network,g;\n    s,%NETWORK_API_VERSION%,2.0,g;\n    s,%VOLUME_CATALOG_TYPE%,volume,g;\n    s,%VOLUME_BUILD_INTERVAL%,3,g;\n    s,%VOLUME_BUILD_TIMEOUT%,300,g;\n\' -i /opt/stack/new/tempest/etc/tempest.conf\n+ echo \'Created tempest configuration file:\'\nCreated tempest configuration file:\n+ cat /opt/stack/new/tempest/etc/tempest.conf\n[identity]\n# This section contains configuration options that a variety of Tempest\n# test clients use when authenticating with different user/tenant\n# combinations\n\n# Set to True if your test environment\'s Keystone authentication service should\n# be accessed over HTTPS\nuse_ssl = False\n# This is the main host address of the authentication service API\nhost = 127.0.0.1\n# Port that the authentication service API is running on\nport = 5000\n# Version of the authentication service API (a string)\napi_version = v2.0\n# Path to the authentication service tokens resource (do not modify unless you\n# have a custom authentication API and are not using Keystone)\npath = tokens\n# Should typically be left as keystone unless you have a non-Keystone\n# authentication API service\nstrategy = keystone\n\n[compute]\n# This section contains configuration options used when executing tests\n# against the OpenStack Compute API.\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_isolation = True\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_reuse = True\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n# This should be the username of an alternate user WITHOUT\n# administrative privileges\nalt_username = alt_demo\n# The above non-administrative user\'s password\nalt_password = secret\n# The above non-administrative user\'s tenant name\nalt_tenant_name = alt_demo\n\n# Reference data for tests. The ref and ref_alt should be\n# distinct images/flavors.\nimage_ref = c24f3c44-0968-44b6-b161-53cb80ea220a\nimage_ref_alt = c24f3c44-0968-44b6-b161-53cb80ea220a\nflavor_ref = 1\nflavor_ref_alt = 2\n\n# Number of seconds to wait while looping to check the status of an\n# instance that is building.\nbuild_interval = 3\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nchown: cannot access `/opt/stack/data/tempest\': No such file or directory\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-507688-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-507688.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/screen-swift.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az1-507688/38/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<375659657.23.1380867013927.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1548350183.59.1386744948435.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-11 06:55:48',0,'2013-12-11 06:55:48',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-dsvm-neutron-large-ops-havana #8','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-large-ops-havana/8/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827773 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-large-ops-havana/ws/>\n[periodic-tempest-dsvm-neutron-large-ops-havana] $ /bin/bash -xe /tmp/hudson381051397205186529.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: Unable to find 9e06327193e2aa23b488c3c566f13acd3f03de87 under https://review.openstack.org/p/openstack-infra/devstack-gate\nCannot obtain needed object 9e06327193e2aa23b488c3c566f13acd3f03de87\nerror: Fetch failed.\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-large-ops-havana/devstack-precise-hpcloud-az2-827773\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-large-ops-havana/devstack-precise-hpcloud-az2-827773/8\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1548467.pe66lqcK7A@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-28 11:26:46',7200,'2014-08-28 09:26:46',NULL,'[Openstack] Clean ovs ports','Hello,\n\nUnfortunatelly now I have no possibility to check it on newer release (but I \nwill try). Those ports exists in neutron and IMHO it is correct because \ninstance is not deleted but only shutdown (or suspended) so IP is still \n\"reserver\" for this vm - am I correct?\nSecond thing is that IMHO problem is not in neutron or ovs agent but more on \nnova because as I know nova-compute should remove port (tapXXX) from br-int \nbridge and then ovs agent \"knows\" that port was deleted - is it correct?\nI check that if I remove port from bridge manually than in next loop ovs agent \nwill clean everythink because he find that port is not exists.\nI\'m not using vlans but vxlan network on that hosts :)\n\n--\nPozdrawiam,\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\n--\nKlucz GPG mo?na pobra? ze strony:\nhttp://kaplonski.pl/files/slawek_kaplonski.pub.key\n--\nMy public GPG key can be downloaded from:\nhttp://kaplonski.pl/files/slawek_kaplonski.pub.key\n\nDnia czwartek, 28 sierpnia 2014 09:47:23 Salvatore Orlando pisze:\n> Hi,\n> \n> it would be good if you can confirm whether this behaviour affects icehouse\n> or trunk as well.\n> Several bugs concerning nova/neutron communication as well as ovs agent\n> handling of ports have been fixed during the last two release cycle.\n> While the stable team did a great job in back-porting those fixes, some\n> were not applied because they were too extensive.\n> Are these \"leftover\" ports only present on the OVS agent, or do you see\n> them in neutron as well? In the former case the problem might be mitigated\n> as suggested by Martinx.\n> \n> Another thing to check is whether these ports are wired or not. If they are\n> on the \"dead\" VLAN (4095), then they\'re not wired, and while they surely\n> represent a nuisance they will not be harmful.\n> As Havana is now approaching EOL [1], I would focus on establishing whether\n> this behaviour affects more recent releases as well.\n> \n> Regards,\n> Salvatore\n> \n> [1]\n> https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fhavana_\n> releases\n> On 28 August 2014 04:14, Martinx - ????? <thiagocmartinsc at gmail.com> wrote:\n> > Sometimes I need to run \"sudo service neutron-ovs-cleanup restart ; sudo\n> > reboot\", on both Network Node and/or at the Compute Nodes too...\n> > Rebooting alone isn\'t allways enough...\n> > \n> > On 27 August 2014 20:37, ?? <yanchao727 at gmail.com> wrote:\n> >> Same questions here. I sometimes use ovs-vsctl command before manually.\n> >> \n> >> *Best Regards?*\n> >> \n> >> \n> >> *Chao Yan--------------**My twitter?Andy Yan @yanchao727\n> >> <https://twitter.com/yanchao727>*\n> >> \n> >> \n> >> *My Weibo?http://weibo.com/herewearenow\n> >> <http://weibo.com/herewearenow>--------------*\n> >> \n> >> 2014-08-28 5:26 GMT+08:00 S?awek Kap?o?ski <slawek at kaplonski.pl>:\n> >>>  Hello,\n> >>> \n> >>> I\'m using Openstack havana release with neutron. Neutron is with ML2\n> >>> plugin\n> >>> and ovs_agents on hosts. Today I found that if for some reason compute\n> >>> host is\n> >>> for example rebooted and before restartt there was some instances on\n> >>> host than\n> >>> after restart instances are in state \"SHUTOFF\" and are not configured in\n> >>> virsh\n> >>> on compute host but nova-compute not remove ports from openvswitch\n> >>> br-int\n> >>> bridge and I ovs agent see those ports are still configured on host.\n> >>> Is it known bug maybe? Maybe someone of You know some solution of that?\n> >>> Thanks\n> >>> in advance for any info about that.\n> >>> \n> >>> --\n> >>> Pozdrawiam,\n> >>> S?awek Kap?o?ski\n> >>> slawek at kaplonski.pl\n> >>> \n> >>> --\n> >>> Klucz GPG mo?na pobra? ze strony:\n> >>> http://kaplonski.pl/files/slawek_kaplonski.pub.key\n> >>> --\n> >>> My public GPG key can be downloaded from:\n> >>> http://kaplonski.pl/files/slawek_kaplonski.pub.key\n> >>> _______________________________________________\n> >>> Mailing list:\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >>> Post to     : openstack at lists.openstack.org\n> >>> Unsubscribe :\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >> \n> >> _______________________________________________\n> >> Mailing list:\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >> Post to     : openstack at lists.openstack.org\n> >> Unsubscribe :\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > \n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140828/24b974d8/attachment.pgp>\n\n','<CAGR=i3ggYJfx-_=h14aTvdwfJk4NOnJ6XOXWyzPz+=2GyqUO+w@mail.gmail.com>',NULL),('<1548980612.34708001.1355747590346.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-17 07:33:10',-18000,'2012-12-17 12:33:10',NULL,'[openstack-dev] [nova][quotas] quota accounting\n	for	failed	resource creation','\n\n> > Eoghan Glynn wrote:\n> >\n> > So the main point here is whether we really want to ensure\n> > that quota isn\'t consumed for failed resource creation\n> > attempts?\n>\n> Vishvananda Ishaya wrote:\n> \n> I don\'t think we do. If something goes into ERROR it should still\n> count against quota until it is explicitly deleted by the user.\n\nOK, fair enough if that was a deliberate change in policy when\nthe nova scheduler run_instance logic was reworked for Folsom.\n\nSo if quota consumption for a new instance is no longer contingent\non a suitable host being found by the scheduler, should we also\nstop having the quota deltas for an instance resize depend on\nit successfully reaching the FINISH state?\n\nOr is there a case for retaining the special quota handling logic\nfor resize, given the additional complexity involved? (i.e. it\nbeing a two-stage process, with an explicit revert/confirm step).\n\n> Malini Bhandaru wrote:\n> \n> Vish\'s response -- error still counts as quota consumed till deleted\n> jives, else it would leave open a way for denial of service by\n> requesting error-prone activity,m example, starting up a VM with a\n> bad image etc.\n\nYep, good point about DoS attack vulnerability.\n\nCheers,\nEoghan\n\n\n','<EE6FFF4F6C34C84C8C98DD2414EEA47E2F047B1C@FMSMSX105.amr.corp.intel.com>',NULL),('<1549326626.75.1379831630362.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-22 06:33:50',0,'2013-09-22 06:33:50',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #28','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/28/>\n\n------------------------------------------\n[...truncated 20982 lines...]\n======================================================================\nFAIL: setUpClass (tempest.api.compute.images.test_images_oneserver.ImagesOneServerTestXML)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/images/test_images_oneserver.py\", line 48, in setUpClass\n    resp, cls.server = cls.create_server(wait_until=\'ACTIVE\')\n  File \"tempest/api/compute/base.py\", line 142, in create_server\n    server[\'id\'], kwargs[\'wait_until\'])\n  File \"tempest/services/compute/xml/servers_client.py\", line 340, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 6766f724-75e7-4276-a5e5-00d368b9f1e4 failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.compute.images.test_list_image_filters.ListImageFiltersTestJSON)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/images/test_list_image_filters.py\", line 42, in setUpClass\n    resp, cls.server2 = cls.create_server(wait_until=\'ACTIVE\')\n  File \"tempest/api/compute/base.py\", line 142, in create_server\n    server[\'id\'], kwargs[\'wait_until\'])\n  File \"tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 87382d05-0421-4353-9742-c42e5dde6cbe failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.compute.images.test_list_image_filters.ListImageFiltersTestXML)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/images/test_list_image_filters.py\", line 42, in setUpClass\n    resp, cls.server2 = cls.create_server(wait_until=\'ACTIVE\')\n  File \"tempest/api/compute/base.py\", line 142, in create_server\n    server[\'id\'], kwargs[\'wait_until\'])\n  File \"tempest/services/compute/xml/servers_client.py\", line 340, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 25881b67-d950-4bc6-b49b-d0bce7d25eab failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.compute.servers.test_create_server.ServersTestJSON)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/servers/test_create_server.py\", line 55, in setUpClass\n    cls.client.wait_for_server_status(cls.server_initial[\'id\'], \'ACTIVE\')\n  File \"tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server c62638e2-e306-4689-80ed-1dfdd3bf499a failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.compute.servers.test_instance_actions.InstanceActionsTestJSON)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/servers/test_instance_actions.py\", line 30, in setUpClass\n    resp, server = cls.create_server(wait_until=\'ACTIVE\')\n  File \"tempest/api/compute/base.py\", line 142, in create_server\n    server[\'id\'], kwargs[\'wait_until\'])\n  File \"tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server e6c4bc03-9921-4c44-97e1-7d0f3f58fd11 failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.compute.servers.test_instance_actions.InstanceActionsTestXML)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/servers/test_instance_actions.py\", line 30, in setUpClass\n    resp, server = cls.create_server(wait_until=\'ACTIVE\')\n  File \"tempest/api/compute/base.py\", line 142, in create_server\n    server[\'id\'], kwargs[\'wait_until\'])\n  File \"tempest/services/compute/xml/servers_client.py\", line 340, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server d4ccc36e-819f-4827-8811-d6c5ca3b2059 failed to build and is in ERROR status\n======================================================================\nFAIL: setUpClass (tempest.api.volume.test_volumes_actions.VolumesActionsTestXML)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/volume/test_volumes_actions.py\", line 40, in setUpClass\n    cls.servers_client.wait_for_server_status(cls.server[\'id\'], \'ACTIVE\')\n  File \"tempest/services/compute/xml/servers_client.py\", line 340, in wait_for_server_status\n    return waiters.wait_for_server_status(self, server_id, status)\n  File \"tempest/common/waiters.py\", line 71, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server bc36bf4f-b0ac-49d4-b461-630436e9fd45 failed to build and is in ERROR status\n======================================================================\nFAIL: tempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntags: worker-1\n----------------------------------------------------------------------\nEmpty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-22 06:25:54,107 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:25:54,195 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_minimum_basic.py\", line 153, in test_minimum_basic_scenario\n    self.nova_boot()\n  File \"tempest/scenario/test_minimum_basic.py\", line 92, in nova_boot\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-1299805964> failed to get to expected status.                           In ERROR state.\n======================================================================\nFAIL: tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntags: worker-1\n----------------------------------------------------------------------\nEmpty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-22 06:25:58,071 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:25:58,198 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:25:58,917 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:25:59,011 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:26:00,567 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:26:01,694 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:26:02,784 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:26:03,861 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 129, in test_volume_boot_pattern\n    keypair)\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 53, in _boot_instance_from_volume\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-496430295> failed to get to expected status.                           In ERROR state.\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: tearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\ntags: worker-3\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/thirdparty/boto/test.py\", line 270, in tearDownClass\n    raise exceptions.TearDownException(num=fail_count)\nTearDownException: 2 cleanUp operation failed\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2286 tests in 1518.860s\nFAILED (id=0, failures=74, skips=48)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-365856-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-365856.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-365856/28/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1550161938.13473879.1400945224631.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-24 11:27:04',-14400,'2014-05-24 15:27:04',NULL,'[openstack-dev] Election Stats and Review Discussion','\n\n> One of the things that OpenStack does really well is review our process\n> for various activities. I don\'t believe we have had a discussion in the\n> past reviewing our electoral process and I think it would be good to\n> have this discussion.\n> \n> There are two issues that I feel need to be addressed:\n> Item One: the health of our voter engagement for the tc election\n> Item Two: messaging around campaigning\n> others may feel additional issues need some airtime, if you can think of\n> other issues affection our election process for ptl and/or tc elections,\n> do add your item to the list.\n> \n> Item One:\n>     the health of our voter engagement for the tc election\n> \n> Going by voter turnout, the health of individual programs as reflected\n> in the ptl voter turnout statistics is sound (43.5% voter turnout or\n> better) however the health of the voter turnout for the tc election\n> process could tolerate some scrutiny.\n> \n> For the April 2014 tc election the voter turnout was 29.7%. We have had\n> a total of three tc elections in the history of OpenStack and our voter\n> turnout percentage is dropping.\n> First TC Election, March 2013: 33.6% voter turnout\n> Second TC Election, October 2013: 30.9% voter turnout\n> Third TC Election, April 2014: 29.7% voter turnout\n\nIMO the single biggest factor dampening down interest in the TC\nelections would be the staggered terms, such that only circa half\nthe seats are contested in each election.\n\nThis, I feel, undermines the sense of there being a potential for\nan overall \"changing of the guard\" occurring on each cycle.\n\nI appreciate that the current model is in place to ensure some degree\nof continuity across cycles, but I suspect much of that continuity\nwould emerge naturally in any case ... i.e. if we were to change over\nto an  all-seats-up-for-grabs model, I suspect the overall outcome\nwouldn\'t actually be that different in terms of the TC composition.\n\nHowever, it might make for a more open contest, and feel like less of\nforegone conclusion ... possibly with the last few seats being contested\nby candidates with less of a \"traditional\" openstack backgroud (e.g.\nfrom one of the smaller projects on the edge of the ecosystem, or even\nfrom the user/operator community).\n\nAnd that might be just the ticket to reverse the perception of voter\napathy.\n\n> Now our actual votes cast are increasing, but the size of the electorate\n> is increasing faster, with proportionally fewer ATCs voting\n> March 2013: 208 votes cast, 619 authorized voters\n> October 2013: 342 votes cast, 1106 authorized voters\n> April 2014: 448 votes cast, 1510 authorized voters\n> \n> I would like for there to be a discussion around voter engagement in the\n> tc election.\n> \n> Item Two:\n>     messaging around campaigning\n> \n> Right now we have no messaging around election campaigning and I think\n> we should have some.\n> \n> Specifically I feel we should state that the TC requires candidates and\n> their backers to campaign in the spirit of the OpenStack ideals\n> (Openness, Transparency, Commonality, Integration, Quality...)  as\n> stated in the TC mission statement[footnote] while refraining from\n> sending unsolicited email and also refraining from holding privately\n> sponsored campaign events. Campaigning is expected to be done in the\n> open with public access to links and content available to all.\n\nAgree with the spirit of the above, but I do feel we should be able\nto rely on a \"gentleperson\'s agreement\" between the candidates to\nplay fair and allow their individual record stand for itself.\n\nCheers,\nEoghan\n\n> I welcome your participation in this discussion.\n> \n> Thank you,\n> Anita.\n> anteaya\n> \n> [footnote] The  Technical Committee (\"TC\") is tasked with providing the\n> technical  leadership for OpenStack as a whole (all official programs,\n> as defined  below). It enforces OpenStack ideals (Openness,\n> Transparency,  Commonality, Integration, Quality...), decides on issues\n> affecting  multiple programs, forms an ultimate appeals board for\n> technical  decisions, and generally has oversight over all the OpenStack\n> project.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<537F5EF0.9080000@anteaya.info>',NULL),('<1550399775.62.1375769558310.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:12:38',0,'2013-08-06 06:12:38',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #312','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/312/>\n\n\n\n','<1624397192.50.1375682578683.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1550760654.1489200.1374006896607.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-16 16:34:56',-14400,'2013-07-16 20:34:56',NULL,'[openstack-dev] [OSLO] Comments/Questions on Messaging Wiki','\n\n----- Original Message -----\n> \n> \n> ----- Original Message -----\n> > Hi William,\n> > \n> > I think Doug has done a good job of answering all these, but here\'s\n> > another set of answers to make sure there\'s no confusion :)\n> > \n> > On Fri, 2013-07-12 at 17:40 -0400, William Henry wrote:\n> > > Hi all,\n> > > \n> > > I\'ve been reading through the Messaging Wiki and have some comments.\n> > \n> > The docs generated from the code are now up on:\n> > \n> >   http://docs.openstack.org/developer/oslo.messaging/\n> > \n> > There should be some useful clarifying stuff in there too. Indeed some\n> > of thinking has moved on a bit since the wiki page was written.\n> > \n> > >  Not criticisms, just comments and questions.\n> > > I have found this to be a very useful document. Thanks.\n> > > \n> > > 1. \"There are multiple backend transport drivers which implement the\n> > > API semantics using different messaging systems - e.g. RabbitMQ, Qpid,\n> > > ZeroMQ. While both sides of a connection must use the same transport\n> > > driver configured in the same way, the API avoids exposing details of\n> > > transports so that code written using one transport should work with\n> > > any other transport.\"\n> > > \n> > > The good news for AMQP 1.0 users is that technically \"boths sides of\n> > > the connection\" do not have to use same transport driver. In pre-AMQP\n> > > 1.0 days this was the case. But today interoperability between AMQP\n> > > 1.0 implementations has been demonstrated.\n> > \n> > Yeah, the point was more that like you need to use the zmq driver on\n> > both sides.\n> > \n> > I could imagine us having multiple \"amqp 1.0\" interoperable drivers. I\n> > don\'t know what the use case would be for using one of those drivers on\n> > one side and another on the other side, but there\'s no reason why it\n> > should be impossible.\n> > \n> > > 2. I notice under the RPC concepts section that you mention Exchanges\n> > > as a container in which topics are scoped. Is this exchange a pre AMQP\n> > > 1.0 artifact or just a general term for oslo.messaging that is loosely\n> > > based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you\n> > > assuming that messaging implementations have something called an\n> > > exchange? Or do you mean that messaging implementations can scope a\n> > > topic and in oslo we call that scoping an exchange?\n> > \n> > Yeah, it really is only loosely related to the AMQP concept.\n> > \n> > It\'s purely a namespace thing. You could e.g. have two Nova deployments\n> > with exactly the same messaging transport (and e.g. sending messages\n> > over the same broker, using the same topic names, etc.) and you could\n> > keep them separated from one another by using a different exchange name\n> > for each.\n> > \n> > The reason we\'ve stuck with the name \"exchange\" is that we have a\n> > \"control_exchange\" configuration variable (defaulting to e.g. \'nova\')\n> > that servers roughly this purpose now and we want to continue using it\n> > rather than renaming it to something else.\n> > \n> > Which raises a point about all of this - we need to be able to\n> > interoperate with existing OpenStack deployments using the current RPC\n> > code. So, we really don\'t have the luxury of changing on-the-wire\n> > formats, basic messaging semantics, configuration settings, etc.\n> > \n> > oslo.messaging is mostly about cleaning up the python API which services\n> > use to issue/receive RPCs and send notifications.\n> > \n> > > 3. Some messaging nomenclature: The way the wiki describes RPC \"\n> > > Invoke Method on One of Multiple Servers \" is more like a queue than a\n> > > topic. In messaging a queue is something that multiple consumers can\n> > > attach to and one of them gets and services a message/request. A topic\n> > > is where 1+ consumers are \"connected\" and each receives a the message\n> > > and each can service it as it sees fit. In pre-AMQP 1.0 terms what\n> > > this seems to describe is a direct exchange. And a direct excahnge can\n> > > have multiple consumers listening to a queue on that exchange.\n> > > (Remember that fanout is just a generalization of topic in that all\n> > > consumers get all fanout messages - there are no sub-topics etc.)\n> > > \n> > > In AMQP 1.0 the addressing doesn\'t care or know about exchanges but it\n> > > can support this queue type behavior on an address or topic type\n> > > behavior on an address.\n> > > \n> > > I know this isn\'t about AMQP specifically but therefore this is even\n> > > more important. Topics are pub/sub with multiple consumer/services\n> > > responding to a single message. Queues are next consumer up gets the\n> > > next message.\n> > > \n> > > (BTW I\'ve seen this kind of confusion also in early versions of\n> > > MCollective in Puppet.)\n> > > \n> > > It might be better to change some of the references to \"topic\" to\n> > > \"address\". This would solve the problem. i.e. a use case where one of\n> > > many servers listening on an address services a message/request. And\n> > > later all of servers listening on an address service a\n> > > message/request. Addressing also solves the one-to-one as the address\n> > > is specific to the server (and the others don\'t have to receive and\n> > > reject the message).\n> > \n> > It sounds to me like the qpid-proton based transport driver could easily\n> > map the semantics we expect from topic/fanout to amqp 1.0 addresses.\n> > \n> > The \'topic\' nomenclature is pretty baked in the various services doing\n> > RPC and notifications, especially in the naming of configuration\n> > options.\n> > \n> > The basic semantics is a nova compute service listens on the \'compute\'\n> > topic on the \'nova\' exchange and a client can cause a method to be\n> > invoked on the service with either of the following targets:\n> > \n> >   Target(exchange=\'nova\', topic=\'compute\')\n> >   Target(exchange=\'nova\', topic=\'compute\', server=\'compute1\')\n> >   Target(exchange=\'nova\', topic=\'compute\', fanout=True)\n> > \n> > In the first case, any compute service will do. In the second, you want\n> > to invoke the method on a particular compute service. The the latter\n> > case, you want to invoke it on all compute services.\n> \n> This really helps understand some of what I\'ve read. Thanks.\n> \n> It seems that exchange is really just a high level qualifier of a namespace\n> for the most part.\n> \n> Q: if in the above last Target, fanout was false (fanout=False) would that\n> mean that you are expecting queue type behavior in that instance? i.e. I\n> want only one consumer, I don\'t care which one, but only one consumer to\n> service this request? So that syntax would change the semantics from pub/sub\n> topic (i.e. all subscribers to the topic get it) to a queue semantic (first\n> consumer to acquire the message causes it to dequeue and be not available t\n> others?\n\nActually rereading this I think it does. i.e. the first example is essentially fanout=false.\n\nWilliam\n\n> \n> William\n> \n> > \n> > Cheers,\n> > Mark.\n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n\n\n','<370789647.1487096.1374006465223.JavaMail.root@redhat.com>',NULL),('<155079401.151.1366006723721.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-15 06:18:43',0,'2013-04-15 06:18:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-grizzly #5','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 1155 lines...]\n    test_raw_json_schema                                         OK    0.00\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.00\nTestStoreImage\n    test_image_delayed_delete                                    OK    0.00\n    test_image_delete                                            OK    0.00\n    test_image_get_data                                          OK    0.00\n    test_image_set_data                                          OK    0.00\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_cache_manage.TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_cache_manage.py\",> line 182, in test_queue\n    ids[x] = self.add_image(\"Image%s\" % x)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_cache_manage.py\",> line 60, in add_image\n    self.assertEqual(response.status, 201)\nMismatchError: 500 != 201\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 87.08 secs:\n    25.40    TestScrubber.test_scrubber_app\n    19.91    TestScrubber.test_delayed_delete\n    14.33    TestGlanceControl.test_reload\n    14.09    TestGlanceControl.test_respawn\n    13.35    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1102 tests in 499.198s\n\nFAILED (SKIP=55, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.8.0\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python27.stable.grizzly.5\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.30\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.SCrUykGDG6\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/5\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<155164242.77kQXviHPJ@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 19:17:04',7200,'2014-04-01 17:17:04',NULL,'[openstack-dev] devstack: Unable to restart rabbitmq-server','Le mardi 1 avril 2014, 12:17:39 John Eckersberg a ?crit :\n> An update has been submitted for Fedora 20 which corrects this issue:\n> \n> https://admin.fedoraproject.org/updates/rabbitmq-server-3.1.5-4.fc20\n> \n> Please give it a try and if it works for you, be sure to leave karma on\n> the update so it gets pushed to stable faster.\n\nOh great! I tested it and it works with SELinux configured in Enforcing.\n\nI tried to submit a +1 using bodhi but it requests a password, and I don\'t \nknow which password it is.\n\nVictor\n\n\n','<878urpf2ho.fsf@redhat.com>',NULL),('<1551742596.203301413226869692.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-10-13 19:01:09',0,'2014-10-13 19:01:09',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting October 20, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting October 20, 2014\nHost: Alan Clark\nDate: Monday, October 20, 2014\nTime: 12:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 494 240 739\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t230172299ea955c4a9409d7a5290a9ba\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t86a1b0988458fb1a6a75ae42c609e71b\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=299781583&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 494 240 739\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tcefa7decc62fa24da796affeb027ad3f\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20141013/0a049e7e/attachment.html>\n\n',NULL,NULL),('<1551765232.35453180.1402764228780.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-14 12:43:48',-14400,'2014-06-14 16:43:48',NULL,'[Openstack] _member_ role after keystone installation','----- Original Message -----\n> From: \"Ageeleshwar Kandavelu\" <Ageeleshwar.Kandavelu at csscorp.com>\n> To: \"Ricardo Carrillo Cruz\" <ricardo.carrillo.cruz at gmail.com>\n> \n> I recently installed icehouse and never created that role but it exists.\n> \n> Please see if its present in the db.\n> root at sun:~# mysql keystone -e \'select * from role;\'\n> +----------------------------------+----------+---------------------------------------------------------------------------+\n> | id                               | name     | extra\n> | |\n> +----------------------------------+----------+---------------------------------------------------------------------------+\n> | 9fe2ff9ee4384b1894a90878d3e92bab | _member_ | {\"enabled\": \"True\",\n> | \"description\": \"Default role for project membership\"} |\n> +----------------------------------+----------+---------------------------------------------------------------------------+\n> \n> This is populated when you run keystone-manage db_sync\n> \n> Thank you,\n> Ageeleshwar K\n\nYes, it\'s supposed to be created by the db creation/migration scripts if it\'s not there (since Grizzly if I recall correctly).\n\n-Steve\n\n\n','<7CE078CE0FB4A743B287BF573132B9771B819220@INCHEAMVW033.ad.csscorp.com>',NULL),('<1551888012.47.1374732159009.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-25 06:02:38',0,'2013-07-25 06:02:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #297','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/297/>\n\n------------------------------------------\n[...truncated 67 lines...]\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-kM4mOV/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-kM4mOV/d2to1-0.2.10/egg-dist-tmp-qv0Sep\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-C7scHe/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-C7scHe/setuptools-git-1.0/egg-dist-tmp-sWTwuq\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-Y2cqGG/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-Y2cqGG/d2to1-0.2.10/egg-dist-tmp-anXf2n\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-XNDwr_/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-XNDwr_/setuptools-git-1.0/egg-dist-tmp-7Rqx05\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-I4XipO/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-I4XipO/d2to1-0.2.10/egg-dist-tmp-SYfSfr\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.mA8a3cq6Dq/easy_install-HzbbFF/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.mA8a3cq6Dq/easy_install-HzbbFF/setuptools-git-1.0/egg-dist-tmp-VTkXic\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.mA8a3cq6Dq\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/297\n[SCP] Copying console log.\n\n\n','<813606108.34.1374645724012.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1552541955.33.1381039935709.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-06 06:12:15',0,'2013-10-06 06:12:15',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #27','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/27/>\n\n\n\n','<408294411.26.1380953500146.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1553079851.17.1375943731833.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-08 06:35:31',0,'2013-08-08 06:35:31',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-grizzly #3','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/3/>\n\n\n\n','<1741235807.7.1375855350492.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1553118075.5820449.1368617804864.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 07:36:44',-14400,'2013-05-15 11:36:44',NULL,'[openstack-dev] [Ceilometer] Proposal to add Gordon Chung\n	to	ceilometer core','\n+1!\n\nCheers,\nEoghan\n\n----- Original Message -----\n> Hey fellow Ceilometer developers,\n> \n> I\'d like to nominate Gordon Chung <chungg at ca.ibm.com> to join our core\n> development team. He\'s done great reviews for a few weeks now, and\n> contributed with a few useful patches and fixes.\n> \n> Reviews:\n>   https://review.openstack.org/#/q/reviewer:chungg+project:openstack/ceilometer,n,z\n> \n> Patches:\n>   https://review.openstack.org/#/q/owner:chungg+project:openstack/ceilometer,n,z\n> \n> Thoughts?\n> \n> Cheers,\n> --\n> Julien Danjou\n> // Free Software hacker / freelance consultant\n> // http://julien.danjou.info\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<87r4haerx0.fsf@dex.adm.naquadah.org>',NULL),('<1553623347.287.1368685454332.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-16 06:24:14',0,'2013-05-16 06:24:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #227','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/227/>\n\n------------------------------------------\n[...truncated 12584 lines...]\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for ed33b8d79f9e47cd8277e05062e3f2a1 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43323\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43323/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (11353) wsgi starting up on http://127.0.0.1:43323/\n\nnova.osapi_compute.wsgi.server: INFO: (11353) accepted (\'127.0.0.1\', 48797)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/May/2013 06:18:52] \"GET /v2 HTTP/1.1\" 204 216 0.001059\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-ccd7bd81-28f7-41cd-a44b-95b537248a25</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (11353) accepted (\'127.0.0.1\', 48798)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8336210>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8336210>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43323/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43323/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/May/2013 06:18:53] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.272900\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 8e926785b01d47da9e241d0480a2ee4d \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43794\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43794/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (11353) wsgi starting up on http://127.0.0.1:43794/\n\nnova.osapi_compute.wsgi.server: INFO: (11353) accepted (\'127.0.0.1\', 42623)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/May/2013 06:18:53] \"GET /v2 HTTP/1.1\" 204 216 0.001086\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-a47206f6-c1f8-4e36-9d15-428ae14d5516</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (11353) accepted (\'127.0.0.1\', 42624)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b65690>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9b65690>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43794/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     name)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-16 06:18:53 11353 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43794/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [16/May/2013 06:18:53] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.317874\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.I8Cr3fuc3N\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/227\n[SCP] Copying console log.\n\n\n','<26159945.284.1368598919730.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1554139905.21.1355703138302.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-17 00:12:18',0,'2012-12-17 00:12:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #77','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/77/>\n\n------------------------------------------\n[...truncated 914 lines...]\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.02\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.02\n    test_add_auth_url_variations                                 OK    0.21\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 61, in test_interrupt_avoids_respawn_storm\n    execute(cmd, raise_error=True)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 255, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command kill -INT 10297 10296 did not succeed. Returned an exit code of 1.\n\nSTDOUT: \n\nSTDERR: kill: 1: No such process\n\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 69.96 secs:\n    15.09    TestGlanceControl.test_bouncing\n    14.27    TestScrubber.test_delayed_delete\n    13.88    TestGlanceControl.test_reload\n    13.72    TestGlanceControl.test_respawn\n    12.99    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 913 tests in 494.745s\n\nFAILED (SKIP=100, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6b1\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\nglance==jenkins-periodic-glance-python26-stable-folsom-77\ngreenlet==0.4.0\nhttplib2==0.7.7\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==0.7\nkombu==2.5.4\nlxml==3.0.2\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==0.14.2\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.5xwDou7Loa\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/77\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/77/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1554273847.21.1372141390054.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-25 06:23:10',0,'2013-06-25 06:23:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #267','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/267/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:60934\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:60934/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (29216) wsgi starting up on http://127.0.0.1:60934/\n\nnova.osapi_compute.wsgi.server: INFO: (29216) accepted (\'127.0.0.1\', 55824)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/Jun/2013 06:17:47] \"GET /v2 HTTP/1.1\" 204 216 0.000792\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-20edad64-6a4e-4477-9de8-7512e8900c85</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (29216) accepted (\'127.0.0.1\', 55825)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x91ef3d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x91ef3d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:60934/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-25 06:17:47 29216 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:60934/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/Jun/2013 06:17:47] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.247160\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for dab9f977e99145d28cc0d81b64012739 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:47127\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:47127/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (29216) wsgi starting up on http://127.0.0.1:47127/\n\nnova.osapi_compute.wsgi.server: INFO: (29216) accepted (\'127.0.0.1\', 44101)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/Jun/2013 06:17:47] \"GET /v2 HTTP/1.1\" 204 216 0.000962\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-ea377cae-5c7c-4302-9230-24e8345297c3</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (29216) accepted (\'127.0.0.1\', 44102)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x84ed910>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x84ed910>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:47127/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     name)\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-25 06:17:48 29216 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:47127/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [25/Jun/2013 06:17:48] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.308587\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.45\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.LO7GzvQFhx\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/267\n[SCP] Copying console log.\n\n\n','<578906735.19.1372055004148.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1555226839.157.1358235139821.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-15 07:32:19',0,'2013-01-15 07:32:19',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #68','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/68/>\n\n------------------------------------------\n[...truncated 15674 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:28:22 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-78178f05-eb7b-470d-a90d-aa80af469690\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzoyODowMS42ODg4MDAiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjI4OjAxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAiaWQiOiAiNmY2NDcwOWI4Yjk5NGNlZWJlZGM1YWFlZjJlZGQ5MjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3MDFmNDQxMzE3ZDY0ZjgxOGEyOThkYWNhOWVhMWY1NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDNjZjU3OGE3ZmNhNDIxMGJhZGU4YWY2NTYwZThmNTIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJpZCI6ICI4ZjQwYjJmNWQyYjA0NGRjYWMwOTI5MDc3NTFlMTc4YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI3NDhhMzNmZmFlNDM0YmQ1YTkxODA1NGQ1NThhMDdmOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIiwgImlkIjogIjUyZTkzM2E1MWI5OTRjNDI5NDE5NzNjYzQ4YzNlYTA4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjViMDJhMGMzMzRhMTQ5NDliMjUyOTczMzBkNzJhZDQxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiYjQ0YzUwNThlMjIzNGZlMmEwMThlMmFiNDc4YTU3OWMiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTg2ODcwYThmYjg4NDMxMzhlY2QzNTc3Njg2NDQ5NDgiLCAiZGEwMWQyOTEwNjMwNDNiM2E5ZjhmY2M1OGE2OTE1NjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAf4DpVJ0VoWT8ZblUgB-nPhN+ADzbTcdSrG+ikvZuJu8EpsGjtMaAf10X57LFfBlM+m3dr82gDxtFCjeuISd5CnjDhAaBz5ZmAaTKnziFfiidS32UlZko5upvD44XEBGgNp5UlFfgTHZxYmqdsBhikc4VrYA7WI8xR35iz6cElXg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/ab94e566-51e7-4d05-ade7-3984ac1d37e4\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:28:22 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-633f9a44-386b-4231-b2f7-e183f4037fd6\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzoyODowMS42ODg4MDAiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjI4OjAxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAiaWQiOiAiNmY2NDcwOWI4Yjk5NGNlZWJlZGM1YWFlZjJlZGQ5MjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3MDFmNDQxMzE3ZDY0ZjgxOGEyOThkYWNhOWVhMWY1NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDNjZjU3OGE3ZmNhNDIxMGJhZGU4YWY2NTYwZThmNTIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJpZCI6ICI4ZjQwYjJmNWQyYjA0NGRjYWMwOTI5MDc3NTFlMTc4YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI3NDhhMzNmZmFlNDM0YmQ1YTkxODA1NGQ1NThhMDdmOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIiwgImlkIjogIjUyZTkzM2E1MWI5OTRjNDI5NDE5NzNjYzQ4YzNlYTA4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjViMDJhMGMzMzRhMTQ5NDliMjUyOTczMzBkNzJhZDQxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiYjQ0YzUwNThlMjIzNGZlMmEwMThlMmFiNDc4YTU3OWMiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTg2ODcwYThmYjg4NDMxMzhlY2QzNTc3Njg2NDQ5NDgiLCAiZGEwMWQyOTEwNjMwNDNiM2E5ZjhmY2M1OGE2OTE1NjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAf4DpVJ0VoWT8ZblUgB-nPhN+ADzbTcdSrG+ikvZuJu8EpsGjtMaAf10X57LFfBlM+m3dr82gDxtFCjeuISd5CnjDhAaBz5ZmAaTKnziFfiidS32UlZko5upvD44XEBGgNp5UlFfgTHZxYmqdsBhikc4VrYA7WI8xR35iz6cElXg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/05b0e3d2-8e26-4c37-9df8-84b95b792610\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:28:23 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-dbff808c-2b05-41f1-827a-58aa4177fec4\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzoyODowMS42ODg4MDAiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjI4OjAxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAiaWQiOiAiNmY2NDcwOWI4Yjk5NGNlZWJlZGM1YWFlZjJlZGQ5MjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3MDFmNDQxMzE3ZDY0ZjgxOGEyOThkYWNhOWVhMWY1NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDNjZjU3OGE3ZmNhNDIxMGJhZGU4YWY2NTYwZThmNTIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJpZCI6ICI4ZjQwYjJmNWQyYjA0NGRjYWMwOTI5MDc3NTFlMTc4YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI3NDhhMzNmZmFlNDM0YmQ1YTkxODA1NGQ1NThhMDdmOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIiwgImlkIjogIjUyZTkzM2E1MWI5OTRjNDI5NDE5NzNjYzQ4YzNlYTA4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjViMDJhMGMzMzRhMTQ5NDliMjUyOTczMzBkNzJhZDQxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiYjQ0YzUwNThlMjIzNGZlMmEwMThlMmFiNDc4YTU3OWMiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTg2ODcwYThmYjg4NDMxMzhlY2QzNTc3Njg2NDQ5NDgiLCAiZGEwMWQyOTEwNjMwNDNiM2E5ZjhmY2M1OGE2OTE1NjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAf4DpVJ0VoWT8ZblUgB-nPhN+ADzbTcdSrG+ikvZuJu8EpsGjtMaAf10X57LFfBlM+m3dr82gDxtFCjeuISd5CnjDhAaBz5ZmAaTKnziFfiidS32UlZko5upvD44XEBGgNp5UlFfgTHZxYmqdsBhikc4VrYA7WI8xR35iz6cElXg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/839328ec-6f90-42d0-8e23-cc3dec22c8a2\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:28:24 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-b1a84069-29a5-4a11-bd1f-2794f96bb67e\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzoyODowMS42ODg4MDAiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjI4OjAxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMzhiMzc1MTdkNDE1NDQ1MWJhMmM0M2VlZjZmZDY4Y2IiLCAiaWQiOiAiNmY2NDcwOWI4Yjk5NGNlZWJlZGM1YWFlZjJlZGQ5MjciLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI3MDFmNDQxMzE3ZDY0ZjgxOGEyOThkYWNhOWVhMWY1NSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDNjZjU3OGE3ZmNhNDIxMGJhZGU4YWY2NTYwZThmNTIiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiIsICJpZCI6ICI4ZjQwYjJmNWQyYjA0NGRjYWMwOTI5MDc3NTFlMTc4YiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI3NDhhMzNmZmFlNDM0YmQ1YTkxODA1NGQ1NThhMDdmOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzM4YjM3NTE3ZDQxNTQ0NTFiYTJjNDNlZWY2ZmQ2OGNiIiwgImlkIjogIjUyZTkzM2E1MWI5OTRjNDI5NDE5NzNjYzQ4YzNlYTA4IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8zOGIzNzUxN2Q0MTU0NDUxYmEyYzQzZWVmNmZkNjhjYiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjViMDJhMGMzMzRhMTQ5NDliMjUyOTczMzBkNzJhZDQxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiYjQ0YzUwNThlMjIzNGZlMmEwMThlMmFiNDc4YTU3OWMiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYTg2ODcwYThmYjg4NDMxMzhlY2QzNTc3Njg2NDQ5NDgiLCAiZGEwMWQyOTEwNjMwNDNiM2E5ZjhmY2M1OGE2OTE1NjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAf4DpVJ0VoWT8ZblUgB-nPhN+ADzbTcdSrG+ikvZuJu8EpsGjtMaAf10X57LFfBlM+m3dr82gDxtFCjeuISd5CnjDhAaBz5ZmAaTKnziFfiidS32UlZko5upvD44XEBGgNp5UlFfgTHZxYmqdsBhikc4VrYA7WI8xR35iz6cElXg==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/c7895dd6-e023-4eed-b062-59577f198210\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:28:25 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c577d386-69d5-414a-ab4d-80a0ad431c4e\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n======================================================================\nFAIL: test_create_image_specify_uuid_35_characters_or_less (tempest.tests.compute.images.test_images.ImagesTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 136, in test_create_image_specify_uuid_35_characters_or_less\n    self.fail(\"Should return 404 Not Found if server uuid is 35\"\nAssertionError: Should return 404 Not Found if server uuid is 35 characters or less\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 35 characters or less\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d2d908dc049b443ea9a9c840e52e75ed/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: {\"createImage\": {\"name\": \"test-snap-251\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 15 Jan 2013 06:41:13 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-9ff924d1-3cc8-4371-a5d8-171fc7e4e8cd\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_37_characters_or_more (tempest.tests.compute.images.test_images.ImagesTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 148, in test_create_image_specify_uuid_37_characters_or_more\n    self.fail(\"Should return 404 Not Found if server uuid is 37\"\nAssertionError: Should return 404 Not Found if server uuid is 37 characters or more\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 37 characters or more\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d2d908dc049b443ea9a9c840e52e75ed/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: {\"createImage\": {\"name\": \"test-snap-847659\"}}\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 15 Jan 2013 06:41:13 GMT\', \'status\': \'500\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-1241ebb4-4028-414d-bd19-68da8443923f\'}\ntempest.common.rest_client: ERROR: Response Body: {u\'computeFault\': {u\'message\': u\'The server has either erred or is incapable of performing the requested operation.\', u\'code\': 500}}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_35_characters_or_less (tempest.tests.compute.images.test_images.ImagesTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 136, in test_create_image_specify_uuid_35_characters_or_less\n    self.fail(\"Should return 404 Not Found if server uuid is 35\"\nAssertionError: Should return 404 Not Found if server uuid is 35 characters or less\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 35 characters or less\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d5acb2e5e8444022b88d1ef56069daab/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<createImage name=\"test-snap-444704\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 15 Jan 2013 06:42:37 GMT\', \'status\': \'500\', \'content-length\': \'192\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-b992c0d1-ca79-4394-a8c6-8fc1d5a50ecf\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'The server has either erred or is incapable of performing the requested operation.\', \'code\': \'500\'}\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_create_image_specify_uuid_37_characters_or_more (tempest.tests.compute.images.test_images.ImagesTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/images/test_images.py\", line 148, in test_create_image_specify_uuid_37_characters_or_more\n    self.fail(\"Should return 404 Not Found if server uuid is 37\"\nAssertionError: Should return 404 Not Found if server uuid is 37 characters or more\n    \"\"\"Fail immediately, with the given message.\"\"\"\n>>  raise self.failureException(\'Should return 404 Not Found if server uuid is 37 characters or more\')\n    \n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8774/v2/d5acb2e5e8444022b88d1ef56069daab/servers/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/action\ntempest.common.rest_client: ERROR: Request Body: <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<createImage name=\"test-snap-647767\"/>\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Tue, 15 Jan 2013 06:42:37 GMT\', \'status\': \'500\', \'content-length\': \'192\', \'content-type\': \'application/xml; charset=UTF-8\', \'x-compute-request-id\': \'req-411d4dda-2ced-4bf6-ae03-0491cc7bc8d0\'}\ntempest.common.rest_client: ERROR: Response Body: {\'message\': \'The server has either erred or is incapable of performing the requested operation.\', \'code\': \'500\'}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 653 tests in 3381.237s\n\nFAILED (SKIP=84, failures=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/rabbitmq/rabbit at devstack-1358216493-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/rabbitmq/rabbit at devstack-1358216493.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/68/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1017631426.136.1358148453004.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1555793622.45.1381385721729.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-10 06:15:21',0,'2013-10-10 06:15:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #40','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/40/changes>\n\nChanges:\n\n[stuart.mclaren] Enforce \'download_image\' policy in cache\n\n[flaper87] Gracefully handle qpid errors\n\n[flaper87] Fixing glance-api hangs in the qpid notifier\n\n------------------------------------------\n[...truncated 1188 lines...]\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.02\n    test_multi_tenant_location_with_region                       OK    0.02\n    test_single_tenant_location                                  OK    0.02\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_api.TestRootApi.test_version_configurations\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_api.py\",> line 65, in test_version_configurations\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n======================================================================\nFAIL: glance.tests.functional.test_bin_glance_control.TestGlanceControl.test_respawn\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_control.py\",> line 166, in test_respawn\n    self.assertTrue(launch_msg is None, launch_msg)\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: Unexpected server launch status\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 95.62 secs:\n    27.49    TestScrubber.test_scrubber_app\n    21.76    TestScrubber.test_delayed_delete\n    15.93    TestBinGlanceCacheManage.test_queue\n    15.75    TestGlanceControl.test_reload\n    14.69    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 715.911s\n\nFAILED (SKIP=42, errors=1, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.14.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.40\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.7.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.P2FVW1b4X0\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/40/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise19/40\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1556635444.12493049.1394527604377.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-11 04:46:44',-14400,'2014-03-11 08:46:44',NULL,'[openstack-dev] [neutron][rootwrap] Performance considerations,\n	sudo?','\nI have included on the etherpad, the option to write a sudo \nplugin (or several), specific for openstack.\n\n\nAnd this is a test with shedskin, I suppose that in more complicated\ndependecy scenarios it should perform better.\n\n[majopela at redcylon tmp]$ cat <<EOF >test.py\n> import sys\n> print \"hello world\"\n> sys.exit(0)\n> EOF\n\n[majopela at redcylon tmp]$ time python test.py\nhello world\n\nreal	0m0.016s\nuser	0m0.015s\nsys	0m0.001s\n\n\n[majopela at redcylon tmp]$ shedskin test.py\n*** SHED SKIN Python-to-C++ Compiler 0.9.4 ***\nCopyright 2005-2011 Mark Dufour; License GNU GPL version 3 (See LICENSE)\n\n[analyzing types..]\n********************************100% \n[generating c++ code..]\n[elapsed time: 1.59 seconds]\n[majopela at redcylon tmp]$ make \ng++  -O2 -march=native -Wno-deprecated  -I. -I/usr/lib/python2.7/site-packages/shedskin/lib /tmp/test.cpp /usr/lib/python2.7/site-packages/shedskin/lib/sys.cpp /usr/lib/python2.7/site-packages/shedskin/lib/re.cpp /usr/lib/python2.7/site-packages/shedskin/lib/builtin.cpp -lgc -lpcre  -o test\n[majopela at redcylon tmp]$ time ./test\nhello world\n\nreal	0m0.003s\nuser	0m0.000s\nsys	0m0.002s\n\n\n----- Original Message -----\n> We had this same issue with the dhcp-agent. Code was added that paralleled\n> the initial sync here: https://review.openstack.org/#/c/28914/ that made\n> things a good bit faster if I remember correctly. Might be worth doing\n> something similar for the l3-agent.\n> \n> Best,\n> \n> Aaron\n> \n> \n> On Mon, Mar 10, 2014 at 5:07 PM, Joe Gordon < joe.gordon0 at gmail.com > wrote:\n> \n> \n> \n> \n> \n> \n> On Mon, Mar 10, 2014 at 3:57 PM, Joe Gordon < joe.gordon0 at gmail.com > wrote:\n> \n> \n> \n> I looked into the python to C options and haven\'t found anything promising\n> yet.\n> \n> \n> I tried Cython, and RPython, on a trivial hello world app, but git similar\n> startup times to standard python.\n> \n> The one thing that did work was adding a \'-S\' when starting python.\n> \n> -S Disable the import of the module site and the site-dependent manipulations\n> of sys.path that it entails.\n> \n> Using \'python -S\' didn\'t appear to help in devstack\n> \n> #!/usr/bin/python -S\n> # PBR Generated from u\'console_scripts\'\n> \n> import sys\n> import site\n> site.addsitedir(\'/mnt/stack/oslo.rootwrap/oslo/rootwrap\')\n> \n> \n> \n> \n> \n> \n> I am not sure if we can do that for rootwrap.\n> \n> \n> jogo at dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c\n> hello world\n> \n> real 0m0.021s\n> user 0m0.000s\n> sys 0m0.020s\n> jogo at dev:~/tmp/pypy-2.2.1-src$ time ./tmp-c\n> hello world\n> \n> real 0m0.021s\n> user 0m0.000s\n> sys 0m0.020s\n> jogo at dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py\n> hello world\n> \n> real 0m0.010s\n> user 0m0.000s\n> sys 0m0.008s\n> \n> jogo at dev:~/tmp/pypy-2.2.1-src$ time python -S ./tmp.py\n> hello world\n> \n> real 0m0.010s\n> user 0m0.000s\n> sys 0m0.008s\n> \n> \n> \n> On Mon, Mar 10, 2014 at 3:26 PM, Miguel Angel Ajo Pelayo <\n> mangelajo at redhat.com > wrote:\n> \n> \n> Hi Carl, thank you, good idea.\n> \n> I started reviewing it, but I will do it more carefully tomorrow morning.\n> \n> \n> \n> ----- Original Message -----\n> > All,\n> > \n> > I was writing down a summary of all of this and decided to just do it\n> > on an etherpad. Will you help me capture the big picture there? I\'d\n> > like to come up with some actions this week to try to address at least\n> > part of the problem before Icehouse releases.\n> > \n> > https://etherpad.openstack.org/p/neutron-agent-exec-performance\n> > \n> > Carl\n> > \n> > On Mon, Mar 10, 2014 at 5:26 AM, Miguel Angel Ajo < majopela at redhat.com >\n> > wrote:\n> > > Hi Yuri & Stephen, thanks a lot for the clarification.\n> > > \n> > > I\'m not familiar with unix domain sockets at low level, but , I wonder\n> > > if authentication could be achieved just with permissions (only users in\n> > > group \"neutron\" or group \"rootwrap\" accessing this service.\n> > > \n> > > I find it an interesting alternative, to the other proposed solutions,\n> > > but\n> > > there are some challenges associated with this solution, which could make\n> > > it\n> > > more complicated:\n> > > \n> > > 1) Access control, file system permission based or token based,\n> > > \n> > > 2) stdout/stderr/return encapsulation/forwarding to the caller,\n> > > if we have a simple/fast RPC mechanism we can use, it\'s a matter\n> > > of serializing a dictionary.\n> > > \n> > > 3) client side implementation for 1 + 2.\n> > > \n> > > 4) It would need to accept new domain socket connections in green threads\n> > > to\n> > > avoid spawning a new process to handle a new connection.\n> > > \n> > > The advantages:\n> > > * we wouldn\'t need to break the only-python-rule.\n> > > * we don\'t need to rewrite/translate rootwrap.\n> > > \n> > > The disadvantages:\n> > > * it needs changes on the client side (neutron + other projects),\n> > > \n> > > \n> > > Cheers,\n> > > Miguel ?ngel.\n> > > \n> > > \n> > > \n> > > On 03/08/2014 07:09 AM, Yuriy Taraday wrote:\n> > >> \n> > >> On Fri, Mar 7, 2014 at 5:41 PM, Stephen Gran\n> > >> < stephen.gran at theguardian.com <mailto: stephen.gran at theguardian.com >>\n> > >> wrote:\n> > >> \n> > >> Hi,\n> > >> \n> > >> Given that Yuriy says explicitly \'unix socket\', I dont think he\n> > >> means \'MQ\' when he says \'RPC\'. I think he just means a daemon\n> > >> listening on a unix socket for execution requests. This seems like\n> > >> a reasonably sensible idea to me.\n> > >> \n> > >> \n> > >> Yes, you\'re right.\n> > >> \n> > >> On 07/03/14 12:52, Miguel Angel Ajo wrote:\n> > >> \n> > >> \n> > >> I thought of this option, but didn\'t consider it, as It\'s somehow\n> > >> risky to expose an RPC end executing priviledged (even filtered)\n> > >> commands.\n> > >> \n> > >> \n> > >> subprocess module have some means to do RPC securely over UNIX sockets.\n> > >> I does this by passing some token along with messages. It should be\n> > >> secure because with UNIX sockets we don\'t need anything stronger since\n> > >> MITM attacks are not possible.\n> > >> \n> > >> If I\'m not wrong, once you have credentials for messaging, you can\n> > >> send messages to any end, even filtered, I somehow see this as a\n> > >> higher\n> > >> risk option.\n> > >> \n> > >> \n> > >> As Stephen noted, I\'m not talking about using MQ for RPC. Just some\n> > >> local UNIX socket with very simple RPC over it.\n> > >> \n> > >> And btw, if we add RPC in the middle, it\'s possible that all those\n> > >> system call delays increase, or don\'t decrease all it\'ll be\n> > >> desirable.\n> > >> \n> > >> \n> > >> Every call to rootwrap would require the following.\n> > >> \n> > >> Client side:\n> > >> - new client socket;\n> > >> - one message sent;\n> > >> - one message received.\n> > >> \n> > >> Server side:\n> > >> - accepting new connection;\n> > >> - one message received;\n> > >> - one fork-exec;\n> > >> - one message sent.\n> > >> \n> > >> This looks like way simpler than passing through sudo and rootwrap that\n> > >> requires three exec\'s and whole lot of configuration files opened and\n> > >> parsed.\n> > >> \n> > >> --\n> > >> \n> > >> Kind regards, Yuriy.\n> > >> \n> > >> \n> > >> _______________________________________________\n> > >> OpenStack-dev mailing list\n> > >> OpenStack-dev at lists.openstack.org\n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >> \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAEYMMcO2hsL5i2ikx7h+zw3zRkZW+E0pmB3np81n=SCkLcvWkA@mail.gmail.com>',NULL),('<1556990481.87.1353111133500.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-17 00:12:13',0,'2012-11-17 00:12:13',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #47','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/47/>\n\n\n\n','<802408847.62.1353026271947.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1557221995.4827904.1392719555252.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-18 05:32:35',-18000,'2014-02-18 10:32:35',NULL,'[openstack-dev] [Neutron] DVR blueprint document locked / private','Regarding the DVR blueprint [1], I noticed that its corresponding Google Doc [2]\nhas been private / blocked for nearly a week now. It\'s very difficult to participate\nin upstream design discussions when the document is literally locked.\n\nI would appreciate the re-opening of the document, especially considering the recent\nface to face meeting and the contested discussion points that were raised.\n\n[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr\n[2] https://docs.google.com/document/d/1iXMAyVMf42FTahExmGdYNGOBFyeA4e74sAO3pvr_RjA/edit\n\n\nThank you,\nAssaf Muller, Cloud Networking Engineer \nRed Hat \n\n\n','<459892290.4823215.1392718132933.JavaMail.zimbra@redhat.com>',NULL),('<1558615133.10.1376978792460.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-20 06:06:32',0,'2013-08-20 06:06:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #5','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 645 lines...]\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 176, in test_FnGetAtt\n    self.assertEqual(s2.CREATE_COMPLETE, s2.state)\nAssertionError: \'CREATE_COMPLETE\' != \'CREATE_FAILED\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\" = \'%s != %s\' % (safe_repr(\'CREATE_COMPLETE\'), safe_repr(\'CREATE_FAILED\'))\n    \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\" = self._formatMessage(\"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\", \"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\")\n>>  raise self.failureException(\"\'CREATE_COMPLETE\' != \'CREATE_FAILED\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: ERROR: create Instance \"S2\"\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/engine/resource.py\",> line 320, in create\n    self.handle_create()\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 765, in __call__\n    return mock_method(*params, **named_params)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1002, in __call__\n    expected_method = self._VerifyMethodCall()\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1049, in _VerifyMethodCall\n    expected = self._PopNextMethod()\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 1035, in _PopNextMethod\n    raise UnexpectedMethodCallError(self, None)\nUnexpectedMethodCallError: Unexpected method call handle_create.__call__() -> None\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.537s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncliff==1.4.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.13\nlxml==2.3.5\nmox==0.5.3\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npyflakes==0.7.3\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.10.0\npython-keystoneclient==0.3.1\npython-memcached==1.53\npython-novaclient==2.14.1\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.sWk4ekOhFO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise5/5\n[SCP] Copying console log.\n\n\n','<569289931.6.1376892296598.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1559390049.62.1379311872188.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-16 06:11:12',0,'2013-09-16 06:11:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-grizzly #22','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/22/>\n\n------------------------------------------\n[...truncated 31 lines...]\n+ TMPDIR=/tmp/tmp.Y6T7muxVMV\n+ trap \'rm -rf /tmp/tmp.Y6T7muxVMV\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' nova == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.22\n+ tox -epy26\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/tools/test-requires>\npy26 inst: <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.22.zip>\npy26 runtests: commands[0] | python tools/patch_tox_venv.py\npy26 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.Y6T7muxVMV/tmp4pKoZj\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.Y6T7muxVMV/tmpGlKLbA\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.Y6T7muxVMV/tmpzRe2CI\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.Y6T7muxVMV/tmpyDcluA\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\ntags: worker-2\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group qusunswq\n0.65224s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nCreate Security Group supanrw\n0.64259s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress qusunswq\n0.123402s None GET /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64]  text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 582, in test_authorize_revoke_security_group_foreign_group\n    group.authorize(src_group=other_group)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group icdis\n0.66690s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress icdis\n0.104765s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 419, in test_authorize_revoke_security_group_cidr\n    group.authorize(\'tcp\', 80, 81, \'0.0.0.0/0\')\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: nova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'boto\'\n  stderr\n  stdout\n\npythonlogging:\'nova\': {{{\nCreate Security Group sansss\n0.64490s None POST /services/Cloud/ CloudController:CreateSecurityGroup 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\nAuthorize security group ingress sansss\n0.96006s None POST /services/Cloud/ CloudController:AuthorizeSecurityGroupIngress 200 [Boto/2.13.0 Python/2.6.6 Linux/2.6.32-358.6.2.el6.x86_64] application/x-www-form-urlencoded text/xml\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/nova/tests/test_api.py\",> line 521, in test_authorize_revoke_security_group_cidr_v6\n    group.authorize(\'tcp\', 80, 81, \'::/0\')\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 207, in authorize\n    src_group_group_id, dry_run=dry_run)\n  File \"<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/boto/ec2/securitygroup.py\",> line 115, in add_rule\n    dry_run=dry_run\nTypeError: add_grant() got an unexpected keyword argument \'dry_run\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 11310 tests in 414.672s\nFAILED (id=0, failures=5, skips=13)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.22\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\nstevedore==0.11\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nunittest2==0.5.1\nwarlock==1.0.1\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py26/bin/subunit-1to2\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_foreign_group\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr\nnova.tests.test_api.ApiEc2TestCase.test_authorize_revoke_security_group_cidr_v6\nprocess-returncode\nprocess-returncode\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Y6T7muxVMV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly/centos6-4/22\n[SCP] Copying console log.\n\n\n','<1528277932.59.1379225559403.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1559787849.329.1359072146398.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-25 00:02:26',0,'2013-01-25 00:02:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-folsom #116','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/116/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric4 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/>\nCheckout:periodic-swift-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/> - hudson.remoting.Channel at 7ed9a08f:oneiric4\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0.3\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson2596676526960825462.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.CJQYZ9xtCp\n+ TMPDIR=/tmp/tmp.CJQYZ9xtCp\n+ trap \'rm -rf /tmp/tmp.CJQYZ9xtCp\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/116/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python26-stable-folsom-116\', \'SSH_CLIENT\': \'198.101.231.203 56756 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1358004656.871334-577647899\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric4\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.CJQYZ9xtCp\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-25_00-01-26\', \'BUILD_NUMBER\': \'116\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'7dd17f75-db16-42de-8903-fb202f148615\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric4\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 56756 166.78.31.217 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.CJQYZ9xtCp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-folsom/116\n[SCP] Copying console log.\n\n\n','<1061809184.308.1358985733959.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<15622_1395857373_533317DD_15622_6665_1_533317DB.20104@externos.ciemat.es>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-26 19:09:31',3600,'2014-03-26 18:09:31',NULL,'[Openstack-operators] Horizon failing in self.auth_url of\n	neutronclient.','Hi,\n\nHorizon (of Havana) is showing problems when accessing:\n\nThe error message is:\n\nunsupported operand type(s) for +: \'NoneType\' and \'str\'\n\n\nand is produced in:\n\n|/usr/lib/python2.6/site-packages/neutronclient/client.py| in \n|authenticate|\n\ntoken_url = self.auth_url + \"/tokens\"\n\nI\'ve applied the patch https://review.openstack.org/#/c/52954/\nbut the self.auth_url of the code above is still None\n\nCommands such as nova net-list and nova floating-ip-list work fine.\n\nAny idea?\n\nThanks!\nMiguel.\n\n\n-- \n/Miguel Angel D?az Corchero/\n/*System Administrator / Researcher*/\n/c/ Sola n? 1; 10200 TRUJILLO, SPAIN/\n/Tel: +34 927 65 93 17 Fax: +34 927 32 32 37/\n\nCETA-Ciemat logo <http://www.ceta-ciemat.es/>\n\n\n----------------------------\nConfidencialidad: \nEste mensaje y sus ficheros adjuntos se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente respondiendo al mensaje y proceda a su destrucci?n.\n\nDisclaimer: \nThis message and its attached files is intended exclusively for its recipients and may contain confidential information. If you received this e-mail in error you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited and may be unlawful. In this case, please notify us by a reply and delete this email and its contents immediately. \n----------------------------\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140326/36bb2b8f/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.png\nType: image/png\nSize: 26213 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140326/36bb2b8f/attachment.png>\n\n',NULL,NULL),('<1562972108.1185699.1366815030780.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-04-24 10:50:30',-14400,'2013-04-24 14:50:30',NULL,'[OpenStack-Infra] Talking is the first step.','\n----- Original Message -----\n> From: Brian Lamar <brian.lamar at rackspace.com>\n\n> So the question again becomes how can we get XenServer into the gate.\n\nHi Lamar,\n\nI understand there is a long term goal to move towards larger scale testing on bare metal w/ TripleO, etc. I\'m very interested in that myself too. In the short/mid term however perhaps using SmokeStack (which supports testing multiple/flexible configurations) would help cover the scenario you described below via pre-gate testing?\n\n> I imagine it going something like this:\n> \n> \n> 1) Hardware is provided with XenServer 6.1 installed\n\n SmokeStack currently runs a single node (all in one) XenServer 5.6 test on upstream branches and comments on them (pre-gate testing). It does this using 4 Dell R710\'s (provided by RAX). Why not upgrade these machines to XenServer 6.1 to cover this?\n\n> 2) Script for Jenkins will boot XenServer VM on hardware provided\n\n SmokeStack uses this approach as well (via something called Kytoon).\n\n> 3) VM will be configured using...devstack?\n\n SmokeStack uses Puppet w/ Fedora packages I maintain :). I understand people have various opinions on how to deploy things... but if it works w/ packages I would argue that is probably \"close enough\" to the test coverage you are looking for. The actual configuration that is used for XenServer testing is easily modifiable though so long as the puppet modules support it.\n\n> 4) This script will be an unofficial gate (aka 3rd party gate) until\n> it is considered stable\n> 5) This script will be integrated into the official process either as\n> a gate-gate or a periodic-gate\n\n SmokeStack comments on reviews pre-commit (via Bellows). It isn\'t a gate (that ship sailed at the Diablo conference) but it is a well defined 3rd party review tool ATM.\n\n----\n\nNot trying to derail this into a conversation about SmokeStack. But it does seem like it wouldn\'t take too much effort to be able to cover your concerns in the short/mid term via something that is already running and commenting on reviews upstream.\n\nDan\n\n\n','<1366746569.21508.0.camel@sorcha>',NULL),('<1563365536.2922953.1399464248969.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 08:04:08',-14400,'2014-05-07 12:04:08',NULL,'[openstack-dev] [nova][neutron] VIF event\n	callbacks	implementation','Hi,\n\nSorry for late reply, please see replies inline.\n\nI have additional concern that API is something that\'s user facing so\nbasically now Nova is exposing some internal synchronization detail to\nthe outside world.\nDoes it make sense that the user would now be able to send messages to\nthis API?\n\n----- Original Message -----\n> > Aside from creating a sort of cyclic dependency between the two, it\n> > is my understanding that Neutron is meant to be a \"stand alone\"\n> > service capable of being consumed by other compute managers (i.e.\n> > oVirt). This breaks that paradigm.\n> \n> <snip>\n> \n> > So my question is: Why use API and not RPC?\n> > \n> > I saw that there is already a notification system in Neutron that\n> > notifies on each port update (among other things) which are\n> > currently consumed by Ceilometer. Why not have Nova use those\n> > notifications to decide that a VIF got plugged correctly, floating\n> > IPs changed, and so on?\n> \n> To your point above, having either service sit on the other\'s RPC bus\n> ties them together far closer than having them consume each other\'s REST\n> API, IMHO. Further, Nova\'s internal RPC mechanics are controlled pretty\n> tightly for upgrade compatibility and I don\'t think I\'d want another\n> service sitting on that bus that we have to worry about when we\'re\n> coordinating a change across releases (which we do quite often). We\n> consume Neutron\'s services via the REST API because that\'s what is\n> exposed externally and guaranteed to be stable -- the same goes for\n> Neutron consuming anything from Nova.\n\nNot sure why RPC is more coupled than API. Maybe you could explain?\n\nCurrently it\'s a very specific API putting a burden on Neutron to now know\nwhat is VIF and what state is necessary for this VIF to be working,\ninstead of having these calculations in Nova (which is of course aware of\nVIF, and of Port).\n\nI wasn\'t suggesting touching Nova\'s RPC but rather utilize the existing\nnotifications sent from Neutron to achieve the same logic. So not sure what\nchanges you believe are to be coordinated from Nova\'s POV.\n\nAlso, RPC is just what is used today. It could similarly be a queue with\nsome defined message format. IMHO \"RPC\" is just that, it\'s not really\nmaking any remote procedure calls in the notifications it sends.\n\nWe could alternatively provide a \"callback\" functionality that allows\nvarious clients to receive notifications from Neutron, specifying an\naddress to send these details to.\n\n> \n> > I believe the rationale here was that nova\'s API interface is only\n> > currently exposed via a rest API over http so leveraging this\n> > existing framework seemed like a good place to do it. In addition,\n> > there didn\'t seem to be an obvious advantage to using RPC rather\n> > than the rest interface. Lastly, this new interface that nova exposes\n> > is generic and not neutron specific as it can be used for other type\n> > of notifications that things want to send nova. I added Dan Smith to\n> > CC to keep me honest here as I believe this was the rationale.\n> \n> Yeah, we\'ve already got plans in place to get Cinder to use the\n> interface to provide us more detailed information and eliminate some\n> polling. We also have a very purpose-built notification scheme between\n> nova and cinder that facilitates a callback for a very specific\n> scenario. I\'d like to get that converted to use this mechanism as well,\n> so that it becomes \"the way you tell nova that things it\'s waiting for\n> have happened.\"\n\nNot sure how you consider this \"mechanism\" something generic since it\'s\nfacilitating only Nova while there might be a number of different services\ninterested in this information.\nNow Neutron needs to be aware of VIF and Nova\'s expectations of Neutron\nin regards to that VIF, which is highly tightly coupled.\n\nUsing a notification scheme where any subscriber can receive the event\nfrom Neutron/Cinder/etc and handle it how it needs instead would be\nmuch more decoupled, IMHO.\n\n> \n> --Dan\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<535FFC47.5030009@danplanet.com>',NULL),('<15634511.424.1383854274858.JavaMail.Daniel@Daniel-PC>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-07 20:56:28',3600,'2013-11-07 19:56:28',NULL,'[Openstack] Is there a way to tell Nova not to count\n NFS-mounted instances directory to disk space on each node?','There is compute_nodes file in /var/lib/nova/instances with the hostnames of all compute nodes using that storage so it should be possible and easy to figure out if that is a shared storage or not. \n\nRegards, \nDaniel \n\n----- Original Message -----\n\n> From: \"Razique Mahroua\" <razique.mahroua at gmail.com>\n> To: \"Chris Friesen\" <chris.friesen at windriver.com>,\n> openstack at lists.openstack.org\n> Sent: Thursday, November 7, 2013 1:53:29 PM\n> Subject: Re: [Openstack] Is there a way to tell Nova not to count\n> NFS-mounted instances directory to disk space on each node?\n\n> I think during the migrations, the compute topic already checks\n> whether or not the storage is a shared one\n\n> --\n> Razique\n\n> On 7 Nov 2013 at 10:11:24, Chris Friesen (\n> chris.friesen at windriver.com ) wrote:\n> > I think it would make sense to have an entry in the nova.conf file\n> > on\n> > a\n> \n> > compute node to indicate that the instances are mounted on shared\n> > storage.\n> \n\n> > This could be fed back into the database, used in resource\n> > reporting\n> \n> > (like in this case where it affects the \"real\" amount of storage\n> \n> > available), and could also be added to the instance itself so that\n> > the\n> \n> > evacuate/migrate commands could programmatically determine whether\n> > the\n> \n> > instance is on shared storage or not instead of requiring the user\n> > to\n> \n> > specify it.\n> \n\n> > Chris\n> \n\n> > On 11/07/2013 04:36 AM, Razique Mahroua wrote:\n> \n> > > Hey Daniel,\n> \n> > >\n> \n> > > Doesn?t seem possible at the moment looks like...\n> \n> > > --\n> \n> > > Razique\n> \n> > >\n> \n> > > On 7 Nov 2013 at 02:09:15, Daniel Speichert (daniel at speichert.pl\n> \n> > > <mailto://daniel at speichert.pl>) wrote:\n> \n> > >\n> \n> > >> Hi All,\n> \n> > >>\n> \n> > >> We have a couple of compute nodes each having its\n> \n> > >> /var/lib/nova/instances directory mounted via NFS from shared\n> > >> storage\n> \n> > >> server.\n> \n> > >> Nova gathers free space statistics from each compute node and\n> > >> adds\n> \n> > >> them, making the theoretical total disk space equal N times the\n> > >> real\n> \n> > >> one (N is the number of nodes we have).\n> \n> > >> Is there a way to tell it not to count this space again on some\n> > >> nodes?\n> \n> > >>\n> \n> > >> Regards,\n> \n> > >> Daniel Speichert\n> \n> > >>\n> \n> > >>\n> \n> > >> _______________________________________________\n> \n> > >> Mailing list:\n> \n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> > >> Post to : openstack at lists.openstack.org\n> \n> > >> Unsubscribe :\n> \n> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> > >\n> \n> > >\n> \n> > > _______________________________________________\n> \n> > > Mailing list:\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> > > Post to : openstack at lists.openstack.org\n> \n> > > Unsubscribe :\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> > >\n> \n\n> > _______________________________________________\n> \n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> > Post to : openstack at lists.openstack.org\n> \n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n> _______________________________________________\n> Mailing list:\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to : openstack at lists.openstack.org\n> Unsubscribe :\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131107/937a1fc4/attachment.html>\n\n','<etPan.527be1a9.6b8b4567.1869@MacBook-Air-Razique.local>',NULL),('<1563854512.40.1369635723304.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-27 06:22:03',0,'2013-05-27 06:22:03',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #238','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/238/>\n\n------------------------------------------\n[...truncated 12586 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for 93d63e33e5eb46c7a1e00a092689372a \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43054\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43054/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (2916) wsgi starting up on http://127.0.0.1:43054/\n\nnova.osapi_compute.wsgi.server: INFO: (2916) accepted (\'127.0.0.1\', 44786)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [27/May/2013 06:16:41] \"GET /v2 HTTP/1.1\" 204 216 0.001073\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-68c06684-a419-44e5-aa11-75ea11f1400d</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (2916) accepted (\'127.0.0.1\', 44787)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1c1950>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa1c1950>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43054/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-27 06:16:41 2916 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43054/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [27/May/2013 06:16:41] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.262423\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 9bb0049c9aa945249ccce02d6cf42fa2 \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:50711\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:50711/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (2916) wsgi starting up on http://127.0.0.1:50711/\n\nnova.osapi_compute.wsgi.server: INFO: (2916) accepted (\'127.0.0.1\', 50354)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [27/May/2013 06:16:41] \"GET /v2 HTTP/1.1\" 204 216 0.001088\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-aaf11065-bf2a-432f-b836-8803fd2b3d8b</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (2916) accepted (\'127.0.0.1\', 50355)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x88981d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x88981d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:50711/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     name)\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-27 06:16:42 2916 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:50711/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [27/May/2013 06:16:42] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.285654\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.OFo66C5vf9\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/238\n[SCP] Copying console log.\n\n\n','<108683333.37.1369549324273.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1564256365.18.1385187227863.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-23 06:13:47',0,'2013-11-23 06:13:47',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-havana #3','See <https://jenkins01.openstack.org/job/periodic-ceilometer-python26-stable-havana/3/changes>\n\n\n\n','<311496942.13.1385100758391.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<15654266.6111080.1397597093603.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 17:24:53',-14400,'2014-04-15 21:24:53',NULL,'[openstack-dev] [nova] [neutron] Gerrit spec reviews','This page actually has most of the answers on it: https://wiki.openstack.org/wiki/Blueprints#Nova\n\n1: The time limit is one release: \"at the end of each release, non-completed specs will be removed\"\n2: The \"nova-drivers\" team approves specs\n3: No, it\'s not required to have a summit session. Something like that would be problematic, as\n   blueprints could be proposed after summit.\n\nHope that helps.  IMHO, the nova-specs gerrit repository is a great way to review\nblueprints.  I\'m really liking it so far.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Kyle Mestery\" <mestery at noironetworks.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Tuesday, April 15, 2014 5:14:14 PM\nSubject: [openstack-dev] [nova] [neutron] Gerrit spec reviews\n\nHi Nova developers:\n\nI have a question around the new nova-specs gerrit repository. We\'re\nimplementing the same thing in Neutron for Juno (I\'m hoping to make\nthis live tomorrow), but I had a few quick questions so I can build on\nyour experience with this so far:\n\n1. Did you implement any sort of time limit on BPs in review? Mostly\naround trying to triage the BPs as they come in.\n2. Nova has a subset of the core-team which can actually approve BPs,\nis this correct?\n3. For all BPs submitted using the new procedure, is it required to\nsubmit a Summit session?\n\nAny guidance appreciated here!\n\nThanks,\nKyle\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CADEmHi0YPMUo=7vwxL29hPjGN67g8H4ZrGb4Nc5sg53RM3z2Mg@mail.gmail.com>',NULL),('<1566181813.3050789.1380820079580.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-03 13:07:59',-14400,'2013-10-03 17:07:59',NULL,'[openstack-dev] SmokeStack welcomes Heat and Ceilometer','Hi all,\n\nA quick update on some recent SmokeStack additions in the Havana dev cycle:\n\nSeveral weeks back we added support for Ceilometer. Test configuration using both MongoDB (Fedora 19) and MySQL (Centos 6.4) are currently being used to test Ceilometer. Currently only the compute agent is being used and verified. We hope to expand coverage to include using and testing the central agent as well in the future.\n\nThis week we put the finishing touches on Heat support for SmokeStack. Similar to Ceilometer above this includes configuration which test things on Fedora 19 and Centos 6.4.\n\nYou should now see SmokeStack results for these projects. There have already been a couple regressions we found in reporting -1 results back into Gerrit for these projects.\n\nAlso, Because SmokeStack uses (and helps maintain) upstream packages we are also able to provide review feedback on the associated puppet-ceilometer and puppet-heat projects which are currently being used to install packages for testing.\n\nSmokin\' since Cactus...\n\nDan\n\n\n\n','<1891176125.3043814.1380819175505.JavaMail.root@redhat.com>',NULL),('<1566349866.148.1367994024640.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-08 06:20:24',0,'2013-05-08 06:20:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python26-stable-grizzly #28','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/28/changes>\n\n\n\n','<1786623546.117.1367907724038.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1567001233.5256502.1386777466808.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-11 10:57:46',-18000,'2013-12-11 15:57:46',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','> On 2013/10/12 19:39, Tzu-Mainn Chen wrote:\n> >>\n> >> Ideally, we don\'t. But with this approach we would take out the\n> >> possibility to change something or decide something from the user.\n> >>\n> >> The \'easiest\' way is to support bigger companies with huge deployments,\n> >> tailored infrastructure, everything connected properly.\n> >>\n> >> But there are tons of companies/users who are running on old\n> >> heterogeneous hardware. Very likely even more than the number of\n> >> companies having already mentioned large deployments. And giving them\n> >> only the way of \'setting up rules\' in order to get the service on the\n> >> node - this type of user is not gonna use our deployment system.\n> >>\n> >> Somebody might argue - why do we care? If user doesn\'t like TripleO\n> >> paradigm, he shouldn\'t use the UI and should use another tool. But the\n> >> UI is not only about TripleO. Yes, it is underlying concept, but we are\n> >> working on future *official* OpenStack deployment tool. We should care\n> >> to enable people to deploy OpenStack - large/small scale,\n> >> homo/heterogeneous hardware, typical or a bit more specific use-cases.\n> >\n> > I think this is a very important clarification, and I\'m glad you made it.\n> > It sounds\n> > like manual assignment is actually a sub-requirement, and the feature\n> > you\'re arguing\n> > for is: supporting non-TripleO deployments.\n>\n> Mostly but not only. The other argument is - keeping control on stuff I\n> am doing. Note that undercloud user is different from overcloud user.\n\nSure, but again, that argument seems to me to be a non-TripleO approach.  I\'m\nnot saying that it\'s not a possible use case, I\'m saying that you\'re advocating\nfor a deployment strategy that fundamentally diverges from the TripleO\nphilosophy - and as such, that strategy will likely require a separate UI, underlying\narchitecture, etc, and should not be planned for in the Icehouse timeframe.\n\n> > That might be a worthy goal, but I think it\'s a distraction for the\n> > Icehouse timeframe.\n> > Each new deployment strategy requires not only a new UI, but different\n> > deployment\n> > architectures that could have very little common with each other.\n> > Designing them all\n> > to work in the same space is a recipe for disaster, a convoluted gnarl of\n> > code that\n> > doesn\'t do any one thing particularly well.  To use an analogy: there\'s a\n> > reason why\n> > no one makes a flying boat car.\n> >\n> > I\'m going to strongly advocate that for Icehouse, we focus exclusively on\n> > large scale\n> > TripleO deployments, working to make that UI and architecture as sturdy as\n> > we can.  Future\n> > deployment strategies should be discussed in the future, and if they\'re not\n> > TripleO based,\n> > they should be discussed with the proper OpenStack group.\n> One concern here is - it is quite likely that we get people excited\n> about this approach - it will be a new boom - \'wow\', there is automagic\n> doing everything for me. But then the question would be reality - how\n> many from that excited users will actually use TripleO for their real\n> deployments (I mean in the early stages)? Would it be only couple of\n> them (because of covered use cases, concerns of maturity, lack of\n> control scarcity)? Can we assure them that if anything goes wrong, they\n> have control over it?\n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52A85A3A.1000701@redhat.com>',NULL),('<1567446924.36900260.1410480364590.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 20:06:04',-14400,'2014-09-12 00:06:04',NULL,'[openstack-dev] [all] [clients] [keystone] lack of retrying\n tokens leads to overall OpenStack fragility','\n\n----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-dev at lists.openstack.org\n> Sent: Thursday, 11 September, 2014 9:44:43 PM\n> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility\n> \n> On 09/10/2014 08:46 PM, Jamie Lennox wrote:\n> > \n> > ----- Original Message -----\n> >> From: \"Steven Hardy\" <shardy at redhat.com>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >> <openstack-dev at lists.openstack.org>\n> >> Sent: Thursday, September 11, 2014 1:55:49 AM\n> >> Subject: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying\n> >> tokens leads to overall OpenStack fragility\n> >>\n> >> On Wed, Sep 10, 2014 at 10:14:32AM -0400, Sean Dague wrote:\n> >>> Going through the untriaged Nova bugs, and there are a few on a similar\n> >>> pattern:\n> >>>\n> >>> Nova operation in progress.... takes a while\n> >>> Crosses keystone token expiration time\n> >>> Timeout thrown\n> >>> Operation fails\n> >>> Terrible 500 error sent back to user\n> >>\n> >> We actually have this exact problem in Heat, which I\'m currently trying to\n> >> solve:\n> >>\n> >> https://bugs.launchpad.net/heat/+bug/1306294\n> >>\n> >> Can you clarify, is the issue either:\n> >>\n> >> 1. Create novaclient object with username/password\n> >> 2. Do series of operations via the client object which eventually fail\n> >> after $n operations due to token expiry\n> >>\n> >> or:\n> >>\n> >> 1. Create novaclient object with username/password\n> >> 2. Some really long operation which means token expires in the course of\n> >> the service handling the request, blowing up and 500-ing\n> >>\n> >> If the former, then it does sound like a client, or usage-of-client bug,\n> >> although note if you pass a *token* vs username/password (as is currently\n> >> done for glance and heat in tempest, because we lack the code to get the\n> >> token outside of the shell.py code..), there\'s nothing the client can do,\n> >> because you can\'t request a new token with longer expiry with a token...\n> >>\n> >> However if the latter, then it seems like not really a client problem to\n> >> solve, as it\'s hard to know what action to take if a request failed\n> >> part-way through and thus things are in an unknown state.\n> >>\n> >> This issue is a hard problem, which can possibly be solved by\n> >> switching to a trust scoped token (service impersonates the user), but\n> >> then\n> >> you\'re effectively bypassing token expiry via delegation which sits\n> >> uncomfortably with me (despite the fact that we may have to do this in\n> >> heat\n> >> to solve the afforementioned bug)\n> >>\n> >>> It seems like we should have a standard pattern that on token expiration\n> >>> the underlying code at least gives one retry to try to establish a new\n> >>> token to complete the flow, however as far as I can tell *no* clients do\n> >>> this.\n> >>\n> >> As has been mentioned, using sessions may be one solution to this, and\n> >> AFAIK session support (where it doesn\'t already exist) is getting into\n> >> various clients via the work being carried out to add support for v3\n> >> keystone by David Hu:\n> >>\n> >> https://review.openstack.org/#/q/owner:david.hu%2540hp.com,n,z\n> >>\n> >> I see patches for Heat (currently gating), Nova and Ironic.\n> >>\n> >>> I know we had to add that into Tempest because tempest runs can exceed 1\n> >>> hr, and we want to avoid random fails just because we cross a token\n> >>> expiration boundary.\n> >>\n> >> I can\'t claim great experience with sessions yet, but AIUI you could do\n> >> something like:\n> >>\n> >> from keystoneclient.auth.identity import v3\n> >> from keystoneclient import session\n> >> from keystoneclient.v3 import client\n> >>\n> >> auth = v3.Password(auth_url=OS_AUTH_URL,\n> >>                    username=USERNAME,\n> >>                    password=PASSWORD,\n> >>                    project_id=PROJECT,\n> >>                    user_domain_name=\'default\')\n> >> sess = session.Session(auth=auth)\n> >> ks = client.Client(session=sess)\n> >>\n> >> And if you can pass the same session into the various clients tempest\n> >> creates then the Password auth-plugin code takes care of reauthenticating\n> >> if the token cached in the auth plugin object is expired, or nearly\n> >> expired:\n> >>\n> >> https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/identity/base.py#L120\n> >>\n> >> So in the tempest case, it seems like it may be a case of migrating the\n> >> code creating the clients to use sessions instead of passing a token or\n> >> username/password into the client object?\n> >>\n> >> That\'s my understanding of it atm anyway, hopefully jamielennox will be\n> >> along\n> >> soon with more details :)\n> >>\n> >> Steve\n> > \n> > \n> > By clients here are you referring to the CLIs or the python libraries?\n> > Implementation is at different points with each.\n> > \n> > Sessions will handle automatically reauthenticating and retrying a request,\n> > however it relies on the service throwing a 401 Unauthenticated error. If\n> > a service is returning a 500 (or a timeout?) then there isn\'t much that a\n> > client can/should do for that because we can\'t assume that trying again\n> > with a new token will solve anything.\n> > \n> > At the moment we have keystoneclient, novaclient, cinderclient\n> > neutronclient and then a number of the smaller projects with support for\n> > sessions. That obviously doesn\'t mean that existing users of that code\n> > have transitioned to the newer way though. David Hu has been working on\n> > using this code within the existing CLIs. I have prototypes for at least\n> > nova to talk to neutron and cinder which i\'m waiting for Kilo to push.\n> > From there it should be easier to do this for other services.\n> > \n> > For service to service communication there are two types.\n> > 1) using the user\'s token like nova->cinder. If this token expires there is\n> > really nothing that nova can do except raise 401 and make the client do it\n> > again.\n> \n> In this case it would be really good to do at least 1 retry, because\n> it\'s completely silly for us to fail an action based on a token timeout.\n> The solution ops are doing is changing their token expiration back to\n> some really large number.\n\nI think though that the correct response from nova here is still 401. Because we are using the user\'s token internally to nova there is not the option to re-authenticate (we don\'t have the user\'s credentials). Then the retry logic will happen on the client side. An improvement here might be the service token work we are looking at in keystonemiddleware. https://review.openstack.org/#/c/108384/\n\nBasically when nova talks to neutron/cinder or any of the other services it should submit to that service the user\'s token as now and an X-Service-Token which is that service\'s token. The intention here is to start limiting by policy what actions are allowed to be done on behalf of another service.\n\nI don\'t know how this would work but it may be acceptable that if both tokens are given we rely on the validity of the Service token and some window for the Auth token. It would indicate the token was valid when submitted to nova and nova is validating this by passing it\'s own token. Possibly that just shuffles the problem to the service token expiration but at least nova could do something about that.\n\nAgain we are only just at the point of allowing this in auth_token middleware, i\'m not sure of the greater security implications at this point. \n\n> > 2) using a service user like nova->neutron. This should allow automatic\n> > reauthentication and will be fixed/standardied by sessions.\n> \n> Ok, glanceclient should be a high target here, because that\'s often\n> involved in long running things (snapshot manip is slow).\n\nAll the clients are special, glance is extra special. I\'m not sure how to match what the session is capable of with the ssl compression mangling that glanceclient does, however it is really the next goal client.\n \n> 	-Sean\n> \n> --\n> Sean Dague\n> http://dague.net\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<54118B2B.6020500@dague.net>',NULL),('<1567572963.23178017.1370962308851.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 10:51:48',-14400,'2013-06-11 14:51:48',NULL,'[openstack-qa] Is tempest must be able to operate without\n identity admin privileges?','\n\n\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: openstack-qa at lists.openstack.org\n> Sent: Sunday, June 9, 2013 9:00:56 PM\n> Subject: Re: [openstack-qa] Is tempest must be able to operate without identity admin privileges?\n> \n> On 06/09/2013 03:26 AM, Attila Fazekas wrote:\n> > Looks like everybody is able to change the quota at the same time, when he\n> > creates the test user.\n> \n> No, this is not true. You need to have admin privileges do update the\n> quota of a tenant.\n> \nIt is true, because everybody has the admin privileges to create users.\nIn this use case, you just want to test the orations which is doable by a regular user.\n\n> > It implies the question:\n> >   Why do we create new tenants in test case,\n> >    which must be able to run in parallel with a single tenant ?\n> >\n> >   Why we not just create tenants only when it is really needed ?\n> \n> As mentioned before, creating a new tenant for the test case provides\n> isolation for the various list operations. If you are doing a call to,\n> say, list servers or list images, you need to be able to rely on the\n> result of that call not changing, otherwise you can get\n> non-deterministic assertions in tests due to other users in the same\n> tenant creating and destroying resources.\n\nThe tenant just isolates the user operations in most cases, but not always.\n\n\n> -jay\n> \n> > ----- Original Message -----\n> >> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> >> To: openstack-qa at lists.openstack.org\n> >> Sent: Sunday, June 9, 2013 12:17:29 AM\n> >> Subject: Re: [openstack-qa] Is tempest must be able to operate without\n> >> identity admin privileges?\n> >>\n> >> On 06/08/2013 02:05 PM, Daryl Walleck wrote:\n> >>> There\'s other ways to work around the quotas issue. The way I\'ve been\n> >>> handling this is configuring users that have modified quota groups. This\n> >>> has allowed me to run all my compute tests in parallel with a single\n> >>> user.\n> >>\n> >> Note that the above solution runs into the exact same issue that Attila\n> >> is talking about: you need admin privileges in order to change the quota\n> >> of a tenant.\n> >>\n> >> Best,\n> >> -jay\n> >>\n> >>> Daryl\n> >>>\n> >>> -----Original Message-----\n> >>> From: Attila Fazekas [mailto:afazekas at redhat.com]\n> >>> Sent: Saturday, June 8, 2013 8:04 AM\n> >>> To: Sean Dague\n> >>> Cc: All Things QA.\n> >>> Subject: Re: [openstack-qa] Is tempest must be able to operate without\n> >>> identity admin privileges?\n> >>>\n> >>> Do we want parallel execution in this cases ?\n> >>> - obviously yes\n> >>> - nice to have\n> >>> - who cares\n> >>>\n> >>> Can we expect larger quota than the default 10 in this case ?\n> >>> - never\n> >>> - usually\n> >>> - always\n> >>>\n> >>>\n> >>> ----- Original Message -----\n> >>>> From: \"Sean Dague\" <sean at dague.net>\n> >>>> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> >>>> Cc: \"Attila Fazekas\" <afazekas at redhat.com>\n> >>>> Sent: Saturday, June 8, 2013 1:49:40 PM\n> >>>> Subject: Re: [openstack-qa] Is tempest must be able to operate without\n> >>>> identity admin privileges?\n> >>>>\n> >>>> On 06/08/2013 03:06 AM, Attila Fazekas wrote:\n> >>>>> Hi All,\n> >>>>>\n> >>>>> In modeling viewpoint keeping the ability to run tempest without\n> >>>>> identity admin credentials is not easy.\n> >>>>>\n> >>>>> The demo and alt_demo user is still in the config to maintain the\n> >>>>> ability, to run tempest against a cloud where you do not know the\n> >>>>> identity admin credentials.\n> >>>>>\n> >>>>> I would like to know, is it real use case for anyone ?\n> >>>>>\n> >>>>> Without these users you lose the ability to run tempest against any\n> >>>>> cloud where you do not know the admin credentials.\n> >>>>>\n> >>>>> The benefits of removing these can give you:\n> >>>>>     - simpler model\n> >>>>>     - better role based test suite\n> >>>>\n> >>>> Yes, it is a real use case, we can\'t remove that.\n> >>>>\n> >>>> 	-Sean\n> >>>>\n> >>>> --\n> >>>> Sean Dague\n> >>>> http://dague.net\n> >>>>\n> >>>\n> >>> _______________________________________________\n> >>> openstack-qa mailing list\n> >>> openstack-qa at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >>>\n> >>> _______________________________________________\n> >>> openstack-qa mailing list\n> >>> openstack-qa at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> openstack-qa mailing list\n> >> openstack-qa at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >>\n> >\n> > _______________________________________________\n> > openstack-qa mailing list\n> > openstack-qa at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> >\n> \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B4D0E8.1050903@gmail.com>',NULL),('<1567655370.1.1377167490098.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-22 10:31:29',0,'2013-08-22 10:31:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-grizzly #9','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/9/>\n\n------------------------------------------\n[...truncated 1172 lines...]\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_api.TestApi.test_put_image_content_bad_container_format\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1350, in test_put_image_content_bad_container_format\n    self._do_test_put_image_content_missing_format(\'container_format\')\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1321, in _do_test_put_image_content_missing_format\n    response, content = http.request(path, \'POST\', headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 87.69 secs:\n    25.69    TestScrubber.test_scrubber_app\n    20.08    TestScrubber.test_delayed_delete\n    14.40    TestGlanceControl.test_reload\n    14.14    TestGlanceControl.test_respawn\n    13.38    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1101 tests in 555.232s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.9\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.13\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Qe29IUrUHq\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/9/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise14/9\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<15689009.2569.1347293266787.JavaMail.jsuh@remote40.east.isi.edu>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2012-09-10 09:07:50',-25200,'2012-09-10 16:07:50',NULL,'[openstack-hpc] weex address for today\'s meeting','All,\n\nToday\'s hpc meeting will be at https://usc-isi.webex.com/mw0306ld/mywebex/default.do?siteurl=usc-isi\n\nPassword is dodcs.\n\n\nThanks,\n\nJoseph\n\n----\n(w) 703-248-6160\n(c) 571-340-2434\n(f) 703-812-3712\nhttp://www.east.isi.edu/~jsuh\n\nInformation Sciences Institute\nUniversity of Southern California\n3811 N. Fairfax Drive Suite 200\nArlington, VA, 22203, USA\n\n\n\n\n','<27541478.2564.1347293235441.JavaMail.jsuh@remote40.east.isi.edu>',NULL),('<1569719664.30.1369375559394.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-24 06:05:59',0,'2013-05-24 06:05:59',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python26-stable-folsom #235','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/235/changes>\n\n\n\n','<1632751032.26.1369289377533.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1569960459.24369223.1379533933922.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-18 15:52:13',-14400,'2013-09-18 19:52:13',NULL,'[Openstack-docs] Basic Install Guides','Does the Install Guide specifically avoid including documentation on Neutron setups, or is that just something that needs to be done?\n\n----- Original Message -----\nFrom: \"Andreas Jaeger\" <aj at suse.com>\nTo: \"Solly Ross\" <sross at redhat.com>\nCc: openstack-docs at lists.openstack.org\nSent: Wednesday, September 18, 2013 3:37:15 PM\nSubject: Re: [Openstack-docs] Basic Install Guides\n\nOn 09/18/2013 09:29 PM, Solly Ross wrote:\n> Hello All,\n> I wanted to inquire as to the state/future of the basic install guides.  Currently, as far a I can tell, there are three \"basic install guides\": the one at the root of the basic install docs (http://docs.openstack.org/trunk/basic-install/content/basic-install_intro.html), which seems to be the most robust although slightly out of date wrt the naming of neutron; the yum-specific guide; and the apt-specific guide (which is a bit of a misnomer, since the first guide is also written for apt).  While the latter two appear to be more up to date with naming, they are also much less detailed and seem to leave out important information.\n> \n> I have followed the first of the listed basic install guides in an attempt to convert its more detailed information to Fedora/RHEL-compatible instructions.\n> \n> My question is this: which basic install guides should get updated?  The tool-specific guides (the latter two) appear to target a slightly different setup than the first guide.  Should the first of the three guides be removed and its instructions merged into the APT-specific guide?  Should the APT-specific guide be scrapped (with an updated version of the first guide taking its place) and the yum-specific guide updated to match the setup of the first guide?\n\nIn general, update the version that is the git master. We had build all\nguides from the same sources.\n\n*BUT* with the current restructering of the documentation, the basic\ninstall guide is dead and will not be published for future releases.\n\nYou should put your efforts in the Install Guide, it\'s in the git repo\nunder \"doc/install-guide\" - and build in three different versions from\nthe same sources.\n\nThe current set of books that we plan to release for Havana are\navailable via http://docs.openstack.org/trunk/\n\nAndreas\n-- \n Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n   GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n\n\n','<523A00EB.9070109@suse.com>',NULL),('<156C7552-1C2A-4A14-AAB6-96A171526687@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-12 13:08:04',-14400,'2014-09-12 17:08:04',NULL,'[openstack-dev] [neutron][all] switch from mysqldb to another\n	eventlet aware mysql client','\nOn Sep 12, 2014, at 1:03 PM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:\n\n> Signed PGP part\n> On 12/09/14 17:30, Mike Bayer wrote:\n> >\n> > On Sep 12, 2014, at 10:40 AM, Ihar Hrachyshka <ihrachys at redhat.com>\n> > wrote:\n> >\n> >> Signed PGP part On 12/09/14 16:33, Mike Bayer wrote:\n> >>> I agree with this, changing the MySQL driver now is not an\n> >>> option.\n> >>\n> >> That was not the proposal. The proposal was to introduce support\n> >> to run against something different from MySQLdb + a gate job for\n> >> that alternative. The next cycle was supposed to do thorough\n> >> regression testing, benchmarking, etc. to decide whether we\'re ok\n> >> to recommend that alternative to users.\n> >\n> > ah, well that is a great idea.  But we can have that throughout\n> > Kilo anyway, why not ?\n> \n> Sure, it\'s not the end of the world. We\'ll just need to postpone work\n> till RC1 (=opening of master for new stuff), pass spec bureauracy\n> (reapplying for kilo)... That\'s some burden, but not tragedy.\n> \n> The only thing that I\'m really sad about is that Juno users won\'t be\n> able to try out that driver on their setup just to see how it works,\n> so it narrows testing base to gate while we could get some valuable\n> deployment feedback in Juno already.\n\nIt?s all experimental, right? And implemented in libraries? So those users could update oslo.db and sqlalchemy-migrate and test the results under Juno.\n\nDoug\n\n\n\n','<54132770.4000206@redhat.com>',NULL),('<1570033088.21.1383113394358.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-30 06:09:54',0,'2013-10-30 06:09:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #34','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/34/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd290>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64b34d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64b34d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-2682bb30-1bf2-4f75-a0de-de5c2beb2fbe\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x412d7d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x412d7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x412d7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x412d7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:09:26Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'26\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:09:26Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'26\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:09:26+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'26\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:09:26-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'26\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:09:26Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'26\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x7226b10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2cd22d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 84.39 secs:\n    24.64    TestScrubber.test_scrubber_app\n    19.22    TestScrubber.test_delayed_delete\n    13.85    TestGlanceControl.test_reload\n    13.60    TestGlanceControl.test_respawn\n    13.09    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 488.739s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.34\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.22\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.9iwiAxZbaX\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/34/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise34/34\n[SCP] Copying console log.\n\n\n','<1464058161.18.1382940762850.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1570088335.479.1367131027302.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:37:07',0,'2013-04-28 06:37:07',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-postgres-stable-grizzly #24','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/24/>\n\n\n\n','<749018483.391.1367042855544.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<157061172.2.1386915375597.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:16:15',0,'2013-12-13 06:16:15',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-docs-havana #6','See <https://jenkins01.openstack.org/job/periodic-ceilometer-docs-havana/6/changes>\n\n\n\n','<643083404.77.1386828299230.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1570912265.32340926.1402427185275.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 15:06:25',-14400,'2014-06-10 19:06:25',NULL,'[openstack-dev] [NFV] Re: NFV in OpenStack use cases and context','----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: \"Stephen Wong\" <stephen.kf.wong at gmail.com>\n> \n> ----- Original Message -----\n> > From: \"Stephen Wong\" <stephen.kf.wong at gmail.com>\n> > To: \"ITAI MENDELSOHN (ITAI)\" <itai.mendelsohn at alcatel-lucent.com>,\n> > \"OpenStack Development Mailing List (not for usage\n> > questions)\" <openstack-dev at lists.openstack.org>\n> > \n> > Hi,\n> > \n> >     Perhaps I have missed it somewhere in the email thread? Where is the\n> > use case => bp document we are supposed to do for this week? Has it been\n> > created yet?\n> > \n> > Thanks,\n> > - Stephen\n> \n> Hi,\n> \n> Itai is referring to the ETSI NFV use cases document [1] and the discussion\n> is around how we distill those - or a subset of them - into a more\n> consumable format for an OpenStack audience on the Wiki. At this point I\n> think the best approach is to simply start entering one of them (perhaps #5)\n> into the Wiki and go from there. Ideally this would form a basis for\n> discussing the format etc.\n> \n> Thanks,\n> \n> Steve\n> \n> [1]\n> http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf\n\nTo try and kick start things I have created a table on the wiki [1] based on the *DRAFT* NFV Performance & Portability Best Practises document [2]. This really lists workload types rather than specific applications, although I\'ve put in an examples column we can populate with them.\n\nI find it a useful way to quickly break down some of the characteristics of NFV applications at a glance. What do people think of this as something to start with? Remember, it\'s a wiki! So anyone is welcome to either expand the table or start adding more concrete user stories (e.g. around ETSI NFV use case number 5 that Itai and I have been referring to, or any other VNF for that matter) in this section (we may/want need to create a separate page but for now it seems OK to get started here).\n\nThanks,\n\nSteve\n\n[1] https://wiki.openstack.org/wiki/Meetings/NFV#Use_Cases\n[2] http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20&%20Portability%20Best%20Practises.pdf\n\n\n','<78144109.32176129.1402416920344.JavaMail.zimbra@redhat.com>',NULL),('<1571154258.34.1378361369192.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-05 06:09:29',0,'2013-09-05 06:09:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #15','See <https://jenkins02.openstack.org/job/periodic-horizon-python26-stable-folsom/15/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-14 in workspace <https://jenkins02.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/>\nCheckout:periodic-horizon-python26-stable-folsom / <https://jenkins02.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/> - hudson.remoting.Channel at 5115f2f9:centos6-14\nUsing strategy: Default\nLast Built Revision: Revision d202fd4e8a86cc8a5fe787be3fb5c17c86b8daaa (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/horizon\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://git.openstack.org/openstack/horizon\nCommencing build of Revision d202fd4e8a86cc8a5fe787be3fb5c17c86b8daaa (origin/stable/folsom)\nChecking out Revision d202fd4e8a86cc8a5fe787be3fb5c17c86b8daaa (origin/stable/folsom)\n[periodic-horizon-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson7693370976137418298.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.k2pagTa7fV\n+ TMPDIR=/tmp/tmp.k2pagTa7fV\n+ trap \'rm -rf /tmp/tmp.k2pagTa7fV\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n++ org=openstack\n++ project=horizon\n++ [[ -z openstack ]]\n++ [[ -z horizon ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' horizon == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\n2012.2.5\n+ tox -epy26\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 48: tox: command not found\n+ result=127\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 53: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 127\n+ rm -rf /tmp/tmp.k2pagTa7fV\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/centos6-14\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/centos6-14/15\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1571228038.51.1381558275156.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-12 06:11:15',0,'2013-10-12 06:11:15',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #33','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/33/>\n\n\n\n','<1442742900.35.1381212667008.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1571434510.94.1365746787748.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-12 06:06:27',0,'2013-04-12 06:06:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #2','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/2/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-12 06:06:23    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:06:23,726 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-12 06:06:23,726 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:06:23,727 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,728 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,729 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-12 06:06:23,730 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-12 06:06:23,731 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-12 06:06:23  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-12 06:06:23,732 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:06:23    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-12 06:06:23,733 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,738 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.737987\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.737987\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23,739 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,740 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,740 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,742 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23,743 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.742283\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.742283\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23,744 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,745 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,746 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:06:23,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,749 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23,750 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.749336\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.749336\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,752 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,753 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:06:23,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,756 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23,757 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.756399\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.756399\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23,758 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,759 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,760 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:06:23,760 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,761 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,763 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-12 06:06:23,764 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-12 06:06:23,765 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.764729\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-12T06:06:23.764729\', resource_metadata={}) from 0 transformer\n2013-04-12 06:06:23,766 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,767 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23,768 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-12 06:06:23,769 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-12 06:06:23,770 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-12 06:06:23    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.881s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.2\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a43.g50c2020\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.1.0\nkombu==2.5.10\nlxml==3.1.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a298.g4861a3b\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.oLq8OgJiFu\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/2\n[SCP] Copying console log.\n\n\n','<219481126.77.1365660506087.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1571922478.318.1355014821082.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-12-09 01:00:20',0,'2012-12-09 01:00:20',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #38','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/38/>\n\n------------------------------------------\n[...truncated 14242 lines...]\nAttempt to assign a non existent role to user should fail ... ok\nAttempt to assign a role on a non existent tenant should fail ... ok\nAttempt to assign a role to a non existent user should fail ... ok\nRequest to assign a role to a user without a valid token ... ok\nReturn a list of all roles ... ok\nNon admin user should not be able to list roles ... ok\nRequest to list roles without a valid token should fail ... ok\nList roles assigned to a user on tenant ... ok\nNon admin user should not be authorized to list a user\'s roles ... ok\nAttempt to list roles of a non existent user should fail ... ok\nRequest to list user\'s roles without a valid token should fail ... ok\nRemove a role assigned to a user on a tenant ... ok\nNon admin user should not be authorized to remove a user\'s role ... ok\nAttempt to delete a non existent role from a user should fail ... ok\nAttempt to remove a role from a non existent tenant should fail ... ok\nAttempt to remove a role from a non existent user should fail ... ok\nRequest to remove a user\'s role without a valid token ... ok\nShould not be able to create a role with a blank name ... ok\nRole should be created, verified, and deleted ... ok\nRole names should be unique ... ok\nDuplicate user role should not get assigned ... ok\nAssign a role to a user on a tenant ... ok\nNon admin user should not be authorized to assign a role to user ... ok\nAttempt to assign a non existent role to user should fail ... ok\nAttempt to assign a role on a non existent tenant should fail ... ok\nAttempt to assign a role to a non existent user should fail ... ok\nRequest to assign a role to a user without a valid token ... ok\nReturn a list of all roles ... ok\nNon admin user should not be able to list roles ... ok\nRequest to list roles without a valid token should fail ... ok\nList roles assigned to a user on tenant ... ok\nNon admin user should not be authorized to list a user\'s roles ... ok\nAttempt to list roles of a non existent user should fail ... ok\nRequest to list user\'s roles without a valid token should fail ... ok\nRemove a role assigned to a user on a tenant ... ok\nNon admin user should not be authorized to remove a user\'s role ... ok\nAttempt to delete a non existent role from a user should fail ... ok\nAttempt to remove a role from a non existent tenant should fail ... ok\nAttempt to remove a role from a non existent user should fail ... ok\nRequest to remove a user\'s role without a valid token ... ok\nShould not be able to create a role with a blank name ... ok\nRole should be created, verified, and deleted ... ok\nRole names should be unique ... ok\nGET Service ... ok\nSKIP: Skipping until Bug #1061738 resolved\nNon-admin user should not be authorized to create a tenant ... ok\nCreate tenant request without a token should not be authorized ... ok\nTenant name should not be empty ... ok\nTenant name length should not be greater than 64 characters ... ok\nAttempt to delete a non existent tenant should fail ... ok\nRequest to list tenants without a valid token should fail ... ok\nReturn a list of all tenants ... ok\nNon-admin user should not be able to list tenants ... ok\nTenant names should be unique ... ok\nCreate a tenant that is enabled ... ok\nCreate a tenant that is not enabled ... ok\nCreate tenant with a description ... ok\nCreate several tenants and delete them ... ok\nNon-admin user should not be able to delete a tenant ... ok\nRequest to delete a tenant without a valid token should fail ... ok\nUpdate description attribute of a tenant ... ok\nUpdate the enabled attribute of a tenant ... ok\nUpdate name attribute of a tenant ... ok\nNon-admin user should not be authorized to create a tenant ... ok\nCreate tenant request without a token should not be authorized ... ok\nTenant name should not be empty ... ok\nTenant name length should not be greater than 64 characters ... ok\nAttempt to delete a non existent tenant should fail ... ok\nRequest to list tenants without a valid token should fail ... ok\nReturn a list of all tenants ... ok\nNon-admin user should not be able to list tenants ... ok\nTenant names should be unique ... ok\nCreate a tenant that is enabled ... ok\nCreate a tenant that is not enabled ... ok\nCreate tenant with a description ... ok\nCreate several tenants and delete them ... ok\nNon-admin user should not be able to delete a tenant ... ok\nRequest to delete a tenant without a valid token should fail ... ok\nUpdate description attribute of a tenant ... ok\nUpdate the enabled attribute of a tenant ... ok\nUpdate name attribute of a tenant ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nRegister a new remote image ... ok\nRegister, then upload an image ... ok\nNegative tests for invalid data supplied to POST /images ... ok\nSimple test to see all fixture images returned ... ok\nSKIP: No OpenStack Network API endpoint\nAdd metadata to account ... ok\nDelete metadata from account ... ok\nList all account metadata ... ok\nList of all containers should not be empty ... ok\nUpdate/Retrieve/Delete Container Metadata ... ok\nCreate a container, test responses ... ok\nCreate and Delete a container, test responses ... ok\nAdd metadata to object ... ok\nCopy storage object ... ok\nCopy storage object across containers ... ok\nCopy storage object ... ok\nChange the content type of an existing object ... ok\nCreate storage object, test response ... ok\nCreate and delete a storage object, test responses ... ok\nRetrieve object\'s data(in response body) ... ok\nAdd metadata to storage object, test if metadata is retrievable ... ok\nVersioned container responses tests ... ok\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nERROR: Creating a server with a name that already exists is allowed\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 63, in test_create_with_existing_server_name\n    self.client.wait_for_server_status(server[\'id\'], \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/servers_client.py\", line 155, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 4fe6968b-40ed-4e26-8bf5-882589b16242 failed to build and is in ERROR status\n\n======================================================================\nERROR: Creating a server with a name that already exists is allowed\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 63, in test_create_with_existing_server_name\n    self.client.wait_for_server_status(server[\'id\'], \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/servers_client.py\", line 190, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server ecd4d28a-9b0d-4541-93e2-e8cc34698c53 failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 547 tests in 2236.155s\n\nFAILED (SKIP=69, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/rabbitmq/rabbit at devstack-1354971654-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/rabbitmq/rabbit at devstack-1354971654.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/38/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1571949163.6636806.1386961685718.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-13 14:08:05',-18000,'2013-12-13 19:08:05',NULL,'[openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements\n	-	Summary, Milestones','> Quick note - I want to keep this discussion a bit high-level and not to\n> get into big implementation details. For everyone, please, let\'s agree\n> in this thread on the direction and approach and we can start follow-up\n> threads with bigger details of how to get those things done.\n\nI\'m not sure how the items listed below are implementation details; they seem\nlike scoping the requirements to me.\n\n> On 2013/13/12 12:04, Tzu-Mainn Chen wrote:\n> >> *VERSION 0*\n> >> ===========\n> >> Enable user to deploy OpenStack with the simpliest TripleO way, no\n> >> difference between hardware.\n> >>\n> >> Target:\n> >> - end of icehouse-2\n> >\n> > My impression was that some of these features required features to be\n> > developed in other\n> > OpenStack services - if so, should we call those out so that we can see if\n> > they\'ll be\n> > available in the icehouse-2 timeframe?\n> As for below listed features for v0 - it is the smallest set of what we\n> have to have in the UI - if there is some delay in other services, we\n> have to put attention there as well. But I don\'t think there is anything\n> blocking us at the moment.\n> \n> >> Features we need to get in:\n> >> - Enable manual nodes registration (Ironic)\n> >> - Get images available for user (Glance)\n> >\n> > Are we still providing the Heat template?  If so, are there image\n> > requirements that we\n> > need to take into account?\n> I am not aware of any special requirements, but I will let experts to\n> answer here...\n> \n> >\n> >> - Node roles (hardcode): Controller, Compute, Object Storage, Block\n> >> Storage\n> >> - Design deployment (number of nodes per role)\n> >\n> > We\'re only allowing a single deployment, right?\n> Correct. For the whole Icehouse. I don\'t think we can get multiple\n> deployments in time, there are much more important features.\n> \n> >> - Deploy (Heat + Nova)\n> >\n> > What parameters are we passing in for deploy?  Is it limited to the # of\n> > nodes/role, or\n> > are we also passing in the image?\n> I think it is # nodes/role and image as well. Though images might be\n> hardcoded for the very first iteration. Soon we should be able to let\n> user assign images to roles.\n> \n> > Do we also need the following?\n> >\n> > * unregister a node in Ironic\n> > * update a deployment (add or destroy instances)\n> > * destroy a deployment\n> > * view information about management node (instance?)\n> > * list nodes/instances by role\n> > * view deployment configuration\n> > * view status of deployment as it\'s being deployed\n> Some of that is part of above mentioned, some a bit later down the road\n> (not far away though). We need all of that, but let\'s enable user to\n> deploy first and we can add next features after we get something working\n> then.\n\nWell, these are requirements that I previously pulled from your wireframes\nthat aren\'t listed anywhere, so I don\'t know if they were forgotten, descoped,\nor assumed to be part of release 0.  If it\'s assumed, I think it\'s important\nthat we call it out; otherwise, I\'m not sure how we can appropriately evaluate\nwhether the feature list fits into the icehouse-2 timeframe.\n\nI\'m also not sure what we consider \"needed\".  To me, it seems like:\n\na) NEEDED\n   * list nodes/instances by role\n\nb) STANDARD (but possibly not needed?)\n   * unregister a node\n   * update a deployment\n   * destroy a deployment\n   * view status of deployment as it\'s being deployed\n\nc) UNSURE\n   * view information about a management node\n   * view deployment configuration - I vaguely recall someone saying that it was \nimportant for the user to view the options being used when creating the overcloud,\neven if those options were uneditable defaults.\n\n\nRegarding the split in features between icehouse-2 and icehouse-3 - I\'m not sure it makes sense.\nWe\'re re-architecting all of tuskar, and as such, I think it\'s more important to call out the\nfeatures we want for *all* of icehouse.  Otherwise, it\'s possible that we\'ll create an architecture\nthat works for icehouse-2 but which needs to be significantly reworked for icehouse-3.\n\nFor that reason, I think it might make more sense to work towards a single deadline within icehouse.\n\n\nMainn\n\n\n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52AAF629.6020102@redhat.com>',NULL),('<1571961.csgZE2zXLH@horus>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-28 19:40:35',3600,'2013-10-28 18:40:35',NULL,'[Openstack] Can\'t connect to RabbitMQ','Hello,\n\nI\'ve installed OpenStack on a Ubuntu 12.04 VM according to the install guide. \nIt worked fine until I created the compute node on a second VM and tried to set \nup nova networking:\n \nhttp://docs.openstack.org/havana/install-guide/install/apt/content/nova-network.html\n\n# nova network-create vmnet --fixed-range-v4=10.0.0.0/24 --bridge-\ninterface=br100 --multi-host=T\n\njust does nothing until canceled. I tried on the controller and compute1 node.\n\nnova-api.log shows:\n\nERROR nova.openstack.common.rpc.common AMQP server on controller:5672 is \nunreachable: Socket closed. Trying again in 1 seconds.\nINFO nova.openstack.common.rpc.common Reconnecting to AMQP server on \ncontroller:5672\n\ncontroller:~# netstat -lpn | grep beam\ntcp        0      0 0.0.0.0:36595           0.0.0.0:*               LISTEN      \n1045/beam       \ntcp6       0      0 :::5672                 :::*                    LISTEN      \n1045/beam\n\nIt listens on this port, but IPv6. IMO on linux listing on an IPv6 port also \nmeans listening on the same v4 port.\n\nWhat\'s wrong with the installation?\n\nThanks a lot!\n\nFlorian\n\n\n',NULL,NULL),('<1572078871.2720713.1390217510476.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-20 06:31:50',-18000,'2014-01-20 11:31:50',NULL,'[Openstack] [HA] [neutron] neutron-l3-agent & HA host=.. parameter','\n\n    Hi!,\n   \n    I want to ask, specifically, about the intended purpose of the\nhost=... parameter in the neutron-agents (undocumented AFAIK).\n\n    I\'ve been checking a reference HA setup, where one of the issues\nwas having an HA l3-agent in active/passive or active/active.\n\n    One of the configurations we came up with, was setting two network\nnodes, in active/passive, and using the \"host=....\" config field in\nagents. \n    \n   Network Node 1:  /etc/neutron/l3_agent.ini   host=ha-nnode\n   Network Node 2:  /etc/neutron/l3_agent.ini   host=ha-nnode\n\n\n      This allows that in the event that the active node goes down,\nthe passive l3-agent can be started, and it will take all virtual routers\nassociated to the first node. Otherwise (if they had different host \nidentifications), the virtual routers would stick scheduled to the \nfirst network node they were scheduled to... as, when an l3-agent\nfirst connects to neutron server, it gets routers scheduled to itself.\n\n\nThinking of active/active\n\n      One interesting feature, regarding this, could be automatically\nrescheduling virtual routers from down l3-agents to other available l3-agents\nwhich have the same external network connectivity capabilities. But ok,\nthat\'s content for a blueprint, and I\'m sure that has many situations to\naddress: for example, we wouldn\'t want several nodes running the same\nvirtual-router configurations at the same time without VRRP or equivalents...,\nwhich in an active/passive setup like the one explained above, can be\nhandled with fencing/power cycling the failing node.\n\n   That kind of behavior is already handled externally by this tool:\nhttps://github.com/stackforge/cookbook-openstack-network/blob/master/files/default/neutron-ha-tool.py\n\n\n\nCheers,\n    Miguel ?ngel Ajo\n\n\n\n    \n   \n\n\n','<1378474918.2705679.1390215926822.JavaMail.root@redhat.com>',NULL),('<1573007773.24724639.1403190353065.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-19 11:05:53',-14400,'2014-06-19 15:05:53',NULL,'[openstack-dev] [Neutron][ML2] Modular L2 agent architecture','----- Original Message -----\n> What\'s the progress by Terry Wilson?\n> If not much, I\'m willing to file blueprint/spec and drive it.\n> \n> thanks,\n\nI\'ve been working on some proof-of-concept code to help flesh out ideas for writing the spec. I\'d talked to Maru and he mentioned that he didn\'t think that the official OVS python library was a good base for this (the one that ryu uses). I don\'t remember what all of the reasons were, though. It isn\'t particularly well documented, but that can always be remedied. Does anyone else have any experience with the official OVS python API who could speak to its quality/stability/usefulness? It looked fairly full-featured.\n\nTerry\n \n> On Wed, Jun 18, 2014 at 07:00:59PM +0900,\n> Isaku Yamahata <isaku.yamahata at gmail.com> wrote:\n> \n> > Hi. Ryu provides ovs_vsctl.py library which is python equivalent to\n> > ovs-vsctl command. It speaks OVSDB protocl.\n> > https://github.com/osrg/ryu/blob/master/ryu/lib/ovs/vsctl.py\n> > \n> > So with the library, it\'s mostly mechanical change to convert\n> > ovs_lib.py, I think.\n> > I\'m not aware other similar library written in python.\n\nMost of ryu\'s library is implemented on top of the official OVS python stuff: https://github.com/openvswitch/ovs/tree/master/python/ovs\n\nTerry\n\n\n','<20140619013837.GE10003@private.email.ne.jp>',NULL),('<1573472825.224029.1389577582494.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-12 20:46:22',-18000,'2014-01-13 01:46:22',NULL,'[Openstack-docs] Ice House vs Icehouse vs IceHouse vs icehouse','+1 Icehouse\n\ncheers, Summer\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n> From: \"Nermina Miller\" <nmiller at mirantis.com>\n> To: \"Diane Fleming\" <diane.fleming at RACKSPACE.COM>\n> Cc: \"Andreas Jaeger\" <aj at suse.com>, openstack-docs at lists.openstack.org\n> Sent: Saturday, January 11, 2014 12:30:21 AM\n> Subject: Re: [Openstack-docs] Ice House vs Icehouse vs IceHouse vs icehouse\n> \n> +1\n> \n> Nermina\n> \n> On Jan 10, 2014, at 9:24 AM, Diane Fleming <diane.fleming at RACKSPACE.COM>\n> wrote:\n> \n> > +1 Icehouse\n> > Diane\n> > ----------------------------------------------\n> > Diane Fleming\n> > Software Developer II - US\n> > \n> > diane.fleming at rackspace.com\n> > Cell  512.323.6799\n> > Office 512.874.1260\n> > Skype drfleming0227\n> > Google-plus diane.fleming at gmail.com\n> > \n> > \n> > \n> > \n> > \n> > \n> > On 1/10/14 4:03 AM, \"Lana Brindley\" <openstack at lanabrindley.com> wrote:\n> > \n> >> \n> >> On 10 Jan 2014, at 4:04 pm, Andreas Jaeger <aj at suse.com> wrote:\n> >> \n> >>> On 01/10/2014 01:16 AM, Tom Fifield wrote:\n> >>>> Hi,\n> >>>> \n> >>>> Just following up from suggestions made in\n> >>>> https://review.openstack.org/#/c/65616/ to change \"Ice House\" to\n> >>>> \"Icehouse\".\n> >>>> \n> >>>> So far I\'ve regularly written Ice House or IceHouse, because the proper\n> >>>> name of the original street is two separate words, both in Chinese and\n> >>>> English.\n> >>>> \n> >>>> However, I do see that Icehouse/icehouse is in frequent use on the wiki\n> >>>> and on launchpad.\n> >>>> \n> >>>> So, what\'s the standard for documentation? :)\n> >>> \n> >>> It\'s a code name derived from the street \"Ice House\". When we voted for\n> >>> the name in May, the vote was for Icehouse and that\'s how I have seen it\n> >>> written in all other sites.\n> >>> \n> >>> From the Release_Naming wiki page \"Only single words with a maximum of\n> >>> 10 characters are good candidates for a name\". So, we voted for Icehouse\n> >>> and that\'s what I suggest to use, let\'s not confuse people.\n> >> \n> >> +1\n> >> \n> >> L\n> >> \n> >> _______________________________________________\n> >> Openstack-docs mailing list\n> >> Openstack-docs at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> > \n> > _______________________________________________\n> > Openstack-docs mailing list\n> > Openstack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n\n','<72E1D788-2A43-46A3-9CD4-6F5794FE8A4B@gmail.com>',NULL),('<1573912846.6.1376633975474.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-16 06:19:35',0,'2013-08-16 06:19:35',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #5','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/5/>\n\n\n\n','<1130040139.6.1376460977523.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1573948199.277.1366610832008.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-22 06:07:11',0,'2013-04-22 06:07:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #12','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/12/>\n\n------------------------------------------\n[...truncated 5087 lines...]\n2013-04-22 06:07:07    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-22 06:07:07,270 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-22 06:07:07,271 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-22 06:07:07,271 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,272 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,273 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-22 06:07:07,274 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-22 06:07:07,275 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-22 06:07:07  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-22 06:07:07,276 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-22 06:07:07    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-22 06:07:07,277 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,283 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.283166\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.283166\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07,284 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,286 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,287 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,289 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07,290 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.289027\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.289027\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07,292 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,293 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,294 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-22 06:07:07,295 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,297 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,299 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07,300 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.298984\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.298984\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07,301 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,302 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,304 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-22 06:07:07,305 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,306 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,308 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07,310 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.308486\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.308486\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07,311 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,312 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,314 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-22 06:07:07,315 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,316 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,318 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-22 06:07:07,320 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-22 06:07:07,322 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.320618\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-22T06:07:07.320618\', resource_metadata={}) from 0 transformer\n2013-04-22 06:07:07,323 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,324 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07,325 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-22 06:07:07,326 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-22 06:07:07,328 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-22 06:07:07    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.602s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.12\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a332.g18d9a8b\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.YoXb4gku9f\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/12\n[SCP] Copying console log.\n\n\n','<1191921867.256.1366524394124.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1573988288.325.1357085934688.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-02 00:18:54',0,'2013-01-02 00:18:54',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-cinder-stable-folsom #93','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/93/>\n\n\n\n','<682970803.306.1357001637046.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1574091941.9632633.1375294840544.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-31 14:20:40',-14400,'2013-07-31 18:20:40',NULL,'[Openstack-docs] Common content strategy?','Hi all,\n\nIn the lead up to the Grizzly release I made a handful of commits to move shared content into the common directory, where it was not already there. This had the effect of:\n\n- Making it more obvious which content was actually shared (in one case I even found a file inside the openstack-compute-admin folder that was no longer used in that guide at all, but was used by others).\n- Making it easier for me to transform/build with Publican (an admittedly selfish reason but listing for completeness :)). \n\nLooking at the state of the repository as it stands today I have noticed that a few instances of the following have been creeping back in as a result of the restructuring efforts:\n\n- Content that has become common (linked in to multiple guides) but not been moved to a location beneath the \"common\" folder (I\'m ignoring here the case where the cli-guide now largely includes content from the user-guide folder as I believe the cli-guide is effectively now part of the user-guide effort?).\n- Content in the \"common\" folder that itself links in content from other guides - effectively resulting in (1).\n\nI was wondering whether there are any objections to me continuing to submit patches to move common content falling into these categories into common (and of course update the relevant xi:includes)? There are by no means a lot of these but I feel like it\'s probably easier to keep on top of them as they come to light rather than waiting - that is if others agree it\'s not problematic for me to be doing this. I was also wondering if there might be a need to define a deeper taxonomy for content under the \"common\" folder?\n\nThanks,\n\nSteve\n\n\n','<542621385.9589250.1375288148935.JavaMail.root@redhat.com>',NULL),('<1574154473.2112422.1417422671344.JavaMail.yahoo@jws10913.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-01 08:31:11',0,'2014-12-01 08:31:11',NULL,'[Openstack] failing to boot instance \"message\": \"No valid host\n was found. There are not enough hosts available.\"','Hi Geo Varghese,?\nNo neutron service I use nova legacy networking. Neutron is disabled.?\n?\nRegards\nNeelu \n\n     On Monday, 1 December 2014 1:35 AM, Geo Varghese <gvarghese at aqorn.com> wrote:\n   \n\n Please paste the output of \n\nneutron agent-list\n\nI think something will be down in it.\n\nOn Sun, Nov 30, 2014 at 5:06 PM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n\nSeems text size was not proper resending it.?\nHi All,?\nI am newbie to openstack, I am trying to get my first istance to boot.? ANy pointers on this will help, thanks in advance\nI see this error while booting.? I have not installed glance or swift on compute node.?On controller node its full stack setup done by devops quick start ..\n\nfault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec,\nopenstack paste link\nPaste #141783 | LodgeIt!\n\n| ? |\n| ? | ? | ? | ? | ? |\n| Paste #141783 | LodgeIt![neelumadhu at localhost devstack]$ nova-manage service list 2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:65 2014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e8... |\n|  |\n| View on?paste.openstack.org | Preview by Yahoo |\n|  |\n| ? |\n\n?\nlogs given below ?with each command?\nOn controller side I have setup using Devops quick start to setup steps.?On compute node I have followed steps mentioned at openstack manual steps.?\n\n\nlogs-----[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29295) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 05:53:28.241 DEBUG oslo.db.sqlalchemy.session [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29295) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:192014-11-30 05:53:28.398 DEBUG nova.servicegroup.drivers.db [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 761.398104 from (pid=29295) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:25nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:19\n\n[neelumadhu at localhost devstack]$ nova image-list+--------------------------------------+---------------------------------+--------+--------+| ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Status | Server |+--------------------------------------+---------------------------------+--------+--------+| db82f672-df9f-403c-a7de-7f0b4ba487d9 | Fedora-x86_64-20-20140618-sda ? | ACTIVE | ? ? ? ?|| 0af91b22-5306-4c97-8761-3800f9029907 | cirros-0.3.2-x86_64-uec ? ? ? ? | ACTIVE | ? ? ? ?|| da9e55ab-f25e-4886-8b75-9fc2e7069cb6 | cirros-0.3.2-x86_64-uec-kernel ?| ACTIVE | ? ? ? ?|| e3f5ef50-433a-4bbd-9007-b1386c129be0 | cirros-0.3.2-x86_64-uec-ramdisk | ACTIVE | ? ? ? ?|+--------------------------------------+---------------------------------+--------+--------+[neelumadhu at localhost devstack]$?\n[neelumadhu at localhost devstack]$ nova boot --flavor 2 --image 0af91b22-5306-4c97-8761-3800f9029907 test44+--------------------------------------+----------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+----------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| scheduling ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| building ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| adminPass ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SUFRq8WmQy3p ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? || image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) || key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || progress ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | BUILD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:32Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+----------------------------------------------------------------+\n\n[neelumadhu at localhost devstack]$ nova show 16e847eb-7f51-48d5-a8b8-cafb99a12605+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| fault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 49, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 35, in __run_method ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? return getattr(self.instance, __name)(*args, **kwargs) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/query.py\\\", line 34, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/rpcapi.py\\\", line 112, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec=request_spec, filter_properties=filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\\\", line 152, in call ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=self.retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py\\\", line 90, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? timeout=timeout, retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 408, in send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 399, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? raise result ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| \", \"created\": \"2014-11-30T10:58:20Z\"} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | d084bb735e188f6a0d20e6485ba7347c6d9cea4ceae2f9763af00b09 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| private network ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:58:19Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+[neelumadhu at localhost devstack]$?\n\n\n[neelumadhu at localhost devstack]$ nova host-list+-----------------------+-------------+----------+| host_name ? ? ? ? ? ? | service ? ? | zone ? ? |+-----------------------+-------------+----------+| localhost.localdomain | conductor ? | internal || localhost.localdomain | cert ? ? ? ?| internal || localhost.localdomain | compute ? ? | nova ? ? || localhost.localdomain | scheduler ? | internal || localhost.localdomain | consoleauth | internal || compute1 ? ? ? ? ? ? ?| network ? ? | internal || compute1 ? ? ? ? ? ? ?| compute ? ? | nova ? ? |+-----------------------+-------------+----------+[neelumadhu at localhost devstack]$ nova service-list+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| Id | Binary ? ? ? ? ? | Host ? ? ? ? ? ? ? ? ?| Zone ? ? | Status ?| State | Updated_at ? ? ? ? ? ? ? ? | Disabled Reason |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| 1 ?| nova-conductor ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 2 ?| nova-cert ? ? ? ?| localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:02:59.000000 | - ? ? ? ? ? ? ? || 3 ?| nova-compute ? ? | localhost.localdomain | nova ? ? | enabled | down ?| - ? ? ? ? ? ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? || 4 ?| nova-scheduler ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 5 ?| nova-consoleauth | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 6 ?| nova-network ? ? | compute1 ? ? ? ? ? ? ?| internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 7 ?| nova-compute ? ? | compute1 ? ? ? ? ? ? ?| nova ? ? | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 06:03:26.915 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29950) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 06:03:26.955 DEBUG oslo.db.api [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29950) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:03:27.400 DEBUG oslo.db.sqlalchemy.session [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29950) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:192014-11-30 06:03:27.669 DEBUG nova.servicegroup.drivers.db [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 1360.669212 from (pid=29950) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26[neelumadhu at localhost devstack]$ nova-manage host list\nhost ? ? ? ? ? ? ? ? ? ?? zone ? ? ? ? ??2014-11-30 06:04:08.471 DEBUG oslo.db.api [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29971) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:04:08.875 DEBUG oslo.db.sqlalchemy.session [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29971) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509localhost.localdomain ? ? internal ? ? ??compute1 ? ? ? ? ? ? ? ?? internal ? ? ??[neelumadhu at localhost devstack]$?[neelumadhu at localhost devstack]$?\n\n\n----------------log ends\nNeelu?\n\n\n     On Sunday, 30 November 2014 6:25 AM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n   \n\n Hi All,?\nI am newbie to openstack, I am trying to get my first istance to boot.? ANy pointers on this will help, thanks in advance\nI see this error while booting.? I have not installed glance or swift on compute node.?On controller node its full stack setup done by devops quick start ..\n\nfault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec,\nopenstack paste link\nPaste #141783 | LodgeIt!\n\n| ? |\n| ? | ? | ? | ? | ? |\n| Paste #141783 | LodgeIt![neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e8... |\n|  |\n| View on paste.openstack.org | Preview by Yahoo |\n|  |\n| ? |\n\n ?\nlogs given below ?with each command?\nOn controller side I have setup using Devops quick start to setup steps.?On compute node I have followed steps mentioned at openstack manual steps.?\n\n\nlogs-----[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29295) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 05:53:28.241 DEBUG oslo.db.sqlalchemy.session [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29295) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:192014-11-30 05:53:28.398 DEBUG nova.servicegroup.drivers.db [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 761.398104 from (pid=29295) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:25nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:19\n\n[neelumadhu at localhost devstack]$ nova image-list+--------------------------------------+---------------------------------+--------+--------+| ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Status | Server |+--------------------------------------+---------------------------------+--------+--------+| db82f672-df9f-403c-a7de-7f0b4ba487d9 | Fedora-x86_64-20-20140618-sda ? | ACTIVE | ? ? ? ?|| 0af91b22-5306-4c97-8761-3800f9029907 | cirros-0.3.2-x86_64-uec ? ? ? ? | ACTIVE | ? ? ? ?|| da9e55ab-f25e-4886-8b75-9fc2e7069cb6 | cirros-0.3.2-x86_64-uec-kernel ?| ACTIVE | ? ? ? ?|| e3f5ef50-433a-4bbd-9007-b1386c129be0 | cirros-0.3.2-x86_64-uec-ramdisk | ACTIVE | ? ? ? ?|+--------------------------------------+---------------------------------+--------+--------+[neelumadhu at localhost devstack]$?\n[neelumadhu at localhost devstack]$ nova boot --flavor 2 --image 0af91b22-5306-4c97-8761-3800f9029907 test44+--------------------------------------+----------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+----------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| scheduling ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| building ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| adminPass ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SUFRq8WmQy3p ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? || image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) || key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || progress ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | BUILD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:32Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+----------------------------------------------------------------+\n\n[neelumadhu at localhost devstack]$ nova show 16e847eb-7f51-48d5-a8b8-cafb99a12605+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| fault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 49, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 35, in __run_method ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? return getattr(self.instance, __name)(*args, **kwargs) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/query.py\\\", line 34, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/rpcapi.py\\\", line 112, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec=request_spec, filter_properties=filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\\\", line 152, in call ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=self.retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py\\\", line 90, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? timeout=timeout, retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 408, in send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 399, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? raise result ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| \", \"created\": \"2014-11-30T10:58:20Z\"} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | d084bb735e188f6a0d20e6485ba7347c6d9cea4ceae2f9763af00b09 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| private network ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:58:19Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+[neelumadhu at localhost devstack]$?\n\n\n[neelumadhu at localhost devstack]$ nova host-list+-----------------------+-------------+----------+| host_name ? ? ? ? ? ? | service ? ? | zone ? ? |+-----------------------+-------------+----------+| localhost.localdomain | conductor ? | internal || localhost.localdomain | cert ? ? ? ?| internal || localhost.localdomain | compute ? ? | nova ? ? || localhost.localdomain | scheduler ? | internal || localhost.localdomain | consoleauth | internal || compute1 ? ? ? ? ? ? ?| network ? ? | internal || compute1 ? ? ? ? ? ? ?| compute ? ? | nova ? ? |+-----------------------+-------------+----------+[neelumadhu at localhost devstack]$ nova service-list+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| Id | Binary ? ? ? ? ? | Host ? ? ? ? ? ? ? ? ?| Zone ? ? | Status ?| State | Updated_at ? ? ? ? ? ? ? ? | Disabled Reason |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| 1 ?| nova-conductor ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 2 ?| nova-cert ? ? ? ?| localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:02:59.000000 | - ? ? ? ? ? ? ? || 3 ?| nova-compute ? ? | localhost.localdomain | nova ? ? | enabled | down ?| - ? ? ? ? ? ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? || 4 ?| nova-scheduler ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 5 ?| nova-consoleauth | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 6 ?| nova-network ? ? | compute1 ? ? ? ? ? ? ?| internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 7 ?| nova-compute ? ? | compute1 ? ? ? ? ? ? ?| nova ? ? | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 06:03:26.915 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29950) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 06:03:26.955 DEBUG oslo.db.api [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29950) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:03:27.400 DEBUG oslo.db.sqlalchemy.session [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29950) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:192014-11-30 06:03:27.669 DEBUG nova.servicegroup.drivers.db [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 1360.669212 from (pid=29950) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26[neelumadhu at localhost devstack]$ nova-manage host list\nhost ? ? ? ? ? ? ? ? ? ?  zone ? ? ? ? ??2014-11-30 06:04:08.471 DEBUG oslo.db.api [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29971) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:04:08.875 DEBUG oslo.db.sqlalchemy.session [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29971) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509localhost.localdomain ? ? internal ? ? ??compute1 ? ? ? ? ? ? ? ?  internal ? ? ??[neelumadhu at localhost devstack]$?[neelumadhu at localhost devstack]$?\n\n\n----------------log ends\nNeelu\n\n    \n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? ?: openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n-- \n--Regards,Geo Varghese\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141201/b1d7a487/attachment.html>\n\n','<CADB-E-vZGZ04Aj-Dyg8UJcUV-ByNWAP3Nh=oi6nrYjwXGb49Dg@mail.gmail.com>',NULL),('<1575196809.52.1381558352323.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-12 06:12:32',0,'2013-10-12 06:12:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #37','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 1238 lines...]\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.00\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_copy_to_file.TestCopyToFile.test_copy_from_http_nonexistent\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_copy_to_file.py\",> line 251, in test_copy_from_http_nonexistent\n    self._do_test_copy_from_http(False)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_copy_to_file.py\",> line 205, in _do_test_copy_from_http\n    self.assertEqual(response.status, 201, content)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 500 != 201: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/wsgi.py\",> line 389, in handle_one_response\n    result = self.application(self.environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 362, in __call__\n    response = req.get_response(self.application)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1296, in send\n    application, catch_exc_info=False)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1260, in call_application\n    app_iter = application(self.environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 362, in __call__\n    response = req.get_response(self.application)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1296, in send\n    application, catch_exc_info=False)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/request.py\",> line 1260, in call_application\n    app_iter = application(self.environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/paste/urlmap.py\",> line 203, in __call__\n    return app(environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 144, in __call__\n    return resp(environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/routes/middleware.py\",> line 131, in __call__\n    response = self.app(environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 144, in __call__\n    return resp(environ, start_response)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 130, in __call__\n    resp = self.call_func(req, *args, **self.kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/webob/dec.py\",> line 195, in call_func\n    return self.func(req, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 572, in __call__\n    request, **action_args)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/wsgi.py\",> line 589, in dispatch\n    return method(*args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/utils.py\",> line 413, in wrapped\n    return func(self, req, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/api/v1/images.py\",> line 687, in create\n    image_meta = self._reserve(req, image_meta)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/api/v1/images.py\",> line 367, in _reserve\n    image_meta = registry.add_image_metadata(req.context, image_meta)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/__init__.py\",> line 166, in add_image_metadata\n    return c.add_image(image_meta)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/client.py\",> line 142, in add_image\n    res = self.do_request(\"POST\", \"/images\", body=body, headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/registry/client.py\",> line 90, in do_request\n    **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 377, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/common/client.py\",> line 541, in _do_request\n    raise exception.ClientConnectionError(e)\nClientConnectionError: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.67 secs:\n    26.45    TestScrubber.test_scrubber_app\n    20.89    TestScrubber.test_delayed_delete\n    14.90    TestGlanceControl.test_reload\n    14.83    TestRootApi.test_version_configurations\n    14.60    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 648.312s\n\nFAILED (SKIP=42, failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.14.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.37\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.4.0\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.UeNTS0Gu5j\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/37/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-11/37\n[SCP] Copying console log.\n\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1576132298.453.1367129510655.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:11:50',0,'2013-04-28 06:11:50',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #209','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/209/>\n\n\n\n','<1939498359.370.1367042676771.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<157614606.115.1365833326029.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-13 06:08:45',0,'2013-04-13 06:08:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #3','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/3/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-13 06:08:42    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-13 06:08:42,072 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-13 06:08:42,073 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-13 06:08:42,074 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,075 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,076 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-13 06:08:42,076 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-13 06:08:42,077 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-13 06:08:42  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-13 06:08:42,078 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-13 06:08:42    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-13 06:08:42,079 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,084 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.084642\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.084642\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42,086 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,086 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,087 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,089 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42,090 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.089199\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.089199\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42,091 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,092 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,093 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-13 06:08:42,093 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,094 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,096 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42,097 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.096255\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.096255\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42,098 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,099 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,100 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-13 06:08:42,101 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,101 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,103 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42,104 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.103390\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.103390\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42,105 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,106 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,107 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-13 06:08:42,108 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,108 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,110 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-13 06:08:42,112 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-13 06:08:42,113 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.112183\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-13T06:08:42.112183\', resource_metadata={}) from 0 transformer\n2013-04-13 06:08:42,114 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,115 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42,116 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-13 06:08:42,117 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-13 06:08:42,117 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-13 06:08:42    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.779s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.3\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a45.g4bf4390\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a305.g4d5267b\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.InjtDlaCOU\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/3\n[SCP] Copying console log.\n\n\n','<1571434510.94.1365746787748.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<157695053.18.1377067648390.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-21 06:47:28',0,'2013-08-21 06:47:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #12','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/12/>\n\n------------------------------------------\n[...truncated 19121 lines...]\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_container_object_without_using_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_object_with_another_user_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_create_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_metadata[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_object_without_using_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_with_another_user_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_version.ContainerTest.test_versioned_container[smoke] ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[smoke] ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 824 tests in 1505.783s\n\nOK (SKIP=73)\nfull runtests: commands[1] | nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\nWARNING:test command found but not installed in testenv\n  cmd: /usr/local/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/full\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... SKIP: version is empty, bug 1138844\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 45, in test_admin_catalog_list\n    self.assertTrue(svc[\'__label\'].startswith(\'Service:\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-21 06:44:39,174 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   catalog \'\n2013-08-21 06:44:39,597 Invalid line between tables: Service: compute\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 93, in test_admin_help\n    self.assertTrue(lines[0].startswith(\'usage: keystone\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-21 06:44:41,519 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   help \'\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-cli.xml\n----------------------------------------------------------------------\nRan 54 tests in 32.985s\n\nFAILED (SKIP=4, failures=2)\nERROR: InvocationError: \'/usr/local/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\'\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-144680-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-144680.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-144680/12/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1687203806.13.1376981046983.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1577199.cspKghYEmm@horus>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-28 21:14:30',3600,'2013-10-28 20:14:30',NULL,'[Openstack] Can\'t connect to RabbitMQ','Am Montag, 28. Oktober 2013, 12:04:02 schrieb Razique Mahroua:\n> hey\n> is ?controller? a hostame all ur servers can resolve?\n\nYes, set in /etc/hosts.\n\nRegards,\nFlorian\n\n> \n> - Razique\n> \n> On Oct 28, 2013, at 11:40, Florian Lindner <mailinglists at xgm.de> wrote:\n> > Hello,\n> > \n> > I\'ve installed OpenStack on a Ubuntu 12.04 VM according to the install\n> > guide. It worked fine until I created the compute node on a second VM and\n> > tried to set up nova networking:\n> > \n> > http://docs.openstack.org/havana/install-guide/install/apt/content/nova-ne\n> > twork.html\n> > \n> > # nova network-create vmnet --fixed-range-v4=10.0.0.0/24 --bridge-\n> > interface=br100 --multi-host=T\n> > \n> > just does nothing until canceled. I tried on the controller and compute1\n> > node.\n> > \n> > nova-api.log shows:\n> > \n> > ERROR nova.openstack.common.rpc.common AMQP server on controller:5672 is\n> > unreachable: Socket closed. Trying again in 1 seconds.\n> > INFO nova.openstack.common.rpc.common Reconnecting to AMQP server on\n> > controller:5672\n> > \n> > controller:~# netstat -lpn | grep beam\n> > tcp        0      0 0.0.0.0:36595           0.0.0.0:*               LISTEN\n> > 1045/beam\n> > tcp6       0      0 :::5672                 :::*                    LISTEN\n> > 1045/beam\n> > \n> > It listens on this port, but IPv6. IMO on linux listing on an IPv6 port\n> > also means listening on the same v4 port.\n> > \n> > What\'s wrong with the installation?\n> > \n> > Thanks a lot!\n> > \n> > Florian\n> > \n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n','<A4EDC8AD-0009-4055-97EA-0958694406E8@gmail.com>',NULL),('<1577477203.1973831421687030904.JavaMail.nobody@rsj2rmd003.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2015-01-19 17:03:50',0,'2015-01-19 17:03:50',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting\n January 28, 2015 Noon Pacific','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting January 28, 2015 Noon Pacific\nHost: Alan Clark\nDate: Wednesday, January 28, 2015\nTime: 12:00 pm, Pacific Standard Time (San Francisco, GMT-08:00)\nSession number: 924 559 806\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=tf8dac82330b876022a1dabfb372ca5eb\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=td1173e8dae8f6dc055859304c18b49e9\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb282c75f876eec6dc65f873c9c7a0353\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=322986372&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 924 559 806\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20150119/160825a1/attachment.html>\n\n',NULL,NULL),('<1577487162.48.1386741890883.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:04:50',0,'2013-12-11 06:04:50',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-docs-grizzly #4','See <https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/4/>\n\n------------------------------------------\n[...truncated 209 lines...]\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_configparser.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_constants.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_credentials_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_exceptions.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_faults.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_utils.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.api.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_db.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._credential_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._qos_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.credential.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.qos.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2device_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2network_plugin_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.models.virt_phy_sw_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.network_plugin.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_network_driver_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_plugin_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_snippets.rst\nGenerating doc/source/api/quantum.plugins.cisco.run_tests.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_cisco_extension.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_database.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.nexus.fake_nexus_driver.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.test_api_v2.rst\nGenerating doc/source/api/quantum.plugins.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.utils.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent_notifier_api.rst\nGenerating doc/source/api/quantum.plugins.hyperv.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.db.rst\nGenerating doc/source/api/quantum.plugins.hyperv.hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.hyperv.model.rst\nGenerating doc/source/api/quantum.plugins.hyperv.rpc_callbacks.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.agent.linuxbridge_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.config.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.constants.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.lb_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_db_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_models_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.proxy_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.run_tests.rst\nGenerating doc/source/api/quantum.plugins.midonet.config.rst\nGenerating doc/source/api/quantum.plugins.midonet.midonet_lib.rst\nGenerating doc/source/api/quantum.plugins.midonet.plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.agent.nec_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.nec.common.config.rst\nGenerating doc/source/api/quantum.plugins.nec.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nec.common.ofc_client.rst\nGenerating doc/source/api/quantum.plugins.nec.db.api.rst\nGenerating doc/source/api/quantum.plugins.nec.db.models.rst\nGenerating doc/source/api/quantum.plugins.nec.db.nec_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.pfc.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.trema.rst\nGenerating doc/source/api/quantum.plugins.nec.extensions.packetfilter.rst\nGenerating doc/source/api/quantum.plugins.nec.nec_plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_driver_base.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_manager.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.NvpApiClient.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.QuantumPlugin.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.common.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.check_nvp_config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.metadata_access.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.securitygroups.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_networkgw.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_qos.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_models.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_networkgw_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_qos_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_cluster.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_plugin_version.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvplib.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.agent.ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.config.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.constants.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_db_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_models_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plugin_ver.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_nos_snippets.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.rest_connection.rst\nGenerating doc/source/api/quantum.plugins.ryu.agent.ryu_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.ryu.common.config.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.api_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.models_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.ryu_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.api.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.manager.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.constants.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.cfg.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.namespace_driver.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.plugin.rst\nGenerating doc/source/api/quantum.plugins.services.service_base.rst\nGenerating doc/source/api/quantum.policy.rst\nGenerating doc/source/api/quantum.quantum_plugin_base_v2.rst\nGenerating doc/source/api/quantum.quota.rst\nGenerating doc/source/api/quantum.rootwrap.filters.rst\nGenerating doc/source/api/quantum.rootwrap.wrapper.rst\nGenerating doc/source/api/quantum.scheduler.dhcp_agent_scheduler.rst\nGenerating doc/source/api/quantum.scheduler.l3_agent_scheduler.rst\nGenerating doc/source/api/quantum.service.rst\nGenerating doc/source/api/quantum.tests.base.rst\nGenerating doc/source/api/quantum.tests.unit._test_extension_portbindings.rst\nGenerating doc/source/api/quantum.tests.unit._test_rootwrap_exec.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_restproxy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_router_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_vlan.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_network_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_nexus_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.database_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.db.loadbalancer.test_db_loadbalancer.rst\nGenerating doc/source/api/quantum.tests.unit.dummy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.extension_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extendedattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extensionattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.foxinsocks.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.v2attributes.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_db.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_linuxbridge_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.fake_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_basic.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_metaplugin.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_lib.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.stub_ofc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_agent.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_ofc_manager.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_pfc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_trema_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.fake_nvpapiclient.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_networkgw.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nicira_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request_eventlet.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvplib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_openvswitch_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_db.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_lib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_tunnel.rst\nGenerating doc/source/api/quantum.tests.unit.plumgrid.test_plumgrid_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.fake_ryu.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_agent.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_db.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_api.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_init.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_manager.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_cfg.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_namespace_driver.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.test_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ext_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_linux_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_netns_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ovs_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2_resource.rst\nGenerating doc/source/api/quantum.tests.unit.test_attributes.rst\nGenerating doc/source/api/quantum.tests.unit.test_auth.rst\nGenerating doc/source/api/quantum.tests.unit.test_common_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_migration.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_rpc_base.rst\nGenerating doc/source/api/quantum.tests.unit.test_debug_commands.rst\nGenerating doc/source/api/quantum.tests.unit.test_dhcp_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extended_attribute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extraroute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_portsecurity.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.test_extensions.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_firewall.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_daemon.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_dhcp.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_external_process.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_interface.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_ip_lib.rst\nGenerating doc/source/api/quantum.tests.unit.test_loadbalancer_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_namespace_proxy.rst\nGenerating doc/source/api/quantum.tests.unit.test_policy.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_context.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_quota_ext.rst\nGenerating doc/source/api/quantum.tests.unit.test_rootwrap.rst\nGenerating doc/source/api/quantum.tests.unit.test_routerserviceinsertion.rst\nGenerating doc/source/api/quantum.tests.unit.test_security_groups_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_servicetype.rst\nGenerating doc/source/api/quantum.tests.unit.test_wsgi.rst\nGenerating doc/source/api/quantum.tests.unit.testlib_api.rst\nGenerating doc/source/api/quantum.version.rst\nGenerating doc/source/api/quantum.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-grizzly/precise14/4\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1578415384.34568214.1412714690880.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-07 16:44:50',-14400,'2014-10-07 20:44:50',NULL,'[openstack-dev] ETSI NFV gap analysis [NFV]','----- Original Message -----\n> From: \"Alan Kavanagh\" <alan.kavanagh at ericsson.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> \n> I believe pointing it to the NFV Wiki would be good and that way it can be\n> discussed during one of the weekly meetings run by Steven et.al and match\n> the list to what is being requested to what is identified in the wiki list\n> as a good starting point.\n> /Alan\n\nHi all,\n\nI\'ve uploaded the document here:\n\n    https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf\n\nMany items are tracked (and in fact linked inline in the document itself) in the list that we have already compiled on the wiki, but there are certainly gaps over and above those as you work your way down the list.\n\nThanks,\n\nSteve\n\n> -----Original Message-----\n> From: Sylvain Bauza [mailto:sbauza at redhat.com]\n> Sent: October-06-14 9:19 AM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] ETSI NFV gap analysis [NFV]\n> \n> \n> Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a ?crit :\n> > Team,\n> >\n> > Following my action item from last week  IRC.\n> > It seems that the document is ready for submission by ETSI NFV team.\n> > It was written in a liaison form as this is how they are used to operate.\n> > They are wondering who should they send it to...\n> > IMHO it seems a good idea that the NFV sub group will \"receive\" it in\n> > behalf of the community.\n> >\n> > Thoughts?\n> >\n> > Itai\n> \n> I don\'t know the legal conditions of the publication of this document, but I\n> would assume it would be worth of interest within the whole OpenStack\n> community so anyone could see what\'s missing and contribute to it.\n> \n> \n> At least pointing the document to the NFV wiki page sounds important,\n> provided this communication can be done this way (ie. no opt-in list for\n> people looking at the doc)\n> \n> -Sylvain\n> \n> >\n> > Sent from my iPhone\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<C977B257ADF8814C8EB4FB66BB9D0C2E7238B0@eusaamb109.ericsson.se>',NULL),('<157921534.2.1376806758117.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-18 06:19:18',0,'2013-08-18 06:19:18',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #7','See <https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/7/>\n\n------------------------------------------\n[...truncated 3740 lines...]\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 433.67 secs:\n    156.22    KcMasterTestCase.test_admin_requires_adminness\n    144.94    Kc11TestCase.test_admin_requires_adminness\n    118.41    KcEssex3TestCase.test_admin_requires_adminness\n    7.24    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    6.85    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n----------------------------------------------------------------------\nRan 1300 tests in 902.263s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==2.0\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.7\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ErkrmpRoOq\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/7/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/centos6-5/7\n[SCP] Copying console log.\n\n\n','<1375266770.5.1376633809729.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<157C83BA-453E-4EEE-A16A-2EFD4ED6887A@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-07-23 09:40:07',7200,'2012-07-23 07:40:07',NULL,'[Openstack-docs] Open Help Conference August 10-15','Too bad it\'s a bit far for me :-(\nI hope there will be a podcast afterwards\n\n\nNuage & Co - Razique Mahroua \nrazique.mahroua at gmail.com\n\n\n\nLe 23 juil. 2012 ? 03:51, Ying Chun Guo a ?crit :\n\n> Very useful conference but I\'m not able to join it.\n> Hope to see some on-line materials.\n> \n> Regards\n> Ying Chun Guo (Daisy)\n> \n> Anne Gentle <anne at openstack.org> wrote on 07/22/2012 03:32:59 AM:\n> \n> > Anne Gentle <anne at openstack.org> \n> > 07/22/2012 03:32 AM\n> > \n> > To\n> > \n> > openstack-docs at lists.openstack.org, \n> > \n> > cc\n> > \n> > Subject\n> > \n> > [Openstack-docs] Open Help Conference August 10-15\n> > \n> > Hi all -\n> > \n> > I wanted to be sure you know about the Open Help Conference hosted by\n> > GNOME doc veteran Shaun McCance. I\'ll be there and would love for\n> > other Stackers to attend as well, though I apologize for the late notice.\n> > \n> > You can register online and learn more here:\n> > http://openhelpconference.com/\n> > \n> > Thanks,\n> > Anne\n> > \n> > _______________________________________________\n> > Openstack-docs mailing list\n> > Openstack-docs at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20120723/dc9e22c1/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: NUAGECO-LOGO-Fblan_petit.jpg\nType: image/jpeg\nSize: 10122 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20120723/dc9e22c1/attachment.jpg>\n\n','<OF61E2F072.6FD95996-ON48257A44.0009500C-48257A44.000A363E@cn.ibm.com>',NULL),('<1580218993.937525.1371490285162.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-17 10:31:25',-25200,'2013-06-17 17:31:25',NULL,'[openstack-dev]  [vmware] VMwareAPI sub-team status update','\nGreetings stackers!\n\nWherever you are I hope you\'ve had/are having a lovely Monday. I\'d like to see discussion this week on the Blueprint \"Enhance vmware Hyper vm disk usage\" if possible. See: https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage who, when, and where shall we discuss this. #openstack-vmware is always open.\n\nopen reviews: 10\nclosed reviews: 5\n\n== Accepted! (Congrats) ===\nThanks to the core reviewers for accepting these:\n\nhttps://review.openstack.org/#/c/29552/\nhttps://review.openstack.org/#/c/30036/ <- looks like this and 31593 were in conflict and this patch lost the race (I\'m working on it)\nhttps://review.openstack.org/#/c/31593/\n\n== More work needed ===\nThese looked like they were ready to go but are currently blocked:\nhttps://review.openstack.org/#/c/31593/\nhttps://review.openstack.org/#/c/29453/\n\nReviews needing *vmware* expert attention:\nhttps://review.openstack.org/#/c/29396/\nhttps://review.openstack.org/#/c/30628/ <- in particular, we need a traversal spec for this\nhttps://review.openstack.org/#/c/30282/ <- I think this will also benefit from some API pointers\n\n... these have *not* been looked at by enough non-core reviewers with VMware\nAPI expertise. We need folks listed on this email\'s \"CC\" block to come and\nspend some time on these. If you are doing VMware related work and need\nreviews, reach out to me, and I\'ll try to coordinate some help for you.\n\nIs your review not listed?\n * add me as a reviewer http://i.imgur.com/XLINkt3.png\n \nIs your review not listed *ready* for core?\n * get more +1 from the VMware API maintainers and trusted VMware API experts\nin the OpenStack community!\n\n== Blueprints ==\nsee: https://blueprints.launchpad.net/openstack?searchtext=vmware\nOf the 10 proposed blueprints, only 3 have commitments. Only 1 has \"good\nprogress\" ... these 3 BP are all tagged for completion by July 18th.\n\nAt our current rate of progress, I am concerned about our rate of progress with reviews and that\'s why I\'m organizing this email. Let\'s try and stay on top of these and find more people who can contribute VMware API expertise into the OpenStack code-base! \n\nOkay. Happy programming! I\'ll post again on Friday with a recap on the week. Remember to attend the VMwareAPI sub-team meeting this week where we discuss blueprints & blocker-bugs. If you can\'t attend, that\'s okay as long as you have someone write on the blueprint. For example: https://blueprints.launchpad.net/nova/+spec/v3-api-extension-framework is a good example of a documented, discussed, and acted upon blueprint. Let\'s try and emulate that.\n\nNext Meeting:\nhttps://wiki.openstack.org/wiki/Meetings/VMwareAPI\nhttp://www.timeanddate.com/worldclock/fixedtime.html?iso=20130619T1700\nheld in #openstack-meeting\n\n# Shawn Hartsock, VMware\'s Nova Compute driver maintainer\n\n\n','<1801993628.19204418.1371224985135.JavaMail.root@vmware.com>',NULL),('<1581094824.3780200.1373635065415.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-12 09:17:45',-14400,'2013-07-12 13:17:45',NULL,'[Openstack-docs] Linking to external install guides','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n\n>8-------->8-------->8-------->8-------->8-------->8\n> On Jul 11, 2013, at 9:16 AM, Shaun McCance <shaunm at gnome.org> wrote:\n> \n> > On Wed, 2013-07-10 at 15:46 +1000, Tom Fifield wrote:\n> >> On 10/07/13 15:40, Andreas Jaeger wrote:\n> >>> On 07/10/2013 02:34 AM, Tom Fifield wrote:\n> >>>> I\'ll take a bullish line, which may not necessarily be achievable:\n> >>>> \n> >>>> \"\"\"\n> >>>> On the day that the press release for Havana is sent out, we need -by\n> >>>> hook or by crook!- to have installation instructions for RHEL and\n> >>>> Ubuntu, and ideally SUSE and Debian too.\n> >>>> \"\"\"\n> >>> \n> \n> I\'d like as many helpers on this as possible and focus on this effort.\n> Andreas it sounds like you want to make this happen for SUSE.\n> \n> Do we stop single sourcing with conditions for each op sys?\n\nI think that single sourcing using conditionals is working OK and I\'d prefer to see it stay, albeit with the installation materials consolidated into one source guide instead of conditionalizing two source guides. That said what alternative would you propose?\n\n> >>> What kind of instructions are you looking at? The \"Basic installation\"\n> >>> ones, the current \"installation guides\" - or both?\n> >>> \n> \n> I think we want one guide that starts simple and goes to complex with\n> multiple example architectures. Note this is the opposite of what we have\n> been doing so far.\n\n+1, I think this approach makes a lot of sense even with the core projects where users may wish to pick and choose some of them let alone if it ever becomes possible/necessary to add the integrated projects.\n\n> >>> Andreas\n> >> \n> >> Thanks for the reply!!\n> >> \n> >> I think the answer is: \"something\" ;)\n> >> \n> >> My personal impression is:\n> >> * the basic install guide is too basic right now\n> >> * the install guides are too heavy\n> >> \n> \n> Heh. I think the basic is too complex because of the networking. But your\n> eyes are fresh.\n\nNetworking setup, while complicated, is also pretty core to user expectations of a working environment. I guess the network node could be collapsed onto the controller for a basic setup (I suspect that argument has probably been had before  :)) but I\'m not sure that significantly simplifies things.\n\n>8-------->8-------->8-------->8-------->8-------->8\n> > And I believe very strongly that your docs should be ready on release\n> > day. They\'re part of your fanfare, and should be linked to from your\n> > marketing materials.\n> > \n> \n> I\'m scared of this but we have to scope it for install docs at least, the\n> board, technical committee, and especially the users expect it.\n> \n> I don\'t think all docs can be ready at release, the scope is too wide. There\n> are 30+  docs on an Openstack.org domains. My current thinking is that we\n> will have a set of release docs (install and config only) and a set of\n> library books that are not manuals tied to a release but merely guides. We\n> may need to publish elsewhere to make this line strongly drawn, but I\'m not\n> sure we are ready to do that type of curation.\n> \n> This distinction is especially important as we must prove we can deliver docs\n> at release time.\n\nSo here\'s a related question, what determines whether a given document is ready for the release? Both in terms of what has been done in the past and whether or not we need/want to define a criteria that we\'re aiming for?\n\nThanks,\n\nSteve\n\n\n','<CA8014D4-CABE-4AD9-B782-DF3AB223499D@justwriteclick.com>',NULL),('<1581667003.7.1374213932629.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-19 06:05:32',0,'2013-07-19 06:05:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #291','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/291/>\n\n------------------------------------------\n[...truncated 2595 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.123.g32f38fe to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.123.g32f38fe\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.123.g32f38fe\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.8.g2f84a4e to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/rabbitmq/rabbit at devstack-1374206464-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/rabbitmq/rabbit at devstack-1374206464.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/291/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<548521098.1.1374127495486.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1583079047.1.1381472978133.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-11 06:29:37',0,'2013-10-11 06:29:37',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #35','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/35/>\n\n------------------------------------------\n[...truncated 21582 lines...]\ntempest.api.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[gate,smoke] ... ok\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke]\ntempest.api.object_storage.test_object_version.ContainerTest.test_versioned_container[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id[gate] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[compute,gate,smoke,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment[compute,gate,stress] ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\nInitialized empty Git repository in /tmp/tempest-unit00Ss6M/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitP_4oIr/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          209.805\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  176.271\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  68.975\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     44.390\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        34.398\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         33.757\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        28.743\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         26.745\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        26.396\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     26.055\n\n----------------------------------------------------------------------\nRan 1357 tests in 1278.340s\n\nOK (skipped=65)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-571828-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-571828.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-571828/35/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<944234064.45.1381386516351.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1584076858.7904234.1382600931729.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-24 03:48:51',-14400,'2013-10-24 07:48:51',NULL,'[Openstack] Port status after stoping veth pair','Hi,\n\nI found out that after I\'ve shut down the veth pair between a linux bridge and the integration bridge for a working VM (ifconfig qvb816b1a35-5a down,ifconfig qvo816b1a35-5a down), and even shut down the bridge (ifconfig qbr816b1a35-5a down), the neutron port show still show it as an ACTIVE port:\n+-----------------------+--------------------------------------------------------------------------------------+\n| Field                 | Value                                                                                |\n+-----------------------+--------------------------------------------------------------------------------------+\n| admin_state_up        | True                                                                                 |\n| allowed_address_pairs |                                                                                      |\n| binding:capabilities  | {\"port_filter\": true}                                                                |\n| binding:host_id       | rose12.qa.lab.tlv.redhat.com                                                         |\n| binding:vif_type      | ovs                                                                                  |\n| device_id             | e44976a5-2b8e-4640-a8b3-9608fa80001a                                                 |\n| device_owner          | compute:None                                                                         |\n| extra_dhcp_opts       |                                                                                      |\n| fixed_ips             | {\"subnet_id\": \"c83f4896-f8b0-4760-a3b9-ef31972c6c12\", \"ip_address\": \"192.168.238.2\"} |\n| id                    | 816b1a35-5a75-48f9-8c0d-45f3c92356e5                                                 |\n| mac_address           | fa:16:3e:ba:cd:09                                                                    |\n| name                  |                                                                                      |\n| network_id            | 89b65a31-c1a1-42a5-8450-70a242a288a3                                                 |\n| security_groups       | 0b5c7c9c-418e-4662-b895-adf244c84680                                                 |\n| status                | ACTIVE                                                                               |\n| tenant_id             | fe09679160d342dbb4a43b9ff541f70e                                                     |\n+-----------------------+--------------------------------------------------------------------------------------+\nIs this suppose to happen? Or is this a bug?\n\nRegards,\nRoey\n\n\n',NULL,NULL),('<158416308.2478016.1385476165136.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-26 15:29:25',3600,'2013-11-26 14:29:25',NULL,'[openstack-dev] [horizon] Javascript development improvement','I made a little POC about Nodejs integration with its task runner Grunt https://review.openstack.org/58525\n\nIt is easy to configure and override, we have more flexibility with this solution.\n\nRunning Selenium which will run Firefox which will launch an html page with js embedded seems really overkill. It provides a lot of complexity and we have to manipulate the file launched by Firefox if we want a little modification or just test a single file. \nCurrently all files are tested together with all the tests without any control. Imagine testing the backend this way, launching all the tests just for looking at your modifications. No command line support in development implies a lack of automatisation, and a lack of automatisation lead to a lose of time. \n\nIn the other hand, grunt allows us to launch tests on a specific file or all libraries. We can make specific tasks really fast with a better readability. I encourage you to think of the further developments and to think of all the pro and cons of these solutions. Just test it and look at the documentation with all the plugins (unit testing, less compilation, jshint checking, angular testing), this is just configuration and no development, with a great community which will allow us to focus on the Horizon development and not wasting times on external tools.\n\nHorizon will need more and more development on the client side, currently javascript is a mess and we need great tools to improve our work. Developing our tools will take time and during this time developers will continue developing with no tools to automate or check their work.\n\nMaxime\n\n----- Original Message -----\nFrom: \"Imre Farkas\" <ifarkas at redhat.com>\nTo: openstack-dev at lists.openstack.org\nSent: Tuesday, November 26, 2013 1:42:26 PM\nSubject: Re: [openstack-dev] [horizon] Javascript development improvement\n\nOn 11/22/2013 06:13 PM, Julie Pichon wrote:\n> \"Imre Farkas\" <ifarkas at redhat.com> wrote:\n>> On 11/22/2013 02:49 PM, Maxime Vidori wrote:\n>>>> It seems a bit crazy to me to introduce NodeJS as a dependency just for\n>>>> the sake of an easy way to run jslint. There are other options\n>>>> available that run without NodeJS as a dependency.\n>>>\n>>> Sadly, the only solutions which try to implement jslint in pure python are\n>>> in alpha or abandoned. If you have a python library which has the same\n>>> quality as jslint (which is written by Douglas Crockford himself), I will\n>>> be glad to take a look at it.\n>>\n>> There\'s a jslint fork called jshint which is able to run in the browser\n>> without any node.js dependency.\n>>\n>> I created a POC patch [1] long time ago to demonstrate its capabilities.\n>> It\'s integrated with qunit and runs automatically with the horizon test\n>> suite.\n>\n> Thanks Imre, this is interesting. Would you mind restoring the patch? If\n> you don\'t have time to work on it please indicate so (I don\'t think it\'s\n> possible to pick up a patch if the status is \'Abandoned\') and someone else\n> can look into the test failures.\n\nJulie, Matthias,\nI restored the patch, rebased, fixed the tests, added the test files as \nRadomir suggested and removed the .jshintrc file.\n\nThe original patch was WIP and I left the failing tests intentionally, \nso that it was easier to compare the two solutions (node.js vs pure \nqunit). But as I wrote, it\'s cleaned up by now and only contains the latter.\n\nImre\n\n>\n>> The patch also contains a .jshintrc file for the node.js package but you\n>> can remove it since it\'s not used by the qunit+jshint test at all.\n>\n> Sounds good.\n>\n> Julie\n>\n>> Imre\n>>\n>> [1] https://review.openstack.org/#/c/41087/\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<52949732.7030507@redhat.com>',NULL),('<1584357795.5710706.1390401079575.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 09:31:19',-18000,'2014-01-22 14:31:19',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology\n	Revival	#1	-	Roles','> > On 2014/22/01 10:00, Jaromir Coufal wrote:\n> > >\n> > >\n> > > On 2014/22/01 00:56, Tzu-Mainn Chen wrote:\n> > >> Hiya - Resource is actually a Heat term that corresponds to what we\'re\n> > >> deploying within\n> > >> the Overcloud Stack - i.e., if we specify that we want an Overcloud\n> > >> with 1 Controller\n> > >> and 3 Compute, Heat will create a Stack that contains 1 Controller and\n> > >> 3 Compute\n> > >> Resources.\n> > >\n> > > Then a quick question - why do we design deployment by\n> > > increasing/decreasing number of *instances* instead of resources?\n> > >\n> > > -- Jarda\n> > \n> > And one more thing - Resource is very broad term as well as Role is. The\n> > only difference is that Heat accepted \'Resource\' as specific term for\n> > them (you see? they used broad term for their concept). So I am asking\n> > myself, where is difference between generic term Resource and Role? Why\n> > cannot we accept Roles? It\'s short, well describing...\n> \n> True, but Heat was creating something new, while it seems like (to me),\n> our intention is mostly to consume other Openstack APIs and expose the\n> results in the UI.  If I call a Heat API which returns something that\n> they call a Resource, I think it\'s confusing to developers to rename\n> that.\n> \n> > I am leaning towards Role. We can be more specific with adding some\n> > extra word, e.g.:\n> > * Node Role\n> > * Deployment Role\n> > ... and if we are in the context of undercloud, people can shorten it to\n> > just Roles. But \'Resource Category\' seems to me that it doesn\'t solve\n> > anything.\n> \n> I\'d be okay with Resource Role!\n\nActually - didn\'t someone raise the objection that Role was a defined term within\nKeystone and potentially a source of confusion?\n\nMainn\n\n> > -- Jarda\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<2011329422.5705126.1390400094089.JavaMail.root@redhat.com>',NULL),('<1584489017.10.1376460801036.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-14 06:13:21',0,'2013-08-14 06:13:21',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-cinder-python27-stable-grizzly #4','See <https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/4/changes>\n\n\n\n','<572828569.5.1376287781548.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1585135895.1782996.1389069638246.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-07 05:40:38',3600,'2014-01-07 04:40:38',NULL,'[openstack-dev] [nova] unittests are failing after change I5e4cb4a8','Hello everyone,\n\nI\'m just wondering, is there anyone else who is affected by this bug: https://bugs.launchpad.net/nova/+bug/1266534 ?\nIt looks to me that everyone should be affected by it (after change https://review.openstack.org/#/c/61310 has been merged),\nbut I also see many tests in Jenkins which are passing.\n\nI\'m not sure if I am missing anything.\n\nThanks,\nVladik\n\n\n','<52CB6CB1.5090306@dague.net>',NULL),('<1585570178.1729864.1377074886855.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-21 10:48:06',7200,'2013-08-21 08:48:06',NULL,'[openstack-dev] oauth and keystone','Hello,\n\nYou have to add the oAuth filter (oauth_extension) in your pipeline, in /etc/keystone/keystone.conf or /etc/keystone/keystone-paste.ini:\n\n[pipeline:api_v3]\npipeline = access_log sizelimit url_normalize token_auth admin_token_auth xml_body json_body oauth_extension ec2_extension s3_extension service_v3\n\nand restart keystone.\n\nMatthieu Huin \n\nmhu at enovance.com\n\n----- Original Message -----\n| From: \"Yongsheng Gong\" <gongysh at unitedstack.com>\n| To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n| Sent: Wednesday, August 21, 2013 6:22:09 AM\n| Subject: [openstack-dev] oauth and keystone\n| \n| Hi,\n| \n| I have seen the code about oauth in the keystone but I cannot find the\n| document about how to setup keystone and other openstack services to enable\n| oauth.\n| \n| Can anyone tell me how to setup an env like this?\n| \n| Thanks\n| Yong Sheng Gong\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n\n\n','<CAEM-rjRtfdk1ucxDYMbHj7TAtdQ2ywvdpta4cXDkXfiG8qNvvA@mail.gmail.com>',NULL),('<1586229915.14.1386918368683.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 07:06:08',0,'2013-12-13 07:06:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-postgres-full-havana #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-postgres-full-havana/5/>\n\n\n\n',NULL,NULL),('<1586354690.5761654.1390405773732.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:49:33',-18000,'2014-01-22 15:49:33',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival\n	#1	-	Roles','> On Jan 22, 2014, at 4:02 AM, Jaromir Coufal <jcoufal at redhat.com> wrote:\n> \n> > \n> > \n> > On 2014/22/01 00:56, Tzu-Mainn Chen wrote:\n> >> Hiya - Resource is actually a Heat term that corresponds to what we\'re\n> >> deploying within\n> >> the Overcloud Stack - i.e., if we specify that we want an Overcloud with 1\n> >> Controller\n> >> and 3 Compute, Heat will create a Stack that contains 1 Controller and 3\n> >> Compute\n> >> Resources.\n> > \n> > Then a quick question - why do we design deployment by\n> > increasing/decreasing number of *instances* instead of resources?\n> \n> Yeah, great question Jarda. When I test out the ?Stacks? functionality in\n> Horizon the user doesn?t create a Stack that spins up resources, it spins up\n> instances. Maybe there is a difference around the terms being used behind\n> the scenes and in Horizon?\n\nMaybe we\'re looking at different parts of the UI, but when I look at a Stack\ndetail page in Horizon, I see a tab for Resources, and not Instances.  The resource\ntable might link to an Instance, but that information is retrieved from the Resource.\n\nMainn\n\n> Liz\n> \n> > \n> > -- Jarda\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<40069DA5-BEFD-4A9F-8140-B7C03BD630F7@redhat.com>',NULL),('<1586391008.4237991.1381213868231.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-08 02:31:08',-14400,'2013-10-08 06:31:08',NULL,'[openstack-dev] [TRIPLEO] tripleo-core update october','> Hi, like most OpenStack projects we need to keep the core team up to\n> date: folk who are not regularly reviewing will lose context over\n> time, and new folk who have been reviewing regularly should be trusted\n> with -core responsibilities.\n> \n> Please see Russell\'s excellent stats:\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt\n> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt\n> \n> For joining and retaining core I look at the 90 day statistics; folk\n> who are particularly low in the 30 day stats get a heads up: it\'s not\n> a purely mechanical process :).\n> \n> As we\'ve just merged review teams with Tuskar devs, we need to allow\n> some time for everyone to get up to speed; so for folk who are core as\n> a result of the merge will be retained as core, but November I expect\n> the stats will have normalised somewhat and that special handling\n> won\'t be needed.\n> \n> IMO these are the reviewers doing enough over 90 days to meet the\n> requirements for core:\n> \n> |       lifeless **        |     349    8 140   2 199    57.6% |    2\n> (  1.0%)  |\n> |     clint-fewbar **      |     329    2  54   1 272    83.0% |    7\n> (  2.6%)  |\n> |         cmsj **          |     248    1  25   1 221    89.5% |   13\n> (  5.9%)  |\n> |        derekh **         |      88    0  28  23  37    68.2% |    6\n> ( 10.0%)  |\n> \n> Who are already core, so thats easy.\n> \n> If you are core, and not on that list, that may be because you\'re\n> coming from tuskar, which doesn\'t have 90 days of history, or you need\n> to get stuck into some more reviews :).\n> \n> Now, 30 day history - this is the heads up for folk:\n> \n> | clint-fewbar **  |     179    2  27   0 150    83.8% |    6 (  4.0%)  |\n> |     cmsj **      |     179    1  15   0 163    91.1% |   11 (  6.7%)  |\n> |   lifeless **    |     129    3  39   2  85    67.4% |    2 (  2.3%)  |\n> |    derekh **     |      41    0  11   0  30    73.2% |    0 (  0.0%)  |\n> |      slagle      |      37    0  11  26   0    70.3% |    3 ( 11.5%)  |\n> |    ghe.rivero    |      28    0   4  24   0    85.7% |    2 (  8.3%)  |\n> \n> \n> I\'m using the fairly simple metric of \'average at least one review a\n> day\' as a proxy for \'sees enough of the code and enough discussion of\n> the code to be an effective reviewer\'. James and Ghe, good stuff -\n> you\'re well on your way to core. If you\'re not in that list, please\n> treat this as a heads-up that you need to do more reviews to keep on\n> top of what\'s going on, whether so you become core, or you keep it.\n> \n> In next month\'s update I\'ll review whether to remove some folk that\n> aren\'t keeping on top of things, as it won\'t be a surprise :).\n> \n> Cheers,\n> Rob\n> \n> \n> \n> \n> \n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\nHi,\n\nI feel like I should point out that before tuskar merged with tripleo, we had some distinction between the team working on the tuskar api and the team working on the UI, with each team focusing reviews on its particular experties.  The latter team works quite closely with horizon, to the extent of spending a lot of time involved with horizon development and blueprints.  This is done so that horizon changes can be understood and utilized by tuskar-ui.\n\nFor that reason, I feel like a UI core reviewer split here might make sense. . . ?  tuskar-ui doesn\'t require as many updates as tripleo/tuskar api, but a certain level of horizon and UI expertise is definitely helpful in reviewing the UI patches.\n\nThanks,\nTzu-Mainn Chen\n\n\n','<CAJ3HoZ1+UnGC=4Vckfs5fPa=zgtDFEy8Be=R2iZ9CqSpumnhaQ@mail.gmail.com>',NULL),('<1586697448.2836624.1395854915629.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 13:28:35',-14400,'2014-03-26 17:28:35',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials to\n Keystone','\n\n> On 3/25/2014 1:50 PM, Matt Wagner wrote:\n> > This would argue to me that the easiest thing for Ceilometer might be\n> > to query us for IPMI stats, if the credential store is pluggable.\n> > \"Fetch these bare metal statistics\" doesn\'t seem too off-course for\n> > Ironic to me. The alternative is that Ceilometer and Ironic would both\n> > have to be configured for the same pluggable credential store.\n> \n> There is already a blueprint with a proposed patch here for Ironic to do\n> the querying:\n> https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer.\n\nYes, so I guess there are two fundamentally different approaches that\ncould be taken here:\n\n1. ironic controls the cadence of IPMI polling, emitting notifications\n   at whatever frequency it decides, carrying whatever level of\n   detail/formatting it deems appropriate, which are then consumed by\n   ceilometer which massages these provided data into usable samples\n\n2. ceilometer acquires the IPMI credentials either via ironic or\n   directly from keystone/barbican, before calling out over IPMI at\n   whatever cadence it wants and transforming these raw data into\n   usable samples\n\nIIUC approach #1 is envisaged by the ironic BP[1].\n\nThe advantage of approach #2 OTOH is that ceilometer is in the driving\nseat as far as cadence is concerned, and the model is far more\nconsistent with how we currently acquire data from the hypervisor layer\nand SNMP daemons.\n\nCheers,\nEoghan\n\n\n[1]  https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer\n \n> I think, for terms of credential storage (and, for that matter, metrics\n> gathering as I noted in that blueprint), it\'s very useful to have things\n> pluggable. Ironic, in particular, has many different use cases: bare\n> metal private cloud, bare metal public cloud, and triple-o. I could\n> easily see all three being different enough to call for different forms\n> of credential storage.\n\n\n','<BLU0-SMTP1852B789FA890F795B299EDDC640@phx.gbl>',NULL),('<1587570566.7549308.1374864149722.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-26 14:42:29',-14400,'2013-07-26 18:42:29',NULL,'[Openstack-docs] Intro and example installations','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> Cc: \"Shaun McCance\" <shaunm at gnome.org>, openstack-docs at lists.openstack.org\n> Sent: Friday, July 19, 2013 4:29:34 PM\n> Subject: Re: [Openstack-docs] Intro and example installations\n> \n> Another area that a decision has to be made in the opinionated installs is\n> around nova-conductor, which receives requests over RPC. It was introduced\n> in Grizzly to proxy database calls and API calls. It decouples nova-compute\n> and the database, to enable rolling upgrades. However the Security Guide\n> calls it out as too insecure to run because it cannot verify who messages\n> come from. So in the opinionated install you\'d have to discuss when to use\n> nova-conductor.\n> \n> I\'ll keep bringing up decision points until you tell me to stop! :)\n> \n> Anne\n\nWell...in the current basic install I think we are transmitting all the RPC messages in plain text (unencrypted) although password authentication is applied - certainly there doesn\'t appear to be any SSL setup for QPID. So I think there is also the question of do we wish to complicate the most basic install with setting up message security properly or leave securing the deployment to a choose your own adventure component as well?\n\nThanks,\n\nSteve\n\n\n','<CAD0KtVFZq_=QRi3HVQVz1eQ1jSLDgDqdDg0Bc9sEagn2fRb=wQ@mail.gmail.com>',NULL),('<1587689085.203.1361081852451.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-17 06:17:32',0,'2013-02-17 06:17:32',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #139','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/139/>\n\n\n\n','<961583361.191.1360995735709.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<158833116.68.1382335658505.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-21 06:07:38',0,'2013-10-21 06:07:38',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #39','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/39/>\n\n------------------------------------------\n[...truncated 14457 lines...]\n2013-10-21 06:06:06 ++ trueorfalse True False\n2013-10-21 06:06:06 ++ local default=True\n2013-10-21 06:06:06 ++ local testval=False\n2013-10-21 06:06:06 ++ [[ -z False ]]\n2013-10-21 06:06:06 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-10-21 06:06:06 ++ echo False\n2013-10-21 06:06:06 ++ return\n2013-10-21 06:06:06 + USE_SCREEN=False\n2013-10-21 06:06:06 + is_service_enabled s-container\n2013-10-21 06:06:06 + services=s-container\n2013-10-21 06:06:06 + for service in \'${services}\'\n2013-10-21 06:06:06 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,s-container, ]]\n2013-10-21 06:06:06 + return 0\n2013-10-21 06:06:06 + screen_rc s-container \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\'\n2013-10-21 06:06:06 + SCREEN_NAME=stack\n2013-10-21 06:06:06 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:06 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-21 06:06:06 + grep s-container /opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:06 ++ echo -ne \'\\015\'\n2013-10-21 06:06:06 + NL=$\'\\r\'\n2013-10-21 06:06:06 + echo \'screen -t s-container bash\'\n2013-10-21 06:06:06 + echo \'stuff \"cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\n\"\'\n2013-10-21 06:06:06 + [[ False = \\T\\r\\u\\e ]]\n2013-10-21 06:06:06 + run_process s-container \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\'\n2013-10-21 06:06:06 + local service=s-container\n2013-10-21 06:06:06 + local \'command=cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\'\n2013-10-21 06:06:06 + echo 22797\n2013-10-21 06:06:06 + _run_process s-container \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\'\n2013-10-21 06:06:06 + for type in object container account\n2013-10-21 06:06:06 + screen_it s-account \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n2013-10-21 06:06:06 + SCREEN_NAME=stack\n2013-10-21 06:06:06 + SERVICE_DIR=/opt/stack/new/status\n2013-10-21 06:06:06 + local service=s-container\n2013-10-21 06:06:06 + local \'command=cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-container-server /etc/swift/container-server/1.conf -v\'\n2013-10-21 06:06:06 + exec\n2013-10-21 06:06:06 + exec\n2013-10-21 06:06:06 ++ trueorfalse True False\n2013-10-21 06:06:06 ++ local default=True\n2013-10-21 06:06:06 ++ local testval=False\n2013-10-21 06:06:06 ++ [[ -z False ]]\n2013-10-21 06:06:06 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-10-21 06:06:06 ++ echo False\n2013-10-21 06:06:06 ++ return\n2013-10-21 06:06:06 + USE_SCREEN=False\n2013-10-21 06:06:06 + is_service_enabled s-account\n2013-10-21 06:06:06 + services=s-account\n2013-10-21 06:06:06 + for service in \'${services}\'\n2013-10-21 06:06:06 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,s-account, ]]\n2013-10-21 06:06:06 + return 0\n2013-10-21 06:06:06 + screen_rc s-account \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n2013-10-21 06:06:06 + SCREEN_NAME=stack\n2013-10-21 06:06:06 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:06 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-21 06:06:06 + grep s-account /opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:06 ++ echo -ne \'\\015\'\n2013-10-21 06:06:06 + NL=$\'\\r\'\n2013-10-21 06:06:06 + echo \'screen -t s-account bash\'\n2013-10-21 06:06:08 + echo \'stuff \"cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\n\"\'\n2013-10-21 06:06:08 + [[ False = \\T\\r\\u\\e ]]\n2013-10-21 06:06:08 + run_process s-account \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n+ exec\n+ exec\n+ [[ -n /opt/stack/new/screen-logs ]]\n+ exec\n2013-10-21 06:06:08 + local service=s-account\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n2013-10-21 06:06:08 + echo 22802\n2013-10-21 06:06:08 + is_service_enabled g-api g-reg\n2013-10-21 06:06:08 + services=\'g-api g-reg\'\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,g-api, ]]\n2013-10-21 06:06:08 + return 0\n2013-10-21 06:06:08 + echo_summary \'Starting Glance\'\n2013-10-21 06:06:08 + [[ -t 3 ]]\n2013-10-21 06:06:08 + echo -e Starting Glance\n2013-10-21 06:06:08 + start_glance\n2013-10-21 06:06:08 + screen_it g-reg \'cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + SCREEN_NAME=stack\n2013-10-21 06:06:08 + SERVICE_DIR=/opt/stack/new/status\n2013-10-21 06:06:08 Starting Glance\n2013-10-21 06:06:08 ++ trueorfalse True False\n2013-10-21 06:06:08 ++ local default=True\n2013-10-21 06:06:08 ++ local testval=False\n2013-10-21 06:06:08 ++ [[ -z False ]]\n2013-10-21 06:06:08 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-10-21 06:06:08 ++ echo False\n2013-10-21 06:06:08 ++ return\n2013-10-21 06:06:08 + USE_SCREEN=False\n2013-10-21 06:06:08 + is_service_enabled g-reg\n2013-10-21 06:06:08 + services=g-reg\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,g-reg, ]]\n2013-10-21 06:06:08 + return 0\n2013-10-21 06:06:08 + screen_rc g-reg \'cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + SCREEN_NAME=stack\n2013-10-21 06:06:08 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:08 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-21 06:06:08 + grep g-reg /opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:08 ++ echo -ne \'\\015\'\n2013-10-21 06:06:08 + NL=$\'\\r\'\n2013-10-21 06:06:08 + echo \'screen -t g-reg bash\'\n2013-10-21 06:06:08 + echo \'stuff \"cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\n\"\'\n2013-10-21 06:06:08 + [[ False = \\T\\r\\u\\e ]]\n2013-10-21 06:06:08 + run_process g-reg \'cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + local service=g-reg\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + echo 22808\n2013-10-21 06:06:08 + screen_it g-api \'cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + SCREEN_NAME=stack\n2013-10-21 06:06:08 + SERVICE_DIR=/opt/stack/new/status\n2013-10-21 06:06:08 + _run_process g-reg \'cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + local service=g-reg\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/glance; /usr/local/bin/glance-registry --config-file=/etc/glance/glance-registry.conf\'\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 + _run_process s-account \'cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n2013-10-21 06:06:08 + local service=s-account\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/swift && /opt/stack/new/swift/bin/swift-account-server /etc/swift/account-server/1.conf -v\'\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 ++ trueorfalse True False\n2013-10-21 06:06:08 ++ local default=True\n2013-10-21 06:06:08 ++ local testval=False\n2013-10-21 06:06:08 ++ [[ -z False ]]\n2013-10-21 06:06:08 ++ [[ 0 no No NO false False FALSE =~ False ]]\n2013-10-21 06:06:08 ++ echo False\n2013-10-21 06:06:08 ++ return\n2013-10-21 06:06:08 + USE_SCREEN=False\n2013-10-21 06:06:08 + is_service_enabled g-api\n2013-10-21 06:06:08 + services=g-api\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,g-api, ]]\n2013-10-21 06:06:08 + return 0\n2013-10-21 06:06:08 + screen_rc g-api \'cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + SCREEN_NAME=stack\n2013-10-21 06:06:08 + SCREENRC=/opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:08 + [[ ! -e /opt/stack/new/devstack/stack-screenrc ]]\n2013-10-21 06:06:08 + grep g-api /opt/stack/new/devstack/stack-screenrc\n2013-10-21 06:06:08 ++ echo -ne \'\\015\'\n2013-10-21 06:06:08 + NL=$\'\\r\'\n2013-10-21 06:06:08 + echo \'screen -t g-api bash\'\n2013-10-21 06:06:08 + echo \'stuff \"cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\n\"\'\n2013-10-21 06:06:08 + [[ False = \\T\\r\\u\\e ]]\n2013-10-21 06:06:08 + run_process g-api \'cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + local service=g-api\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + echo 22825\n2013-10-21 06:06:08 + echo \'Waiting for g-api (127.0.0.1:9292) to start...\'\n2013-10-21 06:06:08 Waiting for g-api (127.0.0.1:9292) to start...\n2013-10-21 06:06:08 + timeout 60 sh -c \'while ! wget --no-proxy -q -O- http://127.0.0.1:9292; do sleep 1; done\'\n2013-10-21 06:06:08 + _run_process g-api \'cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + local service=g-api\n2013-10-21 06:06:08 + local \'command=cd /opt/stack/new/glance; /usr/local/bin/glance-api --config-file=/etc/glance/glance-api.conf\'\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 + exec\n2013-10-21 06:06:08 {\"versions\": [{\"status\": \"CURRENT\", \"id\": \"v2.2\", \"links\": [{\"href\": \"http://127.0.0.1:9292/v2/\", \"rel\": \"self\"}]}, {\"status\": \"SUPPORTED\", \"id\": \"v2.1\", \"links\": [{\"href\": \"http://127.0.0.1:9292/v2/\", \"rel\": \"self\"}]}, {\"status\": \"SUPPORTED\", \"id\": \"v2.0\", \"links\": [{\"href\": \"http://127.0.0.1:9292/v2/\", \"rel\": \"self\"}]}, {\"status\": \"CURRENT\", \"id\": \"v1.1\", \"links\": [{\"href\": \"http://127.0.0.1:9292/v1/\", \"rel\": \"self\"}]}, {\"status\": \"SUPPORTED\", \"id\": \"v1.0\", \"links\": [{\"href\": \"http://127.0.0.1:9292/v1/\", \"rel\": \"self\"}]}]}+ is_service_enabled ir-api ir-cond\n2013-10-21 06:06:08 + services=\'ir-api ir-cond\'\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,ir-api, ]]\n2013-10-21 06:06:08 + [[ ir-api == n-cell-* ]]\n2013-10-21 06:06:08 + [[ ir-api == \\n\\o\\v\\a ]]\n2013-10-21 06:06:08 + [[ ir-api == \\c\\i\\n\\d\\e\\r ]]\n2013-10-21 06:06:08 + [[ ir-api == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-21 06:06:08 + [[ ir-api == \\g\\l\\a\\n\\c\\e ]]\n2013-10-21 06:06:08 + [[ ir-api == \\n\\e\\u\\t\\r\\o\\n ]]\n2013-10-21 06:06:08 + [[ ir-api == \\t\\r\\o\\v\\e ]]\n2013-10-21 06:06:08 + [[ ir-api == \\s\\w\\i\\f\\t ]]\n2013-10-21 06:06:08 + [[ ir-api == s-* ]]\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,ir-cond, ]]\n2013-10-21 06:06:08 + [[ ir-cond == n-cell-* ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\n\\o\\v\\a ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\c\\i\\n\\d\\e\\r ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\g\\l\\a\\n\\c\\e ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\n\\e\\u\\t\\r\\o\\n ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\t\\r\\o\\v\\e ]]\n2013-10-21 06:06:08 + [[ ir-cond == \\s\\w\\i\\f\\t ]]\n2013-10-21 06:06:08 + [[ ir-cond == s-* ]]\n2013-10-21 06:06:08 + return 1\n2013-10-21 06:06:08 + is_service_enabled key\n2013-10-21 06:06:08 + services=key\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,key, ]]\n2013-10-21 06:06:08 + return 0\n2013-10-21 06:06:08 + is_service_enabled swift3\n2013-10-21 06:06:08 + services=swift3\n2013-10-21 06:06:08 + for service in \'${services}\'\n2013-10-21 06:06:08 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,c-bak,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,ceilometer-alarm-notifier,ceilometer-alarm-evaluator,n-net, =~ ,swift3, ]]\n2013-10-21 06:06:08 + [[ swift3 == n-cell-* ]]\n2013-10-21 06:06:08 + [[ swift3 == \\n\\o\\v\\a ]]\n2013-10-21 06:06:08 + [[ swift3 == \\c\\i\\n\\d\\e\\r ]]\n2013-10-21 06:06:08 + [[ swift3 == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n2013-10-21 06:06:08 + [[ swift3 == \\g\\l\\a\\n\\c\\e ]]\n2013-10-21 06:06:08 + [[ swift3 == \\n\\e\\u\\t\\r\\o\\n ]]\n2013-10-21 06:06:08 + [[ swift3 == \\t\\r\\o\\v\\e ]]\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-593910-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-593910.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-593910/39/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<380854819.64.1382162846501.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1589585613.5760557.1390405649867.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 10:47:29',-18000,'2014-01-22 15:47:29',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival\n	#1	-	Roles','> On Jan 22, 2014, at 7:09 AM, Jaromir Coufal <jcoufal at redhat.com> wrote:\n> \n> > \n> > \n> > On 2014/22/01 10:00, Jaromir Coufal wrote:\n> >> \n> >> \n> >> On 2014/22/01 00:56, Tzu-Mainn Chen wrote:\n> >>> Hiya - Resource is actually a Heat term that corresponds to what we\'re\n> >>> deploying within\n> >>> the Overcloud Stack - i.e., if we specify that we want an Overcloud\n> >>> with 1 Controller\n> >>> and 3 Compute, Heat will create a Stack that contains 1 Controller and\n> >>> 3 Compute\n> >>> Resources.\n> >> \n> >> Then a quick question - why do we design deployment by\n> >> increasing/decreasing number of *instances* instead of resources?\n> >> \n> >> -- Jarda\n> > \n> > And one more thing - Resource is very broad term as well as Role is. The\n> > only difference is that Heat accepted \'Resource\' as specific term for them\n> > (you see? they used broad term for their concept). So I am asking myself,\n> > where is difference between generic term Resource and Role? Why cannot we\n> > accept Roles? It\'s short, well describing...\n> > \n> > I am leaning towards Role. We can be more specific with adding some extra\n> > word, e.g.:\n> > * Node Role\n> \n> +1 to Node Role. I agree that ?role? is being used as a generic term here.\n> I?m still convinced it?s important to use ?Node? in the name since this is\n> the item we are describing by assigning it a certain type of role.\n\nI\'m *strongly* against Node Role.  In Ironic, a Node has no explicit Role assigned\nto it; whatever Role it has is implicit through the Instance running on it\n(which maps to a Heat Resource).\n\nIn that sense, we\'re not really monitoring Nodes; we\'re monitoring Resources, and\na Node \"just happens\" to be one attribute of a Resource.\n\nMainn\n\n> Liz\n> \n> > * Deployment Role\n> > ... and if we are in the context of undercloud, people can shorten it to\n> > just Roles. But \'Resource Category\' seems to me that it doesn\'t solve\n> > anything.\n> > \n> > -- Jarda\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<0A5F07A1-C337-4490-90CC-E592445F7821@redhat.com>',NULL),('<158A97FC7D125A40A52F49EE9C463AF512674627@MISOUT7MSGUSR9A.ITServices.sbc.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-31 12:26:43',0,'2014-03-31 12:26:43',NULL,'[Openstack-operators] OpenStack-operators Digest, Vol 41,\n	Issue 25','Folks: I am new to this mailing list.\nWhy does the user advisory group have to be selected by these other groups?\nIf this is really going to be run by users, I think word should go out that a user advisory group is being formed and who wants to join.\nAlso what will the costs to participate in this advisory group.\nThen once the group is \'formed\', have them decide how they want to govern or pick the chair/co-chair to help facilitate\nand work with the other groups.\n\n-----Original Message-----\nFrom: openstack-operators-request at lists.openstack.org [mailto:openstack-operators-request at lists.openstack.org] \nSent: Monday, March 31, 2014 8:00 AM\nTo: openstack-operators at lists.openstack.org\nSubject: OpenStack-operators Digest, Vol 41, Issue 25\n\nSend OpenStack-operators mailing list submissions to\n	openstack-operators at lists.openstack.org\n\nTo subscribe or unsubscribe via the World Wide Web, visit\n	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\nor, via email, send a message with subject or body \'help\' to\n	openstack-operators-request at lists.openstack.org\n\nYou can reach the person managing the list at\n	openstack-operators-owner at lists.openstack.org\n\nWhen replying, please edit your Subject line so it is more specific\nthan \"Re: Contents of OpenStack-operators digest...\"\n\n\nToday\'s Topics:\n\n   1. Re: Atlanta Summit - More Ops? ;) (Tom Fifield)\n   2. Unable to launch instance after basic	two-node DevStack\n      installation (Nico van Gessel)\n\n\n----------------------------------------------------------------------\n\nMessage: 1\nDate: Mon, 31 Mar 2014 10:15:39 +0800\nFrom: Tom Fifield <tom at openstack.org>\nTo: John Dewey <john at dewey.ws>\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Atlanta Summit - More Ops? ;)\nMessage-ID: <5338CFCB.9060603 at openstack.org>\nContent-Type: text/plain; charset=UTF-8; format=flowed\n\nOn 30/03/14 00:44, John Dewey wrote:\n> Would it make sense to have an ops PTL?\n\nSo, my reading is we already have such governance established - but \nrather than being an individual, it is a committee - the user committee. \nWe\'ll need to tweak it a bit I guess, but in fact it is already set up \nsuch that the TC _must_[1] listen to it ... for at least four hours per \nyear ;)\n\nSince the number of users majorly outweighs the number of developers in \na project, we probably do need more than a single individual. Tim, Ryan \nand JC have done very well in this extremely difficult position so far.\n\nHowever, I think if we can rally around the user committee, get some \nmore people in and start doing even more things it might just satisfy \nthe need for extra governance we\'re seeking.\n\nThoughts? What would you see this group doing?\n\n\nRegards,\n\n\nTom\n\n\n[1] 4.14 User Committee. The User Committee shall be an advisory \ncommittee to the Board of Directors and shall be comprised of at least \nthree (3) Individual Members, one (1) appointed by the Technical \nCommittee, one (1) appointed by the Board of Directors, and one (1) \nappointed by the appointees of the Technical Committee and Board of \nDirectors. The User Committee shall organize its meetings and may, on \napproval of the Board of Directors, create elected seats to be filled by \na vote of the Individual Members. On request of the User Committee, the \nBoard of Directors shall invite the User Committee to attend each \nregular quarterly meeting and shall allocate at least one (1) hour \nduring the regular quarterly meeting following the annual election to \nhear the report and recommendations of the User Committee. On request of \nthe User Committee, the Technical Committee shall invite the User \nCommittee to attend a regular meeting and shall allocate at least one \n(1) hour during such meeting up to four times each calendar year to hear \nthe report and recommendations of the User Committee.\n\n\n\n> John\n>\n> On Friday, March 28, 2014 at 2:34 AM, Tom Fifield wrote:\n>> All,\n>>\n>> I had a bit of a play around, combining some similar things from the\n>> suggestions, and was able to come up with something that I think covers\n>> everything that was suggested. If it\'s way off - no problems, we can go\n>> to a vote or similar.\n>>\n>> Also had a go at selecting moderators for sessions based on our\n>> volunteers - feel free to strike yourself out or move around.\n>>\n>> All of this is up for discussion and change, so read below and head on\n>> over to the etherpad, or post a reply email :)\n>>\n>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>\n>>\n>> Monday\n>> 0700 - 1115 Registration, Keynotes, Break\n>> 1115 - 1155 Ask the devs: Meet the PTLs and TC, How to get the best\n>> out of the design summit\n>> 1205 - 1245 Reasonable Defaults\n>>\n>> 1400 - 1440 Upgrades and Deployment Approaches\n>> 1450 - 1530 Architecture Show and Tell, Tales and Fails\n>> 1540 - 1620 Architecture Show and Tell, Tales and Fails\n>>\n>> 1730 - 1810 Security (MODERATOR NEEDED)\n>>\n>> Schedule: Friday\n>> 9:00 - 9:40 Enterprise Gaps\n>> 9:50 - 10:30 Database\n>>\n>> 10:50 - 11:30 Issues at Scale\n>> 11:40 - 12:20 Monitoring and Logging\n>>\n>> 1:20 - 2:00 Ansible (MODERATOR NEEDED)\n>> 2:10 - 2:50 Chef\n>> 3:00 - 3:40 Puppet\n>>\n>> 4:00 - 4:40 Networking\n>> 4:50 - 5:30 Best discovery of the week, Meta Discussion - ops\n>> communication and governance\n>>\n>>\n>> Regards,\n>>\n>>\n>> Tom\n>>\n>> On 27/03/14 11:20, Tom Fifield wrote:\n>>> All,\n>>>\n>>> The idea for this \"Operators Summit\" has received excellent support, and\n>>> we have more than twenty session ideas proposed in the etherpad:\n>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>\n>>> We\'ve blocked out a room on Monday to host it.\n>>>\n>>> What we need now is:\n>>> 1) Find moderators for the sessions\n>>> 2) Select which sessions are going to happen\n>>> 3) For the architecture show-and-tell, we probably need to select who\n>>> will present in this.\n>>>\n>>> If you can help with any of this, please do get in touch, or get your\n>>> name down on the etherpad. I\'ll be in contact soon.\n>>>\n>>>\n>>>\n>>> Regards,\n>>>\n>>>\n>>> Tom\n>>>\n>>> On 17/03/14 07:54, Tom Fifield wrote:\n>>>> Hi all,\n>>>>\n>>>> Would you like more time at the summit to talk OpenStack ops? Read on!\n>>>>\n>>>> Of course, we will have a dedicated Operations track in the conference -\n>>>> and it\'s going to be better than ever this year, with an all-new\n>>>> selection group ... all of whom actually run clouds.\n>>>>\n>>>>\n>>>> However, we\'ve never really had many design-summit style\n>>>> feedback/sharing sessons for ops. Let\'s change that.\n>>>>\n>>>>\n>>>> Would you find it useful to have a space to share architectures, best\n>>>> practices, and give feedback on the bits of OpenStack that are giving\n>>>> you pain? Or perhaps find out how to get more involved in the Open\n>>>> Design process? Help us justify locking away a few rooms :)\n>>>>\n>>>>\n>>>> Just to start the discussion, I have written up a straw man proposal/RFC\n>>>> of one potential use of the time. It\'s specifically designed to be\n>>>> ripped to shreds - so please do!\n>>>>\n>>>> The idea is to have something that\'s more like a design summit feel -\n>>>> people sitting in a room discussing things, as opposed to more\n>>>> presentations.\n>>>>\n>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>\n>>>>\n>>>> So, what would you like to see?\n>>>>\n>>>>\n>>>> Regards,\n>>>>\n>>>>\n>>>> Tom\n>>>>\n>>>> _______________________________________________\n>>>> OpenStack-operators mailing list\n>>>> OpenStack-operators at lists.openstack.org\n>>>> <mailto:OpenStack-operators at lists.openstack.org>\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> <mailto:OpenStack-operators at lists.openstack.org>\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> <mailto:OpenStack-operators at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n\n\n\n------------------------------\n\nMessage: 2\nDate: Mon, 31 Mar 2014 12:50:38 +0200\nFrom: Nico van Gessel <nico.vangessel at biologie.uni-freiburg.de>\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Unable to launch instance after basic\n	two-node DevStack installation\nMessage-ID: <5339487E.5050805 at biologie.uni-freiburg.de>\nContent-Type: text/plain; charset=ISO-8859-1\n\nHey there,\n\nfor three weeks I am struggling to get a basic OpenStack environment going. I learned a lot during my work but am still relatively new to Linux\nnetworking and the cloud architecture. After several luckless attempts to manually set up the machines following the official OpenStack documentation\nand some other tutorials I finally landed at using DevStack and still am unable to get things going.\n\nMy setup consists of\n- one physical controller node (\"controller\", 10.8.234.100, 4 cores, 16 GB RAM, 1 TB RAID1) and\n- one physical compute node (\"compute1\", 10.8.234.101, 8 cores, 64 GB RAM, 1 TB RAID1)\n\nBoth run on fresh Ubuntu 12.04 Server installations and connect to the same network (10.8.234.0/24) on eth0 through a gateway (10.8.234.254), using\naspecific proxy (http://proxy.uni-freiburg.de:8080) and DNS (132.230.201.111).\n\nUsing Ubuntu\'s environment variables I added proxy addresses, the no_proxy and the substitution of \"git://\" to /etc/profile:\n\n------------------------\nexport http_proxy=http://proxy.uni-freiburg.de:8080\nexport https_proxy=http://proxy.uni-freiburg.de:8080\nexport ftp_proxy=http://proxy.uni-freiburg.de:8080\nexport no_proxy=\"localhost,*.local,127.0.0.0/8,192.168.0.0/24,10.8.234.0/24\"\ngit config --global url.\"https://\".insteadOf git://\n------------------------\n\nTo get a simple nova-network with basic services I configured the devstack/local.conf on both nodes accordingly:\n\n------------------------\n\n[[local|localrc]]\n## Controller Host ##\nHOST_IP=10.8.234.100\nMULTI_HOST=1\n\n## Network nova-network ##\nFLAT_INTERFACE=eth0\nFIXED_RANGE=192.168.0.0/24\nFIXED_NETWORK_SIZE=254\nFLOATING_RANGE=10.8.234.128/27\n\n## Leaving Default Services Enabled ##\nDISABLED_SERVICES=neutron\n\n## Passwords ##\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=token\n\n## Logs ##\nLOGFILE=/opt/stack/logs/stack.sh.log\nVERBOSE=True\nLOG_COLOR=False\nSCREEN_LOGDIR=/opt/stack/logs\n\nRECLONE=yes\n\n## Images ##\nIMAGE_URLS+=\",http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img\"\n\n------------------------\n\n[[local|localrc]]\n## Compute Host ##\nSERVICE_HOST=10.8.234.100\nHOST_IP=10.8.234.101\nMULTI_HOST=1\n\n## Network nova-network ##\nFLAT_INTERFACE=eth0\nFIXED_RANGE=192.168.0.0/24\nFIXED_NETWORK_SIZE=254\nFLOATING_RANGE=10.8.234.128/27\n\n## Compute Node Services ##\nENABLED_SERVICES=n-cpu,n-net,n-api,n-vol\n\n## API URIs ##\nQ_HOST=$SERVICE_HOST\nMYSQL_HOST=$SERVICE_HOST\nRABBIT_HOST=$SERVICE_HOST\nGLANCE_HOSTPORT=$SERVICE_HOST:9292\nKEYSTONE_AUTH_HOST=$SERVICE_HOST\nKEYSTONE_SERVICE_HOST=$SERVICE_HOST\n\n## Passwords ##\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=token\n\n## Logs ##\nLOGFILE=/opt/stack/logs/stack.sh.log\nVERBOSE=True\nLOG_COLOR=False\nSCREEN_LOGDIR=/opt/stack/logs\n\n------------------------\n\nAfter succesfull completion of devstack/stack.sh on both nodes I can log in to Horizon and am able to see both Hypervisors \"controller\" and \"compute1\".\nThough when trying to launch an instance I get the following error message:\n\n------------------------\nError: Failed to launch instance \"Test\": Please try again later [Error: Remote error: ProcessExecutionError Unexpected error while running command.\nCommand: sudo nova-rootwrap /etc/nova/rootwrap.conf env CONFIG_FILE=[\"/etc/nova/nova.conf\"] NETWORK_ID=1 dnsmasq --strict-order --bind-interfaces\n--conf-file= --pid-file=/opt/stac].\n------------------------\n\nIs there somebody having an idea on what could be the problem here? My initial thought was that there maybe a conflict with the given DNS and/or\nproxy. But I don\'t know how to analyze this possibility.\n\nI\'d be deeply grateful for some suggestions...\n\nRegards, Nico\n\n\n\n------------------------------\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\nEnd of OpenStack-operators Digest, Vol 41, Issue 25\n***************************************************\n\n\n','<mailman.9.1396267201.16457.openstack-operators@lists.openstack.org>',NULL),('<158A97FC7D125A40A52F49EE9C463AF51267464F@MISOUT7MSGUSR9A.ITServices.sbc.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-31 12:28:49',0,'2014-03-31 12:28:49',NULL,'[Openstack-operators] OpenStack-operators Digest, Vol 41,\n	Issue 25','Sorry I didn\'t sign this.\nMargaret T. Chiosi, AT&T DMTS - \nI helped create the ETSI ISG NFV group and am currently leading the Open NFV platform study to create an open source platform for NFV (Network Function Virtualization)\n\n-----Original Message-----\nFrom: CHIOSI, MARGARET T \nSent: Monday, March 31, 2014 8:27 AM\nTo: openstack-operators at lists.openstack.org\nSubject: RE: OpenStack-operators Digest, Vol 41, Issue 25\n\nFolks: I am new to this mailing list.\nWhy does the user advisory group have to be selected by these other groups?\nIf this is really going to be run by users, I think word should go out that a user advisory group is being formed and who wants to join.\nAlso what will the costs to participate in this advisory group.\nThen once the group is \'formed\', have them decide how they want to govern or pick the chair/co-chair to help facilitate\nand work with the other groups.\n\n-----Original Message-----\nFrom: openstack-operators-request at lists.openstack.org [mailto:openstack-operators-request at lists.openstack.org] \nSent: Monday, March 31, 2014 8:00 AM\nTo: openstack-operators at lists.openstack.org\nSubject: OpenStack-operators Digest, Vol 41, Issue 25\n\nSend OpenStack-operators mailing list submissions to\n	openstack-operators at lists.openstack.org\n\nTo subscribe or unsubscribe via the World Wide Web, visit\n	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\nor, via email, send a message with subject or body \'help\' to\n	openstack-operators-request at lists.openstack.org\n\nYou can reach the person managing the list at\n	openstack-operators-owner at lists.openstack.org\n\nWhen replying, please edit your Subject line so it is more specific\nthan \"Re: Contents of OpenStack-operators digest...\"\n\n\nToday\'s Topics:\n\n   1. Re: Atlanta Summit - More Ops? ;) (Tom Fifield)\n   2. Unable to launch instance after basic	two-node DevStack\n      installation (Nico van Gessel)\n\n\n----------------------------------------------------------------------\n\nMessage: 1\nDate: Mon, 31 Mar 2014 10:15:39 +0800\nFrom: Tom Fifield <tom at openstack.org>\nTo: John Dewey <john at dewey.ws>\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] Atlanta Summit - More Ops? ;)\nMessage-ID: <5338CFCB.9060603 at openstack.org>\nContent-Type: text/plain; charset=UTF-8; format=flowed\n\nOn 30/03/14 00:44, John Dewey wrote:\n> Would it make sense to have an ops PTL?\n\nSo, my reading is we already have such governance established - but \nrather than being an individual, it is a committee - the user committee. \nWe\'ll need to tweak it a bit I guess, but in fact it is already set up \nsuch that the TC _must_[1] listen to it ... for at least four hours per \nyear ;)\n\nSince the number of users majorly outweighs the number of developers in \na project, we probably do need more than a single individual. Tim, Ryan \nand JC have done very well in this extremely difficult position so far.\n\nHowever, I think if we can rally around the user committee, get some \nmore people in and start doing even more things it might just satisfy \nthe need for extra governance we\'re seeking.\n\nThoughts? What would you see this group doing?\n\n\nRegards,\n\n\nTom\n\n\n[1] 4.14 User Committee. The User Committee shall be an advisory \ncommittee to the Board of Directors and shall be comprised of at least \nthree (3) Individual Members, one (1) appointed by the Technical \nCommittee, one (1) appointed by the Board of Directors, and one (1) \nappointed by the appointees of the Technical Committee and Board of \nDirectors. The User Committee shall organize its meetings and may, on \napproval of the Board of Directors, create elected seats to be filled by \na vote of the Individual Members. On request of the User Committee, the \nBoard of Directors shall invite the User Committee to attend each \nregular quarterly meeting and shall allocate at least one (1) hour \nduring the regular quarterly meeting following the annual election to \nhear the report and recommendations of the User Committee. On request of \nthe User Committee, the Technical Committee shall invite the User \nCommittee to attend a regular meeting and shall allocate at least one \n(1) hour during such meeting up to four times each calendar year to hear \nthe report and recommendations of the User Committee.\n\n\n\n> John\n>\n> On Friday, March 28, 2014 at 2:34 AM, Tom Fifield wrote:\n>> All,\n>>\n>> I had a bit of a play around, combining some similar things from the\n>> suggestions, and was able to come up with something that I think covers\n>> everything that was suggested. If it\'s way off - no problems, we can go\n>> to a vote or similar.\n>>\n>> Also had a go at selecting moderators for sessions based on our\n>> volunteers - feel free to strike yourself out or move around.\n>>\n>> All of this is up for discussion and change, so read below and head on\n>> over to the etherpad, or post a reply email :)\n>>\n>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>\n>>\n>> Monday\n>> 0700 - 1115 Registration, Keynotes, Break\n>> 1115 - 1155 Ask the devs: Meet the PTLs and TC, How to get the best\n>> out of the design summit\n>> 1205 - 1245 Reasonable Defaults\n>>\n>> 1400 - 1440 Upgrades and Deployment Approaches\n>> 1450 - 1530 Architecture Show and Tell, Tales and Fails\n>> 1540 - 1620 Architecture Show and Tell, Tales and Fails\n>>\n>> 1730 - 1810 Security (MODERATOR NEEDED)\n>>\n>> Schedule: Friday\n>> 9:00 - 9:40 Enterprise Gaps\n>> 9:50 - 10:30 Database\n>>\n>> 10:50 - 11:30 Issues at Scale\n>> 11:40 - 12:20 Monitoring and Logging\n>>\n>> 1:20 - 2:00 Ansible (MODERATOR NEEDED)\n>> 2:10 - 2:50 Chef\n>> 3:00 - 3:40 Puppet\n>>\n>> 4:00 - 4:40 Networking\n>> 4:50 - 5:30 Best discovery of the week, Meta Discussion - ops\n>> communication and governance\n>>\n>>\n>> Regards,\n>>\n>>\n>> Tom\n>>\n>> On 27/03/14 11:20, Tom Fifield wrote:\n>>> All,\n>>>\n>>> The idea for this \"Operators Summit\" has received excellent support, and\n>>> we have more than twenty session ideas proposed in the etherpad:\n>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>\n>>> We\'ve blocked out a room on Monday to host it.\n>>>\n>>> What we need now is:\n>>> 1) Find moderators for the sessions\n>>> 2) Select which sessions are going to happen\n>>> 3) For the architecture show-and-tell, we probably need to select who\n>>> will present in this.\n>>>\n>>> If you can help with any of this, please do get in touch, or get your\n>>> name down on the etherpad. I\'ll be in contact soon.\n>>>\n>>>\n>>>\n>>> Regards,\n>>>\n>>>\n>>> Tom\n>>>\n>>> On 17/03/14 07:54, Tom Fifield wrote:\n>>>> Hi all,\n>>>>\n>>>> Would you like more time at the summit to talk OpenStack ops? Read on!\n>>>>\n>>>> Of course, we will have a dedicated Operations track in the conference -\n>>>> and it\'s going to be better than ever this year, with an all-new\n>>>> selection group ... all of whom actually run clouds.\n>>>>\n>>>>\n>>>> However, we\'ve never really had many design-summit style\n>>>> feedback/sharing sessons for ops. Let\'s change that.\n>>>>\n>>>>\n>>>> Would you find it useful to have a space to share architectures, best\n>>>> practices, and give feedback on the bits of OpenStack that are giving\n>>>> you pain? Or perhaps find out how to get more involved in the Open\n>>>> Design process? Help us justify locking away a few rooms :)\n>>>>\n>>>>\n>>>> Just to start the discussion, I have written up a straw man proposal/RFC\n>>>> of one potential use of the time. It\'s specifically designed to be\n>>>> ripped to shreds - so please do!\n>>>>\n>>>> The idea is to have something that\'s more like a design summit feel -\n>>>> people sitting in a room discussing things, as opposed to more\n>>>> presentations.\n>>>>\n>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>\n>>>>\n>>>> So, what would you like to see?\n>>>>\n>>>>\n>>>> Regards,\n>>>>\n>>>>\n>>>> Tom\n>>>>\n>>>> _______________________________________________\n>>>> OpenStack-operators mailing list\n>>>> OpenStack-operators at lists.openstack.org\n>>>> <mailto:OpenStack-operators at lists.openstack.org>\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> <mailto:OpenStack-operators at lists.openstack.org>\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>\n>>\n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> <mailto:OpenStack-operators at lists.openstack.org>\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n\n\n\n------------------------------\n\nMessage: 2\nDate: Mon, 31 Mar 2014 12:50:38 +0200\nFrom: Nico van Gessel <nico.vangessel at biologie.uni-freiburg.de>\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] Unable to launch instance after basic\n	two-node DevStack installation\nMessage-ID: <5339487E.5050805 at biologie.uni-freiburg.de>\nContent-Type: text/plain; charset=ISO-8859-1\n\nHey there,\n\nfor three weeks I am struggling to get a basic OpenStack environment going. I learned a lot during my work but am still relatively new to Linux\nnetworking and the cloud architecture. After several luckless attempts to manually set up the machines following the official OpenStack documentation\nand some other tutorials I finally landed at using DevStack and still am unable to get things going.\n\nMy setup consists of\n- one physical controller node (\"controller\", 10.8.234.100, 4 cores, 16 GB RAM, 1 TB RAID1) and\n- one physical compute node (\"compute1\", 10.8.234.101, 8 cores, 64 GB RAM, 1 TB RAID1)\n\nBoth run on fresh Ubuntu 12.04 Server installations and connect to the same network (10.8.234.0/24) on eth0 through a gateway (10.8.234.254), using\naspecific proxy (http://proxy.uni-freiburg.de:8080) and DNS (132.230.201.111).\n\nUsing Ubuntu\'s environment variables I added proxy addresses, the no_proxy and the substitution of \"git://\" to /etc/profile:\n\n------------------------\nexport http_proxy=http://proxy.uni-freiburg.de:8080\nexport https_proxy=http://proxy.uni-freiburg.de:8080\nexport ftp_proxy=http://proxy.uni-freiburg.de:8080\nexport no_proxy=\"localhost,*.local,127.0.0.0/8,192.168.0.0/24,10.8.234.0/24\"\ngit config --global url.\"https://\".insteadOf git://\n------------------------\n\nTo get a simple nova-network with basic services I configured the devstack/local.conf on both nodes accordingly:\n\n------------------------\n\n[[local|localrc]]\n## Controller Host ##\nHOST_IP=10.8.234.100\nMULTI_HOST=1\n\n## Network nova-network ##\nFLAT_INTERFACE=eth0\nFIXED_RANGE=192.168.0.0/24\nFIXED_NETWORK_SIZE=254\nFLOATING_RANGE=10.8.234.128/27\n\n## Leaving Default Services Enabled ##\nDISABLED_SERVICES=neutron\n\n## Passwords ##\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=token\n\n## Logs ##\nLOGFILE=/opt/stack/logs/stack.sh.log\nVERBOSE=True\nLOG_COLOR=False\nSCREEN_LOGDIR=/opt/stack/logs\n\nRECLONE=yes\n\n## Images ##\nIMAGE_URLS+=\",http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img\"\n\n------------------------\n\n[[local|localrc]]\n## Compute Host ##\nSERVICE_HOST=10.8.234.100\nHOST_IP=10.8.234.101\nMULTI_HOST=1\n\n## Network nova-network ##\nFLAT_INTERFACE=eth0\nFIXED_RANGE=192.168.0.0/24\nFIXED_NETWORK_SIZE=254\nFLOATING_RANGE=10.8.234.128/27\n\n## Compute Node Services ##\nENABLED_SERVICES=n-cpu,n-net,n-api,n-vol\n\n## API URIs ##\nQ_HOST=$SERVICE_HOST\nMYSQL_HOST=$SERVICE_HOST\nRABBIT_HOST=$SERVICE_HOST\nGLANCE_HOSTPORT=$SERVICE_HOST:9292\nKEYSTONE_AUTH_HOST=$SERVICE_HOST\nKEYSTONE_SERVICE_HOST=$SERVICE_HOST\n\n## Passwords ##\nADMIN_PASSWORD=password\nMYSQL_PASSWORD=password\nRABBIT_PASSWORD=password\nSERVICE_PASSWORD=password\nSERVICE_TOKEN=token\n\n## Logs ##\nLOGFILE=/opt/stack/logs/stack.sh.log\nVERBOSE=True\nLOG_COLOR=False\nSCREEN_LOGDIR=/opt/stack/logs\n\n------------------------\n\nAfter succesfull completion of devstack/stack.sh on both nodes I can log in to Horizon and am able to see both Hypervisors \"controller\" and \"compute1\".\nThough when trying to launch an instance I get the following error message:\n\n------------------------\nError: Failed to launch instance \"Test\": Please try again later [Error: Remote error: ProcessExecutionError Unexpected error while running command.\nCommand: sudo nova-rootwrap /etc/nova/rootwrap.conf env CONFIG_FILE=[\"/etc/nova/nova.conf\"] NETWORK_ID=1 dnsmasq --strict-order --bind-interfaces\n--conf-file= --pid-file=/opt/stac].\n------------------------\n\nIs there somebody having an idea on what could be the problem here? My initial thought was that there maybe a conflict with the given DNS and/or\nproxy. But I don\'t know how to analyze this possibility.\n\nI\'d be deeply grateful for some suggestions...\n\nRegards, Nico\n\n\n\n------------------------------\n\n_______________________________________________\nOpenStack-operators mailing list\nOpenStack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\nEnd of OpenStack-operators Digest, Vol 41, Issue 25\n***************************************************\n\n\n',NULL,NULL),('<158A97FC7D125A40A52F49EE9C463AF512676B45@MISOUT7MSGUSR9A.ITServices.sbc.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-01 11:37:35',0,'2014-04-01 11:37:35',NULL,'[Openstack-operators] OpenStack-operators Digest, Vol 41,\n Issue 25','On the ETSI ISG NFV (Toby Ford is aware of this), we have a Network Operator Council which is an advisory board for the ISG NFV.\nWe have network vendors, component vendors, platform vendors as well as operators participating in this forum (which is only 15 months old).\n\nIt is all the \'operators\' with networks that are interested in virtualizing network functions. We have been discussing how do we as operators\nInfluence Openstack even though we may not have developers involved in the SW code submission.\nBut we will ultimately be some of the real users of the openstack software.\n\nSo we were thinking as a forum if we come up with specific feature \'gaps\' on Openstack, then we could submit the \nrequests. It appears you have a design summit twice a year where this could be done.\n\nMichael Brenner, ALU, volunteered to be our liaison to help us here.\n\nWhen is the next design summit? I know you have an Atlanta summit - but it is the same week as our meeting in Okinawa..\n\n\n\n-----Original Message-----\nFrom: Tom Fifield [mailto:tom at openstack.org] \nSent: Monday, March 31, 2014 11:30 PM\nTo: openstack-operators at lists.openstack.org; CHIOSI, MARGARET T\nSubject: Re: [Openstack-operators] OpenStack-operators Digest, Vol 41, Issue 25\n\nOn 31/03/14 20:28, CHIOSI, MARGARET T wrote:\n> Sorry I didn\'t sign this.\n> Margaret T. Chiosi, AT&T DMTS -\n> I helped create the ETSI ISG NFV group and am currently leading the Open NFV platform study to create an open source platform for NFV (Network Function Virtualization)\n>\n> -----Original Message-----\n> From: CHIOSI, MARGARET T\n> Sent: Monday, March 31, 2014 8:27 AM\n> To: openstack-operators at lists.openstack.org\n> Subject: RE: OpenStack-operators Digest, Vol 41, Issue 25\n>\n> Folks: I am new to this mailing list.\n> Why does the user advisory group have to be selected by these other groups?\n> If this is really going to be run by users, I think word should go out that a user advisory group is being formed and who wants to join.\n> Also what will the costs to participate in this advisory group.\n> Then once the group is \'formed\', have them decide how they want to govern or pick the chair/co-chair to help facilitate\n> and work with the other groups.\n\nHi Margaret,\n\nWelcome :) It\'s great to have your input.\n\nI\'m not sure if you\'ve seen the following emails in this thread yet, but \nwhat\'s being worked at now is how to potentially tweak our existing \ngovernance structure into something more like what you describe. It\'s \nnot about selection or exclusion - just trying to expand the scope of \nwhat was set up for this purpose so that it becomes even more useful, \nand avoid overbuilding. I, for one, definitely think that there will be \nsome kind of open call associated with this for people to \"do \nsomething\", but it clearly needs some people to do some coordination \nactivity to make even that happen.\n\nParticipation in any OpenStack community follows our Open principles \n(http://wiki.openstack.org/Open), is encouraged, and without cost. :)\n\n\nRegards,\n\n\nTom\n\n\n\n>\n> -----Original Message-----\n> From: openstack-operators-request at lists.openstack.org [mailto:openstack-operators-request at lists.openstack.org]\n> Sent: Monday, March 31, 2014 8:00 AM\n> To: openstack-operators at lists.openstack.org\n> Subject: OpenStack-operators Digest, Vol 41, Issue 25\n>\n> Send OpenStack-operators mailing list submissions to\n> 	openstack-operators at lists.openstack.org\n>\n> To subscribe or unsubscribe via the World Wide Web, visit\n> 	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n> or, via email, send a message with subject or body \'help\' to\n> 	openstack-operators-request at lists.openstack.org\n>\n> You can reach the person managing the list at\n> 	openstack-operators-owner at lists.openstack.org\n>\n> When replying, please edit your Subject line so it is more specific\n> than \"Re: Contents of OpenStack-operators digest...\"\n>\n>\n> Today\'s Topics:\n>\n>     1. Re: Atlanta Summit - More Ops? ;) (Tom Fifield)\n>     2. Unable to launch instance after basic	two-node DevStack\n>        installation (Nico van Gessel)\n>\n>\n> ----------------------------------------------------------------------\n>\n> Message: 1\n> Date: Mon, 31 Mar 2014 10:15:39 +0800\n> From: Tom Fifield <tom at openstack.org>\n> To: John Dewey <john at dewey.ws>\n> Cc: openstack-operators at lists.openstack.org\n> Subject: Re: [Openstack-operators] Atlanta Summit - More Ops? ;)\n> Message-ID: <5338CFCB.9060603 at openstack.org>\n> Content-Type: text/plain; charset=UTF-8; format=flowed\n>\n> On 30/03/14 00:44, John Dewey wrote:\n>> Would it make sense to have an ops PTL?\n>\n> So, my reading is we already have such governance established - but\n> rather than being an individual, it is a committee - the user committee.\n> We\'ll need to tweak it a bit I guess, but in fact it is already set up\n> such that the TC _must_[1] listen to it ... for at least four hours per\n> year ;)\n>\n> Since the number of users majorly outweighs the number of developers in\n> a project, we probably do need more than a single individual. Tim, Ryan\n> and JC have done very well in this extremely difficult position so far.\n>\n> However, I think if we can rally around the user committee, get some\n> more people in and start doing even more things it might just satisfy\n> the need for extra governance we\'re seeking.\n>\n> Thoughts? What would you see this group doing?\n>\n>\n> Regards,\n>\n>\n> Tom\n>\n>\n> [1] 4.14 User Committee. The User Committee shall be an advisory\n> committee to the Board of Directors and shall be comprised of at least\n> three (3) Individual Members, one (1) appointed by the Technical\n> Committee, one (1) appointed by the Board of Directors, and one (1)\n> appointed by the appointees of the Technical Committee and Board of\n> Directors. The User Committee shall organize its meetings and may, on\n> approval of the Board of Directors, create elected seats to be filled by\n> a vote of the Individual Members. On request of the User Committee, the\n> Board of Directors shall invite the User Committee to attend each\n> regular quarterly meeting and shall allocate at least one (1) hour\n> during the regular quarterly meeting following the annual election to\n> hear the report and recommendations of the User Committee. On request of\n> the User Committee, the Technical Committee shall invite the User\n> Committee to attend a regular meeting and shall allocate at least one\n> (1) hour during such meeting up to four times each calendar year to hear\n> the report and recommendations of the User Committee.\n>\n>\n>\n>> John\n>>\n>> On Friday, March 28, 2014 at 2:34 AM, Tom Fifield wrote:\n>>> All,\n>>>\n>>> I had a bit of a play around, combining some similar things from the\n>>> suggestions, and was able to come up with something that I think covers\n>>> everything that was suggested. If it\'s way off - no problems, we can go\n>>> to a vote or similar.\n>>>\n>>> Also had a go at selecting moderators for sessions based on our\n>>> volunteers - feel free to strike yourself out or move around.\n>>>\n>>> All of this is up for discussion and change, so read below and head on\n>>> over to the etherpad, or post a reply email :)\n>>>\n>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>\n>>>\n>>> Monday\n>>> 0700 - 1115 Registration, Keynotes, Break\n>>> 1115 - 1155 Ask the devs: Meet the PTLs and TC, How to get the best\n>>> out of the design summit\n>>> 1205 - 1245 Reasonable Defaults\n>>>\n>>> 1400 - 1440 Upgrades and Deployment Approaches\n>>> 1450 - 1530 Architecture Show and Tell, Tales and Fails\n>>> 1540 - 1620 Architecture Show and Tell, Tales and Fails\n>>>\n>>> 1730 - 1810 Security (MODERATOR NEEDED)\n>>>\n>>> Schedule: Friday\n>>> 9:00 - 9:40 Enterprise Gaps\n>>> 9:50 - 10:30 Database\n>>>\n>>> 10:50 - 11:30 Issues at Scale\n>>> 11:40 - 12:20 Monitoring and Logging\n>>>\n>>> 1:20 - 2:00 Ansible (MODERATOR NEEDED)\n>>> 2:10 - 2:50 Chef\n>>> 3:00 - 3:40 Puppet\n>>>\n>>> 4:00 - 4:40 Networking\n>>> 4:50 - 5:30 Best discovery of the week, Meta Discussion - ops\n>>> communication and governance\n>>>\n>>>\n>>> Regards,\n>>>\n>>>\n>>> Tom\n>>>\n>>> On 27/03/14 11:20, Tom Fifield wrote:\n>>>> All,\n>>>>\n>>>> The idea for this \"Operators Summit\" has received excellent support, and\n>>>> we have more than twenty session ideas proposed in the etherpad:\n>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>\n>>>> We\'ve blocked out a room on Monday to host it.\n>>>>\n>>>> What we need now is:\n>>>> 1) Find moderators for the sessions\n>>>> 2) Select which sessions are going to happen\n>>>> 3) For the architecture show-and-tell, we probably need to select who\n>>>> will present in this.\n>>>>\n>>>> If you can help with any of this, please do get in touch, or get your\n>>>> name down on the etherpad. I\'ll be in contact soon.\n>>>>\n>>>>\n>>>>\n>>>> Regards,\n>>>>\n>>>>\n>>>> Tom\n>>>>\n>>>> On 17/03/14 07:54, Tom Fifield wrote:\n>>>>> Hi all,\n>>>>>\n>>>>> Would you like more time at the summit to talk OpenStack ops? Read on!\n>>>>>\n>>>>> Of course, we will have a dedicated Operations track in the conference -\n>>>>> and it\'s going to be better than ever this year, with an all-new\n>>>>> selection group ... all of whom actually run clouds.\n>>>>>\n>>>>>\n>>>>> However, we\'ve never really had many design-summit style\n>>>>> feedback/sharing sessons for ops. Let\'s change that.\n>>>>>\n>>>>>\n>>>>> Would you find it useful to have a space to share architectures, best\n>>>>> practices, and give feedback on the bits of OpenStack that are giving\n>>>>> you pain? Or perhaps find out how to get more involved in the Open\n>>>>> Design process? Help us justify locking away a few rooms :)\n>>>>>\n>>>>>\n>>>>> Just to start the discussion, I have written up a straw man proposal/RFC\n>>>>> of one potential use of the time. It\'s specifically designed to be\n>>>>> ripped to shreds - so please do!\n>>>>>\n>>>>> The idea is to have something that\'s more like a design summit feel -\n>>>>> people sitting in a room discussing things, as opposed to more\n>>>>> presentations.\n>>>>>\n>>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>>\n>>>>>\n>>>>> So, what would you like to see?\n>>>>>\n>>>>>\n>>>>> Regards,\n>>>>>\n>>>>>\n>>>>> Tom\n\n\n\n','<533A32D0.9060505@openstack.org>',NULL),('<158A97FC7D125A40A52F49EE9C463AF512679C55@MISOUT7MSGUSR9A.ITServices.sbc.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-04-03 14:47:02',0,'2014-04-03 14:47:02',NULL,'[Openstack-operators] OpenStack Operator Participation','Decided to clean up the title - since I didn\'t do this correctly when I initiated the email.\n\nThanks for all the different feedback. I understand that it will not be effective if we as users just\ncome up with requirements and throw it over the wall and wait for the features to get developed.\nA long time ago, I use to own an organization that developed Frame Relay Network Product as well as Unix network drivers.\nSo I understand the value of an intimate relationship with user requests and development.\n\nI suspect it will be a combination of carriers creating a focused set of requirements that are missing in OpenStack \'today\' and\nthen working with our vendors in  submitting software to help fill in the gaps (as well as some carriers potentially also submitting code).\n\nBut by having a carrier specific user group may help us prioritize features and even be on the same page of key features which will\nhelp us focus on what to develop.\n\nSo question is - Is it useful to create an Operator User group - which I think this mailing list is an attempt to create a community around this?\n\n-----Original Message-----\nFrom: Tom Fifield [mailto:tom at openstack.org] \nSent: Tuesday, April 01, 2014 9:47 AM\nTo: CHIOSI, MARGARET T; openstack-operators at lists.openstack.org\nCc: Brenner, Michael Ralf (Michael) (michael.brenner at ALCATEL-LUCENT.COM); FORD, TOBY\nSubject: Re: [Openstack-operators] OpenStack-operators Digest, Vol 41, Issue 25\n\nForgot one pragmatic note.\n\nThere is actually a session on networking where feedback can be \ndelivered and it will be recorded at the ops summit. See the schedule @\n\nhttps://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n\n\n\nRegards,\n\n\nTom\n\nOn 01/04/14 21:42, Tom Fifield wrote:\n> Ah, Okinawa is excellent :)\n>\n> The design summit following Atlanta is in Paris, in the first week of\n> November.\n>\n> However, very crucially, this is not the only time you can participate\n> in the design and development of OpenStack.\n>\n> In fact, many claim that the design summits are \"the middle\" of the\n> discussion, and it\'s better to give feedback well before :)\n>\n> Understanding and participating in all of these occasions is actually a\n> big part of what makes OpenStack, OpenStack. This isn\'t a normal\n> proprietary software development process where you just put your\n> requirements in at the beginning and let it run away :)\n>\n> Jonathan Bryce has a good blog on this here:\n> https://www.openstack.org/blog/2014/01/openstack-2014-powered-by-users/\n>\n> There\'s so much I could write on the many ways we, as users, have to\n> contribute to the process and make sure our needs are met while\n> supporting our esteemed developers. Though, for now, I will just point\n> out one link, assuming more questions may come from reading the blog\n> post above:\n>\n> https://www.openstack.org/user-survey/\n>\n> We\'re launching the next user survey collection right now. Please tell\n> all your friends :)\n>\n> Looking forward to our continued interactions!\n>\n> Regards,\n>\n>\n> Tom\n>\n> On 01/04/14 19:37, CHIOSI, MARGARET T wrote:\n>> On the ETSI ISG NFV (Toby Ford is aware of this), we have a Network\n>> Operator Council which is an advisory board for the ISG NFV.\n>> We have network vendors, component vendors, platform vendors as well\n>> as operators participating in this forum (which is only 15 months old).\n>>\n>> It is all the \'operators\' with networks that are interested in\n>> virtualizing network functions. We have been discussing how do we as\n>> operators\n>> Influence Openstack even though we may not have developers involved in\n>> the SW code submission.\n>> But we will ultimately be some of the real users of the openstack\n>> software.\n>>\n>> So we were thinking as a forum if we come up with specific feature\n>> \'gaps\' on Openstack, then we could submit the\n>> requests. It appears you have a design summit twice a year where this\n>> could be done.\n>>\n>> Michael Brenner, ALU, volunteered to be our liaison to help us here.\n>>\n>> When is the next design summit? I know you have an Atlanta summit -\n>> but it is the same week as our meeting in Okinawa..\n>>\n>>\n>>\n>> -----Original Message-----\n>> From: Tom Fifield [mailto:tom at openstack.org]\n>> Sent: Monday, March 31, 2014 11:30 PM\n>> To: openstack-operators at lists.openstack.org; CHIOSI, MARGARET T\n>> Subject: Re: [Openstack-operators] OpenStack-operators Digest, Vol 41,\n>> Issue 25\n>>\n>> On 31/03/14 20:28, CHIOSI, MARGARET T wrote:\n>>> Sorry I didn\'t sign this.\n>>> Margaret T. Chiosi, AT&T DMTS -\n>>> I helped create the ETSI ISG NFV group and am currently leading the\n>>> Open NFV platform study to create an open source platform for NFV\n>>> (Network Function Virtualization)\n>>>\n>>> -----Original Message-----\n>>> From: CHIOSI, MARGARET T\n>>> Sent: Monday, March 31, 2014 8:27 AM\n>>> To: openstack-operators at lists.openstack.org\n>>> Subject: RE: OpenStack-operators Digest, Vol 41, Issue 25\n>>>\n>>> Folks: I am new to this mailing list.\n>>> Why does the user advisory group have to be selected by these other\n>>> groups?\n>>> If this is really going to be run by users, I think word should go\n>>> out that a user advisory group is being formed and who wants to join.\n>>> Also what will the costs to participate in this advisory group.\n>>> Then once the group is \'formed\', have them decide how they want to\n>>> govern or pick the chair/co-chair to help facilitate\n>>> and work with the other groups.\n>>\n>> Hi Margaret,\n>>\n>> Welcome :) It\'s great to have your input.\n>>\n>> I\'m not sure if you\'ve seen the following emails in this thread yet, but\n>> what\'s being worked at now is how to potentially tweak our existing\n>> governance structure into something more like what you describe. It\'s\n>> not about selection or exclusion - just trying to expand the scope of\n>> what was set up for this purpose so that it becomes even more useful,\n>> and avoid overbuilding. I, for one, definitely think that there will be\n>> some kind of open call associated with this for people to \"do\n>> something\", but it clearly needs some people to do some coordination\n>> activity to make even that happen.\n>>\n>> Participation in any OpenStack community follows our Open principles\n>> (http://wiki.openstack.org/Open), is encouraged, and without cost. :)\n>>\n>>\n>> Regards,\n>>\n>>\n>> Tom\n>>\n>>\n>>\n>>>\n>>> -----Original Message-----\n>>> From: openstack-operators-request at lists.openstack.org\n>>> [mailto:openstack-operators-request at lists.openstack.org]\n>>> Sent: Monday, March 31, 2014 8:00 AM\n>>> To: openstack-operators at lists.openstack.org\n>>> Subject: OpenStack-operators Digest, Vol 41, Issue 25\n>>>\n>>> Send OpenStack-operators mailing list submissions to\n>>>     openstack-operators at lists.openstack.org\n>>>\n>>> To subscribe or unsubscribe via the World Wide Web, visit\n>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>>>\n>>>\n>>> or, via email, send a message with subject or body \'help\' to\n>>>     openstack-operators-request at lists.openstack.org\n>>>\n>>> You can reach the person managing the list at\n>>>     openstack-operators-owner at lists.openstack.org\n>>>\n>>> When replying, please edit your Subject line so it is more specific\n>>> than \"Re: Contents of OpenStack-operators digest...\"\n>>>\n>>>\n>>> Today\'s Topics:\n>>>\n>>>      1. Re: Atlanta Summit - More Ops? ;) (Tom Fifield)\n>>>      2. Unable to launch instance after basic    two-node DevStack\n>>>         installation (Nico van Gessel)\n>>>\n>>>\n>>> ----------------------------------------------------------------------\n>>>\n>>> Message: 1\n>>> Date: Mon, 31 Mar 2014 10:15:39 +0800\n>>> From: Tom Fifield <tom at openstack.org>\n>>> To: John Dewey <john at dewey.ws>\n>>> Cc: openstack-operators at lists.openstack.org\n>>> Subject: Re: [Openstack-operators] Atlanta Summit - More Ops? ;)\n>>> Message-ID: <5338CFCB.9060603 at openstack.org>\n>>> Content-Type: text/plain; charset=UTF-8; format=flowed\n>>>\n>>> On 30/03/14 00:44, John Dewey wrote:\n>>>> Would it make sense to have an ops PTL?\n>>>\n>>> So, my reading is we already have such governance established - but\n>>> rather than being an individual, it is a committee - the user committee.\n>>> We\'ll need to tweak it a bit I guess, but in fact it is already set up\n>>> such that the TC _must_[1] listen to it ... for at least four hours per\n>>> year ;)\n>>>\n>>> Since the number of users majorly outweighs the number of developers in\n>>> a project, we probably do need more than a single individual. Tim, Ryan\n>>> and JC have done very well in this extremely difficult position so far.\n>>>\n>>> However, I think if we can rally around the user committee, get some\n>>> more people in and start doing even more things it might just satisfy\n>>> the need for extra governance we\'re seeking.\n>>>\n>>> Thoughts? What would you see this group doing?\n>>>\n>>>\n>>> Regards,\n>>>\n>>>\n>>> Tom\n>>>\n>>>\n>>> [1] 4.14 User Committee. The User Committee shall be an advisory\n>>> committee to the Board of Directors and shall be comprised of at least\n>>> three (3) Individual Members, one (1) appointed by the Technical\n>>> Committee, one (1) appointed by the Board of Directors, and one (1)\n>>> appointed by the appointees of the Technical Committee and Board of\n>>> Directors. The User Committee shall organize its meetings and may, on\n>>> approval of the Board of Directors, create elected seats to be filled by\n>>> a vote of the Individual Members. On request of the User Committee, the\n>>> Board of Directors shall invite the User Committee to attend each\n>>> regular quarterly meeting and shall allocate at least one (1) hour\n>>> during the regular quarterly meeting following the annual election to\n>>> hear the report and recommendations of the User Committee. On request of\n>>> the User Committee, the Technical Committee shall invite the User\n>>> Committee to attend a regular meeting and shall allocate at least one\n>>> (1) hour during such meeting up to four times each calendar year to hear\n>>> the report and recommendations of the User Committee.\n>>>\n>>>\n>>>\n>>>> John\n>>>>\n>>>> On Friday, March 28, 2014 at 2:34 AM, Tom Fifield wrote:\n>>>>> All,\n>>>>>\n>>>>> I had a bit of a play around, combining some similar things from the\n>>>>> suggestions, and was able to come up with something that I think\n>>>>> covers\n>>>>> everything that was suggested. If it\'s way off - no problems, we\n>>>>> can go\n>>>>> to a vote or similar.\n>>>>>\n>>>>> Also had a go at selecting moderators for sessions based on our\n>>>>> volunteers - feel free to strike yourself out or move around.\n>>>>>\n>>>>> All of this is up for discussion and change, so read below and head on\n>>>>> over to the etherpad, or post a reply email :)\n>>>>>\n>>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>>\n>>>>>\n>>>>> Monday\n>>>>> 0700 - 1115 Registration, Keynotes, Break\n>>>>> 1115 - 1155 Ask the devs: Meet the PTLs and TC, How to get the best\n>>>>> out of the design summit\n>>>>> 1205 - 1245 Reasonable Defaults\n>>>>>\n>>>>> 1400 - 1440 Upgrades and Deployment Approaches\n>>>>> 1450 - 1530 Architecture Show and Tell, Tales and Fails\n>>>>> 1540 - 1620 Architecture Show and Tell, Tales and Fails\n>>>>>\n>>>>> 1730 - 1810 Security (MODERATOR NEEDED)\n>>>>>\n>>>>> Schedule: Friday\n>>>>> 9:00 - 9:40 Enterprise Gaps\n>>>>> 9:50 - 10:30 Database\n>>>>>\n>>>>> 10:50 - 11:30 Issues at Scale\n>>>>> 11:40 - 12:20 Monitoring and Logging\n>>>>>\n>>>>> 1:20 - 2:00 Ansible (MODERATOR NEEDED)\n>>>>> 2:10 - 2:50 Chef\n>>>>> 3:00 - 3:40 Puppet\n>>>>>\n>>>>> 4:00 - 4:40 Networking\n>>>>> 4:50 - 5:30 Best discovery of the week, Meta Discussion - ops\n>>>>> communication and governance\n>>>>>\n>>>>>\n>>>>> Regards,\n>>>>>\n>>>>>\n>>>>> Tom\n>>>>>\n>>>>> On 27/03/14 11:20, Tom Fifield wrote:\n>>>>>> All,\n>>>>>>\n>>>>>> The idea for this \"Operators Summit\" has received excellent\n>>>>>> support, and\n>>>>>> we have more than twenty session ideas proposed in the etherpad:\n>>>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>>>\n>>>>>> We\'ve blocked out a room on Monday to host it.\n>>>>>>\n>>>>>> What we need now is:\n>>>>>> 1) Find moderators for the sessions\n>>>>>> 2) Select which sessions are going to happen\n>>>>>> 3) For the architecture show-and-tell, we probably need to select who\n>>>>>> will present in this.\n>>>>>>\n>>>>>> If you can help with any of this, please do get in touch, or get your\n>>>>>> name down on the etherpad. I\'ll be in contact soon.\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>>> Regards,\n>>>>>>\n>>>>>>\n>>>>>> Tom\n>>>>>>\n>>>>>> On 17/03/14 07:54, Tom Fifield wrote:\n>>>>>>> Hi all,\n>>>>>>>\n>>>>>>> Would you like more time at the summit to talk OpenStack ops?\n>>>>>>> Read on!\n>>>>>>>\n>>>>>>> Of course, we will have a dedicated Operations track in the\n>>>>>>> conference -\n>>>>>>> and it\'s going to be better than ever this year, with an all-new\n>>>>>>> selection group ... all of whom actually run clouds.\n>>>>>>>\n>>>>>>>\n>>>>>>> However, we\'ve never really had many design-summit style\n>>>>>>> feedback/sharing sessons for ops. Let\'s change that.\n>>>>>>>\n>>>>>>>\n>>>>>>> Would you find it useful to have a space to share architectures,\n>>>>>>> best\n>>>>>>> practices, and give feedback on the bits of OpenStack that are\n>>>>>>> giving\n>>>>>>> you pain? Or perhaps find out how to get more involved in the Open\n>>>>>>> Design process? Help us justify locking away a few rooms :)\n>>>>>>>\n>>>>>>>\n>>>>>>> Just to start the discussion, I have written up a straw man\n>>>>>>> proposal/RFC\n>>>>>>> of one potential use of the time. It\'s specifically designed to be\n>>>>>>> ripped to shreds - so please do!\n>>>>>>>\n>>>>>>> The idea is to have something that\'s more like a design summit\n>>>>>>> feel -\n>>>>>>> people sitting in a room discussing things, as opposed to more\n>>>>>>> presentations.\n>>>>>>>\n>>>>>>> https://etherpad.openstack.org/p/ATL-ops-unconference-RFC\n>>>>>>>\n>>>>>>>\n>>>>>>> So, what would you like to see?\n>>>>>>>\n>>>>>>>\n>>>>>>> Regards,\n>>>>>>>\n>>>>>>>\n>>>>>>> Tom\n>>\n>\n>\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n',NULL,NULL),('<158d8f94.c071.1483aa4cb26.Coremail.15510333529@163.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-03 16:32:31',28800,'2014-09-03 08:32:31',NULL,'[Openstack] openstack','openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140903/331e18ba/attachment.html>\n\n',NULL,NULL),('<1590213115.48.1373263487104.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-08 06:04:46',0,'2013-07-08 06:04:46',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #280','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/280/>\n\n------------------------------------------\n[...truncated 2639 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.17-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.107.g5c8616d to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.107.g5c8616d\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.17\nBest match: pbr 0.5.17\nProcessing pbr-0.5.17-py2.7.egg\nRemoving pbr 0.5.17 from easy-install.pth file\npbr 0.5.17 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.17-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0b1\nBest match: setuptools-git 1.0b1\nAdding setuptools-git 1.0b1 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.107.g5c8616d\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.17-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.4.0.34.g6f7458a to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.4.0.34.g6f7458a\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.17\nBest match: pbr 0.5.17\nProcessing pbr-0.5.17-py2.7.egg\nRemoving pbr 0.5.17 from easy-install.pth file\npbr 0.5.17 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.17-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0b1\nBest match: setuptools-git 1.0b1\nAdding setuptools-git 1.0b1 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.4.0.34.g6f7458a\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/rabbitmq/rabbit at devstack-1373260908-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/rabbitmq/rabbit at devstack-1373260908.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/280/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1590772962.2.1382594979042.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-24 06:09:39',0,'2013-10-24 06:09:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #37','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/37/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n    action, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4a89c10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4a89c10>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5084b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5084b50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-cd041d60-f5da-442c-a63b-7cc2140944ff\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:09:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:09:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:09:15+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:09:15-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'15\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:09:15Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'15\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64bd6d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x284fd50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.92 secs:\n    13.72    TestGlanceControl.test_bouncing\n    13.63    TestScrubber.test_delayed_delete\n    13.24    TestGlanceControl.test_reload\n    13.17    TestGlanceControl.test_respawn\n    12.17    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 452.404s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-37\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.M1dzO34QQn\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/37/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise37\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise37/37\n[SCP] Copying console log.\n\n\n','<224801190.74.1382422284883.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1592088827.25.1380952968919.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-05 06:02:48',0,'2013-10-05 06:02:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #32','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/32/>\n\n------------------------------------------\n[...truncated 636 lines...]\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.546s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.9\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.32\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.7.0\npytz==2013.7\nrequests==2.0.0\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.2xODvTEcnJ\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise10/32\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1593f438-d8f7-477d-8b7d-0c8fa0ecf981@inchnzm02.tcsin.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-19 16:32:55',19800,'2014-11-19 11:02:55',NULL,'[openstack-dev] Installing multinode(control node)','Hi,\n\nI want to install multinode in openstack, i need some guidence on what all are the services that i need to enable for installing control node.\nAttached is the localrc. \n\n-- \nThanks & Regards\n\nChhavi Kant\n\n=====-----=====-----=====\nNotice: The information contained in this e-mail\nmessage and/or attachments to it may contain \nconfidential or privileged information. If you are \nnot the intended recipient, any dissemination, use, \nreview, distribution, printing or copying of the \ninformation contained in this e-mail message \nand/or attachments to it are strictly prohibited. If \nyou have received this communication in error, \nplease notify us by reply e-mail or telephone and \nimmediately and permanently delete the message \nand any attachments. Thank you\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/f7878dbb/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: localrc\nType: application/octet-stream\nSize: 1432 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/f7878dbb/attachment.obj>\n\n',NULL,NULL),('<1594039390.2096252.1422398116928.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-27 17:35:16',-18000,'2015-01-27 22:35:16',NULL,'[Openstack] [All] Summit Session Proposal Voting','----- Original Message -----\n> From: \"Matt Griffin\" <matt.griffin at percona.com>\n> To: \"Maish Saidel-Keesing\" <maishsk+openstack at maishsk.com>\n> \n> Here\'s a great presentation from the Women of OpenStack team about how to\n> write a better speaker proposal and the voting process.\n> \n> Recording: https://www.youtube.com/watch?v=CxFYNZ4jqik\n> Slides:\n> http://www.slideshare.net/openstack/designing-an-openstack-summit-session-submission-for-success\n> \n> Best,\n> Matt\n\nThe above provides good tips on enhancing your chances of getting a proposal selected but doesn\'t really address the core of the questions Maish was posing, which relate to the transparency of the selection process both in terms of the voting process and results publication (or more accurately lack thereof) and the subsequent impact of the track committees on the final selections (also unknown).\n\nThis is without endeavouring to also consider how realistic it is to pick out your preferred sessions from 1000+ submissions.\n\n-Steve\n\n> maishsk+openstack at maishsk.com> wrote:\n> \n> > Hello all.\n> >\n> > CFP is upon us, and thereafter will be a period of voting for the sessions.\n> >\n> > What is the purpose of the voting period? Is it for the Foundation to\n> > gauge what sessions are more popular?\n> > How is this measured?\n> > What weight does the popularity have in deciding if a session is\n> > accepted or not?\n> >\n> > And most importantly - are the results of the voting process publicly\n> > available - if so - where?\n> > And if not - then why not?\n> >\n> > Thanks\n> >\n> > --\n> > Maish Saidel-Keesing\n> >\n> >\n> > _______________________________________________\n> > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > Post to     : openstack at lists.openstack.org\n> > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> >\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<CAAH+R2LG2okJxdCZCysfiqpBCP-dDavo8RiP3viLhTEw2J-9EA@mail.gmail.com>',NULL),('<1595433608.15.1380780186037.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-03 06:03:06',0,'2013-10-03 06:03:06',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #28','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/28/>\n\n\n\n','<2093374292.14.1380694780841.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1595771095.606719.1411007145591.JavaMail.app@ela4-app2369.prod>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-18 02:25:45',0,'2014-09-18 02:25:45',NULL,'[Openstack] I\'d like to add you to my professional network on\n	LinkedIn','Hi,\n\nI&#39;d like to add you to my professional network on LinkedIn.\n\n- Raghavendra\n\nAccept: http://www.linkedin.com/blink?simpleRedirect=0Udz4Pd3AVcP8PdPsOej4UcjARfkh9rCZFt65QqnpKqipyk4dbdSx5i3RVpkJApn9xq7cCt7dBtmtvpnhFtCVFfmJB9C5QoORBt6BSrCAJt7dBtmsJr6RBfmtKqmJzon9Q9ClQqnpKimtBkClOs3Rx9CoRbmVWpztEdP1FbmgPsmYOq3RBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&msgID=I7914910588_1&markAsRead=\n\n\nYou received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=6tOrQkO9mJzonhPrClMrQkO9ndQsSBIc3gBqSdxt7dKpn1LfmNFomRB9CxHrSZxs71Is69Ns6Fzd3RAqm4CcjoMc38Zp6ACciQZp6BJ9CoRbmVWpztEdP1FbmgPsmYOq3RAqmkCt7dBtmtvpnhFtCVFfmJB9B4ScSh5hSxmhD9JhB51fmVBqSZkp6BJ9DdKtjRQ9CoRbmVWpztEdP1FbmgPsmYOq3RBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&amp;msgID=I7914910588_1&amp;markAsRead= Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSlQqnpKqjRHpipIsBlBoSBSsCljsClJrThPtmcZoipCdiRKuCoTq3sMqiRAcT5LcCwZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I7914910588_1&markAsRead=\n&copy; 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140918/f357fc66/attachment.html>\n\n',NULL,NULL),('<1596410699.16475089.1372874756549.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 11:05:56',-25200,'2013-07-03 18:05:56',NULL,'[openstack-dev] [vmware] VMwareAPI sub-team status update','Yes. I\'m logged into gerrit and I can review my own patch. I can\'t abandon or press \"work in progress\" on it.\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"David Ripton\" <dripton at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, July 3, 2013 1:25:47 PM\n> Subject: Re: [openstack-dev] [vmware] VMwareAPI sub-team status update\n> \n> On 07/03/2013 11:51 AM, Shawn Hartsock wrote:\n> \n> > Work in progress:\n> > * https://review.openstack.org/#/c/35502/ <- I can\'t click the \"Work in\n> > progress button\" I\'m not sure how else to signal that I\'m still working...\n> > help?\n> \n> It\'s your patch.  You should be able to.  (I just successfully put one\n> of my reviews into WIP state and then back to Ready for Review, so it\'s\n> not globally broken.)  Are you logged into Gerrit?\n> \n> --\n> David Ripton   Red Hat   dripton at redhat.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<51D45E9B.7010701@redhat.com>',NULL),('<1597465841.20771246.1384254597632.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 06:09:57',-18000,'2013-11-12 11:09:57',NULL,'[openstack-dev] Horizon PTL candidacy','\n\n> On 11/10/2013 11:53 PM, John Dickinson wrote:\n> > A random off-the-top-of-my-head use case would be to subscribe to\n> > events from creating or changing objects in a particular Swift\n> > account or container. This would allow much more efficient listings\n> > in Horizon for active containers (and may also be consumed by other\n> > listeners too).\n> > \n> > --John\n> > \n> \n> yupp.\n> There are many many usecases for this, and we\'d get rid of pulling\n> services for status.\n\nSounds reasonable, but just one caveat ...\n\nNotifications can either be disabled in the service config (e.g. by setting\nthe notifier_strategy to noop in the glance config) or mis-configured (e.g.\nby not overriding control_exchange name in the cinder code) such that the\nnotifications are not seen by the consumer.\n\nWe have a similar potential problem with ceilometer, and no good way currently\nof detecting the non-flow of notifications, i.e. the old story that the absence\nof evidence <> evidence of absence.\n\nI\'m not sure whether if it would be workable for horizon to detect whether\nnotifications are flowing for each service by probing in some way (e.g. by\nsetting & unsetting a random property on an image and then ensuring that \nthe corresponding image.update events are seen).\n\nIf the absence of notifications were easily & reliably detectable, then\nobviously horizon could simply fallback to polling.\n\nAnyhoo, just some food for thought.\n\nCheers,\nEoghan\n\n\n','<52808FA4.8020608@redhat.com>',NULL),('<1597492459.874517.1346363957163.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-30 14:59:17',-25200,'2012-08-30 21:59:17',NULL,'[openstack-dev] cleaning up an LXC instance fails','\n?Hi,\n\n?I downloaded nova from github.com yesterday.\nI started an LXC instance (with use_cow_images=True in nova.conf).\nTermination is done successfully, but it fails in cleanup.\nIs it a bug?\n\n?I\'m using libvirt 0.9.13.\n\nIn the log:\n2012-08-30 13:35:11 INFO nova.virt.libvirt.driver [-] [instance: cde9e8e0-621b-440a-969b-2a787adac731] Instance destroyed successfully.\n2012-08-30 13:35:11 ERROR nova.virt.libvirt.driver [req-381cac99-426a-44c0-83a7-e18060973cdb admin admin] [instance: cde9e8e0-621b-440a-969b-2a787adac731] Error from libvirt during saved instance removal. Code=3 Error=this function is not supported by the connection driver: virDomainHasManagedSaveImage\n\nI think it fails at line 488 in the following code:\n\nnova/virt/libvirt/driver.py \n?479 ? ? def _cleanup(self, instance, network_info, block_device_info):\n?480 ? ? ? ? try:\n?481 ? ? ? ? ? ? virt_dom = self._lookup_by_name(instance[\'name\'])\n?482 ? ? ? ? except exception.NotFound:\n?483 ? ? ? ? ? ? virt_dom = None\n?484 ? ? ? ? if virt_dom:\n?485 ? ? ? ? ? ? try:\n?486 ? ? ? ? ? ? ? ? # NOTE(derekh): we can switch to undefineFlags and\n?487 ? ? ? ? ? ? ? ? # VIR_DOMAIN_UNDEFINE_MANAGED_SAVE once we require 0.9.4\n?488 ? ? ? ? ? ? ? ? if virt_dom.hasManagedSaveImage(0):\n?489 ? ? ? ? ? ? ? ? ? ? virt_dom.managedSaveRemove(0)\n\n?Thanks,\n?David\n\n----------------------\nDr. Dong-In \"David\" Kang\nComputer Scientist\nUSC/ISI\n\n\n','<1682876801.874474.1346363564429.JavaMail.root@zm.isi.edu>',NULL),('<1598989304.12.1385050660993.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-21 16:17:40',0,'2013-11-21 16:17:40',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #55','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/55/>\n\n------------------------------------------\n[...truncated 21569 lines...]\ntempest.cli.simple_read_only.test_ceilometer.SimpleReadOnlyCeilometerClientTest.test_ceilometermeter_alarm_list ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_admin_help ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_crud_no_resources[gate,smoke] ... ok\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke]\ntempest.api.orchestration.stacks.test_stacks.StacksTestJSON.test_stack_list_responds[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_absolute_limit_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_availability_zone_list ... ok\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_backup_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_bash_completion ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_credentials ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_debug_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_endpoints ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_extra_specs_list ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get_delete[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke]\ntempest.api.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_fake_action ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate]\ntempest.api.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id[gate] ... ok\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate]\ntempest.api.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          101.278\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  74.641\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   67.414\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_create_backup[gate]                           56.558\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             48.232\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                47.891\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_create_backup[gate]                            39.905\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        39.194\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         39.108\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        37.841\n\n----------------------------------------------------------------------\nRan 1502 tests in 1371.379s\n\nOK (skipped=79)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-711423-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-711423.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-711423/55/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<676476957.99.1384410581840.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1599792815.9.1382767815846.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-26 06:10:15',0,'2013-10-26 06:10:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #43','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/43/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x595eed0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e626d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e626d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-99c92c3d-de0b-4e4f-958d-b0f1946eec3a\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x3a4c9b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x3a4c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x3a4c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x3a4c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:09:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:09:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:09:44+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'44\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:09:44-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'44\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:09:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d04290>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x270db10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 85.44 secs:\n    25.00    TestScrubber.test_scrubber_app\n    19.48    TestScrubber.test_delayed_delete\n    13.97    TestGlanceControl.test_reload\n    13.80    TestGlanceControl.test_respawn\n    13.19    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 518.459s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.1\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.43\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.1\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.VJJ9fFcaTD\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/43/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-13/43\n[SCP] Copying console log.\n\n\n','<224080291.3.1382595144407.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<15AAD4F4-75B8-498C-8757-37B80A8DE578@demonware.net>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-05-26 23:11:00',-25200,'2014-05-27 06:11:00',NULL,'[Openstack-operators] [Neutron] EVB/Vepa','** Sorry if I?ve sent this twice, I realized I hadn?t set a subject. **\n\n Hi all\n\nDoes anybody have experience running neutron with 802.11Qbh/g?\nI have vepa/evb capable switches and want to move away from software overlays for performance reasons.\nDoes neutron support it and if so how?\n\nThanks\n\nStuart\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140526/fd5a08db/attachment.html>\n\n',NULL,NULL),('<15B2F4686BEC774D9271D3873DDF3B5FB809F04C@ORD1EXD03.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-24 16:30:20',0,'2014-07-24 16:30:20',NULL,'[openstack-dev] [Nova][Spec freeze exception] Controlled\n shutdown of GuestOS','\n________________________________________\nFrom: Day, Phil [philip.day at hp.com]\nSent: Thursday, July 24, 2014 9:20 AM\nTo: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange\nSubject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled shutdown of GuestOS\n\nAccording to: https://etherpad.openstack.org/p/nova-juno-spec-priorities   alaski has also singed up for this if I drop the point of contention - which I\'ev done\n\n\nYes, I will sponsor this one as well.  This is more a bug fix than a feature IMO and would be really nice to get into Juno.\n\n\n\n> -----Original Message-----\n> From: Michael Still [mailto:mikal at stillhq.com]\n> Sent: 24 July 2014 00:50\n> To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage\n> questions)\n> Subject: Re: [openstack-dev] [Nova][Spec freeze exception] Controlled\n> shutdown of GuestOS\n>\n> Another core sponsor would be nice on this one. Any takers?\n>\n> Michael\n>\n> On Thu, Jul 24, 2014 at 4:14 AM, Daniel P. Berrange <berrange at redhat.com>\n> wrote:\n> > On Wed, Jul 23, 2014 at 06:08:52PM +0000, Day, Phil wrote:\n> >> Hi Folks,\n> >>\n> >> I\'d like to propose the following as an exception to the spec freeze, on the\n> basis that it addresses a potential data corruption issues in the Guest.\n> >>\n> >> https://review.openstack.org/#/c/89650\n> >>\n> >> We were pretty close to getting acceptance on this before, apart from a\n> debate over whether one additional config value could be allowed to be set\n> via image metadata - so I\'ve given in for now on wanting that feature from a\n> deployer perspective, and said that we\'ll hard code it as requested.\n> >>\n> >> Initial parts of the implementation are here:\n> >> https://review.openstack.org/#/c/68942/\n> >> https://review.openstack.org/#/c/99916/\n> >\n> > Per my comments already, I think this is important for Juno and will\n> > sponsor it.\n> >\n> > Regards,\n> > Daniel\n> > --\n> > |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/\n> :|\n> > |: http://libvirt.org              -o-             http://virt-manager.org :|\n> > |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> > |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>\n>\n> --\n> Rackspace Australia\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<BD26CCD58723F74AA8E6BCB31052A1F00719797C@G6W2490.americas.hpqcorp.net>',NULL),('<15B2F4686BEC774D9271D3873DDF3B5FCA3ADB09@ORD1EXD02.RACKSPACE.CORP>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 05:35:21',0,'2015-01-28 05:35:21',NULL,'[openstack-dev] [nova] Nominating Melanie Witt\n	for	python-novaclient-core','+1\n\n________________________________________\nFrom: Michael Still [mikal at stillhq.com]\nSent: Tuesday, January 27, 2015 5:41 PM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] [nova] Nominating Melanie Witt for     python-novaclient-core\n\nGreetings,\n\nI would like to nominate Melanie Witt for the python-novaclient-core team.\n\n(What is python-novaclient-core? Its a new group which will contain\nall of nova-core as well as anyone else we think should have core\nreviewer powers on just the python-novaclient code).\n\nMelanie has been involved with nova for a long time now. She does\nsolid reviews in python-novaclient, and at least two current\nnova-cores have suggested her as ready for core review powers on that\nrepository.\n\nPlease respond with +1s or any concerns.\n\nReferences:\n\n    https://review.openstack.org/#/q/project:openstack/python-novaclient+reviewer:%22melanie+witt+%253Cmelwitt%2540yahoo-inc.com%253E%22,n,z\n\nAs a reminder, we use the voting process outlined at\nhttps://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our\ncore team.\n\nThanks,\nMichael\n\n--\nRackspace Australia\n\n__________________________________________________________________________\nOpenStack Development Mailing List (not for usage questions)\nUnsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAEd1pt7rhzxiyDkPgu=Ftsw=vxEVJhoELXhuSjxrMoHc-v+XXg@mail.gmail.com>',NULL),('<15B3F6CF-53DE-4236-BD7D-A1FD65ACE159@gmail.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2012-08-18 08:37:01',-14400,'2012-08-18 12:37:01',NULL,'[Openstack-docs] Operations Manual.','And I, in turn, have just entered a critical phase on DreamHost\'s cloud implementation. It may be a while before I can give this a significant amount of attention.\n\nDoug\n\nOn Aug 17, 2012, at 11:45 PM, Tom Fifield wrote:\n\n> I\'ve un-abandoned the change :)\n> \n> Sorry for the lack of communication - I\'ve been on the road for about a month now and haven\'t had a lot of time to peek in.\n> \n> Now it\'s time to attack\n> \n> http://webnumbr.com/untouched-bugs-in-openstack-manuals-\n> \n> \n> Regards,\n> \n> Tom\n> \n> \n> On 17/08/12 06:21, Williams-Cauley, Debra wrote:\n>> The final manuscript for the book project can be delivered in either Docbook\n>> or Sphinx. I will have authoring teams work in whatever is most convenient\n>> and then convert files at the end. Just keep me posted, happy to help.\n>> \n>> Debra\n>> \n>> \n>>> From: Anne Gentle <anne at openstack.org>\n>>> Date: Sun, 12 Aug 2012 10:48:51 -0400\n>>> To: Jonathan Proulx <jon at jonproulx.com>\n>>> Cc: Doug Hellmann <doug.hellmann at gmail.com>, \"Williams-Cauley, Debra\"\n>>> <Debra.J.Williams at pearson.com>, <openstack-docs at lists.openstack.org>\n>>> Subject: Re: [Openstack-docs] Operations Manual.\n>>> \n>>> On Fri, Aug 10, 2012 at 10:30 AM, Jonathan Proulx <jon at jonproulx.com> wrote:\n>>>> On Mon, Aug 6, 2012 at 11:50 AM, Doug Hellmann <doug.hellmann at gmail.com>\n>>>> wrote:\n>>>> \n>>>>> I have a bit of experience with DocBook, and IIRC it was an option with\n>>>>> Pearson. My book was done with Sphinx and LaTeX with only moderate pain\n>>>>> during the compositing phase.\n>>>> \n>>>>> Anything that makes merging and collaborating easy works for me. What tools\n>>>>> are the group used to working with?\n>>> \n>>> Hi Doug, for working on OpenStack docs, you can get an Oxygen license\n>>> for free which should make editing DocBook fairly fast and efficient.\n>>> \n>>> You can author with validation in emacs, if you don\'t want a separate\n>>> tool to launch. I\'ve updated the\n>>> http://wiki.openstack.org/Documentation/HowTo page with links about\n>>> how to configure emacs to validate XML if you would want to go that\n>>> route.\n>>> \n>>> As far as the collaboration stuff, it\'s all just like code projects\n>>> with Launchpad/Git/Gerrit/Jenkins as tool at the heart of the\n>>> processing.\n>>> \n>>> Can\'t wait to see some patches for the operations manual!\n>>> \n>>> Anne\n>>> \n>>>> Hi Doug,\n>>>> \n>>>> If you\'re going to be putting major hours into this I\'m personally\n>>>> happy to leave the choice of tools to you. So if you\'d rather use\n>>>> Sphinx and LaTeX let\'s go for that, if it\'s all the same I think the\n>>>> default path forward is what Anne suggested as a possibility:\n>>>> \n>>>>>> I think one good path is:\n>>>>>> 1. Un-abandon review 10487.\n>>>>>> 2. In the book file make sure CC licensing is set.\n>>>>>> 3. Start writing based on the outline.\n>>>>>> 4. Rock out.\n>>>>>> 5. Do maintenance going forward in a common authoring environment.\n>>>> \n>>>> -Jon\n>> \n>> \n>> _______________________________________________\n>> Openstack-docs mailing list\n>> Openstack-docs at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>> \n> \n\n\n\n','<502F0FCD.8010207@unimelb.edu.au>',NULL),('<15be01cdc271$2d485320$87d8f960$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 18:05:59',14400,'2012-11-14 14:05:59',NULL,'[openstack-dev] [quantum] Quantum extension framework issue','Hi guys,\n\n \n\nWhile working on the API extension for LBaaS I didn\'t find a way to use\ncustom member actions if they have the same name and differ only by request\nmethod, for example\n\n \n\nList all health monitors of a specific pool: GET\n/pool/pool_id/health_monitors\n\nAssociate health monitors with a pool: POST /pool/pool_id/health_monitors\n\n \n\nIn quantum extension framework we pass \"health_monitors\" as member actions\nfor a controller (quantum.api.v2.base.create_resource())\n\n \n\nmember_actions = {\'health_monitors\': \'GET\',\n\n                                        \'health_monitors\': \'POST\'}\n\n \n\ncontroller = base.create_resource(collection_name,\n\n                                    resource_name,\n\n                                    plugin, params,\n\n                                    member_actions=member_actions)\n\n \n\nAccording to the Controller implementation it dispatches all custom member\nactions to its plugin attr:\n\n \n\ndef __getattr__(self, name):\n\n        if name in self._member_actions:\n\n            def _handle_action(request, id, body=None):\n\n                return getattr(self._plugin, name)(request.context, id,\nbody)\n\n            return _handle_action\n\n        else:\n\n            raise AttributeError\n\n \n\nWhere request.context is of type quantum.context.Context and does not\ncontain info about request method.\n\nAs a result there is no way to distinguish two custom actions in the plugin.\n\n\nIs it an issue in the framework?\n\n \n\nPossible solution may be in concatenation of request method and action name\n(\"get_health_monitors\", \"post_health_monitors\") in a controller before\ndispatching them to a plugin.\n\nWhat do you think? \n\n \n\nThanks,\n\nOleg\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/0917fe55/attachment.html>\n\n',NULL,NULL),('<15C4B200-6413-487A-842C-6DC4D7E3D7A0@gmail.com>','http://lists.openstack.org/pipermail/openstack-hpc',NULL,'2013-04-15 11:25:51',-25200,'2013-04-15 18:25:51',NULL,'[openstack-hpc] [HPC] Anyone interested in an HPC-themed\n	unconference?','john, I would love to join....just like to hear what others are doing around openstack and HPC...so an unstructured meeting would be nice\n\nSent from my iPad\n\nOn Apr 15, 2013, at 10:31 AM, John Paul Walters <jwalters at isi.edu> wrote:\n\n> Hi,\n> \n> We missed the deadline for an HPC related design summit session, but there\'s still time to sign up for an unconference if anyone\'s interested.  Anyone interested?  I\'d propose one of the Wednesday slots.\n> \n> best,\n> JP\n> _______________________________________________\n> OpenStack-HPC mailing list\n> OpenStack-HPC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-hpc\n\n\n','<089349C0-F956-450C-910B-DB71B9FE2FDE@isi.edu>',NULL),('<15d5e076d9f4443a806f12a6cf72217a@BL2PR08MB051.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-13 21:18:08',0,'2013-09-13 21:18:08',NULL,'[openstack-dev] [Heat] Does Heat support checkpointing for guest\n application','All,\nI\'m wondering if Heat provide service for checkpointing the guest application for HA/redundancy similar to what corosync/pacemaker/openais provided for bare medal applications.\n\nThanks,\n\nQing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130913/d3c36c1a/attachment.html>\n\n',NULL,NULL),('<15d7294bb6e5f2209a9d9d7b62de0a54@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-03 16:25:41',-21600,'2013-12-03 22:25:41',NULL,'[openstack-dev] creating a default for oslo config variables  within a project?','We can\'t do that.  It used to behave that way, which led to \nhttps://bugs.launchpad.net/cinder/+bug/1065531\n\n-Ben\n\nOn 2013-12-03 16:22, Davanum Srinivas wrote:\n> Should we update oslo-incubator first to?\n> \n> default=os.environ.get(\"OSLO_LOCK_PATH\") or tempfile.mkdtemp()\n> \n> -- dims\n> \n> On Tue, Dec 3, 2013 at 4:56 PM, Sean Dague <sean at dague.net> wrote:\n>> This cinder patch - https://review.openstack.org/#/c/48935/\n>> \n>> Is blocked on failing upgrade because the updated oslo lockutils won\'t\n>> function until there is a specific configuration variable added to the\n>> cinder.conf.\n>> \n>> That work around is proposed here -\n>> https://review.openstack.org/#/c/52070/3\n>> \n>> However I think this is exactly the kind of forward breaks that we \n>> want\n>> to prevent with grenade, as cinder failing to function after a rolling\n>> upgrade because a config item wasn\'t added is exactly the kind of pain\n>> we are trying to prevent happening to ops.\n>> \n>> So the question is, how is this done correctly so that a default can \n>> be\n>> set in the cinder code for this value, and it not require a config\n>> change to work?\n>> \n>>         -Sean\n>> \n>> --\n>> Sean Dague\n>> http://dague.net\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n\n\n','<CANw6fcFZ5OwPgoqYbvkOZ8t1mtZcVhS3sGejVRYZDX47JgorjQ@mail.gmail.com>',NULL),('<15DD46D2-E612-4B50-9814-3F14E100E871@gmail.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-12 10:38:56',-25200,'2014-09-12 17:38:56',NULL,'[Openstack-operators] Kernel and KVM version','It?s been a long time since I saw that, but I had a similar issue.\nIIRC, the kernel you?re running has a bug in iSCSI, fixed in the 3.8.0-35 version\nWhat we experienced (in Ubuntu 12.04) was when a user would detach a cinder volume, the compute node would KP.\nKernel upgrade fixed it.\nI?m not 100% certain that is your issue, but you may be looking at a maintenance window and a kernel package upgrade.\n\nOn Sep 11, 2014, at 12:51 PM, Fl?vio Ramalho <f.ramalhoo at gmail.com> wrote:\n\n> Hello Abel,\n> \n> Sorry for the missing info.\n> \n> I am running Ubuntu 12.04 - 3.8.0-29-generic, QEMU emulator version\n> 1.5.0 and Openstack Havana.\n> \n> 2014-09-11 16:31 GMT-03:00 Abel Lopez <alopgeek at gmail.com>:\n>> More info please!\n>> What distro? What kernel version? what version of kvm? what version of openstack?\n>> \n>> On Sep 11, 2014, at 12:26 PM, Fl?vio Ramalho <f.ramalhoo at gmail.com> wrote:\n>> \n>>> Hi,\n>>> \n>>> Some compute nodes are frequently having kernel panic and, as far as I see, the kernel\n>>> panics are related with KVM.\n>>> \n>>> Do you guys have any recommendation about the kernel and KVM version to be used in\n>>> an production environment?\n>>> \n>>> Thanks,\n>>> \n>>> Fl?vio\n>>> _______________________________________________\n>>> OpenStack-operators mailing list\n>>> OpenStack-operators at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n> \n> \n> \n> -- \n> []\'s\n> Fl?vio\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140912/150d7954/attachment.pgp>\n\n','<CADbBuk_a2T10dgQi8KKkpjwF9zhTyOQPOuaCvKydMQVgTDDj3g@mail.gmail.com>',NULL),('<15dd5632.14014.148bbaf93c3.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-28 17:55:19',28800,'2014-09-28 09:55:19',NULL,'[openstack-dev] [nova] where can i get all notifications spec\n for nova','Yes. But it\'s just a part of notifications. Should we collect all notifications and display them in documents? Or is there an elegant way to get all notifications?\n\n\nThanks.\n\n\n--\n\nBest\n    Li Tianqing\n\nAt 2014-09-28 17:17:57, \"Liping Mao -X (limao - YI JIN XIN XI FU WU(SU ZHOU)YOU XIAN GONG SI at Cisco)\" <limao at cisco.com> wrote:\n\n\nYou may find part of them here?\n\nhttps://wiki.openstack.org/wiki/SystemUsageData\n\n \n\nRegards,\n\nLiping Mao\n\n \n\n \n\nFrom: Li Tianqing [mailto:jazeltq at 163.com]\nSent: 2014?9?28? 16:30\nTo:openstack-dev at lists.openstack.org\nSubject: [openstack-dev] [nova] where can i get all notifications spec for nova\n\n \n\nHello,\n\n    Is there some documents to display all notifications in nova? Thanks.\n\n\n\n\n\n\n--\n\nBest\n\n    Li Tianqing\n\n \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140928/db9d3e28/attachment.html>\n\n','<316691786CCAEE44AE90482264E3AB8206BCE64C@xmb-rcd-x08.cisco.com>',NULL),('<15E27F6D-2DCF-4C55-966A-E010EC9083E6@rackspace.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-09-05 19:03:01',0,'2014-09-05 19:03:01',NULL,'[User-committee] OpenStack End User Working Group','+1 \nOn Sep 5, 2014, at 2:55 PM, Everett Toews <everett.toews at RACKSPACE.COM> wrote:\n\n> No response on this in some time. Shall we take that as lazy consensus and move forward with Application Ecosystem Working Group?\n> \n> It would be good to get this squared away well before the Summit so we can plan to meet there and come up with a strategy and plans to promote the Application Ecosystem.\n> \n> One venue for discussing this could be one of these Tech Talks [1]. Or we could have a ?Birds of a Feather? session and just meet somewhere to discuss ourselves.\n> \n> Does anyone have any other ideas for venues to discuss this?\n> \n> Thanks,\n> Everett\n> \n> [1] http://openstack.prov12n.com/techtalks-at-openstack-summit-paris/\n> \n> \n> On Aug 29, 2014, at 10:59 AM, Rainya Mosher <rainya.mosher at RACKSPACE.COM> wrote:\n> \n>> \n>> Everett, +1 for Application Ecosystem Working Group. \n>> \n>> Rainya Mosher\n>> Dev Manager, PSST Release & Deploy\n>> 210.316.5065 (mobile)\n>> ----------------------------------------------\n>> Strategic ? Activator ? Connectedness ? Individualization ? Communication\n>> I am an artist. This means I live in a perverse fantasy world with unrealistic expectations. Thank you for understanding.\n>> \n>> \n>> \n>> From: Everett Toews <everett.toews at RACKSPACE.COM>\n>> Date: Friday, August 29, 2014 at 10:37 AM\n>> To: Tom Fifield <tom at openstack.org>\n>> Cc: \"user-committee at lists.openstack.org\" <user-committee at lists.openstack.org>\n>> Subject: Re: [User-committee] OpenStack End User Working Group\n>> \n>> 4. Application Ecosystem Working Group\n>> \n>> I?m partial to 4 because the connotations of an ecosystem promote broader thinking about the applications built for OpenStack clouds. \n> \n> _______________________________________________\n> User-committee mailing list\n> User-committee at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n\n\n','<AD782609-03DD-46DA-8F1C-5502622B268F@rackspace.com>',NULL),('<15E57B1B-7E80-4987-B6DA-7A0874FD6C9E@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-12 12:31:49',-28800,'2015-01-12 20:31:49',NULL,'[openstack-dev] [Keystone] LDAP Identity Use Survey','The Keystone development team is looking for deployment feedback regarding the use of the LDAP Identity backend. The Identity backend only covers Users and Groups.\n\nWe are looking to get an idea of types (read-only, read-write, etc) and reasons for use of the LDAP backend. The answers to this survey will help us to prioritize updates, changes, and set direction for the the LDAP Identity backend.\n\nhttp://goo.gl/forms/bzZT5KGqkv <http://goo.gl/forms/bzZT5KGqkv>\n\nThis survey is only meant to get information on the use of the LDAP Identity backend. Identity only contains User and Group information.\n\nCheers,\nMorgan Fainberg\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150112/5c6fe4e9/attachment.html>\n\n',NULL,NULL),('<15E6B766-C690-4232-9D84-32BDD3F78747@jbryce.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:54:42',-21600,'2014-02-05 17:54:42',NULL,'[openstack-dev] [PTL] Designating \"required use\" upstream code','On Feb 5, 2014, at 11:12 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n> I don\'t have a big issue with the way the Foundation currently enforces\n> \"you must use the code\" - anyone who signs a trademark agreement with\n> the Foundation agrees to \"include the entirety of\" Nova\'s code. That\'s\n> very vague, but I assume the Foundation can terminate the agreement if\n> it thinks the other party is acting in bad faith.\n> \n> Basically, I\'m concerned about us swinging from a rather lax \"you must\n> include our code\" rule to an overly strict \"you must make no downstream\n> modifications to our code?.\n\nI tend to agree with you for the most part. As they exist today, the trademark licenses include a couple of components: legally agreeing to use the code in the projects specified (requires self certification from the licensee) and passing the approved test suite once it exists (which adds a component requiring external validation of behavior). By creating the test suite and selecting required capabilities that can be externally validated through the test suite, we would take a step in tightening up the usage and consistency enforceable by our existing legal framework.\n\nI think that \"designated sections? could provide a useful construct for better general guidance on where the extension points to the codebase are. From a practical standpoint, it would probably be pretty difficult to efficiently audit an overly strict definition of the designated sections and this would still be a self certifying requirement on the licensee.\n\nJonathan\n\n\n\n','<1391620320.2357.71.camel@sorcha>',NULL),('<15ECA23895F1574CB3A15B81E6A9038304336E83@G6W2503.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/community',NULL,'2014-05-01 14:35:21',0,'2014-05-01 14:35:21',NULL,'[openstack-community] HP OpenStack Survey Available for OpenStack\n	Summit','OpenStack Community:\n\nThe survey is an experience and opinion survey.  Opinions solicited  include willingness to recommend OpenStack for different cloud environments, why they have or have not recommended OpenStack, and ratings of OpenStack for specific deployments.  The experiences covered included deployment metrics, workloads using OpenStack  and distributions used.  We will share a digest of results with the community.  The survey closes on Sunday May 4 at midnight.  Five eligible respondents will be selected at random for $100 American Express gift cards.\n\nLink to Survey: http://hp.io/61889Fgm\n\n\nStephen Spector\nSocial Media Strategist, HP Cloud\n\"Social Merlin\"\n(M) +1 512-529-1103 (O) +1 512-319-5137\nstephen.spector at hp.com<mailto:stephen.spector at hp.com> | @spectorID<http://www.twitter.com/spectorid>\n[ZA102637858]<http://www.twitter.com/hpcloud>[ZA102637857]<http://www.linkedin.com/groups?gid=4282907&trk=hb_side_g>[ZA102637861]<https://www.facebook.com/HPCloud>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140501/5f56e3a0/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image001.gif\nType: image/gif\nSize: 1351 bytes\nDesc: image001.gif\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140501/5f56e3a0/attachment.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image002.gif\nType: image/gif\nSize: 1295 bytes\nDesc: image002.gif\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140501/5f56e3a0/attachment-0001.gif>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: image003.gif\nType: image/gif\nSize: 1317 bytes\nDesc: image003.gif\nURL: <http://lists.openstack.org/pipermail/community/attachments/20140501/5f56e3a0/attachment-0002.gif>\n\n',NULL,NULL),('<15f6aa66a2eb4baaba0b15574e87c0db@SINPR04MB011.apcprd04.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-16 09:45:26',0,'2014-09-16 09:45:26',NULL,'[Openstack] [openstack-dev]Unable to get IP for VM on vmware esx5.5,\n openstack icehouse, nova-network','Hi All,\n\nI have ESX5.5 host and I want to manage the ESX host using openstack(icehouse).\n\nI have configured nova-network service to provide networking for the VMs, used vmwareESXDriver as compute driver.\n\nAll the required brdiges br169, vlan169, portgroup on ESX host with name br169 are gettign created but VM is unable to get IP address.\n\nMain configuration options from my nova.conf are as follows:\n\n[DEFAULT]\n\ndhcpbridge_flagfile=/etc/nova/nova.conf\n\ndhcpbridge=/usr/bin/nova-dhcpbridge\n\nbridge_interface=eth0\n\nforce_dhcp_release=True\n\ndhcp_lease_time=604800\n\nfixed_ip_disassociate_timeout=1209600\n\npublic_interface=vlan159\n\nconnection_type=vmware\n\ncompute_driver=vmwareapi.VMwareESXDriver\n\nnetwork_manager=nova.network.manager.VlanManager\n\nnetwork_size=256\n\nfixed_range=172.16.0.0/12\n\nauto_assign_floating_ip=True\n\n\n\n[vmware]\n\nhost_ip=10.233.52.201\n\nhost_username=root\n\nhost_password=******\n\nwsdl_location=http://10.233.52.212:8081/vmware/SDK//vsphere-ws/wsdl/vim25/vimService.wsdl\n\nvlan_interface=vmnic0\n\nvif_driver=nova.virt.vmwareapi.vif.VMWareVlanBridgeDriver\n\nPlease find attached nova.conf for all configuration options.\n\nCould anyone please suggest where am going wrong.\n\nI don\'t want to use neutron, VCenter driver.\nThanks & regards,\nSirisha Devineni\n\nDISCLAIMER\n==========\nThis e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140916/7f6132d5/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: nova.conf\nType: application/octet-stream\nSize: 2574 bytes\nDesc: nova.conf\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140916/7f6132d5/attachment.obj>\n\n','<af7b865e16c8494a8289f0547eedd3e3@SINPR04MB011.apcprd04.prod.outlook.com>',NULL),('<15f7298e.cff9.14acf1a34d8.Coremail.ll_nwpu@163.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-09 22:30:08',28800,'2015-01-09 14:30:08',NULL,'[Openstack] [neutron] Question about binding relationship between\n network and subnet','Hi, All\n\n\nI went through openstack user/admin guide and get to know neutron network/subnet concept. As my understanding, network is the logical isolated L2 domain and subnet attached to the network is for IP address management for attached network. But when playing with real OpenStack, I\'m confused with following questions:\n\n\n1. In dashboard, I create one pure network (without subnet attached). When VM connected to this network is started, dashboard reports error. It seems VM could be started successfully only when attached to network with subnet. I\'m wondering what\'s the purpose for this restriction? In real world, we often connect physical machines to pure L2 switch...\n\n\n2. Through neutron client, we could attach multi-subnets with one network. I\'m confused with this scenario: for one L2 network(vlan) usually we plan one subnet for that network and start one dhcp server for IP management. \n\n\nAppreciate your help in advance.\n\n\nThanks,\nLyon\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150109/2f83c7e5/attachment.html>\n\n',NULL,NULL),('<15F9715C-DBF1-4907-ABC1-718F2A252316@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-27 20:53:44',-14400,'2014-05-28 00:53:44',NULL,'[openstack-dev] [Neutron][IPv6] Minutes from May 27 2014','I am reading the meeting minute, and saw the discussion on this BP submitted by xuhanp:\n\nhttps://review.openstack.org/#/c/76125/\n\nI don?t see any reason why we need it?.do you?\n\nShixiong\n\n\n\nOn May 27, 2014, at 12:47 PM, Collins, Sean <Sean_Collins2 at cable.comcast.com> wrote:\n\n> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html\n> \n> -- \n> Sean M. Collins\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20140527164720.GC9528@HQSML-1081034>',NULL),('<15FEC8C6-5A5D-4F2B-845D-B57B99B8DAF3@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-27 09:45:58',14400,'2013-08-27 05:45:58',NULL,'[openstack-dev] [savanna] savanna-extra and hadoop-patch','Hi Erik,\n\nFirst of all, savanna-extra has been created exactly for such needs - to store all stuff that we need but couldn\'t be placed to another repos. Initially it contains elements and pre-builded jar with Swift HCFS. Now the last one has been moved to the CDN and it\'s a good idea to make separated project for elements.\n\nAs for Swift HCFS the core attached to the HADOOP-8545 is targeted to the Hadoop 2 version and should be patched to work with Hadoop 1.X correctly. So, that\'s why we add it to the extra repo. It looks like that it\'s ok to add one more repo for Swift HCFS near the savanna at stackforge like HCFS for Gluster[0].\n\nSo, let\'s discuss both of the migrations at the next IRC team meeting.\n\n[0] https://github.com/gluster/hadoop-glusterfs\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\nOn Aug 27, 2013, at 5:18, Matthew Farrellee <matt at redhat.com> wrote:\n\n> https://review.openstack.org/#/c/42926/\n> \n> I didn\'t get back to this on Friday and it got merged this morning, so here\'s my feedback.\n> \n> The savanna-extra repository now appears to hold (a) DIB image elements as well as (b) the source for the Swift backed HCFS (Hadoop Compatible File System) implementation.\n> \n> If I understand this correctly, (b) is actually the patch set that is being proposed to the Apache Hadoop community. That patch set has not been accepted and is being tracked in HADOOP-8545[0], which appears stalled since July 2013.\n> \n> Let\'s break Savanna\'s DIB elements out of savanna-extra and into savanna-image-elements. It has a clear path forward and a good definition of scope.\n> \n> Let\'s also leave savanna-extra as a grab bag, whose only occupant is currently the Swift code. Eventually that code will need a proper home, either contributed to Apache Hadoop or broken out as its own project.\n> \n> Best,\n> \n> \n> matt\n> \n> [0] https://issues.apache.org/jira/browse/HADOOP-8545\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<521BFE7E.5070309@redhat.com>',NULL),('<1600470800.1427391410980478729.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-09-17 19:01:18',0,'2014-09-17 19:01:18',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n Meeting September 18, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting September 18, 2014\nHost: Alan Clark\nDate: Thursday, September 18, 2014\nTime: 12:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 923 040 210\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=ta205a50d0d41f0f2176929241dffefd4\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tfe7cba6f49f64ca9014765ee89f6be11\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=295724267&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 923 040 210\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tc2619dbb8517ad8e14d47ebd5048e7b4\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140917/1aec967d/attachment.html>\n\n',NULL,NULL),('<1600657486.32617654.1372888427778.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 17:53:47',-14400,'2013-07-03 21:53:47',NULL,'[openstack-dev] [Ceilometer] Changing pollster/pipeline\n parameters','\n\n----- Original Message -----\n> A couple of related questions on managing CM pollster behavior via \"config\"\n> type files:\n> \n> 1. I\'m trying to make some modifications to the timing of the Glance (image)\n> polling in a default CM install. It looks like the pipeline interval fields\n> are the way to do it, and that I should tweak it using a yaml config file,\n> but I can\'t seem to verify based on a read-through of the code. Can anyone\n> confirm?\n\nYep, the configured interval in the /etc/ceilometer/pipeline.yaml is the way\nto go.\n\nFor example:\n\n $ sed -i \'s/interval: .*$/interval: 10/\' /etc/ceilometer/pipeline.yaml\n $ # restart ceilometer-agent-central\n $ ceilometer sample-list -m image.size | tail -5\n | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B    | 2013-07-03T21:40:15        |\n | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B    | 2013-07-03T21:40:25        |\n | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B    | 2013-07-03T21:40:35        |\n | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B    | 2013-07-03T21:40:45        |\n +--------------------------------------+------------+-------+------------+------+----------------------------+\n\nAs you see the meter is now being collected at a 10s cadence.\n\nThis timing is pulled in via the AgentManager base class:\n\n  https://github.com/openstack/ceilometer/blob/master/ceilometer/agent.py#L90\n \n> 2. Similarly, it looks like disabling pollsters is done via the oslo.cfg\n> logic in the agent manager. I\'d like to populate that using a config\n> file....is there logic already to do that that I haven\'t come across yet?\n\nWell the way I\'d disable a pollster is simply by configuring the counters\nexclusion in the pipeline.yaml.\n\nFor example to disable the pollster providing the image.size meter referred\nto above, the following will do the trick:\n\n    counters:\n        - \"*\"\n        - \"!image.size\"\n\ni.e. allow everything but the image.size meter.\n\nConfirm as before using:\n\n $ # restart ceilometer-agent-central\n $ ceilometer sample-list -m image.size | tail -5\n\n\nCheers,\nEoghan\n \n> - Phil\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1D1D76789BDAB4468D7C75811110C7C67F75CCEF@G9W0764.americas.hpqcorp.net>',NULL),('<1601334408.2804172.1398153478005.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-04-22 03:57:58',-14400,'2014-04-22 07:57:58',NULL,'[Openstack-docs] <replaceable>VALUE</replaceable> conventions?','I\'m sure you\'re right for those examples, but ensuring that the user knows that it is a variable covers all bases (even those with strange and wonderful configurations), and caps really do that. Not to mention that switching between caps and no caps gets rid of that standardization feel, which was the original motivator? \n\nJust 2 ? \nSummer \n\n----- Original Message -----\n\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: \"Summer Long\" <slong at redhat.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Tuesday, April 22, 2014 5:36:01 PM\n> Subject: Re: [Openstack-docs] <replaceable>VALUE</replaceable> conventions?\n\n> On 22/04/14 15:30, Summer Long wrote:\n> > I\'m +1 on the caps as well to make it obvious.\n> >\n> > Even more so in those cases where it functions without changing it. It\n> > might work, but not as they expect because they didn\'t think about it, and\n> > then they troubleshoot for days....\n\n> In the examples I\'ve provided (one from the install guide, and one from\n> the config reference), I don\'t believe this would be the case.\n\n> Do you have some examples where this could happen so we can help make a\n> distinction?\n\n> Regards,\n\n> Tom\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140422/fbcde27a/attachment-0001.html>\n\n','<53561BE1.2050908@openstack.org>',NULL),('<1601809969.392.1355186318868.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-12-11 00:38:38',0,'2012-12-11 00:38:38',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-postgres-vm-full #33','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/33/>\n\n\n\n','<1612710789.356.1355099759287.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<160189740.121001405954875836.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-07-21 15:01:15',0,'2014-07-21 15:01:15',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n	Meeting July 22, 2014','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting July 22, 2014\nHost: Alan Clark\nDate: Tuesday, July 22, 2014\nTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\n\nSession number: 925 892 682\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=teff1082a4ff1c633822be02eabeedf2e\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tc1d2646f7b5386b2c05a28f419a30245\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=291427802&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 925 892 682\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=ta11be132f134ca9085398d27972ee139\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140721/8aadd52b/attachment.html>\n\n',NULL,NULL),('<1602340171.59538.1379711131737.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-20 14:05:31',-25200,'2013-09-20 21:05:31',NULL,'[openstack-dev] [nova] [pci passthrough] Is \"extra_info\" broken?','\n----- Original Message -----\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Friday, September 20, 2013 1:28:13 PM\n> Subject: Re: [openstack-dev] [nova] [pci passthrough] Is \"extra_info\" broken?\n> https://bugs.launchpad.net/nova/+bug/1223559\n> \n> This should be already fixed. Make sure you\'re using a version new\n> enough to have the fix in it.\n\n I\'ve already patched the following two bug fixes.\n\nhttps://review.openstack.org/#/c/46690/\nhttps://review.openstack.org/#/c/46464/\n\n And the error that I have now is different from the previous ones.\nPrevious bug happens when extra_info is not specified in the pci_whitelist flag \nin the nova.conf file.\nNow, I specified extra_info something like this (for test):\n\npci_passthrough_whitelist=[{\"vendor_id\":\"8086\",\"product_id\":\"100f\",\"extra_info\": {\"path\":\"/dev/sda\"}}]\n\nThen, I got error. \nIs the error due to my misuse of extra_info or a bug?\n\nThe log in /var/log/nova/compute.log says:\n\n2013-09-20 14:00:53.203 7292 CRITICAL nova [-] Unacceptable parameters.\n2013-09-20 14:00:53.203 7292 TRACE nova Traceback (most recent call last):\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/bin/nova-compute\", line 10, in <module>\n2013-09-20 14:00:53.203 7292 TRACE nova     sys.exit(main())\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/cmd/compute.py\", line 68, in main\n2013-09-20 14:00:53.203 7292 TRACE nova     db_allowed=False)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/service.py\", line 257, in create\n2013-09-20 14:00:53.203 7292 TRACE nova     db_allowed=db_allowed)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/service.py\", line 139, in __init__\n2013-09-20 14:00:53.203 7292 TRACE nova     self.manager = manager_class(host=self.host, *args, **kwargs)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/compute/manager.py\", line 450, in __init__\n2013-09-20 14:00:53.203 7292 TRACE nova     self.driver = driver.load_compute_driver(self.virtapi, compute_driver)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/virt/driver.py\", line 1106, in load_compute_driver\n2013-09-20 14:00:53.203 7292 TRACE nova     virtapi)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/openstack/common/importutils.py\", line 52, in import_object_ns\n2013-09-20 14:00:53.203 7292 TRACE nova     return import_class(import_value)(*args, **kwargs)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py\", line 337, in __init__\n2013-09-20 14:00:53.203 7292 TRACE nova     self.dev_filter = pci_whitelist.get_pci_devices_filter()\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/pci/pci_whitelist.py\", line 117, in get_pci_devices_filter\n2013-09-20 14:00:53.203 7292 TRACE nova     return PciHostDevicesWhiteList(CONF.pci_passthrough_whitelist)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/pci/pci_whitelist.py\", line 102, in __init__\n2013-09-20 14:00:53.203 7292 TRACE nova     self.spec = self._parse_white_list_from_config(whitelist_spec)\n2013-09-20 14:00:53.203 7292 TRACE nova   File \"/usr/lib/python2.6/site-packages/nova/pci/pci_whitelist.py\", line 84, in _parse_white_list_from_config\n2013-09-20 14:00:53.203 7292 TRACE nova     raise exception.PciConfigInvalidWhitelist(reason=str(e))\n2013-09-20 14:00:53.203 7292 TRACE nova PciConfigInvalidWhitelist: Unacceptable parameters.\n2013-09-20 14:00:53.203 7292 TRACE nova \n\n Thanks,\n David\n\n\n\n\n','<523C85AD.1020902@redhat.com>',NULL),('<160262916.30455727.1407940721322.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 10:38:41',-14400,'2014-08-13 14:38:41',NULL,'[openstack-dev] [neutron] Rotating the weekly Neutron meeting','This is fantastic, thank you.\n\n----- Original Message -----\n> +1\n> \n> PCM (Paul Michali)\n> \n> MAIL ?..?. pcm at cisco.com\n> IRC ??..? pcm_ (irc.freenode.com)\n> TW ???... @pmichali\n> GPG Key ? 4525ECC253E31A83\n> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n> \n> \n> \n> On Aug 13, 2014, at 10:05 AM, Kyle Mestery <mestery at mestery.com> wrote:\n> \n> > Per this week\'s Neutron meeting [1], it was decided that offering a\n> > rotating meeting slot for the weekly Neutron meeting would be a good\n> > thing. This will allow for a much easier time for people in\n> > Asia/Pacific timezones, as well as for people in Europe.\n> > \n> > So, I\'d like to propose we rotate the weekly as follows:\n> > \n> > Monday 2100UTC\n> > Tuesday 1400UTC\n> > \n> > If people are ok with these time slots, I\'ll set this up and we\'ll\n> > likely start with this new schedule in September, after the FPF.\n> > \n> > Thanks!\n> > Kyle\n> > \n> > [1]\n> > http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<3811A899-EBF1-4648-AB00-6209860FFB92@cisco.com>',NULL),('<1602693279.37.1378361811407.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-05 06:16:51',0,'2013-09-05 06:16:51',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python26-stable-grizzly #10','See <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-grizzly/10/>\n\n\n\n','<528847273.24.1378275035515.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1603239410.103.1364019569015.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-23 06:19:28',0,'2013-03-23 06:19:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #173','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/173/>\n\n------------------------------------------\n[...truncated 943 lines...]\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.02\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.20\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: Test that versioning is handled properly through all channels\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_api.py\",> line 155, in test_version_variations\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 119.26 secs:\n    39.92    TestGlanceControl.test_bouncing\n    21.42    TestBinGlanceCacheManage.test_queue\n    20.62    TestBinGlance.test_results_filtering\n    19.61    TestRootApi.test_version_configurations\n    17.69    TestScrubber.test_delayed_delete\n----------------------------------------------------------------------\nRan 925 tests in 811.848s\n\nFAILED (SKIP=106, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.10\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-173\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.1.0\nkombu==2.5.8\nlxml==3.1.0\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.3.0\nrepoze.lru==0.6\nrequests==1.1.0\nsimplejson==3.1.2\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.14c4lQSykH\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/173\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/173/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1603362032.33028824.1418192272555.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-10 01:17:52',-18000,'2014-12-10 06:17:52',NULL,'[openstack-dev] [Telco][NFV] Meeting Reminder - Wednesday Dec 9 @\n 2200 UTC in #openstack-meeting','Hi all,\n\nJust a reminder that the Telco Working Group will be meeting @ 2200 UTC in #openstack-meeting on Wednesday December 9th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add anything you think I missed.\n\nThanks,\n\nSteve\n\n\n','<116250306.33028596.1418192185798.JavaMail.zimbra@redhat.com>',NULL),('<1603362032.33028824.1418192272555.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-10 01:17:52',-18000,'2014-12-10 06:17:52',NULL,'[Openstack-operators] [Telco][NFV] Meeting Reminder - Wednesday Dec\n 9 @ 2200 UTC in #openstack-meeting','Hi all,\n\nJust a reminder that the Telco Working Group will be meeting @ 2200 UTC in #openstack-meeting on Wednesday December 9th. Draft agenda is available here:\n\n    https://etherpad.openstack.org/p/nfv-meeting-agenda\n\nPlease feel free to add anything you think I missed.\n\nThanks,\n\nSteve\n\n\n','<116250306.33028596.1418192185798.JavaMail.zimbra@redhat.com>',NULL),('<1603462007.73.1386828136508.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:02:16',0,'2013-12-12 06:02:16',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-docs-grizzly #6','See <https://jenkins01.openstack.org/job/periodic-neutron-docs-grizzly/6/>\n\n------------------------------------------\n[...truncated 210 lines...]\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_constants.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_credentials_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_exceptions.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_faults.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_utils.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.api.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_db.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._credential_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._qos_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.credential.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.qos.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2device_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2network_plugin_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.models.virt_phy_sw_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.network_plugin.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_network_driver_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_plugin_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_snippets.rst\nGenerating doc/source/api/quantum.plugins.cisco.run_tests.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_cisco_extension.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_database.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.nexus.fake_nexus_driver.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.test_api_v2.rst\nGenerating doc/source/api/quantum.plugins.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.utils.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent_notifier_api.rst\nGenerating doc/source/api/quantum.plugins.hyperv.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.db.rst\nGenerating doc/source/api/quantum.plugins.hyperv.hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.hyperv.model.rst\nGenerating doc/source/api/quantum.plugins.hyperv.rpc_callbacks.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.agent.linuxbridge_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.config.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.constants.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.lb_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_db_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_models_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.proxy_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.run_tests.rst\nGenerating doc/source/api/quantum.plugins.midonet.config.rst\nGenerating doc/source/api/quantum.plugins.midonet.midonet_lib.rst\nGenerating doc/source/api/quantum.plugins.midonet.plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.agent.nec_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.nec.common.config.rst\nGenerating doc/source/api/quantum.plugins.nec.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nec.common.ofc_client.rst\nGenerating doc/source/api/quantum.plugins.nec.db.api.rst\nGenerating doc/source/api/quantum.plugins.nec.db.models.rst\nGenerating doc/source/api/quantum.plugins.nec.db.nec_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.pfc.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.trema.rst\nGenerating doc/source/api/quantum.plugins.nec.extensions.packetfilter.rst\nGenerating doc/source/api/quantum.plugins.nec.nec_plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_driver_base.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_manager.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.NvpApiClient.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.QuantumPlugin.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.common.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.check_nvp_config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.metadata_access.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.securitygroups.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_networkgw.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_qos.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_models.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_networkgw_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_qos_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_cluster.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_plugin_version.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvplib.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.agent.ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.config.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.constants.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_db_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_models_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plugin_ver.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_nos_snippets.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.rest_connection.rst\nGenerating doc/source/api/quantum.plugins.ryu.agent.ryu_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.ryu.common.config.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.api_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.models_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.ryu_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.api.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.manager.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.constants.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.cfg.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.namespace_driver.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.plugin.rst\nGenerating doc/source/api/quantum.plugins.services.service_base.rst\nGenerating doc/source/api/quantum.policy.rst\nGenerating doc/source/api/quantum.quantum_plugin_base_v2.rst\nGenerating doc/source/api/quantum.quota.rst\nGenerating doc/source/api/quantum.rootwrap.filters.rst\nGenerating doc/source/api/quantum.rootwrap.wrapper.rst\nGenerating doc/source/api/quantum.scheduler.dhcp_agent_scheduler.rst\nGenerating doc/source/api/quantum.scheduler.l3_agent_scheduler.rst\nGenerating doc/source/api/quantum.service.rst\nGenerating doc/source/api/quantum.tests.base.rst\nGenerating doc/source/api/quantum.tests.unit._test_extension_portbindings.rst\nGenerating doc/source/api/quantum.tests.unit._test_rootwrap_exec.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_restproxy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_router_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_vlan.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_network_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_nexus_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.database_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.db.loadbalancer.test_db_loadbalancer.rst\nGenerating doc/source/api/quantum.tests.unit.dummy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.extension_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extendedattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extensionattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.foxinsocks.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.v2attributes.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_db.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_linuxbridge_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.fake_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_basic.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_metaplugin.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_lib.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.stub_ofc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_agent.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_ofc_manager.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_pfc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_trema_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.fake_nvpapiclient.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_networkgw.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nicira_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request_eventlet.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvplib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_openvswitch_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_db.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_lib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_tunnel.rst\nGenerating doc/source/api/quantum.tests.unit.plumgrid.test_plumgrid_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.fake_ryu.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_agent.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_db.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_api.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_init.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_manager.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_cfg.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_namespace_driver.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.test_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ext_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_linux_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_netns_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ovs_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2_resource.rst\nGenerating doc/source/api/quantum.tests.unit.test_attributes.rst\nGenerating doc/source/api/quantum.tests.unit.test_auth.rst\nGenerating doc/source/api/quantum.tests.unit.test_common_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_migration.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_rpc_base.rst\nGenerating doc/source/api/quantum.tests.unit.test_debug_commands.rst\nGenerating doc/source/api/quantum.tests.unit.test_dhcp_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extended_attribute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extraroute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_portsecurity.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.test_extensions.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_firewall.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_daemon.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_dhcp.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_external_process.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_interface.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_ip_lib.rst\nGenerating doc/source/api/quantum.tests.unit.test_loadbalancer_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_namespace_proxy.rst\nGenerating doc/source/api/quantum.tests.unit.test_policy.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_context.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_quota_ext.rst\nGenerating doc/source/api/quantum.tests.unit.test_rootwrap.rst\nGenerating doc/source/api/quantum.tests.unit.test_routerserviceinsertion.rst\nGenerating doc/source/api/quantum.tests.unit.test_security_groups_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_servicetype.rst\nGenerating doc/source/api/quantum.tests.unit.test_wsgi.rst\nGenerating doc/source/api/quantum.tests.unit.testlib_api.rst\nGenerating doc/source/api/quantum.version.rst\nGenerating doc/source/api/quantum.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-neutron-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-neutron-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-grizzly/precise5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-grizzly/precise5/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1603885565.77323.1380102834030.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-25 17:53:47',28800,'2013-09-25 09:53:47',NULL,'[openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova\n libvirt driver','Hi all,\n\nI\'m the owner of this bp https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support\nand Daniel Berrange gave me lots of help about implementing this bp, and the original idea of mine is the same as yours.\nSo I think the opinion of Daniel will be very useful.\n\n2013-09-25\n\n\n\nWangpan\n\n\n\n????balaji patnala <patnala003 at gmail.com>\n?????2013-09-25 22:36\n???Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver\n????\"OpenStack Development Mailing List\"<openstack-dev at lists.openstack.org>\n???\n\nHi Haomai,\n\n\nThanks for your interest on this.\n\n\nThe code check-ins done against the below bp are more specific to Qemu Guest Agent.\n\n\n https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support\n\n\n\n\n\nOur requirement is to enable Virtio-Serial Interface to the applications running in VM.\n\n\nDo you have the same requirement?\n\n\nWe will share the draft BP on this.\n\n\n\n\nAny comments on this approach will be helpful.\n\n\nRegards,\nBalaji.P\n\n\n\nOn Tue, Sep 24, 2013 at 8:10 PM, Haomai Wang <haomai at unitedstack.com> wrote:\n\n\nOn Sep 24, 2013, at 6:40 PM, P Balaji-B37839 <B37839 at freescale.com> wrote:\n\n> Hi,\n>\n> Virtio-Serial interface support for Nova - Libvirt is not available now. Some VMs who wants to access the Host may need like running qemu-guest-agent or any proprietary software want to use this mode of communication with Host.\n>\n> Qemu-GA uses virtio-serial communication.\n>\n> We want to propose a blue-print on this for IceHouse Release.\n>\n> Anybody interested on this.\n\n\nGreat! We have common interest and I hope we can promote it for IceHouse.\n\nBTW, do you have a initial plan or description about it.\n\nAnd I think this bp may invoke. https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support\n\n\n>\n> Regards,\n> Balaji.P\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\nBest regards,\nHaomai Wang, UnitedStack Inc.\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130925/0019a507/attachment.html>\n\n','<CANT02KT5VZcuu1pjb9hnyVuoVzSMJxK+-i5xK=SvWSN_D4N1eA@mail.gmail.com>',NULL),('<160402605.36177112.1394805989419.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-14 10:06:29',-14400,'2014-03-14 14:06:29',NULL,'[Openstack-docs] Config reference news','----- Original Message -----\n> Le 2014-03-12 20:36, Steve Gordon a ?crit?:\n> > ----- Original Message -----\n> >> Hi!\n> >> \n> >> This change is raising a big question: how do we handle duplication\n> >> of\n> >> tables. Tables now have an xml:id attribute, and multiple inclusions\n> >> of\n> >> tables make the build fail [0]. Here are a few solutions:\n> >> \n> >> 1) find a way to include tables multiple times in the config-ref book\n> >> (docbook magic).\n> > \n> > There\'s no real magic possible here, each element in the DOM that has\n> > an ID must have a *unique* ID. Including the tables twice results in\n> > this not being the case.\n> > \n> >> 2) include tables in pages where they are actually needed, and add a\n> >> \"misc options\" page which includes all remaining tables.\n> >> 3) create a page including all the tables, and xlink from other\n> >> pages.\n> > \n> > This is my preference for consistency and to benefit maintenance. At\n> > the moment it\'s kind of difficult for the chapters that don\'t do this\n> > to work out which tables are missing because the ones that are there\n> > are spread around in the hierarchy. I would add that really it\'s a\n> > subset of the chapters (particularly compute and block storage) that\n> > aren\'t doing this already.\n> > \n> >> Personally I\'m OK with duplicating tables but it might be hard to get\n> >> this working in docbook, and even harder to convince everyone that\n> >> it\'s\n> >> a good idea (based on IRC discussions) ;)\n> > \n> > The reason I asked for IDs on these tables in the first place was so\n> > I could add a reference from the Libvirt/KVM hypervisor section to the\n> > relevant table and avoid duplicating it. I did not realize that we\n> > were already duplicating tables :/.\n> > \n> >> I like solution 3 because it provides a single page with all the\n> >> config\n> >> options, in which it\'s easy to search for what you need. The downside\n> >> (IMO) is that hyperlinks makes you jump back and forth between pages.\n> >> \n> >> So what do you think is the best option, or is there an other one we\n> >> didn\'t think of?\n> > \n> > I think that the problem we are having is that the config files\n> > driving the automation are \"flat\", as in the option groups are all on\n> > the same level:\n> > \n> > * api\n> > * apiv3\n> > * xen\n> > * hyperv\n> > * libvirt\n> > * spice\n> > * vnc\n> > \n> > There are some obvious logical groupings you can make here like \"api\n> > configuration\", \"hypervisor configuration\", and \"console\n> > configuration\". That\'s effectively what\'s being reflected in the\n> > manually handled hierarchy in the guide today for the minority of\n> > configuration groups where somebody took the time to write an overview\n> > of that component. I\'m wonder if the solution isn\'t something like the\n> > flag mappings file for the CLI where we manually map out the hierarchy\n> > we expect, obviously we\'d need to maintain it as new groups are added.\n> > \n> > The script would then generate both the tables (as it does today) and\n> > the top level files for the book itself that link the tables into the\n> > hierarchy, potentially with a xi:include to a predictable location for\n> > the overview for that group if one was written (we would place them\n> > into this location) and an xi:fallback to a known small/null snippet\n> > to catch cases where none exists (maybe even a call to action, know\n> > about this section? help us write an overview!).\n> \n> I think I like this option, but I\'m not sure I understand it fully...\n> Do you think you could provide a basic example of what you\'d expect to\n> see (only xi:include\'s and tables)?\n\nYeah, understand - I\'ll try dummy something up over the weekend. As I kind of alluded to in my email I think this would be something to bring to the summit and then discuss there for the Juno cycle rather than something to do now.\n\n-Steve\n\n\n\n\n','<634ac6f194b86e3e097f1d35ff5d7c76@objectif-libre.com>',NULL),('<160448242.32016329.1408117829372.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-15 11:50:29',-14400,'2014-08-15 15:50:29',NULL,'[openstack-dev] [all] The future of the integrated release','\n> But, if someone asked me what they should use for metering today,\n> I\'d point them towards Monasca in a heartbeat.\n\nFWIW my view is that Monasca is an interesting emerging project, with a\nteam accreting around it that seems to be interested in collaboration.\n\nWe\'ve had ongoing discussions with them about overlaps and differences\nsince the outset of this cycle, though of course our over-riding focus\nfor Juno has had to be on the TC gap analysis and on addressing\narchitectural debts.\n\nBut going forward into Kilo, I think there should be scope for possible\ncloser collaboration between the projects, figuring out the aspects that\nare complementary and possible shared elements and/or converged APIs.\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A52BF3E5@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1605228806.26676958.1407448874590.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 18:01:14',-14400,'2014-08-07 22:01:14',NULL,'[openstack-dev] introducing cyclops','\n\n\n> Dear All,\n> \n> Let me use my first post to this list to introduce Cyclops and initiate a\n> discussion towards possibility of this platform as a future incubated\n> project in OpenStack.\n> \n> We at Zurich university of Applied Sciences have a python project in open\n> source (Apache 2 Licensing) that aims to provide a platform to do\n> rating-charging-billing over ceilometer. We call is Cyclops (A Charging\n> platform for OPenStack CLouds).\n> \n> The initial proof of concept code can be accessed here:\n> https://github.com/icclab/cyclops-web &\n> https://github.com/icclab/cyclops-tmanager\n> \n> Disclaimer: This is not the best code out there, but will be refined and\n> documented properly very soon!\n> \n> A demo video from really early days of the project is here:\n> https://www.youtube.com/watch?v=ZIwwVxqCio0 and since this video was made,\n> several bug fixes and features were added.\n> \n> The idea presentation was done at Swiss Open Cloud Day at Bern and the talk\n> slides can be accessed here:\n> http://piyush-harsh.info/content/ocd-bern2014.pdf , and more recently the\n> research paper on the idea was published in 2014 World Congress in Computer\n> Science (Las Vegas), which can be accessed here:\n> http://piyush-harsh.info/content/GCA2014-rcb.pdf\n> \n> I was wondering, if our effort is something that OpenStack\n> Ceilometer/Telemetry release team would be interested in?\n> \n> I do understand that initially rating-charging-billing service may have been\n> left out by choice as they would need to be tightly coupled with existing\n> CRM/Billing systems, but Cyclops design (intended) is distributed, service\n> oriented architecture with each component allowing for possible integration\n> with external software via REST APIs. And therefore Cyclops by design is\n> CRM/Billing platform agnostic. Although Cyclops PoC implementation does\n> include a basic bill generation module.\n> \n> We in our team are committed to this development effort and we will have\n> resources (interns, students, researchers) work on features and improve the\n> code-base for a foreseeable number of years to come.\n> \n> Do you see a chance if our efforts could make in as an incubated project in\n> OpenStack within Ceilometer?\n\nHi Piyush,\n\nThanks for bringing this up!\n\nI should preface my remarks by setting out a little OpenStack\nhistory, in terms of the original decision not to include the\nrating and billing stages of the pipeline under the ambit of\nthe ceilometer project.\n\nIIUC, the logic was that such rating/billing policies were very\nlikely to be:\n\n  (a) commercially sensitive for competing cloud operators\n\nand:\n\n  (b) already built-out via existing custom/proprietary systems\n\nThe folks who were directly involved at the outset of ceilometer\ncan correct me if I\'ve misrepresented the thinking that pertained\nat the time.\n\nWhile that logic seems to still apply, I would be happy to learn\nmore about the work you\'ve done already on this, and would be\nopen to hearing arguments for and against. Are you planning to\nattend the Kilo summit in Paris (Nov 3-7)? If so, it would be a\ngood opportunity to discuss further in person.\n\nIn the meantime, stackforge provides a low-bar-to-entry for\nprojects in the OpenStack ecosystem that may, or may not, end up\nas incubated projects or as dependencies taken by graduated\nprojects. So you might consider moving your code there?\n\nCheers,\nEoghan\n\n\n \n> I really would like to hear back from you, comments, suggestions, etc.\n> \n> Kind regards,\n> Piyush.\n> _______________________________________\n> Dr. Piyush Harsh, Ph.D.\n> Researcher, InIT Cloud Computing Lab\n> Zurich University of Applied Sciences (ZHAW)\n> [Site] http://piyush-harsh.info\n> [Research Lab] http://www.cloudcomp.ch/\n> Fax: +41(0)58.935.7403 GPG Keyid: 9C5A8838\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CABZL8qNoAXzn_SHx-b_k9uaKq_tG7X6tMLux-YynKMf2vQccgA@mail.gmail.com>',NULL),('<1605271829.252532.1419261930342.JavaMail.yahoo@jws10917.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-22 15:25:30',0,'2014-12-22 15:25:30',NULL,'[Openstack] COnfiguration to setup basic cloud','Hi All, \n\nCurrently I trying to setup the following cloud setup. \nBefore I go further I just need to review the hardware configuration setup \n\nBasic requirement \n\nTotal 40 VMs\nHard Disk per user 10 to 50 GB\nRAM per VM 4 GB, dynamic max 12GB\nNetwork per VM 100Mbits/second per VM \nMAx req is 16GHz per VM\n\nSO I read openstack docs and Mirantis doc on this and cameup with this config \n\n\n1. CPU requirement \n\ntotal cores required 34 cores rounding it to 36 cores \n6 sockets containing 6 cores per socket \n1 CPU core with 2.4 GHz\n\nTotal number of CPU cores per VM = 5 \n\nTotal number of servers =3 ( 2 sockets per server).\n\nNumber of VM on single VM = 14 \n\n\n2. Memory requirement\n 40 VM\'s, 4 GB per VM, Min 512MB, Max 32GB? 160GB 0f totalmemory = 40 VM x 4 GB per VM?\n Consider Dynamicallocation of RAM upto 12GB for each VM it accounts to, consideringper server 14 VMS it requires 168 GB per server.\n3. Storage \nflat 2 TB disk 50GB per VM \nor with Redundancy wirh Raid \n4 TB ( 1TB of DISK each) with RAID 1, 5 or 10 \n4. Networking \nto get 100Mbits/second per VM \nUse Two 1 GB link per server.\nor use 10 Gig \n\nOn the switches 24 ports of 1 GB switch should be sufficient . \n\n\nCan I have this hosted as single Host machine. ?\nOr Is it better to have 3 servers. \nThis is just to start inhouse? project replication of data or controller failure is OK later need to scale it. \n\nPlease suggest if the above config is ok or any mis calculations? or may be better one. \n\nthanks in advance \n\n\nRegards\nNeelu ?\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141222/0b3d4eee/attachment.html>\n\n','<20141222140410.GL2497@yuggoth.org>',NULL),('<1605470810.25.1374473070718.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-22 06:04:30',0,'2013-07-22 06:04:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #294','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/294/>\n\n------------------------------------------\n[...truncated 9008 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.10 secs:\n    0.38    RoleAPITests.test_get_default_role\n    0.23    HorizonTests.test_lazy_urls\n    0.18    DataTableTests.test_summation_row\n    0.16    DataTableTests.test_table_action_attributes\n    0.15    NetworkTests.test_subnet_create_post_gw_inconsistent\n----------------------------------------------------------------------\nRan 350 tests in 7.294s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.19\npep8==1.4.6\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.1\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.uzFXHTD2wL\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/294\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/294/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/294/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<441854438.20.1374386691543.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1605580678.110.1384236131593.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-12 06:02:11',0,'2013-11-12 06:02:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #60','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/60/>\n\n------------------------------------------\n[...truncated 639 lines...]\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 11.212s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.16.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.60\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.4\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.8\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.ZtVLqDDCCs\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise40\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise40/60\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1606092538.17.1378016124850.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-01 06:15:24',0,'2013-09-01 06:15:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python26-stable-grizzly #8','See <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-grizzly/8/changes>\n\n\n\n','<1946344499.2.1377411554872.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1606726847.5.1386915480957.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-13 06:18:00',0,'2013-12-13 06:18:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-docs-grizzly #5','See <https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/5/>\n\n------------------------------------------\n[...truncated 210 lines...]\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_constants.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_credentials_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_exceptions.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_faults.rst\nGenerating doc/source/api/quantum.plugins.cisco.common.cisco_utils.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.api.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_db.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.l2network_models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.models.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_db_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.db.nexus_models_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._credential_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions._qos_view.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.credential.rst\nGenerating doc/source/api/quantum.plugins.cisco.extensions.qos.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2device_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.cisco.l2network_plugin_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.models.virt_phy_sw_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.network_plugin.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_configuration.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_network_driver_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_plugin_v2.rst\nGenerating doc/source/api/quantum.plugins.cisco.nexus.cisco_nexus_snippets.rst\nGenerating doc/source/api/quantum.plugins.cisco.run_tests.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_cisco_extension.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.test_database.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.nexus.fake_nexus_driver.rst\nGenerating doc/source/api/quantum.plugins.cisco.tests.unit.v2.test_api_v2.rst\nGenerating doc/source/api/quantum.plugins.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent.utils.rst\nGenerating doc/source/api/quantum.plugins.hyperv.agent_notifier_api.rst\nGenerating doc/source/api/quantum.plugins.hyperv.common.constants.rst\nGenerating doc/source/api/quantum.plugins.hyperv.db.rst\nGenerating doc/source/api/quantum.plugins.hyperv.hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.hyperv.model.rst\nGenerating doc/source/api/quantum.plugins.hyperv.rpc_callbacks.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.agent.linuxbridge_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.config.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.common.constants.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_db_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.db.l2network_models_v2.rst\nGenerating doc/source/api/quantum.plugins.linuxbridge.lb_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_db_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_models_v2.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.meta_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.proxy_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.metaplugin.run_tests.rst\nGenerating doc/source/api/quantum.plugins.midonet.config.rst\nGenerating doc/source/api/quantum.plugins.midonet.midonet_lib.rst\nGenerating doc/source/api/quantum.plugins.midonet.plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.agent.nec_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.nec.common.config.rst\nGenerating doc/source/api/quantum.plugins.nec.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nec.common.ofc_client.rst\nGenerating doc/source/api/quantum.plugins.nec.db.api.rst\nGenerating doc/source/api/quantum.plugins.nec.db.models.rst\nGenerating doc/source/api/quantum.plugins.nec.db.nec_plugin_base.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.pfc.rst\nGenerating doc/source/api/quantum.plugins.nec.drivers.trema.rst\nGenerating doc/source/api/quantum.plugins.nec.extensions.packetfilter.rst\nGenerating doc/source/api/quantum.plugins.nec.nec_plugin.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_driver_base.rst\nGenerating doc/source/api/quantum.plugins.nec.ofc_manager.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.NvpApiClient.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.QuantumPlugin.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.client_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.common.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.api_client.request_eventlet.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.check_nvp_config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.config.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.metadata_access.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.common.securitygroups.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_networkgw.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.extensions.nvp_qos.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_models.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_networkgw_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nicira_qos_db.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_cluster.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvp_plugin_version.rst\nGenerating doc/source/api/quantum.plugins.nicira.nicira_nvp_plugin.nvplib.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.agent.ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.config.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.common.constants.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_db_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_models_v2.rst\nGenerating doc/source/api/quantum.plugins.openvswitch.ovs_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.common.exceptions.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plugin_ver.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_nos_snippets.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.plumgrid_plugin.rst\nGenerating doc/source/api/quantum.plugins.plumgrid.plumgrid_nos_plugin.rest_connection.rst\nGenerating doc/source/api/quantum.plugins.ryu.agent.ryu_quantum_agent.rst\nGenerating doc/source/api/quantum.plugins.ryu.common.config.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.api_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.db.models_v2.rst\nGenerating doc/source/api/quantum.plugins.ryu.ryu_quantum_plugin.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.api.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.agent.manager.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.constants.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.cfg.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.drivers.haproxy.namespace_driver.rst\nGenerating doc/source/api/quantum.plugins.services.agent_loadbalancer.plugin.rst\nGenerating doc/source/api/quantum.plugins.services.service_base.rst\nGenerating doc/source/api/quantum.policy.rst\nGenerating doc/source/api/quantum.quantum_plugin_base_v2.rst\nGenerating doc/source/api/quantum.quota.rst\nGenerating doc/source/api/quantum.rootwrap.filters.rst\nGenerating doc/source/api/quantum.rootwrap.wrapper.rst\nGenerating doc/source/api/quantum.scheduler.dhcp_agent_scheduler.rst\nGenerating doc/source/api/quantum.scheduler.l3_agent_scheduler.rst\nGenerating doc/source/api/quantum.service.rst\nGenerating doc/source/api/quantum.tests.base.rst\nGenerating doc/source/api/quantum.tests.unit._test_extension_portbindings.rst\nGenerating doc/source/api/quantum.tests.unit._test_rootwrap_exec.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_restproxy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.bigswitch.test_router_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_db.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.brocade.test_brocade_vlan.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_network_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.cisco.test_nexus_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.database_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.db.loadbalancer.test_db_loadbalancer.rst\nGenerating doc/source/api/quantum.tests.unit.dummy_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.extension_stubs.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extendedattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.extensionattribute.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.foxinsocks.rst\nGenerating doc/source/api/quantum.tests.unit.extensions.v2attributes.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_quantum_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.hyperv.test_hyperv_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_db.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_lb_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_linuxbridge_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.linuxbridge.test_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.fake_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_basic.rst\nGenerating doc/source/api/quantum.tests.unit.metaplugin.test_metaplugin.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_lib.rst\nGenerating doc/source/api/quantum.tests.unit.midonet.test_midonet_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.stub_ofc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_agent.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_nec_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_ofc_manager.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_pfc_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.nec.test_trema_driver.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.fake_nvpapiclient.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_networkgw.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nicira_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvp_api_request_eventlet.rst\nGenerating doc/source/api/quantum.tests.unit.nicira.test_nvplib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_agent_scheduler.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_openvswitch_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_db.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_lib.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_quantum_agent.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_rpcapi.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.openvswitch.test_ovs_tunnel.rst\nGenerating doc/source/api/quantum.tests.unit.plumgrid.test_plumgrid_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.fake_ryu.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_defaults.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_agent.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_db.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.ryu.test_ryu_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_api.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_init.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.agent.test_manager.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_cfg.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.driver.haproxy.test_namespace_driver.rst\nGenerating doc/source/api/quantum.tests.unit.services.agent_loadbalancer.test_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ext_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_linux_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_netns_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_ovs_cleanup.rst\nGenerating doc/source/api/quantum.tests.unit.test_agent_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_api_common.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2.rst\nGenerating doc/source/api/quantum.tests.unit.test_api_v2_resource.rst\nGenerating doc/source/api/quantum.tests.unit.test_attributes.rst\nGenerating doc/source/api/quantum.tests.unit.test_auth.rst\nGenerating doc/source/api/quantum.tests.unit.test_common_utils.rst\nGenerating doc/source/api/quantum.tests.unit.test_config.rst\nGenerating doc/source/api/quantum.tests.unit.test_db.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_migration.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_db_rpc_base.rst\nGenerating doc/source/api/quantum.tests.unit.test_debug_commands.rst\nGenerating doc/source/api/quantum.tests.unit.test_dhcp_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extended_attribute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_extraroute.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_portsecurity.rst\nGenerating doc/source/api/quantum.tests.unit.test_extension_security_group.rst\nGenerating doc/source/api/quantum.tests.unit.test_extensions.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_firewall.rst\nGenerating doc/source/api/quantum.tests.unit.test_iptables_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_l3_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_daemon.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_dhcp.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_external_process.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_interface.rst\nGenerating doc/source/api/quantum.tests.unit.test_linux_ip_lib.rst\nGenerating doc/source/api/quantum.tests.unit.test_loadbalancer_plugin.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_agent.rst\nGenerating doc/source/api/quantum.tests.unit.test_metadata_namespace_proxy.rst\nGenerating doc/source/api/quantum.tests.unit.test_policy.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_context.rst\nGenerating doc/source/api/quantum.tests.unit.test_quantum_manager.rst\nGenerating doc/source/api/quantum.tests.unit.test_quota_ext.rst\nGenerating doc/source/api/quantum.tests.unit.test_rootwrap.rst\nGenerating doc/source/api/quantum.tests.unit.test_routerserviceinsertion.rst\nGenerating doc/source/api/quantum.tests.unit.test_security_groups_rpc.rst\nGenerating doc/source/api/quantum.tests.unit.test_servicetype.rst\nGenerating doc/source/api/quantum.tests.unit.test_wsgi.rst\nGenerating doc/source/api/quantum.tests.unit.testlib_api.rst\nGenerating doc/source/api/quantum.version.rst\nGenerating doc/source/api/quantum.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-neutron-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-grizzly/precise2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-docs-grizzly/precise2/5\n[SCP] Copying console log.\n\n\n','<1577487162.48.1386741890883.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1606806007.2819098.1416148046749.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-16 09:27:26',-18000,'2014-11-16 14:27:26',NULL,'[openstack-dev] [Ironic] A mascot for Ironic','\n\n----- Original Message -----\n> Hi Ironickers,\n> \n> I was thinking this weekend: All the cool projects does have a mascot\n> so I thought that we could have one for Ironic too.\n> \n> The idea about what the mascot would be was easy because the RAX guys\n> put \"bear metal\" their presentation[1] and that totally rocks! So I\n> drew a bear. It also needed an instrument, at first I thought about a\n> guitar, but drums is actually my favorite instrument so I drew a pair\n> of drumsticks instead.\n> \n> The drawing thing wasn\'t that hard, the problem was to digitalize it.\n> So I scanned the thing and went to youtube to watch some tutorials\n> about gimp and inkspace to learn how to vectorize it. Magic, it\n> worked!\n> \n> Attached in the email there\'s the original draw, the vectorized\n> version without colors and the final version of it (with colors).\n> \n> Of course, I know some people does have better skills than I do, so I\n> also attached the inkspace file of the final version in case people\n> want to tweak it :)\n> \n> So, what you guys think about making this little drummer bear the\n> mascot of the Ironic project?\n> \n\nTotally awesome.\n\n> Ahh he also needs a name. So please send some suggestions and we can\n> vote on the best name for him.\n> \n\nMetal is kind of obvious.\n\nWhat would it take for you to give Neutron a mascot as well? We need all\nthe PR we can get :)\n\n> [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90\n> \n> Lucas\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAB1EZBp11-TZAkWYWOyu_C--afb0rY2FkketHbVJ2QPNqO8a1A@mail.gmail.com>',NULL),('<1606858593.415.1367043165506.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:12:45',0,'2013-04-27 06:12:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric5 in workspace <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/>\nCheckout:periodic-quantum-python26-stable-grizzly / <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/> - hudson.remoting.Channel at 6ef1dd49:oneiric5\nUsing strategy: Default\nLast Built Revision: Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/quantum.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/quantum.git\nCommencing build of Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\nChecking out Revision 92c234b483504b6dc7bddd9338ad9a60dbb849b8 (origin/stable/grizzly)\n[periodic-quantum-python26-stable-grizzly] $ /bin/bash -xe /tmp/hudson1401868864514476744.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack quantum\n+ version=26\n+ org=openstack\n+ project=quantum\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.LkeVNjhw6c\n+ TMPDIR=/tmp/tmp.LkeVNjhw6c\n+ trap \'rm -rf /tmp/tmp.LkeVNjhw6c\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack quantum\n+ org=openstack\n+ project=quantum\n+ [[ -z openstack ]]\n+ [[ -z quantum ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' quantum == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.quantum.python26.stable.grizzly.17\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/test-requires\',> \'setuptools_git>=0.4\']\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-quantum-python26-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 48660 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-quantum-python26-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182612.323880-1683346245\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric5\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.LkeVNjhw6c\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-10-11\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'459c381c-d85c-474a-a06d-4cbe25875e4c\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'92c234b483504b6dc7bddd9338ad9a60dbb849b8\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric5\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 48660 166.78.48.43 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking setuptools-git>=0.4\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement setuptools-git>=0.4\nNo distributions at all found for setuptools-git>=0.4\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/ws/tools/test-requires,> setuptools_git>=0.4]\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.LkeVNjhw6c\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/17\n[SCP] Copying console log.\n\n\n','<1115173206.356.1366958797088.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1607145665.577923.1374479743814.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-22 09:55:43',7200,'2013-07-22 07:55:43',NULL,'[openstack-dev] Change in openstack/neutron[master]: Add method\n to get iptables traffic counters','Hi Brian,\n\nThanks for your reply.\n\n> 1. This isn\'t something a tenant should be able to do, so should be admin-only,\n> correct?\n\nCorrect.\n\n> 2. I think it would be useful for an admin to be able to add metering rules for\n> all tenants with a single command.  This gets back to wanting to pre-seed an ini\n> file with a set of subnets, then add/subtract from it later without restarting\n> the daemon.\n\nI agree with you, could be a future enhancement.\n\n> 3. I think it would be better if you didn\'t mark the packets, for performance\n> reasons.  If you were marking them on input to be matched by something on output\n> I\'d feel different, but for just counting bytes we should be able to do it\n> another way.  I can get back to you next week on figuring this out.\n\nOk, I\'ll take a look too.\n\nThanks.\n\nSylvain.\n\n----- Original Message -----\nFrom: \"Brian Haley\" <brian.haley at hp.com>\nTo: \"Sylvain Afchain\" <sylvain.afchain at enovance.com>\nCc: openstack-dev at lists.openstack.org\nSent: Friday, July 19, 2013 11:47:41 PM\nSubject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters\n\nHi Sylvain,\n\nSorry for the slow reply, I\'ll have to look closer next week, but I did have\nsome comments.\n\n1. This isn\'t something a tenant should be able to do, so should be admin-only,\ncorrect?\n\n2. I think it would be useful for an admin to be able to add metering rules for\nall tenants with a single command.  This gets back to wanting to pre-seed an ini\nfile with a set of subnets, then add/subtract from it later without restarting\nthe daemon.\n\n3. I think it would be better if you didn\'t mark the packets, for performance\nreasons.  If you were marking them on input to be matched by something on output\nI\'d feel different, but for just counting bytes we should be able to do it\nanother way.  I can get back to you next week on figuring this out.\n\nThanks,\n\n-Brian\n\nOn 07/18/2013 04:29 AM, Sylvain Afchain wrote:\n> Hi Brian,\n> \n> For iptables rules, see below\n> \n> Yes the only way to setup metering labels/rules is the neutronclient. I agree with you about the future\n> enhancement.\n> \n> Regards,\n> \n> Sylvain\n> \n> ----- Original Message -----\n> From: \"Brian Haley\" <brian.haley at hp.com>\n> To: \"Sylvain Afchain\" <sylvain.afchain at enovance.com>\n> Cc: openstack-dev at lists.openstack.org\n> Sent: Thursday, July 18, 2013 4:58:26 AM\n> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters\n> \n>> Hi Sylvain,\n>>\n>> I think I\'ve caught-up with all your reviews, but I still did have some\n>> questions on the iptables rules, below.\n>>\n>> One other question, and maybe it\'s simply a future enhancement, but is the only\n>> way to setup these meters using neutronclient?  I think being able to specify\n>> these in an .ini file would be good as well, which is something I\'d want to do\n>> as a provider, such that they\'re always there, and actually not visible to the\n>> tenant.\n>>\n>> On 07/11/2013 10:04 AM, Sylvain Afchain wrote:\n>>> Hi Brian,\n>>>\n>>> You\'re right It could be easier with your approach to get and keep the traffic counters.\n>>>\n>>> I will add a new method to get the details of traffic counters of a chain.\n>>> https://review.openstack.org/35624\n>>>\n>>> Thoughts?\n>>>\n>>> Regards,\n>>>\n>>> Sylvain.\n>>>\n>>> ----- Original Message -----\n>>> From: \"Sylvain Afchain\" <sylvain.afchain at enovance.com>\n>>> To: \"Brian Haley\" <brian.haley at hp.com>\n>>> Cc: openstack-dev at lists.openstack.org\n>>> Sent: Thursday, July 11, 2013 11:19:39 AM\n>>> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters\n>>>\n>>> Hi Brian,\n>>>\n>>> First thanks for the reviews and your detailed email.\n>>>\n>>> Second I will update the blueprint specs. as soon as possible, but for example it will look like that:\n>>>\n>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)\n>>>     pkts      bytes target     prot opt in     out     source               destination         \n>>>        55       245 metering-r-aef1456343  all  --  *      *       0.0.0.0/0            0.0.0.0/0   /* jump to rules the label aef1456343 */        \n>>>        55       245 metering-r-badf566782  all  --  *      *       0.0.0.0/0            0.0.0.0/0           \n> \n>> So are these two used to separate out what you don\'t want to count from what you\n>> want to count?  Seems the jump to the r-aef1456343 will filter, then the\n>> r-badf566782 will count per-subnet?  I\'m just trying to understand why you\'re\n>> splitting the two up.\n> \n> No here, there are two rules only because there are two labels. In the chain of each \n> label you will find the label\'s rules. \n> \n>>> Chain metering-l-aef1456343 (1 references)	/* the chain for the label aef1456343 */\n>>>     pkts      bytes target     prot opt in     out     source               destination         \n>>>\n>>> Chain metering-l-badf566782 (1 references)	/* the chain for the label badf566782 */\n>>>     pkts      bytes target     prot opt in     out     source               destination      \n> \n>> These two chains aren\'t really doing anything, and I believe their packet/byte\n>> counts would be duplicated in the calling rules, correct?  If that\'s the case I\n>> don\'t see the reason to jump to them.  Our performance person always reminds me\n>> when I increase path length by doing things like this, so removing unnecessary\n>> things is one of my goals.  Of course we\'re doing more work here to count\n>> things, but that needs to be done.\n> \n> I recently change this(according to your remarks on iptables accounting), so now there is a \n> rule which is used to count the traffic for a label. A mark is added one this rule to be \n> sure to not count it twice. You can check the metering iptables drivers.\n> https://review.openstack.org/#/c/36813/\n> \n>>> Chain metering-r-aef1456343 (1 references)\n>>>     pkts      bytes target     prot opt in     out     source               destination         \n>>>        20     100 RETURN     all  --  *      *       0.0.0.0/0           !10.0.0.0/24      /* don\'t want to count this traffic */   \n>>>        0        0 RETURN     all  --  *      *       0.0.0.0/0           !20.0.0.0/24      /* don\'t want to count this traffic */   \n>>>        25      145 metering-l-aef1456343  all  --  *      *       0.0.0.0/0            0.0.0.0/0	/* count the remaining traffic */     \n> \n>> This has excluded (!) certain subnets, then allowed anything else to pass through.\n> \n> Correct, I don\'t want to count the traffic in/out for these network and I want to count anything else.\n> \n>>> Chain metering-r-badf566782 (1 references)\n>>>     pkts      bytes target     prot opt in     out     source               destination         \n>>>        0        0 metering-l-badf56678  all  --  *      *       0.0.0.0/0            30.0.0.0/24 /* want to count only this */\n> \n>> This is only counting packets going to a certain subnet.\n> \n> Correct.\n> \n>> I\'m still trying to get all these changes running in devstack, so sorry for all\n>> the questions.\n> \n> No problem, and thanks for your reviews.\n> \n> Sylvain.\n> \n>> Thanks,\n> \n>> -Brian\n> \n>>\n>> Of course the in/out interfaces will be set in order to get the ingress or the egress traffic.\n>>\n>> I agree with you I could add a single rule to the chain of the label and get the traffic of the first entry, though I found this approach less generic. \n>> I mean, to be forced to add a rule at the top of a chain to get its traffic. My approach is I don\'t want the counters of a specific rule but I want to count\n>> the traffic going through the chain.\n>>\n>> Thoughts?\n>>\n>> Regards,\n>>\n>> Sylvain.\n>>\n>> ----- Original Message -----\n>> From: \"Brian Haley\" <brian.haley at hp.com>\n>> To: \"sylvain afchain\" <sylvain.afchain at enovance.com>\n>> Cc: openstack-dev at lists.openstack.org\n>> Sent: Thursday, July 11, 2013 2:30:24 AM\n>> Subject: Re: Change in openstack/neutron[master]: Add method to get iptables traffic counters\n>>\n>> On 07/08/2013 01:10 PM, Sylvain Afchain (Code Review) wrote:\n>>> Sylvain Afchain has posted comments on this change.\n>>>\n>>> Change subject: Add method to get iptables traffic counters\n>> <snip>\n>>> --\n>>> To view, visit https://review.openstack.org/35624\n>>\n>> Hi Sylvain,\n>>\n>> Instead of trying to ask questions directly in the review itself (since it will mess-up formatting) I\'ll just send this to you and the list since I had some questions on the traffic counter changes you\'ve been doing.\n>>\n>> First, thanks for working on this, it\'s definitely something I\'m interested in, and I\'m trying to review all your changes.\n>>\n>> Second, do you have more than just the short description from the blueprint for how the iptables chains/rules will look like when created?  I\'m still a little confused with this change (above) and how it\'s matching chains to get packet/byte statistics.  I\'m thinking it can be done within a single chain so that you can do an \'iptables -L $chain\' call to get just what you need, instead of parsing the entire table.\n>>\n>> For example, I did something similar in Nova (out of tree), and it used a single chain per-VM, such that you could get it\'s statistics with a single iptables call like:\n>>\n>> (sorry if this wraps)\n>> $ sudo iptables -t mangle -L nova-meter-output-91 -n -v -x [-Z]\n>> Chain nova-meter-output-91 (1 references)\n>>     pkts      bytes target     prot opt in     out     source               destination         \n>>   805210 247931149            all  --  *      *       0.0.0.0/0            0.0.0.0/0        /* inst-91 packets transmitted total */ \n>>    15510   964648             all  --  *      *       0.0.0.0/0            x.y.0.0/16\n>>    21282  3075403             all  --  *      *       0.0.0.0/0            x.z.0.0/16\n>>    [...]\n>>\n>> None of the rules in the chain has a jump target, so they simply count packets/bytes as they pass through, and the chain is called from a single location based on IP address, so in iptables-save format it looks like this:\n>>\n>> -A nova-meter-output -s $my_ip/32 -i bridge1 -j nova-meter-output-91 \n>> -A nova-meter-output-91 -m comment --comment \"inst-91 packets transmitted total\"\n>> -A nova-meter-output-91 -d x.y.0.0/16\n>> -A nova-meter-output-91 -d x.z.0.0/16\n>> [...]\n>>\n>> Obviously with Neutron, and doing this at the router egress, things change, but I think it could still be done in a single OUTPUT chain in the filter table.\n>>\n>> Thoughts?\n>>\n>> -Brian\n>>\n> \n\n\n\n','<51E9B3FD.7080702@hp.com>',NULL),('<1607976252.22309947.1379353381411.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-16 13:43:01',-14400,'2013-09-16 17:43:01',NULL,'[openstack-dev] Issues with IPTables','Here you go.  Keep in mind that I structured them more like their own install guide.  Basic tweaks were integrated into the steps, but larger issues are noted at the bottom under the \"notes\" section.\n\nBest Regards,\nSolly Ross\n\n\n----- Original Message -----\nFrom: \"Qing He\" <Qing.He at radisys.com>\nTo: \"Solly Ross\" <sross at redhat.com>\nCc: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, September 16, 2013 1:37:02 PM\nSubject: RE: Issues with IPTables\n\nSolly,\nIt would be great if you can share the notes.  The reason I asked the question is that I\'m trying to decide If I need to allocate development time in installation following the installation guide. The usual wisdom is that installation with detailed instruction would \"take no time\". However, your experience and mine showed the contrary. I have not finished mine following the Ubuntu installation guide. Thus, I was interested in knowing your effort spent on it so that I would know that it was not just me who had issues with the supposedly \"plug and play\" installation with the packages.\nThanks,\nQing\n\n-----Original Message-----\nFrom: Solly Ross [mailto:sross at redhat.com] \nSent: Monday, September 16, 2013 10:24 AM\nTo: Qing He\nCc: OpenStack Development Mailing List\nSubject: Re: Issues with IPTables\n\nQuite a while.  RDO\'s documentation for configuring multinode Packstack with Neutron was a bit lacking, so after attempting to get that working for a while, I switched to following the Basic Install Guide (http://docs.openstack.org/trunk/basic-install/content/basic-install_intro.html).  I also found the basic install guide catered for Fedora (http://docs.openstack.org/trunk/basic-install/yum/content/basic-install_intro.html), but that is sorely lacking in the actual instruction department, and is missing several steps.\n\nIf you would like, I can attach the raw draft of my notes.  Eventually, some of the changes or clairifications should make their way into the actual OpenStack Docs.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Qing He\" <Qing.He at radisys.com>\nTo: sross at redhat.com\nSent: Monday, September 16, 2013 1:14:42 PM\nSubject: RE: Issues with IPTables\n\nSolly,\nA side question, how long did this process take you?\n\nThanks,\n\nQing\n\n-----Original Message-----\nFrom: Solly Ross [mailto:sross at redhat.com] \nSent: Monday, September 16, 2013 10:11 AM\nTo: OpenStack Development Mailing List\nSubject: [openstack-dev] Issues with IPTables\n\nIn a enfort to improve/verify the Openstack Documentation with regards to RHEL and Fedora, I\'ve been attempting to follow the basic install guides.  I\'ve managed to create a working installation and set of instructions.  However, to do so I needed to disable the Neutron IPTables firewall, as it was blocking non-VM traffic.  Namely, it was blocking the GRE packets being used by Neutron.  Did I miss something, or is this a bug?\n\nBest Regards,\nSolly Ross\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn embedded and charset-unspecified text was scrubbed...\nName: notes-neutron-from-scratch2.txt\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130916/f0904c9c/attachment.txt>\n\n','<30a504f6912a4f8d90201bca9ba205fd@BL2PR08MB051.namprd08.prod.outlook.com>',NULL),('<1608077116.42.1385965782154.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-02 06:29:41',0,'2013-12-02 06:29:41',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #7','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/7/>\n\n------------------------------------------\n[...truncated 20904 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  188.054\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           96.247\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  78.656\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                47.654\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     39.988\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             39.547\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        37.389\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       35.054\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         34.336\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    34.259\n\n----------------------------------------------------------------------\nRan 1340 tests in 1288.852s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-768247-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-768247.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-768247/7/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1793039459.34.1385706557291.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1608823.1578.1391013688600.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-29 08:41:13',-28800,'2014-01-29 16:41:13',NULL,'[openstack-dev] [neutron] [policy] More conflict resolution','Hi Manuel,\n\nResponses inline.  Thanks for the feedback!\n\n----- Original Message -----\n| From: \"Manuel Stein (Manuel)\" <manuel.stein at alcatel-lucent.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Friday, January 24, 2014 2:03:43 AM\n| Subject: Re: [openstack-dev] More conflict resolution\n| \n| Tim,\n| \n| w.r.t. different tenants I might be missing something - why should\n| policies remain stored per-user? In general, when the user creates\n| something, wouldn\'t the user\'s policies (more like\n| preferences/template) be applied to and saved for the tenant/created\n| elements they\'re active in? IMHO you can\'t solve the policy\n| anomalies when you don\'t know yet whether they\'ll ever be applied to\n| the same entity or never actually conflict.\n\nEach policy has a src and destination group to which it applies.  Groups include apps, VMs, logical ports, or whatever.  Group membership can change.  Because groups are dynamic it may be that at the time the policy is written there are no conflicts but that as elements are added to the groups, conflicts arise.  And since each policy only applies to some packets, there can be conflicts for some communications and not others.\n\n| \n| FYI: Ehab Al-Shaer (UNCC) is well known in IEEE regarding policies\n| and has formalized policy anomalies and investigated their\n| detection, also in distributed systems.\n\nThanks for the pointer.  I quickly perused his publication list and will return to it when I have more time to browse.\n\n| \n| The scenarios in 1) could be solved with priorities and different\n| corrective actions.\n| I\'d say an admin rule has a higher priority than the non-admin one,\n| in which case both should be informed about the precedence taken.\n| The cases user-vs-user and admin-vs-admin shouldn\'t allow to apply\n| conflicting rules on the same entity. Two admins share the\n| responsibility within a tenant/project and rules should be visible\n| to one another. Same for the user group. I wouldn\'t know how to deal\n| with \"hidden\" user-specific rules that somehow interfere with and\n| shadow my already applied policies.\n\nPriorities seem like the right solution for admin-tenant conflicts.  Are there any other roles that should have priorities?\n\nI think that disallowing conflicting policies is a bit difficult, esp in the tenant-tenant case b/c the two tenants may not know each other.  It might be disconcerting for a tenant to have her policy rejected b/c someone she didn\'t know wrote a policy she\'s not allowed to see that may potentially conflict with her policy at some point in the future.  An alternative to disallowing conflicting policies from is to combine the policies of the same priority into a single policy (conceptually) and then apply the conflict-resolution scheme for that single policy.   Thoughts?\n\n| \n| as of 2) at creation or runtime\n| Either way you\'d want a policy anomaly detected at creation, i.e.\n| when a user\'s rule is applied. Either the new rule\'s priority is\n| lower and hence shadowed by the higher priority or the new rule\'s\n| priority is higher and supersedes actions of another. In either case\n| you\'d want the anomaly detected and corrective action taken at the\n| time it is applied (Supersede and email the non-admin, report the\n| user which rules shadow/generalize which, etc, etc). The\n| conflicts/status (overruled/active/etc) should be part of the\n| applied rules set.\n\nWhat if the rules only conflict sometimes (e.g. for some packets), e.g. one policy says to ALLOW packets with dest port 80 and another rule says to DROP packets with src port 80.  For most packets, there\'s no conflict, but if the dest-port is 80 and the src-port is 80, then there\'s a conflict.  So (a) it\'s not as simple as marking a rule as overruled/active/etc., (b) computationally it may be non-trivial to identify rules that sometimes conflict, and (c) the users writing the policies may know that the packets that cause conflicts will never appear in the network.\n\n| \n| as of 3) role changes\n| my gut feeling was to say that rules keep their priorities, because\n| they\'ve been made by an admin/non-admin at that time. The\n| suddenly-an-admin user could remove the shadowing rules if it bugs\n| the user-rules.\n\nRole changes are complicated for 2 reasons: (i) we need to have a way of finding out about them and (ii) once we have the information we need to decide what to do with it.  Any thoughts on how to accomplish (i)?\n\nAs for (ii), I worry about leaving rule priorities as they were before the role change because the whole purpose of a role change is to change someone\'s rights.  If someone was an admin and were demoted for questionable behavior, leaving their policies in the admin priority seems like a mistake.  At the same time, re-prioritizing the rules for role changes could cause drastic behavioral changes in the network.  If a regular user\'s policies are all suddenly promoted to admin priority, no one will be able to predict how the policy changes will affect the network.  Demoting admin rules to non-admin priority has a similar effect.  Hmmm... leaving the priorities the same seems problematic, but changing the priorities seems problematic too; not sure what to do here.\n\nTim\n\n| \n| my 2 cents,\n| Manuel\n| ________________________________________\n| From: Tim Hinrichs [thinrichs at vmware.com]\n| Sent: Thursday, January 23, 2014 6:57 PM\n| To: OpenStack Development Mailing List (not for usage questions)\n| Subject: [openstack-dev] [neutron] [policy] More conflict resolution\n| \n| Hi all,\n| \n| Today on the Neutron-policy IRC, we ran into some issues that we\n| wanted all your feedback on (and as I was writing this note several\n| more occurred to me). It\'s the problem of conflict resolution:\n| different policies making different decisions about what to do.  We\n| have a conflict resolution scheme for when conflicts arise within a\n| single policy, but we have yet to solve the problem of conflicts\n| arising because different policies make different decisions.  The\n| important thing to know is that each policy is attached to a tenant\n| (and a single tenant can have multiple policies).\n| \n| 1) We need conflict resolution for the following scenarios.\n|  Suggestions?\n| \n| - Two policies for a single tenant have a conflict.\n| \n| - Two policies for different tenants with different Keystone roles\n| have a conflict.  For example, we expect that admin policies should\n| supersede non-admin policies (i.e. that if the admin policy makes a\n| decision to either allow or drop a packet, then the non-admin\'s\n| policy is ignored; otherwise, the non-admin\'s policy makes the final\n| decision).  Are there other roles we need to think about?\n| \n| - Two policies for different tenants with the same Keystone roles\n| have a conflict.  For example, if there are two admins whose\n| policies conflict, which one wins?\n| \n| 2) Do we perform conflict resolution at the time policies are created\n| (i.e. at the API level) or do we resolve conflicts more dynamically\n| at run-time?\n| \n| To me, API-level conflict resolution doesn\'t seem like a good option.\n|  Suppose a non-admin writes a perfectly reasonable policy.  Then a\n| month later an admin writes a policy that conflicts with the\n| non-admin policy.  There\'s no way to reject the non-admin\'s policy\n| at this point (and we can\'t reject the admin\'s policy).  It seems\n| the best we can do is inform the non-admin (via email?) that her\n| policy has been overruled.  But if we do that, it may be possible\n| for a tenant to learn what the admin\'s policy is--whether that is a\n| security problem or not I don\'t know.\n| \n| 3) What do we do when roles change, e.g. a non-admin user gets\n| promoted to an admin user or vice versa?  And how do we find out\n| about role changes if the users do not log in after their policies\n| have been created?  That is, role-changes seem to affect the overall\n| policy that is enforced at any point in time and thus role-changes\n| ought to be factored into policy enforcement.\n| \n| Role-changes make me even more dubious that API-level conflict\n| resolution is a good choice.\n| \n| \n| Hopefully that\'s a reasonable summary.  Others will chime in where\n| not.\n| \n| Thoughts?\n| Thanks,\n| Tim\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=GCQOsyh5WyZr4Lx2t%2Bs5Kt6S9fWkBV9dfeL%2B1xUUBag%3D%0A&s=c06f67fbd826026f4abc79fda10240d25bd756e237f4c121a43e06de8cdfc5e1\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=GCQOsyh5WyZr4Lx2t%2Bs5Kt6S9fWkBV9dfeL%2B1xUUBag%3D%0A&s=c06f67fbd826026f4abc79fda10240d25bd756e237f4c121a43e06de8cdfc5e1\n| \n\n\n','<DA6B6F4B7F698F41AA16462C9FA24F2E0D176D@FR712WXCHMBA16.zeu.alcatel-lucent.com>',NULL),('<1609126248.56.1386742734535.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-11 06:18:54',0,'2013-12-11 06:18:54',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-dsvm-stress-havana #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-stress-havana/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827420 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-stress-havana/ws/>\n[periodic-tempest-dsvm-stress-havana] $ /bin/bash -xe /tmp/hudson3732281941892612546.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: RPC failed; result=7, HTTP code = 0\nfatal: The remote end hung up unexpectedly\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-stress-havana/devstack-precise-hpcloud-az2-827420\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-stress-havana/devstack-precise-hpcloud-az2-827420/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1609321292.26.1383114732387.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-30 06:32:12',0,'2013-10-30 06:32:12',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #47','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/47/>\n\n------------------------------------------\n[...truncated 21088 lines...]\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_class_show ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_defaults ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_service_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_transfer_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  181.476\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           99.162\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  66.789\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     41.109\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       41.013\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     38.712\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        36.430\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      36.145\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       35.805\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]          34.662\n\n----------------------------------------------------------------------\nRan 1408 tests in 1402.273s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-619222-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-619222.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-619222/47/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1378310367.23.1383028266795.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<160940869.427.1355444168298.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-14 00:16:08',0,'2012-12-14 00:16:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #74','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/74/>\n\n\n\n','<1085035552.414.1355357675395.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<160EB9A8-69C8-4C6C-9D25-3D8C9D56D247@cloudbasesolutions.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-16 05:19:30',0,'2013-10-16 05:19:30',NULL,'[openstack-dev] Hyper-V meeting Minutes','\n\n\nOn Oct 16, 2013, at 02:36 , Sean Dague <sean at dague.net<mailto:sean at dague.net>> wrote:\n\nOn 10/15/2013 04:54 PM, Vishvananda Ishaya wrote:\nHi Everyone,\n\nI\'ve been following this conversation and weighing the different sides. This is a tricky issue but I think it is important to decouple further and extend our circle of trust.\n\nWhen nova started it was very easy to do feature development. As it has matured the pace has slowed. This is expected and necessary, but we periodically must make decoupling decisions or we will become mired in overhead. We did this already with cinder and neutron, and we have discussed doing this with virt drivers in the past.\n\nWe have a large number of people attempting to contribute to small sections of nova and getting frustrated with the process.  The perception of developers is much more important than the actual numbers here. If people are frustrated they are disincentivized to help and it hurts everyone. Suggesting that these contributors need to learn all of nova and help with the review queue is silly and makes us seem elitist. We should make it as easy as possible for new contributors to help.\n\nI think our current model is breaking down at our current size and we need to adopt something more similar to the linux model when dealing with subsystems. The hyper-v team is the only one suggesting changes, but there have been similar concerns from the vmware team. I have no doubt that there are similar issues with the PowerVM, Xen, Docker, lxc and even kvm driver contributors.\n\nThe Linux kernel process works for a couple of reasons...\n\n1) the subsystem maintainers have known each other for a solid decade (i.e. 3x the lifespan of the OpenStack project), over a history of 10 years, of people doing the right things, you build trust in their judgment.\n\n*no one* in the Linux tree was given trust first, under the hope that it would work out. They had to earn it, hard, by doing community work, and not just playing in their corner of the world.\n\n2) This http://www.wired.com/wiredenterprise/2012/06/torvalds-nvidia-linux/ is completely acceptable behavior. So when someone has bad code, they are flamed to within an inch of their life, repeatedly, until they never ever do that again. This is actually a time saving measure in code review. It\'s a lot faster to just call people idiots then to help them with line by line improvements in their code, 10, 20, 30, or 40 iterations in gerrit.\n\nWe, as a community have decided, I think rightly, that #2 really isn\'t in our culture. But you can\'t start cherry picking parts of the Linux kernel community without considering how all the parts work together. The good and the bad are part of why the whole system works.\n\nIn my opinion, nova-core needs to be willing to trust the subsystem developers and let go of a little bit of control. I frankly don\'t see the drawbacks.\n\nI actually see huge draw backs. Culture matters. Having people active and willing to work on real core issues matter. The long term health of Nova matters.\n\nAs the QA PTL I can tell you that when you look at Nova vs. Cinder vs. Neutron, you\'ll see some very clear lines about how long it takes to get to the bottom of a race condition, and how many deep races are in each of them. I find this directly related to the stance each project has taken on whether it\'s socially acceptable to only work on your own vendor code. Nova\'s insistence up until this point that if you only play in your corner, you don\'t get the same attention is important incentive for people to integrate and work beyond just their boundaries. I think diluting this part of the culture would be hugely detrimental to Nova.\n\nLet\'s take an example that came up today, the compute_diagnostics API. This is an area where we\'ve left it completely to the virt drivers to vomit up a random dictionary of the day for debugging reasons, and stamped it as an API. With a model where we let virt driver authors go hide in a corner, that\'s never going to become an API with any kind of contract, and given how much effort we\'ve spent on ensuring RPC versioning and message formats, the idea that we are exposing a public rest endpoint that\'s randomly fluctuating data based on date and underlying implementation, is a bit saddening.\n\nI\'m leaning towards giving control of the subtree to the team as the best option because it is simple and works with our current QA system. Alternatively, we could split out the driver into a nova subproject (2 below) or we could allow them to have a separate branch and do a trusted merge of all changes at the end of the cycle (similar to the linux model).\n\nI hope we can come to a solution to the summit that makes all of our contributors want to participate more. I believe that giving people more responsibility inspires them to participate more fully.\n\nI would like nothing more than all our contributors to participate more. But more has to mean caring about not only your stuff.\n\nI was called out today in the hyper-v meeting because I had the audacity to -1 a hyper-v patch because I wanted some reference in the code somewhere to format references so why we had some new random seek call would be understood by people down the road - http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-15-16.03.log.html\n\n\nSean, you got \"called out\" in the meeting not because you asked to put a refernce link to the specs which was perfectly reasonable, but because after we did what you asked for in a timely manner, you didn\'t bother to review the patch again until asked to please review it 6 days later!!!\n\nThis is a perfect example about why we need autonomy. We cannot leave a patch starving in the review queue for a critical bug like that one!!\n\n\nAs OpenStack grows, the single biggest factor in it\'s success isn\'t going to be a feature in a driver, it\'s going to be if this crazy complicated system holds together. Whether or not we\'ve got a handle on the emergent behavior that happens in an asynchronous message based system, with 10s of integrated projects, and many dozens of daemons cross talking with each other.\n\nI mean seriously, one of the only reasons we made it through to Havana RC phase is because we built a search engine based system to build statistical frequency analysis of unique failures on our gate resets to fully expose the top race conditions that had gotten so bad the gate basically locked up. And a bunch of people went all hands on deck to drive these out. People jumped across normal project lines to help on some of these top bugs, because that\'s what makes OpenStack a whole system.\n\nThings actually looked *really* bleak for release for a while. All the people that helped out and got us through this deserve a huge pat on the back. That\'s what OpenStack is about.\n\nSo I feel pretty strongly that optimizing the contribution process for people that aren\'t helping with that larger problem, is the tragedy of the commons, and I think entirely the wrong optimization to be made.\n\n   -Sean\n\n--\nSean Dague\nhttp://dague.net\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/b4e23be7/attachment.html>\n\n','<525DD163.4060102@dague.net>',NULL),('<1610305702.28543890.1406745671283.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-30 14:41:11',-14400,'2014-07-30 18:41:11',NULL,'[openstack-dev] [NFV] Ready to change the meeting time?','----- Original Message -----\n> From: \"Isaku Yamahata\" <isaku.yamahata at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> \n> Hi Steve.\n> \n> The timeslot of 5:00AM UTC(Tuesday) 30min clashes with it.\n> https://wiki.openstack.org/wiki/Meetings/ServiceVM\n> Please disable this time slot.\n> \n> thanks,\n\nHi Isaku,\n\nWhen I go to the link ( http://whenisgood.net/exzzbi8 ) and select GMT this time is already filtered out/disabled?\n\nThanks,\n\nSteve\n\n> On Tue, Jul 29, 2014 at 10:53:21AM -0400,\n> Steve Gordon <sgordon at redhat.com> wrote:\n> \n> > Hi all,\n> > \n> > I have recently had a few people express concern to me that the current\n> > meeting time is preventing their attendance at the meeting. As we\'re still\n> > using the original meeting time we discussed using for a trial period\n> > immediately after summit it is probably time we reassess anyway.\n> > \n> > I have been through the global iCal [1] and tried to identify times where\n> > at least one of the IRC meeting rooms is available and no other NFV\n> > related team or subteam (E.g. Nova, Neutron, DVR, L3, etc.) is meeting.\n> > The resultant times are available for voting on this whenisgood.net sheet\n> > - be sure to select your location to view in your local time:\n> > \n> >     http://whenisgood.net/exzzbi8\n> > \n> > If you are a regular participant in the NFV meetings, or even more\n> > importantly if you would like to be but are restrained from doing so\n> > because of the current timing then please record your preferences above.\n> > If you think there is an available time slot that I\'ve missed, or I\'ve\n> > made a time slot available that actually clashes with a meeting relevant\n> > to NFV participants, then please respond on list!\n> > \n> > This week\'s meeting will proceed at the regular time on Wednesday, July 30\n> > at 1400 UTC in #openstack-meeting-alt.\n> > \n> > Thanks,\n> > \n> > Steve\n> > \n> > [1]\n> > https://www.google.com/calendar/ical/bj05mroquq28jhud58esggqmh4 at group.calendar.google.com/public/basic.ics\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> --\n> Isaku Yamahata <isaku.yamahata at gmail.com>\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<20140730054220.GA15844@private.email.ne.jp>',NULL),('<1610748942.28443701.1403084700384.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-18 05:45:00',-14400,'2014-06-18 09:45:00',NULL,'[OpenStack-Infra] Status of check-tempest-dsvm-f20 job','\n\n> On 06/18/2014 06:46 PM, Eoghan Glynn wrote:\n> > If we were to use f20 more widely in the gate (not to entirely\n> > supplant precise, more just to split the load more evenly) then\n> > would the problem observed tend to naturally resolve itself?\n> \n> I would be happy to see that, having spent some time on the Fedora\n> bring-up :) However I guess there is a chicken-egg problem with\n> large-scale roll-out in that the platform isn\'t quite stable yet.\n> We\'ve hit some things that only really become apparent \"in the wild\";\n> differences between Rackspace & HP images, issues running on Xen which\n> we don\'t test much, the odd upstream bug requiring work-arounds [1],\n> etc.\n\nFair point.\n \n> It did seem that devstack changes was the best place to stabilze the\n> job.  However, as is apparent, devstack changes often need to be\n> pushed through quickly and that does not match well with a slightly\n> unstable job.\n> \n> Having it experimental in devstack isn\'t much help in stabilizing.  If\n> I trigger experimental builds for every devstack change it runs\n> several other jobs too, so really I\'ve just increased contention for\n> limited resources by doing that.\n\nVery true also.\n\n> I say this *has* to be running for devstack eventually to stop the\n> fairly frequent breakage of devstack on Fedora, which causes a lot of\n> people wasted time often chasing the same bugs.\n\nI agree, if we\'re committed to Fedora being a first class citizen (as\nper TC distro policy, IIUC) then it\'s crucial that Fedora-specific\nbreakages are exposed quickly in the gate, as opposed to being seen\nby developers for the first time in the wild whenever they happen to\nrefresh their devstack.\n\n> But in the mean time, maybe suggestions for getting the Fedora job\n> exposure somewhere else where it can brew and stabilize are a good\n> idea.\n\nWell, I would suggest the ceilometer/py27 unit test job as a first\ncandidate for such exposure.\n\nThe reason being that mongodb 2.4 is not available on precise, but\nis on f20. As a result, the mongodb scenario tests are effectively\nskipped in the ceilo/py27 units, which is clearly badness and needs\nto be addressed.\n\nObviously this lack of coverage will resolve itself quickly once\nthe Trusty switchover occurs, but it seems like we can short-circuit\nthat process by simply switching to f20 right now.\n\nI think the marconi jobs would be another good candidate, where\nswitching over to f20 now would add real value. The marconi tests\ninclude some coverage against mongodb proper, but this is currently\ndisabled, as marconi requires mongodb version >= 2.2 (and precise\ncan only offer 2.0.4).\n\n> We could make a special queue just for f20 that only triggers that\n> job, if others like that idea.\n> \n> Otherwise, ceilometer maybe?  I made some WIP patches [2,3] for this\n> already.  I think it\'s close, just deciding what tempest tests to\n> match for the job in [2].\n\nThanks for that.\n\nSo my feeling is that at least the following would make sense to base\non f20:\n\n1. ceilometer/py27 \n2. tempest variant with the ceilo DB configured as mongodb\n3. marconi/py27\n\nThen a random selection of other p27 jobs could potentially be added\nover time to bring f20 usage up to approximately the same breath\nas precise.\n\nCheers,\nEoghan\n\n> Thanks,\n> \n> -i\n> \n> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1099031\n> [2] https://review.openstack.org/#/c/96316/\n> [3] https://review.openstack.org/#/c/96317/\n> \n\n\n','<53A1593A.6070205@redhat.com>',NULL),('<1612143795.9986619.1369285192875.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-23 00:59:52',-14400,'2013-05-23 04:59:52',NULL,'[openstack-qa] Tempest core cleanup motions - motion 3 - remove\n dwalleck','+1\n\n\n\n----- Original Message -----\n> From: \"Matthew Treinish\" <mtreinish at kortar.org>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Tuesday, May 21, 2013 8:01:37 PM\n> Subject: Re: [openstack-qa] Tempest core cleanup motions - motion 3 - remove dwalleck\n> \n> On Tue, May 21, 2013 at 01:40:50PM -0400, Sean Dague wrote:\n> > On 05/21/2013 12:31 PM, Jay Pipes wrote:\n> > >On 05/21/2013 11:58 AM, Sean Dague wrote:\n> > >>Remembering that openstack-qa-core isn\'t an honor society, but is a\n> > >>working group of people that are actively engaged in the tempest code\n> > >>base, providing feedback to new contributors, and helping shepherd\n> > >>important features into Tempest. Removal doesn\'t mean judgement on the\n> > >>person, it just means that right now these are not active in driving\n> > >>this project through actively reviewing code.\n> > >>\n> > >>Remove the following folks from openstack-qa-core (the voting group for\n> > >>tempest): dwalleck\n> > >\n> > >+1 for removal. As Sean mentioned, -core membership is all about\n> > >reviews. It\'s not some honor society or mark of privilege, and being\n> > >removed isn\'t any mark of shame.\n> > \n> > +1, exactly the right sentiment, Jay describes it well.\n> > \n> > 	-Sean\n> > \n> \n> +1\n> \n> -Matt Treinish\n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<20130521180136.GC28273@kortar.Treinish>',NULL),('<1612222442.35.1387089054005.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:30:54',0,'2013-12-15 06:30:54',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-full-havana #8','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-full-havana/8/>\n\n\n\n','<1478773319.25.1387004061788.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1612328361.17.1385535777632.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-27 07:02:57',0,'2013-11-27 07:02:57',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-stable-havana #5','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-havana/5/changes>\n\n\n\n',NULL,NULL),('<1612658066.43.1383372794425.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:13:14',0,'2013-11-02 06:13:14',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-keystone-python27-stable-grizzly #45','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/45/>\n\n\n\n',NULL,NULL),('<1612710789.356.1355099759287.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-12-10 00:35:59',0,'2012-12-10 00:35:59',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #32','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/32/>\n\n------------------------------------------\n[...truncated 14255 lines...]\nAttempt to assign a role on a non existent tenant should fail ... ok\nAttempt to assign a role to a non existent user should fail ... ok\nRequest to assign a role to a user without a valid token ... ok\nReturn a list of all roles ... ok\nNon admin user should not be able to list roles ... ok\nRequest to list roles without a valid token should fail ... ok\nList roles assigned to a user on tenant ... ok\nNon admin user should not be authorized to list a user\'s roles ... ok\nAttempt to list roles of a non existent user should fail ... ok\nRequest to list user\'s roles without a valid token should fail ... ok\nRemove a role assigned to a user on a tenant ... ok\nNon admin user should not be authorized to remove a user\'s role ... ok\nAttempt to delete a non existent role from a user should fail ... ok\nAttempt to remove a role from a non existent tenant should fail ... ok\nAttempt to remove a role from a non existent user should fail ... ok\nRequest to remove a user\'s role without a valid token ... ok\nShould not be able to create a role with a blank name ... ok\nRole should be created, verified, and deleted ... ok\nRole names should be unique ... ok\nDuplicate user role should not get assigned ... ok\nAssign a role to a user on a tenant ... ok\nNon admin user should not be authorized to assign a role to user ... ok\nAttempt to assign a non existent role to user should fail ... ok\nAttempt to assign a role on a non existent tenant should fail ... ok\nAttempt to assign a role to a non existent user should fail ... ok\nRequest to assign a role to a user without a valid token ... ok\nReturn a list of all roles ... ok\nNon admin user should not be able to list roles ... ok\nRequest to list roles without a valid token should fail ... ok\nList roles assigned to a user on tenant ... ok\nNon admin user should not be authorized to list a user\'s roles ... ok\nAttempt to list roles of a non existent user should fail ... ok\nRequest to list user\'s roles without a valid token should fail ... ok\nRemove a role assigned to a user on a tenant ... ok\nNon admin user should not be authorized to remove a user\'s role ... ok\nAttempt to delete a non existent role from a user should fail ... ok\nAttempt to remove a role from a non existent tenant should fail ... ok\nAttempt to remove a role from a non existent user should fail ... ok\nRequest to remove a user\'s role without a valid token ... ok\nShould not be able to create a role with a blank name ... ok\nRole should be created, verified, and deleted ... ok\nRole names should be unique ... ok\nGET Service ... ok\nSKIP: Skipping until Bug #1061738 resolved\nNon-admin user should not be authorized to create a tenant ... ok\nCreate tenant request without a token should not be authorized ... ok\nTenant name should not be empty ... ok\nTenant name length should not be greater than 64 characters ... ok\nAttempt to delete a non existent tenant should fail ... ok\nRequest to list tenants without a valid token should fail ... ok\nReturn a list of all tenants ... ok\nNon-admin user should not be able to list tenants ... ok\nTenant names should be unique ... ok\nCreate a tenant that is enabled ... ok\nCreate a tenant that is not enabled ... ok\nCreate tenant with a description ... ok\nCreate several tenants and delete them ... ok\nNon-admin user should not be able to delete a tenant ... ok\nRequest to delete a tenant without a valid token should fail ... ok\nUpdate description attribute of a tenant ... ok\nUpdate the enabled attribute of a tenant ... ok\nUpdate name attribute of a tenant ... ok\nNon-admin user should not be authorized to create a tenant ... ok\nCreate tenant request without a token should not be authorized ... ok\nTenant name should not be empty ... ok\nTenant name length should not be greater than 64 characters ... ok\nAttempt to delete a non existent tenant should fail ... ok\nRequest to list tenants without a valid token should fail ... ok\nReturn a list of all tenants ... ok\nNon-admin user should not be able to list tenants ... ok\nTenant names should be unique ... ok\nCreate a tenant that is enabled ... ok\nCreate a tenant that is not enabled ... ok\nCreate tenant with a description ... ok\nCreate several tenants and delete them ... ok\nNon-admin user should not be able to delete a tenant ... ok\nRequest to delete a tenant without a valid token should fail ... ok\nUpdate description attribute of a tenant ... ok\nUpdate the enabled attribute of a tenant ... ok\nUpdate name attribute of a tenant ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nDisabled user\'s token should not get authenticated ... ok\nRequest for token authentication with a valid token in header ... ok\nUser\'s token for a disabled tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nUser\'s token with invalid password should not be authenticated ... ok\nUser\'s token for an invalid tenant should not be authenticated ... SKIP: Until Bug 988920 is fixed\nNon-existent user\'s token should not get authenticated ... ok\nCreate a user ... ok\nNon-admin should not be authorized to create a user ... ok\nAttempt to create a user in a non-existent tenant should fail ... ok\nRequest to create a user without a valid token should fail ... ok\nDuplicate user should not be created ... ok\nUser with an empty name should not be created ... ok\nUser with an empty password should not be created ... SKIP: Until Bug 999084 is fixed\nEmail format should be validated while creating a user ... SKIP: Until Bug 999084 is fixed\nUser having password exceeding max length should not be created ... SKIP: Until Bug 999084 is fixed\nLength of user name filed should be restricted to 64 characters ... SKIP: Until Bug 966251 is fixed\nAttempt to delete a non-existent user should fail ... ok\nDelete a user ... ok\nNon admin user should not be authorized to delete a user ... ok\nGet a list of users and find the test user ... ok\nNon admin user should not be authorized to get user list ... ok\nRequest to get list of users without a valid token should fail ... ok\nReturn a list of all users for a tenant ... ok\nShould not be able to return a list of all ... ok\nReturn list of users on tenant when roles are assigned to users ... ok\nValid user\'s token is authenticated ... ok\nRegister a new remote image ... ok\nRegister, then upload an image ... ok\nNegative tests for invalid data supplied to POST /images ... ok\nSimple test to see all fixture images returned ... ok\nSKIP: No OpenStack Network API endpoint\nAdd metadata to account ... ok\nDelete metadata from account ... ok\nList all account metadata ... ok\nList of all containers should not be empty ... ok\nUpdate/Retrieve/Delete Container Metadata ... ok\nCreate a container, test responses ... ok\nCreate and Delete a container, test responses ... ok\nAdd metadata to object ... ok\nCopy storage object ... ok\nCopy storage object across containers ... ok\nCopy storage object ... ok\nChange the content type of an existing object ... ok\nCreate storage object, test response ... ok\nCreate and delete a storage object, test responses ... ok\nRetrieve object\'s data(in response body) ... ok\nAdd metadata to storage object, test if metadata is retrievable ... ok\nVersioned container responses tests ... ok\nVolume is attached and detached successfully from an instance ... ok\nVerify that a volume\'s attachment information is retrieved ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume without passing metadata, get details, and delete ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\nShould not be able to create volume with invalid size ... ok\nShould not be able to create volume without passing size ... ok\nShould not be able to create volume with size zero ... ok\nShould not be able to delete volume when invalid ID is passed ... ok\nShould not be able to delete volume when empty ID is passed ... ok\nShould not be able to get volume with invalid id ... ok\nShould not be able to get volume when empty ID is passed ... ok\nShould not be able to delete a nonexistant Volume ... ok\nShould not be able to get a nonexistant volume ... ok\n\n======================================================================\nERROR: Creating a server with a name that already exists is allowed\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 63, in test_create_with_existing_server_name\n    self.client.wait_for_server_status(server[\'id\'], \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/servers_client.py\", line 155, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 79d1c06e-e8c8-4c7b-854c-316fe9dc3d7f failed to build and is in ERROR status\n\n======================================================================\nERROR: Creating a server with a name that already exists is allowed\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_servers.py\", line 63, in test_create_with_existing_server_name\n    self.client.wait_for_server_status(server[\'id\'], \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/servers_client.py\", line 190, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 8aa035c8-39f8-4fa4-a630-a2e6ac0853cd failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 547 tests in 1243.322s\n\nFAILED (SKIP=69, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/rabbitmq/rabbit at devstack-1354993254-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/rabbitmq/rabbit at devstack-1354993254.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/32/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<255327906.319.1355014837974.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1613035823.24.1383113633316.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-30 06:13:53',0,'2013-10-30 06:13:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #48','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/48/>\n\n------------------------------------------\n[...truncated 1277 lines...]\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5d215d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5d215d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4979690>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4979690>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-f3a39764-7cf3-45e0-ac83-30bcb2f5d5be\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:13:24Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'24\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:13:24Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'24\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:13:24+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'24\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:13:24-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'24\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:13:24Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'24\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6637a10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27e4d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 75.47 secs:\n    15.80    TestBinGlanceCacheManage.test_queue\n    15.77    TestScrubber.test_delayed_delete\n    14.80    TestGlanceControl.test_bouncing\n    14.58    TestGlanceControl.test_respawn\n    14.52    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 932 tests in 649.767s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-48\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.MxV7tADo6t\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/48\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/48/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise28\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise28/48\n[SCP] Copying console log.\n\n\n','<79752784.20.1383026896737.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1613389202.39441675.1351258420226.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-26 09:33:40',-14400,'2012-10-26 13:33:40',NULL,'[openstack-dev] [ceilometer] alternative publication conduits','\nHi Ceilo Folks,\n\nTL;DR: just wanted to get feedback on some initial ideas on how\nwe might accommodate different conduits of publication from the\nceilo pollsters and notification handlers.\n\nCurrently, we\'re obviously hard-coded to always publish via the\nmessage bus, so the idea is to support alternative/additional\npublication routes, according to the following outline:\n\n - a ceilo notification handler or pollster can be associated\n   via config with a chain of zero or more Publishers\n\n - each Publisher knows now to emit their representation over some\n   conduit (AMQP notification, CW PutMetricData call, statsd UDP\n   packet, or whatever)\n\n - a ceilometer notification handler or pollster provides a\n   Transformer corresponding to each of its Publishers, which\n   knows how to transform domain-specific raw data into the\n   relevant representation\n\n - the batching of transformer output is up to the Publisher\n\n - each Publisher has an independent frequency, so not all\n   Publishers are called to publish every measurement\n\nSo for example the compute.libvirt.DiskIOPollster would provide a\ntransformer to map the raw disk stats reported by libvirt into\nDiskWriteOps, DiskWriteBytes, DiskReadOps & DiskReadBytes metric\ndatapoints for CW, also indicating that this should be published\nvery minute. This CWPublisher would handle batching these data\nas a single PutMetricData call.\n\nThe DiskIOPollster would also provide a second Transformer to\nmediate between the raw stats format and the ceilo Counter\nrepresentation for metering.  Additionally, this second Publisher\ncould be configured with a longer period (as befits metering data\nlikely to be consumed by a billing engine).\n\nNow the frequency aspect is a bit awkward. For notifications,\nthe frequency of the \"exists\" style of usage audit is out of our\nhands, depending usually on the configuration of the emitter\n(e.g. the nova instance_usage_audit_period config). Whereas ceilo\nconfig direct controls only the frequency of polling. So one idea \nwould be for a publisher\'s frequency only to impact on the periods\nunder ceilo control - i.e. we\'d accept and publish notifications\nwhenever we get them, whereas the polling cycle would be determined\nby the greatest common divisor of all the configured publisher\nperiods for each set of related pollsters (the config would probably\nhave to be restricted so to ensure a sane GCD). \n\nAlso, I\'m assuming that an alternative publication route would\ngenerally be used when the target endpoint is not the ceilo collector\n& metering store ... i.e. non-standard publisher would most often\nbe used in order to hive off the data to an alternative endpoint\nor store, such as a CW metrics store, or say to be dumped as RRD \nfiles to be consumed by graphite.\n\nThoughts?\n\nCheers,\nEoghan\n\n\n','<1483372350.39435379.1351257801742.JavaMail.root@redhat.com>',NULL),('<1613577.vTCKfsV735@e6230>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-21 10:20:07',7200,'2013-03-21 08:20:07',NULL,'[openstack-dev] PCI-passthrough dev ...','Hi.\n\nIs someone working with this currently, or have some info\nabout usage ?\n\nBlueprint : https://blueprints.launchpad.net/nova/+spec/pci-passthrough-and-\nsr-iov\n\nLatest code review : https://review.openstack.org/#/c/776/\n\nThanks in advance.\n\n- niilo -\n\n\n',NULL,NULL),('<1613E283-341D-41DE-8A6C-A36133E7E446@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-26 18:14:56',-25200,'2013-08-27 01:14:56',NULL,'[openstack-dev] About multihost patch review','\nOn Aug 26, 2013, at 4:06 PM, Edgar Magana <emagana at plumgrid.com> wrote:\n\n> Hi Developers,\n> \n> Let me explain my point of view on this topic and please share your thoughts in order to merge this new feature ASAP.\n> \n> My understanding is that multi-host is nova-network HA  and we are implementing this bp https://blueprints.launchpad.net/neutron/+spec/quantum-multihost for the same reason.\n> So, If in neutron configuration admin enables multi-host:\n> etc/dhcp_agent.ini\n> \n> # Support multi host networks\n> # enable_multihost = False\n> \n> Why do tenants needs to be aware of this? They should just create networks in the way they normally do and not by adding the \"multihost\" extension.\n\nI was pretty confused until I looked at the nova-network HA doc [1].  The proposed design would seem to emulate nova-network\'s multi-host HA option, where it was necessary to both run nova-network on every compute node and create a network explicitly as multi-host.  I\'m not sure why nova-network was implemented in this way, since it would appear that multi-host is basically all-or-nothing.  Once nova-network services are running on every compute node, what does it mean to create a network that is not multi-host?\n\nSo, to Edgar\'s question - is there a reason other than \'be like nova-network\' for requiring neutron multi-host to be configured per-network?\n\n\nm.\n\n1: http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html\n\n\n> I could be totally wrong and crazy, so please provide some feedback.\n> \n> Thanks,\n> \n> Edgar\n> \n> \n> From: Yongsheng Gong <gongysh at unitedstack.com>\n> Date: Monday, August 26, 2013 2:58 PM\n> To: \"Kyle Mestery (kmestery)\" <kmestery at cisco.com>, Aaron Rosen <arosen at nicira.com>, Armando Migliaccio <amigliaccio at vmware.com>, Akihiro MOTOKI <amotoki at gmail.com>, Edgar Magana <emagana at plumgrid.com>, Maru Newby <marun at redhat.com>, Nachi Ueno <nachi at nttmcl.com>, Salvatore Orlando <sorlando at nicira.com>, Sumit Naiksatam <sumit.naiksatam at bigswitch.com>, Mark McClain <mark.mcclain at dreamhost.com>, Gary Kotton <gkotton at vmware.com>, Robert Kukura <rkukura at redhat.com>\n> Cc: OpenStack List <openstack-dev at lists.openstack.org>\n> Subject: Re: About multihost patch review\n> \n> Hi,\n> Edgar Magana has commented to say:\n> \'This is the part that for me is confusing and I will need some clarification from the community. Do we expect to have the multi-host feature as an extension or something that will natural work as long as the deployment include more than one Network Node. In my opinion, Neutron deployments with more than one Network Node by default should call DHCP agents in all those nodes without the need to use an extension. If the community has decided to do this by extensions, then I am fine\' at\n> https://review.openstack.org/#/c/37919/11/neutron/extensions/multihostnetwork.py\n> \n> I have commented back, what is your opinion about it?\n> \n> Regards,\n> Yong Sheng Gong\n> \n> \n> On Fri, Aug 16, 2013 at 9:28 PM, Kyle Mestery (kmestery) <kmestery at cisco.com> wrote:\n>> Hi Yong:\n>> \n>> I\'ll review this and try it out today.\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On Aug 15, 2013, at 10:01 PM, Yongsheng Gong <gongysh at unitedstack.com> wrote:\n>> \n>> > The multihost patch is there for a long long time, can someone help to review?\n>> > https://review.openstack.org/#/c/37919/\n>> \n> \n\n\n\n','<CE412B76.20243%emagana@plumgrid.com>',NULL),('<1614252448.23708342.1418609647315.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-15 10:14:04',28800,'2014-12-15 02:14:04',NULL,'[openstack-dev]  [nova] pylint failure in havana stable 2013.2.4','Hi all?\n    While I\'m cherry-picking havana stable 2013.2.4(nova) commits to our private branch? I found that this backport commit 97028309ff7a13ea5e9b8cc353d56ec9678caaff causes a pylint failure: nova/api/openstack/compute/contrib/floating_ips.py:203: [E1101, FloatingIPController.delete] Module \'nova.exception\' has no \'Forbidden\' member.\n    Then I downloaded the tar package on launched(https://launchpad.net/nova/havana/2013.2.4/+download/nova-2013.2.4.tar.gz), I checked the nova/exception.py, there is no \'Forbidden\' class or other member in it, so I guess this is a mis-denpendency backport commit, this denpended commit c75a15a48981628e77d4178476c121693a656814 should be backported.\n\n2014-12-15 09:51 (UTC+8)\nWangpan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141215/ac86cdb2/attachment.html>\n\n',NULL,NULL),('<1614861030.230.1368253839633.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:30:39',0,'2013-05-11 06:30:39',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #11','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/11/>\n\n------------------------------------------\n[...truncated 12584 lines...]\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 7677d71b1f2646bcb9a4ba61a632409c \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:58761\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:58761/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (2299) wsgi starting up on http://127.0.0.1:58761/\n\nnova.osapi_compute.wsgi.server: INFO: (2299) accepted (\'127.0.0.1\', 34082)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [11/May/2013 06:25:20] \"GET /v2 HTTP/1.1\" 204 216 0.000906\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-8158b132-157e-49cf-8cc1-c96638cc08e8</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (2299) accepted (\'127.0.0.1\', 34083)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa8c2dd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa8c2dd0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:58761/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-11 06:25:20 2299 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:58761/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [11/May/2013 06:25:20] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.250203\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 91636729937e4554bb983b8e4ae09c8b \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:34325\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:34325/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (2299) wsgi starting up on http://127.0.0.1:34325/\n\nnova.osapi_compute.wsgi.server: INFO: (2299) accepted (\'127.0.0.1\', 45435)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [11/May/2013 06:25:20] \"GET /v2 HTTP/1.1\" 204 216 0.001045\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-5b9de117-8379-425e-9492-2ad16d458281</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (2299) accepted (\'127.0.0.1\', 45436)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9e498d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9e498d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:34325/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     name)\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-11 06:25:21 2299 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:34325/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [11/May/2013 06:25:21] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.347035\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.xjKmFnQRWb\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/11\n[SCP] Copying console log.\n\n\n','<1045138282.211.1368167535603.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1615155261.30294124.1378494739678.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-06 15:12:19',-14400,'2013-09-06 19:12:19',NULL,'[openstack-dev] [Nova] FFE Request: oslo-messaging','\n\n----- Original Message -----\n> From: \"Bob Ball\" <bob.ball at citrix.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>, \"Mark McLoughlin\" <markmc at redhat.com>\n> Cc: \"Dan Prince (dprince at redhat.com)\" <dprince at redhat.com>\n> Sent: Friday, September 6, 2013 10:21:45 AM\n> Subject: RE: [openstack-dev] [Nova] FFE Request: oslo-messaging\n> \n> Puppet is failing to build the packages - which is probably understandable\n> given it\'s a refactor.\n> \n> I\'m not sure if this is something that points to a problem with the refactor\n> or the packaging itself - hopefully Dan can review the logs, or if others\n> want to see more of the details look at the logs at\n> https://review.openstack.org/39929.\n> \n> I don\'t see any point in triggering another Smokestack run as it\'s likely to\n> fail again until the packaging issue has been resolved by Dan\'s team.\n\nFTR. SmokeStack should have oslo-messaging packages available for use as of today. Once I kick the tires on it a bit I\'ll go and re-run the existing Nova Oslo messaging branches so we have a better idea of how this works w/ Qpid, etc.\n\nSo whether we wait till IceHouse or not we\'ll be ready.\n\nDan\n\n> \n> Bob\n> \n> From: Davanum Srinivas [mailto:davanum at gmail.com]\n> Sent: 05 September 2013 17:04\n> To: Mark McLoughlin; OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Nova] FFE Request: oslo-messaging\n> \n> Thanks Mark. Looks like we need to get someone to manually trigger Smokestack\n> to run against this review at least once since i don\'t see any +1\'s from\n> Smokestack for some reason.\n> \n> On Thu, Sep 5, 2013 at 11:49 AM, Mark McLoughlin\n> <markmc at redhat.com<mailto:markmc at redhat.com>> wrote:\n> Hi\n> \n> On Thu, 2013-09-05 at 10:43 -0400, Davanum Srinivas wrote:\n> > Mark,\n> >\n> > Has this changeset get through a full tempest with QPid enabled?\n> No, I\'ve only done local testing with the qpid transport to date.\n> \n> I think Smokestack is the only CI tool actively testing the qpid driver.\n> I ran out of time adding oslo.messaging to Smokestack before heading off\n> on vacation, but I expect I\'ll get to it next week.\n> \n> Cheers,\n> Mark.\n> \n> \n> >\n> > thanks,\n> > dims\n> >\n> >\n> > On Thu, Sep 5, 2013 at 10:17 AM, Mark McLoughlin\n> > <markmc at redhat.com<mailto:markmc at redhat.com>> wrote:\n> >\n> > > Hi\n> > >\n> > > I\'d like to request a feature freeze exception for the final (and\n> > > admittedly the largest) patch in the series of 40 patches to port Nova to\n> > > oslo.messaging:\n> > >\n> > >   https://review.openstack.org/39929\n> > >\n> > > While this change doesn\'t provide any immediate user-visible benefit, it\n> > > would be massively helpful in maintaining momentum behind the effort all\n> > > through the Havana cycle to move the RPC code from oslo-incubator into a\n> > > library.\n> > >\n> > > In terms of risk of regression, there is certainly some risk but that\n> > > risk\n> > > is mitigated by the fact that the core code of each of the transport\n> > > drivers has been modified minimally. The idea was to delay re-factoring\n> > > these drivers until we were sure that we hadn\'t caused any regressions in\n> > > Nova. The code has been happily passing the devstack/tempest based\n> > > integration tests for 10 days now.\n> > >\n> > > Thanks,\n> > > Mark.\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> > >\n> >\n> >\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> --\n> Davanum Srinivas :: http://davanum.wordpress.com\n> \n\n\n','<BB824EA959B82F43820FFEE5E6B00AA60DA220@AMSPEX01CL01.citrite.net>',NULL),('<1615156199.6815811.1391093985160.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 14:59:45',0,'2014-01-30 14:59:45',NULL,'[openstack-dev] [nova] bp proposal: libvirt-resize-disk-down','  Greetings,\n\nA blueprint is being discussed about the disk resize down feature of libvirt driver.\n  https://blueprints.launchpad.net/nova/+spec/libvirt-resize-disk-down\n\nThe current implementation does not handle disk resize down and just skips the\nstep during a resize down of the instance. I\'m really convinced we can implement \nthis feature by using the good job of disk resize down of the driver xenapi.\n\nCriteria for allowing disk resize down:\n  + The disk must have one partition\n  + The fs must be ext3 or ext4\n\nThe implementation will be separated in several commits:\n  + Move shared utility methods to a common module:\n    - virt.xenapi.vm_utils._get_partitions to virt.disk.utils.get_partitions\n    - virt.libvirt.utils.copy_image to virt.disk.utils.copy_image\n    - virt.xenapi.vm_utils._repair_filesystem to virt.disk.utils.repair_filesystem\n  + Disk resize down implementation\n\nNotes:\n  - Another point we have to discuss, is that the current implementation just skips\n    the fs resize if not supported, is it a good choice? Should we have\n    to raise an exception to inform the user that it is not possible to resize\n    the instance? (if we have to raise an exception, a task will be added to the\n    TODO to handle this case for resize up before working on resize down.)\n  - The current workflow for a user is to confirm the resize when the state\n    of the instance is VERIFY_RESIZE, I think we probably have to add a\n    checklist of good pratices of how to verify a resize in the manual:\n      http://docs.openstack.org/user-guide/content/nova_cli_resize.html\n\nThanks a lot,\ns.\n\n\n','<2076521863.6814253.1391093841491.JavaMail.root@cloudwatt.com>',NULL),('<1615726760.8941074.1404995860293.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-10 08:37:40',-14400,'2014-07-10 12:37:40',NULL,'[openstack-dev] [qa][all] Branchless Tempest beyond pure-API\n tests, impact on backporting policy','\n> > Note that the notifications that capture these resource state transitions\n> > are a long-standing mechanism in openstack that ceilometer has depended\n> > on from the very outset. I don\'t think it\'s realistic to envisage these\n> > interactions will be replaced by REST APIs any time soon.\n> \n> I wasn\'t advocating doing everything over a REST API. (API is an\n> overloaded term) I just meant that if we\'re depending on\n> notifications for communication between projects then we should\n> enforce a stability contract on them. Similar to what we already\n> have with the API stability guidelines for the REST APIs. The fact\n> that there is no direct enforcement on notifications, either through\n> social policy or testing, is what I was taking issue with.\n>\n> I also think if we decide to have a policy of enforcing notification\n> stability then we should directly test the notifications from an\n> external repo to block slips. But, that\'s a discussion for later, if\n> at all.\n\nA-ha, OK, got it.\n\nI\'ve discussed enforcing such stability with jogo on IRC last night, and\nkicked off a separate thread to capture that:\n\n  http://lists.openstack.org/pipermail/openstack-dev/2014-July/039858.html\n\nHowever the time-horizon for that effort would be quite a bit into the\nfuture, compared to the test coverage that we\'re aiming to have in place\nfor juno-2.\n\n> > > > The branchless Tempest spec envisages new features will be added and\n> > > > need to be skipped when testing stable/previous, but IIUC requires\n> > > > that the presence of new behaviors is externally discoverable[5].\n> > > \n> > > I think the test case you proposed is fine. I know some people will\n> > > argue that it is expanding the scope of tempest to include more\n> > > whitebox like testing, because the notification are an internal\n> > > side-effect of the api call, but I don\'t see it that way. It feels\n> > > more like exactly what tempest is there to enable testing, a\n> > > cross-project interaction using the api.\n> > \n> > In my example, APIs are only used to initiate the action in cinder\n> > and then to check the metering data in ceilometer.\n> > \n> > But the middle-piece, i.e. the interaction between cinder & ceilometer,\n> > is not mediated by an API. Rather, its carried via an unversioned\n> > notification.\n> \n> Yeah, exactly, that\'s why I feel it\'s a valid Tempest test case.\n\nJust to clarify: you meant to type \"it\'s a valid Tempest test case\"\nas opposed to \"it\'s *not* a valid Tempest test case\", right?\n \n> What I was referring to as the counter argument, and where the\n> difference of opinion was, is that the test will be making REST API\n> calls to both trigger a nominally internal mechanism (the\n> notification) from the services and then using the ceilometer api to\n> validate the notification worked. \n\nYes, that\'s exactly the idea.\n\n> But, it\'s arguably the real intent of these tests is to validate\n> that internal mechanism, which is basically a whitebox test. The\n> argument was that by testing it in tempes we\'re testing\n> notifications poorly because of it\'s black box limitation\n> notifications will just be tested indirectly. Which I feel is a\n> valid point, but not a sufficient reason to exclude the notification\n> tests from tempest.\n\nAgreed.\n\n> I think the best way to move forward is to have functional whitebox\n> tests for the notifications as part of the individual projects\n> generating them, and that way we can direct validation of the\n> notification. But, I also feel there should be tempest tests on top\n> of that that verify the ceilometer side of consuming the\n> notification and the api exposing that information.\n\nExcellent. So, indeed, more fullsome coverage of the notification\nlogic with in-tree tests on the producer side would definitely\nto welcome, and could be seen as a \"phase zero\" of an overall to\nfix/impove the notification mechanism.\n  \n> > > But, they\'re is also a slight misunderstanding here. Having a\n> > > feature be externally discoverable isn\'t a hard requirement for a\n> > > config option in tempest, it\'s just *strongly* recommended. Mostly,\n> > > because if there isn\'t a way to discover it how are end users\n> > > expected to know what will work.\n> > \n> > A-ha, I missed the subtle distinction there and thought that this\n> > discoverability was a *strict* requirement. So how bad a citizen would\n> > a project be considered to be if it chose not to meet that strong\n> > recommendation?\n> \n> You\'d be far from the only ones who are doing that, for an existing example\n> look at anything on the nova driver feature matrix. Most of those aren\'t\n> discoverable from the API. So I think it would be ok to do that, but when we\n> have efforts like:\n> \n> https://review.openstack.org/#/c/94473/\n> \n> it\'ll make that more difficult. Which is why I think having discoverability\n> through the API is important. (it\'s the same public cloud question)\n\nSo for now, would it suffice for the master versus stable/icehouse\nconfig to be checked-in in static form pending the completion of that\nBP on tempest-conf-autogen?\n\nThen the assumption is that this static config is replaced by auto-\ngenerating the tempest config using some project-specific discovery\nmechanisms?\n\n> > > For this specific case I think it\'s definitely fair to have an\n> > > option for which notifications services are expected to be\n> > > generated. That\'s something that is definitely a configurable option\n> > > when setting up a deployment, and is something that feels like a\n> > > valid tempest config option, so we know which tests will work. We\n> > > already have similar feature flags for config time options in the\n> > > services, and having options like that would also get you out of\n> > > that backport mess you have right now.\n> > \n> > So would this test configuration option would have a semantic like:\n> > \n> >  \"a wildcarded list of notification event types that ceilometer consumes\"\n> > \n> > then tests could be skipped on the basis of the notifications that\n> > they depend on being unavailable, in the manner of say:\n> > \n> >   @testtools.skipUnless(\n> >       matchesAll(CONF.telemetry_consumed_notifications.volume,\n> >                  [\'snapshot.exists\',\n> >                   \'snapshot.create.*\',\n> >                   \'snapshot.delete.*\',\n> >                   \'snapshot.resize.*\',]\n> >                 )\n> >   )\n> >   @test.services(\'volume\')\n> >   def test_check_volume_notification(self):\n> i>       ...\n> > \n> > Is something of that ilk what you envisaged above?\n> \n> Yeah that was my idea more or less, but I\'d probably move the logic into a\n> separate\n> decorator to make a bit cleaner. Like:\n> \n> @test.consumed_notifications(\'volumes\', \'snapshot.exists\',\n> \'snapshot.create.*\',\n>                              \'snapshot.delete.*\', \'snapshot.resize.*\')\n> \n> and you can just double them up if the test requires notifications from other\n> services.\n\nOK, so the remaining thing I wanted to confirm is that it\'s acceptable\nfor the skip/no-skip logic of that decorator to be driven by static\n(as opposed to discoverable) config?\n\n> > > However, it does raise the question of being an end user how am I\n> > > expected to know which notifications get counted? Which is why having\n> > > the feature discoverability is generally a really good idea.\n> > \n> > So certain things we could potentially make discoverable through the\n> > ceilometer capabilities API. But there\'s a limit to how fine-grained\n> > we can make that. Also it was primarily intended to surface lack of\n> > feature-parity in the storage driver layer (e.g. one driver supports\n> > sdtdev, but another doesn\'t) as opposed to the notification-handling\n> > layer.\n> \n> I think we should probably decouple the discoverability question\n> from the discussion about testing, because to a certain degree it\'s\n> a separate problem.  It might be worth splitting the API\n> discoverability discussion off as a separate thread so we don\'t\n> cloud either topic. (pun intended :) )\n\nI\'m confused as how we can completely split off the discoverability\nquestion, if its a *strong* recommendation (but not a strict requirement)\nof the testing framework.\n\n> I guess it really depends on how we expect people to be consuming\n> the API, and whether we\'re presenting that expectation to\n> people. I\'ll have to admit I\'m not as familiar with ceilometer as I\n> should be, which is probably where some of my confusion is coming\n> from.\n\nThe intent of capabilities API was initially purely to give users\ninsight into the storage-driver-specific functionality exposed in\nthe primary API.\n\nI guess we\'ve been kicking around on the idea of re-purposing that\nAPI, so that it also allows surfacing of the list of meters being\ncaptured.\n\nBut that idea hasn\'t yet been firmed up to the extent that we\'ve\nfigured out how *users* might consume it.\n\n> The naive real world example I have in my head is: someone wants to\n> build a tool that will generate pretty pictures from data queried\n> from the ceilometer API, and if they want to run this on 2+ distinct\n> OpenStack deployments how will they know only through the API which\n> notifications are getting counted, etc. If it\'s doable through the\n> API then the tool can adjust what gets generated based on an API\n> call, (either up front or with an expected error response, like\n> unsupported request. (of course a new response like unsupported\n> would probably mean a new API rev) Without the discoverability\n> manual intervention would be required each time it\'s used with a new\n> cloud. This probably isn\'t a valid use case and I\'m missing\n> something critical here. In which case the discoverability\n> discussion is moot.\n\nThat would be a case where discoverability of meters would be useful\n(i.e. not just the meters currently in the metering store, also all\nthe meter that this deployment of ceilometer is capable of gathering\nsamples for). However that feature will take a bit more thought &\ndiscussion to firm up.\n\n> > > > One approach mooted for allowing these kind of scenarios to be tested\n> > > > was to split off the pure-API aspects of Tempest so that it can be used\n> > > > for probing public-cloud-capabilities as well as upstream CI, and then\n> > > > build project-specific mini-Tempests to test integration with other\n> > > > projects.\n> > > > \n> > > > Personally, I\'m not a fan of that approach as it would require a lot\n> > > > of QA expertise in each project, lead to inefficient use of CI\n> > > > nodepool resources to run all the mini-Tempests, and probably lead to\n> > > > a divergent hotchpotch of per-project approaches.\n> > > \n> > > I think the proposal here was for people interested in doing\n> > > whitebox testing, where there is a desire to test an internal\n> > > project mechanism. I could see the argument for testing\n> > > notifications this way, but that would have to be for every project\n> > > individually. There are already several projects that have\n> > > functional testing like this in tree and run them as a gating\n> > > job. There are definitely certain classes of testing where doing\n> > > this makes sense.\n> > \n> > I\'m not sure that this would be realistic to test individually (if by\n> > that you meant just with the ceilometer agents running alone) as it\n> > depends on a notification emitted from cinder.\n> \n> I wasn\'t actually referring to use it for this specific case, just a\n> general thought. Although maybe it would be useful to add to add\n> notification functional tests to Cinder. I think Sean\'s response on\n> the OP outlined some interesting alternative testing strategies\n> which could would definitely fit this use case. I still need to\n> finish forming my opinions about that before I respond to it.\n\nOK. (And so do I).\n\n> So I wrote this in one pass, sorry if bits of it are incoherent. :)\n\nNo, it was all good, thanks!\n\nCheers,\nEoghan\n\n\n','<20140709221031.GB8349@Sazabi.treinish>',NULL),('<1616078769.5.1387173794621.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-16 06:03:14',0,'2013-12-16 06:03:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-heat-python27-grizzly/8/>\n\n------------------------------------------\n[...truncated 649 lines...]\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 14.837s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.20.1\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7.1\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.grizzly.8\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.7\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.12.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.8\nrequests==2.1.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.8.2\ntermcolor==1.1.0\nwarlock==1.1.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.ynx8rZ60eh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-grizzly/precise9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-grizzly/precise9/8\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1617041656.21127616.1383756142762.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-06 11:42:22',-18000,'2013-11-06 16:42:22',NULL,'[openstack-dev] How to add a comment to a change review?','You just click the \"review\" button under the change list on Gerrit.  It should then take you to a screen where you can see inline comments waiting to be added and enter an overall comment as well.\n\nThe comment system in Gerrit really should be a bit more intuitive.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Michael Bright\" <mjbrightfr at gmail.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, November 6, 2013 11:34:27 AM\nSubject: [openstack-dev] How to add a comment to a change review?\n\n\nCan someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org . \n\nI suppose it\'s mind numbingly obvious but here for example I just cannot see how to add a comment. \n\nIt says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures \n\n\n\nLeave a comment on the review referencing the bug causing the transient failure (not the bug you\'re attempting to fix with your patch): \nTo re-run the check jobs (before a change has been approved), leave a comment with the form \"recheck bug ####\". \nTo re-run the gate jobs (after a change has been approved), leave a comment with the form \"reverify bug ####\". \n\nIt must be so obvious ... \n\nThanks in advance, \nMike. \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAMZ8oZ05eASjEJQoghvMwaVB6C0rHBSUPRut=E-Rcf+5SaL49Q@mail.gmail.com>',NULL),('<1617231955.9.1385359847492.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-25 06:10:47',0,'2013-11-25 06:10:47',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-havana #3','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-havana/3/changes>\n\n\n\n','<955269142.136.1385014948155.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1618223443.39.1352678458928.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:00:58',0,'2012-11-12 00:00:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-diablo #90','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/90/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/>\nCheckout:periodic-horizon-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson7121940693302699333.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-diablo/90\n[SCP] Copying console log.\n\n\n','<1309494357.27.1352592058909.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<161873892.3193091.1397145679586.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-04-10 12:01:19',-14400,'2014-04-10 16:01:19',NULL,'[openstack-tc] upgrade testing expectation','\n> > Sean Dague wrote:\n> > > I\'ve proposed another add to the expectations post graduation to the\n> > > governance repo - https://review.openstack.org/#/c/86162/\n> > > \n> > > This was in the original QA requirements proposal, however when that got\n> > > restructured, it got lost somewhere. Also happy to discuss it if there\n> > > are any concerns.\n> > > \n> > > As a scorecard today the following projects participate in upgrade\n> > > testing:\n> > > \n> > >  * Nova\n> > >  * Swift\n> > >  * Keystone\n> > >  * Glance\n> > >  * Cinder\n> > >  * Horizon\n> > >  * Neutron (new as of this week)\n> > > \n> > > Projects that don\'t (yet)\n> > >  * Heat\n> > >  * Ceilometer\n\nHi Sean,\n\nThanks for raising this.\n\nCan I clarify one related point, whether grenade is intended\nprimarily to catch intrinsic or extrinsic upgrade issues?\n\nOr both?\n\nIntrinsic in this context would for example be service A failing\npost-upgrade due to a bad DB schema migration.\n\nWhereas extrinsic would for example be service A failing post-\nupgrade because some dependency/assumption with respect to\nservice B is now broken.\n\nI ask because ceilometer when used with a \"schema free\" storage\ndriver may be more likely to suffer from extrinsic issues on\nupgrade as opposed to intrinsic (e.g. nova changes a notification\npayload between versions, as opposed to a failed db-sync as that\nwouldn\'t even arise).\n\nBut surely such integration issues should have been caught in\nadvance via the normal Tempest testing of master-versus-master,\nand wouldn\'t necessarily require the big-bang stable-to-master\napproach of grenade to smoke out?\n\nOr am I missing something obvious here?\n\nThanks,\nEoghan\n\n> > >  * Trove\n> > >  * Sahara\n> > \n> > Icehouse is the first release with Trove (and Juno will be the first\n> > release with Sahara) so I think it\'s fine if they aren\'t included in\n> > upgrade testing yet.\n> > \n> > The fact that Ceilometer and Heat haven\'t caught up with upgrade testing\n> > during their N+1 integrated cycle is more of a problem, so I think it\'s\n> > a good idea to document it in the post-graduation requirements.\n> > \n> > --\n> > Thierry Carrez (ttx)\n> > \n> > _______________________________________________\n> > OpenStack-TC mailing list\n> > OpenStack-TC at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n\n\n','<720773944.3045222.1397134045481.JavaMail.zimbra@redhat.com>',NULL),('<1619365258.1746046.1395862321207.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 15:32:01',-14400,'2014-03-26 19:32:01',NULL,'[openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0','What bug tracker should I file under?  I tried filing one under the openstack common infrastructure tracker,\nbut was told that it wasn\'t the correct place to file such a bug.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, March 26, 2014 3:28:32 PM\nSubject: Re: [openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0\n\nWhere is the RC bug tracking this?\n\nIf it\'s that bad, we really need to be explicit about this with a\ncritical bug at this stage of the release.\n\n	-Sean\n\nOn 03/26/2014 01:14 PM, Solly Ross wrote:\n> Code which breaks:\n> \n> Glance\'s mutliprocessing tests will break (the reason we should limit it now).\n> For the future, people attempting to use psutil will have no clear version target\n> (Either they use 1.x and break with the people who install the latest version from pip,\n> of they use 2.0.0 and break with everything that doesn\'t use the latest version).\n> \n> psutil\'s API is extremely unstable -- it has undergone major revisions going from 0.x to 1.x, and now\n> 1.x to 2.0.0.  Limiting psutil explicitly to a single major version (it was more or less implicitly limited\n> before, since there was no version major version above 1) ensures that the requirements.txt file actually\n> indicates what is necessary to use OpenStack.\n> \n> The alternative option would be to update the glance tests, but my concern is that 2.0.0 is not available\n> from the package managers of most distros yet.\n> \n> Best Regards,\n> Solly Ross\n> \n> ----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, March 26, 2014 10:39:41 AM\n> Subject: Re: [openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0\n> \n> On 03/26/2014 10:30 AM, Solly Ross wrote:\n>> Hi,\n>> I currently have a patch up for review (https://review.openstack.org/#/c/81373/) to limit psutil be <2.0.0.\n>> 2.0.0 just came out a couple weeks ago, and breaks the API in a major way.  Until we can port our code to the\n>> latest version, I suggest we limit the version of psutil to 1.x (currently there\'s a lower bound in the 1.x\n>> range, just not an upper bound).\n> \n> Which code will be broken by this if it\'s not done? Is there an RC bug\n> tracking it?\n> \n> 	-Sean\n> \n\n\n-- \nSean Dague\nSamsung Research America\nsean at dague.net / sean.dague at samsung.com\nhttp://dague.net\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53332A60.9000302@dague.net>',NULL),('<161987314.53.1387780351693.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-23 06:32:31',0,'2013-12-23 06:32:31',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-havana #10','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/10/>\n\n\n\n','<1771773460.52.1387694637194.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1620973620.420.1367129060357.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:04:20',0,'2013-04-28 06:04:20',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-docs-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-glance-docs-stable-grizzly/18/>\n\n\n\n','<1411376643.364.1367042615331.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1621127390.3111742.1395327956166.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-20 11:05:56',-14400,'2014-03-20 15:05:56',NULL,'[openstack-dev] [nova] Backwards incompatible API changes','I concur.  I suspect people/organizations who are doing CD *probably* won\'t mind\nsuch a change as much as the people who use the versioned releases will mind\nbackwards-incompatibility.  Correct me if I\'m wrong, but doing CD requires a\ncertain willingness to roll with the punches, so to speak, whereas people using\nversioned releases are less likely to be as flexible.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Thierry Carrez\" <thierry at openstack.org>\nTo: openstack-dev at lists.openstack.org\nSent: Thursday, March 20, 2014 6:51:26 AM\nSubject: Re: [openstack-dev] [nova] Backwards incompatible API changes\n\nChristopher Yeoh wrote:\n> The patch was merged in October (just after Icehouse opened) and so has\n> been used in clouds that do CD for quite a while. After some discussion\n> on IRC I think we\'ll end up having to leave this backwards incompatible\n> change in there - given there are most likely users who now rely on\n> both sets of behaviour there is no good way to get out of this\n> situation. I\'ve added a note to the Icehouse release notes.\n\nI still think reverting before release is an option we should consider.\nMy point is, yes we broke it back in October for people doing CD (and\nthey might by now have gotten used to it), if we let this to release\nwe\'ll then break it for everyone else.\n\nWe put a high emphasis into guaranteeing backward compatibility between\nreleases. I think there would be more damage done if we let this sail to\nrelease, compared to the damage of reverting CD followers to pre-October\nbehavior...\n\n-- \nThierry Carrez (ttx)\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<532AC82E.3010407@openstack.org>',NULL),('<1622271862.100.1383977592892.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-09 06:13:12',0,'2013-11-09 06:13:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #42','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/42/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50d1dd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x50d1dd0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46cda90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46cda90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-72020da0-028f-4f1b-b5cc-dcf1b7262d0b\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x2ea18c0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x2ea18c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x2ea18c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x2ea18c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:12:36Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'36\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'36\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:12:36Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'36\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'36\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:12:36+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'36\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'36\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:12:36-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'36\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'36\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:12:36Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'36\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'36\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x520a6d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1a422d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.24 secs:\n    25.87    TestScrubber.test_scrubber_app\n    20.23    TestScrubber.test_delayed_delete\n    15.75    TestGlanceControl.test_respawn\n    15.66    TestGlanceControl.test_reload\n    13.74    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1109 tests in 616.616s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.42\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.1DD7sHhrTg\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/42/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise2/42\n[SCP] Copying console log.\n\n\n','<1803699183.97.1383891252948.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1622857209.6335019.1405337079572.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-14 07:24:39',-14400,'2014-07-14 11:24:39',NULL,'[openstack-dev] [neutron] Spec Proposal Deadline has passed,\n a note on Spec Approval Deadline','The oslo-rootwrap spec counterpart of this\nspec has been approved:\n\nhttps://review.openstack.org/#/c/94613/\n\nCheers :-)\n\n----- Original Message -----\n> Yurly, thanks for your spec and code! I\'ll sync with Carl tomorrow on this\n> and see how we can proceed for Juno around this.\n> \n> \n> On Sat, Jul 12, 2014 at 10:00 AM, Carl Baldwin < carl at ecbaldwin.net > wrote:\n> \n> \n> \n> \n> +1 This spec had already been proposed quite some time ago. I\'d like to see\n> this work get in to juno.\n> \n> Carl\n> On Jul 12, 2014 9:53 AM, \"Yuriy Taraday\" < yorik.sar at gmail.com > wrote:\n> \n> \n> \n> Hello, Kyle.\n> \n> On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery < mestery at noironetworks.com >\n> wrote:\n> \n> \n> Just a note that yesterday we passed SPD for Neutron. We have a\n> healthy backlog of specs, and I\'m working to go through this list and\n> make some final approvals for Juno-3 over the next week. If you\'ve\n> submitted a spec which is in review, please hang tight while myself\n> and the rest of the neutron cores review these. It\'s likely a good\n> portion of the proposed specs may end up as deferred until \"K\"\n> release, given where we\'re at in the Juno cycle now.\n> \n> Thanks!\n> Kyle\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> Please don\'t skip my spec on rootwrap daemon support:\n> https://review.openstack.org/#/c/93889/\n> It got -2\'d my Mark McClain when my spec in oslo wasn\'t approved but now\n> that\'s fixed but it\'s not easy to get hold of Mark.\n> Code for that spec (also -2\'d by Mark) is close to be finished and requires\n> some discussion to get merged by Juno-3.\n> \n> --\n> \n> Kind regards, Yuriy.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CADEmHi34_RGdrHkVvxON1tKNvFn4N+TeJ93_oX3mrq4E51W05Q@mail.gmail.com>',NULL),('<1623945297.8343764.1354109913296.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-28 08:38:33',-18000,'2012-11-28 13:38:33',NULL,'[openstack-dev] [ceilometer] The reset on the cumulative counter','\n> > > That doesn\'t work if different collector instances receive\n> > > events from the same meter on the same resource in\n> > > parallel (which could happen easily if the queue gets\n> > > backed up).\n> >\n> > It does if you don\'t try to cache locally but request the\n> > last value From the storage backend, right? \n>\n> There\'s a race condition, though. If you and I are processing events\n> at the same time, we get the same \"last value\" from the storage but\n> then try to update it to our current value.\n\nYeah, I think it would be possible to disambiguate with the timestamp\nas long as only two events are mis-ordered (as the older last_value\ncan always be recovered from the more recent last_value - delta).\n\nHowever that approach wouldn\'t extend to t2,t0,t1 style misorderings\n(if such a thing has a non-zero probability of occurring) and the\nproblem quickly becomes intractable.\n\nSo sounds like the delta would be calculated at source to be 100%\nrock-solid.\n\nCheers,\nEoghan\n\n\n','<CADb+p3TMGB8QYVScK6g1u_h-QCAO0Of=vDnBUd_vkVReJs3pOw@mail.gmail.com>',NULL),('<1624397192.50.1375682578683.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-05 06:02:58',0,'2013-08-05 06:02:58',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #311','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/311/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-182628 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #213152 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stable-folsom] $ /bin/bash -xe /tmp/hudson841906055212662034.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stable-folsom] $ /bin/bash -xe /tmp/hudson40758857952998861.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az1-182628\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az1-182628/311\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az1-182628/311/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/devstack-precise-hpcloud-az1-182628/311/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1624692138.941799.1348493747389.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-24 09:35:47',-14400,'2012-09-24 13:35:47',NULL,'[openstack-dev] [heat-api] Proposed heat watch/monitoring\n architectural changes','\n\n> I have been looking at a rework of the current heat-api internal\n> architecture to better support our alarm/metric-collection\n> facilities.\n> \n> There has been some discussion within the team, but I\'d like to\n> ensure we\n> have a proper discussion with the whole team and any community\n> members\n> who may be able to contribute ideas, before I proceed with what will\n> be\n> fairly major rework.\n> \n> I know that asalkeld was in discussion with the ceilometer project re\n> merging some of these features into ceilometer, my understanding is\n> that\n> this is unlikely in the short/medium term, hence the proposed changes\n> below, please advise if anyone knows different :)\n> \n> The aim of this rework is as follows:\n> - Provide a better/more-complete Cloudwatch API implementation\n> - Provide an openstack specific ReST API to the Cloudwatch features\n> and\n>   data\n> - Separate ochestration (stack+resource management) from monitoring\n>   (metrics+alarms), aim is to simplify the code, and to provide\n>   better\n>   scalability and performance\n> - Replace the current metadata server, since it combines\n>   resource-metadata and monitoring, and does not authenticate client\n>   connections\n> \n> The proposed changes are illustrated in the following diagram:\n> https://github.com/hardys/diagrams/blob/master/PNG/architecture-overview.png\n> \n> Compare with our current architecture diagram:\n> https://github.com/heat-api/diagrams/blob/master/PNG/architecture-overview.png\n> \n> Summary of proposed changes:\n> - Move resource metadata features of the current metadata-server API\n> into\n>   the new heat ReST API\n> - Modify our cfn-hup implementation to retrieve metadata from the\n> heat\n>   ReST API\n> - Modify our cfn-signal implementation to send WaitCondition metadata\n> to\n>   the heat ReST API, longer term it may be better if the\n>   WaitCondition\n>   implementation is modified to use a Watch rule instead of writing\n>   the\n>   resource metadata.\n> - Move the metric and alarm/watch features of the metadata server\n> into\n>   the Watch API (we already have a Cloudwatch compatible API  which\n>   supports this functionality, medium term perhaps using the proposed\n>   new\n>   Watch ReST API would be better)\n> - Modify our cfn-push-stats implementation to send data to the Watch\n> API\n> - Separate out the metric/watch/alarm heat-engine features into a new\n>   process/daemon (\"Watch Engine\" in the diagram)\n> - Separate the current watch_rule and watch_data tables from the main\n>   heat DB into a watch-specific separarate DB\n> - Rework the watch DB schema, as it\'s currently non-ideal, and\n> doesn\'t\n>   allow us to store event transitions/history which is required for a\n>   complete cloudwatch API implementation\n\nHi Steve,\n\nThis proposed separation is much better than deeply embedding\nthe CloudWatch API implementation within Heat.\n\nHowever, since metrics collection & alarming have much wider\napplicability than their use within orchestration, would it\nmake sense to go one step further and hive off the CW/CWA-\nrelated logic into a completely separate infrastructure that\ncould be independently deployed and be developed in parallel\nwith the Heat project?\n\nCheers,\nEoghan\n\n\n> - Figure out a scheme to put credentials on each instance, so they\n> can\n>   authenticate with the heat/watch APIs\n> \n> The final item is the one I am least clear about, we seem to need the\n> following:\n> - Either per-stack or per-instance credentials, created at stack\n> creation\n>   time\n> - Credentials deployed to the instance in a secure way\n> - Credentials must not expire, or have to be refreshed (e.g via\n> cfn-hup)\n>   in a reliable way.\n> - Note we cannot deploy the initial credentials via cfn-hup since it\n> will\n>   now require credentials (chicken/egg!)\n> \n> Does anyone have any thoughts about the best way to deploy the\n> credentials to each instance?\n> \n> If anyone has any thoughts, suggestions or comments on any of the\n> above\n> (and particularly on the credentials management), they would be\n> appreciated :)\n> \n> Steve\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<20120924130119.GB30634@s01.fab.redhat.com>',NULL),('<1625003530.9.1371709260229.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-20 06:21:00',0,'2013-06-20 06:21:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #262','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/262/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:33599\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:33599/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (29070) wsgi starting up on http://127.0.0.1:33599/\n\nnova.osapi_compute.wsgi.server: INFO: (29070) accepted (\'127.0.0.1\', 39967)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [20/Jun/2013 06:15:50] \"GET /v2 HTTP/1.1\" 204 216 0.000762\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-9e4eeb13-7e3a-499f-a841-fec5fc0c014b</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (29070) accepted (\'127.0.0.1\', 39968)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x804ecd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x804ecd0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:33599/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-20 06:15:50 29070 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:33599/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [20/Jun/2013 06:15:50] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.227738\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 694688edfa604410a09b6889696c71cd \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:36551\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:36551/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (29070) wsgi starting up on http://127.0.0.1:36551/\n\nnova.osapi_compute.wsgi.server: INFO: (29070) accepted (\'127.0.0.1\', 35711)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [20/Jun/2013 06:15:50] \"GET /v2 HTTP/1.1\" 204 216 0.000941\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-32bf8f60-e1b4-4b0e-be8c-38ffe97c753c</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (29070) accepted (\'127.0.0.1\', 35712)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x80392d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x80392d0>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:36551/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     name)\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-20 06:15:51 29070 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:36551/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [20/Jun/2013 06:15:51] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.296342\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.dZdVmixwtG\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/262\n[SCP] Copying console log.\n\n\n','<1789926283.3.1371623028405.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1625064993.45.1378620723032.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-08 06:12:03',0,'2013-09-08 06:12:03',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #20','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/20/>\n\n------------------------------------------\n[...truncated 1175 lines...]\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.00\n    test_no_key                                                  OK    0.00\n    test_no_user                                                 OK    0.00\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.00\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.21\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_cache_middleware.TestImageCacheManageXattr.test_cache_manage_delete_cached_images\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 412, in test_cache_manage_delete_cached_images\n    self.verify_no_images()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/test_cache_middleware.py\",> line 233, in verify_no_images\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.20 secs:\n    26.29    TestScrubber.test_scrubber_app\n    20.77    TestScrubber.test_delayed_delete\n    14.86    TestGlanceControl.test_reload\n    14.70    TestRootApi.test_version_configurations\n    14.58    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 613.294s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.20\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.jdfu86vsWw\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/20/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-12/20\n[SCP] Copying console log.\n\n\n','<1334836762.38.1378361932206.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<162642CFACE02242ACAE35250B43E3548D10DEE9@GRUPRD8011MB604.lamprd80.prod.outlook.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-05-21 02:48:00',0,'2013-05-21 02:48:00',NULL,'[openstack-community] Mailing lists in non-English languages','Hello Stefano,\n\nI\'m from Brazil and it would be great to have a list in our native language (Brazilian Portuguese).\nWe could also suggest a web site such as br.openstack.org in Portuguese to help garnering attention to the Openstack project in our country. We have lot of people that do not speak English here.\nAdditionally, I can help offering a server to run the mailman list and a webserver in my company, if necessary.\n\nPlease let me know if I can help you to make this idea happen.\n\nThank you,\n\nC?sar Schmitzhaus\nCoordenador de Tecnologia\n\nTeltec Solutions\nFone: 48 3031.3450? | DDR: 471? |? Cel: 48 9108.7855\n\n\n\n\n-----Original Message-----\nFrom: Stefano Maffulli [mailto:stefano at openstack.org] \nSent: segunda-feira, 20 de maio de 2013 18:21\nTo: Community User Groups, OpenStack\nSubject: [openstack-community] Mailing lists in non-English languages\n\nHello folks,\n\nI would like to test the idea of opening the list server lists.openstack.org to mailing lists in other languages than English.\n\nAt the moment lists.openstack.org only supports English for the user interfaces, archives included. But mailman supports also different languages and our international community is growing, so I think it shouldn\'t be too hard to help discussions happen in other languages.\n\nDo you think it would be useful for your groups to have one place hosted by on the OpenStack infrastructure, where discussions can happen in your local language?\n\n/stef\n\n--\nAsk and answer questions on https://ask.openstack.org\n\n_______________________________________________\nCommunity mailing list\nCommunity at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/community\n\n\n\n\n','<519A93D5.3040207@openstack.org>',NULL),('<1626634108.2216743.1417445248237.JavaMail.yahoo@jws10964.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-01 14:47:28',0,'2014-12-01 14:47:28',NULL,'[Openstack] failing to boot instance \"message\": \"No valid host\n was found. There are not enough hosts available.\"','?erl.crash?http://paste.openstack.org/show/142629/\n\n\nRegards\nNeelu \n\n     On Monday, 1 December 2014 9:35 AM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n   \n\n Sure I try it out.?\nI getting this error when i run ./stack.sh on the controller node I am looking into it.?\n[neelumadhu at controller devstack]$ sudo systemctl -l status rabbitmq-server.servicerabbitmq-server.service - RabbitMQ broker? ?Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled)? ?Active: failed (Result: exit-code) since Mon 2014-12-01 09:29:22 EST; 23s ago? Process: 11842 ExecStop=/usr/lib/rabbitmq/bin/rabbitmqctl stop (code=exited, status=1/FAILURE)? Process: 11806 ExecStart=/usr/lib/rabbitmq/bin/rabbitmq-server (code=exited, status=1/FAILURE)?Main PID: 11806 (code=exited, status=1/FAILURE)\nDec 01 09:29:22 controller rabbitmqctl[11842]: {error_logger,{{2014,12,1},{9,29,22}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{\"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only\",[{auth,init_cookie,0,[{file,\"auth.erl\"},{line,285}]},{auth,init,1,[{file,\"auth.erl\"},{line,139}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}]}},{offender,[{pid,undefined},{name,auth},{mfargs,{auth,start_link,[]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]}Dec 01 09:29:22 controller rabbitmqctl[11842]: {error_logger,{{2014,12,1},{9,29,22}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,{shutdown,{failed_to_start_child,auth,{\"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only\",[{auth,init_cookie,0,[{file,\"auth.erl\"},{line,285}]},{auth,init,1,[{file,\"auth.erl\"},{line,139}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}]}}}},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]}Dec 01 09:29:22 controller rabbitmqctl[11842]: {error_logger,{{2014,12,1},{9,29,22}},crash_report,[[{initial_call,{application_master,init,[\'Argument__1\',\'Argument__2\',\'Argument__3\',\'Argument__4\']}},{pid,<0.9.0>},{registered_name,[]},{error_info,{exit,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,auth,{\"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only\",[{auth,init_cookie,0,[{file,\"auth.erl\"},{line,285}]},{auth,init,1,[{file,\"auth.erl\"},{line,139}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}]}}}}},{kernel,start,[normal,[]]}},[{application_master,init,4,[{file,\"application_master.erl\"},{line,133}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}]}},{ancestors,[<0.8.0>]},{messages,[{\'EXIT\',<0.10.0>,normal}]},{links,[<0.8.0>,<0.7.0>]},{dictionary,[]},{trap_exit,true},{status,running},{heap_size,987},{stack_size,27},{reductions,165}],[]]}Dec 01 09:29:22 controller rabbitmqctl[11842]: {error_logger,{{2014,12,1},{9,29,22}},std_info,[{application,kernel},{exited,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,auth,{\"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only\",[{auth,init_cookie,0,[{file,\"auth.erl\"},{line,285}]},{auth,init,1,[{file,\"auth.erl\"},{line,139}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,239}]}]}}}}},{kernel,start,[normal,[]]}}},{type,permanent}]}Dec 01 09:29:22 controller rabbitmqctl[11842]: {\"Kernel pid terminated\",application_controller,\"{application_start_failure,kernel,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,auth,{\\\"Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only\\\",[{auth,init_cookie,0,[{file,\\\"auth.erl\\\"},{line,285}]},{auth,init,1,[{file,\\\"auth.erl\\\"},{line,139}]},{gen_server,init_it,6,[{file,\\\"gen_server.erl\\\"},{line,304}]},{proc_lib,init_p_do_apply,3,[{file,\\\"proc_lib.erl\\\"},{line,239}]}]}}}}},{kernel,start,[normal,[]]}}}\"}Dec 01 09:29:22 controller rabbitmqctl[11842]: Crash dump was written to: erl_crash.dumpDec 01 09:29:22 controller rabbitmqctl[11842]: Kernel pid terminated (application_controller) ({application_start_failure,kernel,{{shutdown,{failed_to_start_child,net_sup,{shutdown,{failed_to_start_child,auth,{\"Cookie file /var/lib/rabbitmq/.erlDec 01 09:29:22 controller systemd[1]: rabbitmq-server.service: control process exited, code=exited status=1Dec 01 09:29:22 controller systemd[1]: Failed to start RabbitMQ broker.Dec 01 09:29:22 controller systemd[1]: Unit rabbitmq-server.service entered failed state.[neelumadhu at controller devstack]$?\n\n?\nRegards\nNeelu \n\n     On Monday, 1 December 2014 4:23 AM, Eric Eleazar Perez <ericperez at komiyaph.com> wrote:\n   \n\n Hi,\nYou can paste this on your nova.conf (both nodes) then restart services.\nscheduler_default_filters=AllHostsFilter\nRegards,Eric Perez\nOn Mon, Dec 1, 2014 at 4:31 PM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n\nHi Geo Varghese,?\nNo neutron service I use nova legacy networking. Neutron is disabled.?\n?\nRegards\nNeelu \n\n     On Monday, 1 December 2014 1:35 AM, Geo Varghese <gvarghese at aqorn.com> wrote:\n   \n\n Please paste the output of \n\nneutron agent-list\n\nI think something will be down in it.\n\nOn Sun, Nov 30, 2014 at 5:06 PM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n\nSeems text size was not proper resending it.?\nHi All,?\nI am newbie to openstack, I am trying to get my first istance to boot.? ANy pointers on this will help, thanks in advance\nI see this error while booting.? I have not installed glance or swift on compute node.?On controller node its full stack setup done by devops quick start ..\n\nfault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec,\nopenstack paste link\nPaste #141783 | LodgeIt!\n\n| ? |\n| ? | ? | ? | ? | ? |\n| Paste #141783 | LodgeIt![neelumadhu at localhost devstack]$ nova-manage service list 2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:65 2014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e8... |\n|  |\n| View on?paste.openstack.org | Preview by Yahoo |\n|  |\n| ? |\n\n?\nlogs given below ?with each command?\nOn controller side I have setup using Devops quick start to setup steps.?On compute node I have followed steps mentioned at openstack manual steps.?\n\n\nlogs-----[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29295) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 05:53:28.241 DEBUG oslo.db.sqlalchemy.session [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29295) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:192014-11-30 05:53:28.398 DEBUG nova.servicegroup.drivers.db [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 761.398104 from (pid=29295) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:25nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:19\n\n[neelumadhu at localhost devstack]$ nova image-list+--------------------------------------+---------------------------------+--------+--------+| ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Status | Server |+--------------------------------------+---------------------------------+--------+--------+| db82f672-df9f-403c-a7de-7f0b4ba487d9 | Fedora-x86_64-20-20140618-sda ? | ACTIVE | ? ? ? ?|| 0af91b22-5306-4c97-8761-3800f9029907 | cirros-0.3.2-x86_64-uec ? ? ? ? | ACTIVE | ? ? ? ?|| da9e55ab-f25e-4886-8b75-9fc2e7069cb6 | cirros-0.3.2-x86_64-uec-kernel ?| ACTIVE | ? ? ? ?|| e3f5ef50-433a-4bbd-9007-b1386c129be0 | cirros-0.3.2-x86_64-uec-ramdisk | ACTIVE | ? ? ? ?|+--------------------------------------+---------------------------------+--------+--------+[neelumadhu at localhost devstack]$?\n[neelumadhu at localhost devstack]$ nova boot --flavor 2 --image 0af91b22-5306-4c97-8761-3800f9029907 test44+--------------------------------------+----------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+----------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| scheduling ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| building ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| adminPass ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SUFRq8WmQy3p ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? || image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) || key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || progress ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | BUILD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:32Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+----------------------------------------------------------------+\n\n[neelumadhu at localhost devstack]$ nova show 16e847eb-7f51-48d5-a8b8-cafb99a12605+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| fault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 49, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 35, in __run_method ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? return getattr(self.instance, __name)(*args, **kwargs) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/query.py\\\", line 34, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/rpcapi.py\\\", line 112, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec=request_spec, filter_properties=filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\\\", line 152, in call ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=self.retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py\\\", line 90, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? timeout=timeout, retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 408, in send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 399, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? raise result ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| \", \"created\": \"2014-11-30T10:58:20Z\"} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | d084bb735e188f6a0d20e6485ba7347c6d9cea4ceae2f9763af00b09 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| private network ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:58:19Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+[neelumadhu at localhost devstack]$?\n\n\n[neelumadhu at localhost devstack]$ nova host-list+-----------------------+-------------+----------+| host_name ? ? ? ? ? ? | service ? ? | zone ? ? |+-----------------------+-------------+----------+| localhost.localdomain | conductor ? | internal || localhost.localdomain | cert ? ? ? ?| internal || localhost.localdomain | compute ? ? | nova ? ? || localhost.localdomain | scheduler ? | internal || localhost.localdomain | consoleauth | internal || compute1 ? ? ? ? ? ? ?| network ? ? | internal || compute1 ? ? ? ? ? ? ?| compute ? ? | nova ? ? |+-----------------------+-------------+----------+[neelumadhu at localhost devstack]$ nova service-list+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| Id | Binary ? ? ? ? ? | Host ? ? ? ? ? ? ? ? ?| Zone ? ? | Status ?| State | Updated_at ? ? ? ? ? ? ? ? | Disabled Reason |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| 1 ?| nova-conductor ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 2 ?| nova-cert ? ? ? ?| localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:02:59.000000 | - ? ? ? ? ? ? ? || 3 ?| nova-compute ? ? | localhost.localdomain | nova ? ? | enabled | down ?| - ? ? ? ? ? ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? || 4 ?| nova-scheduler ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 5 ?| nova-consoleauth | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 6 ?| nova-network ? ? | compute1 ? ? ? ? ? ? ?| internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 7 ?| nova-compute ? ? | compute1 ? ? ? ? ? ? ?| nova ? ? | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 06:03:26.915 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29950) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 06:03:26.955 DEBUG oslo.db.api [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29950) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:03:27.400 DEBUG oslo.db.sqlalchemy.session [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29950) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:192014-11-30 06:03:27.669 DEBUG nova.servicegroup.drivers.db [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 1360.669212 from (pid=29950) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26[neelumadhu at localhost devstack]$ nova-manage host list\nhost ? ? ? ? ? ? ? ? ? ?? zone ? ? ? ? ??2014-11-30 06:04:08.471 DEBUG oslo.db.api [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29971) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:04:08.875 DEBUG oslo.db.sqlalchemy.session [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29971) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509localhost.localdomain ? ? internal ? ? ??compute1 ? ? ? ? ? ? ? ?? internal ? ? ??[neelumadhu at localhost devstack]$?[neelumadhu at localhost devstack]$?\n\n\n----------------log ends\nNeelu?\n\n\n     On Sunday, 30 November 2014 6:25 AM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n   \n\n Hi All,?\nI am newbie to openstack, I am trying to get my first istance to boot.? ANy pointers on this will help, thanks in advance\nI see this error while booting.? I have not installed glance or swift on compute node.?On controller node its full stack setup done by devops quick start ..\n\nfault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec,\nopenstack paste link\nPaste #141783 | LodgeIt!\n\n| ? |\n| ? | ? | ? | ? | ? |\n| Paste #141783 | LodgeIt![neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e8... |\n|  |\n| View on paste.openstack.org | Preview by Yahoo |\n|  |\n| ? |\n\n ?\nlogs given below ?with each command?\nOn controller side I have setup using Devops quick start to setup steps.?On compute node I have followed steps mentioned at openstack manual steps.?\n\n\nlogs-----[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 05:53:26.795 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29295) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 05:53:26.860 DEBUG oslo.db.api [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29295) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 05:53:28.241 DEBUG oslo.db.sqlalchemy.session [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29295) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:192014-11-30 05:53:28.398 DEBUG nova.servicegroup.drivers.db [req-e81e7530-7d86-4723-8fcd-e640e4d4838f None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 761.398104 from (pid=29295) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:25nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 10:53:19\n\n[neelumadhu at localhost devstack]$ nova image-list+--------------------------------------+---------------------------------+--------+--------+| ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name ? ? ? ? ? ? ? ? ? ? ? ? ? ?| Status | Server |+--------------------------------------+---------------------------------+--------+--------+| db82f672-df9f-403c-a7de-7f0b4ba487d9 | Fedora-x86_64-20-20140618-sda ? | ACTIVE | ? ? ? ?|| 0af91b22-5306-4c97-8761-3800f9029907 | cirros-0.3.2-x86_64-uec ? ? ? ? | ACTIVE | ? ? ? ?|| da9e55ab-f25e-4886-8b75-9fc2e7069cb6 | cirros-0.3.2-x86_64-uec-kernel ?| ACTIVE | ? ? ? ?|| e3f5ef50-433a-4bbd-9007-b1386c129be0 | cirros-0.3.2-x86_64-uec-ramdisk | ACTIVE | ? ? ? ?|+--------------------------------------+---------------------------------+--------+--------+[neelumadhu at localhost devstack]$?\n[neelumadhu at localhost devstack]$ nova boot --flavor 2 --image 0af91b22-5306-4c97-8761-3800f9029907 test44+--------------------------------------+----------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+----------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| scheduling ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| building ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| adminPass ? ? ? ? ? ? ? ? ? ? ? ? ? ?| SUFRq8WmQy3p ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? || image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) || key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || progress ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | BUILD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:32Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+----------------------------------------------------------------+\n\n[neelumadhu at localhost devstack]$ nova show 16e847eb-7f51-48d5-a8b8-cafb99a12605+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| Property ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+| OS-DCF:diskConfig ? ? ? ? ? ? ? ? ? ?| MANUAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-AZ:availability_zone ? ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:host ? ? ? ? ? ? ? ? | compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:hypervisor_hostname ?| compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| OS-EXT-SRV-ATTR:instance_name ? ? ? ?| instance-00000001 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:power_state ? ? ? ? ? ? ? | 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:task_state ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-EXT-STS:vm_state ? ? ? ? ? ? ? ? ?| error ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:launched_at ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || OS-SRV-USG:terminated_at ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv4 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || accessIPv6 ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || config_drive ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || created ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:56:31Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| fault ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| {\"message\": \"No valid host was found. There are not enough hosts available.\", \"code\": 500, \"details\": \" ?File \\\"/opt/stack/nova/nova/conductor/manager.py\\\", line 632, in build_instances || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 49, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/__init__.py\\\", line 35, in __run_method ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? return getattr(self.instance, __name)(*args, **kwargs) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/client/query.py\\\", line 34, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? context, request_spec, filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/opt/stack/nova/nova/scheduler/rpcapi.py\\\", line 112, in select_destinations ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? request_spec=request_spec, filter_properties=filter_properties) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/client.py\\\", line 152, in call ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=self.retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/transport.py\\\", line 90, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? timeout=timeout, retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 408, in send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? retry=retry) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? File \\\"/usr/lib/python2.7/site-packages/oslo/messaging/_drivers/amqpdriver.py\\\", line 399, in _send ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? raise result ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| \", \"created\": \"2014-11-30T10:58:20Z\"} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || flavor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | m1.small (2) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| hostId ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | d084bb735e188f6a0d20e6485ba7347c6d9cea4ceae2f9763af00b09 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | 16e847eb-7f51-48d5-a8b8-cafb99a12605 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| image ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| cirros-0.3.2-x86_64-uec (0af91b22-5306-4c97-8761-3800f9029907) ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| key_name ? ? ? ? ? ? ? ? ? ? ? ? ? ? | - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || metadata ? ? ? ? ? ? ? ? ? ? ? ? ? ? | {} ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| name ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | test44 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| os-extended-volumes:volumes_attached | [] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| private network ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || security_groups ? ? ? ? ? ? ? ? ? ? ?| default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || status ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ERROR ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? || tenant_id ? ? ? ? ? ? ? ? ? ? ? ? ? ?| e3ae515070c740b89199b8a7e312cb6f ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| updated ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 2014-11-30T10:58:19Z ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| user_id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| 45dfecb18d8a4b069085107f9c2f314a ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|+--------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+[neelumadhu at localhost devstack]$?\n\n\n[neelumadhu at localhost devstack]$ nova host-list+-----------------------+-------------+----------+| host_name ? ? ? ? ? ? | service ? ? | zone ? ? |+-----------------------+-------------+----------+| localhost.localdomain | conductor ? | internal || localhost.localdomain | cert ? ? ? ?| internal || localhost.localdomain | compute ? ? | nova ? ? || localhost.localdomain | scheduler ? | internal || localhost.localdomain | consoleauth | internal || compute1 ? ? ? ? ? ? ?| network ? ? | internal || compute1 ? ? ? ? ? ? ?| compute ? ? | nova ? ? |+-----------------------+-------------+----------+[neelumadhu at localhost devstack]$ nova service-list+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| Id | Binary ? ? ? ? ? | Host ? ? ? ? ? ? ? ? ?| Zone ? ? | Status ?| State | Updated_at ? ? ? ? ? ? ? ? | Disabled Reason |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+| 1 ?| nova-conductor ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 2 ?| nova-cert ? ? ? ?| localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:02:59.000000 | - ? ? ? ? ? ? ? || 3 ?| nova-compute ? ? | localhost.localdomain | nova ? ? | enabled | down ?| - ? ? ? ? ? ? ? ? ? ? ? ? ?| - ? ? ? ? ? ? ? || 4 ?| nova-scheduler ? | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? || 5 ?| nova-consoleauth | localhost.localdomain | internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 6 ?| nova-network ? ? | compute1 ? ? ? ? ? ? ?| internal | enabled | up ? ?| 2014-11-30T11:03:04.000000 | - ? ? ? ? ? ? ? || 7 ?| nova-compute ? ? | compute1 ? ? ? ? ? ? ?| nova ? ? | enabled | up ? ?| 2014-11-30T11:03:06.000000 | - ? ? ? ? ? ? ? |+----+------------------+-----------------------+----------+---------+-------+----------------------------+-----------------+[neelumadhu at localhost devstack]$ nova-manage service list2014-11-30 06:03:26.915 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db from (pid=29950) __new__ /opt/stack/nova/nova/servicegroup/api.py:652014-11-30 06:03:26.955 DEBUG oslo.db.api [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29950) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:03:27.400 DEBUG oslo.db.sqlalchemy.session [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29950) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509Binary ? ? ? ? ? Host ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Zone ? ? ? ? ? ? Status ? ? State Updated_Atnova-conductor ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-cert ? ? ? ?localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:192014-11-30 06:03:27.669 DEBUG nova.servicegroup.drivers.db [req-d76a610c-a3c9-43a3-9d1c-bffb9947de7d None None] Seems service is down. Last heartbeat was 2014-11-30 10:40:47. Elapsed time is 1360.669212 from (pid=29950) is_up /opt/stack/nova/nova/servicegroup/drivers/db.py:75nova-compute ? ? localhost.localdomain ? ? ? ? ? ? ? ?nova ? ? ? ? ? ? enabled ? ?XXX ? None ? ? ?nova-scheduler ? localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26nova-consoleauth localhost.localdomain ? ? ? ? ? ? ? ?internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-network ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:24nova-compute ? ? compute1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? nova ? ? ? ? ? ? enabled ? ?:-) ? 2014-11-30 11:03:26[neelumadhu at localhost devstack]$ nova-manage host list\nhost ? ? ? ? ? ? ? ? ? ?  zone ? ? ? ? ??2014-11-30 06:04:08.471 DEBUG oslo.db.api [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] Loading backend \'sqlalchemy\' from \'nova.db.sqlalchemy.api\' from (pid=29971) _load_backend /usr/lib/python2.7/site-packages/oslo/db/api.py:1822014-11-30 06:04:08.875 DEBUG oslo.db.sqlalchemy.session [req-ae7268ec-7f2b-4515-a444-22d800a14932 None None] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION from (pid=29971) _check_effective_sql_mode /usr/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509localhost.localdomain ? ? internal ? ? ??compute1 ? ? ? ? ? ? ? ?  internal ? ? ??[neelumadhu at localhost devstack]$?[neelumadhu at localhost devstack]$?\n\n\n----------------log ends\nNeelu\n\n    \n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? ?: openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n-- \n--Regards,Geo Varghese\n\n    \n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? ?: openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n\n\n    \n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141201/76a19644/attachment.html>\n\n','<1568245863.2230971.1417444518613.JavaMail.yahoo@jws10928.mail.sg3.yahoo.com>',NULL),('<1626984695.4744083.1405116850286.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-07-11 18:14:10',-14400,'2014-07-11 22:14:10',NULL,'[Openstack-operators] nova-manage service list via API','----- Original Message -----\n> From: \"Gustavo Randich\" <gustavo.randich at gmail.com>\n> To: openstack-operators at lists.openstack.org\n> \n> HI everybody,\n> \n> Seems a simple question but I couldn\'t find the answer in the API reference.\n> \n> Any way to determine a compute node state ( :-) or XXX), same info given by\n> \'nova-manage service list\' but via API?\n> \n> Thanks!\n> Gustavo\n\nStatus is part of the detail returned by:\n\n/v2/?{tenant_id}?/servers/?{server_id}? - Gets details for a specified server. \n\nNote that it returns more descriptive strings (e.g. ACTIVE instead of :-)). See http://developer.openstack.org/api-ref-compute-v2.html for more info.\n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<CABUq5YUAi9=zTf740HhucxQZ2v5iqYsgRgCog5KqoFSNzNm85A@mail.gmail.com>',NULL),('<1627487749.29.1381039322673.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-06 06:02:02',0,'2013-10-06 06:02:02',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #33','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/33/>\n\n\n\n','<1592088827.25.1380952968919.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<16275011-C1F6-4AB5-9BE2-999D4FF6C2FE@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-23 08:54:30',-25200,'2014-07-23 15:54:30',NULL,'[openstack-dev] [swift] Use FQDN in Ring files instead of \"ip\"','Using hostnames instead of IPs is, as mentioned above, something under consideration in that patch.\n\nHowever, note that until now, we\'ve intentionally kept it as just IP addresses since using hostnames adds a lot of operational complexity and burden. I realize that hostnames may be preferred in some cases, but this places a very large strain on DNS systems. So basically, it\'s a question of do we add the feature, knowing that most people who use it will in fact be making their lives more difficult, or do we keep it out, knowing that we won\'t be serving those who actually require the feature.\n\n--John\n\n\n\nOn Jul 23, 2014, at 2:29 AM, Matsuda, Kenichiro <matsuda_kenichi at jp.fujitsu.com> wrote:\n\n> Hi,\n> \n> Thank you for the info.\n> I was able to understand that hostname support is under developing.\n> \n> Best Regards,\n> Kenichiro Matsuda.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/9becc1ac/attachment.pgp>\n\n','<0239431E587EFB4AAC571DD74E73204B151A31C8@G01JPEXMBYT04>',NULL),('<1627660253.4.1373781850262.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-14 06:04:10',0,'2013-07-14 06:04:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #286','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/286/>\n\n------------------------------------------\n[...truncated 2639 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.110.ga45c49b to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.110.ga45c49b\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.3\nBest match: requests 1.2.3\nrequests 1.2.3 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.110.ga45c49b\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.7.g07d13b5 to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.7.g07d13b5\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.7.g07d13b5\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,n-vol =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/rabbitmq/rabbit at devstack-1373779869-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/rabbitmq/rabbit at devstack-1373779869.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/286/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<863873957.1.1373695453021.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1627845892.51024657.1386845768756.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-12 05:56:08',-18000,'2013-12-12 10:56:08',NULL,'[Openstack] [FWaaS] FWaaS in Horizon','\"trinath somanchi\" <trinath.somanchi at freescale.com> wrote:\n> Yes.. The screens are given in the Openstack Wiki Link, but when I install\n> FWaaS , They are not shown in the Horizon.\n> \n> https://wiki.openstack.org/wiki/Quantum/FWaaS/HowToInstall\n\nHi Trinath,\n\nYou should also set the \'enable_firewall\' setting to True in the Horizon\'s\nlocal_settings file [1], and restart your web server.\n\nJulie\n\n[1] https://github.com/openstack/horizon/blob/stable/havana/openstack_dashboard/local/local_settings.py.example#L161\n\n> \n> --\n> Trinath Somanchi - B39208\n> trinath.somanchi at freescale.com | extn: 4048\n> \n> -----Original Message-----\n> From: Matthias Runge [mailto:mrunge at redhat.com]\n> Sent: Thursday, December 12, 2013 2:52 PM\n> To: openstack at lists.openstack.org\n> Subject: Re: [Openstack] [FWaaS] FWaaS in Horizon\n> \n> On 12/12/2013 08:19 AM, trinath.somanchi at freescale.com wrote:\n> \n> > Is there any other installation required for the FWaaS Screens ??\n> > \n> A Havana version of Horizon?\n> \n> Matthias\n> \n> \n\n\n','<e0c14808057b44d3a5a876151c49b9bf@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<1627933779.5874947.1393837984256.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-03 10:13:04',3600,'2014-03-03 09:13:04',NULL,'[openstack-dev] [Neutron] L3 HA VRRP concerns','Hi everyone,\n\nSorry for the late reply, I was on vacation :)\n\nSee, inline comments\n\n-Sylvain\n\n----- Original Message -----\n> From: \"Assaf Muller\" <amuller at redhat.com>\n\n> 1) Is there a way through the API to know, for a given router, what agent is\n> hosting\n> the active instance? This might be very important for admins to know.\n\nDo you mean keepalived active instance or where the active instance was scheduled ?\n\nCurrently only the vrid is returned by the router-show command. I agree with you it\'s a important thing, I\'ll try to address it.\n\n> 2) The current approach is to create an administrative network and subnet for\n> VRRP traffic per router group /\n> per router. Is this network counted in the quota for the tenant? (Clearly it\n> shouldn\'t). Same\n> question for the HA ports created for each router instance.\n\nThe current approach is to create a admin network/subnet per tenant not per router and this admin network/subnet is not set to any tenant.\n \n> 3) The administrative network is created per router and takes away from the\n> VLAN ranges if using\n> VLAN tenant networks (For a tunneling based deployment this is a non-issue).\n> Maybe we could\n> consider a change that creates an administrative network per tenant (Which\n> would then limit\n> the solution to up to 255 routers because of VRRP\'d group limit), or an admin\n> network per 255\n> routers?\n\nsee 2)\n\n> 4) Maybe the VRRP hello and dead times should be configurable? I can see\n> admins that would love to\n> up or down these numbers.\n\nSure, I started to introduce it.\n\n> 5) The administrative / VRRP networks, subnets and ports that are created -\n> Will they be marked in any way\n> as an \'internal\' network or some equivalent tag? Otherwise they\'d show up\n> when running neutron net-list,\n> in the Horizon networks listing as well as the graphical topology drawing\n> (Which, personally, is what\n> bothers me most about this). I\'d love them tagged and hidden from the normal\n> net-list output,\n> and something like a \'neutron net-list --all\' introduced.\n\nI agree, will be a nice improvement, maybe addressed in another BP ?\n\n> 6) The IP subnet chosen for VRRP traffic is specified in neutron.conf. If a\n> tenant creates a subnet\n> with the same range, and attaches a HA router to that subnet, the operation\n> will fail as the router\n> cannot have different interfaces belonging to the same subnet. Nir suggested\n> to look into using\n> the 169.254.0.0/16 range as the default because we know it will (hopefully)\n> not be allocated by tenants\n\nYes we could change the default value in the neutron.conf file.\n\n\n','<1009717727.8187787.1393257496658.JavaMail.zimbra@redhat.com>',NULL),('<1628031799.70.1379494819672.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-18 09:00:19',0,'2013-09-18 09:00:19',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #19','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/19/>\n\n------------------------------------------\n[...truncated 17918 lines...]\n2013-09-18 06:08:08 # If tenant networks are reachable, connectivity checks will be\n2013-09-18 06:08:08 # performed directly against addresses on those networks.\n2013-09-18 06:08:08 tenant_networks_reachable = false\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # Id of the public network that provides external connectivity.\n2013-09-18 06:08:08 public_network_id = \n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # Id of a shared public router that provides external connectivity.\n2013-09-18 06:08:08 # A shared public router would commonly be used where IP namespaces\n2013-09-18 06:08:08 # were disabled.  If namespaces are enabled, it would be preferable\n2013-09-18 06:08:08 # for each tenant to have their own router.\n2013-09-18 06:08:08 public_router_id = \n2013-09-18 06:08:08 \n2013-09-18 06:08:08 \n2013-09-18 06:08:08 [volume]\n2013-09-18 06:08:08 volume_backup_enabled = True\n2013-09-18 06:08:08 # This section contains the configuration options used when executing tests\n2013-09-18 06:08:08 # against the OpenStack Block Storage API service\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-18 06:08:08 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-18 06:08:08 # probably want to leave this value as \"volume\"\n2013-09-18 06:08:08 catalog_type = volume\n2013-09-18 06:08:08 # The disk format to use when copying a volume to image\n2013-09-18 06:08:08 disk_format = raw\n2013-09-18 06:08:08 # Number of seconds to wait while looping to check the status of a\n2013-09-18 06:08:08 # volume that is being made available\n2013-09-18 06:08:08 build_interval = 1\n2013-09-18 06:08:08 # Number of seconds to time out on waiting for a volume\n2013-09-18 06:08:08 # to be available or reach an expected status\n2013-09-18 06:08:08 build_timeout = 400\n2013-09-18 06:08:08 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-18 06:08:08 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-18 06:08:08 # have to be different)\n2013-09-18 06:08:08 multi_backend_enabled = false\n2013-09-18 06:08:08 backend1_name = BACKEND_1\n2013-09-18 06:08:08 backend2_name = BACKEND_2\n2013-09-18 06:08:08 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-18 06:08:08 # You should update to reflect those exported by configured backend driver.\n2013-09-18 06:08:08 storage_protocol = iSCSI\n2013-09-18 06:08:08 vendor_name = Open Source\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 [object-storage]\n2013-09-18 06:08:08 # This section contains configuration options used when executing tests\n2013-09-18 06:08:08 # against the OpenStack Object Storage API.\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # You can configure the credentials in the compute section\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-18 06:08:08 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-18 06:08:08 # this value as \"object-store\"\n2013-09-18 06:08:08 catalog_type = object-store\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # Number of seconds to time on waiting for a container to container\n2013-09-18 06:08:08 # synchronization complete\n2013-09-18 06:08:08 container_sync_timeout = 120\n2013-09-18 06:08:08 # Number of seconds to wait while looping to check the status of a\n2013-09-18 06:08:08 # container to container synchronization\n2013-09-18 06:08:08 container_sync_interval = 5\n2013-09-18 06:08:08 # Set to True if the Account Quota middleware is enabled\n2013-09-18 06:08:08 accounts_quotas_available = True\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # Set operator role for tests that require creating a container\n2013-09-18 06:08:08 operator_role = Member\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 [boto]\n2013-09-18 06:08:08 ssh_user = cirros\n2013-09-18 06:08:08 # This section contains configuration options used when executing tests\n2013-09-18 06:08:08 # with boto.\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # EC2 URL\n2013-09-18 06:08:08 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-18 06:08:08 # S3 URL\n2013-09-18 06:08:08 s3_url = http://127.0.0.1:3333\n2013-09-18 06:08:08 \n2013-09-18 06:08:08 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-18 06:08:08 aws_access =\n2013-09-18 06:08:08 aws_secret =\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Image materials for S3 upload\n2013-09-18 06:08:09 # ALL content of the specified directory will be uploaded to S3\n2013-09-18 06:08:09 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-18 06:08:09 # Subdirectories not allowed!\n2013-09-18 06:08:09 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-18 06:08:09 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-18 06:08:09 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-18 06:08:09 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Instance type\n2013-09-18 06:08:09 instance_type = m1.nano\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # TCP/IP connection timeout\n2013-09-18 06:08:09 http_socket_timeout = 30\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Number of retries actions on connection or 5xx error\n2013-09-18 06:08:09 num_retries = 1\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Status change wait timout\n2013-09-18 06:08:09 build_timeout = 400\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Status change wait interval\n2013-09-18 06:08:09 build_interval = 1\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [orchestration]\n2013-09-18 06:08:09 # Status change wait interval\n2013-09-18 06:08:09 build_interval = 1\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Status change wait timout. This may vary across environments as some some\n2013-09-18 06:08:09 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-18 06:08:09 build_timeout = 300\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Instance type for tests. Needs to be big enough for a\n2013-09-18 06:08:09 # full OS plus the test workload\n2013-09-18 06:08:09 instance_type = m1.micro\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-18 06:08:09 # If not specified, tests that spawn instances will not run\n2013-09-18 06:08:09 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-18 06:08:09 # any key, which will generate a keypair for each test class\n2013-09-18 06:08:09 #keypair_name = heat_key\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [dashboard]\n2013-09-18 06:08:09 # URL where to find the dashboard home page\n2013-09-18 06:08:09 dashboard_url = http://127.0.0.1/\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # URL where to submit the login form\n2013-09-18 06:08:09 login_url = http://127.0.0.1/auth/login/\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [scenario]\n2013-09-18 06:08:09 # Directory containing image files\n2013-09-18 06:08:09 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # AMI image file name\n2013-09-18 06:08:09 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # ARI image file name\n2013-09-18 06:08:09 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # AKI image file name\n2013-09-18 06:08:09 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # ssh username for the image file\n2013-09-18 06:08:09 ssh_user = cirros\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 # specifies how many resources to request at once. Used for large operations\n2013-09-18 06:08:09 # testing.\"\n2013-09-18 06:08:09 large_ops_number = 0\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [cli]\n2013-09-18 06:08:09 # Enable cli tests\n2013-09-18 06:08:09 enabled = True\n2013-09-18 06:08:09 # directory where python client binaries are located\n2013-09-18 06:08:09 cli_dir = /usr/local/bin\n2013-09-18 06:08:09 # Number of seconds to wait on a CLI timeout\n2013-09-18 06:08:09 timeout = 15\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [service_available]\n2013-09-18 06:08:09 # Whether or not cinder is expected to be available\n2013-09-18 06:08:09 cinder = True\n2013-09-18 06:08:09 # Whether or not neutron is expected to be available\n2013-09-18 06:08:09 neutron = False\n2013-09-18 06:08:09 # Whether or not glance is expected to be available\n2013-09-18 06:08:09 glance = True\n2013-09-18 06:08:09 # Whether or not swift is expected to be available\n2013-09-18 06:08:09 swift = True\n2013-09-18 06:08:09 # Whether or not nova is expected to be available\n2013-09-18 06:08:09 nova = True\n2013-09-18 06:08:09 # Whether or not Heat is expected to be available\n2013-09-18 06:08:09 heat = True\n2013-09-18 06:08:09 # Whether or not horizon is expected to be available\n2013-09-18 06:08:09 horizon = True\n2013-09-18 06:08:09 \n2013-09-18 06:08:09 [stress]\n2013-09-18 06:08:09 # Maximum number of instances to create during test\n2013-09-18 06:08:09 max_instances = 32\n2013-09-18 06:08:09 # Time (in seconds) between log file error checks\n2013-09-18 06:08:09 log_check_interval = 60\n2013-09-18 06:08:09 # The default number of threads created while stress test\n2013-09-18 06:08:09 default_thread_number_per_action=4\n2013-09-18 06:08:09 ++ IFS=\' 	\n2013-09-18 06:08:09 \'\n2013-09-18 06:08:09 ++ set +o errexit\n2013-09-18 06:08:09 ++ init_tempest\n2013-09-18 06:08:09 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-18 06:08:09 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-18 06:08:09 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-18 06:08:09 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-18 06:08:09 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-09-18 06:08:09 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-09-18 06:08:09 ++ echo \'Prepare aki/ari/ami Images\'\n2013-09-18 06:08:09 Prepare aki/ari/ami Images\n2013-09-18 06:08:09 ++ cat\n2013-09-18 06:08:09 ++ source /opt/stack/new/devstack/accrc/demo/demo\n2013-09-18 06:08:09 +++ export EC2_ACCESS_KEY=6e1d89bf20d24473bca6a6745a245285\n2013-09-18 06:08:09 +++ EC2_ACCESS_KEY=6e1d89bf20d24473bca6a6745a245285\n2013-09-18 06:08:09 +++ export EC2_SECRET_KEY=967c63a36aca4583b2521c4fe27a47ca\n2013-09-18 06:08:09 +++ EC2_SECRET_KEY=967c63a36aca4583b2521c4fe27a47ca\n2013-09-18 06:08:09 +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-09-18 06:08:09 +++ EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-09-18 06:08:09 +++ export S3_URL=http://127.0.0.1:3333\n2013-09-18 06:08:09 +++ S3_URL=http://127.0.0.1:3333\n2013-09-18 06:08:09 +++ export OS_USERNAME=demo\n2013-09-18 06:08:09 +++ OS_USERNAME=demo\n2013-09-18 06:08:09 +++ export OS_TENANT_NAME=demo\n2013-09-18 06:08:09 +++ OS_TENANT_NAME=demo\n2013-09-18 06:08:09 +++ export OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-09-18 06:08:09 +++ OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-09-18 06:08:09 +++ export EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-09-18 06:08:09 +++ EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-09-18 06:08:09 +++ export EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-09-18 06:08:09 +++ EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-09-18 06:08:09 +++ export EC2_USER_ID=42\n2013-09-18 06:08:09 +++ EC2_USER_ID=42\n2013-09-18 06:08:09 +++ export EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-18 06:08:09 +++ EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-18 06:08:09 +++ export NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-18 06:08:09 +++ NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-18 06:08:09 +++ export OS_PASSWORD=secret\n2013-09-18 06:08:09 +++ OS_PASSWORD=secret\n2013-09-18 06:08:09 ++ euca-bundle-image -i /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz --kernel true -d /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-18 06:08:09 Checking image\n2013-09-18 06:08:09 Encrypting image\n2013-09-18 06:08:09 Splitting image...\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1771.gb17460e.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-316140\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-316140/19\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-316140/19/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-316140/19/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-316140/19/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1632927986.68.1379408417520.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1628340057.36.1374645739207.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-24 06:02:19',0,'2013-07-24 06:02:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-grizzly #105','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/105/changes>\n\nChanges:\n\n[ryan.petrello] Fix a few visual issues on the network topology diagram.\n\n------------------------------------------\n[...truncated 60 lines...]\n  Running setup.py egg_info for package Django\nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth>=1.0.7,!=1.1.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.0.11.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\nDownloading/unpacking netaddr (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package netaddr\n    warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n    warning: no previously-included files matching \'*.git*\' found anywhere in distribution\nDownloading/unpacking python-cinderclient>=1.0.2,<2.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-cinderclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-glanceclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-tMxvkg/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-tMxvkg/d2to1-0.2.10/egg-dist-tmp-iJtf89\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-aJ3tDY/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-aJ3tDY/setuptools-git-1.0/egg-dist-tmp-9pSKpC\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-keystoneclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient>=2.12.0,<3 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-novaclient/setuptools_git-1.0-py2.6.egg>\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-laf8f0/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-laf8f0/d2to1-0.2.10/egg-dist-tmp-qzRgFV\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-MkY3it/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-MkY3it/setuptools-git-1.0/egg-dist-tmp-Nsxhmo\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-quantumclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 11))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/pbr-0.5.19-py2.6.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-XQoLi3/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-XQoLi3/d2to1-0.2.10/egg-dist-tmp-_iBxGH\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/d2to1-0.2.10-py2.6.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/tmp.rlFWojQfEr/easy_install-gyGbqv/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/tmp.rlFWojQfEr/easy_install-gyGbqv/setuptools-git-1.0/egg-dist-tmp-5cxIXF\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/.tox/py26/build/python-swiftclient/setuptools_git-1.0-py2.6.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib64/python2.6/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib64/python2.6/multiprocessing/util.py\", line 258, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires> (line 12))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.rlFWojQfEr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-grizzly/105\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1628805766.34.1355789841765.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-18 00:17:21',0,'2012-12-18 00:17:21',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #78','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/78/>\n\n\n\n','<711498374.12.1355702595722.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<162A8B27-7CD2-40FB-9990-535BFFF015E2@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-23 06:12:16',-14400,'2014-04-23 10:12:16',NULL,'[OpenStack-Infra] establishing a standing policy for approving\n	new oslo library imports','\n\n> On Apr 23, 2014, at 4:39 AM, Thierry Carrez <thierry at openstack.org> wrote:\n> \n> Doug Hellmann wrote:\n>> Can we establish a standing policy that imports for new oslo libraries\n>> won\'t happen until I vote +1 the changeset? I can try to keep up and\n>> -1 until the team has a chance to review it, but I\'m worried that I\n>> may miss an update to a changeset.\n> \n> You mean for the requirements repository ?\n\nNo, sorry I wasn\'t clear. I mean for the config repo for changes that create new oslo source repositories. \n\nDoug\n\n> \n> -- \n> Thierry Carrez (ttx)\n> \n> _______________________________________________\n> OpenStack-Infra mailing list\n> OpenStack-Infra at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra\n\n\n','<53577C41.6090206@openstack.org>',NULL),('<1630400394.74.1386828152137.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-12 06:02:32',0,'2013-12-12 06:02:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-keystone-docs-havana #3','See <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/3/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise1 in workspace <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/>\nCheckout:periodic-keystone-docs-havana / <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/> - hudson.remoting.Channel at 65fcfa01:precise1\nUsing strategy: Default\nLast Built Revision: Revision d9272736ab785e6abab84eb1b9df6f4d00da3b10 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/keystone\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/keystone\nCommencing build of Revision d9272736ab785e6abab84eb1b9df6f4d00da3b10 (origin/stable/havana)\nChecking out Revision d9272736ab785e6abab84eb1b9df6f4d00da3b10 (origin/stable/havana)\n[periodic-keystone-docs-havana] $ /bin/bash -xe /tmp/hudson6063318233190682587.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=keystone\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n++ org=openstack\n++ project=keystone\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=keystone\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z keystone ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/keystone /opt/requirements/projects.txt\nopenstack/keystone\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nvenv create: <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/test-requirements.txt>\nvenv develop-inst: <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-havana/precise1\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-havana/precise1/3\n[SCP] Copying console log.\n\n\n','<415404559.60.1386741800101.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1630482965.219.1366351541889.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-19 06:05:41',0,'2013-04-19 06:05:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #9','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/9/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-19 06:05:36    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:05:36,517 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-19 06:05:36,518 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:05:36,518 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,519 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,519 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-19 06:05:36,520 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-19 06:05:36,520 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-19 06:05:36  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-19 06:05:36,521 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:05:36    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-19 06:05:36,522 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,524 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.524811\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.524811\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36,525 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,526 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,527 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,528 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36,528 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.528047\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.528047\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36,529 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,530 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,530 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:05:36,531 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,531 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,532 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36,533 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.532602\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.532602\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36,534 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,534 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,535 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:05:36,535 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,536 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,537 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36,538 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.537307\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.537307\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36,538 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,539 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,540 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:05:36,540 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,541 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,542 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-19 06:05:36,543 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-19 06:05:36,543 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.543051\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-19T06:05:36.543051\', resource_metadata={}) from 0 transformer\n2013-04-19 06:05:36,544 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,545 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36,545 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-19 06:05:36,546 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-19 06:05:36,546 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-19 06:05:36    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 16.971s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.9\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a329.g7c2b662\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.lwPlXynxwz\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/9\n[SCP] Copying console log.\n\n\n','<894354082.200.1366265141523.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1630532.Nxo50OVooN@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-11 20:03:34',7200,'2014-10-11 18:03:34',NULL,'[Openstack] [openstacl][neutron][ml2][vlan]','Hello,\n\nCheck in neutron-server logs why port is not bind correctly on host.\n\n---\nBest regards\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\nDnia sobota, 11 pa?dziernika 2014 04:37:50 Chinasubbareddy M pisze:\n> Hi ,\n> \n> When I am configuring ML2 plugin with vlan based network ,  nova boot is\n> failing with following error ,where as if I change the driver from ML2 to\n> OVS  , things are working fine . Please suggest.\n> \n> \n> Here is the ml2 configuration:\n> \n> [ml2]\n> type_drivers = vlan\n> tenant_network_types = vlan\n> mechanism drivers = openvswitch\n> [ml2_type_vlan]\n> network_vlan_ranges = physnet1:1:4094\n> [ovs]\n> tenant_network_type = vlan\n> network_vlan_ranges = physnet1:1:4094\n> bridge_mappings = physnet1:br-eth1\n> [securitygroup]\n> firewall_driver =\n> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver\n> enable_security_group = True\n> \n> /etc/neutron/neutron.conf:\n> core_plugin = ml2\n> service_plugins = router\n> allow_overlapping_ips = True\n> \n> \n> logs:\n> \n> \n> root at build-server:/etc/init# grep -ir \"241e4c21-5604-4a1b-a782-f44128fbd0b3\"\n> /var/log/nova/* /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053\n> 21941 ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821\n> 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0]\n> [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Instance failed to spawn\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> Traceback (most recent call last):\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720,\n> in _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n>     block_device_info) /var/log/nova/nova-compute.log:2014-09-11\n> 02:41:23.053 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250,\n> in spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> write_to_disk=True) /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431,\n> in to_xml /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n>     disk_info, rescue, block_device_info)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n> 3247, in get_guest_config /var/log/nova/nova-compute.log:2014-09-11\n> 02:41:23.053 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384,\n> in get_config /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941\n> TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n>     _(\"Unexpected vif_type=%s\") % vif_type)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> NovaException: Unexpected vif_type=binding_failed\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.053 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:23.877 21941 ERROR\n> nova.virt.libvirt.driver [-] [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance\n> disappeared. /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> ERROR nova.compute.manager [req-f4550d18-b37c-4dc6-9544-a9e8b2e38821\n> 5249dfc7f6c34fe68f98cfe60f82b331 22ad3f28f8f24b7fb14f17af44aa55f0]\n> [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3] Error: Unexpected\n> vif_type=binding_failed /var/log/nova/nova-compute.log:2014-09-11\n> 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3] Traceback (most recent call last):\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1311,\n> in _build_instance /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]     set_access_ip=set_access_ip)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 399,\n> in decorated_function /var/log/nova/nova-compute.log:2014-09-11\n> 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]     return function(self, context,\n> *args, **kwargs) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1723, in\n> _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> LOG.exception(_(\'Instance failed to spawn\'), instance=instance)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/openstack/common/excutils.py\",\n> line 68, in __exit__ /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]     six.reraise(self.type_,\n> self.value, self.tb) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/compute/manager.py\", line 1720, in\n> _spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> block_device_info) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 2250,\n> in spawn /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]    \n> write_to_disk=True) /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275\n> 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]   File\n> \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line 3431,\n> in to_xml /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n>     disk_info, rescue, block_device_info)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py\", line\n> 3247, in get_guest_config /var/log/nova/nova-compute.log:2014-09-11\n> 02:41:24.275 21941 TRACE nova.compute.manager [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3]     flavor)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]  \n> File \"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py\", line 384,\n> in get_config /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941\n> TRACE nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n>     _(\"Unexpected vif_type=%s\") % vif_type)\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> NovaException: Unexpected vif_type=binding_failed\n> /var/log/nova/nova-compute.log:2014-09-11 02:41:24.275 21941 TRACE\n> nova.compute.manager [instance: 241e4c21-5604-4a1b-a782-f44128fbd0b3]\n> /var/log/nova/nova-compute.log:2014-09-11 02:50:44.135 23339 ERROR\n> nova.virt.libvirt.driver [-] [instance:\n> 241e4c21-5604-4a1b-a782-f44128fbd0b3] During wait destroy, instance\n> disappeared.\n> \n> \n> Regards,\n> Subbareddy\n> Persistent systems ltd.\n> \n> \n> DISCLAIMER\n> ==========\n> This e-mail may contain privileged and confidential information which is the\n> property of Persistent Systems Ltd. It is intended only for the use of the\n> individual or entity to which it is addressed. If you are not the intended\n> recipient, you are not authorized to read, retain, copy, print, distribute\n> or use this message. If you have received this communication in error,\n> please notify the sender and delete all copies of this message. Persistent\n> Systems Ltd. does not accept any liability for virus infected mails.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141011/b2e8b157/attachment.pgp>\n\n','<00f51a0831764790b071eeb81d864dbf@HKXPR04MB183.apcprd04.prod.outlook.com>',NULL),('<16305400.31.1387087517107.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:05:17',0,'2013-12-15 06:05:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-docs-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/6/>\n\n------------------------------------------\n[...truncated 489 lines...]\nGenerating doc/source/api/nova.tests.fake_hosts.rst\nGenerating doc/source/api/nova.tests.fake_imagebackend.rst\nGenerating doc/source/api/nova.tests.fake_instance_actions.rst\nGenerating doc/source/api/nova.tests.fake_ldap.rst\nGenerating doc/source/api/nova.tests.fake_libvirt_utils.rst\nGenerating doc/source/api/nova.tests.fake_loadables.fake_loadable1.rst\nGenerating doc/source/api/nova.tests.fake_loadables.fake_loadable2.rst\nGenerating doc/source/api/nova.tests.fake_network.rst\nGenerating doc/source/api/nova.tests.fake_network_cache_model.rst\nGenerating doc/source/api/nova.tests.fake_policy.rst\nGenerating doc/source/api/nova.tests.fake_utils.rst\nGenerating doc/source/api/nova.tests.fake_volume.rst\nGenerating doc/source/api/nova.tests.fakeguestfs.rst\nGenerating doc/source/api/nova.tests.fakelibvirt.rst\nGenerating doc/source/api/nova.tests.glance.stubs.rst\nGenerating doc/source/api/nova.tests.hyperv.db_fakes.rst\nGenerating doc/source/api/nova.tests.hyperv.fake.rst\nGenerating doc/source/api/nova.tests.image.fake.rst\nGenerating doc/source/api/nova.tests.image.test_fake.rst\nGenerating doc/source/api/nova.tests.image.test_glance.rst\nGenerating doc/source/api/nova.tests.image.test_s3.rst\nGenerating doc/source/api/nova.tests.integrated.api.client.rst\nGenerating doc/source/api/nova.tests.integrated.integrated_helpers.rst\nGenerating doc/source/api/nova.tests.integrated.test_api_samples.rst\nGenerating doc/source/api/nova.tests.integrated.test_extensions.rst\nGenerating doc/source/api/nova.tests.integrated.test_login.rst\nGenerating doc/source/api/nova.tests.integrated.test_multiprocess_api.rst\nGenerating doc/source/api/nova.tests.integrated.test_servers.rst\nGenerating doc/source/api/nova.tests.integrated.test_xml.rst\nGenerating doc/source/api/nova.tests.matchers.rst\nGenerating doc/source/api/nova.tests.monkey_patch_example.example_a.rst\nGenerating doc/source/api/nova.tests.monkey_patch_example.example_b.rst\nGenerating doc/source/api/nova.tests.network.security_group.test_quantum_driver.rst\nGenerating doc/source/api/nova.tests.network.test_api.rst\nGenerating doc/source/api/nova.tests.network.test_deprecated_api.rst\nGenerating doc/source/api/nova.tests.network.test_linux_net.rst\nGenerating doc/source/api/nova.tests.network.test_manager.rst\nGenerating doc/source/api/nova.tests.network.test_network_info.rst\nGenerating doc/source/api/nova.tests.network.test_quantumv2.rst\nGenerating doc/source/api/nova.tests.network.test_rpcapi.rst\nGenerating doc/source/api/nova.tests.policy_fixture.rst\nGenerating doc/source/api/nova.tests.scheduler.fakes.rst\nGenerating doc/source/api/nova.tests.scheduler.test_chance_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_filter_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_host_filters.rst\nGenerating doc/source/api/nova.tests.scheduler.test_host_manager.rst\nGenerating doc/source/api/nova.tests.scheduler.test_least_cost.rst\nGenerating doc/source/api/nova.tests.scheduler.test_multi_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_rpcapi.rst\nGenerating doc/source/api/nova.tests.scheduler.test_scheduler.rst\nGenerating doc/source/api/nova.tests.scheduler.test_scheduler_options.rst\nGenerating doc/source/api/nova.tests.scheduler.test_weights.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_db_servicegroup.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_mc_servicegroup.rst\nGenerating doc/source/api/nova.tests.servicegroup.test_zk_driver.rst\nGenerating doc/source/api/nova.tests.test_api.rst\nGenerating doc/source/api/nova.tests.test_availability_zones.rst\nGenerating doc/source/api/nova.tests.test_bdm.rst\nGenerating doc/source/api/nova.tests.test_block_device.rst\nGenerating doc/source/api/nova.tests.test_cinder.rst\nGenerating doc/source/api/nova.tests.test_configdrive2.rst\nGenerating doc/source/api/nova.tests.test_context.rst\nGenerating doc/source/api/nova.tests.test_crypto.rst\nGenerating doc/source/api/nova.tests.test_db_api.rst\nGenerating doc/source/api/nova.tests.test_driver.rst\nGenerating doc/source/api/nova.tests.test_exception.rst\nGenerating doc/source/api/nova.tests.test_fakelibvirt.rst\nGenerating doc/source/api/nova.tests.test_filters.rst\nGenerating doc/source/api/nova.tests.test_hooks.rst\nGenerating doc/source/api/nova.tests.test_hypervapi.rst\nGenerating doc/source/api/nova.tests.test_image_utils.rst\nGenerating doc/source/api/nova.tests.test_imagebackend.rst\nGenerating doc/source/api/nova.tests.test_imagecache.rst\nGenerating doc/source/api/nova.tests.test_instance_types.rst\nGenerating doc/source/api/nova.tests.test_instance_types_extra_specs.rst\nGenerating doc/source/api/nova.tests.test_iptables_network.rst\nGenerating doc/source/api/nova.tests.test_ipv6.rst\nGenerating doc/source/api/nova.tests.test_libvirt.rst\nGenerating doc/source/api/nova.tests.test_libvirt_blockinfo.rst\nGenerating doc/source/api/nova.tests.test_libvirt_config.rst\nGenerating doc/source/api/nova.tests.test_libvirt_utils.rst\nGenerating doc/source/api/nova.tests.test_libvirt_vif.rst\nGenerating doc/source/api/nova.tests.test_libvirt_volume.rst\nGenerating doc/source/api/nova.tests.test_linuxscsi.rst\nGenerating doc/source/api/nova.tests.test_loadables.rst\nGenerating doc/source/api/nova.tests.test_matchers.rst\nGenerating doc/source/api/nova.tests.test_metadata.rst\nGenerating doc/source/api/nova.tests.test_migration_utils.rst\nGenerating doc/source/api/nova.tests.test_migrations.rst\nGenerating doc/source/api/nova.tests.test_misc.rst\nGenerating doc/source/api/nova.tests.test_notifications.rst\nGenerating doc/source/api/nova.tests.test_nova_manage.rst\nGenerating doc/source/api/nova.tests.test_objectstore.rst\nGenerating doc/source/api/nova.tests.test_periodic_tasks.rst\nGenerating doc/source/api/nova.tests.test_pipelib.rst\nGenerating doc/source/api/nova.tests.test_plugin_api_extensions.rst\nGenerating doc/source/api/nova.tests.test_policy.rst\nGenerating doc/source/api/nova.tests.test_powervm.rst\nGenerating doc/source/api/nova.tests.test_quota.rst\nGenerating doc/source/api/nova.tests.test_safeutils.rst\nGenerating doc/source/api/nova.tests.test_service.rst\nGenerating doc/source/api/nova.tests.test_test.rst\nGenerating doc/source/api/nova.tests.test_test_utils.rst\nGenerating doc/source/api/nova.tests.test_utils.rst\nGenerating doc/source/api/nova.tests.test_versions.rst\nGenerating doc/source/api/nova.tests.test_virt.rst\nGenerating doc/source/api/nova.tests.test_virt_disk.rst\nGenerating doc/source/api/nova.tests.test_virt_disk_vfs_guestfs.rst\nGenerating doc/source/api/nova.tests.test_virt_disk_vfs_localfs.rst\nGenerating doc/source/api/nova.tests.test_virt_drivers.rst\nGenerating doc/source/api/nova.tests.test_vmmode.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vif.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vm_util.rst\nGenerating doc/source/api/nova.tests.test_vmwareapi_vmops.rst\nGenerating doc/source/api/nova.tests.test_wsgi.rst\nGenerating doc/source/api/nova.tests.test_xenapi.rst\nGenerating doc/source/api/nova.tests.utils.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_api.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_loop.rst\nGenerating doc/source/api/nova.tests.virt.disk.test_nbd.rst\nGenerating doc/source/api/nova.tests.virt.hyperv.test_vhdutils.rst\nGenerating doc/source/api/nova.tests.virt.test_images.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.imageupload.test_glance.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.test_vm_utils.rst\nGenerating doc/source/api/nova.tests.virt.xenapi.test_volumeops.rst\nGenerating doc/source/api/nova.tests.vmwareapi.db_fakes.rst\nGenerating doc/source/api/nova.tests.vmwareapi.stubs.rst\nGenerating doc/source/api/nova.tests.xenapi.stubs.rst\nGenerating doc/source/api/nova.tests.xenapi.test_vm_utils.rst\nGenerating doc/source/api/nova.utils.rst\nGenerating doc/source/api/nova.version.rst\nGenerating doc/source/api/nova.virt.baremetal.baremetal_states.rst\nGenerating doc/source/api/nova.virt.baremetal.base.rst\nGenerating doc/source/api/nova.virt.baremetal.db.api.rst\nGenerating doc/source/api/nova.virt.baremetal.db.migration.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.api.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.001_init.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.002_drop_bm_deployments.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.003_add_uuid_to_bm_nodes.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migrate_repo.versions.004_add_instance_name_to_bm_nodes.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.migration.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.models.rst\nGenerating doc/source/api/nova.virt.baremetal.db.sqlalchemy.session.rst\nGenerating doc/source/api/nova.virt.baremetal.driver.rst\nGenerating doc/source/api/nova.virt.baremetal.fake.rst\nGenerating doc/source/api/nova.virt.baremetal.ipmi.rst\nGenerating doc/source/api/nova.virt.baremetal.pxe.rst\nGenerating doc/source/api/nova.virt.baremetal.utils.rst\nGenerating doc/source/api/nova.virt.baremetal.vif_driver.rst\nGenerating doc/source/api/nova.virt.baremetal.virtual_power_driver.rst\nGenerating doc/source/api/nova.virt.baremetal.virtual_power_driver_settings.rst\nGenerating doc/source/api/nova.virt.baremetal.volume_driver.rst\nGenerating doc/source/api/nova.virt.configdrive.rst\nGenerating doc/source/api/nova.virt.disk.api.rst\nGenerating doc/source/api/nova.virt.disk.mount.api.rst\nGenerating doc/source/api/nova.virt.disk.mount.loop.rst\nGenerating doc/source/api/nova.virt.disk.mount.nbd.rst\nGenerating doc/source/api/nova.virt.disk.vfs.api.rst\nGenerating doc/source/api/nova.virt.disk.vfs.guestfs.rst\nGenerating doc/source/api/nova.virt.disk.vfs.localfs.rst\nGenerating doc/source/api/nova.virt.driver.rst\nGenerating doc/source/api/nova.virt.event.rst\nGenerating doc/source/api/nova.virt.fake.rst\nGenerating doc/source/api/nova.virt.firewall.rst\nGenerating doc/source/api/nova.virt.hyperv.basevolumeutils.rst\nGenerating doc/source/api/nova.virt.hyperv.constants.rst\nGenerating doc/source/api/nova.virt.hyperv.driver.rst\nGenerating doc/source/api/nova.virt.hyperv.hostops.rst\nGenerating doc/source/api/nova.virt.hyperv.hostutils.rst\nGenerating doc/source/api/nova.virt.hyperv.imagecache.rst\nGenerating doc/source/api/nova.virt.hyperv.livemigrationops.rst\nGenerating doc/source/api/nova.virt.hyperv.livemigrationutils.rst\nGenerating doc/source/api/nova.virt.hyperv.migrationops.rst\nGenerating doc/source/api/nova.virt.hyperv.networkutils.rst\nGenerating doc/source/api/nova.virt.hyperv.pathutils.rst\nGenerating doc/source/api/nova.virt.hyperv.snapshotops.rst\nGenerating doc/source/api/nova.virt.hyperv.vhdutils.rst\nGenerating doc/source/api/nova.virt.hyperv.vif.rst\nGenerating doc/source/api/nova.virt.hyperv.vmops.rst\nGenerating doc/source/api/nova.virt.hyperv.vmutils.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeops.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeutils.rst\nGenerating doc/source/api/nova.virt.hyperv.volumeutilsv2.rst\nGenerating doc/source/api/nova.virt.images.rst\nGenerating doc/source/api/nova.virt.libvirt.blockinfo.rst\nGenerating doc/source/api/nova.virt.libvirt.config.rst\nGenerating doc/source/api/nova.virt.libvirt.designer.rst\nGenerating doc/source/api/nova.virt.libvirt.driver.rst\nGenerating doc/source/api/nova.virt.libvirt.firewall.rst\nGenerating doc/source/api/nova.virt.libvirt.imagebackend.rst\nGenerating doc/source/api/nova.virt.libvirt.imagecache.rst\nGenerating doc/source/api/nova.virt.libvirt.utils.rst\nGenerating doc/source/api/nova.virt.libvirt.vif.rst\nGenerating doc/source/api/nova.virt.libvirt.volume.rst\nGenerating doc/source/api/nova.virt.libvirt.volume_nfs.rst\nGenerating doc/source/api/nova.virt.netutils.rst\nGenerating doc/source/api/nova.virt.powervm.blockdev.rst\nGenerating doc/source/api/nova.virt.powervm.command.rst\nGenerating doc/source/api/nova.virt.powervm.common.rst\nGenerating doc/source/api/nova.virt.powervm.constants.rst\nGenerating doc/source/api/nova.virt.powervm.driver.rst\nGenerating doc/source/api/nova.virt.powervm.exception.rst\nGenerating doc/source/api/nova.virt.powervm.lpar.rst\nGenerating doc/source/api/nova.virt.powervm.operator.rst\nGenerating doc/source/api/nova.virt.storage_users.rst\nGenerating doc/source/api/nova.virt.virtapi.rst\nGenerating doc/source/api/nova.virt.vmwareapi.driver.rst\nGenerating doc/source/api/nova.virt.vmwareapi.error_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.fake.rst\nGenerating doc/source/api/nova.virt.vmwareapi.host.rst\nGenerating doc/source/api/nova.virt.vmwareapi.io_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.network_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.read_write_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vif.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vim.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vim_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vm_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vmops.rst\nGenerating doc/source/api/nova.virt.vmwareapi.vmware_images.rst\nGenerating doc/source/api/nova.virt.vmwareapi.volume_util.rst\nGenerating doc/source/api/nova.virt.vmwareapi.volumeops.rst\nGenerating doc/source/api/nova.virt.xenapi.agent.rst\nGenerating doc/source/api/nova.virt.xenapi.driver.rst\nGenerating doc/source/api/nova.virt.xenapi.fake.rst\nGenerating doc/source/api/nova.virt.xenapi.firewall.rst\nGenerating doc/source/api/nova.virt.xenapi.host.rst\nGenerating doc/source/api/nova.virt.xenapi.imageupload.glance.rst\nGenerating doc/source/api/nova.virt.xenapi.network_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.pool.rst\nGenerating doc/source/api/nova.virt.xenapi.pool_states.rst\nGenerating doc/source/api/nova.virt.xenapi.vif.rst\nGenerating doc/source/api/nova.virt.xenapi.vm_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.vmops.rst\nGenerating doc/source/api/nova.virt.xenapi.volume_utils.rst\nGenerating doc/source/api/nova.virt.xenapi.volumeops.rst\nGenerating doc/source/api/nova.vnc.xvp_proxy.rst\nGenerating doc/source/api/nova.volume.cinder.rst\nGenerating doc/source/api/nova.weights.rst\nGenerating doc/source/api/nova.wsgi.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-grizzly/precise10\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-docs-grizzly/precise10/6\n[SCP] Copying console log.\n\n\n','<242214320.8.1386915569915.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1632314620.2052763.1422482289693.JavaMail.yahoo@mail.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-28 21:58:09',0,'2015-01-28 21:58:09',NULL,'[openstack-dev] [Neutron] fixed ip info shown for port even\n when dhcp is disabled','Some follow up questions on this.\nIn the specs, i see that during a \"create_port\", ?there\'s provisions to query the external source by? \"Pluggable IPAM\" to return the IP.This works fine for cases where the external source (say, DHCP server) can be queried for the IP address when a launch happens.\nIs there a provision to have the flexibility of a \"late IP assignment\"?\n I am thinking of cases, like the temporary unavailability of external IP source or lack of standard interfaces in which case data packet snooping is used to find the IP address of a VM after launch. Something similar to late binding of IP addresses.This means the create_port? may not get the IP address from the pluggable IPAM. In that case, launch of a VM (or create_port) shouldn\'t fail. The Pluggable IPAM should have some provision to return something equivalent to \"unavailable\" during create_port and be able to do an update_port when the IP address becomes available.\nI don\'t see that option. Please correct me if I am wrong.\nThanks,Paddu \n \n\n     On Thursday, December 18, 2014 7:59 AM, Padmanabhan Krishnan <kprad1 at yahoo.com> wrote:\n   \n\n Hi John,Thanks for the pointers. I shall take a look and get back.\nRegards,Paddu\n \n\n     On Thursday, December 18, 2014 6:23 AM, John Belamaric <jbelamaric at infoblox.com> wrote:\n   \n\n Hi Paddu,\nTake a look at what we are working on in Kilo [1] for external IPAM. While this does not address DHCP specifically, it does allow you to use an external source to allocate the IP that OpenStack uses, which may solve your problem.\nAnother solution to your question is to invert the logic - you need to take the IP allocated by OpenStack and program the DHCP server to provide a fixed IP for that MAC.\nYou may be interested in looking at this Etherpad [2] that Don Kehn put together gathering all the various DHCP blueprints and related info, and also at this BP [3] for including a DHCP relay so we can utilize external DHCP more easily.\n[1] https://blueprints.launchpad.net/neutron/+spec/neutron-ipam[2]?https://etherpad.openstack.org/p/neutron-dhcp-org[3]?https://blueprints.launchpad.net/neutron/+spec/dhcp-relay\nJohn\nFrom: Padmanabhan Krishnan <kprad1 at yahoo.com>\nReply-To: Padmanabhan Krishnan <kprad1 at yahoo.com>, \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nDate: Wednesday, December 17, 2014 at 6:06 PM\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Neutron] fixed ip info shown for port even when dhcp is disabled\n\nThis means whatever tools the operators are using, it need to make sure the IP address assigned inside the VM matches with Openstack has assigned to the port.Bringing the question that i had in another thread on the same topic:\nIf one wants to use the provider DHCP server and not have Openstack\'s DHCP or L3 agent/DVR, it may not be possible to do so even with DHCP disabled in Openstack network. Even if the provider DHCP server is configured with the same start/end range in the same subnet, there\'s no guarantee that it will match with Openstack assigned IP address for bulk VM launches or? when there\'s a failure case.So, how does one deploy external DHCP with Openstack?\nIf Openstack hasn\'t assigned a IP address when DHCP is disabled for a network, can\'t port_update be done with the provider DHCP specified IP address to put the anti-spoofing and security rules?With Openstack assigned IP address, port_update cannot be done since IP address aren\'t in sync and can overlap.\nThanks,Paddu\n\n\n\nOn 12/16/14 4:30 AM, \"Pasquale Porreca\" <pasquale.porreca at dektech.com.au>\nwrote:\n\n>I understood and I agree that assigning the ip address to the port is\n>not a bug, however showing it to the user, at least in Horizon dashboard\n>where it pops up in the main instance screen without a specific search,\n>can be very confusing.\n>\n>On 12/16/14 12:25, Salvatore Orlando wrote:\n>> In Neutron IP address management and distribution are separated\n>>concepts.\n>> IP addresses are assigned to ports even when DHCP is disabled. That IP\n>> address is indeed used to configure anti-spoofing rules and security\n>>groups.\n>> \n>> It is however understandable that one wonders why an IP address is\n>>assigned\n>> to a port if there is no DHCP server to communicate that address.\n>>Operators\n>> might decide to use different tools to ensure the IP address is then\n>> assigned to the instance\'s ports. On XenServer for instance one could\n>>use a\n>> guest agent reading network configuration from XenStore; as another\n>> example, older versions of Openstack used to inject network\n>>configuration\n>> into the instance file system; I reckon that today\'s configdrive might\n>>also\n>> be used to configure instance\'s networking.\n>> \n>> Summarising I don\'t think this is a bug. Nevertheless if you have any\n>>idea\n>> regarding improvements on the API UX feel free to file a bug report.\n>> \n>> Salvatore\n>> \n>> On 16 December 2014 at 10:41, Pasquale Porreca <\n>> pasquale.porreca at dektech.com.au> wrote:\n>>>\n>>> Is there a specific reason for which a fixed ip is bound to a port on a\n>>> subnet where dhcp is disabled? it is confusing to have this info shown\n>>> when the instance doesn\'t have actually an ip on that port.\n>>> Should I fill a bug report, or is this a wanted behavior?\n>>>\n>>> --\n>>> Pasquale Porreca\n>>>\n>>> DEK Technologies\n>>> Via dei Castelli Romani, 22\n>>> 00040 Pomezia (Roma)\n>>>\n>>> Mobile +39 3394823805\n>>> Skype paskporr\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>\n>-- \n>Pasquale Porreca\n>\n>DEK Technologies\n>Via dei Castelli Romani, 22\n>00040 Pomezia (Roma)\n>\n>Mobile +39 3394823805\n>Skype paskporr\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n    \n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150128/ca6198fe/attachment.html>\n\n','<1451335840.835432.1418918340043.JavaMail.yahoo@jws10635.mail.bf1.yahoo.com>',NULL),('<1632344.T3h0vTSAW1@laptop>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-09-22 12:35:33',7200,'2014-09-22 10:35:33',NULL,'[Openstack-operators] Openstack and mysql galera with haproxy','Hello,\n\nThanks for Your explanations. I thought so and now I decrease \n\"idle_connection_timeout\" in neutron and nova. Now when master server is back \nto cluster than in less than one minute all conections are again made to this \nmaster node becuase old connections which was made to backup node are closed.\nSo for now it looks almost perfect but when I now testing cluster (with master \nnode active and all connections established to this node) in neutron I still \nsometimes see errors like:\nStaleDataError: UPDATE statement on table \'ports\' expected to update 1 row(s); \n0 were matched.\n\nand also today I found errors like:\n2014-09-22 11:38:05.715 11474 INFO sqlalchemy.engine.base.Engine [-] ROLLBACK\n2014-09-22 11:38:05.784 11474 ERROR \nneutron.openstack.common.db.sqlalchemy.session [-] DB exception wrapped.\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session Traceback (most recent call \nlast):\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-\npackages/neutron/openstack/common/db/sqlalchemy/session.py\", line 524, in \n_wrap\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     return f(*args, **kwargs)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-\npackages/neutron/openstack/common/db/sqlalchemy/session.py\", line 718, in flush\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     return super(Session, \nself).flush(*args, **kwargs)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py\", line 1818, in \nflush\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     self._flush(objects)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py\", line 1936, in \n_flush\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     \ntransaction.rollback(_capture_exception=True)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py\", line 58, in \n__exit__\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     compat.reraise(exc_type, \nexc_value, exc_tb)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py\", line 1900, in \n_flush\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     flush_context.execute()\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py\", line 372, in \nexecute\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     rec.execute(self)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py\", line 525, in \nexecute\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     uow\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py\", line 64, in \nsave_obj\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     table, insert)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py\", line 541, in \n_emit_insert_statements\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     execute(statement, \nmultiparams)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 662, in \nexecute\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     params)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 761, in \n_execute_clauseelement\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     compiled_sql, \ndistilled_params\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 874, in \n_execute_context\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     context)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 1027, in \n_handle_dbapi_exception\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     util.reraise(*exc_info)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py\", line 856, in \n_execute_context\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     context)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/sqlalchemy/connectors/mysqldb.py\", line 60, \nin do_executemany\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     rowcount = \ncursor.executemany(statement, parameters)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session   File \n\"/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py\", line 206, in \nexecutemany\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session     r = r + self.execute(query, \na)\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session TypeError: unsupported operand \ntype(s) for +: \'int\' and \'NoneType\'\n2014-09-22 11:38:05.784 11474 TRACE \nneutron.openstack.common.db.sqlalchemy.session \n\nAnd I have to investigate why it is happening becuase whith single mysql \nserver I have no such errors :/\n\n---\nBest regards\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\nDnia poniedzia?ek, 22 wrze?nia 2014 11:18:27 Peter Boros pisze:\n> Hi,\n> \n> Let me answer this and one of your previous questions in one because\n> they are related.\n> \n> Earlier you wrote:\n> > I made such modifications today in my infra and generally it looks\n> > better now. I don\'t see deadlocks. But I have one more problem with\n> > that: generally it works fine when main node is active but in\n> > situation when this node is down, haproxy connect to one of backup\n> > nodes. Still all is ok but problem is when main node is up again - all\n> > new connections are made to main node but active connections which was\n> > made to backup node still are active and neutron (or nova) are using\n> > connections to two servers and then there are problems with deadlock\n> > again.\n> > Do You know how to prevent such situation?\n> \n> This is because of how haproxy works. Haproxy\'s load balancing is TCP\n> level, once the TCP connection is established, haproxy has nothing to\n> do with it. If the MySQL application (neutron in this case), uses\n> persistent connections, at the time of failing over, haproxy doesn\'t\n> make an extra decision upon failover, because a connection is already\n> established. This can be mitigated by using haproxy 1.5 and defining\n> the backend with on-marked-down shutdown-sessions, this will kill the\n> connections at the TCP level on the formerly active node. Or in case\n> of graceful failover, include killing connections in the failover\n> script on the formerly active node. The application in this case will\n> get error 1 or 2 you described.\n> \n> From your description error 1 and 2 are related to killing\n> connections. Case 1 (MySQL server has gone away) happens when the\n> connection was killed (but not at the MySQL protocol level) while it\n> was idle, and the application is attempting to re-use it. In this case\n> the correct behaviour would be re-establishing the connection. Error 2\n> is the same thing, but while the connection was actually doing\n> something, reconnecting and retrying is the correct behaviour. These\n> errors are not avoidable, if the node dies non-gracefully. A server\n> can for example lose power while doing the transaction, in this case\n> the transaction will be aborted, and the application will get one of\n> the errors described above. The application has to know that the data\n> is not written, since it didn\'t do commit or database didn\'t\n> acknowledge the commit.\n> \n> On Sat, Sep 20, 2014 at 12:11 AM, S?awek Kap?o?ski <slawek at kaplonski.pl> \nwrote:\n> > Hello,\n> > \n> > New questions below\n> > \n> > ---\n> > Best regards\n> > S?awek Kap?o?ski\n> > slawek at kaplonski.pl\n> > \n> > Dnia czwartek, 18 wrze?nia 2014 09:45:21 Clint Byrum pisze:\n> >> Excerpts from S?awek Kap?o?ski\'s message of 2014-09-18 09:29:27 -0700:\n> >> > Hello,\n> >> > \n> >> > Is anyone here using openstack with mysql galera and haproxy? Have You\n> >> > got\n> >> > any problems with that?\n> >> > I was today installed such ha infra for database (two mysql servers in\n> >> > galera cluster and haproxy on controller and neutron node, this haproxy\n> >> > is connecting to one of galera servers with round robin algorithm).\n> >> > Generally all is working fine but I have few problems:\n> >> > 1. I have a lot of messages like:\n> >> > WARNING neutron.openstack.common.db.sqlalchemy.session [-] Got mysql\n> >> > server\n> >> > has gone away: (2006, \'MySQL server has gone away\')\n> >> > 2. I have (most on neutron) many errors like:\n> >> > OperationalError: (OperationalError) (2013, \'Lost connection to MySQL\n> >> > server during query\') \'UPDATE ml2_port_bindings SET vif_type=%s,\n> >> > driver=%s, segment=%s WHERE ml2_port_bindings.port_id =\n> >> \n> >> 1 and 2 look like timeout issues. Check haproxy\'s timeouts. They need\n> >> to be just a little longer than MySQL\'s connection timeouts.\n> > \n> > After I made ACTIVE/PASSIVE cluster and change sql_idle_timeout in neutron\n> > and nova problem 1 looks that is solver. Unfortunatelly I found that when\n> > I\'m deleting port from neutron I still sometimes have got errors like in\n> > 2. I don\'t check exactly nova logs yet so I\'m not sure is it only in\n> > neutron or in both.\n> > Do You maybe know why it happens in neutron? It not happend when I have\n> > single mysql node without haproxy and galera so I suppose that haproxy or\n> > galera is responsible for that problem :/\n> > \n> >> > 3. Also errors:\n> >> > StaleDataError: UPDATE statement on table \'ports\' expected to update 1\n> >> > row(s); 0 were matched.\n> >> > 4. and errors:\n> >> > DBDeadlock: (OperationalError) (1213, \'Deadlock found when trying to\n> >> > get\n> >> > lock; try restarting transaction\') \'UPDATE ipavailabilityranges SET\n> >> > first_ip=%s WHERE ipavailabilityranges.allocation_pool_id =\n> >> \n> >> 3 and 4 are a known issue. Our code doesn\'t always retry transactions,\n> >> which is required to use Galera ACTIVE/ACTIVE. Basically, that doesn\'t\n> >> work.\n> >> \n> >> You can use ACTIVE/PASSIVE, and even do vertical partitioning where\n> >> one of the servers is ACTIVE for Nova, but another one is ACTIVE for\n> >> Neutron. But AFAIK, ACTIVE/ACTIVE isn\'t being tested and the work hasn\'t\n> >> been done to make the concurrent transactions work properly.\n> >> \n> >> _______________________________________________\n> >> OpenStack-operators mailing list\n> >> OpenStack-operators at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> > \n> > _______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140922/5b3b4199/attachment.pgp>\n\n','<CAA11gNcxe3KY9g2dSNNEAA+Qq7a3tPKWVnxyoqd5hvmyBr5Vdg@mail.gmail.com>',NULL),('<1632505041.57.1386742877670.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-11 06:21:17',0,'2013-12-11 06:21:17',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-pg-havana #5','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-pg-havana/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827421 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-pg-havana/ws/>\n[periodic-tempest-dsvm-neutron-pg-havana] $ /bin/bash -xe /tmp/hudson4889531418163527511.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: Unable to find 9e06327193e2aa23b488c3c566f13acd3f03de87 under https://review.openstack.org/p/openstack-infra/devstack-gate\nCannot obtain needed object 9e06327193e2aa23b488c3c566f13acd3f03de87\nerror: Fetch failed.\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-827421\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-pg-havana/devstack-precise-hpcloud-az2-827421/5\n[SCP] Copying console log.\n\n\n','<1139906069.43.1386657213894.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1632751032.26.1369289377533.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-23 06:09:37',0,'2013-05-23 06:09:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #234','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/234/>\n\n------------------------------------------\n[...truncated 845 lines...]\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n139958731630408:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_verify_signed_token_succeeds_for_unrevoked_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 533, in test_verify_signed_token_succeeds_for_unrevoked_token\n    self.middleware.verify_signed_token(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140184437958472:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_fetch_revocation_list_with_expire (test_auth_token_middleware.StackResponseAuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 422, in test_fetch_revocation_list_with_expire\n    fetched_list = jsonutils.loads(self.middleware.fetch_revocation_list())\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 820, in fetch_revocation_list\n    return self.cms_verify(data[\'signed\'])\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140711405967176:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_default_tenant_signed_token (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 483, in test_default_tenant_signed_token\n    self.assert_unscoped_default_tenant_auto_scopes(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 476, in assert_unscoped_default_tenant_auto_scopes\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140254054586184:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_memcache_set_expired (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 629, in test_memcache_set_expired\n    self.assertEqual(len(self.middleware._cache.set_value), 2)\nAssertionError: 7 != 2\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.middleware.auth_token: DEBUG: Cached Token 9bba6849c9e1f77727ae7813fd151115 seems expired\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140134676924232:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: DEBUG: Marking token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg== as unauthorized in memcache\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_valid_signed_request (test_auth_token_middleware.AuthTokenMiddlewareTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 461, in test_valid_signed_request\n    self.assert_valid_request_200(SIGNED_TOKEN_SCOPED)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_auth_token_middleware.py\",> line 450, in assert_valid_request_200\n    self.assertEqual(self.response_status, 200)\nAssertionError: 401 != 200\n-------------------- >> begin captured logging << --------------------\nkeystone.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystone.middleware.auth_token: INFO: Using signing as cache directory for signing certificate\nkeystone.middleware.auth_token: WARNING: signing_dir mode is 0755 instead of 0700\nkeystone.middleware.auth_token: DEBUG: Authenticating user token\nkeystone.middleware.auth_token: DEBUG: Removing headers from request environment: X-Identity-Status,X-Tenant-Id,X-Tenant-Name,X-User-Id,X-User-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant,X-Role\nkeystone.common.cms: ERROR: Verify error: Verification failure\n140561536182088:error:2E099064:CMS routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify error:cms_smime.c:304:Verify error:certificate has expired\n\nkeystone.middleware.auth_token: DEBUG: Token validation failure.\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 511, in _validate_user_token\n    verified = self.verify_signed_token(user_token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 760, in verify_signed_token\n    return self.cms_verify(formatted)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/middleware/auth_token.py\",> line 743, in cms_verify\n    self.ca_file_name)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/keystone/common/cms.py\",> line 45, in cms_verify\n    raise subprocess.CalledProcessError(retcode, \"openssl\", output=err)\nTypeError: __init__() got an unexpected keyword argument \'output\'\nkeystone.middleware.auth_token: WARNING: Authorization failed for token MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCTAHBgUrDgMCGjCCBc4GCSqGSIb3DQEHAaCCBb8EggW7eyJhY2Nlc3MiOiB7InNlcnZpY2VDYXRhbG9nIjogW3siZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzYvdjEvNjRiNmYzZmJjYzUzNDM1ZThhNjBmY2Y4OWJiNjYxN2EifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAidm9sdW1lIiwgIm5hbWUiOiAidm9sdW1lIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInJlZ2lvbiI6ICJyZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo5MjkyL3YxIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIvdjEifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaW1hZ2UiLCAibmFtZSI6ICJnbGFuY2UifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSIsICJyZWdpb24iOiAicmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92MS4xLzY0YjZmM2ZiY2M1MzQzNWU4YTYwZmNmODliYjY2MTdhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjEuMS82NGI2ZjNmYmNjNTM0MzVlOGE2MGZjZjg5YmI2NjE3YSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo1MDAwL3YyLjAifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAiaWRlbnRpdHkiLCAibmFtZSI6ICJrZXlzdG9uZSJ9XSwidG9rZW4iOiB7ImV4cGlyZXMiOiAiMjAxMi0wNi0wMlQxNDo0NzozNFoiLCAiaWQiOiAicGxhY2Vob2xkZXIiLCAidGVuYW50IjogeyJlbmFibGVkIjogdHJ1ZSwgImRlc2NyaXB0aW9uIjogbnVsbCwgIm5hbWUiOiAidGVuYW50X25hbWUxIiwgImlkIjogInRlbmFudF9pZDEifX0sICJ1c2VyIjogeyJ1c2VybmFtZSI6ICJ1c2VyX25hbWUxIiwgInJvbGVzX2xpbmtzIjogWyJyb2xlMSIsInJvbGUyIl0sICJpZCI6ICJ1c2VyX2lkMSIsICJyb2xlcyI6IFt7Im5hbWUiOiAicm9sZTEifSwgeyJuYW1lIjogInJvbGUyIn1dLCAibmFtZSI6ICJ1c2VyX25hbWUxIn19fQ0KMYH3MIH0AgEBMFQwTzEVMBMGA1UEChMMUmVkIEhhdCwgSW5jMREwDwYDVQQHEwhXZXN0Zm9yZDEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czELMAkGA1UEBhMCVVMCAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAD6hPEpc-0wHe3rYDBFec52h7gxdbrTNEN7jmwdFtoxw0QnucmCREh9IUikJ2ob0c0uUC6cmNPajD9aFkGWhvNswNH2W2BYzUiC3CHM7U07nsIe3OOatqyUAyoQUhHZnIAx1tOgdPBVflnrtdIV1vkdqxednlJZ52Hxob2PP3hxg==\nkeystone.middleware.auth_token: INFO: Invalid user token - rejecting request\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 23.42 secs:\n    6.91    KcMasterTestCase.test_admin_requires_adminness\n    6.91    KcEssex3TestCase.test_admin_requires_adminness\n    6.87    Kc11TestCase.test_admin_requires_adminness\n    1.52    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.22    KcMasterSqlTestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 701 tests in 78.416s\n\nFAILED (SKIP=11, errors=4, failures=3)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeystone==2012.2.5\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=43\n+ \'[\' 43 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Grp5yZduk1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/234\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/234/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<712350057.21.1369202927469.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1632927986.68.1379408417520.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-17 09:00:17',0,'2013-09-17 09:00:17',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #18','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-stress/18/>\n\n------------------------------------------\n[...truncated 17919 lines...]\n2013-09-17 06:06:57 # If tenant networks are reachable, connectivity checks will be\n2013-09-17 06:06:57 # performed directly against addresses on those networks.\n2013-09-17 06:06:57 tenant_networks_reachable = false\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Id of the public network that provides external connectivity.\n2013-09-17 06:06:57 public_network_id = \n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Id of a shared public router that provides external connectivity.\n2013-09-17 06:06:57 # A shared public router would commonly be used where IP namespaces\n2013-09-17 06:06:57 # were disabled.  If namespaces are enabled, it would be preferable\n2013-09-17 06:06:57 # for each tenant to have their own router.\n2013-09-17 06:06:57 public_router_id = \n2013-09-17 06:06:57 \n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [volume]\n2013-09-17 06:06:57 volume_backup_enabled = True\n2013-09-17 06:06:57 # This section contains the configuration options used when executing tests\n2013-09-17 06:06:57 # against the OpenStack Block Storage API service\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-17 06:06:57 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-17 06:06:57 # probably want to leave this value as \"volume\"\n2013-09-17 06:06:57 catalog_type = volume\n2013-09-17 06:06:57 # The disk format to use when copying a volume to image\n2013-09-17 06:06:57 disk_format = raw\n2013-09-17 06:06:57 # Number of seconds to wait while looping to check the status of a\n2013-09-17 06:06:57 # volume that is being made available\n2013-09-17 06:06:57 build_interval = 1\n2013-09-17 06:06:57 # Number of seconds to time out on waiting for a volume\n2013-09-17 06:06:57 # to be available or reach an expected status\n2013-09-17 06:06:57 build_timeout = 400\n2013-09-17 06:06:57 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-17 06:06:57 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-17 06:06:57 # have to be different)\n2013-09-17 06:06:57 multi_backend_enabled = false\n2013-09-17 06:06:57 backend1_name = BACKEND_1\n2013-09-17 06:06:57 backend2_name = BACKEND_2\n2013-09-17 06:06:57 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-17 06:06:57 # You should update to reflect those exported by configured backend driver.\n2013-09-17 06:06:57 storage_protocol = iSCSI\n2013-09-17 06:06:57 vendor_name = Open Source\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [object-storage]\n2013-09-17 06:06:57 # This section contains configuration options used when executing tests\n2013-09-17 06:06:57 # against the OpenStack Object Storage API.\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # You can configure the credentials in the compute section\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-17 06:06:57 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-17 06:06:57 # this value as \"object-store\"\n2013-09-17 06:06:57 catalog_type = object-store\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Number of seconds to time on waiting for a container to container\n2013-09-17 06:06:57 # synchronization complete\n2013-09-17 06:06:57 container_sync_timeout = 120\n2013-09-17 06:06:57 # Number of seconds to wait while looping to check the status of a\n2013-09-17 06:06:57 # container to container synchronization\n2013-09-17 06:06:57 container_sync_interval = 5\n2013-09-17 06:06:57 # Set to True if the Account Quota middleware is enabled\n2013-09-17 06:06:57 accounts_quotas_available = True\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Set operator role for tests that require creating a container\n2013-09-17 06:06:57 operator_role = Member\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [boto]\n2013-09-17 06:06:57 ssh_user = cirros\n2013-09-17 06:06:57 # This section contains configuration options used when executing tests\n2013-09-17 06:06:57 # with boto.\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # EC2 URL\n2013-09-17 06:06:57 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-17 06:06:57 # S3 URL\n2013-09-17 06:06:57 s3_url = http://127.0.0.1:3333\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-17 06:06:57 aws_access =\n2013-09-17 06:06:57 aws_secret =\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Image materials for S3 upload\n2013-09-17 06:06:57 # ALL content of the specified directory will be uploaded to S3\n2013-09-17 06:06:57 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-17 06:06:57 # Subdirectories not allowed!\n2013-09-17 06:06:57 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-17 06:06:57 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-17 06:06:57 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-17 06:06:57 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Instance type\n2013-09-17 06:06:57 instance_type = m1.nano\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # TCP/IP connection timeout\n2013-09-17 06:06:57 http_socket_timeout = 30\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Number of retries actions on connection or 5xx error\n2013-09-17 06:06:57 num_retries = 1\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Status change wait timout\n2013-09-17 06:06:57 build_timeout = 400\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Status change wait interval\n2013-09-17 06:06:57 build_interval = 1\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [orchestration]\n2013-09-17 06:06:57 # Status change wait interval\n2013-09-17 06:06:57 build_interval = 1\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Status change wait timout. This may vary across environments as some some\n2013-09-17 06:06:57 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-17 06:06:57 build_timeout = 300\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Instance type for tests. Needs to be big enough for a\n2013-09-17 06:06:57 # full OS plus the test workload\n2013-09-17 06:06:57 instance_type = m1.micro\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-17 06:06:57 # If not specified, tests that spawn instances will not run\n2013-09-17 06:06:57 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-17 06:06:57 # any key, which will generate a keypair for each test class\n2013-09-17 06:06:57 #keypair_name = heat_key\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [dashboard]\n2013-09-17 06:06:57 # URL where to find the dashboard home page\n2013-09-17 06:06:57 dashboard_url = http://127.0.0.1/\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # URL where to submit the login form\n2013-09-17 06:06:57 login_url = http://127.0.0.1/auth/login/\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [scenario]\n2013-09-17 06:06:57 # Directory containing image files\n2013-09-17 06:06:57 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # AMI image file name\n2013-09-17 06:06:57 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # ARI image file name\n2013-09-17 06:06:57 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # AKI image file name\n2013-09-17 06:06:57 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # ssh username for the image file\n2013-09-17 06:06:57 ssh_user = cirros\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 # specifies how many resources to request at once. Used for large operations\n2013-09-17 06:06:57 # testing.\"\n2013-09-17 06:06:57 large_ops_number = 0\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [cli]\n2013-09-17 06:06:57 # Enable cli tests\n2013-09-17 06:06:57 enabled = True\n2013-09-17 06:06:57 # directory where python client binaries are located\n2013-09-17 06:06:57 cli_dir = /usr/local/bin\n2013-09-17 06:06:57 # Number of seconds to wait on a CLI timeout\n2013-09-17 06:06:57 timeout = 15\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [service_available]\n2013-09-17 06:06:57 # Whether or not cinder is expected to be available\n2013-09-17 06:06:57 cinder = True\n2013-09-17 06:06:57 # Whether or not neutron is expected to be available\n2013-09-17 06:06:57 neutron = False\n2013-09-17 06:06:57 # Whether or not glance is expected to be available\n2013-09-17 06:06:57 glance = True\n2013-09-17 06:06:57 # Whether or not swift is expected to be available\n2013-09-17 06:06:57 swift = True\n2013-09-17 06:06:57 # Whether or not nova is expected to be available\n2013-09-17 06:06:57 nova = True\n2013-09-17 06:06:57 # Whether or not Heat is expected to be available\n2013-09-17 06:06:57 heat = True\n2013-09-17 06:06:57 # Whether or not horizon is expected to be available\n2013-09-17 06:06:57 horizon = True\n2013-09-17 06:06:57 \n2013-09-17 06:06:57 [stress]\n2013-09-17 06:06:57 # Maximum number of instances to create during test\n2013-09-17 06:06:57 max_instances = 32\n2013-09-17 06:06:57 # Time (in seconds) between log file error checks\n2013-09-17 06:06:57 log_check_interval = 60\n2013-09-17 06:06:57 # The default number of threads created while stress test\n2013-09-17 06:06:57 default_thread_number_per_action=4\n2013-09-17 06:06:57 ++ IFS=\' 	\n2013-09-17 06:06:57 \'\n2013-09-17 06:06:57 ++ set +o errexit\n2013-09-17 06:06:57 ++ init_tempest\n2013-09-17 06:06:57 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-17 06:06:57 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-17 06:06:57 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-17 06:06:57 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-17 06:06:57 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\n2013-09-17 06:06:57 ++ \'[\' -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd -a -f /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img -a libvirt \'!=\' openvz -a \'(\' qemu \'!=\' lxc -o libvirt \'!=\' libvirt \')\' \']\'\n2013-09-17 06:06:57 ++ echo \'Prepare aki/ari/ami Images\'\n2013-09-17 06:06:57 Prepare aki/ari/ami Images\n2013-09-17 06:06:57 ++ cat\n2013-09-17 06:06:57 ++ source /opt/stack/new/devstack/accrc/demo/demo\n2013-09-17 06:06:57 +++ export EC2_ACCESS_KEY=789e94051db14710a75fd21cc0780f06\n2013-09-17 06:06:57 +++ EC2_ACCESS_KEY=789e94051db14710a75fd21cc0780f06\n2013-09-17 06:06:57 +++ export EC2_SECRET_KEY=f8361de38f754938b21cdd72cd2ec792\n2013-09-17 06:06:57 +++ EC2_SECRET_KEY=f8361de38f754938b21cdd72cd2ec792\n2013-09-17 06:06:57 +++ export EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-09-17 06:06:57 +++ EC2_URL=http://127.0.0.1:8773/services/Cloud\n2013-09-17 06:06:57 +++ export S3_URL=http://127.0.0.1:3333\n2013-09-17 06:06:57 +++ S3_URL=http://127.0.0.1:3333\n2013-09-17 06:06:57 +++ export OS_USERNAME=demo\n2013-09-17 06:06:57 +++ OS_USERNAME=demo\n2013-09-17 06:06:57 +++ export OS_TENANT_NAME=demo\n2013-09-17 06:06:57 +++ OS_TENANT_NAME=demo\n2013-09-17 06:06:57 +++ export OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-09-17 06:06:57 +++ OS_AUTH_URL=http://127.0.0.1:35357/v2.0\n2013-09-17 06:06:57 +++ export EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-09-17 06:06:57 +++ EC2_CERT=/opt/stack/new/devstack/accrc/demo/demo-cert.pem\n2013-09-17 06:06:57 +++ export EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-09-17 06:06:57 +++ EC2_PRIVATE_KEY=/opt/stack/new/devstack/accrc/demo/demo-pk.pem\n2013-09-17 06:06:57 +++ export EC2_USER_ID=42\n2013-09-17 06:06:57 +++ EC2_USER_ID=42\n2013-09-17 06:06:57 +++ export EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-17 06:06:57 +++ EUCALYPTUS_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-17 06:06:57 +++ export NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-17 06:06:57 +++ NOVA_CERT=/opt/stack/new/devstack/accrc/cacert.pem\n2013-09-17 06:06:57 +++ export OS_PASSWORD=secret\n2013-09-17 06:06:57 +++ OS_PASSWORD=secret\n2013-09-17 06:06:57 ++ euca-bundle-image -i /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz --kernel true -d /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-17 06:06:57 Checking image\n2013-09-17 06:06:57 Encrypting image\n2013-09-17 06:06:57 Splitting image...\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1768.g66fcba9.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-304590\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-304590/18\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-304590/18/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-304590/18/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-304590/18/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<659082054.64.1379322019239.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<163300660.10036184.1375367478323.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-01 10:31:18',-14400,'2013-08-01 14:31:18',NULL,'[Openstack-docs] Welcome Stephen Gordon to docs-core','----- Original Message -----\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Wednesday, July 31, 2013 2:10:17 PM\n> Subject: [Openstack-docs] Welcome Stephen Gordon to docs-core\n> \n> Hi all,\n> Stephen Gordon has been doing a great job with reviews and I\'ve invited him\n> to join docs-core. Thanks for bringing more RedHat to docs!\n> Anne\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\nThanks all for the warm welcome!\n\n-Steve\n\n\n','<CAD0KtVFUmJA3tNhAEw4OMWAwDyt6Jdq1OBNW==NKp+9v7UfZPA@mail.gmail.com>',NULL),('<1633693689.16.1387000969182.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-14 06:02:49',0,'2013-12-14 06:02:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-keystone-docs-havana #9','See <https://jenkins02.openstack.org/job/periodic-keystone-docs-havana/9/changes>\n\n\n\n','<1852937567.1.1386915172225.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<163401cdc283$a8e3ad10$faab0730$@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 20:18:18',14400,'2012-11-14 16:18:18',NULL,'[openstack-dev] [quantum] Quantum extension framework issue','Hi Dan,\n\nThanks for your comment here. \n\nJust wanted to correct a mistake in my first email: of course there can\'t be\na dict with duplicate keys. The idea was to use list of pairs, like:\n\nmember_actions = [{\"health_monitors\": \"GET\"}, \n\n                                         {\"health_monitors\": \"POST\"}]\n\nto have an ability of using same function name with different request\nactions. Initially I thought that the framework provides such ability but\ndoes not dispatch requests correctly. I was wrong.\n\nActually there is no issue with the framework as it assumes using unique\naction names for different request methods. \n\n \n\nI believe we should update LBaaS REST API doc and use \"get_health_monitors\",\n\"add_health_monitors\", etc. to fit in the framework.\n\n \n\nThanks,\n\nOleg\n\n \n\nFrom: Dan Wendlandt [mailto:dan at nicira.com] \nSent: Wednesday, November 14, 2012 7:27 PM\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] [quantum] Quantum extension framework issue\n\n \n\nHi Oleg,\n\n \n\nFolks from the API-subteam can correct me, but I believe this use model is\noutside of what the API framework was trying to enable with \"actions\".  The\nidea is that you use POST/DELETE to create an delete API \"resources\" (which\nactually have UUIDs, for example, the \"pool\" in your example below) and then\ndo a PUT to an \"action\" to cause some kind of change that you can affect on\na resource (e.g., \"add_health_monitor\" or \"remove_health_monitor\").  It\nsounds like what you are proposing is more treating \"health_monitors\" almost\nas a \"sub-resource\", which is not really what the \"actions\" stuff was\ndesigned for.  \n\n \n\nI haven\'t been deeply involved in the LBaaS api design discussion though, so\nI\'d also like to hear from Salvatore, et al. on the API sub-team.\n\n \n\nDan\n\n \n\n \n\nOn Wed, Nov 14, 2012 at 6:05 AM, Oleg Bondarev <obondarev at mirantis.com>\nwrote:\n\nHi guys,\n\n \n\nWhile working on the API extension for LBaaS I didn\'t find a way to use\ncustom member actions if they have the same name and differ only by request\nmethod, for example\n\n \n\nList all health monitors of a specific pool: GET\n/pool/pool_id/health_monitors\n\nAssociate health monitors with a pool: POST /pool/pool_id/health_monitors\n\n \n\nIn quantum extension framework we pass \"health_monitors\" as member actions\nfor a controller (quantum.api.v2.base.create_resource())\n\n \n\nmember_actions = {\'health_monitors\': \'GET\',\n\n                                        \'health_monitors\': \'POST\'}\n\n \n\ncontroller = base.create_resource(collection_name,\n\n                                    resource_name,\n\n                                    plugin, params,\n\n                                    member_actions=member_actions)\n\n \n\nAccording to the Controller implementation it dispatches all custom member\nactions to its plugin attr:\n\n \n\ndef __getattr__(self, name):\n\n        if name in self._member_actions:\n\n            def _handle_action(request, id, body=None):\n\n                return getattr(self._plugin, name)(request.context, id,\nbody)\n\n            return _handle_action\n\n        else:\n\n            raise AttributeError\n\n \n\nWhere request.context is of type quantum.context.Context and does not\ncontain info about request method.\n\nAs a result there is no way to distinguish two custom actions in the plugin.\n\n\nIs it an issue in the framework?\n\n \n\nPossible solution may be in concatenation of request method and action name\n(\"get_health_monitors\", \"post_health_monitors\") in a controller before\ndispatching them to a plugin.\n\nWhat do you think? \n\n \n\nThanks,\n\nOleg\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n\n \n\n-- \n~~~~~~~~~~~~~~~~~~~~~~~~~~~\nDan Wendlandt \n\nNicira, Inc: www.nicira.com\n\ntwitter: danwendlandt\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\n \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/30afbbf3/attachment.html>\n\n','<CA+0XJm_NGUGwjUi4ZHLZ0WFzgrgBiYZMPNr-8y5xTwtrL=9Hvg@mail.gmail.com>',NULL),('<1634898558.95.1356049870115.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-21 00:31:09',0,'2012-12-21 00:31:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #81','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/81/>\n\n------------------------------------------\n[...truncated 12375 lines...]\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... ok\nCREATE, GET, DELETE Volume ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nVolume is attached and detached successfully from an instance ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ok\nGet a list of Volumes ... ok\nGet a list of Volumes with details ... ok\nERROR\nERROR\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 227, in run\n    self.tearDown()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 350, in tearDown\n    self.teardownContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 366, in teardownContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 150, in tearDownClass\n    cls.client.wait_for_resource_deletion(volume)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 260, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 79, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/new/tempest/tempest/services/volume/json/volumes_client.py\", line 126, in wait_for_volume_status\n    raise exceptions.VolumeBuildErrorException(volume_id=volume_id)\nVolumeBuildErrorException: Volume 804ab97c-2087-47a8-af8b-d2f93cedbe64 failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 44 tests in 726.839s\n\nFAILED (SKIP=8, errors=2)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/rabbitmq/rabbit at devstack-1356045655-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/rabbitmq/rabbit at devstack-1356045655.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/81/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1635204.vPSZkMFmxb@bort.suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-04 16:28:15',3600,'2013-11-04 15:28:15',NULL,'[openstack-dev] [horizon] BootstrapV3 and lessc','On Monday 04 November 2013 13:49:20 Matthias Runge wrote:\n> On 11/04/2013 11:41 AM, Sascha Peilicke wrote:\n> > On Monday 04 November 2013 10:52:21 Maxime Vidori wrote:\n> >> Hi,\n> >> \n> >> I talked with Jiri Tomasek who is currently in charge of the integration\n> >> of\n> >> Bootstrap V3 into Horizon. The integration is currently stuck and was\n> >> waiting for almost two month that lesscpy could parse the Bootstrap v3\n> >> less\n> >> template. I know that Nodejs was removed because of some dependencies\n> >> issues in production environment, but we do not need Node in production\n> >> environment.\n> \n> We didn\'t had nodejs for a long time in fedora, because it used to\n> bundle a lot of code from other projects.\n> The other issue is, that is a quite fast moving project. When you want a\n> stable platform, you probably don\'t want to update every two to four\n> weeks to a newer minor-version, and probably want to avoid new major\n> versions at all.\n> \n> So, it ended up in: we compiled LESS code offline and combined that with\n> the package. That is not ideal at all for folks changing the style to\n> give their dashboard another look. I assume, that\'s a pretty common\n> situation.\n\nJust to give people an impression, this is a RPM spec file stripped of \neverything except the nodejs / offline compression parts: \nhttp://paste.opensuse.org/view/raw/8915603 (as seen in [0])\n\nOf course you can bet that your usual consultancy-based PoC deployment won\'t \ncare about such details o:-)\n\n> > Regardless of that, nodejs is a huge dependency of which not that many\n> > people have long experience with. While I know that nodejs is the new\n> > fancy of web development, things where radically different less than 2\n> > years ago. It will the same in 2 years from now. That\'s why distros want\n> > to avoid it if they can. You simply don\'t know how reliable upstream is.\n> > What happens if they need to fix a security issue in that crappy old\n> > release that happens to be shipped in, say, openSUSE-12.2.\n> \n> Exactly, just compare the binary size with the size of less sourcecode\n> in horizon sourcecode at all.\n> \n> So, that being said, dropping lesscss in favor of re-integrating node.js\n> is a big step backwards. If there\'s something missing in lesscpy, we\n> should fix that.\n> \n> Matthias\n\n[0] \nhttps://build.opensuse.org/package/view_file/Cloud:OpenStack:Grizzly/openstack-dashboard/openstack-dashboard.spec?expand=1\n-- \nWith kind regards,\nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131104/0372c1f6/attachment.pgp>\n\n','<527797D0.4070200@redhat.com>',NULL);
INSERT INTO `messages` VALUES ('<1635388516.410.1367043027156.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:10:27',0,'2013-04-27 06:10:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/17/changes>\n\nChanges:\n\n[Vishvananda Ishaya] Fallback to conductor if types are not stashed.\n\n[Vishvananda Ishaya] Update latest oslo.setup.\n\n[Vishvananda Ishaya] Fixes argument order of quantumv2.api.get_instance_nw_info\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal11 in workspace <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/>\nCheckout:periodic-nova-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 1dc0dbe0:quantal11\nUsing strategy: Default\nLast Built Revision: Revision 93a713bc07c0f53915c1dd8631dec42c3c6bee02 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 8f66e1afdb632a63c31839b5db49873174e67713 (origin/stable/grizzly)\nChecking out Revision 8f66e1afdb632a63c31839b5db49873174e67713 (origin/stable/grizzly)\n[periodic-nova-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson5228936263520599930.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack nova\n+ version=27\n+ org=openstack\n+ project=nova\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.dnINGGDO7b\n+ TMPDIR=/tmp/tmp.dnINGGDO7b\n+ trap \'rm -rf /tmp/tmp.dnINGGDO7b\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python27.stable.grizzly.17\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-nova-python27-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 42178 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-nova-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal11\', \'TMPDIR\': \'/tmp/tmp.dnINGGDO7b\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-05-37\', \'BUILD_NUMBER\': \'17\', \'HUDSON_COOKIE\': \'7db752ce-a11a-47ba-9f74-9a21bf6350ef\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'8f66e1afdb632a63c31839b5db49873174e67713\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'_\': \'/usr/local/bin/tox\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal11\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 42178 166.78.63.46 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking SQLAlchemy>=0.7.8,<0.7.99 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires> (line 1))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement SQLAlchemy>=0.7.8,<0.7.99 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires> (line 1))\nNo distributions at all found for SQLAlchemy>=0.7.8,<0.7.99 (from -r <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires> (line 1))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.dnINGGDO7b\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1636005291.408.1359417712115.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-29 00:01:51',0,'2013-01-29 00:01:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-folsom #120','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/120/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise15 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/>\nCheckout:periodic-swift-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/> - hudson.remoting.Channel at 220df4c8:precise15\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson4860431490083534023.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.2i2TyclvHH\n+ TMPDIR=/tmp/tmp.2i2TyclvHH\n+ trap \'rm -rf /tmp/tmp.2i2TyclvHH\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/120/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python27-stable-folsom-120\', \'SSH_CLIENT\': \'198.101.231.203 35491 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1357687285.661868-1681004066\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise15\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.2i2TyclvHH\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-29_00-01-21\', \'BUILD_NUMBER\': \'120\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'ffa06e0a-70bf-41db-b452-f1411403f426\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise15\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 35491 50.57.88.228 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.2i2TyclvHH\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-folsom/120\n[SCP] Copying console log.\n\n\n','<1692521103.392.1359331311932.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1636323055.542.1367389367230.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-01 06:22:47',0,'2013-05-01 06:22:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-grizzly-centos6 #1','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/1/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-3 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/>\nCheckout:periodic-nova-python26-stable-grizzly-centos6 / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/> - hudson.remoting.Channel at 7b18f61:centos6-3\nUsing strategy: Default\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision c18519501af57e91deb35792c53e542116ccba64 (origin/stable/grizzly)\nChecking out Revision c18519501af57e91deb35792c53e542116ccba64 (origin/stable/grizzly)\nNo change to record in branch origin/stable/grizzly\n[periodic-nova-python26-stable-grizzly-centos6] $ /bin/bash -xe /tmp/hudson4263540477832648432.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.pFYyAowYbr\n+ TMPDIR=/tmp/tmp.pFYyAowYbr\n+ trap \'rm -rf /tmp/tmp.pFYyAowYbr\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\ngrep: /var/log/auth.log: No such file or directory\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.centos6.1\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.centos6.1.zip>\npy26 runtests: commands[0]\npy26 runtests: commands[1]\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.pFYyAowYbr/tmp3CL81d\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.pFYyAowYbr/tmpTznPfJ\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.pFYyAowYbr/tmpAcSqr_\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.pFYyAowYbr/tmpy1gZD8\n======================================================================\nFAIL: nova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/nova/tests/test_db_api.py\",> line 2597, in test_archive_deleted_rows_fk_constraint\n    self.assertEqual(num, 1)\nMismatchError: 0 != 1\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 5539 tests in 421.129s\nFAILED (id=0, failures=2, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.0\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.centos6.1\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npyflakes==0.7.2\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-quantumclient==2.2.1\npython-subunit==0.0.11\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\ntestrepository==0.0.15\ntesttools==0.9.31\nunittest2==0.5.1\nwarlock==1.0.0\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint (subunit.RemotedTestCase)\nprocess-returncode (subunit.RemotedTestCase)\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n++ .tox/py26/bin/python .tox/py26/bin/testr list-tests\n++ sed -e 1d\n++ wc -l\n/usr/bin/python: No module named subunit\n+ foundcount=0\n++ .tox/py26/bin/python .tox/py26/bin/testr last\n++ sed -ne \'s/Ran \\([0-9]\\+\\).*tests in.*/\\1/p\'\n+ rancount=5539\n+ \'[\' 5539 -lt 0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.pFYyAowYbr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly-centos6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly-centos6/1\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1637279503.57.1386484828991.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-08 06:40:28',0,'2013-12-08 06:40:28',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-dsvm-full-havana #3','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-full-havana/3/>\n\n\n\n','<631844355.53.1386225814603.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1637833638.10150942.1405178166467.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-12 11:16:06',-14400,'2014-07-12 15:16:06',NULL,'[openstack-dev] [all] Treating notifications as a contract','\n\n> > A notification of compute.instance.create.start is naturally going to\n> > carry different types of data than a volume.snapshot.delete.end for\n> > example, but of course we\'d seek to accommodate that difference within\n> > a generic structure as far as possible.\n> \n> Is it going to carry different types of data or different values on\n> identical keys. The goal would be that the \"meaning\" of a notification\n> for compute.instance.create.start and volume.snapshot.delete.end\n> should be found on the same set of keys. That\'s all \"the proposal\" is.\n\nOK, got it. :)\n\nSo what we need to figure out is how exactly this common structure can be\naccommodated without reverting back to what Sandy called the \"wild west\"\nin another post.\n\n(i.e. the current scenario of a small set of common fields such as priority\nor timestamp, followed by a free-form payload dict that differs from one\nevent type to another, or may even change from the old form of one event\ntype to the new form of the same notification)\n\n> >> It may be, they have the same basic idea: \"stuff that\n> >> happens\" can be represented by a sequence of relatively stupid event-\n> >> like things.\n> >\n> > OK, I might be missing something here, but we seem to have a close\n> > approximation of that already:\n> >\n> >  stuff happens ==> events pop out on the bus\n> >\n> > So is your point that our events aren\'t dumb enough?\n> \n> Events are too different in from, from event to event.\n> \n> > (e.g. encode too much structure, or carry too much data, or require\n> > too much interpretation?)\n> \n> Of these three, \"require too much interpretation\" is perhaps the best\n> match.\n\nOK, I think I can agree with the spirit of that.\n \n> > But overall, it doesn\'t look like too radical a change in format.\n> \n> No, it\'s not. What it is is a minor change that \"everyone\" could adopt\n> and thus be able to play in the party.\n\nAgreed, so I think we just need to tie down the benefits of such a non-\nradical change, and compare those to the potential costs and benefits of\nmore locked-down schemata (i.e. more specific to individual event types).\n\n> > The metric-oriented view is subset/specialized aspect of something\n> > more generic.\n> \n> Okay, so we agree on that. Can we agree that it might be possible to\n> represent that generic thing with a common grammar?\n\nYes, I think we can :)\n \n> >> No, you are seeing the evolution of my thinking: as I write about this\n> >> stuff and try to understand it, it becomes more clear (to me) that\n> >> samples ought to be treated as event-like thingies.\n> >\n> > OK, so that shift makes it a little difficult to follow and engage with.\n> \n> This is a mailing list for a distributed project, it is the sole place\n> where we can get some reasonable simulation of \"having a chat\" with a\n> wide body of interested parties. The point of having a chat is to\n> explore, think, and exchange and hone ideas. I certainly hope you\n> don\'t expect me and everyone else only to write to the list when we\n> have a fully researched proposal. This (apart from summits and\n> mid-cycles) is the most accessible place we have to which we can go to\n> create the information that allows us to do the compare and contrast\n> the eventually leads to creating proposals.\n\nFully agreed that the ML is exactly the place for discussing and honing\nideas, outside of the design summit and mid-cycle meetups. And I agree\nthat there is no requirement for these ideas to be fully formed before\nbringing them to the list. \n\n> > OK, so perhaps I misread your earlier comments on samples and assumed\n> > a predisposition to ceilometer\'s requirements was being proposed?\n> \n> It seems that way. Throughout I\'ve been saying notifications should be\n> easy for anyone to create and anyone to consume and have confidence\n> they are doing it right.\n\nYep ... after discussing this on IRC, it seems that the confusion arose\nfrom me reading too much into your prior statement of:\n\n  \"to me ceilometer is a service for gathering metrics and then being able\n   to do things with those metrics. anything with the proper creds ought to\n   be able to send out a notification which is to be treated as a metric\n   and ceilometer should consume it\"\n\ni.e. assuming this to indicate a stronger equivalence between notifications\nand metrics/samples than you had intended.\n \n> > Can you start fleshing out exactly what you mean by a standard not\n> > necessarily predisposed to ceilometer, still sufficiently close to\n> > eliminate the need for a mapping layer on the ceilometer side?\n> \n> That\'s what I\'m trying to do here in this discussion here on this list\n> because as far as I\'m able to tell that\'s the one way to ensure that\n> the idea has some validity and I\'m not missing important details. I\n> thought I was saying \"how about this general idea, any merit? Help me\n> flesh it out?\" but apparently it came across as something different.\n\nApologies, I should have wrote: can you *continue* fleshing out ...\n\nPoor choice of words on my part.\n\n> That\'s a shame. If I were made of less stern stuff I might be put off\n> trying to share ideas and make improvements: the hoops I\'m leaping through\n> are making me a feel bit \"whoa, man, really I don\'t want to have to try\n> this hard just to discuss an idea\".\n\nDiscussion of ideas is definitely encouraged, and I would hate to think\nthat any other impression was given on this thread. So please do continue\ndeveloping your ideas here.\n\n> > And then please run this by the other stake-holders (e.g. StackTach)\n> > for a sanity check to confirm that it would complicate their lives\n> > unnecessarily.\n> \n> I would have thought that was what I was already doing by posting in\n> this thread based on the title and the participants thus far, but\n> I\'m assuming you mean something else?\n\nWell, I just meant to continue in this vein and then follow up with\nan explicit checkpoint with all the stake-holders.\n\nFor example you could write up a brief wiki walking through how an\nexisting widely-consumed notification might look under your vision,\nsay compute.instance.start.end. Then post a link back here as an RFC.\n\nOr, possibly better, maybe submit up a strawman spec proposal to one\nof the relevant *-specs repos and invite folks to review in the usual\nway?\n\nAnyway, whatever works for you ...\n\n> > If you can figure out how to do that in a concrete way ... then great,\n> > I\'d be receptive, let\'s hear some proposals.\n> \n> I\'ve made a very limited one, how\'s it sound? Does it need an\n> implementation in order to warrant further discussion? Or would it\n> be better to toss it around a bit more? It makes no sense to me to\n> formalize something that has no potential legs.\n\nSo it sounds like we\'re converging towards a common understanding,\nand while I don\'t think there\'s a need for an implementation to warrant\nfurther discussion, a more detailed and concrete (but not necessarily\ncomplete) write-up in say one of the formats suggested above would be\ngreat to keep up the momentum of the discussion.\n\nThis feels like something that we should be thinking about with an eye\nto the K* cycle - would you agree?\n\nCheers,\nEoghan\n\n\n','<alpine.OSX.2.00.1407111318080.86533@crank.local>',NULL),('<1637892848.39.1378533728834.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-07 06:02:08',0,'2013-09-07 06:02:08',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #14','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/14/>\n\n------------------------------------------\n[...truncated 635 lines...]\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 10.800s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.14\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-memcached==1.53\npython-novaclient==2.14.1\npython-quantumclient==2.2.3\npython-swiftclient==1.6.0\npytz==2013d\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.jS9pVqK7Ut\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise39\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise39/14\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<163806761.5371315.1390418517691.JavaMail.zimbra@mozilla.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-22 11:21:57',-28800,'2014-01-22 19:21:57',NULL,'[Openstack] Practicality of an unusual bare-metal use-case','Great, thanks!  It\'s good to know I\'m not on a blind alley.\n\n----- Original Message -----\n> Windows is not yet a feature for nova-baremetal or Ironic, but we\'d\n> love it to be :)\n> Ditto OS X.\n\n..\n\n> Yes, one OpenStack region can handle multiple baremetal flavours,\n> which seems to be the only variation you have between the machines -\n> client OS is always a separate layer in OpenStack :)\n\nThese don\'t really square up in my mind -- as far as Nova\'s concerned, the client OS is just a pile of 1\'s and 0\'s, right?\n\nDustin\n\n\n','<CAJ3HoZ2cn=TFqyYVBm0gsGnFxr17vnKGstOBqGqoSxVkOmTvWA@mail.gmail.com>',NULL),('<1638099496.11.1371795719547.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-21 06:21:59',0,'2013-06-21 06:21:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #72','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/72/>\n\n------------------------------------------\n[...truncated 1164 lines...]\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.01\n    test_add_ignores_acls_if_no_locations                        OK    0.01\n    test_add_updates_acls                                        OK    0.01\n    test_member_addition_updates_acls                            OK    0.01\n    test_member_removal_updates_acls                             OK    0.01\n    test_save_fetches_members_if_private                         OK    0.01\n    test_save_updates_acls                                       OK    0.01\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.02\n    test_filesystem_store_location                               OK    0.03\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.03\n    test_http_store_location                                     OK    0.03\n    test_rbd_store_location                                      OK    0.03\n    test_s3_store_location                                       OK    0.03\n    test_swift_store_location                                    OK    0.03\nTestChunkReader\n    test_read_all_data                                           OK    0.02\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.03\n    test_multi_tenant_location_custom_service_type               OK    0.02\n    test_multi_tenant_location_http                              OK    0.02\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.02\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.02\n    test_add_auth_url_variations                                 OK    0.03\n    test_add_large_object                                        OK    0.02\n    test_add_large_object_zero_size                              OK    0.02\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.test_bin_glance_cache_manage.TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/functional/test_bin_glance_cache_manage.py\",> line 164, in test_queue\n    exitcode, out, err = execute(cmd)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/utils.py\",> line 198, in execute\n    raise RuntimeError(msg)\nRuntimeError: Command bin/glance-cache-manage --port=52112 list-cached did not succeed. Returned an exit code of 1.\n\nSTDOUT: Failed to show cached images. Got error:\n[Errno 111] Connection refused\n\n\nSTDERR:\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 114.09 secs:\n    31.51    TestScrubber.test_scrubber_app\n    24.46    TestScrubber.test_delayed_delete\n    23.69    TestRootApi.test_version_configurations\n    17.33    TestGlanceControl.test_reload\n    17.10    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 937.459s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.6\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python27.stable.grizzly.72\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.17\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.5\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.HTVIZqn5mr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/72\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/72/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<163855375.3356740.1353172847484.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-17 12:20:47',-18000,'2012-11-17 17:20:47',NULL,'[openstack-dev] [ceilometer] The periodic task on openstack','\n\n> > > But I\'m not sure that we can always address (b) or (c) even with\n> > > a special thread for high-priority/time-sensitive tasks.\n> > \n> > We can\'t do anything about (b), except starting the task again\n> > while the\n> > previous one is not finished. Is that desirable?\n> > - Yes if your task is taking much time because of blocked I/O (i.e.\n> > long\n> >   round-trip);\n> > - No if your task is taking much time because of system load.\n> \n> For nova\'s periodic task implementation, it\'s a bit different to. In\n> nova, all periodic_task are organized as a list and are executed in\n> one timer (nova/service.py) through one Looping call\n> So in nova, (b) is \"summary (all periodic task execute time) <\n> periodic_interval\", and which will be easier to fulfill, after all,\n>  if this happen, it means the periodic_interval should be adjusted .\n\nBy \"the periodic_interval should be adjusted\", you mean that the\nentire set of periodic tasks should be put on a slower cadence?\n\nThis may not be acceptable, if certain tasks really need to run\nat a certain frequency (e.g. reporting something every minute).\n\nNow of course we can only adjust the sleep interval to take account of\nthe tasks run duration if the difference between the former and the\nlatter is positive. If it turns out negative, then the next task runs\nare inevitably going to be skewed from the wall-clock boundary.\n\nBut we could make this a bit less likely by running the periodic tasks\nin parallel instead of serially, in which case it would require a\nsingle tasks\'s duration to exceed the periodic interval before we\'d\nhave an issue (and then only this individual task would execute late\non the next iteration, assuming we\'d never want individual task runs\nto overlap).\n\nCheers,\nEoghan\n\n\n','<DDCAE26804250545B9934A2056554AA034C414@SHSMSX101.ccr.corp.intel.com>',NULL),('<1638695347.179.1366094788398.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-16 06:46:28',0,'2013-04-16 06:46:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #6','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/6/>\n\n------------------------------------------\n[...truncated 4459 lines...]\nTestSecurityGroups\n    test_create_default_security_group_fail                      OK    0.16\n    test_create_delete_security_group_port_in_use                OK    0.47\n    test_create_port_with_bad_security_group                     OK    0.26\n    test_create_port_with_non_uuid                               OK    0.26\n    test_create_security_group                                   OK    0.21\n    test_create_security_group_rule_bad_remote_group_id          OK    0.27\n    test_create_security_group_rule_bad_security_group_id        OK    0.20\n    test_create_security_group_rule_bad_tenant                   OK    0.30\n    test_create_security_group_rule_bad_tenant_remote_group_id   OK    0.29\n    test_create_security_group_rule_bad_tenant_security_group_ruleOK    0.28\n    test_create_security_group_rule_bulk_emulated                OK    0.23\n    test_create_security_group_rule_bulk_native                  SKIP\n    test_create_security_group_rule_case_insensitive             OK    0.21\n    test_create_security_group_rule_differnt_security_group_ids  SKIP\n    test_create_security_group_rule_duplicate_rule_db            SKIP\n    test_create_security_group_rule_duplicate_rule_db_emulated   OK    0.25\n    test_create_security_group_rule_duplicate_rule_in_post       SKIP\n    test_create_security_group_rule_duplicate_rule_in_post_emulatedOK    2.60\n    test_create_security_group_rule_duplicate_rules              OK    0.47\n    test_create_security_group_rule_ethertype_invalid_as_number  OK    0.27\n    test_create_security_group_rule_group_id                     OK    0.28\n    test_create_security_group_rule_min_port_greater_max         OK    0.31\n    test_create_security_group_rule_ports_but_no_protocol        OK    0.27\n    test_create_security_group_rule_protocol_invalid_as_number   OK    0.23\n    test_create_security_group_rule_remote_ip_prefix             OK    0.33\n    test_create_security_group_rule_with_invalid_ethertype       OK    0.21\n    test_create_security_group_rule_with_invalid_protocol        OK    0.17\n    test_create_security_group_source_group_ip_and_ip_prefix     OK    0.16\n    test_default_security_group                                  OK    0.22\n    test_default_security_group_rules                            OK    0.29\n    test_delete_default_security_group_fail                      OK    0.33\n    test_delete_security_group                                   OK    0.28\n    test_get_security_group                                      OK    0.24\n    test_list_ports_security_group                               OK    0.33\n    test_list_security_group_rules                               OK    0.31\n    test_list_security_group_rules_with_pagination               OK    2.93\n    test_list_security_group_rules_with_pagination_reverse       OK    0.33\n    test_list_security_group_rules_with_sort                     OK    0.46\n    test_list_security_groups                                    OK    0.36\n    test_list_security_groups_with_pagination                    OK    0.27\n    test_list_security_groups_with_pagination_reverse            OK    0.28\n    test_list_security_groups_with_sort                          OK    0.27\n    test_update_port_remove_security_group_empty_list            OK    0.38\n    test_update_port_remove_security_group_none                  OK    0.41\n    test_update_port_with_multiple_security_groups               OK    0.39\n    test_update_port_with_security_group                         OK    0.46\nTestSecurityGroupsXML\n    test_create_default_security_group_fail                      OK    0.14\n    test_create_delete_security_group_port_in_use                OK    2.38\n    test_create_port_with_bad_security_group                     OK    0.32\n    test_create_port_with_non_uuid                               OK    0.26\n    test_create_security_group                                   OK    0.37\n    test_create_security_group_rule_bad_remote_group_id          OK    0.20\n    test_create_security_group_rule_bad_security_group_id        OK    0.18\n    test_create_security_group_rule_bad_tenant                   OK    0.22\n    test_create_security_group_rule_bad_tenant_remote_group_id   OK    0.23\n    test_create_security_group_rule_bad_tenant_security_group_ruleOK    0.24\n    test_create_security_group_rule_bulk_emulated                OK    0.36\n    test_create_security_group_rule_bulk_native                  SKIP\n    test_create_security_group_rule_case_insensitive             OK    0.35\n    test_create_security_group_rule_differnt_security_group_ids  SKIP\n    test_create_security_group_rule_duplicate_rule_db            SKIP\n    test_create_security_group_rule_duplicate_rule_db_emulated   OK    0.33\n    test_create_security_group_rule_duplicate_rule_in_post       SKIP\n    test_create_security_group_rule_duplicate_rule_in_post_emulatedOK    0.25\n    test_create_security_group_rule_duplicate_rules              OK    0.26\n    test_create_security_group_rule_ethertype_invalid_as_number  OK    0.22\n    test_create_security_group_rule_group_id                     OK    0.27\n    test_create_security_group_rule_min_port_greater_max         OK    2.68\n    test_create_security_group_rule_ports_but_no_protocol        OK    0.26\n    test_create_security_group_rule_protocol_invalid_as_number   OK    0.19\n    test_create_security_group_rule_remote_ip_prefix             OK    0.24\n    test_create_security_group_rule_with_invalid_ethertype       OK    0.14\n    test_create_security_group_rule_with_invalid_protocol        OK    0.15\n    test_create_security_group_source_group_ip_and_ip_prefix     OK    0.21\n    test_default_security_group                                  OK    0.35\n    test_default_security_group_rules                            OK    0.20\n    test_delete_default_security_group_fail                      OK    0.28\n    test_delete_security_group                                   OK    0.29\n    test_get_security_group                                      OK    0.24\n    test_list_ports_security_group                               OK    0.37\n    test_list_security_group_rules                               OK    0.34\n    test_list_security_group_rules_with_pagination               OK    0.34\n    test_list_security_group_rules_with_pagination_reverse       OK    0.33\n    test_list_security_group_rules_with_sort                     OK    0.31\n    test_list_security_groups                                    OK    2.74\n    test_list_security_groups_with_pagination                    OK    0.33\n    test_list_security_groups_with_pagination_reverse            OK    0.59\n    test_list_security_groups_with_sort                          OK    0.34\n    test_update_port_remove_security_group_empty_list            OK    0.39\n    test_update_port_remove_security_group_none                  OK    0.38\n    test_update_port_with_multiple_security_groups               OK    0.43\n    test_update_port_with_security_group                         OK    0.50\nActionExtensionTest\n    test_extended_action_for_adding_extra_data                   OK    0.11\n    test_extended_action_for_deleting_extra_data                 OK    0.02\n    test_returns_404_for_non_existent_action                     OK    0.03\n    test_returns_404_for_non_existent_resource                   OK    0.02\nExtensionControllerTest\n    test_extension_can_be_accessed_by_alias                      OK    0.02\n    test_index_gets_all_registerd_extensions                     OK    0.02\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionControllerTestXML\n    test_extension_can_be_accessed_by_alias                      OK    0.02\n    test_index_gets_all_registerd_extensions                     OK    0.03\n    test_show_returns_not_found_for_non_existent_extension       OK    0.02\nExtensionManagerTest\n    test_invalid_extensions_are_not_registered                   OK    0.00\nPluginAwareExtensionManagerTest\n    test_extension_loaded_for_non_core_plugin                    OK    0.00\n    test_extensions_are_loaded_for_plugin_with_expected_interfaceOK    0.00\n    test_extensions_are_not_loaded_for_plugins_unaware_of_extensionsOK    0.00\n    test_extensions_expecting_quantum_plugin_interface_are_loadedOK    0.00\n    test_extensions_not_loaded_for_plugin_without_expected_interfaceOK    0.00\n    test_extensions_without_need_for__plugin_interface_are_loadedOK    0.00\n    test_unsupported_extensions_are_not_loaded                   OK    0.00\nRequestExtensionTest\n    test_edit_previously_uneditable_field                        OK    0.02\n    test_extend_get_resource_response                            OK    0.01\n    test_get_resources                                           OK    0.02\n    test_headers_can_be_extended                                 OK    0.01\nResourceExtensionTest\n    test_exceptions_notimplemented                               OK    0.02\n    test_plugin_prefix_with_parent_resource                      OK    0.03\n    test_resource_can_be_added_as_extension                      OK    0.02\n    test_resource_ext_for_formatted_req_on_custom_collection_actionOK    0.02\n    test_resource_ext_for_nested_resource_custom_collection_actionOK    0.02\n    test_resource_ext_with_custom_member_action_gets_plugin_prefixOK    0.03\n    test_resource_extension_for_delete_custom_collection_action  OK    0.01\n    test_resource_extension_for_get_custom_collection_action     OK    0.01\n    test_resource_extension_for_post_custom_collection_action    OK    0.01\n    test_resource_extension_for_put_custom_collection_action     OK    0.01\n    test_resource_extension_with_custom_member_action            OK    0.02\n    test_resource_extension_with_custom_member_action_and_attr_mapOK    0.01\n    test_resource_gets_prefix_of_plugin                          OK    0.02\n    test_returns_404_for_non_existent_extension                  OK    0.01\nIptablesFirewallTestCase\n    test_defer_apply                                             OK    0.01\n    test_filter_defer_with_exception                             OK    0.01\n    test_filter_ipv4_egress                                      OK    0.01\n    test_filter_ipv4_egress_icmp                                 OK    0.01\n    test_filter_ipv4_egress_icmp_prefix                          OK    0.02\n    test_filter_ipv4_egress_prefix                               OK    1.94\n    test_filter_ipv4_egress_tcp                                  OK    0.01\n    test_filter_ipv4_egress_tcp_mport                            OK    0.01\n    test_filter_ipv4_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_tcp_port                             OK    0.01\n    test_filter_ipv4_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv4_egress_udp                                  OK    0.01\n    test_filter_ipv4_egress_udp_mport                            OK    0.01\n    test_filter_ipv4_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_udp_port                             OK    0.01\n    test_filter_ipv4_egress_udp_prefix                           OK    0.01\n    test_filter_ipv4_ingress                                     OK    0.01\n    test_filter_ipv4_ingress_icmp                                OK    0.01\n    test_filter_ipv4_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv4_ingress_prefix                              OK    0.01\n    test_filter_ipv4_ingress_tcp                                 OK    0.01\n    test_filter_ipv4_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv4_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_tcp_port                            OK    0.01\n    test_filter_ipv4_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv4_ingress_udp                                 OK    0.01\n    test_filter_ipv4_ingress_udp_mport                           OK    0.01\n    test_filter_ipv4_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_udp_port                            OK    0.01\n    test_filter_ipv4_ingress_udp_prefix                          OK    0.01\n    test_filter_ipv6_egress                                      OK    0.01\n    test_filter_ipv6_egress_icmp                                 OK    0.01\n    test_filter_ipv6_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv6_egress_prefix                               OK    0.01\n    test_filter_ipv6_egress_tcp                                  OK    0.01\n    test_filter_ipv6_egress_tcp_mport                            OK    0.01\n    test_filter_ipv6_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_tcp_port                             OK    0.01\n    test_filter_ipv6_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv6_egress_udp                                  OK    0.01\n    test_filter_ipv6_egress_udp_mport                            OK    0.01\n    test_filter_ipv6_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_udp_port                             OK    0.01\n    test_filter_ipv6_egress_udp_prefix                           OK    0.01\n    test_filter_ipv6_ingress                                     OK    0.01\n    test_filter_ipv6_ingress_icmp                                OK    0.01\n    test_filter_ipv6_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv6_ingress_prefix                              OK    0.01\n    test_filter_ipv6_ingress_tcp                                 OK    0.01\n    test_filter_ipv6_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv6_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_tcp_port                            OK    0.01\n    test_filter_ipv6_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv6_ingress_udp                                 OK    0.01\n    test_filter_ipv6_ingress_udp_mport                           OK    0.01\n    test_filter_ipv6_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_udp_port                            OK    0.01\n    test_filter_ipv6_ingress_udp_prefix                          OK    0.01\n    test_prepare_port_filter_with_no_sg                          OK    0.01\n    test_remove_unknown_port                                     OK    0.01\n    test_update_delete_port_filter                               OK    0.01\nIptablesManagerStateFulTestCase\n    test_add_and_remove_chain                                    OK    0.00\n    test_add_filter_rule                                         OK    0.00\n    test_add_nat_rule                                            OK    0.00\n    test_add_rule_to_a_nonexistent_chain                         OK    0.00\n    test_binary_name                                             OK    0.02\n    test_get_chanin_name                                         OK    0.01\n    test_remove_nonexistent_chain                                OK    0.01\n    test_remove_nonexistent_rule                                 OK    0.01\nIptablesManagerStateLessTestCase\n    test_nat_not_found                                           OK    0.00\nTestBasicRouterOperations\n    testAgentAddExternalGateway                                  OK    0.04\n    testAgentAddFloatingIP                                       OK    0.02\n    testAgentAddInternalNetwork                                  OK    0.02\n    testAgentCreate                                              OK    0.01\n    testAgentRemoveExternalGateway                               OK    0.02\n    testAgentRemoveFloatingIP                                    OK    0.02\n    testAgentRemoveInternalNetwork                               OK    0.02\n    testAgentRoutingTableUpdated                                 OK    0.01\n    testAgentRoutingTableUpdatedNoNameSpace                      OK    0.01\n    testDestroyNamespace                                         OK    0.01\n    testDestroyNamespaceWithRouterId                             OK    0.01\n    testProcessRouter                                            OK    2.21\n    testRouterInfoCreate                                         OK    0.02\n    testRoutersWithAdminStateDown                                OK    0.02\n    testRoutesUpdated                                            OK    0.03\n    testRoutesUpdatedNoNamespace                                 OK    0.02\n    testSingleLoopRouterRemoval                                  OK    0.06\nTestL3AgentEventHandler\n    test_spawn_metadata_proxy                                    OK    0.03\nL3NatDBTestCase\n    test_create_external_network_admin_suceeds                   OK    0.42\n    test_create_external_network_non_admin_fails                 OK    0.29\n    test_create_floating_non_ext_network_returns_400             OK    0.49\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.18\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.13\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.14\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.48\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.49\n    test_create_port_external_network_admin_suceeds              OK    0.44\n    test_create_port_external_network_non_admin_fails            OK    0.28\n    test_floating_ip_direct_port_delete_returns_409              Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.A9iqYSd3Ja\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/6\n[SCP] Copying console log.\n\n\n','<543387699.160.1366008996474.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1639352334.8111256.1357294737928.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-01-04 05:18:57',-18000,'2013-01-04 10:18:57',NULL,'[OpenStack-Infra] [Openstack-stable-maint] Horizon\n	docs	stable/folsom bitrot job failures','\"James E. Blair\" <corvus at inaugust.com> wrote:\n> Gabriel Hurley <Gabriel.Hurley at nebula.com> writes:\n> \n> >> -----Original Message-----\n> >> From: Mark McLoughlin [mailto:markmc at redhat.com]\n> ...\n> >> Hi Gabriel,\n> >> \n> >> Do you have any idea why this stable/folsom bitrot job has been\n> >> failing\n> >> since December 17?\n> ...\n> > Dying while building sphinx docs? How very odd. There\'s was no\n> > change\n> > that would\'ve started triggering that failure that I\'m aware of.\n> > I\'d\n> > blame some sort of environment config issue offhand...\n> ...\n> \n> Docutils 0.10 was released around that time, but a new version of\n> sphinx\n> that fixes a long-known incompatibility with docutils 0.10 has not\n> been\n> released:\n> \n>   https://bitbucket.org/birkenfeld/sphinx/issue/998/docutils-010-will-break-sphinx-manpage\n> \n> Pinning docutils to 0.9 should help.\n\nFYI: https://review.openstack.org/#/c/18398/\n\n(This patch also fixes a couple of outstanding PEP8 error due to the 1.3.4 release on Dec 18th -- I believe they have to be together to avoid the pep8/docs gates blocking each other).\n\nJulie\n\n\n','<87mwwqgiab.fsf@meyer.lemoncheese.net>',NULL),('<1639352334.8111256.1357294737928.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-04 05:18:57',-18000,'2013-01-04 10:18:57',NULL,'[Openstack-stable-maint] [OpenStack-Infra] Horizon\n	docs	stable/folsom bitrot job failures','\"James E. Blair\" <corvus at inaugust.com> wrote:\n> Gabriel Hurley <Gabriel.Hurley at nebula.com> writes:\n> \n> >> -----Original Message-----\n> >> From: Mark McLoughlin [mailto:markmc at redhat.com]\n> ...\n> >> Hi Gabriel,\n> >> \n> >> Do you have any idea why this stable/folsom bitrot job has been\n> >> failing\n> >> since December 17?\n> ...\n> > Dying while building sphinx docs? How very odd. There\'s was no\n> > change\n> > that would\'ve started triggering that failure that I\'m aware of.\n> > I\'d\n> > blame some sort of environment config issue offhand...\n> ...\n> \n> Docutils 0.10 was released around that time, but a new version of\n> sphinx\n> that fixes a long-known incompatibility with docutils 0.10 has not\n> been\n> released:\n> \n>   https://bitbucket.org/birkenfeld/sphinx/issue/998/docutils-010-will-break-sphinx-manpage\n> \n> Pinning docutils to 0.9 should help.\n\nFYI: https://review.openstack.org/#/c/18398/\n\n(This patch also fixes a couple of outstanding PEP8 error due to the 1.3.4 release on Dec 18th -- I believe they have to be together to avoid the pep8/docs gates blocking each other).\n\nJulie\n\n\n','<87mwwqgiab.fsf@meyer.lemoncheese.net>',NULL),('<1639541984.47.1357778923160.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-10 00:48:42',0,'2013-01-10 00:48:42',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #70','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/70/>\n\n------------------------------------------\n[...truncated 15189 lines...]\ndate: Thu, 10 Jan 2013 00:45:34 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-f1e87412-85ef-45d5-92b5-087f6c2a1b10\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/cd48f6cc-3f70-4159-a017-ec55a752f326\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:35 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-3bd6ade4-693f-4b0a-a324-5e4f6d943ca6\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/76bb2d42-ea8e-479b-903f-66be062a0bec\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:35 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-79cbd9ff-39a4-4306-ad3a-7fe44abbadf0\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f3dd7840-89ab-4834-9757-c2b7eee8387b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:35 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-3b7ee5ea-ed2b-4e0a-a4e8-99a8af99f509\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/04a1d1e5-da2c-4f8f-9a10-8b830c0e254d\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:36 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-54b6e645-4618-46d2-a931-a743a941d8f5\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/549e9cc3-004f-4f79-964c-56667250fc13\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:36 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-336ab903-e006-4670-863d-7b1e6535397a\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/5d00b71f-edfe-49e8-951b-84b67b1f115a\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:37 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-4d2e1d47-cc25-4c64-9746-7b46d4d166fd\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/add9026c-feba-4445-881e-68fc7e28e26d\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:37 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-b7f6a089-35c1-4cbe-9ca0-f28e4abcdca4\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xMFQwMDo0NToyNi4xNDQyNDgiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTExVDAwOjQ1OjI2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWFlMDZlZGExOWQ1NGNjOTg3NjcxMDJlNTA0NTY1YTUiLCAiaWQiOiAiNjM2ZjcwYmYwNTUwNGM0NWI3OGY0Yzg2MzJlY2M3OGUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIyZmE4YWMyZmQ1OWE0ZDAxOTg4NzRhMzA0ZmU2NjdkOCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiNGU1Yzc5ZWY2YjQ1NGEyZjgwZDIxMjIzZjg0ZDFkMTQiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSIsICJpZCI6ICI3ZWJlZDc0YWY4NmY0OTU1ODNhMTc4NWUyZGU1YTFjMSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwZjdjOGJmZjFiMTg0ZWE1YTdjM2RmNTNjM2M1Njk5MyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVhZTA2ZWRhMTlkNTRjYzk4NzY3MTAyZTUwNDU2NWE1IiwgImlkIjogIjk0YTc1ZmU4ODM5ZTQ2NmFiNDU2Mzc2MzIxNmNjZGQ2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81YWUwNmVkYTE5ZDU0Y2M5ODc2NzEwMmU1MDQ1NjVhNSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjI3NjM5OTdjMmU4MTRmNjI5YzcyNmYyMjViODYzZTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiMGIyZDQ5ZDZlMzNlNDU4NjhlZmI1MDkwNjdmZGNjNTEiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMDg4M2JlMjA4MWI5NGE5NDljNmZhZGEyYmUwZTMxNzEiLCAiMTI1MGEwMGY5MWQyNDlhYzkwYTdlNWViODMwMzM3Y2UiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCpoZZrjPsIaZvgsPnp7pvckGOvXv+11WHW6UPStPp4LFz8FKJC2iJqLTk6SSNOpwa5MhPbcHTYqrqHY4hO-azIzZhTusH33Sdv3j0uZGy++FdqvJT2E+dcUGwP+jhUAiepRXWQ8PDDBSYdutjWdCPVXf5U2F88CU1yExEQHIUXeQ==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/4c220126-ff76-425a-a58e-4176bb46d2a1\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 10 Jan 2013 00:45:38 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-5185bf20-499e-4e70-a8f7-0e1502c9f69f\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ERROR\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n======================================================================\nERROR: test_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/volume/admin/test_volume_types.py\", line 96, in test_create_get_delete_volume_with_volume_type_and_extra_specs\n    resp, _ = self.volumes_client.delete_volume(volume[\'id\'])\n  File \"/opt/stack/new/tempest/tempest/services/volume/json/volumes_client.py\", line 89, in delete_volume\n    return self.delete(\"volumes/%s\" % str(volume_id))\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 176, in delete\n    return self.request(\'DELETE\', url, headers)\n  File \"/opt/stack/new/tempest/tempest/common/rest_client.py\", line 245, in request\n    raise exceptions.Unauthorized()\nUnauthorized: Unauthorized\nDetails: Unauthorized\n-------------------- >> begin captured logging << --------------------\ntempest.common.rest_client: ERROR: Request URL: http://127.0.0.1:8776/v1/245c6490cd6a4e6e94698cb335a40ee7/volumes/abf0c42a-a49e-49d4-8637-98c13fb2d984\ntempest.common.rest_client: ERROR: Request Body: None\ntempest.common.rest_client: ERROR: Response Headers: {\'date\': \'Thu, 10 Jan 2013 00:45:52 GMT\', \'status\': \'403\', \'content-length\': \'78\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-30f860e9-ac63-48aa-abb4-5b6a7bb37d96\'}\ntempest.common.rest_client: ERROR: Response Body: {\"forbidden\": {\"message\": \"User does not have admin privileges\", \"code\": 403}}\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 593 tests in 1558.958s\n\nFAILED (SKIP=74, errors=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/rabbitmq/rabbit at devstack-1357764697-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/rabbitmq/rabbit at devstack-1357764697.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d/90-cloudimg-ubuntu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/70/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1639673022.13.1381817038712.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-15 06:03:58',0,'2013-10-15 06:03:58',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-ceilometer-python26-stable-grizzly #31','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/31/changes>\n\n\n\n','<1768961868.7.1381730614664.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<163E353E-DBF4-4CFB-8785-8252F0CB37F7@italy1.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-17 23:18:14',-25200,'2014-06-18 06:18:14',NULL,'[Openstack] Horizon can\'t not login','It is on your shell where your run the packstack install \n\nInviato da iPhone (?)\n\n> Il giorno Jun 17, 2014, alle ore 23:09, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Where can I find the keystone_admin file ???\n>  \n> From: Remo Mattei [mailto:remo at italy1.com] \n> Sent: Wednesday, June 18, 2014 2:07 PM\n> To: Li, Chen\n> Cc: <openstack at lists.openstack.org>\n> Subject: Re: [Openstack] Horizon can\'t not login\n>  \n> You should have a file called keystone_admin with the pass of your dashboard try that. \n>  \n> Remo\n> \n> Inviato da iPhone (?)\n> \n> Il giorno Jun 17, 2014, alle ore 22:28, \"Li, Chen\" <chen.li at intel.com> ha scritto:\n> \n> Hi list,\n>  \n> I just installed a fresh new Horizon on CentOS.\n> My kernel is ?2.6.32-358.el6.x86_64?.\n> And the version of horizon:\n> openstack-dashboard.noarch                        2014.1-1.el6    @openstack-icehouse\n>  \n> When I trying to login , I get error.\n> Here is what I get from /var/log/httpd/error_log:\n> http://paste.openstack.org/show/84366/\n>  \n> Based on https://ask.openstack.org/en/question/6180/unable-to-login-to-openstack-dashboard-havana/\n> I already disabled SELinux and also changed  \n> OPENSTACK_KEYSTONE_DEFAULT_ROLE = \"admin\"\n> \n>  \n> Here is my /etc/openstack-dashboard/local_settings:\n> http://paste.openstack.org/show/84365/\n>  \n> Anyone know why this happened ???\n>  \n> Thanks.\n> -chen\n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n> \n> !DSPAM:1,53a126e8127841117147092!\n> !DSPAM:1,53a12e0c143781762293630!\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140617/a3b11189/attachment.html>\n\n','<988E98D31B01E44893AF6E48ED9DEFD401B3D85E@SHSMSX101.ccr.corp.intel.com>',NULL),('<164013245.3150393.1373553238987.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-07-11 10:33:58',-14400,'2013-07-11 14:33:58',NULL,'[Openstack-docs] Linking to external install guides','----- Original Message -----\n> From: \"Lorin Hochstein\" <lorin at nimbisservices.com>\n> To: \"Tom Fifield\" <tom at openstack.org>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Tuesday, July 9, 2013 10:53:34 PM\n> Subject: Re: [Openstack-docs] Linking to external install guides\n> \n> On Tue, Jul 9, 2013 at 10:37 PM, Tom Fifield <tom at openstack.org> wrote:\n> \n> > On 10/07/13 12:20, Lorin Hochstein wrote:\n> >\n> >> On Tue, Jul 9, 2013 at 8:34 PM, Tom Fifield <tom at openstack.org\n> >> <mailto:tom at openstack.org>> wrote:\n> >>\n> >>     On 10/07/13 00:48, Steve Gordon wrote:\n> >>\n> >>         My understanding is that at least RPM/DEB packages are likely to\n> >>         be available *very* shortly after the actual release for Havana.\n> >>\n> >>\n> >>     I\'ll take a bullish line, which may not necessarily be achievable:\n> >>\n> >>     \"\"\"\n> >>     On the day that the press release for Havana is sent out, we need\n> >>     -by hook or by crook!- to have installation instructions for RHEL\n> >>     and Ubuntu, and ideally SUSE and Debian too.\n> >>     \"\"\"\n> >>\n> >>     I\'m thinking: \"if you can\'t install the software, then it\'s not\n> >>     really a release, is it?\". Release day is our time to shine :)\n> >>\n> >>     So, feasibility/sanity check:\n> >>     * This is unlikely to be provided in time by our friends at RH or\n> >>     Canonical, leaving:\n> >>     Option 1: Delay the press release\n> >>     Option 2: DIY\n> >>\n> >>     Personally, I think Option 1 would be terrible for the community\'s\n> >>     \"feelings\", and tying OpenStack to particular product offerings is\n> >>     not something we should probably be doing :)\n> >>\n> >>     So, for me, that leaves Option 2 :)\n> >>\n> >>     but, it\'s early in the morning .... are there other alternatives?\n> >>\n> >>\n> >>\n> >> Tom:\n> >>\n> >> Just to be explicit here, I can imagine three scenarios for \"release day\"\n> >>\n> >> 1. Downstream packages haven\'t been released yet  :(\n> >> 2. Downstream packages have been released, but there are no accompanying\n> >> install docs   :|\n> >> 3. Downstream packages and accompanying install docs have been released\n> >>  :)\n> >>\n> >> For \"DIY\", are you talking about scenario #1 or scenario #2 (or both?).\n> >>\n> >> Steve alluded to scenario 1 being unlikely, but we should probably talk\n> >> to the distros to see how they plan to align their release packages to\n> >> the official OpenStack release.\n> >>\n> >\n> > Yup, I think in practice #2 is what happens, and that was the one I was\n> > referring to :)\n> >\n> > Regards,\n> >\n> > Tom\n> >\n> >\n> >\n> OK, I grudgingly admit that we probably need to write install docs *at\n> least* for Ubuntu, since I think it\'s unlikely that Canonical will produce\n> install docs for Havana by release day.\n> \n> (Side question: Does Canonical maintain their own install docs for Grizzly?\n> They have an impressive-looking OpenStack page, but I don\'t see install\n> docs linked on it anywhere:\n> http://www.ubuntu.com/cloud/private-cloud/openstack).\n> \n> For RedHat (and SUSE), I think we should contact their doc maintainers and\n> ask them if they\'ll have updated release docs ready on the same day that\n> their packages are ready. No sense duplicating effort if they\'ll be ready\n> quickly enough. If they won\'t be ready, we should *sigh* also probably do\n> an RPM-based install guide. Perhaps I\'m naively optimistic, but I\'m hoping\n> that these distros will be ready quickly with docs since they have a strong\n> incentive to reduce deployment effort.\n> \n> Steve, any insights into how quickly RedHat plans to release their install\n> docs for Havana?\n> \n> Lorin\n\nFor RDO the current plan is (as I understand it) to provide RPMs for each of the Havana milestones and update installation instructions on the Wiki at http://openstack.redhat.com as we go, this generally provides a bare bones guide to getting up and running using the PackStack utility. RDO users that want more flexible deployments currently tend to head to http://docs.openstack.org/ (or at least that is my impression from watching the forums and ask.openstack.org) which is why I want to help with improving the installation guides there for users of Fedora and EL-based distributions.\n\nThe documents that appear at https://access.redhat.com/site/documentation/Red_Hat_OpenStack/ would likely be published some time later, I can\'t really allude to the exact time frames for that unfortunately. A key point here that I brought up in an earlier thread is that those guides start to diverge a fair bit from what\'s currently considered \"OpenStack\" in terms of installation because deployment is ideally performed using PackStack/Foreman/Puppet rather than manually installing and configuring the packages so there is not necessarily a lot of overlap for the \"deployer\" user. We do want to collaborate more on user and administrator documentation though, and I personally am still very much interested in contributing to any RPM-based installation material that continues to live on in openstack-manuals. As per Shaun\'s email I would prefer to see it consolidated into one guide though.\n\nThanks,\n\nSteve\n\n\n','<CADzpNMXczbZXMrLOPfLiJCL9QGPL7MAFpZ=XruDud_gOOk0OjQ@mail.gmail.com>',NULL),('<1640687419.19364469.1387342303596.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-12-17 23:51:43',-18000,'2013-12-18 04:51:43',NULL,'[Openstack-docs] Upgrading to Havana','Hey Nick, \nI don\'t know. I\'ve never been a fan of putting install and upgrade in for mation together. They are two separate user processes (although not two different audiences), so you end up bulking the Install Guide, upgrade in for mation is extremely version dependent (hence the typical tagging into release notes), and dev info coming in usually hits at different times as well. \n\nI think putting it in the wiki is good, is easy to tag just for the Havana page. Will also update the general process in the Ops guide. \n\n? \nSummer \n\n----- Original Message -----\n\n> From: \"Nick Chase\" <nchase at mirantis.com>\n> To: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> Cc: openstack-docs at lists.openstack.org, \"Summer Long\" <slong at redhat.com>\n> Sent: Wednesday, December 18, 2013 2:39:40 PM\n> Subject: Re: [Openstack-docs] Upgrading to Havana\n\n> Actually it sounds like an installation issue to me. Basically you are\n> installing the same version as the install guide, but with the special case\n> that you already have the previous version installed.\n> On Dec 17, 2013 11:12 PM, \"Anne Gentle\" < annegentle at justwriteclick.com >\n> wrote:\n\n> > On Tue, Dec 17, 2013 at 10:03 PM, Summer Long < slong at redhat.com > wrote:\n> \n\n> > > Hi all,\n> > \n> \n> > > Am triaging for bug day, and have signed up to do the upgrade notes\n> > > (perhaps\n> > > not on bug day, but you know what I mean). However, er, where should they\n> > > go?\n> > \n> \n\n> > > Currently, I\'m only seeing the notes in the Ops manual, was there a\n> > > consensus\n> > > to put them somewhere else?\n> > \n> \n> > > A new Upgrading article for the Havana page? The Installation Guide is\n> > > already too bulky (would think).\n> > \n> \n> > > Or have I missed them completely somewhere else?\n> > \n> \n\n> > > Should they also be pulled out of the Ops guide (since upgrading is SO\n> > > version-specific)?\n> > \n> \n\n> > I think the job of upgrading usually lands in an operator/architects lap,\n> > so\n> > I think the Ops Guide is the location. O\'Reilly editor thinks so too. It\n> > shouldn\'t be written to be super version specific, though, if it can be\n> > helped. Here\'s the current section:\n> > http://docs.openstack.org/trunk/openstack-ops/content/maintenance.html#upgrades\n> \n\n> > I hate to envision this, but I wonder if it could be its own guide? Blah. I\n> > stand by my request to have it in the Ops Guide.\n> \n\n> > Anne\n> \n\n> > > thanks, Summer\n> > \n> \n\n> > > --\n> > \n> \n> > > Summer Long\n> > \n> \n> > > OpenStack Documentation Lead\n> > \n> \n> > > Engineering Content Services\n> > \n> \n\n> > > Red Hat Asia Pacific\n> > \n> \n> > > Brisbane, Austral ia\n> > \n> \n> > > slong at redhat.com | irc: slong\n> > \n> \n\n> > > _______________________________________________\n> > \n> \n> > > Openstack-docs mailing list\n> > \n> \n> > > Openstack-docs at lists.openstack.org\n> > \n> \n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> > \n> \n\n> > --\n> \n> > Anne Gentle\n> \n> > annegentle at justwriteclick.com\n> \n\n> > _______________________________________________\n> \n> > Openstack-docs mailing list\n> \n> > Openstack-docs at lists.openstack.org\n> \n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20131217/d23bc02d/attachment.html>\n\n','<CA+p99G=HkR8Yf8ZzKF36eAcy1Fg7BT5ptxyTyhU2O5RdMawSSg@mail.gmail.com>',NULL),('<1640C0EA-107E-4DEF-94FD-DE45CB18C04D@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-07 10:28:51',-25200,'2014-07-07 17:28:51',NULL,'[openstack-dev] [Neutron] cloud-init IPv6 support','I haven?t heard of anyone addressing this, but it seems useful.\n\nVish\n\nOn Jul 7, 2014, at 9:15 AM, Nir Yechiel <nyechiel at redhat.com> wrote:\n\n> AFAIK, the cloud-init metadata service can currently be accessed only by sending a request to http://169.254.169.254, and no IPv6 equivalent is currently implemented. Does anyone working on this or tried to address this before?\n> \n> Thanks,\n> Nir\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/0d2f1851/attachment.pgp>\n\n','<1389135050.3355035.1404749709717.JavaMail.zimbra@redhat.com>',NULL),('<1641071797.14713370.1383227839487.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-31 09:57:19',-14400,'2013-10-31 13:57:19',NULL,'[Openstack-docs] Integrating Ask OpenStack in docs','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> To: \"Nicholas Chase\" <nchase at mirantis.com>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, October 31, 2013 9:44:24 AM\n> Subject: Re: [Openstack-docs] Integrating Ask OpenStack in docs\n> \n> Id values on each section are required because of commenting. We already\n> programatically require this. ASCII doc also allows this. RST doesn\'t have\n> this mechanism nor does markdown.\n\nLooking in the HA guide I see some values like:\n\n[[ha-aa-rabbitmq]]                                                                                                                                                                                    \n=== RabbitMQ \n\nNot sure whether these are considered IDs or anchors in RST?\n\n> We are wanting to replace disqus with an id per output HTML page not per\n> paragraph. If people want to ask about or report a bug for a para they can\n> say so in text, no need for fine grained threads.\n\nSounds right to me.\n\n> Chanda Kumar expressed interest in the implementation and he and David Cramer\n> are going to meet soon. Who else is interested in implementation?\n> \n> I\'m interested in notifications and moderation, how are these handled?\n\nIdeally I think that if someone asks a question coming from say the Installation Guide, it should get an \"install-guide\" tag in ask.o.o and ideally a \"yum\", \"apt\", or \"zypper\" tag. You can \"subscribe\" to tags you are interested in from the ask site itself.\n\nModeration of the question itself should be done in the same way as any other ask.o.o question, authors who don\'t have enough points to moderate on the ask site would pretty quickly gain them if actively engaged (though I know the community team granted some users the magic 500 points recently I\'m not particularly in favour of this approach going forward). At this point I think Tom, Nermina, Nick and myself can already moderate on ask.o.o and you aren\'t too far off.\n\nWhat we may need in addition though is a way to moderate the link between ask and the docs for cases where the question the user ultimately asks does not actually end up relating to the section so we would remove (or modify) the record that links it to the section.\n\nThanks,\n\nSteve\n\n\n','<B52807F3-54B9-4B7F-B6EF-B52EAD8A424A@justwriteclick.com>',NULL),('<1641256581.15.1382855481813.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-27 06:31:21',0,'2013-10-27 06:31:21',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #44','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/44/>\n\n------------------------------------------\n[...truncated 21047 lines...]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   230.737\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           122.162\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   70.332\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]         38.509\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]         37.496\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   36.363\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]      35.763\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                 35.360\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]     34.432\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         33.491\n\n----------------------------------------------------------------------\nRan 1371 tests in 1293.035s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-610871-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-610871.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-610871/44/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<869664958.8.1382682684138.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1641271722.6367928.1416582229769.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-21 10:03:49',-18000,'2014-11-21 15:03:49',NULL,'[openstack-dev] Where should Schema files live?','\n\n> >> Some problems / options:\n> >> a. Unlike Python, there is no simple pip install for text files. No\n> >> version control per se. Basically whatever we pull from the repo. The\n> >> problem with a git clone is we need to tweak config files to point to a\n> >> directory and that\'s a pain for gating tests and CD. Could we assume a\n> >> symlink to some well-known location?\n> >>     a\': I suppose we could make a python installer for them, but that\'s a\n> >>     pain for other language consumers.\n> \n> >Would it be unfair to push that burden onto the writers of clients\n> >in other languages?\n> >\n> >i.e. OpenStack, being largely python-centric, would take responsibility\n> >for both:\n> >\n> >  1. Maintaining the text versions of the schema in-tree (e.g. as json)\n> >\n> >and:\n> >\n> >  2. Producing a python-specific installer based on #1\n> >\n> >whereas, the first Java-based consumer of these schema would take\n> >#1 and package it up in their native format, i.e. as a jar or\n> >OSGi bundle.\n> \n> Certainly an option. My gut says it will lead to abandoned/fragmented\n> efforts.\n> If I was a ruby developer, would I want to take on the burden of maintaining\n> yet another package?\n> I think we need to treat this data as a form of API and there it\'s our\n> responsibility to make easily consumable.\n> \n> (I\'m not hard-line on this, again, just my gut feeling)\n\nOK, that\'s fair.\n\n[snip]\n> >> d. Should we make separate distro packages? Install to a well known\n> >> location all the time? This would work for local dev and integration\n> >> testing and we could fall back on B and C for production distribution. Of\n> >> course, this will likely require people to add a new distro repo. Is that\n> >> a concern?\n> \n> >Quick clarification ... when you say \"distro packages\", do you mean\n> >Linux-distro-specific package formats such as .rpm or .deb?\n> \n> Yep.\n\nSo that would indeed work, but just to sound a small note of caution\nthat keeping an oft-changing package (assumption #5) up-to-date for\nfedora20/21 & epel6/7, or precise/trusty, would involve some work.\n\nI don\'t know much about the Debian/Ubuntu packaging pipeline, in\nparticular how it could be automated.\n\nBut in my small experience of Fedora/EL packaging, the process is\nsomewhat resistant to many fine-grained updates.\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A535222C@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1642708594.7.1376461964739.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-14 06:32:44',0,'2013-08-14 06:32:44',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #3','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/3/>\n\n------------------------------------------\n[...truncated 20999 lines...]\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=6.41 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 6.414/6.414/6.414/0.000 ms\n++ cinder list\n++ get_field 2\n++ grep ex-vol-50e59477\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1376460830\n+ cinder create --display_name ex-vol-50e59477 --display_description \'test volume: ex-vol-50e59477\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-14T06:13:51.299868      |\n| display_description |     test volume: ex-vol-50e59477     |\n|     display_name    |           ex-vol-50e59477            |\n|          id         | a5bab94d-0409-4e50-90ee-f94b804571cc |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-50e59477 | grep available; do sleep 1; done\'\n| a5bab94d-0409-4e50-90ee-f94b804571cc | available | ex-vol-50e59477 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376460833\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-50e59477\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| a5bab94d-0409-4e50-90ee-f94b804571cc | available | ex-vol-50e59477 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=a5bab94d-0409-4e50-90ee-f94b804571cc\n+ die_if_not_set 164 VOL_ID \'Failure retrieving volume ID for ex-vol-50e59477\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1376460834\n+ nova volume-attach 2150d10d-dc5e-42a9-b650-75c3a0f5e038 a5bab94d-0409-4e50-90ee-f94b804571cc /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 2150d10d-dc5e-42a9-b650-75c3a0f5e038 |\n| id       | a5bab94d-0409-4e50-90ee-f94b804571cc |\n| volumeId | a5bab94d-0409-4e50-90ee-f94b804571cc |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-50e59477 | grep in-use; do sleep 1; done\'\n| a5bab94d-0409-4e50-90ee-f94b804571cc | in-use | ex-vol-50e59477 |  1   |     None    |  False   | 2150d10d-dc5e-42a9-b650-75c3a0f5e038 |\n++ date +%s\n+ end_time=1376460839\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-50e59477\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| a5bab94d-0409-4e50-90ee-f94b804571cc | in-use | ex-vol-50e59477 |  1   |     None    |  False   | 2150d10d-dc5e-42a9-b650-75c3a0f5e038 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=2150d10d-dc5e-42a9-b650-75c3a0f5e038\n+ die_if_not_set 178 VOL_ATTACH \'Failure retrieving ex-vol-50e59477 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 2150d10d-dc5e-42a9-b650-75c3a0f5e038 != 2150d10d-dc5e-42a9-b650-75c3a0f5e038 ]]\n++ date +%s\n+ start_time=1376460840\n+ nova volume-detach 2150d10d-dc5e-42a9-b650-75c3a0f5e038 a5bab94d-0409-4e50-90ee-f94b804571cc\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-50e59477 | grep available; do sleep 1; done\'\n| a5bab94d-0409-4e50-90ee-f94b804571cc | available | ex-vol-50e59477 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376460844\n+ echo \'Completed volume-detach in 4 seconds\'\nCompleted volume-detach in 4 seconds\n++ date +%s\n+ start_time=1376460844\n+ cinder delete a5bab94d-0409-4e50-90ee-f94b804571cc\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-50e59477; do sleep 1; done\'\n| a5bab94d-0409-4e50-90ee-f94b804571cc | deleting | ex-vol-50e59477 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376460847\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 2150d10d-dc5e-42a9-b650-75c3a0f5e038\n+ timeout 60 sh -c \'while nova list | grep -q 2150d10d-dc5e-42a9-b650-75c3a0f5e038; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1557.g3049dc9.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpmDscUy\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpJ0S4ei\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpeJx95P\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpYnucyX\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 28, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2456 tests in 1053.407s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/rabbitmq/rabbit at devstack-1376457105-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/rabbitmq/rabbit at devstack-1376457105.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-9782/3/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1683957539.2.1376288988252.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<164297A6-F2DB-44DF-8BD8-87C331F958B2@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-24 18:19:39',-14400,'2014-10-24 22:19:39',NULL,'[openstack-dev] [all][doc]','\nOn Oct 24, 2014, at 3:33 AM, Angelo Matarazzo <angelo.matarazzo at dektech.com.au> wrote:\n\n> Hi all,\n> I have a question for you devs.\n> I don\'t understand the difference between this link \n> http://git.openstack.org/cgit/openstack/governance/tree/reference/ project-testing-interface.rst\n> and\n> https://wiki.openstack.org/wiki/ProjectTestingInterface\n> \n> Some parts don\'t match (e.g. unittest running section).\n> If the git link is the right doc should we update the wiki page?  \n> \n> I found the reference to the wiki page here:\n> https://lists.launchpad.net/openstack/msg08058.html\n> \n> Best regards,\n> Angelo\n\nWe?re working on setting things up so the rst files in that git repository can be published as HTML. When we do that, we should update the wiki page to link to the HTML page. For now, the rst file should be considered the canonical reference, since it is the version managed by the TC.\n\nDoug\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/a6a77f39/attachment.html>\n\n','<544A00B2.1060207@dektech.com.au>',NULL),('<16439607.kJJgCSfxp5@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-01 18:28:34',7200,'2014-04-01 16:28:34',NULL,'[openstack-dev] Sprint at Pycon: Port OpenStack to Python 3','Le mardi 1 avril 2014, 09:44:11 John Dennis a ?crit :\n> > The goal of the sprint is to port OpenStack components and OpenStack\n> > dependencies to Python 3,\n> \n> This is a great goal, thank you! But I\'m concerned it might be premature.\n\nThe portage is already in progress. There are many components (8 clients) \nwhere the py33 (Python 3.3) gate is voting. We try to keep this page up to \ndate:\n\n   https://wiki.openstack.org/wiki/Python3\n\nThere are already a lot of dependencies which are already Python 3 compatible, \nand the portage of OpenStack \"server\" components already started.\n\n> My concern is this. The singled biggest change in Py2 -> Py3 is string\n> handling, especially with regards to str vs. unicode. We have a\n> significant number of bugs in the current code base with regards to\n> encoding exceptions, I just got done fixing a number of them, I know\n> there are others.\n\nIn which OpenStack component?\n\n> While I was fixing them I searched the OpenStack\n> coding guidelines to find out coding practices were supposed to be\n> enforcing with regards to non-ASCII strings and discovered there is\n> isn\'t much, it seems incomplete. Some of it seems based more on\n> speculation than actual knowledge of defined Python behavior. I\'m not\n> sure, but given we do not have clear guidelines for unicode in Py2,\n> never mind guidelines that will allow running under both Py2 and Py3 I\'m\n> willing to guess we have little in the gate testing that enforces any\n> string handling guidelines.\n\nIt\'s an ongoing effort. We are slowly porting code but also adding new tests \nfor non-ASCII data. For example, one of my recent patch for swiftclient adds \nnew tests for non-ASCII URLs, whereas the existing tests only test ASCII \n(which is irrevelant for this specific test):\n\n   https://review.openstack.org/#/c/84102/\n\nTo be honest, we invest more time on fixing Python 3 issues than on adding new \ntests to check for non-regression. The problem is that currently, you cannot \neven import the Python module, so it\'s hard to run tests and harder to add new \ntests.\n\nI hope that it will become easier to run tests on Python 2 and Python 3, and \nto add more tests for non-ASCII data.\n\n> I\'m just in the process of finishing up a document to address these\n> concerns. Unfortunately I\'m going to be off-line for several weeks and I\n> didn\'t want to start a discussion I couldn\'t participate in (plus there\n> are some Py3 issues in the document I need to clean up) so I was going\n> to wait to post it.\n\nThere are some \"guidelines\" to port Python 2 code on Python 3 on the wiki \npage. You may complete it?\n\n   https://wiki.openstack.org/wiki/Python3\n\n> My concern is we need to get our Py2 house in order *before* tackling\n> Py3 porting. Doing Py3 porting before we have clear guidelines on\n> unicode, str, bytes, encoding, etc. along with gate tests that enforce\n> these guidelines is putting the cart before the horse. Whatever patches\n> come out of a Py3 porting sprint might have to be completely redone.\n\nIt\'s not easy to detect Unicode issues using Python 2 since most setup are in \nenglish, only no test using non-ASCII data right now, and Python 2 uses \nimplicit conversion between bytes and Unicode strings.\n\nIt\'s much easier to detect Unicode issues using Python 3. I don\'t want to drop \nPython 2 support, just *add* Python 3 support. The code will work on 2.6-3.3.\n\n> FWIW projects that deal with web services, wire protocols, external\n> datastores, etc. who have already started porting to Py3 have\n> encountered significant pain points with Py3, some of which is just\n> being resolved and which have caused on-going changes in Py3. We deal\n> with a lot of these same issues in OpenStack. Before we just start\n> hacking away I think it would behoove us to first have a very clear and\n> explicit document on how we\'re going to address these issues *before* we\n> start changing code.\n\nThere are many web servers and clients already running on Python 3. For \nexample, Django supports Python 3 since its version 1.5 (released in February \n2013). I ported Paste and PasteScript on Python 3, but there are also web \nmodules already Python 3 compatible (ex: WebOb).\n\nVictor\n\n\n','<533AC2AB.4080801@redhat.com>',NULL),('<1643E9DF-C5D0-4F80-AA09-8E4A6AF8BDD6@codestud.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-26 10:24:59',-18000,'2013-06-26 15:24:59',NULL,'[openstack-dev] [Nova] Nominating John Garbutt for nova-core','+1\n\nOn Jun 26, 2013, at 10:09 AM, Russell Bryant <rbryant at redhat.com> wrote:\n\n> Greetings,\n> \n> I would like to nominate John Garbutt for the nova-core team.\n> \n> John has been involved with nova for a long time now.  He\'s primarily\n> known for his great work on the xenapi driver.  However, he has been\n> contributing and reviewing in other areas, as well.  Based on my\n> experience with him I think he would be a good addition, so it would be\n> great to have him on board to help keep up with the review load.\n> \n> Please respond with +1s or any concerns.\n> \n> References:\n> \n>  https://review.openstack.org/#/dashboard/782\n> \n>  https://review.openstack.org/#/q/reviewer:782,n,z\n> \n>  https://launchpad.net/~johngarbutt/+specs?role=assignee\n> \n>  https://launchpad.net/~johngarbutt/+bugs?role=assignee\n> \n> Thanks,\n> \n> -- \n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<51CB042E.5080802@redhat.com>',NULL),('<1644368108.35.1383372147006.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:02:27',0,'2013-11-02 06:02:27',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-horizon-python26-stable-folsom #47','See <https://jenkins02.openstack.org/job/periodic-horizon-python26-stable-folsom/47/>\n\n\n\n',NULL,NULL),('<1644441337.8563326.1397496910280.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-14 13:35:10',-14400,'2014-04-14 17:35:10',NULL,'[openstack-dev] [tripleo] /bin/bash vs. /bin/sh','\n\n----- Original Message -----\n> From: \"Ben Nemec\" <openstack at nemebean.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, April 14, 2014 12:26:17 PM\n> Subject: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh\n> \n> tldr: I propose we use bash explicitly for all diskimage-builder scripts\n> (at least for the short-term - see details below).\n> \n> This is something that was raised on my linting changes to enable set -o\n> pipefail.  That is a bash-ism, so it could break in the\n> diskimage-builder scripts that are run using /bin/sh.  Two possible\n> fixes for that: switch to /bin/bash, or don\'t use -o pipefail\n> \n> But I think this raises a bigger question - does diskimage-builder\n> require bash?  If so, I think we should just add a rule to enforce that\n> /bin/bash is the shell used for everything. \n\nThis sounds like the easiest (and possibly best) solution here to me.\n\n> I know we have a bunch of\n> bash-isms in the code already, so at least in the short-term I think\n> this is probably the way to go, so we can get the benefits of things\n> like -o pipefail and lose the ambiguity we have right now.  For\n> reference, a quick grep of the diskimage-builder source shows we have\n> 150 scripts using bash explicitly and only 24 that are plain sh, so\n> making the code truly shell-agnostic is likely to be a significant\n> amount of work.\n> \n> In the long run it might be nice to have cross-shell compatibility, but\n> if we\'re going to do that I think we need a couple of things: 1) Someone\n> to do the work (I don\'t have a particular need to run dib in not-bash,\n> so I\'m not signing up for that :-) 2) Testing in other shells -\n> obviously just changing /bin/bash to /bin/sh doesn\'t mean we actually\n> support anything but bash.  We really need to be gating on other shells\n> if we\'re going to make a significant effort to support them.  It\'s not\n> good to ask reviewers to try to catch every bash-ism proposed in a\n> change.  This also relates to some of the unit testing work that is\n> going on right now too - if we had better unit test coverage of the\n> scripts we would be able to do this more easily.\n> \n> Thoughts?\n\nI see the fact that DIB uses /bin/bash as mostly an implementation detail. So long as we keep this internal to DIB it shouldn\'t matter what shell we use right? And on that note why not just make things simpler and require and use /bin/bash?\n\nThe only exception would be for scripts that might need to be sourced by end users in their own environment shells. And for those we can certainly try to make things as generic as possible.\n\n> \n> Thanks.\n> \n> -Ben\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<534C0C29.8010005@nemebean.com>',NULL),('<164465317.12.1352851335020.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:02:14',0,'2012-11-14 00:02:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/92/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric1 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/>\nCheckout:periodic-horizon-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/> - hudson.remoting.Channel at 62f4a9a3:oneiric1\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson2551763663853293196.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<2073878392.53.1352765054745.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1644928438.34205768.1386607472433.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-09 11:44:32',-18000,'2013-12-09 16:44:32',NULL,'[openstack-dev] [Solum] Second working group meeting on\n	language packs today','----- Original Message -----\n> Hi,\n> \n> We will hold our second Git Integration working group meeting on IRC in\n> #solum on Monday, December 9, 2013 1700 UTC / 0900 PST.\n> \n> Agenda for today\'s meeting:\n> 	* Administrative:\n> 		* Decide whether to continue this meeting at the same time in January\n> 	* Topics:\n> 		* Determine minimal set of milestone-1 functionality\n>                 * Get volunteers for milestone-1 example language packs\n\nAdding:\n                * Discuss https://wiki.openstack.org/wiki/Solum/specify-lang-pack-design\n\n>               * Discuss names\n> 	* General discussion\n> \n> ----- Original Message -----\n> > Meeting 1 was conducted on Monday and consisted mostly of freeform\n> > discussions, clarification, and QA:\n> > http://irclogs.solum.io/2013/solum.2013-12-02-17.05.html.  The next meeting\n> > is Monday, December 9, 2013 1700 UTC.\n> > \n> > Wiki:\n> > https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts\n> > \n> > Action and open topics:\n> > \n> > * Updated proposal wiki with personas\n> > * Discussed whether a single command or multiple commands are needed to\n> > transform an image (one for build+test, or two)\n> > ** Believe 1 is sufficient to encapsulate the entire transformation, use\n> > cases are needed to justify extras.\n> > * The parent blueprint and wiki page represents the general design and\n> > philosophy, and specific child blueprints will target exact scenarios for\n> > milestones\n> > * [NEXT] Helpful discussion on the injection of artifacts such that the\n> > transformation script can operator on them.  No clear design, but lots of\n> > suggestions\n> > * Strong consensus that the the transformation script should depend on\n> > Solum\n> > or OpenStack concepts - a developer should be able to debug a\n> > transformation\n> > by using the image themselves, or run it outside of Solum.\n> > * Should anticipate that the transformation environment and execution\n> > environment might have different resource needs - i.e. Java maven may\n> > require more memory than Java execution\n> > * [NEXT] Should the transformation happen inside the environment the app is\n> > destined for (i.e. able to reach existing deployed resources) or in a\n> > special build env?\n> > ** No consensus, arguments for and against\n> > ** Transformation environments may need external network access, production\n> > environments may not allow it\n> > * Transformation should remove or disable debugging or compile tools prior\n> > to\n> > execution for security - this is a recommendation to image authors\n> > * The final execution environment may dynamically define exposed ports that\n> > Solum must be aware of\n> > ** For M1 the recommendation was to focus on upfront definition via\n> > metadata\n> > * [AGREED] No external metadata service would be part of Solum, any\n> > metadata\n> > that needs to be provided to the image during transformation would be done\n> > via injection and be an argument to prepare\n> > ** That might be via userdata or docker environment variables and bind\n> > mounted files\n> \n\n\n','<1036673267.34198951.1386606741776.JavaMail.root@redhat.com>',NULL),('<1645612206.119182.1414239208168.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-25 08:13:28',-14400,'2014-10-25 12:13:28',NULL,'[openstack-dev] [NFV] NFV BoF session for OpenStack Summit Paris','----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> ----- Original Message -----\n> > From: \"Steve Gordon\" <sgordon at redhat.com>\n> > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > <openstack-dev at lists.openstack.org>\n> > ----- Original Message -----\n> > > From: \"Steve Gordon\" <sgordon at redhat.com>\n> > > To: \"OpenStack Development Mailing List (not for usage questions)\"\n> > > <openstack-dev at lists.openstack.org>\n> > > \n> > > Hi all,\n> > > \n> > > I took an action item in one of the meetings to try and find a\n> > > date/time/space to do another NFV BoF session for Paris to take advantage\n> > > of\n> > > the fact that many of us will be in attendance for a face to face\n> > > session.\n> > > \n> > > To try and avoid clashing with the general and design summit sessions I\n> > > am\n> > > proposing that we meet either before the sessions start one morning,\n> > > during\n> > > the lunch break, or after the sessions finish for the day. For the lunch\n> > > sessions the meeting would be shorter to ensure people actually have time\n> > > to\n> > > grab lunch beforehand.\n> > > \n> > > I\'ve put together a form here, please register your preferred date/time\n> > > if\n> > > you would be interested in attending an NFV BoF session:\n> > > \n> > >     http://doodle.com/qchvmn4sw5x39cps\n> > > \n> > > I will try and work out the *where* once we have a clear picture of the\n> > > preferences for the above. We can discuss further in the weekly meeting.\n> > > \n> > > Thanks!\n> > > \n> > > Steve\n> > > \n> > > [1]\n> > > https://openstacksummitnovember2014paris.sched.org/event/f5bcb6033064494390342031e48747e3#.VEWEIOKmhkM\n> > \n> > Hi all,\n> > \n> > I have just noticed an update on a conversation I had been following on the\n> > community list:\n> > \n> >     http://lists.openstack.org/pipermail/community/2014-October/000921.html\n> > \n> > It seems like after hours use of the venue will not be an option in Paris,\n> > though there may be some space available for BoF style activities on\n> > Wednesday. I also noticed this \"Win the telco BoF\" session on the summit\n> > schedule for the creation of a *new* working group:\n> > \n> >     https://openstacksummitnovember2014paris.sched.org/event/f5bcb6033064494390342031e48747e3#.VEbRkOKmhkM\n> > \n> > Does anyone know anything about this? It\'s unclear if this is the\n> > appropriate\n> > place to discuss the planning and development activities we\'ve been working\n> > on. Let\'s discuss further in the meeting tomorrow.\n> > \n> > Thanks,\n> > \n> > Steve\n> \n> Ok, it looks like there is a user-committee email on this topic now:\n> \n>     http://lists.openstack.org/pipermail/user-committee/2014-October/000320.html\n> \n> I did reach out to Carol to highlight the existing efforts before the above\n> was sent but it seems it still does contain quite a bit of overlap.\n> \n> -Steve\n\nHi all,\n\nThere is some more detail on the above here for those who don\'t subscribe to user-committee:\n\n    http://lists.openstack.org/pipermail/user-committee/2014-October/000322.html\n\nThe updated session entry is here:\n\n    http://kilodesignsummit.sched.org/event/b3ccf1464e335b703fc126f068142792\n\nI would also like to highlight that the Nova design track has a specific session allocated to discuss NFV related specifications:\n\n    http://kilodesignsummit.sched.org/event/aa14a2bd2a4c1afa1aa24a60c3131fcc\n\nLet\'s work this week to make sure that the relevant specification submissions on the Nova side are in good shape to ensure a productive discussion.\n\nThanks,\n\nSteve\n\n\n\n','<2129827367.45469126.1414015273339.JavaMail.zimbra@redhat.com>',NULL),('<1646488974.19131.1396948743203.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-08 11:19:03',7200,'2014-04-08 09:19:03',NULL,'[openstack-dev] Issues when running unit tests in OpenStack','Sylvain Bauza wrote:\n>> (2) When a test fails, it\'s hard to find the command to rerun a single\n>> failing test.\n> (...) \n> \n> See the wiki page I gave to you. Some helpful tricks are there. That said, I\n> never had the issue you mentioned related to only checking one unittest by\n> providing the path.\n> When I\'m isolating one test, tox -epy27 <pattern> is enough for me.\n\nFor the \"parameter ignore\", here is an example with Oslo Incubator (which uses testr, at least for Python 2):\n\n$ tox -e py27\n...\nFAIL: tests.unit.test_timeutils.TestIso8601Time.test_west_normalize\n...\nRan 8675 (+8673) tests in 16.137s (+16.083s)\n...\n\n$ tox -e py27 tests.unit.test_timeutils.TestIso8601Time.test_west_normalize \n...\nFAIL: tests.unit.test_timeutils.TestIso8601Time.test_west_normalize\n...\nRan 8675 (+8455) tests in 17.250s (-39.332s)\n\n> You can run testtools without testr. Nosetests has been marked as\n> non-supported, IIRC.\n\nOslo Incubator runs unit tests using nosetests. I tried to use testr, but it fails on Python 3 because the openstack.common.eventlet_backdoor module cannot be loaded (eventlet is not available on Python 3).\n\nHow can I ignore openstack.common.eventlet_backdoor using testr? I understood that testr first loads all modules and then filter them using the regex.\n\nVictor\n\n\n','<CANWE-CnPa1MQm57245tEkB3_Aft0xRgFDLym4HQOU8yDgUL1hA@mail.gmail.com>',NULL),('<1646887523.2.1387087357249.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:02:37',0,'2013-12-15 06:02:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-keystone-docs-grizzly #5','See <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise13 in workspace <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/>\nCheckout:periodic-keystone-docs-grizzly / <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/> - hudson.remoting.Channel at 32915ba8:precise13\nUsing strategy: Default\nLast Built Revision: Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/keystone\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/keystone\nCommencing build of Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\nChecking out Revision 82dcde08f60c45002955875664a3cf82d1d211bc (origin/stable/grizzly)\n[periodic-keystone-docs-grizzly] $ /bin/bash -xe /tmp/hudson5182918377330992024.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=keystone\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n++ org=openstack\n++ project=keystone\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack keystone /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=keystone\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z keystone ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/keystone /opt/requirements/projects.txt\nopenstack/keystone\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/tools/pip-requires,> -r<https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/tools/test-requires>\nvenv inst: <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/dist/keystone-jenkins.periodic.keystone.docs.grizzly.5.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/>\nGenerating doc/source/api/keystone.auth.controllers.rst\nGenerating doc/source/api/keystone.auth.core.rst\nGenerating doc/source/api/keystone.auth.plugins.password.rst\nGenerating doc/source/api/keystone.auth.plugins.token.rst\nGenerating doc/source/api/keystone.auth.routers.rst\nGenerating doc/source/api/keystone.auth.token_factory.rst\nGenerating doc/source/api/keystone.catalog.backends.kvs.rst\nGenerating doc/source/api/keystone.catalog.backends.sql.rst\nGenerating doc/source/api/keystone.catalog.backends.templated.rst\nGenerating doc/source/api/keystone.catalog.controllers.rst\nGenerating doc/source/api/keystone.catalog.core.rst\nGenerating doc/source/api/keystone.catalog.routers.rst\nGenerating doc/source/api/keystone.clean.rst\nGenerating doc/source/api/keystone.cli.rst\nGenerating doc/source/api/keystone.common.bufferedhttp.rst\nGenerating doc/source/api/keystone.common.cms.rst\nGenerating doc/source/api/keystone.common.config.rst\nGenerating doc/source/api/keystone.common.controller.rst\nGenerating doc/source/api/keystone.common.dependency.rst\nGenerating doc/source/api/keystone.common.kvs.rst\nGenerating doc/source/api/keystone.common.ldap.core.rst\nGenerating doc/source/api/keystone.common.ldap.fakeldap.rst\nGenerating doc/source/api/keystone.common.logging.rst\nGenerating doc/source/api/keystone.common.manager.rst\nGenerating doc/source/api/keystone.common.models.rst\nGenerating doc/source/api/keystone.common.openssl.rst\nGenerating doc/source/api/keystone.common.router.rst\nGenerating doc/source/api/keystone.common.serializer.rst\nGenerating doc/source/api/keystone.common.sql.core.rst\nGenerating doc/source/api/keystone.common.sql.legacy.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.manage.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.001_add_initial_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.002_token_id_hash.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.003_token_valid.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.004_undo_token_id_hash.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.005_set_utf8_character_set.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.006_add_policy_table.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.007_add_domain_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.008_create_default_domain.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.009_normalize_identity.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.010_normalize_identity_migration.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.011_endpoints_v3.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.012_populate_endpoint_type.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.013_drop_legacy_endpoints.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.014_add_group_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.015_tenant_to_project.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.016_normalize_domain_ids.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.017_membership_role.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.018_add_trust_tables.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.019_fixup_role.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.020_migrate_metadata_table_roles.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.021_add_trust_to_token.rst\nGenerating doc/source/api/keystone.common.sql.migrate_repo.versions.022_move_legacy_endpoint_id.rst\nGenerating doc/source/api/keystone.common.sql.migration.rst\nGenerating doc/source/api/keystone.common.sql.nova.rst\nGenerating doc/source/api/keystone.common.sql.util.rst\nGenerating doc/source/api/keystone.common.systemd.rst\nGenerating doc/source/api/keystone.common.utils.rst\nGenerating doc/source/api/keystone.common.wsgi.rst\nGenerating doc/source/api/keystone.config.rst\nGenerating doc/source/api/keystone.contrib.access.core.rst\nGenerating doc/source/api/keystone.contrib.admin_crud.core.rst\nGenerating doc/source/api/keystone.contrib.ec2.backends.kvs.rst\nGenerating doc/source/api/keystone.contrib.ec2.backends.sql.rst\nGenerating doc/source/api/keystone.contrib.ec2.core.rst\nGenerating doc/source/api/keystone.contrib.s3.core.rst\nGenerating doc/source/api/keystone.contrib.stats.backends.kvs.rst\nGenerating doc/source/api/keystone.contrib.stats.core.rst\nGenerating doc/source/api/keystone.contrib.user_crud.core.rst\nGenerating doc/source/api/keystone.controllers.rst\nGenerating doc/source/api/keystone.exception.rst\nGenerating doc/source/api/keystone.identity.backends.kvs.rst\nGenerating doc/source/api/keystone.identity.backends.ldap.core.rst\nGenerating doc/source/api/keystone.identity.backends.pam.rst\nGenerating doc/source/api/keystone.identity.backends.sql.rst\nGenerating doc/source/api/keystone.identity.controllers.rst\nGenerating doc/source/api/keystone.identity.core.rst\nGenerating doc/source/api/keystone.identity.routers.rst\nGenerating doc/source/api/keystone.middleware.auth_token.rst\nGenerating doc/source/api/keystone.middleware.core.rst\nGenerating doc/source/api/keystone.middleware.ec2_token.rst\nGenerating doc/source/api/keystone.middleware.s3_token.rst\nGenerating doc/source/api/keystone.openstack.common.gettextutils.rst\nGenerating doc/source/api/keystone.openstack.common.importutils.rst\nGenerating doc/source/api/keystone.openstack.common.jsonutils.rst\nGenerating doc/source/api/keystone.openstack.common.policy.rst\nGenerating doc/source/api/keystone.openstack.common.setup.rst\nGenerating doc/source/api/keystone.openstack.common.timeutils.rst\nGenerating doc/source/api/keystone.openstack.common.version.rst\nGenerating doc/source/api/keystone.policy.backends.rules.rst\nGenerating doc/source/api/keystone.policy.backends.sql.rst\nGenerating doc/source/api/keystone.policy.controllers.rst\nGenerating doc/source/api/keystone.policy.core.rst\nGenerating doc/source/api/keystone.policy.routers.rst\nGenerating doc/source/api/keystone.routers.rst\nGenerating doc/source/api/keystone.service.rst\nGenerating doc/source/api/keystone.test.rst\nGenerating doc/source/api/keystone.token.backends.kvs.rst\nGenerating doc/source/api/keystone.token.backends.memcache.rst\nGenerating doc/source/api/keystone.token.backends.sql.rst\nGenerating doc/source/api/keystone.token.controllers.rst\nGenerating doc/source/api/keystone.token.core.rst\nGenerating doc/source/api/keystone.token.routers.rst\nGenerating doc/source/api/keystone.trust.backends.kvs.rst\nGenerating doc/source/api/keystone.trust.backends.sql.rst\nGenerating doc/source/api/keystone.trust.controllers.rst\nGenerating doc/source/api/keystone.trust.core.rst\nGenerating doc/source/api/keystone.trust.routers.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-grizzly/precise13\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-docs-grizzly/precise13/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1647485198.37853953.1403296007239.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-20 16:26:47',-14400,'2014-06-20 20:26:47',NULL,'[openstack-dev] [TripleO] [Heat] Reminder: Mid-cycle Meetup\n	-	Attendance Confirmation','Any more takers for the tripleo mid-cycle meetup in Raleigh? If so, please\nsign up on the etherpad below.\n\nThe hotel group room rate will be finalized on Monday Jul 23rd (US time), \nafter that time you will be on your own for finding accommodation.\n\nThanks\nCharles\n\n----- Original Message -----\n> Hi all,\n> \n> I would like to remind you to sign up for mid-cycle meetup which is\n> happening July 21-25 in Raleigh:\n> \n> * https://etherpad.openstack.org/p/juno-midcycle-meetup\n> \n> We need number of participants as soon as possible so that we can ask\n> for group discount at the hotel. Also if we don\'t get rooms in one of\n> these two hotels (see etherpad) the experience of accommodation is\n> rapidly decreasing. Therefor I would like to ask everybody, if you can\n> confirm your attendance as soon as possible.\n> \n> If you have any related question just let me know, I will be happy to help.\n> \n> Looking forward to seeing you all in Raleigh\n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<53A009AC.4080901@redhat.com>',NULL),('<1647594116.3.1387087426599.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-15 06:03:46',0,'2013-12-15 06:03:46',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-neutron-docs-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-neutron-docs-grizzly/8/changes>\n\n\n\n','<2044324869.2.1387001075108.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1647630671.41.1381385294124.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-10 06:08:13',0,'2013-10-10 06:08:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #37','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 11879 lines...]\n2013-10-10 06:07:41   Running setup.py install for python-mimeparse\n2013-10-10 06:07:41     \n2013-10-10 06:07:41   Running setup.py install for fixtures\n2013-10-10 06:07:41     \n2013-10-10 06:07:42   Running setup.py install for python-subunit\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-1to2 from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-2to1 from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit2gtk from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit2junitxml from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit2pyunit from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-filter from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-ls from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-notify from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-stats from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/subunit-tags from 644 to 755\n2013-10-10 06:07:42     changing mode of build/scripts-2.7/tap2subunit from 644 to 755\n2013-10-10 06:07:42     \n2013-10-10 06:07:42     warning: no previously-included files found matching \'.bzrignore\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'aclocal.m4\'\n2013-10-10 06:07:42     no previously-included directories found matching \'autom4te.cache\'\n2013-10-10 06:07:42     no previously-included directories found matching \'c\'\n2013-10-10 06:07:42     no previously-included directories found matching \'c++\'\n2013-10-10 06:07:42     no previously-included directories found matching \'compile\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'configure*\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'depcomp\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'INSTALL\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'install-sh\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'lib*\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'ltmain.sh\'\n2013-10-10 06:07:42     no previously-included directories found matching \'m4\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'Makefile*\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'missing\'\n2013-10-10 06:07:42     no previously-included directories found matching \'perl\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'py-compile\'\n2013-10-10 06:07:42     no previously-included directories found matching \'shell\'\n2013-10-10 06:07:42     warning: no previously-included files found matching \'stamp-h1\'\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-notify to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-2to1 to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/tap2subunit to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-filter to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-tags to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit2pyunit to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit2gtk to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-ls to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit2junitxml to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-stats to 755\n2013-10-10 06:07:42     changing mode of /usr/local/bin/subunit-1to2 to 755\n2013-10-10 06:07:42 Successfully installed testtools testresources testrepository extras python-mimeparse fixtures python-subunit\n2013-10-10 06:07:42 Cleaning up...\n2013-10-10 06:07:42 ++ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-10-10 06:07:42 running develop\n2013-10-10 06:07:42 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-10-10 06:07:42 /usr/bin/python -E -c pass\n2013-10-10 06:07:42 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-10-10 06:07:42 running egg_info\n2013-10-10 06:07:42 writing requirements to tempest.egg-info/requires.txt\n2013-10-10 06:07:42 writing tempest.egg-info/PKG-INFO\n2013-10-10 06:07:42 writing top-level names to tempest.egg-info/top_level.txt\n2013-10-10 06:07:42 writing dependency_links to tempest.egg-info/dependency_links.txt\n2013-10-10 06:07:42 reading manifest template \'MANIFEST.in\'\n2013-10-10 06:07:42 warning: no files found matching \'AUTHORS\'\n2013-10-10 06:07:42 warning: no files found matching \'ChangeLog\'\n2013-10-10 06:07:42 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-10-10 06:07:42 writing manifest file \'tempest.egg-info/SOURCES.txt\'\n2013-10-10 06:07:42 running build_ext\n2013-10-10 06:07:42 Creating /usr/local/lib/python2.7/dist-packages/tempest.egg-link (link to .)\n2013-10-10 06:07:42 Adding tempest 2013.1.a972.g2c3bbea to easy-install.pth file\n2013-10-10 06:07:42 Installing tempest script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Installed /opt/stack/new/tempest\n2013-10-10 06:07:42 Processing dependencies for tempest==2013.1.a972.g2c3bbea\n2013-10-10 06:07:42 Searching for oslo.config==1.2.1\n2013-10-10 06:07:42 Best match: oslo.config 1.2.1\n2013-10-10 06:07:42 oslo.config 1.2.1 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for testrepository==0.0.17\n2013-10-10 06:07:42 Best match: testrepository 0.0.17\n2013-10-10 06:07:42 testrepository 0.0.17 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for keyring==1.6.1\n2013-10-10 06:07:42 Best match: keyring 1.6.1\n2013-10-10 06:07:42 keyring 1.6.1 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing keyring script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for testresources==0.2.7\n2013-10-10 06:07:42 Best match: testresources 0.2.7\n2013-10-10 06:07:42 testresources 0.2.7 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for python-quantumclient==2.2.4.3\n2013-10-10 06:07:42 Best match: python-quantumclient 2.2.4.3\n2013-10-10 06:07:42 python-quantumclient 2.2.4.3 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing quantum script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for python-novaclient==2.15.0.54.g59ea4e1\n2013-10-10 06:07:42 Best match: python-novaclient 2.15.0.54.g59ea4e1\n2013-10-10 06:07:42 python-novaclient 2.15.0.54.g59ea4e1 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing nova script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /opt/stack/new/python-novaclient\n2013-10-10 06:07:42 Searching for python-keystoneclient==0.4.0\n2013-10-10 06:07:42 Best match: python-keystoneclient 0.4.0\n2013-10-10 06:07:42 Removing python-keystoneclient 0.2.5 from easy-install.pth file\n2013-10-10 06:07:42 python-keystoneclient 0.4.0 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing keystone script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /opt/stack/new/python-keystoneclient\n2013-10-10 06:07:42 Searching for python-glanceclient==0.10.0.29.gcd11833\n2013-10-10 06:07:42 Best match: python-glanceclient 0.10.0.29.gcd11833\n2013-10-10 06:07:42 python-glanceclient 0.10.0.29.gcd11833 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing glance script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /opt/stack/new/python-glanceclient\n2013-10-10 06:07:42 Searching for netaddr==0.7.10\n2013-10-10 06:07:42 Best match: netaddr 0.7.10\n2013-10-10 06:07:42 Adding netaddr 0.7.10 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for paramiko==1.7.7.1\n2013-10-10 06:07:42 Best match: paramiko 1.7.7.1\n2013-10-10 06:07:42 Adding paramiko 1.7.7.1 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for boto==2.2.2\n2013-10-10 06:07:42 Best match: boto 2.2.2\n2013-10-10 06:07:42 Adding boto 2.2.2 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for lxml==2.3.2\n2013-10-10 06:07:42 Best match: lxml 2.3.2\n2013-10-10 06:07:42 Adding lxml 2.3.2 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for testtools==0.9.32\n2013-10-10 06:07:42 Best match: testtools 0.9.32\n2013-10-10 06:07:42 testtools 0.9.32 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for httplib2==0.7.2\n2013-10-10 06:07:42 Best match: httplib2 0.7.2\n2013-10-10 06:07:42 Adding httplib2 0.7.2 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for nose==1.1.2\n2013-10-10 06:07:42 Best match: nose 1.1.2\n2013-10-10 06:07:42 Adding nose 1.1.2 to easy-install.pth file\n2013-10-10 06:07:42 Installing nosetests script to /usr/local/bin\n2013-10-10 06:07:42 Installing nosetests-2.7 script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for anyjson==0.3.1\n2013-10-10 06:07:42 Best match: anyjson 0.3.1\n2013-10-10 06:07:42 Adding anyjson 0.3.1 to easy-install.pth file\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for six==1.4.1\n2013-10-10 06:07:42 Best match: six 1.4.1\n2013-10-10 06:07:42 six 1.4.1 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for python-subunit==0.0.15\n2013-10-10 06:07:42 Best match: python-subunit 0.0.15\n2013-10-10 06:07:42 python-subunit 0.0.15 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for fixtures==0.3.14\n2013-10-10 06:07:42 Best match: fixtures 0.3.14\n2013-10-10 06:07:42 fixtures 0.3.14 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages\n2013-10-10 06:07:42 Searching for python-neutronclient==2.3.1.17.g1dd88b9\n2013-10-10 06:07:42 Best match: python-neutronclient 2.3.1.17.g1dd88b9\n2013-10-10 06:07:42 python-neutronclient 2.3.1.17.g1dd88b9 is already the active version in easy-install.pth\n2013-10-10 06:07:42 Installing neutron script to /usr/local/bin\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /opt/stack/new/python-neutronclient\n2013-10-10 06:07:42 Searching for pbr==0.5.21\n2013-10-10 06:07:42 Best match: pbr 0.5.21\n2013-10-10 06:07:42 Processing pbr-0.5.21-py2.7.egg\n2013-10-10 06:07:42 Removing pbr 0.5.21 from easy-install.pth file\n2013-10-10 06:07:42 pbr 0.5.21 is already the active version in easy-install.pth\n2013-10-10 06:07:42 \n2013-10-10 06:07:42 Using /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg\n2013-10-10 06:07:42 Searching for Babel==1.3\n2013-10-10 06:07:42 Best match: Babel 1.3\n2013-10-10 06:07:42 Adding Babel 1.3 to easy-install.pth file\n2013-10-10 06:07:42 Installing pybabel script to /usr/local/bin\n2013-10-10 06:07:42 \nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-566561-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-566561.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-566561/37/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1647997095.111.1384236927727.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-12 06:15:27',0,'2013-11-12 06:15:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #43','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/43/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52e86d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52e86d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54372d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54372d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-71a10557-2a6a-45d8-8cbf-7d34d657f1ee\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:14:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:14:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:14:49+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'49\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:14:49-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'49\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2013-11-15T06:14:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'15\', \'minute\': u\'14\'} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x61c4090>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x26046d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 82.96 secs:\n    17.84    TestBinGlanceCacheManage.test_queue\n    16.62    TestGlanceControl.test_bouncing\n    16.61    TestBinGlance.test_results_filtering\n    16.02    TestRootApi.test_version_configurations\n    15.87    TestScrubber.test_delayed_delete\n----------------------------------------------------------------------\nRan 932 tests in 745.967s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-43\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.SnebaXFcy1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/43/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-2/43\n[SCP] Copying console log.\n\n\n','<1387920227.107.1384150354609.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1648292946.8.1375855350532.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-07 06:02:30',0,'2013-08-07 06:02:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/2/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az3-1273 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #1260 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson638128583713571329.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-cinder-stable-folsom] $ /bin/bash -xe /tmp/hudson5459774930318953943.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_CINDER=1\n+ DEVSTACK_GATE_CINDER=1\n+ export ZUUL_BRANCH=stable/folsom\n+ ZUUL_BRANCH=stable/folsom\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az3-1273\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az3-1273/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az3-1273/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/devstack-precise-hpcloud-az3-1273/2/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<145646731.0.1375768928931.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1649503645.191701.1399484353781.JavaMail.root@mail>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 13:39:13',-14400,'2014-05-07 17:39:13',NULL,'[openstack-dev] Monitoring as a Service','Hi everyone,\n\nIt is not possible for me to attend the summit and I would prefer if we waited until after the summit. My colleague Jonathan Le Lous, Cloud leader (OpenStack) at Savoir-Faire Linux, will be attending to the first three days of the summit. For those of you who are willing to talk, you may meet him there.\n\nI will be attending to Solutions Linux in Paris (May 20-21), you may contact me to arrange a meeting there.\n\nI will also most likely attend to the next summit in Paris (Nov 03 ? 08) where I plan to arrange discussions around the topic. \n\nIn the meantime, I will shortly contact everyone subscribed to the blueprint to plan an IRC meeting. I will be posting more information about the meeting on openstack-dev as soon as we have settled on a date and time.\n\nThanks,\nAlexandre Viau\n\n\n\n----- Original Message -----\nFrom: \"Paulo Oliveira\" <paulonascimento at av.it.pt>\nTo: openstack-dev at lists.openstack.org\nCc: \"alexandre viau\" <alexandre.viau at savoirfairelinux.com>\nSent: Wednesday, May 7, 2014 12:10:08 PM\nSubject: [openstack-dev] Monitoring as a Service\n\n\n\n\n\nHello everyone, \n\n\nMe and my team have been following this subject and similar ones related to Monitoring. IHMO, seems to be very logical to aggregate monitoring with Ceilometer. Others have been working on similar features, like ICC Lab: Nagios/Ceilometer Integration and SNMP Support \n\n\nThe best choice, is to enhance Ceilometer with monitoring features. \n\nAre you planning on talking about this on following IRC meetings? For further discussion. \n\nBest regards, \n\n\n\nPaulo J. Nascimento Oliveira \nhttp://about.me/pnascimento \n\nAdvanced Telecommunications and Networks Group - http://atnog.av.it.pt \nFollow us - @ATNoG_ITAv \n\n\n\n\n\n\n\n\nFrom: Eoghan Glynn < eglynn at redhat.com > \n\nSubject: Re: [openstack-dev] Monitoring as a Service \n\nDate: 7 May 2014 09:57:38 GMT+1 \n\nTo: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org > \n\nReply-To: \"OpenStack Development Mailing List \\(not for usage questions\\)\" < openstack-dev at lists.openstack.org > \n\n\n\nHi Alexandre, \n\nI wanted to let this discussion develop a little before jumping in, as \nwe\'ve already had many circular debates about the cross-over between \nceilometer and monitoring infrastructure in general. \n\nPersonally I\'m in favor of the \"big tent/broad church\" interpretation of \nceilometer\'s project mandate, and would welcome further development of \nour capabilities in this area (whether directly within the ceilometer \ncode-tree itself, or within a parallel repo aligned with the Telemetry \nprogram). \n\nIn terms of furthering the discussion, unfortunately you\'ve missed the \nboat in terms of securing a slot in the design summit next week in \nAtlanta (proposal deadline was April 20th, and the scheduling has all \nbeen finalized at this stage). \n\nHowever, we do have a project pod space available for ad-hoc overflow \nsessions. I would suggest that we organize something on this theme \nafter the main ceilometer track[1] has completed, say on the Thursday \nor Friday. Please reach out on IRC to discuss availability for this \nand we\'ll work out something around remote participation. \n\nThanks, \nEoghan \n\n[1] http://junodesignsummit.sched.org/overview/type/ceilometer \n\n----- Original Message ----- \n\n\nThanks to everyone for the feedback. I agree that this falls under the \nTelemetry Program and I have moved the blueprint. \n\nYou can find it here: \nhttps://blueprints.launchpad.net/ceilometer/+spec/monitoring-as-a-service \nWiki page: https://wiki.openstack.org/wiki/MaaS \nEtherpad: https://etherpad.openstack.org/p/MaaS \n\n\n\nI can go over the project with you as well as others that are interested. \nWe would like to start working with other open-source developers. I\'ll \nalso be at the Summit next week. \nRoland, \n\nI currently have no plans to be at the Summit next week. However, I \nwould be interested in exploring what you have already done and learn \nfrom it. Maybe we can schedule a meeting? You can always contact me on \nIRC (aviau) or by e-mail at alexandre.viau at savoirfairelinux.com \n\nFor now, I think we should focus on the use cases. I invite all of you \nto help us list them on the Etherpad. \n\nAlexandre \n\n\n\nOn 14-05-05 12:00 PM, Hochmuth, Roland M wrote: \n\n\nAlexandre, Great timing on this question and I agree with your proposal. I \nwork for HP and we are just about to open-source a project for Monitoring \nas a Service (MaaS), called \"Jahmon\". Jahmon is based on our \ncustomer-facing monitoring as a service solution and internal monitoring \nprojects. \n\n\nJahmon is a multi-tenant, highly performant, scalable, reliable and \nfault-tolerant monitoring solution that scales to service provider levels \nof metrics throughput. It has a RESTful API that is used for \nstoring/querying metrics, creating compound alarms, querying alarm \nstate/history, sending notifications and more. \n\nI can go over the project with you as well as others that are interested. \nWe would like to start working with other open-source developers. I\'ll \nalso be at the Summit next week. \n\nRegards --Roland \n\n\nOn 5/4/14, 1:37 PM, \"John Dickinson\" < me at not.mn > wrote: \n\n\n\nOne of the advantages of the program concept within OpenStack is that \nseparate code projects with complementary goals can be managed under the \nsame program without needing to be the same codebase. The most obvious \nexample across every program are the \"server\" and \"client\" projects under \nmost programs. \n\nThis may be something that can be used here, if it doesn\'t make sense to \nextend the ceilometer codebase itself. \n\n--John \n\n\n\n\n\nOn May 4, 2014, at 12:30 PM, Denis Makogon < dmakogon at mirantis.com > wrote: \n\n\n\nHello to All. \n\nI also +1 this idea. As I can see, Telemetry program (according to \nLaunchpad) covers the process of the infrastructure metrics (networking, \netc) and in-compute-instances metrics/monitoring. \nSo, the best option, I guess, is to propose add such great feature to \nCeilometer. In-compute-instance monitoring will be the great value-add \nto upstream Ceilometer. \nAs for me, it\'s a good chance to integrate well-known production ready \nmonitoring systems that have tons of specific plugins (like Nagios etc.) \n\nBest regards, \nDenis Makogon \n\n???????????, 4 ??? 2014 ?. ???????????? John Griffith ???????: \n\n\n\nOn Sun, May 4, 2014 at 9:37 AM, Thomas Goirand < zigo at debian.org > wrote: \nOn 05/02/2014 05:17 AM, Alexandre Viau wrote: \n\n\nHello Everyone! \n\nMy name is Alexandre Viau from Savoir-Faire Linux. \n\nWe have submited a Monitoring as a Service blueprint and need \nfeedback. \n\n\nProblem to solve: Ceilometer\'s purpose is to track and \n*measure/meter* usage information collected from OpenStack components \n(originally for billing). While Ceilometer is usefull for the cloud \noperators and infrastructure metering, it is not a *monitoring* solution \nfor the tenants and their services/applications running in the cloud \nbecause it does not allow for service/application-level monitoring and \nit ignores detailed and precise guest system metrics. \n\n\nProposed solution: We would like to add Monitoring as a Service to \nOpenstack \n\n\nJust like Rackspace\'s Cloud monitoring, the new monitoring service - \nlets call it OpenStackMonitor for now - would let users/tenants keep \ntrack of their ressources on the cloud and receive instant notifications \nwhen they require attention. \n\n\nThis RESTful API would enable users to create multiple monitors with \npredefined checks, such as PING, CPU usage, HTTPS and SMTP or custom \nchecks performed by a Monitoring Agent on the instance they want to \nmonitor. \n\n\nPredefined checks such as CPU and disk usage could be polled from \nCeilometer. Other predefined checks would be performed by the new \nmonitoring service itself. Checks such as PING could be flagged to be \nperformed from multiple sites. \n\n\nCustom checks would be performed by an optional Monitoring Agent. \nTheir results would be polled by the monitoring service and stored in \nCeilometer. \n\n\nIf you wish to collaborate, feel free to contact me at \nalexandre.viau at savoirfairelinux.com \n\n\nThe blueprint is available here: \nhttps://blueprints.launchpad.net/openstack-ci/+spec/monitoring-as-a-servi \nce \n\n\nThanks! \nI would prefer if monitoring capabilities was added to Ceilometer rather \nthan adding yet-another project to deal with. \n\nWhat\'s the reason for not adding the feature to Ceilometer directly? \n\nThomas \n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n?I\'d also be interested in the overlap between your proposal and \nCeilometer. It seems at first thought that it would be better to \nintroduce the monitoring functionality in to Ceilometer and make that \nproject more diverse as opposed to yet another project.? \n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n','<0E3BD191-FE39-4FF3-A86C-1C62FB3DD5D6@av.it.pt>',NULL),('<1649823333.2.1352419437377.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:03:57',0,'2012-11-09 00:03:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-diablo #87','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/87/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/>\nCheckout:periodic-horizon-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/> - hudson.remoting.Channel at 183b7230:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson4228235547391142286.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-diablo/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1650B171-EEBF-4ED3-8B74-817530222309@it.uu.se>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-12 13:12:12',7200,'2014-06-12 11:12:12',NULL,'[Openstack-operators] Havana Dashboard crashed. (Premature end\n	of script headers)','Hi, \n\nThanks for your answer Dan. \n\nJust to update about this issue, \n\nI have tried all possible options (up to my expertise) to find out the problem but no success and than I uninstall the openstack-dashboard rpm and reinstall it and everything started to work fine. Absolutely no change in configurations... Strange :-(\n\n\nRegards..\nSalman. \n\n\nSalman Toor, PhD\nsalman.toor at it.uu.se\n\n\n\nOn Jun 11, 2014, at 4:21 PM, Dan Radez wrote:\n\n> I usually turn on django debugging to troubleshoot the dashboard\'s 500\'s. It\'s commonly because a connection to neutron can\'t be made.\n> \n> edit /etc/openstack-dashboard/local_settings and set debug to True.\n> bounce apache again and do what you did before to get the 500. You\'ll get an error displayed in the browser.\n> \n> Don\'t forget to turn it back off when you\'re done.\n> \n> Dan\n> \n> \n> On 06/11/2014 06:26 AM, Salman Toor wrote:\n>> Hi,\n>> \n>> I am running Havana release from couple of months. Till yesterday everything was working fine but today all of a sudden dashboard crashed with the error message \"Internal Server Error\".\n>> \n>> Haven\'t changed anything and have know idea what went wrong.\n>> \n>> In the httpd/error_log file I have found following lines\n>> \n>> \n>> [Wed Jun 11 11:18:22 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)\n>> [Wed Jun 11 11:18:22 2014] [notice] Digest: generating secret for digest authentication ...\n>> [Wed Jun 11 11:18:22 2014] [notice] Digest: done\n>> [Wed Jun 11 11:18:22 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations\n>> [Wed Jun 11 11:18:30 2014] [error] [client 130.238.137.246] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 11:18:30 2014] [notice] child pid 2452 exit signal Segmentation fault (11)\n>> [Wed Jun 11 11:50:29 2014] [error] [client 130.238.137.246] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 11:50:30 2014] [notice] child pid 2487 exit signal Segmentation fault (11)\n>> [Wed Jun 11 11:57:13 2014] [error] [client 130.238.138.22] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 11:57:13 2014] [notice] child pid 3857 exit signal Segmentation fault (11)\n>> [Wed Jun 11 11:57:16 2014] [error] [client 130.238.138.22] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 11:57:16 2014] [notice] child pid 4159 exit signal Segmentation fault (11)\n>> [Wed Jun 11 12:11:20 2014] [error] [client 130.238.138.22] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 12:11:21 2014] [notice] child pid 4188 exit signal Segmentation fault (11)\n>> [Wed Jun 11 12:21:11 2014] [error] [client 130.238.137.246] Premature end of script headers: django.wsgi\n>> [Wed Jun 11 12:21:12 2014] [notice] child pid 4943 exit signal Segmentation fault (11)\n>> \n>> \n>> Can someone give me some hints? Its really strange from last couple of months everything was so stable. I have restarted the httpd and memcached service as well but no luck ...\n>> \n>> Regards..\n>> Salman.\n>> \n>> \n>> \n>> Salman Toor, PhD\n>> salman.toor at it.uu.se\n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-operators mailing list\n>> OpenStack-operators at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>> \n> \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140612/1eb27b14/attachment.html>\n\n','<539865F4.6050006@redhat.com>',NULL),('<1651400964.11.1375164141559.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-30 06:02:21',0,'2013-07-30 06:02:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #302','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/302/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/>\nCheckout:periodic-horizon-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/> - hudson.remoting.Channel at 6cfcb7d4:precise6\nUsing strategy: Default\nLast Built Revision: Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nChecking out Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\n[periodic-horizon-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson9006872290006272261.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/302/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-302\', \'SSH_CLIENT\': \'198.101.231.203 38573 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374971246.196776-1340970677\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-30_06-00-44\', \'BUILD_NUMBER\': \'302\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'2198f394-d21b-4f04-8341-64e189cdaeae\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#302\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 38573 50.56.249.238 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.20-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-J5Sbc3/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-J5Sbc3/d2to1-0.2.10/egg-dist-tmp-rFW4lY\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-4dX1vV/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-4dX1vV/setuptools-git-1.0/egg-dist-tmp-xOM_7o\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/pbr-0.5.20-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-LiQrR0/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-LiQrR0/d2to1-0.2.10/egg-dist-tmp-4drWrU\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-DlYg67/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-DlYg67/setuptools-git-1.0/egg-dist-tmp-1fLE9R\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/pbr-0.5.20-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-9hAPAb/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-9hAPAb/d2to1-0.2.10/egg-dist-tmp-Br0GxR\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-xvn9LG/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-xvn9LG/setuptools-git-1.0/egg-dist-tmp-9KYLBv\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/302\n[SCP] Copying console log.\n\n\n','<1521363575.5.1375077724892.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<165175099.3.1368857643600.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-18 06:14:03',0,'2013-05-18 06:14:03',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #229','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/229/>\n\n\n\n','<1329877082.0.1368771227928.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1652668103.153.1358230332759.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-15 06:12:12',0,'2013-01-15 06:12:12',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #106','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/106/>\n\n\n\n','<989552914.135.1358145272787.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1652698.gSKelWNFSa@os>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 18:04:30',3600,'2014-01-23 17:04:30',NULL,'[openstack-dev] [Hacking] unit test code is too less','On Thursday 23 January 2014 12:06:37 Dirk M?ller wrote:\n> Hi Zhi Qiang,\n> \n> > for i.e. the hacking rule h233 in hacking looks not so robust,\n> > https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L345\n> > it cannot detect\n> > \n> > \\bprint$\n> > \\bprint >>>xxx, (\\s+\n> \n> It currently detects both as a violation of the rule, which is IMHO\n> correct. Please note that the behavior of\n> \n>   print\n> \n> depends on if its an operator (then it prints a newline) and a\n> function (then it does nothing)\n\nWrong:\n\n	% python\n	Python 2.7.6 (default, Nov 21 2013, 15:55:38) [GCC] on linux2\n	>>> print\n	\n	>>> from __future__ import print_function\n	>>> print()\n	\n	>>> \n	% python3\n	Python 3.3.3 (default, Nov 19 2013, 16:19:14) [GCC] on linux\n	>>> print()\n	\n	>>> \n\nPython3 just broke \"Hello, world!\", but they tried to follow the principle of \nleast surprise :-)\n-- \nSascha Peilicke\nSUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany\nGF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg) \n\n\n','<CAL5wTH60WvBSShfDxi37vqNiUFhMBRxfeDTuRsJFU3odJdTJQQ@mail.gmail.com>',NULL),('<1653385435.23346774.1370972769396.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 13:46:09',-14400,'2013-06-11 17:46:09',NULL,'[openstack-qa] Why not to use with context ?','Just for the users it is not a big issue.\n\nProbably we will not need more than 4 users in a test case.\n\nI saw with context attempts for another resources in the past.\n\nYou will need to impersonate the same user multiple times.\n\n\n\n----- Original Message -----\n> From: \"Jay Pipes\" <jaypipes at gmail.com>\n> To: openstack-qa at lists.openstack.org\n> Sent: Tuesday, June 11, 2013 6:22:29 PM\n> Subject: Re: [openstack-qa] Why not to use with context ?\n> \n> On 06/11/2013 12:09 PM, Attila Fazekas wrote:\n> > The with context are very powerful element of the python, this\n> > should be used wisely. I like it.\n> >\n> > One my main concern against massive with context usage is python 2.6.\n> > I need to use tempest with python 2.6 nowadays.\n> >\n> > In complex test case you would need to have more than 10 with.\n> >          with ..\n> >              with ..\n> >                  with ..\n> >                      with ..\n> >                          with ..\n> >                              with ..\n> >                                  with ..\n> >                                      with ..\n> >                                          with ..\n> >                                              with ..\n> \n> Show me a real example of a test case that would have that many levels\n> of nesting. I presume you are talking about the PoC code I put together\n> that uses context managers to switch between users? If so, it\'s\n> *switching* between users, not nested user actions. Therefore you would\n> never have more than one level of nesting.\n> \n> So, even if you had three different user contexts active in a single\n> test case, you would still only see a single level of context manager:\n> \n> def test_some_interaction(self):\n>    with self.do_as(\'net_admin\') as client:\n>      self.assertSomething...\n>    with self.do_as(\'system_admin\') as client:\n>      self.assertSomething...\n>    with self.do_as(\'keystone_admin\') as client:\n>      self.assertSomething...\n> \n> Best,\n> -jay\n> \n> > http://docs.python.org/2/whatsnew/2.7.html#python-3-1-features\n> >\n> > The syntactical sugar what usable in python 2.6 is similar to the one\n> > used by testresources.\n> \n> \n> \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<51B74EC5.6070007@gmail.com>',NULL),('<1653451396.261.1368425909166.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-13 06:18:29',0,'2013-05-13 06:18:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly-centos6 #13','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/13/>\n\n------------------------------------------\n[...truncated 1157 lines...]\n    test_validate_with_additional_properties_allowed             OK    0.00\nTestStoreImage\n    test_image_delayed_delete                                    OK    0.00\n    test_image_delete                                            OK    0.00\n    test_image_get_data                                          OK    0.00\n    test_image_set_data                                          OK    0.00\n    test_image_set_data_unknown_size                             OK    0.00\nTestStoreImageRepo\n    test_add_fetches_members_if_private                          OK    0.00\n    test_add_ignores_acls_if_no_locations                        OK    0.00\n    test_add_updates_acls                                        OK    0.00\n    test_member_addition_updates_acls                            OK    0.00\n    test_member_removal_updates_acls                             OK    0.00\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nTestMonkeyPatch\n    test_time_is_monkey_patched                                  OK    0.00\n\n======================================================================\nFAIL: glance.tests.functional.v1.test_ssl.TestSSL.test_filtered_images\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/glance/tests/functional/v1/test_ssl.py\",> line 725, in test_filtered_images\n    self.assertEqual(response.status, 200)\nMismatchError: 500 != 200\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.04 secs:\n    26.31    TestScrubber.test_scrubber_app\n    20.70    TestScrubber.test_delayed_delete\n    14.86    TestGlanceControl.test_reload\n    14.66    TestRootApi.test_version_configurations\n    14.51    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1102 tests in 612.962s\n\nFAILED (SKIP=38, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.centos6.13\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.31\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=127\n+ \'[\' 127 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KvlZYFmLCU\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/13\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly-centos6/13/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1296172584.245.1368339402727.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1653600.8d165G5jGE@cacao>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 12:16:51',7200,'2014-06-10 10:16:51',NULL,'[openstack-dev] [Cinder] DRBD integration as volume driver','So, I now tried to push the proof-of-concept driver to Gerrit,\nand got this:\n\n> Downloading/unpacking dbus (from -r /home/jenkins/workspace/gate-\ncinder-pep8/requirements.txt (line 32))\n>   http://pypi.openstack.org/openstack/dbus/ uses an insecure transport \nscheme (http). Consider using https if pypi.openstack.org has it \navailable\n>   Could not find any downloads that satisfy the requirement dbus (from \n-r /home/jenkins/workspace/gate-cinder-pep8/requirements.txt (line 32))\n\n\nSo, how would I get additional modules (dbus and its dependencies) onto \npypi.openstack.org? I couldn\'t find a process for that.\n\n\nRegards,\n\nPhil\n\n\n\n','<2524943.b93qrTdfx5@cacao>',NULL),('<1653983907.17036316.1390954398867.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-01-28 19:13:18',-18000,'2014-01-29 00:13:18',NULL,'[Openstack-docs] Fwd: OpenStack Docs Hangout on Air 1/29 20:00 UTC','Dang it, was thinking that would be Brisbane\'s 30.Jan (automatically place us one day ahead when thinking about US meetings). \n\nMany, many apologies. Hope it was a good one, \nSummer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Tuesday, January 21, 2014 3:42:17 AM\n> Subject: [Openstack-docs] OpenStack Docs Hangout on Air 1/29 20:00 UTC\n\n> Hi all,\n> I\'ve set up the Hangout for 1/29 at 20:00 UTC.\n\n> https://plus.google.com/u/1/events/c647s0aa5v05e2t6fsaf8eu22q8\n\n> Please edit the discussion list at\n> https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Google_Hangout_for_Docs\n> if you have other items to chat about.\n\n> Thanks,\n> Anne\n\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140128/6933f5ac/attachment.html>\n\n','<CAD0KtVFDfNYOEE1Hn-R2kpvpFk-zZhJEdfZKcpVXdeGFgQbzgg@mail.gmail.com>',NULL),('<1654363.8zVPTkTYqq@bort.suse.de>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 13:14:51',3600,'2014-03-26 12:14:51',NULL,'[openstack-dev] [depfreeze][horizon] Exception for lesscpy>=0.10.1','Hi,\n\nthere\'s been a review up for some time [0] that wants to raise the version of \nlesscpy to 0.10.1. It\'s specific to horizon and contains some important fixes \nthat we\'ll likely want to include. So I\'d like to ask for an exception for \nthis one.\n\n[0] https://review.openstack.org/#/c/70619/\n-- \nViele Gr??e,\nSascha Peilicke\n\n\n','<532C75AA.3060908@openstack.org>',NULL),('<1655281586.46.1383373031030.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:17:11',0,'2013-11-02 06:17:11',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-nova-python26-stable-folsom #40','See <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-folsom/40/>\n\n\n\n',NULL,NULL),('<1655763098.23891302.1371010437071.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-12 00:13:57',-14400,'2013-06-12 04:13:57',NULL,'[openstack-qa] Simplified testcase class model','Long time ago I wanted to add single root class,\nwhich provides everything what is generally usable by all test\ntypes. (Not the things what easily could be used as a simple functions in another places) \n\nProbably we need only one additional base class per test types (~4).\n\nWe need to remove the small anomalies and move functionality to an upper level.\n(closer to the root class)\n\nhacking.py (inspection at syntax check) and loosing the setup_package combination was a blocker.\nBTW: I just don\'t like inspection aka. \'arbitrary code execution\' in a \'syntax checker\', otherwise I am using it.\nBTW: The miss of the teardown_package is an issue in a test suite scoped resource management.\n\nThe above combination was my real reason of trying to fix or remove the hacking.py\'s\n module import rule checker. (And trying to apply the module import rules by a ~2000 line change)\n\nWe definitely uses a more complex test class hierarchy than it is really necessary!\n\nWe have small anomalies, but AFAIK non of them a real blocker,\n which could prevent the 1-5 base class goal.\n\nThoughts ?\n\n\nPS.: The current flake8/hacking anomaly is a not wanted exception printing,\n at least it is does not a blocker for other changes (EXIT_SUCCESS).\n\n\n','<1654108025.23886926.1371008000449.JavaMail.root@redhat.com>',NULL),('<165597256.1977103.1399479451395.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-07 12:17:31',-14400,'2014-05-07 16:17:31',NULL,'[openstack-dev] [TripleO][Tuskar][Summit] Tuskar Session Etherpad','Hey all,\n\nHere\'s a link to the etherpad for the summit session on Tuskar:\n\nhttps://etherpad.openstack.org/p/juno-summit-tripleo-tuskar-planning\n\nPlease feel free to discuss or add suggestions or make changes!\n\nThanks,\nTzu-Mainn Chen\n\n\n','<1034885102.1976851.1399479404912.JavaMail.zimbra@redhat.com>',NULL),('<1655A95A-793D-4805-A860-870A05075337@rackspace.com>','http://lists.openstack.org/pipermail/community',NULL,'2013-07-31 16:32:46',0,'2013-07-31 16:32:46',NULL,'[openstack-community] [User-committee] summit talk proposal\n \"The role of the community managers in the OpenStack community\"','Hi Mark,\n\nRackspace would love to be part of this panel. If our community manager can\'t attend (because it\'s just that far away), I\'ll be able to step in. My community creds are that I\'ve been active in the community since Bexar, I\'ve deployed Cactus into production, I\'ve written numerous posts on OpenStack, I\'ve presented on OpenStack all over the place, and I co-authored the OpenStack Operations Guide.\n\nThanks,\nEverett\n\nOn Jul 30, 2013, at 3:12 PM, Atwood, Mark wrote:\n\nHi!\n\nI have submitted a presentation abstract for the upcoming summit in Hong Kong, titled \"The role of the community managers in the OpenStack community\".\n\nhttp://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/297\n\nOne of the interesting things about the OpenStack project is in addition the excellent work being done by Stephano working for the Foundation, many of the participating organizations have community managers, directors of engagement, and other such people in such roles also engaged with the project and with the community.\n\nI don?t want to be the only guy on stage.  In fact, if we can make it a panel discussion of all the community managers, that would be best, and would be a better and more useful presentation.\n\nWho else is interested in signing up as a co-presenter, and making this a panel?\n\n..m\n_______________________________________________\nUser-committee mailing list\nUser-committee at lists.openstack.org<mailto:User-committee at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/community/attachments/20130731/902fc41a/attachment.html>\n\n','<649F7F83B756284783FCCD0F43E2AC0E011A58C3@G2W2432.americas.hpqcorp.net>',NULL),('<1655A95A-793D-4805-A860-870A05075337@rackspace.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2013-07-31 16:32:46',0,'2013-07-31 16:32:46',NULL,'[User-committee] summit talk proposal \"The role of the\n community managers in the OpenStack community\"','Hi Mark,\n\nRackspace would love to be part of this panel. If our community manager can\'t attend (because it\'s just that far away), I\'ll be able to step in. My community creds are that I\'ve been active in the community since Bexar, I\'ve deployed Cactus into production, I\'ve written numerous posts on OpenStack, I\'ve presented on OpenStack all over the place, and I co-authored the OpenStack Operations Guide.\n\nThanks,\nEverett\n\nOn Jul 30, 2013, at 3:12 PM, Atwood, Mark wrote:\n\nHi!\n\nI have submitted a presentation abstract for the upcoming summit in Hong Kong, titled \"The role of the community managers in the OpenStack community\".\n\nhttp://www.openstack.org/summit/openstack-summit-hong-kong-2013/become-a-speaker/TalkDetails/297\n\nOne of the interesting things about the OpenStack project is in addition the excellent work being done by Stephano working for the Foundation, many of the participating organizations have community managers, directors of engagement, and other such people in such roles also engaged with the project and with the community.\n\nI don?t want to be the only guy on stage.  In fact, if we can make it a panel discussion of all the community managers, that would be best, and would be a better and more useful presentation.\n\nWho else is interested in signing up as a co-presenter, and making this a panel?\n\n..m\n_______________________________________________\nUser-committee mailing list\nUser-committee at lists.openstack.org<mailto:User-committee at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/user-committee/attachments/20130731/902fc41a/attachment.html>\n\n','<649F7F83B756284783FCCD0F43E2AC0E011A58C3@G2W2432.americas.hpqcorp.net>',NULL),('<1656188749.10.1374214585334.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-19 06:16:25',0,'2013-07-19 06:16:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #100','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/100/>\n\n------------------------------------------\n[...truncated 1170 lines...]\n    test_save_fetches_members_if_private                         OK    0.00\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.00\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.00\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_api.TestApi.test_mismatched_checksum\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1606, in test_mismatched_checksum\n    \'foobar\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 1582, in _do_test_mismatched_attribute\n    body=image_data)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 93.15 secs:\n    26.64    TestScrubber.test_scrubber_app\n    21.01    TestScrubber.test_delayed_delete\n    15.66    TestRootApi.test_version_configurations\n    14.98    TestGlanceControl.test_reload\n    14.85    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1101 tests in 644.464s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.8\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfixtures==0.3.12\nglance==jenkins.periodic.glance.python26.stable.grizzly.100\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.18\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.1\npython-mimeparse==0.1.4\npython-swiftclient==1.5.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.rGFar03VKv\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/100\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/100/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1657435604.96.1384409486258.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-14 06:11:26',0,'2013-11-14 06:11:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #46','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/46/changes>\n\n\n\n','<667159507.91.1384323120459.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1658264705.8570203.1403755206747.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-26 12:00:00',28800,'2014-06-26 04:00:00',NULL,'[Openstack] Why doesn\'t suspend release vCPUs/memory?','Oh, sorry, I misunderstood your idea,\nOk, then the last problem is how to release the vcpus/mem resources of suspended instances on the compute nodes?\n\n2014-06-26 11:57 (UTC+8)\nWangpan\n\n----- Original Message -----\n> From: Ricky Saltzer <ricky at cloudera.com>\n> To: \"Wangpan\"<hzwangpan at corp.netease.com>\n> Sent: 2014-06-25 03:58\n> Subject: Re: Re: [Openstack] Why doesn\'t suspend release vCPUs/memory?\nI don\'t see how there would be a problem if you still enforced a hard limit of the number of instances a user can have. The proposal here is suspending would release only vCPUs and memory, so the user could still potentially exceed their quota by reaching their allotted amount of instances. Let\'s say 5/10 instances for a user accumulated to 20 vCPUs (4 vCPUs per node), suspending those 5 instances would release the 20 vCPUs back, but those 5 suspended instances would still count towards their total number of instances quota.  \n\n\n\n\n\n\nOn Mon, Jun 23, 2014 at 11:24 PM, Wangpan <hzwangpan at corp.netease.com> wrote:\n\nI think if we do this, a serious security risk is imported, think this use case:\n1) an user has quotas like 10 instances, 20 vcpus, 100G ram and 200G disks\n2) he boots 10 instances under his quotas\n3) he suspends all this instances\n4) he repeats step 2&3 day and night\n5) then the cloud platform will have no resources to supply eventually\n\n2014-06-24 11:17 (UTC+8)\nWangpan\n\n----- Original Message -----\n> From: Ricky Saltzer <ricky at cloudera.com>\n> To: \"John Griffith\"<john.griffith at solidfire.com>\n> Sent: 2014-06-24 01:05\n> Subject: Re: [Openstack] Why doesn\'t suspend release vCPUs/memory?\nThat seems to be the case, and I can see where you\'re coming from, but if the resources aren\'t released at the quota level, then they\'re effectively being used from a user\'s point of view. It would be nice if suspend released resources after the instance is shutdown, and a resume would reclaim the resources (provided enough are available). For instance, if I had 210/210 vCPUs used, and I suspend instance_a with 1 vCPU, and then launch instance_b with 1 vCPU...instance_b should successfully deploy, but resuming instance_a should fail with a quota exceeded exception.\n\n\n\n\n\nOn Mon, Jun 23, 2014 at 12:54 PM, John Griffith <john.griffith at solidfire.com> wrote:\n\n\n\n\n\n\nOn Mon, Jun 23, 2014 at 10:49 AM, Ricky Saltzer <ricky at cloudera.com> wrote:\n\nRight, the quotas don\'t seem to be released. If I have 210/210 vCPUs used, and I suspend an instance with 4 vCPUs, I still have 210/210 vCPUs used. \n\n\n\n\nOn Mon, Jun 23, 2014 at 11:38 AM, John Griffith <john.griffith at solidfire.com> wrote:\n\n\n\nOn Mon, Jun 23, 2014 at 7:45 AM, Ricky Saltzer <ricky at cloudera.com> wrote:\n\nhttps://ask.openstack.org/en/question/32826/why-doesnt-suspend-release-vcpusmemory/\n\n\n?My understanding was always that the instance is no longer consuming any resources via the virt layer, so in essence the resources are in fact freed up on the Compute Node.  Quotas and such however aren\'t modified (which seems correct to me).  Are you saying you want to see quota\'s adjusted here? ?\n\n\n\n\n\n\n-- \n\nRicky Saltzer\nhttp://www.cloudera.com\n\n\n\n?Yeah, I think that makes sense and is expected, as a user you\'re still consuming those \"items\" even if they\'re not active.  The alternative would be (which I think is what you\'re getting at) to actually deduct items that are suspended from the tenants quota count.  I guess when I think of it though those resources are still \"reserved\" even if they\'re not in use.  I suppose you could do this and then if on resume the quota isn\'t there we don\'t actually resume... but I think this could be argued either way.\n\n\nMaybe seperate quotas for active vs suspended?  ?\n\n\n\n\n\n-- \n\nRicky Saltzer\nhttp://www.cloudera.com\n\n\n\n\n\n\n\n-- \n\nRicky Saltzer\nhttp://www.cloudera.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140626/36c2d1a6/attachment.html>\n\n','<CAEcou0Sp_sWTBx82mTDN9ioKnBA9Z+ZdHLE_URVVSkVCmWn9hw@mail.gmail.com>',NULL),('<1658506120.282.1368598446727.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-15 06:14:06',0,'2013-05-15 06:14:06',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #226','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/226/>\n\n------------------------------------------\n[...truncated 941 lines...]\n    test_policy_file_default_not_found                           OK    0.01\n    test_policy_file_specified_but_not_found                     OK    0.01\nTestStore\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.02\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.02\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.19\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Ensure an interrupt signal does not cause a respawn storm.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_multiprocessing.py\",> line 71, in test_interrupt_avoids_respawn_storm\n    self.assertTrue(child in children)\nAssertionError: \n    \"\"\"Fail the test unless the expression is true.\"\"\"\n>>  if not False: raise self.failureException, None\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 71.11 secs:\n    14.84    TestScrubber.test_delayed_delete\n    14.63    TestGlanceControl.test_bouncing\n    14.12    TestGlanceControl.test_reload\n    13.92    TestGlanceControl.test_respawn\n    13.60    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 573.828s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-226\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.YSXHL8o0FO\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/226\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/226/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<534097080.276.1368512351632.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<16586BB1-C172-4377-A911-F441B82D22F4@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-23 01:13:07',0,'2013-08-23 01:13:07',NULL,'[openstack-dev] [Glance] import task meeting 15:00 UTC\n	Monday	26 August','Maybe lets try tuesday?\n\nSent from my really tiny device...\n\nOn Aug 22, 2013, at 3:38 PM, \"Mark Washenberger\" <mark.washenberger at markwash.net<mailto:mark.washenberger at markwash.net>> wrote:\n\nEek, I might not actually be able to make this time on Monday. I\'m free from 9:30 Pacific Monday and on. Would Tuesday work? Or tomorrow?\n\n\nOn Thu, Aug 22, 2013 at 2:33 PM, Brian Rosmaita <brian.rosmaita at rackspace.com<mailto:brian.rosmaita at rackspace.com>> wrote:\nWe\'re shooting for 15:00 UTC Monday 26 August.  (Let me know ASAP if you really want to be in on this and can\'t make it, but this is probably the best time available.)\n\nTopics:\n(1) taskflow seam for integration\n(2) tasks api and executor interface\n(3) indexable column in db for tasks to be queryable\n\nSee http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-08-22-20.02.log.html for brief discussion of these topics during today\'s glance meeting.\n\nMore info:\nhttps://etherpad.openstack.org/havana-glance-requirements\nhttps://etherpad.openstack.org/LG39UnQA7z\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130823/0ead3559/attachment.html>\n\n','<CAJyP2C98HRLOcUya0rmFh=Cwe2bWsqjVu1Sq_GNOcFHKNegy_A@mail.gmail.com>',NULL),('<165907661.23761052.1375806338429.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-06 09:25:38',-25200,'2013-08-06 16:25:38',NULL,'[openstack-dev] [Nova] Blueprint approval','Thanks Russell!\n\n# Shawn Hartsock\n\n----- Original Message -----\n> From: \"Russell Bryant\" <rbryant at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Tuesday, August 6, 2013 11:30:19 AM\n> Subject: Re: [openstack-dev] [Nova] Blueprint approval\n> \n> On 08/06/2013 02:25 AM, Gary Kotton wrote:\n> > Hi,\n> > \n> > Would it be possible to get approval for the following blueprint -\n> > https://blueprints.launchpad.net/openstack/?searchtext=vmware-nova-cinder-support\n> > \n> > A WIP review has been posted. Today I am going to add in the unit tests\n> > so hopefully this will be ready for review by the end of the day.\n> \n> Done.\n> \n> --\n> Russell Bryant\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5201168B.4040002@redhat.com>',NULL),('<1659891303.3.1376893624248.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-19 06:27:04',0,'2013-08-19 06:27:04',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #10','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/10/>\n\n\n\n','<174416377.1.1376719968960.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<165BE1DA-D1E8-4981-8DD5-AF967D24B2CF@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 14:44:43',-28800,'2014-01-23 22:44:43',NULL,'[openstack-dev] [oslo] memoizer aka cache','Ok, I see. Thanks, good to know.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\nOn 23 Jan 2014, at 14:33, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n\n> The fact that it is already in the requirements list makes it a top contender in my mind, unless we find some major issue with it.\n> \n> Doug\n> \n> \n> On Thu, Jan 23, 2014 at 4:56 PM, Morgan Fainberg <m at metacloud.com> wrote:\n> Keystone uses dogpile.cache and I am making an effort to add it into the oslo incubator cache library that was recently merged.\n> \n> Cheers,\n> --Morgan\n> \n> \n> On Thu, Jan 23, 2014 at 1:35 PM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> \n> On 23 Jan 2014, at 08:41, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n> \n> > So to me memoizing is typically a premature optimization in a lot of cases. And doing it incorrectly leads to overfilling the python processes memory (your global dict will have objects in it that can\'t be garbage collected, and with enough keys+values being stored will act just like a memory leak; basically it acts as a new GC root object in a way) or more cache invalidation races/inconsistencies than just recomputing the initial value?\n> \n> I agree with your concerns here. At the same time, I think this thinking shouldn?t cancel cases of conscious usage of caching technics. A decent cache implementation would help to solve lots of performance problems (which eventually becomes a concern for any project).\n> \n> > Overall though there are a few caching libraries I\'ve seen being used, any of which could be used for memoization.\n> >\n> > - https://github.com/openstack/oslo-incubator/tree/master/openstack/common/cache\n> > - https://github.com/openstack/oslo-incubator/blob/master/openstack/common/memorycache.py\n> \n> I looked at the code. I have lots of question to the implementation (like cache eviction policies, whether or not it works well with green threads, but I think it?s a subject for a separate discussion though). Could you please share your experience of using it? Were there specific problems that you could point to? May be they are already described somewhere?\n> \n> > - dogpile cache @ https://pypi.python.org/pypi/dogpile.cache\n> \n> This one looks really interesting in terms of claimed feature set. It seems to be compatible with Python 2.7, not sure about 2.6. As above, it would be cool you told about your experience with it.\n> \n> \n> > I am personally weary of using them for memoization, what expensive method calls do u see the complexity of this being useful? I didn\'t think that many method calls being done in openstack warranted the complexity added by doing this (premature optimization is the root of all evil...). Do u have data showing where it would be applicable/beneficial?\n> \n> I believe there?s a great deal of use cases like caching db objects or more generally caching any heavy objects involving interprocess communication. For instance, API clients may be caching objects that are known to be immutable on the server side.\n> \n> \n> >\n> > Sent from my really tiny device...\n> >\n> >> On Jan 23, 2014, at 8:19 AM, \"Shawn Hartsock\" <hartsock at acm.org> wrote:\n> >>\n> >> I would like to have us adopt a memoizing caching library of some kind\n> >> for use with OpenStack projects. I have no strong preference at this\n> >> time and I would like suggestions on what to use.\n> >>\n> >> I have seen a number of patches where people have begun to implement\n> >> their own caches in dictionaries. This typically confuses the code and\n> >> mixes issues of correctness and performance in code.\n> >>\n> >> Here\'s an example:\n> >>\n> >> We start with:\n> >>\n> >> def my_thing_method(some_args):\n> >>   # do expensive work\n> >>   return value\n> >>\n> >> ... but a performance problem is detected... maybe the method is\n> >> called 15 times in 10 seconds but then not again for 5 minutes and the\n> >> return value can only logically change every minute or two... so we\n> >> end up with ...\n> >>\n> >> _GLOBAL_THING_CACHE = {}\n> >>\n> >> def my_thing_method(some_args):\n> >>   key = key_from(some_args)\n> >>    if key in _GLOBAL_THING_CACHE:\n> >>        return _GLOBAL_THING_CACHE[key]\n> >>    else:\n> >>         # do expensive work\n> >>         _GLOBAL_THING_CACHE[key] = value\n> >>         return value\n> >>\n> >> ... which is all well and good... but now as a maintenance programmer\n> >> I need to comprehend the cache mechanism, when cached values are\n> >> invalidated, and if I need to debug the \"do expensive work\" part I\n> >> need to tease out some test that prevents the cache from being hit.\n> >> Plus I\'ve introduced a new global variable. We love globals right?\n> >>\n> >> I would like us to be able to say:\n> >>\n> >> @memoize(seconds=10)\n> >> def my_thing_method(some_args):\n> >>   # do expensive work\n> >>   return value\n> >>\n> >> ... where we\'re clearly addressing the performance issue by\n> >> introducing a cache and limiting it\'s possible impact to 10 seconds\n> >> which allows for the idea that \"do expensive work\" has network calls\n> >> to systems that may change state outside of this Python process.\n> >>\n> >> I\'d like to see this done because I would like to have a place to\n> >> point developers to during reviews... to say: use \"common/memoizer\" or\n> >> use \"Bob\'s awesome memoizer\" because Bob has worked out all the cache\n> >> problems already and you can just use it instead of worrying about\n> >> introducing new bugs by building your own cache.\n> >>\n> >> Does this make sense? I\'d love to contribute something... but I wanted\n> >> to understand why this state of affairs has persisted for a number of\n> >> years... is there something I\'m missing?\n> >>\n> >> --\n> >> # Shawn.Hartsock - twitter: @hartsock - plus.google.com/+ShawnHartsock\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140123/961b11b7/attachment.html>\n\n','<CADb+p3TdoQffwhJiCKGbE5AzNuEeAWpqCpUQSm0HNC0bn42R6g@mail.gmail.com>',NULL),('<16608933.39043447.1351190675696.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-25 14:44:35',-14400,'2012-10-25 18:44:35',NULL,'[openstack-dev] [Synaps] a more forgiving interpretation of\n	INSUFFICIENT_DATA?','\nThanks for the response June Yi,\n\n> I could be wrong, but I guess that AWS CW might evaluate in batch\n> processing so that it could introduce unexpected leeway.\n\nWell one can do a bit of experimentation with some CW alarms\nbased on custom metrics, and see that state transitions to ALARM\nare generally quite timely (e.g. occur within at most a minute\nafter pushing the last datapoint required to make the threshold\ncondition true). \n\nSimilarly, transitions to OK can be seen to occur soon after the\nfirst datapoint that would make the threshold condition false.\n\nWhereas transitions into INSUFFICIENT_DATA are only seen after a\nsignificant lag, longer than [eval periods * period length] mins\nwithout any datapoints what-so-ever.\n\nThe opposite is true for transitions out of INSUFFICIENT_DATA,\nwhich can be observed to occur eagerly, on the first datapoint\nencountered after a gap.\n\nThese observations don\'t suggest the lag is induced by batching up\nevaluations, as it would be symmetric for different state transitions\nin that case. Rather it seems more like deliberate sensitivity\ntuning to avoid flapping and to minimize the length of time any\nmonitor spends in the unknown state.\n \n> I prefer strict interpretation of INSUFFICIENT_DATA so that we can\n> predict behavior of the system. For large production deployments,\n> they should use long enough period of alarm.\n\nI guess the thing to remember is that this is a user-facing API,\nso in a production deployment we must expect and tolerate a mix\nof different alarming strategies ... i.e. the cloud provider can\'t\ndictate that users prefer monitors with long periods over short\n(and/or many evaluation periods over few).\n\nIf Synaps is on a hair-trigger with regard to INSUFFICIENT_DATA\ntransitions, it will add to its own notification workload when\nshort term metric-stream delays occur (possibly making it harder\nto recover from the original problem).\n\nAlso the behavior can still be predictable, as long as the leeway\nis clearly quantified.\n\n> And, I agree that current Synaps concept of evaluation period is\n> useful but making confusion. So I\'ll start to make it align with AWS\n> CW\'s concept. And switching to out-of-stream evaluation can make\n> Synaps evaluate lesser and will be helpful to reduce flapping.\n\nWould you be interested in making those changes collaboratively?\n\nIt would be a good learning experience for me, and also perhaps a\nuseful exercise in community engagement for you guys.\n\nJust a thought, let me know.\n\nCheers,\nEoghan\n\n\n','<21710901.140651351170715572.JavaMail.weblogic@epml04>',NULL),('<1661766797.11070838.1361966242785.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-27 06:57:22',-18000,'2013-02-27 11:57:22',NULL,'[openstack-qa] automatically skipping tests based on config','Hi,\n\nI agree we must stop skipping tests based on weather conditions or something like that.\n(But, We can keep and/or extend the early failure logic.)\n\nThe other option would be using attributes or coding patterns to the testcase\'s name.\n(nosetests -x ec2 # skips the ec2 tests for example)\nWe could skip tests based on path as well.\n\nAny not skip exception in setUpClass is considered as an ERROR or FAIL (if the class has non zero test_ method).\n\nWe should do the skipping based on service endpoint expected to work or not, if we doing it on a configuration level.\n\nFor example if in a test run we do not expect a working glance,\n it leads to we cannot boot servers and cannot test ssh connection with newtwork tests,\n but we can create a keypair if the corresponding nova service is up.\n \nBest Regards,\nAttila\n\n\n$ cat tests.py\nimport testtools as unittest\nclass test(unittest.TestCase):\n    @classmethod\n    def setUpClass(cls):\n        raise Exception\n    def test_foo():\n        pass\n\n$ nosetests tests.py || echo Gate test FAILED\nE\n======================================================================\nERROR: test suite for <class \'tests.test\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib64/python2.7/site-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib64/python2.7/site-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib64/python2.7/site-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib64/python2.7/site-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/tmp/tests.py\", line 5, in setUpClass\n    raise Exception\nException\n\n----------------------------------------------------------------------\nRan 0 tests in 0.001s\n\nFAILED (errors=1)\nGate test FAILED\n\n\n\n----- Original Message -----\nFrom: \"Christopher Yeoh\" <cyeoh at au1.ibm.com>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Wednesday, February 27, 2013 12:18:37 PM\nSubject: [openstack-qa] automatically skipping tests based on config\n\nHi,\n\nFor a few days now the tempest gating has been fairly quietly skipping\nsome EC2 tests. This has happened because of a change in devstack which\nchanged the version of the cirros image used. As a result ami/aki/ari\nfiles defined in the generated tempest.conf did not match and the\nsetupClass for the tests noticed the missing files and automatically\nskipped the tests as they could not run successfully. There\'s output in\nthe log files, but hey no one looks at the logs when the tests pass :-)\n\nNow I\'m all for an easy to configure and setup test suite so I\nunderstand why it works this way but I\'m wondering now that if we can\nso easily get into the state of accidentally disabling tests that its\nin fact not such a good feature to have.\n\nI\'m wondering instead if we should have some fields in the tempest\nconfiguration file to allow people to skip tests - eg they have to\nexplicitly say that they do not want them to run. If the skip setting\nfor a specific test (or class of tests) is not set then we should fail\nthe test instead, perhaps with a warning message saying that it can be\nset to skip the tempest config file. That way we won\'t ever get into the\nsituation of ever accidentally disabling tests.\n\nI don\'t think we can fail a test or class of tests in setUpClass -\nraising an exception at that point just results in both nose or testr\ntreating them as skips. Does anyone know of a way to do this?\n\nOtherwise we\'d have to implement it using a setUp or maybe a decorator\non each of the tests (a bit of a pain but not that intrusive). \n\nAny suggestions/comments?\n\nRegards,\n\nChris\n-- \nyeohc at au1.ibm.com\n\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<20130227214837.513f6923@rockhopper>',NULL),('<1662795890.7572754.1393229008258.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-24 03:03:28',-18000,'2014-02-24 08:03:28',NULL,'[openstack-dev] [neutron]Can somebody describe the all the\n rolls about networks\' admin_state_up','\n\n----- Original Message -----\n> Hi,\n> \n>     I want to know the admin_state_up attribute about networks but I\n> have not found any describes.\n> \n> Can you help me to understand it? Thank you very much.\n> \n\nThere\'s a discussion about this in this bug [1].\n>From what I gather, nobody knows what admin_state_up is actually supposed\nto do with respect to networks.\n\n[1] https://bugs.launchpad.net/neutron/+bug/1237807\n\n> \n> Regard,\n> \n> Lee Li\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAGYb91=OiBc1ahzYdp=2DXiW_6iHumRu5KRKnxG=J5eMqUqYEg@mail.gmail.com>',NULL),('<1663052817.1364613.1376845324143.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-18 19:02:04',7200,'2013-08-18 17:02:04',NULL,'[openstack-dev] [keystone] Help consuming trusts','Hi Steve,\n\nIt might be a bit late for this, but here\'s a script I wrote when experimenting with trusts: https://github.com/mhuin/keystone_trust/blob/master/tests/swift_example.sh\n\nI hope it\'ll help you.\n\nMatthieu Huin \n\nmhu at enovance.com\n\n----- Mail original -----\n| De: \"Steven Hardy\" <shardy at redhat.com>\n| ?: openstack-dev at lists.openstack.org\n| Envoy?: Vendredi 16 Ao?t 2013 17:35:36\n| Objet: [openstack-dev] [keystone] Help consuming trusts\n| \n| Hi,\n| \n| I\'m looking for help, ideally some code or curl examples, figuring out why\n| I can\'t consume trusts in the manner specified in the documentation:\n| \n| https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3-os-trust-ext.md\n| \n| I\'ve been working on getting Heat integrated with the trusts functionality,\n| and the first step was to add keystoneclient support:\n| \n| https://review.openstack.org/#/c/39899/\n| \n| All works fine in terms of the actual operations on the OS-TRUST path, I\n| can create, list, get, delete trusts with no issues.\n| \n| However I\'m strugging to actually *use* the trust, i.e obtain a\n| trust-scoped token using the trust ID, I always seem to get the opaque\n| \"Authorization failed. The request you have made requires authentication.\"\n| message, despite the requests on authentication looking as per the API docs.\n| \n| Are there any curl examples or test code I can refer to?\n| \n| Thanks,\n| \n| Steve\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n\n\n','<20130816153535.GA3340@t430slt.redhat.com>',NULL),('<1663494037.20495761.1384192811255.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-11 13:00:11',-18000,'2013-11-11 18:00:11',NULL,'[Openstack] One Time Keystone Use Tokens?','I think we need to look into using a trust for this instead of a Token hand-off.  The need for one user or limited use trusts has come up multiple times.  That coupled with a very short lived token (5 minutes) is probably a better solution.\n\n----- Original Message -----\nFrom: \"Adam Young\" <ayoung at redhat.com>\nTo: openstack at lists.openstack.org\nSent: Friday, October 25, 2013 9:06:29 PM\nSubject: Re: [Openstack] One Time Keystone Use Tokens?\n\nOn 10/25/2013 04:03 PM, Ali, Haneef wrote: \n\n\n\n\n\nI don?t think it is possible. Can?t you revoke the token after VM boot? \nYes, but I would not recommend doing that. You would have to modify every place that used tokens. Youncould make the token timeout very short, but it will break on any long running tasks. \n\n\n\n\n\n\n\n\n\n\nThanks \n\nHaneef \n\n\n\n\nFrom: Brian Chong [ mailto:Brian_Chong at symantec.com ] \nSent: Friday, October 25, 2013 8:19 AM \nTo: openstack at lists.openstack.org \nSubject: [Openstack] One Time Keystone Use Tokens? \n\n\n\n\n\nHi, \n\n\n\n\n\nI\'m trying to figure out if its possible to configure KeyStone tokens to be one time use. My use case is that when a user requests that they want to take a action on the platform (i.e.: boot a VM) they aren\'t also using that same token to load a image in Glance or delete another VM, etc. \n\n\n\n\n\nHow would I do that or is that even possible? \n\n\n\n\n\nThanks a lot! \n\n\n-Brian \n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to     : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<526B1595.5000200@redhat.com>',NULL),('<1663561973.2792394.1367333624792.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-30 10:53:44',-14400,'2013-04-30 14:53:44',NULL,'[openstack-dev] SmokeStack: where is Xen?','A quick update on some recent SmokeStack changes:\n\nYesterday I deployed some new changes to support using/testing the new stackforge/puppet-* modules. This is good news in that SmokeStack will both use and provide test covereage for these modules (with upstream packages). It is now commenting on Gerrit reviews for stackforge/puppet-* modules.\n\nThere were a couple casualties in making this change... one of which was XenServer. PostgreSQL is also gone for now as are a couple other odd configurations I had in the old mix (I had like 8 or something). Anyway, until I get time, or someone else jumps in and helps rebuild these I essentially cut over to a single configuration for now. As time permits I\'d like to gradually expand this coverage again.\n\nAlso, if anyone is interested in helping out with this sort of thing then let me know here or on IRC (dprince).\n\nDan\n\n\n','<924033680.2790007.1367333226110.JavaMail.root@redhat.com>',NULL),('<1663592732.71.1361945522226.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-27 06:12:01',0,'2013-02-27 06:12:01',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #50','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/50/>\n\n------------------------------------------\n[...truncated 16098 lines...]\n++ field=\'$3\'\n++ echo \'| private network             | 10.1.0.2                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.2\n+ die_if_not_set IP \'Failure retrieving IP address\'\n+ local exitcode=0\n+ set +o xtrace\n+ ping_check private 10.1.0.2 90\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net =~ q- ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.2 90\n+ local from_net=private\n+ local ip=10.1.0.2\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=5.30 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 5.301/5.301/5.301/0.000 ms\n++ cinder list\n++ grep ex-vol-bc70ac21\n++ head -1\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1361945468\n+ cinder create --display_name ex-vol-bc70ac21 --display_description \'test volume: ex-vol-bc70ac21\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                false                 |\n|      created_at     |      2013-02-27T06:11:08.924397      |\n| display_description |     test volume: ex-vol-bc70ac21     |\n|     display_name    |           ex-vol-bc70ac21            |\n|          id         | 309cac10-39e6-4fc4-a42b-358f5a0db66e |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-bc70ac21 | grep available; do sleep 1; done\'\n| 309cac10-39e6-4fc4-a42b-358f5a0db66e | available | ex-vol-bc70ac21 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361945470\n+ echo \'Completed cinder create in 2 seconds\'\nCompleted cinder create in 2 seconds\n++ cinder list\n++ grep ex-vol-bc70ac21\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 309cac10-39e6-4fc4-a42b-358f5a0db66e | available | ex-vol-bc70ac21 |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=309cac10-39e6-4fc4-a42b-358f5a0db66e\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for ex-vol-bc70ac21\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1361945471\n+ nova volume-attach 7f3dd749-5386-4180-b72b-87d600e82d01 309cac10-39e6-4fc4-a42b-358f5a0db66e /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 7f3dd749-5386-4180-b72b-87d600e82d01 |\n| id       | 309cac10-39e6-4fc4-a42b-358f5a0db66e |\n| volumeId | 309cac10-39e6-4fc4-a42b-358f5a0db66e |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-bc70ac21 | grep in-use; do sleep 1; done\'\n| 309cac10-39e6-4fc4-a42b-358f5a0db66e | in-use | ex-vol-bc70ac21 |  1   |     None    |  false   | 7f3dd749-5386-4180-b72b-87d600e82d01 |\n++ date +%s\n+ end_time=1361945475\n+ echo \'Completed volume-attach in 4 seconds\'\nCompleted volume-attach in 4 seconds\n++ cinder list\n++ grep ex-vol-bc70ac21\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 309cac10-39e6-4fc4-a42b-358f5a0db66e | in-use | ex-vol-bc70ac21 |  1   |     None    |  false   | 7f3dd749-5386-4180-b72b-87d600e82d01 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=7f3dd749-5386-4180-b72b-87d600e82d01\n+ die_if_not_set VOL_ATTACH \'Failure retrieving ex-vol-bc70ac21 status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 7f3dd749-5386-4180-b72b-87d600e82d01 != 7f3dd749-5386-4180-b72b-87d600e82d01 ]]\n++ date +%s\n+ start_time=1361945476\n+ nova volume-detach 7f3dd749-5386-4180-b72b-87d600e82d01 309cac10-39e6-4fc4-a42b-358f5a0db66e\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-bc70ac21 | grep available; do sleep 1; done\'\n| 309cac10-39e6-4fc4-a42b-358f5a0db66e | available | ex-vol-bc70ac21 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361945480\n+ echo \'Completed volume-detach in 4 seconds\'\nCompleted volume-detach in 4 seconds\n++ date +%s\n+ start_time=1361945480\n+ cinder delete 309cac10-39e6-4fc4-a42b-358f5a0db66e\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-bc70ac21; do sleep 1; done\'\n| 309cac10-39e6-4fc4-a42b-358f5a0db66e | deleting | ex-vol-bc70ac21 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361945483\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 7f3dd749-5386-4180-b72b-87d600e82d01\n+ timeout 60 sh -c \'while nova list | grep -q 7f3dd749-5386-4180-b72b-87d600e82d01; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nStarting coverage data collection\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 194, in <module>\n    main(sys.argv)\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 148, in main\n    coverage_client.start_coverage_combine()\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 52, in start_coverage_combine\n    return self.post(\'os-coverage/action\', post_body, self.headers)\n  File \"tempest/common/rest_client.py\", line 178, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 280, in request\n    wait)\n  File \"tempest/common/rest_client.py\", line 357, in _error_checker\n    raise exceptions.ComputeFault(message)\ntempest.exceptions.ComputeFault: Got compute fault\nDetails: The server has either erred or is incapable of performing the requested operation.\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/rabbitmq/rabbit at devstack-1361943126-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/rabbitmq/rabbit at devstack-1361943126.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-swift.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/50/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1728428210.56.1361859144472.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1663745581.237.1366437944284.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-20 06:05:44',0,'2013-04-20 06:05:44',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #10','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/10/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-20 06:05:40    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-20 06:05:40,063 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-20 06:05:40,063 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-20 06:05:40,064 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,065 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,066 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-20 06:05:40,066 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-20 06:05:40,067 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-20 06:05:40  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-20 06:05:40,068 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-20 06:05:40    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-20 06:05:40,069 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,073 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.073338\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.073338\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40,074 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,075 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,076 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,077 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40,079 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.077715\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.077715\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40,080 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,081 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,082 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-20 06:05:40,083 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,084 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,085 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40,086 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.085596\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.085596\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40,087 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,088 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,089 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-20 06:05:40,090 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,091 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,092 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40,094 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.092535\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.092535\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40,095 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,096 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,097 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-20 06:05:40,098 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,098 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,100 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-20 06:05:40,101 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-20 06:05:40,102 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.101302\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-20T06:05:40.101302\', resource_metadata={}) from 0 transformer\n2013-04-20 06:05:40,103 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,104 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40,105 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-20 06:05:40,106 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-20 06:05:40,106 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-20 06:05:40    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.056s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.10\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a48.g60431d8\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a330.gb177151\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.6EXjV9Cs72\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/10\n[SCP] Copying console log.\n\n\n','<1630482965.219.1366351541889.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1663849162.7.1382681561225.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-25 06:12:41',0,'2013-10-25 06:12:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #49','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/49/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5630650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5630650>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x535aad0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x535aad0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-dc56da01-a774-47c8-8ef8-bfce45249d6f\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x32297d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x32297d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x32297d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x32297d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:12:04Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'04\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:12:04Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'04\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:12:04+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'04\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-27T06:12:04-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'04\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'27\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'27\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2013-10-28T06:12:04Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'04\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'28\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x63a19d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1dce2d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 87.85 secs:\n    25.67    TestScrubber.test_scrubber_app\n    20.13    TestScrubber.test_delayed_delete\n    14.49    TestGlanceControl.test_reload\n    14.18    TestGlanceControl.test_respawn\n    13.38    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 584.807s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.49\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.XZKUOFJFBS\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/49/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise7/49\n[SCP] Copying console log.\n\n\n','<909226585.1.1382508773122.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1664202722.20.1372140814232.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-25 06:13:34',0,'2013-06-25 06:13:34',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #267','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/267/>\n\n\n\n','<715325395.18.1372054426663.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1664582651.378.1367042724065.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:05:24',0,'2013-04-27 06:05:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/>\nCheckout:periodic-horizon-docs-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/> - hudson.remoting.Channel at 564389b7:quantal6\nUsing strategy: Default\nLast Built Revision: Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\nChecking out Revision 525fab26148158055a6534be8e390b7f3f89dab0 (origin/stable/folsom)\n[periodic-horizon-docs-stable-folsom] $ /bin/bash -xe /tmp/hudson844232443620261377.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 55086 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-03-23\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'9f61bbdf-ff12-4ef8-b0d6-873f63d73748\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 55086 166.78.136.121 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\nNo distributions at all found for Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1664994557.48.1386087054285.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-12-03 16:10:53',0,'2013-12-03 16:10:53',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-dsvm-coverage-master #3','See <https://jenkins01.openstack.org/job/periodic-tempest-dsvm-coverage-master/3/>\n\n------------------------------------------\n[...truncated 22766 lines...]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\nsetUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\nsetUpClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest) ... skipped u\'EC2 InstanceRunTest: requires ami/aki/ari manifest\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_get_console_output[gate]                      217.696\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  165.836\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]           94.618\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  77.168\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_create_backup[gate]                           38.236\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         32.423\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_create_backup[gate]                            28.261\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             25.918\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         25.457\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      24.800\n\n----------------------------------------------------------------------\nRan 1823 tests in 1629.694s\n\nOK (skipped=106)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-779154-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-779154.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-dsvm-coverage-master/devstack-precise-hpcloud-az2-779154/3/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<389682477.47.1386086998801.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1664A804-E74B-490E-ADE1-BE4D9DC09D27@ct.infn.it>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-24 19:01:13',3600,'2014-12-24 18:01:13',NULL,'[openstack-dev] [Keystone] Bug in federation','Hi John,\nthe problem is not to establish which variable has the correct information but the association\nbetween IDP and URL. In OS-Federation you define an authentication URL per IDP and protocol\nand it is supposed to use the specified IDP and protocol for authenticate. Nevertheless, during the\nauthentication there is not code to check if the IDP and protocol are the one specified for the URL\nand in the apache configuration for Juno there was no configuration in the apache side to bind the\nIDP with the URL.\n\nTherefore, you need to add something in OS_Federation to perform this control using the variable you\nare proposing or others.\n\nMarco\n\n> On 24 Dec 2014, at 15:15, John Dennis <jdennis at redhat.com> wrote:\n> \n> Can\'t this be solved with a couple of environment variables? The two\n> keys pieces of information needed are:\n> \n> 1) who authenticated the subject?\n> \n> 2) what authentication method was used?\n> \n> There is already precedence for AUTH_TYPE, it\'s used in AJP to\n> initialize the authType property in a Java Servelet. AUTH_TYPE would\n> cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps\n> there could be a convention that AUTH_TYPE could carry extra qualifying\n> parameters much like HTTP headers do. The first token would be the\n> primary mechanism, e.g. saml, negotiate, x509, etc. For authentication\n> types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra\n> parameter would qualify the actual mechanism used. For SAML that\n> qualifying extra parameter could be the value from AuthnContextClassRef.\n> \n> Item 1 could be covered by a new environment variable AUTH_AUTHORITY.\n> \n> If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would\n> be the KDC. For SAML it would probably be taken from the\n> AuthenticatingAuthority element or the IdP entityID.\n> \n> I\'m not sure I see the need for other layers to receive the full SAML\n> assertion and validate the signature. One has to trust the server you\'re\n> running in. It\'s the same concept as trusting REMOTE_USER.\n> \n> -- \n> John\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n====================================================\nEng. Marco Fargetta, PhD\n\nIstituto Nazionale di Fisica Nucleare (INFN)\nCatania, Italy\n\nEMail: Marco.Fargetta at ct.infn.it\n====================================================\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4551 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141224/4eb08f3b/attachment.bin>\n\n','<549ACA86.9070109@redhat.com>',NULL),('<1665665799.3303153.1343292232492.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-26 04:43:52',-14400,'2012-07-26 08:43:52',NULL,'[openstack-dev] API changes [was: Re: [API] Standardizing\n status codes in the native API]','\n> Context for others - Jay asked for feedback on some API change\n> guidelines which he and David have been working on. See here:\n> \n>   http://etherpad.openstack.org/Hn8rKP7XgB\n> \n> So ... kudos for kicking this off. I think it\'ll help a lot to get this\n> stuff written down - e.g. consistency in reviews and to give confidence\n> to users that we do care about API compat.\n\nAgreed, the current version on etherpad is a *great* start, and will be\nan excellent resource if we continue to codify the group wisdom as it \nevolves.\n\nJust one suggestion, can we put the guidelines under version control,\nin the style of the HACKING.rst?\n\nSo, I\'ve just added a small clarification to the etherpad, and there\'s\nnothing to stop anyone else adding their particular slant, without it\nnecessarily reflecting the group consensus.\n\nWhereas putting the thing in git at least ensures some oversight on\nchanges. Obviously the guideline should apply across all projects, but\nI think it would be OK to just stick the file into the nova repo\n(with the understanding that there\'s broader applicability).\n\nThanks,\nEoghan\n\n> What you have looks like a good start, but I think it\'s going to take\n> an\n> sustained effort to polish this off into something really useful for\n> reviewers in particular.\n> \n> The guidelines themselves will probably only get us so far. What will\n> probably be more effective is expanding on examples of where we\n> considered and approved/rejected an incompatible change. If we got\n> into\n> the habit of discussing such proposed changes on the list and then\n> documenting the conclusion as examples in the guidelines, I think\n> we\'d\n> be in great shape pretty quickly.\n> \n> I\'ve taken a stab at reworking most of the doc, but I don\'t think\n> I\'ve\n> changed it all that much. I think we\'re pretty well aligned. The main\n> thing I tried to was make it read like helpful advice for reviewers\n> and\n> developers rather than a stringent set of \"THOU SHALT NOT\"\n> commandments :-)\n> \n> Hope that helps,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1343253797.2465.244.camel@sorcha>',NULL),('<1666806933.3529187.1386383956041.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-06 21:39:16',-18000,'2013-12-07 02:39:16',NULL,'[openstack-dev] [TripleO][Tuskar] Icehouse Requirements','Thanks for the comments and questions!  I fully expect that this list of requirements\nwill need to be fleshed out, refined, and heavily modified, so the more the merrier.\n\nComments inline:\n\n> >\n> > *** Requirements are assumed to be targeted for Icehouse, unless marked\n> > otherwise:\n> >    (M) - Maybe Icehouse, dependency on other in-development features\n> >    (F) - Future requirement, after Icehouse\n> >\n> > * NODES\n> \n> Note that everything in this section should be Ironic API calls.\n> \n> >    * Creation\n> >       * Manual registration\n> >          * hardware specs from Ironic based on mac address (M)\n> \n> Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory\n> stats\n> \n> >          * IP auto populated from Neutron (F)\n> \n> Do you mean IPMI IP ? I\'d say IPMI address managed by Neutron here.\n> \n> >       * Auto-discovery during undercloud install process (M)\n> >    * Monitoring\n> >        * assignment, availability, status\n> >        * capacity, historical statistics (M)\n> \n> Why is this under \'nodes\'? I challenge the idea that it should be\n> there. We will need to surface some stuff about nodes, but the\n> underlying idea is to take a cloud approach here - so we\'re monitoring\n> services, that happen to be on nodes. There is room to monitor nodes,\n> as an undercloud feature set, but lets be very very specific about\n> what is sitting at what layer.\n\nThat\'s a fair point.  At the same time, the UI does want to monitor both\nservices and the nodes that the services are running on, correct?  I would\nthink that a user would want this.\n\nWould it be better to explicitly split this up into two separate requirements?\n\n> >    * Management node (where triple-o is installed)\n> \n> This should be plural :) - TripleO isn\'t a single service to be\n> installed - We\'ve got Tuskar, Ironic, Nova, Glance, Keystone, Neutron,\n> etc.\n\nI misspoke here - this should be \"where the undercloud is installed\".  My\ncurrent understanding is that our initial release will only support the undercloud\nbeing installed onto a single node, but my understanding could very well be flawed.\n\n> >        * created as part of undercloud install process\n> >        * can create additional management nodes (F)\n> >     * Resource nodes\n> \n>                         ^ nodes is again confusing layers - nodes are\n> what things are deployed to, but they aren\'t the entry point\n> \n> >         * searchable by status, name, cpu, memory, and all attributes from\n> >         ironic\n> >         * can be allocated as one of four node types\n> \n> Not by users though. We need to stop thinking of this as \'what we do\n> to nodes\' - Nova/Ironic operate on nodes, we operate on Heat\n> templates.\n\nRight, I didn\'t mean to imply that users would be doing this allocation.  But once Nova\ndoes this allocation, the UI does want to be aware of how the allocation is done, right?\nThat\'s what this requirement meant.\n\n> >             * compute\n> >             * controller\n> >             * object storage\n> >             * block storage\n> >         * Resource class - allows for further categorization of a node type\n> >             * each node type specifies a single default resource class\n> >                 * allow multiple resource classes per node type (M)\n> \n> Whats a node type?\n\nCompute/controller/object storage/block storage.  Is another term besides \"node type\"\nmore accurate?\n\n> \n> >             * optional node profile for a resource class (M)\n> >                 * acts as filter for nodes that can be allocated to that\n> >                 class (M)\n> \n> I\'m not clear on this - you can list the nodes that have had a\n> particular thing deployed on them; we probably can get a good answer\n> to being able to see what nodes a particular flavor can deploy to, but\n> we don\'t want to be second guessing the scheduler..\n\nCorrect; the goal here is to provide a way through the UI to send additional filtering\nrequirements that will eventually be passed into the scheduler, allowing the scheduler\nto apply additional filters.\n\n> >         * nodes can be viewed by node types\n> >                 * additional group by status, hardware specification\n> \n> *Instances* - e.g. hypervisors, storage, block storage etc.\n> \n> >         * controller node type\n> \n> Again, need to get away from node type here.\n> \n> >            * each controller node will run all openstack services\n> >               * allow each node to run specified service (F)\n> >            * breakdown by workload (percentage of cpu used per node) (M)\n> >     * Unallocated nodes\n> \n> This implies an \'allocation\' step, that we don\'t have - how about\n> \'Idle nodes\' or something.\n\nIs it imprecise to say that nodes are allocated by the scheduler?  Would something like\n\'active/idle\' be better?\n\n> >     * Archived nodes (F)\n> >         * Will be separate openstack service (F)\n> >\n> > * DEPLOYMENT\n> >    * multiple deployments allowed (F)\n> >      * initially just one\n> >    * deployment specifies a node distribution across node types\n> \n> I can\'t parse this. Deployments specify how many instances to deploy\n> in what roles (e.g. 2 control, 2 storage, 4 block storage, 20\n> hypervisors), some minor metadata about the instances (such as \'kvm\'\n> for the hypervisor, and what undercloud flavors to deploy on).\n\nThat\'s what I meant by node distribution (the first word that jumped out\nat me when I looked at the wireframes).\n\n> >       * node distribution can be updated after creation\n> >    * deployment configuration, used for initial creation only\n> \n> Can you enlarge on what you mean here?\n\nThis is the equivalent of the options that a user would have before running, say,\npackstack.  My understanding is that passing those options in is non-trivial, so\nwe would just want to expose the default options being used, without allowing\nthe user to change them.\n\n> >       * defaulted, with no option to change\n> >          * allow modification (F)\n> >    * review distribution map (F)\n> >    * notification when a deployment is ready to go or whenever something\n> >    changes\n> \n> Is this an (M) ?\n\nAh, you\'re right to call this out; it needs expansion.  I\'m guessing that having\na notification when a deployment deploys successfully should be possible during\nthe Icehouse timeframe; having a notification when there\'s an error or something\nis more of an (M).\n\n> > * DEPLOYMENT ACTION\n> >    * Heat template generated on the fly\n> >       * hardcoded images\n> >          * allow image selection (F)\n> \n> We\'ll be spinning images up as part of the deployment, I presume - so\n> this is really M, isn\'t it? or do you mean \'allow supplying images\n> rather than building just in time\' ? Or --- I dunno, but lets get some\n> clarity here.\n\nTuskar currently doesn\'t allow you to actually specify what image is spun up\nas part of the deployment.  This requirement is about allowing users to upload\ntheir own images and have them be used in the deployment.\n\n> >       * pre-created template fragments for each node type\n> >       * node type distribution affects generated template\n> >    * nova scheduler allocates nodes\n> >       * filters based on resource class and node profile information (M)\n> \n> What does this mean?\n\nThe proposed requirement is that within a deployment, a user can specify a resource class, and then\nspecify a \'node profile\' that lists the requirements necessary for a node to be placed in that class.\nUpon deployment, that information is passed through to the scheduler, which uses them in its filters\nwhen picking nodes.\n\n> \n> Sorry for having so many questions :)\n\nNot at all!  Again, thank you for asking them, and sorry for adding some of my own :)\n\nMainn\n \n> -Rob\n> \n> --\n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJ3HoZ1oATEv+GWb2WZjSsWoY+JsBpF8bnSFAWseLpPpFOZc8g@mail.gmail.com>',NULL),('<1667133933.26878362.1400384694844.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-17 20:44:54',-25200,'2014-05-18 03:44:54',NULL,'[Openstack] Juno Summit: VMware + OpenStack:\n	Accelerating	OpenStack in the Enterprise','Hi Michael, \n\nGlad you enjoyed the talk. Additionally, h ere is the video for the companion OpenStack + VMware \"deep dive demo\" session that was held right afterward: https://www.youtube.com/watch?v=fv7V_zbbd5g \n\nLet me know if you have questions about either talk. \n\nDan \n\n----- Original Message -----\n\n| From: \"Eric Brown\" <browne at vmware.com>\n| To: \"Michael Gale\" <gale.michael at gmail.com>\n| Cc: openstack at lists.openstack.org\n| Sent: Friday, May 16, 2014 11:54:57 PM\n| Subject: Re: [Openstack] Juno Summit: VMware + OpenStack: Accelerating\n| OpenStack in the Enterprise\n\n| https://www.youtube.com/watch?v=3WqFTPgNRGg\n\n| On May 16, 2014, at 3:39 PM, Michael Gale <gale.michael at gmail.com> wrote:\n\n| | Hey,\n| \n\n| | I am looking for the video to this session, I attended it on Wednesday and\n| | it\n| | gave a great look at how VMware and integrate with OpenStack:\n| \n\n| | http://openstacksummitmay2014atlanta.sched.org/event/2af26570126221f64af8e0ab891b9a33#.U3ZohXWx1dk\n| \n\n| | VMware + OpenStack: Accelerating OpenStack in the Enterprise\n| \n\n| | This type of transition can really help my company adopt OpenStack.\n| \n\n| | Thanks\n| \n| | Michael\n| \n| | _______________________________________________\n| \n| | Mailing list:\n| | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=2CQc966BQ6s3Cdd6nQ79uvWP17nF9g%2FX4m3XppGg1xQ%3D%0A&m=ShJBsRkQWTMRx%2FijU5eq5q0pglspm%2BTFonO%2BcLPWm8o%3D%0A&s=856b8357aa836f22d57b47b2c0e13772bba3e924ea3931aeae873a0634b8e15c\n| \n| | Post to : openstack at lists.openstack.org\n| \n| | Unsubscribe :\n| | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=2CQc966BQ6s3Cdd6nQ79uvWP17nF9g%2FX4m3XppGg1xQ%3D%0A&m=ShJBsRkQWTMRx%2FijU5eq5q0pglspm%2BTFonO%2BcLPWm8o%3D%0A&s=856b8357aa836f22d57b47b2c0e13772bba3e924ea3931aeae873a0634b8e15c\n| \n\n| _______________________________________________\n| Mailing list:\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=SpT6zLT203fyLuATIfjyy8nNvtmXwwcVHxFQWU4UPjY%3D%0A&s=272d46babe77750c098d5ccd916bf259fb798bbabab1667a524103cac981ccdf\n| Post to : openstack at lists.openstack.org\n| Unsubscribe :\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=SpT6zLT203fyLuATIfjyy8nNvtmXwwcVHxFQWU4UPjY%3D%0A&s=272d46babe77750c098d5ccd916bf259fb798bbabab1667a524103cac981ccdf\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140517/eb05c933/attachment.html>\n\n','<851BA582-2B1A-49D3-8FFC-CFA37D2EDF5A@vmware.com>',NULL),('<1667812063.119.1367908657591.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-07 06:37:37',0,'2013-05-07 06:37:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly-centos6 #7','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly-centos6/7/changes>\n\nChanges:\n\n[Gary Kotton] Adds POST method support in the metadata service\n\n------------------------------------------\n[...truncated 5013 lines...]\n    test_execute_env_var_prepend                                 OK    0.00\n    test_namespace_doest_not_exist                               OK    0.00\n    test_namespace_exists                                        OK    0.00\nTestIpRouteCommand\n    test_add_gateway                                             OK    0.00\n    test_del_gateway                                             OK    0.00\n    test_get_gateway                                             OK    0.00\n    test_pullup_route                                            OK    0.00\n    test_pullup_route_first                                      OK    0.00\nTestIpWrapper\n    test_add_device_to_namespace                                 OK    0.00\n    test_add_device_to_namespace_is_none                         OK    0.00\n    test_add_tuntap                                              OK    0.00\n    test_add_veth                                                OK    0.00\n    test_ensure_namespace                                        OK    0.01\n    test_ensure_namespace_existing                               OK    0.01\n    test_garbage_collect_namespace_does_not_exist                OK    0.01\n    test_garbage_collect_namespace_existing_empty_ns             OK    0.01\n    test_garbage_collect_namespace_existing_not_empty            OK    0.00\n    test_get_device                                              OK    0.01\n    test_get_devices                                             OK    0.00\n    test_get_devices_malformed_line                              OK    0.00\n    test_get_namespaces                                          OK    0.00\n    test_namespace_is_empty                                      OK    0.00\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.00\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.10\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    2.15\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.05\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.05\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.06\n    test_vip_get                                                 OK    0.05\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.06\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.05\n    test_health_monitor_update                                   OK    0.06\n    test_member_create                                           OK    2.25\n    test_member_delete                                           OK    0.06\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.06\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.06\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.06\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.01\n    test_get_instance_id_router_id                               OK    0.01\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.00\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.01\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.01\n    test_init_exists                                             OK    0.01\n    test_init_exists_unlink_fails_file_still_exists              OK    0.01\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.01\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.00\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.00\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.01\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    2.26\n    test_main_dont_fork                                          OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.01\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    0.30\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.30\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    2.79\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_without_admin_forbidden                     OK    0.20\n    test_update_quotas_forbidden                                 OK    0.38\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.47\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.26\n    test_list_quotas_with_admin                                  OK    0.31\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.30\n    test_quotas_default_values                                   OK    2.58\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.20\n    test_quotas_get_tenant_from_request_context                  OK    0.20\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.22\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.22\n    test_show_quotas_with_admin                                  OK    2.54\n    test_show_quotas_with_owner_tenant                           OK    0.20\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    2.56\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.20\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.20\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.22\n    test_quotas_limit_check                                      OK    2.63\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.20\n    test_quotas_limit_check_with_over_quota                      OK    0.21\n    test_quotas_loaded_bad_returns_404                           OK    0.21\n    test_quotas_loaded_right                                     OK    0.21\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.22\n    test_update_attributes                                       OK    2.57\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.20\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.20\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.42\n    test_KillFilter_deleted_exe                                  OK    0.00\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.43\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    0.31\n    test_health_monitor_update_with_router_id                    OK    0.29\n    test_health_monitor_update_without_router_id                 Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.VIPhWvNurG\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1:  7466 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly-centos6/7\n[SCP] Copying console log.\n\n\n','<1161878055.87.1367822227604.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1668637919.23658831.1402383335858.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 02:55:35',-14400,'2014-06-10 06:55:35',NULL,'[openstack-dev] [ceilometer][gate] ceilometer unit test\n frequently failing in gate','\n\n> Over the last 7 days ceilometer unit test jobs have a 18% failure rate in the\n> gate queue [0], while we see expect to see some failures in integration\n> testing, unit tests should not be failing in the gate with such a high\n> frequency (and for so long).\n> \n> It looks like these failures are due to two bugs [1] [2]. I would like to\n> propose that until these bugs are resolved, that ceilometer refrain from\n> approving patches as to not negatively impact the gate queue, which is\n> already in a tenuous state.\n\nHi Joe,\n\nThanks for raising this.\n\nWe have approved patches addressing both persistent failures\nin the verification queue:\n\n  https://review.openstack.org/98953\n  https://review.openstack.org/98820\n\nBTW these data on per-project unit test failure rates sound\ninteresting and useful. Are these rates surfaced somewhere\neasily consumable (by folks outside of the QA team)?\n\nCheers,\nEoghan\n \n> best,\n> Joe\n> \n> [0]\n> http://logstash.openstack.org/#eyJmaWVsZHMiOltdLCJzZWFyY2giOiJtZXNzYWdlOlwiRmluaXNoZWQ6XCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svY2VpbG9tZXRlclwiIEFORCBidWlsZF9xdWV1ZTpcImdhdGVcIiBBTkQgKGJ1aWxkX25hbWU6XCJnYXRlLWNlaWxvbWV0ZXItcHl0aG9uMjdcIiBPUiAgYnVpbGRfbmFtZTpcImdhdGUtY2VpbG9tZXRlci1weXRob24yNlwiKSIsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50Iiwib2Zmc2V0IjowLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQwMjM1NjkyMDE2MCwibW9kZSI6InNjb3JlIiwiYW5hbHl6ZV9maWVsZCI6ImJ1aWxkX3N0YXR1cyJ9\n> [1] https://bugs.launchpad.net/ceilometer/+bug/1323524\n> [2] https://bugs.launchpad.net/ceilometer/+bug/1327344\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHXdxOdhSQpVw-=467NSjg+SH_rYSM5hdCVVBSxxYCOCy3=Wcw@mail.gmail.com>',NULL),('<166DA678-DF26-46B3-A424-951F15E8F6A1@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-24 18:38:50',-18000,'2014-08-24 23:38:50',NULL,'[openstack-dev] [congress] specs update','So I have the spec changes all fixed up and pending reviews\nhttps://review.openstack.org/#/c/113638/\nhttps://review.openstack.org/#/c/116530/\nhttps://review.openstack.org/#/c/116531/\nhttps://review.openstack.org/#/c/116532/\n\nOnce these are merged, i will start pinging people on blueprints that are missing specs.\nThere is a process for holding over non-implemented specs into the next release. I will update the wiki.\n\n~ sean\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140824/c0141cd8/attachment.html>\n\n',NULL,NULL),('<1670650242.3060039.1365766218369.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-04-12 07:30:18',-14400,'2013-04-12 11:30:18',NULL,'[openstack-dev] [Openstack][Glance] difference api version\n between v1 and v2','\nHi Gareth,\n\nThe swift backend optionally used by glance to store image content is\njust one of the stores supported by glance. Alternatively the image\ndata can be stored in flat files (the default option), S3, RBD-based\nstores, or in external stores accessible via HTTP.\n\nIn addition to being able to use alternative stores to swift, glance\nalso manages image metadata independently of the backend, via a local\nRDBMS (generally mysql or posrtgresql).\n\nSo to answer your question, glance is not just a thin layer over swift.\nYou could of course re-implement a more limited glance-like image service\nin that way, but you would be losing some flexibility and also creating\na maintenance headache for yourself in shadowing developments in the\nglance API to avoid breaking clients such as nova & cinder.\n\nCheers,\nEoghan\n\n----- Original Message -----\n> Thanks for your answer, Iccha and Eoghan,\n> \n> I have another problem. After scanning the source codes, I found current\n> Glance is just managing image file ?or disk file?, which I think its\n> functionality is subset of Swift. Both x-meta-image-* and\n> x-meta-image-property-* could store in Swift metadata, and ACLs could help\n> manage authorizing. And some new features like protected properties could be\n> implemented as middleware in Swift too. So, I\'m not clear about the goal of\n> this project.\n> \n> Before reading the codes (I have to read codes because Glance documents is\n> not so helpful), I image this project could manage image file, and also data\n> in this image, such root password, default IP and so on. But it\'s not real.\n> \n> In short, if I want build a cloud with OpenStack and I have ability to write\n> my own codes, are there some reasons I setup Glance to manage images, not to\n> write a Swift middleware to avoid lots of middle-process?\n> \n> \n> \n> \n> On Fri, Apr 12, 2013 at 6:01 PM, Eoghan Glynn < eglynn at redhat.com > wrote:\n> \n> \n> \n> \n> > Gareth,\n> > \n> > There are a number of improvisations in v2 of Glance API. To name a few the\n> > registry layer is no longer been used in v2 of Glance API(so one less layer\n> > your request has to go through), image sharing has been designed to prevent\n> > spamming in v2, there are additional features like protected properties and\n> > multiple locations been worked on. I am sure there are several more.\n> \n> \n> One other bit of newness in v2 that\'s worth noting, because it\'s\n> actually used in anger by both cinder and nova currently, is the\n> direct_url metadata which if enabled in glance allows a client to\n> directly access image content from the backend store (if that can\n> be achieved more cheaply that way than by traversing the glance-api\n> service).\n> \n> Also there was a design document for the v2 API knocking around\n> that might be useful for background and detail. The latest draft\n> version I have to hand is:\n> \n> https://docs.google.com/document/d/1jPdgmQUzTuSt9iqcgPy74fbkzafCvqfQpvzRhwf2Kic\n> \n> though there may be a more recent version in existence.\n> \n> Cheers,\n> Eoghan\n> \n> \n> > Thanks,\n> > Iccha\n> > \n> > -----Original Message-----\n> > From: \"Gareth\" < academicgareth at gmail.com >\n> > Sent: Thursday, April 11, 2013 12:51am\n> > To: openstack-dev at lists.openstack.org\n> > Subject: [openstack-dev] [Openstack][Glance] difference api version between\n> > v1 and v2\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > Hi, Glance devs\n> > \n> > Any design purpose between v1 and v2 API?\n> > \n> > I know the url changed a little, but functionality seems same.\n> > \n> > So is there any further improvement in v2 API?\n> > \n> > Thanks\n> > --\n> > Gareth\n> > \n> > *Cloud Computing, Openstack, Fitness, Basketball\n> > *\n> > *OpenStack contributor*\n> > *My promise: if you find any spelling or grammar mistakes in my email from\n> > Mar 1 2013, notify me *\n> > *and I\'ll donate $1 or ?1 to an open organization you specify.*\n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> --\n> Gareth\n> \n> Cloud Computing, Openstack, Fitness, Basketball\n> OpenStack contributor\n> My promise: if you find any spelling or grammar mistakes in my email from Mar\n> 1 2013, notify me\n> and I\'ll donate $1 or ?1 to an open organization you specify.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<CAAhuP__AXJaehOVieH2dQmohUKfkp4mMrBW-n9BgaV=B9VhrDw@mail.gmail.com>',NULL),('<1670985218.27.1371018260650.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-12 06:24:20',0,'2013-06-12 06:24:20',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #254','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/254/>\n\n------------------------------------------\n[...truncated 12590 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:38149\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:38149/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (3671) wsgi starting up on http://127.0.0.1:38149/\n\nnova.osapi_compute.wsgi.server: INFO: (3671) accepted (\'127.0.0.1\', 60865)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [12/Jun/2013 06:18:57] \"GET /v2 HTTP/1.1\" 204 216 0.001078\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-92061b87-b1e4-40ff-94e1-742a1cee896c</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (3671) accepted (\'127.0.0.1\', 60866)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x90bc090>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x90bc090>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:38149/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-12 06:18:57 3671 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:38149/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [12/Jun/2013 06:18:57] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.260112\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for c91df14a04e84b58a17af69b7ede616f \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:53141\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:53141/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (3671) wsgi starting up on http://127.0.0.1:53141/\n\nnova.osapi_compute.wsgi.server: INFO: (3671) accepted (\'127.0.0.1\', 40500)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [12/Jun/2013 06:18:58] \"GET /v2 HTTP/1.1\" 204 216 0.001867\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-61b44ac3-46f7-4ecb-98e9-123cce016ef3</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (3671) accepted (\'127.0.0.1\', 40501)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9221150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9221150>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:53141/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     name)\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-12 06:18:58 3671 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:53141/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [12/Jun/2013 06:18:58] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.290373\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.16\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.SkDJgyjfXK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/254\n[SCP] Copying console log.\n\n\n','<730833083.22.1370931770482.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1671084662.824730.1380210657568.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 17:50:57',7200,'2013-09-26 15:50:57',NULL,'[openstack-dev] New Pycharm License','Hi!\n\nI send this email to get my PyCharm licence.\n\nThank you :)\n\n\n----- Original Message -----\nFrom: \"Andrew Melton\" <andrew.melton at rackspace.com>\nTo: openstack-dev at lists.openstack.org\nSent: Thursday, September 26, 2013 5:41:17 PM\nSubject: [openstack-dev] New Pycharm License\n\n\n\nHey Devs, \n\n\n\nIt\'s almost been a year since I sent out the first email and I\'ve been getting a few emails lately about alerts that the current license is about to expire. Well, I\'ve got a hold of our new license, good for another year. This\'ll give you access to the new Pro edition of Pycharm and any updates for a year. \n\n\n\nAs this list is public, I can\'t email the license out to everyone, so please reply to this email and I\'ll get you the license. \n\n\n\nAlso, please note that if your current license expires, Pycharm will continue to work. You will just stop receiving updates until you\'ve entered this new license. \n\n\n\nThanks, \n\nAndrew Melton \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1380210077.13436630@apps.rackspace.com>',NULL),('<1671137275.3725827.1381953168245.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-16 15:52:48',-14400,'2013-10-16 19:52:48',NULL,'[Openstack-docs] Havana Install - Neutron chapter','Thanks.  I have a suggestion/nitpick: currently, the actually installation details for Neutron have been put in a file called section_neutron-install-network-node.xml.  I believe this is a bit of a misnomer, since it actually also includes documentation for setting up the required parts of Neutron on the compute and controller nodes as well.  Perhaps we should split the file into multiple parts?  I didn\'t initially in my commit just as a side effect of writing it in a couple large bursts, but I don\'t think a large, monolithic file is the way to go.\n\nBest Regards,\nSolly\n\n----- Original Message -----\nFrom: \"Nermina Miller\" <nerminamiller at gmail.com>\nTo: \"Solly Ross\" <sross at redhat.com>\nCc: \"Darragh O\'Reilly\" <dara2002-openstack at yahoo.com>, openstack-docs at lists.openstack.org\nSent: Wednesday, October 16, 2013 3:43:45 PM\nSubject: Re: [Openstack-docs] Havana Install - Neutron chapter\n\nI\'ve brought in Solly\'s wonderful work in this patch:\nhttps://review.openstack.org/#/c/51789/4.\n\n\nOn Wed, Oct 16, 2013 at 2:23 PM, Solly Ross <sross at redhat.com> wrote:\n\n> Currently, my docs have use the Open vSwitch plugin, and have instructions\n> for either GRE or VLANs.  Note that there are several places where I don\'t\n> yet provide options commands for Ubuntu (specifically, some of the package\n> installs and the network config file), so if you could check the package\n> names for those commands, etc, that would be great.\n>\n> Best Regards,\n> Solly Ross\n>\n> ----- Original Message -----\n> From: \"Darragh O\'Reilly\" <dara2002-openstack at yahoo.com>\n> To: openstack-docs at lists.openstack.org\n> Sent: Wednesday, October 16, 2013 2:16:31 PM\n> Subject: Re: [Openstack-docs] Havana Install - Neutron chapter\n>\n>\n>\n> I can test the steps on Ubuntu as I have a script that can auto install\n> everything else. Let me know which plugin to do.\n>\n> Re, Darragh.\n>\n>\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n>\n\n\n\n-- \nThank you!\n\nNermina Miller\nTech Writer and Editor\n\n\n','<CAOGB-shvGTNsyHK+dBXV7BKahafSfPy7EAx93bFdejDM7YE8pQ@mail.gmail.com>',NULL),('<1671381361.36.1367648129567.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-04 06:15:29',0,'2013-05-04 06:15:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly-centos6 #4','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/4/>\n\n------------------------------------------\n[...truncated 3973 lines...]\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 489, in test_user_list_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:47828/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 823, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:54699/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 842, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:58481/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 496, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:52085/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 512, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:42214/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 35.25 secs:\n    7.75    TestTokenRevoking.test_group_membership_changes_revokes_token\n    7.12    KcEssex3TestCase.test_admin_requires_adminness\n    6.86    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.80    KcMasterTestCase.test_admin_requires_adminness\n    6.71    Kc11TestCase.test_admin_requires_adminness\n----------------------------------------------------------------------\nRan 1272 tests in 478.336s\n\nFAILED (SKIP=82, errors=129)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.centos6.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=66\n+ \'[\' 66 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.LsOwEPg1de\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/4\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/4/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1671834.DrhUZ4pAbg@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-16 21:18:06',3600,'2014-12-16 20:18:06',NULL,'[Openstack] [Openstack-operators] Migrating instances according\n	to load on host','Hello,\n\nThanks for show me some direction what I should look for :)\nI search blueprints of nova with \'drs\' and I found somethink like this: \nhttps://blueprints.launchpad.net/nova/+spec/resource-optimization-service\nIt would be nice to have it in nova :)\n\n---\nBest regards\nSlawek Kaplonski\nslawek at kaplonski.pl\n\nDnia wtorek, 16 grudnia 2014 12:05:41 Abel Lopez pisze:\n> Sounds like you\'re describing VMWare DRS.\n> It\'s a pretty neat feature that aims to reduce outages during maintenance\n> and also reduce the impact of noisy neighbor.\n> To my knowledge, we don\'t have that today, but I haven\'t been following the\n> wishlist for nova\n> > On Dec 16, 2014, at 12:01 PM, S?awek Kap?o?ski <slawek at kaplonski.pl>\n> > wrote:\n> > \n> > Hello,\n> > \n> > I\'m wondering is ther some solution (maybe separate project or some\n> > plugin)\n> > which allow to automatically live-migrate (or migrate when instances are\n> > stopped) instances between hosts according to load which instance generate\n> > on host. For example if there are 10 instances on host and all of then\n> > use lot cpu or ram some of them should be migrated to different (free)\n> > host. When there are instances which are do not heavy load - then should\n> > be migrated to one host where will be for example 15 such instances. Do\n> > you know about something like that for openstack?\n> > \n> > ---\n> > Best regards\n> > Slawek Kaplonski\n> > slawek at kaplonski.pl_______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141216/149399ea/attachment.pgp>\n\n','<6957A964-EDE2-4CAC-BA45-5925A36B9729@gmail.com>',NULL),('<1671834.DrhUZ4pAbg@laptop>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-16 21:18:06',3600,'2014-12-16 20:18:06',NULL,'[Openstack-operators] Migrating instances according to load on\n	host','Hello,\n\nThanks for show me some direction what I should look for :)\nI search blueprints of nova with \'drs\' and I found somethink like this: \nhttps://blueprints.launchpad.net/nova/+spec/resource-optimization-service\nIt would be nice to have it in nova :)\n\n---\nBest regards\nSlawek Kaplonski\nslawek at kaplonski.pl\n\nDnia wtorek, 16 grudnia 2014 12:05:41 Abel Lopez pisze:\n> Sounds like you\'re describing VMWare DRS.\n> It\'s a pretty neat feature that aims to reduce outages during maintenance\n> and also reduce the impact of noisy neighbor.\n> To my knowledge, we don\'t have that today, but I haven\'t been following the\n> wishlist for nova\n> > On Dec 16, 2014, at 12:01 PM, S?awek Kap?o?ski <slawek at kaplonski.pl>\n> > wrote:\n> > \n> > Hello,\n> > \n> > I\'m wondering is ther some solution (maybe separate project or some\n> > plugin)\n> > which allow to automatically live-migrate (or migrate when instances are\n> > stopped) instances between hosts according to load which instance generate\n> > on host. For example if there are 10 instances on host and all of then\n> > use lot cpu or ram some of them should be migrated to different (free)\n> > host. When there are instances which are do not heavy load - then should\n> > be migrated to one host where will be for example 15 such instances. Do\n> > you know about something like that for openstack?\n> > \n> > ---\n> > Best regards\n> > Slawek Kaplonski\n> > slawek at kaplonski.pl_______________________________________________\n> > OpenStack-operators mailing list\n> > OpenStack-operators at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: This is a digitally signed message part.\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141216/149399ea/attachment.pgp>\n\n','<6957A964-EDE2-4CAC-BA45-5925A36B9729@gmail.com>',NULL),('<1671980550.24832241.1409120863934.JavaMail.zimbra@zmail22.collab.prod.int.phx2.redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-27 02:27:43',-14400,'2014-08-27 06:27:43',NULL,'[openstack-dev] [neutron] Juno-3 BP meeting','Works perfect for me.  I will join.  \n\nSent from my Android phone using TouchDown (www.nitrodesk.com)\n\n\n-----Original Message-----\nFrom: Carl Baldwin [carl at ecbaldwin.net]\nReceived: Wednesday, 27 Aug 2014, 5:07\nTo: OpenStack Development Mailing List [openstack-dev at lists.openstack.org]\nSubject: Re: [openstack-dev] [neutron] Juno-3 BP meeting\n\nKyle,\n\nThese are three good ones.  I\'ve been reviewing the HA ones and have had an\neye on the other two.\n\n1300 is a bit early but I\'ll plan to be there.\n\nCarl\nOn Aug 26, 2014 4:04 PM, \"Kyle Mestery\" <mestery at mestery.com> wrote:\n\n> I\'d like to propose a meeting at 1300UTC on Thursday in\n> #openstack-meeting-3 to discuss Neutron BPs remaining for Juno at this\n> point. We\'re taking specifically about medium and high priority ones,\n> with a focus on these three:\n>\n> https://blueprints.launchpad.net/neutron/+spec/l3-high-availability)\n> https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security)\n>\n> https://blueprints.launchpad.net/neutron/+spec/security-group-rules-for-devices-rpc-call-refactor\n> )\n>\n> These three BPs will provide a final push for scalability in a few\n> areas and are things we as a team need to work to merge this week. The\n> meeting will allow for discussion of final issues on these patches\n> with the goal of trying to merge them by Feature Freeze next week. If\n> time permits, we can discuss other medium and high priority community\n> BPs as well.\n>\n> Let me know if this works by responding on this thread and I hope to\n> see people there Thursday!\n>\n> Thanks,\n> Kyle\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/f4c0024d/attachment.html>\n-------------- next part --------------\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n','<CALiLy7p7wBxN+PpSdgYUdvzPiTZFdzSEhGuhKfpsKocYXin=mw@mail.gmail.com>',NULL),('<1672542815.37.1365401859832.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-08 06:17:39',0,'2013-04-08 06:17:39',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #189','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/189/>\n\n\n\n','<1501537726.24.1365315385668.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1672969184.6634474.1353693614140.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-23 13:00:14',-18000,'2012-11-23 18:00:14',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova\n interaction going forward','\n\n> >2. the bandwidth stats are cached in the DB then retrieved again\n> >   before being reported, so the mechanism is quite heavyweight.\n> \n> Well, b/w accounting is the biggest issue with billing. Getting it\n> right is critically important for SP\'s. Personally I like the\n> comfort of having it in the db for later retrieval vs having it\n> float in the ether until it gets picked up. Somewhere, someone has\n> to persist this stuff quickly. Should this be done in Nova ... Hmm.\n> I could see both arguments. It is a pretty important thing though. I\n> suspect it lives there because it was done when ceilometer was but a\n> glint-in-the-eye.\n> \n> What would a lighter weight approach look like?\n\n\nI\'d expect that it would involve eagerly off-loading the b/w counters\nto the ceilo pipeline (or whatever is being used to publish these data)\nwhere it\'s likely to be persisted at the endpoint.\n\n(As opposed to caching in the nova DB, then retrieving and sending \noff as a notification, which is received and re-persisted in for example\nthe ceilo metering store)\n\nSo there\'s a chance that some notifications could be dropped if for\nexample the ceilo collector is swamped, but wouldn\'t these counters\nbe mainly cumulative? (and if so, would a v. small loss rate be a\nmassive issue?)\n\nCheers,\nEoghan\n \n\n\n','<60A3427EF882A54BA0A1971AE6EF03888572C3AE@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1672E09790594650BDBAB3845A120B2A@pistoncloud.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2012-03-12 15:39:08',-25200,'2012-03-12 22:39:08',NULL,'[OpenStack Foundation] Foundation Structure: An Alternative','I\'m on the look-out for emergent points of consensus, and I think I see one - Sean, you highlighted a 12-member board as being a target, and Dallas mentioned a concern about keeping the board a manageable size as well. Setting aside for a moment the composition (user seats, dev seats, tiered corporate seats vs. all elected, etc) - is a 12-seat board the target?  \n\nA second question - how would you define a self-affiliated block of companies? I can imagine throwing my vote behind a shared candidate, but would I have the right to pull support during their term, or would I need to wait for the next election? Can we have a vote of no-confidence for such a representative? (I suppose we could always draft a side letter, but I\'m hoping for a general-purpose solution).\n\nHeidi\'s name is dirty enough as it is.  \n\n--\nJoshua McKenty, CEO\nPiston Cloud Computing, Inc.\nw: (650) 24-CLOUD\nm: (650) 283-6846\nhttp://www.pistoncloud.com\n\n\"Oh, Westley, we\'ll never survive!\"\n\"Nonsense. You\'re only saying that because no one ever has.\"\n\n\nOn Monday, March 12, 2012 at 11:55 AM, Sean Roberts wrote:\n\n> How about as many companies that want to contribute annually $100K to running the foundation separate from marketing and sponsorship, can do so.  Each company or a self-affiliated block of companies can put forward their board candidate. The companies that contributed to the board can then vote on 2/3 of the overall board membership. The 8 candidates with the largest number of votes are board members for one year. The user community would still have 1/3 of the board seats to elect 4 people of note. The board membership would be limited to 12 people. This way, all the committees and boards will be elected.\n> A board membership code of conduct will be very important in this situation, as to protect the community from some companies up to mischief.\n>  \n> BTW, I see no reason to dirty the good name of Heidi Klum by dragging her into this.\n> sean\n> roberts\n>   \n> infrastructure strategy\n>   \n> seanrob at yahoo-inc.com (applewebdata://2E35986A-DC2A-436F-BB4A-C451982006C2/seanrob at yahoo-inc.com)\n> direct 408-349-5234    mobile 925-980-4729\n>   \n> 701 first avenue, sunnyvale, ca, 94089-0703, us\n> phone (408) 349 3300    fax (408) 349 3301\n>  \n>  \n>  \n> On 3/12/12 11:06 AM, \"Dallas Kashuba\" <dallas at dreamhost.com (mailto:dallas at dreamhost.com)> wrote:\n>  \n> >  \n> > On Mar 12, 2012, at 2:45 AM, Thierry Carrez wrote:\n> >  \n> > > Boris Renski Jr. wrote:\n> > > > While I like the simplicity and elegance of the newly proposed\n> > > > structure, I don?t see how it does away with the evils of the\n> > > > pay-to-play model?. Which is what you purport we are striving to\n> > > > achieve. What you, Josh, proposed is a simplified pay-to-play that\n> > > > arguably embraces the evils for the ?market driven selfishness? in an\n> > > > even more obvious way than the model before it. In your case, all the\n> > > > seats are simply purchased for a fixed price of $200K.\n> > > >  \n> > >  \n> > >  \n> > > Right, any pay-to-play model will create a threshold effect, and Josh\'s\n> > > proposal is just lowering the price to pay to get a reserved board seat\n> > > to something that a company like Piston Cloud can pay. Since a lot of\n> > > the 156 companies \"supporting\" OpenStack can afford such a price tag,\n> > > you end up with a board containing too many directors.\n> > >  \n> >  \n> >  \n> > This is something I was wondering about myself.  Would there be a limit on the number of directors under Josh\'s proposal?\n> >  \n> >  \n> > > > Once we accept this, the question of structuring the board really\n> > > > becomes the question of how does one raise the maximum amount of money\n> > > > to continue to have a centralized body with a mission to evangelize the\n> > > > project. You can structure it by tiers to let the bigger guys pay more\n> > > > and get a bigger logo on the homepage. You can do a flat structure like\n> > > > Josh proposed. You can auction off the board seats etc.\n> > > >  \n> > >  \n> > >  \n> > > I see four models for this:\n> > >  \n> > > All individual seats: All board seats are elected, you get one vote for\n> > > every foundation member. Sponsoring is done separately. This is likely\n> > > to raise the smallest amount of money, and the problem remains at\n> > > another level: \"what is a foundation member ?\".\n> > >  \n> >  \n> >  \n> > I agree that this model is likely to raise the smallest amount of money.   \n> >  \n> > > Tiered structure: this is the current proposal, which is well balanced.\n> > > The only issue is that the board grows by 3 people when (if) a strategic\n> > > member is added.\n> > >  \n> >  \n> >  \n> > This is another thing I was wondering about.  Will there be a limit on the number of strategic members?  I don\'t see the foundation wanting to turn away someone waving money around, but then you have to deal with board growth.\n> >  \n> >  \n> > > Single-price: this is Josh\'s proposal, but I think it will result in a\n> > > board that is too big and unable to function.\n> > >  \n> >  \n> >  \n> > > Pay-to-vote: you have two classes: corporate seats and individual seats.\n> > > Individual members elect the individual seats (which represent 25-33% of\n> > > the total). Corporate seats are also all elected and corporations get a\n> > > vote for every ?$ they put in. One drawback is that large corporations\n> > > which are no longer guaranteed of getting a board seat will probably pay\n> > > less under this model.\n> > >  \n> >  \n> >  \n> > Also agreed that large corporations will likely pay less without a guaranteed board seat.\n> >  \n> >  \n> > We\'ve been watching this conversation with much interest over the last couple of days at DreamHost.  Its great to see so many smart people who clearly care a great deal about this project and the foundation!\n> >  \n> > I\'ve been personally wrestling with this balance of fundraising vs the best leadership for the foundation.  I think ultimately the best leadership would be the meritocratic approach insulated from the money side of things, but I also see a lot of value in the financial stability provided by larger companies committing to a significant amount of funding over the longer term.\n> >  \n> >  \n> > One additional question I\'ve been pondering relates to both the \"Single-price\" and \"Tiered structure\" models as Thierry referred to them here.  If you do put limits on total board seats (and thus total foundation membership), what do you do if there are more companies interested in membership than you have spots available?  Do companies get turned away and if they do, what process is used to figure out who is in and who is out (in the voice of Heidi Klum).\n> >  \n> >  \n> > > Personally, I tend to prefer models that effectively prevent the board\n> > > from growing uncontrollably.\n> > >  \n> >  \n> >  \n> > Agreed.\n> >  \n> >  \n> >  \n> > - Dallas\n> >  \n> > --\n> > Co-Founder, DreamHost\n> > dallas at dreamhost.com (mailto:dallas at dreamhost.com)\n> >  \n> >  \n> >  \n> >  \n> >  \n> > _______________________________________________\n> > Foundation mailing list\n> > Foundation at lists.openstack.org (mailto:Foundation at lists.openstack.org)\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n> >  \n> _______________________________________________\n> Foundation mailing list\n> Foundation at lists.openstack.org (mailto:Foundation at lists.openstack.org)\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n>  \n>  \n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20120312/45dba0a0/attachment-0001.html>\n\n','<CB838A49.1FF39%seanrob@yahoo-inc.com>',NULL),('<1674071106.83.1383633240672.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-05 06:34:00',0,'2013-11-05 06:34:00',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #41','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/41/>\n\n------------------------------------------\n[...truncated 21216 lines...]\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          118.030\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   67.029\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  59.934\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         48.505\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]       45.888\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             42.877\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                42.725\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     42.419\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     37.642\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    37.289\n\n----------------------------------------------------------------------\nRan 1439 tests in 1406.456s\n\nOK (skipped=70)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-634840-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-634840.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az3-634840/41/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<140841686.27.1383201509392.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1674110771.44.1352678759921.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-12 00:05:59',0,'2012-11-12 00:05:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #90','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/90/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.35\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.06\n    test_public_versions                                        OK  0.05\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 19.007s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.07 secs:\n    2.30       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    2.27       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    1.08       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    0.35       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at f617b09874046a0f56f6342638cc8444ed719022#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 217bd202dd9a7359efb8b49799eb0626866a203f#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/90\n[SCP] Copying console log.\n\n\n','<1274935987.29.1352592245411.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<16745078.3313.1384369055622.JavaMail.thinrichs@promg-2n-a-dhcp151.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 10:57:35',-28800,'2013-11-13 18:57:35',NULL,'[openstack-dev] [neutron] Group-based Policy Sub-team Meetings','Are there plans for a concrete policy language (e.g. a grammar and semantics) to be part of the proposal, or does each plugin to Neutron supply its own policy language?\n\nI\'m trying to envision how Heat would utilize the policy API.  If there\'s a concrete policy language, then Heat can take an app template, extract the networking-relevant policy, and express that policy in the concrete language.  Then whatever plugin we\'re using for Neutron can implement that policy in any way it sees fit as long as it obeys the policy\'s semantics (according to the language--the semantics Heat intended).\n\nBut if there\'s no concrete policy language, how does Heat know which policy statements to send?  It doesn\'t know which plugin is being used for Neutron.  So it doesn\'t even know which strings are valid policy statements.  Or are we assuming that Heat knows which plugin is being used for Neutron?  Or am I missing something?\n\nThanks,\nTim\n\n----- Original Message -----\n| From: \"Kyle Mestery (kmestery)\" <kmestery at cisco.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Wednesday, November 13, 2013 9:57:54 AM\n| Subject: Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings\n| \n| On Nov 13, 2013, at 10:36 AM, Stephen Wong <s3wong at midokura.com>\n|  wrote:\n| \n| > Hi Kyle,\n| > \n| >    So no meeting this Thursday?\n| > \n| I am inclined to skip this week\'s meeting due to the fact I haven\'t\n| heard many\n| replies yet. I think a good starting point for people would be to\n| review the\n| BP [1] and Design Document [2] and provide feedback where\n| appropriate.\n| We should start to formalize what the APIs will look like at next\n| week\'s meeting,\n| and the Design Document has a first pass at this.\n| \n| Thanks,\n| Kyle\n| \n| [1]\n| https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction\n| [2]\n| https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing\n| \n| > Thanks,\n| > - Stephen\n| > \n| > On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery)\n| > <kmestery at cisco.com> wrote:\n| >> On Nov 13, 2013, at 8:58 AM, \"Stein, Manuel (Manuel)\"\n| >> <manuel.stein at alcatel-lucent.com> wrote:\n| >> \n| >>> Kyle,\n| >>> \n| >>> I\'m afraid your meeting vanished from the Meetings page [2] when\n| >>> user amotiki reworked neutron meetings ^.^\n| >>> Is the meeting for Thu 1600 UTC still on?\n| >>> \n| >> Ack, thanks for the heads up here! I have re-added the meeting. I\n| >> only heard\n| >> back from one other person other than yourself, so at this point\n| >> I\'m inclined\n| >> to wait until next week to hold our first meeting unless I hear\n| >> back from others.\n| >> \n| >>> A few heads-up questions (couldn\'t attend the HK design summit\n| >>> Friday meeting):\n| >>> \n| >>> 1) In the summit session Etherpad [3], ML2 implementation\n| >>> mentions insertion of arbitrary metadata to hint to underlying\n| >>> implementation. Is that (a) the plug-ing reporting its\n| >>> policy-bound realization? (b) the user further specifying what\n| >>> should be used? (c) both? Or (d) none of that but just some\n| >>> arbitrary message of the day?\n| >>> \n| >> I believe that would be (a).\n| >> \n| >>> 2) Would policies _always_ map to the old Neutron entities?\n| >>> E.g. when I have policies in place, can I query related\n| >>> network/port, subnet/address, router elements on the API or are\n| >>> there no equivalents created? Would the logical topology created\n| >>> under the policies be exposed otherwise? for e.g.\n| >>> monitoring/wysiwyg/troubleshoot purposes.\n| >>> \n| >> No, this is up to the plugin/MechanismDriver implementation.\n| >> \n| >>> 3) Do the chain identifier in your policy rule actions match to\n| >>> \"Service Chain UUID\" in Service Insertion, Chaining and API [4]\n| >>> \n| >> That\'s one way to look at this, yes.\n| >> \n| >>> 4) Are you going to describe L2 services the way group policies\n| >>> work? I mean, why would I need a LoadBalancer or Firewall\n| >>> instance before I can insert it between two groups when all that\n| >>> load balancing/firewalling requires is nothing but a policy for\n| >>> group communication itself? - regardless the service instance\n| >>> used to carry out the service.\n| >>> \n| >> These are things I\'d like to discuss at the IRC meeting each week.\n| >> The goal\n| >> would be to try and come up with some actionable items we can\n| >> drive towards\n| >> in both Icehouse-1 and Icehouse-2. Given how close the closing of\n| >> Icehouse-1\n| >> is, we need to focus on this very fast if we want to have a\n| >> measurable impact in\n| >> Icehouse-1.\n| >> \n| >> Thanks,\n| >> Kyle\n| >> \n| >> \n| >>> Best, Manuel\n| >>> \n| >>> [2]\n| >>> https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting\n| >>> [3]\n| >>> https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron\n| >>> [4]\n| >>> https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#\n| >>> \n| >>>> -----Original Message-----\n| >>>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n| >>>> Sent: Montag, 11. November 2013 19:41\n| >>>> To: OpenStack Development Mailing List (not for usage questions)\n| >>>> Subject: [openstack-dev] [neutron] Group-based Policy\n| >>>> Sub-team Meetings\n| >>>> \n| >>>> Hi folks! Hope everyone had a safe trip back from Hong Kong.\n| >>>> Friday afternoon in the Neutron sessions we discussed the\n| >>>> \"Group-based Policy Abstraction\" BP [1]. It was decided we\n| >>>> would try to have a weekly IRC meeting to drive out further\n| >>>> requirements with the hope of coming up with a list of\n| >>>> actionable tasks to begin working on by December.\n| >>>> I\'ve tentatively set the meeting [2] for Thursdays at 1600\n| >>>> UTC on the #openstack-meeting-alt IRC channel. If there are\n| >>>> serious conflicts with this day and time, please speak up\n| >>>> soon. Otherwise, we\'ll host our first meeting on Thursday this\n| >>>> week.\n| >>>> \n| >>>> Thanks!\n| >>>> Kyle\n| >>>> \n| >>>> [1]\n| >>>> https://blueprints.launchpad.net/neutron/+spec/group-based-pol\n| >>> icy-abstraction\n| >>>> [2]\n| >>>> https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_\n| >>>> Sub-Team_Meeting\n| >>>> _______________________________________________\n| >>>> OpenStack-dev mailing list\n| >>>> OpenStack-dev at lists.openstack.org\n| >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| >>>> \n| >>> _______________________________________________\n| >>> OpenStack-dev mailing list\n| >>> OpenStack-dev at lists.openstack.org\n| >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| >> \n| >> \n| >> _______________________________________________\n| >> OpenStack-dev mailing list\n| >> OpenStack-dev at lists.openstack.org\n| >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| > \n| > _______________________________________________\n| > OpenStack-dev mailing list\n| > OpenStack-dev at lists.openstack.org\n| > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n\n\n','<C7CF46F5-FD09-4582-9C11-EB5AF3D94171@cisco.com>',NULL),('<1676132418.54.1386742557091.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:15:56',0,'2013-12-11 06:15:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-dsvm-neutron-grizzly #3','See <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-grizzly/3/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az2-827368 in workspace <https://jenkins02.openstack.org/job/periodic-tempest-dsvm-neutron-grizzly/ws/>\n[periodic-tempest-dsvm-neutron-grizzly] $ /bin/bash -xe /tmp/hudson1901579856941339426.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\nerror: Unable to find 9e06327193e2aa23b488c3c566f13acd3f03de87 under https://review.openstack.org/p/openstack-infra/devstack-gate\nCannot obtain needed object 9e06327193e2aa23b488c3c566f13acd3f03de87\nerror: Fetch failed.\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: logs/**\n[SCP] \'logs/**\' doesn\'t match anything, but \'**\' does. Perhaps that\'s what you mean?\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-827368\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-dsvm-neutron-grizzly/devstack-precise-hpcloud-az2-827368/3\n[SCP] Copying console log.\n\n\n','<45034153.42.1386569077181.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1676364486.7014427.1394192583960.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-07 12:43:03',3600,'2014-03-07 11:43:03',NULL,'[openstack-dev] time.sleep is affected\n	by	eventlet.monkey_patch()','Hi,\n\nYes, a monotonic *must* be used to compute timeouts. I wrote the time.monotonic() function of Python 3.3 and the PEP 418. For my Trollius project, I wrote this code for Python 2 using ctypes. It works on Linux, Windows, Mac OS X, OpenBSD, FreeBSD and Solaris:\nhttps://bitbucket.org/enovance/trollius/src/5e45fc18fce0b34a47481916a274dace7f2964f4/asyncio/time_monotonic.py?at=trollius\n\nThere are existing Python modules, examples:\nhttps://github.com/gavinbeatty/python-monotonic-time\nhttps://github.com/ludios/Monoclock\n\nAny other many projecs have their own implementation.\n\nRead also the 418 for the background:\nhttp://legacy.python.org/dev/peps/pep-0418/\n\nFYI On Linux, since the glibc 2.17, clock_gettime() is provided by the libc. On older glibc versions, it is provided by librt.\n\nVictor\n\n----- Mail original -----\n> De: \"Yuriy Taraday\" <yorik.sar at gmail.com>\n> ?: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Envoy?: Vendredi 7 Mars 2014 08:52:56\n> Objet: Re: [openstack-dev] time.sleep is affected by	eventlet.monkey_patch()\n> \n> On Fri, Mar 7, 2014 at 11:20 AM, Yuriy Taraday < yorik.sar at gmail.com > wrote:\n> \n> \n> \n> All in all it sounds like an eventlet bug. I\'m not sure how it can be dealt\n> with though.\n> \n> Digging into it I found out that eventlet uses time.time() by default that is\n> not monotonic. There\'s no clear way to replace it, but you can workaround\n> this:\n> 1. Get monotonic clock function here:\n> http://stackoverflow.com/a/1205762/238308 (note that for FreeBSD or MacOS\n> you\'ll have to use different constant).\n> 2. Make eventlet\'s hub use it:\n> eventlet.hubs._threadlocal.hub =\n> eventlet.hubs.get_default_hub().Hub(monotonic_time)\n> \n> --\n> \n> Kind regards, Yuriy.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CABocrW4bvQfXWDNgfo20Bbf3UaCr39BOg1Ud-y7YXT7Xx=j-HA@mail.gmail.com>',NULL),('<1676587155.36.1382249498620.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-20 06:11:38',0,'2013-10-20 06:11:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #35','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/35/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4800610>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4800610>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3886890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x3886890>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-e1ac97f3-9490-4440-9be0-0f53d8dbef46\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-19T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'19\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-21T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'21\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-22T06:11:05+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-22T06:11:05-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'05\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:11:05Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'05\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4f72850>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15cf6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 75.85 secs:\n    19.00    TestGlanceControl.test_bouncing\n    14.79    TestScrubber.test_delayed_delete\n    14.23    TestGlanceControl.test_reload\n    13.97    TestGlanceControl.test_respawn\n    13.88    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 932 tests in 610.771s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-35\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.7\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.NsNy8ej5b5\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/35/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-10/35\n[SCP] Copying console log.\n\n\n','<1225752882.31.1382163093453.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<167703621.26651464.1407444075954.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 16:41:15',-14400,'2014-08-07 20:41:15',NULL,'[openstack-dev] [all] The future of the integrated release','\n> > If we try to limit the number of WIP slots, then surely aspiring\n> > contributors will simply work around that restriction by preparing\n> > the code they\'re interested in on their own private branches, or\n> > in their github forks?\n> >\n> > OK, some pragmatic contributors will adjust their priorities to\n> > align with the available slots. And some companies employing\n> > large numbers of contributors will enforce policies to align\n> > their developers\' effort with the gatekeepers\' priorities.\n> >\n> > But I suspect we\'d also have a good number who would take the\n> > risk that their code never lands and work on it anyway. Given\n> > that such efforts would really be flying beneath the radar and\n> > may never see the light of day, that would seem like true waste\n> > to me.\n> \n> Is that a problem? \n\nWell I guess it wouldn\'t be, if we\'re willing to tolerate waste.\n\nBut IIUC the motiviation behind applying the ideas of kanban is\nto minimize waste piling up at bottlenecks in the pipeline.\n\nMy point was simply that we don\'t have direct control over the\ncontributors\' activities, so that limiting WIP slots wouldn\'t\ncut out the waste, rather it would force it underground.\n\nThis seems worse to me because either:\n\n (a) lots of good ideas end up being lost, as a critical mass\n     of other contributors don\'t get to see them\n\nand/or:\n\n (b) contributors figure out ways to by-pass the rate-limiting\n     on gerrit and share their code in other ways\n\nJust a thought ...\n\nCheers,\nEoghan\n\n\n> If such developers are going to work on their pet\n> project anyway, it\'s really up to the core team whether or not they\n> think it makes sense to merge the changes upstream.\n> \n> If the core team doesn\'t think they\'re worth merging (given the\n> constraints on reviewer/approver time) then so be it.  At that point\n> either we accept that we\'re going to leave possible contributions by the\n> wayside or else we increase the core team (and infrastructure, and other\n> strategic resources)  to be able to handle the load.\n> \n> Chris\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<53E3CA50.4000209@windriver.com>',NULL),('<1677204340.8.1371708743183.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-20 06:12:23',0,'2013-06-20 06:12:23',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-folsom #262','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/262/>\n\n\n\n','<381870718.4.1371624115209.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1677318636.17.1367562157975.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-03 06:22:37',0,'2013-05-03 06:22:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-grizzly-centos6 #3','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/3/changes>\n\nChanges:\n\n[ldbragst] Grab instance for migration before updating usage\n\n[P?draig Brady] Raise rather than generating millions of IPs.\n\n[yaguang.tang] Add missing snapshot image properties for VMware Hyper.\n\n[Russell Bryant] Fix attach when running as root without sysfsutils\n\n[Russell Bryant] import and install gettext in vm_vdi_cleaner.py\n\n[Russell Bryant] Catch glance image create exceptions\n\n[Russell Bryant] Convert the cache key from unicode to a string.\n\n[Russell Bryant] Fix baremetal get_available_nodes\n\n[Michael Still] Allow listing fixed_ips for a given compute host.\n\n[emilien.macchi] Wrong proxy port in nova.conf for Spice proxy\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on centos6-5 in workspace <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/>\nCheckout:periodic-nova-python26-stable-grizzly-centos6 / <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/> - hudson.remoting.Channel at 53b5e629:centos6-5\nUsing strategy: Default\nLast Built Revision: Revision a58d97502fdbab4e4416b779a6219bbe687250d6 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/nova.git\ngit --version\ngit version 1.7.1\nFetching upstream changes from git://github.com/openstack/nova.git\nCommencing build of Revision 43004ba04e77cb4776b42b4697f28364ef2db839 (origin/stable/grizzly)\nChecking out Revision 43004ba04e77cb4776b42b4697f28364ef2db839 (origin/stable/grizzly)\n[periodic-nova-python26-stable-grizzly-centos6] $ /bin/bash -xe /tmp/hudson3898547859615753170.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack nova\n+ version=26\n+ org=openstack\n+ project=nova\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.BIzY5tCyT5\n+ TMPDIR=/tmp/tmp.BIzY5tCyT5\n+ trap \'rm -rf /tmp/tmp.BIzY5tCyT5\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\ngrep: /var/log/auth.log: No such file or directory\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n+ org=openstack\n+ project=nova\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' nova == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.nova.python26.stable.grizzly.centos6.3\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/dist/nova-jenkins.periodic.nova.python26.stable.grizzly.centos6.3.zip>\npy26 runtests: commands[0]\npy26 runtests: commands[1]\nrunning testr\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.BIzY5tCyT5/tmp_NuKTq\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.BIzY5tCyT5/tmpJVopin\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.BIzY5tCyT5/tmpmB0fhi\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests  --load-list /tmp/tmp.BIzY5tCyT5/tmp1I5F0l\n======================================================================\nFAIL: nova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint\ntags: worker-3\n----------------------------------------------------------------------\nEmpty attachments:\n  pythonlogging:\'nova\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/nova/tests/test_db_api.py\",> line 2640, in test_archive_deleted_rows_fk_constraint\n    self.assertEqual(num, 1)\nMismatchError: 0 != 1\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 5545 tests in 425.509s\nFAILED (id=0, failures=2, skips=12)\nerror: testr failed (1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-grizzly-centos6/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.9.2\ncliff==1.3.3\ncmd2==0.6.5.1\ncoverage==3.6\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python26.stable.grizzly.centos6.3\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npyflakes==0.7.2\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-quantumclient==2.2.1\npython-subunit==0.0.11\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\ntestrepository==0.0.15\ntesttools==0.9.31\nunittest2==0.5.1\nwarlock==1.0.0\nwebsockify==0.3.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ cp .testrepository/0 ./subunit_log.txt\n+ .tox/py26/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nnova.tests.test_db_api.ArchiveTestCase.test_archive_deleted_rows_fk_constraint (subunit.RemotedTestCase)\nprocess-returncode (subunit.RemotedTestCase)\n+ gzip -9 ./subunit_log.txt\n+ gzip -9 ./testr_results.html\n++ .tox/py26/bin/python .tox/py26/bin/testr list-tests\n++ sed -e 1d\n++ wc -l\n/usr/bin/python: No module named subunit\n+ foundcount=0\n++ .tox/py26/bin/python .tox/py26/bin/testr last\n++ sed -ne \'s/Ran \\([0-9]\\+\\).*tests in.*/\\1/p\'\n+ rancount=5545\n+ \'[\' 5545 -lt 0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.BIzY5tCyT5\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-grizzly-centos6/3\n[SCP] Copying console log.\n\n\n','<1338498541.564.1367475688425.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<167738e7.17c56.1485db0e881.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 11:52:28',28800,'2014-09-10 03:52:28',NULL,'[openstack-dev] [all] i need some help on this bug Bug #1365892','Hello,\n    I use backdoor of eventlet to enable gc.DEBUG_LEAK, and after wait a few minutes, i can sure that there will some objects that can not be collected by gc.collect in gc.garbage. \nThose looks like this (catched in ceilometer-collector)\n\n\n[\'_context_auth_token\', \'auth_token\', \'new_pass\'],\n (<cell at 0x363bc58: list object at 0x361c170>,\n  <cell at 0x363bda8: function object at 0x361a5f0>),\n <function _fix_passwords at 0x361a5f0>,\n <cell at 0x363bde0: list object at 0x363c680>,\n <cell at 0x363bd70: function object at 0x361a668>,\n [\'_context_auth_token\', \'auth_token\', \'new_pass\'],\n (<cell at 0x363bde0: list object at 0x363c680>,\n  <cell at 0x363bd70: function object at 0x361a668>),\n <function _fix_passwords at 0x361a668>,\n <cell at 0x363bf30: list object at 0x361b680>,\n <cell at 0x363e168: function object at 0x361a758>,\n [\'_context_auth_token\', \'auth_token\', \'new_pass\'],\n (<cell at 0x363bf30: list object at 0x361b680>,\n  <cell at 0x363e168: function object at 0x361a758>),\n <function _fix_passwords at 0x361a758>,\n <cell at 0x363e1a0: list object at 0x363cdd0>,\n <cell at 0x363e130: function object at 0x361a7d0>,\n\n\nand i suspect those code in oslo.messaging\n\n\ndef _safe_log(log_func, msg, msg_data):\n    \"\"\"Sanitizes the msg_data field before logging.\"\"\"\n    SANITIZE = [\'_context_auth_token\', \'auth_token\', \'new_pass\']\n\n\n    def _fix_passwords(d):\n        \"\"\"Sanitizes the password fields in the dictionary.\"\"\"\n        for k in d.iterkeys():\n            if k.lower().find(\'password\') != -1:\n                d[k] = \'<SANITIZED>\'\n            elif k.lower() in SANITIZE:\n                d[k] = \'<SANITIZED>\'\n            elif isinstance(d[k], dict):\n                _fix_passwords(d[k])\n        return d\n\n\n    return log_func(msg, _fix_passwords(copy.deepcopy(msg_data)))\n\n\ni can resolve this problem by add _fix_passwords = None before _safe_log returns.\n\n\nBut i do not really understand why this problem happened, and in depth why the gc can not collect those object. Although i can make those uncollectable objects disappeared.\nBut this is not good enough, because if you do not understand it you will write out some code like this in future, and then also has memory leak too.\n\n\nSo can some one helps me give some detailed on recursive closure used like the code above, and on why gc can not collect them.\nThanks a lot lot ......\n\n\n--\n\nBest\n    Li Tianqing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140910/12441e50/attachment.html>\n\n',NULL,NULL),('<1677863900.76.1379831789294.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-22 06:36:29',0,'2013-09-22 06:36:29',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #25','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/25/>\n\n------------------------------------------\n[...truncated 23994 lines...]\n    self.nova_boot()\n  File \"tempest/scenario/test_minimum_basic.py\", line 92, in nova_boot\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-193493410> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-22 06:21:58,971 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:21:59,079 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 51, in test_resize_server_confirm\n    instance = self.create_server(self.compute_client)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-171999245> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: tempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  pythonlogging:\'\'\n  stderr\n  stdout\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_server_advanced_ops.py\", line 69, in test_server_sequence_suspend_resume\n    instance = self.create_server(self.compute_client)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-678530739> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-22 06:22:04,122 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:04,237 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 72, in test_snapshot_pattern\n    server = self._boot_image(self.config.compute.image_ref)\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 38, in _boot_image\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-41450865> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{\n2013-09-22 06:22:18,329 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:18,439 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:19,361 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:19,470 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:21,053 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:22,130 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:23,268 Starting new HTTP connection (1): 127.0.0.1\n2013-09-22 06:22:24,343 Starting new HTTP connection (1): 127.0.0.1\n}}}\n\nTraceback (most recent call last):\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 129, in test_volume_boot_pattern\n    keypair)\n  File \"tempest/scenario/test_volume_boot_pattern.py\", line 53, in _boot_instance_from_volume\n    create_kwargs=create_kwargs)\n  File \"tempest/scenario/manager.py\", line 390, in create_server\n    self.status_timeout(client.servers, server.id, \'ACTIVE\')\n  File \"tempest/scenario/manager.py\", line 290, in status_timeout\n    self._status_timeout(things, thing_id, expected_status=expected_status)\n  File \"tempest/scenario/manager.py\", line 338, in _status_timeout\n    self.config.compute.build_interval):\n  File \"tempest/test.py\", line 237, in call_until_true\n    if func():\n  File \"tempest/scenario/manager.py\", line 329, in check_status\n    raise exceptions.BuildErrorException(message)\nBuildErrorException: Server %(server_id)s failed to build and is in ERROR status\nDetails: <Server: scenario-server-782298945> failed to get to expected status.                           In ERROR state.\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n======================================================================\nFAIL: tearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\ntearDownClass (tempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest)\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"tempest/thirdparty/boto/test.py\", line 270, in tearDownClass\n    raise exceptions.TearDownException(num=fail_count)\nTearDownException: 2 cleanUp operation failed\n\n\n======================================================================\nFAIL: process-returncode\nprocess-returncode\n----------------------------------------------------------------------\n_StringException: Binary content:\n  traceback (test/plain; charset=\"utf8\")\n\n\n----------------------------------------------------------------------\nRan 1013 tests in 1699.991s\n\nFAILED (failures=60, skipped=48)\nERROR: InvocationError: \'/bin/sh tools/pretty_tox.sh (?!.*\\\\[.*\\\\bslow\\\\b.*\\\\])(^tempest\\\\.(api|scenario|thirdparty|cli|tests))\'\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-366127-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-366127.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-366127/25/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1963905468.72.1379658578720.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1678142545.4797054.1344941632178.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-14 06:53:52',-14400,'2012-08-14 10:53:52',NULL,'[openstack-dev] [nova] Some nova bugs needing\n	prioritization/target\'ing at F-3','\nFolks,\n\nThe following bugs with fixes already landed (or with well-progressed\nreviews) still need prioritization and/or target\'ing at Folsom-3:\n\n  https://bugs.launchpad.net/nova/+bug/988335  \n  https://bugs.launchpad.net/nova/+bug/1020634\n  https://bugs.launchpad.net/nova/+bug/1021373\n  https://bugs.launchpad.net/nova/+bug/1021748\n  https://bugs.launchpad.net/nova/+bug/1022961\n  https://bugs.launchpad.net/nova/+bug/1024354\n  https://bugs.launchpad.net/nova/+bug/1026600\n  https://bugs.launchpad.net/nova/+bug/1026167\n  https://bugs.launchpad.net/nova/+bug/1027187\n  https://bugs.launchpad.net/nova/+bug/1027281\n  https://bugs.launchpad.net/nova/+bug/1029911\n  https://bugs.launchpad.net/nova/+bug/1030010\n  https://bugs.launchpad.net/nova/+bug/1031737\n\nCan someone on nova-core do the needful?\n\nThanks,\nEoghan\n\n\n','<1103038573.4783009.1344938834006.JavaMail.root@redhat.com>',NULL),('<1678149485.427.1367129143360.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:05:43',0,'2013-04-28 06:05:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/18/>\n\n------------------------------------------\n[...truncated 5084 lines...]\n    raise Exception()\nException\n2013-04-28 06:05:37    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-28 06:05:37,735 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-28 06:05:37,736 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-28 06:05:37,736 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,737 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,737 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-28 06:05:37,738 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-28 06:05:37,739 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-28 06:05:37  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-28 06:05:37,739 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-28 06:05:37    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-28 06:05:37,740 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,743 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.743281\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.743281\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37,744 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,744 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,745 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,746 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.746177\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.746177\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37,747 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,748 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,748 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-28 06:05:37,749 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,749 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,750 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.750774\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.750774\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37,752 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,753 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,753 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-28 06:05:37,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,754 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,755 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37,756 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.755758\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.755758\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37,757 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,757 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,758 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-28 06:05:37,759 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,759 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,760 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-28 06:05:37,761 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-28 06:05:37,762 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.761423\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-28T06:05:37.761423\', resource_metadata={}) from 0 transformer\n2013-04-28 06:05:37,763 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,763 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37,764 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-28 06:05:37,764 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-28 06:05:37,765 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-28 06:05:37    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 17.339s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.18\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a79.g3acd2a5\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a415.g25541a5\nnumpy==1.7.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.V9Y06WTXfF\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/18\n[SCP] Copying console log.\n\n\n','<1977835202.365.1367042667426.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<167826675.28736023.1407798844624.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 19:14:04',-14400,'2014-08-11 23:14:04',NULL,'[openstack-dev] [qa][ceilometer] swapping the roles of mongodb\n and sqlalchemy for ceilometer in Tempest','\n\n> >> So would we:\n> >>\n> >>  (a) add a new integrated-gate-ceilometer project-template to [1],\n> >>      in the style of integrated-gate-neutron or integrated-gate-sahara,\n> >>      which would replicate the main integrated-gate template but with\n> >>      the addition of gate-tempest-dsvm-ceilometer-mongodb(-full)\n> >>\n> >> or:\n> >>\n> >>  (b) simply move gate-tempest-dsvm-ceilometer-mongodb(-full) from\n> >>      the experimental column[2] in the openstack-ceilometer project,\n> >>      to the gate column on that project\n> >>\n> >> or:\n> >>\n> >>  (c) something else\n> >>\n> >> Please excuse the ignorance of gate mechanics inherent in that question.\n> >\n> >\n> >\n> > Correct, AFAIK (a) or (b) would be sufficient.\n> >\n> > There is another option, which is make the mongodb version the default in\n> > integrated-gate and only run SQLA on ceilometer.\n> >\n> \n> Joe,\n> \n> I believe this last option is equivalent to making mongodb the\n> recommended implementation by virtue of suddenly being the most tested\n> implementation. I would prefer not to see that.\n> \n> Eoghan,\n> \n> IIUC (and I am not an infra expert) I would suggest (b) since this\n> keeps the mongo tests within the ceilometer project only, which I\n> think is fine from a \"what we test is what we recommend\" standpoint.\n\nFair enough ... though I think (a) would also have that quality\nof encapsulation, as long as the new integrated-gate-ceilometer\nproject-template was only referenced by the openstack/ceilometer\nproject.\n\nI\'m not sure it makes a great deal of difference though, so would\nbe happy enough to go with either (b) or (a).\n\n> Also, if there is a situation where a change in Nova passes with\n> ceilometer+mysql and thus lands in Nova, but fails with\n> ceilometer+mongodb, yes, that would break the ceilometer project\'s\n> gate (but not the integrated gate). It would also indicate a\n> substantial abstraction violation within ceilometer. I have proposed\n> exactly this model for Ironic\'s deploy driver testing, and am willing\n> to accept the consequences within the project if we break our own\n> abstractions.\n\nFair point.\n\nCheers,\nEoghan\n\n\n','<CAExZKEoVF808tc9nYGQovz8_qZ2F61oxqb3TJNL-hXQBYaQWnA@mail.gmail.com>',NULL),('<1678370197.67.1374905724557.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-27 06:15:24',0,'2013-07-27 06:15:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #299','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/299/>\n\n\n\n','<1519483188.58.1374819053452.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1678864625.12844291.1396541122885.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-03 12:05:22',-14400,'2014-04-03 16:05:22',NULL,'[openstack-dev] [Nova] Hosts within two Availability Zones :\n possible or not ?','----- Original Message -----\n \n> Currently host aggregates are quite general, but the only ways for an\n> end-user to make use of them are:\n> \n> 1) By making the host aggregate an availability zones (where each host\n> is only supposed to be in one availability zone) and selecting it at\n> instance creation time.\n> \n> 2) By booting the instance using a flavor with appropriate metadata\n> (which can only be set up by admin).\n> \n> \n> I would like to see more flexibility available to the end-user, so I\n> think we should either:\n> \n> A) Allow hosts to be part of more than one availability zone (and allow\n> selection of multiple availability zones when booting an instance), or\n\nWhile changing to allow hosts to be in multiple AZs changes the concept from an operator/user point of view I do think the idea of being able to specify multiple AZs when booting an instance makes sense and would be a nice enhancement for users working with multi-AZ environments - \"I\'m OK with this instance running in AZ1 and AZ2, but not AZ*\".\n\n-Steve\n\n\n','<533D755C.70906@windriver.com>',NULL),('<1679629631.158.1358236817318.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-15 08:00:17',0,'2013-01-15 08:00:17',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #7','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/7/>\n\n------------------------------------------\n[...truncated 15547 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:52 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-17e2c87a-5d96-471b-9e30-ddf856461a97\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\nSKIP: No OpenStack Network API endpoint\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/248fad7b-1336-4805-be4b-dd854b69b556\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:42 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-8ceac2cc-5fdd-4662-9a79-9469a51f71de\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/301d9a7c-363a-445f-8b23-fed352eaaff8\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:43 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-519fb78d-6988-4e62-8b11-14f6e5a91f71\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/85c02d20-1fe1-477e-bf9b-5cc092e33071\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:44 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-0a11041a-0253-4d0a-87a0-8b3fd64f9370\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/ab19acfa-3e12-40c4-a7a6-00af3718eb8b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:45 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-1f6609d0-8a9d-467c-bda9-1d831bb0a249\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/370975df-5e3b-4b48-a79f-c217faf0707b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:46 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d40a22dd-a4e9-4293-a808-9d1c7cce2373\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/608d3aee-86c1-48f2-a747-a38f9bc64660\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:48 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-8a483f6d-60b6-40d9-afc3-95fabb23bdee\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/2632b1d1-8b38-4200-9bc1-acfe69a3bf3c\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:49 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-a0343417-50b7-47c2-8568-273e2f9b20cc\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/dda66a5a-bb18-496d-800e-908cbea07764\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:50 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-5c375cbb-90cf-4647-9e66-976f6816f8e8\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/4e16417c-58d4-42e7-aa93-fb78ea747d61\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:51 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-f80253d4-00c4-4a31-85cd-5ab27300d72b\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xNVQwNzo1NDozOS42ODU4MzYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE2VDA3OjU0OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvNWUxYWNhZmIxNGJkNDNiOGIwMDVkYjQ2N2ZmZThjZTAiLCAiaWQiOiAiMTgzM2E2ZmE5NWZkNGEyMDliMDM2ZTIwYzJhMDAxNzgiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICI0YTA5ZDIyMDMzM2Y0YWUzYmIxMDVlMWNkNGVlMWMwZSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiOGNkNDg5YzFhM2U2NGNhNzlmODQ1NTM3YTZmMTEyMmUiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCIsICJpZCI6ICIxODZmMzExYzJjNzU0NDQ0YWE5YzkyYTIzOThhZGFiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIwY2M1M2FiOTU2OGI0OTIwOTZmOGE0YWQxYzI0MGUwYyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzVlMWFjYWZiMTRiZDQzYjhiMDA1ZGI0NjdmZmU4Y2UwIiwgImlkIjogIjI4MDMxMTZhNzAxNjQyZWE4MmQ1YjAyNTlhZDBiYzBlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF81ZTFhY2FmYjE0YmQ0M2I4YjAwNWRiNDY3ZmZlOGNlMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjAzMTNjYmY4ODk3ZDQ0ZGE4N2ViN2Q3ZjhlNjdmMTU0IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiM2E1MzIwMGI5MGQ4NDhmMWJjMDE3MDE4MDIxNWE0NWIiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzI4YTk3MzU1N2MzNDdiZTkzYjZkMDdiZDAyYjE4NmIiLCAiNDJjZTQyZmE5ZjFhNGY0MmI2ZmUxM2NjNDc1NTJiZjciXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBCTOIiEY4m9655Y567i+ANVOPbxNw0VLPgYn1MdkKQtvGCTpk8U7ESculSuicJc0v942vaXKoVCPI+JGX4Vu8c-dLnkmyuLmh2WsN3VKLiIqUFUfi-qUGweqbEbtNemm7o+JVNDDgnSbsSH+Q3u1v2url4n674S5AODZKPkU8tbw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/43eea4f7-15c5-422a-a462-56aca1733c33\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Tue, 15 Jan 2013 07:55:52 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-17e2c87a-5d96-471b-9e30-ddf856461a97\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 653 tests in 3982.219s\n\nOK (SKIP=84)\nGenerating coverage report\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 194, in <module>\n    main(sys.argv)\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 179, in main\n    shutil.copytree(path, CLI.output)\n  File \"/usr/lib/python2.7/shutil.py\", line 175, in copytree\n    os.makedirs(dst)\n  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\n    mkdir(name, mode)\nOSError: [Errno 13] Permission denied: \'<https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/ws/logs/coverage-report\'>\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/rabbitmq/rabbit at devstack-1358229086-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/rabbitmq/rabbit at devstack-1358229086.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/7/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<961445035.134.1358144395040.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<167B45DD-F122-44F8-8CD4-3AA7A78DAD76@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-20 16:15:43',-18000,'2013-02-20 21:15:43',NULL,'[openstack-dev] [devstack] Problem logging into Horizon as\n	non-admin?','Hi,\n\nI\'m not sure how I got into this situation, but I have a VM based setup with Devstack, where I stopped and started it a few times. Currently, I see the following issue:\n\n- Start Devstack\n- Login as admin and create a project\n- Create a user and add as a MEMBER to the project.\n- Log out\n- Try to log in as the user.\n\nAt this point, I get a traceback on the browser (shown at end of this e-mail). The odd thing is that it says the user does not have admin privileges (true), for the project page. I\'m logging in at the main URL, and it is jumping to /project for some reason. \n\nI have another VM and this works fine. A coworker is having the same issue, again, not sure how he hit this either.  If I check as admin, the user is there. I\'ve tried using a different browser (FF vs Chrome), rebooting the system and retrying, and I get the same results.\n\nAny idea as to what could have happened?\nWhy is it redirecting to a /project page?\nAny ideas on how to diagnose?\n\nThanks:\n\nForbidden at /project/\nUser does not have admin privileges (HTTP 403) (Request-ID: req-981a0ae9-e9dd-43d5-8946-ec9b27811a25)\nRequest Method:	GET\nRequest URL:	http://172.16.6.141/project/\nDjango Version:	1.4.3\nException Type:	Forbidden\nException Value:	\nUser does not have admin privileges (HTTP 403) (Request-ID: req-981a0ae9-e9dd-43d5-8946-ec9b27811a25)\nException Location:	/opt/stack/python-novaclient/novaclient/client.py in request, line 194\nPython Executable:	/usr/bin/python\nPython Version:	2.7.3\nPython Path:	\n[\'/opt/stack/horizon/openstack_dashboard/wsgi/../..\',\n \'/opt/stack/python-keystoneclient\',\n \'/opt/stack/python-novaclient\',\n \'/opt/stack/python-openstackclient\',\n \'/opt/stack/keystone\',\n \'/opt/stack/glance\',\n \'/opt/stack/python-glanceclient/setuptools_git-1.0b1-py2.7.egg\',\n \'/opt/stack/python-glanceclient\',\n \'/opt/stack/nova\',\n \'/opt/stack/horizon\',\n \'/opt/stack/quantum\',\n \'/opt/stack/cinder\',\n \'/opt/stack/python-cinderclient\',\n \'/usr/local/lib/python2.7/dist-packages/ropemode-0.2-py2.7.egg\',\n \'/usr/local/lib/python2.7/dist-packages/rope-0.9.4-py2.7.egg\',\n \'/usr/local/lib/python2.7/dist-packages/ropemacs-0.7-py2.7.egg\',\n \'/usr/local/lib/python2.7/dist-packages\',\n \'/usr/lib/python2.7\',\n \'/usr/lib/python2.7/plat-linux2\',\n \'/usr/lib/python2.7/lib-tk\',\n \'/usr/lib/python2.7/lib-old\',\n \'/usr/lib/python2.7/lib-dynload\',\n \'/usr/lib/python2.7/dist-packages\',\n \'/usr/lib/python2.7/dist-packages/PIL\',\n \'/usr/lib/python2.7/dist-packages/gst-0.10\',\n \'/usr/lib/python2.7/dist-packages/gtk-2.0\',\n \'/usr/lib/pymodules/python2.7\',\n \'/usr/lib/python2.7/dist-packages/ubuntu-sso-client\',\n \'/usr/lib/python2.7/dist-packages/ubuntuone-client\',\n \'/usr/lib/python2.7/dist-packages/ubuntuone-control-panel\',\n \'/usr/lib/python2.7/dist-packages/ubuntuone-couch\',\n \'/usr/lib/python2.7/dist-packages/ubuntuone-installer\',\n \'/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol\',\n \'/opt/stack/horizon/openstack_dashboard\']\nServer time:	Wed, 20 Feb 2013 21:03:25 +0000\nTraceback Switch to copy-and-paste view\n\n/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py in get_response\n                        response = callback(request, *callback_args, **callback_kwargs) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/decorators.py in dec\n        return view_func(request, *args, **kwargs) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/decorators.py in dec\n            return view_func(request, *args, **kwargs) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/decorators.py in dec\n        return view_func(request, *args, **kwargs) ...\n? Local vars\n/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py in view\n            return self.dispatch(request, *args, **kwargs) ...\n? Local vars\n/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py in dispatch\n        return handler(request, *args, **kwargs) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/views.py in get\n        handled = self.construct_tables() ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/views.py in construct_tables\n            handled = self.handle_table(table) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/views.py in handle_table\n        data = self._get_data_dict() ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/tables/views.py in _get_data_dict\n            self._data = {self.table_class._meta.name: self.get_data()} ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/overview/views.py in get_data\n        super(ProjectOverview, self).get_data() ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/usage/views.py in get_data\n        self.usage.summarize(*self.usage.get_date_range()) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/usage/base.py in summarize\n                                  _(\'Unable to retrieve usage information.\')) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/usage/base.py in summarize\n                self.usage_list = self.get_usage_list(start, end) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/usage/base.py in get_usage_list\n        usage = api.nova.usage_get(self.request, self.tenant_id, start, end) ...\n? Local vars\n/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/nova.py in usage_get\n    return NovaUsage(novaclient(request).usage.get(tenant_id, start, end)) ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/v1_1/usage.py in get\n                         \"tenant_usage\") ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/base.py in _get\n        _resp, body = self.api.client.get(url) ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/client.py in get\n        return self._cs_request(url, \'GET\', **kwargs) ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/client.py in _cs_request\n                                            **kwargs) ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/client.py in _time_request\n        resp, body = self.request(url, method, **kwargs) ...\n? Local vars\n/opt/stack/python-novaclient/novaclient/client.py in request\n            raise exceptions.from_response(resp, body, url, method) ...\n? Local vars\n\n\n\nPCM (Paul Michali)\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 495 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130220/b19d00d9/attachment-0001.pgp>\n\n',NULL,NULL),('<167BC4B4-E6E6-49DA-95E6-AD532364CE3D@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-07 16:28:44',-28800,'2013-03-08 00:28:44',NULL,'[openstack-dev] [Nova] PTL Candidacy','\nOn Mar 7, 2013, at 2:04 AM, Mark McLoughlin <markmc at redhat.com> wrote:\n\n> On Thu, 2013-03-07 at 10:45 +0100, Thierry Carrez wrote:\n>> Vishvananda Ishaya wrote:\n>>> I\'d like to announce formally that I won\'t be running for nova PTL this cycle. PTL duties for a large project like Nova take an inordinate amount of time and I think it is good to spread the load around.\n>>> \n>>> Over the last release cycle Russell Bryant has been extremely helpful, taking on a lot of the blueprint and meeting work. Other members have also contributed in important ways, by doing massive amounts of reviews (Sean Dague, Michael Still, Kevin Mitchell) or taking on specific areas of functionality (Devananda Van Der Veen, Daniel Berrange, Chris Behrens).\n>>> \n>>> I don\'t think it is possible for one person to fly solo; it really requires a team of people working together. I will therefore continue to help the new PTL by taking on whatever duties I can. I plan on continuing to contribute code, bug fixes, and reviews.\n>> \n>> Yes, I think Nova needs to be run by a small group (1-4) of very active\n>> lieutenants (nova-drivers group ?), potentially split along functional\n>> lines, with the PTL having the duties to keep a global view, updated\n>> roadmaps and do release meeting reports. To compensate for that, the PTL\n>> gets the right to make final calls when one needs to be taken (+ a free\n>> TC seat).\n> \n> A model that could work is that drivers become a very small group of\n> leaders (e.g. 4 members) that make final calls based on rough consensus\n> amongst them.\n\n+1\n\nI like this approach. It seems to be happening organically anyway, but we\ncould make it more official.\n\nVish\n\n> \n> OpenStack basically requires that all projects have a PTL (and not just\n> for the TC seat) but maybe an individual project could prove the concept\n> of \"joint, consensus based leadersip\" can work and rotate the figurehead\n> PTL title amongst the drivers every 6 months.\n> \n> With these PTL elections, you can say it\'s better when each PTL position\n> is contested because it shows that the project has multiple viable\n> leaders. However, I hate the idea that folks who are effectively jointly\n> leading a project are forced to compete for the PTL title and that this\n> competition would in any way damage their relationship and ability to\n> jointly lead. I also hate the idea that the loser of that competition\n> then steps back and takes less of a leadership role.\n> \n> Cheers,\n> Mark.\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<1362650695.2383.8.camel@sorcha>',NULL),('<1680518.L3mdUvXxqU@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-16 15:40:57',36000,'2014-06-16 05:40:57',NULL,'[openstack-dev] [nova] Distributed locking','On Fri, 13 Jun 2014 09:40:30 AM Matthew Booth wrote:\n> On 12/06/14 21:38, Joshua Harlow wrote:\n> > So just a few thoughts before going to far down this path,\n> > \n> > Can we make sure we really really understand the use-case where we think\n> > this is needed. I think it\'s fine that this use-case exists, but I just\n> > want to make it very clear to others why its needed and why distributing\n> > locking is the only *correct* way.\n> \n> An example use of this would be side-loading an image from another\n> node\'s image cache rather than fetching it from glance, which would have\n> very significant performance benefits in the VMware driver, and possibly\n> other places. The copier must take a read lock on the image to prevent\n> the owner from ageing it during the copy. Holding a read lock would also\n> assure the copier that the image it is copying is complete.\n\nFor this particular example, taking a lock every time seems expensive.  An \nalternative would be to just try to read from another node, and if the result \nwasn\'t complete+valid for whatever reason then fallback to reading from \nglance.\n\n> > * What happens when a node goes down that owns the lock, how does the\n> > software react to this?\n> \n> This can be well defined according to the behaviour of the backend. For\n> example, it is well defined in zookeeper when a node\'s session expires.\n> If the lock holder is no longer a valid node, it would be fenced before\n> deleting its lock, allowing other nodes to continue.\n> \n> Without fencing it would not be possible to safely continue in this case.\n\nSo I\'m sorry for explaining myself poorly in my earlier post.  I think you\'ve \njust described waiting for the lock to expire before another node can take it, \nwhich is just a regular lock behaviour.  What additional steps do you want \nFence() to perform at this point?\n\n(I can see if the resource provider had some form of fencing, then it could do \nall sorts of additional things - but I gather your original use case is \nexactly where that *isn\'t* an option)\n\n\n\"If the lock was allowed to go stale and not released cleanly, then we should \nforcibly reboot the stale instance before allowing the lock to be held again\" \nshouldn\'t be too hard to add.\n\n- Is this just rebooting the instance sufficient for similar situations or would \nwe need configurable \"actions\"?\n- Which bot do we trust to issue the reboot command?\n\n>From the locking service pov, I can think of several ways to implement this, \nso we probably want to export a high-level operation and allow the details to \nvary to suit the underlying locking implementation.\n\n-- \n - Gus\n\n\n','<539AB8FE.2090809@redhat.com>',NULL),('<1680902632.15.1352851560587.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:06:00',0,'2012-11-14 00:06:00',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/92/>\n\n------------------------------------------\n[...truncated 265 lines...]\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.04\n    test_get_image_details_marker_limit                          OK    0.09\n    test_get_image_details_sort_disk_format_asc                  OK    0.08\n    test_get_image_details_with_maximum_size                     OK    0.06\n    test_get_image_details_with_minimum_size                     OK    0.07\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.05\n    test_get_image_index_limit                                   OK    0.08\n    test_get_image_index_limit_None                              OK    0.07\n    test_get_image_index_marker                                  OK    0.08\n    test_get_image_index_marker_limit                            OK    0.08\n    test_get_image_members                                       OK    0.05\n    test_get_image_members_not_existing                          OK    0.05\n    test_get_image_non_existing                                  OK    0.05\n    test_get_index_sort_container_format_desc                    OK    0.08\n    test_get_index_sort_created_at_asc                           OK    0.17\n    test_get_index_sort_disk_format_asc                          OK    0.07\n    test_get_index_sort_id_desc                                  OK    0.08\n    test_get_index_sort_name_asc                                 OK    0.07\n    test_get_index_sort_size_asc                                 OK    0.07\n    test_get_index_sort_status_desc                              OK    0.08\n    test_get_index_sort_updated_at_desc                          OK    0.07\n    test_get_member_images                                       OK    0.05\n    test_replace_members                                         OK    0.05\n    test_update_image                                            OK    0.07\n    test_update_image_not_existing                               OK    0.05\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.01\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.01\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.20\n    test_version_control_existing_db                             OK    0.81\n    test_walk_versions                                           OK    0.85\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.00\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 40.97 secs:\n    11.64    TestScrubber.test_delayed_delete\n    9.22    TestBinGlance.test_results_filtering\n    7.41    TestBinGlance.test_results_pagination\n    7.23    TestBinGlance.test_results_sorting\n    5.47    TestBinGlance.test_add_list_update_list\n----------------------------------------------------------------------\nRan 338 tests in 105.234s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-diablo/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nimportlib==1.0.2\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\nordereddict==1.1\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.5\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<243470105.55.1352765115225.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<168112439.82948038.1381354213156.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-10-09 14:30:13',-25200,'2013-10-09 21:30:13',NULL,'[OpenStack-Infra] Third Party Testing: ServiceAccount for\n	posting reviews','Attached a wrong file. Please use SmokeSignal.pub.tgz \n\nThanks \nSreeram \n\n----- Original Message -----\n\nFrom: \"Sreeram Yerrapragada\" <syerrapragada at vmware.com> \nTo: openstack-infra at lists.openstack.org \nSent: Wednesday, October 9, 2013 2:26:47 PM \nSubject: Third Party Testing: ServiceAccount for posting reviews \n\nHi Admin, \n\nHere at vmware we have setup a Jenkins CI environment based on Gerrit Plugin and would like to post reviews. Could you please create a dedicated account? \n\nAccountName: \" SmokeSignal \" \nPublic key: <Attached> \n\nPlease let me know if you need any other information. \n\nThanks \nSreeram \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131009/2b7eb001/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: SmokeSignal.pub.tgz\nType: application/x-compressed-tar\nSize: 464 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131009/2b7eb001/attachment.bin>\n\n','<1154020949.82944638.1381354007210.JavaMail.root@vmware.com>',NULL),('<168186660.46089008.1414095739990.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/user-committee',NULL,'2014-10-23 16:22:20',-14400,'2014-10-23 20:22:20',NULL,'[User-committee] Telcom Working Group','Hi all,\n\nI spoke with Carol on the phone earlier to try and clarify the situation but wanted to ensure my thoughts are recorded on the list as well. By way of background I currently facilitate the existing NFV sub team with the help of a couple of others (volunteers welcome!) which consists of people from service providers, network equipment providers, and OpenStack vendors interested in this space:\n\n    https://wiki.openstack.org/wiki/Meetings/NFV\n\nIt\'s thus far been primarily focussed on identifying use cases/requirements for NFV, turning these into actionable OpenStack blueprints, and finally implementing these. This effort started in Atlanta, made some progress in Juno, and is now hoping to regroup in Paris to drive further improvements in Kilo.\n\n> -------- Forwarded Message --------\n> Subject: 	[User-committee] Telcom Working Group\n> Date: 	Wed, 22 Oct 2014 19:28:48 +0000\n> From: 	Barrett, Carol L <carol.l.barrett at intel.com>\n> To: 	user-committee at lists.openstack.org\n> <user-committee at lists.openstack.org>\n> \n> \n> \n> Hi All ? I?m glad to see the interest in forming a Telco Work group. I?d\n> like to propose a charter and scope as a starting point for discussion:\n>  \n> Charter (if one is already in development pls let me know):\n> \n>   * Foster discussion amongst Telco users of OpenStack to share BKMs,\n>     resolve issues, etc.\n>   * Gather information on add?l features, functions, capabilities,\n>     services needed to increase OpenStack deployments by Telco users and\n>     engage OpenStack community developers to discuss/implement\n>   * Understand business, market and ecosystem barriers to OpenStack\n>     deployments and work with the community to create action plans to\n>     address them.\n\nAs I may have indicated above I see (1) and (2) as largely being the combination of the efforts of the existing group and ETSI NFV (see https://wiki.openstack.org/w/images/c/c7/NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf for the latest copy of the OpenStack gap analysis provided by ETSI NFV). How other initiatives like OPNFV might fit into this is unknown but it seems like (3) is the item raised that is currently not directly addressed in the context of OpenStack at least by the Foundation, the Board, or community driven initiatives like the existing working group.\n\nIt\'s not immediately clear whether addressing this requires a completely new working group, and the inherent confusion from having two groups working in the same space in the same community or some way to address within the auspices of existing frameworks with some loose but defined coupling to the requirement identification and development activities occurring in the community.\n\n> Scope:\n> \n>   * Include the current NFV Work Group into this team bringing community\n>     developers\n\nIt\'s important to note that it can\'t be assumed that developers from the existing community will necessarily follow, particularly if the effort is seen to be too marketing/business centric and a distraction from actually implementing the required functionality. Building a developer community around this space has been non-trivial precisely because of the gap between the marketing hype around NFV and the current realities of implementation. I understand the desire to make the marketing story more specific to OpenStack, but simply wanted to highlight that if there is one thing NFV can\'t be accused of it\'s not having enough marketing!\n\nCertainly when I raised the topic in the weekly meeting on Wednesday there was some scepticism about any attempt to combine efforts here distracting from laying out design and implementation priorities for Kilo which is front and centre for the existing group. The reason I had raised it however remains valid, per some conversation on the community list it appears to be more difficult at this venue to informally obtain space for BoF style activities then it has been in the past.\n\nIn Atlanta we used one of the development pods but due to the number of interested parties this proved quite difficult to manage, it was also hard to identify exactly where we would be and what time until we were on the ground at the event. We got plenty of feedback that there was not enough notice for everyone to attend.\n\nFor this reason if there is consensus that there really does need to be a separate effort to address the marketing/business side of the coin I would still be interested in the idea of co-locating in the space scheduled for this working group on the Wednesday afternoon and effectively splitting the room. This would allow all of those interested in this space to attend a single venue, which we can get out in advance, and self select which area they are interested in assisting with.\n\nThanks,\n\nSteve\n\n>   * Create a Marketing/Business team in the work group to work on\n>     messaging framework, customer whitepapers, reference architectures,\n>     etc. This group could also interact with OPNFV, ETSI NFV and other\n>     groups where there?s common interests.\n>   * Create an Ecosystem team in the work group to develop the\n>     Marketplace and create reference materials to support OpenStack\n>     deployments\n>\n> Is there interest in meeting in Paris to kick-off this work group?\n> Regards.\n> Carol\n\n\n\n','<544871BD.6050806@openstack.org>',NULL),('<1682063095.11414719.1349945544365.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 04:52:24',-14400,'2012-10-11 08:52:24',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','\n\nThanks for the quick response June Yi,\n\n> Synaps basically stores metric data aggregated with 1 minute\n> resolution in hybrid way, in-memory of storm workers and Cassandra\n> database. And it rolls those aggregated datapoints up again when\n> another resolutions of statistics are requested.\n\nAre all aggregations (sum, min, max, average, sample count)\nfor the 60s metrics stored across all dimensions (i.e. instance ID,\ninstance type, image ID etc. for AWS/EC2 metrics)?\n\nOr are some or all aggregation-over-dimensions only calculated lazily\nif and when a corresponding call to GetMetricStatistics occurs?\n \n> Storm holds time-series datapoints within flexible sliding window per\n> metric based on its longest period of alarm so that it can evaluate\n> alarms without any reading operation from Cassandra database.\n\nHow do you handle metric backfill? Say for example at time t0 a\ndelayed datapoint is received for t0-600s and you\'re evaluating\na monitor with say 3x5min evaluation periods. Is the in-memory\nrepresentation updated or somehow marked as stale so as to force\na re-read from Cassandra?\n\nCheers,\nEoghan\n\n\n> Synaps was designed with inspiration by following posts:\n> [1]\n> https://www.cloudkick.com/blog/2010/mar/02/4_months_with_cassandra/\n> [2]\n> http://pyvideo.org/video/675/storm-the-hadoop-of-realtime-stream-processing\n> \n> Hi Endre,\n> \n> > But how does Synaps then difffer from Ceilometer? It looks to be\n> > duplicated\n> > efforts here?\n> > \n> \n> I think I don\'t understand Ceilometer enough but as I know its main\n> purpose is to be a billing system based on hourly collected data\n> while Synaps is focusing to be a monitoring service which deals with\n> more amount of data more frequently.\n> \n> Thank you,\n> June Yi\n> \n> ------- Original Message -------\n> Sender : Endre Karlson<endre.karlson at gmail.com>\n> Date : 2012-10-11 06:04 (GMT+09:00)\n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> But how does Synaps then difffer from Ceilometer? It looks to be\n> duplicated efforts here?\n> \n> \n> Endre.\n> \n> \n> 2012/10/10 Joonwon Lee <joonwon7.lee at samsung.com>\n> \n> Hi, Eoghan,\n> 1. No, we don\'t have any relation with ceilometer.\n> 2. Cassandra and Storm (as explained in\n> http://wiki.openstack.org/Synaps)\n> 3. As far as I understand, aggregation is performed lazily on the\n> request.\n>  (Metrics are collected every minute and aggregated according to the\n>  request.)\n> \n> Deok-June Yi can explain with more details tomorrow, if you want.\n> Thanks,\n> Joonwon Lee\n> \n> \n> ------- Original Message -------\n> Sender : Eoghan Glynn<eglynn at redhat.com>\n> \n> Date : Oct 10, 2012 21:14 (GMT+09:00)\n> \n> Title : Re: [openstack-dev] Introducing Synaps project that provides\n> AWS CloudWatch compatible API\n> \n> \n> \n> Hi Joonwon Lee,\n> \n> > Unfortunately, we could not attend the Design Summit. We also need\n> > some time\n> > before opening our source codes, mostly for our internal process.\n> > We\n> > will try to shorten this time.\n> \n> It\'s unfortunate you guys won\'t be at the summit, as it would have\n> been great to discuss in that forum.\n> \n> But that said, the quicker you can push the code through your\n> internal\n> process, the better.\n> \n> \n> > Now we\'re preparing the overview of our project and other\n> > documentation.\n> > If you have any questions, feel free to ask them at any time.\n> \n> A few immediate questions that spring to mind:\n> \n> 1. Are you re-using any of the ceilometer[1] infrastructure for\n>    your metrics collection pipeline?\n> \n> 2. What technology is the metrics store based on, at a high level?\n>    (e.g. RDBMS accessed via sqlalchemy, noSQL store such as MongoDB,\n>     etc.)\n> \n> 3. How are you performing datapoint aggregation? (e.g. eagerly on\n>    metric ingestion, versus lazily on get)\n> \n> Cheers,\n> Eoghan\n> \n> [1] http://ceilometer.readthedocs.org/en/latest/architecture.html\n> \n> \n> > Here are answers of June Yi for Steven Hardy\'s questions below.\n> > > - Is the metric collection secure/authenticated?\n> > > - Are metrics collected from the hypervisors or in-instance?\n> > > - Can service monitoring (in instance) metrics be collected?\n> > > - Is the API authenticated (ie via keystone ec2 credentials?)\n> >\n> > All metrics are collected using the API. The API is authenticated\n> > via\n> > auth\n> > module came from Nova.Authenticate WSGI middleware which supports\n> > AWS\n> > signature v2. It works well with LdapDriver. But we did not tested\n> > if\n> > it is\n> > working with keystone yet.\n> >\n> > Default metrics (i.e. CPUUtilization, disk IO, network IO) are\n> > collected\n> > from hypervisors. Custom metrics can be collected from in-instance\n> > or\n> > any other source.\n> >\n> > Regards,\n> > --\n> > Joonwon Lee, principal software engineer, Samsung SDS\n> >\n> >\n> > ------- Original Message -------\n> > Sender : Eoghan Glynn\n> \n> > Date : 2012-10-10 18:59 (GMT+09:00)\n> > Title : Re: [openstack-dev] Introducing Synaps project that\n> > provides\n> > AWS CloudWatch compatible API\n> >\n> >\n> >\n> > > > > I\'m working for Synaps project that provides AWS CloudWatch\n> > > > > compatible API at Samsung SDS.\n> > > > > Currently, we have plan to open the project to the community.\n> > > > >\n> > > > > Here I introduce Synaps project:\n> > > > > http://wiki.openstack.org/Synaps\n> > > >\n> > > > Details are a bit scarce but at first glance there seem to be\n> > > > an\n> > > > overlap\n> > > > with the CloudWatch work in the Heat project ?\n> > >\n> > > There certainly seems to be from the description, but pretty hard\n> > > to\n> > > evaluate until we see some code ;)\n> >\n> > Yes, I would second that.\n> >\n> > Once the code is out the open, the community will be much better\n> > placed\n> > to judge which approach will make sense to concentrate efforts on.\n> >\n> > June Yi - are you planning on attending the design summit?\n> >\n> > Cheers,\n> > Eoghan\n> >\n> >\n> > > > Any chance the two groups could meet at the Design Summit next\n> > > > week\n> > > > and\n> > > > make sure we don\'t duplicate effort here ?\n> > > >\n> > > > Angus Saskeld has a session on CloudWatch in the Incubation\n> > > > room:\n> > > > http://openstacksummitfall2012.sched.org/event/60b0bcf1253efcb3dd72dff531d59d26\n> > >\n> > > Angus Salkeld and Steve Dake will be at the Summit and could\n> > > discuss,\n> > > also\n> > > possible overlap with metric collection in ceilometer (has been\n> > > discussed\n> > > previously).\n> > >\n> > > I have several questions which will be make/break for the heat\n> > > usage\n> > > of\n> > > Cloudwatch:\n> > >\n> > > - Is the metric collection secure/authenticated?\n> > > - Are metrics collected from the hypervisors or in-instance?\n> > > - Can service monitoring (in instance) metrics be collected?\n> > > - Is the API authenticated (ie via keystone ec2 credentials?)\n> > >\n> > > Many more questions, need to see code and evaluate if we could\n> > > use\n> > > this for\n> > > heat or if we continue with our own implementation.\n> > >\n> > > --\n> > > Steve Hardy\n> > > Red Hat Engineering, Cloud\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<14514393.878571349922171466.JavaMail.weblogic@epml01>',NULL),('<168265265.210.1366265511761.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-18 06:11:51',0,'2013-04-18 06:11:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-folsom #199','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/199/>\n\n------------------------------------------\n[...truncated 941 lines...]\n    test_policy_file_default_not_found                           OK    0.01\n    test_policy_file_specified_but_not_found                     OK    0.01\nTestStore\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_host_variations                                     OK    0.03\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.02\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.02\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: We test that the \'--respawn\' option causes the API server\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 161, in test_respawn\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \'Unexpected server launch status\' = self._formatMessage(\'Unexpected server launch status\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'Unexpected server launch status\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.17 secs:\n    14.07    TestScrubber.test_delayed_delete\n    13.71    TestGlanceControl.test_reload\n    13.50    TestGlanceControl.test_bouncing\n    12.56    TestApi.test_unsupported_default_store\n    11.32    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 465.985s\n\nFAILED (SKIP=106, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python27-stable-folsom-199\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.1.3\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Tegcni8YOz\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/199\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/199/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1682685572.229151378401039715.JavaMail.nobody@rsj2rmd004.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-09-05 17:10:39',0,'2013-09-05 17:10:39',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting\n	Occtober 3, 2013','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting Occtober 3, 2013\nHost: Alan Clark\nDate: Thursday, October 3, 2013\nTime: 9:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\nSession number: 923 270 538\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=237604132&UID=1675344187&HMAC=9a61e3cfbb34c14e1818c01fb6a4ca0bef9b9e98&RT=MiM0\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=237604132&EF=MA&UUID=1675344187&SHA2=UdmHbHfANGPitH8pPuCPI%2F1OL3ilWjjvnKNPbRGzE8o%3D&RT=MiM0\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=237604132&UID=1675344187&ORT=MiM0&HMAC=9a61e3cfbb34c14e1818c01fb6a4ca0bef9b9e98\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=237604132&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 923 270 538\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20130905/cf404f98/attachment.html>\n\n',NULL,NULL),('<16830CFC-3BC4-4E2E-88C6-5340C82625B2@cdl.asgaard.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-22 21:17:07',-25200,'2013-10-23 04:17:07',NULL,'[openstack-dev] Distributed Virtual Router Discussion','On 22 Oct 2013, at 18:02, Brian Haley wrote:\n\n> Hi Swami,\n>\n> I would like to participate as well.\n>\n> -Brian\n>\n\n+1\n\n\n> On 10/21/2013 12:18 PM, Vasudevan, Swaminathan (PNB Roseville) wrote:\n>> Hi Folks,\n>>\n>> I am currently working on a blueprint for Distributed Virtual Router.\n>>\n>> If anyone interested in being part of the discussion please let me know.\n>>\n>> I have put together a first draft of my blueprint and have posted it on\n>> Launchpad for review.\n>>\n>> https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr\n>>\n>>\n>>\n>>\n>>\n>> Thanks.\n>>\n>>\n>>\n>> Swaminathan Vasudevan\n>>\n>> Systems Software Engineer (TC)\n>>\n>>\n>>\n>>\n>>\n>> HP Networking\n>>\n>> Hewlett-Packard\n>>\n>> 8000 Foothills Blvd\n>>\n>> M/S 5541\n>>\n>> Roseville, CA - 95747\n>>\n>> tel: 916.785.0937\n>>\n>> fax: 916.785.1815\n>>\n>> email: swaminathan.vasudevan at hp.com <mailto:swaminathan.vasudevan at hp.com>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n--\n???\nCheck my PGP key here: http://www.asgaard.org/cdl/cdl.asc\nCurrent vCard here: http://www.asgaard.org/cdl/cdl.vcf\n\n\n','<5267200A.5020500@hp.com>',NULL),('<1683177313.19481443.1383304060386.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 07:07:40',-14400,'2013-11-01 11:07:40',NULL,'[openstack-dev] [nova] Closes-Bug and Launchpad','Hi Gary,\n\n\"Gary Kotton\" <gkotton at vmware.com> wrote:\n> Hi,\n> Over the last few days I have noticed that bug fixes posted to gerrit are not\n> updated in Launchpad. Am I doing something wrong? I think that the commit\n> message is the correct format: Closes-Bug: #<bug number>.\n> Any ideas?\n\nI\'ve seen the linking fail when the bug number is followed by a period.\n\nThat seems to match the regexp, if I\'m looking at the right place:\n\nhttps://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/update_bug.py#n250\n\nJulie\n\n> Thanks\n> Gary\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CE987F74.1E943%gkotton@vmware.com>',NULL),('<1683234933.5477262.1397564852641.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-15 08:27:32',-14400,'2014-04-15 12:27:32',NULL,'[openstack-dev] [tripleo] /bin/bash vs. /bin/sh','----- Original Message -----\n> From: \"Chris Jones\" <cmsj at tenshu.net>\n> To: openstack at nemebean.com, \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Sent: Monday, April 14, 2014 2:24:57 PM\n> Subject: Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh\n> \n> Hi\n> \n> Apart from special cases like the ramdisk\'s /init, which is a script that\n> needs to run in busybox\'s shell, everything should be using bash. There\'s no\n> point us tying ourselves in knots trying to achieve POSIX compliance for the\n> sake of it, when bashisms are super useful.\n\n+1 for the pragmatic approach.\n\n> \n> Cheers,\n> \n> Chris\n> \n> \n> On 14 April 2014 17:26, Ben Nemec < openstack at nemebean.com > wrote:\n> \n> \n> tldr: I propose we use bash explicitly for all diskimage-builder scripts (at\n> least for the short-term - see details below).\n> \n> This is something that was raised on my linting changes to enable set -o\n> pipefail. That is a bash-ism, so it could break in the diskimage-builder\n> scripts that are run using /bin/sh. Two possible fixes for that: switch to\n> /bin/bash, or don\'t use -o pipefail\n> \n> But I think this raises a bigger question - does diskimage-builder require\n> bash? If so, I think we should just add a rule to enforce that /bin/bash is\n> the shell used for everything. I know we have a bunch of bash-isms in the\n> code already, so at least in the short-term I think this is probably the way\n> to go, so we can get the benefits of things like -o pipefail and lose the\n> ambiguity we have right now. For reference, a quick grep of the\n> diskimage-builder source shows we have 150 scripts using bash explicitly and\n> only 24 that are plain sh, so making the code truly shell-agnostic is likely\n> to be a significant amount of work.\n> \n> In the long run it might be nice to have cross-shell compatibility, but if\n> we\'re going to do that I think we need a couple of things: 1) Someone to do\n> the work (I don\'t have a particular need to run dib in not-bash, so I\'m not\n> signing up for that :-) 2) Testing in other shells - obviously just changing\n> /bin/bash to /bin/sh doesn\'t mean we actually support anything but bash. We\n> really need to be gating on other shells if we\'re going to make a\n> significant effort to support them. It\'s not good to ask reviewers to try to\n> catch every bash-ism proposed in a change. This also relates to some of the\n> unit testing work that is going on right now too - if we had better unit\n> test coverage of the scripts we would be able to do this more easily.\n> \n> Thoughts?\n> \n> Thanks.\n> \n> -Ben\n> \n> ______________________________ _________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack. org\n> http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-dev\n> \n> \n> \n> --\n> Cheers,\n> \n> Chris\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHWFm4dBGzVLOp92AjBiE_zGdxBTCJ51AfTW4o+teAJYbKxu5w@mail.gmail.com>',NULL),('<1683957539.2.1376288988252.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-12 06:29:47',0,'2013-08-12 06:29:47',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/2/>\n\n------------------------------------------\n[...truncated 20997 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=6.03 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 6.035/6.035/6.035/0.000 ms\n++ cinder list\n++ get_field 2\n++ read data\n++ head -1\n++ grep ex-vol-0929bef8\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1376287857\n+ cinder create --display_name ex-vol-0929bef8 --display_description \'test volume: ex-vol-0929bef8\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-12T06:10:57.912583      |\n| display_description |     test volume: ex-vol-0929bef8     |\n|     display_name    |           ex-vol-0929bef8            |\n|          id         | 557852f3-d80d-425d-9e40-badce3051c49 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-0929bef8 | grep available; do sleep 1; done\'\n| 557852f3-d80d-425d-9e40-badce3051c49 | available | ex-vol-0929bef8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376287860\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-0929bef8\n++ get_field 1\n++ read data\n++ head -1\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 557852f3-d80d-425d-9e40-badce3051c49 | available | ex-vol-0929bef8 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=557852f3-d80d-425d-9e40-badce3051c49\n+ die_if_not_set 164 VOL_ID \'Failure retrieving volume ID for ex-vol-0929bef8\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1376287860\n+ nova volume-attach 386eb359-148e-465d-ba8b-9ad98d5dd388 557852f3-d80d-425d-9e40-badce3051c49 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 386eb359-148e-465d-ba8b-9ad98d5dd388 |\n| id       | 557852f3-d80d-425d-9e40-badce3051c49 |\n| volumeId | 557852f3-d80d-425d-9e40-badce3051c49 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-0929bef8 | grep in-use; do sleep 1; done\'\n| 557852f3-d80d-425d-9e40-badce3051c49 | in-use | ex-vol-0929bef8 |  1   |     None    |  False   | 386eb359-148e-465d-ba8b-9ad98d5dd388 |\n++ date +%s\n+ end_time=1376287865\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-0929bef8\n++ get_field -1\n++ head -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 557852f3-d80d-425d-9e40-badce3051c49 | in-use | ex-vol-0929bef8 |  1   |     None    |  False   | 386eb359-148e-465d-ba8b-9ad98d5dd388 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=386eb359-148e-465d-ba8b-9ad98d5dd388\n+ die_if_not_set 178 VOL_ATTACH \'Failure retrieving ex-vol-0929bef8 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ 386eb359-148e-465d-ba8b-9ad98d5dd388 != 386eb359-148e-465d-ba8b-9ad98d5dd388 ]]\n++ date +%s\n+ start_time=1376287865\n+ nova volume-detach 386eb359-148e-465d-ba8b-9ad98d5dd388 557852f3-d80d-425d-9e40-badce3051c49\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-0929bef8 | grep available; do sleep 1; done\'\n| 557852f3-d80d-425d-9e40-badce3051c49 | available | ex-vol-0929bef8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376287869\n+ echo \'Completed volume-detach in 4 seconds\'\nCompleted volume-detach in 4 seconds\n++ date +%s\n+ start_time=1376287869\n+ cinder delete 557852f3-d80d-425d-9e40-badce3051c49\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-0929bef8; do sleep 1; done\'\n| 557852f3-d80d-425d-9e40-badce3051c49 | deleting | ex-vol-0929bef8 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376287872\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 386eb359-148e-465d-ba8b-9ad98d5dd388\n+ timeout 60 sh -c \'while nova list | grep -q 386eb359-148e-465d-ba8b-9ad98d5dd388; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1553.gf722050.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpbHLlWo\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpPz7Mxr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpsxZHEQ\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpMfFIxH\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 28, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2456 tests in 1050.253s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/rabbitmq/rabbit at devstack-1376286105-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/rabbitmq/rabbit at devstack-1376286105.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-6749/2/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1132827071.16.1375943359028.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1684659234.286.1356912491703.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-31 00:08:11',0,'2012-12-31 00:08:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #91','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/91/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.99 secs:\n    2.77    Kc11TestCase.test_admin_requires_adminness\n    2.37    KcEssex3TestCase.test_admin_requires_adminness\n    2.26    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 48.619s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b3\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.10.0\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.Om1tk9WwS2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/91\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/91/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<75432543.269.1356826114423.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<168465951.91.1383719636550.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-06 06:33:56',0,'2013-11-06 06:33:56',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #42','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/42/>\n\n------------------------------------------\n[...truncated 21263 lines...]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_member_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Skipped until Bug: 1157349 is resolved.\'\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until Bug: 1205344 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  186.794\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          124.302\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  52.605\ntempest.api.volume.test_volumes_actions.VolumesActionsTestXML.test_volume_upload[gate,image]                             50.694\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         41.751\ntempest.api.compute.servers.test_server_actions.ServerActionsTestXML.test_resize_server_revert[gate]                     36.942\ntempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload[gate,image]                                36.909\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     36.300\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    35.468\ntempest.api.compute.servers.test_servers.ServersTestXML.test_create_with_existing_server_name[gate]                      34.555\n\n----------------------------------------------------------------------\nRan 1439 tests in 1457.439s\n\nOK (skipped=70)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-636151-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-636151.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-636151/42/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1674071106.83.1383633240672.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<168496F1-BC82-4A25-83FD-297BD14FE81C@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 15:26:30',0,'2014-08-13 15:26:30',NULL,'[openstack-dev] [Infra] Minesweeper behaving badly','Thanks very much Jeremy for getting us back up and running again. Without a doubt, we will be triggering directly from the CI system itself next time the need to do a mass recheck arises. The lesson was learned seconds after the script was run!\n\nAgain, my sincere apologies for all the havoc that was caused yesterday.\n\nRegards,\nRyan\n\nOn Aug 13, 2014, at 7:38 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:\n\n> On 2014-08-13 02:40:28 +0200 (+0200), Salvatore Orlando wrote:\n> [...]\n>> The problem has now been fixed, and once the account will be\n>> re-enabled, rechecks should be issued with the command\n>> \"vmware-recheck\".\n> [...]\n> \n> Oh, I meant to add that I\'ve reenabled the account now. Thanks for\n> the rapid response when it was brought to your attention!\n> -- \n> Jeremy Stanley\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<20140813143825.GF1251@yuggoth.org>',NULL),('<1685003813.8.1379398363564.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-17 06:12:43',0,'2013-09-17 06:12:43',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-grizzly #20','See <https://jenkins01.openstack.org/job/periodic-nova-python26-stable-grizzly/20/>\n\n\n\n','<1322220835.0.1379139084201.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1685367801.86.1384064025203.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-10 06:13:45',0,'2013-11-10 06:13:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #53','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/53/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x57bbd10>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5266c50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5266c50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-9e2f2c90-bf92-4d9b-9b58-c7a4c4f33b95\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x32bdcf8> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x32bdcf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x32bdcf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x32bdcf8>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:13:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:13:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:13:02+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:13:02-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'02\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:13:02Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'02\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x64d78d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1f69b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.62 secs:\n    26.46    TestScrubber.test_scrubber_app\n    20.82    TestScrubber.test_delayed_delete\n    14.94    TestRootApi.test_version_configurations\n    14.88    TestGlanceControl.test_reload\n    14.52    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 652.133s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.16.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.53\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.OM40nGpmL4\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/53/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-3/53\n[SCP] Copying console log.\n\n\n','<347759825.82.1383977455958.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<16853745-189C-48C9-963B-395B91CEBE6C@raseley.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-07 10:03:46',-28800,'2014-03-07 18:03:46',NULL,'[Openstack] Companies Offering Paid Support?','Adam,\n\nDepending on what specific technologies you?re deploying, I would recommend reaching out to the folks at hastexo (http://www.hastexo.com). Florian, Martin, Andreas, and company are very knowledgable (and active) within the OpenStack space.\n\nRegards,\n\nRichard\n\nOn Mar 7, 2014, at 9:53, Adam Lawson <alawson at aqorn.com> wrote:\n\n> Are there any companies offering subscription or incident-based OpenStack support for private clouds that aren\'t using a specific packaged distro such as Piston, CloudScaling, StackOps or Fuel?\n> \n> Just wondering if there are companies that will help someone get through a problem or assist them with a manual-installed special deployment like a standalone HA Swift cluster or some other config that doesn\'t necessarily fit into the default mold.\n> \n> Are there companies doing this? I have only found Rackspace and waiting for pricing/confirmation of their service. Just wondering if there is anyone else doing this?\n> \n> \n> Adam Lawson\n> AQORN, Inc.\n> 427 North Tatnall Street\n> Ste. 58461\n> Wilmington, Delaware 19801-2230\n> Toll-free: (888) 406-7620\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140307/6f76aa3b/attachment.pgp>\n\n','<CAJfWK49R0GabsSvnPkdg+Jj=9BwEuOss-AW9+OiPX7pHriys6A@mail.gmail.com>',NULL),('<16853745-189C-48C9-963B-395B91CEBE6C@raseley.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-07 10:03:46',-28800,'2014-03-07 18:03:46',NULL,'[Openstack-operators] [Openstack] Companies Offering Paid\n	Support?','Adam,\n\nDepending on what specific technologies you?re deploying, I would recommend reaching out to the folks at hastexo (http://www.hastexo.com). Florian, Martin, Andreas, and company are very knowledgable (and active) within the OpenStack space.\n\nRegards,\n\nRichard\n\nOn Mar 7, 2014, at 9:53, Adam Lawson <alawson at aqorn.com> wrote:\n\n> Are there any companies offering subscription or incident-based OpenStack support for private clouds that aren\'t using a specific packaged distro such as Piston, CloudScaling, StackOps or Fuel?\n> \n> Just wondering if there are companies that will help someone get through a problem or assist them with a manual-installed special deployment like a standalone HA Swift cluster or some other config that doesn\'t necessarily fit into the default mold.\n> \n> Are there companies doing this? I have only found Rackspace and waiting for pricing/confirmation of their service. Just wondering if there is anyone else doing this?\n> \n> \n> Adam Lawson\n> AQORN, Inc.\n> 427 North Tatnall Street\n> Ste. 58461\n> Wilmington, Delaware 19801-2230\n> Toll-free: (888) 406-7620\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140307/6f76aa3b/attachment.pgp>\n\n','<CAJfWK49R0GabsSvnPkdg+Jj=9BwEuOss-AW9+OiPX7pHriys6A@mail.gmail.com>',NULL),('<1685449534.33139412.1387281520020.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-17 11:58:40',0,'2013-12-17 11:58:40',NULL,'[openstack-dev] [horizon] Blueprint\n	decrypt-and-display-vm-generated-password','Hi all,\n\nI would like to get your opinion/feedback about the implementation of the blueprint \"Decrypt and display VM generated password\"[1]\n\nOur use case is primarily targeting Windows instances with cloudbase-init, but the functionality can be also used on Linux instances.\nThe general idea of this blueprint is to give the user the ability to retrieve, through Horizon, administrative password for his Windows session.\n\nThere is two ways for the user to set/get his password on cloudbase-init Windows instances:\n- The user sets the desired password as admin_pass key/value as metadata of the new server. Example : https://gist.github.com/arezmerita/8001673. In this case the password is visible in instance description, in metatada section. \n- The user do not set his password. In this case the cloudbase-init will generate a random password, encrypt it with user provided public key, and will send the result to the metadata server. The only way to get the clear password is to use API/nova client and provide the private key. Example:  nova get-password  . The novaclient will retrieve encrypted password from Nova and will use locally the private key in order to decrypt the password. \n\nNow about our blueprint implementation: \n- We add an new action \"Retrieve password\" on an instance, that shows a form displaying the key pair name used to boot the instance and the encrypted password. The user can provide its private key, that will be used ONLY on the client side for password decryption using JSEncrypt library[2]. \n- We choose to not send the private key over the network (for decryption on server side), because we consider that the user should not be forced to share this information with the cloud operator.\nSome may argue that the connection is protected, and we are already passing sensitive data over the network. However, openstack user password/tokens are \"openstack\" sensitive data, they are related to the \"openstack\" user. User\'s private key on the other hand, is something personal to the user, \"not-openstack\" related.\n\nWhat do you think?  \n\nNote: On the whiteboard of the blueprint[1] I provided two demos and some instructions of how to test this functionality with Linux instances.\n\nThanks,\n\nReferences: \n[1] https://blueprints.launchpad.net/horizon/+spec/decrypt-and-display-vm-generated-password\n[2] JSEncrypt library http://travistidwell.com/jsencrypt/\n\n\nAla Rezmerita\nSoftware Engineer || Cloudwatt\nM: (+33) 06 77 43 23 91\nImmeuble Etik\n892 rue Yves Kermen\n92100 Boulogne-Billancourt ? France\n\n\n\n','<1773899190.33138665.1387281421736.JavaMail.root@cloudwatt.com>',NULL),('<1685929129.6596389.1390415961422.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-22 13:39:21',-18000,'2014-01-22 18:39:21',NULL,'[openstack-dev] [TripleO] our update story: can people live with it?','Clint wrote:\n> I would call your e-mail a documentation/roadmap bug. This plan may\n> have been recorded somewhere, but for me it has just always been in my\n> head as the end goal (thanks to Robert Collins for drilling the hole\n> and pouring it in there btw ;).\n\nI found the following links helpful in getting a better idea of how updates could work:\n\nhttps://etherpad.openstack.org/p/tripleo-image-updates\nhttps://github.com/openstack/tripleo-incubator/blob/master/scripts/takeovernode\n\n/hat-tip to lifeless for the pointers.\n\nCheers\nCharles\n\n\n','<2044467905.6593217.1390415803593.JavaMail.root@redhat.com>',NULL),('<1685E8A3-EB46-4070-BF4A-0BF0302BDC5B@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-26 12:19:46',-25200,'2013-10-26 19:19:46',NULL,'[openstack-dev] [nova] Thoughs please on how to address\n	a	problem with mutliple deletes leading to a\n	nova-compute	thread pool problem','This is a bit off topic , but in general it seems to me that the state transitions as you said are not clearly defined for many openstack components. Is there any effort underway to define these? As the software gets bigger and bigger this will help both developers and operators.\n\nThanks & Regards\nAbhishek Lahiri\n\nOn Oct 26, 2013, at 9:52 AM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n\n> Potentially,\n> \n> Although I think the lack of formalization and visibility (and the ability to easily change its transitions) into the state machine is at this point causing part of this pain.\n> \n> If the state machine was well defined (and adjustable - to a degree...) then you could imagine only allowing delete transitions from the powered off state while another deployer may prefer a more \"experimental\" allow delete transition at any time (with associated side effects).\n> \n> Without the underlying state machine being in a more formalized state it\'s hard to do either in a manageable (and recoverable & resumable...) manner IMHO.\n> \n> Sent from my really tiny device...\n> \n> On Oct 26, 2013, at 9:12 AM, \"Abhishek Lahiri\" <aviostack at gmail.com> wrote:\n> \n>> Deletes should only be allowed when the vm is in a power off state. This will allow consistent state transition.\n>> \n>> Thanks\n>> Al\n>> \n>> \n>> On Oct 26, 2013, at 8:55 AM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:\n>> \n>>> I think I will try to have a unconference at the HK summit about ideas the cinder developers (and the taskflow developers, since it\'s not a concept that is unique /applicable to just cinder) are having about said state machine (and it\'s potential usage).\n>>> \n>>> So look out for that, be interesting to have some nova folks involved there also :-)\n>>> \n>>> Sent from my really tiny device...\n>>> \n>>> On Oct 26, 2013, at 3:14 AM, \"Alex Glikson\" <GLIKSON at il.ibm.com> wrote:\n>>> \n>>>> +1 \n>>>> \n>>>> Regards, \n>>>> Alex \n>>>> \n>>>> \n>>>> Joshua Harlow <harlowja at yahoo-inc.com> wrote on 26/10/2013 09:29:03 AM:\n>>>> > \n>>>> > An idea that others and I are having for a similar use case in \n>>>> > cinder (or it appears to be similar).\n>>>> > \n>>>> > If there was a well defined state machine/s in nova with well \n>>>> > defined and managed transitions between states then it seems like \n>>>> > this state machine could resume on failure as well as be interrupted\n>>>> > when a \"dueling\" or preemptable operation arrives (a delete while \n>>>> > being created for example). This way not only would it be very clear\n>>>> > the set of states and transitions but it would also be clear how \n>>>> > preemption occurs (and under what cases). \n>>>> > \n>>>> > Right now in nova there is a distributed and ad-hoc state machine \n>>>> > which if it was more formalized it could inherit some if the \n>>>> > described useful capabilities. It would also be much more resilient \n>>>> > to these types of locking problems that u described. \n>>>> > \n>>>> > IMHO that\'s the only way these types of problems will be fully be \n>>>> > fixed, not by more queues or more periodic tasks, but by solidifying\n>>>> > & formalizing the state machines that compose the work nova does.\n>>>> > \n>>>> > Sent from my really tiny device...\n>>>> > \n>>>> > > On Oct 25, 2013, at 3:52 AM, \"Day, Phil\" <philip.day at hp.com> wrote:\n>>>> > > \n>>>> > > Hi Folks,\n>>>> > > \n>>>> > > We\'re very occasionally seeing problems where a thread processing \n>>>> > a create hangs (and we\'ve seen when taking to Cinder and Glance).  \n>>>> > Whilst those issues need to be hunted down in their own rights, they\n>>>> > do show up what seems to me to be a weakness in the processing of \n>>>> > delete requests that I\'d like to get some feedback on.\n>>>> > > \n>>>> > > Delete is the one operation that is allowed regardless of the \n>>>> > Instance state (since it\'s a one-way operation, and users should \n>>>> > always be able to free up their quota).   However when we get a \n>>>> > create thread hung in one of these states, the delete requests when \n>>>> > they hit the manager will also block as they are synchronized on the\n>>>> > uuid.   Because the user making the delete request doesn\'t see \n>>>> > anything happen they tend to submit more delete requests.   The \n>>>> > Service is still up, so these go to the computer manager as well, \n>>>> > and eventually all of the threads will be waiting for the lock, and \n>>>> > the compute manager will stop consuming new messages.\n>>>> > > \n>>>> > > The problem isn\'t limited to deletes - although in most cases the \n>>>> > change of state in the API means that you have to keep making \n>>>> > different calls to get past the state checker logic to do it with an\n>>>> > instance stuck in another state.   Users also seem to be more \n>>>> > impatient with deletes, as they are trying to free up quota for other things. \n>>>> > > \n>>>> > > So while I know that we should never get a thread into a hung \n>>>> > state into the first place, I was wondering about one of the \n>>>> > following approaches to address just the delete case:\n>>>> > > \n>>>> > > i) Change the delete call on the manager so it doesn\'t wait for \n>>>> > the uuid lock.  Deletes should be coded so that they work regardless\n>>>> > of the state of the VM, and other actions should be able to cope \n>>>> > with a delete being performed from under them.  There is of course \n>>>> > no guarantee that the delete itself won\'t block as well. \n>>>> > > \n>>>> > > ii) Record in the API server that a delete has been started (maybe\n>>>> > enough to use the task state being set to DELETEING in the API if \n>>>> > we\'re sure this doesn\'t get cleared), and add a periodic task in the\n>>>> > compute manager to check for and delete instances that are in a \n>>>> > \"DELETING\" state for more than some timeout. Then the API, knowing \n>>>> > that the delete will be processes eventually can just no-op any \n>>>> > further delete requests.\n>>>> > > \n>>>> > > iii) Add some hook into the ServiceGroup API so that the timer \n>>>> > could depend on getting a free thread from the compute manager pool \n>>>> > (ie run some no-op task) - so that of there are no free threads then\n>>>> > the service becomes down. That would (eventually) stop the scheduler\n>>>> > from sending new requests to it, and make deleted be processed in \n>>>> > the API server but won\'t of course help with commands for other \n>>>> > instances on the same host.\n>>>> > > \n>>>> > > iv) Move away from having a general topic and thread pool for all \n>>>> > requests, and start a listener on an instance specific topic for \n>>>> > each running instance on a host (leaving the general topic and pool \n>>>> > just for creates and other non-instance calls like the hypervisor \n>>>> > API).   Then a blocked task would only affect request for a specificinstance.\n>>>> > > \n>>>> > > I\'m tending towards ii) as a simple and pragmatic solution in the \n>>>> > near term, although I like both iii) and iv) as being both generally\n>>>> > good enhancments - but iv) in particular feels like a pretty seismic change.\n>>>> > > \n>>>> > > Thoughts please,\n>>>> > > \n>>>> > > Phil        \n>>>> > > \n>>>> > > _______________________________________________\n>>>> > > OpenStack-dev mailing list\n>>>> > > OpenStack-dev at lists.openstack.org\n>>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> > \n>>>> > _______________________________________________\n>>>> > OpenStack-dev mailing list\n>>>> > OpenStack-dev at lists.openstack.org\n>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>> >\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131026/91f191aa/attachment.html>\n\n','<188C3DE6-2C4F-4566-BCCE-6E02B38F7B27@yahoo-inc.com>',NULL),('<1687203806.13.1376981046983.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-20 06:44:06',0,'2013-08-20 06:44:06',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #11','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/11/>\n\n------------------------------------------\n[...truncated 19118 lines...]\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_container_object_without_using_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_object_with_another_user_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_create_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_metadata[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_object_without_using_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_with_another_user_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_version.ContainerTest.test_versioned_container[smoke] ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[smoke] ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 824 tests in 1614.883s\n\nOK (SKIP=73)\nfull runtests: commands[1] | nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\nWARNING:test command found but not installed in testenv\n  cmd: /usr/local/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/full\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... SKIP: version is empty, bug 1138844\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 45, in test_admin_catalog_list\n    self.assertTrue(svc[\'__label\'].startswith(\'Service:\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-20 06:42:58,031 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   catalog \'\n2013-08-20 06:42:58,471 Invalid line between tables: Service: compute\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 93, in test_admin_help\n    self.assertTrue(lines[0].startswith(\'usage: keystone\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-20 06:43:00,461 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   help \'\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-cli.xml\n----------------------------------------------------------------------\nRan 54 tests in 34.457s\n\nFAILED (SKIP=4, failures=2)\nERROR: InvocationError: \'/usr/local/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\'\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-137854-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-137854.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az2-137854/11/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1937299953.8.1376894252390.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1687494964.20.1370931177231.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-11 06:12:57',0,'2013-06-11 06:12:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #253','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/253/>\n\n------------------------------------------\n[...truncated 947 lines...]\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.02\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.20\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.02\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.02\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: Test that we notice when our log file has been rotated\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_logging.py\",> line 95, in test_logrotate\n    response, content = httplib2.Http().request(path, \'GET\')\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1290, in _conn_request\n    conn.connect()\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 73.75 secs:\n    15.80    TestGlanceControl.test_reload\n    15.55    TestGlanceControl.test_bouncing\n    14.70    TestScrubber.test_delayed_delete\n    13.99    TestGlanceControl.test_respawn\n    13.71    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 582.134s\n\nFAILED (SKIP=89, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.11\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-253\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.10\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.puxH0ndWXn\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/253\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/253/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1688877117.60184473.1364367157381.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-27 02:52:37',-14400,'2013-03-27 06:52:37',NULL,'[openstack-dev] [Glance] Proposal to add Flavio Percoco Premoli\n to	Glance Core','\nA hearty +1 :)\n\nCheers,\nEoghan\n\n> Hi folks,\n> \n> I\'d like to propose adding Flavio Percoco Premoli (flaper87) to the\n> glance-core team.\n> \n> https://review.openstack.org/#/dashboard/6159\n> \n> Flavio has been contributing heavily to glance reviews and bugfixes,\n> and working on several important new features.\n> \n> Please respond with comments, +1s, or objections within one week.\n> \n> Thanks!\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAJyP2C-uwcRFFeh4S=Mz3K5vVLvWxG3Zk2hgHQ2w4xT4f65LLA@mail.gmail.com>',NULL),('<1689915437.2903882.1353071902834.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-16 08:18:22',-18000,'2012-11-16 13:18:22',NULL,'[openstack-dev] [ceilometer] The periodic task on openstack','\n> > A follow-up for your discussion on IRC last night, I had a quick\n> > check of the loopingcall implementation, and seems there is really\n> > no time gurantee. Even if we adjust the interval for\n> > greenthread.sleep() dynamically, we also must make the metering\n> > periodic task always at the head.\n> > \n> > I think we can enhance the periodic task to meet partially our\n> > requirement, like create a separated task type as high-priority,\n> > which should make sure no long-delay.\n> > \n> > The only concern is, can we make sure the LoopingCall itself will\n> > be invoked on time after the greenthread.sleep(interval),\n> > considering the attribute of greenthread, or even python thread.\n> > \n> > openstack/common/loopingcall.py-> LoopingCall(object):\n> > \n> >                 while self._running:\n> >                     self.f(*self.args, **self.kw)\n> >                     if not self._running:\n> >                         break\n> >                     greenthread.sleep(interval)\n\nThanks for following this up!\n\nSo can I confirm that I\'ve understood the basic issues here are\nthat:\n\n (a) The time spent executing tasks is not accounted for when\n     determining how much time to sleep between task runs. So\n     for example if periodic_interval is set to N seconds, the\n     actual time between tasks is of the order of:\n\n       N + \\Sigma duration(task_i)/(1 + ticks for task_i)\n\n     The more tasks with ticks=0, and the longer the task\n     duration, the more we skew away from tasks executing on \n     wall-clock boundaries. \n\n (b) There is no guarantee (beyond convention) that a task won\'t\n     take longer than periodic_interval/|tasks| to execute.\n\n (c) There is an indeterminate lag after the expiry of the sleep \n     interval before the LoopingCall thread is re-scheduled.\n\nSo could we at least address issue (a) by simply subtracting\nthe duration of the last tasks run from the next sleep interval?\n\ne.g. change LoopingCall.start()._inner() as follows:\n\n    while self._running:\n+       start = datetime.datetime.now()\n        self.f(*self.args, **self.kw)\n+       end = datetime.datetime.now()\n+       delta = end - start\n+       elapsed = delta.seconds + delta.microseconds/(10 ** 6)\n+       delay = interval - elapsed\n        if not self._running:\n            break\n-       greenthread.sleep(interval)\n+       greenthread.sleep(delay if delay > 0 else 0)\n\nI guess that\'s what you meant by adjusting the interval dynamically?\n\nBut I\'m not sure that we can always address (b) or (c) even with a\nspecial thread for high-priority/time-sensitive tasks.\n\nCheers,\nEoghan\n\n\n','<DDCAE26804250545B9934A2056554AA0349F41@SHSMSX101.ccr.corp.intel.com>',NULL),('<1690861817.35461824.1402774841448.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-14 15:40:41',-14400,'2014-06-14 19:40:41',NULL,'[Openstack] flavor extra_specs','----- Original Message -----\n> From: \"Tiago Sousa\" <tiagu.asp at gmail.com>\n> To: \"Anne Gentle\" <anne at openstack.org>\n> \n> Thanks for the feedback,\n> \n> but that was the info that i also found on the documentation\n> \n> i was looking for more/other information, namely how to add a serial port\n> to a flavor.\n> \n> Cumprimentos,\n> Tiago Sousa\n\nHi Tiago,\n\nThere isn\'t to my knowledge any support within Nova for adding a serial port to an instance today (without hacking Nova directly yourself, anyway), there is a blueprint [1] and a related design specification [2] proposing such functionality be added available for review.\n\nThanks,\n\nSteve\n\n[1] https://blueprints.launchpad.net/nova/+spec/serial-ports\n[2] https://review.openstack.org/#/c/86418/\n\n\n','<CAO2b7Qxa181QS3KMVMTev6v9kGXH6aQeKi4_48wb87=i9B1o_w@mail.gmail.com>',NULL),('<16916FA1-BECC-4350-8EDD-CB1800DDBD26@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-02-06 23:58:35',0,'2013-02-06 23:58:35',NULL,'[openstack-dev] \"Changing\" an API','It\'s all about balance.  If \"wild-west\" style extensions turn into \"wild-west\" style core API changes, then we\'re in really bad shape.\n\nKeep in mind that a client may have to live in an environment where it has to interact with multiple deployments with different versions and different set of extensions etc.\n\nWe talked a lot about versioning on the list.  There were a lot of really good ideas thrown out there.  \n\nWe\'ve also talked about having extensions in the default / unprefixed namespace so that they look like new core features but can be detected at runtime.\n\nIn my opinion the fundamental principles that we need to stick to are:\n\n1.  The core contract should be strict and implemented / supported by all environments.\n2.  New features, should not be incompatible with the core contract.\n3.  New features should be detectable -- ie because they are extensions.\n4.  New features should not collide with each other.  For example if HP introduces a password reset feature in keystone and RAX introduces a password reset features that doesn\'t work the same way then those two should not interfere with each other (so there are cases where we should use prefixing).\n5.  The PTL has the right to promote any extension so that it doesn\'t need to be prefixed, but should track what these are, and thus should control the non-prefixed (default) namespace.\n\nIn my opinion we don\'t need versioning unless we have a change that is truly incompatible with the core contract. And honestly I would avoid these sort of changes.  Instead I\'d rather have changes in the default (non-prefixed) namespace, that are detectible at runtime.  And have all of these changes be compatible with the core.  This to me is a much smoother than have folks rewrite to a new API version frequently -- you can consume new features as is, when you detect them.\n\n\n-jOrGe W.\n\n\nOn Feb 6, 2013, at 5:39 PM, Gabriel Hurley wrote:\n\n> Something\'s been bothering me for a long time about the way OpenStack handles its APIs... There\'s a firmly-rooted idea in this community that touching a published API in any way, shape or form requires a complete API major-version revision.\n> \n> That\'s how you halt progress. That\'s how you never fix problems.\n> \n> \n> To basic principles: why do we version APIs? To prevent incompatibilities. What causes an incompatibility? Changing key names, changing routes, changing methods, changing required or positional arguments, or changing the data type of values. Doing those things requires an API rev.\n> \n> You know what\'s not incompatible? Adding additional non-conflicting data, and adding additional capabilities via query parameters. Those types of changes can be done with no impact on anything other than the strictest XML schema validators. To be polite you do a minor version bump so that consumers can identify specifically when a certain piece of data or capability became available.\n> \n> \n> But this idea that the APIs can never be touched has to stop. It\'s caused an explosion of \"wild west\"-style extensions in Nova that are unversioned unpoliced workarounds and hacks. It\'s caused features in Keystone and Glance to be delayed by one or more full releases.\n> \n> \n> I submit that the process is broken and we as a community need to embrace incremental API revisions to make our APIs worth using, \'cuz frankly right now they\'re a mess.\n> \n> \n> Sorry for the tirade,\n> \n>    - Gabriel\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<BD35DBE010D5B64589500D43F775F23643913568@CH1PRD0511MB431.namprd05.prod.outlook.com>',NULL),('<1691827112.54.1383373697839.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-02 06:28:17',0,'2013-11-02 06:28:17',NULL,'[openstack-qa] Jenkins build became unstable:\n periodic-tempest-devstack-vm-all #44','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/44/>\n\n\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1692089521.22394467.1408600942280.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-21 02:02:22',-14400,'2014-08-21 06:02:22',NULL,'[openstack-dev] [neutron]Performance of security group','Thank you shihanzhang!,\n\nI can\'t believe I didn\'t realize the ipset part spec was accepted I live\non my own bubble... I will be reviewing and testing/helping on that part \ntoo during the next few days,  I was too concentrated in the RPC part.\n\n\nBest regards,\n\n----- Original Message -----\n> hi neutroner!\n> my patch about BP:\n> https://blueprints.launchpad.net/openstack/?searchtext=add-ipset-to-security\n> need install ipset in devstack, I have commit the patch:\n> https://review.openstack.org/#/c/113453/, who can help me review it, thanks\n> very much!\n> \n> Best regards,\n> shihanzhang\n> \n> \n> \n> \n> At 2014-08-21 10:47:59, \"Martinx - ?????\" <thiagocmartinsc at gmail.com> wrote:\n> \n> \n> \n> +1 \"NFTablesDriver\"!\n> \n> Also, NFTables, AFAIK, improves IDS systems, like Suricata, for example:\n> https://home.regit.org/2014/02/suricata-and-nftables/\n> \n> Then, I\'m wondering here... What benefits might come for OpenStack Nova /\n> Neutron, if it comes with a NFTables driver, instead of the current\n> IPTables?!\n> \n> * E fficient Security Group design?\n> * Better FWaaS, maybe with NAT(44/66) support?\n> * Native support for IPv6, with the defamed NAT66 built-in, simpler \"Floating\n> IP\" implementation, for both v4 and v6 networks under a single\n> implementation ( I don\'t like NAT66, I prefer a `routed Floating IPv6`\n> version ) ?\n> * Metadata over IPv6 still using NAT(66) ( I don\'t like NAT66 ), single\n> implementation?\n> * Suricata-as-a-Service?!\n> \n> It sounds pretty cool! :-)\n> \n> \n> On 20 August 2014 23:16, Baohua Yang < yangbaohua at gmail.com > wrote:\n> \n> \n> \n> Great?\n> We met similar problems.\n> The current mechanisms produce too many iptables rules, and it\'s hard to\n> debug.\n> Really look forward to seeing a more efficient security group design.\n> \n> \n> On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery < mestery at noironetworks.com >\n> wrote:\n> \n> \n> \n> On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang < ayshihanzhang at 126.com > wrote:\n> > \n> > With the deployment \'nova + neutron + openvswitch\', when we bulk create\n> > about 500 VM with a default security group, the CPU usage of neutron-server\n> > and openvswitch agent is very high, especially the CPU usage of openvswitch\n> > agent will be 100%, this will cause creating VMs failed.\n> > \n> > With the method discussed in mailist:\n> > \n> > 1) ipset optimization ( https://review.openstack.org/#/c/100761/ )\n> > \n> > 3) sg rpc optimization (with fanout)\n> > ( https://review.openstack.org/#/c/104522/ )\n> > \n> > I have implement these two scheme in my deployment, when we again bulk\n> > create about 500 VM with a default security group, the CPU usage of\n> > openvswitch agent will reduce to 10%, even lower than 10%, so I think the\n> > iprovement of these two options are very efficient.\n> > \n> > Who can help us to review our spec?\n> > \n> This is great work! These are on my list of things to review in detail\n> soon, but given the Neutron sprint this week, I haven\'t had time yet.\n> I\'ll try to remedy that by the weekend.\n> \n> Thanks!\n> Kyle\n> \n> > Best regards,\n> > shihanzhang\n> > \n> > \n> > \n> > \n> > \n> > At 2014-07-03 10:08:21, \"Ihar Hrachyshka\" < ihrachys at redhat.com > wrote:\n> >>-----BEGIN PGP SIGNED MESSAGE-----\n> >>Hash: SHA512\n> >> \n> >>Oh, so you have the enhancement implemented? Great! Any numbers that\n> >>shows how much we gain from that?\n> >> \n> >>/Ihar\n> >> \n> >>On 03/07/14 02:49, shihanzhang wrote:\n> >>> Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today\n> >>> I will modify my spec, when the spec is approved, I will commit the\n> >>> codes as soon as possilbe!\n> >>> \n> >>> \n> >>> \n> >>> \n> >>> \n> >>> At 2014-07-02 10:12:34, \"Miguel Angel Ajo\" < majopela at redhat.com >\n> >>> wrote:\n> >>>> \n> >>>> Nice Shihanzhang,\n> >>>> \n> >>>> Do you mean the ipset implementation is ready, or just the\n> >>>> spec?.\n> >>>> \n> >>>> \n> >>>> For the SG group refactor, I don\'t worry about who does it, or\n> >>>> who takes the credit, but I believe it\'s important we address\n> >>>> this bottleneck during Juno trying to match nova\'s scalability.\n> >>>> \n> >>>> Best regards, Miguel ?ngel.\n> >>>> \n> >>>> \n> >>>> On 07/02/2014 02:50 PM, shihanzhang wrote:\n> >>>>> hi Miguel ?ngel and Ihar Hrachyshka, I agree with you that\n> >>>>> split the work in several specs, I have finished the work (\n> >>>>> ipset optimization), you can do \'sg rpc optimization (without\n> >>>>> fanout)\'. as the third part(sg rpc optimization (with fanout)),\n> >>>>> I think we need talk about it, because just using ipset to\n> >>>>> optimize security group agent codes does not bring the best\n> >>>>> results!\n> >>>>> \n> >>>>> Best regards, shihanzhang.\n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> At 2014-07-02 04:43:24, \"Ihar Hrachyshka\" < ihrachys at redhat.com >\n> >>>>> wrote:\n> >>> On 02/07/14 10:12, Miguel Angel Ajo wrote:\n> >>> \n> >>>> Shihazhang,\n> >>> \n> >>>> I really believe we need the RPC refactor done for this cycle,\n> >>>> and given the close deadlines we have (July 10 for spec\n> >>>> submission and July 20 for spec approval).\n> >>> \n> >>>> Don\'t you think it\'s going to be better to split the work in\n> >>>> several specs?\n> >>> \n> >>>> 1) ipset optimization (you) 2) sg rpc optimization (without\n> >>>> fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you\n> >>>> , me)\n> >>> \n> >>> \n> >>>> This way we increase the chances of having part of this for the\n> >>>> Juno cycle. If we go for something too complicated is going to\n> >>>> take more time for approval.\n> >>> \n> >>> \n> >>> I agree. And it not only increases chances to get at least some of\n> >>> those highly demanded performance enhancements to get into Juno,\n> >>> it\'s also \"the right thing to do\" (c). It\'s counterproductive to\n> >>> put multiple vaguely related enhancements in single spec. This\n> >>> would dim review focus and put us into position of getting\n> >>> \'all-or-nothing\'. We can\'t afford that.\n> >>> \n> >>> Let\'s leave one spec per enhancement. @Shihazhang, what do you\n> >>> think?\n> >>> \n> >>> \n> >>>> Also, I proposed the details of \"2\", trying to bring awareness\n> >>>> on the topic, as I have been working with the scale lab in Red\n> >>>> Hat to find and understand those issues, I have a very good\n> >>>> knowledge of the problem and I believe I could make a very fast\n> >>>> advance on the issue at the RPC level.\n> >>> \n> >>>> Given that, I\'d like to work on this specific part, whether or\n> >>>> not we split the specs, as it\'s something we believe critical\n> >>>> for neutron scalability and thus, *nova parity*.\n> >>> \n> >>>> I will start a separate spec for \"2\", later on, if you find it\n> >>>> ok, we keep them as separate ones, if you believe having just 1\n> >>>> spec (for 1 & 2) is going be safer for juno-* approval, then we\n> >>>> can incorporate my spec in yours, but then\n> >>>> \"add-ipset-to-security\" is not a good spec title to put all this\n> >>>> together.\n> >>> \n> >>> \n> >>>> Best regards, Miguel ?ngel.\n> >>> \n> >>> \n> >>>> On 07/02/2014 03:37 AM, shihanzhang wrote:\n> >>>>> \n> >>>>> hi Miguel Angel Ajo Pelayo! I agree with you and modify my\n> >>>>> spes, but I will also optimization the RPC from security group\n> >>>>> agent to neutron server. Now the modle is\n> >>>>> \'port[rule1,rule2...], port...\', I will change it to \'port[sg1,\n> >>>>> sg2..]\', this can reduce the size of RPC respose message from\n> >>>>> neutron server to security group agent.\n> >>>>> \n> >>>>> At 2014-07-01 09:06:17, \"Miguel Angel Ajo Pelayo\"\n> >>>>> < mangelajo at redhat.com > wrote:\n> >>>>>> \n> >>>>>> \n> >>>>>> Ok, I was talking with ?douard @ IRC, and as I have time to\n> >>>>>> work into this problem, I could file an specific spec for\n> >>>>>> the security group RPC optimization, a masterplan in two\n> >>>>>> steps:\n> >>>>>> \n> >>>>>> 1) Refactor the current RPC communication for\n> >>>>>> security_groups_for_devices, which could be used for full\n> >>>>>> syncs, etc..\n> >>>>>> \n> >>>>>> 2) Benchmark && make use of a fanout queue per security\n> >>>>>> group to make sure only the hosts with instances on a\n> >>>>>> certain security group get the updates as they happen.\n> >>>>>> \n> >>>>>> @shihanzhang do you find it reasonable?\n> >>>>>> \n> >>>>>> \n> >>>>>> \n> >>>>>> ----- Original Message -----\n> >>>>>>> ----- Original Message -----\n> >>>>>>>> @Nachi: Yes that could a good improvement to factorize\n> >>>>>>>> the RPC\n> >>>>>>> mechanism.\n> >>>>>>>> \n> >>>>>>>> Another idea: What about creating a RPC topic per\n> >>>>>>>> security group (quid of the\n> >>>>>>> RPC topic\n> >>>>>>>> scalability) on which an agent subscribes if one of its\n> >>>>>>>> ports is\n> >>>>>>> associated\n> >>>>>>>> to the security group?\n> >>>>>>>> \n> >>>>>>>> Regards, ?douard.\n> >>>>>>>> \n> >>>>>>>> \n> >>> \n> >>> \n> >>>>>>> Hmm, Interesting,\n> >>> \n> >>>>>>> @Nachi, I\'m not sure I fully understood:\n> >>> \n> >>> \n> >>>>>>> SG_LIST [ SG1, SG2] SG_RULE_LIST = [SG_Rule1, SG_Rule2] ..\n> >>>>>>> port[SG_ID1, SG_ID2], port2 , port3\n> >>> \n> >>> \n> >>>>>>> Probably we may need to include also the SG_IP_LIST =\n> >>>>>>> [SG_IP1, SG_IP2] ...\n> >>> \n> >>> \n> >>>>>>> and let the agent do all the combination work.\n> >>> \n> >>>>>>> Something like this could make sense?\n> >>> \n> >>>>>>> Security_Groups = {SG1:{IPs:[....],RULES:[....],\n> >>>>>>> SG2:{IPs:[....],RULES:[....]} }\n> >>> \n> >>>>>>> Ports = {Port1:[SG1, SG2], Port2: [SG1] .... }\n> >>> \n> >>> \n> >>>>>>> @Edouard, actually I like the idea of having the agent\n> >>>>>>> subscribed to security groups they have ports on... That\n> >>>>>>> would remove the need to include all the security groups\n> >>>>>>> information on every call...\n> >>> \n> >>>>>>> But would need another call to get the full information of\n> >>>>>>> a set of security groups at start/resync if we don\'t\n> >>>>>>> already have any.\n> >>> \n> >>> \n> >>>>>>>> \n> >>>>>>>> On Fri, Jun 20, 2014 at 4:04 AM, shihanzhang <\n> >>>>>>> ayshihanzhang at 126.com >\n> >>>>>>>> wrote:\n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> hi Miguel ?ngel, I am very agree with you about the\n> >>>>>>>> following point:\n> >>>>>>>>> * physical implementation on the hosts (ipsets,\n> >>>>>>>>> nftables, ... )\n> >>>>>>>> --this can reduce the load of compute node.\n> >>>>>>>>> * rpc communication mechanisms.\n> >>>>>>>> -- this can reduce the load of neutron server can you\n> >>>>>>>> help me to review my BP specs?\n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> At 2014-06-19 10:11:34, \"Miguel Angel Ajo Pelayo\" <\n> >>>>>>> mangelajo at redhat.com >\n> >>>>>>>> wrote:\n> >>>>>>>>> \n> >>>>>>>>> Hi it\'s a very interesting topic, I was getting ready\n> >>>>>>>>> to raise the same concerns about our security groups\n> >>>>>>>>> implementation,\n> >>>>>>> shihanzhang\n> >>>>>>>>> thank you for starting this topic.\n> >>>>>>>>> \n> >>>>>>>>> Not only at low level where (with our default security\n> >>>>>>>>> group rules -allow all incoming from \'default\' sg- the\n> >>>>>>>>> iptable rules will grow in ~X^2 for a tenant, and, the\n> >>>>>>>>> \"security_group_rules_for_devices\" rpc call from\n> >>>>>>>>> ovs-agent to neutron-server grows to message sizes of\n> >>>>>>>>>> 100MB,\n> >>>>>>>>> generating serious scalability issues or\n> >>>>>>>>> timeouts/retries that totally break neutron service.\n> >>>>>>>>> \n> >>>>>>>>> (example trace of that RPC call with a few instances\n> >>>>>>>>> http://www.fpaste.org/104401/14008522/ )\n> >>>>>>>>> \n> >>>>>>>>> I believe that we also need to review the RPC calling\n> >>>>>>>>> mechanism for the OVS agent here, there are several\n> >>>>>>>>> possible approaches to\n> >>>>>>> breaking\n> >>>>>>>>> down (or/and CIDR compressing) the information we\n> >>>>>>>>> return via this\n> >>>>>>> api\n> >>>>>>>>> call.\n> >>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>> So we have to look at two things here:\n> >>>>>>>>> \n> >>>>>>>>> * physical implementation on the hosts (ipsets,\n> >>>>>>>>> nftables, ... ) * rpc communication mechanisms.\n> >>>>>>>>> \n> >>>>>>>>> Best regards, Miguel ?ngel.\n> >>>>>>>>> \n> >>>>>>>>> ----- Mensaje original -----\n> >>>>>>>>> \n> >>>>>>>>>> Do you though about nftables that will replace\n> >>>>>>> {ip,ip6,arp,eb}tables?\n> >>>>>>>>>> It also based on the rule set mechanism. The issue\n> >>>>>>>>>> in that proposition, it\'s only stable since the\n> >>>>>>>>>> begin\n> >>>>>>> of the\n> >>>>>>>>>> year and on Linux kernel 3.13. But there lot of pros\n> >>>>>>>>>> I don\'t list here (leverage iptables\n> >>>>>>> limitation,\n> >>>>>>>>>> efficient update rule, rule set, standardization of\n> >>>>>>>>>> netfilter commands...).\n> >>>>>>>>> \n> >>>>>>>>>> ?douard.\n> >>>>>>>>> \n> >>>>>>>>>> On Thu, Jun 19, 2014 at 8:25 AM, henry hly <\n> >>>>>>>>>> henry4hly at gmail.com > wrote:\n> >>>>>>>>> \n> >>>>>>>>>>> we have done some tests, but have different\n> >>>>>>>>>>> result: the\n> >>>>>>> performance is\n> >>>>>>>>>>> nearly the same for empty and 5k rules in iptable,\n> >>>>>>>>>>> but huge gap between enable/disable iptable hook\n> >>>>>>>>>>> on linux bridge\n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>> On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang <\n> >>>>>>> ayshihanzhang at 126.com\n> >>>>>>>>>>>> \n> >>>>>>>>>>> wrote:\n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>> Now I have not get accurate test data, but I can\n> >>>>>>>>>>>> confirm the following points?\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>> 1. In compute node, the iptable\'s chain of a VM\n> >>>>>>>>>>>> is liner,\n> >>>>>>> iptable\n> >>>>>>>>>>>> filter it one by one, if a VM in default\n> >>>>>>>>>>>> security group and this default security group\n> >>>>>>>>>>>> have many members, but ipset chain is set, the\n> >>>>>>>>>>>> time\n> >>>>>>> ipset\n> >>>>>>>>>>>> filter one and many member is not much\n> >>>>>>>>>>>> difference.\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>> 2. when the iptable rule is very large, the\n> >>>>>>>>>>>> probability of\n> >>>>>>> failure\n> >>>>>>>>>>>> that iptable-save save the iptable rule is very\n> >>>>>>>>>>>> large.\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>> At 2014-06-19 10:55:56, \"Kevin Benton\" <\n> >>>>>>>>>>>> blak111 at gmail.com\n> >>>>>>>> wrote:\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>>> This sounds like a good idea to handle some of\n> >>>>>>>>>>>>> the\n> >>>>>>> performance\n> >>>>>>>>>>>>> issues until the ovs firewall can be\n> >>>>>>>>>>>>> implemented down the the line.\n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>> Do you have any performance comparisons?\n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>> On Jun 18, 2014 7:46 PM, \"shihanzhang\" <\n> >>>>>>> ayshihanzhang at 126.com >\n> >>>>>>>>>>>>> wrote:\n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>>>> Hello all,\n> >>>>>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>>>> Now in neutron, it use iptable implementing\n> >>>>>>>>>>>>>> security\n> >>>>>>> group, but\n> >>>>>>>>>>>>>> the performance of this implementation is\n> >>>>>>>>>>>>>> very poor, there\n> >>>>>>> is a bug:\n> >>>>>>>>>>>>>> https://bugs.launchpad.net/neutron/+bug/1302272\n> >>>>>>>>>>>>>> \n> >>>>>>>>>>>>>> \n> >>to\n> >>>>>>> reflect this\n> >>>>>>>>>>>>>> problem. In his test, w ith default security\n> >>>>>>>>>>>>>> groups(which has remote security group),\n> >>>>>>>>>>>>>> beyond 250-300 VMs, there were around 6k\n> >>>>>>>>>>>>>> Iptable rules\n> >>>>>>> on evry\n> >>>>>>>>>>>>>> compute node, although his patch can reduce\n> >>>>>>>>>>>>>> the processing time, but\n> >>>>>>> it don\'t\n> >>>>>>>>>>>>>> solve this problem fundamentally. I have\n> >>>>>>>>>>>>>> commit a BP to solve this\n> >>>>>>> problem:\n> >>>>>>>>>>>>>> \n> >>>>>>> https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security\n> >>> \n> >>>>>>> \n> >>> \n> >>>>>>>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>>> There are other people interested in this\n> >>>>>>>>>>>>>> it?\n> >>>>>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>>>> _______________________________________________\n> >>> \n> >>>>>>>>>>>>>> \n> >>>>>>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>>> OpenStack-dev mailing list\n> >>>>>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>>> OpenStack-dev at lists.openstack.org >> > > >\n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>>>> \n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>>>>> \n> >>> \n> >>>>>>>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>>> _______________________________________________\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>> OpenStack-dev mailing list\n> >>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>>>>> OpenStack-dev at lists.openstack.org >> >\n> >>>>>>>>>> \n> >>>>>>>>>>>> \n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>>> \n> >>>>>>> \n> >>>> \n> >>>>>>>>>>>>> \n> >>>>>>>>>> \n> >>>>>>>>> \n> >>>>>>>>>>> _______________________________________________\n> >>>>>>>>>> \n> >>>>>>>>>>> OpenStack-dev mailing list\n> >>>>>>>>>> \n> >>>>>>>>>>> OpenStack-dev at lists.openstack.org >>\n> >>>>>>>>>>> \n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>>> \n> >>>>>>> \n> >>>> \n> >>>>>>>>> \n> >>>>>>>>>> _______________________________________________\n> >>>>>>>>>> OpenStack-dev mailing list\n> >>>>>>>>>> OpenStack-dev at lists.openstack.org >>\n> >>>>>>>>>> \n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>>> \n> >>>>>>> \n> >>> \n> >>>>>>>>> _______________________________________________\n> >>>>>>>>> OpenStack-dev mailing list\n> >>>>>>>>> OpenStack-dev at lists.openstack.org >\n> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>>>>>>> \n> >>>>>>>>> \n> >>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> _______________________________________________\n> >>>>>>>> OpenStack-dev mailing list\n> >>>>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>>>>>> \n> >>>>>>>> \n> >>> \n> >>>>>>>> \n> >>>>>>>> \n> >>>>>>>> _______________________________________________\n> >>>>>>>> OpenStack-dev mailing list\n> >>>>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>>>>>> \n> >>>>>>>> \n> >>> \n> >>> \n> >>>>>>> _______________________________________________\n> >>>>>>> OpenStack-dev mailing list\n> >>>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>>>>> \n> >>>>>> \n> >>>>>> \n> >>> \n> >>> _______________________________________________\n> >>>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>>> \n> >>> \n> >>>>>> \n> >>_______________________________________________\n> >>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>> \n> >>> \n> >>>>> \n> >>>>> \n> >>>> _______________________________________________ OpenStack-dev\n> >>>> mailing list OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>>> \n> >>>>>>_______________________________________________\n> >>>>>>OpenStack-dev\n> >>>> \n> >>mailing list\n> >>>>>> OpenStack-dev at lists.openstack.org\n> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>> \n> >>>>>> \n> >>_______________________________________________\n> >>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>>> \n> >>>> \n> >>>>_______________________________________________\n> >>>>OpenStack-dev\n> >>>>> \n> >>mailing list\n> >>>> OpenStack-dev at lists.openstack.org\n> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>>> \n> >>> \n> >>> \n> >>> \n> >>> \n> >>> _______________________________________________ OpenStack-dev\n> >>> mailing list OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>> \n> >>-----BEGIN PGP SIGNATURE-----\n> >>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> >>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n> >> \n> >>iQEcBAEBCgAGBQJTtWPVAAoJEC5aWaUY1u57PyMH/3Honqp3NQN5d1crkgn2y4zR\n> >>IiMlTMoeloaLx84Fv7Ya44evA+ZX1dDIfozrig+/uuWlVXql4EIl9vcGQ2T0xvoE\n> >>WXo7eu6D4ysca1Bx0AAmNi3IY0jC3QP46V3slmOWYHW2GAwRrrWHLyuOfCubPros\n> >>7zlOEC5MRZsh1KY3fj+bX1a7dmR6QdKqnya/JdP8I0bkkYxOXAivX+gFJCTGeB23\n> >>1Ss//rr781W9mynwB2rXssUQZU3ySK7PQmMEAVZUPkPAIzbtlTfq7nbV1GPzL3Di\n> >>/qEXL0cEx57fv9l8SvqYHqVpeh09dbh3h7kKKovwgNKCpiD1oMDoWgCS+PelZFc=\n> >>=TxAT\n> >>-----END PGP SIGNATURE-----\n> >> \n> >>_______________________________________________\n> >>OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> --\n> Best wishes!\n> Baohua\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<77a4a6e9.63bf.147f68c0b6e.Coremail.ayshihanzhang@126.com>',NULL),('<1692456547.13705135.1395913035414.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-27 09:37:15',0,'2014-03-27 09:37:15',NULL,'[openstack-dev] [nova][scheduler] Availability Zones and Host\n aggregates..','\n\n----- Original Message -----\n> From: \"Sangeeta Singh\" <singhs at yahoo-inc.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, March 26, 2014 6:54:18 PM\n> Subject: Re: [openstack-dev] [nova][scheduler] Availability Zones and Host aggregates..\n> \n> \n> \n> On 3/26/14, 10:17 AM, \"Khanh-Toan Tran\" <khanh-toan.tran at cloudwatt.com>\n> wrote:\n> \n> >\n> >\n> >----- Original Message -----\n> >> From: \"Sangeeta Singh\" <singhs at yahoo-inc.com>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >><openstack-dev at lists.openstack.org>\n> >> Sent: Tuesday, March 25, 2014 9:50:00 PM\n> >> Subject: [openstack-dev] [nova][scheduler] Availability Zones and Host\n> >>aggregates..\n> >> \n> >> Hi,\n> >> \n> >> The availability Zones filter states that theoretically a compute node\n> >>can be\n> >> part of multiple availability zones. I have a requirement where I need\n> >>to\n> >> make a compute node part to 2 AZ. When I try to create a host aggregates\n> >> with AZ I can not add the node in two host aggregates that have AZ\n> >>defined.\n> >> However if I create a host aggregate without associating an AZ then I\n> >>can\n> >> add the compute nodes to it. After doing that I can update the\n> >> host-aggregate an associate an AZ. This looks like a bug.\n> >> \n> >> I can see the compute node to be listed in the 2 AZ with the\n> >> availability-zone-list command.\n> >> \n> >\n> >Yes it appears a bug to me (apparently the AZ metadata indertion is\n> >considered as a normal metadata so no check is done), and so does the\n> >message in the AvailabilityZoneFilter. I don\'t know why you need a\n> >compute node that belongs to 2 different availability-zones. Maybe I\'m\n> >wrong but for me it\'s logical that availability-zones do not share the\n> >same compute nodes. The \"availability-zones\" have the role of partition\n> >your compute nodes into \"zones\" that are physically separated (in large\n> >term it would require separation of physical servers, networking\n> >equipments, power sources, etc). So that when user deploys 2 VMs in 2\n> >different zones, he knows that these VMs do not fall into a same host and\n> >if some zone falls, the others continue working, thus the client will not\n> >lose all of his VMs. It\'s smaller than Regions which ensure total\n> >separation at the cost of low-layer connectivity and central management\n> >(e.g. scheduling per region).\n> >\n> >See: http://www.linuxjournal.com/content/introduction-openstack\n> >\n> >The former purpose of regouping hosts with the same characteristics is\n> >ensured by host-aggregates.\n> >\n> >> The problem that I have is that I can still not boot a VM on the\n> >>compute node\n> >> when I do not specify the AZ in the command though I have set the\n> >>default\n> >> availability zone and the default schedule zone in nova.conf.\n> >> \n> >> I get the error ?ERROR: The requested availability zone is not\n> >>available?\n> >> \n> >> What I am  trying to achieve is have two AZ that the user can select\n> >>during\n> >> the boot but then have a default AZ which has the HV from both AZ1 AND\n> >>AZ2\n> >> so that when the user does not specify any AZ in the boot command I\n> >>scatter\n> >> my VM on both the AZ in a balanced way.\n> >> \n> >\n> >I do not understand your goal. When you create two availability-zones and\n> >put ALL of your compute nodes into these AZs, then if you don\'t specifies\n> >the AZ in your request, then AZFilter will automatically accept all hosts.\n> >The defaut weigher (RalWeigher) will then distribute the workload fairely\n> >among these nodes regardless of AZ it belongs to. Maybe it is what you\n> >want?\n> \n>   With Havana that does not happen as there is a concept of\n> default_scheduler_zone which is none if not specified and when we specify\n> one can only specify a since AZ whereas in my case I basically want the 2\n> AZ that I create both to be considered default zones if nothing is\n> specified.\n\nIf you look into the code of the AvailabilityFilter, you\'ll see that the filter automatically accepts host if there is NO availability-zone in the request, which is the case when user does not specify AZ. This is exactly what I see in my Openstack platform (Hanava stable). FYI, I didn\'t set up a default AZ in config. So whenever I creates several VMs without specifying an AZ, the scheduler spreads the VMs into all hosts regardless of their AZ.\n\nWhat I think lacking is that user can not select a set of AZs instead of one or none right now.\n\n> >\n> >> Any pointers.\n> >> \n> >> Thanks,\n> >> Sangeeta\n> >> \n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >_______________________________________________\n> >OpenStack-dev mailing list\n> >OpenStack-dev at lists.openstack.org\n> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CF5861BB.4DD55%singhs@yahoo-inc.com>',NULL),('<1692521103.392.1359331311932.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-28 00:01:51',0,'2013-01-28 00:01:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-folsom #119','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/119/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise6 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/>\nCheckout:periodic-swift-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/> - hudson.remoting.Channel at 577a2815:precise6\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson5597266593130338210.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.A1YGrD1qfE\n+ TMPDIR=/tmp/tmp.A1YGrD1qfE\n+ trap \'rm -rf /tmp/tmp.A1YGrD1qfE\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/119/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python27-stable-folsom-119\', \'SSH_CLIENT\': \'198.101.231.203 50520 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python27-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1357687285.854054-1874355803\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk-amd64/jre/../lib/amd64\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.A1YGrD1qfE\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-28_00-01-16\', \'BUILD_NUMBER\': \'119\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'cba1334c-b768-4658-ae34-c89cf60ca19d\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50520 108.166.59.174 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    \n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\n    \nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\n    \nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\n    \nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\n    \nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    \n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\n    \nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\n    \nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/.tox/py27/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python27-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.A1YGrD1qfE\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-folsom/119\n[SCP] Copying console log.\n\n\n','<33967668.369.1359244909987.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1692627358.30.1378276219789.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-04 06:30:19',0,'2013-09-04 06:30:19',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-folsom #18','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-folsom/18/>\n\n\n\n','<1045065208.23.1378189126029.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1692719743.13002489.1379077358757.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-13 09:02:38',-14400,'2013-09-13 13:02:38',NULL,'[Openstack-stable-maint] Stable grizzly failures','Hi, sorry I missed this.\n\nYes we should be ok to remove those skips with keyring < 2.0.\n\nBut to stop thinking about it, we should first at least \nget https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1197988 moving,\nbut I can\'t re-open it. So who can?\n\nAlso I\'ve proposed backport of complete cli-output logging also to tempest-stable/grizly https://review.openstack.org/#/c/46485/.\nI would suggest that un-skip should better happen after that, so we don\'t find ourself in the dark again.\n\n----- Original Message -----\n> From: \"Thierry Carrez\" <thierry at openstack.org>\n> To: \"Alan Pevec\" <apevec at gmail.com>\n> Cc: \"openstack-stable-maint\" <openstack-stable-maint at lists.openstack.org>, \"Pavel Sedl?k\" <psedlak at redhat.com>,\n> \"David Kranz\" <dkranz at redhat.com>\n> Sent: Tuesday, September 10, 2013 11:09:49 AM\n> Subject: Re: [Openstack-stable-maint] Stable grizzly failures\n> \n> Alan Pevec wrote:\n> > 2013/8/29 Thierry Carrez <thierry at openstack.org>:\n> >> Can we mark https://bugs.launchpad.net/devstack/+bug/1193164 fixcomitted\n> >> too ?\n> > \n> > Please note https://bugs.launchpad.net/devstack/+bug/1217120 where it\n> > wants to unpin keyring as soon as 1193164 is fixed but fix for 1193164\n> > was pinning, so we\'re full circle :)\n> > \n> > 1217120 should probably depend on a fix in keyring, i.e. reopen\n> > 1197988 based on\n> > https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1197988/comments/5\n> > \n> >> Is there anything else we need to do before we can reenable the tests\n> >> that were temporarily disabled at:\n> >> https://github.com/openstack/tempest/commit/27e8547c31f15708b3ff143a62eb96742b287d26\n> >> ?\n> > \n> > AFAICT keystone cli tests can be re-enabled now, but I\'d like to hear\n> > from Pavel first.\n> \n> Pavel: any news ? I would really like to reenable the tests before I\n> stop thinking about this issue to focus on havana release :)\n> \n> --\n> Thierry Carrez (ttx)\n> \n\n-- \nPavel Sedl?k <psedlak at redhat.com>\n irc: psedlak\n\n\n\n','<522EE1DD.1070101@openstack.org>',NULL),('<1692853437.984468.1386248122900.JavaMail.zimbra@csc.fi>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 14:55:23',7200,'2013-12-05 12:55:23',NULL,'[Openstack] Openstack--instance-boot-from-ceph-volume','Hello Everyone \n\nThanks for your quick response , i am glad to be a part of such a responsive community \n\n\nI am using qemu-kvm provided by ceph repository that have RBD support . Using this i am able to create RBD volumes and its working good. \n\n\n\n\n[root at rdo qemu(keystone_admin)]# rbd list ceph-volumes \nvolume-0e2bfced-be6a-44ec-a3ca-22c771c66cdc \nvolume-10cc0855-652a-4a9b-baa1-80bc86dc12ac \nvolume-5e09ce7b-b874-4c24-97ae-341a305841d5 \nvolume-9671edaa-62c8-4f98-a36c-d6e59612141b \nvolume-a75d435b-ebce-4013-9c68-8df5d2c917e1 \nvolume-dd315dda-b22a-4cf8-8b77-7c2b2f163155 \n[root at rdo qemu(keystone_admin)]# \n\n\n\n\n\n\n\nI tried below steps needed for booting from volume \n\n\n\n\n\n\n\nhttp://docs.openstack.org/user-guide/content/boot_from_volume.html \n\n\n\n\n\n\n\n\n\n\n[root at rdo nova(keystone_admin)]# nova image-list \n+--------------------------------------+-----------------------------+--------+--------+ \n| ID | Name | Status | Server | \n+--------------------------------------+-----------------------------+--------+--------+ \n| f61edc8d-c9a1-4ff4-b4fc-c8128bd1a10b | Ubuntu 12.04 cloudimg amd64 | ACTIVE | | \n| fcc07414-bbb3-4473-a8df-523664c8c9df | ceph-glance-image | ACTIVE | | \n| be62a5bf-879f-4d1f-846c-fdef960224ff | precise-cloudimg.raw | ACTIVE | | \n| 3c2db0ad-8d1e-400d-ba13-a506448f2a8e | precise-server-cloudimg | ACTIVE | | \n+--------------------------------------+-----------------------------+--------+--------+ \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# cinder list \n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | \n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n| 0e2bfced-be6a-44ec-a3ca-22c771c66cdc | in-use | nova-vol_1 | 2 | None | false | 9d3c327f-1893-40ff-8a82-16fad9ce6d91 | \n| 10cc0855-652a-4a9b-baa1-80bc86dc12ac | available | ceph-vol1 | 5 | ceph-storage | false | | \n| 5e09ce7b-b874-4c24-97ae-341a305841d5 | available | precise-cloudimg_vol_boot | 5 | None | true | | \n| 9671edaa-62c8-4f98-a36c-d6e59612141b | available | boot_from_volume | 20 | None | false | | \n| a75d435b-ebce-4013-9c68-8df5d2c917e1 | available | dashboard-volume | 1 | ceph-storage | false | | \n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# cinder create --image-id be62a5bf-879f-4d1f-846c-fdef960224ff --display-name new_boot_from_vol 10 \n+---------------------+--------------------------------------+ \n| Property | Value | \n+---------------------+--------------------------------------+ \n| attachments | [] | \n| availability_zone | nova | \n| bootable | false | \n| created_at | 2013-12-05T12:34:45.241324 | \n| display_description | None | \n| display_name | new_boot_from_vol | \n| id | dd315dda-b22a-4cf8-8b77-7c2b2f163155 | \n| image_id | be62a5bf-879f-4d1f-846c-fdef960224ff | \n| metadata | {} | \n| size | 10 | \n| snapshot_id | None | \n| source_volid | None | \n| status | creating | \n| volume_type | None | \n+---------------------+--------------------------------------+ \n[root at rdo nova(keystone_admin)]# \n\n\n\n\n[root at rdo nova(keystone_admin)]# cinder list \n\n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to | \n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n| 0e2bfced-be6a-44ec-a3ca-22c771c66cdc | in-use | nova-vol_1 | 2 | None | false | 9d3c327f-1893-40ff-8a82-16fad9ce6d91 | \n| 10cc0855-652a-4a9b-baa1-80bc86dc12ac | available | ceph-vol1 | 5 | ceph-storage | false | | \n| 5e09ce7b-b874-4c24-97ae-341a305841d5 | available | precise-cloudimg_vol_boot | 5 | None | true | | \n| 9671edaa-62c8-4f98-a36c-d6e59612141b | available | boot_from_volume | 20 | None | false | | \n| a75d435b-ebce-4013-9c68-8df5d2c917e1 | available | dashboard-volume | 1 | ceph-storage | false | | \n| dd315dda-b22a-4cf8-8b77-7c2b2f163155 | available | new_boot_from_vol | 10 | None | true | | \n+--------------------------------------+-----------+---------------------------+------+--------------+----------+--------------------------------------+ \n[root at rdo nova(keystone_admin)]# \n\n\n\n\n\n\n\n\n\n\n\n\n\n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# nova boot --flavor 2 --image be62a5bf-879f-4d1f-846c-fdef960224ff --block_device_mapping vda=dd315dda-b22a-4cf8-8b77-7c2b2f163155:::0 --security_groups=default --nic net-id=4fe5909e-02db-4517-89f2-1278248fa26c myInstanceFromVolume \n+--------------------------------------+----------------------------------------------------+ \n| Property | Value | \n+--------------------------------------+----------------------------------------------------+ \n| OS-EXT-STS:task_state | scheduling | \n| image | precise-cloudimg.raw | \n| OS-EXT-STS:vm_state | building | \n| OS-EXT-SRV-ATTR:instance_name | instance-0000001d | \n| OS-SRV-USG:launched_at | None | \n| flavor | m1.small | \n| id | f324e9b8-ec3a-4174-8b97-bf78dba62932 | \n| security_groups | [{u\'name\': u\'default\'}] | \n| user_id | 99f8019ba2694d78a680a5de46aa1afd | \n| OS-DCF:diskConfig | MANUAL | \n| accessIPv4 | | \n| accessIPv6 | | \n| progress | 0 | \n| OS-EXT-STS:power_state | 0 | \n| OS-EXT-AZ:availability_zone | nova | \n| config_drive | | \n| status | BUILD | \n| updated | 2013-12-05T12:42:22Z | \n| hostId | | \n| OS-EXT-SRV-ATTR:host | None | \n| OS-SRV-USG:terminated_at | None | \n| key_name | None | \n| OS-EXT-SRV-ATTR:hypervisor_hostname | None | \n| name | myInstanceFromVolume | \n| adminPass | eish5pu56CiE | \n| tenant_id | 0dafe42cfde242ddbb67b681f59bdb00 | \n| created | 2013-12-05T12:42:21Z | \n| os-extended-volumes:volumes_attached | [{u\'id\': u\'dd315dda-b22a-4cf8-8b77-7c2b2f163155\'}] | \n| metadata | {} | \n+--------------------------------------+----------------------------------------------------+ \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# \n[root at rdo nova(keystone_admin)]# nova list \n+--------------------------------------+----------------------+---------+------------+-------------+---------------------+ \n| ID | Name | Status | Task State | Power State | Networks | \n+--------------------------------------+----------------------+---------+------------+-------------+---------------------+ \n| 0043a8be-60d1-43ed-ba43-1ccd0bba7559 | instance2 | SHUTOFF | None | Shutdown | public=172.24.4.228 | \n| f324e9b8-ec3a-4174-8b97-bf78dba62932 | myInstanceFromVolume | ERROR | None | NOSTATE | private=10.0.0.3 | \n| 9d3c327f-1893-40ff-8a82-16fad9ce6d91 | small-ubuntu | ACTIVE | None | Running | public=172.24.4.230 | \n+--------------------------------------+----------------------+---------+------------+-------------+---------------------+ \n[root at rdo nova(keystone_admin)]# \n\n\n\n\n\n\n\n===================================== \n\n\n\n\nLogs from /var/log/libvirt/qemu :: \n\n\n===================================== \n\n\n\nqemu-kvm: -drive file=rbd:ceph-volumes/volume-dd315dda-b22a-4cf8-8b77-7c2b2f163155:id=volumes:key=AQC804xS8HzFJxAAD/zzQ8LMzq9wDLq/5a472g==:auth_supported=cephx\\;none:mon_host=192.168.1.31\\:6789\\;192.168.1.33\\:6789\\;192.168.1.38\\:6789,if=none,id=drive-virtio-disk0,format=raw,serial=dd315dda-b22a-4cf8-8b77-7c2b2f163155,cache=none: could not open disk image rbd:ceph-volumes/volume-dd315dda-b22a-4cf8-8b77-7c2b2f163155:id=volumes:key=AQC804xS8HzFJxAAD/zzQ8LMzq9wDLq/5a472g==:auth_supported=cephx\\;none:mon_host=192.168.1.31\\:6789\\;192.168.1.33\\:6789\\;192.168.1.38\\:6789: No such file or directory \n2013-12-05 12:42:29.544+0000: shutting down \n\n\nAny idea why its throwing this error. \n\nMany Thanks \nKaran Singh \n\n\n----- Original Message -----\n\nFrom: \"Darren Birkett\" <darren.birkett at gmail.com> \nTo: \"Karan Singh\" <ksingh at csc.fi> \nSent: Thursday, 5 December, 2013 2:37:27 PM \nSubject: Re: [Openstack] Openstack--instance-boot-from-ceph-volume \n\nHi Karan, \n\n\nOn 5 December 2013 12:24, Karan Singh < ksingh at csc.fi > wrote: \n\n\n\nHello Stackers \n\nWondering if someone got Openstack Instance booted from ceph volume successfully , can help me to do it. \n\nAs of now , i have running ceph cluster which is integrated with Openstack ciner and glance , i can create volumes and put images from OS to ceph , this is working good. \n\nMy next target is to boot instance from volume. Can you share steps or instructions how you get it done. It would be great if you can help me setting this up. \n\nThanks a ton in advance \n\n\nMy setup --> ceph Dumpling , OS havana , Centos 6.5 \n\n\n\n\n\n\nIf you\'re using Centos, you\'ll need a qemu-kvm that is built with rbd support. You can grab this src rpm for qemu-kvm-rhev from Redhat and build it yourself: \n\nhttp://ftp.redhat.com/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu-kvm-rhev-0.12.1.2-2.415.el6.src.rpm \n\nUsing: \n\nrpmbuild -ba --with rhev_features --without guest_agent qemu-kvm.spec \n\nThen install the qemu-kvm-rhev and qemu-kvm-img that it builds - they will obsolete the qemu-kvm and qemu-img that come as part of the base CentOS. \n\nThen it\'s just a matter of creating your cinder volume from an image in glance (you need to use a raw image in glance): \n\n[root at cent-comp1 ~]# glance image-list \n+--------------------------------------+--------------+-------------+------------------+----------+--------+ \n| ID | Name | Disk Format | Container Format | Size | Status | \n+--------------------------------------+--------------+-------------+------------------+----------+--------+ \n| eada58eb-14ac-4a36-940f-794e9c3ef633 | cirros-image | qcow2 | bare | 13147648 | active | \n| 1c31a2ca-7f50-44d7-84d5-a16fbbafbfa7 | cirros-raw | raw | bare | 41126400 | active | \n+--------------------------------------+--------------+-------------+------------------+----------+--------+ \n[root at cent-comp1 ~]# cinder create --image-id 1c31a2ca-7f50-44d7-84d5-a16fbbafbfa7 --display-name my-bootable-volume 5 \n+---------------------+--------------------------------------+ \n| Property | Value | \n+---------------------+--------------------------------------+ \n| attachments | [] | \n| availability_zone | nova | \n| bootable | false | \n| created_at | 2013-12-05T12:36:19.502399 | \n| display_description | None | \n| display_name | my-bootable-volume | \n| id | 3d0199e0-4762-4e71-8eea-216b69c6e36c | \n| image_id | 1c31a2ca-7f50-44d7-84d5-a16fbbafbfa7 | \n| metadata | {} | \n| size | 5 | \n| snapshot_id | None | \n| source_volid | None | \n| status | creating | \n| volume_type | None | \n+---------------------+--------------------------------------+ \n[root at cent-comp1 ~]# nova boot --boot-volume 3d0199e0-4762-4e71-8eea-216b69c6e36c --flavor 1 myserver \n+--------------------------------------+----------------------------------------------------+ \n| Property | Value | \n+--------------------------------------+----------------------------------------------------+ \n| OS-EXT-STS:task_state | scheduling | \n| image | Attempt to boot from volume - no image supplied | \n| OS-EXT-STS:vm_state | building | \n| OS-EXT-SRV-ATTR:instance_name | instance-00000017 | \n| OS-SRV-USG:launched_at | None | \n| flavor | m1.tiny | \n| id | 7b28b8b7-75d0-4d57-8313-a4c78c021e54 | \n| security_groups | [{u\'name\': u\'default\'}] | \n| user_id | 772c04a676dc40288d8e77aece774103 | \n| OS-DCF:diskConfig | MANUAL | \n| accessIPv4 | | \n| accessIPv6 | | \n| progress | 0 | \n| OS-EXT-STS:power_state | 0 | \n| OS-EXT-AZ:availability_zone | nova | \n| config_drive | | \n| status | BUILD | \n| updated | 2013-12-05T12:36:49Z | \n| hostId | | \n| OS-EXT-SRV-ATTR:host | None | \n| OS-SRV-USG:terminated_at | None | \n| key_name | None | \n| OS-EXT-SRV-ATTR:hypervisor_hostname | None | \n| name | myserver | \n| adminPass | QCZAS6cPNGkP | \n| tenant_id | f1b863076b36422091d13d85bb127c4d | \n| created | 2013-12-05T12:36:49Z | \n| os-extended-volumes:volumes_attached | [{u\'id\': u\'3d0199e0-4762-4e71-8eea-216b69c6e36c\'}] | \n| metadata | {} | \n+--------------------------------------+----------------------------------------------------+ \n\nThanks \nDarren \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/dd78b6c3/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: undefined\nType: image/gif\nSize: 323 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/dd78b6c3/attachment.gif>\n\n','<CAHX4EnMkLoUKNC7XyeZTb8=vjgXMYC9J7i+F4jVN4MXdgkdTGA@mail.gmail.com>',NULL),('<1692ca7baa5b406984842d41e3e10d23@BY2PR08MB062.namprd08.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 23:48:11',0,'2013-10-28 23:48:11',NULL,'[openstack-dev]\n [TripleO][Nova][neutron][Heat][Oslo][Ceilometer][Havana]Single Subscription\n Point for event notification','Thanks Angus!\nYes, if this rpc notification mechanism works for all other components, e.g., Neutron, in addition to Nova, which seems to be the only documented component working with this notification system.\n\nFor example, can we do something like\n\nNetwork.instance.shutdown/.end\n\nOr \nStorage.instance.shutdown/.end\n\nOr \nImage.instance.shutdown/.end \n...\n\n-----Original Message-----\nFrom: Angus Salkeld [mailto:asalkeld at redhat.com] \nSent: Monday, October 28, 2013 4:36 PM\nTo: openstack-dev at lists.openstack.org\nSubject: Re: [openstack-dev] [TripleO][Nova][neutron][Heat][Oslo][Ceilometer][Havana]Single Subscription Point for event notification\n\nOn 28/10/13 22:30 +0000, Qing He wrote:\n>All,\n>I found multiple places/components you can get event alarms, e.g., Heat, Ceilometer, Oslo, Nova etc, notification. But I fail to find any documents as to how to do it in the respective component documents.\n>\n>I \'m  wondering if there is document as to if there is a single API entry point where you can subscribe and get event notification from all components, such as Nova, Neutron.\n\nHi,\n\nIf you are talking about rpc notifications, then this is one wiki page I know about:\nhttps://wiki.openstack.org/wiki/SystemUsageData\n\n(I have just added some heat notifications to it).\n\n-Angus\n\n>\n>Thanks,\n>\n>Qing\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20131028233549.GA10937@redhat.com>',NULL),('<1693546559.32.1383372084693.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:01:24',0,'2013-11-02 06:01:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #51','See <https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/51/>\n\n------------------------------------------\n[...truncated 655 lines...]\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_user_creds_none (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_user_creds_password (heat.tests.test_sqlalchemy_api.SqlAlchemyTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:15)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:16)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 698 tests in 11.278s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.10\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.51\nhttplib2==0.8\niso8601==0.1.8\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.2.0\nkombu==3.0.2\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.23\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6.1\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.7\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.1\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.7\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.3yT3zBRvft\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise34/51\nERROR: Failed to upload files\n2: No such file\n	at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2833)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2185)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2202)\n	at com.jcraft.jsch.ChannelSftp.stat(ChannelSftp.java:2159)\n	at be.certipost.hudson.plugin.SCPSite.mkdirs(SCPSite.java:314)\n	at be.certipost.hudson.plugin.SCPSite.createOutStream(SCPSite.java:208)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:204)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)\n	at hudson.model.Run.execute(Run.java:1618)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:247)\n\n\n','<2125916974.28.1383285729304.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1694179040.475.1367130458471.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:27:38',0,'2013-04-28 06:27:38',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-quantum-python27-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-quantum-python27-stable-grizzly/18/>\n\n\n\n','<1088779172.403.1367042974437.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1695173376.6339849.1368199081909.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-10 11:18:01',-14400,'2013-05-10 15:18:01',NULL,'[openstack-dev] revert keystone eventlet changes?','After talking on IRC the fix (for today) seems to be:\n\nSet EVENTLET_NO_GREENDNS=yes in tox.ini. (https://review.openstack.org/#/c/28802/)\n\nAnd then we can do a nice clean (and safe) revert of the breaking eventlet patch.\n\nThanks for the help in working through this.\n\nDan\n\n----- Original Message -----\n> From: \"Brant Knudson\" <blk at acm.org>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Friday, May 10, 2013 9:19:32 AM\n> Subject: Re: [openstack-dev] revert keystone eventlet changes?\n> \n> That fix was put in to get Keystone to pass the python26 gate on centos, so\n> reverting this change is going to fail Jenkins. Sorry for not looking close\n> enough yesterday to see that smokestack hadn\'t passed (smokestack has\n> usually finished before Jenkins). I\'ll investigate a fix for the swift\n> issue. - Brant\n> \n> \n> On Fri, May 10, 2013 at 8:06 AM, Dan Prince <dprince at redhat.com> wrote:\n> \n> >\n> >\n> > ----- Original Message -----\n> > > From: \"Thierry Carrez\" <thierry at openstack.org>\n> > > To: openstack-dev at lists.openstack.org\n> > > Sent: Friday, May 10, 2013 8:28:30 AM\n> > > Subject: Re: [openstack-dev] revert keystone eventlet changes?\n> > >\n> > > Dan Prince wrote:\n> > > > We made a change to keystone eventlet last night that seems to have\n> > ground\n> > > > SmokeStack to a halt:\n> > > >\n> > > > https://review.openstack.org/#/c/28785/\n> > > > https://bugs.launchpad.net/keystone/+bug/1178646\n> > > >\n> > > > Could we get a speedy revert on that patch until we get this figured\n> > out?\n> > >\n> > > There is also a comment on the original review that observes the same\n> > > failure: https://review.openstack.org/#/c/28737/\n> > >\n> > > Sounds like it should be reverted ASAP, and we need some tests to cover\n> > > that in the gate.\n> > >\n> > > Dan: any idea why SmokeStack was happy with it on the review ?\n> >\n> > ttx: From what I can see only patchset 3 ran fine in SmokeStack. Patchset\n> > 4 did not get a +1 verified (and I didn\'t get around to approving the\n> > negative result so it would post a -1).\n> >\n> > Dan\n> >\n> > >\n> > > --\n> > > Thierry Carrez (ttx)\n> > > Release Manager, OpenStack\n> > >\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHjeE=THH4KxTH9bvYvmJO19yeaJ725=TfXQc1vTiq9JHLr35Q@mail.gmail.com>',NULL),('<1695190998.228.1356653065388.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-28 00:04:25',0,'2012-12-28 00:04:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #88','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/88/>\n\n------------------------------------------\n[...truncated 2287 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 82%] sourcecode/horizon/horizon.dashboards.syspanel.projects.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 84%] sourcecode/horizon/horizon.dashboards.syspanel.projects.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/projects/tests.py\",> line 27, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:projects:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 86%] sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/quotas/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 89%] sourcecode/horizon/horizon.dashboards.syspanel.services.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 91%] sourcecode/horizon/horizon.dashboards.syspanel.services.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/services/tests.py\",> line 22, in <module>\n    INDEX_URL = reverse(\'horizon:syspanel:services:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 93%] sourcecode/horizon/horizon.dashboards.syspanel.users.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/panel.py\",> line 24, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [ 95%] sourcecode/horizon/horizon.dashboards.syspanel.users.tests\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/users/tests.py\",> line 29, in <module>\n    USERS_INDEX_URL = reverse(\'horizon:syspanel:users:index\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 447, in reverse\n    app_list = resolver.app_dict[ns]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 290, in app_dict\n    self._populate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 242, in _populate\n    for pattern in reversed(self.url_patterns):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 328, in url_patterns\n    patterns = getattr(self.urlconf_module, \"urlpatterns\", self.urlconf_module)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/core/urlresolvers.py\",> line 323, in urlconf_module\n    self._urlconf_module = import_module(self.urlconf_name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/django/utils/importlib.py\",> line 35, in import_module\n    __import__(name)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\nreading sources... [ 97%] sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/volumes/panel.py\",> line 5, in <module>\n    from horizon.dashboards.syspanel import dashboard\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/dashboards/syspanel/dashboard.py\",> line 22, in <module>\n    class SystemPanels(horizon.PanelGroup):\nAttributeError: \'module\' object has no attribute \'PanelGroup\'\nreading sources... [100%] sourcecode/openstack_dashboard/openstack_dashboard.urls\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py\",> line 321, in import_object\n    __import__(self.modname)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/openstack_dashboard/urls.py\",> line 36, in <module>\n    url(r\'\', include(horizon.urls)))\nAttributeError: \'module\' object has no attribute \'urls\'\n\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:24: WARNING: autodoc can\'t import/find function \'horizon.register\', it reported error: \"register\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:25: WARNING: autodoc can\'t import/find function \'horizon.unregister\', it reported error: \"unregister\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:26: WARNING: autodoc can\'t import/find function \'horizon.get_absolute_url\', it reported error: \"get_absolute_url\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:27: WARNING: autodoc can\'t import/find function \'horizon.get_user_home\', it reported error: \"get_user_home\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:28: WARNING: autodoc can\'t import/find function \'horizon.get_dashboard\', it reported error: \"get_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:29: WARNING: autodoc can\'t import/find function \'horizon.get_default_dashboard\', it reported error: \"get_default_dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:30: WARNING: autodoc can\'t import/find function \'horizon.get_dashboards\', it reported error: \"get_dashboards\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:35: WARNING: autodoc can\'t import/find class \'horizon.Dashboard\', it reported error: \"Dashboard\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:41: WARNING: autodoc can\'t import/find class \'horizon.Panel\', it reported error: \"Panel\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/ref/horizon.rst>:44: WARNING: autodoc can\'t import/find class \'horizon.PanelGroup\', it reported error: \"PanelGroup\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.floating_ips.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.keypairs.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.access_and_security.security_groups.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.containers.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.containers.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.images.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.instances.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.instances.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.nova.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.nova.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.dashboard\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.ec2.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.ec2.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.project.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.project.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.settings.user.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.settings.user.panel\', it reported error: \"\'module\' object has no attribute \'Dashboard\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.dashboard.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.dashboard\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.flavors.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.images.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.images.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.instances.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.instances.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.networks.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.networks.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.overview.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.overview.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.projects.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.projects.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.quotas.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.services.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.services.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.users.tests.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.users.tests\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel.rst>:4: WARNING: autodoc can\'t import/find module \'horizon.dashboards.syspanel.volumes.panel\', it reported error: \"\'module\' object has no attribute \'PanelGroup\'\", please check your spelling and sys.path\n<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/doc/source/sourcecode/openstack_dashboard/openstack_dashboard.urls.rst>:4: WARNING: autodoc can\'t import/find module \'openstack_dashboard.urls\', it reported error: \"\'module\' object has no attribute \'urls\'\", please check your spelling and sys.path\nlooking for now-outdated files... none found\npickling environment... done\nchecking consistency... done\nwriting... horizon.1 { intro quickstart topics/tutorial topics/deployment topics/customizing contributing testing topics/tables topics/testing ref/run_tests ref/horizon ref/workflows ref/tables ref/tabs ref/forms ref/middleware ref/context_processors ref/decorators ref/exceptions ref/test sourcecode/autoindex sourcecode/openstack_dashboard/openstack_dashboard sourcecode/openstack_dashboard/openstack_dashboard.exceptions sourcecode/openstack_dashboard/openstack_dashboard.settings sourcecode/openstack_dashboard/openstack_dashboard.urls sourcecode/openstack_dashboard/openstack_dashboard.test sourcecode/openstack_dashboard/openstack_dashboard.test.settings sourcecode/openstack_dashboard/openstack_dashboard.local sourcecode/horizon/horizon.test sourcecode/horizon/horizon.site_urls sourcecode/horizon/horizon.decorators sourcecode/horizon/horizon sourcecode/horizon/horizon.models sourcecode/horizon/horizon.base sourcecode/horizon/horizon.version sourcecode/horizon/horizon.exceptions sourcecode/horizon/horizon.middleware sourcecode/horizon/horizon.loaders sourcecode/horizon/horizon.messages sourcecode/horizon/horizon.context_processors sourcecode/horizon/horizon.views sourcecode/horizon/horizon.views.base sourcecode/horizon/horizon.usage.views sourcecode/horizon/horizon.usage.tables sourcecode/horizon/horizon.usage sourcecode/horizon/horizon.usage.base sourcecode/horizon/horizon.forms.fields sourcecode/horizon/horizon.forms.views sourcecode/horizon/horizon.forms sourcecode/horizon/horizon.forms.base sourcecode/horizon/horizon.workflows.views sourcecode/horizon/horizon.workflows sourcecode/horizon/horizon.workflows.base sourcecode/horizon/horizon.templatetags.horizon sourcecode/horizon/horizon.templatetags.truncate_filter sourcecode/horizon/horizon.templatetags.sizeformat sourcecode/horizon/horizon.templatetags.parse_date sourcecode/horizon/horizon.templatetags sourcecode/horizon/horizon.templatetags.branding sourcecode/horizon/horizon.conf sourcecode/horizon/horizon.conf.dash_template sourcecode/horizon/horizon.conf.dash_template.models sourcecode/horizon/horizon.conf.panel_template.views sourcecode/horizon/horizon.conf.panel_template sourcecode/horizon/horizon.conf.panel_template.models sourcecode/horizon/horizon.conf.panel_template.urls sourcecode/horizon/horizon.tables.views sourcecode/horizon/horizon.tables sourcecode/horizon/horizon.tables.actions sourcecode/horizon/horizon.tables.base sourcecode/horizon/horizon.dashboards sourcecode/horizon/horizon.dashboards.syspanel sourcecode/horizon/horizon.dashboards.syspanel.models sourcecode/horizon/horizon.dashboards.syspanel.dashboard sourcecode/horizon/horizon.dashboards.syspanel.networks.views sourcecode/horizon/horizon.dashboards.syspanel.networks.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.tables sourcecode/horizon/horizon.dashboards.syspanel.networks sourcecode/horizon/horizon.dashboards.syspanel.networks.panel sourcecode/horizon/horizon.dashboards.syspanel.networks.tests sourcecode/horizon/horizon.dashboards.syspanel.networks.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tabs sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.views sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.ports sourcecode/horizon/horizon.dashboards.syspanel.networks.ports.urls sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.views sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.forms sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.tables sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets sourcecode/horizon/horizon.dashboards.syspanel.networks.subnets.urls sourcecode/horizon/horizon.dashboards.syspanel.flavors.views sourcecode/horizon/horizon.dashboards.syspanel.flavors.forms sourcecode/horizon/horizon.dashboards.syspanel.flavors.tables sourcecode/horizon/horizon.dashboards.syspanel.flavors sourcecode/horizon/horizon.dashboards.syspanel.flavors.panel sourcecode/horizon/horizon.dashboards.syspanel.flavors.tests sourcecode/horizon/horizon.dashboards.syspanel.flavors.urls sourcecode/horizon/horizon.dashboards.syspanel.volumes.views sourcecode/horizon/horizon.dashboards.syspanel.volumes.tables sourcecode/horizon/horizon.dashboards.syspanel.volumes sourcecode/horizon/horizon.dashboards.syspanel.volumes.panel sourcecode/horizon/horizon.dashboards.syspanel.volumes.tests sourcecode/horizon/horizon.dashboards.syspanel.volumes.urls sourcecode/horizon/horizon.dashboards.syspanel.projects.views sourcecode/horizon/horizon.dashboards.syspanel.projects.forms sourcecode/horizon/horizon.dashboards.syspanel.projects.tables sourcecode/horizon/horizon.dashboards.syspanel.projects sourcecode/horizon/horizon.dashboards.syspanel.projects.panel sourcecode/horizon/horizon.dashboards.syspanel.projects.tests sourcecode/horizon/horizon.dashboards.syspanel.projects.workflows sourcecode/horizon/horizon.dashboards.syspanel.projects.urls sourcecode/horizon/horizon.dashboards.syspanel.quotas.views sourcecode/horizon/horizon.dashboards.syspanel.quotas.tables sourcecode/horizon/horizon.dashboards.syspanel.quotas sourcecode/horizon/horizon.dashboards.syspanel.quotas.panel sourcecode/horizon/horizon.dashboards.syspanel.quotas.tests sourcecode/horizon/horizon.dashboards.syspanel.quotas.urls sourcecode/horizon/horizon.dashboards.syspanel.users.views sourcecode/horizon/horizon.dashboards.syspanel.users.forms sourcecode/horizon/horizon.dashboards.syspanel.users.tables sourcecode/horizon/horizon.dashboards.syspanel.users sourcecode/horizon/horizon.dashboards.syspanel.users.panel sourcecode/horizon/horizon.dashboards.syspanel.users.tests sourcecode/horizon/horizon.dashboards.syspanel.users.urls sourcecode/horizon/horizon.dashboards.syspanel.instances.views sourcecode/horizon/horizon.dashboards.syspanel.instances.tables sourcecode/horizon/horizon.dashboards.syspanel.instances sourcecode/horizon/horizon.dashboards.syspanel.instances.panel sourcecode/horizon/horizon.dashboards.syspanel.instances.tests sourcecode/horizon/horizon.dashboards.syspanel.instances.urls sourcecode/horizon/horizon.dashboards.syspanel.overview.views sourcecode/horizon/horizon.dashboards.syspanel.overview sourcecode/horizon/horizon.dashboards.syspanel.overview.panel sourcecode/horizon/horizon.dashboards.syspanel.overview.tests sourcecode/horizon/horizon.dashboards.syspanel.overview.urls sourcecode/horizon/horizon.dashboards.syspanel.images.views sourcecode/horizon/horizon.dashboards.syspanel.images.forms sourcecode/horizon/horizon.dashboards.syspanel.images.tables sourcecode/horizon/horizon.dashboards.syspanel.images sourcecode/horizon/horizon.dashboards.syspanel.images.panel sourcecode/horizon/horizon.dashboards.syspanel.images.tests sourcecode/horizon/horizon.dashboards.syspanel.images.urls sourcecode/horizon/horizon.dashboards.syspanel.services.views sourcecode/horizon/horizon.dashboards.syspanel.services.tables sourcecode/horizon/horizon.dashboards.syspanel.services sourcecode/horizon/horizon.dashboards.syspanel.services.panel sourcecode/horizon/horizon.dashboards.syspanel.services.tests sourcecode/horizon/horizon.dashboards.syspanel.services.urls sourcecode/horizon/horizon.dashboards.settings sourcecode/horizon/horizon.dashboards.settings.models sourcecode/horizon/horizon.dashboards.settings.dashboard sourcecode/horizon/horizon.dashboards.settings.user.views sourcecode/horizon/horizon.dashboards.settings.user.forms sourcecode/horizon/horizon.dashboards.settings.user sourcecode/horizon/horizon.dashboards.settings.user.panel sourcecode/horizon/horizon.dashboards.settings.user.urls sourcecode/horizon/horizon.dashboards.settings.project.views sourcecode/horizon/horizon.dashboards.settings.project.forms sourcecode/horizon/horizon.dashboards.settings.project.tables sourcecode/horizon/horizon.dashboards.settings.project sourcecode/horizon/horizon.dashboards.settings.project.panel sourcecode/horizon/horizon.dashboards.settings.project.urls sourcecode/horizon/horizon.dashboards.settings.ec2.views sourcecode/horizon/horizon.dashboards.settings.ec2.forms sourcecode/horizon/horizon.dashboards.settings.ec2 sourcecode/horizon/horizon.dashboards.settings.ec2.panel sourcecode/horizon/horizon.dashboards.settings.ec2.tests sourcecode/horizon/horizon.dashboards.settings.ec2.urls sourcecode/horizon/horizon.dashboards.nova sourcecode/horizon/horizon.dashboards.nova.models sourcecode/horizon/horizon.dashboards.nova.dashboard sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.volume_snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.snapshots.urls sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tabs sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.views sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.forms sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tables sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.panel sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.tests sourcecode/horizon/horizon.dashboards.nova.images_and_snapshots.images.urls sourcecode/horizon/horizon.dashboards.nova.networks.views sourcecode/horizon/horizon.dashboards.nova.networks.forms sourcecode/horizon/horizon.dashboards.nova.networks.tables sourcecode/horizon/horizon.dashboards.nova.networks sourcecode/horizon/horizon.dashboards.nova.networks.panel sourcecode/horizon/horizon.dashboards.nova.networks.tests sourcecode/horizon/horizon.dashboards.nova.networks.workflows sourcecode/horizon/horizon.dashboards.nova.networks.urls sourcecode/horizon/horizon.dashboards.nova.networks.ports.tabs sourcecode/horizon/horizon.dashboards.nova.networks.ports.views sourcecode/horizon/horizon.dashboards.nova.networks.ports.tables sourcecode/horizon/horizon.dashboards.nova.networks.ports sourcecode/horizon/horizon.dashboards.nova.networks.ports.urls sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tabs sourcecode/horizon/horizon.dashboards.nova.networks.subnets.views sourcecode/horizon/horizon.dashboards.nova.networks.subnets.forms sourcecode/horizon/horizon.dashboards.nova.networks.subnets.tables sourcecode/horizon/horizon.dashboards.nova.networks.subnets sourcecode/horizon/horizon.dashboards.nova.networks.subnets.urls sourcecode/horizon/horizon.dashboards.nova.volumes.tabs sourcecode/horizon/horizon.dashboards.nova.volumes.views sourcecode/horizon/horizon.dashboards.nova.volumes.forms sourcecode/horizon/horizon.dashboards.nova.volumes.tables sourcecode/horizon/horizon.dashboards.nova.volumes sourcecode/horizon/horizon.dashboards.nova.volumes.panel sourcecode/horizon/horizon.dashboards.nova.volumes.tests sourcecode/horizon/horizon.dashboards.nova.volumes.urls sourcecode/horizon/horizon.dashboards.nova.containers.browsers sourcecode/horizon/horizon.dashboards.nova.containers.views sourcecode/horizon/horizon.dashboards.nova.containers.forms sourcecode/horizon/horizon.dashboards.nova.containers.tables sourcecode/horizon/horizon.dashboards.nova.containers sourcecode/horizon/horizon.dashboards.nova.containers.panel sourcecode/horizon/horizon.dashboards.nova.containers.tests sourcecode/horizon/horizon.dashboards.nova.containers.urls sourcecode/horizon/horizon.dashboards.nova.instances.tabs sourcecode/horizon/horizon.dashboards.nova.instances.views sourcecode/horizon/horizon.dashboards.nova.instances.forms sourcecode/horizon/horizon.dashboards.nova.instances.tables sourcecode/horizon/horizon.dashboards.nova.instances sourcecode/horizon/horizon.dashboards.nova.instances.panel sourcecode/horizon/horizon.dashboards.nova.instances.tests sourcecode/horizon/horizon.dashboards.nova.instances.workflows sourcecode/horizon/horizon.dashboards.nova.instances.urls sourcecode/horizon/horizon.dashboards.nova.overview.views sourcecode/horizon/horizon.dashboards.nova.overview sourcecode/horizon/horizon.dashboards.nova.overview.panel sourcecode/horizon/horizon.dashboards.nova.overview.tests sourcecode/horizon/horizon.dashboards.nova.overview.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.views sourcecode/horizon/horizon.dashboards.nova.access_and_security sourcecode/horizon/horizon.dashboards.nova.access_and_security.panel sourcecode/horizon/horizon.dashboards.nova.access_and_security.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.workflows sourcecode/horizon/horizon.dashboards.nova.access_and_security.floating_ips.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.keypairs.urls sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.views sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.forms sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tables sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.tests sourcecode/horizon/horizon.dashboards.nova.access_and_security.security_groups.urls sourcecode/horizon/horizon.api.nova sourcecode/horizon/horizon.api sourcecode/horizon/horizon.api.glance sourcecode/horizon/horizon.api.base sourcecode/horizon/horizon.api.keystone sourcecode/horizon/horizon.api.quantum sourcecode/horizon/horizon.api.swift sourcecode/horizon/horizon.browsers.breadcrumb sourcecode/horizon/horizon.browsers.views sourcecode/horizon/horizon.browsers sourcecode/horizon/horizon.browsers.base sourcecode/horizon/horizon.openstack sourcecode/horizon/horizon.openstack.common.jsonutils sourcecode/horizon/horizon.openstack.common sourcecode/horizon/horizon.openstack.common.setup sourcecode/horizon/horizon.management sourcecode/horizon/horizon.management.commands sourcecode/horizon/horizon.management.commands.startpanel sourcecode/horizon/horizon.management.commands.startdash sourcecode/horizon/horizon.utils.fields sourcecode/horizon/horizon.utils.html sourcecode/horizon/horizon.utils.secret_key sourcecode/horizon/horizon.utils sourcecode/horizon/horizon.utils.memoized sourcecode/horizon/horizon.utils.validators sourcecode/horizon/horizon.utils.filters sourcecode/horizon/horizon.utils.functions sourcecode/horizon/horizon.tabs.views sourcecode/horizon/horizon.tabs sourcecode/horizon/horizon.tabs.base releases/2012_1 releases/2012_2 faq glossary } Traceback (most recent call last):\n  File \"setup.py\", line 105, in <module>\n    \'Topic :: Internet :: WWW/HTTP\']\n  File \"/usr/lib/python2.7/distutils/core.py\", line 152, in setup\n    dist.run_commands()\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 953, in run_commands\n    self.run_command(cmd)\n  File \"/usr/lib/python2.7/distutils/dist.py\", line 972, in run_command\n    cmd_obj.run()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/horizon/openstack/common/setup.py\",> line 195, in run\n    BuildDoc.run(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/setup_command.py\",> line 143, in run\n    app.build(force_all=self.all_files)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/application.py\",> line 200, in build\n    self.builder.build_all()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 159, in build_all\n    self.build(None, summary=\'all source files\', method=\'all\')\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/__init__.py\",> line 252, in build\n    self.write(docnames, list(updated_docnames), method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/builders/manpage.py\",> line 88, in write\n    docwriter.write(largetree, destination)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/__init__.py\",> line 80, in write\n    self.translate()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 35, in translate\n    self.document.walkabout(visitor)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 174, in walkabout\n    if child.walkabout(visitor):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 187, in walkabout\n    visitor.dispatch_departure(self)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/nodes.py\",> line 1640, in dispatch_departure\n    return method(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/sphinx/writers/manpage.py\",> line 194, in depart_seealso\n    self.depart_admonition(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 411, in depart_admonition\n    self.depart_block_quote(node)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 449, in depart_block_quote\n    self.dedent()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/local/lib/python2.7/site-packages/docutils/writers/manpage.py\",> line 865, in dedent\n    self._indent.pop()\nIndexError: pop from empty list\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/88\n[SCP] Copying console log.\n\n\n','<153334745.210.1356566712433.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1695452934.44913474.1409973310489.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-05 23:15:10',-14400,'2014-09-06 03:15:10',NULL,'[openstack-dev] [nova][FFE] Use Libvirt Storage Pools (Partial)','Hi,\n\nI would like to request a feature freeze exception for the first part of the\nuse-libvirt-storage-pools blueprint [1].\n\nOverview\n========\n\nThe patches in question [2] would entail adding support for libvirt storage pools,\nbut neither making them default nor adding in automatic transitioning [3] from the\nlegacy backends to the storage pool backends.  This would allow new deployments\nand/or \"adventurous\" existing deployments to switch to libvirt storage pools,\nwhile adding an extra release before the automated transitioning and switch\nto default (as per the blueprint) is made.\n\nRisk\n====\n\nWhile the risk is not negligible, it is relatively minor, since the major changes\nare behind a configuration option (\"[libvirt] use_storage_pools\").  Additionally,\nsince the major changes are enabled by default [4], there is little danger of breakage\nin existing deployments\n\nBenefits\n========\n\nThe plan according to the original blueprint was to enable automatic transitioning of\nlegacy backends to the new backend, and setting the storage pools to default to enabled.\nHowever, this would likely not be a good idea for feature freeze, as things like that\ncan cause complicated and odd bugs (although we all hope our code has no bugs, it\'s more\nor less inevitable that bugs pop up ;-)).\n\nHowever, adding support for using the storage pool backend without enabling it by default\nor adding in automatic transitioning in Juno would give an extra cycle to ensure that any\nbugs get reported before the storage pool backend is made default.  Then, the rest of the\nspec could proceed as planned, just moved up a relase (i.e. deprecate the legacy backends\nin Kilo, and remove in L, assuming, of course, that the spec is re-approved).\n\n[1] https://review.openstack.org/#/c/86947/7\n[2] https://review.openstack.org/#/c/113058/, https://review.openstack.org/#/c/113059/, https://review.openstack.org/#/c/113060/\n[3] The patch for enabling automatic transitioning is up on Gerrit.\n    However, there are a couple of flaws in its implementation (not bugs, per se,\n    but things I would like to fix none-the-less).  However, this patch is not needed\n    for the previous patches to function properly, as they stand on their own.\n[4] The only significant change not behind a configuration option is the change that\n    makes the image cache use a file-based storage pool to manage its images.  Since the\n    pool is file-based and automatically created in the same location as the current image\n    cache, there is little risk associated.\n\n\nBest Regards,\nSolly Ross\n\n\n','<294631994.44871300.1409951690896.JavaMail.zimbra@redhat.com>',NULL),('<1696083167.22523772.1418979811149.JavaMail.zimbra@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-19 09:03:31',0,'2014-12-19 09:03:31',NULL,'[openstack-dev] [Congress] Re: Placement and Scheduling\n	via	Policy','Hi all,\n\nI\'ve made an analyse a while a go how to use SolverScheduler with a policy engine:\n\nhttps://docs.google.com/document/d/1RfP7jRsw1mXMjd7in72ARjK0fTrsQv1bqolOriIQB2Y\n\nBasically there should be a plugin that translates the policy into constraints for\nsolver to solve. This was made using Policy-Based Engine [1], but it works well\nwith Congress.\n\n[1] https://blueprints.launchpad.net/nova/+spec/policy-based-scheduler\n\n\n----- Mail original -----\n> De: \"Tim Hinrichs\" <thinrichs at vmware.com>\n> ?: \"ruby krishnaswamy\" <ruby.krishnaswamy at orange.com>\n> Cc: \"Prabhakar Kudva\" <kudva at us.ibm.com>, \"openstack-dev\" <openstack-dev at lists.openstack.org>, \"Gokul B Kandiraju\"\n> <gokul at us.ibm.com>\n> Envoy?: Jeudi 18 D?cembre 2014 18:24:59\n> Objet: Re: [openstack-dev] [Congress] Re: Placement and Scheduling via	Policy\n> \n> Hi all,\n> \n> Responses inline.\n> \n> On Dec 16, 2014, at 10:57 PM,\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>>\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>> wrote:\n> \n> Hi Tim & All\n> \n> @Tim: I did not reply to openstack-dev. Do you think we could have an\n> openstack list specific for ?congress? to which anybody may subscribe?\n> \n> Sending to openstack-dev is the right thing, as long as we put [Congress] in\n> the subject.  Everyone I know sets up filters on openstack-dev so they only\n> get the mail they care about.  I think you?re the only one in the group who\n> isn?t subscribed to that list.\n> \n> \n> \n> 1)     Enforcement:\n>            By this we mean ?how will the actions computed by the policy\n>            engine be executed by the concerned OpenStack functional module?.\n> \n> \n>       In this case, it is better to first work this out for a ?simpler? case,\n>       e.g. your running example concerning the network/groups.\n>             Note: some actions concern only some data base (e.g. insert the\n>             user within some group).\n> \n> \n> \n> 2)      From Prabhakar?s mail\n> \n> ?Enforcement. That is with a large number of constraints in place for\n> placement and\n> scheduling, how does the policy engine communicate and enforce the placement\n> constraints to nova scheduler. ?\n> \n>             Nova scheduler (current): It assigns VMs to servers based on the\n>             policy set by the administrator (through filters and host\n>             aggregates).\n> \n>   The administrator also configures a scheduling heuristic (implemented as a\n>   driver), for example ?round-robin? driver.\n>                                                  Then the computed assignment\n>                                                  is sent back to the\n>                                                  requestor (API server) that\n>                                                  interacts with nova-compute\n>                                                  to provision the VM.\n>                                                  The current nova-scheduler\n>                                                  has another function: It\n>                                                  updates the allocation\n>                                                  status of each compute node\n>                                                  on the DB (through another\n>                                                  indirection called\n>                                                  nova-conductor)\n> \n>             So it is correct to re-interpret your statement as follows:\n> \n> -       What is the entity with which the policy engine interacts for either\n> proactive or reactive placement management?\n> \n> -       How will the output from the policy engine (for example the placement\n> matrix) be communicated back?\n> \n> o    Proactive: this gives the mapping of VM to host\n> \n> o    Reactive: this gives the new mapping of running VMs to hosts\n> \n> -       How starting from the placement matrix, the correct migration plan\n> will be executed? (for reactive case)\n> \n> \n> \n> 3)     Currently openstack does not have ?automated management of reactive\n> placement?:  Hence if the policy engine is used for reactive placement, then\n> there is a need for another ?orchestrator? that can interpret the new\n> proposed placement configuration (mapping of VM to servers) and execute the\n> reconfiguration workflow.\n> \n> \n> 4)     So with a policy-based ?placement engine? that is integrated with\n> external solvers, then this engine will replace nova-scheduler?\n> \n> Could we converge on this?\n> \n> \n> \n> The notes from Yathiraj say that there is already a policy-based Nova\n> scheduler we can use.  I suggest we look into that.  It could potentially\n> simplify our problem to the point where we need only figure out how to\n> convert a fragment of the Congress policy language into their policy\n> language.  But those of you who are experts in placement will know better.\n> \n>    https://github.com/stackforge/nova-solver-scheduler<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_nova-2Dsolver-2Dscheduler&d=AAMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=gSzCqpS6tRMB8r5xNbeWoNcpobYiFYvOFpo3QBmvm0M&s=mdMcHh7nMTJv8PmY0i8NpQXP9_gpUpI3gxEec6zyt7A&e=>\n> \n> Tim\n> \n> \n> Regards\n> Ruby\n> \n> De : Tim Hinrichs [mailto:thinrichs at vmware.com]\n> Envoy? : mardi 16 d?cembre 2014 19:25\n> ? : Prabhakar Kudva\n> Cc : KRISHNASWAMY Ruby IMT/OLPS; Ramki Krishnan\n> (ramk at Brocade.com<mailto:ramk at Brocade.com>); Gokul B Kandiraju;\n> openstack-dev\n> Objet : [Congress] Re: Placement and Scheduling via Policy\n> \n> [Adding openstack-dev to this thread.  For those of you just joining? We\n> started kicking around ideas for how we might integrate a special-purpose VM\n> placement engine into Congress.]\n> \n> Kudva: responses inline.\n> \n> \n> On Dec 16, 2014, at 6:25 AM, Prabhakar Kudva\n> <kudva at us.ibm.com<mailto:kudva at us.ibm.com>> wrote:\n> \n> \n> Hi,\n> \n> I am very interested in this.\n> \n> So, it looks like there are two parts to this:\n> 1. Policy analysis when there are a significant mix of logical and builtin\n> predicates (i.e.,\n> runtime should identify a solution space when there are arithmetic\n> operators). This will\n> require linear programming/ILP type solvers.  There might be a need to have a\n> function\n> in runtime.py that specifically deals with this (Tim?)\n> \n> I think it?s right that we expect there to be a mix of builtins and standard\n> predicates.  But what we?re considering here is having the linear solver be\n> treated as if it were a domain-specific policy engine.  So that solver\n> wouldn?t be embedded into the runtime.py necessarily.  Rather, we?d delegate\n> part of the policy to that domain-specific policy engine.\n> \n> \n> 2. Enforcement. That is with a large number of constraints in place for\n> placement and\n> scheduling, how does the policy engine communicate and enforce the placement\n> constraints to nova scheduler.\n> \n> I would imagine that we could delegate either enforcement or monitoring or\n> both.  Eventually we want enforcement here, but monitoring could be useful\n> too.\n> \n> And yes you?re asking the right questions.  I was trying to break the problem\n> down into pieces in my bullet (1) below.  But I think there is significant\n> overlap in the questions we need to answer whether we?re delegating\n> monitoring or enforcement.\n> \n> \n> Both of these require some form of mathematical analysis.\n> \n> Would be happy and interested to discuss more on these lines.\n> \n> Maybe take a look at how I tried to breakdown the problem into separate\n> questions in bullet (1) below and see if that makes sense.\n> \n> Tim\n> \n> \n> Prabhakar\n> \n> \n> \n> \n> \n> \n> From:        Tim Hinrichs <thinrichs at vmware.com<mailto:thinrichs at vmware.com>>\n> To:\n> \"ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>\"\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>>\n> Cc:        \"Ramki Krishnan (ramk at Brocade.com<mailto:ramk at Brocade.com>)\"\n> <ramk at Brocade.com<mailto:ramk at Brocade.com>>, Gokul B\n> Kandiraju/Watson/IBM at IBMUS, Prabhakar Kudva/Watson/IBM at IBMUS\n> Date:        12/15/2014 12:09 PM\n> Subject:        Re: Placement and Scheduling via Policy\n> ________________________________\n> \n> \n> \n> [Adding Prabhakar and Gokul, in case they are interested.]\n> \n> 1) Ruby, thinking about the solver as taking 1 matrix of [vm, server] and\n> returning another matrix helps me understand what we?re talking\n> about?thanks.  I think you?re right that once we move from placement to\n> optimization problems in general we?ll need to figure out how to deal with\n> actions.  But if it?s a placement-specific policy engine, then we can build\n> VM-migration into it.\n> \n> It seems to me that the only part left is figuring out how to take an\n> arbitrary policy, carve off the placement-relevant portion, and create the\n> inputs the solver needs to generate that new matrix.  Some thoughts...\n> \n> - My gut tells me that the placement-solver should basically say ?I enforce\n> policies having to do with the schema nova:location.?  This way the Congress\n> policy engine knows to give it policies relevant to nova:location\n> (placement).  If we do that, I believe we can carve off the right sub\n> theory.\n> \n> - That leaves taking a Datalog policy where we know nova:location is\n> important and converting it to the input language required by a linear\n> solver.  We need to remember that the Datalog rules may reference tables\n> from other services like Neutron, Ceilometer, etc.  I think the key will be\n> figuring out what class of policies we can actually do that for reliably.\n> Cool?a concrete question.\n> \n> \n> 2) We can definitely wait until January on this.  I?ll be out of touch\n> starting Friday too; it seems we all get back early January, which seems\n> like the right time to resume our discussions.  We have some concrete\n> questions to answer, which was what I was hoping to accomplish before we all\n> went on holiday.\n> \n> Happy Holidays!\n> Tim\n> \n> \n> On Dec 15, 2014, at 5:53 AM,\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>>\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>> wrote:\n> \n> Hi Tim\n> \n> ?Questions:\n> 1) Is there any more data the solver needs?  Seems like it needs something\n> about CPU-load for each VM.\n> 2) Which solver should we be using?  What does the linear program that we\n> feed it look like?  How do we translate the results of the linear solver\n> into a collection of ?migrate_VM? API calls??\n> \n> \n> \n>   Question (2) seems to me the first to address, in particular:\n>      ?how to prepare the input (variables, constraints, goal) and invoke the\n>      solver?\n> =>  We need rules that represent constraints to give the solver (e.g. a\n> technical constraint that a VM should not be assigned to more than one\n> server or that more than maximum resource (cpu / mem ?) of a server cannot\n> be assigned.\n> \n>      ?how to translate the results of the linear solver into a collection of\n>      API calls?:\n> =>  The output from the ?solver? will give the new placement plan (respecting\n> the constraints in input)?\n> o    E.g. a table of [vm, server, true/false]\n> =>  Then this depends on how ?action? is going to be implemented in Congress\n> (whether an external solver is used or not)\n> o    Is the action presented as the ?final? DB rows that the system must\n> produce as a result of the actions?\n> o    E.g. if current vm table is [vm3, host4] and the recomputed row says\n> [vm3, host6], then the action is to move vm3 to host6?\n> \n> \n>      ?how will the solver be invoked??\n> =>  When will the optimization call be invoked?\n> =>  Is it ?batched?, e.g. periodically invoke Congress to compute new\n> assignments?\n> \n>   Which solver to use:\n>      http://www.coin-or.org/projects/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.coin-2Dor.org_projects_&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=3lvgeryw4T-aWafrSZZG96NcydtHt6HnT_6vKookx6U&s=01_9grcy8VGwbKRXcqhFRex3N0XIoCBzOimWFwXYI58&e=>\n>      and\n>      http://www.coin-or.org/projects/PuLP.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.coin-2Dor.org_projects_PuLP.xml&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=3lvgeryw4T-aWafrSZZG96NcydtHt6HnT_6vKookx6U&s=RRiv5ZWCQwWguBZIsIXzCA4_otY4Gr7aeFmFMRB4ZZQ&e=>\n>       I think it may be useful to pass through an interface (e.g. LP modeler\n>       to generate LP files in standard formats accepted by prevalent\n>       solvers)\n> \n> \n>   The mathematical program:\n>       We can (Orange) contribute to writing down in an informal way the\n>       program for this precise use case, if this can wait until January.\n>       Perhaps the objective is to may be ?minimize the number of servers\n>       whose usage is less than 50%?, since the original policy ?Not more\n>       than 1 server of type1 to have a load under 50%? need not necessarily\n>       have a solution.\n> \n>     This may help to derive the ?mappings? from Congress (rules to program\n>     equations, intermediary tables to program variables)?\n> \n> \n> For ?migration? use case: it may be useful to add some constraint\n> representing cost of migration, such that the solver computes the new\n> assignment plan such that the maximum migration cost is not exceeded. To\n> start with, perhaps number of migrations?\n> \n> \n> I will be away from the end of the week until 5th January. I will also\n> discuss with colleagues to see how we can formalize contribution\n> (congress+nfv poc).\n> \n> Rgds\n> Ruby\n> \n> De : Tim Hinrichs [mailto:thinrichs at vmware.com]\n> Envoy? : vendredi 12 d?cembre 2014 19:41\n> ? : KRISHNASWAMY Ruby IMT/OLPS\n> Cc : Ramki Krishnan (ramk at Brocade.com<mailto:ramk at Brocade.com>)\n> Objet : Re: Placement and Scheduling via Policy\n> \n> There?s a ton of good stuff here!\n> \n> So if we took Ramki?s initial use case and combined it with Ruby?s HA\n> constraint, we?d have something like the following policy.\n> \n> \n> // anti-affinity\n> error (server, VM1, VM2) :-\n>             same_ha_group(VM1, VM2),\n>             nova:location(VM1, server),\n>             nova:location(VM2, server)\n> \n> // server-utilization\n> error(server) :-\n> type1_server(server),\n> ceilometer:average_utilization(server, ?cpu-util?, avg),\n> avg < 50\n> \n> As a start, this seems plenty complex to me.  anti-affinity is great b/c it\n> DOES NOT require a sophisticated solver; server-utilization is great because\n> it DOES require a linear solver.\n> \n> Data the solver needs:\n> - Ceilometer: cpu-utilization for all the servers\n> - Nova: data as to where each VM is located\n> - Policy: high-availability groups\n> \n> Questions:\n> 1) Is there any more data the solver needs?  Seems like it needs something\n> about CPU-load for each VM.\n> 2) Which solver should we be using?  What does the linear program that we\n> feed it look like?  How do we translate the results of the linear solver\n> into a collection of ?migrate_VM? API calls?\n> \n> Maybe another few emails and then we set up a phone call.\n> \n> Tim\n> \n> \n> \n> \n> \n> \n> \n> \n> On Dec 11, 2014, at 1:33 AM,\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>>\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>> wrote:\n> \n> \n> Hello\n> \n> A) First a small extension to the use case that Ramki proposes\n> \n>    - Add high availability constraint.\n>   - Assuming server-a and server-b are of same size and same failure model.\n>     [Later: Assumption of identical failure rates can be loosened.\n>      Instead of considering only servers as failure domains, can introduce\n>      other failure domains ==> not just an anti-affinity policy but a\n>      calculation from 99,99.. requirement to VM placements, e.g.\n>     ]\n>   - For an exemplary maximum usage scenario, 53 physical servers could be\n>   under peak utilization (100%), 1 server (server-a) could be under  partial\n>   utilization (50%) with 2 instances of type large.3 and 1 instance of type\n>   large.2, and 1 server (server-b) could be under partial utilization\n>   (37.5%) with 3 instances of type large.2.\n>     Call VM.one.large2 as the large2 VM in server-a\n>     Call VM.two.large2 as one of the large2 VM in server-b\n> \n>   - VM.one.large2 and VM.two.large2\n>   - When one of the large.3 instances mapped to server-a is deleted from\n>   physical server type 1, Policy 1 will be violated, since the overall\n>   utilization of server-a falls to 37,5%.\n> \n>   - Various new placements(s) are described below\n> \n> \n>     VM.two.large2 must not be moved. Moving VM.two.large2 breaks non-affinity\n>     constraint.\n> \n>     error (server, VM1, VM2) :-\n>                 node (VM1, server1),\n>                 node (VM2, server2),\n>                 same_ha_group(VM1, VM2),\n>                 equal(server1, server2);\n> \n>    1) New placement 1: Move 2 instances of large.2 to server-a. Overall\n>    utilization of server-a - 50%. Overall utilization of server-b -\n>    12.5%.\n> \n>    2) New placement 2: Move 1 instance of large.3 to server-b. Overall\n>    utilization of server-a - 0%. Overall utilization of server-b -\n>    62.5%.\n> \n>    3) New placement 3: Move 3 instances of large.2 to server-a. Overall\n>    utilization of server-a - 62.5%. Overall utilization of server-b -\n>    0%.\n> \n>    New placements 2 and 3 could be considered optimal, since they\n>    achieve maximal bin packing and open up the door for turning off\n>    server-a or server-b and maximizing energy efficiency.\n> \n>    But new placement 3 breaks client policy.\n> \n> \n> BTW: what happens if a given situation does not allow the policy violation to\n> be removed?\n> \n> B) Ramki?s original use case can itself be extended:\n> \n>   Adding additional constraints to the previous use case due to cases such\n>   as:\n> \n> -       Server heterogeneity\n> \n> -       CPU ?pinning?\n> \n> -       ?VM groups? (and allocation\n> \n> -       Application interference\n> \n> -       Refining on the statement ?instantaneous energy consumption can be\n> approximately measured using an overall utilization metric, which is a\n> combination of CPU utilization, memory usage, I/O usage, and network usage?\n> \n> \n> Let me know if this will interest you. Some (e.g. application interference)\n> will need some time. E.G; benchmarking / profiling to class VMs etc.\n> \n> \n> C) New placement plan execution\n> \n> -       In Ramki?s original use case, violation is detected at events such as\n> VM delete.\n> While certainly this by itself is sufficiently complex, we may need to\n> consider other triggering cases (periodic or when multiple VMs are\n> deleted/added)\n> -       In this case, it may not be sufficient to compute the new placement\n> plan that brings the system to a configuration that does not break policy,\n> but also add other goals\n> \n> \n> \n> D) Let me know if a use case such as placing ?video conferencing servers?\n> (geographically distributed clients) would suit you (multi site scenario)\n> \n> =>  Or is it too premature?\n> \n> Ruby\n> \n> De : Tim Hinrichs [mailto:thinrichs at vmware.com]\n> Envoy? : mercredi 10 d?cembre 2014 19:44\n> ? : KRISHNASWAMY Ruby IMT/OLPS\n> Cc : Ramki Krishnan (ramk at Brocade.com<mailto:ramk at Brocade.com>)\n> Objet : Re: Placement and Scheduling via Policy\n> \n> Hi Ruby,\n> \n> Whatever information you think is important for the use case is good.\n> Section 3 from one of the docs Ramki sent you covers his use case.\n> https://datatracker.ietf.org/doc/draft-krishnan-nfvrg-policy-based-rm-nfviaas/?include_text=1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkrishnan-2Dnfvrg-2Dpolicy-2Dbased-2Drm-2Dnfviaas_-3Finclude-5Ftext-3D1&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=R82SMwEX_3O32-8F5eqMQ8Y6wuHt9WhjmMg6rr-4gWs&s=nE7Xheq0TcCDN98mFIOG_VvMsmfBeIDNDVVFV1HpJx0&e=>\n> \n> From my point of view, the keys things for the use case are?\n> \n> - The placement policy (i.e. the conditions under which VMs require\n> migration).\n> \n> - A description of how we want to compute what specific migrations should be\n> performed (a sketch of (i) the information that we need about current\n> placements, policy violations, etc., (2) what systems/algorithms/etc. can\n> utilize that input to figure out what migrations to perform.\n> \n> I think we want to focus on the end-user/customer experience (write a policy,\n> and watch the VMs move around to obey that policy in response to environment\n> changes) and then work out the details of how to implement that experience.\n> That?s why I didn?t include things like delays, asynchronous/synchronous,\n> architecture, applications, etc. in my 2 bullets above.\n> \n> Tim\n> \n> On Dec 10, 2014, at 8:55 AM,\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>>\n> <ruby.krishnaswamy at orange.com<mailto:ruby.krishnaswamy at orange.com>> wrote:\n> \n> \n> \n> Hi Ramki, Tim\n> \n> \n> By a ?format? for describing use cases, I meant to ask what sets of\n> information to provide, for example,\n> -       what granularity in description of use case?\n> -       a specific placement policy (and perhaps citing reasons for needing\n> such policy)?\n> -       Specific applications\n> -       Requirements on the placement manager itself (delay, ?)?\n> o   Architecture as well\n> -       Specific services from the placement manager (using Congress), such\n> as,\n> o   Violation detection (load, security, ?)\n> -       Adapting (e.g. context-aware) of policies used\n> \n> \n> In any case I will read the documents that Ramki has sent to not resend\n> similar things.\n> \n> Regards\n> Ruby\n> \n> De : Ramki Krishnan [mailto:ramk at Brocade.com]\n> Envoy? : mercredi 10 d?cembre 2014 16:59\n> ? : Tim Hinrichs; KRISHNASWAMY Ruby IMT/OLPS\n> Cc : Norival Figueira; Pierre Ettori; Alex Yip;\n> dilikris at in.ibm.com<mailto:dilikris at in.ibm.com>\n> Objet : RE: Placement and Scheduling via Policy\n> \n> Hi Tim,\n> \n> This sounds like a plan. It would be great if you could add the links below\n> to the Congress wiki. I am all for discussing this in the openstack-dev\n> mailing list and at this point this discussion is completely open.\n> \n> IRTF NFVRG Research Group:\n> https://trac.tools.ietf.org/group/irtf/trac/wiki/nfvrg<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_group_irtf_trac_wiki_nfvrg&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=R82SMwEX_3O32-8F5eqMQ8Y6wuHt9WhjmMg6rr-4gWs&s=X---GnOf7YwhOGKMWYa8Mh52VtmO-2imfuZdKLEY39M&e=>\n> \n> IRTF NFVRG draft on NFVIaaS placement/scheduling (includes system analysis\n> for the PoC we are thinking):\n> https://datatracker.ietf.org/doc/draft-krishnan-nfvrg-policy-based-rm-nfviaas/?include_text=1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dkrishnan-2Dnfvrg-2Dpolicy-2Dbased-2Drm-2Dnfviaas_-3Finclude-5Ftext-3D1&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=R82SMwEX_3O32-8F5eqMQ8Y6wuHt9WhjmMg6rr-4gWs&s=nE7Xheq0TcCDN98mFIOG_VvMsmfBeIDNDVVFV1HpJx0&e=>\n> \n> IRTF NFVRG draft on Policy Architecture and Framework (looking forward to\n> your comments and thoughts):\n> https://datatracker.ietf.org/doc/draft-norival-nfvrg-nfv-policy-arch/?include_text=1<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dnorival-2Dnfvrg-2Dnfv-2Dpolicy-2Darch_-3Finclude-5Ftext-3D1&d=AAMFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=B6BWd4kFfgOzAREgThxkmTZKy7dDXE2-eBAmL0PBK7s&m=R82SMwEX_3O32-8F5eqMQ8Y6wuHt9WhjmMg6rr-4gWs&s=lBet00H8iO1igDZNEMUGaryHWutkg8abBbL5VG8pjyk&e=>\n> \n> Hi Ruby,\n> \n> Looking forward to your use cases.\n> \n> Thanks,\n> Ramki\n> \n> \n> \n> _________________________________________________________________________________________________________________________\n> \n> Ce message et ses pieces jointes peuvent contenir des informations\n> confidentielles ou privilegiees et ne doivent donc\n> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu\n> ce message par erreur, veuillez le signaler\n> a l\'expediteur et le detruire ainsi que les pieces jointes. Les messages\n> electroniques etant susceptibles d\'alteration,\n> Orange decline toute responsabilite si ce message a ete altere, deforme ou\n> falsifie. Merci.\n> \n> This message and its attachments may contain confidential or privileged\n> information that may be protected by law;\n> they should not be distributed, used or copied without authorisation.\n> If you have received this email in error, please notify the sender and delete\n> this message and its attachments.\n> As emails may be altered, Orange is not liable for messages that have been\n> modified, changed or falsified.\n> Thank you.\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<AFBD8E41-732B-44C8-AAEA-29D962D28CE6@vmware.com>',NULL),('<1697017881.2635978.1416054988579.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-15 07:36:28',-18000,'2014-11-15 12:36:28',NULL,'[openstack-dev] TC election by the numbers','> >>   1. *make a minor concession to proportionality* - while keeping the\n> >>      focus on consensus, e.g. by adopting the proportional Condorcet\n> >>      variant.\n> > \n> > It would be interesting to see the analysis again, but in the past this\n> > proved to not make much difference.\n> \n> For the record, I just ran the ballots in CIVS \"proportional mode\" and\n> obtained the same set of winners:\n> \n> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_88cae988dff29be6\n\nThanks for doing this Thierry,\n\nNot surprising that it made no difference to the outcome this time,\ngiven the smaller number of seats contested and the gap between the\nfirst 6 and the trailing pack. IIRC the only previous election where\nyour analysis showed the proportional variant would have any impact\nwas the Oct 2013 contest for 11 seats, where the margins were tighter\nin the lower preferences.\n\nSo in the absence of switching to simultaneous terms, adopting the\nproportional variant of Condorcet is probably not worth the extra\nconceptual complexity for the interested voter to digest.\n\nOf course, we could just throw in the towel and cede the community\nleadership to a deck of playing cards ;)\n\nCheers,\nEoghan\n\n\n','<5464C981.3040109@openstack.org>',NULL),('<1697502046.8398591.1372840833266.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-03 04:40:33',-14400,'2013-07-03 08:40:33',NULL,'[openstack-dev] [horizon] Removing the .mo files from Horizon\n git','\"Monty Taylor\" <mordred at inaugust.com> wrote:\n> On 07/02/2013 01:13 AM, Mark McLoughlin wrote:\n> > On Tue, 2013-07-02 at 09:58 +0200, Thierry Carrez wrote:\n> >> Thomas Goirand wrote:\n> >>> So, shouldn\'t the .mo files be generated at build time only, and be kept\n> >>> out of the Git?\n> >>\n> >> +1\n> > \n> > Yep, agree too.\n> > \n> > Interestingly, last time I checked, devstack doesn\'t actually compile\n> > the message catalogs (python setup.py compile_catalog).\n> > \n> > I\'ve been meaning to fix that for a while now, but it\'s fallen by the\n> > wayside. I\'ve unassigned myself from the bug for now:\n> > \n> >   https://bugs.launchpad.net/devstack/+bug/995287\n> \n> Should we make python setup.py install do this if gettext is installed?\n> Or keep it as a separate step for people who care?\n\nYes, it would be awesome to automate this on install and let people still get the translations automagically.\n\nJulie\n\n\n','<51D318D4.9040408@inaugust.com>',NULL),('<1697878577.2352582.1368600649048.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-05-15 02:50:49',-14400,'2013-05-15 06:50:49',NULL,'[openstack-qa] tempest run length - need a gate tag - call for\n help','In Jenkins you can a single console and you can see your \n change is not OK even before jenkins says -1.\n\nMixing two nose processes output is not readable, without an additional trick.\n\nThe real questions:\nWill we have this feature with testr ?\n\nIs it a really important feature ?\n\nBest Regards,\nAttila\n\n----- Original Message -----\nFrom: \"Daryl Walleck\" <daryl.walleck at RACKSPACE.COM>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nCc: \"Sean Dague\" <sean at dague.net>, \"Robert Collins\" <robertc at robertcollins.net>\nSent: Tuesday, May 14, 2013 11:13:48 PM\nSubject: Re: [openstack-qa] tempest run length - need a gate tag - call for help\n\nJust a thought, but even if Nose\'s parallelization is broken, what\'s stopping us from using Nose\'s loader and runner programmatically to kick individual test modules off to run in their own thread process (as a stop gap solution)? We\'re doing something similar (using just base unittest) with CloudCafe and it required no modifications to our tests. I couldn\'t see it needing modifications in this case either.\n\nDaryl \n________________________________________\nFrom: David Kranz [david.kranz at qrclab.com]\nSent: Tuesday, May 14, 2013 12:51 PM\nTo: All Things QA.\nCc: Sean Dague; Robert Collins\nSubject: Re: [openstack-qa] tempest run length - need a gate tag - call for help\n\nThis subject seems to be as controversial on the list as it was at the\nsummit. But I think we did agree (or agree to disagree) at the summit on\nthe following points:\n\n1. We should test as much as we can and not assume any \"hardware\"\nlimitations unless they are proven to exist.\n2. The tests need to run below some budget. It is not clear what it\nshould be but many felt that the current time was near the upper bound.\nOthers disagree.\n3. We need parallel test execution ASAP\n\nThe trouble was that (3) is not so easy or it would have been done\nmonths ago as this is a long-running problem. If Robert can help that\nwould be great. If we solve this,\nthe other issues will largely disappear.\n\n  -David\n\nOn 5/14/2013 12:18 PM, Monty Taylor wrote:\n>\n> On 05/13/2013 12:51 PM, Sean Dague wrote:\n>> On 05/13/2013 02:52 PM, James E. Blair wrote:\n>>> Sean Dague <sean at dague.net> writes:\n>>>\n>>>> Any assistance would be good.\n>>>>\n>>>> Right now we really just need \'gate\' attr added to basically all the\n>>>> non skipped methods, we can prune later. Once \'gate\' looks to be ~\n>>>> full, we can flip over check and gate to use that.\n>>>>\n>>>> I think long term the approach we\'re going to need to go with is 3\n>>>> sets of tests:\n>>>>\n>>>> smoke (< 10 mins)\n>>>> gate (< 45 mins)\n>>>> full (everything)\n>>>>\n>>>> All projects gate on gate\n>>>>\n>>>> Periodic runs of full - daily, more often?\n>>>>\n>>>> Tempest check runs full (but not gate), it\'s advisory.\n>>>>\n>>>> Some on demand facility for people to run full.\n>>>>\n>>>> At this point I\'m not adding my +2 to any more tests (only approving\n>>>> fixes to existing tests) until we get gate tag in, as I don\'t think we\n>>>> should be running any longer than we currently are.\n>>> We discussed this at the summit, and while running fewer tests is\n>>> certainly one of the things we can do, I don\'t remember consensus that\n>>> it was our first priority.\n>> It\'s not really about running fewer tests, it\'s about test growth.\n>> Tempest isn\'t just a tool for the gate, lots of people want to use it on\n>> their clouds. So at some point we do need to divorce the gate set from\n>> the whole set. Otherwise the tolerable length of the OpenStack gate\n>> limits the content people can contribute to test their real world clouds.\n>>\n>> We already have instances of this, stress tests, which are in tempest\n>> but not in the gate. David and I had some lunch time conversations about\n>> this one day and I think that we were both of the mindset that:\n>>   * not everything in tempest has to be in the gate\n>>   * however, everything in tempest has to get run on some interval for\n>> bitrot reasons (which we aren\'t currently doing)\n> I think we\'re still suffering from diverging assumptions about some\n> things. IMO, there are three types of tests:\n>\n> functional tests - test that a thing works\n> stress tests - hammer the thing to make sure it can handle load\n> performance regression tests - check that this commit performs as well\n> as the last one\n>\n> We are fundamentally unequipped to run the second two in any meaningful\n> way as part of OpenStack Infra right now - and I think that\'s ok for\n> now. But let\'s ignore them for the rest of this - they\'re a topic for\n> future.\n>\n> Our discussions about tests in the gate should at the moment be around\n> tests that test functionality and what to do with them.\n>\n> I am of the opinion that we should run every single functionality test\n> we have at our disposal every time we run anything, because that\'s how\n> we ensure that OpenStack works, and that is the current purpose of and\n> scope of the gate.\n>\n>>> We have a number of other things that we can do to reduce run-time that\n>>> I think we agreed should be a higher priority:\n>>>\n>>> A) Parallelize the test runner (move to testr).\n>>> B) Split the run into multiple jobs (XML vs JSON, etc).\n>>> C) Focus on flakey tests so that gate resets are less of a factor\n>>>      (reducing sensitivity to runtime).\n>>>\n>>> Note that work on both A and B independently facilitates C.\n>>>\n>>> I think the general direction we\'d like to head is to run _more_ tests,\n>>> not less.  Further, I don\'t think that check jobs and gate jobs should\n>>> run different tests -- some people will learn to just ignore check jobs\n>>> and enqueue failing jobs into the gate (as people already ignore\n>>> non-voting jobs), resulting in more bad code landing.  It\'s also\n>>> optimizing the wrong pipeline -- developers are more sensitive to slow\n>>> check jobs than gate jobs.\n>>>\n>>> I got the impression that we all agreed that testr was the highest\n>>> priority for this, and I\'d still like to see that land before we move on\n>>> to functional job splits.  Is that effort progressing?  What can we do\n>>> to help?\n>> A is currently stalled for lack of anyone working on it for H1. Chris\n>> Yeoh was the driving force in Grizzly on this, but he\'s hard at work on\n>> the Nova v3 API right now. Matt Treinish\'s going to pick this up on H2\n>> if no one else steps forward.\n> Robert - can you provide some help here? It seems like we\'re blocking on\n> some engineering challenges that I believe might be easy for you.\n>\n>> B currently has the issue that test criteria selection kind of sucks\n>> because of the lack of structure in the tempest tree. I\'m currently\n>> working on this one to get it done by H1 -\n>> https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/tempest-repo-restructure,n,z\n>>\n>>\n>> C is currently probably a later in cycle task, just for time reasons.\n>>\n>> So B we should be able to do ~ H1 timeframe, we\'ll have the test suite\n>> in chunks that are easy to run bits and pieces of.\n>>\n>> A should be ~H2 (depending).\n>>\n>> But that\'s still a lot of weeks where we have test case contributors\n>> largely blocked because run time is an issue. Having a gate tag that we\n>> can annotate is just another lever. It also provides us with an excuse\n>> to get the multi tag support into the test cases, because developers\n>> really do want to run things like:\n> I agree, A and B are both important, and separate tasks.\n>\n> I don\'t agree that run time is an issue, actually, and if that is an\n> assertion we\'re operating under, I\'d like to dig more in to why. The\n> tests have been running between 45 minutes and 1.5 hours for the past 6\n> months. I don\'t think that waiting another chunk of weeks is going to\n> kill us, and I don\'t think we should not accept new test cases because\n> of a run time limit. If we need to bump the gate timeout because the run\n> time is legitimately increased, that\'s not hard to do.\n>\n> If at all possible, I\'d really like to get things sorted without gating\n> less.\n>\n>> ./run_tests.sh -t cinder  (or something similar)\n>>\n>> And get just the slice of tests that has a cinder interaction.\n>>\n>>      -Sean\n>>\n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C694D25F2@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1697973611.3648995.1397207984180.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-04-11 05:19:44',-14400,'2014-04-11 09:19:44',NULL,'[openstack-tc] upgrade testing expectation','\n\n> > Thanks for raising this.\n> > \n> > Can I clarify one related point, whether grenade is intended\n> > primarily to catch intrinsic or extrinsic upgrade issues?\n> > \n> > Or both?\n> > \n> > Intrinsic in this context would for example be service A failing\n> > post-upgrade due to a bad DB schema migration.\n> > \n> > Whereas extrinsic would for example be service A failing post-\n> > upgrade because some dependency/assumption with respect to\n> > service B is now broken.\n> > \n> > I ask because ceilometer when used with a \"schema free\" storage\n> > driver may be more likely to suffer from extrinsic issues on\n> > upgrade as opposed to intrinsic (e.g. nova changes a notification\n> > payload between versions, as opposed to a failed db-sync as that\n> > wouldn\'t even arise).\n> > \n> > But surely such integration issues should have been caught in\n> > advance via the normal Tempest testing of master-versus-master,\n> > and wouldn\'t necessarily require the big-bang stable-to-master\n> > approach of grenade to smoke out?\n> > \n> > Or am I missing something obvious here?\n> \n> I will in no way say we catch all upgrade issues in grenade, but let me\n> tell you what we expect to work, and are testing against.\n> \n> In grenade we bring up stable/last version of OpenStack, exercise it\n> with Tempest (smoke subset), and then specifically create some\n> additional resources we expect to survive the upgrade. We then upgrade\n> the *code* to master. The configuration is left at the stable/last\n> version, as we should have 1 cycle deprecation on configuration. We run\n> a series of specific upgrade scripts (which in the base case do\n> db-sync), then check for the expected resources to still be there, and\n> complete with another Tempest smoke run.\n> \n> This should catch config deprecation issues, it should catch bad db\n> upgrades (as we\'ve got content in the db), and it represents some rough\n> state of running an openstack cloud that includes data from an old state\n> of openstack.\n\nThanks for the clarification, IIUC sounds like grenade is best suited to\nthree particular potential upgrade issues:\n\n1. forward compatibility of configuration\n\n2. schema migrations applied to a non-empty DB\n\n3. survivability of pre-existing resources\n\nSo ceilometer will benefit fully from #1 like any other service,\nmay benefit from #2 depending on the choice of storage backend,\nand will partially benefit from #3 (in the sense of an upgraded\nceilometer being capable of continuing to gather data on those\npre-existing resources, but not directly being responsible for\nthe resources surviving the upgrade).\n\nThat basically addresses my uncertainty around whether ceilometer\nwould benefit from participating in grenade-based upgrade testing.\n\nCheers,\nEoghan\n \n> There are plenty of things that could be improved, but it\'s managed to\n> catch a lot of basic issues that are huge pains for deployers rolling\n> openstack forward.\n\n\n\n','<5346D64F.9030304@dague.net>',NULL),('<1697981648.6239387.1400077344028.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-14 10:22:24',-14400,'2014-05-14 14:22:24',NULL,'[openstack-dev] [nova] Consuming keystoneclient\'s Session\n object in novaclient','\n\n----- Original Message -----\n> From: \"Joe Gordon\" <joe.gordon0 at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, May 8, 2014 4:54:31 PM\n> Subject: Re: [openstack-dev] [nova] Consuming keystoneclient\'s Session object in novaclient\n> \n> \n> \n> \n> On Wed, May 7, 2014 at 7:54 PM, Jamie Lennox < jamielennox at redhat.com >\n> wrote:\n> \n> \n> \n> \n> \n> ----- Original Message -----\n> > From: \"Monty Taylor\" < mordred at inaugust.com >\n> > To: openstack-dev at lists.openstack.org\n> > Sent: Thursday, May 8, 2014 8:22:21 AM\n> > Subject: Re: [openstack-dev] [nova] Consuming keystoneclient\'s Session\n> > object in novaclient\n> > \n> > On 05/07/2014 03:10 PM, Joe Gordon wrote:\n> > > \n> > > \n> > > \n> > > On Tue, May 6, 2014 at 3:22 PM, Jamie Lennox < jamielennox at redhat.com\n> > > <mailto: jamielennox at redhat.com >> wrote:\n> > > \n> > > All,\n> > > \n> > > TL;DR: novaclient should be able to use the common transport/auth\n> > > layers of keystoneclient. If it does there are going to be functions\n> > > like client.authenticate() that won\'t operate the same way when a\n> > > session object is passed. For most users who just use the CRUD\n> > > operations there will be no difference.\n> > > \n> > > \n> > > I\'m hoping that at least some of the nova community has heard of the\n> > > push for using keystoneclient\'s Session object across all the\n> > > clients. For those unaware keystoneclient.session.Session is a\n> > > common transport and authentication layer to remove the need for\n> > > each python-*client having there own authentication configuration\n> > > and disparate transport options.\n> > > \n> > > It offers:\n> > > - a single place for updates to transport (eg fixing TLS or other\n> > > transport issues in one place)\n> > > - a way for all clients to immediately support the full range of\n> > > keystone\'s authentication including v3 auth, SAML, kerberos etc\n> > > - a common place to handle version discovery such that we support\n> > > multiple version endpoints from the same service catalog endpoint.\n> > > \n> > > For information of how to interact with a session you can see:\n> > > http://www.jamielennox.net/blog/2014/02/24/client-session-objects/\n> > > This mentions the code is uncommitted however has since been\n> > > committed with a few small details around parameter names being\n> > > changed. The theory remains the same.\n> > > \n> > > \n> > > To integrate this into novaclient means that if a session= object is\n> > > passed then the standard HTTPClient code will be ignored in favour\n> > > of using what was passed. This means that there are changes in the\n> > > API of the client. In keystoneclient we have take the opinion that\n> > > by passing a session object then you opt-in to the newer API and\n> > > therefore accept that some functions are no longer available. For\n> > > example client.authenticate() is no longer allowed because\n> > > authentication is not the client\'s responsibility. It will have no\n> > > impact on the standard novaclient CRUD operations and so be\n> > > un-noticed by the vast majority of users.\n> > > \n> > > The review showing these changes is here:\n> > > https://review.openstack.org/#/c/85920\n> > > \n> > > To enable this there are a series of test changes to mock client\n> > > requests at the HTTP layer rather than in the client. This means\n> > > that we can test that all client operations against the new and old\n> > > client construction methods and ensure the same requests are being\n> > > sent. The foundation of this to turn tests into fixtures can be\n> > > found by following:\n> > > https://blueprints.launchpad.net/python-novaclient/+spec/httpretty-testing\n> > > \n> > > IMO making these tests into fixtures is a good idea anyway, however\n> > > I am only pursuing it so that we can transition to using a common\n> > > Session.\n> > > \n> > > Regarding dependencies, novaclient will need a test-requirements.txt\n> > > on keystoneclient so that it can construct Session objects to test\n> > > with but it should not need a requirements.txt as the session object\n> > > is constructed by the user of the client (eg openstackclient,\n> > > horizon etc).\n> > > \n> > > \n> > > Can we make novaclient use keystoneclient\'s session by default? And just\n> > > add this to requirements.\n> > \n> > ++\n> > \n> > Once it\'s supported, I would think that someone wanting to use\n> > novaclient _without_ keystoneclient should be seen as the exception case\n> > and not the normal case.\n> \n> So keystoneclient\'s session is designed to be passed around, rather than\n> constructed individually by the clients, so that the same authentication\n> mechanisms can be shared by multiple instances of a client. A made up, but\n> not unrealistic example:\n> \n> auth = keystoneclient.auth.identity.v3.Password(auth_url=\' http://keystone/v3\n> \', username=\'user\', password=\'pass\', ...)\n> session = keystoneclient.session.Session(auth=auth, cacerts=\'path/to\')\n> \n> glance = glanceclient.v1.Client(session)\n> keystone = keystoneclient.v3.Client(session)\n> nova = novaclient.v1.Client(session)\n> \n> This is why the dependency on keystoneclient falls onto the user (eg heat,\n> horizon, OSC etc). Passing the session around will be the norm rather than\n> an additional inconvenience. Having said that the novaclient CLI is a\n> consumer of the novaclient library and so there is going to be a dependence\n> there eventually.\n> \n> We can rip out the existing transport logic of the HTTPClient such that it\n> constructs a session object for us, but it essentially comes down to what\n> sort of behaviour change is allowed. Scanning the existing HTTPClient code\n> there are going to be subtle differences in:\n> \n> - the service catalog logic\n> - when authentication is triggered\n> - keyring handling\n> - connection pooling\n> - the way the existing auth_system is handled.\n> - all the attributes saved on the client are no longer required.\n> \n> None of these result in changes to user experience for standard use. However\n> there are going to be consumers such as horizon and OSC who already deal\n> with multiple clients that currently force set token data into the client\n> rather than have each client authenticate itself again. They rely on\n> specific behaviour that will possibly change. Most of these changes could be\n> compensated for as we did in keystoneclient but it\'s not pretty.\n> \n> \n> My question is why not make the novaclient CLI use the keystoneclient\'s\n> session by default (but don\'t change the default behavior for the python\n> library). We can still leave in the old logic in place so that python\n> developers using python-novaclient (the library) have to opt-in to using\n> keystoneclient\'s session object.\n\nOh, absolutely agreed. Once the library is able to take a session the CLI should use it exclusively.\n\n> \n> So the theory is given that session is required to be passed anyway, passing\n> a Session object is opting-in to new behaviour. When OSC changes to dealing\n> with sessions the old hacks will be removed at the same time. But until then\n> the existing behaviour will be maintained. When we are satisfied the changes\n> work and we get more other client adoption then we deprecate passing\n> username= etc to client.\n> \n> Makes sense to me, I would add horizon into this list as well.\n> \n> \n> \n> \n> \n> > > If there are concerns with this process please respond here and/or\n> > > on the review.\n> > > \n> > > \n> > > \n> > > Thanks,\n> > > \n> > > Jamie\n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > <mailto: OpenStack-dev at lists.openstack.org >\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > > \n> > > \n> > > \n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > > \n> > \n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHXdxOeAzW0C02qtqaEs82U5AS32finJ7eHjSQcb79LuYMv80w@mail.gmail.com>',NULL),('<1698067607.54.1381644115951.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-13 06:01:55',0,'2013-10-13 06:01:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #33','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/33/>\n\n------------------------------------------\n[...truncated 634 lines...]\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.497s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.14.0\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\necdsa==0.9\neventlet==0.14.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.33\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\nparamiko==1.12.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-memcached==1.53\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-swiftclient==1.8.0\npytz==2013.7\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.tFiaqPVhTh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise13/33\n[SCP] Copying console log.\n\n\n','<1247493268.46.1381471366245.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1698212837.2457287.1381862061754.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-15 14:34:21',-14400,'2013-10-15 18:34:21',NULL,'[Openstack-docs] Install Guide Neutron Component','Hello All,\nI\'ve got a section of the install guide for doing a Neutron setup written, and I\'d like to hear what people think.  There are a few places where Ubuntu-specific or openSUSE-specific commands still need to be written, but other than that it should be good to go.  I also wrote a concepts section to go along with it, but I think I forgot to include it in the main file, so it won\'t get compiled currently (I\'ll fix that shortly).  You can take a look at it at https://github.com/DirectXMan12/openstack-manuals/tree/topic/neutron.  Let me know what you think.\n\nBest Regards,\nSolly Ross\n\nSoftware Engineer\nRed Hat OpenStack Team\n\n\n','<497835312.2408027.1381858090434.JavaMail.root@redhat.com>',NULL),('<1698818211.141.1365921962705.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-14 06:46:02',0,'2013-04-14 06:46:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #4','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/4/>\n\n------------------------------------------\n[...truncated 4575 lines...]\n    test_unsupported_extensions_are_not_loaded                   OK    0.00\nRequestExtensionTest\n    test_edit_previously_uneditable_field                        OK    0.02\n    test_extend_get_resource_response                            OK    0.01\n    test_get_resources                                           OK    0.02\n    test_headers_can_be_extended                                 OK    0.01\nResourceExtensionTest\n    test_exceptions_notimplemented                               OK    0.02\n    test_plugin_prefix_with_parent_resource                      OK    0.04\n    test_resource_can_be_added_as_extension                      OK    0.02\n    test_resource_ext_for_formatted_req_on_custom_collection_actionOK    0.02\n    test_resource_ext_for_nested_resource_custom_collection_actionOK    0.02\n    test_resource_ext_with_custom_member_action_gets_plugin_prefixOK    0.02\n    test_resource_extension_for_delete_custom_collection_action  OK    0.01\n    test_resource_extension_for_get_custom_collection_action     OK    0.01\n    test_resource_extension_for_post_custom_collection_action    OK    0.01\n    test_resource_extension_for_put_custom_collection_action     OK    0.01\n    test_resource_extension_with_custom_member_action            OK    0.02\n    test_resource_extension_with_custom_member_action_and_attr_mapOK    0.01\n    test_resource_gets_prefix_of_plugin                          OK    0.02\n    test_returns_404_for_non_existent_extension                  OK    0.01\nIptablesFirewallTestCase\n    test_defer_apply                                             OK    0.01\n    test_filter_defer_with_exception                             OK    0.01\n    test_filter_ipv4_egress                                      OK    0.01\n    test_filter_ipv4_egress_icmp                                 OK    0.01\n    test_filter_ipv4_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv4_egress_prefix                               OK    0.01\n    test_filter_ipv4_egress_tcp                                  OK    0.01\n    test_filter_ipv4_egress_tcp_mport                            OK    0.01\n    test_filter_ipv4_egress_tcp_mport_prefix                     OK    0.02\n    test_filter_ipv4_egress_tcp_port                             OK    0.03\n    test_filter_ipv4_egress_tcp_prefix                           OK    0.02\n    test_filter_ipv4_egress_udp                                  OK    0.01\n    test_filter_ipv4_egress_udp_mport                            OK    0.01\n    test_filter_ipv4_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv4_egress_udp_port                             OK    0.01\n    test_filter_ipv4_egress_udp_prefix                           OK    0.01\n    test_filter_ipv4_ingress                                     OK    0.01\n    test_filter_ipv4_ingress_icmp                                OK    0.01\n    test_filter_ipv4_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv4_ingress_prefix                              OK    1.99\n    test_filter_ipv4_ingress_tcp                                 OK    0.01\n    test_filter_ipv4_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv4_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_tcp_port                            OK    0.01\n    test_filter_ipv4_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv4_ingress_udp                                 OK    0.01\n    test_filter_ipv4_ingress_udp_mport                           OK    0.01\n    test_filter_ipv4_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv4_ingress_udp_port                            OK    0.01\n    test_filter_ipv4_ingress_udp_prefix                          OK    0.01\n    test_filter_ipv6_egress                                      OK    0.01\n    test_filter_ipv6_egress_icmp                                 OK    0.01\n    test_filter_ipv6_egress_icmp_prefix                          OK    0.01\n    test_filter_ipv6_egress_prefix                               OK    0.01\n    test_filter_ipv6_egress_tcp                                  OK    0.01\n    test_filter_ipv6_egress_tcp_mport                            OK    0.01\n    test_filter_ipv6_egress_tcp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_tcp_port                             OK    0.02\n    test_filter_ipv6_egress_tcp_prefix                           OK    0.01\n    test_filter_ipv6_egress_udp                                  OK    0.01\n    test_filter_ipv6_egress_udp_mport                            OK    0.01\n    test_filter_ipv6_egress_udp_mport_prefix                     OK    0.01\n    test_filter_ipv6_egress_udp_port                             OK    0.01\n    test_filter_ipv6_egress_udp_prefix                           OK    0.01\n    test_filter_ipv6_ingress                                     OK    0.01\n    test_filter_ipv6_ingress_icmp                                OK    0.01\n    test_filter_ipv6_ingress_icmp_prefix                         OK    0.01\n    test_filter_ipv6_ingress_prefix                              OK    0.01\n    test_filter_ipv6_ingress_tcp                                 OK    0.01\n    test_filter_ipv6_ingress_tcp_mport                           OK    0.01\n    test_filter_ipv6_ingress_tcp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_tcp_port                            OK    0.01\n    test_filter_ipv6_ingress_tcp_prefix                          OK    0.01\n    test_filter_ipv6_ingress_udp                                 OK    0.01\n    test_filter_ipv6_ingress_udp_mport                           OK    0.01\n    test_filter_ipv6_ingress_udp_mport_prefix                    OK    0.01\n    test_filter_ipv6_ingress_udp_port                            OK    0.01\n    test_filter_ipv6_ingress_udp_prefix                          OK    0.01\n    test_prepare_port_filter_with_no_sg                          OK    0.01\n    test_remove_unknown_port                                     OK    0.01\n    test_update_delete_port_filter                               OK    0.01\nIptablesManagerStateFulTestCase\n    test_add_and_remove_chain                                    OK    0.00\n    test_add_filter_rule                                         OK    0.00\n    test_add_nat_rule                                            OK    0.01\n    test_add_rule_to_a_nonexistent_chain                         OK    0.00\n    test_binary_name                                             OK    0.02\n    test_get_chanin_name                                         OK    0.00\n    test_remove_nonexistent_chain                                OK    0.01\n    test_remove_nonexistent_rule                                 OK    0.01\nIptablesManagerStateLessTestCase\n    test_nat_not_found                                           OK    0.01\nTestBasicRouterOperations\n    testAgentAddExternalGateway                                  OK    0.04\n    testAgentAddFloatingIP                                       OK    0.03\n    testAgentAddInternalNetwork                                  OK    0.02\n    testAgentCreate                                              OK    0.05\n    testAgentRemoveExternalGateway                               OK    0.03\n    testAgentRemoveFloatingIP                                    OK    0.02\n    testAgentRemoveInternalNetwork                               OK    0.02\n    testAgentRoutingTableUpdated                                 OK    0.01\n    testAgentRoutingTableUpdatedNoNameSpace                      OK    0.01\n    testDestroyNamespace                                         OK    0.01\n    testDestroyNamespaceWithRouterId                             OK    0.01\n    testProcessRouter                                            OK    0.03\n    testRouterInfoCreate                                         OK    0.01\n    testRoutersWithAdminStateDown                                OK    0.01\n    testRoutesUpdated                                            OK    0.02\n    testRoutesUpdatedNoNamespace                                 OK    0.01\n    testSingleLoopRouterRemoval                                  OK    0.03\nTestL3AgentEventHandler\n    test_spawn_metadata_proxy                                    OK    2.05\nL3NatDBTestCase\n    test_create_external_network_admin_suceeds                   OK    0.20\n    test_create_external_network_non_admin_fails                 OK    0.15\n    test_create_floating_non_ext_network_returns_400             OK    0.28\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.14\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.14\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.15\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.46\n    test_create_floatingip_no_public_subnet_returns_400          OK    0.49\n    test_create_port_external_network_admin_suceeds              OK    0.30\n    test_create_port_external_network_non_admin_fails            OK    0.28\n    test_floating_ip_direct_port_delete_returns_409              OK    0.87\n    test_floatingip_crd_ops                                      OK    3.33\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    0.76\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    0.80\n    test_floatingip_list_with_pagination                         OK    0.61\n    test_floatingip_list_with_pagination_reverse                 OK    0.61\n    test_floatingip_list_with_sort                               OK    2.84\n    test_floatingip_port_delete                                  OK    0.78\n    test_floatingip_update                                       OK    0.76\n    test_floatingip_with_assoc                                   OK    0.68\n    test_floatingip_with_assoc_fails                             OK    2.92\n    test_floatingips_op_agent                                    OK    0.84\n    test_get_network_succeeds_without_filter                     OK    0.15\n    test_interfaces_op_agent                                     OK    0.36\n    test_l3_agent_routers_query_floatingips                      OK    0.72\n    test_l3_agent_routers_query_gateway                          OK    0.37\n    test_l3_agent_routers_query_ignore_interfaces_with_moreThanOneIpOK    0.39\n    test_l3_agent_routers_query_interfaces                       OK    0.36\n    test_list_nets_external                                      OK    2.45\n    test_list_nets_external_pagination                           OK    0.42\n    test_network_filter_hook_admin_context                       OK    0.16\n    test_network_filter_hook_nonadmin_context                    OK    0.13\n    test_network_update_external                                 OK    0.45\n    test_network_update_external_failure                         OK    0.39\n    test_router_add_gateway                                      OK    0.39\n    test_router_add_gateway_dup_subnet1_returns_400              OK    0.39\n    test_router_add_gateway_dup_subnet2_returns_400              OK    0.38\n    test_router_add_gateway_invalid_network_returns_404          OK    0.20\n    test_router_add_gateway_net_not_external_returns_400         OK    0.29\n    test_router_add_gateway_no_subnet_returns_400                OK    0.37\n    test_router_add_gateway_tenant_ctx                           OK    2.27\n    test_router_add_interface_dup_subnet1_returns_400            OK    0.35\n    test_router_add_interface_dup_subnet2_returns_400            OK    0.42\n    test_router_add_interface_no_data_returns_400                OK    0.18\n    test_router_add_interface_overlapped_cidr_returns_400        OK    0.58\n    test_router_add_interface_port                               OK    0.37\n    test_router_add_interface_port_bad_tenant_returns_404        OK    0.44\n    test_router_add_interface_subnet                             OK    0.42\n    test_router_add_interface_subnet_with_bad_tenant_returns_404 OK    0.42\n    test_router_add_interface_subnet_with_port_from_other_tenant OK    2.85\n    test_router_create                                           OK    0.19\n    test_router_create_with_gwinfo                               OK    0.35\n    test_router_delete                                           OK    0.24\n    test_router_delete_subnet_inuse_returns_409                  OK    0.43\n    test_router_delete_with_floatingip_existed_returns_409       OK    0.71\n    test_router_delete_with_port_existed_returns_409             OK    0.37\n    test_router_gateway_op_agent                                 OK    0.44\n    test_router_list                                             OK    0.38\n    test_router_list_with_pagination                             OK    0.25\n    test_router_list_with_pagination_reverse                     OK    2.58\n    test_router_list_with_parameters                             OK    0.25\n    test_router_list_with_sort                                   OK    0.28\n    test_router_remove_interface_inuse_returns_409               OK    0.38\n    test_router_remove_interface_wrong_port_returns_404          OK    0.53\n    test_router_remove_interface_wrong_subnet_returns_409        OK    0.44\n    test_router_show                                             OK    0.19\n    test_router_update                                           OK    0.19\n    test_router_update_gateway                                   OK    0.53\n    test_router_update_gateway_to_empty_with_existed_floatingip  OK    2.87\n    test_router_update_gateway_with_existed_floatingip           OK    0.84\n    test_two_fips_one_port_invalid_return_409                    OK    0.84\nL3NatDBTestCaseXML\n    test_create_external_network_admin_suceeds                   OK    0.21\n    test_create_external_network_non_admin_fails                 OK    0.16\n    test_create_floating_non_ext_network_returns_400             OK    0.34\n    test_create_floatingip_invalid_fixed_ip_address_returns_400  OK    0.16\n    test_create_floatingip_invalid_floating_network_id_returns_400OK    0.15\n    test_create_floatingip_invalid_floating_port_id_returns_400  OK    0.16\n    test_create_floatingip_no_ext_gateway_return_404             OK    0.50\n    test_create_floatingip_no_public_subnet_returns_400          OK    2.86\n    test_create_port_external_network_admin_suceeds              OK    0.30\n    test_create_port_external_network_non_admin_fails            OK    0.26\n    test_floating_ip_direct_port_delete_returns_409              OK    0.81\n    test_floatingip_crd_ops                                      OK    0.80\n    test_floatingip_delete_router_intf_with_port_id_returns_409  OK    0.75\n    test_floatingip_delete_router_intf_with_subnet_id_returns_409OK    2.83\n    test_floatingip_list_with_pagination                         OK    0.73\n    test_floatingip_list_with_pagination_reverse                 OK    0.70\n    test_floatingip_list_with_sort                               OK    0.67\n    test_floatingip_port_delete                                  OK    0.74\n    test_floatingip_update                                       OK    3.07\n    test_floatingip_with_assoc                                   OK    0.79\n    test_floatingip_with_assoc_fails                             OK    0.69\n    test_floatingips_op_agent                                    OK    0.72\n    test_get_network_succeeds_without_filter                     OK    0.16\n    test_interfaces_op_agent                                     OK    0.37\n    test_l3_agent_routers_query_floatingips                      OK    3.86\n    test_l3_agent_routers_query_gateway                          OK    0.48\n    test_l3_agent_routers_query_ignore_interfaces_with_moreThanOneIpOK    0.44\n    test_l3_agent_routers_query_interfaces                       OK    0.46\n    test_list_nets_external                                      OK    0.35\n    test_list_nets_external_pagination                           OK    0.35\n    test_network_filter_hook_admin_context                       OK    0.16\n    test_network_filter_hook_nonadmin_context                    OK    0.14\n    test_network_update_external                                 OK    0.44\n    test_network_update_external_failure                         OK    0.41\n    test_router_add_gateway                                      OK    2.79\n    test_router_add_gateway_dup_subnet1_returns_400              OK    0.42\n    test_router_add_gateway_dup_subnet2_returns_400              OK    0.52\n    test_router_add_gateway_invalid_network_returns_404          OK    0.23\n    test_router_add_gateway_net_not_external_returns_400         OK    0.29\n    test_router_add_gateway_no_subnet_returns_400                OK    0.29\n    test_router_add_gateway_tenant_ctx                           OK    0.65\n    test_router_add_interface_dup_subnet1_returns_400            OK    0.43\n    test_router_add_interface_dup_subnet2_returns_400            OK    0.55\n    test_router_add_interface_no_data_returns_400                OK    0.21\n    test_router_add_interface_overlapped_cidr_returns_400        OK    3.29\n    test_router_add_interface_port                               OK    0.39\n    test_router_add_interface_port_bad_tenant_returns_404        OK    0.42\n    test_router_add_interface_subnet                             OK    0.39\n    test_router_add_interface_subnet_with_bad_tenant_returns_404 OK    0.37\n    test_router_add_interface_subnet_with_port_from_other_tenant OK    0.51\n    test_router_create                                           OK    0.19\n    test_router_create_with_gwinfo                               OK    0.59\n    test_router_delete                                           OK    0.19\n    test_router_delete_subnet_inuse_returns_409                  OK    0.34\n    test_router_delete_with_floatingip_existed_returns_409       Build timed out (after 30 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.h1380RiJxz\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/4\n[SCP] Copying console log.\n\n\n','<547599352.123.1365835663585.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1699061027.27827558.1385469695209.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-26 07:41:35',-18000,'2013-11-26 12:41:35',NULL,'[Openstack] devstack log files','\n\n----- Original Message -----\n> Hi,\n> \n> \n> Im running devstack, but cant seem to find the log files. I cannot\n> find them in /opt/stack, nor in /var/log.\n> \n> Do I need to do some configuring before devstack will create log\n> files, or am i simply looking in the wrong location ?\n\nBy default devstack uses screen logging, which you can see via:\n\n  $ screen -r\n  # navigate to the required service:\n  ctrl+a \"\n  # enter copy-mode to page-up or search\n  ctrl+a [\n  # search backward for a pattern\n  ?pattern\n\n... etc.\n\nIf you want logging output to be preserved to a file instead,\nset LOGFILE in your localrc in advance of running stack.sh.\n\nFor more details, see:\n\n  http://devstack.org/localrc.html\n\nCheers,\nEoghan\n\n\n\n \n> Thanks.\n> \n> \n> \n> Regards,\n> \n> \n> John Smith.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CADJDz9gkhvNg-shhXcpTBP8zhe654qxPOS2YHn40DXjxTd3NGw@mail.gmail.com>',NULL),('<1699401936.256.1356740151472.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-29 00:15:51',0,'2012-12-29 00:15:51',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #89','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/89/>\n\n\n\n','<1390090380.237.1356655740076.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<169993730.0.1374127488705.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-18 06:04:48',0,'2013-07-18 06:04:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #290','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/290/>\n\n------------------------------------------\n[...truncated 2705 lines...]\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_novaclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_novaclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): prettytable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 4))\nRequirement already satisfied (use --upgrade to upgrade): requests>=0.8 in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 5))\nRequirement already satisfied (use --upgrade to upgrade): simplejson in /usr/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 6))\nRequirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from -r python_novaclient.egg-info/requires.txt (line 7))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_novaclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_novaclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_novaclient.egg-info/requires.txt\nwriting python_novaclient.egg-info/PKG-INFO\nwriting top-level names to python_novaclient.egg-info/top_level.txt\nwriting dependency_links to python_novaclient.egg-info/dependency_links.txt\nwriting entry points to python_novaclient.egg-info/entry_points.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwriting manifest file \'python_novaclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-novaclient.egg-link (link to .)\nAdding python-novaclient 2.13.0.121.gaf7ca70 to easy-install.pth file\nInstalling nova script to /usr/local/bin\n\nInstalled /opt/stack/new/python-novaclient\nProcessing dependencies for python-novaclient==2.13.0.121.gaf7ca70\nSearching for six==1.3.0\nBest match: six 1.3.0\nsix 1.3.0 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for requests==1.2.2\nBest match: requests 1.2.2\nrequests 1.2.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for prettytable==0.7.2\nBest match: prettytable 0.7.2\nprettytable 0.7.2 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for iso8601==0.1.4\nBest match: iso8601 0.1.4\nAdding iso8601 0.1.4 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-novaclient==2.13.0.121.gaf7ca70\n+ is_service_enabled swift glance\n+ services=\'swift glance\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,swift, ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-swiftclient /opt/stack/new/python-swiftclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-swiftclient\n+ GIT_DEST=/opt/stack/new/python-swiftclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-swiftclient ]]\n+ [[ \'\' == \\y\\e\\s ]]\n+ setup_develop /opt/stack/new/python-swiftclient\n+ [[ False = True ]]\n+ SUDO_CMD=sudo\n+ cd /opt/stack/new/python-swiftclient\n+ python setup.py egg_info\nrunning egg_info\ncreating python_swiftclient.egg-info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\n++ awk \'/^.+/ {print \"-f \" $1}\' python_swiftclient.egg-info/dependency_links.txt\n+ raw_links=\n++ echo\n++ xargs\n+ depend_links=\n++ \'[\' \'!\' -r python_swiftclient.egg-info/requires.txt \']\'\n++ echo \'-r *-info/requires.txt\'\n+ require_file=\'-r *-info/requires.txt\'\n+ pip_install -r python_swiftclient.egg-info/requires.txt\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ -z -r python_swiftclient.egg-info/requires.txt ]]\n+ [[ -z deb ]]\n+ [[ False = True ]]\n+ SUDO_PIP=sudo\n+ [[ deb = \\d\\e\\b ]]\n+ CMD_PIP=/usr/bin/pip\n+ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/bin/pip install --use-mirrors -r python_swiftclient.egg-info/requires.txt\nRequirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): pbr>=0.5,<0.6 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg (from -r python_swiftclient.egg-info/requires.txt (line 2))\nRequirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from -r python_swiftclient.egg-info/requires.txt (line 3))\nRequirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->-r python_swiftclient.egg-info/requires.txt (line 1))\nRequirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from pbr>=0.5,<0.6->-r python_swiftclient.egg-info/requires.txt (line 2))\nCleaning up...\n+ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\nrunning develop\nChecking .pth file support in /usr/local/lib/python2.7/dist-packages/\n/usr/bin/python -E -c pass\nTEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\nrunning egg_info\nwriting requirements to python_swiftclient.egg-info/requires.txt\nwriting python_swiftclient.egg-info/PKG-INFO\nwriting top-level names to python_swiftclient.egg-info/top_level.txt\nwriting dependency_links to python_swiftclient.egg-info/dependency_links.txt\nreading manifest template \'MANIFEST.in\'\nwarning: no files found matching \'AUTHORS\'\nwarning: no files found matching \'ChangeLog\'\nwarning: no files found matching \'*\' under directory \'tools\'\nwriting manifest file \'python_swiftclient.egg-info/SOURCES.txt\'\nrunning build_ext\nCreating /usr/local/lib/python2.7/dist-packages/python-swiftclient.egg-link (link to .)\nAdding python-swiftclient 1.5.0.8.g2f84a4e to easy-install.pth file\nInstalling swift script to /usr/local/bin\n\nInstalled /opt/stack/new/python-swiftclient\nProcessing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\nSearching for simplejson==2.3.2\nBest match: simplejson 2.3.2\nAdding simplejson 2.3.2 to easy-install.pth file\n\nUsing /usr/lib/python2.7/dist-packages\nSearching for pbr==0.5.18\nBest match: pbr 0.5.18\nProcessing pbr-0.5.18-py2.7.egg\nRemoving pbr 0.5.18 from easy-install.pth file\npbr 0.5.18 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/pbr-0.5.18-py2.7.egg\nSearching for d2to1==0.2.10\nBest match: d2to1 0.2.10\nProcessing d2to1-0.2.10-py2.7.egg\nRemoving d2to1 0.2.10 from easy-install.pth file\nd2to1 0.2.10 is already the active version in easy-install.pth\n\nUsing /usr/local/lib/python2.7/dist-packages/d2to1-0.2.10-py2.7.egg\nSearching for setuptools-git==1.0\nBest match: setuptools-git 1.0\nAdding setuptools-git 1.0 to easy-install.pth file\n\nUsing /usr/local/lib/python2.7/dist-packages\nSearching for distribute==0.6.24dev-r0\nBest match: distribute 0.6.24dev-r0\nAdding distribute 0.6.24dev-r0 to easy-install.pth file\nInstalling easy_install script to /usr/local/bin\nInstalling easy_install-2.7 script to /usr/local/bin\n\nUsing /usr/lib/python2.7/dist-packages\nFinished processing dependencies for python-swiftclient==1.5.0.8.g2f84a4e\n+ is_service_enabled quantum nova\n+ services=\'quantum nova\'\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ q- ]]\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch, =~ ,nova, ]]\n+ [[ nova == \\n\\o\\v\\a ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,n-net,swift,cinder,c-api,c-vol,c-sch =~ n- ]]\n+ return 0\n+ git_clone https://github.com/openstack/python-neutronclient /opt/stack/new/python-quantumclient master\n+ [[ False = \\T\\r\\u\\e ]]\n+ GIT_REMOTE=https://github.com/openstack/python-neutronclient\n+ GIT_DEST=/opt/stack/new/python-quantumclient\n+ GIT_REF=master\n+ echo master\n+ egrep -q \'^refs\'\n+ [[ ! -d /opt/stack/new/python-quantumclient ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ exit 1\n+ clean\n+ local r=1\n++ jobs -p\n+ kill\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/rabbitmq/rabbit at devstack-1374121844-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/rabbitmq/rabbit at devstack-1374121844.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/290/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<2044999537.20.1374041055681.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<169B816E-000F-4B0A-90EF-47D6E90BC4B6@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 14:27:36',-25200,'2013-10-29 21:27:36',NULL,'[openstack-dev] HK Neutron Icehouse Design Meetings','Here is the link to it - http://icehousedesignsummit.sched.org/overview/type/neutron\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\nOn Oct 29, 2013, at 1:47 PM, Hemanth Ravi <hemanthraviml at gmail.com> wrote:\n\n> Hi,\n> \n> Is there a schedule published for the Neutron Icehouse design meetings listed at http://summit.openstack.org/\n> \n> Thanks,\n> -hemanth\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/994a1da3/attachment.html>\n\n','<CAP3yDp3LSN8aaHjp+vJi1sYdhFoqcdKUBDGXv2XwPYYM9rddyw@mail.gmail.com>',NULL),('<169B8F4FCC41864EAE0959D6FB7BBD97233051A3@G1W3782.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-24 08:36:27',0,'2014-03-24 08:36:27',NULL,'[Openstack] Keystone support for simultaneous AD/LDAP domain','Hi All,\n   I have a generic deployment, where I would like to configure  Keystone with AD, LDAP  and SQL domain as my identity backend. Such that users  from AD,LDAP and SQL can have access to my swift resources. Let me know if this feasible in current Ice House release or are there any plans for future release.\n\nRegards,\nAllauddin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140324/a332c923/attachment.html>\n\n',NULL,NULL),('<169B8F4FCC41864EAE0959D6FB7BBD9723305835@G1W3782.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-26 06:41:53',0,'2014-03-26 06:41:53',NULL,'[Openstack] Keystone support for simultaneous AD/LDAP domain','Thanks Adam for the information. Just curious to know, is it \'domain_specific_driver\' implementation that existed in Havana, which will enable to have multiple identity provider backends.\n        I had installed IceHouse-2, and was trying to configure multiple identity provider backend. But in keystone.log, saw below warning.\n\nWARNING keystone.identity.core [-] Running an experimental and unsupported configuration (domain_specific_drivers_enabled = True); this will result in known issues.\n\nThanks in advance...\nRegards,\nAllauddin\n\nFrom: Adam Lawson [mailto:alawson at aqorn.com]\nSent: Tuesday, March 25, 2014 1:50 AM\nTo: Mohammed, Allauddin\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Keystone support for simultaneous AD/LDAP domain\n\nFor now you have to pick one. With Icehouse Release 3, federation of multiple IdP\'s (multiple Identity Provider back-ends) will be supported with Keystone.\n\nHope this helps.\n\nMahalo,\nAdam\n\n\nAdam Lawson\nAQORN, Inc.\n427 North Tatnall Street\nSte. 58461\nWilmington, Delaware 19801-2230\nToll-free: (888) 406-7620\n[http://www.aqorn.com/images/logo.png]\n\nOn Mon, Mar 24, 2014 at 1:36 AM, Mohammed, Allauddin <allauddin.mohammed at hp.com<mailto:allauddin.mohammed at hp.com>> wrote:\nHi All,\n   I have a generic deployment, where I would like to configure  Keystone with AD, LDAP  and SQL domain as my identity backend. Such that users  from AD,LDAP and SQL can have access to my swift resources. Let me know if this feasible in current Ice House release or are there any plans for future release.\n\nRegards,\nAllauddin\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140326/866a559d/attachment.html>\n\n','<CAJfWK4-=JgVSF6=y5wcgePptJ-HZg3_ju8sMw9ovaxpRSJ-Mig@mail.gmail.com>',NULL),('<169B8F4FCC41864EAE0959D6FB7BBD9723308013@G2W2433.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-02 10:38:03',0,'2014-04-02 10:38:03',NULL,'[Openstack] Feasibility of using Keystone Folsom + Swift IceHouse','Hi All,\n    Is it possible to use keystone (Folsom)  + Swift (IceHouse)?  Will it be compatible to each other?\n\nThanks in advance\n\nRegards,\nMohammed Allauddin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140402/d64fc8f8/attachment.html>\n\n',NULL,NULL),('<169B8F4FCC41864EAE0959D6FB7BBD972331588B@G1W3640.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-16 05:15:39',0,'2014-04-16 05:15:39',NULL,'[Openstack] Query on container sync','Hi All,\n    I had a question regarding container sync. Can container sync be accomplished using keystone authentication and normal PUT requests as coming from an external client, instead of using current sync-key based authentication.\n\nRegards,\nMohammed Allauddin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140416/ef23db03/attachment.html>\n\n',NULL,NULL),('<169B8F4FCC41864EAE0959D6FB7BBD97233158C8@G1W3640.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-04-16 06:13:30',0,'2014-04-16 06:13:30',NULL,'[Openstack] Query on container sync','Since I have seen some cloud vendor?s don?t support container sync from another private cloud?s\n\nFrom: Hugo [mailto:tonytkdk at gmail.com]\nSent: Wednesday, April 16, 2014 11:19 AM\nTo: Mohammed, Allauddin\nCc: openstack at lists.openstack.org\nSubject: Re: [Openstack] Query on container sync\n\nAny specific reason in this way for container-sync?\n\n\n\nFrom Hugo\'s iPhone\n\nOn 2014/4/16, at ??1:15, \"Mohammed, Allauddin\" <allauddin.mohammed at hp.com<mailto:allauddin.mohammed at hp.com>> wrote:\nHi All,\n    I had a question regarding container sync. Can container sync be accomplished using keystone authentication and normal PUT requests as coming from an external client, instead of using current sync-key based authentication.\n\nRegards,\nMohammed Allauddin\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140416/96c97b1f/attachment.html>\n\n','<1215E66F-7E94-4C66-B678-D994B3551064@gmail.com>',NULL),('<169B8F4FCC41864EAE0959D6FB7BBD9725E22732@G2W2433.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-04 09:30:00',0,'2014-06-04 09:30:00',NULL,'[Openstack] Not able to create containers using keystone V3 for\n	swift','Hi All,\n   I am trying to create containers using X-Auth-Token generated using v3, but I am getting below errors in keystone log.\n\nDEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:271\nDEBUG keystone.common.wsgi [-] arg_dict: {} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181\nWARNING keystone.common.wsgi [-] Authorization failed. Could not find user, swift. from 10.21.14.11\nINFO eventlet.wsgi.server [-] 10.21.14.11 - - [04/Jun/2014 08:47:05] \"POST /v2.0/tokens HTTP/1.1\" 401 288 0.018013\n\n\nAny pointers?\n\nRegards,\nMohammed Allauddin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140604/1abd2c38/attachment.html>\n\n',NULL,NULL),('<169B8F4FCC41864EAE0959D6FB7BBD9725E2479C@G2W2433.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-04 14:56:07',0,'2014-06-04 14:56:07',NULL,'[Openstack] Does Ice House swift supports keystone V3?','Hi All,\n    Does Ice House version of swift supports keystone V3?\n\n\nRegards,\nAllauddin\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140604/94a772f8/attachment.html>\n\n',NULL,NULL),('<16A59581-0689-44F5-9368-DCE9977191CC@yahoo-inc.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2013-11-12 00:56:47',0,'2013-11-12 00:56:47',NULL,'[OpenStack-Infra] taskflow requirements','Sounds good,\n\nWill do when I get back from HK, still here exploring :-)\n\nSent from my really tiny device...\n\n> On Nov 11, 2013, at 10:17 PM, \"Monty Taylor\" <mordred at inaugust.com> wrote:\n> \n> Ok. Cool. Let\'s just put an upper bound on it for now then (mainly\n> because it\'s listed as 0.1, so that version to me suggests that it might\n> still have breaking API churn)\n> \n>> On 11/11/2013 07:53 AM, Joshua Harlow wrote:\n>> I can put an upper bound on the version, that\'s fine with me. I\'d rather not avoid adding taskflow to wait until some new preemptive gating process is in place. That doesn\'t exactly feel fair to the people creating taskflow or the people using it, especially since people are integrating it at this moment and it would be sad for their work to be lost due to a requirement line.\n>> \n>> As for part of oslo, cc\'ing Doug since from my talks with him seem to be that it\'s just a library and to encourage the growth of useful libraries the red tape isn\'t needed (aka, taskflow has no strong ties to oslo and I\'m not sure it should). \n>> \n>> Sent from my really tiny device...\n>> \n>>> On Nov 11, 2013, at 7:33 PM, \"Monty Taylor\" <mordred at inaugust.com> wrote:\n>>> \n>>> There is a change up to add taskflow to the global requirements. I have\n>>> no problem with this in principle, but it\'s one more that\'s in the set\n>>> of things like pecan, wsme and friends that are in the set of things\n>>> that Sean talked about in preemptively gate the universe.\n>>> \n>>> I\'d like to not add it until we have a plan for at least assymetrical\n>>> gating, so that changes to taskflow at least can\'t break cinder and friends.\n>>> \n>>> Further, I think we might need to discuss how to include libraries such\n>>> as this. Should taskflow be a part of oslo?\n>> \n\n\n','<5280E6C8.1000002@inaugust.com>',NULL),('<16A6274A-98BB-444F-BCC3-2C5682AD7F57@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-05 08:09:17',-28800,'2013-12-05 16:09:17',NULL,'[openstack-dev] request-id in API response','\nOn Dec 5, 2013, at 1:36 AM, Maru Newby <marun at redhat.com> wrote:\n\n> \n> On Dec 3, 2013, at 12:18 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:\n> \n>> \n>> \n>> \n>> On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson <me at not.mn> wrote:\n>> Just to add to the story, Swift uses \"X-Trans-Id\" and generates it in the outer-most \"catch_errors\" middleware.\n>> \n>> Swift\'s catch errors middleware is responsible for ensuring that the transaction id exists on each request, and that all errors previously uncaught, anywhere in the pipeline, are caught and logged. If there is not a common way to do this, yet, I submit it as a great template for solving this problem. It\'s simple, scalable, and well-tested (ie tests and running in prod for years).\n>> \n>> https://github.com/openstack/swift/blob/master/swift/common/middleware/catch_errors.py\n>> \n>> Leaving aside error handling and only focusing on the transaction id (or request id) generation, since OpenStack services are exposed to untrusted clients, how would you propose communicating the appropriate transaction id to a different service? I can see great benefit to having a glance transaction ID carry through to Swift requests (and so on), but how should the transaction id be communicated? It\'s not sensitive info, but I can imagine a pretty big problem when trying to track down errors if a client application decides to set eg the X-Set-Transaction-Id header on every request to the same thing.\n>> \n>> -1 to cross service request IDs, for the reasons John mentions above.\n>> \n>> \n>> Thanks for bringing this up, and I\'d welcome a patch in Swift that would use a common library to generate the transaction id, if it were installed. I can see that there would be huge advantage to operators to trace requests through multiple systems.\n>> \n>> Another option would be for each system that calls an another OpenStack system to expect and log the transaction ID for the request that was given. This would be looser coupling and be more forgiving for a heterogeneous cluster. Eg when Glance makes a call to Swift, Glance cloud log the transaction id that Swift used (from the Swift response). Likewise, when Swift makes a call to Keystone, Swift could log the Keystone transaction id. This wouldn\'t result in a single transaction id across all systems, but it would provide markers so an admin could trace the request.\n>> \n>> There was a session on this at the summit, and although the notes are a little scarce this was the conclusion we came up with.  Every time a cross service call is made, we will log and send a notification for ceilometer to consume, with the request-ids of both request ids.  One of the benefits of this approach is that we can easily generate a tree of all the API calls that are made (and clearly show when multiple calls are made to the same service), something that just a cross service request id would have trouble with.\n> \n> Is wise to trust anything a client provides to ensure traceability?  If a user receives a request id back from Nova, then submits that request id in an unrelated request to Neutron, the traceability would be effectively corrupted.  If the consensus is that we don\'t want to securely deliver request ids for inter-service calls, how about requiring a service to log its request id along with the request id returned from a call to another service to achieve the a similar result?\n\nYes, this is what I was proposing. I think this is the best path forward.\n\n\n> The catch is that every call point (or client instantiation?) would have to be modified to pass the request id instead of just logging at one place in each service.  Is that a cost worth paying?\n\nPerhaps this is my ignorance of how other projects work today, but does this not already happen? Is it possible to get a response from an API call to an OpenStack project that doesn\'t include a request id?\n\n> \n> \n> m.\n> \n> \n>> \n>> https://etherpad.openstack.org/p/icehouse-summit-qa-gate-debugability \n>> \n>> \n>> With that in mind I think having a standard x-openstack-request-id makes things a little more uniform, and means that adding new services doesn\'t require new logic to handle new request ids.\n> \n> \n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/a5962e69/attachment-0001.pgp>\n\n','<7FF8ABE0-73DD-4687-BC3A-91CB50F937F0@redhat.com>',NULL),('<16A95FC1-0A38-4BB1-8EFA-5AF2BDBB8A4D@pilotti.it>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 15:22:39',10800,'2012-09-05 12:22:39',NULL,'[openstack-dev] Hyper-V meeting','Hi Vish,\n\nI\'m going to commit it for review by tomorrow.\n\n\nAlessandro Pilotti\nCloudbase Solutions\n-------------------------------------\nMVP ASP.Net / IIS\nWindows Azure Insider\nRed Hat Certified Engineer \n-------------------------------------\n\n> Hey I meant to jump into the meeting today but I missed it. There was a modification of the way we do resource reservations that went in, and Hyper-V wasn\'t updated properly when the other hypervisors were updated. I wanted to make sure you knew about it so someone could get it fixed. I think it will be relatively simple.\n> \n> Essentially update_available_resource was changed to get_available_resource. Let me know if you guys can make the change or if we need to find someone in core to help out.\n> \n> Vish\n> \n> On Sep 4, 2012, at 7:51 AM, Peter Pouliot <ppouliot at microsoft.com> wrote:\n> \n> > Hi all,\n> > \n> > Quick meeting today, as I\'m still out of the office.\n> > \n> > Topics for discussion.\n> > \n> > Pedro\'s Cinder work.\n> > \n> > General Discussion.\n> > \n> > \n> > \n> >\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120905/63bf6baa/attachment.html>\n\n','<504740F0.4080301@openstack.org>',NULL),('<16A998E9-0606-49D7-8B81-AA263162F72B@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-22 18:50:10',0,'2014-08-22 18:50:10',NULL,'[openstack-dev] [neutron] Need community weigh-in on requests-mock','Hi! Need to get the community to weigh in on this?\n\nIn Neutron there currently is no mock library for the Requests package. During Icehouse, I created unit tests that used the httmock package (a context-library based Requests mock). However, the community did not want me to add this to global requirements, because there was httpretty (a URL registration based mock) already approved for use (but not in Neutron). As a result, I disabled the UTs (renaming the module to have a ?no? prefix).\n\nInstead of modifying the UT to work with httpretty, and requesting that httpretty be added to Neutron test-requirements, I waited, as there was discussion on replacing httpretty.\n\nFast forward to now, and there is a new requests-mock package that has been implemented, added to global requirements, and is being used in keystone client and nova client projects.  My goal is to make use of the new mock library, as it has become the library of choice.\n\nI have migrated my UT to use the requests-mock package, and would like to gain approval to add requests-mock to Neutron. I have two commits out for review. The first, https://review.openstack.org/#/c/115107/, is to add requests-mock to test-requirements for Neutron. The second,https://review.openstack.org/#/c/116018/, has the UT module reworked to use requests-mock, AND includes the addition of requests-mock to test-requirements (so that there is one commit showing the use of this new library - originally, I had just the UT, but there was a request to join the two changes).\n\nCommunity questions:\n\nIs it OK to add requests-mock to Neutron test-requirements?\nIf so, would you rather see this done as two commits (one for the package, one for the UT), or one combined commit?\n\nCores, you can ?vote/comment? in the reviews, so that I can proceed in the right direction.\n\nThanks for your consideration!\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/cf23c4bc/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140822/cf23c4bc/attachment.pgp>\n\n',NULL,NULL),('<16AD01F8DFFDCE4CAD97D3AC11F247FD0E9F8FC5@G4W3228.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-06 18:19:14',0,'2013-06-06 18:19:14',NULL,'[openstack-dev] [keystone] Domain admin roles','Thank you guys!\n\nAlso, more than the add/delete/update services, the list services could operate based on the domain_id of the user that is calling it. Today there are the query strings to filter the search, but what happens if the user doesn?t use them? He will be able to list all projects from all domains, for example.\n\n\nTo deal with the domain_id and target.domain_id, what do you think if we take this information based on the user token_id? So, will not be necessary the user send the domain_id in the request.\n\n\nThanks,\n\nOtavio\n\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com]\nSent: quinta-feira, 6 de junho de 2013 12:06\nTo: OpenStack Development Mailing List\nCc: Knuppe, Gustavo (Brazil R&D-ECL); Gaspareto, Otavio; Rosa, Leandro (Brazil R&D-ECL)\nSubject: Re: [openstack-dev] [keystone] Domain admin roles\n\nTo expand on Dolph\'s comments, the restriction in Grizzly  is that you can include a domain_id check in your policy file against apis - however, this will only work if the objects in the parameters of the api calls includes the domain_id (so that it can be checked by the policy engine).  So for instance you can restrict the creation of users, groups and projects to the domain scope of a user by including a policy rule like:\n\n\"domain_id:%(user.domain_id)s\"\n(substitute group or project for user in the above as required).\n\nThe issue is, of course, that this only works for create (since you are passing the object to create), but doesn\'t work for update or delete.  Extending keystone to enable rule definition that checks the object the api will operate on is what we are working on for Havana.\n\nThere is a blueprint for this already : https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target\n\nHenry\n\nOn 6 Jun 2013, at 15:42, Dolph Mathews wrote:\n\nWe\'re on our way to supporting domain-based role assignments in policy.json, but it\'s not quite there in grizzly. Related bug:\n\n  https://bugs.launchpad.net/keystone/+bug/1187198\n\n(this should probably be turned into a blueprint)\n\n-Dolph\n\nOn Thu, Jun 6, 2013 at 9:10 AM, Gaspareto, Otavio <otavio.barcelos-gaspareto at hp.com<mailto:otavio.barcelos-gaspareto at hp.com>> wrote:\nHi Dolph/Guang,\n\nI\'m implementing here a new role, called domain_admin, where the user with this role will be a manager inside his domain. For this, I\'ve created this entry into the policy.json file:\n\n\"domain_admin_required\" : [[\"role:domain_admin\", \"domain_id:%(domain_id)s\"]],\n\nTesting some services marked with this rule, and using an user that is a domain_admin I could perform operations in other domains, like create project.\n\nSo, my question: this rule \"domain_id:%(domain_id)s\" shouldn\'t block operations on domains different from mine?\n\nAnother info, I\'m using domain scoped authentication.\n\nThanks,\n\nOtavio Gaspareto\nSoftware Designer\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/29b2d4f3/attachment.html>\n\n',NULL,NULL),('<16AD01F8DFFDCE4CAD97D3AC11F247FD131247B2@G4W3228.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 19:58:00',0,'2013-08-08 19:58:00',NULL,'[openstack-dev] Problem using Keystone split backend','\nHi all,\n\nI\'m using the Keystone split backend code (H2) with both identity and assignment using SQL drivers. During the process of authentication thru Horizon, I\'m getting the following error in the log:\n\nTraceback (most recent call last):\n  File \"/usr/lib/python2.6/site-packages/keystone/common/wsgi.py\", line 240, in __call__\n    result = method(context, **params)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 80, in authenticate\n    context, auth)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 257, in _authenticate_local\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 371, in _get_project_roles_and_ref\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/identity/core.py\", line 123, in get_roles_for_user_and_project\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 125, in get_roles_for_user_and_project\n    user_role_list = _get_user_project_roles(user_id, project_ref)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 107, in _get_user_project_roles\n    metadata_ref.get(\'roles\', {}), False)\n  File \"/usr/lib/python2.6/site-packages/keystone/common/manager.py\", line 44, in _wrapper\n    return f(*args, **kw)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 216, in _roles_from_role_dicts\n    if ((not d.get(\'inherited_to\') and not inherited) or\nAttributeError: \'unicode\' object has no attribute \'get\'\n\n\nI\'m using a fresh tenant/role/user that were created using the V2.0. Has anybody faced this problem too?\n\nThanks.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130808/32b198fe/attachment.html>\n\n',NULL,NULL),('<16AD01F8DFFDCE4CAD97D3AC11F247FD13124B07@G4W3228.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-09 16:43:01',0,'2013-08-09 16:43:01',NULL,'[openstack-dev] Problem using Keystone split backend','Guys,\n\nI filed a bug https://bugs.launchpad.net/keystone/+bug/1210590 to address this problem. Also, I posted a comment with the solution I found to bypass the problem.\n\nThanks,\n\n--Otavio\n\nFrom: Henry Nash [mailto:henryn at linux.vnet.ibm.com]\nSent: sexta-feira, 9 de agosto de 2013 04:22\nTo: OpenStack Development Mailing List\nSubject: Re: [openstack-dev] Problem using Keystone split backend\n\nYep, agreed, certainly my code....if you can provide as much info in the bug as possible, and I\'ll get straight on it.\n\nHenry\nOn 9 Aug 2013, at 00:14, Adam Young wrote:\n\n\nOn 08/08/2013 03:58 PM, Gaspareto, Otavio wrote:\n\nHi all,\n\nI\'m using the Keystone split backend code (H2) with both identity and assignment using SQL drivers. During the process of authentication thru Horizon, I\'m getting the following error in the log:\n\nTraceback (most recent call last):\n  File \"/usr/lib/python2.6/site-packages/keystone/common/wsgi.py\", line 240, in __call__\n    result = method(context, **params)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 80, in authenticate\n    context, auth)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 257, in _authenticate_local\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/token/controllers.py\", line 371, in _get_project_roles_and_ref\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/identity/core.py\", line 123, in get_roles_for_user_and_project\n    user_id, tenant_id)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 125, in get_roles_for_user_and_project\n    user_role_list = _get_user_project_roles(user_id, project_ref)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 107, in _get_user_project_roles\n    metadata_ref.get(\'roles\', {}), False)\n  File \"/usr/lib/python2.6/site-packages/keystone/common/manager.py\", line 44, in _wrapper\n    return f(*args, **kw)\n  File \"/usr/lib/python2.6/site-packages/keystone/assignment/core.py\", line 216, in _roles_from_role_dicts\n    if ((not d.get(\'inherited_to\') and not inherited) or\n\n\nThis looks like a bug, and, if I guess correctly, Henry Nash\'s inheritance change is to blame.\n\ncommit 7f4891ddc3da7457df09c0cc8bbfe8a888063feb\n\" Implement role assignment inheritance (OS-INHERIT extension)\"\n\nPlease file it in Launchpad,\n\n\nThere are known issues with Unicode and LDAP, and I suspect you are tripping over that.\n\n\n\nAttributeError: \'unicode\' object has no attribute \'get\'\n\n\nI\'m using a fresh tenant/role/user that were created using the V2.0. Has anybody faced this problem too?\n\nThanks.\n\n\n\n\n_______________________________________________\n\nOpenStack-dev mailing list\n\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\n\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130809/5ad94dc7/attachment.html>\n\n','<1DB32ADA-C2C3-4B03-9322-063A769DE775@linux.vnet.ibm.com>',NULL),('<16afca1e.00001128.00000020@VMWARE-5KNQC8NC.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-06 15:12:24',-28800,'2012-12-06 23:12:24',NULL,'[openstack-dev] 答复: [Quantum][LBaaS] vip_id in pool creation API','Hi Youcef,\n\nThat?s exactly what I suggest that don?t place a ?vip_id? inside pool\ncreation payload.  In this way, ?vip_id? is a ready-only property in\npool and we can avoid the case that you mentioned.\n\nCurrently API spec said that ?vip_id? could be provided during pool\ncreation (POST) call. It potentially allows someone to create a pool to be\nassociated with a VIP which still think is associated with another pool.\n\n\n\nCorrect me if my statement is wrong.  thanks\n\n\n\nThanks\n\nLeon\n\n???: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]\n????: 2012?12?5? 11:56\n???: Leon Cui\n??: openstack-dev at lists.openstack.org\n??: RE: [Quantum][LBaaS] vip_id in pool creation API\n\n\n\nHi Leon,\n\n\n\nThe reason the spec said this is to ensure that the information in the VIP\n(which pool_id is used by the VIP) and the information in the pool (to\nwhich VIP the pool belongs, if it belongs to one), never get out-of-sync.\nIf we allowed separate updates, then someone can update the pool to be\nassociated with a new VIP, but the old VIP still thinks the pool is\nassociated with it.\n\n\n\nThanks,\n\nYoucef\n\n\n\n\n\n\n\nFrom: Leon Cui [mailto:lcui at vmware.com]\nSent: Wednesday, December 5, 2012 10:24 AM\nTo: Youcef Laribi\nCc: openstack-dev at lists.openstack.org\nSubject: [Quantum][LBaaS] vip_id in pool creation API\n\n\n\nHi Youcef,\n\nIn Create_Pool API, the spec says ?Optionally, you can also assign the\npool to a vip during creation time, by specifying the vip_id attribute.?.\nI don?t think we should allow user to do it because it means that it will\nmodify the ?pool_id? of a VIP in an implicitly way.  I suggest that\ndon?t allow user to provide vip_id during pool creation api. User can\nalways to update the VIP by given a different pool_id.\n\n\n\nWhat do you think?\n\n\n\nThanks\n\nLeon\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121206/1f61c3af/attachment.html>\n\n','<7B14C05615DB43488B85E143995BD549010A57E62C43@LONPMAILBOX01.citrite.net>',NULL),('<16B3B16D-46DC-4456-9267-63B19473DE45@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-22 17:13:30',-25200,'2014-05-23 00:13:30',NULL,'[openstack-dev] [neutron][group-based-policy] Should we revisit\n	the priority of group-based policy?','\nOn May 22, 2014, at 4:35 PM, Mandeep Dhami <dhami at noironetworks.com> wrote:\n\n> > each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback.\n> \n> At least two core neutron members were involved in creating the PoC, and at least two more cores were involved in reviews at various times. In addition to them, senior developers from at least seven networking companies were involved in developing this code. I concede that this code was on github for a few weeks, as that made the prototyping faster and allowed us to \"fail faster\", but it was open and reviewed with the team above (and with the cores in that team). Based on our learning from that prototype activity, and feedback of those cores, we are upstreaming the improved \"production code\" to gerrit. All that involvement from the neutron core reviewers was critical in keeping the larger PoC team above focused on neutron norms and expectations from design and code.\n\nThe feedback from reviewers needs to be provided on openstack infrastructure rather than outside it so that it is both visible to all reviewers (not just those directly involved) and that an enduring history of the process is retained.  These requirements were not met in working in github on the POC, regardless of your protestations of how \'open\' that work was and of who was involved.  This isn\'t to suggest that out-of-tree prototyping isn\'t useful - of course it is.  But I think it important to recognize that out-of-tree development is unlikely to be an effective way to develop code that can be easily merged to Neutron, and that the project can ill-afford the additional review cost it is likely to impose.\n\nAs such, and as was agreed to in the irc meeting this morning, the way forward is to recognize that the POC is best considered a prototype useful in informing efforts to iterate in the open.\n\n\nm.\n\n\n> \n> \n> \n> On Thu, May 22, 2014 at 4:03 PM, Maru Newby <marun at redhat.com> wrote:\n> On May 22, 2014, at 1:59 PM, Mandeep Dhami <dhami at noironetworks.com> wrote:\n> \n> >\n> > Maru\'s concerns are that:\n> > 1. It is large\n> > 2. It is complex\n> \n> As per the discussion in the irc meeting today, I hope it is clear now that eventual size and complexity are not real issue.  Rather, I am concerned at how we get there.\n> \n> I keep talking about \'iterating in the open\', and want to make it clear what I mean by this.  It involves proposing a reviewable patch to openstack gerrit, working with reviewers to get the patch merged, and then incorporating their feedback into the overall design to drive the implementation of future patches.\n> \n> \'Iterating in the open\' does not imply working outside of gerrit to create a monolithic codebase that needs to be manually decomposed into reviewable chunks at the end.  I understand that this may be an effective way to create a POC, but it is not an effective way to produce code that can be merged into Neutron.  Core reviewers have a mandate to ensure the quality of every patch, and their feedback is likely to have an impact on subsequent implementation.\n> \n> \n> >\n> > And Armando\'s related concerns are:\n> > 3. Could dev/review cycles be better spent on refactoring\n> > 4. If refactored neutron was available, would a simpler option become more viable\n> >\n> > Let me address them in that order.\n> >\n> > 1. Re: It is large\n> > Group policy has an ambitious goal  - provide devop teams with policy based controls that are usable at scale and with automation (say a higher governance layer like Congress). The fact that meeting a large challenge requires more code is natural. We understand that challenge, and that is why we did a prototype (as PoC that was demonstrated on the summit). And based on that learning we are incrementally creating patches for building the group based policy. Just because a task is large, we as neutron can not shy away from building it. That will only drive people who need it out side neutron (as we are seeing with the frustration that the LBaaS team had because they have a requirement that is \"large\" as well).\n> \n> Again, the amount of code is not the problem.  How code is introduced into the tree, and how the design is socialized (both with developers and users), _is_ of critical importance.  Neutron is not alone in requiring an \'iterate in the open\' approach - it is a characteristic common to many open source projects.\n> \n> \n> >\n> > 2. Re: It is complex\n> > Complexity depends on the context. Our goal was to make the end-user\'s life simpler (and more automated). To achieve some of that simplicity, we required a little more complexity in the implementation. We decide to make that arbitrage - a little higher complexity in implementation to allow for simpler usage. But we were careful and did not want to impose that complexity on every use case - hence a lot of that is optional (and exercised only if the use case needs it). Unfortunately the model, has to model all of it so as it not add complexity later in upgrade and backward compatibility issues. We choose to do architecture upfront, and then implement it incrementally.\n> \n> Doing upfront architecture is fine, so long as the architecture also evolves in response to feedback from the review process in gerrit.  Similarly, incremental implementation is not enough - it needs to happen in gerrit.  And to be clear, the tool is not the critical factor.  When I say gerrit, I mean that each patch needs to receive core reviewer attention and that subsequent patches incorporate their feedback.\n> \n> \n> >\n> > The team came up with the model currently in model based on that review and evaluation all the proposals in the document that you refer. It is easy to make general comments, but unless you participate in the process and sign up to writing the code, those comments are not going to help with solving the original problem. And this _is_ open-source. If you disagree, please write code and the community can decide for itself as to what model is actually simple to use for them. Curtailing efforts from other developers just because their engineering trade-offs are different from what you believe your use-case needs is not why we like open source. We enjoy the mode where different developers try different things, we experiment, and the software evolves to what the user demands. Or maybe, multiple models live in harmony. Let the users decide that.\n> \n> You are correct in saying that it is not my job to decide what you or other developers do.  It is, however, my role as a Neutron core reviewer to ensure that we make good use of the resources available to us to meet the project\'s commitments.  If I believe that the approach chosen to implement a given Neutron feature has the potential to starve other priorities of resources, then I have a responsibility to voice that concern and push back.  You\'re free to implement whatever you want outside of the tree, but participating in the Neutron community means accepting the norms that we have adopted.  If you don\'t like them, you are free to work to effect change, but it won\'t happen by simply wishing it so.\n> \n> And as per the summit session, there appears to be significant user demand for a subset of the POC that represents the \'link-based\' approach.  If we are to talk about taking user interests into account, I think the starting point would be implementing what they are asking for first and and evolving more complex solutions from there.\n> \n> \n> m.\n> \n> \n> > 3. Re: Could dev/review cycles be better spent on refactoring\n> > I think that most people agree that policy control is an important feature that fundamentally improves neutron (by solving the automation and scale issues). In a large project, multiple sub-projects can, and for a healthy project should, work in parallel. I understand that the neutron core team is stretched. But we still need to be able to balance the needs of today (paying off the technical debt/existing-issues by doing refactoring) with needs of tomorrow (new features like GP and LBaaS). GP effort was started in Havana, and now we are trying to get this in Juno. I think that is reasonable and a long enough cycle for a \"high priority\" project to be able to get some core attention. Again I refer to LBaaS experience, as they struggled with very similar issues.\n> >\n> > 4. Re: If refactored neutron was available, would a simpler option become more viable\n> > We would love to be able to answer that question. We have been trying to understand the refactoring work to understand this (see another ML thread) and we are open to understanding your position on that. We will call the ad-hoc meeting that you suggested and we would like to understand the refactoring work that might be reused for simpler policy implementation. At the same time, we would like to build on what is available today, and when the required refactored neutron becomes available (say Juno or K-release), we are more than happy to adapt to it at that time. Serializing all development around an effort that is still in inception phase is not a good solution. We are looking forward to participating in the core refactoring work, and based on the final spec that come up with, we would love to be able to eventually make the policy implementation simpler.\n> >\n> > Regards,\n> > Mandeep\n> >\n> >\n> >\n> >\n> > On Thu, May 22, 2014 at 11:44 AM, Armando M. <armamig at gmail.com> wrote:\n> > I would second Maru\'s concerns, and I would also like to add the following:\n> >\n> > We need to acknowledge the fact that there are certain architectural\n> > aspects of Neutron as a project that need to be addressed; at the\n> > summit we talked about the core refactoring, a task oriented API, etc.\n> > To me these items have been neglected far too much over the past and\n> > would need a higher priority and a lot more attention during the Juno\n> > cycle. Being stretched as we are I wonder if dev/review cycles\n> > wouldn\'t be better spent devoting more time to these efforts rather\n> > than GP.\n> >\n> > That said, I appreciate that GP is important and needs to move\n> > forward, but at the same time I am thinking that there must be a\n> > better way for addressing it and yet relieve some of the pressure that\n> > GP complexity imposes to the Neutron team. One aspect it was discussed\n> > at the summit was that the type of approach shown in [2] and [3]\n> > below, was chosen because of lack of proper integration hooks...so I\n> > am advocating: let\'s talk about those first before ruling them out in\n> > favor of a monolithic approach that seems to violate some engineering\n> > principles, like modularity and loose decoupling of system components.\n> >\n> > I think we didn\'t have enough time during the summit to iron out some\n> > of the concerns voiced here, and it seems like the IRC meeting for\n> > Group Policy would not be the right venue to try and establish a\n> > common ground among the people driving this effort and the rest of the\n> > core team.\n> >\n> > Shall we try and have an ad-hoc meeting and an ad-hoc agenda to find a\n> > consensus?\n> >\n> > Many thanks,\n> > Armando\n> >\n> > On 22 May 2014 11:38, Maru Newby <marun at redhat.com> wrote:\n> >>\n> >> On May 22, 2014, at 11:03 AM, Maru Newby <marun at redhat.com> wrote:\n> >>\n> >>> At the summit session last week for group-based policy, there were many concerns voiced about the approach being undertaken.  I think those concerns deserve a wider audience, and I\'m going to highlight some of them here.\n> >>>\n> >>> The primary concern seemed to be related to the complexity of the approach implemented for the POC.  A number of session participants voiced concern that the simpler approach documented in the original proposal [1] (described in the section titled \'Policies applied between groups\') had not been implemented in addition to or instead of what appeared in the POC (described in the section titled \'Policies applied as a group API\').  The simpler approach was considered by those participants as having the advantage of clarity and immediate usefulness, whereas the complex approach was deemed hard to understand and without immediate utility.\n> >>>\n> >>> A secondary but no less important concern is related to the impact on Neutron of the approach implemented in the POC.  The POC was developed monolithically, without oversight through gerrit, and the resulting patches were excessive in size (~4700 [2] and ~1500 [3] lines).  Such large patches are effectively impossible to review.  Even broken down into reviewable chunks, though, it does not seem realistic to target juno-1 for merging this kind of complexity.  The impact on stability could be considerable, and it is questionable whether the necessary review effort should be devoted to fast-tracking group-based policy at all, let alone an approach that is considered by many to be unnecessarily complicated.\n> >>>\n> >>> The blueprint for group policy [4] is currently listed as a \'High\' priority.  With the above concerns in mind, does it make sense to continue prioritizing an effort that at present would seem to require considerably more resources than the benefit it appears to promise?\n> >>>\n> >>>\n> >>> Maru\n> >>>\n> >>> 1: https://etherpad.openstack.org/p/group-based-policy\n> >>\n> >> Apologies, this link is to the summit session etherpad.  The link to the original proposal is:\n> >>\n> >> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit\n> >>\n> >>> 2: https://review.openstack.org/93853\n> >>> 3: https://review.openstack.org/93935\n> >>> 4: https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CACqkTfPmTnYdGoCma5wt=Ka4s+9jQM2VQZfiubrzp5o3j-L0+g@mail.gmail.com>',NULL),('<16C8BE39ADF2194EAFB816DC5FCDDA4D0D3CB6F9@G5W2717.americas.hpqcorp.net>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-05-23 15:57:15',0,'2014-05-23 15:57:15',NULL,'[Openstack] Large volume creation takes long time','I believe that the volume delete will clear the volume first (dd if=/dev/zero).\n\nThe volume resize option was implemented in Havana.\n\nYou can try to resize to 1G instead of 0.\n\nI hope this helps.\n\n-Yehia\n\nFrom: John Griffith [mailto:john.griffith at solidfire.com]\nSent: Friday, May 23, 2014 11:21 AM\nTo: Ruzicka, Marek\nCc: Udara Liyanage; openstack at lists.openstack.org\nSubject: Re: [Openstack] Large volume creation takes long time\n\n\n\nOn Thu, May 22, 2014 at 11:33 PM, Ruzicka, Marek <marek.ruzicka at t-systems.sk<mailto:marek.ruzicka at t-systems.sk>> wrote:\nCan?t help you here? I?m still running Grizzly, and volume resize came in IceHouse I believe.\n\nMarek\n\n\nFrom: Udara Liyanage [mailto:udaraliyanage at gmail.com<mailto:udaraliyanage at gmail.com>]\nSent: 23. m?ja 2014 07:28\nTo: Ruzicka, Marek\nCc: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: Re: [Openstack] Large volume creation takes long time\n\nHI marek,\nThanks for the reply.\nBy the way how to resize a volume to zero. I found \"cinder extend\" command where volumes can be extended. How to shrink the volume to zero?\n\nOn Fri, May 23, 2014 at 10:52 AM, <marek.ruzicka at t-systems.sk<mailto:marek.ruzicka at t-systems.sk>> wrote:\nI?m not 100% sure, but I remember (depending on the driver you are using) it used to zero entire volume before deletion, which might or might not make sense for you.\nSorry for not being able to provide any details, this is just something I remember from way back.\n\nCheers,\nMarek\n\nFrom: Udara Liyanage [mailto:udaraliyanage at gmail.com<mailto:udaraliyanage at gmail.com>]\nSent: 23. m?ja 2014 07:00\nTo: openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nSubject: [Openstack] Large volume creation takes long time\n\nHi,\nWhen it tries to delete a large sized volume, it takes a long time. Is there a another better way to do  this such as resizing a volume to zero.\n\n--\nUdara S.S Liyanage.\nSoftware Engineer at WSO2.\nCommiter and PPMC Member of Apache Stratos.\nBlog - http://udaraliyanage.wordpress.com<http://udaraliyanage.wordpress.com/>\nphone: +94 71 443 6897<tel:%2B94%2071%20443%206897>\n\n\n\n--\nUdara S.S Liyanage.\nSoftware Engineer at WSO2.\nCommiter and PPMC Member of Apache Stratos.\nBlog - http://udaraliyanage.wordpress.com<http://udaraliyanage.wordpress.com/>\nphone: +94 71 443 6897<tel:%2B94%2071%20443%206897>\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n?The writing zeros to the volume on delete is indeed what you\'re seeing, it\'s a \"feature\" that is there for security purposes, so for example a public provider doesn\'t hand out a new volume to a tenant with the possibility of allocating blocks with somebody elses data on them.\n\nYou can switch to using \"lvm_type=thin\" in your cinder.conf file which will basically handle this by returning zero for blocks that haven\'t been written yet (so we don\'t do the secure delete).  Or as was suggested if you don\'t need the secure delete option you can turn it off altogether by setting \"volume_clear=none\" in your cinder.conf file.\n\nAs far as adjusting the size to zero, we don\'t allow reducing the volume size, only extending.  Reducing introduces quite a bit of risk and also it doesn\'t address the problem that secure_delete is there for anyway.\n\nThanks,\nJohn?\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140523/ecd9c143/attachment.html>\n\n','<CA+qL3LU9vq9yCNUF0rJcrod5zVAt_g8dSb3Pyk-rjPtdQHu0Yg@mail.gmail.com>',NULL),('<16C902E7-6D95-45D6-845B-C2C389273FFD@not.mn>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-01 19:04:31',-28800,'2013-12-02 03:04:31',NULL,'[openstack-dev] request-id in API response','Just to add to the story, Swift uses \"X-Trans-Id\" and generates it in the outer-most \"catch_errors\" middleware.\n\nSwift\'s catch errors middleware is responsible for ensuring that the transaction id exists on each request, and that all errors previously uncaught, anywhere in the pipeline, are caught and logged. If there is not a common way to do this, yet, I submit it as a great template for solving this problem. It\'s simple, scalable, and well-tested (ie tests and running in prod for years).\n\nhttps://github.com/openstack/swift/blob/master/swift/common/middleware/catch_errors.py\n\nLeaving aside error handling and only focusing on the transaction id (or request id) generation, since OpenStack services are exposed to untrusted clients, how would you propose communicating the appropriate transaction id to a different service? I can see great benefit to having a glance transaction ID carry through to Swift requests (and so on), but how should the transaction id be communicated? It\'s not sensitive info, but I can imagine a pretty big problem when trying to track down errors if a client application decides to set eg the X-Set-Transaction-Id header on every request to the same thing.\n\nThanks for bringing this up, and I\'d welcome a patch in Swift that would use a common library to generate the transaction id, if it were installed. I can see that there would be huge advantage to operators to trace requests through multiple systems.\n\nAnother option would be for each system that calls an another OpenStack system to expect and log the transaction ID for the request that was given. This would be looser coupling and be more forgiving for a heterogeneous cluster. Eg when Glance makes a call to Swift, Glance cloud log the transaction id that Swift used (from the Swift response). Likewise, when Swift makes a call to Keystone, Swift could log the Keystone transaction id. This wouldn\'t result in a single transaction id across all systems, but it would provide markers so an admin could trace the request.\n\n--John\n\n\n\n\nOn Dec 1, 2013, at 5:48 PM, Maru Newby <marun at redhat.com> wrote:\n\n> \n> On Nov 30, 2013, at 1:00 AM, Sean Dague <sean at dague.net> wrote:\n> \n>> On 11/29/2013 10:33 AM, Jay Pipes wrote:\n>>> On 11/28/2013 07:45 AM, Akihiro Motoki wrote:\n>>>> Hi,\n>>>> \n>>>> I am working on adding request-id to API response in Neutron.\n>>>> After I checked what header is used in other projects\n>>>> header name varies project by project.\n>>>> It seems there is no consensus what header is recommended\n>>>> and it is better to have some consensus.\n>>>> \n>>>> nova:     x-compute-request-id\n>>>> cinder:   x-compute-request-id\n>>>> glance:   x-openstack-request-id\n>>>> neutron:  x-network-request-id  (under review)\n>>>> \n>>>> request-id is assigned and used inside of each project now,\n>>>> so x-<service>-request-id looks good. On the other hand,\n>>>> if we have a plan to enhance request-id across projects,\n>>>> x-openstack-request-id looks better.\n>>> \n>>> My vote is for:\n>>> \n>>> x-openstack-request-id\n>>> \n>>> With an implementation of \"create a request UUID if none exists yet\" in\n>>> some standardized WSGI middleware...\n>> \n>> Agreed. I don\'t think I see any value in having these have different\n>> service names, having just x-openstack-request-id across all the\n>> services seems a far better idea, and come back through and fix nova and\n>> cinder to be that as well.\n> \n> +1 \n> \n> An openstack request id should be service agnostic to allow tracking of a request across many services (e.g. a call to nova to boot a VM should generate a request id that is provided to other services in requests to provision said VM).  All services would ideally share a facility for generating new request ids and for securely accepting request ids from other services.\n> \n> \n> m.\n> \n>> \n>> 	-Sean\n>> \n>> -- \n>> Sean Dague\n>> http://dague.net\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131201/66b0d21e/attachment.pgp>\n\n','<4C08021B-104C-4993-AF82-FEC1D9616B5F@redhat.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D0109679B1571@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-08-11 13:03:41',3600,'2011-08-11 12:03:41',NULL,'[Openstack-operators] sertting max number of instances per compute\n	node','\nAll,\n\nis there an option to set the max number of instances that will be scheduled onto a particular compute node? (in eucalyptus the option is max_cores) \n\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\n\n\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9C28@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-09-27 23:01:42',3600,'2011-09-27 22:01:42',NULL,'[Openstack-operators] configuring the scheduler','\nAll,\n\nIs it possible to set options for nova-scheduler to limit the number of instances  that the scheduler will start on a given compute node?\nSo somethign  similar to MAX_CORES option in eucalyptus.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9C7A@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-14 15:13:24',3600,'2011-10-14 14:13:24',NULL,'[Openstack-operators] configuring the scheduler','\nHi,\n\nI\'m running Diablo and looking for advice on configuring the scheduler. I have compute nodes of differing capabilities and would like to be able to describe that to the scheduler so it can make decisions based on that information. \n\nDoes anybody know how to do something like this?\n\nKind Regards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9C7B@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-14 15:16:35',3600,'2011-10-14 14:16:35',NULL,'[Openstack-operators] second availability zone','\nHi,\n\nis it possible to set up a second availability zone on diablo? If anybody knows how to do this would be very interested in hearing from them.\n\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9C92@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-20 16:14:19',3600,'2011-10-20 15:14:19',NULL,'[Openstack-operators] swift proxy server problem','Hi All,\n\nI\'m trying to set up swift and am having an issue with getting the proxy service to start, after a\nswift-init proxy start\n\nthe proxy does not start and I see this in the logs:\n\nOct 20 16:12:14 storage05 proxy-server UNCAUGHT EXCEPTION#012Traceback (most recent call last):#012  File \"/usr/bin/swift-proxy-server\", line 22, in <module>#012    run_wsgi(conf_file, \'proxy-server\', default_port=8080, **options)#012  File \"/usr/lib/pymodules/python2.6/swift/common/wsgi.py\", line 126, in run_wsgi#012    app = loadapp(\'config:%s\' % conf_file, global_conf={\'log_name\': log_name})#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 204, in loadapp#012    return loadobj(APP, uri, name=name, **kw)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 224, in loadobj#012    global_conf=global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 248, in loadcontext#012    global_conf=global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 278, in _loadconfig#012    return loader.get_context(object_type, name, global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 405, in get_context#012    global_additions=global_additions)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 503, in _pipeline_app_context#012    for name in pipeline[:-1]]#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 409, in get_context#012    section)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 431, in _context_from_use#012    object_type, name=use, global_conf=global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 361, in get_context#012    global_conf=global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 248, in loadcontext#012    global_conf=global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 285, in _loadegg#012    return loader.get_context(object_type, name, global_conf)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 561, in get_context#012    object_type, name=name)#012  File \"/usr/lib/pymodules/python2.6/paste/deploy/loadwsgi.py\", line 587, \n\n\nAny help appreciated.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9CA4@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-25 22:23:11',3600,'2011-10-25 21:23:11',NULL,'[Openstack-operators] swift accounts V users','\nHi All,\n\nhaving problems understanding the concept of a swift account and how it relates to a user. Can anybody provide an explanation?\nCan an account have multiple users associated with it?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9CA7@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-26 09:54:52',3600,'2011-10-26 08:54:52',NULL,'[Openstack-operators] glance and swift','\nHi All,\n\nHas anybody managed to configure glance to use swift?\n\nI\'ve created a glance account and user on swift and can upload files:\n\n>swift list -A https://127.0.0.1:8080/auth/v1.0/ -U glance:glance -K glance glance_bucket\n\nvirtualization-2edition.pdf\n\nNow, I\'m truing to update glance config, /etc/glance/glance-api.conf\n\ndefault_store = swift\nswift_store_auth_address = https://131.227.75.25:8080/auth/\nswift_store_user = glance\nswift_store_key=glance\nswift_store_container = glance_bucket\n\nand restart glance, but when I upload images into nova they are ending up in local filesystem /var/lib/glance/images instead of in swift.\n\nAny help appreciated.\n\nKind Regards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9CAA@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-26 12:48:59',3600,'2011-10-26 11:48:59',NULL,'[Openstack-operators] glance and swift','\nAnd this is the error message I\'m seeing in the logs\n\nERROR [glance.store.swift] Could not find swift_store_auth_address in configuration options\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] On Behalf Of J.O\'Loughlin at surrey.ac.uk [J.O\'Loughlin at surrey.ac.uk]\nSent: 26 October 2011 09:54\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] glance and swift\n\nHi All,\n\nHas anybody managed to configure glance to use swift?\n\nI\'ve created a glance account and user on swift and can upload files:\n\n>swift list -A https://127.0.0.1:8080/auth/v1.0/ -U glance:glance -K glance glance_bucket\n\nvirtualization-2edition.pdf\n\nNow, I\'m truing to update glance config, /etc/glance/glance-api.conf\n\ndefault_store = swift\nswift_store_auth_address = https://131.227.75.25:8080/auth/\nswift_store_user = glance\nswift_store_key=glance\nswift_store_container = glance_bucket\n\nand restart glance, but when I upload images into nova they are ending up in local filesystem /var/lib/glance/images instead of in swift.\n\nAny help appreciated.\n\nKind Regards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9CA7@EXMB01CMS.surrey.ac.uk>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D010CF98C9CAB@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-10-26 14:16:49',3600,'2011-10-26 13:16:49',NULL,'[Openstack-operators] Roles','Hi All,\n\nI\'m running trunk on 10.10\n\nI\'ve just created a user and added to a project:\n\nnova-manage user create tom\nnova-project add project2 tom\n\nat this stage no roles added:\n\nmy understanding is that a euca-describe-images should just show images in project? \nthe new user can see all images, all instances in all projects, can start an instance from any image even if marked private, can allocate themselves an address\nand can then assign that to any other user instances! \n\nAfter the above I gave tom the sysadmin role (global and then in the project). Makes no difference to what they can and cant do.\n\nIs this normal behaviour?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F1248F@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-12 14:08:13',0,'2012-01-12 14:08:13',NULL,'[Openstack-operators] nova volume service','\nHi All,\n\nneed some help with the nova-volume service...\n\ndoes the volume group need to be on the same host as the nova-volume service or can the volume service manage volumes groups on multiple hosts?\n\nAlso, for the diablo release does boot from a volume work?\n\nKind Regards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F124A3@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-18 12:05:57',0,'2012-01-18 12:05:57',NULL,'[Openstack-operators] set max number of instances per compute node','\nAll,\n\nis there a way to set the maximum number of instances or cores that can be used on a compute node? (similar to the max_cores option in eucalyptus)\n\nI\'m running diablo. \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F124A5@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-18 15:57:54',0,'2012-01-18 15:57:54',NULL,'[Openstack-operators] set max number of instances per compute\n node','\nThanks, \n\nI added this as an option to nova.conf on one of my compute nodes and doesn\'t work. Does it need to be set on the scheduler host? if so, is it possible to set different values for different compute hosts?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] On Behalf Of Tom Fifield [fifieldt at unimelb.edu.au]\nSent: 18 January 2012 12:53\nTo: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nhttp://docs.openstack.org/diablo/openstack-compute/admin/content/reference-for-flags-in-nova-conf.html\n\n--max_cores     default: \'16\'   Integer value; Maximum number of instance\ncores to allow per compute host.\n\nRegards,\n\nTom\n\nOn 18/01/12 23:05, J.O\'Loughlin at surrey.ac.uk wrote:\n>\n> All,\n>\n> is there a way to set the maximum number of instances or cores that can be used on a compute node? (similar to the max_cores option in eucalyptus)\n>\n> I\'m running diablo.\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<4F16C0B7.9080301@unimelb.edu.au>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F124A7@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-18 16:33:05',0,'2012-01-18 16:33:05',NULL,'[Openstack-operators] set max number of instances per compute\n node','\nAre there any docs on configuring the various schedulers? I\'m  putting together a test cloud, and have a variety of different servers. \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla Santamar?a [diego.parrilla.santamaria at gmail.com]\nSent: 18 January 2012 16:28\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: fifieldt at unimelb.edu.au; openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nCorrect me if I\'m wrong, but this parameter is used by the SimpleScheduler, so it must be in the configuration file used by nova-scheduler.\n\nCheers\nDiego\n\n--\nDiego Parrilla\n<http://www.stackops.com/>CEO\nwww.stackops.com<http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +34 649 94 43 29 | skype:diegoparrilla\n<http://www.stackops.com/>\n\n[http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png]\n\n\n\n\nOn Wed, Jan 18, 2012 at 4:57 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n\nThanks,\n\nI added this as an option to nova.conf on one of my compute nodes and doesn\'t work. Does it need to be set on the scheduler host? if so, is it possible to set different values for different compute hosts?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org> [openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>] On Behalf Of Tom Fifield [fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>]\nSent: 18 January 2012 12:53\nTo: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nhttp://docs.openstack.org/diablo/openstack-compute/admin/content/reference-for-flags-in-nova-conf.html\n\n--max_cores     default: \'16\'   Integer value; Maximum number of instance\ncores to allow per compute host.\n\nRegards,\n\nTom\n\nOn 18/01/12 23:05, J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk> wrote:\n>\n> All,\n>\n> is there a way to set the maximum number of instances or cores that can be used on a compute node? (similar to the max_cores option in eucalyptus)\n>\n> I\'m running diablo.\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<CAASO9xbJ8Pwn4oPyysy8XyfVAhUPaVr9sX7D46NEpKLHAcPjzw@mail.gmail.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F124A8@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-18 17:27:32',0,'2012-01-18 17:27:32',NULL,'[Openstack-operators] set max number of instances per compute\n node','\nThanks,\n\nWhat options would I need to set in nova.conf to change the scheduler to this?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla Santamar?a [diego.parrilla.santamaria at gmail.com]\nSent: 18 January 2012 16:50\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: fifieldt at unimelb.edu.au; openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nEverett Toews wrote something really sexy a couple of months ago:\n\nhttps://github.com/canarie/dair/blob/master/OpenStack/misc/hardware.py\n\nMay be you can give it good use!\n\n--\nDiego Parrilla\n<http://www.stackops.com/>CEO\nwww.stackops.com<http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +34 649 94 43 29 | skype:diegoparrilla\n<http://www.stackops.com/>\n\n\n\n\n\nOn Wed, Jan 18, 2012 at 5:33 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n\nAre there any docs on configuring the various schedulers? I\'m  putting together a test cloud, and have a variety of different servers.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla Santamar?a [diego.parrilla.santamaria at gmail.com<mailto:diego.parrilla.santamaria at gmail.com>]\nSent: 18 January 2012 16:28\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>; openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nCorrect me if I\'m wrong, but this parameter is used by the SimpleScheduler, so it must be in the configuration file used by nova-scheduler.\n\nCheers\nDiego\n\n--\nDiego Parrilla\n<http://www.stackops.com/>CEO\nwww.stackops.com<http://www.stackops.com><http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com><mailto:diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com>> | +34 649 94 43 29<tel:%2B34%20649%2094%2043%2029> | skype:diegoparrilla\n<http://www.stackops.com/>\n\n[http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png]\n\n\n\n\nOn Wed, Jan 18, 2012 at 4:57 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk><mailto:J.O%27Loughlin at surrey.ac.uk<mailto:J.O%2527Loughlin at surrey.ac.uk>>> wrote:\n\nThanks,\n\nI added this as an option to nova.conf on one of my compute nodes and doesn\'t work. Does it need to be set on the scheduler host? if so, is it possible to set different values for different compute hosts?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org><mailto:openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>> [openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org><mailto:openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>>] On Behalf Of Tom Fifield [fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au><mailto:fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>>]\nSent: 18 January 2012 12:53\nTo: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org><mailto:openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nhttp://docs.openstack.org/diablo/openstack-compute/admin/content/reference-for-flags-in-nova-conf.html\n\n--max_cores     default: \'16\'   Integer value; Maximum number of instance\ncores to allow per compute host.\n\nRegards,\n\nTom\n\nOn 18/01/12 23:05, J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk><mailto:J.O%27Loughlin at surrey.ac.uk<mailto:J.O%2527Loughlin at surrey.ac.uk>> wrote:\n>\n> All,\n>\n> is there a way to set the maximum number of instances or cores that can be used on a compute node? (similar to the max_cores option in eucalyptus)\n>\n> I\'m running diablo.\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n','<CAASO9xYF3bRNJDC-XPEgb_tpgJKxPmGmL7Ue-2zDugtrvdn30Q@mail.gmail.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB6F124C0@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-27 10:02:47',0,'2012-01-27 10:02:47',NULL,'[Openstack-operators] set max number of instances per\n	compute	node','Thanks for that, does exactly what I was looking for.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Paul Ruth [pruth at renci.org]\nSent: 26 January 2012 17:01\nTo: Michael J Fork\nCc: O\'Loughlin JF Mr (FEPS Faculty Admin); <openstack-operators at lists.openstack.org>; <openstack-operators-bounces at lists.openstack.org>\nSubject: Re: [Openstack-operators] set max number of instances per compute      node\n\nThe hardware.py scheduler that was posted earlier had a bug that makes it not do what it claims to do.    I have attached my fix for anyone that is interested.\n\nThe original code assumes that all the hosts are full when it finds one full host.  It should check them all.   The simple scheduler can make this assumption because the db.service_get_all_compute_sorted(context) call returns a list that is sorted (in ascending order) by number of virtual cores each host is currently handling.   Since the simple scheduler assumes that all hosts have the same number of cores, when it finds a full host it knows that the hosts remaining the the sorted list are also full.\n\nPaul\n\n\n\nOn Jan 18, 2012, at 1:29 PM, Michael J Fork wrote:\n\nI was able to get it to work by downloading the hardware.py file to site-packages/nova/scheduler/hardware.py and setting the scheduler_driver in nova.conf\n\n--scheduler_driver=nova.scheduler.hardware.HardwareScheduler\n\nMichael\n\n-------------------------------------------------\nMichael Fork\nCloud Architect, Emerging Solutions\nIBM Systems & Technology Group\n\n\n\nFrom:        <J.O\'Loughlin at surrey.ac.uk<mailto:J.O\'Loughlin at surrey.ac.uk>>\nTo:        <diego.parrilla.santamaria at gmail.com<mailto:diego.parrilla.santamaria at gmail.com>>\nCc:        openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>\nDate:        01/18/2012 12:28 PM\nSubject:        Re: [Openstack-operators] set max number of instances per compute node\nSent by:        openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>\n________________________________\n\n\n\n\nThanks,\n\nWhat options would I need to set in nova.conf to change the scheduler to this?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla Santamar?a [diego.parrilla.santamaria at gmail.com]\nSent: 18 January 2012 16:50\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>; openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nEverett Toews wrote something really sexy a couple of months ago:\n\nhttps://github.com/canarie/dair/blob/master/OpenStack/misc/hardware.py\n\nMay be you can give it good use!\n\n--\nDiego Parrilla\n<http://www.stackops.com/>CEO\nwww.stackops.com<http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com> | +34 649 94 43 29 | skype:diegoparrilla\n<http://www.stackops.com/>\n\n\n\n\n\nOn Wed, Jan 18, 2012 at 5:33 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n\nAre there any docs on configuring the various schedulers? I\'m  putting together a test cloud, and have a variety of different servers.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla Santamar?a [diego.parrilla.santamaria at gmail.com<mailto:diego.parrilla.santamaria at gmail.com>]\nSent: 18 January 2012 16:28\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>; openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nCorrect me if I\'m wrong, but this parameter is used by the SimpleScheduler, so it must be in the configuration file used by nova-scheduler.\n\nCheers\nDiego\n\n--\nDiego Parrilla\n<http://www.stackops.com/>CEO\nwww.stackops.com<http://www.stackops.com<http://www.stackops.com/>><http://www.stackops.com/> |  diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com><mailto:diego.parrilla at stackops.com<mailto:diego.parrilla at stackops.com>> | +34 649 94 43 29<tel:%2B34%20649%2094%2043%2029> | skype:diegoparrilla\n<http://www.stackops.com/>\n\n[http://stackops.s3-external-3.amazonaws.com/STACKOPSLOGO-ICON.png]\n\n\n\n\nOn Wed, Jan 18, 2012 at 4:57 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk><mailto:J.O%27Loughlin at surrey.ac.uk<mailto:J.O%2527Loughlin at surrey.ac.uk>>> wrote:\n\nThanks,\n\nI added this as an option to nova.conf on one of my compute nodes and doesn\'t work. Does it need to be set on the scheduler host? if so, is it possible to set different values for different compute hosts?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org><mailto:openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>> [openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org><mailto:openstack-operators-bounces at lists.openstack.org<mailto:openstack-operators-bounces at lists.openstack.org>>] On Behalf Of Tom Fifield [fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au><mailto:fifieldt at unimelb.edu.au<mailto:fifieldt at unimelb.edu.au>>]\nSent: 18 January 2012 12:53\nTo: openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org><mailto:openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>\nSubject: Re: [Openstack-operators] set max number of instances per compute node\n\nhttp://docs.openstack.org/diablo/openstack-compute/admin/content/reference-for-flags-in-nova-conf.html\n\n--max_cores     default: \'16\'   Integer value; Maximum number of instance\ncores to allow per compute host.\n\nRegards,\n\nTom\n\nOn 18/01/12 23:05, J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk><mailto:J.O%27Loughlin at surrey.ac.uk<mailto:J.O%2527Loughlin at surrey.ac.uk>> wrote:\n>\n> All,\n>\n> is there a way to set the maximum number of instances or cores that can be used on a compute node? (similar to the max_cores option in eucalyptus)\n>\n> I\'m running diablo.\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org><mailto:Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<F1DDDF37-FED0-4128-9135-DD9759E0EA89@renci.org>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB792E77E@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-01-31 15:27:42',0,'2012-01-31 15:27:42',NULL,'[Openstack-operators] filtering instances to particular hosts','\nHi all,\n\nI\'m planning on adding a new compute node with significantly more memory than the existing compute nodes and would like to create a new \'high memory\' machine type and have instances of that machine type run on the new compute node?\n\nAny help or suggestions much appreciated.\n \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120B7C@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-03 12:54:33',0,'2012-02-03 12:54:33',NULL,'[Openstack-operators] filtering instances to particular hosts',' \nHi All\n\nDoes anybody know how to filter particular instance types onto specific compute hosts? I imagine this could be useful for quite a few people?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] On Behalf Of J.O\'Loughlin at surrey.ac.uk [J.O\'Loughlin at surrey.ac.uk]\nSent: 31 January 2012 15:27\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] filtering instances to particular hosts\n\nHi all,\n\nI\'m planning on adding a new compute node with significantly more memory than the existing compute nodes and would like to create a new \'high memory\' machine type and have instances of that machine type run on the new compute node?\n\nAny help or suggestions much appreciated.\n\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<16D2E990EC74F04799F77FA02C7E1F8D011AB792E77E@EXMB01CMS.surrey.ac.uk>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120B96@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-07 12:54:44',0,'2012-02-07 12:54:44',NULL,'[Openstack-operators] auto_assign floating ips','\nHi All,\n\nIs anybody using auto_assign_floating_ip feature? if so would be grateful for some pointers on how to configure\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120BFE@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-21 17:12:21',0,'2012-02-21 17:12:21',NULL,'[Openstack-operators] cloud-init and meta data service','\nHi All,\n\nI\'m trying to use the meta data service, i have added the iptables rule to route to the nova-api service,  \n\niptables -t nat -A PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 131.227.75.5:8773\n\nand if I start an instance I can curl http://169.254.169.254/2009--04-04/meta-data/instance-id\n\nand the above works, but when using cloud-init the instance boot up just hangs with url error.\n\nI\'m using diablo and lucid for the instances.\n\nAny help appreciated!\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120C20@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-02-29 12:50:34',0,'2012-02-29 12:50:34',NULL,'[Openstack-operators] essex networking questions','\nAll,\n\nI\'ve been running diablo and now have a test essex set up, built on trunk ppa. In essex a euca-describe-instances returns the following:\n\nroot at kvm-dev01:~/ubuntu-kvm# euca-describe-instances \nRESERVATION	r-wn6ny48r	project1	default\nINSTANCE	i-00000002	ami-0000000c	server-2	server-2	running	None (project1, kvm-dev01)	1		m1.small	2012-02-29T11:39:58Z	nova	\n\npreviously, in diablo, the private IP address would be displayed instead of server-2. Two questions:\n\n1. Is there an option to change this back to the behaviour in diablo\n2. How does essex manage DNS? and how are people generally dealing with this? \n\nAlso, \n\nnova-manage floating create 131.227.76.235/32\n\nis silently failing, a  nova-manage floating list show no floating IP addresses have been defined. Has the syntax for this changed? \n\nAny help appreciated\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120C30@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-02 13:58:17',0,'2012-03-02 13:58:17',NULL,'[Openstack-operators] nova-manage floating create','\n\nAll,\n\nOn the essex-4 milestone nova-manage floating create is failing to add floating ips.\n\nroot at kvm-dev01:~# nova-manage floating create  131.227.76.235/32\nroot at kvm-dev01:~# nova-manage floating list\n2012-03-02 13:59:28,261 DEBUG nova.utils [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] backend <module \'nova.db.sqlalchemy.api\' from \'/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc\'> from (pid=13715) debug /usr/lib/python2.7/dist-packages/nova/log.py:175\nCommand failed, please check log for more info\n2012-03-02 13:59:28,367 CRITICAL nova [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] Zero floating ips exist.\n(nova): TRACE: Traceback (most recent call last):\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 2372, in <module>\n(nova): TRACE:     main()\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 2360, in main\n(nova): TRACE:     fn(*fn_args, **fn_kwargs)\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 724, in list\n(nova): TRACE:     floating_ips = db.floating_ip_get_all(ctxt)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/api.py\", line 314, in floating_ip_get_all\n(nova): TRACE:     return IMPL.floating_ip_get_all(context)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 101, in wrapper\n(nova): TRACE:     return f(*args, **kwargs)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 823, in floating_ip_get_all\n(nova): TRACE:     raise exception.NoFloatingIpsDefined()\n(nova): TRACE: NoFloatingIpsDefined: Zero floating ips exist.\n\n\nand the floating_ips table is empty.\n\nIs there a different/new way of adding floating ips?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120C31@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-02 14:10:40',0,'2012-03-02 14:10:40',NULL,'[Openstack-operators] nova-manage floating create','Hi,\n\n\n/32 is for adding just one IP address, 131.227.76.235 in this case. On diablo this works. \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Mike Scherbakov [mscherbakov at mirantis.com]\nSent: 02 March 2012 14:07\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] nova-manage floating create\n\nHi,\nyou have to specify the right subnet (not /32):\nnova-manage floating create 131.227.76.235/24<http://131.227.76.235/24>\n2012-03-02 06:06:34 DEBUG nova.utils [req-4520071f-d05b-4169-9368-3310e92fa247 None None] backend <module \'nova.db.sqlalchemy.api\' from \'/opt/stack/nova/nova/db/sqlalchemy/api.pyc\'> from (pid=7251) __get_backend /opt/stack/nova/nova/utils.py:607\nstack at baseubuntuserver:~$ nova-manage floating list\n2012-03-02 06:06:46 DEBUG nova.utils [req-fd30962c-7b24-4b3b-83b7-237b7fd026c0 None None] backend <module \'nova.db.sqlalchemy.api\' from \'/opt/stack/nova/nova/db/sqlalchemy/api.pyc\'> from (pid=7257) __get_backend /opt/stack/nova/nova/utils.py:607\nNone 172.24.4.225 None nova br100\nNone 172.24.4.226 None nova br100\nNone 172.24.4.227 None nova br100\n.....\n\nRegards,\n\nOn Fri, Mar 2, 2012 at 5:58 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n\n\nAll,\n\nOn the essex-4 milestone nova-manage floating create is failing to add floating ips.\n\nroot at kvm-dev01:~# nova-manage floating create  131.227.76.235/32<http://131.227.76.235/32>\nroot at kvm-dev01:~# nova-manage floating list\n2012-03-02 13:59:28,261 DEBUG nova.utils [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] backend <module \'nova.db.sqlalchemy.api\' from \'/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc\'> from (pid=13715) debug /usr/lib/python2.7/dist-packages/nova/log.py:175\nCommand failed, please check log for more info\n2012-03-02 13:59:28,367 CRITICAL nova [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] Zero floating ips exist.\n(nova): TRACE: Traceback (most recent call last):\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 2372, in <module>\n(nova): TRACE:     main()\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 2360, in main\n(nova): TRACE:     fn(*fn_args, **fn_kwargs)\n(nova): TRACE:   File \"/usr/bin/nova-manage\", line 724, in list\n(nova): TRACE:     floating_ips = db.floating_ip_get_all(ctxt)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/api.py\", line 314, in floating_ip_get_all\n(nova): TRACE:     return IMPL.floating_ip_get_all(context)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 101, in wrapper\n(nova): TRACE:     return f(*args, **kwargs)\n(nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 823, in floating_ip_get_all\n(nova): TRACE:     raise exception.NoFloatingIpsDefined()\n(nova): TRACE: NoFloatingIpsDefined: Zero floating ips exist.\n\n\nand the floating_ips table is empty.\n\nIs there a different/new way of adding floating ips?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n\n--\nMike Scherbakov\n\n','<CAKYN3rMZqwtJznJVdy3-v8KEH_8jauzuF67ttPZAmvhhp2MnyA@mail.gmail.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120C33@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-02 14:19:07',0,'2012-03-02 14:19:07',NULL,'[Openstack-operators] nova-manage floating create','\nI know that it works in version 2011.3. seems strange that it should stop working? \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Diego Parrilla [diego.parrilla.santamaria at gmail.com]\nSent: 02 March 2012 14:16\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: <mscherbakov at mirantis.com>; openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] nova-manage floating create\n\nAre you sure it works in diablo 2011.3.1? I think it worked till latest bug fix version\n\nEnviado desde mi iPhone, perdona la brevedad\n\nEl 02/03/2012, a las 15:10, <J.O\'Loughlin at surrey.ac.uk> escribi?:\n\n> Hi,\n>\n>\n> /32 is for adding just one IP address, 131.227.76.235 in this case. On diablo this works.\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> ________________________________________\n> From: Mike Scherbakov [mscherbakov at mirantis.com]\n> Sent: 02 March 2012 14:07\n> To: O\'Loughlin JF Mr (FEPS Faculty Admin)\n> Cc: openstack-operators at lists.openstack.org\n> Subject: Re: [Openstack-operators] nova-manage floating create\n>\n> Hi,\n> you have to specify the right subnet (not /32):\n> nova-manage floating create 131.227.76.235/24<http://131.227.76.235/24>\n> 2012-03-02 06:06:34 DEBUG nova.utils [req-4520071f-d05b-4169-9368-3310e92fa247 None None] backend <module \'nova.db.sqlalchemy.api\' from \'/opt/stack/nova/nova/db/sqlalchemy/api.pyc\'> from (pid=7251) __get_backend /opt/stack/nova/nova/utils.py:607\n> stack at baseubuntuserver:~$ nova-manage floating list\n> 2012-03-02 06:06:46 DEBUG nova.utils [req-fd30962c-7b24-4b3b-83b7-237b7fd026c0 None None] backend <module \'nova.db.sqlalchemy.api\' from \'/opt/stack/nova/nova/db/sqlalchemy/api.pyc\'> from (pid=7257) __get_backend /opt/stack/nova/nova/utils.py:607\n> None 172.24.4.225 None nova br100\n> None 172.24.4.226 None nova br100\n> None 172.24.4.227 None nova br100\n> .....\n>\n> Regards,\n>\n> On Fri, Mar 2, 2012 at 5:58 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n>\n>\n> All,\n>\n> On the essex-4 milestone nova-manage floating create is failing to add floating ips.\n>\n> root at kvm-dev01:~# nova-manage floating create  131.227.76.235/32<http://131.227.76.235/32>\n> root at kvm-dev01:~# nova-manage floating list\n> 2012-03-02 13:59:28,261 DEBUG nova.utils [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] backend <module \'nova.db.sqlalchemy.api\' from \'/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc\'> from (pid=13715) debug /usr/lib/python2.7/dist-packages/nova/log.py:175\n> Command failed, please check log for more info\n> 2012-03-02 13:59:28,367 CRITICAL nova [req-0ddb4739-3845-4240-9d2c-e106d2bc588d None None] Zero floating ips exist.\n> (nova): TRACE: Traceback (most recent call last):\n> (nova): TRACE:   File \"/usr/bin/nova-manage\", line 2372, in <module>\n> (nova): TRACE:     main()\n> (nova): TRACE:   File \"/usr/bin/nova-manage\", line 2360, in main\n> (nova): TRACE:     fn(*fn_args, **fn_kwargs)\n> (nova): TRACE:   File \"/usr/bin/nova-manage\", line 724, in list\n> (nova): TRACE:     floating_ips = db.floating_ip_get_all(ctxt)\n> (nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/api.py\", line 314, in floating_ip_get_all\n> (nova): TRACE:     return IMPL.floating_ip_get_all(context)\n> (nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 101, in wrapper\n> (nova): TRACE:     return f(*args, **kwargs)\n> (nova): TRACE:   File \"/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py\", line 823, in floating_ip_get_all\n> (nova): TRACE:     raise exception.NoFloatingIpsDefined()\n> (nova): TRACE: NoFloatingIpsDefined: Zero floating ips exist.\n>\n>\n> and the floating_ips table is empty.\n>\n> Is there a different/new way of adding floating ips?\n>\n> Regards\n>\n> John O\'Loughlin\n> FEPS IT, Service Delivery Team Leader\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n>\n>\n>\n> --\n> Mike Scherbakov\n> _______________________________________________\n> Openstack-operators mailing list\n> Openstack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<6EB4E23E-3646-48AA-AEB7-3C6817C58BA5@gmail.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8D011AB8120C3F@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-03-06 12:43:39',0,'2012-03-06 12:43:39',NULL,'[Openstack-operators] scheduling','\nHi All,\n\nLooking for some advice on scheduling. I want to be able to have a particular set of users instances to be scheduled onto a particular set of compute nodes. \nAny ideas on the best way to do this?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, \nService Delivery Team Leader\nUniversity of Surrey\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B02BA@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-01 22:01:12',0,'2011-02-01 22:01:12',NULL,'[Openstack-operators] nova networking','\nHi All,\n\nWith vlan networking mode how do you associate a public IP address with your instance? In eucalyptus you define both the public IP range and the private IP subnet, I haven\'t been able to find this in the docs for nova.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B02CC@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-07 16:18:03',0,'2011-02-07 16:18:03',NULL,'[Openstack-operators] nova networking','\nI\'ve used nova-manage to add public IPs and \n\neuca-associate-address -i i-00000014 131.227.76.80\n\nand euca-describe-instances\n\nRESERVATION	r-dhu9bgpn	project1	default\nINSTANCE	i-00000014	ami-l54ryhvw	131.227.76.80	10.0.0.7	running	None (project1, kvm-dev01)	0		m1.small	2011-02-06 19:21:56.863522	nova	\n\nssh and ping is allowed, but I get no route to host when trying to access the public address. Any help or pointers appreciated.  \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: openstack-operators-bounces at lists.openstack.org [openstack-operators-bounces at lists.openstack.org] On Behalf Of J.O\'Loughlin at surrey.ac.uk [J.O\'Loughlin at surrey.ac.uk]\nSent: 01 February 2011 22:01\nTo: openstack-operators at lists.openstack.org\nSubject: [Openstack-operators] nova networking\n\nHi All,\n\nWith vlan networking mode how do you associate a public IP address with your instance? In eucalyptus you define both the public IP range and the private IP subnet, I haven\'t been able to find this in the docs for nova.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n','<16D2E990EC74F04799F77FA02C7E1F8DCA485B02BA@EXMB01CMS.surrey.ac.uk>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B0316@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-16 15:55:31',0,'2011-02-16 15:55:31',NULL,'[Openstack-operators] networking question','\nAll,\n\nI have a nova install on a single machine, I have launched an instance which I can log into from the compute node, and have associated a public IP address to the instance, see below. \n\nroot at kvm-dev02:~/project2# euca-describe-instances \nRESERVATION	r-omedt4i6	project2	default\nINSTANCE	i-00000001	ami-bn6x5xnb	131.227.76.80	10.0.0.3	running	mykey (project2, kvm-dev02)	0		m1.small	2011-02-15 22:57:17.803241	nova	\n\nsecurity groups allow ssh and icmp:\n\nroot at kvm-dev02:~/project2# euca-describe-groups \nGROUP	project2	default	default\nPERMISSION	project2	default	ALLOWS	icmp	-1	-1	FROM	CIDR	0.0.0.0/0\nPERMISSION	project2	default	ALLOWS	tcp	22	22	FROM	CIDR	0.0.0.0/0\n\nbut I\'m not sure about the routing should now work, under eucalyptus the public IP is added as an alias to the public interface and a rule is added to iptables to nat the traffic to the instances private IP address.\nIt appears nova networking is different, are there any steps I have missed ?\n\nAny help or pointers much appreciated. \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B0330@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-22 18:16:50',0,'2011-02-22 18:16:50',NULL,'[Openstack-operators] networking question','\nIn vlan networking mode, are vpns and cloud pipes the only way to assess your instances ? Is there a way of associating a public IP address to an instance, as happens with ec2 ?\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n________________________________________\nFrom: Ahmed El Gamil [ahmed at manhag.org]\nSent: 17 February 2011 07:01\nTo: O\'Loughlin JF Mr (FEPS Faculty Admin)\nCc: openstack-operators at lists.openstack.org\nSubject: Re: [Openstack-operators] networking question\n\nI would also like an answer to this question, with the current networking models of Nova, When i need to assign private IP addresses to my instances, I have to create an alias on NIC of the node that holds eucatools so that the routing will be correct so as to access the instance via SSH or whatever.\n\nOn Wed, Feb 16, 2011 at 5:55 PM, <J.O\'Loughlin at surrey.ac.uk<mailto:J.O%27Loughlin at surrey.ac.uk>> wrote:\n\nAll,\n\nI have a nova install on a single machine, I have launched an instance which I can log into from the compute node, and have associated a public IP address to the instance, see below.\n\nroot at kvm-dev02:~/project2# euca-describe-instances\nRESERVATION     r-omedt4i6      project2        default\nINSTANCE        i-00000001      ami-bn6x5xnb    131.227.76.80   10.0.0.3        running mykey (project2, kvm-dev02)     0               m1.small        2011-02-15 22:57:17.803241      nova\n\nsecurity groups allow ssh and icmp:\n\nroot at kvm-dev02:~/project2# euca-describe-groups\nGROUP   project2        default default\nPERMISSION      project2        default ALLOWS  icmp    -1      -1      FROM    CIDR    0.0.0.0/0<http://0.0.0.0/0>\nPERMISSION      project2        default ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0<http://0.0.0.0/0>\n\nbut I\'m not sure about the routing should now work, under eucalyptus the public IP is added as an alias to the public interface and a rule is added to iptables to nat the traffic to the instances private IP address.\nIt appears nova networking is different, are there any steps I have missed ?\n\nAny help or pointers much appreciated.\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n_______________________________________________\nOpenstack-operators mailing list\nOpenstack-operators at lists.openstack.org<mailto:Openstack-operators at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n\n\n','<AANLkTimcX6yMxhsopg1=1Xpp_UiKbmetJiyJPKG0FqE1@mail.gmail.com>',NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B0353@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-02-28 17:20:32',0,'2011-02-28 17:20:32',NULL,'[Openstack-operators] per project vpns in bexar','\nHi,\n\nIs cloudpipe, the per project vpns working in the bexar release ?\n\n(nova.root): TRACE: IOError: [Errno 2] No such file or directory: \'/usr/lib/pymodules/python2.6/nova/cloudpipe/bootscript.template\'\n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D2E990EC74F04799F77FA02C7E1F8DCA485B03AD@EXMB01CMS.surrey.ac.uk>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2011-03-17 15:17:34',0,'2011-03-17 15:17:34',NULL,'[Openstack-operators] multiple users in a project','\nHi All,\n\nIn have openstack running on ubuntu 10.10 installed from trunk ppa. The networking is flat mode and I have one project (project1) set up and an admin user who can bundle/upload/regaister and run images. When I add a new user to to the project\nnova-manage user create student\nnova-manage project add project1 student\n\nas the student user I can now euca-describe-images but when I try to run an image:\nWarning: failed to parse error message from AWS: <unknown>:1:0: syntax error\nEC2ResponseError: 401 Unauthorized\n\nI think this is because the image as uploaded by the admin user is marked private, but trying euca-modify-image-attribute as the admin user to make the image public also fails.\n\nAs the student user I can bundle and upload images, but when In try to register I also have a 401 unauthorised.\n\nAny help or pointers on using multiple users in a project would be great. \n\nRegards\n\nJohn O\'Loughlin\nFEPS IT, Service Delivery Team Leader\n\n',NULL,NULL),('<16D6C4C9-2B5D-4533-B5E8-A9C00FBDB3FB@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-14 10:26:46',-14400,'2013-06-14 14:26:46',NULL,'[openstack-qa] [Openstack-qa-team] Script to prepare the stack\n	for full tempest run.','\nOn Jun 14, 2013, at 3:09 AM, Attila Fazekas <afazekas at redhat.com> wrote:\n\n> Lot of people does not see the true value of tempest like installation\n> and deployment independent testing.\n\n> \n> - These are the tests what all OpenStack user/admin/system integrator can share on.\n> - Tempest contains most of the tests what can work regardless to any topology or infra...\n> - Tempest can be isolated from the inspected deployment by multiple ways.\n> \n> This bug about isolation tempest cli tests and cli utilities:\n> https://bugs.launchpad.net/tempest/+bug/1150296\n> \n> Tempest even does not have to be on any machine which is part of the deployment,\n> so it can be even on different machine when you issue a multi-node packstack install.\n> This is the place where I prefer the isolation, instead of saving nodes.\n> But, you can run multiple tempest process on single node against multiple different deployment.\n> (tempest itself not a resource hunger process)\n\n+1\n\n> \n> - run packstack or devstack or whatever is not the first step in any testing and not the last.\n> - packstack is not the only way to deploy RDO or RHOS. \n> \n> If I had choose where to implement a __generic__ solution for fully prepare tempest test,\n> it will not be in packstack repo or the tempest repo.\n\nI apologize if I wasn\'t clear, but my focus is updating the tempest support in the stackforge/puppet-* modules.   The work will be reusable beyond packstack.  I would expect similar functionality to find its way into the openstack chef recipes.\n\nWhile I agree that a deployment-agnostic mechanism would be useful, I don\'t think it would replace the need for puppet/chef-native mechanisms.  It would, however, be essential to testing clouds that are already deployed.  In my ideal world such a mechanism would be implemented in python for ease of testing and maintenance, and live in the tempest repo.\n \n\n> \n> What I would really recommend is extending the tempest documentation\n> with a generic manual setup documentation\n> which contains copy paste-able code snippets and descriptions.\n\n+1 - Please do!\n\n> \n> Preparing tempest automatically is not an issue.\n\nI\'m not sure I agree.  I believe that CI is essential to ensuring the quality of a distributed system like openstack, and CI depends on being able to build and run tests without human intervention.  To this end, I\'m convinced that a given deployment mechanism is not feature-complete unless it supports automatic configuration of tempest (or some other automated test suite).\n\n\n> \n> What I would recommend (I created bugs in the bz) for packstack, \n> is changing the default settings to be more tempest friendly.\n> \n> I have additional packstack enhancement recommendation, \n> about what logic could be moved to the packstack.\n\nAs always, patches welcome!\n\n\nm.\n\n\n> \n> \n> \n> ----- Original Message -----\n> From: \"Jaroslav Henner\" <jhenner at redhat.com>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Cc: \"Sean Dague\" <sean at dague.net>\n> Sent: Thursday, June 13, 2013 5:40:17 PM\n> Subject: Re: [openstack-qa] [Openstack-qa-team] Script to prepare the stack for full tempest run.\n> \n> On ?t 13. ?erven 2013, 17:08:52 CEST, Sean Dague wrote:\n>> On 06/13/2013 10:59 AM, James Michel wrote:\n>>> On 13/06/13 14:50, Jaroslav Henner wrote:\n>>>> Hi,\n>>>> \n>>>> We wish to create some tool for automated preparation of stack for full\n>>>> tempest run. We need it to be able to work with deployment that has\n>>>> been\n>>>> prepared by Packstack [1].\n>>>> \n>>>> Packstack can give as an output some \"answer file\", which is\n>>>> actually an\n>>>> ini file. We can parse that file, take some other values as input, for\n>>>> example images locations, ... and create a tempest.conf accordingly.\n>>> \n>>> Actually we were looking at some smart way of configuring tempest.conf\n>>> after having deployed openstack. Is this more-or-less what you had in\n>>> mind?\n> \n> Yes but it is ... bit less than I had in mind. We need at least to \n> upload the images for testing (cirros), increase quotas, add testing \n> users. That\'s not what I would expect from the deploying tool to do. \n> Maybe if I called it with some --test parameter I would.\n> \n>>> \n>>>> \n>>>> The questions now are:\n>>>>  * Should this be a part of Tempest?\n>>>>  * Should this be a separate project?\n>>>>  * Should this be a part of the Packstack?\n>>>>  * What about other deploying tools - should that tool have several\n>>>> frond-ends?\n>>>>  * Does anybody have something already?\n>>>> \n>>>> Any comments?\n>>>> \n>>>> [1] https://wiki.openstack.org/wiki/Packstack\n>>>> \n>>>> PS: As Attila Fazekas pointed, most things we can find dynamically from\n>>>> the keystone/nova. True, but I don\'t quite like the idea to ssh to nova\n>>>> host to get nova SQL password and tricks like that.\n>>>> \n>>>> Jaroslav Henner\n>> \n>> So I really think that these tempest configuration generators should\n>> be back in the install tools themselves. We do this in devstack today,\n>> and the installer should just configure tempest.conf as it\'s output.\n>> \n>> It\'s not clear that an intermediary tool is really useful, because it\n>> means that when your installer enables a new feature, you have to fix\n>> the installer -> question file, then fix question engine -> tempest.\n>> \n>>    -Sean\n>> \n> \n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n\n','<2092322596.707489.1371193799136.JavaMail.root@redhat.com>',NULL),('<16EAC517-6966-4C08-B121-104BD3CBB030@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-07 17:35:27',0,'2014-04-07 17:35:27',NULL,'[openstack-dev] [Neutron] Status of\n	ovs-firewall-driver	blueprint?','Kyle,\n\nYes. I plan on getting all 4 existing patches up-to-date over the next 9 days. I?m not working on upstream 100% of the time so that?s not a hard commitment, but I think it?s definitely doable.\n\nAmir\n\nOn Apr 7, 2014, at 11:42 AM, Kyle Mestery <mestery at noironetworks.com<mailto:mestery at noironetworks.com>> wrote:\n\nOn Mon, Apr 7, 2014 at 11:01 AM, Amir Sadoughi\n<amir.sadoughi at rackspace.com<mailto:amir.sadoughi at rackspace.com>> wrote:\nHi Vishal,\n\nI\'ve restarted my work on the blueprint last week now that Juno is open for\ndevelopment and OVS 2.1.0 is available, targeting juno-1. My plan is to have\na working implementation available by the summit design discussion to make\nsure we cover all our bases. Between the blueprint page you referenced[0],\nthis wiki page[1], and the Gerrit review[2] site, that is all the up-to-date\ninformation. Outside of those links, any other updates will be on this\nmailing list or the ML2 weekly IRC meeting.\n\nI\'m open to collaboration and interested in anything you are able to\ncontribute. Do you have any existing work to share or feedback?\n\nAmir\n\nAmir, I looked at the review, and it\'s coming along nicely! Any chance\nyou can post a\nrebased version this week to get a clean Jenkins run?\n\nThanks!\nKyle\n\n[0] https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver\n[1] https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver\n[2] https://review.openstack.org/#/q/topic:bp/ovs-firewall-driver,n,z\n\nOn Apr 7, 2014, at 3:33 AM, Thapar, Vishal (HP Networking) <vthapar at hp.com<mailto:vthapar at hp.com>>\nwrote:\n\nHi,\n\nI am working on an OVS based implementation of Neutron Security Groups and\ncame across this blueprint:\nhttps://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver\n\nI\'ve gone through every mail, document and IRC chat log on this to get a\ngood grasp of history on this, but couldn\'t find any recent activity on this\nblueprint. It is listed on Meetings page on wiki but last meeting seems to\nhave been held last year in December. I\'ve just started working on\nprototyping this and would like to work with community to see it to\ncompletion.\n\nCould anyone suggest on how to proceed on this? Do I need to request a\nmeeting for this?\n\nThanks and Regards,\nVishal.\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140407/719a4c46/attachment.html>\n\n','<CADEmHi0W59YU-XLThUabvnaa06e-G_6FwSqgQ+L_56pTE5P2kQ@mail.gmail.com>',NULL),('<16ebf8ab50c6db132d457ebc477a0c23@home.nemebean.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-13 17:47:20',-18000,'2013-06-13 22:47:20',NULL,'[openstack-dev] [Swift] code changes feedback','There\'s a button in Gerrit to mark a change Work In Progress once you\'ve \nsubmitted it.  Sounds like that would be appropriate here.\n\n-Ben\n\nOn 2013-06-13 13:59, Pecoraro, Alex wrote:\n> I can submit code to gerrit that is not ready to be checked in (hasn\'t\n> been fully tested, unit tests aren\'t fully written yet, etc)?  Mainly\n> I\'m just looking for feedback so that I can be sure that I\'m headed in\n> a direction that will be acceptable when I am done.\n> \n> Thanks.\n> \n> Alex\n> \n> -----Original Message-----\n> From: John Dickinson [mailto:me at not.mn]\n> Sent: Wednesday, June 12, 2013 5:29 PM\n> To: OpenStack Development Mailing List\n> Subject: Re: [openstack-dev] [Swift] code changes feedback\n> \n> I\'m happy to see your interest in contributing. Now that the patch is\n> squashed (as gerrit requires), and since you actually already have the\n> code, submitting it to gerrit would be the best way to get feedback.\n> Gerrit will allow us to comment line-by-line and recommend any\n> changes, if needed. I\'d suggest adding a second paragraph to your\n> commit message with some of the info from your original email about\n> the reasons for this and problems it solves for you.\n> \n> Looking forward to seeing the patch in gerrit.\n> \n> --John\n> \n> \n> \n> \n> On Jun 12, 2013, at 1:38 PM, \"Pecoraro, Alex\" <Alex.Pecoraro at emc.com> \n> wrote:\n> \n>> I think I did the patch format correctly this time. So sending again.\n>> \n>> Alex\n>> \n>> From: Pecoraro, Alex [mailto:Alex.Pecoraro at emc.com]\n>> Sent: Wednesday, June 12, 2013 11:04 AM\n>> To: OpenStack Development Mailing List\n>> Subject: [openstack-dev] [Swift] code changes feedback\n>> \n>> Forgot to put the [Swift] on the subject of this email - resubmitting \n>> so it doesn\'t get missed.\n>> \n>> From: Pecoraro, Alex\n>> Sent: Wednesday, June 12, 2013 11:02 AM\n>> To: OpenStack Development Mailing List\n>> Subject: code changes feedback\n>> \n>> Hi, I\'ve been working on some changes to Swift that I\'m not quite done \n>> with, but I wanted to request some feedback on the path I\'m taking to \n>> make sure it is correct/acceptable. My changes don\'t add any new \n>> features per se, their purpose is to make the code a little more \n>> flexible so that it is easier to add custom behavior by subclassing \n>> base Swift classes and overriding key functions. The reason that I \n>> want to do this is so that I can create extensions to Swift either \n>> through monkey-patching or some other method that make it possible for \n>> Swift to work with Isilon storage devices. The main change that I \n>> needed to make was to how nodes are iterated in the proxy server, \n>> replicators, updaters, and the container synchronizer. So I created a \n>> class called NodeIterator and another class called \n>> NodeIteratorFactory, which are used for iterating the primary and \n>> handoff nodes rather than simply iterating the list of nodes returned \n>> by ring.get_nodes(), ring.get_more_nodes(), etc. So for example, the \n>> proxy server the code for iterating through nodes to satisfy a GET \n>> request  changes from this:\n>> \n>> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n>> ...\n>> for node in self.iter_nodes(ring, partition):\n>> \n>> to (more or less) this:\n>> \n>> def GETorHEAD_base(self, req, server_type, ring, partition, path):\n>> ...\n>> node_iter = self.node_iterator_factory.create(ring, part) for node in\n>> node_iter:\n>> \n>> My plan is to create a subclass of NodeIteratorFactory and override \n>> the create function to have it return a subclass of NodeIterator that \n>> iterates the nodes in a way that is compatible with Isilon devices.\n>> \n>> I\'ve attached a patch file showing what I\'ve done so far. Please take \n>> a look and let me know what you think.\n>> \n>> Also, I\'m not sure if I created the patch file correctly, it seems to \n>> show every change that I\'ve committed rather than just my most recent \n>> changes (this is my first time using git). I\'ve been committing \n>> locally and then pulling in changes from the origin/source as I go in \n>> order to lessen the chance of conflicts. Hopefully that\'s not too \n>> confusing.\n>> \n>> Thanks.\n>> \n>> Alex\n>> <node_iterator_changes.patch>_________________________________________\n>> ______\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<0B0DC37E1D749C4CAE907CB0D568C2A491BEA1FB@MX06A.corp.emc.com>',NULL),('<16fa1b4f.6dc5.147e6ac063c.Coremail.jazeltq@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-18 09:12:19',28800,'2014-08-18 01:12:19',NULL,'[openstack-dev] [nova] reboot after image changes','Hello,\n    After images changes its properties, we reboot the server, but the server will not read the new properties of that images. For example, if i change the os_type\n    for an image, then the reboot the vm created by that image. But the vm will create xml from instance read from nova db. Not use the new images os_type.\n\n\n\n\n--\n\nBest\n    Li Tianqing\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140818/7b0fbb17/attachment.html>\n\n',NULL,NULL),('<16FAB602-8813-4364-8703-A652A1442571@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-07-31 11:21:55',-25200,'2012-07-31 18:21:55',NULL,'[openstack-dev] [nova] Team meeting details','Hey Everyone,\n\nOne of the most important items from the agenda[1] for the Nova meeting on Thursday is discussing some api consistency issues. I wanted to give a little overview on what I want to discuss, so that people have time to prepare in advance of the meeting.\n\nThe main issue is that we have a bunch of data that we handle as part of a post to servers that is not in the core api spec. This data really belongs to extensions (and is in fact directly related to a specific extension in most cases). Unfortunately, there is no way to turn processing for this extra data off, which is basically a Very Bad Thing?.\n\nI\'ve been thinking about a simple way to solve this issue, and I\'ve come up with a spec[2] that i think is workable. I\'d like to get some decisions on the following at the meeting:\n\na) is this approach acceptable?\n * does it need to be modified slightly?\n * is renaming the badly named extensions ok?\n * is there a more general approach that extensions could use?\nb) is there an alternative to this that is easier/better?\n * alternative: bump minor version of the api?\nc) who wants to help on produce the required code in the next week?\nd) who wants to help update the documentation?\ne) who wants to investigate xml?\n\nAlso, a quick heads up on the \"Other Potential Issues\" section on the agenda[1]. I want to discuss large user/deployer facing issues. I\'ve listed the ones that I know about. I would like to get some consensus on whether we should push to get any of these fixed in Folsom, either during f-3 or bugfixing. If there are other key user issues, let me know so I can add them to the list.\n\n[1] http://wiki.openstack.org/Meetings/Nova\n[2] http://wiki.openstack.org/DisableServerExtensions\n\n',NULL,NULL),('<170035844.1057893.1376430439494.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 17:47:19',-14400,'2013-08-13 21:47:19',NULL,'[openstack-dev] Blueprint: launch-time configurable kernel-id,\n ramdisk-id, and kernel command line','I have just created a new blueprint: https://blueprints.launchpad.net/nova/+spec/expose-ramdisk-kernel-and-command-line-via-rest-and-cli\n\nI realize that some of this work overlaps with: https://blueprints.launchpad.net/nova/+spec/improve-boot-from-volume\nwhich is an umbrella blueprint for: https://blueprints.launchpad.net/nova/+spec/improve-block-device-handling\n\nI can see that a lot of work has been done for the above blueprints, but I was not clear on the progress with regard to exposing kernel-id and ramdisk-id.  Perhaps I don\'t need to implement this?   \n\nThe second change proposed in the blueprint has not been addressed in any other blueprints.  Does anyone think that adding ability to pass in at launch time the kernel command line would be problematic?\n\nThanks,\nDennis\n\n\n','<1513567488.1057806.1376430356284.JavaMail.root@redhat.com>',NULL),('<1701434552.6655660.1377761002744.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-08-29 03:23:22',-14400,'2013-08-29 07:23:22',NULL,'[Openstack] Adding User to Roles invalidates current token?','Hi Joe,\n\n\"Joe Topjian\" <joe.topjian at cybera.ca> wrote:\n> I\'m running through some Folsom to Grizzly upgrade tests and have noticed\n> an odd issue with Keystone and Horizon:\n> \n> If I\'m logged into Horizon as the admin user and then (on the command line)\n> add a role to the admin user to a tenant, my Horizon session is now invalid\n> and I have to logout and log back in.\n> \n> Logs are showing this error:\n> \n> Unauthorized: Unable to communicate with identity service: {\"error\":\n> {\"message\": \"Could not find token: 80429dc1ca214b39ad3ef17a71ac5915\",\n> \"code\": 401, \"title\": \"Not Authorized\"}}. (HTTP 401)\n> \n> If I use MySQL as the token store, I can see that the token in question has\n> indeed become invalid.\n> \n> I\'m not sure if something broke or is misconfigured from the upgrade or if\n> this is a new characteristic of Keystone?\n\nThis sounds like https://bugs.launchpad.net/keystone/+bug/1170186 which should have been backported to Grizzly 2013.1.3 (Aug 8th stable release).\n\nJulie\n\n> \n> Any ideas?\n> \n> Thanks,\n> Joe\n> \n> --\n> Joe Topjian\n> Systems Architect\n> Cybera Inc.\n> \n> www.cybera.ca\n> \n> Cybera is a not-for-profit organization that works to spur and support\n> innovation, for the economic benefit of Alberta, through the use\n> of cyberinfrastructure.\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAD07=DcB4VSjPspZRQ=xALicUUxnkxvquQ4u43W5We6i2SgdQQ@mail.gmail.com>',NULL),('<1702792189.59.1352765521848.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-13 00:12:01',0,'2012-11-13 00:12:01',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-docs-stable-diablo #91','See <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/91/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/>\nCheckout:periodic-swift-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/> - hudson.remoting.Channel at 183b7230:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson266739229804043521.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-docs-stable-diablo/91\n[SCP] Copying console log.\n\n\n','<1539087966.46.1352679123652.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1703962525.14297102.1352821794918.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-13 10:49:54',-18000,'2012-11-13 15:49:54',NULL,'[openstack-dev] [Nova] Reviews and core members','\n\n----- Original Message -----\n> From: \"Yun Mao\" <yunmao at gmail.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, November 12, 2012 10:03:40 AM\n> Subject: Re: [openstack-dev] [Nova] Reviews and core members\n> \n> +1 to all three. Would be wonderful additions to the core. Thanks,\n> \n> Yun\n> \n> \n> On Fri, Nov 9, 2012 at 11:27 PM, Chris Behrens\n> <cbehrens at codestud.com>wrote:\n> \n> > +1 on those 3 for core.\n> >\n> > On Nov 9, 2012, at 4:16 PM, Vishvananda Ishaya\n> > <vishvananda at gmail.com>\n> > wrote:\n> >\n> > > Hey Everyone,\n> > >\n> > > It\'s that time again. We are falling behind with over 100 reviews\n> > > in the\n> > nova queue[1]. It would be great if more people were involved in\n> > the review\n> > process. Here are the stats from the last thirty days for core\n> > members:\n> > >\n> > > Kevin Mitchell \"klmitch\": 207\n> > > Michael Still \"mikalstill\": 197\n> > > Vish Ishaya \"vishvananda\": 175\n> > > Russell Bryant \"russellb\": 160\n> > > Mark McLoughlin \"markmc\": 113\n> > > Josh Kearney \"jk0\": 90\n> > > Johannes Erdfelt \"johannes.erdfelt\": 84\n> > > Chris Behrens \"cbehrens\": 64\n> > > P?draig Brady \"p-draigbrady\": 55\n> > > Matt Dietz \"cerberus\": 36\n> > > Yon Mao\"yunmao\": 58\n> > > Dan Prince \"dan-prince\": 22\n> > > Rick Harris \"rconradharris\": 12\n> > > Christopher MacGown \"0x44\": 6\n> > > Brian Waldon \"bcwaldon\": 5\n> > > Trey Morris \"tr3buchet\": 5\n> > > Sandy Walsh \"sandy-walsh\": 1\n> > > Devin Carlen \"devcamcar\": 0\n> > > Mark Washenberger \"markwash\": 0\n> > >\n> > > Thanks to everyone who has been active! Based on these numbers I\n> > > think\n> > it is fairly clear that there are some people who have moved on to\n> > other\n> > things. I\'d like to propose we cut the following people from core:\n> > >\n> > > Christopher MacGown, Brian Waldon, Trey Morris, Sandy Walsh,\n> > > Devin\n> > Carlen, Mark Washenberger.\n> > >\n> > > As before, please keep in mind that this isn\'t intended to\n> > > question the\n> > amazing work that all of these people have done for nova.\n> >  Nova-core is a\n> > review team, so we have to make sure the people on it actually have\n> > time to\n> > do reviews. If anyone jumps back in and starts reviewing we can\n> > fast-track\n> > them back in.\n> > >\n> > > I\'d also like to propose that we add the following active\n> > > reviewers to\n> > the core team:\n> > >\n> > > Dan Smith \"danms\": 84\n\n+1\n\n> > > Has been doing a lot of work with russelb on no-db-compute\n> > >\n> > > Sean Dague \"sdague-b\": 82\n\n+1\n\n> > > Has been leading a lot of the api related work and api-sample\n> > > testing\n> > >\n> > > Joe Gordon \"joe-gordon0\": 48\n\n+1\n\n> > > Has been doing lots of general cleanup and feature work around\n> > > host\n> > aggregates\n> > >\n> > > Nova Core members: Please +1 each person you think should join\n> > > nova core.\n> > >\n> > > Vish\n> > >\n> > > [1]\n> > https://review.openstack.org/#/q/status:open+project:openstack/nova,n,z\n> > > _______________________________________________\n> > > OpenStack-dev mailing list\n> > > OpenStack-dev at lists.openstack.org\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CADcnTpvcQ5eo_kyibWn74JhhEdCn0D=NuaNGNpzXVEEtJHGh4w@mail.gmail.com>',NULL),('<170424517.17430850.1383318892142.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 11:14:52',-14400,'2013-11-01 15:14:52',NULL,'[openstack-dev] [Solum] Some initial code copying for db/migration\n (was: Stackforge Repo Ready)','----- Original Message -----\n> Noorul Islam K M <noorul at noorul.com> writes:\n> \n> > Adrian Otto <adrian.otto at rackspace.com> writes:\n> >\n> >> Team,\n> >>\n> >> Our StackForge code repo is open, so you may begin submitting code for\n> >> review. For those new to the process, I made a will page with links to\n> >> the repo and information about how to contribute:\n> >>\n> >> https://wiki.openstack.org/wiki/Solum/Contributing\n> >>\n> >\n> > 1. .gitreview file is missing, so I submitted a patch\n> >\n> > https://review.openstack.org/#/c/54877\n> >\n\nOnce all the gitreview stuff is cleaned up I was going to do some purely mechanical additions.\n\nI heard a few +1 for sqlalchemy with the standard OpenStack abstraction:\n\nsolum/db/api.py\n  manager abstraction for db calls\nsolum/db/sqlalchemy/api.py\n  sqlalchemy implementation\n\nI was also going to throw in migrate as a dependency and put in the glue code for that based on common use from ironic/trove/heat.  That\'ll pull in a few openstack common and config settings.  Finally, was going to add a solum-dbsync command a la the aforementioned projects.  No schema will be added.\n\nObjections?\n\n\n','<87eh70bnsh.fsf@noman.maa.corp.collab.net>',NULL),('<1704470.M972dm09rI@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-15 11:44:21',39600,'2014-10-15 00:44:21',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','On Tue, 14 Oct 2014 07:51:54 AM Steven Dake wrote:\n> Angus,\n> \n> On 10/13/2014 08:51 PM, Angus Lees wrote:\n> > I\'ve been reading a bunch of the existing Dockerfiles, and I have two\n> > humble requests:\n> > \n> > \n> > 1. It would be good if the \"interesting\" code came from python\n> > sdist/bdists\n> > rather than rpms.\n> > \n> > This will make it possible to rebuild the containers using code from a\n> > private branch or even unsubmitted code, without having to go through a\n> > redhat/rpm release process first.\n> > \n> > I care much less about where the python dependencies come from. Pulling\n> > them from rpms rather than pip/pypi seems like a very good idea, given\n> > the relative difficulty of caching pypi content and we also pull in the\n> > required C, etc libraries for free.\n> > \n> > \n> > With this in place, I think I could drop my own containers and switch to\n> > reusing kolla\'s for building virtual testing environments.  This would\n> > make me happy.\n> \n> I\'ve captured this requirement here:\n> https://blueprints.launchpad.net/kolla/+spec/run-from-master\n> \n> I also believe it would be interesting to run from master or a stable\n> branch for CD.  Unfortunately I\'m still working on the nova-compute\n> docker code, but if someone comes along and picks up that blueprint, i\n> expect it will get implemented :)  Maybe that could be you.\n\nYeah I\'ve already got a bunch of working containers that pull from master[1], \nbut I\'ve been thinking I should change that to use an externally supplied \nbdist.  The downside is you quickly end up wanting a docker container to build \nyour deployment docker container.  I gather this is quite a common thing to \ndo, but I haven\'t found the time to script it up yet.\n\n[1] https://github.com/anguslees/kube-openstack/tree/master/docker\n\nI could indeed work on this, and I guess I was gauging the level of enthusiasm \nwithin kolla for such a change.  I don\'t want to take time away from the \nalternative I have that already does what I need only to push uphill to get it \nintegrated :/\n\n> > 2. I think we should separate out \"run the server\" from \"do once-off\n> > setup\".\n> > \n> > Currently the containers run a start.sh that typically sets up the\n> > database, runs the servers, creates keystone users and sets up the\n> > keystone catalog.  In something like k8s, the container will almost\n> > certainly be run multiple times in parallel and restarted numerous times,\n> > so all those other steps go against the service-oriented k8s ideal and\n> > are at-best wasted.\n> > \n> > I suggest making the container contain the deployed code and offer a few\n> > thin scripts/commands for entrypoints.  The main\n> > replicationController/pod _just_ starts the server, and then we have\n> > separate pods (or perhaps even non-k8s container invocations) that do\n> > initial database setup/migrate, and post- install keystone setup.\n> \n> The server may not start before the configuration of the server is\n> complete.  I guess I don\'t quite understand what you indicate here when\n> you say we have separate pods that do initial database setup/migrate.\n> Do you mean have dependencies in some way, or for eg:\n> \n> glance-registry-setup-pod.yaml - the glance registry pod descriptor\n> which sets up the db and keystone\n> glance-registry-pod.yaml - the glance registry pod descriptor which\n> starts the application and waits for db/keystone setup\n> \n> and start these two pods as part of the same selector (glance-registry)?\n> \n> That idea sounds pretty appealing although probably won\'t be ready to go\n> for milestone #1.\n\nSo the way I do it now, I have a replicationController that starts/manages \n(eg) nova-api pods[2].  I separately have a nova-db-sync pod[3] that basically \njust runs \"nova-manage db sync\".\n\nI then have a simple shell script[4] that starts them all at the same time.  \nThe nova-api pods crash and get restarted a few times until the database has \nbeen appropriately configured by the nova-db-sync pod, and then they\'re fine and \nstart serving.\n\nWhen nova-db-sync exits successfully, the pod just sits in state terminated \nthanks to restartPolicy: onFailure.  Sometime later I can delete the \nterminated nova-db-sync pod, but it\'s also harmless if I just leave it or even \nif it gets occasionally re-run as part of some sort of update.\n\n\n[2] https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-api-repcon.yaml\n[3] https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-db-sync-pod.yaml\n[4] https://github.com/anguslees/kube-openstack/blob/master/kubecfg-create.sh\n\n\n> > I\'m open to whether we want to make these as lightweight/independent as\n> > possible (every daemon in an individual container), or limit it to one per\n> > project (eg: run nova-api, nova-conductor, nova-scheduler, etc all in one\n> > container).   I think the differences are run-time scalability and\n> > resource- attribution vs upfront coding effort and are not hugely\n> > significant either way.\n> > \n> > Post-install catalog setup we can combine into one cross-service setup\n> > like\n> > tripleO does[1].  Although k8s doesn\'t have explicit support for batch\n> > tasks currently, I\'m doing the pre-install setup in restartPolicy:\n> > onFailure pods currently and it seems to work quite well[2].\n> > \n> > (I\'m saying \"post install catalog setup\", but really keystone catalog can\n> > happen at any point pre/post aiui.)\n> > \n> > [1]\n> > https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-> > endpoints [2]\n> > https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nov\n> > a-db-sync-pod.yaml\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \n - Gus\n\n\n','<543D388A.8070408@redhat.com>',NULL),('<1705505304.12688529.1391617839833.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-05 08:30:39',-28800,'2014-02-05 16:30:39',NULL,'[OpenStack Foundation] The two types of interoperability','----- Original Message -----\n\n| From: \"Troy Toman\" <troy at tomanator.com>\n| To: \"Nicolas Barcet\" <nicolas at barcet.com>\n| Cc: foundation at lists.openstack.org\n| Sent: Wednesday, February 5, 2014 8:08:02 AM\n| Subject: Re: [OpenStack Foundation] The two types of interoperability\n\n| On Feb 5, 2014, at 7:13 AM, Nicolas Barcet < nicolas at barcet.com > wrote:\n\n| | Having been part of the defcore committee for a bit, I must say that\n| \n| | the work that is being done there has a very good intent. It is\n| \n| | also great to define what type of interoperability we want to mesure\n| \n| | and offer is key to providing OpenStack users valuable information\n| \n| | they expect.\n| \n\n| | However, as part of this committee, I have failed to make myself\n| \n| | heard on a very key point in my mind. The notion of core, or\n| \n| | interoperability, means 3 different things, because of the nature of\n| \n| | what we do and the population they address:\n| \n| | 1/ Which projects are part of core and can call themselves\n| \n| | OpenStack?\n| \n| | -> Interesting to developpers and distribution builders\n| \n\n| | 2/ Which distributions are based on core OpenStack and can therefore\n| \n| | call themselves OpenStack?\n| \n| | -> Interesting to cloud operators that want to pick an OpenStack\n| \n| | distribution\n| \n\n| | 3/ Which clouds are delivering an OpenStack experience and can call\n| \n| | themselves OpenStack?\n| \n| | -> Interesting to cloud users and enterprises wanting to pick the\n| \n| | right infrastructure to deploy their application on\n| \n\n| | The current bylaws of the foundation fails to make this distinction in\n| \n| | defining the term Core, and therefore the DefCore committee has failed\n| \n| | to distinguish those 3 aspects and is producing what seems to me a\n| \n| | bunch of rules which, by trying to satisfy 3 very different things with\n| \n| | a single set, is going to, at best, produce some lowest common\n| \n| | denominator set.\n| \n\n| I think Nick begins the discussion around a very important point that I have\n| also, so far, failed to articulate well. We keep tying to solve multiple\n| problems with one solution.\n\n| (Here is where I started articulate, in my words, those problems and realized\n| It was essentially a repeat Nick\'s)\n\n| \"Core\" can\'t solve all of these with one brand/test/process and be very good\n| at it. I don\'t think every feature/capability/option in Nova should be\n| required in an \"OpenStack cloud\", for instance. But, just branding a\n| collection of capabilities as OpenStack without anyway to extend the brand\n| to the major projects is not proving to be a satisfying approach either. We\n| need to find the best approach for these specific problems vs. trying to\n| stretch \"core\" to be everything.\n\nStrongly agree :) \n\nTo me the key interoperability question is \"can I as a user easily understand the portability of my workload across different clouds that use the OpenStack label\". While one approach to this is that all clouds labeled \"OpenStack\" have exactly the same \"core\" API/toolset surface, I doubt this is a very practical approach. For example, I know many people who are deploying OpenStack without Swift, and that makes perfect sense for them. What they would care about is whether the code that wrote against their API (Nova, Glance, etc.) would work against another cloud. So if we instead approach the problem from a sense of \"how can we give people a mental framework and perhaps a set of tools for understanding interoperability\", I think we will end up at a much better place. \n\nAnd I definitely agree that using the term \"core\" for othis is extra confusing, as the same term applies to a projects status. However, just because a project is \"core\" does not mean that all instances of it expose the same API/toolset surface, due to API extensions, different release versions, different configuration options, different flavors, etc. \n\nDan \n\n| | So, yes, we need to determine which type of interoperability we want\n| \n| | to achieve, but I do think that we need to define what is Core\n| \n| | independently for each one of the 3 cases above. The perception of\n| \n| | what OpenStack is cannot be defined independently of the type of users\n| \n| | and what interactions they are going to have with OpenStack. and this\n| \n| | may very well have ties onto which body has the right to validate what\n| \n| | Core is.\n| \n\n| | _______________________________________________\n| \n| | Foundation mailing list\n| \n| | Foundation at lists.openstack.org\n| \n| | http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation\n| \n\n| _______________________________________________\n| Foundation mailing list\n| Foundation at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=BwXFws9S3oB5yn4XyrLBKqyCiMCR2a6GqTO5yTehi3Y%3D%0A&s=fa24bbe732e8d92f221c82a92ee0c6ad7edebdf49febaea76475146bb9c23be9\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140205/767b4af3/attachment-0001.html>\n\n','<4CAE49B2-2BAD-4BC6-B92C-F65C9BD49F2F@tomanator.com>',NULL),('<1705659276F6A540A34DBC1919579984101610CB@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-06 20:54:56',0,'2013-05-06 20:54:56',NULL,'[openstack-dev] how to configure cisco plugin in devstack\n environment','Hi YuLing,\n\nMy guess is that you pulled the code from the master. So please follow this link https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana_Release.29 instead.\n\nCurrently, configuring Q_PLUGIN to use cisco plugin is not available in devstack yet, and it\'s being worked on. Therefore you have to manually configure it with instructions given in the above link.\n\nThanks,\nRobert\n\nOn 5/6/13 1:50 PM, \"Yuling_C at DELL.com<mailto:Yuling_C at DELL.com>\" <Yuling_C at DELL.com<mailto:Yuling_C at DELL.com>> wrote:\n\n\nHi All,\n\n\n\nI\'m new to devstack and would need to configure cisco plugin to work in devstack environment. I followed the instruction in the webpage (https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Grizzly_Release.29) to configure cisco plugin. However, devstack seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n\n\n\nI tried to set up Q_plugin in localrc. However, it seems cisco is not one of the plugins supported under /opt/stack/devstack/lib/quantum_plugins...do I need to configure this variable in localrc? If not, what else I need to do in order for openstack to pick up Cisco plugin in devstack environment?\n\n\n\nThanks,\n\n\n\nYuLing\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130506/f78a7162/attachment.html>\n\n','<0B87C97B6D8E0B43BAF497C2B90FA0F3E150119F49@AUSX7MCPC101.AMER.DELL.COM>',NULL),('<1705659276F6A540A34DBC191957998410161462@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 13:42:18',0,'2013-05-07 13:42:18',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Hi Yuling,\n\nSee below for the response from Rich.\n\nThanks,\nRobert\n\nOn 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 9:29 AM\n>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack\n>environment\n>\n>Hi Yuling -\n>\n>I think there\'s at least one major mismatch going on here.\n>\n>If you\'re using Robert\'s devstack change\n>(https://review.openstack.org/#/c/25378/) then this assumes another\n>change (cisco-single-config blueprint) that was committed to the\n>openstack master branch but didn\'t make it into stable/grizzly.\n>\n>If you want to continue to use Robert\'s devstack changes then please\n>comment out this line from your localrc file:\n>#QUANTUM_BRANCH=stable/grizzly\n>\n>./unstack.sh and then ./stack.sh again\n>\n>This should pick up the master version of quantum. To check verify that\n>the only file under:\n>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Kyle Mestery (kmestery)\n>Sent: Tuesday, May 07, 2013 9:07 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>environment\n>\n>Did you do a \"git fetch\"? I think you may want to do that to ensure you\n>get the entire change set.\n>\n>Can you paste the contents of your\n>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>\n>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>\n>> Actually, I just followed the instruction on devstack grizzly\n>> installation \n>> link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>> ck/ and installed again. I copied over the \'cisco\' file from the link\n>> https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and set\n>>Q_plugin = cisco.\n>> \n>> However, when I run stack.sh, Quantum server was not able to start with\n>>the following error in screen-q-svc.log:\n>> \n>>    __import__(mod_str)\n>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>line 30, in <module>\n>>    from quantum.plugins.cisco.common import cisco_utils as cutil  File\n>> \"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line\n>>23, in <module>\n>>    from quantum.plugins.cisco.db import l2network_db as cdb  File\n>> \"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line 24,\n>>in <module>\n>>    from quantum.plugins.cisco import l2network_plugin_configuration as\n>> conf  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration.\n>>py\", line 21, in <module>\n>>    from quantum.plugins.cisco.common import cisco_configparser as\n>> confp  File \n>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\",\n>>line 19, in <module>\n>>    from configobj import ConfigObj\n>> ImportError: No module named configobj\n>> ERROR: Unable to load quantum from configuration file\n>>/etc/quantum/api-paste.ini.\n>> \n>> Any idea why there\'s an input error for loading \'configobj\'? this file\n>>should be under /usr/lib/python2.7/dist-packages/landscape/lib. Why\n>>quantum cannot load this file?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> ________________________________________\n>> From: C, Yuling\n>> Sent: Monday, May 06, 2013 7:58 PM\n>> To: openstack-dev at lists.openstack.org\n>> Cc: rcurran at cisco.com\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>> environment\n>> \n>> Thanks Kyle and Robert very much for all these information.\n>> \n>> So, it seems that the new devstack version that contains Cisco plugin\n>>support is already available at https://review.openstack.org/#/c/25378/?\n>>Should I just use \'git fetch\' to download it and install? Is this Havana\n>>version(release)?\n>> \n>> After I download, can I just use Q_plugin to configure the core plugin?\n>>Do I still need to follow the manual set up steps on\n>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_fo\n>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Hava\n>>na_Release.29?\n>> \n>> Thanks,\n>> \n>> YuLing\n>> \n>> \n>> -----Original Message-----\n>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>> Sent: Monday, May 06, 2013 2:09 PM\n>> To: OpenStack Development Mailing List\n>> Cc: Rich Curran (rcurran)\n>> Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>> environment\n>> \n>> I should note Robert\'s review for adding support to devstack for the\n>>Cisco plugin is here:\n>> \n>> https://review.openstack.org/#/c/25378/\n>> \n>> I\'ve been running with it for a few weeks and it works great!\n>> \n>> Thanks,\n>> Kyle\n>> \n>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>> \n>>> Hi YuLing,\n>>> \n>>> My guess is that you pulled the code from the master. So please follow\n>>>this link \n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_f\n>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Ha\n>>>vana_Release.29 instead.\n>>> \n>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available\n>>>in devstack yet, and it\'s being worked on. Therefore you have to\n>>>manually configure it with instructions given in the above link.\n>>> \n>>> Thanks,\n>>> Robert\n>>> \n>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>> \n>>>> Hi All,\n>>>> \n>>>> I\'m new to devstack and would need to configure cisco plugin to work\n>>>>in devstack environment. I followed the instruction in the webpage\n>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack\n>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any idea?\n>>>> \n>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is not\n>>>>one of the plugins supported under\n>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure this\n>>>>variable in localrc? If not, what else I need to do in order for\n>>>>openstack to pick up Cisco plugin in devstack environment?\n>>>> \n>>>> Thanks,\n>>>> \n>>>> YuLing\n>>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n\n','<96B198D1930C1D489CDF84797AC8170E20FC30@xmb-rcd-x13.cisco.com>',NULL),('<1705659276F6A540A34DBC191957998410164288@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-15 13:03:49',0,'2013-05-15 13:03:49',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Hi Yuling,\n\nThe Name of the database is not important. In other words, they are the\nsame database with different names.\n\n--Robert\n\nOn 5/14/13 8:42 PM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>Hi Yuling -\n>\n>Are you now using either an external nexus switch and/or the Nexus 1000\n>in your topology?\n>If not then I don\'t know why you would enable Q_PLUGIN=cisco in\n>devstack\'s localrc.\n>\n>But if you want to move forward regardless of available Cisco devices\n>then you would have to follow the instructions listed in that web link\n>below or you can add some additional information to the localrc file.\n>Robert has put this info on a Cisco internal webpage so I\'ll cut/paste\n>here. At some point (if he hasn\'t already) we should add this info to the\n>devstack.org documentation.\n>=====================================================\n>Customization in localrc\n>\n>In addition to existing DevStack variables, DevStack with Cisco plugin\n>supports the following bash variables that can be defined in localrc.\n>declare -a Q_CISCO_PLUGIN_SUBPLUGINS 	\n>\n>Supported values are:\n>    (openvswitch)\n>    (openvswitch nexus)\n>    (n1kv)\n>    (n1kv nexus)\n>\n>Defines the subplugins that will be deployed with this DevStack. For\n>example:\n>\n>declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)\n>------------------------------------------------------\n>declare -A Q_CISCO_PLUGIN_SWITCH_INFO 	\n>\n>The value has the following format:\n> \n>({<switch_ip>=<username>:<password>:<ssh_port>[:<compute-host-name>:<nexus\n>-port-connected-with>] })\n>\n>Defines the nexus switch information used in the deployment. This is a\n>bash associative array with nexus switch ip addresses as keys.\n>Essentially, it defines the switch\'s access information, and the compute\n>hosts that are connected to the switch. An example looks like\n>             declare -A Q_CISCO_PLUGIN_SWITCH_INFO=\n>([1.1.1.1]=admin:mySecretPassword:22:compute1:1/1:compute2:1/2)\n>\n>If Q_CISCO_PLUGIN_SWITCH_INFO is not defined in localrc, it assumes no\n>switch is used in the deployment. In that case, if the nexus subplugin is\n>deployed (as indicated by the Q_CISCO_PLUGIN_SUBPLUGINS array), a fake\n>switch (with a fake driver) will be deployed.\n>\n>**** - Note - since you\'re not using any cisco devices I wouldn\'t declare\n>this variable and have the fake nexus driver configured.\n>======================================================\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\n>Sent: Tuesday, May 14, 2013 5:52 PM\n>To: Rich Curran (rcurran); openstack-dev at lists.openstack.org\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Rich,\n>\n>I was able to use Robert\'s file of lib/quantum_plugins/cisco to run cisco\n>plugin in devstack environment. However, I\'m not sure if everything was\n>set up correctly in my environment. I thought this configuration using\n>Q_plugin=cisco in localrc would set up exactly the same environment as\n>what the instructions on the following attached link describes. However,\n>I was not able to see the \'quantum_l2network\' database at all. All I saw\n>was database \'cisco_quantum\'.  Is there anything wrong in my set up?\n>Should I see \'quantum_l2network\' at all?\n> \n>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for\n>_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana\n>_Release.29\n>\n>Thanks,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: C, Yuling\n>Sent: Tuesday, May 07, 2013 11:40 AM\n>To: \'Rich Curran (rcurran)\'; OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>B.T.W.,  I\'m not planning to use a Nexus switch in my testing environment\n>for now...just would like to use the fake driver to see how it\n>goes...will plugin a real switch later:-)\n>\n>Thanks very much,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\n>Sent: Tuesday, May 07, 2013 11:13 AM\n>To: OpenStack Development Mailing List; C, Yuling\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>HI Yuling -\n>\n>Actually if you change the localrc as described below you won\'t have to\n>install configobj (I don\'t think).\n>So change the localrc first, unstack, stack. I don\'t think at that point\n>you\'ll have the configobj issue.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 2:09 PM\n>To: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\n>Subject: Re: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Yuling -\n>\n>Here are instructions I found on installing configobj:\n>http://www.voidspace.org.uk/python/articles/configobj.shtml\n>\n>Also, you didn\'t get the latest (master) cisco quantum code.\n>In localrc please add/change:\n>OFFLINE=False\n>RECLONE=yes\n>\n>Also, are you using a nexus hardware switch in your topology?\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\n>Sent: Tuesday, May 07, 2013 1:46 PM\n>To: openstack-dev at lists.openstack.org\n>Cc: Rich Curran (rcurran)\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Thanks very much for the information... I just tried commenting out\n>#QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I\n>still hit the same issue.\n>\n>From reading the log, I can see quantum was trying to pick up cisco\n>plugin. However, it failed at importing configobj at\n>cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t\n>see any instructions for changing this environment variable)\n>\n>When you mentioned that\n>>\' this assumes another\n>>change (cisco-single-config blueprint) that was committed to the\n>>openstack master branch but didn\'t make it into stable/grizzly\'.\n>\n>Do I need to pick up this change as well? The only thing I picked up was\n>Robert\'s file of lib/quantum_plugins/cisco...the rest running on my\n>environment was devstack grizzly release...\n>\n>\n>Thanks,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: Robert Li (baoli) [mailto:baoli at cisco.com]\n>Sent: Tuesday, May 07, 2013 6:42 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: [openstack-dev] FW: how to configure cisco plugin in devstack\n>environment\n>\n>Hi Yuling,\n>\n>See below for the response from Rich.\n>\n>Thanks,\n>Robert\n>\n>On 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n>\n>>\n>>\n>>-----Original Message-----\n>>From: Rich Curran (rcurran)\n>>Sent: Tuesday, May 07, 2013 9:29 AM\n>>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack\n>>environment\n>>\n>>Hi Yuling -\n>>\n>>I think there\'s at least one major mismatch going on here.\n>>\n>>If you\'re using Robert\'s devstack change\n>>(https://review.openstack.org/#/c/25378/) then this assumes another\n>>change (cisco-single-config blueprint) that was committed to the\n>>openstack master branch but didn\'t make it into stable/grizzly.\n>>\n>>If you want to continue to use Robert\'s devstack changes then please\n>>comment out this line from your localrc file:\n>>#QUANTUM_BRANCH=stable/grizzly\n>>\n>>./unstack.sh and then ./stack.sh again\n>>\n>>This should pick up the master version of quantum. To check verify that\n>>the only file under:\n>>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>>\n>>Thanks,\n>>Rich\n>>\n>>-----Original Message-----\n>>From: Kyle Mestery (kmestery)\n>>Sent: Tuesday, May 07, 2013 9:07 AM\n>>To: OpenStack Development Mailing List\n>>Cc: Rich Curran (rcurran)\n>>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>>environment\n>>\n>>Did you do a \"git fetch\"? I think you may want to do that to ensure you\n>>get the entire change set.\n>>\n>>Can you paste the contents of your\n>>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>>\n>>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>>\n>>> Actually, I just followed the instruction on devstack grizzly\n>>>installation \n>>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>>> ck/ and installed again. I copied over the \'cisco\' file from the link\n>>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and\n>>>set Q_plugin = cisco.\n>>> \n>>> However, when I run stack.sh, Quantum server was not able to start\n>>>with the following error in screen-q-svc.log:\n>>> \n>>>    __import__(mod_str)\n>>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>>line 30, in <module>\n>>>    from quantum.plugins.cisco.common import cisco_utils as cutil File\n>>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line\n>>>23, in <module>\n>>>    from quantum.plugins.cisco.db import l2network_db as cdb  File\n>>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line\n>>>24, in <module>\n>>>    from quantum.plugins.cisco import l2network_plugin_configuration\n>>>as  conf  File \n>>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration\n>>>.\n>>>py\", line 21, in <module>\n>>>    from quantum.plugins.cisco.common import cisco_configparser as\n>>>confp  File \n>>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>>\",\n>>>line 19, in <module>\n>>>    from configobj import ConfigObj\n>>> ImportError: No module named configobj\n>>> ERROR: Unable to load quantum from configuration file\n>>>/etc/quantum/api-paste.ini.\n>>> \n>>> Any idea why there\'s an input error for loading \'configobj\'? this\n>>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>>Why quantum cannot load this file?\n>>> \n>>> Thanks,\n>>> \n>>> YuLing\n>>> \n>>> ________________________________________\n>>> From: C, Yuling\n>>> Sent: Monday, May 06, 2013 7:58 PM\n>>> To: openstack-dev at lists.openstack.org\n>>> Cc: rcurran at cisco.com\n>>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>>> devstack environment\n>>> \n>>> Thanks Kyle and Robert very much for all these information.\n>>> \n>>> So, it seems that the new devstack version that contains Cisco plugin\n>>>support is already available at https://review.openstack.org/#/c/25378/?\n>>>Should I just use \'git fetch\' to download it and install? Is this\n>>>Havana version(release)?\n>>> \n>>> After I download, can I just use Q_plugin to configure the core plugin?\n>>>Do I still need to follow the manual set up steps on\n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>>_fo\n>>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>>ava\n>>>na_Release.29?\n>>> \n>>> Thanks,\n>>> \n>>> YuLing\n>>> \n>>> \n>>> -----Original Message-----\n>>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>>> Sent: Monday, May 06, 2013 2:09 PM\n>>> To: OpenStack Development Mailing List\n>>> Cc: Rich Curran (rcurran)\n>>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>>> devstack environment\n>>> \n>>> I should note Robert\'s review for adding support to devstack for the\n>>>Cisco plugin is here:\n>>> \n>>> https://review.openstack.org/#/c/25378/\n>>> \n>>> I\'ve been running with it for a few weeks and it works great!\n>>> \n>>> Thanks,\n>>> Kyle\n>>> \n>>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>>> \n>>>> Hi YuLing,\n>>>> \n>>>> My guess is that you pulled the code from the master. So please\n>>>>follow this link\n>>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>>k_f\n>>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>>8Ha\n>>>>vana_Release.29 instead.\n>>>> \n>>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available\n>>>>in devstack yet, and it\'s being worked on. Therefore you have to\n>>>>manually configure it with instructions given in the above link.\n>>>> \n>>>> Thanks,\n>>>> Robert\n>>>> \n>>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>>> \n>>>>> Hi All,\n>>>>> \n>>>>> I\'m new to devstack and would need to configure cisco plugin to\n>>>>>work in devstack environment. I followed the instruction in the\n>>>>>webpage \n>>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>>ork\n>>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>>_.2\n>>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack\n>>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any\n>>>>>idea?\n>>>>> \n>>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is\n>>>>>not one of the plugins supported under\n>>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure\n>>>>>this variable in localrc? If not, what else I need to do in order\n>>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>>> \n>>>>> Thanks,\n>>>>> \n>>>>> YuLing\n>>>>> \n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<96B198D1930C1D489CDF84797AC8170E212DDF@xmb-rcd-x13.cisco.com>',NULL),('<1705659276F6A540A34DBC191957998410164AC0@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-16 13:10:28',0,'2013-05-16 13:10:28',NULL,'[openstack-dev] FW: how to configure cisco plugin in devstack\n environment','Hi Yuling,\n\nCan you try the following localrc and let me know if it works with a new\ndevstack?\n\n\nADMIN_PASSWORD=stack\nMYSQL_PASSWORD=stack\nRABBIT_PASSWORD=stack\nSERVICE_PASSWORD=stack\nSERVICE_TOKEN=tokentoken\n#FLAT_INTERFACE=br100\n#ENABLE_TENANT_VLANS=True\n#OVS_VLAN_RANGES=physnet1:100:200\n#PHYSICAL_NETWORK=physnet1\n#OVS_BRIDGE_MAPPINGS=physnet1:br-int\n\ndisable_service n-net\nenable_service q-svc\nenable_service q-agt\nenable_service q-dhcp\nenable_service q-l3\nenable_service q-meta\nenable_service quantum\n# Optional, to enable tempest configuration as part of devstack\nenable_service tempest\n\n#OFFLINE=False\n#RECLONE=yes\n\nLOGFILE=~/devstack/stack.log\nQ_PLUGIN=cisco\nSCREEN_LOGDIR=~/tmp/screen\n\nIf its not working, send me the stack.log and the\n~/tmp/screen/screen-q-svc.log.\n\nThanks,\nRobert \n\n\n\nOn 5/15/13 9:45 PM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n\n>Hi Yuling -\n>\n>At this point why don\'t you just edit\n>/etc/quantum/plugins/cisco/cisco_plugins.ini\n>and make sure these values are set\n>\n>[CISCO_PLUGINS]\n>nexus_plugin=quantum.plugins.cisco.nexus.cisco_nexus_plugin_v2.NexusPlugin\n>\n>and create a nexus_switch entry using the example given in the file\n># Example:\n># [NEXUS_SWITCH:1.1.1.1]\n># compute1=1/1\n># compute2=1/2\n># ssh_port=22\n># username=admin\n># password=mySecretPassword\n>\n>Thanks,\n>Rich\n>\n>\n>\n>-----Original Message-----\n>From: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\n>Sent: Wednesday, May 15, 2013 9:19 PM\n>To: Rich Curran (rcurran); openstack-dev at lists.openstack.org; Robert Li\n>(baoli)\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Rich,\n>\n>The original problem that I had was if I do not enable Q_PLUGIN=cisco,\n>the core_plugin will always be OVS plugin instead of Cisco plugin.\n>\n>I don\'t have a Cisco device yet, however, I will eventually test on Cisco\n>Nexus switch.  I do want to go as far as possible with Nexus fake driver.\n>So, do you think with Q_PLUGIN=cisco, am  I going to see pretty much the\n>same environment as that of plugging a real device? I thought at least\n>the data base tables would be the same as what I will see with a real\n>switch...\n>\n>So, if I would like to go as far as possible, do I need to follow your\n>instruction to set subplugins, i.e. declare -a\n>Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)?\n>\n>Thanks,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\n>Sent: Tuesday, May 14, 2013 5:42 PM\n>To: C, Yuling; openstack-dev at lists.openstack.org; Robert Li (baoli)\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Yuling -\n>\n>Are you now using either an external nexus switch and/or the Nexus 1000\n>in your topology?\n>If not then I don\'t know why you would enable Q_PLUGIN=cisco in\n>devstack\'s localrc.\n>\n>But if you want to move forward regardless of available Cisco devices\n>then you would have to follow the instructions listed in that web link\n>below or you can add some additional information to the localrc file.\n>Robert has put this info on a Cisco internal webpage so I\'ll cut/paste\n>here. At some point (if he hasn\'t already) we should add this info to the\n>devstack.org documentation.\n>=====================================================\n>Customization in localrc\n>\n>In addition to existing DevStack variables, DevStack with Cisco plugin\n>supports the following bash variables that can be defined in localrc.\n>declare -a Q_CISCO_PLUGIN_SUBPLUGINS\n>\n>Supported values are:\n>    (openvswitch)\n>    (openvswitch nexus)\n>    (n1kv)\n>    (n1kv nexus)\n>\n>Defines the subplugins that will be deployed with this DevStack. For\n>example:\n>\n>declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)\n>------------------------------------------------------\n>declare -A Q_CISCO_PLUGIN_SWITCH_INFO\n>\n>The value has the following format:\n> \n>({<switch_ip>=<username>:<password>:<ssh_port>[:<compute-host-name>:<nexus\n>-port-connected-with>] })\n>\n>Defines the nexus switch information used in the deployment. This is a\n>bash associative array with nexus switch ip addresses as keys.\n>Essentially, it defines the switch\'s access information, and the compute\n>hosts that are connected to the switch. An example looks like\n>             declare -A Q_CISCO_PLUGIN_SWITCH_INFO=\n>([1.1.1.1]=admin:mySecretPassword:22:compute1:1/1:compute2:1/2)\n>\n>If Q_CISCO_PLUGIN_SWITCH_INFO is not defined in localrc, it assumes no\n>switch is used in the deployment. In that case, if the nexus subplugin is\n>deployed (as indicated by the Q_CISCO_PLUGIN_SUBPLUGINS array), a fake\n>switch (with a fake driver) will be deployed.\n>\n>**** - Note - since you\'re not using any cisco devices I wouldn\'t declare\n>this variable and have the fake nexus driver configured.\n>======================================================\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\n>Sent: Tuesday, May 14, 2013 5:52 PM\n>To: Rich Curran (rcurran); openstack-dev at lists.openstack.org\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Rich,\n>\n>I was able to use Robert\'s file of lib/quantum_plugins/cisco to run cisco\n>plugin in devstack environment. However, I\'m not sure if everything was\n>set up correctly in my environment. I thought this configuration using\n>Q_plugin=cisco in localrc would set up exactly the same environment as\n>what the instructions on the following attached link describes. However,\n>I was not able to see the \'quantum_l2network\' database at all. All I saw\n>was database \'cisco_quantum\'.  Is there anything wrong in my set up?\n>Should I see \'quantum_l2network\' at all?\n>\n>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework_for\n>_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28Havana\n>_Release.29\n>\n>Thanks,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: C, Yuling\n>Sent: Tuesday, May 07, 2013 11:40 AM\n>To: \'Rich Curran (rcurran)\'; OpenStack Development Mailing List\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>B.T.W.,  I\'m not planning to use a Nexus switch in my testing environment\n>for now...just would like to use the fake driver to see how it\n>goes...will plugin a real switch later:-)\n>\n>Thanks very much,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran) [mailto:rcurran at cisco.com]\n>Sent: Tuesday, May 07, 2013 11:13 AM\n>To: OpenStack Development Mailing List; C, Yuling\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>HI Yuling -\n>\n>Actually if you change the localrc as described below you won\'t have to\n>install configobj (I don\'t think).\n>So change the localrc first, unstack, stack. I don\'t think at that point\n>you\'ll have the configobj issue.\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Rich Curran (rcurran)\n>Sent: Tuesday, May 07, 2013 2:09 PM\n>To: Yuling_C at DELL.com; openstack-dev at lists.openstack.org\n>Subject: Re: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Hi Yuling -\n>\n>Here are instructions I found on installing configobj:\n>http://www.voidspace.org.uk/python/articles/configobj.shtml\n>\n>Also, you didn\'t get the latest (master) cisco quantum code.\n>In localrc please add/change:\n>OFFLINE=False\n>RECLONE=yes\n>\n>Also, are you using a nexus hardware switch in your topology?\n>\n>Thanks,\n>Rich\n>\n>-----Original Message-----\n>From: Yuling_C at DELL.com [mailto:Yuling_C at DELL.com]\n>Sent: Tuesday, May 07, 2013 1:46 PM\n>To: openstack-dev at lists.openstack.org\n>Cc: Rich Curran (rcurran)\n>Subject: RE: [openstack-dev] FW: how to configure cisco plugin in\n>devstack environment\n>\n>Thanks very much for the information... I just tried commenting out\n>#QUANTUM_BRANCH=stable/grizzly. However, when I ran \'stack.sh\' again, I\n>still hit the same issue.\n>\n>From reading the log, I can see quantum was trying to pick up cisco\n>plugin. However, it failed at importing configobj at\n>cisco_configparser.py. Could this be PYTHONPATH issue? (However, I don\'t\n>see any instructions for changing this environment variable)\n>\n>When you mentioned that\n>>\' this assumes another\n>>change (cisco-single-config blueprint) that was committed to the\n>>openstack master branch but didn\'t make it into stable/grizzly\'.\n>\n>Do I need to pick up this change as well? The only thing I picked up was\n>Robert\'s file of lib/quantum_plugins/cisco...the rest running on my\n>environment was devstack grizzly release...\n>\n>\n>Thanks,\n>\n>YuLing\n>\n>-----Original Message-----\n>From: Robert Li (baoli) [mailto:baoli at cisco.com]\n>Sent: Tuesday, May 07, 2013 6:42 AM\n>To: OpenStack Development Mailing List\n>Cc: Rich Curran (rcurran)\n>Subject: [openstack-dev] FW: how to configure cisco plugin in devstack\n>environment\n>\n>Hi Yuling,\n>\n>See below for the response from Rich.\n>\n>Thanks,\n>Robert\n>\n>On 5/7/13 9:33 AM, \"Rich Curran (rcurran)\" <rcurran at cisco.com> wrote:\n>\n>>\n>>\n>>-----Original Message-----\n>>From: Rich Curran (rcurran)\n>>Sent: Tuesday, May 07, 2013 9:29 AM\n>>To: Kyle Mestery (kmestery); OpenStack Development Mailing List\n>>Subject: RE: [openstack-dev] how to configure cisco plugin in devstack\n>>environment\n>>\n>>Hi Yuling -\n>>\n>>I think there\'s at least one major mismatch going on here.\n>>\n>>If you\'re using Robert\'s devstack change\n>>(https://review.openstack.org/#/c/25378/) then this assumes another\n>>change (cisco-single-config blueprint) that was committed to the\n>>openstack master branch but didn\'t make it into stable/grizzly.\n>>\n>>If you want to continue to use Robert\'s devstack changes then please\n>>comment out this line from your localrc file:\n>>#QUANTUM_BRANCH=stable/grizzly\n>>\n>>./unstack.sh and then ./stack.sh again\n>>\n>>This should pick up the master version of quantum. To check verify that\n>>the only file under:\n>>etc/quantum/plugins/cisco/ is the cisco_plugins.ini file.\n>>\n>>Thanks,\n>>Rich\n>>\n>>-----Original Message-----\n>>From: Kyle Mestery (kmestery)\n>>Sent: Tuesday, May 07, 2013 9:07 AM\n>>To: OpenStack Development Mailing List\n>>Cc: Rich Curran (rcurran)\n>>Subject: Re: [openstack-dev] how to configure cisco plugin in devstack\n>>environment\n>>\n>>Did you do a \"git fetch\"? I think you may want to do that to ensure you\n>>get the entire change set.\n>>\n>>Can you paste the contents of your\n>>/etc/quantum/plugins/cisco/cisco_plugins.ini file?\n>>\n>>On May 7, 2013, at 1:39 AM, Yuling_C at DELL.com wrote:\n>>\n>>> Actually, I just followed the instruction on devstack grizzly\n>>>installation \n>>>link:http://networkstatic.net/installing-openstack-grizzly-with-devsta\n>>> ck/ and installed again. I copied over the \'cisco\' file from the link\n>>>https://review.openstack.org/#/c/25378/ to lib/quantum_plugins/ and\n>>>set Q_plugin = cisco.\n>>>\n>>> However, when I run stack.sh, Quantum server was not able to start\n>>>with the following error in screen-q-svc.log:\n>>>\n>>>    __import__(mod_str)\n>>>  File \"/opt/stack/quantum/quantum/plugins/cisco/network_plugin.py\",\n>>>line 30, in <module>\n>>>    from quantum.plugins.cisco.common import cisco_utils as cutil File\n>>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_utils.py\", line\n>>>23, in <module>\n>>>    from quantum.plugins.cisco.db import l2network_db as cdb  File\n>>>\"/opt/stack/quantum/quantum/plugins/cisco/db/l2network_db.py\", line\n>>>24, in <module>\n>>>    from quantum.plugins.cisco import l2network_plugin_configuration\n>>>as  conf  File \n>>>\"/opt/stack/quantum/quantum/plugins/cisco/l2network_plugin_configuration\n>>>.\n>>>py\", line 21, in <module>\n>>>    from quantum.plugins.cisco.common import cisco_configparser as\n>>>confp  File \n>>>\"/opt/stack/quantum/quantum/plugins/cisco/common/cisco_configparser.py\n>>>\",\n>>>line 19, in <module>\n>>>    from configobj import ConfigObj\n>>> ImportError: No module named configobj\n>>> ERROR: Unable to load quantum from configuration file\n>>>/etc/quantum/api-paste.ini.\n>>>\n>>> Any idea why there\'s an input error for loading \'configobj\'? this\n>>>file should be under /usr/lib/python2.7/dist-packages/landscape/lib.\n>>>Why quantum cannot load this file?\n>>>\n>>> Thanks,\n>>>\n>>> YuLing\n>>>\n>>> ________________________________________\n>>> From: C, Yuling\n>>> Sent: Monday, May 06, 2013 7:58 PM\n>>> To: openstack-dev at lists.openstack.org\n>>> Cc: rcurran at cisco.com\n>>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>>> devstack environment\n>>>\n>>> Thanks Kyle and Robert very much for all these information.\n>>>\n>>> So, it seems that the new devstack version that contains Cisco plugin\n>>>support is already available at https://review.openstack.org/#/c/25378/?\n>>>Should I just use \'git fetch\' to download it and install? Is this\n>>>Havana version(release)?\n>>>\n>>> After I download, can I just use Q_plugin to configure the core plugin?\n>>>Do I still need to follow the manual set up steps on\n>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framework\n>>>_fo\n>>>r_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.28H\n>>>ava\n>>>na_Release.29?\n>>>\n>>> Thanks,\n>>>\n>>> YuLing\n>>>\n>>>\n>>> -----Original Message-----\n>>> From: Kyle Mestery (kmestery) [mailto:kmestery at cisco.com]\n>>> Sent: Monday, May 06, 2013 2:09 PM\n>>> To: OpenStack Development Mailing List\n>>> Cc: Rich Curran (rcurran)\n>>> Subject: Re: [openstack-dev] how to configure cisco plugin in\n>>> devstack environment\n>>>\n>>> I should note Robert\'s review for adding support to devstack for the\n>>>Cisco plugin is here:\n>>>\n>>> https://review.openstack.org/#/c/25378/\n>>>\n>>> I\'ve been running with it for a few weeks and it works great!\n>>>\n>>> Thanks,\n>>> Kyle\n>>>\n>>> On May 6, 2013, at 3:54 PM, Robert Li (baoli) <baoli at cisco.com> wrote:\n>>>\n>>>> Hi YuLing,\n>>>>\n>>>> My guess is that you pulled the code from the master. So please\n>>>>follow this link\n>>>>https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framewor\n>>>>k_f\n>>>>or_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches_.2\n>>>>8Ha\n>>>>vana_Release.29 instead.\n>>>>\n>>>> Currently, configuring Q_PLUGIN to use cisco plugin is not available\n>>>>in devstack yet, and it\'s being worked on. Therefore you have to\n>>>>manually configure it with instructions given in the above link.\n>>>>\n>>>> Thanks,\n>>>> Robert\n>>>>\n>>>> On 5/6/13 1:50 PM, \"Yuling_C at DELL.com\" <Yuling_C at DELL.com> wrote:\n>>>>\n>>>>> Hi All,\n>>>>>\n>>>>> I\'m new to devstack and would need to configure cisco plugin to\n>>>>>work in devstack environment. I followed the instruction in the\n>>>>>webpage \n>>>>>(https://wiki.openstack.org/wiki/Cisco-quantum#A_Cisco_Plugin_Framew\n>>>>>ork\n>>>>>_for_Quantum_L2_Network_Overlays_Spanning_Multiple_Physical_Switches\n>>>>>_.2\n>>>>>8Grizzly_Release.29) to configure cisco plugin. However, devstack\n>>>>>seems to always pick up OVSQuantumPluginV2 as \'core_plugin\'.  Any\n>>>>>idea?\n>>>>>\n>>>>> I tried to set up Q_plugin in localrc. However, it seems cisco is\n>>>>>not one of the plugins supported under\n>>>>>/opt/stack/devstack/lib/quantum_plugins...do I need to configure\n>>>>>this variable in localrc? If not, what else I need to do in order\n>>>>>for openstack to pick up Cisco plugin in devstack environment?\n>>>>>\n>>>>> Thanks,\n>>>>>\n>>>>> YuLing\n>>>>>\n>>>> _______________________________________________\n>>>> OpenStack-dev mailing list\n>>>> OpenStack-dev at lists.openstack.org\n>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>>\n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n>\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n>_______________________________________________\n>OpenStack-dev mailing list\n>OpenStack-dev at lists.openstack.org\n>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<96B198D1930C1D489CDF84797AC8170E213262@xmb-rcd-x13.cisco.com>',NULL),('<1705659276F6A540A34DBC1919579984102793D2@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-25 20:15:56',0,'2013-10-25 20:15:56',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register a summit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131025/69e2dcb0/attachment.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E7773626E18@MTLDAG02.mtl.com>',NULL),('<1705659276F6A540A34DBC19195799841027A7A4@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-28 19:22:08',0,'2013-10-28 19:22:08',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi Irena,\n\nThank you very much for your comments. See inline.\n\n--Robert\n\nOn 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert,\nThank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest  to bind Nova and Neutron?\n\nThe end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.\n\nNormally, one will invoke \"nova boot\" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn\'t allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for \'nova boot\':\n\n      -- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:\n               . PCI alias\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n\n        The above information is optional. In the absence of them, the existing behavior remains.\n\n     -- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose\n\n     -- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.\n\n     -- Nova compute invokes neutron services with PCI passthrough information if any\n\n     --  Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It\'s also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns  nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:\n          binding:vif_type\n          binding:host_id\n          binding:profile\n          binding:capabilities\n\n    -- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.\n\n\n\n\nThe blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.\nOn the Neutron side, there is a need to  support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.\n\nI haven\'t sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.\n\n\nDuring the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.\nWe want to integrate our solution with PCI pass-through Nova support.  I will be glad to share more details if you are interested.\n\n\nGood to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I\'m interested in knowing its details.\n\nThe PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.\n\nI agree. Maybe we can steal some time in that discussion.\n\nWould you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?\n\nSure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.\n\n\n\nRegards,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Friday, October 25, 2013 11:16 PM\nTo: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register asummit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131028/ba1ae583/attachment.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E7780248ABE@MTLDAG01.mtl.com>',NULL),('<1705659276F6A540A34DBC19195799841027C380@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 13:30:36',0,'2013-10-29 13:30:36',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi Yunhong,\n\nI haven\'t looked at Mellanox in much detail. I think that we\'ll get more details from Irena down the road. Regarding your question, I can only answer based on my experience with Cisco\'s VM-FEX. In a nutshell:\n     -- a vNIC is connected to an external switch. Once the host is booted up, all the PFs and VFs provisioned on the vNIC will be created, as well as all the corresponding ethernet interfaces .\n     -- As far as Neutron is concerned, a neutron port can be associated with a VF. One way to do so is to specify this requirement in the ?nic option, providing information such as:\n               . PCI alias (this is the same alias as defined in your nova blueprints)\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n     -- similar to how you translate the nova flavor with PCI requirements to PCI requests for scheduling purpose, Nova API (the nova api component) can translate the above to PCI requests for scheduling purpose. I can give more detail later on this.\n\nRegarding your last question, since the vNIC is already connected with the external switch, the vNIC driver will be responsible for communicating the port profile to the external switch. As you have already known, libvirt provides several ways to specify a VM to be booted up with SRIOV. For example, in the following interface definition:\n\n\n  <interface type=\'hostdev\' managed=\'yes\'>\n      <source>\n        <address type=\'pci\' domain=\'0\' bus=\'0x09\' slot=\'0x0\' function=\'0x01\'/>\n      </source>\n      <mac address=\'01:23:45:67:89:ab\' />\n      <virtualport type=\'802.1Qbh\'>\n        <parameters profileid=\'my-port-profile\' />\n      </virtualport>\n    </interface>\n\n\nThe SRIOV VF (bus 0x09, VF 0x01) will be allocated, and the port profile \'my-port-profile\' will be used to provision this VF. Libvirt will be responsible for invoking the vNIC driver to configure this VF with the port profile my-port-porfile. The driver will talk to the external switch using the 802.1qbh standards to complete the VF\'s configuration and binding with the VM.\n\n\nNow that nova PCI passthrough is responsible for discovering/scheduling/allocating a VF, the rest of the puzzle is to associate this PCI device with the feature that\'s going to use it, and the feature will be responsible for configuring it. You can also see from the above example, in one implementation of SRIOV, the feature (in this case neutron) may not need to do much in terms of working with the external switch, the work is actually done by libvirt behind the scene.\n\n\nNow the questions are:\n\n        -- how the port profile gets defined/managed\n\n        -- how the port profile gets associated with a neutron network\n\nThe first question will be specific to the particular product, and therefore a particular neutron plugin has to mange that.\n\nThere may be several approaches to address the second question. For example, in the simplest case, a port profile can be associated with a neutron network. This has some significant drawbacks. Since the port profile defines features for all the ports that use it, the one port profile to one neutron network mapping would mean all the ports on the network will have exactly the same features (for example, QoS characteristics). To make it flexible, the binding of a port profile to a port may be done at the port creation time.\n\n\nLet me know if the above answered your question.\n\n\nthanks,\n\nRobert\n\nOn 10/29/13 3:03 AM, \"Jiang, Yunhong\" <yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>> wrote:\n\nRobert, is it possible to have a IRC meeting? I?d prefer to IRC meeting because it?s more openstack style and also can keep the minutes clearly.\n\nTo your flow, can you give more detailed example. For example, I can consider user specify the instance with ?nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?\n\nThanks\n--jyh\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, October 28, 2013 12:22 PM\nTo: Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Jiang, Yunhong; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThank you very much for your comments. See inline.\n\n--Robert\n\nOn 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert,\nThank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest  to bind Nova and Neutron?\n\nThe end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.\n\nNormally, one will invoke \"nova boot\" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn\'t allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for \'nova boot\':\n\n      -- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:\n               . PCI alias\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n\n        The above information is optional. In the absence of them, the existing behavior remains.\n\n     -- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose\n\n     -- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.\n\n     -- Nova compute invokes neutron services with PCI passthrough information if any\n\n     --  Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It\'s also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns  nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:\n          binding:vif_type\n          binding:host_id\n          binding:profile\n          binding:capabilities\n\n    -- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.\n\n\n\n\nThe blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.\nOn the Neutron side, there is a need to  support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.\n\nI haven\'t sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.\n\n\nDuring the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.\nWe want to integrate our solution with PCI pass-through Nova support.  I will be glad to share more details if you are interested.\n\n\nGood to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I\'m interested in knowing its details.\n\nThe PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.\n\nI agree. Maybe we can steal some time in that discussion.\n\nWould you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?\n\nSure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.\n\n\n\nRegards,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Friday, October 25, 2013 11:16 PM\nTo: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register asummit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/ebc194e2/attachment.html>\n\n','<DDCAE26804250545B9934A2056554AA01FBA9084@ORSMSX108.amr.corp.intel.com>',NULL),('<1705659276F6A540A34DBC19195799841027C398@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 13:31:34',0,'2013-10-29 13:31:34',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi,\n\nsounds like there are enough interests for an IRC meeting before the summit. Do you guys know how to schedule a #openstack IRC meeting?\n\nthanks,\nRobert\n\nOn 10/29/13 6:17 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Jiang, Robert,\nIRC meeting option works for me.\nIf I understand your question below, you are looking for a way to tie up between requested virtual network(s) and requested PCI device(s). The way we did it in our solution  is to map a provider:physical_network to an interface that represents the Physical Function. Every virtual network is bound to the provider:physical_network, so the PCI device should be allocated based on this mapping.  We can  map a PCI alias to the provider:physical_network.\n\nAnother topic to discuss is where the mapping between neutron port and PCI device should be managed. One way to solve it, is to propagate the allocated PCI device details to neutron on port creation.\nIn case  there is no qbg/qbh support, VF networking configuration should be applied locally on the Host.\nThe question is when and how to apply networking configuration on the PCI device?\nWe see the following options:\n\n?         it can be done on port creation.\n\n?         It can be done when nova VIF driver is called for vNIC plugging. This will require to  have all networking configuration available to the VIF driver or send request to the neutron server to obtain it.\n\n?         It can be done by  having a dedicated L2 neutron agent on each Host that scans for allocated PCI devices  and then retrieves networking configuration from the server and configures the device. The agent will be also responsible for managing update requests coming from the neutron server.\n\n\nFor macvtap vNIC type assignment, the networking configuration can be applied by a dedicated L2 neutron agent.\n\nBR,\nIrena\n\nFrom: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\nSent: Tuesday, October 29, 2013 9:04 AM\n\nTo: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nRobert, is it possible to have a IRC meeting? I?d prefer to IRC meeting because it?s more openstack style and also can keep the minutes clearly.\n\nTo your flow, can you give more detailed example. For example, I can consider user specify the instance with ?nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?\n\nThanks\n--jyh\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, October 28, 2013 12:22 PM\nTo: Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Jiang, Yunhong; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThank you very much for your comments. See inline.\n\n--Robert\n\nOn 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert,\nThank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest  to bind Nova and Neutron?\n\nThe end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.\n\nNormally, one will invoke \"nova boot\" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn\'t allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for \'nova boot\':\n\n      -- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:\n               . PCI alias\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n\n        The above information is optional. In the absence of them, the existing behavior remains.\n\n     -- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose\n\n     -- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.\n\n     -- Nova compute invokes neutron services with PCI passthrough information if any\n\n     --  Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It\'s also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns  nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:\n          binding:vif_type\n          binding:host_id\n          binding:profile\n          binding:capabilities\n\n    -- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.\n\n\n\n\nThe blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.\nOn the Neutron side, there is a need to  support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.\n\nI haven\'t sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.\n\n\nDuring the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.\nWe want to integrate our solution with PCI pass-through Nova support.  I will be glad to share more details if you are interested.\n\n\nGood to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I\'m interested in knowing its details.\n\nThe PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.\n\nI agree. Maybe we can steal some time in that discussion.\n\nWould you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?\n\nSure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.\n\n\n\nRegards,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Friday, October 25, 2013 11:16 PM\nTo: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register asummit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/708617fc/attachment-0001.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E778024CC05@MTLDAG01.mtl.com>',NULL),('<1705659276F6A540A34DBC19195799841027C3BB@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-29 13:35:30',0,'2013-10-29 13:35:30',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi John,\n\nGreat to hear from you on Cinder with pcipassthrough. I thought that it\nwould be coming. I like the idea.\n\nthanks,\nRobert\n\nOn 10/29/13 6:46 AM, \"John Garbutt\" <john at johngarbutt.com> wrote:\n\n>I would love to see a symmetry between Cinder local volumes and\n>Neutron PCI passthrough VIFs.\n>\n>Not entirely sure I have that clear in my head right now, but I just\n>wanted to share the idea:\n>* describe resource external to nova that is attached to VM in the API\n>(block device mapping and/or vif references)\n>* ideally the nova scheduler needs to be aware of the local capacity,\n>and how that relates to the above information (relates to the cross\n>service scheduling issues)\n>* state of the device should be stored by Neutron/Cinder\n>(attached/detached, capacity, IP, etc), but still exposed to the\n>\"scheduler\"\n>* connection params get given to Nova from Neutron/Cinder\n>* nova still has the vif driver or volume driver to make the final\n>connection\n>* the disk should be formatted/expanded, and network info injected in\n>the same way as before (cloud-init, config drive, DHCP, etc)\n>\n>John\n>\n>On 29 October 2013 10:17, Irena Berezovsky <irenab at mellanox.com> wrote:\n>> Hi Jiang, Robert,\n>>\n>> IRC meeting option works for me.\n>>\n>> If I understand your question below, you are looking for a way to tie up\n>> between requested virtual network(s) and requested PCI device(s). The\n>>way we\n>> did it in our solution  is to map a provider:physical_network to an\n>> interface that represents the Physical Function. Every virtual network\n>>is\n>> bound to the provider:physical_network, so the PCI device should be\n>> allocated based on this mapping.  We can  map a PCI alias to the\n>> provider:physical_network.\n>>\n>>\n>>\n>> Another topic to discuss is where the mapping between neutron port and\n>>PCI\n>> device should be managed. One way to solve it, is to propagate the\n>>allocated\n>> PCI device details to neutron on port creation.\n>>\n>> In case  there is no qbg/qbh support, VF networking configuration\n>>should be\n>> applied locally on the Host.\n>>\n>> The question is when and how to apply networking configuration on the\n>>PCI\n>> device?\n>>\n>> We see the following options:\n>>\n>> ?         it can be done on port creation.\n>>\n>> ?         It can be done when nova VIF driver is called for vNIC\n>>plugging.\n>> This will require to  have all networking configuration available to\n>>the VIF\n>> driver or send request to the neutron server to obtain it.\n>>\n>> ?         It can be done by  having a dedicated L2 neutron agent on each\n>> Host that scans for allocated PCI devices  and then retrieves networking\n>> configuration from the server and configures the device. The agent will\n>>be\n>> also responsible for managing update requests coming from the neutron\n>> server.\n>>\n>>\n>>\n>> For macvtap vNIC type assignment, the networking configuration can be\n>> applied by a dedicated L2 neutron agent.\n>>\n>>\n>>\n>> BR,\n>>\n>> Irena\n>>\n>>\n>>\n>> From: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\n>> Sent: Tuesday, October 29, 2013 9:04 AM\n>>\n>>\n>> To: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com;\n>> chris.friesen at windriver.com; He, Yongli; Itzik Brown\n>>\n>>\n>> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle\n>>Mestery\n>> (kmestery); Sandhya Dasu (sadasu)\n>> Subject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network\n>> support\n>>\n>>\n>>\n>> Robert, is it possible to have a IRC meeting? I?d prefer to IRC meeting\n>> because it?s more openstack style and also can keep the minutes clearly.\n>>\n>>\n>>\n>> To your flow, can you give more detailed example. For example, I can\n>> consider user specify the instance with ?nic option specify a network\n>>id,\n>> and then how nova device the requirement to the PCI device? I assume the\n>> network id should define the switches that the device can connect to ,\n>>but\n>> how is that information translated to the PCI property requirement? Will\n>> this translation happen before the nova scheduler make host decision?\n>>\n>>\n>>\n>> Thanks\n>>\n>> --jyh\n>>\n>>\n>>\n>> From: Robert Li (baoli) [mailto:baoli at cisco.com]\n>> Sent: Monday, October 28, 2013 12:22 PM\n>> To: Irena Berezovsky; prashant.upadhyaya at aricent.com; Jiang, Yunhong;\n>> chris.friesen at windriver.com; He, Yongli; Itzik Brown\n>> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle\n>>Mestery\n>> (kmestery); Sandhya Dasu (sadasu)\n>> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network\n>> support\n>>\n>>\n>>\n>> Hi Irena,\n>>\n>>\n>>\n>> Thank you very much for your comments. See inline.\n>>\n>>\n>>\n>> --Robert\n>>\n>>\n>>\n>> On 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com> wrote:\n>>\n>>\n>>\n>> Hi Robert,\n>>\n>> Thank you very much for sharing the information regarding your efforts.\n>>Can\n>> you please share your idea of the end to end flow? How do you suggest\n>>to\n>> bind Nova and Neutron?\n>>\n>>\n>>\n>> The end to end flow is actually encompassed in the blueprints in a\n>>nutshell.\n>> I will reiterate it in below. The binding between Nova and Neutron\n>>occurs\n>> with the neutron v2 API that nova invokes in order to provision the\n>>neutron\n>> services. The vif driver is responsible for plugging in an instance\n>>onto the\n>> networking setup that neutron has created on the host.\n>>\n>>\n>>\n>> Normally, one will invoke \"nova boot\" api with the ?nic options to\n>>specify\n>> the nic with which the instance will be connected to the network. It\n>> currently allows net-id, fixed ip and/or port-id to be specified for the\n>> option. However, it doesn\'t allow one to specify special networking\n>> requirements for the instance. Thanks to the nova pci-passthrough work,\n>>one\n>> can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t\n>> provide means to tie up these PCI devices in the case of ethernet\n>>adpators\n>> with networking services. Therefore the idea is actually simple as\n>>indicated\n>> by the blueprint titles, to provide means to tie up SRIOV devices with\n>> neutron services. A work flow would roughly look like this for \'nova\n>>boot\':\n>>\n>>\n>>\n>>       -- Specifies networking requirements in the ?nic option.\n>>Specifically\n>> for SRIOV, allow the following to be specified in addition to the\n>>existing\n>> required information:\n>>\n>>                . PCI alias\n>>\n>>                . direct pci-passthrough/macvtap\n>>\n>>                . port profileid that is compliant with 802.1Qbh\n>>\n>>\n>>\n>>         The above information is optional. In the absence of them, the\n>> existing behavior remains.\n>>\n>>\n>>\n>>      -- if special networking requirements exist, Nova api creates PCI\n>> requests in the nova instance type for scheduling purpose\n>>\n>>\n>>\n>>      -- Nova scheduler schedules the instance based on the requested\n>>flavor\n>> plus the PCI requests that are created for networking.\n>>\n>>\n>>\n>>      -- Nova compute invokes neutron services with PCI passthrough\n>> information if any\n>>\n>>\n>>\n>>      --  Neutron performs its normal operations based on the request,\n>>such\n>> as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it\n>> should validate the information such as profileid, and stores them in\n>>its\n>> db. It\'s also possible to associate a port profileid with a neutron\n>>network\n>> so that port profileid becomes optional in the ?nic option. Neutron\n>>returns\n>> nova the port information, especially for PCI passthrough related\n>> information in the port binding object. Currently, the port binding\n>>object\n>> contains the following information:\n>>\n>>           binding:vif_type\n>>\n>>           binding:host_id\n>>\n>>           binding:profile\n>>\n>>           binding:capabilities\n>>\n>>\n>>\n>>     -- nova constructs the domain xml and plug in the instance by\n>>calling\n>> the vif driver. The vif driver can build up the interface xml based on\n>>the\n>> port binding information.\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>> The blueprints you registered make sense. On Nova side, there is a need\n>>to\n>> bind between requested virtual network and PCI device/interface to be\n>> allocated as vNIC.\n>>\n>> On the Neutron side, there is a need to  support networking\n>>configuration of\n>> the vNIC. Neutron should be able to identify the PCI device/macvtap\n>> interface in order to apply configuration. I think it makes sense to\n>>provide\n>> neutron integration via dedicated Modular Layer 2 Mechanism Driver to\n>>allow\n>> PCI pass-through vNIC support along with other networking technologies.\n>>\n>>\n>>\n>> I haven\'t sorted through this yet. A neutron port could be associated\n>>with a\n>> PCI device or not, which is a common feature, IMHO. However, a ML2\n>>driver\n>> may be needed specific to a particular SRIOV technology.\n>>\n>>\n>>\n>>\n>>\n>> During the Havana Release, we introduced Mellanox Neutron plugin that\n>> enables networking via SRIOV pass-through devices or macvtap interfaces.\n>>\n>> We want to integrate our solution with PCI pass-through Nova support.  I\n>> will be glad to share more details if you are interested.\n>>\n>>\n>>\n>>\n>>\n>> Good to know that you already have a SRIOV implementation. I found out\n>>some\n>> information online about the mlnx plugin, but need more time to get to\n>>know\n>> it better. And certainly I\'m interested in knowing its details.\n>>\n>>\n>>\n>> The PCI pass-through networking support is planned to be discussed\n>>during\n>> the summit: http://summit.openstack.org/cfp/details/129. I think it?s\n>>worth\n>> to drill down into more detailed proposal and present it during the\n>>summit,\n>> especially since it impacts both nova and neutron projects.\n>>\n>>\n>>\n>> I agree. Maybe we can steal some time in that discussion.\n>>\n>>\n>>\n>> Would you be interested in collaboration on this effort? Would you be\n>> interested to exchange more emails or set an IRC/WebEx meeting during\n>>this\n>> week before the summit?\n>>\n>>\n>>\n>> Sure. If folks want to discuss it before the summit, we can schedule a\n>>webex\n>> later this week. Or otherwise, we can continue the discussion with\n>>email.\n>>\n>>\n>>\n>>\n>>\n>>\n>>\n>> Regards,\n>>\n>> Irena\n>>\n>>\n>>\n>> From: Robert Li (baoli) [mailto:baoli at cisco.com]\n>> Sent: Friday, October 25, 2013 11:16 PM\n>> To: prashant.upadhyaya at aricent.com; Irena Berezovsky;\n>> yunhong.jiang at intel.com; chris.friesen at windriver.com;\n>>yongli.he at intel.com\n>> Cc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle\n>>Mestery\n>> (kmestery); Sandhya Dasu (sadasu)\n>> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network\n>> support\n>>\n>>\n>>\n>> Hi Irena,\n>>\n>>\n>>\n>> This is Robert Li from Cisco Systems. Recently, I was tasked to\n>>investigate\n>> such support for Cisco\'s systems that support VM-FEX, which is a SRIOV\n>> technology supporting 802-1Qbh. I was able to bring up nova instances\n>>with\n>> SRIOV interfaces, and establish networking in between the instances that\n>> employes the SRIOV interfaces. Certainly, this was accomplished with\n>>hacking\n>> and some manual intervention. Based on this experience and my study\n>>with the\n>> two existing nova pci-passthrough blueprints that have been implemented\n>>and\n>> committed into Havana\n>> (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\n>> https://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I\n>> registered a couple of blueprints (one on Nova side, the other on the\n>> Neutron side):\n>>\n>>\n>>\n>> https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\n>>\n>> https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n>>\n>>\n>>\n>> in order to address SRIOV support in openstack.\n>>\n>>\n>>\n>> Please take a look at them and see if they make sense, and let me know\n>>any\n>> comments and questions. We can also discuss this in the summit, I\n>>suppose.\n>>\n>>\n>>\n>> I noticed that there is another thread on this topic, so copy those\n>>folks\n>> from that thread as well.\n>>\n>>\n>>\n>> thanks,\n>>\n>> Robert\n>>\n>>\n>>\n>> On 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com> wrote:\n>>\n>>\n>>\n>> Hi,\n>>\n>> As one of the next steps for PCI pass-through I would like to discuss\n>>is the\n>> support for PCI pass-through vNIC.\n>>\n>> While nova takes care of PCI pass-through device resources  management\n>>and\n>> VIF settings, neutron should manage their networking configuration.\n>>\n>> I would like to register asummit proposal to discuss the support for PCI\n>> pass-through networking.\n>>\n>> I am not sure what would be the right topic to discuss the PCI\n>>pass-through\n>> networking, since it involve both nova and neutron.\n>>\n>> There is already a session registered by Yongli on nova topic to\n>>discuss the\n>> PCI pass-through next steps.\n>>\n>> I think PCI pass-through networking is quite a big topic and it worth to\n>> have a separate discussion.\n>>\n>> Is there any other people who are interested to discuss it and share\n>>their\n>> thoughts and experience?\n>>\n>>\n>>\n>> Regards,\n>>\n>> Irena\n>>\n>>\n>>\n>>\n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>>\n\n\n\n','<CABib2_o6tVKB+pEk6p-OByYd5ZF23JcMLM0yN37pcX6bHOHNAQ@mail.gmail.com>',NULL),('<1705659276F6A540A34DBC19195799841027D7E6@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 17:12:45',0,'2013-10-30 17:12:45',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi,\n\nRegarding physical network mapping,  This is what I thought.\n\nconsider the following scenarios:\n   1. a compute node with SRIOV only interfaces attached to a physical network. the node is connected to one upstream switch\n   2. a compute node with both SRIOV interfaces and non-SRIOV interfaces attached to a physical network. the node is connected to one upstream switch\n   3. in addition to case 1 &2, a compute node may have multiple vNICs that are connected to different upstream switches.\n\nCASE 1:\n -- the mapping from a virtual network (in terms of neutron) to a physical network is actually done by binding a port profile to a neutron port. With cisco\'s VM-FEX, a port profile is associated with one or multiple vlans. Once the neutron port is bound with this port-profile in the upstream switch, it\'s effectively plugged into the physical network.\n -- since the compute node is connected to one upstream switch, the existing nova PCI alias will be sufficient. For example, one can boot a Nova instance that is attached to a SRIOV port with the following command:\n          nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>,pci-alias=<alias>,sriov=<direct|macvtap>,port-profile=<profile>\n    the net-id will be useful in terms of allocating IP address, enable dhcp, etc that is associated with the network.\n-- the pci-alias specified in the nova boot command is used to create a PCI request for scheduling purpose. a PCI device is bound to a neutron port during the instance build time in the case of nova boot. Before invoking the neutron API to create a port, an allocated PCI device out of a PCI alias will be located from the PCI device list object. This device info among other information will be sent to neutron to create the port.\n\nCASE 2:\n-- Assume that OVS is used for the non-SRIOV interfaces. An example of configuration with ovs plugin would look like:\n            bridge_mappings = physnet1:br-vmfex\n            network_vlan_ranges = physnet1:15:17\n            tenant_network_type = vlan\n    When a neutron network is created, a vlan is either allocated or specified in the neutron net-create command. Attaching a physical interface to the bridge (in the above example br-vmfex) is an administrative task.\n-- to create a Nova instance with non-SRIOV port:\n           nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>\n-- to create a Nova instance with SRIOV port:\n           nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>,pci-alias=<alias>,sriov=<direct|macvtap>,port-profile=<profile>\n    it\'s essentially the same as in the first case. But since the net-id is already associated with a vlan, the vlan associated with the port-profile must be identical to that vlan. This has to be enforced by neutron.\n    again, since the node is connected to one upstream switch, the existing nova PCI alias should be sufficient.\n\nCASE 3:\n-- A compute node might be connected to multiple upstream switches, with each being a separate network. This means SRIOV PFs/VFs are already implicitly associated with physical networks. In the none-SRIOV case, a physical interface is associated with a physical network by plugging it into that network, and attaching this interface to the ovs bridge that represents this physical network on the compute node. In the SRIOV case, we need a way to group the SRIOV VFs that belong to the same physical networks. The existing nova PCI alias is to facilitate PCI device allocation by associating <product_id, vendor_id> with an alias name. This will no longer be sufficient. But it can be enhanced to achieve our goal. For example, the PCI device domain, bus (if their mapping to vNIC is fixed across boot) may be added into the alias, and the alias name should be corresponding to a list of tuples.\n\nAnother consideration is that a VF or PF might be used on the host for other purposes. For example, it\'s possible for a neutron DHCP server to be bound with a VF. Therefore, there needs a method to exclude some VFs from a group.  One way is to associate an exclude list with an alias.\n\nThe enhanced PCI alias can be used to support features other than neutron as well. Essentially, a PCI alias can be defined as a group of PCI devices associated with a feature. I\'d think that this should be addressed with a separate blueprint.\n\nThanks,\nRobert\n\nOn 10/30/13 12:59 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nPlease see my answers inline\n\nFrom: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\nSent: Tuesday, October 29, 2013 10:17 PM\nTo: Irena Berezovsky; Robert Li (baoli); prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nYour explanation of the virtual network and physical network is quite clear and should work well. We need change nova code to achieve it, including get the physical network for the virtual network, passing the physical network requirement to the filter properties etc.\n[IrenaB]  The physical network is already available to nova at networking/nova/api at as virtual network attribute, it then passed to the VIF driver. We will push soon the fix to:https://bugs.launchpad.net/nova/+bug/1239606 ; which will provide general support for getting this information.\n\nFor your port method, so you mean we are sure to passing network id to ?nova boot? and nova will create the port during VM boot, am I right?  Also, how can nova knows that it need allocate the PCI device for the port? I?d suppose that in SR-IOV NIC environment, user don?t need specify the PCI requirement. Instead, the PCI requirement should come from the network configuration and image property. Or you think user still need passing flavor with pci request?\n[IrenaB] There are two way to apply port method. One is to pass network id on nova boot and use default type as chosen in the neutron config file for vnic type. Other way is to define port with required vnic type and other properties if applicable, and run ?nova boot? with port id argument. Going forward with nova support for PCI devices awareness, we do need a way impact scheduler choice to land VM on suitable Host with available PC device that has the required connectivity.\n\n--jyh\n\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Tuesday, October 29, 2013 3:17 AM\nTo: Jiang, Yunhong; Robert Li (baoli); prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Jiang, Robert,\nIRC meeting option works for me.\nIf I understand your question below, you are looking for a way to tie up between requested virtual network(s) and requested PCI device(s). The way we did it in our solution  is to map a provider:physical_network to an interface that represents the Physical Function. Every virtual network is bound to the provider:physical_network, so the PCI device should be allocated based on this mapping.  We can  map a PCI alias to the provider:physical_network.\n\nAnother topic to discuss is where the mapping between neutron port and PCI device should be managed. One way to solve it, is to propagate the allocated PCI device details to neutron on port creation.\nIn case  there is no qbg/qbh support, VF networking configuration should be applied locally on the Host.\nThe question is when and how to apply networking configuration on the PCI device?\nWe see the following options:\n\n?         it can be done on port creation.\n\n?         It can be done when nova VIF driver is called for vNIC plugging. This will require to  have all networking configuration available to the VIF driver or send request to the neutron server to obtain it.\n\n?         It can be done by  having a dedicated L2 neutron agent on each Host that scans for allocated PCI devices  and then retrieves networking configuration from the server and configures the device. The agent will be also responsible for managing update requests coming from the neutron server.\n\n\nFor macvtap vNIC type assignment, the networking configuration can be applied by a dedicated L2 neutron agent.\n\nBR,\nIrena\n\nFrom: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\nSent: Tuesday, October 29, 2013 9:04 AM\n\nTo: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nRobert, is it possible to have a IRC meeting? I?d prefer to IRC meeting because it?s more openstack style and also can keep the minutes clearly.\n\nTo your flow, can you give more detailed example. For example, I can consider user specify the instance with ?nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?\n\nThanks\n--jyh\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, October 28, 2013 12:22 PM\nTo: Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Jiang, Yunhong; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThank you very much for your comments. See inline.\n\n--Robert\n\nOn 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert,\nThank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest  to bind Nova and Neutron?\n\nThe end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.\n\nNormally, one will invoke \"nova boot\" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn\'t allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for \'nova boot\':\n\n      -- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:\n               . PCI alias\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n\n        The above information is optional. In the absence of them, the existing behavior remains.\n\n     -- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose\n\n     -- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.\n\n     -- Nova compute invokes neutron services with PCI passthrough information if any\n\n     --  Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It\'s also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns  nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:\n          binding:vif_type\n          binding:host_id\n          binding:profile\n          binding:capabilities\n\n    -- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.\n\n\n\n\nThe blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.\nOn the Neutron side, there is a need to  support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.\n\nI haven\'t sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.\n\n\nDuring the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.\nWe want to integrate our solution with PCI pass-through Nova support.  I will be glad to share more details if you are interested.\n\n\nGood to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I\'m interested in knowing its details.\n\nThe PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.\n\nI agree. Maybe we can steal some time in that discussion.\n\nWould you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?\n\nSure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.\n\n\n\nRegards,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Friday, October 25, 2013 11:16 PM\nTo: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register asummit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/28d53eba/attachment.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E778024DCBF@MTLDAG01.mtl.com>',NULL),('<1705659276F6A540A34DBC19195799841027D8D5@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-30 17:57:32',0,'2013-10-30 17:57:32',NULL,'[openstack-dev] [nova] [neutron] #openstack IRC meeting UTC 1300\n Friday on PCI pass-through network support','Hi,\n\nLet\'s have a meeting with the #openstack IRC channel at UTC 1300 Friday.\n\nBased on our email discussions so far, I listed the topics in below:\n       -- physical network binding\n       -- nova/neutron APIs to support SRIOV\n       -- PCI Alias\n\nthanks,\nRobert\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131030/f2895d8d/attachment.html>\n\n','<1705659276F6A540A34DBC19195799841027D7E6@xmb-rcd-x03.cisco.com>',NULL),('<1705659276F6A540A34DBC19195799841027F471@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 12:47:10',0,'2013-10-31 12:47:10',NULL,'[openstack-dev] [nova] [neutron] PCI pass-through network\n support','Hi Irena,\n\nGreat that you brought up HA cases. If I understand the case you brought up correctly (please clarify otherwise), you mean to say that a guest may have more than one SRIOV port attached to it. This can be achieved in a couple of ways:\n     -- nova boot with multiple ?nic options\n     -- after the instance is booted up, attach additional interface to it by nova interface-attach.\n\nRegarding HW VEB, can you share more details about it? As always, if this is specific to a particular product, it will have to be managed by the neutron plugin (or mechanism driver). The Nova VIF driver does two things mainly:\n       -- plug/unplug interfaces. With pci-passthrough, this is no longer needed since the device is directly attached to the guest\n       -- generate interface xml. This is still needed.\n\nThanks,\nRobert\n\n\n\n\nOn 10/31/13 6:09 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nI would like to add for consideration another scenario that may be considered for HA:\n\nn  A compute node with SRIOV interfaces attached to a physical network via more than one Server port; node is connected to different upstream switches. In non SRIOV environment this can be solved by bonding Hypervisor interfaces and attach the physical network  to bonded interface. It won?t work for SRIOV case, since bond should be managed in the guest.\nFor the case #1,  please see my comments inline.\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Wednesday, October 30, 2013 7:13 PM\nTo: Irena Berezovsky; Jiang, Yunhong; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi,\n\nRegarding physical network mapping,  This is what I thought.\n\nconsider the following scenarios:\n   1. a compute node with SRIOV only interfaces attached to a physical network. the node is connected to one upstream switch\n   2. a compute node with both SRIOV interfaces and non-SRIOV interfaces attached to a physical network. the node is connected to one upstream switch\n   3. in addition to case 1 &2, a compute node may have multiple vNICs that are connected to different upstream switches.\n\nCASE 1:\n -- the mapping from a virtual network (in terms of neutron) to a physical network is actually done by binding a port profile to a neutron port. With cisco\'s VM-FEX, a port profile is associated with one or multiple vlans. Once the neutron port is bound with this port-profile in the upstream switch, it\'s effectively plugged into the physical network.\n -- since the compute node is connected to one upstream switch, the existing nova PCI alias will be sufficient. For example, one can boot a Nova instance that is attached to a SRIOV port with the following command:\n          nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>,pci-alias=<alias>,sriov=<direct|macvtap>,port-profile=<profile>\n    the net-id will be useful in terms of allocating IP address, enable dhcp, etc that is associated with the network.\n-- the pci-alias specified in the nova boot command is used to create a PCI request for scheduling purpose. a PCI device is bound to a neutron port during the instance build time in the case of nova boot. Before invoking the neutron API to create a port, an allocated PCI device out of a PCI alias will be located from the PCI device list object. This device info among other information will be sent to neutron to create the port.\n[IrenaB] for the HW VEB (no port profile associated), since neutron will have the details of the allocated device, the question is when/how the networking configuration will be applied to the VF. The VIF Driver on plug VIF can trigger the VF configuration, but it will mix the nova/neutron separation of concerns and introduce additional dependency between nova and neutron.\n\nCASE 2:\n-- Assume that OVS is used for the non-SRIOV interfaces. An example of configuration with ovs plugin would look like:\n            bridge_mappings = physnet1:br-vmfex\n            network_vlan_ranges = physnet1:15:17\n            tenant_network_type = vlan\n    When a neutron network is created, a vlan is either allocated or specified in the neutron net-create command. Attaching a physical interface to the bridge (in the above example br-vmfex) is an administrative task.\n-- to create a Nova instance with non-SRIOV port:\n           nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>\n-- to create a Nova instance with SRIOV port:\n           nova boot ?flavor m1.large ?image <image-id> --nic net-id=<net>,pci-alias=<alias>,sriov=<direct|macvtap>,port-profile=<profile>\n    it\'s essentially the same as in the first case. But since the net-id is already associated with a vlan, the vlan associated with the port-profile must be identical to that vlan. This has to be enforced by neutron.\n    again, since the node is connected to one upstream switch, the existing nova PCI alias should be sufficient.\n\nCASE 3:\n-- A compute node might be connected to multiple upstream switches, with each being a separate network. This means SRIOV PFs/VFs are already implicitly associated with physical networks. In the none-SRIOV case, a physical interface is associated with a physical network by plugging it into that network, and attaching this interface to the ovs bridge that represents this physical network on the compute node. In the SRIOV case, we need a way to group the SRIOV VFs that belong to the same physical networks. The existing nova PCI alias is to facilitate PCI device allocation by associating <product_id, vendor_id> with an alias name. This will no longer be sufficient. But it can be enhanced to achieve our goal. For example, the PCI device domain, bus (if their mapping to vNIC is fixed across boot) may be added into the alias, and the alias name should be corresponding to a list of tuples.\n\nAnother consideration is that a VF or PF might be used on the host for other purposes. For example, it\'s possible for a neutron DHCP server to be bound with a VF. Therefore, there needs a method to exclude some VFs from a group.  One way is to associate an exclude list with an alias.\n\nThe enhanced PCI alias can be used to support features other than neutron as well. Essentially, a PCI alias can be defined as a group of PCI devices associated with a feature. I\'d think that this should be addressed with a separate blueprint.\n\nThanks,\nRobert\n\nOn 10/30/13 12:59 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nPlease see my answers inline\n\nFrom: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\nSent: Tuesday, October 29, 2013 10:17 PM\nTo: Irena Berezovsky; Robert Li (baoli); prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nYour explanation of the virtual network and physical network is quite clear and should work well. We need change nova code to achieve it, including get the physical network for the virtual network, passing the physical network requirement to the filter properties etc.\n[IrenaB]  The physical network is already available to nova at networking/nova/api at as virtual network attribute, it then passed to the VIF driver. We will push soon the fix to:https://bugs.launchpad.net/nova/+bug/1239606 ; which will provide general support for getting this information.\n\nFor your port method, so you mean we are sure to passing network id to ?nova boot? and nova will create the port during VM boot, am I right?  Also, how can nova knows that it need allocate the PCI device for the port? I?d suppose that in SR-IOV NIC environment, user don?t need specify the PCI requirement. Instead, the PCI requirement should come from the network configuration and image property. Or you think user still need passing flavor with pci request?\n[IrenaB] There are two way to apply port method. One is to pass network id on nova boot and use default type as chosen in the neutron config file for vnic type. Other way is to define port with required vnic type and other properties if applicable, and run ?nova boot? with port id argument. Going forward with nova support for PCI devices awareness, we do need a way impact scheduler choice to land VM on suitable Host with available PC device that has the required connectivity.\n\n--jyh\n\n\nFrom: Irena Berezovsky [mailto:irenab at mellanox.com]\nSent: Tuesday, October 29, 2013 3:17 AM\nTo: Jiang, Yunhong; Robert Li (baoli); prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Jiang, Robert,\nIRC meeting option works for me.\nIf I understand your question below, you are looking for a way to tie up between requested virtual network(s) and requested PCI device(s). The way we did it in our solution  is to map a provider:physical_network to an interface that represents the Physical Function. Every virtual network is bound to the provider:physical_network, so the PCI device should be allocated based on this mapping.  We can  map a PCI alias to the provider:physical_network.\n\nAnother topic to discuss is where the mapping between neutron port and PCI device should be managed. One way to solve it, is to propagate the allocated PCI device details to neutron on port creation.\nIn case  there is no qbg/qbh support, VF networking configuration should be applied locally on the Host.\nThe question is when and how to apply networking configuration on the PCI device?\nWe see the following options:\n\n?         it can be done on port creation.\n\n?         It can be done when nova VIF driver is called for vNIC plugging. This will require to  have all networking configuration available to the VIF driver or send request to the neutron server to obtain it.\n\n?         It can be done by  having a dedicated L2 neutron agent on each Host that scans for allocated PCI devices  and then retrieves networking configuration from the server and configures the device. The agent will be also responsible for managing update requests coming from the neutron server.\n\n\nFor macvtap vNIC type assignment, the networking configuration can be applied by a dedicated L2 neutron agent.\n\nBR,\nIrena\n\nFrom: Jiang, Yunhong [mailto:yunhong.jiang at intel.com]\nSent: Tuesday, October 29, 2013 9:04 AM\n\nTo: Robert Li (baoli); Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: RE: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nRobert, is it possible to have a IRC meeting? I?d prefer to IRC meeting because it?s more openstack style and also can keep the minutes clearly.\n\nTo your flow, can you give more detailed example. For example, I can consider user specify the instance with ?nic option specify a network id, and then how nova device the requirement to the PCI device? I assume the network id should define the switches that the device can connect to , but how is that information translated to the PCI property requirement? Will this translation happen before the nova scheduler make host decision?\n\nThanks\n--jyh\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Monday, October 28, 2013 12:22 PM\nTo: Irena Berezovsky; prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Jiang, Yunhong; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; He, Yongli; Itzik Brown\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThank you very much for your comments. See inline.\n\n--Robert\n\nOn 10/27/13 3:48 AM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi Robert,\nThank you very much for sharing the information regarding your efforts. Can you please share your idea of the end to end flow? How do you suggest  to bind Nova and Neutron?\n\nThe end to end flow is actually encompassed in the blueprints in a nutshell. I will reiterate it in below. The binding between Nova and Neutron occurs with the neutron v2 API that nova invokes in order to provision the neutron services. The vif driver is responsible for plugging in an instance onto the networking setup that neutron has created on the host.\n\nNormally, one will invoke \"nova boot\" api with the ?nic options to specify the nic with which the instance will be connected to the network. It currently allows net-id, fixed ip and/or port-id to be specified for the option. However, it doesn\'t allow one to specify special networking requirements for the instance. Thanks to the nova pci-passthrough work, one can specify PCI passthrough device(s) in the nova flavor. But it doesn\'t provide means to tie up these PCI devices in the case of ethernet adpators with networking services. Therefore the idea is actually simple as indicated by the blueprint titles, to provide means to tie up SRIOV devices with neutron services. A work flow would roughly look like this for \'nova boot\':\n\n      -- Specifies networking requirements in the ?nic option. Specifically for SRIOV, allow the following to be specified in addition to the existing required information:\n               . PCI alias\n               . direct pci-passthrough/macvtap\n               . port profileid that is compliant with 802.1Qbh\n\n        The above information is optional. In the absence of them, the existing behavior remains.\n\n     -- if special networking requirements exist, Nova api creates PCI requests in the nova instance type for scheduling purpose\n\n     -- Nova scheduler schedules the instance based on the requested flavor plus the PCI requests that are created for networking.\n\n     -- Nova compute invokes neutron services with PCI passthrough information if any\n\n     --  Neutron performs its normal operations based on the request, such as allocating a port, assigning ip addresses, etc. Specific to SRIOV, it should validate the information such as profileid, and stores them in its db. It\'s also possible to associate a port profileid with a neutron network so that port profileid becomes optional in the ?nic option. Neutron returns  nova the port information, especially for PCI passthrough related information in the port binding object. Currently, the port binding object contains the following information:\n          binding:vif_type\n          binding:host_id\n          binding:profile\n          binding:capabilities\n\n    -- nova constructs the domain xml and plug in the instance by calling the vif driver. The vif driver can build up the interface xml based on the port binding information.\n\n\n\n\nThe blueprints you registered make sense. On Nova side, there is a need to bind between requested virtual network and PCI device/interface to be allocated as vNIC.\nOn the Neutron side, there is a need to  support networking configuration of the vNIC. Neutron should be able to identify the PCI device/macvtap interface in order to apply configuration. I think it makes sense to provide neutron integration via dedicated Modular Layer 2 Mechanism Driver to allow PCI pass-through vNIC support along with other networking technologies.\n\nI haven\'t sorted through this yet. A neutron port could be associated with a PCI device or not, which is a common feature, IMHO. However, a ML2 driver may be needed specific to a particular SRIOV technology.\n\n\nDuring the Havana Release, we introduced Mellanox Neutron plugin that enables networking via SRIOV pass-through devices or macvtap interfaces.\nWe want to integrate our solution with PCI pass-through Nova support.  I will be glad to share more details if you are interested.\n\n\nGood to know that you already have a SRIOV implementation. I found out some information online about the mlnx plugin, but need more time to get to know it better. And certainly I\'m interested in knowing its details.\n\nThe PCI pass-through networking support is planned to be discussed during the summit: http://summit.openstack.org/cfp/details/129. I think it?s worth to drill down into more detailed proposal and present it during the summit, especially since it impacts both nova and neutron projects.\n\nI agree. Maybe we can steal some time in that discussion.\n\nWould you be interested in collaboration on this effort? Would you be interested to exchange more emails or set an IRC/WebEx meeting during this week before the summit?\n\nSure. If folks want to discuss it before the summit, we can schedule a webex later this week. Or otherwise, we can continue the discussion with email.\n\n\n\nRegards,\nIrena\n\nFrom: Robert Li (baoli) [mailto:baoli at cisco.com]\nSent: Friday, October 25, 2013 11:16 PM\nTo: prashant.upadhyaya at aricent.com<mailto:prashant.upadhyaya at aricent.com>; Irena Berezovsky; yunhong.jiang at intel.com<mailto:yunhong.jiang at intel.com>; chris.friesen at windriver.com<mailto:chris.friesen at windriver.com>; yongli.he at intel.com<mailto:yongli.he at intel.com>\nCc: OpenStack Development Mailing List; Brian Bowen (brbowen); Kyle Mestery (kmestery); Sandhya Dasu (sadasu)\nSubject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support\n\nHi Irena,\n\nThis is Robert Li from Cisco Systems. Recently, I was tasked to investigate such support for Cisco\'s systems that support VM-FEX, which is a SRIOV technology supporting 802-1Qbh. I was able to bring up nova instances with SRIOV interfaces, and establish networking in between the instances that employes the SRIOV interfaces. Certainly, this was accomplished with hacking and some manual intervention. Based on this experience and my study with the two existing nova pci-passthrough blueprints that have been implemented and committed into Havana (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-base and\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-libvirt),  I registered a couple of blueprints (one on Nova side, the other on the Neutron side):\n\nhttps://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov\nhttps://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov\n\nin order to address SRIOV support in openstack.\n\nPlease take a look at them and see if they make sense, and let me know any comments and questions. We can also discuss this in the summit, I suppose.\n\nI noticed that there is another thread on this topic, so copy those folks  from that thread as well.\n\nthanks,\nRobert\n\nOn 10/16/13 4:32 PM, \"Irena Berezovsky\" <irenab at mellanox.com<mailto:irenab at mellanox.com>> wrote:\n\nHi,\nAs one of the next steps for PCI pass-through I would like to discuss is the support for PCI pass-through vNIC.\nWhile nova takes care of PCI pass-through device resources  management and VIF settings, neutron should manage their networking configuration.\nI would like to register asummit proposal to discuss the support for PCI pass-through networking.\nI am not sure what would be the right topic to discuss the PCI pass-through networking, since it involve both nova and neutron.\nThere is already a session registered by Yongli on nova topic to discuss the PCI pass-through next steps.\nI think PCI pass-through networking is quite a big topic and it worth to have a separate discussion.\nIs there any other people who are interested to discuss it and share their thoughts and experience?\n\nRegards,\nIrena\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131031/6c47e311/attachment.html>\n\n','<9D25E123B44F4A4291F4B5C13DA94E778024EF14@MTLDAG01.mtl.com>',NULL),('<1705659276F6A540A34DBC191957998410280512@xmb-rcd-x03.cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 12:45:02',0,'2013-11-01 12:45:02',NULL,'[openstack-dev] [nova] [neutron] #openstack IRC meeting UTC\n 1300 Friday on PCI pass-through network support','Just to clarify that the channel is #openstack-meeting\n\nthanks,\nRobert\n\nOn 10/30/13 1:57 PM, \"Robert Li (baoli)\" <baoli at cisco.com<mailto:baoli at cisco.com>> wrote:\n\nHi,\n\nLet\'s have a meeting with the #openstack IRC channel at UTC 1300 Friday.\n\nBased on our email discussions so far, I listed the topics in below:\n       -- physical network binding\n       -- nova/neutron APIs to support SRIOV\n       -- PCI Alias\n\nthanks,\nRobert\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131101/d56cc803/attachment.html>\n\n','<1705659276F6A540A34DBC19195799841027D8D5@xmb-rcd-x03.cisco.com>',NULL),('<1706495146.16.1385534768596.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-27 06:46:08',0,'2013-11-27 06:46:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-neutron-python26-stable-grizzly #62','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-stable-grizzly/62/>\n\n\n\n',NULL,NULL),('<170656122.245.1354752169382.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-06 00:02:49',0,'2012-12-06 00:02:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-cinder #59','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder/59/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-rackspace-27468 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder/ws/>\nTriggering projects: devstack-update-inprogress\n[periodic-tempest-devstack-vm-cinder] $ /bin/bash -xe /tmp/hudson4505891288101803815.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-ci/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-cinder] $ /bin/bash -xe /tmp/hudson7579051413895355519.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_CINDER=1\n+ DEVSTACK_GATE_CINDER=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nTriggered by: https://review.openstack.org/ patchset \nPipeline: \n/opt/stack/new/devstack-gate/devstack-vm-gate.sh: line 24: cd: /devstack: No such file or directory\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder/59/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1706807.VTUkA3AHZD@localhost.localdomain>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-09 15:06:04',0,'2014-01-09 15:06:04',NULL,'[Openstack] No valid host was found','I am running OpenStack Havana on CentOS 6.5 using 1 controller node and 6 \ncompute nodes.\n\nThey are set up with shared storage for Glance, Nova & Cinder as well as shared Nova \nNetworking (no Neutron in our environment).\n\nWhen trying to boot an instance it goes into Building status for a few seconds before \ngoing into Error status. \n\nTailing the nova scheduler log shows this error each time:\n\n2014-01-09 14:40:06.304 2239 WARNING nova.scheduler.utils \n[req-3f21465f-7ec6-4ea0-9a08-c3a7dcd3faff 5fc621f9f24941febb883f78d2d350ec \nc22af115b6a84dc78b1ae19385c6cd23] Failed to scheduler_run_instance: No valid \nhost was found. Exceeded max scheduling attempts 3 for instance \nd1ff048b-6ddd-4589-b188-7606a047df23\n2014-01-09 14:40:06.305 2239 WARNING nova.scheduler.utils \n[req-3f21465f-7ec6-4ea0-9a08-c3a7dcd3faff 5fc621f9f24941febb883f78d2d350ec \nc22af115b6a84dc78b1ae19385c6cd23] [instance: d1ff048b-6ddd-4589-\nb188-7606a047df23] Setting instance to ERROR state.\n\nAs I understand the \"No valid host\" error indicates that the scheduler could not find a \ncompute host with the resources required in order to schedule the instance on any of \nthe available hosts. However none of the hosts are running anything currently and \nhave decent specs. Also it\'s only a tiny instance so doesn\'t require much anyway.\n\nI tried setting \'*scheduler_default_filters=AllHostsFilter\'* in \'*/etc/nova/nova.conf\'*\0 as \nhow I read it in the Developers docs and on various forums this should mean that the \nscheduler does not checks for resources and just schedules the build on a connected \nhost. However even with this option set the \'*nova boot\' *still goes into Error status \nand gives the error shown in the above log snippet.\n\nI have tried multiple images in case the image is at fault but none will launch (even the \none we have in use in another OpenStack environment) so don\'t believe that it is that. \nI also updated all our boxes yesterday to the latest package versions and this hasn\'t \nchanged anything.\n\nAny ideas why this error might still be occurring or any advise on how we could debug \nthe situation further?\n\nRegards,\n-- \nDanny Roberts\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140109/cc611abe/attachment.html>\n\n',NULL,NULL),('<1707056880.26750496.1394720811527.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-13 10:26:51',-14400,'2014-03-13 14:26:51',NULL,'[openstack-dev] [OpenStack-Infra] Intermittent failures\n	cloning	noVNC from github.com/kanaka','@bnemec: I don\'t think that\'s been considered.  I\'m actually one of the upstream maintainers for noVNC.  The only concern that I\'d have with OpenStack adopting noVNC (there are other maintainers, as well as the author, so I\'d have to check with them as well) is that there are a few other projects that use noVNC, so we\'d need to make sure that no OpenStack-specific code gets merged into noVNC if we adopt it.  Other that that, though, adopting noVNC doesn\'t sound like a horrible idea.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Ben Nemec\" <openstack at nemebean.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nCc: openstack-infra at lists.openstack.org\nSent: Wednesday, March 12, 2014 3:38:19 PM\nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning	noVNC from github.com/kanaka\n\n\n\nOn 2014-03-11 20:34, Joshua Harlow wrote: \n\n\nhttps://status.github.com/messages \n* \'GitHub.com is operating normally, despite an ongoing DDoS attack. The mitigations we have in place are proving effective in protecting us and we\'re hopeful that we\'ve got this one resolved.\' \nIf you were cloning from github.org and not http://git.openstack.org then you were likely seeing some of the DDoS attack in action. \nUnfortunately I don\'t think novnc is in git.openstack.org because it\'s not an OpenStack project. I wonder if we should investigate adopting it (if the author(s) are amenable to that) since we\'re using the git version of it. Maybe that\'s already been considered and I just don\'t know about it. :-) \n-Ben \n\n\n\nFrom: Sukhdev Kapur < sukhdevkapur at gmail.com > \nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org > \nDate: Tuesday, March 11, 2014 at 4:08 PM \nTo: \"Dane Leblanc (leblancd)\" < leblancd at cisco.com > \nCc: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >, \" openstack-infra at lists.openstack.org \" < openstack-infra at lists.openstack.org > \nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka \n\n\n\nI have noticed that even clone of devstack has failed few times within last couple of hours - it was running fairly smooth so far. \n-Sukhdev \n\n\nOn Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur < sukhdevkapur at gmail.com > wrote: \n\n\n\n[adding openstack-dev list as well ] \nI have noticed that this has stated hitting my builds within last few hours. I have noticed exact same failures on almost 10 builds. \nLooks like something has happened within last few hours - perhaps the load? \n-Sukhdev \n\n\nOn Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) < leblancd at cisco.com > wrote: \n\n\n\n\n\nApologies if this is the wrong audience for this question... \n\n\n\nI\'m seeing intermittent failures running stack.sh whereby \'git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\' is returning various errors. Below are 2 examples. \n\n\n\nIs this a known issue? Are there any localrc settings which might help here? \n\n\n\nExample 1: \n\n\n\n2014-03-11 15:00:33.779 | + is_service_enabled n-novnc \n\n2014-03-11 15:00:33.780 | + return 0 \n\n2014-03-11 15:00:33.781 | ++ trueorfalse False \n\n2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False \n\n2014-03-11 15:00:33.783 | + \'[\' False = True \']\' \n\n2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC \n\n2014-03-11 15:00:33.785 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master \n\n2014-03-11 15:00:33.786 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git \n\n2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC \n\n2014-03-11 15:00:33.789 | + GIT_REF=master \n\n2014-03-11 15:00:33.790 | ++ trueorfalse False False \n\n2014-03-11 15:00:33.791 | + RECLONE=False \n\n2014-03-11 15:00:33.792 | + [[ False = \\T\\r\\u\\e ]] \n\n2014-03-11 15:00:33.793 | + echo master \n\n2014-03-11 15:00:33.794 | + egrep -q \'^refs\' \n\n2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]] \n\n2014-03-11 15:00:33.796 | + [[ False = \\T\\r\\u\\e ]] \n\n2014-03-11 15:00:33.797 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n\n2014-03-11 15:00:33.798 | + local count=0 \n\n2014-03-11 15:00:33.799 | + local timeout=0 \n\n2014-03-11 15:00:33.801 | + [[ -n 0 ]] \n\n2014-03-11 15:00:33.802 | + timeout=0 \n\n2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n\n2014-03-11 15:00:33.804 | Cloning into \'/opt/stack/noVNC\'... \n\n2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200 \n\n2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly \n\n2014-03-11 15:03:13.697 | fatal: early EOF \n\n2014-03-11 15:03:13.698 | fatal: index-pack failed \n\n2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]] \n\n2014-03-11 15:03:13.700 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\' \n\n2014-03-11 15:03:13.701 | + local exitcode=0 \n\n2014-03-11 15:03:13.702 | [Call Trace] \n\n2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova \n\n2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone \n\n2014-03-11 15:03:13.706 | /var/lib/jenkins/devstack/functions-common:543:git_timed \n\n2014-03-11 15:03:13.707 | /var/lib/jenkins/devstack/functions-common:596:die \n\n2014-03-11 15:03:13.708 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC] \n\n\n\n\n\nExample 2: \n\n\n2014-03-11 14:12:58.472 | + is_service_enabled n-novnc \n2014-03-11 14:12:58.473 | + return 0 \n2014-03-11 14:12:58.474 | ++ trueorfalse False \n2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False \n2014-03-11 14:12:58.476 | + \'[\' False = True \']\' \n2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC \n2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master \n2014-03-11 14:12:58.479 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git \n2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC \n2014-03-11 14:12:58.481 | + GIT_REF=master \n2014-03-11 14:12:58.482 | ++ trueorfalse False False \n2014-03-11 14:12:58.483 | + RECLONE=False \n2014-03-11 14:12:58.484 | + [[ False = \\T\\r\\u\\e ]] \n2014-03-11 14:12:58.485 | + echo master \n2014-03-11 14:12:58.486 | + egrep -q \'^refs\' \n2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]] \n2014-03-11 14:12:58.488 | + [[ False = \\T\\r\\u\\e ]] \n2014-03-11 14:12:58.489 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n2014-03-11 14:12:58.490 | + local count=0 \n2014-03-11 14:12:58.491 | + local timeout=0 \n2014-03-11 14:12:58.492 | + [[ -n 0 ]] \n2014-03-11 14:12:58.493 | + timeout=0 \n2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n2014-03-11 14:12:58.495 | Cloning into \'/opt/stack/noVNC\'... \n2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while accessing https://github.com/kanaka/noVNC.git/info/refs \n2014-03-11 14:14:02.316 | fatal: HTTP request failed \n2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]] \n2014-03-11 14:14:02.318 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\' \n2014-03-11 14:14:02.319 | + local exitcode=0 \n2014-03-11 14:14:02.321 | [Call Trace] \n2014-03-11 14:14:02.322 | ./stack.sh:736:install_nova \n2014-03-11 14:14:02.323 | /var/lib/jenkins/devstack/lib/nova:618:git_clone \n2014-03-11 14:14:02.324 | /var/lib/jenkins/devstack/functions-common:543:git_timed \n2014-03-11 14:14:02.326 | /var/lib/jenkins/devstack/functions-common:596:die \n2014-03-11 14:14:02.327 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC] \n\n\n\n\nThanks, \n\nDane \n\n\n_______________________________________________ \nOpenStack-Infra mailing list \nOpenStack-Infra at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra \n\n\n_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<f67c8851bf52095b57f03061558cf081@localhost>',NULL),('<1707056880.26750496.1394720811527.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-03-13 10:26:51',-14400,'2014-03-13 14:26:51',NULL,'[OpenStack-Infra] [openstack-dev] Intermittent failures\n	cloning	noVNC from github.com/kanaka','@bnemec: I don\'t think that\'s been considered.  I\'m actually one of the upstream maintainers for noVNC.  The only concern that I\'d have with OpenStack adopting noVNC (there are other maintainers, as well as the author, so I\'d have to check with them as well) is that there are a few other projects that use noVNC, so we\'d need to make sure that no OpenStack-specific code gets merged into noVNC if we adopt it.  Other that that, though, adopting noVNC doesn\'t sound like a horrible idea.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Ben Nemec\" <openstack at nemebean.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nCc: openstack-infra at lists.openstack.org\nSent: Wednesday, March 12, 2014 3:38:19 PM\nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning	noVNC from github.com/kanaka\n\n\n\nOn 2014-03-11 20:34, Joshua Harlow wrote: \n\n\nhttps://status.github.com/messages \n* \'GitHub.com is operating normally, despite an ongoing DDoS attack. The mitigations we have in place are proving effective in protecting us and we\'re hopeful that we\'ve got this one resolved.\' \nIf you were cloning from github.org and not http://git.openstack.org then you were likely seeing some of the DDoS attack in action. \nUnfortunately I don\'t think novnc is in git.openstack.org because it\'s not an OpenStack project. I wonder if we should investigate adopting it (if the author(s) are amenable to that) since we\'re using the git version of it. Maybe that\'s already been considered and I just don\'t know about it. :-) \n-Ben \n\n\n\nFrom: Sukhdev Kapur < sukhdevkapur at gmail.com > \nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org > \nDate: Tuesday, March 11, 2014 at 4:08 PM \nTo: \"Dane Leblanc (leblancd)\" < leblancd at cisco.com > \nCc: \"OpenStack Development Mailing List (not for usage questions)\" < openstack-dev at lists.openstack.org >, \" openstack-infra at lists.openstack.org \" < openstack-infra at lists.openstack.org > \nSubject: Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka \n\n\n\nI have noticed that even clone of devstack has failed few times within last couple of hours - it was running fairly smooth so far. \n-Sukhdev \n\n\nOn Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur < sukhdevkapur at gmail.com > wrote: \n\n\n\n[adding openstack-dev list as well ] \nI have noticed that this has stated hitting my builds within last few hours. I have noticed exact same failures on almost 10 builds. \nLooks like something has happened within last few hours - perhaps the load? \n-Sukhdev \n\n\nOn Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) < leblancd at cisco.com > wrote: \n\n\n\n\n\nApologies if this is the wrong audience for this question... \n\n\n\nI\'m seeing intermittent failures running stack.sh whereby \'git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC\' is returning various errors. Below are 2 examples. \n\n\n\nIs this a known issue? Are there any localrc settings which might help here? \n\n\n\nExample 1: \n\n\n\n2014-03-11 15:00:33.779 | + is_service_enabled n-novnc \n\n2014-03-11 15:00:33.780 | + return 0 \n\n2014-03-11 15:00:33.781 | ++ trueorfalse False \n\n2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False \n\n2014-03-11 15:00:33.783 | + \'[\' False = True \']\' \n\n2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC \n\n2014-03-11 15:00:33.785 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master \n\n2014-03-11 15:00:33.786 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git \n\n2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC \n\n2014-03-11 15:00:33.789 | + GIT_REF=master \n\n2014-03-11 15:00:33.790 | ++ trueorfalse False False \n\n2014-03-11 15:00:33.791 | + RECLONE=False \n\n2014-03-11 15:00:33.792 | + [[ False = \\T\\r\\u\\e ]] \n\n2014-03-11 15:00:33.793 | + echo master \n\n2014-03-11 15:00:33.794 | + egrep -q \'^refs\' \n\n2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]] \n\n2014-03-11 15:00:33.796 | + [[ False = \\T\\r\\u\\e ]] \n\n2014-03-11 15:00:33.797 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n\n2014-03-11 15:00:33.798 | + local count=0 \n\n2014-03-11 15:00:33.799 | + local timeout=0 \n\n2014-03-11 15:00:33.801 | + [[ -n 0 ]] \n\n2014-03-11 15:00:33.802 | + timeout=0 \n\n2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n\n2014-03-11 15:00:33.804 | Cloning into \'/opt/stack/noVNC\'... \n\n2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200 \n\n2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly \n\n2014-03-11 15:03:13.697 | fatal: early EOF \n\n2014-03-11 15:03:13.698 | fatal: index-pack failed \n\n2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]] \n\n2014-03-11 15:03:13.700 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\' \n\n2014-03-11 15:03:13.701 | + local exitcode=0 \n\n2014-03-11 15:03:13.702 | [Call Trace] \n\n2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova \n\n2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone \n\n2014-03-11 15:03:13.706 | /var/lib/jenkins/devstack/functions-common:543:git_timed \n\n2014-03-11 15:03:13.707 | /var/lib/jenkins/devstack/functions-common:596:die \n\n2014-03-11 15:03:13.708 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC] \n\n\n\n\n\nExample 2: \n\n\n2014-03-11 14:12:58.472 | + is_service_enabled n-novnc \n2014-03-11 14:12:58.473 | + return 0 \n2014-03-11 14:12:58.474 | ++ trueorfalse False \n2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False \n2014-03-11 14:12:58.476 | + \'[\' False = True \']\' \n2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC \n2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC master \n2014-03-11 14:12:58.479 | + GIT_REMOTE= https://github.com/kanaka/noVNC.git \n2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC \n2014-03-11 14:12:58.481 | + GIT_REF=master \n2014-03-11 14:12:58.482 | ++ trueorfalse False False \n2014-03-11 14:12:58.483 | + RECLONE=False \n2014-03-11 14:12:58.484 | + [[ False = \\T\\r\\u\\e ]] \n2014-03-11 14:12:58.485 | + echo master \n2014-03-11 14:12:58.486 | + egrep -q \'^refs\' \n2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]] \n2014-03-11 14:12:58.488 | + [[ False = \\T\\r\\u\\e ]] \n2014-03-11 14:12:58.489 | + git_timed clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n2014-03-11 14:12:58.490 | + local count=0 \n2014-03-11 14:12:58.491 | + local timeout=0 \n2014-03-11 14:12:58.492 | + [[ -n 0 ]] \n2014-03-11 14:12:58.493 | + timeout=0 \n2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC \n2014-03-11 14:12:58.495 | Cloning into \'/opt/stack/noVNC\'... \n2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while accessing https://github.com/kanaka/noVNC.git/info/refs \n2014-03-11 14:14:02.316 | fatal: HTTP request failed \n2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]] \n2014-03-11 14:14:02.318 | + die 596 \'git call failed: [git clone\' https://github.com/kanaka/noVNC.git \'/opt/stack/noVNC]\' \n2014-03-11 14:14:02.319 | + local exitcode=0 \n2014-03-11 14:14:02.321 | [Call Trace] \n2014-03-11 14:14:02.322 | ./stack.sh:736:install_nova \n2014-03-11 14:14:02.323 | /var/lib/jenkins/devstack/lib/nova:618:git_clone \n2014-03-11 14:14:02.324 | /var/lib/jenkins/devstack/functions-common:543:git_timed \n2014-03-11 14:14:02.326 | /var/lib/jenkins/devstack/functions-common:596:die \n2014-03-11 14:14:02.327 | [ERROR] /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone https://github.com/kanaka/noVNC.git /opt/stack/noVNC] \n\n\n\n\nThanks, \n\nDane \n\n\n_______________________________________________ \nOpenStack-Infra mailing list \nOpenStack-Infra at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra \n\n\n_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<f67c8851bf52095b57f03061558cf081@localhost>',NULL),('<1707254585.0.1385100266203.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-22 06:04:25',0,'2013-11-22 06:04:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-havana #3','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/3/>\n\n------------------------------------------\n[...truncated 259 lines...]\n    rv = f(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1947, in _delete_instance\n    user_id=user_id)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1942, in _delete_instance\n    db_inst)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/instance.py\",> line 225, in _from_db_object\n    instance[field] = db_inst[field]\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/base.py\",> line 379, in __setitem__\n    setattr(self, name, value)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/base.py\",> line 70, in setter\n    field.coerce(self, name, value))\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 163, in coerce\n    return self._type.coerce(obj, attr, value)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 214, in coerce\n    value.__class__.__name__)\nValueError: (u\'A string is required here, not %s\', \'MagicMock\')\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: test_notifier.TestNovaNotifier.test_samples\ntags: worker-3\n----------------------------------------------------------------------\npythonlogging:\'\': {{{\nLoading compute driver \'nova.virt.fake.FakeDriver\'\nprocessing compute.instance.delete.start\nTerminating instance\nKey \'instance-00000001\' not in instances \'{}\'\nError setting Instance.vm_state\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/base.py\",> line 70, in setter\n    field.coerce(self, name, value))\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 163, in coerce\n    return self._type.coerce(obj, attr, value)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 214, in coerce\n    value.__class__.__name__)\nValueError: (u\'A string is required here, not %s\', \'MagicMock\')\n}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/mock.py\",> line 1201, in patched\n    return func(*args, **keywargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/nova_tests/test_notifier.py\",> line 224, in setUp\n    instance=self.instance)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 360, in decorated_function\n    return function(self, context, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/exception.py\",> line 90, in wrapped\n    payload)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/exception.py\",> line 73, in wrapped\n    return f(self, context, *args, **kw)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 250, in decorated_function\n    pass\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 236, in decorated_function\n    return function(self, context, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 301, in decorated_function\n    function(self, context, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 278, in decorated_function\n    e, sys.exc_info())\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 265, in decorated_function\n    return function(self, context, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1982, in terminate_instance\n    do_terminate_instance(instance, bdms)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/openstack/common/lockutils.py\",> line 248, in inner\n    return f(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1974, in do_terminate_instance\n    reservations=reservations)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/hooks.py\",> line 105, in inner\n    rv = f(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1947, in _delete_instance\n    user_id=user_id)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/compute/manager.py\",> line 1942, in _delete_instance\n    db_inst)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/instance.py\",> line 225, in _from_db_object\n    instance[field] = db_inst[field]\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/base.py\",> line 379, in __setitem__\n    setattr(self, name, value)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/base.py\",> line 70, in setter\n    field.coerce(self, name, value))\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 163, in coerce\n    return self._type.coerce(obj, attr, value)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/.tox/py27/local/lib/python2.7/site-packages/nova/objects/fields.py\",> line 214, in coerce\n    value.__class__.__name__)\nValueError: (u\'A string is required here, not %s\', \'MagicMock\')\n======================================================================\nFAIL: process-returncode\ntags: worker-3\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 8 tests in 0.904s\nFAILED (id=0, failures=8)\nerror: testr failed (1)\nERROR: InvocationError: \'/bin/bash -x <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/run-tests.sh\'>\npy27 runtests: commands[1] | <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-havana/ws/tools/config/check_uptodate.sh>\nNo module named deprecated\nNo module named crypto\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nFlask==0.10.1\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.1.3\nTempita==0.5.1\nWSME==0.5b5\nWebOb==1.2.3\nWebTest==2.0.10\nWerkzeug==0.9.4\nalembic==0.6.0\namqp==1.3.3\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\nboto==2.17.0\n-e git://git.openstack.org/openstack/ceilometer at d90c8e1638e957f867ed507464c889782edc241e#egg=ceilometer-origin/stable/havana\ncffi==0.8\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.7\ndecorator==3.4.0\ndiscover==0.4.0\ndnspython==1.11.1\ndocutils==0.9.1\necdsa==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhappybase==0.7\nhttplib2==0.8\niso8601==0.1.8\nitsdangerous==0.23\njsonpatch==1.3\njsonpointer==1.1\njsonschema==2.3.0\nkombu==3.0.5\nlxml==3.2.4\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nmsgpack-python==0.4.0\nnetaddr==0.7.10\nnetifaces==0.8\nnova==2014.1.dev807.g250b92d\nnumpy==1.8.0\noslo.config==1.2.1\noslo.sphinx==1.1\nparamiko==1.12.0\npbr==0.5.23\npecan==0.4.2\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycparser==2.10\npycrypto==2.6.1\npyflakes==0.7.3\npymongo==2.6.3\npyparsing==2.0.1\npython-ceilometerclient==1.0.6\npython-cinderclient==1.0.7\npython-glanceclient==0.12.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-subunit==0.0.15\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplegeneric==0.8.1\nsimplejson==3.3.1\nsingledispatch==3.4.0.2\nsix==1.4.1\nsphinxcontrib-httpdomain==1.2.0\nsphinxcontrib-pecanwsme==0.5\nsqlalchemy-migrate==0.8.2\nstevedore==0.12\nsuds==0.4\nswift==1.10.0\ntestrepository==0.0.18\ntestscenarios==0.4\ntesttools==0.9.33\nthrift==0.9.1\nwaitress==0.8.7\nwarlock==1.1.0\nwebsockify==0.5.1\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py27/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nTraceback (most recent call last):\n  File \"/usr/local/jenkins/slave_scripts/subunit2html.py\", line 727, in <module>\n    main()\n  File \"/usr/local/jenkins/slave_scripts/subunit2html.py\", line 702, in main\n    stream = open(subunit_file, \'rb\')\nIOError: [Errno 2] No such file or directory: \'./subunit_log.txt\'\n+ gzip -9 ./subunit_log.txt\ngzip: ./subunit_log.txt: No such file or directory\n+ gzip -9 ./testr_results.html\ngzip: ./testr_results.html: No such file or directory\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.uiO8W5MudD\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-havana/precise24/3\n[SCP] Copying console log.\n\n\n','<35885463.135.1385014061716.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1707825463.199.1356480794110.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-26 00:13:14',0,'2012-12-26 00:13:14',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-folsom #86','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/86/>\n\n------------------------------------------\n[...truncated 904 lines...]\n    test_max_object_name_length                                  OK    0.00\n    test_max_upload_time                                         OK    0.50\n    test_short_body                                              OK    0.00\nTestObjectUpdater\n    test_creation                                                OK    0.00\n    test_object_sweep                                            OK    0.11\n    test_run_once                                                OK    0.05\nTestAccountController\n    test_DELETE                                                  OK    0.01\n    test_GET                                                     OK    0.02\n    test_GET_autocreate                                          OK    0.01\n    test_HEAD                                                    OK    0.02\n    test_HEAD_autocreate                                         OK    0.01\n    test_POST_autocreate                                         OK    0.02\n    test_POST_bad_metadata                                       OK    0.01\n    test_POST_metadata                                           OK    0.01\n    test_PUT                                                     OK    0.01\n    test_PUT_bad_metadata                                        OK    0.01\n    test_PUT_connect_exceptions                                  OK    0.02\n    test_PUT_max_account_name_length                             OK    0.01\n    test_PUT_metadata                                            OK    0.01\n    test_connection_refused                                      OK    0.01\n    test_other_socket_error                                      OK    0.01\n    test_response_get_accept_ranges_header                       OK    0.01\n    test_response_head_accept_ranges_header                      OK    0.01\nTestContainerController\n    test_DELETE                                                  OK    0.02\n    test_GET_calls_authorize                                     OK    0.01\n    test_GET_no_content                                          OK    0.01\n    test_HEAD                                                    OK    0.01\n    test_HEAD_calls_authorize                                    OK    0.01\n    test_POST_bad_metadata                                       OK    0.01\n    test_POST_calls_clean_acl                                    OK    0.01\n    test_POST_metadata                                           OK    0.01\n    test_PUT                                                     OK    0.01\n    test_PUT_bad_metadata                                        OK    0.02\n    test_PUT_calls_clean_acl                                     OK    0.01\n    test_PUT_connect_exceptions                                  OK    0.02\n    test_PUT_max_container_name_length                           OK    0.01\n    test_PUT_max_containers_per_account                          OK    0.01\n    test_PUT_metadata                                            OK    0.01\n    test_acc_missing_returns_404                                 OK    0.01\n    test_error_limiting                                          OK    0.04\n    test_put_locking                                             OK    0.01\n    test_response_get_accept_ranges_header                       OK    0.01\n    test_response_head_accept_ranges_header                      OK    0.01\nTestController\n    test_account_info_200                                        OK    0.01\n    test_account_info_404                                        OK    0.01\n    test_account_info_account_autocreate                         OK    0.01\n    test_account_info_no_cache                                   OK    0.01\n    test_container_info_200                                      OK    0.01\n    test_container_info_404                                      OK    0.01\n    test_container_info_invalid_account                          OK    0.01\n    test_container_info_no_cache                                 OK    0.01\n    test_make_requests                                           OK    0.01\nTestObjectController\n    test_COPY                                                    OK    0.03\n    test_COPY_calls_authorize                                    OK    0.01\n    test_COPY_newest                                             OK    0.01\n    test_DELETE                                                  OK    0.01\n    test_GET_calls_authorize                                     OK    0.01\n    test_GET_newest                                              OK    0.01\n    test_GET_newest_large_file                                   OK    0.13\n    test_HEAD                                                    OK    0.01\n    test_HEAD_calls_authorize                                    OK    0.01\n    test_HEAD_newest                                             OK    0.01\n    test_POST                                                    OK    0.01\n    test_POST_as_copy                                            OK    0.03\n    test_POST_as_copy_calls_authorize                            OK    0.01\n    test_POST_as_copy_meta_key_len                               OK    0.01\n    test_POST_as_copy_meta_val_len                               OK    0.01\n    test_POST_calls_authorize                                    OK    0.01\n    test_POST_converts_delete_after_to_delete_at                 OK    0.01\n    test_POST_delete_at                                          OK    0.01\n    test_POST_meta_count                                         OK    0.01\n    test_POST_meta_key_len                                       OK    0.01\n    test_POST_meta_size                                          OK    0.01\n    test_POST_meta_val_len                                       OK    0.01\n    test_POST_negative_delete_after                              OK    0.01\n    test_POST_non_int_delete_after                               OK    0.00\n    test_PUT                                                     OK    0.01\n    test_PUT_POST_as_copy_requires_container_exist               OK    0.01\n    test_PUT_POST_requires_container_exist                       OK    0.01\n    test_PUT_auto_content_type                                   OK    0.01\n    test_PUT_calls_authorize                                     OK    0.01\n    test_PUT_connect_exceptions                                  OK    0.02\n    test_PUT_converts_delete_after_to_delete_at                  OK    0.01\n    test_PUT_delete_at                                           OK    0.01\n    test_PUT_getresponse_exceptions                              OK    0.01\n    test_PUT_max_size                                            OK    0.01\n    test_PUT_negative_delete_after                               OK    0.01\n    test_PUT_non_int_delete_after                                OK    0.01\n    test_PUT_send_exceptions                                     OK    0.01\n    test_acc_or_con_missing_returns_404                          OK    0.01\n    test_bad_metadata                                            OK    0.02\n    test_best_response_sets_etag                                 OK    0.01\n    test_chunked_put                                             OK    0.01\n    test_chunked_put_bad_method                                  OK    0.01\n    test_chunked_put_bad_path                                    OK    0.01\n    test_chunked_put_bad_path_no_controller                      OK    0.01\n    test_chunked_put_bad_utf8                                    OK    0.01\n    test_chunked_put_bad_version                                 OK    0.01\n    test_chunked_put_chunked_put                                 OK    0.10\n    test_chunked_put_head_account                                OK    0.01\n    test_chunked_put_lobjects                                    OK    0.73\n    test_chunked_put_lobjects_with_nonzero_size_manifest_file    OK    0.39\n    test_chunked_put_unhandled_exception                         OK    0.01\n    test_chunked_put_utf8_all_the_way_down                       OK    0.16\n    test_client_disconnect                                       OK    0.01\n    test_client_timeout                                          OK    0.51\n    test_copy_from                                               OK    0.04\n    test_custom_mime_types_files                                 OK    0.01\n    test_error_limiting                                          OK    0.04\n    test_iter_nodes                                              OK    0.01\n    test_leak_1                                                  OK    0.06\n    test_mismatched_etags                                        Traceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/eventlet/greenpool.py\",> line 80, in _spawn_n_impl\n    func(*args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/eventlet/wsgi.py\",> line 514, in process_request\n    proto = self.protocol(socket, address, self)\n  File \"/usr/lib/python2.6/SocketServer.py\", line 618, in __init__\n    self.finish()\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/eventlet/wsgi.py\",> line 456, in finish\n    BaseHTTPServer.BaseHTTPRequestHandler.finish(self)\n  File \"/usr/lib/python2.6/SocketServer.py\", line 661, in finish\n    self.wfile.flush()\n  File \"/usr/lib/python2.6/socket.py\", line 297, in flush\n    self._sock.sendall(buffer(data, write_offset, buffer_size))\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/eventlet/greenio.py\",> line 283, in sendall\n    tail = self.send(data, flags)\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/eventlet/greenio.py\",> line 269, in send\n    total_sent += fd.send(data[total_sent:], flags)\nerror: [Errno 32] Broken pipe\nOK    0.06\n    test_node_read_timeout                                       OK    0.71\n    test_node_write_timeout                                      OK    0.71\n    test_proxy_passes_content_length_on_head                     OK    0.01\n    test_proxy_passes_content_type                               OK    0.01\n    test_response_get_accept_ranges_header                       OK    0.01\n    test_response_head_accept_ranges_header                      OK    0.01\n    test_version_manifest                                        OK    1.26\nTestProxyServer\n    test_calls_authorize_allow                                   OK    0.01\n    test_calls_authorize_deny                                    OK    0.01\n    test_denied_host_header                                      OK    0.01\n    test_inexistent_method_request                               OK    0.01\n    test_internal_method_request                                 OK    0.01\n    test_negative_content_length                                 OK    0.01\n    test_unhandled_exception                                     OK    0.01\nTestSegmentedIterable\n    test_app_iter_range_unexpected_error                         OK    0.00\n    test_app_iter_range_with_many_segments                       OK    5.00\n    test_app_iter_range_with_no_segments                         OK    0.00\n    test_app_iter_range_with_one_segment                         OK    0.00\n    test_app_iter_range_with_two_segments                        OK    0.00\n    test_iter_unexpected_error                                   OK    0.00\n    test_iter_with_get_error                                     OK    0.00\n    test_iter_with_no_segments                                   OK    0.00\n    test_iter_with_one_segment                                   OK    0.00\n    test_iter_with_two_segments                                  OK    0.00\n    test_load_next_segment_rate_limiting                         OK    0.00\n    test_load_next_segment_unexpected_error                      OK    0.00\n    test_load_next_segment_with_get_error                        OK    0.00\n    test_load_next_segment_with_no_segments                      OK    0.00\n    test_load_next_segment_with_one_segment                      OK    0.00\n    test_load_next_segment_with_seek                             OK    0.00\n    test_load_next_segment_with_two_segments                     OK    0.00\n    test_load_next_segment_with_two_segments_skip_first          OK    0.00\n\n======================================================================\nFAIL: test_hash_suffix_multi_file_two (test.unit.obj.test_replicator.TestObjectReplicator)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/test/unit/obj/test_replicator.py\",> line 328, in test_hash_suffix_multi_file_two\n    self.assertEquals(len(os.listdir(whole_hsh_path)), 2)\nAssertionError: 1 != 2\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (1, 2))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 8.68 secs:\n    5.00    TestSegmentedIterable.test_app_iter_range_with_many_segments\n    1.26    TestObjectController.test_version_manifest\n    0.95    TestUtils.test_ratelimit_sleep_with_sleep\n    0.74    TestServer.test_wait\n    0.73    TestObjectController.test_chunked_put_lobjects\n----------------------------------------------------------------------\nRan 942 tests in 22.796s\n\nFAILED (SKIP=8, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin/nosetests> test/unit\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.3.3\nPygments==1.5\nSphinx==1.1.3\nWebOb==1.2.3\ncolorama==0.2.4\nconfigobj==4.7.1\ncoverage==3.6b2\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.15\ngreenlet==0.3.1\nnetifaces==0.6\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npep8==0.6.1\npython-swiftclient==0.0.0\nsimplejson==2.0.9\nswift==1.7.4.1\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=73\n+ \'[\' 73 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.wt2xt5nKjP\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-folsom/86\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-swift-python26-stable-folsom/86/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1707f1b2458746c5a9b56ce2692b0c11@HKNPR01MB241.apcprd01.prod.exchangelabs.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-15 03:01:23',0,'2014-07-15 03:01:23',NULL,'[openstack-dev] Can not create cinder volume','Hi,\n\nHere is my complete cinder-volume.log\n2014-07-15 10:55:28.849 27399 AUDIT cinder.service [-] Starting cinder-volume node (version 2014.1)\n2014-07-15 10:55:28.862 27399 INFO cinder.volume.manager [req-06b5b19c-20b2-4e8d-a675-b4ef51ebe3a6 - - - - -] Starting volume driver LVMISCSIDriver (2.0.0)\n2014-07-15 10:55:29.985 27399 ERROR cinder.volume.manager [req-06b5b19c-20b2-4e8d-a675-b4ef51ebe3a6 - - - - -] Error encountered during initialization of driver: LVMISCSIDriver\n2014-07-15 10:55:29.986 27399 ERROR cinder.volume.manager [req-06b5b19c-20b2-4e8d-a675-b4ef51ebe3a6 - - - - -] Unexpected error while running command.\nCommand: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --noheadings -o name cinder-volumes\nExit code: 1\nStdout: \'\'\nStderr: \'Traceback (most recent call last):\\n  File \"/usr/bin/cinder-rootwrap\", line 10, in <module>\\n    sys.exit(main())\\n  File \"/usr/lib/python2.7/dist-packages/oslo/rootwrap/cmd.py\", line 107, in main\\n    filters = wrapper.load_filters(config.filters_path)\\n  File \"/usr/lib/python2.7/dist-packages/oslo/rootwrap/wrapper.py\", line 119, in load_filters\\n    for (name, value) in filterconfig.items(\"Filters\"):\\n  File \"/usr/lib/python2.7/ConfigParser.py\", line 347, in items\\n    raise NoSectionError(section)\\nConfigParser.NoSectionError: No section: \\\'Filters\\\'\\n\'\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager Traceback (most recent call last):\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/volume/manager.py\", line 243, in init_host\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     self.driver.check_for_setup_error()\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/volume/drivers/lvm.py\", line 83, in check_for_setup_error\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     executor=self._execute)\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/brick/local_dev/lvm.py\", line 81, in __init__\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     if self._vg_exists() is False:\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/brick/local_dev/lvm.py\", line 106, in _vg_exists\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     self.vg_name, root_helper=self._root_helper, run_as_root=True)\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/utils.py\", line 136, in execute\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     return processutils.execute(*cmd, **kwargs)\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager   File \"/usr/lib/python2.7/dist-packages/cinder/openstack/common/processutils.py\", line 173, in execute\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager     cmd=\' \'.join(cmd))\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager ProcessExecutionError: Unexpected error while running command.\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --noheadings -o name cinder-volumes\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager Exit code: 1\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager Stdout: \'\'\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager Stderr: \'Traceback (most recent call last):\\n  File \"/usr/bin/cinder-rootwrap\", line 10, in <module>\\n    sys.exit(main())\\n  File \"/usr/lib/python2.7/dist-packages/oslo/rootwrap/cmd.py\", line 107, in main\\n    filters = wrapper.load_filters(config.filters_path)\\n  File \"/usr/lib/python2.7/dist-packages/oslo/rootwrap/wrapper.py\", line 119, in load_filters\\n    for (name, value) in filterconfig.items(\"Filters\"):\\n  File \"/usr/lib/python2.7/ConfigParser.py\", line 347, in items\\n    raise NoSectionError(section)\\nConfigParser.NoSectionError: No section: \\\'Filters\\\'\\n\'\n2014-07-15 10:55:29.986 27399 TRACE cinder.volume.manager\n2014-07-15 10:55:30.909 27399 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on controller:5672\n2014-07-15 10:55:49.942 27399 INFO cinder.volume.manager [req-2e368031-ee15-428d-8239-2973261f116d - - - - -] Updating volume status\n2014-07-15 10:55:49.943 27399 WARNING cinder.volume.manager [req-2e368031-ee15-428d-8239-2973261f116d - - - - -] Unable to update stats, LVMISCSIDriver -2.0.0  driver is uninitialized.\n\nMy cinder version is 1.0.8, and ?cinder service-list? output is listed as below,\n+------------------+------------+------+---------+-------+----------------------------+\n|      Binary      |    Host    | Zone |  Status | State |         Updated_at         |\n+------------------+------------+------+---------+-------+----------------------------+\n| cinder-scheduler | controller | nova | enabled |   up  | 2014-07-15T02:57:55.000000 |\n|  cinder-volume   | controller | nova | enabled |   up  | 2014-07-15T02:57:51.000000 |\n+------------------+------------+------+---------+-------+----------------------------+\n\n\nRegards,\nJohnson\n\n\nFrom: John Griffith [mailto:john.griffith at solidfire.com]\nSent: Monday, July 14, 2014 10:26 PM\nTo: OpenStack Development Mailing List (not for usage questions)\nSubject: Re: [openstack-dev] Can not create cinder volume\n\n\n\nOn Mon, Jul 14, 2014 at 8:13 AM, Duncan Thomas <duncan.thomas at gmail.com<mailto:duncan.thomas at gmail.com>> wrote:\nPlease post up more (all) of your cinder-volume.log - something is stopping your driver being initialised, but you haven\'t provided enough logs to tell what the issue it.\n\nOn 14 July 2014 12:22, Johnson Cheng <Johnson.Cheng at qsantechnology.com<mailto:Johnson.Cheng at qsantechnology.com>> wrote:\nDear All,\n\nWhen I use ?cinder create ?display-name myVolume 1? to create a cinder volume, its status will be error when I use ?cinder list? to query it.\n+--------------------------------------+--------+--------------+------+-------------+----------+-------------+\n|                  ID                  | Status | Display Name | Size | Volume Type | Bootable | Attached to |\n+--------------------------------------+--------+--------------+------+-------------+----------+-------------+\n| 83059a3e-e66c-4fd8-829e-09ca450b4d70 | error  |   myVolume   |  1   |     None    |  false   |             |\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nMy Openstack version is Icehouse, and I install it on Ubuntu 14.04 LTS.\n\nThe vgs output,\n  VG                #PV #LV #SN Attr   VSize   VFree\n  cinder-volumes      1   0   0 wz--n- 153.38g 153.38g\n\nHere is my cinder.conf\n[DEFAULT]\nrootwrap_config = /etc/cinder/rootwrap.conf\napi_paste_confg = /etc/cinder/api-paste.ini\niscsi_helper = tgtadm\nvolume_name_template = volume-%s\nvolume_group = cinder-volumes\nverbose = True\nauth_strategy = keystone\nstate_path = /var/lib/cinder\nlock_path = /var/lock/cinder\nvolumes_dir = /var/lib/cinder/volumes\n\nrpc_backend = cinder.openstack.common.rpc.impl_kombu\nrabbit_host = controller\nrabbit_port = 5672\nrabbit_userid = guest\nrabbit_password = demo\n\nglance_host = controller\n\ncontrol_exchange = cinder\nnotification_driver = cinder.openstack.common.notifier.rpc_notifier\n\n[database]\nconnection = mysql://cinder:demo at controller/cinder\n\n[keystone_authtoken]\nauth_uri = http://controller:5000\nauth_host = controller\nauth_port = 35357\nauth_protocol = http\nadmin_tenant_name = service\nadmin_user = cinder\nadmin_password = demo\n\nHere is my cinder-schedule.log\n2014-07-14 17:34:37.592 7141 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on controller:5672\n2014-07-14 17:34:44.769 7141 WARNING cinder.context [-] Arguments dropped when creating context: {\'user\': u\'1149275f4ea84690a9da5b7f442ab48f\', \'tenant\': u\'4e898758e77c4d3c8d0b0eecf5ae0957\', \'user_identity\': u\'1149275f4ea84690a9da5b7f442ab48f 4e898758e77c4d3c8d0b0eecf5ae0957 - - -\'}\n2014-07-14 17:34:45.004 7141 ERROR cinder.scheduler.filters.capacity_filter [req-ebae9974-8741-4a6d-af44-456e506e5612 1149275f4ea84690a9da5b7f442ab48f 4e898758e77c4d3c8d0b0eecf5ae0957 - - -] Free capacity not set: volume node info collection broken.\n2014-07-14 17:34:45.030 7141 ERROR cinder.scheduler.flows.create_volume [req-ebae9974-8741-4a6d-af44-456e506e5612 1149275f4ea84690a9da5b7f442ab48f 4e898758e77c4d3c8d0b0eecf5ae0957 - - -] Failed to schedule_create_volume: No valid host was found.\n\nHere is my cinder-volume.log\n2014-07-14 19:14:15.489 7151 INFO cinder.volume.manager [-] Updating volume status\n2014-07-14 19:14:15.490 7151 WARNING cinder.volume.manager [-] Unable to update stats, LVMISCSIDriver -2.0.0  driver is uninitialized.\n\n\nYour response will be appreciated.\nLet me know if you need more information.\n\n\nRegards,\nJohnson\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n--\nDuncan Thomas\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n?Make sure \"controller\" resolves on your cinder-volume node.  It appears that either your volume-node isn\'t able to communicate with the controller (you can check this by trying a \'cinder service-list\').  Another possibility is something\'s not quite right with your message queue settings.  Main thing here would again be name resolution and that your message queue is actually matched up here (ie settings on the controller match those on your volume-node).\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/04dc9c49/attachment.html>\n\n','<CA+qL3LWUZT35KtFMmi_XRsaP1cys0kCsUWuh5L9FS0shHOfRFA@mail.gmail.com>',NULL),('<1708260848.69.1353804405396.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-25 00:46:45',0,'2012-11-25 00:46:45',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #55','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/55/>\n\n------------------------------------------\n[...truncated 12137 lines...]\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nCheck that the required fields are returned with values ... ok\nThe created server should be in the list of all servers ... ok\nThe created server should be in the detailed list of all servers ... ok\nVerify the specified server attributes are set correctly ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nThe expected flavor details should be returned ... ok\nList of all flavors should contain the expected flavor ... ok\nDetailed list of all flavors should contain the expected flavor ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\nReturns the correct details for a single image ... ok\nThe list of all images should contain the image ... ok\nDetailed list of all images should contain the expected images ... ok\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nThe server\'s password should be set to the provided password ... SKIP: Change password not available.\nThe server should be power cycled ... ok\nThe server should be signaled to reboot gracefully ... SKIP: Until bug 1014647 is dealt with.\nThe server should be rebuilt using the provided image and data ... ok\nThe server\'s RAM and disk space should be modified to that of ... SKIP: Resize not available.\nAll public and private addresses for ... ok\nProviding a network type should filter ... ok\nCREATE, GET, DELETE Volume ... No handlers could be found for logger \"tempest.common.rest_client\"\nok\nCREATE, GET, DELETE Volume ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nCreate a user ... ok\nDelete a user ... ok\nGet a list of users and find the test user ... ok\nValid user\'s token is authenticated ... ok\nVolume is attached and detached successfully from an instance ... ok\nCreate a volume, Get it\'s details and Delete the volume ... ERROR\nCreate a volume, Get it\'s details and Delete the volume ... ERROR\nERROR\nERROR\n\n======================================================================\nERROR: Create a volume, Get it\'s details and Delete the volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_get.py\", line 68, in test_volume_create_get_delete\n    self.client.wait_for_resource_deletion(volume[\'id\'])\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 260, in wait_for_resource_deletion\n    raise exceptions.TimeoutException\nTimeoutException: Request timed out\n\n======================================================================\nERROR: Create a volume, Get it\'s details and Delete the volume\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_get.py\", line 66, in test_volume_create_get_delete\n    resp, _ = self.client.delete_volume(volume[\'id\'])\n  File \"/opt/stack/tempest/tempest/services/volume/json/volumes_client.py\", line 93, in delete_volume\n    return self.delete(\"volumes/%s\" % str(volume_id))\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 169, in delete\n    return self.request(\'DELETE\', url, headers)\n  File \"/opt/stack/tempest/tempest/common/rest_client.py\", line 208, in request\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'Invalid volume: Volume status must be available or error\', u\'code\': 400}}\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_list.py\", line 125, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/volume/json/volumes_client.py\", line 132, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Volume volume791820 failed to reach available status within the required time (300.0 s).\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/tempest/tempest/tests/volume/test_volumes_list.py\", line 79, in setUpClass\n    cls.client.wait_for_volume_status(volume[\'id\'], \'available\')\n  File \"/opt/stack/tempest/tempest/services/volume/json/volumes_client.py\", line 132, in wait_for_volume_status\n    raise exceptions.TimeoutException(message)\nTimeoutException: Request timed out\nDetails: Volume volume456398 failed to reach available status within the required time (300.0 s).\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 42 tests in 1684.636s\n\nFAILED (SKIP=8, errors=4)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/devstack-gate-setup-workspace.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/localrc.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/screen-swift.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/55/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<170838695.49.1352681257190.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-12 00:47:37',0,'2012-11-12 00:47:37',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-postgres-vm-full #4','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/4/>\n\n\n\n','<1942645669.37.1352595956917.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1708986166.9111460.1391541180905.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 14:13:00',-18000,'2014-02-04 19:13:00',NULL,'[openstack-dev] Ugly Hack to deal with multiple versions','\n\n----- Original Message -----\n> From: \"Dean Troyer\" <dtroyer at gmail.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Tuesday, February 4, 2014 9:31:57 AM\n> Subject: Re: [openstack-dev] Ugly Hack to deal with multiple versions\n> \n> On Mon, Feb 3, 2014 at 1:50 PM, Adam Young < ayoung at redhat.com > wrote:\n> \n> HACK: In a new client, look at the URL. If it ends with /v2.0, chop it off\n> and us the substring up to that point.\n> \n> Now, at this point you are probably going: That is ugly, is it really\n> necessary? Can\'t we do something more correct?\n> \n> At this point I think we are stuck with hard-coding some legacy compatibility\n> like this for the near future. Fortunately Identity is an easy one to\n> handle, Compute is going to be a #$^%! as the commonly documented case has a\n> version not at the end.\n> \n> I\'ve been playing with variations on this strategy and I think it is our\n> least bad option...\n> \n> \n> \n> Can we accept that this is necessary, and vow to never let this happen again\n> by removing the versions from the URLs after the current set of clients are\n> deprecated?\n> +1\n> \n> There is another hack to think about: if public_endpoint and/or\n> admin_endpoint are not set in keystone.conf, all of the discovered urls use\n> localhost: http://localhost:8770/v2.0/ . Discovery falls over aga\n> \n> I don\'t know how common this is but I have encountered it at least once or\n> twice. Is this the only place those config values are used? It seems like a\n> better default could be worked out here too; is \'localhost\' ever the right\n> thing to advertise in a real-world deployment?\n\nI\'ve not come across that one so much as something similar i\'ve been wanting to \nraise. Version discovery happens across either a public or an internal URL \nand we retrieve the version list which has links to version endpoints. \n\nThese links in discovery are fully qualified and so it doesn\'t matter if you \nconnect to the server across the internal or public address you will always end\nup communicating with the links specified in the config\'s public_endpoint value. \n\nI propose for this situation we allow (and make default asap) that links in\ndiscovery can be relative links in the standard <a href=\"\" /> manner (ie \npython\'s urljoin rather than the just append it that we do now) joined onto\nthe URL that took us to the page.\n\nSo keystone: \n\n{\'versions\': {\'values\': [{\'id\': \'v3.0\',\n                          \'links\': [{\'href\': \'/v3/\',\n                                     \'rel\': \'self\'}],\n                          \'status\': \'stable\',\n                          \'updated\': \'2013-03-06T00:00:00Z\'},\n                         {\'id\': \'v2.0\',\n                          \'links\': [{\'href\': \'/v2.0/\',\n                                     \'rel\': \'self\'},\n                          \'status\': \'stable\',\n                          \'updated\': \'2013-03-06T00:00:00Z\'}]}}\n\n> dt\n> \n> --\n> \n> Dean Troyer\n> dtroyer at gmail.com\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAOJFoEt8vcJ_TF8Es6yneCUP06Pa6A1x5-neJiXKkYfKh84GBA@mail.gmail.com>',NULL),('<1708DBD9-A6C2-4C60-9376-3093229ED7F7@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-17 18:01:27',28800,'2013-12-17 10:01:27',NULL,'[Openstack] Unable to boot instance','you can check nova-scheduler service log, you can find about error log. Maybe you have no valid nova-compute host, check you ntp and nova-compute is work!\n\nKevin Zhang\nWeibo:kevin_prajna\nTwitter:topshare\nMSN:zhangjinnan at hotmail.com\n\n\n\nOn Dec 17, 2013, at 2:21 PM, Kevin Breit <kevin.breit at kevinbreit.net> wrote:\n\n> No valid host was found\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131217/e3214729/attachment.html>\n\n','<etPan.52afedb7.6b8b4567.108f@Kevins-MacBook-Pro.local>',NULL),('<1709100695.85.1384063801736.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-10 06:10:01',0,'2013-11-10 06:10:01',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #55','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/55/>\n\n------------------------------------------\n[...truncated 1276 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5c42e90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5c42e90>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x576a5d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x576a5d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-937de337-5102-4a49-8652-bbc97249ced0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:09:35Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'35\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'35\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:09:35Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'35\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'35\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:09:35+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'35\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'35\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-12T06:09:35-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'35\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'12\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'35\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:09:35Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'35\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'09\'} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'35\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6766250>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2cbd6d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.69 secs:\n    14.71    TestGlanceControl.test_bouncing\n    13.79    TestScrubber.test_delayed_delete\n    13.51    TestGlanceControl.test_reload\n    13.30    TestGlanceControl.test_respawn\n    12.38    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 484.468s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-55\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.sbHmNSYHOH\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/55\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/55/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/55\n[SCP] Copying console log.\n\n\n','<1298445286.83.1383977556506.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<170938092.3384805.1420563115718.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-06 17:51:55',3600,'2015-01-06 16:51:55',NULL,'[openstack-dev] [oslo] Progress of the port to Python 3','Hi,\n\nI\'m still working on porting OpenStack to Python 3. I\'m fixing Python 3 issues in eventlet and I\'m trying to replace eventlet with trollius in OpenStack. Two different and complementary ways to port OpenStack to Python 3.\n\n\nI fixed some eventlet issues related to Python 3 and monkey-patching. My changes are part of eventlet 0.16 which was released the 2014-12-30. I tried this version with Oslo Messaging: with another fix in eventlet (threading.Condition) and a change in the zmq driver, only 3 tests are now failing (which is a great success for me).\n\nSee my Oslo Messaging change for more information:\nhttps://review.openstack.org/#/c/145241/\n\nIt looks like eventlet 0.16 works much better with Python 3 and monkey-patching. You should try it on your own project! Tell me if you need help to fix issues.\n\n--\n\nAbout asyncio, I renamed my \"aiogreen\" project to \"aioeventlet\" (to make it more explicit that it is specific to eventlet). With the release 0.4, the API is now considered as stable.\nhttp://aioeventlet.readthedocs.org/\n\nMehdi Abaakouk voted +2 on my Oslo Messaging patches to support trollius coroutines using aioeventlet project, but it looks that he\'s alone to review Oslo Messaging patches :-/ Anyway to approve my changes?\n\n* Add an optional executor callback to dispatcher\n  https://review.openstack.org/136652\n* Add a new aioeventlet executor\n  https://review.openstack.org/136653\n\nBy the way, my review to add aioeventlet dependency also waits for a review:\n\n* Add aioeventlet dependency\n  https://review.openstack.org/138750\n\nVictor Stinner\n\n\n','<1655458275.3378881.1420562077391.JavaMail.zimbra@enovance.com>',NULL),('<1709884256.536.1367388869789.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-01 06:14:29',0,'2013-05-01 06:14:29',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-keystone-python27-stable-grizzly #21','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-grizzly/21/>\n\n\n\n','<745588134.514.1367302458224.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1710385962.2116561.1352914121528.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-14 12:28:41',-18000,'2012-11-14 17:28:41',NULL,'[openstack-dev] [nova][ceilometer] model for ceilo/nova interaction\n	going forward','\nFolks,\n\nTL;DR: soliciting feedback on the best (most stable/supportable)\napproach for ceilometer to interact with nova going forward.\n\nCurrently ceilo both consumes notifications from nova (instance\nlifecycle events & the like) and also periodically polls libvirt to\nextract more detailed info. This latter mechanism uses internal nova\nclasses, so we want to move towards a model that is more stable and\nsupportable into the future.\n\nWe are also currently limited to libvirt, so it would make sense to\nmove towards a more hypervisor-agnostic position, or at least to\nprovide wider support.\n\nNow, there are at least 4 different approaches that could be followed,\neach with its own advantages and disadvantages, so I just wanted to\ncall these out so to solicit some feedback and guidance from the nova\ndomain experts ...\n\n1. Extend the existing os-server-diagnostics API extension to expose\n   any additional stats that ceilo needs.\n\n   +  would allow the ceilo compute agent to be scaled independently\n      of the nova-compute node (i.e. no need for a 1:1 correspondence)\n   -  the diagnostics returned are currently hypervisor-specific\n   -  the additional nova-api-->nova-compute RPC call would add lag\n      and impact timeliness for metrics gathering\n\n\n2. Call the nova get_diagnostics RPC directly (as per the experimental\n   patch proposed by Yunhong Jiang https://review.openstack.org/15952),\n   or use a new RPC message specifically designed for this purpose.\n\n   +/- as for #1, but also removes the lag involved in an additional\n       hop between nova services\n   -   calling RPC directly would expose ceilo to a much less stable\n       (i.e. rapidly rev\'d) API than would be the case for #1\n\n\n3. Have nova itself emit metering messages directly onto the ceilo\n   message bus, encompassing both lifecycle events and usage stats,\n   to be picked up and persisted by the ceilo collector or other agent.\n\n   - leaks ceilo concerns into nova\n   - requires message bus usage, probably inappropriate for time-\n     sensitive measurements feeding into near-realtime metrics.\n\n\n4. Invert control and have the nova compute service itself call into a\n   ceilo-provided API that abstracts the conduit used for publication\n   (could be via the message bus, or UDP, or a direct call to a CW API)\n\n   - a loaded nova compute service may fall behind in this periodic\n     task, especially if the reporting cadence is configured high\n\n\nSo the question is how the nova domain experts see these options sizing\nup?\n\nPersonally I\'m liking option #2, aside from a lingering concern about\nhow rapidly RPC versioning is rev\'d (which suggests the more sedate\npace of API versioning would be easier to consume). Also some statement\non whether RPC is envisaged as being externally-callable would be good.\n\nThoughts/feedback most welcome ...\n\nThanks,\nEoghan\n\n\n',NULL,NULL),('<1710546841.17420569.1418059356293.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-08 12:22:36',-18000,'2014-12-08 17:22:36',NULL,'[openstack-dev] Where should Schema files live?','\n\n> >From: Sandy Walsh [sandy.walsh at RACKSPACE.COM] Monday, December 01, 2014 9:29\n> >AM\n> > \n> >>From: Duncan Thomas [duncan.thomas at gmail.com]\n> >>Sent: Sunday, November 30, 2014 5:40 AM\n> >>To: OpenStack Development Mailing List\n> >>Subject: Re: [openstack-dev] Where should Schema files live?\n> >> \n> >>Duncan Thomas\n> >>On Nov 27, 2014 10:32 PM, \"Sandy Walsh\" <sandy.walsh at rackspace.com> wrote:\n> >>> \n> >>> We were thinking each service API would expose their schema via a new\n> >>> /schema resource (or something). Nova would expose its schema. Glance\n> >>> its own. etc. This would also work well for installations still using\n> >>> older deployments.\n> >>This feels like externally exposing info that need not be external (since\n> >>the notifications are not external to the deploy) and it sounds like it\n> >>will potentially leak fine detailed version and maybe deployment config\n> >>details that you don\'t want to make public - either for commercial reasons\n> >>or to make targeted attacks harder\n> >> \n> > \n> >Yep, good point. Makes a good case for standing up our own service or just\n> >relying on the tarballs being in a well know place.\n> \n> Hmm, I wonder if it makes sense to limit the /schema resource to service\n> accounts. Expose it by role.\n> \n> There\'s something in the back of my head that doesn\'t like calling out to the\n> public API though. Perhaps unfounded.\n\nI\'m wondering here how this relates to the other URLs in the\nservice catalog that aren\'t intended for external consumption,\ne.g. the internalURL and adminURL.\n\nI had assumed that these URLs would be visible to external clients,\nbut protected by firewall rules such that clients would be unable\nto do anything in anger with those raw addresses from the outside.\n\nSo would including a schemaURL in the service catalog actually\nexpose an attack surface, assuming this was in general safely\nfirewalled off in any realistic deployment?\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A53669FF@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1711254962.34688602.1403711325458.JavaMail.root@mailnew.scality.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-06-25 17:48:45',7200,'2014-06-25 15:48:45',NULL,'[OpenStack-Infra] Requesting a Service Account','Hello,\n\nI currently work on Cinder for my company, Scality. We plan to work on other parts of openstack in the near future too, and as such, we are currently setting up a Third-party CI system, that would validate and vote for each project that requires (or supports) it.\n\nIt seems I was misled by the documentation and created a user account instead of a service account, named \"scal-ci\" with the ID 12123. I discussed it with anteaya before writing this message, so fungi (Jeremy Stanley) has the removal of that erroneous account on his todo list.\n\nSo here I am requestion a service account:\nUsername: scality-ci\nE-Mail: openstack-ci at scality.com\nName: Scality CI\nSsh key:\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDOoIUeA/EAhn0He8PUSQc038iSukahiDpHYB0lrWQQCqYrd8WJ0YJufl7cP8gi3nCAGn4Box5q36rO4UkI6ygs0SZJhmT1s9ASpezCCe3PkLZfQkqZC1Gb6FCpU5e/cKa6iaVBGbCjWleqfVwXQkSlF9GuFjyVp5glMF3IhWp7qw== stb at ns3317586.ip-5-135-165.eu\n\nThanks you !\n\n\n','<792810096.34614294.1403706923149.JavaMail.root@mailnew.scality.com>',NULL),('<1711272672.27061775.1402905576647.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-06-16 03:59:36',-14400,'2014-06-16 07:59:36',NULL,'[openstack-tc] An alternative approach to enforcing \"expected\n	election behaviour\"','\nTL;DR: how about we adopt a \"soft enforcement\" model, relying \n       on sound judgement and good faith within the community?\n\n\nHi Folks,\n\nI\'m concerned that the \"expected election behaviour\" review[1]\nis not converging on the optimal approach, partially due to the\ninitial concentration on the procedural aspects of the proposal.\n\nThis concentration was natural enough, due to shortcomings such\nas the lack of any provision for a right of reply, or the\nfuzziness around who was capable of deciding a violation had\noccurred and imposing the stiff penalties envisaged.\n\nHowever, I think we should take a step back at this stage and\nreconsider the whole approach. Looking at this in the round, as\nI see it, the approach mooted seems to suffer from a fundamental\nflaw.\n\nSpecifically, in holding individuals to the community code of\nconduct in a very *strict* sense (under pain of severe career\ndamage), when much of that code is written in an aspirational\nstyle, and so is not very suitable for use as an *objective*\nstandard.\n\nThe reference to \"the spirit of the OpenStack ideals\" ideals is\neven more problematic in that sense. Ideals by their nature are\n*idealized* versions of reality. So IMHO it\'s not workable to\ninfuse an aspiration to meet these laudable ideals, with the\nlanguage of abuse, violations, investigation, punishment etc.\nIn fact it strikes me as a tad Orwellian to do so.\n\nSo I wanted to throw an alternative idea out onto the table ...\n\nHow about we rely instead on the values and attributes that\nactually make our community strong?\n\nSpecifically: maturity, honesty, and a self-correcting nature.\n\nHow about we simply require that each candidate for a TC or PTL\nelection gives a simple undertaking in their self-nomination mail,\nalong the lines of:\n\n\"I undertake to respect the election process, as required by the\ncommunity code of conduct.\n\nI also undertake not to engage in campaign practices that the\ncommunity has considered objectionable in the past, including but\nnot limited to, unsolicited mail shots and private campaign events.\n\nIf my behavior during this election period does not live up to those\nstandards, please feel free to call me out on it on this mailing\nlist and/or withhold your vote.\"\n\nWe then rely on:\n\n  (a) the self-policing nature of an honest, open community\n\nand:\n\n  (b) the maturity and sound judgement within that community giving\n      us the ability to quickly spot and disregard any frivolous\n      reports of mis-behavior\n\nSo no need for heavy-weight inquisitions, no need to interrupt the\nelection process, no need for handing out of stiff penalties such\nas termination of membership.\n\nInstead, we simply rely on good faith and sound judgement within\nthe community.\n\nTBH I think we\'re pretty good at making ourselves heard when\nneeds be, and also pretty good at filtering through the noise. \n\nSo I would trust the electorate to apply their judgement, filter\nout those reports of bad practice that they consider frivolous or\ntending to make mischief, or conversely to withhold their vote if\nthey consider the practice reported to be unacceptable.\n\nIf someone has already cast their vote when the report of some\nquestionable behavior surfaces, well so be it. The electorate\nhas a long memory and most successful candidates end up running\nagain for subsequent elections (e.g. a follow-on term as PTL,\nor for the TC).\n\nThe key strength of this alternative approach IMO is that it\ndirectly relies on the *actual* values of the community, as\nopposed to attempting to codify those values, a priori.\n\nJust my $0.02 ...\n\nCheers,\nEoghan\n\n[1] https://review.openstack.org/98675\n[2] http://www.openstack.org/legal/community-code-of-conduct\n\n\n','<1539033312.27056006.1402905037444.JavaMail.zimbra@redhat.com>',NULL),('<1711499432.31.1383286370396.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-01 06:12:50',0,'2013-11-01 06:12:50',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #52','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/52/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bb2610>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bb2610>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5306310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5306310>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-56d24ae8-14cb-4f41-bda7-e4b822be3d0c\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x38187d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x38187d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x38187d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x38187d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:12:14Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'14\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:12:14Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'14\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:12:14+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'14\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:12:14-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'14\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:12:14Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'14\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6902c90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x23ba2d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 88.39 secs:\n    25.80    TestScrubber.test_scrubber_app\n    20.26    TestScrubber.test_delayed_delete\n    14.48    TestGlanceControl.test_reload\n    14.29    TestGlanceControl.test_respawn\n    13.56    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1109 tests in 596.970s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.52\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ctD27h81yK\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/52/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise27/52\n[SCP] Copying console log.\n\n\n','<1526471866.20.1383026927446.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1711834456.6.1377499376379.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-26 06:42:56',0,'2013-08-26 06:42:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-grizzly #9','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-grizzly/9/>\n\n------------------------------------------\n[...truncated 107 lines...]\n    test_image_update_properties                                 OK    0.01\n    test_image_update_purge_properties                           OK    0.01\n    test_image_update_with_locations                             OK    0.01\n    test_is_image_visible                                        OK    0.01\nTestSimpleMembershipVisibility\n    test_admin_finding_owner1s_image_members                     OK    0.02\n    test_admin_finding_user1_memberships                         OK    0.02\n    test_owner1_finding_owner1s_image_members                    OK    0.02\n    test_owner1_finding_user1_memberships                        OK    0.02\n    test_user1_finding_owner1s_image_members                     OK    0.02\n    test_user1_finding_user1_memberships                         OK    0.02\n    test_user2_finding_owner1s_image_members                     OK    0.02\n    test_user2_finding_user1_memberships                         OK    0.02\n    test_user3_finding_owner1s_image_members                     OK    0.02\nTestSimpleVisibility\n    test_known_admin_is_public_false                             OK    0.02\n    test_known_admin_is_public_none                              OK    0.02\n    test_known_admin_is_public_true                              OK    0.02\n    test_known_admin_sees_all                                    OK    0.02\n    test_tenant1_is_public_false                                 OK    0.02\n    test_tenant1_is_public_none                                  OK    0.02\n    test_tenant1_is_public_true                                  OK    0.02\n    test_unknown_admin_is_public_false                           OK    0.02\n    test_unknown_admin_is_public_none                            OK    0.02\n    test_unknown_admin_is_public_true                            OK    0.02\n    test_unknown_admin_sees_all                                  OK    0.02\n    test_unknown_user_is_public_false                            OK    0.02\n    test_unknown_user_is_public_none                             OK    0.02\n    test_unknown_user_is_public_true                             OK    0.02\n    test_what_tenant1_sees                                       OK    0.02\n    test_what_unknown_user_sees                                  OK    0.02\nTestSqlAlchemyDriver\n    test_image_create_defaults                                   OK    0.09\n    test_image_create_duplicate_id                               OK    0.06\n    test_image_create_properties                                 OK    0.06\n    test_image_create_requires_status                            OK    0.06\n    test_image_create_unknown_attribtues                         OK    0.06\n    test_image_create_with_locations                             OK    0.06\n    test_image_destroy                                           OK    0.07\n    test_image_get                                               OK    0.06\n    test_image_get_all                                           OK    0.06\n    test_image_get_all_invalid_sort_key                          OK    0.05\n    test_image_get_all_limit                                     OK    0.16\n    test_image_get_all_limit_marker                              OK    0.06\n    test_image_get_all_marker                                    OK    0.07\n    test_image_get_all_marker_deleted                            OK    0.07\n    test_image_get_all_marker_deleted_showing_deleted            OK    0.09\n    test_image_get_all_marker_deleted_showing_deleted_as_admin   OK    0.08\n    test_image_get_all_owned                                     OK    0.08\n    test_image_get_all_size_max                                  OK    0.07\n    test_image_get_all_size_min                                  OK    0.06\n    test_image_get_all_size_min_max                              OK    0.06\n    test_image_get_all_size_range                                OK    0.06\n    test_image_get_all_with_filter                               OK    0.06\n    test_image_get_all_with_filter_max_range_bad_value           OK    0.05\n    test_image_get_all_with_filter_min_range_bad_value           OK    0.13\n    test_image_get_all_with_filter_undefined_property            OK    0.06\n    test_image_get_all_with_filter_user_defined_property         OK    0.06\n    test_image_get_all_with_filter_user_deleted_property         OK    0.07\n    test_image_get_allow_deleted                                 OK    0.07\n    test_image_get_disallow_deleted                              OK    0.07\n    test_image_get_force_allow_deleted                           OK    0.07\n    test_image_get_multiple_members                              OK    0.12\n    test_image_get_not_found                                     OK    0.06\n    test_image_get_not_owned                                     OK    0.07\n    test_image_member_create                                     OK    0.06\n    test_image_member_delete                                     OK    0.06\n    test_image_member_find                                       OK    0.07\n    test_image_member_update                                     OK    0.06\n    test_image_member_update_status                              OK    0.06\n    test_image_paginate                                          OK    0.12\n    test_image_property_delete                                   OK    0.06\n    test_image_tag_create                                        OK    0.06\n    test_image_tag_delete                                        OK    0.06\n    test_image_tag_get_all                                       OK    0.06\n    test_image_tag_get_all_no_tags                               OK    0.05\n    test_image_tag_set_all                                       OK    0.06\n    test_image_update                                            OK    0.07\n    test_image_update_core_attribute                             OK    0.06\n    test_image_update_properties                                 OK    0.07\n    test_image_update_purge_properties                           OK    0.07\n    test_image_update_with_locations                             OK    0.07\n    test_is_image_visible                                        OK    0.07\nTestSqlAlchemyMembershipVisibility\n    test_admin_finding_owner1s_image_members                     OK    0.11\n    test_admin_finding_user1_memberships                         OK    0.14\n    test_owner1_finding_owner1s_image_members                    OK    0.11\n    test_owner1_finding_user1_memberships                        OK    0.12\n    test_user1_finding_owner1s_image_members                     OK    0.11\n    test_user1_finding_user1_memberships                         OK    0.20\n    test_user2_finding_owner1s_image_members                     OK    0.11\n    test_user2_finding_user1_memberships                         OK    0.11\n    test_user3_finding_owner1s_image_members                     OK    0.11\nTestSqlAlchemyVisibility\n    test_known_admin_is_public_false                             OK    0.11\n    test_known_admin_is_public_none                              OK    0.11\n    test_known_admin_is_public_true                              OK    0.11\n    test_known_admin_sees_all                                    OK    0.11\n    test_tenant1_is_public_false                                 OK    0.11\n    test_tenant1_is_public_none                                  OK    0.11\n    test_tenant1_is_public_true                                  OK    0.11\n    test_unknown_admin_is_public_false                           OK    0.11\n    test_unknown_admin_is_public_none                            OK    0.11\n    test_unknown_admin_is_public_true                            OK    0.11\n    test_unknown_admin_sees_all                                  OK    0.11\n    test_unknown_user_is_public_false                            OK    0.10\n    test_unknown_user_is_public_none                             OK    0.11\n    test_unknown_user_is_public_true                             OK    0.11\n    test_what_tenant1_sees                                       OK    0.12\n    test_what_unknown_user_sees                                  OK    0.11\nTestFilesystemStore\n    test_create_store                                            OK    0.01\n    test_get_remote_image                                        OK    0.01\n    test_lifecycle                                               OK    0.01\nTestHTTPStore\n    test_create_store                                            OK    0.00\n    test_get_remote_image                                        OK    0.08\n    test_lifecycle                                               SKIP\nTestS3Store\n    test_create_store                                            SKIP\n    test_get_remote_image                                        SKIP\n    test_lifecycle                                               SKIP\nTestSwiftStore\n    test_create_store                                            SKIP\n    test_get_remote_image                                        SKIP\n    test_lifecycle                                               SKIP\n    test_multitenant                                             SKIP\n    test_object_chunking                                         SKIP\nTestApi\n    test_delete_not_existing                                     OK    35.60\n    test_duplicate_image_upload                                  OK    8.50\n    test_filtered_images                                         OK    8.47\n    test_get_head_simple_post                                    OK    14.52\n    test_image_visibility_to_different_users                     OK    59.88\n    test_limited_images                                          OK    20.00\n    test_mismatched_checksum                                     OK    16.37\n    test_mismatched_size                                         OK    30.20\n    test_ordered_images                                          OK    55.03\n    test_ownership                                               OK    15.83\n    test_post_image_content_bad_container_format                 OK    36.31\n    test_post_image_content_bad_disk_format                      OK    37.87\n    test_put_image_content_bad_container_format                  OK    12.60\n    test_put_image_content_bad_disk_format                       OK    34.68\n    test_queued_process_flow                                     OK    28.24\n    test_size_greater_2G_mysql                                   OK    18.94\n    test_traceback_not_consumed                                  OK    13.54\n    test_unsupported_default_store                               OK    18.58\n    test_v1_enabled                                              OK    53.37\n    test_v1_not_enabled                                          OK    25.14\n    test_zero_initial_size                                       OK    33.92\nTestCopyToFile\n    test_copy_from_file                                          OK    24.52\n    test_copy_from_http_exists                                   OK    53.63\n    test_copy_from_http_nonexistent                              OK    49.77\n    test_copy_from_s3                                            SKIP\n    test_copy_from_swift                                         SKIP\nTestMiscellaneous\n    test_api_response_when_image_deleted_from_filesystem         OK    44.34\n    test_exception_not_eaten_from_registry_to_api                OK    39.51\nTestMultiprocessing\n    test_interrupt_avoids_respawn_storm                          OK    23.72\n    test_multiprocessing                                         OK    55.44\nTestRBD\n    test_delete_not_existing                                     SKIP\n    test_duplicate_image_upload                                  SKIP\n    test_filtered_images                                         SKIP\n    test_get_head_simple_post                                    SKIP\n    test_image_visibility_to_different_users                     SKIP\n    test_limited_images                                          SKIP\n    test_mismatched_checksum                                     SKIP\n    test_mismatched_size                                         SKIP\n    test_ordered_images                                          SKIP\n    test_ownership                                               SKIP\n    test_post_image_content_bad_container_format                 SKIP\n    test_post_image_content_bad_disk_format                      SKIP\n    test_put_image_content_bad_container_format                  SKIP\n    test_put_image_content_bad_disk_format                       SKIP\n    test_queued_process_flow                                     SKIP\n    test_size_greater_2G_mysql                                   SKIP\n    test_traceback_not_consumed                                  SKIP\n    test_unsupported_default_store                               SKIP\n    test_v1_enabled                                              SKIP\n    test_v1_not_enabled                                          SKIP\n    test_zero_initial_size                                       SKIP\nTestSSL\n    test_delete_not_existing                                     OK    38.36\n    test_duplicate_image_upload                                  OK    12.28\n    test_filtered_images                                         OK    24.49\n    test_get_head_simple_post                                    OK    11.07\n    test_limited_images                                          OK    21.03\n    test_ordered_images                                          OK    8.83\n    test_queued_process_flow                                     OK    9.67\n    test_size_greater_2G_mysql                                   OK    7.24\n    test_traceback_not_consumed                                  OK    5.64\n    test_version_variations                                      OK    19.05\nTestImageDirectURLVisibility\n    test_image_direct_url_not_visible                            OK    8.65\n    test_image_direct_url_visible                                OK    8.52\n    test_v2_enabled                                              OK    5.33\n    test_v2_not_enabled                                          OK    5.62\nTestImageMembers\n    test_image_member_lifecycle                                  OK    26.48\nTestImages\n    test_image_lifecycle                                         OK    8.19\n    test_image_visibility_to_different_users                     OK    19.71\n    test_images_container                                        OK    20.03\n    test_permissions                                             OK    25.56\n    test_tag_lifecycle                                           OK    12.48\nTestSchemas\n    test_resource                                                OK    38.54\nTestRootApi\n    test_version_configurations                                  OK    37.94\n    test_version_variations                                      OK    33.63\nTestBinGlanceCacheManage\n    test_cache_index                                             OK    49.53\n    test_no_cache_enabled                                        OK    15.25\n    test_queue                                                   OK    30.68\nTestGlanceControl\n    test_bouncing                                                OK    38.49\n    test_fallback_pidfile_uncreateable_dir                       OK    21.94\n    test_fallback_pidfile_unwriteable_dir                        OK    11.82\n    test_infinite_child_death                                    OK    30.85\n    test_reload                                                  OK    61.27\n    test_respawn                                                 OK    47.30\nTestImageCacheManageSqlite\n    test_cache_manage_delete_cached_images                       OK    59.28\n    test_cache_manage_get_cached_images                          OK    44.61\n    test_queue_and_prefetch                                      OK    52.89\n    test_user_not_authorized                                     OK    48.53\nTestImageCacheManageXattr\n    test_cache_manage_delete_cached_images                       OK    55.40\n    test_cache_manage_get_cached_images                          OK    28.48\n    test_queue_and_prefetch                                      OK    55.75\n    test_user_not_authorized                                     OK    47.66\nTestImageCacheSqlite\n    test_cache_middleware_transparent_v1                         OK    40.08\n    test_cache_middleware_transparent_v2                         OK    45.23\n    test_cache_remote_image                                      OK    26.25\nTestImageCacheXattr\n    test_cache_middleware_transparent_v1                         OK    56.51\n    test_cache_middleware_transparent_v2                         Build timed out (after 40 minutes). Marking the build as failed.\n++ rm -rf /tmp/tmp.Gba8MRcgua\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 1:  2991 Terminated              tox -e$venv\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise7/9\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<17119A06-B06E-4E82-BEC8-06EFDCE3C0F2@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 01:03:17',0,'2013-10-31 01:03:17',NULL,'[openstack-dev] [Solum] Call for participation: Breakout meeting\n	for API deep-dive','Team,\n\nThose of us interested in participating in a series of API deep-dive design discussions, are encouraged to provide date/time scheduling feedback at the link shown on our Breakout Meetings wiki page:\n\nhttps://wiki.openstack.org/wiki/Solum/BreakoutMeetings\n\nWe look forward to your input to select the date/time of this series. \n\nThanks,\n\nAdrian\n\n',NULL,NULL),('<1712110465.30604847.1407956758449.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 15:05:58',-14400,'2014-08-13 19:05:58',NULL,'[openstack-dev] [all] The future of the integrated release','\n> > At the end of the day, that\'s probably going to mean saying No to more\n> > things. Everytime I turn around everyone wants the TC to say No to\n> > things, just not to their particular thing. :) Which is human nature.\n> > But I think if we don\'t start saying No to more things we\'re going to\n> > end up with a pile of mud that no one is happy with.\n> \n> That we\'re being so abstract about all of this is frustrating. I get\n> that no-one wants to start a flamewar, but can someone be concrete about\n> what they feel we should say \'no\' to but are likely to say \'yes\' to?\n> \n> \n> I\'ll bite, but please note this is a strawman.\n>\n> No:\n> * Accepting any more projects into incubation until we are comfortable with\n> the state of things again\n> * Marconi\n> * Ceilometer\n\nWell -1 to that, obviously, from me.\n\nCeilometer is on track to fully execute on the gap analysis coverage\nplan agreed with the TC at the outset of this cycle, and has an active\nplan in progress to address architectural debt.\n \n> Divert all cross project efforts from the following projects so we can focus\n> our cross project resources. Once we are in a bitter place we can expand our\n> cross project resources to cover these again. This doesn\'t mean removing\n> anything.\n> * Sahara\n> * Trove\n> * Tripleo\n\nYou write as if cross-project efforts are both of fixed size and\namenable to centralized command & control.\n\nNeither of which is actually the case, IMO.\n\nAdditional cross-project resources can be ponied up by the large\ncontributor companies, and existing cross-project resources are not\nnecessarily divertable on command.\n\n> Yes:\n> * All integrated projects that are not listed above\n\nAnd what of the other pending graduation request?\n\nCheers,\nEoghan\n\n\n','<CAHXdxOdAYVbVVCnxY3Ux3h5d0QY-SMsDragH2-1paEyb9U5-9A@mail.gmail.com>',NULL),('<1712227991.11640864.1394119386587.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-03-06 10:23:06',-18000,'2014-03-06 15:23:06',NULL,'[Openstack-operators] OpenStack / Cloud Persona Survey','Hello.  The OpenStack User Experience Team is looking for people using OpenStack or other cloud technologies.  We want to better understand your role and your experience with the cloud.  \n\nWe are looking for people who manage, use and develop applications for the cloud using. We are interested in people who use a GUI, CLI and/or APIs. Most of the activities take about an hour.\n\nPlease complete the following survey if you are interested in participating:\nhttps://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dHl2Qi1QVzdDeVNXUEIyR2h3LUttcGc6MA\n\nThank you,\nThe OpenStack UX Team\nURL: https://wiki.openstack.org/wiki/UX\n\n\n','<1648632485.11640625.1394119355477.JavaMail.zimbra@redhat.com>',NULL),('<1713644060.39796504.1351445780707.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-28 13:36:20',-14400,'2012-10-28 17:36:20',NULL,'[openstack-dev] [Synaps] a more forgiving interpretation of\n	INSUFFICIENT_DATA?','\n\n> If the leeway is clearly quantified, I agree it could make Synaps\n> better for users and operators also. Let\'s do it.\n\nExcellent!\n\n> > Would you be interested in making those changes collaboratively?\n> > \n> > It would be a good learning experience for me, and also perhaps a\n> > useful exercise in community engagement for you guys.\n> \n> I\'m happy to hear that. It\'s surely what we want to.\n\nGreat! Monday is a holiday in Ireland, but I\'ll aim to set up a fully\nfunctional Synaps development environment on Tuesday. Expect to be\nnagged about any issues I encounter as I get all the components up & \nrunning ;) Once I\'m all set up, lets discuss in more detail planning\nout some tasks.\n\nCheers,\nEoghan\n\n\n','<24509036.174661351301632220.JavaMail.weblogic@epml09>',NULL),('<1713837130.4.1376720348189.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-17 06:19:08',0,'2013-08-17 06:19:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/6/>\n\n\n\n','<1527609141.3.1376632944184.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1714050543.23044873.1413331507509.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-14 20:05:07',-14400,'2014-10-15 00:05:07',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','\n\n----- Original Message -----\n> Ok, why are you so down on running systemd in a container?\n> \n> Pacemaker works, but its kind of a pain to setup compared just yum installing\n> a few packages and setting init to systemd. There are some benefits for\n> sure, but if you have to force all the docker components onto the same\n> physical machine anyway, why bother with the extra complexity?\n\nThe other benefit of running systemd in a container is that, at least\nconceptually, it makes the migration path from VMs to docker containers\nthat much easier. If you\'ve got an existing investment in using system\ntools to run your services, it would be awfully nice to be able to keep\nusing that, at least in the short term, as you get your feet wet with\ndocker. Once you\'ve \"seen the light\" and decided that pacemaker is a much\nbetter choice than systemd then you can go port everything over.\n\nI know that using systemd is not the \"docker-way\" but it is a way. \nAnd I think enabling people to gain some benefits of using containers without \nmaking them completely re-architect how they manage their services\nhas some value. \n\nTo me this is akin to letting people run their legacy/non-cloudy apps on \nan IaaS. Are you going to get all the benefits that come from re-architecting \nyour app to be autoscaleable and robust in the face of instance outages?\nNope. But are you going to get some benefits? Yep\n\nCheers\nCharles\n\n> \n> Thanks,\n> Kevin\n> \n> ________________________________________\n> From: David Vossel [dvossel at redhat.com]\n> Sent: Tuesday, October 14, 2014 3:14 PM\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [kolla] on Dockerfile patterns\n> \n> ----- Original Message -----\n> > Same thing works with cloud init too...\n> >\n> >\n> > I\'ve been waiting on systemd working inside a container for a while. it\n> > seems\n> > to work now.\n> \n> oh no...\n> \n> > The idea being its hard to write a shell script to get everything up and\n> > running with all the interactions that may need to happen. The init\n> > system\'s\n> > already designed for that. Take a nova-compute docker container for\n> > example,\n> > you probably need nova-compute, libvirt, neutron-openvswitch-agent, and the\n> > celiometer-agent all backed in. Writing a shell script to get it all\n> > started\n> > and shut down properly would be really ugly.\n> >\n> > You could split it up into 4 containers and try and ensure they are\n> > coscheduled and all the pieces are able to talk to each other, but why?\n> > Putting them all in one container with systemd starting the subprocesses is\n> > much easier and shouldn\'t have many drawbacks. The components code is\n> > designed and tested assuming the pieces are all together.\n> \n> What you need is a dependency model that is enforced outside of the\n> containers. Something\n> that manages the order containers are started/stopped/recovered in. This\n> allows\n> you to isolate your containers with 1 service per container, yet still\n> express that\n> container with service A needs to start before container with service B.\n> \n> Pacemaker does this easily. There\'s even a docker resource-agent for\n> Pacemaker now.\n> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/docker\n> \n> -- Vossel\n> \n> ps. don\'t run systemd in a container... If you think you should, talk to me\n> first.\n> \n> >\n> > You can even add a ssh server in there easily too and then ansible in to do\n> > whatever other stuff you want to do to the container like add other\n> > monitoring and such....\n> >\n> > Ansible or puppet or whatever should work better in this arrangement too\n> > since existing code assumes you can just systemctl start foo;\n> >\n> > Kevin\n> > ________________________________________\n> > From: Lars Kellogg-Stedman [lars at redhat.com]\n> > Sent: Tuesday, October 14, 2014 12:10 PM\n> > To: OpenStack Development Mailing List (not for usage questions)\n> > Subject: Re: [openstack-dev] [kolla] on Dockerfile patterns\n> >\n> > On Tue, Oct 14, 2014 at 02:45:30PM -0400, Jay Pipes wrote:\n> > > With Docker, you are limited to the operating system of whatever the\n> > > image\n> > > uses.\n> >\n> > See, that\'s the part I disagree with.  What I was saying about ansible\n> > and puppet in my email is that I think the right thing to do is take\n> > advantage of those tools:\n> >\n> >   FROM ubuntu\n> >\n> >   RUN apt-get install ansible\n> >   COPY my_ansible_config.yaml /my_ansible_config.yaml\n> >   RUN ansible /my_ansible_config.yaml\n> >\n> > Or:\n> >\n> >   FROM Fedora\n> >\n> >   RUN yum install ansible\n> >   COPY my_ansible_config.yaml /my_ansible_config.yaml\n> >   RUN ansible /my_ansible_config.yaml\n> >\n> > Put the minimal instructions in your dockerfile to bootstrap your\n> > preferred configuration management tool. This is exactly what you\n> > would do when booting, say, a Nova instance into an openstack\n> > environment: you can provide a shell script to cloud-init that would\n> > install whatever packages are required to run your config management\n> > tool, and then run that tool.\n> >\n> > Once you have bootstrapped your cm environment you can take advantage\n> > of all those distribution-agnostic cm tools.\n> >\n> > In other words, using docker is no more limiting than using a vm or\n> > bare hardware that has been installed with your distribution of\n> > choice.\n> >\n> > > [1] Is there an official MySQL docker image? I found 553 Dockerhub\n> > > repositories for MySQL images...\n> >\n> > Yes, it\'s called \"mysql\".  It is in fact one of the official images\n> > highlighted on https://registry.hub.docker.com/.\n> >\n> > > >I have looked into using Puppet as part of both the build and runtime\n> > > >configuration process, but I haven\'t spent much time on it yet.\n> > >\n> > > Oh, I don\'t think Puppet is any better than Ansible for these things.\n> >\n> > I think it\'s pretty clear that I was not suggesting it was better than\n> > ansible.  That is hardly relevant to this discussion.  I was only\n> > saying that is what *I* have looked at, and I was agreeing that *any*\n> > configuration management system is probably better than writing shells\n> > cript.\n> >\n> > > How would I go about essentially transferring the ownership of the RPC\n> > > exchanges that the original nova-conductor container managed to the new\n> > > nova-conductor container? Would it be as simple as shutting down the old\n> > > container and starting up the new nova-conductor container using things\n> > > like\n> > > --link rabbitmq:rabbitmq in the startup docker line?\n> >\n> > I think that you would not necessarily rely on --link for this sort of\n> > thing.  Under kubernetes, you would use a \"service\" definition, in\n> > which kubernetes maintains a proxy that directs traffic to the\n> > appropriate place as containers are created and destroyed.\n> >\n> > Outside of kubernetes, you would use some other service discovery\n> > mechanism; there are many available (etcd, consul, serf, etc).\n> >\n> > But this isn\'t particularly a docker problem.  This is the same\n> > problem you would face running the same software on top of a cloud\n> > environment in which you cannot predict things like ip addresses a\n> > priori.\n> >\n> > --\n> > Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}\n> > Cloud Engineering / OpenStack          | http://blog.oddbit.com/\n> >\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<1A3C52DFCD06494D8528644858247BF088B6E0@EX10MBOX03.pnnl.gov>',NULL),('<1714375.603.1390499829863.JavaMail.thinrichs@change-mac-5.local>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-23 09:57:15',-28800,'2014-01-23 17:57:15',NULL,'[openstack-dev] [neutron] [policy] More conflict resolution','Hi all,\n\nToday on the Neutron-policy IRC, we ran into some issues that we wanted all your feedback on (and as I was writing this note several more occurred to me). It\'s the problem of conflict resolution: different policies making different decisions about what to do.  We have a conflict resolution scheme for when conflicts arise within a single policy, but we have yet to solve the problem of conflicts arising because different policies make different decisions.  The important thing to know is that each policy is attached to a tenant (and a single tenant can have multiple policies).\n\n1) We need conflict resolution for the following scenarios.  Suggestions?\n\n- Two policies for a single tenant have a conflict.\n\n- Two policies for different tenants with different Keystone roles have a conflict.  For example, we expect that admin policies should supersede non-admin policies (i.e. that if the admin policy makes a decision to either allow or drop a packet, then the non-admin\'s policy is ignored; otherwise, the non-admin\'s policy makes the final decision).  Are there other roles we need to think about?\n\n- Two policies for different tenants with the same Keystone roles have a conflict.  For example, if there are two admins whose policies conflict, which one wins?\n\n2) Do we perform conflict resolution at the time policies are created (i.e. at the API level) or do we resolve conflicts more dynamically at run-time?  \n\nTo me, API-level conflict resolution doesn\'t seem like a good option.  Suppose a non-admin writes a perfectly reasonable policy.  Then a month later an admin writes a policy that conflicts with the non-admin policy.  There\'s no way to reject the non-admin\'s policy at this point (and we can\'t reject the admin\'s policy).  It seems the best we can do is inform the non-admin (via email?) that her policy has been overruled.  But if we do that, it may be possible for a tenant to learn what the admin\'s policy is--whether that is a security problem or not I don\'t know.\n\n3) What do we do when roles change, e.g. a non-admin user gets promoted to an admin user or vice versa?  And how do we find out about role changes if the users do not log in after their policies have been created?  That is, role-changes seem to affect the overall policy that is enforced at any point in time and thus role-changes ought to be factored into policy enforcement.  \n\nRole-changes make me even more dubious that API-level conflict resolution is a good choice.\n\n\nHopefully that\'s a reasonable summary.  Others will chime in where not.\n\nThoughts?\nThanks,\nTim\n\n\n','<10035597.598.1390498098918.JavaMail.thinrichs@change-mac-5.local>',NULL),('<1714554.3128031381787691992.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2013-10-14 21:54:51',0,'2013-10-14 21:54:51',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting\n October 18, 2013 - Requested Session','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting October 18, 2013 - Requested Session\nHost: Alan Clark\nDate: Thursday, October 17, 2013\nTime: 4:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00)\nSession number: 922 514 295\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&HMAC=f5f8695f8841b510747721a5bc4065416f20533c&RT=MiM0\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?AT=down&ED=243475827&EF=MA&UUID=1713093867&SHA2=ZlP4vQhaE4dlXtCzk6Cj5KtCw9Kbet44JsLa1MX0AHA%3D&RT=MiM0\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?ED=243475827&UID=1713093867&ORT=MiM0&HMAC=f5f8695f8841b510747721a5bc4065416f20533c\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=243475827&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 922 514 295\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20131014/580963c4/attachment.html>\n\n',NULL,NULL),('<1714572406.24064301.1393802405061.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-02 18:20:05',-18000,'2014-03-02 23:20:05',NULL,'[Openstack-docs] Compute node vs compute node','Hi there, \nI\'ve used \'Compute nodes\' to indicate where the Compute service is hosted. Or rather, I see that it\'s hosting Compute as the defining factor. \nOthers use \'compute nodes\', but we could have one of these without Compute running on it. \n\nCould we nail a convention? This just came up in one of my patches. \n\nthanks, Summer \n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140302/4ef09b9a/attachment.html>\n\n','<CAD0KtVHhRD=JigVjjeNDfbwammm_n7QGwEE-HmpWehEs+EgY2A@mail.gmail.com>',NULL),('<1715903863.44120130.1409849947747.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 12:59:07',-14400,'2014-09-04 16:59:07',NULL,'[openstack-dev] [nova][FFE] websocket-proxy-to-host-security','I would like to request a feature freeze exception for the Websocket Proxy to Host Security.\nThe spec [1] was approved for Nova, and the patches [2] are currently sitting there with one\n+2 (courtesy of @danpb), with a +1 from Jenkins.\n\nFor a TL;DR on the spec, essentially this patch series implements a framework for authenticating\nand encrypting communication between the VNC proxy and the actual compute nodes, and then\nimplements a TLS/x509 driver using that framework.\n\nThe patches don\'t touch much, and are enabled optionally, so they should be relatively \"safe\".\n\nBest Regards,\nSolly Ross\n\n[1] https://review.openstack.org/#/c/115483/\n[2] https://review.openstack.org/#/c/115483/, https://review.openstack.org/#/c/115484/\n\n\n','<803778465.44117862.1409849728689.JavaMail.zimbra@redhat.com>',NULL),('<171635167.8184264.1361560792042.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-22 14:19:52',-18000,'2013-02-22 19:19:52',NULL,'[openstack-qa] On refactoring of base classes/infrastructure','The XML/JSON tests are able to share on the same setUpClass and tearDownClass or on an equivalent thing.\n\nI am not sure about the testresources will be the final solution, but it definitely can be an evolutionary step.\n\nIf we want to use a non default TestSuite it MUST be in tempest, even if it just inherit a base class from testresources. \n\n\n----- Original Message -----\nFrom: \"Christopher Yeoh\" <cyeoh at au1.ibm.com>\nTo: \"All Things QA.\" <openstack-qa at lists.openstack.org>\nSent: Friday, February 22, 2013 1:28:12 PM\nSubject: Re: [openstack-qa] On refactoring of base classes/infrastructure\n\nOn Thu, 21 Feb 2013 04:03:21 +0000\nDaryl Walleck <daryl.walleck at RACKSPACE.COM> wrote:\n> \n> It seems like we could handle some of our complexity through\n> aggregates and breaking things down into smaller pieces. I also think\n> base test classes might not be the right term in some cases, as\n> they\'re really more of high level fixtures. Just my thoughts, but\n> here\'s what I sketched out.\n\nSomething to keep in mind is that if we go the\ntestresources/OptimisingTestSuite route (which I think we are, but I\'d\nlike to know if we do have a consensus for this) then as I understand\nthings we\'ll need to factor out setUpClass and tearDownClass as they are\nnot compatible with OptimisingTestSuite and instead replace them with\nfixtures (there is a testresources.FixtureResource). \n\nThis means we can better share resources across classes but there is\nsome work required to convert what is currently done in setUpClass to\nfixtures. I\'m happy to work on this, I\'d just like to know there is a\nconsensus to do so.\n\nRegards,\n\nChris\n-- \ncyeoh at au.ibm.com\n\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<20130222225812.78675bb8@rockhopper>',NULL),('<1716551899.12.1377853216135.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-30 09:00:15',0,'2013-08-30 09:00:15',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #14','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/14/>\n\n------------------------------------------\n[...truncated 17925 lines...]\n2013-08-30 06:06:15 username =\n2013-08-30 06:06:15 # The above administrative user\'s password\n2013-08-30 06:06:15 password =secret\n2013-08-30 06:06:15 # The above administrative user\'s tenant name\n2013-08-30 06:06:15 tenant_name =\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [image]\n2013-08-30 06:06:15 # This section contains configuration options used when executing tests\n2013-08-30 06:06:15 # against the OpenStack Images API\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The type of endpoint for an Image API service. Unless you have a\n2013-08-30 06:06:15 # custom Keystone service catalog implementation, you probably want to leave\n2013-08-30 06:06:15 # this value as \"image\"\n2013-08-30 06:06:15 catalog_type = image\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The version of the OpenStack Images API to use\n2013-08-30 06:06:15 api_version = 1\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # HTTP image to use for glance http image testing\n2013-08-30 06:06:15 http_image = http://127.0.0.1/\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [network]\n2013-08-30 06:06:15 # This section contains configuration options used when executing tests\n2013-08-30 06:06:15 # against the OpenStack Network API.\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Version of the Neutron API\n2013-08-30 06:06:15 api_version = 2.0\n2013-08-30 06:06:15 # Catalog type of the Neutron Service\n2013-08-30 06:06:15 catalog_type = network\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # A large private cidr block from which to allocate smaller blocks for\n2013-08-30 06:06:15 # tenant networks.\n2013-08-30 06:06:15 tenant_network_cidr = 10.100.0.0/16\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The mask bits used to partition the tenant block.\n2013-08-30 06:06:15 tenant_network_mask_bits = 28\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # If tenant networks are reachable, connectivity checks will be\n2013-08-30 06:06:15 # performed directly against addresses on those networks.\n2013-08-30 06:06:15 tenant_networks_reachable = false\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Id of the public network that provides external connectivity.\n2013-08-30 06:06:15 public_network_id = \n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Id of a shared public router that provides external connectivity.\n2013-08-30 06:06:15 # A shared public router would commonly be used where IP namespaces\n2013-08-30 06:06:15 # were disabled.  If namespaces are enabled, it would be preferable\n2013-08-30 06:06:15 # for each tenant to have their own router.\n2013-08-30 06:06:15 public_router_id = \n2013-08-30 06:06:15 \n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [volume]\n2013-08-30 06:06:15 # This section contains the configuration options used when executing tests\n2013-08-30 06:06:15 # against the OpenStack Block Storage API service\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The type of endpoint for a Cinder or Block Storage API service.\n2013-08-30 06:06:15 # Unless you have a custom Keystone service catalog implementation, you\n2013-08-30 06:06:15 # probably want to leave this value as \"volume\"\n2013-08-30 06:06:15 catalog_type = volume\n2013-08-30 06:06:15 # Number of seconds to wait while looping to check the status of a\n2013-08-30 06:06:15 # volume that is being made available\n2013-08-30 06:06:15 build_interval = 1\n2013-08-30 06:06:15 # Number of seconds to time out on waiting for a volume\n2013-08-30 06:06:15 # to be available or reach an expected status\n2013-08-30 06:06:15 build_timeout = 400\n2013-08-30 06:06:15 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-08-30 06:06:15 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-08-30 06:06:15 # have to be different)\n2013-08-30 06:06:15 multi_backend_enabled = false\n2013-08-30 06:06:15 backend1_name = BACKEND_1\n2013-08-30 06:06:15 backend2_name = BACKEND_2\n2013-08-30 06:06:15 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-08-30 06:06:15 # You should update to reflect those exported by configured backend driver.\n2013-08-30 06:06:15 storage_protocol = iSCSI\n2013-08-30 06:06:15 vendor_name = Open Source\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [object-storage]\n2013-08-30 06:06:15 # This section contains configuration options used when executing tests\n2013-08-30 06:06:15 # against the OpenStack Object Storage API.\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # You can configure the credentials in the compute section\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-08-30 06:06:15 # custom Keystone service catalog implementation, you probably want to leave\n2013-08-30 06:06:15 # this value as \"object-store\"\n2013-08-30 06:06:15 catalog_type = object-store\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Number of seconds to time on waiting for a container to container\n2013-08-30 06:06:15 # synchronization complete\n2013-08-30 06:06:15 container_sync_timeout = 120\n2013-08-30 06:06:15 # Number of seconds to wait while looping to check the status of a\n2013-08-30 06:06:15 # container to container synchronization\n2013-08-30 06:06:15 container_sync_interval = 5\n2013-08-30 06:06:15 # Set to True if the Account Quota middleware is enabled\n2013-08-30 06:06:15 accounts_quotas_available = True\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Set operator role for tests that require creating a container\n2013-08-30 06:06:15 operator_role = Member\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [boto]\n2013-08-30 06:06:15 ssh_user = cirros\n2013-08-30 06:06:15 # This section contains configuration options used when executing tests\n2013-08-30 06:06:15 # with boto.\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # EC2 URL\n2013-08-30 06:06:15 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-08-30 06:06:15 # S3 URL\n2013-08-30 06:06:15 s3_url = http://127.0.0.1:3333\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-08-30 06:06:15 aws_access =\n2013-08-30 06:06:15 aws_secret =\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Image materials for S3 upload\n2013-08-30 06:06:15 # ALL content of the specified directory will be uploaded to S3\n2013-08-30 06:06:15 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # The manifest.xml files, must be in the s3_materials_path directory\n2013-08-30 06:06:15 # Subdirectories not allowed!\n2013-08-30 06:06:15 # The filenames will be used as a Keys in the S3 Buckets\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-08-30 06:06:15 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-08-30 06:06:15 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-08-30 06:06:15 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Instance type\n2013-08-30 06:06:15 instance_type = m1.nano\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # TCP/IP connection timeout\n2013-08-30 06:06:15 http_socket_timeout = 30\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Number of retries actions on connection or 5xx error\n2013-08-30 06:06:15 num_retries = 1\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Status change wait timout\n2013-08-30 06:06:15 build_timeout = 400\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Status change wait interval\n2013-08-30 06:06:15 build_interval = 1\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [orchestration]\n2013-08-30 06:06:15 # Status change wait interval\n2013-08-30 06:06:15 build_interval = 1\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Status change wait timout. This may vary across environments as some some\n2013-08-30 06:06:15 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-08-30 06:06:15 build_timeout = 300\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Instance type for tests. Needs to be big enough for a\n2013-08-30 06:06:15 # full OS plus the test workload\n2013-08-30 06:06:15 instance_type = m1.micro\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Name of heat-cfntools enabled image to use when launching test instances\n2013-08-30 06:06:15 # If not specified, tests that spawn instances will not run\n2013-08-30 06:06:15 #image_ref = ubuntu-vm-heat-cfntools\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # Name of existing keypair to launch servers with. The default is not to specify\n2013-08-30 06:06:15 # any key, which will generate a keypair for each test class\n2013-08-30 06:06:15 #keypair_name = heat_key\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [dashboard]\n2013-08-30 06:06:15 # URL where to find the dashboard home page\n2013-08-30 06:06:15 dashboard_url = http://127.0.0.1/\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # URL where to submit the login form\n2013-08-30 06:06:15 login_url = http://127.0.0.1/auth/login/\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [scenario]\n2013-08-30 06:06:15 # Directory containing image files\n2013-08-30 06:06:15 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # AMI image file name\n2013-08-30 06:06:15 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # ARI image file name\n2013-08-30 06:06:15 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # AKI image file name\n2013-08-30 06:06:15 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # ssh username for the image file\n2013-08-30 06:06:15 ssh_user = cirros\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 # specifies how many resources to request at once. Used for large operations\n2013-08-30 06:06:15 # testing.\"\n2013-08-30 06:06:15 large_ops_number = 0\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [cli]\n2013-08-30 06:06:15 # Enable cli tests\n2013-08-30 06:06:15 enabled = True\n2013-08-30 06:06:15 # directory where python client binaries are located\n2013-08-30 06:06:15 cli_dir = /usr/local/bin\n2013-08-30 06:06:15 # Number of seconds to wait on a CLI timeout\n2013-08-30 06:06:15 timeout = 15\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [service_available]\n2013-08-30 06:06:15 # Whether or not cinder is expected to be available\n2013-08-30 06:06:15 cinder = True\n2013-08-30 06:06:15 # Whether or not neutron is expected to be available\n2013-08-30 06:06:15 neutron = False\n2013-08-30 06:06:15 # Whether or not glance is expected to be available\n2013-08-30 06:06:15 glance = True\n2013-08-30 06:06:15 # Whether or not swift is expected to be available\n2013-08-30 06:06:15 swift = True\n2013-08-30 06:06:15 # Whether or not nova is expected to be available\n2013-08-30 06:06:15 nova = True\n2013-08-30 06:06:15 # Whether or not Heat is expected to be available\n2013-08-30 06:06:15 heat = True\n2013-08-30 06:06:15 # Whether or not horizon is expected to be available\n2013-08-30 06:06:15 horizon = True\n2013-08-30 06:06:15 \n2013-08-30 06:06:15 [stress]\n2013-08-30 06:06:15 # Maximum number of instances to create during test\n2013-08-30 06:06:15 max_instances = 32\n2013-08-30 06:06:15 # Time (in seconds) between log file error checks\n2013-08-30 06:06:15 log_check_interval = 60\n2013-08-30 06:06:15 # The default number of threads created while stress test\n2013-08-30 06:06:15 default_thread_number_per_action=4\n2013-08-30 06:06:15 ++ IFS=\' 	\n2013-08-30 06:06:15 \'\n2013-08-30 06:06:15 ++ set +o errexit\n2013-08-30 06:06:15 ++ init_tempest\n2013-08-30 06:06:15 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-08-30 06:06:15 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-08-30 06:06:15 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-08-30 06:06:15 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-08-30 06:06:15 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1654.g40c1ec4.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n./safe-devstack-vm-gate-wrap.sh: line 441:  2402 Terminated              $GATE_SCRIPT_DIR/devstack-vm-gate.sh\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-193532\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-193532/14\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-193532/14/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-193532/14/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az2-193532/14/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<531590842.10.1377756429737.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1716715584.4580627.1382026887601.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-17 12:21:27',-14400,'2013-10-17 16:21:27',NULL,'[Openstack-docs] Suggestion: Improved styling for \"Replaceable\" in\n	install guide','I was discussing the new install guide with Lars Kellogg-Stedman, and we were discussing how the underlying docbook metadata gets transformed into the final HTML and PDF products.  The idea came of up having some sort of tool tip show up for text tagged with \"replaceable\" to display more information about a particular \"replaceable\" entry.  \n\nFor instance, the \"EXTERNAL_INTERFACE\" replaceable in the networking section could say something to the effect of \"The external interface is the NIC responsible for enabling communication between your networks and the outside world\".\n\nAt the very least, a static tooltip or style that better indicated that something should be replaced with an actual value would perhaps be useful (this could be accomplished pretty trivially in the style sheet for the docs).\n\nWhat do people think?\n\nBest Regards,\nSolly Ross\n\n\n','<295478833.4571469.1382026246527.JavaMail.root@redhat.com>',NULL),('<1717158265.14275764.1405712301725.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-18 15:38:21',-14400,'2014-07-18 19:38:21',NULL,'[openstack-dev] [NOVA] https://review.openstack.org/91486','----- Original Message -----\n> From: \"Arkady Kanevsky\" <Arkady_Kanevsky at DELL.com>\n> To: openstack-dev at lists.openstack.org\n> \n> Why is this blueprint dropped?\n> We really like it to be in the code base.\n> It has been submitted to Icehouse and has been ready for review for more than\n> 2 months.\n> The code is ready for review and we have been using it for a while\n> internally.\n> Thanks,\n> Arkady\n\nThis was discussed in the Nova meeting this week and granted an exception [1] so I believe it\'s currently waiting for John to remove the -2 he added as part of spec approval deadline clean-up and then obviously further core review to confirm it\'s ready to merge.\n\nThanks,\n\n[1] http://eavesdrop.openstack.org/meetings/nova/2014/nova.2014-07-17-21.01.html\n\n\n','<336424C1A5A44044B29030055527AA75049FA46935@AUSX7MCPS301.AMER.DELL.COM>',NULL),('<1717292570.23.1374041299382.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-17 06:08:19',0,'2013-07-17 06:08:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #289','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/289/>\n\n------------------------------------------\n[...truncated 8993 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 204, in test_workflow_finalization\n    self.assertTrue(flow.finalize())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 747, in finalize\n    exceptions.handle(self.request)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 0.90 secs:\n    0.37    RoleAPITests.test_get_default_role\n    0.17    HorizonTests.test_lazy_urls\n    0.14    DataTableTests.test_summation_row\n    0.12    DataTableTests.test_table_action_attributes\n    0.10    NetworkTests.test_subnet_create_post_cidr_inconsistent\n----------------------------------------------------------------------\nRan 350 tests in 5.329s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.xeCZlVN0ZC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/289\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/289/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/289/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<727929300.16.1373954773777.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1718491065.382.1367042790497.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:06:30',0,'2013-04-27 06:06:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-keystone-docs-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal16 in workspace <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/>\nCheckout:periodic-keystone-docs-stable-grizzly / <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/> - hudson.remoting.Channel at 743ca07a:quantal16\nUsing strategy: Default\nLast Built Revision: Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/keystone.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/keystone.git\nCommencing build of Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\nChecking out Revision 5929850979b0ccf348c1b913961d581ccac9732c (origin/stable/grizzly)\n[periodic-keystone-docs-stable-grizzly] $ /bin/bash -xe /tmp/hudson4107143394126998538.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack keystone\n+ org=openstack\n+ project=keystone\n+ [[ -z openstack ]]\n+ [[ -z keystone ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' keystone == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-keystone-docs-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 50847 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-keystone-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal16\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-04-27\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'09157a29-bf53-4f60-880b-e96943bb2171\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'5929850979b0ccf348c1b913961d581ccac9732c\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal16\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50847 166.78.177.214 22\'}\nDownloading/unpacking pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\nNo distributions at all found for pam>=0.1.4 (from -r <https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-keystone-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1718657142.14624047.1408435219984.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-08-19 16:00:09',28800,'2014-08-19 08:00:09',NULL,'[Openstack] [heat][docker] How to mange multi nodes by\n	openstack-heat-docker plugin?','Hi all,\nI want to know heat+docker plugin, how it manages multi nodes which have docker deployed?\nFor example, if I have a template for docker instance, and I have two docker nodes \'dockerA\' and \'dockerB\'(like two hypersiors),\nI want to know which node will be choosed to boot my docker instance?\n\nThanks in advance!\n\n\n2014-08-19 15:40 (UTC+8)\nWangpan\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140819/3f977a3f/attachment.html>\n\n',NULL,NULL),('<1718675964.1868440.1376467523815.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 04:05:23',-14400,'2013-08-14 08:05:23',NULL,'[openstack-dev] [Horizon] The source language of Horizon\n	in	Transifex','Hi Daisy,\n\n\"Ying Chun Guo\" <guoyingc at cn.ibm.com> wrote:\n> Now the source language of Horizon in Transifex is set as en_US, not en. So\n> when pulling the translations\n> from Transifex, there will be some dummy characters in en.po, which will\n> cause errors in unit\n> tests.\n> \n> I don\'t find a way to change the setting in Transifex. I think the only way\n> to fix it is to\n> re-upload the resources with source language setting as en, and delete the\n> existing resources.\n> \n> Please let me know if Horizon development team know the issue and have any\n> plans to fix it. Thanks\n\nWe have a bug open for tracking this, 1179526 [0]. Akihiro Motoki\nsuggested a temporary change that prevents the issues we saw with\nunit tests, which we should implement. I think at this point we\nwere planning on reaching out to our contacts at Transifex (...if\nwe have any?) to see if it would be possible to fix this without\nhaving to delete and recreate the project.\n\nRegards,\n\nJulie\n\n[0] https://bugs.launchpad.net/horizon/+bug/1179526\n\n\n\n','<OF8E38093F.00141577-ON48257BC7.00249203-48257BC7.0024EE45@cn.ibm.com>',NULL),('<1719035822.28713402.1407793566396.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-11 17:46:06',-14400,'2014-08-11 21:46:06',NULL,'[openstack-dev]\n	[tc][ceilometer]	Some	background	on	the	gnocchi	project','\n\n> >> On 8/11/2014 4:22 PM, Eoghan Glynn wrote:\n> >>>> Hi Eoghan,\n> >>>>\n> >>>> Thanks for the note below. However, one thing the overview below does\n> >>>> not\n> >>>> cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged.\n> >>>> Many\n> >>>> folks feel that this technology is a viable solution for the problem\n> >>>> space\n> >>>> discussed below.\n> >>> Great question Brad!\n> >>>\n> >>> As it happens we\'ve been working closely with Paul Dix (lead\n> >>> developer of InfluxDB) to ensure that this metrics store would be\n> >>> usable as a backend driver. That conversation actually kicked off\n> >>> at the Juno summit in Atlanta, but it really got off the ground\n> >>> at our mid-cycle meet-up in Paris on in early July.\n> >> ...\n> >>> The InfluxDB folks have committed to implementing those features in\n> >>> over July and August, and have made concrete progress on that score.\n> >>>\n> >>> I hope that provides enough detail to answer to your question?\n> >> I guess it begs the question, if influxdb will do what you want and it\'s\n> >> open source (MIT) as well as commercially supported, how does gnocchi\n> >> differentiate?\n> > Hi Sandy,\n> >\n> > One of the ideas behind gnocchi is to combine resource representation\n> > and timeseries-oriented storage of metric data, providing an efficient\n> > and convenient way to query for metric data associated with individual\n> > resources.\n> \n> Doesn\'t InfluxDB do the same?\n\nInfluxDB stores timeseries data primarily.\n\nGnocchi in intended to store strongly-typed OpenStack resource\nrepresentations (instance, images, etc.) in addition to providing\na means to access timeseries data associated with those resources.\n\nSo to answer your question: no, IIUC, it doesn\'t do the same thing.\n\nThough of course these things are not a million miles from each\nother, one is just a step up in the abstraction stack, having a\nwider and more OpenStack-specific scope.\n \n> > Also, having an API layered above the storage driver avoids locking in\n> > directly with a particular metrics-oriented DB, allowing for the\n> > potential to support multiple storage driver options (e.g. to choose\n> > between a canonical implementation based on Swift, an InfluxDB driver,\n> > and an OpenTSDB driver, say).\n> Right, I\'m not suggesting to remove the storage abstraction layer. I\'m\n> just curious what gnocchi does better/different than InfluxDB?\n> \n> Or, am I missing the objective here and gnocchi is the abstraction layer\n> and not an influxdb alternative? If so, my apologies for the confusion.\n\nNo worries :)\n\nThe intention is for gnocchi to provide an abstraction over\ntimeseries, aggregation, downsampling and archiving/retention\npolicies, with a number of drivers mapping onto real timeseries\nstorage options. One of those drivers is based on Swift, another\nis in the works based on InfluxDB, and a third based on OpenTSDB\nhas also been proposed.\n\nCheers,\nEoghan\n\n\n','<60A3427EF882A54BA0A1971AE6EF0388A52BAF68@ORD1EXD02.RACKSPACE.CORP>',NULL),('<1719733594.9972513.1411520943685.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-23 21:09:03',-14400,'2014-09-24 01:09:03',NULL,'[openstack-dev] [sahara] Juno release images','\n----- Original Message -----\n> Mike, please, propose a CR to our docs w/ Fedora images when it\'ll be ready.\n\n\nwill do\n\nmike\n\n\n','<CA+GZd782d2DFKyZnBHjig8v=WF1fdk-M8HBcpOp0haOHjLM4GQ@mail.gmail.com>',NULL),('<1719754205.26125727.1375988146091.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-08 11:55:46',-25200,'2013-08-08 18:55:46',NULL,'[openstack-dev] [nova][vmware] a blueprint and bugs needing\n attention','I have a couple things that need some action (they\'re becoming problems).\n\nThis blueprint is not accepted... but the associated patch is merged already! Can we just get the paperwork on this one caught up?\n* https://blueprints.launchpad.net/nova/+spec/vmware-configuration-section\n** https://review.openstack.org/#/c/37539/\n\nThis review has sat for weeks with very few -1\'s and it\'s been in review for months, it really is ready to go:\n* https://review.openstack.org/#/c/30822/\n\nThese patches are also pretty much a slam-dunk for whomever has time to look:\n* https://review.openstack.org/#/c/33504/\n* https://review.openstack.org/#/c/39336/\n\nThanks for your help.\n\n# Shawn Hartsock\n\n\n','<1372851921.26021928.1375983689736.JavaMail.root@vmware.com>',NULL),('<1719769447.335867.1418835864745.JavaMail.yahoo@jws106134.mail.bf1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-17 17:04:24',0,'2014-12-17 17:04:24',NULL,'[openstack-dev] [Neutron][Nova][DHCP] Use case of enable_dhcp\n option when creating a network',' \nThanks for the response, i saw the other thread in the morning. Will use that thread, if i have further questions.\n-Paddu\n\n\n \nFrom: Pasquale Porreca <pasquale.porreca at dektech.com.au>\nReply-To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nDate: Wednesday, December 17, 2014 12:37 AM\nTo: \"openstack-dev at lists.openstack.org\" <openstack-dev at lists.openstack.org>\nSubject: Re: [openstack-dev] [Neutron][Nova][DHCP] Use case of enable_dhcp option when creating a network\n\nJust yesterday I asked a similar question on ML, this is the answer I got:\n\nIn Neutron IP address management and distribution are separated concepts.IP addresses are assigned to ports even when DHCP is disabled. That IP address is indeed used to configure anti-spoofing rules and security groups.\nhttp://lists.openstack.org/pipermail/openstack-dev/2014-December/053069.html\n\nOn 12/17/14 09:15, Padmanabhan Krishnan wrote:\n\nHello,I have a question regarding the enable_dhcp option when creating a network.\n\nWhen a VM is attached to? a network where enable_dhcp is False, I understand that the DHCP namespace is not created for the network and the VM does not get any IP address after it boots up and sends a DHCP Discover.But, I also see that the Neutron port is filled with the fixed IP value from the network pool even though there\'s no DHCP associated with the subnet.?So, for such VM\'s, does one need to statically configure the IP address with whatever Neutron has allocated from the pool?\nWhat exactly is the use case of the above??\nI do understand that for providing public network access to VM\'s, an external network is generally created with enable-dhcp option set to False. Is it only for this purpose?\nI was thinking of a case of external/provider DHCP servers from where VM\'s can get their IP addresses and when one does not want to use L3 agent/DVR. In such cases, one may want to disable DHCP when creating networks. ?Isn\'t this a use-case?\nAppreciate any response or corrections with my above understanding.\n\nThanks,Paddu?\n\n \n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nPasquale Porreca\n\nDEK Technologies\nVia dei Castelli Romani, 22\n00040 Pomezia (Roma)\n\nMobile +39 3394823805\nSkype paskporr\n\n    \n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141217/fa1b8075/attachment.html>\n\n','<954850604.342520.1418835750054.JavaMail.yahoo@jws10604.mail.bf1.yahoo.com>',NULL),('<1720255040.3315584.1376402232434.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-13 09:57:12',-14400,'2013-08-13 13:57:12',NULL,'[openstack-dev] Neutron a quick qpid revert','All of my Neutron tests are failing this morning in SmokeStack. We need a quick revert to fix the qpid RPC implementation:\n\nhttps://review.openstack.org/41689\n\nhttps://bugs.launchpad.net/neutron/+bug/1211778\n\nI figure we may as well revert this quick and then just wait on oslo.messaging to fix the original RPC concern here?\n\nDan\n\n\n','<418730442.3315128.1376402177603.JavaMail.root@redhat.com>',NULL),('<1720323943.43.1378544418418.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-07 09:00:18',0,'2013-09-07 09:00:18',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-stress #18','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stress/18/>\n\n------------------------------------------\n[...truncated 17373 lines...]\n2013-09-07 06:07:11 username =\n2013-09-07 06:07:11 # The above administrative user\'s password\n2013-09-07 06:07:11 password =secret\n2013-09-07 06:07:11 # The above administrative user\'s tenant name\n2013-09-07 06:07:11 tenant_name =\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [image]\n2013-09-07 06:07:11 # This section contains configuration options used when executing tests\n2013-09-07 06:07:11 # against the OpenStack Images API\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The type of endpoint for an Image API service. Unless you have a\n2013-09-07 06:07:11 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-07 06:07:11 # this value as \"image\"\n2013-09-07 06:07:11 catalog_type = image\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The version of the OpenStack Images API to use\n2013-09-07 06:07:11 api_version = 1\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # HTTP image to use for glance http image testing\n2013-09-07 06:07:11 http_image = http://127.0.0.1/\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [network]\n2013-09-07 06:07:11 # This section contains configuration options used when executing tests\n2013-09-07 06:07:11 # against the OpenStack Network API.\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Version of the Neutron API\n2013-09-07 06:07:11 api_version = 2.0\n2013-09-07 06:07:11 # Catalog type of the Neutron Service\n2013-09-07 06:07:11 catalog_type = network\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # A large private cidr block from which to allocate smaller blocks for\n2013-09-07 06:07:11 # tenant networks.\n2013-09-07 06:07:11 tenant_network_cidr = 10.100.0.0/16\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The mask bits used to partition the tenant block.\n2013-09-07 06:07:11 tenant_network_mask_bits = 28\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # If tenant networks are reachable, connectivity checks will be\n2013-09-07 06:07:11 # performed directly against addresses on those networks.\n2013-09-07 06:07:11 tenant_networks_reachable = false\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Id of the public network that provides external connectivity.\n2013-09-07 06:07:11 public_network_id = \n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Id of a shared public router that provides external connectivity.\n2013-09-07 06:07:11 # A shared public router would commonly be used where IP namespaces\n2013-09-07 06:07:11 # were disabled.  If namespaces are enabled, it would be preferable\n2013-09-07 06:07:11 # for each tenant to have their own router.\n2013-09-07 06:07:11 public_router_id = \n2013-09-07 06:07:11 \n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [volume]\n2013-09-07 06:07:11 # This section contains the configuration options used when executing tests\n2013-09-07 06:07:11 # against the OpenStack Block Storage API service\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The type of endpoint for a Cinder or Block Storage API service.\n2013-09-07 06:07:11 # Unless you have a custom Keystone service catalog implementation, you\n2013-09-07 06:07:11 # probably want to leave this value as \"volume\"\n2013-09-07 06:07:11 catalog_type = volume\n2013-09-07 06:07:11 # Number of seconds to wait while looping to check the status of a\n2013-09-07 06:07:11 # volume that is being made available\n2013-09-07 06:07:11 build_interval = 1\n2013-09-07 06:07:11 # Number of seconds to time out on waiting for a volume\n2013-09-07 06:07:11 # to be available or reach an expected status\n2013-09-07 06:07:11 build_timeout = 400\n2013-09-07 06:07:11 # Runs Cinder multi-backend tests (requires 2 backends declared in cinder.conf)\n2013-09-07 06:07:11 # They must have different volume_backend_name (backend1_name and backend2_name\n2013-09-07 06:07:11 # have to be different)\n2013-09-07 06:07:11 multi_backend_enabled = false\n2013-09-07 06:07:11 backend1_name = BACKEND_1\n2013-09-07 06:07:11 backend2_name = BACKEND_2\n2013-09-07 06:07:11 # Protocol and vendor of volume backend to target when testing volume-types.\n2013-09-07 06:07:11 # You should update to reflect those exported by configured backend driver.\n2013-09-07 06:07:11 storage_protocol = iSCSI\n2013-09-07 06:07:11 vendor_name = Open Source\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [object-storage]\n2013-09-07 06:07:11 # This section contains configuration options used when executing tests\n2013-09-07 06:07:11 # against the OpenStack Object Storage API.\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # You can configure the credentials in the compute section\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The type of endpoint for an Object Storage API service. Unless you have a\n2013-09-07 06:07:11 # custom Keystone service catalog implementation, you probably want to leave\n2013-09-07 06:07:11 # this value as \"object-store\"\n2013-09-07 06:07:11 catalog_type = object-store\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Number of seconds to time on waiting for a container to container\n2013-09-07 06:07:11 # synchronization complete\n2013-09-07 06:07:11 container_sync_timeout = 120\n2013-09-07 06:07:11 # Number of seconds to wait while looping to check the status of a\n2013-09-07 06:07:11 # container to container synchronization\n2013-09-07 06:07:11 container_sync_interval = 5\n2013-09-07 06:07:11 # Set to True if the Account Quota middleware is enabled\n2013-09-07 06:07:11 accounts_quotas_available = True\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Set operator role for tests that require creating a container\n2013-09-07 06:07:11 operator_role = Member\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [boto]\n2013-09-07 06:07:11 ssh_user = cirros\n2013-09-07 06:07:11 # This section contains configuration options used when executing tests\n2013-09-07 06:07:11 # with boto.\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # EC2 URL\n2013-09-07 06:07:11 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-09-07 06:07:11 # S3 URL\n2013-09-07 06:07:11 s3_url = http://127.0.0.1:3333\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-09-07 06:07:11 aws_access =\n2013-09-07 06:07:11 aws_secret =\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Image materials for S3 upload\n2013-09-07 06:07:11 # ALL content of the specified directory will be uploaded to S3\n2013-09-07 06:07:11 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # The manifest.xml files, must be in the s3_materials_path directory\n2013-09-07 06:07:11 # Subdirectories not allowed!\n2013-09-07 06:07:11 # The filenames will be used as a Keys in the S3 Buckets\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-09-07 06:07:11 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-09-07 06:07:11 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-09-07 06:07:11 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Instance type\n2013-09-07 06:07:11 instance_type = m1.nano\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # TCP/IP connection timeout\n2013-09-07 06:07:11 http_socket_timeout = 30\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Number of retries actions on connection or 5xx error\n2013-09-07 06:07:11 num_retries = 1\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Status change wait timout\n2013-09-07 06:07:11 build_timeout = 400\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Status change wait interval\n2013-09-07 06:07:11 build_interval = 1\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [orchestration]\n2013-09-07 06:07:11 # Status change wait interval\n2013-09-07 06:07:11 build_interval = 1\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Status change wait timout. This may vary across environments as some some\n2013-09-07 06:07:11 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-09-07 06:07:11 build_timeout = 300\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Instance type for tests. Needs to be big enough for a\n2013-09-07 06:07:11 # full OS plus the test workload\n2013-09-07 06:07:11 instance_type = m1.micro\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Name of heat-cfntools enabled image to use when launching test instances\n2013-09-07 06:07:11 # If not specified, tests that spawn instances will not run\n2013-09-07 06:07:11 #image_ref = ubuntu-vm-heat-cfntools\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # Name of existing keypair to launch servers with. The default is not to specify\n2013-09-07 06:07:11 # any key, which will generate a keypair for each test class\n2013-09-07 06:07:11 #keypair_name = heat_key\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [dashboard]\n2013-09-07 06:07:11 # URL where to find the dashboard home page\n2013-09-07 06:07:11 dashboard_url = http://127.0.0.1/\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # URL where to submit the login form\n2013-09-07 06:07:11 login_url = http://127.0.0.1/auth/login/\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [scenario]\n2013-09-07 06:07:11 # Directory containing image files\n2013-09-07 06:07:11 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # AMI image file name\n2013-09-07 06:07:11 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # ARI image file name\n2013-09-07 06:07:11 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # AKI image file name\n2013-09-07 06:07:11 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # ssh username for the image file\n2013-09-07 06:07:11 ssh_user = cirros\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 # specifies how many resources to request at once. Used for large operations\n2013-09-07 06:07:11 # testing.\"\n2013-09-07 06:07:11 large_ops_number = 0\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [cli]\n2013-09-07 06:07:11 # Enable cli tests\n2013-09-07 06:07:11 enabled = True\n2013-09-07 06:07:11 # directory where python client binaries are located\n2013-09-07 06:07:11 cli_dir = /usr/local/bin\n2013-09-07 06:07:11 # Number of seconds to wait on a CLI timeout\n2013-09-07 06:07:11 timeout = 15\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [service_available]\n2013-09-07 06:07:11 # Whether or not cinder is expected to be available\n2013-09-07 06:07:11 cinder = True\n2013-09-07 06:07:11 # Whether or not neutron is expected to be available\n2013-09-07 06:07:11 neutron = False\n2013-09-07 06:07:11 # Whether or not glance is expected to be available\n2013-09-07 06:07:11 glance = True\n2013-09-07 06:07:11 # Whether or not swift is expected to be available\n2013-09-07 06:07:11 swift = True\n2013-09-07 06:07:11 # Whether or not nova is expected to be available\n2013-09-07 06:07:11 nova = True\n2013-09-07 06:07:11 # Whether or not Heat is expected to be available\n2013-09-07 06:07:11 heat = True\n2013-09-07 06:07:11 # Whether or not horizon is expected to be available\n2013-09-07 06:07:11 horizon = True\n2013-09-07 06:07:11 \n2013-09-07 06:07:11 [stress]\n2013-09-07 06:07:11 # Maximum number of instances to create during test\n2013-09-07 06:07:11 max_instances = 32\n2013-09-07 06:07:11 # Time (in seconds) between log file error checks\n2013-09-07 06:07:11 log_check_interval = 60\n2013-09-07 06:07:11 # The default number of threads created while stress test\n2013-09-07 06:07:11 default_thread_number_per_action=4\n2013-09-07 06:07:11 ++ IFS=\' 	\n2013-09-07 06:07:11 \'\n2013-09-07 06:07:11 ++ set +o errexit\n2013-09-07 06:07:11 ++ init_tempest\n2013-09-07 06:07:11 ++ local base_image_name=cirros-0.3.1-x86_64\n2013-09-07 06:07:11 ++ local image_dir=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-09-07 06:07:11 ++ local kernel=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-vmlinuz\n2013-09-07 06:07:11 ++ local ramdisk=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-initrd\n2013-09-07 06:07:11 ++ local disk_image=/opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec/cirros-0.3.1-x86_64-blank.img\nstress create: /opt/stack/new/tempest/.tox/stress\nstress inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1704.gb3abf9c.zip\nstress runtests: commands[0] | python -m tempest/stress/run_stress -a -d 3600\nBuild timed out (after 180 minutes). Marking the build as failed.\n/tmp/hudson1889618952304855746.sh: line 8:  1718 Terminated              ./safe-devstack-vm-gate-wrap.sh\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-230357\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-230357/18\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-230357/18/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-230357/18/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stress/devstack-precise-hpcloud-az3-230357/18/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1543442868.35.1378361906414.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1720684.YrPHgtedvt@dblinov.sw.ru>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-16 19:49:42',10800,'2014-12-16 16:49:42',NULL,'[openstack-dev] [Nova] question about \"Get Guest Info\" row in\n	HypervisorSupportMatrix','On Tuesday 09 December 2014 18:15:01 Markus Zoeller wrote:\n> > > On Tue, Dec 09, 2014 at 06:33:47PM +0300, Dmitry Guryanov wrote:\n> > > \n> > > Hello!\n> > > \n> > > There is a feature in HypervisorSupportMatrix\n> > > (https://wiki.openstack.org/wiki/HypervisorSupportMatrix) called \"Get\n> \n> Guest\n> \n> > > Info\". Does anybody know, what does it mean? I haven\'t found anything\n> \n> like\n> \n> > > this neither in nova api nor in horizon and nova command line.\n> \n> I think this maps to the nova driver function \"get_info\":\n> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4\n> 054\n> \n> I believe (and didn\'t double-check) that this is used e.g. by the\n> Nova CLI via `nova show [--minimal] <server>` command.\n> \n\nIt seems Driver.get_info used only for obtaining instance\'s power state. It\'s \nstrange. It think we can cleanup the code, rename get_info to get_power_state \nand return only power state from this function.\n\n> I tried to map the features of the hypervisor support matrix to\n> specific nova driver functions on this wiki page:\n> https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DriverAPI\n> \n\nThanks!\n\n> > On Tue Dec 9 15:39:35 UTC 2014, Daniel P. Berrange wrote:\n> > I\'ve pretty much no idea what the intention was for that field. I\'ve\n> > been working on formally documenting all those things, but draw a blank\n> > for that\n> > \n> > FYI:\n> > \n> > https://review.openstack.org/#/c/136380/1/doc/hypervisor-support.ini\n> > \n> > Regards, Daniel\n> \n> Nice! I will keep an eye on that :)\n> \n> \n> Regards,\n> Markus Zoeller\n> IRC: markus_z\n> Launchpad: mzoeller\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-- \nDmitry Guryanov\n\n\n','<OF421A6D10.43AE3EBB-ONC1257DA9.005EA75C-C1257DA9.005EC2A8@de.ibm.com>',NULL),('<1720987854.1082890.1386074927440.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-03 13:48:47',3600,'2013-12-03 12:48:47',NULL,'[Openstack] problem in installing swift dependencies','Hello,\n\nMaybe you need to read this \nhttps://help.ubuntu.com/10.04/serverguide/package-management.html\nand expecially this section :\nhttps://help.ubuntu.com/10.04/serverguide/configuration.html\nYour problem is not related to Swift.\n\nCheers,\n\nFabien Boucher\nOpenStack Engineer\neNovance SaS - 10 rue de la Victoire 75009 Paris - France\n\n----- Original Message -----\nFrom: \"pragya jain\" <prag_2648 at yahoo.co.in>\nTo: \"pragya jain\" <prag_2648 at yahoo.co.in>, \"Jitendra Kumar Bhaskar\" <jitendra.b at pramati.com>\nCc: openstack at lists.openstack.org\nSent: Tuesday, December 3, 2013 11:49:54 AM\nSubject: Re: [Openstack] problem in installing swift dependencies\n\nplease reply sir \n\n---------- \n\npragya jain \n\n\nOn Tuesday, 3 December 2013 3:43 PM, pragya jain <prag_2648 at yahoo.co.in> wrote: \n\n\n\nthanks for the reply jitendra \nI follow the link you mentioned \nbut I got the following error \nMedia change: please insert the disc labeled \n\'Ubuntu 12.04 LTS _Precise Pangolin_ - Release i386 (20120423)\' \nin the drive \'/cdrom/\' and press enter \n\nthe steps I followed are: \npragya at pragya-Aspire-5742:~$ sudo su - \n[sudo] password for pragya: \nroot at pragya-Aspire-5742:~# apt-get install swift openssh-server rsync memcached python-netifaces python-xattr python-memcache \nhttp://paste.openstack.org/show/54338/ \nroot at pragya-Aspire-5742:~# mkdir -p /etc/swift \nroot at pragya-Aspire-5742:~# chown -R swift:swift /etc/swift/ \nroot at pragya-Aspire-5742:~# apt-get install python-software-properties \nhttp://paste.openstack.org/show/54339/ \nroot at pragya-Aspire-5742:~# apt-get update && apt-get dist-upgrade \nhttp://paste.openstack.org/show/54341/ \n\n------------- \n\nplease help \n\n\n\n\nOn Tuesday, 3 December 2013 2:53 PM, Jitendra Kumar Bhaskar <jitendra.b at pramati.com> wrote: \n\n\n\nHi Pragya, \n\nTry to follow http://docs.openstack.org/havana/install-guide/install/apt/content/general-installation-steps-swift.html to setup swift with at-least two nodes, one for proxy and one for storage node. Its running in our test lab with Havana. \n\nRegards \nJitendra Bhaskar \n\n\n\n\n\n\nOn Tue, Dec 3, 2013 at 1:40 PM, pragya jain < prag_2648 at yahoo.co.in > wrote: \n\n\n\nhello all, \n\nI am trying to install and configure swift from a long period, but I am not successful in it till now \nlast time I had installed it using the instructions given at \nhttp://docs.openstack.org/developer/swift/development_saio.html \n\nwhen Setting up scripts for running Swift \nat the command \nroot at arun-Aspire-5742:~# startmain \n\nI got the following error: \nhttp://paste.openstack.org/show/53458/ \nI uninstall ubuntu 12.04 desktop from my system, freshly reinstall it and again try to install and configure swift using same link http://docs.openstack.org/developer/swift/development_saio.html \n\nbut now I get the following error in the starting itself \nhttp://paste.openstack.org/show/54333/ \n\nplease help me in this regard. \n----------- \n\nPragya jain \n\n_______________________________________________ \nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \nPost to : openstack at lists.openstack.org \nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\n\n\n\n\n_______________________________________________ \nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \nPost to : openstack at lists.openstack.org \nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack \n\n\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<1386067794.14959.YahooMailNeo@web193603.mail.sg3.yahoo.com>',NULL),('<1721359506.48.1375682568146.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-05 06:02:47',0,'2013-08-05 06:02:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #126','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/126/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-182672 in workspace <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #213150 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-postgres-stable-grizzly] $ /bin/bash -xe /tmp/hudson2805010110927881903.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-postgres-stable-grizzly] $ /bin/bash -xe /tmp/hudson4125166887861330807.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_POSTGRES=1\n+ DEVSTACK_GATE_POSTGRES=1\n+ export DEVSTACK_GATE_TEMPEST_FULL=1\n+ DEVSTACK_GATE_TEMPEST_FULL=1\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-182672\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-182672/126\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-182672/126/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az1-182672/126/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1722190511.11.1352419949343.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:12:29',0,'2012-11-09 00:12:29',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-diablo #87','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/87/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/>\nCheckout:periodic-swift-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson6962096981376211175.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-diablo/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<172230038.60.1352765530968.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-13 00:12:10',0,'2012-11-13 00:12:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-diablo #91','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/91/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/>\nCheckout:periodic-swift-python26-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/> - hudson.remoting.Channel at 183b7230:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python26-stable-diablo] $ /bin/bash -xe /tmp/hudson4480076128987837324.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py26/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-diablo/91\n[SCP] Copying console log.\n\n\n','<897269990.47.1352679135349.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1722816931.6194730.1353517569993.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-21 12:06:09',-18000,'2012-11-21 17:06:09',NULL,'[openstack-dev] [nova] versioning scheme for\n	consumable	libraries','\n\n> >> In particular, where would that library code live ? In Nova tree ?\n> >> Or in a separate tree under nova\'s responsibility, like\n> >> python-novaclient ?\n> > \n> > The former I think, if feasible, as the library would depend on a\n> > fair chunk of the nova innards, common utils, config options etc.\n> > so wouldn\'t be trivial to split off.\n> > [...]\n> > Now suppose the the *same* versioning was used as you suggest,\n> > would\n> > it still be possible to produce more than one artifact from the\n> > nova\n> > release process (e.g. multiple tarballs, binaries)?\n> \n> It\'s not possible with the current CI setup we have, and I\'d argue\n> it\'s not desirable. It\'s good that a given source tree results in a\n> given source code tarball...\n\nOK.\n \n> Doug seems to have a slightly different vision for option 5, which\n> sounds much more doable to me (external library).\n\nYeah, it was the unpicking of the mutual dependencies between the\nnew library and the nova core that made me a bit leery of completely\nexternalizing it. But if that\'s do-able, then external is probably\nthe way to go.\n \n> >> That option seems to be adding a new corner case\n> >> category of OpenStack project within the \"library\" project type,\n> >> with its own release model...\n> > \n> > Yes, agreed, it does feel like a new thing without a direct\n> > precedent.\n> \n> I fear that when the ML thread favored option 5 it did not really\n> take into account the added complexity on the release side of things\n> (probably my fault for not diving into it earlier). All things\n> considered, it might not be the simplest route.\n\nI guess there other concerns than simplicity influencing that discussion,\nsuch as eliminating long round-trips for the query path (i.e. nova-api-->\nRPC-->nova-compute), also avoiding usage of private internal nova APIs\n(i.e the compute RPC API).\n\nSo while this approach would introduce new complexity to the release\nmanagement side, do you think it\'s a show-stopper level of complexity,\nor a more a give-us-pause-to-ensure-we-really-need-to-do-this level?\n\nCheers,\nEoghan\n\n\n','<50AD0592.8000608@openstack.org>',NULL),('<1723049441.48.1369894406507.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-30 06:13:26',0,'2013-05-30 06:13:26',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #241','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/241/>\n\n\n\n','<1951353079.45.1369808029134.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1723611916.11512743.1378915234871.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-09-11 12:00:34',-14400,'2013-09-11 16:00:34',NULL,'[Openstack-docs] validate.py - images?','----- Original Message -----\n> From: \"Andreas Jaeger\" <aj at suse.com>\n> To: \"Christian Berendt\" <berendt at b1-systems.de>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Wednesday, September 11, 2013 3:52:51 AM\n> Subject: Re: [Openstack-docs] validate.py - images?\n> \n> On 09/11/2013 09:22 AM, Christian Berendt wrote:\n> > On 09/11/2013 09:16 AM, Andreas Jaeger wrote:\n> >> Christian, can\'t we remove the \"href.endswith(\'.xml\')\" condition\n> >> completely?\n> > \n> > That will not change the behaviour. At the moment we scan all XML files\n> > for \"//xi:include\" and if the href attribute contains a modified file\n> > the book is marked as modified and will be built.\n\nIndeed, but as it turns out we probably should remove that condition anyway to pick up includes of samples (like the .conf files) which are not XML files but are included in the same way (xi:include).\n\nThanks,\n\nSteve\n\n\n','<52302153.5050303@suse.com>',NULL),('<172371467.13638018.1392946469841.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-02-20 20:34:29',-18000,'2014-02-21 01:34:29',NULL,'[Openstack-docs] Script to update samples?','In my very last patch, keystone, I saw and used the project\'s sample files. And this is great, no manual updates for the next version. \n\nWill now go back through the other patches, and switch out sample files for project links wherever possible. \nhttp://git.openstack.org/cgit/openstack/keystone/plain/etc/ \nhttp://git.openstack.org/cgit/openstack/glance/plain/etc/ \nhttp://git.openstack.org/cgit/openstack/heat/plain/etc/heat/ \n\nAnd so forth :) \n\ncool schmool, \nSummer \n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n\n> From: \"Anne Gentle\" <anne at openstack.org>\n> To: \"Tom Fifield\" <tom at openstack.org>\n> Cc: openstack-docs at lists.openstack.org\n> Sent: Thursday, February 20, 2014 11:55:15 PM\n> Subject: Re: [Openstack-docs] Script to update samples?\n\n> On Thu, Feb 20, 2014 at 5:08 AM, Tom Fifield < tom at openstack.org > wrote:\n\n> > Hi,\n> \n\n> > With the excellent work Summer has done adding updated (and missing!)\n> > sample\n> > config files to the docs, it got me thinking. Is a future step to this work\n> > making a script that will pull in the files from the source repositories\n> > that we can run every now and again? Now Summer has added the places they\n> > should live to our repo, this might be possible, no?\n> \n\n> I asked a similar question while reviewing -- for keystone, we directly link\n> to the git.openstack.org copy of the sample files in the source repos. I\'d\n> prefer that to pulling in a copy.\n\n> If a project doesn\'t already have sample files, then we\'d need to bring it\n> into ours, and automating makes sense in that case.\n\n> Summer, do you have an inventory or idea of what the possibilities are here?\n\n> Anne\n\n> > Regards,\n> \n\n> > Tom\n> \n\n> > ______________________________ _________________\n> \n> > Openstack-docs mailing list\n> \n> > Openstack-docs at lists. openstack.org\n> \n> > http://lists.openstack.org/ cgi-bin/mailman/listinfo/ openstack-docs\n> \n\n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140220/15429849/attachment-0001.html>\n\n','<CAD0KtVHf6syFxPZ0Gx5WZWvurY7zix3a0BxTHOd3W3XtyAOSJg@mail.gmail.com>',NULL),('<1724449816.2206316.1376506016204.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-08-14 14:46:56',-14400,'2013-08-14 18:46:56',NULL,'[Openstack-docs] programlisting language=\"bash\" or\n language=\"INI\" for config files?','----- Original Message -----\n> From: \"Anne Gentle\" <annegentle at justwriteclick.com>\n> To: \"Steve Gordon\" <sgordon at redhat.com>\n> Cc: \"Andreas Jaeger\" <aj at suse.com>, openstack-docs at lists.openstack.org\n> Sent: Wednesday, August 14, 2013 2:37:37 PM\n> Subject: Re: [Openstack-docs] programlisting language=\"bash\" or language=\"INI\" for config files?\n> \n> On Wed, Aug 14, 2013 at 1:25 PM, Steve Gordon <sgordon at redhat.com> wrote:\n> \n> > ----- Original Message -----\n> > > From: \"Andreas Jaeger\" <aj at suse.com>\n> > > To: openstack-docs at lists.openstack.org\n> > > Sent: Wednesday, August 14, 2013 2:05:29 PM\n> > > Subject: Re: [Openstack-docs] programlisting language=\"bash\" or\n> > language=\"INI\" for config files?\n> > >\n> > > On 08/14/2013 07:13 PM, Steve Gordon wrote:\n> > > > ----- Original Message -----\n> > > >> From: \"Andreas Jaeger\" <aj at suse.com>\n> > > >> To: openstack-docs at lists.openstack.org\n> > > >> Sent: Wednesday, August 14, 2013 12:35:25 PM\n> > > >> Subject: [Openstack-docs] programlisting language=\"bash\" or\n> > language=\"INI\"\n> > > >>         for config files?\n> > > >>\n> > > >> Stephen Gordon asked in reviewing https://review.openstack.org/41861:\n> > > >>\n> > > >> \"Line 146:                                 <programlisting\n> > > >> language=\"bash\">[DEFAULT]\n> > > >> Is bash actually the correct directive for these, I\'m not super\n> > familiar\n> > > >> with clouddocs-maven\'s highlight functionality but other tools I have\n> > > >> worked with have one specifically for the INI file format?\"\n> > > >>\n> > > >> Looking at the wiki, I do not see INI mentioned - and don\'t see it\n> > used\n> > > >> anywhere. So, is there an INI option we should use or should we\n> > continue\n> > > >> using \"bash\"?\n> > >\n> > >\n> > > Diane answered it with this link as part of the review, so \"bash\" is\n> > fine:\n> > >\n> > https://github.com/rackerlabs/clouddocs-maven-plugin/#new-features-and-changes-1\n> > >\n> > > Thanks Diane!\n> >\n> > The other option would be to not provide the language attribute at all,\n> > which is semantically correct and what I see in most examples of INI\n> > content I can find in openstack-manuals. If there\'s an expectation that for\n> > INI files they will always be marked up as Bash then I think it should be\n> > added to the Conventions and applied uniformly:\n> >\n> \n> When you say the INI files you mean nova.conf, cinder.conf, and so on\n> right?\n\nYes, I refer to them as INI files simply because that\'s the syntax they use (intentionally).\n\n> I believe should not be marked language=\"bash\"\n> linenumbering=\"unnumbered\" but simply <programlisting> -- is that okay with\n> everyone?\n\nThat\'s OK with me and mirrors the vast majority of the occurrences I could find in the repository.\n\n> >\n> >\n> > https://wiki.openstack.org/wiki/Documentation/Conventions#Code_or_data_.28block.29\n> \n> \n> Feel free to change this wiki page to reflect the outcome of this\n> discussion, and thanks all for updating it as we shape these conventions.\n\nI\'ll wait for further responses from Andreas, or anyone else for that matter, before doing this.\n\nThanks,\n\nSteve\n\n\n','<CAD0KtVFtvDHs=cuQF73+EwJJBvRH-pajTAAAF67PW0EmG+ESLw@mail.gmail.com>',NULL),('<172464318.34.1375510156105.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-03 06:09:16',0,'2013-08-03 06:09:16',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-python26-stable-folsom #306','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/306/changes>\n\n\n\n','<79660208.20.1375423500586.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1724954681.108.1353976356604.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2012-11-27 00:32:36',0,'2012-11-27 00:32:36',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-full #26','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/26/>\n\n\n\n','<824508911.88.1353889710514.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1725288286.8366266.1364567760252.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-03-29 10:36:00',-14400,'2013-03-29 14:36:00',NULL,'[openstack-dev] [horizon] [*client] WAS\n [Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #178','\"Alan Pevec\" <apevec at gmail.com> wrote:\n> Hi all,\n> \n> horizon stable/folsom started failing after keystoneclient 0.2.3 last\n> good was\n>  https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/168/\n> with keystoneclient 0.2.2.\n> \n> All OpenStack clients are supposed to be backward compatible, so I\'m\n> not sure if the solution here is to lock all client version on\n> stable/* or is Horizon using keystoneclient internals which aren\'t\n> part of stable API?\n\nHi Alan,\n\nThank you for bringing this up, I went and had a look. I don\'t think this is affecting functionality, but only the tests and mox in particular.\n\nThis is the keystoneclient commit that causes the problem:\n\nhttps://github.com/openstack/python-keystoneclient/commit/01735608644a8b71d98f7798ccd6549e4db5de48\n\nin which auth_token started using the @property decorator. Googling around, apparently mox is known not to behave very well with decorators.\n\nThis isn\'t happening on the Horizon master branch thanks to this commit, which explicitly mocks the auth_token:\n\nhttps://github.com/openstack/horizon/commit/1e867700415b17c29056fb55069b6a3e2b22cf1b\n\nI\'m going to file a bug for the error Alan mentioned and backport that patch to Folsom. Let me know if that doesn\'t sound reasonable.\n\nCheers,\n\nJulie\n\n> Cheers,\n> Alan\n> \n> \n> 2013/3/28 OpenStack Jenkins <jenkins at openstack.org>:\n> > See\n> > https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/178/\n> \n> ...snip...\n> \n> 2013-03-28 06:04:01.567 | FAIL: test_get_default_role\n> (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n> 2013-03-28 06:04:01.567 |\n> ----------------------------------------------------------------------\n> 2013-03-28 06:04:01.567 | Traceback (most recent call last):\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/tests/api_tests/keystone_tests.py\",\n> line 76, in test_get_default_role\n> 2013-03-28 06:04:01.568 |     keystoneclient =\n> self.stub_keystoneclient()\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/horizon/test.py\",\n> line 329, in stub_keystoneclient\n> 2013-03-28 06:04:01.568 |     self.keystoneclient =\n> self.mox.CreateMock(keystone_client.Client)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 258, in CreateMock\n> 2013-03-28 06:04:01.568 |     new_mock = MockObject(class_to_mock,\n> attrs=attrs)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 556, in __init__\n> 2013-03-28 06:04:01.568 |     attr = getattr(class_to_mock, method)\n> 2013-03-28 06:04:01.568 |   File\n> \"/home/jenkins/workspace/periodic-horizon-python27-stable-folsom/.tox/py27/local/lib/python2.7/site-packages/mox.py\",\n> line 608, in __getattr__\n> 2013-03-28 06:04:01.568 |     raise UnknownMethodCallError(name)\n> 2013-03-28 06:04:01.568 | UnknownMethodCallError: Method called is\n> not\n> a member of the object: Method called is not a member of the object:\n> auth_token\n> 2013-03-28 06:04:01.568 | >>  raise\n> UnknownMethodCallError(\'auth_token\')\n> \n> ...snip...\n> \n> 2013-03-28 06:04:03.188 | python-keystoneclient==0.2.3\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAGi==UU5GHqnGCCejP2RXya6rLxtC4Ls5PN3di91Oh4D_gC34A@mail.gmail.com>',NULL),('<1725524428.233.1368254825186.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:47:05',0,'2013-05-11 06:47:05',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly-centos6 #11','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly-centos6/11/>\n\n------------------------------------------\n[...truncated 5147 lines...]\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.01\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.30\n    test_quotas_default_values                                   OK    2.59\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.30\n    test_update_quotas_forbidden                                 OK    0.31\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.31\n    test_show_quotas_with_admin                                  OK    0.31\n    test_show_quotas_without_admin_forbidden                     OK    2.70\n    test_update_quotas_forbidden                                 OK    0.21\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.21\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.22\n    test_quotas_default_values                                   OK    0.22\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.23\n    test_quotas_get_tenant_from_request_context                  OK    2.74\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.21\n    test_quotas_limit_check_with_over_quota                      OK    0.23\n    test_quotas_loaded_bad_returns_404                           OK    0.22\n    test_quotas_loaded_right                                     OK    0.22\n    test_show_quotas_with_admin                                  OK    0.22\n    test_show_quotas_with_owner_tenant                           OK    0.23\n    test_show_quotas_without_admin_forbidden_returns_403         OK    2.67\n    test_update_attributes                                       OK    0.21\n    test_update_quotas_with_admin                                OK    0.21\n    test_update_quotas_with_non_integer_returns_400              OK    0.21\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.21\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    0.22\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.21\n    test_list_quotas_with_admin                                  OK    2.65\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.20\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.22\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.22\n    test_quotas_limit_check_with_over_quota                      OK    0.23\n    test_quotas_loaded_bad_returns_404                           OK    2.61\n    test_quotas_loaded_right                                     OK    0.20\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_with_owner_tenant                           OK    0.21\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    0.23\n    test_update_quotas_with_admin                                OK    0.22\n    test_update_quotas_with_non_integer_returns_400              OK    0.22\n    test_update_quotas_with_non_support_resource_returns_400     OK    2.60\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.21\nRootwrapTestCase\n    test_DnsmasqFilter                                           OK    0.00\n    test_DnsmasqNetnsFilter                                      OK    0.00\n    test_IpFilter_netns_add                                      OK    0.00\n    test_IpFilter_netns_delete                                   OK    0.00\n    test_IpFilter_netns_list                                     OK    0.00\n    test_IpFilter_non_netns                                      OK    0.00\n    test_IpNetnsExecFilter_match                                 OK    0.00\n    test_IpNetnsExecFilter_nomatch                               OK    0.00\n    test_KillFilter                                              OK    0.45\n    test_KillFilter_deleted_exe                                  OK    0.00\n    test_KillFilter_no_raise                                     OK    0.00\n    test_ReadFileFilter                                          OK    0.00\n    test_RegExpFilter_match                                      OK    0.00\n    test_RegExpFilter_reject                                     OK    0.00\n    test_match_filter_recurses_exec_command_filter               OK    0.00\n    test_missing_command                                         OK    0.00\n    test_skips                                                   OK    0.00\nRouterServiceInsertionTestCase\n    test_health_monitor_create                                   OK    0.45\n    test_health_monitor_delete_with_router_id                    OK    0.36\n    test_health_monitor_delete_without_router_id                 OK    0.32\n    test_health_monitor_update_with_router_id                    OK    0.29\n    test_health_monitor_update_without_router_id                 OK    0.28\n    test_pool_create                                             OK    0.26\n    test_pool_delete_with_router_id                              OK    0.28\n    test_pool_delete_without_router_id                           OK    0.28\n    test_pool_update_with_router_id                              OK    3.43\n    test_pool_update_without_router_id                           OK    0.26\n    test_router_create_no_service_type_id                        OK    0.22\n    test_router_create_with_service_type_id                      OK    0.22\n    test_router_delete                                           OK    0.24\n    test_router_get                                              OK    0.23\n    test_router_update_with_service_type_id                      OK    0.22\n    test_router_update_without_service_type_id                   OK    0.23\n    test_vip_create                                              OK    0.28\n    test_vip_delete_with_router_id                               OK    0.32\n    test_vip_delete_without_router_id                            OK    0.30\n    test_vip_update_with_router_id                               OK    0.27\n    test_vip_update_without_router_id                            OK    2.70\nSGAgentRpcCallBackMixinTestCase\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSGServerRpcCallBackMixinTestCase\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.44\n    test_security_group_rules_for_devices_ipv4_ingress           OK    0.45\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.49\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.40\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.42\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.49\nSGServerRpcCallBackMixinTestCaseXML\n    test_security_group_rules_for_devices_ipv4_egress            OK    0.43\n    test_security_group_rules_for_devices_ipv4_ingress           OK    2.86\n    test_security_group_rules_for_devices_ipv4_source_group      OK    0.55\n    test_security_group_rules_for_devices_ipv6_egress            OK    0.45\n    test_security_group_rules_for_devices_ipv6_ingress           OK    0.44\n    test_security_group_rules_for_devices_ipv6_source_group      OK    0.54\nSecurityGroupAgentRpcApiTestCase\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.00\nSecurityGroupAgentRpcTestCase\n    test_prepare_and_remove_devices_filter                       OK    0.00\n    test_refresh_firewall                                        OK    0.01\n    test_security_groups_member_not_updated                      OK    0.00\n    test_security_groups_member_updated                          OK    0.01\n    test_security_groups_provider_updated                        OK    0.00\n    test_security_groups_rule_not_updated                        OK    0.00\n    test_security_groups_rule_updated                            OK    0.01\nSecurityGroupServerRpcApiTestCase\n    test_security_group_rules_for_devices                        OK    0.00\nTestSecurityGroupAgentWithIptables\n    test_prepare_remove_port                                     OK    0.05\n    test_security_group_member_updated                           OK    0.10\n    test_security_group_rule_udpated                             OK    0.04\nTestSecurityGroupAgentWithOVSIptables\n    test_prepare_remove_port                                     OK    0.04\n    test_security_group_member_updated                           OK    0.10\n    test_security_group_rule_udpated                             OK    0.04\nTestSecurityGroupExtensionControl\n    test_disable_security_group_extension_iptables_driver        OK    0.00\n    test_disable_security_group_extension_noop_driver            OK    0.00\n    test_firewall_enabled_iptables_driver                        OK    0.00\n    test_firewall_enabled_noop_driver                            OK    0.00\nServiceTypeExtensionTestCase\n    test_create_service_type_adminctx_returns_200                OK    0.10\n    test_create_service_type_nonadminctx_returns_403             OK    0.03\n    test_service_type_create                                     OK    0.03\n    test_service_type_delete                                     OK    0.04\n    test_service_type_get                                        OK    0.02\n    test_service_type_list                                       OK    0.02\n    test_service_type_update                                     OK    0.03\n    test_update_service_type_adminctx_returns_200                OK    0.03\n    test_update_service_type_nonadminctx_returns_403             Build timed out (after 30 minutes). Marking the build as failed.\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 48: 31382 Terminated              tox -e$venv\n+ result=143\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\n++ rm -rf /tmp/tmp.n3DlsWDLf7\n[SCP] Connecting to static.openstack.org\nBabel==0.9.6\nJinja2==2.6\nMako==0.8.0\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==1.3.3\nalembic==0.5.0\namqplib==0.6.1\nanyjson==0.3.3\nargparse==1.2.1\ncliff==1.3.3\ncmd2==0.6.5.1\ncolorama==0.2.5\nconfigobj==4.7.2\ncoverage==3.6\ndiscover==0.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nextras==0.0.3\nfixtures==0.3.12\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkombu==1.0.4\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.3.3\nprettytable==0.7.2\npyparsing==1.5.7\npython-keystoneclient==0.2.3\npython-mimeparse==0.1.4\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-subunit==0.0.11\npyudev==0.16.1\nquantum==jenkins.periodic.quantum.python26.stable.grizzly.centos6.11\nrepoze.lru==0.6\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.3.0\ntermcolor==1.1.0\ntestrepository==0.0.15\ntesttools==0.9.31\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly-centos6/11\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<172553379.565.1367475831247.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-02 06:23:51',0,'2013-05-02 06:23:51',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-nova-python26-stable-folsom-centos6 #2','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/2/>\n\n------------------------------------------\n[...truncated 12586 lines...]\nnova.compute.resource_tracker: INFO: Compute_service record created for aca64d785c7f49f08f17941eb6be1eef \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:51185\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:51185/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19206) wsgi starting up on http://127.0.0.1:51185/\n\nnova.osapi_compute.wsgi.server: INFO: (19206) accepted (\'127.0.0.1\', 52756)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/May/2013 06:18:29] \"GET /v2 HTTP/1.1\" 204 216 0.001063\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-21921939-9cc5-4be3-9c84-b1f1789fba17</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19206) accepted (\'127.0.0.1\', 52757)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x960ef90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x960ef90>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:51185/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2207, in import_key_pair\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-02 06:18:29 19206 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:51185/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/May/2013 06:18:29] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.235990\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 79353bd106d24618b4182d04afea850f \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:58035\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:58035/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (19206) wsgi starting up on http://127.0.0.1:58035/\n\nnova.osapi_compute.wsgi.server: INFO: (19206) accepted (\'127.0.0.1\', 40452)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/May/2013 06:18:29] \"GET /v2 HTTP/1.1\" 204 216 0.001107\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-dcf6ce19-9299-4c3d-b226-eef246d9b6b6</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (19206) accepted (\'127.0.0.1\', 40453)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8f63850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x8f63850>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:58035/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     name)\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/compute/api.py\",> line 2230, in create_key_pair\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/utils.py\",> line 200, in execute\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-05-02 06:18:30 19206 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:58035/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [02/May/2013 06:18:30] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.300965\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.6\nMarkdown==2.3.1\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.3.2\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.3.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\nparamiko==1.10.1\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-quantumclient==2.2.1\nrequests==1.2.0\nsetuptools-git==1.0b1\nsimplejson==3.2.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.yN2Gpwh6Pm\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom-centos6/2\n[SCP] Copying console log.\n\n\n','<1151393717.543.1367389463302.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1727850952.7790642.1412761890423.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-08 05:51:30',-14400,'2014-10-08 09:51:30',NULL,'[openstack-dev] TC Candidacy','\n\nFolks,\n\nI would like to throw my hat into the ring for the upcoming Technical\nCommittee election.\n\nI\'ve been involved in the OpenStack community for nearly three years,\nstarting off by becoming core on glance, before moving my focus mainly\nonto the ceilometer project. Along the way I\'ve landed a smattering of\ncommits across nova, heat, cinder, horizon, neutron, oslo, devstack,\nand openstack-manuals, while contributing to the stable-maint effort\nover multiple cycles.\n\nMore recently, I\'ve served the ceilometer project as PTL over the Juno\ncycle, and will be doing so again for Kilo.\n\nI\'m employed by Red Hat to work primarily upstream, but I also have\nsome perspective on the \"sausage machine\" that operates downstream in\norder to put the technology we produce into the hands of users.\n\nMy motivation in running is to bring more perspective from a smaller\nproject to the deliberations of the TC, which I think already has a\ntonne of large-project and cross-project perspective to draw on.\nBalance is a good and healthy thing :)\n\nAs a community we have a big challenge ahead of us to figure out how\nwe respond to the growing pains that been felt in our governance\nstructure and cross-project resources. This has crystallized around\nthe recent layering and big tent discussions. My own feeling has\nalways been in favor of a big welcoming tent, but I\'m less convinced\nthat a small blessed core is necessarily a corollary of such\ninclusiveness. Before we radically alter the release cycle model\nthat\'s served us relatively well thus far, I think a critical eye\nshould be brought to the proposals; in particular we really need to\nclearly identify the core problems that these proposed changes are\nintended to solve.\n\nAnd so, onwards to the stock questions ...\n\nTopic: OpenStack Mission\n========================\n\nHow do you feel the technical community is doing in meeting the\nOpenStack Mission?\n\nIn all honesty, I would give us an A+ for effort, but more like a B-\nfor execution. In our excitement and enthusiasm to add shiny new\nfeatures, we sometimes take our eye off the ball in terms of what\'s\nneeded to make the lives of our users easier. I\'m as guilty of this as\nanyone else, perhaps even more so. But I think at this stage, it would\nbe of much benefit to our user community if we swung the pendulum\nsomewhat in the other direction, and shifted some focus onto easing\nthe practical challenges of operating our stuff at scale.\n\nTopic: Technical Committee Mission\n==================================\n\nHow do you feel the technical committee is doing in meeting the\ntechnical committee mission?\n\nWell, to be honest, if I thought this couldn\'t be improved, I wouldn\'t\nbe running for election.\n\nOn the one hand, I felt the gap analysis for already-integrated\nprojects was a good and healthy thing, and certainly assisted in\nfocusing resources over Juno on the areas where the TC saw\ndeficiencies.\n\nOn the other hand, I was quite disheartened by how some of the TC\ndiscussions around project status played out. IMO there was a failure\nof due diligence and mentoring. If we continue to have the TC making\nimportant determinations about the future of projects (whether it be\ntheir integrated status or their \"production readiness\"), then I think\nwe need to ensure that the TC keeps itself fully appraised from an\nearlier stage about the direction that the project is taking, and\ngives fair warning when it feels that a project needs a\ncourse-correction.\n\nTopic: Contributor Motivation\n=============================\n\nHow would you characterize the various facets of contributor\nmotivation?\n\nMost of my prior opensource experience was on various Apache projects\nand in contrast it\'s striking that the OpenStack contributor community\nis on the whole more skewed away from pure volunteerism, and towards\ncorporate contributors. By that, I mean contributors who are employed\nby major operators and distributors of OpenStack, where their day-job\nis to go forth and make it better. On balance, this is actually a\nstrength in our community. It certainly aids in the continuity and\nsustainability of effort. It also helps ensure that less glamorous,\nbut ultra-important, efforts such as stable-maint and vulnerability\nmanagement get the attention they deserve.\n\nHowever, despite this skew, I\'m well aware that we\'re building a\n\"broad church\" here. I think we all benefit from active efforts to\nbuild diversity in our contributor community and harness the energy of\ncontributors with all kinds of motivations. Not just because it\'s the\nright-on thing to do, but because it\'s the *smart* thing to do\n... ensuring that we get access to all of the talents, especially from\npreviously under-represented groups. Towards this end, I continue to\nsupport the efforts of programs such as the GNOME OPW and their recent\nmoves towards extending their reach to a wider set of contributor\nbackgrounds.\n\nTopic: Rate of Growth\n=====================\n\nThere is no argument the OpenStack technical community has a\nsubstantial rate of growth. What are some of the consequences of this\nrate?\n\nIt\'s clear that we\'re nearing an inflection point in our growth path,\nwhere the ability of our cross-project concerns to continue scaling up\nto meet the growing demand can no longer be taken for granted.\n\nMy instinct on this is to first examine how we organize those\ncross-project concerns to see if the scalability ceilings can be\nraised, before going down the route of rationing these cross-project\nresources across a smaller set of projects.\n\nTopic: New Contributor Experience\n=================================\n\nHow would you characterize the experience new contributors have\ncurrently?\n\nTo answer this question, I tried to project myself back to my own\njourney up the on-ramp. It was of course a simpler time in terms of\nthe proliferation of projects and services, but the key elements have\nmostly remained the same. \n\nFirstly, the good ...\n\nOne thing I found awesomely useful at the time was the ability to\neasily spin up an entire mini-cloud in a VM and just get my hands\ndirty, attempt to decipher the logs, snoop the messages passing\nbetween services, peek inside the databases and so on. Given that we\nrely on it so heavily in our day-to-day, it\'s easy to forget how\nhelpful devstack really is. I found it a massive leg-up, coming from a\nscenario where setting up any kind of simulacrum of production was\nquite a gnarly task.\n\nI also found refreshing the willingness of various \"old-timers\" to\nanswer my dumb noob questions in a friendly and non-judgemental way.\nWe should never under-value this quality in our community, anyone who\nin a past life has struggled with knowledge-hoarding will attest to\nhow open we are in this respect.\n\nNext, the bad ...\n\nWe have a particular culture on gerrit were newbies sometimes feel\nthey\'re being ignored, or at least that their patches are not getting\nthe timely traction they expect. I know I fell into this trap myself\nback in the day, where I followed up a git push with an almost\nimmediate full-court-press on potential reviewers via IRC. With\npredictably counter-productive results. I think we could better\nserve new contributors by setting more realistic expectations of\nreview turnaround from the very outset.\n\nAnd finally, the ugly ... ;)\n\nAh yes, the old Contributor License Agreement that many of us love to\nhate. TBH being required to sign this was more of an irritation to me\nwhen I first encountered it, but thanks to efforts over the last\ncouple of cycles by some individuals on the TC, I now have a much\nclearer perspective on the real and practical difficulties this\nseemingly unnecessary legalism introduces for some contributors.\nNeedless to relate, I\'d be fully supportive of the TC\'s continuing\nefforts to replace the CLA with the Developer Certificate of Origin.\n\nTopic: Communication\n====================\n\nHow would you describe our current state of communication in the\nOpenStack community?\n\nWe have many \"official\" vectors of communication: the design summit,\nmailing lists, mid-cycle meetups, gerrit, logged IRC meetings and so\non. All of these have their strenghts and weaknesses, but as a\ncommunity we\'re learning to use and filter them quite well, despite\ntheir firehose-like nature.\n\nThere is also an emerging trend for important discussions to be\ninitiated and developed outside of these official channels, e.g. via\nad-hoc discussions and blog posts. This is something I\'m not so\nenthused about, as it\'s harder for such channels to host a two-way\ninclusive conversation.\n\nAlso, as in any technical community that I\'ve ever experienced,\nthere\'s a lot of shared \"tribal knowledge\" sitting in peoples\'\nheads. I\'m as guilty of it as anyone else, perhaps even more\nso. That\'s just what happens day-to-day as the rate of knowledge\naccretion surpasses the time available to codify it. However we all\nneed to try forcing ourselves to take the time to write such nuggets\ndown in a discoverable place, in order to provide a bread-crumb trail\nfor those who come behind us.\n\nTopic: Relationship with the Foundation Board\n=============================================\n\nThe technical committee interacts with the foundation board on several\ndifferent fronts. How would you describe these interactions?\n\nInterestingly, the membership of these two governance structures is\nsomewhat intertwined. Obviously this presents challenges for the\nindividuals involved in both, in ensuring that they can \"swap hats\"\nand context-switch appropriately. But it does at least ensure that the\nboard is not resting in an ivory tower, insulated from the day-to-day\ntechnical leadership. In terms of the practical interactions that I\'ve\nseen, I was heartened by the robust approach of the TC in making their\npreference to switch to the DCO crystal-clear and putting it up to the\nboard to deal with the CLA issue once and for all.\n\nCheers,\nEoghan\n\n\n','<1452738704.7787856.1412761100550.JavaMail.zimbra@redhat.com>',NULL),('<1728221129.22.1383113492263.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-30 06:11:32',0,'2013-10-30 06:11:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #39','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/39/>\n\n------------------------------------------\n[...truncated 1288 lines...]\n    action, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46ec990>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x46ec990>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x44a1f10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x44a1f10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-a8545cd0-41bb-43c8-9530-383b4aefbe89\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:11:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:11:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:11:00+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'00\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:11:00-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'00\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:11:00Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'00\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x54eb310>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x15a66d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 72.07 secs:\n    18.87    TestGlanceControl.test_bouncing\n    14.13    TestGlanceControl.test_reload\n    13.57    TestBinGlanceCacheManage.test_queue\n    12.76    TestApi.test_unsupported_default_store\n    12.74    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 932 tests in 586.450s\n\nFAILED (SKIP=89, failures=3)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-39\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.bnCLIxOiNz\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/39/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-8/39\n[SCP] Copying console log.\n\n\n','<1929062679.19.1382940854537.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<17283B0A-7AE9-4BC2-853C-7E3EBA4973D5@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-10 15:32:24',-18000,'2014-12-10 20:32:24',NULL,'[openstack-dev] [oslo] [taskflow] sprint review day','\nOn Dec 10, 2014, at 2:12 PM, Joshua Harlow <harlowja at outlook.com> wrote:\n\n> Hi everyone,\n> \n> The OpenStack oslo team will be hosting a virtual sprint in the\n> Freenode IRC channel #openstack-oslo for the taskflow subproject on\n> Wednesday 12-17-2014 starting at 16:00 UTC and going for ~8 hours.\n> \n> The goal of this sprint is to work on any open reviews, documentation\n> or any other integration questions, development and so-on, so that we\n> can help progress the taskflow subproject forward at a good rate.\n> \n> Live version of the current documentation is available here:\n> \n> http://docs.openstack.org/developer/taskflow/\n> \n> The code itself lives in the openstack/taskflow respository.\n> \n> http://git.openstack.org/cgit/openstack/taskflow/tree\n> \n> Please feel free to join if interested, curious, or able.\n> \n> Much appreciated,\n> \n> Joshua Harlow\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\nThanks for setting this up, Josh!\n\nThis day works for me. We need to make sure a couple of other Oslo cores can make it that day for the sprint to really be useful, so everyone please let us know if you can make it.\n\nDoug\n\n\n\n','<BLU436-SMTP214E0709B48ADAD9D75CA3D8620@phx.gbl>',NULL),('<1728428210.56.1361859144472.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-26 06:12:24',0,'2013-02-26 06:12:24',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #49','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/49/>\n\n------------------------------------------\n[...truncated 16249 lines...]\n++ field=\'$3\'\n++ echo \'| private network             | 10.1.0.2                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.2\n+ die_if_not_set IP \'Failure retrieving IP address\'\n+ local exitcode=0\n+ set +o xtrace\n+ ping_check private 10.1.0.2 90\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net =~ q- ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.2 90\n+ local from_net=private\n+ local ip=10.1.0.2\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.2; do sleep 1; done\'\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=4.34 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 4.344/4.344/4.344/0.000 ms\n++ cinder list\n++ grep ex-vol-8102bde0\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1361859096\n+ cinder create --display_name ex-vol-8102bde0 --display_description \'test volume: ex-vol-8102bde0\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                false                 |\n|      created_at     |      2013-02-26T06:11:37.090188      |\n| display_description |     test volume: ex-vol-8102bde0     |\n|     display_name    |           ex-vol-8102bde0            |\n|          id         | 54c64c1d-bde4-4a72-b0eb-b68414820542 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-8102bde0 | grep available; do sleep 1; done\'\n| 54c64c1d-bde4-4a72-b0eb-b68414820542 | available | ex-vol-8102bde0 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361859099\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-8102bde0\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 54c64c1d-bde4-4a72-b0eb-b68414820542 | available | ex-vol-8102bde0 |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=54c64c1d-bde4-4a72-b0eb-b68414820542\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for ex-vol-8102bde0\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1361859099\n+ nova volume-attach 9d821580-c1ae-41d6-9408-104fa354692c 54c64c1d-bde4-4a72-b0eb-b68414820542 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | 9d821580-c1ae-41d6-9408-104fa354692c |\n| id       | 54c64c1d-bde4-4a72-b0eb-b68414820542 |\n| volumeId | 54c64c1d-bde4-4a72-b0eb-b68414820542 |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-8102bde0 | grep in-use; do sleep 1; done\'\n| 54c64c1d-bde4-4a72-b0eb-b68414820542 | in-use | ex-vol-8102bde0 |  1   |     None    |  false   | 9d821580-c1ae-41d6-9408-104fa354692c |\n++ date +%s\n+ end_time=1361859104\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-8102bde0\n++ get_field -1\n++ read data\n++ head -1\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 54c64c1d-bde4-4a72-b0eb-b68414820542 | in-use | ex-vol-8102bde0 |  1   |     None    |  false   | 9d821580-c1ae-41d6-9408-104fa354692c |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=9d821580-c1ae-41d6-9408-104fa354692c\n+ die_if_not_set VOL_ATTACH \'Failure retrieving ex-vol-8102bde0 status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 9d821580-c1ae-41d6-9408-104fa354692c != 9d821580-c1ae-41d6-9408-104fa354692c ]]\n++ date +%s\n+ start_time=1361859104\n+ nova volume-detach 9d821580-c1ae-41d6-9408-104fa354692c 54c64c1d-bde4-4a72-b0eb-b68414820542\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-8102bde0 | grep available; do sleep 1; done\'\n| 54c64c1d-bde4-4a72-b0eb-b68414820542 | available | ex-vol-8102bde0 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361859109\n+ echo \'Completed volume-detach in 5 seconds\'\nCompleted volume-detach in 5 seconds\n++ date +%s\n+ start_time=1361859109\n+ cinder delete 54c64c1d-bde4-4a72-b0eb-b68414820542\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-8102bde0; do sleep 1; done\'\n| 54c64c1d-bde4-4a72-b0eb-b68414820542 | deleting | ex-vol-8102bde0 |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1361859112\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete 9d821580-c1ae-41d6-9408-104fa354692c\n+ timeout 60 sh -c \'while nova list | grep -q 9d821580-c1ae-41d6-9408-104fa354692c; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nStarting coverage data collection\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 194, in <module>\n    main(sys.argv)\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 148, in main\n    coverage_client.start_coverage_combine()\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 52, in start_coverage_combine\n    return self.post(\'os-coverage/action\', post_body, self.headers)\n  File \"tempest/common/rest_client.py\", line 178, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 280, in request\n    wait)\n  File \"tempest/common/rest_client.py\", line 357, in _error_checker\n    raise exceptions.ComputeFault(message)\ntempest.exceptions.ComputeFault: Got compute fault\nDetails: The server has either erred or is incapable of performing the requested operation.\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/rabbitmq/rabbit at devstack-1361835129-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/rabbitmq/rabbit at devstack-1361835129.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-swift.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/49/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1728888411.39282605.1409227023433.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-08-28 07:57:03',-14400,'2014-08-28 11:57:03',NULL,'[Openstack-operators] neutron network configuration: linux\n bridges','\n\n----- Original Message -----\n> I found something strange I can\'t solve by myself.\n> \n> Sometimes I getting configuration where VMs traffic get to the gre\n> tunnes via following sequence: tap->qbr->qvb->qvo->br-int->br-tun->eth0.\n> It described here:\n> http://docs.openstack.org/grizzly/openstack-network/admin/content/under_the_hood_openvswitch.html\n> \n> But sometimes I getting very different configuration:\n> tap->br-int->br-tun->eth0. It working, and working fine. And I just\n> can\'t find option or configuration difference, or combination of both\n> which cause switching between \'simple\' and \'normal\' scheme. I feel like\n> I don\'t understand something basic and something important.\n> \n> Any ideas? Thanks!\n> \n\nIt depends on the vif_driver = nova.virt.libvirt.vif.LibvirtGenericVIFDriver\noption in nova.conf.\n\n> _______________________________________________\n> OpenStack-operators mailing list\n> OpenStack-operators at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators\n> \n\n\n','<53FF1791.7010308@gmail.com>',NULL),('<1729167605.1581442.1411728642904.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-26 06:50:42',-14400,'2014-09-26 10:50:42',NULL,'[Openstack] Ceilometer unable to meter LBaaS','\n\n> Hi,\n> \n> I have a requirement to meter LBaaS using Ceilometer.\n> \n> I have installed LBaaS agent on a single node Icehouse and\n> I am able to administer LBaaS via Horizon. I have followed the steps\n> mentioned in\n> http://docs.openstack.org/admin-guide-cloud/content/install_neutron-lbaas-agent.html\n> \n> I have created a Load Balancer and a pool of 2 VMs under the Load Balancer.\n> \n> I am currently not able to get any LBaaS related readings on Ceilometer.\n> \n> My need is to get the LBaaS measurements mentioned in the URL\n> http://docs.openstack.org/developer/ceilometer/measurements.html\n> \n> I came across the URL\n> https://blueprints.launchpad.net/neutron/+spec/lbaas-ceilometer-integration\n> which says that Ceilometer will only be able to measure LBaaS in the Juno\n> release.\n> \n> Kindly let me know if there is a way to get Ceilometer to meter LBaaS.in\n> IceHouse.\n\nWell that feature was only added in the Juno timeframe.\n\nBeing a feature (as opposed to a big-fix) it would not be backported\nto stable/icehouse branch, as per standard backporting policy in the\nOpenStack community.\n\nSo you will need to move to Juno to take advantage of the new feature.\n\nCheers,\nEoghan\n \n> \n> Regards,\n> --\n> Vivek Varghese Cherian (????? ?????? ???????)\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAOVWD3sSc-_J+AGYfAyPvA_38RdRdst8a4e7fwaWQFaMjQxVZQ@mail.gmail.com>',NULL),('<1729404483.187.1366178830050.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-17 06:07:10',0,'2013-04-17 06:07:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #7','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/7/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-17 06:07:04    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-17 06:07:04,736 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-17 06:07:04,737 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-17 06:07:04,738 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,739 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,739 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-17 06:07:04,740 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-17 06:07:04,741 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-17 06:07:04  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-17 06:07:04,742 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-17 06:07:04    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-17 06:07:04,743 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,748 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.748306\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.748306\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04,749 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,751 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,753 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,758 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04,761 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.757807\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.757807\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04,764 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,766 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,768 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-17 06:07:04,769 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,770 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,774 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04,777 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.774377\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.774377\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04,778 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,778 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,779 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-17 06:07:04,780 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,781 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,782 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04,784 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.782741\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.782741\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04,787 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,790 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,792 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-17 06:07:04,794 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,798 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,803 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-17 06:07:04,808 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-17 06:07:04,811 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.807732\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-17T06:07:04.807732\', resource_metadata={}) from 0 transformer\n2013-04-17 06:07:04,814 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,817 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04,820 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-17 06:07:04,822 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-17 06:07:04,825 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-17 06:07:04    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 22.161s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b1\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.8.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.7\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a47.g4793577\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.2.0\nkombu==2.5.10\nlxml==3.1.2\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a316.g964df95\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.2\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.oKvOAMjwc8\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/7\n[SCP] Copying console log.\n\n\n','<1337861760.169.1366092425688.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1729624990.8.1375079212248.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-29 06:26:52',0,'2013-07-29 06:26:52',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #49','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/49/>\n\n------------------------------------------\n[...truncated 22430 lines...]\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep ex-vol-fec49752\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e | available | ex-vol-fec49752 |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e\n+ die_if_not_set 158 VOL_ID \'Failure retrieving volume ID for ex-vol-fec49752\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1375078268\n+ nova volume-attach ca998e6e-f9db-44b7-af04-6bfec953e849 f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | ca998e6e-f9db-44b7-af04-6bfec953e849 |\n| id       | f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e |\n| volumeId | f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-fec49752 | grep in-use; do sleep 1; done\'\n| f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e | in-use | ex-vol-fec49752 |  1   |     None    |  False   | ca998e6e-f9db-44b7-af04-6bfec953e849 |\n++ date +%s\n+ end_time=1375078272\n+ echo \'Completed volume-attach in 4 seconds\'\nCompleted volume-attach in 4 seconds\n++ cinder list\n++ head -1\n++ get_field -1\n++ read data\n++ grep ex-vol-fec49752\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e | in-use | ex-vol-fec49752 |  1   |     None    |  False   | ca998e6e-f9db-44b7-af04-6bfec953e849 |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=ca998e6e-f9db-44b7-af04-6bfec953e849\n+ die_if_not_set 172 VOL_ATTACH \'Failure retrieving ex-vol-fec49752 status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ ca998e6e-f9db-44b7-af04-6bfec953e849 != ca998e6e-f9db-44b7-af04-6bfec953e849 ]]\n++ date +%s\n+ start_time=1375078272\n+ nova volume-detach ca998e6e-f9db-44b7-af04-6bfec953e849 f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-fec49752 | grep available; do sleep 1; done\'\n| f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e | available | ex-vol-fec49752 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375078275\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1375078275\n+ cinder delete f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-fec49752; do sleep 1; done\'\n| f59e3cfd-ee8c-4707-ac94-fb971c1e9c4e | deleting | ex-vol-fec49752 |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1375078278\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete ca998e6e-f9db-44b7-af04-6bfec953e849\n+ timeout 60 sh -c \'while nova list | grep -q ca998e6e-f9db-44b7-af04-6bfec953e849; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1439.g0c8da88.zip\nall runtests: commands[0] | python setup.py testr --slowest\nrunning testr\nNo handlers could be found for logger \"tempest.api.compute.base\"\nNo handlers could be found for logger \"tempest.cli.output_parser\"\nNo handlers could be found for logger \"tempest.cli\"\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpWHjJ8_\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpkuNiXu\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmprKzOue\nrunning=${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpU9L2yA\n======================================================================\nFAIL: tempest.api.compute.admin.test_aggregates.AggregatesAdminTestXML.test_aggregate_add_host_create_server_with_az[gate]\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/admin/test_aggregates.py\", line 213, in test_aggregate_add_host_create_server_with_az\n    availability_zone=az_name)\n  File \"tempest/api/compute/base.py\", line 123, in create_server\n    name, image_id, flavor, **kwargs)\n  File \"tempest/services/compute/xml/servers_client.py\", line 304, in create_server\n    resp, body = self.post(\'servers\', str(Document(server)), self.headers)\n  File \"tempest/common/rest_client.py\", line 258, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 386, in request\n    resp, resp_body)\n  File \"tempest/common/rest_client.py\", line 436, in _error_checker\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {\'message\': \'The requested availability zone is not available\', \'code\': \'400\'}\n======================================================================\nFAIL: tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_create_server_with_az[gate]\ntags: worker-2\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/api/compute/admin/test_aggregates.py\", line 213, in test_aggregate_add_host_create_server_with_az\n    availability_zone=az_name)\n  File \"tempest/api/compute/base.py\", line 123, in create_server\n    name, image_id, flavor, **kwargs)\n  File \"tempest/services/compute/json/servers_client.py\", line 81, in create_server\n    resp, body = self.post(\'servers\', post_body, self.headers)\n  File \"tempest/common/rest_client.py\", line 258, in post\n    return self.request(\'POST\', url, headers, body)\n  File \"tempest/common/rest_client.py\", line 386, in request\n    resp, resp_body)\n  File \"tempest/common/rest_client.py\", line 436, in _error_checker\n    raise exceptions.BadRequest(resp_body)\nBadRequest: Bad request\nDetails: {u\'badRequest\': {u\'message\': u\'The requested availability zone is not available\', u\'code\': 400}}\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\n======================================================================\nFAIL: tempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern\ntags: worker-0\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 133, in test_snapshot_pattern\n    self._create_security_group_rule()\n  File \"tempest/scenario/test_snapshot_pattern.py\", line 84, in _create_security_group_rule\n    **ruleset)\n  File \"/opt/stack/new/python-novaclient/novaclient/v1_1/security_group_rules.py\", line 69, in create\n    \'security_group_rule\')\n  File \"/opt/stack/new/python-novaclient/novaclient/base.py\", line 141, in _create\n    _resp, body = self.api.client.post(url, body=body)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 232, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 213, in _cs_request\n    **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 195, in _time_request\n    resp, body = self.request(url, method, **kwargs)\n  File \"/opt/stack/new/python-novaclient/novaclient/client.py\", line 189, in request\n    raise exceptions.from_response(resp, body, url, method)\nBadRequest: This rule already exists in group 1 (HTTP 400) (Request-ID: req-d1b8afce-d3e4-40d9-bef8-b6a9d0c47fb4)\n======================================================================\nFAIL: process-returncode\ntags: worker-0\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2374 tests in 877.227s\nFAILED (id=0, failures=5, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/rabbitmq/rabbit at devstack-1375074066-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/rabbitmq/rabbit at devstack-1375074066.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/49/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1389608163.3.1374992789520.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<172AF81C-43C5-42E1-B389-00AF74003B99@juniper.net>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-09 18:25:15',0,'2013-10-09 18:25:15',NULL,'[openstack-dev] [neutron] Extraroute and router extensions','Updated the subject [neutron]\n\nHi All,\n\nIs the extra route extension always tied to the router extension or \ncan it live in a separate route-table container. If extra-route routes \nare available in separate container then sharing of such\ncontainers across networks is possible.\n\nAnother reason to remove the dependency would be to have\nnext hops that are not CIDRs. Next-hops should be allowed as\ninterface or a VM instance such as NAT instance. This would\nmake the extra route extension more generic. \n\nThis way an extra-route container can be attached/bound to\neither a router extension or to a network as well. Many plugins\ndo not need a separate router entity for most of the inter-network\nrouting.\n\nThanks,\nRudra\n\n\n\n','<4DE5A043-2CCE-42C4-A212-E2808DDAC291@juniper.net>',NULL),('<17301573-FDA3-46F7-B1AA-1179E4FB0664@stufft.io>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:05:17',-21600,'2014-02-05 17:05:17',NULL,'[openstack-dev] olso.config error on running Devstack','Avoiding namespace packages is a good idea in general. At least until Python 3.whatever is baseline. \n\n> On Feb 5, 2014, at 10:58 AM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:\n> \n> \n> \n> \n>> On Wed, Feb 5, 2014 at 11:44 AM, Ben Nemec <openstack at nemebean.com> wrote:\n>>> On 2014-02-05 09:05, Doug Hellmann wrote:\n>>> \n>>> \n>>>> On Tue, Feb 4, 2014 at 5:14 PM, Ben Nemec <openstack at nemebean.com> wrote:\n>>>> On 2014-01-08 12:14, Doug Hellmann wrote:\n>>>> \n>>>> \n>>>> \n>>>>> On Wed, Jan 8, 2014 at 12:37 PM, Ben Nemec <openstack at nemebean.com> wrote:\n>>>>>> On 2014-01-08 11:16, Sean Dague wrote:\n>>>>>> On 01/08/2014 12:06 PM, Doug Hellmann wrote:\n>>>>>> <snip>\n>>>>>>> Yeah, that\'s what made me start thinking oslo.sphinx should be called\n>>>>>>> something else.\n>>>>>>> \n>>>>>>> Sean, how strongly do you feel about not installing oslo.sphinx in\n>>>>>>> devstack? I see your point, I\'m just looking for alternatives to the\n>>>>>>> hassle of renaming oslo.sphinx.\n>>>>>> \n>>>>>> Doing the git thing is definitely not the right thing. But I guess I got\n>>>>>> lost somewhere along the way about what the actual problem is. Can\n>>>>>> someone write that up concisely? With all the things that have been\n>>>>>> tried/failed, why certain things fail, etc.\n>>>>> The problem seems to be when we pip install -e oslo.config on the system, then pip install oslo.sphinx in a venv.  oslo.config is unavailable in the venv, apparently because the namespace package for o.s causes the egg-link for o.c to be ignored.  Pretty much every other combination I\'ve tried (regular pip install of both, or pip install -e of both, regardless of where they are) works fine, but there seem to be other issues with all of the other options we\'ve explored so far.\n>>>>> \n>>>>> We can\'t remove the pip install -e of oslo.config because it has to be used for gating, and we can\'t pip install -e oslo.sphinx because it\'s not a runtime dep so it doesn\'t belong in the gate.  Changing the toplevel package for oslo.sphinx was also mentioned, but has obvious drawbacks too.\n>>>>> \n>>>>> I think that about covers what I know so far.\n>>>> Here\'s a link dstufft provided to the pip bug tracking this problem: https://github.com/pypa/pip/issues/3\n>>>> Doug\n>>>> This just bit me again trying to run unit tests against a fresh Nova tree.    I don\'t think it\'s just me either - Matt Riedemann said he has been disabling site-packages in tox.ini for local tox runs.  We really need to do _something_ about this, even if it\'s just disabling site-packages by default in tox.ini for the affected projects.  A different option would be nice, but based on our previous discussion I\'m not sure we\'re going to find one.\n>>>> Thoughts?\n>>>  \n>>> Is the problem isolated to oslo.sphinx? That is, do we end up with any configurations where we have 2 oslo libraries installed in different modes (development and \"regular\") where one of those 2 libraries is not oslo.sphinx? Because if the issue is really just oslo.sphinx, we can rename that to move it out of the namespace package.\n>> \n>> oslo.sphinx is the only one that has triggered this for me so far.  I think it\'s less likely to happen with the others because they tend to be runtime dependencies so they get installed in devstack, whereas oslo.sphinx doesn\'t because it\'s a build dep (AIUI anyway).\n> \n> That\'s pretty much what I expected.\n> \n> Can we get a volunteer to work on renaming oslo.sphinx?\n> \n> Doug\n>  \n>>>  \n>>> Doug\n>>>> -Ben\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/1048bd58/attachment.html>\n\n','<CADb+p3RwV0j-JiGYz3_bPEacFMKE_YX=UkXgmbn1AQNK==AQ1g@mail.gmail.com>',NULL),('<1730566263.4689752.1384224704835.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 10:51:42',28800,'2013-11-12 02:51:42',NULL,'[openstack-dev] [nova] How to fix the race condition issue\n between deleting and soft reboot?','Hi John,\n\nI agree with you about that \'terminate should be able to happen at any time.\'\n\nAnd I have checked the terminate_instance and reboot_instance method in compute manager,\nbut they just log a warning while catching the InstanceNotFound exception, nothing else.\n\nAnd last but not least, I believe that the InstanceNotFound exception should not be raised while this race condition occurs,\nbecause the bug https://bugs.launchpad.net/nova/+bug/1246181\njust resulting in an instance going to be a \'running deleted\' one after termination.\n\nI want to re-explain the race condition here:\n1. soft reboot an instance\n2. the \'soft reboot\' thread waits for the instance becoming \'shutdown\' state(this may be a long period if the instance doesn\'t install acpid service)\n3. terminate the instance during step #2\n4. the \'terminate\' thread waits for the instance becoming \'shutdown\' state through a endless loopingcall \'_wait_for_destroy\', too\n4. if the \'soft reboot\' thread finds the instance becomed to \'shutdown\' state firstly, and re-create/restart it before the \'terminate\' thread, then the instance will stick to \'deleting\' status and couldn\'t be deleted again, because the \'terminate\' thread lost itself in the endless loopingcall \'_wait_for_destroy\'(the instance will never become to \'shutdown\' state) and the lock in \'terminate_instance\', this is the bug https://bugs.launchpad.net/nova/+bug/1111213 which has been fixed.\n5. and on the other hand, if the \'terminate\' thread finds the instance becoming to \'shutdown\' state firstly in the loopingcall \'_wait_for_destroy\', and the \'soft reboot\' thread re-create/restart it just before the \'terminate\' thread deletes the instance files in the instance dir(disk, disk.local, libvirt.xml, console.log and so on), then the \'terminate\' thread finishes successfully, the instance is deleted in the nova db, but it is still running in the hypervisor, this is the bug I want to fix this time https://bugs.launchpad.net/nova/+bug/1246181, you can find my FIXME comment here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L924\n\n\n2013-11-12\n\n\n\nWangpan\n\n\n\n????John Garbutt <john at johngarbutt.com>\n?????2013-11-11 20:11\n???Re: [openstack-dev] [nova] How to fix the race condition issue between deleting and soft reboot?\n????\"OpenStack Development Mailing List (not for usage questions)\"<openstack-dev at lists.openstack.org>\n???\n\nIt seems we still agreed that terminate should be able to happen at any time. \n\nI thought I remembered some code in the manager that treats \nInstanceNotFound errors differently. \n\nI would rather we ensure InstanceNotFound is raised to indicate we \nhave hit this race condition, and let the compute manager unify how we \ndeal with that across all sorts of operations. \n\nJohn \n\nOn 11 November 2013 02:57, Wangpan <hzwangpan at corp.netease.com> wrote: \n> Hi all, \n> \n> I want to re-ask this problem after the Hongkong summit, you may have time \n> to discuss this issue now. \n> Thanks a lot! \n> \n> 2013-11-11 \n> ________________________________ \n> Wangpan \n> ________________________________ \n> ????\"Wangpan\"<hzwangpan at corp.netease.com> \n> ?????2013-11-04 12:08 \n> ???[openstack-dev] [nova] How to fix the race condition issue between \n> deleting and soft reboot? \n> ????\"OpenStack Development Mailing List (not for usage \n> questions)\"<openstack-dev at lists.openstack.org> \n> ??? \n> \n> Hi all, \n> \n> I have a question about fixing a race condition issue between deleting and \n> soft reboot, \n> the issue is that: \n> 1. If we soft reboot an instance, and then delete it, the instance may not \n> be deleted and stand on deleting task state, this is because the bug below, \n> https://bugs.launchpad.net/nova/+bug/1111213 \n> and I have fixed this bug yet several months ago(just for libvirt driver). \n> 2. The other issue is, if the instance is rebooted just before deleting the \n> files under instance dir, then it may become to a running deleted one, and \n> this bug is at below: \n> https://bugs.launchpad.net/nova/+bug/1246181 \n> I want to fix it now, and I need your advice. \n> The commit is here: https://review.openstack.org/#/c/54477/ , you can post \n> your advice on gerrit or mail to me. \n> \n> The ways to fix bug #2 may be these(just for libvirt driver in my mind): \n> 1. Add a lock to reboot operation like the deleting operation, so the reboot \n> operation and the delete operation will be done in sequence. \n> But on the other hand, the soft reboot operation may cost 120s if the \n> instance doesn\'t support graceful shutdown, I think it is too long for a \n> user to delete an instance, so this may not be the best way. \n> 2. Check the instance state at the last of _cleanup method in libvirt \n> driver, and if it is still running, destroy it again. \n> This way is usable but both Nikola Dipanov and I don\'t like this \'ugly\' way. \n> 3. Check the instance vm state and task state in nova db before booting in \n> reboot, if it is deleted/deleting, stop the reboot process, this will access \n> db at driver level, it is a \'ugly\' way, too. \n> \n> Nikola suggests that \'maybe we can leverage task/vm states and refactor how \n> reboot is done so we can back out of a reboot on a delete\', but I think we \n> should let user delete an instance at any time and any state, so the delete \n> operation during \'soft reboot\' may not be forbidden. \n> \n> Thanks and waiting for your voice! \n> \n> 2013-11-04 \n> ________________________________ \n> Wangpan \n> \n> _______________________________________________ \n> OpenStack-dev mailing list \n> OpenStack-dev at lists.openstack.org \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n> \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/550c0789/attachment-0001.html>\n\n','<CABib2_rNUjB-6Y=SCsU7-Ksmtps05zshsOd1HvT0xHhRELQoCg@mail.gmail.com>',NULL),('<1731065599.876637.1346436768346.JavaMail.root@zm.isi.edu>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-08-31 11:12:48',-25200,'2012-08-31 18:12:48',NULL,'[openstack-dev] cleaning up an LXC instance fails','\n I still have the following errors: (again, libvirt being used in v.0.9.13)\nI\'ve added the code manually and line number is different.\n\"\"/usr/local/nova/nova/virt/libvirt/driver.py\", line 501\" --> corresponds to line 489 of the patch.\n\n Thanks, \n David\n\n2012-08-31 14:05:58 INFO nova.virt.libvirt.driver [-] [instance: 1eceb9bf-4352-4127-a749-af9b03a865e7] Instance destroyed successfully.\n2012-08-31 14:05:58 ERROR nova.virt.libvirt.driver [req-2bb0bd45-e9f9-4933-893c-1e77d117489e admin admin] [instance: 1eceb9bf-4352-4127-a749-af9b03a865e7] Error from libvirt during undefine. Code=8 Error=unsupported flags (0x1) in function lxcDomainUndefineFlags\n2012-08-31 14:05:58 DEBUG nova.utils [req-2bb0bd45-e9f9-4933-893c-1e77d117489e admin admin] Attempting to grab semaphore \"compute_resources\" for method \"update_load_stats_for_instance\"... from (pid=9164) inner /usr/local/nova/nova/utils.py:708\n2012-08-31 14:05:58 AUDIT nova.compute.resource_tracker [-] free_ram_mb: 13728\n2012-08-31 14:05:58 AUDIT nova.compute.resource_tracker [-] free_disk_gb: 68\n2012-08-31 14:05:58 INFO nova.compute.resource_tracker [-] Compute_service record updated for bespin101 \n2012-08-31 14:05:58 DEBUG nova.manager [-] Running periodic task ComputeManager._poll_rebooting_instances from (pid=9164) periodic_tasks /usr/local/nova/nova/manager.py:170\n2012-08-31 14:05:58 DEBUG nova.manager [-] Skipping ComputeManager._cleanup_running_deleted_instances, 27 ticks left until next run from (pid=9164) periodic_tasks /usr/local/nova/nova/manager.py:165\n2012-08-31 14:05:58 DEBUG nova.manager [-] Running periodic task ComputeManager._check_instance_build_time from (pid=9164) periodic_tasks /usr/local/nova/nova/manager.py:170\n2012-08-31 14:05:58 DEBUG nova.manager [-] Running periodic task ComputeManager._heal_instance_info_cache from (pid=9164) periodic_tasks /usr/local/nova/nova/manager.py:170\n2012-08-31 14:05:58 DEBUG nova.openstack.common.rpc.amqp [-] Making asynchronous call on network ... from (pid=9164) multicall /usr/local/nova/nova/openstack/common/rpc/amqp.py:351\n2012-08-31 14:05:58 DEBUG nova.openstack.common.rpc.amqp [-] MSG_ID is 1aa22c67eb56412c81c12766025a077d from (pid=9164) multicall /usr/local/nova/nova/openstack/common/rpc/amqp.py:354\n2012-08-31 14:05:58 DEBUG nova.utils [req-2bb0bd45-e9f9-4933-893c-1e77d117489e admin admin] Got semaphore \"compute_resources\" for method \"update_load_stats_for_instance\"... from (pid=9164) inner /usr/local/nova/nova/utils.py:712\n2012-08-31 14:05:58 ERROR nova.openstack.common.rpc.amqp [-] Exception during message handling\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last):\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/openstack/common/rpc/amqp.py\", line 275, in _process_data\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/openstack/common/rpc/dispatcher.py\", line 145, in dispatch\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 117, in wrapped\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     temp_level, payload)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/exception.py\", line 92, in wrapped\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     return f(*args, **kw)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 211, in decorated_function\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     pass\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 204, in decorated_function\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 184, in decorated_function\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 237, in decorated_function\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     instance_uuid, e, sys.exc_info())\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/contextlib.py\", line 23, in __exit__\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self.gen.next()\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 226, in decorated_function\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     return function(self, context, *args, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 955, in terminate_instance\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     do_terminate_instance(instance)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/utils.py\", line 733, in inner\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     retval = f(*args, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 947, in do_terminate_instance\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self._delete_instance(context, instance)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 917, in _delete_instance\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self._shutdown_instance(context, instance)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/compute/manager.py\", line 881, in _shutdown_instance\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     block_device_info)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/virt/libvirt/driver.py\", line 477, in destroy\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     self._cleanup(instance, network_info, block_device_info)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/local/nova/nova/virt/libvirt/driver.py\", line 501, in _cleanup\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     libvirt.VIR_DOMAIN_UNDEFINE_MANAGED_SAVE)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/eventlet/tpool.py\", line 187, in doit\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     result = proxy_call(self._autowrap, f, *args, **kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/eventlet/tpool.py\", line 147, in proxy_call\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     rv = execute(f,*args,**kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib/python2.6/site-packages/eventlet/tpool.py\", line 76, in tworker\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     rv = meth(*args,**kwargs)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp   File \"/usr/lib64/python2.6/site-packages/libvirt.py\", line 1608, in undefineFlags\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp     if ret == -1: raise libvirtError (\'virDomainUndefineFlags() failed\', dom=self)\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp libvirtError: unsupported flags (0x1) in function lxcDomainUndefineFlags\n2012-08-31 14:05:58 TRACE nova.openstack.common.rpc.amqp\n\n\n----- Original Message -----\n> On 08/30/2012 11:18 PM, David Kang wrote:\n> >\n> >  Reported as a bug\n> >\n> > https://bugs.launchpad.net/nova/+bug/1044090\n> \n> I\'ve submitted a possible fix for this,\n> https://review.openstack.org/#/c/12274/\n> https://review.openstack.org/#/c/12275/\n> \n> undefineFlags is supported by the LXC driver and was implemented in\n> vibvirt 0.9.4\n> \n> I tested this on KVM but don\'t have LXC setup so would appreciated it\n> anybody could verify it using LXC\n> \n> thanks,\n> Derek.\n\n\n','<5040FAB9.7050309@redhat.com>',NULL),('<1731140587.6.1381730558191.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-14 06:02:38',0,'2013-10-14 06:02:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python27-stable-grizzly #32','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/32/>\n\n------------------------------------------\n[...truncated 4904 lines...]\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:02:33.582277\', resource_metadata={}) from 0 transformer\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:02:33    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:02:33.584462\', resource_metadata={}) from 0 transformer\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:02:33    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:02:33.587784\', resource_metadata={}) from 0 transformer\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:02:33    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:02:33.591577\', resource_metadata={}) from 0 transformer\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:02:33     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:02:33    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:02:33.595522\', resource_metadata={}) from 0 transformer\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:02:33    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 41, in test_keystone_middleware_conf\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nceilometer.storage: DEBUG: looking for \'mongodb\' driver in \'ceilometer.storage\'\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'sqlite = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'postgresql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'log = ceilometer.storage.impl_log:LogStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mongodb = ceilometer.storage.impl_mongodb:MongoDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mysql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'test = ceilometer.storage.impl_test:TestDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'hbase = ceilometer.storage.impl_hbase:HBaseStorage\')\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.d0yxHss9MC/keystone-signing-Tp0UzV as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 51, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 42, in test_keystone_middleware_conf\n    self.assertEqual(api_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.d0yxHss9MC/keystone-signing-JwBrEn as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 52, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\n2013-10-14 06:02:23     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-14 06:02:23     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-14 06:02:23  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-14 06:02:23  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-14 06:02:23     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.d0yxHss9MC/keystone-signing-21a9ET as cache directory for signing certificate\n2013-10-14 06:02:23     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.d0yxHss9MC/keystone-signing-21a9ET as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 15.277s\n\nFAILED (SKIP=290, errors=4)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> --no-path-adjustment\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.7.1\nMako==0.9.0\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b5\nWebOb==1.2.3\nWebTest==2.0.9\nWerkzeug==0.9.4\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\nboto==2.14.0\nceilometer==jenkins.periodic.ceilometer.python27.stable.grizzly.32\ncffi==0.7.2\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.7\ndecorator==3.4.0\ndnspython==1.11.1\ndocutils==0.9.1\necdsa==0.9\neventlet==0.14.0\nextras==0.0.3\nglance==2013.1\ngreenlet==0.4.1\nhappybase==0.6\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.1\nnumpy==1.7.1\noslo.config==1.2.1\nparamiko==1.12.0\npasslib==1.6.1\npbr==0.5.21\npecan==0.4.2\nprettytable==0.7.2\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycparser==2.10\npycrypto==2.6\npymongo==2.6.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-spidermonkey==0.0.10\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplegeneric==0.8.1\nsimplejson==3.3.1\nsingledispatch==3.4.0.2\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\nswift==1.9.1\nthrift==0.9.1\nunittest2==0.5.1\nwaitress==0.8.7\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.d0yxHss9MC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python27-stable-grizzly/precise38/32\n[SCP] Copying console log.\n\n\n','<1210958928.2.1381557861406.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<17312274.921361349954020241.JavaMail.weblogic@epml01>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-10-11 11:13:40',0,'2012-10-11 11:13:40',NULL,'[openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API','Hi, Steve.\n\nAll metrics in Synaps only can be pushed via API. Agents should know their credentials to make signature for every API call by AWS Signature v2 [1]. To do that, the credentials should be deployed inside the instance. Synaps still has the problem that you are pointed out. I hope that we could find out a better way for this.\n\n[1] http://docs.amazonwebservices.com/general/latest/gr/signature-version-2.html\n\nThank you,\nJune Yi\n\n\n------- Original Message -------\nSender : Steven Hardy<shardy at redhat.com> \nDate   : 2012-10-11 16:49 (GMT+09:00)\nTitle  : Re: [openstack-dev] Introducing Synaps project that provides AWS\n CloudWatch compatible API\n\nOn Thu, Oct 11, 2012 at 05:53:32AM +0000, Deok-June Yi wrote:\n> Hi Sam,\n> \n> > Maybe it\'s related to this in the wiki: http://wiki.openstack.org/ResourceMonitorAlertsandNotifications and related BP: https://blueprints.launchpad.net/openstack-devops/+spec/resource-monitor-alerts-and-notifications \n> > \n> > Not sure if anybody started working on that. Hope it helps.\n> >\n> \n> I thought that it would be better to implement another seperated project rather than inside of Nova.\n> \n> Hi Doug,\n> \n> > Ceilometer collects data for use by a billing system, but it is not itself a billing system. It sounds like Synaps collects metrics far more frequently than ceilometer does.\n> > \n> > Can you share a list of the things Synaps measures?\n> >\n> \n> Thank you for your corrections, Doug. \n> \n> Synaps can collect any metric if its value can be represented in double type just like AWS CloudWatch can. \n> \n> - Currently we have Synaps agent so called VMMON that gets following metrics, CPUUtilization, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes, NetworkIn and NetworkOut from hypervisors and send them to Synaps.\n> - If you have cloud service such as LBaaS or DBaaS, you can provide their metrics to your users easily by implementing an agent using Synaps API.\n> - Users can also put their own custom metrics from in-instance.\n\nCan you please provide more details on how your in-instance monitoring\nworks?\n\nI assume you have an in instance agent (similar to cfn-push-stats?), which\npushes metrics via your cloudwatch API?\n\nOr is it pushing data directly to your data-collection \"engine\"?\n\nIn either case, how do you handle authentication to ensure data collected\nfrom inside the instances cannot be faked, and also to limit the scope for\nattack should a single instance be compromised?\n\nI am currently working on this problem for the heat project, and we are\nfiguring out how to get our cfn-push-stats to (securely) send data via our\ncloudwatch API - a big problem is ensuring whatever credentials are deployed\ninside the instance to authenticate with the API are sufficiently\nunprivileged/separated to contain damage from any potential instance\ncompromise.\n\n-- \nSteve Hardy\nRed Hat Engineering, Cloud\n\n',NULL,NULL),('<1731562502.49410005.1414156784878.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-24 09:19:44',-14400,'2014-10-24 13:19:44',NULL,'[openstack-dev] [neutron] [stable] Tool to aid in scalability\n problems mitigation.','Thanks for your feedback too Ihar, comments inline.\n\n----- Original Message -----\n> -----BEGIN PGP SIGNED MESSAGE-----\n> Hash: SHA512\n> \n> On 24/10/14 11:56, Miguel Angel Ajo Pelayo wrote:\n> > \n> > \n> > ----- Original Message -----\n> >> Hi Miguel,\n> >> \n> >> while we\'d need to hear from the stable team, I think it\'s not\n> >> such a bad idea to make this tool available to users of pre-juno\n> >> openstack releases.\n> \n> It\'s a great idea actually. It\'s great when code emerged from real\n> life downstream support cases eventually flow up to upstream for all\n> operator\'s benefit (and not just those who pay huge money for\n> commercial service).\n> \n> >> As far as upstream repos are concerned, I don\'t know if this tool\n> >> violates the criteria for stable branches. Even if it would be a\n> >> rather large change for stable/icehouse, it is pretty much\n> >> orthogonal to the existing code, so it could be ok. However,\n> >> please note that stable/havana has now reached its EOL, so there\n> >> will be no more stable release for it.\n> > \n> > Sure, I was mentioning havana as affected, but I understand it\'s\n> > already under U/S EOL, D/S distributions would always be free to\n> > backport, specially on an orthogonal change like this.\n> > \n> > About stable/icehouse, I\'d like to hear from the stable\n> > maintainers.\n> \n> I\'m for inclusion of the tool in the main neutron package. Though it\'s\n> possible to publish it on pypi as a separate package, I would better\n> apply formal review process to it, plus reduce packaging efforts for\n> distributions (and myself). The tool may be later expanded for other\n> useful operator hooks, so I\'m for inclusion of the tool in master and\n> backporting it back to all supported branches.\n> \n> Though official stable maintainership rules state that \'New features\'\n> are no-go for stable branch [1], I think they should not apply in this\n> case since the tool does not touch production code in any way and just\n> provides a way to heal security groups on operator demand. Also, rules\n> are to break them. ;) Quoting the same document, \"Proposed backports\n> breaking any of above guidelines can be discussed as exception\n> requests on openstack-stable-maint list where stable-maint team will\n> try to reach consensus.\"\n> \n> Operators should be more happy if we ship such a tool as part of\n> neutron release and not as another third-party tool from pypi of\n> potentially unsafe origin.\n> \n> BTW I wonder whether the tool can be useful for Juno+ setups too.\n> Though we mostly mitigated the problem by RPC interface rework and\n> ipset, some operators may still hit some limitation that could be\n> workarounded by optimizing their rules. Also, I think the idea of\n> having a tool with miscellaneous operator hooks in the master tree is\n> quite interesting. I would recommend to still go with pushing it to\n> master and then backporting to stable branches. That would also help\n> to get more review attention from cores than stable branch requests\n> usually receive. ;)\n\n\nI believe the tool could also be expanded to report and , equally generate\nscripts to cleanup orphaned resources, those happen to be when\nyou remove an instance and the port is not deleted, or you delete a \ntenant, but the resources are kept, etc.\n\nI know there are efforts to do proper cleanup when tenants are deleted,\nbut still, I see production databases plagued of orphaned resources. \n\n> \n> [1]: https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes\n> \n> > \n> >> \n> >> The orthogonal nature of this tool however also make the case for\n> >> making it widely available on pypi. I think it should be ok to\n> >> describe the scalability issue in the official OpenStack Icehouse\n> >> docs and point out to this tool for mitigation.\n> > \n> > Yes, of course, I consider that as a second option, my point here\n> > is that direct upstream review time would result in better quality\n> > code here, and could certainly spot any hidden bugs, and increase\n> > testing quality.\n> > \n> > It also reduces packaging time all across distributions making it\n> > available via the standard neutron repository.\n> > \n> > \n> > Thanks for the feedback!,\n> > \n> >> \n> >> Salvatore\n> >> \n> >> On 23 October 2014 14:03, Miguel Angel Ajo Pelayo <\n> >> mangelajo at redhat.com > wrote:\n> >> \n> >> \n> >> \n> >> \n> >> Recently, we have identified clients with problems due to the bad\n> >> scalability of security groups in Havana and Icehouse, that was\n> >> addressed during juno here [1] [2]\n> >> \n> >> This situation is identified by blinking agents (going UP/DOWN),\n> >> high AMQP load, nigh neutron-server load, and timeout from\n> >> openvswitch agents when trying to contact neutron-server\n> >> \"security_group_rules_for_devices\".\n> >> \n> >> Doing a [1] backport involves many dependent patches related to\n> >> the general RPC refactor in neutron (which modifies all\n> >> plugins), and subsequent ones fixing a few bugs. Sounds risky to\n> >> me. [2] Introduces new features and it\'s dependent on features\n> >> which aren\'t available on all systems.\n> >> \n> >> To remediate this on production systems, I wrote a quick tool to\n> >> help on reporting security groups and mitigating the problem by\n> >> writing almost-equivalent rules [3].\n> >> \n> >> We believe this tool would be better available to the wider\n> >> community, and under better review and testing, and, since it\n> >> doesn\'t modify any behavior or actual code in neutron, I\'d like\n> >> to propose it for inclusion into, at least, Icehouse stable\n> >> branch where it\'s more relevant.\n> >> \n> >> I know the usual way is to go master->Juno->Icehouse, but at this\n> >> moment the tool is only interesting for Icehouse (and Havana),\n> >> although I believe it could be extended to cleanup orphaned\n> >> resources, or any other cleanup tasks, in that case it could make\n> >> sense to be available for K->J->I.\n> >> \n> >> As a reference, I\'m leaving links to outputs from the tool\n> >> [4][5]\n> >> \n> >> Looking forward to get some feedback, Miguel ?ngel.\n> >> \n> >> \n> >> [1] https://review.openstack.org/#/c/111876/ security group rpc\n> >> refactor [2] https://review.openstack.org/#/c/111877/ ipset\n> >> support [3] https://github.com/mangelajo/neutrontool [4]\n> >> http://paste.openstack.org/show/123519/ [5]\n> >> http://paste.openstack.org/show/123525/\n> >> \n> >> _______________________________________________ OpenStack-dev\n> >> mailing list OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >>\n> >>\n> >> \n> _______________________________________________\n> >> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >\n> >> \n> > _______________________________________________ OpenStack-dev\n> > mailing list OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> -----BEGIN PGP SIGNATURE-----\n> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)\n> \n> iQEcBAEBCgAGBQJUSjIHAAoJEC5aWaUY1u57dUsH/0hs0OUJQYJJ5Ll/DbT8BgnD\n> sQvYMVVzVQDKU58qLYT0j03+TfdPOHcPrQ9q0/Oi2kzzpAsFS9/ZY/apIX9ztvbQ\n> BkCQ8tubQEy8v7gpaUgxP6tREY36g0lLWpO9D2YhNXMhzlugzbgME5s6NEa3yrNM\n> sXQJH9F3KpsppNtBdlUNImvcNB4xOD2IY6nQMbPTBX9CXY2y7pLDLYZchVXlexuB\n> S5lRKuKN3E6N9uGOUGeAqfGT0ghJZyUFNNsSuNG9H4338jXQFayGHjKiJsde8tK1\n> IyOYMNT9sULMpDlrVjh0+u9YZyV5bKQTjM/ldbjoRM/he1scTxe2XWe1xO4lmfY=\n> =0r7e\n> -----END PGP SIGNATURE-----\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>\n\n\n','<544A3207.30601@redhat.com>',NULL),('<1731702539.22286602.1379351442403.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-16 13:10:42',-14400,'2013-09-16 17:10:42',NULL,'[openstack-dev] Issues with IPTables','In a enfort to improve/verify the Openstack Documentation with regards to RHEL and Fedora, I\'ve been attempting to follow the basic install guides.  I\'ve managed to create a working installation and set of instructions.  However, to do so I needed to disable the Neutron IPTables firewall, as it was blocking non-VM traffic.  Namely, it was blocking the GRE packets being used by Neutron.  Did I miss something, or is this a bug?\n\nBest Regards,\nSolly Ross\n\n\n','<805784526.20057269.1379015943692.JavaMail.root@redhat.com>',NULL),('<1731878922.50.1378966201413.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-12 06:10:01',0,'2013-09-12 06:10:01',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #14','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/14/>\n\n\n\n','<712185659.36.1378361537806.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<17328210.802.1395071839030.JavaMail.thinrichs@promg-2n-a-dhcp457.eng.vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 08:57:05',-25200,'2014-03-17 15:57:05',NULL,'[openstack-dev] [Congress] Policy types','Hi Prabhakar,\n\nOne big piece we\'re missing in terms of code right now is the Data Integration component.  The job of this component is to integrate data sources available in the cloud so that tables like nova:virtual_machine, neutron:owner, etc. reflect the information stored in Nova, Neutron, etc.  Rajdeep is making progress on that (he\'s got some code up on review that we\'re iterating on), and Peter had worked on integrating AD a while back.\n\nTypically I\'ve seen the Python functions (which I usually call \'builtins\') integrated into a Datalog system have explicit declarations (e.g. inputs, outputs, etc.).  This is good if we need to do deeper analysis of the policy (which is one of the reasons to use a policy language) and typically requires information about how that builtin works.  \n\nI dug through some old (Lisp) code to see how I\'ve done this in the past.\n\n// (defbuiltin <datalog-name> <lisp-function> <list of types of args> <list of types of returns> [<internal>])\n(defbuiltin plus + (integer integer) integer)\n(defbuiltin minus - (integer integer) integer)\n(defbuiltin times * (integer integer) integer)\n(defbuiltin div (lambda (x y) (floor (/ x y))) (integer integer) integer)\n(defbuiltin lt numlessp (integer integer) nil)\n(defbuiltin lte numleqp (integer integer) nil)\n(defbuiltin gte numgeqp (integer integer) nil)\n(defbuiltin gt numgreaterp (integer integer) nil)\n\nBut maybe you\'re right in that we could do away with these explicit declarations and just assume that everything that (i) is calleable, (ii) not managed by the Data Integration component, and (iii) does not appear in the head of a rule is a builtin.  My only worry is that I could imagine silent and weird problems showing up, e.g. someone forgot to define a table with rules and there happens to be a function in Python by that name.  Or someone supplies the wrong number of arguments, and we just get an error from Python, which we\'d have no direct way to communicate to the policy-writer, i.e. there\'s no compile-time argument-length checking.\n\nThe other thing I\'ve seen done is to have a single builtin \'evaluate\' that lets us call an arbitrary Python function, e.g.\n\np(x, y) :- q(x), evaluate(mypyfunc(x), y)\n\nThen we wouldn\'t need to declare the functions.  Errors would still be silent.  But it would be clear whether we were using a Python function or not.\n\nThoughts?\nTim\n\n\n\n\n----- Original Message -----\n| From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n| Sent: Saturday, March 15, 2014 8:28:27 PM\n| Subject: Re: [openstack-dev] [Congress] Policy types\n| \n| \n| \n| Hi Tim,\n| \n| Here is a small change I wanted to try in runtime.py\n| It may already exist in MaterializedViewTheory, but wasn\'t clear to\n| me.\n| Checking to see if this is something that:1. makes sense 2. already\n| exists\n| 3. worth implementing? in that order.\n| \n| Let\'s take the example from private_public_network.classify\n| \n| error(vm) :- nova:virtual_machine(vm), nova:network(vm, network),\n| not neutron:public_network(network),\n| neutron:owner(network, netowner), nova:owner(vm, vmowner), not\n| same_group(netowner, vmowner)\n| \n| same_group(user1, user2) :- cms:group(user1, group), cms:group(user2,\n| group)\n| \n| nova:virtual_machine(\"vm1\")\n| nova:virtual_machine(\"vm2\")\n| nova:virtual_machine(\"vm3\")\n| nova:network(\"vm1\", \"net_private\")\n| nova:network(\"vm2\", \"net_public\")\n| neutron:public_network(\"net_public\")\n| nova:owner(\"vm1\", \"tim\")\n| nova:owner(\"vm2\", \"pete\")\n| nova:owner(\"vm3\", \"pierre\")\n| neutron:owner(\"net_private\", \"martin\")\n| \n| \n| In this example, if as in Scenario 1:\n| \n| Cloud services at our disposal:\n| nova:virtual_machine(vm)\n| nova:network(vm, network)\n| nova:owner(vm, owner)\n| neutron:public_network(network)\n| neutron:owner(network, owner)\n| cms:group(user, group)\n| \n| are all python functions called through some nova/neutron api,\n| then, we just execute them to get a true/false value in runtime.py\n| They should be first checked to make sure they are python functions\n| and\n| not condition primitives using \'callable\' and os.dir or some such\n| combination.\n| \n| If not, and they are assertions made in the file, not directly\n| related to OS\n| state, then in Scenario 2\n| \n| nova:owner(\"vm1\", \"tim\")\n| nova:owner(\"vm2\", \"pete\")\n| nova:owner(\"vm3\", \"pierre\")\n| \n| Are assertions made in the file. In a dynamic environment,\n| a python function could query an OS client to actually find the\n| current owner,\n| since some other OS command could have been used to change the owner\n| without an entry being made in this file, i.e., without explicitly\n| informing Congres.\n| This may not occur currently with vms, but may be implemented\n| in a future release. Similar other examples are possible\n| https://ask.openstack.org/en/question/5582/how-to-change-ownership-between-tenants-of-volume/\n| https://blueprints.launchpad.net/cinder/+spec/volume-transfer\n| \n| \n| So, I was thinking that python_nova_owner(\"vm1\"), is first checked as\n| a python\n| function which calls the appropriate OS client to check the current\n| owner.\n| As in nova:owner(\"vm1\", python_nova_owner(\"vm1\"))\n| \n| So, in runtime.py, in either scenario, condition primitives are first\n| checked to\n| see if it they are callable\n| python functions (by using python \'callable\' with os.dir). In which\n| case, it is\n| executed to get the name of the owner. All non-callable primitives\n| are assumed\n| assumed to be congress and/or datalog primitives, and unified through\n| the\n| Materializedviewtheory.\n| \n| \n| Thanks,\n| \n| \n| > Date: Thu, 13 Mar 2014 08:55:24 -0700\n| > From: thinrichs at vmware.com\n| > To: openstack-dev at lists.openstack.org\n| > Subject: Re: [openstack-dev] [Congress] Policy types\n| > \n| > Hi Prabhakar,\n| > \n| > I\'m not sure the functionality is split between \'policy\' and\n| > \'server\' as cleanly as you describe.\n| > \n| > The \'policy\' directory contains the Policy Engine. At its core, the\n| > policy engine has a generic Datalog implementation that could\n| > feasibly be used by other OS components. (I don\'t want to think\n| > about pulling it out into Oslo though. There are just too many\n| > other things going on and no demand yet.) But there are also\n| > Congress-specific things in that directory, e.g. the class Runtime\n| > in policy/runtime.py will be the one that we hook up external API\n| > calls to.\n| > \n| > The \'server\' directory contains the code for the API web server\n| > that calls into the Runtime class.\n| > \n| > So if you\'re digging through code, I\'d suggest focusing on the\n| > \'policy\' directory and looking at compile.py (responsible for\n| > converting Datalog rules written as strings into an internal\n| > representation) and runtime.py (responsible for everything else).\n| > The docs I mentioned in the IRC should have a decent explanation\n| > of the functions in Runtime that the API web server will hook\n| > into.\n| > \n| > Be warned though that unless someone raises some serious objections\n| > to the proposal that started this thread, we\'ll be removing some\n| > of the more complicated functions from Runtime. The compile.py\n| > code won\'t change (much). All of the 3 new theories will be\n| > instances of MaterializedViewTheory. That\'s also the code that\n| > must change to add in the Python functions we talked about (more\n| > specifically see MaterializedViewTheory::propagate_rule(), which\n| > calls TopDownTheory::top_down_evaluation(), which is what will\n| > need modification).\n| > \n| > Tim\n| > \n| > \n| > \n| > \n| > ----- Original Message -----\n| > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | To: \"OpenStack Development Mailing List (not for usage\n| > | questions)\" <openstack-dev at lists.openstack.org>\n| > | Sent: Wednesday, March 12, 2014 1:38:55 PM\n| > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | \n| > | \n| > | \n| > | \n| > | Hi Tim,\n| > | \n| > | Thanks for your comments.\n| > | Would be happy to contribute to the propsal and code.\n| > | \n| > | The existing code already reflects the thoughts below, and got me\n| > | in the line of ideas. Please orrect me if I am wrong as I am\n| > | learning with these discussions:\n| > | \n| > | One part (reflected by code in \"policy\" directory is the generic\n| > | \"condition-> action engine\" which could take logic primitives and\n| > | (in the future) python functions, evaluate the conditions and\n| > | execute the action. This portable core engine be used for any\n| > | kind of\n| > | policy enforcement\n| > | (as by other OS projects), such as for data center monitoring and\n| > | repair,\n| > | service level enforcement, compliance policies, optimization\n| > | (energy,\n| > | performance) etc... at any level of the stack. This core engine\n| > | seems\n| > | possibly\n| > | a combination of logic reasoning/unification and python function\n| > | evaluation, and python code actions.\n| > | \n| > | Second part (reflected by code in \"server\") are the applications\n| > | for various purposes. These could be project specific, task\n| > | specific.\n| > | We could add a diverse set of examples. The example I have worked\n| > | with seems closer to compliance (as in net owner, vm owner\n| > | check),\n| > | and we will add more.\n| > | \n| > | Prabhakar\n| > | \n| > | \n| > | \n| > | Date: Wed, 12 Mar 2014 12:33:35 -0700\n| > | From: thinrichs at vmware.com\n| > | To: openstack-dev at lists.openstack.org\n| > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | \n| > | \n| > | \n| > | Hi Prabhakar,\n| > | \n| > | \n| > | Thanks for the feedback. I\'d be interested to hear what other\n| > | policy\n| > | types you have in mind.\n| > | \n| > | \n| > | To answer your questions...\n| > | \n| > | \n| > | We\'re planning on extending our policy language in such a way\n| > | that\n| > | you can use Python functions as conditions (\"<atom>\" in the\n| > | grammar)\n| > | in rules. That\'s on my todo-list but didn\'t mention it yesterday\n| > | as\n| > | we were short on time. There will be some syntactic restrictions\n| > | so\n| > | that we can properly execute those Python functions (i.e. we need\n| > | to\n| > | always be able to compute the inputs to the function). I had\n| > | thought\n| > | it was just an implementation detail I hadn\'t gotten around to\n| > | (all\n| > | Datalog implementations I\'ve seen have such things), but it\n| > | sounds\n| > | like it\'s worth writing up a proposal and sending it around\n| > | before\n| > | implementing. If that\'s a pressing concern for you, let me know\n| > | and\n| > | I\'ll bump it up the stack (a little). If you\'d like, feel free to\n| > | draft a proposal (or remind me to do it once in a while).\n| > | \n| > | \n| > | As for actions, I typically think of them as API calls to other\n| > | OS\n| > | components like Nova. But they could just as easily be Python\n| > | functions. But I would want to avoid an action that changes\n| > | Congress\'s internal data structures directly (e.g. adding a new\n| > | policy statement). Such actions have caused trouble in the past\n| > | for\n| > | policy languages (though for declarative programming languages\n| > | like\n| > | Prolog they are less problematic). I don\'t think there\'s anyway\n| > | we\n| > | can stop people from creating such actions, but I think we should\n| > | advocate against them.\n| > | \n| > | \n| > | Tim\n| > | \n| > | \n| > | \n| > | From: \"prabhakar Kudva\" <nandavarpk at hotmail.com>\n| > | To: \"OpenStack Development Mailing List (not for usage\n| > | questions)\"\n| > | <openstack-dev at lists.openstack.org>\n| > | Sent: Wednesday, March 12, 2014 11:34:04 AM\n| > | Subject: Re: [openstack-dev] [Congress] Policy types\n| > | \n| > | \n| > | \n| > | Hi Tim, All,\n| > | \n| > | I was in the discussion yesterday (kudva), and would like to\n| > | start\n| > | gradually\n| > | contributing to the code base.\n| > | \n| > | So, this discussion below is based on my limited exploration of\n| > | Congress\n| > | code, running it. I am trying some small pieces to implement to\n| > | familiarize.\n| > | Please view it as such. As I start adding code, I am sure, my\n| > | thoughts will\n| > | be more evolved.\n| > | \n| > | I agree with the three types you outline. I also agree that these\n| > | will grow.\n| > | We are already thinking of expanding congress for various other\n| > | types\n| > | of\n| > | policies. But those would be a manageable start.\n| > | \n| > | Regarding the comment below. I was wondering if all conditions,\n| > | and\n| > | actions\n| > | could be both:\n| > | 1. python functions (for conditions they eval\n| > | 2. policy primitives.\n| > | \n| > | The advantage of 1, is that it is just executed and a True or\n| > | False\n| > | returned\n| > | by Python for conditions. For actions, python functions are\n| > | executed\n| > | to respond to conditions.\n| > | This controls the growth of policies and adding more primitives,\n| > | and\n| > | makes it flexible (say\n| > | to use alarms, monitors, os clients, nova actions etc).\n| > | \n| > | The advantage of 2, is the ability to use unification (as in\n| > | unify.py) and do\n| > | some logic reduction. This gives us the full strength of\n| > | extensive\n| > | and mature\n| > | logic reasoning and reduction methods.\n| > | \n| > | One possibility is that it checks which one the two it is and\n| > | does\n| > | the appropriate\n| > | evaluation for condition and action.\n| > | \n| > | \n| > | \n| > | \n| > | >There are drawbacks to this proposal as well.\n| > | >- We will have 3 separate policies that are conceptually very\n| > | >similar. As the policies grow larger, it will become\n| > | >>increasingly\n| > | >difficult to keep the policies synchronized. This problem can be\n| > | >mitigated to some extent by having >all 3 share a library of\n| > | >policy\n| > | >statements that they all apply in different ways (and such a\n| > | >library mechanism is >already implemented).\n| > | >- As cloud services change their behavior, policies may need to\n| > | >be\n| > | >re-written. For example, right now Nova does >not consult\n| > | >Congress\n| > | >before creating a VM; thus, to enforce policy surrounding VMs,\n| > | >the\n| > | >best we could do is >write a Condition-Action policy that\n| > | >adjusts\n| > | >VM configuration when it learns about new VMs being created. If\n| > | >we\n| > | >>later make Nova consult with Congress before creating a VM, we\n| > | >need to write an Access-control policy that puts >the proper\n| > | >controls in place.\n| > | Thanks,\n| > | \n| > | Prabhakar Kudva\n| > | \n| > | \n| > | \n| > | \n| > | \n| > | \n| > | \n| > | \n| > | Date: Wed, 12 Mar 2014 10:05:23 -0700\n| > | From: thinrichs at vmware.com\n| > | To: openstack-dev at lists.openstack.org\n| > | Subject: [openstack-dev] [Congress] Policy types\n| > | \n| > | \n| > | \n| > | \n| > | Hi all,\n| > | \n| > | \n| > | We started a discussion on IRC yesterday that I\'d like to\n| > | continue.\n| > | The main question is what kind of policy does a Congress user\n| > | actually write? I can see three options. The first two focus on\n| > | actions (API calls that make changes to the state of the cloud)\n| > | and\n| > | the last focuses on just the cloud state. (By \"state of the\n| > | cloud\" I\n| > | mean all the information Congress can see about all the cloud\n| > | services it is managing, e.g. all the information we can get\n| > | through\n| > | API calls to Nova, Neutron, Cinder, Heat, ...).\n| > | \n| > | \n| > | 1) Access Control (e.g. Linux, XACML, AD): which *actions* can be\n| > | performed by other cloud services (for each state of the cloud)\n| > | 2) Condition Action: which *actions* Congress should execute (for\n| > | each state of the cloud)\n| > | 3) Classification (currently supported in Congress): which\n| > | *states*\n| > | violate real-world policy. [For those of you who have read\n| > | docs/white-papers/etc. I\'m using \"Classification\" in this note to\n| > | mean the combination of the current \"Classification\" and \"Action\n| > | Description\" policies.]\n| > | \n| > | \n| > | The important observation is that each of these policies could\n| > | contain different information from each of the others.\n| > | \n| > | \n| > | \n| > | - Access Control vs Condition Action. The Access Control policy\n| > | tells\n| > | *other cloud services* which actions they are *allowed* to\n| > | execute.\n| > | The Condition Action policy tells *Congress* which actions it\n| > | *must*\n| > | execute. These policies differ because they constrain different\n| > | sets\n| > | of cloud services.\n| > | \n| > | \n| > | - Access Control vs. Classification. The Access Control policy\n| > | might\n| > | permit some users to violate the Classification policy in some\n| > | situations (e.g. to fix violation A, we might need to cause\n| > | violation B before eliminating both). These policies differ\n| > | because\n| > | a violation in one policy might be be a violation in the other.\n| > | \n| > | \n| > | - Classification vs. Condition Action. The Classification policy\n| > | might imply which actions *could* eliminate a given violation,\n| > | but\n| > | the Condition Action policy would dictate which of those actions\n| > | *should* be executed (e.g. the Classification policy might tell\n| > | us\n| > | that disconnecting a network and deleting a VM would both\n| > | eliminate\n| > | a particular violation, but the Condition Action policy would\n| > | tell\n| > | us which to choose). And the Condition Action policy need not\n| > | eliminate all the violations present in the Classification\n| > | policy.\n| > | Again these policies differ because a violation in one policy\n| > | might\n| > | not be a violation in the other.\n| > | \n| > | \n| > | \n| > | I\'m proposing that for the first release of Congress we support\n| > | all 3\n| > | of these policies. When a user inserts/deletes a policy\n| > | statement,\n| > | she chooses which policy it belongs to. All would be written in\n| > | basically the same syntax but would be used in 3 different\n| > | scenarios:\n| > | \n| > | \n| > | - Prevention: If a component wants to consult Congress before\n| > | taking\n| > | action to see if that action is allowed, Congress checks the\n| > | Access\n| > | Control policy.\n| > | \n| > | \n| > | - Reaction: When Congress learns of a change in the cloud\'s\n| > | state, it\n| > | checks the Condition Action policy to see which actions should be\n| > | executed (if any).\n| > | \n| > | \n| > | - Monitoring: If a user wants to simply check if the cloud\'s\n| > | state is\n| > | in compliance and monitor compliance over time, she writes and\n| > | queries the Classification policy.\n| > | \n| > | \n| > | There are several benefits to this proposal.\n| > | - It allows users to choose any of the policy types, if they only\n| > | want one of them. From our discussions with potential users, most\n| > | seem to want one of these 3 policy types (and are uninterested in\n| > | the others).\n| > | - It makes the introduction to Congress relatively simple. We\n| > | describe 3 different uses of policy (Prevention, Reaction,\n| > | Monitoring) and then explain which policy to use in which case.\n| > | \n| > | - This allows us to focus on implementing a single policy-engine\n| > | technology (a Datalog policy language and evaluation algorithms),\n| > | which gives us the opportunity to make it solid.\n| > | \n| > | \n| > | There are drawbacks to this proposal as well.\n| > | - We will have 3 separate policies that are conceptually very\n| > | similar. As the policies grow larger, it will become increasingly\n| > | difficult to keep the policies synchronized. This problem can be\n| > | mitigated to some extent by having all 3 share a library of\n| > | policy\n| > | statements that they all apply in different ways (and such a\n| > | library\n| > | mechanism is already implemented).\n| > | - As cloud services change their behavior, policies may need to\n| > | be\n| > | re-written. For example, right now Nova does not consult Congress\n| > | before creating a VM; thus, to enforce policy surrounding VMs,\n| > | the\n| > | best we could do is write a Condition-Action policy that adjusts\n| > | VM\n| > | configuration when it learns about new VMs being created. If we\n| > | later make Nova consult with Congress before creating a VM, we\n| > | need\n| > | to write an Access-control policy that puts the proper controls\n| > | in\n| > | place.\n| > | \n| > | \n| > | These drawbacks were the original motivation for supporting only\n| > | the\n| > | Classification policy and attempting to derive the Access Control\n| > | and Condition Action policies from it. But given that we can\'t\n| > | always derive the proper Access Control and Condition Action\n| > | policies from the Classification policy, we will eventually need\n| > | support for all 3. In addition, the technical complexity of\n| > | supporting all 3 is much lower than supporting just the\n| > | Classification policy and deriving the others.\n| > | \n| > | \n| > | I\'ll stop there for now.\n| > | \n| > | \n| > | Comments, thoughts, questions?\n| > | Tim\n| > | \n| > | \n| > | _______________________________________________ OpenStack-dev\n| > | mailing\n| > | list OpenStack-dev at lists.openstack.org\n| > | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| > | _______________________________________________\n| > | OpenStack-dev mailing list\n| > | OpenStack-dev at lists.openstack.org\n| > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=4QiYdqIhBIaa%2FY1uu8c2Wq%2F92NWfXkaUvJLsncl4ccI%3D%0A&s=a18a843e031ec87277e04caa8396b5cf71bc7a2e5252247084abacf0b9e51409\n| > | \n| > | \n| > | \n| > | _______________________________________________ OpenStack-dev\n| > | mailing\n| > | list OpenStack-dev at lists.openstack.org\n| > | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| > | _______________________________________________\n| > | OpenStack-dev mailing list\n| > | OpenStack-dev at lists.openstack.org\n| > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=SMheq3u5q7x9wYFjxnNx6C%2F9lZgxydUP452rygu28MY%3D%0A&s=5c1cf9f3a5adc86ce59d2bf582891e0da033394f43a6ffa72127843c8cf78f80\n| > | \n| > \n| > _______________________________________________\n| > OpenStack-dev mailing list\n| > OpenStack-dev at lists.openstack.org\n| > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n| _______________________________________________\n| OpenStack-dev mailing list\n| OpenStack-dev at lists.openstack.org\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=QvFCD7z%2FP29TE6KUtbaOJzeGxlOtxzdiGCdlm1LkcOY%3D%0A&s=8f7ec7cc8312dd84709bc99d725e9934b5403a43e8f1f2d02c638e504009ea71\n| \n\n\n','<BLU170-W66EC9762CFB73AA1E72384D5720@phx.gbl>',NULL),('<173295276.74.1379830328010.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-22 06:12:07',0,'2013-09-22 06:12:07',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #24','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/24/>\n\n------------------------------------------\n[...truncated 1173 lines...]\n    test_save_updates_acls                                       OK    0.00\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestCreatingLocations\n    test_multi_tenant_location                                   OK    0.01\n    test_multi_tenant_location_custom_service_type               OK    0.01\n    test_multi_tenant_location_http                              OK    0.01\n    test_multi_tenant_location_with_region                       OK    0.01\n    test_single_tenant_location                                  OK    0.01\n    test_single_tenant_location_http                             OK    0.01\nTestMultiTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestSingleTenantStoreConnections\n    test_basic_connection                                        OK    0.01\n    test_connection_invalid_user                                 OK    0.01\n    test_connection_missing_user                                 OK    0.01\n    test_connection_with_auth_v1                                 OK    0.01\n    test_connection_with_endpoint_type                           OK    0.01\n    test_connection_with_no_trailing_slash                       OK    0.01\n    test_connection_with_region                                  OK    0.01\n    test_connection_with_service_type                            OK    0.01\n    test_connection_with_snet                                    OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.00\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.00\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_get_size                                                OK    0.01\n    test_get_size_with_multi_tenant_on                           OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.00\n    test_read_acl_tenants                                        OK    0.00\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.00\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1                                        OK    0.01\n    test_request_url_v2_2_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.22\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: glance.tests.functional.v1.test_api.TestApi.test_v1_not_enabled\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/utils.py\",> line 121, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/functional/v1/test_api.py\",> line 460, in test_v1_not_enabled\n    response, content = http.request(path, \'GET\')\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 1252, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.55 secs:\n    26.42    TestScrubber.test_scrubber_app\n    20.73    TestScrubber.test_delayed_delete\n    14.97    TestRootApi.test_version_configurations\n    14.85    TestGlanceControl.test_reload\n    14.58    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1101 tests in 615.563s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.13.3\ncffi==0.7.2\ncolorama==0.2.6\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.24\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=126\n+ \'[\' 126 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.z27WFbTebf\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/24/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-12/24\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1733033678.11.1385446346945.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-26 06:12:26',0,'2013-11-26 06:12:26',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #42','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/42/>\n\n------------------------------------------\n[...truncated 7126 lines...]\n2013-11-26 06:11:20 + local file=/etc/cinder/cinder.conf\n2013-11-26 06:11:20 + local section=DEFAULT\n2013-11-26 06:11:20 + local option=secure_delete\n2013-11-26 06:11:20 + local line\n2013-11-26 06:11:20 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^secure_delete[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-26 06:11:20 + line=\n2013-11-26 06:11:20 + \'[\' -n \'\' \']\'\n2013-11-26 06:11:20 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-26 06:11:20 secure_delete = False\n2013-11-26 06:11:20 \' /etc/cinder/cinder.conf\n2013-11-26 06:11:20 + iniset /etc/cinder/cinder.conf DEFAULT volume_clear none\n2013-11-26 06:11:20 + local file=/etc/cinder/cinder.conf\n2013-11-26 06:11:20 + local section=DEFAULT\n2013-11-26 06:11:20 + local option=volume_clear\n2013-11-26 06:11:20 + local value=none\n2013-11-26 06:11:20 + grep -q \'^\\[DEFAULT\\]\' /etc/cinder/cinder.conf\n2013-11-26 06:11:20 + ini_has_option /etc/cinder/cinder.conf DEFAULT volume_clear\n2013-11-26 06:11:20 + local file=/etc/cinder/cinder.conf\n2013-11-26 06:11:20 + local section=DEFAULT\n2013-11-26 06:11:20 + local option=volume_clear\n2013-11-26 06:11:20 + local line\n2013-11-26 06:11:20 ++ sed -ne \'/^\\[DEFAULT\\]/,/^\\[.*\\]/ { /^volume_clear[ \\t]*=/ p; }\' /etc/cinder/cinder.conf\n2013-11-26 06:11:20 + line=\n2013-11-26 06:11:20 + \'[\' -n \'\' \']\'\n2013-11-26 06:11:20 + sed -i -e \'/^\\[DEFAULT\\]/ a\\\n2013-11-26 06:11:20 volume_clear = none\n2013-11-26 06:11:20 \' /etc/cinder/cinder.conf\n2013-11-26 06:11:20 + \'[\' False == True \']\'\n2013-11-26 06:11:20 + \'[\' default == XenAPINFS \']\'\n2013-11-26 06:11:20 + \'[\' default == sheepdog \']\'\n2013-11-26 06:11:20 + is_service_enabled quantum\n2013-11-26 06:11:20 + services=quantum\n2013-11-26 06:11:20 + for service in \'${services}\'\n2013-11-26 06:11:20 + [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta, =~ ,quantum, ]]\n2013-11-26 06:11:20 + return 0\n2013-11-26 06:11:20 + install_quantum\n2013-11-26 06:11:20 + git_clone https://github.com/openstack/neutron.git /opt/stack/new/neutron stable/grizzly\n2013-11-26 06:11:20 + [[ False = \\T\\r\\u\\e ]]\n2013-11-26 06:11:20 + GIT_REMOTE=https://github.com/openstack/neutron.git\n2013-11-26 06:11:20 + GIT_DEST=/opt/stack/new/neutron\n2013-11-26 06:11:20 + GIT_REF=stable/grizzly\n2013-11-26 06:11:20 + echo stable/grizzly\n2013-11-26 06:11:20 + egrep -q \'^refs\'\n2013-11-26 06:11:20 + [[ ! -d /opt/stack/new/neutron ]]\n2013-11-26 06:11:20 + [[ \'\' == \\y\\e\\s ]]\n2013-11-26 06:11:20 + setup_develop /opt/stack/new/neutron\n2013-11-26 06:11:20 + [[ False = True ]]\n2013-11-26 06:11:20 + SUDO_CMD=sudo\n2013-11-26 06:11:20 + cd /opt/stack/new/neutron\n2013-11-26 06:11:20 + python setup.py egg_info\n2013-11-26 06:11:20 running egg_info\n2013-11-26 06:11:20 creating quantum.egg-info\n2013-11-26 06:11:20 writing requirements to quantum.egg-info/requires.txt\n2013-11-26 06:11:20 writing quantum.egg-info/PKG-INFO\n2013-11-26 06:11:20 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-26 06:11:20 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-26 06:11:20 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-26 06:11:20 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-26 06:11:20 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-26 06:11:20 reading manifest template \'MANIFEST.in\'\n2013-11-26 06:11:20 warning: no files found matching \'AUTHORS\'\n2013-11-26 06:11:20 warning: no files found matching \'ChangeLog\'\n2013-11-26 06:11:20 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-26 06:11:21 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-26 06:11:21 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-26 06:11:21 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-26 06:11:21 ++ awk \'/^.+/ {print \"-f \" $1}\' quantum.egg-info/dependency_links.txt\n2013-11-26 06:11:21 + raw_links=\n2013-11-26 06:11:21 ++ echo\n2013-11-26 06:11:21 ++ xargs\n2013-11-26 06:11:21 + depend_links=\n2013-11-26 06:11:21 ++ \'[\' \'!\' -r quantum.egg-info/requires.txt \']\'\n2013-11-26 06:11:21 ++ echo \'-r *-info/requires.txt\'\n2013-11-26 06:11:21 + require_file=\'-r *-info/requires.txt\'\n2013-11-26 06:11:21 + pip_install -r quantum.egg-info/requires.txt\n2013-11-26 06:11:21 + [[ False = \\T\\r\\u\\e ]]\n2013-11-26 06:11:21 + [[ -z -r quantum.egg-info/requires.txt ]]\n2013-11-26 06:11:21 + [[ -z deb ]]\n2013-11-26 06:11:21 + [[ False = True ]]\n2013-11-26 06:11:21 + SUDO_PIP=sudo\n2013-11-26 06:11:21 ++ get_pip_command\n2013-11-26 06:11:21 ++ is_fedora\n2013-11-26 06:11:21 ++ [[ -z Ubuntu ]]\n2013-11-26 06:11:21 ++ \'[\' Ubuntu = Fedora \']\'\n2013-11-26 06:11:21 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-11-26 06:11:21 ++ \'[\' Ubuntu = CentOS \']\'\n2013-11-26 06:11:21 ++ which pip\n2013-11-26 06:11:21 + CMD_PIP=/usr/local/bin/pip\n2013-11-26 06:11:21 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-11-26 06:11:21 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r quantum.egg-info/requires.txt\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): Paste in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 1))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 2))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): Routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 3))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 4))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 5))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 6))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 7))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 8))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 9))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 10))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 11))\n2013-11-26 06:11:21 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:21   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.4.3.tar.gz\n2013-11-26 06:11:21   Running setup.py egg_info for package python-quantumclient\n2013-11-26 06:11:21     [pbr] Processing SOURCES.txt\n2013-11-26 06:11:21     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-11-26 06:11:21     \n2013-11-26 06:11:21     [pbr] In git context, generating filelist from git\n2013-11-26 06:11:21     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): pyudev in /usr/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 13))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy>=0.7.8,<=0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 14))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): WebOb>=1.2 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 15))\n2013-11-26 06:11:21 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:21 Downloading/unpacking alembic>=0.4.1 (from -r quantum.egg-info/requires.txt (line 17))\n2013-11-26 06:11:23   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Falembic%2Falembic-0.6.0.tar.gz\n2013-11-26 06:11:23   Running setup.py egg_info for package alembic\n2013-11-26 06:11:23     \n2013-11-26 06:11:23     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-26 06:11:23     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-26 06:11:23     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-26 06:11:23     no previously-included directories found matching \'docs/build/output\'\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r quantum.egg-info/requires.txt (line 18))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): python-novaclient in /opt/stack/new/python-novaclient (from -r quantum.egg-info/requires.txt (line 19))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.23-py2.7.egg (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): six>=1.4.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Downloading/unpacking Mako (from alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-26 06:11:23   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMako%2FMako-0.9.0.tar.gz\n2013-11-26 06:11:23   Running setup.py egg_info for package Mako\n2013-11-26 06:11:23     \n2013-11-26 06:11:23     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-26 06:11:23     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-26 06:11:23     warning: no files found matching \'ez_setup.py\'\n2013-11-26 06:11:23     no previously-included directories found matching \'doc/build/output\'\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=1.3->python-keystoneclient>=0.2.0->-r quantum.egg-info/requires.txt (line 16))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): MarkupSafe>=0.9.2 in /usr/lib/python2.7/dist-packages (from Mako->alembic>=0.4.1->-r quantum.egg-info/requires.txt (line 17))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.2.0,<3.0.0->-r quantum.egg-info/requires.txt (line 12))\n2013-11-26 06:11:23 Installing collected packages: python-quantumclient, alembic, Mako\n2013-11-26 06:11:23   Running setup.py install for python-quantumclient\n2013-11-26 06:11:23     [pbr] Reusing existing SOURCES.txt\n2013-11-26 06:11:23     Installing quantum script to /usr/local/bin\n2013-11-26 06:11:23   Running setup.py install for alembic\n2013-11-26 06:11:23     \n2013-11-26 06:11:23     warning: no files found matching \'*.jpg\' under directory \'docs\'\n2013-11-26 06:11:23     warning: no files found matching \'*.sty\' under directory \'docs\'\n2013-11-26 06:11:23     warning: no files found matching \'*.dat\' under directory \'tests\'\n2013-11-26 06:11:23     no previously-included directories found matching \'docs/build/output\'\n2013-11-26 06:11:23     Installing alembic script to /usr/local/bin\n2013-11-26 06:11:23   Running setup.py install for Mako\n2013-11-26 06:11:23     changing mode of build/scripts-2.7/mako-render from 644 to 755\n2013-11-26 06:11:23     \n2013-11-26 06:11:23     warning: no files found matching \'*.xml\' under directory \'examples\'\n2013-11-26 06:11:23     warning: no files found matching \'*.mako\' under directory \'examples\'\n2013-11-26 06:11:23     warning: no files found matching \'ez_setup.py\'\n2013-11-26 06:11:23     no previously-included directories found matching \'doc/build/output\'\n2013-11-26 06:11:23     changing mode of /usr/local/bin/mako-render to 755\n2013-11-26 06:11:23 Successfully installed python-quantumclient alembic Mako\n2013-11-26 06:11:23 Cleaning up...\n2013-11-26 06:11:23 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-11-26 06:11:23 running develop\n2013-11-26 06:11:23 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-11-26 06:11:23 /usr/bin/python -E -c pass\n2013-11-26 06:11:23 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-11-26 06:11:23 running egg_info\n2013-11-26 06:11:23 writing requirements to quantum.egg-info/requires.txt\n2013-11-26 06:11:23 writing quantum.egg-info/PKG-INFO\n2013-11-26 06:11:23 writing eager_resources to quantum.egg-info/eager_resources.txt\n2013-11-26 06:11:23 writing top-level names to quantum.egg-info/top_level.txt\n2013-11-26 06:11:23 writing dependency_links to quantum.egg-info/dependency_links.txt\n2013-11-26 06:11:23 writing entry points to quantum.egg-info/entry_points.txt\n2013-11-26 06:11:23 reading manifest template \'MANIFEST.in\'\n2013-11-26 06:11:23 warning: no files found matching \'AUTHORS\'\n2013-11-26 06:11:23 warning: no files found matching \'ChangeLog\'\n2013-11-26 06:11:23 warning: no files found matching \'quantum/db/migration/alembic/script.py.mako\'\n2013-11-26 06:11:23 warning: no files found matching \'quantum/db/migration/alembic/versions/README\'\n2013-11-26 06:11:23 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-11-26 06:11:23 writing manifest file \'quantum.egg-info/SOURCES.txt\'\n2013-11-26 06:11:23 running build_ext\n2013-11-26 06:11:23 Creating /usr/local/lib/python2.7/dist-packages/quantum.egg-link (link to .)\n2013-11-26 06:11:23 Adding quantum 2013.1.5.a1.g666826a to easy-install.pth file\n2013-11-26 06:11:23 Installing quantum-debug script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-nec-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-dhcp-agent-dnsmasq-lease-update script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-dhcp-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-lbaas-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-ryu-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-l3-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-check-nvp-config script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-db-manage script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-metadata-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-server script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-linuxbridge-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-ns-metadata-proxy script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-openvswitch-agent script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-netns-cleanup script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-ovs-cleanup script to /usr/local/bin\n2013-11-26 06:11:23 Installing quantum-rootwrap script to /usr/local/bin\n2013-11-26 06:11:23 \n2013-11-26 06:11:23 Installed /opt/stack/new/neutron\n2013-11-26 06:11:23 Processing dependencies for quantum==2013.1.5.a1.g666826a\n2013-11-26 06:11:23 error: Installed distribution iso8601 0.1.4 conflicts with requirement iso8601>=0.1.8\n2013-11-26 06:11:23 ++ failed\n2013-11-26 06:11:23 ++ local r=1\n2013-11-26 06:11:23 +++ jobs -p\n2013-11-26 06:11:23 ++ kill\n2013-11-26 06:11:23 ++ set +o xtrace\n2013-11-26 06:11:23 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-11-26-060847\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-740952-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-740952.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az2-740952/42/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1447888971.116.1384495612787.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1733201417.30382384.1407936255259.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 09:24:15',-14400,'2014-08-13 13:24:15',NULL,'[openstack-dev] [all] The future of the integrated release','\n\n> >  > It seems like this is exactly what the slots give us, though. The core\n> >  > review\n> > > team picks a number of slots indicating how much work they think they can\n> > > actually do (less than the available number of blueprints), and then\n> > > blueprints queue up to get a slot based on priorities and turnaround time\n> > > and other criteria that try to make slot allocation fair. By having the\n> > > slots, not only is the review priority communicated to the review team,\n> > > it\n> > > is also communicated to anyone watching the project.\n> > \n> > One thing I\'m not seeing shine through in this discussion of slots is\n> > whether any notion of individual cores, or small subsets of the core\n> > team with aligned interests, can \"champion\" blueprints that they have\n> > a particular interest in.\n> > \n> > For example it might address some pain-point they\'ve encountered, or\n> > impact on some functional area that they themselves have worked on in\n> > the past, or line up with their thinking on some architectural point.\n> > \n> > But for whatever motivation, such small groups of cores currently have\n> > the freedom to self-organize in a fairly emergent way and \"champion\"\n> > individual BPs that are important to them, simply by *independently*\n> > giving those BPs review attention.\n> > \n> > Whereas under the slots initiative, presumably this power would be\n> > subsumed by the \"group will\", as expressed by the prioritization\n> > applied to the holding pattern feeding the runways?\n> > \n> > I\'m not saying this is good or bad, just pointing out a change that\n> > we should have our eyes open to.\n> \n> Yeah, I\'m really nervous about that aspect.\n> \n> Say a contributor proposes a new feature, a couple of core reviewers\n> think it\'s important exciting enough for them to champion it but somehow\n> the \'group will\' is that it\'s not a high enough priority for this\n> release, even if everyone agrees that it is actually cool and useful.\n> \n> What does imposing that \'group will\' on the two core reviewers and\n> contributor achieve? That the contributor and reviewers will happily\n> turn their attention to some of the higher priority work? Or we lose a\n> contributor and two reviewers because they feel disenfranchised?\n> Probably somewhere in the middle.\n\nYeah, the outcome probably depends on the motivation/incentives that\nare operating for individual contributors.\n\nIf their brief or primary interest was to land *specific* features,\nthen they may sit out the cycle, or just work away on their pet features\nanyway \"under the radar\".\n\nIf, OTOH, they have more of a over-arching \"make the project better\"\ngoal, they may gladly (or reluctantly) apply themselves to the group-\ndefined goals.\n\nHowever, human nature being what it is, I\'d suspect that the energy\nlevels applied to self-selected goals may be higher in the average case.\nJust a gut feeling on that, no hard data to back it up. \n\n> On the other hand, what happens if work proceeds ahead even if not\n> deemed a high priority? I don\'t think we can say that the contributor\n> and two core reviewers were distracted from higher priority work,\n> because blocking this work is probably unlikely to shift their focus in\n> a productive way. Perhaps other reviewers are distracted because they\n> feel the work needs more oversight than just the two core reviewers? It\n> places more of a burden on the gate?\n\nWell I think we have accept the reality that we can\'t force people to\nwork on stuff they don\'t want to, or entirely stop them working on the\nstuff that they do.\n\nSo inevitably there will be some deviation from the shining path, as\nset out in the \"group will\". Agreed that blocking this work from say\nbeing proposed on gerrit won\'t necessarily have the desired outcome\n\n(OK, it could stop the transitive distraction of other reviewers, and\nremove the gate load, but won\'t restore the time spent working off-piste\nby the contributor and two cores in your example)\n\n> I dunno ... the consequences of imposing group will worry me more than\n> the consequences of allowing small groups to self-organize like this.\n\nYep, this capacity for self-organization of informal groups with aligned\ninterests (as opposed to corporate affiliations) is, or at least should\nbe IMO, seen as one of the primary strengths of the open source model.\n\nCheers,\nEoghan\n\n\n','<1407934372.26856.327.camel@sorcha>',NULL),('<17336E10-82EC-4986-B259-344FEFDF0419@dreamhost.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-10 07:55:58',-18000,'2013-11-10 12:55:58',NULL,'[openstack-dev] [Solum] Choice of API infrastructure','Sorry for the late reply to this thread - I was having email access fits for most of the summit this past week.  I also intend to look at the gate failures for py33 and pypy for Noorul\'s patch.  I need to dig a bit and figure out what\'s *actually* going on there, as pecan should work just fine for both.\n\n---\nRyan Petrello\nSenior Developer, DreamHost\nryan.petrello at dreamhost.com\n\nOn Nov 7, 2013, at 7:02 PM, Jay Pipes <jaypipes at gmail.com> wrote:\n\n> On 11/07/2013 06:41 PM, Adrian Otto wrote:\n>> Solum Team,\n>> \n>> First of all I wanted to say that I have been thinking a lot about this thread, and have been seeking input from a number of you who attended the Summit this week. I do *not* see this decision as a critical one, because if something really mattered a ton we could rip our one framework and put another in.\n>> \n>> What I love about this discussion is that we are having a healthy debate about different points of view, which was very thought provoking. I have heard input from skeptics who think that engineering decisions have to be made in a small group in order to be efficient. I know that thinking is wrong, and it\'s examples like these that convince me further that discussions like these help us make better choices, and make development more efficient over the long run.\n>> \n>> We should give the most weight to the preferences of the engineers who will write and maintain the code. If there are team members who are volunteering to write and maintain the bulk of our API code over a period of time who really want Falcon over Pecan, then we should give that fair consideration. The API is exceedingly important to Solum, and all of us will be working on it, so we need a choice that all of us can live with.\n>> \n>> I suggest that we settle on Pecan+WSME, for the following reasons:\n>> \n>> 1) It is a known quantity, and is likely to work well for Solum\'s needs, considering that Solum is primarily a control plane API system, and that performance is not a primary motivator.\n>> \n>> 2) Pecan+WSME allows us to offer data serializations in both JSON and XML to help satisfy the preferences of the API consumers.\n>> \n>> 3) It allows us to have multiple models that are loosely coupled, which can aid in data validation.\n>> \n>> 4) At this point in time, other OpenStack core/integrated/ecosystem projects are using Pecan+WSME, and several Solum contributors will be switching between projects. There is an advantage to a higher level of consistency among various projects.\n>> \n>> I accept that Webob may be problematic for us, that performance may be less than ideal, and that some Solum developers may dislike working with WSME, and that Falcon may actually be more pleasant to work with. We have team members with a deep understanding of Falcon, and could definitely make it work. We can proceed with Pecan+WSME accepting these (and  other) trade-offs.\n>> \n>> Are there any other critically important considerations that we should consider before converging on this choice? I\'d like to hear that input prior to our next IRC meeting.\n> \n> None that I can think of. I\'ll get behind the decision, then, and if all are in consensus, I\'ll abandon the Falcon API patch.\n> \n> We do need to get the Pecan/WSME patch to pass the gates though :) Doug, I\'m hoping you might give Noorul a hand with that next week upon your return from Hong Kong?\n> \n> All the best,\n> -jay\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<527C2A10.3070505@gmail.com>',NULL);
INSERT INTO `messages` VALUES ('<1733973181.24387701.1407260344978.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-05 13:39:04',-14400,'2014-08-05 17:39:04',NULL,'[openstack-dev] [nova] so what do i do about libvirt-python if\n i\'m on precise?','Just to add my two cents, while I get that people need to run on older versions of software,\nat a certain point you have to bump the minimum version.  Even libvirt 0.9.11 is from April 3rd 2012.\nThat\'s two and a third years old at this point.  I think at a certain point we need to say \"if you want\nto run OpenStack on an older platform, then you\'ll need to run an older OpenStack or backport the required\npackages.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Joe Gordon\" <joe.gordon0 at gmail.com>\n> To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, July 30, 2014 7:07:13 PM\n> Subject: Re: [openstack-dev] [nova] so what do i do about libvirt-python if i\'m on precise?\n> \n> \n> \n> \n> On Jul 30, 2014 3:36 PM, \"Clark Boylan\" < cboylan at sapwetik.org > wrote:\n> > \n> > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:\n> > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:\n> > > > While forcing people to move to a newer version of libvirt is\n> > > > doable on most environments, do we want to do that now? What is\n> > > > the benefit of doing so?\n> > > [...]\n> > > \n> > > The only dog I have in this fight is that using the split-out\n> > > libvirt-python on PyPI means we finally get to run Nova unit tests\n> > > in virtualenvs which aren\'t built with system-site-packages enabled.\n> > > It\'s been a long-running headache which I\'d like to see eradicated\n> > > everywhere we can. I understand though if we have to go about it\n> > > more slowly, I\'m just excited to see it finally within our grasp.\n> > > --\n> > > Jeremy Stanley\n> > > \n> > We aren\'t quite forcing people to move to newer versions. Only those\n> > installing nova test-requirements need newer libvirt. This does not\n> > include people using eg devstack. I think it is reasonable to expect\n> > people testing tip of nova master to have a reasonably newish test bed\n> > to test it (its not like the Infra team moves at a really fast pace :)\n> > ).\n> \n> Based on\n> http://lists.openstack.org/pipermail/openstack-dev/2014-July/041457.html\n> this patch is breaking people, which is the basis for my concerns. Perhaps\n> we should get some further details from Salvatore.\n> \n> > \n> > Avoiding system site packages in virtualenvs is a huge win particularly\n> > for consistency of test results. It avoids pollution of site packages\n> > that can happen differently across test machines. This particular type\n> > of inconsistency has been the cause of the previously mentioned\n> > headaches.\n> \n> I agree this is a huge win, but I am just concerned we don\'t have any\n> deprecation cycle and just roll out a new requirement without a heads up.\n> \n> > \n> > Clark\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CAHXdxOd1FBxqkE4uPmsB5ycYm4xhTypA1q5fNVBQrn24MOWh7Q@mail.gmail.com>',NULL),('<1734467249.1771409.1385149844843.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 20:50:44',3600,'2013-11-22 19:50:44',NULL,'[openstack-dev] [horizon] Javascript development improvement','That is a fact all client side development is based on javascript, Node allow us to easily execute javascript without a browser. Every time we will have a reflexion on the client side, Node will show up, what we are doing is just delaying something inevitable and wasting our forces in compromises. Node is not the best way, but it is the easiest one, what would we do next time, search another alternative in python, if it is buggy we will have to maintain it. You are right Node is currently fancy, but less is fancy, angular is fancy but they provides some ease and that is why we choose them.\n\n----- Original Message -----\nFrom: \"Jordan OMara\" <jomara at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Friday, November 22, 2013 7:22:12 PM\nSubject: Re: [openstack-dev] [horizon] Javascript development improvement\n\nOn 22/11/13 12:06 -0500, Julie Pichon wrote:\n>I don\'t think Selenium is going away, and efforts have started around\n>using it as well for our integration tests [0]. Looking at the current\n>AngularJS patch up for review, it is testable without requiring\n>NodeJS. \n\nWhile the Angular modules are testable in QUnit, it would be a boon to use the\ntesting patterns common with most Angular projects.  It would make new\ndevelopers, familiar with Angular but not Horizon, immediately familiar with the\nworkflow.\n\nQUnit is acceptable, but karma/jasmine is preferable\n\n> From the initial mailing list discussion [1], my understanding\n>is that we\'re planning on using a specific AngularJS feature, not\n>rewriting everything with it. Changing our build system to accommodate\n>this seems like getting a bit ahead of ourselves.\n>\n>[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html\n\nTo be clear, we\'re using a specific feature of Angular (the directive) to\nintroduce it into the existing Django templates; that\'s not the only feature of\nAngular we\'re using. There are controllers & services behind the directive, but\nusing a directive is the cleanest way of integrating these features with the\nexisting templates.\n\n-- \nJordan O\'Mara <jomara at redhat.com>\nRed Hat Engineering, Raleigh \n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<20131122182212.GC1565@redhat.com>',NULL),('<1735543085.29924893.1384254489327.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-12 06:08:09',-18000,'2013-11-12 11:08:09',NULL,'[openstack-dev] [openstack][metering] Contributing to\n ceilometer while participating in GSoC','Hi Ajay,\n\n\"Ajay Phogat\" <letsgotry7 at gmail.com> wrote:\n> Hello, all!\n> \n> I am a student of Computer Science and have learnt some basics of OpenStack\n> for implementing one of my projects in college. While learning about\n> OpenStack, I came to know about the metering project, ceilometer.\n> \n> I would love to contribute to ceilometer, which according to\n> ohloh<http://www.ohloh.net/p?ref=homepage&q=ceilometer> has\n> 88 contributors presently. Also, I wanted to participate in Google Summer\n> of Code while being associated with ceilometer. I wanted to know if\n> contributing to ceilometer can be a valid project for GSoC.\n\nThanks for your interest in OpenStack and Ceilometer, that\'s great! Many\nmembers of the community were away in Hong Kong for the OpenStack Summit last\nweek, sorry for the delay.\n\nOpenStack has never participated in GSoC before - we never quite managed to\nmatch the organisation requirements in time for the deadline. Maybe this will\nchange next year but I wouldn\'t necessarily count on it. I still encourage you\nto get involved with the community even outside of a program like GSoC. There\'s\na lot of things we could use your help with!\n\nMaybe a current Ceilometer contributor can point you toward a suitable first\ntask, in the meantime there\'s a lot of information you can read about to get\nyourself started contributing: see [0] to learn the general OpenStack\ncontribution guidelines, [1] for finding something small to work on that you\nfind interesting, [2] to get an OpenStack dev environment set up in a VM.\n\nConsider also popping by on IRC [3], on #openstack-metering for Ceilometer\nrelated questions and #openstack-101 if you encounter any hiccup getting\nstarted contributing. There are lots of people happy to help and guide you!\n\nKind regards,\n\nJulie\n\n[0] https://wiki.openstack.org/wiki/HowToContribute\n[1] https://bugs.launchpad.net/ceilometer/\n[2] http://devstack.org/\n[3] https://wiki.openstack.org/IRC\n\n> \n> Thanks a lot for your time and effort!\n> \n> \n> Ajay Phogat\n\n\n','<CAEG3EeFsaPH8gatCvytu3s_HT9vkV1=rJaGg+=wLw2JO6es5Ag@mail.gmail.com>',NULL),('<17358747.384.1367042793377.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:06:33',0,'2013-04-27 06:06:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal2 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/>\nCheckout:periodic-horizon-python27-stable-grizzly / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 183c97db:quantal2\nUsing strategy: Default\nLast Built Revision: Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\nChecking out Revision 04aa8c8dad0ffedcddc16423454703b73df5de91 (origin/stable/grizzly)\n[periodic-horizon-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson3578626629960300154.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.SaiEdZvSaY\n+ TMPDIR=/tmp/tmp.SaiEdZvSaY\n+ trap \'rm -rf /tmp/tmp.SaiEdZvSaY\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins.periodic.horizon.python27.stable.grizzly.17\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/log/py27-1.log>\nERROR: actionid=py27\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-python27-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 36964 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-python27-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/.tox/py27\',> \'SHELL\': \'/bin/bash\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal2\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'TMPDIR\': \'/tmp/tmp.SaiEdZvSaY\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-03-29\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'edcdcbe5-fd81-4258-a6a5-82b0132b364e\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'04aa8c8dad0ffedcddc16423454703b73df5de91\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal2\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 36964 166.78.137.199 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\nNo distributions at all found for Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires> (line 2))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py27: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-grizzly/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nargparse==1.2.1\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.SaiEdZvSaY\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1736498405.47167189.1359046262135.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-24 11:51:02',-18000,'2013-01-24 16:51:02',NULL,'[openstack-dev] [swift] cleanup after partial upload','\nHi Folks,\n\nA quick swift question.\n\nIf an upload is dropped while in-flight (i.e. the PUT .../container/obj\nrequest is terminated by the client before all the content or chunks\nhave been written), does swift gracefully detect and clean up after \nthis scenario?\n\nIn particular, is the storage used by the partial data uploaded all\nproperly released?\n\nCheers,\nEoghan\n\n\n','<1943886055.47160265.1359045831204.JavaMail.root@redhat.com>',NULL),('<1736652971.65.1386741971247.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:06:11',0,'2013-12-11 06:06:11',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-havana #5','See <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise5 in workspace <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/>\nCheckout:periodic-horizon-docs-havana / <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/> - hudson.remoting.Channel at 665ea991:precise5\nUsing strategy: Default\nLast Built Revision: Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/horizon\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/horizon\nCommencing build of Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\nChecking out Revision 852e5c88a30f5fd5bfd0fe659a92b3ad018fb771 (origin/stable/havana)\n[periodic-horizon-docs-havana] $ /bin/bash -xe /tmp/hudson5748353826339335889.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack horizon /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=horizon\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n++ org=openstack\n++ project=horizon\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack horizon /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=horizon\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z horizon ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/horizon /opt/requirements/projects.txt\nopenstack/horizon\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/test-requirements.txt>\nvenv inst: <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/dist/horizon-jenkins.periodic.horizon.docs.havana.5.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-havana/precise5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-havana/precise5/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1736743172.26580613.1407436329506.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 14:32:09',-14400,'2014-08-07 18:32:09',NULL,'[openstack-dev] [all] The future of the integrated release','\n\n> Multidisciplinary training rules! As an architect with field experience\n> building roads, sidewalks, roofs, city planning (and training in lean\n> manufacturing and services) I think I can have a say ;)\n> \n> > You\'re not really introducing a successful Kanban here, you\'re just\n> > clarifying that there should be a set number of workstations.\n> \n> Right, and to clarify I\'m really thinking kanban here, expanding on the\n> few lines Mikal used to explain the \'slots\' concept.\n> \n> > Our current system is like a gigantic open space with hundreds of\n> > half-finished pieces, and a dozen workers keep on going from one to\n> > another with no strong pattern. The proposed system is to limit the\n> > number of half-finished pieces fighting for the workers attention at any\n> > given time, by setting a clear number of workstations.\n> \n> Correct, and I think we should add a limit to the amount of WIP, too. So\n> we have a visible limit to people, workstations and Work In Progress.\n> This way we can *immediately*, at any given time, identify problems.\n\nIf there\'s a trend in the replies from folks with experience\nof running manufacturing or construction pipelines out in the\nwild, it seems to be:\n\n  extend the reach of the back-pressure further up the funnel \n\nThis makes logical sense, but IMO simply doesn\'t apply in our\ncase, given the lack of direct command & control over the stuff\nthat contributors actually want to work on.\n\nIf we try to limit the number of WIP slots, then surely aspiring\ncontributors will simply work around that restriction by preparing\nthe code they\'re interested in on their own private branches, or\nin their github forks?\n\nOK, some pragmatic contributors will adjust their priorities to\nalign with the available slots. And some companies employing\nlarge numbers of contributors will enforce policies to align\ntheir developers\' effort with the gatekeepers\' priorities.\n\nBut I suspect we\'d also have a good number who would take the\nrisk that their code never lands and work on it anyway. Given\nthat such efforts would really be flying beneath the radar and\nmay never see the light of day, that would seem like true waste\nto me.\n\nI don\'t have a good solution, just wanted to point out that\naspect.\n\nCheers,\nEoghan\n\n> > A true Kanban would be an interface between developers and reviewers,\n> > where reviewers define what type of change they have to review to\n> > complete production objectives, *and* developers would strive to produce\n> > enough to keep the kanban above the red line, but not too much (which\n> > would be piling up waste).\n> \n> Exactly where I am aiming at: reducing waste, which we already have but\n> nobody (few, at different times) sees. By switching to a pull \'Just In\n> Time\' mode we\'d see waste accumulate much earlier than as we do now.\n> \n> > Without that discipline, Kanbans are useless. Unless the developers\n> > adapt what they work on based on release objectives, you don\'t really\n> > reduce waste/inventory at all, it just piles up waiting for available\n> > \"runway slots\". As I said in my original email, the main issue here is\n> > the imbalance between too many people proposing changes and not enough\n> > people caring about the project itself enough to be trusted with core\n> > reviewers rights.\n> \n> I agree with you. Right now we\'re accumulating waste in the form of code\n> proposals (raw pieces that need to be processed) but reviewers and core\n> reviewers\' attention span is limited (the number of \'workstations\' is\n> finite but we don\'t have such limit exposed) and nobody sees the\n> accumulation of backlog until it\'s very late, at the end of the release\n> cycle.\n> \n> A lot of the complaints I hear and worsening time to merge patches seems\n> to indicate that we\'re over capacity and we didn\'t notice.\n> \n> > The only way to be truly pull-based is\n> > to define a set of production objectives and have those objectives\n> > trickle up to the developers so that they don\'t work on something else.\n> \n> Yeah, don\'t we try to do that with blueprints/specs and priority? But we\n> don\'t set a limit, it\'s almost a \'free for all\' send your patches in and\n> someone will evaluate them. Except there is a limit to what we can produce.\n> \n> I think fundamentally we need to admit that there are 24 hours in a day\n> and that core reviewers have to sleep, sometimes. There is a finite\n> amount of patches that can be processed in a given time interval.\n> \n> It\'s about finding a way to keep producing OpenStack at the highest\n> speed possible, keeping quality, listening to \'downstream\' first.\n> \n> > The solution is about setting release cycle goals and strongly\n> > communicating that everything out of those goals is clearly priority 2.\n> \n> I don\'t think there is any \'proposal\' just yet, only a half-baked idea\n> thrown out there by the nova team during a meeting and fluffed up by me\n> on the list. Still only a half-baked idea.\n> \n> I realized this is a digression from the original thread though. I\'ll\n> talk to Russell and Nikola off-list (since they sent interesting\n> comments, too) and John and Dan to see if they\'re still interested in\n> formulating a comprehensive proposal.\n> \n> /stef\n\n\n','<53E3B9A5.4080002@openstack.org>',NULL),('<1737033965.5.1376634478738.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-08-16 06:27:58',0,'2013-08-16 06:27:58',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #8','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-all/8/>\n\n------------------------------------------\n[...truncated 21159 lines...]\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.2 (10.1.0.2) 56(84) bytes of data.\n64 bytes from 10.1.0.2: icmp_req=1 ttl=64 time=5.84 ms\n\n--- 10.1.0.2 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 5.849/5.849/5.849/0.000 ms\n++ cinder list\n++ head -1\n++ get_field 2\n++ read data\n++ grep ex-vol-92aa2e6e\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1376633412\n+ cinder create --display_name ex-vol-92aa2e6e --display_description \'test volume: ex-vol-92aa2e6e\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-08-16T06:10:12.772264      |\n| display_description |     test volume: ex-vol-92aa2e6e     |\n|     display_name    |           ex-vol-92aa2e6e            |\n|          id         | 945a4c86-6d11-4527-b4d7-0ba8bd124f6b |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-92aa2e6e | grep available; do sleep 1; done\'\n| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | available | ex-vol-92aa2e6e |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376633415\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ head -1\n++ grep ex-vol-92aa2e6e\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | available | ex-vol-92aa2e6e |  1   |     None    |  False   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=945a4c86-6d11-4527-b4d7-0ba8bd124f6b\n+ die_if_not_set 165 VOL_ID \'Failure retrieving volume ID for ex-vol-92aa2e6e\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1376633415\n+ nova volume-attach deb55dee-49d8-4b62-9073-6334ab06501d 945a4c86-6d11-4527-b4d7-0ba8bd124f6b /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| serverId | deb55dee-49d8-4b62-9073-6334ab06501d |\n| id       | 945a4c86-6d11-4527-b4d7-0ba8bd124f6b |\n| volumeId | 945a4c86-6d11-4527-b4d7-0ba8bd124f6b |\n+----------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-92aa2e6e | grep in-use; do sleep 1; done\'\n| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | in-use | ex-vol-92aa2e6e |  1   |     None    |  False   | deb55dee-49d8-4b62-9073-6334ab06501d |\n++ date +%s\n+ end_time=1376633420\n+ echo \'Completed volume-attach in 5 seconds\'\nCompleted volume-attach in 5 seconds\n++ cinder list\n++ grep ex-vol-92aa2e6e\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | in-use | ex-vol-92aa2e6e |  1   |     None    |  False   | deb55dee-49d8-4b62-9073-6334ab06501d |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=deb55dee-49d8-4b62-9073-6334ab06501d\n+ die_if_not_set 179 VOL_ATTACH \'Failure retrieving ex-vol-92aa2e6e status\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ [[ deb55dee-49d8-4b62-9073-6334ab06501d != deb55dee-49d8-4b62-9073-6334ab06501d ]]\n++ date +%s\n+ start_time=1376633420\n+ nova volume-detach deb55dee-49d8-4b62-9073-6334ab06501d 945a4c86-6d11-4527-b4d7-0ba8bd124f6b\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-92aa2e6e | grep available; do sleep 1; done\'\n| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | available | ex-vol-92aa2e6e |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376633423\n+ echo \'Completed volume-detach in 3 seconds\'\nCompleted volume-detach in 3 seconds\n++ date +%s\n+ start_time=1376633423\n+ cinder delete 945a4c86-6d11-4527-b4d7-0ba8bd124f6b\n+ timeout 90 sh -c \'while cinder list | grep ex-vol-92aa2e6e; do sleep 1; done\'\n| 945a4c86-6d11-4527-b4d7-0ba8bd124f6b | deleting | ex-vol-92aa2e6e |  1   |     None    |  False   |             |\n++ date +%s\n+ end_time=1376633426\n+ echo \'Completed cinder delete in 3 seconds\'\nCompleted cinder delete in 3 seconds\n+ nova delete deb55dee-49d8-4b62-9073-6334ab06501d\n+ timeout 60 sh -c \'while nova list | grep -q deb55dee-49d8-4b62-9073-6334ab06501d; do sleep 1; done\'\n+ [[ vol_secgroup = \\d\\e\\f\\a\\u\\l\\t ]]\n+ nova secgroup-delete vol_secgroup\n+----+--------------+--------------------------+\n| Id | Name         | Description              |\n+----+--------------+--------------------------+\n| 5  | vol_secgroup | vol_secgroup description |\n+----+--------------+--------------------------+\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: /opt/stack/new/devstack/exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest all test suite\nGLOB sdist-make: /opt/stack/new/tempest/setup.py\nall create: /opt/stack/new/tempest/.tox/all\nall inst: /opt/stack/new/tempest/.tox/dist/tempest-2013.2.a1562.g4369755.zip\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpUEq4OO\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpYUohq3\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpsB0osB\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-250} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpkRhJP_\n======================================================================\nFAIL: setUpClass (tempest.whitebox.test_servers_whitebox.ServersWhiteboxTest)\ntags: worker-1\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"tempest/whitebox/test_servers_whitebox.py\", line 30, in setUpClass\n    BaseIdentityAdminTest.setUpClass()\n  File \"tempest/api/identity/base.py\", line 29, in setUpClass\n    os = clients.AdminManager(interface=cls._interface)\nAttributeError: type object \'BaseIdentityAdminTest\' has no attribute \'_interface\'\n======================================================================\nFAIL: process-returncode\ntags: worker-1\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2456 tests in 980.517s\nFAILED (id=0, failures=2, skips=64)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/rabbitmq/rabbit at devstack-1376632278-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/rabbitmq/rabbit at devstack-1376632278.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az1-11990/8/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<273053567.2.1376548530574.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<17371B5F-7E7D-4D82-B8B8-11EEFD70F6B0@nimbisservices.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-08-20 22:18:00',-14400,'2012-08-21 02:18:00',NULL,'[Openstack-operators] Reducing ext4/qcow2 snapshot size','\n\nOn Aug 20, 2012, at 10:11 PM, Shake Chen <shake.chen at gmail.com> wrote:\n\n> \n> \n> On Tue, Aug 21, 2012 at 9:04 AM, Lorin Hochstein <lorin at nimbisservices.com> wrote:\n> \n> On Aug 20, 2012, at 12:47 PM, Samuel Winchenbach <swinchen at gmail.com> wrote:\n> \n>> Hi all,\n>> \n>> I launched a large (100 GB) VM and made the changes I wanted\n>> (installed software, created users, etc...)  and made a snapshot.\n>> Now I would like to launch VMs from that snapshot with a smaller disk\n>> size, but no mater what flavor I select it always creates a 100GB\n>> image.\n>> \n>> Is there a way to reduce the ext4 partition size inside the qcow2 disk\n>> image?   It might involve creating a new image file and cloning over\n>> the original image?  If so what tools do you use for the cloning?\n>> \n> \n> Sam:\n> \n> You can mount the qcow2 image in your file system using qemu-nbd (see http://en.wikibooks.org/wiki/QEMU/Images#Mounting_an_image_on_the_host) and then resize the partition using the e2fsprogs tools (e.g., see http://en.positon.org/post/Resize-an-ext3-ext4-partition).\n> \n> \n> I believe you can also use libguestfs <http://libguestfs.org/> as an alternative to qemu-nbd, but I\'ve never tried it.\n> \n> \n> \n> whether is possible done it auto when create snapshot?\n\n\nWhoops, I didn\'t read the original post closely enough. I\'m not sure how to manipulate a qcow2 image that was created as a snapshot.\n\nTake care,\n\nLorin\n--\nLorin Hochstein\nLead Architect - Cloud Services\nNimbis Services, Inc.\nwww.nimbisservices.com\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120820/04987106/attachment.html>\n\n','<CAO__-Nb51zx-QrA8f+CeE2bHDnoVLB3Cq8oK=N+fbEtU9OaACQ@mail.gmail.com>',NULL),('<1737254898.387.1355184921208.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-11 00:15:21',0,'2012-12-11 00:15:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-folsom #71','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/71/>\n\n------------------------------------------\n[...truncated 11063 lines...]\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nFailure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found) ... ERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\nERROR\n\n======================================================================\nERROR: Failure: RuntimeError (Config file /opt/stack/new/tempest/etc/tempest.conf not found)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/loader.py\", line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"/usr/lib/python2.7/dist-packages/nose/importer.py\", line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/__init__.py\", line 27, in <module>\n    CONFIG = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 340, in setUpClass\n    super(UsersTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 76, in setUpClass\n    super(BaseIdentityAdminTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.identity.admin.test_users.UsersTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/admin/test_users.py\", line 346, in setUpClass\n    super(UsersTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 85, in setUpClass\n    super(BaseIdentityAdminTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/identity/base.py\", line 29, in setUpClass\n    os = openstack.IdentityManager(interface=cls._interface)\n  File \"/opt/stack/new/tempest/tempest/openstack.py\", line 234, in __init__\n    conf = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_actions.VolumesActionsTest\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_actions.py\", line 28, in setUpClass\n    super(VolumesActionsTest, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 110, in setUpClass\n    super(VolumesGetTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_get.VolumesGetTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_get.py\", line 102, in setUpClass\n    super(VolumesGetTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestJSON\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 112, in setUpClass\n    super(VolumeListTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 155, in setUpClass\n    super(BaseVolumeTestJSON, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n======================================================================\nERROR: test suite for <class \'tempest.tests.volume.test_volumes_list.VolumeListTestXML\'>\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 208, in run\n    self.setUp()\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 291, in setUp\n    self.setupContext(ancestor)\n  File \"/usr/lib/python2.7/dist-packages/nose/suite.py\", line 314, in setupContext\n    try_run(context, names)\n  File \"/usr/lib/python2.7/dist-packages/nose/util.py\", line 478, in try_run\n    return func()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/test_volumes_list.py\", line 66, in setUpClass\n    super(VolumeListTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 162, in setUpClass\n    super(BaseVolumeTestXML, cls).setUpClass()\n  File \"/opt/stack/new/tempest/tempest/tests/volume/base.py\", line 38, in setUpClass\n    cls.config = config.TempestConfig()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 388, in getinstance\n    instances[cls] = cls()\n  File \"/opt/stack/new/tempest/tempest/config.py\", line 419, in __init__\n    raise RuntimeError(msg)\nRuntimeError: Config file /opt/stack/new/tempest/etc/tempest.conf not found\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 1 test in 0.041s\n\nFAILED (errors=8)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/rabbitmq/rabbit at devstack-1355178686-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/rabbitmq/rabbit at devstack-1355178686.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-n-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-folsom/71/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<411408432.354.1355098378918.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1737298849.0.1376547199773.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-15 06:13:19',0,'2013-08-15 06:13:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-grizzly #5','See <https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/5/>\n\n------------------------------------------\n[...truncated 3737 lines...]\n======================================================================\nERROR: test_user_get (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 570, in test_user_get\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_get_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 518, in test_user_get_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 563, in test_user_list\n    client = self.get_client(admin=True)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 74, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 2, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 17, in <module>\n    from keystoneclient import exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 525, in test_user_list_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 859, in test_user_role_add_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 878, in test_user_role_remove_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 532, in test_user_update_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/tests/test_keystoneclient.py\",> line 548, in test_user_update_password_404\n    from keystoneclient import exceptions as client_exceptions\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/exceptions.py\",> line 7, in <module>\n    from keystoneclient.openstack.common import jsonutils\n  File \"<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/vendor/python-keystoneclient-master/keystoneclient/openstack/common/jsonutils.py\",> line 44, in <module>\n    import netaddr\nImportError: No module named netaddr\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py27/bin/nosetests on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 33.90 secs:\n    8.27    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    7.03    TestTokenRevoking.test_group_membership_changes_revokes_token\n    6.47    TestTokenRevoking.test_unscoped_token_remains_valid_after_role_assignment\n    6.16    TestTokenRevoking.test_removing_role_assignment_does_not_affect_other_users\n    5.97    TestTokenAPIs.test_revoke_token\n----------------------------------------------------------------------\nRan 1300 tests in 444.419s\n\nFAILED (SKIP=84, errors=134)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-keystone-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.6\nargparse==1.2.1\nbeautifulsoup4==4.2.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.6.1\nkeystone==jenkins.periodic.keystone.python27.stable.grizzly.5\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npam==0.1.4\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npycparser==2.10\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.5\npython-ldap==2.3.13\npython-memcached==1.53\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.0.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.5\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=69\n+ \'[\' 69 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.C6LdmEDX2D\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-grizzly/precise5/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1738040464.404844.1386877206904.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-12 20:40:06',3600,'2013-12-12 19:40:06',NULL,'[openstack-dev] Unified Guest Agent proposal','Dmitry,\n\nI understand that :)\nThe only hypervisor dependency it has is how it communicates with the host, while this can be extended and turned into a binding, so people could connect to it in multiple ways.\n\nThe real value, as I see it, is which features this guest agent already implements and the fact that this is a mature code base.\n\nThanks,\nVladik \n\n----- Original Message -----\n> From: \"Dmitry Mescheryakov\" <dmescheryakov at mirantis.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, 12 December, 2013 12:27:47 PM\n> Subject: Re: [openstack-dev] Unified Guest Agent proposal\n> \n> Vladik,\n> \n> Thanks for the suggestion, but hypervisor-dependent solution is exactly what\n> scares off people in the thread :-)\n> \n> Thanks,\n> \n> Dmitry\n> \n> \n> 2013/12/11 Vladik Romanovsky < vladik.romanovsky at enovance.com >\n> \n> \n> \n> Maybe it will be useful to use Ovirt guest agent as a base.\n> \n> http://www.ovirt.org/Guest_Agent\n> https://github.com/oVirt/ovirt-guest-agent\n> \n> It is already working well on linux and windows and has a lot of\n> functionality.\n> However, currently it is using virtio-serial for communication, but I think\n> it can be extended for other bindings.\n> \n> Vladik\n> \n> ----- Original Message -----\n> > From: \"Clint Byrum\" < clint at fewbar.com >\n> > To: \"openstack-dev\" < openstack-dev at lists.openstack.org >\n> > Sent: Tuesday, 10 December, 2013 4:02:41 PM\n> > Subject: Re: [openstack-dev] Unified Guest Agent proposal\n> > \n> > Excerpts from Dmitry Mescheryakov\'s message of 2013-12-10 12:37:37 -0800:\n> > > >> What is the exact scenario you\'re trying to avoid?\n> > > \n> > > It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server\n> > > (Salt / Our own self-written server). Looking at the design, it doesn\'t\n> > > look like the attack could be somehow contained within a tenant it is\n> > > coming from.\n> > > \n> > \n> > We can push a tenant-specific route for the metadata server, and a tenant\n> > specific endpoint for in-agent things. Still simpler than hypervisor-aware\n> > guests. I haven\'t seen anybody ask for this yet, though I\'m sure if they\n> > run into these problems it will be the next logical step.\n> > \n> > > In the current OpenStack design I see only one similarly vulnerable\n> > > component - metadata server. Keeping that in mind, maybe I just\n> > > overestimate the threat?\n> > > \n> > \n> > Anything you expose to the users is \"vulnerable\". By using the localized\n> > hypervisor scheme you\'re now making the compute node itself vulnerable.\n> > Only now you\'re asking that an already complicated thing (nova-compute)\n> > add another job, rate limiting.\n> > \n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<CALU-hjFF9YrY7By2UUXfax6D9q_JA2g1FkxNe+jTS6fN7qjkmg@mail.gmail.com>',NULL),('<1738769525.60.1383459724397.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-03 06:22:04',0,'2013-11-03 06:22:04',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-neutron-python27-stable-grizzly #46','See <https://jenkins01.openstack.org/job/periodic-neutron-python27-stable-grizzly/46/>\n\n\n\n','<814229277.48.1383373337372.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1739374439.195.1356480580903.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-26 00:09:40',0,'2012-12-26 00:09:40',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-folsom #86','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/86/>\n\n------------------------------------------\n[...truncated 4953 lines...]\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 809, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 828, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 484, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 500, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 95, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/tests/test_keystoneclient.py\",> line 71, in _client\n    from keystoneclient.v2_0 import client as ks_client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/__init__.py\",> line 1, in <module>\n    from keystoneclient.v2_0.client import Client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 18, in <module>\n    from keystoneclient import client\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-folsom/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 16, in <module>\n    import requests\nImportError: No module named requests\n-------------------- >> begin captured logging << --------------------\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nkeystone.common.wsgi: DEBUG: Starting run_tests.py on 127.0.0.1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.87 secs:\n    2.58    Kc11TestCase.test_admin_requires_adminness\n    2.37    KcEssex3TestCase.test_admin_requires_adminness\n    2.32    KcMasterTestCase.test_admin_requires_adminness\n    1.51    TokenExpirationTest.test_maintain_uuid_token_expiration\n    1.08    Kc11TestCase.test_token_expiry_maintained\n----------------------------------------------------------------------\nRan 670 tests in 49.863s\n\nFAILED (SKIP=11, errors=128)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.3\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.6b2\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.7\niso8601==0.1.4\nkeystone==2012.2.3\nlogilab-astng==0.24.1\nlogilab-common==0.58.3\nlxml==3.1beta1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosehtmloutput==0.0.4\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.6.1\npylint==0.26.0\npython-keystoneclient==0.1.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\nswift==1.7.6\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=39\n+ \'[\' 39 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.yiHUUqwSB7\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/86\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-folsom/86/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<825204885.179.1356394195562.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1739418197.267.1358812937846.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-22 00:02:17',0,'2013-01-22 00:02:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python26-stable-folsom #113','See <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/113/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/>\nCheckout:periodic-swift-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/> - hudson.remoting.Channel at 29dee714:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0.3\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\nChecking out Revision 9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc (origin/stable/folsom)\n[periodic-swift-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson6399302517989123478.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26\n+ version=26\n+ \'[\' -z 26 \']\'\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.jVp5IrSUZ3\n+ TMPDIR=/tmp/tmp.jVp5IrSUZ3\n+ trap \'rm -rf /tmp/tmp.jVp5IrSUZ3\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'--download-cache=<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/113/\', \'BUILD_TAG\': \'jenkins-periodic-swift-python26-stable-folsom-113\', \'SSH_CLIENT\': \'198.101.231.203 50178 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-swift-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1358004605.676584-1419924838\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric2\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.jVp5IrSUZ3\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-01-22_00-01-34\', \'BUILD_NUMBER\': \'113\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'6473bd7b-aacb-4b6c-9e3e-e77f34f4460b\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'9c4c7bb05ce93b20bba7cf77e39d19d226eea8dc\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric2\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 50178 166.78.31.224 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking WebOb>=1.0.8,<1.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 1))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FWebOb%2FWebOb-1.2.3.tar.gz>\n  Running setup.py egg_info for package WebOb\n    no previously-included directories found matching \'*.pyc\'\n    no previously-included directories found matching \'*.pyo\'\nDownloading/unpacking configobj==4.7.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 2))\n  Downloading configobj-4.7.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fconfigobj%2Fconfigobj-4.7.1.tar.gz>\n  Running setup.py egg_info for package configobj\nDownloading/unpacking eventlet==0.9.15 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 3))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Feventlet%2Feventlet-0.9.15.tar.gz>\n  Running setup.py egg_info for package eventlet\nDownloading/unpacking greenlet==0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading greenlet-0.3.1.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fgreenlet%2Fgreenlet-0.3.1.tar.gz>\n  Running setup.py egg_info for package greenlet\n    /usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: \'repository\'\n      warnings.warn(msg)\nDownloading/unpacking netifaces==0.6 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 5))\n  Downloading netifaces-0.6.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fnetifaces%2Fnetifaces-0.6.tar.gz>\n  Running setup.py egg_info for package netifaces\nDownloading/unpacking pastedeploy==1.3.3 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 6))\n  Real name of requirement pastedeploy is PasteDeploy\n  Downloading PasteDeploy-1.3.3.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2FPasteDeploy%2FPasteDeploy-1.3.3.tar.gz>\n  Running setup.py egg_info for package pastedeploy\n    warning: no files found matching \'docs/*.html\'\n    warning: no previously-included files found matching \'docs/rebuild\'\nDownloading/unpacking simplejson==2.0.9 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 7))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fsimplejson%2Fsimplejson-2.0.9.tar.gz>\n  Running setup.py egg_info for package simplejson\nDownloading/unpacking xattr==0.4 (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 8))\n  Downloading xattr-0.4.tar.gz\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/http%3A%2F%2Fpypi.openstack.org%2Fxattr%2Fxattr-0.4.tar.gz>\n  Running setup.py egg_info for package xattr\nDownloading/unpacking python-swiftclient from https://github.com/openstack/python-swiftclient/zipball/master (from -r <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires> (line 11))\n  Storing download in cache at <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/_download/https%3A%2F%2Fgithub.com%2Fopenstack%2Fpython-swiftclient%2Fzipball%2Fmaster>\n  Running setup.py egg_info for package python-swiftclient\n    Traceback (most recent call last):\n      File \"<string>\", line 16, in <module>\n      File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n        version=setup.get_version(name),\n      File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n        raise Exception(\"Versioning for this project requires either an sdist\"\n    Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n    Complete output from command python setup.py egg_info:\n    Traceback (most recent call last):\n\n  File \"<string>\", line 16, in <module>\n\n  File \"<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient/setup.py\",> line 35, in <module>\n\n    version=setup.get_version(name),\n\n  File \"swiftclient/openstack/common/setup.py\", line 311, in get_version\n\n    raise Exception(\"Versioning for this project requires either an sdist\"\n\nException: Versioning for this project requires either an sdist tarball, or access to an upstream git repository.\n\n----------------------------------------\nCommand python setup.py egg_info failed with error code 1 in <https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/.tox/py26/build/python-swiftclient>\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-swift-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.31\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.jVp5IrSUZ3\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python26-stable-folsom/113\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1740103391.2712545.1360848780092.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-02-14 08:33:00',-18000,'2013-02-14 13:33:00',NULL,'[openstack-qa] New Client Test Suite','Very good idea!\n\nI think it can fit into tempest repository,  but in a different directory.\n\nI would extend a scope too.\n\nAt the first Round:\n- *mange command tests. \n- remote execution (with ssh connection pooling)\nThe whitebox test type (not the existing test case), partially should be converted to utilities, partially the functionality should move to the new folder.\nhttps://github.com/openstack/tempest/blob/master/tempest/whitebox.py#L138\n\n\n----- Original Message -----\n> From: \"Daryl Walleck\" <daryl.walleck at RACKSPACE.COM>\n> To: \"All Things QA.\" <openstack-qa at lists.openstack.org>\n> Sent: Thursday, February 14, 2013 3:33:20 AM\n> Subject: Re: [openstack-qa] New Client Test Suite\n> \n> \n> \n> \n> \n> We\'ve bumped into some Novaclient only issues before in the past as\n> well. Sam and some of his team did prototype some tests that execute\n> using Novaclient. If there\'s any interest I can see about getting it\n> into a WIP branch to get eyes on it.\n> \n> \n> \n> Daryl\n> \n> \n> From: Joe Gordon [jogo at cloudscaling.com]\n> Sent: Tuesday, February 12, 2013 4:39 PM\n> To: openstack-qa at lists.openstack.org\n> Subject: [openstack-qa] New Client Test Suite\n> \n> \n> \n> \n> Hi All,\n> \n> We currently have thorough API tests (Tempest) that do an excellent\n> job of testing nova, glance, keystone, etc. But to date we don\'t\n> have anything that tests the assorted python clients.\n> \n> \n> Extensive python client tests, which would consist of mostly shell\n> commands, would prevent many bugs from arising such as:\n> https://bugs.launchpad.net/python-novaclient/+bug/1122958 .\n> \n> \n> The question is where should theses tests live?\n> \n> \n> * Devstack/smoketests - these are just smoketests and are not\n> designed to be exhaustive\n> * Tempest - currently explicitly doesn\'t use the python clients, but\n> we can add a separate folder that tests the clients\n> * In respective client repos - easier to require new tests when\n> adding to client, but will result in divergent test suites\n> * Separate Repo - perhaps this is premature?\n> \n> \n> I propose adding a separate folder in tempest to run the python\n> client tests, and taking it from there.\n> \n> \n> \n> \n> best,\n> Joe Gordon\n> _______________________________________________\n> openstack-qa mailing list\n> openstack-qa at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n> \n\n\n','<BF1FE6A2EBA2D54BBF44C3128B132D9C6941039D@ORD1EXD04.RACKSPACE.CORP>',NULL),('<1740131110.4901895.1396301052673.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 17:24:12',-14400,'2014-03-31 21:24:12',NULL,'[openstack-dev] [Nova] Juno open for development','There was some talk about updating the CI for Juno.\nHas this been done/when will this be done?\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Russell Bryant\" <rbryant at redhat.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Monday, March 31, 2014 2:23:32 PM\nSubject: [openstack-dev] [Nova] Juno open for development\n\nWe just merged the change that opens the master branch for Juno development:\n\n    https://review.openstack.org/#/c/83752/\n\nWe will be releasing icehouse-rc1 from the commit that precedes the\nabove patch.  If anything comes up that warrants another release\ncandidates, please get in contact with me directly.\n\nOn the Juno front, we are now ready to start accepting and reviewing\nJuno blueprints.  The process is documented here:\n\n    https://wiki.openstack.org/wiki/Blueprints#Creation\n\nIf you have any questions not answered by that page, please bring them\nup so that we can ensure the process is adequately documented.\n\nThanks,\n\n-- \nRussell Bryant\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5339B2A4.5090904@redhat.com>',NULL),('<1740238299.64.1375769976969.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-06 06:19:36',0,'2013-08-06 06:19:36',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-neutron-stable-grizzly #34','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/34/>\n\n\n\n','<471278188.54.1375682595914.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1740319377.1213620.1395068512402.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-17 11:01:52',-14400,'2014-03-17 15:01:52',NULL,'[openstack-dev] [Neutron] Docs for new plugins','----- Original Message -----\n> Edgar:\n> \n> I don\'t see the configuration options for the OpenDaylight ML2\n> MechanismDriver\n> added here yet, even though the code was checked in well over a week ago.\n> How long does it take to autogenerate this page from the code?\n> \n> Thanks!\n> Kyle\n\nAdding the docs list, I suspect there are two issues here. The first is that the generation of the config-reference content is initiated manually and potentially hasn\'t been done since this was added. The second is that prior to running it the flag mappings file needs to be updated [1], this maps a given configuration option to a group and is the main hole in our current automation process for this guide.\n\nEdgar/Kyle can you check whether the new options are listed in there and we\'ll arrange to get this re-generated for rc1?\n\nThanks,\n\nSteve\n\n[1] http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/neutron.flagmappings\n\n> On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana <emagana at plumgrid.com> wrote:\n> \n> > You should be able to add your plugin here:\n> >\n> > http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html\n> >\n> > Thanks,\n> >\n> > Edgar\n> >\n> > From: Mohammad Banikazemi <mb at us.ibm.com>\n> > Date: Monday, March 10, 2014 2:40 PM\n> > To: OpenStack List <openstack-dev at lists.openstack.org>\n> > Cc: Edgar Magana <emagana at plumgrid.com>\n> > Subject: Re: [openstack-dev] [Neutron] Docs for new plugins\n> >\n> > Would like to know what to do for adding documentation for a new plugin.\n> > Can someone point me to the right place/process please.\n> >\n> > Thanks,\n> >\n> > Mohammad\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nProduct Manager, Red Hat Enterprise Linux OpenStack Platform\nRed Hat Canada (Toronto, Ontario)\n\n\n','<CADEmHi17oR9Ztf0DeXdC_kgdzA1KEZHMW+E8Bd5brMVOHkV_bQ@mail.gmail.com>',NULL),('<1740319377.1213620.1395068512402.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-17 11:01:52',-14400,'2014-03-17 15:01:52',NULL,'[Openstack-docs] [openstack-dev] [Neutron] Docs for new plugins','----- Original Message -----\n> Edgar:\n> \n> I don\'t see the configuration options for the OpenDaylight ML2\n> MechanismDriver\n> added here yet, even though the code was checked in well over a week ago.\n> How long does it take to autogenerate this page from the code?\n> \n> Thanks!\n> Kyle\n\nAdding the docs list, I suspect there are two issues here. The first is that the generation of the config-reference content is initiated manually and potentially hasn\'t been done since this was added. The second is that prior to running it the flag mappings file needs to be updated [1], this maps a given configuration option to a group and is the main hole in our current automation process for this guide.\n\nEdgar/Kyle can you check whether the new options are listed in there and we\'ll arrange to get this re-generated for rc1?\n\nThanks,\n\nSteve\n\n[1] http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/neutron.flagmappings\n\n> On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana <emagana at plumgrid.com> wrote:\n> \n> > You should be able to add your plugin here:\n> >\n> > http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html\n> >\n> > Thanks,\n> >\n> > Edgar\n> >\n> > From: Mohammad Banikazemi <mb at us.ibm.com>\n> > Date: Monday, March 10, 2014 2:40 PM\n> > To: OpenStack List <openstack-dev at lists.openstack.org>\n> > Cc: Edgar Magana <emagana at plumgrid.com>\n> > Subject: Re: [openstack-dev] [Neutron] Docs for new plugins\n> >\n> > Would like to know what to do for adding documentation for a new plugin.\n> > Can someone point me to the right place/process please.\n> >\n> > Thanks,\n> >\n> > Mohammad\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> >\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nProduct Manager, Red Hat Enterprise Linux OpenStack Platform\nRed Hat Canada (Toronto, Ontario)\n\n\n','<CADEmHi17oR9Ztf0DeXdC_kgdzA1KEZHMW+E8Bd5brMVOHkV_bQ@mail.gmail.com>',NULL),('<1740416462.9118224.1391542028537.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-04 14:27:08',-18000,'2014-02-04 19:27:08',NULL,'[openstack-dev] Ugly Hack to deal with multiple versions','----- Original Message -----\n\n> From: \"Adam Young\" <ayoung at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, February 5, 2014 2:29:18 AM\n> Subject: Re: [openstack-dev] Ugly Hack to deal with multiple versions\n\n> On 02/04/2014 11:09 AM, Dean Troyer wrote:\n\n> > On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague < sean at dague.net > wrote:\n> \n\n> > > Can you be more specific about what goes wrong here? I\'m not entirely\n> > \n> \n> > > sure I understand why an old client of arbitrary age needs to be\n> > \n> \n> > > supported with new OpenStack. The contract is the API, not the client,\n> > \n> \n> > > and an old client that doesn\'t do version discovery is just a buggy\n> > \n> \n> > > client from what I\'m concerned. Time to release a new version.\n> > \n> \n\n> Remember: the client is not the only code that Keystone has to worry about.\n> THere is also a whole cotteage industry that is talking direct to the\n> endpoints themselves. We\'ve trained these poor souls to expect the version\n> in the Endpoint. So even if we said \"we are only supporting the latest\n> Keystone client\" we\'d still have to deal with code that expects the identity\n> endpoint URL to look like this:\n\n> https://hostname:35357/v2.0/\n\n> We want people to be able to call on the V3 API. To be able to do version\n> discovery, the identity endpoint URL should look like this:\n\n> https://hostname:35357/\n\n> And then they can navigate down to\n\n> https://hostname:35357/v3\n\n> Via discovery. So, what I am proposing for Keystone (here:\n> https://review.openstack.org/#/c/62801/ ) is that we do this\n\n> If the Catalog endpoint looks like this: https://hostname:35357/v2.0/ chop\n> off /v2.0 and call on it for discover.\n\n> Now, the code In that link *will* work the same on a\n> https://hostname:35357/v3/ due to the regex (copied from termie who\n> recognized this problem long ago) and that may scare you into saying \"won\'t\n> we have this problem in the future?\"\n\n> Maybe, if we are stupid. We\'ve been stupid before, so I can\'t promise\n> anything. However, much more important is that, as the tools for deployment\n> get smarter, they stop putting out Service catalogs with versions in the\n> URLS. They would have to deliberately replace an explicit /v3 into the url\n> in place of the V2.0 Then, yes, the hack would still silently work.\n\n> But without the hack, if they only check against the the V3 API, it will\n> still work, too. Broken again, and we are back here....this really is\n> something that requires education across the deployers.\n\nSo we\'ve been around this problem a few times and i\'ve tried every other solution i can think of and it never quite works so i pretty much agree. \n\nWhat i\'d like to know and see really well defined is how we get out of this position once we\'re in it. Yes we can educate deployers and such but at some point we have the situation where our clients are going to be able to accept an endpoint from the service catalog that is wrong and we\'ll need to deprecate that behaviour. The ripping a band-aid metaphor seems appropriate here, When do we get to deprecate this and are we just delaying (possibly increasing as now we have to deprecate changes on the server and on the client) that pain that we could just declare a one-off hit for? \n\n(Note that i am well aware that even our own clients cannot handle this currently, things would still need to be fixed) \n\n> > Problem 1: API version discovery is not universally considered to be part\n> > of\n> > the API and therefore is not defined by most services beyond them\n> > responding\n> > to a \'/\' request with a 300 response and a list of versions. No two of\n> > these\n> > responses look alike except where the source was copied from an existing\n> > service.\n> \n\n> > Problem 2: Identity is unique in that it is handed a deployment-defined URL\n> > to authenticate and get endpoints for all other services. Most of these\n> > auth\n> > URLs have a version hard-coded in them because the client didn\'t do version\n> > discovery or negotiation until recently. This is what we\'re talking about\n> > here, how to remove the version from this URL and not break old clients. We\n> > can\'t. Not without doing nasty things like detecting an old client and\n> > compensating for it server-side. So we have to work out a way for new\n> > clients to do discovery even when handed a URL that has a version in it.\n> \n\n> > I\'ve tested a couple of more generalized approaches, and the best solution\n> > I\n> > have found so far is to simply special-case the known legacy behaviour then\n> > drop in to the general discovery process.\n> \n\n> > > I also wonder if this is an issue with version discovery implementation.\n> > \n> \n> > > It seems like if we think this is going to be affecting multiple\n> > \n> \n> > > services before doing an odd hack for keystone, we should actually\n> > \n> \n> > > figure out a pattern that works for all services, and figure out why\n> > \n> \n> > > this has only just become an issue. Most of the other services have done\n> > \n> \n\n> > The services that traditionally embed a version inside the URL followed by\n> > a\n> > tenant ID or something get even deeper into parsing the URL to hack the\n> > version.\n> \n\n> > > dual APIs at some point over the last 2 years, and this didn\'t seem to\n> > \n> \n> > > trip them up too badly. What happened differently in keystone that made\n> > \n> \n> > > this an issue? And what can be learned about how we structure APIs going\n> > \n> \n> > > forward.\n> > \n> \n> > I think the difference is this is the first API we have actually tried to\n> > deprecate and we don\'t have the option to hide it in an updated SC\n> > endpoint.\n> > The service catalog has hidden a lot of this pain for other services\n> > because\n> > the clients generally can use whatever endpoint the SC gives it.\n> \n\n> > a) Version discovery needs to be rationalized across the services. We\'ve\n> > talked about this at summits before, and proposals have been written. And\n> > here we are. We\'ll do it again in Atlanta, hopefully for the last time.\n> \n\n> > b) Define a common structured endpoint and let the client assemble the\n> > components into the final URL. If the service catalog had a base URL for\n> > compute, and a list of versions, and the additional bits to be appended the\n> > client could make an intelligent choice and assemble the endpoint. It isn\'t\n> > like the client doesn\'t already have to know how the REST URLs are\n> > constructed.\n> \n\n> > b-alt) Stop putting things like tenant IDs in the SC. This has the same\n> > issue\n> > as the auth URL in how to do this without instantly breaking the existing\n> > clients.\n> \n\n> > dt\n> \n\n> > --\n> \n\n> > Dean Troyer\n> \n> > dtroyer at gmail.com\n> \n\n> > _______________________________________________\n> \n> > OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/0efb85e2/attachment.html>\n\n','<52F1155E.2050808@redhat.com>',NULL),('<1740845013.13.1374300287468.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-20 06:04:47',0,'2013-07-20 06:04:47',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #292','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/292/>\n\n------------------------------------------\n[...truncated 8986 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 204, in test_workflow_finalization\n    self.assertTrue(flow.finalize())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 747, in finalize\n    exceptions.handle(self.request)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 0.89 secs:\n    0.38    RoleAPITests.test_get_default_role\n    0.16    HorizonTests.test_lazy_urls\n    0.14    DataTableTests.test_summation_row\n    0.12    DataTableTests.test_table_action_attributes\n    0.10    NetworkTests.test_subnet_create_post\n----------------------------------------------------------------------\nRan 350 tests in 4.871s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.6\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.iys94aOvtC\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/292\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/292/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/292/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<713096430.9.1374214032438.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<174096703.80.1357885680412.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-11 06:28:00',0,'2013-01-11 06:28:00',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-postgres-vm-full #64','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-postgres-vm-full/64/>\n\n------------------------------------------\n[...truncated 14830 lines...]\n+ end_time=1357885005\n+ echo \'Completed cinder create in 3 seconds\'\nCompleted cinder create in 3 seconds\n++ cinder list\n++ grep myvol-0985973b\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 75d60788-9446-4c70-821f-5270eb76a7a0 | available | myvol-0985973b |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=75d60788-9446-4c70-821f-5270eb76a7a0\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for myvol-0985973b\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1357885006\n+ nova volume-attach 7d728588-a436-45d7-9e0a-23e557a9511e 75d60788-9446-4c70-821f-5270eb76a7a0 /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| id       | 75d60788-9446-4c70-821f-5270eb76a7a0 |\n| serverId | 7d728588-a436-45d7-9e0a-23e557a9511e |\n| volumeId | 75d60788-9446-4c70-821f-5270eb76a7a0 |\n+----------+--------------------------------------+\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-0985973b | grep in-use; do sleep 1; done\'\n| 75d60788-9446-4c70-821f-5270eb76a7a0 | in-use | myvol-0985973b |  1   |     None    |  false   | 7d728588-a436-45d7-9e0a-23e557a9511e |\n++ date +%s\n+ end_time=1357885014\n+ echo \'Completed volume-attach in 8 seconds\'\nCompleted volume-attach in 8 seconds\n++ cinder list\n++ grep myvol-0985973b\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| 75d60788-9446-4c70-821f-5270eb76a7a0 | in-use | myvol-0985973b |  1   |     None    |  false   | 7d728588-a436-45d7-9e0a-23e557a9511e |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=7d728588-a436-45d7-9e0a-23e557a9511e\n+ die_if_not_set VOL_ATTACH \'Failure retrieving myvol-0985973b status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 7d728588-a436-45d7-9e0a-23e557a9511e != 7d728588-a436-45d7-9e0a-23e557a9511e ]]\n++ date +%s\n+ start_time=1357885015\n+ nova volume-detach 7d728588-a436-45d7-9e0a-23e557a9511e 75d60788-9446-4c70-821f-5270eb76a7a0\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-0985973b | grep available; do sleep 1; done\'\n| 75d60788-9446-4c70-821f-5270eb76a7a0 | available | myvol-0985973b |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357885021\n+ echo \'Completed volume-detach in 6 seconds\'\nCompleted volume-detach in 6 seconds\n++ date +%s\n+ start_time=1357885021\n+ cinder delete 75d60788-9446-4c70-821f-5270eb76a7a0\n+ timeout 60 sh -c \'while cinder list | grep myvol-0985973b; do sleep 1; done\'\n| 75d60788-9446-4c70-821f-5270eb76a7a0 | deleting | myvol-0985973b |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1357885025\n+ echo \'Completed cinder delete in 4 seconds\'\nCompleted cinder delete in 4 seconds\n+ nova delete 7d728588-a436-45d7-9e0a-23e557a9511e\n+ timeout 60 sh -c \'while nova list | grep -q 7d728588-a436-45d7-9e0a-23e557a9511e; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nRunning tempest smoke tests\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\nSKIP: EC2 InstanceRunTest: requires ami/aki/ari manifest\n-------------------- >> begin captured logging << --------------------\ntempest.config: INFO: Using tempest config file /opt/stack/new/tempest/etc/tempest.conf\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6676\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/users/84e2b3da2c184769b09243d34fd5f635/credentials/OS-EC2 HTTP/1.1\" 200 777\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6676\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"GET /v2.0/users/84e2b3da2c184769b09243d34fd5f635/credentials/OS-EC2 HTTP/1.1\" 200 777\n--------------------- >> end captured logging << ---------------------\ntest_create_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... ok\ntest_delete_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... SKIP: Skipped until the Bug #1072318 is resolved\ntest_duplicate_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... SKIP: Skipped until the Bug #1072762 is resolved\ntest_get_ec2_keypair (tempest.tests.boto.test_ec2_keys.EC2KeysTest) ... ok\ntest_disassociate_not_associated_floating_ip (tempest.tests.boto.test_ec2_network.EC2NetworkTest) ... SKIP: Skipped until the Bug #1080406 is resolved\ntest_create_authorize_security_group (tempest.tests.boto.test_ec2_security_groups.EC2SecurityGroupTest) ... ok\ntest_create_get_delete (tempest.tests.boto.test_ec2_volumes.EC2VolumesTest) ... ok\ntest_create_volme_from_snapshot (tempest.tests.boto.test_ec2_volumes.EC2VolumesTest) ... ok\ntest_create_and_get_delete_bucket (tempest.tests.boto.test_s3_buckets.S3BucketsTest) ... SKIP: Skipped until the Bug #1076965 is resolved\nSKIP: EC2 S3ImagesTest: requires ami/aki/ari manifest\ntest_create_get_delete_object (tempest.tests.boto.test_s3_objects.S3BucketsTest) ... SKIP: Skipped until the Bug #1076534 is resolved\ntest_get_default_quotas (tempest.tests.compute.admin.test_quotas.QuotasTest) ... ok\ntest_get_flavor (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_list_flavors (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_list_flavors_with_detail (tempest.tests.compute.flavors.test_flavors.FlavorsTestJSON) ... ok\ntest_get_flavor (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\ntest_list_flavors (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\ntest_list_flavors_with_detail (tempest.tests.compute.flavors.test_flavors.FlavorsTestXML) ... ok\nSKIP: Until Bug 1046870 is fixed\nSKIP: Until Bug 1046870 is fixed\ntest_get_image (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_list_images (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_list_images_with_detail (tempest.tests.compute.images.test_list_images.ListImagesTest) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestAutoDisk) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestJSON) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestJSON) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestJSON) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestJSON) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestManualDisk) ... ok\ntest_create_server_response (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_list_servers (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_list_servers_with_detail (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_verify_server_details (tempest.tests.compute.servers.test_create_server.ServersTestXML) ... ok\ntest_change_server_password (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Change password not available.\ntest_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... ERROR\ntest_reboot_server_soft (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Until bug 1014647 is dealt with.\ntest_rebuild_server (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... ok\ntest_resize_server_confirm (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON) ... SKIP: Resize not available.\ntest_change_server_password (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Change password not available.\ntest_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... ok\ntest_reboot_server_soft (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Until bug 1014647 is dealt with.\ntest_rebuild_server (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... ok\ntest_resize_server_confirm (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML) ... SKIP: Resize not available.\ntest_list_server_addresses (tempest.tests.compute.servers.test_server_addresses.ServerAddressesTest) ... ok\ntest_list_server_addresses_by_network (tempest.tests.compute.servers.test_server_addresses.ServerAddressesTest) ... ok\ntest_volume_create_get_delete (tempest.tests.compute.volumes.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.compute.volumes.test_volumes_get.VolumesGetTestXML) ... ok\ntest_get_default_quotas (tempest.tests.compute.test_quotas.QuotasTest) ... ok\ntest_create_user (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_delete_user (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_get_users (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_user_authentication (tempest.tests.identity.admin.test_users.UsersTestJSON) ... ok\ntest_create_user (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_delete_user (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_get_users (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_user_authentication (tempest.tests.identity.admin.test_users.UsersTestXML) ... ok\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\n\n======================================================================\nERROR: test_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestJSON)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_server_actions.py\", line 230, in setUp\n    ServerActionsTestBase.setUp(self)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_server_actions.py\", line 44, in setUp\n    self.client.wait_for_server_status(self.server_id, \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/json/servers_client.py\", line 156, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 2421eeac-c972-44d9-a48f-e2e6bf627497 failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-smoke.xml\n----------------------------------------------------------------------\nRan 84 tests in 597.949s\n\nFAILED (SKIP=15, errors=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/rabbitmq/rabbit at devstack-1357877491-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/rabbitmq/rabbit at devstack-1357877491.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-postgres-vm-full/64/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<386839424.48.1357779201666.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1741235807.7.1375855350492.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-07 06:02:30',0,'2013-08-07 06:02:30',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-stable-grizzly #2','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/2/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on devstack-precise-hpcloud-az1-1270 in workspace <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-stable-grizzly/ws/>\nWaiting for the completion of devstack-update-inprogress\ndevstack-update-inprogress #1257 completed. Result was SUCCESS\nBuild step \'Trigger/call builds on other projects\' changed build result to SUCCESS\n[periodic-tempest-devstack-vm-stable-grizzly] $ /bin/bash -xe /tmp/hudson204483134560780513.sh\n+ [[ ! -e devstack-gate ]]\n+ git clone https://review.openstack.org/p/openstack-infra/devstack-gate\nCloning into \'devstack-gate\'...\n[periodic-tempest-devstack-vm-stable-grizzly] $ /bin/bash -xe /tmp/hudson6767159330102546617.sh\n+ export PYTHONUNBUFFERED=true\n+ PYTHONUNBUFFERED=true\n+ export DEVSTACK_GATE_TEMPEST=1\n+ DEVSTACK_GATE_TEMPEST=1\n+ export DEVSTACK_GATE_TEMPEST_FULL=1\n+ DEVSTACK_GATE_TEMPEST_FULL=1\n+ export ZUUL_BRANCH=stable/grizzly\n+ ZUUL_BRANCH=stable/grizzly\n+ cp devstack-gate/devstack-vm-gate-wrap.sh ./safe-devstack-vm-gate-wrap.sh\n+ ./safe-devstack-vm-gate-wrap.sh\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-1270\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-1270/2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-1270/2/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-stable-grizzly/devstack-precise-hpcloud-az1-1270/2/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<926863225.3.1375768933229.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1741327935.47115681.1410368429208.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-10 13:00:29',-14400,'2014-09-10 17:00:29',NULL,'[openstack-dev] [Horizon] Licensing issue with using JSHint in\n build','JSHint *isn\'t* Douglas Crockford.  It was written by someone who (understandably)\nthought Douglas Crockford had some good ideas, but was overzealous.  It does mostly the\nsame things, but is more lenient with regards to style elements.\n\nThe license is as such: https://github.com/jshint/jshint/blob/master/LICENSE\n\nYou are thinking of JSLint, which is written by Douglas Crockford.\n\n----- Original Message -----\n> From: \"Aaron Sahlin\" <asahlin at linux.vnet.ibm.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, September 10, 2014 11:56:37 AM\n> Subject: [openstack-dev] [Horizon] Licensing issue with using JSHint in build\n> \n> I noticed that the build is using JSHint now, and before I consider\n> syncing it with the proposed options from the JavaScript best practices\n> (https://review.openstack.org/#/c/117595/), I wanted to double check and\n> be sure Horizon got past the legal problem with the good/evil licensing.\n> \n> Some background for those who are not aware.   JSHint was authored by\n> Doug Crockford, and he added an extra line in the licensing, \"The\n> software shall be used for good, not evil\".  The issue is in the\n> definition of what is good and what is evil.   It is too subjective,\n> what is evil differs from person to person therefore ends up being a\n> liability and leaving users open to frivolous lawsuits.\n> \n> Did Horizon get permission or find some way around the licensing issue?\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<541074B5.50507@linux.vnet.ibm.com>',NULL),('<1742005326.21.1352852132636.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-14 00:15:32',0,'2012-11-14 00:15:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-swift-python27-stable-diablo #92','See <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/92/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric2 in workspace <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/>\nCheckout:periodic-swift-python27-stable-diablo / <https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/> - hudson.remoting.Channel at 276b998f:oneiric2\nUsing strategy: Default\nLast Built Revision: Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/swift.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/swift.git\nCommencing build of Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\nChecking out Revision d415db9af18749356123c43f1f9754d309a60505 (origin/stable/diablo)\n[periodic-swift-python27-stable-diablo] $ /bin/bash -xe /tmp/hudson1583573228121353873.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27\n+ version=27\n+ \'[\' -z 27 \']\'\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ tox -epy27\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-swift-python27-stable-diablo/ws/tox.ini\'> does not exist\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\n/usr/local/jenkins/slave_scripts/run-tox.sh: line 38: .tox/py27/bin/pip: No such file or directory\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-swift-python27-stable-diablo/92\n[SCP] Copying console log.\n\n\n','<215001624.61.1352765564265.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1742086121.374.1367042681587.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:04:41',0,'2013-04-27 06:04:41',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #208','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/208/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric5 in workspace <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/>\nCheckout:periodic-glance-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/> - hudson.remoting.Channel at 6ef1dd49:oneiric5\nUsing strategy: Default\nLast Built Revision: Revision dbd3d3d76a9599af83b5b71753b0206ac6d1e1df (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/glance.git\ngit --version\ngit version 1.8.2.1\nFetching upstream changes from git://github.com/openstack/glance.git\nCommencing build of Revision dbd3d3d76a9599af83b5b71753b0206ac6d1e1df (origin/stable/folsom)\nChecking out Revision dbd3d3d76a9599af83b5b71753b0206ac6d1e1df (origin/stable/folsom)\n[periodic-glance-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson4438812765959899453.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack glance\n+ version=26\n+ org=openstack\n+ project=glance\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.Tk76kIymDt\n+ TMPDIR=/tmp/tmp.Tk76kIymDt\n+ trap \'rm -rf /tmp/tmp.Tk76kIymDt\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack glance\n+ org=openstack\n+ project=glance\n+ [[ -z openstack ]]\n+ [[ -z glance ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' glance == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ python setup.py --version\njenkins-periodic-glance-python26-stable-folsom-208\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/log/py26-1.log>\nERROR: actionid=py26\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/208/\', \'BUILD_TAG\': \'jenkins-periodic-glance-python26-stable-folsom-208\', \'SSH_CLIENT\': \'198.101.231.203 48660 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-glance-python26-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'7009302d9214fa25943d46d1000005ef-1365182612.323880-1683346245\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'LD_LIBRARY_PATH\': \'/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64\', \'NODE_LABELS\': \'oneiric oneiric5\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'TMPDIR\': \'/tmp/tmp.Tk76kIymDt\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'208\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'a2a2b6b9-b3dc-422a-a6d3-1d79dfaa9fb4\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'dbd3d3d76a9599af83b5b71753b0206ac6d1e1df\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'NOSE_WITH_XUNIT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'oneiric5\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'NOSE_WITH_HTML_OUTPUT\': \'1\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 48660 166.78.48.43 22\', \'NOSE_HTML_OUT_FILE\': \'nose_results.html\'}\nDownloading/unpacking greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires> (line 4))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires> (line 4))\nNo distributions at all found for greenlet>=0.3.1 (from -r <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires> (line 4))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   py26: could not install deps [-r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/tools/test-requires]>\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\ndistribute==0.6.34\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.Tk76kIymDt\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1742086630.68.1373523465868.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-11 06:17:45',0,'2013-07-11 06:17:45',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #31','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/31/>\n\n------------------------------------------\n[...truncated 21285 lines...]\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova secgroup-list-rules vol_secgroup\n+ grep -q \' tcp .* 22 \'\n+ nova secgroup-add-rule vol_secgroup tcp 22 22 0.0.0.0/0\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| tcp         | 22        | 22      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova secgroup-list-rules vol_secgroup\n+-------------+-----------+---------+-----------+--------------+\n| IP Protocol | From Port | To Port | IP Range  | Source Group |\n+-------------+-----------+---------+-----------+--------------+\n| icmp        | -1        | -1      | 0.0.0.0/0 |              |\n| tcp         | 22        | 22      | 0.0.0.0/0 |              |\n+-------------+-----------+---------+-----------+--------------+\n+ nova flavor-list\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |\n| 2  | m1.small  | 2048      | 20   | 0         |      | 1     | 1.0         | True      |\n| 3  | m1.medium | 4096      | 40   | 0         |      | 2     | 1.0         | True      |\n| 4  | m1.large  | 8192      | 80   | 0         |      | 4     | 1.0         | True      |\n| 42 | m1.nano   | 64        | 0    | 0         |      | 1     | 1.0         | True      |\n| 5  | m1.xlarge | 16384     | 160  | 0         |      | 8     | 1.0         | True      |\n| 84 | m1.micro  | 128       | 0    | 0         |      | 1     | 1.0         | True      |\n+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+\n++ nova flavor-list\n++ get_field 1\n++ grep m1.tiny\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| 1  | m1.tiny   | 512       | 1    | 0         |      | 1     | 1.0         | True      |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ INSTANCE_TYPE=1\n+ [[ -z 1 ]]\n+ nova delete ex-vol-inst\nERROR: Unable to delete any of the specified servers.\nNo server with a name or ID of \'ex-vol-inst\' exists.\n+ true\n+ timeout 90 sh -c \'while nova show ex-vol-inst; do sleep 1; done\'\nERROR: No server with a name or ID of \'ex-vol-inst\' exists.\n++ nova boot --flavor 1 --image 52b6cd43-fb89-43a6-8b6c-b7abc19b2fb1 --security_groups=vol_secgroup ex-vol-inst\n++ grep \' id \'\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ echo \'| id                                   | 3af91d23-514c-4573-8776-9eadf6b35d1e |\'\n++ read data\n+ VM_UUID=3af91d23-514c-4573-8776-9eadf6b35d1e\n+ die_if_not_set 124 VM_UUID \'Failure launching ex-vol-inst\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ timeout 90 sh -c \'while ! nova show 3af91d23-514c-4573-8776-9eadf6b35d1e | grep status | grep -q ACTIVE; do sleep 1; done\'\n++ nova show 3af91d23-514c-4573-8776-9eadf6b35d1e\n++ grep private\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| private network                      | 10.1.0.3                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.3\n+ die_if_not_set 133 IP \'Failure retrieving IP address\'\n+ local exitcode=0\n++ set +o\n++ grep xtrace\n+ FXTRACE=\'set -o xtrace\'\n+ set +o xtrace\n+ ping_check private 10.1.0.3 90\n+ is_service_enabled neutron\n+ services=neutron\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net, =~ ,neutron, ]]\n+ [[ neutron == \\n\\o\\v\\a ]]\n+ [[ neutron == \\c\\i\\n\\d\\e\\r ]]\n+ [[ neutron == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ neutron == \\g\\l\\a\\n\\c\\e ]]\n+ [[ neutron == \\n\\e\\u\\t\\r\\o\\n ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,sysstat,tempest,s-proxy,s-account,s-container,s-object,cinder,c-api,c-vol,c-sch,n-cond,heat,h-api,h-api-cfn,h-api-cw,h-eng,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,n-net =~ q- ]]\n+ [[ neutron == \\s\\w\\i\\f\\t ]]\n+ [[ neutron == s-* ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.3 90\n+ local from_net=private\n+ local ip=10.1.0.3\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.3; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.3; do sleep 1; done\'\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.3 (10.1.0.3) 56(84) bytes of data.\n64 bytes from 10.1.0.3: icmp_req=1 ttl=64 time=6.56 ms\n\n--- 10.1.0.3 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 6.568/6.568/6.568/0.000 ms\n++ cinder list\n++ grep ex-vol-6654b19d\n++ get_field 2\n++ read data\n++ head -1\n+ [[ -n \'\' ]]\n++ date +%s\n+ start_time=1373523343\n+ cinder create --display_name ex-vol-6654b19d --display_description \'test volume: ex-vol-6654b19d\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                False                 |\n|      created_at     |      2013-07-11T06:15:44.023739      |\n| display_description |     test volume: ex-vol-6654b19d     |\n|     display_name    |           ex-vol-6654b19d            |\n|          id         | 3a774c92-c6bf-4749-9ed9-542bf429f3d4 |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ timeout 90 sh -c \'while ! cinder list | grep ex-vol-6654b19d | grep available; do sleep 1; done\'\n+ die 151 \'Volume ex-vol-6654b19d not created\'\n+ local exitcode=0\n+ set +o xtrace\n[ERROR] /opt/stack/new/devstack/exercises/volumes.sh:151 Volume ex-vol-6654b19d not created\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP neutron-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nFAILED euca\nFAILED volumes\n=====================================================================\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/mysql/mysql-slow.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/rabbitmq/rabbit at devstack-1373522493-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/rabbitmq/rabbit at devstack-1373522493.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/31/logs/sysstat.dat.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1742114553.2982720.1410187380379.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-tc',NULL,'2014-09-08 10:43:00',-14400,'2014-09-08 14:43:00',NULL,'[openstack-tc] Concern about potential divisive nature of\n	tc	election call for questions','\n> On June 3, 2014, I participated in the tc meeting and presented a report\n> of the current status of election participation[0]. One of the items for\n> discussion was increasing the percentage of active technical\n> contributors who participate in the tc election. Several suggestions\n> arose, some of which were acted upon, including posting blog entries to\n> the openstack.org namespace to inform the electorate of tc\n> activities[1]. Thanks to Anne, Russell and Thierry for composing and\n> posting their blog entries. Thierry also blogged his analysis of the\n> April election[2].\n> \n> I have a concern to which I would like to draw your attention and\n> hopefully get your feedback and guidance. At the same June 3 meeting an\n> agreement was reached, Action Item #4 in [0], \"election officials to\n> call for questions at the same time they call for  self-nominations, and\n> curate a list of questions candidates will answer\". I\'m going to have to\n> take liberties with the timing of that in order for Tristan and I to\n> have time to curate and post questions for the candidates to have time\n> to compose answers but the spirit is plain, to open a call for questions\n> for tc candidates.\n>\n> Here is my concern, this potentially has the outcome of being divisive.\n> Now at the time the idea was suggested and I did agree with the spirit\n> of it (to better inform the electorate of the purpose of the tc as well\n> as introduce them to candidates they may not know) I felt that the\n> elements that bring us together were strong enough to weather a bit of\n> divisiveness for the sake of trying a new direction to get our\n> participation percentage up. Now I hesitate. Lately I have been more\n> aware of those elements that separate us or try to draw us apart moreso\n> than those qualities I have felt for so long in that they bring us\n> together. My concern is that this well intended exercise may have\n> negative consequences and I wanted to share my perspective with you\n> prior to taking action.\n> \n> If I am to open a call for questions I would have to do it tomorrow,\n> Friday Sept. 5, in order to have the questions open for a week and then\n> give Tristan and myself a week to curate a list and have them posted\n> with 2 weeks prior to the tc nomination period. A draft timetable\n> (without specific timestamps, just days) follows:\n> Sept. 5 - 11 - call for questions\n> Sept. 12 - 18 - election officials curate submitted questions\n> Sept. 19 - 25 (Friday-Thursday) PTL Nominations Open - questions for TC\n> candidates posted Sept. 19\n> Sept. 26 - Oct. 2 (Friday - Thursday) PTL Election\n> Oct. 3 - 9 (Friday - Thursday) TC Nominations Open - TC candidate\n> questions due end of day Oct. 9\n> Oct. 10 - 16 (Friday - Thursday) TC Election - TC candidate question\n> responses posted Oct. 10\n> This doesn\'t leave a lot of time for discussion and direction and I am\n> sorry for that, I had hoped I would feel a clear direction on this\n> without having to bother everyone during feature freeze week and I just\n> don\'t.\n> \n> There is something else to consider.\n> \n> Joe has recently posted a thread[3] to solicit ideas (tc members are\n> identified, but candidates I think would be welcome too) to identify\n> areas where we agree. Personally I think this is a direction which has a\n> greater chance of being a collaborative discussion and display of\n> co-operation which I think the community needs, as opposed to something\n> that could feel divisive. The email identifies September 10 as the\n> cutoff for ideas, followed by discussion, which I really think is an\n> exercise that deserves focus. It is possible that the objective for\n> which the tc candidate questions were designed to achieve, greater\n> awareness of the role of the tc and participation in the tc election,\n> could be achieved by Joe\'s initiative.\n> \n> I welcome your thoughts.\n\nThanks for raising this Anita, my initial thought would be ...\n\n<note>\nNot intending to cast aspersions in any way at any existing or\nfuture officials (all of whom I\'m sure have the utmost integrity).\n</note>\n\nIMO the role of election official is best served if it\'s seen\nas being completely \"above the fray\" in terms of the campaign\nissues of the day.\n\nIn that sense, I\'d be wary of too direct an involvement by the\nofficials in the selection/curation of questions to put to the\ncandidates, lest this is seen to stray a bit too much into the\n\"cut & thrust\" of debate during the campaign.\n\nJust my $0.02 ...\n\nOTOH that recent ML thread from Joe doesn\'t explicitly seek to\nframe debate around the TC election either. Personally I\'m not\nreally sure an election debate needs such explicit framing with\na thread weeks in advance of voting, but if it does, then that\nshould be clearly signaled.\n\nCheers,\nEoghan\n\n> Thank you,\n> Anita.\n> \n> References:\n> [0] http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-06-03-20.03.html\n> [1] http://www.openstack.org/blog/category/governance/\n> [2]\n> http://fnords.wordpress.com/2014/06/06/analysis-of-april-2014-tc-election/\n> [3]\n> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044766.html\n> \n> _______________________________________________\n> OpenStack-TC mailing list\n> OpenStack-TC at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc\n> \n\n\n','<5408ACEE.2060809@anteaya.info>',NULL),('<174255105.2117079.1365650154160.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-04-10 23:15:54',-14400,'2013-04-11 03:15:54',NULL,'[Openstack-docs] OpenStack Image Guide','----- Original Message -----\n> From: \"Lorin Hochstein\" <lorin at nimbisservices.com>\n> To: openstack-docs at lists.openstack.org\n> Sent: Thursday, April 11, 2013 12:17:53 AM\n> Subject: [Openstack-docs] OpenStack Image Guide\n> \n> Hi all:\n> \n> I just posted a WIP draft of a new manual, an \"Image Guide\", about how to\n> do things like create new images from scratch or modify existing images.\n> It\'s something I\'ve always wanted but never existed.\n> \n> https://review.openstack.org/26624\n> \n> \n> This would obsolete a lot of the current in the OpenStack Compute Admin\n> guide on images, so that would eventually get zapped.\n> \n> Let me know what you think.\n\nThis looks great, one of the issues I was having when looking at the bug for RHEL image creation [1] was that the existing image creation/modification content in is quite spread out in the admin guide (and in some cases duplicated).\n\nSteve\n\n[1] https://bugs.launchpad.net/openstack-manuals/+bug/993010\n\n\n','<CADzpNMUkgNCLY-=5nTKhy_DX57wW=oK1dH61Vj4nJ17GHDe3VA@mail.gmail.com>',NULL),('<1742727.b1yy7mxTyM@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-13 17:28:25',36000,'2014-08-13 07:28:25',NULL,'[openstack-dev] [neutron] Which changes need accompanying bugs?','I\'m doing various small cleanup changes as I explore the neutron codebase.  \nSome of these cleanups are to fix actual bugs discovered in the code.  Almost \nall of them are tiny and \"obviously correct\".\n\nA recurring reviewer comment is that the change should have had an \naccompanying bug report and that they would rather that change was not \nsubmitted without one (or at least, they\'ve -1\'ed my change).\n\nI often didn\'t discover these issues by encountering an actual production \nissue so I\'m unsure what to include in the bug report other than basically a \ncopy of the change description.  I also haven\'t worked out the pattern yet of \nwhich changes should have a bug and which don\'t need one.\n\nThere\'s a section describing blueprints in NeutronDevelopment but nothing on \nbugs.  It would be great if someone who understands the nuances here could add \nsome words on when to file bugs:\nWhich type of changes should have accompanying bug reports?\nWhat is the purpose of that bug, and what should it contain?\n\n-- \nThanks,\n - Gus\n\n\n',NULL,NULL),('<174286041.184.1364537323994.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-29 06:08:43',0,'2013-03-29 06:08:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python26-stable-folsom #179','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/179/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/>\nCheckout:periodic-horizon-python26-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/> - hudson.remoting.Channel at 399b07ba:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.2\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python26-stable-folsom] $ /bin/bash -xe /tmp/hudson6205473099051418364.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 26 openstack horizon\n+ version=26\n+ org=openstack\n+ project=horizon\n+ [[ -z 26 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py26\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.TuagwG1hiw\n+ TMPDIR=/tmp/tmp.TuagwG1hiw\n+ trap \'rm -rf /tmp/tmp.TuagwG1hiw\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ tox -epy26\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/setup.py>\npy26 create: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26>\npy26 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/tools/test-requires>\npy26 inst: <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy26 runtests: commands[0]\nRunning Horizon application tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/template/defaulttags.py>:1235: DeprecationWarning: The syntax for the url template tag is changing. Load the `url` tag from the `future` tag library to start using the new behavior.\n  category=DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/contrib/auth/__init__.py>:26: DeprecationWarning: Authentication backends without a `supports_inactive_user` attribute are deprecated. Please define it in <class \'openstack_auth.backend.KeystoneBackend\'>.\n  DeprecationWarning)\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.53 secs:\n    0.61    UserSettingsTest.test_timezone_offset_is_displayed\n    0.58    ImagesViewTest.test_images_list_get_pagination\n    0.56    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.43    SwiftTests.test_upload\n    0.35    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 21.157s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/conf/__init__.py>:110: DeprecationWarning: The SECRET_KEY setting must not be empty.\n  warnings.warn(\"The SECRET_KEY setting must not be empty.\", DeprecationWarning)\n<https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/ws/.tox/py26/lib/python2.6/site-packages/django/utils/translation/__init__.py>:63: DeprecationWarning: Translations in the project directory aren\'t supported anymore. Use the LOCALE_PATHS setting instead.\n  DeprecationWarning)\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==1.1.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.12.0\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==0.8.2\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.TuagwG1hiw\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/179\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/179/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python26-stable-folsom/179/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<361680725.171.1364451057838.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1742995543.43377213.1409759849285.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-03 11:57:29',-14400,'2014-09-03 15:57:29',NULL,'[openstack-dev] [Nova] Feature Freeze Exception process for Juno','> I will follow up with a more detailed email about what I believe we are\n> missing, once the FF settles and I have applied some soothing creme to\n> my burnout wounds, but currently my sentiment is:\n> \n> Contributing features to Nova nowadays SUCKS!!1 (even as a core\n> reviewer) We _have_ to change that!\n\nI think this is *very* important.\n\n<rant>\nFor instance, I have/had two patch series\nup. One is of length 2 and is relatively small.  It\'s basically sitting there\nwith one \"+2\" on each patch.  I will now most likely have to apply for a FFE\nto get it merged, not because there\'s more changes to be made before it can get merged\n(there was one small nit posted yesterday) or because it\'s a huge patch that needs a lot\nof time to review, but because it just took a while to get reviewed by cores,\nand still only appears to have been looked at by one core.\n\nFor the other patch series (which is admittedly much bigger), it was hard just to\nget reviews (and it was something where I actually *really* wanted several opinions,\nbecause the patch series touched a couple of things in a very significant way).\n\nNow, this is not my first contribution to OpenStack, or to Nova, for that matter.  I\nknow things don\'t always get in.  It\'s frustrating, however, when it seems like the\nreason something didn\'t get in wasn\'t because it was fundamentally flawed, but instead\nbecause it didn\'t get reviews until it was too late to actually take that feedback into\naccount, or because it just didn\'t get much attention review-wise at all.  If I were a\nnew contributor to Nova who had successfully gotten a major blueprint approved and\nthe implemented, only to see it get rejected like this, I might get turned off of Nova,\nand go to work on one of the other OpenStack projects that seemed to move a bit faster.\n</rant>\n\nSo, it\'s silly to rant without actually providing any ideas on how to fix it.\nOne suggestion would be, for each approved blueprint, to have one or two cores\nexplicitly marked as being responsible for providing at least some feedback on\nthat patch.  This proposal has issues, since we have a lot of blueprints and only\ntwenty cores, who also have their own stuff to work on.  However, I think the\ngeneral idea of having \"guaranteed\" reviewers is not unsound by itself.  Perhaps\nwe should have a loose tier of reviewers between \"core\" and \"everybody else\".\nThese reviewers would be known good reviewers who would follow the implementation\nof particular blueprints if a core did not have the time.  Then, when those reviewers\ngave the \"+1\" to all the patches in a series, they could ping a core, who could feel\nmore comfortable giving a \"+2\" without doing a deep inspection of the code.\n\nThat\'s just one suggestion, though.  Whatever the solution may be, this is a\nproblem that we need to fix.  While I enjoyed going through the blueprint process\nthis cycle (not sarcastic -- I actually enjoyed the whole \"structured feedback\" thing),\nthe follow up to that was not the most pleasant.\n\nOne final note: the specs referenced above didn\'t get approved until Spec Freeze, which\nseemed to leave me with less time to implement things.  In fact, it seemed that a lot\nof specs didn\'t get approved until spec freeze.  Perhaps if we had more staggered\napproval of specs, we\'d have more staggered submission of patches, and thus less of a\nsudden influx of patches in the couple weeks before feature proposal freeze.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\n> From: \"Nikola ?ipanov\" <ndipanov at redhat.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, September 3, 2014 5:50:09 AM\n> Subject: Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno\n> \n> On 09/02/2014 09:23 PM, Michael Still wrote:\n> > On Tue, Sep 2, 2014 at 1:40 PM, Nikola ?ipanov <ndipanov at redhat.com> wrote:\n> >> On 09/02/2014 08:16 PM, Michael Still wrote:\n> >>> Hi.\n> >>>\n> >>> We\'re soon to hit feature freeze, as discussed in Thierry\'s recent\n> >>> email. I\'d like to outline the process for requesting a freeze\n> >>> exception:\n> >>>\n> >>>     * your code must already be up for review\n> >>>     * your blueprint must have an approved spec\n> >>>     * you need three (3) sponsoring cores for an exception to be granted\n> >>\n> >> Can core reviewers who have features up for review have this number\n> >> lowered to two (2) sponsoring cores, as they in reality then need four\n> >> (4) cores (since they themselves are one (1) core but cannot really\n> >> vote) making it an order of magnitude more difficult for them to hit\n> >> this checkbox?\n> > \n> > That\'s a lot of numbers in that there paragraph.\n> > \n> > Let me re-phrase your question... Can a core sponsor an exception they\n> > themselves propose? I don\'t have a problem with someone doing that,\n> > but you need to remember that does reduce the number of people who\n> > have agreed to review the code for that exception.\n> > \n> \n> Michael has correctly picked up on a hint of snark in my email, so let\n> me explain where I was going with that:\n> \n> The reason many features including my own may not make the FF is not\n> because there was not enough buy in from the core team (let\'s be\n> completely honest - I have 3+ other core members working for the same\n> company that are by nature of things easier to convince), but because of\n> any of the following:\n> \n> * Crippling technical debt in some of the key parts of the code\n> * that we have not been acknowledging as such for a long time\n> * which leads to proposed code being arbitrarily delayed once it makes\n> the glaring flaws in the underlying infra apparent\n> * and that specs process has been completely and utterly useless in\n> helping uncover (not that process itself is useless, it is very useful\n> for other things)\n> \n> I am almost positive we can turn this rather dire situation around\n> easily in a matter of months, but we need to start doing it! It will not\n> happen through pinning arbitrary numbers to arbitrary processes.\n> \n> I will follow up with a more detailed email about what I believe we are\n> missing, once the FF settles and I have applied some soothing creme to\n> my burnout wounds, but currently my sentiment is:\n> \n> Contributing features to Nova nowadays SUCKS!!1 (even as a core\n> reviewer) We _have_ to change that!\n> \n> N.\n> \n> > Michael\n> > \n> >>>     * exceptions must be granted before midnight, Friday this week\n> >>> (September 5) UTC\n> >>>     * the exception is valid until midnight Friday next week\n> >>> (September 12) UTC when all exceptions expire\n> >>>\n> >>> For reference, our rc1 drops on approximately 25 September, so the\n> >>> exception period needs to be short to maximise stabilization time.\n> >>>\n> >>> John Garbutt and I will both be granting exceptions, to maximise our\n> >>> timezone coverage. We will grant exceptions as they come in and gather\n> >>> the required number of cores, although I have also carved some time\n> >>> out in the nova IRC meeting this week for people to discuss specific\n> >>> exception requests.\n> >>>\n> >>> Michael\n> >>>\n> >>\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> > \n> > \n> > \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<5406E451.3060709@redhat.com>',NULL),('<1743674662.8155866.1396248197659.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-03-31 02:43:17',-14400,'2014-03-31 06:43:17',NULL,'[Openstack-docs] How to deal with DocImpact patches','Many thanks for that tip, Tom! And assume your patch will fix all. :)\n\nSummer\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Australia \nslong at redhat.com | irc: slong \n\n----- Original Message -----\n> From: \"Tom Fifield\" <tom at openstack.org>\n> To: openstack-docs at lists.openstack.org\n> Sent: Monday, March 31, 2014 4:37:11 PM\n> Subject: Re: [Openstack-docs] How to deal with DocImpact patches\n> \n> On 31/03/14 13:51, Summer Long wrote:\n> > Hello all,\n> > Here\'s something I\'ve hit more than once.\n> > I\'m seeing a blueprint with a change that says \'DocImpact\'. But I cannot\n> > find the related docs bug, although this should have been created\n> > automatically, right?\n> >\n> > We had a chat about this at the last design conference. There\'s no way to\n> > easily see or find the attached docs bug. And if there isn\'t a bug,\n> > there\'s no way to see \'yes, someone has looked at this. No, there\'s no\n> > impact\'. Which in this case, there\'s not (it\'s a small change, and it will\n> > be automatically included in the Config Ref).\n> >\n> > Should we say that a comment should be placed on the attached Blueprint\'s\n> > whiteboard? But what about patches without whiteboards?\n> >\n> > Am I just being blind (granted, am tired today)?\n> >\n> > thanks, Summer\n> \n> Best way I\'ve found is to use the change ID, eg\n> 2cbea242092dabf4c54544d5c8c32ba4b5fb8a1f\n> \n> Put that in google and you get the review and the bug.\n> \n> \n> Having said that, I have a theory as to why some are not being created -\n> false positive matches from the anti-duplicate code that we no longer\n> need. Hope that this patch will fix things...\n> \n> https://review.openstack.org/#/c/84067/\n> \n> \n> Regards,\n> \n> \n> Tom\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n\n\n','<53390D17.9090905@openstack.org>',NULL),('<1743852786.49.1360045052132.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-02-05 06:17:32',0,'2013-02-05 06:17:32',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #127','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/127/>\n\n------------------------------------------\n[...truncated 925 lines...]\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.02\n    test_get_calling_format_default                              OK    0.03\n    test_get_calling_format_path                                 OK    0.03\n    test_get_non_existing                                        OK    0.03\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.02\n    test_no_host                                                 OK    0.04\n    test_no_secret_key                                           OK    0.02\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.25\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.03\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.02\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.02\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.02\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nERROR: test that images don\'t get deleted immediatly and that the scrubber\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/test_scrubber.py\",> line 86, in test_delayed_delete\n    meta = client.add_image(TEST_IMAGE_META, TEST_IMAGE_DATA)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/client.py\",> line 165, in add_image\n    res = self.do_request(\"POST\", \"/images\", body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/common/client.py\",> line 589, in _do_request\n    raise exception.ClientConnectionError(e)\nClientConnectionError: [Errno 111] ECONNREFUSED\n-------------------- >> begin captured logging << --------------------\nglance.common.client: DEBUG: Constructed URL: http://localhost:34944/v1/images\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 104.26 secs:\n    33.33    TestGlanceControl.test_bouncing\n    20.26    TestBinGlanceCacheManage.test_queue\n    18.27    TestBinGlance.test_results_filtering\n    16.84    TestRootApi.test_version_configurations\n    15.56    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 919 tests in 731.089s\n\nFAILED (SKIP=103, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.6\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.31\ndocutils==0.10\neventlet==0.12.1\nglance==jenkins-periodic-glance-python26-stable-folsom-127\ngreenlet==0.4.0\nhttplib2==0.7.7\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==0.8.0\nkombu==2.5.4\nlxml==3.1beta1\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.2.0\nrepoze.lru==0.6\nrequests==1.1.0\nsimplejson==3.0.7\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.5L9nfEf1Nr\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/127\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/127/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1744038.yb7ZeK88Vk@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-11 23:28:37',7200,'2014-09-11 21:28:37',NULL,'[Openstack] History of fixed IPs in neutron','Hello,\n\nDo You know is there any way to save all history of each fixed IP assigned to \nport (and instance). For example: I have external network with some subnet. \nUser is creating instance A connected to this instance so I have in history \nthat IP x.x.x.x was assinged to instance A, then he delete instance so in \nhistory there is info that IP is not assigned to instance. And so on. \nI\'m using openstack havana version and neutron with ML2 and I don\'t see such \npossibility but maybe I\'m wrong :)\n\n---\nBest regards\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\n\n',NULL,NULL),('<174416377.1.1376719968960.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-17 06:12:48',0,'2013-08-17 06:12:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #9','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/9/>\n\n------------------------------------------\n[...truncated 950 lines...]\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.04\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.02\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: We test that the \'--respawn\' option causes the API server\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_bin_glance_control.py\",> line 161, in test_respawn\n    self.assertTrue(launch_msg is None, launch_msg)\nAssertionError: Unexpected server launch status\n    \'Unexpected server launch status\' = self._formatMessage(\'Unexpected server launch status\', \"%s is not true\" % safe_repr(False))\n>>  raise self.failureException(\'Unexpected server launch status\')\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 66.87 secs:\n    14.33    TestGlanceControl.test_bouncing\n    14.22    TestScrubber.test_delayed_delete\n    13.86    TestGlanceControl.test_reload\n    12.61    TestApi.test_unsupported_default_store\n    11.84    TestBinGlanceCacheManage.test_queue\n----------------------------------------------------------------------\nRan 926 tests in 515.376s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python27-stable-folsom-9\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.13\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.1Q4mTHK2RA\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/9\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/9/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise12/9\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1744433465.3121579.1377866135637.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-30 08:35:35',-14400,'2013-08-30 12:35:35',NULL,'[openstack-dev] Horizon - Mockup tool','+1 for balsamiq\n\n----- Original Message -----\nFrom: \"Sergey Lukjanov\" <slukjanov at mirantis.com>\nTo: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\nSent: Friday, August 30, 2013 12:54:28 AM\nSubject: Re: [openstack-dev] Horizon - Mockup tool\n\n\n\nI\'m using balsamiq to make mockups. \n\nSincerely yours, \nSergey Lukjanov \nSavanna Technical Lead \nMirantis Inc. \n(sent from my phone) \n30.08.2013 0:37 ???????????? \"Endre Karlson\" < endre.karlson at gmail.com > ???????: \n\n\n\nDoes anyone know what too is used to do mockups ? \n\nEndre \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CA+GZd788vkv02Zt6OQXCPOs2rj8z9b2XOsmO-s5qpLe2Fcvn3A@mail.gmail.com>',NULL),('<1745003139.88.1384236684876.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-12 06:11:24',0,'2013-11-12 06:11:24',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #44','See <https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/44/>\n\n------------------------------------------\n[...truncated 1275 lines...]\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/registry/client.py\",> line 89, in do_request\n    action, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 63, in wrapped\n    return func(self, *args, **kwargs)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 444, in do_request\n    headers=headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 80, in wrapped\n    return func(self, method, url, body, headers)\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/common/client.py\",> line 574, in _do_request\n    raise exception.Invalid(res.read())\nInvalid: 400 Bad Request\n\nThe server could not comply with the request since it is either malformed or otherwise incorrect.\n\n Unrecognized changes-since value  \nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5d9e6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5d9e6d0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': []}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5035b50>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5035b50>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-ead65a78-c78c-4040-bd49-fdd5d4e18860\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n    \'200 != 400\' = \'%s != %s\' % (safe_repr(200), safe_repr(400))\n    \'200 != 400\' = self._formatMessage(\'200 != 400\', \'200 != 400\')\n>>  raise self.failureException(\'200 != 400\')\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:10:56Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'56\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'56\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-13T06:10:56Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'56\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'13\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'56\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:10:56+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'56\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'56\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-14T06:10:56-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'56\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'14\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'14\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'56\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2013-11-15T06:10:56Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'56\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'15\', \'minute\': u\'10\'} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'15\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'56\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x66b9d90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x2873d50>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 68.11 secs:\n    14.21    TestGlanceControl.test_bouncing\n    14.13    TestScrubber.test_delayed_delete\n    13.74    TestGlanceControl.test_reload\n    13.52    TestGlanceControl.test_respawn\n    12.51    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 526.833s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.3\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python27-stable-folsom-44\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.4\nlxml==3.2.4\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.ulcD1gfGF4\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/44/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise5/44\n[SCP] Copying console log.\n\n\n','<1907693176.84.1384063658197.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1745116899.4178614.1404305615087.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/community',NULL,'2014-07-02 08:53:35',-14400,'2014-07-02 12:53:35',NULL,'[openstack-community] User deendayal3786 spamming ask.o.o','----- Original Message -----\n> From: \"Steve Gordon\" <sgordon at redhat.com>\n> To: community at lists.openstack.org\n> Sent: Wednesday, July 2, 2014 8:38:38 AM\n> Subject: User deendayal3786 spamming ask.o.o\n> \n> Hi all,\n> \n> It looks like user deendayal3786 [1] is spamming ask.o.o this morning, I\n> closed a few but new ones are popping up. Does anyone have the ability to\n> block/ban? Also wondering if there should be some tighter spam control to\n> prevent this number of questions being posted in X minutes of each other.\n> \n> Thanks,\n> \n> Steve\n> \n> [1] https://ask.openstack.org/en/users/6619/deendayal3786/\n\nThis one as well:\n\nhttps://ask.openstack.org/en/users/6614/dasram477/\n\n\n','<600657857.4148506.1404304718716.JavaMail.zimbra@redhat.com>',NULL),('<1745469633.6998127.1415793461943.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-12 06:57:41',-18000,'2014-11-12 11:57:41',NULL,'[openstack-dev] [NFV] NFV sub group meeting week of November\n 10th','Hi Itai,\n\nI just sent an email about this - no meeting this week (would have been Thursday), we will pick up next Wednesday. I am in the process of selecting a new meeting time for the Thursday alternate and will also be sending out an email about the CI needs shortly :).\n\nThanks,\n\nSteve\n\n----- Original Message -----\n> From: \"ITAI MENDELSOHN (ITAI)\" <itai.mendelsohn at alcatel-lucent.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Wednesday, November 12, 2014 6:46:14 AM\n> Subject: [openstack-dev] [NFV] NFV sub group meeting week of November 10th\n> \n> Team,\n> \n> Do we meet Wednesday or Thursday this week?\n> \n> Best,\n> Itai\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n-- \nSteve Gordon, RHCE\nSr. Technical Product Manager,\nRed Hat Enterprise Linux OpenStack Platform\n\n\n','<D0891524.4AD0C%itai.mendelsohn@alcatel-lucent.com>',NULL),('<1745760553.322.1359008234106.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-01-24 06:17:14',0,'2013-01-24 06:17:14',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #115','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/115/>\n\n\n\n','<1430154953.301.1358921728620.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1746265834.108.1353197861583.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-18 00:17:41',0,'2012-11-18 00:17:41',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #48','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/48/>\n\n\n\n','<436092415.83.1353110930388.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1746859.uVvHpnbNoJ@smithers>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-08 00:00:00',3600,'2014-02-07 23:00:00',NULL,'[openstack-dev] Asynchrounous programming: replace eventlet\n	with asyncio','Le jeudi 6 f?vrier 2014, 22:32:26 Zane Bitter a ?crit :\n> [BTW am I right in thinking that in trollius you _have_ to drive your\n> co-routines from a top-level Task? That\'s not the case in Heat (although\n> we do anyway), or IIUC in asyncio - I was expecting e.g. the exception\n> handling for Return to happen in the coroutine decorator rather than in\n> Task. Just curious.]\n\nSorry, but I don\'t understand what you mean by \"to drive your co-routines from \na top-level Task\". Here is a simple example chaining two coroutines:\nhttp://docs.python.org/dev/library/asyncio-task.html#example-chain-coroutines\n\n> The main reason asyncio exists (as opposed to, say, twisted) is that\n> it\'s supposed to be the standard place to get an event loop from, so\n> that everybody ends up using the same event loop. Right now, though,\n> there are still lots of competing event loops (including eventlet) and\n> it\'s difficult to see how introducing another one helps in the short\n> term.\n\nasyncio can use eventlet (greenlet in fact) event loop though greenio.\n\nasyncio is more than an event loop, it\'s a nice API to use it. For example, I \nprefer coroutines (yield from) to callbacks!\n\nVictor\n\n\n','<52F453CA.9030007@redhat.com>',NULL),('<1746879.38.1381127317908.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-07 06:28:37',0,'2013-10-07 06:28:37',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #32','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-coverage/32/>\n\n------------------------------------------\n[...truncated 21480 lines...]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_quota_show ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id[gate] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id[gate] ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_rate_limits ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_region_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\nInitialized empty Git repository in /tmp/tempest-unit_71STp/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox ... ok\nInitialized empty Git repository in /tmp/tempest-unitBWMbhK/.git/\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_fails ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial ... ok\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails\ntempest.tests.test_wrappers.TestWrappers.test_pretty_tox_serial_fails ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_snapshot_create_get_list_update_delete[gate] ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network]\ntempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basicops[compute,network] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_fake_action ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_help ... ok\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list\ntempest.cli.simple_read_only.test_glance.SimpleReadOnlyGlanceClientTest.test_glance_image_list ... ok\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image]\ntempest.scenario.test_large_ops.TestLargeOpsScenario.test_large_ops_scenario[compute,image] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          187.676\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  175.572\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  72.590\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_specify_keypair[gate]                               37.794\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]        33.180\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestXML.test_rescued_vm_detach_volume[gate,negative]          30.254\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]        30.069\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     28.564\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                     28.397\ntempest.api.compute.images.test_images.ImagesTestJSON.test_create_image_from_stopped_server[gate,negative]               27.954\n\n----------------------------------------------------------------------\nRan 1191 tests in 1212.231s\n\nOK (skipped=42)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-557068-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az1-557068.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az1-557068/32/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1515139550.35.1381040916832.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1746935139.23.1383113579695.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-30 06:12:59',0,'2013-10-30 06:12:59',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #40','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/40/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5594ed0>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x59060d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x59060d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-1f8c21fb-63f9-4c7b-9af1-cef033db00bb\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x39259b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x39259b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x39259b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x39259b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-29T06:12:19Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'19\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'29\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'29\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2013-10-31T06:12:19Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'19\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'31\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'31\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:12:19+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'19\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:12:19-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'19\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2013-11-02T06:12:19Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'19\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'02\', \'minute\': u\'12\'} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'02\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'12\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'19\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6b7fa10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x25e4b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.44 secs:\n    26.38    TestScrubber.test_scrubber_app\n    20.75    TestScrubber.test_delayed_delete\n    14.91    TestRootApi.test_version_configurations\n    14.87    TestGlanceControl.test_reload\n    14.53    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 648.737s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.40\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.22\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.EOhne4X4vY\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/40/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-6/40\n[SCP] Copying console log.\n\n\n','<277177467.9.1382681553942.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<174783563.538008.1384338021252.JavaMail.root@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-13 11:20:21',3600,'2013-11-13 10:20:21',NULL,'[openstack-dev] [Horizon] Introduction of AngularJS in\n membership workflow','Hi all,\n\nI was wondering how can we continue to maintain a no js version of Horizon with the integration of Angular, it seems to be a lot of work on top of it.\nIn addition, do we know the performance of Angularjs, where are the limits, it could be good to check some documentation and made some POC. I have tried the asynchronous API and I encountered some issues with the two way data bind. \nDoes people have some feedbacks?\n\nMaxime Vidori\n\n----- Original Message -----\nFrom: \"Jiri Tomasek\" <jtomasek at redhat.com>\nTo: openstack-dev at lists.openstack.org\nSent: Wednesday, November 13, 2013 11:00:43 AM\nSubject: Re: [openstack-dev] [Horizon] Introduction of AngularJS in membership workflow\n\nHi, \n\nI\'d like to point out, that our main intent should be to use mostly AngularJS\'s Directives feature. \nAs Jordan mentions, It is a self-contained reusable item that is initialized on the html element \n(see line 6 in [2]), you can pass it variables that Django template has available. Then Angular takes \nover and replaces the html element with template that belongs to directive. The business logic \nis taken care by controller that is also assigned to the directive. The directive can get data either \nfrom the variables passed to the html element or better, through the service injected to controller. \nThis service brings data asynchronously from our API. \n\nIn our patch we are getting data using the current membership code, that brings data from \nhidden form. Maintaining the synchronization between the directive and the form involves quite \na lot of code. Once we\'d have the API on the Django side that would serve the data for membership \ncomponent in json, the membership directive code would get reduced by a good amount. \n\nReading back on yesterday\'s Horizon meeting, there was some confusion about \"compile phase\" \nThe compile phase in angular does not have much to do with jasvascript compilation/minification. \nIt is a phase in AngularJS when compiler parses the template and instantiates directives and expressions. \n( http://www.benlesh.com/2013/08/angular-compile-how-it-works-how-to-use.html ) \n\nJirka \n\nOn 11/11/2013 08:21 PM, Jordan OMara wrote: \n\n\nHello Horizon! \n\nOn November 11th, we submitted a patch to introduce AngularJS into \nHorizon [1]. We believe AngularJS adds a lot of value to Horizon. \n\nFirst, AngularJS allows us to write HTML templates for interactive \nelements instead of doing jQuery-based DOM manipulation. This allows \nthe JavaScript layer to focus on business logic, provides easy to \nwrite JavaScript testing that focuses on the concern (e.g. business \nlogic, template, DOM manipulation), and eases the on-boarding for new \ndevelopers working with the JavaScript libraries. \nSecond, AngularJS is not an all or nothing solution and integrates \nwith the existing Django templates. For each feature that requires \nJavaScript, we can write a self-contained directive to handle the DOM, \na template to define our view and a controller to contain the business \nlogic. Then, we can add this directive to the existing template. To \nsee an example in action look at _workflow_step_update_member.html \n[2]. It can also be done incrementally - this isn\'t an all-or-nothing \napproach with a massive front-end time investment, as the Angular \ncomponents can be introduced over time. \n\nFinally, the initial work to bring AngularJS to Horizon provides a \nspringboard to remove the \"DOM Database\" (i.e. hidden-divs) used on \nthe membership page (and others). Instead of abusing the DOM, we can \ninstead expose an API for membership data, add an AngularJS resource \n(i.e. reusable representation of API entities) for the API. The data \ncan then be loaded data asynchronously and allow the HTML to focus on \nexpressing a semantic representation of the data to the user. \nPlease give our patch a try! You can find the interactions on \nDomains/Groups, Flavors/Access(this form does not seem to work in \ncurrent master or on my patch) and Projects/Users&Groups. You should \nnotice that it behaves...exactly the same! \nWe look forward to your feedback. Jordan O\'Mara & Jirka Tomasek \n\n[1] [ https://review.openstack.org/#/c/55901/ ] [2] [ https://github.com/jsomara/horizon/blob/angular2/horizon/templates/horizon/common/_workflow_step_update_members.html ] \n\n\n_______________________________________________\nOpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<52834DCB.1060908@redhat.com>',NULL),('<1747953760.6493821.1417689184026.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-04 05:33:04',-18000,'2014-12-04 10:33:04',NULL,'[openstack-dev] [TripleO] Alternate meeting time','----- Original Message -----\n> From: \"James Polley\" <jp at jamezpolley.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Thursday, 4 December, 2014 9:40:36 AM\n> Subject: Re: [openstack-dev] [TripleO] Alternate meeting time\n> \n> Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we\'ve had\n> 10 people respond so far. The winning time so far is Monday 2100UTC - 7\n> \"yes\" and one \"If I have to\".\n> \n> ... but the 2 people who can\'t make that time work in UTC or CET. Finding a\n> time that includes those people rules out people who work in Eastern\n> Australia and New Zealand. Purely in terms of getting the biggest numbers\n> in, Monday 2100UTC seems like the most workable time so far.\n\nYeah, one of those people is me. I realise I\'m not that flexible, so it\'s \nfine if I can\'t make it. However, I\'m still generally +1 to having \nalternating meeting times.\n\nDougal\n\n\n','<CAPtRfUGyOp817p2xxNXMLSgn8Wq=ke3zi5bKOKFxVLVs6ZkwuA@mail.gmail.com>',NULL),('<1749201017.24786.1421403990012.JavaMail.zimbra@li.nux.ro>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2015-01-16 10:26:30',0,'2015-01-16 10:26:30',NULL,'[openstack-dev] [Ironic] Hands-on documentation','Hi,\n\nI\'ve been asked to implement Ironic instead of other PXE deployment engines (Cobbler, Foreman).\nI have a few questions, though:\na - is it production ready?\nb - is it capable of replacing solutions such as the ones mentioned above?\nc - is there some more hands-on documentation that would help me install and configure it?\n\nCheers,\nLucian\n\n--\nSent from the Delta quadrant using Borg technology!\n\nNux!\nwww.nux.ro\n\n\n',NULL,NULL),('<1749440907.25689824.1417558402631.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 17:13:22',-18000,'2014-12-02 22:13:22',NULL,'[openstack-dev] [Telco][NFV] Framing use case contributions','Hi all,\n\nBased on last week\'s conversation [1] I have tried to update the use cases page to remove the emphasis on requirements/solutions and focus on the \"what\" and \"why\" and to provide some guidance as to initial scope to help those wishing to submit use cases in framing them.\n\nPlease review and see if I have missed anything:\n\n    https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Contributing_Use_Cases\n\nThanks,\n\nSteve\n\n[1] http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-11-26-22.00.log.html\n\n\n','<118363379.25687877.1417558219823.JavaMail.zimbra@redhat.com>',NULL),('<1749440907.25689824.1417558402631.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-12-02 17:13:22',-18000,'2014-12-02 22:13:22',NULL,'[Openstack-operators] [Telco][NFV] Framing use case contributions','Hi all,\n\nBased on last week\'s conversation [1] I have tried to update the use cases page to remove the emphasis on requirements/solutions and focus on the \"what\" and \"why\" and to provide some guidance as to initial scope to help those wishing to submit use cases in framing them.\n\nPlease review and see if I have missed anything:\n\n    https://wiki.openstack.org/wiki/TelcoWorkingGroup/UseCases#Contributing_Use_Cases\n\nThanks,\n\nSteve\n\n[1] http://eavesdrop.openstack.org/meetings/telcowg/2014/telcowg.2014-11-26-22.00.log.html\n\n\n','<118363379.25687877.1417558219823.JavaMail.zimbra@redhat.com>',NULL),('<174962906.270.1365056253026.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-04 06:17:33',0,'2013-04-04 06:17:33',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #185','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/185/>\n\n\n\n','<939065499.256.1364969813664.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<174A5A2A-585F-4BE2-8BC2-AEBCE3101331@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-20 09:24:30',-28800,'2012-12-20 17:24:30',NULL,'[openstack-dev] A question about selecting host','It is managed by the scheduler. Admins can force a specific host by passing in availabilty zone like so:\n\nnova boot --availability_zone nova:HOST\n\nwhere HOST is the name of the host that you want it to boot on. Note that this will skip the scheduler altogether so it is possible to overallocate a host this way.\n\nor an example post in json:\n\n{\n    \"server\" : {\n        \"name\" : \"new-server-test\",\n        \"imageRef\" : \"70a599e0-31e7-49b7-b260-868f441e862b\",\n        \"flavorRef\" : \"1\",\n        \"availability_zone\": \"nova:HOST\",\n    }\n}\n\nVish\n\nOn Dec 19, 2012, at 8:03 PM, tianwei zhang <artdream07 at gmail.com> wrote:\n\n> Dear All:\n> \n> I am a new user to Openstack. I have a question about nova compute:\n> \n> When we want to run an instance, can we select a host to be assigned, or just a random one?  If we can select a specific one, how is this option passed into the create_instance function?\n> \n> Could someone help me with this question?\n> \n> Thanks a lot\n> \n> Sincerely\n> \n> Tianwei Zhang\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAOyF181RuGyksQP2GA6VMLMGiDGJboh3THo4-6J9DR7gQs7z2A@mail.gmail.com>',NULL),('<174B02D7-91D6-4C55-BC57-D22E3D26F1BE@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-25 11:38:46',25200,'2014-02-25 04:38:46',NULL,'[openstack-dev] [Mistral] Plugin architecture for custom\n	actions?','Yes, it?s one of the important things that we would like to implement. It?s not the highest priority right now but we definitely need to do that. Dmitri Zimine and I talked about it and at some point Dmitri wanted to start working on it. However, we can decide to rearrange our plans within the team and assign this task to someone else.\n\nWe already have a BP (https://blueprints.launchpad.net/mistral/+spec/mistral-pluggable-task-actions) but it doesn?t describe how this plugin architecture should be implemented.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 25 Feb 2014, at 08:43, W Chan <m4d.coder at gmail.com> wrote:\n\n> Will Mistral be supporting custom actions developed by users?  If so, should the Actions module be refactored to individual plugins with a dynamic process for action type mapping/lookup?\n> \n> Thanks.\n> Winson\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/b3ab4170/attachment.html>\n\n','<CABNy8O77XguXU0sWk5Yyng1fRWGqwJmpRmTRYrYNMDrBK_JMGQ@mail.gmail.com>',NULL),('<1750917097.26223831.1402491759084.JavaMail.zimbra@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2014-06-11 13:02:39',0,'2014-06-11 13:02:39',NULL,'[Openstack-stable-maint] Instance shelving is broken in Havana\n : needs backport review','Hi,\nThanks to the nice help of Matthew Treinish and Gary Kotton, I have some +2 on the patches I\'d love to see merged in nova stable/havana. I need one final +2, on https://review.openstack.org/#/c/72521/ (fix missing host when unshelving).\n\nAny help would be very much appreciated.\nJordan\n\n----- Original Message -----\nFrom: \"Jordan Pittier\" <jordan.pittier at cloudwatt.com>\nTo: \"Vishvananda Ishaya\" <vishvananda at gmail.com>\nCc: openstack-stable-maint at lists.openstack.org\nSent: Friday, June 6, 2014 3:16:11 PM\nSubject: Re: [Openstack-stable-maint] Instance shelving is broken in Havana : needs backport review\n\nHi,\nThanks Vish for the +2 ! So, I am continuing on landing a Tempest patch that effectively test shelve/unshelve. Now the unshelve works great but when the instance is unshelved a property of the instance is not set set back. I get this stacktrace http://logs.openstack.org/65/96165/1/check/check-grenade-dsvm-partial-ncpu-icehouse/2ac603c/logs/new/screen-n-api.txt.gz#_2014-06-04_12_57_04_476 I have been able to track this, and the fix was already proposed in Nova/havana. \n\nSo if some of you could review and eventually approve the backport here : https://review.openstack.org/#/c/72521/ and https://review.openstack.org/#/c/77734/ I think I will then be able to merge my new test in tempest !\n\nThanks a lot, and sorry to bother you if this list is not the right place.\n\nJordan\n\n----- Original Message -----\nFrom: \"Vishvananda Ishaya\" <vishvananda at gmail.com>\nTo: \"Jordan Pittier\" <jordan.pittier at cloudwatt.com>\nCc: openstack-stable-maint at lists.openstack.org\nSent: Monday, June 2, 2014 5:18:59 PM\nSubject: Re: [Openstack-stable-maint] Instance shelving is broken in Havana : needs backport review\n\nThis is a really nasty bug. +2/+a from me.\n\nVish\n\nOn Jun 2, 2014, at 7:29 AM, Jordan Pittier <jordan.pittier at cloudwatt.com> wrote:\n\n> Hi,\n> Instance shelving is broken in stable/havana, the instance that will be unshelved is not the one that has been shelved. A bug was filled here https://bugs.launchpad.net/nova/+bug/1257594 and a patch was merged in Icehouse. I\'d like to write a Tempest test to prevent this bug from happening again but in order to do this, I need the patch to be backported in stable/havana. A backport was proposed here : https://review.openstack.org/81214  It needs one more +2. Maybe you could help :)\n> \n> Thanks a lot !\n> Jordan\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n_______________________________________________\nOpenstack-stable-maint mailing list\nOpenstack-stable-maint at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n\n\n','<1092173503.19901663.1402060571885.JavaMail.zimbra@cloudwatt.com>',NULL),('<1751320818.46.1383372486043.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:08:06',0,'2013-11-02 06:08:06',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-keystone-python26-stable-folsom #43','See <https://jenkins02.openstack.org/job/periodic-keystone-python26-stable-folsom/43/>\n\n\n\n',NULL,NULL),('<1752749950.5406557.1381726583227.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2013-10-14 00:56:23',-14400,'2013-10-14 04:56:23',NULL,'[Openstack-docs] Meeting times','\nHi there,\nAm wondering whether we could possibly change the meeting time? \n11pm is just brutal and would be lovely to change it just a couple of hours back? Or even 1 hour back?\n\nThis would set:\nUTC -      11am\nCST -      6am\nEST -      7am\nGermany -  1pm\nBrisbane - 9pm\n\nthanks, Summer\n\n\n\n-- \nSummer Long \nOpenStack Documentation Lead \nEngineering Content Services \n\nRed Hat Asia Pacific \nBrisbane, Austral ia \nslong at redhat.com | irc: slong \n\n\n','<1217561708.5405289.1381725787569.JavaMail.root@redhat.com>',NULL),('<1752805066.1.1376201306015.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-11 06:08:25',0,'2013-08-11 06:08:25',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-python27-stable-grizzly #2','See <https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/2/changes>\n\nChanges:\n\n[thierry] Use utils.safe_minidom_parse_string in extensions\n\n[apevec] Bump stable/grizzly next version to 2013.1.4\n\n------------------------------------------\n[...truncated 1558 lines...]\n    test_delete_volume                                           OK    0.02\n    test_ensure_export                                           OK    0.02\n    test_initialize_connection                                   OK    0.02\n    test_remove_export                                           OK    0.02\nExceptionTest\n    test_exception_with_none_code_throws_500                     OK    0.01\n    test_non_cinder_exception_mapping                            OK    0.01\n    test_non_cinder_notfound_exception_mapping                   OK    0.01\n    test_quota_error_mapping                                     OK    0.02\n    test_safe_exceptions_are_described_in_faults                 OK    0.01\n    test_unsafe_exceptions_are_not_described_in_faults           OK    0.01\nTestLoaderNormalFilesystem\n    test_app_found                                               OK    0.01\n    test_app_not_found                                           OK    0.00\n    test_config_found                                            OK    0.00\nTestLoaderNothingExists\n    test_config_not_found                                        OK    0.01\nTestWSGIServer\n    test_app                                                     OK    0.00\n    test_app_using_ipv6_and_ssl                                  OK    0.03\n    test_app_using_ssl                                           OK    0.03\n    test_no_app                                                  OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nDriverTestCase\n    test_config_options                                          OK    0.00\n    test_copy_image_to_volume_non_xenserver_case                 OK    0.00\n    test_copy_image_to_volume_xenserver_case                     OK    0.00\n    test_copy_volume_to_image_non_xenserver_case                 OK    0.00\n    test_copy_volume_to_image_xenserver_case                     OK    0.00\n    test_create_export_does_not_raise_exception                  OK    0.00\n    test_create_snapshot                                         OK    0.00\n    test_create_volume                                           OK    0.00\n    test_create_volume_from_snapshot                             OK    0.00\n    test_delete_snapshot                                         OK    0.00\n    test_delete_volume                                           OK    0.00\n    test_do_setup                                                OK    0.00\n    test_get_volume_stats_reports_required_keys                  OK    0.00\n    test_get_volume_stats_reports_unknown_cap                    OK    0.00\n    test_initialize_connection                                   OK    0.00\n    test_initialize_connection_null_values                       OK    0.00\n    test_remove_export_does_not_raise_exception                  OK    0.00\n    test_reported_driver_type                                    OK    0.00\n    test_use_glance_plugin_to_copy_image_to_volume_fail          OK    0.00\n    test_use_glance_plugin_to_copy_image_to_volume_success       OK    0.00\n    test_use_glance_plugin_to_upload_volume                      OK    0.00\n    test_use_image_utils_to_pipe_bytes_to_volume                 OK    0.00\n    test_use_image_utils_to_upload_volume                        OK    0.00\nToolsTest\n    test_get_this_vm_uuid                                        OK    0.00\n    test_stripped_first_line_of                                  OK    0.00\nXIVVolumeDriverTest\n    test_create_volume                                           OK    0.01\n    test_create_volume_should_fail_if_no_pool_space_left         OK    0.01\n    test_delete_volume                                           OK    0.01\n    test_delete_volume_should_fail_for_not_existing_volume       OK    0.01\n    test_initialize_connection                                   OK    0.01\n    test_initialize_connection_should_fail_for_non_existing_volumeOK    0.01\n    test_initialized_should_set_xiv_info                         OK    0.01\n    test_setup_should_fail_if_connection_is_invalid              OK    0.01\n    test_setup_should_fail_if_credentials_are_invalid            OK    0.01\n    test_terminate_connection                                    OK    0.01\n    test_terminate_connection_should_fail_on_non_attached_volume OK    0.01\n    test_terminate_connection_should_fail_on_non_existing_volume OK    0.01\n    test_volume_exists                                           OK    0.01\nZadaraVPSADriverTestCase\n    test_bad_http_response                                       OK    0.01\n    test_create_destroy                                          OK    0.01\n    test_create_destroy_multiple                                 OK    0.02\n    test_delete_without_detach                                   OK    0.04\n    test_destroy_non_existent                                    OK    0.01\n    test_empty_apis                                              OK    0.01\n    test_no_active_ctrl                                          OK    0.01\n    test_ssl_use                                                 OK    0.01\n    test_volume_attach_detach                                    OK    0.02\n    test_volume_attach_multiple_detach                           OK    0.03\n    test_wrong_attach_params                                     OK    0.01\n    test_wrong_detach_params                                     OK    0.02\n    test_wrong_login_reply                                       OK    0.01\n\n======================================================================\nERROR: Test glance version set by arg to GlanceClientWrapper\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/tests/image/test_glance.py\",> line 576, in test_glance_version_by_arg\n    9292, version=2)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 103, in __init__\n    use_ssl, version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 117, in _create_static_client\n    self.use_ssl, self.version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 73, in _create_glance_client\n    return glanceclient.Client(str(version), endpoint, **params)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/client.py\",> line 22, in Client\n    return client_class(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/client.py\",> line 43, in __init__\n    self._get_member_model())\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/client.py\",> line 50, in _get_member_model\n    schema = self.schemas.get(\'member\')\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/schemas.py\",> line 53, in get\n    _, raw_schema = self.http_client.json_request(\'GET\', uri)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/common/http.py\",> line 250, in json_request\n    resp, body_iter = self._http_request(url, method, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/common/http.py\",> line 216, in _http_request\n    raise exc.InvalidEndpoint(message=message)\nInvalidEndpoint: Error finding address for fake_host: [Errno -2] Name or service not known\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X GET -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' http://fake_host:9292/v2/schemas/member\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Test glance version set by flag is honoured\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/tests/image/test_glance.py\",> line 564, in test_glance_version_by_flag\n    9292)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 103, in __init__\n    use_ssl, version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 117, in _create_static_client\n    self.use_ssl, self.version)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/cinder/image/glance.py\",> line 73, in _create_glance_client\n    return glanceclient.Client(str(version), endpoint, **params)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/client.py\",> line 22, in Client\n    return client_class(*args, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/client.py\",> line 43, in __init__\n    self._get_member_model())\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/client.py\",> line 50, in _get_member_model\n    schema = self.schemas.get(\'member\')\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/v2/schemas.py\",> line 53, in get\n    _, raw_schema = self.http_client.json_request(\'GET\', uri)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/common/http.py\",> line 250, in json_request\n    resp, body_iter = self._http_request(url, method, **kwargs)\n  File \"<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/glanceclient/common/http.py\",> line 216, in _http_request\n    raise exc.InvalidEndpoint(message=message)\nInvalidEndpoint: Error finding address for fake_host: [Errno -2] Name or service not known\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X GET -H \'Content-Type: application/json\' -H \'User-Agent: python-glanceclient\' http://fake_host:9292/v2/schemas/member\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 9.69 secs:\n    2.27    TestMigrations.test_postgresql_opportunistically\n    2.01    SolidFireVolumeTestCase.test_create_volume\n    2.01    SolidFireVolumeTestCase.test_create_with_qos_type\n    2.01    SolidFireVolumeTestCase.test_create_volume_with_qos\n    1.38    ScalityDriverTestCase.test_create_snapshot\n----------------------------------------------------------------------\nRan 1323 tests in 62.654s\n\nFAILED (SKIP=52, errors=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-cinder-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\ncinder==jenkins.periodic.cinder.python27.stable.grizzly.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nhp3parclient==1.0.0\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.12\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npython-glanceclient==0.10.0\npython-keystoneclient==0.3.1\npython-swiftclient==1.5.0\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.10\nsuds==0.4\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=178\n+ \'[\' 178 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.UceGaqgoji\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-cinder-python27-stable-grizzly/2/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-python27-stable-grizzly/precise2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-cinder-python27-stable-grizzly/precise2/2\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1752860495.568004.1412694437273.JavaMail.yahoo@jws10071.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-07 15:07:17',0,'2014-10-07 15:07:17',NULL,'[Openstack] Trouble adding volume to instance','Hi all,\nBeen troubleshooting this for a while now and cant seem to figure out what wrong, reaching out here hoping that maybe someone would have some input/advice on how to fix. I am trying to add a volume to an instance and it keeps failing with the following errors below. Would appreciate any insight as I am wits end and I apologize in advance if this is not a place to ask questions such as these - Ive tried the AskOpenstack and have gotten nothing. Thanks!!\n[root at block1 tgt]# cinder list+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+| ? ? ? ? ? ? ? ? ?ID ? ? ? ? ? ? ? ? ?| ? Status ?| Display Name | Size | Volume Type | Bootable | Attached to |+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+| 4c6e1b15-2c7e-4bca-aae4-925cc054db8d | available | ? myVolume ? | ?1 ? | ? ? None ? ?| ?false ? | ? ? ? ? ? ? || b8df2a1a-48df-443c-a078-bec907d8462d | available | ? amitvol ? ?| ?20 ?| ? ? None ? ?| ?false ? | ? ? ? ? ? ? |+--------------------------------------+-----------+--------------+------+-------------+----------+-------------+\n\n\nBlock node error log:\n2014-10-07 10:58:46.720 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231 ? ?bb7ce560d1e9482b862679cefaf5ae69 - - -] Failed to create iscsi target for volume id:volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n2014-10-07 10:58:46.721 31375 ERROR cinder.brick.iscsi.iscsi [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231 ? ?bb7ce560d1e9482b862679cefaf5ae69 - - -] Unexpected error while running command.Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool create /dev/cinder-volumes/volume-b8df2a1a-48df-443c-a078-bec907 ? d8462d iqn.2010-10.org.openstack:volume-b8df2a1a-48df-443c-a078-bec907d8462d 8HayuR8mAq7QpK9y7soB iZypk62NhziXmfvdZMDfExit code: 1Stdout: \'Error creating NetworkPortal: ensure port 3260 is not in use by another service.\\n\'Stderr: \'Traceback (most recent call last):\\n ?File \"/bin/cinder-rtstool\", line 238, in <module>\\n ? ?sys.exit(main())\\n ?File \"/bin/ci ? nder-rtstool\", line 203, in main\\n ? ?create(backing_device, name, userid, password, initiator_iqns)\\n ?File \"/bin/cinder-rtstool\", lin ? e 95, in create\\n ? ?rtslib.NetworkPortal(tpg_new, \\\'0.0.0.0\\\', 3260, mode=\\\'any\\\')\\n ?File \"/usr/lib/python2.7/site-packages/rtslib/ta ? rget.py\", line 694, in __init__\\n ? ?self._create_in_cfs_ine(mode)\\n ?File \"/usr/lib/python2.7/site-packages/rtslib/node.py\", line 60, ? ?in _create_in_cfs_ine\\n ? ?% self.__class__.__name__)\\nrtslib.utils.RTSLibError: Could not create NetworkPortal in configFS.\\n\'\n2014-10-07 10:58:46.721 31375 ERROR oslo.messaging.rpc.dispatcher [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a71921374 ? 22231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Exception during message handling: Failed to create iscsi target for volume volume-b8df2a ? 1a-48df-443c-a078-bec907d8462d.\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher ? File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\" ? , line 540, in create_iscsi_target\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher ? ? raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher ISCSITargetCreateFailed: Failed to create iscsi target for volume vol ? ume-b8df2a1a-48df-443c-a078-bec907d8462d.\n2014-10-07 10:58:46.721 31375 TRACE oslo.messaging.rpc.dispatcher\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137 ? 422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Returning exception Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a ? 078-bec907d8462d. to caller\n2014-10-07 10:58:46.724 31375 ERROR oslo.messaging._drivers.common [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137 ? 422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] [\'Traceback (most recent call last):\\n\', \' ?File \"/usr/lib/python2.7/site-packages/oslo/ ? messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n ? ?incoming.message))\\n\', \' ?File \"/usr/lib/python2.7/site-packages/os ? lo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n ? ?return self._do_dispatch(endpoint, method, ctxt, args)\\n\', \' ?File \"/usr/l ? ib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n ? ?result = getattr(endpoint, method)(ctxt, * ? *new_args)\\n\', \' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n ? ?volume)\\n\', ? ?\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n ? ?return self._create_export(co ? ntext, volume)\\n\', \' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n ? ?data = sel ? f.target_helper.create_export(context, volume, volume_path)\\n\', \' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line ? ?53, in create_export\\n ? ?chap_auth)\\n\', \' ?File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_i ? scsi_target\\n ? ?raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', \'ISCSITargetCreateFailed: Failed to create iscsi target ? ?for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\']\n\nController node error log:\n2014-10-07 10:58:46.745 12232 ERROR cinder.api.middleware.fault [req-d5e26671-6ca3-45d8-a9ca-730913c87010 8748be7fb9d544c088a7192137422231 bb7ce560d1e9482b862679cefaf5ae69 - - -] Caught error: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.[u\'Traceback (most recent call last):\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n ? ?incoming.message))\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n ? ?return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n ? ?result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n ? ?volume)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n ? ?return self._create_export(context, volume)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n ? ?data = self.target_helper.create_export(context, volume, volume_path)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n ? ?chap_auth)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n ? ?raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].\n\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault RemoteError: Remote error: ISCSITargetCreateFailed Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\n2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault [u\'Traceback (most recent call last):\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 133, in _dispatch_and_reply\\n ? ?incoming.message))\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 176, in _dispatch\\n ? ?return self._do_dispatch(endpoint, method, ctxt, args)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/oslo/messaging/rpc/dispatcher.py\", line 122, in _do_dispatch\\n ? ?result = getattr(endpoint, method)(ctxt, **new_args)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/manager.py\", line 783, in initialize_connection\\n ? ?volume)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 524, in create_export\\n ? ?return self._create_export(context, volume)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py\", line 533, in _create_export\\n ? ?data = self.target_helper.create_export(context, volume, volume_path)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/volume/iscsi.py\", line 53, in create_export\\n ? ?chap_auth)\\n\', u\' ?File \"/usr/lib/python2.7/site-packages/cinder/brick/iscsi/iscsi.py\", line 540, in create_iscsi_target\\n ? ?raise exception.ISCSITargetCreateFailed(volume_id=vol_id)\\n\', u\'ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-b8df2a1a-48df-443c-a078-bec907d8462d.\\n\'].2014-10-07 10:58:46.745 12232 TRACE cinder.api.middleware.fault\n\n\n\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141007/dd1dc1e8/attachment.html>\n\n',NULL,NULL),('<1753720878.74.1383544944054.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:02:24',0,'2013-11-04 06:02:24',NULL,'[Openstack-stable-maint] Jenkins build is back to stable :\n periodic-horizon-docs-stable-folsom #37','See <https://jenkins02.openstack.org/job/periodic-horizon-docs-stable-folsom/37/>\n\n\n\n','<1077227719.39.1383372181473.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<175411976.13.1370671975833.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-08 06:12:55',0,'2013-06-08 06:12:55',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #250','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/250/>\n\n\n\n','<1222380711.8.1370585569576.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1754624058.194.1358407897982.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-17 07:31:37',0,'2013-01-17 07:31:37',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #9','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/9/>\n\n------------------------------------------\n[...truncated 15755 lines...]\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:27:03 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-8b39467b-359e-428a-a2c4-b733be81383b\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\nSKIP: No OpenStack Network API endpoint\n-------------------- >> begin captured logging << --------------------\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/e14c78d7-3a3f-43a8-9d0a-73474a05b63b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:55 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-80fad2bb-b824-4d38-936a-857649b02cb6\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/4ed2a867-2c62-4c66-82b4-7a5164c6de3b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:56 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-635d9001-0df6-49cd-97f2-a85756ae4e2b\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/2e50f46d-971f-47be-b8a3-2a9ce5060425\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:57 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d4bfb329-2a82-4b37-94dc-55900b8c31c1\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/bc36d42c-82b1-458b-9a2f-af4719d2e2d1\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:58 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-b03b976a-4352-41db-9446-1b894e2b115c\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/63cb74af-b361-46f5-b1b9-5483766aa477\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:58 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-3dbe6005-7987-43bd-ac84-47fb3f5c8026\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/c62ef3d5-691e-4b78-9793-77fd0ed11df9\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:26:59 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c686f14d-27ce-4a04-be1a-9cbcba0c9693\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/475ef435-eb5b-4112-b814-1bceaedc10a1\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:27:00 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-01b66a49-4118-4de5-a0da-6daabcda0c1a\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/fd99cc09-4661-45ba-875c-8ce54360ee6b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:27:01 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-c54b68a1-c110-4878-bc77-2433932cfd66\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/e40459a5-4e88-4279-816a-eb2c78c0c1e9\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:27:02 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-d6fccc45-be9c-405e-bbd7-53262ffd81a4\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0xN1QwNzoyNjo0MC4wMzIzMDYiLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTE4VDA3OjI2OjM5WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogImVjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvZWM2OTdmOTNmMTRmNDE1OGFhYTMyMGU2NzgxODM0ZTkiLCAiaWQiOiAiNDI1MDk2NzhiNjhlNDFhYTg2Y2EzMTc3YzY3ZWRhOWEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIzMWEwZTgzZmI1MGE0NWY5OTcwYTdhM2I5NjM3MDQzNiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMDFkMWVmOTRlYmFhNDVmNzgxNWIwYjNmNWI2ODcwNmEiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSIsICJpZCI6ICIzZWYxMTJjMTE0ODQ0ZjM5OTVhN2UzNDYzMjMyMTJiOSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxL2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICIzYWJhZjBhN2Q1N2M0ZTZhYTU1OTJiZjE3MjI2OTc2MCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIX2VjNjk3ZjkzZjE0ZjQxNThhYWEzMjBlNjc4MTgzNGU5IiwgImlkIjogIjAyMzc1NmM5NDFmYTQ0YmFiOGE4YjE3YWFiYjQ0OGJhIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF9lYzY5N2Y5M2YxNGY0MTU4YWFhMzIwZTY3ODE4MzRlOSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjRjMjc5MjdhYjM0MzQxNzY5MTliZmQ3MGM1NjljZDYwIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiNWZhMzk3YTVmN2FhNGFiNDgyYmM1NWQ1ODE2ZGZlMGYiLCAicm9sZXMiOiBbeyJuYW1lIjogImFub3RoZXJyb2xlIn0sIHsibmFtZSI6ICJNZW1iZXIifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiMGNkZjY2ZjhkZWMxNDVkODlhODlmM2EwOWIzYTUyNzMiLCAiZmE4ZmUxZjE2MjdiNGRhM2FmZTdmMTk0OTE1ZjY1OTIiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYC6CGRg+I0ADBQJVUY21dVnGZVKKStPIkv--9mAW+7wTOcdraXzycYmlFrTHyvpVxDDgHNlu2JEYS+mLNNSrhZASUSADMDya4dOj0nk7bVUeUXmRw3vj81RxQFUx0rQ6hoZI5ztlrMAeJa-xS4OlME+mgPKtqctdyNDS-gswppygA==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/6f0e8da8-1481-4736-b3be-f1285b8bce2b\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Thu, 17 Jan 2013 07:27:03 GMT\ncontent-length: 0\ncontent-type: text/html; charset=UTF-8\nx-openstack-request-id: req-8b39467b-359e-428a-a2c4-b733be81383b\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 None\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 659 tests in 3552.655s\n\nOK (SKIP=78)\nGenerating coverage report\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/runpy.py\", line 162, in _run_module_as_main\n    \"__main__\", fname, loader, pkg_name)\n  File \"/usr/lib/python2.7/runpy.py\", line 72, in _run_code\n    exec code in run_globals\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 194, in <module>\n    main(sys.argv)\n  File \"/opt/stack/new/tempest/tools/tempest_coverage.py\", line 179, in main\n    shutil.copytree(path, CLI.output)\n  File \"/usr/lib/python2.7/shutil.py\", line 175, in copytree\n    os.makedirs(dst)\n  File \"/usr/lib/python2.7/os.py\", line 157, in makedirs\n    mkdir(name, mode)\nOSError: [Errno 13] Permission denied: \'<https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/ws/logs/coverage-report\'>\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/rabbitmq/rabbit at devstack-1358387485-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/rabbitmq/rabbit at devstack-1358387485.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/9/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<150434243.175.1358319843378.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1754672069.2088020.1414583161140.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-29 07:46:01',-14400,'2014-10-29 11:46:01',NULL,'[openstack-dev] [NFV] Patches tagging with NFVImpact','----- Original Message -----\n> From: \"Sean Dague\" <sean at dague.net>\n> To: openstack-dev at lists.openstack.org\n> \n> On 10/29/2014 07:25 AM, Steve Gordon wrote:\n> > ----- Original Message -----\n> >> From: \"Maru Newby\" <marun at redhat.com>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >> <openstack-dev at lists.openstack.org>\n> >>\n> >> Am I the only one wondering whether introducing arbitrary tagging into our\n> >> commit messages sets a bad precedent?  Or was there a discussion on this\n> >> topic that I missed?\n> >>\n> >> Maru\n> > \n> > Any particular reason for digging this up from June? We already changed the\n> > process so that we did not need to do this.\n> > \n> > Thanks,\n> > \n> > Steve\n> \n> Steve, et all, sorry for piling on. I didn\'t read dates earlier than\n> Maru\'s post.\n> \n> Glad there is a different solution here.\n> \n>         -Sean\n\nWe pretty quickly came to basically the same conclusion as you and Maru are suggesting [1], that doing this was too invasive and created unnecessary noise.\n\nThanks,\n\nSteve\n\n[1] http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-06-18-14.03.log.html\n\n\n','<5450CFBE.9050102@dague.net>',NULL),('<1754905073.61.1355876869663.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-12-19 00:27:49',0,'2012-12-19 00:27:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python26-stable-folsom #79','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/79/>\n\n\n\n',NULL,NULL),('<1754949207.10462686.1389258994356.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-09 04:16:34',-18000,'2014-01-09 09:16:34',NULL,'[openstack-dev] [Neutron] Allow multiple subnets on gateway\n port for router','Hi Randy, \n\nI don\'t have a specific use case. I just wanted to understand the scope here as the name of this blueprint (\"allow multiple subnets on gateway port for router\") could be a bit misleading. \n\nTwo questions I have though: \n\n1. Is this talking specifically about the gateway port to the provider\'s next-hop router or relevant for all ports in virtual routers as well? \n2. There is a fundamental difference between v4 and v6 address assignment. With IPv4 I agree that one IP address per port is usually enough (there is the concept of secondary IP, but I am not sure it\'s really common). With IPv6 however you can sure have more then one (global) IPv6 on an interface. Shouldn\'t we support this? \n\n\nThanks, \nNir \n\n----- Original Message -----\n\nFrom: \"Randy Tuttle\" <randy.m.tuttle at gmail.com> \nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org> \nCc: rantuttl at cisco.com \nSent: Tuesday, December 31, 2013 6:43:50 PM \nSubject: Re: [openstack-dev] [Neutron] Allow multiple subnets on gateway port for router \n\nHi Nir \n\nGood question. There\'s absolutely no reason not to allow more than 2 subnets, or even 2 of the same IP versions on the gateway port. In fact, in our POC we allowed this (or, more specifically, we did not disallow it). However, for the gateway port to the provider\'s next-hop router, we did not have a specific use case beyond an IPv4 and an IPv6. Moreover, in Neutron today, only a single subnet is allowed per interface (either v4 or v6). So all we are doing is opening up the gateway port to support what it does today (i.e., v4 or v6) plus allow IPv4 and IPv6 subnets to co-exist on the gateway port (and same network/vlan). Our principle use case is to enable IPv6 in an existing IPv4 environment. \n\nDo you have a specific use case requiring 2 or more of the same IP-versioned subnets on a gateway port? \n\nThanks \nRandy \n\n\nOn Tue, Dec 31, 2013 at 4:59 AM, Nir Yechiel < nyechiel at redhat.com > wrote: \n\n\n\nHi, \n\nWith regards to https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port, can you please clarify this statement: \"We will disallow more that two subnets, and exclude allowing 2 IPv4 or 2 IPv6 subnets\". \nThe use case for dual-stack with one IPv4 and one IPv6 address associated to the same port is clear, but what is the reason to disallow more than two IPv4/IPv6 subnets to a port? \n\nThanks and happy holidays! \nNir \n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n\n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140109/34cca0c1/attachment.html>\n\n','<CAHFXTQM3uRivaJuUL2TBfK-Ct-F5X+bk=xVhriWDJ7fr4u-L+A@mail.gmail.com>',NULL),('<1755210.ABczjNEKEs@laptop>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-11-07 20:01:09',3600,'2013-11-07 19:01:09',NULL,'[Openstack] Cleaning after tests','Hello,\n\nI\'m trying to use tempest tests to testing openstack installation. I\'m using \nbranch stable/grizzly and I can\'t now upgrade it to havana. My problem is that \nif some test has got error e.g. test instance is not created propery than in \nopenstack database remains a lot of unecessary instances, tenants, user and \nother data.\nI try to fix some tests to catch errors in few places and clean after such \nerrors but there are place that I have no idea how to clean. E.g. in test:\n\ntest_server_security_groups(self)\nfrom tempest/tests/compute/security_groups/test_security_groups.py\n\nif in code:\n	# Create server and add the security group created\n        # above to the server we just created\n        server_name = rand_name(\'server\')\n        resp, server = self.servers_client.create_server(server_name,\n                                                         self.image_ref,\n                                                         self.flavor_ref)\n        server_id = server[\'id\']\n        self.servers_client.wait_for_server_status(server_id, \'ACTIVE\')\n\nis not created properly than this instance is in database with state \"ERROR\" \nand it is not deleted. Also tenant and user which was earlier created in test \nclass are not deleted.\nSo maybe someone of You have got such problem and know how to clean database \nafter tempest tests?\n\n-----------------------\nRegards,\nS?awek Kap?o?ski\nslawek at kaplonski.pl\n\n\n',NULL,NULL),('<175539809.8.1377240218912.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-23 06:43:38',0,'2013-08-23 06:43:38',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #10','See <https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/10/>\n\n------------------------------------------\n[...truncated 20274 lines...]\ntempest.tests.object_storage.test_container_services.ContainerTest.test_delete_container[smoke] ... ok\ntempest.tests.object_storage.test_container_services.ContainerTest.test_list_container_contents_json[smoke] ... ok\ntempest.tests.object_storage.test_container_sync.ContainerSyncTest.test_container_synchronization ... SKIP: Until Bug 1093743 is resolved.\ntempest.tests.object_storage.test_object_expiry.ObjectExpiryTest.test_get_object_after_expiry_time ... SKIP: Until bug 1069849 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_container_object_without_using_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_access_public_object_with_another_user_creds[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_2d_way[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_across_containers[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_in_same_container[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_copy_object_to_itself[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_create_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_delete_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url ... SKIP: Until bug 1097137 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_metadata[smoke] ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_object_upload_in_segments ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_read_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_with_non_authorized_user ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_object_without_using_creds ... ok\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_object_without_using_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_services.ObjectTest.test_write_public_with_another_user_creds[smoke] ... SKIP: Until Bug #1020722 is resolved.\ntempest.tests.object_storage.test_object_version.ContainerTest.test_versioned_container[smoke] ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_create_get_delete_volume_with_volume_type_and_extra_specs ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_delete ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_create_get ... ok\ntempest.tests.volume.admin.test_volume_types.VolumeTypesTest.test_volume_type_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_spec_create_get_delete ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_list ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest.test_volume_type_extra_specs_update ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTest.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_invalid_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_none_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_create_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_delete_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_get_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_list_nonexistent_volume_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_multiple_extra_spec ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_no_body ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_none_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML.test_update_nonexistent_extra_spec_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumeTypesNegativeTest.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_empty_name ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_create_with_nonexistent_volume_type ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_delete_nonexistent_type_id ... ok\ntempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML.test_get_nonexistent_type_id ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_attach_detach_volume_to_instance[smoke] ... ok\ntempest.tests.volume.test_volumes_actions.VolumesActionsTest.test_get_volume_attachment ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTest.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_delete[smoke] ... ok\ntempest.tests.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list[smoke] ... ok\ntempest.tests.volume.test_volumes_list.VolumesListTest.test_volume_list_with_details[smoke] ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_invalid_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_out_passing_size ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_create_volume_with_size_zero ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_delete_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_invalid_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_get_volume_without_passing_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_delete_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML.test_volume_get_nonexistant_volume_id ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot ... ok\ntempest.tests.volume.test_volumes_snapshots.VolumesSnapshotTestXML.test_volume_from_snapshot ... ok\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 824 tests in 1499.864s\n\nOK (SKIP=73)\nfull runtests: commands[1] | nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\nWARNING:test command found but not installed in testenv\n  cmd: /usr/local/bin/nosetests\n  env: /opt/stack/new/tempest/.tox/full\nMaybe forgot to specify a dependency?\nnose.config: INFO: Ignoring files matching [\'^\\\\.\', \'^_\', \'^setup\\\\.py$\']\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... SKIP: Test needs parameters, Bug: 1157349\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ncli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ncli.simple_read_only.test_compute_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... SKIP: version is empty, bug 1138844\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... FAIL\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ncli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 45, in test_admin_catalog_list\n    self.assertTrue(svc[\'__label\'].startswith(\'Service:\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-23 06:35:57,627 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   catalog \'\n2013-08-23 06:35:58,192 Invalid line between tables: Service: compute\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"/opt/stack/new/tempest/cli/simple_read_only/test_keystone.py\", line 93, in test_admin_help\n    self.assertTrue(lines[0].startswith(\'usage: keystone\'))\n  File \"/usr/lib/python2.7/unittest/case.py\", line 420, in assertTrue\n    raise self.failureException(msg)\nAssertionError: False is not true\n\n-------------------- >> begin captured logging << --------------------\n2013-08-23 06:36:00,589 running: \'/usr/local/bin/keystone --os-username admin --os-tenant-name admin --os-password secret --os-auth-url http://127.0.0.1:5000/v2.0/   help \'\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests-cli.xml\n----------------------------------------------------------------------\nRan 54 tests in 33.131s\n\nFAILED (SKIP=4, failures=2)\nERROR: InvocationError: \'/usr/local/bin/nosetests --logging-format %(asctime)-15s %(message)s --with-xunit --xunit-file=nosetests-cli.xml -sv cli\'\n___________________________________ summary ____________________________________\nERROR:   full: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-158690-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-158690.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az3-158690/10/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<783571787.3.1377169726123.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1756123312.118.1358057920744.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-13 06:18:40',0,'2013-01-13 06:18:40',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-coverage-vm-full #5','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-coverage-vm-full/5/>\n\n------------------------------------------\n[...truncated 14672 lines...]\n++ echo \'| id                     | 465ce73f-8e59-4aed-95cd-1e24c2f9457f |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ VM_UUID=465ce73f-8e59-4aed-95cd-1e24c2f9457f\n+ die_if_not_set VM_UUID \'Failure launching ex-vol\'\n+ local exitcode=0\n+ set +o xtrace\n+ timeout 60 sh -c \'while ! nova show 465ce73f-8e59-4aed-95cd-1e24c2f9457f | grep status | grep -q ACTIVE; do sleep 1; done\'\n++ nova show 465ce73f-8e59-4aed-95cd-1e24c2f9457f\n++ grep private\n++ get_field 2\n++ read data\n++ \'[\' 2 -lt 0 \']\'\n++ field=\'$3\'\n++ echo \'| private network        | 10.1.0.4                                                       |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $3}\'\n++ read data\n+ IP=10.1.0.4\n+ die_if_not_set IP \'Failure retrieving IP address\'\n+ local exitcode=0\n+ set +o xtrace\n+ ping_check private 10.1.0.4 90\n+ is_service_enabled quantum\n+ services=quantum\n+ for service in \'${services}\'\n+ [[ ,g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net, =~ ,quantum, ]]\n+ [[ quantum == \\n\\o\\v\\a ]]\n+ [[ quantum == \\c\\i\\n\\d\\e\\r ]]\n+ [[ quantum == \\c\\e\\i\\l\\o\\m\\e\\t\\e\\r ]]\n+ [[ quantum == \\g\\l\\a\\n\\c\\e ]]\n+ [[ quantum == \\q\\u\\a\\n\\t\\u\\m ]]\n+ [[ g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,horizon,mysql,rabbit,tempest,swift,cinder,c-api,c-vol,c-sch,n-cond,n-net =~ q- ]]\n+ return 1\n+ _ping_check_novanet private 10.1.0.4 90\n+ local from_net=private\n+ local ip=10.1.0.4\n+ local boot_timeout=90\n+ local expected=True\n+ local check_command=\n++ trueorfalse False\n++ local default=False\n++ local testval=\n++ [[ -z \'\' ]]\n++ echo False\n++ return\n+ MULTI_HOST=False\n+ [[ False = \\T\\r\\u\\e ]]\n+ [[ True = \\T\\r\\u\\e ]]\n+ check_command=\'while ! ping -c1 -w1 10.1.0.4; do sleep 1; done\'\n+ timeout 90 sh -c \'while ! ping -c1 -w1 10.1.0.4; do sleep 1; done\'\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n2 packets transmitted, 0 received, 100% packet loss, time 999ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n>From 10.1.0.1 icmp_seq=1 Destination Host Unreachable\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 0 received, 100% packet loss, time 0ms\n\nPING 10.1.0.4 (10.1.0.4) 56(84) bytes of data.\n64 bytes from 10.1.0.4: icmp_req=1 ttl=64 time=3.15 ms\n\n--- 10.1.0.4 ping statistics ---\n1 packets transmitted, 1 received, 0% packet loss, time 0ms\nrtt min/avg/max/mdev = 3.150/3.150/3.150/0.000 ms\n++ openssl rand -hex 4\n+ VOL_NAME=myvol-25c962db\n++ cinder list\n++ grep myvol-25c962db\n++ head -1\n++ get_field 2\n++ read data\n+ [[ -n \'\' ]]\n+ cinder create --display_name myvol-25c962db --display_description \'test volume: myvol-25c962db\' 1\n+---------------------+--------------------------------------+\n|       Property      |                Value                 |\n+---------------------+--------------------------------------+\n|     attachments     |                  []                  |\n|  availability_zone  |                 nova                 |\n|       bootable      |                false                 |\n|      created_at     |      2013-01-13T06:17:33.032310      |\n| display_description |     test volume: myvol-25c962db      |\n|     display_name    |            myvol-25c962db            |\n|          id         | a0b61371-d637-4b21-96cd-10cb0605415a |\n|       metadata      |                  {}                  |\n|         size        |                  1                   |\n|     snapshot_id     |                 None                 |\n|     source_volid    |                 None                 |\n|        status       |               creating               |\n|     volume_type     |                 None                 |\n+---------------------+--------------------------------------+\n+ [[ 0 != 0 ]]\n++ date +%s\n+ start_time=1358057853\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-25c962db | grep available; do sleep 1; done\'\n| a0b61371-d637-4b21-96cd-10cb0605415a | available | myvol-25c962db |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1358057855\n+ echo \'Completed cinder create in 2 seconds\'\nCompleted cinder create in 2 seconds\n++ cinder list\n++ grep myvol-25c962db\n++ head -1\n++ get_field 1\n++ read data\n++ \'[\' 1 -lt 0 \']\'\n++ field=\'$2\'\n++ echo \'| a0b61371-d637-4b21-96cd-10cb0605415a | available | myvol-25c962db |  1   |     None    |  false   |             |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print $2}\'\n++ read data\n+ VOL_ID=a0b61371-d637-4b21-96cd-10cb0605415a\n+ die_if_not_set VOL_ID \'Failure retrieving volume ID for myvol-25c962db\'\n+ local exitcode=0\n+ set +o xtrace\n+ DEVICE=/dev/vdb\n++ date +%s\n+ start_time=1358057856\n+ nova volume-attach 465ce73f-8e59-4aed-95cd-1e24c2f9457f a0b61371-d637-4b21-96cd-10cb0605415a /dev/vdb\n+----------+--------------------------------------+\n| Property | Value                                |\n+----------+--------------------------------------+\n| device   | /dev/vdb                             |\n| id       | a0b61371-d637-4b21-96cd-10cb0605415a |\n| serverId | 465ce73f-8e59-4aed-95cd-1e24c2f9457f |\n| volumeId | a0b61371-d637-4b21-96cd-10cb0605415a |\n+----------+--------------------------------------+\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-25c962db | grep in-use; do sleep 1; done\'\n| a0b61371-d637-4b21-96cd-10cb0605415a | in-use | myvol-25c962db |  1   |     None    |  false   | 465ce73f-8e59-4aed-95cd-1e24c2f9457f |\n++ date +%s\n+ end_time=1358057863\n+ echo \'Completed volume-attach in 7 seconds\'\nCompleted volume-attach in 7 seconds\n++ cinder list\n++ grep myvol-25c962db\n++ head -1\n++ get_field -1\n++ read data\n++ \'[\' -1 -lt 0 \']\'\n++ field=\'($(NF-1))\'\n++ echo \'| a0b61371-d637-4b21-96cd-10cb0605415a | in-use | myvol-25c962db |  1   |     None    |  false   | 465ce73f-8e59-4aed-95cd-1e24c2f9457f |\'\n++ awk \'-F[ \\t]*\\\\|[ \\t]*\' \'{print ($(NF-1))}\'\n++ read data\n+ VOL_ATTACH=465ce73f-8e59-4aed-95cd-1e24c2f9457f\n+ die_if_not_set VOL_ATTACH \'Failure retrieving myvol-25c962db status\'\n+ local exitcode=0\n+ set +o xtrace\n+ [[ 465ce73f-8e59-4aed-95cd-1e24c2f9457f != 465ce73f-8e59-4aed-95cd-1e24c2f9457f ]]\n++ date +%s\n+ start_time=1358057864\n+ nova volume-detach 465ce73f-8e59-4aed-95cd-1e24c2f9457f a0b61371-d637-4b21-96cd-10cb0605415a\n+ timeout 60 sh -c \'while ! cinder list | grep myvol-25c962db | grep available; do sleep 1; done\'\n| a0b61371-d637-4b21-96cd-10cb0605415a | available | myvol-25c962db |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1358057870\n+ echo \'Completed volume-detach in 6 seconds\'\nCompleted volume-detach in 6 seconds\n++ date +%s\n+ start_time=1358057870\n+ cinder delete a0b61371-d637-4b21-96cd-10cb0605415a\n+ timeout 60 sh -c \'while cinder list | grep myvol-25c962db; do sleep 1; done\'\n| a0b61371-d637-4b21-96cd-10cb0605415a | deleting | myvol-25c962db |  1   |     None    |  false   |             |\n++ date +%s\n+ end_time=1358057874\n+ echo \'Completed cinder delete in 4 seconds\'\nCompleted cinder delete in 4 seconds\n+ nova delete 465ce73f-8e59-4aed-95cd-1e24c2f9457f\n+ timeout 60 sh -c \'while nova list | grep -q 465ce73f-8e59-4aed-95cd-1e24c2f9457f; do sleep 1; done\'\n+ nova secgroup-delete vol_secgroup\n+ set +o xtrace\n*********************************************************************\nSUCCESS: End DevStack Exercise: ./exercises/volumes.sh\n*********************************************************************\n=====================================================================\nSKIP boot_from_volume\nSKIP client-env\nSKIP quantum-adv-test\nPASS aggregates\nPASS bundle\nPASS client-args\nPASS euca\nPASS floating_ips\nPASS horizon\nPASS sec_groups\nPASS swift\nPASS volumes\n=====================================================================\nStarting coverage data collection\nTraceback (most recent call last):\n  File \"tools/tempest_coverage.py\", line 23, in <module>\n    from tempest.common.rest_client import RestClient\nImportError: No module named tempest.common.rest_client\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/rabbitmq/rabbit at devstack-1357981882-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/rabbitmq/rabbit at devstack-1357981882.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-coverage-vm-full/5/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1813400741.99.1357971506488.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1756265956.33079847.1403647007667.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-06-24 17:56:47',-14400,'2014-06-24 21:56:47',NULL,'[Openstack-operators] Browser Usage for noVNC','Hello Operators,\n\nI\'m part of the noVNC upstream development team.  noVNC, for those of you who don\'t know, is the HTML5 VNC client\nintegrated into Horizon (the OpenStack dashboard).  We are considering removing support for some older browsers, and\nwanted to make sure that we wouldn\'t be inconveniencing anybody too much.  Are there any operators who still aim to\nsupport connecting with any of the following browsers:\n\n- Firefox < 11.0\n- Chrome < 16.0\n- IE < 10.0\n- Safari < 6.0\n(insert uncommon browser here that doesn\'t support WebSockets natively)\n\nIf so, what is your minimum browser version?\n\nBest Regards,\nSolly Ross\n\n\n','<1897676716.32953671.1403630955743.JavaMail.zimbra@redhat.com>',NULL),('<1756EFC4-ABAF-4377-B44A-219F34C3ABFA@subbu.org>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-16 09:49:17',-28800,'2014-02-16 17:49:17',NULL,'[openstack-dev] [keystone] role of Domain in VPC definition','Harshad,\n\nBut the key question that Ravi brought up remains though. A project is a very small administrative container to manage policies and resources for VPCs. We\'ve been experimenting with VPCs on OpenStack (with some mods) at work for nearly a year, and came across cases where hundreds/thousands of apps in equal number of projects needing to share resources and policies, and project to VPC mapping did not cut. \n\nI was wondering if there was prior discussion around the mapping of AWS VPC model to OpenStack concepts like projects and domains. Thanks for any pointers.\n\nSubbu\n\nOn Feb 16, 2014, at 8:01 AM, Harshad Nakil <hnakil at contrailsystems.com> wrote:\n\n> Yes, [1] can be done without [2] and [3]. \n> As you are well aware [2] is now merged with group policy discussions. \n> IMHO all or nothing approach will not get us anywhere. \n> By the time we line up all our ducks in row. New features/ideas/blueprints will keep Emerging.  \n> \n> Regards\n> -Harshad\n> \n> \n> On Feb 16, 2014, at 2:30 AM, Salvatore Orlando <sorlando at nicira.com> wrote:\n> \n>> It seems this work item is made of several blueprints, some of which are not yet approved. This is true at least for the Neutron blueprint regarding policy extensions.\n>> \n>> Since I first looked at this spec I\'ve been wondering why nova has been selected as an endpoint for network operations rather than Neutron, but this probably a design/implementation details whereas JC here is looking at the general approach.\n>> \n>> Nevertheless, my only point here is that is seems that features like this need an \"all-or-none\" approval.\n>> For instance, could the VPC feature be considered functional if blueprint [1] is implemented, but not [2] and [3]?\n>> \n>> Salvatore\n>> \n>> [1] https://blueprints.launchpad.net/nova/+spec/aws-vpc-support\n>> [2] https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron\n>> [3] https://blueprints.launchpad.net/keystone/+spec/hierarchical-multitenancy\n>> \n>> \n>> On 11 February 2014 21:45, Martin, JC <jch.martin at gmail.com> wrote:\n>> Ravi,\n>> \n>> It seems that the following Blueprint\n>> https://wiki.openstack.org/wiki/Blueprint-aws-vpc-support\n>> \n>> has been approved.\n>> \n>> However, I cannot find a discussion with regard to the merit of using project vs. domain, or other mechanism for the implementation.\n>> \n>> I have an issue with this approach as it prevents tenants within the same domain sharing the same VPC to have projects.\n>> \n>> As an example, if you are a large organization on AWS, it is likely that you have a large VPC that will be shred by multiple projects. With this proposal, we loose that capability, unless I missed something.\n>> \n>> JC\n>> \n>> On Dec 19, 2013, at 6:10 PM, Ravi Chunduru <ravivsn at gmail.com> wrote:\n>> \n>> > Hi,\n>> >   We had some internal discussions on role of Domain and VPCs. I would like to expand and understand community thinking of Keystone domain and VPCs.\n>> >\n>> > Is VPC equivalent to Keystone Domain?\n>> >\n>> > If so, as a public cloud provider - I create a Keystone domain and give it to an organization which wants a virtual private cloud.\n>> >\n>> > Now the question is if that organization wants to have  departments wise allocation of resources it is becoming difficult to visualize with existing v3 keystone constructs.\n>> >\n>> > Currently, it looks like each department of an organization cannot have their own resource management with in the organization VPC ( LDAP based user management, network management or dedicating computes etc.,) For us, Openstack Project does not match the requirements of a department of an organization.\n>> >\n>> > I hope you guessed what we wanted - Domain must have VPCs and VPC to have projects.\n>> >\n>> > I would like to know how community see the VPC model in Openstack.\n>> >\n>> > Thanks,\n>> > -Ravi.\n>> >\n>> >\n>> > _______________________________________________\n>> > OpenStack-dev mailing list\n>> > OpenStack-dev at lists.openstack.org\n>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<-4426752061342328447@unknownmsgid>',NULL),('<1757377754.44033804.1409842842073.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-04 11:00:42',-14400,'2014-09-04 15:00:42',NULL,'[openstack-dev] [nova] Averting the Nova crisis by splitting\n out	virt drivers','> My only question is about the need to separate out each virt driver into a separate project, wouldn\'t you \n> accomplish a lot of the benefit by creating a single virt project that includes all of the drivers?\n\nI don\'t think there\'s particularly a *point* to having all drivers in one repo.  Part of code review is looking for code \"gotchas\", but part of code review is looking for subtle issues that are caused by the very nature of the driver.  A HyperV \"core\" reviewing a libvirt change should certainly be able to provide the former, but most likely cannot provide the latter to a sufficient degree (if he or she can, then he or she should be a libvirt \"core\" as well).\n\nA strong +1 to Dan\'s proposal.  I think this would also make it easier for non-core reviewers to get started reviewing, without having a specialized tool setup.\n\nBest Regards,\nSolly Ross\n\nP.S. \n>This is a crisis. A large crisis. In fact, if you got a moment, it\'s\n> a twelve-storey crisis with a magnificent entrance hall, carpeting\n> throughout, 24-hour portage, and an enormous sign on the roof,\n> saying \'This Is a Large Crisis\'. A large crisis requires a large\n> plan.\n\nHa!\n\n----- Original Message -----\n> From: \"Donald D Dugger\" <donald.d.dugger at intel.com>\n> To: \"Daniel P. Berrange\" <berrange at redhat.com>, \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>\n> Sent: Thursday, September 4, 2014 10:33:27 AM\n> Subject: Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out	virt drivers\n> \n> Basically +1 with what Daniel is saying (note that, as mentioned, a side\n> effect of our effort to split out the scheduler will help but not solve this\n> problem).\n> \n> My only question is about the need to separate out each virt driver into a\n> separate project, wouldn\'t you accomplish a lot of the benefit by creating a\n> single virt project that includes all of the drivers?  I wouldn\'t\n> necessarily expect a VMware guy to understand the specifics of the HyperV\n> implementation but both people should understand what a virt driver does,\n> how it interfaces to Nova and they should be able to intelligently review\n> each other\'s code.\n> \n> --\n> Don Dugger\n> \"Censeo Toto nos in Kansa esse decisse.\" - D. Gale\n> Ph: 303/443-3786\n> \n> -----Original Message-----\n> From: Daniel P. Berrange [mailto:berrange at redhat.com]\n> Sent: Thursday, September 4, 2014 4:24 AM\n> To: OpenStack Development\n> Subject: [openstack-dev] [nova] Averting the Nova crisis by splitting out\n> virt drivers\n> \n> Position statement\n> ==================\n> \n> Over the past year I\'ve increasingly come to the conclusion that Nova is\n> heading for (or probably already at) a major crisis. If steps are not taken\n> to avert this, the project is likely to loose a non-trivial amount of\n> talent, both regular code contributors and core team members. That includes\n> myself. This is not good for Nova\'s long term health and so should be of\n> concern to anyone involved in Nova and OpenStack.\n> \n> For those who don\'t want to read the whole mail, the executive summary is\n> that the nova-core team is an unfixable bottleneck in our development\n> process with our current project structure.\n> The only way I see to remove the bottleneck is to split the virt drivers out\n> of tree and let them all have their own core teams in their area of code,\n> leaving current nova core to focus on all the common code outside the virt\n> driver impls. I, now, none the less urge people to read the whole mail.\n> \n> \n> Background information\n> ======================\n> \n> I see many factors coming together to form the crisis\n> \n>  - Burn out of core team members from over work\n>  - Difficulty bringing new talent into the core team\n>  - Long delay in getting code reviewed & merged\n>  - Marginalization of code areas which aren\'t popular\n>  - Increasing size of nova code through new drivers\n>  - Exclusion of developers without corporate backing\n> \n> Each item on their own may not seem too bad, but combined they add up to a\n> big problem.\n> \n> Core team burn out\n> ------------------\n> \n> Having been involved in Nova for several dev cycles now, it is clear that the\n> backlog of code up for review never goes away. Even intensive code review\n> efforts at various points in the dev cycle makes only a small impact on the\n> backlog. This has a pretty significant impact on core team members, as their\n> work is never done. At best, the dial is sometimes set to 10, instead of 11.\n> \n> Many people, myself included, have built tools to help deal with the reviews\n> in a more efficient manner than plain gerrit allows for. These certainly\n> help, but they can\'t ever solve the problem on their own - just make it\n> slightly more bearable. And this is not even considering that core team\n> members might have useful contributions to make in ways beyond just code\n> review. Ultimately the workload is just too high to sustain the levels of\n> review required, so core team members will eventually burn out (as they have\n> done many times already).\n> \n> Even if one person attempts to take the initiative to heavily invest in\n> review of certain features it is often to no avail.\n> Unless a second dedicated core reviewer can be found to \'tag team\' it is hard\n> for one person to make a difference. The end result is that a patch is +2d\n> and then sits idle for weeks or more until a merge conflict requires it to\n> be reposted at which point even that one +2 is lost. This is a pretty\n> demotivating outcome for both reviewers & the patch contributor.\n> \n> \n> New core team talent\n> --------------------\n> \n> It can\'t escape attention that the Nova core team does not grow in size very\n> often. When Nova was younger and its code base was smaller, it was easier\n> for contributors to get onto core because the base level of knowledge\n> required was that much smaller. To get onto core today requires a major\n> investment in learning Nova over a year or more. Even people who potentially\n> have the latent skills may not have the time available to invest in learning\n> the entire of Nova.\n> \n> With the number of reviews proposed to Nova, the core team should probably be\n> at least double its current size[1]. There is plenty of expertize in the\n> project as a whole but it is typically focused into specific areas of the\n> codebase. There is nowhere we can find\n> 20 more people with broad knowledge of the codebase who could be promoted\n> even over the next year, let alone today. This is ignoring that many\n> existing members of core are relatively inactive due to burnout and so need\n> replacing. That means we really need another\n> 25-30 people for core. That\'s not going to happen.\n> \n> \n> Code review delays\n> ------------------\n> \n> The obvious result of having too much work for too few reviewers is that code\n> contributors face major delays in getting their work reviewed and merged.\n> From personal experience, during Juno, I\'ve probably spent 1 week in\n> aggregate on actual code development vs\n> 8 weeks on waiting on code review. You have to constantly be on alert for\n> review comments because unless you can respond quickly (and repost) while\n> you still have the attention of the reviewer, they may not be look again for\n> days/weeks.\n> \n> The length of time to get work merged serves as a demotivator to actually do\n> work in the first place. I\'ve personally avoided doing alot of code\n> refactoring & cleanup work that would improve the maintainability of the\n> libvirt driver in the long term, because I can\'t face the battle to get it\n> reviewed & merged. Other people have told me much the same. It is not\n> uncommon to see changes that have been pending for 2 dev cycles, not because\n> the code was bad but because they couldn\'t get people to review it.\n> Contributors will simply walk away from nova if that happens too often.\n> \n> Even when fate is on your side and code is reviewed, the chances of it\n> getting a success result from the CI systems first time around is slim due\n> to false failures. This really compounds the already poor experiance of\n> submitting code to Nova.\n> \n> \n> Marginalization of areas\n> ------------------------\n> \n> Since the core team has far more work to do than it can manage, it has to\n> prioritize what it looks at. The core team figures out what the overall\n> project priorities are and will focus more effort in to those areas.\n> Individual members will also focus their attention in areas where they have\n> personal interest. Unfortunately the core team is not representative of the\n> entire of Nova codebase. The inevitable result is that the HyperV and VMWare\n> drivers can often loose out in the battle for attention. In the past we\'ve\n> said that it is the responsibility of people in those teams to invest in\n> learning the entire of Nova so that they have the knowledge required to be\n> promoted to core. I used to support that approach, but now consider to be\n> flawed due to the increased difficulty of *anyone* getting onto core. The\n> time investment required is simply too great to expect people to undertake\n> it. The marginalized areas have no freedom to self-organize to solve their\n> own problems because the!\n>  y are forever dependant on the core team bottleneck.\n> \n> \n> Increasing size\n> ---------------\n> \n> There is a long standing policy that the Nova virt driver API is considered\n> unstable and thus all virt driver implementations should ultimately be part\n> of the Nova codebase. In Juno it is likely that the Ironic driver will be\n> merged into Nova. In a future release we may yet see the Docker driver\n> return to the Nova tree.\n> \n> The result of merging yet more drivers is that there will be yet more work\n> for nova reviewers to do. It is far from obvious that merging new drivers\n> will be accompanied by new members on the core team. So it is likely that\n> the workload is going to get worse over future releases.\n> \n> Splitting out the scheduler will be beneficial in reducing the review\n> backlog, but probably not enough to counter the growth from virt drivers.\n> Killing of nova-network is unlikely to help at all, since that consumes\n> little-to-no review time currently [2].\n> \n> \n> Exclusion of non-corporate devs\n> -------------------------------\n> \n> There is a strong push from nova core for everything that is merged into Nova\n> to be accompanied by CI testing. This certainly makes sense from the POV of\n> overall product quality and reducing the burden on the core reviewers to\n> catch all mistakes through code review. What we don\'t take into account is\n> that setting up and maintaining such testing infrastructure requires a major\n> investment in terms of both hardware costs and man power. It has already\n> been seen that this is too much to bear for some companies who contribute to\n> Nova, eg with the Docker driver [3]. Developers who are not affiliated with\n> any company do not stand any realistic chance of meeting the CI testing\n> needs unless they\'re lucky that their feature can be covered by an existing\n> running CI system. This looks like it could effectively prevent support for\n> a community submitted FreeBSD BHyve driver from being merged, no matter how\n> useful it might be to users who want it.\n> NB, now a FreeBSD BHyve driver would probably be done as part of the libvirt\n> driver, which complicates this particular point I\'m trying to make, since I\n> don\'t suggest reducing testing of the libvirt driver compared to what it has\n> today.\n> \n> I don\'t want to get into a detailed testing discussion here really, since\n> that\'s somewhat of a tangent to the question of our dev and review process.\n> I am, however, concerned when our testing policy forces maintainers of some\n> virt drivers into the position of being treated as second class citizens\n> within the project as a whole, with a different development structure to the\n> in-tree approved drivers.\n> That said, Docker probably benefits from being out of tree, since it thus\n> avoids the painful nova core bottleneck entirely.\n> \n> \n> Problem summary\n> ---------------\n> \n> The common thread through most of these problems is that the nova core team\n> is a massive bottleneck in the development process.\n> Processes adopted (or under discussion) by the core team are fundamentally\n> not helping to remove the bottleneck. Rather they are introducing new layers\n> of beaurocracy so that we can feel justified in telling contributors that we\n> are going to ignore or reject their work. At best this is going to result in\n> far less useful work taking place in Nova. At worst this is further reducing\n> the ability of people to self organize to solve the problems, will cause our\n> contribtors to leave the community and possibly even force some virt drivers\n> to go out of tree to get their work done. Death by a thousand cuts.\n> \n> A sub-thread is around the idea that our current structure of one big repo\n> also has other negative consequences for drivers who may not be able to meet\n> the same high standards as the rest of the drivers. A driver is either in or\n> out of the club, and if its out of the club life is made comparatively\n> harder for its developers & users. By all means have rules around that\n> requirements for a release to use the openstack trademarks based on CI\n> testing coverage, but don\'t let that penalize the actual development process\n> itself.\n> \n> Overall Nova is being increasingly hostile to its community of contributors.\n> I don\'t mean this as a result of any sense of malice or ill-will. What we\'re\n> seeing is merely a symptom of a hard worked team struggling to survive with\n> a burden they can no longer be reasonably expected to cope with. Nova core\n> has done an amazing job at surviving for so long as the project grew much\n> larger & more quickly than anyone probably expected. The time has come for\n> some radical changes to let nova adapt & evolve to the next level.\n> \n> This is a crisis. A large crisis. In fact, if you got a moment, it\'s a\n> twelve-storey crisis with a magnificent entrance hall, carpeting throughout,\n> 24-hour portage, and an enormous sign on the roof, saying \'This Is a Large\n> Crisis\'. A large crisis requires a large plan.\n> \n> \n> Proposal / solution\n> ===================\n> \n> In the past Nova has spun out its volume layer to form the cinder project.\n> The Neutron project started as an attempt to solve the networking space, and\n> ultimately replace the nova-network. It is likely that the schedular will be\n> spun out to a separate project.\n> \n> Now Neutron itself has grown so large and successful that it is considering\n> going one step further and spinning its actual drivers out of tree into\n> standalone add-on projects [4]. I\'ve heard on the grapevine that Ironic is\n> considering similar steps for hardware drivers.\n> \n> The radical (?) solution to the nova core team bottleneck is thus to follow\n> this lead and split the nova virt drivers out into separate projects and\n> delegate their maintainence to new dedicated teams.\n> \n>  - Nova becomes the home for the public APIs, RPC system, database\n>    persistent and the glue that ties all this together with the\n>    virt driver API.\n> \n>  - Each virt driver project gets its own core team and is responsible\n>    for dealing with review, merge & release of their codebase.\n> \n> Note, I really do mean *all* virt drivers should be separate. I do not want\n> to see some virt drivers split out and others remain in tree because I feel\n> that signifies that the out of tree ones are second class citizens. It is\n> important to set up our dev structure so that every virt driver is treated\n> equally & so has equal chance to achieve success. As long as one driver\n> remains in tree there will always be pressure for others to join it, which\n> is exactly what we\'re trying to get away from here. By everyone being out of\n> tree, drivers (like\n> Docker) can take a decision about whether it is the right time for them to be\n> investing in gating CI systems, without being penalized in their dev process\n> if they make a decision to not have gate tests right now.\n> \n> This has quite a few implications for the way development would operate.\n> \n>  - The Nova core team at least, would be voluntarily giving up a big\n>    amount of responsibility over the evolution of virt drivers. Due\n>    to human nature, people are not good at giving up power, so this\n>    may be painful to swallow. Realistically current nova core are\n>    not experts in most of the virt drivers to start with, and more\n>    important we clearly do not have sufficient time to do a good job\n>    of review with everything submitted. Much of the current need\n>    for core review of virt drivers is to prevent the mis-use of a\n>    poorly defined virt driver API...which can be mitigated - See\n>    later point(s)\n> \n>  - Nova core would/should not have automatic +2 over the virt driver\n>    repositories since it is unreasonable to assume they have the\n>    suitable domain knowledge for all virt drivers out there. People\n>    would of course be able to be members of multiple core teams. For\n>    example John G would naturally be nova-core and nova-xen-core. I\n>    would aim for nova-core and nova-libvirt-core, and so on. I do not\n>    want any +2 responsibility over VMWare/HyperV/Docker drivers since\n>    they\'re not my area of expertize - I only look at them today because\n>    they have no other nova-core representation.\n> \n>  - Not sure if it implies the Nova PTL would be solely focused on\n>    Nova common. eg would there continue to be one PTL over all virt\n>    driver implementation projects, or would each project have its\n>    own PTL. Maybe this is irrelevant if a Czars approach is chosen\n>    by virt driver projects for their work. I\'d be inclined to say\n>    that a single PTL should stay as a figurehead to represent all\n>    the virt driver projects, acting as a point of contact to ensure\n>    we keep communication / co-operation between the drivers in sync.\n> \n>  - A fairly significant amount of nova code would need to be\n>    considered semi-stable API. Certainly everything under nova/virt\n>    and any object which is passed in/out of the virt driver API.\n>    Changes to such APIs would have to be done in a backwards\n>    compatible manner, since it is no longer possible to lock-step\n>    change all the virt driver impls. In some ways I think this would\n>    be a good thing as it will encourage people to put more thought\n>    into the long term maintainability of nova internal code instead\n>    of relying on being able to rip it apart later, at will.\n> \n>  - The nova/virt/driver.py class would need to be much better\n>    specified. All parameters / return values which are opaque dicts\n>    must be replaced with objects + attributes. Completion of the\n>    objectification work is mandatory, so there is cleaner separation\n>    between virt driver impls & the rest of Nova.\n> \n>  - If changes are required to common code, the virt driver developer\n>    would first have to get the necccessary pieces merged into Nova\n>    common. Then the follow up virt driver specific changes could be\n>    proposed to their repo. This implies that some changes to virt\n>    drivers will still contend for resource in the common nova repo\n>    and team. This contention should be lower than it is today though\n>    since the current nova core team should have less code to look\n>    after per-person on aggregate.\n> \n>  - Changes submitted to nova common code would trigger running of CI\n>    tests against the external virt drivers. Each virt driver core team\n>    would decide whether they want their driver to be tested upon Nova\n>    common changes. Expect that all would choose to be included to the\n>    same extent that they are today. So level of validation of nova code\n>    would remain at least at current level. I don\'t want to reduce the\n>    amount of code testing here since that\'s contrary to the direction\n>    we\'re taking wrt testing.\n> \n>  - Changes submitted to virt drivers would trigger running CI tests\n>    that are applicable. eg changes to libvirt driver repo would not\n>    involve running database migration tests, since all database code\n>    is isolated in nova. libvirt changes would not trigger vmware,\n>    xenserver, ironic, etc CI systems. Virt driver changes should\n>    see fewer false positives in the tests as a result, and those\n>    that do occur should be more explicitly related to the code being\n>    proposed. eg a change to vmware is not going to trigger a tempest\n>    run that uses libvirt, so non-deterministic failures in libvirt\n>    will no longer plague vmware developers reviews. This would also\n>    make it possible for VMWare CI to be made gating for changes to\n>    the VMWare virt driver repository, without negatively impacting\n>    other virt drivers. So this change should increase testing quality\n>    for non-libvirt virt drivers and reduce pain of false failures\n>    for everyone.\n> \n>  - Virt drivers shouldn\'t use oslo incubator code from nova, since\n>    that can be replaced any time and isn\'t upgrade safe. Ideally most\n>    of the incubator stuff virt drivers need should turn into stable\n>    oslo APIs. Failing that, virt drivers would need their own copy\n>    of the incubated code in their module namespace, to avoid clash\n>    or the need to lock-step upgrade code across separate git repos.\n> \n> Overall the outcome is that\n> \n>  - Far larger pool of people able to approve changes for merge\n>    across nova core and the virt driver core teams.\n> \n>  - Faster review & merge for virt driver patches that don\'t involve\n>    changes to common nova code, with less CI system testing pain.\n> \n>  - Ability to set priority of work in virt drivers without a 3rd\n>    party being a bottleneck, where the work doesn\'t involve changes\n>    to common nova code.\n> \n>  - Each virt driver team can accept as many features as they feel\n>    able to deal with, without it negatively impacting amount of\n>    features that other virt driver teams can accept.\n> \n>  - Virt drivers have flexibility to set their own policies on testing\n>    without being penalized in the way they then develop their code.\n> \n> \n> The migration\n> -------------\n> \n> Obviously a proposal such as this is a pretty major undertaking. It should be\n> clear that it could not be done in a short amount of time.\n> It is suggested that it be phased in over two dev cycles. In the Kilo release\n> the focus would be on prep work:\n> \n>   - Formalizing the separation between the virt driver impls and the\n>     rest of the nova codebase. Figure out exactly which areas of\n>     Nova internal code will need to be marked as \'semi-stable\' for\n>     use by virt drivers, and ensure their APIs are sufficiently\n>     future proof.\n> \n>   - Discussions with the infrastructure, docs, release, etc teams to\n>     identify impacts on them and do any required prep work.\n> \n>   - Identify the teams which will lead the new virt driver projects.\n>     eg core reviewers, PTL or Czars for each job if applicable\n> \n>   - Probably more things I can\'t think of right now\n> \n> Then at the start of the Lxxxx release, the virt drivers would actually be\n> split out into separate git repos and start their dev process for the\n> future. So for bulk of Lxxxx the drivers would be on their own. The two\n> Lxxxx rc milestones would allow us to ensure our release processes were\n> working well with the split drivers before the Lxxxx final release.\n> \n> \n> Final thought\n> -------------\n> \n> Overall consider this a vote of no confidence in nova continuing to operate\n> as it does today. As mentioned above this is not intended to be disrepectful\n> to the effort every nova core member has put in, just a reflection on the\n> changed environment we find ourselves in. Fiddling with our processes for\n> the prioritization of work cannot fix the fundamental fact that nova core\n> today is a massive single point of failure & bottleneck, increasingly\n> crippling the project. The only way to address this is by a radical\n> re-organization of our project to remove the bottlenecks by modularization\n> of the project & leaders.\n> Keeping a single team and adding more/changing process is simply akin to\n> shifting deckchairs on the titanic and not a viable option to coninue with\n> long term.\n> \n> Now, I\'m realistic. Even with every driver separated out, I expect that each\n> of them will individually still have more work proposed than their\n> respective core teams have time to review. The new structure will, however,\n> make it easier for the core individal teams to grow & adapt in ways that\n> suit their specific needs. For self-contained virt driver changes it will\n> mean that acceptance of work by one team will not take away capacity from\n> another team. Further the burden of knowledge required to make it onto a\n> virt driver core team would be greatly reduced due to the narrower focus of\n> each core team, so we\'ll be able to promote good talent onto virt driver\n> core teams more quickly.\n> \n> Thanks for reading so far. Now lets make some real change to prepare us for\n> future sustainability & even growth.\n> \n> Regards,\n> Daniel\n> \n> [1]\n> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044459.html\n> [2] There was a ban on changes to nova-network for much of the past two\n>     cycles. It was relaxed primarily to allow full conversion of nova\n>     codebase to use objects, not for major new feature development.\n> [3] http://lists.openstack.org/pipermail/openstack-dev/2014-July/040443.html\n> [4]\n> http://lists.openstack.org/pipermail/openstack-dev/2014-August/043036.html\n> \n> --\n> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|\n> |: http://libvirt.org              -o-             http://virt-manager.org :|\n> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|\n> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<6AF484C0160C61439DE06F17668F3BCB53388E0C@ORSMSX114.amr.corp.intel.com>',NULL),('<1758188990.13998661.1401292790481.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-28 11:59:50',-14400,'2014-05-28 15:59:50',NULL,'[openstack-dev] Specifying file encoding','\n\n----- Original Message -----\n> From: \"Martin Geisler\" <martin at geisler.net>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, May 28, 2014 11:35:02 AM\n> Subject: Re: [openstack-dev] Specifying file encoding\n> \n> Ryan Brady <rbrady at redhat.com> writes:\n> \n> > ----- Original Message -----\n> >> From: \"P?draig Brady\" <P at draigBrady.com>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >> <openstack-dev at lists.openstack.org>\n> >> Sent: Wednesday, May 28, 2014 6:28:28 AM\n> >> Subject: Re: [openstack-dev] Specifying file encoding\n> >> \n> >> On 05/28/2014 08:16 AM, Martin Geisler wrote:\n> >> > Hi everybody,\n> >> > \n> >> > I\'m trying to get my feet wet with OpenStack development,\n> >\n> > Welcome aboard!  Thanks for contributing.  :)\n> >\n> >>> so I recently\n> >> > tried to submit some small patches. One small thing I noticed was that\n> >> > some files used\n> >> > \n> >> >   # -*- encoding: utf-8 -*-\n> >> > \n> >> > to specify the file encoding for both Python and Emacs. Unfortunately,\n> >> > Emacs expects you to set \"coding\", not \"encoding\". Python is fine with\n> >> > either. I submitted a set of patches for this:\n> >> > \n> >> > * https://review.openstack.org/95862\n> >> > * https://review.openstack.org/95864\n> >> > * https://review.openstack.org/95865\n> >> > * https://review.openstack.org/95869\n> >> > * https://review.openstack.org/95871\n> >> > * https://review.openstack.org/95880\n> >> > * https://review.openstack.org/95882\n> >> > * https://review.openstack.org/95886\n> >> > \n> >> > It was pointed out to me that such a change ought to be coordinated\n> >> > better via bug(s) or the mailinglist, so here I am :)\n> >> \n> >> This is valid change.\n> >> I don\'t see why there is any question\n> >> as it only improves the situation for emacs\n> >> which will pop up an error when trying to edit these files.\n> >\n> > I guess I approach this differently. When I saw this patch, my first\n> > thought was to validate if the line being changed needed to exist at\n> > all.\n> \n> That makes a lot of sense!\n> \n> > If the file has valid non-ascii characters that effect its execution,\n> > are absolutely required for documentation to convey a specific\n> > meaning, or in strings that need to translate, then I agree the change\n> > is valid. But in the case the characters in the file can be changed,\n> > it seems like the bug is the extra encoding comment itself.\n> \n> I see what you mean -- I also try to keep my files just ASCII for\n> convenience (even though I\'m from Denmark where we have the extra three\n> vowels ?, ?, and ?). As a brand new contributor, changing copyright\n> statements seemed like a bigger change than updating the coding line :)\n> \n\nIt helps me to think about effort, value, complexity, future maintenance,\nand dependencies when evaluating changes.\n\n> > Taking tuskar for example, the files in question seem to only need\n> > this encoding line to support the copyright symbol.\n> >\n> > [rb at localhost tuskar]$ grep -R -i -P \"[^\\x00-\\x7F]\" ./*\n> > Binary file ./doc/source/api/img/model_v2.jpg matches\n> > Binary file ./doc/source/api/img/model_v4.odg matches\n> > Binary file ./doc/source/api/img/model.odg matches\n> > Binary file ./doc/source/api/img/model_v3.jpg matches\n> > Binary file ./doc/source/api/img/model_v3.odg matches\n> > Binary file ./doc/source/api/img/model_v2.odg matches\n> > Binary file ./doc/source/api/img/model_v4.jpg matches\n> > Binary file ./doc/source/api/img/model_v1.jpg matches\n> > Binary file ./doc/source/_static/header_bg.jpg matches\n> > Binary file ./doc/source/_static/header-line.gif matches\n> > Binary file ./doc/source/_static/openstack_logo.png matches\n> > ./tuskar/api/hooks.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n> > ./tuskar/api/app.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n> > ./tuskar/api/acl.py:# Copyright ? 2012 New Dream Network, LLC (DreamHost)\n> > ./tuskar/common/service.py:# Copyright ? 2012 eNovance\n> > <licensing at enovance.com>\n> > ./tuskar/tests/api/api.py:# Copyright ? 2012 New Dream Network, LLC\n> > (DreamHost)\n> >\n> >\n> > In the U.S., copyright notices haven\'t really been needed since 1989.\n> > You also only need to include\n> > one instance of the symbol, \"Copyright\" or \"copr\" [1]. If the\n> > requirements for copyright are different\n> > outside the U.S., then I hope we capture that in the copyright wiki\n> > page [2]. Maybe the current info\n> > in that wiki needs to be updated or at least notated as to why the\n> > specific notice text is suggested.\n> >\n> > Unless there is another valid requirement to keep the ? in the files,\n> > I think it\'s best if we just remove them altogether and eliminate the\n> > need to add the encoding comments at all.\n> \n> Sounds good to me. I\'ll update my script to do this and rework the patch\n> sets. I\'ve made most patches as two: one that removes coding lines that\n> are currently redudant and one that adjusts the remaining lines to make\n> Emacs happy.\n> \n> Would you want to merge the patches that simply remove the unneeded\n> lines and then let me followup with patches that remove ? along with the\n> then unnecessary coding lines?\n\nIf I was in your position, I\'d update the patches that remove lines to include all\nof the affected files and also remove the ?.  I\'d abandon the patches that simply\nupdate the line for Emacs compatibility.\n\n> \n> I\'m asking since it seems that Gerrit encourages a different style of\n> development than most other projects I know -- single large commits\n> instead of a series of smaller commits, each one logical step building\n> on the previous.\n> \n\nWhen patches are too complex, breaking them down makes it easier to review, easier\nto test and easier to revert.  In this case, I don\'t think you\'re adding complexity\nby changing a line and a character in comments for each file in the scope of a project.\nOpinions may vary project to project.  \n\nCheers,\n\nRyan\n\n> --\n> Martin Geisler\n> \n> https://plus.google.com/+MartinGeisler/\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<87egzd7w7t.fsf@geisler.net>',NULL),('<1758453796.1471903.1421651497472.JavaMail.yahoo@jws10919.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-19 07:11:37',0,'2015-01-19 07:11:37',NULL,'[Openstack] login(SSH) to open-stack instance','You need to ssh into instance using keypair if you want to access it.?\n?\nRegards\nNeelu \n\n     On Monday, 19 January 2015 12:37 PM, somshekar kadam <som_kadam at yahoo.co.in> wrote:\n   \n\n Hi Vedsar,?\nJust check this?Add a keypair, security rules to allow and then try it?for example ssh -i keypair.pem fedora at IP?this link will be useful?\nConfigure access and security for instances?-?OpenStack End User Guide ?-?current\n\n| ? |\n| ? |  | ? | ? | ? | ? | ? |\n| Configure access and security for instances?-?OpenStack ...?Configure access and security for instances Add a key pair Import a key pair Create and manage security groups Create and manage security group rules  |\n|  |\n| View on docs.openstack.org | Preview by Yahoo |\n|  |\n| ? |\n\n\n?\nRegards\nNeelu \n\n     On Monday, 19 January 2015 1:14 AM, Steven Dake <sdake at redhat.com> wrote:\n   \n\n  On 01/17/2015 12:17 PM, Vedsar Kushwaha wrote:\n  \n  I can spawn instances from openstack, but I\'m not able to ping or SSH to those instances. Moreover, I\'m also not able to open the console give in dashboard of openstack. Security policies are set to allow all protocols.\n \n  Please Help.\n     \n       \n if your using Neutron, you may need to specify the --nic net= option to nova boot.\n \n I usually use the UUID of my public neutron network\n \n eg \n \n neutron net-show public\n \n Regards\n -steve\n \n \n      -- \n    Vedsar Kushwaha M.Tech-Computational Science Indian Institute of Science           \n  \n _______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n \n \n \n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to? ? : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n    \n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20150119/71a91aba/attachment.html>\n\n','<969637167.1473294.1421651249790.JavaMail.yahoo@jws10953.mail.sg3.yahoo.com>',NULL),('<1758697976.467.1367129760377.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-28 06:16:00',0,'2013-04-28 06:16:00',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-nova-python27-stable-grizzly #18','See <https://jenkins.openstack.org/job/periodic-nova-python27-stable-grizzly/18/changes>\n\n\n\n','<1635388516.410.1367043027156.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1758F814-1C49-46A9-9016-9A5BC5393476@not.mn>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2013-01-11 21:28:21',0,'2013-01-11 21:28:21',NULL,'[Openstack-operators] [SWIFT] Change the partition power to\n	recreate the RING','If effect, this would be a complete replacement of your rings, and that is essentially a whole new cluster. All of the existing data would need to be rehashed into the new ring before it is available.\n\nThere is no process that rehashes the data to ensure that it is still in the correct partition. Replication only ensures that the partitions are on the right drives.\n\nTo change the number of partitions, you will need to GET all of the data from the old ring and PUT it to the new ring. A more complicated, but perhaps more efficient) solution may include something like walking each drive and rehashing+moving the data to the right partition and then letting replication settle it down.\n\nEither way, 100% of your existing data will need to at least be rehashed (and probably moved). Your CPU (hashing), disks (read+write), RAM (directory walking), and network (replication) may all be limiting factors in how long it will take to do this. Your per-disk free space may also determine what method you choose.\n\nI would not expect any data loss while doing this, but you will probably have availability issues, depending on the data access patterns.\n\nI\'d like to eventually see something in swift that allows for changing the partition power in existing rings, but that will be hard/tricky/non-trivial.\n\nGood luck.\n\n--John\n\n\nOn Jan 11, 2013, at 1:17 PM, Alejandro Comisario <alejandro.comisario at mercadolibre.com> wrote:\n\n> Hi guys.\n> We\'ve created a swift cluster several months ago, the things is that righ now we cant add hardware and we configured lots of partitions thinking about the final picture of the cluster.\n> \n> Today each datanodes is having 2500+ partitions per device, and even tuning the background processes ( replicator, auditor & updater ) we really want to try to lower the partition power.\n> \n> Since its not possible to do that without recreating the ring, we can have the luxury of recreate it with a very lower partition power, and rebalance / deploy the new ring.\n> \n> The question is, having a working cluster with *existing data* is it possible to do this and wait for the data to move around *without data loss* ???\n> If so, it might be true to wait for an improvement in the overall cluster performance ?\n> \n> We have no problem to have a non working cluster (while moving the data) even for an entire weekend.\n> \n> Cheers.\n> \n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: smime.p7s\nType: application/pkcs7-signature\nSize: 4082 bytes\nDesc: not available\nURL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130111/dd46854c/attachment.bin>\n\n','<CAMrG31zYvn=jJqgO2H6aW0fM41o90B69umcnLns-W-LXevL+mA@mail.gmail.com>',NULL),('<1759361669.13945573.1378969411623.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-12 03:03:31',-14400,'2013-09-12 07:03:31',NULL,'[Openstack] [Ceilometer/Heat in Havana]: Should autoscaling\n groups	work already?','\n\nHi Juha,\n\nThe problem you\'re encountering is a known restriction of the sqlalchemy storage\ndriver, which doesn\'t yet provide the capability to select the statistics for the\ngiven Heat autoscaling group on which the scale up/down alarms are based (the so-\ncalled metaquery feature).\n\nIn order for this feature to be present in the ceilometer API service, you\'ll need\nto use the mongodb storage driver instead.\n\nThanks,\nEoghan \n\n----- Original Message -----\n> Hi,\n> \n> I met the problem when tried to be using autoscaling groups in heat templates\n> with havana (see:\n> https://bugs.launchpad.net/heat/+bug/1223710 )\n> \n> Can anyone confirm whether the autoscaling should already work with havana?\n> \n> Currently the evaluation of the ceilometer alarm/meter data seems to be\n> failing:\n> \n> \n> \n> ceilometer-alarm-singleton:\n> ======================\n> 2013-09-11 10:16:28.074 5326 INFO ceilometer.alarm.threshold_evaluation [-]\n> initiating evaluation cycle on 3 alarms\n> 2013-09-11 10:16:28.108 5326 ERROR ceilometer.alarm.threshold_evaluation [-]\n> alarm stats retrieval failed\n> ...\n> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation File\n> \"/opt/stack/python-ceilometerclient/ceilometerclient/v2/statistics.py\", line\n> 29, in list\n> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation\n> \'/v2/meters/\' + meter_name + \'/statistics\',\n> 2013-09-11 10:16:28.108 5326 TRACE ceilometer.alarm.threshold_evaluation\n> TypeError: cannot concatenate \'str\' and \'NoneType\' objects\n> \n> ceilometer-api:\n> ===============\n> 2013-09-11 10:16:28.221 4500 ERROR wsme.api [-] Server-side error: \"metaquery\n> not implemented\". Detail:\n> Traceback (most recent call last):\n> \n> File \"/usr/local/lib/python2.7/dist-packages/wsmeext/pecan.py\", line 70, in\n> callfunction\n> result = f(self, *args, **kwargs)\n> \n> File \"/opt/stack/ceilometer/ceilometer/api/controllers/v2.py\", line 693, in\n> statistics\n> for c in computed]\n> \n> File \"/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py\", line 517,\n> in get_meter_statistics\n> query = self._make_stats_query(sample_filter, groupby)\n> \n> File \"/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py\", line 468,\n> in _make_stats_query\n> return make_query_from_filter(query, sample_filter)\n> \n> File \"/opt/stack/ceilometer/ceilometer/storage/impl_sqlalchemy.py\", line 137,\n> in make_query_from_filter\n> raise NotImplementedError(\'metaquery not implemented\')\n> \n> NotImplementedError: metaquery not implemented\n> \n> \n> Many thanks,\n> -Juha\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAHYuhGxkONaQ3oSeKe-a2B2nEZXLhjh4dHe5mzCtoifjnciZCg@mail.gmail.com>',NULL),('<1759545777.8425874.1404927873498.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-09 13:44:33',-14400,'2014-07-09 17:44:33',NULL,'[openstack-dev] [qa][all] Branchless Tempest beyond pure-API\n tests, impact on backporting policy','\nThanks for the response Matt, some comments inline.\n\n> > At the project/release status meeting yesterday[1], I raised the issue\n> > that featureful backports to stable are beginning to show up[2], purely\n> > to facilitate branchless Tempest. We had a useful exchange of views on\n> > IRC but ran out of time, so this thread is intended to capture and\n> > complete the discussion.\n> \n> So, [2] is definitely not something that should be backported.\n\nAgreed. It was the avoidance of such forced backports that motivated\nthe thread.\n\n> But, doesn\'t it mean that cinder snapshot notifications don\'t work\n> at all in icehouse?\n\nThe snapshot notifications work in the sense that cinder emits them\nat the appropriate points in time. What was missing in Icehouse is\nthat ceilometer didn\'t consume those notifications and translate to\nmetering data.\n\n> Is this reflected in the release notes or docs somewhere\n\nYeah it should be clear from the list of meters in the icehouse docs:\n\n  https://github.com/openstack/ceilometer/blob/stable/icehouse/doc/source/measurements.rst#volume-cinder\n\nversus the Juno version:\n\n  https://github.com/openstack/ceilometer/blob/master/doc/source/measurements.rst#volume-cinder\n\n> because it seems like something that would be expected to work, which,\n> I think, is actually a bigger bug being exposed by branchless tempest.\n\nThe bigger bug being the lack of ceilometer support for consuming this\nnotification, or the lack of discoverability for that feature?\n\n> As a user how do I know that with the cloud I\'m using whether cinder\n> snapshot notifications are supported?\n\nIf you depend on this as a front-end user, then you\'d have to read\nthe documentation listing the meters being gathered.\n\nBut is this something that a front-end cloud user would actually be\ndirectly concerned about?\n \n> >  * Tempest has an implicit bent towards pure API tests, yet not all\n> >    interactions between OpenStack services that we want to test are\n> >    mediated by APIs\n> \n> I think this is the bigger issue. If there is cross-service communication it\n> should have an API contract. (and probably be directly tested too) It doesn\'t\n> necessarily have to be a REST API, although in most cases that\'s easier. This\n> is probably something for the TC to discuss/mandate, though.\n\nAs I said at the PTLs meeting yesterday, I think we need to be wary\nof the temptation to bend the problem-space to fit the solution.\n\nShort of the polling load imposed by ceilometer significantly increasing,\nin reality we will have to continue to depend on notifications as one\nof the main ways of detecting \"phase-shifts\" in resource state.\n\nNote that the notifications that capture these resource state transitions\nare a long-standing mechanism in openstack that ceilometer has depended\non from the very outset. I don\'t think it\'s realistic to envisage these\ninteractions will be replaced by REST APIs any time soon.\n\n> > The branchless Tempest spec envisages new features will be added and\n> > need to be skipped when testing stable/previous, but IIUC requires\n> > that the presence of new behaviors is externally discoverable[5].\n> \n> I think the test case you proposed is fine. I know some people will\n> argue that it is expanding the scope of tempest to include more\n> whitebox like testing, because the notification are an internal\n> side-effect of the api call, but I don\'t see it that way. It feels\n> more like exactly what tempest is there to enable testing, a\n> cross-project interaction using the api.\n\nIn my example, APIs are only used to initiate the action in cinder\nand then to check the metering data in ceilometer.\n\nBut the middle-piece, i.e. the interaction between cinder & ceilometer,\nis not mediated by an API. Rather, its carried via an unversioned\nnotification.\n\n> I\'m pretty sure that most of the concerns around tests like this\n> were from the gate maintenance and debug side of things. In other\n> words when things go wrong how impossible will it be to debug that a\n> notification wasn\'t generated or not counted? Right now I think it\n> would be pretty difficult to debug a notification test failure,\n> which is where the problem is. While I think testing like this is\n> definitely valid, that doesn\'t mean we should rush in a bunch of\n> sloppy tests that are impossible to debug, because that\'ll just make\n> everyone sad panda.\n\nIt\'s a fair point that cross-service diagnosis is not necessarily easy,\nespecially as there\'s pressure to reduce the volume of debug logging\nemitted. But notification-driven metering is an important part of what\nceilometer does, so we need to figure out some way of integration-testing\nit, IMO.\n\n> But, they\'re is also a slight misunderstanding here. Having a\n> feature be externally discoverable isn\'t a hard requirement for a\n> config option in tempest, it\'s just *strongly* recommended. Mostly,\n> because if there isn\'t a way to discover it how are end users\n> expected to know what will work.\n\nA-ha, I missed the subtle distinction there and thought that this\ndiscoverability was a *strict* requirement. So how bad a citizen would\na project be considered to be if it chose not to meet that strong\nrecommendation?\n\n> For this specific case I think it\'s definitely fair to have an\n> option for which notifications services are expected to be\n> generated. That\'s something that is definitely a configurable option\n> when setting up a deployment, and is something that feels like a\n> valid tempest config option, so we know which tests will work. We\n> already have similar feature flags for config time options in the\n> services, and having options like that would also get you out of\n> that backport mess you have right now.\n\nSo would this test configuration option would have a semantic like:\n\n \"a wildcarded list of notification event types that ceilometer consumes\"\n\nthen tests could be skipped on the basis of the notifications that\nthey depend on being unavailable, in the manner of say:\n\n  @testtools.skipUnless(\n      matchesAll(CONF.telemetry_consumed_notifications.volume,\n                 [\'snapshot.exists\',\n                  \'snapshot.create.*\',\n                  \'snapshot.delete.*\',\n                  \'snapshot.resize.*\',]\n                )\n  )\n  @test.services(\'volume\')\n  def test_check_volume_notification(self):\n      ...\n\nIs something of that ilk what you envisaged above?\n\n> However, it does raise the question of being an end user how am I\n> expected to know which notifications get counted? Which is why having\n> the feature discoverability is generally a really good idea.\n\nSo certain things we could potentially make discoverable through the\nceilometer capabilities API. But there\'s a limit to how fine-grained\nwe can make that. Also it was primarily intended to surface lack of\nfeature-parity in the storage driver layer (e.g. one driver supports\nsdtdev, but another doesn\'t) as opposed to the notification-handling\nlayer.\n \n> > One approach mooted for allowing these kind of scenarios to be tested\n> > was to split off the pure-API aspects of Tempest so that it can be used\n> > for probing public-cloud-capabilities as well as upstream CI, and then\n> > build project-specific mini-Tempests to test integration with other\n> > projects.\n> > \n> > Personally, I\'m not a fan of that approach as it would require a lot\n> > of QA expertise in each project, lead to inefficient use of CI\n> > nodepool resources to run all the mini-Tempests, and probably lead to\n> > a divergent hotchpotch of per-project approaches.\n> \n> I think the proposal here was for people interested in doing\n> whitebox testing, where there is a desire to test an internal\n> project mechanism. I could see the argument for testing\n> notifications this way, but that would have to be for every project\n> individually. There are already several projects that have\n> functional testing like this in tree and run them as a gating\n> job. There are definitely certain classes of testing where doing\n> this makes sense.\n\nI\'m not sure that this would be realistic to test individually (if by\nthat you meant just with the ceilometer agents running alone) as it\ndepends on a notification emitted from cinder. \n\n> > Another idea would be to keep all tests in Tempest, while also\n> > micro-versioning the services such that tests can be skipped on the\n> > basis of whether a particular feature-adding commit is present.\n> > \n> > When this micro-versioning can\'t be discovered by the test (as in the\n> > public cloud capabilities probing case), those tests would be skipped\n> > anyway.\n> \n> Yeah, I\'m not a fan of this approach at all. It is just a bad way of\n> reimplementing a temporally-aware tempest. But, instead of using\n> branches we have arbitrary service versions. It sacrifices all the\n> real advantages of having branchless tempest, but adds more\n> complexity around the version discovery to all the projects and\n> tempest. If we want to revert back to a temporally aware tempest,\n> which I don\'t think we should, then going back the branched model is\n> what we should do.\n\nFair point about it giving us the worst of both worlds. Yeap, scratch\nthat suggestion.\n\n> > The final, less palatable, approach that occurs to me would be to\n> > revert to branchful Tempest.\n> \n> So I don\'t think we\'re anywhere near this.\n\nAgreed.\n\n> I think what we\'re\n> hitting here is more a matter of projects trying to map out exactly\n> how to test things for real in the gate with tempest. While at the\n> same time coming to understand that things don\'t quite work as well\n> as we expected. I think that we have to remember that this is the\n> first cycle with branchless tempest it\'s still new for everyone and\n> what we\'re hitting here are just some of the growing pains around\n> it.  Having discussions like this and mapping out the requirements\n> more completely is th\n\nYep, we\'re all learning and beginning to see the for-real implications\nof branchless Tempest.\n\n> I recognize that for projects that didn\'t have any real testing\n> before we started branchless tempest it\'s harder to get things going\n> with it.  Especially because in my experience the adage \"if it isn\'t\n> tested it\'s broken\" tends to hold true. So I expect there will be a\n> lot of non-backportable fixes just to enable testing. What this\n> friction with branchless tempest is showing us is that these fixes,\n> besides fixing the bug, will also have implications for people using\n> OpenStack clouds. Which I feel is invaluable information to collect,\n> and definitely something we should gate on. The open question is how\n> do we make it easier the to enable testing for new things.\n\nYes, ceilometer unfortunately falls somewhat into that category of not\nhaving much pre-existing Tempest coverage. We had a lot of Tempest tests\nproposed during Icehouse, but much of it stalled around performance\nissues in our sql-alchemy driver.\n\nThanks in any case for the feedback.\n\nCheers,\nEoghan\n\n\n','<20140709124623.GA958@Sazabi.treinish>',NULL),('<1760206930.23885402.1371007583964.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-11 23:26:23',-14400,'2013-06-12 03:26:23',NULL,'[openstack-qa] Why Tool Chain bahalof on user abstraction','The Unified CLI provides similar abstraction:\nhttps://wiki.openstack.org/wiki/UnifiedCLI/Mapping\nhttps://wiki.openstack.org/wiki/UnifiedCommandLineClient\n\nThis concept is good enough for most test types, this model allow as to\n manage more things in similar way regardless we are using library or API or CLI backed, or ..\n\nIt is simple.\n\nIt can use the token efficiently.\n\nThe \"clients\", \"manager\", \"os\", \"os_adm\", \"openstack\" , is close to this concept, but it does not used\nconsistently anywhere.\n\nThis concept can be extended to be role based model in a simple way.\n\n\n','<80489014.23883262.1371006697001.JavaMail.root@redhat.com>',NULL),('<1760535948.124.1384668742867.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-17 06:12:22',0,'2013-11-17 06:12:22',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python27-stable-grizzly #47','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/47/>\n\n\n\n','<153664223.121.1384582500274.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1760756148.17546023.1383330144137.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-01 14:22:24',-14400,'2013-11-01 18:22:24',NULL,'[openstack-dev] [Solum] Some initial code copying for\n db/migration','\n----- Original Message -----\n> I think there is a summit topic about what to do about a good \'oslo.db\'\n> (not sure if it got scheduled?)\n\nWill look.\n\n> \n> I\'d always recommend reconsidering just copying what nova/cinder and a few\n> others have for there db structure.\n> \n> I don\'t think that has turned out so well in the long term (a 6000+ line\n> file is not so good).\n> \n> As for a structure that might be better, in taskflow I followed more of\n> how ceilometer does there db api. It might work for u.\n> \n> - https://github.com/openstack/ceilometer/tree/master/ceilometer/storage\n> -\n\nThe Connection / Model object paradigm in Ceilometer was what I was assuming was \"recommended\" and was where mentially I was starting (it\'s similar but not identical to trove, ironic, and heat).  The ceilometer model is what I would describe as a resource manager class (Connection) that hides implementation (by mapping Sqlalchemy to the Model* objects).  So storage/base.py | storage/models.py define a rough domain model.  Russell, is that what you\'re advocating against (because of the size of the eventual resource manager class)?\n\nHere\'s a couple of concrete storage interaction patterns\n\n  simple application/component/sensor persistence with clean validation back to REST consumers\n    traditional crud, probably 3-8 resources over time will follow this pattern\n    best done via object model type interactions and then a direct persist operation\n\n  elaborate a plan description for the application (yaml/json/etc) into the object model\n    will need to retrieve specific sets of info from the object model\n    typically one way\n    may potentially involve asynchronous operations spawned from the initial request to retrieve more information\n\n  translate the plan/object model into a HEAT template\n    will need to retrieve specific sets of info from the object model\n    typically one way\n\n  create/update a HEAT stack based on changes\n    likely will set the stack id into the object model\n    might return within milliseconds or seconds\n\n  provision source code repositories\n    might return within milliseconds or minutes\n\n  provision DNS\n    this can take from within milliseconds to seconds, and DNS is likely only visible to an API consumer after minutes.\n\n  trigger build flows\n    this may take milliseconds to initiate, but minutes to complete\n\nThe more complex operations are likely separate pluggable service implementations (read: abstracted) that want to call back into the object model in a simple way, possibly via methods exposed specifically for those use cases.\n\nI *suspect* that Solum will never have the complexity Nova does in persistence model, but that we\'ll end up with at around 20 tables in the first 2 years.  I would expect API surface area to be slightly larger than some projects, but not equivalent to keystone/nova by any means.\n\n> https://github.com/stackforge/taskflow/tree/master/taskflow/persistence/bac\n> kends\n> \n> I also have examples of alembic usage in taskflow, since I also didn\'t\n> want to use sqlalchemy-migrate for the same reasons russell mentioned.\n> \n> -\n> https://github.com/stackforge/taskflow/tree/master/taskflow/persistence/bac\n> kends/sqlalchemy\n> \n> Feel free to bug me about questions.\n\nThanks\n\n\n','<CE993115.4B858%harlowja@yahoo-inc.com>',NULL),('<1761673152.64088.1403169636043.JavaMail.hzwangpan@corp.netease.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-19 17:20:29',28800,'2014-06-19 09:20:29',NULL,'[Openstack] [Nova] get-vnc-console command do not work','Hi chenli,\nYou can get some information from this page:\nhttp://docs.openstack.org/admin-guide-cloud/content/getting-started-with-vnc-proxy.html\n\n\n2014-06-19 17:18 (UTC+8)\nWangpan\n\n----- Original Message -----\n> From: \"Li, Chen\" <chen.li at intel.com>\n> To: \"Jitendra Bhaskar\"<jeetuindian at gmail.com>\n> Sent: 2014-06-19 16:58\n> Subject: Re: [Openstack] [Nova] get-vnc-console command do not work\nHi Jitendra,\n\nIt can work now.\nThanks a lot!!! J\n\n\nCompare the configuration you suggested and my old, \nI have configured compute node correctly.\nBut on api node:\nI missed \nvncserver_listen = 0.0.0.0\nnovnc_enabled=true\nAnd miss configured \nvncserver_proxyclient_address = 0.0.0.0  => api_node_ip\n\n\nCould  you explain a little how these three configuration works ???\nWould be really helpful to prevent me to make same mistake next time. \n\nFrom: Jitendra Bhaskar [mailto:jeetuindian at gmail.com] \nSent: Thursday, June 19, 2014 4:42 PM\nTo: Li, Chen\nCc: <openstack at lists.openstack.org>\nSubject: Re: [Openstack] [Nova] get-vnc-console command do not work\n\nHi Li,\nOn api node please use the config on nova.conf\n\nvncserver_listen = 0.0.0.0\nvncserver_proxyclient_address = 0.0.0.0 \nnovncproxy_port=6080\nnovnc_enabled=true\nnovncproxy_base_url=http://public_ip_of_controller:6080/vnc_auto.html\nOn compute node update nova.conf as :\n\nvnc_enabled = True\nvncserver_listen = 0.0.0.0\nvncserver_proxyclient_address = compute_ip_address\nnovncproxy_base_url = http://public_ip_of_controller:6080/vnc_auto.html\n\n\nOn Thu, Jun 19, 2014 at 1:48 PM, Li, Chen <chen.li at intel.com> wrote:\nHi list,\n\nI?m working under CentOS with icehouse.\n\nI?m trying to enable VNC console for instances.\n\nWhile my api node has 2 physical NICs, one with IP 172.16.24.2, another one with IP 192.168.40.121.\nThe compute node has only one NIC with IP 192.168.40.127.\n\nI configured nova.conf on api node with:\nnovncproxy_base_url=http://172.16.24.2:6080/vnc_auto.html\nvncserver_proxyclient_address=192.168.40.121\nvnc_enabled=true\n\nnova.conf on compute node with:\nnovncproxy_base_url=http://172.16.24.2:6080/vnc_auto.html\nvncserver_listen=0.0.0.0\nvncserver_proxyclient_address=192.168.40.127\nvnc_enabled=true\nAlso I start services openstack-nova-novncproxy & openstack-nova-cert & openstack-nova-consoleauth on api node too.\nThen I try to run command ?nova ?debug get-vnc-console my_instances novnc?\nI get error:\n??\nINFO (connectionpool:203) Starting new HTTP connection (1): 172.16.24.2\nDEBUG (connectionpool:295) \"POST /v2/2eb6bd3a69ad454a90489dd12b9cdf3b/servers/f5155a67-3584-4a8a-a3a2-dced6b8e735a/action HTTP/1.1\" 500 128\nRESP: [500] {\'date\': \'Thu, 19 Jun 2014 00:03:39 GMT\', \'content-length\': \'128\', \'content-type\': \'application/json; charset=UTF-8\', \'x-compute-request-id\': \'req-d9a77e15-e8cf-436a-a895-e798d7908e66\'}\nRESP BODY: {\"computeFault\": {\"message\": \"The server has either erred or is incapable of performing the requested operation.\", \"code\": 500}}\n\nDEBUG (shell:783) The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d9a77e15-e8cf-436a-a895-e798d7908e66)\nTraceback (most recent call last):\n  File \"/usr/lib/python2.6/site-packages/novaclient/shell.py\", line 780, in main\n    OpenStackComputeShell().main(map(strutils.safe_decode, sys.argv[1:]))\n  File \"/usr/lib/python2.6/site-packages/novaclient/shell.py\", line 716, in main\n    args.func(self.cs, args)\n  File \"/usr/lib/python2.6/site-packages/novaclient/v1_1/shell.py\", line 1870, in do_get_vnc_console\n    data = server.get_vnc_console(args.console_type)\n  File \"/usr/lib/python2.6/site-packages/novaclient/v1_1/servers.py\", line 69, in get_vnc_console\n    return self.manager.get_vnc_console(self, console_type)\n  File \"/usr/lib/python2.6/site-packages/novaclient/v1_1/servers.py\", line 642, in get_vnc_console\n    {\'type\': console_type})[1]\n  File \"/usr/lib/python2.6/site-packages/novaclient/v1_1/servers.py\", line 1179, in _action\n    return self.api.client.post(url, body=body)\n  File \"/usr/lib/python2.6/site-packages/novaclient/client.py\", line 312, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n  File \"/usr/lib/python2.6/site-packages/novaclient/client.py\", line 286, in _cs_request\n    **kwargs)\n  File \"/usr/lib/python2.6/site-packages/novaclient/client.py\", line 268, in _time_request\n    resp, body = self.request(url, method, **kwargs)\n  File \"/usr/lib/python2.6/site-packages/novaclient/client.py\", line 262, in request\n    raise exceptions.from_response(resp, body, url, method)\nClientException: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d9a77e15-e8cf-436a-a895-e798d7908e66)\nERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d9a77e15-e8cf-436a-a895-e798d7908e66)\n\n\nAlso error message in api.log:\n\n2014-06-19 08:03:19.776 3171 ERROR nova.api.openstack [req-5aeda2f2-0785-4c2a-8d87-8851c2e9ffb7 fa970646fa92442fa14b2b759cf381a6 2eb6bd3a69ad454a90489dd12b9cdf3b] Caught error: Timed out waiting for a reply to message ID b5eecf56a54b492ca8ed1e6db30f5b96\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack Traceback (most recent call last):\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/api/openstack/__init__.py\", line 125, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return req.get_response(self.application)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/request.py\", line 1296, in send\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     application, catch_exc_info=False)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/request.py\", line 1260, in call_application\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     app_iter = application(self.environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 144, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return resp(environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py\", line 615, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return self.app(env, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 144, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return resp(environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 144, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return resp(environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/routes/middleware.py\", line 131, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     response = self.app(environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 144, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return resp(environ, start_response)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 130, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     resp = self.call_func(req, *args, **self.kwargs)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/webob/dec.py\", line 195, in call_func\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return self.func(req, *args, **kwargs)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py\", line 917, in __call__\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     content_type, body, accept)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py\", line 983, in _process_stack\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     action_result = self.dispatch(meth, request, action_args)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/api/openstack/wsgi.py\", line 1070, in dispatch\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return method(req=request, **action_args)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/api/openstack/compute/contrib/consoles.py\", line 45, in get_vnc_console\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     console_type)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/compute/api.py\", line 201, in wrapped\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return func(self, context, target, *args, **kwargs)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/compute/api.py\", line 182, in wrapped\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return function(self, context, instance, *args, **kwargs)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/compute/api.py\", line 2640, in get_vnc_console\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     connect_info[\'internal_access_path\'], instance[\'uuid\'])\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/nova/consoleauth/rpcapi.py\", line 74, in authorize_console\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     instance_uuid=instance_uuid)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/rpc/client.py\", line 150, in call\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     wait_for_reply=True, timeout=timeout)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/transport.py\", line 90, in _send\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     timeout=timeout)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 412, in send\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     return self._send(target, ctxt, message, wait_for_reply, timeout)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 403, in _send\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     result = self._waiter.wait(msg_id, timeout)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 267, in wait\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     reply, ending = self._poll_connection(msg_id, timeout)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack   File \"/usr/lib/python2.6/site-packages/oslo/messaging/_drivers/amqpdriver.py\", line 217, in _poll_connection\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack     % msg_id)\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack MessagingTimeout: Timed out waiting for a reply to message ID b5eecf56a54b492ca8ed1e6db30f5b96\n2014-06-19 08:03:19.776 3171 TRACE nova.api.openstack\n\n\n\nAnyone know why this happens ???\n\nThanks.\n-chen\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n\n-- \n Thanks & Regards   \nJitendra Kumar Bhaskar\nCell:- +91 7306311531\n      :- +91 9989743042\n         \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140619/7527641e/attachment.html>\n\n','<988E98D31B01E44893AF6E48ED9DEFD401B3E2A1@SHSMSX101.ccr.corp.intel.com>',NULL),('<1761797689.74.1373609273268.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-12 06:07:53',0,'2013-07-12 06:07:53',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #284','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/284/>\n\n------------------------------------------\n[...truncated 8993 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 204, in test_workflow_finalization\n    self.assertTrue(flow.finalize())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 747, in finalize\n    exceptions.handle(self.request)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 0.90 secs:\n    0.38    RoleAPITests.test_get_default_role\n    0.15    HorizonTests.test_index_url_name\n    0.14    DataTableTests.test_summation_row\n    0.12    DataTableTests.test_table_action_attributes\n    0.11    NetworkTests.test_subnet_create_post\n----------------------------------------------------------------------\nRan 350 tests in 4.892s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.kJJt89o0eE\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/284\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/284/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/284/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<336408363.63.1373522985203.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1762552715.25679530.1393901068921.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-03 21:44:28',-18000,'2014-03-04 02:44:28',NULL,'[Openstack] [nova] opportunistic and energy efficient cloud','----- Original Message -----\n> Hi everyone,\n> \n> I\'m currently taking part of a project at the Federal University of Campina\n> Grande called fogbow, which aims on providing an energy efficient scheduler\n> and an opportunistic compute node (which deactivates the service if the\n> host isn\'t idle) on top of openstack.\n\nHi Marcos,\n\nThis sounds like an interesting idea - have you had a look at the way this functionality is implemented in the oVirt (http://ovirt.org) scheduler [1] in case there are any ideas there that could be leveraged? I believe the determination there is also made by examining pCPU load (albeit with some additional computations applied) though it does not use powernap.\n\n> Regarding the opportunistic aspect of the project, we\'re planning on using\n> powernap (http://manpages.ubuntu.com/manpages/lucid/man8/powernap.8.html)\n> to tell if the host is idle or not.\n> \n> Finally, my question is: what do you guys think would be the best way for a\n> powernap action script to interact with nova-compute in order to stop all\n> running instances and disable the host?\n\nIf I understand correctly your suggestion here is that the powernap action script would run when powernapd on the host has determined it to be at low CPU usage at which point it would stop the instances and disable/poweroff the host, rather than having one of the other nova components monitor the load and initiate the required action?\n\n> Would killing and respawning the nova-compute be an elegant way of doing\n> that in your opinion? Or do RPC calls sound better?\n\nIs the desire necessarily to *stop* all instances, or evacuate/migrate them to another host so that you can consolidate instances on a subset of your compute hosts and either power the remainder down and/or disable the compute service on them? Another consideration here might be how much available pCPU you want to keep as a buffer in case of a burst in instance activity (probably something to make configurable?)?\n\nThanks,\n\nSteve\n\n[1] http://www.ovirt.org/Features/oVirtSchedulerAPI#Balance\n\n\n','<CACgJQSkGsnTWc1eKZBsOf7-Vdfp=Mm4DSFtBTTy4HMcGPLhqwA@mail.gmail.com>',NULL),('<1762b8a091234fcba94e2cbfa5095039@CO2PR05MB732.namprd05.prod.outlook.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-01-13 22:22:31',0,'2014-01-13 22:22:31',NULL,'[Openstack] [Horizon and Nova] Inclusion of exception message\n to UI	error','The reason the architecture is the way it is in Horizon right now is because historically most projects have sent messages that are either raw tracebacks (not appropriate for a popup error display at all), extremely detailed/technical reports containing multiple resource IDs that are not human-parseable, or otherwise unhelpful error strings.\n\nBasically, until there is a concerted effort on the part of each and every service to be better about returning human-parseable error messages from the APIs, the default should be to show a generic error message unless we know that the API is trusted to return appropriate responses. Opt-in, not opt-out.\n\nThere are basically two ways to proceed right now: invest a ton of work-hours in Horizon figuring out a good message for each poor response returned from each API call, or invest a ton of work-hours in the projects themselves to improve the error responses for human consumption.\n\nAs a third option that does not ultimately reduce the need for the work described above, you could display the generic message and have an option attached to the generic message that says \"See the raw API response (advanced)\" or something like that which would pop up a window that had the actual error response from the API. This would probably need to be configurable in the settings since many deployers still wouldn\'t want regular users exposed to some of the information that\'s returned in those error responses.\n\nPersonally I favor investing the energy in improving the responses sent back from the APIs. It\'d go a long way towards improving the global user experience of OpenStack.\n\n     - Gabriel\n\n> -----Original Message-----\n> From: Musso, Veronica A [mailto:veronica.a.musso at intel.com]\n> Sent: Monday, January 13, 2014 12:54 PM\n> To: openstack at lists.openstack.org\n> Cc: Musso, Veronica A\n> Subject: [Openstack] [Horizon and Nova] Inclusion of exception message to\n> UI error\n> \n> Hi!\n> \n> Due this bug: https://bugs.launchpad.net/horizon/+bug/1210540 and its fix\n> proposal: https://review.openstack.org/#/c/62026, I would like to discuss the\n> inclusion of Nova\'s exception messages in the Horizon\'s dashboard.\n> nova/compute/api.py functions throws exceptions with a translatable\n> messages, and they are caught by  \"handle\" function in\n> horizon/tables/actions.py. This function ignores the exception message and\n> displays a general one.\n> The idea is to modify \"handle\" function to show the exception messages to\n> the users. The advantage is to have a better idea of the failure reason\n> without reviewing logs, helping the end users with the troubleshooting. On\n> the other hand, the disadvantage is it may lead to information disclosure or\n> not translatable messages (if functions sending the exception do not\n> translate the messages).\n> \n> Then, what is the best approach to resolved the bug?\n> \n> Thanks!\n> \n> Best Regards,\n> Ver?nica Musso\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<3E86006CD7DCE241B8C56ACA85F0B39A586D93F9@ORSMSX110.amr.corp.intel.com>',NULL),('<1763BED4-A110-4F1D-9D43-34E290F00231@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-18 17:49:06',-25200,'2013-08-19 00:49:06',NULL,'[openstack-dev] All TripleO repositories are now in the\n	openstack/ namespace!','On Aug 18, 2013, at 4:32 PM, Robert Collins <robertc at robertcollins.net> wrote:\n\n> Thanks to -infra folk over this weekend, we\'re now in the openstack/\n> namespace for gerrit, git etc.\n> \n> Anyone consuming these from git - such as trove - will need to update\n> to pull from the new repository, or you\'ll get stale code.\n\nThx for the info. Duly noted. \n\n> \n> We\'ll give it a week or so and then delete the old repositories from\n> github etc to avoid confusion - please update before then to avoid\n> errors when we remove them.\n> \n> Code review bookmarks will need updating immediately however.\n> \n> Thanks!\n> Rob\n> \n> -- \n> Robert Collins <rbtcollins at hp.com>\n> Distinguished Technologist\n> HP Converged Cloud\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAJ3HoZ08CM8MWAzfcbNmF3-fLh=UypsfcFD1FMe7sbpJTGgmCg@mail.gmail.com>',NULL),('<1764246812.38.1382422468330.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-22 06:14:27',0,'2013-10-22 06:14:27',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #37','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 1486 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5bcbf90>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x56b8a10>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x56b8a10>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-c449bf8f-c5c6-4789-958e-400cc977dc9d\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x363c9b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x363c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x363c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x363c9b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-21T06:13:11Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'11\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'21\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'21\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-23T06:13:11Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'11\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'23\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'23\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:13:11+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'11\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:13:11-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'11\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:13:11Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'11\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6900f90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x22f8b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 91.97 secs:\n    26.54    TestScrubber.test_scrubber_app\n    20.88    TestScrubber.test_delayed_delete\n    14.97    TestRootApi.test_version_configurations\n    14.94    TestGlanceControl.test_reload\n    14.63    TestGlanceControl.test_respawn\n----------------------------------------------------------------------\nRan 1109 tests in 652.381s\n\nFAILED (SKIP=42, errors=1, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.37\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.7\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=124\n+ \'[\' 124 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.KdvmRfxIA3\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/37/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-10/37\n[SCP] Copying console log.\n\n\n','<754340992.37.1382249556828.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1764418249.5.1382596265373.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-10-24 06:31:05',0,'2013-10-24 06:31:05',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-all #40','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-all/40/>\n\n------------------------------------------\n[...truncated 18254 lines...]\n2013-10-24 06:07:46 catalog_type = object-store\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # The name of a region for object storage. If empty or commented-out, the\n2013-10-24 06:07:46 # value of identity.region is used instead. If no such region is found in\n2013-10-24 06:07:46 # the service catalog, the first found one is used.\n2013-10-24 06:07:46 #region = RegionOne\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # Number of seconds to time on waiting for a container to container\n2013-10-24 06:07:46 # synchronization complete\n2013-10-24 06:07:46 container_sync_timeout = 120\n2013-10-24 06:07:46 # Number of seconds to wait while looping to check the status of a\n2013-10-24 06:07:46 # container to container synchronization\n2013-10-24 06:07:46 container_sync_interval = 5\n2013-10-24 06:07:46 # Set to True if the Account Quota middleware is enabled\n2013-10-24 06:07:46 accounts_quotas_available = True\n2013-10-24 06:07:46 # Set to True if the Container Quota middleware is enabled\n2013-10-24 06:07:46 container_quotas_available = True\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # Set operator role for tests that require creating a container\n2013-10-24 06:07:46 operator_role = Member\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 [boto]\n2013-10-24 06:07:46 ssh_user = cirros\n2013-10-24 06:07:46 # This section contains configuration options used when executing tests\n2013-10-24 06:07:46 # with boto.\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # EC2 URL\n2013-10-24 06:07:46 ec2_url = http://127.0.0.1:8773/services/Cloud\n2013-10-24 06:07:46 # S3 URL\n2013-10-24 06:07:46 s3_url = http://127.0.0.1:3333\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # Use keystone ec2-* command to get those values for your test user and tenant\n2013-10-24 06:07:46 aws_access =\n2013-10-24 06:07:46 aws_secret =\n2013-10-24 06:07:46 \n2013-10-24 06:07:46 # Image materials for S3 upload\n2013-10-24 06:07:46 # ALL content of the specified directory will be uploaded to S3\n2013-10-24 06:07:46 s3_materials_path = /opt/stack/new/devstack/files/images/s3-materials/cirros-0.3.1\n2013-10-24 06:07:46 \n2013-10-24 06:07:47 # The manifest.xml files, must be in the s3_materials_path directory\n2013-10-24 06:07:47 # Subdirectories not allowed!\n2013-10-24 06:07:47 # The filenames will be used as a Keys in the S3 Buckets\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # ARI Ramdisk manifest. Must be in the above s3_materials_path\n2013-10-24 06:07:47 ari_manifest = cirros-0.3.1-x86_64-initrd.manifest.xml\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # AMI Machine Image manifest. Must be in the above s3_materials_path\n2013-10-24 06:07:47 ami_manifest = cirros-0.3.1-x86_64-blank.img.manifest.xml\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # AKI Kernel Image manifest, Must be in the above s3_materials_path\n2013-10-24 06:07:47 aki_manifest = cirros-0.3.1-x86_64-vmlinuz.manifest.xml\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Instance type\n2013-10-24 06:07:47 instance_type = m1.nano\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # TCP/IP connection timeout\n2013-10-24 06:07:47 http_socket_timeout = 30\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Number of retries actions on connection or 5xx error\n2013-10-24 06:07:47 num_retries = 1\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Status change wait timout\n2013-10-24 06:07:47 build_timeout = 400\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Status change wait interval\n2013-10-24 06:07:47 build_interval = 1\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 [orchestration]\n2013-10-24 06:07:47 # The type of endpoint for an Orchestration API service. Unless you have a\n2013-10-24 06:07:47 # custom Keystone service catalog implementation, you probably want to leave\n2013-10-24 06:07:47 # this value as \"orchestration\"\n2013-10-24 06:07:47 catalog_type = orchestration\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # The name of a region for orchestration. If empty or commented-out, the value\n2013-10-24 06:07:47 # of identity.region is used instead. If no such region is found in the service\n2013-10-24 06:07:47 # catalog, the first found one is used.\n2013-10-24 06:07:47 #region = RegionOne\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Status change wait interval\n2013-10-24 06:07:47 build_interval = 1\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Status change wait timout. This may vary across environments as some some\n2013-10-24 06:07:47 # tests spawn full VMs, which could be slow if the test is already in a VM.\n2013-10-24 06:07:47 build_timeout = 300\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Instance type for tests. Needs to be big enough for a\n2013-10-24 06:07:47 # full OS plus the test workload\n2013-10-24 06:07:47 instance_type = m1.micro\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Name of heat-cfntools enabled image to use when launching test instances\n2013-10-24 06:07:47 # If not specified, tests that spawn instances will not run\n2013-10-24 06:07:47 #image_ref = ubuntu-vm-heat-cfntools\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # Name of existing keypair to launch servers with. The default is not to specify\n2013-10-24 06:07:47 # any key, which will generate a keypair for each test class\n2013-10-24 06:07:47 #keypair_name = heat_key\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 [dashboard]\n2013-10-24 06:07:47 # URL where to find the dashboard home page\n2013-10-24 06:07:47 dashboard_url = http://127.0.0.1/\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # URL where to submit the login form\n2013-10-24 06:07:47 login_url = http://127.0.0.1/auth/login/\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 [scenario]\n2013-10-24 06:07:47 # Directory containing image files\n2013-10-24 06:07:47 img_dir = /opt/stack/new/devstack/files/images/cirros-0.3.1-x86_64-uec\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # AMI image file name\n2013-10-24 06:07:47 ami_img_file = cirros-0.3.1-x86_64-blank.img\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # ARI image file name\n2013-10-24 06:07:47 ari_img_file = cirros-0.3.1-x86_64-initrd\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # AKI image file name\n2013-10-24 06:07:47 aki_img_file = cirros-0.3.1-x86_64-vmlinuz\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # ssh username for the image file\n2013-10-24 06:07:47 ssh_user = cirros\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 # specifies how many resources to request at once. Used for large operations\n2013-10-24 06:07:47 # testing.\"\n2013-10-24 06:07:47 large_ops_number = 0\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 [cli]\n2013-10-24 06:07:47 # Enable cli tests\n2013-10-24 06:07:47 enabled = True\n2013-10-24 06:07:47 # directory where python client binaries are located\n2013-10-24 06:07:47 cli_dir = /usr/local/bin\n2013-10-24 06:07:47 # Number of seconds to wait on a CLI timeout\n2013-10-24 06:07:47 timeout = 15\n2013-10-24 06:07:47 \n2013-10-24 06:07:47 [service_available]\n2013-10-24 06:07:47 # Whether or not cinder is expected to be available\n2013-10-24 06:07:47 cinder = True\nall develop-inst: /opt/stack/new/tempest\nall runtests: commands[0] | python setup.py testr --slowest --testr-args=\nrunning testr\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest --list \nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpOaQBMM\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpxfp80H\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmpGp4Ead\nrunning=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \\\nOS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \\\nOS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-500} \\\n${PYTHON:-python} -m subunit.run discover -t ./ ./tempest  --load-list /tmp/tmp7pvvpG\n======================================================================\nFAIL: unittest.loader.ModuleImportFailure.tempest.api.compute.admin.test_hypervisor_negative\ntags: worker-2\n----------------------------------------------------------------------\nImportError: Failed to import test module: tempest.api.compute.admin.test_hypervisor_negative\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 252, in _find_tests\n    module = self._get_module_from_name(name)\n  File \"/usr/lib/python2.7/unittest/loader.py\", line 230, in _get_module_from_name\n    __import__(name)\n  File \"tempest/api/compute/admin/test_hypervisor_negative.py\", line 26, in <module>\n    class HypervisorAdminNegativeTestJSON(base.BaseComputeAdminTest):\nAttributeError: \'module\' object has no attribute \'BaseComputeAdminTest\'\n======================================================================\nFAIL: process-returncode\ntags: worker-2\n----------------------------------------------------------------------\nBinary content:\n  traceback (test/plain; charset=\"utf8\")\nRan 2819 tests in 1312.096s\nFAILED (id=0, failures=2, skips=76)\nerror: testr failed (1)\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/all/bin/python setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   all: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-603669-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-603669.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-alarm-evaluator.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-alarm-notifier.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-all/devstack-precise-hpcloud-az3-603669/40/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<17648161.224.1368252629158.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:10:28',0,'2013-05-11 06:10:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-cinder-stable-folsom #222','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-cinder-stable-folsom/222/>\n\n------------------------------------------\n[...truncated 12603 lines...]\n    s,%FLAVOR_REF%,1,g;\n    s,%FLAVOR_REF_ALT%,2,g;\n    s,%COMPUTE_CONFIG_PATH%,/etc/nova/nova.conf,g;\n    s,%COMPUTE_SOURCE_DIR%,/opt/stack/new/nova,g;\n    s,%COMPUTE_BIN_DIR%,/usr/bin/nova,g;\n    s,%COMPUTE_PATH_TO_PRIVATE_KEY%,/opt/stack/new/tempest/id_rsa,g;\n    s,%COMPUTE_DB_URI%,mysql://root:secret at localhost/nova,g;\n    s,%IMAGE_HOST%,127.0.0.1,g;\n    s,%IMAGE_PORT%,9292,g;\n    s,%IMAGE_API_VERSION%,1,g;\n    s,%IMAGE_CATALOG_TYPE%,image,g;\n    s,%COMPUTE_ADMIN_USERNAME%,admin,g;\n    s,%COMPUTE_ADMIN_PASSWORD%,secret,g;\n    s,%COMPUTE_ADMIN_TENANT_NAME%,admin,g;\n    s,%IDENTITY_ADMIN_USERNAME%,admin,g;\n    s,%IDENTITY_ADMIN_PASSWORD%,secret,g;\n    s,%IDENTITY_ADMIN_TENANT_NAME%,admin,g;\n    s,%NETWORK_CATALOG_TYPE%,network,g;\n    s,%NETWORK_API_VERSION%,2.0,g;\n    s,%VOLUME_CATALOG_TYPE%,volume,g;\n    s,%VOLUME_BUILD_INTERVAL%,3,g;\n    s,%VOLUME_BUILD_TIMEOUT%,300,g;\n\' -i /opt/stack/new/tempest/etc/tempest.conf\n+ echo \'Created tempest configuration file:\'\nCreated tempest configuration file:\n+ cat /opt/stack/new/tempest/etc/tempest.conf\n[identity]\n# This section contains configuration options that a variety of Tempest\n# test clients use when authenticating with different user/tenant\n# combinations\n\n# Set to True if your test environment\'s Keystone authentication service should\n# be accessed over HTTPS\nuse_ssl = False\n# This is the main host address of the authentication service API\nhost = 127.0.0.1\n# Port that the authentication service API is running on\nport = 5000\n# Version of the authentication service API (a string)\napi_version = v2.0\n# Path to the authentication service tokens resource (do not modify unless you\n# have a custom authentication API and are not using Keystone)\npath = tokens\n# Should typically be left as keystone unless you have a non-Keystone\n# authentication API service\nstrategy = keystone\n\n[compute]\n# This section contains configuration options used when executing tests\n# against the OpenStack Compute API.\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_isolation = True\n\n# Allows test cases to create/destroy tenants and users. This option\n# enables isolated test cases and better parallel execution,\n# but also requires that OpenStack Identity API admin credentials\n# are known.\nallow_tenant_reuse = True\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n# This should be the username of an alternate user WITHOUT\n# administrative privileges\nalt_username = alt_demo\n# The above non-administrative user\'s password\nalt_password = secret\n# The above non-administrative user\'s tenant name\nalt_tenant_name = alt_demo\n\n# Reference data for tests. The ref and ref_alt should be\n# distinct images/flavors.\nimage_ref = befcc2b9-f737-465d-bdb2-594660a340e0\nimage_ref_alt = befcc2b9-f737-465d-bdb2-594660a340e0\nflavor_ref = 1\nflavor_ref_alt = 2\n\n# Number of seconds to wait while looping to check the status of an\n# instance that is building.\nbuild_interval = 3\n\n# Number of seconds to time out on waiting for an instance\n# to build or reach an expected status\nbuild_timeout = 400\n\n# The type of endpoint for a Compute API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"compute\"\ncatalog_type = compute\n\n# Does the Compute API support creation of images?\ncreate_image_enabled = True\n\n# For resize to work with libvirt/kvm, one of the following must be true:\n# Single node: allow_resize_to_same_host=True must be set in nova.conf\n# Cluster: the \'nova\' user must have scp access between cluster nodes\nresize_available = False\n\n# Does the compute API support changing the admin password?\nchange_password_available = False\n\n# Level to log Compute API request/response details.\nlog_level = ERROR\n\n# Whitebox options for compute. Whitebox options enable the\n# whitebox test cases, which look at internal Nova database state,\n# SSH into VMs to check instance state, etc.\n\n# Should we run whitebox tests for Compute?\nwhitebox_enabled = True\n\n# Path of nova source directory\nsource_dir = /opt/stack/new/nova\n\n# Path of nova configuration file\nconfig_path = /etc/nova/nova.conf\n\n# Directory containing nova binaries such as nova-manage\nbin_dir = /usr/bin/nova\n\n# Path to a private key file for SSH access to remote hosts\npath_to_private_key = /opt/stack/new/tempest/id_rsa\n\n# Connection string to the database of Compute service\ndb_uri = mysql://root:secret at localhost/nova\n\n[image]\n# This section contains configuration options used when executing tests\n# against the OpenStack Images API\n\n# The type of endpoint for an Image API service. Unless you have a\n# custom Keystone service catalog implementation, you probably want to leave\n# this value as \"image\"\ncatalog_type = image\n\n# The version of the OpenStack Images API to use\napi_version = 1\n\n# This is the main host address of the Image API\nhost = 127.0.0.1\n\n# Port that the Image API is running on\nport = 9292\n\n# This should be the username of a user WITHOUT administrative privileges\nusername = demo\n# The above non-administrative user\'s password\npassword = secret\n# The above non-administrative user\'s tenant name\ntenant_name = demo\n\n[compute-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[identity-admin]\n# This section contains configuration options for an administrative\n# user of the Compute API. These options are used in tests that stress\n# the admin-only parts of the Compute API\n\n# This should be the username of a user WITH administrative privileges\nusername = admin\n# The above administrative user\'s password\npassword = secret\n# The above administrative user\'s tenant name\ntenant_name = admin\n\n[volume]\n# This section contains the configuration options used when executing tests\n# against the OpenStack Block Storage API service\n\n# The type of endpoint for a Cinder or Block Storage API service.\n# Unless you have a custom Keystone service catalog implementation, you\n# probably want to leave this value as \"volume\"\ncatalog_type = volume\n# Number of seconds to wait while looping to check the status of a\n# volume that is being made available\nbuild_interval = 3\n# Number of seconds to time out on waiting for a volume\n# to be available or reach an expected status\nbuild_timeout = 300\n+ echo \'\\n\'\n\\n\n+ echo \'**************************************************\'\n**************************************************\n+ echo \'Finished Configuring Tempest\'\nFinished Configuring Tempest\n+ echo \'**************************************************\'\n**************************************************\nRunning tempest smoke tests\nERROR: unknown environment \'smoke\'\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/mysql/error.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/rabbitmq/rabbit at devstack-1368221514-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/rabbitmq/rabbit at devstack-1368221514.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/screen-swift.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-cinder-stable-folsom/222/logs/syslog.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1764827223.1373385.1391680552286.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-06 10:55:52',3600,'2014-02-06 09:55:52',NULL,'[openstack-dev] Asynchrounous programming: replace eventlet\n with asyncio','Sean Dague wrote:\n> First, very cool!\n\nThanks.\n\n> This is very promising work. It might be really interesting to figure\n> out if there was a smaller project inside of OpenStack that could be\n> test ported over to this (even as a stackforge project), and something\n> we could run in the gate.\n\nOslo Messaging is a small project, but it\'s more a library. For a full daemon, my colleague Mehdi Abaakouk has a proof-on-concept for Ceilometer replacing eventlet with asyncio. Mehdi told me that he doesn\'t like to debug eventlet race conditions :-)\n\n> Our experience is the OpenStack CI system catches bugs in libraries and\n> underlying components that no one else catches, and definitely getting\n> something running workloads hard on this might be helpful in maturing\n> Trollius. Basically coevolve it with a piece of OpenStack to know that\n> it can actually work on OpenStack and be a viable path forward.\n\nReplacing eventlet with asyncio is a huge change. I don\'t want to force users to use it right now, nor to do the change in one huge commit. The change will be done step by step, and when possible, optional. For example, in Olso Messaging, you can choose the executor: eventlet or blocking (and I want to add asyncio).\n\nVictor\n\n\n','<52F2A7F5.70505@dague.net>',NULL),('<1765344841.2851044.1367970582331.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-05-07 16:49:42',-25200,'2013-05-07 23:49:42',NULL,'[openstack-dev] [Nova][vmware] sub-team meeting announcement','Hello everyone,\n\nI would like to announce the first meeting of the VMwareAPI subteam. \nThis subteam will be focused on improving OpenStack support for \nboth the VMwareESXDriver and the VMwareVCDriver but I\'m leaving\nthe door open to including any other ways that VMwareAPI might be\nused in OpenStack.\n\nOur first meeting\'s agenda will be:\n\n* Grizzly Bug Triage\n* general Havana Blueprint discussion & priority\n* Test Coverage: We need Unit tests and better test coverage!\n* Future meeting time(s) and frequency\n\nFirst meeting time:\n\nThursday, May 9, 2013 at 1:00:00 AM UTC \nhttp://www.timeanddate.com/worldclock/fixedtime.html?iso=20130509T0100 \nNote: this is 6pm Wednesday May 8th for west coast US\n\nFor details see:\nhttps://wiki.openstack.org/wiki/Meetings/VMwareAPI \n\nIf you are interested in lending a hand I hope to see you!\n\n# Shawn Hartsock\n\n\n','<1881591314.2785720.1367968879873.JavaMail.root@vmware.com>',NULL),('<1767461802.12657765.1395830622334.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 11:43:42',3600,'2014-03-26 10:43:42',NULL,'[openstack-dev] [horizon] xstatic for removing bundled js libs','Hi Radomir,\n\nI quickly looked at xstatic and I have the impression that you have to handle manually the retrievement of the javascript library files and the version of the scripts. What do you think of wrapping bower in a script in order to dynamically generate packages with the right versions? \n\n----- Original Message -----\nFrom: \"Radomir Dopieralski\" <openstack at sheep.art.pl>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, March 26, 2014 9:25:26 AM\nSubject: [openstack-dev] [horizon] xstatic for removing bundled js libs\n\nHello,\n\nBefore we split Horizon into two parts, we need to deal with a couple of\nrelated cleanup tasks. One of them is getting rid of the bundled\nJavaScript libraries that we are using. They are currently just included\nin the Horizon\'s source tree. Ideally, we would like to have them\ninstalled as dependencies. There is a blueprint for that at:\n\nhttps://blueprints.launchpad.net/horizon/+spec/remove-javascript-bundling\n\nWe have several options for actually doing this. One of them is\nselecting an appropriate django-* library, where available, and using\nwhatever additional API and code the author of the library made\navailable. We need to choose carefully, and every library has to be\napproached separately for this.\n\nI propose a more general solution of using xstatic-* Python packages,\nwhich contain basically just the files that we want to bundle, plus some\nsmall amount of metadata. All of the JavaScript (and any static files,\nreally, including styles, fonts and icons) would be then handled the\nsame way, by just adding the relevant package to the requirements and to\nthe settings.py file. Packaging the libraries that are missing is very\neasy (as there is no extra code to write), and we get to share the\neffort with other projects that use xstatic.\n\nAnyways, I made a proof of concept patch that demonstrates this approach\nfor the jQuery library. Obviously it fails Jenkins tests, as the xstatic\nand xstatic-jquery packages are not included in the global requirements,\nbut it shows how little effort is involved. You can see the patch at:\n\nhttps://review.openstack.org/#/c/82516/\n\nAny feedback and suggestions appreciated.\n-- \nRadomir Dopieralski\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<53328EF6.6000200@sheep.art.pl>',NULL),('<1767815.54EeIdMSPH@hounddog>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-16 12:35:14',39600,'2014-10-16 01:35:14',NULL,'[openstack-dev] [kolla] on Dockerfile patterns','On Wed, 15 Oct 2014 12:40:16 AM Fox, Kevin M wrote:\n> Systemd has invested a lot of time/effort to be able to relaunch failed\n> services, support spawning and maintaining unix sockets and services across\n> them, etc, that you\'d have to push out of and across docker containers. All\n> of that can be done, but why reinvent the wheel? Like you said, pacemaker\n> can be made to make it all work, but I have yet to see a way to deploy\n> pacemaker services anywhere near as easy as systemd+yum makes it. (Thanks\n> be to redhat. :)\n\nYou should also consider \"fleet\", if you want a systemd-approach to containers.  \nIt\'s basically a cluster-wide systemd that often (but doesn\'t have to) \nstart/restart docker containers on various hosts.\n\nI tried it for a short while and it isn\'t bad.  The verbosity and \nrepetitiveness of the systemd files was a bit annoying, but that would be easy \nto script away.  I did like how simple it was, and the ability to express \ndependencies between systemd entities.\n\nNote that fleet is essentially systemd managing containers from the outside - \nnot running systemd inside the container.  So in many ways it\'s a \nrepeat/reinforcement of the same conversation we\'re already having.\n\n-- \n - Gus\n\n\n','<1A3C52DFCD06494D8528644858247BF088C31B@EX10MBOX03.pnnl.gov>',NULL),('<1768649681.27.1380089073483.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-25 06:04:33',0,'2013-09-25 06:04:33',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-postgres-stable-grizzly #24','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/24/>\n\n------------------------------------------\n[...truncated 7155 lines...]\n2013-09-25 06:04:08 warning: no files found matching \'ChangeLog\'\n2013-09-25 06:04:08 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-25 06:04:08 writing manifest file \'nova.egg-info/SOURCES.txt\'\n2013-09-25 06:04:08 ++ awk \'/^.+/ {print \"-f \" $1}\' nova.egg-info/dependency_links.txt\n2013-09-25 06:04:08 + raw_links=\n2013-09-25 06:04:08 ++ echo\n2013-09-25 06:04:08 ++ xargs\n2013-09-25 06:04:08 + depend_links=\n2013-09-25 06:04:08 ++ \'[\' \'!\' -r nova.egg-info/requires.txt \']\'\n2013-09-25 06:04:08 ++ echo \'-r *-info/requires.txt\'\n2013-09-25 06:04:08 + require_file=\'-r *-info/requires.txt\'\n2013-09-25 06:04:08 + pip_install -r nova.egg-info/requires.txt\n2013-09-25 06:04:08 + [[ False = \\T\\r\\u\\e ]]\n2013-09-25 06:04:10 + [[ -z -r nova.egg-info/requires.txt ]]\n2013-09-25 06:04:10 + [[ -z deb ]]\n2013-09-25 06:04:10 + [[ False = True ]]\n2013-09-25 06:04:10 + SUDO_PIP=sudo\n2013-09-25 06:04:10 ++ get_pip_command\n2013-09-25 06:04:10 ++ is_fedora\n2013-09-25 06:04:10 ++ [[ -z Ubuntu ]]\n2013-09-25 06:04:10 ++ \'[\' Ubuntu = Fedora \']\'\n2013-09-25 06:04:10 ++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-09-25 06:04:10 ++ \'[\' Ubuntu = CentOS \']\'\n2013-09-25 06:04:10 ++ which pip\n2013-09-25 06:04:10 + CMD_PIP=/usr/local/bin/pip\n2013-09-25 06:04:10 + [[ False != \\F\\a\\l\\s\\e ]]\n2013-09-25 06:04:10 + sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r nova.egg-info/requires.txt\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): SQLAlchemy>=0.7.8,<0.7.99 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 1))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): Cheetah>=2.4.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 2))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 3))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.2.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 4))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): boto in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 5))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.9.17 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 6))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): kombu>=1.0.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 7))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): lxml>=2.3 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 8))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): routes>=1.12.3 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 9))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): WebOb==1.2.3 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 10))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.1 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 11))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): PasteDeploy>=1.5.0 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 12))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): paste in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 13))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): sqlalchemy-migrate>=0.7.2 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 14))\n2013-09-25 06:04:10 Downloading/unpacking netaddr>=0.7.6 (from -r nova.egg-info/requires.txt (line 15))\n2013-09-25 06:04:10   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fnetaddr%2Fnetaddr-0.7.10.zip\n2013-09-25 06:04:10   Running setup.py egg_info for package netaddr\n2013-09-25 06:04:10     \n2013-09-25 06:04:10     warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n2013-09-25 06:04:10     warning: no previously-included files matching \'*.git*\' found anywhere in distribution\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): suds>=0.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 16))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): paramiko in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 17))\n2013-09-25 06:04:10 Downloading/unpacking pyasn1 (from -r nova.egg-info/requires.txt (line 18))\n2013-09-25 06:04:10   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyasn1%2Fpyasn1-0.1.7.tar.gz\n2013-09-25 06:04:10   Running setup.py egg_info for package pyasn1\n2013-09-25 06:04:10     \n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 19))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 20))\n2013-09-25 06:04:10 Requirement already satisfied (use --upgrade to upgrade): httplib2 in /usr/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 21))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): setuptools-git>=0.4 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 22))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): python-cinderclient>=1.0.1 in /opt/stack/new/python-cinderclient (from -r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Downloading/unpacking python-quantumclient>=2.2.0,<3.0.0 (from -r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:13   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-quantumclient%2Fpython-quantumclient-2.2.3.tar.gz\n2013-09-25 06:04:13   Running setup.py egg_info for package python-quantumclient\n2013-09-25 06:04:13     [pbr] Processing SOURCES.txt\n2013-09-25 06:04:13     warning: LocalManifestMaker: standard file \'-c\' not found\n2013-09-25 06:04:13     \n2013-09-25 06:04:13     [pbr] In git context, generating filelist from git\n2013-09-25 06:04:13     warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): python-glanceclient>=0.5.0,<2 in /opt/stack/new/python-glanceclient (from -r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r nova.egg-info/requires.txt (line 26))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): stevedore>=0.7 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 27))\n2013-09-25 06:04:13 Downloading/unpacking websockify<0.4 (from -r nova.egg-info/requires.txt (line 28))\n2013-09-25 06:04:13   Downloading websockify-0.3.0.tar.gz\n2013-09-25 06:04:13   In the tar file /tmp/pip-oxhpl9-unpack/websockify-0.3.0.tar.gz the member websockify-0.3.0/websockify.py is invalid: \"linkname \'websockify-0.3.0/run\' not found\"\n2013-09-25 06:04:13   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fwebsockify%2Fwebsockify-0.3.0.tar.gz\n2013-09-25 06:04:13   Running setup.py egg_info for package websockify\n2013-09-25 06:04:13     \n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r nova.egg-info/requires.txt (line 29))\n2013-09-25 06:04:13 Downloading/unpacking Markdown>=2.0.1 (from Cheetah>=2.4.4->-r nova.egg-info/requires.txt (line 2))\n2013-09-25 06:04:13   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2FMarkdown%2FMarkdown-2.3.1.tar.gz\n2013-09-25 06:04:13   Running setup.py egg_info for package Markdown\n2013-09-25 06:04:13     \n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): decorator in /usr/lib/python2.7/dist-packages (from sqlalchemy-migrate>=0.7.2->-r nova.egg-info/requires.txt (line 14))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): Tempita>=0.4 in /usr/lib/python2.7/dist-packages (from sqlalchemy-migrate>=0.7.2->-r nova.egg-info/requires.txt (line 14))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=0.9.6->-r nova.egg-info/requires.txt (line 19))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:13 Requirement already satisfied (use --upgrade to upgrade): d2to1>=0.2.10,<0.3 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4 in /usr/local/lib/python2.7/dist-packages (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:15 Downloading/unpacking pyparsing>=1.5.6,<2.0 (from python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:15   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpyparsing%2Fpyparsing-1.5.7.tar.gz\n2013-09-25 06:04:15   Running setup.py egg_info for package pyparsing\n2013-09-25 06:04:15     \n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): numpy in /usr/lib/python2.7/dist-packages (from websockify<0.4->-r nova.egg-info/requires.txt (line 28))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-cinderclient>=1.0.1->-r nova.egg-info/requires.txt (line 23))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): distribute in /usr/lib/python2.7/dist-packages (from d2to1>=0.2.10,<0.3->python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4->python-quantumclient>=2.2.0,<3.0.0->-r nova.egg-info/requires.txt (line 24))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:15 Requirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient>=0.5.0,<2->-r nova.egg-info/requires.txt (line 25))\n2013-09-25 06:04:15 Installing collected packages: netaddr, pyasn1, python-quantumclient, websockify, Markdown, pyparsing\n2013-09-25 06:04:15   Found existing installation: netaddr 0.7.5\n2013-09-25 06:04:15     Uninstalling netaddr:\n2013-09-25 06:04:15       Successfully uninstalled netaddr\n2013-09-25 06:04:15   Running setup.py install for netaddr\n2013-09-25 06:04:15     changing mode of build/scripts-2.7/netaddr from 644 to 755\n2013-09-25 06:04:15     \n2013-09-25 06:04:15     warning: no previously-included files matching \'*.svn*\' found anywhere in distribution\n2013-09-25 06:04:15     warning: no previously-included files matching \'*.git*\' found anywhere in distribution\n2013-09-25 06:04:15     changing mode of /usr/local/bin/netaddr to 755\n2013-09-25 06:04:15   Running setup.py install for pyasn1\n2013-09-25 06:04:15     \n2013-09-25 06:04:15   Running setup.py install for python-quantumclient\n2013-09-25 06:04:15     [pbr] Reusing existing SOURCES.txt\n2013-09-25 06:04:15     Installing quantum script to /usr/local/bin\n2013-09-25 06:04:15   Running setup.py install for websockify\n2013-09-25 06:04:15     \n2013-09-25 06:04:15     Installing websockify script to /usr/local/bin\n2013-09-25 06:04:15   Running setup.py install for Markdown\n2013-09-25 06:04:15     changing mode of build/scripts-2.7/markdown_py from 644 to 755\n2013-09-25 06:04:15     Converting docs/cli.txt -> build/docs/cli.html\n2013-09-25 06:04:15     Converting docs/release-2.1.0.txt -> build/docs/release-2.1.0.html\n2013-09-25 06:04:15     Converting docs/change_log.txt -> build/docs/change_log.html\n2013-09-25 06:04:15     Converting docs/reference.txt -> build/docs/reference.html\n2013-09-25 06:04:15     Converting docs/release-2.0.1.txt -> build/docs/release-2.0.1.html\n2013-09-25 06:04:15     Converting docs/authors.txt -> build/docs/authors.html\n2013-09-25 06:04:15     Converting docs/release-2.2.0.txt -> build/docs/release-2.2.0.html\n2013-09-25 06:04:15     Converting docs/release-2.3.txt -> build/docs/release-2.3.html\n2013-09-25 06:04:15     Converting docs/install.txt -> build/docs/install.html\n2013-09-25 06:04:15     Converting docs/release-2.0.txt -> build/docs/release-2.0.html\n2013-09-25 06:04:15     Converting docs/release-2.2.1.txt -> build/docs/release-2.2.1.html\n2013-09-25 06:04:15     Converting docs/test_suite.txt -> build/docs/test_suite.html\n2013-09-25 06:04:16     Converting docs/siteindex.txt -> build/docs/siteindex.html\n2013-09-25 06:04:16     Converting docs/release-2.0.2.txt -> build/docs/release-2.0.2.html\n2013-09-25 06:04:16     Converting docs/release-2.1.1.txt -> build/docs/release-2.1.1.html\n2013-09-25 06:04:16     Converting docs/index.txt -> build/docs/index.html\n2013-09-25 06:04:16     Converting docs/extensions/extra.txt -> build/docs/extensions/extra.html\n2013-09-25 06:04:16     Converting docs/extensions/nl2br.txt -> build/docs/extensions/nl2br.html\n2013-09-25 06:04:16     Converting docs/extensions/api.txt -> build/docs/extensions/api.html\n2013-09-25 06:04:16     Converting docs/extensions/header_id.txt -> build/docs/extensions/header_id.html\n2013-09-25 06:04:16     Converting docs/extensions/smart_strong.txt -> build/docs/extensions/smart_strong.html\n2013-09-25 06:04:16     Converting docs/extensions/code_hilite.txt -> build/docs/extensions/code_hilite.html\n2013-09-25 06:04:16     Converting docs/extensions/tables.txt -> build/docs/extensions/tables.html\n2013-09-25 06:04:16     Converting docs/extensions/definition_lists.txt -> build/docs/extensions/definition_lists.html\n2013-09-25 06:04:16     Converting docs/extensions/meta_data.txt -> build/docs/extensions/meta_data.html\n2013-09-25 06:04:16     Converting docs/extensions/sane_lists.txt -> build/docs/extensions/sane_lists.html\n2013-09-25 06:04:16     Converting docs/extensions/wikilinks.txt -> build/docs/extensions/wikilinks.html\n2013-09-25 06:04:16     Converting docs/extensions/attr_list.txt -> build/docs/extensions/attr_list.html\n2013-09-25 06:04:16     Converting docs/extensions/toc.txt -> build/docs/extensions/toc.html\n2013-09-25 06:04:16     Converting docs/extensions/admonition.txt -> build/docs/extensions/admonition.html\n2013-09-25 06:04:16     Converting docs/extensions/abbreviations.txt -> build/docs/extensions/abbreviations.html\n2013-09-25 06:04:16     Converting docs/extensions/fenced_code_blocks.txt -> build/docs/extensions/fenced_code_blocks.html\n2013-09-25 06:04:16     Converting docs/extensions/index.txt -> build/docs/extensions/index.html\n2013-09-25 06:04:16     Converting docs/extensions/footnotes.txt -> build/docs/extensions/footnotes.html\n2013-09-25 06:04:16     \n2013-09-25 06:04:16     changing mode of /usr/local/bin/markdown_py to 755\n2013-09-25 06:04:16   Found existing installation: pyparsing 2.0.1\n2013-09-25 06:04:16     Uninstalling pyparsing:\n2013-09-25 06:04:16       Successfully uninstalled pyparsing\n2013-09-25 06:04:16   Running setup.py install for pyparsing\n2013-09-25 06:04:16     \n2013-09-25 06:04:16 Successfully installed netaddr pyasn1 python-quantumclient websockify Markdown pyparsing\n2013-09-25 06:04:16 Cleaning up...\n2013-09-25 06:04:16 + sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-09-25 06:04:16 running develop\n2013-09-25 06:04:16 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-09-25 06:04:16 /usr/bin/python -E -c pass\n2013-09-25 06:04:16 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-09-25 06:04:16 running egg_info\n2013-09-25 06:04:16 writing requirements to nova.egg-info/requires.txt\n2013-09-25 06:04:16 writing nova.egg-info/PKG-INFO\n2013-09-25 06:04:16 writing top-level names to nova.egg-info/top_level.txt\n2013-09-25 06:04:16 writing dependency_links to nova.egg-info/dependency_links.txt\n2013-09-25 06:04:16 reading manifest template \'MANIFEST.in\'\n2013-09-25 06:04:16 warning: no files found matching \'AUTHORS\'\n2013-09-25 06:04:16 warning: no files found matching \'ChangeLog\'\n2013-09-25 06:04:16 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-09-25 06:04:16 writing manifest file \'nova.egg-info/SOURCES.txt\'\n2013-09-25 06:04:16 running build_ext\n2013-09-25 06:04:16 Creating /usr/local/lib/python2.7/dist-packages/nova.egg-link (link to .)\n2013-09-25 06:04:16 Adding nova 2013.1.4.a27.gfaabb91 to easy-install.pth file\n2013-09-25 06:04:16 Installing nova-all script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-api script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-api-ec2 script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-api-metadata script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-api-os-compute script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-baremetal-deploy-helper script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-baremetal-manage script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-rpc-zmq-receiver script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-cells script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-cert script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-clear-rabbit-queues script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-compute script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-conductor script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-console script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-consoleauth script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-dhcpbridge script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-manage script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-network script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-novncproxy script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-objectstore script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-rootwrap script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-scheduler script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-spicehtml5proxy script to /usr/local/bin\n2013-09-25 06:04:16 Installing nova-xvpvncproxy script to /usr/local/bin\n2013-09-25 06:04:16 \n2013-09-25 06:04:16 Installed /opt/stack/new/nova\n2013-09-25 06:04:16 Processing dependencies for nova==2013.1.4.a27.gfaabb91\n2013-09-25 06:04:16 error: Installed distribution pyparsing 1.5.7 conflicts with requirement pyparsing>=2.0.1\n2013-09-25 06:04:16 ++ failed\n2013-09-25 06:04:16 ++ local r=1\n2013-09-25 06:04:16 +++ jobs -p\n2013-09-25 06:04:16 ++ kill\n2013-09-25 06:04:16 ++ set +o xtrace\n2013-09-25 06:04:16 stack.sh failed: full log in /opt/stack/new/devstacklog.txt.2013-09-25-060130\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/localrc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-384360-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-384360.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-postgres-stable-grizzly/devstack-precise-hpcloud-az2-384360/24/logs/syslog.txt.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<17688349.217.1387867634016.JavaMail.yfried@yfried-mobl-rh>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-12-24 01:47:15',-18000,'2013-12-24 06:47:15',NULL,'[openstack-dev] [Tempest][qa] Adding tags to commit messages','Hi,\nSuggestion: Please consider tagging your Tempest commit messages the same way you do your mails in the mailing list\n\nExplanation: Since tempest is a single project testing multiple Openstack project we have a very diverse collection of patches as well as reviewers. Tagging our commit messages will allow us to classify patches and thus:\n1. Allow reviewer to focus on patches related to their area of expertise\n2. Track \"trends\" in patches - I think we all know that we lack in Neutron testing for example, but can we assess how many network related patches are for awaiting review\n3. Future automation of flagging \"interesting\" patches\n\nYou can usually tell all of this from reviewing the patch, but by then - you\'ve spent time on a patch you might not even be qualified to review.\nI suggest we tag our patches with, to start with, the components we are looking to test, and the type of test (sceanrio, api, ...) and that reviewers should -1 untagged patches.\n\nI think the tagging should be the 2nd line in the message:\n\n======================================\nExample commit message\n\n[Neutron][Nova][Network][Scenario]\n\nExplanation of how this scenario tests both Neutron and Nova\nNetwork performance\n\nChang-id XXXXXXXXXXXXXXXXXXX\n=======================================\n\nI would like this to start immediately but what do you guys think?\n\n\n','<16605157.210.1387866795146.JavaMail.yfried@yfried-mobl-rh>',NULL),('<1768961868.7.1381730614664.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-14 06:03:34',0,'2013-10-14 06:03:34',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #30','See <https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/30/>\n\n------------------------------------------\n[...truncated 4910 lines...]\n    raise Exception()\nException\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:03:26.584504\', resource_metadata={}) from 0 transformer\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:03:26    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:03:26.589743\', resource_metadata={}) from 0 transformer\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:03:26    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:03:26.597069\', resource_metadata={}) from 0 transformer\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:03:26    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:03:26.604609\', resource_metadata={}) from 0 transformer\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-10-14 06:03:26     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-10-14 06:03:26    DEBUG [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-10-14T06:03:26.614128\', resource_metadata={}) from 0 transformer\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-10-14 06:03:26    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 41, in test_keystone_middleware_conf\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nceilometer.storage: DEBUG: looking for \'mongodb\' driver in \'ceilometer.storage\'\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'sqlite = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'postgresql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'log = ceilometer.storage.impl_log:LogStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mongodb = ceilometer.storage.impl_mongodb:MongoDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'mysql = ceilometer.storage.impl_sqlalchemy:SQLAlchemyStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'test = ceilometer.storage.impl_test:TestDBStorage\')\nstevedore.extension: DEBUG: found extension EntryPoint.parse(\'hbase = ceilometer.storage.impl_hbase:HBaseStorage\')\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.ij1YH79MzE/keystone-signing-aBChtf as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v1.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v1/test_app.py\",> line 51, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.wsgi_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n\n======================================================================\nERROR: test_keystone_middleware_conf (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 42, in test_keystone_middleware_conf\n    self.assertEqual(api_app.auth_protocol, \'foottp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\nkeystoneclient.middleware.auth_token: INFO: Starting keystone auth_token middleware\nkeystoneclient.middleware.auth_token: WARNING: Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\nkeystoneclient.middleware.auth_token: INFO: Using /tmp/tmp.ij1YH79MzE/keystone-signing-cvBTbr as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_keystone_middleware_parse_conffile (tests.api.v2.test_app.TestApp)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/api/v2/test_app.py\",> line 52, in test_keystone_middleware_parse_conffile\n    self.assertEqual(api_app.auth_protocol, \'barttp\')\nAttributeError: \'AuthProtocol\' object has no attribute \'auth_protocol\'\n-------------------- >> begin captured logging << --------------------\n2013-10-14 06:03:11     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-14 06:03:11     INFO [keystoneclient.middleware.auth_token] Starting keystone auth_token middleware\n2013-10-14 06:03:11  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-14 06:03:11  WARNING [keystoneclient.middleware.auth_token] Configuring auth_uri to point to the public identity endpoint is required; clients may not be able to authenticate against an admin endpoint\n2013-10-14 06:03:11     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.ij1YH79MzE/keystone-signing-0ydRmk as cache directory for signing certificate\n2013-10-14 06:03:11     INFO [keystoneclient.middleware.auth_token] Using /tmp/tmp.ij1YH79MzE/keystone-signing-0ydRmk as cache directory for signing certificate\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 22.194s\n\nFAILED (SKIP=290, errors=4)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/bin/nosetests> --no-path-adjustment\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.7.1\nMako==0.9.0\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b5\nWebOb==1.2.3\nWebTest==2.0.9\nWerkzeug==0.9.4\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\nboto==2.14.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.30\ncffi==0.7.2\ncliff==1.4.5\ncmd2==0.6.7\ncoverage==3.7\ndecorator==3.4.0\ndnspython==1.11.1\ndocutils==0.9.1\necdsa==0.9\neventlet==0.14.0\nextras==0.0.3\nglance==2013.1\ngreenlet==0.4.1\nhappybase==0.6\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==1.2\njsonpointer==1.0\njsonschema==2.1.0\nkombu==2.5.15\nlogutils==0.3.3\nlxml==3.2.3\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.1\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.2.1\nparamiko==1.12.0\npasslib==1.6.1\npbr==0.5.21\npecan==0.4.2\nprettytable==0.7.2\npyOpenSSL==0.13.1\npyasn1==0.1.7\npycparser==2.10\npycrypto==2.6\npymongo==2.6.3\npyparsing==2.0.1\npython-cinderclient==1.0.6\npython-glanceclient==0.11.0\npython-keystoneclient==0.4.0\npython-neutronclient==2.3.1\npython-novaclient==2.15.0\npython-quantumclient==2.2.4.3\npython-spidermonkey==0.0.10\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplegeneric==0.8.1\nsimplejson==3.3.1\nsingledispatch==3.4.0.2\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.12\nsuds==0.4\nswift==1.9.1\nthrift==0.9.1\nunittest2==0.5.1\nwaitress==0.8.7\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.ij1YH79MzE\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/centos6-8/30\n[SCP] Copying console log.\n\n\n','<67081185.3.1381644216826.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1769508685.3587448.1415363007836.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-11-07 07:23:27',-18000,'2014-11-07 12:23:27',NULL,'[openstack-dev] [NFV][Telco] Minutes from Telco Working Group\n Session are now available.','Hi all,\n\nThis week there was \"Telco Working Group\" session on the operators track at OpenStack Summit in Paris. We had some issues with etherpad connectivity during the session but Carol has since uploaded minutes of the session and they are available here:\n\n    https://etherpad.openstack.org/p/kilo-summit-ops-telco\n\nThanks,\n\nSteve\n\n\n','<1319217299.3586476.1415362819787.JavaMail.zimbra@redhat.com>',NULL),('<1769508685.3587448.1415363007836.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2014-11-07 07:23:27',-18000,'2014-11-07 12:23:27',NULL,'[Openstack-operators] [NFV][Telco] Minutes from Telco Working Group\n Session are now available.','Hi all,\n\nThis week there was \"Telco Working Group\" session on the operators track at OpenStack Summit in Paris. We had some issues with etherpad connectivity during the session but Carol has since uploaded minutes of the session and they are available here:\n\n    https://etherpad.openstack.org/p/kilo-summit-ops-telco\n\nThanks,\n\nSteve\n\n\n','<1319217299.3586476.1415362819787.JavaMail.zimbra@redhat.com>',NULL),('<1769568541.5162146.1390315245035.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-21 09:40:45',-18000,'2014-01-21 14:40:45',NULL,'[openstack-dev] [TripleO] [Tuskar] Terminology Revival #1 -\n Roles','Thanks for starting this!  Comments in-line:\n\n> Hi folks,\n> \n> when I was getting feedback on wireframes and we talked about Roles,\n> there were various objections and not much suggestions. I would love to\n> call for action and think a bit about the term for concept currently\n> known as Role (= Resource Category).\n> \n> Definition:\n> Role is a representation of a group of nodes, with specific behavior.\n\nI don\'t think this is technically correct; according to the wireframes, a \'Role\'\nis a representation of a group of Heat resources from an overcloud stack - a \nController Resource, Compute Resource, etc.  Free nodes have no Role.\n\n> Each role contains (or will contain):\n> * one or more Node Profiles (which specify HW which is going in)\n> * association with image (which will be provisioned on new coming nodes)\n> * specific service settings\n> \n> So far suggested terms:\n> * Role *\n>    - short name - plus points\n>    - quite overloaded term (user role, etc)\n> \n> * Resource Category *\n>    - pretty long (devs already shorten it - confusing)\n>    - Heat specific term\n\nThat\'s why I suggested this term after others objected to Role; it seems to me\nthat whatever term we use should have the world \'Resource\' in it, in order to\nmake the correspondence clear.\n\n\nMainn\n\n> * Resource Class *\n>    - older term\n> \n> Are there any other suggestions (ideally something short and accurate)?\n> Or do you prefer any of already suggested terms?\n> \n> Any ideas are welcome - we are not very good in finding the best match\n> for this particular term.\n> \n> Thanks\n> -- Jarda\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<52DE81F6.2020803@redhat.com>',NULL),('<1769935159.317.1366784614579.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-24 06:23:34',0,'2013-04-24 06:23:34',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #205','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/205/>\n\n\n\n','<1272362839.300.1366697846946.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1770631585.117.1364105948433.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-24 06:19:08',0,'2013-03-24 06:19:08',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-folsom #174','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/174/>\n\n\n\n','<1603239410.103.1364019569015.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1770809843.38.1374645739540.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-24 06:02:19',0,'2013-07-24 06:02:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-folsom #296','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/296/>\n\n------------------------------------------\n[...truncated 23 lines...]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' horizon == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/296/\', \'BUILD_TAG\': \'jenkins-periodic-horizon-docs-stable-folsom-296\', \'SSH_CLIENT\': \'198.101.231.203 47218 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-horizon-docs-stable-folsom\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'XDG_SESSION_COOKIE\': \'46b38f61d2217983c255af8300000421-1374091207.84347-824899917\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'precise precise6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-07-24_06-00-25\', \'BUILD_NUMBER\': \'296\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'5857f07e-0f63-4fd0-9a98-34a121ca8a36\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/\', \'GIT_BRANCH\': \'origin/stable/folsom\', \'GIT_COMMIT\': \'525fab26148158055a6534be8e390b7f3f89dab0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'precise6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'BUILD_DISPLAY_NAME\': \'#296\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 47218 50.56.249.238 22\'}\nDownloading/unpacking Django>=1.4,<1.5 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 2))\n  Running setup.py egg_info for package Django\n    \nDownloading/unpacking django-compressor (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 3))\n  Running setup.py egg_info for package django-compressor\n    \n    warning: no files found matching \'*.js\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.css\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.png\' under directory \'compressor/tests/media\'\n    warning: no files found matching \'*.coffee\' under directory \'compressor/tests/media\'\nDownloading/unpacking django-openstack-auth (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 4))\n  Downloading django_openstack_auth-1.1.0.tar.gz\n  Running setup.py egg_info for package django-openstack-auth\n    \nDownloading/unpacking python-cinderclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 5))\n  Running setup.py egg_info for package python-cinderclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-cinderclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-glanceclient<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 6))\n  Running setup.py egg_info for package python-glanceclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-glanceclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-keystoneclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 7))\n  Running setup.py egg_info for package python-keystoneclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-hljxEb/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-hljxEb/d2to1-0.2.10/egg-dist-tmp-5jReDH\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-slOzhW/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-slOzhW/setuptools-git-1.0/egg-dist-tmp-_keBbY\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-keystoneclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-novaclient (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 8))\n  Running setup.py egg_info for package python-novaclient\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-novaclient/setuptools_git-1.0-py2.7.egg>\n    \n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\nDownloading/unpacking python-quantumclient>=2.0 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 9))\n  Running setup.py egg_info for package python-quantumclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1>=0.2.10,<0.3\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-WLnnS4/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-WLnnS4/d2to1-0.2.10/egg-dist-tmp-ygPqCV\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-r3EEwN/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-r3EEwN/setuptools-git-1.0/egg-dist-tmp-CdSM0I\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-quantumclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking python-swiftclient>1.1,<2 (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 10))\n  Running setup.py egg_info for package python-swiftclient\n    warning: no previously-included files found matching \'.gitignore\'\n    warning: no previously-included files found matching \'.gitreview\'\n    warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n    zip_safe flag not set; analyzing archive contents...\n    pbr.d2to1.tests.__init__: module references __file__\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/pbr-0.5.19-py2.7.egg>\n    Searching for d2to1\n    Reading http://pypi.openstack.org/openstack/d2to1/\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=M;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/d2to1/?C=S;O=A\n    Best match: d2to1 0.2.10\n    Downloading http://pypi.openstack.org/openstack/d2to1/d2to1-0.2.10.tar.gz\n    Processing d2to1-0.2.10.tar.gz\n    Writing /tmp/easy_install-JUJId9/d2to1-0.2.10/setup.cfg\n    Running d2to1-0.2.10/setup.py -q bdist_egg --dist-dir /tmp/easy_install-JUJId9/d2to1-0.2.10/egg-dist-tmp-ZUvvvk\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/d2to1-0.2.10-py2.7.egg>\n    Searching for setuptools-git>=0.4\n    Reading http://pypi.openstack.org/openstack/setuptools_git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=S;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=N;O=D\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=D;O=A\n    Reading http://pypi.openstack.org/openstack/setuptools-git/?C=M;O=A\n    Best match: setuptools-git 1.0\n    Downloading http://pypi.openstack.org/openstack/setuptools-git/setuptools-git-1.0.tar.gz\n    Processing setuptools-git-1.0.tar.gz\n    Writing /tmp/easy_install-7wOVze/setuptools-git-1.0/setup.cfg\n    Running setuptools-git-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-7wOVze/setuptools-git-1.0/egg-dist-tmp-TImLoS\n    \n    Installed <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/.tox/venv/build/python-swiftclient/setuptools_git-1.0-py2.7.egg>\n    [d2to1] running patched manifest_maker command with extra_files support\n    \n    warning: no files found matching \'*\' under directory \'tools\'\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in atexit._run_exitfuncs:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\n    Error in sys.exitfunc:\n    Traceback (most recent call last):\n      File \"/usr/lib/python2.7/atexit.py\", line 24, in _run_exitfuncs\n        func(*targs, **kargs)\n      File \"/usr/lib/python2.7/multiprocessing/util.py\", line 284, in _exit_function\n        info(\'process shutting down\')\n    TypeError: \'NoneType\' object is not callable\nDownloading/unpacking pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\n  Could not find a version that satisfies the requirement pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11)) (from versions: 2012c, 2012c, 2012c, 2012d, 2012d, 2012d, 2012f, 2012f, 2012f, 2012g, 2012g, 2012g, 2012h, 2012h, 2012j, 2012j, 2012j, 2013b, 2013b, 2013b)\nCleaning up...\nNo distributions matching the version for pytz (from -r <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires> (line 11))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-folsom/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-folsom/296\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<17708253.8b0d.1420c9e25ae.Coremail.xu_zhong_xing@163.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-10-31 11:46:00',28800,'2013-10-31 03:46:00',NULL,'[openstack-dev] [neutron] [ml2] What is the router plugin for ml2','I noticed that the ml2 plugin does not support router extension itself. In README, it says \"It utilizes the service plugin interface to implement the L3 router abstraction.\"\n\nI wonder what is the current solution for router in ml2? Is there a plugin that already exists?\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131031/cb25ee22/attachment.html>\n\n',NULL,NULL),('<1770842665.3.1374127595494.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-18 06:06:35',0,'2013-07-18 06:06:35',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #290','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/290/>\n\n------------------------------------------\n[...truncated 8986 lines...]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 204, in test_workflow_finalization\n    self.assertTrue(flow.finalize())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 747, in finalize\n    exceptions.handle(self.request)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 738, in finalize\n    data = step.action.handle(self.request, self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/functional.py\",> line 185, in inner\n    return func(self._wrapped, *args)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_render (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 230, in test_workflow_render\n    output = http.HttpResponse(flow.render())\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 791, in render\n    return workflow_template.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 140, in render\n    return self._render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/test/utils.py\",> line 62, in instrumented_test_render\n    return self.nodelist.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 823, in render\n    bit = self.render_node(node, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 837, in render_node\n    return node.render(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/defaulttags.py\",> line 474, in render\n    self.extra_context.iteritems()])\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 571, in resolve\n    obj = self.var.resolve(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 721, in resolve\n    value = self._resolve_lookup(context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/template/base.py\",> line 772, in _resolve_lookup\n    current = current()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 659, in get_entry_point\n    step._verify_contributions(self.context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 386, in _verify_contributions\n    field = self.action.fields.get(key, None)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nERROR: test_workflow_validation (horizon.tests.workflows_tests.WorkflowsTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 191, in test_workflow_validation\n    flow = TestWorkflow(req, context_seed={\"project_id\": self.tenant.id})\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 589, in __init__\n    valid = step.action.is_valid()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 361, in action\n    context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 141, in __init__\n    self._populate_choices(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/workflows/base.py\",> line 153, in _populate_choices\n    bound_field.choices = meth(request, context)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/workflows_tests.py\",> line 48, in populate_project_id_choices\n    request.user.authorized_tenants]\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 214, in authorized_tenants\n    if self.is_authenticated() and self._authorized_tenants is None:\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/user.py\",> line 189, in is_authenticated\n    return self.token is not None and check_token_expiration(self.token)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/openstack_auth/utils.py\",> line 55, in check_token_expiration\n    if settings.USE_TZ and timezone.is_naive(expiration):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/django/utils/timezone.py\",> line 261, in is_naive\n    return value.tzinfo is None or value.tzinfo.utcoffset(value) is None\nAttributeError: \'str\' object has no attribute \'tzinfo\'\n\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 332, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: service_catalog\n>>  raise UnknownMethodCallError(\'service_catalog\')\n    \n\nSlowest 5 tests took 1.04 secs:\n    0.52    RoleAPITests.test_get_default_role\n    0.16    HorizonTests.test_lazy_urls\n    0.14    DataTableTests.test_summation_row\n    0.12    DataTableTests.test_table_action_attributes\n    0.10    NetworkTests.test_subnet_create_post\n----------------------------------------------------------------------\nRan 350 tests in 5.525s\n\nFAILED (SKIP=2, errors=455, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.7\nMarkupSafe==0.18\nPygments==1.6\nSphinx==1.2b1\nargparse==1.2.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndistribute==0.7.3\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.1.0\ndocutils==0.9.1\nhorizon==2012.2.5\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nlockfile==0.9.1\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\npbr==0.5.18\npep8==1.4.5\nprettytable==0.7.2\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.3.1\npython-novaclient==2.13.0\npython-quantumclient==2.2.3\npython-swiftclient==1.5.0\npytz==2013b\nrequests==1.2.3\nselenium==2.33.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.3i88GFgbx7\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/290\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/290/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/290/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1717292570.23.1374041299382.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1771217515.52.1383372927765.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:15:27',0,'2013-11-02 06:15:27',NULL,'[Openstack-stable-maint] Jenkins build became unstable:\n periodic-nova-python26-stable-grizzly #44','See <https://jenkins02.openstack.org/job/periodic-nova-python26-stable-grizzly/44/changes>\n\n\n\n',NULL,NULL),('<1771625760.43.1378534096420.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-07 06:08:16',0,'2013-09-07 06:08:16',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-folsom #22','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/22/>\n\n------------------------------------------\n[...truncated 953 lines...]\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.00\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.00\n    test_merge_properties                                        OK    0.00\n    test_raw_json_schema                                         OK    0.00\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.00\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.00\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.01\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.01\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.01\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.03\n    test_cooperative_reader_of_iterator                          OK    0.00\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.00\n    test_is_uuid_like_success                                    OK    0.00\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.01\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_from_json_malformed                                     OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.00\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\n\n======================================================================\nERROR: Test that we notice when our log file has been rotated\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/glance/tests/functional/test_logging.py\",> line 95, in test_logrotate\n    response, content = httplib2.Http().request(path, \'GET\')\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1570, in request\n    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1317, in _request\n    (response, content) = self._conn_request(conn, request_uri, method, body, headers)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 1290, in _conn_request\n    conn.connect()\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/httplib2/__init__.py\",> line 913, in connect\n    raise socket.error, msg\nerror: [Errno 111] ECONNREFUSED\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 65.66 secs:\n    13.72    TestGlanceControl.test_bouncing\n    13.41    TestScrubber.test_delayed_delete\n    13.28    TestGlanceControl.test_reload\n    13.07    TestGlanceControl.test_respawn\n    12.18    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 926 tests in 429.388s\n\nFAILED (SKIP=89, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-folsom/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python27-stable-folsom-22\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.14\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\npasslib==1.6.1\npbr==0.5.21\npep8==1.1\npycparser==2.10\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.6.0\npytz==2013d\nrepoze.lru==0.6\nrequests==1.2.3\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.095SkMHEKb\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/22\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-folsom/22/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-folsom/precise36/22\n[SCP] Copying console log.\n\n\n','<932299892.42.1378447747265.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1771773460.52.1387694637194.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-22 06:43:57',0,'2013-12-22 06:43:57',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-neutron-python26-havana #9','See <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/9/changes>\n\nChanges:\n\n[Armando Migliaccio] Reduce the severity of dhcp related log traces\n\n------------------------------------------\n[...truncated 115 lines...]\n<https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'NexusPortBinding\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.cisco.db.nexus_models_v2.NexusPortBinding\'>\n  _as_declarative(cls, classname, cls.__dict__)\n<https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/lib/python2.6/site-packages/sqlalchemy/ext/declarative.py>:1341: SAWarning: The classname \'VlanAllocation\' is already in the registry of this declarative base, mapped to <class \'neutron.plugins.openvswitch.ovs_models_v2.VlanAllocation\'>\n  _as_declarative(cls, classname, cls.__dict__)\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.plugins.nicira.nvp_cluster:The following cluster attributes were not specified: [\'default_l3_gw_service_uuid\']\'\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.manager:Loading Plugin: neutron.plugins.nicira.NeutronPlugin.NvpPluginV2\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'metadata_dhcp_host_route\' has been deprecated or moved to a new section. See new configuration file for details.\nWARNING:neutron.plugins.nicira.nvp_cluster:Deprecated: Attribute \'nvp_controller_connection\' has been deprecated or moved to a new section. See new configuration file for details.\nINFO:neutron.manager:Service L3_ROUTER_NAT is supported by the core plugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nINFO:neutron.common.config:Config paste file: <https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/neutron/tests/etc/api-paste.ini.test>\nINFO:neutron.manager:Loading Plugin: neutron.db.db_base_plugin_v2.NeutronDbPluginV2\nINFO:neutron.manager:Loading Plugin: neutron.tests.unit.dummy_plugin.DummyServicePlugin\nBuild timed out (after 40 minutes). Marking the build as failed.\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-neutron-python26-havana/ws/.tox/py26/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==2.0\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==2.0.10\nalembic==0.6.1\namqp==1.3.3\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.3.2\ncliff==1.4.5\ncmd2==0.6.7\nconfigobj==4.7.2\ncoverage==3.7.1\ndiscover==0.4.0\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nflake8==2.0\ngreenlet==0.4.1\nhacking==0.7.2\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonrpclib==0.1.3\nkombu==3.0.8\nmccabe==0.2.1\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nneutron==jenkins.periodic.neutron.python26.havana.9\nordereddict==1.1\noslo.config==1.2.1\npbr==0.5.23\npep8==1.4.5\nprettytable==0.7.2\npyflakes==0.7.3\npyparsing==2.0.1\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-neutronclient==2.3.2\npython-novaclient==2.15.0\npython-subunit==0.0.16\npytz==2013.8\npyudev==0.16.1\nrepoze.lru==0.6\nrequests==2.1.0\nsetuptools-git==1.0\nsimplejson==3.3.1\nsix==1.4.1\nstevedore==0.13\ntestrepository==0.0.18\ntesttools==0.9.34\nwaitress==0.8.8\n[SCP] Connecting to static.openstack.org\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py26/bin/subunit-1to2\n++ rm -rf /tmp/tmp.XhaOEPAOI5\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-havana/centos6-2\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python26-havana/centos6-2/9\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1772163771.6007393.1389808632053.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-15 09:57:12',-28800,'2014-01-15 17:57:12',NULL,'[openstack-dev] [Neutron] Partially Shared Networks','----- Original Message -----\n> From: \"PAUL CARVER\" <pc2929 at att.com>\n> To: OpenStack-dev at lists.openstack.org\n> Sent: Wednesday, January 15, 2014 6:52:32 AM\n> Subject: [openstack-dev] [Neutron] Partially Shared Networks\n> \n> <snip>\n>\n> The particular use case I have in mind concerns networks that could\n> technically be created as admin and marked as shared and thus have only\n> whatever network namespace considerations that apply to shared networks. The\n> desire to make them \"partially shared\" has more to do with the UI (either\n> Horizon or API access) not showing them to tenants who are not on the\n> approved list and not permitting tenants who are not on the list to attach\n> instances to them.\n> \n> This is basically like the door list at a club. If you\'re not on the list you\n> can\'t get into the club. But if you\'re on the list, once you\'re inside the\n> club it\'s not really any different from a less exclusive club other than the\n> fact that everybody inside was \"on the list\".\n> \n> \n> --\n> Paul Carver\n\nThis is one of the use cases we are considering for the \"Congress\" project (https://wiki.openstack.org/wiki/Congress).\n\nPolicy is well-suited for modeling this sort of scenario where the user wants to express intended behavior as a subset of the system\'s capabilities.  Decoupling policy from networking facilitates expressing this intent using inputs across multiple systems (e.g. Neutron, Nova, Active Directory, etc).\n\nAs an example, we have a demo modeling the following use case: \"Every network connected to a VM must be either public or private and owned by someone in the same group as the VM\'s owner.\"  Congress is still in the early stages, however, and integration with Neutron is still TBD.  If this sounds interesting, please send me a note.\n\n- Peter\n\n\n','<A81F249089B6C7479786834457908C600AC07696@MISOUT7MSGUSR9N.ITServices.sbc.com>',NULL),('<1772776180.236.1364882696811.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-02 06:04:56',0,'2013-04-02 06:04:56',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-horizon-python26-stable-folsom #183','See <https://jenkins.openstack.org/job/periodic-horizon-python26-stable-folsom/183/changes>\n\n\n\n','<340672114.224.1364796381456.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1773490829.10.1379485764905.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-09-18 06:29:24',0,'2013-09-18 06:29:24',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-coverage #21','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage/21/>\n\n------------------------------------------\n[...truncated 20464 lines...]\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_retries_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_snapshot_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_type_list ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_version ... ok\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list\ntempest.cli.simple_read_only.test_cinder.SimpleReadOnlyCinderClientTest.test_cinder_volumes_list ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_delete[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_snapshot_create_get_list_delete[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_absolute_limites ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_aggregate_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_availability_zone_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_cloudpipe_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_credentials ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_domains ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_dns_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_endpoints ... ok\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate]\ntempest.api.volume.test_volumes_snapshots.VolumesSnapshotTest.test_volume_from_snapshot[gate] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_bashcompletion ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_catalog_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_acces_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_debug_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_discover ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_flavor_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_bulk_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_endpoint_service_match ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_role_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_floating_ip_pool_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_service_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_help ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_tenant_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_host_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_user_role_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_hypervisor_list ... ok\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version\ntempest.cli.simple_read_only.test_keystone.SimpleReadOnlyKeystoneClientTest.test_admin_version ... ok\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume]\ntempest.scenario.test_stamp_pattern.TestStampPattern.test_stamp_pattern[compute,image,network,volume] ... skipped u\'Skipped until the Bug #1205344 is resolved.\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_image_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_interface_list ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until the Bug #1182679 is resolved.\'\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_compute.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest)\nsetUpClass (tempest.cli.simple_read_only.test_neutron.SimpleReadOnlyNeutronClientTest) ... skipped u\'Skiping all Neutron cli tests because it is not available\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard]\ntempest.scenario.test_dashboard_basic_ops.TestDashboardBasicOps.test_basic_scenario[dashboard] ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until the Bug #1080406 is resolved\'\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_get_delete[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until the Bug #1098891 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until the Bug #1072318 is resolved\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke]\ntempest.thirdparty.boto.test_ec2_volumes.EC2VolumesTest.test_create_volume_from_snapshot[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\nSlowest Tests\nTest id                                                                                                                 Runtime (s)\n----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]          190.464\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]  171.143\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                  66.806\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestXML.test_server_security_groups[gate]         34.519\ntempest.api.compute.security_groups.test_security_groups.SecurityGroupsTestJSON.test_server_security_groups[gate]        33.291\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                    32.234\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_auto_disk_config[gate]    31.097\ntempest.api.compute.servers.test_server_rescue.ServerRescueTestJSON.test_rescued_vm_detach_volume[gate,negative]         29.935\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]       29.404\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_rebuild_server_with_auto_disk_config[gate]     29.384\n\n----------------------------------------------------------------------\nRan 1214 tests in 1277.261s\n\nOK (skipped=74)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-316126-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-316126.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage/devstack-precise-hpcloud-az2-316126/21/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1816961469.4.1379230770053.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1773576979.77.1383545541692.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-04 06:12:21',0,'2013-11-04 06:12:21',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #37','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/37/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60ae850>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x60ae850>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x666ac90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x666ac90>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-cb9a37d8-7383-4c9d-85aa-663627c2e0cd\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x458e7d0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x458e7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x458e7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x458e7d0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:11:46Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'46\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'46\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:11:46Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'46\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'46\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:11:46+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'46\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'46\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:11:46-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'46\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'46\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:11:46Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'46\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'46\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x769b590>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x31312d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 87.77 secs:\n    25.67    TestScrubber.test_scrubber_app\n    20.11    TestScrubber.test_delayed_delete\n    14.44    TestGlanceControl.test_reload\n    14.19    TestGlanceControl.test_respawn\n    13.36    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 1109 tests in 579.206s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.37\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.uMoMEeLHgI\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/37/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise2/37\n[SCP] Copying console log.\n\n\n','<1889292486.70.1383459322134.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1773935472.5123411402695355736.JavaMail.nobody@rsj2rmd001.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-06-13 21:35:55',0,'2014-06-13 21:35:55',NULL,'[OpenStack Foundation] Invitation to OpenStack Board Meeting July\n	22, 2014','Hello Foundation Mailing List,\n\nThe OpenStack Board invites you to participate as an attendee in the following OpenStack board meeting. We will be using WebEx to facilitate the meeting and audio conferencing. Please join the WebEx session then follow the instructions to either join the telephone conference service or to join via VOIP.\n\nTopic: OpenStack Board Meeting July 22, 2014\nHost: Alan Clark\nDate: Tuesday, July 22, 2014\nTime: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)\nSession number: 925 892 682\nSession password: This session does not require a password.\nAgenda: http://wiki.openstack.org/Governance/Foundation\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=teff1082a4ff1c633822be02eabeedf2e\n2. Enter your name and email address.\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo add this session to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=ta11be132f134ca9085398d27972ee139\n\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tc1d2646f7b5386b2c05a28f419a30245\n\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=291427802&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 925 892 682\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\naclark at suse.com\n\n\n\n\n\nhttp://www.webex.com\n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140613/711636d8/attachment.html>\n\n',NULL,NULL),('<177419166.229.1368253009314.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-11 06:16:49',0,'2013-05-11 06:16:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly-centos6 #11','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly-centos6/11/>\n\n\n\n','<1417462918.209.1368166753639.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1774869569.46.1387260418510.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-17 06:06:58',0,'2013-12-17 06:06:58',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-horizon-docs-grizzly #8','See <https://jenkins02.openstack.org/job/periodic-horizon-docs-grizzly/8/changes>\n\n\n\n','<786918272.37.1387173689655.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1775097105.50.1387433012359.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-19 06:03:32',0,'2013-12-19 06:03:32',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-heat-docs-grizzly #9','See <https://jenkins02.openstack.org/job/periodic-heat-docs-grizzly/9/changes>\n\n\n\n','<656019340.48.1387346493971.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1775306685.94.1364018704315.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-03-23 06:05:04',0,'2013-03-23 06:05:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-horizon-python27-stable-folsom #173','See <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/173/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal5 in workspace <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/>\nCheckout:periodic-horizon-python27-stable-folsom / <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/> - hudson.remoting.Channel at 2760bf5e:quantal5\nUsing strategy: Default\nLast Built Revision: Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\nChecking out Revision 5677e583d8d0cf9318557d9513287c7e2be60d9c (origin/stable/folsom)\n[periodic-horizon-python27-stable-folsom] $ /bin/bash -xe /tmp/hudson2946231421566776974.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack horizon\n+ version=27\n+ org=openstack\n+ project=horizon\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.x79OF1oDKu\n+ TMPDIR=/tmp/tmp.x79OF1oDKu\n+ trap \'rm -rf /tmp/tmp.x79OF1oDKu\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack horizon\n+ org=openstack\n+ project=horizon\n+ [[ -z openstack ]]\n+ [[ -z horizon ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ echo openstack\nopenstack\n+ cat\n+ tox -epy27\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/setup.py>\npy27 create: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/tools/test-requires>\npy27 inst: <https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/dist/horizon-2012.2.4.zip>\npy27 runtests: commands[0]\nRunning Horizon application tests\n\n...........................................................................................................................................................................................................................................................FF............................................................................................SS\n======================================================================\nFAIL: test_get_default_role (horizon.tests.api_tests.keystone_tests.RoleAPITests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 76, in test_get_default_role\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\n======================================================================\nFAIL: Tests api.keystone.remove_tenant_user\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/tests/api_tests/keystone_tests.py\",> line 62, in test_remove_tenant_user\n    keystoneclient = self.stub_keystoneclient()\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/horizon/test.py\",> line 329, in stub_keystoneclient\n    self.keystoneclient = self.mox.CreateMock(keystone_client.Client)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 258, in CreateMock\n    new_mock = MockObject(class_to_mock, attrs=attrs)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 556, in __init__\n    attr = getattr(class_to_mock, method)\n  File \"<https://jenkins.openstack.org/job/periodic-horizon-python27-stable-folsom/ws/.tox/py27/local/lib/python2.7/site-packages/mox.py\",> line 608, in __getattr__\n    raise UnknownMethodCallError(name)\nUnknownMethodCallError: Method called is not a member of the object: Method called is not a member of the object: auth_token\n>>  raise UnknownMethodCallError(\'auth_token\')\n    \n\nSlowest 5 tests took 2.12 secs:\n    0.50    UserSettingsTest.test_timezone_offset_is_displayed\n    0.49    ImagesViewTest.test_images_list_get_pagination\n    0.47    SecurityGroupsViewTests.test_edit_rules_invalid_icmp_rule\n    0.38    RoleAPITests.test_get_default_role\n    0.27    ImagesAndSnapshotsTests.test_index\n----------------------------------------------------------------------\nRan 347 tests in 15.613s\n\nFAILED (SKIP=2, failures=2)\nnosetests --verbosity 1 horizon --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nRunning openstack_dashboard tests\n\n\n----------------------------------------------------------------------\nRan 0 tests in 0.000s\n\nOK\nnosetests --verbosity 1 openstack_dashboard --nocapture --nologcapture --exclude-dir=horizon/conf/ --cover-package=horizon --cover-inclusive\nCreating test database for alias \'default\'...\nDestroying test database for alias \'default\'...\nTests failed.\nERROR: InvocationError: \'/bin/bash run_tests.sh -N\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nDjango==1.4.5\nJinja2==2.6\nPygments==1.6\nSphinx==1.1.3\nargparse==1.2.1\ncliff==1.3.1\ncmd2==0.6.4\ncolorama==0.2.5\ncoverage==3.6\ndistribute==0.6.34\ndjango-appconf==0.6\ndjango-compressor==1.3\ndjango-nose==1.1\ndjango-openstack-auth==1.0.7\ndocutils==0.9.1\nhorizon==2012.2.4\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==0.7\njsonschema==0.8.0\nlockfile==0.9.1\nlogilab-astng==0.24.2\nlogilab-common==0.59.0\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.0\npep8==1.4.5\nprettytable==0.7.1\npyOpenSSL==0.13\npylint==0.27.0\npyparsing==1.5.7\npython-cinderclient==1.0.2\npython-glanceclient==0.8.0\npython-keystoneclient==0.2.3\npython-novaclient==2.11.1\npython-quantumclient==2.2.0\npython-swiftclient==1.3.0\npytz==2013b\nrequests==0.14.2\nselenium==2.31.0\nsimplejson==3.1.2\nsix==1.3.0\ntermcolor==1.1.0\nwarlock==0.8.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -f .testrepository/0 \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ \'[\' -d .testrepository \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.x79OF1oDKu\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/173\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/173/dashboard_nose_results.html\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-horizon-python27-stable-folsom/173/horizon_nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1321746560.80.1363932283363.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1775653880.7624906.1393235177604.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-24 04:46:17',-18000,'2014-02-24 09:46:17',NULL,'[Openstack] [Heat/Ceilometer/Havana]: Auto scaling no\n	longer	occurring after some time','\nHi Juha,\n\nAre you using Havana?\n\nIf so, your alarm resource templates seem to be missing setting the\n\"repeat_actions\" attribute to true. Continuous notification was required\nin order for the Heat autoscaling cooldown logic (and continued scaling\nactions) to work.\n\nThis was a quirk of the Heat implementation in Havan, but TBH from a\nusability PoV should have always had this set to True by default. This\nis fixed now on Heat:master:\n\n  https://github.com/openstack/heat/commit/4dc987ef\n\nbut hasn\'t been backported to Heat:stable/stable.\n\nThe issue you see with the instance.scheduled message being rejected with \n\"signature invalid\" is not related to autoscaling, and in case I\'ve fixed\nit in Ceilometer:master and stable/havana:\n\n  https://bugs.launchpad.net/ceilometer/+bug/1262255\n\nreleased in:\n\n  https://launchpad.net/ceilometer/+milestone/2013.2.2\n\nThe issue you see with mongo complaining that a metering message is not\nokForStorage is generally caused by a stray period (\'.\') in some resource\nmetadata key.\n\nWhere the metadata is prefixed by \'metering.\', then the periods are\nmapped to underscores, so in your case:\n\n  { \"Key\" : \"metering.server_group\", \"Value\" : \"Group_A\" },\n            ^^^^^^^^^^\n\nthat mapping should have occurred. In any case, I\'d be interested in hearing\nwhich actual metering messages are being rejected with not okForStorage.\n\nThanks,\nEoghan\n\n> Hi,\n> \n> I\'m having some problems concerning auto scaling feature.\n> Any ideas?\n> \n> First scaling up and down is working just fine. But then when tested later on\n> scaling down/up is no longer working properly.\n> Scaling down may occur even it shouldn\'t or scaling up doesn\'t occur even it\n> should. When in this situation I remove all the\n> received metric data from the DB, auto scaling starts to work again.\n> \n> Ceilometer is configured to use Mongo and the auto scaling is based on the\n> cpu_util metrics.\n> \n> Related configurations:\n> -----------------------\n> /etc/ceilometer/pipeline.yaml on compute nodes:\n> \n> name: cpu_pipeline\n> interval: 15\n> \n> /etc/ceilometer/ceilometer.conf on controller:\n> evaluation_interval=15\n> \n> Heat template used:\n> -------------------\n> \"Resources\" : {\n> \n> \"Group_A\" : {\n> \"Type\" : \"AWS::AutoScaling::AutoScalingGroup\",\n> \"Properties\" : {\n> \"AvailabilityZones\" : { \"Fn::GetAZs\" : \"\"},\n> \"LaunchConfigurationName\" : { \"Ref\" : \"Group_A_Config\" },\n> \"MinSize\" : \"1\",\n> \"MaxSize\" : \"3\",\n> \"Tags\" : [\n> { \"Key\" : \"metering.server_group\", \"Value\" : \"Group_A\" },\n> { \"Key\" : \"custom_metadata\", \"Value\" : \"test\" }\n> ],\n> \"VPCZoneIdentifier\" : [ { \"Ref\" : \"PrivateSubnetId\" } ]\n> }\n> },\n> \n> \"Group_A_Config\" : {\n> \"Type\" : \"AWS::AutoScaling::LaunchConfiguration\",\n> \"Properties\": {\n> \"ImageId\" : { \"Ref\" : \"ImageId\" },\n> \"InstanceType\" : { \"Ref\" : \"InstanceType\" },\n> \"KeyName\" : { \"Ref\" : \"KeyName\" }\n> }\n> },\n> \n> \"ScaleUpPolicy\" : {\n> \"Type\" : \"AWS::AutoScaling::ScalingPolicy\",\n> \"Properties\" : {\n> \"AdjustmentType\" : \"ChangeInCapacity\",\n> \"AutoScalingGroupName\" : { \"Ref\" : \"Group_A\" },\n> \"Cooldown\" : \"20\",\n> \"ScalingAdjustment\" : \"1\"\n> }\n> },\n> \n> \"ScaleDownPolicy\" : {\n> \"Type\" : \"AWS::AutoScaling::ScalingPolicy\",\n> \"Properties\" : {\n> \"AdjustmentType\" : \"ChangeInCapacity\",\n> \"AutoScalingGroupName\" : { \"Ref\" : \"Group_A\" },\n> \"Cooldown\" : \"20\",\n> \"ScalingAdjustment\" : \"-1\"\n> }\n> },\n> \n> \"CPUAlarmHigh\": {\n> \"Type\": \"OS::Ceilometer::Alarm\",\n> \"Properties\": {\n> \"description\": \"Scale-up if CPU is greater than 90% for 20 seconds\",\n> \"meter_name\": \"cpu_util\",\n> \"statistic\": \"avg\",\n> \"period\": \"20\",\n> \"evaluation_periods\": \"1\",\n> \"threshold\": \"90\",\n> \"alarm_actions\":\n> [ {\"Fn::GetAtt\": [\"ScaleUpPolicy\", \"AlarmUrl\"]} ],\n> \"matching_metadata\":\n> {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> \"comparison_operator\": \"gt\"\n> }\n> },\n> \n> \"CPUAlarmLow\": {\n> \"Type\": \"OS::Ceilometer::Alarm\",\n> \"Properties\": {\n> \"description\": \"Scale-down if CPU is less than 50% for 20 seconds\",\n> \"meter_name\": \"cpu_util\",\n> \"statistic\": \"avg\",\n> \"period\": \"20\",\n> \"evaluation_periods\": \"1\",\n> \"threshold\": \"50\",\n> \"alarm_actions\":\n> [ {\"Fn::GetAtt\": [\"ScaleDownPolicy\", \"AlarmUrl\"]} ],\n> \"matching_metadata\":\n> {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> \"comparison_operator\": \"lt\"\n> }\n> \n> In ceilometer logs I can see the following kind of warnings:\n> \n> <44>Feb 24 08:41:08 node-16\n> ceilometer-ceilometer.collector.dispatcher.database WARNING: message\n> signature invalid, discarding message: {u\'counter_name\':\n> u\'instance.scheduled\', u\'user_id\': None, u\'message_signature\':\n> u\'d1b49ddf004edc5b7a8dc9405b42a71f2ae975d04c25838c3dc0ea0e6f6e4edd\',\n> u\'timestamp\': u\'2014-02-24 08:41:08.334580\', u\'resource_id\':\n> u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'message_id\':\n> u\'67e611e4-9d2f-11e3-81f1-080027e519cb\', u\'source\': u\'openstack\',\n> u\'counter_unit\': u\'instance\', u\'counter_volume\': 1, u\'project_id\':\n> u\'efcca4ba425c4beda73eb31a54df931a\', u\'resource_metadata\': {u\'instance_id\':\n> u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'weighted_host\': {u\'host\':\n> u\'node-18\', u\'weight\': 3818.0}, u\'host\': u\'scheduler.node-16\',\n> u\'request_spec\': {u\'num_instances\': 1, u\'block_device_mapping\':\n> [{u\'instance_uuid\': u\'48c815ab-01c9-4ac8-9096-ac171976598c\',\n> u\'guest_format\': None, u\'boot_index\': 0, u\'delete_on_termination\': True,\n> u\'no_device\': None, u\'connection_info\': None, u\'volume_id\': None,\n> u\'device_name\': None, u\'disk_bus\': None, u\'image_id\':\n> u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'source_type\': u\'image\',\n> u\'device_type\': u\'disk\', u\'snapshot_id\': None, u\'destination_type\':\n> u\'local\', u\'volume_size\': None}], u\'image\': {u\'status\': u\'active\', u\'name\':\n> u\'cirrosImg\', u\'deleted\': False, u\'container_format\': u\'bare\',\n> u\'created_at\': u\'2014-02-12T08:46:04.000000\', u\'disk_format\': u\'qcow2\',\n> u\'updated_at\': u\'2014-02-12T08:46:04.000000\', u\'properties\': {},\n> u\'min_disk\': 0, u\'min_ram\': 0, u\'checksum\':\n> u\'50bdc35edb03a38d91b1b071afb20a3c\', u\'owner\':\n> u\'efcca4ba425c4beda73eb31a54df931a\', u\'is_public\': True, u\'deleted_at\':\n> None, u\'id\': u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'size\': 9761280},\n> u\'instance_type\': {u\'root_gb\': 1, u\'name\': u\'m1.tiny\', u\'ephemeral_gb\': 0,\n> u\'memory_mb\': 512, u\'vcpus\': 1, u\'extra_specs\': {}, u\'swap\': 0,\n> u\'rxtx_factor\': 1.0, u\'flavorid\': u\'1\', u\'vcpu_weight\': None, u\'id\': 2},\n> u\'instance_properties\': {u\'vm_state\': u\'building\', u\'availability_zone\':\n> None, u\'terminated_at\': None, u\'ephemeral_gb\': 0, u\'instance_type_id\': 2,\n> u\'user_data\': u\'Q29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PSI9PT0\n> ...\n> , u\'cleaned\': False, u\'vm_mode\': None, u\'deleted_at\': None,\n> u\'reservation_id\': u\'r-l91mh33v\', u\'id\': 274, u\'security_groups\':\n> {u\'objects\': []}, u\'disable_terminate\': False, u\'root_device_name\': None,\n> u\'display_name\': u\'tyky-Group_A-55cklit7nvbq-Group_A-2-yis32na5m7ey\',\n> u\'uuid\': u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'default_swap_device\':\n> None, u\'info_cache\': {u\'instance_uuid\':\n> u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'network_info\': []}, u\'hostname\':\n> u\'tyky-group-a-55cklit7nvbq-group-a-2-yis32na5m7ey\', u\'launched_on\': None,\n> u\'display_description\': u\'tyky-Group_A-55cklit7nvbq-Group_A-2-yis32na5m7ey\',\n> u\'key_data\': u\'ssh-rsa\n> AAAAB3NzaC1yc2EAAAADAQABAAABAQC39hmz8e40Xv/+QKkLyRA7j02RfIG61cr1j41RftnkOF3ZbwBzi7qibsOA3gC9Ln05YbB6z2/iUnQzxQsoOpmlnXuv2O296utY2ZCTKhdFSzn2Ot7l635zEXkivMc97wz4bITtaBTjX3nV6sXOfevdTIOJeC11SqxmfNRRzXcz9fRv6kLjz7IrA0tvRTp2xDVtFEj+vFLWaXc3TcUSygxiSLeAuNkH1rZ9jVuHXXvzb/e7navrGyJec2P86AQg2TUk77MhLjPcbyKiJJK0DhK6zOkZUWXtgIVQx7+gO/Xs2QgQHcw+VdzRzpJK+/EOzUOU8IDWNnyfaJEnQEoX2oMj\n> Generated by Nova\\n\', u\'deleted\': False, u\'config_drive\': u\'\',\n> u\'power_state\': 0, u\'default_ephemeral_device\': None, u\'progress\': 0,\n> u\'project_id\': u\'efcca4ba425c4beda73eb31a54df931a\', u\'launched_at\': None,\n> u\'scheduled_at\': None, u\'node\': None, u\'ramdisk_id\': u\'\', u\'access_ip_v6\':\n> None, u\'access_ip_v4\': None, u\'kernel_id\': u\'\', u\'key_name\': u\'heat_key\',\n> u\'updated_at\': None, u\'host\': None, u\'user_id\':\n> u\'ef4e983291ef4ad1b88eb1f776bd52b6\', u\'system_metadata\':\n> {u\'instance_type_memory_mb\': 512, u\'instance_type_swap\': 0,\n> u\'instance_type_vcpu_weight\': None, u\'instance_type_root_gb\': 1,\n> u\'instance_type_name\': u\'m1.tiny\', u\'instance_type_id\': 2,\n> u\'instance_type_ephemeral_gb\': 0, u\'instance_type_rxtx_factor\': 1.0,\n> u\'image_disk_format\': u\'qcow2\', u\'instance_type_flavorid\': u\'1\',\n> u\'instance_type_vcpus\': 1, u\'image_container_format\': u\'bare\',\n> u\'image_min_ram\': 0, u\'image_min_disk\': 1, u\'image_base_image_ref\':\n> u\'11848cbf-a428-4dfb-8818-2f0a981f540b\'}, u\'task_state\': u\'scheduling\',\n> u\'shutdown_terminate\': False, u\'cell_name\': None, u\'root_gb\': 1, u\'locked\':\n> False, u\'name\': u\'instance-00000112\', u\'created_at\':\n> u\'2014-02-24T08:41:08.257534\', u\'locked_by\': None, u\'launch_index\': 0,\n> u\'memory_mb\': 512, u\'vcpus\': 1, u\'image_ref\':\n> u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'architecture\': None,\n> u\'auto_disk_config\': False, u\'os_type\': None, u\'metadata\':\n> {u\'metering.server_group\': u\'Group_A\', u\'AutoScalingGroupName\':\n> u\'tyky-Group_A-55cklit7nvbq\', u\'custom_metadata\': u\'test\'}},\n> u\'security_group\': [u\'default\'], u\'instance_uuids\':\n> [u\'48c815ab-01c9-4ac8-9096-ac171976598c\']}, u\'event_type\':\n> u\'scheduler.run_instance.scheduled\'}, u\'counter_type\': u\'delta\'}\n> \n> Also the following warnings/errors can be seen but they seem to occur when\n> auto scaling is properly working and have no negative effects as such:\n> \n> <44>Feb 24 08:43:08 node-16\n> <U+FEFF>ceilometer-ceilometer.transformer.conversions WARNING: dropping\n> sample with no predecessor: <ceilometer.sample.Sample object at 0x3774fd0>\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <44>Feb 24 08:43:09 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> Publishing 1 samples on metering\n> <43>Feb 24 08:43:09 node-16\n> ceilometer-ceilometer.collector.dispatcher.database ERROR: Failed to record\n> metering data: not okForStor\n> age\n> Traceback (most recent call last):\n> File\n> \"/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py\",\n> line 65, in record_metering_data\n> self.storage_conn.record_metering_data(meter)\n> File \"/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py\",\n> line 417, in record_metering_data\n> upsert=True,\n> File \"/usr/lib/python2.7/dist-packages/pymongo/collection.py\", line 487, in\n> update\n> check_keys, self.__uuid_subtype), safe)\n> File \"/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py\", line 969, in\n> _send_message\n> rv = self.__check_response_to_last_error(response)\n> File \"/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py\", line 911, in\n> __check_response_to_last_error\n> raise OperationFailure(details[\"err\"], details[\"code\"])\n> OperationFailure: not okForStorage\n> \n> Br,\n> -Juha\n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAC4iNR8KeQZw13jeuiaFUMpfVppm1t62aXVCV_jzB+oiJJ_kMw@mail.gmail.com>',NULL),('<1775740364.926932.1411139393951.JavaMail.app@ela4-app1201.prod>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-09-19 15:09:53',0,'2014-09-19 15:09:53',NULL,'[Openstack] 徐本磊，希望您能加我为领英联系人','&#x6211;&#x60f3;&#x9080;&#x8acb;&#x60a8;&#x52a0;&#x5165;&#x6211;&#x7684; LinkedIn &#x4eba;&#x8108;&#x7db2;&#x3002;\n\n??: http://www.linkedin.com/blink?simpleRedirect=c3wUcz0Oe34VdjkQdPgTe34VdjR4imVLqnhxt6BSrCACsj9Dj5wJsSIZumlbp6lOomxP9zwOnT9BoCRBrlZBt6BSrCAZqSkCpnhFtCVFtSlKbnhMpmdzoiRybmRSrCBvrmRLoORIrmkZpSVFqSdxsDgCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCpnhFtCV9sClyrmlJfm4Ce2ROpntUrzAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12647380_117&markAsRead=\n\nPeter Cheung??? http://www.linkedin.com/blink?simpleRedirect=0Ucj4Tc34Ud3R4in9BoCRBripoelgVfmVBqSZkq7hRoipBrm5KfmlMulhEt7lx9zsNclYMe3cTd3oOckBve3gRe3kVc3sPfnhMpmdzgmVLqnhxt6BSrCACe39vsClyrmlJnSlQqnpKqjRHpipBt6BSrCBTpmUJpmRxryRybmRSrCBvrmRLoORIrmkZpSVFqSdxsDgCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCtD1KfngCe2ROpntUrzAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12647380_117&markAsRead=\n\n???????????????????????: http://www.linkedin.com/blink?simpleRedirect=3wJsClTu6UVc6AJd6tUtjgSfmhFpipDm6l5rT9Gc4ZOu7lntQkJrRFcdjBBpRdOjQtQsmd5pkVAq3xpclFSc4RNmjd9gCVkpA9DcShPm3p2q4NMckp7cPpApQJJr6hfqll1gk5hkApNgl1fdTB9p4thgjRAqmZI9zwOnT9BoCRBrlZBt6BSrCAZqSkCpnhFtCVFtSlKbm9RsSVRbmoJrnpKqlZJrmZzbmNJpjRDrCBHoS5Ot2pDrnBdsSV5gmJjc4xhgjRKpmJLl6hFripPtmkZt2oUbn9BtTxKej1FbjhDu7kQdzRBfP9SbSkLrmZzbCVFp6lHrCBIbDtTtOYLeDdMt7hE&msgID=I12647380_117&markAsRead=\n\n???????? (???? - yocto????)? ????????????: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9zwOnT9BoCRBrlZBt6BSrCAZqSkCpSRVjndKhk5HkP18kk4ZrClHrRhAqmQCr79lpmdFtD9BkT9BrmZQsTlzfm4Ce2ROpntUrzAMqiQQpTxRd3oZpjYOtyZBbSRLoOVKqmhBqSVFr2VTtTsLbPFMt7hE&msgID=I12647380_117&markAsRead=\n&copy;2014 LinkedIn Ireland Limited ????????????????????: 477441?????: 70 Sir John Roberson&apos;s Quay, Dublin 2\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140919/39e85fa6/attachment.html>\n\n',NULL,NULL),('<1776113587.344056.1414190004117.JavaMail.yahoo@jws100159.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-10-24 22:33:24',0,'2014-10-24 22:33:24',NULL,'[Openstack] [openstack-dev] [Heat] Stack stuck in\n DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE','Found it! The user_creds.password column in the database is 255 characters. My value is long enough (800+) that it fills it up and gets truncated. ?I think that garbling of the data leads to the padding exception.\nIf I modify the database so that the column is longer, then the delete goes through just fine.\nKen\n      From: Ken Thomas <krt at yahoo-inc.com>\n To: Zane Bitter <zbitter at redhat.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n Sent: Friday, October 24, 2014 2:43 PM\n Subject: Re: [openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE\n   \nI\'ve got some additional info for y\'all on this. ?The problem is in heat.engine.parser.Stack.delete with this statement:\nuser_creds = db_api.user_creds_get(self.user_creds_id)\nIn my case, that call is throwing an exception that\'s not getting caught or logged. ?The exact exception is:\nERROR Incorrect paddingTraceback (most recent call last):? File \"/usr/lib/python2.6/site-packages/heat/engine/parser.py\", line 670, in delete? ? user_creds = db_api.user_creds_get(self.user_creds_id)? File \"/usr/lib/python2.6/site-packages/heat/db/api.py\", line 170, in user_creds_get? ? return IMPL.user_creds_get(context_id)? File \"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py\", line 468, in user_creds_get? ? result[\'password\'] = _decrypt(result[\'password\'], db_result.decrypt_method)? File \"/usr/lib/python2.6/site-packages/heat/db/sqlalchemy/api.py\", line 174, in _decrypt? ? value = decryptor(enc_value)? File \"/usr/lib/python2.6/site-packages/heat/common/crypt.py\", line 48, in oslo_decrypt_v1? ? auth_info, b64decode=True)? File \"/usr/lib/python2.6/site-packages/heat/openstack/common/crypto/utils.py\", line 158, in decrypt? ? msg = base64.b64decode(msg)? File \"/usr/lib64/python2.6/base64.py\", line 76, in b64decode? ? raise TypeError(msg)TypeError: Incorrect padding\nDoes this ring any bells? I checked the user_creds table and it looks okay as far as I can tell. Do I have a mismatch between how the value is encoded vs how it\'s being decoded?\nKen \n\n     From: Zane Bitter <zbitter at redhat.com>\n To: Ken Thomas <krt at yahoo-inc.com>; \"openstack at lists.openstack.org\" <openstack at lists.openstack.org> \n Sent: Wednesday, October 22, 2014 6:10 AM\n Subject: Re: [openstack-dev] [Heat] Stack stuck in DELETE_IN_PROGRESS even though all resources are DELETE_COMPLETE\n   \nMoving this to the openstack@ list...\n\nOn 21/10/14 18:56, Ken Thomas wrote:\n> Greetings all,\n> I\'m using Heat from Icehouse and I\'m hitting a problem that I\'m hoping y\'all can shed some light on.\n> I have no problems doing stack-create. I can watch the MySQL commands go by and see it happily update the stack table so that it eventually shows up as CREATE_COMPLETE. When I delete the stack, everything seems to be working fine.? I see the MySQL update that sets the stack to DELETE IN PROGRESS as well as the updates that sets my single resource to DELETE_COMPLETE... but I never see the final update to the stack table to set it to DELETE COMPLETE.\n\nI don\'t think you\'re the first person to report this, but afaik we\'ve \nnever been able to track it down. There are a bunch of things that Heat \ndoes after deleting the resources, like cleaning up trusts in Keystone, \nand perhaps one of those is failing. However, *in theory* there\'s no way \nfor the stack to be left in the \"DELETE_IN_PROGRESS\" state without an \nexception being raised that would leave a prominent entry in the logs.\n\n> One very odd thing that I found in the MySQL logs (snippet below), is a query that includes that stack name but with an extra \'*\' character append to it. My stack is named \'xyzzy8\' but notice the \'xzyzzy8*\' in the constraint. That\'s not going to return anything and I\'m wondering if that is what\'s preventing the final stack DELETE_COMPLTE update from happening?\n\nThe stack name that ends with \'*\' is the \"backup stack\", which is used \nto hold out-of-date resources during a stack update. When the stack is \ndeleted, Heat will check for the existence of the backup stack and make \nsure any resources left behind in there (from a failed update) are \ndeleted too. If it doesn\'t exist, that shouldn\'t be a problem.\n\n> There are no errors in the any of the heat logs.\n>\n> Any guidance would be greatly appreciated!\n\nAll I can suggest is to (a) make sure you have the very latest version \nof Icehouse and (b) make sure your logging is turned up to 11, then try \nagain.\n\nSince you seem very proficient at debugging, if that doesn\'t work you \ncould also try adding extra logging into the method \nheat.engine.parser.Stack.delete to try to figure out how far it is getting.\n\nFeel free to raise a bug in Launchpad and attach any logs that might \nhelp us figure out what is happening.\n\ncheers,\nZane.\n\n\n\n>\n> Ken\n> SELECT stack.status_reason AS stack_status_reason, stack.created_at AS stack_created_at, stack.deleted_at AS stack_deleted_at, stack.action AS stack_action, stack.status AS stack_status, stack.id AS stack_id, stack.name AS stack_name, stack.raw_template_id AS stack_raw_template_id, stack.username AS stack_username, stack.tenant AS stack_tenant, stack.parameters AS stack_parameters, stack.user_creds_id AS stack_user_creds_id, stack.owner_id AS stack_owner_id, stack.timeout AS stack_timeout, stack.disable_rollback AS stack_disable_rollback, stack.stack_user_project_id AS stack_stack_user_project_id, stack.updated_at AS stack_updated_atFROM stackWHERE stack.deleted_at IS NULL AND (stack.tenant = \'c6c488223aae4e97bf56dda8cef36b3b\' OR stack.stack_user_project_id = \'c6c488223aae4e97bf56dda8cef36b3b\') AND stack.name = \'xyzzy8*\' AND stack.owner_id = \'9a3e56d7-0c10-4c1c-8c54-0e5580cee121\'\n\n\n\n   \n\n  \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141024/585b0449/attachment.html>\n\n','<1321913563.329281.1414186986867.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>',NULL),('<1776855808.33.1369377375549.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-24 06:36:15',0,'2013-05-24 06:36:15',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-quantum-python26-stable-grizzly #44','See <https://jenkins.openstack.org/job/periodic-quantum-python26-stable-grizzly/44/>\n\n------------------------------------------\n[...truncated 5011 lines...]\n    test_eq_diff_name                                            OK    0.00\n    test_eq_diff_namespace                                       OK    0.00\n    test_eq_other_is_none                                        OK    0.00\n    test_eq_same_name                                            OK    0.00\n    test_eq_same_namespace                                       OK    0.00\n    test_str                                                     OK    0.00\nTestIPDeviceCommandBase\n    test_name_property                                           OK    0.00\nTestIpAddrCommand\n    test_add_address                                             OK    0.00\n    test_add_address_scoped                                      OK    0.00\n    test_del_address                                             OK    0.00\n    test_flush                                                   OK    0.00\n    test_list                                                    OK    0.00\n    test_list_filtered                                           OK    0.00\nTestIpLinkCommand\n    test_address_property                                        OK    0.00\n    test_alias_property                                          OK    0.00\n    test_delete                                                  OK    0.00\n    test_mtu_property                                            OK    0.00\n    test_qdisc_property                                          OK    0.00\n    test_qlen_property                                           OK    0.00\n    test_set_address                                             OK    0.00\n    test_set_alias                                               OK    0.00\n    test_set_down                                                OK    0.00\n    test_set_mtu                                                 OK    0.00\n    test_set_name                                                OK    0.00\n    test_set_netns                                               OK    0.00\n    test_set_up                                                  OK    0.00\n    test_settings_property                                       OK    0.00\n    test_state_property                                          OK    0.00\nTestIpNetnsCommand\n    test_add_namespace                                           OK    0.00\n    test_delete_namespace                                        OK    0.00\n    test_execute                                                 OK    0.00\n    test_execute_env_var_prepend                                 OK    0.00\n    test_namespace_doest_not_exist                               OK    0.00\n    test_namespace_exists                                        OK    0.00\nTestIpRouteCommand\n    test_add_gateway                                             OK    0.00\n    test_del_gateway                                             OK    0.00\n    test_get_gateway                                             OK    0.00\n    test_pullup_route                                            OK    0.00\n    test_pullup_route_first                                      OK    0.00\nTestIpWrapper\n    test_add_device_to_namespace                                 OK    0.00\n    test_add_device_to_namespace_is_none                         OK    0.00\n    test_add_tuntap                                              OK    0.00\n    test_add_veth                                                OK    0.00\n    test_add_veth_with_namespaces                                OK    0.00\n    test_ensure_namespace                                        OK    0.01\n    test_ensure_namespace_existing                               OK    0.01\n    test_garbage_collect_namespace_does_not_exist                OK    0.00\n    test_garbage_collect_namespace_existing_empty_ns             OK    0.01\n    test_garbage_collect_namespace_existing_not_empty            OK    0.01\n    test_get_device                                              OK    0.00\n    test_get_devices                                             OK    0.00\n    test_get_devices_malformed_line                              OK    0.00\n    test_get_namespaces                                          OK    0.00\n    test_namespace_is_empty                                      OK    0.00\n    test_namespace_is_empty_no_devices                           OK    0.00\nTestSubProcessBase\n    test_as_root_namespace                                       OK    0.00\n    test_as_root_no_root_helper                                  OK    0.00\n    test_execute_wrapper                                         OK    0.00\n    test_execute_wrapper_int_options                             OK    0.00\n    test_execute_wrapper_no_options                              OK    0.00\n    test_run_namespace                                           OK    0.00\n    test_run_no_namespace                                        OK    0.01\nLoadBalancerExtensionTestCase\n    test_create_pool_health_monitor                              OK    0.09\n    test_delete_pool_health_monitor                              OK    0.06\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    2.21\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    0.07\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.06\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.07\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nLoadBalancerExtensionTestCaseXML\n    test_create_pool_health_monitor                              OK    0.06\n    test_delete_pool_health_monitor                              OK    0.07\n    test_health_monitor_create                                   OK    0.06\n    test_health_monitor_delete                                   OK    0.07\n    test_health_monitor_get                                      OK    0.06\n    test_health_monitor_list                                     OK    0.06\n    test_health_monitor_update                                   OK    0.07\n    test_member_create                                           OK    0.06\n    test_member_delete                                           OK    2.27\n    test_member_get                                              OK    0.06\n    test_member_list                                             OK    0.06\n    test_member_update                                           OK    0.06\n    test_pool_create                                             OK    0.06\n    test_pool_delete                                             OK    0.07\n    test_pool_get                                                OK    0.06\n    test_pool_list                                               OK    0.07\n    test_pool_stats                                              OK    0.06\n    test_pool_update                                             OK    0.07\n    test_vip_create                                              OK    0.06\n    test_vip_delete                                              OK    0.07\n    test_vip_get                                                 OK    0.06\n    test_vip_list                                                OK    0.06\n    test_vip_update                                              OK    0.07\nTestMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_call_no_instance_match                                  OK    0.01\n    test_get_instance_id_network_id                              OK    0.00\n    test_get_instance_id_network_id_no_match                     OK    0.00\n    test_get_instance_id_router_id                               OK    0.00\n    test_get_instance_id_router_id_no_match                      OK    0.00\n    test_proxy_request_200                                       OK    0.01\n    test_proxy_request_403                                       OK    0.01\n    test_proxy_request_404                                       OK    0.01\n    test_proxy_request_409                                       OK    0.01\n    test_proxy_request_500                                       OK    0.01\n    test_proxy_request_other_code                                OK    0.01\n    test_proxy_request_post                                      OK    0.01\n    test_sign_instance_id                                        OK    0.00\nTestUnixDomainHttpProtocol\n    test_init_empty_client                                       OK    0.00\n    test_init_with_client                                        OK    0.00\nTestUnixDomainMetadataProxy\n    test_init_doesnot_exists                                     OK    0.00\n    test_init_exists                                             OK    0.00\n    test_init_exists_unlink_fails_file_still_exists              OK    0.00\n    test_init_exists_unlink_no_file                              OK    0.00\n    test_main                                                    OK    0.01\n    test_run                                                     OK    0.01\nTestUnixDomainWSGIServer\n    test_run                                                     OK    0.01\n    test_start                                                   OK    0.00\nTestNetworkMetadataProxyHandler\n    test_call                                                    OK    0.01\n    test_call_internal_server_error                              OK    0.01\n    test_no_argument_passed_to_init                              OK    0.00\n    test_proxy_request_network_200                               OK    0.01\n    test_proxy_request_network_404                               OK    0.00\n    test_proxy_request_network_409                               OK    0.01\n    test_proxy_request_network_418                               OK    0.00\n    test_proxy_request_network_500                               OK    0.00\n    test_proxy_request_network_exception                         OK    0.00\n    test_proxy_request_router_200                                OK    0.01\nTestProxyDaemon\n    test_init                                                    OK    0.00\n    test_main                                                    OK    0.02\n    test_main_dont_fork                                          OK    2.26\n    test_run                                                     OK    0.00\nTestUnixDomainHttpConnection\n    test_connect                                                 OK    0.00\nDefaultPolicyTestCase\n    test_default_not_found                                       OK    0.01\n    test_not_found_policy_calls_default                          OK    0.01\n    test_policy_called                                           OK    0.01\nPolicyFileTestCase\n    test_modified_policy_reloads                                 OK    0.00\nPolicyTestCase\n    test_check_bad_action_noraise                                OK    0.01\n    test_early_AND_enforcement                                   OK    0.01\n    test_early_OR_enforcement                                    OK    0.01\n    test_enforce_bad_action_throws                               OK    0.01\n    test_enforce_good_action                                     OK    0.01\n    test_enforce_http_false                                      OK    0.01\n    test_enforce_http_true                                       OK    0.01\n    test_enforce_nonexistent_action_throws                       OK    0.01\n    test_ignore_case_role_check                                  OK    0.01\n    test_templatized_enforcement                                 OK    0.01\nQuantumPolicyTestCase\n    test_enforce_adminonly_attribute_create                      OK    0.07\n    test_enforce_adminonly_attribute_nonadminctx_returns_403     OK    0.01\n    test_enforce_adminonly_attribute_update                      OK    0.01\n    test_enforce_parentresource_owner                            OK    0.01\n    test_enforce_regularuser_on_read                             OK    0.01\n    test_nonadmin_read_on_private_fails                          OK    0.01\n    test_nonadmin_read_on_shared_succeeds                        OK    0.01\n    test_nonadmin_write_on_private_fails                         OK    0.01\n    test_nonadmin_write_on_shared_fails                          OK    0.01\nTestQuantumContext\n    testQuantumContextAdminToDict                                OK    0.00\n    testQuantumContextAdminWithoutSessionToDict                  OK    0.00\n    testQuantumContextCreate                                     OK    0.00\n    testQuantumContextToDict                                     OK    0.00\nQuantumManagerTestCase\n    test_multiple_plugins_specified_for_service_type             OK    0.01\n    test_service_plugin_is_loaded                                OK    0.03\nQuotaExtensionCfgTestCase\n    test_delete_quotas_forbidden                                 OK    0.31\n    test_quotas_default_values                                   OK    0.32\n    test_show_quotas_with_admin                                  OK    0.30\n    test_show_quotas_without_admin_forbidden                     OK    0.31\n    test_update_quotas_forbidden                                 OK    0.31\nQuotaExtensionCfgTestCaseXML\n    test_delete_quotas_forbidden                                 OK    0.32\n    test_quotas_default_values                                   OK    2.67\n    test_show_quotas_with_admin                                  OK    0.21\n    test_show_quotas_without_admin_forbidden                     OK    0.21\n    test_update_quotas_forbidden                                 OK    0.21\nQuotaExtensionDbTestCase\n    test_delete_quotas_with_admin                                OK    0.21\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.22\n    test_list_quotas_with_admin                                  OK    0.30\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.31\n    test_quotas_default_values                                   OK    2.62\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.21\n    test_quotas_limit_check_with_invalid_quota_value             OK    0.22\n    test_quotas_limit_check_with_over_quota                      OK    0.23\n    test_quotas_loaded_bad_returns_404                           OK    0.23\n    test_quotas_loaded_right                                     OK    0.22\n    test_show_quotas_with_admin                                  OK    3.63\n    test_show_quotas_with_owner_tenant                           OK    0.22\n    test_show_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_update_attributes                                       OK    0.24\n    test_update_quotas_with_admin                                OK    0.23\n    test_update_quotas_with_non_integer_returns_400              OK    0.23\n    test_update_quotas_with_non_support_resource_returns_400     OK    0.22\n    test_update_quotas_without_admin_forbidden_returns_403       OK    0.22\nQuotaExtensionDbTestCaseXML\n    test_delete_quotas_with_admin                                OK    2.68\n    test_delete_quotas_without_admin_forbidden_returns_403       OK    0.20\n    test_list_quotas_with_admin                                  OK    0.21\n    test_list_quotas_without_admin_forbidden_returns_403         OK    0.21\n    test_quotas_default_values                                   OK    0.21\n    test_quotas_get_tenant_from_empty_request_context_returns_400OK    0.21\n    test_quotas_get_tenant_from_request_context                  OK    0.21\n    test_quotas_limit_check                                      OK    0.24\n    test_quotas_limit_check_with_invalid_quota_value             Build timed out (after 30 minutes). Marking the build as failed.\n[SCP] Connecting to static.openstack.org\n++ rm -rf /tmp/tmp.G1YLcwAoEb\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-quantum-python26-stable-grizzly/44\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1777712581.23543018.1368112454273.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-09 11:14:14',-14400,'2013-05-09 15:14:14',NULL,'[Openstack-stable-maint] Please review - needed for py26 CI on\n stable WAS: Change in openstack/nova[stable/grizzly]: Do not test foreign\n keys with SQLite version < 3.7','\n\n> Hi all,\n> \n> we need https://review.openstack.org/28329 merged asap, please review!\n\nApproved.\n\nCheers,\nEoghan\n \n> Cheers,\n> Alan\n> \n> > Jeremy Stanley has posted comments on this change.\n> > \n> > Change subject: Do not test foreign keys with SQLite version < 3.7\n> > ......................................................................\n> > \n> > \n> > Patch Set 1: Looks good to me, but someone else must approve\n> > \n> > Now grenade looks healthy, but more importantly this is the last remaining\n> > backport needed to have working CentOS Python 2.6 unit tests for\n> > nova/grizzly. Ubuntu ends support for Oneiric today, and with it Python\n> > 2.6. We\'ll be switching to testing on CentOS, and until this goes in all\n> > other changes to nova/grizzly will start failing to merge. Just seeing\n> > what we can do to bump the priority here.\n> > \n> > To view, visit https://review.openstack.org/28329\n> \n> _______________________________________________\n> Openstack-stable-maint mailing list\n> Openstack-stable-maint at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint\n> \n\n\n','<CAGi==UVEmpRpdAck_BqQuqnOX3ztdfrHBcAAwNcwbVpik3CujQ@mail.gmail.com>',NULL),('<177785074.1141153.1379691431483.JavaMail.root@telecom-lille.fr>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-09-20 17:37:11',7200,'2013-09-20 15:37:11',NULL,'[Openstack] Savanna error','oupps, \n\nThe previous reply was in the wrong thread. sorry.\n\nJacques Landru\n\n\n\n----- Mail original -----\nDe: \"Jacques LANDRU\" <landru at telecom-lille.fr>\nCc: openstack at lists.openstack.org\nEnvoy?: Vendredi 20 Septembre 2013 15:02:45\nObjet: Re: [Openstack] Savanna error\n\nHi,\n\nOn the compute node console, with KVM/libvirt, I use \"ps | grep\" command\n\n# ps -edf | grep instance-xxxx\n\nor to list all instances\n\n# ps -edf | grep kvm | grep vnc\n\nIf you know the libvirt domainname or domainid (*) of your instance, you can also use the virsh vncdisplay command\n- locally on the compute-node console\n              # virsh -c qemu:///system vncdisplay <domain>\n- remotely\n              # virsh -c qemu://compute-node-address/system vncdisplay <domain>\n\n(*) domainname or domainid can be displayed using the \"virsh list\" command\n\nHope, this can help.\n\nJacques Landru\n\n\n    -----oOo-----\n Jacques Landru\n   mel:  landru~hat~telecom-lille.fr\n   tel:  +33 (0)3 2033 5556\n   fax:  +33 (0)3 2033 5598\n\n Telecom Lille\n Cite scientifique, rue G. Marconi, BP20145\n 59653 VILLENEUVE D\'ASCQ  Cedex\n  web: http://www.telecom-lille.fr\n  Tel: +33 (0)3 2033 5577 \n  Fax: +33 (0)3 2033 5599 \n    -----oOo-----\n\n\n\n----- Mail original -----\nDe: \"Sagar Shimpi\" <sshimpi at expedia.com>\n?: openstack at lists.openstack.org\nEnvoy?: Vendredi 20 Septembre 2013 14:05:17\nObjet: [Openstack] Savanna error\n\nHi team \n\nI am using - \nRedhat 6.4 64-bit \nRDO -> rdo-release-grizzly-3.noarch \n\nI installed RDO grizzly on my desktop and I am able to login to the dashboard. Also I am able to create Vm\'s and login into the VM\'s. \n\nI tried to install Savanna following guidelines given on - https://savanna.readthedocs.org/en/latest/userdoc/installation.guide.html \n\nI completed the steps given in - \" To install into a virtual environment\" \nI am able to see the \"SAVANNA\" tab in Openstack dashboard, but when I click the savanna tab I am getting error saying \" Something went wrong! \" \n\n\nFollowing are my logs - \n------------------------------ \ntail -f /var/log/keystone/keystone.log \n2013-09-20 17:22:08 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:22:57 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:23:46 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:24:35 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:26:19 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:27:08 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:27:57 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:28:46 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:29:35 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n2013-09-20 17:30:42 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 127.0.0.1 \n2013-09-20 17:31:19 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 172.26.35.81 \n\n------------------------------ \ntail -f /var/log/savanna.log \n\n2013-09-20 17:32:03.721 31415 DEBUG keystoneclient.middleware.auth_token [-] Authenticating user token __call__ /root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:445 \n2013-09-20 17:32:03.721 31415 DEBUG keystoneclient.middleware.auth_token [-] Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role _remove_auth_headers /root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:503 \n2013-09-20 17:32:03.767 31415 WARNING keystoneclient.middleware.auth_token [-] Unexpected response from keystone service: {u\'error\': {u\'message\': u\'The request you have made requires authentication.\', u\'code\': 401, u\'title\': u\'Not Authorized\'}} \n2013-09-20 17:32:03.767 31415 DEBUG keystoneclient.middleware.auth_token [-] Token validation failure. _validate_user_token /root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:704 \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token Traceback (most recent call last): \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token File \"/root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py\", line 699, in _validate_user_token \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token data = self.verify_uuid_token(user_token, retry) \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token File \"/root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py\", line 995, in verify_uuid_token \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token headers = {\'X-Auth-Token\': self.get_admin_token()} \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token File \"/root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py\", line 554, in get_admin_token \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token self.admin_token_expiry) = self._request_admin_token() \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token File \"/root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py\", line 674, in _request_admin_token \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token raise ServiceError(\'invalid json response\') \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token ServiceError: invalid json response \n2013-09-20 17:32:03.767 31415 TRACE keystoneclient.middleware.auth_token \n2013-09-20 17:32:03.768 31415 DEBUG keystoneclient.middleware.auth_token [-] Marking token bc895966e9bab6912fdb7befb4e99590 as unauthorized in memcache _cache_store_invalid /root/savanna-venv/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py:965 \n2013-09-20 17:32:03.768 31415 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token bc895966e9bab6912fdb7befb4e99590 \n2013-09-20 17:32:03.769 31415 INFO keystoneclient.middleware.auth_token [-] Invalid user token - rejecting request \n------------------------------ \n\n[root at openstack ]# cat /root/savanna-venv/etc/savanna.conf \n[DEFAULT] \n\n# REST API config \nport=8386 \n\n# Address and credentials that will be used to check auth tokens \nos_auth_host=172.26.35.81 \nos_auth_port=35357 \nos_admin_username=admin \nos_admin_password=openstack \nos_admin_tenant_name=admin \n\n# When set to false, Savanna uses only internal IP of VMs. \n# When set to true, Savanna expects OpenStack to auto- \n# assign floating IPs to cluster nodes. Internal IPs will \n# be used for inter-cluster communication, while floating \n# ones will be used by Savanna to configure nodes. Also \n# floating IPs will be exposed in service URLs. \n#use_floating_ips=True \n\n# The suffix of the node\'s FQDN. In nova-network that is \n# dhcp_domain config parameter (string value) \n#node_domain=novalocal \n\n# List of plugins to be loaded. Savanna preserves the order of \n# the list when returning it. (list value) \nplugins=vanilla,hdp \n\n\n[plugin:vanilla] \nplugin_class=savanna.plugins.vanilla.plugin:VanillaProvider \n\n[plugin:hdp] \nplugin_class=savanna.plugins.hdp.ambariplugin:AmbariPlugin \n\n[database] \n\n# URL for sqlalchemy database (string value) \nconnection=sqlite:////tmp/savanna-server.db \n\n------------------------------ \n\n[root at openstack]# cat /root/keystonerc_admin \nexport OS_USERNAME=admin \nexport OS_TENANT_NAME=admin \nexport OS_PASSWORD=openstack \nexport OS_AUTH_URL=http://172.26.35.81:35357/v2.0/ \nexport PS1=\'[\\u@\\h \\W(keystone_admin)]\\$ \' \n[root at openstack ]# \n------------------------------------------------------------------------------------------- \n\nCan you please guide me where it is gng wrong ? \n\n\n\n\n\n\n\n\n\nSagar Shimpi \n\nExpedia India \n\n22nd Floor, DLF Building 5C, DLF Cyber City Phase III Gurgaon 122002, Haryana India \n\nDDI: 0124 6170828 | Mobile: +91 8800911665 \nE-mail: sshimpi at expedia.com \n\n\n\nPlease consider the environment before printing this e-mail \n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n_______________________________________________\nMailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\nPost to     : openstack at lists.openstack.org\nUnsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n\n\n','<68520449.1127109.1379682165640.JavaMail.root@telecom-lille.fr>',NULL),('<1777951210.52106017.1351785797781.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-01 12:03:17',-14400,'2012-11-01 16:03:17',NULL,'[Openstack-stable-maint] Proposing garyk for stable-maint team','\n\n----- Original Message -----\n> Hey,\n> \n> I figure I\'d abuse our new mailing list even though we set it up for\n> Jenkins notifications :)\n> \n> Gary has been doing a tonne of work identifying fixes to backport to\n> Quantum\'s stable/folsom:\n> \n>   https://review.openstack.org/#/q/branch:stable/folsom+owner:garyk,n,z\n> \n> I think he\'s showing good judgement about what constitutes a suitable\n> fix for the stable branch. Any objections to adding him to\n> stable-maint?\n\n+1 ... IMO the more domain-expertise available to stable-maint, the better.\n\nCheers,\nEoghan\n\n\n','<1351781094.3820.190.camel@sorcha>',NULL),('<1778017025.6.1352419663120.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:07:43',0,'2012-11-09 00:07:43',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-essex #87','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/87/>\n\n------------------------------------------\n[...truncated 471 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.00\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.01\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.36\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.05\n    test_public_versions                                        OK  0.05\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-essex/ws/.tox/py26/lib/python2.6/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 19.736s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.28 secs:\n    2.45       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    2.34       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.36       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at d471f65231427d54c329697982533e6868b7cdb1#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 65554ea32f0b35b7ba623dccb92489f556d89efa#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-essex/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1779986600.45297573.1403810907021.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-06-26 15:28:27',-14400,'2014-06-26 19:28:27',NULL,'[Openstack] [openstack][nova] Compute node update interval','----- Original Message -----\n> From: \"Kai Brennenstuhl\" <kai.brennenstuhl at gmail.com>\n> To: openstack at lists.openstack.org\n> Sent: Thursday, June 26, 2014 8:56:20 AM\n> Subject: [Openstack] [openstack][nova] Compute node update interval\n> \n> Hi,\n> \n> how can I specify the interval in which the (free) resources of my compute\n> nodes are updated and written into the DB?\n> I looked into nova.conf doc and already changed the following attributes:\n> \n> heal_instance_info_cache_interval = 20\n> service_down_time = 20\n> periodic_fuzzy_delay = 20\n> qpid_heartbeat = 20\n> scheduler_driver_task_period = 20\n> \n> call_timeout = 20\n> db_check_interval = 20\n> \n> But the update interval in which the resources are written into the\n> database still is about one minute.\n> \n> Which parameters should I change? Or is this configuration done somewhere\n> else than in nova.conf?\n\nHi Kai,\n\nI think you are after the report_interval [1], although the default is actually 10 seconds.\n\nThanks,\n\nSteve\n\n[1] http://docs.openstack.org/trunk/config-reference/content/list-of-compute-config-options.html\n\n\n','<CAL5=d=AHj5=iKGjD8Wnr=FG4UDbEB1oWwc8msBHSAkbN+JFAAQ@mail.gmail.com>',NULL),('<177BBF93-6656-45F0-ACA0-2B7107DE2E8A@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-10-03 09:11:11',-25200,'2014-10-03 16:11:11',NULL,'[openstack-dev] [nova] why do we have os-attach-interfaces in\n	the v3 API?','If you can add and delete interfaces it seems like being able to list them is useful. You can get the info you need from the networks list when you get the instance, but ?nova interface-list? seems like a useful addition if we have ?interface-attach? and ?interface-detach?, so in this case I think I would suggest that we leave the proxying in and implement it for nova-network as well.\n\nI was looking for an anologue with cinder but it looks like we have a volume-attach and volume-detach there without a volume-list <server> command so if people want to kill it I?m ok with that too.\n\nVish\n\nOn Oct 2, 2014, at 2:43 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:\n\n> \n> \n> On 10/2/2014 4:34 PM, Vishvananda Ishaya wrote:\n>> os-attach-interfacees is actually a a forward port of:\n>> \n>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/contrib/attach_interfaces.py\n>> \n>> which is a compute action that is valid for both nova-network and neutron:\n>> \n>> http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/api.py#n2991\n>> \n>> On Oct 2, 2014, at 1:57 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:\n>> \n>>> The os-interface (v2) and os-attach-interfaces (v3) APIs are only used for the neutron network API, you\'ll get a NotImplemented if trying to call the related methods with nova-network [1].\n>>> \n>>> Since we aren\'t proxying to neutron in the v3 API (v2.1), why does os-attach-interfaces [2] exist?  Was this just an oversight?  If so, please allow me to delete it. :)\n>>> \n>>> [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/network/api.py?id=2014.2.rc1#n310\n>>> [2] http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/plugins/v3/attach_interfaces.py?id=2014.2.rc1\n>>> \n>>> --\n>>> \n>>> Thanks,\n>>> \n>>> Matt Riedemann\n>>> \n>>> \n>>> _______________________________________________\n>>> OpenStack-dev mailing list\n>>> OpenStack-dev at lists.openstack.org\n>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> OK so create/delete call the compute_api to attach/detach, but show and index are calling the network_api on port methods which are neutron only, so I guess that\'s what I\'m talking about as far as removing. Personally I don\'t think it hurts anything, but I\'m getting mixed signals about the stance on neutron proxying in the v2.1 API.\n> \n> -- \n> \n> Thanks,\n> \n> Matt Riedemann\n> \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141003/9f8a5068/attachment.pgp>\n\n','<542DC71A.503@linux.vnet.ibm.com>',NULL),('<1781595963.52.1352765053755.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-13 00:04:13',0,'2012-11-13 00:04:13',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python27-stable-essex #91','See <https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/91/>\n\n------------------------------------------\n[...truncated 328 lines...]\n    test_xml_replaced_by_json                                   OK  0.00\nFailure\n    runTest                                                     ERROR\nDefaultPolicyTestCase\n    test_default_not_found                                      OK  0.00\n    test_not_found_policy_calls_default                         OK  0.00\n    test_policy_called                                          OK  0.00\nPolicyFileTestCase\n    test_modified_policy_reloads                                OK  0.00\nPolicyTestCase\n    test_early_AND_enforcement                                  OK  0.00\n    test_early_OR_enforcement                                   OK  0.00\n    test_enforce_bad_action_throws                              OK  0.00\n    test_enforce_good_action                                    OK  0.00\n    test_enforce_http_false                                     OK  0.00\n    test_enforce_http_true                                      OK  0.00\n    test_enforce_nonexistent_action_throws                      OK  0.01\n    test_ignore_case_role_check                                 OK  0.00\n    test_templatized_enforcement                                OK  0.00\nS3TokenMiddlewareTest\n    test_authorization_nova_toconnect                           OK  0.00\n    test_authorized                                             OK  0.00\n    test_no_path_request                                        OK  0.00\n    test_with_bogus_authorization                               OK  0.00\n    test_without_auth_storage_token                             OK  0.00\n    test_without_authorization                                  OK  0.00\nXmlSerializerTestCase\n    test_auth_request                                           OK  0.00\n    test_none                                                   OK  0.00\n    test_role_crud                                              OK  0.00\n    test_service_crud                                           OK  0.00\n    test_tenant_crud                                            OK  0.00\n    test_values_list                                            OK  0.00\nSwiftAuth\n    test_anonymous_is_authorized_for_permitted_referrer         OK  0.00\n    test_anonymous_is_not_authorized_for_unknown_reseller_prefixOK  0.00\n    test_blank_reseller_prefix                                  OK  0.00\n    test_confirmed_identity_is_authorized                       OK  0.00\n    test_confirmed_identity_is_not_authorized                   OK  0.00\nTestAuthorize\n    test_authorize_fails_as_owner_for_tenant_owner_match        OK  0.00\n    test_authorize_fails_for_invalid_referrer                   OK  0.00\n    test_authorize_fails_for_invalid_reseller_prefix            OK  0.00\n    test_authorize_fails_for_referrer_without_rlistings         OK  0.00\n    test_authorize_fails_for_unauthorized_user                  OK  0.00\n    test_authorize_succeeds_as_owner_for_operator_role          OK  0.00\n    test_authorize_succeeds_as_owner_for_tenant_owner_match     OK  0.00\n    test_authorize_succeeds_for_container_sync                  OK  0.00\n    test_authorize_succeeds_for_referrer_with_obj               OK  0.00\n    test_authorize_succeeds_for_referrer_with_rlistings         OK  0.00\n    test_authorize_succeeds_for_reseller_admin                  OK  0.00\n    test_authorize_succeeds_for_tenant_user_in_roles            OK  0.00\n    test_authorize_succeeds_for_user_role_in_roles              OK  0.00\nUtilsTestCase\n    test_auth_str_equal                                         OK  0.00\n    test_hash                                                   OK  0.01\n    test_hash_edge_cases                                        OK  0.00\n    test_hash_long_password                                     OK  0.36\n    test_hash_unicode                                           OK  0.01\n    test_isotime                                                OK  0.00\nVersionTestCase\n    test_admin_versions                                         OK  0.07\n    test_public_versions                                        OK  0.06\nApplicationTest\n    test_query_string_available                                 OK  0.00\n    test_response_content_type                                  OK  0.00\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_backend_sql.py\",> line 19, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_import_legacy.py\",> line 24, in <module>\n    from keystone.common.sql import legacy\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/legacy.py\",> line 23, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_keystoneclient_sql.py\",> line 21, in <module>\n    from keystone.common.sql import util as sql_util\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/util.py\",> line 20, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n======================================================================\nERROR: Failure: ImportError (cannot import name exceptions)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/tests/test_migrate_nova_auth.py\",> line 19, in <module>\n    from keystone.common.sql import nova\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/nova.py\",> line 22, in <module>\n    from keystone.contrib.ec2.backends import sql as ec2_sql\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/contrib/ec2/backends/sql.py\",> line 18, in <module>\n    from keystone.common.sql import migration\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/keystone/common/sql/migration.py\",> line 24, in <module>\n    from migrate.versioning import api as versioning_api\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/api.py\",> line 33, in <module>\n    from migrate.versioning import (repository, schema, version,\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python27-stable-essex/ws/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py\",> line 10, in <module>\n    from sqlalchemy import exceptions as sa_exceptions\nImportError: cannot import name exceptions\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 324 tests in 20.038s\n\nFAILED (SKIP=11, errors=4)\nSlowest 5 tests took 7.22 secs:\n    2.36       test_admin_requires_adminness (test_keystoneclient.KcEssex3TestCase)\n    2.34       test_admin_requires_adminness (test_keystoneclient.KcMasterTestCase)\n    1.09       test_token_expiry_maintained (test_keystoneclient.KcEssex3TestCase)\n    1.07       test_token_expiry_maintained (test_keystoneclient.KcMasterTestCase)\n    0.36       test_hash_long_password (test_utils.UtilsTestCase)\nERROR: InvocationError: \'/bin/bash run_tests.sh -N --no-pep8\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.8.0b1\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\nWebTest==1.4.0\nargparse==1.2.1\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\ngreenlet==0.4.0\nhttplib2==0.7.6\niso8601==0.1.4\nkeystone==2012.1.4\nlogilab-astng==0.24.1\nlogilab-common==0.58.1\nlxml==3.0.1\nmox==0.5.3\nnetifaces==0.8\nnose==1.2.1\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npam==0.1.4\npasslib==1.6.1\npep8==1.0.1\nprettytable==0.6.1\npylint==0.26.0\n-e git+https://github.com/openstack/python-keystoneclient.git at f617b09874046a0f56f6342638cc8444ed719022#egg=python_keystoneclient-dev\npython-ldap==2.3.13\npython-memcached==1.48\nrepoze.lru==0.6\nsimplejson==2.6.2\nsqlalchemy-migrate==0.7.2\n-e git+https://github.com/openstack/swift.git at 53ab2e150df92f6780819b7e66eb4c71688bd154#egg=swift-dev\ntermcolor==1.1.0\nunittest2==0.5.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python27-stable-essex/91\n[SCP] Copying console log.\n\n\n','<1674110771.44.1352678759921.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<178230132.2976405.1395865316031.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 16:21:56',-14400,'2014-03-26 20:21:56',NULL,'[openstack-dev] [Ironic][Keystone] Move drivers credentials\n	to	Keystone','\n\n----- Original Message -----\n> On 27 March 2014 06:28, Eoghan Glynn <eglynn at redhat.com> wrote:\n> >\n> >\n> >> On 3/25/2014 1:50 PM, Matt Wagner wrote:\n> >> > This would argue to me that the easiest thing for Ceilometer might be\n> >> > to query us for IPMI stats, if the credential store is pluggable.\n> >> > \"Fetch these bare metal statistics\" doesn\'t seem too off-course for\n> >> > Ironic to me. The alternative is that Ceilometer and Ironic would both\n> >> > have to be configured for the same pluggable credential store.\n> >>\n> >> There is already a blueprint with a proposed patch here for Ironic to do\n> >> the querying:\n> >> https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer.\n> >\n> > Yes, so I guess there are two fundamentally different approaches that\n> > could be taken here:\n> >\n> > 1. ironic controls the cadence of IPMI polling, emitting notifications\n> >    at whatever frequency it decides, carrying whatever level of\n> >    detail/formatting it deems appropriate, which are then consumed by\n> >    ceilometer which massages these provided data into usable samples\n> >\n> > 2. ceilometer acquires the IPMI credentials either via ironic or\n> >    directly from keystone/barbican, before calling out over IPMI at\n> >    whatever cadence it wants and transforming these raw data into\n> >    usable samples\n> >\n> > IIUC approach #1 is envisaged by the ironic BP[1].\n> >\n> > The advantage of approach #2 OTOH is that ceilometer is in the driving\n> > seat as far as cadence is concerned, and the model is far more\n> > consistent with how we currently acquire data from the hypervisor layer\n> > and SNMP daemons.\n> \n> The downsides of #2 are:\n>  - more machines require access to IPMI on the servers (if a given\n> ceilometer is part of the deployed cloud, not part of the minimal\n> deployment infrastructure). This sets of security red flags in some\n> organisations.\n>  - multiple machines (ceilometer *and* Ironic) talking to the same\n> IPMI device. IPMI has a limit on sessions, and in fact the controllers\n> are notoriously buggy - having multiple machines talking to one IPMI\n> device is a great way to exceed session limits and cause lockups.\n> \n> These seem fundamental showstoppers to me.\n\nThanks Robert, that\'s really useful information, and I agree a\ncompelling argument to invert control in this case.\n\nCheers,\nEoghan\n\n\n\n','<CAJ3HoZ1agshsiHY9ox7N3yjXJ+oW1Q67vqrmn5bi7h_VtiRpGw@mail.gmail.com>',NULL),('<1783375126.4.1380350191802.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-28 06:36:31',0,'2013-09-28 06:36:31',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-postgres-stable-grizzly #26','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-postgres-stable-grizzly/26/>\n\n\n\n','<1286206424.32.1380175895060.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1784049950.10.1387260534208.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-17 06:08:54',0,'2013-12-17 06:08:54',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-horizon-docs-havana #7','See <https://jenkins01.openstack.org/job/periodic-horizon-docs-havana/7/changes>\n\n\n\n','<2008885579.76.1386828239724.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1784094596.2648732.1397056070776.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-09 11:07:50',-14400,'2014-04-09 15:07:50',NULL,'[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live\n migration with one nova compute','----- Original Message -----\n> I\'m not writing off vCenter or its capabilities. I am arguing that the\n> bar for modifying a fundamental design decision in Nova -- that of being\n> horizontally scalable by having a single nova-compute worker responsible\n> for managing a single provider of compute resources -- was WAY too low,\n> and that this decision should be revisited in the future (and possibly\n> as part of the vmware driver refactoring efforts currently underway by\n> the good folks at RH and VMWare).\n\n+1, This is my main concern about having more than one ESX cluster under a single nova-compute agent as well. Currently it works, but it doesn\'t seem particularly advisable as on face value as such an architecture seems to break a number of the Nova design guidelines around high availability and fault tolerance. To me it seems like such an architecture effectively elevates nova-compute into being part of the control plane where it needs to have high availability (when discussing on IRC yesterday it seemed like this *may* be possible today but more testing is required to shake out any bugs).\n\nNow may well be the right approach *is* to make some changes to these expectations about Nova, but I think it\'s disingenuous to suggest that what is being suggested here isn\'t a significant re-architecting to resolve issues resulting from earlier hacks that allowed this functionality to work in the first place. Should be an interesting summit session.\n\n-Steve\n\n\n','<1397048702.2954.14.camel@sleepy>',NULL),('<1784285467.26.1374043635781.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-07-17 06:47:15',0,'2013-07-17 06:47:15',NULL,'[openstack-qa] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-all #37','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-all/37/>\n\n\n\n','<34478993.19.1373957168816.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1784D9D4-E45D-4C0A-BD20-6CC1DAE39767@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-09-05 20:14:39',0,'2012-09-05 20:14:39',NULL,'[openstack-dev] [Openstack] Quantum vs. Nova-network in Folsom','On Sep 5, 2012, at 2:25 PM, Chris Wright wrote:\n> * Dan Wendlandt (dan at nicira.com) wrote:\n>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes at gmail.com> wrote:\n>>> late to the party... but I\'ll dabble.\n>>> \n>>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw at sous-sol.org> wrote:\n>>>> * Rob_Hirschfeld at Dell.com (Rob_Hirschfeld at Dell.com) wrote:\n>>>>> We\'ve been discussing using Open vSwitch as the basis for non-Quantum Nova Networking deployments in Folsom.  While not Quantum, it feels like we\'re bringing Nova Networking a step closer to some of the core technologies that Quantum uses.\n>>>> \n>>>> To what end?\n>>> \n>>> OVS provides much more robust monitoring and operational facilities\n>>> (e.g sFlow monitoring, better switch table visibility etc).\n>> \n>> You won\'t find any disagreement from me about OVS having more advanced\n>> capabilities :)\n>> \n>>> It also provides a linux-bridge compatibility layer (ovs-brcompatd\n>>> [1]), which should work out-of-box with the linux-bridge. As such,\n>>> switching to using OVS rather than the linux bridge could be done\n>>> without any code changes to nova, just deployment changes (e.g. ensure\n>>> that ovs-brcompatd is running to intercept brctl ioctl\'s - [2]).\n>> \n>> Using ovs-brcompatd would be possible, though some distros do not\n>> package and run it by default and in general it is not the \"preferred\"\n>> way to run things according to email on the OVS mailing list.\n> \n> Indeed.  While it\'s doable, it\'s not something that will hit upstream\n> Linux, and therefore will not be supported by some distros.\n> \n> But, in general...while adding OVS support to nova networking (in the\n> simplest layer 2 switch mode), may not be much work.  It\'s adding a (not\n> particularly useful) feature to a code base that we hope to deprecate.\n> And making it more useful (adding things like tunnelling) support are\n> really the point of Quantum.\n> \nI think that\'s what this really boils down to: The entire point of Quantum was to\nadd feature-rich networking as it\'s own service to OpenStack. Hedging by\nadding piecemeal features to nova-net at this point may seem ok, but it\'s\na slippery slope, and may end up duplicating work which has already happened\nin Quantum.\n\nThanks,\nKyle\n\n> thanks,\n> -chris\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20120905192514.GT4538@sequoia.sous-sol.org>',NULL),('<1784D9D4-E45D-4C0A-BD20-6CC1DAE39767@cisco.com>','http://lists.openstack.org/pipermail/openstack-operators',NULL,'2012-09-05 20:14:39',0,'2012-09-05 20:14:39',NULL,'[Openstack-operators] [openstack-dev] [Openstack] Quantum vs.\n	Nova-network in Folsom','On Sep 5, 2012, at 2:25 PM, Chris Wright wrote:\n> * Dan Wendlandt (dan at nicira.com) wrote:\n>> On Wed, Sep 5, 2012 at 5:23 AM, andi abes <andi.abes at gmail.com> wrote:\n>>> late to the party... but I\'ll dabble.\n>>> \n>>> On Mon, Aug 27, 2012 at 12:21 PM, Chris Wright <chrisw at sous-sol.org> wrote:\n>>>> * Rob_Hirschfeld at Dell.com (Rob_Hirschfeld at Dell.com) wrote:\n>>>>> We\'ve been discussing using Open vSwitch as the basis for non-Quantum Nova Networking deployments in Folsom.  While not Quantum, it feels like we\'re bringing Nova Networking a step closer to some of the core technologies that Quantum uses.\n>>>> \n>>>> To what end?\n>>> \n>>> OVS provides much more robust monitoring and operational facilities\n>>> (e.g sFlow monitoring, better switch table visibility etc).\n>> \n>> You won\'t find any disagreement from me about OVS having more advanced\n>> capabilities :)\n>> \n>>> It also provides a linux-bridge compatibility layer (ovs-brcompatd\n>>> [1]), which should work out-of-box with the linux-bridge. As such,\n>>> switching to using OVS rather than the linux bridge could be done\n>>> without any code changes to nova, just deployment changes (e.g. ensure\n>>> that ovs-brcompatd is running to intercept brctl ioctl\'s - [2]).\n>> \n>> Using ovs-brcompatd would be possible, though some distros do not\n>> package and run it by default and in general it is not the \"preferred\"\n>> way to run things according to email on the OVS mailing list.\n> \n> Indeed.  While it\'s doable, it\'s not something that will hit upstream\n> Linux, and therefore will not be supported by some distros.\n> \n> But, in general...while adding OVS support to nova networking (in the\n> simplest layer 2 switch mode), may not be much work.  It\'s adding a (not\n> particularly useful) feature to a code base that we hope to deprecate.\n> And making it more useful (adding things like tunnelling) support are\n> really the point of Quantum.\n> \nI think that\'s what this really boils down to: The entire point of Quantum was to\nadd feature-rich networking as it\'s own service to OpenStack. Hedging by\nadding piecemeal features to nova-net at this point may seem ok, but it\'s\na slippery slope, and may end up duplicating work which has already happened\nin Quantum.\n\nThanks,\nKyle\n\n> thanks,\n> -chris\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n\n','<20120905192514.GT4538@sequoia.sous-sol.org>',NULL),('<1786623546.117.1367907724038.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-07 06:22:04',0,'2013-05-07 06:22:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly #27','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/27/>\n\n------------------------------------------\n[...truncated 1330 lines...]\n    test_create_endpoint_400                                     OK    1.95\n    test_create_endpoint_on_v2                                   OK    2.83\n    test_create_service                                          OK    2.00\n    test_delete_endpoint                                         OK    3.02\n    test_delete_service                                          OK    2.01\n    test_get_endpoint                                            OK    2.15\n    test_get_service                                             OK    2.04\n    test_list_endpoints                                          OK    2.04\n    test_list_endpoints_xml                                      OK    3.08\n    test_list_services                                           OK    2.07\n    test_list_services_xml                                       OK    2.15\n    test_update_endpoint                                         OK    1.94\n    test_update_service                                          OK    1.89\nIdentityTestCase\n    test_add_user_to_group                                       OK    2.03\n    test_check_user_in_group                                     OK    3.57\n    test_create_credential                                       OK    1.98\n    test_create_domain                                           OK    2.37\n    test_create_group                                            OK    2.02\n    test_create_project                                          OK    2.12\n    test_create_role                                             OK    2.19\n    test_create_user                                             OK    3.28\n    test_crud_group_domain_role_grants                           OK    3.85\n    test_crud_group_project_role_grants                          OK    3.65\n    test_crud_user_domain_role_grants                            OK    3.36\n    test_crud_user_project_role_grants                           OK    3.74\n    test_delete_credential                                       OK    1.94\n    test_delete_domain                                           OK    2.56\n    test_delete_enabled_domain_fails                             OK    1.84\n    test_delete_group                                            OK    1.73\n    test_delete_project                                          OK    2.00\n    test_delete_role                                             OK    3.10\n    test_delete_user                                             OK    3.58\n    test_disable_domain                                          OK    3.88\n    test_get_credential                                          OK    2.02\n    test_get_domain                                              OK    2.10\n    test_get_group                                               OK    3.08\n    test_get_project                                             OK    1.93\n    test_get_role                                                OK    2.19\n    test_get_user                                                OK    1.92\n    test_list_credentials                                        OK    2.13\n    test_list_credentials_xml                                    OK    2.17\n    test_list_domains                                            OK    3.35\n    test_list_domains_xml                                        OK    2.19\n    test_list_groups                                             OK    2.03\n    test_list_groups_xml                                         OK    1.89\n    test_list_projects                                           OK    2.07\n    test_list_projects_xml                                       OK    2.09\n    test_list_roles                                              OK    3.38\n    test_list_roles_xml                                          OK    2.08\n    test_list_users                                              OK    2.07\n    test_list_users_in_group                                     OK    2.41\n    test_list_users_xml                                          OK    2.00\n    test_remove_user_from_group                                  OK    3.39\n    test_update_credential                                       OK    2.03\n    test_update_domain                                           OK    1.98\n    test_update_group                                            OK    1.95\n    test_update_project                                          OK    2.02\n    test_update_role                                             OK    1.95\n    test_update_user                                             OK    3.16\nPolicyTestCase\n    test_create_policy                                           OK    2.07\n    test_delete_policy                                           OK    2.10\n    test_get_policy                                              OK    2.08\n    test_list_policies                                           OK    2.01\n    test_list_policies_xml                                       OK    1.96\n    test_update_policy                                           OK    3.10\nIdentityTestProtectedCase\n    test_get_user_protected_match_id                             OK    1.99\n    test_list_filtered_domains                                   OK    2.68\n    test_list_groups_protected_by_domain                         OK    2.39\n    test_list_groups_protected_by_domain_and_filtered            OK    2.08\n    test_list_users_filtered_by_domain                           OK    2.27\n    test_list_users_protected_by_domain                          OK    3.52\n    test_list_users_unprotected                                  OK    2.05\n    test_multiple_filters                                        OK    2.10\nVersionTestCase\n    test_admin_version_v2                                        OK    0.17\n    test_admin_version_v3                                        OK    0.13\n    test_admin_versions                                          OK    0.11\n    test_public_version_v2                                       OK    0.11\n    test_public_version_v3                                       OK    0.14\n    test_public_versions                                         OK    1.10\nApplicationTest\n    test_query_string_available                                  OK    0.01\n    test_render_response                                         OK    0.01\n    test_render_response_custom_headers                          OK    0.01\n    test_render_response_custom_status                           OK    0.01\n    test_render_response_no_body                                 OK    0.01\n    test_response_content_type                                   OK    0.01\n\n======================================================================\nERROR: Make sure both public and admin API work with ipv6.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_ipv6.py\",> line 43, in test_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 30.27 secs:\n    9.13    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.83    TestTokenRevoking.test_group_membership_changes_revokes_token\n    5.06    TestTrustAuth.test_list_trusts\n    4.93    TestTrustAuth.test_trust_crud\n    4.32    TestTokenRevoking.test_creating_user_grant_revokes_token\n----------------------------------------------------------------------\nRan 1272 tests in 658.431s\n\nFAILED (SKIP=82, errors=3)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.27\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.51\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=68\n+ \'[\' 68 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.MIZDGqanA2\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/27\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly/27/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1830593282.85.1367821389660.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<178701082.42.1381385404601.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-10 06:10:04',0,'2013-10-10 06:10:04',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-tempest-devstack-vm-neutron-stable-grizzly #38','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/38/>\n\n------------------------------------------\n[...truncated 14122 lines...]\n2013-10-10 06:09:26 writing manifest file \'tempest.egg-info/SOURCES.txt\'\n2013-10-10 06:09:26 +++ awk \'/^.+/ {print \"-f \" $1}\' tempest.egg-info/dependency_links.txt\n2013-10-10 06:09:26 ++ raw_links=\n2013-10-10 06:09:26 +++ echo\n2013-10-10 06:09:26 +++ xargs\n2013-10-10 06:09:26 ++ depend_links=\n2013-10-10 06:09:26 +++ \'[\' \'!\' -r tempest.egg-info/requires.txt \']\'\n2013-10-10 06:09:26 +++ echo \'-r *-info/requires.txt\'\n2013-10-10 06:09:26 ++ require_file=\'-r *-info/requires.txt\'\n2013-10-10 06:09:26 ++ pip_install -r tempest.egg-info/requires.txt\n2013-10-10 06:09:26 ++ [[ False = \\T\\r\\u\\e ]]\n2013-10-10 06:09:26 ++ [[ -z -r tempest.egg-info/requires.txt ]]\n2013-10-10 06:09:26 ++ [[ -z deb ]]\n2013-10-10 06:09:26 ++ [[ False = True ]]\n2013-10-10 06:09:26 ++ SUDO_PIP=sudo\n2013-10-10 06:09:26 +++ get_pip_command\n2013-10-10 06:09:26 +++ is_fedora\n2013-10-10 06:09:26 +++ [[ -z Ubuntu ]]\n2013-10-10 06:09:26 +++ \'[\' Ubuntu = Fedora \']\'\n2013-10-10 06:09:26 +++ \'[\' Ubuntu = \'Red Hat\' \']\'\n2013-10-10 06:09:26 +++ \'[\' Ubuntu = CentOS \']\'\n2013-10-10 06:09:26 +++ which pip\n2013-10-10 06:09:26 ++ CMD_PIP=/usr/local/bin/pip\n2013-10-10 06:09:26 ++ [[ False != \\F\\a\\l\\s\\e ]]\n2013-10-10 06:09:26 ++ sudo PIP_DOWNLOAD_CACHE=/var/cache/pip HTTP_PROXY= HTTPS_PROXY= NO_PROXY= /usr/local/bin/pip install -r tempest.egg-info/requires.txt\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): anyjson in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 1))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): nose in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 2))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): httplib2>=0.7.0 in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 3))\n2013-10-10 06:09:26 Downloading/unpacking testtools>=0.9.29 (from -r tempest.egg-info/requires.txt (line 4))\n2013-10-10 06:09:26   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Ftesttools%2Ftesttools-0.9.32.tar.gz\n2013-10-10 06:09:26   Running setup.py egg_info for package testtools\n2013-10-10 06:09:26     \n2013-10-10 06:09:26     no previously-included directories found matching \'doc/_build\'\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): lxml in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 5))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): boto>=2.2.1 in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 6))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): paramiko in /usr/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 7))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): netaddr in /usr/local/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 8))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): python-glanceclient>=0.5.0 in /opt/stack/new/python-glanceclient (from -r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): python-keystoneclient>=0.2.0 in /opt/stack/new/python-keystoneclient (from -r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): python-novaclient>=2.10.0 in /opt/stack/new/python-novaclient (from -r tempest.egg-info/requires.txt (line 11))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): python-quantumclient>=2.1 in /usr/local/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 12))\n2013-10-10 06:09:26 Downloading/unpacking testresources (from -r tempest.egg-info/requires.txt (line 13))\n2013-10-10 06:09:26   Downloading testresources-0.2.7.tar.gz\n2013-10-10 06:09:26   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Ftestresources%2Ftestresources-0.2.7.tar.gz\n2013-10-10 06:09:26   Running setup.py egg_info for package testresources\n2013-10-10 06:09:26     \n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): keyring in /usr/local/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 14))\n2013-10-10 06:09:26 Downloading/unpacking testrepository (from -r tempest.egg-info/requires.txt (line 15))\n2013-10-10 06:09:26   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Ftestrepository%2Ftestrepository-0.0.17.tar.gz\n2013-10-10 06:09:26   Running setup.py egg_info for package testrepository\n2013-10-10 06:09:26     \n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): oslo.config>=1.1.0 in /usr/local/lib/python2.7/dist-packages (from -r tempest.egg-info/requires.txt (line 16))\n2013-10-10 06:09:26 Downloading/unpacking extras (from testtools>=0.9.29->-r tempest.egg-info/requires.txt (line 4))\n2013-10-10 06:09:26   Downloading extras-0.0.3.tar.gz\n2013-10-10 06:09:26   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fextras%2Fextras-0.0.3.tar.gz\n2013-10-10 06:09:26   Running setup.py egg_info for package extras\n2013-10-10 06:09:26     \n2013-10-10 06:09:26 Downloading/unpacking python-mimeparse (from testtools>=0.9.29->-r tempest.egg-info/requires.txt (line 4))\n2013-10-10 06:09:26   Downloading python-mimeparse-0.1.4.tar.gz\n2013-10-10 06:09:26   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-mimeparse%2Fpython-mimeparse-0.1.4.tar.gz\n2013-10-10 06:09:26   Running setup.py egg_info for package python-mimeparse\n2013-10-10 06:09:26     \n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): pbr>=0.5.21,<1.0 in /usr/local/lib/python2.7/dist-packages/pbr-0.5.21-py2.7.egg (from python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): PrettyTable>=0.6,<0.8 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): pyOpenSSL in /usr/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): warlock>=1.0.1,<2 in /usr/local/lib/python2.7/dist-packages (from python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): iso8601>=0.1.4 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): requests>=1.1 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): simplejson>=2.0.9 in /usr/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): six in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:26 Requirement already satisfied (use --upgrade to upgrade): Babel>=0.9.6 in /usr/local/lib/python2.7/dist-packages (from python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): python-neutronclient>=2.3.0,<3 in /opt/stack/new/python-neutronclient (from python-quantumclient>=2.1->-r tempest.egg-info/requires.txt (line 12))\n2013-10-10 06:09:29 Downloading/unpacking fixtures (from testrepository->-r tempest.egg-info/requires.txt (line 15))\n2013-10-10 06:09:29   Downloading fixtures-0.3.14.tar.gz\n2013-10-10 06:09:29   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Ffixtures%2Ffixtures-0.3.14.tar.gz\n2013-10-10 06:09:29   Running setup.py egg_info for package fixtures\n2013-10-10 06:09:29     \n2013-10-10 06:09:29 Downloading/unpacking python-subunit>=0.0.10 (from testrepository->-r tempest.egg-info/requires.txt (line 15))\n2013-10-10 06:09:29   Storing download in cache at /var/cache/pip/http%3A%2F%2Fpypi.openstack.org%2Fopenstack%2Fpython-subunit%2Fpython-subunit-0.0.15.tar.gz\n2013-10-10 06:09:29   Running setup.py egg_info for package python-subunit\n2013-10-10 06:09:29     \n2013-10-10 06:09:29     warning: no previously-included files found matching \'.bzrignore\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'aclocal.m4\'\n2013-10-10 06:09:29     no previously-included directories found matching \'autom4te.cache\'\n2013-10-10 06:09:29     no previously-included directories found matching \'c\'\n2013-10-10 06:09:29     no previously-included directories found matching \'c++\'\n2013-10-10 06:09:29     no previously-included directories found matching \'compile\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'configure*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'depcomp\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'INSTALL\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'install-sh\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'lib*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'ltmain.sh\'\n2013-10-10 06:09:29     no previously-included directories found matching \'m4\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'Makefile*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'missing\'\n2013-10-10 06:09:29     no previously-included directories found matching \'perl\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'py-compile\'\n2013-10-10 06:09:29     no previously-included directories found matching \'shell\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'stamp-h1\'\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): pip>=1.0 in /usr/lib/python2.7/dist-packages (from pbr>=0.5.21,<1.0->python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): jsonschema>=0.7,<3 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): jsonpatch>=0.10,<2 in /usr/local/lib/python2.7/dist-packages (from warlock>=1.0.1,<2->python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): pytz>=0a in /usr/local/lib/python2.7/dist-packages (from Babel>=0.9.6->python-keystoneclient>=0.2.0->-r tempest.egg-info/requires.txt (line 10))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): cliff>=1.4.3 in /usr/local/lib/python2.7/dist-packages (from python-neutronclient>=2.3.0,<3->python-quantumclient>=2.1->-r tempest.egg-info/requires.txt (line 12))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): jsonpointer>=1.0 in /usr/local/lib/python2.7/dist-packages (from jsonpatch>=0.10,<2->warlock>=1.0.1,<2->python-glanceclient>=0.5.0->-r tempest.egg-info/requires.txt (line 9))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): pyparsing>=2.0.1 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.1->-r tempest.egg-info/requires.txt (line 12))\n2013-10-10 06:09:29 Requirement already satisfied (use --upgrade to upgrade): cmd2>=0.6.7 in /usr/local/lib/python2.7/dist-packages (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->python-quantumclient>=2.1->-r tempest.egg-info/requires.txt (line 12))\n2013-10-10 06:09:29 Installing collected packages: testtools, testresources, testrepository, extras, python-mimeparse, fixtures, python-subunit\n2013-10-10 06:09:29   Running setup.py install for testtools\n2013-10-10 06:09:29     \n2013-10-10 06:09:29     no previously-included directories found matching \'doc/_build\'\n2013-10-10 06:09:29   Running setup.py install for testresources\n2013-10-10 06:09:29     \n2013-10-10 06:09:29   Running setup.py install for testrepository\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/testr from 644 to 755\n2013-10-10 06:09:29     \n2013-10-10 06:09:29     changing mode of /usr/local/bin/testr to 755\n2013-10-10 06:09:29   Running setup.py install for extras\n2013-10-10 06:09:29     \n2013-10-10 06:09:29   Running setup.py install for python-mimeparse\n2013-10-10 06:09:29     \n2013-10-10 06:09:29   Running setup.py install for fixtures\n2013-10-10 06:09:29     \n2013-10-10 06:09:29   Running setup.py install for python-subunit\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-1to2 from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-2to1 from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit2gtk from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit2junitxml from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit2pyunit from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-filter from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-ls from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-notify from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-stats from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/subunit-tags from 644 to 755\n2013-10-10 06:09:29     changing mode of build/scripts-2.7/tap2subunit from 644 to 755\n2013-10-10 06:09:29     \n2013-10-10 06:09:29     warning: no previously-included files found matching \'.bzrignore\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'aclocal.m4\'\n2013-10-10 06:09:29     no previously-included directories found matching \'autom4te.cache\'\n2013-10-10 06:09:29     no previously-included directories found matching \'c\'\n2013-10-10 06:09:29     no previously-included directories found matching \'c++\'\n2013-10-10 06:09:29     no previously-included directories found matching \'compile\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'configure*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'depcomp\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'INSTALL\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'install-sh\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'lib*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'ltmain.sh\'\n2013-10-10 06:09:29     no previously-included directories found matching \'m4\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'Makefile*\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'missing\'\n2013-10-10 06:09:29     no previously-included directories found matching \'perl\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'py-compile\'\n2013-10-10 06:09:29     no previously-included directories found matching \'shell\'\n2013-10-10 06:09:29     warning: no previously-included files found matching \'stamp-h1\'\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-ls to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-tags to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-filter to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/tap2subunit to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit2pyunit to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-2to1 to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-1to2 to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-notify to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit2gtk to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit2junitxml to 755\n2013-10-10 06:09:29     changing mode of /usr/local/bin/subunit-stats to 755\n2013-10-10 06:09:29 Successfully installed testtools testresources testrepository extras python-mimeparse fixtures python-subunit\n2013-10-10 06:09:29 Cleaning up...\n2013-10-10 06:09:29 ++ sudo HTTP_PROXY= HTTPS_PROXY= NO_PROXY= python setup.py develop\n2013-10-10 06:09:29 running develop\n2013-10-10 06:09:29 Checking .pth file support in /usr/local/lib/python2.7/dist-packages/\n2013-10-10 06:09:29 /usr/bin/python -E -c pass\n2013-10-10 06:09:29 TEST PASSED: /usr/local/lib/python2.7/dist-packages/ appears to support .pth files\n2013-10-10 06:09:29 running egg_info\n2013-10-10 06:09:29 writing requirements to tempest.egg-info/requires.txt\n2013-10-10 06:09:29 writing tempest.egg-info/PKG-INFO\n2013-10-10 06:09:29 writing top-level names to tempest.egg-info/top_level.txt\n2013-10-10 06:09:29 writing dependency_links to tempest.egg-info/dependency_links.txt\n2013-10-10 06:09:29 reading manifest template \'MANIFEST.in\'\n2013-10-10 06:09:29 warning: no files found matching \'AUTHORS\'\n2013-10-10 06:09:29 warning: no files found matching \'ChangeLog\'\n2013-10-10 06:09:29 warning: no previously-included files matching \'*.pyc\' found anywhere in distribution\n2013-10-10 06:09:29 writing manifest file \'tempest.egg-info/SOURCES.txt\'\n2013-10-10 06:09:29 running build_ext\n2013-10-10 06:09:29 Creating /usr/local/lib/python2.7/dist-packages/tempest.egg-link (link to .)\n2013-10-10 06:09:29 Adding tempest 2013.1.a972.g2c3bbea to easy-install.pth file\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-566557-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az3-566557.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-q-agt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-q-dhcp.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-q-l3.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-q-meta.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-q-svc.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/50_stack_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.d/quantum-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-neutron-stable-grizzly/devstack-precise-hpcloud-az3-566557/38/logs/sysstat.dat.gz\'\n[SCP] No file(s) found: **/testr_results.html.gz\n[SCP] \'**/testr_results.html.gz\' doesn\'t match anything: \'**\' exists but not \'**/testr_results.html.gz\'\n[SCP] No file(s) found: **/subunit_log.txt.gz\n[SCP] \'**/subunit_log.txt.gz\' doesn\'t match anything: \'**\' exists but not \'**/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL);
INSERT INTO `messages` VALUES ('<1787530053.31.1357436014873.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-01-06 01:33:34',0,'2013-01-06 01:33:34',NULL,'[openstack-qa] Build failed in Jenkins:\n	periodic-tempest-devstack-vm-full #66','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-full/66/>\n\n------------------------------------------\n[...truncated 15257 lines...]\ndate: Sun, 06 Jan 2013 01:28:49 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-94081a33-4e04-4d0d-9d60-17a119bf2961\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/d333db8b-17c1-45a0-a1c7-5d84a97d7c28\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:51 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-7dd19d97-d61e-4ea3-a612-0a9a17bff70b\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f714d37f-eec2-4f72-8cee-825badadb069\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:52 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-b61019a2-0f06-4aa7-aae5-58d5c736b236\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/7eadc2e6-90ae-4e0a-95e0-c9c0cd51ab29\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:54 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-f5f1e481-29b0-4f68-90fb-134d31bf3ac0\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/18405dae-73f3-4e05-8dc8-5465c803b581\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:55 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-b7f3ef25-44a2-42d3-a39a-fc88fc2e2396\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/88c9d36f-5cb2-4cde-a12e-77dae22458e2\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:56 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-761872da-2359-4afc-9b79-85f51a40319a\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/f5f752a1-ab7a-4fce-8641-614e6f24782d\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:58 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-d2112d61-3b6b-4a0f-a373-7decec352a52\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/011c944d-2a5f-4c4e-b98b-edb5db30a460\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:28:59 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-a663cfa5-d616-4f91-b638-913a368057e2\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/66a33273-5db5-49c4-997e-71db6cbcf79d\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:29:00 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-9aa35033-1b58-429a-bd03-cef440198a53\n\nnull\n\nglanceclient.common.http: DEBUG: curl -i -X DELETE -H \'X-Auth-Token: MIILtQYJKoZIhvcNAQcCoIILpjCCC6ICAQExCTAHBgUrDgMCGjCCCo4GCSqGSIb3DQEHAaCCCn8Eggp7eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxMy0wMS0wNlQwMToyNzo0MS40MDg2NTciLCAiZXhwaXJlcyI6ICIyMDEzLTAxLTA3VDAxOjI3OjQxWiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImVuYWJsZWQiOiB0cnVlLCAiZGVzY3JpcHRpb24iOiBudWxsLCAibmFtZSI6ICJkZW1vIiwgImlkIjogIjEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In19LCAic2VydmljZUNhdGFsb2ciOiBbeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjg3NzQvdjIvMTI3ZjhjZGNiNTlkNDMzN2E4ZTY2MDJmNjY5NzVjNTUiLCAiaWQiOiAiMTM2NjhkYWRkNTA4NDgwZjhjNjdjYzU3Y2FhMTMyYzAiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3NC92Mi8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJjb21wdXRlIiwgIm5hbWUiOiAibm92YSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzMzMyIsICJpZCI6ICIwY2FjNmIwYTZkYmM0OTFmOGQxNmZjMmJiNTBiODBjMiIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTozMzMzIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAiczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjkyOTIiLCAiaWQiOiAiMjBmZjE0ZmM3NzE4NDY1NWI2OGVmYzg4YzJlZWRjN2UiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3Ni92MS8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSIsICJpZCI6ICI0NjMxMWQxMDAwMTQ0MTcyOTQ3NDNlNjI5NDY4MDAxYSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4Nzc2L3YxLzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9BZG1pbiIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODc3My9zZXJ2aWNlcy9DbG91ZCIsICJpZCI6ICI0ZjQ3YTI1MmU2OTg0OGU4YWVhOWEwNTRhMGM2MTM3YSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEyNy4wLjAuMTo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogImVjMiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6ODA4MC92MS9BVVRIXzEyN2Y4Y2RjYjU5ZDQzMzdhOGU2NjAyZjY2OTc1YzU1IiwgImlkIjogIjQ4YWVhODgxY2MxODQ1NzNhMjk1MjI4YzQ0ZGI0ZDVmIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjgwODAvdjEvQVVUSF8xMjdmOGNkY2I1OWQ0MzM3YThlNjYwMmY2Njk3NWM1NSJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHA6Ly8xMjcuMC4wLjE6NTAwMC92Mi4wIiwgImlkIjogIjA5MmIwZDkzNzExOTQ5ZTA5MzJkOThkMTZkMzZjN2NiIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTI3LjAuMC4xOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiZGVtbyIsICJyb2xlc19saW5rcyI6IFtdLCAiaWQiOiAiZjI1M2NiZTdjNTgyNDVkYWFlYzE2ODJjNzI4OWY1ZDUiLCAicm9sZXMiOiBbeyJuYW1lIjogIk1lbWJlciJ9LCB7Im5hbWUiOiAiYW5vdGhlcnJvbGUifV0sICJuYW1lIjogImRlbW8ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiOTYxMzdmZTEyNGNhNDVlZGE5OWI2YmZmYzMwZDE1OTQiLCAiYzU4ODUxZTA4YjM0NGJhNmJjNjUyYWFhYmQyNjYzODMiXX19fTGB-zCB-AIBATBcMFcxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVVbnNldDEOMAwGA1UEBxMFVW5zZXQxDjAMBgNVBAoTBVVuc2V0MRgwFgYDVQQDEw93d3cuZXhhbXBsZS5jb20CAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCKQv-nHpECSRsVFhTlA20B8oNFoGLJwpuQRt9D5-AzpjlG8rhGIp7prVXrKv2-6W1RRZxy2S8V9CZJ7D6+Gp1mZQMTvGCWzIfkpFMOPYafP3DPXh-aEuiU4eXTJUw6jLasJrOHf54uZA57lp4uD8Z-hXrtwcvoemW8qTwBn9STDw==\' -H \'Content-Type: application/octet-stream\' -H \'User-Agent: python-glanceclient\' http://127.0.0.1:9292/v1/images/85a3f5e3-31b7-4539-b655-d143b245d1ae\nglanceclient.common.http: DEBUG: \nHTTP/1.1 200 OK\ndate: Sun, 06 Jan 2013 01:29:02 GMT\ncontent-length: 4\ncontent-type: application/json; charset=UTF-8\nx-openstack-request-id: req-e0f7632d-c9e9-4023-8279-e71bb1091709\n\nnull\n\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): 127.0.0.1\nrequests.packages.urllib3.connectionpool: DEBUG: \"POST /v2.0/tokens HTTP/1.1\" 200 6537\n--------------------- >> end captured logging << ---------------------\ntest_create_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_delete_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_account_metadata (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_list_containers (tempest.tests.object_storage.test_account_services.AccountTest) ... ok\ntest_container_metadata (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_create_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_delete_container (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_list_container_contents_json (tempest.tests.object_storage.test_container_services.ContainerTest) ... ok\ntest_get_object_after_expiry_time (tempest.tests.object_storage.test_object_expiry.ObjectExpiryTest) ... SKIP: Until bug 1069849 is resolved.\ntest_access_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_access_public_container_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_2d_way (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_across_containers (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_in_same_container (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_copy_object_to_itself (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_create_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_delete_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_get_object (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_object_metadata (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_write_object_without_using_creds (tempest.tests.object_storage.test_object_services.ObjectTest) ... ok\ntest_versioned_container (tempest.tests.object_storage.test_object_version.ContainerTest) ... ok\ntest_create_get_delete_volume_with_volume_type_and_extra_specs (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_delete (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_create_get (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_list (tempest.tests.volume.admin.test_volume_types.VolumeTypesTest) ... ok\ntest_volume_type_extra_spec_create_delete (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_spec_create_get (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_list (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_volume_type_extra_specs_update (tempest.tests.volume.admin.test_volume_types_extra_specs.VolumeTypesExtraSpecsTest) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestJSON) ... ok\ntest_create_invalid_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_none_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090322 is fixed\ntest_create_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_delete_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_get_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_list_nonexistent_volume_type_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_multiple_extra_spec (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_no_body (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... SKIP: Until bug 1090320 is fixed\ntest_update_none_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_update_nonexistent_extra_spec_id (tempest.tests.volume.admin.test_volume_types_extra_specs_negative.ExtraSpecsNegativeTestXML) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestJSON) ... ok\ntest_create_with_empty_name (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... SKIP: Until bug 1090356 is fixed\ntest_create_with_nonexistent_volume_type (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_delete_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_get_nonexistent_type_id (tempest.tests.volume.admin.test_volume_types_negative.VolumesTypesNegativeTestXML) ... ok\ntest_attach_detach_volume_to_instance (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_get_volume_attachment (tempest.tests.volume.test_volumes_actions.VolumesActionsTest) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestJSON) ... ok\ntest_volume_create_get_delete (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_get_metadata_none (tempest.tests.volume.test_volumes_get.VolumesGetTestXML) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestJSON) ... ok\ntest_volume_list (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_volume_list_with_details (tempest.tests.volume.test_volumes_list.VolumeListTestXML) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestJSON) ... ok\ntest_create_volume_with_invalid_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_out_passing_size (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_create_volume_with_size_zero (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_delete_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_invalid_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_get_volume_without_passing_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_delete_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\ntest_volume_get_nonexistant_volume_id (tempest.tests.volume.test_volumes_negative.VolumesNegativeTestXML) ... ok\n\n======================================================================\nERROR: test_reboot_server_hard (tempest.tests.compute.servers.test_server_actions.ServerActionsTestXML)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_server_actions.py\", line 220, in setUp\n    ServerActionsTestBase.setUp(self)\n  File \"/opt/stack/new/tempest/tempest/tests/compute/servers/test_server_actions.py\", line 44, in setUp\n    self.client.wait_for_server_status(self.server_id, \'ACTIVE\')\n  File \"/opt/stack/new/tempest/tempest/services/compute/xml/servers_client.py\", line 193, in wait_for_server_status\n    raise exceptions.BuildErrorException(server_id=server_id)\nBuildErrorException: Server 7d2c8aeb-9b7d-4b18-b83c-0a61e8ce154e failed to build and is in ERROR status\n\n----------------------------------------------------------------------\nXML: nosetests-full.xml\n----------------------------------------------------------------------\nRan 583 tests in 3609.420s\n\nFAILED (SKIP=75, errors=1)\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/devstack-gate-cleanup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/devstack-gate-setup-host.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/devstack-gate-setup-workspace-new.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/devstacklog.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/iptables.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/kern_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/localrc.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/rabbitmq/rabbit at devstack-1357426872-sasl.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/rabbitmq/rabbit at devstack-1357426872.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/rabbitmq/startup_log.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-c-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-c-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-c-vol.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-g-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-g-reg.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-horizon.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-key.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-api.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-cond.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-cpu.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-crt.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-net.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-obj.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-n-sch.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/screen-swift.txt\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.d/README.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.d/cinder-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.d/jenkins-sudo-grep.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.d/nova-rootwrap.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/sudoers.txt\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-full/66/logs/syslog.txt\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1787561443.357.1367042603813.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-27 06:03:23',0,'2013-04-27 06:03:23',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-cinder-docs-stable-grizzly #17','See <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/17/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on quantal6 in workspace <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/>\nCheckout:periodic-cinder-docs-stable-grizzly / <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/> - hudson.remoting.Channel at 564389b7:quantal6\nUsing strategy: Default\nLast Built Revision: Revision 875e42ffbefebdb9fe8eb5595a269461cb7dd5d0 (origin/stable/grizzly)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/cinder.git\ngit --version\ngit version 1.7.10.4\nFetching upstream changes from git://github.com/openstack/cinder.git\nCommencing build of Revision 875e42ffbefebdb9fe8eb5595a269461cb7dd5d0 (origin/stable/grizzly)\nChecking out Revision 875e42ffbefebdb9fe8eb5595a269461cb7dd5d0 (origin/stable/grizzly)\n[periodic-cinder-docs-stable-grizzly] $ /bin/bash -xe /tmp/hudson8066905212195215808.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack cinder\n+ org=openstack\n+ project=cinder\n+ [[ -z openstack ]]\n+ [[ -z cinder ]]\n+ /usr/local/jenkins/slave_scripts/select-mirror.sh openstack cinder\n+ org=openstack\n+ project=cinder\n+ [[ -z openstack ]]\n+ [[ -z cinder ]]\n+ rm -f /home/jenkins/.pydistutils.cfg\n+ mkdir -p /home/jenkins/.pip\n+ rm -f /home/jenkins/.pip/pip.conf\n+ \'[\' openstack == openstack \']\'\n+ \'[\' cinder == requirements \']\'\n+ \'[\' openstack == openstack \']\'\n+ cat\n+ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/setup.py>\nvenv create: <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/test-requires>\nERROR: invocation failed, logfile: <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/.tox/venv/log/venv-1.log>\nERROR: actionid=venv\nmsg=getenv\ncmdargs=[local(\'<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/.tox/venv/bin/pip\'),> \'install\', \'-r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires\',> \'-r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/test-requires\']>\nenv={\'JENKINS_HOME\': \'/var/lib/jenkins\', \'PYTHONIOENCODING\': \'utf_8\', \'BUILD_CAUSE\': \'TIMERTRIGGER\', \'HUDSON_URL\': \'https://jenkins.openstack.org/\', \'BUILD_URL\': \'https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/17/\', \'BUILD_TAG\': \'jenkins-periodic-cinder-docs-stable-grizzly-17\', \'SSH_CLIENT\': \'198.101.231.203 55086 22\', \'JENKINS_URL\': \'https://jenkins.openstack.org/\', \'LOGNAME\': \'jenkins\', \'USER\': \'jenkins\', \'WORKSPACE\': \'<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/\',> \'HOME\': \'/home/jenkins\', \'PATH\': \'<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/.tox/venv/bin>:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games\', \'HUDSON_PUBLISH_DOCS\': \'1\', \'DEBFULLNAME\': \'OpenStack Hudson\', \'JOB_NAME\': \'periodic-cinder-docs-stable-grizzly\', \'LANG\': \'en_US.UTF-8\', \'VIRTUAL_ENV\': \'<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/.tox/venv\',> \'SHELL\': \'/bin/bash\', \'LANGUAGE\': \'en_US:en\', \'SHLVL\': \'3\', \'NOSE_OPENSTACK_RED\': \'0.05\', \'GIT_AUTHOR_EMAIL\': \'jenkins at openstack.org\', \'HUDSON_HOME\': \'/var/lib/jenkins\', \'NODE_LABELS\': \'quantal quantal6\', \'NOSE_OPENSTACK_YELLOW\': \'0.025\', \'NOSE_OPENSTACK_STDOUT\': \'1\', \'BUILD_CAUSE_TIMERTRIGGER\': \'true\', \'DEBEMAIL\': \'hudson at openstack.org\', \'BUILD_ID\': \'2013-04-27_06-01-26\', \'BUILD_NUMBER\': \'17\', \'NOSE_WITH_OPENSTACK\': \'1\', \'HUDSON_COOKIE\': \'854f8bd0-fd66-44ba-963c-d20076815489\', \'JOB_URL\': \'https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/\', \'GIT_BRANCH\': \'origin/stable/grizzly\', \'GIT_COMMIT\': \'875e42ffbefebdb9fe8eb5595a269461cb7dd5d0\', \'GIT_AUTHOR_NAME\': \'OpenStack Jenkins\', \'LC_ALL\': \'C\', \'GIT_COMMITTER_NAME\': \'OpenStack Jenkins\', \'_\': \'/usr/local/bin/tox\', \'NOSE_OPENSTACK_COLOR\': \'1\', \'NOSE_OPENSTACK_SHOW_ELAPSED\': \'1\', \'HUDSON_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'EXECUTOR_NUMBER\': \'0\', \'NODE_NAME\': \'quantal6\', \'PWD\': \'<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/\',> \'GIT_COMMITTER_EMAIL\': \'jenkins at openstack.org\', \'JENKINS_SERVER_COOKIE\': \'a8c4be63eae9909c\', \'MAIL\': \'/var/mail/jenkins\', \'SSH_CONNECTION\': \'198.101.231.203 55086 166.78.136.121 22\'}\nDownloading/unpacking SQLAlchemy>=0.7.3,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires> (line 1))\n  Cannot fetch index base URL http://pypi.openstack.org/openstack/\n  Could not find any downloads that satisfy the requirement SQLAlchemy>=0.7.3,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires> (line 1))\nNo distributions at all found for SQLAlchemy>=0.7.3,<=0.7.9 (from -r <https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires> (line 1))\nStoring complete log in /home/jenkins/.pip/pip.log\n\nERROR: could not install deps [-r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/test-requires]>\n___________________________________ summary ____________________________________\nERROR:   venv: could not install deps [-r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins.openstack.org/job/periodic-cinder-docs-stable-grizzly/ws/tools/test-requires]>\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\nERROR: Failed to upload files\ncom.jcraft.jsch.JSchException: java.net.ConnectException: Connection timed out\n	at com.jcraft.jsch.Util.createSocket(Util.java:341)\n	at com.jcraft.jsch.Session.connect(Session.java:182)\n	at com.jcraft.jsch.Session.connect(Session.java:150)\n	at be.certipost.hudson.plugin.SCPSite.createSession(SCPSite.java:162)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:163)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)\n	at hudson.model.Run.execute(Run.java:1593)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:237)\nCaused by: java.net.ConnectException: Connection timed out\n	at java.net.PlainSocketImpl.socketConnect(Native Method)\n	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327)\n	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193)\n	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)\n	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)\n	at java.net.Socket.connect(Socket.java:546)\n	at java.net.Socket.connect(Socket.java:495)\n	at java.net.Socket.<init>(Socket.java:392)\n	at java.net.Socket.<init>(Socket.java:206)\n	at com.jcraft.jsch.Util.createSocket(Util.java:335)\n	... 13 more\n\n\n',NULL,NULL),('<1787666260.7.1376374369699.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-13 06:12:49',0,'2013-08-13 06:12:49',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/6/>\n\n\n\n','<635367782.10.1376115244710.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1787962056.56.1378879315589.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-11 06:01:55',0,'2013-09-11 06:01:55',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-python27-stable-grizzly #18','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/18/>\n\n------------------------------------------\n[...truncated 634 lines...]\ntest_update_template_diff_properties_added (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_changed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_none (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_notallowed (heat.tests.test_resource.ResourceTest) ... ok\ntest_update_template_diff_properties_removed (heat.tests.test_resource.ResourceTest) ... ok\ntest_updated_time (heat.tests.test_resource.ResourceTest) ... ok\ntest_create_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_create_watch_data (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_call (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_delete_stack_cast (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_describe_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_find_physical_resource (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_get_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_events (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_list_stack_resources (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_metadata_update (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_set_watch_state (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_show_watch_metric (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_update_stack (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_validate_template (heat.tests.test_rpc_client.EngineRpcAPITestCase) ... ok\ntest_attributes (heat.tests.test_s3.s3Test) ... ok\ntest_authenticated_read (heat.tests.test_s3.s3Test) ... ok\ntest_create_container_name (heat.tests.test_s3.s3Test) ... ok\ntest_delete_exception (heat.tests.test_s3.s3Test) ... ok\ntest_delete_retain (heat.tests.test_s3.s3Test) ... ok\ntest_public_read (heat.tests.test_s3.s3Test) ... ok\ntest_public_read_write (heat.tests.test_s3.s3Test) ... ok\ntest_website (heat.tests.test_s3.s3Test) ... ok\ntest_security_group_nova (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_security_group_nova_exception (heat.tests.test_security_group.SecurityGroupTest) ... ok\ntest_byte_string_12 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_16 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_60 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_byte_string_8 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_generate_ids (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_string (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_0 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_1 (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_endianness (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_get_id_uuid_f (heat.tests.test_short_id.ShortIdTest) ... ok\ntest_attributes (heat.tests.test_swift.swiftTest) ... ok\ntest_build_meta_headers (heat.tests.test_swift.swiftTest) ... ok\ntest_create_container_name (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_exception (heat.tests.test_swift.swiftTest) ... ok\ntest_delete_retain (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read (heat.tests.test_swift.swiftTest) ... ok\ntest_public_read_write (heat.tests.test_swift.swiftTest) ... ok\ntest_website (heat.tests.test_swift.swiftTest) ... ok\ntest_convert_all_templates (heat.tests.test_template_format.JsonToYamlTest) ... ok\ntest_quantum_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_wordpress_resolved (heat.tests.test_template_format.JsonYamlResolvedCompareTest) ... ok\ntest_minimal_yaml (heat.tests.test_template_format.YamlMinimalTest) ... ok\ntest_file_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_garbage (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_error (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_http_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_https_scheme (heat.tests.test_urlfetch.UrlFetchTest) ... ok\ntest_access_key (heat.tests.test_user.AccessKeyTest) ... ok\ntest_access_key_no_user (heat.tests.test_user.AccessKeyTest) ... ok\ntest_accesspolicy_access_allowed (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_err_notfound (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_create_ok_empty (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_accesspolicy_update (heat.tests.test_user.AccessPolicyTest) ... ok\ntest_user (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed (heat.tests.test_user.UserTest) ... ok\ntest_user_access_allowed_ignorepolicy (heat.tests.test_user.UserTest) ... ok\ntest_user_create_bad_policies (heat.tests.test_user.UserTest) ... ok\ntest_user_validate_policies (heat.tests.test_user.UserTest) ... ok\ntest_validate_findinmap_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_findinmap_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_ref_valid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_invalid (heat.tests.test_validate.validateTest) ... ok\ntest_validate_volumeattach_valid (heat.tests.test_validate.validateTest) ... ok\ntest_volume (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_attachment_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_volume_create_error (heat.tests.test_volume.VolumeTest) ... ok\ntest_internet_gateway (heat.tests.test_vpc.InternetGatewayTest) ... ok\ntest_network_interface (heat.tests.test_vpc.NetworkInterfaceTest) ... ok\ntest_route_table (heat.tests.test_vpc.RouteTableTest) ... ok\ntest_subnet (heat.tests.test_vpc.SubnetTest) ... ok\ntest_vpc (heat.tests.test_vpc.VPCTest) ... ok\ntest_get_status (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_get_status_reason (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_handle (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_metadata_update_invalid (heat.tests.test_waitcondition.WaitConditionHandleTest) ... ok\ntest_FnGetAtt (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_failure_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_post_success_to_handle_count (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_timeout (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_resource_type (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackid (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_stackname (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_validate_handle_url_bad_tenant (heat.tests.test_waitcondition.WaitConditionTest) ... ok\ntest_ave (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_create_watch_data (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_evaluate (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_load (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_maximum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_minimum (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_normal (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_alarm_two_actions (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_nodata (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_rule_actions_ok_alarm (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_samplecount (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_set_watch_state_invalid (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_store (heat.tests.test_watch.WatchRuleTest) ... ok\ntest_sum (heat.tests.test_watch.WatchRuleTest) ... ok\n\n======================================================================\nFAIL: test_FnGetAtt (heat.tests.test_metadata_refresh.MetadataRefreshTest)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/utils.py\",> line 75, in wrapped_test\n    test_fn(test_cls)\n  File \"<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/heat/tests/test_metadata_refresh.py\",> line 178, in test_FnGetAtt\n    self.assertEqual(cont, \'s2-ip=1.2.3.5\')\nAssertionError: u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\n-------------------- >> begin captured stdout << ---------------------\nRunning test test_FnGetAtt\n\n--------------------- >> end captured stdout << ----------------------\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = \'%s != %s\' % (safe_repr(u\'s2-ip=\'), safe_repr(\'s2-ip=1.2.3.5\'))\n    \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\" = self._formatMessage(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\", \"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n>>  raise self.failureException(\"u\'s2-ip=\' != \'s2-ip=1.2.3.5\'\")\n    \n-------------------- >> begin captured logging << --------------------\nheat.engine.resource: INFO: creating Instance \"S1\"\nheat.engine.resource: INFO: creating Instance \"S2\"\nheat.engine.resource: INFO: deleting Instance \"S1\" (inst:None db_id:12)\nheat.engine.resource: INFO: deleting Instance \"S2\" (inst:None db_id:13)\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 694 tests in 13.891s\n\nFAILED (failures=1)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/ws/.tox/py27/bin/nosetests> -a tag=unit\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.12.0\ncliff==1.4.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.11\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\ngreenlet==0.4.1\nheat==jenkins.periodic.heat.python27.stable.grizzly.18\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.4\nprettytable==0.7.2\npyOpenSSL==0.13.1\npycrypto==2.6\npyflakes==0.7.3\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-memcached==1.53\npython-novaclient==2.14.1\npython-quantumclient==2.2.3\npython-swiftclient==1.6.0\npytz==2013d\nrequests==1.2.3\nsimplejson==3.3.0\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwarlock==1.0.1\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.l7A66dsMv8\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-python27-stable-grizzly/precise1/18\n[SCP] Copying console log.\n\n\n','<371333965.52.1378792969688.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1788330670.242.1368339113988.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-12 06:11:53',0,'2013-05-12 06:11:53',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-stable-folsom #223','See <https://jenkins.openstack.org/job/periodic-tempest-devstack-vm-stable-folsom/223/>\n\n\n\n','<1099239531.223.1368252614998.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1788852399.27667197.1385138077079.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-22 11:34:37',-18000,'2013-11-22 16:34:37',NULL,'[openstack-dev] [Solum] Working group on language packs','I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far.  The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance).  These are *DRAFT* and are intended for public debate.  \n\nhttps://blueprints.launchpad.net/solum/+spec/lang-pack\nhttps://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts\n\nPlease take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving.\n\n[1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes\n\n\n\n\n\n\n\n','<1129450998.27664612.1385137843947.JavaMail.root@redhat.com>',NULL),('<1789142715.12.1373868850344.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-07-15 06:14:10',0,'2013-07-15 06:14:10',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-folsom #287','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/287/>\n\n------------------------------------------\n[...truncated 947 lines...]\n    test_calling_format_default                                  OK    0.01\n    test_calling_format_path                                     OK    0.01\n    test_calling_format_subdomain                                OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_calling_format_default                              OK    0.01\n    test_get_calling_format_path                                 OK    0.02\n    test_get_non_existing                                        OK    0.01\n    test_get_s3_bad_location                                     OK    0.01\n    test_get_s3_good_location                                    OK    0.01\n    test_no_access_key                                           OK    0.01\n    test_no_host                                                 OK    0.01\n    test_no_secret_key                                           OK    0.01\nTestBasicSchema\n    test_filter_strips_extra_properties                          OK    0.01\n    test_merge_conflicting_but_identical_properties              OK    0.01\n    test_merge_conflicting_properties                            OK    0.01\n    test_merge_properties                                        OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_fails_on_bad_type                              OK    0.01\n    test_validate_fails_on_extra_properties                      OK    0.01\n    test_validate_passes                                         OK    0.01\nTestBasicSchemaLinks\n    test_raw_json_schema                                         OK    0.01\nTestCollectionSchema\n    test_raw_json_schema                                         OK    0.01\nTestPermissiveSchema\n    test_filter_passes_extra_properties                          OK    0.01\n    test_raw_json_schema                                         OK    0.01\n    test_validate_rejects_non_string_extra_properties            OK    0.01\n    test_validate_with_additional_properties_allowed             OK    0.01\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.01\n    test_002_increase_test_counter                               OK    0.01\n    test_003_verify_test_counter                                 OK    0.01\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.01\n    test_filesystem_store_location                               OK    0.01\n    test_get_location_from_uri_back_to_uri                       OK    0.01\n    test_get_store_from_scheme                                   OK    0.02\n    test_http_store_location                                     OK    0.01\n    test_rbd_store_location                                      OK    0.02\n    test_s3_store_location                                       OK    0.01\n    test_swift_store_location                                    OK    0.01\nTestChunkReader\n    test_read_all_data                                           OK    0.01\nTestStoreAuthV1\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\nTestStoreAuthV2\n    test_add                                                     OK    0.01\n    test_add_already_existing                                    OK    0.01\n    test_add_auth_url_variations                                 OK    0.02\n    test_add_large_object                                        OK    0.01\n    test_add_large_object_zero_size                              OK    0.01\n    test_add_no_container_and_create                             OK    0.01\n    test_add_no_container_no_create                              OK    0.01\n    test_delete                                                  OK    0.01\n    test_delete_non_existing                                     OK    0.01\n    test_get                                                     OK    0.01\n    test_get_non_existing                                        OK    0.01\n    test_get_size                                                OK    0.01\n    test_get_with_http_auth                                      OK    0.01\n    test_no_auth_address                                         OK    0.01\n    test_no_key                                                  OK    0.01\n    test_no_user                                                 OK    0.01\n    test_read_acl_public                                         OK    0.01\n    test_read_acl_tenants                                        OK    0.01\n    test_read_write_public                                       OK    0.01\n    test_v2_multi_tenant_location                                OK    0.01\n    test_v2_with_no_tenant                                       OK    0.01\nTestUtils\n    test_cooperative_reader                                      OK    0.05\n    test_cooperative_reader_of_iterator                          OK    0.01\n    test_generate_uuid_format                                    OK    0.01\n    test_generate_uuid_unique                                    OK    0.01\n    test_is_uuid_like_fails                                      OK    0.01\n    test_is_uuid_like_success                                    OK    0.01\n    test_limiting_reader                                         OK    0.01\n    test_limiting_reader_fails                                   OK    0.01\nVersionNegotiationTest\n    test_request_accept_v1                                       OK    0.20\n    test_request_url_v1                                          OK    0.01\n    test_request_url_v1_0                                        OK    0.01\n    test_request_url_v1_1                                        OK    0.01\n    test_request_url_v2                                          OK    0.01\n    test_request_url_v2_0                                        OK    0.01\n    test_request_url_v2_1_unsupported                            OK    0.01\n    test_request_url_v3_unsupported                              OK    0.01\nVersionsTest\n    test_get_version_list                                        OK    0.01\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.01\n    test_default_with_body                                       OK    0.01\n    test_from_json                                               OK    0.01\n    test_from_json_malformed                                     OK    0.01\n    test_has_body_has_content_length                             OK    0.01\n    test_has_body_no_content_length                              OK    0.01\n    test_has_body_zero_content_length                            OK    0.01\n    test_no_body_no_content_length                               OK    0.01\nJSONResponseSerializerTest\n    test_default                                                 OK    0.01\n    test_to_json                                                 OK    0.01\nRequestTest\n    test_content_type_accept_default                             OK    0.01\n    test_content_type_from_accept_json                           OK    0.01\n    test_content_type_from_accept_json_xml_quality               OK    0.01\n    test_content_type_from_accept_xml                            OK    0.01\n    test_content_type_from_accept_xml_json                       OK    0.01\n    test_content_type_missing                                    OK    0.01\n    test_content_type_unsupported                                OK    0.01\n    test_content_type_with_charset                               OK    0.01\nResourceTest\n    test_dispatch                                                OK    0.01\n    test_dispatch_default                                        OK    0.01\n    test_dispatch_no_default                                     OK    0.01\n    test_get_action_args                                         OK    0.01\nTestHelpers\n    test_data_passed_properly_through_headers                    OK    0.01\n    test_headers_are_unicode                                     OK    0.01\n\n======================================================================\nFAIL: Set up four test images and ensure each query param filter works\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/utils.py\",> line 178, in wrapped\n    func(*a, **kwargs)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/functional/v1/test_api.py\",> line 559, in test_filtered_images\n    self.assertEqual(response.status, 200)\nAssertionError: 500 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (500, 200))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 71.85 secs:\n    14.98    TestScrubber.test_delayed_delete\n    14.60    TestBinGlanceCacheManage.test_queue\n    14.29    TestGlanceControl.test_reload\n    14.06    TestGlanceControl.test_respawn\n    13.91    TestGlanceControl.test_bouncing\n----------------------------------------------------------------------\nRan 926 tests in 601.822s\n\nFAILED (SKIP=89, failures=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.7\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.0.12\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nglance==jenkins-periodic-glance-python26-stable-folsom-287\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonschema==2.0.0\nkombu==2.5.12\nlxml==3.2.1\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.9\nnosehtmloutput==0.0.4\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npbr==0.5.18\npep8==1.1\npycrypto==2.6\npysendfile==2.0.0\npython-swiftclient==1.5.0\nrepoze.lru==0.6\nrequests==1.2.3\nsetuptools-git==1.0\nsimplejson==3.3.0\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=94\n+ \'[\' 94 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.qksfixz6sf\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/287\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-folsom/287/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1789926283.3.1371623028405.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-06-19 06:23:48',0,'2013-06-19 06:23:48',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python26-stable-folsom #261','See <https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/261/>\n\n------------------------------------------\n[...truncated 12589 lines...]\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:43109\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:43109/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (32494) wsgi starting up on http://127.0.0.1:43109/\n\nnova.osapi_compute.wsgi.server: INFO: (32494) accepted (\'127.0.0.1\', 54269)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [19/Jun/2013 06:18:29] \"GET /v2 HTTP/1.1\" 204 216 0.001069\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-5beabe80-aa47-4208-8258-54550307dab2</name>\n    <public_key>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDx8nkQv/zgGgB4rMYmIf+6A4l6Rr+o/6lHBQdW5aYd44bd8JttDCE/F/pNRr0lRE+PiqSPO8nDPHw0010JeMH9gYgnnFlyY3/OcJ02RhIPyyxYpv9FhY+2YiUkpwFOcLImyrxEsYXpD/0d3ac30bNH6Sw9JD9UZHYcpSxsIbECHw== Generated by Nova</public_key>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (32494) accepted (\'127.0.0.1\', 54270)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9902890>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0x9902890>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:43109/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 85, in create\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     params[\'public_key\'])\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2211, in import_key_pair\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     fingerprint = crypto.generate_fingerprint(public_key)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 133, in generate_fingerprint\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     return _generate_fingerprint(pubfile)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 122, in _generate_fingerprint\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     (out, err) = utils.execute(\'ssh-keygen\', \'-q\', \'-l\', \'-f\', public_key_file)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-19 06:18:29 32494 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:43109/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [19/Jun/2013 06:18:29] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.290462\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: Get api sample of key pairs post request\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/integrated/test_api_samples.py\",> line 884, in test_keypairs_post\n    self.assertEqual(response.status, 200)\nAssertionError: 400 != 200\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (400, 200))\n    \n-------------------- >> begin captured logging << --------------------\nnova.compute.manager: INFO: Loading compute driver \'nova.virt.fake.FakeDriver\'\nnova.service: AUDIT: Starting compute node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.compute.resource_tracker: AUDIT: Free ram (MB): 7680\nnova.compute.resource_tracker: AUDIT: Free disk (GB): 1028\nnova.compute.resource_tracker: AUDIT: Free VCPUS: 1\nnova.compute.resource_tracker: INFO: Compute_service record created for 27e5516eaf6549f783782f5f78064d1d \nnova.service: AUDIT: Starting volume node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting network node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.service: AUDIT: Starting scheduler node (version 2012.2.5-LOCALBRANCH:LOCALREVISION)\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.api.openstack.compute.extensions: AUDIT: Initializing extension manager.\nnova.api.openstack.extensions: AUDIT: Loaded extension: os-keypairs\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nnova.wsgi: INFO: osapi_compute listening on 127.0.0.1:52471\nnova.tests.integrated.integrated_helpers: WARNING: http://127.0.0.1:52471/v2\nnova.tests.integrated.api.client: INFO: Doing GET on /v2\nnova.osapi_compute.wsgi.server: INFO: (32494) wsgi starting up on http://127.0.0.1:52471/\n\nnova.osapi_compute.wsgi.server: INFO: (32494) accepted (\'127.0.0.1\', 36837)\n\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [19/Jun/2013 06:18:29] \"GET /v2 HTTP/1.1\" 204 216 0.001071\n\nnova.tests.integrated.api.client: INFO: Doing POST on /v2/openstack/os-keypairs\nnova.tests.integrated.api.client: INFO: Body: <keypair>\n    <name>keypair-e142dcbd-2657-45fd-af5a-00875fca7503</name>\n</keypair>\nnova.osapi_compute.wsgi.server: INFO: (32494) accepted (\'127.0.0.1\', 36838)\n\nroutes.middleware: DEBUG: Matched POST /openstack/os-keypairs\nroutes.middleware: DEBUG: Route path: \'/{project_id}/os-keypairs\', defaults: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa248d90>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'create\', \'controller\': <nova.api.openstack.wsgi.Resource object at 0xa248d90>, \'project_id\': u\'openstack\'}\nnova.api.openstack.wsgi: INFO: POST http://127.0.0.1:52471/v2/openstack/os-keypairs\nnova.api.openstack.wsgi: ERROR: Exception handling resource: wait() got an unexpected keyword argument \'timeout\'\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi Traceback (most recent call last):\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 944, in _process_stack\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     action_result = self.dispatch(meth, request, action_args)\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/wsgi.py\",> line 1032, in dispatch\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     return method(req=request, **action_args)\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/api/openstack/compute/contrib/keypairs.py\",> line 88, in create\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     name)\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/compute/api.py\",> line 2234, in create_key_pair\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     private_key, public_key, fingerprint = crypto.generate_key_pair()\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/crypto.py\",> line 144, in generate_key_pair\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     \'-t\', \'rsa\', \'-f\', keyfile, \'-C\', \'Generated by Nova\')\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/utils.py\",> line 200, in execute\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     result = obj.communicate()\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 729, in communicate\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     stdout, stderr = self._communicate(input, endtime)\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi   File \"/usr/lib64/python2.6/subprocess.py\", line 1330, in _communicate\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi     self.wait(timeout=self._remaining_time(endtime))\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi TypeError: wait() got an unexpected keyword argument \'timeout\'\n2013-06-19 06:18:30 32494 TRACE nova.api.openstack.wsgi \nnova.api.openstack.wsgi: INFO: http://127.0.0.1:52471/v2/openstack/os-keypairs returned with HTTP 400\nnova.osapi_compute.wsgi.server: INFO: 127.0.0.1 - - [19/Jun/2013 06:18:30] \"POST /v2/openstack/os-keypairs HTTP/1.1\" 400 399 0.433096\n\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: test_get_product_version_product_brand_does_not_fail (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2855, in test_get_product_version_product_brand_does_not_fail\n    session._get_product_version_and_brand()\nAssertionError: (None, None) != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % ((None, None), ((5, 6, 2), \'XenServer\')))\n    \n\n======================================================================\nFAIL: test_get_product_version_product_brand_xs_6 (nova.tests.test_xenapi.XenAPISessionTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/nova/tests/test_xenapi.py\",> line 2866, in test_get_product_version_product_brand_xs_6\n    session._get_product_version_and_brand()\nAssertionError: ((6, 0, 50), \'XenServer\') != ((5, 6, 2), \'XenServer\')\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (((6, 0, 50), \'XenServer\'), ((5, 6, 2), \'XenServer\')))\n    \n\n----------------------------------------------------------------------\nXML: nosetests.xml\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-nova-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nJinja2==2.7\nMarkdown==2.3.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.12.3\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqplib==0.6.1\nanyjson==0.2.4\nargparse==1.2.1\nboto==2.1.1\ncliff==1.4\ncmd2==0.6.5.1\ncolorama==0.2.5\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.10\neventlet==0.12.1\nfeedparser==5.1.3\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.0\njsonpointer==1.0\njsonschema==1.4.0\nkombu==1.0.4\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==2.3.5\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.2.1\nnosehtmloutput==0.0.4\nnova==2012.2.5\nopenstack.nose-plugin==0.11\noslo.config==1.1.1\nparamiko==1.10.1\npbr==0.5.17\npep8==1.1\nprettytable==0.7.2\npyOpenSSL==0.13\npycrypto==2.6\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.4\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.5\npython-quantumclient==2.2.1\nrequests==1.2.3\nsetuptools-git==1.0b1\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nsuds==0.4\ntermcolor==1.1.0\nunittest2==0.5.1\nwarlock==1.0.0\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.h0POy7arti\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python26-stable-folsom/261\n[SCP] Copying console log.\n\n\n','<1269550458.2.1371536606614.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<178C5798-E501-44F1-BF1A-62F118DC236E@thstack.com>','http://lists.openstack.org/pipermail/openstack-infra',NULL,'2014-04-12 23:29:03',28800,'2014-04-12 15:29:03',NULL,'[OpenStack-Infra] thstack-ci service account','The following is my user information?\n\n1. username: thstack-ci\n2. display name: THSTACK CI\n3. email address: openstack-ci at thstack.com\n4. pub key?\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCeAVrArrv0xZTlna/EqoTKxMHtz1tgJshutBHrIN0C9T8MOT4YJCK0E5fnVsLKvOrzPIEaMcWxZMnnFhYhf6NKJJfPaBygN+BPVf08OsvMSWaKegqHBK5AuujkyA4t0aB9zZlexNZfaskK5ErTgD6UwRqOd5gVgQlXgs+eDEF+8LteB48cZERPNVxpfwr2azzy6cJWtYCXKdsMfPpoN+sX1WtJ5r379cy9vQZYzPYHw1eMY9mgdGW9k0mS1t6OQr6i1M4nWtGQH3CReht/4/WBJ7vaqPBBgrnvIbdkuR6UGprWHWjhmzbrYDFPHiJnZlx4eVIjePXpMdN76g2RRWv/ openstack-ci at thstack.com\n\n--\nRong Li - ??\nTHSTACK Inc. CTO\nTwitter:  @Longgeek\nWeb:   http://www.thstack.com\nBlog:   http://www.longgeek.com\nWeibo:  http://weibo.com/longgeek \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20140412/25ba2f43/attachment.html>\n\n',NULL,NULL),('<1791153626.38735613.1405948716309.JavaMail.zimbra@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-07-21 13:18:36',0,'2014-07-21 13:18:36',NULL,'[openstack-dev] [keystone/swift] role-based access cotrol\n	in	swift','Hi, \n\nMy answer is may be a little bite late but here\'s a swift middleware we have just published: https://github.com/cloudwatt/swiftpolicy \nit allows managing swift authorization using a policy.json file. \nIt is based on the keystoneauth middleware, and uses oslo.policy file format.\n\nFeel free to comment and/or to ask if any questions.\n\n--\nNassim\n\n----- Mail original -----\nDe: \"John Dickinson\" <me at not.mn>\n?: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nEnvoy?: Vendredi 11 Juillet 2014 05:33:13\nObjet: Re: [openstack-dev] [keystone/swift] role-based access cotrol in	swift\n\nThere are a couple of places to look to see the current dev effort in Swift around ACLs.\n\nIn no particular order:\n\n* Supporting a service token in Swift https://review.openstack.org/#/c/105228/\n* Adding policy engine support to Swift https://review.openstack.org/#/c/89568/\n* Fixing ACLs to work with Keystone v3+ https://review.openstack.org/#/c/86430/\n\nSome of the above may be in line with what you\'re looking for.\n\n--John\n\nOn Jul 10, 2014, at 8:17 PM, Osanai, Hisashi <osanai.hisashi at jp.fujitsu.com> wrote:\n\n> \n> Hi, \n> \n> I looked for info about role-based access control in swift because \n> I would like to prohibit PUT operations to containers like create \n> containers and set ACLs.\n> \n> Other services like Nova, Cinder have \"policy.json\" file but Swift doesn\'t.\n> And I found out the following info.\n> - Swift ACL\'s migration\n> - Centralized policy management\n> \n> Do you have detail info for above?\n> \n> http://dolphm.com/openstack-juno-design-summit-outcomes-for-keystone/\n> ---\n> Migrate Swift ACL\'s from a highly flexible Tenant ID/Name basis, which worked reasonably well against Identity API v2, to strictly be based on v3 Project IDs. The driving requirement here is that Project Names are no longer globally unique in v3, as they\'re only unique within a top-level domain.\n> ---\n> Centralized policy management\n> Keystone currently provides an unused /v3/policies API that can be used to centralize policy blob management across OpenStack.\n> \n> \n> Best Regards,\n> Hisashi Osanai\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<DFCE786E-7D5D-4453-A55C-973675D506A8@not.mn>',NULL),('<1791339655.490.1367215716376.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-29 06:08:36',0,'2013-04-29 06:08:36',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-ceilometer-python26-stable-grizzly #19','See <https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/19/>\n\n------------------------------------------\n[...truncated 5086 lines...]\n2013-04-29 06:08:32    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:08:32,005 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\n2013-04-29 06:08:32,006 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:08:32,007 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,008 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,009 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline second_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline second_pipeline\n2013-04-29 06:08:32,010 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Publishing counters\n2013-04-29 06:08:32,011 WARNI [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-29 06:08:32  WARNING [ceilometer.pipeline] Pipeline second_pipeline: Continue after error from publisher except\n2013-04-29 06:08:32,012 ERROR [ceilometer.pipeline][MainThread] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:08:32    ERROR [ceilometer.pipeline] \nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/ceilometer/pipeline.py\",> line 198, in _publish_counters_to_one_publisher\n    ext.obj.publish_counters(ctxt, counters, source)\n  File \"<https://jenkins.openstack.org/job/periodic-ceilometer-python26-stable-grizzly/ws/tests/test_pipeline.py\",> line 65, in publish_counters\n    raise Exception()\nException\n2013-04-29 06:08:32,013 AUDIT [ceilometer.pipeline][MainThread] Pipeline second_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline second_pipeline: Published counters\nok\ntest_no_counters (tests.test_pipeline.TestPipeline) ... ok\ntest_no_interval (tests.test_pipeline.TestPipeline) ... ok\ntest_no_name (tests.test_pipeline.TestPipeline) ... ok\ntest_no_publishers (tests.test_pipeline.TestPipeline) ... ok\ntest_no_transformers (tests.test_pipeline.TestPipeline) ... ok\ntest_none_transformer_pipeline (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,018 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.017875\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.017875\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32,019 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,020 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,021 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\nok\ntest_publisher_transformer_invoked (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,022 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32,023 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.022513\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.022513\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32,024 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,025 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,026 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:08:32,027 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,027 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_variable_counter (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,029 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32,030 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.029383\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a:b\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.029383\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32,031 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,032 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,033 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:08:32,034 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,035 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_counter (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,036 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32,037 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.036482\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.036482\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32,038 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,039 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,040 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:08:32,041 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,041 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_wildcard_excluded_counters (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,043 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\nok\ntest_wildcard_excluded_counters_not_excluded (tests.test_pipeline.TestPipeline) ... 2013-04-29 06:08:32,045 INFO  [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32     INFO [ceilometer.pipeline] Pipeline test_pipeline: Setup transformer instance update with parameter {}\n2013-04-29 06:08:32,046 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.044998\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Transform counter Counter(name=\'a\', type=\'test_type\', unit=\'B\', volume=1, user_id=\'test_user\', project_id=\'test_proj\', resource_id=\'test_resource\', timestamp=\'2013-04-29T06:08:32.044998\', resource_metadata={}) from 0 transformer\n2013-04-29 06:08:32,047 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,047 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32,048 AUDIT [ceilometer.pipeline][MainThread] Flush pipeline test_pipeline\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Flush pipeline test_pipeline\n2013-04-29 06:08:32,049 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Publishing counters\n2013-04-29 06:08:32,050 AUDIT [ceilometer.pipeline][MainThread] Pipeline test_pipeline: Published counters\n2013-04-29 06:08:32    AUDIT [ceilometer.pipeline] Pipeline test_pipeline: Published counters\nok\ntest_init (tests.test_policy.TestPolicy) ... ok\ntest_init_file_not_found (tests.test_policy.TestPolicy) ... ok\ntest_prepare_service (tests.test_service.ServiceTestCase) ... ok\ntests.test_tools_notificationclient.test_send_messages ... ok\ntests.test_tools_notificationclient.test_record_messages ... ok\n\n----------------------------------------------------------------------\nXML: nosetests.xml\n----------------------------------------------------------------------\nRan 682 tests in 23.935s\n\nOK (SKIP=289)\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nCheetah==2.4.4\nFlask==0.9\nJinja2==2.6\nMako==0.8.0\nMarkdown==2.3.1\nMarkupSafe==0.15\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPyYAML==3.10\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWSME==0.5b2\nWebOb==1.2.3\nWebTest==2.0.2\nWerkzeug==0.8.3\namqp==1.0.11\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nbeautifulsoup4==4.1.3\nboto==2.9.0\nceilometer==jenkins.periodic.ceilometer.python26.stable.grizzly.19\ncliff==1.3.2\ncmd2==0.6.4\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndocutils==0.9.1\neventlet==0.12.1\nextras==0.0.3\nglance==2013.2.a79.g3acd2a5\ngreenlet==0.4.0\nhappybase==0.4\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.4\njsonpatch==0.12\njsonpointer==1.0\njsonschema==1.3.0\nkombu==2.5.10\nlxml==3.2.0\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnova==2013.2.a415.g25541a5\nnumpy==1.7.1\nordereddict==1.1\noslo.config==1.1.0\nparamiko==1.10.1\npasslib==1.6.1\npecan==0.2.3\nprettytable==0.7.2\npyOpenSSL==0.13\npyasn1==0.1.6\npycrypto==2.6\npymongo==2.5\npyparsing==1.5.7\npython-cinderclient==1.0.3\npython-glanceclient==0.9.0\npython-keystoneclient==0.2.3\npython-novaclient==2.13.0\npython-quantumclient==2.2.1\npython-spidermonkey==0.0.10\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==0.14.2\nsetuptools-git==1.0b1\nsimplegeneric==0.8.1\nsimplejson==3.1.3\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.8\nsuds==0.4\nswift==1.8.0\nthrift==0.9.0\nunittest2==0.5.1\nwaitress==0.8.2\nwarlock==0.8.2\nwebsockify==0.3.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.p5ivXPzs1s\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-ceilometer-python26-stable-grizzly/19\n[SCP] Copying console log.\n\n\n','<1895575273.439.1367129231246.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1792249.thStJ8tsyn@dblinov.sw.ru>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-04 13:46:39',14400,'2014-08-04 09:46:39',NULL,'[openstack-dev] [nova] Why people don\'t close bugs?','Hello!\n\nI looked through launchpad bugs and it seems there are a lot of bugs, \nwhich are fixed already, but still open, here are 3 ones:\n\nhttps://bugs.launchpad.net/nova/+bug/909096\nhttps://bugs.launchpad.net/nova/+bug/1206762\nhttps://bugs.launchpad.net/nova/+bug/1208743\n\nI\'ve posted comments on these bugs, but nobody replied. How is it \npossible, to close them?\n\n-- \nDmitry Guryanov\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140804/d7e908c0/attachment.html>\n\n',NULL,NULL),('<1792610240.1867790.1352116195602.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-05 06:49:55',-18000,'2012-11-05 11:49:55',NULL,'[openstack-dev] [metering] proposing Angus Salkeld for\n Ceilometer	core','\n\n> I would like to propose adding Angus Salkeld as a core reviewer for\n> Ceilometer, based on his contributions over the past couple of\n> months.\n\n+1\n\nCheers,\nEoghan\n\n\n','<CADb+p3R9pjY+dNT+3gHWK8Dc2n0HUd4SqBbKyPtn_FFGRiFAvA@mail.gmail.com>',NULL),('<1793039459.34.1385706557291.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-11-29 06:29:17',0,'2013-11-29 06:29:17',NULL,'[openstack-qa] Build failed in Jenkins:\n periodic-tempest-devstack-vm-coverage-stable-havana #6','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-coverage-stable-havana/6/>\n\n------------------------------------------\n[...truncated 20906 lines...]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke]\ntempest.thirdparty.boto.test_s3_buckets.S3BucketsTest.test_create_and_get_delete_bucket[gate,smoke] ... skipped u\'Skipped until Bug: 1076965 is resolved.\'\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest)\nsetUpClass (tempest.api.volume.admin.test_multi_backend.VolumeMultiBackendTest) ... skipped u\'Cinder multi-backend feature disabled\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_keypair_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_list_extensions ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete[gate,smoke] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_net_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_network_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_rate_limits ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_secgroup_list_rules ... skipped u\'Test needs parameters, Bug #1157349\'\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_servce_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timeout ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_timing ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_usage_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_version ... ok\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_as_clone[gate] ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_snapshot_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_admin_volume_type_list ... ok\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list\ntempest.cli.simple_read_only.test_nova.SimpleReadOnlyNovaClientTest.test_agent_list ... ok\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps)\nsetUpClass (tempest.scenario.test_network_basic_ops.TestNetworkBasicOps) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_create_get_update_delete_from_image[gate,image,smoke] ... ok\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic)\nsetUpClass (tempest.scenario.test_network_quotas.TestNetworkQuotaBasic) ... skipped u\'Neutron not available\'\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate]\ntempest.api.volume.test_volumes_get.VolumesGetTestXML.test_volume_get_metadata_none[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list[gate,smoke] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_by_name[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_resize_server_confirm[compute] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_details_by_name[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volume_list_with_details[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_by_status[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_availability_zone[gate] ... ok\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate]\ntempest.api.volume.test_volumes_list.VolumeListTestXML.test_volumes_list_details_by_status[gate] ... ok\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute]\ntempest.scenario.test_server_advanced_ops.TestServerAdvancedOps.test_server_sequence_suspend_resume[compute] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_attach_volumes_with_nonexistent_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_out_passing_size[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_detach_volumes_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistant_volume_id[gate,negative] ... ok\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative]\ntempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistant_volume_id[gate,negative] ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_admin_fake_action ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_cell_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_archive_deleted_rows ... ok\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke]\ntempest.thirdparty.boto.test_ec2_network.EC2NetworkTest.test_disassociate_not_associated_floating_ip[gate,smoke] ... skipped u\'Skipped until Bug: 1080406 is resolved.\'\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_sync ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_db_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_debug_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_flavor_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_help_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_aki_image ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_host_list ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_verbose_flag ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version ... ok\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag\ntempest.cli.simple_read_only.test_nova_manage.SimpleReadOnlyNovaManageTest.test_version_flag ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke]\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ami_image[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image\ntempest.thirdparty.boto.test_s3_ec2_images.S3ImagesTest.test_register_get_deregister_ari_image ... ok\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume] ... ok\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_create_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_delete_ec2_keypair[gate,smoke] ... skipped u\'Skipped until Bug: 1072318 is resolved.\'\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_duplicate_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke]\ntempest.thirdparty.boto.test_ec2_keys.EC2KeysTest.test_get_ec2_keypair[gate,smoke] ... ok\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke]\ntempest.thirdparty.boto.test_s3_objects.S3BucketsTest.test_create_get_delete_object[gate,smoke] ... ok\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_integration_1[gate,smoke] ... skipped u\'Skipped until Bug: 1182679 is resolved.\'\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_idempotent_instances[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_stop_terminate_instance_with_tags[gate,smoke] ... ok\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke]\ntempest.thirdparty.boto.test_ec2_instance_run.InstanceRunTest.test_run_terminate_instance[gate,smoke] ... skipped u\'Skipped until Bug: 1098891 is resolved.\'\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke]\ntempest.thirdparty.boto.test_ec2_security_groups.EC2SecurityGroupTest.test_create_authorize_security_group[gate,smoke] ... ok\nSlowest Tests\nTest id                                                                                                                  Runtime (s)\n-----------------------------------------------------------------------------------------------------------------------  -----------\ntempest.scenario.test_minimum_basic.TestMinimumBasicScenario.test_minimum_basic_scenario[compute,image,network,volume]   189.341\ntempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern[compute,image,volume]            98.069\ntempest.scenario.test_snapshot_pattern.TestSnapshotPattern.test_snapshot_pattern[compute,image,network]                   70.408\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_manual_to_auto[gate]         40.941\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestXML.test_resize_server_from_auto_to_manual[gate]         38.678\ntempest.api.compute.servers.test_server_actions.ServerActionsTestJSON.test_resize_server_revert[gate]                     37.661\ntempest.api.compute.servers.test_servers.ServersTestJSON.test_create_with_existing_server_name[gate]                      37.170\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_manual_to_auto[gate]        35.926\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_rebuild_server_with_manual_disk_config[gate]   33.864\ntempest.api.compute.servers.test_disk_config.ServerDiskConfigTestJSON.test_resize_server_from_auto_to_manual[gate]        32.857\n\n----------------------------------------------------------------------\nRan 1340 tests in 1270.263s\n\nOK (skipped=72)\ncoverage runtests: commands[2] | python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\nERROR: InvocationError: \'/opt/stack/new/tempest/.tox/coverage/bin/python -m tools/tempest_coverage -c report --html -o /opt/stack/new/tempest/coverage-report\'\n___________________________________ summary ____________________________________\nERROR:   coverage: commands failed\nProcess leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/devstack-gate-cleanup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/devstack-gate-setup-host.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/devstack-gate-setup-workspace-new.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/devstacklog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/df.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/iptables.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/kern_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/localrc.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/mysql\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/mysql/error.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/mysql/mysql-slow.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/pip-freeze.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/rabbitmq\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-762664-sasl.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/rabbitmq/rabbit at devstack-precise-hpcloud-az2-762664.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/rabbitmq/startup_log.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-c-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-c-bak.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-c-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-c-vol.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-ceilometer-acentral.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-ceilometer-acompute.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-ceilometer-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-ceilometer-collector.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-g-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-g-reg.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-h-api-cfn.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-h-api-cw.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-h-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-h-eng.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-horizon.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-key.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-api.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-cond.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-cpu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-crt.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-net.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-obj.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-n-sch.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-s-account.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-s-container.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-s-object.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-s-proxy.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/screen-sysstat.txt.gz\'\n[SCP] Trying to create /srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/51_tempest_sh.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/90-cloudimg-ubuntu.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/README.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/cinder-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/jenkins-sudo-grep.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.d/nova-rootwrap.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sudoers.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/syslog.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/sysstat.dat.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/logs/tempest.txt.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/testr_results.html.gz\'\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-tempest-devstack-vm-coverage-stable-havana/devstack-precise-hpcloud-az2-762664/6/subunit_log.txt.gz\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1519875676.29.1385620191218.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1793713114.50668.1419160469384.JavaMail.yahoo@jws10940.mail.sg3.yahoo.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-21 11:14:29',0,'2014-12-21 11:14:29',NULL,'[Openstack] {Disarmed} Re: Fedora/cirros instance failed to set\n root password','Hi Georgios Dimitrakakis/Girija Sharan,\nThanks for help, now I am bale to ssh and able to change root passwd. \nI ssh and they say sudo su as told by Georgios I am loged in as root, the using root command able to set new passwd for root. \n\nNow I am ble to run YUM, I seeing that I am not able to ping outside world I am able to ping my controller host 10.10.126.62. \n\nAnd my instance IP fixed one is 10.4.128.4 and floating IP is 10.10.126.133,\nI am also able to ping other host which is not running the instance 10.10.126.54. I am looking into it. \n\nroute -n shows[root at sunday fedora]# route -n\nKernel IP routing table\nDestination???? Gateway???????? Genmask???????? Flags Metric Ref??? Use Iface\n0.0.0.0???????? 10.4.128.3????? 0.0.0.0???????? UG??? 0????? 0??????? 0 eth0\n10.4.128.0????? 0.0.0.0???????? 255.255.240.0?? U???? 0????? 0??????? 0 eth0\n\n\nI amnot able to ping google.comlooking into it. \n\nthanks in advance \n\nregardsNeelu\n\n\nRegards\nNeelu \n\n     On Friday, 19 December 2014 8:19 PM, Georgios Dimitrakakis <giorgis at acmac.uoc.gr> wrote:\n   \n\n  Doing that is changing the password for \"fedora\" user and not \"root\"\n\n\n When you ssh as the \"fedora\" user do \"sudo su\" and you will be able to \n login as \"root\" directly provided that the keys have been correctly \n injected.\n\n You can then set the password for \"root\"\n\n Best,\n\n George\n\n> Hi Girija Sharan,\n>\n> I tried it it is giving me\n>\n> [fedora at blabla ~]$ passwd\n> Changing password for user fedora.\n> Changing password for fedora.\n> (current) UNIX password:\n> passwd: Authentication token manipulation error\n> [fedora at blabla ~]$\n>\n> [fedora at blabla ~]$ su - root\n> Password:\n> su: Authentication failure\n>\n> here is the admin pass as shown below \"uTU3H5er7yZS\"\n>\n> I enter this password gives error\n>\n> i the above commands used the same admin pass\n>\n> stack at celestial-PC-1:~/devstack$ nova boot --flavor 3 --image\n> 9d30b9b5-d648-4af1-ad24-d5792d3f1909 --key-name nnnn --security-group\n> default blabla\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n> | Property | Value |\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n> | OS-DCF:diskConfig | MANUAL |\n> | OS-EXT-AZ:availability_zone | nova |\n> | OS-EXT-SRV-ATTR:host | - |\n> | OS-EXT-SRV-ATTR:hypervisor_hostname | - |\n> | OS-EXT-SRV-ATTR:instance_name | instance-00000001 |\n> | OS-EXT-STS:power_state | 0 |\n> | OS-EXT-STS:task_state | scheduling |\n> | OS-EXT-STS:vm_state | building |\n> | OS-SRV-USG:launched_at | - |\n> | OS-SRV-USG:terminated_at | - |\n> | accessIPv4 | |\n> | accessIPv6 | |\n> | adminPass | uTU3H5er7yZS |\n> | config_drive | |\n> | created | 2014-12-19T12:29:45Z |\n> | flavor | m1.medium (3) |\n> | hostId | |\n> | id | 898a3c21-c1bf-4325-93ac-f14315dd2210 |\n> | image | Fedora-x86_64-20-20140618-sda\n> (9d30b9b5-d648-4af1-ad24-d5792d3f1909) |\n> | key_name | nnnn |\n> | metadata | {} |\n> | name | blabla |\n> | os-extended-volumes:volumes_attached | [] |\n> | progress | 0 |\n> | security_groups | default |\n> | status | BUILD |\n> | tenant_id | 2d51ee7250aa4532801f83fda82468fc |\n> | updated | 2014-12-19T12:29:46Z |\n> | user_id | f923e8ad018a40c4a315fa1c23126eed |\n> \n> +--------------------------------------+----------------------------------------------------------------------+\n>\n> Regards\n> Neelu\n>\n>? On Friday, 19 December 2014 3:25 PM, Girija Sharan? wrote:\n>\n> Hi Som,\n>\n> As you said, you are able to ssh into the instance using keypair, why\n> don\'t you just ssh into that and set root password using \'passwd\'\n> command or create another user with root permissions ?\n>\n> On Fri, Dec 19, 2014 at 3:06 PM, somshekar kadam? wrote:\n>\n>> Hi Girija Sharan,\n>>\n>> Thanks for pointing the link I will try and let me see if it works.\n>>\n>> I just need to set the root pasword so that I can install apache\n>> wbserver on this instance.\n>>\n>> Is there any other best method to do it, which I not know.\n>>\n>> thanks in advance\n>>\n>> Regards\n>> Neelu\n>>\n>> On Friday, 19 December 2014 2:44 PM, Girija Sharan wrote:\n>>\n>> Hi Som,\n>>\n>> Not sure on what you are looking for. But here is a link which\n>> describe\n>>\n>> how to set root password during instance boot up.\n>>\n>>\n> \n> http://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/\n>> [10]\n>>\n>> On Fri, Dec 19, 2014 at 2:19 PM, somshekar kadam wrote:\n>>\n>>> Hi All,\n>>>\n>>> I am trying to set root password on\n>>> Fedora-x86_64-20-20140618-sda/cirros instance it fails .\n>>> DO I need to add anyother security rules, please what I am\n>>> missing.\n>>> I need to install apache webserver on this instance.\n>>>\n>>> Thanks in advance\n>>>\n>>> nova root-password gggg\n>>> New password:\n>>> Again:\n>>> ERROR (HTTPNotImplemented): Unable to set password on instance\n>>> (HTTP 501) (Request-ID: req-6d0eebe3-68c5-4d8d-80b7-8d4639b7c2d4)\n>>>\n>>> I have set all rules for security groups\n>>> PC-1:~/devstack$ nova secgroup-list-rules default\n>>> +-------------+-----------+---------+-----------+--------------+\n>>> | IP Protocol | From Port | To Port | IP Range | Source Group |\n>>> +-------------+-----------+---------+-----------+--------------+\n>>> | icmp | -1 | -1 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [1] | |\n>>> | tcp | 1 | 65535 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [2] | |\n>>> | udp | 1 | 65535 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [3] | |\n>>> | tcp | 22 | 22 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [4] | |\n>>> | tcp | 80 | 80 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [5] | |\n>>> | tcp | 443 | 443 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [6] | |\n>>> | tcp | 3306 | 3306 | MAILSCANNER WARNING: NUMERICAL LINKS ARE\n>>> OFTEN MALICIOUS: 0.0.0.0/0 [7] | |\n>>> | tcp | 53 | 53 | MAILSCANNER WARNING: NUMERICAL LINKS ARE OFTEN\n>>> MALICIOUS: 0.0.0.0/0 [8] | |\n>>> +-------------+-----------+---------+-----------+--------------+\n>>>\n>>> Regards\n>>> Neelu\n>\n>\n>\n> Links:\n> ------\n> [1] http://0.0.0.0/0\n> [2] http://0.0.0.0/0\n> [3] http://0.0.0.0/0\n> [4] http://0.0.0.0/0\n> [5] http://0.0.0.0/0\n> [6] http://0.0.0.0/0\n> [7] http://0.0.0.0/0\n> [8] http://0.0.0.0/0\n> [9] mailto:girijasharansingh at gmail.com\n> [10]\n> \n> http://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/\n> [11] mailto:som_kadam at yahoo.co.in\n> [12] mailto:som_kadam at yahoo.co.in\n\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20141221/1665abf1/attachment.html>\n\n','<109c0c339f7bb2791f4029f63d3e8f19@acmac.uoc.gr>',NULL),('<1794870205.47439489.1410418922648.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 03:02:02',-14400,'2014-09-11 07:02:02',NULL,'[openstack-dev] [Horizon] Licensing issue with using JSHint in\n build','I want to apologize for my rapid response, I was incorrect about the license\nbecause of the file you pointed out.  I did not intend to sound snarky or\nanything like that in either the original email or the reply.\n\nAnyway, for future reference, I believe the last thread where this was discussed was\nhere: http://lists.openstack.org/pipermail/openstack-dev/2014-April/031689.html,\nwhich basically reiterates what David says above (it\'s good to have links to the\npast discussions, IMO).\n\nBest Regards,\nSolly Ross\n\nP.S. Here\'s hoping that the JSHint devs eventually find a way to remove that line\nfrom the file -- according to https://github.com/jshint/jshint/issues/1234, not\nmuch of the original remains.\n\n----- Original Message -----\n> From: \"Aaron Sahlin\" <asahlin at linux.vnet.ibm.com>\n> To: openstack-dev at lists.openstack.org\n> Sent: Wednesday, September 10, 2014 1:35:48 PM\n> Subject: Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in build\n> \n> What you are finding is the same as I found, which raised my concern.\n> \n> Thanks for the pointer to legal-discuss at lists.openstack.org, I will post\n> the question there (let the lawyers figure it out).\n> \n> \n> \n> \n> On 9/10/2014 12:16 PM, Solly Ross wrote:\n> > ----- Original Message -----\n> >> From: \"Jeremy Stanley\" <fungi at yuggoth.org>\n> >> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> >> <openstack-dev at lists.openstack.org>\n> >> Sent: Wednesday, September 10, 2014 1:10:18 PM\n> >> Subject: Re: [openstack-dev] [Horizon] Licensing issue with using JSHint\n> >> in build\n> >>\n> >> On 2014-09-10 13:00:29 -0400 (-0400), Solly Ross wrote:\n> >>> JSHint *isn\'t* Douglas Crockford. It was written by someone who\n> >>> (understandably) thought Douglas Crockford had some good ideas,\n> >>> but was overzealous.\n> >> [...]\n> >>\n> >> Overzealous enough to copy his code.\n> > ?? This sentence doesn\'t make much sense.  I meant to say that\n> > Douglas Crockford was overzealous (which he is, IMO).\n> >\n> >>> The license is as such:\n> >>> https://github.com/jshint/jshint/blob/master/LICENSE\n> >> Ahem. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19\n> > Fair enough.  I stand corrected.  I didn\'t catch that.\n> > The general license, however, is as stated.\n> >\n> >>> You are thinking of JSLint, which is written by Douglas Crockford.\n> >> JSHint is a derivative project of JSLint. Sorry to burst your\n> >> bubble.\n> > To be fair, it\'s been undergoing *major* revisions lately, making it\n> > resemble\n> > JSHint less and less in terms of what it checks for.  Having used it in the\n> > past, functionality wise it\'s very different.  While it maintains some\n> > backwards\n> > compatibility, it has added in new checks, doesn\'t complain about nearly\n> > the number\n> > of things that JSLint complains about (for good reasons).\n> >\n> >> --\n> >> Jeremy Stanley\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> \n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<54108BF4.9040004@linux.vnet.ibm.com>',NULL),('<1795159583.58.1367734519740.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-05-05 06:15:19',0,'2013-05-05 06:15:19',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-keystone-python26-stable-grizzly-centos6 #5','See <https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/5/>\n\n------------------------------------------\n[...truncated 3973 lines...]\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_list_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 489, in test_user_list_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:40247/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_add_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 823, in test_user_role_add_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:44699/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_role_remove_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 842, in test_user_role_remove_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:38656/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 496, in test_user_update_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:47518/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: test_user_update_password_404 (test_keystoneclient_sql.KcMasterSqlTestCase)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 512, in test_user_update_password_404\n    client = self.get_client(admin=True)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 98, in get_client\n    admin=admin)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_keystoneclient.py\",> line 80, in _client\n    kc.authenticate()\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/client.py\",> line 205, in authenticate\n    token)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/vendor/python-keystoneclient-master/keystoneclient/v2_0/client.py\",> line 180, in get_raw_token_from_identity_service\n    \"%s\" % e)\nAuthorizationFailure: Authorization Failed: <attribute \'message\' of \'exceptions.BaseException\' objects> (HTTP Unable to establish connection to http://localhost:56047/v2.0/tokens)\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on 127.0.0.1:0\nrequests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection (1): localhost\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 1-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 91, in test_1way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nERROR: Make sure both public and admin API work with 2-way ipv6 & SSL.\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/tests/test_ssl.py\",> line 115, in test_2way_ssl_with_ipv6_ok\n    host=\"::1\", port=0)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/test.py\",> line 319, in serveapp\n    server.start(key=\'socket\')\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/keystone/common/wsgi.py\",> line 88, in start\n    socket.SOCK_STREAM)[0]\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 174, in getaddrinfo\n    rrset = resolve(host)\n  File \"<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/lib/python2.6/site-packages/eventlet/support/greendns.py\",> line 133, in resolve\n    raise socket.gaierror(error)\ngaierror: (-5, \'No address associated with hostname\')\n-------------------- >> begin captured logging << --------------------\nkeystone.common.wsgi: DEBUG: Starting .tox/py26/bin/nosetests on ::1:0\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 35.20 secs:\n    7.77    TestTokenRevoking.test_group_membership_changes_revokes_token\n    7.01    KcEssex3TestCase.test_admin_requires_adminness\n    6.92    KcMasterTestCase.test_admin_requires_adminness\n    6.79    TestTokenRevoking.test_deleting_group_grant_revokes_tokens\n    6.72    Kc11TestCase.test_admin_requires_adminness\n----------------------------------------------------------------------\nRan 1272 tests in 471.495s\n\nFAILED (SKIP=82, errors=129)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-keystone-python26-stable-grizzly-centos6/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==0.9.6\nJinja2==2.6\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\nWebTest==2.0.2\nargparse==1.2.1\nbeautifulsoup4==4.1.3\ncolorama==0.2.5\ncoverage==3.6\ndecorator==3.4.0\ndistribute==0.6.34\ndnspython==1.10.0\ndocutils==0.10\neventlet==0.12.1\ngreenlet==0.4.0\nhttplib2==0.8\niso8601==0.1.4\nkeyring==1.2.2\nkeystone==jenkins.periodic.keystone.python26.stable.grizzly.centos6.5\nlogilab-astng==0.24.3\nlogilab-common==0.59.1\nlxml==3.2.0\nmox==0.5.3\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.4\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.1.0\npam==0.1.4\npasslib==1.6.1\npep8==1.3.3\nprettytable==0.7.2\npylint==0.27.0\npysqlite==2.6.3\npython-keystoneclient==0.2.3\npython-ldap==2.3.13\npython-memcached==1.48\npython-swiftclient==1.4.0\nrepoze.lru==0.6\nrequests==1.2.0\nsimplejson==3.2.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nswift==1.8.1\ntermcolor==1.1.0\nunittest2==0.5.1\nwaitress==0.8.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\ngrep: /var/log/auth.log: No such file or directory\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./tests/nose_results.html\n+ \'[\' -f ./tests/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./tests/nose_results.html\n+ passcount=66\n+ \'[\' 66 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.6pE2JCC08P\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/5\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-keystone-python26-stable-grizzly-centos6/5/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Copying console log.\n\n\n','<1671381361.36.1367648129567.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1795768744.10.1377325374347.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-24 06:22:54',0,'2013-08-24 06:22:54',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-nova-python27-stable-grizzly #6','See <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/6/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise26 in workspace <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/>\nCheckout:periodic-nova-python27-stable-grizzly / <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/> - hudson.remoting.Channel at 78bac5c6:precise26\nUsing strategy: Default\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/nova\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/nova\nCommencing build of Revision 2ab1b6a5fa571552fb1d8a5c77312445c07a252a (origin/stable/grizzly)\nChecking out Revision 2ab1b6a5fa571552fb1d8a5c77312445c07a252a (origin/stable/grizzly)\nNo change to record in branch origin/stable/grizzly\n[periodic-nova-python27-stable-grizzly] $ /bin/bash -xe /tmp/hudson4878168970554746923.sh\n+ /usr/local/jenkins/slave_scripts/run-tox.sh 27 openstack nova\n+ version=27\n+ org=openstack\n+ project=nova\n+ [[ -z 27 ]]\n+ [[ -z openstack ]]\n+ [[ -z nova ]]\n+ venv=py27\n+ export NOSE_WITH_XUNIT=1\n+ NOSE_WITH_XUNIT=1\n+ export NOSE_WITH_HTML_OUTPUT=1\n+ NOSE_WITH_HTML_OUTPUT=1\n+ export NOSE_HTML_OUT_FILE=nose_results.html\n+ NOSE_HTML_OUT_FILE=nose_results.html\n++ /bin/mktemp -d\n+ export TMPDIR=/tmp/tmp.2LcrovKwrS\n+ TMPDIR=/tmp/tmp.2LcrovKwrS\n+ trap \'rm -rf /tmp/tmp.2LcrovKwrS\' EXIT\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh pre\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh pre\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack nova\n++ org=openstack\n++ project=nova\n++ [[ -z openstack ]]\n++ [[ -z nova ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ \'[\' openstack == openstack \']\'\n++ \'[\' nova == requirements \']\'\n++ \'[\' openstack == openstack \']\'\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ python setup.py --version\njenkins.periodic.nova.python27.stable.grizzly.6\n+ tox -epy27\nGLOB sdist-make: <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/setup.py>\npy27 create: <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27>\npy27 installdeps: -r<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/pip-requires,> -r<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/tools/test-requires>\npy27 inst: <https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/dist/nova-jenkins.periodic.nova.python27.stable.grizzly.6.zip>\npy27 runtests: commands[0] | python tools/patch_tox_venv.py\npy27 runtests: commands[1] | python setup.py testr --slowest --testr-args=\nrunning testr\nunpack requires a string argument of length 1\nrunning=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ ./nova/tests --list \nerror: testr failed (3)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-nova-python27-stable-grizzly/ws/.tox/py27/bin/python> setup.py testr --slowest --testr-args=\'\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nCheetah==2.4.4\nJinja2==2.7.1\nMarkdown==2.3.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.10.0\ncliff==1.4.3\ncmd2==0.6.5.1\ncoverage==3.6\nd2to1==0.2.10\ndecorator==3.4.0\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.13.0\nextras==0.0.3\nfeedparser==5.1.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\njsonpatch==1.1\njsonpointer==1.0\njsonschema==2.0.0\nkombu==2.5.14\nlogilab-astng==0.24.3\nlogilab-common==0.60.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnova==jenkins.periodic.nova.python27.stable.grizzly.6\nnumpy==1.7.1\noslo.config==1.1.1\nparamiko==1.11.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npyOpenSSL==0.13\npyasn1==0.1.7\npycrypto==2.6\npyflakes==0.7.3\npylint==0.25.2\npyparsing==1.5.7\npython-cinderclient==1.0.5\npython-glanceclient==0.11.0\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-quantumclient==2.2.3\npython-subunit==0.0.14\npytz==2013b\nrepoze.lru==0.6\nrequests==1.2.2\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.3.0\nsqlalchemy-migrate==0.7.2\nstevedore==0.10\nsuds==0.4\ntestrepository==0.0.17\ntesttools==0.9.32\nwarlock==1.0.1\nwebsockify==0.3.0\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ \'[\' -f .testrepository/0.2 \']\'\n+ \'[\' -f .testrepository/0 \']\'\n+ .tox/py27/bin/python /usr/local/jenkins/slave_scripts/subunit2html.py ./subunit_log.txt testr_results.html\nTraceback (most recent call last):\n  File \"/usr/local/jenkins/slave_scripts/subunit2html.py\", line 727, in <module>\n    main()\n  File \"/usr/local/jenkins/slave_scripts/subunit2html.py\", line 702, in main\n    stream = open(subunit_file, \'rb\')\nIOError: [Errno 2] No such file or directory: \'./subunit_log.txt\'\n+ gzip -9 ./subunit_log.txt\ngzip: ./subunit_log.txt: No such file or directory\n+ gzip -9 ./testr_results.html\ngzip: ./testr_results.html: No such file or directory\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\n+ rm -rf /tmp/tmp.2LcrovKwrS\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise26\n[SCP] Trying to create /srv/static/logs/periodic/periodic-nova-python27-stable-grizzly/precise26/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1795769166.0.1352419277604.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-09 00:01:17',0,'2012-11-09 00:01:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-horizon-docs-stable-diablo #87','See <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/87/>\n\n------------------------------------------\nStarted by timer\n[EnvInject] - Loading node environment variables.\nBuilding remotely on oneiric6 in workspace <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/>\nCheckout:periodic-horizon-docs-stable-diablo / <https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/> - hudson.remoting.Channel at 4d4beca0:oneiric6\nUsing strategy: Default\nLast Built Revision: Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://github.com/openstack/horizon.git\ngit --version\ngit version 1.8.0\nFetching upstream changes from git://github.com/openstack/horizon.git\nCommencing build of Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\nChecking out Revision 8cef264638c8f6dac690d30f821378ad56a5f7d3 (origin/stable/diablo)\n[periodic-horizon-docs-stable-diablo] $ /bin/bash -xe /tmp/hudson2652146472962532148.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nERROR: toxini file \'<https://jenkins.openstack.org/job/periodic-horizon-docs-stable-diablo/ws/tox.ini\'> does not exist\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-horizon-docs-stable-diablo/87\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1795900822.6991839.1391108570898.JavaMail.root@cloudwatt.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-01-30 19:02:50',0,'2014-01-30 19:02:50',NULL,'[openstack-dev] [nova] bp proposal: libvirt-resize-disk-down','> In case it hasn\'t been considered yet, shrinking a filesystem can result\n> in terrible fragmentation.  The block allocator in resize2fs does not do\n> a great job of handling this case.  The result will be a very\n> non-optimal file layout and measurably worse performance, especially for\n> drives with a relatively high average seek time.\n\nThis is an interesting point and I really want to get more information \nabout it, I done some search on the manual of resize2fs but nothing.\nAs well, what do you think about to use \"freezero\" after the resize if\navailable on the host, could it fix this kind of problem?\n\nBest,\ns.\n\n\n','<20140130154854.GA20795@shaniqua>',NULL),('<1796033875.36649726.1407413105872.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-08-07 08:05:05',-14400,'2014-08-07 12:05:05',NULL,'[openstack-dev] [NFV] Meeting summary 2014-08-06','Meeting Summary (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.html\nMeeting Log (HTML): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.log.html\nMeeting Summary (TXT): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.txt\nMeeting Log (TXT): http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-08-06-14.00.log.txt\n\nAction items:\n* ACTION: sgordon to email list about alternating schedule (sgordon, 14:11:31)\n* ACTION: sgordon to remove extensible resource tracker from nfv list (for now...) (sgordon, 14:33:27)\n* ACTION: sgordon to update wiki to reflect on track for juno vs outstanding (sgordon, 14:48:16)\n\nNB: Code reviews for Juno are now updating @ http://nfv.russellbryant.net/ again\n\n\n','<710557974.36646277.1407412685579.JavaMail.zimbra@redhat.com>',NULL),('<1796431921.20.1387692147046.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-22 06:02:27',0,'2013-12-22 06:02:27',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n	periodic-heat-python27-grizzly #9','See <https://jenkins01.openstack.org/job/periodic-heat-python27-grizzly/9/changes>\n\n\n\n','<1616078769.5.1387173794621.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1796952897.14663.1410478270182.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-09-11 23:31:09',0,'2014-09-11 23:31:09',NULL,'[openstack-dev] On an API proxy from baremetal to ironic','We manage a fairly large nova-baremetal installation at Yahoo. And while we\'ve developed tools to hit the nova-bm API, we\'re planning to move to ironic without any support for the nova BM API. Definitely no interest in the proxy API from our end.?\nSometimes you just need to let a thing die.?\n-James\n?:)= \n\n     On Wednesday, September 10, 2014 12:51 PM, Ben Nemec <openstack at nemebean.com> wrote:\n   \n\n -----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn 09/10/2014 02:26 PM, Dan Smith wrote:\n>> 1) Is this tested anywhere?? There are no unit tests in the patch\n>> and it\'s not clear to me that there would be any Tempest coverage\n>> of this code path.? Providing this and having it break a couple\n>> of months down the line seems worse than not providing it at all.\n>> This is obviously fixable though.\n> \n> AFAIK, baremetal doesn\'t have any tempest-level testing at all\n> anyway. However, I don\'t think our proxy code breaks, like, ever. I\n> expect that unit tests for this stuff is plenty sufficient.\n\nRight, but this would actually be running against Ironic, which does\nhave Tempest testing.? It might require some client changes to be able\nto hit a Baremetal API instead of Ironic though.\n\n> \n>> 2) If we think maintaining compatibility for existing users is\n>> that important, why aren\'t we proxying everything?? Is it too \n>> difficult/impossible due to the differences between Baremetal\n>> and Ironic?? And if they\'re that different, does it still make\n>> sense to allow one to look like the other?? As it stands, this\n>> isn\'t going to let deployers use their existing tools without\n>> modification anyway.\n> \n> Ideally we\'d proxy everything, based on our current API\n> guarantees. However, I think the compromise of just the show/index\n> stuff came about because it would be extremely easy to do, provide\n> some measure of continuity, and provide us a way to return\n> something nicer for the create/update operations than a 500. It\n> seemed like a completely fair and practical balance.\n\nFair enough.? I\'m still not crazy about it, but since it already\nexists and you say these interfaces don\'t require much maintenance I\nguess that takes care of my major concerns.\n\n- -Ben\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJUEKsAAAoJEDehGd0Fy7uqM3YIAKaqJPCwyS1l3NoKhj7qmGlT\nwqdPspI2LyVgnHY62iq73O6FSpmEp0JzEcuBxHi21gK3tIBrvRr+mOsNtGNoj7Of\n84YmcFyWgBR75rRDSLLnVu7rs1LJ0jpGwVzWDi/vmzVoxWdNXwSx223mQTwi9gJ3\nn+Rgf0HYOKUwGgDVDpyWFv1DUBo/Hgc3ZdG8pzwnEqONN0bmRlBQMZRJrl2+8Jvj\nzTYxDmunWp8FbTdKE80JcQ1YQYjmg4anCzaH0MEwax+j6lxu8MwEtM61ISJ7vV3L\nKqTSW2OrjtqKY/9oHSnKiBuD9RInyWhML6pq8jsniadPw+TOatJ4PZaCyTS9XvI=\n=cSmK\n-----END PGP SIGNATURE-----\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n   \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/42ad60dc/attachment.html>\n\n','<5410AB03.1030307@nemebean.com>',NULL),('<1796953384.22092470.1370882735277.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-10 12:45:35',-14400,'2013-06-10 16:45:35',NULL,'[openstack-dev] Discussion of Nova Bug 1189543 (Setting drive error\n	policy in Nova)','(https://bugs.launchpad.net/nova/+bug/1189543)\n\nIt was proposed at RedHat (https://bugzilla.redhat.com/show_bug.cgi?id=865336) that we should explicitly set Libvirt to stop VMs on drive read/write errors, and then detect that and somehow set a piece of state in nova.\n\nActually stopping on errors is supported via libvirt\'s error_policy (for both, override read error policy with rerror_policy) on the driver tag for the disk specification (http://libvirt.org/formatdomain.html#elementsDisks).  According to the libvirt doc, the default setting for libvirt is REPORT (which, according to the qemu documentation, means report it to the guest OS: http://qemu.weilnetz.de/qemu-doc.html#sec_005finvocation).\n\nSo, injecting it in to the configuration should be pretty easy, but we probably also want to provide a configuration option too (which is easy enough as well).\n\nAs for state, perhaps we could use the metadata tag (http://libvirt.org/formatdomain.html#elementsMetadata) and have to store a flag, but we\'d need to figure out how to detect if the stopping of the VM was intentional or accidental (we could manually set the flag to \"on_purpose\" whenever we intentionally shut down the vm, then look and see if the vm is shut down but on_purpose is not set).  I was looking through, and I didn\'t see any hooks in libvirt for this purpose, but I may have missed one.  Ideas?\n\nBest Regards,\nSolly Ross\n\n\n','<1473615844.22092151.1370882672603.JavaMail.root@redhat.com>',NULL),('<1798328645.19.1352505962288.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2012-11-10 00:06:02',0,'2012-11-10 00:06:02',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python27-stable-diablo #88','See <https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/88/>\n\n------------------------------------------\n[...truncated 263 lines...]\n    test_get_image_details_by_name                               OK    0.05\n    test_get_image_details_by_property                           OK    0.06\n    test_get_image_details_by_status                             OK    0.06\n    test_get_image_details_invalid_marker                        OK    0.04\n    test_get_image_details_marker_limit                          OK    0.07\n    test_get_image_details_sort_disk_format_asc                  OK    0.07\n    test_get_image_details_with_maximum_size                     OK    0.06\n    test_get_image_details_with_minimum_size                     OK    0.05\n    test_get_image_index                                         OK    0.05\n    test_get_image_index_by_name                                 OK    0.06\n    test_get_image_index_invalid_marker                          OK    0.04\n    test_get_image_index_limit                                   OK    0.06\n    test_get_image_index_limit_None                              OK    0.06\n    test_get_image_index_marker                                  OK    0.07\n    test_get_image_index_marker_limit                            OK    0.07\n    test_get_image_members                                       OK    0.04\n    test_get_image_members_not_existing                          OK    0.04\n    test_get_image_non_existing                                  OK    0.05\n    test_get_index_sort_container_format_desc                    OK    0.07\n    test_get_index_sort_created_at_asc                           OK    0.06\n    test_get_index_sort_disk_format_asc                          OK    0.06\n    test_get_index_sort_id_desc                                  OK    0.07\n    test_get_index_sort_name_asc                                 OK    0.07\n    test_get_index_sort_size_asc                                 OK    0.06\n    test_get_index_sort_status_desc                              OK    0.07\n    test_get_index_sort_updated_at_desc                          OK    0.07\n    test_get_member_images                                       OK    0.04\n    test_replace_members                                         OK    0.04\n    test_update_image                                            OK    0.06\n    test_update_image_not_existing                               OK    0.04\nTestConfig\n    test_common_options                                          OK    0.00\n    test_parse_options                                           Usage: nosetests [options]\n\nnosetests: error: no such option: --unknown\nOK    0.00\nTestContext\n    test_anon_private                                            OK    0.00\n    test_anon_private_owned                                      OK    0.00\n    test_anon_public                                             OK    0.00\n    test_anon_public_owned                                       OK    0.00\n    test_anon_shared                                             OK    0.00\n    test_auth_private                                            OK    0.00\n    test_auth_private_owned                                      OK    0.00\n    test_auth_private_unowned                                    OK    0.00\n    test_auth_public                                             OK    0.00\n    test_auth_public_owned                                       OK    0.00\n    test_auth_public_unowned                                     OK    0.00\n    test_auth_sharable                                           OK    0.01\n    test_auth_sharable_admin                                     OK    0.00\n    test_auth_sharable_can_share                                 OK    0.00\n    test_auth_sharable_cannot_share                              OK    0.00\n    test_auth_sharable_owned                                     OK    0.00\n    test_empty_private                                           OK    0.00\n    test_empty_private_owned                                     OK    0.00\n    test_empty_public                                            OK    0.00\n    test_empty_public_owned                                      OK    0.00\n    test_empty_shared                                            OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\nTestHttpStore\n    test_http_delete_raise_error                                 OK    0.00\n    test_http_get                                                OK    0.00\n    test_https_get                                               OK    0.00\nTestImageCache\n    test_can_be_disabled                                         OK    0.00\n    test_can_be_enabled                                          OK    0.00\n    test_enabled_defaults_to_false                               OK    0.00\nTestMigrations\n    test_no_data_loss_2_to_3_to_2                                OK    0.19\n    test_version_control_existing_db                             OK    0.76\n    test_walk_versions                                           OK    0.68\nAuthorsTestCase\n    test_authors_up_to_date                                      OK    0.00\nTestInvalidNotifier\n    test_cannot_create                                           OK    0.00\nTestLoggingNotifier\n    test_erorr                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestNoopNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestRabbitNotifier\n    test_error                                                   OK    0.00\n    test_info                                                    OK    0.00\n    test_warn                                                    OK    0.00\nTestStore\n    test_add                                                     OK    0.00\n    test_add_already_existing                                    OK    0.00\n    test_add_host_variations                                     OK    0.01\n    test_delete                                                  OK    0.00\n    test_delete_non_existing                                     OK    0.00\n    test_get                                                     OK    0.00\n    test_get_non_existing                                        OK    0.00\n    test_no_access_key                                           OK    0.00\n    test_no_host                                                 OK    0.00\n    test_no_secret_key                                           OK    0.00\nTestSkipExamples\n    test_001_increase_test_counter                               OK    0.00\n    test_002_increase_test_counter                               OK    0.00\n    test_003_verify_test_counter                                 OK    0.00\n    test_skip_if_example                                         SKIP\n    test_skip_test_example                                       SKIP\n    test_skip_unless_example                                     SKIP\nTestStoreLocation\n    test_bad_store_scheme                                        OK    0.00\n    test_filesystem_store_location                               OK    0.00\n    test_get_location_from_uri_back_to_uri                       OK    0.00\n    test_get_store_from_scheme                                   OK    0.00\n    test_http_store_location                                     OK    0.00\n    test_s3_store_location                                       OK    0.00\n    test_swift_store_location                                    OK    0.00\nNone\n    None                                                         ERROR  0.02\nTestUtils\n    test_boolean_header_values                                   OK    0.00\n    test_data_passed_properly_through_headers                    OK    0.00\n    test_headers_are_unicode                                     OK    0.00\nVersionsTest\n    test_client_handles_versions                                 OK    0.00\n    test_get_version_list                                        OK    0.00\nJSONRequestDeserializerTest\n    test_default_no_body                                         OK    0.00\n    test_default_with_body                                       OK    0.00\n    test_from_json                                               OK    0.00\n    test_has_body_has_content_length                             OK    0.00\n    test_has_body_no_content_length                              OK    0.00\n    test_has_body_zero_content_length                            OK    0.00\n    test_no_body_no_content_length                               OK    0.00\nJSONResponseSerializerTest\n    test_default                                                 OK    0.00\n    test_to_json                                                 OK    0.00\nRequestTest\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_from_accept_json                           OK    0.00\n    test_content_type_from_accept_json_xml_quality               OK    0.00\n    test_content_type_from_accept_xml                            OK    0.00\n    test_content_type_from_accept_xml_json                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\nResourceTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_default                                        OK    0.00\n    test_dispatch_no_default                                     OK    0.00\n    test_get_action_args                                         OK    0.00\n\n======================================================================\nERROR: Failure: ImportError (No module named client)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/loader.py\",> line 390, in loadTestsFromName\n    addr.filename, addr.module)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 39, in importFromPath\n    return self.importFromDir(dir_path, fqname)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/local/lib/python2.7/site-packages/nose/importer.py\",> line 86, in importFromDir\n    mod = load_module(part_fqname, fh, filename, desc)\n  File \"<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/glance/tests/unit/test_swift_store.py\",> line 28, in <module>\n    import swift.common.client\nImportError: No module named client\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 38.15 secs:\n    11.62    TestScrubber.test_delayed_delete\n    8.67    TestBinGlance.test_results_filtering\n    6.62    TestBinGlance.test_results_pagination\n    6.05    TestBinGlance.test_results_sorting\n    5.19    TestBinGlance.test_add_list_update_list\n----------------------------------------------------------------------\nRan 338 tests in 97.307s\n\nFAILED (SKIP=38, errors=1)\nERROR: InvocationError: \'<https://jenkins.openstack.org/job/periodic-glance-python27-stable-diablo/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nJinja2==2.6\nPasteDeploy==1.5.0\nPygments==1.5\nRoutes==1.13\nSQLAlchemy==0.6.9\nSphinx==1.1.3\nTempita==0.5.1\nWebOb==1.0.8\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.6.0\nbzr==2.6b2\ncolorama==0.2.4\ncoverage==3.5.3\ndecorator==3.4.0\ndistribute==0.6.28\ndocutils==0.9.1\neventlet==0.9.17\nglance==2011.3.2\ngreenlet==0.4.0\nhttplib2==0.7.6\nkombu==2.4.8\nmox==0.5.3\nnose==1.2.1\nnose-exclude==0.1.9\nnosexcover==1.0.7\nopenstack.nose-plugin==0.11\npep8==0.6.1\nrepoze.lru==0.6\nsqlalchemy-migrate==0.6.1\nswift==1.7.4\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.6.4\n+ echo ======================================================================\n======================================================================\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=\n+ \'[\' -f \'\' \']\'\n+ echo\n\n+ echo \'WARNING: Unable to find  to confirm results!\'\nWARNING: Unable to find  to confirm results!\n+ echo\n\n+ exit 1\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] No file(s) found: **/*nose_results.html\n[SCP] \'**/*nose_results.html\' doesn\'t match anything: \'**\' exists but not \'**/*nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-diablo/88\n[SCP] Copying console log.\n\n\n','<1984334952.4.1352419519655.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1798547090.2.1382508748800.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-23 06:12:28',0,'2013-10-23 06:12:28',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #38','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/38/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4d48450>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52d7bd0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x52d7bd0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-1de27444-1aee-4673-9a39-1f6815d5265e\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 417, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x2d039b0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x2d039b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x2d039b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x2d039b0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2013-10-22T06:11:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'22\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'22\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2013-10-24T06:11:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'24\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'24\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:11:49+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'+01:00\', \'second\': u\'49\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2013-10-25T06:11:49-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'10\', \'timezone\': u\'-01:00\', \'second\': u\'49\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'25\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'25\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2013-10-26T06:11:49Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'10\', \'timezone\': u\'Z\', \'second\': u\'49\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'26\', \'minute\': u\'11\'} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'26\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'49\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5e82650>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19c2b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 90.23 secs:\n    26.16    TestScrubber.test_scrubber_app\n    20.54    TestScrubber.test_delayed_delete\n    14.73    TestGlanceControl.test_reload\n    14.50    TestGlanceControl.test_respawn\n    14.29    TestRootApi.test_version_configurations\n----------------------------------------------------------------------\nRan 1109 tests in 625.464s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.0\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.38\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.0\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.0\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.32\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.EevrhV0mTE\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/38/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-4/38\n[SCP] Copying console log.\n\n\n','<1764246812.38.1382422468330.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1799642404.61.1386741817185.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:03:37',0,'2013-12-11 06:03:37',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-docs-havana #5','See <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/5/>\n\n------------------------------------------\nStarted by user anonymous\n[EnvInject] - Loading node environment variables.\nBuilding remotely on precise7 in workspace <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/>\nCheckout:periodic-heat-docs-havana / <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/> - hudson.remoting.Channel at 6e8cc7de:precise7\nUsing strategy: Default\nLast Built Revision: Revision 3fc572eb9ccb3f1ab948a2bff18e35d6d6b4a088 (origin/stable/havana)\nWiping out workspace first.\nCloning the remote Git repository\nCloning repository git://git.openstack.org/openstack/heat\ngit --version\ngit version 1.7.9.5\nFetching upstream changes from git://git.openstack.org/openstack/heat\nCommencing build of Revision 3fc572eb9ccb3f1ab948a2bff18e35d6d6b4a088 (origin/stable/havana)\nChecking out Revision 3fc572eb9ccb3f1ab948a2bff18e35d6d6b4a088 (origin/stable/havana)\n[periodic-heat-docs-havana] $ /bin/bash -xe /tmp/hudson1710935687418555885.sh\n+ /usr/local/jenkins/slave_scripts/run-docs.sh openstack heat\n+ org=openstack\n+ project=heat\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack heat /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=heat\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z heat ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack heat\n++ org=openstack\n++ project=heat\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack heat /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=heat\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z heat ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/heat /opt/requirements/projects.txt\nopenstack/heat\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/requirements.txt,> -r<https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/test-requirements.txt>\nvenv inst: <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/.tox/dist/heat-jenkins.periodic.heat.docs.havana.5.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/doc/build/html>\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-docs-havana/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-docs-havana/precise7\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-docs-havana/precise7/5\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<179f1fb2f51e468c92d57e17050f91c7@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-05 11:26:28',-21600,'2014-02-05 17:26:28',NULL,'[openstack-dev] [Openstack-dev] [Oslo] [Fuel] [Fuel-dev]\n	Openstack services should support SIGHUP signal','On 2014-02-05 10:58, Bogdan Dobrelya wrote:\n> Hi, stackers.\n> I believe Openstack services from all projects should support SIGHUP \n> for\n> effective log/config files handling w/o unnecessary restarts.\n> (See https://bugs.launchpad.net/oslo/+bug/1276694)\n> \n> \'Smooth reloads\'(kill -HUP) are much better than \'disturbing restarts\',\n> aren\'t they?\n\nI believe Oslo already has support for this: \nhttps://github.com/openstack/oslo-incubator/commit/825ace5581fbb416944acae62f51c489ed93b9c9\n\nAs such, I\'m going to mark that bug invalid against Oslo, but please \nfeel free to add other projects to it that need to start using the \nfunctionality (or tell me I\'m completely wrong and that doesn\'t do what \nyou want :-).\n\n-Ben\n\n\n','<52F26DB3.2040608@mirantis.com>',NULL),('<17a03145f0f67dce991e6668fca23161@cse.iitb.ac.in>','http://lists.openstack.org/pipermail/openstack',NULL,'2015-01-06 14:26:05',19800,'2015-01-06 08:56:05',NULL,'[Openstack] Openstack nova free disk issue','Hi All,\nI have a multi node setup of openstack juno on centos 7. After I \ninstantiate multiple VMs and check the nova-compute.log on compute nodes \nit shows a negative value for free disks even though the the physical \nsystem has a lot of free memory\n\non the physical system. df -h\n\nFilesystem               Size  Used Avail Use% Mounted on\n/dev/mapper/centos-root   50G  2.0G   49G   4% /\ndevtmpfs                  16G     0   16G   0% /dev\ntmpfs                     16G     0   16G   0% /dev/shm\ntmpfs                     16G  281M   16G   2% /run\ntmpfs                     16G     0   16G   0% /sys/fs/cgroup\n/dev/mapper/centos-home  865G   33M  865G   1% /home\n/dev/sda1                494M  137M  358M  28% /boot\n\nnova-compute.log on compute node:\n\n2015-01-06 11:00:28.756 8123 AUDIT nova.compute.resource_tracker [-] \nTotal physical ram (MB): 31911, total allocated virtual ram (MB): 17920\n2015-01-06 11:00:28.756 8123 AUDIT nova.compute.resource_tracker [-] \nFree disk (GB): -113\n2015-01-06 11:00:28.757 8123 AUDIT nova.compute.resource_tracker [-] \nTotal usable vcpus: 16, total allocated vcpus: 10\n\nWhat is the issue and how can I resolve it? Please help.\n\nThanks,\n\nPriyanka\n\n\n\n\n',NULL,NULL),('<17A79E69-7E5E-4721-9753-603D020AB178@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-21 17:20:03',25200,'2014-03-21 10:20:03',NULL,'[openstack-dev] [Mistral] Local vs. Scalable Engine','Alright, thanks Winson!\n\nTeam, please review.\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\nOn 21 Mar 2014, at 06:43, W Chan <m4d.coder at gmail.com> wrote:\n\n> I submitted a rough draft for review @ https://review.openstack.org/#/c/81941/.  Instead of using the pecan hook, I added a class property for the transport in the abstract engine class.  On the pecan app setup, I passed the shared transport to the engine on load.  Please provide feedback.  Thanks.\n> \n> \n> On Mon, Mar 17, 2014 at 9:37 AM, Ryan Petrello <ryan.petrello at dreamhost.com> wrote:\n> Changing the configuration object at runtime is not thread-safe.  If you want to share objects with controllers, I?d suggest checking out Pecan?s hook functionality.\n> \n> http://pecan.readthedocs.org/en/latest/hooks.html#implementating-a-pecan-hook\n> \n> e.g.,\n> \n> class SpecialContextHook(object):\n> \n>     def __init__(self, some_obj):\n>         self.some_obj = some_obj\n> \n>     def before(self, state):\n>         # In any pecan controller, `pecan.request` is a thread-local webob.Request instance,\n>         # allowing you to access `pecan.request.context[?foo?]` in your controllers.  In this example,\n>         # self.some_obj could be just about anything - a Python primitive, or an instance of some class\n>         state.request.context = {\n>             ?foo?: self.some_obj\n>         }\n> \n> ...\n> \n> wsgi_app = pecan.Pecan(\n>     my_package.controllers.root.RootController(),\n>     hooks=[SpecialContextHook(SomeObj(1, 2, 3))]\n> )\n> \n> ---\n> Ryan Petrello\n> Senior Developer, DreamHost\n> ryan.petrello at dreamhost.com\n> \n> On Mar 14, 2014, at 8:53 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> \n> > Take a look at method get_pecan_config() in mistral/api/app.py. It?s where you can pass any parameters into pecan app (see a dictionary ?cfg_dict? initialization). They can be then accessed via pecan.conf as described here: http://pecan.readthedocs.org/en/latest/configuration.html#application-configuration. If I understood the problem correctly this should be helpful.\n> >\n> > Renat Akhmerov\n> > @ Mirantis Inc.\n> >\n> >\n> >\n> > On 14 Mar 2014, at 05:14, Dmitri Zimine <dz at stackstorm.com> wrote:\n> >\n> >> We have access to all configuration parameters in the context of api.py. May be you don\'t pass it but just instantiate it where you need it? Or I may misunderstand what you\'re trying to do...\n> >>\n> >> DZ>\n> >>\n> >> PS: can you generate and update mistral.config.example to include new oslo messaging options? I forgot to mention it on review on time.\n> >>\n> >>\n> >> On Mar 13, 2014, at 11:15 AM, W Chan <m4d.coder at gmail.com> wrote:\n> >>\n> >>> On the transport variable, the problem I see isn\'t with passing the variable to the engine and executor.  It\'s passing the transport into the API layer.  The API layer is a pecan app and I currently don\'t see a way where the transport variable can be passed to it directly.  I\'m looking at https://github.com/stackforge/mistral/blob/master/mistral/cmd/api.py#L50 and https://github.com/stackforge/mistral/blob/master/mistral/api/app.py#L44.  Do you have any suggestion?  Thanks.\n> >>>\n> >>>\n> >>> On Thu, Mar 13, 2014 at 1:30 AM, Renat Akhmerov <rakhmerov at mirantis.com> wrote:\n> >>>\n> >>> On 13 Mar 2014, at 10:40, W Chan <m4d.coder at gmail.com> wrote:\n> >>>\n> >>>>    ? I can write a method in base test to start local executor.  I will do that as a separate bp.\n> >>> Ok.\n> >>>\n> >>>>    ? After the engine is made standalone, the API will communicate to the engine and the engine to the executor via the oslo.messaging transport.  This means that for the \"local\" option, we need to start all three components (API, engine, and executor) on the same process.  If the long term goal as you stated above is to use separate launchers for these components, this means that the API launcher needs to duplicate all the logic to launch the engine and the executor. Hence, my proposal here is to move the logic to launch the components into a common module and either have a single generic launch script that launch specific components based on the CLI options or have separate launch scripts that reference the appropriate launch function from the common module.\n> >>> Ok, I see your point. Then I would suggest we have one script which we could use to run all the components (any subset of of them). So for those components we specified when launching the script we use this local transport. Btw, scheduler eventually should become a standalone component too, so we have 4 components.\n> >>>\n> >>>>    ? The RPC client/server in oslo.messaging do not determine the transport.  The transport is determine via oslo.config and then given explicitly to the RPC client/server.  https://github.com/stackforge/mistral/blob/master/mistral/engine/scalable/engine.py#L31 and https://github.com/stackforge/mistral/blob/master/mistral/cmd/task_executor.py#L63 are examples for the client and server respectively.  The in process Queue is instantiated within this transport object from the fake driver.  For the \"local\" option, all three components need to share the same transport in order to have the Queue in scope. Thus, we will need some method to have this transport object visible to all three components and hence my proposal to use a global variable and a factory method.\n> >>> I?m still not sure I follow your point here.. Looking at the links you provided I see this:\n> >>>\n> >>> transport = messaging.get_transport(cfg.CONF)\n> >>>\n> >>> So my point here is we can make this call once in the launching script and pass it to engine/executor (and now API too if we want it to be launched by the same script). Of course, we?ll have to change the way how we initialize these components, but I believe we can do it. So it?s just a dependency injection. And in this case we wouldn?t need to use a global variable. Am I still missing something?\n> >>>\n> >>>\n> >>> Renat Akhmerov\n> >>> @ Mirantis Inc.\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>>\n> >>>\n> >>> _______________________________________________\n> >>> OpenStack-dev mailing list\n> >>> OpenStack-dev at lists.openstack.org\n> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >>\n> >> _______________________________________________\n> >> OpenStack-dev mailing list\n> >> OpenStack-dev at lists.openstack.org\n> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> >\n> > _______________________________________________\n> > OpenStack-dev mailing list\n> > OpenStack-dev at lists.openstack.org\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140321/1acc6b92/attachment.html>\n\n','<CABNy8O5QKEgmnkCKoeEbcMFKLdPTEpLcptJBUz41+6+9jPYPXg@mail.gmail.com>',NULL),('<17a9a7a75884551222d9df5a8366dbee@localhost>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-02-13 10:56:28',-21600,'2014-02-13 16:56:28',NULL,'[openstack-dev] Devstack installation failed with CINDER\n	installation',' \n\nLooks like a transient pypi failure. You can either wait for pypi to get\nits act together or configure pip to use the pypi.openstack.org mirror.\nThis is the relevant part of my ~/.pip/pip.conf file: \n\n[fedora at openstack .pip]$ cat pip.conf \n[global]\nindex-url = http://pypi.openstack.org/openstack \n\nI think that\'s enough to make it use pypi.openstack.org. \n\n-Ben \n\nOn 2014-02-13 03:31, trinath.somanchi at freescale.com wrote: \n\n> Hi stackers- \n> \n> I have an issue while installing devstack on my machine. \n> \n> While configuring cider root wrap, devstack installation failed. \n> \n> Here is the complete log \n> \n> .dEYRz -e /opt/stack/cinder \n> \n> Obtaining file:///opt/stack/cinder \n> \n> Running setup.py egg_info for package from file:///opt/stack/cinder \n> \n> [pbr] Reusing existing SOURCES.txt \n> \n> Requirement already satisfied (use --upgrade to upgrade): pbr>=0.6,<1.0 in /opt/stack/pbr (from cinder==2014.1.dev166.g893aaa9) \n> \n> Requirement already satisfied (use --upgrade to upgrade): amqplib>=0.6.1 in /usr/lib/python2.7/dist-packages (from cinder==2014.1.dev166.g893aaa9) \n> \n> Requirement already satisfied (use --upgrade to upgrade): anyjson>=0.3.3 in /usr/lib/python2.7/dist-packages (from cinder==2014.1.dev166.g893aaa9) \n> \n> Requirement already satisfied (use --upgrade to upgrade): Babel>=1.3 in /usr/local/lib/python2.7/dist-packages/Babel-1.3-py2.7.egg (from cinder==2014.1.dev166.g893aaa9) \n> \n> Requirement already satisfied (use --upgrade to upgrade): eventlet>=0.13.0 in /usr/lib/python2.7/dist-packages (from cinder==2014.1.dev166.g893aaa9) \n> \n> Requirement already satisfied (use --upgrade to upgrade): greenlet>=0.3.2 in /usr/lib/python2.7/dist-packages (from cinder==2014.1.dev166.g893aaa9) \n> \n> Downloading/unpacking iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Could not fetch URL https://pypi.python.org/simple/iso8601/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed> \n> \n> Will skip URL https://pypi.python.org/simple/iso8601/ when looking for download links for iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Could not fetch URL https://pypi.python.org/simple/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed> \n> \n> Will skip URL https://pypi.python.org/simple/ when looking for download links for iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Cannot fetch index base URL https://pypi.python.org/simple/ \n> \n> Could not fetch URL https://pypi.python.org/simple/iso8601/: There was a problem confirming the ssl certificate: <urlopen error [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed> \n> \n> Will skip URL https://pypi.python.org/simple/iso8601/ when looking for download links for iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Could not find any downloads that satisfy the requirement iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Cleaning up... \n> \n> No distributions at all found for iso8601>=0.1.8 (from cinder==2014.1.dev166.g893aaa9) \n> \n> Storing complete log in /home/stack/.pip/pip.log \n> \n> + safe_chown -R stack /opt/stack/cinder/cinder.egg-info \n> \n> + _safe_permission_operation chown -R stack /opt/stack/cinder/cinder.egg-info \n> \n> + args=($@) \n> \n> + local args \n> \n> + local last \n> \n> + local sudo_cmd \n> \n> + local dir_to_check \n> \n> + let \'last=4 - 1\' \n> \n> + dir_to_check=/opt/stack/cinder/cinder.egg-info \n> \n> + \'[\' \'!\' -d /opt/stack/cinder/cinder.egg-info \']\' \n> \n> + is_nfs_directory /opt/stack/cinder/cinder.egg-info \n> \n> ++ stat -f -L -c %T /opt/stack/cinder/cinder.egg-info \n> \n> + local mount_type=ext2/ext3 \n> \n> + test ext2/ext3 == nfs \n> \n> + [[ False = True ]] \n> \n> + sudo_cmd=sudo \n> \n> + sudo chown -R stack /opt/stack/cinder/cinder.egg-info \n> \n> + \'[\' True = True \']\' \n> \n> + \'[\' 0 -eq 0 \']\' \n> \n> + cd /opt/stack/cinder \n> \n> + git reset --hard \n> \n> HEAD is now at 893aaa9 Merge \"GlusterFS: Fix create/restore backup\" \n> \n> + configure_cinder \n> \n> + [[ ! -d /etc/cinder ]] \n> \n> + sudo chown stack /etc/cinder \n> \n> + cp -p /opt/stack/cinder/etc/cinder/policy.json /etc/cinder \n> \n> + configure_cinder_rootwrap \n> \n> ++ get_rootwrap_location cinder \n> \n> ++ local module=cinder \n> \n> +++ get_python_exec_prefix \n> \n> +++ is_fedora \n> \n> +++ [[ -z Ubuntu ]] \n> \n> +++ \'[\' Ubuntu = Fedora \']\' \n> \n> +++ \'[\' Ubuntu = \'Red Hat\' \']\' \n> \n> +++ \'[\' Ubuntu = CentOS \']\' \n> \n> +++ is_suse \n> \n> +++ [[ -z Ubuntu ]] \n> \n> +++ \'[\' Ubuntu = openSUSE \']\' \n> \n> +++ \'[\' Ubuntu = \'SUSE LINUX\' \']\' \n> \n> +++ echo /usr/local/bin \n> \n> ++ echo /usr/local/bin/cinder-rootwrap \n> \n> + CINDER_ROOTWRAP=/usr/local/bin/cinder-rootwrap \n> \n> + [[ ! -x /usr/local/bin/cinder-rootwrap ]] \n> \n> ++ get_rootwrap_location oslo \n> \n> ++ local module=oslo \n> \n> +++ get_python_exec_prefix \n> \n> +++ is_fedora \n> \n> +++ [[ -z Ubuntu ]] \n> \n> +++ \'[\' Ubuntu = Fedora \']\' \n> \n> +++ \'[\' Ubuntu = \'Red Hat\' \']\' \n> \n> +++ \'[\' Ubuntu = CentOS \']\' \n> \n> +++ is_suse \n> \n> +++ [[ -z Ubuntu ]] \n> \n> +++ \'[\' Ubuntu = openSUSE \']\' \n> \n> +++ \'[\' Ubuntu = \'SUSE LINUX\' \']\' \n> \n> +++ echo /usr/local/bin \n> \n> ++ echo /usr/local/bin/oslo-rootwrap \n> \n> + CINDER_ROOTWRAP=/usr/local/bin/oslo-rootwrap \n> \n> + [[ ! -x /usr/local/bin/oslo-rootwrap ]] \n> \n> + die 190 \'No suitable rootwrap found.\' \n> \n> + local exitcode=0 \n> \n> + set +o xtrace \n> \n> [Call Trace] \n> \n> ./stack.sh:711:configure_cinder \n> \n> /home/stack/devstack/lib/cinder:238:configure_cinder_rootwrap \n> \n> /home/stack/devstack/lib/cinder:190:die \n> \n> [ERROR] /home/stack/devstack/lib/cinder:190 No suitable rootwrap found. \n> \n> Kindly help me resolve the issue. \n> \n> -- \n> \n> Trinath Somanchi - B39208 \n> \n> trinath.somanchi at freescale.com | extn: 4048 \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [1]\n\n \n\nLinks:\n------\n[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140213/20c079fe/attachment.html>\n\n','<39909bf2afb74508bc3be5b4f495d0a5@BN1PR03MB153.namprd03.prod.outlook.com>',NULL),('<17AEA3BD-5946-4EA9-A2BD-1E9C3B547C80@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-12-14 15:01:46',-28800,'2012-12-14 23:01:46',NULL,'[openstack-dev] [Nova] Flavor ID consistency','\nOn Dec 13, 2012, at 5:09 AM, \"Gurjar, Unmesh\" <Unmesh.Gurjar at nttdata.com> wrote:\n\n> Hi,\n>  \n> I would like to gather some thoughts for fixing the issue https://bugs.launchpad.net/python-novaclient/+bug/1089299.\n>  \n> Issues:\n> 1.       The documentation (http://api.openstack.org/api-ref.html) and the CLI help text (for flavor-create) suggests that only a unique integer value is acceptable as flavor identifier. However, a flavor can be created by specifying a non-integer identifier. Also, if the create flavor API is not provided with an identifier, it generates a UUID (alphanumeric) identifier. Does the documentation and help text need a relook?\n\ndocs need to be updated\n\n> 2.       If alphanumeric identifiers are allowed, the CLI failure (for instance of flavor with non-integer and non-UUID identifier) on ?show <instance-id>? needs a fix?\n\nyes this should be fixed. It should look by name and then \'flavorid\' which is a string\n>  \n> Is fixing the CLI failure on ?show? command the correct fix for this issue?\n\nyes\n\n>  \n> Another related issue is the absence of an Update Flavor API. Due to this, what currently happens is when a user edits a flavor from the Dashboard, a new flavor gets created which has a UUID (and the original flavor ID is marked deleted). Are there any specific reasons for this behavior?\n\nWe still don\'t copy flavor data into the instance so changing a flavor after instances have been booted from it is problematic\n\n>  \n> Thanks & Regards,\n> Unmesh Gurjar | Lead Engineer | NTT DATA Global Technology Services Private Limited | w. +91.20.6604.1500 x 379 | m. +91.982.324.7631 |unmesh.gurjar at nttdata.com | Learn more at nttdata.com/americas\n>  \n> \n> ______________________________________________________________________\n> Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding\n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121214/3481aa47/attachment.html>\n\n','<C2F1FD20FE83284AA0E9E36639ECDAEB0170A553@MAIL703.KDS.KEANE.COM>',NULL),('<17BF5497-CC71-420F-A542-358574070C59@rackspace.com>','http://lists.openstack.org/pipermail/openstack-docs',NULL,'2014-08-14 18:49:10',0,'2014-08-14 18:49:10',NULL,'[Openstack-docs] Internet capitalized?','This is how I understand it...\n\nThe Internet : is the network  we use to access twitter?etc.\nAn internet : is an interconnected network ? the biggest of which is the Internet.\n\n-jOrGe W.\n\n\nOn Aug 14, 2014, at 1:36 PM, Anne Gentle <anne at openstack.org> wrote:\n\n> \n> \n> \n> On Thu, Aug 14, 2014 at 1:35 PM, Matt Kassawara <mkassawara at gmail.com> wrote:\n> I think we should capitalize it, but at the end of the day it probably doesn\'t matter as long as we\'re consistent. :)\n> \n> P.S. - Can you add it to the conventions?\n> \n> Since we have a valid reference (IBM), I don\'t want to keep adding to our conventions -- do you know how long that\'ll get? :)\n>  \n> \n> \n> On Thu, Aug 14, 2014 at 1:00 PM, Andreas Jaeger <aj at suse.com> wrote:\n> Diane asked in one review how to capitalize Internet, she noticed that\n> we\'re not consistent.\n> \n> Looking at the Operations Guide (following O\'Reilly conventions) and the\n> IBM Style Guide (pointing to\n> http://www-01.ibm.com/software/globalization/terminology/i.html), I\n> choose to capitalize it and send a patch:\n> https://review.openstack.org/#/c/114279/\n> \n> If you have strong arguments for not capitalizing it, please speak up,\n> \n> Andreas\n> --\n>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi\n>   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany\n>    GF: Jeff Hawn,Jennifer Guild,Felix Imend?rffer,HRB16746 (AG N?rnberg)\n>     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126\n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n> \n> \n> _______________________________________________\n> Openstack-docs mailing list\n> Openstack-docs at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs\n\n\n\n','<CAD0KtVEGHxa3UE5Rb8kACmexUUHn-fOt0EKLGxOdmwRXLOSxfA@mail.gmail.com>',NULL),('<17BFC57E-D410-4776-B8A7-98EF302C2F9B@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-01-23 20:35:54',0,'2013-01-23 20:35:54',NULL,'[openstack-dev] [marconi] Meeting agenda for Thursday at 19:00','The Marconi project team holds a meeting in #openstack-meeting-alt on Thursdays at 1900 UTC.\n\nThe next meeting is this Thursday, Jan 24. Let me know if you have any topics you\'d like to add to the agenda.\n\n## Agenda (30-60 mins): ##\n\n* Review last week\'s actions\n  * kgriffs to kick the tires on Pecan\n* Review the [[https://launchpad.net/marconi/+milestone/grizzly-1|g1 milestone]<https://launchpad.net/marconi/+milestone/grizzly-1|g1%20milestone]>].\n* Decide whether to support tags or some other fanout mechanism, or just stick with N-queue approach (for v1.0 at least)\n* Consider splitting the API into two namespaces, one for work queuing and one for eventing\n* Decide whether client state should be based on timestamps or markers (or make one optional)\n* Talk about the state of XML support in OpenStack and decide where we stand on the issue.\n* Open discussion\n\n\n## See also: ##\n\n* https://launchpad.net/marconi\n* http://wiki.openstack.org/Meetings/Marconi\n\n\nCheers,\n\nKurt Griffiths | Rackspace | kgriffs | mail at kgriffs.com<mailto:mail at kgriffs.com>\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130123/24dfdabf/attachment.html>\n\n',NULL,NULL),('<17C07465-AEC9-4BE5-833B-235F6DB630F3@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-18 21:34:30',14400,'2013-07-18 17:34:30',NULL,'[openstack-dev] [Savanna] Team meeting reminder July 18 18:00 UTC','Hi folks,\n\nWe\'ll be have the Savanna team meeting today as usual in #openstack-meeting-alt channel.\n\nAgenda:\n\n* Savann 0.2 release!\n* General news/updates\n* Savanna architecture discussions\n* EDP discussions\n\nhttp://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20130718T18 \n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\n\n\n',NULL,NULL),('<17C46BD9-F6F6-43AE-883E-2512EE698CDD@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-09 14:52:38',21600,'2014-12-09 08:52:38',NULL,'[openstack-dev] [Mistral] Event Subscription','Ok, got it.\n\nSo my general suggestion here is: let\'s keep it as simple as possible for now, create something that works and then let?s see how to improve it. And yes, consumers may be and mostly will be 3rd parties.\n\nThanks\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n\n\n> On 09 Dec 2014, at 08:25, W Chan <m4d.coder at gmail.com> wrote:\n> \n> Renat,\n> \n> On sending events to an \"exchange\", I mean an exchange on the transport (i.e. rabbitMQ exchange https://www.rabbitmq.com/tutorials/amqp-concepts.html <https://www.rabbitmq.com/tutorials/amqp-concepts.html>).  On implementation we can probably explore the notification feature in oslo.messaging.  But on second thought, this would limit the consumers to trusted subsystems or services though.  If we want the event consumers to be any 3rd party, including untrusted, then maybe we should keep it as HTTP calls.\n> \n> Winson\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141209/5f5eb550/attachment.html>\n\n','<CABNy8O6DbuSEicLw5Cvz_h=REpyZvunhHogPTRe5nywBYTm-ig@mail.gmail.com>',NULL),('<17C9FE1D-4644-4CF9-92FF-6411538B2B8D@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 16:28:55',-14400,'2014-06-04 20:28:55',NULL,'[openstack-dev]  [Neutron][IPv6] Issues on dnsmasq','Hi, Xu Han:\n\nYou mentioned in the weekly meeting that you guys saw some issues in the lab, which may pertain to the dnsmasq source code I wrote. Would you please share with me the symptom and the procedures to reproduce them? I would like to take a look and fix the issue if necessary.\n\nThanks!\n\nShixiong\n\n\nShixiong Shang\n\n!--- Stay Hungry, Stay Foolish ---!\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/ffcfb2a1/attachment.html>\n\n',NULL,NULL),('<17CBF863-797A-4277-846E-8D23D46759FC@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-11-15 16:01:44',0,'2013-11-15 16:01:44',NULL,'[openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd\n week of January, Montreal, QC, Canada','On Nov 15, 2013, at 9:36 AM, Russell Bryant <rbryant at redhat.com> wrote:\n> On 11/13/2013 11:10 AM, Anita Kuno wrote:\n>> Neutron Tempest code sprint\n>> \n>> In the second week of January in Montreal, Quebec, Canadathere will be a\n>> Neutron Tempest code sprint to improve the status of Neutron tests in\n>> Tempest and to add new tests.\n> \n> First off, I think anything regarding putting more effort into this is\n> great.  However, I *beg* the Neutron team not to wait until this week to\n> make significant progress.\n> \n> To be clear, IMO, this is already painfully late.  It\'s one of the\n> largest items blocking deprecation of nova-network and moving forward\n> with Neutron.  This spring is just a couple weeks before icehouse-2.\n> Come i2, mid-cycle, we\'re going to have make a call on whether or not\n> nova-network deprecation seems likely.  If not, we really can\'t wait\n> around and I will probably propose un-freezing nova-network.\n> \n>> The event will be vendor neutral. We will talk to each other based on\n>> who we are and our interests, not based on who signs our paycheque. If\n>> folks arrive with logoed shirts (I don\'t know which logos are work logos\n>> and which aren\'t, so I will request no logos please) I will issue you a\n>> white T-shirt to wear. We need to work collaboratively to effectlvely\n>> make progress during the code sprint.\n> \n> I\'m all for promoting a culture of individuals and vendor neutrality.\n> However, I think this requirement is bizarre and unnecessary.  From a\n> practical standpoint, many people (myself included) get a ton of shirts\n> at conferences, so a lot of my clothes have tech company logos.  If you\n> actually get people to show up to an event dedicated to working on\n> testing, who cares what shirt they have on?\n> \n> \"I will issue you a white T-shirt\"?!  Are you serious?\n> \n>> Someone at the summit choose not to wear footwear at the event. If you\n>> want to come to the code sprint please plan on wearing appropriate\n>> footwear in the public areas at the code sprint. For two reasons:\n>> 1. It will be cold.\n>> 2. The event is meant to facilitate mutual respect between us to\n>> increase communication, both at the event and afterwards. I feel wearing\n>> appropriate footwear supports this goal.\n> \n> It\'s Winter in Canada... I\'d be quite surprised if someone went without\n> shoes.\n> \n> I love the idea, but this stuff is just a big turn-off.\n\nHuge +1 from me as well. The sprint and Tempest work is great, the\nclothing requirements are going to make people not take this seriously.\nI feel these were not necessary.\n\n\n\n\n','<52863F8B.5080708@redhat.com>',NULL),('<17CDB569-DAA9-4915-83E2-CF77492EA9AE@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-02 15:19:19',0,'2012-11-02 15:19:19',NULL,'[openstack-dev] [ceilometer] database timestamps timezones','I\'d highly recommend using all UTC timestamps.  The daylight savings time craziness alone is a good reason for this. \nPlus issues of distributed systems that may physically span multiple timezones. \n\n\nOn Nov 1, 2012, at 10:00 PM, John Tran wrote:\n\n> Looking over https://bugs.launchpad.net/ceilometer/+bug/1048647, we\'d\n> like some feedback on timezone aware datetimes for the timestamp\n> fields (in Meters and Resources tables).  From what I understand, some\n> backends do not support timezone in timestamp type fields , such as\n> MongoDB and Postgres.  I think the way Nova handles it is that it\n> expects all timestamps in the database is expected to be UTC.\n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n\n','<CAHHzA4VU18CAfQzquDyenap6Me5n2DVK7eWKOGMzaYFo5T_gZQ@mail.gmail.com>',NULL),('<17CE8CEAAED0554D8677EB8ED52ACFB0020BD599@EXBE07-Y.ad.hosteam.fr>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-10-24 14:57:50',7200,'2013-10-24 12:57:50',NULL,'[Openstack] test; ignore','\n\n',NULL,NULL),('<17D6603D-EC31-4585-9965-3DA96871BFF8@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 19:08:09',14400,'2013-09-26 15:08:09',NULL,'[openstack-dev] [savanna] 0.2.2 release!','Hello everyone,\n\nI\'m glad to announce the 0.2.2 release of Savanna. This release contains 4 components: Savanna core, plugin for OpenStack Dashboard, diskimage-builder elements and alpha version of python bindings.\n\nRelease Notes (https://wiki.openstack.org/wiki/Savanna/ReleaseNotes/0.2.2): \n\nFeatures implemented:\n* Hortonworks Data Platform plugin added with cluster scaling support and docs.\n\nBug fixes:\n* documentation on scaling improved;\n* UI improvements and minor bug-fixes;\n* improvements and minor bug-fixes.\n\nSavanna wiki: https://wiki.openstack.org/wiki/Savanna\nLaunchpad project: https://launchpad.net/savanna\nSavanna docs: https://savanna.readthedocs.org/en/0.2.2/index.html (quickstart and installation, user and dev guides)\n\nEnjoy!\n\nP.S. It\'s the last release of Savanna for previous 0.2 version.\n\nSincerely yours,\nSergey Lukjanov\nSavanna Technical Lead\nMirantis Inc.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/5649869b/attachment.html>\n\n',NULL,NULL),('<17D67BAB-68FC-48DF-8C90-8C6B3ACB2984@doughellmann.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-12-02 11:37:19',-18000,'2014-12-02 16:37:19',NULL,'[openstack-dev] oslo.config 1.5.0 released','The Oslo team is pleased to announce release 1.5.0 of oslo.config.\n\nThis is primarily a bug-fix release, but does include requirements changes.\n\nFor more details, please see the git log history below and\n http://launchpad.net/oslo/+milestone/1.5.0\n\nPlease report issues through launchpad:\n http://bugs.launchpad.net/oslo\n\n----------------------------------------\n\nChanges in openstack/oslo.config  1.4.0..1.5.0\n\n7ab3326 Updated from global requirements\nc81dc30 Updated from global requirements\n4a15ea3 Fix class constant indentation\n5d5faeb Updated from global requirements\nd6b0ee6 Activate pep8 check that _ is imported\n73635ef Updated from global requirements\ncf94a51 Updated from global requirements\ne140a1d Add pbr to installation requirements\ne906e74 Updated from global requirements\n0a7abd0 Add some guidance for group names\ne0ad7fa delay formatting debug log message\nf7c54d9 Check config default value is correct type\n41770ad Report permission denied when parsing config\n5ada833 Fix docs example using generator config files\ne82f6bb Updated from global requirements\nfa458ee do not use colons in section titles\n2af57e5 Stop using intersphinx\na736da3 Fixed typo in docstring for _get_config_dirs\nba6486a Update contributing instructions\n70fc459 Add missing newline to stderr output when argument value is wrong\n\n  diffstat (except docs and test files):\n\n CONTRIBUTING.rst            |  2 +-\n oslo/config/cfg.py          | 64 ++++++++++++++++++++++++++++++++++++++++-----\n oslo/config/generator.py    |  2 +-\n oslo/config/types.py        | 45 +++++++++++++++++++++++++------\n requirements.txt            |  3 ++-\n test-requirements.txt       |  8 +++---\n tests/test_cfg.py           | 58 ++++++++++++++++++++++++----------------\n tests/test_generator.py     |  3 ++-\n tox.ini                     |  1 -\n 14 files changed, 162 insertions(+), 52 deletions(-)\n\n  Requirements updates:\n\n diff --git a/requirements.txt b/requirements.txt\n index bde4919..fb3695c 100644\n --- a/requirements.txt\n +++ b/requirements.txt\n @@ -4,0 +5 @@\n +pbr>=0.6,!=0.7,<1.0\n @@ -8 +9 @@ six>=1.7.0\n -stevedore>=0.14\n +stevedore>=1.1.0  # Apache-2.0\n diff --git a/test-requirements.txt b/test-requirements.txt\n index 2a9b720..e23d9ef 100644\n --- a/test-requirements.txt\n +++ b/test-requirements.txt\n @@ -12,2 +12,2 @@ testscenarios>=0.4\n -testtools>=0.9.34\n -oslotest>=1.1.0.0a1\n +testtools>=0.9.36,!=1.2.0\n +oslotest>=1.2.0  # Apache-2.0\n @@ -21,2 +21,2 @@ coverage>=3.6\n -sphinx>=1.1.2,!=1.2.0,<1.3\n -oslosphinx>=2.2.0.0a2\n +sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3\n +oslosphinx>=2.2.0  # Apache-2.0\n\n',NULL,NULL),('<17DC6A5B-D604-4B21-B22D-22E6C96D8F92@gmail.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2013-12-05 11:28:13',-28800,'2013-12-05 19:28:13',NULL,'[Openstack] Remote Login thorugh a website','Hey I never tried, but maybe by removing the user password in Keystone \nshould do it.\nOr do you want to bypass the login page?\n\n\nRazique\nOn 5 Dec 2013, at 10:01, Abhishek Aggarwal wrote:\n\n> Hi,\n>\n>\n>\n> I want to login into openstack dashboard through my website without \n> the\n> user action of filling the username and password. Please help me on \n> that.\n>\n>\n>\n> Thanks.\n>\n> Abhishek\n> _______________________________________________\n> Mailing list: \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : \n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/1cf726eb/attachment.html>\n\n','<b8969052ee77f83f91683135e18b2293@mail.gmail.com>',NULL),('<17E200D3-49FD-43A3-84EF-A9959867A3EC@rackspace.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-04 17:08:49',0,'2014-06-04 17:08:49',NULL,'[openstack-dev] [solum] reviews for the new API','Angus/Julien,\n\nI would disagree that we should expose the mistral DSL to end users.\n\nWhat if we decide to use something other than Mistral in the future? We should be able to plug in any workflow system we want without changing what we expose to the end user.\n\nTo me, the pipeline DSL is similar to our plan file. We don\'t expose a heat template to our end users.\n\nMurali\n\n\n\nOn Jun 4, 2014, at 10:58 AM, Julien Vey <vey.julien at gmail.com<mailto:vey.julien at gmail.com>>\n wrote:\n\nHi Angus,\n\nI really agree with you. I would insist on #3, most of our users will use the default workbook, and only advanced users will want to customize the workflow. \"advanced\" users should easily understand a mistral workbook, cause they are \"advanced\"\n\nTo add to the cons of creating our own DSL, it will require a lot more work, more design discussions, more maintenance... We might end up doing what mistral is already doing. If we have some difficulties with Mistral\'s DSL, we can talk with the team, and contribute back our experience of using Mistral.\n\nJulien\n\n\n\n\n\n2014-06-04 14:11 GMT+02:00 Angus Salkeld <angus.salkeld at rackspace.com<mailto:angus.salkeld at rackspace.com>>:\n-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nHi all\n\nI have posted this series and it has evoked a surprising (to me) amount\nof discussion so I wanted to clarify some things and talk to some of the\nissues so we can move forward.\n\nSo first note is this is an early posting and still is not tested much.\n\nhttps://review.openstack.org/#/q/status:open+project:stackforge/solum+branch:master+topic:new-api,n,z\n\nFirst the terminology\n   I have a pipeline meaning the association between a mistral workbook,\n   a trigger url and a plan. This is a running entity not just a\n   different workbook.\n\nThe main issue seems to be the extent to which I am exposing the mistral\nworkbook. Many of you expected a simpler workflow DSL that would be\nconverted into the mistral workbook.\n\nThe reason for me doing it this way are:\n1) so we don\'t have to write much code\n2) this is an iterative process. Let\'s try it the simple way first and\n   only make it more complicated if we really need to (the agile way?).\n3) to be consistent in the way we treat heat templates, mistral\n   workbooks and language packs - i.e. we provide standard ones and\n   allow you to customize down to the underlying openstack primitives\n   if you want (we should aim for this to be only a small percentage\n   of our users).\n   eg. pipeline == (check-build-deploy mistral workbook +\n                    basic-docker heat template + custom plan)\n   here the user just choose the heat template and workbook from a list\n   of options.\n\n4) if the mistral dsl is difficult for our users to work with we should\n   give the mistral devs a chance to improve it before working around\n   it.\n5) our users are primary developers and I don\'t think the current\n   mistral DSL is tricky to figure out for someone that can code.\n6) doing it this way we can make use of heat and mistral\'s horizon\n   plugins and link to them from the pipeline instead of having to\n   redo all of the same pages. In a similar why that heat links to\n   servers/volumes etc from a running stack.\n\n- -Angus\n\n\nSome things to note:\n- - the entire mistral engine can be replaced with an engine level plugin\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\nComment: Using GnuPG with Thunderbird - http://www.enigmail.net/\n\niQEcBAEBAgAGBQJTjwz2AAoJEFrDYBLxZjWoEr0H/3nh66Umdw2nGUEs+SikigXa\nXAN90NHHPuf1ssEqrF/rMjRKg+GvrLx+31x4oFfHEj7oplzGeVA9TJC0HOp4h6dh\niCeXAHF7KX+t4M4VuZ0y9TJB/jLxfxg4Qge7ENJpNDD/gggjMYSNhcWzBG87QBE/\nMi4YAvxNk1/C3/YZYx2Iujq7oM+6tflTeuoG6Ld72JMHryWT5/tdYZrCMnuD4F7Q\n8a6Ge3t1dQh7ZlNHEuRDAg3G5oy+FInXyFasXYlYbtdpTxDL8/HbXegyAcsw42on\n2ZKRDYBubQr1MJKvSV5I3jjOe4lxXXFylbWpYpoU8Y5ZXEKp69R4wrcVISF1jQQ=\n=P0Sl\n-----END PGP SIGNATURE-----\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/b944b621/attachment.html>\n\n','<CAP4JdAEaHdxud9=hC7PZNMZmjw7rx1XGsbcOQ2LKT+c50_yhaA@mail.gmail.com>',NULL),('<17E41F91-1770-4D22-A6B4-388B13547740@cisco.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-05-23 23:25:51',0,'2014-05-23 23:25:51',NULL,'[openstack-dev] [Neutron] Seeking opinions on scope of\n	code	refactoring...','Thanks for the comment Carl. See @PCM inline\n\n\nPCM (Paul Michali)\n\nMAIL ?..?. pcm at cisco.com\nIRC ??..? pcm_ (irc.freenode.com)\nTW ???... @pmichali\nGPG Key ? 4525ECC253E31A83\nFingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n\n\n\nOn May 23, 2014, at 6:09 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:\n\n> Paul,\n> \n> On Fri, May 23, 2014 at 8:24 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:\n>> Hi,\n>> \n>> I?m working on a task for a BP to separate validation from persistence logic\n>> in L3 services code (VPN currently), so that providers can override/extend\n>> the validation logic (before persistence).\n>> \n>> So I?ve separated the code for one of the create APIs, placed the default\n>> validation into an ABC class (as a non-abstract method) that the service\n>> drivers inherit from, and modified the plugin to invoke the validation\n>> function in the service driver, before doing the persistence step.\n>> \n>> The flow goes like this?\n>> \n>>    def create_vpnservice(self, context, vpnservice):\n>>        driver = self._get_driver_for_vpnservice(vpnservice)\n>>        driver.validate_create_vpnservice(context, vpnservice)\n>>        super(VPNDriverPlugin, self).create_vpnservice(context, vpnservice)\n>>        driver.apply_create_vpnservice(context, vpnservice)\n>> \n>> If the service driver has a validation routine, it?ll be invoked, otherwise,\n>> the default method in the ABC for the service driver will be called and will\n>> handle the ?baseline? validation. I also renamed the service driver method\n>> that is used for applying the changes to the device driver as apply_*\n>> instead of using the same name as is used for persistence (e.g.\n>> create_vpnservice -> apply_create_vpnservice).\n>> \n>> The questions I have is?\n>> \n>> 1) Should I create new validation methods A) for every create (and update?)\n>> API (regardless of whether they currently have any validation logic, B) for\n>> resources that have some validation logic already, or C) only for resources\n>> where there are providers with different validation needs?  I was thinking\n>> (B), but would like to hear peoples? thoughts.\n> \n> I think B.  C may leave a little too much inconsistency.  A feels like\n> extra boiler-plate.  Would there be any benefit to creating a higher\n> level abstraction for the create/update API calls?  I\'m not suggesting\n> you do so but if you did then you could add a validation method to\n> that interface with a default pass.  Otherwise, I\'d stick with B until\n> there is a need for more.\n\n@PCM Yeah, there is somewhat of an abstraction. In VPN, for the service drivers, they all inherit from an ABC. For the apply, there are already abstract methods in the ABC, so that the service driver is forced to provide a function (of course it is inconsistent currently - they are there for VPN services, but not for IPSec connections, which are provided in the service driver). For the validation, I was creating methods in the ABC, with implementations, but not abstract, so that the service driver could provide a function, if it wanted to extend or override (and call super, if desired), or leave it out and the base class function would be used.\n\nSo, I guess it?s at two points, the validate and apply methods, where we should probably be consistent with providing base class methods for all that present in the service driver.\n\n\n> \n>> 2) I?ve added validation_* and modified the other service driver call to\n>> apply_*. Should I instead, use the ML2 terminology of pre commit_* and post\n>> commit_*? I personally favor the former, as it is more descriptive of what\n>> is happening in the methods, but I understand the desire for consistency\n>> with other code.\n> \n> I\'m on the fence.  ML2 is not where I\'m most familiar and I don\'t know\n> the history behind that design.  Without considering ML2 and\n> consistency, I think I like your terminology better.\n\n@PCM I?m in the same camp. I don?t know ML2 well, and I like the explicit terminology. It *seems* like ML2 is dealing with this all at the same level of abstraction (pre-commit, commit, post-commit all for the same plugin or driver), whereas with L3 services, it is at two levels (validate at service driver and then plugin, commit at plugin, apply at service driver only). I guess I can leave it and see what happens at review?I have some asbestos here somewhere.\n\n\n> \n>> 3) Should I create validation methods for code, where defaults are being set\n>> for missing (optional) information? For example, VPN IKE Policy lifetime\n>> being set to units=seconds, value=3600, if not set. Currently, provider\n>> implementations have same defaults, but could potentially use different\n>> defaults. The alternative is to leave this in the persistence code and not\n>> allow it to be changed. This could be deferred, if 1C is chosen above.\n> \n> I\'m tempted to say punt on this until there is a need for it.\n\n@PCM I think you?re right. It may turn out to be YAGNI.\n\nThanks!\n\nPCM\n\n\n> \n> Carl\n> \n>> Looking forward to your thoughts...\n>> \n>> \n>> Thanks!\n>> \n>> PCM (Paul Michali)\n>> \n>> MAIL ?..?. pcm at cisco.com\n>> IRC ??..? pcm_ (irc.freenode.com)\n>> TW ???... @pmichali\n>> GPG Key ? 4525ECC253E31A83\n>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83\n>> \n>> \n>> \n>> \n>> _______________________________________________\n>> OpenStack-dev mailing list\n>> OpenStack-dev at lists.openstack.org\n>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n>> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/89ee6d88/attachment.html>\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140523/89ee6d88/attachment.pgp>\n\n','<CALiLy7rLcPQtfr3UP-D-cGcSMaoKLRmsAsjY0whnH18sS_W4ug@mail.gmail.com>',NULL),('<17EF0911-B67B-4E74-A8DA-B352125B0AB5@gmail.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-08-14 16:53:01',-25200,'2013-08-14 23:53:01',NULL,'[openstack-dev] [nova] live-snapshot/cloning of virtual machines','Hi Everyone,\n\nI have been trying for some time to get the code for the live-snapshot blueprint[1] in. Going through the review process for the rpc and interface code[2] was easy. I suspect the api-extension code[3] will also be relatively trivial to get in. The main concern is with the libvirt driver implementation[4]. I\'d like to discuss the concerns and see if we can make some progress.\n\nShort Summary (tl;dr)\n=====================\n\nI propose we merge live-cloning as an experimental feature for havanna and have the api extension disabled by default.\n\nOverview\n========\n\nFirst of all, let me express the value of live snapshoting. The slowest part of the vm provisioning process is generally booting of the OS. The advantage of live-snapshotting is that it allows the possibility of bringing up application servers while skipping the overhead of vm (and application startup).\n\nI recognize that this capability comes with some security concerns, so I don\'t expect this feature to go in and be ready to for use in production right away. Similarly, containers have a lot of the same benefit, but have had their own security issues which are gradually being resolved. My hope is that getting this feature in would allow people to start experimenting with live-booting so that we could uncover some of these security issues.\n\nThere are two specific concerns that have been raised regarding my patch. The first concern is related to my use of libvirt. The second concern is related to the security issues above. Let me address them separately.\n\n1. Libvirt Issues\n=================\n\nThe only feature I require from the hypervisor is to load memory/processor state for a vm from a file. Qemu supports this directly. The only way that libvirt exposes this functionality is via its restore command which is specifically for restoring the previous state of an existing vm. \"Cloning\", or restoring the memory state of a cloned vm is considered unsafe (which I will address in the second point, below).\n\nThe result of the limited api is that I must include some hacks to make the restore command actually allow me to restore the state of the new vm. I recognize that this is using an undocumented libvirt api and isn\'t the ideal solution, but it seemed \"better\" then avoiding libvirt and talking directly to qemu.\n\nThis is obviously not ideal. It is my hope that this 0.1 version of the feature will allow us to iteratively improve the live-snapshot/clone proccess and get the security to a point where the libvirt maintainers would be willing to accept a patch to directly expose an api to load memory from a file.\n\n2. Security Concerns\n====================\n\nThere are a number of security issues with loading state from another vm. Here is a short list of things that need to be done just to make a cloned vm usable:\n\na) mac address needs to be recreated\nb) entropy pool needs to be reset\nc) host name must be reset\nd) host keys bust be regenerated\n\nThere are others, and trying to clone a running application as well may expose other sensitive data, especially if users are snaphsoting vms and making them public.\n\nThe only issue that I address on the driver side is the mac addresses. This is the minimum that needs to be done just to be able to access the vm over the network. This is implemented by unplugging all network devices before the snapshot and plugging new network devices in on clone. This isn\'t the most friendly thing to guest applications, but it seems like the safest option for the first version of this feature.\n\nSo cloning vms must be done with care. Sensitive data must be removed from the vm pre-clone and new data needs to be generated post-clone. Ultimately this should all be done via guest-agent of some sort. I have found some volunteers to make the guest agent a reality, but it will take a bit of time to get something workable, and it will be much more difficult if there isn\'t a way to test the feature.\n\nConclusion\n==========\n\nThere are obviously problems to be solved with the whole idea of live cloning, but I think it enables some important new ways of deploying applications. Imagine for example a PaaS built on fast-cloning vms instead of containers. This is clearly a long term project but if we block it now it may never get the support it needs to become a real option.\n\nProposal\n========\n\nI propose we allow the patch in and we leave the live-snapshot extension disabled by default. Deployers can turn on the extension to experiment with the feature. This will allow other hypervisors do do an implementation, and the community in general to improve the security and usefulness of live-cloned virtual machines.\n\nI\'m very interested in your thoughts and feedback. Thank you to everyone who made it this far.\n\nVish \n\n[1] https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms\n[2] https://review.openstack.org/#/c/33697/\n[3] https://review.openstack.org/#/c/34036/\n[4] https://review.openstack.org/#/c/33698/\n\n',NULL,NULL),('<17F412CD-A2DB-47BC-9D1E-B2D5BF60C7AE@mirantis.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-31 11:36:16',25200,'2014-03-31 04:36:16',NULL,'[openstack-dev] [Mistral] task update at end of handle_task in\n	executor','I agree with all the explanations given here.\n\n\n> On Thu, Mar 27, 2014 at 9:47 AM, Manas Kelshikar <manas at stackstorm.com> wrote:\n> Yes. It is a bug and should be done before line 119:  self._do_task_action(db_task). It can definitely lead to bugs especially since _do_task_action itself updates the status.\n> \n> On Wed, Mar 26, 2014 at 8:46 PM, W Chan <m4d.coder at gmail.com> wrote:\n> In addition, for sync tasks, it\'ll overwrite the task state from SUCCESS to RUNNING.\n\nGuys, good catch.\n\nHas it been addressed yet?\n\nRenat Akhmerov\n@ Mirantis Inc.\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140331/6f0dc4b5/attachment.html>\n\n','<CACarOJYcDGJZUvQHi+AQphp7y5m6poWYARMiaEqENQ_La9X1LQ@mail.gmail.com>',NULL),('<1800686811.9678001.1398287460755.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-04-23 17:11:00',-14400,'2014-04-23 21:11:00',NULL,'[openstack-dev] [Horizon] Question regarding new panels and\n tests','Thanks Mainn, that approach does work to get my panels registered for the tests and takes care of all of the errors that I saw.\n\nBad news is that it gives me a couple of new ones.  They are pasted here:  http://ur1.ca/h5l8u\nIt looks like the panel_group_tests and panel tests want to do a deepcopy on HORIZON_CONFIG, which usually works now fails.\n\nIn test/settings.py, I can do the deepcopy before I call settings.update_dashboards, but it will fail after the call to update_dashboards.  Something non-deep-copy-able must be getting stuck in there, but I can\'t see it.  Any thoughts?\n\nThanks again,\nChad\n\n----- Original Message -----\nFrom: \"Tzu-Mainn Chen\" <tzumainn at redhat.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, April 23, 2014 4:23:29 PM\nSubject: Re: [openstack-dev] [Horizon] Question regarding new panels and tests\n\n> I have a question about adding new panels with respect to tests.\n> \n> I have a new panel (for the Sahara project, data processing) that lives (for\n> now at least) under the projects folder.  The plan is to have it activated\n> only by using the new \"enabled\" mechanism to define a new panel group, \"data\n> processing\", where it and several other panels will eventually show up.\n> \n> When I did this, it works fine for me when I run it, but running the tests\n> (tox -e py27) fails because my panel is not registered anywhere.  Is there a\n> config for the tests that I can tweak so that my panel can be registered for\n> the tests (tests/enabled or something like that?\n> \n> Thanks,\n> Chad\n> \n\nHiya - I haven\'t tested this, but one thing you could try. . . if you look at \nhorizon/openstack_dashboard/settings.py, there\'s a section that determines\nwhere the dashboard looks for plugins (https://github.com/openstack/horizon/blob/master/openstack_dashboard/settings.py#L220)\n\n   # Load the pluggable dashboard settings\n   import openstack_dashboard.enabled\n   import openstack_dashboard.local.enabled\n   from openstack_dashboard.utils import settings\n\n   INSTALLED_APPS = list(INSTALLED_APPS) # Make sure it\'s mutable\n   settings.update_dashboards([\n       openstack_dashboard.enabled,\n       openstack_dashboard.local.enabled,\n   ], HORIZON_CONFIG, INSTALLED_APPS)\n\nIf you edit horizon/openstack_dashboard/settings.py to add a similar section,\nonly using, say, openstack_dashboard.test.local.enabled, you may be able to enable\nthe panels for the tests there.\n\nMainn\n\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<1394086202.9658097.1398284609175.JavaMail.zimbra@redhat.com>',NULL),('<1801021634.70610130.1380244736043.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-09-26 18:18:56',-25200,'2013-09-27 01:18:56',NULL,'[openstack-dev] How to create vmdk for openstack usage','Hi Jason, \n\nComments inlined. If it helps, I can also work with you off-list via email to \nhelp resolve the issues you have. \n\nThanks, \nVui \n\n----- Original Message -----\n\n| From: \"Jason Zhang\" <bearovercloud at gmail.com>\n| To: \"OpenStack Development Mailing List\" <openstack-dev at lists.openstack.org>\n| Cc: \"Vui Chiap Lam\" <vuichiap at vmware.com>\n| Sent: Thursday, September 26, 2013 5:48:10 PM\n| Subject: Re: [openstack-dev] How to create vmdk for openstack usage\n\n| Dear Vui,\n\n| Thank you very much for your information.\n\n| > After obtaining a sparse ide vmdk from \"qemu-img convert\", due to a bug in\n| > the\n| > VMware nova driver, you need to convert the vmdk to a thin or preallocated\n| > disk.\n\n| We tested it based on your information by using the ide.\n| The preallocated option works. Thin didn\'t work, any idea?\n\nCan you give more details about what you did and what did not work? Was it the \nconversion to a thin disk that failed, or the usage of of the converted disk? \n\n| > You can do this one of the following tools:\n| > - vmkfstools.pl referenced in the DeveloperGuide Appendix\n| > - vmkfstools directly if you can ssh into an ESX machine\n\n| The above 2 didn\'t work.\n\nSame here. Can you provide more details? Were you not able to set up or get to \nan environment to run these tools, or did they not produce a converted disk, \nor did not produce one that works with nova? \n\n| > - vmware-vdiskmanager (comes bundled with VMware Fusion or VMware\n| > Workstation)\n| > (e.g. \'/Applications/VMware\n| > Fusion.app/Contents/Library/vmware-vdiskmanager\' -r > our_sparse_ide.vmdk\n| > -t 4 converted.vmdk\n\n| This works for pre-allocated.\n\n| Is there an option to reduce the disk size of the converted vmdk?\n\n| We were using vmware-vdiskmanager -r <source.vmdk> -t 0 <target.vmdk> to\n| reduced the disk size but it didn\'t work, OS couldn\'t be booted.\n\n-t 0 produces a monosparse format that is not compatible with ESX. \n\nAs for the reduction of disk size, not at the moment, although currently two issues related to https://bugs.launchpad.net/nova/+bug/1215146 are being looked into: \n1. reduce disk usage on ESX datastore by restoring the thin-provisioned-ness of a thin disk. \n2. minimize glance <-> nova network traffic when transferring thin provisioned disk. \n\nthat hopefully will address this issue soon. \n\n| Thanks in advance!\n\n| Best regards,\n\n| Jason\n\n| On 9/16/13 1:13 AM, Vui Chiap Lam wrote:\n\n| | Hi Jason,\n| \n\n| | What happens if you forgo the converting to lsilogic, and instead upload\n| | the\n| | disk to glance as an ide disk (using --property vmware_adaptertype=ide)?\n| \n\n| | Also, just reiterating the docs and Dan\'s comments,\n| \n\n| | After obtaining a sparse ide vmdk from \"qemu-img convert\", due to a bug in\n| | the VMware nova driver, you need to convert the vmdk to a thin or\n| | preallocated disk.\n| \n| | You can do this one of the following tools:\n| \n| | - vmkfstools.pl referenced in the DeveloperGuide Appendix\n| \n| | - vmkfstools directly if you can ssh into an ESX machine\n| \n| | - vmware-vdiskmanager (comes bundled with VMware Fusion or VMware\n| | Workstation)\n| \n| | (e.g. \'/Applications/VMware\n| | Fusion.app/Contents/Library/vmware-vdiskmanager\'\n| | -r our_sparse_ide.vmdk -t 4 converted.vmdk\n| \n| | After this step you should have a converted .vmdk and a converted\n| | -flat.vmdk.\n| \n| | At this point converted -flat.vmdk (not the descriptor file converted\n| | .vmdk)\n| | can be uploaded to with --property vmware_adaptertype=ide as an ide image\n| \n\n| | If this works, we can worry about converting the disk to SCSI next.\n| \n\n| | Regards,\n| \n| | Vui\n| \n\n| | ----- Original Message -----\n| \n\n| | | From: \"Jason Zhang\" <bearovercloud at gmail.com>\n| | \n| \n| | | To: \"OpenStack Development Mailing List\"\n| | | <openstack-dev at lists.openstack.org>\n| | \n| \n| | | Sent: Friday, September 13, 2013 4:09:47 PM\n| | \n| \n| | | Subject: Re: [openstack-dev] How to create vmdk for openstack usage\n| | \n| \n\n| | | Hi Dan,\n| | \n| \n\n| | | Thank you very much for your reply.\n| | \n| \n\n| | | We tested again and it still does not work, can you give more information\n| | | about how the vmdk\'s were created?\n| | \n| \n| | | I.e the tool used to create the debian and trend vmdk\'s listed here\n| | \n| \n| | | https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide#Glance_Initial_Setup\n| | \n| \n\n| | | Using qemu-img convert to convert a qcow2 or raw image to vmdk doesn\'t\n| | | seem\n| | | to work, for example, by using\n| | \n| \n| | | qemu-img convert -f qcow2 -O vmdk <input-file.qcow2> <output-file.vmdk>\n| | \n| \n| | | The command always converts to a vmdk which is of adapter type \'ide\'\n| | | other\n| | | than lsilogic.\n| | \n| \n\n| | | We modified the adapter type to lsilogic and uploading it to glance by\n| | | using,\n| | \n| \n\n| | | glance image-create --name=<name> --disk-format=vmdk\n| | | --container-format=bare\n| | | --is-public=true --property vmware_adaptertype=lsiLogic --property\n| | | vmware_disktype=thin --property vmware_ostype=ubuntu64Guest <\n| | | output-file.vmdk\n| | \n| \n| | | or\n| | \n| \n| | | glance image-create --name=<name> --disk-format=vmdk\n| | | --container-format=bare\n| | | --is-public=true --property vmware_adaptertype=lsiLogic --property\n| | | vmware-disktype=\"preallocated\" --property vmware_disktype=thin --property\n| | | vmware_ostype=ubuntu64Guest < output-file.vmdk\n| | \n| \n\n| | | doesn\'t seem to work. Even after tying the steps under\n| | | https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide#Appendix\n| | \n| \n\n| | | It seems the patch to convert into a scsi disk, has not been merged yet:\n| | | https://bugs.launchpad.net/qemu/+bug/545089\n| | \n| \n\n| | | Thanks in advance!\n| | \n| \n\n| | | Best regards,\n| | \n| \n\n| | | Jason\n| | \n| \n\n| | | On 9/12/13 12:48 PM, Dan Wendlandt wrote:\n| | \n| \n\n| | | | Hi Jason,\n| | | \n| | \n| \n\n| | | | The best place to look is the official openstack compute documentation\n| | | | that\n| | | | covers vSphere in Nova:\n| | | | http://docs.openstack.org/trunk/openstack-compute/admin/content/vmware.html\n| | | \n| | \n| \n\n| | | | In particular, check out the section titled \"Images with VMware\n| | | | vSphere\"\n| | | | (pasted below). As that text suggests, the most likely issue with your\n| | | | VMDK\n| | | | not booting is that you may have passed the wrong vmware_adaptertype to\n| | | | glance when creating the image. Also note the statement indicating that\n| | | | all\n| | | | VMDK images must be \"flat\" (i.e., single file), otherwise Glance will\n| | | | be\n| | | | confused.\n| | | \n| | \n| \n\n| | | | Dan\n| | | \n| | \n| \n\n| | | | Images with VMware vSphere\n| | | \n| | \n| \n\n| | | | When using either VMware driver, images should be uploaded to the\n| | | | OpenStack\n| | | | Image Service in the VMDK format. Both thick and thin images are\n| | | | currently\n| | | | supported and all images must be flat (i.e. contained within 1 file).\n| | | | For\n| | | | example\n| | | \n| | \n| \n\n| | | | To load a thick image with a SCSI adaptor:\n| | | \n| | \n| \n| | | | $ glance image-create name=\"ubuntu-thick-scsi\" disk_format=vmdk\n| | | | container_format=bare \\\n| | | \n| | \n| \n| | | | is_public=true --property vmware_adaptertype=\"lsiLogic\" \\\n| | | \n| | \n| \n| | | | --property vmware_disktype=\"preallocated\" \\\n| | | \n| | \n| \n| | | | --property vmware_ostype=\"ubuntu64Guest\" < ubuntuLTS-flat.vmdk\n| | | \n| | \n| \n\n| | | | To load a thin image with an IDE adaptor:\n| | | \n| | \n| \n| | | | $ glance image-create name=\"unbuntu-thin-ide\" disk_format=vmdk\n| | | | container_format=bare \\\n| | | \n| | \n| \n| | | | is_public=true --property vmware_adaptertype=\"ide\" \\\n| | | \n| | \n| \n| | | | --property vmware_disktype=\"thin\" \\\n| | | \n| | \n| \n| | | | --property vmware_ostype=\"ubuntu64Guest\" < unbuntuLTS-thin-flat.vmdk\n| | | \n| | \n| \n\n| | | | The complete list of supported vmware disk properties is documented in\n| | | | the\n| | | | Image Management section. It\'s critical that the adaptertype is\n| | | | correct;\n| | | | In\n| | | | fact, the image will not boot with the incorrect adaptertype. If you\n| | | | have\n| | | | the meta-data VMDK file the the ddb.adapterType property specifies the\n| | | | adaptertype. The default adaptertype is \"lsilogic\" which is SCSI.\n| | | \n| | \n| \n\n| | | | On Thu, Sep 12, 2013 at 11:29 AM, Jason Zhang < bearovercloud at gmail.com\n| | | | >\n| | | | wrote:\n| | | \n| | \n| \n\n| | | | | Hi Dears,\n| | | | \n| | | \n| | \n| \n\n| | | | | In the document\n| | | | | https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide\n| | | | | under the \'Get an initial VMDK to work with\',\n| | | | \n| | | \n| | \n| \n| | | | | its said, \'There are a lot of ?gotchas? around what VMDK disks work\n| | | | | with\n| | | | | OpenStack + vSphere,\'.\n| | | | \n| | | \n| | \n| \n| | | | | The appendix section lists one of the gotchas. Are there any more\n| | | | | gotchas?\n| | | | \n| | | \n| | \n| \n\n| | | | | During our testing, the vmdk instance on boot-up gives a \'Operating\n| | | | | System\n| | | | | not found\' error,\n| | | | \n| | | \n| | \n| \n| | | | | I am not sure whether this is a already known issue or not.\n| | | | \n| | | \n| | \n| \n\n| | | | | Thanks in advance!\n| | | | \n| | | \n| | \n| \n\n| | | | | Best regards,\n| | | | \n| | | \n| | \n| \n\n| | | | | Jason\n| | | | \n| | | \n| | \n| \n\n| | | | | _______________________________________________\n| | | | \n| | | \n| | \n| \n| | | | | OpenStack-dev mailing list\n| | | | \n| | | \n| | \n| \n| | | | | OpenStack-dev at lists.openstack.org\n| | | | \n| | | \n| | \n| \n| | | | | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| | | | \n| | | \n| | \n| \n\n| | | | --\n| | | \n| | \n| \n| | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n| | | \n| | \n| \n| | | | Dan Wendlandt\n| | | \n| | \n| \n| | | | Nicira, Inc: www.nicira.com\n| | | \n| | \n| \n| | | | twitter: danwendlandt\n| | | \n| | \n| \n| | | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~\n| | | \n| | \n| \n\n| | | | _______________________________________________\n| | | \n| | \n| \n| | | | OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n| | | | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| | | \n| | \n| \n\n| | | _______________________________________________\n| | \n| \n| | | OpenStack-dev mailing list\n| | \n| \n| | | OpenStack-dev at lists.openstack.org\n| | \n| \n| | | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| | \n| \n\n| | _______________________________________________\n| \n| | OpenStack-dev mailing list OpenStack-dev at lists.openstack.org\n| | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n| \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130926/3d54282f/attachment.html>\n\n','<5244D5CA.6060903@gmail.com>',NULL),('<1801993628.19204418.1371224985135.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-06-14 08:49:45',-25200,'2013-06-14 15:49:45',NULL,'[openstack-dev]  [vmware] VMwareAPI sub-team status update','\nGreetings programmers!\n\nThis is a regular report I\'ll be sending out on the status of the Nova Compute driver for VMware API. (The product family is called vSphere and covers the ESX, ESXi, and vCenter products which all use the same API by the way.) If you have a patch you want me to track, review, or mention, please put me as a reviewer: http://i.imgur.com/XLINkt3.png\n\n== Reviews ==\n\nOpen Reviews: 9\nRecently Closed: 2 \n\nReviews *ready* for core developer attention:\nhttps://review.openstack.org/#/c/29552/\nhttps://review.openstack.org/#/c/30036/\nhttps://review.openstack.org/#/c/30822/\nhttps://review.openstack.org/#/c/31593/\n... these have had a number of +1 reviews from the VMwareAPI community (people known to have VMware API expertise) so they are ready for some core-developer review! Let\'s solicit some attention from them only when appropriate and only after we can agree that this code is good from a VMwareAPI perspective.\n\nReviews needing *vmware* expert attention:\nhttps://review.openstack.org/#/c/29396/\nhttps://review.openstack.org/#/c/29453/\nhttps://review.openstack.org/#/c/30282/\nhttps://review.openstack.org/#/c/30628/\n... these have *not* been looked at by enough non-core reviewers with VMware API expertise. We need folks listed on this email\'s \"CC\" block to come and spend some time on these. If you are doing VMware related work and need reviews, reach out to me, and I\'ll try to coordinate some help for you.\n\nClosed reviews: (celebrate the victories!)\nhttps://review.openstack.org/#/c/30545/\nhttps://review.openstack.org/#/c/31454/\n... these were closed very quickly (relatively speaking) so they are worth studying and learning from. Small patches. Directed fixes. Clear and straight-forward changes.\n\nIs your review not listed?\n* add me as a reviewer http://i.imgur.com/XLINkt3.png\n\nIs your review not listed *ready* for core?\n* get more +1 from the VMware API maintainers and trusted VMware API experts in the OpenStack community!\n\n== Blueprints ==\nsee: https://blueprints.launchpad.net/openstack?searchtext=vmware\nOf the 10 proposed blueprints, only 3 have commitments. Only 1 has \"good progress\" ... many of us are still dedicated to \"fire-fighting\" activities. \n\n* https://blueprints.launchpad.net/nova/+spec/multiple-clusters-managed-by-one-service\n** Multiple VMware vCenter Clusters managed using single compute service\n** Target: Havana-2 (July 18th)\n** review: https://review.openstack.org/#/c/30282/ (listed as needs attention by VMwareAPI experts)\n\nWe need VMwareAPI people to spend some time discussing this. This is currently not anywhere near ready for the core developers to look at.\n\n\n* https://blueprints.launchpad.net/nova/+spec/improve-vmware-disk-usage\n** Enhance vmware Hyper vm disk usage\n** Target: Havana-2 (July 18th)\n** review: [none]\n\nWe currently do not know what this is, no one has discussed it. It has been accepted by someone. We don\'t know why. Good progress, however. I\'m sure it\'s important for some reason.\n\n* https://blueprints.launchpad.net/glance/+spec/hypervisor-templates-as-glance-images\n** VMware vCenter templates available as glance images\n** Target: Havana-2 (July 18th)\n** review: [none] \n\nI am aware, that currently, there is some debate on how best to add this feature. Some proposed solutions may \"break\" Glance while others allow vCenter to act as a Glance storage device by creating a Glance level plugin which our Nova compute Driver can then use extra meta-data to short-cut the copy process saving network bandwidth by handling the template copy inside vCenter. I\'ve not seen code. I would like to see this listed as \"in Discussion\" but I lack the authority to move these around.\n\n* https://blueprints.launchpad.net/nova/+spec/live-snapshots\n** Add ability to create live snapshot for VMs\n** Target: [none]\n** review: [none]\n** see: http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-06-06-21.00.log.html#l-18\n\nThis is a *new* feature OpenStack core wants to add. Technically speaking, it looks easy for us to do in VMwareAPIs but I\'m not sure we have bandwidth to make this happen quickly. Is there anyone who thinks they could tackle this in a timely manner? I can probably start on this task in late July or early August but I\'m booked solid right now.\n\nPersonally, I look forward to the day we\'ve managed to kill off the 10 critical/high priority bugs we have open and start to work on forward looking features to improve OpenStack + VMware. Which brings me to BUGS!\n== Bugs ==\nsee: https://bugs.launchpad.net/nova/+bugs?field.tag=vmware\n\nThat \"vmware\" tag is critical. If you want my attention or the attention of other VMware folks you need to tag! If you are working but haven\'t submitted code, make a comment, let us know you are working!\n\nJust the critical/high priority bugs:\nhttps://bugs.launchpad.net/nova/+bug/1105032 (active in the last 7 days)\nhttps://bugs.launchpad.net/nova/+bug/1180044 (active)\nhttps://bugs.launchpad.net/nova/+bug/1183192 (no action since May 24th!!!)\nHigh priority...\nhttps://bugs.launchpad.net/nova/+bug/1104994 (active)\nhttps://bugs.launchpad.net/nova/+bug/1177993 (no action since May 16th!!!)\nhttps://bugs.launchpad.net/nova/+bug/1178369 (active)\nhttps://bugs.launchpad.net/nova/+bug/1180471 (active)\nhttps://bugs.launchpad.net/nova/+bug/1180779 (active)\nhttps://bugs.launchpad.net/nova/+bug/1180897 (active)\nhttps://bugs.launchpad.net/nova/+bug/1183452 (fix comitted! good work!)\n\nI\'m happy to say *all* these bugs currently have *someone* working on them. Several are related to the patches listed above. There are a few where I will be writing the bug\'s owners directly to make sure they are still available to create a fix for the bug in a timely manner. If I don\'t hear from them by next Friday I will assign new people to the bugs and we\'ll keep moving. I would *love* to see *all* these closed by the Havana-2 deadline but I don\'t want to rush people. Let\'s see where people are in 7 days.\n\nWe have a lot of work to do! Let\'s get to it!\n\nBTW: sorry for the long email. Future updates will be shorter since there will be less to cover.\n\nMeeting info: https://wiki.openstack.org/wiki/Meetings/VMwareAPI\nWe maintain a channel for general discussion of VMwareAPI on freenode IRC at #openstack-vmware I try to hang out there regularly.\n\nOutside meetings, I encourage people to communicate! If you are working on something let us know otherwise, how can we help you?\n\n# Shawn Hartsock, VMware\'s Nova Compute driver maintainer\n\n\n','<1156378350.19098062.1371218743475.JavaMail.root@vmware.com>',NULL),('<1802132423.92.1380176396357.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-09-26 06:19:56',0,'2013-09-26 06:19:56',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-neutron-python27-stable-grizzly #29','See <https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/29/>\n\n------------------------------------------\n[...truncated 5437 lines...]\n    test_create_service_type_default_returns_400                 OK    0.11\n    test_create_service_type_no_svcdef_returns_400               OK    0.11\n    test_delete_dummy_decreases_service_type_refcount            OK    0.13\n    test_delete_service_type_in_use_returns_409                  OK    0.14\n    test_get_default_service_type                                OK    0.11\n    test_get_service_type                                        OK    0.12\n    test_list_service_types                                      OK    0.14\n    test_service_type_create                                     OK    0.11\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.12\n    test_service_type_update_name                                OK    0.13\n    test_service_type_update_set_default_returns_400             OK    0.12\n    test_service_type_update_svc_defs                            OK    0.12\nServiceTypeManagerTestCaseXML\n    test_create_dummy_increases_service_type_refcount            OK    0.13\n    test_create_service_type_default_returns_400                 OK    0.11\n    test_create_service_type_no_svcdef_returns_400               OK    0.11\n    test_delete_dummy_decreases_service_type_refcount            OK    2.44\n    test_delete_service_type_in_use_returns_409                  OK    0.14\n    test_get_default_service_type                                OK    0.12\n    test_get_service_type                                        OK    0.14\n    test_list_service_types                                      OK    0.14\n    test_service_type_create                                     OK    0.12\n    test_service_type_update_clear_svc_defs_returns_400          OK    0.13\n    test_service_type_update_name                                OK    0.13\n    test_service_type_update_set_default_returns_400             OK    0.13\n    test_service_type_update_svc_defs                            OK    0.13\nActionDispatcherTest\n    test_dispatch                                                OK    0.00\n    test_dispatch_action_None                                    OK    0.00\n    test_dispatch_default                                        OK    0.00\nDictSerializerTest\n    test_dispatch_default                                        OK    0.00\nFaultTest\n    test_call_fault                                              OK    0.00\nJSONDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nJSONDictSerializerTest\n    test_json                                                    OK    0.00\n    test_json_with_unicode                                       OK    0.00\n    test_json_with_utf8                                          OK    0.00\nMiddlewareTest\n    test_process_response                                        OK    0.00\nRequestDeserializerTest\n    test_deserialize                                             OK    0.00\n    test_get_action_args                                         OK    0.00\n    test_get_body_deserializer_unknown_content_type              OK    0.00\n    test_get_deserializer                                        OK    0.00\n    test_get_expected_content_type                               OK    0.00\nRequestHeadersDeserializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nRequestTest\n    test_content_type_accept_and_query_extension                 OK    0.00\n    test_content_type_accept_default                             OK    0.00\n    test_content_type_accept_with_given_content_types            OK    0.00\n    test_content_type_from_accept                                OK    0.00\n    test_content_type_from_query_extension                       OK    0.00\n    test_content_type_missing                                    OK    0.00\n    test_content_type_unsupported                                OK    0.00\n    test_content_type_with_charset                               OK    0.00\n    test_content_type_with_given_content_types                   OK    0.00\nResourceTest\n    test_call_resource_class_bad_request                         OK    0.00\n    test_call_resource_class_internal_error                      OK    0.00\n    test_dispatch                                                OK    0.00\n    test_dispatch_unknown_controller_action                      OK    0.00\n    test_malformed_request_body_throws_bad_request               OK    0.00\n    test_type_error                                              OK    0.00\n    test_wrong_content_type_server_error                         OK    0.00\n    test_wrong_content_type_throws_unsupported_media_type_error  OK    0.00\nResponseHeadersSerializerTest\n    test_custom                                                  OK    0.00\n    test_default                                                 OK    0.00\nResponseSerializerTest\n    test_get_body_serializer                                     OK    0.00\n    test_get_serializer                                          OK    0.00\n    test_serialize_json_response                                 OK    0.00\n    test_serialize_response_None                                 OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_response                                  OK    0.00\nSerializerTest\n    test_deserialize_json_content_type                           OK    0.00\n    test_deserialize_raise_bad_request                           OK    0.00\n    test_deserialize_xml_content_type                            OK    0.00\n    test_deserialize_xml_content_type_with_meta                  OK    0.00\n    test_get_deserialize_handler_unknown_content_type            OK    0.00\n    test_serialize_content_type_json                             OK    0.00\n    test_serialize_content_type_xml                              OK    0.00\n    test_serialize_unknown_content_type                          OK    0.00\n    test_serialize_xml_root_is_None                              OK    0.00\n    test_serialize_xml_root_key_is_dict                          OK    0.00\n    test_serialize_xml_root_key_is_list                          OK    0.00\nServerTest\n    test_run_server                                              OK    0.00\nTestWSGIServer\n    test_ipv6_listen_called_with_scope                           OK    0.00\n    test_start_random_port                                       OK    0.00\n    test_start_random_port_with_ipv6                             OK    0.00\nTextDeserializerTest\n    test_dispatch_default                                        OK    0.00\nXMLDeserializerTest\n    test_default_raise_Malformed_Exception                       OK    0.00\n    test_initialization                                          OK    0.00\n    test_xml_empty                                               OK    0.00\n    test_xml_with_utf8                                           OK    0.00\nXMLDictSerializerTest\n    test_None                                                    OK    0.00\n    test_call                                                    OK    0.00\n    test_empty_dic_xml                                           OK    0.00\n    test_non_root_one_item_dic_xml                               OK    0.00\n    test_non_root_two_items_dic_xml                              OK    0.01\n    test_xml                                                     OK    0.00\n    test_xml_meta_contains_node_name_dict                        OK    0.00\n    test_xml_meta_contains_node_name_list                        OK    0.00\n    test_xml_root_key_is_list                                    OK    0.00\n    test_xml_with_unicode                                        OK    0.00\n    test_xml_with_utf8                                           OK    0.00\n\n======================================================================\nERROR: quantum.tests.unit.test_debug_commands.TestDebugCommands.test_list_probe\n----------------------------------------------------------------------\n_StringException: Empty attachments:\n  stderr\n  stdout\n\npythonlogging:\'\': {{{2013-09-26 06:17:37,109    ERROR [cliff.display] (pyparsing 1.5.7 (<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/lib/python2.7/site-packages),> Requirement.parse(\'pyparsing>=2.0.1\'))}}}\n\nTraceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/quantum/tests/unit/test_debug_commands.py\",> line 244, in test_list_probe\n    cmd = commands.ListProbe(self.app, None)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/quantumclient/quantum/v2_0/__init__.py\",> line 277, in __init__\n    super(QuantumCommand, self).__init__(app, app_args)\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/cliff/display.py\",> line 21, in __init__\n    self.load_formatter_plugins()\n  File \"<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/cliff/display.py\",> line 38, in load_formatter_plugins\n    if self.app_args.debug:\nAttributeError: \'NoneType\' object has no attribute \'debug\'\n\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 10.17 secs:\n    2.44    ServiceTypeManagerTestCaseXML.test_delete_dummy_decreases_service_type_refcount\n    2.03    ExtraRouteDBTestCase.test_floatingip_crd_ops\n    2.01    TunnelTest.testDaemonLoop\n    1.86    QuotaExtensionDbTestCase.test_update_quotas_with_negative_integer_returns_400\n    1.84    L3NatDBTestCaseXML.test_floatingip_with_assoc_fails\n----------------------------------------------------------------------\nRan 5179 tests in 943.570s\n\nFAILED (SKIP=238, errors=1)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-neutron-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMako==0.9.0\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.10\nSphinx==1.2b1\nWebOb==1.2.3\nWebTest==1.3.3\nalembic==0.6.0\namqp==1.0.13\namqplib==1.0.2\nanyjson==0.3.3\nargparse==1.2.1\ncliff==1.4.5\ncmd2==0.6.7\ncolorama==0.2.6\nconfigobj==4.7.2\ncoverage==3.6\nd2to1==0.2.11\ndiscover==0.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.4\nkombu==2.5.14\nmock==1.0.1\nmox==0.5.3\nnetaddr==0.7.10\nnetifaces==0.8\nnose==1.3.0\nnosehtmloutput==0.0.5\nnosexcover==1.0.8\nopenstack.nose-plugin==0.11\noslo.config==1.2.0\npbr==0.5.21\npep8==1.3.3\nprettytable==0.7.2\npyparsing==1.5.7\npython-keystoneclient==0.3.2\npython-mimeparse==0.1.4\npython-novaclient==2.15.0\npython-quantumclient==2.2.3\npython-subunit==0.0.15\npytz==2013d\npyudev==0.16.1\nquantum==jenkins.periodic.neutron.python27.stable.grizzly.29\nrepoze.lru==0.6\nrequests==2.0.0\nsetuptools-git==1.0\nsimplejson==3.3.0\nsix==1.4.1\ntermcolor==1.1.0\ntestrepository==0.0.17\ntesttools==0.9.32\nwsgiref==0.1.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./quantum/tests/unit/nose_results.html\n+ \'[\' -f ./quantum/tests/unit/nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./quantum/tests/unit/nose_results.html\n+ passcount=315\n+ \'[\' 315 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.tAQ9YJbYfp\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-neutron-python27-stable-grizzly/29/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-neutron-python27-stable-grizzly/precise34/29\n[SCP] Copying console log.\n\n\n','<592400681.87.1380090155762.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1802546097.6363050.1402311354261.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-09 03:55:54',-25200,'2014-06-09 10:55:54',NULL,'[openstack-dev] Debugging Devstack Neutron with Pycharm','Hello all, \n\nI am trying to debug devstack Neutron with Pycharm, i have found here ( https://wiki.openstack.org/wiki/NeutronDevelopment#How_to_debug_Neutron_.28and_other_OpenStack_projects_probably_.29 ) \nThat i need to change the neutron server code to this=> eventlet.monkey_patch() To: eventlet.monkey_patch(os=False, thread=False) \n\nI have done so, debug seems to run, but when i am trying to initiate commands from the CLI i get this: \n\n\ngal at ubuntu:~/devstack$ neutron net-list \nConnection to neutron failed: Maximum attempts reached \n\n(the server seems to run ok...) \n\nAny help is appreciated as i am trying to learn and understand main flows by debugging the code locally. \n\nThanks \n\nGal. \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140609/e2576182/attachment.html>\n\n','<1545926681.6361667.1402311056096.JavaMail.root@vmware.com>',NULL),('<1803141044.94.1383804889442.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-07 06:14:49',0,'2013-11-07 06:14:49',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python26-stable-grizzly #44','See <https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/44/>\n\n------------------------------------------\n[...truncated 1465 lines...]\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5fe5710>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x42e1450>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x42e1450>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-aff4b791-965c-418b-b999-e24c0fa243ea\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/lib/python2.6/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x3b16b90> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x3b16b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x3b16b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x3b16b90>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-06T06:13:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'06\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-08T06:13:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'08\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:13:59+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:13:59-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'59\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:13:59Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'59\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'59\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x6d2b6d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x27c1b10>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 100.21 secs:\n    27.93    TestScrubber.test_scrubber_app\n    22.14    TestScrubber.test_delayed_delete\n    17.57    TestRootApi.test_version_configurations\n    16.75    TestBinGlanceCacheManage.test_queue\n    15.82    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1109 tests in 762.307s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python26-stable-grizzly/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python26.stable.grizzly.44\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.7RUTMNVdA9\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/44/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-grizzly/centos6-2/44\n[SCP] Copying console log.\n\n\n','<1527544327.67.1383459127668.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1803280281.12124747.1395663211147.JavaMail.zimbra@enovance.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-24 13:13:31',3600,'2014-03-24 12:13:31',NULL,'[openstack-dev] [Murano][Heat] MuranoPL questions?','Hi Stan,\n\nComments inline.\n\n> Zane,\n> \n> I appreciate your explanations on Heat/HOT. This really makes sense.\n> I didn\'t mean to say that MuranoPL is better for Heat. Actually HOT is good\n> for Heat\'s mission. I completely acknowledge it.\n> I\'ve tried to avoid comparison between languages and I\'m sorry if it felt\n> that way. This is not productive as I don\'t offer you to replace HOT with\n> MuranoPL (although I believe that certain elements of MuranoPL syntax can be\n> contributed to HOT and be valuable addition there). Also people tend to\n> protect what they have developed and invested into and to be fair this is\n> what we did in this thread to great extent.\n> \n> What I\'m trying to achieve is that you and the rest of Heat team understand\n> why it was designed the way it is. I don\'t feel that Murano can become\n> full-fledged member of OpenStack ecosystem without a bless from Heat team.\n> And it would be even better if we agree on certain design, join our efforts\n> and contribute to each other for sake of Orchestration program.\n\nNote that I feel that most people outside of the Murano project are against the idea of using a DSL. You should feel that it could block the integration in OpenStack.\n\n> I\'m sorry for long mail texts written in not-so-good English and appreciate\n> you patience reading and answering them.\n> \n> Having said that let me step backward and explain our design decisions.\n> \n> Cloud administrators are usually technical guys that are capable of learning\n> HOT and writing YAML templates. They know exact configuration of their cloud\n> (what services are available, what is the version of OpenStack cloud is\n> running) and generally understands how OpenStack works. They also know about\n> software they intent to install. If such guy wants to install Drupal he\n> knows exactly that he needs HOT template describing Fedora VM with Apache +\n> PHP + MySQL + Drupal itself. It is not a problem for him to write such HOT\n> template.\n> \n> Note that such template would be designed for very particular configuration.\n> There are hundreds of combinations that may be used to install that Drupal -\n> use RHEL/Windows/etc instead of Fedora, use ngnix/IIS/etc instead of Apache,\n> use FastCGI instead of mod_php, PostgreSQL instead of MySQL. You may choose\n> to have all software on single VM or have one VM for database and another\n> for Drupal. There are also constraints to those combinations. For example\n> you cannot have Fedora + IIS on the same VM. You cannot have Apache and\n> Drupal on different VMs.\n> \n> So the HOT template represent fixed combination of those software components.\n> HOT may have input parameters like \"username\" or \"dbImageName\" but the\n> overall structure of template is fixed. You cannot have template that choses\n> whether to use Windows or Linux based on parameter value. You cannot write\n> HOT that accepts number of instances it allowed to create and then decide\n> what would be installed on each of them. This is just not needed for Heat\n> users.\n> \n> With Murano the picture looks the opposite. Typical Murano user is a guy who\n> bought account from cloud hosting vendor (cloud operator) and want to run\n> some software in the cloud. He may not even be aware that it is OpenStack.\n> He knows nothing about programming in general and Heat in particular. He\n> doesn\'t want to write YAMLs. He may not know how exactly Drupal is installed\n> and what components it consists of.\n\nSo that\'s where I want to make a first stop. If your primary user is not a developer, there is no reason to introduce a DSL for security reasons. The provider can trust the code he writes, and there is no need to create a dedicated language.\n\n> So what he does is he goes to his cloud (Murano) dashboard, browses through\n> application catalog, finds Drupal and drags it onto his environment board\n> (think like Visio-style designer). He can stop at this point, click \"deploy\"\n> button and the system will deploy Drupal. In another words the system (or\n> maybe better to say cloud operator or application developer) decides what\n> set of components is going to be installed (like 1 Fedora VM for MySQL and 1\n> CentOS VM for Apache-PHP-Drupal). But user may decide he wants to customize\n> his environment. He digs down and sees that Drupal requires database\n> instance and the default is MySQL. He clicks on a button to see what are\n> other options available for that role.\n> \n> In Heat HOT developer is the user. But in Murano those are completely\n> different roles. There are developers that write application definitions\n> (that is DSL code) and there are end users who compose environments from\n> those applications (components). Application developers may have nothing to\n> do with particular cloud their application deployed on. As for Drupal\n> application the developer knows that Drupal can be run with MySQL or\n> PostgreSQL. But there may be many compatible implementations of those DBMSes\n> - Galera MySQL, TroveMySQL, MMM MySQL etc. So to get a list of what\n> components can be placed in a database role Murano needs to look at all\n> applications in Application Catalog and find which of them are compatible\n> with MySQL and PostgreSQL so that user could choose what implementation is\n> better suits his needs (trade performance for high-availability etc.).\n> \n> User can go deeper and to decide that he wants that MySQL instance (this can\n> be 1 or more VMs depending on implementation) to be shared between Drupal\n> and another application in that environment (say WordPress). He can go even\n> deeper to VM level and decide that he wants to have WordPress, Drupal,\n> Apcache and slave MySQL node on one VM and MySQL master node on another.\n> \n> The ultimate goal is to create sort of construction kit for applications.\n> Cloud LEGO. And let users build environments of any complexity from small\n> components while providing reasonable default so that one-click deployment\n> would also be possible. And such system to be useful the design process need\n> to be guided and driven by UI. System must know what combination of\n> components are possible and what are not and not let user create Microsoft\n> IIS hosted on Fedora.\n\nThose goals are really nice and I\'d like to have something like that in OpenStack.\n\n> This leads us to following design decisions:\n> \n> a. We need a DSL that would allow describing those small components\n> independently in such a way that the environment could be composed from\n> components written by different people that are not aware of each other\n\nYou somewhat start by the end here. You haven\'t convinced us that you need a DSL.\n\n> b. Components need to have properties (parameters in Heat terms). Properties\n> may be of different types (strings, numbers, booleans etc.). There can be\n> constraints on property values (\"not null\", \"length > 5\").\n\nWe have those constraints in Heat, they don\'t require imperative constructs.\n\n> c. Components may reference (require, make use of) other components (Drupal\n> uses MySQL, hosted on Apache etc). There can be constraints for those\n> references.\n\nPresent in HOTs.\n\n> d. Constraints for both properties and references can be *very* complex and\n> indirect. Like \"IIS can be deployed on any VM who\'s image is known to be\n> Windows with version >= WinServer2003\". Or \"my app requires 10 to 20 Windows\n> instances that are all member of the same ActiveDirectory domain\". Or \"I\n> have 2 properties: minInstanceCount and maxInstanceCount and constraint\n> maxInstaceCount >= minInstanceCount\". So we need a language to express\n> conditions of any complexity.\n\nWe support pluggable constraints in Heat, that you can write in Python.\n\n> e. Both properties and references must be declared in a way that would make\n> possible for UI dashboard to discover their existence, ask user appropriate\n> input and validate the constraints on the fly.\n\nPossible as well.\n\n> f. Properties and especially references can have complex structure (lists,\n> maps, combination of them) rather than plain scalars. For example\n> ActiveDirectory consists of (e.g. references) *list* of domain controllers.\n> Constraints must respect that and be capable of validating things like\n> len(list) >= 2, all elements in list have some predicate true, there is at\n> least one element with desired set of properties etc.\n\nIf not possible, HOT should be extended to support this.\n\n> g. Language need to have some sort mechanism to express polymorphism. E,g,\n> GaleraMySQL *is* MySQL (and thus can be used anywhere where \"just MySQL\" can\n> be). This also implies ability to have declare interfaces (class contracts)\n> and ability to implement those interface to that it would be possible that\n> two components are conform to the same interface.\n\nYou don\'t need to have polymorphism for this. I\'m mostly familiar with the mechanism used by Juju, where you *declare* an interface. It\'s basically metadata, and it\'s much simpler.\n\n> h. If we want components to be reusable and easy to write we need to have\n> ability to one component to inherit/extend another. Inheritance implies\n> ability to override and customize some methods\n> \n> i. We don\'t want to do deployment ourself. We don\'t intend to replace Heat,\n> Puppet etc. So we need a way to construct Heat templates that will do the\n> job. We need to map component\'s properties to\n> HOT parameters. This requires a language to express those bindings\n> \n> j. Because there can be lists of references (or properties) it should be\n> possible to express something like\n> for(domain_controller in self.controllers):\n> hot_template.insert(resources_for_particular_controller)\n> \n> or\n> \n> if self.deploy_on_windows:\n> generate_windows_hot_template()\n> else:\n> generate_linux_hot_template()\n> \n> or\n> \n> for i in range(self.instance_count):\n> hot_template.insert(generate_instance())\n\nCloudFormation recently added support for conditionals in templates. I\'m not a super fan of it, but we could presumably have those in HOT as well.\n\n> k. Need to provide most simple method to compose stack from pre-made HOT\n> snippets and avoid dynamic generation when its not really needed\n> \n> l. Need to have some standard format to represent view of the world that is\n> what was designed in dashboard. In Murano it is JSON that describes object\n> graph with object property values and references to another objects. This is\n> somewhat similar to simple HOT template but with hierarchical structure\n> \n> I think at this point it becomes obvious that above describes object-oriented\n> Turing-complete language. And the most important property of that language\n> is that *everything* is declared in a way useful to be accessed from\n> dashboard/app catalog. You not often see properties/references/constraints\n> declared in dynamic language. I\'ve answered several times already why this\n> language cannot be JavaScript or Lua. And this is just on the surface. There\n> are many things under the hood that makes MuranoPL stand out from all\n> embeddable languages I know and thats for a good reason.\n> \n> And I didn\'t even mentioned ALM aspects, orchestration, and many many other\n> things that go far beyond what can be expressed by HOT-style DSL\n\nWell orchestration should be Heat\'s job.\n\nWhat I can say is that I\'m not convinced. The only use-case for a DSL would be if you have to upload user-written code, but what you mentioned is a Web interface, where the user doesn\'t use the DSL, and the cloud provider is the developer. There is no reason in this case to have a secure environment for the code.\n\nCheers,\n\n-- \nThomas\n\n\n','<CAOCoZibVmWN8-TXdhpyGwCrfAiL4F9aARDrgAmwjqgH5q2ijTQ@mail.gmail.com>',NULL),('<1803330664.23573918.1402411768513.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-10 10:49:28',-14400,'2014-06-10 14:49:28',NULL,'[openstack-dev] [nova] Proposal: Move CPU and memory allocation\n ratio out of scheduler','Response inline\n\n----- Original Message -----\n> From: \"Alex Glikson\" <GLIKSON at il.ibm.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\n> Sent: Monday, June 9, 2014 3:13:52 PM\n> Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler\n> \n> >> So maybe the problem isn?t having the flavors so much, but in how the user\n> >> currently has to specific an exact match from that list.\n> If the user could say ?I want a flavor with these attributes? and then the\n> system would find a ?best match? based on criteria set by the cloud admin\n> then would that be a more user friendly solution ?\n> \n> Interesting idea.. Thoughts how this can be achieved?\n\nWell, that is *essentially* what a scheduler does -- you give it a set of parameters\nand it finds a chunk of resources (in this case, a flavor) to match those features.\nI\'m *not* suggesting that we reuse any scheduling code, it\'s just one way to think\nabout it.\n\nAnother way to think about it would be to produce a \"distance\" score and choose the\nflavor with the smallest \"distance\", discounting flavors that couldn\'t fit the target\nconfiguration.  The \"distance\" score would simply be a sum of distances between the individual\nresources for the target and flavor.\n\nBest Regards,\nSolly Ross\n\n> \n> Alex\n> \n> \n> \n> \n> From: \"Day, Phil\" <philip.day at hp.com>\n> To: \"OpenStack Development Mailing List (not for usage questions)\"\n> <openstack-dev at lists.openstack.org>,\n> Date: 06/06/2014 12:38 PM\n> Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation\n> ratio out of scheduler\n> \n> \n> \n> \n> \n> From: Scott Devoid [ mailto:devoid at anl.gov ]\n> Sent: 04 June 2014 17:36\n> To: OpenStack Development Mailing List (not for usage questions)\n> Subject: Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation\n> ratio out of scheduler\n> \n> Not only live upgrades but also dynamic reconfiguration.\n> \n> Overcommitting affects the quality of service delivered to the cloud user. In\n> this situation in particular, as in many situations in general, I think we\n> want to enable the service provider to offer multiple qualities of service.\n> That is, enable the cloud provider to offer a selectable level of\n> overcommit. A given instance would be placed in a pool that is dedicated to\n> the relevant level of overcommit (or, possibly, a better pool if the\n> selected one is currently full). Ideally the pool sizes would be dynamic.\n> That\'s the dynamic reconfiguration I mentioned preparing for.\n> \n> +1 This is exactly the situation I\'m in as an operator. You can do different\n> levels of overcommit with host-aggregates and different flavors, but this\n> has several drawbacks:\n> 1. The nature of this is slightly exposed to the end-user, through\n> extra-specs and the fact that two flavors cannot have the same name. One\n> scenario we have is that we want to be able to document our flavor\n> names--what each name means, but we want to provide different QoS standards\n> for different projects. Since flavor names must be unique, we have to create\n> different flavors for different levels of service. Sometimes you do want to\n> lie to your users!\n> [Day, Phil] I agree that there is a problem with having every new option we\n> add in extra_specs leading to a new set of flavors. There are a number of\n> changes up for review to expose more hypervisor capabilities via extra_specs\n> that also have this potential problem. What I?d really like to be able to\n> ask for a s a user is something like ?a medium instance with a side order of\n> overcommit?, rather than have to choose from a long list of variations. I\n> did spend some time trying to think of a more elegant solution ? but as the\n> user wants to know what combinations are available it pretty much comes down\n> to needing that full list of combinations somewhere. So maybe the problem\n> isn?t having the flavors so much, but in how the user currently has to\n> specific an exact match from that list.\n> If the user could say ?I want a flavor with these attributes? and then the\n> system would find a ?best match? based on criteria set by the cloud admin\n> (for example I might or might not want to allow a request for an\n> overcommitted instance to use my not-overcommited flavor depending on the\n> roles of the tenant) then would that be a more user friendly solution ?\n> \n> 2. If I have two pools of nova-compute HVs with different overcommit\n> settings, I have to manage the pool sizes manually. Even if I use puppet to\n> change the config and flip an instance into a different pool, that requires\n> me to restart nova-compute. Not an ideal situation.\n> [Day, Phil] If the pools are aggregates, and the overcommit is defined by\n> aggregate meta-data then I don?t see why you need to restart nova-compute.\n> 3. If I want to do anything complicated, like 3 overcommit tiers with \"good\",\n> \"better\", \"best\" performance and allow the scheduler to pick \"better\" for a\n> \"good\" instance if the \"good\" pool is full, this is very hard and\n> complicated to do with the current system.\n> [Day, Phil] Yep, a combination of filters and weighting functions would allow\n> you to do this ? its not really tied to whether the overcommit Is defined in\n> the scheduler or the host though as far as I can see.\n> \n> I\'m looking forward to seeing this in nova-specs!\n> ~ Scott _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n> \n> _______________________________________________\n> OpenStack-dev mailing list\n> OpenStack-dev at lists.openstack.org\n> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n> \n\n\n','<OF566B3D52.C6C7C1FB-ONC2257CF2.00696C57-C2257CF2.0069A3F6@il.ibm.com>',NULL),('<1803540010.0.1377410784224.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-08-25 06:06:24',0,'2013-08-25 06:06:24',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-heat-python27-stable-grizzly #8','See <https://jenkins01.openstack.org/job/periodic-heat-python27-stable-grizzly/8/>\n\n\n\n','<438396917.5.1377325015077.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1803687570.59.1386741797711.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-12-11 06:03:17',0,'2013-12-11 06:03:17',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-heat-docs-grizzly #6','See <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/6/>\n\n------------------------------------------\n[...truncated 18 lines...]\n+ source /usr/local/jenkins/slave_scripts/functions.sh\n+ check_variable_org_project openstack heat /usr/local/jenkins/slave_scripts/run-docs.sh\n+ org=openstack\n+ project=heat\n+ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n+ [[ -z openstack ]]\n+ [[ -z heat ]]\n+ source /usr/local/jenkins/slave_scripts/select-mirror.sh openstack heat\n++ org=openstack\n++ project=heat\n++ source /usr/local/jenkins/slave_scripts/functions.sh\n++ check_variable_org_project openstack heat /usr/local/jenkins/slave_scripts/run-docs.sh\n++ org=openstack\n++ project=heat\n++ filename=/usr/local/jenkins/slave_scripts/run-docs.sh\n++ [[ -z openstack ]]\n++ [[ -z heat ]]\n++ rm -f /home/jenkins/.pydistutils.cfg\n++ mkdir -p /home/jenkins/.pip\n++ rm -f /home/jenkins/.pip/pip.conf\n++ cat\n++ grep -x openstack/heat /opt/requirements/projects.txt\nopenstack/heat\n++ export TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ TOX_INDEX_URL=http://pypi.openstack.org/openstack\n++ cat\n++ cat\n+ venv=venv\n+ mkdir -p doc/build\n+ export HUDSON_PUBLISH_DOCS=1\n+ HUDSON_PUBLISH_DOCS=1\n+ tox -evenv -- python setup.py build_sphinx\nGLOB sdist-make: <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/setup.py>\nvenv create: <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/.tox/venv>\nvenv installdeps: -r<https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/tools/pip-requires,> -r<https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/tools/test-requires>\nvenv inst: <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/.tox/dist/heat-jenkins.periodic.heat.docs.grizzly.6.zip>\nvenv runtests: commands[0] | python setup.py build_sphinx\nrunning build_sphinx\ncreating <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/doc/build/doctrees>\ncreating <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/doc/build/html>\n**Autodocumenting from <https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/>\nGenerating doc/source/api/heat.api.aws.ec2token.rst\nGenerating doc/source/api/heat.api.aws.exception.rst\nGenerating doc/source/api/heat.api.aws.utils.rst\nGenerating doc/source/api/heat.api.cfn.v1.stacks.rst\nGenerating doc/source/api/heat.api.cfn.v1.waitcondition.rst\nGenerating doc/source/api/heat.api.cfn.versions.rst\nGenerating doc/source/api/heat.api.cloudwatch.versions.rst\nGenerating doc/source/api/heat.api.cloudwatch.watch.rst\nGenerating doc/source/api/heat.api.middleware.context.rst\nGenerating doc/source/api/heat.api.middleware.version_negotiation.rst\nGenerating doc/source/api/heat.api.openstack.v1.events.rst\nGenerating doc/source/api/heat.api.openstack.v1.resources.rst\nGenerating doc/source/api/heat.api.openstack.v1.stacks.rst\nGenerating doc/source/api/heat.api.openstack.v1.util.rst\nGenerating doc/source/api/heat.api.openstack.versions.rst\nGenerating doc/source/api/heat.cfn_client.boto_client.rst\nGenerating doc/source/api/heat.cfn_client.boto_client_cloudwatch.rst\nGenerating doc/source/api/heat.cfn_client.client.rst\nGenerating doc/source/api/heat.cfn_client.utils.rst\nGenerating doc/source/api/heat.cloudinit.loguserdata.rst\nGenerating doc/source/api/heat.cloudinit.part-handler.rst\nGenerating doc/source/api/heat.common.auth.rst\nGenerating doc/source/api/heat.common.auth_token.rst\nGenerating doc/source/api/heat.common.client.rst\nGenerating doc/source/api/heat.common.config.rst\nGenerating doc/source/api/heat.common.context.rst\nGenerating doc/source/api/heat.common.crypt.rst\nGenerating doc/source/api/heat.common.custom_backend_auth.rst\nGenerating doc/source/api/heat.common.ec2signer.rst\nGenerating doc/source/api/heat.common.exception.rst\nGenerating doc/source/api/heat.common.heat_keystoneclient.rst\nGenerating doc/source/api/heat.common.identifier.rst\nGenerating doc/source/api/heat.common.plugin_loader.rst\nGenerating doc/source/api/heat.common.policy.rst\nGenerating doc/source/api/heat.common.short_id.rst\nGenerating doc/source/api/heat.common.template_format.rst\nGenerating doc/source/api/heat.common.urlfetch.rst\nGenerating doc/source/api/heat.common.utils.rst\nGenerating doc/source/api/heat.common.wsgi.rst\nGenerating doc/source/api/heat.db.api.rst\nGenerating doc/source/api/heat.db.migration.rst\nGenerating doc/source/api/heat.db.sqlalchemy.api.rst\nGenerating doc/source/api/heat.db.sqlalchemy.manage.rst\nGenerating doc/source/api/heat.db.sqlalchemy.migrate_repo.manage.rst\nGenerating doc/source/api/heat.db.sqlalchemy.migrate_repo.versions.015_grizzly.rst\nGenerating doc/source/api/heat.db.sqlalchemy.migration.rst\nGenerating doc/source/api/heat.db.sqlalchemy.models.rst\nGenerating doc/source/api/heat.db.sqlalchemy.session.rst\nGenerating doc/source/api/heat.db.sync.rst\nGenerating doc/source/api/heat.db.utils.rst\nGenerating doc/source/api/heat.engine.api.rst\nGenerating doc/source/api/heat.engine.clients.rst\nGenerating doc/source/api/heat.engine.dependencies.rst\nGenerating doc/source/api/heat.engine.event.rst\nGenerating doc/source/api/heat.engine.parameters.rst\nGenerating doc/source/api/heat.engine.parser.rst\nGenerating doc/source/api/heat.engine.properties.rst\nGenerating doc/source/api/heat.engine.resource.rst\nGenerating doc/source/api/heat.engine.resources.autoscaling.rst\nGenerating doc/source/api/heat.engine.resources.cloud_watch.rst\nGenerating doc/source/api/heat.engine.resources.dbinstance.rst\nGenerating doc/source/api/heat.engine.resources.eip.rst\nGenerating doc/source/api/heat.engine.resources.instance.rst\nGenerating doc/source/api/heat.engine.resources.internet_gateway.rst\nGenerating doc/source/api/heat.engine.resources.loadbalancer.rst\nGenerating doc/source/api/heat.engine.resources.network_interface.rst\nGenerating doc/source/api/heat.engine.resources.quantum.floatingip.rst\nGenerating doc/source/api/heat.engine.resources.quantum.net.rst\nGenerating doc/source/api/heat.engine.resources.quantum.port.rst\nGenerating doc/source/api/heat.engine.resources.quantum.quantum.rst\nGenerating doc/source/api/heat.engine.resources.quantum.router.rst\nGenerating doc/source/api/heat.engine.resources.quantum.subnet.rst\nGenerating doc/source/api/heat.engine.resources.route_table.rst\nGenerating doc/source/api/heat.engine.resources.s3.rst\nGenerating doc/source/api/heat.engine.resources.security_group.rst\nGenerating doc/source/api/heat.engine.resources.stack.rst\nGenerating doc/source/api/heat.engine.resources.subnet.rst\nGenerating doc/source/api/heat.engine.resources.swift.rst\nGenerating doc/source/api/heat.engine.resources.user.rst\nGenerating doc/source/api/heat.engine.resources.volume.rst\nGenerating doc/source/api/heat.engine.resources.vpc.rst\nGenerating doc/source/api/heat.engine.resources.wait_condition.rst\nGenerating doc/source/api/heat.engine.service.rst\nGenerating doc/source/api/heat.engine.stack_resource.rst\nGenerating doc/source/api/heat.engine.template.rst\nGenerating doc/source/api/heat.engine.timestamp.rst\nGenerating doc/source/api/heat.engine.watchrule.rst\nGenerating doc/source/api/heat.openstack.common.eventlet_backdoor.rst\nGenerating doc/source/api/heat.openstack.common.exception.rst\nGenerating doc/source/api/heat.openstack.common.excutils.rst\nGenerating doc/source/api/heat.openstack.common.gettextutils.rst\nGenerating doc/source/api/heat.openstack.common.importutils.rst\nGenerating doc/source/api/heat.openstack.common.jsonutils.rst\nGenerating doc/source/api/heat.openstack.common.local.rst\nGenerating doc/source/api/heat.openstack.common.log.rst\nGenerating doc/source/api/heat.openstack.common.loopingcall.rst\nGenerating doc/source/api/heat.openstack.common.network_utils.rst\nGenerating doc/source/api/heat.openstack.common.notifier.api.rst\nGenerating doc/source/api/heat.openstack.common.notifier.list_notifier.rst\nGenerating doc/source/api/heat.openstack.common.notifier.log_notifier.rst\nGenerating doc/source/api/heat.openstack.common.notifier.no_op_notifier.rst\nGenerating doc/source/api/heat.openstack.common.notifier.rabbit_notifier.rst\nGenerating doc/source/api/heat.openstack.common.notifier.rpc_notifier.rst\nGenerating doc/source/api/heat.openstack.common.notifier.rpc_notifier2.rst\nGenerating doc/source/api/heat.openstack.common.notifier.test_notifier.rst\nGenerating doc/source/api/heat.openstack.common.policy.rst\nGenerating doc/source/api/heat.openstack.common.rpc.amqp.rst\nGenerating doc/source/api/heat.openstack.common.rpc.common.rst\nGenerating doc/source/api/heat.openstack.common.rpc.dispatcher.rst\nGenerating doc/source/api/heat.openstack.common.rpc.impl_fake.rst\nGenerating doc/source/api/heat.openstack.common.rpc.impl_kombu.rst\nGenerating doc/source/api/heat.openstack.common.rpc.impl_qpid.rst\nGenerating doc/source/api/heat.openstack.common.rpc.impl_zmq.rst\nGenerating doc/source/api/heat.openstack.common.rpc.matchmaker.rst\nGenerating doc/source/api/heat.openstack.common.rpc.proxy.rst\nGenerating doc/source/api/heat.openstack.common.rpc.service.rst\nGenerating doc/source/api/heat.openstack.common.service.rst\nGenerating doc/source/api/heat.openstack.common.setup.rst\nGenerating doc/source/api/heat.openstack.common.threadgroup.rst\nGenerating doc/source/api/heat.openstack.common.timeutils.rst\nGenerating doc/source/api/heat.openstack.common.utils.rst\nGenerating doc/source/api/heat.openstack.common.uuidutils.rst\nGenerating doc/source/api/heat.openstack.common.version.rst\nGenerating doc/source/api/heat.rpc.api.rst\nGenerating doc/source/api/heat.rpc.client.rst\nGenerating doc/source/api/heat.testing.runner.rst\nGenerating doc/source/api/heat.tests.examples.test1.rst\nGenerating doc/source/api/heat.tests.examples.test2.rst\nGenerating doc/source/api/heat.tests.examples.test3.rst\nGenerating doc/source/api/heat.tests.fakes.rst\nGenerating doc/source/api/heat.tests.functional.test_AutoScalingMultiAZSample.rst\nGenerating doc/source/api/heat.tests.functional.test_CFN_API_Actions.rst\nGenerating doc/source/api/heat.tests.functional.test_CFN_API_Actions_Boto.rst\nGenerating doc/source/api/heat.tests.functional.test_CFN_API_UpdateStack.rst\nGenerating doc/source/api/heat.tests.functional.test_HAProxy_Single_Instance.rst\nGenerating doc/source/api/heat.tests.functional.test_OpenShift_Prebuilt_JEOS.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_2_Instances.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_2_Instances_With_EBS.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_2_Instances_With_EBS_EIP.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Composed_Instances.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_Boto.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_With_EBS.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_With_EBS_EIP.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_With_EIP.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_With_HA.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_Single_Instance_With_IHA.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_With_LB.rst\nGenerating doc/source/api/heat.tests.functional.test_WordPress_With_RDS.rst\nGenerating doc/source/api/heat.tests.functional.util.rst\nGenerating doc/source/api/heat.tests.functional.verify.rst\nGenerating doc/source/api/heat.tests.generic_resource.rst\nGenerating doc/source/api/heat.tests.test_api_aws.rst\nGenerating doc/source/api/heat.tests.test_api_cfn_v1.rst\nGenerating doc/source/api/heat.tests.test_api_cloudwatch.rst\nGenerating doc/source/api/heat.tests.test_api_ec2token.rst\nGenerating doc/source/api/heat.tests.test_api_openstack_v1.rst\nGenerating doc/source/api/heat.tests.test_autoscaling.rst\nGenerating doc/source/api/heat.tests.test_cli.rst\nGenerating doc/source/api/heat.tests.test_common_policy.rst\nGenerating doc/source/api/heat.tests.test_dbinstance.rst\nGenerating doc/source/api/heat.tests.test_dependencies.rst\nGenerating doc/source/api/heat.tests.test_eip.rst\nGenerating doc/source/api/heat.tests.test_engine_api_utils.rst\nGenerating doc/source/api/heat.tests.test_engine_service.rst\nGenerating doc/source/api/heat.tests.test_event.rst\nGenerating doc/source/api/heat.tests.test_identifier.rst\nGenerating doc/source/api/heat.tests.test_instance.rst\nGenerating doc/source/api/heat.tests.test_instance_group.rst\nGenerating doc/source/api/heat.tests.test_instance_network.rst\nGenerating doc/source/api/heat.tests.test_loadbalancer.rst\nGenerating doc/source/api/heat.tests.test_loguserdata.rst\nGenerating doc/source/api/heat.tests.test_metadata_refresh.rst\nGenerating doc/source/api/heat.tests.test_nested_stack.rst\nGenerating doc/source/api/heat.tests.test_nokey.rst\nGenerating doc/source/api/heat.tests.test_parameters.rst\nGenerating doc/source/api/heat.tests.test_parser.rst\nGenerating doc/source/api/heat.tests.test_plugin_loader.rst\nGenerating doc/source/api/heat.tests.test_properties.rst\nGenerating doc/source/api/heat.tests.test_quantum.rst\nGenerating doc/source/api/heat.tests.test_resource.rst\nGenerating doc/source/api/heat.tests.test_rpc_client.rst\nGenerating doc/source/api/heat.tests.test_s3.rst\nGenerating doc/source/api/heat.tests.test_security_group.rst\nGenerating doc/source/api/heat.tests.test_short_id.rst\nGenerating doc/source/api/heat.tests.test_sqlalchemy_api.rst\nGenerating doc/source/api/heat.tests.test_swift.rst\nGenerating doc/source/api/heat.tests.test_template_format.rst\nGenerating doc/source/api/heat.tests.test_urlfetch.rst\nGenerating doc/source/api/heat.tests.test_user.rst\nGenerating doc/source/api/heat.tests.test_validate.rst\nGenerating doc/source/api/heat.tests.test_volume.rst\nGenerating doc/source/api/heat.tests.test_vpc.rst\nGenerating doc/source/api/heat.tests.test_waitcondition.rst\nGenerating doc/source/api/heat.tests.test_watch.rst\nGenerating doc/source/api/heat.tests.utils.rst\nGenerating doc/source/api/heat.tests.v1_1.fakes.rst\nGenerating doc/source/api/heat.tests.v1_1.utils.rst\nGenerating doc/source/api/heat.version.rst\nerror: \'source_dir\' must be a directory name (got `<https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/doc/source`)>\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-heat-docs-grizzly/ws/.tox/venv/bin/python> setup.py build_sphinx\'\n___________________________________ summary ____________________________________\nERROR:   venv: commands failed\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-docs-grizzly/precise5\n[SCP] Trying to create /srv/static/logs/periodic/periodic-heat-docs-grizzly/precise5/6\n[SCP] Copying console log.\n\n\n',NULL,NULL),('<1803699183.97.1383891252948.JavaMail.jenkins@jenkins02.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-08 06:14:12',0,'2013-11-08 06:14:12',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n periodic-glance-python27-stable-grizzly #41','See <https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/41/>\n\n------------------------------------------\n[...truncated 1463 lines...]\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4993750>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4993750>}\nglance.api.policy: DEBUG: Loaded policy rules: {u\'default\': \'@\'}\nglance.common.client: DEBUG: Constructed URL: http://0.0.0.0:9191/images/detail?changes-since=2011-09-05\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e4f710>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x4e4f710>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nglance.registry.client: DEBUG: Registry request GET /images/detail HTTP 200 request id req-96764775-6eec-4972-a49b-97fbec12db10\n--------------------- >> end captured logging << ---------------------\n\n======================================================================\nFAIL: glance.tests.unit.v1.test_api.TestRegistryAPI.test_get_details_filter_changes_since\n----------------------------------------------------------------------\n_StringException: Traceback (most recent call last):\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/glance/tests/unit/v1/test_api.py\",> line 1414, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 322, in assertEqual\n    self.assertThat(observed, matcher, message)\n  File \"<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py\",> line 412, in assertThat\n    raise MismatchError(matchee, matcher, mismatch, verbose)\nMismatchError: 200 != 400\n\n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store.filesystem: ERROR: Could not find filesystem_store_datadir in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store filesystem could not be configured correctly. Reason: Could not find filesystem_store_datadir in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: DEBUG: Could not find s3_store_host in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store s3 could not be configured correctly. Reason: Could not find s3_store_host in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: WARNING: Failed to configure store correctly: Store swift could not be configured correctly. Reason: Could not find swift_store_auth_address in configuration options. Disabling add method.\nglance.store: DEBUG: Registering store <function Store at 0x2d658c0> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <function Store at 0x2d658c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <function Store at 0x2d658c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <function Store at 0x2d658c0>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2013-11-07T06:13:28Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'28\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'07\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'07\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2013-11-09T06:13:28Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'28\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'09\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:13:28+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'28\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2013-11-10T06:13:28-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'28\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'10\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'10\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2013-11-11T06:13:28Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'28\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'11\', \'minute\': u\'13\'} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'13\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'28\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x5f6f150>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x19082d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 99.06 secs:\n    28.06    TestScrubber.test_scrubber_app\n    21.94    TestScrubber.test_delayed_delete\n    16.96    TestBinGlanceCacheManage.test_queue\n    16.73    TestRootApi.test_version_configurations\n    15.36    TestGlanceControl.test_reload\n----------------------------------------------------------------------\nRan 1109 tests in 736.432s\n\nFAILED (SKIP=42, failures=2)\nERROR: InvocationError: \'<https://jenkins02.openstack.org/job/periodic-glance-python27-stable-grizzly/ws/.tox/py27/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py27: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py27/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nMySQL-python==1.2.4\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.2.3\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.15.0\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nextras==0.0.3\nfixtures==0.3.14\nglance==jenkins.periodic.glance.python27.stable.grizzly.41\ngreenlet==0.4.1\nhttplib2==0.8\niso8601==0.1.8\njsonschema==2.3.0\nkombu==3.0.3\nlxml==3.2.3\nmox==0.5.3\nnetaddr==0.7.10\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\noslo.config==1.2.1\npasslib==1.6.1\npbr==0.5.23\npep8==1.3.3\nprettytable==0.7.2\npsycopg2==2.5.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-keystoneclient==0.4.1\npython-mimeparse==0.1.4\npython-swiftclient==1.8.0\npytz==2013.8\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsix==1.4.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\ntesttools==0.9.33\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=125\n+ \'[\' 125 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.zifbtYMZqP\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] uploading file: \'/srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/41/nose_results.html\'\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python27-stable-grizzly/precise28/41\n[SCP] Copying console log.\n\n\n','<506667058.92.1383804579132.JavaMail.jenkins@jenkins02.openstack.org>',NULL),('<1803710203.359511393347669930.JavaMail.nobody@rsj2rmd002.webex.com>','http://lists.openstack.org/pipermail/foundation',NULL,'2014-02-25 17:01:09',0,'2014-02-25 17:01:09',NULL,'[OpenStack Foundation] Training session reminder: OpenStack Board\n Meeting March 4, 2014 (F2F meeting)','Hello Foundation Mailing List,\n\nAlan Clark invites you to participate as an attendee in the OpenStack Board meeting:\n\nTopic: OpenStack Board Meeting March 4, 2014 (F2F meeting)\nHost: Alan Clark\nDate: Tuesday, March 4, 2014\nTime: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00)\n\nSession number: 926 584 365\nSession password: This session does not require a password.\n\n-------------------------------------------------------\nTo join the session\n-------------------------------------------------------\n1. Go to https://openstack.webex.com/openstack/k2/j.php?MTID=t7f162cbf8667e42cc4c43fcb840e31a8\n2. Enter your name and email address (or registration ID).\n3. Enter the session password: This session does not require a password.\n4. Click \"Join Now\".\n5. Follow the instructions that appear on your screen.\n\nTo view in other time zones or languages, please click the link\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=tb74dc31225bf9c2c3a45c14a0a7098b4\n\n-------------------------------------------------------\nTo join the session by phone only \n-------------------------------------------------------\nTo receive a call back, provide your phone number when you join the training session, or call the number below and enter the access code.\nCall-in toll number (US/Canada):1-650-479-3207\nCall-in toll-free number (US/Canada):1-855-244-8681\n\nHaving trouble dialing in? Try these backup numbers:\nCall-in toll-free number (US/Canada):1-855-244-8681 \nCall-in toll number (US/Canada):1-650-479-3207\nGlobal call-in numbers: https://openstack.webex.com/openstack/globalcallin.php?serviceType=TC&ED=272441082&tollFree=1\nShow toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf\nAccess code: 926 584 365\n\n-------------------------------------------------------\nFor assistance\n-------------------------------------------------------\nYou can contact Alan Clark at:\n aclark at suse.com\n\n\nTo add this meeting to your calendar program (for example Microsoft Outlook), click this link:\nhttps://openstack.webex.com/openstack/k2/j.php?MTID=t8c379f2c453e2fe18a869125327e39a2\n\nhttp://www.webex.com \n\nIMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/foundation/attachments/20140225/9b2a4914/attachment.html>\n\n',NULL,NULL),('<180374569.57.1381645089505.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-10-13 06:18:09',0,'2013-10-13 06:18:09',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-tempest-devstack-vm-neutron-stable-grizzly #39','See <https://jenkins01.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/39/>\n\n\n\n','<178701082.42.1381385404601.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1804234313.1595257.1395854060910.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-03-26 13:14:20',-14400,'2014-03-26 17:14:20',NULL,'[openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0','Code which breaks:\n\nGlance\'s mutliprocessing tests will break (the reason we should limit it now).\nFor the future, people attempting to use psutil will have no clear version target\n(Either they use 1.x and break with the people who install the latest version from pip,\nof they use 2.0.0 and break with everything that doesn\'t use the latest version).\n\npsutil\'s API is extremely unstable -- it has undergone major revisions going from 0.x to 1.x, and now\n1.x to 2.0.0.  Limiting psutil explicitly to a single major version (it was more or less implicitly limited\nbefore, since there was no version major version above 1) ensures that the requirements.txt file actually\nindicates what is necessary to use OpenStack.\n\nThe alternative option would be to update the glance tests, but my concern is that 2.0.0 is not available\nfrom the package managers of most distros yet.\n\nBest Regards,\nSolly Ross\n\n----- Original Message -----\nFrom: \"Sean Dague\" <sean at dague.net>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: Wednesday, March 26, 2014 10:39:41 AM\nSubject: Re: [openstack-dev] [depfreeze] Exception: limit psutil to <2.0.0\n\nOn 03/26/2014 10:30 AM, Solly Ross wrote:\n> Hi,\n> I currently have a patch up for review (https://review.openstack.org/#/c/81373/) to limit psutil be <2.0.0.\n> 2.0.0 just came out a couple weeks ago, and breaks the API in a major way.  Until we can port our code to the\n> latest version, I suggest we limit the version of psutil to 1.x (currently there\'s a lower bound in the 1.x\n> range, just not an upper bound).\n\nWhich code will be broken by this if it\'s not done? Is there an RC bug\ntracking it?\n\n	-Sean\n\n-- \nSean Dague\nSamsung Research America\nsean at dague.net / sean.dague at samsung.com\nhttp://dague.net\n\n\n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<5332E6AD.2010307@dague.net>',NULL),('<1804559015.47415228.1394831054393.JavaMail.root@vmware.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-14 14:04:14',-25200,'2014-03-14 21:04:14',NULL,'[Openstack] ESXi in production with Neutron','Hi Paul, \n\nIn my experience working with customers, people typically either dip their toe in to start by just running ESXi/vSphere with nova-network, or they have decided on NSX from the get-go and start with Neutron. If you\'re just looking for nova-network, VOVA makes it really easy to do a basic nova-network setup: https://communities.vmware.com/docs/DOC-24626 \n\nOne word of caution is that I have seen several cases of people who deploy Neutron with the OVS plugin with ESX, thinking that the plugin is actually working when in fact all VMs are simply getting plugged into a single port group. If all you test is that VMs can ping each other, you think it is working. But if you actually test L2 isolation, security groups, etc. there is no isolation because the OVS plugin is not actually managing the vSwitch. \n\nMoving forward, there is a group of Neutron developers working on creating a plugin that works with basic vSphere vswitch APIs that come with vCenter (i.e., vSS and vDS), that should provide a basic Neutron plugin to support initial testing. \n\nDan \n\n----- Original Message -----\n\n| From: \"Rajshree Thorat\" <rajshree.thorat at gslab.com>\n| To: \"PAUL CARVER\" <pc2929 at att.com>, openstack at lists.openstack.org\n| Sent: Friday, March 14, 2014 5:55:37 AM\n| Subject: Re: [Openstack] ESXi in production with Neutron\n\n| Hi Paul,\n\n| We are using ESXi in production setup with Neutron networking. ESXi is\n| compatible with OpenStack and specifically\n| with neutron networking. You need to add some rules in ovs and for the same\n| you can refer below link.\n\n| http://www.gossamer-threads.com/lists/openstack/dev/31141\n\n| On 3/14/2014 5:46 PM, CARVER, PAUL wrote:\n\n| | Is anyone using ESXi in production with Neutron networking?\n| \n\n| | We currently run a production OpenStack cloud with KVM only using OvS+GRE\n| | networking. We?re in the process of evaluating a number of commercial SDN\n| | vendors but we?re being asked to support ESXi in the really near timeframe\n| | before we?ve had sufficient time to complete an objective evaluation of all\n| | the available vendors who would like to sell us an SDN solution.\n| \n\n| | If anyone is running an OpenStack cloud that includes ESXi hypervisors but\n| | does not rely on a commercial SDN vendor to make it work I?d love to hear\n| | about it. I?m not eager to bypass the vendor evaluation process and\n| | randomly\n| | pick a vendor without an objective and fair evaluation, but I?m finding it\n| | hard to locate any documentation that indicates that ESXi is compatible\n| | with\n| | OpenStack (and specifically Neutron networking) unless you also select one\n| | of the commercial SDN vendors to bridge the gaps.\n| \n\n| | If we could add ESXi nodes to our current OpenStack zones, even if there\n| | were\n| | some known functional shortcomings, it would give us some breathing room on\n| | evaluating SDN vendors in a diligent manner.\n| \n\n| | --\n| \n\n| | Paul Carver\n| \n\n| | VO: 732-545-7377\n| \n\n| | Cell: 908-803-1656\n| \n\n| | E: pcarver at att.com\n| \n\n| | Q Instant Message\n| \n\n| | _______________________________________________\n| \n| | Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n| | Post to     : openstack at lists.openstack.org Unsubscribe :\n| | http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n| \n\n| --\n| Regards,\n| Rajshree\n\n| _______________________________________________\n| Mailing list:\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=NhWkAdHdN8VJa5KRLSgMSMt%2BTnbF5NgObQi3xMvW59s%3D%0A&s=9e9414884f6c3585b67791b3001501ab9522f54054f8f68479b677f247577822\n| Post to : openstack at lists.openstack.org\n| Unsubscribe :\n| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FGmAC0C4XZyIEAvm3CvAWMRhdLzlce10LeJNK46NsWU%3D%0A&m=NhWkAdHdN8VJa5KRLSgMSMt%2BTnbF5NgObQi3xMvW59s%3D%0A&s=9e9414884f6c3585b67791b3001501ab9522f54054f8f68479b677f247577822\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: <http://lists.openstack.org/pipermail/openstack/attachments/20140314/878b3ab0/attachment.html>\n\n','<5322FC49.1060502@gslab.com>',NULL),('<180486886.1514404.1371372019623.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-qa',NULL,'2013-06-16 04:40:19',-14400,'2013-06-16 08:40:19',NULL,'[openstack-qa] Priolity brainstorming my initial toughts','History of the Active VM creation performance.\n\nhttps://bugs.launchpad.net/nova/+bug/1016633 <open>\n\nhttps://bugs.launchpad.net/nova/+bug/1100446 <fixed>\n\n----- Original Message -----\nFrom: \"Christopher Yeoh\" <cyeoh at au1.ibm.com>\nTo: openstack-qa at lists.openstack.org\nSent: Sunday, June 16, 2013 9:12:50 AM\nSubject: Re: [openstack-qa] Priolity brainstorming my initial toughts\n\nOn Fri, 14 Jun 2013 16:13:24 -0400\nMatthew Treinish <mtreinish at kortar.org> wrote:\n\n> On Fri, Jun 14, 2013 at 09:12:11PM +0200, Giulio Fidente wrote:\n> > On 06/14/2013 10:33 AM, Attila Fazekas wrote:\n> > >- Gate time is continuously increasing and it will\n> > >   if we do not act soon.\n> > \n> > It\'s an interesting topic but I need a little wrap on on the\n> > situation. Still, it\'ll hopefully be useful to other people also\n> > willing to contribute.\n> > \n> > What are the blockers currently preventing us from using testr and\n> > \"drop\" nose?\n> \n> So testr will technically run today, (to test it use \'testr run\' or\n> in parallel \'testr run --parallel\') but you\'ll find that it is slower\n> than just running serially with nose. \n\nWhat sort of machine are you finding that running in parallel runs\nslower than run serially with nose? A few months ago I was seeing a 2x\nspeed up on 4 core machine when running with testr in parallel compared\nto running with nose serially.\n\nChris\n-- \ncyeoh at au1.ibm.com\n\n\n_______________________________________________\nopenstack-qa mailing list\nopenstack-qa at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa\n\n\n','<20130616164250.300a581c@rockhopper>',NULL),('<1805870625.17373618.1394709981371.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-03-13 07:26:21',-14400,'2014-03-13 11:26:21',NULL,'[Openstack] Request for help - Heat Auto-scaling','\nWhat version of Heat are you using?\n\nThe repeat_actions attribute on the alarms was needed to set\nexplicitly True in Havana (whereas this is now the default).\n\nThis continuous notification is needed for the Heat autoscaling\nlogic to kick in successfully.\n\nSo if using Havana, please add this setting to CPUAlarmHigh\n& CPUAlarmLow.\n\nCheers,\nEoghan\n\n\n----- Original Message -----\n> Hello Jay,\n> Thanks, here is my template:\n> \n> {\n> \"AWSTemplateFormatVersion\" : \"2014-03-06\",\n> \n> \"Parameters\" : {\n> \"InstanceType\" : {\n> \"Description\" : \"WebServer EC2 instance type\",\n> \"Type\" : \"String\",\n> \"Default\" : \"m1.small\",\n> \"ConstraintDescription\" : \"must be a valid EC2 instance type.\"\n> },\n> \"WebServerPort\" : {\n> \"Description\" : \"TCP/IP port of the web server\",\n> \"Type\" : \"String\",\n> \"Default\" : \"8888\"\n> },\n> \"KeyName\" : {\n> \"Description\" : \"Name of an existing EC2 KeyPair to enable SSH access to the\n> instances\",\n> \"Type\" : \"String\",\n> \"Default\" : \"damonkey\"\n> }\n> },\n> \n> \"Resources\" : {\n> \"WebServerGroup\" : {\n> \"Type\" : \"AWS::AutoScaling::AutoScalingGroup\",\n> \"Properties\" : {\n> \"AvailabilityZones\" : { \"Fn::GetAZs\" : \"\" },\n> \"LaunchConfigurationName\" : { \"Ref\" : \"LaunchConfig\" },\n> \"MinSize\" : \"1\",\n> \"MaxSize\" : \"3\"\n> }\n> },\n> \"ScaleUpPolicy\": {\n> \"Type\": \"AWS::AutoScaling::ScalingPolicy\",\n> \"Properties\": {\n> \"AdjustmentType\": \"ChangeInCapacity\",\n> \"AutoScalingGroupName\": \"WebServerGroup\",\n> \"Cooldown\": \"60\",\n> \"ScalingAdjustment\": \"1\"\n> }\n> },\n> \"ScaleDownPolicy\": {\n> \"Type\": \"AWS::AutoScaling::ScalingPolicy\",\n> \"Properties\": {\n> \"AdjustmentType\": \"ChangeInCapacity\",\n> \"AutoScalingGroupName\": \"WebServerGroup\",\n> \"Cooldown\": \"60\",\n> \"ScalingAdjustment\": \"-1\"\n> }\n> },\n> \"CPUAlarmHigh\": {\n> \"Type\": \"OS::Ceilometer::Alarm\",\n> \"Properties\": {\n> \"description\": \"Scale-up if CPU is greater than 90% for 10 seconds\",\n> \"meter_name\": \"cpu_util\",\n> \"statistic\": \"avg\",\n> \"period\": \"10\",\n> \"evaluation_periods\": \"1\",\n> \"threshold\": \"90\",\n> \"alarm_actions\": [ {\"Fn::GetAtt\": [\"ScaleUpPolicy\", \"AlarmUrl\"]} ],\n> \"matching_metadata\": {\"metadata.user_metadata.server_group\": \"WebServerGroup\"\n> },\n> \"comparison_operator\": \"gt\"\n> }\n> },\n> \"CPUAlarmLow\": {\n> \"Type\": \"OS::Ceilometer::Alarm\",\n> \"Properties\": {\n> \"description\": \"Scale-down if CPU is less than 50% for 10 seconds\",\n> \"meter_name\": \"cpu_util\",\n> \"statistic\": \"avg\",\n> \"period\": \"10\",\n> \"evaluation_periods\": \"1\",\n> \"threshold\": \"50\",\n> \"alarm_actions\": [ {\"Fn::GetAtt\": [\"ScaleDownPolicy\", \"AlarmUrl\"]} ],\n> \"matching_metadata\": {\"metadata.user_metadata.server_group\": \"WebServerGroup\"\n> },\n> \"comparison_operator\": \"lt\"\n> }\n> },\n> \"LaunchConfig\" : {\n> \"Type\" : \"AWS::AutoScaling::LaunchConfiguration\",\n> \"Properties\" : {\n> \"KeyName\" : { \"Ref\" : \"KeyName\" },\n> \"ImageId\" : \"CirrOS 0.3.1\",\n> \"UserData\" : { \"Fn::Base64\" : { \"Ref\" : \"WebServerPort\" }},\n> \"SecurityGroups\" : [ \"default\" ],\n> \"InstanceType\" : { \"Ref\" : \"InstanceType\" }\n> }\n> }\n> }\n> \n> }\n> \n> \n> 2014-03-13 13:29 GMT+08:00 Micheal < pannov.tsth at gmail.com > :\n> \n> \n> \n> Does Heat support auto-scaling in Havana ? The cloudwatch seems to be\n> deprecated, and the new mechanism with ceilometer seems not working either.\n> I can create stack successfully, but the stack with\n> AWS::AutoScaling::AutoScalingGroup can not auto-scaling as expected.\n> All replies appreciated, thanks!\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAH_+92rAEeQtU=BWtkCRGSqWmXBjS0YtWkVOW7dABrmwWo-NjA@mail.gmail.com>',NULL),('<1806178626.8697611.1393329201053.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-02-25 06:53:21',-18000,'2014-02-25 11:53:21',NULL,'[Openstack] [Heat/Ceilometer/Havana]: Auto scaling no longer\n occurring after some time','\nJuha,\n\nWhat are the actual average cpu_util stats for those periods\nin which scaling occurred or did not occur contrary to your\nexpectations? \n\nI mean, as reported by the ceilometer API, as opposed to being\ntotted up manually:\n\n  $ ceilometer statistics -m cpu_util -q metadata.user_metadata.server_group=GroupA -p 30 \n\nCheers,\nEoghan\n\n----- Original Message -----\n> Hi,\n> \n> Many thanks again.\n> \n> I fine tuned a little bit the heat template having now defined:\n> \n> Scale up: period 30, threshold 90, comparison_operator gt, statistic avg,\n> cooldown 60\n> Scale down: period 30, threshold 30, comparison_operator lt, statistic avg,\n> cooldown 60\n> \n> Workflow:\n> - create stack -> GroupA-0 instance is started\n> - generate load inside GroupA-0 -> cpu_util counter increses to >100%\n> - Group_A-1 instance gets automatically started and after a short while\n> also Group_A-2\n> - Situation remains the same, 3 instances keep on running, no down scaling\n> occurs.\n> \n> According to current thresholds down scaling shouldn\'t occur any longer\n> since:\n> 106.933333333 + 18.3333333333 + 13.5333333333 = ~139. And 139 / 3 = 46\n> \n> ...but I don\'t now see why the Group_A-2 was started in the first place.\n> \n> cpu_util counters received:\n> \n> Group_A-0:\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 34.2666666667 |\n> % | 2014-02-25T11:05:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 16.2 | % |\n> 2014-02-25T11:06:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 18.4666666667 |\n> % | 2014-02-25T11:06:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 19.5333333333 |\n> % | 2014-02-25T11:06:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 16.8 | % |\n> 2014-02-25T11:06:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 16.6 | % |\n> 2014-02-25T11:07:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 16.0 | % |\n> 2014-02-25T11:07:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 19.0666666667 |\n> % | 2014-02-25T11:07:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 18.0666666667 |\n> % | 2014-02-25T11:07:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 19.6666666667 |\n> % | 2014-02-25T11:08:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 19.7333333333 |\n> % | 2014-02-25T11:08:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 31.9333333333 |\n> % | 2014-02-25T11:08:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 120.2 | % |\n> 2014-02-25T11:08:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 118.866666667 |\n> % | 2014-02-25T11:09:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 120.066666667 |\n> % | 2014-02-25T11:09:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 120.133333333 |\n> % | 2014-02-25T11:09:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 118.333333333 |\n> % | 2014-02-25T11:09:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 119.8 | % |\n> 2014-02-25T11:10:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 120.133333333 |\n> % | 2014-02-25T11:10:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 118.4 | % |\n> 2014-02-25T11:10:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 120.866666667 |\n> % | 2014-02-25T11:10:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 109.666666667 |\n> % | 2014-02-25T11:11:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 89.6 | % |\n> 2014-02-25T11:11:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 107.4 | % |\n> 2014-02-25T11:11:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.333333333 |\n> % | 2014-02-25T11:11:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 103.533333333 |\n> % | 2014-02-25T11:12:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 107.4 | % |\n> 2014-02-25T11:12:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.8 | % |\n> 2014-02-25T11:12:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 107.266666667 |\n> % | 2014-02-25T11:12:56 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 107.466666667 |\n> % | 2014-02-25T11:13:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.066666667 |\n> % | 2014-02-25T11:13:26 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.866666667 |\n> % | 2014-02-25T11:13:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 102.0625 | % |\n> 2014-02-25T11:13:57 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 113.928571429 |\n> % | 2014-02-25T11:14:11 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 97.625 | % |\n> 2014-02-25T11:14:27 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 116.0 | % |\n> 2014-02-25T11:14:41 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 100.8125 | % |\n> 2014-02-25T11:14:57 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 108.133333333 |\n> % | 2014-02-25T11:15:12 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.4 | % |\n> 2014-02-25T11:15:27 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.533333333 |\n> % | 2014-02-25T11:15:42 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 108.666666667 |\n> % | 2014-02-25T11:15:57 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.466666667 |\n> % | 2014-02-25T11:16:12 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.133333333 |\n> % | 2014-02-25T11:16:27 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.4 | % |\n> 2014-02-25T11:16:42 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.466666667 |\n> % | 2014-02-25T11:16:57 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.733333333 |\n> % | 2014-02-25T11:17:12 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 105.466666667 |\n> % | 2014-02-25T11:17:27 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 103.666666667 |\n> % | 2014-02-25T11:17:42 |\n> | a7e07a40-45fe-48d2-81c5-412435708c98 | cpu_util | gauge | 106.933333333 |\n> % | 2014-02-25T11:17:57 |\n> Group_A-1\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 34.3333333333 |\n> % | 2014-02-25T11:10:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 17.0 | % |\n> 2014-02-25T11:10:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.6666666667 |\n> % | 2014-02-25T11:10:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.8666666667 |\n> % | 2014-02-25T11:11:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.3333333333 |\n> % | 2014-02-25T11:11:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.4666666667 |\n> % | 2014-02-25T11:11:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.0666666667 |\n> % | 2014-02-25T11:11:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.5333333333 |\n> % | 2014-02-25T11:12:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.4 | % |\n> 2014-02-25T11:12:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 17.9333333333 |\n> % | 2014-02-25T11:12:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.6666666667 |\n> % | 2014-02-25T11:12:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 20.1333333333 |\n> % | 2014-02-25T11:13:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 17.2 | % |\n> 2014-02-25T11:13:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.4 | % |\n> 2014-02-25T11:13:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.5333333333 |\n> % | 2014-02-25T11:13:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.6666666667 |\n> % | 2014-02-25T11:14:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 17.4666666667 |\n> % | 2014-02-25T11:14:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.8 | % |\n> 2014-02-25T11:14:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.4 | % |\n> 2014-02-25T11:14:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.3333333333 |\n> % | 2014-02-25T11:15:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.7333333333 |\n> % | 2014-02-25T11:15:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 17.8 | % |\n> 2014-02-25T11:15:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.3333333333 |\n> % | 2014-02-25T11:15:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.4 | % |\n> 2014-02-25T11:16:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.8666666667 |\n> % | 2014-02-25T11:16:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 16.8 | % |\n> 2014-02-25T11:16:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 20.2666666667 |\n> % | 2014-02-25T11:16:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 19.4 | % |\n> 2014-02-25T11:17:06 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.6 | % |\n> 2014-02-25T11:17:21 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 20.2 | % |\n> 2014-02-25T11:17:36 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.8666666667 |\n> % | 2014-02-25T11:17:51 |\n> | ec1d377e-fd24-4246-8099-e558858d2cf4 | cpu_util | gauge | 18.3333333333 |\n> % | 2014-02-25T11:18:06 |\n> Group_A-2:\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.5333333333 |\n> % | 2014-02-25T11:11:41 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.3333333333 |\n> % | 2014-02-25T11:11:56 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.5333333333 |\n> % | 2014-02-25T11:12:11 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.6 | % |\n> 2014-02-25T11:12:26 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.8 | % |\n> 2014-02-25T11:12:41 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.7333333333 |\n> % | 2014-02-25T11:12:56 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.0666666667 |\n> % | 2014-02-25T11:13:11 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.7333333333 |\n> % | 2014-02-25T11:13:26 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.6 | % |\n> 2014-02-25T11:13:41 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.6666666667 |\n> % | 2014-02-25T11:13:56 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.2666666667 |\n> % | 2014-02-25T11:14:11 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.3333333333 |\n> % | 2014-02-25T11:14:26 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.3333333333 |\n> % | 2014-02-25T11:14:41 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.8666666667 |\n> % | 2014-02-25T11:14:56 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.7333333333 |\n> % | 2014-02-25T11:15:11 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.375 | % |\n> 2014-02-25T11:15:27 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.0 | % |\n> 2014-02-25T11:15:42 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.5333333333 |\n> % | 2014-02-25T11:15:57 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.5333333333 |\n> % | 2014-02-25T11:16:12 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.5333333333 |\n> % | 2014-02-25T11:16:27 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.3333333333 |\n> % | 2014-02-25T11:16:42 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.5333333333 |\n> % | 2014-02-25T11:16:57 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.8666666667 |\n> % | 2014-02-25T11:17:12 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.6 | % |\n> 2014-02-25T11:17:27 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 14.4666666667 |\n> % | 2014-02-25T11:17:42 |\n> | 2505efaf-0656-44a3-8dad-f694251980fd | cpu_util | gauge | 13.5333333333 |\n> % | 2014-02-25T11:17:57 |\n> Br,\n> -Juha\n> \n> \n> \n> \n> On 25 February 2014 11:22, Eoghan Glynn <eglynn at redhat.com> wrote:\n> \n> >\n> > Juha,\n> >\n> > What is the actual cpu_util trend looking like about the time\n> > upscaling occurs?\n> >\n> > In the original template you provided, the cooldown period was set\n> > so as to be quite short (IIRC, 20s).\n> >\n> > So if your artificial load on the first instance drives the cpu_util\n> > above the high-water-mark alarm threshold, e.g. to say 91%, then the\n> > newly launched instance has little load to contend with, giving an\n> > average cpu_util of the instance group of ~46%, then the continual\n> > scale-up/scale-down thrashing that you see is just autoscaling doing\n> > exactly what you\'ve told it to do.\n> >\n> > To avoid this, you\'ll need to:\n> >\n> > * ensure that the \"load\" is spread across the current instance group\n> >   members in a roughly fair distribution (this is often achieved in\n> >   practice using a load balancer randomizing or round-robining)\n> >\n> > * increase the cooldown period to allow the load distribution to\n> >   \"settle\" after a scaling operation has taken place\n> >\n> > * ensure that the low-water-mark alarm threshold is sufficiently\n> >   distant from that of the high-water-mark alarm\n> >\n> > Cheers,\n> > Eoghan\n> >\n> > ----- Original Message -----\n> > > Hi,\n> > >\n> > > Some update... I yesterday added \"repeat_actions\" : true -definition to\n> > > OS::Ceilometer::Alarm resources in the Heat template:\n> > >\n> > > \"CPUAlarmHigh\": {\n> > > \"Type\": \"OS::Ceilometer::Alarm\",\n> > > \"Properties\": {\n> > > \"description\": \"Scale-up if CPU is greater than 90% for 30 seconds\",\n> > > \"meter_name\": \"cpu_util\",\n> > > \"statistic\": \"avg\",\n> > > \"period\": \"30\",\n> > > \"evaluation_periods\": \"1\",\n> > > \"threshold\": \"90\",\n> > > \"alarm_actions\":\n> > > [ {\"Fn::GetAtt\": [\"ScaleUpPolicy\", \"AlarmUrl\"]} ],\n> > > \"matching_metadata\":\n> > > {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> > > \"comparison_operator\": \"gt\",\n> > > \"repeat_actions\" : true\n> > > }\n> > > },\n> > >\n> > > \"CPUAlarmLow\": {\n> > > \"Type\": \"OS::Ceilometer::Alarm\",\n> > > \"Properties\": {\n> > > \"description\": \"Scale-down if CPU is less than 50% for 30 seconds\",\n> > > \"meter_name\": \"cpu_util\",\n> > > \"statistic\": \"avg\",\n> > > \"period\": \"30\",\n> > > \"evaluation_periods\": \"1\",\n> > > \"threshold\": \"50\",\n> > > \"alarm_actions\":\n> > > [ {\"Fn::GetAtt\": [\"ScaleDownPolicy\", \"AlarmUrl\"]} ],\n> > > \"matching_metadata\":\n> > > {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> > > \"comparison_operator\": \"lt\",\n> > > \"repeat_actions\" : true\n> > > }\n> > > }\n> > >\n> > > ...and everything seemed to work fine. But now I just created a stack\n> > again\n> > > and generated some load inside the first VM started. Scaling up occurred,\n> > > but after that the system is now continuously scaling up and down the VMs\n> > > even the load situation doesn\'t change. Seems to be the \"repeat_actions\"\n> > > definitions didn\'t help after all...\n> > >\n> > > Br,\n> > > -Juha\n> > >\n> > >\n> > > On 25 February 2014 00:27, Steven Dake < sdake at redhat.com > wrote:\n> > >\n> > >\n> > >\n> > > Juha,\n> > >\n> > > Copying Angus so he sees. He wrote a big majority of the ceilometer +\n> > heat\n> > > integration and might have a better idea of the details of the problem\n> > you\n> > > face.\n> > >\n> > >\n> > > On 02/24/2014 01:27 AM, Juha Tynninen wrote:\n> > >\n> > >\n> > >\n> > > Hi,\n> > >\n> > > I\'m having some problems concerning auto scaling feature.\n> > > Any ideas?\n> > >\n> > > First scaling up and down is working just fine. But then when tested\n> > later on\n> > > scaling down/up is no longer working properly.\n> > > Scaling down may occur even it shouldn\'t or scaling up doesn\'t occur\n> > even it\n> > > should. When in this situation I remove all the\n> > > received metric data from the DB, auto scaling starts to work again.\n> > >\n> > > Ceilometer is configured to use Mongo and the auto scaling is based on\n> > the\n> > > cpu_util metrics.\n> > >\n> > > Related configurations:\n> > > -----------------------\n> > > /etc/ceilometer/pipeline.yaml on compute nodes:\n> > >\n> > > name: cpu_pipeline\n> > > interval: 15\n> > >\n> > > /etc/ceilometer/ceilometer.conf on controller:\n> > > evaluation_interval=15\n> > >\n> > > Heat template used:\n> > > -------------------\n> > > \"Resources\" : {\n> > >\n> > > \"Group_A\" : {\n> > > \"Type\" : \"AWS::AutoScaling::AutoScalingGroup\",\n> > > \"Properties\" : {\n> > > \"AvailabilityZones\" : { \"Fn::GetAZs\" : \"\"},\n> > > \"LaunchConfigurationName\" : { \"Ref\" : \"Group_A_Config\" },\n> > > \"MinSize\" : \"1\",\n> > > \"MaxSize\" : \"3\",\n> > > \"Tags\" : [\n> > > { \"Key\" : \"metering.server_group\", \"Value\" : \"Group_A\" },\n> > > { \"Key\" : \"custom_metadata\", \"Value\" : \"test\" }\n> > > ],\n> > > \"VPCZoneIdentifier\" : [ { \"Ref\" : \"PrivateSubnetId\" } ]\n> > > }\n> > > },\n> > >\n> > > \"Group_A_Config\" : {\n> > > \"Type\" : \"AWS::AutoScaling::LaunchConfiguration\",\n> > > \"Properties\": {\n> > > \"ImageId\" : { \"Ref\" : \"ImageId\" },\n> > > \"InstanceType\" : { \"Ref\" : \"InstanceType\" },\n> > > \"KeyName\" : { \"Ref\" : \"KeyName\" }\n> > > }\n> > > },\n> > >\n> > > \"ScaleUpPolicy\" : {\n> > > \"Type\" : \"AWS::AutoScaling::ScalingPolicy\",\n> > > \"Properties\" : {\n> > > \"AdjustmentType\" : \"ChangeInCapacity\",\n> > > \"AutoScalingGroupName\" : { \"Ref\" : \"Group_A\" },\n> > > \"Cooldown\" : \"20\",\n> > > \"ScalingAdjustment\" : \"1\"\n> > > }\n> > > },\n> > >\n> > > \"ScaleDownPolicy\" : {\n> > > \"Type\" : \"AWS::AutoScaling::ScalingPolicy\",\n> > > \"Properties\" : {\n> > > \"AdjustmentType\" : \"ChangeInCapacity\",\n> > > \"AutoScalingGroupName\" : { \"Ref\" : \"Group_A\" },\n> > > \"Cooldown\" : \"20\",\n> > > \"ScalingAdjustment\" : \"-1\"\n> > > }\n> > > },\n> > >\n> > > \"CPUAlarmHigh\": {\n> > > \"Type\": \"OS::Ceilometer::Alarm\",\n> > > \"Properties\": {\n> > > \"description\": \"Scale-up if CPU is greater than 90% for 20 seconds\",\n> > > \"meter_name\": \"cpu_util\",\n> > > \"statistic\": \"avg\",\n> > > \"period\": \"20\",\n> > > \"evaluation_periods\": \"1\",\n> > > \"threshold\": \"90\",\n> > > \"alarm_actions\":\n> > > [ {\"Fn::GetAtt\": [\"ScaleUpPolicy\", \"AlarmUrl\"]} ],\n> > > \"matching_metadata\":\n> > > {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> > > \"comparison_operator\": \"gt\"\n> > > }\n> > > },\n> > >\n> > > \"CPUAlarmLow\": {\n> > > \"Type\": \"OS::Ceilometer::Alarm\",\n> > > \"Properties\": {\n> > > \"description\": \"Scale-down if CPU is less than 50% for 20 seconds\",\n> > > \"meter_name\": \"cpu_util\",\n> > > \"statistic\": \"avg\",\n> > > \"period\": \"20\",\n> > > \"evaluation_periods\": \"1\",\n> > > \"threshold\": \"50\",\n> > > \"alarm_actions\":\n> > > [ {\"Fn::GetAtt\": [\"ScaleDownPolicy\", \"AlarmUrl\"]} ],\n> > > \"matching_metadata\":\n> > > {\"metadata.user_metadata.server_group\": \"Group_A\" },\n> > > \"comparison_operator\": \"lt\"\n> > > }\n> > >\n> > > In ceilometer logs I can see the following kind of warnings:\n> > >\n> > > <44>Feb 24 08:41:08 node-16\n> > > ceilometer-ceilometer.collector.dispatcher.database WARNING: message\n> > > signature invalid, discarding message: {u\'counter_name\':\n> > > u\'instance.scheduled\', u\'user_id\': None, u\'message_signature\':\n> > > u\'d1b49ddf004edc5b7a8dc9405b42a71f2ae975d04c25838c3dc0ea0e6f6e4edd\',\n> > > u\'timestamp\': u\'2014-02-24 08:41:08.334580\', u\'resource_id\':\n> > > u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'message_id\':\n> > > u\'67e611e4-9d2f-11e3-81f1-080027e519cb\', u\'source\': u\'openstack\',\n> > > u\'counter_unit\': u\'instance\', u\'counter_volume\': 1, u\'project_id\':\n> > > u\'efcca4ba425c4beda73eb31a54df931a\', u\'resource_metadata\':\n> > {u\'instance_id\':\n> > > u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'weighted_host\': {u\'host\':\n> > > u\'node-18\', u\'weight\': 3818.0}, u\'host\': u\'scheduler.node-16\',\n> > > u\'request_spec\': {u\'num_instances\': 1, u\'block_device_mapping\':\n> > > [{u\'instance_uuid\': u\'48c815ab-01c9-4ac8-9096-ac171976598c\',\n> > > u\'guest_format\': None, u\'boot_index\': 0, u\'delete_on_termination\': True,\n> > > u\'no_device\': None, u\'connection_info\': None, u\'volume_id\': None,\n> > > u\'device_name\': None, u\'disk_bus\': None, u\'image_id\':\n> > > u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'source_type\': u\'image\',\n> > > u\'device_type\': u\'disk\', u\'snapshot_id\': None, u\'destination_type\':\n> > > u\'local\', u\'volume_size\': None}], u\'image\': {u\'status\': u\'active\',\n> > u\'name\':\n> > > u\'cirrosImg\', u\'deleted\': False, u\'container_format\': u\'bare\',\n> > > u\'created_at\': u\'2014-02-12T08:46:04.000000\', u\'disk_format\': u\'qcow2\',\n> > > u\'updated_at\': u\'2014-02-12T08:46:04.000000\', u\'properties\': {},\n> > > u\'min_disk\': 0, u\'min_ram\': 0, u\'checksum\':\n> > > u\'50bdc35edb03a38d91b1b071afb20a3c\', u\'owner\':\n> > > u\'efcca4ba425c4beda73eb31a54df931a\', u\'is_public\': True, u\'deleted_at\':\n> > > None, u\'id\': u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'size\': 9761280},\n> > > u\'instance_type\': {u\'root_gb\': 1, u\'name\': u\'m1.tiny\', u\'ephemeral_gb\':\n> > 0,\n> > > u\'memory_mb\': 512, u\'vcpus\': 1, u\'extra_specs\': {}, u\'swap\': 0,\n> > > u\'rxtx_factor\': 1.0, u\'flavorid\': u\'1\', u\'vcpu_weight\': None, u\'id\': 2},\n> > > u\'instance_properties\': {u\'vm_state\': u\'building\', u\'availability_zone\':\n> > > None, u\'terminated_at\': None, u\'ephemeral_gb\': 0, u\'instance_type_id\': 2,\n> > > u\'user_data\':\n> > u\'Q29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PSI9PT0\n> > > ...\n> > > , u\'cleaned\': False, u\'vm_mode\': None, u\'deleted_at\': None,\n> > > u\'reservation_id\': u\'r-l91mh33v\', u\'id\': 274, u\'security_groups\':\n> > > {u\'objects\': []}, u\'disable_terminate\': False, u\'root_device_name\': None,\n> > > u\'display_name\': u\'tyky-Group_A-55cklit7nvbq-Group_A-2-yis32na5m7ey\',\n> > > u\'uuid\': u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'default_swap_device\':\n> > > None, u\'info_cache\': {u\'instance_uuid\':\n> > > u\'48c815ab-01c9-4ac8-9096-ac171976598c\', u\'network_info\': []},\n> > u\'hostname\':\n> > > u\'tyky-group-a-55cklit7nvbq-group-a-2-yis32na5m7ey\', u\'launched_on\':\n> > None,\n> > > u\'display_description\':\n> > u\'tyky-Group_A-55cklit7nvbq-Group_A-2-yis32na5m7ey\',\n> > > u\'key_data\': u\'ssh-rsa\n> > >\n> > AAAAB3NzaC1yc2EAAAADAQABAAABAQC39hmz8e40Xv/+QKkLyRA7j02RfIG61cr1j41RftnkOF3ZbwBzi7qibsOA3gC9Ln05YbB6z2/iUnQzxQsoOpmlnXuv2O296utY2ZCTKhdFSzn2Ot7l635zEXkivMc97wz4bITtaBTjX3nV6sXOfevdTIOJeC11SqxmfNRRzXcz9fRv6kLjz7IrA0tvRTp2xDVtFEj+vFLWaXc3TcUSygxiSLeAuNkH1rZ9jVuHXXvzb/e7navrGyJec2P86AQg2TUk77MhLjPcbyKiJJK0DhK6zOkZUWXtgIVQx7+gO/Xs2QgQHcw+VdzRzpJK+/EOzUOU8IDWNnyfaJEnQEoX2oMj\n> > > Generated by Nova\\n\', u\'deleted\': False, u\'config_drive\': u\'\',\n> > > u\'power_state\': 0, u\'default_ephemeral_device\': None, u\'progress\': 0,\n> > > u\'project_id\': u\'efcca4ba425c4beda73eb31a54df931a\', u\'launched_at\': None,\n> > > u\'scheduled_at\': None, u\'node\': None, u\'ramdisk_id\': u\'\',\n> > u\'access_ip_v6\':\n> > > None, u\'access_ip_v4\': None, u\'kernel_id\': u\'\', u\'key_name\': u\'heat_key\',\n> > > u\'updated_at\': None, u\'host\': None, u\'user_id\':\n> > > u\'ef4e983291ef4ad1b88eb1f776bd52b6\', u\'system_metadata\':\n> > > {u\'instance_type_memory_mb\': 512, u\'instance_type_swap\': 0,\n> > > u\'instance_type_vcpu_weight\': None, u\'instance_type_root_gb\': 1,\n> > > u\'instance_type_name\': u\'m1.tiny\', u\'instance_type_id\': 2,\n> > > u\'instance_type_ephemeral_gb\': 0, u\'instance_type_rxtx_factor\': 1.0,\n> > > u\'image_disk_format\': u\'qcow2\', u\'instance_type_flavorid\': u\'1\',\n> > > u\'instance_type_vcpus\': 1, u\'image_container_format\': u\'bare\',\n> > > u\'image_min_ram\': 0, u\'image_min_disk\': 1, u\'image_base_image_ref\':\n> > > u\'11848cbf-a428-4dfb-8818-2f0a981f540b\'}, u\'task_state\': u\'scheduling\',\n> > > u\'shutdown_terminate\': False, u\'cell_name\': None, u\'root_gb\': 1,\n> > u\'locked\':\n> > > False, u\'name\': u\'instance-00000112\', u\'created_at\':\n> > > u\'2014-02-24T08:41:08.257534\', u\'locked_by\': None, u\'launch_index\': 0,\n> > > u\'memory_mb\': 512, u\'vcpus\': 1, u\'image_ref\':\n> > > u\'11848cbf-a428-4dfb-8818-2f0a981f540b\', u\'architecture\': None,\n> > > u\'auto_disk_config\': False, u\'os_type\': None, u\'metadata\':\n> > > {u\'metering.server_group\': u\'Group_A\', u\'AutoScalingGroupName\':\n> > > u\'tyky-Group_A-55cklit7nvbq\', u\'custom_metadata\': u\'test\'}},\n> > > u\'security_group\': [u\'default\'], u\'instance_uuids\':\n> > > [u\'48c815ab-01c9-4ac8-9096-ac171976598c\']}, u\'event_type\':\n> > > u\'scheduler.run_instance.scheduled\'}, u\'counter_type\': u\'delta\'}\n> > >\n> > > Also the following warnings/errors can be seen but they seem to occur\n> > when\n> > > auto scaling is properly working and have no negative effects as such:\n> > >\n> > > <44>Feb 24 08:43:08 node-16\n> > > <U+FEFF>ceilometer-ceilometer.transformer.conversions WARNING: dropping\n> > > sample with no predecessor: <ceilometer.sample.Sample object at\n> > 0x3774fd0>\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:08 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <44>Feb 24 08:43:09 node-16 ceilometer-ceilometer.publisher.rpc AUDIT:\n> > > Publishing 1 samples on metering\n> > > <43>Feb 24 08:43:09 node-16\n> > > ceilometer-ceilometer.collector.dispatcher.database ERROR: Failed to\n> > record\n> > > metering data: not okForStor\n> > > age\n> > > Traceback (most recent call last):\n> > > File\n> > >\n> > \"/usr/lib/python2.7/dist-packages/ceilometer/collector/dispatcher/database.py\",\n> > > line 65, in record_metering_data\n> > > self.storage_conn.record_metering_data(meter)\n> > > File\n> > \"/usr/lib/python2.7/dist-packages/ceilometer/storage/impl_mongodb.py\",\n> > > line 417, in record_metering_data\n> > > upsert=True,\n> > > File \"/usr/lib/python2.7/dist-packages/pymongo/collection.py\", line 487,\n> > in\n> > > update\n> > > check_keys, self.__uuid_subtype), safe)\n> > > File \"/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py\", line\n> > 969, in\n> > > _send_message\n> > > rv = self.__check_response_to_last_error(response)\n> > > File \"/usr/lib/python2.7/dist-packages/pymongo/mongo_client.py\", line\n> > 911, in\n> > > __check_response_to_last_error\n> > > raise OperationFailure(details[\"err\"], details[\"code\"])\n> > > OperationFailure: not okForStorage\n> > >\n> > > Br,\n> > > -Juha\n> > >\n> > >\n> > > _______________________________________________\n> > > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > > Post to     : openstack at lists.openstack.org Unsubscribe :\n> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > >\n> > >\n> > >\n> > > _______________________________________________\n> > > Mailing list:\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > > Post to     : openstack at lists.openstack.org\n> > > Unsubscribe :\n> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> > >\n> >\n> \n\n\n','<CAC4iNR-00siTRS2EHrOgtXmt+L2c=tnQsx6cQtzJN0Qvx3CyQw@mail.gmail.com>',NULL),('<1806694389.13928876.1417610041013.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-12-03 07:34:01',-18000,'2014-12-03 12:34:01',NULL,'[Openstack] [Ceilometer] looking for alarm best practice -\n please	help','\n\n> Hi folks,\n> \n> \n> \n> I wonder if anyone could share some best practice regarding to the usage of\n> ceilometer alarm. We are using the alarm evaluation/notification of\n> ceilometer and we don?t feel very well of the way we use it. Below is our\n> problem:\n> \n> \n> \n> ============================\n> \n> Scenario:\n> \n> When cpu usage or memory usage above a certain threshold, alerts should be\n> displayed on admin?s web page. There should be a 3 level alerts according to\n> meter value, namely notice, warning, fatal. Notice means the meter value is\n> between 50% ~ 70%, warning means between 70% ~ 85% and fatal means above 85%\n> \n> For example:\n> \n> * when one vm?s cpu usage is 72%, an alert message should be displayed saying\n> ?Warning: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] cpu usage is above 70%?.\n> \n> * when one vm?s memory usage is 90%, another alert message should be created\n> saying ?Fatal: vm[d9b7018b-06c4-4fba-8221-37f67f6c6b8c] memory usage is\n> above 85%?\n> \n> \n> \n> Our current Solution:\n> \n> We used ceilometer alarm evaluation/notification to implement this. To\n> distinguish which VM and which meter is above what value, we?ve created one\n> alarm for each VM by each condition. So, to monitor 1 VM, 6 alarms will be\n> created because there are 2 meters and for each meter there are 3 levels.\n> That means, if there are 100 VMs to be monitored, 600 alarms will be\n> created.\n> \n> \n> \n> Problems:\n> \n> * The first problem is, when the number of meters increases, the number of\n> alarms will be multiplied. For example, customer may want alerts on disk and\n> network IO rates, and if we do that, there will be 4*3=12 alarms for each\n> VM.\n> \n> * The second problem is, when one VM is created, multiple alarms will be\n> created, meaning multiple http requests will be fired. In the case above, 6\n> HTTP requests will be needed once a VM is created. And this number also\n> increases as the number of meters goes up.\n\nOne way of reducing both the number of alarms and the volume of notifications\nwould be to group related VMs, if such a concept exists in your use-case.\n\nThis is effectively how Heat autoscaling uses ceilometer, alarming on the\naverage of some statistic over a set of instances (as opposed to triggering\non individual instances).\n\nThe VMs could be grouped by setting user-metadata of form:\n\n  nova boot ... --meta metering.my_server_group=foobar\n\nAny user-metadata prefixed with \'metering.\' will be preserved by ceilometer\nin the resource_metadata.user_metedata stored for each sample, so that it\ncan used to select the statistics on which the alarm is based, e.g.\n\n  ceilometer alarm-threshold-create --name cpu_high_foobar \\\n    --description \'warning: foobar instance group running hot\' \\\n    --meter-name cpu_util --threshold 70.0 \\\n    --comparison-operator gt --statistic avg \\\n    ...\n    --query metadata.user_metedata.my_server_group=foobar\n\nThis approach is of course predicated on the there being some natural\ngrouping relation between instances in your environment.\n\nCheers,\nEoghan\n\n\n> =============================\n> \n> \n> \n> Do anyone have any suggestions?\n> \n> \n> \n> \n> \n> \n> \n> Best Regards!\n> \n> Kurt Rao\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n>\n\n\n','<153501d00ecc$e4da1880$ae8e4980$@chinacloud.com.cn>',NULL),('<18079974.449.1403691665478.JavaMail.Nick@Nick-Laptop>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2014-06-25 18:21:10',28800,'2014-06-25 10:21:10',NULL,'[openstack-dev] [Neutron ML2] Potential DB lock when developing\n new mechanism driver','Hi Kevin,\n\nThanks for your reply. Actually, it is not that straightforward.\nEven if postcommit is outside the \'with\' statement, the transaction is not \'truly\' committed immediately. Because when I put my db code (reading and writing ml2-related tables) in postcommit, db lock wait exception is still thrown.\n\nLi Ma\n\n----- Original Message -----\nFrom: \"Kevin Benton\" <blak111 at gmail.com>\nTo: \"OpenStack Development Mailing List (not for usage questions)\" <openstack-dev at lists.openstack.org>\nSent: ???, 2014? 6 ? 25? ?? 4:59:26\nSubject: Re: [openstack-dev] [Neutron ML2] Potential DB lock when developing new mechanism driver\n\n\n\nThe post_commit methods occur outside of the transactions. You should be able to perform the necessary database calls there. \n\n\nIf you look at the code snippet in the email you provided, you can see that the \'try\' block surrounding the postcommit method is at the same indentation-level as the \'with\' statement for the transaction so it will be closed at that point. \n\n\nCheers, \nKevin Benton \n\n\n-- \nKevin Benton \n\n\n\nOn Tue, Jun 24, 2014 at 8:33 PM, Li Ma < skywalker.nick at gmail.com > wrote: \n\n\nHi all, \n\nI\'m developing a new mechanism driver. I\'d like to access ml2-related tables in create_port_precommit and create_port_postcommit. However I find it hard to do that because the two functions are both inside an existed database transaction defined in create_port function of ml2/plugin.py. \n\nThe related code is as follows: \n\ndef create_port(self, context, port): \n... \nsession = context.session \nwith session.begin(subtransactions=True): \n... \nself.mechanism_manager.create_port_precommit(mech_context) \ntry: \nself.mechanism_manager.create_port_postcommit(mech_context) \n... \n... \nreturn result \n\nAs a result, I need to carefully deal with the database nested transaction issue to prevent from db lock when I develop my own mechanism driver. Right now, I\'m trying to get the idea behind the scene. Is it possible to refactor it in order to make precommit and postcommit out of the db transaction? I think it is perfect for those who develop mechanism driver and do not know well about the functioning context of the whole ML2 plugin. \n\nThanks, \nLi Ma \n\n_______________________________________________ \nOpenStack-dev mailing list \nOpenStack-dev at lists.openstack.org \nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev \n\n\n\n\n-- \n\nKevin Benton \n_______________________________________________\nOpenStack-dev mailing list\nOpenStack-dev at lists.openstack.org\nhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev\n\n\n','<CAO_F6JNhy2s5cmeuune8FmHiY=uhpSS2KnKdpcmTwDQRwwnYBA@mail.gmail.com>',NULL),('<1808506046.41.1383372549245.JavaMail.jenkins@jenkins01.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-11-02 06:09:09',0,'2013-11-02 06:09:09',NULL,'[Openstack-stable-maint] Build failed in Jenkins:\n	periodic-glance-python26-stable-folsom #48','See <https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/48/>\n\n------------------------------------------\n[...truncated 1310 lines...]\nFAIL: Tests that the /images/detail registry API returns list of\n----------------------------------------------------------------------\nTraceback (most recent call last):\n  File \"<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/glance/tests/unit/v1/test_api.py\",> line 1409, in test_get_details_filter_changes_since\n    self.assertEquals(res.status_int, 400)\nAssertionError: 200 != 400\n>>  raise self.failureException, \\\n          (None or \'%r != %r\' % (200, 400))\n    \n-------------------- >> begin captured logging << --------------------\nglance.store: DEBUG: Attempting to import store glance.store.filesystem.Store\nglance.store: DEBUG: Registering store <class \'glance.store.filesystem.Store\'> with schemes (\'file\', \'filesystem\')\nglance.store.base: DEBUG: Late loading location class glance.store.filesystem.StoreLocation\nglance.store.location: DEBUG: Registering scheme file with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme filesystem with {\'store_class\': <class \'glance.store.filesystem.Store\'>, \'location_class\': <class \'glance.store.filesystem.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.http.Store\nglance.store: DEBUG: Registering store <class \'glance.store.http.Store\'> with schemes (\'http\', \'https\')\nglance.store.base: DEBUG: Late loading location class glance.store.http.StoreLocation\nglance.store.location: DEBUG: Registering scheme http with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme https with {\'store_class\': <class \'glance.store.http.Store\'>, \'location_class\': <class \'glance.store.http.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.rbd.Store\nglance.store: DEBUG: Registering store <class \'glance.store.rbd.Store\'> with schemes (\'rbd\',)\nglance.store.base: DEBUG: Late loading location class glance.store.rbd.StoreLocation\nglance.store.location: DEBUG: Registering scheme rbd with {\'store_class\': <class \'glance.store.rbd.Store\'>, \'location_class\': <class \'glance.store.rbd.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.s3.Store\nglance.store.s3: ERROR: Could not find s3_store_host in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.s3.Store\'> with schemes (\'s3\', \'s3+http\', \'s3+https\')\nglance.store.base: DEBUG: Late loading location class glance.store.s3.StoreLocation\nglance.store.location: DEBUG: Registering scheme s3 with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+http with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme s3+https with {\'store_class\': <class \'glance.store.s3.Store\'>, \'location_class\': <class \'glance.store.s3.StoreLocation\'>}\nglance.store: DEBUG: Attempting to import store glance.store.swift.Store\nglance.store.swift: ERROR: Could not find swift_store_auth_address in configuration options.\nglance.store.base: ERROR: Failed to configure store correctly. Disabling add method.\nglance.store: DEBUG: Registering store <class \'glance.store.swift.Store\'> with schemes (\'swift+https\', \'swift\', \'swift+http\')\nglance.store.base: DEBUG: Late loading location class glance.store.swift.StoreLocation\nglance.store.location: DEBUG: Registering scheme swift+https with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift+http with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nglance.store.location: DEBUG: Registering scheme swift with {\'store_class\': <class \'glance.store.swift.Store\'>, \'location_class\': <class \'glance.store.swift.StoreLocation\'>}\nroutes.middleware: DEBUG: Initialized with method overriding = True, and path info altering = True\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-01T06:08:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'01\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'01\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-03T06:08:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'03\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'03\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:08:44+01:00 into {\'tz_sign\': u\'+\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'+01:00\', \'second\': u\'44\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-04T06:08:44-01:00 into {\'tz_sign\': u\'-\', \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': u\'01\', \'month\': u\'11\', \'timezone\': u\'-01:00\', \'second\': u\'44\', \'tz_minute\': u\'00\', \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'04\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'01\' for \'tz_hour\' with default None\niso8601.iso8601: DEBUG: Got u\'00\' for \'tz_minute\' with default None\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'04\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2013-11-05T06:08:44Z into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': u\'06\', \'tz_hour\': None, \'month\': u\'11\', \'timezone\': u\'Z\', \'second\': u\'44\', \'tz_minute\': None, \'year\': u\'2013\', \'separator\': u\'T\', \'day\': u\'05\', \'minute\': u\'08\'} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'2013\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'11\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got u\'06\' for \'hour\' with default None\niso8601.iso8601: DEBUG: Got u\'08\' for \'minute\' with default None\niso8601.iso8601: DEBUG: Got u\'44\' for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Matched GET /images/detail\nroutes.middleware: DEBUG: Route path: \'/images/detail\', defaults: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\nroutes.middleware: DEBUG: Match dict: {\'action\': u\'detail\', \'controller\': <glance.common.wsgi.Resource object at 0x55ae7d0>}\niso8601.iso8601: DEBUG: Parsed 2011-09-05 into {\'tz_sign\': None, \'second_fraction\': None, \'hour\': None, \'tz_hour\': None, \'month\': u\'09\', \'timezone\': None, \'second\': None, \'tz_minute\': None, \'year\': u\'2011\', \'separator\': None, \'day\': u\'05\', \'minute\': None} with default timezone <iso8601.iso8601.Utc object at 0x1c856d0>\niso8601.iso8601: DEBUG: Got u\'2011\' for \'year\' with default None\niso8601.iso8601: DEBUG: Got u\'09\' for \'month\' with default None\niso8601.iso8601: DEBUG: Got u\'05\' for \'day\' with default None\niso8601.iso8601: DEBUG: Got None for \'hour\' with default None\niso8601.iso8601: DEBUG: Got None for \'minute\' with default None\niso8601.iso8601: DEBUG: Got None for \'second\' with default None\nglance.registry.api.v1.images: INFO: Returning detailed image list\n--------------------- >> end captured logging << ---------------------\n\n----------------------------------------------------------------------\nXML: nosetests.xml\nSlowest 5 tests took 67.41 secs:\n    14.65    TestGlanceControl.test_bouncing\n    13.73    TestScrubber.test_delayed_delete\n    13.51    TestGlanceControl.test_reload\n    13.26    TestGlanceControl.test_respawn\n    12.27    TestApi.test_unsupported_default_store\n----------------------------------------------------------------------\nRan 932 tests in 483.718s\n\nFAILED (SKIP=89, failures=2)\nERROR: InvocationError: \'<https://jenkins01.openstack.org/job/periodic-glance-python26-stable-folsom/ws/.tox/py26/bin/nosetests\'>\n___________________________________ summary ____________________________________\nERROR:   py26: commands failed\n+ result=1\n+ echo \'Begin pip freeze output from test virtualenv:\'\nBegin pip freeze output from test virtualenv:\n+ echo ======================================================================\n======================================================================\n+ .tox/py26/bin/pip freeze\nBabel==1.3\nJinja2==2.7.1\nMarkupSafe==0.18\nPaste==1.7.5.1\nPasteDeploy==1.5.0\nPygments==1.6\nRoutes==1.13\nSQLAlchemy==0.7.9\nSphinx==1.2b1\nTempita==0.5.1\nWebOb==1.0.8\namqp==1.3.2\nanyjson==0.3.3\nargparse==1.2.1\nboto==2.1.1\ncffi==0.7.2\ncolorama==0.2.7\ncoverage==3.7\ndecorator==3.4.0\ndistribute==0.7.3\ndocutils==0.10\neventlet==0.14.0\nglance==jenkins-periodic-glance-python26-stable-folsom-48\ngreenlet==0.4.1\nhttplib2==0.8\nimportlib==1.0.2\niso8601==0.1.8\njsonschema==2.2.0\nkombu==3.0.2\nlxml==3.2.3\nmox==0.5.3\nnose==1.3.0\nnose-exclude==0.1.10\nnosehtmloutput==0.0.5\nopenstack.nose-plugin==0.11\nordereddict==1.1\npasslib==1.6.1\npep8==1.1\npycparser==2.10\npycrypto==2.6.1\npysendfile==2.0.0\npython-swiftclient==1.8.0\npytz==2013.7\nrepoze.lru==0.6\nrequests==2.0.1\nsimplejson==3.3.1\nsqlalchemy-migrate==0.7.2\ntermcolor==1.1.0\nwsgiref==0.1.2\nxattr==0.7.2\n+ echo ======================================================================\n======================================================================\n+ \'[\' -d .testrepository \']\'\n+ sudo /usr/local/jenkins/slave_scripts/jenkins-sudo-grep.sh post\n+ sudoresult=0\n+ \'[\' 0 -ne 0 \']\'\n+ /usr/local/jenkins/slave_scripts/jenkins-oom-grep.sh post\n+ oomresult=0\n+ \'[\' 0 -ne 0 \']\'\n++ find . -name nose_results.html\n+ htmlreport=./nose_results.html\n+ \'[\' -f ./nose_results.html \']\'\n++ grep -c \'tr class=.passClass\' ./nose_results.html\n+ passcount=95\n+ \'[\' 95 -eq 0 \']\'\n+ exit 1\n+ rm -rf /tmp/tmp.r0XzgjP8i9\nBuild step \'Execute shell\' marked build as failure\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/48\nERROR: Failed to upload files\n2: No such file\n	at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2833)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2185)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2202)\n	at com.jcraft.jsch.ChannelSftp.stat(ChannelSftp.java:2159)\n	at be.certipost.hudson.plugin.SCPSite.mkdirs(SCPSite.java:314)\n	at be.certipost.hudson.plugin.SCPSite.upload(SCPSite.java:243)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:248)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)\n	at hudson.model.Run.execute(Run.java:1618)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:247)\n[SCP] Connecting to static.openstack.org\n[SCP] Trying to create /srv/static/logs/periodic/periodic-glance-python26-stable-folsom/centos6-13/48\nERROR: Failed to upload files\n2: No such file\n	at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2833)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2185)\n	at com.jcraft.jsch.ChannelSftp._stat(ChannelSftp.java:2202)\n	at com.jcraft.jsch.ChannelSftp.stat(ChannelSftp.java:2159)\n	at be.certipost.hudson.plugin.SCPSite.mkdirs(SCPSite.java:314)\n	at be.certipost.hudson.plugin.SCPSite.createOutStream(SCPSite.java:208)\n	at be.certipost.hudson.plugin.SCPRepositoryPublisher.perform(SCPRepositoryPublisher.java:204)\n	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)\n	at hudson.model.Build$BuildExecution.post2(Build.java:183)\n	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)\n	at hudson.model.Run.execute(Run.java:1618)\n	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)\n	at hudson.model.ResourceController.execute(ResourceController.java:88)\n	at hudson.model.Executor.run(Executor.java:247)\n\n\n','<233619725.30.1383286159613.JavaMail.jenkins@jenkins01.openstack.org>',NULL),('<1809575913.11452933.1405413161581.JavaMail.zimbra@redhat.com>','http://lists.openstack.org/pipermail/openstack',NULL,'2014-07-15 04:32:41',-14400,'2014-07-15 08:32:41',NULL,'[Openstack] ceilometer output not showing properly.','\n\n> Hi All,\n> \n> \n> ICEHOUSE with Centos KVM (Two tier ).\n> \n> While verifying the ceilometer meter-list its showing outputs but when i put\n> the statistics command its output is null.\n> \n> Please guide me on this.\n> \n> \n> \n> Commands:\n> \n> \n> [root at controller ~]# ceilometer meter-list\n> +---------------------------------+-------+-----------+----------------------------------------------------+----------------------------------+----------------------------------+\n> | Name | Type | Unit | Resource ID | User ID | Project ID |\n> +---------------------------------+-------+-----------+----------------------------------------------------+----------------------------------+----------------------------------+\n> | disk.ephemeral.size | gauge | GB | 05dfa5db-40c3-4002-a356-1eb530914d86 |\n> | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb |\n> | disk.ephemeral.size | gauge | GB | 1149f13d-7438-4395-92f3-86fad3a1ad4e |\n> | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb |\n> | disk.ephemeral.size | gauge | GB | 16c59c57-3074-46d5-9940-41c318caffa7 |\n> | 4753cf10dd5a405285412b2c499b13a6 | 863c1374386043f6a78ee9eb0bbd7adb |\n> \n> Verify the Telemetry installation\n> \n> \n> To test the Telemetry installation, download an image from the Image Service,\n> and use the ceilometer command to display usage statistics.\n> \n> \n> [root at controller ~]# glance image-download\n> \"Opencascade_Centos6.3_OpenGL_OS_IMAGE\" > opencascade.img\n> [root at controller ~]# ceilometer statistics -m image.download -p 60\n> +--------+--------------+------------+-------+-----+-----+-----+-----+----------+----------------+--------------+\n> | Period | Period Start | Period End | Count | Min | Max | Sum | Avg |\n> | Duration | Duration Start | Duration End |\n> +--------+--------------+------------+-------+-----+-----+-----+-----+----------+----------------+--------------+\n> +--------+--------------+------------+-------+-----+-----+-----+-----+----------+----------------+--------------+\n>\n\nHave you configured glance to emit notifications?\n\nCan you see statistics for any other meters?\n\nCheers,\nEoghan\n\n \n> its not displaying the output.\n> \n> \n> \n> Regards,\n> Dhanesh M.\n> \n> \n> _______________________________________________\n> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> Post to     : openstack at lists.openstack.org\n> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack\n> \n\n\n','<CAA0wu4cY69ByOLVDVz514BuiBnQ8+Nbkt_JyNC=AYw+woSZr9A@mail.gmail.com>',NULL),('<18095878.338.1366870649988.JavaMail.jenkins@jenkins.openstack.org>','http://lists.openstack.org/pipermail/openstack-stable-maint',NULL,'2013-04-25 06:17:29',0,'2013-04-25 06:17:29',NULL,'[Openstack-stable-maint] Jenkins build is back to normal :\n periodic-glance-python26-stable-grizzly #15','See <https://jenkins.openstack.org/job/periodic-glance-python26-stable-grizzly/15/>\n\n\n\n','<1445297960.316.1366784564623.JavaMail.jenkins@jenkins.openstack.org>',NULL),('<1809851637.2380395.1352981333861.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2012-11-15 07:08:53',-18000,'2012-11-15 12:08:53',NULL,'[openstack-dev] [nova][ceilometer]\n	model	for	ceilo/nova	interaction going forward','\n\n> > 5. nova packages a consumable library layered over the hypervisor\n> >    driver, that just exposes the diagnostics available from libvirt\n> >    et al. The ceilo compute agent continues to exist under the\n> >    ceilo\n> >    umbrella, but talks to the hypervisor directly via this stable,\n> >    versioned nova library.\n> > \n> >    + no remote calls required from ceilo-->nova-{api|compute}\n> >    - needs an independent versioning scheme\n> >    - still stuck in the \"implicit trust\" model?\n> \n> I think this is similar to my above statement, the only difference is\n> the direction, and I think you still need remove call, otherwise,\n> what will be the communication channel?\n\nWell I guess there would still be IPC in the form of say interaction\nwith libvirtd under the covers, but not RPC in the sense of calls into\nthe nova REST APIs or via the AMQP RPC conduit.\n\n(Then in the ceilo agent we could also need remote calls to publish\nthese data, but that\'s not the focus of this discussion).\n\nCheers,\nEoghan\n\n\n','<DDCAE26804250545B9934A2056554AA033D16D@SHSMSX101.ccr.corp.intel.com>',NULL),('<1809860607.32738689.1372930538633.JavaMail.root@redhat.com>','http://lists.openstack.org/pipermail/openstack-dev',NULL,'2013-07-04 05:35:38',-14400,'2013-07-04 09:35:38',NULL,'[openstack-dev] [Ceilometer] Changing pollster/pipeline\n parameters','\nHi Phil,\n\nSome more thoughts inline ...\n\n> > A couple of related questions on managing CM pollster behavior via \"config\"\n> > type files:\n> > \n> > 1. I\'m trying to make some modifications to the timing of the Glance\n> > (image)\n> > polling in a default CM install. It looks like the pipeline interval fields\n> > are the way to do it, and that I should tweak it using a yaml config file,\n> > but I can\'t seem to verify based on a read-through of the code. Can anyone\n> > confirm?\n> \n> Yep, the configured interval in the /etc/ceilometer/pipeline.yaml is the way\n> to go.\n> \n> For example:\n> \n>  $ sed -i \'s/interval: .*$/interval: 10/\' /etc/ceilometer/pipeline.yaml\n>  $ # restart ceilometer-agent-central\n>  $ ceilometer sample-list -m image.size | tail -5\n>  | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B\n>  | | 2013-07-03T21:40:15        |\n>  | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B\n>  | | 2013-07-03T21:40:25        |\n>  | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B\n>  | | 2013-07-03T21:40:35        |\n>  | df52ee46-91c0-417a-a27c-ca0b447fb5db | image.size | gauge | 25165824.0 | B\n>  | | 2013-07-03T21:40:45        |\n>  +--------------------------------------+------------+-------+------------+------+----------------------------+\n> \n> As you see the meter is now being collected at a 10s cadence.\n> \n> This timing is pulled in via the AgentManager base class:\n> \n>   https://github.com/openstack/ceilometer/blob/master/ceilometer/agent.py#L90\n\nI should have been more explicit here, in the sense of pointing out 